Tabla
de contenidos
Introducción
Al momento de
desarrollar el nuevo estándar 2.0 de UML, la OMG se planteó, entre otros, dos
objetivos que podríamos considerar principales, debido a la influencia de éstos
en la nueva versión del estándar:
1.
Hacer el
lenguaje de modelado más extensible.
2.
Permitir la
validación y ejecución de modelos.
En el presente
artículo, se muestran los principales cambios en UML 2.0, cómo éstos influyen
en los objetivos planteados anteriormente, la nueva estructura de UML 2.0, los
nuevos diagramas y los cambios más importantes en los diagramas preexistentes.
La evolución de
la programación hacia la ejecución y validación automática de modelos
Conociendo UML 2.0
En este artículo
nos introduciremos al mundo del diseño de aplicaciones de software, a través de
su puerta más novedosa: UML 2.0.
Éste es el
comienzo de una serie de artículos 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 versión.
Objetivos
del UML 2.0
Al momento de
desarrollar el nuevo estándar 2.0 del UML, la OMG se propuso, entre otros, dos
objetivos que podríamos considerar principales debido a la influencia de éstos
en la versión final del estándar. Estos objetivos son:
1.
Hacer el
lenguaje de modelado mucho más extensible de lo que era.
2.
Permitir la
validación y ejecución 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 razón del quiebre y el por qué de esta
evolución tan marcada, nos profundizaremos un poco en la historia y definición
misma del UML.
El
UML y la Industria del Software
El UML se ha
vuelto el estándar de facto (impuesto por la industria y los usuarios) para el
modelado de aplicaciones de software. En los últimos años, 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
básicos sobre UML
UML 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 semántica. Por lo tanto, al modelar un concepto en UML, existen
reglas sobre cómo deben agruparse los elementos del lenguaje y el significado
de esta agrupación.
·
Modelado: el
UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo
real, que permiten una mejor interpretación y entendimiento de éste.
·
Unificado:
unifica varias técnicas de modelado en una única.
Ya que el UML
proviene de técnicas orientadas a objetos, se crea con la fuerte intención de
que este permita un correcto modelado orientado a objetos.
(Muy)
Breve Reseña Histórica
Las raíces del
UML provienen de tres métodos distintos. El método de Grady Booch, la Técnica
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 versión del UML y en 1997 fue
aceptado por la OMG, fecha en la que fue lanzada la versión v1.1 del UML. Desde
entonces, UML atravesó varias revisiones y refinamientos hasta llegar a la
versión actual: UML 2.0.
¿Qué es la OMG?
La
OMG (Object Management Group) es una asociación 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 asociación se encarga de la definición y mantenimiento de estándares para
aplicaciones de la industria de la computación. Otro de los estándares
definidos por la OMG, además del UML, es CORBA, el cual permite
interoperabilidad multiplataforma a nivel de objetos de negocio.
Es importante destacar que, a
lo largo de estas constantes revisiones, muchas técnicas existentes fueron
agregadas a UML. Esta constante ampliación del lenguaje hizo que el UML fuera
perdiendo identidad, convirtiéndose en una agrupación de distintas técnicas de
modelado, sin demasiada cohesión 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.0
En las versiones
previas del UML, se hacía un fuerte hincapié en que UML no era un
lenguaje de programación. Un modelo creado mediante UML no podía ejecutarse. En
el UML 2.0, esta asunción cambió de manera drástica y se modificó el lenguaje,
de manera tal que permitiera capturar mucho más comportamiento (Behavior). De
esta forma, se permitió la creación de herramientas que soporten la
automatización y generación de código ejecutable, a partir de modelos UML.
Estándares que
conforman el UML
·
Superestructura:
Es la especificación que usamos todos los días. Aquí se encuentran todos los
diagramas que la mayoría de los desarrolladores conocen.
·
Infraestructura:
Conceptos de bajo nivel. Meta-Modelo da soporte a la superestructura,
entre otras.
·
OCL: Lenguaje de
restricción. 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.
Reestructuración
del Lenguaje
Para lograr los
objetivos enunciados, varios aspectos del lenguaje fueron reestructurados y/o
modificados. La especificación 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 organización
es modelable utilizando el propio UML 2.0; de esta manera, se da un ejemplo de
utilización 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
continuación, un poco más 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 inglés 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 versión 1.1. El OCL fue
originalmente especificado por IBM y es un ejemplo más de las muchas
herramientas agregadas al UML.
Especificación
para el Intercambio de Diagramas
La especificación
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 decía
nada acerca de la manera en que el modelo debía graficarse. Para solucionar
este problema, la nueva especificación para el intercambio de diagramas fue
desarrollada utilizando un nuevo Schema XML, que permite construir una
representación SVG (Scalable Vector Graphics). Esta especificación es
denominada con las siglas XMI, que en inglés significa: XML Metadata
Interchange; y en castellano se traduce como: XML de Intercambio de Metadata
(datos que representan datos). Típicamente esta especificación es solamente
utilizada por quienes desarrollan herramientas de modelado UML.
Infraestructura
En la
Infraestructura del UML se definen los conceptos centrales y de más 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
común de los usuarios. La Infraestructura brinda también varios mecanismos de
extensión, que hacen del UML un lenguaje configurable. Para los usuarios
normales del UML basta con saber si la infraestructura existe y cuáles son sus
objetivos.
Superestructura
La
superestructura del UML es la definición formal de los elementos del UML. Esta
definición sola contiene más de 640 páginas. La superestructura es típicamente
utilizada por los desarrolladores de aplicación. Es aquella sobre la que hablan
los libros y la que la mayoría conoce de versiones anteriores del UML.
La
Superestructura del UML
Es en la Superestructura donde
encontramos los cambios que más afectan en el día a día 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í dónde se
definen los diagramas y los elementos que los componen. La Superestructura se
encuentra dividida en niveles. Estos niveles se conocen como:
·
Básico (L1):
Contiene los elementos básicos 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 especificación del UML 2.0 completa, como por ejemplo: las
Acciones, Características avanzadas y PowerTypes? entre
otros.
Es importante
destacar que basta con que una herramienta implemente el nivel de conformidad
Básico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver
una disparidad de características (features) bastante amplia entre dos
herramientas distintas, aunque éstas sean UML 2.0 compatibles.
Organización
de la superestructura
El bloque de
construcción básico del UML es un diagrama. La estructura de los diagramas UML
está reflejado por el diagrama de la figura 2, de acuerdo con la especificación
del UML 2.0 del Object Development Group. Los detalles sobre estos diagramas
específicos se organizan de acuerdo a esta estructura taxonómica, que da la
perspectiva a los diagramas y a sus interrelaciones. Los diagramas de
interacción 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 versión del UML.
Figura 2: Estructura
taxonómica del UML 2.0
Diagramas
de Estructura y Diagramas de comportamiento
Los diagramas
estructurales representan elementos y así componen un sistema o una función.
Estos diagramas pueden reflejar las relaciones estáticas de una estructura,
como lo hacen los diagramas de clases o de paquetes, o arquitecturas en tiempo
de ejecución, tales como diagramas de Objetos o de Estructura de Composición.
Los diagramas de comportamiento representan las características 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
descripción sobre los diagramas
En 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 características del UML 2.0. Sobre esta premisa, ampliaremos
la explicación de cada diagrama en las próximas ediciones, dando más
importancia a los diagramas que figuran con mayor prioridad en el cuadro.
|
Diagrama
|
Descripción
|
Prioridad
|
|
Diagrama de Clases
|
Muestra una colección de elementos de modelado declarativo
(estáticos), tales como clases, tipos y sus contenidos y relaciones.
|
Alta
|
|
Diagrama de Componentes
|
Representa los componentes que componen una aplicación, sistema o
empresa. Los componentes, sus relaciones, interacciones y sus interfaces
públicas.
|
Media
|
|
Diagrama de Estructura de Composición
|
Representa la estructura interna de un clasificador (tal como una
clase, un componente o un caso de uso), incluyendo los puntos de interacción
de clasificador con otras partes del sistema.
|
Baja
|
|
Diagrama de Despliegue Físico
|
Un diagrama de despliegue físico muestra cómo y dónde se desplegará el
sistema. Las máquinas físicas y los procesadores se representan como nodos y
la construcción interna puede ser representada por nodos o artefactos
embebidos. Como los artefactos se ubican en los nodos para modelar el
despliegue del sistema, la ubicación es guiada por el uso de las
especificaciones de despliegue.
|
Media
|
|
Diagrama de Objetos
|
Un diagrama que presenta los objetos y sus 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.
|
Baja
|
|
Diagrama de Paquetes
|
Un diagrama que presenta cómo se organizan los elementos de modelado
en paquetes y las dependencias entre ellos, incluyendo importaciones y
extensiones de paquetes.
|
Baja
|
|
Diagrama de Actividades
|
Representa los procesos de negocios de alto nivel, incluidos el flujo
de datos. También puede utilizarse para modelar lógica compleja y/o paralela
dentro de un sistema.
|
Alta
|
|
Diagrama de Comunicaciones (anteriormente: Diagrama de colaboraciones)
|
Es un diagrama que enfoca la interacción entre líneas de vida, donde
es central la arquitectura de la estructura interna y cómo ella se
corresponde con el pasaje de mensajes. La secuencia de los mensajes se da a
través de un esquema de numerado de la secuencia.
|
Baja
|
|
Diagrama de Revisión de la Interacción
|
Los Diagramas de Revisión de la Interacción enfocan la revisión del
flujo de control, donde los nodos son Interacciones u Ocurrencias de
Interacciones. Las Líneas de Vida los Mensajes no aparecen en este nivel de
revisión
|
Baja
|
|
Diagrama de Secuencias
|
Un diagrama que representa una interacción, poniendo el foco en la
secuencia de los mensajes que se intercambian, junto con sus correspondientes
ocurrencias de eventos en las Líneas de Vida.
|
Alta
|
|
Diagrama de Máquinas de Estado
|
Un diagrama de Máquina de Estados ilustra cómo 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 Máquinas de Estados, que
representan y explican el movimiento y el comportamiento.
|
Media
|
|
Diagrama de Tiempos
|
El propósito primario del diagrama de tiempos es mostrar los cambios
en el estado o la condición de una línea de vida (representando una Instancia
de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal.
El uso más común es mostrar el cambio de estado de un objeto a lo largo del
tiempo, en respuesta a los eventos o estímulos aceptados. Los eventos que se
reciben se anotan, a medida que muestran cuándo se desea mostrar el evento
que causa el cambio en la condición o en el estado.
|
Baja
|
|
Diagrama de Casos de Uso
|
Un diagrama que muestra las relaciones entre los actores y el sujeto
(sistema), y los casos de uso.
|
Media
|
Conclusión
A lo largo del
artículo hemos analizado los objetivos y el impacto de éstos en la versión 2.0
del UML. Analizamos la estructura del UML 2.0, su conformación interna y la
división taxonómica de sus diagramas.
¿Cómo sigo?
Recomendamos
leer el siguiente artículo, el cual es la continuación del presente: El Poder
Semántico del UML 2.0 en la Práctica donde se
muestran los cambios más importantes en el Lenguaje Unificado de Modelado,
desde el punto de vista del desarrollador, mediante ejemplos.
Bibliografía
Libros
recomendados: Hemos revisado varios libros dedicados a la
superestructura del UML 2.0. Entre ellos el que parece ser más destacable es:
UML 2.0 in a Nutshell.
Excelente
referencia para el trabajo diario. La introducción teórica es un poco
superficial, debido a que el foco del libro es la superestructura. El libro
puede ser útil tanto a expertos UML como para quienes recién se inician.
·
“UML 2 for Dummies”
de Michael J. Chonoles y James A. Schardt
Libro de muy
fácil lectura con una introducción teórica adecuada. El tratamiento de los
temas podría ser un poco más amplio, ya que el libro apunta a personas sin
conocimiento del UML.
·
“Fast Track UML
2.0” de Kendall Scott y Apress
Libro totalmente
orientado a la superestructura. La introducción conceptual teórica a los nuevos
aspectos del UML 2.0 es bastante superficial y carece de un hilo conductor en
cuanto a la organización de los temas. A pesar de esto, los distintos diagramas
están bien explicados
Otros libros
recomendados de Orientación a Objetos:
Para quien quiera una excelente introducción teórica al mundo del diseño
orientado objetos, dejamos estas recomendaciones:
Si le preguntan
a alguien que trabaje con objetos sobre un libro de diseño orientado a objetos,
seguramente les recomiende este libro
·
"Smalltalk
Objects, and Design (Paperback)" de Chamond Liu
Otro excelente
libro de diseño OO. Un poco más orientado a Smalltalk, pero conceptualmente
completo.
·
“Object-oriented
Systems Analysis and Design Using UML” de Simon Bennett, Steve McRobb? y Ray Farmer.
Un libro que
combina teoría de objetos y UML, con un enfoque un poco más práctico.
Herramientas
A continuación, nombramos algunas herramientas que soportan UML 2.0. Dado que
no todas tienen el mismo nivel de conformidad, el nivel más alto a la
fecha lo tiene Enterprise Architect.
http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15#Infraestructura
No hay comentarios:
Publicar un comentario