Caso práctico 1: Sistema de gestión de agendas y reuniones 1 Enunciado
La práctica consiste en analizar y diseñar con UML una aplicación web para gestionar agendas personales, gestionar grupos de usuarios y organizar reuniones entre personas adscritas al sistema. Los usuarios del sistema se pueden asociar a grupos de trabajo que se definieran en el sistema, pero esto lo hace el administrador de grupos. Cualquier usuario se puede convertir en administrador de grupos, y este puede crear un grupo y se encarga de su gestión (alta (al ta y baja de usuarios en el grupo y eliminación del grupo). Un usuario puede pertenecer a varios grupos. Cada usuario tiene acceso a una agenda personal. La agenda consta de un calendario, un directorio de contactos, una lista de tareas y una lista de notas. El calendario permite ver por días, semanas, meses o años las entradas que se hubieran creado en el mismo. Estas entradas pueden ser creadas por el usuario o por el administrador de reuniones. Cada entrada tiene un título, una fecha (día y hora) y comentarios. Las entradas pueden ser públicas (cualquier otro usuario puede verlas), de grupo (sólo visibles por los usuarios de uno o más grupos al que pertenece el usuario) o privadas (sólo el usuario). El calendario también ofrece la posibilidad de sacar una lista de todas las entradas, con varias opciones, por ejemplo, entre dos fechas, a partir de una fecha, las relacionadas con un grupo, etc. El directorio de contactos es una lista de personas con sus datos de contacto (nombre, alias, dirección, teléfonos, email, etc.) y notas adicionales. Se podrá crear, consultar, buscar, modificar o borrar elementos de este directorio. En la lista de tareas, cada una consta de una fecha de terminación (o sin fecha de terminación), un título, un texto descriptivo, una prioridad, y una categoría (para clasificarlas en grupos de tareas). También tienen un
1
Adaptado de Juan Pavón. Basado en la práctica del Curso 2008/09 11
indicador de hasta qué punto se ha cumplido (porcentaje, cuando llega a 100 es que se ha completado). Se podrá crear, consultar (de varias maneras, por nombre, grupo de tareas, estado y fecha de terminación), modificar o borrar elementos de esta lista. La fecha de terminación se verá reflejada en el calendario. En la lista de notas, cada nota consta de un título y un texto. Pueden estar asociadas a una categoría. Se podrá crear, consultar, buscar, modificar o borrar notas. En la agenda se podrán crear, modificar o borrar nombres de categorías. En los campos de texto se pueden poner enlaces a otras entradas de la agenda (por ejemplo, en una nota, un enlace a un contacto, o en una entrada del calendario un enlace a una tarea). El sistema de gestión de reuniones es un sistema auxiliar y externo al sistema, que permite a los usuarios de un grupo concertar reuniones buscando el momento más propicio. Cada reunión tendrá un título y una descripción de los objetivos y la agenda de la reunión, así como un lugar, fecha y duración. Para decidir la fecha el usuario que propone la reunión indicará un rango de fechas y el sistema proporcionará una lista de las más convenientes para todos según sus agendas. El promotor de la reunión podrá elegir una fecha entre éstas és tas o pedir al sistema que permita votar (en un tiempo límite) a los invitados a la reunión por una fecha, en cuyo caso se elegirá la fecha más votada. Cada invitado recibirá la solicitud de voto cuando se conecte al sistema. La fecha de la reunión final se apuntará en la agenda de todos los usuarios invitados a la reunión.
Se pide modelar el caso con la herramienta Bouml 4.9.1, con los siguientes requisitos:
Diagramas de casos de uso Deben estar diseñados de la siguiente manera: a. Nomenclatura correcta de los casos de uso: con verbos adecuados al contexto. b. Nomenclatura y extracción correcta de los actores: con sustantivos adecuados al contexto. c. Los casos de uso deben cubrir todas las funciones del enunciado (si bien esto se verá con más detalle en las especificaciones).
12
d.
Las relaciones entre casos de uso deben ser las correctas según el enunciado. e. Correcta estructuración en paquetes. f. No poner casos de uso en los que solo haya que que apretar un botón por ejemplo (deben recoger la suficiente funcionalidad como para que formen un caso de uso; si bien esto se verá con más detalle en las especificaciones).
Especificaciones de casos de uso La especificación deberá ser rellenada en el apartado !description", y debe contener todos los apartados de la plantilla. Se evaluará: a. Que todos los casos de uso tengan una especificación de caso de uso ligada a él. b. Que esta especificación conste de todos los apartados. c. Que exista coherencia entre el diagrama de casos de uso y las especificaciones (que los actores y nombre del caso de uso coincidan con los del diagrama de casos de uso). d. Que el objetivo de un caso de uso esté recogido en el enunciado ó al menos sirva para hacer algo del enunciado. e. Que las precondiciones, postcondiciones, y secuencia normal, sean coherentes para la realización del objetivo. La secuencia normal debe reflejar el diálogo entre un usuario y la interfaz del sistema. f. Debe haber al menos un flujo alternativo por cada caso, que debe corresponderse a la secuencia de acciones cuando el usuario pulsa !cancelar". Se valorarán positivamente otros flujos alternativos, siempre que sean coherentes con el caso de uso que se implementa. g. Los casos de uso que se vean extendidos por otros (relación !extends") o que incluyan otros (relación !include") deben de reflejar este hecho en su especificación, en concreto en el paso del flujo de secuencia normal ó alternativa en el que participen.
Diagrama de clases (diseño previo) El diagrama de clases se va a realizar en dos fases: diseño previo y diseño detallado. Aunque solo se debe modelizar el diseño detallado, conviene realizarlo en estos dos pasos, para seguir el proceso unificado. En el diseño previo se debe realizar lo siguiente: a. Extracción de clases: el enunciado da una idea aproximada de cuáles van a ser las clases, examinando conceptos que figuran 13
b.
como sustantivos y que forman parte de la información que va a manejar el sistema. También se pueden extraer de las especificaciones de los casos de uso. Sin embargo, no todos los sustantivos van a ser clases: pueden ser atributos. Se entiende que una clase es un conjunto de atributos y/o métodos que caracterizan a un conjunto de objetos. Extracción de relaciones entre clases y determinación de su tipo: el enunciado también da una idea aproximada de cuáles van a ser las relaciones entre clases y cómo van a ser: 1. Ejemplos de asociación: i. Un usuario se puede asociar a grupos ! ii. A crea B ! iii. Atributo a de clase A también se refleja en el atributo b de clase B! 2. Ejemplos de generalización: i. A es un subtipo de B ii. A puede ser de varios tipos: B ! 3. Ejemplos de agregación: i. A consta de B y C ii. A y B son partes de C iii. A se compone de B y C
Diagrama de clases (diseño detallado) Este diagrama si se debe modelar. En el diseño detallado se debe realizar lo siguiente: a. En las clases: 1. Insertar atributos: si se conoce su tipo, dar su tipo. 2. Insertar métodos: si se conocen los parámetros y el tipo que devuelven, darlos. Ambos se pueden extraer del enunciado, pero los métodos también se refinarán en los diagramas de secuencia, apareciendo nuevos ó desapareciendo otros que no se usan. b. En las relaciones entre clases: se puede extraer del enunciado. 1. Dar nombres a las asociaciones; en su defecto dar nombre a los roles de los extremos. 2. Dar multiplicidad a los extremos de las asociaciones y de las agregaciones. Por defecto es 1. Ambos se pueden extraer del enunciado.
14
Se deben crear dos sub vistas de casos de uso dentro de la vista de casos de uso a la cual se quieren añadir los diagramas de secuencia. Una de las dos sub vistas contendrá los diagramas de secuencia previos; la otra los diagramas de secuencia detallados. Este es un ejemplo de cómo quedaría el navegador del Bouml, para la parte de Tarea y un único caso de uso (se la considera como si no hubiera mas cosas):
Figura 1. Captura de pantalla de un árbol conteniendo las vistas en Bouml
Por otra parte, se observa en el árbol que el diagrama de clases ha quedado al mismo nivel que los casos de uso, en una vista de clases llamada Vista de clases.
Diagrama de secuencia (diseño previo) Una vez situados en la sub vista de casos de uso Diagramas de secuencia previos de la carpeta concreta, hay que realizar tantos diagramas de secuencia previos como escenarios haya para cada caso de uso de esa carpeta. 15
Cada diagrama de secuencia es la realización de un escenario de caso de uso. Para ello debe existir una especificación de caso de uso. Siguiendo el ejemplo de la Tarea, se tiene la especificación de CrearTarea: Caso de uso 1 Nombre: CrearTarea Objetivo: Mediante este caso de uso se pretende crear una tarea con sus campos y que su fecha de terminación se refleje en el calendario. Precondiciones entradas: haber sido seleccionada.
La
opción
CrearTarea
debe
Postcondiciones salida: Condición final exitoso: Tarea y su calendario creadas. Mensaje "Tarea Calendario creados"
entrada en y entrada
el de
Condición final fallido: No se crean ni la tarea ni la entrada. Mensaje "Tarea y entrada calendario no creadas" Actor primario: Usuario Actores secundarios: No hay Secuencia normal: 1. El usuario introduce fecha terminación, titulo, texto, prioridad, categoria, indicador. 2. El sistema crea una entrada de calendario y se envía el mensaje "Calendario creado". 3. El sistema crea una tarea y le envia mensaje "Tarea y entrada de calendario creados" Flujo alternativo a: 1a. El usuario pulsa cancelar 2a. El sistema da el mensaje calendario no creadas"
"Tarea
y
entrada
En la especificación existen dos escenarios: una correspondiente a la secuencia normal y el otro al flujo alternativo a, luego en la sub vista de Diagramas de secuencia previos deben existir 2 diagramas de secuencia previos cuyos nombres cuyos nombres son Crear Tarea, Crear Tarea a. Se debe realizar lo mismo para el resto de casos de uso, y los nombres de los diagramas de secuencia deben ser los mismos que los del caso de uso y una letra opcional que indica el flujo alternativo al que se refiere. 16
La realización de cada diagrama de secuencia previo consiste en poner en la parte de arriba del diagrama todos los actores que intervienen en el caso de uso y una clase genérica que se llame Sistema. Cada paso del escenario del caso de uso debe reflejarse con un envío de mensaje desde la parte que lo genera (actor o sistema) hacia el receptor (actor o sistema). El nombre del mensaje debe reflejar la acción que se realiza ó bien el valor devuelto por una acción previa. Aquí están los dos diagramas de secuencia correspondientes a la especificación del caso de uso anterior:
Figura 2. Diagrama de secuencia previo para la secuencia normal del caso de uso CrearTarea
17
Figura 3. Diagrama de secuencia previo para el flujo alternativo del caso de uso CrearTarea.
Diagrama de secuencia (diseño detallado) Los diagramas de secuencia detallados se generan a partir de los diagramas de secuencia previos y de los diagramas de clases, por lo tanto deben existir tantos diagramas de secuencia detallados como previos y se deben de nombrar casi igual (el Bouml no permite duplicar nombres, así que hay cambiar el nombre del diagrama con un espacio entre nombres o un guion). Para realizar un diagrama de secuencia detallado, en vez de tener la clase Sistema, se van a tener clases del diagrama de clases. Hay que desdoblar cada mensaje del diagrama previo en uno o varios mensajes a las clases involucradas. En realidad los mensajes van a estar etiquetados con funciones de la clase que lo recibe, y por tanto no son más que llamadas a dichas funciones. La etiqueta también debe contener los argumentos de las llamadas a las funciones. Aquí se muestran los diagramas detallados correspondientes a los diagramas anteriores:
18
Figura 4. Diagrama de secuencia detallado para la secuencia normal del caso de uso CrearTarea
19
Figura 5. Diagrama de secuencia detallado para el flujo alternativo del caso de uso CrearTarea
Una heurística para saber a qué clase se le debe dirigir el mensaje es saber qué clase contiene el método al que quieres llamar.
Refinamiento del diagrama de casos de uso y especificaciones de casos de uso La creación de los diagramas de secuencia detallados provoca un refinamiento del diagrama de casos de uso (que los alumnos deben realizar) que consiste en que deben existir los mismos actores (ni más, ni menos) en los diagramas de secuencia y en los diagramas de casos de uso. Si no es así hay que corregirlo (normalmente en los diagramas de casos de uso y sus especificaciones).
20
Refinamiento del diagrama de clases La creación de los diagramas de secuencia detallados provoca un refinamiento del diagrama de clases (que los alumnos deben realizar) a 3 niveles: a. Deben existir las mismas clases en los diagramas de secuencia y en el diagrama de clases (ni más ni menos). Si hay alguna que falta en el d. de clases hay que crearla; si sobra, borrarla. b. Deben existir las mismas operaciones en los diagramas de secuencia y en el diagrama de clases (ni más ni menos). Si hay alguna que falta en el d. de clases hay que crearla; si sobra, borrarla. c. Las llamadas a métodos entre clases provoca que exista una relación entre clases que tal vez no se haya descubierto cuando se creó el diagrama de clases. Si sucede, esto, pensar si hay que crearla (Si se puede navegar a través de las relaciones existentes de una clase a otra no hace falta crearla; si no se puede, hay que crearla).
21
Solución
Diagramas de casos de uso Se adjuntan los diagramas de casos de uso refinados. Diagramas de grupos de usuarios
Figura 6. Diagrama de casos de uso de grupos de usuarios
22
Diagramas de agenda
Figura 7. Diagrama de casos de uso del directorio de contactos
23
Figura 8. Diagrama de casos de uso de categoria
Figura 9. Diagrama de casos de uso de notas
24
Figura 10. Diagrama de casos de uso de calendario
25
Figura 11. Diagrama de casos de uso de tareas
Diagramas de Reuniones de usuarios
Figura 12. Casos de uso d e reuniones
26
Relaciones entre actores
Figura 13. Diagrama de relaciones entre actores (dentro de los casos de uso)
Especificaciones de casos de uso Por considerarlas como las más complejas, se han desarrollado especificaciones de los siguientes caso de uso; el resto son parecidas la especificación del enunciado: a. ConcertarReunión b. ConcertarReuniónArbitraria c. ConcertarReuniónVotación Especificación del caso de uso ConcertarReunion Caso de uso 2 Nombre: ConcertarReunion Objetivo: Mediante este caso de uso se decide fecha de reunion. Precondiciones entradas: La opción ConcertarREunion ha sido seleccionada. Postcondiciones salida: Se ha creado una reunion; se ha apuntado en la agenda de los invitados. 27
Condición final exitoso: Se ha creado una reunion; se ha apuntado en la agenda de los invitados. Mensaje "Reunion creada". Mensaje "Apuntada en agenda". Condición final fallido: No se crean ni la reunion ni se apunta en la agenda. Mensaje "Reunion no creada y no apuntada en agenda" Actor primario: Usuario Actores secundarios: Sistema de gestion de reuniones Secuencia normal: Este caso de uso sigue la secuencia de los casos de uso que lo realizan: DecidirReunionArbitraria DecidirReunionVotacion
Especificación del caso de uso ConcertarReunionArbitraria Caso de uso 3 Nombre: ConcertarReunionArbitraria Objetivo: Mediante este caso de uso se concierta una reunion con fecha elegida por el promotor. Precondiciones entradas: La opción ConcertarREunionArbitraria ha sido seleccionada. Postcondiciones salida: Condición final exitoso: Se ha creado una reunion; se ha apuntado en la agenda de los invitados. Mensaje "Reunion creada". Mensaje "Apuntada en agenda". Condición final fallido: No se crean ni la reunion ni se apunta en la agenda. Mensaje "Reunion no creada y no apuntada en agenda" Actor primario: AdministradorReunion Actores secundarios: SistemaGestionReuniones, Invitado Secuencia normal: 1. El AdministradorReunion pide fechas de la reunion al SistemaGestionReunion. 2. El SistemaGestionReunion le muestra al AdministradorReunion una lista de fechas segun agendas de usuarios grupo. 3. El AdministradorReunion selecciona una fecha. 28
4. El AdministradorReunion proporciona el resto de datos: titulo, descripcion, objetivos, lugar y duracion. 5. El SistemaGestionReunion actualiza la informacion en las agendas de los invitados a la reunión. 6. El SistemaGestionReunion da el mensaje "Reunion creada" tanto al Administrador de la reunion como a los invitados. Flujo alternativo a: 1a. El AdministradorReunion pulsa Cancelar 2a. El SistemaGestionReunion da el mensaje "Reunion no creada y no apuntada en agenda" Flujo alternativo b: 3b. El AdministradorReunion pulsa Cancelar 4b. "Reunion no creada y no apuntada en agenda" Flujo alternativo c: 4c. El AdministradorReunion pulsa Cancelar 5c. "Reunion no creada y no apuntada en agenda"
2.3.3 Use Case ConcertarReunionVotacion Caso de uso 4 Nombre: ConcertarReunionVotación Objetivo: Mediante este caso de uso se concierta una reunion con fecha elegida por votación. Precondiciones entradas: La opción ConcertarREunionVotación ha sido seleccionada. Postcondiciones salida: Condición final exitoso: Se ha creado una reunion; se ha apuntado en la agenda de los invitados. Mensaje "Reunion creada". Mensaje "Apuntada en agenda".
Condición final fallido: No se crean ni la reunion ni se apunta en la agenda. Mensaje "Reunion no creada y no apuntada en agenda" Actor primario: AdministradorReunion
29
Actores secundarios: SistemaGestionReuniones, Invitado Secuencia normal: 1. El AdministradorReunion pide fechas de la reunion al SistemaGestionReunion. 2. El SistemaGestionReunion le muestra al AdministradorReunion una lista de fechas segun agendas de usuarios grupo. 3. El AdministradorReunion pide que al SistemaGestionReunion que se haga una votación de las fechas. 4. El SistemaGestionReunion pide a los Invitados que voten. 5. Los invitados votan la fecha. 6. El SistemaGestionReunion muestra la fecha final al Administrador. 7. El AdministradorReunion proporciona el resto de datos: titulo, descripcion, objetivos, lugar y duracion. 8. El SistemaGestionReunion actualiza la informacion en las agendas de los invitados a la reunión. 9. El SistemaGestionReunion da el mensaje "Reunion creada" a los invitados y a l administrador de la reunión.
Flujo alternativo a: 1a. El AdministradorReunion pulsa Cancelar 2a. El SistemaGestionReunion da el mensaje "Reunion no creada y no apuntada en agenda" Flujo alternativo b: 3b. El AdministradorReunion pulsa Cancelar 4b. "Reunion no creada y no apuntada en agenda" Flujo alternativo c: 7c. El AdministradorReunion pulsa Cancelar 8c. "Reunion no creada y no apuntada en agenda"
30
Diagrama de clases (previo y detallado) Dada la cantidad de diagramas previos posibles, solo se recoge el definitivo, que es el diagrama detallado. No obstante, se debe tener en cuenta que para llegar a este diagrama detallado, se han debido dar todos los pasos previos de casos de uso y especificaciones de casos de uso.
Figura 14. Diagrama de clases previo y detallado
31
Re-estructuración del árbol
Figura 15. Organización de vistas y subvistas en paquetes
Diagramas de secuencia previos Se van a exponer los diagramas de secuencia de los casos de uso para los cuales existe especificación: CrearTarea, ConcertarReuniónArbitraria, ConcertarReuniónVotación:
32
Figura 16. Diagrama de secuencia previo del caso de uso CrearTarea (secuencia normal)
Figura 17. Diagrama de secuencia previo del caso de uso CrearTarea (flujo alternativo)
33
Figura 18. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (secuencia normal)
34
Figura 19. Diagrama de secuencia previo del caso del uso ConcertarReunion Arbitraria (flujo alternativo a)
Figura 20. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (flujo alternativo b)
35
Figura 21. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (secuencia normal)
Figura 22. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo a)
36
Figura 23. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo b)
37
Figura 24. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo c)
38
Diagramas de secuencia detallados Se han incluido los diagramas de secuencia detallados para los que existen diagramas de secuencia previos.
Figura 25. Diagrama de secuencia detallado del caso de uso CrearTarea (secuencia normal)
Figura 26. Diagrama de secuencia detallado para el caso de uso CrearTarea (flujo alternativo a)
39
Figura 27. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (secuencia normal)
Figura 28. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (flujo alternativo a)
40
Figura 29. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (flujo alternativo b)
Figura 30. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (secuencia normal)
41
Figura 31. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo a)
Figura 32. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo b)
42
Figura 33. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo c)
43
