Disseny de Sistemes Orientats A Objectes Amb Notació UML

AULA POLITCNICA 17
Enginyeria del software

Disseny I
Disseny de sistemes orientats a objectes
amb notaci UML
AULA POLITCNICA / FIB
EDICIONS UPC
Cristina Gmez - Enric Mayol
Antoni Oliv - Ernest Teniente
Enginyeria del software
Disseny I
Disseny de sistemes orientats a objectes
amb notaci UML
Primera edici: setembre de 1999
Reimpressi: setembre de 2000
Segona edici: febrer de 2001
Aquest llibre s'ha publicat amb la collaboraci
del Comissionat per a Universitats i Recerca
i del Departament de Cultura de la Generalitat de Catalunya.
En collaboraci amb el Servei de Llenges i Terminologia de la UPC.
Disseny de la coberta: Manuel Andreu
Els autors, 1999
Edicions UPC, 1999
Edicions de la Universitat Politcnica de Catalunya, SL
Jordi Girona Salgado 31, 08034 Barcelona
Tel. 93 401 68 83 Fax 93 401 58 85
Edicions Virtuals: www.edicionsupc.es
e-mail: edupc@sg.upc.es
Producci: CPET (Centre de Publicacions del Campus Nord)
La Cup. Gran Capit s/n, 08034 Barcelona
Dipsit legal: B-2.615-2001
ISBN obra complerta: 84-8301-437-8
ISBN: 84-8301-460-2
Sn rigorosament prohibides, sense l'autoritzaci escrita dels titulars del copyright, sota les sancions
establertes a la llei, la reproducci total o parcial d'aquesta obra per qualsevol procediment, inclosos la
reprografia i el tractament informtic, i la distribuci d'exemplars mitjanant lloguer o prstec pblics.
ndex
1 Introducci
1.1 Introducci al disseny de software ................................................................... 9
1.2 Introducci a larquitectura del software......................................................... 11
1.3 Introducci als patrons de disseny .................................................................. 17
1.4 Patr arquitectnic en capes ........................................................................... 25
1.5 Arquitectura lgica i fsica dels Sistemes dInformaci ................................. 33
2 Disseny orientat a objectes en UML
2.1 Introducci al disseny orientat a objectes en UML......................................... 43
2.2 Conceptes dUML per al disseny .................................................................... 49
2.3 Disseny de la Capa de Domini ........................................................................ 61
2.3.1 Especificaci dun exemple: gesti dun club de tennis.................. 63
2.3.2 Normalitzaci de lesquema conceptual despecificaci ................ 69
2.3.3 Aplicaci de patrons de disseny ...................................................... 75
2.3.3.1 Patr Iterador .................................................................... 75
2.3.3.2 Patr Controlador ............................................................. 81
2.3.3.3 Assignaci de Responsabilitats a Objectes ...................... 87
2.3.3.4 Patr Estat ........................................................................ 99
2.3.3.5 Patr Mtode Plantilla .................................................... 111
2.3.4 Exemple de disseny de la capa de domini .................................... 119
2.4 Disseny de la Capa de Presentaci................................................................ 129
2.4.1 - Introducci...................................................................................... 129
2.4.2 Patr Model Vista Controlador ............................................... 137
2.5 Disseny de la Capa de Gesti de Dades: persistncia en BDOO.................. 147
77
Introducci al disseny de software 1
Introducci al disseny de software
Etapes del desenvolupament de software
Disseny de software
Bibliografia
Anlisi de Requeriments Quin sistema cal construir?
Especificaci Qu ha de fer el sistema?
Disseny Com ho fa el sistema?
Implementaci
Independent de
la tecnologia
Dependent de
la tecnologia
Especificaci del sist. sw.
Arquitectura del sist. sw.
99
Els autors, 2001; Edicions UPC, 2001.
Disseny de software
Disseny de software s lactivitat daplicar diferents tcniques i principis
amb el propsit de definir un sistema amb el suficient detall per permetre la
seva construcci fsica (implementaci).
Punt de partida:
Resultat de lespecificaci: (Qu ha de fer el sistema?)
. Especificaci de dades (Model de Dades)
. Especificaci de processos (Models Funcional i de Comportament)
. Especificaci de la interacci amb lusuari (Model de la Interfcie)
Tecnologia (Amb quins recursos)
. Recursos hardware i software disponibles
. Requeriments no funcionals del sistema
Resultat del disseny: (Com ho fa el sistema?)
Estructura interna del sistema software (Arquitectura del Sistema Software)
Disseny de les Dades
Disseny de la Interfcie
Disseny dels Programes
Procs del disseny:
Metodologies de disseny
Adaptaci de solucions genriques a problemes de disseny (Patrons de disseny)
Bibliografia
Ingeni era del software
Un enfoque prctico
R. G. Pressman
McGraw Hill, 1998. (Cuarta Edicin)
Caps. 11 i 13.
10 10
Introducci: Introducci a larquitectura del software 1
Introducci a larquitectura del software
Arquitectura del software
Components
Vistes
Propietats de larquitectura
Principis de disseny
Relaci entre propietats i principis de disseny
Determinaci de larquitectura
Bibliografia
Arquitectura del software
Larquitectura del software s una descripci dels subsistemes i
components (computacionals) dun sistema software, i les relacions entre ells.
Larquitectura del software s el resultat de lactivitat de disseny arquitectnic del
software.
La determinaci de larquitectura del software consisteix en la presa de decisions
respecte a:
Lorganitzaci del sistema software
La selecci dels elements estructurals i les seves interfcies
Comportament daquests elements estructurals
La possible composici dels elements estructurals en subsistemes ms grans
Lestil que guia aquesta organitzaci
tenint en compte les propietats (requeriments no funcionals) del sistema software que
es volen assolir:
Eficincia, canviabilitat, usabilitat, fiabilitat, ...
11 11
Components
Un component s una part fsica i reemplaable dun sistema que :
s conforme a, i
proporciona una realitzaci
dun conjunt dinterfcies especificades contractualment.
Un component s una part encapsulada dun sistema software
Els components sn els blocs constitutius de larquitectura del sistema
Els components noms tenen dependncies contextuals explcites
A nivell de llenguatge de programaci, els components es poden representar com a:
- mduls
- classes dobjectes
- un conjunt de funcions relacionades
- etc.
Relacions entre components
Una relaci denota una connexi entre components.
Les relacions poden ser:
Esttiques
. Tenen a veure amb la collocaci dels components en larquitectura
. Es veuen directament en el codi
. Exemples: Crides a procediments, accs a variables compartides
Dinmiques
. Tracten de les connexions temporals i les interaccions dinmiques entre els
components
. No sn visibles fcilment en el codi
. Exemples: Protocols client-servidor, protocols daccs a bases de dades
12 12
Vistes
Una vista:
representa un aspecte parcial de larquitectura,
mostra propietats especfiques
Disseny
Procs
Implementaci
Desplegament
Casos ds
Els subsistemes i components sespecifiquen normalment en diferents vistes, per
mostrar diferents propietats rellevants (req. func. i no func) del sistema software.
Casos ds: Com lusuari o analista veu el funcionament del sitema (cas ds, interacci)
Disseny: Descriu la soluci software (classes, interacci entre objectes )
Implementaci: Fitxers i components del sistema implementat (llibreries, executables)
Procs: Mecanismes de concurncia i sincronitzaci dels processos del sistema
Desplegament: Nodes que composen la topologia hardware del sistema instalat
Propietats de larquitectura
Canviable:
Extensible: Noves funcionalitats o millores dels components
Portable: Canvis plataforma hardware, sistemes operatius, llenguatges
Mantenible: Detecci i reparaci derrors
Reestructurable: Reorganitzaci de components
Interoperable
Capacitat de dues o ms entitats software dintercanviar funcionalitat i dades
Eficient
Temps de resposta, rendiment, s de recursos
Fiable:
Tolerncia a fallades: Prdua de connexi i recuperaci posterior
Robustesa: Protecci contra ls incorrecte I el tractament derrors inesperats
Provable
Facilitar les proves del sistema
Reusable: Assolir el que es vol amb lajuda del que es t
Reusar software ja existent
Fer software per a ser reusat
Integritat conceptual: Harmonia, simetria i predictibilitat
13 13
Principis de disseny
Abstracci
Encapsulament
Ocultaci dinformaci
Modularitzaci
Separaci de concerniments
Acoblament i cohesi
Suficincia, completesa i primitivitat
Separaci de poltica i implementaci
Separaci dinterfcie i implementaci
nic punt de referncia
Divideix-i-vencers
Principis de disseny: Ocultaci dinformaci
Confinar (ocultar) en un nic mdul (classe, etc.) un aspecte qualsevol del
software que s possible (probable) que canvi, i establir interfcies
intermduls que siguin insensibles als canvis previstos.
Si hi ha un canvi en laspecte ocultat (secret), quedar limitat al mdul
corresponent, sense afectar la resta del sistema. Les interfcies no quedaran
afectades.
Tamb es diu que el secret soculta en el mdul.
Aquest principi fou proposat per en D. Parnas, el 1972.
14 14
Relaci entre propietats i principis de disseny
Laplicaci dun principi de disseny pot afectar lassoliment duna propietat de
larquitectura del sistema
baix acoblament
alta cohesi
Canviabilitat
Eficincia
pot
Per exemple:
suposar
Determinaci de larquitectura:
Dues vies complementries
Especificaci
Mtode
Selecci
Patrons de disseny
Adaptaci
Arquitectura
Patr
Donats els requeriments del sistema degudament especificats, aplicar un conjunt passos genrics de
forma ordenada i sistemtica definits en un mtode
Donats els requeriments del sistema degudament especificats,
- identificar els problemes especfics a resoldre
- seleccionar solucions genriques a problemes concrets (patrons)
- i adaptar-ne la seva aplicaci tenint en compte el problema concret
- procs molt guiat
- procs independent
del problema
- procs poc guiat
- procs ms contextualitzat
al problema
15 15
Bibliografia
Pattern-ori ented Software Architecture. A System of patterns
F. Buschmann, R. Meunier, H. Rohnert, P.Sommerlad, M. Stal
John Wiley & Sons, 1996, Cap. 6.
The Unified Modeling Language User Gui de
G. Booch, J. Rumbaugh, I. Jacobson
Addison-Wesley, 1999, cap. 2, 25.
Component Software: Beyond Object-oriented programming
C. Szyperski
Addison-Wesley, 1998, cap. 4.
16 16
Introducci: Introducci als patrons de disseny 1
Introducci als patrons de disseny
Patrons de disseny: Definici.
Patrons de disseny: Categories.
Catleg parcial de patrons arquitectnics.
Catleg parcial de patrons de disseny.
Heterogenetat destils.
Bibliografia
Patrons de disseny: definici
Context:
Situaci on es presenta el problema de disseny
Problema:
Problema a resoldre
Forces: Aspectes que shan de considerar en la soluci
Soluci:
Esquema de soluci del problema, que equilibra les forces.
Dos aspectes:
. Esttic
. Dinmic
17 17
Patrons de disseny: Categories
Patr arquitectnic:
Un patr arquitectnic expressa un esquema dorganitzaci estructural
fonamental per a sistemes software.
Proporciona un conjunt de subsistemes predefinits, especifica les seves
responsabilitats, i inclou regles i guies per organitzar les relacions entre ells.
Patr de disseny:
Un cop determinat el patr arquitectnic, un patr de disseny dna un
esquema per refinar els seus subsistemes o components, o les relacions
entre ells.
Descriu lestructura :
+ duna soluci a un problema que apareix repetidament
+ de components que es comuniquen entre ells
Resol un problema de disseny general en un context particular
Modisme:
Usats en la fase dimplementaci per a transformar una arquitectura en un
programa escrit en un llenguatge especfic.
Descriu lestructura duna soluci depenent del llenguatge de programaci
Catleg parcial de patrons (o estils) arquitectnics
Crida i retorn:
estils arquitectnics ms usats, tradicionalment en grans sistemes
software
. Programa principal i subrutina
. Orientaci a objectes
. En capes
Centrat en dades:
per sistemes que requereixen accs a dades compartides
. Repositori
. Pissarra
Flux de dades:
per sistemes que donades unes dades dentrada realitzen una srie de
transformacions per obtenir unes dades de sortida
. Batch sequencial
. Tubs i filtres
Model - Vista - Controlador: per sistemes interactius
18 18
Crida i retorn: programa principal i subrutina
Main
Sub 3 Sub 2 Sub 1
Descomposici jerrquica dun programa principal en subrutines
Una subrutina (component) al rebre el control (i dades) dun dels seus pares,
el passa cap als seus fills, el retorn del control es fa en sentit contrari (de fills
a pares).
Facilita la canviabilitat
Estil tpic de la programaci tradicional
Crida i retorn: Orientaci a objectes
Objecte
Op1()
Op2()
Objecte
Op3()
Objecte
Op4()
Cada component agrupa (encapsula) les dades i els mecanismes per a
manipular-les.
La comunicaci entre components es realitza mitjanant la invocaci de
serveis oferts pels component (operacions).
Facilita la canviabilitat i reusabilitat
19 19
Crida i retorn: En capes
Capa 3 Comp. 3-1 Comp. 3-2 Comp. 3-p
Capa 2 Comp. 2-1 Comp. 2-2 Comp. 2-n
Capa 1 Comp. 1-1 Comp. 1-2
Els components sagrupen en capes.
La comunicaci solament pot ser entre components de la mateixa capa, o
entre components de capes contiges.
Facilita la canviabilitat i portabilitat.
Centrat en dades: Repositori
Les dades compartides per diferents clients estan en un mateix lloc
Els clients es comuniquen amb el repositori per accedir i actualitzar les dades
El Repositori s un medi d'emmagatzemament passiu
Repositori
(dades compartides)
Client6
Client2
Client3
Client4 Client5
Client1
20 20
Centrat en dades: Pissarra
Les dades compartides per diferents clients estan en un mateix lloc
Els clients es comuniquen amb la pissarra per accedir i actualitzar les dades i
la pissarra notifica als clients quan hi ha hagut canvis en les dades que els hi
interessen
La pissarra s un medi d'emmagatzemament actiu
Pissarra
(dades compartides)
Client6
Client2
Client3
Client4 Client5
Client1
Flux de dades: Batch seqencial
validar classificar actualitzar llistar
cinta
llistats
cinta cinta cinta
cinta
Descomposici del sistema en una seqncia de programes independents
Un programa no pot comenar la seva execuci fins que els precedents han
finalitzat completament
Les dades es transmeten entre components en la seva totalitat
Facilita canviabilitat i reusabilitat
Orientat a sistemes que sexecutaran de forma diferida (Batch)
21 21
Tubs i filtres
Procs1
Procs2
Procs4
Procs3
Procs6
Procs5
Descomposici del sistema en una seqncia de processos que realitzen
modificacions incrementals de les dades
Un procs pot comenar la seva execuci en el moment que rebi alguna dada
dentrada
Els tubs (processos) no tenen informaci destat
Facilita canviabilitat i reusabilitat
Estil arquitectnic tpic dels sistemes operatius UNIX
Model-Vista-Controlador
Model
dades
afegir(o:Observador)
treure(o:Observador)
notificar()
obtenirDades()
servei()
Vista
inicialitzar(m:Model)
ferControlador()
mostrar()
actualitzar()
Controlador
inicialitzar(m:Model, v:Vista)
tractarEsdeveniment()
actualitzar()
Observador
actualitzar()
*
1
1 1
T
Amb
Descomposici del sistema software en:
- Model: encarregat de la implementaci de les funcionalitats i dades del sistema
- La interfcie amb lusuari amb:
. Vista: encarregada de gestionar com es mostra la informaci a lusuari
. Controlador: encarregat de gestionar la interacci amb lusuari
Facilita canviabilitat i portabilitat
22 22
Heterogentat destils arquitectnics
Sovint, els sistemes combinen dos o ms estils:
sanomenen sistemes heterogenis.
Hi ha tres menes dheterogenetat:
Locacional
. Diferents parts del sistema poden estar fetes en estils diferents
. Ex.: Algunes de les branques dun sistema que segueix el patr programa
principal i subrutina comparteixen una pissarra i altres branques no.
Jerrquica
. La descomposici dun component dun estil es pot fer en un altre estil
. Ex.: descomposici en capes i orientaci a objectes dins cada capa
Simultnia
. Un mateix sistema es pot interpretar alternativament per ms dun estil
. Ex.: Un mateix sistema es pot veure estructurat seguint el patr tub-filtres
(on cada procs espera una dada a lentrada per processar) o vist com n
subsistemes independents amb un ordre dexecuci predeterminat.
Catleg parcial de patrons de disseny
Creaci:
Patrons de disseny relatius a com es creen classes i objectes
Estructurals:
Patrons de disseny relatius a com diferents classes i objectes es poden
combinar per definir estructures ms grans
Comportament:
Patrons de disseny relatius a com les classes i objectes interaccionen i
com sels hi han dassignar responsabilitats
. Assignaci de responsabilitats (Controlador, Expert, Creador)
. Iterador
. Estat
. Mtode Plantilla
. Observador
23 23
Patrons que considerarem
Patrons Arquitectnics:
- Patr Arquitectnic en 3 Capes (Presentaci, Domini i Gesti de Dades)
- Patr Orientaci a Objectes (dins de cada capa)
- Patr Model-Vista-Controlador (en la Capa de Presentaci)
Patrons de Disseny:
- Iterador
- Controlador
- Expert
- Creador
- Estat
- Mtode Plantilla
Bibliografia
Software Archi tecture in Practice
L. Bass; P. Clements; R. Kazman
Addison-Wesley, 1998, Cap. 5.
Software Archi tecture
M. Shaw; D. Garlan
Prentice Hall, 1996, Cap. 2.
John Wiley & Sons, 1996, Cap. 5 i 2
Design Patterns. Elements of Reusable Object-Oriented Software
E. Gamma, R. Helm, R. Johnson, J. Vlissides
Addison-Wesley, 1995, Cap.1
24 24
Introducci: Patr Arquitectnic en Capes 1
Patr arquitectnic: Arquitectura en capes
Context
Problema
Soluci:
Estructura
Comportament
Consideracions en la definici de larquitectura
Beneficis i inconvenients
Variants
Bibliografia
Context
Un sistema gran que requereix sser descomposat en grups de subtasques
(components), tals que cada grup de subtasques est a un nivell determinat
dabstracci.
25 25
Problema
Cal dissenyar un sistema amb la caracterstica dominant dincloure aspectes dalt i baix
nivell, on les tasques dalt nivell es basen en les de baix nivell.
El sistema requereix tamb una estructuraci horitzontal, ortogonal a la vertical: tasques
del mateix nivell dabstracci independents entre elles
Lespecificaci descriu les tasques a alt nivell, aix com la plataforma.
Es desitja portabilitat a daltres plataformes.
Les tasques dalt nivell no es poden implementar utilitzant directament els serveis de la
plataforma, a causa de la seva complexitat. Calen serveis intermediaris.
Problema: forces a equilibrar
Canvis en el codi no haurien de propagar-se en tot el sistema (Mantenible)
Les interfcies dels components haurien de ser estables i clarament definides
Els components shaurien de poder reemplaar per implementacions
alternatives (Separaci dinterfcie i implementaci)
En el futur, pot ser necessari construir altres sistemes, amb els mateixos
aspectes de baix nivell que aquest (Reusabilitat)
Responsabilitats semblants shaurien dagrupar per ajudar a la
comprensibilitat i mantenibilitat (Cohesi)
No hi ha una granularitat estndard de components
Els components complexos necessiten una descomposici addicional
26 26
Soluci
Estructurar el sistema en un nombre apropiat de capes.
Col.locar les capes verticalment.
Tots els components duna mateixa capa han de treballar al mateix nivell
dabstracci.
Els serveis que proporciona la capa j utilitzen serveis proporcionats per la
capa j - 1. Alhora, els serveis de la capa j poden dependre daltres serveis en
la mateixa capa.
Lesquema ms tpic de comunicaci consisteix en peticions de dalt a baix, i
respostes a les peticions en la direcci oposada.
Soluci: Estructura
usa
Nivell ms alt dabstracci
Nivell ms baix d abstracci
Client Capa N
Capa N - 1
Capa 1
Dispositius Fsics
Sistema Software
27 27
Exemple: Arquitectura 3 capes
Capa 3 Comp. 3-1 Comp. 3-2 Comp. 3-p
Capa 2 Comp. 2-1 Comp. 2-2 Comp. 2-n
Capa 1 Comp. 1-1 Comp. 1-2 Comp. 1-m
Soluci: Comportament
(Comunicaci de dalt a baix)
Un usuari realitza una petici duna tasca a la capa superior
Capa 3 Capa 2 Capa 1
tasca
resultat
petici
28 28
(Comunicaci de baix a dalt)
Capa 3 Capa 2 Capa 1
notificaci
esdeveniment
Un dispositiu fsic detecta locurrncia dun esdeveniment a la cap inferior
(Comunicaci bi-direccional)
Protocol de comunicaci TCP/IP
FTP
TCP
IP
Ethernet
FTP
TCP
IP
Ethernet
Protocol FTP
Protocol TCP
Protocol IP
Protocol Ethernet
Connexi fsica
petici
resposta
29 29
Consideracions a la definici de larquitectura (I)
1. Definir el criteri dabstracci per agrupar tasques en capes.
2. Determinar el nombre de nivells dabstracci (capes):
Una capa per nivell dabstracci.
Dos o ms nivells en una capa.
Un nivell en dues o ms capes.
3. Anomenar les capes i assignar tasques a cada una delles:
La capa superior correspon a la tasca del sistema.
Les altres capes donen suport a les capes superiors.
4. Especificar els serveis:
Cap component pot estar repartit en dues o ms capes.
Pocs serveis en les capes inferiors.
5. Refinar larquitectura en capes.
Consideracions a la definici de larquitectura (II)
6. Especificar una interfcie per cada capa. La capa j pot sser:
Una caixa negra per a la j+1
Una caixa blanca (el seu contingut es visible per la capa j+1)
7. Estructurar les capes individualment
8. Especificar la comunicaci entre capes adjacents:
Model empenta: la informaci es comunica en la petici del servei
Model estirada: el servei demanat estira la informaci de la capa superior
9. Desacoblar capes adjacents:
Comunicaci descendent: Canvis en capa j poden ignorar presncia capa j+1.
Comunicaci ascendent: Capa j coneix quin servei especfic demanar de la capa j+1 per
notificar un esdeveniment rebut (Retrocrides)
10. Dissenyar una estratgia de tractament derrors.
Tractar errors en la capa on es detecten
Tractar errors en les capes superiors
30 30
Beneficis i inconvenients
Beneficis:
Reutilitzaci de les capes en altres contexts (interfcie i abstracci ben
definides)
Suport a lestandaritzaci (nivells dabstracci comunment acceptats)
Totes les dependncies sn locals (canvis locals)
Portabilitat
Facilitat de prova
Canviabilitat
Inconvenients:
Menor eficincia
Feina innecessria o redundant
Dificultat en establir la granularitat i nombre de capes
Variants
Arquitectura en capes relaxat
Una capa pot usar els serveis de totes les capes que estan per sota della
Una capa pot sser parcialment opaca
Conseqncies
Possible guany en flexibilitat i eficincia
Possible prdua en la canviabilitat
31 31
Bibliografia
John Wiley & Sons, 1996. Pgines 31-51
32 32
Introducci: Arquitectura lgica i fsica dels sistemes dinformaci 1
Arquitectura lgica i fsica de sistemes dinformaci
Funcions dun sistema dinformaci.
Arquitectura lgica dun sistema dinformaci.
Arquitectura fsica no distribuda:
Una capa.
Dues capes.
Tres capes.
Bibliografia
Funcions dun sistema dinformaci
Passiva:
Mantenir una representaci consistent de lestat del domini:
. Capturar els esdeveniments que ocorren al domini
. Actualitzar lestat del sistema dinformaci com a conseqncia daquests
esdeveniments
. Assegurar la consistncia de la representaci
Activa:
Respondre a consultes sobre lestat del domini.
Produir reaccions quan es donen certes condicions predefinides.
Sistema
Informaci
Domini
activa
passiva
33 33
Arquitectura lgica dun sistema dinformaci:
Context
operacions
entrada/
sortida
esdeveniments
presentaci:
men seleccionat
bot premut
mostrar finestra
imprimir lnia
...
Sistema
dInformaci
......
......
Visi general
Aplicaci del patr Arquitectura en 3 Capes a un Sistema dInformaci
Sistema
dInformaci
......
......
Sistemes gesti bases de dades/fitxers
Capa Presentaci
Capa del Domini
Capa de Gesti de dades
Responsable de la interacci
amb lusuari
Responsable de la interacci
amb el SGBD/F
Responsable de la implementaci
de les funcionalitats del sistema
34 34
Capa de Presentaci
......
Domini
Presentaci
Sassabenta peticions usuaris
Ordena execuci accions
Comunica resultats accions
als usuaris
Tractament de:
Finestres
Dilegs, Mens
Botons
Llistats
esdeveniments
presentaci
esdeveniments externs
consultes
respostes
resultats
La Capa del Presentaci coneix com presentar les dades a lusuari, per ignora
quines transformacions cal fer per donar resposta a les peticions de lusuari
Capa del Domini
La Capa del Domini coneix com satisfer les peticions de lusuari, per ignora on es
guarden les dades i com es presenten a lusuari
Sassabenta esdeveniments
En controla la validesa
Canvia lestat del domini
Executa accions encomanades
Sassabenta consultes
Obt els resultats
Comunica respostes
Gesti de dades
Domini
Presentaci
consultes
operacions de consulta i
modificaci a les dades
respostes
resultats
resultats
respostes
35 35
Arquitectura lgica dun sistema d'informaci:
Capa Gesti de Dades
La capa del Gesti de Dades coneix on i com estan emmagatzemades les dades, per
desconeix com tractar-les
Gesti de
Dades
Domini
Sistemes de gesti bases de dades/fitxers
modificaci en el llenguatge de
les bases de dades i fitxers
Permet que el domini pugui ignorar on sn les dades.
Les funcions concretes daquesta capa depenen del
sistema de gesti de dades que susi.
modificaci de les dades
resultats
respostes
resultats
respostes
Els sistemes de gesti de bases de dades/fitxers
......
...... Esque. SGBDi SGFj
Gesti de dades
Sencarrega de mantenir una
representaci persistent i concreta
de lestat del domini
modificaci en el llenguatge de
les bases de dades i fitxers
select ... from ... where ...
find ....
delete record
....
resultats
respostes
36 36
Capa Gesti de Dades:
Exemple en arquitectura basada en transaccions/bases de dades
Acceptar
rebut
nou rebut
error
REBUTS
CLIENTS
Verifi car
rebut
Afegir
rebut
CLIENTS REBUTS
nou rebut (correcte)
nou rebut
error
Procs de dades discret Verificar rebut
Estmul: Flux de dades nou rebut
* El flux nou rebut ja est accessible
if client does not exist
error := No conec el client
issue (error) * operaci estndard YSM
else if rebut exists
error := Aquest rebut ja existeix
issue (error)
else
issue (nou rebut (correcte))
end
Procs de dades discret Afegir rebut
Estmul: nou rebut (correcte)
* Tenim nou rebut disponible
create REBUT with:
codi rebut := nou rebut.codi rebut
import := nou rebut.import
data := todays date ()
* todays date() s una operaci estndard del YSM
end;
* tenim REBUT lligat per la creaci anterior i
* CLIENT lligat pel flux dentrada
create REBUT del CLIENT;
end.
Rebut Client del
Capa Gesti de Dades:
Exemple en arquitectura basada en transaccions/bases de dades
ExisteixClient?(Client) ExisteixRebut?(codiRebut) creaRebut (codiRebut,Import,Client)
select client from Clients
where...
select codiRebut from Rebuts
where...
insert into Rebuts...
TAULES:
Clients(client,...)
Rebuts(codi,import,client, data)
Domini
Gesti de dades
Sistema gesti base de dades
Presentaci
Transforma operacions
conceptuals en operacions
fsiques
error nouRebut (CodiRebut,Import,Client)
37 37
Arquitectura fsica no distribuida: Una capa
Sistema
dInformaci
......
......
Presentaci /
Domini /
Gesti de Dades
En el codi estan barrejades
les tres funcions
Propietats de larquitectura:
Poc canviable
Poc reusable
Poc portable
Arquitectura fsica no distribuda: Dues capes (I)
Interfcie:
- portable, reusable i canviable
(canvis a la interfcie sn locals)
Implementaci de funcionalitats:
- Poc portable, canviable i reusable
(molta dependncia del SGBD, el format i
localitzaci de les dades)
Sistema
dInformaci
......
......
Presentaci
Domini/Gesti de dades
38 38
Arquitectura fsica no distribuda: Dues capes (II)
Sistema
dInformaci
......
......
Presentaci/Domini
Gesti de dades
Implementaci de funcionalitats:
- Poc portable, canviable i reusable
(molta dependncia de la interfcie, del GUI i
el disseny de pantalles)
Accs a les dades:
- portable, reusable i canviable
(canvis en format, localitzaci i SGBD sn
locals)
Arquitectura fsica no distribuda: Tres capes
Sistema
dInformaci
......
......
Presentaci
Domini
Gesti de dades
Tots els canvis sn locals
canviable
reusable
portable
39 39
Bibliografa
Analysis Patterns
Martin Fowler
Addison-Wesley, 1997, cap. 12.
40 40
Disseny orientat a objectes en UML 1
Disseny orientat a objectes en UML
Introducci al disseny orientat a objectes en UML
Conceptes dUML per al disseny
Disseny de la Capa de Domini
Especificaci dun exemple: gesti dun club de tennis
Normalitzaci de lesquema conceptual despecificaci
Aplicaci de patrons de disseny
Exemple de disseny de la capa de domini
Disseny de la Capa de Presentaci
Disseny de la Capa de Gesti de Dades
41 41
42 42
Introducci al disseny orientat a objectes en UML 1
Introducci al disseny orientat a objectes en UML
Determinaci de larquitectura del software
Especificaci versus disseny
Visi dun sistema software en UML
Punt de partida: especificaci en UML
Resultat a obtenir: disseny en UML
Bibliografia
Anlisi de Requeriments Quin sistema cal construir?
Especificaci Qu ha de fer el sistema?
Disseny Com ho fa el sistema?
Implementaci
Independent de
la tecnologia
Dependent de
la tecnologia
Especificaci del sistema software
Arquitectura del sistema software
43 43
Determinaci de larquitectura del software
Dependncia tecnolgica:
Propietats que es volen assolir (requeriments no funcionals)
Recursos tecnolgics disponibles
famlia de llenguatges de programaci
famlia de sistema gestor de bases de dades
etc.
Larquitectura del sistema software i els patrons
(arquitectnics) que susaran per fer el disseny del sistema
determina
Determinaci de larquitectura del software - ES:D1
El disseny que explicarem es basa en els supsits segents:
Propietats que es volen assolir: canviabilitat i portabilitat
Recursos tecnolgics disponibles
llenguatge de programaci orientat a objectes
base de dades orientada a objectes
- Arquitectura en tres capes
- Orientaci a objectes dins de cada capa
44 44
Especificaci versus disseny
En UML:
Es fan servir els mateixos models al disseny que a lespecificaci
La visi (enfocament) dels models s molt diferent a ambdues etapes:
Especificaci: els models defineixen els conceptes del mn real.
(domini del probl ema)
Disseny: els models defineixen els conceptes que es desenvoluparan
per proporcionar una soluci a les necessitats del mn real.
(domini de l a soluci)
Del domini del problema al de la soluci (I)
Lespecificaci no t en compte les propietats a assolir ni la tecnologia
que susar per implementar el sistema software.
Durant el disseny, es poden haver de canviar els models despecificaci
per tal dassolir determinades propietats.
Exemple: propi etat a assolir -> eficincia
Esquema conceptual despecificaci:
- Problema: operaci visita-provs costosa perqu hi ha molts recorreguts
- Soluci: afegir una associaci derivada /visita entre persona i ciutat
- Malauradament, aquesta associaci podia no ser rellevant al domini del problema
Empresa
nom
Ciutat
nom
nm-hab
Treb-a T-prov-a *
*
*
Persona
nom
visita-provs(): ll-ciutats
*
ll-ciutats = {nom-c}
45 45
Del domini del problema al de la soluci (II)
Possibles coses a fer, des del punt de vista del domini de la soluci:
afegir informaci derivada (atributs i/o associacions)
simplificar jerarquies de generalitzaci / especialitzaci (eliminar subclasses)
afegir classes dobjectes redundants
considerar classes abstractes
etc.
Aquest pas est poc formalitzat i poc explicat a la literatura actual.
Les transformacions a aplicar depenen de molts factors externs: freqncia
dinvocaci de les operacions, cost dexecuci, poblaci de les classes, etc.
Per tant, lestudi daquestes transformacions queda fora de labast
daquesta documentaci.
Visi dun sistema software en UML
Especificaci Disseny
sistema software
sistema software
Especificaci: el sistema software es veu com una sola classe dobjectes que
engloba tota la informaci i totes les operacions.
Disseny: cada classe dobjectes t les seves prpies operacions de manipulaci
dinformaci. Els objectes interactuen per satisfer les operacions del
sistema.
46 46
Punt de partida: especificaci en UML
Especificaci: QU fa el sistema software?
Resultat de lespecificaci en UML:
Model de Casos ds:
Quina interacci hi ha entre els actors i el sistema software?
Esquema Conceptual:
Quins sn els conceptes rellevants del mn real de referncia ?
Diagrames de seqncia del sistema:
Quina resposta dna el sistema als esdeveniments externs? (quines
operacions ha de tenir el sistema?)
Contractes de les operacions:
Qu fan les operacions del sistema?
Resultat a assolir: disseny en UML
Disseny: COM estructurem el sistema perqu faci el que ha de fer?
el disseny s una acti vitat iterati va i s difcil seqencialitzar tot el que shi fa.
Resultat del disseny en UML:
Model de Casos ds:
Defineix la interacci real, amb una interfcie concreta.
Diagrama de classes de disseny:
Descriu les classes del software i les seves interfcies (operacions).
Diagrames de seqncia:
Defineixen la interacci entre les classes dobjectes per respondre un
esdeveniment extern.
Contractes de les operacions:
Defineixen qu fan les operacions de les classes dobjectes.
47 47
Bibliografia
Applying UML and Patterns
An Introduction to Object-Oriented Analysis and Design
C. Larman
Prentice-Hall 1998
Object-Oriented Modeling and Design
J.Rumbaugh, M.Blaha, W.Premerlani, F.Eddy, W.Lorensen
Prentice-Hall, 1991
Enginyeri a del software: Especificaci
D.Costal, M.R.Sancho, E.Teniente
Edicions UPC, 1999
48 48
Conceptes dUML per al disseny 1
Conceptes dUML per al disseny
Objecte i Classe dobjectes
Atribut
Associaci
Operaci, Mtode i Contracte
Agregaci i Composici
Generalitzaci i Herncia
Polimorfisme
Diagrames dinteracci
Diagrames de seqncia
Invocaci doperacions en jerarquies
Bibliografia
Objecte i classe dobjectes
Objecte:
s una manifestaci concreta duna abstracci
s una instncia duna classe, que encapsula estat i comportament
t una identitat prpia
el fa distingible daltres objectes
la seva existncia s independent dels valors de les seves propietats
Classe dobjectes:
descriu un conjunt dobjectes que comparteixen atributs, associacions,
operacions i mtodes.
representa un concepte dins el sistema que sest modelitzant:
un concepte del mn real (a lespecificaci)
un concepte software equipat amb una implementaci (a disseny)
49 49
Atribut, associaci, operaci i mtode
Atribut: propietat compartida pels objectes duna classe
Associaci: representa relacions entre dos o ms objectes
Operaci:
transformaci o consulta que poden executar els objectes duna classe
t una signatura (nom i parmetres de loperaci) i s invocada per altres
objectes
Mtode: implementaci concreta duna operaci dins duna classe
Persona
dni: String
nom: String
adrea: String
telfon: Integer
canvi-adrea(a:String): Boolean
telfon?(): Integer
afegir-idioma(nom:String)
Idioma
nom: String
/nm-parl.: Integer
nou-parlant(dni:String)
Parla 1..*
*
Atributs: sintaxi completa
[visibilitat] nom [multiplicitat] [:tipus] [=valor-inicial] [{propietats}]
changeable
addOnly
frozen
Public (+): qualsevol classe que pot veure la classe, veu latribut
Protected (#): noms la prpia classe i els seus descendents veuen latribut
Private (-): noms la prpia classe veu latribut
Univaluat (per defecte)
Multivaluat: [1..*]
Admet valors nuls: [0..1]
etc.
Persona
+ dni: String
# nom: String
- adrea: String = C/Nou
- telfon [0..1]: Integer
Suposarem que els atributs sn privats,
a no ser que especifiquem una altra
visibilitat
50 50
Atributs: mbit
Atribut dinstncia:
representa una propietat aplicable a tots els objectes duna classe
cada objecte pot tenir un valor diferent daquest atribut
Atribut de classe:
propietat aplicable a la classe dobjectes com a tal
tots els objectes duna classe comparteixen el valor daquest atribut
Persona
dni: String
nom: String
adrea: String
edat: Integer
edat-promig: Real atribut de classe
Associacions: sintaxi
Persona Idioma
1..*
*
#parlants +idiomes
Persona a Idioma
Idioma a Persona
Persona a Idioma
Navegabilitat
{propietats}
changeable
addOnly
frozen
Navegabilitat:
indica si s possible o no travessar una associaci binria duna classe a una altra
si hi ha navegabilitat, lassociaci defineix un pseudoatribut (que correspon al rol
daquell sentit de navegaci) de la classe a partir de la qual es pot navegar
suposarem que les associacions sn privades, a no ser que sindiqui el contrari
visibilitat: public, protected, private
Persona
Parla
Idioma
1..*
* Parla
+idiomes
51 51
Associacions: qualificador
Ciutat
Hotel
0..1
1
nom-h
qualificador
objecte
qualificat
Qualificador:
permet seleccionar un conjunt dobjectes relacionats amb un objecte qualificat
mitjanant una associaci.
un objecte, conjuntament amb el valor del qualificador, determina un nic objecte
(de vegades un conjunt dobjectes) de laltre extrem de lassociaci.
s un ndex en el recorregut de lassociaci
Ciutat
nom-c: String
Associaci no qualificada:
Hotel
nom-h: String
T * 1
R.I. textuals:
- no hi pot haver dues ciutats amb idntic nom-c
- una ciutat no pot tenir dos hotels amb nom-h
Associaci qualificada:
(ciutat, nom-h) 0 o 1 hotel
T
Associacions: ordenaci
s una propietat dun conjunt dobjectes
relacionats amb un altre objecte mitjanant
una associaci, que indica si el conjunt est
o no ordenat (per posici).
Banc
Prstec Compte
1 1
* *
{ordered} {unordered}
52 52
Agregaci i Composici
Mail
Adrea Text
1 1
* *
Lagregaci s una associaci que
relaciona el tot i les parts.
Les parts poden pertanyer a ms
dun agregat.
A nivell dobjectes, no hi pot haver
cicles en els camins dagregaci.
Cotxe
Xasss
1
1
Motor
1
La composici s una agregaci amb
una pertinena ms forta entre el tot i
les parts: si sesborra el tot, tamb
cal esborrar les parts.
En un moment determinat, les parts
pertanyen com a mxim a una
composici.
Roda
0..5
...
Operacions: sintaxi completa
[visibilitat] nom [(llista-parmetres)] [:tipus-retorn] [{propietats}]
isQuery
sequential
guarded
concurrent
Public (+): loperaci pot ser invocada des de qualsevol objecte
Protected (#): pot ser invocada pels objectes de la classe i els seus descendents
Private (-): noms els objectes de la prpia classe poden invocar loperaci
Signatura duna operaci:
[direcci] nom : tipus [=valor-per-defecte]
Parmetres duna operaci:
in, out, inout
Suposarem que les operacions sn
pbl iques, si no sindica el contrari
53 53
Operacions: mbit
Operaci dinstncia:
loperaci s invocada sobre objectes individuals
Operaci de classe:
loperaci saplica a la classe prpiament dita
Exemple: operaci constructora, que serveix per donar dalta
noves instncies duna classe.
Alumne
nom: String
edat: Integer
nom?(): Integer
nova-assig (nom-a:String): Boolean
alumne (nom: String, edat:Integer)
promig-edat(): Real
Operaci constructora:
Suposarem que, si no sindica el contrari,
cada classe dobjectes t una operaci
constructora amb tants parmetres com
atributs t la classe.
Si es consideren altres constructores,
caldr definir-ne la seva signatura.
Operacions: contractes
Contracte: descriu lefecte duna operaci en base a
canvis destat de la base dinformaci
sortides que el sistema proporciona
Els contractes garanteixen la fiabilitat del software mitjanant:
precondicions: condicions que estan garantides quan es crida loperaci
postcondicions: condicions que loperaci ha de garantir
Tota operaci t un contracte
Sistema
alta-persona (dni: String, nom: String): Boolean
alta-idioma (nom: String) Boolean
parla-idioma (dni: String, nom-i: String): Boolean
Per cada operaci
es defineix
un contracte
54 54
Contractes: exemple
Operaci: parla-idioma (dni: String, nom-id: String)
Classe retorn: Boole
Semntica: Enregistrar que la persona dni parla lidioma nom-id
Precondicions: Els parmetres tenen valor
Postcondicions:
1. Si la persona amb dni no existeix, o lidioma nom-id no existeix o la persona
ja parla aquest idioma, aleshores operaci invlida i es retorna fals.
2. En cas contrari, operaci vlida, es retorna cert i:
2.1 - Es crea una nova instncia de lassociaci Parla entre la Persona i
lIdioma.
Persona
dni: String
nom: String
Idioma
nom: String
Parla 1..*
*
R.I. textuals:
- Claus de les classes no associatives: (Persona, dni); (Idioma,nom)
Generalitzaci / Especialitzaci
Generalitzaci:
relaci taxonmica entre una classe ms general (superclasse) i una altra
ms especfica (subclasse)
la superclasse descriu les caracterstiques comunes a totes les subclasses
cada subclasse descriu un conjunt especfic de caracterstiques
Pagament
quantitat: Integer
Pagament
en metl.lic
Pagament
a crdit
codiTarja: String
Pagament
amb tal
nmTal: Integer
forma_pagament {disjoint,complete}
G
E
discriminador
restricci
classe abstracta
Classe abstracta:
classe que no pot ser instanciada directament (no t objectes propis).
55 55
Herncia
superclasse
subclasses
subclasses,
superclasse
Herncia:
en una generalitzaci, les subclasses incorporen (hereten) lestructura i el
comportament definits a la superclasse.
Professor
plus-lloc: Integer
plus?(): Integer
Prof. Titular
antiguitat: Integer
contractar()
Prof. Associat
perodeCont: Integer
renovar(n:Integer)
Administratiu
nm-h-extres: Integer
def-h-ext(Integer)
{disjoint, incomplete} contracte
{disjoint, complete} tipus
EmpleatUniversitari
nom: String
sou: Integer
nom?(): String
assigSou(Integer)
Polimorfisme
Professor
plus-lloc: Integer
pagarSou(): Integer
Prof. Titular
antiguitat: Integer
pagarSou(): Integer
Prof. Associat
perodeCont: Integer
renovar(n:Integer)
Administratiu
pagarSou(): Integer
Operaci polimrfica:
operaci que saplica a diverses classes duna jerarquia tal que la seva
semntica depn de la subclasse concreta on saplica
{disjoint, incomplete} contracte
EmpleatUniversitari
nom: String
sou: Integer
nom?(): String
pagarSou():Integer
operaci abstracta: no t mtode
associat a la classe on est declarada
operaci concreta: t mtode
associat a la mateixa classe
loperaci es defineix de forma
diferent => mtode diferent
56 56
Herncia mltiple
Una classe pot ser subclasse directa dun nombre arbritari de superclasses
Una classe pot heretar atributs i operacions de diverses classes.
Es produeix un conflicte si una mateixa caracterstica apareix a diverses
superclasses.
. . .
. . .
Docent
assignatura: String
escola: String
donarClasse()
corregir()
Investigador
categoria: String
escola: String
publicar(a: article)
donarClasse()
Professor-Universitat
Diagrames dinteracci
Objectiu: Mostrar les interaccions entre objectes:
Quan es produeix un esdeveniment extern.
Quan sinvoca una operaci dun objecte.
En un cas ds.
Etc.
Dos tipus de diagrama dinteracci (semnticament equivalents):
Diagrames de seqncia.
Diagrames de col.laboraci.
57 57
Diagrames de seqncia
Notaci:
:Client instncia (objecte)
Client classe dobjectes
invocaci de loperaci op3
amb retorn de control
c:Client instncia amb nom
op3(c,d)
:Client p:Producte
:Transacci
op1(a,b)
resultat
op2(a,c)
op3(c,d)
Focus de control
Existncia dobjecte
temps
Destrucci d objecte
Creaci dobj ecte
op4(b)
Autoinvocaci doperaci
oper(a)
result
Invocaci doperacions en jerarquies (I)
Professor
plus-lloc: Integer
s-base-alt?():Boolean
pagarSou(): Integer
Administratiu
preu-h-extra: Integer
pagarSou(): Integer
{disjoint, complete}
tipus
EmpleatUniversitari
nom: String
sou-base: Integer
nom?(): String
sou-base?(): Integer
pagarSou():Integer
sou-base? (invocada a Professor)
:Professor
boolean
s-base-alt?
sou-base?
sou-b
s-base-alt? (a Professor)
:Professor
string
sou-base?
retorna cert si sou-b
ms alt que K
58 58
Invocaci doperacions en jerarquies (II)
pagarSou (invocada a EmpleatUniv.)
:EmpleatUniv
enter
pagarSou
:Professor
enter
pagarSou
sou-base?
retorna sou-b
+ plus-lloc
sou-b
:Administratiu
enter
pagarSou
retorna sou-b
+ (nm-h x preu-h)
Professor
plus-lloc: Integer
s-base-alt?():Boolean
pagarSou(): Integer
Administratiu
preu-h: Integer
nm-h: Integer
pagarSou(): Integer
EmpleatUniversitari
nom: String
sou-base: Integer
nom?(): String
sou-base?(): Integer
pagarSou():Integer
Bibliografia
The Unified Modeling Language Reference Manual
J.Rumbaugh, I.Jacobson, G.Booch
Addison-Wesley 1999
An Introduction to Object-Oriented Analysis and Design
C. Larman
Prentice-Hall 1998
Construccin de Software Orientado a Objetos
B.Meyer
Prentice-Hall, 2a Ed., 1998
G.Booch , J.Rumbaugh, I.Jacobson
Addison-Wesley 1999
59 59
Disseny de la Capa de Domini 1
Disseny de la Capa de Domini
Normalitzaci de lesquema conceptual despecificaci
Aplicaci de patrons de disseny
Iterador
Controlador
Expert
Creador
Estat
Plantilla
Exemple de disseny de la Capa de Domini
De moment, prescindirem del que
fan la capa de Presentaci i la
capa de Gesti de Dades
Suposem que tot ho fa
la Capa de Domini
61 61
Disseny de la Capa de Domini: Especificaci dun exemple 1
Model de Casos ds
Esquema Conceptual
Diagrames de seqncia del sistema
Contractes de les operacions del sistema
Diagrama Casos ds: context del sistema
Gesti pistes
Afegir pistes
Preveure manteniment
Obtenir ocupaci pistes
s pista
Administraci
Admetre soci
Canvi compte corrent
Alta familiar
Baixa soci
Baixa familiar
Reserves
Fer reserva
Anul.lar reserva
Consultar reserves
Veure reserves no usades
Facturaci
Fer rebuts
Pagar rebuts
Fer crrecs de reserves
Carregar servei a soci
Total deute
Obtenir rebuts no pagats
Canviar parmetres club
Administrador
Facturaci
Persona
Encarregat
pistes
63 63
Diagrama de Casos ds: package Administraci
Administraci
Administrador
Admetre soci
Canvi compte corrent
Alta Familiar
Baixa familiar
Baixa Soci
Soci
Familiar
Descripci casos ds: Admetre soci
Cas ds: Admetre soci
Actors: Soci (iniciador), Administrador
Propsit: Donar dalta un nou soci i alguns familiars seus
Curs tpic desdeveniments
Accions dels Actors
1. El cas ds comena quan una persona
es vol donar dalta com a soci.
2. Ladministrador indica el dni, el nom,
ladrea, le-mail i el nmero de compte
corrent de la persona
4. Per cada familiar, ladministrador
introdueix les seves dades (dni, nom,
adrea i e-mail)
Resposta del sistema
3. Comprova que les dades sn correctes,
dna dalta el soci i enregistra que paga
per aquell nmero de compte corrent
4. Comprova que les dades sn correctes,
dna dalta el familiar i enregistra que
s familiar daquell soci
64 64
Esquema conceptual despecificaci (I)
Pista
nm: Integer
Rebut
mesEmissi: Mes
pagat: Bool = false
/import: Import
Club
ltNmSoci: Integer=0
preuHoraPista: Import
preuNos:Import
preuAnul.laci: Import
CompteCorrent
nm-cc: Integer
saldo: Import=0
Familiar
Reserva
dataReserva: Data
Persona
dni: String
nom: String
adrea: String
e-mail [0..1] : String
Interval
data: Data
inici: Hora
Soci
nmSoci: Integer
/deute:Import
Crrec
data: Data
import: Import
desc.: String
Es-reserva
reservant
0..1
*
Es-mant-en
*
*
*
*
*
*
1
1 1
1
0..1
0..1
*
/Correspon
Prevista
Usada
NoUsada
AnMant
data: Data
AnClient
data: Data
Amb
tipus
T
Del
*
A 1
estat
s-pagada
1
Esquema conceptual despecificaci (II)
Supsit:
Tots els intervals tenen una durada duna hora
Restriccions dintegritat textuals:
Claus classes no associatives: (Pista, nm); (Interval, data + inici); (Persona,
dni); (CompteCorrent, nm-cc).
No hi poden haver dos socis amb el mateix nmSoci
Tots els crrecs dun rebut tenen una data dins de mesEmissi
Tots els crrecs dun mateix rebut sn del mateix soci
No hi pot haver ms dun rebut amb els mateixos nmSoci i mesEmissi
Informaci derivada:
El deute dun soci s la suma dels imports dels seus rebuts no pagats
Limport dun rebut s la suma dels imports dels crrecs de que es composa
Lassociaci correspon entre Soci i Rebut relaciona un soci amb els seus rebuts.
65 65
Diagrama de seqncia del sistema: Admetre soci
:Sistema
:Administrador
altaSoci (dni, nom, adrea, e-mail, nm-cc, out nmSoci)
: Boolean
altaFamiliar(nmSoci, dni, nom, adrea, e-mail)
: Boolean
*
Contractes de les operacions del sistema
Operaci: altaSoci (dni: String, nom: String, adrea: String, e-mail: String, nm-cc:
Integer, out nmSoci: Integer)
Classe retorn: Boolean
Semntica: Donar dalta un nou soci i assignar-li el compte corrent.
Precondicions: Els parmetres tenen valor, excepte e-mail que pot ser nul.
Postcondicions: 1. Si no existeix un compte corrent amb nm-cc, aleshores operaci invlida i
es retorna fals.
2.1 - Es crea un objecte de la classe Soci (i de la classe persona)
2.2 - L'atribut numSoci s igual a l'atribut ltNmSoci+1 de club
2.3 - L'atribut ltNumSoci de club s'incrementa en una unitat
2.4 - Es crea una nova ocurrncia de lassociaci Del entre Soci i CompteCorrent
Operaci: altaFamiliar (nmSoci: Integer; dni: String, nom: String, adrea: String, e-mail: String)
Semntica: Donar dalta un familiar dun soci.
Postcondicions: 1. Si no existeix un Soci amb nmSoci, aleshores operaci invlida i es retorna fals.
2.1 - Es crea un objecte de Familiar (i de Persona)
2.2 - Es crea una ocurrncia de lassociaci entre el familiar i el soci amb nmSoci
66 66
Bibliografia
Enginyeri a del software: Especificaci
D.Costal, M.R.Sancho, E.Teniente
Edicions UPC, 1999
67 67
Disseny de la Capa de Domini: Normalitzaci 1
Normalitzaci de lesquema conceptual
Motivaci
Normalitzaci de lesquema conceptual
Tractament dassociacions n-ries i classes associatives
Tractament de la informaci derivada
Tractament de les restriccions dintegritat
Bibliografia
Motivaci
Al disseny hi tenim components software i no conceptes del domini
Limitaci tecnologia orientada a objectes: no permet implementar
directament tots els conceptes que hem usat a lespecificaci:
associacions n-ries, amb n > 2.
classes associatives
informaci derivada
control de les restriccions dintegritat
cal una transformaci prvia: procs de normalitzaci (binaritzaci)
- eliminar n-ries i associatives
- tractar la informaci derivada
- controlar les restriccions dintegritat
que impacta tant al diagrama de classes com als contractes.
69 69
Eliminaci dassociacions n-ries i classes associatives
Reserva
dataReserva: Data
Persona
dni: String
nom: String
adrea: String
Interval
data: Data
inici: Hora
Es-reserva
reservant
0..1
*
Es-mant-en
*
*
*
claus classes no associatives: (Pista, nm); (Interval, data + inici); (Persona, dni)
Esquema conceptual:
Pista
nm: Integer
Normalitzaci: pas a associacions binries
Pista
nm: Integer
Persona
dni: String
nom: String
adrea: String
Interval
data: Data
inici: Hora
1
*
Es-mant-en
1
1
*
claus classes no associatives: (Pista, nm); (Interval, data + inici); (Persona, dni)
(Afegida) No hi pot haver dues reserves amb els mateixos Pista, Interval i Persona
(Afegida) Donats una pista i un interval, com a mxim els pot tenir reservats una Persona
Diagrama de classes normalitzat:
el resultat obti ngut ha de tenir la
mateixa semntica que l esquema
conceptual de parti da
*
*
*
Reserva
dataReserva: Data
selimina perqu est inclosa a la tercera restricci textual
reservant
En
La
Per
70 70
Tractament de la informaci derivada
Els atributs i les associacions derivats es poden:
Calcular quan es necessiten.
Materi ali tzar
Si es calcula:
Desapareix (explcitament) la informaci derivada que es decideix calcular
Apareixen noves operacions per obtenir la informaci derivada que es
calcula
Si es materialitza:
Cal modificar els contractes de les operacions que provoquen canvis al
valor de la informaci que es materialitza
Selimina del diagrama de classes la indicaci que la informaci s derivada
En la decisi hi influeix el temps de clcul, la freqncia daccs i lespai
ocupat.
Tractament de la informaci derivada: exemple
Rebut
mes: Mes
pagat: Bool = fals
/import: Import
Soci
nm: Integer
/deute: Import
Crrec
data: Data
import: Import
desc.: String
*
*
1
1
/Correspon
T
*
A
0..1
Cal decidir si calculem o materialitzem la
informaci derivada.
Decidim:
- calcular l atribut deute de Soci
- materialitzar import de Rebut
- materialitzar lassociaci Correspon
Esquema conceptual:
71 71
Tractament de la informaci derivada: resultat
Dna la suma dels imports
dels rebuts no pagats
Associaci
materialitzada
Atribut
materialitzat
Cal modificar tamb els contractes
de les operacions:
- Fer rebuts
- Pagar rebuts
perqu modifiquin el valor de:
- import de Rebut
- associaci Correspon
Diagrama de classes resultant:
Rebut
mes: Mes
pagat: Bool = fals
import: Import
Soci
nm: Integer
deute?(): Import
Crrec
data: Data
import: Import
desc.: String
*
*
1
1
Correspon
T
*
A
0..1
Control de les restriccions dintegritat
Els models despecificaci sn no redundants entre ells
Quan dissenyem, cal garantir que el sistema software resultant
satisfaci les restriccions dintegritat (grfiques i textuals) de
lesquema conceptual.
cal modificar els contractes de les operacions perqu
controlin totes les restriccions dintegritat
com a conseqncia, les restriccions dintegritat
desapareixen de lesquema conceptual
En general, la capa de presentaci i la de gesti de dades tamb controlaran
algunes restriccions dintegritat
Per tant, aquest control no es far nicament des de la capa de domini
72 72
Control de les restriccions dintegritat: exemple
*
Empleat
codi: Integer
nom: String
data-ingrs: Date
Departament
nom: String
adrea: String
* 0..3 Sassigna
R.I. Textuals:
- Claus: (Empleat, codi); (Departament, nom)
- Data-ini dassignaci data-ingrs
- Un empleat no pot estar assignat alhora als departaments
de Vendes i de Control-Vendes
Assignaci
data-ini: Date
Operaci: novaAssig (codi: Enter, nom-d: String, data: Data)
Semntica: Assignar un empleat a un departament
Postcondicions: 1. Si no existeix lempleat, o no existeix el departament o lempleat ja est
assignat al departament aleshores operaci invlida i es retorna fals.
2.1 - Es dna dalta lassociaci entre lempleat i el departament.
Esquema conceptual:
Control de les rest. dintegritat: normalitzaci de lexemple
*
Empleat
codi: Integer
nom: String
data-ingrs: Date
Departament
nom: String
adrea: String
1 0..3 T
R.I. Textuals:
- Claus: (Empleat, codi); (Departament, nom)
- Data-ini dassignaci data-ingrs
- Un empleat no pot estar assignat alhora als departaments de Vendes i de Control-Vendes
- (Afegida) No hi pot haver dues assignacions amb els mateixos Empleat i Departament
Assignaci
data-ini: Date
1 * Al
73 73
Control de les restriccions dintegritat: resultat
*
assignat al departament aleshores operaci invlida i es retorna fals.
2.1 - Es dna dalta lassociaci entre lempleat i el departament.
assignat al departament, o data < data-ingrs, o l empleat ja est assignat a
tres departaments o lempleat estaria assignat a Vendes i a Control-Vendes,
aleshores operaci invlida i es retorna fals. (Modificada)
2.1 - Es crea un nou objecte Assignaci amb les corresponents associacions
amb Empleat i Departament. (Modificada)
Operaci normalitzada:
Bibliografia
G.Booch; J.Rumbaugh; I.Jacobson
Addison-Wesley, 1999.
Applying UML and Patterns.
An I ntroduction to Object-Oriented Analysis and Design
C.Larman
Prentice Hall, 1998.
74 74
Disseny de la Capa de Domini: Patr de disseny Iterador 1
Patr disseny Iterador
Descripci general.
Soluci: Estructura.
Exemple daplicaci en UML.
Iteradors en Java: Enumeration.
Exemple daplicaci en Java.
Diccionaris.
Exemple diteraci de diccionaris.
Bibliografia.
Descripci general
Context:
Necessitat de fer recorreguts seqencials dels elements dun objecte agregat
(col.lecci dobjectes).
Problema:
Es vol accedir als elements dun objecte agregat, sense exposar lestructura
interna.
Es vol poder tenir diverses travessies pendents del mateix objecte agregat.
Es vol poder travessar els elements dun objecte agregat de formes diferents.
No es vol inflar la classe de lobjecte agregat amb operacions per les
diverses travessies possibles.
Soluci:
Treure la responsabilitat de laccs i recorregut de lobjecte agregat i assignar
aquesta reponsabilitat a una nova classe dobjectes que anomenarem
Iterador.
LIterador proporcionar una interficie per accedir i recrrer els elements de
lobjecte agregat.
75 75
Soluci: Estructura
Cas dun nic recorregut per agregat
Disseny
Implementaci
Defineix una interfcie per
accedir i travessar els
elements dun agregat
crear un objecte Iterador
Iterador
first()
next()
isDone() : Boolean
currentItem() : Object
IteradorLlista
IteradorVector
Llistes i Vectors
en Java
crearIterador(): Iterador
Agregat
Vector
LinkedList
Implementa la interfcie
definida a lIterador segons
el recorregut que es vulgui fer
de creaci de lIterador
que retorna una instncia
de lIterador concret
first()
next()
isDone():Boolean
currentItem():Object
first()
next()
isDone():Boolean
currentItem():Object
Exemple daplicaci en UML: Problema
Rebut
1
*
pagador
Soci
nmSoci:Integer
mesEmissi : Mes
import : Import
pagat : Boolean = False
rebuts
Correspon
Es vol dissenyar loperaci deute de Soci (suma dels imports dels seus rebuts no
pagats).
Aplicaci del patr Iterador
deute():Import
R.I. Textuals
- No poden existir dos socis amb el mateix nmSoci.
- Un soci no pot tenir diversos rebuts amb el mateix mesEmissi.
76 76
Exemple daplicaci en UML: Soluci
Rebut
mesEmissi : Mes
import : Import
pagat : Boolean = False
pagat?() : Boolean
import?() : Import
*
1
Soci
nmSoci : Integer
deute() : Import
rebuts() : Iterador
pagador
rebuts
Correspon
objecte agregat
de soci
operaci de soci que
invoca a loperaci
crearIterador de
lobjecte agregat
rebuts
Diagrama de classes
acumula limport si el
rebut no sha pagat
:Soci
:Iterador
:Rebut
deute
Import
import?()
currentItem()
isDone()
first()
next()
pagat?()
rebuts()
*
Diagrama de seqncia
la definici daquesta navegabilitat
s conseqncia del disseny de
loperaci deute
Iteradors en Java: Enumeration
LinkedList
size : Integer
reset()
hasMoreElements(): Boolean
nextElement(): Object
currentElement(): Object
elements(): Enumeration
size():Integer
Object
Link
head
0..1
tail
0..1
pre
0..1
data
1
0..1
next
Enumeration
ListEnumeration
accedir i travessar els
elements dun agregat
pel cas de les LinkedList
return new ListEnumeration(head)
77 77
Exemple daplicaci en Java
:Soci
:Enumeration
:Rebut
deute
Import
import?()
nextElement()
hasMoreElements()
pagat?()
rebuts()
*
Diagrama de seqncia usant Java
Class Soci
{...
LinkedList rebuts
...
}
Class Rebut
{...
...
}
Definici de classes en Java
Implementaci de
lassociaci Correspon
i la seva navegabilitat,
mitjanant atributs
Diccionaris

dicSocis:Diccionari
Exemples dinstncies:
diccionari()
get(key:Object): Object
put(key:Object, v:Object): Object
remove(key:Object): Object
elements(): Iterador
keys(): Iterador
size: Integer
Diccionari
La classe dobjectes Diccionari mant una col.lecci dobjectes que poden ser
accedits mitjanant una clau key.
La clau key per accedir als objectes dun diccionari ha de ser clau externa de
lobjecte al que es vol accedir.
mant tots els socis del Club. La
clau daquest diccionari podria ser
dni (clau de Persona) o numSoci
(ja que no existeixen dos socis amb
el mateix numSoci).
retorna nul si no hi ha cap
objecte amb aquesta key
si la clau ja existeix, subtitueix
lobjecte existent O per v, i
retorna O
retorna un objecte Iterador
que travessa les claus del
diccionari
que travessa els objectes del
diccionari
dicRebuts:Diccionari
mant tots els rebuts del Club. La
clau daquest diccionari seria
nmSoci+mesEmissi.
78 78
Diccionaris en Java: Hashtable
dicSocis:Hashtable
Exemple dinstncia:
Hashtable
size: Integer
hashtable()
get(Obj ect key) : Obj ect
put(Obj ect k, Obj ect v) : Obj ect
remove(Obj ect key) : Obj ect
elements() : Enumeration
keys() : Enumeration
retorna nul si no hi ha cap
objecte amb aquesta key
si la clau ja existeix, subtitueix
lobjecte existent O per v, i
retorna O
que travessa les claus del
diccionari
que travessa els objectes del
diccionari
dicRebuts:Diccionari
Exemple diteraci de diccionaris
Es vol calcular el deute que t el Club (suma dels deutes de tots els socis).
Club
preuNos: Import
ltNumSoci:Integer=0
1
Soci
numSoci:Integer
deute(): Import
R.I. Textuals
- No poden existir dos socis amb el mateix nmSoci.
79 79
Exemple diteraci de diccionaris
Soci
numSoci : Integer
deute() : Import
Diagrama de classes
Club
preuNos: Import
darrerNumSoci:Integer=0
1
total_deute(): Import
Diagrama de seqncia
:Club
total_deute
dicSocis:Diccionari :Soci
:Iterador
elements()
deute()
currentItem()
isDone()
first()
next()
*
Import
la definici de loperaci
deute sha fet anteriorment.
Bibliografia
Design Patterns. Elements of Reusable Object-Oriented Software.
E. Gamma; R. Helm.; R. Johnson; J. Vlissides.
Addison-Wesley, 1995, pp. 257-271.
http://www.eli.sdsu.edu/courses/spring98/cs635/notes/iterator
80 80
Disseny de la Capa de Domini: Patr de disseny Controlador 1
Patr de disseny Controlador
Descripci general
Controlador Faana
faana-sistema
faana-empresa
Controlador Paper
Controlador Cas ds
Controlador Transacci
Relaci entre la Capa Presentaci i:
Controlador Transacci
Combinaci de controladors (Faana i Transacci)
Bibliografia
Descripci general
Context:
Els sistemes software reben esdeveniments externs
Un cop interceptat un esdeveniment a la Capa de Presentaci, algun
objecte de la Capa del Domini ha de rebre aquest esdeveniment i executar
les accions corresponents
Problema:
Quin objecte s el responsable de tractar un esdeveniment extern?
Soluci:
Assignar aquesta responsabilitat a un controlador
Un controlador s un objecte duna certa classe
Possibles controladors:
. Faana-Sistema: Un objecte que representa tot el sistema
. Faana-Empresa: Un objecte que representa tot el domini (empresa, etc.)
. Paper: Un objecte que representa un actor
. Cas ds: Un objecte que representa una instncia dun cas ds
. Transacci: Un objecte que representa una instncia desdeveniment extern
81 81
Controlador Faana: faana-sistema
Tots els esdeveniments externs sn processats per un sol objecte controlador faana
Controladors inflats si hi ha molts esdeveniments externs
Nhi ha de dos tipus depenent el significat que li donem:
- Controlador faana-sistema
- Controlador faana-empresa
altaSoci(dni:String, nom:String, adrea:String, e-mail:String, nm-cc:Integer, out nmSoci:Integer): Boolean
altaFamiliar(nmSoci:Integer, dni:String, nom:String, adrea:String, e-mail:String): Boolean
baixaSoci(nmSoci:Integer) : Boolean
baixaFamiliar(nmSoci:Integer, dni:String) : Boolean
canviCompteCorrent(nmSoci:Integer, nm-cc:Integer): Boolean
....
SistemaGestiClub 1
Faana-sistema: Un objecte que representa tot el sistema software (SistemaGestiClub)
Controlador Faana: faana-empresa
Faana-empresa: Un objecte que representa tot el domini del problema (Club)
ltNmSoci?(): Integer
incrementar-ltNmSoci()
....
Club 1
ltNumsoci: Integer=0
preuNos: Import
preuAnullaci: Import
En aquest exemple hem aprofitat lobjecte Club del model conceptual i li hem afegit la
responsabilitat de ser el controlador.
82 82
Controlador Paper
Controlador idoni si es volen controlar les accions realitzades per lactor
Problema si un mateix esdeveniment extern pot ser generat per diversos actors
Hi haur un controlador per cada actor
Controlador Paper: Un objecte que representa un actor dels diagrames de casos ds
Administrador
Controlador Cas ds
Pot tenir atributs definits per controlar lestat del cas ds
Problema si un mateix esdeveniment extern apareix en diversos casos ds
Hi haur tants controladors com casos ds tingui el sistema
Admetre Soci
Controlador Cas ds: Un objecte que representa un cas ds
:Sistema
:Administrador
altaSoci (dni, nom, adrea, e-mail, nm-cc, out nm-soci): Boolean
altaFamiliar(nm-soci, dni, nom, adrea, e-mail): Boolean
*
Cas ds Admetre Soci
83 83
Controlador Transacci: Definici
Basat en el patr de disseny Command
Es crea un objecte transacci a cada ocurrncia dun esdeveniment extern
Els parmetres i el retorn de loperaci de sistema associada a lesdeveniment
extern es corresponen als atributs de la transacci
Lexecuci de la transacci es realitza amb la invocaci de loperaci executar(), i
es defineixen operacions especfiques per a consultar els resultats de lexecuci
de la transacci
Sacostuma a destruir lobjecte transacci un cop recuperat el resultat
Operaci de sistema:
altaSoci(dni:String, nom:String, adrea:String, e-mail:String,
nm-cc:Integer, out nmSoci:Integer): Boolean
Sencarrega d efectuar les accions corresponents a la transacci
AltaSoci
dni: String
nom: String
adrea: String
e-mail[0..1]: String
nm-cc: Integer
nmSoci: Integer
resultat: Boolean
nmSoci?(): Integer
resultat():Boolean
executar()
Sencarreguen d obtenir el resultat de la transacci
Resultats de la transacci
Parmetres dentrada la transacci
Estructura de les classes Transacci
Transacci
executar()
AltaSoci
dni: String
nom: String
adrea: String
nmSoci: Integer
nm-cc: Integer
resultat: Boolean
nmSoci?(): Integer
resultat():Boolean
executar()
CanviCompteCorrent
nmSoci: Integer
nm-cc: Integer
resultat: Boolean
resultat():Boolean
executar()
FerRebuts
mesEmissi: Mes
executar()
TotalDeute
deute: Import
executar()
deute():Import
AltaFamiliar
nmSoci: Integer
dni: String
nom: String
adrea: String
resultat: Boolean
resultat():Boolean
executar()
operaci abstracta
Classe abstracta
84 84
Relaci entre la Capa
Presentaci i el controlador
Transacci
:Control-Interfcie
:AltaSoci
onEndavant
executar()
Capa presentaci Capa domini
resultat()
nmSoci()
nom
adrea
e-mail
endavant plega
Alta de soci
dni
nmSoci
nm-cc
. . .
Es dona dalta
un soci
Mostra el nmSoci
per pantalla
Obt el nmSoci
onEndavant
Capa presentaci Capa domini
:Club
altaSoci(...)
:AltaSoci
executar()
resultat()
nmSoci?()
:Control-Interfcie
nom
adrea
e-mail
endavant plega
Alta de soci
dni
nmSoci
nm-cc
Relaci entre la Capa
Presentaci i la combinaci de
controladors (Faana i
Transacci)
. . .
Es dona dalta
un soci
Mostra el nmSoci
per pantalla
Obt el nmSoci
85 85
Bibliografia
C. Larman
Prentice Hall, 1998. Cap. 18.13.
Design Patterns. Elements of Reusable Object-Oriented Software
E. Gamma, R. Helm, R. Johnson, J. Vlissides
86 86
Disseny de la Capa de Domini: Assignaci de responsabilitats a objectes. 1
Assignaci de responsabilitats a objectes
Responsabilitats dels objectes
Criteris per a lassignaci de responsabilitats:
Acoblament baix
Cohesi alta
Patrons dassignaci de responsabilitats:
(Controlador)
Expert
Creador
Bibliografia
Responsabilitats dels objectes
Lassignaci de responsabilitats a objectes consisteix a determinar (assignar)
quines sn les obligacions (responsabilitats) concretes dels objectes del diagrama
de classes per donar resposta als esdeveniments externs.
Les responsabilitats dun objecte consisteixen en:
Saber:
. Sobre els atributs de lobjecte
. Sobre els objectes associats
. Sobre dades que es poden derivar
Fer:
. Fer quelcom en el propi objecte
. Iniciar una acci en altres objectes
. Controlar i coordinar activitats en altres objectes
Lassignaci de responsabilitats a objectes es fa durant el disseny, al definir i
localitzar les operacions de cada classe dobjectes.
87 87
Acoblament
Hi ha un acoblament de la classe A a la classe B si:
A t un atribut de tipus B
A t una associaci navegable amb B
B s un parmetre o el retorn duna operaci de A
Una operaci de A referncia un objecte de B
A s una subclasse directa o indirecta de B
Lacoblament entre classes ha de ser baix per tal de:
Evitar que canvis en una classe tinguin efecte sobre altres classes
Facilitar la comprensi de les classes (sense recrrer a altres)
Facilitar la reutilitzaci
Acoblament duna classe s una mesura del grau de connexi,
coneixement i dependncia daquesta classe respecte daltres classes.
B
A
atribut : B
operac(b : B) : B
Anlisi dacoblament: Exemple
Diagrama de classes normalitzat
* 1
Persona
dni: String
nom: String
adrea: String
e-mail [0..1]: String
Familiar
Soci
nmSoci: Integer
deute(): Import
Amb
tipus
Restriccions dintegritat:
Claus de classes no associatives (Persona, dni)
Suposicions:
Lassociaci Amb t navegabilitat doble
88 88
Contracte altaFamiliar normalitzat i controlador
Operaci: altaFamiliar (nmSoci: Integer, dni:String, nom:String, adrea:String, e-mail:String)
Classe Retorn: Boolean
Semntica: Donar dalta un familiar dun soci.
Postcondicions:1. En el casos segents, operaci invlida i es retorna fals:
1.1 No existeix un soci amb nmSoci
1.2 Ja existeix una Persona amb aquest dni (Afegida)
2.1 Es crea un objecte de Familiar (i de Persona)
2.2 Es crea una ocurrncia de lassociaci Amb entre
Familiar i el soci amb nmSoci
Alta_familiar
nmSoci: Integer
dni: String
nom: String
adrea: String
resultat: Boolean
executar()
resultat():Boolean
Transacci
executar()
Diagrama de seqncia (I)
La classe AltaFamiliar est acoblada a dicSocis, dicPersones, Soci i Familiar
La classe Soci est acoblada a Familiar i, aquesta a Soci
:AltaFamiliar
f:Familiar
s:Soci
dicPersones: Diccionari
executar
get(dni)
afegirFamiliar
afegirFamiliar(f:Famil iar)
dicSocis: Diccionari
get(nmSoci)
Es crea familiar (i persona) i
sinicialitzen els seus atributs
Sassocia el familiar f al soci
Comprova que no existeix
cap persona amb dni
Comprova existncia dun
soci s amb nmSoci
creassocAmb(s)
Sassocia el soci s al familiar
89 89
Diagrama de seqncia (II)
La classe AltaFamiliar est acoblada a dicSocis i Soci
La classe Soci est acoblada a dicPersones i Familiar.
La classe Familiar est acoblada a Soci.
:AltaFamiliar
f:Familiar
s:Soci
executar
get(dni)
afegirFamiliar
afegirFamiliar(dni:String, nom:String, adrea:String, e-mail:String):Boolean
get(nmSoci)
Comprova que no
existeix cap persona
amb dni
Es crea familiar (i persona) i
sinicialitzen els seus atributs
Sassocia el familiar f al soci
Comprova lexistncia del
soci s amb nmSoci
creassocAmb(s)
Sassocia el soci s al familiar
Diagrama de classes de disseny
Alta_familiar
nmSoci: Integer
dni: String
nom: String
adrea: String
resultat: Boolean
executar()
resultat():Boolean
Transacci
executar()
*
1
Persona
dni: String
nom: String
adrea: String
Familiar
Soci
nmSoci: Integer
deute(): Integer
afegirFamiliar(dni:String, nom:String,
adrea:String, e-mail:String):Boolean
Amb
tipus
90 90
Cohesi
Cohesi duna classe s una mesura del grau de relaci i de concentraci de les
diverses responsabilitats duna classe.
Una classe amb cohesi alta:
T poques responsabilitats en una rea funcional
Col.labora (delega) amb daltres classes per a fer les tasques
Acostuma a tenir poques operacions
Aquestes operacions estan molt relacionades funcionalment
Avantatges:
Fcil comprensi
Fcil reutilitzaci i manteniment
Una classe amb cohesi baixa:
s lnica responsable de moltes coses i de diverses rees funcionals
T moltes operacions i/o operacions poc relacionades funcionalment
Inconvenients:
s difcil de comprendre
s difcil de reutilitzar i de mantenir
s molt sensible als canvis
Cohesi: exemple
Els controladors faana acostumen a ser poc cohesius
ltNmSoci?(): Integer
incrementar-ltNmSoci()
....
Club 1
ltNumsoci: Integer=0
preuNos: Import
91 91
Patr Expert
Context:
Problema:
Decidir a quina classe hem dassignar una responsabilitat concreta
Soluci:
Assignar una responsabilitat a la classe que t la informaci necessria per
realitzar-la
Laplicaci del patr requereix tenir clarament definides les responsabilitats
que es volen assignar (postcondicions de les operacions)
No sempre existeix un nic expert, sin que poden existir diversos experts
parcials que hauran de collaborar.
Beneficis:
Es mant lencapsulament baix acoblament
Conducta distribuda entre les classes que tenen la informaci
alta cohesi
Patr Expert: Exemple
Diagrama de classes inicial (normalitzat)
Suposici:
Totes les associacions tenen navegabilitat doble
* 1
Persona
dni: String
nom: String
adrea: String
Familiar
Soci
numSoci: Integer
deute(): Integer
Amb
Reserva
datReserva: Data
*
1
reservant
Pista
nm: Integer
Interval
data: Data
inici: Hora
* *
1
1
Baixa_familiar
numsoci: Integer
dni: String
resultat: Boolean
executar()
resultat():Boolean
Transacci
executar()
Per
La
En
92 92
Cas ds Baixa Familiar
Operaci: baixaFamiliar (nmSoci:Integer, dni:String)
Semntica: Un soci vol donar de baixa un dels seus familiars.
Precondicions: Els parmetres tenen valor.
Postcondicions:1. En el casos segents, operaci invlida i es retorna fals:
1.1 No existeix un Familiar amb el dni especificat
1.2 No existeix un soci amb el nmSoci especificat
1.3 La persona amb dni no s familiar del soci amb nmSoci
2.1 Es dna de baixa lobjecte de Familiar (i de Persona)
2.2 Seliminen les Reserves realitzades pel Familiar
:Sistema
:Soci
baixaFamiliar(nmSoci, dni): Boolean
Cas ds Baixa Familiar
Contracte operaci baixaFamiliar normalitzat
Operaci: baixaFamiliar (nmSoci:Integer, dni:String)
Semntica: Donar de baixa un familiar dun soci.
Precondicions: Els parmetres tenen valor.
Postcondicions:
1. En el casos segents, operaci invlida i es retorna fals:
1.1 No existeix un Familiar amb el dni especificat (dicPersones i Persona)
1.2 No existeix un soci amb el nmSoci especificat (dicSocis)
1.3 La persona amb dni no s familiar del soci amb nmSoci (Soci, Familiar)
2.1 Es dna de baixa lobjecte de Familiar (i de Persona) (Familiar)
2.2 Seliminen les Reserves realitzades pel Familiar (Persona)
Experts
93 93
Diagrama de seqncia baixaFamiliar (I)
:BaixaFamiliar
executar()
get(dni)
p:Persona
familiar-de(nmSoci)
Comprova
existncia de
persona p amb dni
p:Familiar
eliminarReserves()
baixa()
:Soci
elimassocAmb(p)
Elimina p com a Familiar i
com a Persona, i les
seves associacions
Comprova que la persona
p s familiar del Soci amb
nmSoci
Operaci heretada
de Persona
Diagrama de seqncia baixaFamiliar (II)
familiar-de(nmSoci)
compara si nmSoci
coincideix
:Familiar
:Soci
nmSoci?()
Boolean
familiar-de(nmSoci)
:Soci
fals
:Reserva
first()
:Iterador
isDone()
currentItem()
eliminar()
next()
*
p:Persona
reserves()
eliminarReserves()
operaci
pendent de
definir
94 94
*
1
Soci
numSoci: Integer
deute(): Integer
nmSoci?(): Integer
familiar-de(nmSoci:Integer): Boolean
Amb
*
1
reservant
Pista
nm: Integer
Interval
data: Data
inici: Hora
*
*
1
1
Baixa_familiar
numsoci: Integer
dni: String
resultat: Boolean
executar()
resultat():Boolean
Transacci
executar()
Persona
dni: String
nom: String
adrea: String
eliminarReserves()
reserves(): Iterador
Familiar
baixa()
Reserva
datReserva: Data
eliminar()
tipus {disjoint, complete}
La
En
Per
Patr Creador
Context:
Problema:
Qui ha de tenir la responsabilitat de crear una nova instncia duna classe.
Soluci:
Assignar a una classe B la responsabilitat de crear una instncia duna
classe A si se satisf una de les condicions segents:
. B s un agregat d objectes dA
. B cont objectes dA
. B enregistra instncies dobjectes dA
. B usa molt objectes dA
. B t les dades necessries per inicialitzar un objecte d A (B t els valors dels
parmetres del constructor dA)
Beneficis:
Acoblament baix
95 95
Patr Creador: Exemple
Diagrama de classes normalitzat i Controlador
AltaSoci
dni: String
nom: String
adrea: String
nm-cc: Integer
resultat: Boolean
nmSoci: Integer
executar()
resultat():Boolean
nmSoci?(): Integer
Transacci
executar()
* 1
Persona
dni: String
nom: String
adrea: String
Familiar
Soci
nmSoci: Integer
deute(): Integer
Amb
tipus
CompteCorrent
nm-cc: Integer
saldo: Integer
1
*
Del
Club
ltNumSoci: Integer=0
preuNos: Import
1
Restriccions dintegritat:
Claus de classes no associatives (Persona, dni), (CompteCorrent, nm-cc)
Contracte operaci altaSoci normalitzat
Operaci: altaSoci (dni:String, nom:String, adrea:String, e-mail:String, nm-cc: Integer,
out nmSoci: Integer)
Semntica: Donar dalta un soci i assignar-li el compte corrent.
Postcondicions:
1. En el casos segents, operaci invlida i es retorna fals:
1.1 No existeix un compte corrent amb nm-cc
1.2 Ja existeix un Soci amb aquest nmSoci (Afegida)
1.3 Ja existeix una Persona amb aquest dni (Afegida)
2.1 Es crea un objecte de la classe Soci (i de la classe Persona)
2.2 Latribut nmSoci s igual a latribut ltNumSoci+1 de Club
2.3 Latribut ltNumSoci de Club sincrementa en una unitat
2.4 Es crea una ocurrncia de lassociaci Del entre Soci i CompteCorrent
96 96
Diagrama seqncia AltaSoci --- Cas 1
AltaSoci t totes les dades necessries per inicialitzar Soci, excepte nmSoci
Alta Soci acoblat amb els tres diccionaris, Club i Soci. Soci acoblat amb CompteCorrent
:AltaSoci
s:Soci
:Club
executar
get(dni)
assigCompte(cc)
get(nmSoci)
Incrementa latribut ltnumSoci i
retorna el nou valor
cap persona amb dni
cap soci amb nmSoci
dicCompteCorrents: Diccionari
get(nm-cc)
Comprova que existeix un
compte corrent cc amb nm-cc
ltNumSoci()
put(dni,s)
put(nmSoci,s)
Afegim el nou soci
als diccionaris
Associem al soci el
compte corrent
Diagrama seqncia AltaSoci --- Cas 2
Club rep les dades necessries per inicialitzar Soci, excepte nmSoci.
Alta Soci acoblat amb Club. Club acoblat amb els tres diccionaris i Soci. Soci acoblat amb CompteCorrent
Disminueix la cohesi de Club (si no t altres responsabilitats relatives a Soci) i augmenta el seu acoblament.
:AltaSoci
s:Soci
:Club
executar
get(dni)
assigCompte(cc)
get(nmSoci)
Incrementa latribut
ltnumSoci
Comprova que no
existeix cap soci
amb nmSoci ni
cap Persona amb
dni
dicCompteCorrents: Diccionari
get(nm-cc)
Comprova que
existeix un
compte corrent
cc amb nm-cc
nouSoci
put(dni,s)
put(nmSoci,s)
Afegim el nou soci
als diccionaris
Associem al
soci el compte
corrent
Boolean
97 97
Diagrama de classes de disseny (Cas 2)
AltaSoci
dni: String
nom: String
adrea: String
nm-cc: Integer
resultat: Boolean
nmSoci: Integer
executar()
resultat():Boolean
nmSoci?(): Integer
Transacci
executar()
* 1
Persona
dni: String
nom: String
adrea: String
Familiar
Soci
nmSoci: Integer
deute(): Integer
assigCompte(cc:CompteCorrent)
Amb
tipus
CompteCorrent
nm-cc: Integer
saldo: Integer
1
*
Del
Club
ltNumSoci: Integer=0
preuNos: Import
1
nouSoci(dni:String, nom:String, adrea:String,
e-mail:String, nm-cc: Integer):Boolean
Bibliografia
Larman, C.
Prentice Hall, 1998. Caps. 18 i 19.
98 98
Disseny de la Capa de Domini: Patr de disseny Estat 1
Patr de disseny Estat
Descripci general.
Soluci: Estructura.
Aspectes a considerar.
Exemple 1.
Conseqncies.
Exemple 2.
Bibliografia.
Descripci general
Context:
En una jerarquia despecialitzaci, la semntica duna operaci s diferent a
les diverses subclasses per les que pot passar un objecte.
El comportament dun objecte depn del seu estat en temps dexecuci, que
s variable en el decurs del temps.
Problema:
La tecnologia actual no permet que un objecte canvi dinmicament de
subclasse.
Les estructures condicionals per tractar el comportament en funci de lestat
no sn desitjables ja que afegeixen complexitat i/o duplicaci de codi.
Soluci:
Crear una classe per cada estat que pugui tenir lobjecte context.
El canvi de subclasse se simula pel canvi de lassociaci amb la classe estat.
Basant-se en el polimorfisme, assignar mtodes a cada classe estat per
tractar la conducta de lobjecte context.
Quan lobjecte context rep un missatge que depn de lestat, el reenvia a
lobjecte estat.
99 99
Soluci: Estructura
Context
requesta()
Estat
tractament()
1
EstatConcret1
tractament()
EstatConcret2
tractament()
estat
estat tractament()
Altres aspectes a considerar en laplicaci del patr estat:
Compartici o no dels objectes estat concrets (multiplicitat associada al rol
del context).
On estan definides les transicions destat.
Moment de creaci i destrucci dels objectes estat.
Aspectes a considerar: Compartici dobjectes estat
Estats no compartits:
Cada objecte context t el seu propi objecte estat, que inclou tota la
informaci rellevant daquell objecte en aquell estat.
Estats compartits:
Diversos objectes context poden usar els mateixos objectes estat, si els
objectes estat no tenen atributs/associacions.
Un objecte estat pot no tenir atributs/associacions:
Si no els necessita.
Si en t, per es defineixen en lobjecte context.
Dues variants:
Lobjecte context els passa a lestat quan els necessita.
Els objectes estat els obtenen del context quan els necessiten.
100 100
Exemple 1: Problema
Esquema conceptual de lespecificaci i diagrama destats dInterruptor:
Interruptor
{disjoint,complete}
Obert
referncia: String
Tancat
datatanc: Data tempsob:Integer
R.I. Textuals:
Claus classes no associatives: (Interruptor, referncia)
Es vol dissenyar loperaci consum dun interruptor:
s 0 si linterruptor est tancat.
s el temps que estar obert multiplicat per un factor alfa si linterruptor est
obert.
Aplicaci del patr Estat
Tancat Obert
obrir
tancar
estat
data en la que
es va tancar
linterruptor
temps que estar
obert l interruptor
Exemple 1: Compartici dobjectes estat
No Compartici dels objectes estat:
Els objectes estat
tenen informaci
1 Interruptor
referncia: String
{disjoint,complete}
Estat 1
consum():Integer
consum():Integer
Tancat
datatanc: Data
consum():Integer
Obert
tempsob:Integer
consum():Integer
101 101
Exemple 1: Compartici dobjectes estat
Compartici dels objectes estat:
Interruptor
referncia: String
datatanc[0..1]:Data
tempsob[0..1]:Integer
{disjoint,complete}
Obert Tancat
Estat 1
consum():Integer
*
Els objectes estat
no tenen informaci o
la que tenien sha posat
a lobjecte context
aquesta operaci pot
calcular el consum ja
que t tota la informaci
necessria per fer-ho.
Aspectes a considerar: On es defineixen les transicions destat
Les transicions destat vnen determinades pel diagrama destats
despecificaci.
El patr no especifica quin participant t la responsabilitat de portar a
terme les transicions destat.
La responsabilitat de portar a terme les transicions destat pot estar
definida a:
Lobjecte context:
Si els estats sn compartits per diversos contextos.
Si les regles de canvi destat sn fixes.
Els objectes estat:
s ms flexible que siguin els propis objectes estat els qui decideixin
quan fer la transici i especificar el canvi destat.
Hi ha dhaver una operaci en lobjecte context que permeti canviar
lestat.
T linconvenient que una subclasse estat ha de conixer almenys una
altra subclasse.
102 102
Exemple 1: On es defineixen les transicions destat
Transicions destat definides a lobjecte context (estats no compartits):
Aquesta operaci es
utilitzada per les
operacions de canvi
destat del Context
per saber quin s el
seu estat
Interruptor
referncia: String
{disjoint,complete}
1
tancar(dt:Data): Bool
obrir(to:Integer):Bool
consum():Integer
1
Aquesta operaci gestiona el
canvi destat dobert a tancat
Aquesta operaci gestiona el
canvi destat de tancat a obert
Tancat
datatanc: Data
consum():Integer
Obert
tempsob:Integer
consum():Integer
Estat
tipus():String
consum():Integer
Transicions destat definides als objectes estat (estats no comparits):
Exemple 1: On es defineixen les transicions destat
Aquestes operacions deleguen
la responsabilitat del canvi
destat als objectes estat
Interruptor
referncia: String
{disjoint,complete}
1
tancar(dt:Data):Bool
consum():Integer
mod_assoc(e:Estat)
1
Tancat
datatanc: Data
obrir(to:Integer,i:Interruptor):Bool
tancar(dt:Data,i:Interruptor):Bool
consum():Integer
tempsob:Integer
Obert
consum():Integer
Estat
consum():Integer
Aquestes operacions
gestionen el canvi destat
Aquesta operaci modifica
lassociaci entre Interruptor
i Estat.
103 103
Aspectes a considerar: Creaci i destrucci dobjectes estat
Dues opcions:
A: Crear-los quan es necessiten i destruir-los quan ja no sn necessaris.
B: Crear-los dentrada i no destruir-los mai.
Opci A:
Preferible quan:
Lestat inicial no es coneix en temps dexecuci.
Els contextos rarament canvien destat.
Evita la creaci dobjectes estat que no susaran.
Opci B:
Preferible quan :
Lobjecte context canvia destat molt sovint.
Evita la destrucci dobjectes que poden ser necessaris ms endavant.
Els costos de creaci (instanciaci) es paguen un sol cop.
No hi ha costos de destrucci.
Exemple 1: Creaci i destrucci dels objectes estat
Creaci i destrucci dels objectes estat quan es necessiten:
Creaci del nou estat tancat,
destrucci de lestat obert i
creaci de la nova associaci
entre Interruptor i el nou estat.
Creaci del nou estat obert ,
destrucci de lestat tancat i
creaci de la nova associaci
entre Interruptor i el nou estat.
Interruptor
referncia: String
tancar(dt:Data):Bool
consum():Integer
mod_assoc(e:Estat)
1
No canvien lestat
{disjoint,complete}
1
Tancat
datatanc: Data
consum():Integer
tempsob:Integer
Obert
consum():Integer
Estat
consum():Integer
104 104
Exemple 1: Soluci completa
Interruptor
referncia: String
tancar(dt:data):Bool
consum():Integer
mod_assoc(e:Estat)
1
Hiptesis daplicaci del patr Estat:
Objectes estat no compartits.
Transicions destat definides en els objectes estat.
Creaci dels objectes quan es necessiten.
{disjoint,complete}
1
Tancat
datatanc: Data
consum():Integer
tempsob:Integer
Obert
consum():Integer
Estat
consum():Integer
Exemple 1: Soluci completa
i:Interruptor :Estat
consum()
consum()
:Obert
consum()
retorna tempsob*alfa
:Tancat
consum()
retorna 0
consum():Integer
i:Interruptor :Estat
obrir(to)
obrir(to,i)
:Obert
obrir(to,i)
Els diagrames de seqncia
per loperaci tancar serien
similars als de loperaci obrir.
:Tancat
obrir(to,i)
ob:Obert
i:Interruptor
mod_assoc(ob)
obrir(to:Integer):Integer
Fals
Cert
Boolean
105 105
Conseqncies
Descomposa la conducta dels diferents estats:
La conducta de cada estat est en una operaci diferent.
Localitza (en un sol lloc) la conducta especfica dun estat.
Es poden definir fcilment nous estats, sense alterar els existents.
Fa explcites les transicions destat:
Cada estat t associat un objecte estat diferent.
Si els objectes estat no tenen atributs/associacions propis, poden ser
compartits per diversos contextos.
Exemple 2: Problema
Esquema conceptual de lespecificaci:
Es vol dissenyar una operaci de la classe dobjectes Reserva que calcula el cost
duna reserva.
cost= 0 si la reserva est prevista o anul.lada per manteniment.
cost= preuHoraPista (de Club) si la reserva est usada.
cost= preuNos (de Club) si la reserva est no usada.
cost= preuAnul.laci (de Club) si la reserva est anul.lada pel client.
Aplicaci del patr Estat
Reserva
{disjoint,complete}
Res.Prevista ResAnMant
data:Data
ResAnClient
data:Data
ResNoUsada ResUsada
dataReserva:Data
estat
106 106
Prevista
Usada
NoUsada
Anul.lada per Manteniment
Anul.lada pel Client
anMant
anClient
usada
veureSiNoUsada[ dataReserva<dataActual ]
Exemple 2: Diagrama destats de Reserva
Exemple 2: Soluci
Hiptesis daplicaci del patr Estat:
Objectes estat no compartits.
Transicions destat definides en lobjecte context.
Creaci/destrucci dels objectes estat quan es necessiten.
Reserva
1
cost():Integer
anMant(d:Data):Bool
anClient(d:Data):Bool
usada():Bool
nousada():Bool
1
dataReserva:Data
EstatRes
cost():Integer
tipus():String
{disjoint,complete}
ResAnMant
data:Data
ResAnClient
data:Data
Res.Prevista ResNoUsada
cost():Integer
ResUsada
cost():Integer
cost():Integer
107 107
Exemple 2: Soluci
Operaci cost():Integer : Diagrames de seqncia:
:ResUsada
cost()
:Club
preuHoraPista()
:Reserva :Estat
cost()
cost()
retorna 0
operaci ganxo que es
heretada per totes les
subclasses i redefinida
a ResUsada, ResNoUsada
i ResAnClient.
:ResNoUsada
cost()
:Club
preuNos()
:ResAnClient
cost()
:Club
preuAnul.laci()
Exemple 2: Soluci
r:Reserva erp:ResPrevista
eram:ResAnMant
anMant(d)
:Estat
tipus()
formar nova associaci
entre r i eram
comprovar que el tipus
s reserva prevista
La resta de diagrames
de seqncia per les
operacions anClient,
usada i nousada
serien similars.
Operaci anMant(d:Data) : Diagrames de seqncia:
Boolean
108 108
Bibliografia
Elements of Reusable Object-Oriented Software.
E. Gamma; R. Helm; R. Johnson; J. Vlissides
An I ntroduction to Object-Oriented Analysis and Design.
C. Larman
Prentice Hall, 1998, pp. 406-410.
http://www.eli.sdsu.edu/courses/spring98/cs635/notes/state
109 109
Disseny de la Capa de Domini: Patr de disseny Mtode plantilla. 1
Patr de disseny Mtode Plantilla
Descripci general.
Soluci: Estructura.
Exemple 1.
Conseqncies.
Extensi Exemple 1.
Exemple 2.
Bibliografia.
Descripci general
Context:
La definici duna operaci en una jerarquia t un comportament com a
totes les subclasses i un comportament especfic per cadascuna delles.
Problema:
Repetir el comportament com a totes les subclasses implica duplicaci de
codi i un manteniment ms costos.
Soluci:
Definir lalgorisme (loperaci) en la superclasse, invocant operacions
abstractes (amb signatura definida en la superclasse i mtode a les
subclasses) que sn redefinides a les subclasses.
Loperaci de la superclasse defineix la part del comportament com i les
operacions abstractes la part del comportament especfic.
111 111
Soluci: Estructura
AbstractClass
templateMethod()
primitiveOperation1()
ConcreteClass
...
...
..
comportament com
comportament especfic
mtode de loperaci plantilla:
Exemple 1: Problema
Centre Docent
nom: String
*
Escola Ens. Secundria
numestudiants: Integer
Universitat
datacreaci: Data
{disjoint,complete}
Professor
estudis: String
Ensenya 1
Pers. en Formaci
dni: String
1
*
Becari
nif: Integer
1 *
Es vol dissenyar una operaci de la classe dobjectes Centre Docent per calcular
el nombre dempleats que t un centre docent que tenen una edat < 25 anys.
num_empleats=num_professors+num_becaris amb edat < 25 anys si el
centre s una Universitat
num_empleats=num_professors+num_pers_en_formaci amb edat < 25
anys si el centre s una Escola dEnsenyana Secundria.
Aplicaci del patr Plantilla
Assignat
T
R.I. Textuals:
Claus classes no associatives:
(Centre Docent, nom);
(Pers.Docent, nom)
tipus
Pers. Docent
nom: String
edat: Integer
{disjoint,complete}
tipus
Nota: Suposem que els Centres Docents i el Personal Docent no poden canviar de subclasse
112 112
Exemple 1: Soluci (I)
Aplicaci del patr plantilla:
Centre Docent
nom: String
*
{disjoint,complete}
Professor
estudis: String
Ensenya 1
Pers. en Formaci
dni: String
1
*
Becari
nif: Integer
1
*
Assignat
T
num_empleats(): Integer
num_professors():Integer
num_pers_espec():Integer
Universitat
datacreaci: Data
num_pers_espec():
Integer
num_pers_espec(): Integer
mtode plantill a
op.concreta
op. primitiva (abstracta)
definici de loperaci abstracta
Pers. Docent
nom: String
edat: Integer
{disjoint,complete}
tipus
tipus
Exemple 1: Soluci (II)
sumem els dos valors
El diagrama de seqncia de
num_pers_espec() per Escola
Ens. Secundria seria similar al
d Universitat
op. concreta
:CentreDocent
Integer
num_professors()
num_empleats()
num_pers_espec()
mtode plantill a
op. primitiva (abstracta)
:CentreDocent
:Iterador
Integer
currentItem()
isDone()
first()
next()
professors()
*
num_professors()
incrementem un
comptador si edat
<25
:Professor
edat()
num_pers_espec()
:Universitat
:Iterador
Integer
currentItem()
isDone()
first()
next()
becaris
*
incrementem un
comptador si edat
<25
:Becari
edat()
113 113
Exemple 1: Soluci (III)
Diagrama de classes de disseny resultant:
Centre Docent
nom: String
*
{disjoint,complete}
Professor
estudis: String
Ensenya 1
Pers. en Formaci
dni: String
1
*
Becari
nif: Integer
1
*
Assignat
T
Universitat
datacreaci: Data
num_pers_espec():
Integer
Pers. Docent
nom: String
edat: Integer
{disjoint,complete}
tipus
edat(): Integer
tipus
Conseqncies
Tcnica fonamental per a la reutilitzaci de codi.
Els mtodes plantilla porten a una estructura de control invertida:
Principi de Hollywood.
Els mtodes plantilla acostumen a cridar operacions dels segents
tipus:
Operacions concretes de la AbstractClass.
Operacions primitives (s a dir, operacions abstractes).
Operacions ganxo, que proporcionen conducta per defecte (normalment,
res), que les subclasses poden redefinir, si cal.
Operacions concretes (en ConcreteClass o en classes client).
s important que els mtodes plantilla especifiquin:
quines operacions sn ganxos (poden ser redefinides).
Quines operacions sn abstractes (han de ser redefinides):
conv que nhi hagin com menys millor.
114 114
Extensi Exemple 1: Problema
Centre Docent
nom: String
*
Universitat
datacreaci: Data
{disjoint,complete}
Professor
estudis: String
Ensenya 1
Pers. en Formaci
dni: String
1
*
Becari
nif: Integer
1 *
Assignat
T
R.I. Tetuals:
Claus classes no associatives:
(Centre Docent, nom); (Pers.Docent, nom)
Escola Ens. Primria
edatmxima: Integer
Es vol dissenyar la mateixa operaci nombre dempleats que t un centre docent.
num_empleats dUniversitat i dEscola Ensenyana Secundria igual que
lexemple anterior.
num_empleats=num_professors amb edat < 25 anys si el centre s una
Escola dEnsenyana Primria.
Pers. Docent
nom: String
edat: Integer
{disjoint,complete}
tipus
tipus
Extensi Exemple 1: Soluci (I)
Diagrama de classes de disseny resultant:
Centre Docent
nom: String
*
{disjoint,complete}
Professor
estudis: String
Ensenya 1
Pers. en Formaci
dni: String
1
*
Becari
nif: Integer
1
*
Assignat
T
Universitat
datacreaci: Data
num_pers_espec():
Integer
mtode plantill a
op.concreta
op. ganxo
redefinici de loperaci ganxo
Escola Ens. Primria
edatmxima: Integer
Pers. Docent
nom: String
edat: Integer
{disjoint,complete}
tipus
edat(): Integer
tipus
115 115
Extensi Exemple 1: Soluci (II)
El diagrames de seqncia de
num_pers_espec() per Escola
Ens. Secundria i Universitat
i num_professors() per Centre
Docent serien iguals als
de lexemple anterior
:Centre Docent
num_pers_espec()
Integer
retorna 0
op. concreta
mtode plantill a
:CentreDocent
Integer
num_professors()
num_empleats()
sumem els dos valors
num_pers_espec()
op. ganxo
Exemple 2: Problema
deute(): Import
Persona
dni: String
nom: String
adrea: String
Familiar Soci
nmSoci: Integer
{disjoint,complete}
1 *
R.I. Tetuals:
- Claus classes no associatives: (Persona,dni)
- No poden existir dos socis amb el mateix numSoci.
Es vol dissenyar dos casos ds amb un nic esdeveniment per consultar les
dades dun soci:
El primer cas ds obt el nom i el deute dun soci a partir del nmSoci en cas
dexistir, i retorna fals en cas contrari.
El segon obt el nom i ladrea tamb a partir del nmSoci en cas dexistir, i
retorna fals en cas contrari.
Amb
116 116
TrCUS-1
deute: Import
obtDades(s: Soci )
TransConsultaUnSoci
numSoci: Integer
nom: String
resultat:Boolean
executar()
obtDades(s:Soci)
Operaci primitiva
Cert si el soci amb
numSoci existeix. Fals
en cas contrari.
Transacci
executar()
TrCUS-2
adrea: String
obtDades(s: Soci )
Operaci plantilla
Exemple 2: Soluci
deute(): Import
Persona
dni:String
nom: String
adrea: String
Soci
numSoci: Integer
{disjoint,complete}
nom(): String
adrea(): String
....
....
Exemple 2: Soluci
deute()
:TrCUS-1 s:Soci
obtDades() adrea()
:TrCUS-2 s:Soci
obtDades()
error, si el soci
no existeix
:TransConsultaUnSoci
s:Soci
dicSocis:Diccionari
executar
get(numSoci)
nom()
obtDades(s)
117 117
Bibliografia
Elements of Reusable Object-Oriented Software.
E. Gamma; R. Helm; R. Johnson; J. Vlissides
An I ntroduction to Object-Oriented Analysis and Design.
C. Larman
Prentice Hall, 1998, cap. 38.11.
http://www.eli.sdsu.edu/courses/spring98/cs635/notes/template
118 118
Disseny de la Capa de Domini: Exemple 1
Exemple Capa de Domini
Especificaci:
Esquema Conceptual
Cassos ds
Diagrama dEstats
Normalitzaci:
Diagrama de classes normalitzat
Contractes operacions normalitzats
Aplicaci del Patr Estat
Aplicaci del Patr Controlador
Aplicaci del Patr Expert
Diagrames de Seqncia
Diagrama de Classes de Disseny
Especificaci: Esquema Conceptual
0.. 3
Persona
dni: Integer
nom: String
/nmv: Integer
Ciutat
nom: String
Viatge
*
*
Vol-viatjar
Mar
{incomplete}
0..1
*
Amb
Hotel
nom: String
*
1
De
/T-pressupostats
1
inici
Data
data: Date
*
Pressupostat
preu: Import
Reservat
avan: Import
Confirmat
R.I. Textuals:
- Claus classes no associatives: (Persona, dni); (Data, data); (Ciutat, nom)
- Una Ciutat no pot tenir ms dun Hotel amb el mateix nom
- Un viatge confirmat es fa a un Hotel de la mateixa ciutat on es fa el viatge
- Una persona no pot tenir ms dun viatge confirmat amb una mateixa data dinici
Informaci derivada:
- nmv: s el nombre de viatges confirmats daquella Persona
- T-pressupostats: s igual al conjunt de viatges pressupostats duna Persona
Suposicions:
- Latribut derivat nmv sha de calcular i lassociaci derivada T-pressupostats sha de materialitzar.
- Les associacions Amb i T-pressupostats tenen navegabilitat doble
119 119
Especificaci: Cas ds
Quines-Persones
:Sistema
:Empleat/da
Qui?(nom-c, nom-h, ll-per): ok?
Operaci: qui? (nom-c: String, nom-h: String, out ll-per: Llista-noms)
Precondicions: Els arguments han de tenir valor
Semntica: Retorna la llista de noms de persones que shan allotjat alguna vegada a
lhotel nom-h de la ciutat nom-c.
Postcondicions:
1. Si lhotel nom-h no s de la ciutat nom-c o b no hi cap persona que shi hagi
allotjat, llavors operaci invlida i es retorna Fals
2. En cas contrari, operaci vlida, es retorna Cert i la llista que cont els noms de
totes les persones que shan allotjat alguna vegada a lhotel.
Llista-noms= { nom }
Especificaci: Cas ds
Confirmar-Viatge-al-Mar
Operaci: confirmar-mar (dni: Integer, nom-c: String, data: Date, nom-h: String)
Semntica: Confirmar un viatge a una ciutat de mar i assignar-li lhotel
Postcondicions:
1. En el segents casos, operaci invlida i retorna Fals:
1.1 Si la ciutat nom-c no s de mar
1.2 Si no existeix un viatge de la persona a la ciutat i per a la data especificats
1.3 Lhotel nom-h no s de la ciutat nom-c
2. En cas contrari, operaci vlida, es retorna Cert i:
2.1 El viatge passa a estar Confirmat
2.2 Es crea una nova ocurrncia de lassociaci Amb entre el viatge confirmat i lHotel
:Sistema
:Empleat/da
Confirmar-mar(dni, nom-c, data, nom-h): ok?
120 120
Especificaci: Diagrama dEstats
Pressupostat Reservat
Confirmat
reservar
confirmar
confirmar
Normalitzaci: Diagrama de classes normalitzat
*
Ciutat
nom: String
Viatge
*
*
Mar
{incomplete}
0..1 *
Amb
Hotel
nom: String
*
1
De
T-pressupostats
1
inici
Data
data: Date
*
Pressupostat
preu: Import
Reservat
avan: Import
Confirmat
Persona
dni: Integer
nom: String
mmv(): Integer
1
1
1
Viatge-Ciutat
Viatge-Data
Viatge-Pers
R.I. Textuals:
- Claus classes no associatives: (Persona, dni); (Data, data); (Ciutat, nom)
- Una Ciutat de Mar no pot tenir ms dun Hotel amb el mateix nom
- Un viatge confirmat es fa a un Hotel de la mateixa ciutat on es fa el viatge
- Una persona no pot tenir ms dun viatge confirmat amb una mateixa data dinici
- Per una persona i una data no poden existir ms de tres viatges a ciutats diferents
- No poden existir dos viatges de la mateixa persona a la mateixa ciutat amb la
mateixa data dinici
Inf. derivada:
- nmv: s el nombre de viatges confirmats daquella Persona
- T-pressupostats: s igual al conjunt de viatges pressupostats duna Persona
Suposicions:
121 121
Operaci: qui? (nom-c: String, nom-h: String, out ll-per: Llista-noms) (No es modifica)
Semntica: Retorna llista de noms de persones que shan allotjat alguna vegada a lhotel nom-h
de la ciutat nom-c.
Postcondicions:
1. Si lhotel nom-h no s de la ciutat nom-c o b no hi cap persona que shi hagi allotjat, llavors
operaci invlida i es retorna Fals
2. En cas contrari, operaci vlida, es retorna Cert I la llista que cont els noms de totes les
persones que shan allotjat alguna vegada a lhotel.
Normalitzaci: Contracte normalitzat
qui?
Normalitzaci: Contracte normalitzat
confirmar-mar
Operaci: confirmar-mar (dni: Integer, nom-c: String, data: Date, nom-h: String)
Postcondicions:
1.1 La ciutat nom-c no s de mar
1.2 No existeix un viatge de la persona a la ciutat per a la data especificats
1.4 Ja existeix un viatge confirmat de la persona i data especificats
2.2 Es crea una nova ocurrncia de lassociaci Amb entre el viatge confirmat i lHotel
2.3 Si el viatge era Pressupostat, selimina la instncia de lassociaci T-pressupostat entre
Pressupostat i Persona
122 122
Aplicaci del Patr Estat
*
Ciutat
nom: String
*
*
Mar
{incomplete}
0..1
*
Amb
Hotel
nom: String
*
1
De
T-pressupostats
1
inici
Data
data: Date
*
Viatge
Pressupostat
preu: Import
Reservat
avan: Import
Confirmat
Persona
dni: Integer
nom: String
mmv(): Integer
1
1
1
Viatge-Ciutat
Viatge-Data
Viatge-Pers
Estat
estat 1
1
Supsits en l aplicaci del Patr Estat
- Objectes estat no compartits
- Transicions destat definides als objectes estat
- Creaci i destrucci dobjectes estat quan calgui
Suposicions:
Aplicaci del Patr Controlador
Transacci
executar()
Allotjats
nom-c: String
nom-h: String
ll-per: Llista-noms
resultat: Boolean
executar()
resultat(): Boolean
noms(): Llista-noms
Confirmar-Mar
dni: Integer
nom-c: String
data: Date
nom-h: String
resultat: Boolean
executar()
resultat(): Boolean
confirmar-mar (dni: Inmteger, nom-c: String, data: Date,
nom-h: String): Boolean
qui? (nom-c: String, nom-h: String,
out ll-per: Llista-noms): Boolean
123 123
Operaci: qui? (nom-c: String, nom-h: String, out ll-per: llista-noms)
Semntica: Retorna llista de noms de persones que shan allotjat alguna
vegada a lhotel nom-h de la ciutat nom-c.
Postcondicions:
1. En els segents casos, operaci invlida i es retorna fals:
1.1 Si lhotel nom-h no s de la ciutat nom-c
1.2 o b si no hi cap persona que shi hagi allotjat
2. En cas contrari, operaci vlida, es retorna Cert i la llista que cont els
noms de totes les persones que shan allotjat alguna vegada a lhotel
Aplicaci Patr Expert
qui? (nom-c, nom-h, out ll-per)
Experts
DicHotels
Allotjats, Hotel
Allotjats, Hotel
Diagrama Seqncia
confirmat-a(h)
:Estat
fals
:Allotjats
executar()
dicHotel:Diccionari
get(nom-c+nom-h)
existeix
hotel?
:Mar
viatges-a(h)
first()
:Iterador
is_done()
current_item()
:Viatge
next()
*
viatges()
:Estat
confirmat-a(h)
confirmat-a(h)
h:Hotel
qui()
:Persona
nom?()
Llista-noms
Llista-noms
Comprovar si
llista buida
String
confirmat-a(h)
:Confirmat
amb()
= h?
No s
necessari
explicitar-la
Boolean
acumular nom a una llista
124 124
Diagrama Seqncia (alternativa)
Modificant el patr Estat, definint la navegabilitat de lassociaci entre Viatge i
Estat doble, es pot definir loperaci qui? duna forma ms eficient.
:Allotjats
executar()
dicHotel:Diccionari
get(nom-c+nom-h)
existeix hotel?
first()
:Iterador
is_done()
current_item()
next()
*
confirmats()
viatger()
h:Hotel
qui()
:Persona
nom?()
Llista-noms
Comprovar si
llista buida
String
acumular nom a una llista
:Viatge
viatger()
String
:Confirmat
obtenir el viatge obtenir la persona
Aplicaci Patr Expert
confirmar-mar (dni, nom-c, data, nom-h)
Operaci: confirmar-mar (dni: Enter, nom-c: String, data: Dia, nom-h: String)
Postcondicions:
1.1 Si la ciutat nom-c no s de mar
1.2 Si no existeix un viatge de la persona a la ciutat per a la data
especificats
1.4 Ja existeix un viatge confirmat de la persona i data especificats
2.2 Es crea una nova ocurrncia de lassociaci Amb entre el viatge
confirmat i lHotel
2.3 Si el viatge era Pressupostat, selimina lassociaci T-
pressupostat amb Persona
Experts
Ciutat, dicMar
dicViatges
dicHotels
Persona, dicConfirmats
Estat + Viatge
Confirmat + Hotel
Pressupostat + Persona
125 125
Diagrama Seqncia (I)
confirmar-mar(dni, nom-c, data, nom-h)
:Confirmar-mar
executar()
existeix viatge?
dicViatge:Diccionari
get(dni+nom-c+data)
dicHotel:Diccionari
get(nom-c+nom-h)
:Persona
t-confirmats?(data)
first()
:Iterador
is_done()
current_item()
:Viatge
next()
*
viatges()
Boolean
:Estat
confirmat-en(data)
data?(data)
:Data
confirmat?()
v:Viatge
confirmar(h, data)
:Estat
confirmar(v, h)
si existeix hotel (h),
llavors est a la
ciutat i, aquesta s
de mar
Boolean
Boolean
Comprova si ja t
viatges confirmats
en la data
Comprova si s un
viatge confirmats en
la data
Compara atribut
data amb valor
parmetre
Comrova
estat
confirmat
Fa canvi destat
Diagrama Seqncia (II)
e:Confirmat
associarAmb(h)
creassocAmb(e)
h:Hotel
modifassocEstat(e)
v:Viatge
nouconfirmat(v, h)
:Estat
confirmat?()
:Confirmat
cert
confirmat?()
:Estat
fals
:Persona
eliminaTePres(e)
e:Pressupostat
confirmar(v, h)
nouconfirmat(v, h)
cert
:Reservat
confirmar(v, h)
nouconfirmat(v, h)
cert
confirmar(v, h)
:Confirmat
fals
126 126
Diagrama Seqncia (I) (alternativa)
La restricci Una persona no pot tenir ms dun viatge confirmat amb la mateixa
data dinici permet identificar els viatges confirmats amb (dni+data).
:Confirmar-mar
executar()
existeix viatge?
dicViatge:Diccionari
get(dni+nom-c+data)
dicHotel:Diccionari
get(nom-c+nom-h)
v:Viatge
confirmar(h, dni, data)
:Estat
confirmar(v, h)
si existeix hotel (h),
llavors est a la
ciutat i, aquesta s
de mar
Boolean
Mateixa operaci
que abans
dicConfirmats:Diccionari
get(dni+data)
Comprova no existeix cap objecte
estat Confirmat
Diagrama Seqncia (II) (alternativa)
:Persona
eliminaTePres(e)
e:Pressupostat
confirmar(v, h)
nouconfirmat(v, h)
cert
:Reservat
confirmar(v, h)
nouconfirmat(v, h)
cert
confirmar(v, h)
:Confirmat
fals
e:Confirmat
associarAmb(h)
creassocAmb(e)
h:Hotel
modifassocEstat(e)
v:Viatge
nouconfirmat(v, h)
:Estat
modificar associaci amb Viatge
127 127
Diagrama de Classes de Disseny
*
*
Mar
{incompl ete}
0..1
*
Amb
*
1
De
T-pressupostats
1
inici
*
Persona
dni: Integer
nom: String
mmv(): Integer
t-confirmats(data: Date): Boolean
viatges(): Iterador
eliminaTPres(e:Pressupostat)
nom?(): String
1
1
1
Viatge-Ciutat
Viatge-Data
Viatge-Pers
estat
1
1
Data
data: Date
data?(data:Date): Boolean
Ciutat
nom: String
viatges(): Iterador
viatges-a(h:Hotel): Llista-noms
Viatge
confirmat-en(data:Date): Boolean
confirmar(h:Hotel, data:Date):Boolean
modifassocEstat(e:Estat)
confirmat-a(h:Hotel): String
Estat
confirmat?():Boolean
confirmar(v:Viatge, h:Hotel):Boolean
nouconfirmat(v:Viatge, h:Hotel)
confirmat-a(h:Hotel): Boolean
*
Pressupostat
preu: Import
Reservat
avan: Import
Confirmat
associarAmb(h:Hotel)
amb(): Hotel
confirmat-a(h:Hotel): Boolean
confirmat?():Boolean
Hotel
nom: String
qui(): Llista-noms
crearassocAmb(e:Confirmat)
Transacci
executar()
Allotjats
nom-c: String
nom-h: String
ll-per: Llista-noms
resultat: Boolean
executar()
resultat(): Boolean
noms(): Llista-noms
Confirmar-Mar
dni: Integer
nom-c: String
data: Date
nom-h: String
resultat: Boolean
executar()
resultat(): Boolean
Diagrama de Classes de Disseny (alternativa)
*
*
*
Mar
{incompl ete}
0..1
*
Amb
*
1
De
T-pressupostats
1
inici
*
Persona
dni: Integer
nom: String
mmv(): Integer
eliminaTPres(e:Pressupostat)
nom?(): String
1
1
1
Viatge-Ciutat
Viatge-Data
Viatge-Pers
estat
1
1
Data
data: Date
Ciutat
nom: String
Viatge
confirmar(h:Hotel, dni:Integer, data:Date):Boolean
modifassocEstat(e:Estat)
viatger(): String
Estat
nouconfirmat(v:Viatge, h:Hotel)
viatger(): String
Pressupostat
preu: Import
Reservat
avan: Import
Confirmat
associarAmb(h:Hotel)
Hotel
nom: String
qui(): Llista-noms
crearassocAmb(e:Confirmat)
confirmats(): Iterador
Transacci
executar()
Allotjats
nom-c: String
nom-h: String
ll-per: Llista-noms
resultat: Boolean
executar()
resultat(): Boolean
noms(): Llista-noms
Confirmar-Mar
dni: Integer
nom-c: String
data: Date
nom-h: String
resultat: Boolean
executar()
resultat(): Boolean
La navegabilitat de les
associacions Viatge-Data, Viatge-
Ciutat i De, no queden definides
pels diagrames de seqncia.
128 128
Disseny de la Capa Presentaci: Introducci 1
Capa Presentaci
Introducci
Patr Model-Vista-Controlador
Introducci
Qu s i qu inclou la Capa Presentaci
Disseny de la Capa Presentaci:
Disseny Extern
Disseny Intern
Punt de Partida
Bibliografia
129 129
Capa Presentaci: s el component del sistema software encarregat de
gestionar la interacci amb lusuari.
......
Domini
Presentaci
S'assabenta peticions
Ordena execuci accions
Comunica resultats accions
Tractament de:
Finestres, Mens
Botons, Llistats
esdeveniments
presentaci
consultes
resultats
respostes
La interacci home-mquina consisteix en:
Lusuari t un objectiu i un pla dacci.
Lusuari tradueix aquest pla amb accions concretes sobre la interfcie del
sistema software.
El sistema processa els inputs rebuts. Aquest processament consisteix en
accedir, calcular i donar format a les dades.
A cada input rebut, el sistema respon presentant el resultat de les accions i
encaminant lusuari a la segent acci.
La Capa Presentaci inclou els elements necessaris per a:
rebre les ordres o peticions de lusuari
mostrar a lusuari el resultat daquestes peticions
resoldre o coordinar la resoluci de les peticions amb collaboraci de la
Capa Domini
Interfcies:
Lnies de comandes: Sistema porta el control
GUI (Basades en Esdeveniments): Usuari porta el control
130 130
Disseny de la Capa Presentaci
Disseny Capa Presentaci s un procs, incls en letapa de disseny dun
sistema software, encarregat de definir:
com lusuari interacciona amb el sistema software (Disseny Extern)
com la Capa Presentaci interacciona amb la Capa Domini (Disseny Intern)
Punt de partida pel disseny de la Capa Presentaci:
Caracterstiques tecnolgiques perifrics entrada (teclat, ratol, ...) i perifrics
sortida (pantalla, impressora, ...)
Anlisi dusuaris i tasques Casos ds
Procs de disseny basat en el prototipatge
Equip de dissenyadors:
Coneixement del domini del sistema participaci usuari final
Coneixements en orientaci a objectes programadors
Coneixements en sociologia, psicologia i fisiologia psiclegs, ...
Coneixements en medis presentaci informaci dissenyadors grfics, ...
Disseny Extern
Disseny Extern (de la Capa Presentaci) consisteix en el disseny
dels elements (tangibles) que lusuari veu, sent i toca al
interaccionar amb el sistema.
El disseny extern consisteix en la definici de:
Mecanismes com lusuari pot demanar peticions al sistema
Mecanismes dinteracci
Formes com es poden mostrar els resultats daquestes peticions a
lusuari Presentaci de la informaci
Exemples:
Mecanismes interacci: escriure comandes, tecles funci, apuntar
objectes/mens amb ratol o pantalla tctil, comandes orals ...
Presentaci de informaci: formats grfics, imatges, textual, vdeo;
presentaci a pantalla o en llistat imprs; ...
131 131
Disseny Extern: Mecanismes dinteracci
Principis bsics pel disseny de la interacci amb el sistema:
Integritat conceptual en la interacci (seqncia daccions, abreviatures, ...)
Mnim nombre daccions a realitzar (selecci en lloc dintroducci de dades,
evitar introducci dades redundants, ...)
Memria a curt termini usuari mnima (no cal recordar llistes de codis o
comandes complexes, ...)
Compatibilitat entre presentaci informaci i dades introdudes (format
entrada dades similar al de presentaci, ...)
Flexibilitat en la introducci de dades per part de lusuari (permetre entrada
dades en una seqncia diferent per a usuaris experts, ...)
Donar resposta a cada requesta de lusuari.
Principis bsics pel disseny de la presentaci dinformaci:
Integritat conceptual en la presentaci (formats, colors, terminologia, ...)
Assimilaci eficient de la informaci per part de lusuari (format de
presentaci familiar a lusuari)
Memria a curt termini usuari mnima (no cal recordar informaci de
pantalles anteriors)
Compatibilitat entre presentaci informaci i dades introdudes (mateixos
camps dentrada i sortida)
Flexibilitat per controlar la presentaci dinformaci per part de lusuari
(permetre canvis en formats, ordre, ...)
Missatges derror clars, informatius i orientatius.
Disseny Extern: Presentaci de la Informaci
132 132
Disseny Intern
Disseny Intern (de la Capa Presentaci) consisteix en dissenyar els
mecanismes que recullen, processen i donen resposta a les requestes
de lusuari.
El disseny intern i disseny extern es realitzen en parallel o
iterativament.
En una arquitectura lgica en tres capes cal definir, a ms a ms, la
comunicaci entre Capa Presentaci i Capa Domini.
Disseny Intern =>
Disseny mecanismes gestionen la Interacci
Disseny mecanismes permeten Presentaci Informaci
Disseny mecanismes de comunicaci Capa Presentaci i Capa Domini
Estructura lgica de la
Capa Presentaci (GUI):
Disseny Intern
Manipulador dEsdeveniments de Presentaci
Comunicaci amb Capa Domini
Gesti Interacci
amb Usuari
Presentaci
Informaci
Capa Domini
esdeveniments de presentaci
esdeveniments de sistema
Capa
Presentaci
133 133
Disseny Intern
Interfcies dUsuari Grfiques (GUI) basades en esdeveniments.
Com es comuniquen aquests esdeveniments a la Capa Presentaci?.
Comunicaci del sistema software amb el sistema operatiu.
Gesti Interacci amb Usuari
Controlar la recepci desdeveniments de presentaci del manipulador.
Processar aquests esdeveniments i generar esdeveniments de sistema als
objectes que els han de processar.
Presentaci Informaci
Recepci de les dades a presentar a lusuari (pantalla, impressora).
Presentaci de les dades en els formats especfics de lusuari.
Enviar esdeveniments de sistema a processar.
Rebre respostes a aquests esdeveniments.
Disseny Intern
Gesti dEsdeveniments
Gesti Interacci amb Usuari
Presentaci Informaci
Patr Observador
Event Delegation Model de JAVA 1.1
134 134
Punt de Partida
Descripci dels Casos ds.
Cal adaptar-los al disseny (de pantalles i finestres) definits durant el
Disseny Extern.
Cas ds : Admetre Soci
Actor: Administrador
Objectiu: Admetre un soci I els seus familiars com a
membres del club.
Descripci General: . . .
Seqncia desdeveniments:
Acci Resposta
1. Introduir nom, adrea i e-mail del soci 2. Se li assigna nmero de soci
3. Es dna d alta com a nou soci
4. Introduir numero de compte on carregar
pagament de rebuts.
5. Es guarda el compte on carregar rebuts
6. Introducci nom, adrea i e-mail dels familiars
7. Es donen d alta els seus familiars
Punt de Partida: Disseny Extern
Numero Compte Corrent
endavant plega
Assignaci Compte
D
Nom
adrea
e-mail
endavant plega
Alta de soci
A
B
C
Numero Soci
Ok
Nmero de Soci
135 135
Punt de Partida: Cas ds dissenyat
Cas ds : Admetre Soci
. . .
Acci Resposta
1.1. Ladministrador introdueix el nom del soci a A
i introdueix ladrea a B. En cas de tenir una adrea
E-mail, aquesta sintrodueix a C.
1.2. Si es vol donar dalta aquest nou soci, cal pitjar
el bot Endavant. En cas de voler cancelar lalta,
cal prmer el bot Plegar. El bot Plegar, finalitza
la admissi dun soci.
2.1. El sistema genera un nou nmero de
soci que guarda amb les dades anteriors.
2.2. El sistema mostra el nmero de soci en
una finestra auxiliar.
1.3. Cal prmer el bot Ok per continuar amb
ladmissi del soci.
3.1 Es dona d alta com a nou soci
3.2. Apareix la finestra Assignar Compte
Corrent.
4.1. En aquesta finestra ladministrador introduir el
compte corrent a (D), on cobrar els rebuts pendents.
Si es prem, el bot Plegar, es retorna a la finestra
anterior per a donar dalta un nou soci.
. . . .
Bibliografia
Collins, D.
Designing Object-Oriented User Interfaces.
Benjamin/Cummings Publishing Company, 1995.
(Cap. 1, 5, 6, 11)
Shneiderman, B.
Designing the User Interface.
Strategies for Effective Human-Computer Interaction (3 edici).
Addison-Wesley, 1998. (Cap. 2)
Larman, C.
An Introduction to Object-Oriented Analysis and Design.
Prentice Hall, 1998. (Cap. 16)
136 136
Disseny de la Capa Presentaci: Patr Model-Vista-Controlador 1
Descripci General
Soluci: Estructura
Comportament
Conseqncies
Implementaci
Exemple
Bibliografia
Descripci General (I)
Context:
Sistemes software interactius amb interfcies dusuari flexibles.
Problema:
La informaci proporcionada pel sistema software i el seu comportament han de
reflectir immediatament les manipulacions de la informaci.
Pot interessar mostrar la mateixa informaci a diverses finestres en diferents
formats.
Shauria de poder canviar la interfcie dusuari quan el sistema software ja est
implantat sense que aix afects el codi del nucli del sistema.
El Patr Model-Vista-Controlador s un patr arquitectnic
137 137
Descripci General (II)
Soluci:
Descomposar el sistema en tres components:
Model (procs): inclou la implementaci de les funcionalitats i les dades
del sistema.
Vista (sortida): mostra la informaci a lusuari final
Controlador (entrada): responsable de gestionar la interacci amb lusuari
La Capa de Presentaci inclou els components:
Vista: presentaci dinformaci
Controlador: mecanisme dinteracci
El Model representa la Capa de Domini (i Gesti de Dades) del sistema
Soluci: estructura esttica
Observador
actualitzar
*
Model
dades
afegir(observador)
treure(observador)
notificar()
obtenirDades()
servei()
Vista
inicialitzar (model)
ferControlador()
activar()
actualitzar()
mostrar()
Controlador
inicialitzar(model, vista)
tractarEsdev (esdev.)
actualitzar()
1 1
1
Amb
T
En general, hi ha tantes parell es Vista-Controlador com informacions i formats
diferents es vulguin mostrar dun model determinat.
Les operacions actualitzar (dels controladors), mostrar i tractarEsdev
sacostumen a redefinir a les subclasses de vista i controlador que es defineixin
per a un model determinat
138 138
Descripci General: Model
Model:
Encapsula les funcionalitats i les dades del sistema.
s independent dels mecanismes de presentaci dinformaci i dinteracci
amb lusuari.
Proporciona al Controlador els serveis per satisfer les peticions de lusuari.
Mant un mecanisme de coordinaci amb les Vistes i Controladors associats
(patr Observador), per notificar-los qualsevol canvi en el seu estat.
Model
...
afegir(observador)
treure(observador)
notificar()
obtenirDades()
servei()
Afegir i treure permeten gestionar observadors associats
Notifica als observadors que s han produt
canvis en lestat del Model
Permet a la Vista i al Controlador obtenir dades modificades
del Model (1 operaci per cada tipus dinformaci a presentar)
Implementa les funcionalitats del sistema que pot invocar
el Controlador (1 operaci per cada funcionalitat)
Descripci General: Controlador
Controlador:
Lusuari interactua amb el sistema nicament mitjanant controladors
Gestiona els esdeveniments de presentaci i de modificaci del model
generats per lusuari.
La forma com rep aquests esdeveniments depn de la plataforma utilitzada
per interactuar amb lusuari (Manipulador desdeveniments).
Tradueix els esdeveniments de presentaci en:
invocacions a serveis proporcionats pel Model.
peticions de funcionalitats prpies de la Vista.
El comportament del Controlador pot dependre de lestat del Model.
associa el controlador a la Vista i al Model
rep un esdeveniment
el valor del parmetre determina la funcionalitat a tractar
actualitza el comportament del controlador
Controlador
inicialitzar (model, vista)
actualitzar()
139 139
Descripci General: Vista
Vista:
Permet presentar informaci del model a lusuari. Hi pot haver diverses vistes
dun mateix model.
La informaci que mostra es pot veure afectada per canvis en lestat del Model.
T associat un Controlador que gestiona, si sescau, els esdeveniments de
modificaci del Model.
Pot proporcionar operacions que permeten que els controladors gestionar la
modificaci del display (paginaci, moure finestra, iconificar, ...).
Vista
inicialitzar(model)
ferControlador()
activar()
actualitzar()
mostrar()
...
associa el Model a la Vista
mostra dades a pantalla
actualitza el contingut de la Vista
permet activar la Vista
crea el Controlador associat a aquesta Vista
operacions de presentaci de la informaci a la pantalla
Comportament: inicialitzaci del patr MVC
:Main
m:Model
v:Vista
inicialitzar(m)
ferControlador
afegir(v)
c:Controlador
inicialitzar(m,v)
afegir(c)
A partir daqu ja es poden comenar a
tractar els esdeveniments
...
Inicialitzar el patr MVC suposa associar
estti cament un model amb les seves
vistes i controladors.
140 140
Comportament: gesti dun esdeveniment (I)
:Controlador :Model
tractarEsdev(servei)
servei
<- Capa Presentaci
...
es realitzen les accions
necessries a la capa de domini
per efectuar el servei
tantes operacions servei com
esdeveniments tracti el sistema
notificar
:Iterador
tots-obs
actualitzar
:Observador
first
isDone
currentItem
next
*
<- Capa Domini -> Capa Presentaci ->
Comportament: gesti dun esdeveniment (II)
:Controlador
:Model
actualitzar
obtenirDades
:Vista
actualitzar
mostrar
:Model
obtenirDades
- Obt la informaci del model, rellevant
a la vista i al controlador
- No t perqu ser la mateixa informaci
i, aleshores, no ser la mateixa operaci
Actualitzaci dels observadors:
Si el controlador modifica el comportament
141 141
Conseqncies
Beneficis:
Es poden tenir diverses Vistes associades a un mateix Model.
En temps dexecuci puc tenir diverses vistes obertes.
Les Vistes i Controladors estan sincronitzats davant canvis en el Model.
Fcil reutilitzaci de Vistes i Controladors.
Alta portabilitat de la Capa Presentaci.
Acoblament baix entre Capa Domini i Capa Presentaci.
Inconvenients:
Afegeix complexitat a sistemes amb interfcies simples.
Alt acoblament entre Vista i Controlador.
No hi ha encapsulament de dades depenents de la plataforma grfica, per
facilitar portabilitat.
Variants al Patr:
Patr Presentaci-Abstracci-Control.
Patr Document-Vista.
Aspectes a considerar
Canvis freqents en lestat del Model poden comportar actualitzacions
innecessries a vistes (inactives o iconificades) i reduir-ne leficincia.
En sistemes amb ms duna vista oberta, hi haur diversos controladors
actius. Els esdeveniments rebuts han de transmetres als controladors
en un ordre especfic (Patr Cadena de Responsabilitats).
Definici de Vistes i Controladors com a especialitzacions daltres
permet la reutilitzaci, herncia i redefinici doperacions.
142 142
Exemple: deute total del club de tennis
Diagrama de classes de disseny (inicial)
- Es vol visualitzar contnuament per pantalla el deute total del club de tennis
- El deute total del club de tennis es modifica mitjanant ferRebuts i pagRebut
- El comportament del controlador no depn de lestat del model
Soci
nmSoci: Integer
deute?(): Import
Crrec
data: Date
import: Import
desc.: String
Rebut
mesEmissi: Mes
import: Import
pagat: Boolean
T * * 1 0..1
A
Club
tot-deute: Import
1
Correspon
*
1
CompteCorrent
nmcc: Date
saldo: Import
Del
1
*
Exemple: estructura MVC
Observador
actualitzar
*
Model
afegir(observador)
treure(observador)
notificar()
tot-deute?(): Import
pagRebut(nmSoci,mes)
ferRebuts(data)
Vista
inicialitzar (model)
ferControlador()
activar()
actualitzar()
mostrar()
Controlador
inicialitzar(model, vista)
actualitzar()
1 1
1
Amb
T
Club
tot-deute: Import
pagRebut (nmSoci,mes)
ferRebuts (data)
1 ContTotalDeute
VistaTotalDeute
mostrar()
set-text(imp)
operaci de presentaci dinformaci
serveis oferts pel model
correspon a obtenirDades
op. ganxo
esdev pot ser
pagarRebut o ferRebut
Com que noms hi ha un model, una vista i un
controlador, les jerarquies es podrien col.lapsar
143 143
Exemple: inicialitzaci del MVC
:Main
c:Club
v:VistaTotalDeute
inicialitzar(c)
ferControlador
afegir(v)
ctr:ContTotalDeute
inicialitzar(c,v)
afegir(ctr)
A partir daqu ja es poden comenar a
tractar els esdeveniments
...
Exemple: gesti de pagRebut (I)
ctr:ContTotalDeute c:Club
:Rebut
tractarEsdev
(pagRebut(nmSoci,mes))
pagRebut
(nmSoci,mes)
dicReb:diccionari
get
:Soci
pagar
pagar-reb
notificar
Capa Domini -> <- Capa Presentaci
:CC
dec-saldo
dec-deute
boole
boole boole
latribut pagat es posa a cert
144 144
Exemple: gesti de pagRebut (II)
:Club
:Iterador
tots-obs
notificar
actualitzar
:Observador
first
isDone
currentItem
next
*
Capa Domini -> Capa Presentaci ->
Notificaci als observadors, un cop
shan dut a terme els canvis del model
provocats per pagRebut
Exemple: gesti de pagRebut (III)
:Controlador
:VistaTotalDeute
actualitzar
actualitzar
mostrar :Club
tot-deute?
op. ganxo: no fa res perqu el comportament
del controlador no depn de l estat del model
set-text
modifica, a la pantalla, el valor de l import
corresponent al deute total del club
Actualitzaci del contingut del s observadors
145 145
Exemple: diagrama de classes resultant
Soci
nmSoci: Integer
deute?(): Import
pagar-reb(imp): Bool
Crrec
data: Date
import: Import
desc.: String
Rebut
mesEmissi: Mes
import: Import
pagat: Boolean
T *
*
1
0..1
A
Club
tot-deute: Import
1
Correspon
*
1
CompteCorrent
nmcc: Date
saldo: Import
Del
1
*
pagar(): Bool
tots-obs(): Iterador
dec-deute(import)
pagRebut(nmSoci,mes): Bool.
ferRebuts(data)
dec-saldo(import): Bool
...
Bibliografia
Pattern-ori ented Software Architecture. A System of patterns.
John Wiley & Sons, 1996.
146 146
Disseny de la Capa de Gesti de Dades: Persistncia en BDOO. 1
Persistncia en BDOO
Qu s i com saconsegueix la persistncia?.
Antecedents i arquitectura dun SGBDOO.
Model dObjectes i llenguatges despecificaci dobjectes (ODL).
Llenguatge de consulta dobjectes (OQL).
Java binding.
Bibliografia
Qu s i com saconsegueix la persistncia?
Persistncia: s la capacitat que molts sistemes software requereixen per
emmagatzemar i obtenir dades usant un sistema demmagatzemament
permanent.
Els objectes es poden fer persistents en:
BDOO.
BDR.
Altres.
147 147
Antecedents i arquitectura dun SGBDOO
Proposta dun estndar per BDOO
ODMG (Object Database Management Group): s un grup de
persones, membres dempreses (JavaSoft, Windward Solution,
UniSQL, ...), que proposen un estndar per treballar amb sistemes de
gesti de Base de Dades Orientades a Objectes.
Objectiu de lestndard:
Portabilitat
Sistemes de gesti de base de dades orientades a objectes:
ObjectStore
O2
. . .
Comparaci amb un SGBDR
Estructures de dades
de laplicaci
Transparncia
de dades
Representaci
relacional
Cpia i traducci
SGBDR
148 148
Arquitectura dun SGBDOO
Model dobjectes: s el model de dades com suportat per tots els
SGBDOO.
Llenguatge despecificaci dobjectes (ODL): llenguatge de definici dels
objectes.
Llenguatge de consulta dobjectes (OQL): llenguatge declaratiu per fer
consultes i modificacions dels objectes de la BD.
Java binding: defineix el lligam entre el model dobjectes i el llenguatge
de programaci Java.
Arquitectura dun SGBDOO
Declaracions en
ODL o PL ODL
Codi font de
laplicaci en PL
Compilador PL
Aplicaci
binari
Linkador
Aplicaci
executable
Preprocessador
declaracions
SGBDOO
Runtime
Base de
dades
metadades
accs dades
149 149
Model dObjecte: Qu s el Model dObjectes?
El model dobjectes especifica el tipus de semntica que pot definir
explcitament un SGBDOO.
Les construccions suportades pel model dobjecte sn:
Objecte i Literal
Tipus
Estat dun objecte
Comportament de lobjecte
BD
Transaccions
Llenguatge despecificaci dobjectes (ODL)
ODL s un llenguatge despecificaci utilitzat per definir les
especificacions del tipus dobjectes que constitueixen el Model
dObjectes de ODMG.
Principis que han guiat al desenvolupament del ODL:
ha de suportar totes les construccions semntiques del model
dobjectes.
no ha de ser un llenguatge de programaci sencer complet, per si
un llenguatge de definci.
ha de ser un llenguatge de programaci independent.
ha de ser extensible.
ha de ser prctic.
150 150
Model dObjectes: Objecte
Creaci dobjectes:
En ODL:
Identificador dels objectes: sn generats pel SGBDOO. El domini s la
BD.
Nom dels objectes: Els SGBDOO proporcionen funcions que retornen
lobjecte a partir del nom. Lmbit del nom s la BD.
Vida dels objectes:
Transitria
Permanent
interface ObjectFactory {
Object new();
};
interface Object {
enum Lock_Type{read,write,upgrade};
exception LockNotGranted{};
void lock(in Lock_Type mode) raises (LockNotGranted)
boolean try_lock(in Lock_Type mode);
boolean same_as(in Object anObject);
Object Copy();
void delete();
}; tots els objectes tenen una interfcie
en ODL, que es heretada implcitament
a les definicions dobjectes dels usuaris
tots els objectes sn creats per la invocaci
doperacions de creaci que hi ha en els
objectes fbrica proporcionats pels llenguatges
Model dObjectes: Objecte i Literal
El model dobjectes suporta:
Col.leccions dobjectes i literals:
En ODL: Set<t>, Bag<t>, List<t>, Array<t>, Dictionary<t,v>
Objectes i literals estructurats:
En ODL: Date, Interval, Time, Timestamp
Literals atmics:
En ODL: long, short, unsigned long, unsigned short, float, double, boolean,
octet, char, string, enum
Literals nulls:
En ODL: nullable_float, nullable_set,...
151 151
Model dObjectes: Tipus
Un tipus pot tenir una definici externa i una o ms implementacions.
La definici dinterfcie s una especificaci que defineix el comportament
abstracte dun tipus dobjecte.
En ODL: interface Empleat{...}
La definici de classe s una especificaci que defineix el comportament
abstracte i lestat abstracte dun tipus dobjecte.
En ODL: class Persona{...}
La definici de literal fa noms referncia a lestat abstracte dun tipus
dobjecte.
En ODL: struct Complex{float re; float im}
Herncia del comportament:
En ODL: interface Empleat{...} interface Empleat_fix: Empleat {...}
Herncia de lestat i comportament:
En ODL: class Persona{...}
class Persona_empleada extends Persona{...}: Empleat
Extents: conjunt de totes les instncies dun tipus en una BD concreta.
En ODL: class Persona (extent persones) {...}
Key: instncies individuals poden ser identificades pels valors de les
propietats. Lmbit de la clau s lextent.
Atributs: defineixen un estat abstracte dun tipus.
En ODL:
Relacions: es defineixen entre tipus i noms poden ser binries.
En ODL:
1:1
1:n
m:n
Model dObjectes: Estat dun objecte
interface Professor{
relationship curs ensenya
inverse curs::es_ensenyat_per;
};
interface Curs{
relationship professor es_ensenyat_per
inverse professor::ensenya;
};
relationship set<curs> ensenya
};
interface Curs{
relationship professor
es_ensenyat_per
};
interface Curs{
relationship set<professor> es_ensenyat_per
};
relationship set<curs> ensenya
};
class Persona{
attribute short age;
};
El SGBDOO mant la integritat
referencial de les relacions.
152 152
Model dObjectes: Comportament dun objecte
Operacions (signatura): defineixen el nom de loperaci, el nom i tipus
de cada argument, el tipus de o dels valors que retornen i el nom de les
excepcions.
Model Excepcions: representen operacions que poden donar
excepcions i comunicar resultats.
En ODL:
void acomiadar() raises (no_s_un_empleat)
Model dObjectes: BD
Cada BD s una instncia del tipus Database, proporcionat pel
SGBDOO.
interface DatabaseFactory {
Database new();
};
interface Database {
void open(in string database_name);
void close();
void bind(in any an_object, in string name);
Object unbind(in string name);
Object lookup(in string object_name);
Module schema();
};
153 153
Model dObjectes: Transaccions
Hi ha dos tipus definits per suportar lactivitat transaccional en un
SGBDOO.
interface TransactionFactory {
Transaction new();
Transaction current();
};
interface Transaction {
exception TransactionInProgress{};
exception TransactionNotInProgress{};
void begin() raises (TransactionInProgress);
void commit() raises(TransactionNotInProgress);
void abort() raises (TransactionNotInProgress);
void checkpoint() raises (TransactionNotInProgress);
void join();
void leave();
boolean isOpen();
};
Model dObjectes: Exemple
Persona
dni:String
nom: String
adrea: String
Soci
numSoci: Integer
deute():Import
afegirFamiliar(..)
hihaFamiliar(nom:
String):Boolean
Familiar 1 *
class Persona
(extent Persones
key dni)
{
attribute string dni;
attribute string nom;
attribute string adrea;
attribute string e-mail;
};
class Soci extends Persona
{
attribute short numSoci;
relationship set<Familiar> familiars
inverse Familiar::soci;
short deute();
void afegirFamiliar (in string nom, in string adrea, in
string e-mail) raises (familiar_ja_existeix);
boolean hihaFamiliar(in string nom);
};
poblaci de Persones
clau de Persona
navegabilitat
doble
herncia de lestat
i comportament
operaci amb
excepcions
class Familiar extends Persona
{
relationship soci
inverse Soci::familiars;
};
154 154
Llenguatge de consulta dobjectes (OQL)
El disseny del llenguatge (OQL) est basat en els segents principis:
Est basat en el Model Objecte de ODMG.
Molt semblant a SQL92.
Proporciona primitives dalt nivell per treballar amb col.leccions.
Es un llenguatge funcional on els operadors es poden composar.
Proporciona un accs fcil a un SGBDOO.
Pot ser invocat des doperacions escrites en altres llenguatges i al contrari.
No t operadors dactualitzaci, sino que utilitza els mtodes dels objectes.
Proporciona un accs declaratiu als objectes.
La semntica formal pot ser fcilment definida.
Llenguatge de consulta dobjectes (OQL): Exemple
Exemples de consultes en OQL
typedef set<string> vectad;
vectad (select distinct adrea
from Persones
where nom=Pep)
typedef bag<soci> socs;
socs( select distinct soci(a:nom,b:adrea,c:e-mail)
from Persones
where nom=Pep)
155 155
Java binding
Principis de disseny del llenguatge:
Principi bsic:
El programador ha de veure el lligam com un llenguatge nic per expressar
operacions de la BD i de laplicaci.
Corol.laris:
Hi ha noms un nic sistema compartit pel llenguatge Java i la base de
dades dobjectes.
El lligam respecta la sintaxi de Java.
Els objectes es convertiran en persistents quan siguin referenciats per
altres objectes persistents de la BD (persistncia per referncia).
El Java binding proporciona :
Un Model Objecte comparable amb el Model Objecte proposat per ODMG.
Java ODL
Java OML
Java OQL
Java binding: Model Objecte
El Model Objecte de Java suporta totes les caracterstiques del Model
Objecte de ODMG excepte:
Relacions.
Extents.
Claus.
No hi ha literals estructurats.
156 156
Java binding: Java ODL i Java OML
Java ODL ens permet descriure lesquema de la BD com un
conjunt de classes Java utilitzant sintaxi Java a excepci dels
elements que no suporta el Model Objecte de Java.
Java OML s la sintaxi utilitzada per crear, esborrar, identificar,
referenciar, obtenir i modificar valors i invocar mtodes
dobjectes persistents. Totes les operacions de Java OML sn
invocades en els objectes Java apropiats com si fossin
objectes transitoris.
La persistncia dels objectes s per referncia.
Java binding: JavaOQL
Totes les funcionalitats de lOQL estan disponibles mitjanant Java
binding. Aquesta funcionalitat pot ser usada:
Mtodes de consulta a les classes col.lecci.
Consultes utilitzant classes OQLQuery
Collection query(String predicate)
class OQLQuery {
public OQLQuery() {}
public OQLQuery(String Query){...}
public create(String Query){...}
public bind(Object parameter){...}
public Object execute() throws ODMGException{...}
};
157 157
Java binding: Arquitectura dObjectStore
host
host host
host
host host
network
Cache Manager Cache Manager Cache Manager
Cache Manager
Client Application Client Application Client Application
Client Application
Client Application
Server
Server
disk
disk
Java binding
Exemple dutilitzaci del Java binding amb ObjectStore/1
Persona
dni:String
nom: String
adrea: String
Soci
numSoci: Integer
deute():Import
afegirFamiliar(..)
hihaFamiliar(nom:
String):Boolean
Familiar 1
*
abstract class Persona {
String nom;
String adreca;
String email;
// Constructor:
public Persona(String nom, String adreca, String email) {
this.nom = nom; this.adreca = adreca; this.email = email;
}
public String obtenir_nom() { return nom; }
public String obtenir_adreca() { return adreca; }
public String obtenir_email() { return email; }
public void posar_nom(String nom) { this.nom = nom; }
public void posar_adreca(String adreca) { this.adreca = adreca; }
public void posar_email(String email) { this.email = email; }
}
class Familiar extends Persona {
Soci s;
public Familiar(String nom, String adreca, String email,Soci s) {
super(nom,adreca,email);
this.s=s;
s.posar_familiar(this);
}
}
Definici de lesquema
158 158
Java binding
import COM.odi.*;
import COM.odi.coll.*;
class Soci extends Persona {
int numSoci;
Set familiars;
// Constructor:
public Soci(String nom, String adreca, String email,int numSoci,Placement placement) {
super(nom,adreca,email);
this.numSoci=numSoci;
familiars=NewCollection.createSet(placement) ;
}
public int obtenir_numSoci() { return numSoci; }
public void posar_familiar(Familiar f) {
familiars.insert(f);
}
}
Java binding
import COM.odi.*;
public
class Exemple {
public static void main(String argv[]) {
String dbName = argv[0];
// Aquesta linia inicialitza ObjectStore
ObjectStore.initialize(null, null);
Database db = createDatabase(dbName);
readDatabase(db);
}
static Database createDatabase(String dbName) {
// Es crea una BD cada vegada que es crida a l'aplicacio
try {
Database.open(dbName,ObjectStore.OPEN_UPDATE).destroy();
} catch (DatabaseNotFoundException e) {
}
//Crida al metode de creacio de la BD.
Database db = Database.create(dbName, ObjectStore.ALL_READ | ObjectStore.ALL_WRITE);
// Comenca una transaccio d'actualitzacio
Transaction tr = Transaction.begin(ObjectStore.UPDATE);
//Creacio dels socis
Soci pep = new Soci("Pep", "C/Balmes", "pep@lsi.upc.es",1,db);
Soci josep = new Soci("Josep", "C/Sants","josep@lsi.upc.es",2,db);
//Creacio de dos punts d'entrada a la BD
db.createRoot("Pep", pep);
db.createRoot("Josep", josep);

operaci de la classe Database
operaci de la classe Transaction
operaci de creaci dun objecte
a la BD
operaci de punts dentrada a la BD
Definici dels programes
159 159
Java binding
Familiar maria = new Familiar("Maria", "C/Balmes" , "maria@lsi.upc.es",pep);
Familiar joan = new Familiar("Joan", "C/Pelai" , "joan@lsi.upc.es",pep);
Familiar pere = new Familiar("Pere", "Rda. Universitat" , "pere@lsi.upc.es",josep);
// Final de la transaccio. Es guarden els objectes peristents a la BD.
tr.commit();
return db;
}
static void readDatabase(Database db) {
// Comena una transaccio de lectura
Transaction tr = Transaction.begin(ObjectStore.READONLY);
// Utilitzem els punts d'entrada per obtenir els objectes.
Soci pep = (Soci)db.getRoot("Pep");
Soci josep = (Soci)db.getRoot("Josep");
//Final de la transaccio de lectura
tr.commit();
}
}
Bibliografia
Object Database Standard: ODMG 2.0
Catell R.G.G, Barry Douglas, Bartels Dirk et al.
Morgan Kaufmann Publishers, Inc.
160 160

Disseny de Sistemes Orientats A Objectes Amb Notació UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Disseny de Sistemes Orientats A Objectes Amb Notació UML

Uploaded by

Copyright:

Available Formats

AULA POLITCNICA 17

Enginyeria del software

You might also like