Portada

miércoles, 24 de julio de 2013

Estructura SuperEstructura InfraEstructura de SOFTWARE UML 2.0



Tabla de contenidos
·         Introducción
·         Conociendo UML 2.0
o    Conclusión
·         ¿Cómo sigo?
·         Bibliografía
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.
Podemos encontrar más información sobre la OMG en su sitio oficial: http://www.omg.org/ (external link)
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.
·         UML 2.0 in a Nutshell (external link)” de Dan Pilone y Neil Pitman
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:
·         "Designing Object-Oriented? Software" de Rebecca Wirfs-Brock?, Brian Wilkerson y Lauren Wiener
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