Práctico 5 - Diseño - Diagramas de Comunicación

Ejercicio 1 (básico, imprescindible)

Construir los diagramas de comunicación que reflejen las siguientes interacciones:

a) Un objeto de clase ClaseA recibe como punto de entrada un mensaje mensaje1() y si la condición cond se satisface, envía un mensaje mensaje2() a un objeto de clase ClaseB, y en caso contrario, envía un mensaje mensaje3() a un objeto de clase ClaseC.

b) Un objeto de clase ClaseA, al recibir el mensaje mensaje1(), crea una instancia de clase ClaseB, y se lo envía a un objeto de clase ClaseC, el cual envía el mensaje mensaje3() a la instancia recién creada.

c) Un objeto de clase ClaseA, al recibir el mensaje mensaje1(), envía m veces el mensaje mensaje2() a una instancia de clase ClaseB, el cual a su vez, por cada mensaje recibido, envía un mensaje mensaje3() a un objeto de clase ClaseC y otro mensaje mensaje4(), a uno de clase ClaseD.

d) Un objeto de clase ClaseA recibe como punto de entrada un mensaje mensaje1(), y envía a cada objeto de una colección de objetos de clase ClaseB el mensaje mensaje2().

Solución:



Ejercicio 2 (básico, imprescindible)

Considerar el Modelo de Dominio presentado en el siguiente diagrama.

a) Realizar el diagrama de comunicación en el que una instancia de A crea una de B con link unidireccional de A hacia B.

b) Realizar el diagrama de comunicación en el que una instancia de B crea una de A con link unidireccional de B hacia A.

c) Modificar los diagramas anteriores de forma que el link creado sea bidireccional.

Solución:



Ejercicio 3 (básico, imprescindible)

Considerar el Modelo de Dominio presentado en el siguiente diagrama.


Se desea diseñar la operación que retorne todos los identificadores de las instancias de A que participen en la asociación R cuyo atributo val sea mayor que un valor dado.

a) Realizar el diagrama de comunicación sabiendo que R es navegable de A hacia B.

b) Realizar el diagrama de comunicación sabiendo que R es navegable de B hacia A.

c) Realizar el diagrama de comunicación asignando la responsabilidad a R.

Solución:



Ejercicio 4 (básico, imprescindible)

Considerar el sistema analizado en el Ejercicio 3 del Práctico 4 referente a la venta de vehículos a personas. Diseñar la interacción de la colaboración que realiza el caso de uso que registra la venta de un vehículo a una persona.

Solución:
Coming soon...


Ejercicio 5 (básico, imprescindible)

Considerar el Modelo de Dominio presentado en el siguiente diagrama. El atributo potencia indica la capacidad de generación de energía de una turbina, que en el caso de ser especial se multiplica por el valor del atributo coef.


Diseñar la interacción de la colaboración que realiza el caso de uso Obtener Potencia de una Usina que obtiene la potencia total que son capaces de generar todas las turbinas activas de una usina.

Solución:

Práctico 4 - Análisis - DSS y Contratos

Ejercicio 2 (básico, imprescindible)

Considerar el Modelo de Dominio presentado en el siguiente diagrama.



a) Realizar los Diagramas de Secuencia del Sistema para los siguientes casos de uso descritos en alto nivel:

i) Prestar de un libro

“Dado el identificador de una persona, el de un libro, y una fecha de devolución, registra el préstamo de ese libro a esa persona.”

ii) Devolver un libro:

“Dado el identificador de una persona y el de un libro, registra la devolución del libro que tenía esa persona. En caso de haber expirado la fecha de devolución se incrementa su deuda en 10 veces la cantidad de días que se demoró en devolver el libro.”

iii) Pagar una deuda:

“Dado el identificador de una persona y un monto, registra el pago (parcial o total) de la deuda que tenía esa persona.”

b) Realizar el/los contratos para la/las operaciones de sistema identificadas a partir de los casos de uso anteriores.

Solución:




Ejercicio 3 (medio, imprescindible)

Considerar el Modelo de Dominio presentado en el siguiente diagrama.



a) Expresar las siguientes restricciones en OCL

i) La matrícula identifica a los vehículos y la cédula de identidad a las personas.

ii) El dueño actual de un vehículo no puede ser un dueño anterior.

b) Realizar el Diagrama de Secuencia del Sistema para el siguiente caso de uso descrito en alto nivel:

“Dadas la matrícula de un vehículo y el documento de una persona, se debe realizar la compra del vehículo por parte de la persona. En caso de que el vehículo tenga dueño, éste pasa a ser dueño anterior.”

c) Realizar el/los contratos para la/las operaciones del sistema.

d) Presentar mediante snapshots el efecto de aplicar la operación de venta de un vehículo a una persona, considerando que el vehículo tenía otro dueño antes de ejecutar la operación.

Solución:




Ejercicio 4 (medio, imprescindible)

Se desea hacer un prototipo reducido para bedelía donde pueda tenerse registrados los cursos y los estudiantes, así como qué estudiantes están inscriptos a cada curso. Notar que los cursos tienen un cupo de 30 estudiantes. Para ello, el Analista ha construido el Modelo de Dominio presentado en el siguiente diagrama.



El Analista ha identificado cuatro operaciones de sistema, a saber:

Dar de alta un nuevo curso.

nuevoCurso(nombre:String, codigo:Integer)

Dar de alta un nuevo estudiante. El sistema devuelve el número que le asignó al estudiante. El sistema asigna números a partir de cero, en forma ascendente.

nuevoEstudiante(nombre:String):Integer

Obtener la cantidad de estudiantes inscriptos a un curso.

darCantInscriptos(codigo:Integer):Integer

Inscribir al estudiante al curso.

inscribir(numero:Integer, codigo:Integer)

a) Realizar el Diagrama de Secuencia del Sistema para el siguiente comportamiento descrito en alto nivel; considere un sistema sin memoria:

“Para dar de alta un curso se ingresa el nombre y código del mismo. Acto seguido se inscriben los estudiantes, los cuales deben ser ingresados previamente en el sistema en caso de no estarlo. Finalmente se consulta la cantidad de inscriptos del curso.”

b) ¿Cómo se debería modificar el Diagrama de Secuencia anterior si se considera un sistema con memoria?

c) Realizar los contratos de software para las cuatro operaciones.

d) Considere que el sistema no contiene inicialmente ninguna instancia creada.
Simule la aplicación exitosa de las operaciones nuevoCurso, nuevoEstudiante e inscribir, en ese orden, con los datos que desee. Muestre el estado del sistema luego de aplicar cada operación.

Solución:

a)

Nota: para los DSS, paso a utilizar el Visual Paradigm, porque en el Visio logré armar unas cosas mas o menos parecidas a DSSs, pero no encontré forma de poner los recuadros de "loop", "alt", etc. (si alguien sabe cómo se hace...).
Y en el Visual Paradigm, no logro que me subraye el nombre de las instancias de objetos (ej.: Sistema)



b)



c)

Coming (not so) soon....

d)




Ejercicio 5 (medio, imprescindible)

Considerar el Modelo de Dominio presentado en el siguiente diagrama.



a) Realizar el/los Diagramas de Secuencia del Sistema para el siguiente caso de uso descrito en alto nivel:

“Dados los datos de un vehículo, darlo de alta en el sistema”

b) Discutir distintas alternativas considerando que se espera agregar nuevos tipos de vehículos al sistema.

Solución:

a)



Ejercicio 6 (avanzado, de práctica)

Considerando los siguientes artefactos se pide:

a) Construir el Modelo de Dominio y presentarlo en un diagrama utilizando UML.

b) Realizar el/los Diagramas de Secuencia del Sistema para los casos de uso incluidos en el Modelo de Casos de Uso.

Visión del Problema

Se desea implementar un sistema de compras por Internet para un supermercado.

Modelo de Casos de Uso

Los actores que interactúan con el sistema son: cliente y administrador.

Caso de Uso: Proceso de compra

Un cliente se conecta al sitio del supermercado, una vez dentro, puede navegar por distintas góndolas de productos. El cliente posee un carrito, al cual puede agregar unidades de productos.
Cuando escogió todo lo necesario, hace efectiva la compra. Al realizarse la compra, el sistema calcula el monto a pagar en base al contenido del carrito, y solicita al cliente sus datos personales y los datos de su tarjeta de crédito (número, marca y fecha de vencimiento). El sistema efectúa la autorización de la tarjeta, obteniendo el código de autorización. La compra es realizada y se registra los productos comprados, los datos del cliente y el código de autorización de compra, y finalmente el cliente se retira.

Solución:



b)

Versión 1:

Nota: Acabo de darme cuenta que cuando exporto como imagen, el Visual Paradigm no incluye la parte de "sd {nombre}"... ahora ya ví cómo hacer para que lo incluya, pero en las imágenes anteriores falta. Sorry...




Ahora... surgen las dudas...

Ahí asumí que todo eso de "navega por distintas góndolas de productos" era paye para distraer y confundir. Pero...

En el teórico, ponen un ejemplo de un supermercado real ("físico") donde la parte de que el cliente con su carrito (físico) se pasea por las góndolas (físicas) y agarra con la mano productos (físicos) y los mete dentro de su carrito (creo que ya se entendió la idea...), no es relevante para el sistema, pues son eventos externos que no atraviesan la frontera del mismo.

Pero acá todo es virtual; el cliente navegando por las góndolas y viendo los productos, es un evento (o varios eventos) originado en el exterior y que ATRAVIESA la frontera del sistema, pues todo eso de navegar y ver son funcionalidades que mi sistema tiene que proveer...

Así que tendría que reflejar todo eso en mi DSS (verdad????).

Ahora, este "análisis" es un prodigio de ambigüedad (por no decir una porquería), si yo hiciera un análisis tan malo, me echaban del trabajo... es más, al que lo hizo, yo no le daba el título de Analista...
A qué se refiere con "navegar"? Cómo "navega" el cliente???

Cómo reflejo en un DSS las operaciones de "navegar", si en el DSS me dicen que tengo que poner los parámetros con sus tipos, y yo acá no sé ni cómo pretende navegar, menos voy a saber qué operaciones poner y ni hablar de parámetros!! Pongo un "navegarGondola" que reciba de parámetro un DataType "NavOpcion", enumerado, con valores posibles "anterior" y "siguiente" (una navegación básica....)?? No pongo parámetros, asumo que estos se definirán en una etapa posterior (en el diseño, por ej.) y ahí se modificará el DSS para adecuarlo a la opción tomada??

Ante la ambigüedad, asumo las 2 cosas. Meto un DataType de parámetro para que se vea que la navegación no se hace mágicamente leyéndole la mente al usuario, y asumo que más adelante se va a modificar esto.


Ahora... siguiendo con nuestro análisis metodología "Dimensión Desconocida"... la parte de la autorización de la tarjeta de crédito:

Esto en realidad, aunque el "análisis" no lo aclara, va a ser una interacción entre el Sistema y otro software (el de la institución administradora de la tarjeta de crédito). Debería reflejarlo en el DSS, verdad? (verdad????) No es como el caso de una respuesta que el sistema le da al usuario, que ahí sí, es mejor no ponerla en el DSS...

Acá surge otra duda: El actor "administrador" que menciona la letra, y que yo asumí que sería un tipo de usuario del sistema que no intervenía en este caso de uso sino en otro, y que lo ponían para marear, ¿no será en realidad la Institución Administradora de las Tarjetas de Crédito????

Bueno, acá también, asumo que la respuesta es "Sí a todo"...

Con todo esto, acá va la...

Versión 2:



Pero ahora, surgen dudas dentro de las dudas... es que sin dudas, casi que podríamos ser felices, y eso es algo que no debe suceder... :-)

Más allá de "eso está bien????", ¿está bien que el sistema recuerde cosas "temporalmente" (la góndola, el producto actual)? O sería mejor que en los mensajes 1: y 2: el sistema no recuerde nada, y cambiar para que los mensajes 2: y 3: sean:

2: p:=navegarProductosGondola(g:Gondola, navOp:NavOpcion):Producto

y

3: agregarProdACarrito(p:Producto, cantidad:Integer)

???

Práctico 3 - Análisis - OCL y Modelado del Dominio

Parte 1 - OCL

Ejercicio 1 (básico, imprescindible)

Un analista realizó tres Modelos de Dominio diferentes, presentados en los siguientes diagramas:



Especificar utilizando OCL las restricciones al Modelo de Dominio (a) de forma que permita solamente las instancias válidas para los modelos (b) y (c).

Solución:

• Convertir (a) en (b):

context A inv:
-- todo A se relaciona con exactamente 33 instancias de B
self.b->size()=33

context B inv:
-- todo B se relaciona con exactamente 1 A
self.a->size()=1

• Convertir (a) en (c):

context A inv:
let cant:Integer = self.b->size()
in
cant >= 2 and cant <= 4

context B inv:
let cant:Integer = self.a->size()
in
cant >= 8 and cant <= 11


Ejercicio 2 (básico, imprescindible)

Considerar el Modelo de Dominio presentado en el siguiente diagrama:



a) Especificar en OCL la restricción que indica que el atributo ci de la clase Persona identifica a las instancias de Persona, es decir, no hay dos personas con igual cédula de identidad.
b) Expresar de otra forma la misma restricción, utilizando también OCL.

Solución:

a)
context Persona inv:
Persona.allInstances()->isUnique(ci)

b)
Lo mismo, más complicado:

context Persona inv:
Persona.allInstances()->forAll(p1, p2:Persona | p1 <> p2 implies p1.ci <> p2.ci)

ó, aún más retorcido :

context Persona inv :
Persona.allInstances()->forAll(p1, p2 :Persona | p1.ci = p2.ci implies p1 = p2)


Ejercicio 3 (básico, imprescindible)

Un analista construyó el Modelo de Dominio presentado en el siguiente diagrama. Como información adicional, se sabe que el precio de un auto se calcula como la suma de los precios de todas sus partes.



a) Indicar en OCL, de dos formas diferentes, cómo se calcula el precio de un auto.
b) Indicar en OCL la propiedad que indica que el precio de un auto es mayor que el precio de sus partes.
c) Indicar en OCL la restricción que exige que todo auto cuenta, entre sus partes, con exactamente una parte cuyo precio es mayor a la mitad del precio del auto.

Solución:

a)
context Auto inv :
self.precio=self.parte.precio->sum()

Otra forma:

context Auto inv:
self.precio = self.parte->iterate(p:Parte; suma:Real = 0 |
suma = suma + p.precio)

b)
context Auto inv:
self.parte->forAll(p:Parte | self.precio > p.precio)

ó, self.parte->forAll(self.precio > precio)

c)
context Auto inv:
self.parte->select(precio > self.precio / 2)->size() = 1



Ejercicio 4 (básico, imprescindible)

Considerar el Modelo de Dominio presentado en el siguiente diagrama:



a) Expresar en OCL la restricción que exige que un vendedor solamente vende un producto de la empresa para la que trabaja.
b) Expresar dicha restricción considerando que un vendedor vende uno o más productos de la empresa para la que trabaja.
c) Expresar dicha restricción asumiendo que un vendedor trabaja en una o más empresas y vende uno o más productos de éstas.

Solución:

a)
context Vendedor inv:
self.empresa.producto->includes(self.producto)

b)
context Vendedor inv:
self.empresa.producto->includesAll(self.producto)

c)
context Vendedor inv:
self.empresa->forAll(e:Empresa | e.producto->includesAll(self.producto))

ó, equivalentemente:

empresa->forAll(producto->includesAll(self.producto))
(1) (2)

ya que (página 32 del pdf sobre OCL):

- dentro de todo el invariante, está implícita la variable self, de tipo Vendedor (self:Vendedor).

Por lo tanto, donde aparece la propiedad empresa, se asume que es self.empresa.

- el forAll define otra variable implícita, llamémosla iter1, de tipo Empresa.

Por lo tanto, la propiedad producto (1) debe ser o de self o de iter1. Como ambos tienen una propiedad llamada producto, se asuma que pertenece a la variable de alcance más interno: iter1.
De esta forma, producto (1) implica navegar desde la Empresa y no desde el Vendedor.

- el includesAll define una tercer variable implícita, llamémosla iter2, de tipo Producto.

Si en (2) pusiera sólo producto, se buscaría dicha propiedad en self, iter1 e iter2. iter2 no tiene una propiedad con ese nombre, pero sí la tienen self e iter1. Al igual que en (1), se asumiría que es iter1.producto (navegación desde la Empresa), lo que no es correcto (yo quiero navegación desde Vendedor).

Eso me obliga a poner explícitamente self.producto.



Ejercicio 5 (medio, imprescindible)

El Modelo de Dominio presentado en el siguiente diagrama representa a las selecciones de fútbol que participan de los mundiales. Expresar en OCL la restricción que impone la FIFA de que todas las selecciones deben tener exactamente 3 arqueros.



Solución:

context Seleccion inv:
self.jugador-> select(j:Jugador | j.oclIsTypeOf(Arquero))-> size() = 3

ó

context Seleccion inv:
jugador -> select( oclIsTypeOf(Arquero)) -> size() = 3


Ejercicio 6 (medio, imprescindible)

a) Realizar dos Modelos de Dominio consistentes con la siguiente restricción y presentarlos en diagramas utilizando UML.

context A inv:
self.r1.c.p > 0 and self.r2.c.p <>

b) Realizar dos Modelos de Dominio consistentes con la siguiente restricción y presentarlos en diagramas utilizando UML.

context A inv:
self.r1->includesAll(self.r2)

Solución:





Ejercicio 7 (medio, imprescindible)

Construir el Modelo de Dominio para las siguientes realidades y presentarlo utilizando UML y OCL. Su modelo debe representar completa y fielmente lo que el texto dice.

a) Todas las personas comen comida. En general, las personas comen tanto verduras como carne. Las personas vegetarianas sólo comen verduras mientras que las personas carnívoras sólo comen carne.

b) El padre de Juan se llama Alberto. José es el abuelo de Juan. Alberto tiene 40 años, le lleva 25 años a su hijo y es 25 años menor que su padre. Es regla general que cada padre es mayor que todos sus hijos. Además, para cada persona que se conozca el abuelo se conoce el padre. José tiene otro hijo llamado Luis de 42 años, quien no tiene hijos, por lo que el único nieto de José es Juan.

c) Los exámenes pueden contener preguntas y/o problemas. Cada uno de ellos lleva puntos. Cada examen tiene un total de 100 puntos si se suman los puntos de todas sus preguntas y problemas. En cada examen, cada pregunta tiene menos puntos que cada uno de los problemas del mismo examen. Ningún examen puede repetir dos o más preguntas de otro examen. Los problemas aparecen en un examen solamente.

Solución:

Parte 2 - Modelado del Dominio

Ejercicio 1 (básico, de práctica)

Se cuenta con el siguiente anexo al documento de Visión del problema presentado en el ejercicio 2 del práctico 2 referente al sistema de información del control hospitalario.

Las salas tienen un conjunto de camas que interesa individualizar mediante un número. Existen salas de cuidados especiales y salas comunes. Para las salas de cuidados especiales, interesa conocer un detalle de los elementos de que dispone, mientras que de las salas comunes interesa saber si tiene o no capacidad para admitir acompañantes. Para los pacientes internados se desea conocer la fecha de internación y su ubicación en el hospital (la cama a la que están asignados). Acerca de todos los pacientes interesa saber cuáles son los médicos que los tratan, y en cada caso tener una descripción del tratamiento; un paciente puede estar bajo distintos tratamientos con diferentes médicos.

Modificar el Modelo de Dominio realizado previamente incorporando la nueva información y presentarlo en un diagrama utilizando UML y OCL.

Solución:





Ejercicio 2 (medio, imprescindible)

Construir el Modelo de Dominio a partir del siguiente documento de Visión del problema y presentarlo en un diagrama utilizando UML y OCL.

En una empresa de transporte se dispone de una flota de vehículos, de cada uno de los cuales se conoce un número que lo identifica, la marca y el modelo. Estos vehículos pueden ser camiones, en cuyo caso se conocen además la capacidad de carga en toneladas y la cantidad de ejes; existen camionetas, de las cuales se conocen su capacidad de carga en toneladas y si es doble cabina o no; ómnibus, de los que se conocen la cantidad de asientos y si tiene o no baño. Además la empresa cuenta con automóviles, de los cuales se conoce la cantidad máxima de pasajeros que admite. La empresa cuenta con un plantel de conductores. De estos se conoce su documento de identidad y la edad. Los conductores de primera categoría son asignados a manejar camiones, camionetas u ómnibus. Los de segunda categoría solo se asignan a automóviles. En el caso de los conductores de primera categoría, se asignan en forma fija e interesa representar a que vehículo está asignado cada conductor. Los de segunda categoría cambian su asignación diariamente, interesando saber a que auto se asignó cada día. Todos los conductores tienen asignado (de dicha forma) un solo vehículo. No todos los vehículos tienen un conductor asignado, pero se les puede asignar varios conductores.

Solución:




Ejercicio 3 (medio, de práctica)

Se desea modelar la realidad referente a los movimientos de dinero en la plaza financiera, descritos en el siguiente documento de Visión del problema.

Una persona puede realizar transacciones tanto en una ventanilla de un banco como en un cajero automático. Los cajeros automáticos tienen un código, un saldo de dinero en efectivo y la cantidad dispensada hasta el momento. Cada cajero se encuentra conectado en red con la empresa que lo administra, pudiendo haber más de una empresa administradora. Esta empresa se conecta a su vez con los distintos bancos que mantienen las cuentas que pueden ser accedidas.

Los bancos tienen un nombre y un código, y cada cuenta tiene un saldo y un límite de crédito. Cada ventanilla de banco tiene a su vez un código.

Cuando alguna de las terminales realiza una transacción, interesa saber si corresponde a un depósito o a un retiro, la fecha, hora y terminal en que se realizó, el importe y la cuenta.

Construir el Modelo de Dominio y presentarlo en un diagrama utilizando UML y OCL.

Solución:




Ejercicio 4 (medio, de práctica)

Se desea modelar un sistema de información relativo a las obras proyectadas por un organismo estatal, descrito por el siguiente documento de Visión del problema.

El organismo dispone de distintas secciones y son cada una de ellas las que proyectan directamente las obras. Una sección contrata a una empresa para la realización de una obra interesando la fecha del contrato.
Las empresas pueden ser públicas o privadas. Existen a su vez dos tipos de obras; las obras de adjudicación directa y las que deben ser sometidas a licitación. Por reglamento, de las obras de adjudicación directa se puede encargar solamente una empresa pública, mientras que las empresas privadas solo se pueden encargar de las obras licitables. En cuanto a las obras directas, cuando una sección contrata a una empresa para realizarla se debe conocer para que obra. En cuanto a las obras licitables, pueden estar publicadas o no. Cuando una obra se publica, en el pliego de la
licitación debe figurar su información y (en cuanto se sepa) la información referente al contrato entre la sección y la empresa que la realizará.

Construir el Modelo de Dominio y presentarlo en un diagrama utilizando UML y OCL.

Solución:

Práctico 2 - Análisis - Modelado del Dominio

Ejercicio 2 (básico, imprescindible)

En la construcción de un sistema de información para el control hospitalario se relevaron los siguientes conceptos:

▪ Hospital, con los datos nombre, dirección y teléfono.
▪ Sala, con los datos número y cantidad de camas.
▪ Médico, con los datos cédula de identidad, nombre y especialidad.
▪ Paciente, con los datos cédula de identidad, nombre, dirección y fecha de nacimiento.

Por otra parte, las relaciones relevadas entre dichos conceptos son:

▪ Cada hospital tiene varias salas. Todas y cada una de ellas pertenecen a un hospital (y solo a uno).
▪ Cada médico trabaja en un único hospital. Todo hospital tiene al menos 10 médicos.
▪ Un paciente puede estar internado; si lo está, estará en una sala (y sólo en una).
▪ La capacidad máxima de camas que puede tener una sala es de cinco pacientes.
▪ Cada paciente puede ser atendido por más de un médico (pero por lo menos por uno), y a su vez cada médico puede atender varios pacientes.

Construir el Modelo de Dominio correspondiente y presentarlo en un diagrama utilizando UML.



Ejercicio 3 (básico, imprescindible)

Se tiene la siguiente información:

▪ Las personas frecuentan algún restaurante.
▪ A las personas les gustan distintas comidas.
▪ Los restaurantes sirven comidas.

Construir el Modelo de Dominio y presentarlo en un diagrama utilizando UML, teniendo en cuenta las siguientes restricciones:

▪ Un restaurante no sirve más de 10 comidas.
▪ Una persona frecuenta varios restaurantes.
▪ A una persona no le gusta una comida por sí sola sino cómo la sirven en determinados restaurantes, aunque puede no gustarle ninguna.
▪ Una comida servida por un restaurante puede no gustarle a ninguna persona.


Ejercicio 4 (básico, imprescindible)

Se cuenta con el siguiente documento de Visión del problema:

Las empresas producen productos y emplean a varios vendedores. Un vendedor trabaja para una sola empresa y vende un único producto de ésta.

El siguiente diagrama presenta el Modelo de Dominio que se ha construido.



a) ¿El Modelo de Dominio construido representa fielmente la realidad? Modificarlo para tal fin si se considera necesario.
b) Describir otras alternativas para representar la realidad anterior.
c) Modificar el modelo considerando que existen productos que no salen a la venta.




Ejercicio 5 (básico, imprescindible)
Se desea manejar información referente a ciudades y rutas entre las mismas, en varios países. Se considera un país como el conjunto de todas sus ciudades, y una ruta como una secuencia de ciudades. De los países y ciudades interesan sus nombres, y de las rutas su número. Construir el Modelo de Dominio y presentarlo en un diagrama utilizando UML.


Ejercicio 6 (básico, imprescindible)
Se desea modelar el funcionamiento de una compañía de transporte de cargas la cual mantiene una flota de vehículos. De cada vehículo se sabe su código (que lo identifica), si está disponible y su capacidad de carga. Un vehículo puede ser:
▪ una camioneta, de las que se sabe los viajes por semana que puede hacer, y si es doble cabina o no, ▪ un camión, de los que se conoce su potencia, y ▪ un camión con remolque, de los que se sabe la capacidad de carga extra del remolque y una descripción del mismo.
Un camión (con remolque o no) puede hacer un solo viaje por semana. El modelo debe reflejar el estado de la flota en una semana particular ya que semanalmente, la compañía desea estimar la capacidad de carga total de su flota (la suma de la cantidad de carga por semana para todos sus vehículos disponibles).

Construir el Modelo de Dominio y presentarlo en un diagrama utilizando UML.


Ejercicio 7 (básico, de práctica)
Construir el Modelo de Dominio a partir del siguiente documento de Visión del problema y presentarlo en un diagrama utilizando UML.

Una automotora mantiene información sobre los coches y sus clientes. De los clientes se sabe su nombre y teléfono, mientras que de los coches se sabe su marca, modelo, precio y número de chasis. Además un coche puede ser nuevo o usado. En caso de que sea usado interesa su matrícula, año y kilometraje; siendo posible que esté a consignación (sabiéndose el nombre del dueño) o que sea propiedad de la automotora (sabiéndose el precio que pagó por él la automotora). En caso de que sea nuevo interesa saber si es “full equip”. Un cliente puede estar interesado en un coche o haber comprado uno; en este último caso se conoce la fecha y la forma de pago.




Ejercicio 8 (básico, de práctica)

Se desea construir un sistema para la administración de información referente a proyectos.

Un proyecto se compone de tareas. Cada tarea tiene un identificador, una descripción textual, duración, fechas límite y real de comienzo, y fecha real de fin. Las tareas pueden ser interrumpibles o no interrumpibles. Para las tareas no interrumpibles interesa conocer el motivo por el cual no puede ser interrumpida y la fecha límite de finalización. La tareas interrumpibles no tienen fecha límite de finalización, y de las mismas interesa conocer la cantidad máxima de veces que puede ser interrumpida y la duración máxima de una interrupción.

Las tareas tienen asignados recursos. Una tarea puede tener varios recursos asignados y un recurso puede estar asignado a muchas tareas. Un recurso tiene un nombre asociado, la cantidad máxima de unidades disponibles y las cantidades mínimas y máximas que pueden asignarse del mismo a una tarea cualquiera. Cuando un recurso es asignado a una tarea (en cierta cantidad de unidades) será utilizado durante todo el período de tiempo en que dura la tarea. Los recursos pueden ser reutilizables o consumibles. Para los reutilizables se conoce la cantidad de unidades de tiempo que debe permanecer inutilizado el recurso luego de ser liberado para ser asignado a otra tarea. Para los consumibles interesa saber el costo de reposición de cada unidad del recurso.

Construir el Modelo de Dominio a partir del documento de Visión del problema presentado, y mostrarlo en uno o más diagramas utilizando UML.




Ejercicio 9 (medio, imprescindible)
Construir el Modelo de Dominio a partir del siguiente documento de Visión del problema referente a negocios inmobiliarios y presentarlo en un diagrama utilizando UML.

Una inmobiliaria tiene una carpeta de casas para mostrar, de las cuales se conoce la dirección y una descripción de sus comodidades. Las casas pueden estar a la venta o en alquiler, interesando en este último caso, si la casa está o no amueblada. Una casa puede ser mostrada por tres inmobiliarias como máximo. Los clientes pueden ver casas a través de ciertas inmobiliarias. Una inmobiliaria puede tener casas que no han sido visitadas por clientes. Dos inmobiliarias distintas pueden mostrar a un mismo cliente la misma casa. Puede darse el caso de que un cliente buscando casa, tenga la propia para venta o alquiler. De los clientes interesa su nombre y teléfono.


Ejercicio 10 (medio, de práctica)

Se quiere modelar el funcionamiento de un videoclub. El mismo maneja un conjunto de películas para alquiler, y un conjunto de socios a quien son alquiladas. De las películas interesa el código (que la identifica), el título, los actores principales y el género. Las películas pueden ser originales o copias. De las copias interesa saber su estado, pudiendo ser este “malo”, “bueno”, “muy bueno” o “excelente”. De los socios se desea saber el nombre, la dirección y el número de socio. El videoclub desea mantener las reservas de películas y aquellas que tiene en alquiler.

Construir el Modelo de Dominio a partir de la visión del problema planteado y presentarlo en un diagrama utilizando UML.




Ejercicio 11 (avanzado, de práctica)

Se desea modelar una realidad referente a un club deportivo.

El club tiene un conjunto de socios que son vitalicios, de los que interesa su antigüedad, y comunes, que se diferencian entre aquellos que pagan anualmente y aquellos que pagan mensualmente. De los primeros interesa la cuota que pagan, mientras que de los segundos, además de la cuota, interesa la fecha de aumento y el porcentaje del mismo. Hay cobradores, de los que se sabe su nombre y su zona, que cobran a los socios. De los profesores se conoce su nombre y que guían actividades, de las cuales se conoce su nombre. Toda actividad es guiada por algún profesor. Existen algunas actividades que se realizan dos o más veces por semana, conociéndose el día y hora en que el profesor guía cada actividad. El socio no sólo elije la actividad sino que también le interesa el profesor que la guía. Como hay que mantener contentos a los socios mensuales, interesa conocer qué profesor o profesores prefiere.

Construir el Modelo de Dominio a partir del documento de Visión del problema presentado y mostrarlo en uno o más diagramas utilizando UML.




Ejercicio 12 (avanzado, de práctica)

Una empresa maneja la información respecto a sus empleados y productos en stock, realidad descrita por el documento de Visión del problema presentado a continuación.

De los productos se conoce un código, una descripción y su precio de venta. Los productos pueden ser nacionales o importados. En caso de ser nacionales, se conoce el proveedor. Para el caso de productos importados, interesa contar con el nombre del importador y el país de procedencia.

Los productos son recibidos en partidas, las cuales se componen de varias unidades de un mismo producto. Interesa entonces manejar también la información referente a las partidas: fecha de ingreso, cantidad de unidades y de qué producto, y precio global de la misma. De las partidas de productos importados, interesa además el número de expediente generado por el despachante de aduana, del cual se conoce su nombre, número de permiso y dirección. De las partidas de productos nacionales, interesa el numero de remito del distribuidor.

De los empleados se conoce que existen varias categorías:

▪ Gerentes – se conoce el nombre, el código, el sueldo mensual y el total en pesos de la comisión recibida por las ventas.
▪ Comunes – se conoce el nombre, el código, el sueldo mensual y el tiempo a descontar (el descuento es lineal sobre las horas que debe trabajar en el mes).
▪ Vendedores – se conoce el nombre, el código, sueldo mensual, tiempo a descontar y el total en pesos de la comisión recibida por las ventas.
▪ Jornaleros – se conoce el nombre, el código, la cantidad de horas trabajadas y el valor de la hora a pagar.

Los vendedores se dedican a un grupo de productos que les asigna la empresa. Estos grupos están formados sólo por productos nacionales o sólo por productos importados (ningún vendedor maneja ambos tipos de productos). La venta de un producto no esta reservada a un único vendedor.

Construir el Modelo de Dominio y presentarlo en uno o más diagramas utilizando UML.

Yo quería ponerle "OOP-s", pero alguien ya me había ganado de mano... :'(