OMG UML 2.0 – Marcando un hito en el
desarrollo de software
Ing. Ilver Anache - [email protected] – Consultor AVATAR Ing. Joel Moreno - [email protected] – Consultor AVATAR Lima, 2005
AVATAR S.R.L
Av. Javier Prado 1104 Of. 701- San Isidro Teléfono: (51-1) 225-8390
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 (ver figura 1):
Figura 1. Diagramas de UML 1.x
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:
Figura 2. Diagramas de UML 2.0
Como se puede notar al comparar las dos figuras anteriores, el diagrama de 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 siguientes [2]:
? Diagrama de 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.
? 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.).
? Diagrama de 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 son las siguientes [2]:
Estructural Dinámica o Comportamiento
pkg Diagrama de Paquete uc Diagrama de Casos de Uso cmp Diagrama Componentes act Diagrama de Actividad
stm Diagrama de Máquina de Estados sd Diagrama de Secuencia
El Diagrama de Casos de Uso
El Diagrama de 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. Figura 3 -Diagrama de 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 Diagrama de 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 Diagrama de 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 [2]:
? 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
Figura 5 - Diagrama de Secuencia con fragmento opcional El Diagrama de 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 Diagrama de 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.
Figura 7. El Diagrama de 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.
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).
Figura 8. El Diagrama de 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)
Figura 9. 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[5]. 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
mayor cantidad código reduciendo significativamente el ciclo de desarrollo de sus aplicaciones.
Referencias
[1] OBJECT MANAGEMENT GROUP
2005 OMG Model Driven Architecture. http://www.omg.org/mda/ [2] OBJECT MANAGEMENT GROUP
2005 UML 2.0, The current Oficial Version. http://www.uml.org/#UML2.0 [3] OBJECT MANAGEMENT GROUP
2005 OMG’s UML 1.5 Specification.http://www.omg.org/technology/ documents/ modeling_spec_catalog.htm#UML
[4] IBM
2005 Rational Software Modeler,
http://www3.software.ibm.com/ibmdl/pub/software/rational/web/datasheet s/rsm.pdf
[5] Avatar SRL
