Disseny de Sistemes Orientats A Objectes Amb Notació UML PDF

AULA POLITCNICA 17
Enginyeria del software

Disseny I
Disseny de sistemes orientats a objectes
amb notaci UML
AULA POLITCNICA / FIB
Cristina Gmez - Enric Mayol

Antoni Oliv - Ernest Teniente
Enginyeria del software

Disseny I
Disseny de sistemes orientats a objectes
amb notaci UML
EDICIONS UPC
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.
PFGZ
+PVTQFWEEK
+PVTQFWEEKCNFKUUGP[FGUQHVYCTG
+PVTQFWEEKCNOCTSWKVGEVWTCFGNUQHVYCTG
+PVTQFWEEKCNURCVTQPUFGFKUUGP[
2CVTCTSWKVGEVPKEGPECRGU
#TSWKVGEVWTCNIKECKHUKECFGNU5KUVGOGUFO+PHQTOCEK
&KUUGP[QTKGPVCVCQDLGEVGUGP7/.
+PVTQFWEEKCNFKUUGP[QTKGPVCVCQDLGEVGUGP7/.
%QPEGRVGUFO7/.RGTCNFKUUGP[
&KUUGP[FGNC%CRCFG&QOKPK
L'URGEKHKECEKFOWPGZGORNGIGUVKFOWPENWDFGVGPPKU
L0QTOCNKV\CEKFGNOGUSWGOCEQPEGRVWCNFOGURGEKHKECEK
L#RNKECEKFGRCVTQPUFGFKUUGP[
L2CVT+VGTCFQT
L2CVT%QPVTQNCFQT
L#UUKIPCEKFG4GURQPUCDKNKVCVUC1DLGEVGU
L2CVT'UVCV
L2CVT/VQFG2NCPVKNNC
L'ZGORNGFGFKUUGP[FGNCECRCFGFQOKPK
&KUUGP[FGNC%CRCFG2TGUGPVCEK
+PVTQFWEEK
L2CVT/QFGNL8KUVCL%QPVTQNCFQT
&KUUGP[FGNC%CRCFG)GUVKFG&CFGURGTUKUVPEKCGP$&11
7
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?
Independent de
la tecnologia Especificaci Qu ha de fer el sistema?
Especificaci del sist. sw.
Dependent de
la tecnologia Disseny Com ho fa el sistema?
Arquitectura del sist. sw.
Implementaci
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
Ingeniera del software

Un enfoque prctico
R. G. Pressman
McGraw Hill, 1998. (Cuarta Edicin)
Caps. 11 i 13.
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.
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, ...
Larquitectura del software s el resultat de lactivitat de disseny arquitectnic del

software.
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

Vistes
Els subsistemes i components sespecifiquen normalment en diferents vistes, per

mostrar diferents propietats rellevants (req. func. i no func) del sistema software.
Una vista:
representa un aspecte parcial de larquitectura,
mostra propietats especfiques
Disseny Implementaci
Casos ds
Procs Desplegament
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: Canv is 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 connex i 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

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

Relaci entre propietats i principis de disseny
Laplicaci dun principi de disseny pot afectar lassoliment duna propietat de

larquitectura del sistema
Per exemple:
baix acoblament pot Canviabilitat
alta cohesi suposar

Eficincia
Determinaci de larquitectura:
Dues vies complementries
Donats els requeriments del sistema degudament especificats, aplicar un conjunt passos genrics de
forma ordenada i sistemtica definits en un mtode
- procs molt guiat
- procs independent
Mtode
del problema
Especificaci Arquitectura
Selecci Patr Adaptaci
Patrons de disseny - procs poc guiat

- procs ms contextualitzat
al problema
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
15

Bibliografia
Pattern-oriented 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 Guide

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

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

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

Crida i retorn: programa principal i subrutina

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
Main
Sub 1 Sub 2 Sub 3
Crida i retorn: Orientaci a objectes
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
Objecte Objecte
Op1() Op3()
Op2()
Objecte
Op4()
19

Crida i retorn: En capes
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.
Comp. 3-1 Capa 3 Comp. 3-2 Comp. 3-p
Comp. 2-1 Capa 2 Comp. 2-2 Comp. 2-n
Comp. 1-1 Capa 1 Comp. 1-2
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
Client1 Client2
Client6 Repositori
Client3
(dades compartides)
Client5 Client4
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
Client1 Client2
Client6 Pissarra Client3

(dades compartides)
Client5 Client4
Flux de dades: Batch seqencial
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)
cinta cinta cinta cinta

validar classificar actualitzar llistar
cinta
llistats
21

Tubs i filtres
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
Procs2
Procs1 Procs4 Procs5
Procs3
Procs6
Model-Vista-Controlador
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
T * Observador
1 actualitzar()
Model
dades
Vista
afegir(o:Observador)
treure(o:Observador)
inicialitzar(m:Model)
notificar() Controlador
ferControlador() Amb
obtenirDades()
mostrar() 1 1
servei()
actualitzar() inicialitzar(m:Model, v:Vista)
tractarEsdeveniment()
actualitzar()
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

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 Architecture in Practice

L. Bass; P. Clements; R. Kazman
Addison-Wesley, 1998, Cap. 5.
Software Architecture
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

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

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

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
Sistema Software
usa
Client Capa N Nivell ms alt dabstracci
Capa N - 1
Capa 1 Nivell ms baix dabstracci
Dispositius Fsics
27

Exemple: Arquitectura 3 capes
Comp. 3-1 Capa 3 Comp. 3-2 Comp. 3-p
Comp. 2-1 Capa 2 Comp. 2-2 Comp. 2-n
Comp. 1-1 Capa 1 Comp. 1-2 Comp. 1-m
Soluci: Comportament
(Comunicaci de dalt a baix)
Capa 3 Capa 2 Capa 1
tasca
petici
resultat
Un usuari realitza una petici duna tasca a la capa superior
28

(Comunicaci de baix a dalt)
Capa 3 Capa 2 Capa 1

esdeveniment
notificaci
Un dispositiu fsic detecta locurrncia dun esdeveniment a la cap inferior
(Comunicaci bi-direccional)
petici
Protocol FTP
FTP FTP
resposta
Protocol TCP
TCP TCP
Protocol IP
IP IP
Protocol Ethernet
Ethernet Ethernet
Connexi fsica
Protocol de comunicaci TCP/IP
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: Canv is 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

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

Bibliografia

John Wiley & Sons, 1996. Pgines 31-51
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
Domini
Sistema
Informaci
activa
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.
33

Arquitectura lgica dun sistema dinformaci:

Context
...... esdeveniments
presentaci:
men seleccionat
bot premut
mostrar finestra
Sistema imprimir lnia
dInformaci ...
operacions
entrada/
...... sortida

Visi general
Aplicaci del patr Arquitectura en 3 Capes a un Sistema dInformaci
......
Responsable de la interacci
amb lusuari
Capa Presentaci
Responsable de la implementaci
Sistema Capa del Domini de les funcionalitats del sistema
dInformaci
Capa de Gesti de dades
Responsable de la interacci
Sistemes gesti bases de dades/fitxers amb el SGBD/F
......
34


Capa de Presentaci
......
esdeveniments
presentaci
Tractament de:
Sassabenta peticions usuaris Finestres
Presentaci Ordena execuci accions Dilegs, Mens
Comunica resultats accions Botons
als usuaris Llistats
esdeveniments externs
consultes
respostes
resultats
Domini
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
Presentaci
consultes
respostes
resultats
Sassabenta esdeveniments Sassabenta consultes
Domini En controla la validesa Obt els resultats
Canvia lestat del domini Comunica respostes
Executa accions encomanades
operacions de consulta i
modificaci a les dades
resultats
respostes
Gesti de dades
La Capa del Domini coneix com satisfer les peticions de lusuari, per ignora on es
guarden les dades i com es presenten a lusuari
35

Arquitectura lgica dun sistema d'informaci:

Capa Gesti de Dades
Domini
modificaci de les dades
resultats
respostes
Permet que el domini pugui ignorar on sn les dades.
Gesti de Les funcions concretes daquesta capa depenen del
Dades sistema de gesti de dades que susi. operacions de consulta i
modificaci en el llenguatge de
les bases de dades i fitxers
resultats
respostes
Sistemes de gesti bases de dades/fitxers
La capa del Gesti de Dades coneix on i com estan emmagatzemades les dades, per
desconeix com tractar-les

Els sistemes de gesti de bases de dades/fitxers
modificaci en el llenguatge de
Gesti de dades les bases de dades i fitxers
select ... from ... where ...

find ....
delete record
....
resultats
Esque. SGBDi ...... SGFj respostes
......
Sencarrega de mantenir una
representaci persistent i concreta
de lestat del domini
36

Capa Gesti de Dades:

Exemple en arquitectura basada en transaccions/bases de dades
CLIENTS Procs de dades discret Verificar rebut

Estmul: Flux de dades nou rebut
* El flux nou rebut ja est accessible
nou rebut if client does not exist

error := No conec el client
Acceptar
issue (error) * operaci estndard YSM
error rebut else if rebut exists
error := Aquest rebut ja existeix
issue (error)
else
issue (nou rebut (correcte))
Client del Rebut end
REBUTS
Procs de dades discret Afegir rebut
Estmul: nou rebut (correcte)
* Tenim nou rebut disponible
create REBUT with:

nou rebut codi rebut := nou rebut.codi rebut
Verificar nou rebut (correcte) import := nou rebut.import
Afegir data := todays date ()
rebut rebut * todays date() s una operaci estndard del YSM
error
end;
* tenim REBUT lligat per la creaci anterior i

* CLIENT lligat pel flux dentrada
create REBUT del CLIENT;

end.
CLIENTS REBUTS
Capa Gesti de Dades:

Exemple en arquitectura basada en transaccions/bases de dades
Presentaci
nouRebut (CodiRebut,Import,Client) error
Domini
ExisteixClient?(Client) ExisteixRebut?(codiRebut) creaRebut (codiRebut,Import,Client)

Transforma operacions
Gesti de dades conceptuals en operacions
fsiques
select client from Clients select codiRebut from Rebuts
insert into Rebuts...
where... where...
Sistema gesti base de dades TAULES:

Clients(client,...)
Rebuts(codi,import,client, data)
37

Arquitectura fsica no distribuida: Una capa
......
En el codi estan barrejades

les tres funcions
Presentaci /
Domini /
Sistema Gesti de Dades
dInformaci Propietats de larquitectura:
Poc canviable
Poc reusable
Sistemes gesti bases de dades/fitxers Poc portable
......
Arquitectura fsica no distribuda: Dues capes (I)
......
Propietats de larquitectura:
Interfcie:
Presentaci - portable, reusable i canviable
(canvis a la interfcie sn locals)
Sistema
dInformaci Domini/Gesti de dades
Implementaci de funcionalitats:
- Poc portable, canviable i reusable
(molta dependncia del SGBD, el format i
Sistemes gesti bases de dades/fitxers localitzaci de les dades)
......
38

Arquitectura fsica no distribuda: Dues capes (II)
......
Implementaci de funcionalitats:
Presentaci/Domini - Poc portable, canviable i reusable
(molta dependncia de la interfcie, del GUI i
Sistema el disseny de pantalles)
dInformaci
Gesti de dades Accs a les dades:
- portable, reusable i canviable
(canvis en format, localitzaci i SGBD sn
Sistemes gesti bases de dades/fitxers locals)
......
Arquitectura fsica no distribuda: Tres capes
......
Presentaci canviable
reusable
portable
Sistema Domini
dInformaci
Gesti de dades Tots els canvis sn locals
Sistemes gesti bases de dades/fitxers
......
39

Bibliografa
Analysis Patterns
Martin Fowler
Addison-Wesley, 1997, cap. 12.
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

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?

Independent de
la tecnologia
Especificaci del sistema software
Dependent de
la tecnologia
Disseny Com ho fa el sistema?
Arquitectura del sistema software
Implementaci
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.
determina
Larquitectura del sistema software i els patrons

(arquitectnics) que susaran per fer el disseny del sistema
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

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 problema)
Disseny: els models defineixen els conceptes que es desenvoluparan

per proporcionar una soluci a les necessitats del mn real.
(domini de la 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: propietat a assolir -> eficincia
Esquema conceptual despecificaci:
Persona Ciutat
Treb-a Empresa
nom * * * T-prov-a * nom
nom
visita-provs(): ll-ciutats nm-hab
ll-ciutats = {nom-c}
- 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
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

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 activitat iterativa 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

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
Enginyeria del software: Especificaci

D.Costal, M.R.Sancho, E.Teniente
Edicions UPC, 1999
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

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
Idioma
nom: String
adrea: String * Parla 1..* nom: String
telfon: Integer /nm-parl.: Integer
canvi-adrea(a:String): Boolean nou-parlant(dni:String)
telfon?(): Integer
afegir-idioma(nom:String)
Atributs: sintaxi completa

[visibilitat] nom [multiplicitat] [:tipus] [=valor-inicial] [{propietats}]
Univaluat (per defecte) changeable

Multivaluat: [1..*] addOnly
Admet valors nuls: [0..1] frozen
etc.
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
Persona
Suposarem que els atributs sn privats,
+ dni: String
# nom: String a no ser que especifiquem una altra
- adrea: String = C/Nou visibilitat
- telfon [0..1]: Integer
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
Navegabilitat
* Parla 1..* Persona a Idioma
Persona Idioma
#parlants +idiomes Idioma a Persona
* Parla 1..*
Persona Idioma Persona a Idioma
+idiomes
{propietats}
visibilitat: public, protected, private 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
51

Associacions: qualificador
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
Associaci no qualificada: Associaci qualificada:
objecte
Ciutat Hotel qualificat
1 * Ciutat
T
nom-c: String nom-h: String nom-h
1 qualificador
R.I. textuals: T
0..1
- no hi pot hav er dues ciutats amb idntic nom-c
- una ciutat no pot tenir dos hotels amb nom-h Hotel
(ciutat, nom-h) 0 o 1 hotel
Associacions: ordenaci
Banc s una propietat dun conjunt dobjectes

1 1 relacionats amb un altre objecte mitjanant
una associaci, que indica si el conjunt est
{ordered} * * {unordered} o no ordenat (per posici).
Prstec Compte
52

Agregaci i Composici
Mail Cotxe
* * 1
...
1 1 1 1 0..5
Adrea Text Motor Xasss Roda
Lagregaci s una associaci que La composici s una agregaci amb

relaciona el tot i les parts. una pertinena ms forta entre el tot i
les parts: si sesborra el tot, tamb
Les parts poden pertanyer a ms cal esborrar les parts.
dun agregat.
En un moment determinat, les parts
A nivell dobjectes, no hi pot haver pertanyen com a mxim a una
cicles en els camins dagregaci. composici.
Operacions: sintaxi completa
Signatura duna operaci:
[visibilitat] nom [(llista-parmetres)] [:tipus-retorn] [{propietats}]
isQuery
sequential
Public (+): loperaci pot ser invocada des de qualsevol objecte guarded
concurrent
Protected (#): pot ser invocada pels objectes de la classe i els seus descendents
Private (-): noms els objectes de la prpia classe poden invocar loperaci
Suposarem que les operacions sn

Parmetres duna operaci: pbliques, si no sindica el contrari
[direcci] nom : tipus [=valor-per-defecte]
in, out, inout
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
Operaci constructora:
nom: String
edat: Integer Suposarem que, si no sindica el contrari,
cada classe dobjectes t una operaci
nom?(): Integer constructora amb tants parmetres com
nova-assig (nom-a:String): Boolean atributs t la classe.
alumne (nom: String, edat:Integer)
promig-edat(): Real 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 Per cada operaci

es defineix
alta-idioma (nom: String) Boolean
un contracte
parla-idioma (dni: String, nom-i: String): Boolean
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
Idioma
dni: String * Parla 1..*
nom: String
nom: String
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 classe abstracta

discriminador
quantitat: Integer
restricci G
forma_pagament {disjoint,complete}
Pagament Pagament Pagament

en metl.lic a crdit amb tal E
codiTarja: String nmTal: Integer
Classe abstracta:
classe que no pot ser instanciada directament (no t objectes propis).
55

Herncia
Herncia:
en una generalitzaci, les subclasses incorporen (hereten) lestructura i el
comportament definits a la superclasse.
EmpleatUniversitari
nom: String
sou: Integer superclasse
nom?(): String
assigSou(Integer)
tipus {disjoint, complete}
Professor Administratiu
plus-lloc: Integer nm-h-extres: Integer
subclasses,
superclasse
plus?(): Integer def-h-ext(Integer)
contracte {disjoint, incomplete}
Prof. Titular Prof. Associat

antiguitat: Integer perodeCont: Integer subclasses
contractar() renovar(n:Integer)
Polimorfisme
Operaci polimrfica:
operaci que saplica a diverses classes duna jerarquia tal que la seva
semntica depn de la subclasse concreta on saplica
EmpleatUniversitari
operaci concreta: t mtode nom: String operaci abstracta: no t mtode
associat a la mateixa classe sou: Integer associat a la classe on est declarada
nom?(): String
pagarSou():Integer
plus-lloc: Integer nm-h-extres: Integer
pagarSou(): Integer pagarSou(): Integer
contracte {disjoint, incomplete}
Prof. Titular Prof. Associat loperaci es defineix de forma

diferent => mtode diferent
antiguitat: Integer perodeCont: Integer
pagarSou(): Integer renovar(n:Integer)
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 Investigador
assignatura: String categoria: String
escola: String escola: String
donarClasse() publicar(a: article)
corregir() 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

Diagrames de seqncia
:Client p:Producte
Creaci dobjecte
oper(a) Existncia dobjecte
:Transacci
op1(a,b) op2(a,c)
op3(c,d)
temps
op4(b)
Focus de control Autoinvocaci doperaci
resultat
result
Destrucci dobjecte
Notaci:
op3(c,d)
:Client instncia (objecte) invocaci de loperaci op3
amb retorn de control
c:Client instncia amb nom Client classe dobjectes
Invocaci doperacions en jerarquies (I)

EmpleatUniversitari
nom: String
sou-base: Integer
nom?(): String
sou-base?(): Integer
pagarSou():Integer
plus-lloc: Integer preu-h-extra: Integer
nm-h-extres: Integer
s-base-alt?():Boolean
s-base-alt? (a Professor)
sou-base? (invocada a Professor)
:Professor
:Professor
s-base-alt? sou-base?
sou-base?
string sou-b
retorna cert si sou-b
ms alt que K
boolean
58

Invocaci doperacions en jerarquies (II)

EmpleatUniversitari
nom: String
sou-base: Integer
pagarSou (invocada a EmpleatUniv.) nom?(): String
sou-base?(): Integer
pagarSou():Integer
plus-lloc: Integer preu-h: Integer
nm-h: Integer
s-base-alt?():Boolean
:Administratiu
:EmpleatUniv :Professor
pagarSou
pagarSou pagarSou sou-base?
retorna sou-b
retorna sou-b
enter sou-b + (nm-h x preu-h)
+ plus-lloc
enter
enter
Bibliografia
The Unified Modeling Language Reference Manual

J.Rumbaugh, I.Jacobson, G.Booch
Addison-Wesley 1999

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

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 Suposem que tot ho fa

fan la capa de Presentaci i la la Capa de Domini
capa de Gesti de Dades
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
Administraci Reserves
Admetre soci Fer reserva
Canvi compte corrent Anul.lar reserva
Administrador Alta familiar Consultar reserves
Baixa soci Veure reserves no usades Persona
Baixa familiar
Facturaci
Gesti pistes
Fer rebuts
Pagar rebuts Afegir pistes
Fer crrecs de reserves Preveure manteniment
Carregar servei a soci Obtenir ocupaci pistes Encarregat
Facturaci
Total deute s pista pistes
Obtenir rebuts no pagats
Canviar parmetres club
63

Diagrama de Casos ds: package Administraci
Administraci
Admetre soci
Canvi compte corrent

Soci
Baixa Soci
Administrador
Alta Familiar
Familiar
Baixa 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 Resposta del sistema

1. El cas ds comena quan una persona
es vol donar dalta com a soci.
2. Ladministrador indica el dni, el nom, 3. Comprova que les dades sn correctes,

ladrea, le-mail i el nmero de compte dna dalta el soci i enregistra que paga
corrent de la persona per aquell nmero de compte corrent
4. Per cada familiar, ladministrador 4. Comprova que les dades sn correctes,

introdueix les seves dades (dni, nom, dna dalta el familiar i enregistra que
adrea i e-mail) s familiar daquell soci
64

Esquema conceptual despecificaci (I)

Es-mant-en
* Interv al Persona
data: Data dni: String
* nom: String
inici: Hora
0..1 adrea: String
Pista * e-mail [0..1] : String
* reservant
nm: Integer
Es-reserva tipus {disjoint, complete}
Reserva
Soci
1 Amb * Familiar
dataReserva: Data
estat {disjoint, complete} 0..1 nmSoci: Integer
/deute:Import * Del CompteCorrent
Prevista NoUsada AnClient 1 1 1
data: Data nm-cc: Integer
Usada AnMant saldo: Import=0
T
data: Data s-pagada
/Correspon
0..1 *
*
Club 1 Crrec
Rebut
data: Data
ltNmSoci: Integer=0 mesEmissi: Mes
import: Import A 1
preuHoraPista: Import * pagat: Bool = false
desc.: String
preuNos:Import /import: Import
preuAnul.laci: Import
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

Diagrama de seqncia del sistema: Admetre soci
:Administrador :Sistema
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 v alor, 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 nov a 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.
Precondicions: Els parmetres tenen v alor, excepte e-mail que pot ser nul.
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

Bibliografia
Enginyeria del software: Especificaci

D.Costal, M.R.Sancho, E.Teniente
Edicions UPC, 1999
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

Eliminaci dassociacions n-ries i classes associatives
Esquema conceptual:
Interv al
Es-mant-en * data: Data
inici: Hora
* * Persona
Pista dni: String
reservant nom: String
nm: Integer *
adrea: String
Es-reserva 0..1
e-mail [0..1] : String
Reserva
dataReserva: Data

claus classes no associatives: (Pista, nm); (Interv al, data + inici); (Persona, dni)
Normalitzaci: pas a associacions binries
Diagrama de classes normalitzat: el resultat obtingut ha de tenir la

mateixa semntica que lesquema
Interv al conceptual de partida
Es-mant-en * data: Data
inici: Hora
*
1 Persona
En
Pista dni: String
* nom: String
nm: Integer 1 * * Per 1
Reserva adrea: String
La reservant
dataReserva: Data e-mail [0..1] : String

claus classes no associatives: (Pista, nm); (Interv al, 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
selimina perqu est inclosa a la tercera restricci textual
70

Tractament de la informaci derivada
Els atributs i les associacions derivats es poden:

Calcular quan es necessiten.
Materialitzar
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
Soci
Esquema conceptual:
nm: Integer 1
/deute: Import
1
T
*
/Correspon
Crrec
data: Data
import: Import Cal decidir si calculem o materialitzem la
desc.: String informaci derivada.
*
A Decidim:
- calcular latribut deute de Soci
0..1
- materialitzar import de Rebut
Rebut
- materialitzar lassociaci Correspon
mes: Mes
pagat: Bool = fals *
/import: Import
71

Tractament de la informaci derivada: resultat

Diagrama de classes resultant:
Soci
nm: Integer Cal modificar tamb els contractes
1
deute?(): Import de les operacions:
- Fer rebuts
1
T - Pagar rebuts
Dna la suma dels imports
dels rebuts no pagats *
perqu modifiquin el valor de:
Crrec - import de Rebut
data: Data - associaci Correspon
import: Import
desc.: String
*
A Correspon
0..1
Atribut Rebut
materialitzat mes: Mes Associaci
pagat: Bool = fals * materialitzada
import: Import
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

Control de les restriccions dintegritat: exemple
Esquema conceptual: Empleat

Sassigna 0..3
Departament
*
codi: Integer nom: String
nom: String
adrea: String
data-ingrs: Date
Assignaci
R.I. Textuals:
data-ini: Date
- 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
Operaci: novaAssig (codi: Enter, nom-d: String, data: Data)

Semntica: Assignar un empleat a un departament
Precondicions: Els parmetres tenen v alor
Postcondicions: 1. Si no existeix lempleat, o no ex isteix 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.
Control de les rest. dintegritat: normalitzaci de lexemple
Diagrama de classes normalitzat:
Empleat Assignaci Departament

codi: Integer 1 T 0..3 * Al 1
data-ini: Date nom: String
nom: String
adrea: String
data-ingrs: Date
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
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.
Operaci normalitzada:

assignat al departament, o data < data-ingrs, o lempleat 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)
Bibliografia

G.Booch; J.Rumbaugh; I.Jacobson
Addison-Wesley, 1999.
Applying UML and Patterns.

C.Larman
Prentice Hall, 1998.
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

Soluci: Estructura
Cas dun nic recorregut per agregat
Iterador
Defineix una interfcie per
Disseny Agregat first() accedir i travessar els
next() elements dun agregat
crearIterador(): Iterador
isDone() : Boolean
Defineix una interfcie per currentItem() : Object
crear un objecte Iterador
Vector
Implementaci IteradorVector
crearIterador(): Iterador first()
next()
LinkedList isDone():Boolean
IteradorLlista
currentItem():Object
first()
crearIterador(): Iterador
next()
isDone():Boolean
Llistes i Vectors currentItem():Object
Implementa la interfcie en Java
de creaci de lIterador Implementa la interfcie
que retorna una instncia definida a lIterador segons
de lIterador concret el recorregut que es vulgui fer
Exemple daplicaci en UML: Problema

Soci Rebut
1 Correspon * mesEmissi : Mes
nmSoci:Integer pagador
rebuts import : Import
deute():Import pagat : Boolean = False
R.I. Textuals
- No poden existir dos socis amb el mateix nmSoci.
- Un soci no pot tenir diversos rebuts amb el mateix mesEmissi.
Es vol dissenyar loperaci deute de Soci (suma dels imports dels seus rebuts no
pagats).
Aplicaci del patr Iterador
76

Exemple daplicaci en UML: Soluci

Diagrama de seqncia Diagrama de classes
operaci de soci que
invoca a loperaci
:Soci :Rebut crearIterador de
lobjecte agregat
rebuts
deute rebuts() Soci
nmSoci : Integer
:Iterador
deute() : Import
rebuts() : Iterador
first()
pagador 1
isDone()
objecte agregat
de soci
* currentItem() Correspon
pagat?() rebuts
acumula limport si el *
rebut no sha pagat Rebut
import?()
mesEmissi : Mes
next() import : Import
pagat : Boolean = False
Import
pagat?() : Boolean
la definici daquesta navegabilitat
import?() : Import
s conseqncia del disseny de
loperaci deute
Iteradors en Java: Enumeration
Defineix una interfcie per

accedir i travessar els
elements dun agregat
Enumeration
next hasMoreElements(): Boolean
LinkedList head 0..1 nextElement(): Object
size : Integer 0..1 Link
tail
reset()
hasMoreElements(): Boolean 0..1
nextElement(): Object pre
currentElement(): Object
elements(): Enumeration 0..1 ListEnumeration
size():Integer
hasMoreElements(): Boolean
1 data nextElement(): Object
Object
return new ListEnumeration(head)

Implementa la interfcie
pel cas de les LinkedList
77

Exemple daplicaci en Java

Definici de classes en Java Diagrama de seqncia usant Java
:Soci :Rebut
Class Soci
{...
deute rebuts()
LinkedList rebuts
...
} :Enumeration
hasMoreElements()
Class Rebut
{...
... nextElement()
Implementaci de
} lassociaci Correspon
i la seva navegabilitat, * pagat?()
mitjanant atributs
import?()
Import
Diccionaris
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.
Diccionari
size: Integer
retorna nul si no hi ha cap
objecte amb aquesta key diccionari()
get(key:Object): Object
put(key:Object, v:Object): Object
remove(key :Object): Object retorna un objecte Iterador
elements(): Iterador que travessa els objectes del
keys(): Iterador diccionari
si la clau ja existeix, subtitueix
lobjecte existent O per v, i retorna un objecte Iterador
retorna O que travessa les claus del
diccionari
Exemples dinstncies:
dicRebuts:Diccionari dicSocis:Diccionari mant tots els socis del Club. La

clau daquest diccionari podria ser
dni (clau de Persona) o numSoci
mant tots els rebuts del Club. La
(ja que no existeixen dos socis amb
clau daquest diccionari seria
el mateix numSoci).
nmSoci+mesEmissi.
78

Diccionaris en Java: Hashtable
Hashtable
size : Integer
hashtable()
retorna nul si no hi ha cap get(Object key) : Object
objecte amb aquesta key
put(Object k, Object v) : Obj ect
retorna un objecte Iterador
remove(Object key) : Object
que travessa els objectes del
elements() : Enumeration diccionari
keys() : Enumeration
si la clau ja existeix, subtitueix retorna un objecte Iterador
lobjecte existent O per v, i que travessa les claus del
retorna O diccionari
Exemple dinstncia:
dicRebuts:Diccionari dicSocis:Hashtable
Exemple diteraci de diccionaris

Club 1
Soci preuHoraPista: Import

numSoci:Integer preuNos: Import
ltNumSoci:Integer=0
deute(): Import preuAnul.laci: Import
R.I. Textuals
- No poden existir dos socis amb el mateix nmSoci.
Es vol calcular el deute que t el Club (suma dels deutes de tots els socis).
79

Exemple diteraci de diccionaris
Diagrama de seqncia Diagrama de classes
Soci
:Club dicSocis:Diccionari :Soci numSoci : Integer
deute() : Import
total_deute
elements()
:Iterador
first()
Club 1
isDone() preuHoraPista: Import
preuNos: Import
currentItem() * darrerNumSoci:Integer=0
preuAnul.laci: Import
deute()
total_deute(): Import
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

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

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
Faana-sistema: Un objecte que representa tot el sistema software (SistemaGestiClub)
SistemaGestiClub 1
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
....
Controlador Faana: faana-empresa
Faana-empresa: Un objecte que representa tot el domini del problema (Club)
Club 1
ltNumsoci: Integer=0
preuNos: Import
preuHoraPista: Import
preuAnullaci: Import
ltNmSoci?(): Integer
incrementar-ltNmSoci()
....
En aquest exemple hem aprofitat lobjecte Club del model conceptual i li hem afegit la
responsabilitat de ser el controlador.
82

Controlador Paper
Controlador Paper: Un objecte que representa un actor dels diagrames de casos ds
Administrador

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 Cas ds
Controlador Cas ds: Un objecte que representa un cas ds
Cas ds Admetre Soci :Sistema

:Administrador
altaSoci (dni, nom, adrea, e-mail, nm-cc, out nm-soci): Boolean
* altaFamiliar(nm-soci, dni, nom, adrea, e-mail): Boolean
Admetre Soci

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
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
AltaSoci Operaci de sistema:

dni: String altaSoci(dni:String, nom:String, adrea:String, e-mail:String,
nom: String nm-cc:Integer, out nmSoci:Integer): Boolean
adrea: String
e-mail[0..1]: String
nm-cc: Integer Parmetres dentrada la transacci
nmSoci: Integer
resultat: Boolean Resultats de la transacci
nmSoci?(): Integer
resultat():Boolean Sencarreguen dobtenir el resultat de la transacci
executar()
Sencarrega defectuar les accions corresponents a la transacci
Estructura de les classes Transacci
Classe abstracta
Transacci
executar() operaci abstracta
AltaSoci
dni: String CanviCompteCorrent AltaFamiliar TotalDeute
nom: String
nmSoci: Integer nmSoci: Integer deute: Import
adrea: String
nm-cc: Integer dni: String
e-mail[0..1]: String executar()
resultat: Boolean nom: String
nmSoci: Integer deute():Import
resultat():Boolean adrea: String
nm-cc: Integer
executar() e-mail[0..1]: String
resultat: Boolean
resultat: Boolean FerRebuts
nmSoci?(): Integer
mesEmissi: Mes
resultat():Boolean resultat():Boolean
executar() executar() executar()
84

Alta de soci Relaci entre la Capa

nom dni
Presentaci i el controlador
Transacci
adrea nm-cc
e-mail nmSoci
endavant plega
:Control-Interfcie
onEndav ant
:AltaSoci Es dona dalta

executar() un soci
...
Mostra el nmSoci
per pantalla resultat()
Obt el nmSoci
nmSoci()
Capa presentaci Capa domini
Relaci entre la Capa

Alta de soci
Presentaci i la combinaci de
nom dni
controladors (Faana i
adrea nm-cc Transacci)
e-mail nmSoci
endavant plega
:Control-Interfcie :Club
onEndav ant
altaSoci(...)
:AltaSoci Es dona dalta
executar() un soci
...
Mostra el nmSoci
per pantalla
resultat() Obt el nmSoci
nmSoci?()
Capa presentaci Capa domini
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

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

Acoblament
Acoblament duna classe s una mesura del grau de connexi,

coneixement i dependncia daquesta classe respecte daltres classes.
B
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
A s una subclasse directa o indirecta de B atribut : B
operac(b : B) : 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
Anlisi dacoblament: Exemple

Diagrama de classes normalitzat
Persona
dni: String
nom: String
adrea: String
e-mail [0..1]: String
Soci Amb * Familiar

1
nmSoci: Integer
deute(): Import
Restriccions dintegritat:
Claus de classes no associatives (Persona, dni)
No hi poden hav er dos socis amb el mateix nmSoci
Suposicions:
Lassociaci Amb t nav egabilitat doble
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. Transacci
Precondicions: Els parmetres tenen valor, excepte e-mail que pot ser nul. executar()
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)
Alta_familiar
nmSoci: Integer
2.1 Es crea un objecte de Familiar (i de Persona) dni: String
nom: String
2.2 Es crea una ocurrncia de lassociaci Amb entre
adrea: String
Familiar i el soci amb nmSoci e-mail [0..1]: String
resultat: Boolean
executar()
resultat():Boolean

Diagrama de seqncia (I)
:AltaFamiliar dicSocis: Diccionari
executar dicPersones: Diccionari

get(nmSoci)
Comprova existncia dun
soci s amb nmSoci
get(dni) s:Soci
Comprova que no existeix
cap persona amb dni
Es crea familiar (i persona) i

f:Familiar
sinicialitzen els seus atributs afegirFamiliar
creassocAmb(s)
Sassocia el familiar f al soci
Sassocia el soci s al familiar
afegirFamiliar(f:Familiar)
La classe AltaFamiliar est acoblada a dicSocis, dicPersones, Soci i Familiar

La classe Soci est acoblada a Familiar i, aquesta a Soci
89


Diagrama de seqncia (II)
:AltaFamiliar dicSocis: Diccionari dicPersones: Diccionari
executar get(nmSoci) Comprova que no

s:Soci existeix cap persona
Comprova lexistncia del
amb dni
soci s amb nmSoci afegirFamiliar
get(dni)
f:Familiar
creassocAmb(s)
Sassocia el soci s al familiar

Es crea familiar (i persona) i
sinicialitzen els seus atributs Sassocia el familiar f al soci
afegirFamiliar(dni:String, nom:String, adrea:String, e-mail:String):Boolean
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.

Diagrama de classes de disseny
Persona
dni: String Transacci
nom: String
adrea: String executar()
Familiar Alta_familiar
nmSoci: Integer
Amb *
Soci dni: String
nom: String
nmSoci: Integer
adrea: String
1
deute(): Integer e-mail [0..1]: String
afegirFamiliar(dni:String, nom:String, resultat: Boolean
adrea:String, e-mail:String):Boolean
executar()
resultat():Boolean
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
Club 1
ltNumsoci: Integer=0
preuNos: Import
ltNmSoci?(): Integer
incrementar-ltNmSoci()
....
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)
Interval
data: Data
Pista
1
Transacci inici: Hora nm: Integer
La
1
executar() En
* *
Reserva *
Per
Baixa_familiar datReserva: Data reservant
1
numsoci: Integer
dni: String Persona
resultat: Boolean dni: String
executar() nom: String
resultat():Boolean adrea: String
Soci Amb * Familiar

Suposici: 1
numSoci: Integer
Totes les associacions tenen navegabilitat doble
deute(): Integer
92


Cas ds Baixa Familiar
Cas ds Baixa Familiar

:Sistema
:Soci
baixaFamiliar(nmSoci, dni): Boolean
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

Contracte operaci baixaFamiliar normalitzat
Operaci : baixaFamiliar (nmSoci:Integer, dni:String)

Experts
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)
93


Diagrama de seqncia baixaFamiliar (I)
:BaixaFamiliar dicPersones: Diccionari Comprova que la persona

p s familiar del Soci amb
executar() p:Persona nmSoci
get(dni)
Comprova familiar-de(nmSoci) Operaci heretada
existncia de p:Familiar de Persona
persona p amb dni
baixa()
eliminarReserves()
:Soci
elimassocAmb(p)
Elimina p com a Familiar i

com a Persona, i les
seves associacions

Diagrama de seqncia baixaFamiliar (II)
:Familiar :Soci
:Soci
familiar-de(nmSoci) familiar-de(nmSoci)
nmSoci?()
Boolean fals
compara si nmSoci
coincideix
p:Persona
eliminarReserves()
reserves()
:Iterador
first() :Reserva
isDone() operaci
currentItem() pendent de
* eliminar() definir
next()
94


Diagrama de classes de disseny
Pista 1 Persona
nm: Integer La * Reserva dni: String
reservant
nom: String
datReserva: Data
* Per 1 adrea: String
* e-mail [0..1]: String
En eliminar()
Interval familiar-de(nmSoci:Integer): Boolean
1 eliminarReserves()
data: Data
inici: Hora reserves(): Iterador
Transacci Soci
numSoci: Integer
executar()
deute(): Integer 1
nmSoci?(): Integer
familiar-de(nmSoci:Integer): Boolean Amb
Baixa_familiar
*
numsoci: Integer
dni: String
Familiar
resultat: Boolean
familiar-de(nmSoci:Integer): Boolean
executar()
baixa()
resultat():Boolean
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 dobjectes dA
. B cont objectes dA
. B enregistra instncies dobjectes dA
. B usa molt objectes dA
. B t les dades necessries per inicialitzar un objecte dA (B t els valors dels
parmetres del constructor dA)
Beneficis:
Acoblament baix
95

Patr Creador: Exemple

Diagrama de classes normalitzat i Controlador
Transacci Club 1
Persona
ltNumSoci: Integer=0
executar() preuHoraPista: Import dni: String
preuNos: Import nom: String
preuAnullaci: Import adrea: String
AltaSoci
dni: String Soci Amb * Familiar
1
nom: String nmSoci: Integer
adrea: String
e-mail [0..1]: String deute(): Integer *
nm-cc: Integer Del
resultat: Boolean CompteCorrent
nmSoci: Integer 1
nm-cc: Integer
executar() saldo: Integer
resultat():Boolean
nmSoci?(): Integer Restriccions dintegritat:
Claus de classes no associatives (Persona, dni), (CompteCorrent, nm-cc)
No hi poden hav er dos socis amb el mateix nmSoci

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.
Precondicions: Els parmetres tenen valor, ex cepte e-mail que pot ser nul.
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


Diagrama seqncia AltaSoci --- Cas 1
dicPersones: Diccionari
:AltaSoci dicSocis: Diccionari dicCompteCorrents: Diccionari
executar
get(nmSoci) :Club
Comprova que no existeix
cap soci amb nmSoci get(dni)
Comprova que no existeix get(nm-cc)
cap persona amb dni
ltNumSoci()
Comprova que existeix un Incrementa latribut ltnumSoci i
compte corrent cc amb nm-cc retorna el nou valor
s:Soci
assigCompte(cc) Associem al soci el
compte corrent
put(nmSoci,s)
put(dni,s) Afegim el nou soci
als diccionaris
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

Diagrama seqncia AltaSoci --- Cas 2
dicPersones: Diccionari
:AltaSoci dicSocis: Diccionari dicCompteCorrents: Diccionari
executar :Club
nouSoci get(dni)
Comprova que no
get(nmSoci)
existeix cap soci get(nm-cc)
amb nmSoci ni
cap Persona amb s:Soci
dni
assigCompte(cc) Associem al
soci el compte
Comprova que
existeix un corrent
compte corrent put(dni,s)
cc amb nm-cc
Boolean put(nmSoci,s)
Afegim el nou soci
Incrementa latribut als diccionaris
ltnumSoci
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.
97


Diagrama de classes de disseny (Cas 2)
Transacci
Persona
executar() dni: String
nom: String
adrea: String
AltaSoci
dni: String Soci
nom: String 1 Amb * Familiar
nmSoci: Integer
adrea: String
e-mail [0..1]: String deute(): Integer *
nm-cc: Integer assigCompte(cc:CompteCorrent)
resultat: Boolean Del
CompteCorrent
nmSoci: Integer 1
executar() nm-cc: Integer
Club 1 saldo: Integer
resultat():Boolean
nmSoci?(): Integer ltNumSoci: Integer=0
preuNos: Import
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

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

Soluci: Estructura
Context 1 Estat
estat
requesta() tractament()
estat tractament()
EstatConcret1 EstatConcret2
tractament() 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

Exemple 1: Problema
Esquema conceptual de lespecificaci i diagrama destats dInterruptor:
Interruptor
referncia: String
data en la que
es va tancar {disjoint,complete} obrir
linterruptor estat
Tancat Obert
tancar
Tancat Obert
datatanc: Data tempsob:Integer temps que estar
obert l interruptor
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
Exemple 1: Compartici dobjectes estat
No Compartici dels objectes estat:
Interruptor 1 1 Estat Els objectes estat

referncia: String consum():Integer tenen informaci
consum():Integer {disjoint,complete}
Tancat Obert
datatanc: Data tempsob:Integer
consum():Integer consum():Integer
101

Exemple 1: Compartici dobjectes estat
Compartici dels objectes estat:
Interruptor * 1 Estat Els objectes estat

referncia: String no tenen informaci o
datatanc[0..1]:Data la que tenien sha posat
{disjoint,complete} a lobjecte context
tempsob[0..1]:Integer
consum():Integer
Tancat Obert
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

Exemple 1: On es defineixen les transicions destat
Transicions destat definides a lobjecte context (estats no compartits):
Aquesta operaci es
Estat utilitzada per les
operacions de canvi
1 tipus():String destat del Context
Aquesta operaci gestiona el
Interruptor 1
consum():Integer per saber quin s el
canvi destat dobert a tancat referncia: String seu estat
{disjoint,complete}
tancar(dt:Data): Bool
obrir(to:Integer):Bool
Aquesta operaci gestiona el consum():Integer Tancat Obert
canvi destat de tancat a obert datatanc: Data tempsob:Integer
Exemple 1: On es defineixen les transicions destat
Transicions destat definides als objectes estat (estats no comparits):
Estat
Interruptor
1 1 tancar(dt:Data,i:Interruptor):Bool
referncia: String obrir(to:Integer,i:Interruptor):Bool
tancar(dt:Data):Bool consum():Integer
Aquestes operacions deleguen
la responsabilitat del canvi {disjoint,complete}
consum():Integer
destat als objectes estat
mod_assoc(e:Estat)
Aquesta operaci modifica Tancat Obert

lassociaci entre Interruptor datatanc: Data tempsob:Integer
i Estat.
obrir(to:Integer,i:Interruptor):Bool tancar(dt:Data,i:Interruptor):Bool
tancar(dt:Data,i:Interruptor):Bool obrir(to:Integer,i:Interruptor):Bool
Aquestes operacions consum():Integer consum():Integer
gestionen el canvi destat
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:
Estat
Interruptor
tancar(dt:Data):Bool consum():Integer
{disjoint,complete}
consum():Integer
mod_assoc(e:Estat)
Tancat Obert
Creaci del nou estat obert , No canvien lestat Creaci del nou estat tancat,
destrucci de lestat tancat i destrucci de lestat obert i
creaci de la nova associaci creaci de la nova associaci
entre Interruptor i el nou estat. entre Interruptor i el nou estat.
104

Exemple 1: Soluci completa

Hiptesis daplicaci del patr Estat:
Objectes estat no compartits.
Transicions destat definides en els objectes estat.
Creaci dels objectes quan es necessiten.
Estat
Interruptor
tancar(dt:data):Bool consum():Integer
{disjoint,complete}
consum():Integer
mod_assoc(e:Estat)
Tancat Obert
Exemple 1: Soluci completa
consum():Integer
i:Interruptor :Obert :Tancat

:Estat
consum() consum()
consum() consum()
retorna tempsob*alfa retorna 0
obrir(to:Integer):Integer
i:Interruptor :Estat :Obert :Tancat i:Interruptor

obrir(to) obrir(to,i) obrir(to,i)
obrir(to,i) ob:Obert
Boolean Fals
Cert mod_assoc(ob)
Els diagrames de seqncia

per loperaci tancar serien
similars als de loperaci obrir.
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:
Reserva
dataReserva:Data
{disjoint,complete}
estat
Res.Prevista ResAnMant ResAnClient ResNoUsada ResUsada

data:Data data:Data
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
106

Exemple 2: Diagrama destats de Reserva
anClient
Anul.lada pel Client
anMant Anul.lada per Manteniment

Prevista
usada Usada
NoUsada
veureSiNoUsada[ dataReserva<dataActual ]
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 EstatRes
1 1
dataReserva:Data cost():Integer
cost():Integer tipus():String
anMant(d:Data):Bool {disjoint,complete}
anClient(d:Data):Bool
usada():Bool
nousada():Bool
Res.Prevista ResAnMant ResAnClient ResNoUsada ResUsada
data:Data data:Data cost():Integer cost():Integer
cost():Integer
107

Exemple 2: Soluci
Operaci cost():Integer : Diagrames de seqncia:
:ResUsada :Club
cost() preuHoraPista()
:Reserva :Estat
cost() cost()
:ResNoUsada :Club
retorna 0 cost() preuNos()
operaci ganxo que es

heretada per totes les
subclasses i redefinida
a ResUsada, ResNoUsada
i ResAnClient. :ResAnClient :Club
cost() preuAnul.laci()
Exemple 2: Soluci
Operaci anMant(d:Data) : Diagrames de seqncia:
r:Reserva :Estat erp:ResPrevista

anMant(d)
tipus()
La resta de diagrames
de seqncia per les
operacions anClient,
usada i nousada
eram:ResAnMant serien similars.
Boolean
comprovar que el tipus formar nova associaci
s reserva prevista entre r i eram
108

Bibliografia
Elements of Reusable Object-Oriented Software.

E. Gamma; R. Helm; R. Johnson; J. Vlissides
An Introduction 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

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

Soluci: Estructura
mtode de loperaci plantilla:

AbstractClass ...
comportament com primitiveOperation1()
...
templateMethod()
primitiveOperation2()
primitiveOperation1() ..
ConcreteClass
comportament especfic primitiveOperation2()
Exemple 1: Problema
Esquema conceptual de lespecificaci: Pers. Docent R.I. Textuals:
Claus classes no associatives:
Centre Docent 1 Ensenya * Professor nom: String (Centre Docent, nom);
edat: Integer (Pers.Docent, nom)
nom: String estudis: String
{disjoint,complete}
tipus
{disjoint,complete}
tipus
Universitat Escola Ens. Secundria 1 Pers. en Formaci Becari

T *
datacreaci: Data numestudiants: Integer dni: String nif: Integer
1 Assignat *
Nota: Suposem que els Centres Docents i el Personal Docent no poden canviar de subclasse
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
112

Exemple 1: Soluci (I)

Aplicaci del patr plantilla:
Pers. Docent
Centre Docent 1 Ensenya Professor nom: String
*
edat: Integer
estudis: String
nom: String
{disjoint,complete}
num_empleats(): Integer tipus
mtode plantilla
num_professors():Integer op.concreta
num_pers_espec():Integer op. primitiva (abstracta)
tipus {disjoint,complete}

T *
num_pers_espec(): num_pers_espec(): Integer *
Integer
1 Assignat
definici de loperaci abstracta
Exemple 1: Soluci (II)
Diagrames de seqncia: :CentreDocent :Professor

professors()
num_professors()
:CentreDocent :Iterador
op. concreta
first()
num_professors() isDone()
num_empleats()
incrementem un
comptador si edat
* currentItem() edat()
<25 next()
num_pers_espec() Integer
sumem els dos valors

:Universitat :Becari
Integer
becaris
num_pers_espec()
:Iterador
mtode plantilla first()
op. primitiva (abstracta) El diagrama de seqncia de
isDone()
num_pers_espec() per Escola
Ens. Secundria seria similar al
incrementem un
comptador si edat
*currentItem() edat()
d Universitat
<25 next()
Integer
113

Exemple 1: Soluci (III)

Diagrama de classes de disseny resultant: Pers. Docent
nom: String
Centre Docent 1 Ensenya * Professor edat: Integer
edat(): Integer
estudis: String
nom: String
{disjoint,complete}
num_professors():Integer
num_pers_espec():Integer

T *
Integer
1 Assignat
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

Extensi Exemple 1: Problema

Esquema conceptual de lespecificaci: Pers. Docent
Centre Docent 1 Ensenya Professor nom: String
*
edat: Integer
estudis: String
nom: String
{disjoint,complete}
tipus
{disjoint,complete}
tipus

T *
1 Assignat *
R.I. Tetuals:
Escola Ens. Primria Claus classes no associatives:
(Centre Docent, nom); (Pers.Docent, nom)
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.
Extensi Exemple 1: Soluci (I)
Diagrama de classes de disseny resultant: Pers. Docent

nom: String
edat: Integer
Centre Docent 1 Ensenya * Professor
edat(): Integer
estudis: String
nom: String
{disjoint,complete}
mtode plantilla
num_professors():Integer op.concreta
num_pers_espec():Integer op. ganxo

T *
Integer
1 Assignat
redefinici de loperaci ganxo
Escola Ens. Primria

edatmxima: Integer
115

Extensi Exemple 1: Soluci (II)

:CentreDocent
op. concreta
num_professors()
num_empleats() :Centre Docent
num_pers_espec()
retorna 0
num_pers_espec() Integer
sumem els dos valors
Integer
op. ganxo
mtode plantilla
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
Exemple 2: Problema
Persona
dni: String R.I. Tetuals:
nom: String - Claus classes no associatives: (Persona,dni)
- No poden existir dos socis amb el mateix numSoci.
adrea: String
{disjoint,complete}
Soci 1 Amb * Familiar

nmSoci: Integer
deute(): Import
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.
116

Exemple 2: Soluci
Transacci Persona
executar() dni:String
nom: String
adrea: String
TransConsultaUnSoci nom(): String
adrea(): String
Cert si el soci amb
numSoci: Integer {disjoint,complete}
numSoci existeix. Fals
en cas contrari. nom: String
resultat:Boolean
executar() Soci
Operaci plantilla
Operaci primitiva
obtDades(s:Soci) numSoci: Integer ....
deute(): Import
TrCUS-1 TrCUS-2
deute: Import adrea: String ....
obtDades(s: Soci ) obtDades(s: Soci )
Exemple 2: Soluci
:TransConsultaUnSoci dicSocis:Diccionari
executar get(numSoci)
error, si el soci
s:Soci
no existeix nom()
obtDades(s)
:TrCUS-1 s:Soci :TrCUS-2 s:Soci

obtDades() deute() obtDades() adrea()
117

Bibliografia
Elements of Reusable Object-Oriented Software.

E. Gamma; R. Helm; R. Johnson; J. Vlissides
C. Larman
Prentice Hall, 1998, cap. 38.11.
http://www.eli.sdsu.edu/courses/spring98/cs635/notes/template
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

Data
Persona data: Date Ciutat
dni: Integer * inici 0.. 3 nom: String
*
nom: String
/nmv: Integer Vol-viatjar {incomplete}
1
Viatge Mar
/T-pressupostats
{disjoint, complete} 1
De
* *
Pressupostat Reservat Confirmat Hotel
* 0..1
preu: Import avan: Import Amb nom: String
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

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) Llista-noms= { nom }
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.
Especificaci: Cas ds
Confirmar-Viatge-al-Mar
:Sistema
:Empleat/da
Confirmar-mar(dni, nom-c, data, nom-h): ok?
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
120

Especificaci: Diagrama dEstats
reservar
Pressupostat Reservat
confirmar
confirmar
Confirmat
Normalitzaci: Diagrama de classes normalitzat

Data
data: Date Ciutat
Persona
dni: Integer 1 inici 1 nom: String
1
nom: String Viatge-Data
mmv(): Integer Viatge-Pers Viatge-Ciutat
{incomplete}
1 * * *
Viatge Mar
T-pressupostats
{disjoint, complete} 1
De
* *
Pressupostat Reservat Confirmat Hotel
* 0..1
preu: Import avan: Import Amb nom: String
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

Normalitzaci: Contracte normalitzat

qui?
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

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.3 Lhotel nom-h no s de la ciutat nom-c
1.4 Ja existeix un viatge confirmat de la persona i data especificats
2.1 El viatge passa a estar Confirmat
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

Aplicaci del Patr Estat
Supsits en l aplicaci del Patr Estat

- Objectes estat no compartits
- Transicions destat definides als objectes estat
- Creaci i destrucci dobjectes estat quan calgui
Data
data: Date Ciutat
Persona
dni: Integer 1 inici 1 nom: String
1
nom: String Viatge-Data
mmv(): Integer Viatge-Pers Viatge-Ciutat
{incomplete}
1 * * *
Viatge Mar
T-pressupostats 1 1
De
1 estat *
Estat Hotel
0..1
{disjoint, complete} nom: String
Amb
*
Pressupostat Reservat Confirmat
*
preu: Import avan: Import
Suposicions:
Aplicaci del Patr Controlador
Transacci
executar()
Allotjats Confirmar-Mar
nom-c: String dni: Integer
nom-h: String nom-c: String
ll-per: Llista-noms data: Date
resultat: Boolean nom-h: String
resultat: Boolean
executar()
resultat(): Boolean executar()
noms(): Llista-noms resultat(): Boolean
qui? (nom-c: String, nom-h: String, confirmar-mar (dni: Inmteger, nom-c: String, data: Date,
out ll-per: Llista-noms): Boolean nom-h: String): Boolean
123

Aplicaci Patr Expert

qui? (nom-c, nom-h, out ll-per)
Experts
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 DicHotels
1.2 o b si no hi cap persona que shi hagi allotjat Allotjats, Hotel
2. En cas contrari, operaci vlida, es retorna Cert i la llista que cont els
Allotjats, Hotel
noms de totes les persones que shan allotjat alguna vegada a lhotel
Diagrama Seqncia
:Confirmat
:Allotjats confirmat-a(h)
dicHotel:Diccionari amb() No s
necessari
executar() explicitar-la
get(nom-c+nom-h) Boolean
= h?
existeix
hotel? h:Hotel :Estat
:Mar
qui() confirmat-a(h)
viatges-a(h) viatges()
fals
:Iterador
first()
is_done() :Viatge
current_item() :Estat
confirmat-a(h) confirmat-a(h)
* :Persona
nom?()
String
next()
Comprovar si
llista buida Llista-noms
Llista-noms
acumular nom a una llista
124

Diagrama Seqncia (alternativa)

:Allotjats dicHotel:Diccionari
executar()
get(nom-c+nom-h)
h:Hotel
existeix hotel?
qui()
confirmats()
:Iterador
first()
is_done() :Confirmat
current_item()
:Viatge
viatger()
:Persona
* viatger()
nom?()
String
String
next()
Comprovar si obtenir el viatge obtenir la persona
llista buida Llista-noms
acumular nom a una llista
Modificant el patr Estat, definint la navegabilitat de lassociaci entre Viatge i

Estat doble, es pot definir loperaci qui? duna forma ms eficient.
Aplicaci Patr Expert

confirmar-mar (dni, nom-c, data, nom-h)
Experts
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 Ciutat, dicMar
1.2 Si no ex isteix un viatge de la persona a la ciutat per a la data
especificats dicViatges
1.3 Lhotel nom-h no s de la ciutat nom-c dicHotels
1.4 Ja existeix un viatge confirmat de la persona i data especificats Persona, dicConfirmats
2.1 El viatge passa a estar Confirmat Estat + Viatge
2.2 Es crea una nov a ocurrncia de lassociaci Amb entre el viatge
confirmat i lHotel Confirmat + Hotel
2.3 Si el viatge era Pressupostat, selimina lassociaci T-
Pressupostat + Persona
pressupostat amb Persona
125

Diagrama Seqncia (I)

confirmar-mar(dni, nom-c, data, nom-h)
:Confirmar-mar
dicViatge:Diccionari
executar()
dicHotel:Diccionari
get(dni+nom-c+data)
existeix viatge? Comprova si ja t
get(nom-c+nom-h) viatges confirmats
en la data
si existeix hotel (h),
llavors est a la
ciutat i, aquesta s v:Viatge
de mar :Persona Comprova si s un
confirmar(h, data) viatge confirmats en
t-confirmats?(data) la data
viatges()
:Iterador
first()
is_done() :Data
:Viatge
current_item()
:Estat
confirmat-en(data) data?(data)
* confirmat?()
Boolean
next()
Boolean
Compara atribut Comrova
:Estat data amb valor estat
parmetre confirmat
confirmar(v, h)
Boolean Fa canvi destat
Diagrama Seqncia (II)

e:Pressupostat
confirmar(v, h)
:Estat
nouconfirmat(v, h)
nouconfirmat(v, h)
e:Confirmat
:Persona
h:Hotel
associarAmb(h)
eliminaTePres(e) creassocAmb(e)
cert
v:Viatge
modifassocEstat(e)
:Reservat
confirmar(v, h)
nouconfirmat(v, h)
cert
:Confirmat :Estat
:Confirmat confirmat?() confirmat?()
confirmar(v, h) cert fals
fals
126

Diagrama Seqncia (I) (alternativa)

:Confirmar-mar
dicViatge:Diccionari Comprova no existeix cap objecte
executar() estat Confirmat
dicHotel:Diccionari
get(dni+nom-c+data)
existeix viatge?
get(nom-c+nom-h)
si existeix hotel (h),
llavors est a la dicConfirmats:Diccionari
ciutat i, aquesta s v:Viatge
de mar
confirmar(h, dni, data)
get(dni+data)
:Estat
confirmar(v, h)
Boolean Mateixa operaci
que abans
La restricci Una persona no pot tenir ms dun viatge confirmat amb la mateixa
data dinici permet identificar els viatges confirmats amb (dni+data).
Diagrama Seqncia (II) (alternativa)

e:Pressupostat :Reservat :Confirmat
confirmar(v, h) confirmar(v, h) confirmar(v, h)

fals
nouconfirmat(v, h) nouconfirmat(v, h)
:Persona
cert
eliminaTePres(e)
cert
:Estat
nouconfirmat(v, h)
e:Confirmat
h:Hotel
associarAmb(h)
creassocAmb(e)
v:Viatge
modifassocEstat(e)
modificar associaci amb Viatge
127

Diagrama de Classes de Disseny

Ciutat
Persona Data
nom: String
dni: Integer data: Date 1 viatges(): Iterador
nom: String
data?(data:Date): Boolean viatges-a(h:Hotel): Llista-noms
mmv(): Integer 1
t-confirmats(data: Date): Boolean 1 inici
viatges(): Iterador Viatge-Ciutat {incomplete}
Viatge-Data
eliminaTPres(e:Pressupostat) Viatge-Pers
nom?(): String Mar
* * *
1 Viatge 1
Transacci
De
confirmat-en(data:Date): Boolean *
confirmar(h:Hotel, data:Date):Boolean executar()
Hotel
modifassocEstat(e:Estat)
confirmat-a(h:Hotel): String nom: String
1 qui(): Llista-noms
estat crearassocAmb(e:Confirmat)
T-pressupostats 1
0..1
Estat nom-c: String dni: Integer
confirmat?():Boolean ll-per: Llista-noms data: Date
confirmar(v:Viatge, h:Hotel):Boolean resultat: Boolean nom-h: String
nouconfirmat(v:Viatge, h:Hotel) Amb resultat: Boolean
executar()
confirmat-a(h:Hotel): Boolean
{disjoint, complete} noms(): Llista-noms resultat(): Boolean
* *
preu: Import avan: Import confirmar(v:Viatge, h:Hotel):Boolean
confirmar(v:Viatge, h:Hotel):Boolean confirmar(v:Viatge, h:Hotel):Boolean associarAm b(h:Hotel)
amb(): Hotel
confirmat-a(h:Hotel): Boolean
confirmat?():Boolean
Diagrama de Classes de Disseny (alternativa)
Ciutat
Data
Persona nom: String
dni: Integer data: Date 1
La navegabilitat de les
nom: String
associacions Viatge-Data, Viatge-
mmv(): Integer 1
1 inici {incomplete} Ciutat i De, no queden definides
eliminaTPres(e:Pressupostat) pels diagrames de seqncia.
Viatge-Ciutat
nom?(): String Viatge-Data Mar
Viatge-Pers
1
* * * 1
Viatge De
* Transacci
confirmar(h:Hotel, dni:Integer, data:Date):Boolean Hotel
modifassocEstat(e:Estat) executar()
nom: String
viatger(): String
qui(): Llista-noms
1 crearassocAmb(e:Confirmat)
confirmats(): Iterador
T-pressupostats 1 estat
0..1
Estat nom-c: String dni: Integer
confirmar(v:Viatge, h:Hotel):Boolean ll-per: Llista-noms data: Date
nouconfirmat(v:Viatge, h:Hotel) resultat: Boolean nom-h: String
viatger(): String Amb resultat: Boolean
executar()
{disjoint, complete} noms(): Llista-noms resultat(): Boolean
* *
preu: Import avan: Import confirmar(v:Viatge, h:Hotel):Boolean
confirmar(v:Viatge, h:Hotel):Boolean confirmar(v:Viatge, h:Hotel):Boolean associarAm b(h:Hotel)
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

Capa Presentaci: s el component del sistema software encarregat de

gestionar la interacci amb lusuari.
......
esdeveniments
presentaci
S'assabenta peticions Tractament de:
Presentaci Ordena execuci accions Finestres, Mens
Comunica resultats accions Botons, Llistats
consultes
resultats
Domini 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

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

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.
Disseny Extern: Presentaci de la Informaci
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.
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
Disseny Intern
Estructura lgica de la
Capa Presentaci (GUI):
esdeveniments de presentaci
Manipulador dEsdeveniments de Presentaci
Capa Gesti Interacci Presentaci

Presentaci amb Usuari Informaci
Comunicaci amb Capa Domini
esdeveniments de sistema
Capa Domini
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

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 dalta 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 dalta els seus familiars
Punt de Partida: Disseny Extern
Alta de soci Nmero de Soci

Nom A
Numero Soci
adrea B
e-mail C Ok
endavant plega
Assignaci Compte
Numero Compte Corrent
endavant plega
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 Endav ant. 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 dalta 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.
Prentice Hall, 1998. (Cap. 16)
136

Disseny de la Capa Presentaci: Patr Model-Vista-Controlador 1
Descripci General
Soluci: Estructura
Comportament
Conseqncies
Implementaci
Exemple
Bibliografia
Descripci General (I)
El Patr Model-Vista-Controlador s un patr arquitectnic
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.
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
Amb * Observador
1 actualitzar
Model
dades
Vista
Controlador
afegir(observador)
treure(observador)
inicialitzar (model)
notificar()
ferControlador() inicialitzar(model, vista)
obtenirDades() 1 T 1
activar() tractarEsdev (esdev .)
servei()
actualitzar() actualitzar()
mostrar()
En general, hi ha tantes parelles 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

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.
Afegir i treure permeten gestionar observadors associats

Model
Notifica als observadors que shan produt
... canvis en lestat del Model
afegir(observador)
treure(observador) Permet a la Vista i al Controlador obtenir dades modificades
notificar() del Model (1 operaci per cada tipus dinformaci a presentar)
obtenirDades()
servei() 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.
Controlador
associa el controlador a la Vista i al Model
rep un esdeveniment
inicialitzar (model, vista) el valor del parmetre determina la funcionalitat a tractar
tractarEsdev (esdev .)
actualitzar() actualitza el comportament del controlador
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 associa el Model a la Vista
crea el Controlador associat a aquesta Vista
inicialitzar(model) permet activar la Vista

ferControlador()
activar() actualitza el contingut de la Vista
actualitzar()
mostrar() mostra dades a pantalla
...
operacions de presentaci de la informaci a la pantalla
Comportament: inicialitzaci del patr MVC

:Main
Inicialitzar el patr MVC suposa associar

estticament un model amb les seves
m:Model
vistes i controladors.
v:Vista
inicialitzar(m)
afegir(v)
ferControlador
c:Controlador
inicialitzar(m,v)
afegir(c)
...
A partir daqu ja es poden comenar a
tractar els esdeveniments
140

Comportament: gesti dun esdeveniment (I)
:Controlador :Model tantes operacions servei com

esdeveniments tracti el sistema
tractarEsdev(servei)
servei es realitzen les accions
... necessries a la capa de domini
notificar per efectuar el servei
tots-obs
:Iterador
first
isDone :Observador
* currentItem
actualitzar
next
<- Capa Presentaci <- Capa Domini -> Capa Presentaci ->
Comportament: gesti dun esdeveniment (II)
Actualitzaci dels observadors: - 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
Si el controlador modifica el comportament
:Controlador :Model
:Vista
actualitzar
:Model
obtenirDades
actualitzar mostrar
obtenirDades
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

Exemple: deute total del club de tennis
Diagrama de classes de disseny (inicial)
Correspon
1 *
Soci Crrec Rebut
nmSoci: Integer 1 T * data: Date * A 0..1 mesEmissi: Mes

import: Import import: Import
deute?(): Import desc.: String pagat: Boolean
*
Club 1
Del CompteCorrent
1 tot-deute: Import
nmcc: Date
saldo: Import
- 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
Exemple: estructura MVC

Amb * Observador
esdev pot ser
1 correspon a obtenirDades actualitzar pagarRebut o ferRebut
Model
Vista Controlador
afegir(observador)
treure(observador)
inicialitzar (model) 1 T 1
notificar() inicialitzar(model, vista)
ferControlador()
tot-deute?(): Import tractarEsdev (esdev .)
activar()
pagRebut(nmSoci,mes) actualitzar()
actualitzar()
ferRebuts(data)
mostrar()
op. ganxo
Club 1 ContTotalDeute
VistaTotalDeute
tot-deute: Import
tot-deute?(): Import mostrar()
pagRebut (nmSoci,mes) set-text(imp) operaci de presentaci dinformaci
ferRebuts (data)
Com que noms hi ha un model, una vista i un

serveis oferts pel model controlador, les jerarquies es podrien col.lapsar
143

Exemple: inicialitzaci del MVC

:Main
c:Club
v:VistaTotalDeute
inicialitzar(c)
afegir(v)
ferControlador
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
dicReb:diccionari
tractarEsdev
pagRebut
(pagRebut(nmSoci,mes)) get
(nmSoci,mes)
:Rebut
pagar :Soci :CC

pagar-reb
dec-saldo
boole boole
dec-deute
latribut pagat es posa a cert

notificar
boole
<- Capa Presentaci Capa Domini ->
144

Exemple: gesti de pagRebut (II)
:Club Notificaci als observadors, un cop

shan dut a terme els canvis del model
provocats per pagRebut
notificar
tots-obs
:Iterador
first
isDone :Observador
* currentItem
actualitzar
next
Capa Domini -> Capa Presentaci ->
Exemple: gesti de pagRebut (III)
Actualitzaci del contingut dels observadors

:Controlador
actualitzar
op. ganxo: no fa res perqu el comportament
del controlador no depn de lestat del model
:VistaTotalDeute
actualitzar mostrar :Club

tot-deute?
set-text
modifica, a la pantalla, el valor de limport

corresponent al deute total del club
145

Exemple: diagrama de classes resultant
Correspon
1 *
Soci Crrec Rebut

1 T *
nmSoci: Integer data: Date * A 0..1 mesEmissi: Mes
import: Import import: Import
deute?(): Import desc.: String pagat: Boolean
pagar-reb(imp): Bool
pagar(): Bool
*
Del
...
1
CompteCorrent Club 1
nmcc: Date tot-deute: Import

saldo: Import
tot-deute?(): Import
dec-saldo(import): Bool tots-obs(): Iterador
dec-deute(import)
pagRebut(nmSoci,mes): Bool.
ferRebuts(data)
Bibliografia
Pattern-oriented Software Architecture. A System of patterns.

John Wiley & Sons, 1996.
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

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
Cpia i traducci
Transparncia
de dades
Representaci
relacional
SGBDR
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 Codi font de

ODL o PL ODL laplicaci en PL
Preprocessador Compilador PL
declaracions
Aplicaci
metadades SGBDOO binari
Runtime
Linkador
accs dades
Base de Aplicaci
executable
dades
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

Model dObjectes: Objecte
Creaci dobjectes: interface Object {

En ODL: enum Lock_Type{read,write,upgrade};
exception LockNotGranted{};
interface ObjectFactory { void lock(in Lock_Type mode) raises (LockNotGranted)
Object new(); boolean try_lock(in Lock_Type mode);
}; boolean same_as(in Object anObject);
Object Copy();
void delete();
}; tots els objectes tenen una interfcie
tots els objectes sn creats per la invocaci en ODL, que es heretada implcitament
doperacions de creaci que hi ha en els a les definicions dobjectes dels usuaris
objectes fbrica proporcionats pels llenguatges
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
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

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.
Model dObjectes: Estat dun objecte
Atributs: defineixen un estat abstracte dun tipus.

En ODL:
class Persona{
attribute short age;
};
Relacions: es defineixen entre tipus i noms poden ser binries.
En ODL:
interface Curs{
1:1 interface Professor{
relationship professor es_ensenyat_per
relationship curs ensenya
inverse professor::ensenya;
inverse curs::es_ensenyat_per;
};
};
1:n interface Professor{ interface Curs{

relationship set<curs> ensenya relationship professor
inverse curs::es_ensenyat_per; es_ensenyat_per
}; inverse professor::ensenya;
};
m:n
interface Professor{ interface Curs{
relationship set<curs> ensenya relationship set<professor> es_ensenyat_per
inverse curs::es_ensenyat_per; inverse professor::ensenya;
}; };
El SGBDOO mant la integritat

referencial de les relacions.
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 Database {
interface DatabaseFactory {
Database new(); 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

Model dObjectes: Transaccions
Hi ha dos tipus definits per suportar lactivitat transaccional en un

SGBDOO.
interface Transaction {
interface TransactionFactory {
Transaction new(); exception TransactionInProgress{};
Transaction current(); 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

Diagrama de classes de disseny class Persona poblaci de Persones
(extent Persones
key dni) clau de Persona
Persona {
dni:String attribute string dni;
nom: String attribute string nom;
adrea: String attribute string adrea;
e-mail[0..1]: String attribute string e-mail;
}; herncia de lestat
class Soci extends Persona i comportament
1 * Familiar {
Soci
attribute short numSoci;
numSoci: Integer navegabilitat relationship set<Familiar> familiars
doble inverse Familiar::soci;
deute():Import
short deute();
afegirFamiliar(..) operaci amb void afegirFamiliar (in string nom, in string adrea, in
hihaFamiliar(nom: excepcions string e-mail) raises (familiar_ja_existeix);
String):Boolean
boolean hihaFamiliar(in string nom);
};
class Familiar extends Persona

{
relationship soci
inverse Soci::familiars;
};
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; typedef bag<soci> socs;

vectad (select distinct adrea socs( select distinct soci(a:nom,b:adrea,c:e-mail)
from Persones from Persones
where nom=Pep) where nom=Pep)
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

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.
Collection query(String predicate)
Consultes utilitzant classes OQLQuery
class OQLQuery {
public OQLQuery() {}
public OQLQuery(String Query){...}
public create(String Query){...}
public bind(Object parameter){...}
public Object execute() throws ODMGException{...}
};
157

Java binding: Arquitectura dObjectStore
Server
Cache Manager
Server Client Application
host host host disk

disk
network
host host host
Cache Manager Cache Manager Cache Manager
Client Application Client Application Client Application
Client Application
Java binding
Exemple dutilitzaci del Java binding amb ObjectStore/1
Definici de lesquema
Persona abstract class Persona {
String nom;
dni:String
String adreca;
nom: String
String email;
adrea: String
e-mail[0..1]: String // Constructor:
public Persona(String nom, String adreca, String email) {
this.nom = nom; this.adreca = adreca; this.email = email;
1 Familiar }
Soci *
public String obtenir_nom() { return nom; }
numSoci: Integer public String obtenir_adreca() { return adreca; }
public String obtenir_email() { return email; }
deute():Import public void posar_nom(String nom) { this.nom = nom; }
afegirFamiliar(..) public void posar_adreca(String adreca) { this.adreca = adreca; }
hihaFamiliar(nom: public void posar_email(String email) { this.email = email; }
String):Boolean }
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);
}
}
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
Definici dels programes
import COM.odi.*;
public
class Exemple {
public static void main(String argv[]) {
String dbName = argv[0];
// Aquesta linia inicialitza ObjectStore
ObjectStore.initialize(null, null); operaci de la classe Database
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); operaci de la classe Transaction
//Creacio dels socis
Soci pep = new Soci("Pep", "C/Balmes", "pep@lsi.upc.es",1,db); operaci de creaci dun objecte
Soci josep = new Soci("Josep", "C/Sants","josep@lsi.upc.es",2,db); a la BD
//Creacio de dos punts d'entrada a la BDoperaci de punts dentrada a la BD
db.createRoot("Pep", pep);
db.createRoot("Josep", josep);
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

Disseny de Sistemes Orientats A Objectes Amb Notació UML PDF

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 PDF

Uploaded by

Copyright:

Available Formats

AULA POLITCNICA 17

Enginyeria del software

Cristina Gmez - Enric Mayol

Enginyeria del software

Aquest llibre s'ha publicat amb la collaboraci

En collaboraci amb el Servei de Llenges i Terminologia de la UPC.

Disseny de la coberta: Manuel Andreu

Els autors, 1999

Edicions UPC, 1999

Producci: CPET (Centre de Publicacions del Campus Nord)

Dipsit legal: B-2.615-2001

Introducci al disseny de software

Etapes del desenvolupament de software

Introducci al disseny de software 2

Etapes del desenvolupament de software

Anlisi de Requeriments Quin sistema cal construir?

Els autors, 2001; Edicions UPC, 2001.

Resultat del disseny: (Com ho fa el sistema?)

Introducci al disseny de software 4

Ingeniera del software

Els autors, 2001; Edicions UPC, 2001.

Introducci a larquitectura del software

Arquitectura del software

Relaci entre propietats i principis de disseny

Introducci: Introducci a larquitectura del software 2

Arquitectura del software

La determinaci de larquitectura del software consisteix en la presa de decisions

Larquitectura del software s el resultat de lactivitat de disseny arquitectnic del

Els autors, 2001; Edicions UPC, 2001.

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:

Introducci: Introducci a larquitectura del software 4

Relacions entre components

Una relaci denota una connexi entre components.

Les relacions poden ser:

Els autors, 2001; Edicions UPC, 2001.

Els subsistemes i components sespecifiquen normalment en diferents vistes, per

Introducci: Introducci a larquitectura del software 6

Els autors, 2001; Edicions UPC, 2001.

Introducci: Introducci a larquitectura del software 8

Principis de disseny: Ocultaci dinformaci

Confinar (ocultar) en un nic mdul (classe, etc.) un aspecte qualsevol del

Si hi ha un canvi en laspecte ocultat (secret), quedar limitat al mdul

Tamb es diu que el secret soculta en el mdul.

Aquest principi fou proposat per en D. Parnas, el 1972.

Els autors, 2001; Edicions UPC, 2001.

Relaci entre propietats i principis de disseny

Laplicaci dun principi de disseny pot afectar lassoliment duna propietat de

baix acoblament pot Canviabilitat

alta cohesi suposar

Introducci: Introducci a larquitectura del software 10

Selecci Patr Adaptaci

Patrons de disseny - procs poc guiat

Donats els requeriments del sistema degudament especificats,

Els autors, 2001; Edicions UPC, 2001.

Pattern-oriented Software Architecture. A System of patterns

The Unified Modeling Language User Guide

Component Software: Beyond Object-oriented programming

Els autors, 2001; Edicions UPC, 2001.

Introducci als patrons de disseny

Patrons de disseny: Definici.