Vous êtes sur la page 1sur 96

Pgina 1

UML (Unified Modelling Language) es el Lenguaje Unificado de Modelado que se usa


tanto para anlisis como para diseo de la funcionalidad de un sistema de informacin, segn los paradigmas de la Ingeniera del Software. Este libro trata de acercar a
los usuarios de la Ingeniera de Software (profesionales, alumnos, profesores) ejemplos resueltos extrados de casos de la vida real, y as poder extrapolar la metodologa
de resolucin a sus propios casos prcticos. Como herramienta, se ha usado una de
las ms conocidas, Rational Rose Enterprise Edition. En consecuencia, este libro cubre
una brecha en la edicin de libros de Ingeniera de Software en general, y UML en particular, en los cuales predominan la exposicin de fundamentos tericos y casos
prcticos poco sencillos o cercanos al mundo real.

Casos prcticos
de UML
Extensin

9:35

Celia Gutirrez Coso

14/07/2011

Casos prcticos de UML

cubierta_dina4.qxp

Celia Gutirrez Coso

Casos prcticos de UML


CELIA GUTIRREZ COSO

Todos los derechos reservados. Cualquier forma de reproduccin, distribucin,


comunicacin pblica o transformacin de esta obra slo puede ser realizada
con la autorizacin expresa de sus titulares, salvo excepcin prevista por la ley.
Todos los libros publicados por Editorial Complutense a partir de
enero de 2007 han superado el proceso de evaluacin experta.
2011 by Celia Gutirrez Coso
2011 by Editorial Complutense, S. A.
Donoso Corts, 63 - 4. planta. 28015 Madrid
Tels.: 91 394 64 61/0. Fax: 91 394 64 58
ecsa@rect.ucm.es
www.editorialcomplutense.com
Primera edicin:
Septiembre de 2011

ISBN eBook: 978-84-9938-100-8


Esta editorial es miembro de la UNE, lo que garantiza la difusin y comercializacin de sus
publicaciones a nivel nacional e internacional.

Prlogo

El UML es el Lenguaje Unificado de Modelado que se usa tanto para anlisis


como para diseo de la funcionalidad de un sistema de informacin, segn los
paradigmas de la Ingeniera del Software. Se basa en la creacin de varios diagramas que representan varios puntos de vista distintos pero complementarios
de un sistema. Con esta publicacin no se pretende responder a cuestiones tericas, dado que este aspecto ya est muy desarrollado en la bibliografa, sino proporcionar varios casos prcticos y su solucin.
El siguiente libro recopila la parte prctica realizada en la asignatura
Ingeniera de Software de Gestin II durante los cursos 2008/09 y 2009/10.
Consta de ejercicios resueltos que han formado parte de las prcticas y ejemplos
de clase, as como de ejercicios planteados en exmenes.
Consta de 5 casos prcticos: el primero es el ncleo del libro, ya que resuelve
un caso prctico completo, aportando guas para solucionarlo segn el Proceso
Unificado; los cuatro siguientes plantean la resolucin de las partes ms importantes del problema, normalmente diagramas de casos de uso y de clases.
Por ltimo, se incluye un apndice con un manual de uso de una de las herramientas usadas para la creacin de los diagramas: Rational Rose Enterprise
Edition 2003.

ndice
Caso prctico 1: Sistema de gestin de agendas y reuniones
Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Especificaciones de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . 13
Diagrama de clases (diseo previo) . . . . . . . . . . . . . . . . . . . . . 13
Diagrama de clases (diseo detallado) . . . . . . . . . . . . . . . . . . . 14
Re-estructuracin del rbol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Diagrama de secuencia (diseo previo) . . . . . . . . . . . . . . . . . . 15
Diagrama de secuencia (diseo detallado) . . . . . . . . . . . . . . . . 18
Refinamiento del diagrama de casos de uso y
especificaciones de casos de uso . . . . . . . . . . . . . . . . . . . . . 20
Refinamiento del diagrama de clases . . . . . . . . . . . . . . . . . . . . 21
Solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Diagramas de agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Especificaciones de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 27
Diagrama de clases (previo y detallado) . . . . . . . . . . . . . . . . . . 31
Re-estructuracin del rbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Diagramas de secuencia previos . . . . . . . . . . . . . . . . . . . . . . . . 32
Diagramas de secuencia detallados . . . . . . . . . . . . . . . . . . . . . . 39
Caso Prctico 2: Editor de Documentos Parole
Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Caso prctico 3: Sistema Operativo Maxix
Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencia detallado. . . . . . . . . . . . . . . . . . . . . . . .

53
55
55
56
57

Caso prctico 4: Sistema de ecuaciones de grado n


Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clases y mtodos abstractos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencia previo . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencia detallado. . . . . . . . . . . . . . . . . . . . . . . .
Generacin de cdigo para la clase Ecuacion. . . . . . . . . . . . . .

61
63
64
65
65
66
67
68

Caso prctico 5: Quetzalix


Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Solucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Patrn Singleton. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Apndice: breve manual de uso del Rational Rose . . . . . . . . . . . .

71
73
74
75
76
78
79

CASO PRCTICO 1:
Sistema de gestin de agendas y reuniones

CASOS PRCTICOS DE UML

CASOS PRCTICOS DE UML

10

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

CASOS PRCTICOS DE UML

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

CASOS PRCTICOS DE UML

12

d.
e.
f.

Las relaciones entre casos de uso deben ser las correctas segn el
enunciado.
Correcta estructuracin en paquetes.
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
CASOS PRCTICOS DE UML

13

b.

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

CASOS PRCTICOS DE UML

14

Re-estructuracin del rbol


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.
CASOS PRCTICOS DE UML

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:
haber sido seleccionada.

La

opcin

CrearTarea

debe

Postcondiciones salida:
Condicin final exitoso: Tarea y su entrada en
calendario creadas. Mensaje "Tarea y entrada
Calendario creados"

el
de

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
calendario no creadas"

"Tarea

entrada

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.
CASOS PRCTICOS DE UML

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

CASOS PRCTICOS DE UML

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:

CASOS PRCTICOS DE UML

18

Figura 4. Diagrama de secuencia detallado para la secuencia normal del caso de uso CrearTarea

CASOS PRCTICOS DE UML

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

CASOS PRCTICOS DE UML

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

CASOS PRCTICOS DE UML

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

CASOS PRCTICOS DE UML

22

Diagramas de agenda

Figura 7. Diagrama de casos de uso del directorio de contactos

CASOS PRCTICOS DE UML

23

Figura 8. Diagrama de casos de uso de categoria

Figura 9. Diagrama de casos de uso de notas

CASOS PRCTICOS DE UML

24

Figura 10. Diagrama de casos de uso de calendario

CASOS PRCTICOS DE UML

25

Figura 11. Diagrama de casos de uso de tareas

Diagramas de Reuniones de usuarios

Figura 12. Casos de uso de reuniones

CASOS PRCTICOS DE UML

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.
CASOS PRCTICOS DE UML

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.
CASOS PRCTICOS DE UML

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
CASOS PRCTICOS DE UML

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"

CASOS PRCTICOS DE UML

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

CASOS PRCTICOS DE UML

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:

CASOS PRCTICOS DE UML

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)

CASOS PRCTICOS DE UML

33

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


(secuencia normal)

CASOS PRCTICOS DE UML

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)

CASOS PRCTICOS DE UML

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)

CASOS PRCTICOS DE UML

36

Figura 23. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion


(flujo alternativo b)

CASOS PRCTICOS DE UML

37

Figura 24. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion


(flujo alternativo c)

CASOS PRCTICOS DE UML

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)

CASOS PRCTICOS DE UML

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)

CASOS PRCTICOS DE UML

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)

CASOS PRCTICOS DE UML

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)

CASOS PRCTICOS DE UML

42

Figura 33. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion


(flujo alternativo c)

CASOS PRCTICOS DE UML

43

CASOS PRCTICOS DE UML

44

CASO PRCTICO 2:
Editor de Documentos Parole

CASOS PRCTICOS DE UML

45

CASOS PRCTICOS DE UML

46

Caso Prctico 2:
Editor de Documentos Parole2
Enunciado
Crear un diagrama de clases para representar la funcionalidad de un editor
de documentos llamado Parole que admita agrupamiento. El agrupamiento
es un concepto ampliamente utilizado por los editores de documentos.
Suponer que un documento consta de varias pginas (al menos una). Cada
pgina contiene objetos representables, que son textos, objetos grficos y
grupos (tal vez ninguna, es el caso de cuando se abre un nuevo
documento). Un grupo consta de, un conjunto de objetos representables, y
puede constar de otros grupos. Un grupo debe contener al menos dos
objetos representables, mientras que un objeto representable solo puede ser
parte de un grupo como mximo. (Tambin puede ser que no forme parte
de ningn grupo). Un grupo solo puede formar parte de otro grupo como
mximo. Los objetos representables deben existir siempre en el contexto
de una pgina; las pginas solo deben existir en el contexto de un
documento; adems, si existen elementos contenidos en un grupo y ste
desaparece, tambin desaparecen los elementos contenidos en l. Los
objetos grficos pueden ser curvilneos polgonos. Los curvilneos
pueden ser crculos elipses, y los polgonos pueden ser rectngulos,
tringulos y cuadrados.
Solucin
Segn el enunciado del problema, se pueden extraer las siguientes clases:
Documento

Pgina

Objeto representable

Texto

Objeto grfico

Ejercicio propuesto en el curso 2008/09

CASOS PRCTICOS DE UML

47

Grupo

Curvilneo

Polgono

Circulo

Elipse

Rectngulo

Tringulo

Cuadrado

Se pueden distinguir relaciones entre estas clases. El primer tipo es


relacin de composicin entre:
Documento y pgina

Pgina y objeto representable

Objeto representable y grupo

Grupo y grupo

Adems, refirindonos a la multiplicidad, que es:


Relacin de composicin entre documento y pgina: de 1 a 1..*
Relacin de composicin entre pgina y objeto representable: de 1
a 0..*

Relacin de composicin entre grupo y grupo: de 0..1, a 0..*.

Relacin de composicin entre grupo y objeto representable: de


0..1, a 2..*.

Finalmente hay que indicar unas relaciones de generalizacin, que son


evidentes segn el enunciado del problema:
Objeto grfico y curvilneo
Objeto grfico y polgono
CASOS PRCTICOS DE UML

48

Curvilneo y circulo

Curvilneo y elipse

Polgono y rectngulo

Polgono y tringulo

Polgono y cuadrado

El diagrama definitivo queda como sigue:

Figura 34. Diagrama de clases del editor Parole

CASOS PRCTICOS DE UML

49

CASOS PRCTICOS DE UML

50

CASO PRCTICO 3:
Sistema Operativo Maxix

CASOS PRCTICOS DE UML

51

CASOS PRCTICOS DE UML

52

Caso prctico 3:
Sistema Operativo Maxix3
Enunciado
Se plantea el desarrollo de una aplicacin para implementar el sistema
operativo Maxix programado en el lenguaje de programacin orientado
a objetos L:
Existe un sistema de archivos, que est asociado a una tabla de ficheros y a
una tabla de usuarios. La tabla de usuarios referencia a todos los usuarios y
la tabla de ficheros referencia a todos los ficheros. Debe al menos un
usuario referidos (el administrador) y 2 ficheros (la tabla de ficheros y la
tabla de usuarios). Los usuarios pueden ser propietarios de ficheros, pero
un fichero solo pertenece a un propietario. Se puede crear un usuario y
consultar sus datos, pero sto solo lo puede hacer el administrador del
sistema. Existen dos tipos de ficheros: el directorio, que se compone a su
vez de otros ficheros, y el fichero simple. El fichero simple a su vez puede
ser binario (por ejemplo, un ejecutable) o texto (es decir conteniendo
ASCII). Si se borra el directorio, tambin desaparecen los ficheros que
estn contenidos en l. Adems un directorio puede estar vaco. Cualquier
tipo de fichero se puede crear, borrar, consultar, y modificar; cualquier
usuario puede crear un fichero, pero es el usuario que crea el fichero quien
puede borrar, consultar o modificar el fichero.
Cuando un usuario crea un fichero nuevo se produce el siguiente efecto en
cascada: le proporciona el tipo, nombre y propietario al sistema de
archivos, que se encarga de obtener un identificador y una direccin de
comienzo al nuevo fichero; la tabla de ficheros se ve ampliada con una
nueva entrada con los datos del tipo, nombre, propietario, y las
recientemente creadas identificador y direccin de comienzo; y por ltimo
se crea un nuevo fichero del tipo indicado por el usuario, con el nombre
suministrado por el usuario y la direccin de comienzo. Si la creacin se
lleva a cabo correctamente, el usuario recibe la notificacin de Fichero
creado.
Para esta aplicacin se solicita:

Incluido en el examen ordinario del curso 2008/09

CASOS PRCTICOS DE UML

53

a. Un diagrama de casos de uso para representar toda la funcionalidad.


Identificar bien los actores.
b. Un diagrama de clases del dominio de la aplicacin que se han ido
describiendo en el enunciado. Es importante mostrar las relaciones
que hay entre las distintas clases, indicando multiplicidad en las
relaciones de asociacin y agregacin, e indicando el nombre de la
asociacin en las asociaciones. Se debe aplicar un patrn estructural
de los vistos en clase. No hay que indicar atributos ni mtodos en este
apartado.
c. Mostrar el esquema, participantes y colaboraciones de este sistema
operativo de ese patrn aplicado a la funcionalidad descrita. Indicar
los mtodos que deben figurar como mnimo en estas clases que
forman parte del patrn. Tambin es importante indicar qu clases y
mtodos abstractos existen.
d. Un diagrama de secuencia detallado que muestre cmo se crea un
fichero de tipo binario para el caso de que se cree correctamente,
indicando los mtodos que se invocan y los argumentos.

CASOS PRCTICOS DE UML

54

Solucin
Diagrama de casos de uso

Figura 35. Diagrama de casos de uso de Maxix

CASOS PRCTICOS DE UML

55

Diagrama de clases
Para adquirir un aspecto ms compacto, en este diagrama quedan
respondidas las cuestiones a y b.

Figura 36. Diagrama de clases de Maxix

CASOS PRCTICOS DE UML

56

Diagrama de secuencia detallado

Figura 37. Diagrama de secuencia detallado de Crear fichero (flujo alternativo binario)

CASOS PRCTICOS DE UML

57

CASOS PRCTICOS DE UML

58

CASO PRCTICO 4:
Sistema de ecuaciones de grado n

CASOS PRCTICOS DE UML

59

CASOS PRCTICOS DE UML

60

Caso prctico 4:
Sistema de ecuaciones de grado n4
Enunciado
Se plantea el desarrollo de una aplicacin que permita crear, resolver
ecuaciones de grado n por el matemtico, as como representarlas por el
informtico:
Una ecuacin de grado n est compuesta por n sumandos. Cada
sumando tiene la siguiente informacin:
-

Un signo, de tipo carcter

Numerador, que es un nmero entero

Denominador, que es un nmero entero

El grado, que es un nmero entero.

Los sumandos pueden existir independientemente de que una ecuacin


exista no, y pueden aparecer por tanto en muchas ecuaciones, e incluso
ninguna. A su vez, una ecuacin debe contener como mnimo un sumando
y como mximo n.
La informacin de una ecuacin es:
-

grado, que es un nmero entero.

soluciones, array de enteros

La ecuacin debe tener (como mnimo) las operaciones para crear y


resolver la ecuacin, y el sumando debe contener (como mnimo) la
operacin para crear el sumando.
Otra de las cosas que se hace es representar la ecuacin. Esto se puede
hacer de dos maneras, y lo hace el informtico:
-

Representar de manera compacta

Representar de manera extendida

Un ejemplo de ecuacin de grado 3 de manera extendida es:


4

Includo en el examen ordinario del curso 2009/10

CASOS PRCTICOS DE UML

61

3/1x3-22/3x2+5/1x1-9/7x0=0
Y de manera compacta:
3x3-22/3x2+5x-9/7=0
As una ecuacin se asocia a UNA representacin, que puede ser de tipo
compacto extendido. La informacin que guarda la representacin es
contenido, de tipo String, y debe tener como mnimo la operacin para
crear la representacin. Al crear una ecuacin, tambin se representa la
ecuacin.
Para crear la ecuacin de grado 1, se incluyen estos pasos en cascada:
El matemtico introduce el grado de la ecuacin para que se cree la
ecuacin inicializando el grado; el matemtico aade el sumando de grado
1 a la ecuacin (con los datos de ese sumando), quien llama a la creacin
de ese sumando inicializando sus datos; como respuesta a esa creacin el
sumando enva Sumando creado a la ecuacin. Este proceso se repite
para el sumando de grado 0. Al final, la ecuacin enva el mensaje
Ecuacin y sumandos creados al matemtico.
Por ltimo, el informtico aade a la ecuacin una nueva representacin
indicando su tipo (compacta extendida); y a partir de la ecuacin se
crea la representacin correspondiente; una vez creada la representacin se
devuelve el valor de su representacin a la ecuacin quien a su vez se la
devuelve al informtico.
Nota: esta secuencia de pasos no es una especificacin de caso de uso,
sino una lista de funciones que se debe hacer para la creacin completa
de una ecuacin; y que informtico y matemtico son independientes entre
s.
Para esta aplicacin se solicita:
a. Un diagrama de casos de uso para representar toda la funcionalidad.
Identificar bien los actores.
b. Un diagrama de clases del dominio de la aplicacin que se han ido
describiendo en el enunciado. Es importante mostrar las relaciones
que hay entre las distintas clases, indicando multiplicidad en las
relaciones de asociacin y agregacin, e indicando el nombre de la
asociacin en las asociaciones. Tambin deben existir los atributos
con sus tipos y mtodos necesarios para que se pueda cubrir toda la
funcionalidad descrita en el enunciado. Tambin se indica que debe
existir la clase Ecuacin.
CASOS PRCTICOS DE UML

62

c. Segn el enunciado deben existir algn(as) clase(s) abstractas con


algunos mtodo(s) abstractos. Indicar cules son.
d. Un diagrama de secuencia previo que muestre cmo se crea la
ecuacin de grado 1 en representacin compacta: 2x+1=0.
e. Un diagrama de secuencia detallado para crear dicha ecuacin,
indicando los mtodos que se invocan y los argumentos. Indica
cmo queda actualizado el diagrama de clases (si es que queda
actualizado con nuevos mtodos).
f. Qu contendra el cdigo de la clase Ecuacin en el aparatado de
atributos, al generar cdigo en un lenguaje de programacin
orientada a objetos como C++ o Java?. Se asume que se usa el
generador de cdigo del Rational Rose Enterprise Edition 2003
(usado en la asignatura).

Solucin
Los diagramas han sido diseados con Rational Rose Enterprise Edition
2003).

CASOS PRCTICOS DE UML

63

Diagrama de casos de uso

ResuelveEcuacion

Matematico
CreaEcuacion
<<include>>

RepresentaEcuacion

Informatico

RepresentaCompacta

RepresentaExtendida

Figura 38. Diagrama de casos de uso

En este diagrama es clave reflejar que la creacin de una ecuacin


incluye su representacin, como dice el enunciado Al crear una
ecuacin, tambin se representa la ecuacin.

CASOS PRCTICOS DE UML

64

Diagrama de clases

Ecuacion
grado : Integer
soluciones : Integer[]
crear()
resolver()

0..*

1..*

Sumando
signo : Character
numerador : Integer
denominador : Integer
grado : Integer
crear()

se_asocia

Representacion
contenido : String
crear()

RepresentacionCompacta

RepresentacionExtendida

crear()

crear()

Figura 39. Diagrama de clases

En la clase representacin, deben existir el atributo contenido y el mtodo


crear, como el propio enunciado dice: La informacin que guarda la
representacin es contenido, de tipo String, y debe tener como mnimo la
operacin para crear la representacin. Este mtodo crear(), tambin
podra haberse llamado representarecuacion(), ya que es lo que hace. Las
subclases de Representacin deben existir, ya que el enunciado dice que
puede ser de tipo compacto extendido. Estas clases NO PUEDEN
EXISTIR VACIAS, y siguiendo el enunciado tienen su propio mtodo
crear(), para adaptar la creacin representacin al tipo del que se trate.

Clases y mtodos abstractos


Clase abstracta: Representacin.
Mtodo abstracto: Crear.
Dado que la representacin solo puede ser compacta extendida, est
claro que no se van a crear otro tipo de representaciones, y por tanto, desde
CASOS PRCTICOS DE UML

65

Representacin no se va a instanciar ningn objeto, y ser una clase


abstracta. As mismo, el mtodo abstracto ser crear, ya que la funcin de
este es la de crear la representacin, y esto se debe hacer en los mtodos de
las subclases, segn el tipo de representacin de la cual se trate.

Diagrama de secuencia previo

: Informatico

: Sistema

: Matematico
Introducir grado 1
Introducir sumando grado 1

Introducir sumando grado 0

"Ecuacin y sumandos creados"

Solicita representacion compacta


"2x+1=0"

Figura 40. Diagrama de secuencia previo

En este diagrama hay que reflejar las interacciones entre los actores y el
sistema. Tambien sera vlido reflejar las interacciones sistema-sistema.

CASOS PRCTICOS DE UML

66

Diagrama de secuencia detallado

: Informatico

: Matematico
crear(1)

: Ecuacion

aadirSumando(+,1,2,1)
crear(+, 1,2,1)

: Sumando

"Sumando creado"

aadirSumando(+,0,1,1)

crear(+,1,1,1)

: Sumando

"Sumando creado"
"Ecuacion y sumandos creados"
aadirRepresentacion("compacta")
crear( )
"2x+1=0"

:
RepresentacionCompacta

"2x+1=0"

Figura 41. Diagrama de secuencia detallado

Un detalle importante es que en la creacin de los sumandos,


representacincompacta y ecuacin la colocacin de los objetos que se
crean debe estar a la altura de mensaje (es decir, mas abajo que en los
actores), para reflejar la creacin de un objeto. Otro detalle importante es
que no se debe crear desde la clase Representacin, sino desde
RepresentacinCompacta. Ojo con la notacin de los objetos que
intervienen: deben ir subrayados, para reflejar que son objetos. En la
primera llamada a aadirSumando, para crear el primer sumando, la
llamada tambin puede ser de esta manera aadirSumando( , 1,2,1).
Para que se pueda ejecutar este diagrama de secuencia, la clase Ecuacion
necesita dos operaciones nuevas, aadirSumando y aadirRepresentacion,
cuyos prototipos son:
aadirSumando(Character signo, Integer grado, Integer numerador, Integer
denominador)
aadirRepresentacion(String tipo)

CASOS PRCTICOS DE UML

67

Generacin de cdigo para la clase Ecuacion


public class Ecuacion
{
//Atributos
private Integer grado;
private Integer soluciones[];
private Representacion theRepresentacion;
private Sumando theSumando[];
//Metodos
//
}

Lo importante en esta pregunta es que en la generacin de cdigo, las


relaciones de Ecuacin con las clases Representacin y Sumando, quedan
reflejadas como nuevos atributos. Ntese que tambin queda reflejada si la
multiplicidad es con muchos (como un atributo en forma de array) o con
uno solo (como un atributo atmico).

CASOS PRCTICOS DE UML

68

CASO PRCTICO 5:
Quetzalix

CASOS PRCTICOS DE UML

69

CASOS PRCTICOS DE UML

70

Caso prctico 5: Quetzalix5


Enunciado
Quetzalix es una aplicacin para hacer el seguimiento de llamadas a un
centro help-desk de atencin informtica a los usuarios de una empresa. Se
pretende modelar con UML la informacin necesaria para hacer un
seguimiento de todas las incidencias, es decir, su registro, su resolucin y
su cierre.
Se provoca una incidencia cuando falla el PC de un usuario. Entonces el
tcnico del help-desk registra toda la informacin de la incidencia: fecha
de creacin, hora de creacin, comentario. Se crear un registro con estos
datos rellenados y cuatro ms:
- el estado de la incidencia, que puede tomar los valores (abierto, en
resolucin, cerrado). En el momento de registrar la llamada, estado se pone
a abierto.
-causa de la resolucin. En el momento de registrar la llamada, causa se
pone a blancos.
-fecha de la resolucin. En el momento de registrar la llamada, este campo
se pone a blancos.
-hora de la resolucin. En el momento de registrar la llamada, este campo
se pone a blancos.
Sus mtodos son los necesarios para hacer todo el seguimiento de la
incidencia y para actualizar el valor de estado, causa, fecha, y hora de la
resolucin.
Los datos del usuario son:
-nombre
-apellido
-localizacin
-PC asignado
Y los mtodos para dar de alta a un usuario y para asignarle una operacin.

Includo en el examen extraordinario del curso 2009/10

CASOS PRCTICOS DE UML

71

Los datos del tcnico son:


-nombre
-apellido
Y el mtodo para dar de alta a un tcnico.
Un usuario est relacionado con sus incidencias, que pueden ser varias o
incluso ninguna, y una incidencia est relacionada con un usuario; un
tcnico registra varias incidencias, incluso ninguna. Lgicamente una
incidencia solo puede estar registrada una vez y por un solo tcnico. Una
vez abierta la llamada, se le asigna a un tcnico para que resuelva el
problema. Un tcnico puede tener varias incidencias asignadas o ninguna,
pero una incidencia solo puede ser asignada a un tcnico. Una incidencia
puede no tener asignada a ninguno, que es en el momento cuando se
registra la incidencia. Cuando una incidencia se le asigna a un tcnico,
estado se pone en resolucin. Una vez que el tcnico resuelve la
incidencia, la cierra, y se actualizan los datos estado (que se pone a
cerrado), causa, fecha y da de la resolucin. Un tcnico puede cerrar
muchas incidencias e incluso ninguna; una incidencia solo es cerrada por
un tcnico y puede que por ninguno (cuando no est resuelta).
Para coordinar todo esto, se crea una lista de incidencias que contiene
todas las incidencias. El creador de esta lista es el coordinador. La lista
puede estar vaca inicialmente. Una incidencia no puede existir sin
pertenecer a esta lista. Un coordinador no es ms que un tcnico que en un
momento puntual asume tareas de coordinacin. Los datos de la lista son
fecha_apertura y el mtodo necesario para su creacin.
Para esta aplicacin se solicita:
a. Un diagrama de casos de uso para representar toda la funcionalidad.
Identificar bien los actores.
b. Un diagrama de clases del dominio de la aplicacin que se han ido
describiendo en el enunciado. Es importante mostrar las relaciones
que hay entre las distintas clases, indicando multiplicidad en las
relaciones de asociacin y agregacin, e indicando el nombre de las
asociaciones. Tambin deben existir los atributos y mtodos
necesarios para que se pueda cubrir toda la funcionalidad descrita en
el enunciado. Indicar los parmetros de los mtodos.
c. Segn el enunciado, a cul de las clases se le puede aplicar el patrn
Singleton?. Indica cmo quedara actualizada la clase (sus mtodos
CASOS PRCTICOS DE UML

72

y/o atributos) para cumplir este patrn, y cual sera el contenido de


mtodo(s) nuevos(s) y la inicializacin y tipo del nuevo atributo.
d. Un diagrama de estados para reflejar los sucesivos estados por los
que pasa una incidencia, con las siguientes caractersticas:
- Solo un estado inicial y final.
- No hay condiciones.
- No hay estados compuestos.
- Las transiciones deben estar etiquetadas.
- Los estados intermedios deben contemplar los sucesivos estados por
los que pasa una incidencia y deben tener las acciones asociadas que
afectan a los atributos de la incidencia. Estas acciones se realizan en
el momento de entrar en cada estado.

Solucin
Los diagramas han sido realizados usando Bouml 4.9.1.

CASOS PRCTICOS DE UML

73

Diagrama de casos de uso

Figura 42. Diagrama de casos de uso

CASOS PRCTICOS DE UML

74

Diagrama de clases

Figura 43. Diagrama de clases

Segn el enunciado, los prototipos de los mtodos deben tener los


parmetros mnimos para realizar la funcionalidad, por tanto quedaran
como sigue, por ejemplo para la clase Incidencia:

Figura 44. Mtodos de la clase Incidencia

CASOS PRCTICOS DE UML

75

Se distinguen mtodos que inicializan los parmetros de la clase segn el


enunciado (registrar), mtodos que cambian algn valor de la clase con
valores recibidos (los que comienzan por actualizar), y mtodos que
cambian valor sin necesitar valores recibidos (resolver y cerrar).
De manera anloga se tratan el resto de las clases. Se ha tomado Incidencia
por ser la mas compleja.
Patrn Singleton
La clase a la cual se le puede aplicar este patrn es la de ListaIncidencias
por tener solo una instancia.

Figura 45. Clase ListaIncidencias

El nuevo atributo ejemplarunico tiene las siguientes caractersticas


(extrado de la caja de dilogo del Bouml):

Figura 46. Caractersticas del atributo ejemplarunico

El mtodo nuevo getejemplarunico tiene el siguiente contenido (extrado


de la caja de dilogo del Bouml):
CASOS PRCTICOS DE UML

76

Figura 47. Caractersticas del mtodo getejemparunico

CASOS PRCTICOS DE UML

77

Diagrama de estados

Figura 48. Diagrama de estados

CASOS PRCTICOS DE UML

78

APNDICE:
breve manual de uso del Rational Rose

CASOS PRCTICOS DE UML

79

Apndice:
breve manual de uso del Rational Rose
Esta herramienta CASE crea ficheros con la extensin .mdl, que incluyen
todo tipo de diagramas y artefactos definidos en UML.
A continuacin se describe su funcionalidad:
a. Distribucin del espacio de pantalla:
-barras de mens
-browser
-rea de diagrama
-barra de herramientas
-ventana de logs

Figura 49. Distribucin de pantalla del Rational Rose

CASOS PRCTICOS DE UML

80

Creacin de un nuevo modelo en Rational Rose

Figura 50. Creacin de un nuevo modelo desde el men File

Figura 51. Seleccin del lenguaje de programacin al crear un nuevo modelo

CASOS PRCTICOS DE UML

81

Figura 52. Mensajes de error al crear un nuevo modelo

c. Apertura de un modelo ya creado previamente

Figura 53. Apertura de un modelo desde el men File

CASOS PRCTICOS DE UML

82

Figura 54. Cuadro de dilogo al abrir un modelo

Figura 55. Respuesta del sistema al abrir un modelo

CASOS PRCTICOS DE UML

83

Figura 56. Carga de todas las subunidades al abrir un modelo

d. Creacin de diagramas de casos de uso

Figura 57. Creacin de diagramas de caso de uso desde el browser

CASOS PRCTICOS DE UML

84

Figura 58. Opcin para crear un nuevo caso de uso desde el browser

e. Almacenar paquetes del rbol como unidades

Figura 59. Opcin de controlar unidades desde el browser

CASOS PRCTICOS DE UML

85

Figura 60. Opcin de guardar unidad desde el browser

f. Cargar unidades en el modelo actual

Figura 61. Opcin de cargar unidad desde el browser

CASOS PRCTICOS DE UML

86

g. Almacenar el modelo

Figura 62. Opcin de almacenar modelo

h. Generacin de cdigo C a partir del modelo y ficheros resultantes

Figura 63. Opcin de generar cdigo

CASOS PRCTICOS DE UML

87

Al seleccionar la opcin de generacin de cdigo en este diagrama, se


obtienen los siguientes ficheros en C++:
1.
2.
3.
4.
5.
6.

Alumno.h
Alumno.cpp
Asignatura.h
Asignatura.cpp
Optativa.h
Optativa.cpp

A continuacin se expone el cdigo generado para los mencionados


ficheros.
Alumno.h
// Copyright
Corporation

(C)

1991

1999

Rational

Software

#if defined (_MSC_VER) && (_MSC_VER >= 1000)


#pragma once
#endif
#ifndef _INC_ALUMNO_4AC0DD610253_INCLUDED
#define _INC_ALUMNO_4AC0DD610253_INCLUDED
class Asignatura;
//##ModelId=4AC0DD610253
class Alumno
{
public:
//##ModelId=4AC0DD78031E
Asignatura* theAsignatura;
//##ModelId=4AC0DEEF0282
String getNombre();
//##ModelId=4AC0DEFE0011
String getApellido();
private:
//##ModelId=4AC0DE740159
String nombre;
//##ModelId=4AC0DE8002EF
CASOS PRCTICOS DE UML

88

String apellido;
};

CASOS PRCTICOS DE UML

89

Alumno.cpp
// Copyright
Corporation

(C)

1991

1999

Rational

Software

#include "stdafx.h"
#include "Alumno.h"
#include "Asignatura.h"

//##ModelId=4AC0DEEF0282
String Alumno::getNombre()
{
// TODO: Add your specialized code here.
// NOTE: Requires a correct return value
compile.
}
//##ModelId=4AC0DEFE0011
String Alumno::getApellido()
{
// TODO: Add your specialized code here.
// NOTE: Requires a correct return value
compile.
}

CASOS PRCTICOS DE UML

to

to

90

Asignatura.h
// Copyright
Corporation

(C)

1991

1999

Rational

Software

#if defined (_MSC_VER) && (_MSC_VER >= 1000)


#pragma once
#endif
#ifndef _INC_ASIGNATURA_4AC0DD6B03DA_INCLUDED
#define _INC_ASIGNATURA_4AC0DD6B03DA_INCLUDED
//##ModelId=4AC0DD6B03DA
class Asignatura
{
public:
//##ModelId=4AC0DF780205
String getNombre();
private:
//##ModelId=4AC0DF7102A1
String nombre;
};
#endif /* _INC_ASIGNATURA_4AC0DD6B03DA_INCLUDED */

CASOS PRCTICOS DE UML

91

Asignatura.cpp
// Copyright (C)
Corporation

1991

1999

Rational

Software

#include "stdafx.h"
#include "Asignatura.h"

//##ModelId=4AC0DF780205
String Asignatura::getNombre()
{
// TODO: Add your specialized code here.
// NOTE: Requires a correct return value
compile.
}

CASOS PRCTICOS DE UML

to

92

Optativa.h
// Copyright
Corporation

(C)

1991

1999

Rational

Software

#if defined (_MSC_VER) && (_MSC_VER >= 1000)


#pragma once
#endif
#ifndef _INC_OPTATIVA_4AC0E56102A1_INCLUDED
#define _INC_OPTATIVA_4AC0E56102A1_INCLUDED
#include "Asignatura.h"
//##ModelId=4AC0E56102A1
class Optativa
: public Asignatura
{
public:
//##ModelId=4AC0E8460001
int getCreditos();
private:
//##ModelId=4AC0E856038B
int creditos;
};
#endif /* _INC_OPTATIVA_4AC0E56102A1_INCLUDED */

CASOS PRCTICOS DE UML

93

Optativa.cpp
// Copyright
Corporation

(C)

1991

1999

Rational

Software

#include "stdafx.h"
#include "Optativa.h"

//##ModelId=4AC0E8460001
int Optativa::getCreditos()
{
// TODO: Add your specialized code here.
return (int)0;
}

CASOS PRCTICOS DE UML

94

i. Modificacin del modelo a partir del cdigo (ingeniera inversa)

Figura 64. Opcin de ingeniera inversa

Figura 65. Resultado de realizar ingeniera inversa

CASOS PRCTICOS DE UML

95

Al dibujar el diagrama que saca por defecto, se observa que las relaciones
de clientelismo no se ven reflejadas en l, solo las de herencia.

Figura 66. Obtencin de las relaciones con las nuevas clases

Aunque al hacer un diagrama Nuevo y arrastrar las clases, las relaciones s


se arrastran automticamente.

CASOS PRCTICOS DE UML

96