Beruflich Dokumente
Kultur Dokumente
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
Introducció
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.
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).
Exemple d’aplicació
Solució:
Event
Conference BoardMeeting
Person
Member
BoardMember
AAUOC
Person
Location
Event
Member
Conference BoardMeeting
BoardMember
© FUOC • PID_00145181 10 Problemes de modelització amb UML
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).
attendsTo
AAUOC
0..*
Person
0..*
0..*
Location attendsTo
1 0..*
isLocatedIn
Conference BoardMeeting
BoardMember
0..*
0..* attendsTo 0..*
attendsTo
© FUOC • PID_00145181 11 Problemes de modelització amb UML
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.
Solució:
Teacher
InternalTeacher ExternalTeacher
© FUOC • PID_00145181 12 Problemes de modelització amb UML
UOC
Company
Class
Teacher
InternalTeacher ExternalTeacher
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
Class
Teacher Company
getSalary() : Double
Class Teacher
Company
InternalTeacher ExternalTeacher
UOC
0..*
0..*
0..* Company
Class
Teacher
0..* 0..*
0..*
InternalTeacher ExternalTeacher
© FUOC • PID_00145181 14 Problemes de modelització amb UML
Problema 2: UOCphone
• El primer sistema és per als clients que tenen contracte, dels quals es
coneix un número de client.
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.
Solució:
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.
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.
<<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
1
holds ContractLine PrepayLine
1..*
contractRateFrame : RateFrame credits : Integer
© FUOC • PID_00145181 17 Problemes de modelització amb UML
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:
© FUOC • PID_00145181 18 Problemes de modelització amb UML
PersonnelRole
1
Docent Administrative
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.
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.
PersonnelRole
1
getSalary()
Docent Administrative
getBaseSalary() getBaseSalary()
getVariableSalary() getVariableSalary()
© FUOC • PID_00145181 20 Problemes de modelització amb UML
Solució:
La classe Complex es relaciona amb la classe Point mitjançant una relació d’ús.
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
© FUOC • PID_00145181 22 Problemes de modelització amb UML
Solució:
• Figura (Figure)
• Cercle (Circle)
• Rectangle (Rectangle)
• Triangle (Triangle)
• Quadrat (Square)
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
© FUOC • PID_00145181 24 Problemes de modelització amb UML
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).
Solució:
• Docent (Instructor)
• Classe (Class)
• Estudiant (Student)
• Becari (Assistant)
Assistant
-in : Instructor
© FUOC • PID_00145181 26 Problemes de modelització amb UML
Problema 7: OilCompany
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.
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.
Solució:
OilCompany
• Gasolina (Petrol)
• Gasoil (DieselOil)
© FUOC • PID_00145181 27 Problemes de modelització amb UML
OilProduct
-id : Integer
-gallon : Integer
-octane : Integer
-buyCost : Integer
OilCompany
1 1..* computeProfits() : float
name : String computeCost() : float
Petrol
DieselOil
-saleCost : Integer
-saleCost : Integer
+computeCost() : Float
+computeCost() : Float
© FUOC • PID_00145181 28 Problemes de modelització amb UML
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.
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.
Solució:
Tool
name : String
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.
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
0..*
Comercial Free Development
0..*
price : int basePrice : int
© FUOC • PID_00145181 31 Problemes de modelització amb UML
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.
Solució:
• Cotxe (Car)
• Motocicleta (Motorbike)
• Furgoneta (Van)
• Camió (Truck)
• Client Casual (Casual)
• Client de Leasing (Leasing)
• Empresa (Company)
• Lloguer (Rental)
© FUOC • PID_00145181 32 Problemes de modelització amb UML
Addicionalment, hi hem afegit la classe MoveFast per poder partir d’un punt
d’interrelació de totes les entitats.
MoveFast
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
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.
MoveFast
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
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).
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)
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..*
TravelAgency
Reservation
state : int
Service Customer
TravelAgency
Reservation
state : int
Trip
Customer BusinessCustomer
price : double
1..*
available : int name : String bancAccount : String
0..* 0..* address : String
DNI : String
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
© FUOC • PID_00145181 37 Problemes de modelització amb UML
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.
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.
Solució:
• Vehicle (Vehicle)
• Empleat (Employee)
• Comercial (Salesman)
• Conductor (Driver)
• Oficina (Office)
• Trasllat (VehicleTransfer)
• Cotxe (Car)
• Motocicleta (Motorbike)
• Furgoneta (Van)
• Camió (Truck)
© FUOC • PID_00145181 38 Problemes de modelització amb UML
Addicionalment, hi hem afegit la classe MoveFast per poder partir d’un punt
d’interrelació entre totes les entitats.
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).
MoveFast
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
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).
Solució:
• Peça (Part)
• Model (Model)
• Peça del Model (ModelPart)
• Reparació Estàndard (Repair)
• Client/Vehicle (Client)
• Reparació “Efectiva” (RepairPart)
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.
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).
Workshop
0..* 0..*
Client
Repair
0..* 0..* plate : String
description : 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
© FUOC • PID_00145181 42 Problemes de modelització amb UML
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:
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
© FUOC • PID_00145181 43 Problemes de modelització amb UML
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)
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.
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.
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).
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.
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
OrderLine
Book CdRom
getPages() getSize()
setPages() setSize()
© FUOC • PID_00145181 46 Problemes de modelització amb UML
• 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.
Solució:
• Hemeroteca (Library)
• Usuari (User)
• Llibre (Book)
• Revista (Magazine)
• Monogràfic (Monography)
• Document (Document)
• Préstec (Loan)
Finalment, hi ha una classe Loan entre User i Document, que permet gestionar
els préstecs.
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
borrowDoc(d : Document)
listLoans()
0..*
Book Magazine
0..* author : String volume : Integer
title : String number : Integer
price : Double
0..*
Monography
author : String
title : String
© FUOC • PID_00145181 49 Problemes de modelització amb UML
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.
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.
© FUOC • PID_00145181 50 Problemes de modelització amb UML
Solució:
• Producte (Product)
• Equip Informàtic (Computer)
• Dispositiu (Device)
• DVD
• Comanda (Order)
• Client (Customer)
• Majorista (WholeSaler)
• Proveïdor (Supplier)
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).
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.
1 Store
0..*
Supplier Customer 1
0..* 1
id : String id : String
name : String name : String
address : String address : String 1
1 cost : Double
WholeSaler
computeCost()
0..* discount : Double
supplies
Product 0..*
0..50
id : String 0..*
name : String
stock : Integer
price : Double
quantity : Integer
computeCost()
Computer Device
processor : Enum
ramMb : Integer
diskGb : Integer
DVD
© FUOC • PID_00145181 52 Problemes de modelització amb UML
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.
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.
Solució:
• Editorial (Kot)
• Cotxe (Car)
• Material (Material)
• Persona (Person)
• Treballador (Worker)
• Client (Customer)
• 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.
© FUOC • PID_00145181 54 Problemes de modelització amb UML
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.
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.
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
description : String
concept : String
date : Date
refersTo
1
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.
• El nom de la línia.
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.
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)
© FUOC • PID_00145181 58 Problemes de modelització amb UML
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).
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.
Els tickets (Ticket) estan formats de tres atributs (identificador, data de l’avaria
i data de la reparació).
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-
© FUOC • PID_00145181 59 Problemes de modelització amb UML
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.
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()
description : String
estimated : Date 1 1
1 involves TicketStatus
plate : String
NEW_INCIDENCE : Integer
WORK_IN_PROGRESS : Integer
hasStatus 1 FIXED : Integer
DISCARDED : Integer
CoachBreakdown LocomotiveBreakdown
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.
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.
Dels estudiants només ens cal guardar el número d’identificació (NI), ja que
les dades personals les tracta una altra aplicació.
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)
1..*
1 1..*
AnsweredTest AnsweredQuestion
Student
1..* 1..*
-NI : Integer
Test
1 -creationDate : Integer
15..20 1..* -type : String
Question
+obtainMaximalMarks() : void {sequential}
-questionSentence : String
1..*
1..* 1..*
Descriptor
AnsweredSorting
1 1 1 -name : String
+corrects +ordered
1..*
1..* 1..*
correct 1 has
CorrectAnswer 1
has
1..*
has
1..*
© FUOC • PID_00145181 63 Problemes de modelització amb UML
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).
Dels partits s’emmagatzemen els equips que han jugat i els gols que han fet
cadascun.
© FUOC • PID_00145181 64 Problemes de modelització amb UML
Solució:
• Equip (Team)
• Competició (Competition)
• Lliga (League)
• Copa (Cup)
• Jornada (Round)
• Persona (Person)
• Jugador (Player)
• Entrenador (Trainer)
• Partit (Match)
Cada jornada consta d’un conjunt de partits, per la qual cosa s’ha modelitzat
una agregació entre Jornada (Round) i Partit (Partit).
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..*
-id : Integer
1..*
MatchTeam
-goals : Integer
-result : String
© FUOC • PID_00145181 66 Problemes de modelització amb UML
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.
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)
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
PresenterProgram
-date : String
Solució:
• Contingut (Content)
• Contingut imatge (Image)
• Contingut d’àudio (Audio)
• Contingut de vídeo (Video)
• Contingut de document (Document)
• Cooperador (Cooperator)
• Rol (Role)
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
+ Video
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.
Tots els empleats tenen un sou base, que es calcula de la manera següent:
• 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.
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.
© FUOC • PID_00145181 73 Problemes de modelització amb UML
Problema 3: MEC
• 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.
• 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.
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.
Es vol dissenyar una aplicació que representi diferents jocs de tauler, com els
escacs (chess), les dames (draughts), els vaixells (battleship), etc. Tots
© FUOC • PID_00145181 75 Problemes de modelització amb UML
• 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.
Totes les peces, amb independència del joc, tenen un color per a identificar
el jugador al qual pertanyen.
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.
de disposar dels drets que ja tenen persones i robots, entre els quals hi ha el
de poder participar en votacions de referèndums.
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:
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:
Uns grans magatzems ens han encarregat una aplicació per a gestionar els
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.
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
© FUOC • PID_00145181 78 Problemes de modelització amb UML
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.
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ó).
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.
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.).
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.
© FUOC • PID_00145181 81 Problemes de modelització amb UML
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.
© FUOC • PID_00145181 82 Problemes de modelització amb UML
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.
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’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:
• 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.
Els aparells que poden aterrar a l’aeroport que dissenyem són avions de línia
regular i helicòpters.
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.
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.
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.
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).
• 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.