Utilizar UML como un Architecture Description Language

Introducción

UML tiene muchos diagramas que se pueden utilizar para describir un ADL.
Es altamente deseable el uso de UML, por el soporte de las herramientas, conocimientos y procesos de los recursos, costumbre de uso, etc.
Existen algunas maneras de usar UML como un ADL:
Extender UML con MOF (Meta Object Facility)
Usar UML con extensiones OCL (Object Constraint Language)
Utilizar UML básico.
Se ve en este documento como adaptar UML para que pueda usarse como un ADL.
Entonces, primero se da una introducción a que forma un ADL, y luego se describe como relacionar los conceptos con UML 2.0, para poder utilizarlo para documentar una arquitectura.

ADL
UN ADL es un lenguaje descriptivo de modelado que se focaliza en la estructura de alto nivel de la aplicación antes que en los detalles de implementación de sus módulos concretos.
No existe hasta hoy una definición consensuada y unívoca de ADL, pero comúnmente se acepta que un ADL debe proporcionar un modelo explícito de componentes, conectores y sus respectivas configuraciones. Se estima deseable, además, que un ADL suministre soporte de herramientas para el desarrollo de soluciones basadas en arquitectura y su posterior evolución.Los ADLs se remontan a los lenguajes de interconexión de módulos (MIL) de la década de 1970, pero se han comenzado a desarrollar con su denominación actual a partir de 1992 o 1993, poco después de fundada la propia arquitectura de software como especialidad profesional. La definición más simple es la de Tracz que define un ADL como una entidad consistente en cuatro “Cs”: componentes, conectores, configuraciones y restricciones (constraints). Una de las definiciones más tempranas es la de Vestal quien sostiene que un ADL debe modelar o soportar los siguientes conceptos:

Componentes
Representan los elementos computacionales primarios de un sistema. Intuitivamente, corresponden a las cajas de las descripciones de caja-y-línea de las arquitecturas de software. Ejemplos típicos serían clientes, servidores, filtros, objetos, pizarras y bases de datos. En la mayoría de los ADLs los componentes pueden exponer varias interfaces, las cuales definen puntos de interacción entre un componente y su entorno.

Conectores
Representan interacciones entre componentes. Corresponden a las líneas de las descripciones de caja-y-línea. Ejemplos típicos podrían ser tuberías (pipes), llamadas a procedimientos, broadcast de eventos, protocolos cliente-servidor, o conexiones entre una aplicación y un servidor de base de datos. Los conectores también tienen una especie de interfaz que define los roles entre los componentes participantes en la interacción.

Configuraciones o sistemas
Se constituyen como grafos de componentes y conectores. En los ADLs más avanzados la topología del sistema se define independientemente de los componentes y conectores que lo conforman. Los sistemas también pueden ser jerárquicos: componentes y conectores pueden subsumir la representación de lo que en realidad son complejos subsistemas.

Propiedades
Representan información semántica sobre un sistema más allá de su estructura. Distintos ADLs ponen énfasis en diferentes clases de propiedades, pero todos tienen alguna forma de definir propiedades no funcionales, o pueden admitir herramientas complementarias para analizarlas y determinar, por ejemplo, el throughput y la latencia probables, o cuestiones de seguridad, escalabilidad, dependencia de bibliotecas o servicios específicos, configuraciones mínimas de hardware y tolerancia a fallas.

Restricciones
Representan condiciones de diseño que deben acatarse incluso en el caso que el sistema evolucione en el tiempo. Restricciones típicas serían restricciones en los valores posibles de propiedades o en las configuraciones topológicas admisibles. Por ejemplo, el número de clientes que se puede conectar simultáneamente a un servicio.

Estilos
Representan familias de sistemas, un vocabulario de tipos de elementos de diseño y de reglas para componerlos. Ejemplos clásicos serían las arquitecturas de flujo de datos basados en grafos de tuberías (pipes) y filtros, las arquitecturas de pizarras basadas en un espacio de datos compartido, o los sistemas en capas. Algunos estilos prescriben un framework, un estándar de integración de componentes, patrones arquitectónicos o como se lo quiera llamar.

Evolución

Los ADLs deberían soportar procesos de evolución permitiendo derivar subtipos a partir de los componentes e implementando refinamiento de sus rasgos. Sólo unos pocos lo hacen efectivamente, dependiendo para ello de lenguajes que ya no son los de diseño arquitectónico sino los de programación.

Propiedades no funcionales

La especificación de estas propiedades es necesaria para simular la conducta de runtime, analizar la conducta de los componentes, imponer restricciones, mapear implementaciones sobre procesadores determinados, etcétera.

UML

Se describirán los diagramas de UML 2.0 que se utilizarían para documentar las arquitecturas, y de que manera se utilizarían.

Diagrama de estructura compuesta y componentes
Es un diagrama que muestra la estructura interna de un clasificador, incluyendo sus puntos de interacción con otras partes del sistema. Muestra la configuración y las relaciones entre las partes que juntan realizan las tareas del sistema contenedor.
El diagrama de estructura compuesta, esta formado por los siguientes elementos:

• Clase: Es la representación de un objeto (componente), que refleja su estructura y comportamiento dentro del sistema.
• Interfaz: Es una especificación de comportamiento que implementa un contrato a seguir.
• Parte: Son instancias en tiempo de ejecución de una clase o interfaz.
• Puerto: Define la interacción de un componente con su ambiente. Las interfaces expuestas controlan esta interacción.
• Colaboración: Define un conjunto de roles cooperantes y sus conexiones. Se utiliza para mostrar en conjunto una funcionalidad.
• Interfaz expuesta: Es la manera gráfica de demostrar la forma de comunicación del componente (clase, interfaz o parte)
• Conector: Ilustra un enlace de comunicación entre partes para llegar al propósito de la estructura
• Ensamble: oficia de puente entre una interfaz expuesta “requerida” de un componente, con una interfaz expuesta “provista” por otro componente.
• Enlace de rol: Es el mapeo entre los roles internos de una colaboración y las respectivas partes necesarias para implementar una situación específica.
• Representación: indica que una colaboración se usa en un componente
• Ocurrencia: Indica que una colaboración representa a un componente.

El diagrama de componente, esta formado por los siguientes elementos:

• Paquete: Es un contenedor de otros paquetes, componentes, etc. Muy usado para mostrar espacios de nombres o ensamblados.
• Componente: Es una parte modular de un sistema, cuyo comportamiento se define por sus interfaces requeridas y provistas.
• Clase: Es la representación de un objeto (componente), que refleja su estructura y comportamiento dentro del sistema.
• Interfaz: Es una especificación de comportamiento que implementa un contrato a seguir.
• Objeto: Es una instancia de una clase en tiempo de ejecución
• Puerto: Define la interacción de un componente con su ambiente. Las interfaces expuestas controlan esta interacción.
• Interfaz expuesta: Es la manera gráfica de demostrar la forma de comunicación del componente (clase, interfaz o parte)
• Artefacto: es cualquier pieza física de información usada o producida por un sistema
• Ensamble: oficia de puente entre una interfaz expuesta “requerida” de un componente, con una interfaz expuesta “provista” por otro componente.
• Delegado: Define que componente interno de un componente atiende el pedido a un puerto determinado.

Los usaríamos para modelar el aspecto físico de un sistema. Cada componente puede ser un ejecutable, librerías, archivos de datos o cualquier otro recurso físico que es parte de un sistema.

Diagrama de implementación
Modela la arquitectura en tiempo de ejecución de un sistema. Muestra la configuración de los elementos hardware (nodos), y muestra como los elementos y artefactos software están distribuidos en estos nodos.
El diagrama de implementación esta formado por los siguientes elementos:

• Nodo: Representa un equipo sobre el que se implementará el sistema.
• Componente: Es una parte modular de un sistema, cuyo comportamiento se define por sus interfaces requeridas y provistas.
• Interfaz: Es una especificación de comportamiento que implementa un contrato a seguir.
• Artefacto: es cualquier pieza física de información usada o producida por un sistema.
• Especificación de implementación: Especifica una guia de parámetros de implementación de un artefacto, como ser archivos de configuración o algún componente hardware.
• Paquete: Es un contenedor de otros paquetes, componentes, etc. Muy usado para mostrar espacios de nombres o ensamblados.
• Asociación: Muestra que dos elementos están relacionados.
• Clase Asociación: Es una asociación que también tiene propiedades de clase. No solo conecta dos componentes, sino que especifica un conjunto de características que llevan a la relación.
• Generalización: Indica herencia
• Implementación: es una relación que indica en que nodo se implementa un componente SW o un artefacto
• Manifiesto: es una relación que indica que el fuente de un artefacto encierra la especificación de un componente.
• Dependencia: Indica que un componente (nodo, SW, artefacto, etc.) depende de otro componente.
• Inclusión: Indica que un componente está empaquetado dentro de otro.

Lo usaríamos para mostrar una vista estática de la configuración en tiempo de ejecución de los nodos de procesamiento y los componentes que corren en dichos nodos. Pueden usarse, también, para mostrar las conexiones entre hardware, software y cualquier middleware que se utilice en un sistema.

Diagrama de empaquetamiento
Se usan para reflejar la organización de paquetes y sus elementos.
Esta formado por los siguientes elementos:

• Paquete: Es un contenedor de otros paquetes, componentes, etc. Muy usado para mostrar espacios de nombres o ensamblados.
• Clase: Es la representación de un objeto (componente), que refleja su estructura y comportamiento dentro del sistema.
• Interfaz: Es una especificación de comportamiento que implementa un contrato a seguir.
• Objeto: Es una instancia de una clase en tiempo de ejecución
• Tabla: Es una clase estereotipada. Se le puede asignar valores de propiedad de columnas, etc.
• Asociación: Se utiliza para realizar asociaciones entre mas de dos elementos
• Asociado: Asocia dos elementos
• Generalización: Indica herencia de comportamiento o propiedades.
• Composición: Indica que un componente esta formado por otros componentes.
• Agregación: Indica que un componente contiene a otros componentes.
• Clase Asociación: Es una asociación que también tiene propiedades de clase. No solo conecta dos componentes, sino que especifica un conjunto de características que llevan a la relación.
• Ensamble: oficia de puente entre una interfaz expuesta “requerida” de un componente, con una interfaz expuesta “provista” por otro componente.
• Dependencia: Indica que un componente (nodo, SW, artefacto, etc.) depende de otro componente.
• Inclusión: Indica que un componente esta dentro de otro componente.
• Merge: Indica que el contenido de un paquete esta incluido en el de otro paquete, en el momento de implementar
• Importación: Indica que el contenido de un paquete se importa a otro paquete.
  Lo usaríamos para mostrar como se relacionan los distintos elementos componentes de un sistema.

Diagrama de estados
Modela el comportamiento de un objeto, especificando la secuencia de estados por los que pasa un objeto como respuesta a eventos ocasionados sobre el mismo, o por el mismo.
El diagrama esta formado por los siguientes elementos:

• Estado: Indica una situación que se mantiene por una condición invariante, que puede ser estática, o dinámica.
• Sub máquina: Es un puntero a un diagrama de estados hijo.
• Inicial: Indica donde comienza el flujo de estados.
• Final: Indica donde termina el flujo de estados
• Historial: Se utiliza para volver a un estado anterior. Hay dos tipos: Bajo, representa el estado más reciente; y Profundo: Representa la configuración activa mas reciente.
• Sincronización: Indica que caminos concurrentes del diagrama corren sincrónicamente.
• Objeto. Es una instancia de una clase en tiempo de ejecución.
• Decisión: Indica un punto de progresión condicionada. Dada una condición, según el valor retornado, se tomará un camino u otro.
• Unión: Se usa para unir en un mismo punto a varios caminos
• Fork / Join: Se usa para separar el flujo en distintos caminos, y / o unir el flujo de varios caminos en uno.
• Transición: Es el movimiento lógico de un estado a otro.
• Flujo de Objeto: Indica un flujo o transición de estado.Lo usaríamos para mostrar como un componente va cambiando de estados, cuales son los estados esperados que tenga, y mediante que evento (interno o externo), se modifica su estado.

Diagrama temporal
Se utilizan para mostrar el cambio de estado o valor de uno o mas elementos, a través del tiempo. También puede mostrar la interacción entre eventos y el tiempo y duración constantes que los dominan.
El diagrama esta compuesto por los siguientes elementos:

• Línea de estado: Es el camino que un objeto toma a través de una medida de tiempo. Sigue transiciones discretas entre los distintos estados.
• Línea de valor: Es el camino que un objeto toma a través de una medida de tiempo. Sigue transiciones continuas entre los distintos estados.
• Etiqueta de mensaje: Es una forma de denotar mensajes entre líneas de vida.
• Fin de mensaje: Fin de un estado o valor.
• Puerta del diagrama: Punto en el que se transmiten los mensajes
• Mensaje: Links de comunicación entre líneas de vida

Lo usaríamos en el caso de que algún componente de un sistema cambie su estado o valores mediante el factor tiempo (una tarea que tenga que levantarse cada x tiempo).

Relación entre los diagramas de UML y ADL
A continuación se describe que relación tiene cada punto de un ADL con los diagramas UML, y que le falta a UML para poder ser utilizado 100% como un ADL.

Los componentes de ADL se relacionan con los nodos, componentes, clases, interfaces y paquetes de UML.

Los conectores de ADL se relacionan con los puertos, interfaces externas y relaciones de UML.

Las configuraciones o sistemas de ADL se relacionan con los diagramas de componentes e implementación de UML.

Las propiedades de ADL se relacionan con las dependencias que se pueden ver en el diagrama de implementación o empaquetamiento, y cada uno de los componentes tienen sus propiedades internas, aunque no exactamente como lo utilizaríamos.

Las restricciones de ADL se relacionan con las restricciones de dependencia de UML, o con los requisitos funcionales o no funcionales.

Los estilos de ADL estan fuera de UML, son patrones o estilos arquitectónicos.

La evolución de ADL son los refinamientos de los diagramas UML

Las propiedades no funcionales de ADL son las propiedades de los componentes o los requerimientos no funcionales de UML.

Conclusiones
Por lo presentado en este documento, se puede utilizar UML 2.0 para documentar arquitecturas, quedando por definir, para tener un ADL completo:

• Completar las propiedades de UML
• Ver como implementar las restricciones (podría ser con estereotipos, simulando el specification del diagrama de implementación)
• Como indicar las propiedades no funcionales.