LO NUEVO EN UML 2.0IntroduccinAl momento de desarrollar el nuevo estndar 2.0 de UML, la OMG se plante, entre otros, dos objetivos que podramos considerar principales, debido a la influencia de stos en la nueva versin del estndar: 1. Hacer el lenguaje de modelado ms extensible. 2. Permitir la validacin y ejecucin de modelos. En el presente artculo, se muestran los principales cambios en UML 2.0, cmo stos influyen en los objetivos planteados anteriormente, la nueva estructura de UML 2.0, los nuevos diagramas y los cambios ms importantes en los diagramas preexistentes. La evolucin de la programacin hacia la ejecucin y validacin automtica de modelos

Conociendo UML 2.0En este artculo nos introduciremos al mundo del diseo de aplicaciones de software, a travs de su puerta ms novedosa: UML 2.0. ste es el comienzo de una serie de artculos en los que iremos, poco a poco, conociendo el UML 2.0 en detalle. En el presente trabajo, nos enfocaremos en el lenguaje propiamente dicho; su historia, estructura, cambios y objetivos de mayor influencia, en esta nueva y radical versin.

Objetivos del UML 2.0Al momento de desarrollar el nuevo estndar 2.0 del UML, la OMG se propuso, entre otros, dos objetivos que podramos considerar principales debido a la influencia de stos en la versin final del estndar. Estos objetivos son: 1. Hacer el lenguaje de modelado mucho ms extensible de lo que era. 2. Permitir la validacin y ejecucin de modelos creados mediante el UML. UML 2.0 se desarrolla sobre la base de estos dos objetivos, causando un quiebre respecto a versiones anteriores. Para entender la razn del quiebre y el por qu de esta evolucin tan marcada, nos profundizaremos un poco en la historia y definicin misma del UML.

El UML y la Industria del SoftwareEl UML se ha vuelto el estndar de facto (impuesto por la industria y los usuarios) para el modelado de aplicaciones de software. En los ltimos aos, su popularidad trascendi al desarrollo de software y, en la actualidad, el UML es utilizado para modelar muchos otros dominios, como por ejemplo el modelado de procesos de negocios.

Conceptos bsicos sobre UMLUML son las siglas para Unified Modeling Language, que en castellano quiere decir: Lenguaje de Modelado Unificado. Para comprender qu es el UML, basta con analizar cada una de las palabras que lo componen, por separado. Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que ste

cuenta con una sintaxis y una semntica. Por lo tanto, al modelar un concepto

1

en UML, existen reglas sobre cmo deben agruparse los elementos del lenguaje y el significado de esta agrupacin. Modelado: el UML es visual. Mediante su sintaxis se modelan distintos

aspectos del mundo real, que permiten una mejor interpretacin y entendimiento de ste. Unificado: unifica varias tcnicas de modelado en una nica.

Ya que el UML proviene de tcnicas orientadas a objetos, se crea con la fuerte intencin de que este permita un correcto modelado orientado a objetos.

(Muy) Breve Resea HistricaLas races del UML provienen de tres mtodos distintos. El mtodo de Grady Booch, la Tcnica de Modelado de Objetos de James Rumbaugh y Objetory, de Ivar Jacobson. Conocidas estas tres personalidades como los tres amigos. En 1994 Booch, Rumbaugh y Jacobson dieron forma a la primera versin del UML y en 1997 fue aceptado por la OMG, fecha en la que fue lanzada la versin v1.1 del UML. Desde entonces, UML atraves varias revisiones y refinamientos hasta llegar a la versin actual: UML 2.0.

Qu es la OMG?La OMG (Object Management Group) es una asociacin sin fines de lucro formada por grandes corporaciones, muchas de ellas de la industria del software, como por ejemplo: IBM, Apple Computer, Sun Microsystems Inc y Hewlett-Packard?. Esta asociacin se encarga de la definicin y mantenimiento de estndares para aplicaciones de la industria de la computacin. Otro de los estndares definidos por la OMG, adems del UML, es CORBA, el cual permite interoperabilidad multiplataforma a nivel de objetos de negocio. Podemos encontrar http://www.omg.org/ ms informacin sobre la OMG en su sitio oficial:

Es importante destacar que, a lo largo de estas constantes revisiones, muchas tcnicas existentes fueron agregadas a UML. Esta constante ampliacin del lenguaje hizo que el UML fuera perdiendo identidad, convirtindose en una agrupacin de distintas tcnicas de modelado, sin demasiada cohesin entre ellas. Esto transform al UML en un lenguaje sin identidad y, en muchos puntos, ambiguo o falto de coherencia conceptual.

El Nuevo Enfoque del UML 2.0En las versiones previas del UML, se haca un fuerte hincapi en que UML no era un lenguaje de programacin. Un modelo creado mediante UML no poda ejecutarse. En el UML 2.0, esta asuncin cambi de manera drstica y se modific el lenguaje, de manera tal que permitiera capturar mucho ms comportamiento (Behavior). De esta forma, se permiti la creacin de herramientas que soporten la automatizacin y generacin de cdigo ejecutable, a partir de modelos UML.

Estndares que conforman el UML Superestructura: Es la especificacin que usamos todos los das. Aqu se

encuentran todos los diagramas que la mayora de los desarrolladores conocen.

2

Infraestructura: Conceptos de bajo nivel. Meta-Modelo da soporte a la

superestructura, entre otras. OCL: Lenguaje de restriccin. De utilidad para especificar conceptos

ambiguos sobre los distintos elementos del diagrama. XMI / Intercambio de diagramas: Permite compartir diagramas entre

diferentes herramientas de modelado UML.

Reestructuracin del LenguajePara lograr los objetivos enunciados, varios aspectos del lenguaje fueron reestructurados y/o modificados. La especificacin se separ en cuatro especificaciones (paquetes) bien definidas, tal como se muestra en la Figura 1. Es interesante destacar que el UML 2.0 puede definirse a s mismo. Es decir, su estructura y organizacin es modelable utilizando el propio UML 2.0; de esta manera, se da un ejemplo de utilizacin del UML en un dominio distinto al del desarrollo de software. En este caso, cada paquete del diagrama representa cada una de las cuatro especificaciones que componen el lenguaje.

Figura 1: Especificaciones principales del UML 2.0

Veamos a continuacin, un poco ms en detalle cada una de las principales especificaciones que componen UML 2.0. No nos explayaremos demasiado, debido a que en futuras ediciones habr oportunidad de profundizar en cada una de ellas.

OCLOCL son siglas en ingls que significan: Object Constraint Language y que en castellano se traducen como: Lenguaje de Restricciones de Objetos. El OCL define un lenguaje simple, para escribir restricciones y expresiones sobre elementos de un modelo. El OCL suele ser til cuando se est especificando un dominio particular mediante el UML y es necesario restringir los valores permitidos para los objetos del dominio. El OCL brinda la posibilidad definir en los elementos de un diagrama, entre otros: invariantes, precondiciones, poscondiciones y restricciones. El OCL fue incorporado al UML en la versin 1.1. El OCL fue originalmente especificado por IBM y es un ejemplo ms de las muchas herramientas agregadas al UML.

3

Especificacin para el Intercambio de DiagramasLa especificacin para el intercambio de diagramas fue escrita para facilitar una manera de compartir modelos, realizados mediante UML, entre diferentes herramientas de modelado. En versiones anteriores del UML, se utilizaba un Schema XML para capturar los elementos utilizados en el diagrama; pero este Schema no deca nada acerca de la manera en que el modelo deba graficarse. Para solucionar este problema, la nueva especificacin para el intercambio de diagramas fue desarrollada utilizando un nuevo Schema XML, que permite construir una representacin SVG (Scalable Vector Graphics). Esta especificacin es denominada con las siglas XMI, que en ingls significa: XML Metadata Interchange; y en castellano se traduce como: XML de Intercambio de Metadata (datos que representan datos). Tpicamente esta especificacin es solamente utilizada por quienes desarrollan herramientas de modelado UML.

InfraestructuraEn la Infraestructura del UML se definen los conceptos centrales y de ms bajo nivel. La Infraestructura es un meta-modelo (un modelo de modelos) y mediante la misma se modela el resto del UML. Generalmente, la infraestructura no es utilizada por usuarios finales del UML; pero provee la piedra fundamental sobre la cual la Superestructura es definida. Esta ltima s es la utilizada por el comn de los usuarios. La Infraestructura brinda tambin varios mecanismos de extensin, que hacen del UML un lenguaje configurable. Para los usuarios normales del UML basta con saber si la infraestructura existe y cules son sus objetivos.

SuperestructuraLa superestructura del UML es la definicin formal de los elementos del UML. Esta definicin sola contiene ms de 640 pginas. La superestructura es tpicamente utilizada por los desarrolladores de aplicacin. Es aquella sobre la que hablan los libros y la que la mayora conoce de versiones anteriores del UML.

La Superestructura del UMLEs en la Superestructura donde encontramos los cambios que ms afectan en el da a da a quienes trabajan como desarrolladores de aplicaciones de negocios, es decir, profesionales que, en general, deben interpretar o crear modelos que especifiquen el dominio de tales aplicaciones. Es aqu dnde se definen los diagramas y los elementos que los componen. La Superestructura se encuentra dividida en niveles. Estos niveles se conocen como: Bsico (L1): Contiene los elementos bsicos del UML 2.0, entre ellos:

Diagramas de clases, Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de Uso Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado,

Perfiles, Diagramas de Componentes y Diagramas de despliegue. Completo (L3): Representa la especificacin del UML 2.0 completa, como por

ejemplo: las Acciones, Caractersticas avanzadas y PowerTypes? entre otros. Es importante destacar que basta con que una herramienta implemente el nivel de conformidad Bsico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad de caractersticas (features) bastante amplia entre dos herramientas distintas, aunque stas sean UML 2.0 compatibles.

4

Organizacin de la superestructuraEl bloque de construccin bsico del UML es un diagrama. La estructura de los diagramas UML est reflejado por el diagrama de la figura 2, de acuerdo con la especificacin del UML 2.0 del Object Development Group. Los detalles sobre estos diagramas especficos se organizan de acuerdo a esta estructura taxonmica, que da la perspectiva a los diagramas y a sus interrelaciones. Los diagramas de interaccin comparten propiedades y atributos similares, como lo hacen los diagramas estructurales y de comportamiento. En color azul se distinguen aquellos diagramas que aparecen en esta versin del UML.

Figura 2: Estructura taxonmica del UML 2.0

Diagramas de Estructura y Diagramas de comportamientoLos diagramas estructurales representan elementos y as componen un sistema o una funcin. Estos diagramas pueden reflejar las relaciones estticas de una estructura, como lo hacen los diagramas de clases o de paquetes, o arquitecturas en tiempo de ejecucin, tales como diagramas de Objetos o de Estructura de Composicin. Los diagramas de comportamiento representan las caractersticas de comportamiento de un sistema o proceso de negocios y, a su vez, incluyen a los diagramas de: actividades, casos de uso, maquinas de estados, tiempos, secuencias, repaso de interacciones y comunicaciones.

Breve descripcin sobre los diagramasEn beneficio de quienes quieran seguir investigando dentro del mundo UML, en el siguiente cuadro se muestra la importancia que tiene, para un desarrollador, conocer cada una de las nuevas caractersticas del UML 2.0. Sobre esta premisa, ampliaremos la explicacin de cada diagrama en las prximas ediciones, dando ms importancia a los diagramas que figuran con mayor prioridad en el cuadro. Diagrama Diagrama de Clases Descripcin Prioridad

Muestra una coleccin de elementos de modelado Alta declarativo (estticos), tales como clases, tipos y sus contenidos y relaciones. Representa los componentes que componen una Media aplicacin, sistema o empresa. Los componentes, sus relaciones, interacciones y sus interfaces pblicas.

Diagrama de Componentes

5

Diagrama de Estructura de Composicin Diagrama de Despliegue Fsico

Representa la estructura interna de un clasificador Baja (tal como una clase, un componente o un caso de uso), incluyendo los puntos de interaccin de clasificador con otras partes del sistema. Un diagrama de despliegue fsico muestra cmo y Media dnde se desplegar el sistema. Las mquinas fsicas y los procesadores se representan como nodos y la construccin interna puede ser representada por nodos o artefactos embebidos. Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicacin es guiada por el uso de las especificaciones de despliegue. Un diagrama que presenta los objetos y sus Baja relaciones en un punto del tiempo. Un diagrama de objetos se puede considerar como un caso especial de un diagrama de clases o un diagrama de comunicaciones.

Diagrama de Objetos

Diagrama de Paquetes Un diagrama que presenta cmo se organizan los Baja elementos de modelado en paquetes y las dependencias entre ellos, incluyendo importaciones y extensiones de paquetes. Diagrama de Actividades Representa los procesos de negocios de alto nivel, Alta incluidos el flujo de datos. Tambin puede utilizarse para modelar lgica compleja y/o paralela dentro de un sistema. Es un diagrama que enfoca la interaccin entre Baja lneas de vida, donde es central la arquitectura de la estructura interna y cmo ella se corresponde con el pasaje de mensajes. La secuencia de los mensajes se da a travs de un esquema de numerado de la secuencia. Los Diagramas de Revisin de la Interaccin Baja enfocan la revisin del flujo de control, donde los nodos son Interacciones u Ocurrencias de Interacciones. Las Lneas de Vida los Mensajes no aparecen en este nivel de revisin Un diagrama que representa una interaccin, Alta poniendo el foco en la secuencia de los mensajes que se intercambian, junto con sus correspondientes ocurrencias de eventos en las Lneas de Vida.

Diagrama de Comunicaciones (anteriormente: Diagrama de colaboraciones) Diagrama de Revisin de la Interaccin

Diagrama de Secuencias

Diagrama de Mquinas Un diagrama de Mquina de Estados ilustra cmo Media de Estado 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.

6

Diagrama de Tiempos

El propsito primario del diagrama de tiempos es Baja mostrar los cambios en el estado o la condicin de una lnea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo 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. Los eventos que se reciben se anotan, a medida que muestran cundo se desea mostrar el evento que causa el cambio en la condicin o en el estado.

Diagrama de Casos de Un diagrama que muestra las relaciones entre los Media Uso actores y el sujeto (sistema), y los casos de uso.

7

NUEVAS CARACTERSTICAS DE LOS DIAGRAMAS UML 2.0Haremos 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.0La 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.

Figura 1: Organizacin Interna de la Superestructura

Cambios estructuralesComo 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. Bsicamente un Clasificador es a una Clase, lo que una Clase es a un Objeto.

8

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 ClasesPara 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

9

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.

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

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 EstructuralesYa 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 ClasesUno 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).

10

Figura 4: Ejemplo de Interfaz Provista e Interfaz Requerida

Diagramas de DespliegueSegn 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.

11

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

12

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 UsoSegn 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 CompuestasAhora 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.

ExtensionesLas condiciones para una Extensin pueden ser especificadas adjuntando una nota a la relacin de extensin.

13

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 ActividadesMuchos 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.

14

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 EstadosUn 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 InteraccinComo 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.

15

Los Diagramas de secuenciasLas modificaciones de los diagramas de secuencias tienden bsicamente a permitir la reutilizacin de los diagramas, agregando los elementos de tipos Fragmento Combinado.

Fragmentos CombinadosUn 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)

16

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.

17

Figura 16: Diagrama de Tiempos

Lo que qued afueraPor 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 Arquitecturas utilizando UML 2.0.

cmo

realizar

Diagramas

de

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)

ConclusinEn 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.

18