El lenguaje de modelado unificado ( UML ) es un lenguaje de modelado visual de propósito general que tiene como objetivo 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 pueden dividirse 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 distintos sistemas de notación y enfoques del diseño de software. Fue desarrollado en Rational Software entre 1994 y 1995, y su desarrollo posterior estuvo a cargo de ellos hasta 1996. [2]
En 1997, el Object Management Group (OMG) adoptó el UML como estándar y desde entonces lo ha gestionado esta organización. En 2005, la Organización Internacional de Normalización (ISO) y la Comisión Electrotécnica Internacional (IEC) también publicaron el UML como estándar ISO/IEC 19501. [3] Desde entonces, el estándar se ha revisado periódicamente para incluir la última versión del UML. [4]
En ingeniería de software, la mayoría de los profesionales no utilizan UML, sino que producen diagramas informales dibujados a mano; sin embargo, estos diagramas a menudo incluyen elementos de UML. [5] : 536
UML ha evolucionado desde la segunda mitad de la década de 1990 y tiene sus raíces en los métodos de programación orientada a objetos desarrollados a fines de la década de 1980 y principios de la de 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 orientados 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 solo lenguaje. [6]
En 1994, Rational Software Corporation contrató a James Rumbaugh , de General Electric, 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: [7] la técnica de modelado de objetos (OMT) de Rumbaugh y el método de Grady Booch . Pronto recibieron la ayuda 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. [2]
Bajo el liderazgo técnico 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. La asociación también incluía a otras partes interesadas (por ejemplo, HP , DEC , IBM y Microsoft ). El borrador de UML 1.0 de UML Partners fue propuesto al OMG en enero de 1997 por el consorcio. Durante el 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. [2] [8]
Después del primer lanzamiento, se formó un grupo de trabajo [2] para mejorar el lenguaje, que lanzó varias revisiones menores: 1.3, 1.4 y 1.5. [9]
Se ha señalado que las normas que produjo (así como la norma original) son ambiguas e inconsistentes. [10]
Al igual que con los diagramas de base de datos Chen, Bachman e ISO ER , los modelos de clase se especifican para utilizar cardinalidades de "mirar al otro lado" , aunque varios autores ( Merise , [11] Elmasri y Navathe, [12] entre otros [13] ) prefieren el mismo lado o "mirar aquí" para los roles y las cardinalidades mínimas y máximas. Investigadores recientes (Feinerer [14] y Dullea et al. [15] ) han demostrado que la técnica de "mirar al otro lado" 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: "Los problemas surgen si operamos bajo la semántica de look-across que se utiliza para las asociaciones UML. Hartmann [16] investiga esta situación y muestra cómo y por qué fallan diferentes transformaciones", y: "Como veremos en las próximas páginas, la interpretación de look-across 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 nuevas experiencias en el uso de sus características. [17]
Aunque UML 2.1 nunca fue publicado como una 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 fue lanzado formalmente en mayo de 2010. [18] UML 2.4.1 fue lanzado formalmente en agosto de 2011. [18] UML 2.5 fue lanzado en octubre de 2012 como una versión "en progreso" y fue lanzado oficialmente en junio de 2015. [18] La versión formal 2.5.1 fue adoptada en diciembre de 2017. [1]
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, y resuelve cualquier problema con el lenguaje. [21]
UML ofrece una manera de visualizar los planos arquitectónicos de un sistema en un diagrama, incluyendo elementos como: [6]
Aunque originalmente estaba pensado para la documentación de diseño orientado a objetos, UML se ha extendido a un conjunto más amplio de documentación de diseño (como se indica más arriba) [22] y se ha considerado ú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 tiempo, por ejemplo, OMT , el 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. El conjunto de diagramas no tiene por qué cubrir por completo el modelo y la eliminación de un diagrama no modifica el modelo. El modelo también puede contener documentación que guíe 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 de intercambio de metadatos XML (XMI).
En UML, una de las herramientas clave para el modelado de comportamiento es el modelo de casos de uso, creado por OOSE . Los casos de uso son una forma de especificar los usos requeridos de un sistema. Por lo general, 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. [6] 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 categorizar jerárquicamente como se muestra en el siguiente diagrama de clases: [6]
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. Destacan los elementos 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 se divide un sistema de software en componentes y muestra las dependencias entre estos componentes.
Los diagramas de comportamiento representan el aspecto dinámico del sistema. Hacen hincapié en 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.
Representación visual: Usuario del personal → Sistema de quejas: Enviar queja Sistema de quejas → Sistema de RR.HH.: Reenviar queja Sistema de RR.HH. → Departamento: Asignar queja Departamento → Sistema de quejas: Actualizar resolución Sistema de quejas → Sistema de retroalimentación: Solicitar retroalimentación Sistema de retroalimentación → Usuario del personal: Proporcionar retroalimentación Usuario del personal → Sistema de retroalimentación: Enviar retroalimentación Esta descripción se puede utilizar para dibujar un diagrama de secuencia utilizando herramientas como Lucidchart, Draw.io o cualquier software de diagrama UML. El diagrama tendría actores en el lado izquierdo, con flechas que indican la secuencia de acciones e interacciones entre sistemas y actores como se describe en Diagrama de secuencia drow Los diagramas de secuencia deben dibujarse para cada caso de uso para mostrar cómo los diferentes objetos interactúan entre sí para lograr la funcionalidad del caso de uso.
En UML, un artefacto [1] 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 la implementación y operación de un sistema". [1]
"Entre los ejemplos de artefactos se incluyen archivos de modelos, archivos fuente , scripts y archivos ejecutables binarios , una tabla en un sistema de base de datos , un producto de desarrollo, un documento de procesamiento de textos o un mensaje de correo ". [1]
Los artefactos son las entidades físicas que se implementan en los nodos [1] (es decir, dispositivos y entornos de ejecución). Otros elementos UML, como clases y componentes, se manifiestan primero en artefactos y luego se implementan instancias de estos artefactos. Los artefactos también pueden estar compuestos de otros artefactos.
El Object Management Group (OMG) ha desarrollado una arquitectura de metamodelado para definir el 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 Meta-Objeto Facility 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. 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 denominado estereotipo . Brian Henderson-Sellers y Cesar Gonzalez-Perez lo han criticado por ser insuficiente o insostenible en "Usos y abusos del mecanismo de estereotipo en UML 1.x y 2.0". [29]
En 2013, OMG había comercializado UML para muchos contextos, pero apuntaba principalmente al desarrollo de software con un éxito limitado. [23] [30]
En ocasiones se lo ha tratado como una bala de plata para el diseño , lo que conduce a problemas. El uso incorrecto de UML incluye el uso excesivo (diseñar cada parte del sistema con él, lo cual es innecesario) y suponer que los novatos pueden diseñar con él. [31]
Se considera un lenguaje grande, con muchas construcciones . Algunas personas (incluido Jacobson ) creen que el tamaño de UML dificulta el aprendizaje y, por lo tanto, su adopción. [32]
MS Visual Studio abandonó el soporte para UML en 2016 debido a la falta de uso. [33]
Según Google Trends, UML ha estado en constante declive desde 2004. [34]
