Pid 00145182

Problemas
de modelado
con UML
Programacin orientada a objetos
David Masip Rodo
Elena Planas Hortal (coordinadores)
Jordi Brnquez Jimnez
Juanma Dodero Beardo
Marta Tarrs Puertas
PID_00145182
FUOC PID_00145182 3 Problemas de modelado con UML
ndice
Introduccin ......................................................................................... 5
Parte I. El proceso de modelado....................................................... 7
Parte II. Problemas solucionados .................................................... 11
Parte III. Problemas propuestos (sin solucin) ........................... 74

Introduccin
La principal motivacin de este material didctico surge de la necesidad de

crear un recopilatorio de problemas, que sirvan al estudiante para adquirir la
prctica necesaria a la hora de superar las asignaturas de Diseo y Programa-
cin orientada a objetos.
Estos materiales se estructuran de la siguiente forma:
En la primera seccin, introducimos la metodologa elemental de mode-

lado que seguiremos a lo largo del material, con un ejemplo prctico de
aplicacin.
Siguiendo esta metodologa, la segunda seccin muestra 21 problemas de

dificultad creciente con sus correspondientes soluciones.
Finalmente, la tercera seccin contiene un listado de 22 problemas sin

solucin que pueden servir para practicar la metodologa aprendida.
Parte I. El proceso de modelado
Para crear un diagrama de clases a partir de la descripcin de un problema

real, es necesario seguir un conjunto de pasos que permitan modelar la reali-
dad de la mejor manera posible, con el objetivo de reflejar fielmente los deta-
lles importantes del problema y permitir futuras ampliaciones.
El proceso para crear un modelo de clases, a pesar de no ser matemtico, se

puede esquematizar en el siguiente conjunto de actividades:
1) Identificacin de las clases
Consiste en seleccionar los sustantivos y frases nominales que conformarn

nuestro modelo de clases y eliminar las que sean redundantes, irrelevantes
para el problema o aquellas que hagan referencia a conceptos inconcretos.
El resultado de esta fase ser la obtencin de una lista de clases que acabarn
conformando nuestro modelo de datos.
2) Creacin del modelo de datos
Consiste en establecer las distintas relaciones entre clases que se pueden inferir
a partir del enunciado del problema. Para crear el modelo de datos, en la ma-
yora de problemas no podremos abordar el proceso de creacin de golpe, sino
que deberemos ir creando pequeos modelos que constituyan partes funciona-
les del modelo completo y, posteriormente, irlas juntando hasta completar el
proceso, relacionando las clases identificadas en el primer paso.
3) Inclusin de atributos y mtodos
Una vez creado el modelo de datos, debemos ir aadiendo los atributos y

mtodos que dotarn de significado a nuestro diagrama. Los atributos que
deberemos incluir son los que aparecen en el problema que queremos resol-
ver, mientras que los mtodos corresponden a las acciones que nuestra apli-
cacin necesita para poder realizar las funcionalidades requeridas (no slo la
funcionalidad principal, sino tambin todas aquellas sobre las que stas se
apoyan).
4) Inclusin de la cardinalidad y navegabilidad de las relaciones
Por ltimo, completaremos el diagrama indicando el nmero mximo y mnimo

de instancias que pueden participar en cada relacin (cardinalidad), as como qu
clases tienen constancia de la existencia de las otras clases (navegabilidad).
Para mejorar el diagrama de clases obtenido, es aconsejable aplicar este algo-

ritmo iterativamente, asegurndonos de que no se nos olvida ninguna clase,
atributo o mtodo.
Ejemplo de aplicacin
La Asociacin de Antiguos Alumnos de la UOC nos ha pedido si podemos

ayudarles a confeccionar un programa que les permita gestionar a sus aso-
ciados, eventos y dems elementos relacionados.
Los asociados se pueden dividir en miembros numerarios y en miembros de la

junta directiva, que es elegida por votacin en una asamblea general cada cuatro
aos. La nica diferencia entre ellos es que los miembros de la junta directiva son
convocados a las reuniones de junta y los dems miembros no, pero el resto de
actividades que se realizan estn abiertas a todos los miembros de la asociacin.
La convocatoria de un evento se realiza por correo electrnico a todos los

miembros activos en el momento del envo, recibiendo un enlace para acep-
tar su participacin. En todos los eventos, la aceptacin de los asistentes se
realiza por orden de llegada ya que, en algn caso, se puede dar que el nme-
ro de asistentes sea limitado, como en las conferencias.
En la convocatoria, tambin aparece informacin sobre el lugar que en mu-

chos casos se repite, por lo que nos han dicho que quieren almacenar los
datos para futuros usos.
Solucin:
Miembro (o miembro numerario) (Member)

Miembro de la junta directiva (BoardMember)
Evento (Event)
Conferencia (Conference)
Reunin de la junta directiva (BoardMeeting)
Localizacin (Location)
Adicionalmente, se ha aadido la clase Persona (Person) para poder identifi-

car tambin a los conferenciantes, ya que podra darse el caso de que stos
no fueran miembros de la asociacin.
Para crear el modelo de datos, se ha detectado la existencia de una jerarqua de

herencia cuya superclase es el evento y, segn la descripcin del problema,
tiene nicamente dos subclases, que son las conferencias y las reuniones de la
junta directiva. En este problema, se ha descartado la inclusin de una clase

que represente a los eventos con restricciones en el nmero de asistentes. En
caso de ampliarse la tipologa de eventos, se debera considerar dicho punto.
Event
Conference BoardMeeting
Al mismo tiempo, existe la siguiente jerarqua entre los miembros de la aso-

ciacin:
Person
Member
BoardMember
Adems, tenemos las clases Localizacin (Location) y Asociacin (AAUOC),

que se relacionan con el resto de clases del siguiente modo:
AAUOC
Person
Location
Event
Member
BoardMember
Una vez creado el modelo de datos, completamos las clases con sus atributos
y los mtodos ms relevantes (quedan fuera de este diagrama los mtodos
getters y setters, as como los mtodos constructores de cada clase).
La asociacin necesitar un conjunto de m- AAUOC
todos para aadir nuevos eventos, personas y

newLocation(l : Location) : void
localizaciones al sistema (mtodos newX de la newEvent(e : Event) : void
newPerson(p : Person) : void
clase AAUOC), as como tambin un mtodo informEvent(e : Event) : void
register(m : Member,e : Event) : void
para informar a los miembros de la convoca-

toria de un evento (mtodo informEvent). Al
Person
Location
mismo tiempo, se dice que los usuarios nece- description : String
name : String
attendsTo
address : String
sitarn confirmar la asistencia a los eventos
(mtodo register, que deber almacenar los Event
Member
date : Date
asistentes por orden y controlar el nmero isLocated In description : String e-mail : String
assign(l : Location) : void

mximo de stos si fuera necesario).
4) Inclusin de la cardinalidad y navegabi- Conference BoardMeeting BoardMember
max_attendees : Integer
lidad de las relaciones
attendsTo
En el siguiente diagrama, se han eliminado attendsTo
los mtodos e incluido las navegabilidades

(en este caso, todas son bidireccionales, debido a que no se nos ha comuni-
cado ningn tipo de relacin y/o acceso a la informacin de una clase a
otra), y las cardinalidades de dichas relaciones.
AAUOC
0..*
Person
0..*
0..*
Location attendsTo
0..* 0..* 0..*

Event
Member
1 isLocatedIn 0..*
BoardMember
0..*
0..* attendsTo 0..*
attendsTo
Parte II. Problemas solucionados
Problema 1: aplicativo de profesorado
La UOC est realizando una revisin de sus aplicativos para gestionar a los
profesores, debido a que se han dado cuenta de que tienen ciertas necesida-
des que en el momento de su creacin no se tuvieron en cuenta.
En su momento, emplearon el concepto profesor como un trmino genrico,

pero se han dado cuenta de que existen distintas tipologas de profesor (pro-
fesores internos y asociados externos), con un conjunto de necesidades co-
munes y otras dependientes de cada tipologa (por ejemplo, interesa almace-
nar la empresa en la que trabaja un profesor asociado externo), que
actualmente ya estn implementadas.
Por ejemplo, los profesores internos tienen un sueldo fijo, los asociados ex-
ternos tienen un sueldo dependiente del nmero de alumnos y crditos en
los que imparten clase, pero todos tienen un conjunto de aulas asociado.
Se pide el diagrama UML que incluya las clases, relaciones, atributos y mto-
dos que participan en el diseo de las funcionalidades requeridas.
Solucin:
Profesor interno (InternalTeacher)

Profesor asociado externo (ExternalTeacher)
Empresa (Company)
Clase (Class)
Para crear el modelo de datos, se ha detectado la existencia de una jerarqua

de herencia cuya superclase es el concepto de profesor y, segn el problema,
tiene nicamente dos subclases que son los profesores internos y los profeso-
res asociados externos.
Teacher
InternalTeacher ExternalTeacher
Aparte, tenemos las clases Empresa (Company) y Clase (Class), que se relacio-
nan con el resto de clases de la siguiente manera:
UOC
Company
Class
Teacher
Una vez creado el modelo de datos, debemos completar las clases con sus
atributos y los mtodos ms relevantes (quedan fuera de este diagrama los
mtodos getters y setters, as como los mtodos constructores de cada clase).
La UOC necesitar un conjunto de mtodos para aadir nuevos profesores,

clases y empresas al sistema (los mtodos newX de la clase UOC), as como tam-
bin un mtodo para consultar el sueldo de un profesor (el mtodo 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 siguiente diagrama, se han eliminado los mtodos e incluido las nave-

gabilidades (en este caso se ha incluido una unidireccional, ya que se pide
que el profesor externo sepa en qu empresa trabaja, pero no se ha pedido la

informacin contraria), y las cardinalidades de dichas relaciones.
UOC
0..*
0..*
0..* Company
Class
Teacher
0..* 0..*
0..*
Problema 2: UOCphone
La empresa de telefona mvil UOCphone quiere lanzar una campaa de

fidelizacin de clientes mediante un sistema de puntos. Para ello, quiere
poner en marcha dos sistemas de acumulacin de puntos para sus clientes:
El primer sistema es para los clientes que tienen contrato, de los cuales se
conoce un nmero de cliente.
El segundo sistema es para los clientes en modalidad de prepago, que la

empresa no conoce.
En el primer caso, los puntos se asocian al individuo, de manera que si ste

tiene ms de un mvil contratado, los puntos provenientes de todos sus
mviles se acumulan en una sola cuenta.
Cada lnea de telefona mvil con contrato tiene una modalidad de tarifica-
cin establecida (maana o tarde) que puede cambiarse. En el sistema prepa-
go, como no se conoce al cliente, los puntos se asocian al nmero de telfo-
no del mvil en prepago.
El sistema debe registrar todas las llamadas salientes, incluyendo hora de

inicio y fin, ya que posteriormente se puede querer comprobar los puntos
otorgados segn la duracin y franja horaria de las llamadas.
Las lneas prepago deben recibir un punto por minuto. Las lneas de contrato
deben recibir 1,5 puntos por minuto de las llamadas realizadas dentro de la
franja horaria coincidente con la modalidad de tarificacin contratada (la
maana va desde las 8:00 hasta las 15:00 y la tarde desde las 15:00 hasta
las 20:00), y un punto por minuto de las llamadas realizadas fuera de esa
franja. Todos los puntos deben acumularse inmediatamente, tras finalizar
cada llamada.
Se pide el diagrama UML que incluya las clases, asociaciones, atributos y

mtodos que participan en el diseo de la funcionalidad de actualizacin de
puntos tras cada llamada.
Solucin:
Lnea de telefona mvil (Line)

Lnea de contrato (ContractLine)
Lnea prepago (PrepayLine)
Cliente (ClientAccount)
Llamada saliente (OutCall)
Para clasificar las modalidades de tarificacin por franja horaria no es necesa-

rio definir clase alguna, pues no hay ningn atributo ni operacin que atri-
buir a los posibles objetos de tal tipo. Por ello, se han modelado stas con un
tipo enumerado RateFrame.
Las clases ContractLine y PrepayLine representan las dos situaciones posibles.

Ambas coinciden en estar asociadas a un nmero de telfono, que se repre-
senta mediante el atributo number en la superclase abstracta Line. Los objetos
de tipo ContractLine estn asociados a un cliente, siendo ste quien debe
mantener la cuenta de puntos asociada.
Por otro lado, para decidir posteriormente los puntos a otorgar, se asocia a
cada lnea la historia de sus llamadas salientes, a travs de la asociacin que
une Line y OutCall.
En la solucin, no se ha dibujado la clase principal PhoneCompany que, en

este caso, y para lo pedido el enunciado, slo necesitara una relacin de
agregacin que la uniera con Line, de cardinalidad *. Sin embargo, si se soli-
citaran otras funcionalidades adicionales, podran ser necesarias agregaciones
entre PhoneCompany y ClientAccount, o incluso con OutCall o alguna posible
superclase abstracta Call de esta ltima.
Los clientes se han modelado con la clase ClientAccount, que aglutina slo los
atributos que nos interesan para nuestro problema. Como los puntos de
todos los ContractLine de un mismo cliente se deben agregar, se utiliza para
ello un atributo credits en la clase ClientAccount.
Cada PrepayLine, en cambio, tiene una cuenta de puntos independiente de

las restantes lneas, aunque stas fueran de la misma persona fsica y, por
tanto, se representan mediante el atributo credits del PrepayLine.
Las llamadas de telfono se simulan mediante el mtodo makeCall(startDate,

endDate) de Line. Tras el final de la llamada, se actualiza el histrico de lla-
madas creando una instancia nueva de OutCall y se actualizan los puntos
llamando al mtodo privado updateCredits(credits: int) de Line.
El mtodo Line::updateCredits es privado porque es llamado slo desde make-

Call() para sumar los puntos acumulados. En ContractLine la llamada a upda-
teCredits() acta delegando en updateCredits(credits: int) de ClientAccount para
acumular los puntos en el lugar debido. En cambio, un PrepayLine directa-
mente suma los puntos al atributo credits.
Cada vez que se haga una llamada se deber crear una instancia de OutCall y
llamar a Line::updateCredits(). Por lo tanto, el sentido de navegacin de las
asociaciones ser Line OutCall y ContractLine ClientAccount. Las cardina-
lidades se indican en el diagrama, segn se deduce del enunciado.
Diagrama de clases completo
<<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: gestin de personal
Una universidad necesita una aplicacin capaz de gestionar su personal. Exis-

ten dos categoras de personal: docente y administrativo. El personal docente
se identifica a partir de un identificador de registro, posee un nombre, y est
caracterizado por pertenecer a un departamento. Por ejemplo, el docente
12345-078 pertenece al departamento de Psicologa de la Educacin. Puede
haber distintos profesores por departamento, pero un profesor no puede perte-
necer a ms de un departamento en un mismo instante de tiempo.
El personal administrativo tambin se identifica a partir de un identificador

de registro, y est caracterizado por pertenecer a una seccin y ocupar un
cargo. Por ejemplo, el administrativo 23456-891 pertenece a la seccin de
biblioteca y ocupa el cargo de bibliotecario. Una misma persona no puede
ser a la vez personal docente y administrativo de la universidad.
Dentro de la gestin de la universidad se desea realizar varias tareas, que

incluyen generar las nminas (una lista con el nombre y el sueldo mensual)
de su personal, que posteriormente se podrn imprimir. Para el clculo de la
nmina, se debe tener en cuenta que los docentes cobran una cantidad base
fija ms otra cantidad en funcin del nmero de horas de clase que imparten
(15 / hora); los administrativos cobran una cantidad base fija (distinta que
la de los docentes) ms un conjunto de incrementos por antigedad (40
por cada periodo de tres aos). Si el empleado no fuese docente ni adminis-
trativo en algn periodo de tiempo, no debe aparecer en la nmina.
Se pide el diagrama UML que incluya las clases, asociaciones, atributos y

mtodos que participan en el diseo de la funcionalidad de generacin de la
nmina de un empleado cualquiera.
Solucin:
Docente (Docent)
Administrativo (Administrative)
Personal / Empleado (Employee)
Nmina (Payroll)
Universidad (University): clase principal
Dado que una misma persona no puede ser a la vez docente y administrati-
vo, hemos utilizado una relacin de herencia y aadido la clase abstracta
PersonnelRole para clasificar al personal en uno de los dos tipos de puesto,
segn el modelo siguiente:
1 1..* 1 0..* Payroll

University Employee
PersonnelRole
1
Docent Administrative
En este modelo, un empleado de la universidad ser una instancia de Emplo-

yee. El empleado ser dado de alta como docente o como administrativo.
Por otro lado, la relacin entre cada Employee y su nmina se ha modelado con
una asociacin. La clase Payroll almacena instancias de las nminas calculadas
para los empleados, una por cada mes y empleado. La relacin de empleados
de la universidad se modela con la agregacin entre University y Employee.
Sobre el modelo anterior, completamos los atributos y mtodos necesarios para

la operacin makePayroll(), cuya responsabilidad atribuimos a la clase Employee.
El atributo identificador de un empleado lo asignamos a la clase Employee.
El clculo de la nmina se delega en el mtodo abstracto getSalary de la clase

PersonnelRole. Gracias al polimorfismo, cuando queramos calcular la nmina
de un empleado para archivarla en Payroll, se har una llamada al mtodo
getSalary, que sabr cmo calcular la nmina en funcin del tipo de emplea-
do. Las especificidades del clculo de sueldo base y complementos variables
de la nmina tambin pueden quedar ocultas en un par de mtodos getBase-
Salary y getVariableSalary en los que se apoye el mtodo getSalary.
La generacin de la nmina tendr que imprimir el identificador del em-

pleado, el sueldo y el mes a que corresponde. Esto se realizar en el mtodo
print() de la clase Payroll. En dicha clase, hay que guardar al menos dos atri-
butos: el sueldo (salary) y el mes (month) de la nmina. Siguiendo el princi-
pio de encapsulacin, los datos necesarios para calcular el sueldo en funcin
del tipo de empleado deben quedar ocultos en las subclases de PersonnelRole
y no ser conocidos por Employee.
La nmina de un empleado se conoce navegando a partir de la asociacin

Employee-Payroll. Como un empleado tendr varias nminas (una por mes),
para localizar la nmina de un cierto mes har falta filtrar, de entre todas las
instancias de Payroll asociadas al empleado, la correspondiente al mes.
La navegabilidad entre las clases Employee y PersonnelRole permite conocer el

tipo de empleado, para poder calcular su nmina.
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: nmeros complejos
Una aplicacin de clculo matemtico necesita utilizar nmeros complejos

para poder realizar clculos con puntos en el plano. Los nmeros complejos
deben proporcionar las operaciones algebraicas bsicas de suma, producto y
clculo del conjugado. Adems, los nmeros complejos deben poder impri-
mirse tanto en notacin cartesiana como en notacin polar.
La aplicacin que se disee para tratar con nmeros complejos debe poder
interoperar con una clase Point ya definida, que guarda las coordenadas de
un punto en el plano. Las operaciones algebraicas de suma y producto deben
poder hacerse entre nmeros complejos, entre nmeros complejos y puntos,
y entre nmeros reales y nmeros complejos.
Se pide disear la clase Complex, que represente a un nmero complejo, in-

cluyendo sus atributos y mtodos necesarios para implementar las operacio-
nes deseadas.
Solucin:
Nmero complejo (Complex)

Punto (Point)
La clase Complex se relaciona con la clase Point mediante una relacin de uso.
Dado que un nmero complejo es el mismo independientemente de la nota-

cin en que se exprese, slo guardamos atributos para la parte real e imagi-
naria. Sin embargo, se proporcionan mtodos accesores (mdulo y argumen-
to) para conocer su representacin en coordenadas polares.
Los mtodos de suma y producto estarn sobrecargados para permitir que un

complejo se sume/multiplique por otro complejo, un nmero real o un
Point.
La nica relacin identificada es la dependencia entre Complex y Point, ya

que en Complex aparecen operaciones con parmetros de tipo Point. Podra
haberse definido una asociacin 1:1 entre ambas clases para indicar que re-
presentan a una misma 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: herramienta educativa CAD
Se nos ha encomendado el diseo de una herramienta CAD, dirigida a nios

de educacin primaria, que permita modelar figuras geomtricas. En concre-
to, interesa disponer de un prototipo que permita trabajar con figuras y cal-
cular el rea de una lista de figuras. Las figuras que interesa representar en
este prototipo inicial son crculos, tringulos, rectngulos y cuadrados.
De cada figura interesa almacenar las coordenadas del centro de la figura. En

el caso del crculo, se necesita la informacin adicional del radio. En el caso
del rectngulo, las dimensiones de ancho y de largo. En el caso del cuadrado,
las dimensiones de ancho y de largo coinciden. Y en el caso del tringulo, se
necesita almacenar las dimensiones de la base y la altura de la figura.
Solucin:
Figura (Figure)
Crculo (Circle)
Rectngulo (Rectangle)
Tringulo (Triangle)
Cuadrado (Square)
Se detecta una jerarqua de herencia, cuya superclase es el elemento Figure.

Las clases Circle, Rectangle y Triangle heredan de ella. A su vez, Rectangle espe-
cializa en Square.
El mtodo que permite calcular el rea de una figura es abstracto en la clase

Figura, y es definido en las clases Circle, Rectangle y Triangle. El mtodo del
clculo del rea para la clase Square se hereda de la clase Rectangle.
4) Inclusin de la cardinalidad y la navegabilidad de las relaciones
En este caso, no hay cardinalidad ni navegabilidad porque slo se ha identi-

ficado una relacin de herencia.
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: escuela LaVirtual
La escuela LaVirtual nos ha encargado el desarrollo de una ampliacin en su

aplicacin que permita la gestin de unos nuevos usuarios: los becarios. Ac-
tualmente, la escuela dispone de docentes y estudiantes. Un docente es una
persona que imparte docencia a los estudiantes de una clase. Un estudiante
es quien recibe la docencia. Recientemente se ha incorporado, adems, la
figura del becario, que es un estudiante que ayuda a un nico profesor en
una clase.
Debe remarcarse tambin que, normalmente, los estudiantes tienen unos

derechos y unos recursos asignados, y los docentes tienen unos derechos y
unos recursos ms amplios. Hay espacios de la escuela donde un docente s
tiene acceso y un estudiante no (por ejemplo, la sala de profesores, o las reu-
niones de coordinacin de una asignatura).
Un becario no se considera un docente. Los docentes tienen ciertos privile-

gios extras que no se encuentran al alcance de los becarios, tales como el
acceso a la informacin sobre el expediente de los estudiantes o la utilizacin
de ciertos recursos.
dos que participan en el diseo de la funcionalidad requerida.
Solucin:
Docente (Instructor)
Clase (Class)
Estudiante (Student)
Becario (Assistant)
Existe una jerarqua de herencia, puesto que el becario hereda de estudiante.
Assistant dispondr de un atributo interno de tipo Docent que proporciona

todas las funcionalidades que necesite como becario.
No se han restringido las navegabilidades, ya que el problema no especifica

ninguna restriccin. Las cardinalidades se muestran en el diagrama final.
Instructor Class Student

1 1 1..* 1..*
Assistant
-in : Instructor
Problema 7: OilCompany
La compaa petrolfera OilCompany nos ha encargado desarrollar un apli-

cativo para gestionar sus combustibles. Tras un anlisis exhaustivo de los
requerimientos del proyecto, hemos llegado a las siguientes conclusiones:
1) El mbito del proyecto es la gestin de los diferentes tipos de gasolina que

existen, pero, de momento, nuestra responsabilidad se limita al clculo de
los beneficios que se obtienen con la venta de productos refinados.
2) La medida tcnica y financiera del petrleo es el barril. Un barril es un

contenedor que puede tener diferentes capacidades medidas en galones. Otra
medida petrolfera importante es el octanaje, que permite evaluar el rendi-
miento del combustible.
3) La empresa OilCompany compra barriles de petrleo en bruto a un precio

determinado, dependiendo de la Bolsa, los conflictos internacionales, etc.
4) Esta empresa realiza bsicamente dos procesos de refinamiento, que dan

como resultado los diferentes tipos de carburantes. Los costes por barril de
estos dos procesos son los siguientes:
Para gasolinas: (Octanaje Galones) / ( 2 (Galones 1))

Para gasleos: (Octanaje Galones) / 10
5) El precio de venta por galn del producto final (gasolina o gasleo) viene
estipulado por el Gobierno, y la empresa debe respetarlo. Cada tipo de pro-
ducto final tiene un precio de venta.
6) El beneficio de la empresa es, evidentemente, la diferencia entre el precio

de venta y lo que le cuesta a la empresa el producto refinado.
7) No se descarta, en un futuro prximo, que se aadan nuevas tipologas de

producto, y por tanto, la aplicacin debe disearse pensando en esto.
Solucin:
OilCompany
Gasolina (Petrol)
Gasleo (DieselOil)
La clase OilProduct es una clase abstracta obtenida por generalizacin de las

clases Petrol y DieselOil.
Existe una relacin de agregacin entre OilCompany y sus productos OilProduct.
La clase abstracta OilProduct contiene los atributos comunes de Gasolina y

Gasleo. Esa misma clase contiene los mtodos necesarios para calcular los
beneficios (computeProfits) y para calcular el coste por barril del proceso de
refinamiento (computeCost). Este ltimo mtodo es abstracto en la clase Oil-
Product y se define en sus subclases.
La clase principal OilCompany gestiona los productos y el cmputo de los

beneficios.
No se han restringido las navegabilidades, ya que el problema no especifica

ninguna restriccin. Las cardinalidades se muestran 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: gestin de una consultora
Una empresa consultora est pensando en crear una nueva aplicacin para la
gestin de los empleados, los clientes y los proyectos que realizan para stos.
Cada cliente tiene asociado un gerente, que es el empleado encargado de
gestionar todas las acciones con l, as como tambin la venta y el segui-
miento de los proyectos en curso.
En general, cualquier proyecto que se hace en la empresa utiliza un conjunto de

herramientas (a veces no se emplea ninguna). stas pueden ser comerciales (con
lo que tienen un coste por licencia), de licencia gratuita (con un coste base muy
inferior a las herramientas comerciales) o desarrolladas por la propia consultora.
Las herramientas desarrolladas tienen, para cada empleado desarrollador, un

nmero de horas de dedicacin; por lo tanto, su coste es la suma de los cos-
tes de cada empleado involucrado en el desarrollo.
Aparte de los costes atribuibles a las herramientas, en los proyectos trabajan

personas que utilizan las herramientas o bien realizan otras tareas. Para cada
una de las personas involucradas, se quiere saber el rol que han desarrollado
en cada proyecto (se puede desarrollar ms de un rol en el mismo proyecto)
y las horas empleadas.
dos que participan en el diseo de la funcionalidad descrita.
Solucin:
Empleado (gerente y / o desarrollador) (Employee)

Cliente (Client)
Proyecto (Project)
Herramienta (Tool)
Herramienta Comercial (Comercial)
Herramienta Gratuita (Free)
Herramienta Desarrollada (Development)
Rol (Role)
Adicionalmente, hemos aadido la clase empresa (Company) para que poda-

mos partir de un punto de interrelacin de todas las entidades.
Para crear el modelo de datos, se ha detectado la existencia de una jerarqua

de herencia, donde Tool es la superclase y los diferentes tipos de herramien-
tas (Comercial, Free y Developement) corresponden a sus subclases.
Tool
name : String
Comercial Free Development
price : int basePrice : int
Posteriormente, hemos aadido los conceptos de cliente, proyecto y em-

pleado, as como las herramientas (para simplificar, hemos usado la supercla-
se) y la relacin que modela los gestores de cada cliente.
Company
Employee
Client
Project Tools
Uses
Manages
Finalmente, hace falta aadir al diagrama los roles que los empleados desarro-
llan en cada proyecto (que debe incluir las horas dedicadas) y la dedicacin de
los desarrolladores en la creacin de herramientas propias. Para representar esta
informacin, utilizaremos dos clases asociativas (ved el diagrama completo).
Como atributos, deberemos incluir el nombre de los clientes y empleados, as

como tambin de las herramientas a emplear en un proyecto y el precio de stas.
En principio, del enunciado no se puede desprender nada ms, pero se po-

dran llegar a aadir muchos ms atributos y mtodos a medida que veamos
que sern necesarios para el desarrollo.
Para la definicin de la cardinalidad y la navegabilidad de las relaciones,

debemos analizar cada una de ellas y ver, junto al enunciado, cules seran
los valores ms apropiados.
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: vehculos MoveFast
La empresa de alquiler de vehculos MoveFast nos ha pedido si le podemos

crear un programa para la gestin de su flota, ya que hasta ahora tenan un
programa que nicamente les permita gestionar los coches; y ahora quieren
gestionar otros tipos de vehculos dentro de su proceso de expansin.
Adems de los coches, quieren gestionar motocicletas (de cara al turismo) y furgo-
netas y camiones (para el mundo laboral). De cada uno de estos quieren almace-
nar los rasgos caractersticos (matrcula, pasajeros para los turismos, TARA para los
camiones, etc.), el tipo de carn necesario y el precio por da del vehculo.
Hay dos tipos de clientes: casuales y de leasing. Todos los clientes pueden alqui-
lar cualquier tipo de vehculo. La diferencia est en que los clientes casuales
realizan el pago en el momento de retirar el vehculo del local, mientras que
los clientes de leasing, dado que por la propia definicin realizan un alquiler a
largo plazo, se les remiten facturas a las empresas mensualmente. Por este mo-
tivo, los clientes de leasing deben aportar informacin sobre su empresa (en
caso de no tener ficha en MoveFast) para poder realizar el alquiler (adicional-
mente, tienen un 10% de descuento en el clculo de los alquileres).
Sobre los alquileres, la empresa quiere poder consultar qu coches tienen

disponibles en un momento determinado (clasificados segn el tipo de co-
che), as como tambin qu coches se deben entregar durante el da de hoy y
qu coches se deben recoger.
Como operativa general, se debe de poder dar de alta o modificar cualquier

tipo de vehculo, cliente y empresa, as como tambin imprimir facturas de
un alquiler determinado o imprimir la factura de una empresa correspon-
diente a un mes y ao determinado.
Solucin:
Coche (Car)
Motocicleta (Motorbike)
Furgoneta (Van)
Camin (Truck)
Cliente Casual (Casual)
Cliente de Leasing (Leasing)
Empresa (Company)
Alquiler (Rental)
Adicionalmente, hemos aadido la clase MoveFast para poder partir de un

punto de interrelacin de todas las entidades.
Del enunciado se deduce que existe una herencia en los tipos de vehculo
que ofrece la empresa de alquiler de coches y otra en los tipos de cliente.
Notad que tanto la clase Vehicle como la clase Client son clases abstractas,
dado que no se pueden instanciar directamente (es decir, todos los vehculos
y clientes sern de un tipo concreto).
Los clientes leasing se relacionan mediante una asociacin con su empresa.
Finalmente, slo falta relacionar los conceptos vehculo y cliente mediante

una clase asociativa (Rental), que permite representar el alquiler de un veh-
culo por parte de un cliente (ved el diagrama de clases completo).
A continuacin, debemos incluir los atributos y mtodos que requiere el

modelo que acabamos de disear.
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 se han incluido todos los mtodos para no distorsionar el diagrama, pero,

adems de los mtodos que aparecen, tendremos los mtodos que permiten
dar de alta y modificar los datos almacenados.
4) Cardinalidad y navegabilidad de las relaciones
Finalmente, deberemos incluir navegabilidad de las relaciones y su cardinali-

dad. Dado que no hay lmites entre los alquileres que puede hacer cada
cliente, la relacin entre los vehculos y los clientes tiene una cardinalidad
de muchos a muchos.
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
Vehicle 0..*
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: la agencia de viajes
Una agencia de viajes nos pide si le podemos informatizar toda la informa-

cin que tienen sobre los clientes y los viajes, tanto los que tienen ofertados
como los que los clientes les han comprado.
En primer lugar, les interesa separar los clientes segn si son de negocios o
clientes particulares, dado que a los clientes empresariales les facturan los
viajes mensualmente; por lo tanto, debern almacenar sus datos bancarios
para poder facturar a final del mes. Para los clientes particulares, les interesa
conocer los datos estndar que necesitaramos de cualquier cliente: nombre
y apellidos, direccin postal y el DNI para las reservas.
Los tipos de servicios que ofrece la agencia son muy diversos, desde billetes
de avin a coches de alquiler, pasando por noches de hotel o excursiones
organizadas, as como tambin paquetes de viajes que estn formados por
diferentes elementos (por ejemplo, un paquete de viaje puede estar formado
por una excursin y una noche de hotel).
Cada una de las tipologas de viajes tiene un nmero determinado de pla-

zas disponibles, y cuando stas estn llenas ya no se pueden asignar ms
clientes, por lo que se deber de tener en cuenta este hecho al realizar las
reservas.
La agencia de viajes quiere tener una operativa de funcionamiento que les

permita aadir nuevas oportunidades de viajes, eliminarlas (siempre y cuan-
do no haya ninguna reserva confirmada), crear paquetes de viajes (con un
porcentaje de descuento sobre el precio total de sus elementos), reservar un
tipo de viaje a un cliente, confirmar una reserva realizada, realizar el pago de
un viaje y crear la factura para los clientes de negocios.
Adems, les interesa poder realizar listados de clientes particulares y de clien-

tes de negocios (para poder enviarles ofertas especficas para cada uno de los
colectivos), as como tambin de aquellos viajes que no hayan vendido nin-
guna plaza (para no ofrecerlos en el futuro) y de todas las reservas que estn
pendientes de pago (para no olvidarse de cobrar ninguna).
Las reservas de los clientes pueden estar en tres estados (realizadas, con-
firmadas y pagadas). En caso de que una reserva est realizada, pero no
confirmada, si la agencia de viajes pide eliminar una oportunidad de via-
je, esta reserva se debe anular (borrar del sistema), pero antes se ha de
enviar un correo electrnico para que el cliente sepa que la reserva ha
sido anulada.
Solucin:
Cliente (Customer)
Servicio (Service)
Cliente Particular (Customer)
Cliente de Negocios (BusinessCustomer)
Billete de Avin (Flight)
Coche de Alquiler (Car)
Noche de Hotel (Hotel)
Excursin Organizada (Excursion)
Paquete de Viajes (Packet)
Reserva (Reservation)
Adicionalmente, hemos aadido la clase Agencia de Viajes (TravelAgency) para

poder partir de un punto de interrelacin de todas las entidades.
Del enunciado se puede deducir que existe una herencia en los tipos de ser-
vicio que ofrece la empresa de viajes:
Service
1..*
Packet Car Flight Hotel Excursion
Adicionalmente, tenemos los clientes que se dividen entre normales y de

empresa. Dado que nicamente se realizar un tratamiento especial a los
clientes de empresa, se ha creado una especializacin para este tipo de clien-
tes (ved el diagrama completo).
Finalmente, slo hace falta relacionar estos dos conceptos (servicio y cliente)
mediante una clase asociativa (Reservation) que permite guardar informacin
sobre las reservas:
TravelAgency
Reservation
state : int
Service Customer
Una vez definido el modelo de datos, ya podemos incluir los atributos y

mtodos necesarios (ved el diagrama completo).
No se han aadido los mtodos en el diagrama para no distorsionarlo, pero

tendremos como mnimo aquellos que nos permitan crear, modificar y bo-
rrar productos y clientes y, finalmente, los encargados de la asignacin de
productos a clientes, confirmacin y generacin de listados y facturas.
Finalmente, deberemos incluir la navegabilidad de las relaciones y su cardinalidad.

En principio, dado que el enunciado no dice nada sobre el tema, la relacin entre
el paquete y el producto debe ser en este sentido y no en el otro, ya que no se pide
que un producto pueda saber si est dentro o no de un paquete comercial.
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, ampliacin de software
La empresa de alquiler de coches MoveFast, dado que la aplicacin que les

realizamos tiempo atrs les funciona muy bien, nos ha pedido si le podemos
ampliar el programa de modo que les permita tratar ms de una oficina, ya
que estn en pleno crecimiento y tienen necesidades nuevas.
Adems de poder gestionar las tipologas de vehculos que ya les permite la

aplicacin, quieren almacenar ciertos datos de las oficinas, por ejemplo, la
localizacin, la direccin, el telfono y el correo electrnico de contacto.
Para cada centro de trabajo quieren saber qu personal tienen asignado, tanto las
personas que estn de cara al pblico como los conductores que se encargan de
mover los vehculos entre las diferentes oficinas donde los tienen aparcados. Adi-
cionalmente, los conductores pueden tener que realizar traslados de coches entre
oficinas, en el caso de que un cliente deje el coche en una oficina diferente.
Todos los empleados tienen un sueldo base, pero los conductores, en caso de
que deban realizar un traslado de vehculos, reciben una cantidad fija adi-
cional por las molestias del desplazamiento.
A veces, para campaas puntuales, se debern reasignar algunos vehculos.

Por ejemplo, en verano, las oficinas de lugares tursticos tendrn ms coches
asignados que las otras, por lo que hace falta que exista la posibilidad de
reasignarlos segn convenga.
Solucin:
Vehculo (Vehicle)
Empleado (Employee)
Comercial (Salesman)
Conductor (Driver)
Oficina (Office)
Traslado (VehicleTransfer)
Del enunciado anterior, donde se especificaba la primera versin de la apli-

cacin de alquiler de vehculos (ved el problema 9), podemos recuperar las
tipologas bsicas de vehculos con los que trabaja la empresa:
Coche (Car)
Motocicleta (Motorbike)
Furgoneta (Van)
Camin (Truck)
Adicionalmente, hemos aadido la clase MoveFast para poder partir de un

punto de interrelacin entre todas las entidades.
A partir de la solucin de la primera parte de la aplicacin de alquiler de

coches (ved la solucin al problema 9), podemos considerar que las tipolog-
as de vehculos siguen la misma taxonoma.
Del enunciado se puede deducir que existe una herencia entre los tipos de
empleados, donde Employee es la superclase y Driver y Salesman son las sub-
clases.
A continuacin, se incluyen las relaciones que permiten asociar los vehculos

con la oficina en la que estn asignados y el concepto de que se produzca el
traslado de un vehculo entre oficinas (realizado nicamente por los emplea-
dos conductores).
Office
IsAssignedTo
Employee
Vehicle
VehicleTransfer
Driver
Una vez definido el modelo de datos, aadimos los atributos y mtodos que
necesite el modelo que acabamos de disear (ved el diagrama completo).
No se han introducido todos los mtodos para no distorsionar el diagrama,

pero deberemos introducir, como mnimo, los mtodos que permitan dar de
alta y modificar los datos almacenados.
Finalmente, deberemos incluir la navegabilidad de las relaciones (que en este

caso siempre es bidireccional, por lo cual no se muestra en el diagrama) y su
cardinalidad.
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 reparaciones
Nuestro vecino tiene un pequeo taller de reparacin de la mecnica de co-

ches. Dado que los coches cada vez son ms complejos, tiene problemas para
saber qu pieza debe cambiar en cada coche, ya que modelos muy parecidos
emplean piezas diferentes.
Nos ha pedido si le podemos crear una aplicacin que le permita, dada una
descripcin de una pieza (por ejemplo, el filtro del aire) y dado un modelo y
un ao (por ejemplo, SEAT 127, ao 1980), obtener directamente el cdigo
de la pieza correspondiente a aquel modelo para pedirla al distribuidor (as
como tambin el precio y el tiempo estimado necesario para cambiarlo).
Aparte, quiere poder ofrecer un conjunto de reparaciones estndar a los

clientes (por ejemplo, cambio de filtros, que cambiara un conjunto de
filtros ya determinado, especficos para cada modelo). De las reparaciones
almacenadas, quiere conocer las piezas que componen la reparacin para
volverlas a utilizar en posteriores ocasiones.
Sobre los clientes, nicamente le hace falta almacenar la matrcula del vehcu-
lo, el nombre, telfono y direccin del propietario. Con estos datos y el tipo de
reparacin que necesita (puede repetirse en el tiempo) puede ir trabajando.
Para cada reparacin, nicamente se pueden cambiar piezas que la repara-

cin tenga estipuladas (adaptadas a cada modelo), y, en caso de tener que
cambiar alguna pieza que no est dentro de lo previsto, se debe mostrar un
error para que los empleados llamen para confirmar el nuevo presupuesto.
Solucin:
Pieza (Part)
Modelo (Model)
Pieza del Modelo (ModelPart)
Reparacin Estndar (Repair)
Cliente/Vehculo (Client)
Reparacin Efectiva (RepairPart)
Adicionalmente, hemos aadido la clase Taller (Workshop) para poder partir

de un punto de interrelacin de todas las entidades.
Del enunciado se deduce que el taller necesita guardar informacin sobre

piezas, reparaciones estndares, modelos y clientes. Por este motivo, se han
creado relaciones de agregacin entre el taller (Workshop) y las clases Part,

Repair, Model y Client.
El conjunto de piezas que requiere una reparacin se ha modelado mediante

una asociacin entre las clases Repair y Part.
Existe una pieza (Part) especfica para cada modelo (Model), que representare-
mos mediante una clase asociativa (ModelPart) entre las dos clases anteriores.
Finalmente, debemos relacionar el concepto de reparacin con el de cliente y

almacenar las piezas que se han cambiado para poder generar las facturas
correspondientes (ved el diagrama completo).
Una vez hemos definido el modelo de datos, podemos incluir los atributos y
mtodos que necesite el modelo que acabamos de disear (ved el diagrama
completo).
No se han incluido los mtodos para no distorsionar el diagrama, pero tendremos

como mnimo los mtodos que permitan crear, modificar y borrar partes, repara-
ciones, modelos y clientes y, finalmente, los encargados de la asignacin de stos.
Por ltimo, deberemos incluir la navegabilidad de las relaciones y su cardinalidad.
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 librera virtual
Una librera desea ofrecer su catlogo de libros y CD-ROM a la venta por

Internet. Para ello, nos ha solicitado el desarrollo de una librera virtual que
ms adelante se utilizar para construir una aplicacin web. La librera vir-
tual debe ser capaz de gestionar los pedidos, el carrito de la compra, as como
el catlogo en general. Las funcionalidades que ha de soportar la aplicacin
son las siguientes:
1) Crear una nueva cuenta de usuario: de cada usuario se debe guardar el nom-
bre y apellidos, as como la direccin postal. El usuario elegir un nombre de
usuario que debe ser nico, y un password. Se deber guardar informacin de
una o ms tarjetas de crdito que el usuario podr elegir para pagar los diferen-
tes pedidos que haga. De las tarjetas se guardar el tipo de tarjeta, nmero,
titular (segn aparece en la tarjeta), y la fecha de expiracin (mes/ao).
2) Aadir un nuevo artculo al catlogo: se pueden aadir al catlogo tres

tipos de artculos: libros, CD-ROM e informes digitales. Todos ellos tienen un
nmero de referencia interno (una cadena), un precio actual, un ttulo y una
fecha de publicacin, pero slo de los libros y CD-ROM hay que almacenar
el estoc (nmero de artculos disponibles), ya que los informes digitales se
distribuyen mediante descarga por Internet. Los informes digitales tienen,
adems, una fecha de expiracin en la que dejan de venderse, ya que se con-
sideran obsoletos. De los libros, adems, se almacena el nmero de pginas,
y de los CD-ROM el tamao en MB.
3) Actualizar las cantidades de ejemplares en estoc: consiste en incrementar o

disminuir la cantidad de un artculo cuando llegan nuevas existencias o se
dan de baja existencias (por ejemplo, porque se han deteriorado). Cuando se
genera un pedido, ste slo puede hacerse si la cantidad en estoc es suficien-
te para cubrir todos los artculos pedidos, y al hacerse el pedido, las cantida-
des en estoc se disminuyen adecuadamente.
4) Gestionar el carrito de la compra: cada cuenta de usuario tiene asociado

una cesta o carrito de la compra virtual, en el que el usuario puede ir aa-
diendo artculos que desea comprar. Puede adquirir varias unidades de un
mismo artculo, especificndolo al aadir artculos al carrito. No se compro-
bar el nmero de unidades almacenadas en el carrito, pudindose aadir
todos los artculos que se quiera.
5) Finalizar la compra a partir de los contenidos del carrito: cuando el usuario

finaliza la compra (checkout), el carrito se vaca y se genera un pedido. El
usuario deber elegir la tarjeta de crdito con la que pagar el pedido, y del
pedido se guardar adems la fecha en la que se realiza. En este momento, se
asocia el pedido con la tarjeta de crdito y se actualizan las existencias disponi-
bles de cada artculo. Es decir, se puede ir aadiendo al carrito lo que se quiera,
pero no es hasta que se finaliza la compra cuando se comprueban y se ajustan

las existencias. Tambin en este momento se crea la lista de artculos compra-
dos, con un comentario vaco. Ms adelante, cuando se aada un comentario,
se mirar en esta lista de artculos comprados y se actualizar el comentario.
6) Visualizar el historial de compras: se permitir visualizar todos los pedidos

realizados, incluyendo la fecha de compra, la referencia de los artculos com-
prados, la cantidad comprada, y los precios a los que se compraron los art-
culos, que pueden ser diferentes de los precios actuales de los mismos.
7) Aadir una recomendacin a un artculo: cuando un usuario compra un

artculo, tiene derecho a escribir un texto recomendando el mismo, que esta-
r accesible para el resto de los usuarios.
Solucin:
Artculo (Item)
Artculos con estoc (StockableItem)
Libro (Book)
Informe Digital (DigitalReport)
CD-ROM
Usuario (UserAccount)
Tarjeta de Crdito (CreditCard)
Carrito de la Compra (ShopingBasket)
Pedido (Order)
Recomendacin (Recommendation)
Las clases Item y StockableItem son abstractas, ya que representan partes co-
munes de otras clases.
El resto de las clases que representa a los diferentes tipos de Item son subcla-
ses de una de las anteriores: Book, DigitalReport y CDRom. La clase abstracta
StockableItem contiene la funcionalidad especfica de artculos sujetos a ges-
tin de existencias, que es igual para todas sus subclases.
La informacin del usuario se modela en la clase UserAccount, que est aso-

ciada con una o varias tarjetas (CreditCard). Los tipos de tarjeta se represen-
tan mediante un atributo, ya que no hay diferencias en la informacin que
se modela dependiente del tipo de tarjeta.
Los usuarios tienen un (y slo un) objeto carrito de la compra asociado

(ShoppingBasket). Los elementos en el carrito se representan mediante una
asociacin con la clase Item. Se debe usar una clase asociativa para poder
guardar la informacin del nmero de elementos de cada tem que se han
aadido al carrito.
Cuando el usuario haga efectiva la compra, los contenidos del carrito se bo-
rrarn, creando antes un nuevo pedido (Order). Los pedidos estarn asociados
a los tems y, adems, hace falta una clase asociativa, no slo para almacenar
la cantidad de cada Item, sino porque es necesario guardar el precio al que se
vendieron (ya que puede ser diferente al precio actual del producto). Los
pedidos sern cargados a la tarjeta de crdito que el usuario especifique, que-
dando esto reflejado en la asociacin entre Order y CreditCard.
Los comentarios (Recommendation) de los usuarios se aadirn como clase

asociativa entre la cuenta de usuario y el artculo comprado.
Finalmente, se ha dibujado una clase principal BookShop que proporciona

acceso a los objetos gestionados por el sistema, bsicamente de tipo UserAc-
count, Item, Order.
Las clases incluyen los atributos especificados en el enunciado. En cuanto a los

mtodos, stos se reparten de la forma siguiente entre las clases identificadas:
a) La clase Item incluye mtodos comunes a todos los artculos: son los m-
todos accesores a sus atributos (getRef/setRef, getName/setName, getPublica-
tion/setPublication y getPrice/setPrice).
b) La clase UserAccount incluye el mtodo addCreditCard para aadir una

tarjeta de crdito adicional al usuario, y el mtodo createShoppingBasket para
crear y asociar el carrito de la compra que llevar el usuario.
c) La clase abstracta StockableItem contiene la funcionalidad especfica de

artculos sujetos a gestin de existencias: getStock y modifyStock.
d) La clase ShoppingBasket contiene mtodos para aadir y eliminar artculos

(addItem/removeItem) del carrito y para vaciarlo (clear) cuando el usuario haga
efectiva la compra.
e) La clase Order incluye el mtodo chargeToCreditCard para cargar el pedido

a una tarjeta de crdito especfica.
f) La clase BookShop debe proporcionar acceso a las funcionalidades principa-

les de la aplicacin: gestin (altas, bajas, modificaciones y consultas) de
usuarios y artculos, gestin del carrito, hacer un pedido, aadir un comenta-

rio a un artculo comprado, etc. Para hacerlo, se apoyar en los mtodos
repartidos por las clases restantes del modelo.
Las cardinalidades de las relaciones reflejadas en el modelo se definen en

funcin de las restricciones expresadas en el enunciado. Por ejemplo, un
usuario dispone de un solo carrito de la compra. Una tarjeta de crdito est
asignada a un solo usuario (su titular), un pedido se paga con una nica tar-
jeta de crdito, etc.
La navegabilidad de las relaciones se establece en funcin de qu sentido de

navegacin hace falta para poder implementar a los mtodos diseados. Por
ejemplo, es necesario conocer los artculos contenidos en un carrito de la
compra, pero no es necesario saber de un artculo qu carritos de la compra
lo contienen. De ah el sentido de navegacin entre ShoppingBasket e Item.
Por otro lado, como los pedidos hay que procesarlos, hace falta localizar la
tarjeta de crdito (para facturar) y los artculos (para solicitar el envo) desde
un pedido dado. De ah el sentido de navegacin desde la clase Order hacia
sus clases asociadas.
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..* BasketSelection
0..*
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: la ONG-hemeroteca
La biblioteca de una ONG ha recibido una importante ayuda econmica que

se destinar a crear una hemeroteca. Esto le permitir adquirir y gestionar
libros y revistas. Se pide disear la aplicacin que permitir llevar a cabo la
gestin de la hemeroteca y de sus usuarios. Tras el anlisis de requisitos del
sistema, se obtiene la siguiente informacin:
La informacin asociada a los libros est compuesta por la editorial, el autor

principal, el ttulo, el ISBN, la fecha de publicacin y el precio.
De las revistas hace falta almacenar la informacin referente al nombre de la

revista, editorial, volumen, nmero, ISBN y fecha de publicacin.
Cuando un nmero de una revista es un monogrfico (trata un nico tema),

adems de la informacin anterior se debe indicar el ttulo de tema, as como
el autor principal de los artculos. De cada autor slo es necesario almacenar
el nombre completo.
De los usuarios de la biblioteca de la ONG hace falta almacenar el nombre

completo, el telfono, la direccin y la edad.
La aplicacin informtica debe permitir realizar las siguientes funcionalidades:
Dar de alta de nuevos libros y revistas, as como nuevos usuarios.
Realizar el prstamo de libros/revistas y garantizar que se presta un

mximo de cinco artculos por usuario.
Conocer los libros de un autor que se han adquirido en la biblioteca, as

como los monogrficos donde el autor haya escrito algn artculo.
Buscar la informacin asociada a un libro, revista o monogrfico, as co-

mo su disponibilidad, a partir de su ISBN.
Conocer todos los libros y revistas que un usuario tiene actualmente en prs-
tamo, as como informacin respecto a si se encuentra en penalizacin y la
informacin personal del usuario. Consideramos que un usuario puede to-
mar prestados un mximo de cinco documentos simultneamente. Para
simplificar, supondremos que no es necesario guardar un historial de prs-
tamos.
Evaluar cada da qu documentos (libros o revistas) de los que se encuen-

tran en prstamo deberan haberse devuelto.
Solucin:
Hemeroteca (Library)
Usuario (User)
Libro (Book)
Revista (Magazine)
Monogrfico (Monography)
Documento (Document)
Prstamo (Loan)
Como puede observarse en el diagrama de clases completo, la clase Library

tiene relaciones de agregacin con las clases User, Book, Magazine y Mono-
graphic. Las clases Book y Magazine se pueden definir mediante el mecanismo
de herencia a partir de la clase Document. Del mismo modo, la clase Mono-
graphic se puede definir mediante herencia a partir de la clase Magazine.
Finalmente, hay una clase Loan entre User y Document, que permite gestionar
los prstamos.
En el diagrama de clases del completo, se relatan los atributos de cada una de

las clases identificadas. En cuanto a los mtodos, las clases responsables de
implementar las funcionalidades descritas son las siguientes:
Alta de nuevos libros y revistas: Library.
Alta de nuevos usuarios: Library.
Hacer prstamos de documentos: Library, que delega en User, mediante una

llamada al mtodo borrowDoc. Este mtodo crear una instancia de Loan y
llamar a setLoan para asignar el usuario y el documento a prestar, que se le
pasa como parmetros. El mtodo setLoan llamar a su vez a setBorrowedBy
del objeto Document, para que le quede asignada la instancia de Loan.
Conocer los libros adquiridos: Library.
Conocer monogrficos donde participa un autor: Library.
Buscar informacin asociada al documento y su disponibilidad: Library.

Conocer documentos en prstamo de un usuario: Library, que delega en

el mtodo listLoans de la clase User.
Evaluar qu documentos en prstamo deberan haberse devuelto: Library.
Las cardinalidades ms notables son las que restringen el mximo de prsta-

mos (0..5) y la que asocia un prstamo con su nico documento asociado.
Las dems cardinalidades no se han restringido (0..*). Tampoco se han res-
tringido la navegabilidad entre clases, pues todas son necesarias para imple-
mentar las operaciones pedidas.
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 es una empresa especializada en la venta y distribucin de

material y accesorios informticos. Con el fin de mejorar su sistema de gestin, se
pide disear una aplicacin capaz de llevar a cabo la gestin de productos, clientes
y proveedores, as como los pedidos que realizan los clientes. Despus de un anli-
sis de requisitos del proyecto, se ha llegado a las siguientes conclusiones:
1) Todos los productos tendrn un identificador y un nombre. Adems, ser nece-

sario saber la cantidad de unidades de cada producto que tenemos y su proveedor.
Los productos que se venden en la empresa se clasifican en equipos y dispositivos.
2) Los equipos son equipos informticos completos. De stos interesar co-

nocer el procesador, los megabytes de memoria RAM, y los gigabytes de ca-
pacidad del disco duro.
3) Los dispositivos son aquellos que permiten a los equipos adquirir datos
del exterior. Para los dispositivos, en general interesar saber informacin
comn especfica. Hoy por hoy, en la tienda virtual slo se dispone de un
tipo de dispositivo, los DVD (con caractersticas adicionales propias), aunque
en un futuro prximo se catalogarn nuevos dispositivos.
4) Los clientes de la empresa virtual los clasificaremos en dos tipos: particula-

res y mayoristas. De los clientes particulares nos interesar almacenar su
nombre, direccin y un identificador nico del cliente. De los mayoristas nos
interesar saber, adems de los mismos datos que de los clientes particulares, el
descuento que se aplicar a los pedidos que realicen.
5) De los proveedores nos interesar conocer el identificador, nombre y di-

reccin, as como la lista de productos que provee a la empresa. Considera-
remos que un proveedor puede suministrar a la tienda un mximo de 50
productos distintos, pero un producto es suministrado por un nico provee-
dor. La Virtual Store Computers fijar el coste de venta de cada producto, de
forma que ste no va a depender del proveedor.
6) Los clientes comprarn productos de la empresa mediante pedidos. Los

pedidos se resolvern modificando el estoc de los productos conveniente-
mente. Para calcular el coste del pedido, se tendr en cuenta el tipo de clien-
te. Para ello, los mayoristas tendrn descuentos frente a los particulares.
7) Un pedido estar formado por la lista de productos que se ha comprado, y

para cada uno de ellos, el nmero de unidades que se han comprado. Si en
un pedido no hay suficiente estoc para alguno de los productos que se piden,
el pedido no se servir y se tendr que devolver al estoc de productos todos
los productos que ya se hayan asignado al pedido.
Solucin:
Producto (Product)
Equipo Informtico (Computer)
Dispositivo (Device)
DVD
Pedido (Order)
Cliente (Customer)
Mayorista (WholeSaler)
Proveedor (Supplier)
La clase Store representa la aplicacin de la tienda virtual. Puesto que la apli-

cacin est compuesta por sus Customers, sus Suppliers, sus Orders y sus Pro-
ducts, se han establecido relaciones de agregacin entre Store y Customer,
Supplier, Order y Product.
La clase Customer representa un cliente de la tienda virtual. La subclase Who-

leSaler representa un cliente mayorista. La clase Supplier es la clase que repre-
senta un proveedor de la tienda.
La clase Order es una clase que representa un pedido realizado por un cliente a la
tienda virtual. La clase asociativa SubOrder entre Order y Product representa una
parte de un pedido realizado por un cliente de la tienda virtual, donde se especi-
fica cada uno de los productos que ha pedido y el nmero de unidades pedidas.
Para los tipos de producto se establece una jerarqua de herencia que une a la
clase Product con las subclases Computer, Device y DVD para tipificar los art-
culos que vende la tienda.
Se establecen relaciones de asociacin entre Customer y Order (ya que desde una
Order podemos acceder al Customer que la ha hecho efectiva) y entre Supplier y
Product (ya que desde un Supplier podemos acceder a los Products que suministra).
3) Identificacin de atributos y mtodos
La clase principal Store vendr caracterizada por un nombre y atributos que

implementen las asociaciones con el resto de objetos.
La subclase WholeSaler contiene los atributos relativos al cliente mayorista

ms el descuento aplicable.
La clase Order guarda el coste como la suma de los precios de todos los pro-
ductos pedidos. La clase asociativa SubOrder contiene como atributo el n-
mero de unidades solicitadas de cada producto en un mismo pedido. El cl-
culo se realiza a travs del mtodo computeCost de la clase Order, que a su vez
llama al mtodo computeCost de la clase SubOrder.
La clase Product es la que tiene la responsabilidad de almacenar los atributos

comunes a cualquier producto de la tienda virtual (identificador, nombre,
precio y cantidad en estoc). El proveedor asociado al producto se define con
el mtodo setSupplier. La clase Supplier suministra varios productos mediante
llamadas al mtodo supplies.
La clase Computer aglutina los atributos de un equipo informtico bsico de

la tienda virtual (el procesador, los megabytes de memoria RAM, y los giga-
bytes de capacidad del disco duro).
Dado que el enunciado no especifica muchas restricciones de cardinalidad, la

mayora de las asociaciones tienen cardinalidad mltiple, con la excepcin
de la relacin entre Supplier y Product, pues un producto slo puede ser ofre-
cido por un proveedor, y entre Order y Customer, pues un pedido slo es rea-
lizado por un cliente. Por otro lado, no se han definido restricciones de na-
vegabilidad, pues en principio desde cualquier clase se debera poder acceder
a los objetos de otra clase asociada.
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 especializada en material didctico para el aprendizaje de idio-

mas, desea automatizar la gestin de los gastos de sus trabajadores. Para
hacerlo, la editorial nos ha solicitado el desarrollo de un aplicativo que sea
capaz de registrar y calcular los gastos de estos trabajadores que se generan
durante su actividad laboral.
Kot tiene una divisin comercial que alquila vehculos para sus trabajadores.
Los vehculos alquilados son de dos categoras: utilitarios y de gama alta. Los
trabajadores de Kot se clasifican en responsables de la divisin, jefes inter-
medios y comerciales.
Son ejemplos de gastos a gestionar por el nuevo aplicativo: el kilometraje, la

limpieza del vehculo, las comidas, el alojamiento, el material promocional y
los regalos hechos a clientes.
A continuacin, se describen las funcionalidades que se desea que tenga el sis-

tema:
1) Aadir un nuevo coche al sistema: permite aadir un nuevo coche al sis-

tema, indicando la categora (utilitario o gama alta), la matrcula y el kilome-
traje total.
2) Aadir un nuevo trabajador al sistema: consiste en dar de alta en el sistema a

un trabajador, que puede ser comercial, jefe intermedio o responsable de la
divisin. De cada trabajador es necesario guardar su nombre, apellidos y cuenta
bancaria. Tambin queremos almacenar el precio por kilmetro que se pagar
al trabajador en caso de que no tenga coche de empresa asignado y se desplace
con su propio vehculo (para poderle compensar por el gasto que le supondra
el uso de su vehculo). El trabajador estar identificado por el documento de
identidad que haya aportado, del cual nos interesa el emisor (entidad legal que
emiti el documento identificativo), el tipo de documento (por ejemplo, pasa-
porte, documento nacional de identidad, etc.) y el nmero de ste.
3) Gestionar los clientes en el sistema: aadir y eliminar clientes del sistema. De

cada cliente nos interesa su nombre, apellidos, documento de identidad (emisor,
tipo y nmero), nombre de la empresa/institucin donde trabaja y la informacin
de contacto. Para eliminar el cliente, se marca ste como eliminado (no se elimina
fsicamente) y no se puede usar para ninguna nueva operacin, como podra ser
regalarle material. Aunque un empleado pueda ser cliente del sistema, por razones
de confidencialidad sus datos se tratarn en registros separados.
4) Aadir material al sistema: permite aadir un nuevo material, que son los
regalos que los comerciales harn a los clientes. De cada material nos inter-
esa la descripcin y el precio de coste.
5) Asignar un coche a un trabajador: Se asigna un coche de empresa a un

trabajador. Desde el momento en que un trabajador tiene coche de empresa,
no podr pasar ms gastos por kilometraje con su propio vehculo.
6) Registrar un gasto de un trabajador: hace falta almacenar informacin sobre

los gastos generales, como pueden ser lavar el coche, comida o alojamiento. De
los gastos interesa almacenar el concepto, que escribir el trabajador, el impor-
te y la fecha en que se produjo. Si el trabajador tiene coche de empresa, siem-
pre que llene el depsito deber rellenar un justificante de gasto especfico
donde tambin consten los litros que ha repostado y los kilmetros totales que
tiene el coche en ese momento. Todos los trabajadores, cada da que usen el
coche, ya sea privado o de empresa, rellenarn un gasto especfico indicando
los kilmetros que han hecho por trabajo. El trabajador puede haber hecho
ms kilmetros de tipo privado con el coche, tanto si el coche es de empresa o
de uso privado suyo, pero stos no se tienen que informar a la editorial. Ade-
ms, el trabajador deber aadir un justificante de gasto para cada material que
regale a un cliente, especificando la cantidad de cada material regalado, el
cliente que haya recibido el regalo y el motivo de dicho regalo.
7) Generar informe mensual de gastos: al final de cada mes, los trabajadores

indican a la empresa los kilmetros totales del coche. Por simplicidad, consi-
deraremos que a final de mes el depsito del vehculo estar vaco y que el
trabajador empieza y acaba el mes con el mismo coche. Cada mes se genera-
r un informe para cada trabajador que contiene la suma del importe de los
gastos a rembolsar al trabajador, y los datos del coche si el empleado tiene
coche de empresa.
Solucin:
Editorial (Kot)
Coche (Car)
Material (Material)
Persona (Person)
Trabajador (Worker)
Cliente (Customer)
Documento de Identidad (IdentityCard)
Gastos (Expense)
Gastos de Combustible (ExpenseGas)
Gastos de Kilometraje (ExpenseKm)
Gastos de Material (ExpenseMaterial)
Informe (Report)
En primer lugar, se ha modelado una clase principal Kot, que representa la

editorial y proporciona acceso a los objetos gestionados por el sistema, bsi-
camente objetos de tipo Car, Person y Material.
La clase Person es abstracta, puesto que representa la parte comn de las cla-
ses Worker y Customer y no tiene sentido instanciarla en el contexto del
enunciado.
Hay diferentes tipos de gastos. Algunos son generales, como pueden ser las
comidas, el alojamiento o el lavado del coche, que son representadas por la
clase Expense. De esta clase heredan ExpenseGas, ExpenseKm y ExpenseMaterial,
que representan respectivamente los repostes de combustible del vehculo de
empresa, los kilmetros recorridos con el coche y el material promocional
regalado a los clientes por los comerciales.
La clase asociativa Report incluye todos los datos necesarios para los informes
de gastos, y relaciona a los objetos de la clase Car con los de la clase Worker.
En la clase Car se ha creado un atributo category, que indica la categora del

vehculo: utilitario o gama alta. No hubiera estado justificado crear subclases
de Car para cada categora, debido a que no se almacena ningn dato espec-
fico sobre estas categoras. Asimismo, en la clase Worker se ha creado un atri-
buto type que nos indica el tipo de trabajador: comercial, jefe intermedio o
responsable de divisin. No hubiera sido necesario crear subclases de Worker
para cada tipo de trabajador, puesto que no se indica ningn tipo de atributo
o funcionalidad especfica para cada uno de ellos.
En cuanto a los mtodos identificados, la clase principal Kot incluye mtodos

necesarios para gestionar todos los objetos de la aplicacin (addCar, addWorker,
addCustomer, addStuff y reportExpense). La peticin de elaboracin de un infor-
me es tambin responsabilidad de la clase Kot, a travs del mtodo reportExpen-
se. Los gastos de un trabajador se habrn ido acumulando a travs de sucesivas
llamadas al mtodo reportExpense, que crear instancias nuevas de Expense del
tipo de que se trate y llamar a addExpense del objeto Worker para asociarlas al
trabajador en cuestin. Kot delegar en el mtodo expenseIterator de la clase
Worker para averiguar los gastos de un trabajador, sumarlos y, finalmente, lla-
mar a addReport para asociar el informe elaborado con el Car correspondiente.
Tambin se han aadido mtodos para asignar un coche a un trabajador,

tanto desde la clase Car (assignToWorker), como desde la clase Worker (as-
signCar). En cualquier caso, la llamada a alguno de estos mtodos proceder
del mtodo assignCar de la clase Kot.
En el diagrama, se reflejan las cardinalidades identificadas para cada asocia-

cin, as como las restricciones de navegabilidad en caso de que las hubiera
para la implementacin de los mtodos necesarios. La asociacin carAssign-
ment entre Car y Worker tiene cardinalidad 0..1 pues un trabajador puede
estar sin coche, y un coche puede estar an sin asignar a un trabajador.
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 ferrocarriles
La compaa ferroviaria TENFE, en vista de la cantidad de averas y el des-

contento de sus clientes, quiere disponer de una aplicacin que le permita
gestionar las averas de forma rpida y dar a la vez informacin actualizada a
los clientes.
TENFE quiere dividir las averas en tres tipos diferentes:
Averas generales (cualquier tipo de avera).
Averas elctricas (ms especficas, relacionadas con la catenaria y las l-

neas de tensin).
Averas en los trenes (relacionadas con los vagones y la locomotora).
Todas las averas tendrn una descripcin de la avera y una estimacin del
tiempo necesario para repararla. Las averas elctricas, adems, han de indi-
car el voltaje de la lnea y el tipo de corriente (alterna o continua).
Las averas en los trenes pueden ser de dos tipos: averas en la locomotora,
donde se deber indicar el tipo de la locomotora (diesel o elctrica) y el ao
de fabricacin; o averas en los vagones, donde deber de especificar si se
trata de un vagn de mercancas o pasajeros y el nmero de asientos. Ade-
ms, todas las averas en los trenes, sean del tipo que sean, han de indicar el
nmero de matrcula del vagn o locomotora. Las averas son excluyentes, es
decir, no pueden ser de dos tipos a la vez.
Para saber dnde se ha producido la avera, TENFE introducir en su sistema

la informacin de todas las lneas ferroviarias que controla. As, cada lnea
constar de:
El nombre de la lnea.
Todas las paradas de la lnea ordenadas, de forma que siempre podemos

saber cul es la primera y la ltima parada. Cada parada constar del nom-
bre de la parada, que debe ser nico en el sistema, la ciudad ms prxima, y
su posicin GPS (esto es, dos nmeros decimales que indican la latitud y
longitud de un objeto en el mundo). As pues, una ciudad grande como
Barcelona puede tener diferentes paradas, mientras que en una ciudad pe-
quea el nombre de la parada coincide con el de la ciudad. Por ejemplo:
Estacin de Sants, Barcelona, 41.38, 2.14

Fabra i Puig, Barcelona, 41.43, 2.18
Cerdanyola, Cerdanyola, 41.49, 2.14
Cada vez que se produzca una incidencia, se deber registrar un ticket con la
lnea donde se ha producido la incidencia, la parada, y el tipo de avera.
Adems, para asegurar la calidad del servicio y la reparacin, tambin se
guardar el nombre del mecnico que ha reparado la avera y el nombre del
inspector que ha revisado que todo funciona correctamente. Cada incidencia
tendr un identificador nico, y tendr asociada la fecha y la hora en que se
produjo la incidencia y cundo se solucion sta. Dicha informacin se utili-
zar para listar las averas ms recientes.
Segn la descripcin, cada incidencia puede estar en cuatro estados diferentes:
1) Nueva incidencia: cuando se ha dado de alta la avera pero todava no ha

empezado la reparacin.
2) En reparacin: cuando un mecnico ha sido asignado a reparar la inci-

dencia.
3) Reparada: cuando un inspector ha comprobado in situ que la avera est

reparada.
4) Descartada: si se comprueba que la avera es ficticia y se puede descartar.

Fijaos en que, para poder descartar una avera, debe pasar primero por todos
los dems estados. Slo cuando el mecnico asignado y el inspector com-
prueben que es ficticia, se podr descartar la avera.
Tanto los mecnicos como los inspectores son trabajadores de la compaa.

De todos ellos se deber guardar el nombre, un telfono de contacto y una
direccin. Adems, como trabajadores de la compaa, tienen un nmero de
trabajador y la fecha en que empezaron a trabajar.
Solucin:
TENFE
Trabajador (Worker)
Incidencia a Reparar (Ticket)
Ruta (Route)
Parada (Stop)
Estado de los Tickets (TicketStatus)
Avera (Breakdown)
Tipos de Averas (TrainBreakdown, ElectricBreakdown, GeneralBreakdown,
LocomotiveBreakdown y CoachBreakdown)
La aplicacin debe permitir controlar los trabajadores, las rutas y las inciden-
cias. Por ese motivo, hace falta una clase TENFE compuesta por trabajadores
(Worker), tickets de incidencias (Ticket) y rutas (Route). Hay una relacin de
agregacin entre TENFE y estas tres clases.
Expresar el estado de un ticket como una asociacin entre Ticket y TicketSta-

tus no es la nica opcin de modelado, pues los diferentes estados podran
estar tambin definidos dentro de la clase Ticket o como un tipo enumerado.
Los tickets mantienen una relacin con el tipo de avera (Breakdown), la para-
da donde se ha producido sta (Stop), los trabajadores que la han reparado y
supervisado (Worker) y su estado (TicketStatus).
Tiene sentido que una ruta siempre tenga al menos una parada. Como una
parada puede formar parte de ms de una ruta, la relacin entre ellas es de
agregacin (no excluyente) y no de composicin (excluyente).
Tambin tenemos la clase avera (Breakdown) y todas sus especializaciones.

Estas especializaciones pueden ser de tres tipos diferentes: averas de los tre-
nes (TrainBreakdown), elctricas (ElectricBreakdown) y generales (GeneralBreak-
down). Las averas de trenes (TrainBreakdown) pueden ser de dos tipos dife-
rentes (especializacin a uno de dos tipos): avera de la locomotora
(LocomotiveBreakdown) o avera de vagones (CoachBreakdown).
Otra decisin a tener en cuenta es el hecho de que las clases Breakdown y

TrainBreakdown son abstractas, con lo cual es necesario especificar cul de sus
subclases queremos crear.
Cada trabajador (Worker) contiene el identificador asignado por la empresa y

la fecha en que se firm el contrato.
Los tickets (Ticket) estn formatos por tres atributos (identificador, fecha de la
avera y fecha de la reparacin).
Cada clase de la especializacin de Breakdown tiene los atributos especficos del

tipo de avera, mientras que la superclase (Breakdown) contiene los atributos
compartidos por todas (descripcin, tiempo estimado de reparacin y matrcu-
la).
Como son slo dos valores para cada clase, hemos modelado los tipos de
vagn y de locomotora como atributos con valores booleanos (por ejemplo:
electricDiesel: true | false). Si se prev la existencia de ms tipos, podramos
haber definido atributos estticos con los tipos de vagn en CoachBreakdown,
y los tipos de locomotora en LocomotiveBreakdown, o bien en su superclase

(TrainBreakdown) o en alguna otra clase separada (por ejemplo, una denomi-
nada TrainType), pero nunca en la clase Breakdown, puesto que son demasia-
do especficos y slo tiles para las averas de trenes.
La navegabilidad entre Ticket y Stop se ha establecido en este sentido, para loca-

lizar la parada afectada por una incidencia. En principio, no tiene mucho senti-
do localizar los tickets de incidencias de una parada, aunque si as se quisiera
podra cambiarse la navegabilidad. No se ha restringido el resto de navegabili-
dades entre objetos de clases asociadas. Por ejemplo, la navegabilidad de las
asociaciones entre los Tickets y los trabajadores (Worker) se ha dejado en ambos
sentidos, ya que parece razonable querer localizar tanto los tickets de un trabaja-
dor como el trabajador que se encarga 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()
1 1
estimated : Date
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 Direccin General de Trfico TrafiUOC se ha planteado automatizar la

realizacin de pruebas de tipo test de los psicotcnicos necesarios en los
permisos de circulacin. A continuacin, se describen los requisitos del sis-
tema.
TrafiUOC desarrolla test de diferentes tipologas (segn la licencia que se

quiere obtener), por ejemplo ciclomotores (A1) y autobs con remolque (E2).
Interesa conocer el nombre y el cdigo de los diferentes tipos de test, y un
conjunto de descriptores asociados a ellos. Un ejemplo de descriptor del test
E2 sera Mecnica del remolque. Un descriptor puede describir a ms de
una tipologa de test. Cada pregunta de un test evala al menos a uno de
estos descriptores.
Un test se compone de un conjunto de preguntas, entre 15 y 20. De un test

se debe almacenar en qu tipologa se utilizar (A1, E2, etc.) y cul es su fe-
cha de creacin. En ocasiones, las preguntas se reutilizan en test diferentes,
por lo que una misma pregunta puede aparecer en ms de un test.
Un test tiene una puntuacin correspondiente a la suma de las puntuaciones

de las preguntas que contiene. La puntuacin de cada pregunta es un nme-
ro correspondiente a una puntuacin absoluta o a un porcentaje. Es posible
que una misma pregunta, en un test, tenga una valoracin de 1 punto, en
otro test de 0,5, y que en un tercero constituya el 5% de la nota final del test.
Los test estn compuestos de preguntas, todas con valoracin absoluta o
todas con valoracin porcentual. En ste ltimo caso, la puntuacin suma
exactamente 100%.
Cada pregunta describe un enunciado, las posibles opciones de respuesta y

los descriptores que evala. Existen diferentes tipos de pregunta en funcin
de sus opciones de respuesta: pregunta de respuesta simple, pregunta de res-
puesta mltiple y pregunta de ordenacin.
Por otro lado, las preguntas pueden definirse como dependientes o no depen-
dientes del tiempo cuando se asocian a un test determinado. En las primeras,
se requiere almacenar el tiempo estimado que el estudiante debera tardar en
elaborar su contestacin, y se define una penalizacin expresada como por-
centaje de la puntuacin de la pregunta, que se aplicar si el estudiante su-
pera el tiempo estimado al contestar. En el caso de las preguntas no depen-
dientes, estas dos caractersticas (tiempo y penalizacin) tienen un valor
nulo. Una misma pregunta puede ser dependiente del tiempo en un test e
independiente en otro test diferente.
La realizacin de un test por parte de un estudiante es siempre secuencial, es

decir, se le van mostrando las preguntas una a una, sin la posibilidad de re-
troceder. El orden de presentacin de las preguntas de un test se har de

manera aleatoria.
De los estudiantes slo nos interesa guardar su Nmero de Identificacin (NI),

ya que sus datos personales los trata otra aplicacin.
Cuando un estudiante conteste un test, se guardar su fecha de realizacin.

Tambin se deber guardar, para cada pregunta, la opcin u opciones de
respuesta que el estudiante ha seleccionado en su contestacin (y el orden de
seleccin, si es necesario). Finalmente, tambin se desea tener constancia del
tiempo invertido por el estudiante en la contestacin de cada pregunta, in-
dependientemente de si la pregunta es o no dependiente del tiempo. Toda
pregunta debe permitir comprobar si una contestacin concreta es, al mismo
tiempo, una respuesta correcta. Por ello, cada pregunta debe poseer una ope-
racin que comprueba si una contestacin de un estudiante determinado es
correcta o no.
Dada la descripcin del problema a resolver, se pide el diagrama UML que

incluya las clases, relaciones, atributos y mtodos que participan en el diseo
de las funcionalidades requeridas.
Solucin:
Test (Test)
Estudiante (Student)
Pregunta (Question)
Pregunta Simple (SimpleQuestion)
Pregunta Mltiple (MultipleQuestion)
Pregunta Ordenada (SortingQuestion)
Licencia (Licence)
Respuesta Correcta (CorrectAnswer)
Respuestas Test (AnsweredTest)
Respuesta Pregunta (AnsweredQuestion)
Respuesta Pregunta Simple (AnsweredSimple)
Respuesta Pregunta Mltiple (AnsweredMultiple)
Respuesta Pregunta Ordenada (AnsweredSorting)
Se detecta una jerarqua de herencia correspondiente a la tipologa posible de

preguntas. La clase Pregunta (Question) ser una clase abstracta de la cual
heredarn las clases Pregunta Simple (SimpleQuestion), Pregunta Mltiple
(MultipleQuestion) y Pregunta Ordenada (SortingQuestion).
Las opciones de respuesta posible de una pregunta se modelan mediante una

agregacin con subclases de la clase abstracta AnsweredQuestion.
Las respuestas correctas de las preguntas se modelan con otras asociaciones,

que tienen cardinalidades o restricciones diferenciadas de acuerdo con cada
tipo de pregunta. Una solucin alternativa sera utilizar un valor lgico para
indicar las respuestas que el usuario debe marcar, y en el caso de los test or-
denados, un entero que indique el orden. Se ha utilizado la restriccin UML
{ordered} en los elementos de respuesta ordenada. Esto se puede especificar
tambin en el lenguaje natural o bien aadiendo un atributo de la asociacin
con un nmero ordinal para indicar el orden correcto de las opciones de
respuesta.
Se identifican dos tipos de clases asociativas. La primera clase correspondien-

te a las propiedades de una pregunta en un test (QuestionProperties) represen-
ta que una QuestionProperties almacena las propiedades de una Question en un
Test. La segunda clase representa los test que ha respondido un alumno
(AnsweredTest) en una fecha.
Las caractersticas de las entidades se representan por medio de atributos y

mtodos de acceso. En cuanto al Test, es necesario almacenar atributos de
creacin del test (creationDate) y tipologa (type). En el caso de los estudiantes
(Student), es necesario su nmero identificador (NI). En el caso de la pregunta
(Question), se almacenan sus caractersticas propias y diferenciadoras para
cada tipo de test. El tiempo de respuesta de cada pregunta de un test se alma-
cena en la clase AnsweredQuestion, y la fecha de respuesta del test en la clase
AnsweredTest.
Las relaciones se establecen bidireccionales para facilitar los accesos.

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: deportes SportsUOC
SportsUOC es una empresa dedicada a la gestin de competiciones deporti-

vas. Para ello, es necesario obtener y gestionar la informacin relativa a
competiciones, equipos, jugadores y dems caractersticas que se detallan a
continuacin.
La empresa gestiona diferentes competiciones deportivas, con la caractersti-

ca comn de estar referidas a deportes de equipo donde los partidos finalizan
por tiempo. Son ejemplo de estas competiciones el ftbol, el baloncesto y el
balonmano.
Para cualquier competicin, es necesario almacenar la siguiente informacin:

cdigo de identificacin, nombre, nombre del deporte, nmero de equipos
participantes, nmero de jugadores necesarios por equipo en una competi-
cin, lista de equipos participantes, estado de la competicin (para empe-
zar, en juego o finalizada) y equipo ganador. Las competiciones podrn
ser de dos tipos: liga o copa.
El sistema de competicin de liga se caracteriza por que los equipos juegan

todos contra todos, en un sistema de una sola vuelta, de manera que, siendo
N (que tiene que ser par) el nmero de equipos participantes, el nmero de
jornadas es N 1. Cada jornada tendr un nmero de jornada que se asigna-
r de forma correlativa (1, 2, 3...) en orden cronolgico. En cada jornada se
juegan N/2 partidos. Al final de cada partido, en funcin del resultado (victo-
ria, empate o derrota), los equipos suman una determinada cantidad de pun-
tos (que se tendrn que especificar). Al final de la competicin, el ganador de
la liga es el equipo con ms puntos.
El sistema de competicin de copa es un sistema de eliminacin directa

hasta llegar a un partido final que determina el ganador. Por lo tanto, en
este caso el nmero de equipos participantes (N) tiene que ser potencia de
2. El nmero de partidos que se juegan en cada jornada (que en este siste-
ma suelen llamarse rondas) es sucesivamente N/2, N/4... hasta llegar al par-
tido final. As, el nmero de jornadas (incluyendo el partido final) con este
sistema es log2N. En este caso, para asignar el nmero de jornada utiliza-
remos el nmero de partidos a jugar. As, por ejemplo, en una competicin
de copa con 16 equipos participantes, tendremos 4 jornadas, numeradas de
la manera siguiente: 8 (octavos de final), 4 (cuartos de final), 2 (semifina-
les) y 1 (final).
De cualquier competicin nos interesar poder listar los resultados de los

partidos de una determinada jornada. De las competiciones de liga, adems,
se tendr que poder listar la clasificacin (listado ordenado de los equipos,
en funcin de los puntos obtenidos por cada uno desde el inicio de la com-
peticin hasta la ltima jornada jugada).
De las jornadas se almacenar el nmero de la jornada, el nmero de parti-

dos a disputar en la jornada y los partidos que se juegan.
De los partidos se almacenarn los equipos que han jugado y los goles ano-
tados por cada uno de ellos.
De cada equipo guardaremos el cdigo de identificacin, nombre, deporte,

lista de jugadores, entrenador y lista de competiciones inscritas. Un mismo
equipo puede participar en ms de una competicin de su deporte.
De los jugadores y de los entrenadores se necesita el nombre, DNI, equipo al

que pertenecen y el sueldo base. Los entrenadores tienen una prima adicio-
nal por competicin ganada. No existe la posibilidad de que un entrenador
sea tambin un jugador.
La aplicacin deber permitir aadir y eliminar una competicin, listar com-

peticiones, iniciar y finalizar competiciones. Adems, deber permitir la ges-
tin de personas: aadir personas, listar personas y listar el sueldo de una
persona. Finalmente, tambin deber permitir la gestin de equipos: aadir
equipos, listar equipos, aadir el entrenador de un equipo, aadir un jugador
a un equipo, listar la plantilla de un equipo, aadir un equipo a una compe-
ticin, aadir una jornada a una competicin, aadir partido a una jornada,
listar los resultados de los partidos de una jornada, listar la clasificacin de
una determinada competicin y mostrar el equipo campen de una compe-
ticin.

Solucin:
Equipo (Team)
Competicin (Competition)
Liga (League)
Copa (Cup)
Jornada (Round)
Persona (Person)
Jugador (Player)
Entrenador (Trainer)
Partido (Match)
Las caractersticas comunes de Entrenador y Jugador se modelan en la clase

abstracta Persona.
Existe una segunda jerarqua de herencia correspondiente al tipo de compe-

ticin: liga o copa.
La clase SportsClub representa la empresa gestiona el un conjunto de equipos,

competiciones y personas.
Cada jornada consta de un conjunto de partidos, por lo que se ha modelado

una agregacin entre Jornada (Round) y Partido (Match).
Cada competicin consta de un conjunto de jornadas (Round), que se mode-

lan a travs de una agregacin.
El nmero de goles que gana un equipo en un partido se modela a travs de

la clase asociativa MatchTeam.

mtodos de acceso. Los ms relevantes corresponden a los atributos de la
Competition, Team, Person, Round y Match. En el caso de los entrenadores
(Trainer), se aade el atributo que permite gestionar su prima salarial.
Se establece navegabilidad direccional para las relaciones implicadas. En el

caso de la relacin que identifica un equipo ganador de una competicin, se
establece una relacin 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: aplicacin TV
Una importante productora televisiva ha aumentado su volumen de negocio

de modo espectacular, por lo que ha decidido encargarnos una nueva herra-
mienta para gestionar los programas, cadenas y personal implicado.
De los programas interesa registrar la informacin referente a su identifica-

dor, nombre, descripcin, presentadores del programa, lista de emisiones,
fecha de inicio y si se encuentra actualmente en emisin. Los programas de
la productora televisiva se clasifican en programas de divulgacin, competi-
ciones y entretenimiento/tertulia.
De los programas de divulgacin se debe almacenar la informacin referente

a su impacto previsible, segn el cdigo establecido por la asociacin de
programas divulgativos. De los programas de competiciones, donde el obje-
tivo es conseguir un premio, se deben almacenar las caractersticas de ste.
De los programas de entretenimiento/tertulia es necesario almacenar el tema
de discusin.
Los programas de la productora son tan exitosos que se emiten diversas veces
por diferentes cadenas de emisin. En cada emisin del programa, se selec-
cionan los invitados que participaran en el programa, si es preciso. De cada
emisin se almacena en qu cadena se emite y la fecha de emisin. De cada
cadena interesada en emitir los programas la productora almacena su identi-
ficador, el nombre, la direccin y un telfono de contacto.
El equipo humano considerado importante por la productora, en esta ges-

tin, lo forman los presentadores y los invitados. De todos ellos es necesario
almacenar el DNI, nombre, apellidos, direccin y telfono. Adems, de los
invitados se deber guardar su especialidad, as como mantener un control
de las emisiones en las que ha participado. De los presentadores interesa
conocer de qu programas lo son actualmente, as como su experiencia, me-
dida en nmero de programas en los que ha participado a lo largo de su ca-
rrera en la productora. El modo ms habitual de contactar con los presenta-
dores es mediante el correo electrnico, y por tanto, el aplicativo debe
ofrecer la posibilidad de almacenar dicho dato.
El nuevo aplicativo debe gestionar los programas, personas, cadenas, emisio-

nes, permitiendo aadir y listar su informacin relevante, y adicionalmente,
asignar o eliminar presentadores a un programa, aadir invitados a una emi-
sin, listar la programacin para un intervalo de tiempo y asignar un programa
como fuera de emisin, siempre que no haya emisiones pendientes del mismo.
No se descarta, en un futuro cercano, que se aadan nuevas topologas de pro-
gramas o roles del personal de la productora; por tanto, la aplicacin debe
disearse teniendo en cuenta estos aspectos.
Dada la descripcin del problema a resolver, se pide el diagrama UML que in-
cluya las clases, relaciones, atributos y mtodos que participan en el diseo de
las funcionalidades requeridas.
Solucin:
Productora (Producer)
Cadena (Channel)
Presentador (Presenter)
Invitado (Guest)
Emisin (Broadcasting)
Programa (Program)
Programa Entretenimiento / tertulia (Entertainment)
Programa de Divulgacin (NewsReport)
Programa de Competicin (Competition)
La informacin comn a Presentador e Invitado se modela en una nueva

clase Persona, que contiene la informacin comn entre ambos.
Existe una jerarqua adicional de herencia correspondiente a la tipologa del

programa, ya que cada uno de ellos se especializa con informacin caractersti-
ca.
Una Productora (Producer) consta de un conjunto de Canales (Channel), que

se representa mediante la agregacin Producer-Channel. Se asume que el pre-
sentador y los invitados forman parte del programa en curso, y por ello se
modela una agregacin Producer-Person. Un programa forma parte de un
conjunto de emisiones. Por ello, se modela una agregacin entre Program-
Broadcasting.
La asociacin entre presentadores y programas puede modelarse como una

clase asociativa que almacena la fecha de grabacin.
3) Inclusin de mtodos, atributos y relaciones

mtodos de acceso. Los ms relevantes corresponden a los atributos del Ca-
nal (Channel), Programa (Program), las caractersticas comunes a invitados y
presentadores en Person, y las caractersticas especficas correspondientes a
cada tipo de Programa y a invitados en forma de atributos en la subclase
correspondiente.
Se establece navegabilidad direccional para las relaciones implicadas para

facilitar la gestin de listados y acceso a la informacin.
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 multimedia
Una organizacin no gubernamental, veterana en proyectos internacionales de

desarrollo, desea disponer de un aplicativo para la gestin de los contenidos
multimedia que sus cooperadores han ido aportando con el paso del tiempo.
Los contenidos son de topologa diversa, bien en formato digital o en cualquier

otro formato, que se convierte a formato digital antes de almacenarse. El apli-
cativo debe permitir la gestin de dichos contenidos, evitando que ms de un
cooperante pueda modificar un mismo material de modo concurrente (de otro
modo, podra producirse la prdida de las modificaciones), as como limitando
el acceso a los contenidos a los diferentes tipos de cooperantes (roles). De este
modo, un cooperante que desarrolle, por ejemplo, su labor en frica, tendra
acceso de autor (lectura y/o modificacin) a los contenidos relacionados con
frica; tendra acceso de lector (slo lectura) a los contenidos relacionados con
Asia, y no tendra acceso a los contenidos internos de la organizacin.
De los contenidos multimedia a gestionar interesa almacenar la siguiente

informacin: identificador, una breve descripcin y la ruta de acceso al ar-
chivo (filepath).
Existen diversos tipos de contenidos a almacenar: imgenes, audio, vdeos y

documentos ofimticos, aunque no se descarta aadir nuevas tipologas de
contenidos en un futuro prximo.
De los contenidos de tipo imagen (fotografas, escaneados...) interesa alma-

cenar el formato (png, jpeg, etc.), el ancho y la altura en pxeles. De los con-
tenidos audio (registro de msica local, conversaciones) interesa almacenar
el cdec (por ejemplo MPEG Layer-3 o Vorbis Ogg ACM), la duracin en
segundos y los idiomas en que se encuentra disponible. De los vdeos, inter-
esa la misma informacin que los contenidos de audio, el cdec de vdeo
(por ejemplo, DivX 5.0 o xvid) y los idiomas de subttulos disponibles. Fi-
nalmente, los documentos ofimticos para evitar problemas de compatibi-
lidad se guardan nicamente en formato Portable Document Format (PDF)
si se trata de documentos que debern imprimirse o publicarse en papel, o
bien en formato ISO/IEC 26300 (OpenDocument) si se trata de documentos
de procesador de textos, hojas de clculo o presentaciones.
El aplicativo debe gestionar, tambin, la creacin de cooperantes y roles con

los que se accede a los documentos del sistema. Cada vez que un nuevo do-
cumento multimedia se aada al sistema, ser necesario especificar qu roles
pueden acceder a l (en modo de lectura y escritura). De este modo, cuando
un usuario desee acceder a un documento especfico, se comprobar si el
cooperante puede acceder al documento y con qu rol. Si el cooperante pue-
de acceder al documento, se le facilitarn los datos para acceder a ste, siem-
pre que no est siendo usado por ningn otro cooperante.
En base a esta descripcin, las funcionalidades que debe proporcionar el

aplicativo son referentes a la gestin de cooperantes, roles y contenidos mul-
timedia.
Respecto a la gestin de cooperantes y roles, la nueva aplicacin debe permi-

tir aadir y eliminar cooperantes, roles, asignar y desasignar roles a los co-
operantes, listar cooperantes y roles, listar contenidos del cooperante y per-
mitir que un cooperante, si dispone de permisos, edite un contenido.
En cuanto a la gestin de contenidos multimedia, el aplicativo debe permitir

aadir y listar contenidos por tipologa.

Solucin:
Contenido (Content)
Contenido Imagen (Image)
Contenido Audio (Audio)
Contenido Vdeo (Video)
Contenido Documento (Document)
Cooperador (Cooperator)
Rol (Role)
La clase ONG representa la ONG con un nmero de contenidos, roles y co-

operadores. Dicha representacin se modela con agregaciones de ONG a Con-
tent, Role y Cooperator.
Existe una jerarqua de herencia correspondiente a la tipologa del Contenido

que especializa en Image, Audio y Document. Video, a su vez, hereda de Audio.
Se modelan las siguientes relaciones binarias: Contenido-Cooperador, Coopera-

dor-Rol, Contenido-Rol (lector) y Contenido-Rol (autor).

mtodos de acceso. Los ms relevantes corresponden a los atributos del Con-
tenido (Content) y las caractersticas especficas correspondientes a cada tipo
de Contenido (Image, Audio, Document, Video).
4) Cardinalidad y navegabilidad de las relaciones
Se establece navegabilidad direccional de las relaciones implicadas para faci-

litar la gestin de listados y acceso a la informacin.
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

Parte III. Problemas propuestos (sin solucin)
Problema 1: gestin de nminas
Una gran empresa se plantea construir un programa para gestionar las n-

minas de sus empleados. La empresa tiene distintas tipologas de empleados
y, dependiendo de la tipologa, un empleado debe percibir unos pluses u
otros en funcin de un conjunto de objetivos.
Los distintos tipos de empleados que tiene la empresa son: administrativos,

comerciales, personal de logstica, personal de limpieza, directores (generales
y departamentales) y marketing.
Todos los empleados tienen un sueldo base, que se calcula del siguiente modo:
Los comerciales aaden a su sueldo un plus para desplazamiento y otro

segn sus ventas.
Los administrativos tienen un plus para las comidas (dado que estn en
una zona industrial ligeramente apartada).
El personal de logstica tambin tiene el plus para las comidas y, dado que
por turnos realizan tareas por la noche, tambin tienen un plus por noc-
turnidad.
El personal de limpieza tambin tiene un plus por nocturnidad, pero al

tener un turno ms reducido no tienen otros pluses.
Los empleados del departamento de marketing tienen un plus por despla-

zamiento, que depende de los viajes que realicen, y otro para la comida.
Finalmente, los directores, bien sean departamentales o directores generales,

tienen, aparte de un sueldo base, una cuenta de gastos de hasta 6.000 euros
al mes, para invertir en restaurantes, desplazamientos y gastos de representa-
cin. En caso de superarse dicho importe, la diferencia se le descuenta de la
nmina. El dinero no gastado no se acumular para siguientes meses.
Problema 2: empresa en lnea
Una empresa, que tiene una pgina web en la que nicamente se muestra
informacin sobre sus productos, quiere ahora aadir un sistema para ges-
tionar sus pedidos a travs de Internet.
Los usuarios rellenan su carrito de la compra a medida que van navegando,

por lo que en cualquier momento pueden consultarlo (de cada producto se
requiere que se muestre una pequea descripcin, el precio y la cantidad
pedida).
Posteriormente, cuando se produce el proceso de compra, dependiendo de la

cantidad pedida, se debe aplicar un descuento u otro (por ejemplo, si se pi-
den ms de 5 unidades, se aplicar un 5% de descuento). Adems, se han de
aadir los gastos de envo, pero si el valor total de la compra (sin contar los
gastos de envo) supera los 200 euros, dichos gastos son asumidos por la
empresa.
Problema 3: MEC
El Ministerio de Educacin y Ciencia est interesado en conocer los libros de

texto que ms se utilizan en las titulaciones universitarias espaolas. Para
ello, nos ha encargado disear un programa que permita obtener qu textos
son los ms referenciados en los programas oficiales de las asignaturas.
Las diferentes universidades estructuran el plan de estudios de cada una de

sus titulaciones en forma de asignaturas. De cada asignatura se deber saber
el curso, el semestre en que se imparte (se supondr que todas son semestra-
les) y los crditos asignados. Es importante considerar que cada universidad
puede tener el plan de estudios de una misma titulacin estructurado de
diferentes formas, con diferentes asignaturas y diferente disposicin en cur-
sos, pues los planes de estudio suelen cambiar. Del plan de estudios slo es
necesario conocer el ao en que se aprob.
El Ministerio de Educacin quiere poder generar listados ordenados de todas

las asignaturas de una cierta titulacin y un plan de estudios dados. El orden
del listado de asignaturas ser alfabtico o por nmero de curso (y dentro de
un curso alfabticamente), aunque no se descartan otros tipos de ordenacin
en el futuro.
Problema 4: personal PIKAPLUS
La empresa PIKAPLUS quiere informatizar su sistema de gestin del personal

asignado a proyectos de desarrollo de software. Para ello, un primer paso es
la definicin de un modelo flexible de los roles profesionales de sus emplea-
dos dentro de los proyectos.
La empresa tiene contratados en plantilla una serie de empleados de distin-

tos perfiles profesionales. Aunque los diferentes roles estn fijados a priori,
podran definirse otros nuevos roles en el futuro. En el momento actual, los
roles son los siguientes:
Jefes de proyectos, para los cuales se debe conocer qu proyectos estn

dirigiendo bajo este rol. Un empleado puede dirigir ms de un proyecto.
Analistas, para los cuales se debe conocer de qu modelos (diagramas de

clases, casos de uso, diagramas de secuencia, etc.) son responsables.
Programadores, para los cuales se deben conocer los ficheros fuente de los
que son responsables.
Los modelos y los ficheros fuente son dos tipos de entregable. De un entre-
gable se sabe a qu proyecto pertenece. Un entregable no puede compartirse
entre distintos proyectos.
Un mismo empleado puede, simultneamente, cubrir el mismo o diferentes

roles en distintos o el mismo proyecto. Por ejemplo, una persona puede estar
haciendo de analista en un proyecto, y de programador en otro, o puede
estar haciendo a la vez de analista y programador en el mismo proyecto.
Adems, el tipo de rol que un empleado desempea en un proyecto no es
permanente, sino que puede cambiar a lo largo del desarrollo del proyecto.
Por ejemplo, una misma persona puede ser jefe de proyecto para dos proyec-
tos distintos, y ms tarde se promociona a uno de los analistas del segundo
proyecto para que le sustituya como jefe de proyecto.
Cada vez que una persona juega un rol en un proyecto, se le asignar un

nmero de horas de esfuerzo que debe dedicar. As, por ejemplo, puede que
Juan Prez sea Jefe de Proyecto con 50 horas de esfuerzo en el Proyecto
1 y, adems, sea Analista en el Proyecto 2 con 30 horas de esfuerzo, y
adems sea Programador en el Proyecto 2 con 80 horas de esfuerzo.
El objetivo del sistema es realizar una estimacin de costes de los proyectos. A

efectos de estimacin de costes, cada rol tiene una tarifa fija asignada. Por
ejemplo, Jefe de Proyecto ser 2.500 por P/M, mientras que Programa-
dor ser de 1.500 por P/M. (P/M = Persona/mes, es decir, el coste de una
persona trabajando durante un mes en un proyecto) (1 mes = 160 horas).
Se pide el diagrama UML con las clases, atributos y relaciones entre clases
necesarias para modelar el clculo del coste estimado de un proyecto.
Problema 5: juegos de tablero
Se quiere disear un aplicativo que represente distintos juegos de tablero,

como el ajedrez (chess), las damas (draughts), los barquitos (battleship), etc.
Todos ellos comparten una clase Board, que representa al clsico tablero cua-
driculado de dimensiones N M que se usa para jugar. El tablero diseado
debe ser vlido para todos esos juegos, que comparten la disposicin de las
casillas y la manera de acceder a las casillas mediante un par de coordenadas.
Los juegos en cuestin estarn diseados en clases aparte; una de estas clases,
llamada Game, estar unida al tablero mediante una relacin de asociacin.
El juego en cuestin va a pedirle al tablero poder colocar piezas o fichas en
sus casillas. Cada juego ofrece un conjunto de piezas de tipo distinto:
El ajedrez tendr rey (King), reina (Queen), torre (Rook), alfil (Bishop), caba-
llo (Knight) y pen (Pawn), todas ellas de tipo ChessPiece y ocupando una
casilla.
Las damas slo tendrn piezas de tipo dama (Draught), que ocupan una
casilla.
El juego de los barcos tendr fichas de tipo barco (Ship), que tienen la parti-
cularidad de ocupar ms de una casilla, todas ellas adyacentes. Hay fichas
de tamao 1 casilla (dragaminas o minesweeper), 2 casillas (fragatas o frigate),
3 casillas (cruceros o cruiser), y 4 casillas (portaaviones o aircraft carrier).
Todas las piezas, sean del juego que sean, tienen un color para identificar el
jugador al que pertenecen.
El tablero debe incluir el modelado de la funcionalidad de colocar una pieza

en una casilla y de comprobar si una casilla del tablero est ocupada por
alguna pieza. Tngase en cuenta que, si las piezas ocupan ms de una casilla,
no podrn ser colocadas si stas se salen del tablero.
Se pide disear el UML que incluya las clases, asociaciones y atributos nece-
sarios para modelar el tablero y las piezas de una forma reutilizable para los
distintos juegos, as como modelar las operaciones de colocar una pieza en
una casilla y averiguar si una casilla del tablero est ocupada.
Problema 6: el futuro de la tierra
Un viajero del futuro nos ha planteado resolver el siguiente problema, basa-

do en las futuras votaciones terrcolas:
Se supone que estamos en el planeta Tierra en el ao 3010. En este tiempo,

los robots han evolucionado tanto que hace ya aos que son considerados
ciudadanos, con casi los mismos derechos que los humanos. Adems, existe
una nueva civilizacin, los Tcitizens, que conviven con los terrcolas.
La Tierra est organizada en BigCitys, ciudades enormes. Los dirigentes de las

BigCitys consideran que los Tcitizens deben ser considerados ciudadanos y
deben disponer de los derechos que ya tienen personas y robots, entre los
cuales est el de poder participar en votaciones de referendos.
El Gobierno de las BigCity se basa en referendos semanales, donde los ciuda-

danos son consultados sobre los temas a resolver. Las votaciones se hacen a
travs de una red de comunicaciones, donde cada ciudadano puede votar: 1
(muy en desacuerdo), 1 (muy de acuerdo) 0 (abstencin). Este sistema permi-
te medir el grado de aceptacin o satisfaccin de los ciudadanos ante una ini-
ciativa del Gobierno. El recuento es una media ponderada de todas las vota-
ciones (el voto de los robots se considera medio voto). El voto no es totalmente
annimo, ya que se guarda el cdigo del ciudadano (un cdigo de cifras y le-
tras). Este sistema se hizo as para evitar que una persona votara dos veces
(simplemente comprobando que no hay dos cdigos repetidos en un referen-
do). Cada voto incluye el da y la hora en que se ha emitido el voto.
Los gobernantes de la BigCity han convocado un referendo a los ciudadanos

actuales con la pregunta: Los Tcitizens han de ser considerados ciudadanos
de la BigCity?.
Problema 7: reparacin de calzado elReparador
Una pequea empresa familiar de reparacin de calzado, elReparador, cons-

ciente de la crisis econmica que afecta el pas, ha decidido motivar a sus
empleados incrementando su salario en funcin de los clientes atendidos y
de los clientes nuevos.
La empresa elReparador desea centrarse en una parte del aplicativo de ges-

tin de empleados: la parte responsable del incremento de sueldo.
Los empleados se dividen en dos: los responsables de atender a los clientes y

reparar el calzado, y los comerciales, encargados de captar nuevos clientes.
Para los primeros, se incrementar su sueldo en euros (valor entero), segn

los clientes atendidos. La frmula de clculo de sueldo, ser:
sueldo_final = sueldo_base + num_clientes 2 euros
Para los segundos, se incrementar porcentualmente el sueldo en funcin de

las ventas del mes. La frmula de clculo del sueldo para las comerciales ser:
sueldo_final = sueldo_base + sueldo_base coeficiente_ventas
dos que participan en el diseo de la funcionalidad requerida.
Problema 8: gestin de trabajadores de unos grandes almacenes
Unos grandes almacenes nos han encargado una aplicacin para la gestin
de sus trabajadores.
En esta empresa, existen diversos tipos de trabajadores. Por un lado, los ven-
dedores, los cuales son los encargados de hacer el mximo nmero posible
de ventas, ya que reciben una pequea comisin por cada venta. Por otro
lado, los directivos, que se dedican a monitorizar el funcionamiento correcto
de su rea (organizar sus vendedores, elegir los productos que se vendern,
dnde se situarn, etc.). Adems, cada directivo tiene un gestor administrati-
vo que se encarga de las cuestiones jurdicas y administrativas. Supondremos
que tanto los gestores administrativos como los vendedores tienen como
responsable a un nico director.
De momento, y con vistas de ampliar el proyecto en un futuro prximo, se

nos ha encomendado la tarea de centrarnos en el clculo del sueldo de los
trabajadores.
El sueldo de un gestor administrativo es fijo (1.000 euros); los vendedores, en

cambio, con la finalidad de motivarlos para vender el mayor nmero posible
de productos, tienen una parte fija de sueldo (900 euros) ms unas comisio-
nes que representan un 5% del importe vendido. Finalmente, los directivos
cobran una base fija (3.000 euros) ms una comisin de todas las ventas
realizadas por los vendedores a su servicio (2%).
A final de mes, el contable de la empresa desea obtener un listado de todos

los trabajadores de la empresa, con su NIF y sueldo a cobrar, para ingresarlo
en el nmero de cuenta correspondiente.
Dado que es previsible que aparezcan nuevos tipos de trabajadores, es nece-

sario que el sistema de listados anterior sea suficientemente genrico para no
reimplementar la gestin del listado de sueldos, cuando se aada un nuevo
tipo de trabajador, y que, al mismo tiempo, este listado los incluya.
Problema 9: BarCeloNA Noches De Fiesta
El Ayuntamiento de Barcelona, despus de muchos aos de organizar even-

tos festivos, quiere externalizar todas las tareas de gestin de espacios y per-
misos, por lo que propone crear una empresa (BCN_NDF) que se encargue de
gestionar todas las fiestas nocturnas que se lleven a cabo en la ciudad para,
posteriormente, dotar de recursos de seguridad y limpieza (aunque esto ya lo
realizarn otras aplicaciones).
En principio, se ha decidido dividir las fiestas segn las tendencias musicales

que se escucharn en ellas, para no poner demasiado cercanas tendencias
musicales conflictivas. Se ha decidido dividir los eventos en fiesta popular,
discoteca y concierto (pudindose ampliar los tipos de eventos en un
futuro si fuera necesario). Aparte, se deben tener almacenados los recintos,
con una descripcin, la capacidad, direccin, etc. Cada una de estas fiestas se
realiza en una localizacin que debe estar previamente definida dentro de los
sistemas de BCN_NDF.
Cada fiesta tendr un organizador, que ser el encargado de realizar todas las
peticiones a BCN_NDF. Para cada una de las fiestas se pueden contratar un
conjunto de servicios, por ejemplo, limpieza del recinto, montaje del escena-
rio, etc. Cada uno de estos servicios tiene un coste asociado que, en princi-
pio, no variar en el tiempo (para simplificar el modelo). Estos servicios se
pueden contratar en cualquier momento hasta que el evento ya se ha produ-
cido.
En el caso de que ocurra algn incidente, se quiere registrar, dado que en-
tonces, para futuras convocatorias del mismo organizador, se pueden dene-
gar peticiones o establecer condiciones ms restrictivas.
Problema 10: la biblioteca
La biblioteca de nuestro pueblo quiere informatizar todo el proceso de prs-

tamo de libros y revistas que tiene (actualmente, se usan fichas para cada
ejemplar y llevan toda la gestin con papel y lpiz).
Para ello, nos han pedido que les ayudemos, por lo que hemos estado una
semana junto a ellos para captar su modo de proceder, y poder ofrecerles un
programa que se adapte totalmente a sus necesidades.
Hemos detectado que cada ejemplar de libro, revista, pelcula (tanto en VHS
todava tienen algunas as y los socios las piden como en DVD) tiene su
correspondiente etiqueta con un identificador. Para cada identificador, tie-
nen una ficha con un conjunto de datos caractersticos del ejemplar corres-
pondiente (por ejemplo, de los libros tienen las pginas y la edicin; de las
revistas, la editorial, el nmero, el mes y el ao; de las pelculas, el formato y
la duracin; y, en el caso de los DVD, los idiomas).
De los socios tienen, en un conjunto de fichas aparte, sus datos de contacto

y el historial de prstamos realizados por cada uno de ellos (para cada prs-
tamo guardan la fecha de inicio, la de fin y si sufri retraso en la devolu-
cin).
Adicionalmente, y gracias a las nuevas tecnologas, quieren poder realizar

bsquedas (e imprimir listados), tanto por los autores de los libros como de
los artculos que aparecen en las revistas (que tambin deberemos introducir)
y por los actores que aparecen en las pelculas.
Problema 11: la agenda del banco
Una entidad bancaria quiere mantener una agenda de las reuniones y citas
con clientes que tienen sus empleados. De cada evento se quiere saber la
fecha, hora de inicio y duracin.
Las reuniones son para la realizacin de trabajos dentro de los distintos grupos
de trabajo instaurados en el banco, y las citas son peticiones que realizan los
clientes para la realizacin de cualquier tipo de consulta sobre sus cuentas.
Las citas son pedidas con antelacin por los clientes y, posteriormente, el
empleado acepta o rechaza la cita segn su disponibilidad (esta respuesta es
notificada al cliente mediante el correo electrnico). Las citas rechazadas son
eliminadas del sistema. Las citas aceptadas aaden un campo de texto con el
nombre de la sala donde se realizarn.
Aparte, el empleado puede dar de alta una cita directamente si el cliente se

presenta en la oficina sin cita previa.
Las reuniones son convocadas por un empleado, el cual introduce una cade-
na de texto con el tema a tratar y la manda a los distintos asistentes, que
deben aceptar la peticin igual que hacen con las citas de los clientes.
Los empleados estn localizados en oficinas, por lo que las citas nicamente
pueden ser de clientes de sus oficinas; las reuniones no tienen en cuenta esta
restriccin, ya que puede haber grupos de trabajo de distintas oficinas.
Un empleado no puede tener una reunin y una cita en el mismo momento,

por lo que en el instante de confirmar cualquier evento se debe comprobar
que no exista ningn otro evento en esa fecha y hora (sin confirmar, puede
haber tantos eventos como se quiera al mismo tiempo).
Adicionalmente, se deben poder realizar listados para obtener los calendarios

de cada empleado (diarios, semanales y mensuales), as como resmenes del
tiempo empleado en cada tipo de evento.
Problema 12: editorial de coleccionables
Una editorial est empezando a tener problemas con la distribucin de sus

productos. Hasta el momento, stos se distribuan nicamente en los quios-
cos, pero ahora, con el auge de Internet, los clientes pueden hacer sus pedi-
dos a travs del portal web de la editorial.
Los clientes deben poder realizar los pedidos en los quioscos (de los cuales
almacena la direccin y el telfono para confirmar las entregas), y por Inter-
net (en este caso, la direccin ser la de cada cliente para poder enviarles los
productos directamente). Para facilitar su gestin, los clientes nicamente
pueden estar inscritos en uno de los dos mtodos de distribucin.
Los productos disponibles son colecciones que estn formadas por un con-
junto de productos (libros, juegos, etc.), todos ellos del mismo tipo. De cada
producto interesa guardar sus datos bsicos (de los libros, el ttulo y el autor;
de los juegos, la plataforma y el tipo de soporte, etc.).
Adems, se necesita realizar cualquier operacin de alta, baja y modificacin

de los productos y de las colecciones (en este caso, no se podrn realizar
modificaciones a partir de la fecha de publicacin), as como tambin de la
suscripcin de los clientes a las colecciones.
Adicionalmente, para cada cliente se necesita consultar la direccin de en-

trega y las colecciones a las que est suscrito, as como tambin el ltimo
ejemplar mandado.
Problema 13: el lector de correo electrnico
Queremos desarrollar un programa lector de correo, pero, antes de desarro-

llar toda la parte de comunicaciones y representacin de la informacin,
queremos tener claro el modelo que vamos a emplear para almacenar los
datos.
La aplicacin debe permitir recibir mensajes de distintas cuentas, por lo que

para cada cuenta se debe poder definir los distintos parmetros de acceso
(nombre y password). Recordemos que las cuentas son principalmente de dos
tipos (POP3 e IMAP), pero en un futuro se pueden aadir otras cuentas como
los WebMail.
Los mensajes contienen informacin como el origen, el destino, la cabecera

y el cuerpo: una vez descargados de los servidores, los mensajes se almace-
nan en uno de los buzones existentes.
Cada buzn puede tener distintas carpetas (y subcarpetas) donde almacenar

los mensajes. Los buzones se identifican por un nombre y una localizacin, y
contienen informacin sobre los mensajes que hay almacenados en l (el
nmero, tamao total y los mensajes sin leer).
Para facilitar el tratamiento de los mensajes, se deber permitir definir unos

filtros para que los mensajes se almacenen directamente en una carpeta. De
cada filtro necesitaremos saber el nombre, el filtro y si est activo o no.
Problema 14: la escuela de primaria
La direccin de una escuela de primaria nos ha encargado la gestin de una

aplicacin informtica. Una vez realizado un pequeo estudio de la misma,
disponemos de la siguiente informacin:
1) Hay cuatro estadios en la educacin primaria: Educacin Infantil, Ciclo

Inicial, Ciclo Mediano y Ciclo Superior. De todos ellos, debemos disponer
de los datos del alumno (nombre, apellidos, vacunacin) y de su informa-
cin familiar (domicilio, nombre del padre y de la madre y un telfono de
contacto).
2) Adicionalmente, de los alumnos de Educacin Infantil y Ciclo Mediano,

debido a su edad, debemos disponer de los datos de su pediatra (nombre,
apellidos, telfonos), a fin de que si hay cualquier tipo de problema (por
pequeo que sea) podamos llamarlo.
3) De los profesores, interesar guardar informacin personal: DNI, nombre,

apellidos, telfono, titulacin, especialidad y antigedad.
4) Los profesores de la escuela tienen asociado un nmero de nios (que

denominaremos aula) y cada uno de los nios tiene, del mismo modo, un
aula asignada. Consideraremos que, en un aula, no puede haber ms de 30
alumnos.
5) De las aulas interesa guardar un identificador, el curso, el nombre de una

especie animal (a los nios les gusta) y el nombre de la planta donde est
ubicada. No hay cambios de profesores o nios en un aula; una vez asigna-
dos, son permanentes.
Problema 15: oh no!, ms ftbol!
Con previsin de una competicin futbolstica veraniega, la organizacin

gestora de los estadios donde se jugarn los partidos quiere hacer una aplica-
cin web para poder guardar los datos ms relevantes de cada partido y, as,
vender las estadsticas a los diarios nacionales.
Se quieren conocer las estadsticas de los partidos jugados, los equipos y ju-
gadores que han jugado, qu equipos lo han hecho como locales o como
visitantes, y el nmero de goles por partido.
Para poder ofrecer estas estadsticas, el sistema tendr que gestionar los datos
de dos tipos de empleados: los taquilleros y los agentes de seguridad. De los
dos se necesita guardar el nombre, los apellidos, el DNI, la direccin, el tel-
fono de contacto y el nmero de la seguridad social. De los taquilleros se
necesita saber, adems, el nmero de taquilla que tienen asignada. De los
agentes de seguridad nos interesa saber, adems, a qu parte del terreno de
juego estn asignados.
De cada partido nos interesa guardar la fecha en que se juega, qu equipo

juega como local y qu equipo juega como visitante, el marcador final y qu
jugadores han marcado durante el partido.
De los equipos nos interesa guardar el nombre y la lista de jugadores. Y de

los jugadores nos interesa guardar el nombre, los apellidos, el DNI, la direc-
cin, el telfono de contacto, el dorsal y el equipo en el que juegan.
Se pide un diagrama de clases UML que modele el problema anterior, identi-

ficando los mtodos necesarios para realizar un listado de los equipos que
han jugado en un estadio como locales, ordenados alfabticamente.
Problema 16: Caribbean Resorts S. A.
La empresa espaola Caribbean Resorts S. A. ha construido un hotel-resort

en la Repblica Dominicana y nos ha encargado el diseo de un software
para llevar su gestin.
Este hotel, denominado Fiesta Beach, funcionar en rgimen de TI (todo

incluido), con la excepcin de las actividades concertadas que el cliente quie-
ra contratar, que se pagarn aparte.
El hotel constituye un concepto innovador con respecto a la oferta de aloja-

mientos. Est formado, por un lado, por edificios de habitaciones, y por otro
lado, por pequeas villas para el uso exclusivo de un nico cliente (con su
familia y/o amigos). Todos los alojamientos se identifican por un cdigo de
alojamiento y tienen establecido un determinado precio base por da. Todas
las habitaciones son dobles, y el precio diario corresponde a su precio base.

El precio diario de una villa se calcular en funcin del precio base y del
nmero de personas.
El hotel quiere llevar un registro de sus clientes. As, de todos ellos interesar
almacenar los siguientes datos: NIF, nombre y direccin. Se quiere aplicar
una poltica de descuentos a los clientes. En este sentido, el hotel distingue
dos tipos de clientes distintos:
Por un lado, los clientes estndar. A estos clientes se les aplicar un por-
centaje de descuento sobre su factura, en funcin del coste acumulado
por el cliente en estancias anteriores. Por lo tanto, har falta mantener ac-
tualizado este dato.
Por otro lado, tenemos los clientes VIP. Para stos, el descuento se calcu-
lar en funcin del nmero de aos que hace que el cliente es VIP. Por lo
tanto, har falta conocer el ao en que el hotel otorg a este cliente la
consideracin de VIP.
El hotel ofrece a sus clientes un conjunto de actividades que stos pueden

contratar. Las actividades pueden ser de dos tipos: individuales o paquetes.
Para cualquier actividad interesar almacenar: un cdigo de identificacin y
una pequea descripcin de la actividad. Todas las actividades tendrn un
precio.
Las actividades individuales tienen un precio fijo establecido. Los paquetes

estn constituidos por una serie de actividades individuales (previamente
existentes) que se contratan de manera conjunta. Un cliente slo podr con-
tratar aquellos paquetes que el hotel ofrezca (es decir, no podr hacer paque-
tes a la carta). El precio de un paquete se calcular como la suma de precios
de las actividades individuales que la componen, pero se aplicar un des-
cuento en funcin del nmero de actividades de que conste.
El hotel llevar tambin la gestin de las reservas de alojamiento que quieran

efectuar sus clientes. En el momento de efectuar la reserva, se almacenarn
los siguientes datos:
Cdigo de identificacin
Cliente que hace la reserva
Alojamiento asociado
Fecha de inicio de la estancia
Fecha de finalizacin de la estancia
Durante la estancia del cliente en el hotel, se podrn aadir a la reserva los

datos siguientes:
Relacin de actividades contratadas por el cliente durante su estancia
Reserva cerrada. Cuando la reserva est cerrada, no se podr hacer

ninguna modificacin ms en la misma. Esto se utilizar para saber que, a
partir de aquel momento, se puede generar la factura asociada a la
reserva.
Las operaciones ms comunes que se piensan efectuar, con la aplicacin de

esta gestin hotelera, son las siguientes:
Aadir una reserva al hotel: abrir una reserva. Se especificar: cliente,

fechas de entrada y de salida y alojamiento concreto (no una categora de
alojamiento) deseado.
Acceso a una reserva: a partir del NIF del cliente y la fecha de entrada, la
operacin devolver todos los datos de las reservas asociadas al cliente.
Operaciones sobre reservas (la especificacin de la reserva se har

mediante su cdigo): cancelar, aadir actividad, cerrar.
Listar la relacin completa de alojamientos del hotel.
Listar la relacin completa de clientes del hotel.
Listar la relacin completa de actividades del hotel.
Listar la relacin de alojamientos libres entre dos fechas, para una

categora especfica de alojamiento (habitacin o villa).
Problema 17: aeropuertos VolaSA
El nuevo plan director de aeropuertos del Estado contempla la creacin de

un conjunto importante de aeropuertos secundarios para dar respuesta a las
necesidades de transporte areo de carga y pasajeros, as como a los vuelos de
carcter ldico.
La empresa VolaSA se encargar de gestionar un aeropuerto secundario en

Osuna, y nos ha encargado la creacin de una aplicacin que permita ges-
tionar las peticiones de uso del espacio areo del aeropuerto.
Esta aplicacin deber disponer de las siguientes funcionalidades:

Cada vez que se solicita la confirmacin de un plan de vuelo, la

aplicacin determinar si el aparato podr aterrizar en el aeropuerto. En
general, se aceptar el plan de vuelo si, en el mismo instante del
aterrizaje, no hay ms de dos vuelos con plan de vuelo ya aceptado que
han solicitado aterrizar a la misma hora.
La aplicacin deber permitir calcular las tasas que tienen que pagar las
compaas areas en funcin del peso transportado, el tipo de aparato, los
metros de pista necesarios para hacer el aterrizaje, as como la experiencia
del piloto, y el uso de la terminal por parte de los pasajeros.
La aplicacin deber permitir llevar un registro de todos los pilotos y

aparatos de vuelo. Un piloto puede serlo de cualquier tipo de aeronave.
Los aparatos que pueden aterrizar en el aeropuerto que estamos diseando

son: aviones de lnea regular y helicpteros.
La informacin que necesitaremos para cada uno de los aparatos ser:
Un cdigo identificador del aparato: se utilizar, principalmente, para

poder determinar los costes de cada aparato de vuelo por separado.
El consumo de combustible por hora: se utiliza para poder estimar la

cantidad de combustible que necesitaremos tener almacenado en los
depsitos del aeropuerto.
Los aviones de lnea regular pueden ser utilizados por el transporte de mer-
cancas (carga), o bien por el transporte de pasajeros. De los aviones nos
interesar conocer, adems:
La carga que transporta, especificada en kilogramos: se utilizar para calcular

el coste del aterrizaje. Las frmulas que se utilizan para evaluar el desgaste de
la pista en el impacto del aterrizaje siempre consideran el peso del aparato.
El volumen del aparato: las frmulas que calculan el coste del aterrizaje
tienen en cuenta los metros de pista necesarios para la operacin de
aterrizaje. En este sentido, las frmulas tambin necesitan conocer el
volumen que ocupa el aparato.
Los helicpteros son aparatos que se utilizan, principalmente, para la cam-

paaforestal y para emergencias. Nos interesar conocer, adems:
Si la operacin de aterrizaje obedece a una actividad de una emergencia.
El nmero de motores del helicptero.

Con respecto al plan de vuelo, ste tendr que contemplar:
La fecha y la hora de aterrizaje en el aeropuerto.
La informacin del aparato de vuelo, as como un identificador del plan

de vuelo.
La duracin del vuelo: se utiliza para poder estimar la cantidad de com-

bustible que necesitaremos tener almacenada en los depsitos del aero-
puerto.
Piloto: para evaluar el coste del aterrizaje, se utilizar como parmetro las
horas de vuelos acumuladas por parte del piloto.
Finalmente, de los pilotos queremos conocer su nombre, DNI, nmero de

horas de vuelo acumuladas, as como nmero de aterrizajes efectuados.
Problema 18: vuelos AirUOC
La aerolnea AirUOC es una compaa a pequea escala, encargada de los

vuelos regulares y contratados de una determinada zona geogrfica. Para
actualizar su sistema de gestin de personal, aviones, vuelos autorizados y
pasajeros, se nos pide el diseo de un aplicativo que cumpla con los requisi-
tos se detallan a continuacin.
AirUOC realiza dos tipos de vuelos, los vuelos regulares y los vuelos contra-
tados. Los primeros son vuelos con rutas predefinidas, codificadas con un
cdigo numrico. Estos vuelos tienen una salida peridica, y el precio por
pasajero est definido con independencia del nmero de pasajeros del avin.
En los vuelos regulares, como en la mayora de compaas areas, existen dos
modalidades de vuelo: Business Class, ms cmoda pero ms cara, y Turista,
un 30% ms econmica que la anterior. La segunda tipologa de vuelos, los
vuelos contratados, se basan en el alquiler de un avin, generalmente de un
nmero pequeo de pasajeros, para realizar un viaje en una fecha y hora
concretadas. En este caso no hay ruta predefinida, sino que se establece el
origen, el destino del vuelo y las escalas, y a partir de esta informacin y del
nmero de viajeros, se establece el precio a pagar para cada pasajero. En este
caso, siempre se establece una nica tarifa, la Business Class.
De cada vuelo es necesario almacenar, adicionalmente, el cdigo del vuelo,

formado por dos letras y cuatro cifras, la hora de salida, la duracin de ste, y
si es nacional, europeo o internacional. Todos los precios se establecen en
euros.
Cada vuelo est asociado a un avin. De un avin es necesario almacenar la

lista de tripulantes (azafatas y pilotos), los pasajeros y el nmero de butacas
para pasajeros tipo Bussiness Class y Turista.
El sistema tambin deber almacenar los datos de los pasajeros: nombre y

apellidos, nmero de pasaporte, direccin, y si viajan en Business Class o en
clase Turista. De hecho, los responsables de AirUOC han explicitado que, en
los prximos aos, no se prevn ms opciones que no sean Business Class y
Turista.
En el caso de la tripulacin de los aviones, se almacenar el nombre y apelli-

dos, el nmero de pasaporte, la direccin postal y su sueldo mensual. El
sueldo mensual de los pilotos de aviacin depender del nmero de horas de
vuelo realizadas. El sueldo de las azafatas depender de las horas de vuelo
realizadas y del nmero de idiomas que hablan correctamente. Todos los
sueldos se calculan en euros.
El sistema deber permitir la gestin de los pasajeros y de la tripulacin. En

concreto, deber permitir dar de alta pasajeros y tripulantes. Tambin deber
permitir generar los listados de una determinada tipologa Business Class /
Turista por vuelo.
Problema 19: trabajadores UOCfridge
La tienda de alimentos congelados UOCfridge, aprovechando que est ex-

pandiendo su negocio, nos ha pedido un nuevo aplicativo que facilite la
gestin de las ventas y el pago del sueldo a sus trabajadores. Se nos propor-
ciona el siguiente anlisis de requerimientos.
Todos los productos se envasan y se venden unitariamente. Cada producto

tiene asociado un cdigo de barras y un precio unitario. Los precios se pro-
porcionan en euros.
En cuanto a los empleados, mayoritariamente son vendedores, pero el pro-

pietario nos ha dicho que existen otros tipos de empleados, por ejemplo, los
encargados del almacn, pero prefiere que en el sistema actual no se tengan
en cuenta, aunque puedan aadirse en un futuro. De los vendedores es nece-
sario conocer su nombre y apellidos, DNI, direccin postal, el nmero de la
seguridad social y su sueldo. El sueldo de los vendedores se calcula a partir
del sueldo base, ms un porcentaje de ventas.
Todos los clientes de la tienda se registran en el sistema gracias a la tarjeta

cliente, que les permite acceder a descuentos y promociones adicionales. De
cada cliente se guarda el nombre y apellidos, el DNI y su direccin postal. Si

un cliente se deja la tarjeta en casa, ste es identificado a partir de su DNI.
Cada venta se registra en una factura, con el DNI del cliente, el NIF del ven-
dedor y el listado de productos comprados. El importe de la venta se calcula
a partir del precio de los productos listados en la factura. Dicho registro de
facturas debe estar organizado de modo que pueda saberse, de una factura,
toda la informacin asociada. Adems, deben poder obtenerse todas las fac-
turas que corresponden a las compras de un cliente. Finalmente, deben po-
der obtenerse todas las facturas que corresponden a las ventas de un vende-
dor.
El sistema ha de permitir, adicionalmente, dar de alta empleados, clientes,

productos, ventas, calcular el sueldo de los empleados y la totalizacin de las
ventas.
Problema 20: hospital central
El gerente de un hospital nos ha encomendado la gestin de los recursos del

hospital por parte de las compaas mdicas o de particulares, con el objeti-
vo de facturar correctamente la atencin mdica que reciben los enfermos
que acuden al hospital.
Uno de los aspectos que se quiere controlar es la gran cantidad de movi-

mientos que deben realizar los pacientes ingresados en las habitaciones para
acceder a los siguientes recursos estticos: la sala de rayos X y el quirfano.
En el caso de la salas de rayos X, el hospital debe asignarle una enfermera
para su correcto uso. En el caso de los quirfanos, el hospital debe asignar
siempre tres enfermeras en cada operacin, y es la compaa mdica la en-
cargada de aportar sus mdicos.
En el transporte de un paciente, pueden ser necesarios algunos de los si-

guientes recursos dinmicos: muletas, silla de ruedas o litera. En el caso de
una silla de ruedas, el transporte de un paciente requiere adems de un cela-
dor, y si se trata de una litera, el transporte requiere de un celador y de una
enfermera.
Para obtener una evaluacin fiable de los costes que comporta un paciente,
el gerente nos pide la implementacin de un nuevo aplicativo que permita
evaluar, al final del da, la ocupacin de los recursos, el uso de los recursos de
transporte y los recursos estticos generados por cada paciente, y la informa-
cin de los pacientes que ha entendido cada enfermera.
En la evaluacin de la ocupacin de recursos, se desea obtener el DNI del

paciente, tiempo de ocupacin, y el DNI del personal del hospital necesario.
Para cada recurso, adems, es necesario su identificador y el ao de compra.
Para los recursos estticos, se necesita adems el nombre de la compaa
mdica que se hace cargo de los gastos generados.
Deben proporcionarse tambin las operaciones necesarias para dar de alta y

dar de baja enfermeras, pacientes y celadores.

Problema 21: transportes TransUOC
La empresa de transportes TransUOC, dedicada al transporte de mercancas,

nos ha encargado la creacin de una aplicacin que permita gestionar los
pedidos que reciben. La informacin bsica de un pedido consta de la dis-
tancia entre el punto de origen y el punto de destino, y el peso de la carga a
transportar.
La aplicacin deber permitir determinar, cada vez que llegue un pedido, si

se puede cubrir con los vehculos disponibles. Adems, deber gestionar qu
vehculo se utilizar para transportar la carga, seleccionando el ms adecua-
do en cada caso, y calcular el precio del transporte de las mercancas en
funcin de los kilmetros recorridos, el peso transportado y el vehculo utili-
zado.
La informacin necesaria correspondiente a un vehculo consta de un cdigo

identificador, la carga en kilos que transporta, el consumo por cada 100 ki-
lmetros, la capacidad mxima de carga, la velocidad media a la que circula,
el coste bsico de uso del vehculo, la tasa predefinida que se paga cada vez
que se usa el vehculo y el tripulante o tripulantes necesarios para conducir
el vehculo.
Los vehculos pueden ser de tres tipologas diferenciadas: terrestres, areos o

martimos. Los vehculos terrestres son los que circulan por carretera. De
stos es necesario conocer la potencia del motor. Para monitorizar cundo es
necesario realizar las correspondientes revisiones, tambin ser necesario
almacenar el nmero de kilmetros recorridos. Se deber tener constancia
tambin del nmero de averas del vehculo y el coste total de reparacin.
Los vehculos areos corresponden a los aviones de que dispone la empresa
para sus transportes. Las caractersticas necesarias para estos vehculos son el
nmero de motores y la antigedad del vehculo. Los vehculos martimos
son los correspondientes a los barcos de que dispone la empresa. Las caracte-
rsticas que se debern guardar sobre estos vehculos son su antigedad y la

fecha de su ltimo embarque.
Los pedidos debern indicar si el transporte puede utilizarse por mar o no, y
si es o no urgente. La asignacin de vehculos a pedidos se har de modo que
se utilicen el mnimo nmero de recursos para servirlos. Es decir, se elegirn
los vehculos con mayor capacidad de carga posible para atender el pedido.
En caso de que el pedido sea de carcter urgente, la prioridad sern los veh-
culos rpidos, aunque la asignacin de cargas no sea ptima. Una vez elegido
el vehculo ms apropiado, la totalidad de cargas correspondiente a un pedi-
do se transportarn nicamente con dicho vehculo.
El coste total de un pedido se computar como la suma del kilometraje reali-

zado y el coste generado por el vehculo, basndose este ltimo coste en las
caractersticas propias del vehculo previamente definidas (consumo, coste
bsico de uso, tasa predefinida, tasa tripulante/tripulantes necesarios).

Problema 22: VideoMagic
La empresa VideoMagic, dedicada al prstamo a travs de terminales 24

horas, de libros, vdeos, CD y libros, nos ha encargado el diseo de una apli-
cacin informtica que gestione su negocio.
La informacin caracterstica de los productos consta de su identificador,

autor, ttulo, empresa de produccin, fecha de salida al mercado, nmero de
ejemplares disponibles, cdigo de ubicacin en el almacn, nmero de vo-
lumen y descripcin.
Los productos se clasifican en libros, vdeos y CD, con las caractersticas pro-
pias que se especifican a continuacin:
La informacin especfica que debe almacenarse de un libro corresponde

al nmero de pginas y al tipo de contenido (novela, aventuras, policaca,
viajes, etc.).
De los vdeos debe guardarse el tiempo de duracin y el tipo de contenido

(vdeo documental, pelcula, etc.).
Se consideran tres tipologas de CD. Los CD compactos, que son los tpi-
cos CD de msica; los CD-ROM, que son CD con juegos de ordenador; y
los DVD, que renen las caractersticas de los vdeos y de los CD-ROM.
De cada CD deber almacenarse la cartula y su cdigo de barras. De los
CD de msica deber almacenarse, adems, el nmero de canciones y el

tiempo total. De los CD-ROM deber aadirse el nmero de megabytes de
informacin que contienen, y en el caso del DVD, la informacin relativa
al men de contenido disponible.
Se desea que, desde el terminal de prstamo, se puedan realizar los prstamos

de productos, indicando el cdigo del cliente, su saldo actual, el identifica-
dor del producto y la fecha de devolucin del producto. Tambin deber
considerarse la posibilidad de realizar una consulta, y sta ha de devolver
toda la informacin relevante del producto, indicando si hay ejemplares
disponibles para el prstamo o no.
No se descarta, en un futuro prximo, que puedan aadirse nuevas tipolog-

as de productos en prstamo, por lo cual la aplicacin tiene que disearse
teniendo en cuenta este supuesto. Tambin se deber tener en cuenta que la
aplicacin deber gestionar la totalidad de usuarios del sistema en la prxima
ampliacin del proyecto.


Pid 00145182

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Pid 00145182

Загружено:

Авторское право:

Доступные форматы

Problemas

Parte I. El proceso de modelado....................................................... 7

Parte II. Problemas solucionados .................................................... 11

Parte III. Problemas propuestos (sin solucin) ........................... 74

La principal motivacin de este material didctico surge de la necesidad de

Estos materiales se estructuran de la siguiente forma:

En la primera seccin, introducimos la metodologa elemental de mode-

Siguiendo esta metodologa, la segunda seccin muestra 21 problemas de

Finalmente, la tercera seccin contiene un listado de 22 problemas sin

Parte I. El proceso de modelado

Para crear un diagrama de clases a partir de la descripcin de un problema

El proceso para crear un modelo de clases, a pesar de no ser matemtico, se

1) Identificacin de las clases

Consiste en seleccionar los sustantivos y frases nominales que conformarn

2) Creacin del modelo de datos

3) Inclusin de atributos y mtodos

Una vez creado el modelo de datos, debemos ir aadiendo los atributos y

4) Inclusin de la cardinalidad y navegabilidad de las relaciones

Por ltimo, completaremos el diagrama indicando el nmero mximo y mnimo

Para mejorar el diagrama de clases obtenido, es aconsejable aplicar este algo-

La Asociacin de Antiguos Alumnos de la UOC nos ha pedido si podemos

Los asociados se pueden dividir en miembros numerarios y en miembros de la

La convocatoria de un evento se realiza por correo electrnico a todos los

En la convocatoria, tambin aparece informacin sobre el lugar que en mu-

1) Identificacin de las clases

Miembro (o miembro numerario) (Member)

Adicionalmente, se ha aadido la clase Persona (Person) para poder identifi-

2) Creacin del modelo de datos

Para crear el modelo de datos, se ha detectado la existencia de una jerarqua de

junta directiva. En este problema, se ha descartado la inclusin de una clase

Al mismo tiempo, existe la siguiente jerarqua entre los miembros de la aso-

Adems, tenemos las clases Localizacin (Location) y Asociacin (AAUOC),

3) Inclusin de atributos y mtodos

La asociacin necesitar un conjunto de m- AAUOC

todos para aadir nuevos eventos, personas y

para informar a los miembros de la convoca-

assign(l : Location) : void

4) Inclusin de la cardinalidad y navegabi- Conference BoardMeeting BoardMember

En el siguiente diagrama, se han eliminado attendsTo

los mtodos e incluido las navegabilidades

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

Parte II. Problemas solucionados

Problema 1: aplicativo de profesorado

En su momento, emplearon el concepto profesor como un trmino genrico,

1) Identificacin de las clases

Profesor interno (InternalTeacher)

2) Creacin del modelo de datos

Para crear el modelo de datos, se ha detectado la existencia de una jerarqua

3) Inclusin de atributos y mtodos

La UOC necesitar un conjunto de mtodos para aadir nuevos profesores,

newClass(c : Class) : void

name : String name : String

baseSalary : Double variableSalary : Double

4) Inclusin de la cardinalidad y navegabilidad de las relaciones

En el siguiente diagrama, se han eliminado los mtodos e incluido las nave-

que el profesor externo sepa en qu empresa trabaja, pero no se ha pedido la

La empresa de telefona mvil UOCphone quiere lanzar una campaa de

El segundo sistema es para los clientes en modalidad de prepago, que la

En el primer caso, los puntos se asocian al individuo, de manera que si ste

El sistema debe registrar todas las llamadas salientes, incluyendo hora de

Se pide el diagrama UML que incluya las clases, asociaciones, atributos y

1) Identificacin de las clases

Lnea de telefona mvil (Line)