Lenguaje de modelado unificado
El lenguaje de modelado unificado (UML) es un lenguaje de modelado de desarrollo de propósito general en el campo de la ingeniería de software que pretende proporcionar una forma estándar de visualizar el diseño de un sistema.
La creación de UML fue originalmente motivada por el deseo de estandarizar los diferentes sistemas de notación y enfoques para el diseño de software. Fue desarrollado en Rational Software en 1994–1995, con un mayor desarrollo dirigido por ellos hasta 1996.
En 1997, Object Management Group (OMG) adoptó UML como estándar y, desde entonces, ha sido administrado por esta organización. En 2005, UML también fue publicado por la Organización Internacional de Normalización (ISO) como un estándar ISO aprobado. Desde entonces, el estándar ha sido revisado periódicamente para cubrir la última revisión de UML. 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, a menudo incluyen elementos de UML.
Historia
Antes de UML 1.0
UML ha estado evolucionando desde la segunda mitad de la década de 1990 y tiene sus raíces en los métodos de programación orientados 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 orientado a objetos.
Originalmente se basa 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.
Rational Software Corporation contrató a James Rumbaugh de General Electric en 1994 y, después de eso, la empresa se convirtió en la fuente de dos de los enfoques de modelado orientado a objetos más populares del momento: la técnica de modelado de objetos (OMT) de Rumbaugh y El método de Grady Booch. Pronto fueron asistidos en sus esfuerzos por 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.
UML 1.x
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 Unified Modeling Language (UML) y proponerla a el Grupo de Gestión de Objetos (OMG) para la estandarización. La asociación también contenía partes interesadas adicionales (por ejemplo, HP, DEC, IBM y Microsoft). Los socios de UML' El borrador de UML 1.0 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.
Después del primer lanzamiento, se formó un grupo de trabajo para mejorar el lenguaje, que lanzó varias revisiones menores, 1.3, 1.4 y 1.5.
Se ha observado que los estándares que produjo (así como el estándar original) son ambiguos e inconsistentes.
Notación de cardinalidad
Al igual que con los diagramas de base de datos Chen, Bachman e ISO ER, los modelos de clase están especificados para usar "a través de" cardinalidades, aunque varios autores (Merise, Elmasri & Navathe entre otros) prefieren cardinalidades del mismo lado o "mira aquí" para roles y cardinalidades mínimas y máximas. Investigadores recientes (Feinerer, Dullea et al.) han demostrado que el "look-across" La técnica utilizada por los diagramas UML y ER es menos eficaz 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 búsqueda cruzada como se usa para las asociaciones UML. Hartmann 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 transversal presenta varias dificultades que impiden que la extensión de mecanismos simples asociaciones binarias a n-arias."
UML 2
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 características.
Aunque UML 2.1 nunca se lanzó 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 lanzó formalmente en mayo de 2010. UML 2.4.1 se lanzó formalmente en agosto de 2011. UML 2.5 se lanzó en octubre de 2012 como "En progreso" y se lanzó oficialmente en junio de 2015. La versión formal 2.5.1 se adoptó en diciembre de 2017.
Hay cuatro partes en la especificación UML 2.x:
- La Superestructura que define la notación y semántica para los diagramas y sus elementos modelo
- La infraestructura que define la metamola central en la que se basa la Superestructura
- The Object Constraint Language (OCL) for defining rules for model elements
- El diagrama UML Intercambio que define cómo se intercambian los diagramas UML 2
Hasta UML 2.4.1, las últimas versiones de estos estándares eran:
- UML Superestructura versión 2.4.1
- UML versión 2.4.1
- OCL versión 2.3.1
- UML Versión de intercambio de diagramas 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 ahora son:
- Especificación UML 2.5.1
- Versión 2.4
Continúa siendo actualizado y mejorado por el grupo de trabajo de revisión, que resuelve cualquier problema con el lenguaje.
Diseño
UML ofrece una forma de visualizar los planos arquitectónicos de un sistema en un diagrama, incluidos elementos como:
- cualesquiera actividades (juegos);
- componentes individuales del sistema;
- y cómo pueden interactuar con otros componentes de software;
- cómo funcionará el sistema;
- cómo las entidades interactúan con otras (componentes e interfaces);
- interfaz de usuario externa.
Aunque originalmente estaba destinado a la documentación de diseño orientada a objetos, UML se ha extendido a un conjunto más grande de documentación de diseño (como se indica arriba) y se ha encontrado útil en muchos contextos.
Métodos de desarrollo de software
UML no es un método de desarrollo en sí mismo; 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, el método Booch, Objectory y especialmente RUP, con el que originalmente estaba destinado a usarse cuando comenzó el trabajo en Rational Software.
Modelado
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 necesita cubrir 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:
- Estática (o estructural) vista: enfatiza la estructura estática del sistema utilizando objetos, atributos, operaciones y relaciones. Incluye diagramas de clase y diagramas de estructura compuesta.
- Dinámica (o conductual) vista: enfatiza el comportamiento dinámico del sistema mostrando colaboraciones entre objetos y cambios en los estados internos de objetos. Esta vista incluye diagramas de secuencia, diagramas de actividad y diagramas de máquinas estatales.
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, causado 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.
Diagramas
UML 2 tiene muchos tipos de diagramas, que se dividen en dos categorías. Algunos tipos representan información estructural y el resto representa tipos generales de comportamiento, incluidos algunos que representan diferentes aspectos de interacciones. Estos diagramas se pueden categorizar jerárquicamente como se muestra en el siguiente diagrama de clases:
Todos estos diagramas pueden contener comentarios o notas que explican el uso, la restricción o la intención.
Diagramas de estructura
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.
Diagrama de componentes
Diagrama de clase
Diagramas de comportamiento
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 paso a paso las actividades comerciales y operativas de los componentes de un sistema.
Diagrama de actividad
Use diagrama de caso
Diagramas de interacción
Los diagramas de interacción, un subconjunto de los 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í con respecto a una secuencia de mensajes.
Diagrama de secuencia
Diagrama de comunicación
Metamodelado
El Object Management Group (OMG) ha desarrollado una arquitectura de metamodelado para definir el UML, llamada Meta-Object Facility. MOF está diseñado como una arquitectura de cuatro capas, como se muestra en la imagen de la derecha. Proporciona un modelo meta-meta 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 recurso 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. La última capa es la capa M0 o capa de datos. Se utiliza para describir instancias de tiempo de ejecución del sistema.
El metamodelo se puede ampliar usando un mecanismo llamado estereotipo. Esto ha sido criticado por ser insuficiente/insostenible por Brian Henderson-Sellers y Cesar Gonzalez-Perez en 'Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0'.
Adopción
UML se ha comercializado para muchos contextos.
Se ha tratado, a veces, como una panacea de 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 novatos pueden diseñar con él.
Se considera un lenguaje extenso, con muchas construcciones. Algunas personas (incluyendo a Jacobson) sienten que el tamaño de UML dificulta el aprendizaje (y, por lo tanto, su uso).
Contenido relacionado
Contraseña
Kilobit
OsoCompartir