Tabla de Contenidos

Tabla de contenidos

Introducción

En esta entrega nos concentraremos en detallar las nuevas características de los diagramas de mayor importancia, dentro de UML 2.0, para el desarrollador común. Haremos fuerte hincapié en los diagramas estructurales, en especial los diagramas de clases, y describiremos someramente los diagramas de actividades y de secuencia. Se recomienda primero, a modo de introducción, leer el artículo Introducción a lo nuevo de UML 2.0

Nuevas características de los diagramas UML 2.0

Haremos mayor hincapié en aquellos diagramas que figuran como "de mayor prioridad", enumerando de manera somera los cambios en los diagramas de menor prioridad.

La Superestructura de UML 2.0

La superestructura del UML es la definición formal de los elementos que componen el UML 2.0. Éste se encuentra organizado en paquetes, que definen los elementos internos del UML y de qué manera se relacionan. La figura 1 muestra esta estructura.

Figura 1: Organización Interna de la Superestructura

Cambios estructurales

Como puede observarse, el diseño interno del UML 2.0 se encuentra orientado a objetos. Para entender qué significado tiene esta idea, podemos hacernos preguntas tales como: ¿Qué tienen en común los diagramas de clases, las colaboraciones, los componentes y los paquetes? Algunas de las características en común que podemos encontrar son: todos tienen “elementos” (por llamarlos de algún modo), que se asocian los unos a los otros mediante “relaciones”; el significado de las mismas puede depender del diagrama. Esta es una buena aproximación. Ahora, si lo pensamos un poco más, todos estos “elementos” pueden tener propiedades, estereotipos, restricciones, tagged values, etc. Si tuviéramos que modelar esto, mediante un diagrama de clases, es dado a pensar que éste se vería como indica la Figura 2. Y, efectivamente, es así como se ve internamente en la superestructura de UML 2.0; sólo que, los “elementos”, se llaman en realidad Clasificadores. Esto quiere decir que, si tenemos una Clase llamada -por ejemplo- Astronauta, ésta es una instancia de un clasificador (en este caso, el clasificador clase), y no es la clase particular Astronauta un Clasificador.

Basicamente un Clasificador es a una Clase, lo que una Clase es a un Objeto.
Los clasificadores tienen otras características muy interesantes, útiles a los objetivos del UML 2.0. Veamos

Diagramas de Composición de Estructuras (Nuevo Diagrama)

Los diagramas de composición de estructuras (Composite Structures Diagram) fueron específicamente diseñados para la representación de patrones de diseño, y son una de las modificaciones de mayor impacto dentro de UML 2.0. Esta modificación al UML hace que ahora todos los Clasificadores puedan tener una estructura compuesta. Mediante una composición de estructuras, el comportamiento de las instancias de otros Clasificadores contenidos (estructura interna) en un Clasificador determinado, puede especificarse como Colaboraciones. Los conceptos principales para describir la estructura interna son: Partes, Puertos y Conectores.

Diseñando la Estructura Interna de “Mi PC” Mediante un Diagrama de Clases

Para describir cada uno de estos nuevos elementos tomaremos un ejemplo: Supongamos que deseamos modelar el concepto “PC simplificada”. Esta PC consta sólamente de teclado y monitor; también sabemos que, internamente, una PC cuenta con una placa de video, la cual se encarga de enviar información al exterior a través de la interfaz de video. En la figura 3 mostramos el diseño, utilizando la nueva notación de UML 2.0. La misma incluye los siguientes nuevos artefactos:

  • Partes (parts): Una parte es una propiedad contenida en un clasificador. Una parte vive y muere siguiendo el mismo ciclo de vida que el objeto que lo contiene. En nuestro ejemplo, la placa de Video es parte de la PC. Hay que tener en cuenta que esto implica que la placa de video no puede cambiarse, debido a que respeta el mismo ciclo de vida que la PC.
  • Puertos (ports): Un puerto describe un punto de interacción para un clasificador. Los puertos son conocidos, esto significa que se le pueden enviar mensajes. Un puerto puede tener una interfaz requerida (necesarias para la clase) o una interfaz provista (que brinda la clase). En nuestro ejemplo tenemos los puertos: inPCPort, outPCPort, outTecladoPort y InSalidaDeVideoPort?; las interfaces provistas (notadas con un círculo cerrado en el extremo) InterfazDeEntradaTeclado? e InterfazDeSalidaVideo?, y las interfaces requeridas (notadas con un semi-círculo abierto): InterfazDeEntradaTeclado? y InterfazDeSalidaVideo?.
  • Conectores (Connectors): Los conectores especifican un Enlace (Link) entre Partes, que representa una instancia de asociación. Este enlace representa la posibilidad de comunicación entre una o más partes. En nuestro ejemplo la placa de video se comunica con el procesador.

Si bien estas modificaciones afectan a todos los Clasificadores, tienen mayor impacto y utilidad en Clases, Componentes y Colaboraciones.

Figura 3: Diagramas de clase compuesto para el ejemplo “mi PC”

La nueva notación permite mostrar claramente que la Placa de Video y el Procesador forman parte de la PC. Esta relación es aún más fuerte que la relación de composición, debido a que una placa de video no puede ser utilizada por otro objeto. Formalmente hablando, ninguna otra instancia en el dominio puede tener una asociación con esa instancia de la PlacaDeVideo?.
Los diagramas de composición de estructuras permiten, potencialmente, documentar arquitecturas de software  de manera un poco más clara que en versiones anteriores del UML 2.0.

Cambios Particulares en los Diagramas Estructurales

Ya hemos enumerado cambios que afectan de manera transversal a varios de los diagramas del UML 2.0. Ahora nos enfocaremos en los cambios particulares de algunos de los diagramas de UML.

Diagrama de Clases

Uno de los cambios que seguramente será muy utilizado es la notación “Lollipop”: Mediante esta notación, las dependencias de un clasificador a una interfase pueden mostrarse mediante un semi-círculo abierto, que significa "interfaz requerida". Las interfaces implementadas por un clasificador se muestran con un círculo, cuyo significado es "interfaz provista". Ejemplos de interfaces requeridas y provistas pueden verse en la figura 3 de estructuras compuestas. En La figura 4 mostramos un ejemplo detallando cómo se representaría la notación Lollipop mediante clases e interfaces (a la manera tradicional).

Figura 4: Ejemplo de Interfaz Provista e Interfaz Requerida

Diagramas de Despliegue

Según la especificación de la OMG (UML 2.0 Superestructura, p. 8), se establece que: “es un diagrama que representa la arquitectura de ejecución de un sistema. Éste, representa los artefactos del sistema como nodos, los cuales son conectados a través de caminos de comunicación para crear redes de sistemas de complejidad arbitraria.” Al antiguo diagrama de despliegue, se le agregaron los siguientes elementos:

Artefactos (Artifacts)

Típicamente los artefactos eran utilizados para representar la versión compilada de un componente; el UML 2.0 permite representar cualquier elemento empaquetable (por ejemplo un jar). Los artefactos pueden tener atributos, como se muestra en la figura 5.

Figura 5: Un artefacto con atributos

Especificaciones de Despliegue (Deployment Specifications)

Las especificaciones de despliegue son una colección de propiedades (properties) que especifican cómo un artefacto será desplegado. A través de éste, pueden especificarse, por ejemplo, el archivo web.xml, para desplegar una aplicación web en java (cuya correspondencia en .NET sería el archivo web.config). Este ejemplo se ve en la figura 6.

Figura 6: Un Ejemplo de Especificación de despliegue.

Diagramas de Componentes (Components Diagram)

Según la especificación de la OMG (UML 2.0 Superestructura, p. 7), se afirma que: "es un diagrama que muestra la organización y dependencias entre componentes." Las modificaciones más importantes realizadas al diagrama de componentes son: El cambio en la notación de los componentes. Ahora se notan como muestra la figura 7: Con un estereotipo, en vez de los dos rectángulos pequeños cruzados

Antigua notación

Nueva notación

Figura 7: Antigua y nueva notación de componentes respectivamente

Otro cambio importante, dentro de los diagramas de componentes, son los conectores de ensamblado (assembly connectors) que se utilizan para representar las interfaces provistas y requeridas por un componente. La representación del mismo puede verse en la figura 8.

Figura 8: Componente con interfaces provistas e Interfaces requeridas

Cambios en los Diagramas de Comportamiento

Diagramas de Caso de Uso

Según la especificación de la OMG (UML 2.0 Superestructura, p. 17), los diagramas de casos de uso son diagramas que muestran las relaciones entre actores y el sistema.

Estructuras Compuestas

Ahora que ya conocemos la noción de clasificador, podemos notar que un Caso de Uso puede ser parte de (estar compuesto en) cualquier clasificador (no solamente packages). Por ejemplo, un caso de uso puede ser parte de una clase. Ver Figura 9.

Figura 9: Caso de uso como parte de un clasificador.

Extensiones

Las condiciones para una Extensión pueden ser especificadas adjuntando una nota a la relación de extensión.

Figura 10: Casos de Uso y puntos de extensión

Los casos de Uso pueden ser representados como clases (notación de clasificador) y se nota con una elipse en la parte superior derecha (Estereotipo)

Figura 11: Caso de Uso representado como una Clase con su estereotipo

También utilizando el concepto de estereotipos (stereotypes), los actores pueden ser representados mediante distintos íconos, tales como computadoras o relojes.

Los Diagramas de Actividades

Muchos cambios fueron realizados en los diagramas de actividad. Mostraremos solamente los más importantes, aunque muchos nuevos aspectos quedarán fuera. Los cambios realizados son tendientes a:

  • Dar soporte en la definición de procesos de negocio.
  • Brindar una semántica similar al de las redes de petri.
  • Permitir una mayor y más flexible representación de paralelismo.

Si va a trabajar con diagramas de actividades, es conveniente repasarlos debido a que los cambios producidos, tanto semánticos como sintácticos, son muy profundos. En la figura 12 puede verse un ejemplo de un diagrama de actividades con alguno de los nuevos elementos que lo componen.

Figura 12: Ejemplo Diagrama de Actividades

En el ejemplo podemos ver alguno de los nuevos elementos tales como: entradas, parámetros y regiones e interrupciones.

Diagramas de Máquina de Estados

Un diagrama de Máquina de Estados ilustra cómo un elemento, muchas veces una clase, se puede mover entre estados que clasifican su comportamiento, de acuerdo con disparadores de transiciones, guardias de restricciones y otros aspectos de los diagramas de Máquinas de Estados, que representan y explican el movimiento y el comportamiento. Al igual que los diagramas de secuencia, las Máquinas de Estados permiten un mejor rehúso, a través del agregado de Puntos de Entrada y Puntos de Salida (Entry / Exit Points). Las máquinas de estados son ahora generalizables y soportan una vista centrada en la transición. Las capacidades de generalización incluyen: agregar estados y transiciones, extender estados, reemplazar transiciones, reemplazar maquinas compuestas, etc. Lo que permite que, por ejemplo, dada una clase que hereda de otra, especificar ambas clases mediante máquinas de estados que heredan funcionalidad.

Diagramas de Interacción

Como dijimos anteriormente, el UML 2.0 se encuentra diseñado de manera Orientada a Objetos, dentro de la nueva organización interna, y cuenta con los llamados “Diagramas de Interacciones”, que son una subcategoría de los diagramas de comportamiento. Estos diagramas muestran la interacción entre distintos clasificadores de un modelo desde distintos puntos de vista, es decir, haciendo foco en distintos aspectos de la interacción. Esto hace que todos los diagramas de interacción tengan ciertas características compartidas, como por ejemplo la capacidad de crear Diagramas de descripción de interacción y la utilización de fragmentos combinados. Dichos conceptos serán descriptos a continuación utilizando los diagramas de secuencias.

Los Diagramas de secuencias

Las modificaciones de los diagramas de secuencias tienden básicamente a permitir la reutilización de los diagramas, agregando los elementos de tipos Fragmento Combinado.

Fragmentos Combinados

Un Fragmento combinado describe una interacción reutilizable. En la figura 13 se muestra la sintaxis de éste, y en la figura 15 mostramos cómo pueden ser reutilizados en un fragmento combinado.

Figura 13: Sintaxis de un Fragmento Combinado

Operadores de Interacción (Interaction Operators)

Los operadores de interacción contienen un cierto número de operandos y un identificador en el pentágono superior izquierdo del Operador (ver figura 14). Mediante los operadores, pueden definirse: Alternativas, Opciones, Quiebres de secuencia (breaks), ejecuciones paralelas, ciclos (loops) y varios más.

Figura 14: Ejemplos de Operadores de Interacción loop (ciclo) y alt (alternativa)

Diagramas de Revisión de interacciones (Nuevo Diagrama)

Es un diagrama que muestra cómo interactúan varios diagramas de interacciones. Este tipo de diagramas es muy útil para mostrar de qué manera distintos escenarios se combinan. En el ejemplo de la figura 15, se muestra la interacción de un cliente con un cajero ATM, separado en cuatro fragmentos:

  • Secuencia de login: la cual pedirá un usuario y una clave a un cliente. (la secuencia supone que la clave y usuario ingresados son válidos).
  • Secuencia de seleccionar una operación. Las operaciones permitidas por este cajero son cancelar o extraer dinero.
  • Si cancela, se ejecutará la secuencia de deslogueo del cliente. Luego finalizará la operatoria.

Si seleccionar 'extraer dinero' se ejecutará la secuencia de extracción. Luego finalizará la operatoria.

Figura 15: Diagramas descripción de interacción, ejemplo cajero ATM.

Diagramas de Comunicación (Ex diagramas de colaboración)

Quizás el cambio más profundo en los diagramas de comunicación es que anteriormente tenían el nombre de “Diagramas de Colaboración”. Por ser las colaboraciones un diagrama de interacción, al igual que los diagramas de secuencias, heredan la misma capacidad de soportar fragmentos combinados.

Diagrama de Tiempos (Nuevo Diagrama)

El propósito primario de los diagramas de tiempos (o temporizados) es mostrar los cambios en el estado, o la condición, de una línea de vida de una instancia (de un Clasificador o un Rol de un clasificador), a lo largo del tiempo y de manera lineal. El uso más común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos aceptados. Un diagrama de tiempos se ve tal y como lo muestra la figura 16. No resulta trivial leer un diagrama de tiempos; si no se lo conoce, puede resultar poco intuitivo.

Figura 16: Diagrama de Tiempos

Lo que quedó afuera

Por una cuestión de espacio, varios temas muy interesantes relativos a UML 2.0 quedaron sin abordar. Entre los temas más destacados encontramos:

  • Nuevas características en los diagramas: hay muchas nuevas características en UML 2.0 que hemos pasado por alto; algunos ejemplos son: templates, restricciones para las relaciones, varios nuevos elementos en los diagramas de secuencias y máquinas de estados, diagramas de paquetes, etc.
  • MDD (Model Driven Development) y MDA (Model Driven Architecture)
  • Perfiles: un tema bastante relevante y que quedó fuera, es el de Perfiles (Profiles), porque explicarlo debidamente requiere un espacio considerado.
  • Diagramas de Arquitectura: analizar cómo realizar Diagramas de Arquitecturas utilizando UML 2.0.
  • OCL: la utilización de OCL será sin dudas una de las técnicas de mayor crecimiento dentro de la Ingeniería de Software. Así como hubo un tiempo en que los casos de uso no eran siquiera conocidos, y hoy son moneda de uso corriente, con OCL es dado a pensar que pasará algo similar, debido, en gran parte, al poder de expresividad que brinda sobre los modelos.
  • MOF, del inglés: Meta Object Facility. Representa el diseño interno del UML con las estructuras necesarias para dar soporte a la automatización (MDA y MDD)

Conclusión

En esta entrega hemos analizado los cambios en el UML 2.0 desde un punto de vista bastante amplio, teniendo en cuenta principalmente aquellos cambios de mayor impacto para el desarrollador promedio. Sin duda, muchos de los conceptos aquí vistos no podrán faltar en la caja de herramientas de cualquier desarrollador en el corto plazo. Diagramas de estructura compuesta, así como las modificaciones en la mayoría de los diagramas de comportamiento, serán de uso común, debido al gran poder de expresividad que éstos brindan. Sin embargo, sin perder de vista el trabajo cotidiano, es importante recordar, siempre que hablemos del UML 2.0, las dos premisas que rigen su estructura: (1) Hacer el lenguaje de modelado mucho más extensible. (2) Permitir la validación y ejecución de modelos creados mediante el UML.

Ejercicio

Puede ser un ejercicio interesante, modelar este mismo ejemplo utilizando la versión anterior del UML (1.5)y analizando cuáles son sus implicancias.

Recomendaciónes

Si piensa trabajar con UML 2.0, nuestra recomendación es capacitarse adecuadamente sobre el diagrama que está por modelar y utilizar una herramienta que cumpla con el nivel de conformidad más alto posible; esto le permitirá sacar un mayor provecho del libro.

Nuestros recomendados

Excelente referencia para el trabajo diario. La introducción teórica es un poco superficial debido a que el foco del libro es la superestructura. El libro puede ser útil tanto a expertos UML como para quienes recién se inician.

La herramienta recomendada.


Lic. Valerio Adrián Anacleto

- Deploying ideas Epidata Consulting Maipú 521 1er piso Of. A Ofi: 5031 0060 / 61 www.epidataconsulting.com