Tema UML

Ingeniera del Software-UML
INGENIERA DEL SOFTWARE. UML.
IMPORTANTE: Este documento es de uso exclusivo para alumnos de la asignatura de Ingeniera del Software de las titulaciones I.T.I.G. e Ingeniera en Electrnica de la Universidad de Alcal.
TEMARIO: UML Introduccin. Diagrama de Casos de uso. Diagrama de Secuencia. Diagrama de Colaboracin. Diagrama de Estados. Diagrama de Actividades. Diagrama de Clases. Diagrama de Objetos. Diagrama de Componentes. Diagrama de Despliegue. Proceso Unificado de Rational. Generacin de cdigo.
BIBLIOGRAFA: Material entregado en CD (presentaciones, estndar UML y otros documentos). Ayuda de Rational Rose. En especial, para la generacin de cdigo se puede consultar en Ayuda p Contenido p Rose C++ las secciones Concepts y Reference p Model-to-Code correspondences. Apuntes de C++ de Estructura de Datos. Entre otra, contiene informacin 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 fcil de seguir, aunque slo cubre Rose 98. Tiene cerca de mil pginas 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 bsicos de UML antes de intentar leer este libro.
Pg.
NDICE.
Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Diagrama de Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Diagramas de Interaccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Diagrama de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Diagrama de Colaboracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Diagrama de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Diagrama de Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Diagrama de Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Diagramas de Implementacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Diagrama de Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Proceso Unificado de Rational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Generacin de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
PRLOGO. Este documento constituye una introduccin a UML1. Sin embargo, debido a que en la asignatura Laboratorio de Ingeniera del Software se utiliza la herramienta Rational Rose, en algunos momentos se realizan particularizaciones a dicha herramienta. Tambin se ver una breve introduccin a la metodologa Proceso Unificado de Rational. A partir de los diagramas de clases y componentes es factible generar cdigo (al menos un esqueleto del mismo). El ltimo tema se dedicar a la generacin de cdigo mediante Rational Rose, para lo cual se usar C++ como lenguaje de implementacin.
El estndar UML es muy amplio, por lo que aqu no se vern todas sus particularidades. Se recomienda consultar la bibliografa si se desean completar los conocimientos o profundizar en algn aspecto concreto.
INTRODUCCIN.
QU ES UML?
Son las siglas de Lenguaje de Modelado Unificado (Unified Modeling Language). UML es un lenguaje grfico para visualizar, especificar, construir y documentar los artefactos de sistemas con una componente software significativa. Como ejemplos de artefactos de un sistema tenemos el cdigo fuente, el diseo, 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 metodologa, aunque proporciona tcnicas que pueden ser usadas en conjunto o parcialmente en metodologas, fundamentalmente aquellas destinadas al desarrollo orientados a objetos, como el Proceso Unificado de Rational o Mtrica V.3 (aunque Mtrica V.3 es una metodologa mixta que tambin permite el desarrollo estructurado). Al ser UML un lenguaje, est compuesto de una sintaxis (reglas que indican cmo ensamblar los componentes de su vocabulario para crear expresiones) y una semntica (reglas que indican el significado de las expresiones). Ambos aspectos sern tratados aqu.
LA IMPORTANCIA DE MODELAR .
Los sistemas, ya sean naturales o artificiales, son difciles de comprender. Esto es debido a que en general son bastante complejos y la mente humana slo puede manejar 72 elementos de forma simultnea. Sin embargo, es posible representar y entender un sistema usando la tcnica del modelado, esto es, construyendo modelos del sistema. Un modelo es una simplificacin de la realidad creada para comprender mejor un sistema; un modelo es una abstraccin que captura la parte esencial de los sistemas a un determinado nivel de detalle. Los modelos: - Ayudan a visualizar cmo es o queremos que sea un sistema. Permiten especificar la estructura o componentes del sistema. Son una gua para la construccin y mantenimiento de los sistemas. Permiten experimentar mltiples soluciones. Reducen los riesgos por errores. Documentan las decisiones adoptadas.
Existe una serie de principios bsicos en el modelado de sistemas, entre los que destacan los siguientes: - Elegir el modelo ms adecuado para cada sistema. Por ejemplo, si se va a realizar un desarrollo orientado a objetos, se debera utilizar un modelado orientado a objetos. Cuando as convenga, el sistema se podr ver a diferentes niveles de detalle. Para eso, se utilizarn modelos ms 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 semnticamente consistentes. Por ejemplo, si estamos modelando una casa, los tabiques deben ser los mismos en el plano elctrico, de la fontanera, calefaccin, etc.
UML utiliza modelos orientados a objetos. Un modelo orientado a objetos es una representacin de un sistema a partir de los objetos u entidades que lo constituyen, con unos atributos y operaciones asociados, que interactan con otros objetos para conseguir conjuntamente satisfacer los objetivos del sistema. Existen varios tipos de modelos: grficos, matemticos, fsicos, etc. Por ejemplo, la maqueta de un automvil es un modelo fsico del sistema automvil que podra utilizarse para estudiar su aerodinmica en el tnel de viento. UML es un lenguaje de modelado visual, esto es, utiliza modelos grficos para la representacin de sistemas. Los seres humanos son criaturas visuales (de ah el dicho ms vale una imagen que mil palabras). Es ms fcil entender informacin visual que informacin no visual (por ejemplo, es ms fcil entender un recorrido dibujado en un mapa que entender las instrucciones en texto equivalentes). UML utiliza diagramas para representar los modelos.
HISTORIA DE UML.
Aunque el nacimiento de los lenguajes orientados a objetos tuvo lugar en los aos 70 con la aparicin de Smalltalk, fue en los 80 cuando empez realmente su despegue y expansin. Los mtodos de modelado existentes a principios de los 80 estaban adaptados para la construccin de programas en lenguajes pertenecientes al paradigma de la programacin estructurada. Sin embargo, estos mtodos no se adaptaban correctamente al desarrollo de programas orientados a objetos. A mediados de los 80 empezaron a aparecer mtodos de modelado orientados a objetos. Durante el perodo comprendido de 1989 a 1994, el nmero de mtodos se increment de menos de 10 a ms de 50, enfatizando cada uno de ellos en ciertos aspectos y sin proporcionar ninguno de ellos una solucin suficientemente general. Durante este tiempo, los mtodos se fueron perfeccionado a la vez que el paradigma orientado a objetos se consolidaba. De la experiencia acumulada, aparecieron nuevas generaciones de mtodos, entre los que destacan: Mtodo de Booch, de Grady Booch. OOSE (Object Oriented Software Engineering), de Ivar Jacobson. OMT (Object Modeling Technique), de James Rumbaugh.
stos eran mtodos completos, pero cada uno de ellos tena sus puntos fuertes y dbiles. Segn evolucionaban, se iban tomando ideas los unos de los otros, parecindose cada vez ms. Finalmente, deciden unirse los creadores de dichos mtodos (fundando Rational Software Corporation) al objeto de unificar sus mtodos, naciendo UML, cuyos objetivos eran: Modelar sistemas, desde el concepto hasta ejecutables, utilizando tcnicas orientadas a objetos. Vlido para cualquier sistema, ya fuera pequeo, grande, crtico o complejo. Utilizable tanto por personas como por mquinas.
Paulatinamente, fueron apareciendo versiones: 0.8 en 1995. 1.0 en enero de 1997. 1.1 en noviembre de 1997. 1.2 en junio de 1998 (revisin editorial, sin cambios significativos a nivel tcnico). 1.3 en noviembre de 1999.
La versin actual de UML es la 1.3, que es un estndar del OMG (Object Management Group). Se lleva cierto tiempo trabajando ya en la versin 1.4, una revisin menor de la actual que aparecer a corto plazo (principios del ao 2001). Se espera una revisin importante del estndar hacia el ao 2002, con la publicacin de la versin 2.0.
VISIN GENERAL DE UML.

El vocabulario de UML se compone de: Elementos. Hay cuatro tipos de elementos: Estructurales. De comportamiento. De agrupacin. De anotacin. Elementos. Son abstracciones de algn componente o aspecto del sistema modelado. Relaciones. Ligan elementos entre s. Diagramas. Agrupan elementos y relaciones.
Los elementos estructurales representan partes materiales o conceptuales del sistema. Los elementos estructurales principales de UML son la clase, la interfaz, la colaboracin, el caso de uso, los componentes y los nodos. Ms adelante se ver su representacin y significado. Los elementos de comportamiento son las partes dinmicas de los modelos UML. Los elementos de comportamiento bsico son las interacciones (que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propsito especfico) y la mquina de estados (que especifica las secuencias de estados por las que pasa un objeto o una interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos).
Mensaje Estado
Los elementos de agrupacin de UML son los paquetes, y sirven para organizar otros elementos de los modelos UML (pudiendo incluir incluso otros paquetes). Un paquete es un mecanismo conceptual de propsito general para organizar elementos en grupos. Por ejemplo, se pueden incluir en un paquete varias clases y luego asignar ese paquete a un componente (con lo que, realmente, lo que estamos asignado al componente son todas las clases que el paquete incluye). Grficamente, un paquete se visualiza como una carpeta, incluyendo su nombre y, a veces, su contenido:
Paquete
Los elementos de anotacin son partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clarificar o hacer observaciones sobre cualquier elemento de un modelo. Aunque la mayora de herramientas del tipo Rose permiten aadir un texto (o incluso un fichero o una direccin web) comentando o documentando cada elemento, con las anotaciones este texto se ve de forma explcita en el diagrama, de forma que resalta a primera vista.
El smbolo utilizado para una anotacin es el siguiente:

Aqu se escribe el texto de la nota.
Relaciones. Los tipos fundamentales de relaciones son los siguientes: Generalizacin. Asociacin. Realizacin. Dependencia.
La relacin de generalizacin conecta a elementos vinculados por una relacin padre/hijo (generalizacin/especializacin). Grficamente viene dada por una lnea acabada en punta de flecha vaca que va del elemento especializado (el hijo) al general (el padre).
La relacin de asociacin es una relacin estructural entre dos elementos. Grficamente se muestra como una lnea que conecta ambos elementos (de forma opcional puede tambin acabar en punta de flecha para indicar la direccin de navegabilidad o incluir ciertos adornos que aumentan su expresividad):
La relacin de realizacin es una relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplir. Es la relacin que hay entre una especificacin y su implementacin. Poner ejemplo Grficamente viene dada por una lnea discontinua que acabada en punta de flecha vaca y va del elemento que cumple el contrato al elemento que lo especifica:
La relacin de dependencia es una relacin semntica entre dos elementos, en la cual un elemento requiere la presencia de otro para su implementacin o funcionamiento. Un cambio en el elemento requerido (el independiente) puede afectar al del otro elemento (el dependiente). Se representa como una lnea discontinua entre el elemento dependiente y el independiente acabada en punta de flecha que seala al elemento independiente (esto es, el elemento dependiente indica el elemento del que depende):
Diagramas. Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas, de forma que un diagrama es una proyeccin de un sistema. Para todos los sistemas, excepto los ms triviales, un diagrama representa una vista resumida de los elementos que constituyen un sistema. En UML existen nueve tipos de diagramas, agrupables segn la siguiente clasificacin:
Diagramas de comportamiento (modelan cmo se comporta el sistema). 1. Diagrama de casos de uso. Diagramas de interaccin (muestran cmo interaccionan entre s objetos de un sistema). 2. Diagrama de secuencia. 3. Diagrama de colaboracin. 4. Diagrama de estados. 5. Diagrama de actividades.
Diagramas estructurales (modelan algn aspecto de la estructura del sistema). 6. Diagrama de clases. 7. Diagrama de objetos. Diagramas de implementacin (muestran aspectos relacionados con la implementacin). 8. Diagrama de componentes 9. Diagrama de despliegue.
El diagrama de casos de uso muestra actores y formas en que stos pueden utilizar el sistema. El diagrama de secuencia muestra cmo se mandan mensajes los actores y objetos de un sistema a lo largo del tiempo. El diagrama de colaboracin muestra las relaciones existentes entre actores y objetos y los mensajes enviados entre ellos. El diagrama de estados muestra los diferentes estados por los que puede pasar un objeto, as como las transiciones y eventos asociadas. El diagrama de actividades muestra el flujo de control entre objetos. El diagrama de clases muestra la estructura de clases de un sistema, incluyendo las relaciones que pudieran existir entre ellas. Es el ms comn de los diagramas en el modelado de sistemas orientados a objetos. El diagrama de objetos muestra un conjunto de objetos y sus relaciones (enlaces) en un instante determinado. Equivale a una instancia de un diagrama de clases (o una parte del mismo) y se utiliza generalmente para documentar estructuras de datos complejas. El diagrama de componentes muestra cmo se organizan los elementos constituyentes del sistema (cdigo fuente, ejecutables, etc.) y las dependencias existentes entre ellos. El diagrama de despliegue muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos.
MECANISMOS DE EXTENSIBILIDAD .
UML proporciona una serie de mecanismos de extensibilidad que permiten aumentar la capacidad expresiva del mismo. Estos mecanismos son: Estereotipos. Valores etiquetados. Restricciones.
Un estereotipo extiende el vocabulario de UML, permitiendo crear nuevos tipos de bloques de construccin que se deriven de los existentes. Los nombres de los estereotipos se muestran encerrndolos entre los smbolos y 2. Por ejemplo, podramos crear el estereotipo tabla para representar una tabla. Este estereotipo, aadido al smbolo de una clase, indicara que nos encontramos ante un nuevo elemento (en este caso, el estereotipo nos indica que dicho elemento representa una tabla). Un valor etiquetado extiende las propiedades de un bloque de construccin, permitiendo aadir nueva informacin en la especificacin de ese elemento. Los valores etiquetados se muestran encerrndolos entre llaves. Por ejemplo, se podra mostrar el autor de una determinada clase mediante un valor etiquetado aadido al smbolo que representa la clase: {autor = J. Macas}. Una restriccin extiende la semntica de un bloque de construccin de UML, permitiendo aadir nuevas reglas o modificar las existentes. Las restricciones se muestran encerrndolas entre llaves. Por ejemplo, la restriccin {xor} aplicada a un grupo de asociaciones se utiliza para indicar que slo se debe instanciar una relacin de las varias posibles.
A los smbolos y se les denomina guillements y son smbolos simples. Esto significa que, por ejemplo, el smbolo no est compuesto de dos smbolos menor seguidos, esto es <<, sino que existe el smbolo especial .
DIAGRAMA DE CASOS DE USO3. Los diagramas de casos de uso representan la funcionalidad del sistema tal como la ven los usuarios. En los diagramas de casos de uso se muestran las diferentes formas posibles de utilizacin de un sistema. Los diagramas de casos de uso permiten visualizar el comportamiento de un sistema, de forma que los usuarios puedan comprender cmo se utiliza ese elemento y de forma que los desarrolladores puedan implementarlo. En un diagrama de casos de uso importa qu hace el sistema (qu proporciona), no cmo lo hace. Los elementos principales que aparecen en los diagramas de casos de uso son: Actores. Casos de uso. Relaciones.
Veamos, para empezar, un diagrama de casos de uso para un cajero automtico:
Transferir Fondos Empleado Banca Ingresar Cambiar PIN
Cliente
Disponer
Realizar Pago Sistema de Crdito Ver Saldos
En este diagrama se pueden identificar los actores (Cliente, Empleado de Banca y Sistema de Crdito) que son los agentes externos que interactan con el cajero automtico, los casos de uso (Transferir Fondos, Cambiar PIN, Realizar Pago, Ver Saldos, Disponer e Ingresar) que son las funcionalidades que el cajero proporciona y, por ltimo, las relaciones entre actores y casos de uso (las lneas que van entre actores y casos de uso).
Para ms informacin, se puede consultar el libro Writing Effective Use Cases, A. Cockburn, ed. Addison-Wesley (oct., 2000).
10
Opcionalmente, se puede aadir al diagrama un rectngulo que representa los lmites del sistema representado (marca el lmite entre el sistema fsico objeto del modelado y los actores que interactan con dicho sistema), como se puede ver en el ejemplo siguiente:
Realizar Llamada Red Telefnica
Recibir Llamada
Usuario Usar Agenda
Telfono mvil
Los diagramas de casos de uso son una herramienta de comunicacin efectiva entre clientes y desarrolladores. Ayudan a capturar los requerimientos del sistema (que ser una cuestin bsica para todo el desarrollo posterior), para validar el diseo contra ellos, 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 documentacin de usuario. Los diagramas de caso de uso se centran en la interaccin entre los usuarios y los sistemas, y no en las actividades internas que tengan lugar en dicho sistema. Son una herramienta muy general que permite especificar las reglas de un negocio4. No estn basados en la teora de orientacin a objetos y pueden usarse tanto en procesos de desarrollo orientados a objetos como a desarrollos estructurados u otros. La creacin de los casos de uso necesita de la participacin de los usuarios (expertos en el tema a modelar) para su construccin y validacin, adems de analistas. La creacin de los diagramas es un proceso de descubrimiento, que suele requerir varias sesiones. De forma resumida, se puede decir que los diagramas de caso de uso: Representan una forma estructurada, pero informal, de expresar los requerimientos funcionales. Son fciles de entender, tanto por el cliente como por el desarrollador. Son un mecanismo para obtener el consenso en la visin del sistema y sus objetivos entre clientes y desarrolladores.
ACTORES .
Un actor5 es un rol o conjunto homogneo de roles que un usuario (persona o mquina) desempea respecto al sistema. Son, por tanto, agentes externos al sistema y que interactan con l. Grficamente, un actor se simboliza mediante un hombre de alambre, figurando debajo de l el nombre:
Cliente
Las reglas o procesos de negocio son procesos realizados en el seno de una cierta organizacin o empresa. El nombre actor con el que se denomin a este elemento en UML no fue acertado, ya que lo que realmente representa el elemento UML es un rol (o conjunto homogneo de roles), y un actor del mundo real puede (y de hecho normalmente lo hace) representar varios roles dispares.
5
11
Un actor representa una clase, a la cual pueden pertenecer uno o ms elementos (o, de forma equivalente, instancias). Por ejemplo, instancias del actor cliente seran Jos, Luis, Fernando, etc. Hay tres tipos principales de actores: usuarios del sistema, otros sistemas que interactan con el sistema que est siendo modelado y el tiempo: El primer tipo de actor corresponde a personas fsicas o usuarios. No se deben usar nombres de personas ya que, si tomamos por ejemplo el caso del cajero automtico, una misma persona puede desempear 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 adems puede ser cliente del banco y usar el cajero para, por ejemplo, sacar dinero). El segundo tipo de actor es otro sistema. Nuestro sistema puede interaccionar con otros sistemas, que son externos y estn fuera de nuestro control (esto es, nos vienen ya dados y es nuestro sistema el que se debe adaptar para comunicarse con ellos). El tercer tipo de actor es el tiempo. El tiempo es un actor cuando el paso de un cierto tiempo dispara algn evento en el sistema. Por ejemplo, a medianoche el sistema podra realizar un proceso de control del estado del cajero. Debido a que el tiempo est fuera de nuestro control, es un actor.
Representar un actor del tipo sistema externo o tiempo como un hombre de alambre puede resultar poco claro. Una opcin mejor puede ser asignar un estereotipo a los sistemas externos (por ejemplo sistema) y utilizar un nuevo icono para su representacin, por ejemplo la imagen de un miniordenador o un servidor. De forma similar se puede hacer con el tiempo. Los actores se pueden clasificar como primarios o secundarios, dependiendo si participan en las funciones principales del sistema (pertenecientes al mbito del negocio, como Realizar Llamada en el caso del telfono mvil) o funciones secundarias en el mismo (pertenecientes al mbito del mantenimiento del sistema, como copias de seguridad, arrancada y parada del sistema o administracin de la base de datos). Tambin es posible clasificarlos como activos o pasivos, dependiendo de si inician los casos de uso o no. A la hora de encontrar los actores de un sistema, existen dos enfoques diferentes, ambos importantes y legtimos, correspondientes a dos niveles de abstraccin: el modelo de sistemas de informacin y el modelo de negocios. Por ejemplo, pensemos que deseamos modelar el caso de uso consistente en realizar el pedido de un coche en un concesionario. Podramos suponer que el actor es el vendedor o que el actor es el cliente. En el primer caso, estamos a nivel de abstraccin del modelo de sistemas de informacin, ya que modelamos una solucin especfica organizativa y tecnolgica (el vendedor es el encargado de interactuar con el sistema). En el segundo caso, estamos a un mayor nivel de abstraccin, ya que lo que realmente modelamos es una regla del negocio (el cliente es quin encarga el coche). Desde este punto de vista, el vendedor no es ms que un intermediario, el interface del sistema con el que interacta el actor. Cuando se elige el modelo de sistemas de informacin estamos especificando ya una enfoque definido. Sin embargo, al usar el modelo de negocio dejamos abierta la puerta a diferentes enfoques. Por ejemplo, se podra optar durante la fase de anlisis y diseo que el cliente pudiera encargar el coche tanto personalmente a travs del vendedor, por telfono, por correo electrnico o va Web (simplemente, representaran diferentes interfaces para el cliente para realizar una misma tarea: realizar el pedido de un coche).
12
Nota: El uso de interfaces humano o automticos tiene sus pros y sus contras, tal y como se puede ver en la siguiente tabla: Ventajas Interfaz humano Interfaz automtico Flexibilidad (adaptable al actor). Coste. Uniformidad. Inconvenientes Coste. Ausencia de uniformidad. Rigidez.
CASOS DE USO .
Un caso de uso representa una funcionalidad que el sistema proporciona o, de forma equivalente, un caso de uso muestra una forma en la que alguien podra utilizar el sistema. 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. Grficamente, un caso de uso se representa mediante una elipse, 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, que indique el objetivo o funcionalidad del caso. Los casos de uso pueden describir funcionalidades a diferentes niveles: sistema, subsistemas y componentes (clases). A cualquiera de estos niveles, los casos de uso definirn el comportamiento del elemento que describen, sin revelar su estructura interna. Se debe precisar que si se utilizan casos de uso para describir clases, los actores que participarn sern en general otras clases o subsistemas. El nivel ms importante es el que describe las funcionalidades del sistema. Pertenece al nivel de abstraccin del negocio, y es til tanto para clientes como desarrolladores. Se les denomina casos esenciales o abstractos. Desde este punto de vista, se puede redefinir caso de uso como una nica actividad discreta, completa, significativa y bien definida de inters para un usuario externo que desempea un rol o roles especficos con relacin al sistema, englobando las posibles acciones del usuario y las responsabilidades del sistema durante el desarrollo de la actividad, descritas de una forma abstracta, independiente de la tecnologa y de la posible implementacin, usando un lenguaje perteneciente al dominio de la aplicacin y, por tanto, fcilmente entendible por los usuarios. Se debe tener en cuenta que, a este nivel, un caso de uso puede tener una duracin finita cualquiera, ya sea unos segundos, varios das o incluso meses. A nivel de subsistemas se suelen tratar con operaciones atmicas o CRUD (Create, Read, Update, Delete). Este nivel suele ser poco til para los clientes, ya que est ms enfocado al diseo, centndose en las interacciones con la base de datos en lugar de interacciones entre el actor y los sistemas. A este tipo de casos de uso se les denomina a veces como reales, a diferencia de los anteriores (esenciales, abstractos o ideales). Los casos de uso se deben documentar. Dicha documentacin debe contener una descripcin del caso de uso y el flujo de eventos del mismo (la secuencia de acciones, incluyendo variantes, que un sistema puede ejecutar interactuando con los actores para proporcionar la funcionalidad indicada en el caso de uso). Opcionalmente, puede incluir precondiciones y/o postcondiciones. El texto usado en la documentacin de los casos de uso debe estar basado en el lenguaje del negocio a modelar. No se recomienda detallar excesivamente ni utilizar pseudocdigo para especificar el flujo de eventos, ya que podra restringir las soluciones a tomar. Las secciones que podrn aparecer en un caso de uso son, por tanto:
13
Descripcin. Describe, generalmente de forma breve, lo que hace el caso de uso. Precondiciones. Son las condiciones que se deben cumplir antes de poder utilizar el caso de uso. Postcondiciones. Son las condiciones que se cumplirn despus de haber finalizado la ejecucin del caso de uso. Flujo de eventos primario (o base) y alternativo(s). El flujo de eventos describe, paso a paso, lo que sucede en el caso de uso (no cmo sucede). El flujo primario describe la situacin normal (debe ser adems el primer flujo descrito al crearlo). El flujo o flujos alternativos documentan qu ocurre en situaciones variantes o anormales (por ejemplo, que el cliente no dispusiera de suficiente saldo). Para especificar flujos de eventos se puede, adems de texto, usar otras tcnicas, como los diagramas de actividad o de estado.
Si se utiliza texto para especificar el flujo de eventos, se recomienda seguir el estilo del siguiente ejemplo, que representa el flujo de eventos para el caso de uso de obtencin de ayuda para un problema especfico de una empresa de ventas:
Acciones del usuario 1. Identificacin como cliente.
Responsabilidades del sistema
2. Presentacin de las opciones de ayuda. 3. Seleccionar una opcin de ayuda. 4. Pedir descripcin del problema. 5. Describir el problema. 6. Ofrecer posibles soluciones.
RELACIONES .
Hay cuatro tipos de relaciones que pueden aparecer en un diagrama de casos de uso.
Relacin de comunicacin. Es el tipo ms normal de relaciones y tiene lugar entre un caso de uso y un actor. Grficamente es una lnea, a la que se puede aadir una punta de flecha para indicar quin inicia la comunicacin.
Por ejemplo:
Cliente
Realizar Pago
Sistema de Crdito
En este caso, el actor Cliente se comunica con el caso de uso Realizar Pago, siendo el actor quien inicia la comunicacin. Adems, el caso de uso Realizar Pago se comunica con el actor Sistema de Crdito. Todos los casos de uso deben ser iniciados por un actor (a excepcin de los casos de uso que extienden el comportamiento o estn incluidos en otro caso de uso, tal y como se ver ms adelante).
14
Relacin de inclusin6. La relacin de inclusin en un caso de uso A de caso de uso B (esto es, la flecha va de A a B) indica que el caso de uso A contiene el comportamiento indicado por B. El lugar o lugares donde dicho comportamiento se incluye debe especificarse en el flujo de eventos de A. La relacin de inclusin se muestra grficamente como una relacin de dependencia con el estereotipo include. 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. Esta factorizacin permite especificar de una sola vez un comportamiento comn a varios casos de uso. Las relaciones de inclusin tambin se pueden utilizar para detallar un caso de uso complejo que proporcione varias subfuncionalidades, de manera que visualmente se puedan apreciar de una forma ms fcil en qu consiste dicho caso, sin tener que consultar la descripcin del mismo. La relacin de inclusin indica que un caso de uso va a usar siempre la funcionalidad proporcionada por otro caso.
Relacin de extensin. Una relacin de extensin 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, sujeto a determinadas condiciones, que pueden ser especificadas en la extensin o en el caso de uso. La relacin de inclusin se muestra grficamente como una relacin de dependencia con el estereotipo extend. Por ejemplo:
extend
Solicitar cobro revertido
Realizar Llamada
Llamada a Cobro Revertido
En este ejemplo, la funcionalidad Llamada a Cobro Revertido extiende la funcionalidad Realizar Llamada. Esto ocurrira cuando solicitramos, por alguna razn, llamar a cobro revertido
Relacin de generalizacin. Puede ser entre actores o entre casos de uso.

6
En versiones anteriores de UML a esta relacin se le denominaba de uso (uses), sin embargo su nombre se cambio por la de incluye (include) ya que el anterior nombre daba a entender una semntica que no se corresponda con la real.
15
Entre actores: La relacin de generalizacin entre actores se utiliza cuando varios actores tienen caractersticas comunes. Grficamente se muestra como una relacin de generalizacin que va del actor especializado al genrico. Para los usuarios del telfono mvil podramos representar, por ejemplo:
Usuario
Usuario Tarjeta
Usuario Contrato
Una generalizacin 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. Para el caso del ejemplo, un Usuario Tarjeta (o un Usuario Contrato) podra comunicarse con los mismos casos de uso que un Usuario y, posiblemente, con otros particulares a l (por ejemplo, un Usuario Tarjeta podra comunicarse con el caso de uso Recarga Tarjeta). Se deben de usar las relaciones de generalizacin entre actores cuando algunos actores tengan en comn parte de sus comportamientos o cuando interese mostrar explcitamente que cualquier especializacin de un tipo de actor acta de igual forma.
Entre casos de uso: La relacin de generalizacin entre casos de uso se utiliza para indicar que un caso de uso es un refinamiento de otro. Por ejemplo:
Consultar Habitaciones Libres por Categora
Consultar Habitaciones
Este tipo de relacin se utiliza poco y no se debe abusar de ella.
NORMAS PARA CREACIN DE UN DIAGRAMA DE CASOS DE USO .

No modelar la comunicacin entre actores, ya que est fuera del mbito del sistema7. No dibujar flechas entre casos de uso, excepto para relaciones de inclusin, extensin o generalizacin. Todo caso de uso debe ser iniciado por un actor (excepto los casos de uso incluidos o las extensiones). No se debe representar el flujo de informacin entre casos de uso. Un caso de uso representa una funcionalidad o un modo de utilizar el sistema, pero no indica el cmo se implementa esa funcionalidad. Por tanto, un caso de uso puede representar la introduccin de una informacin y otro caso de uso el acceso a la misma, sin que exista ninguna comunicacin entre ambos casos.
Para modelar el modo en que las tareas se llevan a cabo en una empresa se podran utilizar diagramas de flujo de trabajo (workflow diagram).
16
Es importante que cualquier requerimiento funcional aparezca al menos en un caso de uso, ya que de otro modo no ser implementado. Los diagramas de casos de uso deben proporcionar fcilmente una visin de lo que el sistema proporciona, tanto a los desarrolladores como a los clientes (para casos de uso abstracto). Se debe usar un nmero de diagramas adecuado (dependiendo de la complejidad del sistema) con un nmero de casos de uso razonable y dependiendo del nivel de detalle de dicha vista en particular. Adems, los nombres de los casos de uso, actores y descripciones deben ser significativos para el cliente (deben pertenecer al lenguaje del negocio y la organizacin del cliente). Se deben considerar tambin casos de uso relacionados con el mantenimiento del sistema. Se debe elegir con cuidado las personas participantes en su creacin. Es importante evitar personas con pensamiento lineal (al estilo de los programadores), es decir, personas que intentan describir todos y cada uno de los pasos y detalles. Los diagramas de casos de uso slo pueden capturar requerimientos funcionales, y a un nivel relativamente alto. Para capturar otro tipo de requerimientos o detallarlos, se deben usar otras tcnicas. No se debe partir del nivel CRUD, ya que apareceran demasiados casos, a un nivel muy fino y dificultaran su entendimiento por el cliente. El sistema no existe para leer/escribir en una base de datos, existe para producir un resultado de valor mensurable para los actores. Se debe evitar crear los casos de uso basndose exclusivamente en la interfaz del sistema de informacin que ya existiera, si se diera esta situacin, ya que en vez de las reglas del negocio (el qu) podemos estar dando directamente una solucin basada en el sistema existente, que pudiera no ser lo suficientemente buena o flexible. Se debe cuidar la granularidad. Los casos de uso abstracto deben capturar lo esencial y no intentar detallar demasiado, porque esta situacin hace caer en el cmo. Sin embargo, una pequea descomposicin de los casos puede hacerlos ms fciles de comprender y simplificar su diseo.
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 Catlogo
1 Supervisor
n Proporcionar Crdito
El catlogo se enviar al servir el pedido.
Notas: El supervisor es una especializacin de vendedor. El supervisor es el nico que puede proporcionar crdito, pero tambin puede tomar pedidos como cualquier otro vendedor, ya que es una especializacin de ste. En el ejemplo se puede ver una forma de utilizacin de las notas.
17
Se ha aadido la multiplicidad en las relaciones de comunicacin. La condicin para la extensin Pedir Catlogo estar definida en el caso de uso Tomar Pedido (no se ha mostrado en el diagrama). Vase que se ha optado por modelar a nivel de sistema de informacin (aparece el actor vendedor y no el actor cliente).
EJEMPLO DE LA DOCUMENTACIN DE UN CASO DE USO .

A continuacin, se dar la documentacin (resumida) del caso de uso Sacar perteneciente al modelo de casos de uso de un sistema de cajeros automticos. Para hacerlo ms real, se supondr que el cliente slo se identifica una vez (representado por el caso de uso Validar usuario), y despus podr hacer una o ms operaciones sin necesidad de volver a identificarse. Nota: El flujo de eventos primario del caso de uso Validar usuario sera: Acciones del usuario 1. Insertar tarjeta en el cajero 2. Leer la tarjeta. 3. Pedir PIN. 4. Introducir PIN. 5. Verificar PIN. 6. Muestra las opciones. La documentacin del caso de uso Sacar sera la siguiente: - Descripcin: Permite al cliente obtener una cierta cantidad de dinero en efectivo del cajero automtico. - Precondiciones: El usuario se ha validado contra el sistema mediante Validar usuario. - Flujo de eventos principal: Acciones del usuario 1. Selecciona opcin sacar dinero. 2. Preguntar la cantidad. 3. Introduce la cantidad. 4. Visualizar la cantidad. 5. Confirmar la cantidad 6. Dispensar el efectivo. 7. Muestra opciones. - Flujos alternativos: En el paso 2, el usuario cancela la operacin. Se pasa al paso 7. En el paso 5, el usuario indica que la cantidad es errnea. Se vuelve al paso 2. En el paso 6, si no es posible proporcionar la cantidad requerida, se indica y se vuelve al paso 2. Responsabilidades del sistema Responsabilidades del sistema
- Postcondicin: La operacin, si finaliza con xito, queda reflejada en la cuenta del usuario.
18
DIAGRAMAS DE INTERACCIN.
Definiciones previas. Objeto: Clase: Atributo: Es una entidad con lmites definidos e identidad propia que encapsula un estado y un comportamiento. Un objeto es una instancia de una clase. La descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, mtodos y semntica. Caracterstica que describe el rango de valores que una instancia de una clase puede almacenar.
Operacin: Es un servicio que puede ser solicitado a un objeto para que se comporte de una determinada forma. Mtodo: Mensaje: La implementacin de una operacin. Especifica el algoritmo o procedimiento asociado con una operacin. Solicitud de una operacin determinada a un objeto concreto.
Notacin para la representacin de objetos. Un objeto se representa grficamente como un rectngulo, dentro del cual se incluye, subrayado, el nombre del objeto (empezando por letra minscula), o la clase (empezando por letra mayscula) a la que pertenece precedida de dos puntos, o ambos: Por ejemplo:
ana Objeto de nombre ana (no se especifica explcitamente la clase a la que pertenece).
: Persona
Objeto annimo de la clase Persona.
luis : Persona
Objeto de nombre luis perteneciente a la clase Persona.
Tambin puede incluirse una seccin en la que se muestren los valores de uno o ms atributos, tal y como se puede ver en el ejemplo siguiente:
Oscar : Persona Nombre: String = Oscar dni: Integer = 3102427 telefono = 91 555 00 00
19
Los diagramas de interaccin muestran cmo cooperan (interaccionan) un conjunto de objetos para realizar alguna tarea determinada. Modelan, por tanto, aspectos dinmicos del sistema. Un diagrama de interaccin consta de un conjunto de objetos y sus relaciones (ya sea de forma implcita o explcita), as como de los mensajes que se envan entre ellos. Hay dos clases de diagramas de interaccin: el diagrama de secuencia y el diagrama de colaboracin. Ambos diagramas son prcticamente equivalentes entre s, ya que la informacin 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 ordenacin temporal de los mensajes mientras en los diagramas de colaboracin lo que se destaca es la organizacin estructural de los objetos que envan y reciben mensajes. Dependiendo de la misin principal a la que se destine el diagrama, convendr usar uno u otro, tal y como se ver ms adelante. Una de las aplicaciones ms importantes de los diagramas de interaccin consiste en el modelado de escenarios. Un escenario es una secuencia especfica de acciones entre objetos que permite mostrar un comportamiento. Un escenario es, por tanto, una instancia de un flujo de eventos particular de un caso de uso. Varios diagramas de interaccin representando escenarios pertenecientes a distintos flujos de eventos de un mismo caso de uso (por ejemplo, flujo principal, flujo alternativo 1, flujo alternativo 2, etc.) se suelen agrupar en un paquete. Cada diagrama de interaccin que represente un escenario debe tener al menos un objeto actor iniciante, que es el estmulo externo que ejecuta alguna funcionalidad. Este objeto actor ser una instancia de un actor perteneciente al diagrama de casos de uso al que pertenece el flujo de eventos. A la hora de construir un diagrama de interaccin, es necesario encontrar los objetos que participan, a los que se aadirn a continuacin los mensajes que se envan. Existen varias tcnicas para encontrar objetos. Una de ellas consiste en analizar los sustantivos que aparezcan en los flujos de eventos o en escenarios especficos. En general, estos sustantivos se correspondern con actores, atributos u objetos (sern objetos si exhiben un comportamiento). Sin embargo, esta tcnica no permite descubrir todos los objetos. Habr posiblemente que aadir objetos cuya tarea sea controlar8 a los otros objetos (controlan el desarrollo de los acontecimientos). Tambin puede ser necesario aadir objetos de entrada/salida, como formularios e informes, que realizan la tarea de interface entre el usuario y el sistema. En Rose, un objeto se puede calificar (a travs de sus especificaciones) como persistentes (persistent), esttico (static) o transitorio (transient): Persistente: Aquel cuya vida contina aunque el programa haya terminado. Cuando se vuelva a ejecutar el programa, el estado del objeto depender del estado que tuviera al terminar la ejecucin anterior. Para que esto sea posible, debe ser guardado en un fichero o una base de datos (almacenamiento permanente) al terminar una ejecucin y recuperado al empezar la siguiente. Esttico: Es aquel que reside en memoria hasta que el programa termina. Esto es debido a que se trata de un objeto compartido por varios hilos de control o procesos. Transitorio: Aquel que permanece en memoria por un espacio de tiempo limitado (por ejemplo, durante el tiempo o parte del tiempo en que se desarrolla una determinada tarea o flujo de eventos).
El estndar tambin proporciona un smbolo para mltiples instancias de un objeto. Esto permite representar en los diagramas de interaccin agrupaciones de objetos como, por ejemplo, listas de objetos. En general, los mensajes que se mandan a las agrupaciones de objetos constan de una bsqueda ms una operacin que se requiere al objeto (o subconjunto de objetos) encontrado. La notacin es la siguiente (este icono slo puede aparecer en el diagrama de colaboracin):
: Persona
Este tipo de objetos, denominados objetos activos, se pueden mostrar en UML regruesando sus bordes para diferenciarlos del resto de objetos, los pasivos.
20
Para modelar los mensajes, Rose permite especificar cinco semnticas diferentes de sincronizacin de mensajes: - Simple: El mensaje se ejecuta en un hilo simple de control, por lo que el objeto al que va destinado el mensaje siempre lo aceptar y de forma inmediata. Es la opcin por defecto. Grficamente se representa como:
- Sncrono: El objeto cliente manda el mensaje y espera hasta que el objeto al que va destinado acepta el mensaje. Grficamente se representa como:
- Rechazable (balking): El cliente manda el mensaje y si el objeto al que va destinado no lo acepta, el cliente abandona el mensaje. Grficamente se representa como:
- Tiempo lmite (timeout): El cliente manda el mensaje y espera como mximo una determinada cantidad de tiempo. Si el objeto destino no est disponible para recibir el mensaje durante ese periodo, el cliente abandona el mensaje. Grficamente se representa como:
- Asncrono: El cliente manda el mensaje y continua sin esperar confirmacin de si el mensaje ha sido recibido. Grficamente se representa como:
Rose tambin permite especificar la frecuencia de los mensajes, calificndolos como aperidicos (mandados en un instante cualquiera de forma nica o sin una periodicidad; es la opcin por defecto) o peridicos (aquellos que son enviados a intervalos regulares). Se debe tener en cuenta que, al poner un mensaje en un diagrama de interaccin, se est asignando una responsabilidad al objeto que lo recibe. Por ejemplo, si en un diagrama de interaccin se representa un mensaje de un objeto a al objeto b, es responsabilidad del objeto b aceptar el mensaje y obrar en consecuencia, para lo cual deber disponer del mtodo adecuado. Supongamos, por ejemplo, que a manda el mensaje imprimir(hola.txt) al objeto b; el objeto b debe tener una operacin, que normalmente se implementar con un mtodo denominado imprimir, que trate dicho mensaje (en este caso el comportamiento de b podra consistir en imprimir el fichero hola.txt que se le ha pasado como parmetro). Los diagramas de interaccin constituyen una piedra angular en el diseo, ya que a travs de ellos los desarrolladores pueden determinar las clases que necesitan (aquellas a las que pertenecen los objetos que aparecen en ellos), las relaciones entre clases y las operaciones y responsabilidades de cada clase. Para que el diseo sea consistente, todo objeto de un diagrama de interaccin deber ser mapeado en algn momento a una clase del diagrama de clases, as como todo mensaje deber ser mapeado a una operacin (mtodo) de la clase que recibe el mensaje. Adems, la persistencia indicada en los diagramas de interaccin debe ser compatible con la persistencia indicada en los diagramas de clase, debindose cumplir en Rose lo siguiente: Si la clase se define como persistente en el diagrama de clases, un objeto de dicha clase podr calificarse como transitorio, esttico o persistente en el diagrama de interaccin. Si la clase se define como transitoria en el diagrama de clases, un objeto de dicha clase podr calificarse como esttico o transitorio en el diagrama de interaccin.
En Rose, es posible documentar en las especificaciones de un caso de uso los diagramas relacionados con dicho caso (ya sean de interaccin, estado, actividad o clases).
21
Al ser semnticamente equivalentes los diagramas de secuencia y los de colaboracin, es posible pasar de uno a otro automticamente. Por ejemplo, en Rose basta crear uno de ellos y pulsando la tecla [F5] generar el otro.
22
DIAGRAMA DE SECUENCIA.
Un diagrama de secuencia es un tipo de diagrama de interaccin en el cual se destaca el tiempo: los mensajes entre objetos vienen ordenados explcitamente por el instante en que se envan. Consta de dos ejes. Generalmente, el eje vertical es el eje del tiempo, transcurriendo ste de arriba a abajo. En el otro eje se muestran los objetos que participan en la interaccin, siendo el primero de ellos el actor que inicia la ejecucin de la secuencia modelada. De cada objeto parte una lnea discontinua, llamada lnea de la vida, que representa la vida del objeto durante la interaccin. Si el objeto existe durante toda la interaccin, ste aparecer en el eje horizontal y su lnea llegar hasta el final del diagrama de secuencia. Los mensajes parten de la lnea de vida del objeto que lo enva hasta la lnea de vida del objeto al que va destinado (excepto en el caso del mensaje de creacin, como se ver ms adelante). Cada mensaje lleva un nmero de secuencia creciente con el tiempo y el nombre de la operacin requerida, as como posibles argumentos que pueden utilizarse como valores de entrada y/o salida. Usualmente, no se especifica una graduacin en el eje del tiempo, aunque podra hacerse para interacciones que modelen escenarios en tiempo real. Por ejemplo, vamos a modelar un escenario que muestre una instancia del flujo de eventos primario del caso de uso Validar usuario, en el cual el cliente Luis se identifica ante el cajero automtico con su nmero secreto (el 4567):
Obsrvese en el diagrama que el mensaje leerNumTarjeta() es un mensaje que el objeto lector se enva a s mismo (mensaje reflexivo).
23
Nota: Se recuerda que el flujo de eventos primario del caso de uso Validar usuario era: Acciones del usuario 1. Insertar tarjeta en el cajero 2. Leer la tarjeta. 3. Pedir PIN. 4. Introducir PIN. 5. Verificar PIN. 6. Muestra las opciones. Responsabilidades del sistema
Un objeto se crea mediante un mensaje de estereotipo create que apunta al objeto que se crea. Un objeto se destruye mediante un mensaje de estereotipo destroy, dando finalizada la lnea de vida con un aspa. En este diagrama de secuencia simplificado se pueden ver varios ejemplos de creacin y destruccin de objetos:
juan : Cliente
objetoA
objetoB
destroy
create
objetoC
destroy create
objetoE
Aprciese que objetoA y objetoB existen ya cuando empieza el diagrama, aunque objetoB es destruido, por lo que su lnea de la vida est interrumpida en el punto de su destruccin. Por otro lado, objetoC es creado y destruido durante la interaccin, mientras que objetoE es creado y continua existiendo al final del diagrama (al igual que objetoA). Opcionalmente, se puede mostrar en los diagramas de secuencia el foco de control, que es un pequeo rectngulo puesto sobre la lnea de la vida que indica qu objeto tiene el control en cada momento (esto es, el tiempo durante el cual est realizando una accin directa o indirectamente). Vase, por ejemplo, el siguiente fragmento simplificado:
objeto1 objeto2 objeto3
1: mensaje1 2: mensaje2
24
En este ejemplo, objeto1 tiene el control al empezar. En un momento determinado, manda un mensaje (mensaje1) al objeto2 para requerirle una cierta operacin. A partir de ese momento, objeto2 tiene tambin el control. Para realizar la operacin, objeto2 necesita un servicio de objeto3, para lo cual le enva el mensaje2, teniendo tambin control el objeto3 desde que recibe el mensaje hasta que finaliza el servicio requerido. De igual forma, el control de objeto2 finaliza al terminar el servicio que le haba requerido objeto1. Tngase en cuenta que para el caso de un slo hilo de ejecucin, o cuando se debe esperar la terminacin de la operacin solicitada por un mensaje para continuar, el que un objeto tenga el foco de control no significa que se est ejecutando realmente cdigo de dicho objeto durante todo el tiempo de control (ya que puede estar esperando que termine alguna operacin que haya requerido de algn otro objeto). Aunque, en principio, los diagramas de secuencia estn pensados para mostrar un nico escenario, Rose permite mediante los Scritps modelar varios flujos simultneamente, aunque no se debe abusar de esta posibilidad, ya que puede complicar en demasa el diagrama. Un ejemplo de script sera:
objeto1
objeto2
IF (condicion= TRUE) THEN
1: mensaje1
ELSE 2: mensaje2
En este ejemplo, si se cumple condicion=TRUE, objeto1 mandar mensaje1 a objeto2, y si no se cumple, le mandar mensaje2. Aunque Rose no lo soporta, UML permite aadir la condicin delante del mensaje (como por ejemplo [x>0] mensaje, que indica que se mandar el mensaje slo si la condicin se cumple, esto es, si x es mayor que cero). Tambin permite desdoblar la lnea de vida de un objeto en varias para mostrar flujos alternativos.
REFINAMIENTO .
Los diagramas de secuencia permiten mostrar escenarios de forma que sean comprensibles tanto por clientes como por desarrolladores. Sin embargo, una vez que los clientes han dado su visto bueno a los mismos, se suelen refinar aadiendo detalles de diseo que sern tiles a los desarrolladores. Por ejemplo, en el diagrama de secuencia visto anteriormente para validar usuario se debera 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 mayora del control. Esto es as porque el objeto : Pantalla Cajero es un interface y no conviene que los interfaces se encarguen del control ya que se volveran muy complicados y heterogneos, y seran muy sensibles a los cambios. De forma similar, se suelen crear objetos que manejen transacciones, de forma que se separe la lgica de la aplicacin de la lgica de la base de datos. De esta forma, si la lgica de la base de datos cambia, slo es necesario realizar cambios en la clase encargada de las transacciones. Adems, este tipo de clases suelen ser fcilmente reutilizables.
25
DIAGRAMA DE COLABORACIN.
Un diagrama de colaboracin es un diagrama que muestra una interaccin en el cual se destaca la organizacin estructural de los objetos que envan y reciben mensajes. Un diagrama de colaboracin muestra los objetos que intervienen en una relacin, los mensajes que se intercambian y las relaciones de comunicacin que hay entre ellos (para que un objeto pueda comunicarse con otro debe existir algn tipo de enlace o link entre ellos). Por ejemplo, el diagrama de colaboracin 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
Aprciese que, aunque aqu tambin aparece el orden de los mensajes, no es fcil seguir la secuencia de los mismos. Sin embargo se ve claramente qu objetos participan y las relaciones que existen entre ellos, lo que les hace muy tiles para los desarrolladores. Estos diagramas permiten, por ejemplo, valorar el impacto que supondra un cambio en una clase. Hay una diferencia significativa entre los diagramas de secuencia y los de colaboracin, y es que en los de colaboracin se pueden aadir explcitamente flujos de datos. Esto se hace mostrando al lado del mensaje afectado un circulo al que se aade una flecha indicando la direccin del flujo. Si la direccin del flujo coincide con la del mensaje, se trata de un argumento de entrada. Si no coincide, se trata de un valor de retorno. Como ejemplo, aqu se muestra un flujo de datos correspondientes a argumentos de entrada del mensajeA que objeto1 enva a objeto2:
1: mensajeA() objeto1 objeto2
En general, slo se utiliza esta tcnica cuando el flujo de datos es grande, como por ejemplo cuando se pasa una lista. En los diagramas de colaboracin tambin se pueden asociar estereotipos a los roles de los enlaces, como por ejemplo local, que es una restriccin que especifica que el objeto al que califica es visible por
26
ser una variable local al objeto que manda el mensaje. Tambin se pueden aadir restricciones a los objetos que indiquen su persistencia: {new} si son creados durante la interaccin, {destroy} si son destruidos o {transient} si son creados y destruidos durante la interaccin. Por ejemplo:
1: create() 2: mensajeA() 3: destroy() objeto1 objeto2 {transient}

L
En este caso, objeto2 es accesible a objeto1 por ser local a objeto1 (ntese que en Rose, en vez de aparecer el estereotipo local, lo que aparece es una L en el extremo del enlace). El objeto2 es adems transitorio, siendo creado y destruido en la interaccin (como de hecho se puede comprobar por los mensajes que se le envan).
27
DIAGRAMA DE ESTADOS.
Un diagrama de estados muestra el ciclo de vida de un objeto (aunque tambin se puede utilizar para sistemas o subsistemas) desde el momento en que el objeto es creado al momento de su destruccin. Describe todas las secuencias de estados y acciones por las que un objeto puede pasar durante su vida como reaccin a distintos eventos (como pueden ser los mensajes o seales). Un estado es una situacin particular en la que se exhibe un comportamiento determinado y que est caracterizado por el valor de uno o ms atributos y/o por las relaciones con otros objetos. El estado en que se encuentre un objeto ser por tanto dependiente de su historia anterior. Por ejemplo, un objeto de tipo fax podra encontrarse en los estados inactivo, transmitiendo o recibiendo, y en cada uno de estos estados tendra un comportamiento diferente. Un evento, como por ejemplo pulsar la tecla Parar cuando se encuentra en el estado transmitiendo, hara que pasara al estado inactivo. Los diagramas de estado slo se suelen realizar para objetos (clases) que tienen un comportamiento dinmico significativo, esto es, para aquellos que poseen un conjunto significativo de estados. Esto sucede con los objetos reactivos, que son aquellos cuyo comportamiento viene dirigido por los eventos que recibe. En estos casos, los diagramas de estado resultan de gran utilidad para los desarrolladores. Para encontrar clases con un comportamiento dinmico significativo, se puede buscar en primer lugar aquellos objetos que se comporten de forma diferente segn los valores de sus atributos, siendo candidatos, por ejemplo, las clases que tengan un atributo llamado estado. Tambin se deben analizar las clases que participen en relaciones en las que aparezca en nmero cero en la multiplicidad. Esto significa que dicha relacin es opcional y puede que el comportamiento en ese caso sea muy diferente. Por ejemplo, en una relacin entre persona y compaa para la que trabaja, si un objeto persona tiene una relacin con una o ms compaas significar que es un empleado. Sin embargo, si no tiene ninguna relacin, podra estar parado, jubilado o incapacitado.
En un diagrama de estados aparecen uno o ms estados relacionados entre s por transiciones. Las transiciones, en general, sern ocasionadas por algn evento. Por ejemplo, este podra ser el diagrama de estados de un objeto de la clase Curso:
Abierto cancelar Cancelado fin periodo matrcula cancelar
Cerrado fin cuatrimestre Completado
28
ESTADO.
Un estado una situacin en la vida de un objeto durante la cual se satisface alguna condicin, se realiza alguna actividad o se espera algn evento. Un estado se representa grficamente como un rectngulo redondeado. Por ejemplo:
NombreEstado
Dentro del estado (o adjunto en el extremo superior izquierdo en ciertas ocasiones) se puede escribir el nombre del estado, aunque es opcional y se pueden utilizar estados annimos. Mientras un objeto est en un estado particular, puede realizar cero, una o ms acciones internas. En este contexto, una accin es una tarea que tiene lugar mientras un objeto se encuentra en un determinado estado. Estas acciones se muestran en una seccin debajo del nombre del estado, con el formato etiquetaDeAccin/expresinDeAccin. La etiqueta de accin identifica las circunstancias o eventos bajo los cuales la expresin de la accin ser invocada. Existen algunas etiquetas de accin reservadas para propsitos especiales y que no pueden ser utilizadas como nombres de eventos. Estas son: entry: Indica que la tarea se realiza cuando el objeto entra en dicho estado. Se considera una accin no interrumpible. exit: Indica que la tarea se realiza cuando el objeto abandona el estado. Se considera una accin no interrumpible. 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 considera una accin interrumpible. Dicho de otra forma, cuando un objeto est en un estado que contiene una accin etiquetada con do, realiza dicha accin (despus de realizar la accin de entrada si la hubiera) hasta que sta termina o hasta que se abandona dicho estado por la llegada de un evento adecuado. include. No se ver aqu. El resto de las etiquetas se ajustan al siguiente formato: nombreEvento (listaDeParmetros) [condicinDeGuarda] , siendo la lista de parmetros y la condicin de guarda (condicin que se debe satisfacer para que se produzca la accin si se recibe el evento) opcionales.
Por ejemplo (ntese que Rose aade a las etiquetas no predefinidas la palabra event):
LeyendoPassword entry/ poner el eco invisible exit/ poner eco normal event carcter(c)/ tratar carcter (c) event Ayuda/ ^ayuda.mostrarAyuda(password)
Como se puede ver, el estado LeyendoPassword contiene una serie de acciones. En primer lugar, al entrar (entry) se eliminara el eco para evitar que los caracteres tecleados sean visibles. Despus, si se recibe un evento carcter (esto es, el usuario introduce un carcter c) se realiza el tratamiento de dicho carcter (esto
29
es, se aadir a una cadena para ir formando el password que se teclee). Si el usuario pulsara la tecla definida como ayuda, el objeto recibir el evento Ayuda. En ese caso, el objeto manda el mensaje mostrarAyuda al objeto ayuda, con el argumento password (esto es, se requiere al objeto ayuda que muestre la ayuda sobre el password). Al salir de este estado (exit) se vuelve a poner el eco para que se puedan ver los caracteres tecleados. La forma de salir de este estado no se ha especificado, pero puede suponerse que esto ocurre al pulsar el usuario la tecla [enter] (este sera el evento que producira el cambio de estado). En este ejemplo se ha visto cmo especificar desde un objeto el envo de un mensaje. La sintaxis general es: ^objeto.mensaje(argumentos) , siendo los argumentos optativos.
Estados especiales. Estado inicial. Es un pseudoestado que representa el estado en que se encuentra un objeto cuando es creado (inicio de la vida del mismo). Debe aparecer obligatoriamente uno y slo uno en todo diagrama de estados. Grficamente se representa:
Estado final. Es un pseudoestado que indica la destruccin del objeto (finalizacin de la vida del mismo). Es opcional y se pueden aadir varios estados de fin para simplificar el diagrama y evitar el cruce de lneas. Grficamente se representa:
TRANSICIN .
Una transicin es el paso de un estado a otro. Se muestra grficamente como una flecha que va del estado origen al estado destino:
EstadoOrigen EstadoDestino
Este movimiento puede ser reflexivo, es decir, el estado origen y el estado destino pueden coincidir, tal y como se muestra a continuacin:
Las transiciones pueden incluir especificaciones que indiquen cundo ocurre la transicin o qu acciones se llevarn durante la transicin. En caso de no indicarse evento, significa que la transicin ocurre inmediatamente despus de satisfechas las posibles acciones entry, do y exit del estado. El formato general de estas especificaciones es: evento(listaDeParmetros) [condicinDeGuarda] / accin
30
, siendo opcionales todos los componentes. Un evento es un suceso que ocurre y que puede causar la transicin de un estado a otro. La condicin de guarda, si se especifica, debe cumplirse para que la transicin sea posible. La accin es un comportamiento no interrumpible que ocurre como parte de la transicin. Ntese que no siempre es posible sustituir esta accin por una accin interna entry en el estado destino, ya que otras transiciones al estado destino pueden requerir otras acciones (o ninguna). Por ejemplo, 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 botn de avance (evento avance), el robot se pone en movimiento (accin entry) siempre y cuando no est tocando el muro (condicin de guarda de la transicin). Si estamos en movimiento y pulsamos el botn de paro (evento paro) el robot se para (accin exit) y pasa al estado inactivo. Si, por otro lado, estando en movimiento se activa el sensor de muro, el robot se para y adems suena un pitido de alarma, pasando al estado inactivo. En el estado inactivo puede recibir el evento girar que haga que gire un nmero determinado de grados. En este ltimo caso se trata de una transicin reflexiva.
ESTADOS ANIDADOS .
Un estado puede estar compuesto por uno o ms subestados. Estos subestados pueden ser disjuntos o, en el caso de que existan varias regiones o barras de sincronizacin, concurrentes. A su vez, los subestados pueden estar compuestos por otros subestados y as sucesivamente. Por ejemplo, un estado con subestados disjuntos sera el siguiente:
EstadoCompuestoConSubestadosDisjunto
Subestado1
Subestado2
En este caso se ha aadido un estado de inicio y de terminacin dentro del estado compuesto, aunque no es necesario si las transiciones, que entran o salen al estado, llegan o parten de los subestados. Una de las ventajas de los estados compuestos es que, si todos sus subestados responden a una misma transicin, slo hace falta ponerla una vez en el estado superior. Esto hace que se reduzcan el nmero de lneas en el diagrama, hacindolo ms sencillo. Si tomamos el ejemplo del diagrama de estados de un curso dado al inicio, podemos definir un nuevo estado, denominado Activo, que englobe a los subestados Abierto y Cerrado, y agrupar sus transiciones cancelar en una nica transicin que parte del estado Activo:
31
Activo Abierto
fin periodo matrcula Cerrado
fin cuatrimestre cancelar Completado Cancelado
Hay veces que, despus de salir de un estado compuesto, interesa volver al mismo subestado en el que se estaba cuando se sali. Para modelar esta posibilidad, se utilizan estados con memoria. Estos estados se identifican porque en la esquina inferior izquierda tienen una letra H (de History) dentro de una circunferencia.
Por ejemplo:
Activo Abierto dimite profesor Pendiente de cancelacin fin periodo matrcula Cerrado asignado nuevo profesor
cancelar fin cuatrimestre cancelar Completado Cancelado
En este diagrama, existe un nuevo estado al que se accede desde el estado Activo cuando dimite el profesor del curso. Si se asigna un nuevo profesor es posible volver al subestado anterior (Abierto o Cerrado) debido a que el superestado tiene historia.
32
En caso de que los subestados sean a su vez estados compuestos, es tambin posible volver al ltimo subestado pertenezca al nivel que pertenezca. Para ello, 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. Estas reguiones se separan por lineas de puntos en el superestado. Alternativamente a las regiones concurrentes, es posible utilizar barras de sincronizacin, como las que se utilizan en el diagrama de actividades, tal y como se ver. Ejemplo:
Recibiendo clase Incompleto Prctica1 hecha Prctica2 hecha
terminado Trabajo
Aprobado
aprobado Examen
suspendido Suspenso
En este ejemplo, el estado Incompleto (que a su vez es un subestado de Recibiendo clase) est compuesto por tres subestados, cada uno de ellos en una regin concurrente. Adems, el primer subestado est compuesto por otros dos subestados, en este caso disjuntos (Prctica1 y Prctica2). Cuando un estado es compuesto pero su descomposicin est en un diagrama aparte, se aade un pequeo smbolo de composicin en su esquina inferior derecha, tal y como se puede ver en el siguiente ejemplo:
EstadoCompuesto
SIMPLIFICACIN DE TRANSICIONES .
Cuando varias transiciones son disparadas por un mismo evento pero con diferente condicin de guarda, es posible utilizar una simplificacin para su dibujo. Por ejemplo:
ev [cg1]
Origen
ev [cg2] ev [cg3]
Destino1 Destino1 Destino1
Puede simplificarse como:
[cg1] Destino1 ev [cg2]
Origen
Destino1
33
[cg3]
34
DIAGRAMA DE ACTIVIDAD9.
Los diagramas de actividad permiten modelar el comportamiento de un sistema o alguno de sus elementos, mostrando la secuencia de actividades o pasos que tienen lugar para la obtencin de un resultado o la consecucin de un determinado objetivo. Opcionalmente, permite mostrar los flujos de informacin (objetos) producidos como resultado de una actividad y que sern utilizados posiblemente como entrada por la actividad siguiente. Los diagramas de actividad permiten: Modelar el flujo de trabajo de un negocio. Modelar informacin procedimental.
Los diagramas de actividad son tiles para describir flujos de evento en los casos de uso, las actividades que tienen lugar entre un conjunto de objetos (clases) y las operaciones o mtodos de las clases. Es interesante comparar las diferencias entre los diagramas de estados y actividades. La siguiente tabla es un resumen de ellas:
Diagrama de actividades Centrado en las actividades de un proceso.
Diagrama de estados Centrado en los estados de un objeto o sistema.
nfasis en el orden procedimental y/o flujo de nfasis en la reaccin al entorno (control por objetos (control procedimental). eventos).
Veamos a continuacin un ejemplo de diagrama de actividad, 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 Raz
Grabar Fich. Sistema
Actualmente, los diagramas de actividad de UML son un caso especial de una mquina de estados, por lo que comparte ciertas caractersticas comunes con los diagramas de estado. Sin embargo, para evitar confusiones, se ha evitado intencionadamente el uso de la palabra estado al hablar de las actividades, aunque realmente una actividad es un estado de accin.
35
El elemento fundamental de los diagramas de actividad son las actividades. Una actividad representa la ejecucin de una tarea o misin en un flujo de trabajo o la ejecucin de una sentencia en un procedimiento, dependiendo del elemento cuyo comportamiento se est modelando. Las actividades pueden describirse usando lenguaje natural, aunque cuando el diagrama modela operaciones de una clase suele utilizarse pseudocdigo o incluso el lenguaje de programacin en que se vaya a realizar el desarrollo. Las actividades se relacionan unas con otras mediante transiciones, que indican el orden en que se deben de realizar las actividades, empezando desde el punto de inicio del diagrama hasta llegar a un punto final del mismo. Una transicin se dispara cuando termina de realizarse la actividad de la que parte. Tambin es posible aadir condiciones de guarda a las transiciones. Esto permite realizar decisiones o bifurcaciones basadas en las condiciones de las guardas, tal y como muestra el ejemplo siguiente:
Leer PIN
Verificar PIN [ incorrecto ]
[ correcto ]
Ntese que se utiliza un rombo para simbolizar el punto de decisin y el origen de las bifurcaciones. Las condiciones de guarda de una decisin deben ser mutuamente excluyentes, y se permite la condicin especial [else] que se cumple cuando no se cumple ninguna de las otras. Una actividad puede estar compuesta de un conjunto de subactividades, que suelen ser modeladas utilizando un diagrama de actividad propio. Una actividad compuesta no est concluida hasta que no han concluido sus subactividades. Para indicar que una actividad contiene subactividades, se aade un pequeo smbolo de composicin en su esquina inferior derecha, tal y como se puede ver en el siguiente ejemplo:
Actividad Compuesta
En los diagramas de actividad se puede mostrar la concurrencia y la sincronizacin utilizando barras de sincronizacin, que simbolizan uniones y divisiones en el flujo de control. Por ejemplo:
36
Conseguir ingredientes
Calentar aceite
Cascar huevos
Batir
Freir
Como se puede ver, la transicin que sigue a la actividad Conseguir ingredientes se divide por medio de una barra de sincronizacin en dos transiciones que desembocan en las actividades Calentar aceite y Cascar huevos, que pueden ser realizadas de forma concurrente. Por otro lado, la transicin que desemboca en la actividad Freir parte de una barra de sincronizacin a la cual llegan dos transiciones. Este es un punto de sincronizacin que indica que no se disparar la transicin 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).
En los diagramas de actividades tambin se pueden representar calles (swimlanes: calles en el sentido de las diversas calles paralelas en las que se divide una piscina olmpica). 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:
37
Cliente
Ventas
Almacn
Solicitar pedido
Verificar pedido
Reunir pedido
Enviar pedido
Recoger pedido
Obsrvese, por ejemplo, que el cliente es el encargado de realizar las actividades Solicitar pedido y Recoger pedido. Los diagramas de actividad permiten tambin mostrar el flujo de informacin (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 lnea discontinua terminada en flecha que va desde la actividad que genera como salida al objeto, y otra lnea 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 irn modificando el estado del objeto. En este caso se suele aadir al nombre del objeto el estado en que se encuentra entre corchetes.
38
Por ejemplo:
Cliente
Ventas
Almacn
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 construccin de los diagramas de actividad, resulta una conveniencia que puede ser til para aadir cierta clase de informacin en las transacciones. Existen dos iconos de control, el de envo de seal y el de receptor de seal. El icono de envo de seal equivale a una transaccin que enva una seal. Su smbolo es:
El icono de recepcin de seal equivale a un estado de espera, esto es, se produce una espera hasta que se recibe una seal que dispara la transaccin. Su smbolo es:
39
Optativamente, se puede aadir una lnea discontinua acabada en flecha que vaya al objeto que recibe la seal o que parta desde el que la enva (puede ser el mismo). Por ejemplo:
Levantarse
Encender caferera
Coger taza
: Caf
Caf hecho
Beber caf
40
DIAGRAMA DE CLASES.
Los diagramas de clases se utilizan para mostrar la estructura esttica del sistema modelado. Pueden contener clases, interfaces, paquetes, relaciones e incluso instancias, como objetos o enlaces. Los diagramas de clases son una potente herramienta de diseo, ayudando los desarrolladores a planificar y establecer la arquitectura y estructura del sistema y subsistemas antes de escribir ningn cdigo. Esto permite asegurar que el sistema est bien diseado desde el principio. Los diagramas de clases son usados prcticamente en la totalidad de sistemas en que se utiliza UML para su modelado. Para sistemas no triviales, se suele usar ms de un diagrama de clases. Cuando se utilizan varios diagramas, cada uno no tiene necesariamente que representar divisiones del modelo subyacente, sino que se utilizarn segn convenga, pudiendo una misma clase aparecer en diagramas diferentes para representar distintas vistas del modelo.
CLASES.
Las clases son los componentes fundamentales de los diagramas de clases. La notacin general para una clase es un rectngulo dividido en tres secciones, mostrando la primera el nombre de la clase (y opcionalmente otra informacin que afecte a la clase), la siguiente los atributos y la ltima las operaciones. Por ejemplo:
Punto coordenadaX coordenadaY mostrar() ocultar() posicionX() posicionY()
Tanto la seccin de los atributos como la de las operaciones pueden no mostrarse, en cuyo caso tampoco se mostrar la lnea que las separa. Tampoco es necesario visualizar todos y cada uno de los atributos y operaciones, lo cual puede ser til para remarcar qu atributos u operaciones son interesantes en una determinada vista. En este caso, conviene aadir puntos suspensivos (...) al final de la seccin de la que se hayan suprimido atributos u operaciones. Opcionalmente, se pueden aadir ms secciones para indicar otra informacin, como responsabilidades de la clase, excepciones que puede generar, eventos que maneja, etc. Tanto stas como las secciones de atributos y operaciones pueden contener en primer lugar un nombre que indique la seccin de que se trata. Por ejemplo:
Reservas operaciones confirmar() cancelar() cambiar() responsabilidades facturar clientes sin reserva ajustarse a habitaciones libres excepciones tarjeta de crdito no vlida
41
Rose permite especificar la visibilidad de cada clase. La visibilidad puede ser pblica, protegida o privada (-), con los significados usuales. Tambin es posible otras visibilidades dependientes del lenguaje, como por ejemplo la visibilidad de implementacin o paquete (implementation) en el caso de C++ que equivale a una visibilidad pblica para el resto de clases definidas en el mismo paquete y privada para las definidas fuera. Tambin permite especificar otras propiedades, como por ejemplo si los objetos son persistentes, estticos o transitorios. Seccin de nombre. El nombre de la clase se debe poner centrado y en negrita10, y empezando por letra mayscula. En caso de que la clase sea abstracta, el nombre se pondr adems en cursiva. Los nombres de clase deben ser nicos en su entorno, pudiendo coincidir sus nombres si estn definidos en paquetes distintos (ya que sera otro entorno). Cuando sea necesario, se puede preceder al nombre de la clase por el nombre del paquete donde se ha definido, como por ejemplo Utilidades::Visualizador. En caso de especificar un estereotipo para la clase, ste se pondr encima del nombre de la clase. Tambin es posible sustituir el rectngulo por un icono asociado a dicho estereotipo o poner dicho icono en el extremo superior derecho de la seccin. 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. Se aplica a formularios, informes, interfaces y similares. Su icono es el siguiente:
control: Indica que la clase es una clase de control que se dedica a labores de coordinacin. Estas clases son fcilmente reconocibles porque de ellas suelen partir muchos mensajes a otras clases. Su icono es el siguiente:
entity: Contienen la informacin significativa del sistema (entidades) y generalmente son guardadas en almacenamiento externo, esto es, son clases persistentes. Por ejemplo, en un sistema de almacn los clientes, proveedores y productos seran clases a las que se les aplicara este estereotipo. Su icono es el siguiente:
En esta seccin tambin se pueden aadir, debajo del nombre, valores etiquetados con alguna informacin relativa a la clase. En el siguiente ejemplo se muestra la clase EntradaMaterial, con el estereotipo boundary y valores etiquetados que indican su autor y estado:
boundary EntradaMaterial {autor = Eva, estado = comprobado}
10
Rose no lo visualiza en negrita.
42
Seccin de atributos. En la seccin de atributos se muestran todos o parte de los atributos, alineados a la izquierda y utilizando la siguiente sintaxis: visibilidad nombre[multiplicidad]:tipo=valorInicial {cadenaPropiedades} La visibilidad puede ser pblica (+), protegida (#), privada (-) o, segn el lenguaje, implementacin. Rose permite mostrar la visibilidad mediante los signos o, de forma optativa, con un icono:
Es obligatorio definir la visibilidad para cada atributo, aunque se puede no visualizar. El nombre del atributo se escribir con minsculas, y a continuacin se pondr entre corchetes su multiplicidad (siendo optativo para el caso habitual de multiplicidad 1). Cuando la multiplicidad es mayor que uno se puede pensar que equivale a definir un array. La multiplicidad en UML se indica como uno o ms intervalos enteros (en el caso de mltiples intervalos, se separarn por comas). Cada intervalo tiene el formato lmiteInferior..lmiteSuperior (cuando el lmite inferior es igual que el superior basta con poner simplemente el nmero). Para indicar un lmite indefinido, se utiliza el smbolo asterisco (*), aunque Rose utiliza en este caso la letra ene (n). Ejemplos de multiplicidad son: 0..1 1 0..* 1..6 1..3, 7..10, 15, 19..*
Si un atributo tiene como multiplicidad 0..1, significa que dicho atributo podr contener un valor o ninguno (esto es, puede tener un valor nulo, que significa la ausencia de valor). Imagnese que una estacin meteorolgica recoge la temperatura a medio da todos los das. Si un da, por cualquier razn, esto no es posible, el valor de dicho atributo ser nulo (ningn valor), que es distinto de 0.0, que sera una temperatura de 0. Si tuviramos que hallar la media de temperaturas, las temperaturas con valor nulo no seran usadas (no pueden sumar en el numerador ni tampoco cuentan para el denominador). El tipo ser uno de los existentes en el lenguaje de desarrollo, igual que la forma de expresar el valor inicial. El valor inicial es optativo (en cuyo caso no se incluye el signo igual), pero el tipo es obligatorio, aunque puede no visualizarse. La cadena de propiedades es optativa. Por ejemplo, {frozen} indica que un atributo no es modificable. Cuando la clase dispone de un atributo(s) clave, esto es, que el valor de dicho atributo(s) identifica de forma unvoca a cada objeto de dicha clase, se puede indicar subrayndolo(s). Los atributos derivados, esto es, los atributos cuyo valor se calcula a partir de otros atributos de la clase, se marcan con una barra inclinada (/) delante del nombre. Aunque el uso de atributos derivados se debe evitar, pueden ser recomendables en algunos casos por cuestiones de eficacia (tiempo de ejecucin). Los atributos estticos, esto es, atributos cuyo valor es compartido por todas las instancias de una clase, se marcan con el smbolo de dlar ($) delante del nombre. Es posible agrupar atributos por estereotipo precedindoles del mismo.
43
Rose tambin permite indicar el modo de almacenamiento del atributo, esto es, si ser almacenado por valor o por referencia. Ejemplos:
Habitacion -largo: double -ancho: double #/area: double -id: int {frozen} -estado: tEstados = habitable Punto -coordenada[1..3] #color -visible ...
Aprciese en la clase Habitacin que el atributo area es derivado, ya que puede calcularse multiplicando el valor de los atributos largo y ancho. Ntese tambin que en la clase Punto no se han visualizado el tipo de sus atributos, aunque s estarn definidos, y slo se han mostrado parte de los atributos, por lo que se han aadido punto suspensivos para indicarlo.
Seccin de operaciones. En la seccin de operaciones se muestran todas o parte de las operaciones que la clase proporciona, alineadas a la izquierda y utilizando la siguiente sintaxis: visibilidad nombre(listaParmetros):tipoRetorno {cadenaPropiedades} La visibilidad puede ser pblica (+), protegida (#), privada (-) o, segn el lenguaje, implementacin, de forma similar a la visibilidad de los atributos. Es obligatorio especificarla, aunque puede no visualizarse. El nombre de la operacin se escribir en minsculas. En caso de que sea una operacin abstracta (recurso utilizado para implementar polimorfismo), se escribir en cursiva. En caso de existir parmetros, estos vendrn separados por comas y siguiendo la siguiente sintaxis para cada parmetro: clase nombre: tipo = valorPorDefecto La clase puede ser: in: Parmetro de entrada. Es el valor por defecto. En C++ se puede indicar con const. out: Parmetro de salida. inout: Parmetro de entrada y salida.
El nombre indica el nombre del parmetro formal y se escribir en minsculas. Despus se indica el tipo del parmetro (que ser dependiente del lenguaje) y, en caso de que existiera, el valor por defecto. A continuacin se indica el tipo que retorna la operacin (que ser dependiente del lenguaje), pudiendo suprimirse si la operacin no devuelve ningn valor (procedimiento). Por ltimo, se podr indicar una cadena de propiedades. Aqu se podra indicar, por ejemplo, si una operacin es secuencial {concurrency=sequential} o concurrente {concurrency=concurrent}. Es posible aadir una nota a una operacin para indicar, por ejemplo, su algoritmo o cdigo. Rose tambin permite para cada operacin especificar, entre otras, las precondiciones, postcondiciones, su
44
semntica, la cantidad (absoluta o relativa) de memoria necesaria para la operacin y el tiempo (absoluto o relativo) que precisar su ejecucin. Las operaciones se pueden clasificar de la siguiente forma: Implementadoras. Proporcionan una funcionalidad bsica del negocio. Estas operaciones son las que responden a los mensajes que aparecen en los diagramas de interaccin de alto nivel, que proceden de los flujos de eventos de los casos de uso y estos a su vez de los requerimientos. Administracin. Pertenecen a esta categora los constructores y los destructores, encargados de la construccin y destruccin de objetos de la clase. Acceso. Permiten leer o escribir en los atributos (generalmente, realizando las comprobaciones de integridad oportunas en el caso de escritura). Auxiliares. Operaciones necesarias para que la clase pueda realizar su trabajo, pero que no son visibles desde el exterior. Este tipo de operaciones aparece como mensajes reflexivos en los diagramas de interaccin (generalmente, en los de bajo nivel).
Las operaciones se pueden agrupar por estereotipo precedindolas del mismo. Por ejemplo:
Rectangulo -p[1..2]: tPunto constructor +Rectangulo(p1: tPunto, p2: tPunto) query +area(): double +perimetro(): double ... update #mover(delta: tPunto) #escalar(ratio: double=2.0) ...
Ntese que se ha escrito el nombre del constructor empezando por maysculas. Esto ha sido as porque, presuponiendo que esta clase se implementar en C++, el nombre del constructor debe ser igual que el nombre de la clase. Las clases deben estar equilibradas tanto en el nmero de operaciones como en el de los atributos. Si una clase tiene muy pocos atributos u operaciones, puede significar (aunque no necesariamente) que se ha llegado a una descomposicin demasiado grande y que sera mejor que fuera absorbida por otra clase con responsabilidades coherentes. Si una clase tiene demasiados atributos u operaciones, puede significar (aunque no necesariamente) que tiene demasiadas responsabilidades y que es mejor dividirla en dos o ms clases ms sencillas.
RELACIONES .
Una relacin es una conexin semntica entre elementos (en nuestro caso, clases o, de forma ms general, entre clasificadores). Existen cuatro tipos principales de relaciones en UML: Generalizacin: Es una relacin de especializacin. Asociacin: Es una relacin estructural. Existen dos subtipos, la agregacin y la composicin. Realizacin: Es una relacin contractual, en la cual un clasificador especifica un contrato (por ejemplo, un interface) que otro clasificador garantiza que cumplir.
45
Dependencia: Es una relacin de uso.
Desde un punto de vista amplio, la generalizacin, asociacin y realizacin son tambin relaciones de dependencia. Sin embargo, debido a sus caractersticas particulares, UML las cre como relaciones especficas. Conviene modelar antes estas relaciones, ya que las que no se ajusten a ellas sern relaciones de dependencia. Hay varias formas de encontrar o disear relaciones. Por ejemplo, si en un diagrama de interaccin un objeto a manda un mensaje a un objeto b, habr una relacin entre ellos (tpicamente una asociacin o una dependencia). Tambin se deben examinar posibles relaciones todo-parte (que posiblemente se podrn modelar como relaciones de composicin o agregacin). Las generalizaciones de pueden crear mediante un proceso descendente (de arriba a abajo, de la clase ms general a la ms particular) o ascendente (de abajo a arriba, de las ms particulares a las ms generales).
Generalizacin. La generalizacin es una relacin taxonmica11 entre el objeto ms general (el padre o superclase) y el ms especfico (el hijo o clase descendiente). Grficamente, se especifica como una lnea acabada en flecha vaca que va del elemento ms particular (el hijo) al ms general (el padre):
ClasePadre
ClaseHija
La generalizacin se utiliza para modelar la herencia en los lenguajes orientados a objetos. Una de las caractersticas de la herencia es que permite simplificar la construccin de clases relacionadas, ya que gracias a ella es posible agrupar las caractersticas comunes de un conjunto de clases en una clase padre (superclase) y hacer que todas ellas hereden de la superclase. Todos los lenguajes orientados a objetos permiten la herencia simple (una clase puede descender a lo sumo de otra), aunque algunos lenguajes, como C++, permiten la herencia mltiple (una clase puede descender de varias clases padre). Aunque la descendencia mltiple puede ser muy conveniente en algunos casos, no se debe abusar de ella (ya que puede resultar compleja su utilizacin). Tambin se debe cuidar el esquema de herencia. Un esquema con demasiados niveles (ms de cuatro o cinco) es usualmente demasiado complicado de entender; un esquema de slo dos niveles y muy ancho no suele estar aprovechando la potencia de la herencia (ya que, posiblemente, sera posible extraer caractersticas comunes entre algunas clases del segundo nivel que permitiera la creacin de un nuevo nivel).
11
Clasificacin, en el sentido de clasificacin de especies en ancestras y descendientes.
46
Por ejemplo:
Vehculo
Terrestre
Martimo
Areo
Automvil
Camin
Globo
Aeroplano
Vase que en este ejemplo las clases Vehculo, Terrestre y Areo son abstractas, luego no se puede instanciar ningn objeto de ellas. Si el lenguaje dispusiera de herencia mltiple, podramos crear clases descendientes de varias clases padre, como en el siguiente ejemplo:
Terrestre
Martimo
Anfibio
La relacin de generalizacin tambin puede darse entre paquetes, indicando que un paquete es una especializacin de otro. Los paquetes descendientes heredan los elementos pblicos y protegidos del paquete ancestro, redefiniendo generalmente algunas clases y definiendo otras nuevas. Por ejemplo:
GUI12
WindowsGUI
XWindowGUI
12
Interface grfica de usuario.
47
Asociacin. Las asociaciones modelan relaciones estructurales entre clases. Una asociacin se representa grficamente como una lnea que conecta las clases relacionadas:
Compaa Persona
Esta asociacin significa que la clase Compaa puede acceder a los atributos y operaciones pblicas de la clase Persona y que, de forma similar, la clase Persona puede acceder a los atributos y operaciones pblicas de la clase Compaa. Tambin se puede restringir la navegabilidad de la asociacin, aadiendo una flecha que indique el sentido de dicha asociacin:
Compaa Persona
En este caso, Compaa puede acceder a los atributos y operaciones pblicas de la clase Persona, pero Persona no puede acceder a Compaa.
Una clase puede relacionarse consigo misma, es decir, pueden modelarse asociaciones reflexivas:
Persona
Esta asociacin reflexiva podra modelar, por ejemplo, la relacin es familiar directo de.
Se pueden aadir varios adornos y otros elementos a las asociaciones que aumentan su expresividad o completan o restringen su significado: Nombre de la asociacin. Es un nombre descriptivo que indica la naturaleza de la asociacin. Opcionalmente se puede aadir un pequeo tringulo que indique el sentido en que se debe interpretar. Por ejemplo:
Trabaja para Compaa Persona
En este ejemplo, estamos expresando que las personas trabajan para las compaas. Tngase en cuenta que el sentido del nombre de la asociacin no restringe la navegabilidad. Es posible indicar el estereotipo de la asociacin encima del nombre, siendo tambin posible indicar una cadena de propiedades a la derecha del nombre o debajo. Roles. Se puede indicar el rol que desempea una o ambas clases en la asociacin. Por ejemplo:
Compaa patronal empleado Persona
48
Multiplicidad. Se puede indicar cuntas instancias (objetos) de una clase podrn estar asociados a una instancia (objeto) de la otra. Por ejemplo:
Compaa 0..* 1..* Persona
En este caso, para una compaa podrn trabajar una o ms personas, y una persona podr trabajar en cero (que representara el caso de estar desempleada) o ms compaas. Calificador. Es un atributo que califica una asociacin. Dado un objeto origen y un valor determinado para el calificador, se obtendr un objeto destino (si la multiplicidad del destino es a lo ms uno) o un conjunto de objetos destino (si la multiplicidad del destino es muchos). Por ejemplo:
titular N cuenta: int 0..* 0..1
Banco
Persona
En este ejemplo, dado un banco y un nmero de cuenta, obtendremos una persona (el titular de la cuenta). Tngase en cuenta que el calificador pertenece a la asociacin y no es un atributo ni del banco ni de la persona. Es significativo el extremo de la asociacin en el que se pone el calificador. Por ejemplo, si el n de cuenta lo representramos nada ms que con los dgitos finales (eliminando los dgitos iniciales, que son los que especifican el banco), tal y como est el ejemplo, para un banco y un nmero de cuenta obtendramos un solo titular. Pero si pusiramos el n de cuenta en el extremo de Persona, dado un titular y un n de cuenta obtendramos uno o ms bancos. El uso de cualificadores restringe el entorno de la asociacin y es til, por ejemplo, para realizar bsquedas. Orden. Si la multiplicidad es mayor que uno, los elementos relacionados por la asociacin pueden estar ordenados o no. Se utiliza {ordered} para indicar que dichos elementos se encuentran ordenados. Por ejemplo:
paciente Lista Mdico {ordered} Persona
Xor-asociacin. Se utiliza esta restriccin para indicar que slo una de las posibles asociaciones modeladas en el diagrama de clases puede ser instanciada en un momento dato para una determinado objeto. Se representa grficamente como una lnea de puntos que conecta dos o ms asociaciones a la que se le aade la restriccin {xor}. Por ejemplo:
Persona Cuenta {xor} Compaa
Aqu estamos indicando que una cuenta puede estar a nombre de una compaa o de una persona, pero no simultneamente de ambas. Esto es, un objeto : Cuenta puede estar relacionado (enlazado) con un objeto : Persona o con un objeto : Compaa, pero no con un objeto : Persona y un objeto : Compaa a la vez.
49
Clase asociacin. Designa a una asociacin que tiene propiedades de clase, tales como atributos, operaciones y/o otras asociaciones. Siempre es representada junto a la asociacin a la que corresponde, y unida a ella mediante una lnea discontinua. Ya que clase y asociacin forman un todo, el nombre de ambas es igual, pudindose especificarse en cualquiera de ellas o en ambas. Por ejemplo:
0..* Compaa patronal Trabajo fechaContrato salario trabajador 0..* edirige jefe 0..1 empleado 1..* Persona
Ntese que Trabajo, al pertenecer a la asociacin, est ligado tanto a Compaa como a Persona, y es ese conjunto el que tiene significado. Vase que este diagrama permite modelar que una persona p1 fuera jefe de otra persona p2 en una compaa c1, y que simultneamente p2 fuera jefe de p1 en una compaa c2.
Hasta ahora se han visto asociaciones binarias, pero las asociaciones se pueden dar entre cualquier nmero de clases. Tal caso se representa grficamente como un rombo que est unido por una lnea continua a todas las clases incluidas en la asociacin. Por ejemplo:
Temporada 0..* Equipo 0..* 0..* Jugador
Ficha sueldo clausulaRescision
En este ejemplo se modela una asociacin denominada Ficha (que adems tiene una clase asociacin) entre las clases Temporada, Jugador y Equipo.
50
Agregacin y composicin. Estas relaciones son un tipo especial de asociacin. En una relacin de asociacin, las clases participantes tienen una relacin de igual a igual, mientras que en la agregacin y la composicin la relacin es de todo-parte. Esto es, una clase forma parte o es un componente, en algn sentido, de otra. La composicin es ms fuerte que la agregacin. En la composicin, la vida de la parte coincide (o es un subintervalo) de la vida del todo. Es el todo quien se tiene que encargar de construir y destruir la parte y la parte, en general, no podr ser compartida por ningn otro elemento. Simplificando se puede decir que, internamente, una clase todo contendr a una clase parte agregada por referencia, mientras que a una clase parte compuesta la contendr por valor. La agregacin se representa como una asociacin con un rombo vaco en el lado de la clase todo. Por ejemplo:
1 Coche 4 Rueda
Aqu se ha mostrado que un coche (el todo) tiene cuatro ruedas (la parte). Se ha modelado como una agregacin porque la rueda puede existir antes que el coche como entidad propia o incluso despus (se desguaza el coche y de dejan las ruedas) e incluso se puede cambiar alguna de las ruedas de un coche a otro.
La composicin se representa como una asociacin con un rombo lleno en el lado de la clase todo. Por ejemplo:
1 Formulario 0..* Botn
Aqu se ha mostrado que un formulario (el todo) puede contener cero o ms botones (la parte). Un botn slo puede existir dentro de un formulario, por lo que la vida del botn estar restringida a la vida del formulario que lo posee. Un botn pertenece a un y slo un formulario. He aqu otro ejemplo de composicin y agregacin:
1 Poligono 1 {ordered} contiene f 3..* Punto
PropiedadesGraficas 1 color textura focosIluminacion
Realizacin. Una realizacin es una relacin semntica entre clasificadores, en la cual un clasificador especifica un contrato que otro clasificador garantiza que cumplir. Generalmente se emplea la realizacin para especificar una relacin entre una interfaz y la clase o componente que implementa las operaciones especificadas en dicha interfaz.
51
Una interface es un clasificador que especifica una serie de operaciones, pero que no proporciona ninguna implementacin (ni tiene atributos). Es equivalente a una clase abstracta que slo tiene operaciones abstractas. Un ejemplo de interface sera el RS-232 (suele ser el estndar para puertos serie). El estndar especifica operaciones como el envo y recepcin de caracteres, que podrn ser implementados por un chip o tarjeta (que son los que realizan dicha interface). Grficamente, una interface se muestra como una clase con el estereotipo interface y sus operaciones, o en forma resumida como un crculo y debajo el nombre del interface:
interface Mensurable peso(): double volumen(): double Mensurable
En este caso, el interface Mensurable especifica dos operaciones, peso() y volumen(). Para indicar que una clase realiza una interfaz, se muestra una lnea discontinua acabada en flecha vaca que va de la clase que implementa el interfaz a la interfaz.
Por ejemplo:
Saco
... peso(): double volumen(): double ...
interface Mensurable peso(): double volumen(): double
Automvil
... peso(): double volumen(): double ...
En este caso, se indica que tanto Saco como Automovil realizan el interface Mensurable, es decir, ambas implementan las operaciones indicadas en el interface. En el caso de usar la notacin resumida, se unir el interface a la clase que lo implementa por una lnea continua. Por ejemplo:
Saco
Mensurable
Automvil
Mensurable
52
Cuando una clase realiza un interface, debe implementar todas las operaciones indicadas en dicha interface y, posiblemente, otras exclusivas de la clase. Varias clases pueden satisfacer un interface (como en el ejemplo anterior), y una clase puede satisfacer varios interfaces. Por ejemplo:
Furgoneta
Mensurable
Alquilable
Las interfaces pueden evitar en ciertos casos el uso de herencia mltiple. Son muy tiles para independizar la implementacin de sistemas o utilidades de los servicios u operaciones que proporcionan (esto es, se puede cambiar la implementacin sin que sea necesario modificar las llamadas, ya que no se ha modificado el interface), fomentando la reutilizacin. Los interfaces son soportados por lenguajes como Java o Corba. Otra de las posibilidades de los interfaces consiste en limitar el acceso en las asociaciones. Por ejemplo, sea el siguiente interface:
interface Empleado nombre() fechaNacimiento() dni() numeroHijos()
Si en el extremo de una asociacin especificamos un nombre (o lista de nombres) de interface(s) precedidos de dos puntos, la clase en el extremo contrario slo podr acceder a las operaciones indicadas en el interface, como en el siguiente ejemplo:
Compaa : Empleado
Persona
Esto evitara, por ejemplo, que la Compaa pudiera acceder a mtodos de la clase Persona que no fueran de su incumbencia para el tipo de relacin Compaa-Persona (como sera el caso, suponiendo que la clase Persona lo implementara, del mtodo perteneceGrupoRiesgoSida(): bool, que s sera de incumbencia en una relacin Mdico-Persona).
Dependencia. Una dependencia es una relacin entre un elemento dependiente (el cliente) y un elemento independiente (el suministrador del servicio requerido). El elemento dependiente (cliente) requiere conocer al elemento independiente (suministrador) y que ste est presente. 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).
53
Es un tipo de relacin unidireccional, ya que el elemento dependiente debe conocer al independiente, pero el independiente desconoce la existencia del elemento dependiente. Grficamente se muestra como una lnea discontinua acabada en flecha que va del elemento dependiente al independiente (esto es, el elemento dependiente seala al elemento del que depende). Por ejemplo:
Cliente
Servidor
En este caso, la clase Cliente (dependiente) depender de servicios proporcionados por la clase Servidor (independiente), y un cambio en la clase Servidor puede ocasionar que la clase Cliente necesite ser adaptada. Un cambio en la clase Cliente no tiene ningn efecto sobre la clase Servidor, ya que esta ltima es independiente de la primera (no la necesita). Para que la clase dependiente tenga acceso a la clase independiente, la clase independiente debe tener visibilidad global, ser pasada como parmetro a una operacin o ser instanciada como variable local en una operacin de la clase dependiente. Cuando una clase usa los servicios de otra a travs de un interface, tambin se modela como dependencia (depende del interface, un cambio en el interface requerira un cambio en la clase dependiente). Por ejemplo:
ClaseImplementadoraInterface Interface
ClaseDependiente
Ntese que la ClaseDependiente depende de Interface, no de la ClaseImplementadoraInterface. De hecho un cambio en la ClaseImplementadoraInterface no tendra ninguna consecuencia sobre la ClaseDependiente, ya que el interface asla de posibles cambios en la clase implementadora.
Las relaciones de dependencia tambin se utilizan para mostrar la dependencia entre paquetes. Tal y como se dijo, las clases se suelen agrupar en paquetes. Para agrupar las clases en paquetes, se pueden utilizar varios criterios. Un criterio puede ser el agrupar las clases por estereotipos (en este caso habra un paquete para las clases frontera, otro para las de control y otro para las de entidad). Tambin es posible agrupar las clases por su funcionalidad (podra haber un paquete con clases que se encargaran del control de acceso, otras de la gestin informes, otra de errores, etc.). Como los paquetes pueden contener a su vez otros paquetes, una tercera posibilidad consiste en agrupar las clases por funcionalidades y dentro de cada grupo de funcionalidad, volver a agrupar por estereotipo. Una relacin de dependencia entre un paquete A y un paquete B indica que alguna clase del paquete A tiene una relacin unidireccional con alguna clase del paquete B y, por tanto, el paquete A necesita tener acceso al paquete B. Las relaciones de dependencia entre paquetes deben ser calificadas con el estereotipo access o import. Con ambos estereotipos se tiene acceso a los elementos pblicos del paquete independiente, pero con access es necesario preceder dichos elementos por el nombre del paquete que los contiene mientras que con import no (en este caso, es necesario que ningn nombre de un elemento del paquete dependiente coincida con un nombre de elemento del paquete independiente). Por ejemplo:
access A B
54
Esta dependencia tiene implicaciones en la reutilizacin. El paquete B es fcilmente reutilizable (es independiente), mientras que el paquete A no lo es, ya es dependiente del B y para reutilizar el paquete A habra que usar tambin el B. Se deben evitar en lo posible referencias circulares. Los paquetes contenidos en otros paquetes pueden acceder a todos los elementos del paquete que los contiene. Sin embargo, las dependencias no son transitivas, tal y como se muestra en el siguiente ejemplo:
B import A
C
import D
El paquete A puede acceder al paquete B y al paquete C. El paquete B y el paquete C pueden acceder al paquete D. El paquete A no puede acceder al paquete D. Si se deseara que A accediera a D, habra que aadir una dependencia de A a D.
Clases parametrizadas. Una clase parametrizada o plantilla (template) es un descriptor de una clase con uno o ms parmetros formales. Una clase parametrizada define una familia de clases: cada clase se especifica ligando los parmetros formales de la clase parametrizada a valores reales. Una plantilla no es utilizable directamente (es decir, no se puede instanciar ningn objeto de la misma) por tener parmetros libres. Grficamente, una clase parametrizada se muestra como una clase a la que se aade un recuadro en lnea discontinua en la parte superior derecha donde se indican sus parmetros formales:
ListaParmetros NombreClase
Las clases parametrizadas suelen utilizarse para crear contenedores, siendo el parmetro el tipo de elemento que almacenar dicho contenedor. Tambin puede recibir valores, como por ejemplo un nmero entero. Un ejemplo de clase parametrizada (del tipo contenedor) sera una plantilla de pila. Esta plantilla, adems de tener el tipo del elemento a almacenar como parmetro, podr recibir un valor entero que indique el mximo nmero de elemento de la pila (100 por defecto). Para instanciar una clase a partir de la clase parametrizada, se utilizar una dependencia estereotipada como bind (ligar), tal como se muestra en el ejemplo:
tElem, Pila
bind
Tambin es posible indicar directamente los parmetros entre ngulos en la clase instanciada. Por ejemplo:
Pila<persona>
PilaPerson
55
Ntese que en este caso no se ha especificado el nmero mximo de elementos, luego la pila tendr 100 que es el nmero que se le ha dado por defecto. Si quisiramos dar expresamente el valor, quedara:
Pila<persona,100>
UTILIDADES .
Las utilidades son un agrupamiento de variables y procedimientos globales en forma de una declaracin de clase. Es un artificio que facilita el diseo y programacin. Una clase utilidad se modela con el estereotipo utility, tal como se puede ver en el siguiente ejemplo:
utility UtilidadesMatemticas sin(double): double random(): double ...
Otro ejemplo sera una utilidad de operaciones estadsticas, como la media, la mediana, la desviacin, etc. Al definirse como utilidad, se podran utilizar dichas operaciones directamente por cualquier clase (visibilidad global). Las utilidades pueden estar parametrizadas, utilizndose una notacin similar a las clases parametrizadas.
TIPOS .
Los tipos se utilizan para especificar un dominio de objetos junto con las operaciones aplicables a dichos objetos, sin definir ni la implementacin fsica de esos objetos ni mtodos. Un tipo se representa como una clase con el estereotipo type:
type MiTipoDeDatos
Esta notacin permite modelar los tipos predefinidos del lenguaje o crear tipos nuevos. Para que el nuevo tipo sea utilizable, es necesario crear una clase que proporcione mtodos para todas las operaciones del tipo. La relacin sera una realizacin:
type MiTipoDeDatos MiTipoDeDatosImplementado
DIAGRAMA DE OBJETOS.
Un diagrama de objetos es una instancia de un diagrama de clases. Es una instantnea de un sistema en la que se detalla el estado del mismo en ese momento: objetos, valores significativos de los atributos y enlaces entre objetos. Un diagrama de clases indica lo que puede ser el sistema; un diagrama de objetos
56
representa la situacin del sistema en un momento determinado (se utilizan instantes significativos o prototpicos). Los diagramas de objetos se utilizan, generalmente, para visualizar, especificar y documentar modelos estructurales, esto es, estructuras de objetos cuya complejidad aconseje dibujar un diagrama que sirva para una mejor comprensin del modelo. En general, existen dos posibilidades: Partir del diagrama de clases y crear una instancia (diagrama de objetos) que permita una mejor comprensin del mismo. Partir de un diagrama de objetos significativo y modelar un diagrama de clases que posibilite, al menos, dicha instancia. Esto sucede, por ejemplo, cuando se conocen ejemplos de la estructura real y se quiere derivar un diagrama de clases al que se ajuste.
Para construir un diagrama de objetos hay que: Identificar la estructura o mecanismo que se quiera modelar. Identificar las clases, interfaces y otros elementos que intervengan en la relacin. Considerar un escenario en el que intervenga ese mecanismo y congelar ese escenario, representando cada objeto que participe en dicho mecanismo. Mostrar los valores y atributos necesarios para comprender el escenario. Mostrar los enlaces entre esos objetos, que representarn instancias de asociaciones entre ellos.
Por ejemplo, si tenemos este diagrama de clases:
Compaa 1
0..n Dpto 0..n 1..n Persona
57
podramos modelar el siguiente diagrama de objetos para documentarlo:

: Compaa
ventas: Dpto nombre= Ventas
id: Dpto nombre= I+D
: Persona : Persona dMa: Dpto nombre= Deleg. Madrid dLu: Dpto nombre= Deleg. Lugo : Persona
: Persona
: Persona
: Persona
Ntese que los enlaces son instancias de las relaciones del diagrama de clases, esto es, relaciones que se dan en un momento dado, por lo cual no puede aparecer ninguna multiplicidad en ellas. Tambin se han incluido los valores del atributo nombre de los objetos de la clase Dpto para facilitar su entendimiento. Tambin es posible especificar el estado en que se encuentra el objeto. Por ejemplo, el siguiente diagrama muestra un objeto de la clase Robot que se encuentra movindose (estado movimiento), as como el mundo (entorno) que ha identificado y la relacin 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
58
Ntese que el objeto a1 es un rea rectangular (habitacin) formada por tres muros y una puerta, y que cada uno de los elementos constituyentes est relacionado con su adyacente (por ejemplo, el muro m1 limita con la puerta p1 y con el muro m3).
Como en los diagramas de clases tambin se pueden mostrar objetos, un diagrama de clases que slo contenga instancias de clases, esto es, objetos, se le puede denominar diagrama de objetos. Este caso sucede, por ejemplo, en Rose: no hay un diagrama de objetos como tal, por lo que se debe utilizar un diagrama de clases para representar un diagrama de objetos.
59
DIAGRAMAS DE IMPLEMENTACIN.
Los diagramas de implementacin muestran aspectos relativos a la implementacin, incluyendo la estructura del cdigo fuente y similares (diagrama de componentes) y la estructura de implementacin en tiempo de ejecucin (diagrama de despliegue).
DIAGRAMAS DE COMPONENTES.
Un diagrama de componentes se utiliza para modelar los componentes de un sistema y mostrar las dependencias entre ellos. Un componente representa un mdulo de software con un interface bien definido. Ejemplos de componentes son el cdigo fuente, cdigo binario, ejecutable, DLL, fichero de inicializacin (.ini), fichero de registro (.log), tablas, documentos, mapas de bits de los iconos de una aplicacin, etc. Los componentes pueden existir en tiempo de compilacin, de enlace o de ejecucin o incluso en varios o todos esos tiempos. Los componentes son equivalentes a tipos, siendo sus instancias las que aparecern en el diagrama de despliegue. Hay una gran diferencia entre clases y componentes. Las clases son componentes lgicos, mientras que los componentes tienen significado fsico. Antes de poder generar cdigo, las clases deben ser mapeadas a componentes (esto es, las clases residen o son implementadas en componentes), y estos componentes sern los que contengan su cdigo fuente. La notacin estndar de un componente es:
Nombre
Dentro del componente se especifica su nombre y/o su tipo y, opcionalmente, una cadena de propiedades que indiquen, por ejemplo, su versin, autor, estado, etc. Tambin se puede mostrar dentro de un componente las clases o paquetes que residan en l, o incluso otros componentes. Un componente puede depender de otro. En este caso existe una relacin de dependencia entre ellos, tal y como se puede ver en el siguiente ejemplo:
programa.exe
programa.pas
Ntese que el programa ejecutable (programa.exe) depende del programa fuente (programa.pas). Esta es una dependencia de compilacin: para generar programa.exe necesitamos programa.pas. Tal y como se dijo, los componentes deben tener interfaces bien definidos. Esto permite que los componentes puedan ser reemplazados (por ejemplo, por componentes ms eficaces) y reutilizados fcilmente, posibilitando la construccin de componentes complejos utilizando componentes ms simples. Se puede expresar explcitamente que un componente depende de un interface realizado por otro componente, tal y como se muestra a continuacin:
B.dll A.exe
60
Esto podra modelar, por ejemplo, un ejecutable A.exe que requiere de algn servicio proporcionado por la dll (Dinamic Link Library) B.dll. No habra ningn problema en cambiar la dll por otra ms moderna que fuera, por ejemplo, ms eficaz, ya que, al accederse a ella a travs de un interface, no habra que realizar ninguna modificacin en los ejecutables. Rose proporciona para los componentes algunos estereotipos estndar con iconos asociados, tal y como se muestra a continuacin: Especificacin y cuerpo de subprograma. Los subprogramas son colecciones de rutinas (no contienen definiciones de clases), tales como funciones o procedimientos. Las especificaciones constituyen el interface del componente (la definicin de las funciones; en C++ sera el fichero .h) y el cuerpo la implementacin (la implementacin de las funciones; en C++ sera el fichero .cpp). Sus representaciones grficas son:
Especificacin de Subprograma Cuerpo de subprograma
Programa principal. Indica que en el componente reside el programa principal. Su representacin grfica es:
Programa principal
Especificacin y cuerpo de paquete. Los paquetes contienen las clases. Las especificaciones constituyen el interface del componente (la definicin de las clases; en C++ sera el fichero .h) y el cuerpo la implementacin (la implementacin de los mtodos de las clases; en C++ sera el fichero .cpp). En C++ se pueden asociar varias clases a un componente, mientras que en Java cada clase debe asociarse a un componente individual. Sus representaciones grficas son:
Especificacin de paquete Cuerpo de paquete
Especificacin y cuerpo de tarea. Representa paquetes que tienen hilos independientes de control. Normalmente, un fichero ejecutable se representa como una especificacin de tarea con extensin .exe. Sus representaciones grficas son:
Especificacin de tarea Cuerpo de tarea
61
Los diagramas de componentes permiten mostrar tanto dependencias en tiempo de compilacin y lincado como en tiempo de ejecucin. Incluso permiten mostrar dependencias entre varias versiones de componentes. Por ejemplo, el siguiente diagrama muestra dependencias en tiempo de ejecucin:
.exe
.hlp
a.dll
.ini
.log
b.dll
Este otro diagrama muestra dependencias en tiempo de compilacin:
principal.exe
principal.cpp
a.h
b.h
c.h
b.cpp
a.cpp
c.cpp
62
Este tipo de diagrama muestra el orden en que se deben compilar los ficheros, a qu otros componentes afectara el cambio de uno de ellos y qu se debera recompilar. Tngase en cuenta que en los diagramas que muestran la secuencia de compilacin no deben aparecer referencias circulares, ya que sera imposible realizar dicha compilacin. A la hora de asociar clases a componentes, si stas se han agrupado en paquetes, se suelen asociar dichos paquetes a los componentes. Sin embargo, hay veces en que conviene hacerlo de forma diferente (para adaptarse a una arquitectura cliente-servidor, porque haya clases sujetas a modificaciones frecuentes, etc.). Adems, aunque una clase se suele asociar a un solo componente, hay veces que conviene asociar una misma clase a varios componentes. Rose permite especificar el lenguaje en que se realizar cada componente. Esto permitira, por ejemplo, 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.
63
DIAGRAMA DE DESPLIEGUE.
Los diagramas de despliegue muestran la configuracin de elementos de proceso (el despliegue de procesadores, perifricos, comunicaciones, etc.) y los componentes software (programas, procesos, etc. ) que residen en ellos en tiempo de ejecucin. En los diagramas de despliegue aparecen instancias de componentes, pertenecientes al diagrama de componentes, mostrndose en qu nodos (procesadores) reside cada instancia. En un diagrama de despliegue no pueden aparecer componentes que no existen como entidades en tiempo de ejecucin, como los ficheros fuente. Los nodos de un diagrama de despliegue representan elementos fsicos con capacidad de proceso o facilitadores de algn servicio. Se puede especificar el tipo de un nodo o una instancia del mismo (en cuyo caso se subrayar). Un nodo se representa tal como sigue:
Nombre
Rose utiliza dos representaciones diferentes para los nodos. Si el nodo tiene capacidad de proceso (como un ordenador, un servidor o similar), los laterales se ponen en negro:
Si el nodo no tiene capacidad de proceso (como un terminal, una impresora o un escaner), los laterales no se rellenan:
Los nodos son los elementos donde se encuentran o ejecutan las instancias de los componentes en tiempo de ejecucin. Para mostrar que una instancia de un componente reside o se ejecuta en un nodo, es decir, que el nodo soporta una instancia de ese componente, se relaciona al nodo con la instancia mediante una dependencia estereotipada como support, tal y como se muestra a continuacin:
OrdContabilidad : PC
support : ContaGes
64
De forma alternativa, se puede mostrar la instancia dentro del nodo:
OrdContabilidad: PC : ContaGes
Los nodos estn relacionados entre s por asociaciones, que indican caminos de comunicacin. Una asociacin se representa grficamente como una lnea entre los nodos que comunica. Es comn estereotipar las asociaciones para indicar su tecnologa.
Un ejemplo de un diagrama de despliegue de un sistema sera:
ServBD : Servidor : SGBD
LAN
ServCentral : Servidor : ServGestor
USB
: Impresora
RDSI
RDSI
DelegacionJaen : PC : CliGestor
DelegacionToledo : PC : CliGestor
65
Hay veces que una instancia de un componente puede migrar de un nodo a otro. Para modelar esta migracin se representa una relacin entre dichas instancias con el estereotipo become. Por ejemplo:
Nodo1 :A : Cluster
become Nodo2 : Cluster
Aqu se representa la instancia : Cluster que en principio reside en Nodo1 y que en cierto momento pasa a residir en Nodo2. Ntese que la instancia : A reside todo el tiempo en Nodo1.
Rose slo permite un diagrama de despliegue. Por otro lado, Rose permite especificar, entre otras, el tipo de planificacin de tareas que se utiliza en cada nodo.
66
PROCESO UNIFICADO DE RATIONAL13.

Las tcnicas que proporciona UML son bastante independientes del proceso y pueden ser utilizadas en varias metodologas. Una de estas metodologas es el Proceso Unificado de Rational. Las caractersticas fundamentales de esta metodologa son las siguientes: Enfoque iterativo e incremental. Desarrollo orientado a objetos. Dirigida y controlada. Altamente automatizada.
Est basada en tres pilares: Personas. Proceso. Herramientas y mtodo.
Adems, integra dos perspectivas: Organizativa: relativa a aspectos financieros, estratgicos, comerciales y humanos. Tcnica: relativa a la calidad y mtodos ingenieriles y de diseo.
Las fases del ciclo de vida del Proceso Unificado de Desarrollo, desde el punto de vista organizativo, son las siguientes: Concepcin (inception): La idea feliz: especificacin de la visin del producto final y los casos de negocio. Elaboracin (elaboration): Planificacin de las actividades y recursos necesarios; especificacin de requisitos y diseo de la arquitectura. Construccin (construction): Construccin del producto y refinamiento hasta que el producto est preparado para su uso. Transicin (transition): Realizar la transicin de los clientes al producto generado, incluyendo formacin, soporte y mantenimiento hasta que los usuarios estn satisfechos.
Para ms informacin se recomienda consultar el documento A Rational Development Process de Philippe Kruchten, disponible en http://www.rational.com/products/whitepapers/334.jsp.
13
67
Desde un punto de vista tcnico, el ciclo de vida se divide en varias iteraciones (cuyo nmero y duracin depende de factores como la complejidad del software, experiencia del equipo y otros). Existe una coincidencia en el tiempo de los hitos desde el punto de vista organizativo con los hitos desde el punto de vista tcnico, como es lgico:
Cada iteracin consta de siete actividades: Planificacin. Anlisis. Arquitectura. Diseo. Implementacin. Integracin. Prueba/mantenimiento.
68
El nfasis en cada una de estas actividades depende de la fase e iteracin en la que nos encontremos, predominando al principio las actividades de anlisis, ms tarde las de diseo, luego las de construccin y por ltimo las de prueba y mantenimiento, como se puede ver en el siguiente grfico:
El Proceso Unificado de Rational no est guiado por documentos, sino por el producto en s. Los documentos tpicos a obtener pertenecen tanto al mbito organizativo como tcnico, incluyendo los modelos de casos de uso, clases, interaccin, etc., para lo cual se recomienda la utilizacin de herramientas CASE apropiadas.
69
GENERACIN DE CDIGO14. En esta seccin se dar una introduccin bsica sobre cmo generar y qu cdigo se genera a partir de los modelos realizados en Rose.
CMO GENERAR CDIGO .

En general, se deben seguir 6 pasos para la generacin de cdigo: 1. Comprobar el modelo. 2. Crear los componentes. 3. Asignar clases a componentes. 4. Establecer las propiedades para la generacin del cdigo. 5. Seleccionar una clase, componente o paquete. 6. Generar el cdigo.
1. Comprobar el modelo. Utilizando la opcin ToolsJCheck Model se comprueba que el modelo es consistente antes de generar cdigo. Aunque no es obligatorio, es muy recomendable realizarlo. Algunos errores comunes que detecta esta opcin son: Mensajes en los diagramas de secuencia o colaboracin no mapeados a operaciones. Objetos en los diagramas de secuencia o colaboracin no mapeados a clases. Accesos no permitidos entre clases causados por falta de visibilidad.
2. Crear los componentes. Se deben crear los componentes necesarios y sus relaciones (diagrama de componentes). Al crear un componente se puede especificar su estereotipo (p. ej., programa principal, cabecera, cuerpo, etc.) y el lenguaje en el que se generar (C++ en nuestro caso).
3. Asignar clases a componentes. Dependiendo del lenguaje utilizado, una clase debe estar asignada a un solo componente, o varias clases pueden estar asignadas a un mismo componente o, como en el caso de C++, una misma clase puede pertenecer a dos componentes distintos (.h y .cpp). Esta asignacin se hace arrastrando la clase desde el browser y soltndola en el componente o desde la ficha realizes de la especificacin del componente.
4. Establecer las propiedades para la generacin del cdigo. Estas propiedades controlarn el cdigo que ser generado. Rose proporciona unas propiedades por defecto que pueden ser cambiadas segn se requiera. Este cambio se puede hacer para todo el modelo desde ToolsJOptions (se recomienda hacer una copia con Clone y trabajar sobre ella) o para una clase en particular abriendo su especificacin. Entre las propiedades que se pueden establecer paralas clases estn si Rose generar operadores de igualdad (operador == y operador !=) o si generar el destructor y la
14
Se recomienda consultar los apuntes de C++ dejados en el servidor donde se tratan conceptos como constructores por copia, plantillas y la STL.
70
visibilidad del destructor en caso afirmativo. Cambiando el elemento seleccionado en el desplegable type de dicha opcin se puede acceder a otros elementos susceptibles de ser modificados para la generacin de cdigo, como por ejemplo, las relaciones.
5. Seleccionar una clase, componente o paquete. Se puede seleccionar una clase, un componente o un paquete para generar su cdigo. Tambin se pueden seleccionar mltiples elementos mediante la tecla [Ctrl].
6. Generar el cdigo. Se puede generar cdigo seleccionando ToolsJC++JCode Generation o desde el men contextual. Por defecto, 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 extensin .h o .cpp segn el estereotipo del componente.
QU SE GENERA .
Rose puede generar los siguientes elementos: Clases. Atributos (incluyendo visibilidad, tipo y valor por defecto). Declaraciones de operaciones (incluyendo parmetros, tipos de los parmetros y tipo devuelto). Relaciones (aunque slo algunos tipos). Componentes (ficheros).
Por ejemplo, sea la siguiente clase:

Coche
-cilindrada: double +potencia(): double
El cdigo generado para esta clase, dejando las opciones de generacin de cdigo por defecto, incluye: Definicin de la clase, potencia(). incluyendo la definicin del atributo cilindrada y la operacin
Definicin del constructor y constructor por copia y destructor. Tambin genera el esqueleto del cdigo necesario para su implementacin. Definicin de las operaciones de comparacin (igualdad y desigualdad) y la asignacin. Tambin genera el esqueleto del cdigo necesario para su implementacin. Definicin e implementacin de las operaciones (privadas) set y get del atributo cilindrada. Tngase en cuenta, sin embargo, que posiblemente la operacin set se tendr que retocar para evitar la introduccin de valores invlidos en el atributo, como en este caso sera intentar asignar un valor negativo a la cilindrada. Esqueleto para la implementacin de la operacin potencia().
71
Rose permite documentar la mayora de los elementos. Al generar cdigo, parte de esa documentacin aparecer como comentario en el cdigo. Por ejemplo, si documentamos la semntica de una operacin de una clase, esta documentacin aparecer como comentario encima de la definicin de la operacin al generar el cdigo.
Veamos ahora el esqueleto que crea Rose correspondiente a la implementacin de la operacin potencia:
//## Other Operations (implementation) double Coche::potencia () { //## begin Coche::potencia%3A13C55B00DC.body preserve=yes //## end Coche::potencia%3A13C55B00DC.body }
El programador debera generar el cdigo del cuerpo de dicho mtodo entre las lneas //## begin ... y //## end .... De esta forma, dicho cdigo ser preservado (preserve=yes) si se vuelve a generar el cdigo de esa clase. Al ser la programacin orientada a objetos un proceso fundamentalmente iterativo, si sobre el cdigo generado se aaden o suprimen directamente atributos u operaciones, conviene realizar ingeniera inversa para que los nuevos elementos sean introducidos al modelo de forma automtica (Rational Rose C++ Analyzer), ya que, si se olvida modelar los cambios en el diagrama de clases y se vuelve a generar cdigo, se perdern las operaciones y atributos introducidas manualmente. No se deben borrar los cdigos que genera Rose, ya que le son necesarios para si se desea volver a generar cdigo o se realiza ingeniera inversa. Rose tambin proporciona espacios para introducir nuevo cdigo, por ejemplo, para declaraciones pblicas:
// Additional Public Declarations //## begin Coche%3A13C52B03A2.public preserve=yes //## end Coche%3A13C52B03A2.public
Proporciona tambin secciones para realizar includes y otras declaraciones adicionales. El listado completo del cdigo generado para la anterior clase es el siguiente:
//## // // //## begin module%1.3%.codegen_version preserve=yes Read the documentation to learn more about C++ code generator versioning. end module%1.3%.codegen_version
//## begin module%3A13C58701AE.cm preserve=no // %X% %Q% %Z% %W% //## end module%3A13C58701AE.cm //## begin module%3A13C58701AE.cp preserve=no //## end module%3A13C58701AE.cp //## Module: Coche%3A13C58701AE; Main program //## Subsystem: <Top Level> //## Source file: C:\Archivos de programa\Rational\Rose\C++\source\Coche.cpp //## begin module%3A13C58701AE.additionalIncludes preserve=no //## end module%3A13C58701AE.additionalIncludes //## begin module%3A13C58701AE.includes preserve=yes //## end module%3A13C58701AE.includes //## begin module%3A13C58701AE.declarations preserve=no
72
//## end module%3A13C58701AE.declarations //## begin module%3A13C58701AE.additionalDeclarations preserve=yes //## end module%3A13C58701AE.additionalDeclarations //## begin Coche%3A13C52B03A2.preface preserve=yes //## end Coche%3A13C52B03A2.preface //## //## //## //## Class: Coche%3A13C52B03A2 Category: <Top Level> Persistence: Transient Cardinality/Multiplicity: n
class Coche { //## begin Coche%3A13C52B03A2.initialDeclarations preserve=yes //## end Coche%3A13C52B03A2.initialDeclarations public: //## Constructors (generated) Coche(); Coche(const Coche &right); //## Destructor (generated) ~Coche(); //## Assignment Operation (generated) Coche & operator=(const Coche &right); //## Equality Operations (generated) int operator==(const Coche &right) const; int operator!=(const Coche &right) const; //## Other Operations (specified) //## Operation: potencia%3A13C55B00DC double potencia (); // Additional Public Declarations //## begin Coche%3A13C52B03A2.public preserve=yes //## end Coche%3A13C52B03A2.public protected: // Additional Protected Declarations //## begin Coche%3A13C52B03A2.protected preserve=yes //## end Coche%3A13C52B03A2.protected private: //## Get and Set Operations for Class Attributes (generated) //## Attribute: cilindrada%3A13C53501EA const double get_cilindrada () const; void set_cilindrada (double value); // Additional Private Declarations //## begin Coche%3A13C52B03A2.private preserve=yes //## end Coche%3A13C52B03A2.private private: //## implementation // Data Members for Class Attributes //## begin Coche::cilindrada%3A13C53501EA.attr preserve=no double cilindrada; //## end Coche::cilindrada%3A13C53501EA.attr // Additional Implementation Declarations //## begin Coche%3A13C52B03A2.implementation preserve=yes //## end Coche%3A13C52B03A2.implementation }; //## begin Coche%3A13C52B03A2.postscript preserve=yes //## end Coche%3A13C52B03A2.postscript private: double {U}
73
// Class Coche //## Get and Set Operations for Class Attributes (inline) inline const double Coche::get_cilindrada () const { //## begin Coche::get_cilindrada%3A13C53501EA.get preserve=no return cilindrada; //## end Coche::get_cilindrada%3A13C53501EA.get } inline void Coche::set_cilindrada (double value) { //## begin Coche::set_cilindrada%3A13C53501EA.set preserve=no cilindrada = value; //## end Coche::set_cilindrada%3A13C53501EA.set } // Class Coche Coche::Coche() //## begin Coche::Coche%3A13C52B03A2_const.hasinit preserve=no //## end Coche::Coche%3A13C52B03A2_const.hasinit //## begin Coche::Coche%3A13C52B03A2_const.initialization preserve=yes //## end Coche::Coche%3A13C52B03A2_const.initialization { //## begin Coche::Coche%3A13C52B03A2_const.body preserve=yes //## end Coche::Coche%3A13C52B03A2_const.body } Coche::Coche(const Coche &right) //## begin Coche::Coche%3A13C52B03A2_copy.hasinit preserve=no //## end Coche::Coche%3A13C52B03A2_copy.hasinit //## begin Coche::Coche%3A13C52B03A2_copy.initialization preserve=yes //## end Coche::Coche%3A13C52B03A2_copy.initialization { //## begin Coche::Coche%3A13C52B03A2_copy.body preserve=yes //## end Coche::Coche%3A13C52B03A2_copy.body } Coche::~Coche() { //## begin Coche::~Coche%3A13C52B03A2_dest.body preserve=yes //## end Coche::~Coche%3A13C52B03A2_dest.body } Coche & Coche::operator=(const Coche &right) { //## begin Coche::operator=%3A13C52B03A2_assign.body preserve=yes //## end Coche::operator=%3A13C52B03A2_assign.body } int Coche::operator==(const Coche &right) const { //## begin Coche::operator==%3A13C52B03A2_eq.body preserve=yes //## end Coche::operator==%3A13C52B03A2_eq.body } int Coche::operator!=(const Coche &right) const { //## begin Coche::operator!=%3A13C52B03A2_neq.body preserve=yes //## end Coche::operator!=%3A13C52B03A2_neq.body }
//## Other Operations (implementation) double Coche::potencia () { //## begin Coche::potencia%3A13C55B00DC.body preserve=yes //## end Coche::potencia%3A13C55B00DC.body
74
} // Additional Declarations //## begin Coche%3A13C52B03A2.declarations preserve=yes //## end Coche%3A13C52B03A2.declarations //## begin module%3A13C58701AE.epilog preserve=yes //## end module%3A13C58701AE.epilog
CDIGO GENERADO EN LAS RELACIONES .

Una asociacin bidireccional uno a uno se implementa mediante un atributo puntero a la otra clase en cada una de las clases. Ej.:
ClaseA 1 class ClaseA { ... private: ClaseB *the_ClaseB; ... }; 1
ClaseB
class ClaseB { ... private: ClaseA *the_ClaseA; ... };
Si la asociacin es unidireccional, se define el puntero slo en la clase que tiene navegabilidad:

ClaseA 1 1 ClaseB
class ClaseA { ... private: ClaseB *the_ClaseB; ... };
class ClaseB { ... };
75
Si la asociacin es uno a un nmero determinado, por defecto se utilizar una matriz de punteros. Por ejemplo:
ClaseA 1 4
ClaseB
class ClaseA { ... private: ClaseB *the_ClaseB[4]; ... };
Si la asociacin es uno a muchos, se necesita algn tipo de contenedor para los punteros:
ClaseA 1 0..*
ClaseB
class ClaseA { ... private: UnboundedSetByReference<ClaseB> the_ClaseB; ... };
Ntese que UnboundedSetByReference<ClaseB> the_ClaseB significa que el atributo the_ClaseB ser un conjunto (sin nmero mximo de elementos) de valores por referencia a objetos de la la clase ClaseB (punteros). Este es el cdigo generado por defecto y no es compilable directamente por C++, a no ser que creemos un contenedor con dicho nombre y semntica. Sin embargo, se podra utilizar, por ejemplo, alguno de los contenedores proporcionados por la STL (Standard Template Library) de C++, por ejemplo, la lista (list15). Para ello, se debe cambiar en las opciones de compilacin (seleccionando el tipo Project), la definicin de UnorderedUnboundedByReferenceContainer que est por defecto a UnboundedSetByReference<$targetClass>> por list<*targetClass>. Adems, hay que aadir la librera list.h, utilizando por ejemplo la pestaa C++ de las especificaciones del componente (seccin AdditionalIncludes).
15
list es una clase parametrizada (plantilla).
76
El cdigo generado ahora, que puede ser compilado sin problemas, ser:
#include <list.h> ... class ClaseA { ... private: list<*ClaseB> the_ClaseB; ... };
Rose tambin tiene especificaciones propias para generar asociaciones en la que los elementos deben estar ordenados que podemos adaptar a nuestras libreras o a la STL para generar cdigo compilable.
Una relacin de agregacin genera un cdigo similar a una asociacin. Por ejemplo:
ClaseA 1 3
ClaseB
class ClaseA { ... private: ClaseB *the_ClaseB[3]; ... };
Sin embargo, en la relacin de composicin, la parte compuesta se tiene como un atributo de la clase (esto es, por valor):
ClaseA 1 class ClaseA { ... private: ClaseB the_ClaseB[3]; ... }; 3 class ClaseB { ... }; ClaseB
En el caso de relaciones de dependencia, Rose slo incluye en el cdigo los includes que sean necesarios.
Rose tambin genera cdigo para las relaciones de generalizacin. Por ejemplo:
77
Padre
Hija class Padre { ... } ; class Hija: public Padre ... };
CDIGO GENERADO PARA CLASES PARAMETRIZADAS .

Rose tambin genera cdigo para clases parametrizadas (plantillas). Por ejemplo:
T Plantilla
template <void T> class Plantilla { ... };
EJEMPLO.
Como ejemplo de generacin de cdigo, veremos lo que se genera en la siguiente asociacin:
ClaseA 1 0..n
ClaseB
ClaseC
78
class ClaseA { ... private: UnboundedSetByReference<ClaseC> the_ClaseC; ... }; class ClaseB { ... }; class ClaseC { ... private ClaseB *the_ClaseB; ... };
Obsrvese que se podra utilizar como contenedor una lista para hacer que el cdigo fuera compilable.
ROSE Y LA GENERACIN DE CDIGO .

Hay muchos aspectos que quedan fuera de la generacin de cdigo de Rose. Por ejemplo, una clase declarada en Rose como persistente no genera ningn cdigo que soporte dicha persistencia. Ser misin del programador hacer que dicha clase sea persistente.

Tema UML

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema UML

Cargado por

Copyright:

Formatos disponibles

Ingeniera del Software-UML

INGENIERA DEL SOFTWARE. UML.

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

VISIN GENERAL DE UML.

Ingeniera del Software-UML

El smbolo utilizado para una anotacin es el siguiente:

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

Veamos, para empezar, un diagrama de casos de uso para un cajero automtico:

Transferir Fondos Empleado Banca Ingresar Cambiar PIN

Realizar Pago Sistema de Crdito Ver Saldos

Ingeniera del Software-UML

Realizar Llamada Red Telefnica

Usuario Usar Agenda

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

Acciones del usuario 1. Identificacin como cliente.

Responsabilidades del sistema

Ingeniera del Software-UML

Llamada a Cobro Revertido

Relacin de generalizacin. Puede ser entre actores o entre casos de uso.

Ingeniera del Software-UML

Consultar Habitaciones Libres por Categora

Este tipo de relacin se utiliza poco y no se debe abusar de ella.

NORMAS PARA CREACIN DE UN DIAGRAMA DE CASOS DE USO .

Ingeniera del Software-UML

EJEMPLO DE UN DIAGRAMA DE CASOS DE USO .

Aportar Datos Cliente

Tomar Productos Aportar Forma Pago

El catlogo se enviar al servir el pedido.

Ingeniera del Software-UML

EJEMPLO DE LA DOCUMENTACIN DE UN CASO DE USO .

Ingeniera del Software-UML

Objeto annimo de la clase Persona.

Objeto de nombre luis perteneciente a la clase Persona.

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

IF (condicion= TRUE) THEN

Ingeniera del Software-UML

1: aceptarTarjeta( ) lector : Lector Tarjeta luis : Cliente

5: introducirPin(4567) 3: inicializarPantalla() 4: pedirPIN() 7: mostrarOperaciones()

6: verificarPIN(4567) : Pantalla Cajero cuentaDeLuis : Cuenta

Ingeniera del Software-UML

1: create() 2: mensajeA() 3: destroy() objeto1 objeto2 {transient}

Ingeniera del Software-UML

Abierto cancelar Cancelado fin periodo matrcula cancelar

Cerrado fin cuatrimestre Completado

Ingeniera del Software-UML

Ingeniera del Software-UML

Ingeniera del Software-UML

girar( grados ) / realizarGiro(grados)

Movimiento entry/ motorOn exit/ motorOff

Ingeniera del Software-UML

fin periodo matrcula Cerrado