INTRODUCCIN En esta parte de la exposicion nos concentraremos en detallar las nuevas caractersticas de los diagramas de mayor importancia, dentro

de UML 2.0, para el desarrollador comn. Haremos fuerte hincapi en los diagramas estructurales, en especial los diagramas de clases, y describiremos someramente los diagramas de actividades y de secuencia

Nuevas caractersticas 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 definicin 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.

Cambios estructurales Como puede observarse, el diseo 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 comn los diagramas de clases, las colaboraciones, los componentes y los paquetes? Algunas de las caractersticas en comn que podemos encontrar son: todos tienen elementos (por llamarlos de algn modo), que se asocian los unos a los otros mediante relaciones; el significado de las mismas puede depender del diagrama. Esta es una buena aproximacin. Ahora, si lo pensamos un poco ms, todos estos elementos pueden tener propiedades, estereotipos, restricciones, tagged values, etc. Si tuviramos que modelar esto, mediante un diagrama de clases, es dado a pensar que ste se vera como indica la Figura 2. Y, efectivamente, es as como se ve internamente en la superestructura de UML 2.0; slo 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 caractersticas muy interesantes, tiles a los objetivos del UML 2.0. Veamos

Diagramas de Composicin de Estructuras (Nuevo Diagrama) Los diagramas de composicin de estructuras (Composite Structures Diagram) fueron especficamente diseados para la representacin de patrones de diseo, y son una de las modificaciones de mayor impacto dentro de UML 2.0. Esta modificacin al UML hace que ahora todos los Clasificadores puedan tener una estructura compuesta. Mediante una composicin 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.

Diseando 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 slamente de teclado y monitor; tambin sabemos que, internamente, una PC cuenta con una placa de video, la cual se encarga de enviar informacin al exterior a travs de la interfaz de video. En la figura 3 mostramos el diseo, utilizando la nueva notacin 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 interaccin 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 crculo cerrado en el extremo) InterfazDeEntradaTeclado? e InterfazDeSalidaVideo?, y las interfaces requeridas (notadas con un semi-crculo abierto): InterfazDeEntradaTeclado? y InterfazDeSalidaVideo?. Conectores (Connectors): Los conectores especifican un Enlace (Link) entre Partes, que representa una instancia de asociacin. Este enlace representa la posibilidad de comunicacin entre una o ms 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.

La nueva notacin permite mostrar claramente que la Placa de Video y el Procesador forman parte de la PC. Esta relacin es an ms fuerte que la relacin de composicin, 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 asociacin con esa instancia de la PlacaDeVideo?.

Los diagramas de composicin de estructuras permiten, potencialmente, documentar arquitecturas de software de manera un poco ms 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 notacin Lollipop: Mediante esta notacin, las dependencias de un clasificador a una interfase pueden mostrarse mediante un semi-crculo abierto, que significa "interfaz requerida". Las interfaces implementadas por un clasificador se muestran con un crculo, 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 cmo se representara la notacin Lollipop mediante clases e interfaces (a la manera tradicional).

Diagramas de Despliegue Segn la especificacin de la OMG (UML 2.0 Superestructura, p. 8), se establece que: es un diagrama que representa la arquitectura de ejecucin de un sistema. ste, representa los artefactos del sistema como nodos, los cuales son conectados a travs de caminos de comunicacin para crear redes de sistemas de complejidad arbitraria. Al antiguo diagrama de despliegue, se le agregaron los siguientes elementos: Artefactos (Artifacts) Tpicamente los artefactos eran utilizados para representar la versin 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 coleccin de propiedades (properties) que especifican cmo un artefacto ser desplegado. A travs de ste, pueden especificarse, por ejemplo, el archivo web.xml, para desplegar una aplicacin web en java (cuya correspondencia en .NET sera el archivo web.config). Este ejemplo se ve en la figura 6.

Figura 6: Un Ejemplo de Especificacin de despliegue.

Diagramas de Componentes (Components Diagram) Segn la especificacin de la OMG (UML 2.0 Superestructura, p. 7), se afirma que: "es un diagrama que muestra la organizacin y dependencias entre componentes." Las modificaciones ms importantes realizadas al diagrama de componentes son: El cambio en la notacin de los componentes. Ahora se notan como muestra la figura 7: Con un estereotipo, en vez de los dos rectngulos pequeos cruzados Antigua notacin

Nueva notacin

Figura 7: Antigua y nueva notacin 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 representacin 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 Segn la especificacin 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 nocin 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 Extensin pueden ser especificadas adjuntando una nota a la relacin de extensin.

Figura 10: Casos de Uso y puntos de extensin

Los casos de Uso pueden ser representados como clases (notacin 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 Tambin 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 ms importantes, aunque muchos nuevos aspectos quedarn fuera. Los cambios realizados son tendientes a: Dar soporte en la definicin de procesos de negocio. Brindar una semntica similar al de las redes de petri. Permitir una mayor y ms flexible representacin de paralelismo. Si va a trabajar con diagramas de actividades, es conveniente repasarlos debido a que los cambios producidos, tanto semnticos como sintcticos, 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, parmetros y regiones e interrupciones.

Diagramas de Mquina de Estados Un diagrama de Mquina de Estados ilustra cmo 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 Mquinas de Estados, que representan y explican el movimiento y el comportamiento. Al igual que los diagramas de secuencia, las Mquinas de Estados permiten un mejor rehso, a travs del agregado de Puntos de Entrada y Puntos de Salida (Entry / Exit Points). Las mquinas de estados son ahora generalizables y soportan una vista centrada en la transicin. Las capacidades de generalizacin 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 mquinas de estados que heredan funcionalidad.

Diagramas de Interaccin Como dijimos anteriormente, el UML 2.0 se encuentra diseado de manera Orientada a Objetos, dentro de la nueva organizacin interna, y cuenta con los llamados Diagramas de Interacciones, que son una subcategora de los diagramas de comportamiento. Estos diagramas muestran la interaccin entre distintos clasificadores de un modelo desde distintos puntos de vista, es decir, haciendo foco en distintos aspectos de la interaccin. Esto hace que todos los diagramas de interaccin tengan ciertas caractersticas compartidas, como por ejemplo la capacidad de crear Diagramas de descripcin de interaccin y la utilizacin de fragmentos combinados. Dichos conceptos sern descriptos a continuacin utilizando los diagramas de secuencias.

Los Diagramas de secuencias Las modificaciones de los diagramas de secuencias tienden bsicamente a permitir la reutilizacin de los diagramas, agregando los elementos de tipos Fragmento Combinado. Fragmentos Combinados Un Fragmento combinado describe una interaccin reutilizable. En la figura 13 se muestra la sintaxis de ste, y en la figura 15 mostramos cmo pueden ser reutilizados en un fragmento combinado.

Figura 13: Sintaxis de un Fragmento Combinado

Operadores de Interaccin (Interaction Operators) Los operadores de interaccin contienen un cierto nmero de operandos y un identificador en el pentgono superior izquierdo del Operador (ver figura 14). Mediante los operadores, pueden definirse: Alternativas, Opciones, Quiebres de secuencia (breaks), ejecuciones paralelas, ciclos (loops) y varios ms.

Figura 14: Ejemplos de Operadores de Interaccin loop (ciclo) y alt (alternativa)

Diagramas de Revisin de interacciones (Nuevo Diagrama) Es un diagrama que muestra cmo interactan 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 interaccin 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 vlidos). Secuencia de seleccionar una operacin. 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 extraccin. Luego finalizar la operatoria.

Figura 15: Diagramas descripcin de interaccin, ejemplo cajero ATM.

Diagramas de Comunicacin (Ex diagramas de colaboracin) Quizs el cambio ms profundo en los diagramas de comunicacin es que anteriormente tenan el nombre de Diagramas de Colaboracin. Por ser las colaboraciones un diagrama de interaccin, al igual que los diagramas de secuencias, heredan la misma capacidad de soportar fragmentos combinados. Diagrama de Tiempos (Nuevo Diagrama) El propsito primario de los diagramas de tiempos (o temporizados) es mostrar los cambios en el estado, o la condicin, de una lnea 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 ms comn es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estmulos 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 cuestin de espacio, varios temas muy interesantes relativos a UML 2.0 quedaron sin abordar. Entre los temas ms destacados encontramos: Nuevas caractersticas en los diagramas: hay muchas nuevas caractersticas 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 mquinas 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 cmo realizar Diagramas de Arquitecturas utilizando UML 2.0. OCL: la utilizacin de OCL ser sin dudas una de las tcnicas de mayor crecimiento dentro de la Ingeniera 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 ingls: Meta Object Facility. Representa el diseo interno del UML con las estructuras necesarias para dar soporte a la automatizacin (MDA y MDD)

Conclusin 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 podrn faltar en la caja de herramientas de cualquier desarrollador en el corto plazo. Diagramas de estructura compuesta, as como las modificaciones en la mayora de los diagramas de comportamiento, sern de uso comn, 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 ms extensible. (2) Permitir la validacin y ejecucin de modelos creados mediante el UML.