Ingeniería del Software-UML

1

INGENIERÍA DEL SOFTWARE. UML.

PROFESOR: Javier Macías del Campo. Despacho N-317. e-mail: javier.macias@uah.es

IMPORTANTE: Este documento es de uso exclusivo para alumnos de la asignatura de “Ingeniería del Software” de las titulaciones I.T.I.G. e Ingeniería en Electrónica de la Universidad de Alcalá.

TEMARIO: UML Introducción. Diagrama de Casos de uso. Diagrama de Secuencia. Diagrama de Colaboración. Diagrama de Estados. Diagrama de Actividades. Diagrama de Clases. Diagrama de Objetos. Diagrama de Componentes. Diagrama de Despliegue. Proceso Unificado de Rational. Generación de código.

BIBLIOGRAFÍA: • • • • Material entregado en CD (presentaciones, estándar UML y otros documentos). Ayuda de Rational Rose. En especial, para la generación de código se puede consultar en Ayuda Contenido Rose C++ las secciones Concepts y Reference Model-to-Code correspondences. Apuntes de C++ de “Estructura de Datos”. Entre otra, contiene información sobre plantillas (templates), constructores de copia y la STL (Standard Template Library). Libro “Mastering UML with Rational Rose”. Wendy Boggs y Michael Boggs. Ed. Sybex, 1999. Es muy fácil de seguir, aunque sólo cubre Rose 98. Tiene cerca de mil páginas porque contiene muchas pantallas, aunque se repiten demasiado ciertas operaciones. Es caro. Libro “El Lenguaje Unificado de Modelado”. Grady Booch, James Rumbaugh e Ivar Jacobson. Ed. Addison Wesley, 1999. A pesar de definirse en la portada como libro introductorio, es necesario tener unos conocimientos básicos de UML antes de intentar leer este libro.

Ingeniería del Software-UML

2 Pág.

ÍNDICE.
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Diagrama de Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Diagramas de Interacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Diagrama de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Diagrama de Colaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Diagrama de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Diagrama de Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Diagrama de Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Diagramas de Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Diagrama de Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Proceso Unificado de Rational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Generación de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

PRÓLOGO. Este documento constituye una introducción a UML 1. Sin embargo, debido a que en la asignatura “Laboratorio de Ingeniería del Software” se utiliza la herramienta Rational Rose, en algunos momentos se realizan particularizaciones a dicha herramienta. También se verá una breve introducción a la metodología “Proceso Unificado de Rational”. A partir de los diagramas de clases y componentes es factible generar código (al menos un esqueleto del mismo). El último tema se dedicará a la generación de código mediante Rational Rose, para lo cual se usará C++ como lenguaje de implementación.

1

El estándar UML es muy amplio, por lo que aquí no se verán todas sus particularidades. Se recomienda consultar la bibliografía si se desean completar los conocimientos o profundizar en algún aspecto concreto.

Ingeniería del Software-UML

3

INTRODUCCIÓN.

¿QUÉ ES UML?
Son las siglas de Lenguaje de Modela do Unificado (Unified Modeling Language). UML es un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos de sistemas con una componente software significativa. Como ejemplos de artefactos de un sistema tenemos el código fuente, el diseño, los requisitos, la arquitectura y los prototipos, entre otros. UML es un lenguaje de modelado orientado a objetos. Se debe recalcar que UML no es una metodología, aunque proporciona técnicas que pueden ser usadas en conjunto o parcialmente en metodologías, fundamentalmente aquellas destinadas al desarrollo orientados a objetos, como el Proceso Unificado de Rational o Métrica V.3 (aunque Métrica V.3 es una metodología mixta que también permite el desarrollo estructurado). Al ser UML un lenguaje, está compuesto de una sintaxis (reglas que indican cómo ensamblar los componentes de su vocabulario para crear expresiones) y una semántica (reglas que indican el significado de las expresiones). Ambos aspectos serán tratados aquí.

LA IMPORTANCIA DE MODELAR .
Los sistemas, ya sean naturales o artificiales, son difíciles de comprender. Esto es debido a que en general son bastante complejos y la mente humana sólo puede manejar 7 ±2 “elementos” de forma simultánea. Sin embargo, es posible representar y entender un sistema usando la técnica del modelado, esto es, construyendo modelos del sistema. Un modelo es una simplificación de la realidad creada para comprender mejor un sistema; un modelo es una abstracción que captura la parte esencial de los sistemas a un determinado nivel de detalle. Los modelos: - Ayudan a visualizar cómo es o queremos que sea un sistema. Permiten especificar la estructura o componentes del sistema. Son una guía para la construcción y mantenimiento de los sistemas. Permiten experimentar múltiples soluciones. Reducen los riesgos por errores. Documentan las decisiones adoptadas.

Existe una serie de principios básicos en el modelado de sistemas, entre los que destacan los siguientes: - Elegir el modelo más adecuado para cada sistema. Por ejemplo, si se va a realizar un desarrollo orientado a objetos, se debería utilizar un modelado orientado a objetos. Cuando así convenga, el sistema se podrá ver a diferentes niveles de detalle. Para eso, se utilizarán modelos más o menos refinados. Debe representar fielmente la realidad. Un modelo único no suele ser suficiente para modelar un sistema, siendo necesarios varios modelos utilizando diversos puntos de vista. Los modelos deben ser semánticamente consistentes. Por ejemplo, si estamos modelando una casa, los tabiques deben ser los mismos en el plano eléctrico, de la fontanería, calefacción, etc.

el número de métodos se incrementó de menos de 10 a más de 50. HISTORIA DE UML. Se lleva cierto tiempo trabajando ya en la versión 1. 1. 1. esto es. desde el concepto hasta ejecutables.0 en enero de 1997. utiliza modelos gráficos para la representación de sistemas.3 en noviembre de 1999. 1. entre los que destacan: Método de Booch. de Ivar Jacobson.4. Durante este tiempo. enfatizando cada uno de ellos en ciertos aspectos y sin proporcionar ninguno de ellos una solución suficientemente general. Utilizable tanto por personas como por máquinas.Ingeniería del Software-UML 4 UML utiliza modelos orientados a objetos. estos métodos no se adaptaban correctamente al desarrollo de programas orientados a objetos.8 en 1995. con unos atributos y operaciones asociados. 1. físicos. la maqueta de un automóvil es un modelo físico del “sistema” automóvil que podría utilizarse para estudiar su aerodinámica en el túnel de viento. es más fácil entender un recorrido dibujado en un mapa que entender las instrucciones en texto equivalentes). UML es un lenguaje de modelado visual. que interactúan con otros objetos para conseguir conjuntamente satisfacer los objetivos del sistema. De la experiencia acumulada. cuyos objetivos eran: Modelar sistemas. utilizando técnicas orientadas a objetos. los métodos se fueron perfeccionado a la vez que el paradigma orientado a objetos se consolidaba.1 en noviembre de 1997.3. que es un estándar del OMG ( Object Management Group). Es más fácil entender información visual que información no visual (por ejemplo. OOSE (Object Oriented Software Engineering). OMT (Object Modeling Technique). Aunque el nacimiento de los lenguajes orientados a objetos tuvo lugar en los años 70 con la aparición de Smalltalk.2 en junio de 1998 (revisión editorial. fue en los 80 cuando empezó realmente su despegue y expansión. sin cambios significativos a nivel técnico). grande. Éstos eran métodos completos. Un modelo orientado a objetos es una representación de un sistema a partir de los objetos u entidades que lo constituyen. La versión actual de UML es la 1. etc. Por ejemplo. una revisión menor de la actual que aparecerá a corto . de Grady Booch. Existen varios tipos de modelos: gráficos. Paulatinamente. crítico o complejo. pareciéndose cada vez más. de James Rumbaugh. matemáticos. UML utiliza diagramas para representar los modelos. Los métodos de modelado existentes a principios de los 80 estaban adaptados para la construcción de programas en lenguajes pertenecientes al paradigma de la programación estructurada. se iban tomando ideas los unos de los otros. pero cada uno de ellos tenía sus puntos fuertes y débiles. Finalmente. aparecieron nuevas generaciones de métodos. fueron apareciendo versiones: 0. deciden unirse los creadores de dichos métodos (fundando “ Rational Software Corporation”) al objeto de unificar sus métodos. naciendo UML. Según evolucionaban. Durante el período comprendido de 1989 a 1994. ya fuera pequeño. Los seres humanos son criaturas visuales (de ahí el dicho “más vale una imagen que mil palabras”). A mediados de los 80 empezaron a aparecer métodos de modelado orientados a objetos. Sin embargo. Válido para cualquier sistema.

Elementos. De comportamiento. Agrupan elementos y relaciones. un paquete se visualiza como una carpeta. su contenido: Paquete Los elementos de anotación son partes explicativas de los modelos UML. El vocabulario de UML se compone de: Elementos. VISIÓN GENERAL DEUML. Un paquete es un mecanismo conceptual de propósito general para organizar elementos en grupos. incluyendo su nombre y. dentro de un contexto particular. Relaciones. la colaboración. con las anotaciones este texto se ve de forma explícita en el diagrama. de forma que resalta a primera vista. Los elementos estructurales representan partes materiales o conceptuales del sistema. Hay cuatro tipos de elementos: Estructurales. Aunque la mayoría de herramientas del tipo Rose permiten añadir un texto (o incluso un fichero o una dirección web) comentando o documentando cada elemento. y sirven para organizar otros elementos de los modelos UML (pudiendo incluir incluso otros paquetes). Los elementos estructurales principales de UML son la clase. con la publicación de la versión 2. se pueden incluir en un paquete varias clases y luego asignar ese paquete a un componente (con lo que. Son comentarios que se pueden aplicar para describir. para alcanzar un propósito específico) y la máquina de estados (que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos. Ligan elementos entre sí. realmente.0. el caso de uso. junto con sus reacciones a estos eventos). los componentes y los nodos. Gráficamente. lo que estamos asignado al componente son todas las clases que el paquete incluye). De agrupación.Ingeniería del Software-UML 5 plazo (principios del año 2001). Diagramas. De anotación. Mensaje Estado Los elementos de agrupación de UML son los paquetes. Los elementos de comportamiento básico son las interacciones (que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos. clarificar o hacer observaciones sobre cualquier elemento de un modelo. . a veces. Más adelante se verá su representación y significado. la interfaz. Por ejemplo. Se espera una revisión importante del estándar hacia el año 2002. Los elementos de comportamiento son las partes dinámicas de los modelos UML. Son abstracciones de algún componente o aspecto del sistema modelado.

Se representa como una línea discontinua entre el elemento dependiente y el independiente acabada en punta de flecha que señala al elemento independiente (esto es. Gráficamente viene dada por una línea acabada en punta de flecha vacía que va del elemento especializado (el hijo) al general (el padre). Realización. Es la relación que hay entre una especificación y su implementación. Poner ejemplo Gráficamente viene dada por una línea discontinua que acabada en punta de flecha vacía y va del elemento que cumple el contrato al elemento que lo especifica: La relación de dependencia es una relación semántica entre dos elementos. La relación de generalización conecta a elementos vinculados por una relación padre/hijo (generalización/especialización). en la cual un elemento requiere la presencia de otro para su implementación o funcionamiento. Los tipos fundamentales de relaciones son los siguientes: Generalización. Gráficamente se muestra como una línea que conecta ambos elementos (de forma opcional puede también acabar en punta de flecha para indicar la dirección de navegabilidad o incluir ciertos adornos que aumentan su expresividad): La relación de realización es una relación semántica entre clasificadores. Relaciones. Asociación. en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Un cambio en el elemento requerido (el independiente) puede afectar al del otro elemento (el dependiente). Dependencia. el elemento dependiente indica el elemento del que depende): .Ingeniería del Software-UML 6 El símbolo utilizado para una anotación es el siguiente: Aquí se escribe el texto de la nota. La relación de asociación es una relación estructural entre dos elementos.

2. 8. incluyendo las relaciones que pudieran existir entre ellas. El diagrama de objetos muestra un conjunto de objetos y sus relaciones (enla ces) en un instante determinado. 1. agrupables según la siguiente clasificación: - Diagramas de comportamiento (modelan cómo se comporta el sistema). El diagrama de secuencia muestra cómo se mandan mensajes los actores y objetos de un sistema a lo largo del tiempo. El diagrama de casos de uso muestra actores y formas en que ést os pueden utilizar el sistema. Diagrama de secuencia. Es el más común de los diagramas en el modelado de sistemas orientados a objetos. El diagrama de despliegue muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. El diagrama de estados muestra los diferentes estados por los que puede pasar un objeto. Diagrama de objetos. Diagrama de despliegue. Diagrama de estados. Diagrama de clases. Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas. 6. de forma que un diagrama es una proyección de un sistema. Diagramas de interacción (muestran cómo interaccionan entre sí objetos de un sistema).) y las dependencias existentes entre ellos.Ingeniería del Software-UML 7 Diagramas. El diagrama de colaboración muestra las relaciones existentes entre actores y objetos y los mensajes enviados entre ellos. En UML existen nueve tipos de diagramas. Equivale a una instancia de un diagrama de clases (o una parte del mismo) y se utiliza generalmente para documentar estructuras de datos complejas. etc. Diagrama de actividades. 4. El diagrama de actividades muestra el flujo de control entre objetos. Diagramas de implementación (muestran aspectos relacionados con la implementación). El diagrama de clases muestra la estructura de clases de un sistema. Diagrama de componentes 9. 7. Diagrama de colaboración. Diagrama de casos de uso. Para todos los sistemas. un diagrama representa una vista resumida de los elementos que constituyen un sistema. 5. . El diagrama de componentes muestra cómo se organizan los elementos constit uyentes del sistema (código fuente. - Diagramas estructurales (modelan algún aspecto de la estructura del sistema). 3. excepto los más triviales. ejecutables. así como las transiciones y eventos asociadas.

permitiendo añadir nueva información en la especificación de ese elemento. En un diagrama de casos de uso importa qué hace el sistema (qué proporciona). Este estereotipo. Relaciones. Una restricción extiende la semántica de un bloque de construcción de UML. Los nombres de los estereotipos se muestran encerrándolos entre los símbolos « y » 2. ed. se podría mostrar el autor de una determinada clase mediante un valor etiquetado añadido al símbolo que representa la clase: {autor = J. A los símbolos « y » se les denomina guillements y son símbolos simples. el símbolo « no está compuesto de dos símbolos menor seguidos.. Casos de uso. 3 Para más información. Estos mecanismos son: Estereotipos. de forma que los usuarios puedan comprender cómo se utiliza ese elemento y de forma que los desarrolladores puedan implementarlo. permitiendo añadir nuevas reglas o modificar las existentes. Las restricciones se muestran encerrándolas entre llaves. Addison-Wesley (oct. esto es <<. Restricciones. Por ejemplo. no cómo lo hace.Ingeniería del Software-UML 8 MECANISMOS DE EXTENSIBILIDAD . Los diagramas de casos de uso representan la funcionalidad del sistema tal como l a ven los usuarios. podríamos crear el estereotipo «tabla» para representar una tabla. indicaría que nos encontramos ante un nuevo elemento (en este caso. 2000). por ejemplo. se puede consultar el libro “Writing Effective Use Cases”. la restricción {xor} aplicada a un grupo de asociaciones se utiliza para indicar que sólo se debe instanciar una relación de las varias posibles. sino que existe el símbolo especial «. añadido al símbolo de una clase. Por ejemplo. Por ejemplo. En los diagramas de casos de uso se muestran las diferentes formas posibles de utilización de un sistema. Un valor etiquetado extiende las propiedades de un bloque de construcci ón. Cockburn. Valores etiquetados. el estereotipo nos indica que dicho elemento representa una tabla). Esto significa que. 2 . Los valores etiquetados se muestran encerrándolos entre llaves. Los elementos principales que aparecen en los diagramas de casos de uso son: Actores. Un estereotipo extiende el vocabulario de UML. DIAGRAMA DE CASOS DE USO3. Los diagramas de casos de uso permiten visualizar el comportamiento de un sistema. UML proporciona una serie de mecanismos de extensibilidad que permiten aumentar la capacidad expresiva del mismo. permitiendo crear nuevos tipos de bloques de construcción que se deriven de los existentes. Macías}. A.

para obtener los casos de prueba (el sistema obtenido debe proporcionar todas las funcionalidades especificadas en los casos de uso) e incluso como base para la documentación de usuario. los casos de uso (Transferir Fondos. Cambiar PIN. Realizar Pago. Ver Saldos. por último. Son una herramienta muy general que permite . Ayudan a capturar los requerimientos del sistema (que será una cuestión básica para todo el desarrollo posterior). como se puede ver en el ejemplo siguiente: Realizar Llamada Red Telefónica Recibir Llamada Usuario Usar Agenda Teléfono móvil Los diagramas de casos de uso son una herramienta de comunicación efectiva entre clientes y desarrolladores. Empleado de Banca y Sistema de Crédito) que son los agentes externos que interactúan con el cajero automático. y no en las actividades internas que tengan lugar en dicho sistema. Opcionalmente. las relaciones entre actores y casos de uso (las líneas que van entre actores y casos de uso).Ingeniería del Software-UML 9 Veamos. Disponer e Ingresar) que son las funcionalidades que el cajero proporciona y. se puede añadir al diagrama un rectángulo que representa los límites del sistema representado (marca el límite entre el sistema físico objeto del modelado y los actores que interactúan con dicho sistema). para validar el diseño contra ellos. para empezar. Los diagramas de caso de uso se centran en la interacción entre los usuarios y los sistemas. un diagrama de casos de uso para un cajero automático: Transferir Fondos Empleado Banca Ingresar Cambiar PIN Cliente Disponer Realizar Pago Sistema de Crédito Ver Saldos En este diagrama se pueden identificar los actores (Cliente.

etc. otros sistemas que interactúan con el sistema que está siendo modelado y el tiempo: El primer tipo de actor corresponde a personas físicas o usuarios. una misma persona puede desempeñar en un momento dado el rol de empleado de banca (porque sea un empleado del banco) y en otro instante el rol de cliente (ya que además puede ser cliente del banco y usar el cajero para. instancias). que suele requerir varias sesiones. a medianoche el sistema podría realizar un proceso de control del estado del cajero. de pendiendo si participan en las funciones principales del sistema (pertenecientes al ámbito del negocio. Un actor5 es un rol o conjunto homogéneo de roles que un usuario (persona o máquina) desempeña respecto al sistema. pero informal. por ejemplo. Por ejemplo. El segundo tipo de actor es otro sistema. Luis. Son un mecanismo para obtener el consenso en la visión del sistema y sus objetivos entre clientes y desarrolladores. de expresar los requerimientos funcionales. La creación de los diagramas es un proceso de descubrimiento. El tercer tipo de actor es el tiempo.Ingeniería del Software-UML 10 especificar las reglas de un negocio 4. Gráficamente. instancias del actor cliente serían José. ya que lo que realmente representa el elemento UML es un rol (o conjunto homogéneo de roles). que son externos y están fuera de nuestro control (esto es. No están basados en la teoría de orientación a objetos y pueden usarse tanto en procesos de desarrollo orientados a objetos como a desarrollos estructurados u otros. por ejemplo la imagen de un miniordenador o un servidor. además de analistas. un actor se simboliza mediante un hombre “de alambre”. agentes externos al sistema y que interactúan con él. tanto por el cliente como por el desarrollador. a la cual pueden pertenecer uno o más elementos (o. El tiempo es un actor cuando el paso de un cierto tiempo dispara algún evento en el sistema. 5 4 . Fernando. Por ejemplo. - - Representar un actor del tipo sistema externo o tiempo como un hombre de alambre puede resultar poco claro. Los actores se pueden clasificar como primarios o secundarios. figurando debajo de él el nombre: Cliente Un actor representa una clase. es un actor. nos vienen ya dados y es nuestro sistema el que se debe adaptar para comunicarse con ellos). El nombre “actor” con el que se denominó a este elemento en UML no fue acertado. De forma resumida. No se deben usar nombres de personas ya que. y un actor del mundo real puede (y de hecho normalmente lo hace) representar varios roles dispares. sacar dinero). si tomamos por ejemplo el caso del cajero automático. se puede decir que los diagramas de caso de uso: Representan una forma estructurada. como Realizar Llamada en el caso del Las reglas o procesos de negocio son procesos realizados en el seno de una cierta organización o empresa. De forma similar se puede hacer con el tiempo. ACTORES . Una opción mejor puede ser asignar un estereotipo a los sistemas externos (por ejemplo «sistema») y utilizar un nuevo icono para su representación. La creación de los casos de uso necesita de la participación de los usuarios (expertos en e l tema a modelar) para su construcción y validación. de forma equivalente. Hay tres tipos principales de actores: usuarios del sistema. Son. Son fáciles de entender. Nuestro sistema puede interaccionar con otros sistemas. por tanto. Debido a que el tiempo está fuera de nuestro control.

Por ejemplo. Ausencia de uniformidad. pensemos que deseamos modelar el caso de uso consistente en realizar el pedido de un coche en un concesionario. Desde este punto de vista. CASOS DE USO . un caso de uso se representa mediante una elipse. Podríamos suponer que el actor es el vendedor o que el actor es el cliente. Nota: El uso de interfaces humano o automáticos tiene sus pros y sus contras. de forma equivalente .Ingeniería del Software-UML 11 teléfono móvil) o funciones secundarias en el mismo (pertenecientes al ámbito del mantenimiento del sistema. Coste. un caso de uso muestra una forma en la que alguien podría utilizar el sistema. dependiendo de si inician los casos de uso o no. por correo electrónico o vía Web (simplemente. el interface del sistema con el que interactúa el actor. Los casos de uso pueden describir funcionalidades a diferentes niveles: sistema. Por ejemplo. ya que lo que realmente modelamos es una regla del negocio (el cliente es quién encarga el coche). Un caso de uso representa una secuencia de transacciones en un sistema cuyo objetivo es proporcionar un resultado mensurable de valor para el actor del sistema. En el primer caso. Gráficamente. estamos a nivel de abstracción del modelo de sistemas de información. el vendedor no es más que un intermediario. representarían diferentes interfaces para el cliente para realizar una misma tarea: realizar el pedido de un coche). subsistemas y componentes (clases). Un caso de uso representa una funcionalidad que el sistema proporciona o. A la hora de encontrar los actores de un sistema. Inconvenientes Coste. al usar el modelo de negocio dejamos abierta la puerta a diferentes enfoques. como copias de seguridad. Rigidez. tal y como se puede ver en la siguiente tabla: Ventajas Interfaz humano Interfaz automático Flexibilidad (adaptable al actor). se podría optar durante la fase de análisis y diseño que el cliente pudiera encargar el coche tanto personalmente a través del vendedor. Cuando se elige el modelo de sistemas de información estamos especificando ya una enfoque definido. Uniformidad. los casos de uso definirán el comportamiento del elemento . ambos importantes y legítimos. arrancada y parada del sistema o administración de la base de datos). Sin embargo. existen dos enfoques diferentes. A cualquiera de estos niveles. correspondientes a dos niveles de abstracción: el modelo de sistemas de información y el modelo de negocios. por teléfono. estamos a un mayor nivel de abstracción. que indique el objetivo o funcionalidad del caso. ya que modelamos una solución específica organizativa y tecnológica (el vendedor es el encargado de interactuar con el sistema). con el nombre del caso escrito dentro o debajo: Ingresar Para nombrar los casos de uso se utiliza un verbo o una frase que empiece por un verbo activo. En el segundo caso. También es posible clasificarlos como activos o pasivos.

Update. que representa el flujo de eventos para el caso de uso de “obtención de ayuda para un problema específico” de una empresa de ventas: Acciones del usuario 1. los actores que participarán serán en general otras clases o subsistemas. generalmente de forma breve. 3. Seleccionar una opción de ayuda. Los casos de uso se deben documentar. que el cliente no dispusiera de suficiente saldo). ya que está más enfocado al diseño. se recomienda seguir el estilo del siguiente ejemplo. El flujo o flujos alternativos documentan qué ocurre en situaciones variantes o anormales (por ejemplo. . abstractos o ideales). El texto usado en la documentación de los casos de uso debe estar basado en el lenguaje del negocio a modelar. Son las condiciones que se cumplirán después de haber finalizado la ejecución del caso de uso. Read. 6. lo que hace el caso de uso. centándose en las interacciones con la base de datos en lugar de interacciones entre el actor y los sistemas. por tanto. Dicha documentación debe contener una descripción del caso de uso y el flujo de eventos del mismo (la secuencia de acciones. El flujo primario describe la situación normal (debe ser además el primer flujo descrito al crearlo). como los diagramas de actividad o de estado. Delete). Desde este punto de vista. paso a paso. ya sea unos segundos. Las secciones que podrán aparecer en un caso de uso son. Describe. englobando las posibles acciones del usuario y las responsabilidades del sistema durante el desarrollo de la actividad. se puede redefinir caso de uso como “una única actividad discreta. independiente de la tecnología y de la posible implementación.Ingeniería del Software-UML 12 que describen. incluyendo variantes. usar otras técnicas. Describir el problema. a este nivel. que un sistema puede ejecutar interactuando con los actores para proporcionar la funcionalidad indicada en el caso de uso). Flujo de eventos primario (o base) y alternativo(s). 4. Se debe precisar que si se utilizan casos de uso para describir clases. A nivel de subsistemas se suelen tratar con operaciones atómicas o CRUD ( Create. Son las condiciones que se deben cumplir antes de poder utilizar el caso de uso. a diferencia de los anteriores (esenciales. 5. puede incluir precondiciones y/o postcondiciones. Ofrecer posibles soluciones. Si se utiliza texto para especificar el flujo de eventos. Se debe tener en cuenta que. por tanto: Descripción. completa. Este nivel suele ser poco útil para los clientes. Postcondiciones. además de texto. ya que podría restringir las soluciones a tomar. un caso de uso puede tener una duración finita cualquiera. El flujo de eventos describe. varios días o incluso meses. Pertenece al nivel de abstracción del negocio. Identificación como cliente. El nivel más importante es el que describe las funcionalidades del sistema. Pedir descripción del problema. usando un lenguaje perteneciente al dominio de la aplicación y. Opcionalmente. significativa y bien definida de interés para un usuario externo que desempeña un rol o roles específicos con relación al sistema. descritas de una forma abstracta. fácilmente entendible por los usuarios”. A este tipo de casos de uso se les denomina a veces como reales. Para especificar flujos de eventos se puede. Precondiciones. Presentación de las opciones de ayuda. Se les denomina casos esenciales o abstractos. y es útil tanto para clientes como desarrolladores. lo que sucede en el caso de uso (no cómo sucede). Responsabilidades del sistema 2. sin revelar su estructura interna. No se recomienda detallar excesivamente ni utilizar pseudocódigo para especificar el flujo de eventos.

Gráficamente es una línea. Por ejemplo: Cliente Realizar Pago Sistema de Crédito En este caso. siendo el actor quien inicia la comunicación. Relación de comunicación. la flecha va de “A” a “B”) indica que el caso de uso “A” contiene el comportamiento indicado por “B”. Relación de inclusión6. Esta factorización permite especificar de una sola vez un comportamiento común a varios casos de uso. sin embargo su nombre se cambio por la de incluye (include) ya que el anterior nombre daba a entender una semántica que no se correspondía con la real.Ingeniería del Software-UML 13 RELACIONES . 6 . Todos los casos de uso deben ser iniciados por un actor (a excepción de los casos de uso que extienden el comportamiento o están incluidos en otro caso de uso. Hay cuatro tipos de relaciones que pueden aparecer en un diagrama de casos de uso. Es el tipo más normal de relaciones y tiene lugar entre un caso de uso y un actor. el actor “Cliente” se comunica con el caso de uso “Realizar Pago”. La relación de inclusión se muestra gráficamente como una relación de dependencia con el estereotipo «include». a la que se puede añadir una punta de flecha para indicar quién inicia la comunicación. el caso de uso “Realizar Pago” se comunica con el actor “Sistema de Crédito”. El lugar o lugares donde dicho comportamiento se incluye debe especificarse en el flujo de eventos de “A”. En versiones anteriores de UML a esta relación se le denominaba de uso (uses). tal y como se verá más adelante). Por ejemplo: «include» Disponer Autentificar Cliente «include» Realizar Pago En este fragmento se puede ver que tanto el caso de uso “Disponer” como “Realizar Pago” incluyen el caso de uso “Autentificar Cliente”. Además. La relación de inclusión en un caso de uso “A” de caso de uso “B” (esto es.

Entre actores: La relación de generalización entre actores se utiliza cuando varios actores tienen características comunes. La relación de inclusión se muestra gráficamente como una relación de dependencia con el estereotipo «extend». Gráficamente se muestra como una relación de generalización que va del actor especializado al genérico. sujeto a determinadas condiciones. posiblemente. Puede ser entre actores o entre casos de uso. por ejemplo: Usuario Usuario Tarjeta Usuario Contrato Una generalización de un actor “A” (descendiente) a un actor “B” (ancestro) indica que una instancia de “A” puede comunicarse con los mismos casos de uso que un actor “B”. de manera que visualmente se puedan apreciar de una forma más fácil en qué consiste dicho caso. un “Usuario Tarjeta” (o un “Usuario Contrato”) podría comunicarse con los mismos casos de uso que un “Usuario” y. sin tener que consultar la descripción del mismo. por alguna razón. La relación de inclusión indica que un caso de uso va a usar siempre la funcionalidad pro porcionada por otro caso. Esto ocurriría cuando solicitáramos. llamar a cobro revertido Relación de generalización. Para los usuarios del teléfono móvil podríamos representar. Para el caso del ejemplo.Ingeniería del Software-UML 14 Las relaciones de inclusión también se pueden utilizar para detallar un caso de uso complejo que proporcione varias subfuncionalidades. que pueden ser especificadas en la extensión o en el caso de uso. . con otros particulares a él (por ejemplo. la funcionalidad “Llamada a Cob ro Revertido” extiende la funcionalidad “Realizar Llamada”. Una relación de extensión de un caso de uso “A” a un caso de uso “B” indica que comportamiento del caso de uso “B” puede ser incrementado con el comportamiento del caso de uso “A”. Por ejemplo: «extend» Solicitar cobro revertido Realizar Llamada Llamada a Cobro Revertido En este ejemplo. un “Usuario Tarjeta” podría comunicarse con el caso de uso “Recarga Tarjeta”). Relación de extensión.

Por ejemplo: Consultar Habitaciones Libres por Categoría Consultar Habitaciones Este tipo de relación se utiliza poco y no se debe abusar de ella. Un caso de uso representa una funcionalidad o un modo de utilizar el sistema. No modelar la comunicación entre actores. Para capturar otro tipo de requerimientos o detallarlos. Es importante evitar personas con pensamiento “lineal” (al estilo de los programadores). ya que está fuera del ámbito del sistema 7. ya que aparecerían demasiados casos. Entre casos de uso: La relación de generalización entre c asos de uso se utiliza para indicar que un caso de uso es un refinamiento de otro. los nombres de los casos de uso. Además. No dibujar flechas entre casos de uso. ya que de otro modo no será implementado. se deben usar otras técnicas. excepto para relaciones de inclusión. El sistema no existe para leer/escribir en una base de datos.Ingeniería del Software-UML 15 Se deben de usar las relaciones de generalizació n entre actores cuando algunos actores tengan en común parte de sus comportamientos o cuando interese mostrar explícitamente que cualquier especialización de un tipo de actor actúa de igual forma. Es importante que cualquier requerimiento funcional aparezca al menos en un caso de uso. un caso de uso puede representar la introducción de una información y otro caso de uso el acceso a la misma. existe para producir un resultado de valor mensurable para los actores. Los diagramas de casos de uso sólo pueden capturar requerimientos funcionales. personas que intentan describir todos y cada uno de los pasos y detalles. actores y descripciones deben ser significativos para el cliente (deben pertenecer al lenguaje del negocio y la organización del cliente). Se deben considerar también casos de uso relacionados con el mantenimiento del sistema. a un nivel muy fino y dificultarían su entendimiento por el cliente. pero no indica el cómo se implementa esa funcionalidad. tanto a los desarrolladores como a los clientes (para casos de uso abstracto). sin que exista ninguna comunicación entre ambos casos. No se debe representar el flujo de información entre casos de uso. es decir. Por tanto. NORMAS PARA CREACIÓN DE UN DIAGRAMA DE CASOS DE USO . Los diagramas de casos de uso deben proporcionar fácilmente una visión de lo que el sistema proporciona. Se debe usar un número de diagramas adecuado (dependiendo de la complejidad del sistema) con un número de casos de uso razonable y dependiendo del nivel de detalle de dicha vista en particular. No se debe partir del nivel CRUD. - - - - 7 Para modelar el modo en que las tareas se llevan a cabo en una empresa se podrían utilizar diagramas de flujo de trabajo (workflow diagram). Todo caso de uso debe ser iniciado por un actor (excepto los casos de uso incluidos o las extensiones). . extensión o generalización. Se debe elegir con cuidado las personas participantes en su creación. y a un nivel relativamente alto.

Se ha añadido la multiplicidad en las relaciones de comunicación. Véase que se ha optado por modelar a nivel de sistema de información (aparece el actor “vendedor” y no el actor “cliente”). se supondrá que el cliente sólo se identifica una vez (representado por el caso de uso “Validar usuario”). El supervisor es el único que puede proporcionar crédito. En el ejemplo se puede ver una forma de utilización de las notas. Aportar Datos Cliente Tomar Productos Aportar Forma Pago «include» «include» «include» 1 Vendedor n Tomar Pedido «extend» Pedir Catálogo 1 Supervisor n Proporcionar Crédito El catálogo se enviará al servir el pedido. . porque esta situación hace caer en el cómo. una pequeña descomposición de los casos puede hacerlos más fáciles de comprender y simplificar su diseño. Notas: El supervisor es una especialización de vendedor. Se debe cuidar la granularidad. si se diera esta situación. Sin embargo. - EJEMPLO DE LA DOCUMENTACIÓN DE UN CASO DE USO . ya que en vez de las reglas del negocio (el qué) podemos estar dando directamente una solución basada en el sistema existente. y después podrá hacer una o más operaciones sin necesidad de volver a identificarse. La condición para la extensión “Pedir Catálogo” estará definida en el caso de uso “Tomar Pedido” (no se ha mostrado en el diagrama). ya que es una especialización de éste. - EJEMPLO DE UN DIAGRAMA DE CASOS DE USO . se dará la documentación (resumida) del caso de uso “Sacar” perteneciente al modelo de casos de uso de un sistema de cajeros automáticos. pero también puede tomar pedidos como cualquier otro vendedor. Para hacerlo más real. Los casos de uso abstracto deben capturar lo esencial y no intentar detallar demasiado. que pudiera no ser lo suficientemente buena o flexible. A continuación.Ingeniería del Software-UML 16 - Se debe evitar crear los casos de uso basándose exclusivamente en la interfaz del sistema de información que ya existiera.

se indica y se vuelve al paso 2. 3. Verificar PIN. queda reflejada en la cuenta del usuario. Se pasa al paso 7. La descripción de un conjunto de objetos que comparten los mismos atributos. 4. Introducir PIN. Pedir PIN. Se vuelve al paso 2. Definiciones previas. . Muestra opciones. el usuario cancela la operación. Visualizar la cantidad. Muestra las opciones. el usuario indica que la cantidad es errónea. . 6. Responsabilidades del sistema . Objeto: Clase: Atributo: Es una entidad con límites definidos e identidad propia que encapsula un estado y un comportamiento. Responsabilidades del sistema La documentación del caso de uso “Sacar” sería la siguiente: . Introduce la cantidad.Flujo de eventos principal: Acciones del usuario 1. Un objeto es una instancia de una clase.Flujos alternativos: En el paso 2.Ingeniería del Software-UML 17 Nota: El flujo de eventos primario del caso de uso “Validar usuario” sería: Acciones del usuario 1. 4.Precondiciones: El usuario se ha validado contra el sistema mediante “Validar usuario”. 5. . métodos y semántica. En el paso 5. 7. Selecciona opción sacar dinero. Leer la tarjeta. Confirmar la cantidad 6. Dispensar el efectivo. operaciones. 3.Descripción: Permite al cliente obtener una cierta cantidad de dinero en efectivo del cajero automático. Insertar tarjeta en el cajero 2. si no es posible proporcionar la cantidad requerida.Postcondición: La operación. 5. En el paso 6. Característica que describe el rango de valores que una instancia de una clase puede almacenar. DIAGRAMAS DE INTERACCIÓN. Preguntar la cantidad. 2. si finaliza con éxito. .

Solicitud de una operación determinada a un objeto concreto. : Persona Objeto anónimo de la clase Persona. luis : Persona Objeto de nombre luis perteneciente a la clase Persona. Ambos diagramas son prácticamente equivalentes entre sí. subrayado. tal y como se verá más adelante. ya que la información subyacente en la que se basan es la misma. Esp ecifica el algoritmo o procedimiento asociado con una operación. . o ambos: Por ejemplo: ana Objeto de nombre ana (no se especifica explícitamente la clase a la que pertenece). el nombre del objeto (empezando por letra minúscula). Un objeto se representa gráficamente como un rectángulo. así como de los mensajes que se envían entre ellos. estando la diferencia en que en el diagrama de secuencia lo que se destaca es la ordenación temporal de los mensajes mientras en los diagramas de colaboración lo que se destaca es la organización estructural de los objetos que envían y reciben mensajes. Notación para la representación de objetos. aspectos dinámicos del sistema. Modelan. Un diagrama de interacción consta de un conjunto de objetos y sus relaciones (ya sea de forma implícita o explícita). por tanto. También puede incluirse una sección en la que se mues tren los valores de uno o más atributos.Ingeniería del Software-UML 18 Operación: Es un servicio que puede ser solicitado a un objeto para que se comporte de una determinada forma. tal y como se puede ver en el ejemplo siguiente: Oscar : Persona Nombre: String = “Oscar” dni: Integer = 3102427 telefono = 91 555 00 00 Los diagramas de interacción muestran cómo cooperan (interaccionan) un conjunto de objetos para realizar alguna tarea determinada. Método: Mensaje: La implementación de una operación. convendrá usar uno u otro. Hay dos clases de diagramas de interacción: el diagrama de secuencia y el diagrama de colaboración. dentro del cual se incluye. o la clase (empezando por letra mayúscula) a la que pertenece precedida de dos puntos. Dependiendo de la misión principal a la que se destine el diagrama.

estos sustantivos se corresponderán con actores. Para que esto sea posible. que realizan la tarea de interface entre el usuario y el sistema. Un escenario es.Ingeniería del Software-UML 19 Una de las aplicaciones más importantes de los diagramas de interacción consiste en el modelado de escenarios. Un escenario es una secuencia específica de acciones entre objetos que permite mostrar un comportamiento. esta técnica no permite descubrir todos los objetos. como formularios e informes. Una de ellas consiste en analizar los sustantivos que aparezcan en los flujos de eventos o en escenarios específicos. flujo alternativo 1. una instancia de un flujo de eventos particular de un caso de uso. flujo alternativo 2. durante el tiempo o parte del tiempo en que se desarrolla una determinada tarea o flujo de eventos). Esto permite representar en los diagramas de interacción agrupaciones de objetos como. es necesario encontrar los objetos que participan. flujo principal. Es la opción por defecto.Simple: El mensaje se ejecuta en un hilo simple de control. los mensajes que se mandan a las agrupaciones de objetos constan de una búsqueda más una operación que se requiere al objeto (o subconjunto de objetos) encontrado. También puede ser necesario añadir objetos de entrada/salida. por ejemplo. estático (static) o transitorio (transient): Persistente: Aquel cuya vida continúa aunque el programa haya terminado. se pueden mostrar en UML regruesando sus bordes para diferenciarlos del resto de objetos. Esto es debido a que se trata de un objeto compartido por varios hilos de control o procesos. Cuando se vuelva a ejecutar el programa. Gráficamente se representa como: 8 Este tipo de objetos. . Sin embargo. Cada diagrama de interacción que represente un escenario debe tener al menos un objeto actor iniciante.) se suelen agrupar en un paquete. A la hora de construir un diagrama de interacción. Estático: Es aquel que reside en memoria hasta que el programa termina. el estado del objeto dependerá del estado que tuviera al terminar la ejecución anterior. por lo que el objeto al que va destinado el mensaje siempre lo aceptará y de forma inmediata. debe ser guardado en un fichero o una base de datos (almacenamiento permanente) al terminar una ejecución y recuperado al empezar la siguiente. Transitorio: Aquel que permanece en memoria por un espacio de tiempo limitado (por ejemplo. Habrá posiblemente que añadir objetos cuya tarea sea controlar 8 a los otros objetos (controlan el desarrollo de los acontecimientos). listas de objetos. por tanto. En Rose. - El estándar también proporciona un símbolo para múltiples instancias de un objeto. un objeto se puede calificar (a través de sus especificaciones) como persistentes ( persistent). que es el estímulo externo que ejecuta alguna funcionalidad. Existen varias técnicas para encontrar objetos. atributos u objetos (serán objetos si exhiben un comportamiento). En general. Rose permite especificar cinco semánticas diferentes de sincronización de mensajes: . Este objeto actor será una instancia de un actor perteneciente al diagrama de casos de uso al que pertenece el flujo de eventos. En general. los pasivos. Varios diagramas de interacción representando escenarios pertenecientes a distintos flujos de eventos de un mismo caso de uso (por ejemplo. La notación es la siguiente (este icono sólo puede aparecer en el diagrama de colaboración): : Persona Para modelar los mensajes. denominados objetos activos. a los que se añadirán a continuación los mensajes que se envían. etc.

. es posible documentar en las especificaciones de un caso de uso los diagramas relacionados con dicho caso (ya sean de interacción. la persistencia indicada en los diagramas de interacción debe ser compatible con la persistencia indicada en los diagramas de clase. todo objeto de un diagrama de interacción deberá ser mapeado en algún momento a una clase del diagrama de clases. Gráficamente se representa como: Rose también permite especificar la frecuencia de los mensajes. el cliente abandona el mensaje. si en un diagrama de interacción se representa un mensaje de un objeto a al objeto b. es posible pasar de uno a otro automáticamente. actividad o clases). Se debe tener en cuenta que. las relaciones entre clases y las operaciones y responsabilidades de cada clase. el objeto b debe tener una operación. Los diagramas de interacción constituyen una piedra angular en el diseño. Para que el diseño sea consistente. calificándolos como aperiódicos (mandados en un instante cualquiera de forma única o sin una periodicidad. ya que a través de ellos los desarrolladores pueden determinar las clases que necesitan (aquellas a las que pertenecen los objetos que aparecen en ellos). un objeto de dicha clase podrá calificarse como estático o transitorio en el diagrama de interacción. se está asignando una responsabilidad al objeto que lo recibe.Síncrono: El objeto cliente manda el mensaje y espera hasta que el objeto al que va destinado acepta el mensaje. al poner un mensaje en un diagrama de interacción. Al ser semánticamente equivalentes los diagramas de secuencia y los de colaboración. Por ejemplo. Si el objeto destino no está disponible para recibir el mensaje durante ese periodo. debiéndose cumplir en Rose lo siguiente: Si la clase se define como persistente en el diagrama de clases.Ingeniería del Software-UML 20 . Gráficamente se representa como: . En Rose. estado.txt que se le ha pasado como parámetro). así como todo mensaje deberá ser mapeado a una operación (método) de la clase que recibe el mensaje.Asíncrono: El cliente manda el mensaje y continua sin esperar confirmación de si el mensaje ha sido recibido. que normalmente se implementará con un método denominado imprimir. para lo cual deberá disponer del método adecuado. por ejemplo.Tiempo límite (timeout): El cliente manda el mensaje y espera como máximo una determinada cantidad de tiempo. un objeto de dicha clase podrá calificarse como transitorio. Gráficamente se representa como: . es la opción por defecto) o periódicos (aquellos que son enviados a intervalos regulares). Gráficamente se representa como: . estático o persistente en el diagrama de interacción. Por ejemplo. que trate dicho mensaje (en este caso el comportamiento de b podría consistir en imprimir el fichero hola. Supongamos.txt) al objeto b. Si la clase se define como transitoria en el diagrama de clases. Además.Rechazable (balking): El cliente manda el mensaje y si el objeto al que va destinado no lo acepta. es responsabilidad del objeto b aceptar el mensaje y obrar en consecuencia. en Rose basta crear uno de ellos y pulsando la tecla [F5] generará el otro. que a manda el mensaje imprimir(hola. el cliente abandona el mensaje.

Usualmente. De cada objeto parte una línea discon tinua. En el otro eje se muestran los objetos que participan en la interacción. en el cual el cliente Luis se identifica ante el cajero automático con su número secreto (el 4567): Obsérvese en el diagrama que el mensaje leerNumTarjeta() es un mensaje que el objeto lector se envía a sí mismo (mensaje reflexivo).Ingeniería del Software-UML 21 DIAGRAMA DE SECUENCIA. Los mensajes parten de la línea de vida del objeto que lo envía hasta la línea de vida del objeto al que va destinado (excepto en el caso del mensaje de creación. Generalmente. llamada línea de la vida. siendo el primero de ellos el actor que inicia la ejecución de la secuencia modelada. Cada mensaje lleva un número de secuencia creciente con el tiempo y el nombre de la operación requerida. transcurriendo éste de arriba a abajo. Si el objeto existe durante toda la interacción. el eje vertical es el eje del tiempo. . como se verá más adelante). así como posibles argumentos que pueden utilizarse como valores de entrada y/o salida. Por ejemplo. aunque podría hacerse para interacciones que modelen escenarios en tiempo real. no se especifica una graduación en el eje del tiempo. que representa la vida del objeto durante la interacción. Consta de dos ejes. Un diagrama de secuencia es un tipo de diagrama de interacción en el cual se destaca el tiempo: los mensajes entre objetos vienen ordenados explícitamente por el instante en que se envían. vamos a modelar un escenario que muestre una instancia del flujo de eventos primario del caso de uso “Validar usuario”. éste aparecerá en el eje horizontal y su línea llegará hasta el final del diagrama de secuencia.

Un objeto se destruye mediante un mensaje de estereotipo «destroy». mientras que objetoE es creado y continua existiendo al final del diagrama (al igual que objetoA). el tiempo durante el cual está realizando una acción directa o indirectamente). el siguiente fragmento simplificado: objeto1 objeto2 objeto3 1: mensaje1 2: mensaje2 . aunque objetoB es destruido. por ejemplo. Responsabilidades del sistema Un objeto se crea mediante un mensaje de estereotipo «create» que apunta al objeto que se crea. Leer la tarjeta. objetoC es creado y destruido durante la interacción. Introducir PIN. Pedir PIN. dando finalizada la línea de vida con un aspa. 6. 5. 4. Verificar PIN. Por otro lado. que es un pequeño rectángulo puesto sobre la línea de la vida que indica qué objeto tiene el control en cada momento (esto es.Ingeniería del Software-UML 22 Nota: Se recuerda que el flujo de eventos primario del caso de uso “Validar usuario” era: Acciones del usuario 1. Muestra las opciones. Opcionalmente. En este diagrama de secuencia simplificado se pueden ver varios ejemplos de creación y destrucción de objetos: juan : Cliente objetoA objetoB «destroy» «create objetoC «destroy» «create objetoE Apréciese que objetoA y objetoB existen ya cuando empieza el diagrama. se puede mostrar en los diagramas de secuencia el foco de control. por lo que su línea de la vida está interrumpida en el punto de su destrucción. 3. Insertar tarjeta en el cajero 2. Véase.

teniendo también control el objeto3 desde que recibe el mensaje hasta que finaliza el servicio requerido. que indica que se mandará el mensaje sólo si la condición se cumple. Sin embargo. en el diagrama de secuencia visto anteriormente para validar usuario se debería de refinar e incluir un objeto que fuera el que controlara todo el proceso en vez de ser un objeto : Pantalla Cajero el que se encargue de la mayoría del control.Ingeniería del Software-UML 23 En este ejemplo. manda un mensaje (mensaje1) al objeto2 para requerirle una cierta operación. se suelen refinar añadiendo detalles de diseño que serán útiles a los desarrolladores. para lo cual le envía el mensaje2. Un ejemplo de script sería: objeto1 objeto2 IF (condicion= TRUE) THEN 1: mensaje1 ELSE 2: mensaje2 En este ejemplo. los diagramas de secuencia están pensados para mostrar un único escenario. sólo es necesario realizar cambios en la clase encargada de las transacciones. Además. A partir de ese momento. si se cumple condicion=TRUE. objeto1 tiene el control al empezar. si x es mayor que cero). esto es. Téngase en cuenta que para el caso de un sólo hilo de ejecución. ya que puede complicar en demasía el diagrama. Esto es así porque el objeto : Pantalla Cajero es un interface y no conviene que los interfaces se encarguen del control ya que se volverían muy complicados y heterogéneos. en principio. este tipo de clases suelen ser fácilmente reutilizables. . o cuando se debe esperar la terminación de la operación solicitada por un mensaje para continuar. el que un objeto tenga el foco de control no significa que se esté “ejecutando” realmente código de dicho objeto durante todo el tiempo de control (ya que puede estar esperando que termine alguna operación que haya requerido de algún otro objeto). De forma similar. De igual forma. objeto1 mandará mensaje1 a objeto2. Aunque Rose no lo soporta. si la lógica de la base de datos cambia. le mandará mensaje2. Aunque. REFINAMIENTO . una vez que los clientes h an dado su visto bueno a los mismos. Por ejemplo. y si no se cumple. En un momento determinado. También permite desdoblar la línea de vida de un objeto en varias para mostrar flujos alternativos. se suelen crear objetos que manejen transacciones. Rose permite mediante los Scritps modelar varios flujos simultáneamente. aunque no se debe abusar de esta posibilidad. De esta forma. Para realizar la operación. objeto2 necesita un servicio de objeto3. objeto2 tiene también el control. y serían muy sensibles a los cambios. el control de objeto2 finaliza al terminar el servicio que le había requerido objeto1. de forma que se separe la lógica de la aplicación de la lógica de la base de datos. UML permite añadir la condición delante del mensaje (como por ejemplo [x>0] mensaje. Los diagramas de secuencia permiten mostrar escenarios de forma que sean comprensibles tanto por clientes como por desarrolladores.

valorar el impacto que supondría un cambio en una clase. Un diagrama de colaboración es un diagrama que muestra una interacción en el cual se destaca la organización estructural de los objetos que envían y reciben mensajes. por ejemplo. aquí se muestra un flujo de datos correspondientes a argumentos de entrada del mensajeA que objeto1 envía a objeto2: 1: mensajeA() objeto1 objeto2 En general. se trata de un valor de retorno. Por ejemplo.Ingeniería del Software-UML 24 DIAGRAMA DE COLABORACIÓN. y es que en los de colaboración se pueden añadir explícitamente flujos de datos. sólo se utiliza esta técnica cuando el flujo de datos es grande. como por eje mplo cuando se pasa una lista. Si la dirección del flujo coincide con la del mensaje. los mensajes que se intercambian y las relaciones de comunicación que hay entre ellos (para que un objeto pueda comunicarse con otro debe existir algún tipo de enlace o link entre ellos). no es fácil seguir la secuencia de los mismos. Hay una diferencia significativa entre los diagramas de secuencia y los de colaboración. Esto se hace mostrando al lado del mensaje afectado un circulo al que se añade una flecha indicando la dirección del flujo. Como ejemplo. . aunque aquí también aparece el orden de los mensajes. se trata de un argumento de entrada. Un diagrama de colaboración muestra los objetos que intervienen en una relación. Si no coincide. lo que les hace muy útiles para los desarrolladores. Sin embargo se ve claramente qué objetos participan y las relaciones que existen entre ellos. Estos diagramas permiten. el diagrama de colaboración equivalente al de secuencia visto en el apartado anterior es el siguiente: 2: leerNumTarjeta( ) 1: aceptarTarjeta( ) lector : Lector Tarjeta luis : Cliente 5: introducirPin(4567) 3: inicializarPantalla() 4: pedirPIN() 7: mostrarOperaciones() 6: verificarPIN(4567) : Pantalla Cajero cuentaDeLuis : Cuenta Apréciese que.

Un estado es una situación particular en la que se exhibe un comportamiento determinado y que está caracterizado por el valor de uno o más atributos y/o por las relaciones con otros objetos. siendo candidatos. Esto sucede con los objetos reactivos. que son aquellos cuyo comportamiento viene dirigido por los eventos que recibe. y en cada uno de estos estados tendría un comportamiento diferente. Para encontrar clases con un comportamiento dinámico significativo. lo que aparece es una L en el extremo del enlace). El estado en que se encuentre un objeto será por tanto dependiente de su historia anterior. los diagramas de estado resultan de gran utilidad para los desarrolladores. esto es. . como por ejemplo pulsar la tecla “Parar” cuando se encuentra en el estado transmitiendo. Los diagramas de estado sólo se suelen realizar para objetos (clases) que tienen un comportamiento dinámico significativo. Por ejemplo: 1: create() 2: mensajeA() 3: destroy() objeto1 objeto2 {transient} L En este caso. transmitiendo o recibiendo. También se deben analizar las clases que participen en relaciones en las que aparezca en número cero en la multiplicidad. para aquellos que poseen un conjunto significativo de estados. un objeto de tipo fax podría encontrarse en los estados inactivo. como por ejemplo «local». objeto2 es accesible a objeto1 por ser local a objeto1 (nótese que en Rose. si un objeto persona tiene una relación con una o más compañías significará que es un empleado. podría estar parado. Un evento. siendo creado y destruido en la interacción (como de hecho se puede comprobar por los mensajes que se le envían). si no tiene ninguna relación. las clases que tengan un atributo llamado estado. Esto significa que dicha relación es opcional y puede que el comportamiento en ese caso sea muy diferente. DIAGRAMA DE ESTADOS. Sin embargo. haría que pasara al estado inactivo. {destroy} si son destruidos o {transient} si son creados y destruidos durante la interacción. Un diagrama de estados muestra el ciclo de vida de un objeto (aunque también se puede utilizar para sistemas o subsistemas) desde el momento en que el objeto es creado al momento de su destrucción. En estos casos. se puede buscar en primer lugar aquellos objetos que se comporten de forma diferente según los valores de sus atributos.Ingeniería del Software-UML 25 En los diagramas de colaboración también se pueden asociar estereotipos a los roles de los enlaces. También se pueden añadir restricciones a los objetos que indiquen su persistencia: {new} si son creados durante la interacción. por ejemplo. Por ejemplo. en una relación entre persona y compañía para la que trabaja. Por ejemplo. que es una restricción que especifica que el objeto al que califica es visible por ser una variable local al objeto que manda el mensaje. El objeto2 es además transitorio. jubilado o incapacitado. Describe todas las secuencias de estados y acciones por las que un objeto puede pasar durante su vida como reacción a distintos eventos (como pueden ser los mensajes o señales). en vez de aparecer el estereotipo «local».

Mientras un objeto está en un estado particular. Un estado una situación en la vida de un objeto durante la cual se satisface alguna condición. Dicho de otra forma. Las transiciones. . La etiqueta de acción identifica las circunstancias o eventos bajo los cuales la expresión de la acción será invocada. exit: Indica que la tarea se realiza cuando el objeto abandona el estado. una o más acciones internas. aunque es opcional y se pueden utilizar estados anónimos. este podría ser el diagrama de estados de un objeto de la clase Curso: Abierto cancelar Cancelado fin periodo matrícula cancelar Cerrado fin cuatrimestre Completado ESTADO. Estas acciones se muestran en una sección debajo del nombre del estado. Por ejemplo: NombreEstado Dentro del estado (o adjunto en el extremo sup erior izquierdo en ciertas ocasiones) se puede escribir el nombre del estado. se realiza alguna actividad o se espera algún evento. Se considera una acción no interrumpible.Ingeniería del Software-UML 26 En un diagrama de estados aparecen uno o más estados relacionados entre sí por transiciones. realiza dicha acción (después de realizar la acción de entrada si la hubiera) hasta que ésta termina o hasta que se abandona dicho estado por la llegada de un evento adecuado. en general. Se considera una acción interrumpible. puede realizar cero. Se considera una acción no interrumpible. En este contexto. serán ocasionadas por algún evento. Existen algunas etiquetas de acción reservadas para propósitos especiales y que no pueden ser utilizadas como nombres de eventos. cuando un objeto está en un estado que contiene una acción etiquetada con do. Un estado se representa gráficamente como un rectángulo redondeado. una acción es una tarea que tiene lugar mientras un objeto se encuentra en un determinado estado. Por ejemplo. Estas son: entry: Indica que la tarea se realiza cuando el objeto entra en dicho estado. do: Indica que la tarea se realiza mientras el objeto permanezca en el estado en que se encuentra o hasta que termine dicha tarea. con el formato etiquetaDeAcción/expresiónDeAcción.

se requiere al objeto ayuda que muestre la ayuda sobre el password). Es un pseudoestado que representa el estado en que se encuentra un objeto cuando es creado (inicio de la vida del mismo). El resto de las etiquetas se ajustan al siguiente formato: nombreEvento (listaDeParámetros) [condiciónDeGuarda] .Ingeniería del Software-UML 27 include. La sintaxis general es: ^objeto. pero puede suponerse que esto ocurre al pulsar el usuario la tecla [enter] (este sería el evento que produciría el cambio de estado). Gráficamente se representa: . el objeto recibirá el evento Ayuda. Estado inicial. siendo los argumentos optativos. el objeto manda el mensaje mostrarAyuda al objeto ayuda. Por ejemplo (nótese que Rose añade a las etiquetas no predefinidas la palabra event): LeyendoPassword entry/ poner el eco invisible exit/ poner eco normal event carácter(c)/ tratar carácter (c) event Ayuda/ ^ayuda. Si el usuario pulsara la tecla definida como ayuda. Después. La forma de salir de este estado no se ha especificado. En primer lugar.mostrarAyuda(password) Como se puede ver. al entrar (entry) se eliminaría el eco para evitar que los caracteres tecleados sean visibles. Estados especiales. el usuario introduce un carácter c) se realiza el tratamiento de dicho carácter (esto es. se añadirá a una cadena para ir formando el password que se teclee). Es un pseudoestado que indica la destrucción del objeto (finalización de la vida del mismo). Debe aparecer obligatoriamente uno y sólo uno en todo diagrama de estados. el estado LeyendoPassword contiene una serie de acciones. Al salir de este estado (exit) se vuelve a poner el eco para que se puedan ver los caracteres tecleados. En ese caso. En este ejemplo se ha visto cómo especific ar desde un objeto el envío de un mensaje. siendo la lista de parámetros y la condición de guarda (condición que se debe satisfacer para que se produzca la acción si se recibe el evento) opcionales. Gráficamente se representa: Estado final. con el argumento password (esto es. si se recibe un evento carácter (esto es.mensaje(argumentos) . No se verá aquí. Es opcional y se pueden añadir varios estados de fin para simplificar el diagrama y evitar el cruce de líneas.

La acción es un comportamiento no interrumpible que ocurre como parte de la transición. el estado origen y el estado destino pueden coincidir. significa que la transición ocurre inmediatamente después de satisfechas las posibles acciones entry. ya que otras transiciones al estado destino pueden requerir otras acciones (o ninguna). pasando al estado inactivo. debe cumplirse para que la transición sea posible. el robot se pone en movimiento (acción entry) siempre y cuando no esté tocando el muro (condición de guarda de la transición). es decir. La condición de guarda. Si. Nótese que no siempre es posible sustituir esta acción por una acción interna entry en el estado destino. siendo opcionales todos los componentes. En el estado inactivo puede recibir el .Ingeniería del Software-UML 28 TRANSICIÓN . Si estamos en movimiento y pulsamos el botón de paro (evento paro) el robot se para (acción exit) y pasa al estado inactivo. En caso de no indicarse evento. el siguiente diagrama de estados modela el comportamiento de un robot: girar( grados ) / realizarGiro(grados) Inactivo sensorMuro / pitidoAlarma paro Movimiento entry/ motorOn exit/ motorOff avance[ noTocandoMuro ] Si partimos del robot en estado inactivo y pulsamos el botón de avance (evento avance). por otro lado. El formato general de estas especificaciones es: evento(listaDeParámetros) [condiciónDeGuarda] / acción . el robot se para y además suena un pitido de alarma. tal y como se muestra a continuación: Las transiciones pueden incluir especificaciones que indiquen cuándo ocurre la trans ición o qué acciones se llevarán durante la transición. Por ejemplo. si se especifica. do y exit del estado. Se muestra gráficamente como una flecha que va del estado origen al estado destino: EstadoOrigen EstadoDestino Este movimiento puede ser reflexivo. Un evento es un suceso que ocurre y que puede causar la transición de un estado a otro. Una transición es el paso de un estado a otro. estando en movimiento se activa el sensor de muro.

si todos sus subestados responden a una misma transición. llegan o parten de los subestados. Para modelar esta posibilidad. que englobe a los subestados Abierto y Cerrado.Ingeniería del Software-UML 29 evento girar que haga que gire un número determinado de grados. podemos definir un nuevo estado. A su vez. en el caso de que existan varias regiones o barras de sincronización. Por ejemplo. Si tomamos el ejemplo del diagrama de estados de un curso dado al inicio. Estos subestados pueden ser disjuntos o. se utilizan estados con memoria. concurrentes. haciéndolo más sencillo. ESTADOS ANIDADOS . y agrupar sus transiciones cancelar en una única transición que parte del estado Activo: Activo Abierto fin periodo matrícula Cerrado fin cuatrimestre cancelar Completado Cancelado Hay veces que. denominado Activo. interesa volver al mismo subestado en el que se estaba cuando se salió. un estado con subestados disjuntos sería el siguiente: EstadoCompuestoConSubestadosDisjunto Subestado1 Subestado2 En este caso se ha añadido un estado de inicio y de terminación dentro del estado compuesto. . Estos estados se identifican porque en la esquina inferior izquierda tienen una letra H (de History) dentro de una circunferencia. Una de las ventajas de los estados compuestos es que. aunque no es necesario si las transiciones. Esto hace que se reduzcan el número de líneas en el diagrama. sólo hace falta ponerla una vez en el estado superior. los subestados pueden estar compuestos por otros subestados y así sucesivamente. Un estado puede estar compuesto por uno o más subestados. que entran o salen al estado. después de salir de un estado compuesto. En este último caso se trata de una transición reflexiva.

Si se asigna un nuevo profesor es posible volver al subestado anterior ( Abierto o Cerrado) debido a que el superestado tiene historia. En caso de que los subestados sean a su vez estados compuestos. Para ello. Para modelar estados compuestos concurrentes se utilizan regiones concurrentes. es posible utilizar barras de sincronización.Ingeniería del Software-UML 30 Por ejemplo: Activo Abierto dimite profesor Pendiente de cancelación fin periodo matrícula Cerrado asignado nuevo profesor H cancelar fin cuatrimestre cancelar Completado Cancelado En este diagrama. Alternativamente a las regiones concurrentes. tal y como se verá. el superestado que contiene a todos los subestados debe estar marcado con H* en vez de H. Ejemplo: Recibiendo clase Incompleto Práctica1 hecha Práctica2 hecha terminado Trabajo Aprobado aprobado Examen suspendido Suspenso . como las que se utilizan en el diagrama de actividades. existe un nuevo est ado al que se accede desde el estado Activo cuando dimite el profesor del curso. Estas reguiones se separan por lineas de puntos en el superestado. es también posible volver al último subestado pertenezca al nivel que pertenezca.

el estado Incompleto (que a su vez es un subestado de Recibiendo clase) está compuesto por tres subestados. Cuando un estado es compuesto pero su descomposición está en un diagrama aparte. en este caso disjuntos ( Práctica1 y Práctica2). Cuando varias transiciones son disparadas por un mismo evento pero con diferente condición de guarda. el primer subestado está compuesto por otros dos subestados. Además. se añade un pequeño símbolo de composición en su esquina inferior derecha.Ingeniería del Software-UML 31 En este ejemplo. Por ejemplo: ev [cg1] Origen ev [cg2] Destino1 Destino1 ev [cg3] Destino1 Puede simplificarse como: [cg1] Destino1 ev [cg2] Origen Destino1 [cg3] Destino1 . cada uno de ellos en una región concurrente. es posible utilizar una simplificación para su dibujo. tal y como se puede ver en el siguiente ejemplo: EstadoCompuesto SIMPLIFICACIÓN DE TRANSICIONES .

Diagrama de estados Centrado en los estados de un objeto o sistema. que muestra los diferentes pasos o actividades y el orden en que se deben realizar para obtener un disco de sistema (MS-DOS): Formatear Pistas Grabar Boot Crear FAT Crear Directorio Raíz Grabar Fich. se ha evitado intencionadamente el uso de la palabra estado al hablar de las actividades. para evitar confusiones. por lo que comparte ciertas características comunes con los diagramas de estado. las actividades que tienen lugar entre un conjunto de objetos (clases) y las operaciones o métodos de las clases. los diagramas de actividad de UML son un caso especial de una máquina de estados. Énfasis en la reacción al entorno (control por eventos). Los diagramas de actividad son útiles para describir flujos de evento en los casos de uso. . Veamos a continuación un ejemplo de diagrama de acti vidad. mostrando la secuencia de actividades o pasos que tienen lugar para la obtención de un resultado o la consecución de un determinado objetivo. Los diagramas de actividad permiten modelar el comportamiento de un sistema o alguno de sus elementos. Sistema 9 Actualmente. La siguiente tabla es un resumen de ellas: Diagrama de actividades Centrado en las actividades de un proceso.Ingeniería del Software-UML 32 9 DIAGRAMA DE ACTIVIDAD . Los diagramas de actividad permiten: Modelar el flujo de trabajo de un negocio. Opcionalmente. Énfasis en el orden procedimental y/o flujo de objetos (control procedimental). aunque realmente una actividad es un estado de acción. Sin embargo. Modelar información procedimental. Es interesante comparar las diferencias entre los diagramas de estados y actividades. permite mostrar los flujos de información (objetos) producidos como resultado de una actividad y que serán utilizados posiblemente como entrada por la actividad siguiente.

tal y como se puede ver en el siguiente ejemplo: Actividad Compuesta . dependiendo del elemento cuyo comportamiento se esté modelando.Ingeniería del Software-UML 33 El elemento fundamental de los diagramas de actividad son las actividades. y se permite la condición especial [else] que se cumple cuando no se cumple ninguna de las otras. que suelen ser model adas utilizando un diagrama de actividad propio. aunque cuando el diagrama mode la operaciones de una clase suele utilizarse pseudocódigo o incluso el lenguaje de programación en que se vaya a realizar el desarrollo. Para indicar que una actividad contiene subactividades. También es posible añadir condiciones de guarda a las transiciones. que indican el orden en que se deben de realizar las actividades. se añade un pequeño símbolo de composición en su esquina inferior derecha. Las actividades pueden describirse usando lenguaje natural. Las condiciones de guarda de una decisión deben ser mutuamente excluyentes. Una actividad compuesta no está concluida hasta que no han concluido sus subactividades. tal y como muestra el ejemplo siguiente: Leer PIN Verificar PIN [ incorrecto ] [ correcto ] Nótese que se utiliza un rombo para simbolizar el punto de decisión y el origen de las bifurcaciones. Las actividades se relacionan unas con otras mediante transiciones. Una actividad representa la ejecución de una tarea o misión en un flujo de trabajo o la ejecución de una sentencia en un procedimiento. Esto permite realizar decisiones o bifurcaciones basadas en las condiciones de las guardas. Una transición se dispara cuando termina de realizarse la actividad de la que parte. empezando desde el punto de inicio del diagrama hasta llegar a un punto final del mismo. Una actividad puede estar compuesta de un conjunto de subactividades.

Ingeniería del Software-UML

34

En los diagramas de actividad se puede mostrar la concurrencia y la sincronización utilizando barras de sincronización, que simbolizan uniones y divisiones en el flujo de control. Por ejemplo:

Conseguir ingredientes

Calentar aceite

Cascar huevos

Batir

Freir

Como se puede ver, la transición que sigue a la actividad Conseguir ingredientes se divide por medio de una barra de sincronización en dos transiciones que desembocan en las actividades Calentar aceite y Cascar huevos, que pueden ser realizadas de forma concurrente. Por otro lado, la transición que desemboca en la actividad Freir parte de una barra de sincronización a la cual llegan dos transiciones. Este es un punto de sincronización que indica que no se disparará la transición saliente de la barra hasta que no se hayan disparado las transiciones entrantes (esto es, hasta que no hayan concluido las actividades de las transiciones entrantes: Calentar aceite y Cascar huevos).

Ingeniería del Software-UML

35

En los diagramas de actividades también se pue den representar calles (swimlanes: calles en el sentido de las diversas calles paralelas en las que se divide una piscina olímpica). Las calles son elementos organizativos que permiten asignar las responsabilidades de las acciones a unidades organizacionales de un negocio o a clases. Por ejemplo, en el siguiente diagrama se modela una compra por correo:
Cliente Ventas Almacén

Solicitar pedido

Verificar pedido

Reunir pedido

Enviar pedido

Recoger pedido

Obsérvese, por ejemplo, que el cliente es el encargado de realizar las actividades Solicitar pedido y Recoger pedido.

Ingeniería del Software-UML

36

Los diagramas de actividad permiten también mostrar el flujo de información (objetos) entre actividades, significando un compromiso tanto por parte de la actividad que debe generarla como por la actividad que debe aceptarla como entrada. Para ello, se dibuja una línea discontinua terminada en flecha que va desde la actividad que genera como salida al objeto, y otra línea similar que va desde el objeto a la actividad que sigue y que recibe dicho objeto como entrada. Frecuentemente, un mismo objeto se repite como entrada y salida en diversas actividades sucesivas, actividades que posiblemente irán modificando el estado del objeto. En este caso se suele añadir al nombre del objeto el estado en que se encuentra entre corchetes. Por ejemplo:

Cliente

Ventas

Almacén

Solicitar pedido

: Pedido [realizado]

Verificar pedido

: Pedido [verificado]

Reunir pedido

: Pedido [completado]

Enviar pedido
: Pedido [enviado]

Recoger pedido

ICONOS DE CONTROL .
Los iconos de control son un mecanismo que, aun no siendo imprescindibles para la construcción de los diagramas de actividad, resulta una conveniencia que puede ser útil para añadir cierta clase de información en las transacciones. Existen dos iconos de control, el de envío de señal y el de receptor de señal.

sino que se utilizarán según convenga. Para sistemas no triviales. Por ejemplo: Levantarse Encender caferera Coger taza : Café Café hecho Beber café DIAGRAMA DE CLASES.Ingeniería del Software-UML 37 El icono de envío de señal equivale a una transacción que envía una señal. se produce una espera hasta que se recibe una señal que dispara la transacción. se suele usar más de un diagrama de clases. ayudando los desarrolladores a planificar y establecer la arquitectura y estructura del sistema y subsistemas antes de escribir ningún código. paquetes. Cuando se utilizan varios diagramas. se puede añadir una línea discontinua acabada en flecha que vaya al objeto que recibe la señal o que parta desde el que la envía (puede ser el mismo). . cada uno no tiene necesariamente que representar divisiones del modelo subyacente. Su símbolo es: Optativamente. Los diagramas de clases se utilizan para mostrar la estructura estática del sistema modelado. Los diagramas de clases son usados prácticamente en la totalidad de sistemas en que se utiliza UML para su modelado. Pueden contener clases. interfaces. esto es. como objetos o enlaces. pudiendo una misma clase aparecer en diagramas diferentes para representar distintas vistas del modelo. Su símbolo es: El icono de recepción de señal equivale a un estado de espera. Los diagramas de clases son una potente herramienta de diseño. Esto permite asegurar que el sistema está bien diseñado desde el principio. relaciones e incluso instancias.

eventos que maneja. protegida o privada (-). La visibilidad puede ser pública. Tanto éstas como las secciones de atributos y operaciones pueden contener en primer lugar un nombre que indique la sección de que se trata. Tampoco es necesario visualizar todos y cada uno de los atributos y operaciones. etc. . También permite especificar otras propiedades. En este caso. excepciones que puede generar. Opcionalmente. como por ejemplo si los objetos son persistentes. conviene añadir puntos suspensivos (. Por ejemplo: Punto coordenadaX coordenadaY mostrar() ocultar() posicionX() posicionY() Tanto la sección de los atributos como la de las operaciones pueden no mostrarse. También es posible otras visibilidades dependientes del lenguaje. con los significados usuales.. en cuyo caso tampoco se mostrará la línea que las separa. la siguiente los atributos y la última las operaciones. lo cual puede ser útil para remarcar qué atributos u operaciones son interesantes en una determinada vista. mostrando la primera el nombre de la clase (y opcionalmente otra información que afecte a la clase). se pueden añadir más secciones para indicar otra información. como responsabilidades de la clase.Ingeniería del Software-UML 38 CLASES. estáticos o transitorios.) al final de la sección de la que se hayan suprimido atributos u operaciones. La notación general para una clase es un rectángulo dividido en tres secciones. como por ejemplo la visibilidad de implementación o paquete ( implementation) en el caso de C++ que equivale a una visibilidad pública para el resto de clases definidas en el mismo paquete y privada para las definidas fuera. Las clases son los componentes fundamentales de los diagramas de clases.. Por ejemplo: Reservas operaciones confirmar() cancelar() cambiar() responsabilidades facturar clientes sin reserva ajustarse a habitaciones libres excepciones tarjeta de crédito no válida Rose permite especificar la visibilidad de cada clase.

Su icono es el siguiente: En esta sección también se pueden añadir. Su icono es el siguiente: - «entity»: Contienen la información significativa del sistema (entidades) y generalmente son guardadas en almacenamiento externo. También es posible sustituir el rectángulo por un icono asociado a dicho estereotipo o poner dicho icono en el extremo superior derecho de la sección. En el siguiente ejemplo se muestra la clase EntradaMaterial. En caso de que la clase sea abstracta. esto es. El nombre de la clase se debe poner centrado y en negrita 10. Por ejemplo. pudiendo coincidir sus nombres si están definidos en paquetes distintos (ya que sería otro entorno).Ingeniería del Software-UML 39 Sección de nombre. se puede preceder al nombre de la clase por el nombre del paquete donde se ha definido. Se aplica a formularios. Existen algunos estereotipos muy comunes con iconos preestablecidos: «boundary»: Indica que la clase constituye la frontera o interface entre el sistema modelado y el exterior. . y empezando por letra mayúscula. proveedores y productos serían clases a las que se les aplicaría este estereotipo. debajo del nombre. Los nombres de clase deben ser únicos en su entorno. En la sección de atributos se muestran todos o parte de los atributos. el nombre se pondrá además en cursiva. en un sistema de almacén los clientes. con el estereotipo «boundary» y valores etiquetados que indican su autor y estado: «boundary» EntradaMaterial {autor = Eva. Cuando sea necesario. valores etiquetados con alguna información relativa a la clase. estado = comprobado} Sección de atributos. éste se pondrá encima del nombre de la clase. En caso de especificar un estereotipo para la clase. informes. alineados a la izquierda y utilizando la siguiente sintaxis: visibilidad nombre[multiplicidad]:tipo=valorInicial {cadenaPropiedades} 10 Rose no lo visualiza en negrita. interfaces y similares. como por ejemplo Utilidades::Visualizador. Estas clases son fácilmente reconocibles porque de ellas suelen partir muchos mensajes a otras clases. Su icono es el siguiente: - «control»: Indica que la clase es una clase de control que se dedica a labores de coordinación. son clases persistentes.

esto no es posible.10..1 1 0. de forma optativa. los atributos cuyo valor se calcula a partir de otros atributos de la clase..3. según el lenguaje.. se marcan con una barra inclinada (/) delante del nombre. se marcan con el símbolo de dólar ($) delante del nombre. 7. Ejemplos: Habitacion -largo: double -ancho: double #/area: double -id: int {frozen} -estado: tEstados = habitable Punto -coordenada[1. La multiplicidad en UML se indica como uno o más intervalos enteros (en el caso de múltiples intervalos. Es posible agrupar atributos por estereotipo precediéndoles del mismo. Los atributos derivados. Los atributos estáticos. por cualquier razón. con un icono: Es obligatorio definir la visibilidad para cada atributo. El tipo será uno de los existentes en el lenguaje de desarrollo. Rose también permite indicar el modo de almacenamiento del atributo.6 1. se utiliza el símbolo asterisco (*).Ingeniería del Software-UML 40 La visibilidad puede ser pública (+). . Cada intervalo tiene el formato límiteInferior. Si un día. se puede indicar subrayándolo(s). significa que dicho atributo podrá contener un valor o ninguno (esto es. esto es. atributos cuyo valor es compartido por todas las instancias de una clase. que sería una temperatura de 0º. Cuando la multiplicidad es mayor que uno se puede pensar que equivale a definir un array. 19. puede tener un valor nulo..* 1. Para indicar un límite indefinido..3] #color -visible .. igual que la forma de expresar el valor inicial. privada (-) o...1. aunque se puede no visualizar. y a continuación se pondrá entre corchetes su multiplicidad (siendo optativo para el caso habitual de multiplicidad 1). La cadena de propiedades es optativa. que es distinto de 0. el valor de dicho atributo será nulo (ningún valor). Imagínese que una estación meteorológica recoge la temperatura a medio día todos los días. que el valor de dicho atributo(s) identifica de forma unívoca a cada objeto de dicha clase. Cuando la clase dispone de un atributo(s) “clave”. Ejemplos de multiplicidad son: 0. Rose permite mostrar la visibilidad mediante los signos o. pero el tipo es obligatorio. pueden ser recomendables en algunos casos por cuestiones de eficacia (tiempo de ejecución). esto es. implementación.. protegida (#). Si tuviéramos que hallar la media de temperaturas. El valor inicial es optativo (en cuyo caso no se incluye el signo igual). Por ejemplo. 15.* Si un atributo tiene como multiplicidad 0. {frozen} indica que un atributo no es modificable. El nombre del atributo se escribirá con minúsculas. las temperaturas con valor nulo no serían usadas (no pueden sumar en el numerador ni tampoco cuentan para el denominador). se separarán por comas). aunque Rose utiliza en este caso la letra ene (n). esto es.límiteSuperior (cuando el límite inferior es igual que el superior basta con poner simplemente el número).. esto es. que significa la ausencia de valor). Aunque el uso de atributos derivados se debe evitar. si será almacenado por valor o por referencia..0. aunque puede no visualizarse.

Administración. Permiten leer o escribir en los atributos (generalmente. según el lenguaje. A continuación se indica el tipo que retorna la operación (que será dependiente del lenguaje). El nombre de la operación se escribirá en minúsculas. ya que puede calcularse multiplicando el valor de los atributos largo y ancho. postcondiciones. Estas operaciones son las que responden a los mensajes que aparecen en los diagramas de interacción de alto nivel. se podrá indicar una cadena de propiedades.Ingeniería del Software-UML 41 Apréciese en la clase Habitación que el atributo area es derivado. su semántica. implementación. aunque sí estarán definidos. En C++ se puede indicar con const. Las operaciones se pueden clasificar de la siguiente forma: Implementadoras. alineadas a la izquierda y utilizando la siguiente sintaxis: visibilidad nombre(listaParámetros):tipoRetorno {cadenaPropiedades} La visibilidad puede ser pública (+). Acceso. aunque puede no visualizarse. entre otras. Proporcionan una funcionalidad básica del negocio. por ejemplo. En caso de existir parámetros. se escribirá en cursiva. privada (-) o. el valor por defecto. pudiendo suprimirse si la operación no devuelve ningún valor (procedimiento). realizando las comprobaciones de integridad oportunas en el caso de escritura). Es el valor por defecto. Rose también permite para cada operación especificar. en caso de que existiera. por ejemplo. El nombre indica el nombre del parámetro formal y se escribirá en minúsculas. En la sección de operaciones se muestran todas o parte de las operaciones que la clase proporciona. Es posible añadir una nota a una operación para indicar. Por último. Aquí se podría indicar. si una operación es secuencial {concurrency=sequential} o concurrente {concurrency=concurrent}. y sólo se han mostrado parte de los atributos. su algoritmo o código. las precondiciones. Después se indica el tipo del parámetro (que será dependiente del lenguaje) y. que proceden de los flujos de eventos de los casos de uso y estos a su vez de los requerimientos. estos vendrán separados p or comas y siguiendo la siguiente sintaxis para cada parámetro: clase nombre: tipo = valorPorDefecto La clase puede ser: in: Parámetro de entrada. encargados de la construcción y destrucción de objetos de la clase. Es obligatorio especificarla. de forma similar a la visibilidad de los atributos. inout: Parámetro de entrada y salida. out: Parámetro de salida. Sección de operaciones. la cantidad (absoluta o relativa) de memoria necesaria para la operación y el tiempo (absoluto o relativo) que precisará su ejecución. protegida (#). - . Pertenecen a esta categoría los constructores y los destructores. Nótese también que en la clase Punto no se han visualizado el tipo de sus atributos. En caso de que sea una operación abstracta (recurso utilizado para implementar polimorfismo). por lo que se han añadido punto suspensivos para indicarlo.

Ingeniería del Software-UML 42 - Auxiliares.. de forma más general. Las operaciones se pueden agrupar por estereotipo precediéndolas del mismo..0) .. Operaciones necesarias para que la clase pueda realizar su trabajo. Hay varias formas de encontrar o diseñar relaciones. UML las creó como relaciones específicas. habrá una relación entre ellos (típicamente una asociación o una . Dependencia: Es una relación de uso. en la cual un clasificador especifica un contrato (por ejemplo. Conviene modelar antes estas relaciones. la generalización. entre clasificadores). presuponiendo que esta clase se implementará en C++. Nótese que se ha escrito el nombre del constructor empezando por mayúsculas. ya que las que no se ajusten a ellas serán relaciones de dependencia. un interface) que otro clasificador garantiza que cumplirá. Asociación: Es una relación estructural. la agregación y la composición. p2: tPunto) «query» +area(): double +perimetro(): double . puede significar (aunque no necesariamente) que tiene demasiadas responsabilidades y que es mejor dividirla en dos o más clases más sencillas. pero que no son visibles desde el exterior. Si una clase tiene demasiados atributos u operaciones. Si una clase tiene muy pocos atributos u operaciones. Existen dos subtipos. Las clases deben estar equilibradas tanto en el número de operaciones como en el de los atributos.. puede significar (aunque no necesariamente) que se ha llegado a una descomposición demasiado grande y que sería mejor que fuera absorbida por otra clase con responsabilidades coherentes. si en un diagrama de interacción un objeto a manda un mensaje a un objeto b. «update» #mover(delta: tPunto) #escalar(ratio: double=2.2]: tPunto «constructor» +Rectangulo(p1: tPunto. Por ejemplo: Rectangulo -p[1.. asociación y realización son también relaciones de dependencia. el nombre del constructor debe ser igual que el nombre de la clase. Esto ha sido así porque. Este tipo de operaciones aparece como mensajes reflexivos en los diagramas de interacción (generalmente. Realización: Es una relación contractual. clases o. en los de bajo nivel). Desde un punto de vista amplio. debido a sus características particulares. Sin embargo. RELACIONES . Existen cuatro tipos principales de relaciones en UML: Generalización: Es una relación de especialización. Por ejemplo. Una relación es una conexión semántica entre elementos (en nuestro caso.

Un esquema con demasiados niveles (más de cuatro o cinco) es usualmente demasiado complicado de entender. de las más particulares a las más generales). También se deben examinar posibles relaciones todo-parte (que posiblemente se podrán modelar como relaciones de composición o agregación).Ingeniería del Software-UML 43 dependencia). Aunque la descendencia múltiple puede ser muy conveniente en algunos casos. un esquema de sólo dos niveles y muy ancho no suele estar aprovechando la potencia de la herencia (ya que. Generalización. También se debe cuidar el esquema de herencia. 11 Clasificación. de la clase más general a la más particular) o ascendente (de abajo a arriba. Las generalizaciones de pueden crear mediante un proceso descendente (de arriba a abajo. no se debe abusar de ella (ya que puede resultar compleja su utilización). . se especifica como una línea acabada en flecha vacía que va del elemento más particular (el hijo) al más general (el padre): ClasePadre ClaseHija La generalización se utiliza para modelar la herencia en los lenguajes orientados a objetos. sería posible extraer características comunes entre algunas clases del segundo nivel que permitiera la creación de un nuevo nivel). como C++. Por ejemplo: Vehículo Terrestre Marítimo Aéreo Automóvil Camión Globo Aeroplano Véase que en este ejemplo las clases Vehículo. en el sentido de clasificación de “especies” en ancestras y descendientes. aunque algunos lenguajes. posiblemente. permiten la herencia múltiple (una clase puede descender de varias clases padre). Terrestre y Aéreo son abstractas. La generalización es una relación taxonómica 11 entre el objeto más general (el padre o superclase) y el más específico (el hijo o clase descendiente). Todos los lenguajes orientados a objetos permiten la herencia simple (una clase puede descender a lo sumo de otra). Gráficamente. ya que gracias a ella es posible agrupar las características comunes de un conjunto de clases en una clase padre (superclase) y hacer que todas ellas hereden de la superclase. Una de las características de la herencia es que permite simplificar la construcción de clases relacionadas. luego no se puede instanciar ningún objeto de ellas.

añadiendo una flecha que indique el sentido de dicha asociación: Compañía Persona En este caso.Ingeniería del Software-UML 44 Si el lenguaje dispusiera de herencia múltiple. indicando que un paquete es una especialización de otro. Las asociaciones modelan relaciones estructurales entre clases. 12 Interface gráfica de usuario. Por ejemplo: GUI12 WindowsGUI XWindowGUI Asociación. pero Persona no puede acceder a Compañía. podríamos crear clases descendientes de varias clases padre. Una asociación se representa gráficamente como una línea que conecta las clases relacionadas: Compañía Persona Esta asociación significa que la clase Compañía puede acceder a los atributos y operaciones públicas de la clase Persona y que. la clase Persona puede acceder a los atributos y operaciones públicas de la clase Compañía. Compañía puede acceder a los atributos y operaciones públicas de la clase Persona. Los paquetes descendientes heredan los elementos públicos y protegidos del paquete ancestro. También se puede restringir la navegabilidad de la asociación. como en el siguiente ejemplo: Terrestre Marítimo Anfibio La relación de generalización también puede darse entre paquetes. redefiniendo generalmente algunas clases y definiendo otras nuevas. de forma similar. .

. Por ejemplo: titular Nº cuenta: int 0.Ingeniería del Software-UML 45 Una clase puede relacionarse consigo misma. Se puede indicar el rol que desempeña una o ambas clases en la asociación. Es posible indicar el estereotipo de la asociación encima del nombre. Por ejemplo: Compañía 0. Por ejemplo: Trabaja para Compañía Persona En este ejemplo.. para una compañía podrán trabajar una o más personas. Calificador.* 0. la relación “es familiar directo de”.* Persona En este caso. pueden modelarse asociaciones reflexivas: Persona Esta asociación reflexiva podría modelar.1 Banco Persona .* 1. Es un nombre descriptivo que indica la naturaleza de la asociación. Se pueden añadir varios adornos y otros elementos a las as ociaciones que aumentan su expresividad o completan o restringen su significado: Nombre de la asociación. Téngase en cuenta que el sentido del nombre de la asociación no restringe la navegabilidad. Se puede indicar cuántas instancias (objetos) de una clase podrán estar asociados a una instancia (objeto) de la otra. Por ejemplo: Compañía patronal empleado Persona - Multiplicidad. se obtendrá un objeto destino (si la multiplicidad del destino es a lo más uno) o un conjunto de objetos destino (si la multiplicidad del destino es muchos). por ejemplo. Dado un objeto origen y un valor determinado para el calificador.. Opcionalmente se puede añadir un pequeño triángulo que indique el sentido en que se debe interpretar. Roles. es decir. estamos expresando que las personas trabajan para las compañías. siendo también posible indicar una cadena de propiedades a la derecha del nombre o debajo. Es un atributo que califica una asociación. y una persona podrá trabajar en cero (que representaría el caso de estar desempleada) o más compañías..

que son los que especifican el banco). Clase asociación. Se utiliza {ordered} para indicar que dichos elementos se encuentran ordenados. Se utiliza esta restricción para indicar que sólo una de las posibles asociaciones modeladas en el diagrama de clases puede ser instanciada en un momento dato para una determinado objeto. el nombre de ambas es igual. Si la multiplicidad es mayor que uno. tal y como está el ejemplo.1 empleado 1. Por ejemplo.. Esto es. Se representa gráficamente como una línea de puntos que conecta dos o más asociaciones a la que se le añade la restricción {xor}.. Siempre es representada junto a la asociación a la que corresponde. dado un titular y un nº de cuenta obtendríamos uno o más bancos. Designa a una asociación que tiene propiedades de clase. Orden. Por ejemplo: Persona Cuenta {xor} Compañía Aquí estamos indicando que una cuenta puede estar a nombre de una compañía o de una persona. para un banco y un número de cuenta obtendríamos un solo titular.. Téngase en cuenta que el calificador pertenece a la asociación y no es un atributo ni del banco ni de la persona. Ya que clase y asociación forman un todo. Es significativo el extremo de la asociación en el que se pone el calificador. Por ejemplo: 0. El uso de cualificadores restringe el entorno de la asociación y es útil. si el nº de cuenta lo representáramos nada más que con los dígitos finales (eliminando los dígitos iniciales. pero no con un objeto : Persona y un objeto : Compañía a la vez. dado un banco y un número de cuenta. y unida a ella mediante una línea discontinua.Ingeniería del Software-UML 46 En este ejemplo. para realizar búsquedas. por ejemplo. los elementos relacionados por la asociación pueden estar ordenados o no. operaciones y/o otras asociaciones. Por ejemplo: paciente Lista Médico {ordered} Persona - Xor-asociación. Pero si pusiéramos el nº de cuenta en el extremo de Persona. tales como atributos.* Compañía patronal Trabajo fechaContrato salario trabajador 0. obtendremos una persona (el titular de la cuenta).* Persona .. pudiéndose especificarse en cualquiera de ellas o en ambas.* dirige jefe 0. un objeto : Cuenta puede estar relacionado (enlazado) con un objeto : Persona o con un objeto : Compañía. pero no simultáneamente de ambas.

mientras que a una clase parte compuesta la contendrá por valor. Simplificando se puede decir que.. y es ese conjunto el que tiene significado. pero las asociaciones se pueden dar entre cualquier número de clases. Se ha modelado como una agregación porque la rueda puede existir antes que el coche como entidad propia o incluso después (se desguaza el coche y de dejan las ruedas) e incluso se puede cambiar alguna de las ruedas de un coche a otro. Véase que este diagrama permite modelar que una persona p1 fuera jefe de otra persona p2 en una compañía c1. la vida de la parte coincide (o es un subintervalo) de la vida del todo. Jugador y Equipo. está ligado tanto a Compañía como a Persona. Agregación y composición. en algún sentido. al pertenecer a la asociación. Estas relaciones son un tipo especial de asociación. Tal caso se representa gráficamente como un rombo que está unido por una línea continua a todas las clases incluidas en la asociación. una clase todo contendrá a una clase parte agregada por referencia. Esto es. Es el todo quien se tiene que encargar de construir y destruir la parte y la parte. Por ejemplo: 1 Coche 4 Rueda Aquí se ha mostrado que un coche (el todo) t iene cuatro ruedas (la parte). y que simultáneamente p2 fuera jefe de p1 en una compañía c2. internamente. En la composición. . Hasta ahora se han visto asociaciones binarias. una clase forma parte o es un componente. las clases participantes tienen una relación de igual a igual.. mientras que en la agregación y la composición la relación es de todo-parte.. En una relación de asociación. La composición es más fuerte que la agregación.Ingeniería del Software-UML 47 Nótese que Trabajo. La agregación se representa como una asociación con un rombo vacío en el lado de la clase todo.* Jugador Ficha sueldo clausulaRescision En este ejemplo se modela una asociación denominada Ficha (que además tiene una clase asociación) entre las clases Temporada. Por ejemplo: Temporada 0. en general. no podrá ser compartida por ningún otro elemento.* Equipo 0.* 0. de otra.

Es equivalente a una clase abstracta que sólo tiene operaciones abstractas. se muestra una línea discontinua acabada en flecha vacía que va de la clase que implementa el interfaz a la interfaz. el interface Mensurable especifica dos operaciones. o en forma resumida como un círculo y debajo el nombre del interface: «interface» Mensurable peso(): double volumen(): double Mensurable En este caso. que podrán ser implementados por un chip o tarjeta (que son los que realizan dicha interface). El estándar especifica operaciones como el envío y recepción de caracteres. pero que no proporciona ninguna implementación (ni tiene atributos).* Punto {ordered} PropiedadesGraficas 1 color textura focosIluminacion Realización. peso() y volumen(). He aquí otro ejemplo de composición y agregación: 1 Poligono 1 contiene 3.* Botón Aquí se ha mostrado que un formulario (el todo) puede contener cero o más botones (la parte). Por ejemplo: 1 Formulario 0. Para indicar que una clase realiza una interfaz.. Una realización es una relación semántica entre clasificadores. Gráficamente.Ingeniería del Software-UML 48 La composición se representa como una asociación con un rombo lleno en el lado de la clase todo. Generalmente se emplea la realización para especificar una relación entre una interfaz y la clase o componente que implementa las operaciones especificadas en dicha interfaz. una interface se muestra como una clase con el estereotipo «interface» y sus operaciones. Un botón sólo puede existir dentro de un formulario. Un ejemplo de interface sería el RS-232 (suele ser el estándar para puertos serie). por lo que la vida del botón estará restringida a la vida del formulario que lo posee. en la cual un clasificador especifica un contrato que otro clasificador garantiza que cumplirá.. Un botón pertenece a un y sólo un formulario. Una interface es un clasificador que especifica una serie de operaciones. .

Ingeniería del Software-UML 49 Por ejemplo: Saco .... peso(): double volumen(): double . se puede cambiar la implementación sin que sea necesario modificar las llamadas. Son muy útiles para independizar la implementación de sistemas o utilidades de los servicios u operaciones que proporcionan (esto es. y una clase puede satisfacer varios interfaces.. peso(): double volumen(): double . Por ejemplo: Saco Mensurable Automóvil Mensurable Cuando una clase realiza un interface. En el caso de usar la notación resumida. debe implementar todas las operaciones indicadas en dicha interface y.. se indica que tanto Saco como Automovil “realizan” el interface Mensurable.. En este caso. es decir. ambas implementan las operaciones indicadas en el interface. Varias clases pueden satisfacer un interface (como en el ejemplo anterior). otras exclusivas de la clase. se unirá el interface a la clase que lo implementa por una línea continua. posiblemente. ya que no se ha ... Por ejemplo: Furgoneta Mensurable Alquilable Las interfaces pueden evitar en ciertos casos el uso de herencia múltiple. «interface» Mensurable peso(): double volumen(): double Automóvil .

Para que la clase dependiente tenga acceso a la clase independiente. la clase Cliente (dependiente) dependerá de servicios proporcionados por la clase Servidor (independiente). ya que el elemento dependiente debe conocer al independiente. sea el siguiente interface: «interface» Empleado nombre() fechaNacimiento() dni() numeroHijos() Si en el extremo de una asociación especificamos un nombre (o lista de nombres) de interface(s) precedidos de dos puntos. Las dependencias se usan para modelar relaciones en la cual un cambio en el elemento independiente (el suministrador) puede requerir cambios en el elemento dependiente (el cliente). Gráficamente se muestra como una línea discontinua acabada en flecha que va del elemento dependiente al independiente (esto es. . Por ejemplo. El elemento dependiente (cliente) requiere conocer al elemento independiente (suministrador) y que éste esté presente. la clase en el extremo contrario sólo podrá acceder a las operaciones indicadas en el interface. la clase independiente debe tener visibilidad global. Otra de las posibilidades de los interfaces consiste en limitar el acceso en las asociaciones. como en el siguiente ejemplo: Compañía : Empleado Persona Esto evitaría. suponiendo que la clase Persona lo implementara. Un cambio en la clase Cliente no tiene ningún efecto sobre la clase Servidor. y un cambio en la clase Servidor puede ocasionar que la clase Cliente necesite ser adaptada. Es un tipo de relación unidireccional. Por ejemplo: Cliente Servidor En este caso. fomentando la reutilización. ya que esta última es independiente de la primera (no la necesita). que sí sería de incumbencia en una relación Médico-Persona).Ingeniería del Software-UML 50 modificado el interface). ser pasada como parámetro a una operación o ser instanciada como variable local en una operación de la clase dependiente. Dependencia. el elemento dependiente señala al elemento del que depende). por ejemplo. del método perteneceGrupoRiesgoSida(): bool. Una dependencia es una relación entre un elemento dependient e (el cliente) y un elemento independiente (el suministrador del servicio requerido). que la Compañía pudiera acceder a métodos de la clase Persona que no fueran de su incumbencia para el tipo de relación Compañía-Persona (como sería el caso. Los interfaces son soportados por lenguajes como Java o Corba. pero el independiente desconoce la existencia del elemento dependiente.

no de la ClaseImplementadoraInterface. tal y como se muestra en el siguiente ejemplo: B A «import » C «import » D . Para agrupar las clases en paquetes. Tal y como se dijo. se pueden utilizar varios criterios. otra de errores. Las relaciones de dependencia también se utilizan para mostrar la dependencia entre paquetes. El paquete B es fácilmente reutilizable (es independiente). otras de la gestión informes. Un criterio puede ser el agrupar las clases por estereotipos (en este caso habría un paquete para las clases frontera. las clases se suelen agrupar en paquetes. Como los paquetes pueden contener a su vez otros paquetes. es necesario que ningún nombre de un elemento del paquete dependiente coincida con un nombre de elemento del paquete independiente). De hecho un cambio en la ClaseImplementadoraInterface no tendría ninguna consecuencia sobre la ClaseDependiente. Por ejemplo: «access» A B Esta dependencia tiene implicaciones en la reutilización. Por ejemplo: ClaseImplementadoraInterface Interface ClaseDependiente Nótese que la ClaseDependiente depende de Interface. el paquete A necesita tener acceso al paquete B. mientras que el paquete A no lo es. ya que el interface aísla de posibles cambios en la clase implementadora. Sin embargo. Con ambos estereotipos se tiene acceso a los elementos públicos del paquete independiente. volver a agrupar por estereotipo. También es posible agrupar las clases por su funcionalidad (podría haber un paquete con clases que se encargaran del control de acceso. ya es dependiente del B y para reutilizar el paquete A habría que usar también el B.). Una relación de dependencia entre un paquete A y un paquete B indica que alguna clase del paquete A tiene una relación unidireccional con alguna clase del paquete B y.Ingeniería del Software-UML 51 Cuando una clase usa los servicios de otra a través de un interface. por tanto. Se deben evitar en lo posible referencias circulares. etc. las dependencias no son transitivas. Las relaciones de dependencia entre paquetes deben ser calificadas con el estereotipo «access» o «import». también se modela como dependencia (depende del interface. otro para las de control y otro para las de entidad). un cambio en el interface requeriría un cambio en la clase dependiente). pero con «access» es necesario preceder dichos elementos por el nombre del paquete que los contiene mientras que con «import» no (en este caso. una tercera posibilidad consiste en agrupar las clases por funcionalidades y dentro de cada grupo de funcionalidad. Los paquetes contenidos en otros paquetes pueden acceder a todos los elementos del paquete que los contiene.

Una plantilla no es utilizable directamente (es decir. habría que añadir una dependencia de A a D. Una clase parametrizada define una familia de clases: cada clase se especifica ligando los parámetros formales de la clase parametrizada a valores reales. El paquete B y el paquete C pueden acceder al paquete D. Gráficamente. quedaría: Pila<persona. El paquete A no puede acceder al paquete D. tal como se muestra en el ejemplo: tElem. Si quisiéramos dar expresamente el valor. max:int=100 Pila «bind» (persona.100> .Ingeniería del Software-UML 52 El paquete A puede acceder al paquete B y al paquete C. como por ejemplo un número entero. se utilizará una dependencia estereotipada como «bind» (ligar). Clases parametrizadas. Para instanciar una clase a partir de la clase parametrizada. Por ejemplo: Pila<persona> Nótese que en este caso no se ha especificado el número máximo de elementos.200) PilaPersonas También es posible indicar directamente los parámetros entre ángulos en la clase instanciada. siendo el parámetro el tipo de elemento que almacenará dicho contenedor. Una clase parametrizada o plantilla (template) es un descriptor de una clase con uno o más parámetros formales. además de tener el tipo del elemento a almacenar como parámetro. luego la pila tendrá 100 que es el número que se le ha dado por defecto. una clase parametrizada se muestra como una clase a la que se añade un recuadro en línea discontinua en la parte superior derecha donde se indican sus parámetros formales: ListaParámetros NombreClase Las clases parametrizadas suelen utilizarse para crear contenedores. no se puede instanciar ningún objeto de la misma) por tener parámetros libres. Esta plantilla. Si se deseara que A accediera a D. Un ejemplo de clase parametrizada (del tipo contenedor) sería una plantilla de pila. También puede recibir valores. podrá recibir un valor entero que indique el máximo número de elemento de la pila (100 por defecto).

. generalmente. como la media. esto es. Al definirse como utilidad. Otro ejemplo sería una utilidad de operaciones estadísticas. Los diagramas de objetos se utilizan. La relación sería una realización: «type» MiTipoDeDatos MiTipoDeDatosImplementado DIAGRAMA DE OBJETOS. Es un artificio que facilita el diseño y programación. sin definir ni la implementación física de esos objetos ni métodos. Las utilidades pueden estar parametrizadas. tal como se puede ver en el siguiente ejemplo: «utility» UtilidadesMatemáticas sin(double): double random(): double . estructuras de objetos cuya complejidad aconseje dibujar un diagrama que sirva para una mejor comprensión del modelo. Una clase utilidad se modela con el estereotipo «utility». la mediana. utilizándose una notación similar a las clases parametrizadas. es necesario crear una clase que proporcione métodos para todas las operaciones del tipo. un diagrama de objetos representa la situación del sistema en un momento determinado (se utilizan instantes significativos o prototípicos). Las utilidades son un agrupamiento de variables y procedimientos globales en forma de una declaración de clase. Para que el nuevo tipo sea utilizable.. la desviación. . Es una instantánea de un sistema en la que se detalla el estado del mismo en ese momento: objetos.Ingeniería del Software-UML 53 UTILIDADES . para visualizar. Un tipo se representa como una clase con el estereotipo «type»: «type» MiTipoDeDatos Esta notación permite modelar los tipos predefinidos del lenguaje o crear tipos nuevos. especificar y documentar mod elos estructurales. Un diagrama de clases indica lo que puede ser el sistema. etc. Un diagrama de objetos es una instancia de un diagrama de clases. se podrían utilizar dichas operaciones directamente por cualquier clase (visibilidad global). TIPOS . Los tipos se utilizan para especifica r un dominio de objetos junto con las operaciones aplicables a dichos objetos. valores significativos de los atributos y enlaces entre objetos.

Para construir un diagrama de objetos hay que: Identificar la estructura o mecanismo que se quiera modelar. Identificar las clases. por ejemplo.Ingeniería del Software-UML 54 En general. Considerar un escenario en el que intervenga ese mecanismo y congelar ese escenario. dicha instancia. Lugo” : Persona : Persona : Persona : Persona . si tenemos este diagrama de clases: Compañía 1 0. Por ejemplo. Partir de un diagrama de objetos significativo y modelar un diagrama de clases que posibilite.n Dpto 0. Madrid” dLu: Dpto nombre= “Deleg. representando cada objeto que participe en dicho mecanismo. interfaces y otros elementos que intervengan en la relación.. podríamos modelar el siguiente diagrama de objetos para documentarlo: : Compañía ventas: Dpto nombre= “Ventas” id: Dpto nombre= “I+D” : Persona : Persona dMa: Dpto nombre= “Deleg.n 1.n Persona . Esto sucede. cuando se conocen ejemplos de la estructura real y se quiere derivar un diagrama de clases al que se ajuste. Mostrar los enlaces entre esos objetos. existen dos posibilidades: Partir del diagrama de clases y crear una instancia (diagrama de objetos) que permita una mejor comprensión del mismo. que representarán instancias de asociaciones entre ellos. Mostrar los valores y atributos necesarios para comprender el escenario. al menos...

relaciones que se dan en un momento dado. por lo cual no puede aparecer ninguna multiplicidad en ellas. el siguiente diagrama muestra un objeto de la clase Robot que se encuentra moviéndose (estado movimiento). incluyend o la estructura del código fuente y similares (diagrama de componentes) y la estructura de implementación en tiempo de ejecución (diagrama de despliegue).Ingeniería del Software-UML 55 Nótese que los enlaces son instancias de las relaciones del diag rama de clases. objetos. por ejemplo. Un diagrama de componentes se utiliza para modelar los componentes de un sistema y mostrar las dependencias entre ellos. Este caso sucede. un diagrama de clases que sólo contenga instancias de clases. por lo que se debe utilizar un diagrama de clases para representar un diagrama de objetos. así como el mundo (entorno) que ha identificado y la relación entre elementos identificados: : Robot [movimiento] : Mundo a1: Area a1: Area m1: Muro ancho= 80 p1: Puerta ancho= 40 m2: Muro ancho= 80 m3: Muro ancho= 40 Nótese que el objeto a1 es un área rectangular (habitación) formada por tres muros y una puerta. Por ejemplo. DIAGRAMAS DE COMPONENTES. Los diagramas de implementación muestran aspectos relativos a la implementación. esto es. Como en los diagramas de clases también se pueden mostrar objetos. También se han incluido los valores del atributo nombre de los objetos de la clase Dpto para facilitar su entendimiento. También es posible especificar el estado en que se encuentra el objeto. DIAGRAMAS DE IMPLEMENTACIÓN. esto es. en Rose: no hay un diagrama de objetos como tal. se le puede denominar diagrama de objetos. . el muro m1 limita con la puerta p1 y con el muro m3). y que cada uno de los elementos constituyentes está relacionado con su adyacente (por ejemplo.

mientras que los componentes tienen significado físico. un ejecutable A. Antes de poder generar código.pas Nótese que el programa ejecutable ( programa. . Un componente puede depender de otro. y estos componentes serán los que contengan su código fuente. por ejemplo. documentos. más eficaz.log). Ejemplos de componentes son el código fuente.dll A. por ejemplo. las clases residen o son implementadas en componentes). Los componentes pueden existir en tiempo de compilación.pas. Las clases son “componentes lógicos”. opcionalmente. Se puede expresar explícitamente que un componente depende de un interface realizado por otro componente.exe que requiere de algún servicio proporcionado por la dll (Dinamic Link Library) B. las clases deben ser mapeadas a componentes (esto es.dll. estado. tablas. Esta es una dependencia de compilación: para generar programa.exe necesitamos programa. Hay una gran diferencia entre clases y componentes. mapas de bits de los iconos de una aplicación.exe Esto podría modelar. fichero de inicialización (.ini). ya que. una cadena de propiedades que indiquen. los componentes deben tener interfaces bien definidos. su versión. por componentes más eficaces) y reutilizados fácilmente. posibilitando la construcción de componentes complejos utilizando componentes más simples. no habría que realizar ninguna modificación en los ejecutables. En este caso existe una relación de dependencia entre ellos.pas). o incluso otros componentes.exe) depende del programa fuente (programa. al accederse a ella a través de un interface. ejecutable. autor.exe programa. Tal y como se dijo. código binario. fichero de registro (. tal y como se puede ver en el siguiente ejemplo: programa. También se puede mostrar dentro de un componente las clases o paquetes que residan en él. Los componentes son equivalentes a tipos. tal y como se muestra a continuación: B.Ingeniería del Software-UML 56 Un componente representa un módulo de software con un interface bien definido. etc. No habría ningún problema en cambiar la dll por otra más moderna que fuera. etc. DLL. por ejemplo. siendo sus instancias las que aparecerán en el diagrama de despliegue. Esto permite que los componentes puedan ser reemplazados (por ejemplo. de enlace o de ejecución o incluso en varios o todos esos tiempos. La notación estándar de un componente es: Nombre Dentro del componente se especifica su nombre y/o su tipo y.

Los subprogramas son colecciones de rutinas (no contienen definiciones de clases).cpp). en C++ sería el fichero . Los paquetes contienen las clases.exe. mientras que en Java cada clase debe asociarse a un componente individual.Ingeniería del Software-UML 57 Rose proporciona para los componentes algunos estereotipos estándar con iconos asociados.h) y el cuerpo la implementación (la implementación de las funciones.h) y el cuerpo la implementación (la implementación de los métodos de las clases. tales como funciones o procedimientos. Sus representaciones gráficas son: Especificación de tarea Cuerpo de tarea . En C++ se pueden asociar varias clases a un componente.cpp). en C++ sería el fichero . en C++ sería el fichero . Sus representaciones gráficas son: Especificación de paquete Cuerpo de paquete - Especificación y cuerpo de tarea. Las especificaciones constituyen el interface del componente (la definición de las funciones. Indica que en el componente reside el programa principal. un fichero ejecutable se representa como una especificación de tarea con extensión . Sus representaciones gráficas son: Especificación de Subprograma Cuerpo de subprograma - Programa principal. en C++ sería el fichero . Representa paquetes que tienen hilos independientes de control. tal y como se muestra a continuación: Especificación y cuerpo de subprograma. Normalmente. Las especificaciones constituyen el interface del componente (la definición de las clases. Su representación gráfica es: Programa principal - Especificación y cuerpo de paquete.

log b.exe principal.cpp a.dll Este otro diagrama muestra dependencias en tiempo de compilación: principal. Por ejemplo.h c.cpp a.cpp c. Incluso permiten mostrar dependencias entre varias versiones de componentes.h b.dll .h b.hlp a.Ingeniería del Software-UML 58 Los diagramas de componentes permiten mostrar tanto dependencias en tiempo de compilación y lincado como en tiempo de ejecución.ini .cpp . el siguiente diagrama muestra dependencias en tiempo de ejecución: .exe .

a qué otros componentes afectaría el cambio de uno de ellos y qué se debería recompilar. Rose permite especificar el lenguaje en que se realizará cada componente. A la hora de asociar clases a componentes. Un nodo se representa tal como sigue: Nombre Rose utiliza dos representaciones diferentes para los nodos. hay veces en que conviene hacerlo de forma diferente (para adaptarse a una arquitectura cliente-servidor. Esto permitiría. se suelen asociar dichos paquetes a los componentes. si éstas se han agrupado en paquetes. porque haya clases sujetas a modificaciones frecuentes. Se puede especificar el tipo de un nodo o una instancia del mismo (en cuyo caso se subrayará). Los nodos de un diagrama de despliegue representan elementos físicos con capacida d de proceso o facilitadores de algún servicio. un servidor o similar). periféricos. ya que sería imposible realizar dicha compilación. ) que residen en ellos en tiempo de ejecución. Téngase en cuenta que en los diagramas que muestran la secuencia de compilación no deben aparecer referencias circulares. Sin embargo. mostrándose en qué nodos (procesadores) reside cada instancia. etc. hay veces que conviene asociar una misma clase a varios componentes. como los ficheros fuente. DIAGRAMA DE DESPLIEGUE. comunicaciones.) y los componentes software (programas. Además. aunque una clase se suele asociar a un solo componente. generar los componentes de la parte cliente en Visual Basic y los componentes de la parte servidor en C++ en un sistema con arquitectura cliente-servidor. por ejemplo. En un diagrama de despliegue no pueden aparecer componentes que no existen como entidades en tiempo de ejecución. etc.). etc.Ingeniería del Software-UML 59 Este tipo de diagrama muestra el orden en que se deben compilar los ficheros. los laterales se ponen en negro: Si el nodo no tiene capacidad de proceso (como un terminal. los laterales no se rellenan: . En los diagramas de despliegue aparecen instancias de componentes. procesos. Si el no do tiene capacidad de proceso (como un ordenador. Los diagramas de despliegue muestran la configuración de elementos de proceso (el despliegue de procesadores. pertenecientes al diagrama de componentes. una impresora o un escaner).

Ingeniería del Software-UML 60 Los nodos son los elementos donde se encuentran o ejecutan las instancias de los componentes en tiempo de ejecución. que el nodo soporta una instancia de ese componente. Una asociación se representa gráficamente como una línea entre los nodos que comunica. tal y como se muestra a continuación: OrdContabilidad : PC «support » : ContaGes . es decir. se relaciona al nodo con la instancia mediante una dependencia estereotipada como «support». se puede mostrar la instancia dentro del nodo: OrdContabilidad: PC : ContaGes Los nodos están relacionados entre sí por asociaci ones. De forma alternativa. Es común estereotipar las asociaciones para indicar su tecnología. Para mostrar que una instancia de un componente reside o se ejecuta en un nodo. . que indican caminos de comunicación.

Ingeniería del Software-UML 61 Un ejemplo de un diagrama de despliegue de un sistema sería: ServBD : Servidor : SGBD «LAN» ServCentral : Servidor : ServGestor «USB» : Impresora «RDSI» «RDSI» DelegacionJaen : PC : CliGestor DelegacionToledo : PC : CliGestor Hay veces que una instancia de un componente puede migrar de un nodo a otro. Por ejemplo: Nodo1 :A : Cluster «become» Nodo2 : Cluster . Para modelar esta migración se representa una relación entre dichas instancias con el estereotipo «become».

estratégicos. Dirigida y controlada. Las técnicas que proporciona UML son bastante independientes del proceso y pueden ser utilizadas en varias metodologías.Ingeniería del Software-UML 62 Aquí se representa la instancia : Cluster que en principio reside en Nodo1 y que en cierto momento pasa a residir en Nodo2.rational.com/products/whitepapers/334. integra dos perspectivas: Organizativa: relativa a aspectos financieros. Técnica: relativa a la calidad y métodos ingenieriles y de diseño. Está basada en tres pilares: Personas. Las características fundamentales de esta metodología son las siguientes: Enfoque iterativo e incremental. Desarrollo orientado a objetos. 13 PROCESO UNIFICADO DE RATIONAL . Proceso. Rose permite especificar. el tipo de planificación de tareas que se utiliza en cada nodo. disponible en http://www. Además. 13 Para más información se recomienda consultar el documento “A Rational Development Process” de Philippe Kruchten. Una de estas metodologías es el Proceso Unificado de Rational. Altamente automatizada. . Herramientas y método. Rose sólo permite un diagrama de despliegue. comerciales y humanos. entre otras. Nótese que la instancia : A reside todo el tiempo en Nodo1.jsp. Por otro lado.

Elaboración (elaboration): Planificación de las actividades y recursos necesarios. Existe una coincidencia en el tiempo de los hitos desde el punto de vista organizativo con los hitos desde el punto de vista técnico. como es lógico: . incluyendo formación. el ciclo de vida se divide en varias iteraciones (cuyo número y duración depende de factores como la complejidad del software. Desde un punto de vista técnico. soporte y mantenimiento hasta que los usuarios estén satisfechos. especificación de requisitos y diseño de la arquitectura. experiencia del equipo y otros).Ingeniería del Software-UML 63 Las fases del ciclo de vida del Proceso Unificado de Desarrollo. desde el punto de vista organizativo. Construcción (construction): Construcción del producto y refinamiento hasta que el producto esté preparado para su uso. Transición (transition): Realizar la transición de los clientes al producto generado. son las siguientes: Concepción (inception): La “idea feliz”: especificación de la visión del producto final y los casos de negocio.

Prueba/mantenimiento. predominando al principio las actividades de análisis. Análisis. luego las de construcción y por último las de prueba y mantenimiento. . Arquitectura. Integración.. como se puede ver en el siguiente gráfico: El Proceso Unificado de Rational no está guiado por documentos. más tarde las de diseño. Diseño. etc. Implementación. para lo cual se recomienda la utilización de herramientas CASE apropiadas. sino por el producto en sí. Los documentos típicos a obtener pertenecen tanto al ámbito organizativo como técnico. interacción. incluyendo los modelos de casos de uso. El énfasis en cada una de estas actividades depende de la fase e iteración en la que nos encontremos.Ingeniería del Software-UML 64 Cada iteración consta de siete actividades: Planificación. clases.

Comprobar el modelo. Establecer las propiedades para la generación del código. Estas propiedades controlarán el código que será generado. Seleccionar una clase. componente o paquete. 3. 3.h y . Al crear un componente se puede especificar su estereotipo (p. Comprobar el modelo. Dependiendo del lenguaje utilizado. Esta asignación se hace arrastrando la clase desde el browser y “soltándola” en el componente o desde la ficha realizes de la especificación del componente. CÓMO GENERAR CÓDIGO . Objetos en los diagramas de secuencia o colaboración no mapeados a clases. como en el caso de C++. Crear los componentes.cpp). cabecera. 1. se deben seguir 6 pasos para la generación de código: 1. Este cambio se puede hacer para todo el modelo desde Tools Options (se recomienda hacer una copia con Clone y trabajar sobre ella) o para una clase en particular 14 Se recomienda consultar los apuntes de C++ dejados en el servidor donde se tratan conceptos como constructores por copia. etc. . es muy recomendable realizarlo. En general. una misma clase puede pertenecer a dos componentes distintos (. 5. o varias clases pueden estar asignadas a un mismo componente o. Rose proporciona unas propiedades por defecto que pueden ser cambiadas según se requiera.Ingeniería del Software-UML 65 GENERACIÓN DE CÓDIGO14. Asignar clases a componentes. programa principal. 6. cuerpo. Se deben crear los componentes necesarios y sus relaciones (diagrama de componentes). 2.) y el lenguaje en el que se generará (C++ en nuestro caso). 2. Generar el código. Asignar clases a componentes. Crear los componentes. una clase debe estar asignada a un solo componente. Utilizando la opción Tools Check Model se comprueba que el modelo es consistente antes de generar código. 4. Aunque no es obligatorio. plantillas y la STL.. ej. Accesos no permitidos entre clases causados por falta de visibilidad. Establecer las propiedades para la generación del código. En esta sección se dará una introducción básica sobre cómo generar y qué código se genera a partir de los modelos realizados en Rose. Algunos errores comunes que detecta esta opción son: Mensajes en los diagramas de secuencia o colaboración no mapeados a operaciones. 4.

sea la siguiente clase: Coche -cilindrada: double +potencia(): double El código generado para esta clase. Componentes (ficheros). También genera el esqueleto del código necesario para su implementación. 6. Rose puede generar los siguientes elementos: Clases. También se pueden seleccionar múltiples elementos mediante la tecla [Ctrl]. Cambiando el elemento seleccionado en el desplegable type de dicha opción se puede acceder a otros elementos susceptibles de ser modificados para la generación de código.Ingeniería del Software-UML 66 abriendo su especificación. sin embargo. Téngase en cuenta. Se puede seleccionar una clase. Atributos (incluyendo visibilidad. un componente o un paquete para generar su código. Por ejemplo. las relaciones.cpp según el estereotipo del componente. Relaciones (aunque sólo algunos tipos). el fichero o ficheros se generan en C:\Archivos de programa\Rational\Rose\C++\source siendo el nombre de archivo el nombre del componente y la extensión . tipos de los parámetros y tipo devuelto). Definición e implementación de las operaciones (privadas) set y get del atributo cilindrada. incluyendo la definición del atributo cilindrada y la operación potencia(). Seleccionar una clase. QUÉ SE GENERA .h o . Definición de las operaciones de comparación (igualdad y desigualdad) y la asignación. Entre las propiedades que se pueden establecer paralas clases están si Rose generará operadores de igualdad (operador == y operador !=) o si generará el destructor y la visibilidad del destructor en caso afirmativo. También genera el esqueleto del código necesario para su implementación. 5. incluye: Definición de la clase. que posiblemente la operación set se tendrá que retocar para . Declaraciones de operaciones (incluyendo parámetros. Definición del constructor y constructor por copia y destructor. dejando las opciones de generación de código por defecto. componente o paquete. Se puede generar código seleccionando Tools C++ Code Generation o desde el menú contextual. Generar el código. Por defecto. como por ejemplo. tipo y valor por defecto).

si se olvida modelar los cambios en el diagrama de clases y se vuelve a generar código.codegen_version preserve=yes Read the documentation to learn more about C++ code generator versioning.. Por ejemplo. Veamos ahora el esqueleto que crea Rose correspondiente a la implementación de la operación potencia: //## Other Operations (implementation) double Coche::potencia () { //## begin Coche::potencia%3A13C55B00DC. No se deben borrar los códigos que genera Rose. .. end module%1.. ya que le son necesarios para si se desea volver a generar código o se realiza ingeniería inversa.public preserve=yes //## end Coche%3A13C52B03A2. si sobre el código generado se añaden o suprimen directamente atributos u operaciones.body preserve=yes //## end Coche::potencia%3A13C55B00DC.codegen_version //## begin module%3A13C58701AE. para declaraciones públicas: // Additional Public Declarations //## begin Coche%3A13C52B03A2.3%. esta documentación aparecerá como comentario encima de la definición de la operación al generar el código. De esta forma. si documentamos la semántica de una operación de una clase.cpp . Al ser la programación orientada a objetos un proceso fundamentalmente iterativo. se perderán las operaciones y atributos introducidas manualmente.cp preserve=no //## end module%3A13C58701AE.public Proporciona también secciones para realizar “includes” y otras declaraciones adicionales.body } El programador debería generar el código del cuerpo de dicho método entre las líneas //## begin .cm //## begin module%3A13C58701AE. Rose también proporciona espacios para introducir nuevo código. El listado completo del código generado para la anterior clase es el siguiente: //## // // //## begin module%1. conviene realizar ingeniería inversa para que los nuevos elementos sean introducidos al modelo de forma “automática” (Rational Rose C++ Analyzer). dicho código será preservado ( preserve=yes ) si se vuelve a generar el código de esa clase. ya que.cp //## Module: Coche%3A13C58701AE. como en este caso sería intentar asignar un valor negativo a la cilindrada. por ejemplo. Main program //## Subsystem: <Top Level> //## Source file: C:\Archivos de programa\Rational\Rose\C++\source\Coche. Rose permite documentar la mayoría de los elementos. parte de esa documentación aparecerá como comentario en el código. Al generar código. Esqueleto para la implementación de la operación potencia().cm preserve=no // %X% %Q% %Z% %W% //## end module%3A13C58701AE.3%.Ingeniería del Software-UML 67 evitar la introducción de valores inválidos en el atributo. y //## end ..

additionalIncludes //## begin module%3A13C58701AE.includes //## begin module%3A13C58701AE.additionalDeclarations preserve=yes //## end module%3A13C58701AE. //## Other Operations (specified) //## Operation: potencia%3A13C55B00DC double potencia ().preface //## //## //## //## Class: Coche%3A13C52B03A2 Category: <Top Level> Persistence: Transient Cardinality/Multiplicity: n class Coche { //## begin Coche%3A13C52B03A2.additionalIncludes preserve=no //## end module%3A13C58701AE. int operator!=(const Coche &right) const.attr preserve=no double cilindrada.Ingeniería del Software-UML 68 //## begin module%3A13C58701AE. Coche(const Coche &right).protected preserve=yes //## end Coche%3A13C52B03A2.additionalDeclarations //## begin Coche%3A13C52B03A2.public protected: // Additional Protected Declarations //## begin Coche%3A13C52B03A2.public preserve=yes //## end Coche%3A13C52B03A2. // Additional Public Declarations //## begin Coche%3A13C52B03A2. //## end Coche::cilindrada%3A13C53501EA.declarations //## begin module%3A13C58701AE.initialDeclarations preserve=yes //## end Coche%3A13C52B03A2.preface preserve=yes //## end Coche%3A13C52B03A2.private preserve=yes //## end Coche%3A13C52B03A2.initialDeclarations public: //## Constructors (generated) Coche().includes preserve=yes //## end module%3A13C58701AE. //## Equality Operations (generated) int operator==(const Coche &right) const.private private: //## implementation // Data Members for Class Attributes //## begin Coche::cilindrada%3A13C53501EA.attr private: double {U} . //## Destructor (generated) ~Coche().protected private: //## Get and Set Operations for Class Attributes (generated) //## Attribute: cilindrada%3A13C53501EA const double get_cilindrada () const. // Additional Private Declarations //## begin Coche%3A13C52B03A2. //## Assignment Operation (generated) Coche & operator=(const Coche &right).declarations preserve=no //## end module%3A13C58701AE. void set_cilindrada (double value).

//## end Coche::get_cilindrada%3A13C53501EA.body preserve=yes //## end Coche::Coche%3A13C52B03A2_const.get preserve=no return cilindrada.initialization preserve=yes //## end Coche::Coche%3A13C52B03A2_const.hasinit //## begin Coche::Coche%3A13C52B03A2_copy.body } int Coche::operator!=(const Coche &right) const { //## begin Coche::operator!=%3A13C52B03A2_neq.body preserve=yes //## end Coche::operator==%3A13C52B03A2_eq.implementation preserve=yes //## end Coche%3A13C52B03A2. //## begin Coche%3A13C52B03A2.initialization { //## begin Coche::Coche%3A13C52B03A2_copy.hasinit preserve=no //## end Coche::Coche%3A13C52B03A2_copy.body } Coche & Coche::operator=(const Coche &right) { //## begin Coche::operator=%3A13C52B03A2_assign.body preserve=yes //## end Coche::~Coche%3A13C52B03A2_dest.set } // Class Coche Coche::Coche() //## begin Coche::Coche%3A13C52B03A2_const.set preserve=no cilindrada = value.body preserve=yes .Ingeniería del Software-UML 69 // Additional Implementation Declarations //## begin Coche%3A13C52B03A2.body preserve=yes //## end Coche::Coche%3A13C52B03A2_copy. //## end Coche::set_cilindrada%3A13C53501EA.postscript // Class Coche //## Get and Set Operations for Class Attributes (inline) inline const double Coche::get_cilindrada () const { //## begin Coche::get_cilindrada%3A13C53501EA.postscript preserve=yes //## end Coche%3A13C52B03A2.body } Coche::~Coche() { //## begin Coche::~Coche%3A13C52B03A2_dest.hasinit //## begin Coche::Coche%3A13C52B03A2_const.body } Coche::Coche(const Coche &right) //## begin Coche::Coche%3A13C52B03A2_copy.initialization preserve=yes //## end Coche::Coche%3A13C52B03A2_copy.get } inline void Coche::set_cilindrada (double value) { //## begin Coche::set_cilindrada%3A13C53501EA.initialization { //## begin Coche::Coche%3A13C52B03A2_const.implementation }.hasinit preserve=no //## end Coche::Coche%3A13C52B03A2_const.body preserve=yes //## end Coche::operator=%3A13C52B03A2_assign.body } int Coche::operator==(const Coche &right) const { //## begin Coche::operator==%3A13C52B03A2_eq.

.declarations //## begin module%3A13C58701AE... Ej. private: ClaseB *the_ClaseB.epilog preserve=yes //## end module%3A13C58701AE. ..body } // Additional Declarations //## begin Coche%3A13C52B03A2. 1 ClaseB class ClaseB { . }. ....declarations preserve=yes //## end Coche%3A13C52B03A2.Ingeniería del Software-UML 70 //## end Coche::operator!=%3A13C52B03A2_neq.. }. Una asociación bidireccional uno a uno se implementa mediante un atributo puntero a la otra clase en cada una de las clases. Si la asociación es unidireccional. private: ClaseB *the_ClaseB...: ClaseA 1 class ClaseA { . class ClaseB { .. . }. ... private: ClaseA *the_ClaseA.epilog CÓDIGO GENERADO EN LAS RELACIONES . }..body } //## Other Operations (implementation) double Coche::potencia () { //## begin Coche::potencia%3A13C55B00DC. se define el puntero sólo en la clase que tiene navegabilidad: ClaseA 1 1 ClaseB class ClaseA { .body preserve=yes //## end Coche::potencia%3A13C55B00DC.

la lista (list15). .h. hay que añadir la librería list. Para ello. Sin embargo. }.... Si la asociación es uno a muchos. 15 list es una clase parametrizada (plantilla). . utilizando por ejemplo la pestaña C++ de las especificaciones del componente (sección AdditionalIncludes).* ClaseB class ClaseA { . Este es el código generado por defecto y no es compilable directamente por C++. Además.Ingeniería del Software-UML 71 Si la asociación es uno a un número determinado.. por ejemplo. Por ejemplo: ClaseA 1 4 ClaseB class ClaseA { .. private: ClaseB *the_ClaseB[4]..... . la definición de UnorderedUnboundedByReferenceContainer que está por defecto a UnboundedSetByReference<$targetClass>> por list<*targetClass>. a no ser que creemos un contenedor con dicho nombre y semántica. class ClaseB { . class ClaseB { .. alguno de los contenedores proporcionados por la STL ( Standard Template Library) de C++. por defecto se utili zará una matriz de punteros.. por ejemplo.. }. se debe cambiar en las opciones de compilación (seleccionando el tipo Project). Nótese que UnboundedSetByReference<ClaseB> the_ClaseB significa que el atributo the_ClaseB será un conjunto (sin número máximo de elementos) de valores por referencia a objetos de la la clase ClaseB (punteros).. se podría utilizar. private: UnboundedSetByReference<ClaseB> the_ClaseB. }. se necesita algún tipo de contenedor para los punteros: ClaseA 1 0. }.

class ClaseA { .. }.. }.. Por ejemplo: ClaseA 1 3 ClaseB class ClaseA { . class ClaseB { .h> ..... }.. private: ClaseB the_ClaseB[3]. .... private: list<*ClaseB> the_ClaseB.. por valor): ClaseA 1 class ClaseA { . class ClaseB { . . ClaseB En el caso de relaciones de dependencia. la parte compuesta se tiene como un atributo de la clase (esto es.. private: ClaseB *the_ClaseB[3]..... . Rose sólo incluye en el código los “includes” que sean necesarios. Una relación de agregación genera un código similar a una asociación..Ingeniería del Software-UML 72 El código generado ahora. }. que puede ser compilado sin problemas. Rose también tiene especificaciones propias para generar asociaciones en la que los elem entos deben estar ordenados que podemos adaptar a nuestras librerías o a la STL para generar código compilable.. }. Sin embargo. será: #include <list. 3 class ClaseB { . en la relación de composición. . }..

. Por ejemplo: Padre Hija class Padre { . }. Rose también genera código para clases parametrizadas (plantillas)... class Hija: public Padre .n ClaseB ClaseC . } . EJEMPLO. Por ejemplo: T Plantilla template <void T> class Plantilla { . veremos lo que se ge nera en la siguiente asociación: ClaseA 1 0.. Como ejemplo de generación de código.. }.Ingeniería del Software-UML 73 Rose también genera código para las relaciones de generalización... CÓDIGO GENERADO PARA CLASES PARAMETRIZADAS .

. . class ClaseC { . .. ROSE Y LA GENERACIÓN DE CÓDIGO .. }.. Será misión del programador hacer que dicha clase sea persistente.Ingeniería del Software-UML 74 class ClaseA { . }. Hay muchos aspectos que quedan fuera de la generación de código de Rose. una clase declarada en Rose como persistente no genera ningún código que soporte dicha persistencia.. ... }. class ClaseB { . private: UnboundedSetByReference<ClaseC> the_ClaseC... private ClaseB *the_ClaseB. Obsérvese que se podría utilizar co mo contenedor una lista para hacer que el código fuera compilable.. Por ejemplo.

Sign up to vote on this title
UsefulNot useful