UML, lenguaje de modelado gráfico

El lenguaje de modelado unificado (UML) es un estándar para la representación visual de objetos, estados y procesos dentro de un sistema. Por un lado, el lenguaje de modelado puede servir de modelo para un proyecto y garantizar así una arquitectura de información estructurada; por el otro, ayuda a los desarrolladores a presentar la descripción del sistema de una manera que sea comprensible para quienes están fuera del campo. UML se utiliza principalmente en el desarrollo de software orientado a objetos. Al ampliar el estándar en la versión 2.0, también es adecuado para visualizar procesos empresariales.

Antes de que UML se introdujera en el desarrollo de software, el campo de la programación orientada a objetos (OOP) había crecido. Este estilo de programación se basa en el concepto de que todo es un objeto: los bloques de construcción de un programa son objetos que interactúan entre sí, los mensajes que se envían de un lado a otro entre los componentes también constan de objetos. Cada objeto individual es un ejemplo de su clase superior. La clase misma también actúa como un objeto y también determina el comportamiento de las instancias de objetos que contiene. Los objetos consisten en datos y código. El objeto organiza los datos en campos, también llamados atributos. El código determina su procedimiento o método.

Desde finales de la década de 1980 hasta la de 1990 se desarrolló un gran número de métodos y lenguajes para la representación de la programación orientada a objetos. El resultado fue una confusa abundancia de métodos que apenas eran comparables entre sí. Para unificarlos, los tres desarrolladores James Rumbaugh, Grady Booch e Ivar Jacobson decidieron fusionar varios lenguajes existentes en un estándar común.

Los tres ya habían creado sus propios métodos de desarrollo de software orientado a objetos:

• el método Booch
• la técnica de modelado de objetos (OMT)
• el método de Ingeniería de Software Orientado a Objetos (OOSE)

Como lenguaje de modelado, UML debía definir la semántica para la representación de estos métodos. Bajo el nombre de "Socios UML", los desarrolladores comenzaron a trabajar con un equipo para completar UML en 1996. Luego se lo entregaron a la Object Management Group (OMG), que introdujo la versión 1.1 de Unified Modeling Language como estándar en 1997.

No satisfechos, los desarrolladores crearon un grupo de trabajo para mejorar el lenguaje a través de múltiples versiones. Las críticas existentes incluían una semántica imprecisa e innecesariamente compleja, la falta de adaptabilidad y una estandarización inadecuada. Por lo tanto, se llevó a cabo una revisión a fondo. El resultado fue finalmente UML 2.0, que definió el nuevo estándar en 2005. La versión 2.4.1 constituye la base de la normalización ISO 19505-1 (Infraestructura) y 19505-2 (Superestructura) de 2012. La UML-Version 2.5.1 apareció en diciembre de 2017.

El Lenguaje Unificado de Modelado es referido por algunos como la lingua franca entre los lenguajes de modelado. Como se mencionó al principio, el UML visualiza los estados y las interacciones entre objetos dentro de un sistema. Su extensa popularidad se debe probablemente a la fuerte influencia que ejercen los miembros del OMG (IBM, Microsoft y HP entre otros). La semántica estructurada hace el resto. Los diagramas UML se utilizan para representar los siguientes componentes del sistema:

• Objetos individuales (elementos básicos)
• Clases (combina elementos con las mismas propiedades)
• Relaciones entre objetos (jerarquía y comportamiento/comunicación entre objetos)
• Actividad (combinación compleja de acciones/módulos de comportamiento)
• Interacciones entre objetos e interfaces

El gráfico superior muestra el metamodelado de UML 2.0. El nivel M0 es el nivel básico. Representa objetos reales y concretos y registros de datos individuales, por ejemplo, un objeto o un componente. El nivel M1 comprende todos los modelos que describen y estructuran los datos del nivel M0. Estos son diagramas UML como el Diagrama de Actividad o el Diagrama de Paquete (explicado a continuación). Para definir la estructura de estos modelos, los metamodelos de nivel M2 definen las especificaciones y la semántica de los elementos del modelo.

Si deseas crear un diagrama UML comprensible, necesitas conocer el metamodelo UML y sus reglas. El nivel más alto, M3, es un metamodelo del metamodelo. El mencionado Meta Object Facility trabaja a un nivel abstracto que define los metamodelos. Este nivel se define a sí mismo, porque de lo contrario surgirían metaniveles más altos.

UML (nivel M2) define las reglas de su propia semántica. Las unidades de lenguaje son términos definidos en la superestructura UML 2.0. Esto permite una representación formal que todos los participantes pueden entender. Las unidades lingüísticas, en inglés language units, abstraen objetos y procesos de estructura y funcionamiento similares y les dan una forma visualmente representable. Según el nivel jerárquico dentro del modelo, los elementos asumen tareas más especializadas o definen más estrechamente otros elementos.

Clase: como unidad lingüística, las clases son un aspecto central de UML. Definen lo que constituye una clase y cómo las clases interactúan entre sí. Esta language unit tiene cuatro niveles, que van desde elementos simples hasta relaciones más complejas:

• Núcleo (describe elementos de la infraestructura UML 2.0 como paquetes, espacios de nombres, atributos, etc.)
• AssociationClasses (define clases de asociación)
• Interfaces (define las interfaces)
• Powertypes (clase cuyas instancias son subclases dentro de esta clase)

Componente: los componentes son elementos que separan su contenido del sistema externo. Solo existe una conexión con el exterior a través de interfaces o puertos. Un conector de composición establece una conexión con otro componente a través de la interfaz. El conector de delegación une los elementos interiores con una interfaz en el borde exterior. Los componentes son modulares e intercambiables.

Estructura de la composición: la estructura de la composición de la unidad de lenguaje describe los elementos, que están blindados como componentes hacia adentro y hacia afuera. Solo los puertos conectan el contenido con el sistema externo. Los llamados clasificadores encapsulados consisten en elementos llamados partes. Las piezas se comunican a través de conectores.

Perfil: un perfil configura UML 2.0 para necesidades específicas. Los términos abstractos como actividad u objeto deben ser especificados para algunos proyectos con el fin de aumentar la comprensión. La semántica y las notaciones que están colocadas en lugares sueltos se pueden adaptar con un perfil.

Modelo: el modelo comprende todos los elementos necesarios para presentar una visión específica de la estructura o el comportamiento de un sistema. Esto también incluye las influencias externas, como los actores.

Acción: cuando se trata de representar el comportamiento, las acciones son de importancia central. Los valores se aceptan a través de los pines de entrada y se envían a los pines de salida. Estos son los grupos temáticos que UML define para las acciones:

• Manipular objetos
• Manipular relaciones de objetos
• Manipular características estructurales
• Acciones de llamada
• Generar valores
• Acciones sobre objetos
• Recibir eventos

Comportamiento: la unidad de lenguaje Comportamiento se refiere a la modelización de aspectos dinámicos dentro de un sistema. Consta de tres especificaciones:

• Actividad: las acciones interactúan a través flujos de datos y control. Esto resulta en un sistema complejo de comportamientos, las actividades.
• Interacción: este metamodelo describe cómo se intercambian los flujos de mensajes entre objetos, cuándo se envía un mensaje a qué objeto y qué otros elementos se ven afectados por él.
• Estado de las máquinas: en un diagrama de estado, este modelo de metamodelo muestra tanto estados (situaciones con propiedades inmutables) como semiestados (estados sin asignación de valor) y sus transiciones. Los objetos de un estado pueden asignarse a acciones o actividades.

Distribución: una red está formada por objetos que están conectados entre sí en mallas. Se da un caso especial de uso si estos elementos representan software ejecutable o artefactos. Estos artefactos se ejecutan en entornos de ejecución o dispositivos clasificados como nodos por UML 2.0. Por lo tanto, el artefacto depende del nodo. La distribución representa esta relación de dependencia que surge durante la instalación.

Aplicación: el caso de uso (como unidad de idioma) representa los requisitos del sistema. El actor (una persona o un sistema) es un elemento que describe quién o qué debe realizar una actividad concreta utilizando el sistema. El sistema también puede ser una clase o un componente y, por lo tanto, se describe como un tema. El caso de uso (como elemento modelo) simplemente indica que se espera un comportamiento que sea visible para el mundo exterior, pero no suele representar qué acciones concretamente. Dentro de una descripción de comportamiento, el modelado asigna los requisitos detallados al caso de uso.

Flujos de información: esta unidad de lenguaje UML describe los elementos unidad de información y flujo de información. Estos elementos del modelo son técnicas abstractas de descripción del comportamiento que pueden estar muy orientadas al detalle, como actividades o interacciones. Esta representación simplificada permite el uso universal de estos elementos de modelado en todos los tipos de diagramas UML. Por lo tanto, a diferencia de la clase, la unidad de información nunca se describe con más detalle por atributos ni se incluye en los métodos. Por lo tanto, el flujo de información también conecta todos los elementos posibles que intercambian cualquier tipo de información entre sí.

El lenguaje de modelado define 14 tipos de diagramas que se dividen en dos categorías. Las principales categorías de estructura y comportamiento representan los conceptos básicos representados por los diagramas UML. Dentro del grupo de diagramas de comportamiento, UML especifica la subcategoría de diagramas de interacción. Existe una cuarta especificación parcial desde UML 2.0. Determina el diseño de los diagramas del modelo.

• Diagrama de distribución: el diagrama de distribución modela la distribución física de los artefactos en nodos. Los nodos pueden ser hardware (device nodes), que puede proporcionar memoria, o software (execution environment nodes), que proporciona un entorno para ejecutar procesos. Se representan como cuboides tridimensionales. Los artefactos se dibujan como rectángulos conteniendo el nombre del archivo. Para distinguirlo de una clase, añade el estereotipo <<artefact>>. El diagrama es adecuado para visualizar dependencias entre nodos y artefactos, las llamadas relaciones de distribución.
   
• Gráfica de perfil: los diagramas de perfil se utilizan a nivel de metamodelo. Se utilizan para asignar un estereotipo a las clases o un perfil a los paquetes. En el metanivel tienes la posibilidad de adaptar el modelo para otra plataforma o dominio. Por ejemplo, si restringes la semántica UML dentro de un perfil, transfieres las especificaciones a las clases subordinadas.

• Diagrama de actividades: las actividades consisten en una red de acciones que se relacionan entre sí mediante flujos de datos y de control. Mientras que el Diagrama de casos de uso muestra los requisitos del sistema, el Diagrama de actividades muestra cómo funcionan estos casos de uso. En este tipo de diagrama, por ejemplo, el token juega un papel importante: en los procesos paralelos, es un marcador para el cual se priorizan los procesos y, por lo tanto, se reciben los recursos (por ejemplo, la memoria de trabajo).
   
• Diagrama de máquina de estados: una máquina de estados, también llamada autómata finito, representa un conjunto finito de estados en un sistema. Si se cumple una condición definida en el sistema (se detona un desencadenante), se produce una situación correspondiente. Esto puede incluir actividades o interacciones. Bajo UML 2.0, un estado representa esta situación. Los estados se consideran como nodos (inglés: vértices) y se muestran como rectángulos con esquinas redondeadas. Además, el diagrama de máquina de estados modela las transiciones de un estado (nodo fuente) a otro (nodo destino). Los modelos UML presentan las transiciones de estado como bordes. Las acciones son la última piedra angular. Se asignan especificaciones de comportamiento al estado.

El comportamiento está ligado a ciertas situaciones o eventos. El diagrama de máquina de estados UML tiene 4 especificaciones:

• Comportamiento de entrada (entry behavior)
• Comportamiento en el estado (doActivity)
• Comportamiento que ocurre en caso de un evento (event behavior)
• Comportamiento de salida (exit behavior)

Además, un estado puede ser interrumpido y continuado en el mismo punto. Esta propiedad se llama estado de la historia.

• Diagrama de interacción: el nuevo diagrama de interacción añadido a UML 2.0 ayuda a mostrar un sistema muy complejo primero en un esquema aproximado, si un diagrama de interacción normal se vuelve demasiado confuso. Un diagrama de secuencia, por ejemplo, es adecuado para la visualización detallada. El diagrama UML es similar al diagrama de actividad con nodos. Representa los flujos de control entre interacciones. La diferencia con el diagrama de actividad es que un diagrama de interacción completo puede anidarse dentro de nodos que representan actividades. Estos nidos se pueden mostrar directamente en el diagrama (en línea) o se puede hacer referencia (palabra clave: ref, del inglés reference) al modelo, que se muestra en detalle en otra parte.

El siguiente resumen muestra las categorías superiores y las posibles aplicaciones de los tipos de diagrama individuales en forma abreviada. Si deseas representar visualmente un sistema de software orientado a modelos, un caso de uso en la economía, etc., debes seleccionar uno de los tipos de diagrama UML de antemano de acuerdo con la recomendación del Grupo de Trabajo de UML. Solo entonces vale la pena elegir una de las muchas herramientas UML, ya que estos a menudo prescriben un cierto método. A continuación, crea el diagrama UML.