Вы находитесь на странице: 1из 96
Extensión
Extensión
Extensión Casos prácticos de UML Celia Gutiérrez Cosío

Casos prácticos de UML

Celia Gutiérrez Cosío

Casos prácticos de UML

CELIA GUTIÉRREZ COSÍO

Casos prácticos de UML C ELIA G UTIÉRREZ C OSÍO

Todos los derechos reservados. Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra sólo puede ser realizada con la autorización expresa de sus titulares, salvo excepción prevista por la ley.

Todos los libros publicados por Editorial Complutense a partir de enero de 2007 han superado el proceso de evaluación experta.

© 2011 by Celia Gutiérrez Cosío

© 2011 by Editorial Complutense, S.A. Donoso Cortés, 63 - 4.ª planta. 28015 Madrid Tels.: 91 394 64 61/0. Fax: 91 394 64 58 ecsa@rect.ucm.es www.editorialcomplutense.com

Primera edición:

Septiembre de 2011

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

Esta editorial es miembro de la UNE, lo que garantiza la difusión y comercialización de sus publicaciones a nivel nacional e internacional.

Prólogo

El UML es el Lenguaje Unificado de Modelado que se usa tanto para análisis como para diseño de la funcionalidad de un sistema de información, según los paradigmas de la Ingeniería del Software. Se basa en la creación de varios dia- gramas que representan varios puntos de vista distintos pero complementarios de un sistema. Con esta publicación no se pretende responder a cuestiones teó- ricas, dado que este aspecto ya está muy desarrollado en la bibliografía, sino pro- porcionar varios casos prácticos y su solución. El siguiente libro recopila la parte práctica realizada en la asignatura Ingeniería de Software de Gestión II durante los cursos 2008/09 y 2009/10. Consta de ejercicios resueltos que han formado parte de las prácticas y ejemplos de clase, así como de ejercicios planteados en exámenes. Consta de 5 casos prácticos: el primero es el núcleo del libro, ya que resuelve un caso práctico completo, aportando guías para solucionarlo según el Proceso Unificado; los cuatro siguientes plantean la resolución de las partes más impor- tantes del problema, normalmente diagramas de casos de uso y de clases. Por último, se incluye un apéndice con un manual de uso de una de las herra- mientas usadas para la creación de los diagramas: Rational Rose Enterprise Edition 2003.

Índice

Caso práctico 1: Sistema de gestión de agendas y reuniones

Enunciado

.

.

.

.

.

.

.

.

.

. Especificaciones de casos de Diagrama de clases (diseño previo)

.

.

. Diagramas de casos de uso

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

11

12

13

13

. Diagrama de clases (diseño detallado)

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

14

 

15

Re-estructuración del Diagrama de secuencia (diseño previo)

. Refinamiento del diagrama de casos de uso y

.

.

. Diagrama de secuencia (diseño detallado)

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

15

18

especificaciones de casos de uso

Solución

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

20

Refinamiento del diagrama de clases

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

22

Diagramas de casos de uso

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

22

. Especificaciones de casos de uso

Diagramas de agenda

. Diagrama de clases (previo y detallado)

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

23

27

31

Re-estructuración del árbol

32

Diagramas de secuencia previos Diagramas de secuencia detallados

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

32

39

Caso Práctico 2: Editor de Documentos Parole

Enunciado

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

47

Solución

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

47

Caso práctico 3: Sistema Operativo “Maxix”

 

Enunciado

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

53

Solución

.

.

.

.

.

.

. Diagrama de casos de uso

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

55

55

. Diagrama de secuencia

Diagrama

de

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

56

57

Caso práctico 4: Sistema de ecuaciones de grado “n”

Enunciado

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

61

Solución

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

63

Diagrama de casos de uso

64

Diagrama

. Diagrama de secuencia previo

.

. Clases y métodos abstractos

de

clases.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

65

65

66

Diagrama de secuencia

 

67

Generación de código para la clase

68

Caso práctico 5: Quetzalix

 

Enunciado

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

71

Solución

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

73

Diagrama de casos de uso

74

Diagrama

de

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

75

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

76

Patrón Diagrama de estados

.

.

.

.

.

.

.

.

.

.

. Apéndice: breve manual de uso del Rational Rose

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

78

79

CASO PRÁCTICO 1:

Sistema de gestión de agendas y reuniones

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

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

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

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.

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

Re-estructuración 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 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):

caso de uso (se la considera como si no hubiera mas cosas): Figura 1. Captura de

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.

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: La opción CrearTarea debe haber sido seleccionada.

Postcondiciones salida:

Condición final exitoso: Tarea y su entrada en el

calendario creadas. Mensaje Calendario creados"

Condición final fallido: No se crean ni la tarea ni la

entrada. Mensaje "Tarea 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 "Tarea y entrada calendario no creadas"

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.

entrada calendario no

de

"Tarea

y entrada

y

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:

a la especificación del caso de uso anterior: Figura 2. Diagrama de secuencia previo para la

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

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

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:

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

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

Figura 5. Diagrama de secuencia detallado para el flujo alternativo del caso de uso CrearTarea

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

Refinamiento del diagrama de clases

diagramas de secuencia detallados provoca un

refinamiento del diagrama de clases (que los alumnos deben realizar) a 3 niveles:

La

creación

de

los

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

Solución

Diagramas de casos de uso

Se adjuntan los diagramas de casos de uso refinados. Diagramas de grupos de usuarios

de casos de uso refinados. Diagramas de grupos de usuarios Figura 6. Diagrama de casos de

Figura 6. Diagrama de casos de uso de grupos de usuarios

Diagramas de agenda

Diagramas de agenda Figura 7. Diagrama de casos de uso del directorio de contactos CASOS PRÁCTICOS

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

Figura 8. Diagrama de casos de uso de categoria Figura 9. Diagrama de casos de

Figura 8. Diagrama de casos de uso de categoria

Figura 8. Diagrama de casos de uso de categoria Figura 9. Diagrama de casos de uso

Figura 9. Diagrama de casos de uso de notas

Figura 10. Diagrama de casos de uso de calendario CASOS PRÁCTICOS DE UML 2 5

Figura 10. Diagrama de casos de uso de calendario

Figura 11. Diagrama de casos de uso de tareas Diagramas de Reuniones de usuarios Figura

Figura 11. Diagrama de casos de uso de tareas

Diagramas de Reuniones de usuarios

de casos de uso de tareas Diagramas de Reuniones de usuarios Figura 12. Casos de uso

Figura 12. Casos de uso de reuniones

Relaciones entre actores

Relaciones entre actores Figura 13. Diagrama de relaciones entre actores (dentro de los casos de uso)

Figura 13. Diagrama de relaciones entre actores (dentro de los casos de uso)

Especificaciones de casos de uso

Por

especificaciones de los siguientes caso de uso; el resto son parecidas la especificación del enunciado:

han desarrollado

considerarlas

como

las

más

complejas,

se

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.

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.

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

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"

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.

previos de casos de uso y especificaciones de casos de uso. Figura 14. Diagrama de clases

Figura 14. Diagrama de clases previo y detallado

Re-estructuración del árbol

Re-estructuración del árbol Figura 15. Organización de vistas y subvistas en paquetes Diagramas de secuencia previos

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:

Figura 16. Diagrama de secuencia previo del caso de uso CrearTarea (secuencia normal) Figura 17.

Figura 16. Diagrama de secuencia previo del caso de uso CrearTarea (secuencia normal)

previo del caso de uso CrearTarea (secuencia normal) Figura 17. Diagrama de secuencia previo del caso

Figura 17. Diagrama de secuencia previo del caso de uso CrearTarea (flujo alternativo)

Figura 18. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (secuencia normal) CASOS PRÁCTICOS

Figura 18. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (secuencia normal)

Figura 19. Diagrama de secuencia previo de l caso del uso ConcertarReunion Arbitraria (flujo alternativo

Figura 19. Diagrama de secuencia previo del caso del uso ConcertarReunion Arbitraria (flujo alternativo a)

del uso ConcertarReunion Arbitraria (flujo alternativo a) Figura 20. Diagrama de secuencia previo del caso de

Figura 20. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (flujo alternativo b)

Figura 21. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (secuencia normal) Figura 22.

Figura 21. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (secuencia normal)

del caso de uso ConcertarReunionVotacion (secuencia normal) Figura 22. Diagrama de secuencia previo del caso de

Figura 22. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo a)

Figura 23. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo b) CASOS

Figura 23. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo b)

Figura 24. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo c) CASOS

Figura 24. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo c)

Diagramas de secuencia detallados

Se han incluido los diagramas de secuencia detallados para los que existen diagramas de secuencia previos.

para los que existen diagramas de secuencia previos. Figura 25. Diagrama de secuencia deta llado del

Figura 25. Diagrama de secuencia detallado del caso de uso CrearTarea (secuencia normal)

deta llado del caso de uso CrearTarea (secuencia normal) Figura 26. Diagrama de secuencia detallado para

Figura 26. Diagrama de secuencia detallado para el caso de uso CrearTarea (flujo alternativo a)

Figura 27. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (secuencia normal) Figura

Figura 27. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (secuencia normal)

caso de uso ConcertarReunionArbitraria (secuencia normal) Figura 28. Diagrama de secuencia detallado para el caso de

Figura 28. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (flujo alternativo a)

Figura 29. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (flujo alternativo b)

Figura 29. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (flujo alternativo b)

de uso ConcertarReunionArbitraria (flujo alternativo b) Figura 30. Diagrama de secuencia detallado para el caso de

Figura 30. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (secuencia normal)

Figura 31. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo a)

Figura 31. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo a)

caso de uso ConcertarReunionVotacion (flujo alternativo a) Figura 32. Diagrama de secuencia detallado para el caso

Figura 32. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo b)

Figura 33. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo c)

Figura 33. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo c)

CASO PRÁCTICO 2:

Editor de Documentos Parole

Caso Práctico 2:

Editor de Documentos Parole 2

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 páginas (al menos una). Cada página contiene objetos representables, que son textos, objetos gráficos 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 máximo. (También puede ser que no forme parte de ningún grupo). Un grupo solo puede formar parte de otro grupo como máximo. Los objetos representables deben existir siempre en el contexto de una página; las páginas solo deben existir en el contexto de un documento; además, si existen elementos contenidos en un grupo y éste desaparece, también desaparecen los elementos contenidos en él. Los objetos gráficos pueden ser curvilíneos ó polígonos. Los curvilíneos pueden ser círculos ó elipses, y los polígonos pueden ser rectángulos, triángulos y cuadrados.

Solución

Según el enunciado del problema, se pueden extraer las siguientes clases:

Documento

Página

Objeto representable

Texto

Objeto gráfico

2 Ejercicio propuesto en el curso 2008/09

Grupo

Curvilíneo

Polígono

Circulo

Elipse

Rectángulo

Triángulo

Cuadrado

Se pueden distinguir relaciones entre estas clases. El primer tipo es relación de composición entre:

Documento y página

Página y objeto representable

Objeto representable y grupo

Grupo y grupo

Además, refiriéndonos a la multiplicidad, que es:

Relación de composición entre documento y página: de 1 a 1 *

Relación de composición entre página y objeto representable: de 1 *

a 0

Relación de composición entre grupo y grupo: de 0

1,

a 0

*.

Relación de composición entre grupo y objeto representable: de

0

1,

a 2

*.

Finalmente hay que indicar unas relaciones de generalización, que son evidentes según el enunciado del problema:

Objeto gráfico y curvilíneo

Objeto gráfico y polígono

Curvilíneo y circulo

Curvilíneo y elipse

Polígono y rectángulo

Polígono y triángulo

Polígono y cuadrado

El diagrama definitivo queda como sigue:

y cuadrado El diagrama definitivo queda como sigue: Figura 34. Diagrama de cl ases del editor

Figura 34. Diagrama de clases del editor Parole

CASO PRÁCTICO 3:

Sistema Operativo “Maxix”

Caso práctico 3:

Sistema Operativo “Maxix” 3

Enunciado

Se plantea el desarrollo de una aplicación para implementar el sistema operativo “Maxix” programado en el lenguaje de programación 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, también desaparecen los ficheros que están contenidos en él. Además un directorio puede estar vacío. 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 dirección 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 dirección 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 dirección de comienzo. Si la creación se lleva a cabo correctamente, el usuario recibe la notificación de “Fichero creado”.

Para esta aplicación se solicita:

3 Incluido en el examen ordinario del curso 2008/09

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 aplicación 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 asociación y agregación, e indicando el nombre de la asociación en las asociaciones. Se debe aplicar un patrón estructural de los vistos en clase. No hay que indicar atributos ni métodos en este apartado.

c. Mostrar el esquema, participantes y colaboraciones de este sistema operativo de ese patrón aplicado a la funcionalidad descrita. Indicar los métodos que deben figurar como mínimo en estas clases que forman parte del patrón. También es importante indicar qué clases y métodos abstractos existen.

d. Un diagrama de secuencia detallado que muestre cómo se crea un fichero de tipo binario para el caso de que se cree correctamente, indicando los métodos que se invocan y los argumentos.

Solución

Diagrama de casos de uso

Solución Diagrama de casos de uso Figura 35. Diagrama de casos de uso de Maxix CASOS

Figura 35. Diagrama de casos de uso de Maxix

Diagrama de clases

Para adquirir un aspecto más compacto, en este diagrama quedan respondidas las cuestiones a y b.

en este diagrama quedan respondidas las cuestiones a y b. Figura 36. Diagrama de clases de

Figura 36. Diagrama de clases de Maxix

Diagrama de secuencia detallado

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

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

CASO PRÁCTICO 4:

Sistema de ecuaciones de grado “n”

Caso práctico 4:

Sistema de ecuaciones de grado “n” 4

Enunciado

Se plantea el desarrollo de una aplicación que permita crear, resolver ecuaciones de grado “n” por el matemático, así como representarlas por el informático:

Una ecuación de grado “n” está compuesta por n sumandos. Cada sumando tiene la siguiente información:

- Un signo, de tipo carácter

- Numerador, que es un número entero

- Denominador, que es un número entero

- El grado, que es un número entero.

Los sumandos pueden existir independientemente de que una ecuación exista ó no, y pueden aparecer por tanto en muchas ecuaciones, e incluso ninguna. A su vez, una ecuación debe contener como mínimo un sumando y como máximo n.

La información de una ecuación es:

- grado, que es un número entero.

- soluciones, array de enteros

La ecuación debe tener (como mínimo) las operaciones para crear y resolver la ecuación, y el sumando debe contener (como mínimo) la operación para crear el sumando.

Otra de las cosas que se hace es representar la ecuación. Esto se puede hacer de dos maneras, y lo hace el informático:

- Representar de manera compacta

- Representar de manera extendida

Un ejemplo de ecuación de grado 3 de manera extendida es:

4 Incluído en el examen ordinario del curso 2009/10

3/1x 3 -22/3x 2 +5/1x 1 -9/7x 0 =0

Y

de manera compacta:

3x

3 -22/3x 2 +5x-9/7=0

Así una ecuación se asocia a UNA representación, que puede ser de tipo compacto ó extendido. La información que guarda la representación es contenido, de tipo String, y debe tener como mínimo la operación para crear la representación. Al crear una ecuación, también se representa la ecuación.

Para crear la ecuación de grado 1, se incluyen estos pasos en cascada:

El matemático introduce el grado de la ecuación para que se cree la ecuación inicializando el grado; el matemático añade el sumando de grado 1 a la ecuación (con los datos de ese sumando), quien llama a la creación de ese sumando inicializando sus datos; como respuesta a esa creación el sumando envía “Sumando creado” a la ecuación. Este proceso se repite para el sumando de grado 0. Al final, la ecuación envía el mensaje “Ecuación y sumandos creados” al matemático.

Por último, el informático añade a la ecuación una nueva representación indicando su tipo (“compacta” ó “extendida”); y a partir de la ecuación se crea la representación correspondiente; una vez creada la representación se devuelve el valor de su representación a la ecuación quien a su vez se la devuelve al informático.

Nota: esta secuencia de pasos no es una especificación de caso de uso, sino una lista de funciones que se debe hacer para la creación completa de una ecuación; y que informático y matemático son independientes entre sí.

Para esta aplicación 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 aplicación 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 asociación y agregación, e indicando el nombre de la asociación en las asociaciones. También deben existir los atributos con sus tipos y métodos necesarios para que se pueda cubrir toda la funcionalidad descrita en el enunciado. También se indica que debe existir la clase Ecuación.

c.

Según el enunciado deben existir algún(as) clase(s) abstractas con algunos método(s) abstractos. Indicar cuáles son.

d. Un diagrama de secuencia previo que muestre cómo se crea la ecuación de grado 1 en representación compacta: 2x+1=0.

e. Un diagrama de secuencia detallado para crear dicha ecuación, indicando los métodos que se invocan y los argumentos. Indica cómo queda actualizado el diagrama de clases (si es que queda actualizado con nuevos métodos).

f. ¿Qué contendría el código de la clase Ecuación en el aparatado de atributos, al generar código en un lenguaje de programación orientada a objetos como C++ o Java?. Se asume que se usa el generador de código del Rational Rose Enterprise Edition 2003 (usado en la asignatura).

Solución

Los diagramas han sido diseñados con Rational Rose Enterprise Edition

2003).

Diagrama de casos de uso ResuelveEcuacion Matematico
Diagrama de casos de uso
ResuelveEcuacion
Matematico

CreaEcuacion

<<include>>
<<include>>

Informatico

RepresentaEcuacion

I n f o r m a t i c o RepresentaEcuacion R e p r

RepresentaCompacta

RepresentaExtendida

Figura 38. Diagrama de casos de uso

En este diagrama es clave reflejar que la creación de una ecuación incluye su representación, como dice el enunciado “Al crear una ecuación, también se representa la ecuación”.

Diagrama de clases

Sumando Ecuacion signo : Character grado : Integer numerador : Integer soluciones : Integer[] denominador
Sumando
Ecuacion
signo : Character
grado : Integer
numerador : Integer
soluciones : Integer[]
denominador : Integer
grado : Integer
0
*0
*
*1
1
*
crear()
resolver()
crear()
se_asocia
Representacion
contenido : String
crear()
 
 
 
 

RepresentacionCompacta

 

RepresentacionExtendida

crear() crear()

crear()

crear() crear()

crear()

Figura 39. Diagrama de clases

En la clase representación, deben existir el atributo contenido y el método crear, como el propio enunciado dice: “La información que guarda la representación es contenido, de tipo String, y debe tener como mínimo la operación para crear la representación”. Este método crear(), también podría haberse llamado representarecuacion(), ya que es lo que hace. Las subclases de Representación 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 método crear(), para adaptar la creación ó representación al tipo del que se trate.

Clases y métodos abstractos

Clase abstracta: Representación.

Método abstracto: Crear.

Dado que la representación solo puede ser compacta ó extendida, está claro que no se van a crear otro tipo de representaciones, y por tanto, desde

Representación no se va a instanciar ningún objeto, y será una clase abstracta. Así mismo, el método abstracto será crear, ya que la función de este es la de crear la representación, y esto se debe hacer en los métodos de las subclases, según el tipo de representación de la cual se trate.

Diagrama de secuencia previo

: Sistema : Informatico : Matematico Introducir grado 1 Introducir sumando grado 1 Introducir sumando
: Sistema
: Informatico
: Matematico
Introducir grado 1
Introducir sumando grado 1
Introducir sumando grado 0
"Ecuación 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 sería válido reflejar las interacciones sistema-sistema.

Diagrama de secuencia detallado

: Informatico : Matematico crear(1) : Ecuacion añadirSumando(+,1,2,1) crear(+, 1,2,1) : Sumando "Sumando
: Informatico
: Matematico
crear(1)
: Ecuacion
añadirSumando(+,1,2,1)
crear(+, 1,2,1)
: Sumando
"Sumando creado"
añadirSumando(+,0,1,1)
crear(+,1,1,1)
: Sumando
"Sumando creado"
"Ecuacion y sumandos creados"
añadirRepresentacion("compacta")
crear( )
:
RepresentacionCompacta
"2x+1=0"
"2x+1=0"

Figura 41. Diagrama de secuencia detallado

Un detalle importante es que en la creación de los sumandos, representacióncompacta y ecuación la colocación de los objetos que se crean debe estar a la altura de mensaje (es decir, mas abajo que en los actores), para reflejar la creación de un objeto. Otro detalle importante es que no se debe crear desde la clase Representación, sino desde RepresentaciónCompacta. Ojo con la notación de los objetos que intervienen: deben ir subrayados, para reflejar que son objetos. En la primera llamada a añadirSumando, para crear el primer sumando, la llamada también puede ser de esta manera añadirSumando(‘ ‘, 1,2,1).

Para que se pueda ejecutar este diagrama de secuencia, la clase Ecuacion necesita dos operaciones nuevas, añadirSumando y añadirRepresentacion, cuyos prototipos son:

añadirSumando(Character signo, Integer grado, Integer numerador, Integer denominador) añadirRepresentacion(String tipo)

Generación de código 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 generación de código, las relaciones de Ecuación con las clases Representación y Sumando, quedan reflejadas como nuevos atributos. Nótese que también queda reflejada si la multiplicidad es con muchos (como un atributo en forma de array) o con uno solo (como un atributo atómico).

CASO PRÁCTICO 5:

Quetzalix

Caso práctico 5: Quetzalix 5

Enunciado

Quetzalix es una aplicación para hacer el seguimiento de llamadas a un centro help-desk de atención informática a los usuarios de una empresa. Se pretende modelar con UML la información necesaria para hacer un seguimiento de todas las incidencias, es decir, su registro, su resolución y su cierre.

Se provoca una incidencia cuando falla el PC de un usuario. Entonces el técnico del help-desk registra toda la información de la incidencia: fecha de creación, hora de creación, comentario. Se creará un registro con estos datos rellenados y cuatro más:

- el estado de la incidencia, que puede tomar los valores (abierto, en

resolución, cerrado). En el momento de registrar la llamada, estado se pone

a abierto.

-causa de la resolución. En el momento de registrar la llamada, causa se pone a blancos.

-fecha de la resolución. En el momento de registrar la llamada, este campo

se pone a blancos.

-hora de la resolución. En el momento de registrar la llamada, este campo

se pone a blancos.

Sus métodos son los necesarios para hacer todo el seguimiento de la incidencia y para actualizar el valor de estado, causa, fecha, y hora de la resolución.

Los datos del usuario son:

-nombre

-apellido

-localización

-PC asignado

Y los métodos para dar de alta a un usuario y para asignarle una operación.

5 Incluído en el examen extraordinario del curso 2009/10

Los datos del técnico son:

-nombre

-apellido

Y el método para dar de alta a un técnico.

Un usuario está relacionado con sus incidencias, que pueden ser varias o incluso ninguna, y una incidencia está relacionada con un usuario; un técnico registra varias incidencias, incluso ninguna. Lógicamente una incidencia solo puede estar registrada una vez y por un solo técnico. Una vez abierta la llamada, se le asigna a un técnico para que resuelva el problema. Un técnico puede tener varias incidencias asignadas o ninguna, pero una incidencia solo puede ser asignada a un técnico. 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 técnico, estado se pone en resolución. Una vez que el técnico resuelve la incidencia, la cierra, y se actualizan los datos estado (que se pone a cerrado), causa, fecha y día de la resolución. Un técnico puede cerrar muchas incidencias e incluso ninguna; una incidencia solo es cerrada por un técnico 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 vacía inicialmente. Una incidencia no puede existir sin pertenecer a esta lista. Un coordinador no es más que un técnico que en un momento puntual asume tareas de coordinación. Los datos de la lista son fecha_apertura y el método necesario para su creación.

Para esta aplicación 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 aplicación 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 asociación y agregación, e indicando el nombre de las asociaciones. También deben existir los atributos y métodos necesarios para que se pueda cubrir toda la funcionalidad descrita en el enunciado. Indicar los parámetros de los métodos.

c. Según el enunciado, ¿a cuál de las clases se le puede aplicar el patrón Singleton?. Indica cómo quedaría actualizada la clase (sus métodos

d.

y/o atributos) para cumplir este patrón, y cual sería el contenido de método(s) nuevos(s) y la inicialización y tipo del nuevo atributo.

Un diagrama de estados para reflejar los sucesivos estados por los que pasa una incidencia, con las siguientes características:

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

Solución

Los diagramas han sido realizados usando Bouml 4.9.1.

Diagrama de casos de uso

Diagrama de casos de uso Figura 42. Diagrama de casos de uso CASOS PRÁCTICOS DE UML

Figura 42. Diagrama de casos de uso

Diagrama de clases

Diagrama de clases Figura 43. Diagrama de clases Según el enunciado, los prototipos de los métodos

Figura 43. Diagrama de clases

Según el enunciado, los prototipos de los métodos deben tener los parámetros mínimos para realizar la funcionalidad, por tanto quedarían como sigue, por ejemplo para la clase Incidencia:

como sigue, por ejemplo para la clase Incidencia: Figura 44. Métodos de la clase Incidencia CASOS

Figura 44. Métodos de la clase Incidencia

Se distinguen métodos que inicializan los parámetros de la clase según el enunciado (registrar), métodos que cambian algún valor de la clase con valores recibidos (los que comienzan por actualizar), y métodos que cambian valor sin necesitar valores recibidos (resolver y cerrar).

De manera análoga se tratan el resto de las clases. Se ha tomado Incidencia por ser la mas compleja.

Patrón Singleton

La clase a la cual se le puede aplicar este patrón es la de ListaIncidencias por tener solo una instancia.

es la de ListaIncidencias por tener solo una instancia. Figura 45. Clase ListaIncidencias El nuevo atributo

Figura 45. Clase ListaIncidencias

El nuevo atributo ejemplarunico tiene las siguientes características (extraído de la caja de diálogo del Bouml):

(extraído de la caja de diálogo del Bouml): Figura 46. Características del atributo ejemplarunico El

Figura 46. Características del atributo ejemplarunico

El método nuevo getejemplarunico tiene el siguiente contenido (extraído de la caja de diálogo del Bouml):

Figura 47. Características del método getejemparunico CASOS PRÁCTICOS DE UML 7 7

Figura 47. Características del método getejemparunico

Diagrama de estados