OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje de Modelado Unificado (OMG UML) 2.0. Se realiza un análisis de las principales diferencias que existen entre OMG UML 1.x y 2.0 y se exponen algunos de los diagramas de OMG UML 2.0 a través de un caso ejemplo relacionado con los servicios de una biblioteca. Keywords: Modelado, Software, Diseño, UML Historia del Surgimiento Impulsados por la necesidad de métodos más ágiles de desarrollo de software, UML 1.x evoluciona en UML 2.0, siendo dicha evolución influenciada por el Desarrollo Conducido por Modelo (MDD Model Driven Development) y el Modelamiento Conducido por Arquitectura (MDA Model Driven Architecture). OMG UML 2.0, a diferencia de su antecesor, ofrece a los proveedores de herramientas CASE (Computer-Aided Software Engineering) las características necesarias que permitirán cumplir la promesa histórica que le dio vida a este tipo de herramientas: la producción automática de programas basado en especificaciones del software. Actualmente, dicha promesa se encuentra mucho más cerca de ser cumplida con la propuesta de OMG UML 2.0. OMG UML 1.x está constituido por siete (07) diagramas básicos y dos (02) diagramas [3] que constituyen variaciones de dos de los anteriores Casos de Uso Secuencias Colaboraciones Componentes Despliegue Estados
Actividad Objetos Clases En OMG UML 2.0 se definen una serie de diagramas adicionales a los establecidos en OMG UML 1.x. El conjunto de diagramas se encuentra organizado en torno a dos categorías: diagramas estructurales (representados en verdes) y diagramas dinámicos o de comportamiento (representados en celeste). Los diferentes diagramas son indicados en la figura siguiente: colaboración de OMG UML 1.x se ha transformado en el Diagrama de Comunicación en OMG UML 2.0. Adicionalmente se incorporan los diagramas Estructura Compuesta. Se emplea para visualizar de manera gráfica las partes que definen la estructura interna de un clasificador. Cuando se utiliza en el marco de una clase, este diagrama permite elaborar un diagrama de clases donde se muestran los diferentes atributos (partes) y las clases, a partir de las cuales se definen los atributos, indicando principalmente las asociaciones de agregación o de composición de la clase a la que se le elabora el diagrama.? Diagrama General de Interacción. Se emplea fundamentalmente para representar las interacciones, a través de diagramas o fragmentos de diagramas de secuencias, entre los actores y el sistema como una gran caja negra, y de diagramas de actividades en los que aparecen dichos fragmentos. Casos de Uso Componentes Despliegue Máquina de Estados Actividad
Objetos Clases UML 2.0 Estructura Compuesta Estructura Paquete Secuencias Comunicación Diagrama General de Interacción Tiempos Diagramas de Tiempos. Empleados para mostrar las interacciones donde el propósito fundamental consiste en razonar sobre la ocurrencia de eventos en el tiempo que provocan el cambio de estados de un elemento estructural (clase, componente, etc.). Comunicación. Equivalente al diagrama de colaboración del OMG UML 1.x. Permite especificar interacciones entre objetos que conforman la estructura interna de un clasificador. En OMG UML 2.0 los diagramas aparecen dentro de un marco (frame) que posee una etiqueta para indicar el tipo de diagrama. Las etiquetas establecidas por la especificación para identificar los diferentes tipos de diagramas Estructural Dinámica o Comportamiento pkg Paquete uc Casos de Uso cmp Diagrama Componentes act Actividad stm Máquina de Estados sd Secuencia El Casos de Uso El Casos de Uso permite realizar la especificación del alcance funcional del producto software que se construye y de los actores, entes que
interactúan con el producto software, que requieren los diferentes casos de usos. OMG UML 2.0 mantiene los conceptos fundamentales de OMG UML 1.x. Los casos de usos pueden relacionarse entre sí a través de asociaciones que permiten, entre otras cosas, refinar el Modelo de Casos de Usos a través de las asociaciones de: (1) Inclusión (asociación estereotipada como <<incluye>>). Permite incorporar el flujo de eventos de un caso de uso pequeño dentro de un caso de uso base de la aplicación. (2) Extensión (asociación estereotipada como <<extend>>). Permite incorporar el flujo de eventos de un caso de uso pequeño dentro de un caso de uso base de la aplicación bajo la ocurrencia de una determinada condición, cuando la misma evalúa verdadero. (3) Generalización (asociación estereotipada como <<generalization>>). Permite establecer una jerarquía de herencia al nivel de los casos de uso, donde el caso de uso derivado adquiere toda la especificación del caso de uso base e incorporar nuevos requerimientos a la especificación. Casos de Uso Muchos autores recomiendan no emplear estos tres tipos de asociaciones entre los casos de usos, excepto en aquellos casos que producto del refinamiento del modelo se justifique su uso. El Clases El diagrama de clases propuesto desde la OMG UML 1.x no ha sufrido cambios radicales en OMG UML 2.0. Quizás para aquellos especialistas que cuentan con una experiencia en el modelado de datos, encontrarán en las asociaciones de orden superior un buen mecanismo para capturar asociaciones diferentes a las asociaciones binarias. El Secuencia
Al diagrama de secuencia se le ha incorporado un mecanismo a través del cual se puede realizar la especificación de bloques repetitivos, opcionales, alternativos, entre otros. En el siguiente diagrama se puede observar que el registro del préstamo solo se efectúa si el usuario satisface la regla de negocio que establece que el libro se encuentre disponible y que además no se ha alcanzado el número máximo de libros que se le puede prestar a un usuario dependiendo de su tipo. Algunas de las principales alternativas de los fragmentos que se pueden definir en un diagrama de secuencia son las indicadas a continuación opt : Indica que el fragmento de diagrama es opcional. alt : Indica que el fragmento de diagrama es una alternativa. loop : Indica que el fragmento de diagrama se ejecuta repetidas veces. par : Indica que el fragmento de diagrama incluye hilos de ejecución paralelos La definición de los fragmentos anteriores permiten que las diferentes herramientas CASE puedan llevar a cabo la generación de código soportando el Model Driven Development. Secuencia con fragmento opcional El Clases de Diseño Clases de Diseño Durante el diseño de un producto se emplea el diagrama de clases para representar su estructura estática. De igual forma a como se explicó anteriormente, el diagrama de clases en OMG UML 2.0 no introduce aspectos radicales en comparación a OMG UML 1.x. Excepto quizás la incorporación de un conjunto de estereotipos y de las asociaciones de orden superior al binario establecidas en las especificaciones de OMG UML 1.x. El Componentes Uno de los principales elementos incorporados al diagrama de componentes
consiste en la definición de puertos a través de los cuales cada componente software entrega un conjunto de servicios a través de interfaces proveídas y de manera declarativa se definen los servicios requeridos por el componente software. Este mecanismo permite, a diferencia de OMG UML 1.x, que un componente software de manera aislada cuente con toda la especificación no solo interna sino además de la especificación de los requerimientos para la integración del componente software con otros componentes software. El Componentes El Despliegue de la Solución sobre la Infraestructura TI A través del diagrama de despliegue se combina la Arquitectura de TI con la Arquitectura de Aplicación o Software. El diagrama de despliegue propuesto por OMG UML 2.0 introduce una serie de elementos significativamente diferentes y mejorados en relación a OMG UML Sobre los diferentes nodos de la infraestructura de red se colocan, a modo de artefactos, los elementos componentes del software. Un artefacto puede ser elemento físico simple (por ejemplo, un archivo de configuración del despliegue) o estar constituido por otros artefactos (por ejemplo, un archivo WAR, un JAR o EAR). El Despliegue A través de un artefacto se pueden agregar una serie de componentes software para su despliegue sobre un nodo específico sobre la infraestructura de la red. Rational Software Modeler (RSM) Con la adquisición de Rational por IBM en 2003, se ha producido una renovación del portafolio de productos Rational, siendo el IBM Rational Rose uno de los productos sobre los que se ha realizado un excelente trabajo de mejora. IBM
Rational Rose ha evolucionado en XDE y este último en Rational Software Modeler Rational Software Modeler Rational Software Modeler soporta los diagramas fundamentales de UML 2.0 y está construido sobre la plataforma abierta y extensible Eclipse, lo que le proporciona una capacidad de extensión sin precedentes. Además, por ser parte de la plataforma de desarrollo de software IBM se integra con el resto de las herramientas como por ejemplo IBM Rational Requisite Pro e IBM Rational ClearCase. Rational Software Modeler es distribuido en el Perú por AVATAR SRL, empresa líder en la comercialización de herramientas de IBM Rational, ofreciendo además servicios de consultoría, mentoría y capacitación para el uso eficiente de éstas Su misión es, al igual que la de Rational, asegurar el éxito de los clientes que dependen del desarrollo o despliegue de Software. Conclusiones UML 2.0 es la mayor revisión que se le ha hecho a UML desde la versión 1.0. El modelo conceptual ha sido reestructurado completamente y nuevos diagramas han sido incorporados. Los diagramas tradicionales también han sido mejorados. La nueva versión permitirá a los fabricantes de herramientas CASE proporcionar a los analistas, arquitectos y desarrolladores; herramientas cada vez más potentes que les permitan aprovechar mejor los modelos y como consecuencia generar una mayor cantidad código reduciendo significativamente el ciclo de desarrollo de sus aplicaciones.