Enginyeria Del Software, Especificació Amb UML

AULA POLITCNICA / FIB
Dolors Costal - M. Ribera Sancho

Ernest Teniente
Enginyeria del Software

Especificaci
Especificaci de sistemes orientats a objectes
amb la notaci UML
EDICIONS UPC
Primera edici: febrer del 2000
Aquesta publicaci s'acull a la poltica de normalitzaci lingstica

i ha comptat amb la collaboraci del Departament de Cultura i
de la Direcci General d'Universitats, 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, 2000
Edicions UPC, 2000

Edicions de la Universitat Politcnica de Catalunya, SL
Jordi Girona Salgado 31, 08034 Barcelona
Tel.: 934 016 883 Fax: 934 015 885
Edicions Virtuals: www.edicionsupc.es
A/e: edupc@sg.upc.es
Producci:
CPET (Centre de Publicacions del Campus Nord)

La Cup. Gran Capit s/n, 08034 Barcelona
Dipsit legal:
ISBN: 84-8301-366-5
Sn rigorosament prohibides, sense l'autoritzaci escrita dels titulars del copyright, sota les sancions
establertes a la llei, la reproducci total o parcial d'aquesta obra per qualsevol procediment, inclosos la
reprografia i el tractament informtic, i la distribuci d'exemplars mitjanant lloguer o prstec pblics.
ndex
- Transparncies
1. Introducci a lEnginyeria del Software ......................................................... 11
2. Requeriments i Especificaci ......................................................................... 19
3. Introducci a lorientaci a objectes ............................................................... 28
3.1 - Motivaci i orgens ........................................................................... 28
3.2 - Aspecte Esttic ................................................................................. 33
3.3 - Aspecte Dinmic............................................................................... 34
3.4 - El llenguatge UML (Unified Modeling Language) ............................ 37
4. El llenguatge UML......................................................................................... 39
4.1 - Model Conceptual en UML............................................................... 39
4.2 - El llenguatge OCL (Object Constraint Language) ............................. 56
4.3 - Model de Casos ds en UML .......................................................... 65
4.4 - Model del Comportament en UML ................................................... 75
4.5 - Model dels Estats en UML................................................................ 91
5. El Procs Unificat de Desenvolupament de Software...................................... 97
- Recull dexercicis
1. Introducci................................................................................................... 105
2. Model Conceptual en UML.......................................................................... 106
3. El llenguatge OCL ....................................................................................... 127
4. Altres models dUML .................................................................................. 128
Els autors, 2000; Edicions UPC, 2000.
Transparncies
ES:E - Introducci a lEnginyeria del Software
Introducci a lEnginyeria del Software
Software
Importncia
Evoluci
Caracterstiques
Crisi del software
Enginyeria del Software

Definicions
Caracterstiques
Visi genrica
Paradigmes
Cicle de vida clssic
Prototipatge
Model en espiral
Bibliografia
Evoluci de Costos del Hardware i del Software
100%
HARDWARE
SOFTWARE
1960
70
80
11
90
Evoluci del software
Distirubuci
Hardware barat
Software de consum
Batch
Poca distribuci
A mida
Multiusuari
Temps real
Bases de dades
Software de producte
1950
60
Sistemes sobretaula
Sistemes experts
Clcul paral.lel
Orientaci a objectes
80
70
90
2000
Caracterstiques del software
Es desenvolupa, no es fabrica
No sespatlla
Manteniment ms difcil que el hardware
Es construeix a mida, no es reusa
12
Fallades H/S
ndex
fallades
Hardware
Software
temps
Aplicacions del Software

Sistemes
Temps real
Gesti
Denginyeria
Cientfic
Empotrat
De PC
DIntel.ligncia Artificial
13
Crisi del software

Crisi?
Aflicci crnica !!!
Problemes:
Evoluci contnua
Insatisfacci dels usuaris
Poca qualitat
Manteniment difcil
Causes:
Naturalesa del software
Complexitat
Gesti
Mites:
De gesti
Dels clients
Dels dissenyadors
Resultat de projectes de software
PA GAT, NO
LLIURAT
47%
USA T
2%
USA T
DESPRS
CANVIS
3%
LLIURAT, NO
USA T
29%
14
ABA NDONA T O
REFET
19%
Enginyeria del software
Establiment i s de principis de lenginyeria orientats a obtenir

software:
Econmic
Fiable
Que funcioni eficientment
Que satisfaci les necessitats dels usuaris
10
Un enginyer ...
Disposa dun ventall de tcniques provades que donen resultats
precisos.
Es preocupa de la fiabilitat i del rendiment.
Tracta de reduir costos i complexitat.
Basa els seus models en teories matemtiques slides.
Construeix prototipus dels nous dissenys.
Utilitza diagrames formals.
15
11
El procs de lenginyeria
Formulaci
Anlisi
Generaci
Selecci
Especificaci
Implementaci
Modificaci
12
Visi genrica de lEnginyeria del Software

Definici:
Anlisi del sistema
Planificaci del projecte
Anlisi de requeriments del software
Desenvolupament:
Disseny del software
Codificaci
Prova
Manteniment:
Correcci
Adaptaci
Millora
16
13
Cicle de vida clssic

ENG. SISTEMA
ANLISI
DISSENY
CODIFICACI
PROVA
MANTENIMENT
14
Prototipatge
ANLISI
REQUERIMENTS
DISSENY
RPID
PRODUCTE
PROTO_
TIPUS
REFI_
NAMENT
AVALUACI
17
15
Model en Espiral
Anlisi de Risc
Planificaci
Avaluaci
Enginyeria
16
Bibliografia
R.S. Pressman
Ingeniera del Software: Un enfoque prctico.
4a edici.
McGraw Hill, 1997. (Cap. 1)
18
ES:E - Requeriments i Especificacions
Requeriments i Especificacions
Determinaci dels requeriments del software

Requeriments del sistema versus requeriments del software
Etapes
Estratgies
Especificacions de sistemes software

Requeriments funcionals i no funcionals
Propietats desitjables de les especificacions
Estndards de documentaci
Bibliografia
Requeriments del sistema vs. requeriments del software

Requeriment: Condici o capacitat necessitada per un usuari
per tal de solucionar un problema o aconseguir un objectiu
La soluci al problema es pot realitzar amb software, hardware,
manualment, o amb una combinaci de tots tres.
Si la soluci s composta, abans de dissenyar els detalls dun
component software concret, cal dissenyar el sistema global.
Exemple de sistema compost: refineria automatitzada
Exemple de sistema noms_software: control destocs
19
Etapes de lenginyeria de sistemes
Determinar requeriments del sistema

Especificar requeriments del sistema
Disseny del sistema
SOFTWARE
HARDWARE
PERSONES
Determinar
requeriments
Especificar
requeriments
Disseny
enginyeria
del hardware
enginyeria
del software
enginyeria de sistemes
Determinar requeriments del sistema global

Comprensi dels objectius i necessitats de lusuari
Definir el conjunt de sistemes que podrien satisfer les necessitats o
objectius i avaluar-los
Triar el sistema ms adient
QUIN SISTEMA CAL CONSTRUIR?
MAGATZEM
Sistema que rep i verifica els productes demanats

als provedors, i els emmagatzema als prestatges
20
Especificar els requeriments del sistema global

Descriure el comportament extern del sistema, des del punt de vista de
lusuari, o de lentorn
QU HA DE FER EL SISTEMA?
error
1. Comprovar si esperada
error
2. Comprovar correspondncia
albar
3. Control de qualitat
4. Actualitzar comanda
defectus
COMANDA A
PROVEDOR
5. Determinar on va
PRODUCTES
PRESTATGES
6. Emmagatzemar ordre
PRODUCTES EN PRESTATGES
Disseny del sistema

Determinar larquitectura general del sistema que millor satisf els
requeriments , en termes de:
components fsics: hardware, software, persones
comunicaci entre ells
error
1. Comprovar si esperada
error
2. Comprovar correspondncia
albar
3. Control de qualitat
defectus
4. Actualitzar comanda
COMANDA A
PROVEDOR
PRODUCTES
PRESTATGES
5. Determinar on va
ordre
6. Emmagatzemar
SOFTWARE
MANUAL
PRODUCTES EN PRESTATGES
H ARDWARE
21
Disseny del sistema
Recepci
comanda
albar
avs
defectus
resultat
albar
Sistema
Informtic
ordre
errors
Transport
Determinar requeriments del software
s el subconjunt dels requeriments del sistema global que han estat

assignats al component software concret
avs
comanda
albar
SISTEMA
INFORMTIC
resultat
ordre
errors
22
Especificar els requeriments del software

Descriure amb detall el comportament extern del component
software concret
albar
error
comanda
Rebre
Comandes
Tractar
Albarans
comandes
avs
Actualitzar
Comandes
resultat
productes
prestatges
Emetre
Ordre
ordre
10
Determinaci dels requeriments del software:

Estratgies
Demanar-ho a lusuari
Treure-ho dun sistema software existent
Sintetitzar-ho a partir del sistema global
Descobrir-ho mitjanant experimentaci
23
11
Requeriments del software

Funcionals
Descriuen totes les entrades i sortides, i la relaci entre ambdues
de dades
de procs
No funcionals
Defineixen les qualitats generals que ha de tenir el sistema en
realitzar la seva funci
Qualitat
Interfcies
Rendiment extern
Econmics
Estructurals
Poltics
12
Factors de qualitat del software

Eficincia
Flexibilitat
Integritat
Mantenibilitat
Portabilitat
Fiabilitat
Actualitat
Reusabilitat
Testability
Usabilitat
Interoperabilitat
24
13
Factors de qualitat del software: conflictes

Eficincia
Flexibilitat
Integritat
Mantenibilitat
Portabilitat
Fiabilitat
Actualitat
Reusabilitat
Testability
Usabilitat
Interoperabilitat
14
Propietats desitjables de les especificacions
No ambiges
Completes
Verificables
Consistents
Modificables
Traables
Usables durant loperaci i el manteniment
25
15
Com organitzar una especificaci de requeriments?

estndard de documentaci ANSI/IEEE
1. Introducci
1.1
1.2
1.3
1.4
1.5
Propsit de lespecificaci
Abast del producte
Definicions i abreviatures
Referncies
Visi general de lespecificaci
2. Descripci General
2.1
2.2
2.3
2.4
2.5
Perspectiva del producte

Funcions del producte
Caracterstiques dels usuaris
Restriccions generals
Supsits i dependncies
3. Requeriments especfics
4. Apndixos
5. ndex
16
Com organitzar una especificaci de requeriments?

estndard de documentaci ANSI/IEEE
3. Requeriments especfics
3.1 Requeriments funcionals
3.1.1 Requeriment funcional 1
3.1.1.1 Introducci
3.1.1.2 Entrades
3.1.1.3 Tractament
3.1.1.4 Sortides
3.1.2 Requeriment funcional 2
3.2 Requeriments dinterfcies externes

3.2.1 Dusuaris
3.2.2 Hardware
3.2.3 Software
3.2.4 Comunicacions
3.3
3.4
3.5
3.6
Requeriments de rendiment
Restriccions de disseny
Atributs
Altres requeriments
26
17
Bibliografia
K.Shumate, M.Keller
Software Specification and Design - A Disciplined Approach for
Real-Time Systems.
John Wiley, 1992. (Cap. 3)
A. M. Davis
Software Requirements - Objects, Functions and States.
Prentice-Hall, 1993. (Cap. 1-5)
27
ES:E - Introducci a lorientaci a objectes
Introducci a lorientaci a objectes
Motivaci i orgens
Visi dun sistema software

Aspecte esttic
Aspecte dinmic
La notaci UML
Motivaci
- Aparici dels llenguatges de programaci orientats a objectes.
SIMULA: finals dels 1960's
SMALLTALK: principis dels 1970's
- L's d'aquests llenguatges requereix un nou enfocament d'anlisi i

de disseny.
- Altres factors:
Desenvolupament de noves aplicacions
mfasi principal en l'estructura de dades
Aparici dels primers mtodes d'anlisi i de disseny

orientats a objectes
28
Orgens
Fusion
Martin-Odell
OOSE
Processos i Models
Recomanats
BOOCH
OMT
Shlaer &
Mellor
UML
Rumbaugh, Blaha, Premerlani (OMT) - 1991

Coad, Yourdon - 1991
Shlaer, Mellor - 1992
Booch - 1992
Odell, Martin - 1992
Jacobson (OOSE) - 1993
Fusion - 1994
Booch, Rumbaugh, Jacobson (UML) - 1997
Visi dun sistema software
29
Objectes
Objecte:
Entitat que existeix al mn real
Tenen identitat i sn distingibles entre ells
l'avi amb
matrcula 327
una poma
la factura 3443
un semfor
l'avi amb
matrcula 999
Classes dobjectes
Classe d'objectes: descriu un conjunt d'objectes amb:
- les mateixes propietats
- comportament com
- idntica relaci amb altres objectes
- semntica comuna
abstracci
classe avi
Avi
Abstracci: eliminar distincions entre objectes per a poder observar

aspectes comuns
Els objectes d'una classe tenen les mateixes propietats i els
mateixos patrons de comportament
30
Atributs
Atribut: s una propietat compartida pels objectes d'una classe.
Exemples:
Persona => nom, adrea, telfon, ...
Avi => model, capacitat, color, ...
Persona
Nom
Adrea
Telfon
Data_naixement
Edat
Avi
Model
Capacitat
Color
- Cada atribut t un valor (probablement diferent) per cada

instncia d'objecte
- Els atributs poden ser bsics o derivats
Operacions (I)
Operaci: s una funci o transformaci que es pot aplicar als
objectes d'una classe.
Persona
Nom
Adrea
Telfon
Avi
Model
Capacitat
Colors
Canvi_adrea
Canvi_feina
Reparar
Moure
- Les operacions d'un objecte sn invocades pels altres objectes

Mtode: especificaci procedural (implementaci) d'una operaci dins
d'una classe.
Encapsulament: consisteix a separar els aspectes externs d'un objecte
dels detalls d'implementaci.
31
Operacions (II)
- En les operacions, cal indicar tamb el tipus dels arguments i del resultat.
Triangle
Quadrat
Color
Color
Posici
Posici
Girar (angle)
Girar (angle)
seleccionar (p:Punt):Boole
Polimorfisme:
- una mateixa operaci es pot aplicar a diferents classes
- la seva implementaci depn de cada classe
10
Associacions
Associaci:
defineix la manera d'enllaar o connectar objectes de
diferents classes
Exemple: Un pas t una nica capital.
Pas
Nom
Habitants
Ciutat
t_capital
Nom
Habitants
32
11
Generalitzaci
Generalitzaci: s l'acte o resultat de distingir un concepte que s
ms general que un altre
Empleat
Nom
Sou
Contractar
Pagar_sou
Jubilar
Especialitzaci
Directiu
Perode contracte
Desp. autor.
Autoritzar despeses
Jubilar
Generalitzaci
...
Viatjant
Regi
Quota
Assignar regi
Assignar quota
Herncia: permet que l'estructura de dades i les operacions d'una classe

siguin accessibles a una subclasse
12
Orientaci a objectes (I)
Aspecte esttic: descriu l'estructura esttica dels objectes del sistema

i les seves interrelacions
Intra - objecte
Aspecte
esttic
Classes dobjectes
Atributs
Operacions
Inter - objectes
Associaci
Generalitzaci
...
33
13
Descripci del comportament (I)

Els objectes es comuniquen mitjanant la invocaci doperacions
daltres objectes
14
Descripci del comportament (II)

Aspecte dinmic (de comportament): descriu els aspectes d'un sistema
que canvien amb el temps
L'aspecte dinmic d'un sistema descriu:

- Interaccions entre els objectes
- Possibles estats d'un objecte
- Transicions entre estats
- Quins esdeveniments es produeixen
- Quines operacions s'executen
Hi ha molta divergncia entre els mtodes actuals a l'hora de tractar

l'aspecte dinmic
34
15
Descripci del Comportament (III)

Diagrama de transici destats: especifica el canvi
destat dun objecte causat pels esdeveniments
Exemple: estat civil duna persona
neixement
Soltera
casament
Casada
divorci
Divorciada
casament
divorci
casament
separaci
enviudar
Separada
Vdua
enviudar
16
Descripci del comportament (IV)

Esquema d'esdeveniments: permet especificar la interacci entre
diferents objectes (usat pel mtode de Martin i Odell [MO92])
Client envia
comanda
Acceptar
comanda
comanda
acceptada
Lliurar
comanda
Preparar
comanda
comanda
lliurada
Tancar
comanda
comanda
preparada
Client paga
factura
Enviar
factura
factura
pagada
factura
enviada
35
comanda
tancada
17
Orientaci a objectes (II)

Aspecte esttic: descriu l'estructura esttica dels objectes del sistema
software i les seves interrelacions
Aspecte dinmic (de comportament): descriu els aspectes dun
sistema software que canvien amb el temps
Intra - objecte
Aspecte
esttic
Classes dobjectes
Atributs
Operacions
Aspecte
dinmic
Diagrama de
transici destats
Inter - objectes
Associaci
Generalitzaci
...
Esquema
desdeveniments
18
Anlisi i disseny orientats a objectes

Anlisi:
- Creaci duna especificaci del problema i dels requeriments
- Qu ha de fer el sistema software
Disseny:
- definici duna soluci software que satisfaci els requeriments
- Com ho far el sistema
orientats a objectes
Susen els mateixos conceptes a lanlisi i al disseny
s difcil determinar on acaba l'anlisi orientada a objectes i on
comena el disseny:
- estratgia de desenvolupament iterativa
- diferncies de criteris segons els autors
36
19
El llenguatge UML (Unified Modeling Language)

Industrialitzaci
Setembre 97 - Publicaci de lUML 1.1
UML 1.1
Standaritzaci
Gener 97 - Publicaci de lUML 1.0
public
feedback
UML 1.0
UML Partners
Expertise
Juny 96 & Octubre 96
UML 0.9 & UML 0.91
Unificaci
OOPSLA 95
Unified Method 0.8
Booch93 OMT-2
Other methods Booch 91
OMT-1
Fragmentaci
OOSE
20
El triangle de lxit
U.M.L.
Notaci
Procs
(metodologia)
Eina
Rational Rose
Craig Larman
37
21
Model dAnlisi (especificaci)

Model
DAnlisi
Model de
Casos ds
Model
Conceptual
Model del
comportament
del sistema
Model dels
Estats
Casos ds
- nivell alt
- essencial
Diagrames
Esttics
dEstructura
pels Objectes
del Domini
Diagrames de
seqncia
del sistema
Diagrames
dEstat per
Objectes i
Casos ds
Diagrames
de Casos ds
Contractes
per les
operacions
del sistema
38
ES:E - Model Conceptual en UML
Model Conceptual en UML

Introducci
Objectes i classes dobjectes
Atributs
Associacions
Classe associativa
Generalitzaci/Especialitzaci
Agregaci i composici
Ampliacions
Exemples

Model
DAnlisi
Model de
Casos ds
Model
Conceptual
Model del
comportament
del sistema
Model dels
Estats
Casos ds
- nivell alt
- essencial
Diagrames
Esttics
dEstructura
pels Objectes
del Domini
Diagrames de
seqncia
del sistema
Diagrames
dEstat per
Objectes i
Casos ds
Diagrames
de Casos ds
Contractes
per les
operacions
del sistema
39
Model Conceptual
Es la representaci dels conceptes (objectes) significatius en

el domini del problema.
Mostra, principalment:
Classes dobjectes.
Associacions entre classes dobjectes.
Atributs de les classes dobjectes.
Objectes
Objecte:
Entitat que existeix al mn real
Tenen identitat i sn distingibles entre ells
l'avi amb
matrcula 327
una poma
un semfor
l'avi amb
matrcula 999
la factura 3443
40
Classe dobjectes
Classe d'objectes: descriu un conjunt d'objectes amb:
- les mateixes propietats
- comportament com
- idntica relaci amb altres objectes
- semntica comuna
abstracci
classe avi
Avi
Abstracci: eliminar distincions entre objectes per a poder

observar aspectes comuns
Els objectes d'una classe tenen les mateixes propietats i els
mateixos patrons de comportament
Diagrama de classes
TPV
producte
supermercat
venda
linia de
venda
caixer
client
director
pagament
catleg
especificaci
de producte
41
Atributs
Es una propietat compartida pels objectes duna classe
TPV
supermercat
producte
adrea: Adrea
nom: Text
linia de venda
caixer
venda
data: Date
hora: Time
client
director
quantitat: integer
pagament
especificaci
de producte
descripci:Text
preu: Quantitat
upc:UPC
catleg
import: Quantitat
Els atributs:
- Poden prendre valors nuls
- Poden ser multivaluats
Associacions
Es la representaci de relacions entre dos o ms objectes
- direcci de lectura
Persona
Viu a
Ciutat
- nom dassociaci
42
Associacions dordre superior a dos
Alumne
Quadrimestre
Assignatura
Es matricula
10
Associacions - Multiplicitat
Defineix quantes instncies duna classe A es poden associar amb una
instncia de la classe B en un moment de temps determinat
A
A
A
A
A
1..*
0..1
0..*
2..5
A
B
2, 5
A
B
1..3,7..10,15..*
B
1..*
B
0..2
43
11
Nom de rol a les associacions

Cada extrem duna associaci es un rol, que t diverses propietats com:
- nom
- multiplicitat
El nom de rol identifica un cap de lassociaci i descriu el paper jugat pels
objectes en lassociaci.
Vola cap a
1
destinaci
Vol
Ciutat
Nom de Rol
Descriu el Rol d una ciutat
en lassociaci vola cap a
12
Associacions recursives
Associacions en les que una mateixa classe dobjectes hi participa
ms duna vegada (amb papers diferents o no)
Persona
*
0..2
pare
fill
Crea
Persona
*
T per amic
44
13
Classe associativa
Representa una associaci que es pot veure com una classe
Estudiant
Assignatura
EstMatriculat
adrea
nom
nom
* crdits
Matrcula
nota
Empresa
Classe associativa
Els atributs fan referncia a lassociaci
La seva vida depn de lassociaci
Persona
Emplea
nom
adrea
Contracte
sou
14
Exemple classe associativa

Viatge
Persona
sha allotjat
Ciutat
ha_viatjat
(Si una persona P haviatjat algun cop a una ciutat C, existeix una
ocurrncia de lassociaci ha_viatjat)
Incorrecte:
Hotel
*
viatja
Persona
(Hi ha viatges sense allotjament en hotel)
45
Ciutat
Hotel
15
Identificar elements comuns entre els objectes definint relacions de supertipus
(objecte general) i subtipus (objecte especialitzat).
supertipus
Persona
E
G
sexe
{disjoint, complete}
Dona
Home
discriminador - Es el nom de la partici. Ha de ser nic entre els

atributs i rols de la superclasse
subtipus
disjoint - Un descendent no ho pot ser en ms duna subclasse

overlapping - Un descendent pot ser de ms duna subclasse
complete - Shan especificat totes les subclasses
incomplete - La llista de subclasses s incompleta
16
Permet entendre els conceptes en termes ms generals, refinats i
abstractes.
Fa els diagrames ms expressius.
Tots els membres del subtipus sn membres del supertipus.
El 100% de la definici del supertipus ha de ser aplicable
al subtipus.
- atributs
- associacions
(- operacions)
Pagament
Paga per
quantitat: Diners
Pagament
en metl.lic
Pagament
a crdit
46
Venda
Pagament
amb tal
17
Motivacions per particionar un tipus en subtipus
El subtipus t atributs addicionals.
El subtipus t associacions addicionals.
El subtipus s tractat o manipulat de forma
diferent daltres subtipus.
El subtipus es comporta de manera diferent
del supertipus o dels altres subtipus.
Paga per
1
Pagament
Atributs i
associacions comunes
Pagament
en metl.lic
Venda
Quantitat: Diners
associacions
addicionals
Pagament
a crdit
Pagament
amb tal
*
Identifica crdit
1
Cada pagament es
tracta diferent
Pagat amb
1
Tarja
Tal
18
Motivacions per definir un supertipus:
Els subtipus potencials representen variacions
dun mateix concepte.
Els subtipus tenen atributs que poden ser
factoritzats i expressats als supertipus.
Els subtipus tenen associacions que poden
ser factoritzades i relacionades amb el supertipus.
Atributs i
associacions comunes
Pagament
en metl.lic
Paga per
1
Pagament
Venda
Quantitat: Diners
associacions
addicionals
Pagament
a crdit
Pagament
amb tal
*
Identifica crdit
1
Cada pagament es
tracta diferent
Tarja
47
Pagat amb
1
Tal
19
Agregaci
Lagregaci s un tipus dassociaci usada per modelar relacions part-tot entre
objectes.
El tot sanomena composat i les parts components
Ruta
Cont
*
*
Usa
Men
Segment
1..*
Recepta
La distinci entre associaci i agregaci s sovint subjectiva.

Lnica restricci que afegeix lagregaci respecte lassociaci s que les cadenes
dagregacions entre instncies dobjectes no poden formar cicles.
*
A1
B1
*
*
C1
B2
C3
C2
A2
A3
A4
20
Composici
La composici s un tipus dagregaci per la qual:
- La multiplicitat del cap compost pot ser com a mxim 1 (com a mxim un
composat posseeix un component)
- Si un component est associat a un composat i el composat
sesborra aleshores el component tamb sha desborrar (no el pot
sobreviure)
T
Dits
0..5
1
Cont
Venda
0..*
1
Cont
Catleg
0..1
1..*
LniadeVenda
Especificaci
de Producte
48
21
Agregaci i composici - quan mostrar-la
Agregaci/Composici
Existeix un assemblatge tot-part fsic o lgic.
Algunes propietats del tot es propaguen a les parts
(com destrucci, moviment, ...)
Composici
La vida de la part est inclosa en la vida del composat.
Existeix una dependncia crear-esborrar de la part respecte del
composat.
22
Informaci derivada
Un element (atribut o associaci) s derivat si es pot calcular a partir daltres elements.
Sinclou quan millora la claredat del model conceptual
Una constraint (regla de derivaci) ha despecificar com es deriva
Atribut derivat
Departament
Empleat
nom
/nombre_empleats
Associaci derivada
*
Departament
Est situat a
Ciutat
Empleat
*
/Treballa a
49
23
Multiplicitat de classe
La multiplicitat de classe estableix el rang de possibles cardinalitats per les
instncies duna classe
Per defecte, s indefinida
En alguns casos, per, s til establir una multiplicitat finita, especialment en
casos de classes que poden tenir una sola instncia (i que sanomenen
singleton)
- multiplicitat de classe
1
La Puntual, S.A.
NIF
adrea
24
Altres restriccions sobre associacions

A part de la multiplicitat, s possible expressar altres restriccions sobre les associacions:
- Xor
- Subset
Xor
Uneix diverses associacions lligades a una mateixa classe bsica
Una instncia de la classe bsica participa exactament en una de les associacions unides
per xor.
persona propietria
* Persona
Compte
compte per
*
{xor}
*
compte emp
1
empresa propietria
Empresa
Subset
Indica que una associaci s un subconjunt duna altra associaci
*
Persona
Pertany a
*
Comissi
{subset}
1
Presideix
50
25
Canviabilitat
La canviabilitat indica si els valors dun atribut o lextrem duna associaci poden
canviar o no
Canviable (changeable)
- opci per defecte -
Persona
Viu a
*
telfon {changeable} resident
*
Ciutat
ciutat-res
{changeable}
telfon i ciutat-res sn canviables
Congelat (frozen)
Persona
Va nixer a
*
data-naix {frozen} per-nascuda
1
Ciutat
ciutat-naix
{frozen}
data-naix i ciutat-naix sn congelats
Noms-afegir (addOnly)
Persona
Ha residit a
*
resident
ttol-acad {addOnly}
ttol-acad i ciutat-res sn noms-afegir
*
Ciutat
ciutat-res
{addOnly}
26
Classificaci mltiple
Variant de generalitzaci/especialitzaci en la qual una superclasse pot tenir

diverses jerarquies despecilitzaci en funci de diferents discriminadors
Persona
estat
sexe
Home
Dona
Soltera
Casada
51
Divorc.
Vdua
27
Herncia mltiple
Variant de generalitzaci/especialitzaci en la qual una subclasse t ms
duna superclasse
Estudiant
universitat
{disjoint, incomplete}
EstUPC
EstUAB
estudis
{disjoint, incomplete}
Inform.
EstUB
Mates
Empres.
InformUPC
Noms es pot utilitzar si no hi ha conflictes dherncia
28
Equivalncies notacionals (1)

En UML:
Polgon
nombre_costats
Triangle
Rectangle
Pentgon
...
Pentgon
...
s equivalent a:
Polgon
Triangle
Rectangle
Problema?
52
29
Equivalncies notacionals (2)

En UML:
Docncia_Assignatura
1
*
Classe_Teoria
*
Classe_Probl
*
Classe_Lab
s equivalent a:
Docncia_Assignatura
1
*
Classe_Teoria
*
Classe_Probl
*
Classe_Lab
30
Exemples
Quina soluci s millor?
Persona_UPC
nom
num-assignatures
sou
amb valors nuls
Persona_UPC
nom
tipus
{overlapping, incomplete}
Empleat
Estudiant
num-assignatures
sou
sense valors nuls
53
31
Exemples
Quina soluci s millor?
Persona_UPC
nom
telfon
amb valors nuls
Persona_UPC
nom
tenir_telfon
Persona_amb_telfon
telfon
sense valors nuls
32
Exemples
Empleat
Projecte
nom: Text
proj_emp: Projecte
codi_proj: Text
descripcio: Text
Un atribut no pot prendre valors duna de les classes del model conceptual
Aquest cas s una associaci
Empleat
nom: Text
*
Treballa a
Projecte
codi_proj: Text
descripcio: Text
54
33
Bibliografia
The Unified Modeling Language User Guide
G. Booch, J. Rumbaugh, I. Jacobson
Addison-Wesley, 1999
En castell:
El Lenguaje Unificado de Modelado
The Unified Modeling Language Reference Manual
J. Rumbaugh, I. Jacobson, G.Booch
Applying UML and Patterns
An Introduction to Object-Oriented Analysis and Design
C. Larman
Prentice-Hall 1998
Cap. 9, 10, 11, 28, 30
55
ES:E -Object Constraint Language
Object Constraint Language (OCL)
Per qu serveix?
Propietats del Model Conceptual
Col.leccions: conjunts, bosses i seqncies
Navegaci per classes associatives
Generalitzaci / Especialitzaci
Com especificar en OCL
Per qu serveix OCL?
Els models grfics no sn suficients per a una especificaci precisa i no

ambigua
LOCL:
s un llenguatge formal
permet definir expressions (no t efectes laterals)
no s un llenguatge de programaci
Susa per:
especificar invariants (restriccions) del Model Conceptual
com a llenguatge de navegaci
(especificar restriccions en les operacions)
56
Exemple
Persona
0..*
director
dataNaixement : Data
nom : String
cognom : String
sexe : enum{home,dona}
/estCasat : Boolean
/estaturat : Boolean
/edat : Integer
Empresa
empresesDirigides
empleat
nom : String
contractador /nombredEmpleats: Integer
0..*
0..*
esposa
0..1
esps
0..1
Treball
Casament
ttol : String
datadInici: Data
salari : Integer
lloc : String
data : Data
Propietats dels objectes
Una expressi OCL fa referncia a les propietats dels objectes especificats

al Model Conceptual
Una propietat pot fer referncia a:

atributs duna classe dobjectes
navegaci a travs de les associacions
Propietats dels atributs duna classe dobjectes:
Propietat: edat duna persona -- enter

Persona
lexpressi ha de ser certa per a totes
les instncies de la classe
self.edat
instncia contextual de lexpressi (punt de partida)
Restricci de la propietat: ledat de les persones ha de ser superior o igual a

zero
Persona
self.edat >= 0
o, alternativament: p:Persona
p.edat >= 0
57
Propietats dels objectes (II)

Propietats duna navegaci a travs dassociacions:
Partint dun objecte concret, podem navegar a travs de les assocciacions del
Model Conceptual per referir-nos a daltres objectes i a les seves propietats
Com es navega?
Objecte.nom-de-rol
objecte de partida
nom de rol duna associaci de lobjecte
Resultat: conjunt dobjectes de laltre extrem de nom-de-rol
si no hi ha nom de rol especificat, es pot usar el nom de la classe dobjectes de laltre extrem
de lassociaci (amb minscules)
Exemples de navegaci:
Empresa
self.director
self.director.nom
self.empleat
self.empleat.esps
-- director de lempresa -- Persona

-- nom del director -- String
-- empleats de lempresa -- set(Persona)
-- esposos dels empleats -- set(Persona)
Col.leccions: conjunts, bosses i seqncies

Una col.lecci delements pot ser del tipus:
Conjunt: cada element ocorre una nica vegada a la col .lecci

Bossa (multiconjunt): la col .lecci pot contenir elements repetits
Seqncia: bossa on els elements estan ordenats
Exemple:
nombre de treballadors que treballen per a una persona

Persona
num-treb = self.empresesDirigides.empleat -> size
Incorrecte: el resultat s una bossa i pot contenir repetits.
Persona
num-treb = self.empresesDirigides.empleat -> asSet -> size
Regles de navegaci:
si la multiplicitat de lassociaci s 1 el resultat s un objecte o un conjunt dun nic

objecte.
si la multiplicitat de lassociaci s >1 el resultat s una bossa, encara que, de
vegades, pot ser un conjunt
58
Operacions bsiques sobre col.leccions (I)

Select: especifica un subconjunt de la col.lecci
persones majors de 50 anys que treballen a una empresa
Empresa
self.empleat -> select(edat>50)
Empresa
self.empleat -> select(p | p.edat>50)
Empresa
self.empleat -> select(p:Persona | p.edat>50)
Collect: especifica una col.lecci que es deriva duna altra, per que cont
objectes diferents
edats (amb repetits) dels empleats duna empresa
Empresa
self.empleat -> collect(dataNaixement)
versi simplificada: self.empleat.dataNaixement
Operacions bsiques sobre col.leccions (II)

forAll: expressi que han de satisfer tots els elements
tots els empleats de lempresa sanomenen Jack
Empresa
self.empleat -> forAll(nom=Jack)
Exists: condici que satisf almenys un element

com a mnim un empleat de lempresa sha de dir Jack
Empresa
self.empleat -> exists(nom=Jack)
59
Combinaci de propietats
Les propietats es poden combinar per formar expressions ms complexes
Les persones casades han de ser majors dedat

Persona
self.esposa -> notEmpty implies self.esposa.edat >= 18
and self.esps -> notEmpty implies self.esps.edat >= 18
Una empresa t com a mxim 50 empleats

Empresa
self.empleat -> size <= 50
Una persona no pot tenir alhora un esps i una esposa

Persona
not ((self.esposa -> size=1) and (self.esps -> size=1)
definici de latribut derivat nombredEmpleats

Empresa
nombredEmpleats = (self.empleat -> size)
definici de latribut derivat estaturat

Persona
estaturat = if self.contractador-> isEmpty then true else false
10
Navegaci per classes associatives

Navegaci a una classe associativa:
Es fa servir el nom de la classe associativa (amb minscula)
els sous de les persones que treballen a la UPC han de ser ms alts que 1000
Persona
(self.contractador -> select(nom=UPC)).treball)
-> forAll (t | t.salari > 1000)
Navegaci des duna classe associativa:

Susa el nom de rol de lextrem cap on es vol navegar
Si no sha especificat nom de rol, susa el nom de la classe.
les persones que treballen no poden estar aturades

Treball
self.empleat.estaturat = false
un casament ha de ser entre una dona i un home

Casament
self.esposa.sexe = #dona and self.esps.sexe = #home
60
11
Generalitzaci - Especialitzaci (herncia)

Compte corrent
efectua
num-cc: Integer
entitat: String
Transacci
data: Data
quantitat: Integer
Ingrs
Extracci
c-oficina: Integer
persona: String
Avantatges:
Les propietats de les subclasse es poden ignorar

Compte corrent
self.transacci -> select(data.isafter(5-4-1998)) -- transaccions dun compte posteriors al 5-4-1998
Accs directe a les propietats de la superclasse

Ingrs
self.compte-corrent.num-cc -- nmero de compte dun ingrs
Aspectes addicionals:
Selecci dobjectes que pertanyen a la subclasse

Compte corrent
self.transacci -> select(oclType=Ingrs) -- ingressos dun compte
Accs a les propietats definides al nivell de subclasse

Compte corrent
self.transacci.oclasType(Extracci).persona -> asSet
-- persones que han tret diners dun compte corrent
12
Com especificar en O.C.L.
Una expressi O.C.L sespecifica sempre comenant en una classe

dobjectes determinada: instncia contextual
Una expressi es pot especificar de diverses maneres, segons la instncia

contextual de partida:
Persona
self.esposa -> notEmpty implies self.esposa.edat >= 18 and
self.esps -> notEmpty implies self.esps.edat >= 18
Casament
self.esposa.edat >= 18 and self.esps.edat >= 18
Indicacions per escollir la instncia contextual

si la restricci restringeix el valor de latribut duna classe, aquesta s la classe
candidata
si la restricci restringeix el valor dels atributs de ms duna classe, qualsevol
daquestes ns la candidata
qualsevol restricci hauria de navegar a travs del menor nombre possible
dassociacions
61
13
Com especificar en OCL: exemples
Totes les persones han de ser majors dedat

Persona
self.edat >= 18
-- s preferible a
Empresa
self.empleat -> forAll (age >= 18)
Els dos membres dun matrimoni no poden treballar a la mateixa empresa

Empresa
self.empleat.esposa -> intersection(self.empleat) -> isEmpty
-- s preferible a
Persona
self.esps.contractador -> intersection(self.contractador) -> isEmpty
and
self.esposa.contractador -> intersection(self.contractador) -> isEmpty
Ning no pot ser director i empleat duna empresa

Empresa
not(self.empleat -> includes(self.director))
Persona
not(self.empresesDirigides.empleat -> includes(self))
-- quina s preferible en aquest cas?
14
Operacions estndard de tipus boole
Operaci
or
and
or exclusiu
negaci
igualtat
desigualtat
implicaci
if-then-else
Notaci
Resultat
a or b
a and b
a xor b
not a
a=b
a <> b
a implies b
if a then b else b
boole
boole
boole
boole
boole
boole
boole
tipus de b o b
62
15
Operacions estndard de tipus string
Operaci
concatenaci
tamany
substring
igualtat
desigualtat
Notaci
Resultat
string.concat(string)
string.size
string.substring(int,int)
string1 = string2
string1 <> string2
string
integer
string
boole
boole
16
Operacions estndard de tipus col.lecci

Operaci
size
count(object)
includes(object)
includesAll(collection)
isEmpty
notEmpty
sum()
exists(expression)
forAll(expression)
select(expression)
reject(expression)
union(collection)
intersection(collection)
Resultat
nombre delements de la col.lecci
nombre docurrncies de lobjecte
cert si lobjecte pertany a la col.lecci
cert si els elements del parmetre collection sn a la
col.lecci actual
cert si la col.lecci s buida
cert si la col.lecci no s buida
suma de tots els elements (els elements shan de poder sumar)
expression s cert per algun element?
expression s cert per tots els elements?
selecciona el subconjunt delements per als quals expression
s cert
elimina el subconjunt delements per als quals expression s cert
resultat dunir les dues col.leccions
resultat de la intersecci
63
17
Bibliografia
Unified Modeling Language

Object Constraint Language Specification, v. 1.1.
Setembre 1997.
J.Warmer; A.Kleppe
The Object Constraint Language: precise modeling with UML
Addison-Wesley, 1999.
Pgines web amb informaci dOCL:
http://www.software.ibm.com/ad/ocl
http://www.rational.com
http://www.omg.org
64
ES:E - Model de Casos ds en UML
Model de Casos ds en UML
Propsit
Casos ds
Diagrama de Casos ds
Especificaci de Casos ds
Estructuraci de Casos ds
Identificaci de Casos ds

Model
DAnlisi
Model de
Casos ds
Model
Conceptual
Model del
comportament
del sistema
Casos ds
- nivell alt
- essencial
Diagrames
Esttics
dEstructura
pels Objectes
del Domini
Diagrames de
seqncia
del sistema
Diagrames
de Casos ds
Model dels
Estats
Diagrames
dEstat per
Objectes i
Casos ds
Contractes
per les
operacions
del sistema
65
Determinaci de requeriments dun sistema software:

Identificar i categoritzar les funcions del sistema (requeriments funcionals).
Identificar i categoritzar els atributs del sistema (requeriments no funcionals).
Relacionar els requeriments no funcionals amb els funcionals.
Especificaci dels requriments dun sistema software

Comprensi dels requeriments.
Organitzar els requeriments segons les funcions del sistema.
Delimitar la frontera del sistema.
Model de Casos ds: Quines son les funcions del sistema PER CADA ACTOR?
mfasi: USOS del sistema, valor afegit per cada actor
Casos ds
Cas ds: Document que descriu una seqncia desdeveniments que
realitza un actor ( agent extern ) que usa el sistema per dur a
terme un procs que t algun valor per a ell [Jacobson 92].
Extracci de
diners en
caixer
Actor: Entitat externa al sistema que participa en la histria del Cas ds.
Pot ser una persona, un conjunt de persones, un sistema hardware,
un sistema software o un rellotge.
Iniciador: Genera lestmul que provoca lexecuci del procs (nic).
Participant: Interv en el procs.
66
Diagrama de Casos ds
Mostra conjuntament els diferents casos ds dun sistema

software, els actors i les relacions entre actors i casos ds.
Entorn del sistema

Nom del sistema
Cas ds 1
Actor1
Cas ds 2
Actorn
Cas ds i
Comunicaci
Especificaci de Casos ds
Dalt nivell: Descripci breu de les accions del cas ds.
Cas ds: Nom del cas ds.
Actors: Llista dactors, iniciador.
Propsit: Objectiu del cas ds.
Resum: Descripci breu de les activitats que shan de dur a terme.
Tipus: 1 - primari, secundari, opcional.
2 - real o essencial.
Expandida: Descripci detallada de les accions i els requeriments.
Afegeix a lespecificaci dalt nivell:
Referncies creuades: Requeriments a qu fa referncia.
Curs tpic desdeveniments: Descripci detallada de la interacci
(conversa) entre els actors i el sistema.
Descripci dels esdeveniments pas a pas.
Cursos alternatius: Descriu excepcions al curs tpic.
67
Exemple: Terminal de Punt de Venda
Un terminal de punt de venda (TPV) s un sistema computeritzat usat per enregistrar

les vendes i gestionar pagaments. Susa, principalment en supermercats i grans
magatzems. Inclou components hardware (com lordinador i lscanner del codi de
barres) i software per executar el sistema.
Sens demana que especifiquem el software daquest sistema.
Ref #
R1.1
R1.2
R1.3
R1.4
R1.5
R1.6
R1.7
R2.1
R2.2
R2.3
Exemple TPV: Funcions bsiques

Funci
Categoria
Enregistrar la venda actual - els productes comprats.
evident
Calcular el total de la renda actual, incloent impostos i clcul de
evident
punts de client.
Capturar la informaci dels productes comprats dun codi de barres,
evident
usant un scanner o b a partir de lentrada manual del codi de barres
(Universal Product Code).
Descomptar les quantitats venudes de lestoc, quan la venda es confirmi. hidden
Guardar informaci sobre les vendes realitzades.
hidden
El caixer ha didentificar-se en iniciar una sessi amb un identificador
evident
i una clau daccs.
Mostrar la descripci i el preu de cada producte comprat.
hidden
Tractar els pagaments en efectiu capturant la quantitat entregada
evident
pel client i calculant el canvi.
Tractar els pagaments amb tarja de crdit capturant el nmero de la
evident
tarja des dun lector de targes o manualment, demanar confirmaci
del pagament al servei dautoritzaci de crdit (extern) amb una
connexi via modem.
Enregistrar els pagaments amb tarja per tal que puguin ser facturats.
hidden
68
Example TPV: Diagrama de Casos ds

Terminal Punt de Venda
Iniciar Sessi
Compra de productes
Caixer
Retornar producte
Client
Acabar Sessi
Responsable
de compres
Fixar Preus
Comprar a provedors
Fer ofertes
Provedor
Director
comercial
10
Exemple TPV: Entorn del sistema

TPV
Compra de
productes
CAIXER
Retornar
producte
CLIENT
Iniciar
sessi
supermercat
Compra de
productes
CLIENT
Retornar
Producte
69
11
Exemple TPV: especificaci del cas ds compra de productes en efectiu

Cas ds: Compra de productes en efectiu.
Actors: Client (iniciador), Caixer.
Propsit: Capturar una venda i el seu pagament en efectiu.
Resum: Un client arriba a la caixa amb productes per comprar.
El caixer enregistra els productes i recull el pagament.
En acabar, el client sen va amb els productes.
Tipus: Primari i essencial.
Referencies creuades: R1.1, R1.2, R1,3, R1.7, R2.1
Curs tpic desdeveniments
Accions dels Actors
Resposta del sistema
1. El cas ds comena quan un client arriba

a la caixa amb els productes per comprar.
2. El Caixer indica que comena una nova venda
4. El Caixer enregistra lidentificador de
cada producte.
Si hi ha ms duna unitat del producte el
Caixer pot entrar la quantitat.
6. En acabar lentrada de productes el
caixer ho indica.
3. Dna la venda per iniciada

5. Determina el preu del producte i afegeix la
seva informaci al compte.
7. Calcula i mostra el total del compte.

(continua)
12
Accions dels Actors
8. El Caixer li diu el total al client.

9. El Client entrega una quantitat de diners
possiblement ms gran que el total del
compte.
10. El Caixer indica els diners que ha
rebut.
13. El Caixer diposita els diners rebuts
a la caixa i extreu el canvi.
El Caixer dna el canvi i el rebut al
client.
14. El Client sen va amb els productes
comprats.
11. Calcula i mostra el canvi al Client.

Imprimeix un rebut.
12. Enregistra la venda que sacaba de
fer.
Cursos Alternatius
Linia 4: Sentra un identificador de producte invlid. Indicar error.
Linia 9: El Client no t prous diners. Cancel.la la venda.
70
13
Estructuraci de Casos ds: seccions

Cas ds: Compra de productes
Accions dels Actors

2. (passos intermedis exclosos)...
9. El Client escull la forma de pagament:
a. If en efectiu, see section pagar en efectiu
b. If amb tarja see section pagar amb tarja
10. Enregistra la venda que sacaba de fer.
11. Imprimeix un rebut.
12. El Caixer dna el rebut al client.
13. El Client sen va amb els productes
comprats.
14
Estructuraci de Casos ds: seccions

Section: Pagar en efectiu.
Accions dels actors

1. El Client entrega una quantitat de diners
possiblement ms gran que el total del
compte.
2. El Caixer indica els diners que ha
rebut.
4. El Caixer diposita els diners rebuts i
extreu el canvi.
El Caixer dna el canvi al client.
3. Calcula i mostra el canvi al Client.
Cursos Alternatius
Linia 4: Efectiu insuficient per tornar el canvi. Demanar canvi al supervisor.
Section: Pagar amb tarja.
Cursos tpics i alternatius per lhistria del pagament amb tarja.
71
15
Estructuraci de Casos ds: Relaci Usa

Usa: Relaci dun cas ds concret amb un dabstracte, en la qual la conducta
definida pel cas concret usa (empra) la conducta definida en labstracte.
Permet reduir la redundncia quan una seqncia daccions s compartida per diversos
casos ds
Caixer
<<usa>>
Compra de productes
Pagar amb tarja
Client
Cas ds Real
Caixer
Compra de productes + Pagar amb tarja
Client
16
Exemple TPV: Usa

Caixer
<<usa>>
Comprar
productes
Client
<<usa>>
Pagar en
efectiu
Pagar amb
targa
<<usa>>
<<usa>>
Servei
dautoritzaci
de crdit
Retornar producte
Comptabilitat
Accions dels Actors

2. (Passos intermedis exclosos)...
9. El Client escull el tipus de pagament:
a. If s en efectiu initiate
Pagar en efectiu
b. If s amb targa initiate
Pagar amb tarja
10. Enregistra la venda que sacaba de

fer.
11. Imprimeix un rebut.
12. El Caixer dna el rebut al client.

13. El client sen va amb els productes comprats
72
17
Estructuraci de Casos ds: Relaci Estn

Estn: Relaci dun cas ds a un altre especificant com la conducta definida pel
primer pot sser inserida en la conducta definida pel segon. Tamb es pot dir que
el primer s semblant al segon, per fa una mica ms.
Una extensi es comporta com si fssin accions que safegeixen en un punt concret de
lespecificaci original si es dna una certa condici
Estudiant
<<estn>>
Matricular Erasmus
Matricular estudiant
18
Identificaci de casos ds
Mtode basat en els actors
1. Identificar els actors relatius al sistema.
2. Per cada actor, identificar els processos que inicia
o en els quals participa.
Mtode basat en els esdeveniments

1. Identificar els esdeveniments externs als que el
sistema ha de respondre.
2. Relacionar els esdeveniments amb els actors i
casos ds.
73
19
Casos ds essencials versus casos ds reals
Essencial
molt abstracte
Real
molt concret
Essencial
Acci de lactor
1. El client sidentifica.
3. Etc...

2. Presenta opcions
4. Etc...
Real
Acci de lactor
1. El client insereix la tarja.
3. Entra el PIN al teclat
5. Etc...

2. Demana el PIN
4. Mostra el men dopcions
6. Etc...
20
Bibliografia
C. Larman
Applying UML and Patterns.
An Introduction to Object-Oriented Analysis and Design.
Prentice Hall, 1998. (Cap. 6)
I.Jacobson, G.Booch, J.Rumbaugh

The Unified Software Development Process
Addison-Wesley, 1999. (Cap. 6,7)
74
ES:E - Model del Comportament en UML
Model del comportament en UML
Introducci
Diagrames de seqncia del sistema
Contractes de les operacions del sistema
Altres consideracions
Compartici dinformaci entre les operacions dun diagrama

Informaci elemental vs informaci composta
Nombre desdeveniments del diagrama de seqncia
Redundncia entre els models
Bibliografia
Model dAnlisi (Especificaci)

Model
DAnlisi
Model de
Casos ds
Model
Conceptual
Model del
comportament
del sistema
Model dels
Estats
Casos ds
- nivell alt
- essencial
Diagrames
Esttics
dEstructura
pels Objectes
del Domini
Diagrames de
seqncia
del sistema
Diagrames
dEstat per
Objectes i
Casos ds
Diagrames
de Casos ds
Contractes
per les
operacions
del sistema
75
Descripci del comportament en OO

Els objectes es comuniquen mitjanant la invocaci doperacions
daltres objectes
Especificaci del comportament en OO

SISTEMA
Considerem un tipus especial sistema que engloba tots els objectes

Lespecificaci del comportament es fa amb el model del comportament del
sistema
76
Model del comportament del sistema
Diagrames de seqncia del sistema:

Mostren la seqncia desdeveniments entre els actors i el sistema.
Permeten identificar les operacions del sistema
Contractes per les operacions del sistema:

Descriuen lefecte de les operacions del sistema
Objectius:
Punt de partida:
identificar els esdeveniments i les operacions del sistema

casos ds
la descripci dels diagrames de seqncia del sistema s posterior a la
descripci dels casos ds
Casos ds:
descriuen com els actors interaccionen amb el sistema software
lactor genera esdeveniments cap al sistema que exigeixen lexecuci
dalguna operaci com a resposta (durant la interacci)
a partir dels casos ds podem identificar quins sn els esdeveniments
que van dels actors cap al sistema
diagrames de seqncia del sistema
77
Mostra, per a un escenari particular dun cas ds :

els esdeveniments generats pels actors externs
el seu ordre
els esdeveniments interns al sistema (operacions) que resulten de la
invocaci
Definirem un diagrama de seqncia per cada curs rellevant

desdeveniments dun cas ds
Exemple: comprar producte

sistema com a caixa negra
actor
:Caixer
:Sistema
iniciVenda(pv )
:venda
entrarProd(venda,prod,quant)
fiVenda(venda)
:import
pagament(venda,importPag)
:canvi
esdev. del sistema

invoca operaci
78
Construcci dun diagrama de seqncia
1. Dibuixar una lnia vertical que representa el sistema

2. Dibuixar una lnia per cada actor que interacciona directament
amb el sistema
3. Del curs desdev. del cas ds, identificar els esdeveniments
externs generats pels actors. Mostrar-los al diagrama
10
Representaci diteracions desdeveniments
:Actor
:Sistema
esdev1()
iteraci dun sol
esdeveniment
*
*
iteraci duna
seqncia desdev.
esdev2()
esdev3()
esdev4()
79
11
Esdeveniments i operacions
Esdeveniment del sistema: Esdeveniment extern generat per un

actor
Operaci del sistema: Operaci interna que sexecuta com a
resposta a la comunicaci de lesdeveniment
La comunicaci dun esdeveniment del sistema provoca lexecuci

duna operaci del sistema amb el mateix nom i els mateixos
parmetres
12
Operacions del sistema
Les operacions del sistema sagrupen com a operacions del tipus

especial sistema
En canvi, les operacions no sassignen a objectes concrets durant
letapa despecificaci
Exemple:
SISTEMA
iniciVenda(pv ) :venda
fiVenda(venda) :import
pagament(venda,importPag): canvi
80
13
Esdeveniments i el lmit del sistema
Per identificar els esdeveniments del sistema s necessari haver

delimitat clarament la frontera del sistema
Els esdeveniments del sistema sn els que estimulen directament
al sistema
Exemple:
:Caixer
:Sistema
iniciVenda
Lactor client no interacciona

directament amb el sistema,
noms ho fa el caixer
entrarProd
fiVenda
pagament
frontera del
sistema
14
Contractes de les operacions
Contracte duna operaci

Descriu el comportament del sistema en termes de:
quins sn els canvis destat de la base dinformaci
quines sn les sortides que el sistema proporciona
quan sinvoca loperaci
El tipus de descripci s declaratiu:

lmfasi es posa en el qu far loperaci ms que en el com ho far
Els contractes de les operacions inclouen primordialment:

precondicions i postcondicions que descriuen els canvis destat
sortides
81
15
Contractes de les operacions: components

Name:nom i arguments de loperaci (signatura de loperaci)
Responsibilities:
Descripci informal del propsit de loperaci
Exceptions:
Descripci de la reacci del sistema a situacions excepcionals
Preconditions:
Assumpcions sobre lestat del sistema abans de la invocaci de loperaci
Postconditions:
Canv is destat que shan produit:
- altes/baixes dinstncies de classes dobjectes
- altes/baixes dinstncies dassociacions
- modificaci datributs
- generalitzaci dun objecte
- especialitzaci dun objecte
- canvi de subclasse dun objecte
Sortida:
Descripci de la sortida que proporciona loperaci en pseudo-OCL
Observeu el lligam que existeix entre els contractes de les

operacions i lesquema conceptual
16
Exemple: esquema conceptual de partida
PuntDeVenda
num-pv
*
t
Venda
dia
hora
/import
1..* LniaDeVenda
consta de
quantitat
*
correspon a
1
Producte
codi
preu
descripci
RI textuals:
1- La clau externa de PuntDeVenda s num-pv
2- La clau externa de Producte s codi
3- Un punt de venda no pot tenir ms duna venda amb el mateix dia i hora
82
17
Exemple: operaci iniciVenda

Name: iniciVenda(pv) :venda
Responsibilities:
Iniciar lenregistrament duna venda
Exceptions:
Si no existeix cap PuntDeVenda amb num-pv=pv, indicar error
Preconditions:
Existeix un PuntDeVenda amb num-pv=pv
Postconditions:
- alta duna instncia V de Venda amb el dia i lhora actuals
- alta duna instncia de lassociaci t que associa la venda V i la
instncia de PuntDeVenda amb num-pv=pv
Sortida: V
18
Exemple: operaci entrarProd

Name: entrarProd(venda,prod,quant)
Responsibilities:
Enregistrar un lnia duna venda
Exceptions:
Si no existeix cap Producte amb codi=prod, indicar error
Preconditions:
Existeix un Producte amb codi=prod
Postconditions:
- alta duna instncia de LniaDeVenda L amb quantitat=quant
- alta duna instncia de lassociaci consta de que associa L i venda
- alta duna instncia de lassociaci correspon a que associa L i el
producte amb codi=prod
Sortida:
83
19
Exemple: operaci fiVenda

Name: fiVenda(venda) :import
Responsibilities:
Finalitzar lenregistrament duna venda i mostrar limport a pagar
Exceptions:
Preconditions:
Postconditions:
Sortida: import = venda.import
20
Exemple: operaci pagament

Name: pagament(venda,importPag): canvi
Responsibilities:
Mostrar el canvi a retornar
Exceptions:
Si importPag < venda.import indicar error
Preconditions:
importPag venda.import
Postconditions:
Sortida: canvi = venda.import - importPag
84
21
Compartici dinformaci entre les operacions dun diagrama
UML no precisa de quina manera les operacions dun diagrama de seqncia poden
compartir informaci
Dues possibles solucions sn:
Mitjanant arguments
addicionals de les operacions
:Caixer
Mitjanant informaci addicional a

lesquema conceptual
:Sistema
:Caixer
:Sistema
iniciVenda(pv)
iniciVenda(pv)
:venda
:venda
entrarProd(prod,quant)
fiVenda(venda)
Venda
dia
hora
/import
fiVenda()
:import
:import
pagament(importPag)
:canvi
VendaEnCurs
:canvi
Restricci implcita: El valor de largument

venda s el mateix a tots els esdeveniments
del diagrama
22
Informaci Elemental vs Informaci Composta
La informaci tractada per una operaci sexpressa tant a nivell dels

parmetres com de la sortida que apareixen a la signatura de loperaci
Hi ha dos tipus dinformaci:

Informaci Elemental: cont un nic element dinformaci indivisible
Propietat
Classe dobjectes predefinida: Integer, Real, ...
Informaci Composta: s una composici dinformacions elementals (i, per
tant, cal especificar com es defineix la composici)
Exemple: ResumVendes(num-pv) que retorna un llistat de vendes amb la informaci:
Per cada Producte p v enut en aquell PuntDeVenda num-pv mostrar
- el codi del producte
- la quantitat total venuda de p a num-pv
ResumVendes (num-pv:Integer): ???
85
23
Informaci Composta - Definici

Problema: com sespecifica el contingut duna informaci composta?
En lactualitat, UML no proposa cap soluci
Utilitzarem una adaptaci de la definic de fluxes de dades que es fa en
lanlisi estructurada (Yourdon, 1993)
Mecanismes bsics de definici dinformaci composta
Inclusi: i1 = i2 + i3 + i4
Selecci: i1 = [i2 l i3 l i4]
Repetici: i1 = {i2 + i3 + i4}
Opcionalitat: i1 = i2 + (i3 + i4)
Exemple:
LlistatVendes = num-pv + {codi-prod + quantitat}
num-pv = Integer; codi-prod = Integer; quantitat = Integer
ResumVendes(num-pv:Integer) : LlistatVendes
24
Informaci composta - Contractes de les operacions
Les operacions necessitaran mecanismes per manipular (accedir, construir,

etc.) la informaci composta que apareix a la seva signatura
Es necessita estendre OCL per poder manipular informaci composta

Exemple: contracte de loperaci ResumVendes (num-pv): LlistatVendes
Nom: ResumVendes (num-pv): LlistatVendes
Responsabilitats: emetre el resum de vendes demanat
Tipus: sistema
Excepcions:Preconditions: Postconditions: Sortida:
Mostrar (num-pv)
Per cada producte p resultant de
(Producte.allInstances ->
select (p | p.LniaDeVenda.Venda.PuntDeVenda.num-pv->includes(num-pv))
Fer
Qt = (p.LniesdeVenda ->
(select (lv | lv.Venda.PuntdeVenda.num-pv = num-pv).quantitat) -> Sum)
Mostrar (p.codi-prod)
Mostrar (Qt)
86
25
Diagrama de seqncia: quants esdeveniments?
El nombre desdeveniments dun diagrama de seqncia depn de com es

produeix la interacci entre els actors i el sistema software.
:Caixer
:Sistema-X
:Sistema
iniciVenda(pv): venda
:Sistema
fer-Venda(infoVenda)
entrarProd(venda, prod, quant)
fiVenda(venda): import
infoVenda = pv + {prod, quant} + importPag
pagament(venda, importPag): canvi
Ambds diagrames suposen la mateixa

entrada dinformaci al sistema
Els dos diagrames de seqncia poden ser

correctes, segons les circumstncies
26
Redundncia - Exemple
Lesquema Conceptual cont restriccions dintegritat (grfiques i textuals)
Els contractes de les operacions tenen precondicions, que sn requeriments del

contingut de lesquema conceptual per poder executar una transacci
Cal que les precondicions incloguin la comprovaci de les restriccions del M.Conceptual?
Empleat
codi-emp
sou
R.I. textual: dos empleats
no poden tenir el mateix codi
Nom: AltaEmpleat (codi-emp, sou)

Responsabilitats: donar dalta lempleat
Excepcions: Preconditions: no existeix Empleat amb codi-emp
Postconditions:
creaci dun nou objecte Empleat amb
codi-emp i sou
Sortida: -
Cal posar aquesta precondici ???
87
27
Redundncia - Definici
Una especificaci s redundant si un mateix aspecte del sistema

software est especificat diverses vegades.
La redundncia dificulta la modificabilitat de lespecificaci perqu si

varia aquell aspecte cal modificar tots els models que hi fan referncia.
Lespecificaci no hauria de ser redundant !!!
Redundncies possibles:
Entre lEsquema Conceptual i els Contractes
Entre els Diagrames de Seqncia i els Contractes
...
28
Redundncia - Esq. Conceptual i Contractes (I)

Persona
nom-p
0..1
0..3
t
Cotxe
matr
any
Significat habitual:
:Persona
:Sistema
CompraCotxe(nom-p,matr)
Nom: CompraCotxe (nom-p,matr)

Responsabilitats: compra dun cotxe
Excepcions:
(les que es dedueixen de les prec.)
Preconditions:
- existeix Persona p amb nom-p
- existeix Cotxe c amb matr
- p no t c
- p no t ja 3 cotxes
Postconditions:
- creaci duna associaci t entre p i c
Sortida: -
Significat alternatiu:
Nom: CompraCotxe (nom-p,matr)
Responsabilitats: compra dun cotxe
Excepcions:
(les que es dedueixen de les prec.)
Preconditions:
- existeix Persona p amb nom-p
- existeix Cotxe c amb matr
- p no t c
Postconditions:
- Si p t ja 3 cotxes llavors
eliminar lassociaci entre p i el
cotxe c de ms antiguitat
- creaci duna associaci t entre p i c
Sortida: -
88
29
Redundncia - Esq. Conceptual i Contractes (II)
Com shan dinterpretar els contractes en relaci al Model Conceptual?

Precondicions:
qu ha de contenir el Model Conceptual per intentar executar una
operaci
Restriccions del Model Conceptual:

Estan garantides desprs de lexecuci de totes les operacions que
participen en un cas ds
Es rebutgen totes les operacions dun cas ds si la seva execuci
viola (globalment) alguna restricci dintegritat del Model Conceptual
30
Redundncia - Esq. Conceptual i Contractes (III)

Persona
nom
adrea
parla
1..*
Cas ds: Afegir-Persona-1

:Persona
Cas ds: Afegir-Persona-2
:Sistema
:Persona
:Sistema
AltaPersona(nom,adrea)
AltaPersona(nom,adrea)
Idioma
nom
nm-parlants
ParlaIdioma(nom, idioma)
No permet afegir mai una persona !

Nom: AltaPersona(nom,adrea)
Preconditions:
Postconditions:
- creaci dun objecte Persona amb
el nom i ladrea especificats
Sortida:
Nom: ParlaIdioma(nom,idioma)
Preconditions:
- existeix idioma amb nom=idioma
Postconditions:
- creaci duna associaci parla entre
la persona amb nom=nom i lidioma
Sortida:
89
31
Redundncia - Diagrames de Seqncia i Contractes

Els diagrames de seqncia defineixen un ordre dinvocaci de les
operacions
Les operacions no han dincorporar informaci per garantir que
aquest ordre es compleixi
:Caixer
:Sistema
Nom: Pagament (venda, importPag): canvi
Preconditions:
- existeix venda venda
- la venda venda ha finalitzat
entrarProd(venda, prod, quant)
Postconditions:
...
Sortida:
fiVenda(venda): import
pagament(venda, importPag): canvi
sn redundants
32
Bibliografia
C. Larman
Prentice Hall, 1998. (Cap. 13, 14)
J. Rumbaugh, I.Jacobson, G.Booch

The Unified Modeling Language Reference Manual
G.Booch, J. Rumbaugh, I.Jacobson

90
ES:E - Model dels Estats en UML
Model dels Estats en UML
Introducci
s dels diagrames destat
Exemples
Accions i condicions duna transici
Estats imbricats
Bibliografia

Model
DAnlisi
Model de
Casos ds
Model
Conceptual
Model del
comportament
del sistema
Model dels
Estats
Casos ds
- nivell alt
- essencial
Diagrames
Esttics
dEstructura
pels Objectes
del Domini
Diagrames de
seqncia
del sistema
Diagrames
dEstat per
Objectes i
Casos ds
Diagrames
de Casos ds
Contractes
per les
operacions
del sistema
91
Model dels Estats
Objectius:
crear diagrames destat per objectes i casos ds
Esdeveniments, estats i transicions:

Esdeveniment:
tot all que requereix una resposta del sistema software
Estat:
condici dun objecte o dun cas ds en un moment del temps
Transici:
canvi destat com a conseqncia dun esdeveniment
Diagrama destats
Un diagrama destats mostra la seqncia destats que passa un objecte (o una interacci)
durant la seva vida en reposta als estmuls rebuts, juntament amb les seves respostes.
Nom super estat

Nom Estat
Variable: tipus=valor inicial
Esdev.(arguments)[condici]/acci
Entry/acci
do/activitat
exit/acci
event/acci
Nom Estat
92
Canvi destat civil duna persona

Persona
estat-civil
Soltera
Casada
neixement
Separada
Divorciada
Soltera
Vdua
casament
Casada
divorci
casament
Divorciada
divorci
separaci
Separada
casament
enviudar
Vdua
enviudar
s dels diagrames destat
Un diagrama destats es pot especificar per a una:

Classe dobjectes:
per descriure perqu els objectes canvien de subclasse
les subclasses dun diagrama destats no tenen perqu aparixer
explcitament a lesquema conceptual
per descriure classes dobjectes amb important comportament
dinmic
Cas ds:
per descriure la seqncia legal en la que els esdeveniments es
poden produir al mn real
p.ex. en una compra de producte no es pot fer el pagament fins que
no shagi tancat la venda.
93
Diagrama destats del cas dus comprar productes
entrarProd
Introduint
Productes
entrarProd
Esperant
Venda
fiVenda
Esperant
Pagament
pagamentEnMetl.lic
Autoritzant
Pagament
gestionaResposta
pagamentAmbTarja
Diagrama destats dun telfon

estat inicial
estat
lliure
despenjar
actiu
penjar
transici
esdeveniment
94
Accions i condicions duna transici
condici
lliure
despenjar [abonatVlid]
actiu
/marcarTo
penjar
acci
10
Estats imbricats
despenjar [abonatVlid]
/marcarTo
Actiu
Emetent To Marcar
lliure
Parlant
dgit
dgit
connectat
Marcant
Connectant
complet
penjar
95
11
Bibliografia
C. Larman
Prentice Hall, 1998. (Cap. 33)

B. Powel Douglass
Real-Time UML.
96
ES:E - Procs Unificat de Desenvolupament de Software
El Procs Unificat de Desenvolupament de Software
Etapes del procs iteratiu de desenvolupament del software

Cicles de desenvolupament
Exemple: compra de productes
Bibliografia
Procs de desenvolupament del software - Macro Nivell
1. Planificar i Elaborar - Planificar, definir requeriments,

construir prototipus, ...
2. Construir - Desenvolupament del sistema (especificaci, disseny, etc.)
3. Implantar - Implantar el sistema pel seu s.
Pla i
Elaboraci
Construcci
97
Implantaci
Etapa de planificaci i elaboraci

Inclou la concepci inicial del projecte, detecci de problemes, determinaci dobjectius,
investigaci dalternatives de canvi, planificaci i especificaci dels requeriments.
Pla i
Elaboraci
Construcci
Implantaci
1. Definir el Pla Inicial
2. Informe dInvest. Preliminar
3. Definir Requeriments
4. Definir Termes al Glossari
5. Implementar Prototipus
6. Definir Casos Ds
7. Definir Model Conceptual
8. Definir Esq. dArquitectura
9. Refinar el Pla.
Pla: calendari, pressupost, etc.

Informe dinvestigaci preliminar: motivaci, alternatives, necessitats de negoci.
Especificaci de requeriments: descripci declarativa dels requeriments
Glossari: diccionari de termes (conceptes, noms) i qualsevol informaci associada
Etapa de construcci
Pla i
Elaboraci
Cicle de
Desenvolupament 1
Refinar
pla
Sincr.
Artefactes
Implantaci
Construcci
Cicle de
Desenvolupament 2
Anlisi
Disseny
...
C onstrucci
Avantatges:
La complexitat mai no sobrepassa al disenyador
Primeres impressions molt rpidament, perqu la implementaci
duna petita part del sistema es fa molt rpidament.
98
Prova
Etapa de construcci: cicles de desenvolupament (I)

Letapa de construcci inclou diversos cicles de desenvolupament en els quals
el sistema es va estenent de forma progressiva.
Cicle de Desenvolupament 1
Refinar pla
Anlisi
Sincr. Artefactes
...
Disseny
Construcci
1. Definici dels casos

ds essencials
2. Refinar els
Diagrames
3. Refinar el Model
Conceptual
4. Refinar el
Glossari
5. Definir Diagrames
de Sequencia
6. Definir Contractes
dOperaci
Prova
7. Definir Diagrames
dEstat
Etapa de construcci: cicles de desenvolupament (II)
Refinar pla
Sincr. Artefactes
...
Anlisi
Disseny
Construcci
Prova
1. Definici dels casos

ds reals
2. Definir informes i
interfcies dusuari
3. Refinar larquitectura
del sistema
4. Definir els diagrames

dinteracci
5. Definir el diagrama de
classes de disseny
6. Definir lesquema de la
base de dades
99
Ordenar i prioritzar casos ds

Cicle de
desenvolupament
Cas ds A
Versi
Simplificada
...
...
...
Cicle de
desenvolupament
Cas ds A
Versi
Completa
...
...
...
Cicle de
desenvolupament
Cas ds B
...
...
...
Com prioritzar?
a. Inclouen funcions arriscades, crtiques o complexes.
b. Involucra tecnologia nova o arriscada.
c. Representen processos primordials pel negoci.
d. Impacte significatiu en el disseny (afegeix moltes classes
al domini o requereix molts serveis).
e. Permet obtenir informaci significativa respecte al
disseny amb poc esfor.
Cas ds C
...
...
...
Exemple: compra de productes
En un primer cicle de desenvolupament pot no interessar-nos distingir entre les

diverses formes possibles de pagament
:Caixer
:Sistema
iniciVenda(pv)
:venda
fiVenda(venda)
:import
ferPagament
Interessa desenvolupar el subsistema necessari per poder efectuar una compra
El contracte de pagament hauria de ser prou genric per no entrar en detalls de

la seva forma de pagament
100
Compra de productes - 2on cicle
Tenim tants diagrames de seqncia com formes de pagament possibles

Tots aquests diagrames parteixen del diagrama que sha fet al primer cicle de
desenvolupament.
:Caixer
:Sistema
Interacci comuna a
tot tipus de pagament
Interacci especfica al pagament en metl.lic

:Caixer
:Sistema
:canvi
10
Interacci especfica del pagament amb tarja

:Gesti Targes
:Caixer
:Sistema
:Sist. Autor. Crdit
pagTarjaCrdit(num -t,data-cad)
sol.licitaAprov(petici)
tractarResp.Tarja(resposta)
afegeixAprovaci(resposta)
Nom: pagTarjaCrdit (num-tarja, data-cad)

Responsabilitats: pagar amb la tarja de crdit
Excepcions:
Preconditions:
Postconditions:
- creaci dun nou PagamentAmbTarja pmt
- nova associaci entre pmt i la venda actual
- ...
Sortida:
- senvia una sol.licitud daprov aci al
servei dautoritzaci de crdit
Nom: tractarResp.Tarja (resposta)

Responsabilitats:
respondre a la resposta daprovaci rebuda
Excepcions:
Preconditions:
Postconditions:
- ...
Sortida:
- senvia una aprovaci al sistema de Gesti
de Targes perqu lenregistri
101
Bibliografia
C. Larman
Prentice Hall, 1998. (Cap. 13, 32)
I.Jacobson, G.Booch, J.Rumbaugh

The Unified Software Development Process.
102
11
Recull d'exercicis
103
Part I: Introducci
1.
Dna, i justifica, una definici de l'enginyeria del software.
2.
El cicle de vida anomenat "model espiral" est basat en quatre activitats: Planificaci,
Anlisi de risc, Enginyeria i Avaluaci. Comenta breument l'objectiu de cada una
d'aquestes activitats i com s'encadenen.
3.
Dna una definici de requeriment d'un sistema i d'especificaci de requeriments d'un

sistema.
4.
Indica la diferncia entre requeriments d'un sistema i requeriments del software.
5.
Resumeix les quatre estratgies per a determinar els requeriments.
6.
Defineix, i descriu breument, tres requeriments no funcionals, de diferent tipus, relatius al

projecte fet durant el curs.
7.
Una de les propietats desitjables de les especificacions s que siguin "traables"

(traceability). Defineix aquesta propietat.
8.
Una de les propietats desitjables de les especificacions s que siguin verificables. Defineix
quan es pot dir que una especificaci determinada compleix aquesta propietat. Posa un
exemple d'un fragment qualsevol d'una especificaci que sigui verificable i un altre que no
ho sigui.
9.
Molta gent argumenta que el terme "manteniment" s incorrecte aplicat al software - que les
activitats associades amb el manteniment del software no sn del tot "manteniment". Qu
en penses?. (Exercici 1.11 de Pressman 93).
1 0 . Indica quina relaci hi ha (si s que n'hi ha) entre la construcci de prototipus i el model de
desenvolupament de software en espiral.
11. Indica els tres tipus de manteniment de software que hi ha, i explica'ls breument.
12. Quins sn els avantatges i els inconvenients principals, si nhi ha, del cicle de vida basat en
el desenvolupament incremental i iteratiu dUML en relaci al cicle de vida clssic, en
cascada?
13. Explica breument la diferncia entre requeriments funcionals i requeriments no funcionals
dun sistema software. Defineix, i descriu breument, dos requeriments funcionals i dos
requeriments no funcionals, de diferent tipus, relatius al projecte fet durant el curs.
105
Part II : Model Conceptual en UML

1 . Feu el Model Conceptual amb la notaci UML d'un sistema que cont l'horari i les
assignatures de la Facultat, d'una sola enginyeria.
Una assignatura t un codi, un nom i un cert nombre de crdits (no distingirem entre
teoria, problemes i laboratoris), i est assignada a un departament. Les assignatures poden
ser obligatries o opcionals. Les assignatures poden estar relacionades per prerequisits,
pre/corequisits i corequisits.
L'horari indica per cada grup d'una assignatura (per exemple, ES:E grup 10) quins dies de
la setmana hi ha classe, en quina aula i en quines hores. Els perodes de classe podeu
suposar que sn d'una hora. Cada assignatura t un cert nombre d'hores de classe (no cal
distingir entre hores de teora, problemes i laboratoris, ni tenir en compte el concepte de
subgrup).
Expresseu grficament totes les restriccions que pugueu. Les restriccions que no es poden
expressar grficament i les regles de derivaci dels atributs derivats, si nhi ha, especifiqueules en el llenguatge OCL.
2 . Feu el Model Conceptual amb la notaci UML d'una empresa de transports que cont
informaci relativa a rutes, carreteres i poblacions.
L'empresa cobreix un mbit geogrfic comprs per unes 1000 poblacions. Cada poblaci
t un codi i un nom. Aquestes poblacions estan unides per unes 50 carreteres. Cada carretera
t un codi. Una carretera consta d'una srie de trams consecutius. En mitjana, hi ha 100
trams per carretera. Un tram d'una carretera es defineix per les dues poblacions que uneix i la
distncia en kilmetres entre elles. Tamb es considera la duraci del trajecte, en minuts,
entre aquestes dues poblacions, que, en el cas general, pot ser diferent segons sigui un sentit
o l'altre. Per una mateixa poblaci poden passar diverses carreteres.
Un exemple amb 9 poblacions, 3 carreteres i 10 trams podria ser:
autA2
com12
loc1
A
I
D
H
El trajecte que ha de recrrer un cami de l'empresa s una ruta. Hi ha unes 30 rutes, cada
una de les quals t un codi. Una ruta parteix i acaba en una mateixa poblaci, i consta d'una
serie de trams consecutius de la mateixa o diferents carreteres, que s'han de recrrer en una
certa direcci. Per exemple, la ruta 10 podria ser:
(B,C,autA2),(C,F,com12),(F,E,com12),(E,H,loc1),(H,E,loc1),(E,D,autA2),
(D,C,autA2),(C,B,com12)
106
3 . Feu el Model Conceptual amb la notaci UML d'un sistema que guardi i processi dades
sobre les segents relacions entre persones (no cal que aquestes informacions apareguin
explcitament al model, poden obtenir-se indirectament):
1. Casaments (entre dues persones).
2. Divorcis (id.)
3. Fills (o Pare de i Mare de)
El model hauria de mostrar explcitament les restriccions (suposades) segents:
a) Els casaments sn entre un home i una dona.
b) Dues persones noms es poden divorciar si estaven casades.
c) Una persona s filla d'un home i d'una dona que es van casar.
Pots suposar que:
1. Dues persones no es casen entre elles ms d'una vegada.
2. Les persones s'identifiquen pel su nom.
3. De les persones en sabem noms el seu sexe.
4. No estem interessats en cap altre atribut.
Un cop fet el model, mostreu-ne la instanciaci completa amb les dades segents:
En Joan i la Maria es van casar.
L'Helena s una filla del Joan i la Maria.
En Joan i la Maria es van divorciar.
La Maria es va casar amb el Jordi.
L'Albert s un fill del Jordi i la Maria.
4 . Feu el Model Conceptual amb la notaci UML d'un sistema que guardi i processi dades
sobre les segents relacions entre persones i cotxes:
1. Propietari: un cotxe t una o ms persones propietries.
2. Conductor habitual: un cotxe noms t una, i noms una, persona que n's la conductora
habitual.
(No cal que aquestes informacions apareguin explcitament al model: poden obtenir-se
indirectament).
El diagrama hauria de mostrar explcitament les restriccions (suposades) segents:
a) El conductor habitual d'un cotxe s un dels seus propietaris (o l'nic).
b) Una persona pot sser conductora habitual de ms d'un cotxe.
Pots suposar que:
1. Els cotxes d'identifiquen per la seva matrcula.
2. Les persones s'identifiquen pel su nom.
3. No estem interessats en cap altre atribut.
Un cop fet el diagrama, mostreu-ne la instanciaci completa amb les dades segents:
En Joan i la Maria sn propietaris del cotxe A.
En Jordi i la Maria sn propietaris del cotxe C.
En Joan s propietari del cotxe B.
En Joan s el conductor habitual del cotxe B.
La Maria s la conductora habitual del cotxe A.
La Maria s la conductora habitual del cotxe C.
107
5 . Feu el Model Conceptual amb la notaci UML d'un sistema que gestioni un conjunt d'escales
mecniques d'una gran superfcie comercial. Cada escala s'identifica per un codi. En un
moment determinat, una escala pot estar en funcionament o en reparaci. Independentment
d'aix, una escala pot estar pujant, baixant o parada, per si est en reparaci est
necessriament parada.
Si una escala est en reparaci, el sistema guarda quin era l'estat (pujant, baixant, parada)
que tenia l'escala en el moment de passar a reparaci.
6 . Considera una empresa que es dedica a la fabricaci d'aparells electro-mecnics i est
interessada en construir un sistema que inclogui, entre altres coses, informaci sobre la
composici dels aparells. Cada aparell consta d'una o ms unitats d'un o ms components.
Un component pot sser una matria primera o un altre aparell (que alhora tindr
components). Una matria primera s un producte que s'adquereix a un (i noms un)
provedor, i no s fabricada per l'empresa. Tant els aparells com les primeres matries tenen
un codi identificador tipus string(5) i un nom tipus string(50).
Per exemple, l'aparell A requereix 5 unitats de l'aparell B, 8 unitats de l'aparell C i 4 unitats de la
matria primera D (la qual s subministrada pel provedor P1). L'aparell B consta de 10 unitats de la
matria primera E (del provedor P2). L'aparell C consta d'una unitat de l'aparell F, el qual consta de 5
unitats de la matria primera G (del provedor P1).
Un component en la fabricaci d'un cert aparell pot tenir zero o ms substituts. Un substitut
s un altre component que es pot utilitzar si no es disposa del previst en la fabricaci d'un
aparell determinat.
Per exemple, si no es disposa d'un aparell B quan es fabrica l'A es pot utilitzar el F en el seu lloc.
Un substitut d'un component que s un aparell pot sser una matria primera o un altre
aparell. Un substitut d'un component que s una matria primera noms pot sser una altra
matria primera del mateix provedor.
Per exemple, si no es disposa de la matria primera G quan es fabrica l'aparell F, es pot utilitzar en el
seu lloc la matria primera H. Aquesta matria primera H s subministrada per P1. Per tant, compleix
la restricci indicada.
Feu el Model Conceptual d'aquest sistema amb la notaci UML. Expresseu grficament
totes les restriccions que pugueu. Les restriccions que no es poden expressar grficament i
les regles de derivaci dels atributs derivats, si nhi ha, especifiqueu-les en el llenguatge
OCL. Heu d'indicar tamb, necessriament, la instanciaci del model amb les dades de
l'exemple que s'ha donat.
Si en fer aquest exercici us cal ms informaci, feu els supsits que creieu ms adients, i
indiqueu-los ben clarament.
7. Considera un Comit organitzador d'un congrs que est interessat en construir un sistema
que inclogui, entre altres coses, informaci sobre les ponncies que s'hi presentaran. Cada
ponncia t un codi i un ttol i est escrita per un o ms autors. Un cop rebudes, cada
ponncia s'envia a un o ms revisors. Els revisors no poden ser autors de cap ponncia. Al
cap d'un temps, els revisors envien els seus informes de cada ponncia que han de revisar.
A vegades, un revisor no envia cap dels informes, o no n'envia algun dels que havia de fer.
De tota manera, sempre es t almenys un informe de cada ponncia. Cada informe, quan es
reb, dna una puntuaci (de 0 a 10) de la ponncia i classifica la ponncia en una de les
sessions que hi haur al congrs. Cada sessi correspon a un dels dies del congrs, amb
una hora inicial i una hora final.
108
Per exemple, la ponncia 10, de ttol 'YSM' s escrita pels autors A1 i A2. La ponncia s'envia als
revisors Ra, Rb i Rc. El primer li dna un 5 i la classifica en la sessi 'Anlisi Estructurada
Moderna'. El segon li dna un 8 i la classifica en la sessi 'Nous mtodes d'especificaci'. El tercer es
va oblidar d'enviar l'informe.
La ponncia 23, de ttol 'La importncia dels esdeveniments' s escrita pels autors A2 i A5 i s'envia
al revisor Rb, que no contesta, i al Rd, que la qualifica amb un 3 i la classifica en la sessi 'Nous
mtodes d'especificaci'.
De cada autor o revisor, el sistema en t un codi identificador, el seu nom i la seva adrea.
En una certa data, el Comit es reuneix i, partint dels informes, decideix quines ponncies
accepta i quines refusa. Les ponncies acceptades s'assignen a una sessi, que ha de ser
una de les suggerides pels revisors. Per les ponncies rebutjades, es guarda el motiu. Totes
les ponncies acaben sent acceptades o refusades.
Per exemple, es decideix acceptar la ponncia 10 i assignar-la a la sessi 'Anlisi estructurada
moderna'. La sessi 'Anlisi estructurada moderna' es far el dia 29/04/94, de 11 a 13. La ponncia 23
es refusa pel motiu "molt llarga".
8 . Considera el cas d'una Federaci de ciclisme, que vol construir un sistema que tracti, entre
d'altres coses, dels resultats de les curses ciclistes. Les curses s'organitzen en edicions de
sries. Cada srie consta d'edicions, que es van fent peridicament. Una srie s'identifica
per un nom i una edici per la srie i l'any. Una edici consta d'un conjunt d'etapes, que
varien d'una edici a l'altra. Cada etapa t un nmero d'etapa, una longitud, una poblaci
inici i una poblaci final.
Per exemple, de la srie "Volta a Catalunya" se n'han fet tres edicions. La tercera edici tenia dues
etapes. La primera anava de Barcelona a Montserrat (50 Km.) i la segona de Montserrat a Poblet (200
Km.)
Un altre exemple pot ser la srie "Tour de France", de la qual se n'han fet 20 edicions. La darrera tenia
cinc etapes. La primera d'aquestes anava de Paris a Li, etc.
Interessa tamb que el sistema enregistri els ciclistes i la participaci a les curses. De cada
ciclista se n'haur de saber el seu nom, data de naixement, etc. Cada ciclista que participa a
una cursa la pot acabar o no. Si l'acaba s en una certa posici (classificaci) i si no l'acaba
s per un cert motiu, i interessa saber en quina etapa va crrer per darrera vegada. Tamb
cal enregistrar el resultat de ciclista en cada etapa. Com s obvi, un ciclista noms pot tenir
un resultat en una etapa si participava en la cursa corresponent.
Per exemple, els ciclistes C1, C2 i C3 participen a la tercera edici de la Volta a Catalunya. El C3 va
ser el primer, el C1 el segon i el C2 no va acabar, per malatia. La darrera etapa que havia fet era la
Barcelona a Montserrat. En la primera etapa el primer va ser el C3, el segon el C2 i el tercer el C1.
En la segona etapa, el primer va ser el C3 i el segon el C1.
Algunes etapes tenen Premi de Muntanya a l'arribada. Per aquestes etapes, cal enregistrar
quin dels ciclistes que hi va participar va guanyar el premi.
109
Per exemple, l'etapa Barcelona-Montserrat de la cursa que estem considerant tenia aquest premi (l'altra
no). El premi el va guanyar el C2, que, naturalment, havia participat a l'etapa.
9.
Considera una empresa que est interessada en construir un sistema que inclogui, entre
altres coses, informaci sobre els seus empleats. Cada empleat t un nmero de document
d'identitat, un nom i una adrea. Els empleats estan assignats a un, i noms un,
departament. Cada departament t un nom. Els departaments estan estructurats
jerrquicament, i cada departament pot dependre com a mxim d'un altre departament.
Cada Departament t un sol director, que ha de ser un dels empleats que hi estan assignats.
Per exemple,en Joan, la Maria, la Rosa i l'Albert i el Jordi sn empleats de l'empresa. En Joan
treballa al departament de Vendes, la Maria al Servei Tcnic Postvenda, la Rosa al Laboratori i
l'Albert i el Jordi a Recepci. Vendes depn de Direcci Comercial que, alhora, depn de Direcci
General. El Servei Tcnic Postvenda depn de Vendes, etc. La directora del Laboratori s la Rosa. El
director de Recepci s el Jordi.
Cada empleat s d'una (sola) categoria determinada. Noms hi ha tres categories: Venedor,
Tcnic i Administratiu. De cada categoria s'ha d'enregistrar els dies de vacances i el plus de
sou que tenen.
Per exemple, la Categoria Venedor t 30 dies de vacances i un plus de 10.000 Pts. La Categoria
Administratiu t 20 dies de vacances i 20.000 Pts. de plus. El Joan s venedor, la Maria i la Rosa
sn tcnics i l'Albert administratiu.
Pels empleats que sn venedors, s'ha d'enregistrar la zona on treballen. Una zona t un
codi i un nom. Un venedor noms treballa en una zona. Pels empleats que sn tcnics s'ha
d'enregistrar els estudis que tenen. Cada estudi t un codi, un nom i el Centre on
s'imparteix. Un mateix tcnic pot tenir diversos estudis. Pels empleats que sn
administratius, s'ha d'enregistrar els cursos de perfeccionament que han fet. Cada curs t
tamb un codi, un ttol i una data de realitzaci. Un mateix administratiu pot haver fet
diversos cursos.
Per exemple, el Joan treballa a la zona de Girona. La Maria t els estudis d'enginyer en informtica, i
la Rosa el d'electricista i el de mecnica. L'Albert ha fet dos cursos de perfeccionament: Mecanografia i
Arxiu.
110
10.
Considera el cas d'un aficionat a la msica rock, que vol construir un sistema que
gestioni informaci sobre la seva fonoteca. El sistema ha de permetre guardar i consultar
dades sobre els discos (compactes, LPs o cassettes) i els seus intrprets.
Els discos sn editats per cases discogrfiques. Cada casa discogrfica s'identifica per
un nom, i cada disc s'identifica per un codi alfanumric i tamb t un nom. Els discs
s'estructuren en seqncies de talls. Un tall s una gravaci continuada, normalment d'una
nica can, i s'identifica mitjanant un codi alfanumric. Tamb tenen un nom i una data
de gravaci. En un disc compacte hi ha una sola sequncia de talls, i cada tall apareix en
una certa posici de la seqncia. En un LP o un cassette hi ha una seqncia de talls per
cada cara i cada tall apareix en una posici d'una cara. Un mateix tall pot aparixer a
diversos discos (per exemple, al disc original i en una recopilaci) per no pot aparixer
ms d'un cop al mateix disc.
Per exemple, la casa discogrfica Zafiro ha editat el disc compacte D1 i el disc LP D2. D1 t la
can C1 com a primer tall i la can C2 com a segon tall. El disc D2 t la can C1 com a
primer tall de la primera cara, i la can C3 com a primer tall de la segona cara, i no t ms
talls.
Tamb es vol tenir informaci sobre els intrprets de cada tall. Un intrpret s'identifica
mitjanant un codi alfanumric; t un nom, un any de naixement i, si ja s mort, un any de
defunci. Un intrpret pot participar en la gravaci d'un tall jugant diversos papers (vocal,
guitarra solista, piano, bateria, etc.), per un paper determinat d'un tall noms el pot jugar
un intrpret. Malauradament, de vegades es desconeixen els intrprets d'un tall, o els
papers que hi han jugat.
Per exemple, l'intrpret I1 va nixer l'any 1930 i encara s viu. I2 va nixer el 1920 i es va
morir el 1965. Tots dos participaven en la gravaci de C1: I1 com a vocalista i piano, i I2 com
a bateria.
1 1 . Considereu el cas d'una companyia ferroviria que vol costruir un sistema que mantingui
els horaris previstos dels seus trens, i els horaris reals.
Cada lnia de tren t un codi que la identifica, un tipus de tren, una estaci d'origen i una
hora de sortida (prevista). Suposarem que cada lnia de tren circula diriament. Cada lnia
consta d'una srie de trams, que van d'una estaci a una altra. Les estacions s'identifiquen
per un codi. Com a mnim hi ha un tram, que surt de l'estaci origen de la lnia. Per cada
tram d'una lnia, ens interessar mantenir l'hora de sortida prevista de l'estaci origen i
l'hora d'arribada prevista a l'estaci dest. Podem suposar que l'hora d'arribada i la de
sortida d'una estaci sn del mateix dia.
Per exemple, la lnia R12 surt de Manresa, cada dia a les 10:00. s un tren Talgo i consta de dos trams. Va de
Manresa a Terrassa (on ha d'arribar a les 10:15 i sortir a les 10:17) i de Terrassa a Barcelona (on ha d'arribar a
les 10:31).
La lnia C240 surt de Barcelona, cada dia a les 23:00. s un tren Correu i consta de 3 trams. Va de Barcelona
a Terrassa (on ha d'arribar a les 23:20 i sortir a les 23:30), d'aquesta a Monistrol (on ha d'arribar a les 00:05 i
sortir a les 00:15) i d'aquesta a Sant Vicen de Castellet (on ha d'arribar a les 01:00).
111
Cada dia, el cap de l'estaci origen d'una lnia de tren enregistra l'hora de sortida real del
tren i la comunica immediatament al sistema. Si el tren no ha pogut sortir (s a dir, si s'ha
cancel.lat) s'apunta el motiu. Totes aquestes dades, i les que es mencionen posteriorment,
s'han d'enregistrar al sistema, a efectes d'informaci al pblic i estadstics.Suposarem que,
si els trens surten de l'estaci origen, acaben arribant a l'estaci final.
Per exemple, el dia 26/04/95 el tren de la lnia R12 va sortir de Manresa a les 10:01. En canvi, el dia
27/04/95 aquest tren no va poder sortir per 'Tempesta'.
A cada estaci que para un tren, el cap d'estaci corresponent enregistra l'hora real
d'arribada i (si no s l'estaci final) l'hora real de sortida i tamb ho comunica
immediatament al sistema. Com s natural, els trens noms paren a les estacions que est
previst que parin.
Per exemple, el tren de la lnia R12 del dia 26/04/95 va arribar a Terrassa a les 10:14 i va sortir a les 10:17.
El mateix tren arriba a Barcelona a les 10:33.
Finalment, si el maquinista observa alguna anomalia en un tram, enregistra el tram

corresponent (que ser un tram de la lnia), l'hora d'observaci i l'anomalia detectada.
Aquestes observacions es comuniquen al sistema en arribar el tren a l'estaci final.
Per exemple, en el tram de Terrassa a Barcelona, el maquinista del tren de la lnia R12, del dia 26/04/95, va
observar que 'Hi ha tall de corrent' a les 10:23.
1 2 . Considereu una companyia d'assegurances que est interessada en un sistema pel control
dels sinistres en que intervenen els cotxes que t assegurats. Un sinistre el t un cotxe
determinat, essent conduit per una certa persona, i ocorre en una certa data. La companyia
identifica els cotxes per la seva matrcula, i necessita enregistrar-ne la seva marca i el seu
model, entre altres dades. Les persones sn identificades pel seu document d'identitat,
enregistrant-se tamb altres dades com ara el seu nom i la seva adrea. No s impossible
que un cotxe tingui dos sinistres, amb el mateix o diferent conductor, per seria en dies
diferents.
Per exemple, el cotxe 10 (marca Renault, model R6) va tenir un sinistre el dia 10/10/95, quan el conduia el
Joan.
Alguns sinistres requereixen que el cotxe accidentat es porti a un (o ms) tallers per a la
seva reparaci. La companyia t "fitxats" els tallers possibles, amb un codi identificador, el
seu nom comercial, adrea, etc. No tots els sinistres acaben amb el cotxe a un taller. La
companyia indica a quins tallers s'ha de portar el cotxe, i els dies que s'ha de portar. El
sistema ha d'anotar on s'assignen els cotxes.
Per exemple, com a conseqncia del sinistre anterior, calia portar el cotxe a dos tallers. Primer, el dia
15/10/95, a el "Mecnic" i desprs, el 20/10/95 a el "Pintor de cotxes".
Un taller tractar de reparar el cotxe sinistrat, en la part que li correspongui. En aix hi

esmerar un cert nombre d'hores de ma d'obra. Per altra banda, la reparaci pot exigir
112
(per no sempre) l's d'unes certes quantitats de materials determinats. La companyia t

codificats aquests materials, i per cada un d'ells es t tamb el seu nom i el seu preu unitari.
Quan un taller acaba una reparaci, ho comunica a la Companyia, indicant les dades
esmentades, que el sistema ha d'enregistrar.
Per exemple, la reparaci indicada anteriorment va requerir al taller "Pintor de cotxes" 15 hores de ma
d'obra, i l's de 2 litres de pintura blava i d'1 litre de pintura blanca. La pintura blava t el codi ABC, i va a
1000 Pts. el litre, etc.
De quan en quan, els tallers facturen a la Companyia d'assegurances les reparacions que
han fet. Una factura pot incloure diverses reparacions, per una reparaci noms pot estar
inclosa en una factura (les reparacions no es facturen parcialment). De cada factura es
guarda el seu numero i la data de la factura. El sistema ha de poder saber, d'una manera o
altra, el codi del taller emissor de la factura. Una factura no pot incloure reparacions de
dos o ms tallers diferents.
Per exemple, el taller "Pintor de cotxes" esmentat va emetre la factura n 100 el dia 30/12/95. La factura
incloia la reparaci anterior, i la d'altres cotxes.
1 3 . Descriu qu sn els diagrames de transici d'estats de classes dobjectes en UML. Digues
quan es poden definir, i quins components tenen. Posan un exemple.
1 4 . Considera un Model Conceptual, especificat amb la notaci UML, de les dades d'un
sistema que cont noms una relaci ternria R entre les entitats A, B i C. Siguin a,b,c
ocurrncies qualssevol de les entitats A, B, C, respectivament. Indica com s'haurien
d'expressar en aquell model les restriccions segents:
1. Cap c pot participar en ms de 10 ocurrncies de R.
2. Una parella a,b qualsevol pot estar relacionada, via R, amb un mxim de 3 ocurrncies
de C.
3. Una tripleta a,b,c qualsevol pot estar relacionada, via R, com a mxim una vegada.
1 5 . Considereu una mtua sanitria que est interessada en un sistema pel control dels
ingressos hospitalaris en qu intervenen els seus socis. Un ingrs el t una persona
determinada en un cert centre mdic i ocorre en una certa data. La mtua identifica els seus
socis pel seu nmero d'associat i n'enregistra tamb el seu nom i la seva adrea. Els
centres mdics sn identificats pel seu nom i s'enregistren tamb la informaci de si el
centre t signat un conveni o no amb la mtua. s impossible que una mateixa persona
tingui dos ingressos en centres mdics en una mateixa data, encara que si que pot tenir
diversos ingressos en dates diferents.
Per exemple, la soci nmero 17 (nom Maria, adrea C/Diputaci) va ser ingressada a l'hospital de
Santa Maria del Mar (que no t conveni amb la mtua) el dia 8/8/1995.
Els ingressos requereixen que a la persona ingressada se li administrin un o ms

medicaments per a la seva curaci. El sistema guarda informaci dels possibles
113
medicaments, que tenen un codi identificador, un nom i un preu unitari. Tots els ingressos
requereixen l'administraci d'algun medicament, indicant-se en cada cas quin s el nombre
diari d'unitats a administrar i la data d'inici i la data final d'administraci. Un mateix
medicament es pot administrar diverses vegades durant un ingrs. El sistema ha
d'enregistrar nicament quins sn els medicaments administrats a un pacient que est
ingressat en un centre que no t conveni amb la mtua.
Per exemple, com a conseqncia de l'ingrs anterior, la soci 17 va rebre tres medicaments. El
medicament 3, en una quantitat de 3 unitats diries, des del dia 8/8/1995 fins el 10/8/1995. El
medicament 5, en una quantitat de 5 unitats diries, des del dia 8/8/1995 fins el 11/8/1995.
Finalment, una segona administraci del medicament 3, en una quantitat de 7 unitats diries, des
del dia 12/8/1995 fins el 14/8/1995.
El sistema coneix tamb els medicaments que sn incompatibles als socis. Un soci pot tenir
ms d'un medicament incompatible i s'enregistrar, per cada medicament, el motiu de la
incompatibilitat. Durant un ingrs, no es poden administrar a un soci medicaments que li
sn incompatibles.
Per exemple, el medicament 33 s incompatible per a la soci 17 ja que cont penicilina.
1 6 . Considera un Model Conceptual, especificat amb la notaci UML, de les dades d'un
sistema que cont noms una relaci ternria R entre les entitats A, B i C. Siguin a,b,c
ocurrncies qualssevol de les entitats A, B, C, respectivament. Indica com s'haurien
d'expressar en aquell model les restriccions segents:
1. Tots els c han de participar com a mnim en dues ocurrncies de R.
2. Una parella a,b qualsevol ha d'estar relacionada, via R, amb un mnim de 3 ocurrncies
de C.
3. Una ocurrncia c qualsevol ha d'estar relacionada com a mxim amb tres ocurrncies
distintes de B.
4. Una tripleta a,b,c qualsevol pot estar relacionada, via R, com a mxim una vegada, i
com a mnim cap.
1 7 . Considereu que la federaci d'hoquei patins est interessada en el control dels partits qe es
disputen en el decurs d'una lliga. Per simplificar, suposeu que conv enregistrar noms la
informaci corresponent a una nica lliga. Un partit d'hoquei patins se celebra entre un
equip que juga a casa i un equip que juga a fora. Un partit correspon a una determinada
jornada. En una jornada es juguen sempre vuit partits. Els equips s'identifiquen pel seu
nom i s'enregistra tamb la seva adrea i el color de la samarreta. Les jornades
s'identifiquen per un nmero de jornada. s impossible que un mateix equip jugui dos
partits diferents en una mateixa jornada. Tampoc pot passar que un equip jugui al seu camp
en dues jornades diferents amb el mateix equip visitant.
Per exemple, l'equip Vic (adrea C/Guilleries, color Blanc) va jugar contra l'equip Voltreg (adrea
C/Osona, color Blau) a la jornada 3. El Tordera s un equip d'hoquei amb adrea C/Riera i color
Groc.
114
La federaci tamb vol guardar informaci dels jugadors que juguen els partits de la lliga i
dels rbitres que xiulen aquests partits. Tant jugadors com rbitres s'identifiquen pel seu
document d'identitat, i s'enregistra tamb el seu nom en ambds casos. No pot passar que
alg sigui jugador i rbitre alhora. En el cas dels jugadors cal enregistrar tamb quina s la
seva posici (podeu suposar que un jugador t una nica posici: porter, defensa, mig,
etc.) i el nom de l'equip al que pertanyen. La federaci d'hoquei patins vol enregistrar
tamb la informaci dels rbitres que estan recusats pels diversos equips. En una lliga els
equips poden recusar fins un mxim de 3 rbitres si consideren que aquests els han
perjudicat en lligues anteriors, enregistrant-se per cada cas el motiu de la recusaci.
Per exemple, en Joan t el DNI 111, s porter i pertany al Vic. En Pep t el DNI 222, s davanter
i pertany al Voltreg. L'Oriol t el DNI 333 i s un arbitre. El Tordera ha recusat a l'Oriol perqu
els va pitar un penal injust.
Els jugadors dels equips participen en partits durant un determinat nombre de minuts. Un
jugador noms pot participar en partits en els que hi juga el seu equip. A ms, cal
enregistrar tamb la informaci del nombre de gols marcats per un jugador en un partit. Un
jugador noms pot marcar gols en els partits en qu participa. El sistema coneix tamb els
rbitres que xiulen els partits i quina s la qualificaci atorgada a l'rbitre cada cop que
xiula un partit. Un rbitre pot xiular ms d'un partit (sempre i quan siguin de jornades
diferents), un partit noms el xiula un nic rbitre. Un rbitre no pot xiular un partit en el
que hi juga un equip que l'ha recusat.
Per exemple, en Joan va jugar 40 minuts i en Pep 25 del partit esmentat anteriorment. En Pep va
marcar 3 gols en aquest partit. El partit va ser xiulat per l'Oriol, qui va ser qualificat amb Notable.
1 8 . Considereu el cas d'una entitat bancria que est interessada en un sistema pel control de
peticions i de concessions de prstecs hipotecaris. Els prstecs demanats s'identifiquen per
un codi i s'enregistra tamb la quantitat de diners sol.licitada i el nombre d'anys en qu es
tornar el prstec. Un prstec est demanat per una o ms persones. Les persones
s'identifiquen pel seu nom i es guarda tamb informaci de la seva adrea i edat. Tot
prstec t un nic primer titular. El primer titular d'un prstec ha de ser una de les persones
que l'ha demanat.
Per exemple, en Joan (adrea C/Valncia, 25 anys) i la Maria (C/Prat, 24 anys) han demanat el
prstec de codi 111 (per un valor de 3 milions, a retornar en 15 anys). La Maria s el primer
titular d'aquest prstec. La Carme (C/Balmes, 27 anys) ha demanat el prstec 222 (5 milions, 20
anys) i n's el primer i nic titular.
Els prstecs demanats sn assignats a un o ms avaluadors (que s'identifiquen pel seu nom
i dels quals es coneix tamb la seva adrea i edat) per a qu els estudin. Un avaluador no
pot haver sol.licitat cap prstec en aquella entitat bancria. Al cap d'un temps, els
avaluadors envien els informes dels prstecs que els hi han estat assignats. A vegades, un
avaluador no envia algun dels informes que se li havien assignat. Cada informe, quan es
reb, diu si l'avaluador aconsella o no la concessi del prstec. En cas afirmatiu, cal indicar
tamb el tipus d'inters al qual s'hauria de fer efectiu el prstec i en cas negatiu el motiu pel
qual no s'hauria de concedir el prstec.
115
Per exemple, el prstec 111 s'ha assignat als avaluadors Jordi, Anna i Roser. En Jordi i la Roser
consideren que cal concedir el prstec amb un inters del 5,5% i 6%, respectivament, i l'Anna no
envia l'informe preceptiu. D'altra banda, el prstec 222 s'envia als revisors Pol i Anna que envien
un informe negatiu amb el motiu de qu s'han sol.licitat massa diners.
En una certa data, l'entitat bancria decideix si concedir o no un prstec demanat a partir
dels informes dels avaluadors. Als prstecs concedits se'ls hi assigna un tipus d'inters
igual al promig del tipus d'inters suggerits pels revisors que havien ems un informe
positiu. Pels prstecs denegats, cal enregistrar el motiu pel qual l'entitat bancria ha decidit
de no concedir-los. Un prstec no es pot concedir si t un mnim de dos informes negatius.
Cal guardar tamb informaci de la data en qu s'ha fet l'avaluaci del prstec. Pels
prstecs concedits, cal guardar tamb la informaci del compte corrent del qual s'hauran de
treure els diners (nic per a cada prstec, identificat per nmero de compte) i el dia del mes
en qu s'efectuar el trasps dels diners del compte a l'entitat bancria.
Per exemple, el prstec 111 ha estat concedit el dia 5/4/97 a un inters del 5,75%. El pagament
d'aquest prstec es far a partir del compte C567, el dia 4 de cada mes. El prstec 222 ha estat
denegat el dia 7/4/97 ja que l'havia demanat una nica persona.
1 9 . Considereu el cas d'una companyia propietria de diversos teatres i que est interessada en
un sistema pel control de les compres d'entrades de les obres que es representen en els
seus teatres. Les obres de teatre s'identifiquen pel seu nom i s'enregistra tamb el seu
autor, el seu director i el nombre d'actors que hi intervenen. Les obres de teatre es
representen en diverses sessions (cadascuna de les quals s'identifica pel dia i per l'ordre
dins el dia) i en un determinat teatre. Cal guardar tamb la informaci de l'hora d'inici de la
representaci.
Els teatres s'identifiquen pel seu nom i s'enregistra tamb el seu aforament (nombre total
de butaques de qu disposen) i la ciutat on es troben. En un mateix dia no es poden
representar obres de teatre diferents en un mateix teatre. Una obra de teatre no es pot
projectar en teatres diferents en un mateix dia. En una determinada representaci d'un teatre
s'hi representa una nica obra.
Per exemple, el teatre Monumental s a Figueres i t un aforament de 400 butaques. L'obra "El
visitant" s d'en E.Schmitt, est dirigida per la R.M.Sard i hi participen 25 actors. A la tercera
sessi del dia 26/4/96 es representar al teatre Monumental l'obra "El visitant". Aquesta
representaci comenar a les 21 hores.
Cada teatre t un cert nombre de butaques, cadascuna de les quals s'identifica (per a un
teatre determinat) pel nmero de la fila i el nmero de seient dins la fila. El sistema ha de
guardar tamb la informaci de les entrades que s'han venut per a una determinada
representaci. Les entrades es poden vendre de dues maneres diferents: directament a
finestreta o b per telfon. Per les entrades venudes directament a finestreta cal enregistrar
la representaci per la qual s'ha venut l'entrada i la butaca assignada.
En el cas d'entrades venudes per telfon cal enregistrar la mateixa informaci que pel cas
d'entrades venudes a finestreta i, a ms, el nmero de document d'identitat de la persona
que ha comprat l'entrada i del nmero de tarja de crdit al que s'ha de carregar la venda. En
116
una representaci no es poden vendre entrades a les que se'ls assigni una butaca que no
existeix en el teatre on es fa la representaci.
Per exemple, s'han venut tres entrades de la representaci anterior: dues a finestreta i una per
telfon. Les entrades venudes a finestrata ocupen les butaques (1,18) i (1,20), on 1 correspon al
nmero de fila i 18 i 20 al nmero de seient dins la fila. L'entrada venuda per telfon ocupa la
butaca (5,20), ha estat comprada per una persona amb document d'identitat 111, i s'ha de carregar a
la tarja de crdit 333.
El sistema ha d'emmagatzemar tamb informaci de les persones que estan abonades a la

companyia. Un abonat s'identifica pel seu document d'identitat i s'enregistra tamb el seu
nom i la seva adrea. Noms poden comprar entrades per telfon les persones que estan
abonades a la companyia propietria del teatre.
Per exemple, en Joan est abonat a la companyia, t el document d'identitat 111 i viu al
C/Escudellers.
2 0 . Considereu una federaci d'entitats excursionistes que est interessada en un sistema pel
control de les expedicions efectuades pels centres excursionistes adscrits a la federaci.
Una expedici l'efectua un centre excursionista a una certa muntanya, amb una data d'inici
i una de finalitzaci. La federaci identifica els centres excursionistes pel seu nom i
n'enregistra tamb la seva adrea. Les muntanyes s'identifiquen pel seu nom i se
n'enregistra tamb la seva alada. Un centre excursionista pot efectuar diverses
expedicions a la mateixa muntanya, amb dates diferents. A una muntanya s'hi poden fer
diverses expedicions, per en una data concreta hi pot d'haver un mxim de 5 expedicions.
Per exemple, el centre excursionista CEC (adrea Gran Via), va efectuar una expedici a l'Everest
(alada 8848 m) del dia 5/5/1994 al 20/7/1994.
En una expedici hi participen diverses persones (com a mnim una). Una persona pot
participar a ms d'una expedici. El sistema guarda informaci de totes les persones (que
tenen el dni com a identificador, un nom i una edat) que han participat a alguna expedici.
Algun dels components d'una expedici pot assolir el cim. En aquest cas, s'enregistrar
aquest fet i tamb la data en qu s'ha fet el cim. Una persona pot assolir el cim ms d'una
vegada en una mateixa expedici.
Per exemple, les persones amb dni 111 (nom Joan, edat 25 anys), 222 (Maria, 23), 333 (Pere, 24)
i 444 (Ann, 22) varen participar a l'expedici anterior. Les persones 111 i 222 varen fer el cim el
dia 24/6/1994. A ms, la persona 222 va tornar a fer el cim el dia 30/6/1994.
Quan una persona participa en una expedici hi desenvolupa un determinat paper. Per
simplificar, suposarem que els papers possibles sn: metge, alpinista, encarregat de
material i cap d'expedici. En una expedici un paper pot ser desenvolupat per ms d'una
persona. Una mateixa persona pot desenvolupar ms d'un paper en una expedici. No tots
els papers tenen perqu desenvolupar-se en una expedici.
Quan una persona desenvolupa el paper d'alpinista en una expedici, el sistema ha
d'enregistrar tamb l'assegurana mdica (que t un nom d'assegurana identificador i el
117
nom de la mtua que la cobreix) contractada per l'ocasi. En el cas de qu una persona
d'una expedici hi desenvolupi el paper de metge, cal enregistrar tamb el nom del centre
mdic en el que treballa actualment (que suposarem que s nic).
Per exemple, totes quatre persones feien el paper d'alpinista a l'expedici anterior i tenien una
assegurana de nom "Accidents a l'Himlaia" (coberta per la Mtua de Terrassa). La persona 222
era el metge de l'expedici i treballava a l'Hospital del Mar. La persona 444 era el cap de
l'expedici.
2 1 . Considereu que un club de tennis est interessat en el control dels partits que disputen els
seus socis en el torneig social del club. Per simplificar, suposeu que conv enregistrar
noms la informaci corresponent a un nic torneig. Un partit de tennis se celebra entre
dos socis i correspon a una determinada jornada. En una jornada es juguen sempre vint
partits. Els socis s'identifiquen pel seu nom i s'enregistra tamb la seva adrea i edat. Les
jornades s'identifiquen per un nmero de jornada. s impossible que un mateix soci jugui
dos partits diferents en una mateixa jornada. Tampoc pot passar que dos jugadors
s'enfrontin entre ells en dues jornades diferents.
Per exemple, en Joan (adrea C/Guilleries, 27 anys) va jugar contra en Josep (C/Osona, 25 anys)
a la jornada 3.
El club de tennis vol guardar tamb informaci dels jutges principals que arbitren els partits
disputats. Els jutges, com els socis, s'identifiquen pel seu nom i se n'enregistra tamb la
seva adrea i edat. No pot passar que alg sigui soci del club de tennis i jutge de la
competici alhora. El club de tennis vol enregistrar tamb la informaci dels jutges que
estan recusats pels diversos socis.
En un torneig els socis poden recusar fins un mxim de 5 jutges si consideren que aquests
els han perjudicat en tornejos anteriors, enregistrant-se per cada cas el motiu de la
recusaci. El sistema coneix tamb els jutges que arbitren els partits i quina s la
qualificaci atorgada al jutge cada cop que arbitra un partit. Un jutge pot arbitrar ms d'un
partit; un partit noms l'arbitra un nic jutge. Un jutge no pot arbitrar un partit en el que hi
participi un jugador que l'ha recusat.
Per exemple, l'Oriol viu al C/Tortosa, t 29 anys i s jutge. La Maria viu al C/de Mar, t 29 anys
i s jutge. En Joan ha recusat a l'Oriol perqu l'any passat li va fer perdre un partit. El partit entre
en Joan i en Josep va ser arbitrat per la Maria, qui va ser qualificada amb Excel.lent.
Cada partit de tennis es disputa a un mxim de tres sets. Guanya un partit el primer jugador
que guanya 2 sets. El club de tennis vol guardar tamb informaci dels resultats de tots els
sets d'un partit i, en cas que un set es decideixi per tie-break (s a dir, si el resultat final del
set s de 7-6), cal enregistrar tamb el resultat del tie-break.
Per exemple, el partit entre en Joan i en Josep va durar tres sets. El primer el va guanyar en Joan
per 6 a 2. El segon set el va guanyar en Josep per 7 a 6 (7-2 al tie break). El tercer el va tornar a
guanyar en Josep per 6-3.
118
2 2 . Considereu el cas duna biblioteca que est interessada en el control dels prstecs i de les
reserves que efectuen els seus usuaris. La biblioteca disposa dun ampli fons bibliogrfic
de llibres i dun gran nombre dexemplars de cada llibre. Els llibres sidentifiquen pel seu
ttol (aix ho fem per a simplificar) i se nenregistra tamb el seu autor i el nom de
leditorial. Els exemplars dun llibre sidentifiquen per un nmero dexemplar correlatiu
(comenant des de l1) dins de cada llibre.
Per exemple, del llibre titulat Orient, Occident (escrit per la M. de la Pau Janer i publicat per
leditorial Columna) sen tenen dos exemplars: l1 i el 2. Del llibre LAtles Furtiu (Alfred
Bosch, Columna) sen tenen cinc exemplars: l1, el 2, el 3, el 4 i el 5.
La biblioteca admet que tots els seus usuaris puguin fer tant prstecs com reserves. Un
usuari sidentifica per un nmero dusuari i el sistema guarda tamb informaci del seu
nom i adrea. Una reserva la fa un usuari, per a un llibre determinat, amb una data de
recollida de la reserva i sindica tamb el nombre de dies reservats. Un prstec el fa un
usuari, per a un exemplar de llibre determinat, en una certa data i sindica tamb la data
mxima en qu lusuari pot retornar lexemplar que send en prstec.
Un usuari pot fer com a mxim 3 reserves per a una mateixa data. Un usuari pot fer un
nic prstec dun mateix exemplar en un mateix dia. Un mateix exemplar dun llibre en un
cert dia es pot prestar com a mxim a una nica persona. No es pot fer una reserva dun
llibre si no queda cap exemplar disponible daquell llibre durant tot el perode que es vol
reservar. No es pot prestar un exemplar si no est disponible durant tot el perode de
prstec o b si fer efectiu aquest prstec afecta la disponibilitat de les reserves ja fetes.
Per exemple, el soci nmero 22 (de nom Bernat i adrea C/Cristina) ha fet dos prstecs diferents de
lexemplar 3 del llibre LAtles Furtiu. El primer daquests prstecs el va fer el dia 1/9/98 amb
data mxima de retorn el 15/9/98. El segon el va fer el dia 20/9/98 amb data mxima de retorn el
20/10/98. El soci 33 (Ruth, C/Sant Bonaventura) ha fet una reserva del llibre LAtles Furtiu
amb data de recollida el 10/10/98 i per a un total de 15 dies.
Els prstecs que shan fet es retornen en una certa data. El sistema ha denregistrar quins
prstecs shan retornat i la data en qu sha fet efectiu el retorn. Les reserves que es fan es
poden recollir en la data que shavia indicat al fer la reserva. El sistema ha denregistrar
lexemplar del llibre que sha assignat a la reserva. Una reserva noms es pot recollir en la
data de recollida que shavia indicat inicialment (s a dir, ni abans ni desprs).
Per exemple, el primer dels prstecs que havia fet el soci 22 va ser retornat el dia 14/9/98. La
reserva que havia fet la scia 33 del llibre LAtlas Furtiu va ser recollida el dia 10/10/98 i se li
va assignar lexemplar nmero 5 daquell llibre.
Feu el Model Conceptual daquest sistema amb la notaci UML. Expresseu grficament
totes les restriccions que pogueu (les altres, si nhi ha, doneu-les en forma de text).
Indiqueu els atributs de les classes dobjectes i, si s el cas, els atributs de les associacions.
Heu d'indicar tamb necessriament la instanciaci del model amb les dades de l'exemple
que s'ha donat. Si en fer aquest exercici us cal ms informaci, feu els supsits que creieu
ms adients i indiqueu-los ben clarament.
119
2 3 . Considereu el cas duna escola bressol que est interessada en construir un sistema que
inclogui, entre daltres coses, informaci sobre els nens que t al seu crrec. Cada nen t
un nom, que lidentifica, una adrea i una data de naixement. Els nens tenen diverses
persones adultes que sn els seus responsables i que el poden recollir a lescola. De cada
adult que s responsable dalgun nen, lescola vol conixer el seu nom (que lidentifica), el
seu nmero de telfon i el tipus de responsabilitat que exerceix respecte al nen (pare, mare,
avi, via, cangur, etc.). Com us podeu imaginar hi ha adults que sn responsables de ms
dun nen (per exemple, de germans que van plegats a lescola). Cada nen est incls a la
cobertura mdica dun adult, que ha de ser un dels seus adults responsables. En aquest cas
cal conixer el nmero de seguretat social (o plissa mdica) de ladult.
Per exemple, lAlbert, lIris, la Judit i lAriadna sn nens de lescola. LAlbert t tres adults
responsables: la seva mare (Maria), el seu pare (Josep) i la seva via (Concepci), i est incls a
la plissa mdica den Josep (nmero 5643578).
Cada nen est assignat a una (sola) classe. Noms hi ha tres classes: Nadons, Patufets
i Llops. De cada classe se nha de conixer el seu nom, el nom de leducadora i laula
que ocupa. No pot passar que un nen de ms dun any sigu nad. Pels nens que sn
nadons cal enregistrar la llet que prenen (les llets sidentifiquen pel seu nom i sen guarda
tamb la seva composici). Pels nadons i pels patufets cal conixer els bolquers que usen
(que tamb sidentifiquen pel seu nom i es guarda informaci tamb de les possibles
contraindicacions). Un nen pot usar diferents tipus de bolquers.
Per exemple, la classe dels Llops la porta la Dolors i ocupa laula A1; la dels Nadons la porta la
Carme i ocupa laula A2; i la dels Patufets la porta la Isabel i ocupa laula A3. LAriadna s un
Nad, lIris s un Patufet i lAlbert i la Judit sn Llops. LAriadna pren la llet Dorlat2 i usa els
bolquers Dodot i Ausonia. La Iris usa els bolquers Dodot.
Per tal de coordinar-se entre ells, els pares dels nens de cada classe organitzen una cadena
de comunicaci, que ha destar enregistrada. Daquesta manera, quan cal que tothom
sassabenti dalguna cosa, es truquen els uns als altres en lordre que estableix la cadena.
En una cadena, tots els nens sn de la mateixa classe. A ms, a lescola es fan informes
diaris de cada nen on shi indica: com ha dormit la migdiada (b o malament) i com ha
menjat (tot, poc o res). De vegades pot passar que un dia no es faci linforme dalgun nen..
Per exemple, a la classe dels Llops la primera de la cadena s la Judit, la segueix lAlbert i aix
successivament fins a completar tots els nens de la classe. El dia 1-11-98 lAlbert sho va menjar
tot i va dormir b la migdiada. En canvi, el dia 2-11-98 lAlbert va dormir malament la migdiada i
no va menjar res.
totes les restriccions que pogueu (les altres, si nhi ha, doneu-les en forma de text).
Indiqueu els atributs de les classes dobjectes (en particular, com s'identifiquen) i, si s el
cas, els atributs de les associacions. Heu d'indicar tamb necessriament la instanciaci del
model amb les dades de l'exemple que s'ha donat.
Si en fer aquest exercici us cal ms informaci, feu els supsits que creieu ms adients i
24 . Considereu un centre densenyament que est interessat en un sistema per la gesti de les
preguntes que es fan als examens efectuats al centre. Un examen correspon a una certa
assignatura, a un cert curs en el que lassignatura simparteix i es realitza en una data
determinada. El centre identifica les assignatures pel seu nom i nenregistra tamb la seva
rea. Els cursos sidentifiquen pel seu nom i se nenregistra ledat habitual dels alumnes
que el cursen. Una assignatura pot impartir-se a ms dun curs. El sistema enregistra els
crdits que t una assignatura en un curs determinat i el fet de si una assignatura s
obligatria o opcional en un curs. Es poden fer com a mxim 5 examens per assignatura i
curs en el que lassignatura simparteix.
120
Per exemple, lassignatura Biologia (rea Cincies) simparteix a ESO-1 (edat 12) com a opcional
i amb 6 crdits. Es va fer un examen de Biologia al curs ESO-1 el dia 24/3/1999.
El sistema gestiona informaci de preguntes que shan posat en algun examen o que poden
posar-se en algun examen futur. Les preguntes sidentifiquen per un nmero i senregistra
tamb el seu text, el seu tipus (terica, prctica, test), la seva assignatura i el professor que
ns lautor. Els professors sidentifiquen pel seu nom i senregistra tamb el seu telfon.
Per exemple, la pregunta nmero 1 (text Expliqueu els descobriments de Mendel, tipus terica)
s de Biologia i el seu autor s en Joan (telfon 935286748). La pregunta 2 (text Trobeu el factor
Rh que es pot obtenir de ..., tipus prctica) s de Biologia i la seva autora s la Nria (telfon
937226432). La pregunta nmero 3 (text Digueu quina ..., tipus test) s tamb de Biologia i el
seu autor s en Llus (telfon 937226432).
Tots els examens que sefectuen al centre tenen un nic professor organitzador de
lexamen. A un examen shi han de posar entre 1 i 10 preguntes de les que el sistema t
enregistrades. Totes les preguntes han de ser de lassignatura de lexamen. Per cada
pregunta dun examen, senregistra el pes que t i la nota promig que han obtingut els
alumnes per la pregunta en aquell examen.
Per exemple, lexamen anterior lorganitza la Nria i t tres preguntes: la nmero 1 (pes 0.4, nota
promig 5), la nmero 2 (pes 0.4, nota promig 7.5) i la nmero 3 (pes 0.2, nota promig 3).
Per les preguntes teriques dun examen, el sistema ha denregistrar tamb la nota mnima i
la nota mxima que sha obtingut, per les preguntes prctiques el percentatge dalumnes
que han contestat la pregunta i per les preguntes de test els punts negatius que tenen les
respostes errnies.
Per exemple, a lexamen anterior la pregunta 1 t una nota mnima de 1.5 i una mxima de 10, la
pregunta 2 t un percentatge de respostes del 90 per cent i la pregunta 3 t 5 punts negatius si s
errnia.
totes les restriccions que pogueu (les altres, si nhi ha, doneu-les en forma de text). Heu
dindicar tamb necessriament la instanciaci del model amb les dades de lexemple que
sha donat. Si en fer aquest exercici us cal ms informaci, feu els supsits que creieu ms
adients i indiqueu-los ben clarament.
2 5 . Considereu que un consorci dempreses est interessat en informatitzar el seguiment dels
projectes informtics que desenvolupa. Tots els projectes desenvolupats dins el consorci
sn projectes subcontractats. s a dir, en qualsevol cas, una empresa subcontracta a una
altra empresa (o a ella mateixa) perqu porti a terme el projecte. Tot projecte informtic
sinicia en una certa data i semmagatzema tamb la data prevista de finalitzaci.
Lgicament, una empresa pot subcontractar diverses vegades a una altra empresa per a
desenvolupar projectes diferents. Les empreses sidentifiquen pel seu codi i senregistra
tamb la seva poblaci. Una empresa no pot subcontractar a una mateixa empresa dos
projectes diferents amb una mateixa data dinici.
Per exemple, lempresa 111 (de El Vendrell) va subcontractar lempresa 222 (dAltafulla) per
desenvolupar un projecte informtic que comenava el 2-2-1999 i es preveia acabar el 5-5-1999. A
ms, lempresa 111 va subcontractar tamb lempresa 222 per desenvolupar un projecte del 3-31999 al 4-4-1999.
Tot projecte informtic ha de portar a terme alguna de les etapes tradicionals del cicle de
vida dun projecte software (s a dir, especificaci, disseny o implementaci). Lgicament,
no tot projecte ha de comprendre totes les etapes i una etapa es porta a terme una nica
vegada en un projecte.
121
Per exemple, el primer dels projectes anteriors comprenia les etapes despecificaci, disseny i
implementaci. En canvi, el segon projecte consistia noms en una implementaci.
El sistema ha de guardar tamb la informaci dels empleats (identificats per nom i dels que
senregistra tamb la seva adrea i edat) que treballen a les empreses. Per simplificar,
suposarem que un empleat comena a treballar en una empresa en una certa data i que no es
dna mai de baixa. Els empleats que treballen a una empresa, poden participar en els
projectes que aquella empresa est desenvolupant a partir duna certa data (per a
simplificar, suposarem tamb que quan un empleat comena a treballar en un projecte no
deixa mai de treballar-hi). Un empleat noms pot participar en un projecte en qu la seva
empresa s la subcontractada.
Per exemple, la Montse (Cam Ral, 21) treballa a lempresa 111 des del 1-1-1998, i en Joan
(Carrer Nou, 22) i la Maria (La Riera, 20) treballen a lempresa 222 des del 2-2-1998. En Joan i la
Maria participen al primer dels projectes anteriors, en Joan des del 2-2-1999 i la Maria des del 3-31999.
Quan un empleat treballa en un projecte, ho fa en el marc dalguna de les etapes de

desenvolupament del projecte. Cal enregistrar la informaci de les etapes a les que sha
assignat cada empleat (en el marc dun projecte) i de les hores treballades en aquesta etapa.
Per exemple, en el marc del primer projecte informtic, en Joan va ser assignat a letapa
despecificaci i hi va dedicar 40 hores. En canvi, la Maria va ser assignada a letapa de disseny,
dedicant-hi tamb 40 hores, i a letapa dimplementaci, dedicant-hi 60 hores.
totes les restriccions que pugueu (les altres, si nhi ha, doneu-les en forma de text).
Indiqueu els atributs de les classes dobjectes i els atributs de les classes associatives. Heu
d'indicar tamb necessriament la instanciaci del model amb les dades de l'exemple que
s'ha donat. Si en fer aquest exercici us cal ms informaci, feu els supsits que creieu ms
2 6 . Considereu el cas duna ciutat de lilla de Menorca que est interessada en construir un
sistema que li permeti gestionar, entre daltres coses, la informaci de les propietats i els
lloguers de les seves finques i dels pisos daquestes. Per poder localitzar les finques, es
necessita saber la informaci dels carrers (identificats per nom i dels que senregistra tamb
el seu barri) que formen la ciutat. Una finca sidentifica per un nmero dins un carrer. Per
tant, dues finques dun mateix carrer han de tenir nmeros diferents. Tot carrer ha de
contenir alguna finca. Una finca pot estar dividida en diferents pisos, que sidentifiquen pel
nmero de pis i nmero de porta dins la finca.
Per exemple, el carrer Son Saura (barri del Port) i el carrer Ma (barri del Centre) sn carrers de la
ciutat. El carrer Son Saura t dues finques, situades als nmeros 2 i 26, i el carrer Ma en t una
situada al nmero 17. La finca situada al nmero 2 del carrer Son Saura t dos pisos (1er-1a i 1er2a) i la finca del nmero 17 del carrer Ma noms en t dos (1er-1a i 1er-2a).
Les finques sn possedes per persones (identificades per nom i de les que senregistra
tamb la seva adrea). Una persona pot posseir diverses finques, i una finca pot ser
posseda per diverses persones. Una persona posseeix una certa finca a partir duna data i
en un determinat percentatge. Lgicament, la suma dels percentatges de possessi duna
finca no pot superar el 100%. Per a simplificar, suposarem que el percentatge de possessi
duna finca per part duna certa persona no varia mai.
Per exemple, la finca situada al nmero 2 del carrer Son Saura s posseda per en Joan
(C/Algaiarens) en un 40% des del 1-1-1999 i per la Maria (C/Macarella) en un 60% des del 2-21999. En canvi, la finca del carrer Ma s posseda integrament per la Maria.
122
Les persones poden llogar pisos de les finques. Una persona lloga un pis, des duna certa
data i per un nombre de mesos determinat. Una persona pot tenir diversos pisos llogats
alhora. Donada una data dinici i un nombre de mesos de lloguer, un pis s llogat per una
nica persona. Una persona pot llogar diversos cops el mateix pis, per amb dates dinici
diferents. Una persona no pot llogar un pis duna finca que posseeix.
Per exemple, en Joan ha llogat el 1er-1a de la finca del nmero 17 del carrer Ma des del 4-41999, per 3 mesos. La Marta (C/Macarelleta) ha llogat el 1er-2a del nmero 2 del carrer de Son
Saura des del 3-3-1999, per 12 mesos.
Els lloguers dun pis es facturen a un propietari de la finca on es troba situat el pis,
concretament al propietari que t el percentatge de possessi ms alt daquella finca (que
podrem anomenar propietari principal). Cal enregistrar la informaci del nmero de
compte corrent al que sha defectuar el pagament. Si una persona s propietria principal
de diverses finques, el compte corrent al que es facturen els seus lloguers pot ser diferent
per cada finca.
Per exemple, el lloguer de la Marta es facturava a la Maria com a propietria principal de la finca
on estava situat el pis, a crrec del compte corrent 1234. En canvi, el lloguer den Joan que tamb
es facturava a la Maria com a propietria principal singressava al compte 6789.
totes les restriccions que pugueu (les altres, si nhi ha, doneu-les en forma de text).
Indiqueu els atributs de les classes dobjectes i de les classes associatives. Heu d'indicar
tamb necessriament la instanciaci del model amb les dades de l'exemple que s'ha donat.
2 7 . Considereu el cas duna empresa que est interessada en construir un sistema software que
inclogui, entre daltres coses, informaci sobre els seus empleats. Cada empleat t un
nmero de document didentitat (que lidentifica), un nom i una data dingrs a lempresa.
En el decurs de la seva vida laboral, els empleats es van assignant a diversos departaments.
Cada departament t un nom (que lidentifica), una adrea i est a una ciutat. Lempresa t
un total de 10 departaments. Quan sassigna un empleat a un departament, sen registra la
seva data dassignaci i quan es desassigna la seva data de desassignaci.
Un empleat es pot assignar com a mxim tres vegades al mateix departament, per sempre
amb dates dinici diferents i amb perodes que no se solapn entre s. En tota la seva vida
laboral, un empleat es pot assignar com a mxim a cinc departaments diferents. En un
moment determinat, un empleat pot no estar assignat a cap departament, i totes les
assignacions shan de fer en dates posteriors a la data dingrs a lempresa.
Per exemple, lempleat amb dni 111 (Pere Mrtir, 1-10-98) va estar assignat al departament de
Vendes (C/Crsega, Colera) des del 1-10-1998 al 5-9-1999 i des del 5-10-1999 fins al 20-10-1999
i al departament de Gerncia (C/Sardenya, Darnius) des del 21-10-1999 al 1-11-1999. Lempleat
amb dni 222 (Maria Dola, 2-2-99) est assignada al departament de Mrketing des del 2-2-1999.
Quan un empleat est assignat al departament de Vendes o al de Mrketing, el sistema ha de

guardar informaci addicional. Un empleat pot pertnyer alhora al departament de Vendes i
al de Mrketing. Pels empleats assignats al departament de vendes, cal enregistrar els
crrecs que han desenvolupat. Hi ha tres crrecs possibles: Venedor, Responsable de
Vendes i Director General de Vendes, i cal enregistrar la data en qu lempleat va comenar
a ocupar el crrec en qesti.
Per exemple, quan lempleat amb dni 111 va estar al departament de Vendes durant el perode
comprs del 1-10-1998 al 5-9-1999 va desenvolupar dos crrecs: Venedor (des del 1-10-1998) i
Responsable de Vendes (des del 1-1-1999). En canvi, quan va tornar a estar al departament de
123
Vendes, va fer de Venedor (des del 6-10-1999) i de Director General de Vendes (des del 10-101999).
Els empleats assignats al departament de Mrketing participen en diversos projectes. Un

projecte sidentifica per un nom i t una durada determinada. Quan els empleats participen
en projectes hi porten a terme certes activitats (que sidentifiquen pel nom de lactivitat) i
dediquen un determinat nombre dhores setmanals a fer aquesta activitat. Un empleat del
departament de Mrketing pot fer ms duna activitat dins el projecte. Una activitat i un
projecte qualssevol han de tenir com a mnim la participaci dun empleat del departament
de Mrketing.
Per exemple, mentre lempleat amb dni 222 ha estat al departament de Mrketing, ha participat al
projecte Ara, Lleida i hi ha fet les activitats de Responsable dImatge, dedicant-hi 20 hores
setmanals, i de Relaci amb els mitjans de comunicaci, amb una dedicaci de 7 hores/setmana.
Atesa la seva importncia estratgica, el departament de Mrketing pot rebutjar empleats.

Un empleat rebutjat pel departament de Mrketing no es pot assignar mai a aquest
departament.
Per exemple, lempleat amb dni 111 fou rebutjat pel departament de Mrketing i, per tant, no shi
podr assignar mai.
totes les restriccions que pogueu (les altres, si nhi ha, i els possibles atributs derivats
doneu-los en forma de text). Indiqueu els atributs de les classes dobjectes i, si s el cas,
els atributs de les associacions. Heu d'indicar tamb necessriament la instanciaci del
2 8 . Considereu una empresa que es dedica a lorganitzaci de congressos i que est interessada
en un sistema per a la gesti de les ponncies i dels assistents als diversos congressos que
organitza. Un congrs t unes sigles i un any que lidentifiquen i cal que el sistema
enregistri tamb lidioma que sutilitza en el congrs, la ciutat on es realitza i el preu de la
inscripci.
Per exemple, el congrs ER de lany 1998 t: idioma angls, ciutat Singapur i preu 50000 pts. El
congrs ER de lany 1999 t: idioma angls, ciutat Pars i preu 60000 pts.
A cada congrs shi envien moltes ponncies. A cada ponncia se li assigna un codi que
lidentifica i tamb senregistra el seu ttol i qui sn els seus autors. De cada autor, el
sistema ha de tenir el seu nom que es considerar identificador i tamb el seu e-mail.
Algunes de les ponncies enviades sn escollides per a ser presentades al congrs. Totes
les ponncies escollides per a un determinat congrs han destar entre les que shavien
enviat per a aquell congrs. s possible que una mateixa ponncia es presenti a diversos
congressos per aleshores pot ser escollida com a mxim per a un de sol. De les ponncies
escollides, el sistema ha denregistrar la puntuaci que sels ha atorgat.
Per exemple, a lER del 1999 shi ha presentat la ponncia de codi C125 (ttol Evoluci de
jerarquies) que t per autors en Jordi (email jordi@fib.upc.es) i la Rosa (email rosa@fib.upc.es).
Aquesta ponncia ha estat escollida i se li ha atorgat una puntuaci de 7.
Un congrs sestructura en sessions. Cada sessi t un nom que indica la temtica de la

sessi i que no es pot repetir en sessions diferents dun mateix congrs per que s es pot
repetir en congressos diferents. Cada ponncia escollida sassigna a una sessi del congrs
124
per al qual se lha escollit. A una sessi se li poden assignar com a mxim quatre
ponncies.
Per exemple, a lER del 1999 hi ha una sessi que t el nom Modelitzaci conceptual i la
ponncia C125 ha estat assignada a lesmentada sessi.
Les persones que volen assistir a un congrs shi inscriuen i el sistema ha denregistrar el
seu nom que es considera identificador i el seu e-mail. Hi ha dos tipus dinscripcions: les
inscripcions normals i les inscripcions destudiants. Per a les inscripcions destudiants cal
enregistrar el nom dels estudis que est realitzant la persona inscrita en el moment de la
inscripci. Cal considerar que una mateixa persona pot tenir inscripcions de tipus diferents
(per congressos diferents) i tamb que una persona pot tenir diverses inscripcions com a
estudiant cadascuna amb uns estudis diferents.
Per exemple, a lER del 1998 shi va inscriure en Jordi com a estudiant (nom estudis Informtica).
A lER del 1999 shi ha inscrit en Jordi amb inscripci normal i la Rosa tamb amb inscripci
normal. Una altra persona, la Maria (email maria@fib.upc.es) sha inscrit a lER del 1999 amb
inscripci normal.
Per cada congrs, existeixen alguns hotels que serviran per allotjar als inscrits al congrs
que ho desitgin (no obligatriament). El sistema ha denregistrar quins sn els hotels de
cada congrs. Els hotels sidentifiquen pel seu nom. Cal que tamb senregistrin tots els
allotjaments de les persones inscrites en un congrs corresponents a hotels del congrs. De
cada allotjament senregistrar la data dinici i el nombre de nits. Es considerar que una
persona inscrita en un congrs pot tenir diversos allotjaments diferents en perodes que no
se solapin.
Per exemple, els hotels de lER del 1999 sn el Montmartre i el Sena. En Jordi, per a la seva
inscripci a lER del 1999, sallotja a lhotel Montmartre durant 2 nits des del 5-11-1999,
sallotja a lhotel Sena durant 2 nits des del 7-11-1999 i sallotja a lhotel Montmartre durant 3
nits des del 9-11-1999.
2 9 . Considereu el cas duna cadena de botigues de roba que est interessada en construir un
sistema software que inclogui, entre daltres coses, informaci sobre els seus productes i
les botigues on es venen.
Cada producte t un codi (que lidentifica), una descripci, un preu, una data dalta i, si ja
no es fabrica, una data de baixa. De cada producte sen dissenyen diverses talles i de cada
talla sen fabriquen diverses peces (aquesta cadena de botigues no dissenya models
exclusius). Les talles sidentifiquen pel nmero de talla. Els productes poden ser de tres
tipus: infantil, juvenil i adult. Un producte es considera de tipus infantil si sha dissenyat
per alguna talla entre la 2 i la 12; de tipus juvenil si sha dissenyat per alguna talla entre la
34 i la 38; i de tipus adult si shan dissenyat talles superiors a la 38. Res impedeix que un
producte sigui de ms dun tipus (per exemple, infantil i juvenil).
Per exemple, el producte amb codi 333 (forro polar de flors, 6500, 1-9-1999) es va dissenyar en
les talles 2,4 i 6. El producte amb codi 444 (abric blau mar, 14000, 1-9-1998) es va dissenyar
en les talles 12,34 i 36, i es va donar de baixa el 30-6-1999). El producte amb codi 555 (guants
de llana, 1500, 1-9-1998) es va dissenyar en les talles 2 i 4. Per tant, els productes 333 i 555 sn
infantils, i el producte 444 s infantil i juvenil.
125
Les botigues de la cadena tenen un nmero, que les identifica, i una adrea. El sistema ha
de guardar, per cada producte, la quantitat de peces de cada talla que estan disponibles (a la
venda) a cada botiga.
Per exemple, a la botiga nmero 1 (Rambla Catalunya) del producte 333 tenen tres peces de la
talla 4, una pea de la talla 2 i la talla 6 est exhaurida. A la botiga nmero 2 (Diagonal) del
producte 444 tenen dos peces de la talla 12, una pea de la talla 34 i una pea de la talla 36.
De vegades, les botigues fan promoci de productes. El sistema ha denregistrar la botiga,

el producte promocionat, les dates dinici i final de la promoci i el descompte que saplica
al preu del producte. Un producte pot ser promocionat fins a 3 vegades en una mateixa
botiga, per amb dates dinici diferents. En una botiga determinada no hi pot haver ms de
10 productes en promoci simultniament.
Per exemple, a la botiga numero 2 es promociona el producte 444 des del dia 28-12-99 fins el dia
30-1-2000 aplicant-hi un descompte del 50%.
Dos cops lany lempresa elabora els catlegs dels seus productes per promocionar-los en
les temporades de primavera/estiu i tardor/hivern, respectivament. Selaboren tres tipus de
catlegs: linfantil, el juvenil i ladult. El sistema ha denregistrar, per cada tipus de catleg
i temporada, la data en que entra en vigncia i el conjunt de productes que en formen part.
Com s natural, en el catleg infantil noms hi poden haver productes de tipus infantil, en
el juvenil productes de tipus juvenil i en ladult productes de tipus adult.
Per exemple, al catleg infantil tardor/hivern99 (1-9-1999) hi trobem el producte 333 i el producte
555.
totes les restriccions que pugueu (les altres, si nhi ha, i els possibles atributs derivats
doneu-los en forma de text). Indiqueu els atributs de les classes dobjectes i, si s el cas,
els atributs de les associacions. Heu d'indicar tamb necessriament la instanciaci del
3 0 . Considereu un club de jubilats que est interessat en un sistema que gestioni els viatges que
organitzen dins el club. Els jubilats sidentifiquen pel seu nom i cal que el sistema
enregistri el seu any de naixement. Els viatges sidentifiquen per un nmero i cal
enregistrar el tipus de transport que shi utilitza. Els jubilats que desitgen fer un viatge han
de fer una reserva pel viatge (que sha denregistrar). Tamb cal enregistrar quins jubilats
dentre els que havien reservat un viatge lhan fet finalment juntament amb el seu grau de
satisfacci pel funcionament del viatge. Si un viatge no t com a mnim dues persones que
el facin, el viatge sanula i el sistema no lenregistra.
Per exemple, en Joan (any naixement 1930), la Carme (any naixement 1933) i en Carles (any
naixement 1931) sn jubilats del club. Sha organitzat un viatge de nmero 25 (tipus transport
autobs). Per al viatge 25 shan fet tres reserves: una den Joan, una de la Carme i una den
Carles. Finalment, els que han fet el viatge 25 han estat en Joan amb un grau de satisfacci de 5 i
la Carme amb un grau de 10.
Quan un jubilat fa un viatge t la possibilitat de contractar una assegurana pel viatge. En

aquests casos, senregistra el nmero de lassegurana i la mutua asseguradora.
Pel viatge 25, en Joan ha contractat una assegurana que t el nmero 111 de la mutua Segur.
126
En un viatge es fan parades a diverses localitats. Per cada parada del viatge cal enregistrar
la localitat, la data dinici de la parada i la data de fi de la parada. En una determinada data
un viatge no pot iniciar parada a ms duna localitat. Un viatge pot parar com a mxim dues
vegades a la mateixa localitat i pot fer com a mxim deu parades en total. Les localitats
sidentifiquen pel nom i es vol saber tamb el seu nombre dhabitants.
El viatge 25 t una parada a Figueres (30000 habitants) que sinicia el dia 6-10-1999 i finalitza el
dia 8-10-1999. Tamb t una parada a Castell dEmpries (5000 habitants) que sinicia el 8-10199 i fianlitza el 9-10-1999.
Les parades dun viatge poden incloure diverses visites. A cada visita se li assigna un
nmero identificador i el sistema ha denregistrar per cada visita a quina parada correspon
(una sola), el nom de la visita, i la seva data.
Per exemple, la parada que el viatge 25 inicia el dia 6-10-1999 a Figueres inclou la visita nmero
1234 (nom museu Dal, data 7-10-1999). La parada que el viatge 25 inicia el dia 8-10-1999 a
Castell dEmpries inclou la visita nmero 1235 (nom museu de la Catedral, data 8-10-1999).
Els jubilats que fan un viatge poden donar, si volen, la seva valoraci (molt bona, bona,
regular, dolenta) de les visites incloses a les parades del viatge. Aquestes valoracions han
de ser enregistrades pel sistema.
Per exemple, en Joan ha valorat la visita 1234 com a regular i la visita 1235 com a molt bona.
Entre els jubilats que fan un viatge es fa un sorteig i el guanyador rep un regal. El sistema
ha denregistrar qui s el guanyador i quin ha estat el seu regal.
Per exemple, pel viatge 25 la guanyadora del sorteig ha estat la Carme que ha tingut com a regal
un rellotge.
Object Constraint Language (O.C.L.)

1. A partir del Model Conceptual segent, expresseu en OCL les restriccions textuals a) i b). La
classe Persona t un nic atribut nom i la classe Cotxe un nic atribut matrcula, ambds
identificadors.
propietari
1..*
Persona
1..*
conductor
posseeix
posset
propietat
condueix
conducci
Cotxe
*
condut
a) Una persona no pot conduir un cotxe que posseeix.

b) Tot conductor dun cotxe ha de ser un dels propietaris daquell cotxe.
127
Part III : Altres models dUML

Problemes
1.
Considereu un sistema senzill de control de prstecs en una biblioteca. El sistema ha

d'admetre altes i baixes de socis i de llibres. Els socis poden demanar llibres en prstec,
per no es poden tenir ms de tres llibres en prstec en un moment determinat. Els llibres
s'han de tornar abans d'un mes de la data del prstec. Cada cop que un soci torna un llibre
ms enll de la data de devoluci, es penalitza reduint en una unitat el nombre de llibres que
pot tenir simultniament. Quan arriba a zero, el soci es dna de baixa automticament.
Us demanem que feu els models segents (tots ells mitjanant la notaci UML):
Model Conceptual.
Model de Casos ds: diagrama de casos ds i especificaci dels casos ds.
Model del Comportament del Sistema: diagrames de seqncia i contractes de les
operacions.
Model dels Estats: diagrama destats per objectes i casos ds.
2.
Considereu un sistema senzill de reserva i utilitzaci de pistes de tenis d'un club. L's de
les pistes est reservat als socis de club, i s'han de preveure les altes i baixes de socis. El
club t tres pistes, que es poden reservar per blocs d'una hora. Les reserves es poden
cancel.lar, si no sn pel mateix dia. No hi ha lmit en les reserves que pot fer un soci, per
no es poden fer reserves per ms enll d'un mes. Cada final de mes s'envia una factura als
socis, carregant l's que han fet de les pistes durant el mes. Cada hora reservada costa un
cert preu, i l'import de la factura es calcula multiplicant la suma de les hores reservades
durant el mes per aquell preu.
Cal tenir en compte si les pistes reservades s'ocupen o no. La primera "no ocupaci" d'una
pista durant un any natural, no es carregar a la factura del soci, per la resta es carregaran
com si s'hagus utilitzat realment.
Model Conceptual.
operacions.
3.
Considera el cas d'una empresa que es dedica a gestionar l'adopci de gossos. L'empresa
disposa d'uns gossos, cadascun dels quals t un identificador i s d'una raa determinada.
Aquests gossos poden sser adoptats pels clients de l'empresa. Cada client t un
identificador i una raa preferida de gossos. En un moment determinat, cada client pot tenir
adoptat cap o un gos. Alhora, un gos pot estar lliure o adoptat per un client determinat. El
sistema ha de respondre a tres esdeveniments: Alta de gos, Alta de client i Canvi de gos.
Quan es produeix una alta d'un gos, ens comuniquen el seu identificador i la seva raa. Si
hi ha algun client qualsevol que estigui esperant gossos d'aquesta raa, se li assigna el nou
gos, i es produeix una sortida "Adopci feta", indicant l'identificador del gos i el del client.
En cas contrari, el gos queda lliure per ser adoptat en el futur. No es considera que els
gossos es puguin donar de baixa.
Quan es produeix una alta d'un client, ens comuniquen el seu identificador i la raa que
prefereix. Si hi ha algun gos qualsevol d'aquesta raa lliure, se l'assigna al client i es
128
produeix una sortida "Adopci feta", indicant l'identificador del gos i el del client. En cas
contrari, el client queda a l'espera d'adoptar un gos en el futur. No es considera que els
clients es puguin donar de baixa.
Quan es produeix l'esdeveniment de Canvi de gos, ens comuniquen l'identificador de la
persona que ens torna el gos (no cal que ens indiquin el gos que torna). El canvi noms
s'accepta si tenim algun altre gos lliure de la raa preferida pel client. En aquest cas,
s'assigna un gos qualsevol d'aquestos al client i es produeix una sortida "Adopci feta",
indicant l'identificador del gos i el del client. No cal guardar la histria de les adopcions
fetes pels clients. Podeu suposar que les races estan codificades.
Model Conceptual.
operacions.
4.
Considera un sistema que enregistra les compres que fan els clients, i que les factura. El
sistema ha de respondre a tres esdeveniments: nova compra, fer factures i fi d'any. Quan
es produeix una nova compra ens comuniquen el codi del client que l'ha fet, el codi del
producte que ha comprat, la quantitat comprada d'aquest producte i la data de la compra.
Se suposa que en una compra el client noms compra un sol producte.
El sistema accedeix a dos arxius ja existents: Productes i Clients. L'arxiu de productes
cont, per cada producte, el seu codi, la descripci i el preu unitari. L'arxiu de Clients
cont, per cada client, el seu codi, el seu nom i el total comprat en el darrer any.
Un producte pot sser comprat per un nombre indeterminat de clients. Alhora, un client pot
arribar-nos a comprar un nombre indeterminat de productes. Un client pot comprar-nos el
mateix producte en diverses ocasions.
Quan es produeix l'esdeveniment fer factures el sistema ha de generar factures de totes
les compres que encara no s'han facturat. Una factura s'identifica per un nmero de factura
(que el sistema assigna correlativament). Interessa enregistrar, de cada factura, la data en
qu s'ha fet i el seu import. S'ha de generar una factura per cada client que t una o ms
compres no facturades. L'import de la factura s la suma dels imports de les compres. En
acabar el procs, ha de sortir un missatge que digui el primer i el darrer nmero de factura
generat o, si no n'ha generat cap (perqu totes les compres ja estaven facturades), l'avs:
'Cap factura feta'. (No tindrem en compte el llistat de les factures).
Quan es produeix l'esdeveniment fi d'any, el sistema ha de calcular, per cada client,
l'import total de les compres que ens ha fet durant l'any, i enregistrar-lo a l'arxiu Clients.
Model Conceptual.
operacions.
5.
Una federaci de ciclisme ha decidit facilitar l'organitzaci de curses per etapes per
aficionats. Amb aquesta intenci ha encarregat a una empresa de software la construcci
d'un sistema informtic capa de gestionar les dades d'una nica cursa.
129
La cursa consta de diverses etapes, numerades correlativament. Els ciclistes tenen un

nmero de dorsal i es vol conixer tamb el seu nom i el del seu equip. A cada etapa, els
corredors arriben en un cert ordre i havent tardat un determinat temps. La classificaci
general de la cursa s'estableix segons el temps acumulat durant totes les etapes disputades.
El sistema ha de respondre als tres esdeveniments segents: donar d'alta un corredor,
registrar el resultats d'una etapa i generar un llistat amb la classificaci general. Per donar
d'alta un corredor es proporciona el seu nmero de dorsal, el seu nom i el del seu equip. El
sistema ha de comprovar que no existeix un altre ciclista amb el mateix nmero. Els
resultats d'una etapa es registren un cop arribats tots els corredors (exceptuant els que
abandonen o arriben fora de control). Per cada un d'ells s'introdueixen el nmero, la
posici en la que ha arribat i el temps que ha consumit. El sistema comprova que les dades
entrades sn correctes, genera un nmero d'etapa (el ms alt que ja existeixi ms un) i
emmagatzema els resultats. A ms, s'imprimeix un llistat en el qual es mostra el nmero
d'etapa i, per cada corredor, la classificaci, el nmero, el temps, el nom i l'equip. En
qualsevol moment es pot demanar un llistat amb la classificaci general (que ser
provisional si no ha acabat la cursa). S'ha de mostrar el nmero de l'ltima etapa
recorreguda i, per cada corredor que l'ha acabada, la classificaci, el nmero, el temps
acumulat, el nom i l'equip.
Model Conceptual.
operacions.
6.
Els gestors de El set segell, una sala de cinema, han decidit oferir als seus clients un
servei de reserva per telfon d'entrades numerades. Amb aquest propsit, han encarregat a
un estudiant d'ES:E la construcci d'un sistema informtic.
Els films es projecten en sessions, cadascuna de les quals s'identifica pel dia i per l'ordre
dins del dia. Cada sessi comena en una hora determinada i projecta una determinada
pel.lcula (de la qual noms ens interessa el seu nom). En un mateix dia, es poden projectar
pel.lcules diferents. La sala disposa d'un nombre fix de butaques, cadascuna de les quals
s'identifica pel nmero de la fila i el nmero dins la fila.
De tots els esdeveniments als quals ha de respondre el sistema, noms ens n'interessen
quatre: 1) compra directa a la finestreta (sense reserva prvia) d'una entrada, 2) petici
(telefnica) de reserva d'una entrada, 3) recollida i pagament (a finestreta) d'una entrada
reservada i 4) consulta de l'ocupaci d'una sessi. Altres esdeveniments (p.e., altes i
baixes de sessions) poden ignorar-se de cara a l'examen.
Per comprar directament una entrada es proporcionen la sessi, la fila i el nmero de la
butaca. Un cop fetes les comprovacions pertinents, s'anota l'ocupaci de la butaca i
s'imprimeix l'entrada amb les dades necessries. En el cas d'una reserva es requereixen les
mateixes dades i el DNI de la persona que ha de recollir l'entrada. Desprs de les
validacions oportunes, s'anota la reserva amb el DNI. Per recollir una reserva es torna a
entrar la mateixa informaci; es fan, com sempre, les comprovacions necessries, es
registra que l'entrada ha sigut pagada i s'imprimeix com en el cas de la compra directa.
Finalment, l'ocupaci d'una sessi es pot consultar mitjanant el seu identificador. Com a
resposta s'obt una llista de butaques reservades i/o comprades directament, i una llista de
butaques lliures.
130
7.
Model Conceptual.
operacions.
El president d'un comit de programa d'un congrs internacional vol construir un sistema
software que l'ajudi a controlar les ponncies enviades al congrs, les persones que
revisaran aquestes ponncies i les revisions que aquestes fan.
Cada ponncia t un codi, que l'identifica, un ttol i est escrita per una o ms persones. De
tots els autors d'una ponncia n'hi ha un que s l'autor principal la resta es consideren
autors secundaris. Un cop rebuda, cada ponncia s'envia a un o ms revisors.
Les persones s'identifiquen pel seu nom. Pot passar que una persona sigui revisora d'una
ponncia i autora d'altres ponncies.
El sistema ha de respondre als cinc esdeveniments segents: donar d'alta un revisor,
recepci d'una ponncia, assignar una ponncia a un revisor, registrar la valoraci que un
revisor fa d'una ponncia i generar un llistat amb les revisions pendents de valoraci.
Per donar d'alta un revisor es proporciona el seu nom. El sistema ha de comprovar que no
existeix cap altre revisor amb el mateix nom.
Quan es reb una ponncia, s'indica el codi de la ponncia, el seu ttol, l'autor principal i la
resta d'autors.
El president del comit de programa assigna cada ponncia a diversos revisors indicant, per
cada assignaci, el codi de la ponncia i el nom del revisor. Un mateix revisor pot tenir
assignades diverses ponncies. No es pot assignar una ponncia a un revisor que sigui
autor d'aquesta mateixa ponncia.
Al cap d'uns dies, els revisors envien el resultat de la revisi que han fet d'una ponncia
indicant el codi de la ponncia, el nom del revisor i la qualificaci que expressa, en una
escala de 0 a 10, la valoraci global que el revisor fa de la ponncia.Com s lgic, un
revisor no pot enviar la valoraci d'una ponncia que no li havia estat assignada. Per altra
banda, un revisor no pot enviar dues valoracions d'una mateixa ponncia.
En qualsevol moment, el president pot demanar un llistat amb les revisions pendents de
valoraci. S'ha de mostrar, per cada ponncia pendent de valoraci per part d'un revisor,
el codi de la ponncia, el seu ttol i el nom del revisor.
Model Conceptual.
operacions.
8.
Considereu una federaci d'entitats excursionistes que est interessada en un sistema pel
control de les expedicions efectuades pels centres excursionistes adscrits a la federaci.
Una expedici l'efectua un centre excursionista a una certa muntanya, amb una data d'inici
i una de finalitzaci. La federaci identifica els centres excursionistes pel seu nom i
n'enregistra tamb la seva adrea. Les muntanyes s'identifiquen pel seu nom i se
131
n'enregistra tamb la seva alada. Un centre excursionista pot efectuar diverses

expedicions a la mateixa muntanya, amb dates dinici diferents. A una muntanya s'hi
poden fer diverses expedicions, per en una data qualsevol hi pot d'haver un mxim de 5
expedicions.
En una expedici hi participen diverses persones (com a mnim una). Una persona pot
participar a ms d'una expedici. El sistema guarda informaci nicament de les persones
(que tenen el dni com a identificador, un nom i una edat) que han participat a alguna
expedici que tenia com objectiu una muntanya de ms de 8.000 metres.
Algun dels components d'una expedici a una muntanya de ms de 8.000 m. pot assolir el
cim. En aquest cas, s'enregistrar aquest fet i tamb la data en qu s'ha fet el cim. Per a
simplificar, suposeu que una persona pot assolir el cim una nica vegada en una mateixa
expedici.
El sistema a desenvolupar nicament ha de consultar les dades referents a centres
excursionistes i muntanyes, ats que ja existeix algun altre sistema encarregat de mantenirles
El sistema ha de permetre efectuar les operacions segents: alta dexpedici, alta de
participant a una expedici a una muntanya de ms de 8.000 metres, alta de persona que ha
fet el cim i emetre un llistat de les dades duna expedici determinada.
Quan sefectua una alta dexpedici, cal indicar el nom del centre excursionista, el nom de
la muntanya a la que sefectua lexpedici, la data dinici i la data de final de lexpedici.
Quan sefectua una alta dun participant a una expedici a una muntanya de ms de 8.000
metres, sindica el dni de la persona, el nom del centre excursionista que fa lexpedici, la
muntanya i la data dinici de lexpedici.
Quan sefectua una alta de persona que ha fet el cim sindica el nom del centre
excursionista que fa lexpedici, la muntanya i la data dinici de lexpedici, el dni de la
persona i la data en qu assoleix el cim.
Per demanar el llistat de les dades duna expedici cal indicar el el nom del centre
excursionista que fa lexpedici, la muntanya i la data dinici de lexpedici. Es mostren el
nom del centre, la muntanya, la seva alada, la data dinici i final dexpedici i, si s el cas,
el nom de totes les persones que han participat en lexpedici i, opcionalment, la data en
qu han fet el cim.
En totes les operacions anteriors, cal realitzar totes les comprovacions que es considerin
adients.
Model Conceptual.
operacions.
9.
Una gran organitzaci ha decidit posar en funcionament un sistema que li permeti gestionar
els cursos de formaci als que assisteixen els seus empleats, ja sigui com a oients o b
mitjanant una matrcula oficial.
Els empleats sidentifiquen per codi, i tenen tamb un nom i una categoria. Els cursos de
formaci sidentifiquen per nom, i senregistra tamb qui ns lorganitzador. En ambds
132
casos, el sistema a desenvolupar nicament nha de consultar les seves dades, ats que ja
existeix un altre sistema que mant tant les dades dempleat com les de curs de formaci.
Un empleat sinscriu a un curs de formaci en una certa data. Cada inscripci fa referncia
a un curs concret. Un empleat es pot inscriure a tants cursos com vulgui i a un curs shi
poden escriure diversos empleats. Un empleat sinscriu una nica vegada a un mateix curs
de formaci. La inscripci dun empleat a un curs de formaci pot ser de dos tipus: com a
oient o b com a matrcula oficial. En el primer cas, el sistema guardar informaci
nicament del motiu pel qual sha realitzat la inscripci. En el segon, senregistraran tant el
motiu com el preu de la inscripci.
En el cas de les inscripcions corresponents a matrcules oficials, lempleat t un mxim de
tres convocatries per tal daprovar el curs al qual sha inscrit. Per cadascuna de les
convocatries a les que t dret un empleat per a un curs determinat, caldr enregistrar-ne
tamb la seva nota.
El sistema ha de permetre efectuar les operacions segents: nova inscripci, assignar nota,
emetre un llistat dinscripcions dun empleat i emetre un llistat de convocatries.
Quan sefectua una nova inscripci, cal indicar el codi dempleat, el nom del curs, la data
dinscripci, el motiu que la justifica, el tipus dinscripci i, en cas de tractar-se duna
matrcula oficial, el preu.
Quan sassigna una nota duna convocatria, sindica el codi dempleat, el nom del curs i
la nota corresponent. El nmero de la convocatria sassignar, automticament i de forma
correlativa, pel propi sistema i es mostrar a lusuari si loperaci sha pogut efectuar
satisfactriament.
Les inscripcions dun empleat es poden consultar indicant-ne el seu codi i, opcionalment,
el tipus dinscripci (si es proporciona noms es llisten les inscripcions daquell tipus). Es
mostren, per cada curs de formaci al que sha inscrit lempleat, el nom del curs, el seu
organitzador, la data dinscripci, el motiu i, si sescau, el preu.
Per demanar el llistat de convocatries cal indicar el codi de lempleat i el nom del curs dels
quals es demana el llistat. Es mostren el nom i la categoria de lempleat, el nom del curs i,
per cada convocatria daquell empleat en aquell curs, el nmero de la convocatria i la
seva nota.
En totes les operacions anteriors, cal realitzar totes les comprovacions que esconsiderin
adients.
Model Conceptual.
operacions.
1 0 . Considereu una facultat universitria que est interessada en un sistema per la definici dels
horaris dels grups de les diferents assignatures. Lhorari indica, per cada grup duna
assignatura (per exemple, ES:E grup 10) quins dies de la setmana hi ha classe i a quina
hora (per a simplificar, suposarem que els perodes de classe sn sempre duna hora). A
ms, tamb cal guardar la informaci de laula de cada horari.
El sistema a desenvolupar noms ha de consultar les dades dASSIGNATURA i les
FRACCIONS HORRIES, ats que existeix un altre sistema encarregat de donar-los
133
dalta. Els diversos nmeros de GRUP es donen dalta a mesura que es coneixen els
horaris dalgun dells. El Model Conceptual en UML daquest sistema s el segent:
FRACCI-HORRIA
dia
hora
ASSIGNATURA
codi
nom
GRUP
fa-classe
1..*
nmero
HORARI
{incomplete}
HOR-COMPLET
aula
El sistema ha de permetre efectuar les funcionalitats segents: definici-dhoraris-dungrup, assignaci-daula, llistat-dhoraris-sense-aula i llistat-dhoraris de totes les
assignatures.
Quan el Cap dEstudis defineix lhorari dun grup, indica el codi de lassignatura, el
nmero de grup a donar dalta i, per cada fracci horria en qu es fa classe daquell grup
de lassignatura, el dia i lhora. s el propi Cap dEstudis qui comunica aquestes dades al
sistema. Feu que la interacci necessria per a portar a terme aquesta funcionalitat
requereixi ms dun esdeveniment.
Quan sefectua una assignaci daula, sindica el codi de lassignatura, el nmero de grup,
el dia, lhora i laula assignada. Aquesta operaci s efectuada pels empleats de secretaria a
requeriment del Cap dEstudis.
Per demanar el llistat dhoraris sense aula duna assignatura determinada, el Cap dEstudis
indica al sistema el codi de lassignatura i el sistema mostra, per a cada horari daquella
assignatura sense aula assignada, el nmero de grup, el dia i la hora.
En qualsevol moment, qualsevol usuari daquest sistema (inclosos Professors i Alumnes)
pot demanar el llistat dhoraris de totes les assignatures. El sistema mostra, per a cada
assignatura, el seu codi i, per a cada grup de lassignatura, el seu nmero, els dies i hores
en qu es fa classe i, si es coneix, laula.
Us demanem que feu els models segents (tots ells mitjanant la notaci UML). En tots els
casos, cal realitzar totes les comprovacions que siguin necessries. Si nhi ha, cal indicar
les modificacions necessries a fer en el Model Conceptual de partida.
Model de Casos ds: Diagrama de casos ds. Especificaci del cas ds de
lassignaci daula.
Model del Comportament del Sistema: tots els diagrames de seqncia i contractes
de les operacions corresponents a la definici dels horaris dun grup i al llistat
dhoraris sense aula duna assignatura.
134
1 1 . Considereu una empresa de transports que est interessada en un sistema per la definici
dels recorreguts de les rutes de distribuci dels seus camions. Una ruta est formada per
una srie de trams consecutius (que es distingeixen pel nmero de tram dins la ruta). Un
tram es defineix per una poblaci dorigen, una de dest i una carretera que uneix les dues
poblacions. A ms, tamb cal guardar la informaci de la distncia i de la durada de
recorregut dun tram.
El sistema a desenvolupar noms ha de consultar les dades de POBLACI i de
CARRETERA, ats que existeix un altre sistema encarregat de donar-les dalta. El Model
Conceptual en UML daquest sistema s el segent:
POBLACI
nom-p
habitants
1.. 2
(origen)
CARRETERA
fan-tram
1.. 2
1..*
codi-c
(dest)
TRAM
de-la
distncia
durada
RUTA
* codi-ruta
TRAM-RUTA
nm-tram
R.I. Textual:
- La poblaci dest dun tram de la ruta ha de coincidir amb la poblaci origen del tram segent de la mateixa ruta.
- La poblaci origen i la poblaci dest dun tram han de ser diferents.
El sistema ha de permetre efectuar les funcionalitats segents: alta-tram, alta-ruta, llistat-detrams-sense-ruta i llistat-dels-trams-duna-ruta.
Quan es dna dalta un tram, sindica el nom de la poblaci dorigen, el nom de la poblaci
de dest, el codi de la carretera, la distncia i la durada del tram. Aquesta operaci s
efectuada pels empleats de lempresa, a requeriment del Director de Distribuci.
Quan el Director de Distribuci dna dalta una ruta, indica ell mateix al sistema el codi de
la ruta i, per cada tram que forma part de la ruta que sest donant dalta, les poblacions
dorigen i dest del tram, el codi de carretera i el nmero de tram dins la ruta. Feu que la
interacci necessria per a portar a terme aquesta funcionalitat requereixi ms dun
esdeveniment.
El llistat dels trams sense ruta assignada semet sempre a final de mes i va dirigit al Director
de Distribuci. El resultat daquest llistat inclou, per cada tram que no est assignat a cap
ruta, el nom de les poblacions dorigen i dest del tram i el codi de la carretera que les
uneix.
En qualsevol moment, els empleats de lempresa poden demanar el llistat dels trams duna
ruta. El sistema mostra, per a cada tram de la ruta indicada per lempleat, el nom de la
poblaci dorigen i de dest, el codi de la carretera, la distncia i la durada del tram i el
nmero de tram dins la ruta.
Model de Casos ds: Diagrama de casos ds. Especificaci del cas ds de lalta
tram.
Model del Comportament del Sistema: Tots els diagrames de seqncia. Contractes
de les operacions corresponents lalta de ruta i al llistat dels trams duna ruta.
135
1 2 . Considereu un club dautomobilistes que est interessat en desenvolupar un sistema

software per a gestionar assegurances de vehicles. Un vehicle (identificat pel seu nmero
de matrcula i del que se nenregistra tamb el model) s comprat per un nic conductor
(identificat per nmero de llicncia i del que sen coneix el nom) en una certa data. Un
conductor, pot haver comprat diversos vehicles. El sistema guardar nicament la
informaci dels conductors que han comprat algun vehicle.
Tot vehicle comprat ha de contractar una assegurana daccidents a alguna companyia.
Quan es fa un daquests contractes, senregistra tamb la data dinici del mateix. Un vehicle
no pot estar contractat a ms duna companyia, mentre que una companyia pot tenir
diversos contractes de vehicles diferents. De les companyies dassegurances ens interessa
enregistrar el seu nom i ladrea (que suposarem nica per cada companyia).
Cal enregistrar tamb la informaci dels conductors que no sn acceptats per les
companyies dassegurances, conjuntament amb el motiu de la no acceptaci. Lgicament,
una companyia no podr tenir assegurances de cotxes comprats per conductors que no sn
acceptats per la companyia. Un conductor pot no ser acceptat per diverses companyies.
Per simplificar, suposarem que la informaci de conductors, vehicles i compres de vehicles
s mantinguda per algun sistema extern i, per tant, el sistema a desenvolupar nicament
lhaur de consultar. En canvi, el sistema a desenvolupar ha de permetre efectuar altes de
contracte dassegurana, baixes de contracte, enregistrar conductors no acceptats per les
companyies i llistat dassegurances duna companyia.
Quan es vol fer una alta de contracte dassegurana cal indicar la matrcula del cotxe, el nom
de la companyia on es fa lassegurana i la data en qu es fa efectiu el contracte. Quan es
vol donar de baixa un contracte, sndica la matrcula del cotxe i el nom de la companyia.
En ambds casos, sn els empleats qui comuniquen les dades al sistema, a requeriment
dalgun conductor.
Les companyies dassegurances envien al club dautomobilistes els llistats de conductors
que no sn acceptats per la companyia. Algun empleat del club, quan aix ho consideri
convenient, comunicar al sistema el llistat de tots els conductors no acceptats per les
diverses companyies. Sindicar, per cada companyia, el nmero de llicncia de cadascun
dels conductors no acceptats. Feu que la interacci necessria per a portar a terme aquesta
funcionalitat requereixi ms dun esdeveniment.
Per demanar el llistat dels contractes duna companyia, el Director del club dautomobilistes
indica directament al sistema el nom de la companyia i el sistema mostra, per a cada
contracte dassegurances daquella companyia, la matrcula del cotxe, el nmero de llicncia
del seu propietari i la data de contractaci de lassegurana.
En tots els casos, cal realitzar totes les comprovacions que es considerin adients.
Model Conceptual, que ha dincloure totes les restriccions textuals necessries i una
instanciaci del model que demostri la seva validesa.
Model de Casos ds:
- Diagrama de casos ds.
- Especificaci del cas ds de lalta de contracte, que ha dincloure totes les
comprovacions a realitzar.
Model del Comportament del Sistema:
- Diagrames de seqncia de enregistrar conductors no acceptats i de llistat de
contractes duna companyia.
- Contractes de les operacions corresponents a aquests diagrames de seqncia.
136
1 3 . Considereu una agncia immobiliria dun poble turstic de lAlt Empord que est
interessada en un sistema per gestionar els lloguers de les finques que posseeix al poble. El
sistema guarda informaci dels carrers (identificats per nom) on t situades les finques
(identificades per nmero dins el carrer) i dels lloguers de les finques que fan els clients de
lagncia (identificats per dni). Els lloguers fan referncia a un pis de la finca (1er 1a, 1er
2a, etc) i poden ser temporals o b indefinits. El sistema ha de guardar tamb informaci
del preu del lloguer i datributs especfics per a cada tipus de lloguer. A ms, el sistema
noms ha de consultar les dades de CLIENT ats que hi ha un altre sistema encarregat de
donar-les dalta. El Model Conceptual en UML daquest sistema s el segent:
CARRER
FINCA
1
nom-c
1..*
amb
llogada-per
*
num-f
LLOGUER
pis
preu
tipus
tipus
TEMPORAL
A
data-fi-lloguer
CLIENT
dni
nom
{Disj., Comp.}
INDEFINIT
augment
R.I.textuals:
- Claus de les classes no associatives: (Carrer, nom-c), (Client, dni).
- Un carrer no pot teni r dues finques amb el mateix nmero.
El sistema ha de permetre efectuar les funcionalitats segents: alta-carrer, alta-lloguersfinca, baixa-lloguers i llistat-dels-lloguers-amb-augment-elevat.
Quan es dna dalta un carrer, sindica el nom del carrer i, per cada finca daquell carrer, el
seu nmero de finca. Aquesta operaci s efectuada pels empleats de lagncia, a
requeriment de la Directora de lagncia.
Quan el Responsable de Lloguers dna dalta tots els lloguers duna finca, indica ell mateix
al sistema el nom del carrer, el nmero de la finca i, per cada lloguer daquella finca que es
dna dalta, el dni del client, el pis llogat, el preu, el tipus de lloguer (temporal o indefinit) i
la data-fi-lloguer o laugment anual establert, segons sescaigui. Feu que la interacci
necessria per a portar a terme aquesta funcionalitat requereixi ms dun esdeveniment.
A final del dia, es donen de baixa automticament tots els lloguers que finalitzen en aquesta
data. A ms, el sistema genera un llistat que inclou, per cada lloguer donat de baixa, el nom
del carrer, el nmero de finca, el dni del client i el pis.
En qualsevol moment, tots els empleats de lempresa poden demanar el llistat dels lloguers
amb augment elevat. El sistema mostra, per cada lloguer indefinit amb un augment superior
al 5%, el nom del carrer, el nmero de finca i el nom del client que t el pis llogat.
a) Model de Casos ds: Diagrama de casos ds. Especificaci del cas ds dalta
carrer.
b) Model del Comportament del Sistema: Tots els diagrames de seqncia. Contractes
de les operacions corresponents lalta de lloguers duna finca i al llistat dels lloguers
amb augments elevats.
137
1 4 . Considereu un centre excursionista que ha decidit organitzar la travessa dels Pirineus a peu,
des de Biarritz al Cap de Creus. Aquesta travessa consta de diverses jornades (identificades
per un nmero) que es recorren entre una poblaci dinici i una de final. Tota jornada t una
srie de controls (identificats per un nmero dins la jornada) per garantir que cap participant
no es perd. Les persones es poden inscriure a una jornada de la travessa. El sistema
emmagatzema tamb les hores de pas de tots els participants per a cadascun dels controls
que passen. A ms, el sistema noms ha de consultar les dades de PERSONA ats que hi
ha un altre sistema encarregat de donar-les dalta. El Model Conceptual en UML daquest
sistema s el segent:
JORNADA
sinscriu
amb
Num-jorn
Pob-inici
* Pob-fi
CONTROL
1..*
*
num-cont
lloc
passa-per
PERSONA
dni
nom-p
*
PARTICIPACI
CONTROL PARTI CIPANT
hora-de-pas
R.I.textuals:
- Claus de les classes no associatives: (Jornada, num-jornada), (Persona, dni).
- Una jornada no pot tenir dos controls amb el mateix num-cont.
- La poblaci final duna jornda i la dinici de la jornada segent han de coincidir
- La persona que participa a control-participant ha dest ar inscrita a la jornada daquell control
El sistema ha de permetre efectuar les funcionalitats segents: alta-jornada, alta-participant,

assignar-passos-per-control i llistat-dels-controls-duna-jornada.
Quan es dna dalta una jornada, sindica el nmero de la jornada, la poblaci dinici, la
poblaci de final i, per cada control daquella jornada que sest donant dalta en aquell
moment, el seu nmero de control i el lloc. Les jornades no es donen dalta totes de cop,
sin que es van comunicant al sistema a mesura que es pren la decisi del seu recorregut
concret. A ms, ja no es poden donar dalta jornades un cop es coneixen els primers
control de pas de la travessa. Lalta de jornades s efectuada pels empleats de lagncia, a
requeriment de la Responsable de Recorregut. Cal fer que la interacci necessria per a
portar a terme aquesta funcionalitat requereixi ms dun esdeveniment.
Quan una persona vol participar en una jornada de la travessa, ho fa saber a lempleat que
s qui comunica aquesta informaci al sistema. Nhi ha prou indicant el dni de la persona i
el nmero de jornada.
Quan el Controlador en Cap dna dalta tots els controls dels participants duna jornada,
indica ell mateix al sistema el nmero de jornada i, per cada persona que ha participat en
aquella jornada el nmero de control i lhora de pas de tots els controls perqu ha passat.
La interacci necessria per portar a terme aquesta funcionalitat ha de requerir tamb ms
dun esdeveniment.
En qualsevol moment, el Controlador en Cap pot demanar un llistat dels controls duna
jornada. Donada una jornada, que s indicada per ell mateix al sistema, aquest mostra el
dni del participant, el nmero de control i lhora de pas de tots els controls de participant.
Model de Casos ds: Diagrama de casos ds. Especificaci del cas ds dalta
jornada.
Model del Comportament del Sistema: Tots els diagrames de seqncia. Contractes
de les operacions corresponents lalta de controls i al llistat de controls.
138
1 5 . Considereu una facultat universitria que est interessada en un sistema per la definici dels
grups de les diferents assignatures. Una assignatura pot tenir diversos grups (per exemple,
grups nmero 10 i 20 de lassignatura FBD; grups nmero 10, 20 i 30 de lassignatura
ES:E, etc.). Una matrcula es defineix per un estudiant i per un grup on lestudiant es
matricula. Les matrcules poden ser de dos tipus: davaluaci continuada i davaluaci no
continuada. Per les matrcules davaluaci no continuada senregistra la nota final de
lestudiant. Per les davaluaci continuada sentregistren les diverses notes parcials de
lestudiant. El Model Conceptual en UML daquest sistema s el segent:
ASSiGNATURA
1
codi-assig
nom
crdits
ESTUDIANT
GRUP
*
nmero
capacitat
* es-matric *
dni
nom
telfon
MATRCULA
PARCIAL
num-parcial
tipus
correspon
*
NOTA PARCIAL
nota
AVALUACI
CONTINUADA
AVALUACI
NO CONTINUADA
nota-final
R.I. textuals:
- Claus de les classes no associatives: (Assignatura, codi-assig), (Estudiant, dni), (Parcial, num-parcial)
- No hi pot haver cap assignatura que tingui dos grups amb el mateix nmero
- Un estudiant no pot matricular-se de ms dun grup de la mateixa assignatura
El sistema a desenvolupar noms ha de consultar les dades dASSIGNATURA,

ESTUDIANT i PARCIAL, ats que existeix un altre sistema encarregat de donar-los
dalta. El sistema ha de permetre efectuar entre daltres les funcionalitats segents: altagrups-duna-assignatura, matrcula-estudiant, assignaci-notes-parcials, consultadestudiants-amb-notes-finals-aprovades.
Quan el Cap dEstudis vol definir els grups duna assignatura, indica el codi de
lassignatura i, per cada grup a donar dalta, el nmero de grup i la capacitat del grup. s
el propi Cap dEstudis qui comunica aquestes dades al sistema. Feu que la interacci
Quan un estudiant es matricula en un grup, indica el codi de lassignatura, el nmero de
grup, el seu dni i el tipus de matrcula (aval. cont. o no). Aquesta operaci s efectuada pel
propi estudiant.
Quan un professor vol fer una assignaci de notes parcials a estudiants amb matrcula
davaluaci continuada en un determinat grup, sindica el codi de lassignatura, el nmero
de grup i el nmero de parcial i, per cada estudiant que t nota parcial, el dni de lestudiant i
la nota. Aquesta operaci s efectuada per lempleat de secretaria a requeriment del
professor. Feu que la interacci necessria per a portar a terme aquesta funcionalitat
requereixi ms dun esdeveniment.
El Cap dEstudis en qualsevol moment pot consultar els estudiants amb notes finals
aprovades. El sistema mostra, per cada matrcula davaluaci no continuada amb nota final
ms gran o igual que 5, el dni de lestudiant, el codi de lassignatura i el nmero de grup.
Us demanem que feu els models segents en UML. Cal realitzar totes les comprovacions
necessries. Si nhi ha, cal indicar els afegits necessaris al Model Conceptual de partida.
- Model de Casos ds: Diagrama de casos ds (per les funcionalitats especificades).
Especificaci del cas ds de lalta de grups duna assignatura.
- Model del Comportament del Sistema: Tots els diagrames de seqncia. Contractes de
les operacions corresponents a lassignaci de notes parcials i a la consulta destudiants
amb notes finals aprovades.
139
1 6 . Considereu un centre de gesti electoral que est interessat en desenvolupar un sistema

software per a gestionar les candidatures i resultats de les successives eleccions municipals.
Una candidatura sidentifica mitjanant el partit que la presenta, el municipi al qual
correspon i les eleccions per a les que sha confeccionat. A cada candidatura shi presenta
un conjunt de persones candidates (com a mnim 3) que poden presentar-se com a candidats
independents o no. Una mateixa persona no pot estar a ms duna candidatura per elecci.
Cal que el sistema tingui enregistrades quines sn les persones candidates de cada
candidatura i tamb si es presenten com a independents o no (tipus de candidat). Les
persones sidentifiquen pel seu dni i tamb vol enregistrar-se el seu nom.
Cadascuna de les eleccions municipals sidentifica pel seu any de realitzaci, els municipis
sidentifiquen pel seu nom i els partits per les seves sigles. A ms, el sistema ha
denregistrar el nom de cada partit i la comarca de cada municipi.
Un cop shan efectuat unes eleccions, per les candidatures que hagin obtingut
representaci, el sistema haur de permetre tenir enregistrat el nmero total de representants
obtingut i quins sn els candidats (de la candidatura) que queden escollits com a
representants. Per les candidatures que no hagin obtingut representaci, el sistema haur de
permetre enregistrar el nmero de vots obtinguts per la candidatura.
Per simplificar, suposarem que la informaci deleccions, municipis, partits i persones s
mantinguda per algun sistema extern i, per tant, el sistema a desenvolupar nicament
lhaur de consultar. En canvi, el sistema a desenvolupar ha de permetre efectuar altes de
candidatures, entrades de resultats de candidatures sense representaci, entrades de
resultats de candidatures amb representaci i llistats de candidats escollits duna
candidatura.
Quan es vol donar dalta una candidatura cal indicar les sigles del partit, el nom del
municipi, lany de les eleccions i, per cada candidat, el dni, el nom i el seu tipus
(independent o no). Una candidatura es dna dalta tota de cop i, una vegada feta lalta, no
shi poden afegir candidats. A ms, no es poden donar dalta noves candidatures per
eleccions que ja tinguin algun resultat entrat. Lalta de candidatures s efectuada pels
empleats del centre a requeriment dels interlocutors dels partits. Feu que la interacci
Quan un empleat del centre vol entrar els resultats duna candidatura sense representaci,
indica ell mateix al sistema les sigles del partit, el nom del municipi, lany de les eleccions i
el nmero de vots obtingut per la candidatura.
Quan un empleat del centre vol entrar els resultats duna candidatura amb representaci,
indica ell mateix al sistema les sigles del partit, el nom del municipi i lany de les eleccions.
A ms, per cada candidat que queda escollit com a representant, indica el seu dni. Els
resultats duna candidatura amb representaci sentren tots de cop. Feu que la interacci
En qualsevol moment, els interlocutors dels partits poden demanar un llistat de candidats
escollits duna candidatura. Aleshores, un empleat del centre indica les sigles del partit, el
nom del municipi i lany de les eleccions de la candidatura. Com a resposta el sistema
mostra, per cada candidat de la candidatura que hagi quedat escollit com a representant, el
dni, el nom i el tipus de candidat (independent o no). Evidentment, per poder demanar
aquest llistat, cal que la candidatura tingui representaci.
Us demanem que feu els models segents (tots ells mitjanant la notaci UML).
- Model Conceptual, que ha dincloure totes les restriccions textuals i atributs derivats
necessaris (en narrativa, no en OCL) i una instanciaci del model que demostri la seva
validesa.
- Model de Casos ds: Diagrama de casos ds. Especificaci del cas ds de lentrada de
resultats duna candidatura amb representaci (que inclogui totes les comprovacions a
realitzar)
140
Model del Comportament del Sistema: Diagrames de seqncia de alta candidatura i

llistat de candidats escollits duna candidatura. Contractes de les operacions
corresponents a aquests diagrames de seqncia (que incloguin totes les comprovacions a
realitzar). Si nhi ha, indiqueu els afegits necessaris al Model Conceptual de partida.
Expresseu les sortides amb lajuda del llenguatge OCL.
1 7 . Considereu una Universitat que est interessada en un sistema per a la gesti de la matrcula
dels seus alumnes a les diferents titulacions que imparteix. Per simplificar, suposarem que
interessa emmagatzemar nicament la informaci referent a un sol curs acadmic.
La Universitat ofereix diverses titulacions. Una titulaci imparteix un conjunt
dassignatures, cadascuna de les quals consta de diversos grups de lassignatura. Un
alumne pertany a una o ms titulacions de la Universitat i es pot matricular de grups de les
assignatures daquestes titulacions. El Model Conceptual en UML daquest sistema s el
segent:
Assignatura
*
imparteix
1..*
num-grup
capacitat-mx.
amb
nom-a
Grup
es-matricula
*
*
Titulaci
nom-t
facultat
1..*
Alumne
pertany
*
dni
adrea
R.I.textuals:
- Claus de les classes no associatives: (Titulaci, nom-t), (Alumne, dni).
- Una assignatura no pot tenir dos grups amb el mateix num-grup.
- Una titulaci no pot tenir dues assignatures amb el mateix nom-a.
- Un alumne no es pot matricular a dos grups diferents duna mateixa assignatura
- Un alumne noms es pot matricular dassignatures que sn impartides en titulacions a les que ell pertany.
El sistema a desenvolupar no ha de donar dalta les dades de Titulaci, Alumne, Pertany i

Es-matricula, ats que hi ha un altre sistema encarregat de fer-ho. El sistema ha de permetre
efectuar, entre daltres, les funcionalitats segents: alta-dassignatures-impartides i
informaci-alumne.
Quan la Cap dEstudis duna titulaci defineix les assignatures que simparteixen a aquella
titulaci indica el nom de la titulaci i, per cada assignatura, el nom de lassignatura i la
informaci referent a tots els grups de lassignatura (o sigui, per cada grup de lassignatura,
el nmero de grup i la seva capacitat mxima). Com a conseqncia daquesta interacci, la
prpia Cap dEstudis rep un llistat en el qual es mostra, per tot grup amb una capacitat
mxima superior a 80 alumnes, el nmero de grup i el nom de la seva assignatura. Per una
titulaci, lalta de les assignatures impartides es realitza tota de cop. Feu que la interacci
Quan ho desitgin, els alumnes poden demanar la informaci dels estudis que estan fent a la
Universitat. Per a fer-ho indiquen ells mateixos al sistema el seu dni i aquest mostra, per
cada titulaci a la que pertany lestudiant el nom de la titulaci ms el nom de lassignatura i
el nmero de grup de tots els grups dels que lestudiant sha matriculat en aquesta titulaci.
casos, cal realitzar totes les comprovacions que siguin necessries.
Model de Casos ds: Diagrama de casos ds (de les funcionalitats especificades).

operacions corresponents a lalta-dassignatures-impartides i a informaci-alumne.
Expresseu les sortides de les operacions amb lajut del llenguatge OCL.
141
1 8 . Considereu una empresa que es dedica a lorganitzaci de congressos i que est interessada
en un sistema per a la gesti de les sessions, de les ponncies i dels assistents als diversos
congressos que organitza. Un congrs sestructura en sessions. Cada sessi dun congrs
es dedica a la presentaci de diverses ponncies. Les ponncies tenen diversos autors. Les
persones que volen assistir a un congrs shi han dinscriure. Les inscripcions poden ser de
dos tipus: de tipus normal o de tipus estudiant. Per les inscripcions destudiant
senregistra el nom de la universitat on est estudiant la persona inscrita en el moment de la
inscripci. Per les inscripcions normals senregistra la professi de la persona inscrita en el
moment de la inscripci. El Model Conceptual en UML daquest sistema s el segent:
Congrs
Ponncia
Sessi
t
sigles
any
preu
nom-sessi
* durada
es-presenta
1
codi
ttol
0..4
assisteix-a
*
s-autor
Inscripci
tipus
Ins. Normal
professi
1..*
Persona
nom
Ins. Estudiant
universitat
R.I. textuals:
- Claus de classes no associatives: (Congrs: sigles, any), (Ponncia: codi), (Persona: nom)
- No hi pot haver cap congrs que tingui dos sessions amb el mateix nom de sessi.
El sistema a desenvolupar no ha de donar dalta les dades de les inscripcions, ats que
existeix un altre sistema encarregat de fer-ho. El sistema ha de permetre efectuar entre
daltres les funcionalitats segents: alta-de-congrs-i-sessions, alta-de-ponncies-dunasessi i consulta-destudiants-i-autors.
Quan el President del Comit Organitzador dun congrs vol donar dalta el congrs i les
seves sessions, indica les sigles, any i preu del congrs i, per a cada sessi del congrs, el
nom de la sessi i la seva durada. s el propi President del Comit Organitzador qui
comunica aquestes dades al sistema. Finalment, el sistema mostra el nombre total de
sessions donades dalta pel congrs. Feu que la interacci necessria per a portar a terme
aquesta funcionalitat requereixi ms dun esdeveniment.
Quan el President del Comit de Programa dun congrs vol donar dalta les ponncies
duna sessi del congrs, sindiquen les sigles i any del congrs i tamb el nom de la
sessi. A ms, per a cada ponncia de la sessi, sindiquen el codi i ttol de la ponncia
juntament amb els noms de tots els autors de la ponncia. Cal considerar que alguns
daquests autors existiran a la base dinformaci mentre que daltres no. Tamb cal tenir en
compte que no es poden donar dalta ponncies a sessions de congressos que ja tenen
alguna persona inscrita. Aquesta alta s efectuada per un administratiu de lempresa a
requeriment del President del Comit de Programa. Feu que la interacci necessria per a
portar a terme aquesta funcionalitat requereixi ms dun esdeveniment.
Finalment, quan una persona qualsevol indica que vol fer una consulta destudiants i
autors, el sistema mostra els noms de les persones que assisteixen amb inscripci
destudiant a algun congrs i que, alhora, sn autors dalguna ponncia que es presenta en
alguna sessi del mateix congrs.
Us demanem que feu els models segents (tots ells mitjanant la notaci UML).
-
Model de Casos ds: Diagrama de casos ds (per les funcionalitats especificades).

Model del Comportament del Sistema: Diagrames de seqncia i contractes de les
operacions corresponents a lalta de congrs i sessions, a lalta de les ponncies duna
sessi i a la consulta destudiants i autors. Expresseu les sortides de les operacions amb
lajut del llenguatge OCL.
142
Teoria
1. Model del Comportament en UML:
a) s possible en UML que lespecificaci del contracte duna operaci no tingui ni

precondici ni postcondici, per en canvi si que tingui sortida?
b) s possible en UML que lespecificaci del contracte duna operaci no tingui
precondici, per en canvi si que tingui postcondici?
En ambds casos, justifica breument la teva resposta i, si ho creus convenient, il.lustra-la
mitjanant un exemple.
2. En un diagrama destats dUML, t sentit especificar una transici que porti dun estat a ell
mateix com a conseqncia dun esdeveniment determinat? Justifica la teva resposta i, en cas
afirmatiu, posan un exemple que il.lustri el perqu.
143

Enginyeria Del Software, Especificació Amb UML

Uploaded by

Document Information

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

Enginyeria Del Software, Especificació Amb UML

Uploaded by

Copyright:

Available Formats

AULA POLITCNICA / FIB

Dolors Costal - M. Ribera Sancho

Enginyeria del Software

Primera edici: febrer del 2000

Aquesta publicaci s'acull a la poltica de normalitzaci lingstica

Els autors, 2000

Edicions UPC, 2000

CPET (Centre de Publicacions del Campus Nord)

Els autors, 2000; Edicions UPC, 2000.

Els autors, 2000; Edicions UPC, 2000.

ES:E - Introducci a lEnginyeria del Software

Introducci a lEnginyeria del Software

Enginyeria del Software

ES:E - Introducci a lEnginyeria del Software

Evoluci de Costos del Hardware i del Software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Introducci a lEnginyeria del Software

Evoluci del software

ES:E - Introducci a lEnginyeria del Software

Caracterstiques del software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Introducci a lEnginyeria del Software

ES:E - Introducci a lEnginyeria del Software

Aplicacions del Software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Introducci a lEnginyeria del Software

Crisi del software

ES:E - Introducci a lEnginyeria del Software

Resultat de projectes de software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Introducci a lEnginyeria del Software

Enginyeria del software

Establiment i s de principis de lenginyeria orientats a obtenir

ES:E - Introducci a lEnginyeria del Software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Introducci a lEnginyeria del Software

ES:E - Introducci a lEnginyeria del Software

Visi genrica de lEnginyeria del Software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Introducci a lEnginyeria del Software

Cicle de vida clssic

ES:E - Introducci a lEnginyeria del Software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Introducci a lEnginyeria del Software

ES:E - Introducci a lEnginyeria del Software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Requeriments i Especificacions

Determinaci dels requeriments del software

Especificacions de sistemes software

ES:E - Requeriments i Especificacions

Requeriments del sistema vs. requeriments del software

Els autors, 2000; Edicions UPC, 2000.

ES:E - Requeriments i Especificacions

Etapes de lenginyeria de sistemes

Determinar requeriments del sistema

ES:E - Requeriments i Especificacions

Determinar requeriments del sistema global

Sistema que rep i verifica els productes demanats

Els autors, 2000; Edicions UPC, 2000.

ES:E - Requeriments i Especificacions

Especificar els requeriments del sistema global

ES:E - Requeriments i Especificacions

Disseny del sistema

Els autors, 2000; Edicions UPC, 2000.