Tema 3. Diagramas de UML en Rational Rose.

Gua de Prcticas

3.1 Introduccin
En este tema se detallan una serie de actividades que sirven como prctica inicial para el manejo de Rational Rose. El objetivo fundamental es familiarizarse con el entorno de trabajo al mismo tiempo que se empieza a tomar un primer contacto con la sintaxis y semntica de los diagramas UML. Nuestro agradecimiento a Patricio.Letelier (www.dsic.upv.es/~uml), profesor de la Universidad Politcnica de Valencia por compartir este trabajo.

3.2 Actividad 1
Con el botn derecho del ratn y estando en el navegador sobre el paquete de la Vista de Casos de Uso, haga new-package y cree un paquete que se llame Actividad 1. Estando sobre el paquete recin creado haga click con el botn derecho y cree dos nuevos paquetes que se llaman Ventanas y Editor, estos se crearn como paquetes dentro del paquete Actividad 1. Repita la operacin anterior y cree los subpaquetes Motif y MSWindows como subpaquetes de Ventanas y Controlador, Dominio, Elementos, Ncleo Motif, Ncleo Windows como subpaquetes de Editor. Sobre el paquete Actividad 1 realice new-Use Case Diagram, creando el diagrama Actividad 1. Haga doble click en el icono del diagrama e introduzca el diagrama mostrado en la Figura 3.1. Para ello arrastre desde el navegador los paquetes involucrados.

Repita el paso anterior para los paquetes Ventanas y Editor obteniendo los diagramas mostrados en las Figuras 3.2 y 3.3, respectivamente. En cada oportunidad arrastre desde el navegador los paquetes indicados. Consejo: Cuando quiera asociar un nuevo diagrama a un paquete basta con hacer doble clic sobre l y luego renombrar el diagrama obtenido (por defecto se denomina Main). Consejo: Utilice los botones anterior, respectivamente. para ir al diagrama padre o al diagrama

Editor

Ventanas

Figura 3.1: Diagrama Actividad 1

Motif

MSWindows

Figura 3.2: Diagrama Ventanas

Controlador Elementos

Dominio Ncleo Windows

Ncleo Motif

MSW indow (from Ventanas)

Motif (from Ventanas)

Figura 3.3 Diagrama Editor

3.3 Actividad 2
Estando en el navegador sobre el paquete de la Vista de Casos de Uso, con el botn derecho del ratn haga new-package y cree un paquete que se llame Actividad 2. Con el botn derecho del ratn y estando en el navegador sobre el paquete recin creado haga new-Use Case Diagram y cree un diagrama que se llame Actividad 2. Dibuje en el diagrama Actividad 2 lo mostrado en la figura 3.3.

Reintegro Cuenta Corriente

<<include>>

Cliente

Verificar Operacin <<include>>

Reintegro Cuenta de Crdito

Figura 3.3: Diagrama Actividad 2

Observaciones: Los estereotipos se introducen en la especificacin del smbolo de generalizacin (hacer doble clic sobre el smbolo para abrir su especificacin) La opcin Navigable establece la direccin en una asociacin (puede habilitarse o deshabilitarse con el botn derecho sobre el smbolo)

3.4 Actividad 3
Estando en el navegador sobre el paquete de la Vista de Casos de Uso, con el botn derecho del ratn haga new-package y cree un paquete que se llame Actividad 3. En el paquete recin haga new-Use Case Diagram y cree un diagrama que se llame Actividad 3. Dibuje en el diagrama Actividad 3 lo mostrado en la figura 3.4.

Cliente

Reintegro

Figura 3.4: Diagrama Actividad 3 Observacin: Puede arrastrar el actor Cliente desde el paquete Actividad 2. Con el botn derecho del ratn y estando en el navegador sobre el Caso de Uso Reintegro haga new-Sequence Diagram y cree un diagrama que se llame Reintegro Saldo Insuficiente. Haga doble clic en el diagrama Reintegro Saldo Insuficiente y dibuje el diagrama mostrado en la Figura 3.5

: Cliente tarjeta

:Cajero automtico

:cuenta

solicitar nmero secreto

nmero

solicitar cantidad

cantidad realizar transaccin(cantidad) saldo insuficiente saldo insuficiente

Figura 3.5: Diagrama Reintegro Saldo Insuficiente Haga Browse-Create Collaboration Diagram para obtener automticamente el Diagrama de Colaboracin asociado.

3.5 Actividad 4
Crear el paquete Actividad 4 en la Vista Lgica. Dentro de este paquete crear las clases: avin, motor, avin militar, avin comercial, vuelo, piloto, reserva, lnea area, avin de carga, avin de pasajeros, vendedor de billetes. Cree dentro de la Actividad 4 el Diagrama de Clases Actividad 4, mostrado de la Figura 3.6.

Motor 1..4

Piloto 1..2

Vendedor de billetes 1

1 Avin 1 n

n Vuelo n 1 n

n Reserva

{ disjunta, completa }

1 Avin militar Avin comercial Lnea area

{ disjunta, completa }

Avin de carga

Avin de pasajeros

Figura 3.6: Diagrama Actividad 4

3.6 Actividad 5
En la Vista Lgica cree el paquete Actividad 5. Dentro de este paquete cree un Diagrama de Clases que se llame Actividad 5. Incluya una nica clase dentro de este diagrama que se llame Alumno y complete segn lo mostrado en la Figura 3.7.
Alumno DNI : char[10] nmero_exp : int nombre : char[50] alta() poner_nota(asignatura : char *, ao : int, nota : float) matricular(cursos : asignatura, ao : int) listar_expediente()

Figura 3.7: Diagrama Actividad 5

Observacin: Pregunte al profesor si no consigue obtener la presentacin mostrada en la Figura 3.7.

3.7 Actividad 6
En la Vista Lgica cree un paquete denominado Actividad 6. Asociado al paquete Actividad 6 cree el Diagrama de Clases Actividad 6 e inserte las clases Departamento y Profesor y ascielas tal como se muestra en la Figura 3.8. Modifique la visibilidad de los roles eligiendo entre Pblico (+): el rol es visible fuera del mbito del paquete y puede referenciarse en otras partes del modelo; Implementacin (sin smbolo asociado): visible slo en el paquete en el que se define; Protected (#): accesible a la clase misma, a las subclases o friends; Private (-): accesible solo a la propia clase o friends.
1 Departamento depto profesores 0..*

rea_conocimiento : char * dirige

Profesor

director

0..1

Figura 3.8: Diagrama Actividad 6

3.8 Actividad 7
Cree el paquete Actividad 7 y dentro de l introduzca el diagrama de clases Actividad 7 con las clases Empresa, Empleado y Cargo. Defina en la clase Cargo los atributos Nombre y Sueldo. Establezca la asociacin entre Empresa y Empledo, mostrada en la figura 3.9.

empleador Empresa *

trabajadores Empleado 1..*

Cargo nombre sueldo subordinado 1..*

superior 0..1

Figura 3.9: Diagrama Actividad 7 Observacin: Use el smbolo de la barra de herramientas denominado Link Attribute para enlazar la clase Cargo con la asociacin entre Empresa y Empleado.

3.9 Actividad 8
Cree el paquete Actividad 8. Cree en el navegador las clases: Trabajador, Directivo, Administrativo, Obrero, Vehculo, Vehculo impulsado por viento, Vehculo Terrestre, Vehculo impulsado por motor, Vehculo acutico, Camin, Velero, Cuenta, Cuenta rentable y Cuenta no rentable. Cree el Diagrama de Clases llamado Actividad 8.1 segn se muestra en la Figura 3.10. Repita la operacin para las Figuras 3.11 y 3.12.

Trabajador

{ disjunta, completa }

Directivo

Administrativo

Obrero

Figura 3.10: Diagrama Actividad 8.1

Vehculo acutico

VehculoTerrestre

medio Velero Vehculo Camin impulsado por

Vehculo impulsado por viento

Vehculo impulsado por motor

Figura 3.11: Diagrama Actividad 8.2

Cuenta

{ disjunta, incompleta } saldo_medio > 1000

saldo saldo_medio < 500

Cuenta rentable

Cuenta no rentable

Figura 3.12: Diagrama Actividad 8.3

3.10 Actividad 9
Cree el paquete Actividad 9. Cree en este paquete la clase Socio en un Diagrama de Clases que se llame Actividad 9. La Figura 3.13 da el detalle de la estructura de la clase. Asocie a la clase anterior el Diagrama de Transicin de Estados de la Figura 3.14. Para ello, desde el navegador seleccionando la clase en cuestin y con el botn derecho del ratn escoja la opcin Open State Diagram.
Socio nmero : int nombre : char[50] nmero_prestamos : int = 0 alta() baja() prestar(cdigo_libro : int, fecha : date) devolver(cdigo_libro : int, fecha : date)

Figura 3.13: Diagrama Actividad 9

alta

baja nmero_prstamos = 0

sin prstamos

prestar

devolver[ nmero_prstamos = 1 ]

nmero_prst amos > 0 con prstamos prestar

devolver[ nmero_prstamos > 1 ]

Figura 3.14: Diagrama de Estados

3.11 Actividad 10
Cree en la Vista de Componentes un paquete que se llame Actividad 10 y dibuje el diagrama que se muestra en la Figura 3.15. Una relacin de dependencia entre componentes viene dado porque un componente usa las facilidades de otro. Esto se reduce a dependencias de compilacin entre componentes. Consulte en el Help los estereotipos para los componentes. Dibuje el Diagrama de Despliegue de la Figura 3.16. Una Connection representa p.e. un cable RS232, comunicacin va satlite, etc. Un Processor representa hardware con capacidad de computacin. Un Device incluye dispositivos hardware como terminales, modems, etc.
Interfaz de Terminal

Control y Anlisis

Gestin de Cuentas

Rut inas de Conexin

Acceso a DB

Figura 3.15: Diagrama de Componentes

Servidor Central

Gestor de Datos

Punto de Venta

Terminal de Venta

Figura 3.16: Diagrama de Despliegue

3.12 Actividad 11
Cree un nuevo modelo y renombre el diagrama Main de la Vista de Casos de Uso por ACME. Haga doble click sobre el icono del diagrama ACME y dibujando, introduzca los subpaquetes Publicidad, Ventas, Inventario y Contabilidad. El resultado se muestra en la Figura 3.17

Publicidad

Ventas

Inventario

C o ntabilidad

Figura 3.17: Diagrama ACME Haga doble click sobre el paquete Ventas en el Diagrama ACME e introduzca el diagrama de casos de uso mostrado en la Figura 3.18. Con el botn derecho sobre el diagrama llamado Main bajo el paquete Ventas renmbrelo por Ventas. Asociado al paquete Realizar Venta crear un diagrama de casos de uso llamado Realizar Venta. Hacer doble click sobre el icono que representa el paquete Realizar Venta e introduzca el diagrama mostrado en la Figura 3.19 Renombre como Realizar Venta el diagrama Main bajo el paquete Realizar Venta. El resultado hasta este punto puede verse en la Figura 3.20.

Supervisor

Verificar Situacin del Cliente

Administrativo

Preparar Catlogo

Sistema Inventario

Realizar Venta

Figura 3.18: Diagrama Ventas

Venta Normal

Vendedor

Venta de Rebaja

Venta de Oferta

Figura 3.19: Diagrama Realizar Venta

En los D. de Casos de Uso no existe el concepto de explosin tal como se tiene en los DFDs (Diagramas de Flujo de Datos). La funcionalidad representada por un caso de uso es atmica (aunque en Rational Rose 98 a un caso de uso se le puede asociar un nuevo D. de Casos de Uso!!). En UML el concepto de paquete permite organizar de manera jerrquica un modelo, y en este caso, un paquete puede tener asociado un nuevo diagrama.

Figura 3.20: Estado de la Prctica al terminar el paso f) Documente los casos de uso Venta Normal, Venta Rebajas, Venta Ofertas a partir de la informacin siguiente, presentada en tres estilos distintos (secuencia de pasos, condiciones pre-post de la aplicacin del caso de uso y, por ltimo descripcin narrativa). Venta Normal Cree un fichero word con el siguiente contenido: Caso de Uso Venta Normal El cliente se identifica mostrando su tarjeta y el DNI El vendedor revisa los datos del cliente El vendedor introduce su cdigo de vendedor e indica al sistema que se trata de una venta normal El sistema muestra la pantalla para introducir los datos de la venta El vendedor introduce los artculos mediante un lector de cdigo de barras o directamente por teclado. Pueden ser varios artculos en una misma venta. El vendedor solicita la emisin del recibo

El sistema imprime el recibo Haga doble click sobre el caso de uso Venta Normal del diagrama y en la pestaa Files con el botn derecho realice Insert File, asociando el fichero word recin creado. Venta en Oferta Haciendo doble click en el caso de uso Venta en Oferta y dentro del cuadro denominado documentacin, introducir: Precondiciones - Los artculos de la venta deben estar en oferta - El pago debe hacerse en efectivo - El artculo debe tener el suficiente stock para satisfacer la venta Postcondiciones - El stock del artculo se decrementa con la venta realizada - Se registran todos sus datos en la base de datos Venta en Rebajas Seleccionando el caso de uso Venta en Rebajas, introducir en el cuadro de documentacin (bajo el browser) el siguiente texto: En el periodo de rebajas los precios tienen una disminucin de precio tanto de forma individual como por grupos de artculos. Los descuentos se detallan en la correspondiente tabla de descuentos por grupo.

3.13 Actividad 12
Cree un nuevo modelo y renombre el diagrama Main de la Vista de Casos de Uso por Video Club. Introduzca en el Diagrama Video Club el modelo de la figura 3.21.

Encargado

Prestar Video

Figura 3.21: Diagrama Video Club

Cree un Diagrama de Secuencia asociado al Caso de Uso Prestar Video y denomnelo Prestar con xito. Arrastre desde el navegador el actor Encargado y complete el Diagrama de Secuencia segn lo mostrado en la Figura 3.22. Los objetos utilizados en este diagrama son annimos, es decir, slo se indica la clase a la cual pertenecen, pero no se les asigna un nombre especfico. Deshabilite la opcin Focus of Control en Tools-Options-Diagrams y observe el efecto. Cree el Diagrama de Colaboracin asociado al Diagrama de Secuencia dibujado mediante Browse-Create Collaboration Diagram. La Figura 3.23 muestra el diagrama de colaboracin que se debe obtener.

: Encargado

:WInPrstamos

:Socio

:Video

: Prstamo

prestar(video, socio) verificar situacin socio verificar situacin video

registrar prstamo entregar recibo

Figura 3.22: Diagrama Prestar con xito

:Socio

:Video 2: verificar situacin socio

1: prestar(video, socio) :WInPrstamos 5: entregar recibo : Encargado

3: verificar situacin video

4: registrar prstamo

:Prstamo

Figura 3.23: Diagrama Obtenido a partir del Diagrama Prestar con xito

Tema 5. Casos de Uso. Ejercicios Resueltos

Ejercicio 1. Gestin de fincas e inmuebles
Enunciado
Se desea desarrollar una aplicacin de gestin de fincas e inmuebles. La aplicacin deber cubrir todos los aspectos relacionados con dicho tema, teniendo en cuenta la siguiente dinmica de funcionamiento: Una empresa gestiona un conjunto de inmuebles, que administra en calidad de propietaria. Cada inmueble puede ser bien un local (local comercial, oficinas, ...), un piso o bien un edificio que a su vez tiene pisos y locales. Como el nmero de inmuebles que la empresa gestiona no es un nmero fijo, la empresa propietaria exige que la aplicacin permita tanto introducir nuevos inmuebles, con sus datos correspondientes (direccin, nmero, cdigo postal, ...), as como darlos de baja, modificarlos y consultarlos. Asimismo, que una empresa administre un edificio determinado no implica que gestione todos sus pisos y locales, por lo que la aplicacin tambin deber permitir introducir nuevos pisos o locales con sus datos correspondientes (planta, letra,...), darlos de baja, modificarlos y hacer consultas sobre ellos. Cualquier persona que tenga una nmina, un aval bancario, un contrato de trabajo o venga avalado por otra persona puede alquilar el edificio completo o alguno de los pisos o locales que no estn ya alquilados, y posteriormente desalquilarlo. Por ello debern poderse dar de alta, si son nuevos inquilinos, con sus datos correspondientes (nombre, DNI, edad, sexo, fotografa, ... ), poder modificarlos, darlos de baja, consultar, etc. (para la realizacin de cualquiera de estas operaciones es necesaria la identificacin por parte del inquilino). Por otra parte, cada mes el secretario de la empresa pedir la generacin de un recibo para cada uno de los pisos y de los locales, el cual lleva asociado un nmero de recibo que es nico para cada piso y

para cada local y que no variar a lo largo del tiempo, indicando el piso o local a que pertenece, la fecha de emisin, la renta, el agua, la luz, la actualizacin del IPC anual, portera, IVA, etc. Y otros conceptos, teniendo en cuenta que unos sern opcionales (slo para algunos recibos) y otros obligatorios (para todos los recibos). Adems, para cada recibo se desea saber si est o no cobrado. Con vistas a facilitar la emisin de recibos cada mes, la aplicacin deber permitir la generacin de recibos idnticos a los del mes anterior, a excepcin de la fecha. Adems debern existir utilidades para inicializar los conceptos que se desee de los recibos a una determinada cantidad y tambin debe ser posible modificar recibos emitidos en meses anteriores al actual. La aplicacin tambin deber presentar los recibos en formato impreso, pero teniendo en cuenta que en un recibo nunca aparecern aquellos conceptos cuyo importe sea igual a cero. De igual forma, el secretario debe poder gestionar los movimientos bancarios que se producen asociados a cada edificio, piso o local. Un movimiento bancario siempre estar asociado a un banco y a una cuenta determinada de ese banco. En esa cuenta existir un saldo, acreedor o deudor, que aumentar o disminuir con cada movimiento. Para cada movimiento se desea saber tambin la fecha en que se ha realizado. Un movimiento bancario puede ser de dos tipos: un gasto o un ingreso. Si el movimiento bancario es un gasto, entonces estar asociado a un inmueble determinado, y se indicar el tipo de gasto al que pertenece entre los que se tienen estipulados. Ejemplos de gastos son el coste de la reparacin de un ascensor del inmueble que pertenece a gastos de reparacin, el sueldo de la seora de la limpieza, etc. S el movimiento bancario es un ingreso entonces estar asociado a un piso de un inmueble determinado o a un local y tambin se indicar el tipo de ingreso al que pertenece, como en el caso de los gastos. Ejemplos de ingresos son precisamente los recibos que se cobran cada mes a los inquilinos. Basndose en los gastos e ingresos que se deducen de los movimientos bancarios, la aplicacin deber ser capaz de ocuparse de la gestin econmica generando los informes que facilitan la realizacin de la declaracin de la renta. Por ltimo, la aplicacin deber ser capaz de proporcionar el acceso, de forma estructurada, a toda la informacin almacenada en el sistema, generando para ello los listados necesarios que requiere el secretario. Ejemplos de listado son: el listado de todo los inquilinos ordenado por fechas, el listado de inquilinos que han pagado o no en un determinado intervalo de tiempo, el listado de todos los inmuebles, el listado de todos los pisos y locales de cada edificio, el listado de todos los recibos pendientes de cobro en un determinado intervalo de tiempo, etc.

Solucin:
A continuacin se muestra el diagrama de casos de uso en el que se representan al actor propietario y las tareas requeridas por el sistema de gestin de fincas e inmuebles (ver Figura 5.1). El propietario ser el responsable de la gestin del edificio, local o de los pisos mediante el alta, las modificaciones, consulta y la baja de los mismos. En este diagrama de casos de uso asociado con el propietario, los casos de usos con los que se comunica el actor son: ? Gestin de edificios. ? Gestin de locales. ? Gestin de pisos. Cada uno de los casos de uso anteriores refleja las actividades comunes que se deben realizar en el alta, baja, modificacin y consulta. Ya que en el enunciado se hace referencia a estas cuatro funcionalidades que se deben permitir en el sistema, se ha reflejado tal situacin introduciendo un caso de uso especfico si se hace referencia al edificio, al local o al piso. Se ha hecho este desglose y diferenciacin dependiendo de si es un edificio, local o piso, ya que las operaciones que conllevan cada uno es distinta aunque podamos nombrarlas de la misma forma. Los datos y actividades que se manejan son diferentes.

Figura 5.1:.Casos de uso relacionados con el actor propietario.

La relacin empleada para organizar los casos de uso es la de un extend, ya que se intenta identificar que cualquiera de estas funcionalidades se pueden o no realizar tanto individual corno conjuntamente. Adems, hemos relacionado mediante un extend el caso de uso de Gestin de locales y de pisos con el caso de uso Gestin de edificio. Con esto reflejamos que la gestin de edificios puede conllevar la gestin de locales, de pisos o de ambos. En el siguiente diagrama (ver Figura 5.2) se muestran los casos de uso relacionados con el actor inquilino. El inquilino va a ser aquella persona que tiene algn tipo de aval, de los expuestos en el enunciado, y, por tanto, puede realizar algunas de las siguientes operaciones en el sistema: ? ? ? ? ? Alquilar. Desalquilar. Darse de baja. Modificar sus datos. Consultarlos.

Para cada una de estas operaciones hay un caso de uso en el diagrama reflejando la situacin anterior. Adems, ya que se nos dice que para la realizacin de cualquiera de las operaciones es necesaria su identificacin, se ha reflejado un caso de uso nombrado Identificacin que se relaciona con los anteriores mediante la relacin de include. Con la relacin de include hacemos especial nfasis en esta situacin.

Figura 5.2: Casos de uso del actor 'Inquilino".

Tras volver a examinar con ms detalle la descripcin proporcionada se observa que cuando se produce el alquiler ste puede ser el de un piso (Alquiler Piso) un local (Alquiler Local) y de edificio (Alquiler de Edificio). Por ello se generan tres nuevos casos de uso que implican una relacin de extend con el caso de uso de Alquilar. Como hemos observado que la primera vez que se produce una operacin de alquiler se debe permitir el alta de los datos del inquilino, se ha creado el caso de uso Alta Inquilino como una extensin de Alquiler Piso, Alquiler Local y Alquiler Edificio. Finalmente, el ltimo diagrama de caso de uso que se muestra (Figura 5.3) es aquel en el que se encuentra involucrado el actor secretario. Tras una visin general de las caractersticas del sistema, observamos que las tareas del secretario son: Obtencin de los distintos tipos de recibos. Obtener los informes econmicos. Generacin de los listados. Como vemos, en aras de reflejar de una forma ms meticulosa las funcionalidades que debe contemplar el sistema, todos los casos de uso genricos, con los cuales est relacionado, se desglosan en otros casos de uso. Para ello se ha utilizado la relacin de extensin en algunos casos de uso. As pues, el caso de uso de "Generar recibos" est relacionado mediante un extend con los casos de uso: ? Recibos idnticos mes anterior. ? Inicializar conceptos. ? Modificar los del mes anterior. Este desglose se ha realizado para reflejar lo que el enunciado muestra con detalle y as poder tener una comprensin mayor de lo que el sistema debe de hacer. Por otra parte, la Gestin de movimientos bancarios se extiende en los casos de uso de Ingresos y Gastos de inmuebles, mientras que el de ingresos se extiende en ingresos de pisos e ingresos de local. De esta forma reflejamos el hecho de que los ingresos pueden ser de pisos, de locales o ambos, pero slo por esos conceptos.

Figura 5.3:Casos de uso relacionados con el actor "Secretario empresa". Finalmente, el caso de uso de Generacin de listados se extiende en distintos casos de uso dependiendo del tipo de listado que se ha comentado en el enunciado. Con esto se indica claramente cules son especficamente las operaciones que se deben poder realizar, obteniendo, por tanto, una mayor comprensin de los requisitos que debe tener el sistema. La extensin refleja esos comportamientos opcionales que puede haber en el sistema y que no tienen por qu ser exclusivos, en el sentido de que si se realiza uno se pueden realizar los otros, cuando se generan listados. Los casos de uso que tenemos son: Inquilino por fecha, Pagos inquilino en un intervalo de tiempo, Impagos inquilino en un intervalo de tiempo, De todos los inmuebles, De todos los pisos y locales de cada edificio, De recibos pendientes.

Ejercicio 2.
Enunciado

Gestin calificaciones Enunciado:

Se desea desarrollar una aplicacin de gestin de las calificaciones de los alumnos para satisfacer las numerosas quejas de los profesores, por el uso del lpiz y papel. La aplicacin deber cubrir nicamente aquellos aspectos relacionados con dicho tema, y que se describen a continuacin: El profesor recibe las actas en blanco de las asignaturas de las que es responsable, en formato electrnico. El acta contiene los siguientes datos de la asignatura (titulacin, campus, curso acadmico, denominacin de la asignatura, convocatoria y grupo) y la

lista de alumnos matriculados (niu, nif, nombre y apellidos). Alguna de las acciones que puede hacer el profesor son: ? ? ? Completar un acta con las notas de los alumnos. Aadir o borrar un alumno de un acta. Integrar las actas de varios grupos de una misma asignatura en una sola acta.

Otras de las opciones que se le exige a la aplicacin, para satisfacer completamente las necesidades del profesor, son las siguientes: ? Permitir la consulta de la siguiente informacin de cualquier alumno seleccionado: - DNI, N. EXPEDIENTE, Lista de asignaturas en las que est matriculado el alumno (Cdigo asignatura-Nombre asignatura). ? Obtener una estadstica de las calificaciones obtenidas por los alumnos en un determinado grupo de una asignatura. En esta estadstica se tendr para cada posible calificacin: - Nmero de personas con esa calificacin, Porcentaje sobre los presentados, Porcentaje sobre el total del grupo. ? Consultar el porcentaje de personas sobre el total del grupo que se han presentado y el de los que no se han presentado. ? Poder visualizar un grfico indicativo del nmero de personas que han obtenido una calificacin entre 0-0.99, 1-1.99, 2-2.99, 3-3.99, 4-4.99, 5-5.99, 6-6.99, 8-8.99, 9-10; indicndose la nota media obtenida por la clase. ? Disponer de una calculadora que permita realizar las operaciones de suma, resta, multiplicacin, divisin. Esta calculadora se activar cuando se vayan a introducir las notas a algn alumno de forma que una vez realizada la operacin aritmtica, pulsando un botn se vuelque el resultado en la casilla donde se estn introduciendo las calificaciones, redondendose a dos cifras decimales. ? Permitir la importacin y exportacin de la lista de alumnos con sus calificaciones a un formato compatible con MS Excel. ? Imprimir las actas y la lista provisional de calificaciones. Finalmente, como una ampliacin extra, a la cual slo podr acceder quien se identifique inicialmente como administrador de la aplicacin, se deben permitir: ? Gestin ABMC (Altas/Bajas/Modificacin y Consulta) de los datos de un alumno y su matriculacin en una asignatura y a un grupo. ? Gestin de Asignaturas, teniendo en cuenta que una asignatura slo se puede dar en un nico curso (primero, segundo, tercero...) y que cada curso est

formado ponlos datos sobre el nmero mximo de alumnos, nmero mnimo de crditos troncales y nmero mnimo de crditos optativos. Algunos de los datos que vamos a poder consultar de una asignatura son el nombre, nmero de crditos y cuatrimestre en el que se imparte. ? Gestin de Titulaciones, teniendo en cuenta que una titulacin slo se da en un campus determinado y los datos que podemos consultar son el nombre, el nmero de crditos o carga lectiva global, si es de 1. o 2.' ciclo, ... ? Gestin de grupos, en los que podemos consultar el nmero mximo de alumnos permitidos, si es un grupo de maana, de tarde o de noche, y cul es el cdigo empleado para identificar el grupo. ? Consultar aquellos alumnos que no se pueden matricular y el motivo de ello. ? Consultar el historial acadmico de un alumno.

Solucin
A continuacin se muestra el diagrama de casos de uso en el que se representan al actor profesor junto con las tareas que requiere del sistema de gestin de calificaciones (ver Figura 5.4). As tenemos que: El profesor ser aquel que puede realizar una serie de operaciones relacionadas con el listado de alumnos que tiene matriculados en sus asignaturas, tales como introducir las notas de alumnos, consultar el historial de alguno de sus alumnos, introducir o eliminar algn alumno en el listado y tareas de estadstica y de importacin y exportacin. Se ha intentado reflejar toda la funcionalidad del sistema asociada al actor profesor para poder mostrar qu es lo que se espera que haga el sistema de forma completa. As pues, se tiene el caso de uso de Poner notas, el cual se extiende en el caso de uso de Operaciones Calculadora. Con ello se refleja que el profesor al introducir las notas puede en algn momento hacer uso de las operaciones que aporta una calculadora. Y ya que actualmente una calculadora ofrece una gran variedad de operaciones se han detallado mediante la relacin de extend las operaciones que el profesor podra utilizar, como son: Sumar, Restar, Multiplicar o Dividir. Finalmente, para completar cul es la funcionalidad completa que se espera que permita el caso de uso de Operaciones Calculadora se identifica el caso de uso de Volcar Resultado mediante la relacin de include, ya que es algo que debe poder realizar siempre que se haga alguna operacin con la calculadora. Por otra parte, el caso de uso de Gestin de alumno se ha relacionado con el caso de uso de Aadir y Borrar mediante un extend para identificar explcitamente cules son las acciones que se espera que permita el sistema y

que o bien se puede realizar de forma individual o no, cuando el profesor utiliza el sistema. Otras de las funcionalidades que constituyen un caso de uso cada una son: Integrar grupos, Informacin alumno, Estadstica, Grfico, Importar y Exportar. De la misma forma que anteriormente hemos comentado, se ha realizado el proceso de identificacin explcita de las operaciones que se pueden realizar cuando el profesor quiere Imprimir. Se ha expresado mediante el extend las formas de impresin que puede tener el profesor reflejando que cuando se imprime puede imprimir slo las actas (Imprimir actas), slo las listas (Imprimir Listas provisional) o ambas.

Figura 5.4: Casos de uso relacionados con el actor "Profesor". Finalmente se muestra que todos los casos de uso con los que se relaciona de forma directa el actor se relacionan con el caso de uso de Validar Usuario para mostrar que es necesaria la identificacin del profesor en el sistema para poder realizar cualquier operacin comentada anteriormente. En el siguiente diagrama se muestran todos los casos de uso relacionados con el actor administrador del sistema (ver Figura 5.5). El administrador ser el responsable del mantenimiento de los datos que hay en el sistema respecto a las asignaturas y a los alumnos matriculados.

Como podemos observar, se ha intentado expresar toda la funcionalidad del sistema y por ello se han desglosado al mximo todos los casos de uso hasta que cada uno refleja una funcionalidad del sistema. En la siguiente figura se muestran cules son de forma explcita las funcionalidades que conlleva la gestin de los alumnos (caso de uso Gestin ABMC Alumnos). As pues, se ha expresado mediante la relacin de extend las distintas posibilidades que ofrece la gestin de alumnos, mostrndose adems que ninguna es excluyente y que se pueden realizar algunas de las operaciones o todas cuando el administrador gestiona a los alumnos (casos de uso Alta, Baja, Modificacin, Consulta Historial Acadmico). El resto de funcionalidades que el administrador espera del sistema son las siguientes: ? Matriculacin, que identifica a la capacidad del sistema para realizar la matriculacin de un alumno en las asignaturas, titulaciones y grupos existentes. ? Gestin de Asignaturas, que identifica la posibilidad que tiene el administrador para introducir, borrar, modificar y consultar las asignaturas. En este caso no se ha reflejado de forma explcita, ya que en el enunciado no aparece detallado cul es el alcance de la gestin de asignaturas.

Figura 5.5:Casos de uso relacionados con el actor "Administrador". ? Gestin de Titulaciones y Gestin de Grupos reflejan la posibilidad para que el administrador introduzca en el sistema los datos de titulaciones y

Grupos. Como ocurra anteriormente, al no detallarse en el enunciado del problema cul es el alcance real de estas operaciones slo se reflejan estos casos de uso sin el detalle mostrado para la Gestin ABMC Alumnos. Resaltar el hecho de que el caso de uso de Validar Usuario est relacionado, mediante la asociacin de include, con todos los casos de uso con los que se relaciona directamente el actor administrador. De esta forma indicamos que cualquier administrador que tenga que realizar una tarea o funcin debe identificarse en el sistema. El caso de uso que aparece en el grfico siguiente es el mismo que se identific anteriormente.

Ejercicio 3.
Enunciado

Puntos de informacin universitaria

La Universidad Carlos III de Madrid en su constante innovacin pretende instalar un conjunto de Puntos de Informacin Universitaria (PIU) a travs de los cuales se pueda facilitar informacin a la comunidad universitaria. Las funcionalidades consideradas para instalar en cada PIU son: ? Informacin General: actividades culturales y extra-acadmicas de la Universidad y de las diferentes Escuelas y Facultades. ? Informacin Administrativa: plazos de matriculacin, fechas de exmenes, normativas y avisos. ? Informacin Privada: esta informacin se diferenciar segn el tipo de usuario final que se identifique en el PIU. PAS: informacin relativa a su cuerpo e informacin econmico-contractual. Profesores: informacin relativa a su cuerpo, informacin de asignacin horaria de clases e informacin econmico-contractual. Alumnos: informacin referente a la carrera que estn cursando y su currculum, as como el estado de su matriculacin. Como ayuda a la resolucin de esta problemtica, la Universidad Carlos 111 ha pedido a su departamento de investigacin y desarrollo (I+D) la elaboracin de un sistema informtico que pueda ser utilizado por cuatro tipos de usuarios diferentes: ? Administrador: es el responsable de la colocacin y carga inicial de los PIU's en las diferentes Escuelas y Facultades que componen la Universidad, es decir, se encarga de decidir, las situaciones fsicas ms propicias y de activacin inicial de los contenidos (funcionalidades a proporcionar) de cada uno de los PIU's en las diferentes Escuelas y Facultades que componen la Universidad, es decir, se encarga

de decidir las situaciones fsicas ms propicias y de activacin inicial de los contenidos (funcionalidades a proporcionar) de cada uno de los PIU's. Por tanto, el administrador tan slo utilizar este sistema informtico para notificar la instalacin de los distintos dispositivos. Habr un administrador de dispositivos por cada turno de maana y de tarde para solucionar todas las peticiones realizadas por los responsables de cada centro. ? Gestor: es el encargado de determinar la situacin (funcionamiento/desconexin) de cada uno de los PIU's distribuidos previamente por el administrador del sistema. Asimismo, este usuario ser el responsable de determinar qu acciones se desencadenarn como consecuencia de la aparicin de un mal funcionamiento del PIU's, como puede ser: -Registro en una salida de "Log". - Envo de un equipo tcnico. -Reporte del error al CAT (Centro de Atencin Tcnico). -Reinicializacin del PIU. -Emisin de una solicitud de desconexin del PIU al administrador. Como la principal misin de los gestores de los PIU's es la regulacin y mantenimiento de los mismos, tan slo utilizarn el sistema informtico de forma espordica, para retocar los parmetros de funcionamiento del sistema cuando se detectan anomalas a tener en cuenta. Habr un gestor de dispositivos en el turno de maana y en el de tarde. ? Operador: es el usuario responsable de gestionar el funcionamiento de cada uno de los PIU's existentes en cada una de las Escuelas y Facultades. Su actividad consistir en el control de red, es decir, se encarga de verificar el funcionamiento global de la red de PIU's existente. Pudiendo realizar operaciones de control, gestin y estadsticas sobre la misma. Adems, se encarga de reportar los errores observados al Gestor que est de guardia en cada momento. Los operadores estarn utilizando continuamente el sistema de seguimiento de los PIU's, tan slo lo dejarn de utilizar en los periodos de descanso acordados. La Universidad utilizar a tres operadores en activo para cada uno de los turnos de servicio (maana, tarde y noche). Por ltimo, los operadores tambin debern realizar las acciones indicadas por el gestor del sistema en caso de que ste no est localizable. ? Usuarios Finales: este grupo est compuesto por el PAS, el Profesorado y el Alumnado. Su conexin al sistema vendr siempre asociada a una solicitud/servicio de informacin. Cada vez que un usuario intente conectarse al sistema deber introducir sus datos identificativos, as como la introduccin de una contrasea y del tipo de usuario (en

caso de que sea necesario). Las actividades recogidas por el sistema slo estarn accesibles para el tipo de usuario responsable de su realizacin, de tal manera, que la instalacin de PIU's no estar accesible a un gestor o a un operador, del mismo modo la gestin de red no podr ser realizada por un administrador o por un gestor. Instalacin de los PIU's Para instalar un PIU dentro de una Facultad o Escuela ser necesario, en primer lugar, seleccionar la Escuela/Facultad, de tal modo que slo puede haber un nico dispositivo de un tipo determinado en una misma Escuela/Facultad. A continuacin se indicar las funcionalidades que soportar dicho PIU. Ser posible que el administrador de los PIU's cambie la colocacin de los mismos, as como el resto de caractersticas propias del PIU. Control de funcionamiento Peridicamente, el gestor de los PIU's podr observar el estado de funcionamiento de cada uno de los PIU's as como ajustar las acciones a realizar qu se desencadenar como consecuencia de la aparicin de un mal funcionamiento del PIU's. Gestin de red Se podrn realizar operacin de control, gestin y estadstica sobre la red instalada observando la aparicin de errores, que debern ser reportados al gestor de guardia. Obtencin de informacin Los Usuarios Finales realizarn peticiones al sistema guiados a travs de la interfaz grfica del sistema, su nica interrelacin con el sistema, consiste en la emisin de dichas peticiones para que sean procesadas y servidas por el sistema.

Solucin
A continuacin se muestra el diagrama de casos de uso en el que se representan todos los actores y las tareas requeridas por el sistema de gestin de PIU's (ver Figura 5.6). Identificamos inicialmente a los actores que van a interactuar de alguna forma con el sistema, obteniendo la siguiente lista: El Administrador. El Gestor. El Operador o vigilante. El Usuario final.

Una vez que hemos identificado a los distintos usuarios registramos las operaciones que cada uno de ellos debe de poder realizar en el sistema. As pues, indicamos las funcionalidades del sistema desde el punto de vista del usuario del sistema. As tenemos que: ? administrador ser aquel que realice las tareas de instalacin de los PIU's. El ? gestor ser el responsable de controlar el buen funcionamiento de los El diferentes PIU's existentes en el sistema. ? El vigilante ser el responsable de la gestin de la red en la que se encuentran los diferentes PIU's existentes en el sistema. ? El usuario final estar destinado a la realizacin de las consultas necesarias para la extraccin de la informacin contenida en los PIU's. Cada una de estas funcionalidades se representan como un caso de uso relacionado o asociado con el actor que tiene que demandarla.

Figura 5.6:Casos de uso del "sistema de informacin universitaria". Podemos observar con la descripcin del problema que todos los actores van a tener la tarea de su idenificacin previamente a la realizacin de cualquier tarea, con lo cual utilizaremos la relacin de include entre la nueva funcionalidad de Identificacin y el resto. Con ello indicamos explcitamente que para realizar cualquier operacin en el sistema es necesario la identificacin.

Al examinar con posterioridad el enunciado observamos que existe una serie de funcionalidades que no habamos detectado y que mostramos en la Figura 5.7. Identificamos que la operacin de instalacin de PIU's tiene embebido las operaciones de Instalacin de PIU existente y/o la Instalacin de nuevo PIU. Para representar esta relacin entre las distintas funcionalidades que deben existir empleamos la relacin de extend entre el caso de uso Instalacin de los PIU's y los casos de uso Instalacin PIU existente e Instalacin nuevo PIU. Con ello reflejamos la semntica que nos proporciona la descripcin del problema. De forma anloga sucede con la operacin de Control de Funcionamiento. Observamos que esta operacin supone la realizacin o no de la funcin de Determinar las acciones por mal funcionamiento, Realizar las acciones correctivas y Actualizar los parmetros de los PIU. Representamos pues estos casos de uso con una relacin extend entre el caso de uso Control de funcionamiento y los casos de uso Determinar Acciones Mal Funcionamiento, Actualizar Parmetros PIU y Realizar Acciones Correctivas. De esa forma reflejamos el carcter de opcionalidad al realizar la funcin de control de funcionamiento.

Figura 5.7: Relaciones entre los casos de uso del "sistema de informacin universitaria".

Finalmente tambin sucede lo mismo con la funcionalidad de Gestin de Red, ya que supone las operaciones de Realizar Informe, Configurar Estadsticas y Obtener Resultados de Estadsticas. Segn el enunciado, estas operaciones pueden realizarse en determinados momentos, lo que supone que para relacionar los distintos casos de uso que conforman cada una de estas operaciones es necesario utilizar la relacin de extend entre el caso de uso Gestin de Red y los otros tres.

Tema 7. Diagramas Ejercicios Resueltos

Ejercicio 1.
Enunciado

de

Interaccin.

Gestin de dietas

Se pretende modelar el funcionamiento de un servicio de atencin mdica. El hitolfase actual del proyecto es el desarrollo del MAD (Mdulo Automatizado de Diettica), con l se pretende que el mdico cuente con una herramienta que facilite la asignacin de dietas a los pacientes. Para poder llevar a cabo sus funciones el MAD deber poder consultar informacin sobre los pacientes (su historia clnica), las enfermedades y los posibles tratamientos (dietas). Para la obtencin de las posibles dietas el MAD cuenta con un mdulo subordinado (al que emite solicitudes) denominado DIETAS, que es el encargado de definir y prepocesar dietas para el MAD. La operativa de trabajo utilizada para la automatizacin de la realizacin de diagnsticos y tratamientos se define en la enumeracin de los siguientes pasos: 1. Un mdulo no definido actualmente y denominado Gestor de Solicitudes (GS) es el encargado de solicitar un tratamiento al MAD, proporcionndole como nica informacin el paciente a tratar. 2. El mdulo de dietas (MAD) obtiene la historia clnica del paciente. La historia clnica del paciente slo se facilita al MAD si dicho paciente est adscrito al servicio de Nutricin. En otro caso se produce una situacin de excepcin que se soluciona informando al MAD y ste a su vez al GS, dando de esta manera por finalizada la peticin de tratamiento. 3. Para cada una de las enfermedades a tratar que el mdulo MAD recibe, emite una solicitud de dieta al mdulo DIETAS, incluyendo en ella todos los datos necesarios para que se lleve a cabo con xito.

4. El mdulo DIETAS para cada una de las peticiones de dieta que recibe solicita informacin de todas las fuentes alimentarias asociadas a los nutrientes, cuyo dficit produce la enfermedad a tratar. Que una vez recibe, le sirven para generar una dieta aconsejada, que enva al mdulo de dietas (MAD). Una vez que el mdulo de dietas (MAD) recibe todas las dietas aconsejadas para todas las enfermedades para las cuales solicit tratamiento. Las readapta teniendo en cuenta las condiciones caractersticas del caso que se est tratando y las une. Generando una dieta final verificada que es enviada al GS. Se pide representar un diagrama de secuencia y el correspondiente diagrama de colaboracin, que contemple las acciones desencadenadas por el sistema cuando el mdulo MAD recibe una solicitud de tratamiento emitida por el Gestor de Solicitudes (actor) y se dan todas las condiciones para que la peticin llegue a buen trmino.

Solucin
El primer paso a dar para construir un diagrama de secuencia es identificar cul es la actividad del sistema que se quiere representar y quin es el actor que desencadena dicha actividad. En este caso, la actividad en cuestin es aquella a travs de la cual el sistema es capaz de proporcionar la dieta ms apropiada para un paciente concreto. El actor que desencadena o demanda dicha actividad es el Gestor de Solicitudes (GS), tal y como se extrae del paso uno de la operativa de trabajo descrita en el enunciado, ya que ste demanda al sistema que inicie el mecanismo que termina con la obtencin de la dieta ms apropiada. A continuacin se deben identificar las clases que van a participar en el desarrollo de dicha actividad. Para ello, se debe identificar una secuencia de pasos ms cortos en los que se divide dicha actividad y listarlos uno tras otro. Dicho conjunto de pasos que conducen a la obtencin de la dieta especfica pueden aparecer diseminados en distintos puntos de la especificacin del problema a resolver. En este caso los pasos son los siguientes: 1. El GS solicita tratamiento para un paciente concreto y se lo solicita al MAD (Mdulo de Dietas): de este paso se deduce que se tiene un actor, el GS, que solicita al MAD un tratamiento para un paciente. Esto queda representado en la Figura 7.1, y en la Figura 7.2 con el mensaje que le enva el actor GS a la clase MAD.

Figura 7.1: Diagrama de secuencia de obtencin de la dieta ms adecuada

Figura 7.2: Diagrama de colaboracin de obtencin de la dieta ms adecuada

2. A continuacin el MAD solicita la historia clnica de ese paciente. Como la historia clnica es una clase, ya que tiene muchos datos y diferentes operaciones asociadas, esta peticin se representa en la Figura 7.1, y en la Figura 7.2, con el mensaje que le enva la clase MAD a la clase Historia Clnica. 3. Si dicho paciente tiene Historia Clnica, la clase Historia Clnica le devuelve los datos correspondientes de ese paciente al MAD. 4. Por cada una de las enfermedades que aparecen en la Historia Clnica del Paciente, el MAD enva un mensaje a la clase enfermedad, para que le enve los datos relevantes sobre dicha enfermedad. Esto queda representado en la Figura 7.1, y en la Figura 7.2, con el mensaje que le enva la clase MAD a la clase Enfermedad (solicitud enfermedades), y el mensaje que le enva la clase Enfermedad a la clase MAD (enfermedades a tratar). Ambos mensajes se repetirn tantas veces como enfermedades tenga diagnosticadas dicho paciente. Para indicar esto en UML se puede utilizar una nota, o bien comentarlo junto al diagrama a pie de pgina. 5. Una vez que el MAD sabe todas las enfermedades diagnosticadas al paciente en cuestin, le enva un mensaje a la clase Dietas (solicitud dietas). 6. La clase Dietas enva un mensaje a la clase nutrientes (solicitud fuentes) para identificar cules son los nutrientes cuyo dficit provocan cada una de las enfermedades de ese paciente. Los nutrientes le envan un mensaje a la clase dietas (fuentes alimentarias). 7. Cuando la clase Dietas ha recibido todos los mensajes de la clase Nutrientes, enva un mensaje a la clase MAD con la dieta adecuada (dieta recomendada). 8. A su vez la clase MAD, que es la encargada de conectarse con el Actor (GS), le enva un mensaje con la dieta solicitada (dieta final revisada). La Figura 7.1 y la Figura 7.2 representan la misma secuencia anterior, la nica diferencia radica en la forma de representar los datos. En la primera, la lectura se hace de arriba abajo y de izquierda a derecha. Mientras que para la segunda el punto de comienzo sigue siendo el actor (gestor de solicitudes) y la lectura se hace segn un nmero de orden que se debe ir aadiendo a cada mensaje que se genere entre clases.

Ejercicio 2. Control de trfico en un cruce regulado por semforo

Enunciado
El diagrama de clases de la Figura 7.3 muestra la estructura de un controlador de trfico empleado para regular un cruce de calles como el mostrado en la Figura 7.4. Cada calle tiene dos carriles en cada sentido, que permiten en el cruce el giro a la izquierda y a la derecha respectivamente, adems de la marcha hacia delante.

Figura 7.3: Diagrama de clases correspondiente al control de trfico

Figura: 7.4: Cruce de calles.

El controlador est asociado a cuatro semforos y cuatro detectores, identificados cada uno por su posicin: N (norte), E (este), S (sur) y W (oeste). El controlador alterna el trfico en direccin N-S y de acuerdo con un temporizador interno. En cada ciclo de funcionamiento de un semforo se permite primero la circulacin hacia delante (o hacia la derecha) y a continuacin el giro hacia la izquierda. Cada semforo tiene dos hileras verticales de luces, una para controlar la circulacin hacia de la otra hacia la izquierda (siempre que se puede ir hacia delante se puede girar a la derecha, de modo que necesaria una hilera especial para permitir o prohibir el giro a la derecha). Para simplificar, en cada 1 slo se consideran las luces roja y verde, despreciando los breves segundos que el semforo est en antes de pasar de verde a rojo. La operacin "ponerLuces" admite dos parmetros, que son el color que tomar cada una de las dos hileras en un cambio de color. Los semforos N y S estn coordinados de 1 que siempre tienen las mismas luces encendidas; igual ocurre con los semforos E y W. La Figura 7.4 muestra el flujo de vehculos girando a la izquierda en la calle N-S. Cada detector vigila el carril de giro a la izquierda, informando al controlador de que hay un vehiculo detenido esperando a que el semforo le permita el giro. La operacin "detectarVehculo" del centro sirve para que un detector le informe de que efectivamente hay un vehculo esperando en la posicin(N,S,E, W) especificada en el parmetro. El controlador utiliza la informacin de los cuatro detectores para optimizar el funcionamiento del cruce, de modo que si no hay coches esperando para girar a la izquierda se prescinde de la parte del ciclo correspondiente. Se pide construir el diagrama de secuencia y el de colaboracin asociado al control de los semforo el cruce que refleje el paso de vehculos de Este a Oeste y viceversa y no lo permita en direccin Norte y Sur Norte. As como el giro de vehculos en sentido Oeste Norte y Este Sur cuando se detecte un vehculo esperando para girar. Utilizando para ello los mtodos que aparecen en el modelo de clases de la Figura y el diagrama que representa el funcionamiento del cruce de la Figura 7.4.

Solucin
En la Figura 7.5 y Figura 7.6 se pueden ver los diagramas de secuencia y colaboracin correspondiente dicho funcionamiento. En primer lugar hay que identificar el actor que inicia el proceso de control del cruce. En este ea trata de un actor interno al sistema que podemos denominar Reloj. A partir de que se pone en marcha i reloj, el control del cruce queda regulado por el controlador del cruce.

Figura 7.5: Diagrama de Secuencia

Figura 7.6: Diagrama de Colaboracin

Tema 8. Diagrama de Estados. Ejercicios Resueltos

Ejercicio 1.
Enunciado
El objetivo de este ejercicio es la identificacin de los estados por los que pasarn tanto la clase Historia Clnica como la clase Mdulo de Dietas (MAD). Dichos datos deben ser extrados de la informacin que se adjunta sobre el funcionamiento de un sistema de atencin mdica que se pretende desarrollar. Para poder llevar a cabo sus funciones, el MAD deber poder consultar informacin sobre los pacientes (su historia clnica), las enfermedades y los posibles tratamientos (dietas). Para la obtencin de las posibles dietas el MAD cuenta con un mdulo subordinado (al que emite solicitudes) denominado DIETAS, que es el encargado de definir y prepocesar dietas para el MAD. Un mdulo no definido actualmente y denominado Gestor de Solicitudes (GS) es el encargado de solicitar un tratamiento al MAD, proporcionndole como nica informacin el paciente a tratar. El mdulo de dietas (MAD) obtiene la historia clnica del paciente. La historia clnica del paciente slo se facilita al MAD si dicho paciente est adscrito al servicio de Nutricin. En otro caso se produce una situacin de excepcin que se soluciona informando al MAD y ste a su vez al GS, dando de esta manera por finalizada la peticin de tratamiento. Para cada una de las enfermedades a tratar que recibe el mdulo MAD emite una solicitud de dieta al mdulo DIETAS, incluyendo en ella todos los datos necesarios para que se lleve a cabo con xito. El mdulo DIETAS para cada una de las peticiones de dieta que recibe solicita informacin de todas las fuentes alimentarias asociadas a los nutrientes, cuyo dficit

Sistema de Solicitud de Dietas

produce la enfermedad a tratar. Que una vez recibe, le sirven para generar una dieta aconsejada, que enva al mdulo de dietas (MAD). Una vez que el mdulo de dietas (MAD) recibe todas las dietas aconsejadas para todas las enfermedades para las cuales solicit tratamiento. Las readapta teniendo en cuenta las condiciones caractersticas del caso que se est tratando y las une. Generando una dieta final, verificada, que es enviada al GS.

Solucin
El diagrama de transicin de estados correspondiente a la clase historia clnica es el que aparece en la Figura 8.1

Figura 8.1: Diagrama de transicin de estados de la clase historia clnica Para realizar dicho diagrama el primer paso es la identificacin del punto de comienzo en la vida de una historia clnica. Para ello se debe buscar en el enunciado el primer momento en que dicha clase es demandada para realizar alguna actividad. Ese momento marca el comienzo del diagrama de transicin de estados y se produce cuando el MAD le solicita la historia clnica de un paciente determinado, a travs del mensaje solicitud-h-c(paciente). Desde ese momento hasta que la clase historia clnica comprueba la existencia de la historia clnica de ese paciente, la clase historia clnica est en el estado Buscando Paciente. En el caso en que el paciente no est registrado, es decir, no se encuentre la historia clnica de dicho paciente, la clase historia clnica pasa al estado Emitir Notificacin de no Existencia, tras el cual termina su actividad, o por decirlo de otro modo, pasa al estado de finalizacin. Si por el contrario la historia clnica de dicho paciente existe, la clase historia clnica pasa al estado Buscar Historia Clnica, y se mantiene en dicho estado hasta que tenga todos los datos de la historia de dicho paciente. Una vez localizados todos los datos de dicha historia clnica, termina su actividad pasando al estado de fin.

Para el caso de la clase MAD, se identifica que el momento en que dicha clase es activada por primera vez es cuando el actor GS solicita un tratamiento a travs del mensaje, solicitud-tratamiento (paciente), como se indica en la Figura 8.2. En ese momento la clase MAD pasa al estado Solicitando-Historia-Clnica. Una vez que la clase MAD recibe el mensaje datos-historia-clnica se puede extraer del enunciado que pasa al estado solicitando-enfermedades. Se mantendr en este estado hasta que alguna otra clase le enve un mensaje indicndole cules son las enfermedades a tratar. Una vez que recibe el mensaje enfermedades-a-tratar pasa al estado Solicitando Dieta. Hasta que la clase dietas no termine de confeccionar la dieta apropiada, la clase MAD permanecer en el estado Solicitando Dietas. Cuando la clase dietas le enve a la clase MAD el mensaje dieta-final-revisada, la clase MAD pasar al estado Revisando Dieta, y cuando termine dicha revisin se la enviar al GS mediante el mensaje dieta-final revisada, tras cuya recepcin pasar al estado final y su ciclo de vida terminar hasta la prxima solicitud de tratamiento de un paciente por parte del GS.

Figura 8.2: Diagrama de transicin de estado de la clase MAD

Ejercicio 2.
Enunciado

Gestin de un restaurante

Una cadena de restaurantes quiere automatizar el proceso de reservas as como el de los pedidos de cada mesa y la cantidad que hay en la cocina de cada uno de los

productos que se manejan para la realizacin de cada plato, y que obviamente han de ser repuestos desde el almacn a medida que stos se van terminando. Los clientes de los restaurantes pueden llamar por telfono para reservar una mesa, pero lo que se est intentando poner de moda es el uso de unos terminales punto de reserva (TPR) ubicados en la calle. La ventaja que tiene el uso de estos terminales es la posibilidad de elegir la mesa en funcin de su ubicacin dentro del restaurante, cosa que no se puede hacer por telfono. Las mesas estn separadas en mesas de fumador, marcada con la F, y de no fumador, marcadas con NF. Adems, cada mesa lleva un indicador con el nmero de personas para el que est pensada dicha mesa. Si el cliente llega al restaurante veinte minutos despus de la hora de reserva de la mesa, el sistema se encargar automticamente de dejar libre dicha mesa. Si no hay mesas libres a la hora indicada por el usuario, el TPR se lo comunica al cliente, dndole adems la posibilidad de solicitar al sistema sugerencias sobre restaurantes disponibles a la hora y en el da solicitado. Cuando un cliente llega a uno de los restaurantes de la cadena, se le pregunta si tiene reserva o no. En el caso en que tenga reserva, bastar con que presente el ticket, si la hora de reserva no supera en veinte minutos a la hora de llegada al restaurante, la mesa pasa de estar libre a ocupada y se les sienta en el lugar que les corresponde. Si por el contrario la hora de llegada supera en veinte minutos a la hora de reserva, el sistema se habr encargado de anular dicha reserva de modo que la mesa haya quedado libre para otro posible cliente, por tanto, se les trata del mismo modo que si no tuvieran reserva. En ese caso el encargado en ese momento de las reservas solicita al sistema que le muestre las mesas libres para ese momento; si hay mesas libres, le pregunta al usuario si quiere mesa de fumador o de no fumador y cuntas personas son, el usuario se lo dice y en caso de que haya mesa libre, el encargado hace la reserva y les sienta. Si no hay mesa, el encargado le debe pedir al sistema el tiempo aproximado para que quede libre la prxima mesa de las caractersticas de la mesa solicitada. Esto podr calcularlo el sistema a travs del estado en que se encuentran las distintas mesas en un determinado momento; estos estados son: Libre: si nadie la ha reservado. Reservada: si alguien ha hecho una reserva. Ocupada: si los comensales estn ya a la mesa. Pidiendo: s el camarero est recogiendo el pedido de esa mesa. En espera de comida: si estn esperando que se les sirva. Servidos: si los comensales ya tienen la comida en la mesa.

Esperando cuenta: si los comensales han pedido la cuenta. Pagando: si los comensales ya tienen la cuenta en la mesa. A partir de la informacin contenida en el enunciado se pide describir el comportamiento de la clase mesa, dentro del sistema de gestin de reservas.

Solucin
El objetivo que persigue la cadena de restaurantes controlando el estado de sus mesas es poder dar mejor servicio a sus clientes no slo a la hora de hacer una reserva por TPR o telfono sino tambin cundo; sin haber hecho una reserva previa, se acercan al restaurante para comer o cenar y en caso de que no haya una mesa libre con las condiciones que quieren los comensales, poder indicarles el tiempo que queda para que quede libre una mesa de las caractersticas indicadas. Para poder llevar a cabo esta labor sin necesidad de que el encargado del restaurante tenga que ir mesa por mesa, que cumplan las caractersticas indicadas, viendo en ese momento lo que se encuentran haciendo las personas que estn sentadas a la mesa, se quiere dotar al sistema de reservas de un mdulo que permita hacer este proceso automticamente. Para ello es necesario incluir en el sistema una clase MESA, cuyo ciclo de vida permita identificar, a partir del momento en que se encuentra actualmente, el tiempo que queda para que se quede libre. Para ello, es importante identificar el tiempo que los comensales tardan en realizar cada uno de los pasos que se llevan a cabo cuando estn sentados a la mesa. Dicho comportamiento se extrae del enunciado y quedar reflejado a travs del diagrama de transicin de estados de la clase MESA que aparece en la Figura 8.3. El ciclo de vida de la clase mesa comienza cuando se abre el restaurante y se conecta el sistema de Reservas del restaurante. En ese momento la clase MESA pasa a estar en estado libre. En el momento en que los primeros comensales llegan al restaurante se les pregunta si tienen reserva o no. En caso de que tengan la reserva se les sienta en la mesa correspondiente y, por lo tanto, esa mesa pasa a estar en el estado Pidiendo, en el cual estarn hasta que el camarero termine de tomarles nota. Cuando el camarero haya terminado de tomar nota la mesa pasa a un estado en el que los comensales estn esperando a estar servidos, lo que implica que la clase MESA pase al estado Esperando Comida. Una vez que los platos estn cocinados, el camarero les sirve y en ese momento el sistema pasa la clase MESA al estado Servidos, que durar mientras los comensales estn comiendo los platos que han pedido. Una vez que hayan terminado de comer y pidan la cuenta el sistema se encargar de poner esa MESA en estado de Esperando Cuenta, y permanecer en este estado hasta que el camarero les traiga la cuenta y paguen, momento en el cual el sistema pasa dicha MESA al estado Libre. En este estado permanecer mientras no lleguen nuevos comensales. En el

momento del cierre del restaurante, el ciclo de vida de esa MESA termina pasando al estado de fin. Si los comensales que llegan no tienen mesa reservada y quieren comer o cenar, el encargado del restaurante les preguntar las caractersticas de la mesa que quieren e introducir dichos datos en el sistema. El sistema ir comprobando por cada una de las mesas que cumplen con las caractersticas indicadas por los clientes y calcular el tiempo que queda para que queden libres en funcin del estado en que cada una de ellas se encuentra. Del enunciado se puede extraer en conclusin que existe un estado ms referente a la MESA cuando est Reservada, pero en realidad este estado no le corresponde a la clase MESA. El hecho de que una mesa est o no reservada estar contemplado en otra clase, posiblemente la clase RESERVA, ya que una reserva es algo ms que un simple estado, es la hora de la reserva, el nombre al que se hace la reserva, etc. Lo que s existir ser una relacin entre una mesa y todas sus reservas.

Figura 8.3: Diagrama de transicin de estado de la clase MESA.

Ejercicio 4.
Enunciado

Venta de Productos por Internet

El objetivo principal de este sistema es ofrecer la posibilidad de realizar fcil y eficazmente toda gama de acciones sobre marketing clsicas. Una empresa proveedora puede catalogar sus productos y ponerlos a disposicin de sus clientes a travs de la red y con la forma ms real posible. El cliente puede

consultar el catlogo y efectuar varias operaciones a distancia sobre su contenido. Se pretende dar al cliente la posibilidad de visualizar estos productos en forma de tres dimensiones y dejarle toda la libertad de intervenir sobre el aspecto en tiempo real (color, dimensin, etc.). Tambin se ofrece la posibilidad de hacer pedidos y seguir su evolucin. Los productos estarn en forma de objetos tridimensional (3D) y la consulta consistir en visualizar y manipular esos objetos tridimensionales en tiempo real. El pedido se hace tomando en consideracin las modificaciones que se han podido efectuar por el- cliente y almacenando dichas preferencias para que el personal de la empresa pueda consultarlas y procesar debidamente el pedido del cliente. Si, por ejemplo, lo que est comprando el cliente es un sof y le ha puesto una tapicera de color azul, esas sern sus preferencias a la hora de hacer el pedido. Cuando el usuario accede al sistema, el escenario o la escena en la que se visualizan los productos seleccionados est vaco, en el momento en que empieza a seleccionar productos stos aparecen visualmente en la pantalla de su ordenador. El cliente tiene la posibilidad de interactuar con el sistema para cambiar el color de uno de los objetos visualizados, la textura o manipularlo. Las posibilidades que tiene de manipulacin son: rotar el producto seleccionado, cambiarlo de dimensiones o cambiarlo de posicin. Lo que se pide en este ejercicio es construir el diagrama de transicin de estados correspondiente al caso de uso que comienza cuando el cliente se conecta al sistema y selecciona algn producto para posteriormente interactuar con l en la escena en la que se visualizan los productos que va seleccionando.

Solucin
La Figura 8.4 muestra un diagrama de estados para casos de uso y describe visualmente los estados del caso de uso Seleccionar y Manipular un producto. Esto permite garantizar el orden de los eventos externos del sistema. El diagrama de transicin de estados comienza cuando el cliente, ya conectado al sistema, est visualizando un escenario vaco debido a que no ha seleccionado an ningn producto. En el momento en que aade el primer producto a la escena pasa al estado "Escena no vaca", en la que se estar visualizando el producto seleccionado. Una vez que lo ha visualizado, puede realizar varias cosas: ? Si le gusta cmo est, lo enva directamente a la cesta de la compra para formar parte del pedido final. En este caso pasar al estado "Colocando Objeto en Cesta". ? Si lo que quiere es quitarlo de la escena porque ha decidido que no quiere visualizarlo, pasa al estado "Borrando Objeto 3D".

? Si lo que desea es realizar algn tipo de manipulacin sobre un objeto de la escena, primeramente tendr que seleccionar dicho objeto o producto de la escena. Para ello pasa al estado "Objeto 31) seleccionado", desde este estado tiene la posibilidad, segn dice el enunciado, de: ? Cambiarlo de color o de textura, en cuyo caso pasar al estado "Cambiando color / textura". ? Cambiarlo de tamao, posicin o rotarlo, en cuyo caso pasar al estado "Objeto 31) manipulado", en el que tendr la posibilidad de hacerle todos los cambios que desee al producto, hasta que ste se encuentre a su gusto, momento tras el cual podr bien borrarlo de la escena porque finalmente no le agrade dicho producto o mandarlo a la cesta de la compra, para que forme parte del pedido final, manteniendo las caractersticas establecidas sobre el producto al haberlo manipulado.

Figura 8.4: Diagarama de Transicin de Manipular y Seleccionar Producto