ADLs
U N I PA N A M E R I C A N A
Y E S I C A D A N I E L A VA R G A S E S P I T I A
Y D VA R G A S E @ U N I PA N A M E R I C A N A . E D U . C
O
Propiedades de un ADL
Composición: El lenguaje debe ser tal, que el arquitecto pueda dividir un
sistema complejo en partes más pequeñas de manera jerárquica, o construir
un sistema a partir de los elementos que lo constituyen.
Abstracción: La arquitectura expresa una abstracción que permite
identificar a los distintos elementos en una estructura de alto nivel, así como
su papel en la misma. Esta abstracción es específica, y se diferencia de
otras utilizadas en el desarrollo.
Reutilización: Debemos poder reutilizar componentes, conectores, estilos y
arquitecturas, incluso en un contexto diferente a aquél en el que fueron
definidos.
Configuración: El lenguaje debe separar con claridad la descripción de
elementos individuales y de la de las estructuras en que participen. Esta
característica es fundamental.
Heterogeneidad: El ADL ha de ser independiente del lenguaje en que se
implemente cada uno de los componentes que manipula; se deben de poder
combinar patrones arquitectónicos diferentes en un único sistema complejo.
Análisis: Se deben de poder analizar la estructura, de modo que se puedan
determinar sus propiedades con independencia de una implementación
concreta, así como verificarlos después de cualquier modificación. Esto
puede vincularse al uso de métodos formales que permitan la definición de
arquitecturas sin ambigüedad semántica.
Criterios de Definición de un ADL
Una entidad consistente en cuatro “Cs”: componentes,
conectores, configuraciones y restricciones
(constraints).
Un ADL debe modelar o soportar los siguientes
conceptos:
• Componentes
• Conexiones
• Composición jerárquica, en la que un componente
puede contener una sub-arquitectura completa
• Paradigmas de computación, semánticas,
restricciones y propiedades no funcionales
• Paradigmas de comunicación
• Modelos formales
• Soporte de herramientas para modelado, análisis,
evaluación y verificación
• Composición automática de código aplicativo
Basándose en su experiencia sobre Rapide,
Luckham y Vera [LV95] establecen como
requerimientos:
• Abstracción de componentes
• Abstracción de comunicación
• Integridad de comunicación (sólo los
componentes que están conectados pueden
comunicarse)
• Capacidad de modelar arquitecturas
dinámicas
• Composición jerárquica
• Relatividad (la capacidad de mapear o
relacionar conductas entre arquitecturas)
Componentes
Un componente es una unidad de computación o
almacenamiento de datos
Intuitivamente, corresponden a las cajas de las
descripciones de caja-y-línea de las arquitecturas
de software.
Todos los ADL´s soportan modelado de
componentes
Difieren en la terminología:
• Componente
• Interfaz
• Proceso
Representan los elementos computacionales
primarios de un sistema.
Ejemplos:
Clientes, servidores, filtros, objetos y bases de datos. En
la mayoría de los ADLs los componentes puede exponer
varias interfaces, las cuales definen puntos de interacción
entre un componente y su entorno.
Conectores
Representan interacciones entre componentes.
Es un bloque arquitectural usado para modelar:
–Las interacciones entre componentes
–Las reglas que gobiernan esas interacciones
• Todos los ADL’s suportan modelamiento de
conectores aunque algunos no soportan los
conectores como entidades de primera clase
• Todos los ADL’s suportan al menos un tipo
de interconexión sintáctica
• Los ADL’s usualmente difieren en la terminología
para los conectores:
– Connector
– Connection
– Binding.
• Representan interacciones entre componentes.
Corresponden a las líneas de las descripciones de
caja-y-línea.
• Los conectores también tienen una especie de
interfaz que define los roles entre los componentes
participantes en la interacción.
Ejemplos:
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.
Configuraciones o sistemas
Es un grafo conectado de componentes y
conectores el cual describe la estructura de la
arquitectura.
Las Configuraciones ayudan a asegurar las
propiedades de la arquitectura
–Conectividad
–Concurrencia y Distribución
• Los ADL’s deben modelar las configuraciones
de forma explícita por su definición
• En los ADLs más avanzados la topología del
sistema se define independientemente de los
componentes y conectores que lo conforman.
Pros
–Hace explicita la representación de la
arquitectura logrando ser entendida por
humanos y máquinas
–Permite el análisis de las arquitecturas bajo
diferentes criterios de calidad: Completitud,
Consistencia, Ambigüedad, desempeño.
–Pueden soportar la generación automática de
código
Contras:
–La mayoría de representaciones actuales son
difíciles de analizar y no son soportadas por
aplicaciones comerciales, dado su origen
académico en la mayoría de los casos
– ACME (CMU/USC)
– Rapide (Stanford)
– Wright (CMU)
– Unicon (CMU)
– Aesop (CMU)
– MetaH (Honeywell)
– C2 SADL (UCI)
– SADL (SRI)
– Lileanna
– Modechart
– UML
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
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.
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 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.
UML como un ADL
• Pros:
– Fácil de aprender
– Ampliamente usado en la industria y la academia
– Variedad de herramientas
– Puede abarcar otros ADL’s integrandolos
• Contras:
– Los conectores no son objetos de primera clase
– La notación visual tiene poco soporte para generación
– Relaciones escondidas y ambiguas entre vistas
Detalle de los componentes
• Puede estar hecho de un conjunto interno de
clases, paquetes de clases e interfaces
• Las interfaces exponen los puntos visibles de
entradas a los servicios desde otros componentes
Créditos
• Describing Software Architectures. Gert Florijn.
• Workshop de Arquitectura I/T, Bogotá 2005.
Carlos Bittrich. IBM.
• MDA, Model driven architecture.
Väliohjelmistot - Lea Kutvonen
• OMG’s Model Driven Architecture. Davide
Buscaldi
• Architecture Description Languages: An
Overview. MCC.
• Architecture Description Languages -ADL.
Jukka Harkki.