Uml

Problemes
de modelització
amb UML
Programació orientada a objectes
David Masip Rodo
Elena Planas Hortal (coordinadors)
Jordi Brínquez Jiménez
Juanma Dodero Beardo
Marta Tarrés Puertas
PID_00145181
© FUOC • PID_00145181 3 Problemes de modelització amb UML
Índex
Introducció ............................................................................................ 5
Part I. El procés de modelització..................................................... 7
Part II. Problemes resolts .................................................................. 11
Part III. Problemes proposats (sense solució) .............................. 72

Introducció
La motivació principal d’aquest material didàctic sorgeix de la necessitat de

crear un recopilatori de problemes que serveixin a l’estudiant per a adquirir
la pràctica necessària a l’hora de superar les assignatures de Disseny i
programació orientada a objectes.
Aquests materials s’estructuren de la manera següent:
• En la primera secció, introduïm la metodologia elemental de

modelització que seguirem al llarg del material, amb un exemple pràctic
d’aplicació.
• Seguint aquesta metodologia, la segona secció mostra 21 problemes de

dificultat creixent amb les solucions corresponents.
• Finalment, la tercera secció conté una llista de 22 problemes sense solució

que poden servir per a practicar la metodologia apresa.
Part I. El procés de modelització
Per a crear un diagrama de classes a partir de la descripció d’un problema

real, és necessari seguir uns passos que permetin modelitzar la realitat de la
millor manera possible, amb l’objectiu de reflectir fidelment els detalls
importants del problema i permetre futures ampliacions.
El procés per a crear un model de classes, malgrat que no és matemàtic, es

pot esquematitzar en les activitats següents:
1) Identificació de les classes
Consisteix a seleccionar els substantius i les frases nominals que conformaran

el nostre model de classes i eliminar les que siguin redundants, les que siguin
irrellevants per al problema o les que facin referència a conceptes inconcrets.
El resultat d’aquesta fase és obtenir una llista de classes que conformaran el

nostre model de dades.
2) Creació del model de dades
Consisteix a establir les diferents relacions entre classes que es poden inferir
a partir de l’enunciat del problema. Per crear el model de dades, en la
majoria de problemes no podrem abordar el procés de creació de cop, sinó
que haurem d’anar creant petits models que constitueixin parts funcionals
del model complet i, posteriorment, ajuntar-les fins a completar el procés, i
relacionar així les classes identificades en el primer pas.
3) Inclusió d’atributs i mètodes
Una vegada creat el model de dades, hem d’afegir els atributs i mètodes que
dotaran de significat el nostre diagrama. Els atributs que hem d’incloure són
els que apareixen en el problema que volem resoldre, mentre que els
mètodes corresponen a les accions que necessita la nostra aplicació per a
poder dur a terme les funcionalitats requerides (no solament la funcionalitat
principal sinó també totes les altres sobre les quals es basen aquestes
funcionalitats requerides).
4) Inclusió de la cardinalitat i navegabilitat de les relacions
Finalment, completarem el diagrama indicant el nombre màxim i mínim

d’instàncies que poden participar en cada relació (cardinalitat), i també quines
classes tenen constància de l’existència de les altres classes (navegabilitat).
Per a millorar el diagrama de classes obtingut, és aconsellable aplicar aquest

algoritme iterativament, i assegurar-nos així que no oblidem cap classe,
atribut o mètode.
Exemple d’aplicació
L’Associació d’Antics Alumnes de la UOC ens ha demanat si els podem

ajudar a confeccionar un programa que els permeti gestionar els seus
associats, els esdeveniments i els altres elements relacionats.
Els associats es poden dividir en membres numeraris i en membres de la junta

directiva, que és elegida per votació en una assemblea general cada quatre
anys. L’única diferència entre ells és que els membres de la junta directiva són
convocats a les reunions de junta i els altres membres no, però la resta
d’activitats que s’hi fan estan obertes a tots els membres de l’associació.
La convocatòria d’un esdeveniment es fa per correu electrònic a tots els

membres actius en el moment de la tramesa, que reben un enllaç per a
acceptar la participació. En tots els esdeveniments, l’acceptació dels
assistents es fa per ordre d’arribada ja que es pot donar el cas que el nombre
d’assistents sigui limitat, com en les conferències.
En la convocatòria, també apareix informació sobre el lloc, que sovint és el

mateix, per la qual cosa ens han dit que volen emmagatzemar les dades per a
usos futurs.
Solució:
• Membre (o membre numerari) (Member)

• Membre de la junta directiva (BoardMember)
• Esdeveniment (Event)
• Conferència (Conference)
• Reunió de la junta directiva (BoardMeeting)
• Localització (Location)
Addicionalment, s’hi ha afegit la classe Persona (Person) per a poder

identificar també els conferenciants, ja que es pot donar el cas que no siguin
membres de l’associació.
Per a crear el model de dades, s’ha detectat l’existència d’una jerarquia

d’herència la superclasse de la qual és l’esdeveniment i, segons la descripció
del problema, té únicament dues subclasses, que són les conferències i les
reunions de la junta directiva. En aquest problema, s’ha descartat la inclusió

d’una classe que representi els esdeveniments amb restriccions en el nombre
d’assistents. En cas que s’ampliï la tipologia d’esdeveniments, s’hauria de
considerar el punt esmentat.
Event
Conference BoardMeeting
Alhora, hi ha la jerarquia següent entre els membres de l’associació:
Person
Member
BoardMember
A més, tenim les classes Localització (Location) i Associació (AAUOC), que es

relacionen amb la resta de classes de la manera següent:
AAUOC
Person
Location
Event
Member
BoardMember
Una vegada creat el model de dades, completem les classes amb els seus
atributs i els mètodes més rellevants (queden fora d’aquest diagrama els
mètodes getters i setters, i també els mètodes constructors de cada classe).
L’associació necessita els mètodes per a

AAUOC
afegir nous esdeveniments, persones i
localitzacions al sistema (mètodes newX de newLocation(l : Location) : void
newEvent(e : Event) : void
newPerson(p : Person) : void
la classe AAUOC), i també un mètode per a informEvent(e : Event) : void
register(m : Member,e : Event) : void
informar els membres de la convocatòria
d’un esdeveniment (mètode informEvent).
Person
Alhora, es diu que els usuaris necessiten Location
name : String
description : String attendsTo
confirmar l’assistència als esdeveniments address : String
(mètode register, que ha d’emmagatzemar Event

Member
els assistents per ordre i controlar-ne el date : Date
description : String e-mail : String
isLocated In
nombre màxim si és necessari). assign(l : Location) : void
Conference BoardMeeting BoardMember
4) Inclusió de la cardinalitat i max_attendees : Integer
navegabilitat de les relacions

attendsTo
attendsTo
En el diagrama següent, s’han eliminat

els mètodes i s’han inclòs les
navegabilitats (en aquest cas, totes són bidireccionals, ja que no se’ns ha
comunicat cap mena de relació o accés a la informació d’una classe a l’altra) i
les cardinalitats de les relacions esmentades.
AAUOC
0..*
Person
0..*
0..*
Location attendsTo
0..* 0..* 0..*

Event
Member
1 0..*
isLocatedIn
BoardMember
0..*
0..* attendsTo 0..*
attendsTo
Part II. Problemes resolts
Problema 1: aplicació de professorat
La UOC està fent una revisió de les seves aplicacions per a gestionar els
professors, perquè s’han adonat que tenen certes necessitats que quan es van
crear no es van tenir en compte.
Al seu moment, van emprar el concepte professor com un terme genèric, però
s’han adonat que hi ha tipologies de professor diferents (professors interns i
associats externs), amb unes necessitats comunes i altres que depenen de cada
tipologia (per exemple, es necessita emmagatzemar l’empresa en què treballa
un professor associat extern), que actualment ja estan implementades.
Per exemple, els professors interns tenen un sou fix i els associats externs
tenen un sou dependent del nombre d’alumnes i crèdits en què fan classe,
però tots tenen un conjunt d’aules associat.
Es demana el diagrama UML que inclogui les classes, relacions, atributs i

mètodes que participen en el disseny de les funcionalitats requerides.
Solució:
• Professor intern (InternalTeacher)

• Professor associat extern (ExternalTeacher)
• Empresa (Company)
• Classe (Class)
Per a crear el model de dades, s’ha detectat l’existència d’una jerarquia

d’herència la superclasse de la qual és el concepte de professor i, segons el
problema, té únicament dues subclasses, que són els professors interns i els
professors associats externs.
Teacher
InternalTeacher ExternalTeacher
A part, tenim les classes Empresa (Company) i Classe (Class), que es

relacionen amb la resta de classes de la manera següent:
UOC
Company
Class
Teacher
Una vegada creat el model de dades, hem de completar les classes amb els
seus atributs i els mètodes més rellevants (queden fora d’aquest diagrama els
mètodes getters i setters, i també els mètodes constructors de cada classe).
La UOC necessita els mètodes per a afegir nous professors, classes i empreses
al sistema (els mètodes newX de la classe UOC), i també un mètode per a
consultar el sou d’un professor (el mètode getSalary).
UOC
newClass(c : Class) : void

newCompany(c : Company) : void
newTeacher(t : Teacher) : void
getSalary(t : Teacher) : Double
Class
Teacher Company
name : String name : String
getSalary() : Double
Class Teacher
Company
baseSalary : Double variableSalary : Double

Teachers
getSalary() : Double getSalary() : Double
En el diagrama següent, s’han eliminat els mètodes i s’han inclòs les

navegabilitats (en aquest cas se n’hi ha inclòs una d’unidireccional, ja que es
demana que el professor extern sàpiga en quina empresa treballa, però no

s’ha demanat la informació contrària) i les cardinalitats de les relacions
esmentades.
UOC
0..*
0..*
0..* Company
Class
Teacher
0..* 0..*
0..*
Problema 2: UOCphone
L’empresa de telefonia mòbil UOCphone vol llançar una campanya de fide-

lització de clients amb un sistema de punts. Per fer-ho, vol posar en marxa
dos sistemes d’acumulació de punts per als clients:
• El primer sistema és per als clients que tenen contracte, dels quals es
coneix un número de client.
• El segon sistema és per als clients en modalitat de prepagament, als quals

l’empresa no coneix.
En el primer cas, els punts s’associen a l’individu, de manera que, si té més

d’un mòbil contractat, els punts provinents de tots els seus mòbils
s’acumulen en un sol compte.
Cada línia de telefonia mòbil amb contracte té una modalitat de tarifació

establerta (matí o tarda) que es pot canviar. En el sistema de prepagament,
com que no es coneix el client, els punts s’associen al número de telèfon del
mòbil de prepagament.
El sistema ha de registrar totes les trucades de sortida, i ha d’incloure l’hora

d’inici i final, ja que més endavant potser es volen comprovar els punts
atorgats segons la durada i franja horària de les trucades.
Les línies de prepagament han de rebre un punt per minut. Les línies de
contracte han de rebre 1,5 punts per minut de les trucades fetes en la franja
horària coincident amb la modalitat de tarifació contractada (el “matí” va de
les 8:00 fins a les 15:00 i la “tarda”, de les 15:00 fins a les 20:00), i un punt
per minut de les trucades fetes fora d’aquesta franja. Tots els punts s’han
d’acumular immediatament, després d’acabar cada trucada.
Es demana el diagrama UML que inclogui les classes, associacions, atributs i

mètodes que participen en el disseny de la funcionalitat d’actualització de
punts després de cada trucada.
Solució:
• Línia de telefonia mòbil (Line)

• Línia de contracte (ContractLine)
• Línia prepagament (PrepayLine)
• Client (ClientAccount)
• Trucada sortint (OutCall)
Per a classificar les modalitats de tarifació per franja horària, no és necessari

definir cap classe, ja que no hi ha cap atribut ni operació per a atribuir als
possibles objectes d’aquest tipus. Per això s’han modelitzat amb un tipus
enumerat RateFrame.
Les classes ContractLine i PrepayLine representen les dues situacions possibles.

Totes dues coincideixen en el fet d’estar associades a un número de telèfon,
que es representa mitjançant l’atribut number en la superclasse abstracta Line.
Els objectes de tipus ContractLine estan associats a un client, que és qui ha de
mantenir el compte de punts associat.
D’altra banda, per a decidir més endavant els punts que s’han d’atorgar,
s’associa a cada línia l’històric de les seves trucades de sortida, per mitjà de
l’associació que uneix Line i OutCall.
En la solució, no s’ha dibuixat la classe principal PhoneCompany, que, en

aquest cas, i per al que demana l’enunciat, només necessitaria una relació
d’agregació que la unís amb Line, de cardinalitat *. Tanmateix, si se sol·liciten
funcionalitats addicionals, pot ser que facin falta agregacions entre Phone-
Company i ClientAccount, o fins i tot amb OutCall o alguna possible superclas-
se abstracta Call d’aquesta darrera.
Els clients s’han modelitzat amb la classe ClientAccount, que aglutina

solament els atributs que ens interessen per al nostre problema. Com que els
punts de tots els ContractLine d’un mateix client s’han d’agregar, per a fer-ho
s’utilitza un atribut credits en la classe ClientAccount.
Cada PrepayLine, en canvi, té un compte de punts independent de les altres

línies, encara que aquestes línies siguin de la mateixa persona física i, per
tant, es representen mitjançant l’atribut credits del PrepayLine.
Les trucades de telèfon se simulen amb el mètode makeCall(startDate, endDa-

te) de Line. Després de la trucada, s’actualitza l’historial de trucades creant
una instància nova d’OutCall i s’actualitzen els punts cridant el mètode
privat updateCredits(credits: int) de Line.
El mètode Line::updateCredits és privat perquè només es crida des de

makeCall() per a sumar els punts acumulats. A ContractLine la crida a update-
Credits() actua delegant en updateCredits(credits: int) de ClientAccount per a
acumular els punts en el lloc adequat. En canvi, una PrepayLine suma
directament els punts a l’atribut credits.
Cada vegada que es fa una trucada s’ha de crear una instància d’OutCall i
cridar Line::updateCredits(). Per tant, el sentit de navegació de les associacions
és Line Æ OutCall i ContractLine Æ ClientAccount. Les cardinalitats s’indiquen
en el diagrama, segons es dedueix de l’enunciat.
Diagrama de classes complet
<<type>>
RateFrame
Line makes OutCall
morning : Integer 1 0..*
ClientAccount evening : Integer number : String start : Date
end : Date
id : String makeCall(start : Date,end : Date) : void
credits : Integer updateCredits() : void
updateCredits() : void uses
1
holds ContractLine PrepayLine
1..*
contractRateFrame : RateFrame credits : Integer
Problema 3: gestió de personal
Una universitat necessita una aplicació capaç de gestionar el seu personal. Hi

ha dues categories de personal: docent i administratiu. El personal docent
s’identifica a partir d’un identificador de registre, té un nom, i es caracteritza
pel fet de pertànyer a un departament. Per exemple, el docent 12345-078
pertany al Departament de Psicologia de l’Educació. Hi pot haver diferents
professors per departament, però un professor no pot pertànyer a més d’un
departament alhora.
El personal administratiu també s’identifica a partir d’un identificador de

registre, i es caracteritza pel fet de pertànyer a una secció i ocupar un càrrec.
Per exemple, l’administratiu 23456-891 pertany a la secció de biblioteca i
ocupa el càrrec de bibliotecari. Una mateixa persona no pot ser alhora
personal docent i administratiu de la universitat.
Dins de la gestió de la universitat es volen fer diverses tasques, que inclouen

generar les nòmines (una llista amb el nom i el sou mensual) del personal,
que després es podran imprimir. Per a calcular la nòmina, s’ha de tenir en
compte que els docents cobren una quantitat base fixa més una altra quanti-
tat segons el nombre d’hores de classe que imparteixen (15 €/hora); els
administratius cobren una quantitat base fixa (diferent de la dels docents)
més uns increments per antiguitat (40 € per cada tres anys). Si l’empleat no
és docent ni administratiu en algun període de temps, no ha d’aparèixer en
la nòmina.
Es demana el diagrama UML que inclogui les classes, associacions, atributs i

mètodes que participen en el disseny de la funcionalitat de generació de la
nòmina d’un empleat qualsevol.
Solució:
• Docent (Docent)
• Administratiu (Administrative)
• Personal / Empleat (Employee)
• Nòmina (Payroll)
• Universitat (University): classe principal
Com que una mateixa persona no pot ser alhora docent i administrativa,
hem utilitzat una relació d’herència i hem afegit la classe abstracta Personnel-
Role per classificar el personal en un dels dos tipus de rol, segons el model
següent:
1 1..* 1 0..* Payroll

University Employee
PersonnelRole
1
Docent Administrative
En aquest model, un empleat de la universitat és una instància d’Employee.

L’empleat és donat d’alta com a docent o com a administratiu.
D’altra banda, la relació entre cada Employee i la seva nòmina s’ha modelitzat
amb una associació. La classe Payroll emmagatzema instàncies de les nòmines
calculades per als empleats, una per cada mes i empleat. La relació d’empleats
de la universitat es modelitza amb l’agregació entre University i Employee.
Sobre el model anterior, completem els atributs i mètodes necessaris per a

l’operació makePayroll(), la responsabilitat de la qual atribuïm a la classe Emplo-
yee.
L’atribut identificador d’un empleat l’assignem a la classe Employee.
El càlcul de la nòmina es delega en el mètode abstracte getSalary de la classe

PersonnelRole. Gràcies al polimorfisme, quan volem calcular la nòmina d’un
empleat per arxivar-la a Payroll, es fa una crida al mètode getSalary, que sap
com ha de calcular la nòmina segons el tipus d’empleat. Les especificitats del
càlcul de sou base i complements variables de la nòmina també poden
quedar ocultes en un parell de mètodes, getBaseSalary i getVariableSalary, en
els quals es basi el mètode getSalary.
La generació de la nòmina ha d’imprimir l’identificador de l’empleat, el nom,

el sou i el mes a què correspon. Això es fa en el mètode print() de la classe Pay-
roll. En aquesta classe, cal guardar com a mínim dos atributs: el sou (salary) i el
mes (month) de la nòmina. Seguint el principi d’encapsulació, les dades
necessàries per a calcular el sou segons el tipus d’empleat han de quedar
ocultes en les subclasses de PersonnelRole i ser conegudes per l’Employee.
La nòmina d’un empleat es pot obtenir navegant a partir de l’associació Em-

ployee-Payroll. Com que un empleat té diverses nòmines (una per mes), per a
localitzar la nòmina d’un mes determinat fa falta filtrar, entre totes les
instàncies de Payroll associades a l’empleat, la corresponent al mes.
La navegabilitat entre les classes Employee i PersonnelRole permet conèixer el

tipus d’empleat, per a poder-ne calcular la nòmina.
1 1..* 1 0..* Payroll

University Employee
salary : float
name : String id : String
month : date
makePayrolls() makePayroll()
print()
PersonnelRole
1
getSalary()
Docent Administrative
getBaseSalary() getBaseSalary()
getVariableSalary() getVariableSalary()
Problema 4: nombres complexos
Una aplicació de càlcul matemàtic necessita utilitzar nombres complexos per

a poder fer càlculs amb punts en el pla. Els nombres complexos han de
proporcionar les operacions algebraiques bàsiques de suma, producte i càlcul
del conjugat. A més, els nombres complexos s’han de poder imprimir tant en
notació cartesiana com en notació polar.
L’aplicació que es dissenyi per a tractar amb nombres complexos ha de poder

interoperar amb una classe Point que ja estigui definida, que guarda les
coordenades d’un punt en el pla. Les operacions algebraiques de suma i
producte s’han de poder fer entre nombres complexos, entre nombres
complexos i punts, i entre nombres reals i nombres complexos.
Es demana dissenyar la classe Complex, que representi un nombre complex,

incloent-hi els seus atributs i mètodes necessaris per a implementar les
operacions desitjades.
Solució:
• Nombre complex (Complex)

• Punt (Point)
La classe Complex es relaciona amb la classe Point mitjançant una relació d’ús.
Com que un nombre complex és el mateix independentment de la notació

en què s’expressa, unicament guardem atributs per a la part real i imaginària.
Tanmateix, es proporcionen mètodes accessors (mòdul i argument) per a
conèixer-ne la representació en coordenades polars.
Els mètodes de suma i producte han d’estar sobrecarregats per a permetre

que un complex sumi/multipliqui per un altre complex, un nombre real o
un Point.
L’única relació identificada és la dependència entre Complex i Point, ja que a

Complex apareixen operacions amb paràmetres de tipus Point. Es podria
haver definit una associació 1:1 entre totes dues classes per a indicar que
representen una mateixa cosa.
Complex
real : double
imag : double Point
x : double
add(other : Complex) : Complex y : double
add(r : double) : void
add(p : Point) : void
argument() : double
conjugate() : Complex
modulus() : double
printCartesian() : String
printPolar() : String
Problema 5: eina educativa CAD
Se’ns ha encomanat dissenyar una eina CAD, adreçada a infants d’educació

primària, que permeti modelitzar figures geomètriques. En concret, cal
disposar d’un prototip que permeti treballar amb figures i calcular l’àrea
d’una llista de figures. Les figures que s’han de representar en aquest prototip
inicial són cercles, triangles, rectangles i quadrats.
De cada figura cal emmagatzemar les coordenades del centre de la figura.

En el cas del cercle, es necessita la informació addicional del radi. En el
cas del rectangle, les dimensions d’ample i de llarg. I en el cas del quadrat,
les dimensions d’amplada i de llargada coincideixen. En el cas del
triangle, es necessita emmagatzemar les dimensions de la base i l’altura de
la figura.

Solució:
• Figura (Figure)
• Cercle (Circle)
• Rectangle (Rectangle)
• Triangle (Triangle)
• Quadrat (Square)
Es detecta una jerarquia d’herència, la superclasse de la qual és l’element

Figure. Les classes Circle, Rectangle i Triangle hereten d’aquesta superclasse. Al
seu torn, Rectangle especialitza Square.
El mètode que permet calcular l’àrea d’una figura és abstracte en la classe

Figure, i és defineix en les classes Circle, Rectangle i Triangle. El mètode del
càlcul de l’àrea per a la classe Square s’hereta de la classe Rectangle.
4) Inclusió de la cardinalitat i la navegabilitat de les relacions
En aquest cas, no hi ha cardinalitat ni navegabilitat perquè només s’ha

identificat una relació d’herència.
Figure
x : Integer
y : Integer
area() : double
Rectangle
Circle Triangle
width : double
radius : double base : double
length : double
height : double
area() : double
area() : double area() : double
Square
size : double
Problema 6: escola La Virtual
L’escola La Virtual ens ha encarregat que desenvolupem una ampliació en la

seva aplicació que permeti gestionar uns usuaris nous: els becaris.
Actualment, l’escola disposa de docents i estudiants. Un docent és una
persona que imparteix docència als estudiants d’una classe. Un estudiant és
qui rep la docència. Recentment s’ha incorporat, a més, la figura del becari,
que és un estudiant que ajuda un únic professor en una classe.
S’ha de remarcar també que, normalment, els estudiants tenen uns drets i
uns recursos assignats, i els docents tenen uns drets i uns recursos més
amplis. Hi ha espais de l’escola on un docent sí que té accés i un estudiant
no (per exemple, la sala de professors o les reunions de coordinació d’una
assignatura).
Un becari no es considera un docent. Els docents tenen certs privilegis extres

que no estan l’abast dels becaris, com l’accés a la informació sobre
l’expedient dels estudiants o la utilització de certs recursos.

mètodes que participen en el disseny de la funcionalitat requerida.
Solució:
• Docent (Instructor)
• Classe (Class)
• Estudiant (Student)
• Becari (Assistant)
Hi ha una jerarquia d’herència, ja que el becari hereta de l’estudiant.
L’Assistant disposa d’un atribut intern de tipus Instructor que proporciona

totes les funcionalitats que necessita com a becari.
No s’han restringit les navegabilitats, ja que el problema no especifica cap

restricció. Les cardinalitats es mostren en el diagrama final.
Instructor Class Student

1 1 1..* 1..*
Assistant
-in : Instructor
Problema 7: OilCompany
La companyia petroliera OilCompany ens ha encarregat que desenvolupem

una aplicació per a gestionar els combustibles. Després d’una anàlisi
exhaustiva dels requeriments del projecte, hem arribat a les conclusions
següents:
1) L’àmbit del projecte és la gestió dels diferents tipus de gasolina que hi ha,
però, de moment, la nostra responsabilitat es limita a calcular els beneficis
que s’obtenen amb la venda de productes refinats.
2) La mesura tècnica i financera del petroli és el barril. Un barril és un

contenidor que pot tenir diferents capacitats mesurades en galons. Una altra
mesura petroliera important és l’índex d’octà, que permet avaluar el
rendiment del combustible.
3) L’empresa OilCompany compra barrils de petroli en brut a un preu

determinat, depenent de la borsa, dels conflictes internacionals, etc.
4) Aquesta empresa fa bàsicament dos processos de refinament, que donen

com a resultat els diferents tipus de carburants. Els costos per barril d’aquests
dos processos són els següents:
• Per a gasolines: (índex_d’octà * galons) / ( 2 * (galons – 1))

• Per a gasoils: (índex_d’octà * galons) / 10
5) El preu de venda per galó del producte acabat (gasolina o gasoil) està
estipulat pel govern, i l’empresa l’ha de respectar. Cada tipus de producte
acabat té un preu de venda.
6) El benefici de l’empresa és, evidentment, la diferència entre el preu de

venda i el que costa a l’empresa el producte refinat.
7) No es descarta, en un futur pròxim, que s’hi afegeixin noves tipologies de

producte i, per tant, s’ha de dissenyar l’aplicació pensant en això.

Solució:
OilCompany
• Gasolina (Petrol)
• Gasoil (DieselOil)
La classe OilProduct és una classe abstracta obtinguda per generalització de les

classes Petrol i DieselOil.
Hi ha una relació d’agregació entre OilCompany i els seus productes

OilProduct.
La classe abstracta OilProduct conté els atributs comuns de Gasolina i Gasoil.

Aquesta mateixa classe conté els mètodes necessaris per a calcular els
beneficis (computeProfits) i per a calcular el cost per barril del procés de
refinament (computeCost). Aquest darrer mètode és abstracte en la classe Oil-
Product i es defineix en les seves subclasses.
La classe principal OilCompany gestiona els productes i el còmput dels

beneficis.
No s’han restringit les navegabilitats, ja que el problema no especifica cap

restricció. Les cardinalitats es mostren en el diagrama final.
OilProduct
-id : Integer
-gallon : Integer
-octane : Integer
-buyCost : Integer
OilCompany
1 1..* computeProfits() : float
name : String computeCost() : float
+addProduct(op : OilProduct) : void

+computeProfits() : Float
Petrol
DieselOil
-saleCost : Integer
-saleCost : Integer
+computeCost() : Float
+computeCost() : Float
Problema 8: gestió d’una consultoria
Una empresa de consultoria està pensant a crear una nova aplicació per a
gestionar els empleats, els clients i els projectes que fan per a aquests clients.
Cada client té associat un gerent, que és l’empleat encarregat de gestionar-hi
totes les accions, i també la venda i el seguiment dels projectes en curs.
En general, qualsevol projecte que es fa a l’empresa utilitza unes eines (de

vegades no en fa servir cap). Aquestes eines poden ser comercials (amb la
qual cosa tenen un cost per llicència), de llicència gratuïta (amb un cost base
molt inferior a les eines comercials) o desenvolupades per la mateixa
consultoria.
Les eines desenvolupades tenen, per a cada empleat desenvolupador, un

nombre d’hores de dedicació; per tant, el cost que tenen és la suma dels cos-
tos de cada empleat involucrat en el desenvolupament.
A part dels costos atribuïbles a les eines, en els projectes treballen persones
que utilitzen les eines o bé fan altres tasques. Per a cadascuna de les persones
involucrades, es vol saber el rol que han desenvolupat en cada projecte (es
pot desenvolupar més d’un rol en el mateix projecte) i les hores emprades.

mètodes que participen en el disseny de la funcionalitat descrita.
Solució:
• Empleat (gerent i/o desenvolupador) (Employee)

• Client (Client)
• Projecte (Project)
• Eina (Tool)
• Eina Comercial (Comercial)
• Eina Gratuïta (Free)
• Eina Desenvolupada (Development)
• Rol (Role)
Addicionalment, hi hem afegit la classe Empresa (Company) perquè puguem

partir d’un punt d’interrelació de totes les entitats.
Per crear el model de dades, s’ha detectat l’existència d’una jerarquia

d’herència, en què Tool és la superclasse i els diferents tipus d’eines
(Comercial, Free i Developement) corresponen a les seves subclasses.
Tool
name : String
Comercial Free Development
price : int basePrice : int
Després, hi hem afegit els conceptes de client, projecte i empleat, i també les
eines (per simplificar-ho, hem usat la superclasse) i la relació que modelitza
els gestors de cada client.
Company
Employee
Client
Project Tools
Uses
Manages
Finalment, cal afegir al diagrama els rols que desenvolupen els empleats en
cada projecte (que ha d’incloure les hores dedicades) i la dedicació dels de-
senvolupadors a crear eines pròpies. Per representar aquesta informació,
utilitzem dues classes associatives (vegeu el diagrama complet).
Com a atributs, hi hem d’incloure el nom dels clients i empleats, i també les
eines que s’han de fer servir en un projecte i el preu que tenen.
En principi, de l’enunciat no se’n pot desprendre res més, però s’hi poden
arribar a afegir molts més atributs i mètodes a mesura que vegem que són
necessaris per al desenvolupament.
Per a definir la cardinalitat i la navegabilitat de les relacions, hem d’analitzar

cadascuna de les relacions i veure, al costat de l’enunciat, quins són els
valors més apropiats.
Manages
Company
0..* 0..*
Client
name : String
0..* 1
1
Employee
1..* Project
name : String
description : String
0..* 0..* euro_hour : int
0..*
0..*
Tool Role
name : String description : String

TimeDedication hours : int Developer
hours : int
0..*
Comercial Free Development
0..*
price : int basePrice : int
Problema 9: vehicles MoveFast
L’empresa de lloguer de vehicles MoveFast ens ha demanat si li podem crear

un programa per a gestionar-ne la flota, ja que fins ara tenien un programa
que únicament els permetia gestionar els cotxes; i ara volen gestionar altres
tipus de vehicles dins del seu procés d’expansió.
A banda dels cotxes, volen gestionar motocicletes (de cara al turisme) i

furgonetes i camions (per al món laboral). De cadascun d’aquests vehicles
volen emmagatzemar els trets característics (matrícula, passatgers per als
turismes, tara per als camions, etc.), el tipus de carnet necessari i el preu per
dia.
Hi ha dos tipus de clients: casuals i de leasing. Tots els clients poden llogar
qualsevol tipus de vehicle. La diferència és que els clients casuals paguen
quan retiren el vehicle del local, mentre que als clients de leasing, com que
per la mateixa definició fan un lloguer a llarg termini, els trameten factures a
les empreses mensualment. Per aquest motiu, els clients de leasing han
d’aportar informació sobre la seva empresa (en cas de no tenir fitxa a Move-
Fast) per a poder fer el lloguer (addicionalment, tenen un 10% de descompte
en el càlcul dels lloguers).
Sobre els lloguers, l’empresa vol poder consultar quins cotxes tenen
disponibles en un moment determinat (classificats segons el tipus de cotxe),
i també quins cotxes s’han de lliurar cada dia i quins cotxes s’han de recollir.
Com a operativa general, s’ha de poder donar d’alta o modificar qualsevol

tipus de vehicle, client i empresa, i també s’han de poder imprimir factures
d’un lloguer determinat o la factura d’una empresa corresponent a un mes i
any determinats.

Solució:
• Cotxe (Car)
• Motocicleta (Motorbike)
• Furgoneta (Van)
• Camió (Truck)
• Client Casual (Casual)
• Client de Leasing (Leasing)
• Empresa (Company)
• Lloguer (Rental)
Addicionalment, hi hem afegit la classe MoveFast per poder partir d’un punt
d’interrelació de totes les entitats.
De l’enunciat es dedueix que hi ha una herència en els tipus de vehicle que

ofereix l’empresa de lloguer de cotxes i una altra en els tipus de client. Fixeu-
vos que tant la classe Vehicle com la classe Client són classes abstractes, ja que
no es poden instanciar directament (és a dir, tots els vehicles i clients són
d’un tipus concret).
Els clients de leasing es relacionen mitjançant una associació amb la seva

empresa.
Finalment, només falta relacionar els conceptes Vehicle i Client mitjançant

una classe associativa (Rental), que permet representar el lloguer d’un vehicle
per part d’un client (vegeu el diagrama de classes complet).
A continuació, inclourem els atributs i mètodes que necessiti el model que

acabem de dissenyar.
MoveFast
rent(id : String,plateNumber : String) : void

return(plateNumber : String) : void
print(CompanyId : String,month : int,year : int) : void
print(ClientId : String,plateNumber : String) : void
availlable() : void
inToday() : void
outToday() : void
Rental
initialDay : Date
finalDay : Date Client
Vehicle
print() : String id : String
plateNumber : String Company
name : String
licenseType : String
licenseType : String id : String
priceDay : int
name : String
printReceipt() : String
address : String
printBill() : String
Motorbike Car Van Truck Casual Leasing
sidecar : boolean passangers : int cargo : int TARA : int

wheels : int
No s’hi han inclòs tots els mètodes per no distorsionar el diagrama, però, a
més dels mètodes que hi apareixen, tindrem els mètodes que permetin donar
d’alta i modificar les dades emmagatzemades.
4) Cardinalitat i navegabilitat de les relacions
Finalment, hi hem d’incloure la navegabilitat de les relacions i la seva

cardinalitat. Com que no hi ha límits entre els lloguers que pot fer cada
client, la relació entre els vehicles i els clients té una cardinalitat de molts a
molts.
MoveFast
rent(id : String,plateNumber : String) : void

return(plateNumber : String) : void
print(CompanyId : String,month : int,year : int) : void
print(ClientId : String,plateNumber : String) : void
availlable() : void
inToday() : void
outToday() : void
0..*
Rental
0..*
0..* initialDay : Date
finalDay : Date Client 0..*
Vehicle
print() : String id : String
plateNumber : String Company
name : String
licenseType : String
licenseType : String id : String
priceDay : int
0..* 0..* name : String
printReceipt() : String
address : String
printBill() : String
Motorbike Car Van Truck Casual Leasing

WorksIn
sidecar : boolean passangers : int cargo : int TARA : int 1..*
wheels : int
Problema 10: l’agència de viatges
Una agència de viatges ens demana si els podem informatitzar tota la

informació que tenen sobre els clients i els viatges, tant els que tenen
d’oferta com els que els clients els han comprat.
En primer lloc, els interessa separar els clients segons si són de negocis o si
són particulars, ja que als clients empresarials els facturen els viatges
mensualment; per tant, han d’emmagatzemar-ne les dades bancàries per
poder facturar al final de mes. Per als clients particulars, els interessa saber les
dades estàndard que necessitaríem de qualsevol client: nom i cognoms,
adreça postal i document d’identitat per a les reserves.
Els tipus de serveis que ofereixen en l’agència són molt diversos, des de
bitllets d’avió fins a cotxes de lloguer, passant per nits d’hotel o excursions
organitzades, i també paquets de viatges que estan formats de diferents
elements (per exemple, un paquet de viatge pot estar format d’una excursió i
una nit d’hotel).
Cadascuna de les tipologies de viatges té un nombre determinat de places

disponibles, i quan aquestes places són plenes ja no es poden assignar més
clients, de manera que s’ha de tenir en compte aquest fet quan es fan les
reserves.
L’agència de viatges vol tenir una operativa de funcionament que li permeti

afegir oportunitats noves de viatges, eliminar-les (sempre que no hi hagi cap
reserva confirmada), crear paquets de viatges (amb un percentatge de
descompte sobre el preu total dels seus elements), reservar un tipus de viatge
a un client, confirmar una reserva feta, pagar un viatge i crear la factura per
als clients de negocis.
A més, els interessa poder fer llistes de clients particulars i de clients de

negocis (per enviar ofertes específiques a cadascun dels col·lectius), i també
dels viatges que no hagin venut cap plaça (per no tornar-los a oferir) i de
totes les reserves que estiguin pendents de pagament (per no oblidar-se de
cobrar-ne cap).
Les reserves dels clients tenen tres estats (fetes, confirmades i pagades). En
cas que una reserva estigui feta, però no confirmada, si l’agència de viatges
demana eliminar una oportunitat de viatge, aquesta reserva s’ha d’anul·lar
(esborrar del sistema), però abans s’ha d’enviar un correu electrònic al client
perquè ho sàpiga.

Solució:
• Client (Customer)
• Servei (Service)
• Client Particular (Customer)
• Client de Negocis (BusinessCustomer)
• Bitllet d’Avió (Flight)
• Cotxe de Lloguer (Car)
• Nit d’Hotel (Hotel)
• Excursió Organitzada (Excursion)
• Paquet de Viatges (Packet)
• Reserva (Reservation)
Addicionalment, hi hem afegit la classe Agència de Viatges (TravelAgency) per

poder partir d’un punt d’interrelació de totes les entitats.
De l’enunciat es pot deduir que hi ha una herència en els tipus de servei que
ofereix l’empresa de viatges:
Service
1..*
Packet Car Flight Hotel Excursion
Addicionalment, tenim els clients que es divideixen en “normals” i

“d’empresa”. Com que únicament es fa un tractament especial als clients
d’empresa, s’ha creat una especialització per a aquest tipus de clients (vegeu
el diagrama complet).
Finalment, només cal relacionar aquests dos conceptes (servei i client)

mitjançant una classe associativa (Reservation) que permet guardar
informació sobre les reserves:
TravelAgency
Reservation
state : int
Service Customer
Una vegada definit el model de dades, ja hi podem començar a incloure els

atributs i mètodes necessaris (vegeu el diagrama complet).
No s’han afegit els mètodes al diagrama per no distorsionar-lo, però hi tenim

com a mínim els que ens permeten crear, modificar i esborrar productes i
clients i, finalment, els encarregats d’assignar productes a clients, confirmar i
generar llistes i factures.

cardinalitat. En principi, com que l’enunciat no en diu res, la relació entre el
paquet i el producte ha de ser en aquest sentit i no en l’altre, ja que no es
demana que un producte pugui saber si és dins un paquet comercial o no.
TravelAgency
Reservation
state : int
Trip
Customer BusinessCustomer
price : double
1..*
available : int name : String bancAccount : String
0..* 0..* address : String
DNI : String
Packet Car Flight Hotel Excursion
discount : int initialDate : Date date : Date initialDate : Date date : Date
finalDate : Date from : String finalDate : Date startingPoint : String
category : String to : String location : String
initialLocation : String company : String dobleBed : boolean
finalLocation : String fare : String
Problema 11: MoveFast, ampliació de programari
L’empresa de lloguer de cotxes MoveFast, com que l’aplicació que els vam fer
fa un temps els funciona molt bé, ens ha demanat si els podem ampliar el
programa de manera que els permeti tractar més d’una oficina, ja que estan
en ple creixement i tenen necessitats noves.
A banda de poder gestionar les tipologies de vehicles que ja els permet

l’aplicació, volen emmagatzemar certes dades de les oficines; per exemple, la
localització, l’adreça, el telèfon i el correu electrònic de contacte.
Per a cada centre de treball volen saber quin personal tenen assignat, tant les
persones que hi ha de cara al públic com els conductors que s’encarreguen
de moure els vehicles entre les diferents oficines on els tenen aparcats.
Addicionalment, els conductors poden haver de traslladar cotxes entre
oficines, en cas que un client deixi el cotxe en una oficina diferent.
Tots els empleats tenen un sou base, però els conductors, en cas que hagin
de traslladar vehicles, reben una quantitat fixa addicional per les molèsties
del desplaçament.
De vegades, per a campanyes puntuals, s’han de reassignar alguns vehicles.

Per exemple, a l’estiu, les oficines de llocs turístics tenen més cotxes assignats
que les altres, de manera que és necessari que hi hagi la possibilitat de reas-
signar-los segons convingui.

Solució:
• Vehicle (Vehicle)
• Empleat (Employee)
• Comercial (Salesman)
• Conductor (Driver)
• Oficina (Office)
• Trasllat (VehicleTransfer)
De l’enunciat anterior, en què s’especificava la primera versió de l’aplicació

de lloguer de vehicles (vegeu el problema 9), podem recuperar les tipologies
bàsiques de vehicles amb què treballa l’empresa:
• Cotxe (Car)
• Motocicleta (Motorbike)
• Furgoneta (Van)
• Camió (Truck)
Addicionalment, hi hem afegit la classe MoveFast per poder partir d’un punt
d’interrelació entre totes les entitats.
A partir de la solució de la primera part de l’aplicació de lloguer de cotxes

(vegeu la solució del problema 9), podem considerar que les tipologies de
vehicles segueixen la mateixa taxonomia.
De l’enunciat es pot deduir que hi ha una herència entre els tipus

d’empleats, en què Employee és la superclasse i Driver i Salesman són les
subclasses.
A continuació, s’inclouen les relacions que permeten associar els vehicles

amb l’oficina a la qual estan assignats i el concepte que es produeixi el
trasllat d’un vehicle entre oficines (realitzat únicament pels empleats
conductors).
Office
IsAssignedTo
Employee
Vehicle
VehicleTransfer
Driver
Una vegada definit el model de dades, afegim els atributs i mètodes que
necessiti el model que acabem de dissenyar (vegeu el diagrama complet).
No s’han introduït tots els mètodes per no distorsionar el diagrama, però

hem d’introduir, com a mínim, els mètodes que permetin donar d’alta i
modificar les dades emmagatzemades.
Finalment, hi hem d’incloure la navegabilitat de les relacions (que en aquest

cas sempre és bidireccional, per la qual cosa no es mostra en el diagrama) i la
seva cardinalitat.
MoveFast
reassign(v : Vehicle,origin : Office,destination : Office) : void

getSalary(e : Employee) : double
0..*
Office
IsAssignedTo 1
location : String 0..*
0..* 0..* e-mail : String
phone : String
Employee
Vehicle
0..* id : String
plateNumber : String
0..* name : String
licenseType : String 0..* baseSalary : int
priceDay : int
VehicleTransfer
date : String
Motorbike Car Van Truck Driver Salesman

0..1
sidecar : boolean passangers : int cargo : int TARA : int 1 extraPerTransfer : int
wheels : int
getSalary() : double getSalary() : double
Problema 12: el taller de reparacions
El nostre veí té un petit taller de reparació de cotxes. Com que els cotxes
cada vegada són més complexos, té problemes per saber quina peça ha de
canviar a cada cotxe, ja que models molt semblants fan servir peces
diferents.
Ens ha demanat si li podem crear una aplicació que, donada una descripció
d’una peça (per exemple, el filtre de l’aire) i donat un model i un any (per
exemple, Seat 127, any 1980), li permeti obtenir directament el codi de la
peça corresponent a aquell model per a demanar-la al distribuïdor (i també el
preu i el temps estimat necessari per a canviar-la).
A part, vol oferir un conjunt de reparacions “estàndards” als clients (per

exemple, “canvi de filtres”, que canviaria un conjunt de filtres determinats,
específics per a cada model). De les reparacions emmagatzemades vol saber les
peces que componen la reparació per tornar-les a utilitzar una altra vegada.
Sobre els clients, únicament li fa falta emmagatzemar la matrícula del vehicle,

el nom, el telèfon i l’adreça del propietari. Amb aquestes dades i el tipus de
reparació que necessita (es pot repetir una altra vegada) pot anar treballant.
Per a cada reparació, únicament es poden canviar peces que la reparació

tingui estipulades (adaptades a cada model), i, en cas d’haver de canviar
alguna peça que no s’hagi previst, s’ha de mostrar un error perquè els
empleats truquin per confirmar el pressupost nou.

Solució:
• Peça (Part)
• Model (Model)
• Peça del Model (ModelPart)
• Reparació Estàndard (Repair)
• Client/Vehicle (Client)
• Reparació “Efectiva” (RepairPart)
Addicionalment, hi hem afegit la classe Taller (Workshop) per poder partir

d’un punt d’interrelació de totes les entitats.
De l’enunciat es dedueix que el taller necessita guardar informació sobre peces,

reparacions estàndards, models i clients. Per aquest motiu, s’han creat relacions
d’agregació entre el taller (Workshop) i les classes Part, Repair, Model i Client.
El conjunt de peces que requereix una reparació s’ha modelitzat mitjançant

una associació entre les classes Repair i Part.
Hi ha una peça (Part) específica per a cada model (Model), que representem
mitjançant una classe associativa (ModelPart) entre les dues classes anteriors.
Finalment, hem de relacionar el concepte de reparació amb el de client i

emmagatzemar les peces que s’han canviat per a poder generar les factures
corresponents (vegeu el diagrama complet).
Una vegada hem definit el model de dades, podem incloure els atributs i
mètodes que necessiti el model que acabem de dissenyar (vegeu el diagrama
complet).
No s’hi han inclòs els mètodes per no distorsionar el diagrama, però hi

tindrem com a mínim els mètodes que permeten crear, modificar i esborrar
parts, reparacions, models i clients i, finalment, els encarregats d’assignar-los.

cardinalitat.
Workshop
0..* 0..*
Client
Repair
0..* 0..* plate : String
phone : String
baseCost : int
name : String
address : String
0..*
0..*
0..* Model 0..* 1
Part brand : String
model : String 0..*
description : String 0..* 0..* year : int
IsOwnedBy
getEquivalent(m : Model) : ModelPart
ModelPart
RepairVehicle
code : String 0..* 0..*
initialDate : Date
cost : int
finalDate : Date
time : int
changePart(p : Part) : void
Problema 13: la llibreria virtual
Una llibreria vol oferir el seu catàleg de llibres i CD-ROM en venda per Inter-
net. Per això, ens ha demanat que desenvolupem una llibreria virtual que
més endavant s’utilitzarà per a construir una aplicació web. La llibreria
virtual ha de ser capaç de gestionar les comandes, el cistell de la comprai
també el catàleg en general. Les funcionalitats que ha de permetre l’aplicació
són les següents:
1) Crear un nou compte d’usuari: de cada usuari s’ha de guardar el nom i

cognoms, i també l’adreça postal. L’usuari tria un nom d’usuari que ha de ser
únic, i una contrasenya. S’ha de guardar informació d’una o més targetes de
crèdit que l’usuari pot triar per a pagar les diferents comandes que faci. De
les targetes s’ha de guardar el tipus de targeta, el número, el titular (segons
apareix a la targeta) i la data d’expiració (mes / any).
2) Afegir un nou article al catàleg: es poden afegir al catàleg tres tipus

d’articles: llibres, CD-ROM i informes digitals. Tots tenen un número de
referència intern (una cadena), un preu actual, un títol i una data de
publicació, però només dels llibres i CD-ROM cal emmagatzemar l’estoc
(nombre d’articles disponibles), ja que els informes digitals es distribueixen
mitjançant descàrregues d’Internet. Els informes digitals tenen, a més, una
data d’expiració en què es deixen de vendre, ja que es consideren obsolets.
Dels llibres, a més, s’emmagatzema el nombre de pàgines, i dels CD-ROM, la
mida en megabytes.
3) Actualitzar les quantitats d’exemplars en estoc: consisteix a incrementar o

disminuir la quantitat d’un article quan arriben existències noves o se’n
donen de baixa (per exemple, perquè s’han deteriorat). Quan es genera una
comanda, aquesta només es pot dur a terme si la quantitat en estoc és
suficient per a cobrir tots els articles demanats i, quan es fa, les quantitats en
estoc disminueixen adequadament.
4) Gestionar el cistell de la compra: cada compte d’usuari té associat un

cistell de la compra virtual, en què l’usuari pot afegir articles que vol
comprar. Pot adquirir diverses unitats d’un mateix article, especificant-ho
quan afegeix articles al carretó. No es comprova el nombre d’unitats
emmagatzemades al carretó, de nabera que s’hi poden afegir tots els articles
que es vulgui.
5) Finalitzar la compra a partir dels continguts del cistell: quan l’usuari acaba
de comprar (checkout), el cistell “es buida” i es genera una comanda. L’usuari
ha de triar la targeta de crèdit amb què la paga, i de la comanda es guarda a
més la data en què es fa. En aquest moment, s’associa la comanda amb la
targeta de crèdit i s’actualitzen les existències disponibles de cada article. És a
dir, es pot afegir al cistell el que es vulgui, però no és fins que es finalitza la
compra que es comproven i s’ajusten les existències. També en aquest

moment es crea la llista d’articles comprats, amb un comentari buit. Més
endavant, quan s’hi afegeix un comentari, es mira aquesta llista d’articles
comprats i s’actualitza el comentari.
6) Visualitzar l’historial de compres: es permet visualitzar totes les comandes

fetes, incloent-hi la data de compra, la referència dels articles comprats, la
quantitat comprada, i els preus a què es van comprar els articles, que poden
ser diferents dels preus actuals.
7) Afegir una recomanació a un article: quan un usuari compra un article, té

dret d’escriure un text en què el recomana i que és accessible per a la resta
dels usuaris.

Solució:
• Article (Item)
• Articles amb estoc (StockableItem)
• Llibre (Book)
• Informe Digital (DigitalReport)
• CD-ROM
• Usuari (UserAccount)
• Targeta de Crèdit (CreditCard)
• Cistell de la compra (ShopingBasket)
• Comanda (Order)
• Recomanació (Recommendation)
Les classes Item i StockableItem són abstractes, ja que representen parts

comunes d’altres classes.
La resta de les classes que representen els diferents tipus d’Item són subclasses
d’una de les anteriors: Book, DigitalReport i CD-ROM. La classe abstracta Stoc-
kableItem conté la funcionalitat específica d’articles subjectes a gestió
d’existències, que és igual per a totes les seves subclasses.
La informació de l’usuari es modelitza en la classe UserAccount, que està

associada amb una o diverses targetes (CreditCard). Els tipus de targeta es
representen mitjançant un atribut, ja que no hi ha diferències en la
informació que es modelitza depenent del tipus de targeta.
Els usuaris tenen associat un (i només un) objecte carretó d’anar a comprar
(ShoppingBasket). Els elements al carret es representen mitjançant una
associació amb la classe Item. Utilitzem una classe associativa per a poder
guardar la informació del nombre d’elements de cada ítem que s’han afegit
al cistell.
Quan l’usuari fa efectiva la compra, abans es crea una comanda (Order) i els
continguts del cistell s’esborren. Les comandes s’associen als ítems i, a més,
cal una classe associativa, no només per emmagatzemar la quantitat de cada
Item sinó perquè és necessari guardar el preu a què es van vendre (ja que pot
ser diferent del preu actual del producte). Les comandes es carreguen a la
targeta de crèdit que especifiqui l’usuari, i això queda reflectit en l’associació
entre Order i CreditCard.
Els comentaris (Recommendation) dels usuaris s’hi afegeixen com a classe

associativa entre el compte d’usuari i l’article comprat.
Finalment, s’ha dibuixat una classe principal BookShop, que proporciona

accés als objectes gestionats pel sistema, bàsicament de tipus UserAccount,
Item, Order.
Les classes inclouen els atributs especificats en l’enunciat. Respecte als

mètodes, es reparteixen de la manera següent entre les classes identificades:
a) La classe Item inclou mètodes comuns a tots els articles: són els mètodes
per a accedir als seus atributs (getRef/setRef, getName/setName, getPublica-
tion/setPublication i getPrice/setPrice).
b) La classe UserAccount inclou el mètode addCreditCard per a afegir una

targeta de crèdit addicional a l’usuari, i el mètode createShoppingBasket per a
crear i associar el cistell de la compra que portarà l’usuari.
c) La classe abstracta StockableItem conté la funcionalitat específica d’articles

subjectes a gestió d’existències: getStock i modifyStock.
d) La classe ShoppingBasket conté mètodes per a afegir i eliminar articles (ad-

dItem/removeItem) del cistell i per a buidar-lo (clear) quan l’usuari fa efectiva
la compra.
e) La classe Order inclou el mètode chargeToCreditCard per a carregar la

comanda en una targeta de crèdit específica.
f) La classe BookShop ha de proporcionar accés a les funcionalitats principals

de l’aplicació: gestió (altes, baixes, modificacions i consultes) d’usuaris i
articles, gestió del cistell, fer una comanda, afegir un comentari a un article
comprat, etc. Per fer-ho, es basa en els mètodes repartits per les altres classes
del model.
Les cardinalitats de les relacions reflectides en el model es defineixen segons

les restriccions expressades a l’enunciat. Per exemple, un usuari disposa d’un
sol cistell d’anar a comprar. Una targeta de crèdit s’assigna a un sol usuari (el
titular), una comanda es paga amb una única targeta de crèdit, etc.
La navegabilitat de les relacions s’estableix segons el sentit de navegació

necessari per a implementar els mètodes dissenyats. Per exemple, és necessari
saber els articles que hi ha al cistell de la compra, però no és necessari saber
quins cistells de la compra contenen un article. Per això el sentit de
navegació entre ShoppingBasket i Item. D’altra banda, com que cal processar
les comandes, és necessari localitzar la targeta de crèdit (per facturar) i els
articles (per sol·licitar la tramesa) des d’una comanda donada. Per aquest
motiu, el sentit de navegació des de la classe Order cap a les seves classes
associades.
1
Bookshop
hasUsers
1 0..*
newOrder()
UserAccount hasCredirCard CredirCard
newItem()
1 1..*
newUserAccount() id : String number : String
removeOrder() password : String owner : String
removeItem() name : String ShoppingBasket expiry : Date 1
removeUserAccount() surname : String
addItemToOrder(quantity : Integer) address : String 1 1
removeItemFromOrder() addItem()
createShoppingBasket() carries
removeItem()
addCreditCard() clear()
recommend(i : Item,t : String)
1 0..* 0..* BasketSelection
0..* quantity : Integer

0..*
Recommendation Item changeQuantity()
text : String ref : String

0..*
name : String
setText() publication : Date Order
price : Double
hasItems date : Date
0..*
chargeToCreditCard() 0..*
addItem(quantity : Integer)
OrderLine
StockableItem DigitalReport quantity : Integer

price : Double
stock : Integer expiry : Date
setQuantity()
getStock() getExpiry() setPrice()
modifyStock() setExpiry()
Book CdRom
pages : Integer size : Double
getPages() getSize()
setPages() setSize()
Problema 14: l’ONG hemeroteca
La biblioteca d’una ONG ha rebut un ajut econòmic important que es

destinarà a crear una hemeroteca. Això li permetrà adquirir i gestionar llibres
i revistes. Ens demana que dissenyem l’aplicació que permeti gestionar
l’hemeroteca i els seus usuaris. Després de l’anàlisi de requisits del sistema,
s’obté la següent informació:
1) La informació associada als llibres està formada de l’editorial, l’autor

principal, el títol, l’ISBN, la data de publicació i el preu.
2) De les revistes cal emmagatzemar la informació referent al nom de la

revista, l’editorial, el volum, el número, l’ISBN i la data de publicació.
3) Quan un número d’una revista és un monogràfic (tracta d’un únic tema),

a més de la informació anterior s’ha d’indicar el títol de tema, i també l’autor
principal dels articles. De cada autor només és necessari emmagatzemar el
nom complet.
4) Dels usuaris de la biblioteca de l’ONG cal emmagatzemar el nom complet,

el telèfon, l’adreça i l’edat.
L’aplicació informàtica ha de permetre realitzar les funcionalitats següents:
• Donar d’alta llibres i revistes, i també usuaris.
• Realitzar el préstec de llibres/revistes i garantir que es presten com a

màxim cinc articles per usuari.
• Conèixer els llibres d’un autor que s’han adquirit a la biblioteca, i també
els monogràfics en què l’autor ha escrit algun article.
• Buscar la informació associada a un llibre, revista o monogràfic, i també

la disponibilitat, a partir de l’ISBN.
• Conèixer tots els llibres i revistes que té actualment en préstec un usuari, i

també informació respecte si està penalitzat i la informació personal de
l’usuari. Considerem que un usuari pot tenir en préstec un màxim de cinc
documents a la vegada. Per simplificar, suposem que no és necessari
guardar un historial de préstecs.
• Avaluar cada dia quins documents (llibres o revistes) dels que hi ha en

préstec s’haurien d’haver tornat.

Solució:
• Hemeroteca (Library)
• Usuari (User)
• Llibre (Book)
• Revista (Magazine)
• Monogràfic (Monography)
• Document (Document)
• Préstec (Loan)
Com es pot veure en el diagrama de classes complet, la classe Library té

relacions d’agregació amb les classes User, Book, Magazine i Monographic. Les
classes Book i Magazine es poden definir mitjançant el mecanisme d’herència
a partir de la classe Document. De la mateixa manera, la classe Monographic es
pot definir mitjançant herència a partir de la classe Magazine.
Finalment, hi ha una classe Loan entre User i Document, que permet gestionar
els préstecs.
En el diagrama de classes del complet, hi ha els atributs de cadascuna de les

classes identificades. Respecte als mètodes, les classes responsables
d’implementar les funcionalitats descrites són les següents:
• Donar d’alta llibres i revistes: Library.
• Donar d’alta usuaris: Library.
• Fer préstecs de documents: Library, que delega en User, mitjançant una

crida al mètode borrowDoc. Aquest mètode crea una instància de Loan i
crida setLoan per assignar l’usuari i el document que s’ha de deixar, que se li
passa com a paràmetres. El mètode setLoan cridarà al seu torn setBorrowedBy
de l’objecte Document, perquè li quedi assignada la instància de Loan.
• Conèixer els llibres adquirits: Library.
• Saber els monogràfics en què participa un autor: Library.
• Buscar informació associada al document i la seva disponibilitat: Library.
• Conèixer documents en préstec d’un usuari: Library, que delega en el

mètode listLoans de la classe User.
• Avaluar quins documents en préstec s’haurien d’haver tornat: Library.

Les cardinalitats més notables són les que restringeixen el màxim de préstecs
(0...5) i la que associa un préstec amb el seu únic document associat. Les
altres cardinalitats no s’han restringit (0...*). Tampoc no s’ha restringit la
navegabilitat entre classes, ja que totes són necessàries per a implementar les
operacions demanades.
Library
1 hasMonographies
newDocument()
hasUsers 1
newUser() 1 hasMagazines
listBooks()
listMonographies()
getDocAvailability()
listLoans()
1
listPendingLoans() isBorrowed 1
0..* 1 Document
User 0..* isbn : String

publisher : Integer
nif : String Loan 0..1
1 0..5 publishing : Date
name : String
start : Date available : boolean
phone : String borrows end : Date hasBooks
address : String setBorrowedBy()
age : Integer setLoan(u : User,d : Document)
borrowDoc(d : Document)
listLoans()
0..*
Book Magazine
0..* author : String volume : Integer
title : String number : Integer
price : Double
0..*
Monography
author : String
title : String
Problema 15: Virtual Store Computers
Virtual Store Computers és una empresa especialitzada a vendre i distribuir

material i accessoris informàtics. A fi de millorar-ne el sistema de gestió, ens
demanen que dissenyem una aplicació capaç de gestionar productes, clients i
proveïdors, i també les comandes que fan els clients. Després d’una anàlisi de
requisits del projecte, s’ha arribat a les conclusions següents:
1) Tots els productes tenen un identificador i un nom. A més, és necessari

saber la quantitat d’unitats que tenim de cada producte i el seu proveïdor.
Els productes que es venen a l’empresa es classifiquen en equips i
dispositius.
2) Els equips són equips informàtics complets. D’aquests equips cal saber el
processador, els megabytes de memòria RAM i els gigabytes de capacitat del
disc dur.
3) Els dispositius són els que permeten als equips adquirir dades de l’exterior.
Per als dispositius, en general s’ha de saber informació comuna específica.
Ara per ara, a la botiga virtual solament hi ha un tipus de dispositiu, els DVD
(amb característiques addicionals pròpies), encara que aviat es catalogaran
dispositius nous.
4) Els clients de l’empresa virtual els classifiquem en dos tipus: particulars i

majoristes. Dels clients particulars ens cal emmagatzemar el nom, l’adreça i
un identificador únic del client. Dels majoristes ens interessa saber, a banda
de les mateixes dades que dels clients particulars, el descompte que s’aplica a
les comandes que fan.
5) Dels proveïdors ens interessa saber l’identificador, el nom i l’adreça, i també

la llista de productes que proveeix l’empresa. Considerem que un proveïdor
pot subministrar a la botiga com a màxim 50 productes diferents, però un
producte és subministrat per un únic proveïdor. Virtual Store Computers fixa
el cost de venda de cada producte, de manera que aquest cost no depèn del
proveïdor.
6) Els clients compren productes de l’empresa mitjançant comandes. Les

comandes es resolen modificant l’estoc dels productes convenientment. Per
a calcular el cost de la comanda, es té en compte el tipus de client. Per això,
els majoristes tenen descomptes en relació amb els particulars.
7) Una comanda està formada per la llista de productes que s’han comprat, i
per a cadascun d’aquests productes, el nombre d’unitats que s’han comprat.
Si en una comanda no hi ha prou estoc per a algun dels productes que es
demanen, la comanda no se serveix i s’han de tornar a l’estoc de productes
tots els productes que s’han assignat a la comanda.

Solució:
• Producte (Product)
• Equip Informàtic (Computer)
• Dispositiu (Device)
• DVD
• Comanda (Order)
• Majorista (WholeSaler)
• Proveïdor (Supplier)
La classe Store representa l’aplicació de la botiga virtual. Com que l’aplicació

està formada pels seus Customers, els seus Suppliers, els seus Orders i els seus
Products, s’han establert relacions d’agregació entre Store i Customer, Supplier,
Order i Product.
La classe Customer representa un client de la botiga virtual. La subclasse Who-

leSaler representa un client majorista. La classe Supplier és la classe que
representa un proveïdor de la botiga.
La classe Order és una classe que representa una comanda feta per un client a la
botiga virtual. La classe associativa SubOrder entre Order i Product representa una
part d’una comanda feta per un client de la botiga virtual, en què s’especifica
cadascun dels productes que ha demanat i el nombre d’unitats demanades.
Per als tipus de producte s’estableix una jerarquia d’herència que relaciona la
classe Product amb les subclasses Computer, Device i DVD per a tipificar els
articles que ven la botiga.
S’estableixen relacions d’associació entre Customer i Order (ja que des d’una
Order podem accedir al Customer que l’ha fet efectiva) i entre Supplier i Product
(ja que des d’un Supplier podem accedir als Products que subministra).
3) Identificació d’atributs i mètodes
La classe principal Store és caracteritzada per un nom i uns atributs que

implementen les associacions amb la resta d’objectes.
La subclasse WholeSaler conté els atributs relatius al client a l’engròs més el

descompte aplicable.
La classe Order guarda el cost com la suma dels preus de tots els productes
demanats. La classe associativa SubOrder conté com a atribut el nombre
d’unitats sol·licitades de cada producte en una mateixa comanda. El càlcul es
fa mitjançant el mètode computeCost de la classe Order, que al seu torn crida
al mètode computeCost de la classe SubOrder.
La classe Product és la que té la responsabilitat d’emmagatzemar els atributs

comuns a qualsevol producte de la botiga virtual (identificador, nom, preu i
quantitat en estoc). El proveïdor associat al producte es defineix amb el
mètode setSupplier. La classe Supplier subministra diversos productes
mitjançant crides al mètode supplies.
La classe Computer aglutina els atributs d’un equip informàtic bàsic de la

botiga virtual (el processador, els megabytes de memòria RAM i els gigabytes
de capacitat del disc dur).
Com que l’enunciat no especifica gaires restriccions de cardinalitat, la

majoria de les associacions tenen cardinalitat múltiple, amb l’excepció de la
relació entre Supplier i Product, ja que un producte només pot ser ofert per un
proveïdor, i entre Order i Customer, ja que una comanda solament és feta per
un client. D’altra banda, no s’han definit restriccions de navegabilitat,
perquè en principi des de qualsevol classe s’hauria de poder accedir als
objectes d’una altra classe associada.
1 Store
0..*
Supplier Customer 1
0..* 1
id : String id : String
name : String name : String
address : String address : String 1
supplies(p : Product) 0..* 0..*

Order
1 cost : Double
WholeSaler
computeCost()
0..* discount : Double
supplies
Product 0..*
0..50
id : String 0..*
name : String
stock : Integer
price : Double
setSupplier(s : Supplier) SubOrder
quantity : Integer
computeCost()
Computer Device
processor : Enum
ramMb : Integer
diskGb : Integer
DVD
Problema 16: Kot Editorial
Kot, editorial especialitzada en material didàctic per a l’aprenentatge

d’idiomes, vol automatitzar la gestió de les despeses dels seus treballadors.
Per fer-ho, l’editorial ens ha demanat que desenvolupem una aplicació que
sigui capaç de registrar i calcular les despeses d’aquests treballadors que es
generen durant l’activitat laboral.
Kot té una divisió comercial que lloga vehicles per als seus treballadors. Els
vehicles llogats són de dues categories: utilitaris i de gamma alta. Els treballadors
de Kot es classifiquen en responsables de la divisió, caps intermedis i comercials.
Alguns dels exemples de despeses que ha de gestionar la nova aplicació són

els següents: el quilometratge, la neteja del vehicle, el menjar, l’allotjament,
el material promocional i els regals fets a clients.
A continuació, es descriuen les funcionalitats que es vol que tingui el sistema:
1) Afegir un cotxe al sistema: permet afegir un cotxe al sistema, i n’indica la

categoria (utilitari o gamma alta), la matrícula i el quilometratge.
2) Afegir un treballador al sistema: consisteix a donar d’alta en el sistema un

treballador, que pot ser comercial, cap intermedi o responsable de la divisió.
De cada treballador és necessari guardar el nom, els cognoms i el compte
bancari. També volem emmagatzemar el preu per quilòmetre que es paga al
treballador en cas que no tingui cotxe d’empresa assignat i es desplaci amb
vehicle propi (per compensar-lo de la despesa que li comporta haver de fer
servir el seu). El treballador s’identifica pel document d’identitat que ha
aportat, del qual ens cal l’emissor (entitat legal que va emetre el document),
el tipus de document (per exemple, passaport, document d’identitat, etc.) i el
número d’aquest document.
3) Gestionar els clients en el sistema: afegir i eliminar clients del sistema.

De cada client ens cal el nom, els cognoms, el document d’identitat
(emissor, tipus i número), el nom de l’empresa/institució on treballa i la
informació de contacte. Per a eliminar el client, es marca com a eliminat
(no s’elimina físicament) i no es pot usar per a cap operació nova, com ara
regalar-li material. Encara que un empleat pugui ser client del sistema, per
raons de confidencialitat les seves dades es tracten en registres separats.
4) Afegir material al sistema: permet afegir material, que són els regals que els
comercials fan als clients. De cada material ens cal la descripció i el preu de cost.
5) Assignar un cotxe a un treballador: s’assigna un cotxe d’empresa a un

treballador. Des del moment en què un treballador té cotxe d’empresa, no
pot passar més despeses per quilometratge amb el vehicle propi.
6) Registrar una despesa d’un treballador: cal emmagatzemar informació sobre

les despeses generals, com ara la neteja del cotxe, el menjar o l’allotjament. De
les despeses cal emmagatzemar el concepte, que ha d’escriure el treballador,
l’import i la data en què es va produir. Si el treballador té cotxe d’empresa,
sempre que ompli el dipòsit ha d’omplir un justificant de despesa específica en
què també constin els litres de què s’ha proveït i els quilòmetres que té el cotxe
en aquell moment. Tots els treballadors, cada dia que usin el cotxe, tant si es
privat com d’empresa, han d’omplir una despesa específica i indicar els
quilòmetres que han fet per feina. El treballador pot haver fet més quilòmetres
de tipus privat amb el cotxe, tant si el cotxe és d’empresa com d’ús privat, però
no se n’ha d’informar l’editorial. A més, el treballador ha d’afegir un justificant
de despesa per a cada material que regali a un client, i hi ha d’especificar la
quantitat de cada material regalat, el client que ha rebut el regal i el motiu del
regal.
7) Generar un informe mensual de despeses: al final de cada mes, els treballadors

indiquen a l’empresa els quilòmetres del cotxe. Per simplicitat, considerem que al
final de mes el dipòsit del vehicle és buit i que el treballador comença i acaba el
mes amb el mateix cotxe. Cada mes es genera un informe per a cada treballador
que conté la suma de l’import de les despeses que s’han de reembossar al
treballador, i les dades del cotxe si l’empleat té cotxe d’empresa.

Solució:
• Editorial (Kot)
• Cotxe (Car)
• Material (Material)
• Persona (Person)
• Treballador (Worker)
• Document d’Identitat (IdentityCard)
• Despeses (Expense)
• Despeses de Combustible (ExpenseGas)
• Despeses de Quilometratge (ExpenseKm)
• Despeses de Material (ExpenseMaterial)
• Informe (Report)
En primer lloc, s’ha modelitzat una classe principal Kot, que representa
l’editorial i proporciona accés als objectes gestionats pel sistema, bàsicament
objectes de tipus Car, Person i Material.
La classe Person és abstracta, ja que representa la part comuna de les classes

Worker i Customer i no té sentit instanciar-la en el context de l’enunciat.
Hi ha diversos tipus de despeses. Algunes són generals, com ara el menjar,

l’allotjament o la neteja del cotxe, que es representen mitjançant la classe
Expense. D’aquesta classe hereten ExpenseGas, ExpenseKm i ExpenseMaterial,
que representen, respectivament, els proveïments de combustible del vehicle
d’empresa, els quilòmetres recorreguts amb el cotxe i el material promocio-
nal regalat als clients per part dels comercials.
La classe associativa Report inclou totes les dades necessàries per als informes
de despeses, i relaciona els objectes de la classe Car amb els de la classe Worker.
En la classe Car s’ha creat un atribut category, que indica la categoria del
vehicle: utilitari o gamma alta. No hauria estat justificat crear subclasses de
Car per a cada categoria, perquè no s’emmagatzema cap dada concreta sobre
aquestes categories. Així mateix, en la classe Worker s’ha creat un atribut type
que indica el tipus de treballador: comercial, cap intermedi o responsable de
divisió. No hauria estat necessari crear subclasses de Worker per a cada tipus
de treballador, ja que no s’indica cap tipus d’atribut o funcionalitat
específica per a cadascun d’ells.
Respecte als mètodes identificats, la classe principal Kot inclou mètodes

necessaris per a gestionar tots els objectes de l’aplicació (addCar, addWorker,
addCustomer, addStuff i reportExpense). La petició d’elaboració d’un informe és
també responsabilitat de la classe Kot, per mitjà del mètode reportExpense. Les
despeses d’un treballador s’han acumulat mitjançant crides successives al
mètode reportExpense, que crea instàncies noves d’Expense del tipus que es
tracti i crida addExpense de l’objecte Worker per associar-les al treballador en
qüestió. Kot delega en el mètode expenseIterator de la classe Worker per
esbrinar les despeses d’un treballador, sumar-les i, finalment, cridar addReport
per associar l’informe elaborat amb el Car corresponent.
També s’hi han afegit mètodes per a assignar un cotxe a un treballador, tant
des de la classe Car (assignToWorker) com des de la classe Worker (assignCar).
En qualsevol cas, la crida a algun d’aquests mètodes procedeix del mètode
assignCar de la classe Kot.
En el diagrama, es reflecteixen les cardinalitats identificades per a cada

associació, i també les restriccions de navegabilitat en cas que n’hi hagi per a
implementar els mètodes necessaris. L’associació carAssignment entre Car i
Worker té cardinalitat 0..1 ja que un treballador pot estar sense cotxe, i un

cotxe pot estar encara sense assignar a un treballador.
Kot
1 hasStuff
addCar()
addWorker()
hasCars 1 removeWorker() 1 hasCustomers
addCustomer()
addReport()
Person
reportExpense()
assignCar() firstName : String
newOperation() lastName : String
setIdentityCard()
1 0..*
Report 1
Customer
hasWorkers
test : String
company : String
0..* 0..* isRemoved : boolean
Car Worker
category : Integer 1 1 pricePerKm : Double
pate : String bankAccount : String 1
km : Double type : Integer hasIdentity
0..1 0..1
assignToWorker(w : Worker) carAssignment assignCar(c : Car)
1
1 addExpense(e : Expense)
expenseIterator()
IdentityCard
1 0..*
issuer : String
hasExpenses
type : String
Stuff
Expense number : String
0..* cost : Double
amount : Double
concept : String
date : Date
refersTo
1
GasExpense KmExpense StuffExpense 0..* refersTo

0..*
liters : Double km : Double quantity : Integer
carKm : Double 0..* refersTo
Problema 17: TENFE ferrocarrils
La companyia ferroviària TENFE, en vista de la quantitat d’avaries i el

descontentament dels clients, vol disposar d’una aplicació que li permeti
gestionar les avaries de manera ràpida i alhora proporcionar informació
actualitzada als clients.
TENFE vol dividir les avaries en tres tipus diferents:
• Avaries generals (qualsevol tipus d’avaria).
• Avaries elèctriques (més específiques, relacionades amb la catenària i les

línies de tensió).
• Avaries als trens (relacionades amb els vagons i la locomotora).
Totes les avaries tenen una descripció de l’avaria i una estimació del temps
necessari per a reparar-la. Les avaries elèctriques, a més, han d’indicar el
voltatge de la línia i el tipus de corrent (altern o continu).
Les avaries als trens poden ser de dos tipus: avaries a la locomotora, en què
s’ha d’indicar el tipus de la locomotora (dièsel o elèctrica) i l’any de
fabricació, o avaries als vagons, en què s’ha d’especificar si es tracta d’un
vagó de mercaderies o passatgers i el nombre de seients. A més, totes les
avaries als trens, amb independència del tipus que siguin, han d’indicar el
número de matrícula del vagó o locomotora. Les avaries són excloents, és a
dir, no poden ser de dos tipus alhora.
Per saber on s’ha produït l’avaria, TENFE introdueix en el seu sistema la

informació de totes les línies ferroviàries que controla. Així, cada línia consta
de les dades següents:
• El nom de la línia.
• Totes les parades de la línia ordenades, de manera que sempre podem

saber quina és la primera parada i la darrera. Cada parada consta del nom
de la parada, que ha de ser únic en el sistema, la ciutat més pròxima, i la
seva posició GPS (és a dir, dos números decimals que indiquen la latitud i
longitud d’un objecte al món). Així, doncs, una ciutat gran com
Barcelona pot tenir diferents parades, mentre que en una ciutat petita el
nom de la parada coincideix amb el de la ciutat. Per exemple:
Estació de Sants, Barcelona, 41.38, 2.14

Fabra i Puig, Barcelona, 41.43, 2.18
Cerdanyola, Cerdanyola, 41.49, 2.14
Cada vegada que es produeix una incidència, s’ha de registrar un ticket amb
la línia on s’ha produït la incidència, la parada i el tipus d’avaria. A més, per
a assegurar la qualitat del servei i la reparació, també es guarda el nom del
mecànic que ha reparat l’avaria i el nom de l’inspector que ha revisat que tot
funciona correctament. Cada incidència té un identificador únic, i té
associada la data i l’hora en què s’ha produït la incidència i quan s’ha
solucionat. Aquesta informació s’utilitza per a llistar les avaries més recents.
Segons la descripció anterior, cada incidència pot estar en quatre estats

diferents:
1) Nova Incidència: quan s’ha donat d’alta l’avaria però encara no ha

començat la reparació.
2) En reparació: quan un mecànic ha estat assignat per a reparar la

incidència.
3) Reparada: quan un inspector ha comprovat in situ que l’avaria està

reparada.
4) Descartada: si es comprova que l’avaria és fictícia i es pot descartar. Fixeu-

vos que, per a poder descartar una avaria, ha de passar primer per tots els
altres estats. Solament quan el mecànic assignat i l’inspector comproven que
és fictícia, es pot descartar l’avaria.
Tant els mecànics com els inspectors són treballadors de la companyia. De

tots ells es guardarà el nom, un telèfon de contacte i una adreça. A més, com
a treballadors de la companyia, tenen un número de treballador i la data en
què van començar a treballar.

Solució:
• TENFE
• Treballador (Worker)
• Incidència que cal reparar (Ticket)
• Ruta (Route)
• Parada (Stop)
• Estat dels Tickets (TicketStatus)
• Avaria (Breakdown)
• Tipus d’avaries (TrainBreakdown, ElectricBreakdown, GeneralBreakdown,
LocomotiveBreakdown i CoachBreakdown)
L’aplicació ha de permetre controlar els treballadors, les rutes i les

incidències. Per aquest motiu, cal una classe TENFE formada per treballadors
(Worker), tickets d’incidències (Ticket) i rutes (Route). Hi ha una relació
d’agregació entre TENFE i aquestes tres classes.
Expressar l’estat d’un ticket com una associació entre Ticket i TicketStatus no
és l’única opció de modelització, ja que els diferents estats també podrien
estar definits dins de la classe Ticket o com un tipus enumerat. Els tickets
mantenen una relació amb el tipus d’avaria (Breakdown), la parada on s’ha
produït l’avaria (Stop), els treballadors que l’han reparada i supervisada (Wor-
ker) i el seu estat (TicketStatus).
Té sentit que una ruta sempre tingui com a mínim una parada. Com que una
parada pot formar part de més d’una ruta, la relació que tenen és d’agregació
(no excloent) i no de composició (excloent).
També tenim la classe Avaria (Breakdown) i totes les seves especialitzacions.

Aquestes especialitzacions poden ser de tres tipus diferents: avaries dels trens
(TrainBreakdown), elèctriques (ElectricBreakdown) i generals
(GeneralBreakdown). Les avaries de trens (TrainBreakdown) poden ser de dos
tipus diferents (especialització en un dels dos tipus): avaria de la locomotora
(LocomotiveBreakdown) o avaria de vagons (CoachBreakdown).
Una altra decisió que s’ha de tenir en compte és el fet que les classes Break-
down i TrainBreakdown són abstractes, de manera que és necessari especificar
quina de les seves subclasses volem crear.
Cada treballador (Worker) conté l’identificador assignat per l’empresa i la

data en què es va firmar el contracte.
Els tickets (Ticket) estan formats de tres atributs (identificador, data de l’avaria
i data de la reparació).
Cada classe de l’especialització de Breakdown té els atributs específics del

tipus d’avaria, mentre que la superclasse (Breakdown) conté els atributs
compartits per totes (descripció, temps estimat de reparació i matrícula).
Com que només hi ha dos valors per a cada classe, hem modelitzat els tipus
de vagó i de locomotora com a atributs amb valors booleans (per exemple:
electricDiesel: true | false). Si es preveu l’existència de més tipus, podríem
definir atributs estàtics amb els tipus de vagó en CoachBreakdown, i els tipus
de locomotora en LocomotiveBreakdown, o bé en la seva superclasse (Train-
Breakdown) o en alguna altra classe separada (per exemple, una nova classe
d’anomenada TrainType), però mai a la classe Breakdown, ja que són massa
específics i només són útils per a les avaries de trens.
La navegabilitat entre Ticket i Stop s’ha establert en aquest sentit, per a

localitzar la parada afectada per una incidència. En principi, no té gaire
sentit localitzar els tickets d’incidències d’una parada, encara que si es vol fer
així es pot canviar la navegabilitat. No s’ha restringit la resta de
navegabilitats entre objectes de classes associades. Per exemple, la
navegabilitat de les associacions entre els tickets i els treballadors (Worker)
s’ha deixat en tots dos sentits, ja que sembla raonable voler localitzar tant els
tickets d’un treballador com el treballador que s’encarrega de reparar o
supervisar un ticket.
TENFE
Route
Worker
addTicket() name : String
id : String 0..* 1 addWorker() 1 0..*
contract : Date addRoute() addStop()
hasWorkers hasRoutes
supervises(t : Ticket) listRecentBreaks()
0..*
repairs(t : Ticket)
1
1 1 hasTickets
0..* {ordered}
isSupervisedBy 0..* 0..*
Stop
Ticket
name : String
isRepairedBy 0..* id : String city : String
0..1 1
originated : Date latitude : Float
refersTo
fixed : Date longitude : Float
Breakdown setStatus()
estimated : Date 1 1
1 involves TicketStatus
plate : String
NEW_INCIDENCE : Integer
WORK_IN_PROGRESS : Integer
hasStatus 1 FIXED : Integer
DISCARDED : Integer
TrainBreakdown GeneralBreakdown ElectricBreakdown
regNumber : String power : Integer

AC : Boolean
CoachBreakdown LocomotiveBreakdown
passengerFreight : boolean electricDiesel : Boolean

type : Integer type : Integer
seats : Integer year : Integer
Problema 18: test TrafiUOC
La Direcció General de Trànsit TransUOC s’ha plantejat automatitzar la

realització de proves de “tipus test” dels psicotècnics necessaris en els
permisos de circulació. A continuació, es descriuen els requisits del sistema.
TransUOC desenvolupa tests de diferents tipologies (segons la llicència que

es vol obtenir); per exemple, ciclomotors (A1) i autobusos amb remolc (E2).
Ens cal conèixer el nom i el codi dels diferents tipus de test, i un conjunt de
descriptors que hi estan associats. Un exemple de descriptor del test E2 és
“mecànica del remolc”. Un descriptor pot descriure més d’una tipologia de
test. Cada pregunta d’un test avalua com a mínim un d’aquests descriptors.
Un test es compon d’un conjunt de preguntes, entre 15 i 20. D’un test s’ha
d’emmagatzemar en quina tipologia s’utilitzarà (A1, E2, etc.) i quina és la
data de creació. A vegades, les preguntes es reutilitzen en tests diferents, de
manera que una mateixa pregunta pot sortir en més d’un test.
Un test té una puntuació corresponent a la suma de les puntuacions de les

preguntes que conté. La puntuació de cada pregunta és un número
corresponent a una puntuació absoluta o a un percentatge. És possible que
una mateixa pregunta, en un test, tingui una valoració d’1 punt, en un
altre de 0,5 i en un altre que constitueixi el 5% de la nota final del test. Els
tests estan formats per preguntes, totes amb valoració absoluta o totes amb
valoració percentual. En aquest darrer cas, la puntuació suma exactament
el 100%.
Cada pregunta descriu un enunciat, les possibles opcions de resposta i els

descriptors que avalua. Hi ha diferents tipus de pregunta segons les seves
opcions de resposta: pregunta de resposta simple, pregunta de resposta
múltiple i pregunta d’ordenació.
D’altra banda, les preguntes es poden definir com a dependents del temps o
no dependents del temps quan s’associen a un test determinat. En les
primeres, es requereix emmagatzemar el temps estimat que l’estudiant hauria
de trigar a respondre, i es defineix una penalització expressada com a
percentatge de la puntuació de la pregunta, que s’aplica si l’estudiant supera
el temps estimat per a contestar-la. En el cas de les preguntes no dependents,
aquestes dues característiques (temps i penalització) tenen valor nul. Una
mateixa pregunta pot ser dependent del temps en un test i independent en
un altre test diferent.
La realització d’un test d’un estudiant és sempre seqüencial, és a dir, se li

mostren les preguntes d’una en una, sense la possibilitat de recular. L’ordre
de presentació de les preguntes d’un test es fa de manera aleatòria.
Dels estudiants només ens cal guardar el número d’identificació (NI), ja que
les dades personals les tracta una altra aplicació.
Quan un estudiant contesta un test, es guarda la data de realització. També

s’ha de guardar, per a cada pregunta, l’opció o opcions de resposta que ha
seleccionat en la contestació (i l’ordre de selecció, si és necessari). Finalment,
també es vol tenir constància del temps invertit per l’estudiant a contestar
cada pregunta, independentment de si la pregunta és dependent del temps o
no. Tota pregunta ha de permetre comprovar si una contestació concreta és,
alhora, una resposta correcta. És per això que cada pregunta ha de tenir una
operació que comprova si una contestació d’un estudiant determinat és
correcta o no.
Donada la descripció del problema que s’ha de resoldre, es demana el

diagrama UML que inclogui les classes, relacions, atributs i mètodes que
participen en el disseny de les funcionalitats requerides.
Solució:
• Test (Test)
• Estudiant (Student)
• Pregunta (Question)
• Pregunta Simple (SimpleQuestion)
• Pregunta Múltiple (MultipleQuestion)
• Pregunta Ordenada (SortingQuestion)
• Llicència (Licence)
• Resposta Correcta (CorrectAnswer)
• Respostes Test (AnsweredTest)
• Resposta Pregunta (AnsweredQuestion)
• Resposta Pregunta Simple (AnsweredSimple)
• Resposta Pregunta Múltiple (AnsweredMultiple)
• Resposta Pregunta Ordenada (AnsweredSorting)
Es detecta una jerarquia d’herència corresponent a la tipologia possible de

preguntes. La classe Pregunta (Question) és una classe abstracta de la qual
hereten les classes Pregunta Simple (SimpleQuestion), Pregunta Múltiple (Mul-
tipleQuestion) i Pregunta Ordenada (SortingQuestion).
Les opcions de resposta possible d’una pregunta es modelitzen mitjançant

una agregació amb subclasses de la classe abstracta AnsweredQuestion.
Les respostes correctes de les preguntes es modelitzen amb altres

associacions, que tenen cardinalitats o restriccions diferenciades d’acord amb
cada tipus de pregunta. Una solució alternativa és utilitzar un valor lògic per
a indicar les respostes que l’usuari ha de marcar i en el cas dels tests ordenats,
un enter que indiqui l’ordre. S’ha utilitzat la restricció UML {ordered} en els
elements de resposta ordenada. Això es pot especificar també en llenguatge
natural o bé afegint un atribut de l’associació amb un nombre ordinal per
indicar l’ordre correcte de les opcions de resposta.
S’identifiquen dos tipus de classes associatives. La primera classe, corresponent a

les propietats d’una pregunta en un test (QuestionProperties), representa que una
QuestionProperties emmagatzema les propietats d’una Question en un Test. La
segona classe representa els tests que ha respost un alumne (AnsweredTest) en una
data.
Les característiques de les entitats es representen per mitjà d’atributs i mètodes

d’accés. Quant al Test, és necessari emmagatzemar atributs de creació del test
(creationDate) i tipologia (type). En el cas dels estudiants (Student), és necessari
el número identificador (NI). En el cas de la pregunta (Question), se
n’emmagatzemen les característiques pròpies i diferenciadores per a cada tipus
de test. El temps de resposta de cada pregunta d’un test s’emmagatzema en la
classe AnsweredQuestion, i la data de resposta del test en la classe AnsweredTest.
Les relacions s’estableixen bidireccionals per a facilitar els accessos.
1..*
1 1..*
AnsweredTest AnsweredQuestion
-date : Integer -time : Integer
Student
1..* 1..*
-NI : Integer
Test
1 -creationDate : Integer
15..20 1..* -type : String
Question
+obtainMaximalMarks() : void {sequential}
-questionSentence : String
+correctAnswer(AnsweredQuestion : void) : void {sequential} QuestionProperties

AnsweredSimple
1..*-expectedTime : Integer
-timePenalization : Integer
-mark : Integer Licence
-unitMark : MarkType
-name : String
1..*
-code : String
AnsweredMultiple
SimpleQuestion MultipleQuestion SortingQuestion 1..*
1..*
1..* 1..*
Descriptor
AnsweredSorting
1 1 1 -name : String
+corrects +ordered
1..*
1..* 1..*
correct 1 has
CorrectAnswer 1
has
1..*
has
1..*
Problema 19: esports SportsUOC
SportsUOC és una empresa dedicada a gestionar competicions esportives. Per

això, és necessari obtenir i gestionar la informació relativa a competicions,
equips, jugadors i altres característiques que es detallen a continuació.
L’empresa gestiona diferents competicions esportives, amb la característica

comuna que es refereix a esports d’equip en què els partits s’acaben per temps.
El futbol, el bàsquet i l’handbol són alguns exemples d’aquestes competicions.
Per a qualsevol competició, és necessari emmagatzemar la següent informació:

codi d’identificació, nom, nom de l’esport, nombre d’equips participants,
nombre de jugadors necessaris per equip en una competició, llista d’equips
participants, estat de la competició (per començar, en joc o acabada) i equip
guanyador. Les competicions poden ser de dos tipus: lliga o copa.
El sistema de competició de lliga es caracteritza perquè els equips juguen tots

contra tots, en un sistema d’una sola volta, de manera que, essent N (que ha de
ser parell) el nombre d’equips participants, el nombre de jornades és N – 1.
Cada jornada té un número de jornada que s’assigna de manera correlativa (1,
2, 3...) en ordre cronològic. En cada jornada es juguen N/2 partits. Al final de
cada partit, segons el resultat (victòria, empat o derrota), els equips sumen una
determinada quantitat de punts (que s’ha d’especificar). Al final de la
competició, el guanyador de la lliga és l’equip amb més punts.
El sistema de competició de copa és un sistema d’eliminació directa fins a

arribar a un partit final que determina el guanyador. Per tant, en aquest cas
el nombre d’equips participants (N) ha de ser potència de 2. El nombre de
partits que es juguen en cada jornada (que en aquest sistema se solen dir
rondes) és successivament N/2, N/4, etc., fins a arribar al partit final. Així, el
nombre de jornades (incloent-hi el partit final) amb aquest sistema és log2N.
En aquest cas, per assignar el número de jornada utilitzem el nombre de
partits que s’han de jugar. Així, per exemple, en una competició de copa
amb 16 equips participants, tenim 4 jornades, numerades de la manera
següent: 8 (vuitens de final), 4 (quarts de final), 2 (semifinals) i 1 (final).
De qualsevol competició ens cal llistar els resultats dels partits d’una determinada
jornada. De les competicions de lliga, a més, s’ha de llistar la classificació (llista
ordenada dels equips, segons els punts obtinguts per cadascun des del
començament de la competició fins a la darrera jornada jugada).
De les jornades s’emmagatzema el número de la jornada, el nombre de

partits que s’han de disputar en la jornada i els partits que es juguen.
Dels partits s’emmagatzemen els equips que han jugat i els gols que han fet
cadascun.
De cada equip guardem el codi d’identificació, el nom, l’esport, la llista de

jugadors, l’entrenador i la llista de competicions inscrites. Un mateix equip
pot participar en més d’una competició del seu esport.
Dels jugadors i dels entrenadors es necessita el nom, el document d’identitat,

l’equip al qual pertanyen i el sou base. Els entrenadors tenen una prima
addicional per competició guanyada. No hi ha la possibilitat que un
entrenador sigui també un jugador.
L’aplicació ha de permetre afegir i eliminar una competició, llistar

competicions, començar i acabar competicions. A més, ha de permetre
gestionar persones: afegir persones, llistar persones i llistar el sou d’una
persona. Finalment, també ha de permetre gestionar equips: afegir equips,
llistar equips, afegir l’entrenador d’un equip, afegir un jugador a un equip,
llistar la plantilla d’un equip, afegir un equip a una competició, afegir una
jornada a una competició, afegir un partit a una jornada, llistar els resultats
dels partits d’una jornada, llistar la classificació d’una determinada
competició i mostrar l’equip campió d’una competició.

Solució:
• Equip (Team)
• Competició (Competition)
• Lliga (League)
• Copa (Cup)
• Jornada (Round)
• Persona (Person)
• Jugador (Player)
• Entrenador (Trainer)
• Partit (Match)
Les característiques comunes d’Entrenador i Jugador es modelitzen en la

classe abstracta Persona.
Hi ha una segona jerarquia d’herència corresponent al tipus de competició:

lliga o copa.
La classe SportsClub representa l’empresa que gestiona un conjunt d’equips,

competicions i persones.
Cada jornada consta d’un conjunt de partits, per la qual cosa s’ha modelitzat
una agregació entre Jornada (Round) i Partit (Partit).
Cada competició consta d’un conjunt de jornades (Round), que es

modelitzen per mitjà d’una agregació.
El nombre de gols que guanya un equip en un partit es modelitza mitjançant

la classe associativa MatchTeam.
Les característiques de les entitats es representen per mitjà d’atributs i

mètodes d’accés. Els més rellevants corresponen als atributs de la
Competition, Team, Person, Round i Partit. En el cas dels entrenadors (Trainer),
s’hi afegeix l’atribut que permet gestionar-ne la prima salarial.
S’estableix navegabilitat direccional per a les relacions implicades. En el cas

de la relació que identifica un equip guanyador d’una competició, s’estableix
una relació unidireccional.
1 1
1 1..* SportsClub
1 1..*
Team
Trainer Player 1..*
-id : Integer
-additionalSalary : Integer
-name : String
1 -sport : String
1
1..*
Person 1..* 1
+winner
-name : String +plays
-id : Integer
-baseSalary : int 1..* 1..*
Competition 1
Round
-ci : Integer
-number : Integer
-name : String
-state : String
1..* 1
+getResults() : void {sequential}
1
1..*
Match League Cup
-id : Integer
+getClassification() : void {sequential}
1..*
MatchTeam
-goals : Integer
-result : String
Problema 20: aplicació TV
Una important productora televisiva ha augmentat el volum de negoci de

manera espectacular, per la qual cosa ha decidit encarregar-nos una nova
eina per a gestionar els programes, les cadenes i el personal implicat.
Dels programes ens cal registrar la informació referent a l’identificador, el

nom, la descripció, els presentadors, la llista d’emissions, la data d’inici i si
s’emet actualment. Els programes de la productora televisiva es classifiquen
en programes de divulgació, competicions i entreteniment/tertúlia.
Dels programes de divulgació s’ha d’emmagatzemar la informació referent a

l’impacte previsible, segons el codi establert per l’associació de programes
divulgatius. Dels programes de competicions, en què l’objectiu és aconseguir
un premi, s’han d’emmagatzemar les característiques d’aquest premi. Dels
programes d’entreteniment/tertúlia és necessari emmagatzemar el tema de
discussió.
Els programes de la productora tenen tant d’èxit que s’emeten diverses

vegades per diferents cadenes d’emissió. En cada emissió del programa, se
seleccionen els convidats que hi participen, si escau. De cada emissió
s’emmagatzema a quina cadena s’emet i la data d’emissió. De cada cadena
interessada a emetre els programes la productora emmagatzema
l’identificador, el nom, l’adreça i un telèfon de contacte.
L’equip humà considerat important per la productora, en aquesta gestió, el

formen els presentadors i els convidats. De tots ells és necessari
emmagatzemar el document d’identitat, el nom, els cognoms, l’adreça i el
telèfon. A més, dels convidats s’ha de guardar l’especialitat, i també s’ha de
mantenir un control de les emissions en què han participat. Dels
presentadors cal conèixer quins programes presenten actualment, i també la
seva experiència, mesurada en nombre de programes en què han participat
al llarg de la seva carrera en la productora. La manera més habitual de
contactar amb els presentadors és mitjançant el correu electrònic i, per tant,
l’aplicació ha d’oferir la possibilitat d’emmagatzemar aquesta dada.
La nova aplicació ha de gestionar els programes, les persones, les cadenes, les
emissions, i ha de permetre afegir i llistar la informació de manera rellevant
i, addicionalment, assignar o eliminar presentadors d’un programa, afegir
convidats a una emissió, llistar la programació per a un interval de temps i
assignar un programa com a fora d’emissió, sempre que no n’hi hagi
emissions pendents.
No es descarta que, en un futur, s’afegeixin noves topologies de programes o

rols del personal de la productora; per tant, l’aplicació s’ha de dissenyar
tenint en compte aquests aspectes.

Solució:
• Productora (Producer)
• Cadena (Channel)
• Presentador (Presenter)
• Convidat (Guest)
• Emissió (Broadcasting)
• Programa (Program)
• Programa d’entreteniment / tertúlia (Entertainment)
• Programa de divulgació (NewsReport)
• Programa de competició (Competition)
La informació comuna a Presentador i Convidat es modelitza en una nova

classe, Persona, que conté la informació comuna de tots dos.
Hi ha una jerarquia addicional d’herència corresponent a la tipologia del

programa, ja que cadascun té una informació característica.
Una Productora (Producer) consta d’un conjunt de Cadenes (Channel), que es

representa mitjançant l’agregació Producer-Channel. S’assumeix que el
presentador i els convidats formen part del programa en curs, i és per això
que es modelitza una agregació Producer-Person. Un programa forma part
d’un conjunt d’emissions. Per això, es modelitza una agregació entre Pro-
gram-Broadcasting.
L’associació entre presentadors i programes es pot modelitzar com una classe

associativa que emmagatzema la data de gravació.
3) Inclusió de mètodes, atributs i relacions

mètodes d’accés. Els més rellevants corresponen als atributs de la Cadena
(Channel), Programa (Program), les característiques comunes a convidats i
presentadors a Person, i les característiques específiques corresponents a cada
tipus de programa i a convidats en forma d’atributs en la subclasse
corresponent.
S’estableix navegabilitat direccional per a les relacions implicades per a

facilitar la gestió de llistes i l’accés a la informació.
Person
1..* 1..*
Producer -dni : Integer
Channel -name : String
-id : Integer -address : String
1..* 1..* -phone : String
-name : String
-address : String
-phone : String isOnAir
1..* 1..*
Broadcasting
1..* 0..*
-date : Date
Guest
1 0..* +invites
Program -theme : String Presenter
-id : Integer -email : String

-name : String
-description : String
-startingDate : Date 1..* 1..*
PresenterProgram
-date : String
NewsReport Competition Entertainment
-code : Integer -awardCh : String -theme : String

Problema 21: ONG multimèdia
Una organització no governamental, veterana en projectes internacionals de

desenvolupament, necessita una aplicació per a gestionar els continguts
multimèdia que els seus cooperadors han aportat al llarg del temps.
Els continguts són de tipologia diversa, en format digital o en qualsevol altre

format, que es converteix a format digital abans d’emmagatzemar-se.
L’aplicació ha de permetre gestionar els continguts esmentats, i evitar que
més d’un cooperant modifiqui un mateix material de manera concurrent (si
no es podrien perdre les modificacions), i també limitar l’accés als continguts
dels diferents tipus de cooperants (rols). D’aquesta manera, un cooperant
que desenvolupi, per exemple, la tasca a l’Àfrica, té accés d’autor (lectura o
modificació) als continguts relacionats amb l’Àfrica, té accés de lector
(únicament lectura) als continguts relacionats amb Àsia i no té accés als
continguts interns de l’organització.
Dels continguts multimèdia que s’han de gestionar cal emmagatzemar la

informació següent: l’identificador, una descripció i la ruta d’accés a l’arxiu
(filepath).
Hi ha diversos tipus de continguts que cal emmagatzemar: imatges, àudio,

vídeos i documents ofimàtics, encara que no es descarta afegir noves
tipologies de continguts en un futur.
Dels continguts de tipus imatge (fotografies, escanejats, etc.) s’ha

d’emmagatzemar el format (PNG, JPEG, etc.), l’amplada i l’alçària en píxels.
Dels continguts d’àudio (registre de música local, converses) cal
emmagatzemar el còdec (per exemple, MPEG Layer-3 o Vorbis Ogg ACM), la
durada en segons i els idiomes en què està disponible. Dels vídeos ens
interessa la mateixa informació que dels continguts d’àudio, el còdec de
vídeo (per exemple, DivX 5.0 o Xvid) i els idiomes de subtítols disponibles.
Finalment, els documents ofimàtics –per a evitar problemes de compatibili-
tat– es guarden únicament en format de document portàtil (PDF) si es tracta
de documents que s’han d’imprimir o publicar en paper, o bé en format
ISO/IEC 26300 (OpenDocument) si es tracta de documents de processador de
textos, fulls de càlcul o presentacions.
L’aplicació ha de gestionar, també, la creació de cooperants i rols amb què

s’accedeix als documents del sistema. Cada vegada que s’afegeix un
document multimèdia al sistema és necessari especificar quins rols hi poden
accedir (en mode de lectura i escriptura). D’aquesta manera, quan un usuari
vol accedir a un document específic, es comprova si el cooperant hi pot
accedir i amb quin rol. Si hi pot accedir, se li faciliten les dades per a fer-ho,
sempre que en aquell moment no l’estigui fent servir cap més cooperant.
Partint d’aquesta descripció, les funcionalitats que ha de proporcionar

l’aplicació es refereixen a gestionar cooperants, rols i continguts multimèdia.
Respecte a gestionar cooperants i rols, la nova aplicació ha de permetre afegir

i eliminar cooperants, rols, assignar i desassignar rols als cooperants, llistar
cooperants i rols, llistar continguts del cooperant i permetre que un
cooperant, si té permisos, editi un contingut.
Respecte a la gestió de continguts multimèdia, l’aplicació ha de permetre

afegir i llistar continguts per tipologia.

Solució:
• Contingut (Content)
• Contingut imatge (Image)
• Contingut d’àudio (Audio)
• Contingut de vídeo (Video)
• Contingut de document (Document)
• Cooperador (Cooperator)
• Rol (Role)
La classe ONG representa l’ONG amb un nombre de continguts, rols i

cooperadors. Aquesta representació es modelitza amb agregacions d’ONG a
Content, Role i Cooperator.
Hi ha una jerarquia d’herència corresponent a la tipologia del Contingut que

especialitza en Image, Audio i Document. Video, al seu torn, hereta d’Audio.
Es modelitzen les relacions binàries següents: Contingut-Cooperador, Coopera-

dor-Rol, Contingut-Rol (lector) i Contingut-Rol (autor).

mètodes d’accés. Els més rellevants corresponen als atributs del Contingut
(Content) i a les característiques específiques corresponents a cada tipus de
Contingut (Image, Audio, Document, Video).
4) Cardinalitat i navegabilitat de les relacions
S’estableix navegabilitat direccional de les relacions implicades per a facilitar

la gestió de llistats i l’accés a la informació.
1
+ ONG
1
1
1..*
1..*
+ Content 1..*
+ Cooperator
-id : String 1..* +has authors 0..1 1..* 1..*
-id : Integer + Role
-description : String
-filePath : String -id : String
1..* +has readers roles 1..*
1..*
1..*
+has authors roles
+ Image + Audio + Document
-format : String -codec : String -type : String

-width : Integer -languages [0..*] : String
-height : Integer -duration : Integer
+ Video
-subtitlesLanguage [0..*] : String

Part III. Problemes proposats (sense solució)
Problema 1: gestió de nòmines
Una gran empresa es planteja fer un programa per a gestionar les nòmines
dels empleats. L’empresa té diferents tipologies d’empleats i, depenent de la
tipologia, un empleat ha de percebre un plus o un altre segons uns objectius.
Els diferents tipus d’empleats que té l’empresa són administratius,

comercials, personal de logística, personal de neteja, directors (generals i
departamentals) i màrqueting.
Tots els empleats tenen un sou base, que es calcula de la manera següent:
• Els comercials afegeixen al sou un plus per desplaçament i un altre segons

les seves vendes.
• Els administratius tenen un plus pel menjar (ja que són en una zona
industrial una mica apartada).
• El personal de logística també té el plus pel menjar i, com que per torns
fan tasques a la nit, també tenen un plus per nocturnitat.
• El personal de neteja també té un plus per nocturnitat, però com que té

un torn més reduït no tenen cap més plus.
• Els empleats del departament de màrqueting tenen un plus per

desplaçament, que depèn dels viatges que facin, i un altre pel menjar.
• Finalment, els directors, departamentals o generals, tenen, a part d’un sou

base, un compte de despeses de fins a 6.000 euros al mes, per a invertir en
restaurants, desplaçaments i despeses de representació. En cas que se
superi aquest import, la diferència se’ls descompta de la nòmina. Els
diners no gastats no s’acumulen per a mesos següents.

Problema 2: empresa en línia
Una empresa, que té un lloc web en què únicament mostra informació sobre
els seus productes, hi vol afegir ara un sistema per a gestionar les comandes
per Internet.
Els usuaris omplen el cistell de la compra a mesura que naveguen, de

manera que en qualsevol moment el poden consultar (de cada producte es
requereix que mostri una descripció breu, el preu i la quantitat
demanada).
Posteriorment, quan es produeix el procés de compra, depenent de la

quantitat demanada, s’hi ha d’aplicar un descompte o un altre (per exemple,
si es demanen més de 5 unitats, s’hi aplica un 5% de descompte). A més, s’hi
han d’afegir les despeses de tramesa, però si el valor total de la compra (sense
comptar les despeses de tramesa) supera els 200 euros, aquestes despeses són
assumides per l’empresa.

Problema 3: MEC
El Ministeri d’Educació i Ciència està interessat a conèixer els llibres de text

més utilitzats que s’utilitzen més en les titulacions universitàries espanyoles.
Per això, ens ha encarregat que dissenyem un programa que permeti obtenir
els textos més referenciats en els programes oficials de les assignatures.
Les diferents universitats estructuren el pla d’estudis de cadascuna de les

seves titulacions en forma d’assignatures. De cada assignatura s’ha de saber
el curs, el semestre en què s’imparteix (se suposa que totes són semestrals) i
els crèdits assignats. És important considerar que cada universitat pot tenir
el pla d’estudis d’una mateixa titulació estructurat de maneres diferents,
amb assignatures i disposició en cursos, ja que els plans d’estudi solen
canviar. Del pla d’estudis només és necessari saber l’any en què es va
aprovar.
El Ministeri d’Educació vol generar llistes ordenades de totes les

assignatures d’una certa titulació i un pla d’estudis. L’ordre de la llista
d’assignatures ha de ser alfabètic o per número de curs (i dins d’un curs
alfabèticament), encara que no es descarten altres tipus d’ordenació més
endavant.

Problema 4: personal PIKAPLUS
L’empresa PIKAPLUS vol informatitzar el sistema de gestió del personal

assignat a projectes de desenvolupament de programari. Per a fer-ho, un
primer pas és definir un model flexible dels rols professionals dels empleats
dins dels projectes.
L’empresa té contractats en plantilla empleats de diferents perfils

professionals. Encara que els diferents rols són fixats a priori, se’n poden
definir d’altres més endavant. Actualment, els rols són els següents:
• Caps de projectes, per als quals s’ha de saber quins projectes dirigeixen
amb aquest rol. Un empleat pot dirigir més d’un projecte.
• Analistes, per als quals s’ha de saber de quins models (diagrames de

classes, casos d’ús, diagrames de seqüència, etc.) són responsables.
• Programadors, per als quals s’han de saber els fitxers font dels quals són
responsables.
Els models i els fitxers font són dos tipus d’entregables. D’un entregable se
sap a quin projecte pertany. Un entegrable no es pot compartir entre
diferents projectes.
Un mateix empleat pot cobrir, simultàniament, el mateix rol o diferents rols

en diferents projectes o el mateix projecte. Per exemple, una persona pot fer
d’analista en un projecte i de programador en un altre, o pot fer alhora
d’analista i programador en el mateix projecte. A més, el tipus de rol que
exerceix un empleat en un projecte no és permanent, sinó que pot canviar al
llarg del desenvolupament del projecte. Per exemple, una mateixa persona
pot ser cap de projecte per a dos projectes diferents, i més endavant es
promociona un dels analistes del segon projecte perquè el substitueixi com a
cap de projecte.
Cada vegada que una persona té un rol en un projecte, se li assigna un

nombre d’hores d’esforç que hi ha de dedicar. Així, per exemple, pot ser que
Joan Pérez sigui cap de projecte amb 50 hores d’esforç en el projecte 1, que
sigui analista en el projecte 2 amb 30 hores d’esforç i que, a més, sigui
programador en el projecte 2 amb 80 hores d’esforç.
L’objectiu del sistema és fer una estimació de costos dels projectes. A l’efecte
d’estimació de costos, cada rol té una tarifa fixa assignada. Per exemple, un
cap de projecte és de 2.500 € per P/M, mentre que un programador és de
1.500 € per P/M. (P/M = persona/mes, és a dir, el cost d’una persona que
treballa durant un mes en un projecte) (1 mes = 160 hores)
Es demana el diagrama UML amb les classes, atributs i relacions entre classes
necessàries per a modelitzar el càlcul del cost estimat d’un projecte.
Problema 5: jocs de tauler
Es vol dissenyar una aplicació que representi diferents jocs de tauler, com els
escacs (chess), les dames (draughts), els vaixells (battleship), etc. Tots
comparteixen una classe Board, que representa el tauler quadriculat clàssic de

dimensions N × M que s’utilitza per a jugar. El tauler dissenyat ha de ser vàlid
per a tots aquests jocs, que comparteixen la disposició de les caselles i la
manera d’accedir-hi amb un parell de coordenades. Els jocs en qüestió són
dissenyats en classes a part; una d’aquestes classes, anomenada Game, es
relaciona amb al tauler mitjançant una relació d’associació. El joc en qüestió
demana al tauler col·locar peces o fitxes a les caselles. Cada joc ofereix unes
peces de tipus diferent:
• Els escacs tenen rei (King), reina (Queen), torre (Rook), alfil (Bishop), cavall
(Knight) i peó (Pawn), i totes són de tipus ChessPiece i ocupen una casella.
• Les dames només tenen peces de tipus dama (Draught), que ocupen una
casella.
• El joc dels vaixells té fitxes de tipus vaixell (Ship), que tenen la

particularitat d’ocupar més d’una casella, totes adjacents. Hi ha fitxes de
mida 1 casella (pescamines o minesweeper), 2 caselles (fragates o frigate), 3
caselles (creuers o cruiser) i 4 caselles (portaavions o aircraft carrier).
Totes les peces, amb independència del joc, tenen un color per a identificar
el jugador al qual pertanyen.
El tauler ha d’incloure la modelització de la funcionalitat de col·locar una

peça en una casella i de comprovar si una casella del tauler està ocupada per
alguna peça. Tingueu en compte que, si les peces ocupen més d’una casella,
no es poden col·locar si surten del tauler.
Es demana dissenyar l’UML que inclogui les classes, associacions i atributs

necessaris per a modelitzar el tauler i les peces d’una manera reutilitzable per
als diferents jocs, i també modelitzar les operacions de col·locar una peça en
una casella i esbrinar si una casella del tauler està ocupada.
Problema 6: el futur de la Terra
Un viatger del futur ens ha plantejat resoldre el problema següent, basat en

les votacions terrícoles futures.
Se suposa que som al planeta Terra l’any 3010. En aquest temps, els robots
han evolucionat tant que ja fa anys que són considerats ciutadans, amb
gairebé els mateixos drets que els humans. A més, hi ha una nova
civilització, els Tcitizens, que conviuen amb els terrícoles.
La Terra està organitzada en BigCities, ciutats enormes. Els dirigents de les

BigCities consideren que els Tcitizens han de ser considerats ciutadans i han
de disposar dels drets que ja tenen persones i robots, entre els quals hi ha el
de poder participar en votacions de referèndums.
El govern de les BigCities es basa en referèndums setmanals, en què els

ciutadans són consultats sobre les qüestions que s’han de resoldre. Les
votacions es fan per mitjà d’una xarxa de comunicacions, en què cada
ciutadà pot votar: −1 (molt en desacord), 1 (molt d’acord), o 0 (abstenció).
Aquest sistema permet mesurar el grau d’acceptació o satisfacció dels
ciutadans davant d’una iniciativa del govern. El recompte és una mitjana
ponderada de totes les votacions (el vot dels robots es considera mig vot). El
vot no és totalment anònim, ja que es guarda en el vot el codi del ciutadà
(un codi de xifres i lletres). Aquest sistema es va fer així per a evitar que una
persona votés dues vegades (simplement comprovant que no hi ha dos codis
repetits en un referèndum). Cada vot inclou el dia i l’hora en què s’ha emès.
Els governants de la BigCity han convocat un referèndum als ciutadans

actuals amb la pregunta següent: “Els Tcitizens, han de ser considerats
ciutadans de la BigCity?”

Problema 7: reparació de calçat elReparador
Una petita empresa familiar de reparació de calçat, elReparador, conscient de

la crisi econòmica que afecta el país, ha decidit motivar els empleats
incrementant-los el salari segons els clients atesos i els clients nous.
L’empresa elReparador es vol centrar en una part de l’aplicació de gestió
d’empleats: la part responsable de l’increment dels sous.
Els empleats es divideixen en dos grups: els responsables d’atendre els clients
i arreglar el calçat, i els comercials, encarregats de captar nous clients.
Per als primers, s’incrementa el sou en euros (valor sencer), segons els clients
atesos. La fórmula de càlcul de sou és la següent:
sou_final = sou_base + nombre_de_clients * 2 euros
Per als altres, s’incrementa percentualment el sou segons les vendes del mes.
La fórmula de càlcul del sou per a les comercials és la següent:
sou_final = sou_ base + sou base*coeficient_de_vendes

mètodes que participen en el disseny de la funcionalitat requerida.
Problema 8: gestió de treballadors d’uns grans magatzems
Uns grans magatzems ens han encarregat una aplicació per a gestionar els
treballadors.
En aquesta empresa, hi ha diversos tipus de treballadors. D’una banda, els

venedors, que són els encarregats de fer tantes vendes com sigui possible, ja
que reben una petita comissió per cada venda. D’altra banda, els directius, que
es dediquen a monitorar el funcionament correcte de la seva àrea (organitzar
els venedors, triar els productes que es venen, dir on s’han de col·locar, etc.). A
més, cada directiu té un gestor administratiu que s’encarrega de les qüestions
jurídiques i administratives. Suposem que tant els gestors administratius com
els venedors tenen com a responsable un únic director.
De moment, i amb vista a ampliar el projecte aviat, ens han encomanat la

tasca de centrar-nos a calcular el sou dels treballadors.
El sou d’un gestor administratiu és fix (1.000 euros); els venedors, en canvi, amb
la finalitat de motivar-los per vendre tants productes com sigui possible, tenen
una part fixa de sou (900 euros) més unes comissions que representen un 5% de
l’import venut. Finalment, els directius cobren una base fixa (3.000 euros) més
una comissió de totes les vendes fetes pels venedors al seu servei (2%).
Al final de mes, el comptable de l’empresa vol obtenir una llista de tots els
treballadors de l’empresa, amb el número d’identificació fiscal i el sou que
han de cobrar, per a ingressar-lo en el número de compte corresponent.
Com que és previsible que apareguin nous tipus de treballadors, és necessari

que el sistema de llistats anterior sigui prou genèric per a no reimplementar
la gestió de la llista de sous, quan s’hi afegeixi un tipus de treballador, i que,
alhora, aquesta llista els inclogui.

Problema 9: BarCeloNA Nits De Festa
L’Ajuntament de Barcelona, després de molts anys d’organitzar esdeveniments

festius, vol externalitzar totes les tasques de gestió d’espais i permisos, de
manera que proposa crear una empresa (BCN_NDF) que s’encarregui de
gestionar totes les festes nocturnes que es facin a la ciutat i dotar-la, més
endavant, de recursos de seguretat i neteja (encara que això ja ho faran altres
aplicacions).
En principi, s’ha decidit dividir les festes segons les tendències musicals que
s’hi escoltaran, a fi de no posar massa properes tendències musicals
conflictives. S’ha decidit dividir els esdeveniments en: “festa popular”,

“discoteca” i “concert” (i es poden ampliar més endavant si és necessari). A
part, s’han de tenir emmagatzemats els recintes, amb una descripció, la
capacitat, l’adreça, etc. Cadascuna d’aquestes festes es fa en una localització,
que ha d’estar definida prèviament dins dels sistemes de BCN_NDF.
Cada festa té un organitzador, que és l’encarregat de fer totes les peticions a

BCN_NDF. Per a cadascuna de les festes es poden contractar un conjunt de
serveis; per exemple, neteja del recinte, muntatge de l’escenari, etc.
Cadascun d’aquests serveis té un cost associat que, en principi, no varia al
cap d’un temps (per simplificar el model). Aquests serveis es poden
contractar en qualsevol moment fins que l’esdeveniment ja s’ha produït.
En cas que passi algun incident, es vol registrar, ja que llavors, per a
convocatòries vinents del mateix organitzador, es poden denegar peticions o
establir condicions més restrictives.

Problema 10: la biblioteca
La biblioteca del nostre poble vol informatitzar tot el procés de préstec de

llibres i revistes que té (actualment, s’utilitzen fitxes per a cada exemplar i
porten tota la gestió amb paper i llapis).
Per això, ens han demanat que els ajudem, de manera que hem estat una
setmana al seu costat per captar-ne la manera de fer i oferir-los un programa
que s’adapti ben bé a les seves necessitats.
Hem detectat que cada exemplar de llibre, revista, pel·lícula –tant en VHS
(encara en tenen i els socis els en demanen) com en DVD– té una etiqueta amb
un identificador. Per a cada identificador, tenen una fitxa amb unes dades
característiques de l’exemplar corresponent (per exemple, dels llibres tenen el
nombre de pàgines i l’edició; de les revistes, l’editorial i el número, el mes i
l’any; de les pel·lícules, el format, la durada i, en el cas dels DVD, els idiomes).
Dels socis tenen, en unes fitxes a part, les dades de contacte i l’historial de
préstecs que ha fet cadascun d’ells (per a cada préstec guarden la data d’inici,
la de final i si hi va haver retard en la devolució).
Addicionalment, i gràcies a les noves tecnologies, volen fer cerques (i imprimir

llistes), tant pels autors dels llibres i els articles que apareixen a les revistes (que
també hem d’introduir) com pels actors que apareixen a les pel·lícules.

Problema 11: l’agenda del banc
Una entitat bancària vol mantenir una agenda de les reunions i cites amb
clients que tenen els empleats. De cada esdeveniment es vol saber la data,
l’hora d’inici i la durada.
Les reunions són per a fer feines dins dels diferents grups de treball instaurats
al banc, i les cites són peticions que fan els clients per a qualsevol mena de
consulta sobre els seus comptes.
Els clients demanen les cites amb antelació i, més endavant, l’empleat
l’accepta o rebutja segons la seva disponibilitat (aquesta resposta es notifica
al client mitjançant el correu electrònic). Les cites rebutjades s’eliminen del
sistema. Les cites acceptades afegeixen un camp de text amb el nom de la
sala on s’han de fer.
A part, l’empleat pot donar d’alta una cita directament si el client es presenta
a l’oficina sense cita prèvia.
Les reunions són convocades per un empleat, el qual introdueix una cadena
de text amb el tema que s’ha de tractar i l’envia als diferents assistents, que
han d’acceptar la petició igual que fan amb les cites dels clients.
Els empleats es troben en oficines, de manera que les cites únicament poden
ser de clients de les seves oficines; les reunions no tenen en compte aquesta
restricció, ja que hi pot haver grups de treball de diferents oficines.
Un empleat no pot tenir una reunió i una cita alhora, per la qual cosa a
l’hora de confirmar qualsevol esdeveniment s’ha de comprovar que no n’hi
ha cap a la mateixa data i hora (sense confirmar, hi pot haver tants
esdeveniments com es vulgui alhora).
Addicionalment, s’han de poder fer llistes per a obtenir els calendaris de cada
empleat (diaris, setmanals i mensuals), i també resums del temps emprat en
cada d’esdeveniment.

Problema 12: editorial de col·leccionables
Una editorial comença a tenir problemes amb la distribució dels productes.

Fins al moment, es distribuïen únicament als quioscos, però ara, amb
l’apogeu d’Internet, els clients poden fer les comandes pel portal web de
l’editorial.
Els clients han de poder fer les comandes als quioscos (dels quals
emmagatzema l’adreça i el telèfon per confirmar els lliuraments), i per Inter-
net (en aquest cas, l’adreça és la de cada client per a enviar-los els productes
directament). Per a facilitar-ne la gestió, els clients únicament poden estar
inscrits en un dels dos mètodes de distribució.
Els productes disponibles són col·leccions que estan formades d’un conjunt
de productes (llibres, jocs, etc.), tots del mateix tipus. De cada producte cal
guardar les dades bàsiques (dels llibres, el títol i l’autor; dels jocs, la
plataforma i el tipus de suport, etc.).
A més, es necessita fer qualsevol operació d’alta, baixa i modificació dels

productes i de les col·leccions (en aquest cas, no es poden modificar a partir de
la data de publicació), i també de la subscripció dels clients a les col·leccions.
Addicionalment, per a cada client es necessita consultar l’adreça de lliurament i

les col·leccions a què està subscrit, i també el darrer exemplar enviat.

Problema 13: el lector de correu electrònic
Volem desenvolupar un programa lector de correu, però, abans de

desenvolupar tota la part de comunicacions i representació de la informació,
volem tenir clar el model que emprarem per emmagatzemar les dades.
L’aplicació ha de permetre rebre missatges de diferents comptes, de manera que

per a cada compte s’han de definir els diferents paràmetres d’accés (nom i
contrasenya). Recordem que els comptes són principalment de dos tipus (POP3 i
IMAP), però d’aquí a un temps s’hi poden afegir altres comptes com els WebMail.
Els missatges contenen informació com l’origen, el destí, la capçalera i el cos:

una vegada baixats dels servidors, els missatges s’emmagatzemen en una de
les bústies que hi ha.
Cada bústia pot tenir diferents carpetes (i subcarpetes) per a emmagatzemar

els missatges. Les bústies s’identifiquen per un nom i una localització, i
contenen informació sobre els missatges que hi ha emmagatzemats (el
nombre, la mida i els missatges sense llegir).
Per a facilitar el tractament dels missatges, s’ha de permetre definir uns filtres
perquè els missatges s’emmagatzemin directament en una carpeta. De cada
filtre necessitem saber el nom, el filtre i si està actiu o no.

Problema 14: l’escola de primària
La direcció d’una escola de primària ens ha encarregat que gestionem una

aplicació informàtica. Una vegada fet un petit estudi, disposem de la
informació següent:
1) Hi ha quatre estadis en l’educació primària: educació infantil, cicle inicial,

cicle mitjà i cicle superior. De tots aquests estadis, hem de disposar de les
dades de l’alumne (nom, cognoms, vacunació) i de la seva informació
familiar (domicili, nom del pare i de la mare i un telèfon de contacte).
2) Addicionalment, dels alumnes d’educació infantil i cicle mitjà, a causa de

la seva edat, hem de disposar de les dades del seu pediatre (nom, cognoms,
telèfons), a fi que si hi ha qualsevol problema (encara que sigui petit) li
puguem trucar.
3) Dels professors cal guardar informació personal: document d’identitat,

nom, cognoms, telèfon, titulació, especialitat i antiguitat.
4) Els professors de l’escola tenen associat un nombre d’infants (que

anomenem aula) i cadascun d’aquests infants té assignada, alhora, una aula.
Considerem que, en una aula, no hi pot haver més de 30 alumnes.
5) De les aules cal guardar un identificador, el curs, el nom d’una espècie

animal (als infants els agrada) i el nom de la planta on està ubicada. No hi ha
canvis de professors o infants en una aula; una vegada assignats, són
permanents.

Problema 15: oh, no!, més futbol!
Amb previsió d’una competició futbolística estiuenca, l’organització gestora

dels estadis on s’han de jugar els partits vol fer una aplicació web per a
guardar les dades més rellevants de cada partit i, així, vendre les estadístiques
als diaris nacionals.
Es volen saber les estadístiques dels partits jugats, els equips i jugadors que
han jugat, quins equips ho han fet de locals i quins ho fan de visitants, i el
nombre de gols per partit.
Per a poder oferir aquestes estadístiques, el sistema ha de gestionar les dades

de dos tipus d’empleats: els taquillers i els agents de seguretat. D’aquest dos
tipus es necessita guardar el nom, els cognoms, el document d’identitat,
l’adreça, el telèfon de contacte i el número de la Seguretat Social. Dels
taquillers es necessita saber, a més, el número de taquilla que tenen
assignada. Dels agents de seguretat ens interessa saber, a més, a quina part
del terreny de joc estan assignats.
De cada partit ens cal guardar la data en què es juga, quin equip juga com a
local i quin equip juga com a visitant, el marcador final i quins jugadors han
marcat durant el partit.
Dels equips ens interessa guardar el nom i la llista de jugadors. I dels

jugadors hem de guardar el nom, els cognoms, el document d’identitat,
l’adreça, el telèfon de contacte, el dorsal i l’equip en què juguen.
Es demana un diagrama de classes UML que modeli el problema anterior i

que identifiqui els mètodes necessaris per a fer una llista dels equips que han
jugat com a locals en un estadi, ordenats alfabèticament.
Problema 16: Caribbean Resorts, SA
L’empresa espanyola Caribbean Resorts, SA ha construït un hotel balneari a

la República Dominicana i ens ha encarregat que dissenyem un programari
per a portar-ne la gestió.
Aquest hotel, anomenat Fiesta Beach, funciona en règim de TI (tot inclòs),

amb l’excepció de les activitats concertades que el client vulgui contractar,
que es paguen a part.
L’hotel és un concepte innovador respecte a l’oferta d’allotjaments. Està

format, d’una banda, d’edificis d’habitacions i, de l’altra, de vil·les petites per
a l’ús exclusiu d’un únic client (amb la família o els amics). Tots els
allotjaments s’identifiquen per un codi d’allotjament i tenen establert un
determinat preu base per dia. Totes les habitacions són dobles i el preu diari
correspon al seu preu base. El preu diari d’una vil·la es calcula segons el preu
base i el nombre de persones.
L’hotel vol portar un registre dels clients. Així, de tots els clients cal
emmagatzemar les dades següents: número d’identificació fiscal, nom i
adreça. Es vol aplicar una política de descomptes als clients. En aquest sentit,
l’hotel distingeix dos tipus de clients:
• D’una banda, els clients estàndard. A aquests clients se’ls aplica un

percentatge de descompte sobre la factura, segons el cost que han acumulat
en estades anteriors. Per tant, cal mantenir actualitzada aquesta dada.
• D’altra banda, tenim els clients vip. Per a aquests, el descompte es cal-
cula segons els anys que fa que són vips. Per tant, cal saber l’any en
què l’hotel va atorgar a aquest client el tracte de vip.
L’hotel ofereix als clients activitats que poden contractar. Les activitats són
de dos tipus: individuals o paquets. Per a qualsevol activitat s’ha
d’emmagatzemar un codi d’identificació i una petita descripció de l’activitat.
Totes les activitats són de pagament.
Les activitats individuals tenen un preu fix establert. Els paquets estan
constituïts d’activitats individuals (existents prèviament) que es contracten
de manera conjunta. Un client només pot contractar els paquets que ofereix
l’hotel (és a dir, no pot fer paquets a la carta). El preu d’un paquet es calcula
com la suma de preus de les activitats individuals que el componen, però s’hi
aplica un descompte segons el nombre d’activitats que tingui.
L’hotel també vol dur a terme la gestió de les reserves d’allotjament que
vulguin fer els clients. En el moment de fer la reserva, s’emmagatzemen les
dades següents:
• Codi d’identificació.
• Client que fa la reserva.
• Allotjament associat.
• Data de començament de l’estada.
• Data d’acabament de l’estada.
Durant l’estada del client a l’hotel, es poden afegir a la reserva les dades
següents:
• Relació d’activitats contractades pel client durant l’estada.
• Reserva tancada. Quan la reserva està tancada, no s’hi pot fer cap més
modificació. Això s’utilitza per a saber que, a partir d’aquell moment, es
pot generar la factura associada a la reserva.
Les operacions més comunes que es pensen fer aplicant aquesta gestió
hotelera són les següents:
• Afegir una reserva a l’hotel: obrir una reserva. S’ha d’especificar client,
dates d’entrada i de sortida i allotjament concret (no una categoria
d’allotjament).
• Accés a una reserva. a partir del número d’identificació fiscal del client i
la data d’entrada, l’operació torna totes les dades de les reserves associades
al client.
• Operacions sobre reserves (l’especificació de la reserva es fa mitjançant el

seu codi): cancel·lar, afegir activitat, tancar.
• Llistar la relació completa d’allotjaments de l’hotel.
• Llistar la relació completa de clients de l’hotel.
• Llistar la relació completa d’activitats de l’hotel.

• Llistar la relació d’allotjaments lliures entre dues dates, per a una
categoria específica d’allotjament (habitació o vil·la).

Problema 17: aeroports VolaSA
El nou pla director d’aeroports de l’Estat preveu crear un conjunt important

d’aeroports secundaris per donar resposta a les necessitats de transport aeri
de càrrega i passatgers, i també als vols lúdics.
L’empresa VolaSA s’encarrega de gestionar un aeroport secundari a Osuna, i

ens ha encarregat que creem una aplicació que permeti gestionar les
peticions d’ús de l’espai aeri de l’aeroport.
Aquesta aplicació ha de disposar de les funcionalitats següents:
• Cada vegada que se sol·licita la confirmació d’un pla de vol, l’aplicació

determina si l’aparell pot aterrar a l’aeroport. En general, s’accepta el pla
de vol si, en el mateix moment de l’aterratge, no hi ha més de dos vols
amb pla de vol acceptat que han sol·licitat aterrar a la mateixa hora.
• L’aplicació ha de permetre calcular les taxes que han de pagar les

companyies aèries segons el pes transportat, el tipus d’aparell, els metres
de pista necessaris per a fer l’aterratge, i també l’experiència del pilot, i
l’ús de la terminal per part dels passatgers.
• L’aplicació ha de permetre portar un registre de tots els pilots i aparells de

vol. Un pilot pot portar qualsevol tipus d’aeronau.
Els aparells que poden aterrar a l’aeroport que dissenyem són avions de línia
regular i helicòpters.
La informació que necessitem per a cadascun dels aparells és la següent:
• Un codi identificador de l’aparell: s’utilitza, principalment, per a poder

determinar els costos de cada aparell de vol separadament.
• El consum de combustible per hora: s’utilitza per a poder estimar la

quantitat de combustible que necessitem tenir emmagatzemat en els
dipòsits de l’aeroport.
Els avions de línia regular es poden utilitzar pel transport de mercaderies

(càrrega), o bé pel transport de passatgers. Dels avions ens interessa saber, a
més, el següent:
• La càrrega que transporta, especificada en quilograms: s’utilitza per a
calcular el cost de l’aterratge. Les fórmules que s’utilitzen per a avaluar el
desgast de la pista en l’impacte de l’aterratge sempre consideren el pes de
l’aparell.
• El volum de l’aparell: les fórmules que calculen el cost de l’aterratge tenen

en compte els metres de pista necessaris per a l’operació d’aterratge. En
aquest sentit, les fórmules també necessiten saber el volum que ocupa
l’aparell.
Els helicòpters són aparells que s’utilitzen, principalment, per a la campanya

forestal i per a emergències. Ens interessa saber, a més, el següent:
• Si l’operació d’aterratge obeeix a una activitat d’una emergència.
• El nombre de motors de l’helicòpter.
Respecte al pla de vol, ha de preveure la informació següent:
• La data i l’hora d’aterratge a l’aeroport.
• La informació de l’aparell de vol, i també un identificador del pla de vol.
• La durada del vol: s’utilitza per a poder estimar la quantitat de combustible

que necessitem tenir emmagatzemada als dipòsits de l’aeroport.
• El pilot: per a avaluar el cost de l’aterratge, s’utilitza com a paràmetre les

hores de vols que ha acumulat el pilot.
Finalment, dels pilots volem saber el nom, el document d’identitat, el nombre

d’hores de vol acumulades, i també el nombre d’aterratges que han fet.

Problema 18: vols AirUOC
L’aerolínia AirUOC és una companyia a petita escala, encarregada dels vols

regulars i contractats d’una zona geogràfica determinada. Per actualitzar-ne el
sistema de gestió de personal, avions, vols autoritzats i passatgers, ens demanen
que dissenyem una aplicació que compleixi els requisits que es detallen a
continuació.
AirUOC fa dos tipus de vols: els vols regulars i els vols contractats. Els vols
regulars són vols amb rutes predefinides, codificades amb un codi numèric.
Aquests vols tenen una sortida periòdica, i el preu per passatger és fix i
independent del nombre de passatgers de l’avió. En els vols regulars, com en la
majoria de companyies aèries, hi ha dues modalitats de vol: classe preferent,
més còmoda però més cara, i classe turista, un 30% més econòmica que
l’anterior. La segona tipologia de vols, els vols contractats, es basen a llogar un
avió, generalment d’un nombre petit de passatgers, per fer un viatge en una
data i hora concretades. En aquest cas no hi ha ruta predefinida, sinó que
s’estableix l’origen, la destinació i les escales del vol, i a partir d’aquesta
informació i del nombre de viatgers es fixa el preu que ha de pagar cada
passatger. En aquest cas sempre s’estableix una tarifa única, classe preferent.
De cada vol és necessari emmagatzemar, addicionalment, el codi del vol,

format de dues lletres i quatre xifres, l’hora de sortida, la durada i si és
nacional, europeu o internacional. Tots els preus s’estableixen en euros.
Cada vol està associat a un avió. D’un avió és necessari emmagatzemar la

llista de tripulants (hostesses i pilots), els passatgers i el nombre de butaques
per a passatgers de classe preferent i classe turista.
El sistema també ha d’emmagatzemar les dades dels passatgers: nom i

cognoms, número de passaport, adreça i si viatgen en classe preferent o en
classe turista. De fet, els responsables d’AirUOC han explicitat que, els propers
anys, no es preveuen altres opcions que no siguin classe preferent i classe
turista.
En el cas de la tripulació dels avions, s’emmagatzema el nom i els cognoms,

el número de passaport, l’adreça postal i el sou mensual. El sou mensual dels
pilots d’aviació depèn del nombre d’hores de vol fetes. El sou de les hostesses
depèn de les hores de vol fetes i del nombre d’idiomes que parlen
correctament. Tots els sous es calculen en euros.
El sistema ha de permetre gestionar els passatgers i la tripulació. En concret, ha

de permetre donar d’alta passatgers i tripulants. També ha de permetre generar
les llistes d’una determinada tipologia classe preferent / classe turista per vol.

Problema 19: treballadors UOCfridge
La botiga d’aliments congelats UOCfridge, aprofitant que expandeix el

negoci, ens ha demanat una aplicació que faciliti gestionar les vendes i pagar
el sou als treballadors. Ens proporciona l’anàlisi de requeriments següent.
Tots els productes s’envasen i es venen unitàriament. Cada producte té

associat un codi de barres i un preu unitari. Els preus es proporcionen en
euros.
Respecte als empleats, majoritàriament són venedors, però el propietari ens

ha dit que hi ha altres tipus d’empleats (per exemple, els encarregats del
magatzem), però que s’estima més que en el sistema actual no es tinguin en
compte, encara que s’hi puguin afegir més endavant. Dels venedors és
necessari saber el nom i els cognoms, el document d’identitat, l’adreça
postal, el número de la Seguretat Social i el sou. El sou dels venedors es
calcula a partir del sou base, més un percentatge de vendes.
Tots els clients de la botiga es registren en el sistema gràcies a la targeta

client, que els permet accedir a descomptes i a promocions addicionals. De
cada client es guarda el nom i els cognoms, el document d’identitat i l’adreça
postal. Si un client es deixa la targeta a casa, s’identifica a partir del
document d’identitat.
Cada venda es registra en una factura, amb el document d’identitat del client,
el número d’identificació fiscal del venedor i la llista de productes comprats.
L’import de la venda es calcula a partir del preu dels productes llistats a la
factura. Aquest registre de factures s’organitza de manera que es pugui saber,
d’una factura, tota la informació associada. A més, s’han d’obtenir totes les
factures que corresponen a les compres d’un client. Finalment, s’han de poder
consultar totes les factures que corresponen a les vendes d’un venedor.
El sistema ha de permetre, addicionalment, donar d’alta treballadors, clients,

productes, vendes, calcular el sou dels empleats i la totalització de les vendes.

Problema 20: hospital central
El gerent d’un hospital ens ha encomanat la gestió dels recursos de l’hospital

per part de les companyies mèdiques o de particulars, amb l’objectiu de
facturar correctament l’atenció mèdica que reben els malalts que hi

acudeixen.
Un dels aspectes que es vol controlar és la gran quantitat de moviments que

han de fer els pacients ingressats a les habitacions per a accedir als recursos
estàtics següents: la sala de raigs X i la sala d’operacions. En el cas de la sales de
raigs X, l’hospital hi ha d’assignar una infermera per a l’ús correcte. En el cas
de les sales d’operacions, l’hospital ha d’assignar sempre tres infermeres a cada
operació i la companyia mèdica ha d’aportar els seus metges.
En el transport d’un pacient, poden ser necessaris alguns dels recursos

dinàmics següents: crosses, cadira de rodes o llitera. En el cas d’una cadira de
rodes, el transport d’un pacient requereix més d’un zelador i, si es tracta
d’una llitera, el transport requereix un zelador i una infermera.
Per obtenir una avaluació fiable dels costos que comporta un pacient, el
gerent ens demana que implementem una aplicació que permeti avaluar, al
final del dia, l’ocupació dels recursos, l’ús dels recursos de transport i els
recursos estàtics generats per cada pacient, i la informació dels pacients que
ha considerat cada infermera.
En l’avaluació de l’ocupació de recursos, es vol obtenir el document

d’identitat del pacient, el temps d’ocupació i el document d’identitat del
personal de l’hospital necessari. Per a cada recurs, a més, és necessari
l’identificador i l’any de compra. Per als recursos estàtics, es necessita, a més,
el nom de la companyia mèdica que es fa càrrec de les despeses generades.
També s’han de proporcionar les operacions necessàries per a donar d’alta i

donar de baixa infermeres, pacients i zeladors.

Problema 21: transports TransUOC
L’empresa de transports TransUOC, dedicada a transportar mercaderies, ens

ha encarregat que creem una aplicació que permeti gestionar les comandes
que reben. La informació bàsica d’una comanda consta de la distància entre
el punt d’origen i el punt de destinació, i el pes de la càrrega que s’ha de
transportar.
L’aplicació ha de permetre determinar, cada vegada que arribi una comanda,

si es pot cobrir amb els vehicles disponibles. A més, ha de gestionar quin
vehicle s’utilitza per a transportar la càrrega i, així, seleccionar el més
adequat en cada cas, i ha de calcular el preu del transport de les mercaderies

segons els quilòmetres recorreguts, el pes transportat i el vehicle utilitzat.
La informació necessària corresponent a un vehicle consta d’un codi

identificador, la càrrega en quilos que transporta, el consum per cada 100
quilòmetres, la capacitat màxima de càrrega, la velocitat mitjana a què circula,
el cost bàsic d’ús del vehicle, la taxa predefinida que es paga cada vegada que
s’utilitza el vehicle i el tripulant o tripulants necessaris per a conduir-lo.
Els vehicles poden ser de tres tipologies diferenciades: terrestres, aeris o

marítims. Els vehicles terrestres són els que circulen per carretera. D’aquests
vehicles és necessari saber la potència del motor. Per a monitorar quan és
necessari fer les revisions corresponents, també és necessari emmagatzemar
el nombre de quilòmetres recorreguts. S’ha de tenir constància també del
nombre d’avaries del vehicle i el cost total de reparació. Els vehicles aeris
corresponen als avions de què disposa l’empresa per als seus transports. Les
característiques necessàries per a aquests vehicles són el nombre de motors i
l’antiguitat del vehicle. Els vehicles marítims són els corresponents als
vaixells que té l’empresa. Les característiques que s’han de guardar d’aquests
vehicles són l’antiguitat i la data del darrer embarcament.
Les comandes han d’indicar si el transport es pot utilitzar per mar o no i si és

urgent o no. L’assignació de vehicles a comandes es fa de manera que
s’utilitzin tants pocs recursos com sigui possible per a servir-los. És a dir, es
trien els vehicles de més capacitat de càrrega per a atendre la comanda. En
cas que la comanda sigui urgent, la prioritat la tenen els vehicles ràpids,
encara que l’assignació de càrregues no sigui òptima. Una vegada triat el
vehicle més apropiat, totes les càrregues corresponents a una comanda es
transportaran únicament amb aquest vehicle.
El cost total d’una comanda es computa com la suma del quilometratge fet i
el cost generat pel vehicle. Aquest darrer cost es basa en les característiques
pròpies del vehicle prèviament definides (consum, cost bàsic d’ús, taxa
predefinida, taxa tripulant / tripulants necessaris).

Problema 22: VideoMagic
L’empresa VideoMagic, dedicada al préstec per mitjà de terminals de 24

hores de llibres, vídeos, CD i llibres, ens ha encarregat que dissenyem una
aplicació informàtica que gestioni el negoci.
La informació característica dels productes consta de l’identificador, l’autor,

el títol, l’empresa de producció, la data de sortida al mercat, el nombre
d’exemplars disponibles, el codi d’ubicació al magatzem, el número de
volum i la descripció.
Els productes es classifiquen en llibres, vídeos i CD, amb les característiques

pròpies que s’especifiquen a continuació:
• La informació específica que s’ha d’emmagatzemar d’un llibre correspon

al nombre de pàgines i al tipus de contingut (novel·la, aventures,
policíaca, viatges, etc.).
• Dels vídeos s’ha de guardar el temps de durada i el tipus de contingut

(vídeo documental, pel·lícula, etc.).
• Es consideren tres tipologies de CD. Els CD compactes, que són els típics
CD de música; els CD-ROM, que són CD amb jocs d’ordinador; i els DVD,
que reuneixen les característiques dels vídeos i dels CD-ROM. De cada CD
s’ha d’emmagatzemar la caràtula i el codi de barres. Dels CD de música
s’ha d’emmagatzemar, a més, el nombre de cançons i el temps total. Dels
CD-ROM s’hi ha d’afegir els megabytes d’informació que contenen. Dels
DVD, la informació relativa al menú de contingut disponible.
Es vol que, des del terminal de préstec, es puguin fer els préstecs de
productes i que es pugui indicar el codi del client, el saldo actual,
l’identificador del producte i la data de devolució del producte. També s’ha
de considerar la possibilitat de fer una consulta, que ha de retornar tota la
informació rellevant del producte i indicar si hi ha exemplars disponibles per
al préstec o no.
No es descarta que, més endavant, s’afegeixin noves tipologies de productes

en préstec, de manera que l’aplicació s’ha de dissenyar tenint en compte
aquest fet. També s’ha de tenir en compte que l’aplicació ha de gestionar tots
els usuaris del sistema en la pròxima ampliació del projecte.


Uml

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml

Uploaded by

Copyright:

Available Formats

Problemes

Part I. El procés de modelització..................................................... 7

Part II. Problemes resolts .................................................................. 11

Part III. Problemes proposats (sense solució) .............................. 72

La motivació principal d’aquest material didàctic sorgeix de la necessitat de

Aquests materials s’estructuren de la manera següent:

• En la primera secció, introduïm la metodologia elemental de

• Seguint aquesta metodologia, la segona secció mostra 21 problemes de

• Finalment, la tercera secció conté una llista de 22 problemes sense solució

Part I. El procés de modelització

Per a crear un diagrama de classes a partir de la descripció d’un problema

El procés per a crear un model de classes, malgrat que no és matemàtic, es

1) Identificació de les classes

Consisteix a seleccionar els substantius i les frases nominals que conformaran

El resultat d’aquesta fase és obtenir una llista de classes que conformaran el

2) Creació del model de dades

3) Inclusió d’atributs i mètodes

4) Inclusió de la cardinalitat i navegabilitat de les relacions

Finalment, completarem el diagrama indicant el nombre màxim i mínim

Per a millorar el diagrama de classes obtingut, és aconsellable aplicar aquest

L’Associació d’Antics Alumnes de la UOC ens ha demanat si els podem

Els associats es poden dividir en membres numeraris i en membres de la junta

La convocatòria d’un esdeveniment es fa per correu electrònic a tots els

En la convocatòria, també apareix informació sobre el lloc, que sovint és el

1) Identificació de les classes

• Membre (o membre numerari) (Member)

Addicionalment, s’hi ha afegit la classe Persona (Person) per a poder

2) Creació del model de dades

Per a crear el model de dades, s’ha detectat l’existència d’una jerarquia

reunions de la junta directiva. En aquest problema, s’ha descartat la inclusió

Alhora, hi ha la jerarquia següent entre els membres de l’associació:

A més, tenim les classes Localització (Location) i Associació (AAUOC), que es

3) Inclusió d’atributs i mètodes

L’associació necessita els mètodes per a

(mètode register, que ha d’emmagatzemar Event

Conference BoardMeeting BoardMember

4) Inclusió de la cardinalitat i max_attendees : Integer

navegabilitat de les relacions

En el diagrama següent, s’han eliminat

0..* 0..* 0..*

Part II. Problemes resolts

Problema 1: aplicació de professorat

Es demana el diagrama UML que inclogui les classes, relacions, atributs i

1) Identificació de les classes

• Professor intern (InternalTeacher)

2) Creació del model de dades

Per a crear el model de dades, s’ha detectat l’existència d’una jerarquia

A part, tenim les classes Empresa (Company) i Classe (Class), que es

3) Inclusió d’atributs i mètodes

newClass(c : Class) : void

name : String name : String

baseSalary : Double variableSalary : Double

4) Inclusió de la cardinalitat i navegabilitat de les relacions

En el diagrama següent, s’han eliminat els mètodes i s’han inclòs les

demana que el professor extern sàpiga en quina empresa treballa, però no

L’empresa de telefonia mòbil UOCphone vol llançar una campanya de fide-

• El segon sistema és per als clients en modalitat de prepagament, als quals

En el primer cas, els punts s’associen a l’individu, de manera que, si té més

Cada línia de telefonia mòbil amb contracte té una modalitat de tarifació

El sistema ha de registrar totes les trucades de sortida, i ha d’incloure l’hora

Es demana el diagrama UML que inclogui les classes, associacions, atributs i

1) Identificació de les classes

• Línia de telefonia mòbil (Line)