Lenguaje Unificado de Modelado

Los diagramas UML permiten visualizar aspectos del sistema como: ^{[ 14 ]}

• Diagrama de casos de uso para especificar las interacciones del usuario con los sistemas.
• Diagrama de clases para especificar estructuras, incluidas las estructuras de datos.
• Diagrama de actividades para especificar flujos de trabajo de procesos de negocio.
• Diagrama de componentes para especificar cómo interactúan los componentes entre sí.
• Diagrama de despliegue para especificar cómo se despliegan y ejecutan los componentes en los nodos computacionales.

Además de los elementos sintácticos (de notación) con semántica bien definida, los diagramas UML también permiten comentarios (notas) de formato libre que explican aspectos como el uso, las restricciones y las intenciones.

Los modelos UML se pueden intercambiar entre herramientas UML mediante el formato XML Metadata Interchange (XMI).

Al igual que con los diagramas de base de datos Chen, Bachman e ISO ER , los modelos de clases se especifican para usar cardinalidades de "mirada cruzada" , aunque varios autores ( Merise , ^{[ 15 ]} Elmasri y Navathe, ^{[ 16 ]} entre otros ^{[ 17 ]} ) prefieren el mismo lado o "mira aquí" para roles y cardinalidades mínimas y máximas. Investigadores recientes (Feinerer ^{[ 18 ]} y Dullea et al. ^{[ 19 ]} ) han demostrado que la técnica de "mirada cruzada" utilizada por UML y los diagramas ER es menos efectiva y menos coherente cuando se aplica a relaciones n -arias de orden estrictamente mayor que 2.

Feinerer afirma: «Surgen problemas si operamos bajo la semántica de búsqueda cruzada utilizada para las asociaciones UML. Hartmann ^{[ 20 ]} investiga esta situación y muestra cómo y por qué fallan las diferentes transformaciones», y: «Como veremos en las próximas páginas, la interpretación de búsqueda cruzada introduce varias dificultades que impiden la extensión de mecanismos simples de asociaciones binarias a n -arias».

Un artefacto es la "especificación de una pieza física de información que se utiliza o produce mediante un proceso de desarrollo de software , o mediante el despliegue y la operación de un sistema" ^{[ 21 ]} incluyendo modelos, código fuente , scripts, ejecutables , tablas en sistemas de bases de datos , entregables de desarrollo, documentos de diseño y mensajes de correo electrónico . ^{[ 21 ]}

Un artefacto es la entidad física que se despliega en un nodo . ^{[ 21 ]} Otros elementos UML, como clases y componentes, se manifiestan primero en artefactos, y luego se despliegan instancias de estos artefactos. Los artefactos pueden estar compuestos por otros artefactos.

La OMG desarrolló una arquitectura de metamodelado para definir UML, denominada Meta-Object Facility (MOF). ^{[ 22 ]} MOF está diseñada como una arquitectura de cuatro capas, como se muestra en la imagen de la derecha. Proporciona un meta-metamodelo en la parte superior, denominado capa M3. Este modelo M3 es el lenguaje utilizado por Meta-Object Facility para construir metamodelos, denominados modelos M2.

Un ejemplo de modelo de la Facilidad de Metaobjetos de Capa 2 es el metamodelo UML, 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. Una descripción de arquitectura de software podría describir instancias de tiempo de ejecución del sistema. ^{[ 23 ]} . La última capa es la capa M0: el objeto del mundo real que se describe o modela.

El metamodelo UML puede extenderse mediante un mecanismo denominado estereotipo . Brian Henderson-Sellers y César González-Pérez criticaron este mecanismo por considerarlo insuficiente o insostenible en su artículo «Usos y abusos del mecanismo de estereotipo en UML 1.x y 2.0». ^{[ 24 ]}

Los diagramas de estructura enfatizan la estructura del sistema , utilizando objetos, clasificadores, relaciones, atributos y operaciones. Se utilizan para documentar la arquitectura del software .

• Diagrama de clases : describe la estructura de una clase.
• Diagrama de componentes : describe cómo se divide un sistema de software en componentes y las dependencias entre ellos.
• Diagrama de estructura compuesta
• Diagrama de despliegue
• Diagrama de objetos
• Diagrama del paquete
• Diagrama de perfil

Los diagramas de comportamiento resaltan la conducta de un sistema al mostrar las colaboraciones entre objetos y los cambios en sus estados internos. Se utilizan para describir la funcionalidad de un sistema.

• Diagrama de actividades : describe las actividades comerciales y operativas de los componentes.
• Diagrama de máquina de estados
• Diagrama de casos de uso : representa la interacción de un usuario con un sistema ^{[ 26 ].}

Los diagramas de interacción, un subconjunto de los diagramas de comportamiento, enfatizan el flujo de control y de datos entre los componentes de un sistema.

• Diagrama de comunicación : muestra la comunicación entre componentes.
• Diagrama general de interacción
• Diagrama de secuencia : muestra las interacciones ordenadas cronológicamente; se puede dibujar mediante herramientas como Lucidchart y Draw.io.
• Diagrama de tiempos : se centra en las restricciones de tiempo.

• 
  Diagrama de componentes
• 
  Diagrama de clases
• 
  Diagrama de actividad
• 
  Diagrama de casos de uso
• 
  Diagrama de casos de uso
• 
  Diagrama de despliegue

Rational Software 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 de la época: ^{[ 31 ]} la técnica de modelado de objetos (OMT) de Rumbaugh y el método de Grady Booch. Pronto recibieron ayuda en sus esfuerzos de Ivar Jacobson , el creador del método de ingeniería de software orientado a objetos (OOSE), quien se unió a ellos en Rational en 1995. ^{[ 4 ]}

UML 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 se integraron en un único lenguaje. ^{[ 14 ]} UML fue desarrollado en Rational Software entre 1994 y 1995, y continuó su desarrollo hasta 1996. ^{[ 4 ]}

Bajo el liderazgo técnico de Rumbaugh, Jacobson y Booch, se organizó en 1996 un consorcio llamado UML Partners para completar la especificación del Lenguaje Unificado de Modelado (UML) y proponerla al Object Management Group (OMG) para su estandarización. La asociación también incluyó a otras partes interesadas (por ejemplo, HP , DEC , IBM y Microsoft ). El borrador UML 1.0 de UML Partners fue propuesto al OMG en enero de 1997 por el consorcio. Durante ese mismo mes, UML Partners formó un grupo, diseñado para 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 estandarización. El resultado de este trabajo, UML 1.1, fue presentado al OMG en agosto de 1997 y adoptado por el OMG en noviembre de 1997. ^{[ 4 ] [ 32 ]}

Después del primer lanzamiento, se formó un grupo de trabajo ^{[ 4 ]} para mejorar el lenguaje, que lanzó varias revisiones menores, 1.3, 1.4 y 1.5. ^{[ 33 ]}

Se ha señalado que las normas que produjo (así como la norma original) son ambiguas e inconsistentes. ^{[ 34 ]}

La revisión principal UML 2.0 reemplazó a la versión 1.5 en 2005, la cual fue desarrollada con un consorcio ampliado para mejorar aún más el lenguaje y reflejar nuevas experiencias en el uso de sus características. ^{[ 35 ]}

Aunque UML 2.1 nunca se publicó como una 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. ^{[ 36 ]} UML 2.4.1 se publicó formalmente en agosto de 2011. ^{[ 36 ]} UML 2.5 se publicó en octubre de 2012 como una versión "en progreso" y se publicó oficialmente en junio de 2015. ^{[ 36 ]} La versión formal 2.5.1 se adoptó en diciembre de 2017. ^{[ 1 ]}

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

• La superestructura que define la notación y la semántica de los diagramas y sus elementos de modelo.
• La infraestructura que define el metamodelo central sobre el cual se basa la superestructura.
• El lenguaje de restricciones de objetos (OCL) para definir reglas para los elementos del modelo.
• El diagrama de intercambio UML define cómo se intercambian los diseños de diagramas UML 2.

Hasta UML 2.4.1, las versiones más recientes de estos estándares eran: ^{[ 37 ]}

• Superestructura UML versión 2.4.1
• Infraestructura UML versión 2.4.1
• Versión OCL 2.3.1
• Diagrama UML de intercambio versión 1.0.

Desde la versión 2.5, la especificación UML se ha simplificado (sin superestructura ni infraestructura), y las últimas versiones de estos estándares son ahora: ^{[ 38 ]}

• Especificación UML 2.5.1
• OCL versión 2.4

El grupo de trabajo de revisión continúa actualizándolo y mejorándolo, resolviendo cualquier problema con el idioma. ^{[ 39 ]}