Caso prctico 1: Sistema de gestin

de agendas y reuniones1
Enunciado

La prctica consiste en analizar y disear con UML una aplicacin 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 gestin (alta y baja de usuarios en
el grupo y eliminacin 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 das, semanas, meses o aos 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 ttulo,
una fecha (da y hora) y comentarios. Las entradas pueden ser pblicas
(cualquier otro usuario puede verlas), de grupo (slo visibles por los
usuarios de uno o ms grupos al que pertenece el usuario) o privadas (slo
el usuario). El calendario tambin 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, direccin, telfonos, 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 terminacin (o sin
fecha de terminacin), un ttulo, un texto descriptivo, una prioridad, y una
categora (para clasificarlas en grupos de tareas). Tambin tienen un

1
Adaptado de Juan Pavn. Basado en la prctica 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 terminacin),
modificar o borrar elementos de esta lista. La fecha de terminacin se ver
reflejada en el calendario.
En la lista de notas, cada nota consta de un ttulo y un texto. Pueden estar
asociadas a una categora. Se podr crear, consultar, buscar, modificar o
borrar notas.
En la agenda se podrn crear, modificar o borrar nombres de categoras.
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 gestin de reuniones es un sistema auxiliar y externo al
sistema, que permite a los usuarios de un grupo concertar reuniones
buscando el momento ms propicio. Cada reunin tendr un ttulo y una
descripcin de los objetivos y la agenda de la reunin, as como un lugar,
fecha y duracin. Para decidir la fecha el usuario que propone la reunin
indicar un rango de fechas y el sistema proporcionar una lista de las ms
convenientes para todos segn sus agendas. El promotor de la reunin
podr elegir una fecha entre stas o pedir al sistema que permita votar (en
un tiempo lmite) a los invitados a la reunin por una fecha, en cuyo caso
se elegir la fecha ms votada. Cada invitado recibir la solicitud de voto
cuando se conecte al sistema. La fecha de la reunin final se apuntar en la
agenda de todos los usuarios invitados a la reunin.

Se pide modelar el caso con la herramienta Bouml 4.9.1, con los siguientes
requisitos:
Diagramas de casos de uso

Deben estar diseados de la siguiente manera:

a. Nomenclatura correcta de los casos de uso: con verbos adecuados
al contexto.
b. Nomenclatura y extraccin 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 ms detalle en las especificaciones).

      12

 d. Las relaciones entre casos de uso deben ser las correctas segn el
enunciado.
e. Correcta estructuracin en paquetes.
f. No poner casos de uso en los que solo haya que apretar un botn
por ejemplo (deben recoger la suficiente funcionalidad como para
que formen un caso de uso; si bien esto se ver con ms detalle en
las especificaciones).
Especificaciones de casos de uso

La especificacin 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 especificacin de caso de
uso ligada a l.
b. Que esta especificacin 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 realizacin del objetivo. La secuencia normal
debe reflejar el dilogo 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 valorarn 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 (relacin
extends) o que incluyan otros (relacin include) deben de
reflejar este hecho en su especificacin, en concreto en el paso del
flujo de secuencia normal alternativa en el que participen.
Diagrama de clases (diseo previo)

El diagrama de clases se va a realizar en dos fases: diseo previo y diseo

detallado. Aunque solo se debe modelizar el diseo detallado, conviene
realizarlo en estos dos pasos, para seguir el proceso unificado.
En el diseo previo se debe realizar lo siguiente:
a. Extraccin de clases: el enunciado da una idea aproximada de
cules van a ser las clases, examinando conceptos que figuran

 !"#$ %& '() 13

 como sustantivos y que forman parte de la informacin que va a
manejar el sistema. Tambin 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 mtodos que caracterizan
a un conjunto de objetos.
b. Extraccin de relaciones entre clases y determinacin de su tipo: el
enunciado tambin da una idea aproximada de cules van a ser las
relaciones entre clases y cmo van a ser:
1. Ejemplos de asociacin:
i. Un usuario se puede asociar a grupos
ii. A crea B
iii. Atributo a de clase A tambin se refleja en el
atributo b de clase B
2. Ejemplos de generalizacin:
i. A es un subtipo de B
ii. A puede ser de varios tipos: B
3. Ejemplos de agregacin:
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 (diseo detallado)

Este diagrama si se debe modelar.

En el diseo detallado se debe realizar lo siguiente:
a. En las clases:
1. Insertar atributos: si se conoce su tipo, dar su tipo.
2. Insertar mtodos: si se conocen los parmetros y el tipo que
devuelven, darlos.
Ambos se pueden extraer del enunciado, pero los mtodos tambin
se refinarn 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.

*+,-, ./0*12*-, 34 567 14

FGHGIJKLMJLKNMOPQ RGS TKUVS

Se deben crear dos sub vistas de casos de uso dentro de la vista de casos de
uso a la cual se quieren aadir 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 cmo quedara 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 (diseo 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.

89:;: <=>8?@8;: AB CDE 15

Cada diagrama de secuencia es la realizacin de un escenario de caso de
uso. Para ello debe existir una especificacin de caso de uso. Siguiendo el
ejemplo de la Tarea, se tiene la especificacin 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 terminacin
se refleje en el calendario.
Precondiciones entradas: La opcin CrearTarea debe
haber sido seleccionada.
Postcondiciones salida:
Condicin final exitoso: Tarea y su entrada en el
calendario creadas. Mensaje "Tarea y entrada de
Calendario creados"
Condicin 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 terminacin, titulo,
texto, prioridad, categoria, indicador.
2. El sistema crea una entrada de calendario y se enva
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 "Tarea y entrada
calendario no creadas"
En la especificacin 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.

WXYZY [\]W^_WZY `a bcd 16

La realizacin 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 genrica que se llame Sistema. Cada paso del escenario
del caso de uso debe reflejarse con un envo de mensaje desde la parte que
lo genera (actor o sistema) hacia el receptor (actor o sistema). El nombre
del mensaje debe reflejar la accin que se realiza bien el valor devuelto
por una accin previa.
Aqu estn los dos diagramas de secuencia correspondientes a la
especificacin del caso de uso anterior:

Figura 2. Diagrama de secuencia previo para la secuencia normal del caso de uso CrearTarea

efghg ijkelmehg no pqr 17

 Figura 3. Diagrama de secuencia previo para el flujo alternativo del caso de uso CrearTarea.

Diagrama de secuencia (diseo 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 ms que llamadas a
dichas funciones. La etiqueta tambin debe contener los argumentos de las
llamadas a las funciones. Aqu se muestran los diagramas detallados
correspondientes a los diagramas anteriores:

stuvu wxysz{svu |} ~ 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 heurstica para saber a qu clase se le debe dirigir el mensaje es saber

qu clase contiene el mtodo al que quieres llamar.

Refinamiento del diagrama de casos de uso y

especificaciones de casos de uso

La creacin 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 ms, 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 creacin 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 ms 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 ms ni menos). Si hay
alguna que falta en el d. de clases hay que crearla; si sobra,
borrarla.
c. Las llamadas a mtodos entre clases provoca que exista una
relacin 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 travs de las relaciones existentes de
una clase a otra no hace falta crearla; si no se puede, hay que
crearla).

21
Solucin

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 de 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 ms complejas, se han desarrollado

especificaciones de los siguientes caso de uso; el resto son parecidas la
especificacin del enunciado:
a. ConcertarReunin
b. ConcertarReuninArbitraria
c. ConcertarReuninVotacin
Especificacin 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 opcin ConcertarREunion ha
sido seleccionada.
Postcondiciones salida: Se ha creado una reunion; se
ha apuntado en la agenda de los invitados.

27
Condicin final exitoso: Se ha creado una reunion; se
ha apuntado en la agenda de los invitados. Mensaje
"Reunion creada". Mensaje "Apuntada en agenda".
Condicin 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
Especificacin 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 opcin
ConcertarREunionArbitraria ha sido seleccionada.
Postcondiciones salida:
Condicin final exitoso: Se ha creado una reunion; se
ha apuntado en la agenda de los invitados. Mensaje
"Reunion creada". Mensaje "Apuntada en agenda".
Condicin 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 reunin.
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: ConcertarReunionVotacin

Objetivo: Mediante este caso de uso se concierta una

reunion con fecha elegida por votacin.

Precondiciones entradas: La opcin

ConcertarREunionVotacin ha sido seleccionada.

Postcondiciones salida:

Condicin final exitoso: Se ha creado una reunion; se

ha apuntado en la agenda de los invitados. Mensaje
"Reunion creada". Mensaje "Apuntada en agenda".

Condicin 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 votacin 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 reunin.
9. El SistemaGestionReunion da el mensaje "Reunion
creada" a los invitados y a l administrador de la
reunin.

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

)*+,+ -./)01),+ 23 456 31

Re-estructuracin del rbol

Figura 15. Organizacin 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 especificacin: CrearTarea, ConcertarReuninArbitraria,
ConcertarReuninVotacin:

789:9 ;<=7>?7:9 @A BCD 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)

EFGHG IJKELMEHG NO PQR 33



Figura 18. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria

(secuencia normal)

STUVU WXYSZ[SVU \] ^_` 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)

abcdc efgahiadc jk lmn 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)

opqrq stuovworq xy z{| 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
 44