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 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.