Casos Practicos de UML

Casos prácticos de UMLExtensión Celia Gutiérrez Cosío Casos prácticos de UML CELIA GUTIÉRREZ COSÍO A. 28015 Madrid Tels. . Todos los libros publicados por Editorial Complutense a partir de enero de 2007 han superado el proceso de evaluación experta. lo que garantiza la difusión y comercialización de sus publicaciones a nivel nacional e internacional.: 91 394 64 61/0.es www. Cualquier forma de reproducción. S. © 2011 by Celia Gutiérrez Cosío © 2011 by Editorial Complutense.4. Donoso Cortés. Fax: 91 394 64 58 ecsa@rect. comunicación pública o transformación de esta obra sólo puede ser realizada con la autorización expresa de sus titulares.com Primera edición: Septiembre de 2011 ISBN eBook: 978-84-9938-100-8 Esta editorial es miembro de la UNE.ucm. 63 .Todos los derechos reservados. distribución. salvo excepción prevista por la ley.ª planta.editorialcomplutense. así como de ejercicios planteados en exámenes. 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. ya que resuelve un caso práctico completo. Consta de ejercicios resueltos que han formado parte de las prácticas y ejemplos de clase. . Con esta publicación no se pretende responder a cuestiones teóricas. según los paradigmas de la Ingeniería del Software. sino proporcionar varios casos prácticos y su solución. Por último. normalmente diagramas de casos de uso y de clases. se incluye un apéndice con un manual de uso de una de las herramientas usadas para la creación de los diagramas: Rational Rose Enterprise Edition 2003. aportando guías para solucionarlo según el Proceso Unificado. los cuatro siguientes plantean la resolución de las partes más importantes del problema. Consta de 5 casos prácticos: el primero es el núcleo del libro. dado que este aspecto ya está muy desarrollado en la bibliografía. Se basa en la creación de varios diagramas que representan varios puntos de vista distintos pero complementarios de un sistema.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. . 53 55 55 56 57 . . . . . . . . . . . . . . . . . . . . . . . . 22 Diagramas de agenda . . . . . . 18 Refinamiento del diagrama de casos de uso y especificaciones de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Diagrama de clases (diseño detallado) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Índice Caso práctico 1: Sistema de gestión de agendas y reuniones Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Diagrama de secuencia (diseño previo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Diagramas de casos de uso . . . . . . . . . . . 27 Diagrama de clases (previo y detallado) . . . . . . . . . 47 Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Especificaciones de casos de uso. . . . . . . 15 Diagrama de secuencia (diseño detallado) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Caso práctico 3: Sistema Operativo “Maxix” Enunciado . . . . . . . . . . . 11 Diagramas de casos de uso . . . Diagrama de clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Re-estructuración del árbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Re-estructuración del árbol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Refinamiento del diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Diagramas de secuencia detallados . . . . . . . . 39 Caso Práctico 2: Editor de Documentos Parole Enunciado . . . . . 13 Diagrama de clases (diseño previo) . . . . . . . . . . . 23 Especificaciones de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de secuencia detallado. . 32 Diagramas de secuencia previos . . . . . . . . . . . . . . Patrón Singleton. . . . . . . . . . . . Diagrama de clases. . . . . . . . . . . . . . . . . . . . . . Diagrama de estados . . . . . . . Diagrama de clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . Solución . . . . . . . . . . . . . . . .Caso práctico 4: Sistema de ecuaciones de grado “n” Enunciado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de secuencia detallado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de secuencia previo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caso práctico 5: Quetzalix Enunciado . . . . . . . . . . Clases y métodos abstractos . . . . . Generación de código para la clase Ecuacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Apéndice: breve manual de uso del Rational Rose . . . . . . . . . . . 71 73 74 75 76 78 79 61 63 64 65 65 66 67 68 . . . . . . . . . . . . . . . . . . . . Diagrama de casos de uso . . CASO PRÁCTICO 1: Sistema de gestión de agendas y reuniones CASOS PRÁCTICOS DE UML 9 . CASOS PRÁCTICOS DE UML 10 . las relacionadas con un grupo. Cada entrada tiene un título. alias. Se podrá crear. una prioridad. una lista de tareas y una lista de notas. Basado en la práctica del Curso 2008/09 11 CASOS PRÁCTICOS DE UML . gestionar grupos de usuarios y organizar reuniones entre personas adscritas al sistema. 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).Caso práctico 1: Sistema de gestión de agendas y reuniones1 Enunciado La práctica consiste en analizar y diseñar con UML una aplicación web para gestionar agendas personales. teléfonos. buscar. una fecha (día y hora) y comentarios. 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). Cada usuario tiene acceso a una agenda personal. El calendario también ofrece la posibilidad de sacar una lista de todas las entradas. Un usuario puede pertenecer a varios grupos. etc. entre dos fechas. consultar. por ejemplo. un texto descriptivo. Las entradas pueden ser públicas (cualquier otro usuario puede verlas). etc. un título. También tienen un 1 Adaptado de Juan Pavón. El calendario permite ver por días. En la lista de tareas. El directorio de contactos es una lista de personas con sus datos de contacto (nombre. con varias opciones. y una categoría (para clasificarlas en grupos de tareas). cada una consta de una fecha de terminación (o sin fecha de terminación). semanas. a partir de una fecha. Cualquier usuario se puede convertir en administrador de grupos. pero esto lo hace el administrador de grupos. La agenda consta de un calendario. email. Estas entradas pueden ser creadas por el usuario o por el administrador de reuniones. meses o años las entradas que se hubieran creado en el mismo.) y notas adicionales. un directorio de contactos. modificar o borrar elementos de este directorio. dirección. Los usuarios del sistema se pueden asociar a grupos de trabajo que se definieran en el sistema. modificar o borrar elementos de esta lista. c. consultar (de varias maneras. en cuyo caso se elegirá la fecha más votada. modificar o borrar nombres de categorías. Se podrá crear. modificar o borrar notas. buscar. o en una entrada del calendario un enlace a una tarea). así como un lugar. grupo de tareas.indicador de hasta qué punto se ha cumplido (porcentaje. Cada invitado recibirá la solicitud de voto cuando se conecte al sistema. CASOS PRÁCTICOS DE UML 12 . Los casos de uso deben cubrir todas las funciones del enunciado (si bien esto se verá con más detalle en las especificaciones).1. Nomenclatura correcta de los casos de uso: con verbos adecuados al contexto. 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. con los siguientes requisitos: Diagramas de casos de uso Deben estar diseñados de la siguiente manera: a. consultar. estado y fecha de terminación). un enlace a un contacto. fecha y duración. El sistema de gestión de reuniones es un sistema auxiliar y externo al sistema. La fecha de la reunión final se apuntará en la agenda de todos los usuarios invitados a la reunión. En la lista de notas. cuando llega a 100 es que se ha completado). Pueden estar asociadas a una categoría. Se pide modelar el caso con la herramienta Bouml 4. En los campos de texto se pueden poner enlaces a otras entradas de la agenda (por ejemplo. en una nota. b. 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. Cada reunión tendrá un título y una descripción de los objetivos y la agenda de la reunión. La fecha de terminación se verá reflejada en el calendario.9. En la agenda se podrán crear. Nomenclatura y extracción correcta de los actores: con sustantivos adecuados al contexto. por nombre. que permite a los usuarios de un grupo concertar reuniones buscando el momento más propicio. cada nota consta de un título y un texto. Se podrá crear. Correcta estructuración en paquetes. e. Extracción de clases: el enunciado da una idea aproximada de cuáles van a ser las clases. 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). Que el objetivo de un caso de uso esté recogido en el enunciado ó al menos sirva para hacer algo del enunciado. para seguir el proceso unificado. f. Que esta especificación conste de todos los apartados. b. si bien esto se verá con más detalle en las especificaciones). c. sean coherentes para la realización del objetivo. postcondiciones. Se valorarán positivamente otros flujos alternativos. d. Las relaciones entre casos de uso deben ser las correctas según el enunciado.d. Que las precondiciones. siempre que sean coherentes con el caso de uso que se implementa. Debe haber al menos un flujo alternativo por cada caso. que debe corresponderse a la secuencia de acciones cuando el usuario pulsa “cancelar”. La secuencia normal debe reflejar el diálogo entre un usuario y la interfaz del sistema. 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. Aunque solo se debe modelizar el diseño detallado. f. Se evaluará: a. Que todos los casos de uso tengan una especificación de caso de uso ligada a él. examinando conceptos que figuran CASOS PRÁCTICOS DE UML 13 . y debe contener todos los apartados de la plantilla. en concreto en el paso del flujo de secuencia normal ó alternativa en el que participen. Especificaciones de casos de uso La especificación deberá ser rellenada en el apartado “description”. g. Diagrama de clases (diseño previo) El diagrama de clases se va a realizar en dos fases: diseño previo y diseño detallado. 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. e. En el diseño previo se debe realizar lo siguiente: a. conviene realizarlo en estos dos pasos. y secuencia normal. apareciendo nuevos ó desapareciendo otros que no se usan. En las relaciones entre clases: se puede extraer del enunciado. Insertar métodos: si se conocen los parámetros y el tipo que devuelven. Por defecto es 1. A puede ser de varios tipos: B … 3. pero los métodos también se refinarán en los diagramas de secuencia. A crea B … iii. También se pueden extraer de las especificaciones de los casos de uso. como sustantivos y que forman parte de la información que va a manejar el sistema. A y B son partes de C iii. Atributo a de clase A también se refleja en el atributo b de clase B… 2. 2. Ejemplos de asociación: i. Sin embargo. CASOS PRÁCTICOS DE UML 14 . Se entiende que una clase es un conjunto de atributos y/o métodos que caracterizan a un conjunto de objetos. 1. Ambos se pueden extraer del enunciado. En las clases: 1. Ambos se pueden extraer del enunciado. Insertar atributos: si se conoce su tipo. b. A se compone de B y C Diagrama de clases (diseño detallado) Este diagrama si se debe modelar. en su defecto dar nombre a los roles de los extremos. darlos. 2. dar su tipo. Un usuario se puede asociar a grupos … ii. Ejemplos de generalización: i. Dar multiplicidad a los extremos de las asociaciones y de las agregaciones. En el diseño detallado se debe realizar lo siguiente: a.b. A es un subtipo de B ii. Ejemplos de agregación: i. no todos los sustantivos van a ser clases: pueden ser atributos. 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. A consta de B y C ii. Dar nombres a las asociaciones. 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. Captura de pantalla de un árbol conteniendo las vistas en Bouml Por otra parte. Este es un ejemplo de cómo quedaría el navegador del Bouml. para la parte de Tarea y un único caso de uso (se la considera como si no hubiera mas cosas): Figura 1. la otra los diagramas de secuencia detallados. CASOS PRÁCTICOS DE UML 15 . hay que realizar tantos diagramas de secuencia previos como escenarios haya para cada caso de uso de esa carpeta. Una de las dos sub vistas contendrá los diagramas de secuencia previos.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. El sistema crea una tarea y le envia mensaje "Tarea y entrada de calendario creados" Flujo alternativo a: 1a. luego en la sub vista de Diagramas de secuencia previos deben existir 2 diagramas de secuencia previos cuyos nombres cuyos nombres son Crear Tarea. El sistema crea una entrada de calendario y se envía el mensaje "Calendario creado". Mensaje "Tarea y entrada Calendario creados" el de La opción CrearTarea debe Condición final fallido: No se crean ni la tarea ni la entrada. El sistema da el mensaje calendario no creadas" "Tarea y entrada En la especificación existen dos escenarios: una correspondiente a la secuencia normal y el otro al flujo alternativo a. titulo. Postcondiciones salida: Condición final exitoso: Tarea y su entrada en calendario creadas. 2. categoria. 3. indicador.Cada diagrama de secuencia es la realización de un escenario de caso de uso. texto. CASOS PRÁCTICOS DE UML 16 . Se debe realizar lo mismo para el resto de casos de uso. Mensaje "Tarea y entrada calendario no creadas" Actor primario: Usuario Actores secundarios: No hay Secuencia normal: 1. Crear Tarea a. 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. Para ello debe existir una especificación de caso de uso. prioridad. Precondiciones entradas: haber sido seleccionada. Siguiendo el ejemplo de la Tarea. 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. El usuario introduce fecha terminación. El usuario pulsa cancelar 2a. Diagrama de secuencia previo para la secuencia normal del caso de uso CrearTarea CASOS PRÁCTICOS DE UML 17 .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. El nombre del mensaje debe reflejar la acción que se realiza ó bien el valor devuelto por una acción previa. Aquí están los dos diagramas de secuencia correspondientes a la especificación del caso de uso anterior: Figura 2. 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). 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. Aquí se muestran los diagramas detallados correspondientes a los diagramas anteriores: CASOS PRÁCTICOS DE UML 18 . Diagrama de secuencia previo para el flujo alternativo del caso de uso CrearTarea. 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.Figura 3. así que hay cambiar el nombre del diagrama con un espacio entre nombres o un guion). y por tanto no son más que llamadas a dichas funciones. se van a tener clases del diagrama de clases. 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. en vez de tener la clase Sistema. Para realizar un diagrama de secuencia detallado. La etiqueta también debe contener los argumentos de las llamadas a las funciones. Figura 4. Diagrama de secuencia detallado para la secuencia normal del caso de uso CrearTarea CASOS PRÁCTICOS DE UML 19 . CASOS PRÁCTICOS DE UML 20 . 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. Si no es así hay que corregirlo (normalmente en los diagramas de casos de uso y sus especificaciones).Figura 5. 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. Deben existir las mismas operaciones en los diagramas de secuencia y en el diagrama de clases (ni más ni menos). 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. CASOS PRÁCTICOS DE UML 21 . de clases hay que crearla. hay que crearla). si sobra. si sobra. c. Si hay alguna que falta en el d.Refinamiento del diagrama de clases La creación de los diagramas de secuencia detallados provoca un refinamiento del diagrama de clases (que los alumnos deben realizar) a 3 niveles: a. Si sucede. Deben existir las mismas clases en los diagramas de secuencia y en el diagrama de clases (ni más ni menos). de clases hay que crearla. esto. si no se puede. 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. borrarla. b. Si hay alguna que falta en el d. borrarla. Diagramas de grupos de usuarios Figura 6. Diagrama de casos de uso de grupos de usuarios CASOS PRÁCTICOS DE UML 22 .Solución Diagramas de casos de uso Se adjuntan los diagramas de casos de uso refinados. Diagramas de agenda Figura 7. Diagrama de casos de uso del directorio de contactos CASOS PRÁCTICOS DE UML 23 . Figura 8. Diagrama de casos de uso de notas CASOS PRÁCTICOS DE UML 24 . Diagrama de casos de uso de categoria Figura 9. Figura 10. Diagrama de casos de uso de calendario CASOS PRÁCTICOS DE UML 25 . Casos de uso de reuniones CASOS PRÁCTICOS DE UML 26 .Figura 11. Diagrama de casos de uso de tareas Diagramas de Reuniones de usuarios Figura 12. ConcertarReuniónArbitraria c. se ha apuntado en la agenda de los invitados. Diagrama de relaciones entre actores (dentro de los casos de uso) Especificaciones de casos de uso Por considerarlas como las más complejas. Precondiciones entradas: La opción ConcertarREunion ha sido seleccionada. ConcertarReunión b. CASOS PRÁCTICOS DE UML 27 . Postcondiciones salida: Se ha creado una reunion.Relaciones entre actores Figura 13. el resto son parecidas la especificación del enunciado: a. 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. se han desarrollado especificaciones de los siguientes caso de uso. Mensaje "Apuntada en agenda". CASOS PRÁCTICOS DE UML 28 . Mensaje "Apuntada en agenda". se ha apuntado en la agenda de los invitados. Postcondiciones salida: Condición final exitoso: Se ha creado una reunion. Mensaje "Reunion no creada y no apuntada en agenda" Actor primario: AdministradorReunion Actores secundarios: SistemaGestionReuniones. 3. 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. Condición final fallido: No se crean ni la reunion ni se apunta en la agenda. El AdministradorReunion selecciona una fecha.Condición final exitoso: Se ha creado una reunion. Mensaje "Reunion creada". Condición final fallido: No se crean ni la reunion ni se apunta en la agenda. Mensaje "Reunion creada". 2. se ha apuntado en la agenda de los invitados. El SistemaGestionReunion le muestra al AdministradorReunion una lista de fechas segun agendas de usuarios grupo. Precondiciones entradas: La opción ConcertarREunionArbitraria ha sido seleccionada. El AdministradorReunion pide fechas de la reunion al SistemaGestionReunion. Invitado Secuencia normal: 1. El AdministradorReunion pulsa Cancelar 5c. El AdministradorReunion pulsa Cancelar 4b. descripcion.4. El SistemaGestionReunion actualiza la informacion en las agendas de los invitados a la reunión. objetivos. El SistemaGestionReunion da el mensaje "Reunion no creada y no apuntada en agenda" Flujo alternativo b: 3b. 5. se ha apuntado en la agenda de los invitados. El AdministradorReunion proporciona el resto de datos: titulo. "Reunion no creada y no apuntada en agenda" Flujo alternativo c: 4c. Mensaje "Apuntada en agenda". 6. Mensaje "Reunion no creada y no apuntada en agenda" Actor primario: AdministradorReunion CASOS PRÁCTICOS DE UML 29 . El SistemaGestionReunion da el mensaje "Reunion creada" tanto al Administrador de la reunion como a los invitados. Postcondiciones salida: Condición final exitoso: Se ha creado una reunion. El AdministradorReunion pulsa Cancelar 2a. Precondiciones entradas: La opción ConcertarREunionVotación ha sido seleccionada. Flujo alternativo a: 1a. Condición final fallido: No se crean ni la reunion ni se apunta en la agenda. lugar y duracion.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. Mensaje "Reunion creada". "Reunion no creada y no apuntada en agenda" 2.3. El SistemaGestionReunion actualiza la informacion en las agendas de los invitados a la reunión. El AdministradorReunion pulsa Cancelar 4b. 2. descripcion. Los invitados votan la fecha. El SistemaGestionReunion le muestra al AdministradorReunion una lista de fechas segun agendas de usuarios grupo. El AdministradorReunion proporciona el resto de datos: titulo. El SistemaGestionReunion da el mensaje "Reunion creada" a los invitados y a l administrador de la reunión. Invitado Secuencia normal: 1. El SistemaGestionReunion muestra la fecha final al Administrador. 3. 4. 9. lugar y duracion. El SistemaGestionReunion pide a los Invitados que voten. Flujo alternativo a: 1a. El SistemaGestionReunion da el mensaje "Reunion no creada y no apuntada en agenda" Flujo alternativo b: 3b. El AdministradorReunion pulsa Cancelar 8c. El AdministradorReunion pide fechas de la reunion al SistemaGestionReunion. 7. 5. "Reunion no creada y no apuntada en agenda" CASOS PRÁCTICOS DE UML 30 . 8. objetivos. El AdministradorReunion pide que al SistemaGestionReunion que se haga una votación de las fechas. "Reunion no creada y no apuntada en agenda" Flujo alternativo c: 7c. El AdministradorReunion pulsa Cancelar 2a.Actores secundarios: SistemaGestionReuniones. 6. que es el diagrama detallado. Figura 14.Diagrama de clases (previo y detallado) Dada la cantidad de diagramas previos posibles. solo se recoge el definitivo. se debe tener en cuenta que para llegar a este diagrama detallado. No obstante. Diagrama de clases previo y detallado CASOS PRÁCTICOS DE UML 31 . se han debido dar todos los pasos previos de casos de uso y especificaciones de casos de uso. 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ónVotación: CASOS PRÁCTICOS DE UML 32 . ConcertarReuniónArbitraria.Re-estructuración del árbol Figura 15. Diagrama de secuencia previo del caso de uso CrearTarea (secuencia normal) Figura 17.Figura 16. Diagrama de secuencia previo del caso de uso CrearTarea (flujo alternativo) CASOS PRÁCTICOS DE UML 33 . Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (secuencia normal) CASOS PRÁCTICOS DE UML 34 .Figura 18. Diagrama de secuencia previo del caso del uso ConcertarReunion Arbitraria (flujo alternativo a) Figura 20.Figura 19. Diagrama de secuencia previo del caso de uso ConcertarReunionArbitraria (flujo alternativo b) CASOS PRÁCTICOS DE UML 35 . Figura 21. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo a) CASOS PRÁCTICOS DE UML 36 . Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (secuencia normal) Figura 22. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo b) CASOS PRÁCTICOS DE UML 37 .Figura 23. Figura 24. Diagrama de secuencia previo del caso de uso ConcertarReunionVotacion (flujo alternativo c) CASOS PRÁCTICOS DE UML 38 . Diagrama de secuencia detallado para el caso de uso CrearTarea (flujo alternativo a) CASOS PRÁCTICOS DE UML 39 . Diagrama de secuencia detallado del caso de uso CrearTarea (secuencia normal) Figura 26.Diagramas de secuencia detallados Se han incluido los diagramas de secuencia detallados para los que existen diagramas de secuencia previos. Figura 25. Figura 27. Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (flujo alternativo a) CASOS PRÁCTICOS DE UML 40 . Diagrama de secuencia detallado para el caso de uso ConcertarReunionArbitraria (secuencia normal) Figura 28. 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 PRÁCTICOS 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 PRÁCTICOS DE UML 42 Figura 33. Diagrama de secuencia detallado para el caso de uso ConcertarReunionVotacion (flujo alternativo c) CASOS PRÁCTICOS DE UML 43 CASOS PRÁCTICOS DE UML 44 CASO PRÁCTICO 2: Editor de Documentos Parole CASOS PRÁCTICOS DE UML 45 . CASOS PRÁCTICOS DE UML 46 . Un grupo debe contener al menos dos objetos representables. mientras que un objeto representable solo puede ser parte de un grupo como máximo. triángulos y cuadrados.Caso Práctico 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. y los polígonos pueden ser rectángulos. El agrupamiento es un concepto ampliamente utilizado por los editores de documentos. un conjunto de objetos representables. objetos gráficos y grupos (tal vez ninguna. Un grupo consta de. además. (También puede ser que no forme parte de ningún grupo). Cada página contiene objetos representables. y puede constar de otros grupos. si existen elementos contenidos en un grupo y éste desaparece. Solución Según el enunciado del problema. Un grupo solo puede formar parte de otro grupo como máximo. también desaparecen los elementos contenidos en él. Los objetos gráficos pueden ser curvilíneos ó polígonos. las páginas solo deben existir en el contexto de un documento. que son textos. es el caso de cuando se abre un nuevo documento). se pueden extraer las siguientes clases: • Documento • • • • 2 Página Objeto representable Texto Objeto gráfico Ejercicio propuesto en el curso 2008/09 47 CASOS PRÁCTICOS DE UML . Suponer que un documento consta de varias páginas (al menos una). Los curvilíneos pueden ser círculos ó elipses. Los objetos representables deben existir siempre en el contexto de una página. 1. 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..*. 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. Finalmente hay que indicar unas relaciones de generalización.. refiriéndonos a la multiplicidad. a 0..1. que son evidentes según el enunciado del problema: • Objeto gráfico y curvilíneo • Objeto gráfico y polígono CASOS PRÁCTICOS DE UML 48 ..*...* • • Relación de composición entre grupo y grupo: de 0. Relación de composición entre grupo y objeto representable: de 0. a 2.• • • • • • • • Grupo Curvilíneo Polígono Circulo Elipse Rectángulo Triángulo Cuadrado Se pueden distinguir relaciones entre estas clases. • • • • • 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: Figura 34. Diagrama de clases del editor Parole CASOS PRÁCTICOS DE UML 49 . CASOS PRÁCTICOS DE UML 50 . CASO PRÁCTICO 3: Sistema Operativo “Maxix” CASOS PRÁCTICOS DE UML 51 . CASOS PRÁCTICOS DE UML 52 . consultar o modificar el fichero. nombre. nombre y propietario al sistema de archivos. La tabla de usuarios referencia a todos los usuarios y la tabla de ficheros referencia a todos los ficheros. con el nombre suministrado por el usuario y la dirección de comienzo. el usuario recibe la notificación de “Fichero creado”. y el fichero simple. la tabla de ficheros se ve ampliada con una nueva entrada con los datos del tipo. y las recientemente creadas identificador y dirección de comienzo. Si se borra el directorio. pero es el usuario que crea el fichero quien puede borrar. Se puede crear un usuario y consultar sus datos. que se encarga de obtener un identificador y una dirección de comienzo al nuevo fichero. que se compone a su vez de otros ficheros. Si la creación se lleva a cabo correctamente. Los usuarios pueden ser propietarios de ficheros. pero un fichero solo pertenece a un propietario.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. Existen dos tipos de ficheros: el directorio. consultar. que está asociado a una tabla de ficheros y a una tabla de usuarios. Además un directorio puede estar vacío. cualquier usuario puede crear un fichero. un ejecutable) o texto (es decir conteniendo ASCII). Para esta aplicación se solicita: 3 Incluido en el examen ordinario del curso 2008/09 53 CASOS PRÁCTICOS DE UML . pero ésto solo lo puede hacer el administrador del sistema. propietario. y modificar. borrar. y por último se crea un nuevo fichero del tipo indicado por el usuario. Debe al menos un usuario referidos (el administrador) y 2 ficheros (la tabla de ficheros y la tabla de usuarios). también desaparecen los ficheros que están contenidos en él. El fichero simple a su vez puede ser binario (por ejemplo. Cualquier tipo de fichero se puede crear. Cuando un usuario crea un fichero nuevo se produce el siguiente efecto en cascada: le proporciona el tipo. Un diagrama de clases del dominio de la aplicación que se han ido describiendo en el enunciado. indicando multiplicidad en las relaciones de asociación y agregación. Es importante mostrar las relaciones que hay entre las distintas clases. Mostrar el esquema. Se debe aplicar un patrón estructural de los vistos en clase. d. c. Identificar bien los actores. b. No hay que indicar atributos ni métodos en este apartado. participantes y colaboraciones de este sistema operativo de ese patrón aplicado a la funcionalidad descrita. También es importante indicar qué clases y métodos abstractos existen. e indicando el nombre de la asociación en las asociaciones. Un diagrama de secuencia detallado que muestre cómo se crea un fichero de tipo binario para el caso de que se cree correctamente. CASOS PRÁCTICOS DE UML 54 . Indicar los métodos que deben figurar como mínimo en estas clases que forman parte del patrón.a. Un diagrama de casos de uso para representar toda la funcionalidad. indicando los métodos que se invocan y los argumentos. Diagrama de casos de uso de Maxix CASOS PRÁCTICOS DE UML 55 .Solución Diagrama de casos de uso Figura 35. en este diagrama quedan respondidas las cuestiones a y b. Diagrama de clases de Maxix CASOS PRÁCTICOS DE UML 56 .Diagrama de clases Para adquirir un aspecto más compacto. Figura 36. Diagrama de secuencia detallado Figura 37. Diagrama de secuencia detallado de Crear fichero (flujo alternativo binario) CASOS PRÁCTICOS DE UML 57 . CASOS PRÁCTICOS DE UML 58 . CASO PRÁCTICO 4: Sistema de ecuaciones de grado “n” CASOS PRÁCTICOS DE UML 59 . CASOS PRÁCTICOS DE UML 60 . y pueden aparecer por tanto en muchas ecuaciones.Caso práctico 4: Sistema de ecuaciones de grado “n”4 Enunciado Se plantea el desarrollo de una aplicación que permita crear. La información de una ecuación es: grado. una ecuación debe contener como mínimo un sumando y como máximo n. así como representarlas por el informático: Una ecuación de grado “n” está compuesta por n sumandos. resolver ecuaciones de grado “n” por el matemático. que es un número entero Denominador. A su vez. de tipo carácter Numerador. array de enteros La ecuación debe tener (como mínimo) las operaciones para crear y resolver la ecuación. 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 61 CASOS PRÁCTICOS DE UML . soluciones. Esto se puede hacer de dos maneras. e incluso ninguna. y el sumando debe contener (como mínimo) la operación para crear el sumando. Cada sumando tiene la siguiente información: Un signo. que es un número entero El grado. que es un número entero. Otra de las cosas que se hace es representar la ecuación. Los sumandos pueden existir independientemente de que una ecuación exista ó no. que es un número entero. y a partir de la ecuación se crea la representación correspondiente. también se representa la ecuación. Un diagrama de casos de uso para representar toda la funcionalidad. el matemático añade el sumando de grado 1 a la ecuación (con los datos de ese sumando). 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. Un diagrama de clases del dominio de la aplicación que se han ido describiendo en el enunciado. Nota: esta secuencia de pasos no es una especificación de caso de uso.3/1x3-22/3x2+5/1x1-9/7x0=0 Y de manera compacta: 3x3-22/3x2+5x-9/7=0 Así una ecuación se asocia a UNA representación. b. Es importante mostrar las relaciones que hay entre las distintas clases. sino una lista de funciones que se debe hacer para la creación completa de una ecuación. Al final. de tipo String. y que informático y matemático son independientes entre sí. la ecuación envía el mensaje “Ecuación y sumandos creados” al matemático. que puede ser de tipo compacto ó extendido. e indicando el nombre de la asociación en las asociaciones. y debe tener como mínimo la operación para crear la representación. Para crear la ecuación de grado 1. indicando multiplicidad en las relaciones de asociación y agregación. Identificar bien los actores. La información que guarda la representación es contenido. 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. el informático añade a la ecuación una nueva representación indicando su tipo (“compacta” ó “extendida”). CASOS PRÁCTICOS DE UML 62 . Este proceso se repite para el sumando de grado 0. Al crear una ecuación. También se indica que debe existir la clase Ecuación. 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. Para esta aplicación se solicita: a. como respuesta a esa creación el sumando envía “Sumando creado” a la ecuación. Por último. quien llama a la creación de ese sumando inicializando sus datos. CASOS PRÁCTICOS DE UML 63 . Se asume que se usa el generador de código del Rational Rose Enterprise Edition 2003 (usado en la asignatura). ¿Qué contendría el código de la clase Ecuación en el aparatado de atributos. Un diagrama de secuencia detallado para crear dicha ecuación. d. e. Indicar cuáles son. Solución Los diagramas han sido diseñados con Rational Rose Enterprise Edition 2003).c. Un diagrama de secuencia previo que muestre cómo se crea la ecuación de grado 1 en representación compacta: 2x+1=0. indicando los métodos que se invocan y los argumentos. f. Según el enunciado deben existir algún(as) clase(s) abstractas con algunos método(s) abstractos. Indica cómo queda actualizado el diagrama de clases (si es que queda actualizado con nuevos métodos). al generar código en un lenguaje de programación orientada a objetos como C++ o Java?. Diagrama de casos de uso ResuelveEcuacion Matematico CreaEcuacion <<include>> Informatico RepresentaEcuacion RepresentaCompacta RepresentaExtendida Figura 38. como dice el enunciado “Al crear una ecuación. CASOS PRÁCTICOS DE UML 64 . Diagrama de casos de uso En este diagrama es clave reflejar que la creación de una ecuación incluye su representación. también se representa la ecuación”. y por tanto..* 1. de tipo String. Clases y métodos abstractos Clase abstracta: Representación. Estas clases NO PUEDEN EXISTIR VACIAS. está claro que no se van a crear otro tipo de representaciones.Diagrama de clases Sumando signo : Character numerador : Integer denominador : Integer grado : Integer crear() Ecuacion grado : Integer soluciones : Integer[] crear() resolver() se_asocia 0. como el propio enunciado dice: “La información que guarda la representación es contenido.* Representacion contenido : String crear() RepresentacionCompacta crear() RepresentacionExtendida crear() Figura 39. desde CASOS PRÁCTICOS DE UML 65 .. para adaptar la creación ó representación al tipo del que se trate. Este método crear(). también podría haberse llamado representarecuacion(). y debe tener como mínimo la operación para crear la representación”. y siguiendo el enunciado tienen su propio método crear(). deben existir el atributo contenido y el método crear. ya que es lo que hace. ya que el enunciado dice que “puede ser de tipo compacto ó extendido”. Las subclases de Representación deben existir. Dado que la representación solo puede ser compacta ó extendida. Diagrama de clases En la clase representación. Método abstracto: Crear. Representación no se va a instanciar ningún objeto. Diagrama de secuencia previo : Informatico : Matematico Introducir grado 1 Introducir sumando grado 1 : Sistema Introducir sumando grado 0 "Ecuación y sumandos creados" Solicita representacion compacta "2x+1=0" Figura 40. ya que la función de este es la de crear la representación. CASOS PRÁCTICOS DE UML 66 . según el tipo de representación de la cual se trate. el método abstracto será crear. Tambien sería válido reflejar las interacciones sistema-sistema. Así mismo. y será una clase abstracta. Diagrama de secuencia previo En este diagrama hay que reflejar las interacciones entre los actores y el sistema. y esto se debe hacer en los métodos de las subclases. 1. 1.2. Integer numerador. cuyos prototipos son: añadirSumando(Character signo.1) crear(+. para reflejar que son objetos.2. Integer grado. añadirSumando y añadirRepresentacion.1) "Sumando creado" : Sumando "Ecuacion y sumandos creados" añadirRepresentacion("compacta") crear( ) "2x+1=0" "2x+1=0" : RepresentacionCompacta Figura 41.1) : Sumando : Ecuacion "Sumando creado" añadirSumando(+. la llamada también puede ser de esta manera añadirSumando(‘ ‘. Ojo con la notación de los objetos que intervienen: deben ir subrayados. Otro detalle importante es que no se debe crear desde la clase Representación. 1. representacióncompacta y ecuación la colocación de los objetos que se crean debe estar a la altura de mensaje (es decir.2.1. Diagrama de secuencia detallado Un detalle importante es que en la creación de los sumandos.1. mas abajo que en los actores).1. sino desde RepresentaciónCompacta.1) crear(+.1). para crear el primer sumando. para reflejar la creación de un objeto. Para que se pueda ejecutar este diagrama de secuencia. la clase Ecuacion necesita dos operaciones nuevas. En la primera llamada a añadirSumando. Integer denominador) añadirRepresentacion(String tipo) CASOS PRÁCTICOS DE UML 67 .Diagrama de secuencia detallado : Informatico : Matematico crear(1) añadirSumando(+.0. CASOS PRÁCTICOS DE UML 68 . quedan reflejadas como nuevos atributos. //Metodos //… } Lo importante en esta pregunta es que en la generación de código.Generación de código para la clase Ecuacion public class Ecuacion { //Atributos private Integer grado. 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). private Integer soluciones[]. las relaciones de Ecuación con las clases Representación y Sumando. private Representacion theRepresentacion. private Sumando theSumando[]. CASO PRÁCTICO 5: Quetzalix CASOS PRÁCTICOS DE UML 69 . CASOS PRÁCTICOS DE UML 70 . -fecha de la resolución. y hora de la resolución. que puede tomar los valores (abierto. Se creará un registro con estos datos rellenados y cuatro más: . 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. Sus métodos son los necesarios para hacer todo el seguimiento de la incidencia y para actualizar el valor de estado. causa se pone a blancos. su resolución y su cierre. este campo se pone a blancos. hora de creación. su registro. -causa de la resolución.el estado de la incidencia. causa. En el momento de registrar la llamada. estado se pone a abierto. -hora de la resolución.Caso práctico 5: Quetzalix5 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. en resolución. Se pretende modelar con UML la información necesaria para hacer un seguimiento de todas las incidencias. fecha. cerrado). Se provoca una incidencia cuando falla el PC de un usuario. 5 Incluído en el examen extraordinario del curso 2009/10 71 CASOS PRÁCTICOS DE UML . Entonces el técnico del help-desk registra toda la información de la incidencia: fecha de creación. es decir. este campo se pone a blancos. En el momento de registrar la llamada. En el momento de registrar la llamada. comentario. En el momento de registrar la llamada. una incidencia solo es cerrada por un técnico y puede que por ninguno (cuando no está resuelta). fecha y día de la resolución. b. e indicando el nombre de las asociaciones. Según el enunciado. la cierra. Indicar los parámetros de los métodos. indicando multiplicidad en las relaciones de asociación y agregación. El creador de esta lista es el coordinador. También deben existir los atributos y métodos necesarios para que se pueda cubrir toda la funcionalidad descrita en el enunciado. Un diagrama de clases del dominio de la aplicación que se han ido describiendo en el enunciado. Un técnico puede cerrar muchas incidencias e incluso ninguna.Los datos del técnico son: -nombre -apellido Y el método para dar de alta a un técnico. Identificar bien los actores. estado se pone en resolución. Para esta aplicación se solicita: a. Para coordinar todo esto. que pueden ser varias o incluso ninguna. incluso ninguna. un técnico registra varias incidencias. Un técnico puede tener varias incidencias asignadas o ninguna. causa. Un usuario está relacionado con sus incidencias. Una incidencia no puede existir sin pertenecer a esta lista. La lista puede estar vacía inicialmente. Indica cómo quedaría actualizada la clase (sus métodos CASOS PRÁCTICOS DE UML 72 . c. que es en el momento cuando se registra la incidencia. se le asigna a un técnico para que resuelva el problema. Una incidencia puede no tener asignada a ninguno. ¿a cuál de las clases se le puede aplicar el patrón Singleton?. pero una incidencia solo puede ser asignada a un técnico. Lógicamente una incidencia solo puede estar registrada una vez y por un solo técnico. 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. Una vez abierta la llamada. Cuando una incidencia se le asigna a un técnico. Un diagrama de casos de uso para representar toda la funcionalidad. Es importante mostrar las relaciones que hay entre las distintas clases. y una incidencia está relacionada con un usuario. Una vez que el técnico resuelve la incidencia. y se actualizan los datos estado (que se pone a cerrado). se crea una lista de incidencias que contiene todas las incidencias. 9. .No hay estados compuestos. Estas acciones se realizan en el momento de entrar en cada estado.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. CASOS PRÁCTICOS DE UML 73 . .Las transiciones deben estar etiquetadas.1.No hay condiciones. . d. Un diagrama de estados para reflejar los sucesivos estados por los que pasa una incidencia.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. .Solo un estado inicial y final. Solución Los diagramas han sido realizados usando Bouml 4. con las siguientes características: . Diagrama de casos de uso CASOS PRÁCTICOS DE UML 74 .Diagrama de casos de uso Figura 42. los prototipos de los métodos deben tener los parámetros mínimos para realizar la funcionalidad. por tanto quedarían como sigue. Métodos de la clase Incidencia CASOS PRÁCTICOS DE UML 75 . por ejemplo para la clase Incidencia: Figura 44. Diagrama de clases Según el enunciado.Diagrama de clases Figura 43. De manera análoga se tratan el resto de las clases. Se ha tomado Incidencia por ser la mas compleja. y métodos que cambian valor sin necesitar valores recibidos (resolver y cerrar). métodos que cambian algún valor de la clase con valores recibidos (los que comienzan por actualizar).Se distinguen métodos que inicializan los parámetros de la clase según el enunciado (registrar). Patrón Singleton La clase a la cual se le puede aplicar este patrón es la de ListaIncidencias por tener solo una instancia. Figura 45. Características del atributo ejemplarunico El método nuevo getejemplarunico tiene el siguiente contenido (extraído de la caja de diálogo del Bouml): CASOS PRÁCTICOS DE UML 76 . Clase ListaIncidencias El nuevo atributo ejemplarunico tiene las siguientes características (extraído de la caja de diálogo del Bouml): Figura 46. Figura 47. Características del método getejemparunico CASOS PRÁCTICOS DE UML 77 . Diagrama de estados CASOS PRÁCTICOS DE UML 78 .Diagrama de estados Figura 48. APÉNDICE: breve manual de uso del Rational Rose CASOS PRÁCTICOS DE UML 79 . mdl. A continuación se describe su funcionalidad: a. Distribución del espacio de pantalla: -barras de menús -browser -área de diagrama -barra de herramientas -ventana de logs Figura 49. que incluyen todo tipo de diagramas y artefactos definidos en UML. Distribución de pantalla del Rational Rose CASOS PRÁCTICOS DE UML 80 .Apéndice: breve manual de uso del Rational Rose Esta herramienta CASE crea ficheros con la extensión . Creación de un nuevo modelo en Rational Rose Figura 50. Selección del lenguaje de programación al crear un nuevo modelo CASOS PRÁCTICOS DE UML 81 . Creación de un nuevo modelo desde el menú File Figura 51. Apertura de un modelo ya creado previamente Figura 53.Figura 52. Mensajes de error al crear un nuevo modelo c. Apertura de un modelo desde el menú File CASOS PRÁCTICOS DE UML 82 . Respuesta del sistema al abrir un modelo CASOS PRÁCTICOS DE UML 83 .Figura 54. Cuadro de diálogo al abrir un modelo Figura 55. Figura 56. Creación de diagramas de caso de uso desde el browser CASOS PRÁCTICOS DE UML 84 . Creación de diagramas de casos de uso Figura 57. Carga de todas las subunidades al abrir un modelo d. Opción de controlar unidades desde el browser CASOS PRÁCTICOS DE UML 85 . Opción para crear un nuevo caso de uso desde el browser e. Almacenar paquetes del árbol como unidades Figura 59.Figura 58. Opción de cargar unidad desde el browser CASOS PRÁCTICOS DE UML 86 . Cargar unidades en el modelo actual Figura 61. Opción de guardar unidad desde el browser f.Figura 60. g. Opción de almacenar modelo h. Generación de código C a partir del modelo y ficheros resultantes Figura 63. Opción de generar código CASOS PRÁCTICOS DE UML 87 . Almacenar el modelo Figura 62. Al seleccionar la opción de generación de código 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 continuación se expone el código 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 PRÁCTICOS DE UML 88 String apellido; }; CASOS PRÁCTICOS 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. } to to CASOS PRÁCTICOS DE UML 90 #endif /* _INC_ASIGNATURA_4AC0DD6B03DA_INCLUDED */ CASOS PRÁCTICOS DE UML 91 . private: //##ModelId=4AC0DF7102A1 String nombre.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(). h" //##ModelId=4AC0DF780205 String Asignatura::getNombre() { // TODO: Add your specialized code here.cpp // Copyright (C) Corporation 1991 - 1999 Rational Software #include "stdafx. // NOTE: Requires a correct return value compile.Asignatura. } to CASOS PRÁCTICOS DE UML 92 .h" #include "Asignatura. h" //##ModelId=4AC0E56102A1 class Optativa : public Asignatura { public: //##ModelId=4AC0E8460001 int getCreditos(). private: //##ModelId=4AC0E856038B int creditos.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.Optativa. }. #endif /* _INC_OPTATIVA_4AC0E56102A1_INCLUDED */ CASOS PRÁCTICOS DE UML 93 . Optativa. return (int)0.h" #include "Optativa.h" //##ModelId=4AC0E8460001 int Optativa::getCreditos() { // TODO: Add your specialized code here. } CASOS PRÁCTICOS DE UML 94 .cpp // Copyright Corporation (C) 1991 1999 Rational Software #include "stdafx. Resultado de realizar ingeniería inversa CASOS PRÁCTICOS DE UML 95 . Opción de ingeniería inversa Figura 65.i. Modificación del modelo a partir del código (ingeniería inversa) Figura 64. Figura 66.Al dibujar el diagrama que saca por defecto. solo las de herencia. se observa que las relaciones de clientelismo no se ven reflejadas en él. CASOS PRÁCTICOS DE UML 96 . las relaciones sí se arrastran automáticamente. Obtención de las relaciones con las nuevas clases Aunque al hacer un diagrama Nuevo y arrastrar las clases.