Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Extensin
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. . . . . . . . . . . . . . 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 61 63 64 65 65 66 67 68
10
indicador de hasta qu punto se ha cumplido (porcentaje, cuando llega a 100 es que se ha completado). Se podr crear, consultar (de varias maneras, por nombre, grupo de tareas, estado y fecha de terminacin), modificar o borrar elementos de esta lista. La fecha de terminacin se ver reflejada en el calendario. En la lista de notas, cada nota consta de un ttulo y un texto. Pueden estar asociadas a una categora. Se podr crear, consultar, buscar, modificar o borrar notas. En la agenda se podrn crear, modificar o borrar nombres de categoras. En los campos de texto se pueden poner enlaces a otras entradas de la agenda (por ejemplo, en una nota, un enlace a un contacto, o en una entrada del calendario un enlace a una tarea). El sistema de gestin de reuniones es un sistema auxiliar y externo al sistema, que permite a los usuarios de un grupo concertar reuniones buscando el momento ms propicio. Cada reunin tendr un ttulo y una descripcin de los objetivos y la agenda de la reunin, as como un lugar, fecha y duracin. Para decidir la fecha el usuario que propone la reunin indicar un rango de fechas y el sistema proporcionar una lista de las ms convenientes para todos segn sus agendas. El promotor de la reunin podr elegir una fecha entre stas o pedir al sistema que permita votar (en un tiempo lmite) a los invitados a la reunin por una fecha, en cuyo caso se elegir la fecha ms votada. Cada invitado recibir la solicitud de voto cuando se conecte al sistema. La fecha de la reunin final se apuntar en la agenda de todos los usuarios invitados a la reunin. Se pide modelar el caso con la herramienta Bouml 4.9.1, con los siguientes requisitos: Diagramas de casos de uso Deben estar diseados de la siguiente manera: a. Nomenclatura correcta de los casos de uso: con verbos adecuados al contexto. b. Nomenclatura y extraccin correcta de los actores: con sustantivos adecuados al contexto. c. Los casos de uso deben cubrir todas las funciones del enunciado (si bien esto se ver con ms detalle en las especificaciones).
12
d. 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.
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):
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. Postcondiciones salida: Condicin final exitoso: Tarea y su entrada en calendario creadas. Mensaje "Tarea y entrada Calendario creados" el de La opcin CrearTarea debe
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
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:
18
Figura 4. Diagrama de secuencia detallado para la secuencia normal del caso de uso CrearTarea
19
Figura 5. Diagrama de secuencia detallado para el flujo alternativo del caso de uso CrearTarea
Una heurstica para saber a qu clase se le debe dirigir el mensaje es saber qu clase contiene el mtodo al que quieres llamar.
Refinamiento del diagrama de casos de uso y especificaciones de casos de uso La creacin de los diagramas de secuencia detallados provoca un refinamiento del diagrama de casos de uso (que los alumnos deben realizar) que consiste en que deben existir los mismos actores (ni ms, ni menos) en los diagramas de secuencia y en los diagramas de casos de uso. Si no es as hay que corregirlo (normalmente en los diagramas de casos de uso y sus especificaciones).
20
Refinamiento del diagrama de clases La creacin de los diagramas de secuencia detallados provoca un refinamiento del diagrama de clases (que los alumnos deben realizar) a 3 niveles: a. Deben existir las mismas clases en los diagramas de secuencia y en el diagrama de clases (ni ms ni menos). Si hay alguna que falta en el d. de clases hay que crearla; si sobra, borrarla. b. Deben existir las mismas operaciones en los diagramas de secuencia y en el diagrama de clases (ni ms ni menos). Si hay alguna que falta en el d. de clases hay que crearla; si sobra, borrarla. c. Las llamadas a mtodos entre clases provoca que exista una relacin entre clases que tal vez no se haya descubierto cuando se cre el diagrama de clases. Si sucede, esto, pensar si hay que crearla (Si se puede navegar a travs de las relaciones existentes de una clase a otra no hace falta crearla; si no se puede, hay que crearla).
21
Solucin
Diagramas de casos de uso Se adjuntan los diagramas de casos de uso refinados. Diagramas de grupos de usuarios
22
Diagramas de agenda
23
24
25
26
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
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"
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"
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.
31
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:
32
Figura 16. Diagrama de secuencia previo del caso de uso CrearTarea (secuencia normal)
Figura 17. Diagrama de secuencia previo del caso de uso CrearTarea (flujo alternativo)
33
Figura 18. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (secuencia normal)
34
Figura 19. Diagrama de secuencia previo del caso del uso ConcertarReunion Arbitraria (flujo alternativo a)
Figura 20. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (flujo alternativo b)
35
Figura 21. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (secuencia normal)
Figura 22. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo a)
36
Figura 23. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo b)
37
Figura 24. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo c)
38
Diagramas de secuencia detallados Se han incluido los diagramas de secuencia detallados para los que existen diagramas de secuencia previos.
Figura 25. Diagrama de secuencia detallado del caso de uso CrearTarea (secuencia normal)
Figura 26. Diagrama de secuencia detallado para el caso de uso CrearTarea (flujo alternativo a)
39
Figura 27. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (secuencia normal)
Figura 28. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (flujo alternativo a)
40
Figura 29. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (flujo alternativo b)
Figura 30. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (secuencia normal)
41
Figura 31. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo a)
Figura 32. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo b)
42
Figura 33. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo c)
43
44
45
46
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
49
50
51
52
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.
54
Solucin
Diagrama de casos de uso
55
Diagrama de clases Para adquirir un aspecto ms compacto, en este diagrama quedan respondidas las cuestiones a y b.
56
Figura 37. Diagrama de secuencia detallado de Crear fichero (flujo alternativo binario)
57
58
59
60
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
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).
63
ResuelveEcuacion
Informatico
RepresentaEcuacion
RepresentaCompacta
RepresentaExtendida
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.
64
Diagrama de clases
Sumando signo : Character numerador : Integer denominador : Integer grado : Integer crear()
Ecuacion grado : Integer soluciones : Integer[] crear() resolver() se_asocia 0..* 1..*
RepresentacionCompacta crear()
RepresentacionExtendida crear()
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.
: Informatico
: Sistema
En este diagrama hay que reflejar las interacciones entre los actores y el sistema. Tambien sera vlido reflejar las interacciones sistema-sistema.
66
: Informatico
"Sumando creado"
aadirSumando(+,0,1,1)
: Sumando
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)
67
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).
68
69
70
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.
73
74
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:
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.
El nuevo atributo ejemplarunico tiene las siguientes caractersticas (extrado de la caja de dilogo del Bouml):
El mtodo nuevo getejemplarunico tiene el siguiente contenido (extrado de la caja de dilogo del Bouml):
CASOS PRCTICOS DE UML
76
77
Diagrama de estados
78
79
80
81
82
83
84
Figura 58. Opcin para crear un nuevo caso de uso desde el browser
85
86
g. Almacenar el modelo
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
#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; };
89
(C)
1991
1999
Rational
Software
//##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. }
to
to
90
(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 */
91
1991
1999
Rational
Software
//##ModelId=4AC0DF780205 String Asignatura::getNombre() { // TODO: Add your specialized code here. // NOTE: Requires a correct return value compile. }
to
92
#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 */
93
//##ModelId=4AC0E8460001 int Optativa::getCreditos() { // TODO: Add your specialized code here. return (int)0; }
94
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.
Aunque al hacer un diagrama Nuevo y arrastrar las clases, las relaciones s se arrastran automticamente.
96