Diagrama UML

Contenido

 [ocultar] 

• 1 Historia
• 1.1 Antes de UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Diseño
• 2.1 Métodos de desarrollo de software
• 2.2 Modelización
• 3 Diagramas
• 3.1 Diagramas de estructura
• 3.2 Diagramas de comportamiento
• 3.2.1 Diagramas de interacción
• 4 Metamodelación
• 5 Adopción
• 6 Críticas
• 6.1 Crítica a UML 1.x

Historia[editar fuente | editar]

Historia de los métodos y la notación orientados a objetos

UML ha ido evolucionando desde la segunda mitad de los años 90 y tiene sus raíces en los métodos orientados a objetos desarrollados a finales de los años 80 y principios de los 90. La línea de tiempo (ver imagen) muestra los aspectos más destacados de la historia de los métodos y la notación de modelado orientado a objetos.

Se basa originalmente en las notaciones del método Booch, la técnica de modelado de objetos (OMT) y la ingeniería de software orientada a objetos (OOSE), que ha integrado en un único lenguaje. ^[5]

Antes de UML 1.x[editar fuente | editar]

Rational Software Corporation contrató a James Rumbaugh de General Electric en 1994 y, a partir de entonces, la empresa se convirtió en la fuente de dos de los enfoques de modelado orientado a objetos más populares del momento:^[6]técnica de modelado de objetos (OMT) de Rumbaugh y el método de Grady Booch. Pronto contaron con la ayuda de Ivar Jacobson, el creador del método de ingeniería de software orientado a objetos (OOSE), que se unió a ellos en Rational en 1995. ^[1]

Bajo la dirección técnica de estos tres (Rumbaugh, Jacobson y Booch), en 1996 se organizó un consorcio llamado UML Partners para completar la especificación del Lenguaje de Modelado Unificado (UML) y proponerla al Object Management Group (OMG) para su estandarización. El consorcio también incluía otras partes interesadas (por ejemplo, HP, DEC, IBM y Microsoft). El consorcio propuso al OMG el borrador UML 1.0 de los socios UML en enero de 1997. Ese mismo mes, los socios de UML formaron un grupo, destinado a definir el significado exacto de las construcciones del lenguaje, presidido por Cris Kobryn y administrado por Ed Eykholt, para finalizar la especificación e integrarla con otros esfuerzos de normalización. El resultado de este trabajo, UML 1.1, se presentó al OMG en agosto de 1997 y fue adoptado por éste en noviembre de 1997. ^[1][7]

UML 1.x[editar fuente | editar]

Tras la primera versión, se formó un grupo de trabajo ^[1]para mejorar el lenguaje, que publicó varias revisiones menores, 1.3, 1.4 y 1.5. ^[8]

Las normas que produjo (así como la norma original) han sido señaladas como ambiguas e incoherentes. ^[9][10]

UML 2.x[editar fuente | editar]

La revisión mayor de UML 2.0 sustituyó a la versión 1.5 en 2005, que se desarrolló con un consorcio ampliado para mejorar aún más el lenguaje y reflejar la nueva experiencia sobre el uso de sus características. ^[11]

Aunque UML 2.1 nunca se publicó como especificación formal, las versiones 2.1.1 y 2.1.2 aparecieron en 2007, seguidas de UML 2.2 en febrero de 2009. UML 2.3 se publicó formalmente en mayo de 2010.^[12] UML 2.4.1 se publicó formalmente en agosto de 2011. UML 2.5 se ^[12]publicó en octubre de 2012 como versión "En proceso" y se publicó oficialmente en junio de 2015. ^[12]

La especificación UML 2.x consta de cuatro partes:

1. La superestructura que define la notación y la semántica de los diagramas y sus elementos del modelo
2. La infraestructura que define el metamodelo central en el que se basa la superestructura
3. El Lenguaje de Restricciones de Objetos (OCL) para definir las reglas de los elementos del modelo
4. El intercambio de diagramas UML que define cómo se intercambian los diseños de diagramas UML 2

Las versiones actuales de estas normas son las siguientes Superestructura UML versión 2.4.1, Infraestructura UML versión 2.4.1, OCL versión 2.3.1 e Intercambio de diagramas UML versión 1.0.^[13] El grupo de trabajo de revisión sigue actualizándolo y mejorándolo, y resuelve cualquier problema con el lenguaje. ^[14]

Diseño[editar fuente | editar]

El Lenguaje Unificado de Modelado (UML) ofrece una forma de visualizar los planos de arquitectura de un sistema en un diagrama (ver imagen), incluyendo elementos como: ^[5]

• Cualquier actividad (trabajos)
• Componentes individuales del sistema
• Y cómo pueden interactuar con otros componentes de software.
• Cómo funcionará el sistema
• Cómo interactúan las entidades con otras (componentes e interfaces)
• Interfaz de usuario externa

Aunque originalmente estaba destinado únicamente a la documentación del diseño orientado a objetos, el Lenguaje de Modelado Unificado (UML) se ha ampliado para abarcar un conjunto más amplio de documentación del diseño (como se ha enumerado anteriormente), ^[15]y se ha considerado útil en muchos contextos. ^[16]

Métodos de desarrollo de software[editar fuente | editar]

UML no es un método de desarrollo en sí mismo; ^[17]sin embargo, fue diseñado para ser compatible con los principales métodos de desarrollo de software orientado a objetos de su época (por ejemploOMT, el método Booch, Objectory) y, especialmente, con RUP, para el que se pensó originalmente cuando se empezó a trabajar en Rational Software Inc.

Modelado[editar fuente | editar]

Es importante distinguir entre el modelo UML y el conjunto de diagramas de un sistema. Un diagrama es una representación gráfica parcial del modelo de un sistema. El conjunto de diagramas no tiene por qué cubrir completamente el modelo y la eliminación de un diagrama no modifica el modelo. El modelo también puede contener documentación que impulsa los elementos del modelo y los diagramas (como los casos de uso escritos).

Los diagramas UML representan dos vistas diferentes de un modelo de sistema: ^[18]

• Vista estática (o estructural): hace hincapié en la estructura estática del sistema mediante objetos, atributos, operaciones y relaciones. La vista estructural incluye diagramas de clase y diagramas de estructura compuesta.
• Vista dinámica (o de comportamiento): hace hincapié en el comportamiento dinámico del sistema mostrando las colaboraciones entre los objetos y los cambios en los estados internos de los mismos. Esta vista incluye diagramas de secuencia, diagramas de actividad y diagramas de máquinas de estado.

Los modelos UML pueden intercambiarse entre herramientas UML utilizando el formato de intercambio de metadatos XML (XMI).

Diagramas[editar fuente | editar]

UML 2 tiene muchos tipos de diagramas que se dividen en dos categorías.^[5] Algunos tipos representan información estructural, y el resto representan tipos generales de comportamiento, incluyendo algunos que representan diferentes aspectos de las interacciones. Estos diagramas pueden clasificarse jerárquicamente como se muestra en el siguiente diagrama de clases: ^[5]

Todos estos diagramas pueden contener comentarios o notas que expliquen el uso, la restricción o la intención.

Diagramas de estructura[editar fuente | editar]

Los diagramas de estructura hacen hincapié en los elementos que deben estar presentes en el sistema que se modela. Dado que los diagramas de estructura representan la estructura, se utilizan mucho para documentar la arquitectura de los sistemas de software. Por ejemplo, el diagrama de componentes que describe cómo se divide un sistema de software en componentes y muestra las dependencias entre estos componentes.

• Diagrama de componentes
• Diagrama de clases

Diagramas de comportamiento[editar fuente | editar]

Los diagramas de comportamiento hacen hincapié en lo que debe ocurrir en el sistema que se está modelando. Dado que los diagramas de comportamiento ilustran el comportamiento de un sistema, se utilizan ampliamente para describir la funcionalidad de los sistemas de software. Por ejemplo, el diagrama de actividad describe las actividades empresariales y operativas paso a paso de los componentes de un sistema.

• Diagrama de actividades
• Diagrama de casos de uso

Diagramas de interacción[editar fuente | editar]

Los diagramas de interacción, un subconjunto de los diagramas de comportamiento, hacen hincapié en el flujo de control y datos entre los elementos del sistema que se está modelando. Por ejemplo, el diagrama de secuencia, que muestra cómo los objetos se comunican entre sí en términos de una secuencia de mensajes.

• Esquema de la secuencia
• Diagrama de comunicación

Meta modelado[editar fuente | editar]

Artículo principal: Dispositivo de metaobjetos

Ilustración de la herramienta de metaobjetos

El Grupo de Gestión de Objetos (OMG) ha desarrollado una arquitectura de metamodelado para definir el Lenguaje Unificado de Modelado (UML), denominada Meta-Object Facility (MOF).^[19] La Meta-Object Facility está diseñada como una arquitectura de cuatro capas, como se muestra en la imagen de la derecha. Proporciona un modelo meta-meta en la capa superior, denominada capa M3. Este modelo M3 es el lenguaje utilizado por Meta-Object Facility para construir metamodelos, llamados modelos M2.

El ejemplo más destacado de un modelo de Meta-Objeto de Capa 2 es el metamodelo UML, el modelo que describe el propio UML. Estos modelos M2 describen elementos de la capa M1, y por lo tanto modelos M1. Estos serían, por ejemplo, modelos escritos en UML. La última capa es la capa M0 o capa de datos. Se utiliza para describir instancias del sistema en tiempo de ejecución. ^[20]

El metamodelo puede ampliarse mediante un mecanismo denominado estereotipado. Esto ha sido criticado como insuficiente/insostenible por Brian Henderson-Sellers y César González-Pérez en "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

Adopción[editar fuente | editar]

UML ha resultado útil en muchos contextos de diseño,^[16] hasta el punto de que se ha convertido en algo casi omnipresente en la comunidad informática. ^[22]

Se ha tratado, a veces, como una bala de plata del diseño, lo que ha llevado a problemas en su uso. El mal uso incluye un uso excesivo del mismo (diseñar cada pequeña parte del código del sistema con él, lo cual es innecesario) y asumir que cualquiera puede diseñar cualquier cosa con él (incluso aquellos que no han programado). ^[23]

Se considera que es un lenguaje extenso, con muchas construcciones. Algunos (entre ellos Jacobson) consideran que son demasiados y que eso dificulta su aprendizaje (y, por tanto, su uso). ^[24]

Críticas[editar fuente | editar]

Algunas de las críticas más comunes de la industria a UML son ^[4]

• no es útil: "[no] les ofrece ventajas sobre sus prácticas y representaciones actuales y evolucionadas"
• demasiado complejo, sobre todo para la comunicación con los clientes: "innecesariamente complejo" y "la mejor razón para no utilizar UML es que no es "legible" para todos los interesados. ¿Cuánto vale el UML si un usuario empresarial (el cliente) no puede entender el resultado de su esfuerzo de modelado?"
• necesidad de mantener sincronizados el UML y el código, al igual que la documentación en general

Crítica a UML 1.x[editar fuente | editar]

Notación de cardinalidad

Al igual que en los diagramas de base de datos Chen, Bachman e ISO ER, los modelos de clase están especificados para utilizar cardinalidades "look-across", aunque varios autores (Merise, ^[25]Elmasri & Navathe entre ^[26]otros ^[27]) prefieren el mismo lado o "look-here" para los roles y las cardinalidades mínimas y máximas. Investigadores recientes (Feinerer, ^[28]Dullea et. alia ^[29]) han demostrado que la técnica de "look-across" utilizada por los diagramas UML y ER es menos eficaz y menos coherente cuando se aplica a relaciones n-arias de orden >2.

Feinerer dice: "Los problemas surgen si operamos bajo la semántica de "look-across" como la utilizada para las asociaciones UML. Hartmann ^[30]investiga esta situación y muestra cómo y por qué fallan diferentes transformaciones". (Aunque la "reducción" mencionada es espuria, ya que los dos diagramas 3.4 y 3.5 son de hecho el mismo) y también "Como veremos en las próximas páginas, la interpretación look-across introduce varias dificultades que impiden la extensión de mecanismos simples de asociaciones binarias a n-arias."