El lenguaje de modelado unificado ( UML ) es un lenguaje de modelado visual de propósito general cuyo objetivo es proporcionar una forma estándar de visualizar el diseño de un sistema. [1]
UML proporciona una notación estándar para muchos tipos de diagramas que se pueden dividir aproximadamente en tres grupos principales: diagramas de comportamiento, diagramas de interacción y diagramas de estructura.
La creación de UML fue motivada originalmente por el deseo de estandarizar los diferentes sistemas de notación y enfoques del diseño de software. Fue desarrollado en Rational Software en 1994-1995, y ellos dirigieron un mayor desarrollo hasta 1996. [1]
En 1997, UML fue adoptado como estándar por el Object Management Group (OMG) y ha sido administrado por esta organización desde entonces. En 2005, UML también fue publicado por la Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC) como estándar ISO/IEC 19501 . [2] Desde entonces, el estándar se ha revisado periódicamente para cubrir la última revisión de UML. [3]
En ingeniería de software, la mayoría de los profesionales no utilizan UML, sino que producen diagramas informales dibujados a mano; Estos diagramas, sin embargo, suelen incluir elementos de UML. [4] : 536
UML ha evolucionado desde la segunda mitad de los años 1990 y tiene sus raíces en los métodos de programación orientada a objetos desarrollados a finales de los años 1980 y principios de los 1990. 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]
Rational Software Corporation contrató a James Rumbaugh de General Electric en 1994 y después de eso la compañía se convirtió en la fuente de dos de los enfoques de modelado orientado a objetos más populares de la época: [6] la técnica de modelado de objetos (OMT) de Rumbaugh y la técnica de Grady Booch. método. Pronto contaron con la ayuda de Ivar Jacobson , el creador del método de ingeniería de software orientada a objetos (OOSE), que se unió a ellos en Rational en 1995. [1]
Bajo el liderazgo técnico de esos tres (Rumbaugh, Jacobson y Booch), en 1996 se organizó 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 incluí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 el mismo mes, los socios de UML formaron 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. [1] [7]
Después de la primera versión, se formó un grupo de trabajo [1] para mejorar el lenguaje, que lanzó varias revisiones menores, 1.3, 1.4 y 1.5. [8]
Se ha observado que los estándares que produjo (así como el estándar original) son ambiguos e inconsistentes. [9]
Al igual que con los diagramas ER de Chen, Bachman e ISO de bases de datos , los modelos de clases se especifican para utilizar cardinalidades de "visión transversal" , aunque varios autores ( Merise , [10] Elmasri y Navathe [11] entre otros [12] ) prefieren lo mismo. lado o "mirar aquí" para roles y cardinalidades mínimas y máximas. Investigadores recientes (Feinerer, [13] Dullea et al. [14] ) han demostrado que la técnica de "mirada transversal" utilizada por los diagramas UML y ER es menos efectiva y menos coherente cuando se aplica a relaciones n -arias de orden estrictamente mayor que 2.
Feinerer dice: "Surgen problemas si operamos bajo la semántica de mirada cruzada como se usa para las asociaciones UML. Hartmann [15] investiga esta situación y muestra cómo y por qué fallan diferentes transformaciones", y: "Como veremos en los próximos páginas, la interpretación transversal introduce varias dificultades que impiden la extensión de mecanismos simples de asociaciones binarias a n -arias."
La revisión principal de UML 2.0 reemplazó 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 en el uso de sus funciones. [dieciséis]
Aunque UML 2.1 nunca se lanzó como especificación formal, las versiones 2.1.1 y 2.1.2 aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 se lanzó formalmente en mayo de 2010. [17] UML 2.4.1 se lanzó formalmente en agosto de 2011. [17] UML 2.5 se lanzó en octubre de 2012 como una versión "en progreso" y se lanzó oficialmente en junio de 2015. [17] La versión formal 2.5.1 se adoptó en diciembre de 2017. [18]
La especificación UML 2.x consta de cuatro partes:
Hasta UML 2.4.1, las últimas versiones de estos estándares eran: [19]
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: [20]
El grupo de trabajo de revisión continúa actualizándolo y mejorándolo, quienes resuelven cualquier problema con el idioma. [21]
UML ofrece una forma de visualizar los planos arquitectónicos de un sistema en un diagrama, incluidos elementos como: [5]
Aunque originalmente estaba destinado a la documentación de diseño orientada a objetos, UML se ha extendido a un conjunto más amplio de documentación de diseño (como se enumera anteriormente), [22] y se ha encontrado útil en muchos contextos. [23]
UML no es un método de desarrollo en sí mismo; [24] sin embargo, fue diseñado para ser compatible con los principales métodos de desarrollo de software orientado a objetos de su época, por ejemplo OMT , método Booch , Objectory y especialmente RUP , con el que originalmente estaba destinado a usarse cuando comenzó el trabajo en Rational Software. .
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. No es necesario que el conjunto de diagramas cubra completamente el modelo y eliminar un diagrama no cambia el modelo. El modelo también puede contener documentación que impulse los elementos y diagramas del modelo (como casos de uso escritos).
Los diagramas UML representan dos vistas diferentes de un modelo de sistema: [25]
Los modelos UML se pueden intercambiar entre herramientas UML utilizando el formato XML Metadata Interchange (XMI).
En UML, una de las herramientas clave para el modelado de comportamiento es el modelo de casos de uso, generado por OOSE . Los casos de uso son una forma de especificar los usos requeridos de un sistema. Normalmente, se utilizan para capturar los requisitos de un sistema, es decir, lo que se supone que debe hacer un sistema. [26]
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 , incluidos algunos que representan diferentes aspectos de las interacciones . Estos diagramas se pueden clasificar 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.
Los diagramas de estructura representan los aspectos estáticos del sistema. Enfatiza las cosas que deben estar presentes en el sistema que se está modelando. Dado que los diagramas de estructura representan la estructura, se utilizan ampliamente para documentar la arquitectura de software de los sistemas de software. Por ejemplo, el diagrama de componentes describe cómo un sistema de software se divide en componentes y muestra las dependencias entre estos componentes.
Los diagramas de comportamiento representan el aspecto dinámico del sistema. Enfatiza lo que debe suceder 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. Como ejemplo, el diagrama de actividades describe las actividades comerciales y operativas paso a paso de los componentes de un sistema.
Los diagramas de interacción, un subconjunto de diagramas de comportamiento, enfatizan el flujo de control y datos entre las cosas en el sistema que se está modelando. Por ejemplo, el diagrama de secuencia muestra cómo los objetos se comunican entre sí en relación con una secuencia de mensajes.
El Object Management Group (OMG) ha desarrollado una arquitectura de metamodelado para definir UML, llamada Meta-Object Facility . [27] MOF está diseñado como una arquitectura de cuatro capas, como se muestra en la imagen de la derecha. Proporciona un meta-metamodelo en la parte superior, llamado 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 instalación 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 tanto, de los 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 de tiempo de ejecución del sistema. [28]
El metamodelo se puede ampliar mediante un mecanismo llamado estereotipos . Esto ha sido criticado por ser insuficiente/insostenible por Brian Henderson-Sellers y César González-Pérez en "Usos y abusos del mecanismo de estereotipo en UML 1.x y 2.0". [29]
En 2013, OMG comercializó UML para muchos contextos, pero se centró principalmente en el desarrollo de software con un éxito limitado. [23] [30]
En ocasiones, se ha tratado como una solución mágica para el diseño , lo que genera problemas. El mal uso de UML incluye el uso excesivo (diseñar cada parte del sistema con él, lo cual es innecesario) y asumir que los principiantes pueden diseñar con él. [31]
Se considera un lenguaje extenso, con muchas construcciones . Algunas personas (incluyendo a Jacobson ) sienten que el tamaño de UML dificulta su aprendizaje (y por lo tanto su uso). [32]
MS Visual Studio dejó de admitir UML en 2016 debido a la falta de uso. [33]
Según Google Trends, UML ha estado en constante declive desde 2004. [34]
