UML, lenguaje de modelado gráfico

El lenguaje de modelado unificado (UML) es un estándar para la re­pre­se­n­ta­ció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 ga­ra­n­ti­zar así una ar­qui­te­c­tu­ra de in­fo­r­ma­ción es­tru­c­tu­ra­da; por el otro, ayuda a los de­sa­rro­lla­do­res a presentar la de­s­cri­p­ción del sistema de una manera que sea co­m­pre­n­si­ble para quienes están fuera del campo. UML se utiliza pri­n­ci­pa­l­me­n­te en el de­sa­rro­llo de software orientado a objetos. Al ampliar el estándar en la versión 2.0, también es adecuado para vi­sua­li­zar procesos em­pre­sa­ria­les.

Antes de que UML se in­tro­du­je­ra en el de­sa­rro­llo de software, el campo de la pro­gra­ma­ción orientada a objetos (OOP) había crecido. Este estilo de pro­gra­ma­ción se basa en el concepto de que todo es un objeto: los bloques de co­n­s­tru­c­ción de un programa son objetos que in­ter­ac­túan entre sí, los mensajes que se envían de un lado a otro entre los co­m­po­ne­n­tes también constan de objetos. Cada objeto in­di­vi­dual es un ejemplo de su clase superior. La clase misma también actúa como un objeto y también determina el co­m­po­r­ta­mie­n­to de las in­s­ta­n­cias 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 pro­ce­di­mie­n­to o método.

Desde finales de la década de 1980 hasta la de 1990 se de­sa­rro­lló un gran número de métodos y lenguajes para la re­pre­se­n­ta­ción de la pro­gra­ma­ción orientada a objetos. El resultado fue una confusa abu­n­da­n­cia de métodos que apenas eran co­m­pa­ra­bles entre sí. Para uni­fi­car­los, los tres de­sa­rro­lla­do­res James Rumbaugh, Grady Booch e Ivar Jacobson de­ci­die­ron fusionar varios lenguajes exi­s­te­n­tes en un estándar común.

Los tres ya habían creado sus propios métodos de de­sa­rro­llo de software orientado a objetos:

• el método Booch
• la técnica de modelado de objetos (OMT)
• el método de In­ge­nie­ría de Software Orientado a Objetos (OOSE)

Como lenguaje de modelado, UML debía definir la semántica para la re­pre­se­n­ta­ción de estos métodos. Bajo el nombre de "Socios UML", los de­sa­rro­lla­do­res co­me­n­za­ron a trabajar con un equipo para completar UML en 1996. Luego se lo en­tre­ga­ron a la Object Ma­na­ge­me­nt Group (OMG), que introdujo la versión 1.1 de Unified Modeling Language como estándar en 1997.

No sa­ti­s­fe­chos, los de­sa­rro­lla­do­res crearon un grupo de trabajo para mejorar el lenguaje a través de múltiples versiones. Las críticas exi­s­te­n­tes incluían una semántica imprecisa e in­ne­ce­sa­ria­me­n­te compleja, la falta de ada­p­ta­bi­li­dad y una es­ta­n­da­ri­za­ción inade­cua­da. Por lo tanto, se llevó a cabo una revisión a fondo. El resultado fue fi­na­l­me­n­te UML 2.0, que definió el nuevo estándar en 2005. La versión 2.4.1 co­n­s­ti­tu­ye la base de la no­r­ma­li­za­ción ISO 19505-1 (In­frae­s­tru­c­tu­ra) y 19505-2 (Su­pe­re­s­tru­c­tu­ra) 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 in­ter­ac­cio­nes entre objetos dentro de un sistema. Su extensa po­pu­la­ri­dad se debe pro­ba­ble­me­n­te a la fuerte in­flue­n­cia que ejercen los miembros del OMG (IBM, Microsoft y HP entre otros). La semántica es­tru­c­tu­ra­da hace el resto. Los diagramas UML se utilizan para re­pre­se­n­tar los si­guie­n­tes co­m­po­ne­n­tes del sistema:

• Objetos in­di­vi­dua­les (elementos básicos)
• Clases (combina elementos con las mismas pro­pie­da­des)
• Re­la­cio­nes entre objetos (jerarquía y co­m­po­r­ta­mie­n­to/co­mu­ni­ca­ción entre objetos)
• Actividad (co­m­bi­na­ción compleja de acciones/módulos de co­m­po­r­ta­mie­n­to)
• In­ter­ac­cio­nes entre objetos e in­te­r­fa­ces

El gráfico superior muestra el me­ta­mo­de­la­do de UML 2.0. El nivel M0 es el nivel básico. Re­pre­se­n­ta objetos reales y concretos y registros de datos in­di­vi­dua­les, por ejemplo, un objeto o un co­m­po­ne­n­te. El nivel M1 comprende todos los modelos que describen y es­tru­c­tu­ran los datos del nivel M0. Estos son diagramas UML como el Diagrama de Actividad o el Diagrama de Paquete (explicado a co­n­ti­nua­ción). Para definir la es­tru­c­tu­ra de estos modelos, los me­ta­mo­de­los de nivel M2 definen las es­pe­ci­fi­ca­cio­nes y la semántica de los elementos del modelo.

Si deseas crear un diagrama UML co­m­pre­n­si­ble, necesitas conocer el me­ta­mo­de­lo UML y sus reglas. El nivel más alto, M3, es un me­ta­mo­de­lo del me­ta­mo­de­lo. El me­n­cio­na­do Meta Object Facility trabaja a un nivel abstracto que define los me­ta­mo­de­los. Este nivel se define a sí mismo, porque de lo contrario surgirían me­ta­ni­ve­les más altos.

UML (nivel M2) define las reglas de su propia semántica. Las unidades de lenguaje son términos definidos en la su­pe­re­s­tru­c­tu­ra UML 2.0. Esto permite una re­pre­se­n­ta­ción formal que todos los pa­r­ti­ci­pa­n­tes pueden entender. Las unidades li­n­güí­s­ti­cas, en inglés language units, abstraen objetos y procesos de es­tru­c­tu­ra y fu­n­cio­na­mie­n­to similares y les dan una forma vi­sua­l­me­n­te re­pre­se­n­ta­ble. Según el nivel je­rá­r­qui­co dentro del modelo, los elementos asumen tareas más es­pe­cia­li­za­das o definen más es­tre­cha­me­n­te otros elementos.

Clase: como unidad li­n­güí­s­ti­ca, las clases son un aspecto central de UML. Definen lo que co­n­s­ti­tu­ye una clase y cómo las clases in­ter­ac­túan entre sí. Esta language unit tiene cuatro niveles, que van desde elementos simples hasta re­la­cio­nes más complejas:

• Núcleo (describe elementos de la in­frae­s­tru­c­tu­ra UML 2.0 como paquetes, espacios de nombres, atributos, etc.)
• As­so­cia­tio­n­Cla­s­ses (define clases de aso­cia­ción)
• In­te­r­fa­ces (define las in­te­r­fa­ces)
• Po­we­r­t­y­pes (clase cuyas in­s­ta­n­cias son subclases dentro de esta clase)

Co­m­po­ne­n­te: los co­m­po­ne­n­tes son elementos que separan su contenido del sistema externo. Solo existe una conexión con el exterior a través de in­te­r­fa­ces o puertos. Un conector de co­m­po­si­ción establece una conexión con otro co­m­po­ne­n­te a través de la interfaz. El conector de de­le­ga­ción une los elementos in­te­rio­res con una interfaz en el borde exterior. Los co­m­po­ne­n­tes son modulares e in­te­r­ca­m­bia­bles.

Es­tru­c­tu­ra de la co­m­po­si­ción: la es­tru­c­tu­ra de la co­m­po­si­ción de la unidad de lenguaje describe los elementos, que están blindados como co­m­po­ne­n­tes hacia adentro y hacia afuera. Solo los puertos conectan el contenido con el sistema externo. Los llamados cla­si­fi­ca­do­res en­ca­p­su­la­dos consisten en elementos llamados partes. Las piezas se comunican a través de co­ne­c­to­res.

Perfil: un perfil configura UML 2.0 para ne­ce­si­da­des es­pe­cí­fi­cas. Los términos ab­s­tra­c­tos como actividad u objeto deben ser es­pe­ci­fi­ca­dos para algunos proyectos con el fin de aumentar la co­m­pre­n­sión. La semántica y las no­ta­cio­nes que están colocadas en lugares sueltos se pueden adaptar con un perfil.

Modelo: el modelo comprende todos los elementos ne­ce­sa­rios para presentar una visión es­pe­cí­fi­ca de la es­tru­c­tu­ra o el co­m­po­r­ta­mie­n­to de un sistema. Esto también incluye las in­flue­n­cias externas, como los actores.

Acción: cuando se trata de re­pre­se­n­tar el co­m­po­r­ta­mie­n­to, las acciones son de im­po­r­ta­n­cia 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 re­la­cio­nes de objetos
• Manipular ca­ra­c­te­rí­s­ti­cas es­tru­c­tu­ra­les
• Acciones de llamada
• Generar valores
• Acciones sobre objetos
• Recibir eventos

Co­m­po­r­ta­mie­n­to: la unidad de lenguaje Co­m­po­r­ta­mie­n­to se refiere a la mo­de­li­za­ción de aspectos dinámicos dentro de un sistema. Consta de tres es­pe­ci­fi­ca­cio­nes:

• Actividad: las acciones in­ter­ac­túan a través flujos de datos y control. Esto resulta en un sistema complejo de co­m­po­r­ta­mie­n­tos, las ac­ti­vi­da­des.
• In­ter­ac­ción: este me­ta­mo­de­lo describe cómo se in­te­r­ca­m­bian 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 me­ta­mo­de­lo muestra tanto estados (si­tua­cio­nes con pro­pie­da­des in­mu­ta­bles) como se­mie­s­ta­dos (estados sin asi­g­na­ción de valor) y sus tra­n­si­cio­nes. Los objetos de un estado pueden asignarse a acciones o ac­ti­vi­da­des.

Di­s­tri­bu­ción: una red está formada por objetos que están co­ne­c­ta­dos entre sí en mallas. Se da un caso especial de uso si estos elementos re­pre­se­n­tan software eje­cu­ta­ble o ar­te­fa­c­tos. Estos ar­te­fa­c­tos se ejecutan en entornos de ejecución o di­s­po­si­ti­vos cla­si­fi­ca­dos como nodos por UML 2.0. Por lo tanto, el artefacto depende del nodo. La di­s­tri­bu­ción re­pre­se­n­ta esta relación de de­pe­n­de­n­cia que surge durante la in­s­ta­la­ción.

Apli­ca­ción: el caso de uso (como unidad de idioma) re­pre­se­n­ta los re­qui­si­tos del sistema. El actor (una persona o un sistema) es un elemento que describe quién o qué debe realizar una actividad concreta uti­li­za­n­do el sistema. El sistema también puede ser una clase o un co­m­po­ne­n­te y, por lo tanto, se describe como un tema. El caso de uso (como elemento modelo) si­m­ple­me­n­te indica que se espera un co­m­po­r­ta­mie­n­to que sea visible para el mundo exterior, pero no suele re­pre­se­n­tar qué acciones co­n­cre­ta­me­n­te. Dentro de una de­s­cri­p­ción de co­m­po­r­ta­mie­n­to, el modelado asigna los re­qui­si­tos de­ta­lla­dos al caso de uso.

Flujos de in­fo­r­ma­ción: esta unidad de lenguaje UML describe los elementos unidad de in­fo­r­ma­ción y flujo de in­fo­r­ma­ción. Estos elementos del modelo son técnicas ab­s­tra­c­tas de de­s­cri­p­ción del co­m­po­r­ta­mie­n­to que pueden estar muy orie­n­ta­das al detalle, como ac­ti­vi­da­des o in­ter­ac­cio­nes. Esta re­pre­se­n­ta­ción si­m­pli­fi­ca­da permite el uso universal de estos elementos de modelado en todos los tipos de diagramas UML. Por lo tanto, a di­fe­re­n­cia de la clase, la unidad de in­fo­r­ma­ción nunca se describe con más detalle por atributos ni se incluye en los métodos. Por lo tanto, el flujo de in­fo­r­ma­ción también conecta todos los elementos posibles que in­te­r­ca­m­bian cualquier tipo de in­fo­r­ma­ción entre sí.

El lenguaje de modelado define 14 tipos de diagramas que se dividen en dos ca­te­go­rías. Las pri­n­ci­pa­les ca­te­go­rías de es­tru­c­tu­ra y co­m­po­r­ta­mie­n­to re­pre­se­n­tan los conceptos básicos re­pre­se­n­ta­dos por los diagramas UML. Dentro del grupo de diagramas de co­m­po­r­ta­mie­n­to, UML es­pe­ci­fi­ca la su­b­ca­te­go­ría de diagramas de in­ter­ac­ción. Existe una cuarta es­pe­ci­fi­ca­ción parcial desde UML 2.0. Determina el diseño de los diagramas del modelo.

• Diagrama de di­s­tri­bu­ción: el diagrama de di­s­tri­bu­ción modela la di­s­tri­bu­ción física de los ar­te­fa­c­tos en nodos. Los nodos pueden ser hardware (device nodes), que puede pro­po­r­cio­nar memoria, o software (execution en­vi­ro­n­me­nt nodes), que pro­po­r­cio­na un entorno para ejecutar procesos. Se re­pre­se­n­tan como cuboides tri­di­me­n­sio­na­les. Los ar­te­fa­c­tos se dibujan como re­c­tá­n­gu­los co­n­te­nie­n­do el nombre del archivo. Para di­s­ti­n­gui­r­lo de una clase, añade el es­te­reo­ti­po <<artefact>>. El diagrama es adecuado para vi­sua­li­zar de­pe­n­de­n­cias entre nodos y ar­te­fa­c­tos, las llamadas re­la­cio­nes de di­s­tri­bu­ción.
   
• Gráfica de perfil: los diagramas de perfil se utilizan a nivel de me­ta­mo­de­lo. Se utilizan para asignar un es­te­reo­ti­po a las clases o un perfil a los paquetes. En el metanivel tienes la po­si­bi­li­dad de adaptar el modelo para otra pla­ta­fo­r­ma o dominio. Por ejemplo, si re­s­tri­n­ges la semántica UML dentro de un perfil, tra­n­s­fie­res las es­pe­ci­fi­ca­cio­nes a las clases su­bo­r­di­na­das.

• Diagrama de ac­ti­vi­da­des: las ac­ti­vi­da­des consisten en una red de acciones que se re­la­cio­nan entre sí mediante flujos de datos y de control. Mientras que el Diagrama de casos de uso muestra los re­qui­si­tos del sistema, el Diagrama de ac­ti­vi­da­des muestra cómo funcionan estos casos de uso. En este tipo de diagrama, por ejemplo, el token juega un papel im­po­r­ta­n­te: 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, re­pre­se­n­ta un conjunto finito de estados en un sistema. Si se cumple una condición definida en el sistema (se detona un des­en­ca­de­na­n­te), se produce una situación co­rre­s­po­n­die­n­te. Esto puede incluir ac­ti­vi­da­des o in­ter­ac­cio­nes. Bajo UML 2.0, un estado re­pre­se­n­ta esta situación. Los estados se co­n­si­de­ran como nodos (inglés: vértices) y se muestran como re­c­tá­n­gu­los con esquinas re­do­n­dea­das. Además, el diagrama de máquina de estados modela las tra­n­si­cio­nes de un estado (nodo fuente) a otro (nodo destino). Los modelos UML presentan las tra­n­si­cio­nes de estado como bordes. Las acciones son la última piedra angular. Se asignan es­pe­ci­fi­ca­cio­nes de co­m­po­r­ta­mie­n­to al estado.

El co­m­po­r­ta­mie­n­to está ligado a ciertas si­tua­cio­nes o eventos. El diagrama de máquina de estados UML tiene 4 es­pe­ci­fi­ca­cio­nes:

• Co­m­po­r­ta­mie­n­to de entrada (entry behavior)
• Co­m­po­r­ta­mie­n­to en el estado (doA­c­ti­vi­ty)
• Co­m­po­r­ta­mie­n­to que ocurre en caso de un evento (event behavior)
• Co­m­po­r­ta­mie­n­to de salida (exit behavior)

Además, un estado puede ser in­te­rru­m­pi­do y co­n­ti­nua­do en el mismo punto. Esta propiedad se llama estado de la historia.

• Diagrama de in­ter­ac­ción: el nuevo diagrama de in­ter­ac­ción añadido a UML 2.0 ayuda a mostrar un sistema muy complejo primero en un esquema apro­xi­ma­do, si un diagrama de in­ter­ac­ción normal se vuelve demasiado confuso. Un diagrama de secuencia, por ejemplo, es adecuado para la vi­sua­li­za­ción detallada. El diagrama UML es similar al diagrama de actividad con nodos. Re­pre­se­n­ta los flujos de control entre in­ter­ac­cio­nes. La di­fe­re­n­cia con el diagrama de actividad es que un diagrama de in­ter­ac­ción completo puede anidarse dentro de nodos que re­pre­se­n­tan ac­ti­vi­da­des. Estos nidos se pueden mostrar di­re­c­ta­me­n­te en el diagrama (en línea) o se puede hacer re­fe­re­n­cia (palabra clave: ref, del inglés reference) al modelo, que se muestra en detalle en otra parte.

El siguiente resumen muestra las ca­te­go­rías su­pe­rio­res y las posibles apli­ca­cio­nes de los tipos de diagrama in­di­vi­dua­les en forma abreviada. Si deseas re­pre­se­n­tar vi­sua­l­me­n­te un sistema de software orientado a modelos, un caso de uso en la economía, etc., debes se­le­c­cio­nar uno de los tipos de diagrama UML de antemano de acuerdo con la re­co­me­n­da­ción del Grupo de Trabajo de UML. Solo entonces vale la pena elegir una de las muchas he­rra­mie­n­tas UML, ya que estos a menudo pre­s­cri­ben un cierto método. A co­n­ti­nua­ción, crea el diagrama UML.