Professional Documents
Culture Documents
Enginyeria Del Software, Especificació Amb UML PDF
Enginyeria Del Software, Especificació Amb UML PDF
EDICIONS UPC
Primera edici: febrer del 2000
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
Paradigmes
Cicle de vida clssic
Prototipatge
Model en espiral
Bibliografia
100%
HARDWARE
SOFTWARE
1960 70 80 90
11
Batch Distirubuci
Poca distribuci Hardware barat
A mida Software de consum
1950 60 70 80 90 2000
Es desenvolupa, no es fabrica
No sespatlla
12
Fallades H/S
ndex
fallades
Hardware
Software
temps
Sistemes
Temps real
Gesti
Denginyeria
Cientfic
Empotrat
De PC
DIntel.ligncia Artificial
13
Problemes:
Evoluci contnua
Insatisfacci dels usuaris
Poca qualitat
Manteniment difcil
Causes:
Naturalesa del software
Complexitat
Gesti
Mites:
De gesti
Dels clients
Dels dissenyadors
USA T USA T
2% DESPRS
PA GAT, NO CANVIS ABA NDONA T O
LLIURAT 3% REFET
47%
19%
LLIURAT, NO
USA T
29%
14
Econmic
Fiable
Un enginyer ...
15
El procs de lenginyeria
Formulaci
Anlisi
Generaci
Selecci
Especificaci
Implementaci
Modificaci
Definici:
Anlisi del sistema
Planificaci del projecte
Anlisi de requeriments del software
Desenvolupament:
Disseny del software
Codificaci
Prova
Manteniment:
Correcci
Adaptaci
Millora
16
ANLISI
DISSENY
CODIFICACI
PROVA
MANTENIMENT
Prototipatge
ANLISI
REQUERIMENTS
PRODUCTE DISSENY
RPID
REFI_ PROTO_
NAMENT TIPUS
AVALUACI
17
Model en Espiral
Avaluaci Enginyeria
Bibliografia
R.S. Pressman
Ingeniera del Software: Un enfoque prctico.
4a edici.
McGraw Hill, 1997. (Cap. 1)
18
Requeriments i Especificacions
Bibliografia
19
Determinar
requeriments
Especificar
requeriments
Disseny
enginyeria enginyeria
del hardware del software
enginyeria de sistemes
MAGATZEM
20
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
error
1. Comprovar si esperada
error
2. Comprovar correspondncia
albar
3. Control de qualitat
5. Determinar on va PRODUCTES
PRESTATGES
ordre
6. Emmagatzemar
SOFTWARE
MANUAL PRODUCTES EN PRESTATGES
H ARDWARE
21
Recepci
albar comanda
avs albar
defectus resultat
Sistema
Informtic
ordre
errors
Transport
comanda avs
SISTEMA
albar INFORMTIC ordre
resultat errors
22
albar comanda
Tractar Rebre
Albarans Comandes
error
avs comandes
Actualitzar
resultat Comandes productes
prestatges
Emetre
Ordre
ordre
Demanar-ho a lusuari
23
No funcionals
Defineixen les qualitats generals que ha de tenir el sistema en
realitzar la seva funci
Qualitat
Interfcies
Rendiment extern
Econmics
Estructurals
Poltics
Eficincia
Flexibilitat
Integritat
Mantenibilitat
Portabilitat
Fiabilitat
Actualitat
Reusabilitat
Testability
Usabilitat
Interoperabilitat
24
Eficincia
Flexibilitat
Integritat
Mantenibilitat
Portabilitat
Fiabilitat
Actualitat
Reusabilitat
Testability
Usabilitat
Interoperabilitat
No ambiges
Completes
Verificables
Consistents
Modificables
Traables
25
1. Introducci
1.1 Propsit de lespecificaci
1.2 Abast del producte
1.3 Definicions i abreviatures
1.4 Referncies
1.5 Visi general de lespecificaci
2. Descripci General
2.1 Perspectiva del producte
2.2 Funcions del producte
2.3 Caracterstiques dels usuaris
2.4 Restriccions generals
2.5 Supsits i dependncies
3. Requeriments especfics
4. Apndixos
5. ndex
26
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
Motivaci i orgens
La notaci UML
Motivaci
- Altres factors:
Desenvolupament de noves aplicacions
mfasi principal en l'estructura de dades
28
Orgens
Fusion
OOSE Martin-Odell
Processos i Models
Recomanats Shlaer &
BOOCH Mellor
OMT UML
29
Objectes
Objecte:
Entitat que existeix al mn real
Tenen identitat i sn distingibles entre ells
Classes dobjectes
Classe d'objectes: descriu un conjunt d'objectes amb:
- les mateixes propietats
- comportament com
- idntica relaci amb altres objectes
- semntica comuna
30
Atributs
Atribut: s una propietat compartida pels objectes d'una classe.
Exemples:
Persona => nom, adrea, telfon, ...
Avi => model, capacitat, color, ...
Persona Avi
Nom Model
Adrea Capacitat
Telfon Color
Data_naixement
Edat
Operacions (I)
Persona Avi
Nom Model
Adrea Capacitat
Telfon Colors
Canvi_adrea Reparar
Canvi_feina Moure
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
Associacions
Associaci:
defineix la manera d'enllaar o connectar objectes de
diferents classes
Pas Ciutat
t_capital
Nom Nom
Habitants Habitants
32
Generalitzaci
Generalitzaci: s l'acte o resultat de distingir un concepte que s
ms general que un altre
Empleat
Nom
Sou
Especialitzaci Contractar Generalitzaci
Pagar_sou
Jubilar
33
34
Soltera
casament
divorci Casada
Separada Vdua
enviudar
comanda
Lliurar lliurada Tancar
Preparar comanda
comanda comanda comanda tancada
comanda
preparada
factura
Client paga pagada
Enviar
factura factura
factura
enviada
35
Disseny:
- definici duna soluci software que satisfaci els requeriments
- Com ho far el sistema
orientats a objectes
36
Industrialitzaci
Booch93 OMT-2
El triangle de lxit
U.M.L. Notaci
Procs Eina
(metodologia)
Rational Rose
Craig Larman
37
Model
DAnlisi
38
Introducci
Objectes i classes dobjectes
Atributs
Associacions
Classe associativa
Generalitzaci/Especialitzaci
Agregaci i composici
Ampliacions
Exemples
Model
DAnlisi
39
Model Conceptual
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
40
Classe dobjectes
Classe d'objectes: descriu un conjunt d'objectes amb:
- les mateixes propietats
- comportament com
- idntica relaci amb altres objectes
- semntica comuna
Diagrama de classes
41
Atributs
Els atributs:
- Poden prendre valors nuls
- Poden ser multivaluats
Associacions
- direcci de lectura
Viu a
Persona Ciutat
- nom dassociaci
42
Alumne
Assignatura Quadrimestre
Es matricula
Associacions - Multiplicitat
1
A B
2..5
A B
1..*
A B
2, 5
A B
*
A B
1..3,7..10,15..*
A B
0..1
A B
0..*
A B 1..* 1
A B
0..2
C
43
* Vola cap a 1
Vol Ciutat
destinaci
Nom de Rol
Descriu el Rol d una ciutat
en lassociaci vola cap a
Associacions recursives
Persona
0..2 *
pare fill
Crea
Persona
* *
T per amic
44
Classe associativa
Representa una associaci que es pot veure com una classe
Estudiant Assignatura
EstMatriculat
adrea nom
nom * * crdits
Matrcula
nota Classe associativa
Els atributs fan referncia a lassociaci
La seva vida depn de lassociaci
Empresa Persona
Emplea
nom
* *
adrea
Contracte
sou
* sha allotjat *
Viatge Hotel
Persona * * 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 * * Ciutat
45
Generalitzaci/Especialitzaci
supertipus
Persona
E G
sexe {disjoint, complete}
Home Dona
subtipus
discriminador - Es el nom de la partici. Ha de ser nic entre els
atributs i rols de la superclasse
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
Generalitzaci/Especialitzaci
Permet entendre els conceptes en termes ms generals, refinats i
abstractes.
Fa els diagrames ms expressius.
46
Generalitzaci/Especialitzaci
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
Atributs i 1 Venda
associacions comunes Pagament
associacions
Quantitat: Diners addicionals
Generalitzaci/Especialitzaci
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.
Paga per 1
Atributs i 1 Venda
associacions comunes Pagament
associacions
Quantitat: Diners addicionals
47
Agregaci
Lagregaci s un tipus dassociaci usada per modelar relacions part-tot entre
objectes.
El tot sanomena composat i les parts components
Cont
Ruta Segment
* *
* Usa 1..*
Men Recepta
A1
A * * B
* * B1 B2
* C * C1 C2 C3
A2 A3 A4
Composici
- La multiplicitat del cap compost pot ser com a mxim 1 (com a mxim un
composat posseeix un component)
Cont
Venda LniadeVenda
1 0..*
Cont
Catleg Especificaci
1..* de Producte
0..1
48
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.
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
* T *
Empleat
nom
/nombre_empleats
Associaci derivada
* Est situat a 1
Departament Ciutat
1 1
* *
Empleat
T /Treballa a
49
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
50
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 *
*
Ciutat
telfon {changeable} resident ciutat-res
{changeable}
telfon i ciutat-res sn canviables
Congelat (frozen)
Persona Va nixer a 1
*
Ciutat
data-naix {frozen} per-nascuda ciutat-naix
{frozen}
data-naix i ciutat-naix sn congelats
Noms-afegir (addOnly)
Persona Ha residit a
* *
ttol-acad {addOnly} Ciutat
resident ciutat-res
{addOnly}
ttol-acad i ciutat-res sn noms-afegir
Classificaci mltiple
Persona
sexe estat
51
Herncia mltiple
Estudiant
universitat estudis
{disjoint, incomplete} {disjoint, incomplete}
InformUPC
Polgon
nombre_costats
s equivalent a:
Polgon
Problema?
52
En UML:
Docncia_Assignatura
1 1 1
* * *
Classe_Teoria Classe_Probl Classe_Lab
s equivalent a:
Docncia_Assignatura
* * *
Classe_Teoria Classe_Probl Classe_Lab
Exemples
Quina soluci s millor?
Persona_UPC
nom
num-assignatures
sou amb valors nuls
Persona_UPC
nom
tipus
{overlapping, incomplete}
Estudiant Empleat
num-assignatures sou
53
Exemples
Quina soluci s millor?
Persona_UPC
nom
telfon
amb valors nuls
Persona_UPC
nom
tenir_telfon
Persona_amb_telfon
telfon
Exemples
Empleat Projecte
nom: Text codi_proj: Text
proj_emp: Projecte descripcio: Text
Un atribut no pot prendre valors duna de les classes del model conceptual
Empleat *
Projecte
*
nom: Text codi_proj: Text
Treballa a descripcio: Text
54
Bibliografia
En castell:
55
Per qu serveix?
Propietats del Model Conceptual
Col.leccions: conjunts, bosses i seqncies
Navegaci per classes associatives
Generalitzaci / Especialitzaci
Com especificar en OCL
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
Treball
Casament
ttol : String
lloc : String datadInici: Data
data : Data salari : Integer
57
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
Exemples de navegaci:
Empresa
self.director -- director de lempresa -- Persona
self.director.nom -- nom del director -- String
self.empleat -- empleats de lempresa -- set(Persona)
self.empleat.esps -- esposos dels empleats -- set(Persona)
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
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)
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
60
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
61
62
Operaci Resultat
size nombre delements de la col.lecci
count(object) nombre docurrncies de lobjecte
includes(object) cert si lobjecte pertany a la col.lecci
includesAll(collection) cert si els elements del parmetre collection sn a la
col.lecci actual
isEmpty cert si la col.lecci s buida
notEmpty cert si la col.lecci no s buida
sum() suma de tots els elements (els elements shan de poder sumar)
exists(expression) expression s cert per algun element?
forAll(expression) expression s cert per tots els elements?
select(expression) selecciona el subconjunt delements per als quals expression
s cert
reject(expression) elimina el subconjunt delements per als quals expression s cert
union(collection) resultat dunir les dues col.leccions
intersection(collection) resultat de la intersecci
63
Bibliografia
J.Warmer; A.Kleppe
The Object Constraint Language: precise modeling with UML
Addison-Wesley, 1999.
http://www.software.ibm.com/ad/ocl
http://www.rational.com
http://www.omg.org
64
Propsit
Casos ds
Diagrama de Casos ds
Especificaci de Casos ds
Estructuraci de Casos ds
Identificaci de Casos ds
Model
DAnlisi
65
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
Actor1
Cas ds 2 Actorn
Cas ds i
Comunicaci
Especificaci de Casos ds
Dalt nivell: Descripci breu de les accions del cas ds.
67
68
Iniciar Sessi
Acabar Sessi
Responsable
de compres Fixar Preus
Comprar a provedors
Director
comercial
Fer ofertes
Provedor
TPV
Compra de
productes
CAIXER Retornar CLIENT
producte
Iniciar
sessi
supermercat
Compra de
productes
CLIENT
Retornar
Producte
69
Cursos Alternatius
70
Cursos Alternatius
71
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 Client
Compra de productes + Pagar amb tarja
Comptabilitat
Accions dels Actors Resposta del sistema
1. El cas ds comena quan un client arriba
a la caixa amb els productes per comprar.
2. (Passos intermedis exclosos)...
9. El Client escull el tipus de pagament: 10. Enregistra la venda que sacaba de
a. If s en efectiu initiate fer.
Pagar en efectiu
b. If s amb targa initiate
Pagar amb tarja
11. Imprimeix un rebut.
12. El Caixer dna el rebut al client.
13. El client sen va amb els productes comprats
72
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
<<estn>>
Matricular Erasmus Matricular estudiant
Estudiant
Identificaci de casos ds
73
Essencial Real
molt abstracte molt concret
Essencial
Real
Bibliografia
C. Larman
Applying UML and Patterns.
An Introduction to Object-Oriented Analysis and Design.
Prentice Hall, 1998. (Cap. 6)
74
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
75
SISTEMA
76
Objectius:
identificar els esdeveniments i les operacions del sistema
Punt de partida:
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
77
:Caixer :Sistema
iniciVenda(pv )
:venda
entrarProd(venda,prod,quant)
*
fiVenda(venda)
:import
pagament(venda,importPag)
:canvi
78
:Actor :Sistema
esdev1()
iteraci dun sol
esdeveniment esdev2()
*
esdev3()
*
iteraci duna esdev4()
seqncia desdev.
79
Esdeveniments i operacions
Exemple:
SISTEMA
iniciVenda(pv ) :venda
entrarProd(venda,prod,quant)
fiVenda(venda) :import
pagament(venda,importPag): canvi
80
iniciVenda
entrarProd
Lactor client no interacciona *
directament amb el sistema,
noms ho fa el caixer fiVenda
pagament
frontera del
sistema
81
1
Producte
codi
preu
RI textuals: descripci
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
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
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
Responsibilities:
Finalitzar lenregistrament duna venda i mostrar limport a pagar
Exceptions:
Preconditions:
Postconditions:
Responsibilities:
Mostrar el canvi a retornar
Exceptions:
Si importPag < venda.import indicar error
Preconditions:
importPag venda.import
Postconditions:
84
:Caixer :Sistema
:Caixer :Sistema
iniciVenda(pv)
iniciVenda(pv)
:venda
:venda Venda
* entrarProd(venda,prod,quant) dia
entrarProd(prod,quant)
* hora
/import
fiVenda(venda)
fiVenda()
:import
:import
pagament(venda,importPag)
pagament(importPag) VendaEnCurs
:canvi
:canvi
85
Exemple:
LlistatVendes = num-pv + {codi-prod + quantitat}
num-pv = Integer; codi-prod = Integer; quantitat = Integer
ResumVendes(num-pv:Integer) : LlistatVendes
86
Redundncia - Exemple
Cal que les precondicions incloguin la comprovaci de les restriccions del M.Conceptual?
87
Redundncia - Definici
Redundncies possibles:
88
Precondicions:
Persona Idioma
* parla 1..* nom
nom
adrea nm-parlants
AltaPersona(nom,adrea) AltaPersona(nom,adrea)
* ParlaIdioma(nom, idioma)
89
:Caixer :Sistema
Nom: Pagament (venda, importPag): canvi
iniciVenda(pv): venda
Preconditions:
- existeix venda venda
entrarProd(venda, prod, quant)
* - la venda venda ha finalitzat
Bibliografia
C. Larman
Applying UML and Patterns.
An Introduction to Object-Oriented Analysis and Design.
Prentice Hall, 1998. (Cap. 13, 14)
90
Introducci
s dels diagrames destat
Exemples
Accions i condicions duna transici
Estats imbricats
Bibliografia
Model
DAnlisi
91
Objectius:
crear diagrames destat per objectes i casos ds
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 Estat
92
Persona
neixement
estat-civil {disjoint, complete}
Soltera
Soltera Casada Separada Divorciada Vdua
casament
divorci Casada
Separada Vdua
enviudar
Cas ds:
per descriure la seqncia legal en la que els esdeveniments es
poden produir al mn real
93
entrarProd
Introduint
entrarProd Productes
Esperant
Venda
fiVenda
pagamentEnMetl.lic Esperant
Pagament
Autoritzant
gestionaResposta Pagament pagamentAmbTarja
estat inicial
estat
despenjar
lliure actiu
penjar
transici esdeveniment
94
condici
despenjar [abonatVlid]
lliure actiu
/marcarTo
penjar
acci
Estats imbricats
despenjar [abonatVlid]
/marcarTo Actiu
95
Bibliografia
C. Larman
Applying UML and Patterns.
An Introduction to Object-Oriented Analysis and Design.
Prentice Hall, 1998. (Cap. 33)
B. Powel Douglass
Real-Time UML.
Addison-Wesley, 1998.
96
Pla i
Construcci Implantaci
Elaboraci
97
Etapa de construcci
Cicle de Cicle de
Desenvolupament 1 Desenvolupament 2 ...
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
7. Definir Diagrames
dEstat
99
Cas ds C
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.
:Caixer :Sistema
iniciVenda(pv)
:venda
entrarProd(venda,prod,quant)
*
fiVenda(venda)
:import
ferPagament
100
:Caixer :Sistema
iniciVenda(pv): venda
Interacci comuna a
tot tipus de pagament * entrarProd(venda,prod,quant)
:Caixer :Sistema
pagament(venda,importPag)
:canvi
tractarResp.Tarja(resposta)
afegeixAprovaci(resposta)
101
Bibliografia
C. Larman
Applying UML and Patterns.
An Introduction to Object-Oriented Analysis and Design.
Prentice Hall, 1998. (Cap. 13, 32)
102
103
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.
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
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, especifiqueu-
les 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.
autA2 F
com12
loc1
A B C E
I
D
H
G
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
Els autors, 2000; Edicions UPC, 2000.
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):
Un cop fet el model, mostreu-ne la instanciaci completa amb les dades segents:
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:
Un cop fet el diagrama, mostreu-ne la instanciaci completa amb les dades segents:
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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.
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.
110
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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.
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".
112
Els autors, 2000; Edicions UPC, 2000.
(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.
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.
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 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.
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.
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.
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 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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
Per exemple, en Joan est abonat a la companyia, t el document d'identitat 111 i viu al
C/Escudellers.
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.
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.
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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 (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
indiqueu-los ben clarament.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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). 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.
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-3-
1999 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
Els autors, 2000; Edicions UPC, 2000.
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-3-
1999.
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.
Feu el Model Conceptual daquest sistema amb la notaci UML. Expresseu grficament
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
adients i indiqueu-los ben clarament.
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 1er-
2a) 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-2-
1999. En canvi, la finca del carrer Ma s posseda integrament per la Maria.
122
Els autors, 2000; Edicions UPC, 2000.
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-4-
1999, 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.
Feu el Model Conceptual daquest sistema amb la notaci UML. Expresseu grficament
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.
Si en fer aquest exercici us cal ms informaci, feu els supsits que creieu ms adients i
indiqueu-los ben clarament.
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.
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
Els autors, 2000; Edicions UPC, 2000.
Vendes, va fer de Venedor (des del 6-10-1999) i de Director General de Vendes (des del 10-10-
1999).
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.
Per exemple, lempleat amb dni 111 fou rebutjat pel departament de Mrketing i, per tant, no shi
podr assignar mai.
Feu el Model Conceptual daquest sistema amb la notaci UML. Expresseu grficament
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
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.
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.
124
Els autors, 2000; Edicions UPC, 2000.
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.
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). 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 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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
Feu el Model Conceptual daquest sistema amb la notaci UML. Expresseu grficament
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
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.
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.
Pel viatge 25, en Joan ha contractat una assegurana que t el nmero 111 de la mutua Segur.
126
Els autors, 2000; Edicions UPC, 2000.
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-10-
199 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.
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). 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.
127
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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.
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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.
Us demanem que feu els models segents (tots ells mitjanant la notaci UML):
130
Els autors, 2000; Edicions UPC, 2000.
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.
7. 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.
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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.
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.
FRACCI-HORRIA
dia
hora
ASSIGNATURA 3 GRUP
codi 1..* fa-classe nmero
1
nom
HORARI
{incomplete}
HOR-COMPLET
aula
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.
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.. 2 (origen)
POBLACI
CARRETERA
nom-p fan-tram
1..*
habitants codi-c
1.. 2 (dest)
TRAM
de-la RUTA
distncia
* * codi-ruta
durada
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.
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.
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 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
Els autors, 2000; Edicions UPC, 2000.
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.
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.
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.
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.
Us demanem que feu els models segents (tots ells mitjanant la notaci UML):
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
Els autors, 2000; Edicions UPC, 2000.
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:
TEMPORAL INDEFINIT
A
data-fi-lloguer 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.
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.
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.
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
Els autors, 2000; Edicions UPC, 2000.
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:
CONTROL
JORNADA 1 amb 1..*
num-cont
Num-jorn * lloc
Pob-inici
* Pob-fi
sinscriu
passa-per
PERSONA *
*
dni PARTICIPACI CONTROL PARTI CIPANT
nom-p
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
138
Els autors, 2000; Edicions UPC, 2000.
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 GRUP ESTUDIANT
1 t * * es-matric *
codi-assig nmero dni
nom capacitat nom
crdits telfon
MATRCULA
PARCIAL * {disjoint, complete}
tipus
num-parcial correspon
*
NOTA PARCIAL AVALUACI AVALUACI
CONTINUADA NO CONTINUADA
nota
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: alta-
grups-duna-assignatura, matrcula-estudiant, assignaci-notes-parcials, consulta-
destudiants-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
necessria per a portar a terme aquesta funcionalitat requereixi ms dun esdeveniment.
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
Els autors, 2000; Edicions UPC, 2000.
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
necessria per a portar a terme aquesta funcionalitat requereixi ms dun esdeveniment.
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
necessria per a portar a terme aquesta funcionalitat requereixi ms dun esdeveniment.
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
Els autors, 2000; Edicions UPC, 2000.
- 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.
Grup
Assignatura 1 1..*
* amb num-grup
nom-a capacitat-mx.
imparteix
*
es-matricula
*
Titulaci 1
nom-t pertany Alumne
1..*
facultat * 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.
141
Els autors, 2000; Edicions UPC, 2000.
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 Sessi Ponncia
sigles t nom-sessi es-presenta codi
any * durada 1 ttol
1 0..4
preu
* *
assisteix-a
s-autor
1..*
Inscripci Persona
*
tipus {disjoint, complete} nom
143