Documentos de Académico
Documentos de Profesional
Documentos de Cultura
0
Introduccin
Al 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
cuenta con una sintaxis y una semntica. Por lo tanto, al modelar un concepto
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.
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.
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.
OCL
OCL 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.
Infraestructura
En 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.
Superestructura
La 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.
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.
Organizacin de la superestructura
El 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.
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
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 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.
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.
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. Bsicamente 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
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
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.
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).
10
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.
11
Nueva notacin
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.
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.
Extensiones
Las condiciones para una Extensin pueden ser especificadas adjuntando una nota a la relacin de extensin.
13
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.
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
En el ejemplo podemos ver alguno de los nuevos elementos tales como: entradas, parmetros y regiones e interrupciones.
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.
15
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.
16
finalizar la operatoria. Si seleccionar 'extraer dinero' se ejecutar la secuencia de extraccin. Luego finalizar la operatoria.
17
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
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)
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.
18