P. 1
temaUML

temaUML

|Views: 1.735|Likes:
Publicado porMarycita Llj

More info:

Published by: Marycita Llj on May 28, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

08/13/2013

pdf

text

original

Sections

  • DIAGRAMA DE CASOS DE USO3
  • DIAGRAMAS DE INTERACCIÓN
  • DIAGRAMA DE SECUENCIA
  • DIAGRAMA DE COLABORACIÓN
  • DIAGRAMA DE ESTADOS
  • DIAGRAMA DE ACTIVIDAD9
  • DIAGRAMA DE CLASES
  • DIAGRAMA DE OBJETOS
  • DIAGRAMAS DE IMPLEMENTACIÓN
  • DIAGRAMAS DE COMPONENTES
  • DIAGRAMA DE DESPLIEGUE
  • PROCESO UNIFICADO DE RATIONAL13

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.

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

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

Realización. 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). el elemento dependiente indica el elemento del que depende): . 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. La relación de asociación es una relación estructural entre dos elementos.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. Dependencia. Relaciones. La relación de generalización conecta a elementos vinculados por una relación padre/hijo (generalización/especialización). Asociación. Es la relación que hay entre una especificación y su implementación. Un cambio en el elemento requerido (el independiente) puede afectar al del otro elemento (el dependiente). en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. 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. 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. 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.

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

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

Ingeniería del Software-UML 9 Veamos. 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. para empezar. los casos de uso (Transferir Fondos. Disponer e Ingresar) que son las funcionalidades que el cajero proporciona y. 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. Son una herramienta muy general que permite . y no en las actividades internas que tengan lugar en dicho sistema. por último. Cambiar PIN. Opcionalmente. Los diagramas de caso de uso se centran en la interacción entre los usuarios y los sistemas. Empleado de Banca y Sistema de Crédito) que son los agentes externos que interactúan con el cajero automático. las relaciones entre actores y casos de uso (las líneas que van entre actores y casos de uso). para validar el diseño contra ellos. 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. Ver Saldos. Realizar Pago. 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).

Fernando. de expresar los requerimientos funcionales. se puede decir que los diagramas de caso de uso: Representan una forma estructurada. El tiempo es un actor cuando el paso de un cierto tiempo dispara algún evento en el sistema. 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. instancias). por ejemplo la imagen de un miniordenador o un servidor. nos vienen ya dados y es nuestro sistema el que se debe adaptar para comunicarse con ellos). Debido a que el tiempo está fuera de nuestro control. etc. La creación de los diagramas es un proceso de descubrimiento. pero informal. Un actor5 es un rol o conjunto homogéneo de roles que un usuario (persona o máquina) desempeña respecto al sistema. Son. El segundo tipo de actor es otro sistema. 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. Por ejemplo. Son un mecanismo para obtener el consenso en la visión del sistema y sus objetivos entre clientes y desarrolladores. 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. figurando debajo de él el nombre: Cliente Un actor representa una clase. y un actor del mundo real puede (y de hecho normalmente lo hace) representar varios roles dispares. 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. de forma equivalente. a medianoche el sistema podría realizar un proceso de control del estado del cajero. Nuestro sistema puede interaccionar con otros sistemas. Por ejemplo. De forma resumida. - - Representar un actor del tipo sistema externo o tiempo como un hombre de alambre puede resultar poco claro. El nombre “actor” con el que se denominó a este elemento en UML no fue acertado. No se deben usar nombres de personas ya que. que son externos y están fuera de nuestro control (esto es. agentes externos al sistema y que interactúan con él. Son fáciles de entender. ya que lo que realmente representa el elemento UML es un rol (o conjunto homogéneo de roles). Los actores se pueden clasificar como primarios o secundarios.Ingeniería del Software-UML 10 especificar las reglas de un negocio 4. de pendiendo si participan en las funciones principales del sistema (pertenecientes al ámbito del negocio. a la cual pueden pertenecer uno o más elementos (o. un actor se simboliza mediante un hombre “de alambre”. Luis. por ejemplo. además de analistas. por tanto. Hay tres tipos principales de actores: usuarios del sistema. 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. ACTORES . 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. Gráficamente. sacar dinero). El tercer tipo de actor es el tiempo. instancias del actor cliente serían José. que suele requerir varias sesiones. es un actor. tanto por el cliente como por el desarrollador. De forma similar se puede hacer con el tiempo. 5 4 . si tomamos por ejemplo el caso del cajero automático.

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

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

Hay cuatro tipos de relaciones que pueden aparecer en un diagrama de casos de uso. la flecha va de “A” a “B”) indica que el caso de uso “A” contiene el comportamiento indicado por “B”. 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”. a la que se puede añadir una punta de flecha para indicar quién inicia la comunicación. La relación de inclusión en un caso de uso “A” de caso de uso “B” (esto es. tal y como se verá más adelante). El lugar o lugares donde dicho comportamiento se incluye debe especificarse en el flujo de eventos de “A”. Gráficamente es una línea. 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. Además. el actor “Cliente” se comunica con el caso de uso “Realizar Pago”. Relación de inclusión6. Es el tipo más normal de relaciones y tiene lugar entre un caso de uso y un actor. Esta factorización permite especificar de una sola vez un comportamiento común a varios casos de uso. Por ejemplo: Cliente Realizar Pago Sistema de Crédito En este caso. el caso de uso “Realizar Pago” se comunica con el actor “Sistema de Crédito”. siendo el actor quien inicia la comunicación. En versiones anteriores de UML a esta relación se le denominaba de uso (uses). La relación de inclusión se muestra gráficamente como una relación de dependencia con el estereotipo «include». 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. Relación de comunicación.Ingeniería del Software-UML 13 RELACIONES . 6 .

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

No dibujar flechas entre casos de uso. es decir. excepto para relaciones de inclusión. extensión o generalización. . existe para producir un resultado de valor mensurable para los actores. Por tanto. Un caso de uso representa una funcionalidad o un modo de utilizar el sistema. actores y descripciones deben ser significativos para el cliente (deben pertenecer al lenguaje del negocio y la organización del cliente). y a un nivel relativamente alto. El sistema no existe para leer/escribir en una base de datos. tanto a los desarrolladores como a los clientes (para casos de uso abstracto). Es importante que cualquier requerimiento funcional aparezca al menos en un caso de uso. ya que de otro modo no será implementado. No se debe partir del nivel CRUD. Es importante evitar personas con pensamiento “lineal” (al estilo de los programadores). - - - - 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). se deben usar otras técnicas.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. No modelar la comunicación entre actores. a un nivel muy fino y dificultarían su entendimiento por el cliente. un caso de uso puede representar la introducción de una información y otro caso de uso el acceso a la misma. 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. No se debe representar el flujo de información entre casos de uso. Se debe elegir con cuidado las personas participantes en su creación. Se deben considerar también casos de uso relacionados con el mantenimiento del sistema. 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. 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. ya que está fuera del ámbito del sistema 7. pero no indica el cómo se implementa esa funcionalidad. los nombres de los casos de uso. Además. personas que intentan describir todos y cada uno de los pasos y detalles. Los diagramas de casos de uso sólo pueden capturar requerimientos funcionales. sin que exista ninguna comunicación entre ambos casos. Los diagramas de casos de uso deben proporcionar fácilmente una visión de lo que el sistema proporciona. Para capturar otro tipo de requerimientos o detallarlos. ya que aparecerían demasiados casos. NORMAS PARA CREACIÓN DE UN DIAGRAMA DE CASOS DE USO . Todo caso de uso debe ser iniciado por un actor (excepto los casos de uso incluidos o las extensiones).

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). pero también puede tomar pedidos como cualquier otro vendedor. En el ejemplo se puede ver una forma de utilización de las notas. Los casos de uso abstracto deben capturar lo esencial y no intentar detallar demasiado. Se debe cuidar la granularidad. Para hacerlo más real. ya que en vez de las reglas del negocio (el qué) podemos estar dando directamente una solución basada en el sistema existente. si se diera esta situación. El supervisor es el único que puede proporcionar crédito. y después podrá hacer una o más operaciones sin necesidad de volver a identificarse. A continuación. - EJEMPLO DE UN DIAGRAMA DE CASOS DE USO . 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. Véase que se ha optado por modelar a nivel de sistema de información (aparece el actor “vendedor” y no el actor “cliente”). - EJEMPLO DE LA DOCUMENTACIÓN DE UN CASO DE USO . Notas: El supervisor es una especialización de vendedor. Sin embargo. que pudiera no ser lo suficientemente buena o flexible. .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 supondrá que el cliente sólo se identifica una vez (representado por el caso de uso “Validar usuario”). Se ha añadido la multiplicidad en las relaciones de comunicación. una pequeña descomposición de los casos puede hacerlos más fáciles de comprender y simplificar su diseño. ya que es una especialización de éste. 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.

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

o la clase (empezando por letra mayúscula) a la que pertenece precedida de dos puntos. así como de los mensajes que se envían entre ellos. Dependiendo de la misión principal a la que se destine el diagrama. 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. 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. Ambos diagramas son prácticamente equivalentes entre sí. : Persona Objeto anónimo de la clase Persona. dentro del cual se incluye. Hay dos clases de diagramas de interacción: el diagrama de secuencia y el diagrama de colaboración. Modelan. Esp ecifica el algoritmo o procedimiento asociado con una operación. luis : Persona Objeto de nombre luis perteneciente a la clase Persona. convendrá usar uno u otro. o ambos: Por ejemplo: ana Objeto de nombre ana (no se especifica explícitamente la clase a la que pertenece). tal y como se verá más adelante. aspectos dinámicos del sistema. Solicitud de una operación determinada a un objeto concreto. Notación para la representación de objetos. Método: Mensaje: La implementación de una operación. subrayado. . 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. ya que la información subyacente en la que se basan es la misma. 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. el nombre del objeto (empezando por letra minúscula). Un objeto se representa gráficamente como un rectángulo.

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

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

aunque podría hacerse para interacciones que modelen escenarios en tiempo real. no se especifica una graduación en el eje del tiempo. Generalmente. De cada objeto parte una línea discon tinua. Por ejemplo. que representa la vida del objeto durante la interacción. 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. . En el otro eje se muestran los objetos que participan en la interacción.Ingeniería del Software-UML 21 DIAGRAMA DE SECUENCIA. 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). como se verá más adelante). Usualmente. éste aparecerá en el eje horizontal y su línea llegará hasta el final del 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. Consta de dos ejes. transcurriendo éste de arriba a abajo. 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. así como posibles argumentos que pueden utilizarse como valores de entrada y/o salida. el eje vertical es el eje del tiempo. vamos a modelar un escenario que muestre una instancia del flujo de eventos primario del caso de uso “Validar usuario”. llamada línea de la vida. Si el objeto existe durante toda la interacción.

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. Verificar PIN. 3. el tiempo durante el cual está realizando una acción directa o indirectamente). 4. Pedir PIN. aunque objetoB es destruido. Opcionalmente. Un objeto se destruye mediante un mensaje de estereotipo «destroy». el siguiente fragmento simplificado: objeto1 objeto2 objeto3 1: mensaje1 2: mensaje2 . dando finalizada la línea de vida con un aspa. por ejemplo.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. Por otro lado. Muestra las opciones. Introducir PIN. 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. objetoC es creado y destruido durante la interacción. por lo que su línea de la vida está interrumpida en el punto de su destrucción. Leer la tarjeta. Insertar tarjeta en el cajero 2. Véase. Responsabilidades del sistema Un objeto se crea mediante un mensaje de estereotipo «create» que apunta al objeto que se crea. 6. mientras que objetoE es creado y continua existiendo al final del diagrama (al igual que objetoA). se puede mostrar en los diagramas de secuencia el foco de control. 5.

Ingeniería del Software-UML 23 En este ejemplo. REFINAMIENTO . Un ejemplo de script sería: objeto1 objeto2 IF (condicion= TRUE) THEN 1: mensaje1 ELSE 2: mensaje2 En este ejemplo. 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. objeto1 mandará mensaje1 a objeto2. manda un mensaje (mensaje1) al objeto2 para requerirle una cierta operación. 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. Además. o cuando se debe esperar la terminación de la operación solicitada por un mensaje para continuar. ya que puede complicar en demasía el diagrama. Los diagramas de secuencia permiten mostrar escenarios de forma que sean comprensibles tanto por clientes como por desarrolladores. De igual forma. objeto2 tiene también el control. le mandará mensaje2. UML permite añadir la condición delante del mensaje (como por ejemplo [x>0] mensaje. si la lógica de la base de datos cambia. y serían muy sensibles a los cambios. Para realizar la operación. si x es mayor que cero). Sin embargo. de forma que se separe la lógica de la aplicación de la lógica de la base de datos. en principio. Aunque. sólo es necesario realizar cambios en la clase encargada de las transacciones. y si no se cumple. objeto1 tiene el control al empezar. 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). En un momento determinado. objeto2 necesita un servicio de objeto3. De esta forma. se suelen crear objetos que manejen transacciones. De forma similar. una vez que los clientes h an dado su visto bueno a los mismos. este tipo de clases suelen ser fácilmente reutilizables. 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. aunque no se debe abusar de esta posibilidad. los diagramas de secuencia están pensados para mostrar un único escenario. Por ejemplo. el control de objeto2 finaliza al terminar el servicio que le había requerido objeto1. Aunque Rose no lo soporta. Rose permite mediante los Scritps modelar varios flujos simultáneamente. También permite desdoblar la línea de vida de un objeto en varias para mostrar flujos alternativos. A partir de ese momento. . se suelen refinar añadiendo detalles de diseño que serán útiles a los desarrolladores. si se cumple condicion=TRUE. Téngase en cuenta que para el caso de un sólo hilo de ejecución. para lo cual le envía el mensaje2. esto es.

Hay una diferencia significativa entre los diagramas de secuencia y los de colaboración. 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. Si no coincide. 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. Si la dirección del flujo coincide con la del mensaje. aunque aquí también aparece el orden de los mensajes. 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. como por eje mplo cuando se pasa una lista. se trata de un valor de retorno. lo que les hace muy útiles para los desarrolladores. valorar el impacto que supondría un cambio en una clase. sólo se utiliza esta técnica cuando el flujo de datos es grande.Ingeniería del Software-UML 24 DIAGRAMA DE COLABORACIÓN. Un diagrama de colaboración muestra los objetos que intervienen en una relación. . se trata de un argumento de entrada. Estos diagramas permiten. y es que en los de colaboración se pueden añadir explícitamente flujos de datos. no es fácil seguir la secuencia de los mismos. 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). por ejemplo. 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. Sin embargo se ve claramente qué objetos participan y las relaciones que existen entre ellos. Por ejemplo.

DIAGRAMA DE ESTADOS. Sin embargo. Por ejemplo. 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). los diagramas de estado resultan de gran utilidad para los desarrolladores. En estos casos. esto es. objeto2 es accesible a objeto1 por ser local a objeto1 (nótese que en Rose. por ejemplo. las clases que tengan un atributo llamado estado.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 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. jubilado o incapacitado. Por ejemplo: 1: create() 2: mensajeA() 3: destroy() objeto1 objeto2 {transient} L En este caso. 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. Los diagramas de estado sólo se suelen realizar para objetos (clases) que tienen un comportamiento dinámico significativo. 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. lo que aparece es una L en el extremo del enlace). Esto sucede con los objetos reactivos. como por ejemplo «local». si no tiene ninguna relación. Un evento. un objeto de tipo fax podría encontrarse en los estados inactivo. También se pueden añadir restricciones a los objetos que indiquen su persistencia: {new} si son creados 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 una relación entre persona y compañía para la que trabaja. siendo creado y destruido en la interacción (como de hecho se puede comprobar por los mensajes que se le envían). haría que pasara al estado inactivo. si un objeto persona tiene una relación con una o más compañías significará que es un empleado. {destroy} si son destruidos o {transient} si son creados y destruidos durante la interacción. se puede buscar en primer lugar aquellos objetos que se comporten de forma diferente según los valores de sus atributos. en vez de aparecer el estereotipo «local». podría estar parado. El estado en que se encuentre un objeto será por tanto dependiente de su historia anterior. Por ejemplo. Para encontrar clases con un comportamiento dinámico significativo. El objeto2 es además transitorio. transmitiendo o recibiendo. como por ejemplo pulsar la tecla “Parar” cuando se encuentra en el estado transmitiendo. siendo candidatos. y en cada uno de estos estados tendría un comportamiento diferente. Esto significa que dicha relación es opcional y puede que el comportamiento en ese caso sea muy diferente. que son aquellos cuyo comportamiento viene dirigido por los eventos que recibe.

Por ejemplo. Se considera una acción no interrumpible. 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. Mientras un objeto está en un estado particular. Un estado se representa gráficamente como un rectángulo redondeado. Las transiciones. una acción es una tarea que tiene lugar mientras un objeto se encuentra en un determinado estado. Dicho de otra forma. 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. puede realizar cero. Se considera una acción no interrumpible. con el formato etiquetaDeAcción/expresiónDeAcción. Un estado una situación en la vida de un objeto durante la cual se satisface alguna condición. Por ejemplo: NombreEstado Dentro del estado (o adjunto en el extremo sup erior izquierdo en ciertas ocasiones) se puede escribir el nombre del estado. cuando un objeto está en un estado que contiene una acción etiquetada con do. Estas son: entry: Indica que la tarea se realiza cuando el objeto entra en dicho estado.Ingeniería del Software-UML 26 En un diagrama de estados aparecen uno o más estados relacionados entre sí por transiciones. En este contexto. 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. do: Indica que la tarea se realiza mientras el objeto permanezca en el estado en que se encuentra o hasta que termine dicha tarea. se realiza alguna actividad o se espera algún evento. . una o más acciones internas. exit: Indica que la tarea se realiza cuando el objeto abandona el estado. en general. Se considera una acción interrumpible. La etiqueta de acción identifica las circunstancias o eventos bajo los cuales la expresión de la acción será invocada. Estas acciones se muestran en una sección debajo del nombre del estado.

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

el estado origen y el estado destino pueden coincidir. Si. Una transición es el paso de un estado a otro. significa que la transición ocurre inmediatamente después de satisfechas las posibles acciones entry. siendo opcionales todos los componentes. pasando al estado inactivo. La acción es un comportamiento no interrumpible que ocurre como parte de la transición. Se muestra gráficamente como una flecha que va del estado origen al estado destino: EstadoOrigen EstadoDestino Este movimiento puede ser reflexivo. ya que otras transiciones al estado destino pueden requerir otras acciones (o ninguna). es decir. La condición de guarda. En el estado inactivo puede recibir el . El formato general de estas especificaciones es: evento(listaDeParámetros) [condiciónDeGuarda] / acción . do y exit del estado. debe cumplirse para que la transición sea posible.Ingeniería del Software-UML 28 TRANSICIÓN . Por ejemplo. el robot se para y además suena un pitido de alarma. 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). estando en movimiento se activa el sensor de muro. En caso de no indicarse evento. 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). 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. Un evento es un suceso que ocurre y que puede causar la transición de un estado a otro. por otro lado. si se especifica. 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. Nótese que no siempre es posible sustituir esta acción por una acción interna entry en el estado destino.

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

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. Estas reguiones se separan por lineas de puntos en el superestado. existe un nuevo est ado al que se accede desde el estado Activo cuando dimite el profesor del curso. tal y como se verá. el superestado que contiene a todos los subestados debe estar marcado con H* en vez de H. Para modelar estados compuestos concurrentes se utilizan regiones concurrentes. Ejemplo: Recibiendo clase Incompleto Práctica1 hecha Práctica2 hecha terminado Trabajo Aprobado aprobado Examen suspendido Suspenso .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. es posible utilizar barras de sincronización. Alternativamente a las regiones concurrentes. como las que se utilizan en el diagrama de actividades. Para ello. es también posible volver al último subestado pertenezca al nivel que pertenezca.

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

aunque realmente una actividad es un estado de acción. 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. Modelar información procedimental. . Diagrama de estados Centrado en los estados de un objeto o sistema. Sin embargo.Ingeniería del Software-UML 32 9 DIAGRAMA DE ACTIVIDAD . Énfasis en el orden procedimental y/o flujo de objetos (control procedimental). 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. Los diagramas de actividad permiten modelar el comportamiento de un sistema o alguno de sus elementos. se ha evitado intencionadamente el uso de la palabra estado al hablar de las actividades. Opcionalmente. Es interesante comparar las diferencias entre los diagramas de estados y actividades. los diagramas de actividad de UML son un caso especial de una máquina de estados. Los diagramas de actividad son útiles para describir flujos de evento en los casos de uso. 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. para evitar confusiones. La siguiente tabla es un resumen de ellas: Diagrama de actividades Centrado en las actividades de un proceso. Los diagramas de actividad permiten: Modelar el flujo de trabajo de un negocio. por lo que comparte ciertas características comunes con los diagramas de estado. Énfasis en la reacción al entorno (control por eventos). las actividades que tienen lugar entre un conjunto de objetos (clases) y las operaciones o métodos de las clases. Veamos a continuación un ejemplo de diagrama de acti vidad. Sistema 9 Actualmente.

Las actividades pueden describirse usando lenguaje natural. Una actividad compuesta no está concluida hasta que no han concluido sus subactividades. Las condiciones de guarda de una decisión deben ser mutuamente excluyentes. 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. Una transición se dispara cuando termina de realizarse la actividad de la que parte. Para indicar que una actividad contiene subactividades. que indican el orden en que se deben de realizar las actividades. 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. que suelen ser model adas utilizando un diagrama de actividad propio. se añade un pequeño símbolo de composición en su esquina inferior derecha. dependiendo del elemento cuyo comportamiento se esté modelando. Las actividades se relacionan unas con otras mediante transiciones. tal y como se puede ver en el siguiente ejemplo: Actividad Compuesta . Una actividad puede estar compuesta de un conjunto de subactividades. Esto permite realizar decisiones o bifurcaciones basadas en las condiciones de las guardas. 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. También es posible añadir condiciones de guarda a las transiciones. empezando desde el punto de inicio del diagrama hasta llegar a un punto final del mismo.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.

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.

paquetes. se produce una espera hasta que se recibe una señal que dispara la transacción. cada uno no tiene necesariamente que representar divisiones del modelo subyacente.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. como objetos o enlaces. Los diagramas de clases son usados prácticamente en la totalidad de sistemas en que se utiliza UML para su modelado. 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. relaciones e incluso instancias. Esto permite asegurar que el sistema está bien diseñado desde el principio. Por ejemplo: Levantarse Encender caferera Coger taza : Café Café hecho Beber café DIAGRAMA DE CLASES. Para sistemas no triviales. 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). sino que se utilizarán según convenga. Pueden contener clases. Su símbolo es: Optativamente. Cuando se utilizan varios diagramas. Su símbolo es: El icono de recepción de señal equivale a un estado de espera. interfaces. . pudiendo una misma clase aparecer en diagramas diferentes para representar distintas vistas del modelo. Los diagramas de clases son una potente herramienta de diseño. Los diagramas de clases se utilizan para mostrar la estructura estática del sistema modelado. esto es.

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. la siguiente los atributos y la última las operaciones. con los significados usuales. La visibilidad puede ser pública. En este caso. .. 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. protegida o privada (-). 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). Opcionalmente. La notación general para una clase es un rectángulo dividido en tres secciones. También permite especificar otras propiedades. Las clases son los componentes fundamentales de los diagramas de clases.) al final de la sección de la que se hayan suprimido atributos u operaciones. estáticos o transitorios. se pueden añadir más secciones para indicar otra información. 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.Ingeniería del Software-UML 38 CLASES. conviene añadir puntos suspensivos (. en cuyo caso tampoco se mostrará la línea que las separa. etc. como responsabilidades de la clase. También es posible otras visibilidades dependientes del lenguaje. como por ejemplo si los objetos son persistentes. Tampoco es necesario visualizar todos y cada uno de los atributos y operaciones. eventos que maneja.. Por ejemplo: Punto coordenadaX coordenadaY mostrar() ocultar() posicionX() posicionY() Tanto la sección de los atributos como la de las operaciones pueden no mostrarse. excepciones que puede generar.

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

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

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

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

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. También se deben examinar posibles relaciones todo-parte (que posiblemente se podrán modelar como relaciones de composición o agregación). 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). sería posible extraer características comunes entre algunas clases del segundo nivel que permitiera la creación de un nuevo nivel). Generalización. en el sentido de clasificación de “especies” en ancestras y descendientes. Una de las características de la herencia es que permite simplificar la construcción de clases relacionadas.Ingeniería del Software-UML 43 dependencia). 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. Terrestre y Aéreo son abstractas. Las generalizaciones de pueden crear mediante un proceso descendente (de arriba a abajo. 11 Clasificación. Gráficamente. de las más particulares a las más generales). no se debe abusar de ella (ya que puede resultar compleja su utilización). Un esquema con demasiados niveles (más de cuatro o cinco) es usualmente demasiado complicado de entender. posiblemente. de la clase más general a la más particular) o ascendente (de abajo a arriba. un esquema de sólo dos niveles y muy ancho no suele estar aprovechando la potencia de la herencia (ya que. Aunque la descendencia múltiple puede ser muy conveniente en algunos casos. aunque algunos lenguajes. 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. luego no se puede instanciar ningún objeto de ellas. Todos los lenguajes orientados a objetos permiten la herencia simple (una clase puede descender a lo sumo de otra). . permiten la herencia múltiple (una clase puede descender de varias clases padre). También se debe cuidar el esquema de herencia. como C++.

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

por ejemplo. Es un atributo que califica una asociación.. estamos expresando que las personas trabajan para las compañías.* 1. Se puede indicar el rol que desempeña una o ambas clases en la asociación. Téngase en cuenta que el sentido del nombre de la asociación no restringe la navegabilidad.. y una persona podrá trabajar en cero (que representaría el caso de estar desempleada) o más compañías. pueden modelarse asociaciones reflexivas: Persona Esta asociación reflexiva podría modelar. es decir.. 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. 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). Calificador. 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 0. Dado un objeto origen y un valor determinado para el calificador. la relación “es familiar directo de”. Por ejemplo: titular Nº cuenta: int 0. Es posible indicar el estereotipo de la asociación encima del nombre. Opcionalmente se puede añadir un pequeño triángulo que indique el sentido en que se debe interpretar.* 0. Es un nombre descriptivo que indica la naturaleza de la asociación. siendo también posible indicar una cadena de propiedades a la derecha del nombre o debajo. Por ejemplo: Compañía patronal empleado Persona - Multiplicidad.Ingeniería del Software-UML 45 Una clase puede relacionarse consigo misma. para una compañía podrán trabajar una o más personas. Por ejemplo: Trabaja para Compañía Persona En este ejemplo. Roles.1 Banco Persona .* Persona En este caso.

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

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

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

peso(): double volumen(): double . posiblemente. En el caso de usar la notación resumida... Por ejemplo: Furgoneta Mensurable Alquilable Las interfaces pueden evitar en ciertos casos el uso de herencia múltiple.Ingeniería del Software-UML 49 Por ejemplo: Saco . Por ejemplo: Saco Mensurable Automóvil Mensurable Cuando una clase realiza un interface.. 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. «interface» Mensurable peso(): double volumen(): double Automóvil . ya que no se ha . y una clase puede satisfacer varios interfaces. ambas implementan las operaciones indicadas en el interface. debe implementar todas las operaciones indicadas en dicha interface y. se unirá el interface a la clase que lo implementa por una línea continua. se indica que tanto Saco como Automovil “realizan” el interface Mensurable... otras exclusivas de la clase.. En este caso. es decir. peso(): double volumen(): double .. Varias clases pueden satisfacer un interface (como en el ejemplo anterior)..

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. Dependencia. Los interfaces son soportados por lenguajes como Java o Corba. fomentando la reutilización. la clase independiente debe tener visibilidad global. la clase Cliente (dependiente) dependerá de servicios proporcionados por la clase Servidor (independiente). Es un tipo de relación unidireccional. del método perteneceGrupoRiesgoSida(): bool. Por ejemplo: Cliente Servidor En este caso.Ingeniería del Software-UML 50 modificado el interface). Por ejemplo. El elemento dependiente (cliente) requiere conocer al elemento independiente (suministrador) y que éste esté presente. ya que el elemento dependiente debe conocer al independiente. ya que esta última es independiente de la primera (no la necesita). . suponiendo que la clase Persona lo implementara. Gráficamente se muestra como una línea discontinua acabada en flecha que va del elemento dependiente al independiente (esto es. por ejemplo. Para que la clase dependiente tenga acceso a la clase independiente. que sí sería de incumbencia en una relación Médico-Persona). y un cambio en la clase Servidor puede ocasionar que la clase Cliente necesite ser adaptada. Otra de las posibilidades de los interfaces consiste en limitar el acceso en las asociaciones. 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). 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. la clase en el extremo contrario sólo podrá acceder a las operaciones indicadas en 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. el elemento dependiente señala al elemento del que depende). pero el independiente desconoce la existencia del elemento dependiente. Una dependencia es una relación entre un elemento dependient e (el cliente) y un elemento independiente (el suministrador del servicio requerido). Un cambio en la clase Cliente no tiene ningún efecto sobre la clase Servidor. como en el siguiente ejemplo: Compañía : Empleado Persona Esto evitaría.

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

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

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

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

esto es. objetos. 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). relaciones que se dan en un momento dado. esto es. Este caso sucede. También es posible especificar el estado en que se encuentra el objeto. por lo que se debe utilizar un diagrama de clases para representar un diagrama de objetos. se le puede denominar diagrama de objetos. Los diagramas de implementación muestran aspectos relativos a la implementación. 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 IMPLEMENTACIÓN. por lo cual no puede aparecer ninguna multiplicidad en ellas. el muro m1 limita con la puerta p1 y con el muro m3). Un diagrama de componentes se utiliza para modelar los componentes de un sistema y mostrar las dependencias entre ellos. un diagrama de clases que sólo contenga instancias de clases. Como en los diagramas de clases también se pueden mostrar objetos. . y que cada uno de los elementos constituyentes está relacionado con su adyacente (por ejemplo.Ingeniería del Software-UML 55 Nótese que los enlaces son instancias de las relaciones del diag rama de clases. en Rose: no hay un diagrama de objetos como tal. Por ejemplo. DIAGRAMAS DE COMPONENTES. También se han incluido los valores del atributo nombre de los objetos de la clase Dpto para facilitar su entendimiento. el siguiente diagrama muestra un objeto de la clase Robot que se encuentra moviéndose (estado movimiento).

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

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

dll Este otro diagrama muestra dependencias en tiempo de compilación: principal.log b.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. Incluso permiten mostrar dependencias entre varias versiones de componentes. el siguiente diagrama muestra dependencias en tiempo de ejecución: .cpp .cpp a.ini .h c.dll .h b.cpp c.hlp a.exe principal.h b.exe . Por ejemplo.cpp a.

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

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

Para modelar esta migración se representa una relación entre dichas instancias con el estereotipo «become». Por ejemplo: Nodo1 :A : Cluster «become» Nodo2 : Cluster .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.

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

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

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

5. 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. En general. como en el caso de C++. cabecera. es muy recomendable realizarlo. Generar el código. Al crear un componente se puede especificar su estereotipo (p. plantillas y la STL. Se deben crear los componentes necesarios y sus relaciones (diagrama de componentes). Comprobar el modelo. 2. programa principal. componente o paquete. . cuerpo.h y . Asignar clases a componentes.Ingeniería del Software-UML 65 GENERACIÓN DE CÓDIGO14. 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. Dependiendo del lenguaje utilizado. 4. 6. Utilizando la opción Tools Check Model se comprueba que el modelo es consistente antes de generar código. una clase debe estar asignada a un solo componente. Rose proporciona unas propiedades por defecto que pueden ser cambiadas según se requiera. 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. Objetos en los diagramas de secuencia o colaboración no mapeados a clases.cpp). Accesos no permitidos entre clases causados por falta de visibilidad. Comprobar el modelo. se deben seguir 6 pasos para la generación de código: 1. CÓMO GENERAR CÓDIGO . ej. 4. Crear los componentes. Asignar clases a componentes. Crear los componentes. etc. Algunos errores comunes que detecta esta opción son: Mensajes en los diagramas de secuencia o colaboración no mapeados a operaciones. 1. o varias clases pueden estar asignadas a un mismo componente o. una misma clase puede pertenecer a dos componentes distintos (.. Establecer las propiedades para la generación del código. 3. 2. 3. Estas propiedades controlarán el código que será generado. Seleccionar una clase.) y el lenguaje en el que se generará (C++ en nuestro caso). Aunque no es obligatorio. Establecer las propiedades para la generación del código.

componente o paquete. También genera el esqueleto del código necesario para su implementación. Definición del constructor y constructor por copia y destructor.h o . 6.Ingeniería del Software-UML 66 abriendo su especificación. Declaraciones de operaciones (incluyendo parámetros. QUÉ SE GENERA . Téngase en cuenta. 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. Componentes (ficheros). dejando las opciones de generación de código por defecto.cpp según el estereotipo del componente. 5. Se puede generar código seleccionando Tools C++ Code Generation o desde el menú contextual. Seleccionar una clase. Por ejemplo. También genera el esqueleto del código necesario para su implementación. las relaciones. 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 . Rose puede generar los siguientes elementos: Clases. un componente o un paquete para generar su código. Por defecto. como por ejemplo. Definición e implementación de las operaciones (privadas) set y get del atributo cilindrada. que posiblemente la operación set se tendrá que retocar para . Relaciones (aunque sólo algunos tipos). sin embargo. tipo y valor por defecto). incluye: Definición de la clase. Atributos (incluyendo visibilidad. Definición de las operaciones de comparación (igualdad y desigualdad) y la asignación. tipos de los parámetros y tipo devuelto). sea la siguiente clase: Coche -cilindrada: double +potencia(): double El código generado para esta clase. 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. Se puede seleccionar una clase. Generar el código. También se pueden seleccionar múltiples elementos mediante la tecla [Ctrl]. incluyendo la definición del atributo cilindrada y la operación potencia().

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

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

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

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

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

. private: list<*ClaseB> the_ClaseB... Sin embargo..... que puede ser compilado sin problemas. 3 class ClaseB { . }. Por ejemplo: ClaseA 1 3 ClaseB class ClaseA { .. }.. }... . la parte compuesta se tiene como un atributo de la clase (esto es.h> . en la relación de composición. . Una relación de agregación genera un código similar a una asociación... .... class ClaseB { . }.. private: ClaseB the_ClaseB[3]. }. será: #include <list. ClaseB En el caso de relaciones de dependencia. class ClaseA { .. private: ClaseB *the_ClaseB[3]. por valor): ClaseA 1 class ClaseA { .Ingeniería del Software-UML 72 El código generado ahora.. }. . class ClaseB { . 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.. Rose sólo incluye en el código los “includes” que sean necesarios.

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

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

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->