Maestría en Ingeniería

Curso de Arquitectura de Software

Sesión 7

Fernando Barraza A.

fbarraza@javerianacali.edu.co

Sesión 7

•! Objetivo: Exponer los fundamentos básicos sobre los Lenguajes para Descripción de Arquitecturas de Software (ADL’s)

•! Temas:

–!Que es un ADL

–!ADL’s revisados (ACME, DARWIN, Otros)

–!ADL’s para estilos específicos

–!UML como ADL

Que es un ADL?

•! Es un lenguaje que describe la arquitectura de software de un sistema

•! Los ADL’s se enfocan primordialmente en describir:

–! Los componentes de una arquitectura

–! Las interfaces expuestas por los componentes

–! Los conectores utilizados para acoplar los componente mediante las interfaces

–! Las configuraciones de la arquitectura

•! No es:

–! Un lenguaje de programación

–! Una notación de alto nivel del diseño

–! Un lenguaje de interconexión de módulos (MIL)

–! Una notación orientada a objetos

Porque es importante un ADL?

•! Permite a los desarrolladores abstraerse de detalles innecesarios y enfocarse en lo esencial o “big picture”: Estructura del sistema, protocolos de comunicación de alto nivel, asignación de componentes de software, procesos de desarrollo, etc.

•! Apoya el registro de cambios durante la evolución de la arquitectura de un sistema, lo cual debe guiar la implementación. La arquitectura no debe ser el resultado de la implementación.

•! Desplaza la atención desde las líneas de código a los componentes de software y la estructura para su

interconexión.

Como debe ser un ADL?

•! Debe ser simple, entendible, preferiblemente de sintaxis gráfica, pero no necesariamente con una semántica formalmente definida.

•! Debe ayudar a entender y comunicar los elementos importantes de un sistema de software, modelando explícitamente sus elementos y configuraciones.

•! Algunos ADL’s proveen herramientas para análisis, chequeo, “parsing”, compilación y sintetización de la descripción de la arquitectura objetivo.

•! No está claramente estandarizado el nivel de soporte que un ADL debería dar a los desarrolladores, pero debería proveer una herramienta para desarrollo y evolución basado en la arquitectura.

Componentes de un ADL

•!Definición

–!Un componente es una unidad de computación o almacenamiento de datos

•! Todos los ADL´s soportan modelado de componentes

•!Difieren en la terminología:

–!Componente

–!Interfaz

–!Proceso

Conectores en un ADL

•! Definición: Un Conector 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.

Configuraciones en un ADL

•! Definición: La configuración de Arquitectura o Topología es un grafo conectado de componentes y conectores el cual describe la estructura de la arquitectura

•! Los ADL’s deben modelar las configuraciones de forma explícita por su definición

•! Las Configuraciones ayudan a asegurar las propiedades de la arquitectura –! Conectividad

–! Concurrencia y Distribución

–! Adherencia a las heurísticas de diseño y reglas de estilo

Pros y contras para los ADL’s

•! Pros –! Hace explicita la representación de la arquitectura pudiendo ser

entendida por humanos y máquinas

–! Permiten 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:

–! No hay un acuerdo universal sobre lo que un ADL debería representar

–! La mayoría de representaciones actuales son díficiles de analizar y no son soportadas por aplicaciones comerciales, dado su origen académico en la mayoría de los casos

ADL’s considerados

–! ACME (CMU/USC)

–! Rapide (Stanford)

–! Wright (CMU)

–! Unicon (CMU)

–! Aesop (CMU)

–! MetaH (Honeywell)

–! C2 SADL (UCI)

–! SADL (SRI)

–! Lileanna

–! Modechart

–! UML

Ejemplo de un ADL (ACME)

client

send-request

server

receive-request

caller callee

rpc

Ejemplo de una especificación con Rapide

(productor-consumidor)

ACME

•! Es un lenguaje de intercambio de Arquitectura."

•! El proyecto Acme comenzó a principios de 1995 en la Escuela de Ciencias de la Computación de la

Universidad Carnegie Mellon (USA)."

•! Este proyecto se organiza en dos grandes grupos, que

son el lenguaje ACME propiamente dicho y el Acme Tool Developerﾕs Library (AcmeLib). "

Características

•! Es útil por su capacidad de soportar el mapeo de especificaciones arquitectónicas entre diferentes ADLs."

•!Orientado como un ADL que no es necesariamente apto para cualquier clase de sistemas"

•! Es reconocido por su facilidad para describir con facilidad sistemas relativamente simples."

Definición de estructura

•! Se utilizan siete tipos de entidades:"

–!Componentes"

–!Conectores"

–!Sistemas"

–!Puertos"

–!Roles"

–!Representaciones"

–!Rep-mapas (mapas de representación)"

Componentes

•!Representan elementos computacionales y almacenamientos de un sistema. Por

ejemplos:"

–!Servidor de aplicaciones"

–!Base de datos relacional"

•!Un componente se define siempre dentro

de una familia de componentes "

Interfaces

•! Todos los ADLs conocidos soportan la especificación de interfaces para sus componentes. En Acme cada componente puede tener mútiples interfaces. "

•! Los puntos de interfaz se llaman puertos (ports)"

•! Los puertos pueden definir interfaces tanto simples como complejas, desde una signatura de procedimiento hasta una colección de rutinas a ser invocadas en cierto orden, o un evento de multicast."

Conectores

•! Acme modela sus conectores como entidades de primera clase los cuales representan interacciones entre componentes. "

•! Los conectores también tienen interfaces que están definidas por un conjunto de roles. "

•! Los conectores binarios son los más sencillos. Ejemplos: "–!El invocador y el invocado de un conector RPC."

–!La lectura y la escritura de un conector de tubería"

–!El remitente y el receptor de un conector de paso de mensajes. "

Semántica

•!Muchos lenguajes de tipo ADL no modelan la semántica de los

componentes mas allá de sus interfaces."

•! En este sentido, Acme solo soporta cierta

clase de información semántica en listas

de propiedades. Estas propiedades no se interpretan, y solo existen a efectos de documentación."

Ejemplo: Estilo de tuberías y filtros

•! Estilo característico de arquitecturas de tipo UNIX,

usado en compiladores, flujos de datos, tratamiento de

XML con procesadores XSLT, procesamiento de señales y programación funcional, así como en los mecanismos

de procesamiento de consultas de algunos servidores

de bases de datos."

Definición de los componentes

•! Se declaran tipos de componente que permiten establecer la estructura requerida por el tipo. Esta estructura se define mediante la misma sintaxis que la instancia de un componente. "

•! Para el ejemplo todos los filtros definen por lo menos dos puertos"

Component Type FilterT = {"

Ports { stdin; stdout; };"

Property throughput : int;"

}; "

Definición de jerarquías de tipos

•! Se extiende el tipo básico de filtro con una subclase (herencia). Las instancia de WindowsFilterT tendrá todas las propiedades y puertos de las instancias de FilterT, más un puerto stderr y una propiedad implementationFile."

Component Type WindowsFilterT extends FilterT with { "

Port stderr;"

Property implementationFile : String;"

}; "

Definición de otros componentes

•! Se declara el tipo de conector de tubería. Igual que los tipos de componente, un tipo de conector también describe la estructura requerida. "

•! "

Connector Type PipeT = {"

Roles { source; sink; };"

Property bufferSize : int; "

}; "

Interfaces gráficas para ACME

•! AcmeStudio: Entorno gráfico basado en Windows, susceptible de ser

configurado para soportar visualizaciones específicas de estilos e invocación de herramientas auxiliares. "

•! Armani: Utiliza Microsoft Visio como front-end gráfico y un back-end Java,

que puede usar Microsoft Visual J++ o incluso Visual J# de .NET. Armani no es un entorno redundante sino, por detrás de la fachada de Visio, un

lenguaje de restricciones que extiende Acme basándose en lógica de

predicados de primer orden, y que es por tanto útil para definir invariantes y heurísticas de estilos. "

•! Un tercer ambiente, más experimental, diseñado en ISI, utiliza

sorprendentemente el editor de PowerPoint para manipulación gráfica acoplado con analizadores que reaccionan a cambios de una

representación DCOM de los elementos arquitectónicos y de sus propiedades asociadas."

Herramientas ...

•! Acme Estudio (ACME): –!Implementado

como un plugin de Eclipse para portabilidad y extensibilidad

–!Disponible para Windows, Linux y Mac OS-X.

Representación gráfica:

Top Level (Partial System)

Nivel más interno (conf y ord)

Nivel Communication System

DARWIN

•! Es un lenguaje de descripción arquitectónica desarrollado por Jeff Magee y Jeff Kramer."

•! Como su nombre lo indica, Darwin está

orientado más que nada al diseño de arquitecturas dinámicas y cambiantes. "

•! Soporta notación gráfica. Existe una herramienta (Software Architects Assistant) que permite trabajar visualmente con lenguaje Darwin (http://www.doc.ic.ac.uk/~kn/java/saaj.html)"

Modelado con DARWIN

•! Se describe un tipo de componente mediante una interfaz consistente en una colección de servicios que son ya sea provistos (declarados por ese componente) o requeridos (o sea, que se espera ocurran en el entorno). "

•! Las configuraciones se desarrollan instanciando las declaraciones de componentes y estableciendo vínculos entre ambas clases de servicios"

Modelado con DARWIN (2)

•! Cada servicio de Darwin se modela como un nombre de canal, y cada declaración de binding es un proceso que trasmite el nombre del canal al componente que requiere el servicio. "

•! En una implementación generada en Darwin, se presupone que cada componente primitivo está implementado en algún lenguaje de programación, y que para cada tipo de servicio se necesita un ligamento (glue) que depende de cada plataforma. "

•! Un algoritmo de elaboración actúa, esencialmente, como un servidor de nombre que proporciona la ubicación de los servicios provistos a cualquier componentes que se ejecute."

Elementos en DARWIN

•! Estilos: Para delinear un estilo hay que construir un algoritmo capaz de representar a los miembros de un estilo. Dada su especial naturaleza, es razonable suponer que Darwin se presta mejor a la descripción de sistemas que poseen características dinámicas."

•! Interfaces: En Darwin las interfaces de los componentes consisten en una colección de servicios que pueden ser provistos o requeridos. "

•! Conectores: En Darwin no es posible ponerle nombre, sub- tipear o reutilizar un conector. Tampoco se pueden describir patrones de interacción independientemente de los componentes que interactúan. "

Semántica en DARWN

•! Darwin proporciona una semántica para sus procesos estructurales

mediante el cálculo ?. "

•! Este modelo se ha utilizado para demostrar la corrección lógica de las

configuraciones de Darwin donde prevalece su esencia de movilidad y

dinamismo. "

•! En un escenario como el Web, en el que las entidades que interactúan no

están ligadas por conexiones fijas ni caracterizadas por propiedades

definidas de localización, esta clase de cálculo se presenta como un formalismo extremadamente útil. "

•! Ha sido, de hecho, una de las herramientas formales que estuvo en la base

de los primeros modelos del XLANG de Microsoft, que ahora se encuentra

derivando hacia BPEL4WS (Business Process Execution Language for Web Services)."

Características de DARWIN

•! Darwin no proporciona una base adecuada para el análisis de la conducta de una arquitectura, debido a que el modelo no dispone de ningún medio para describir las propiedades de un componente o de sus servicios más que como comentario. "

•! Los componentes de implementación se interpretan como cajas negras, mientras que la colección de tipos de servicio es una colección dependiente de plataforma cuya semántica tampoco se encuentra interpretada en el framework de Darwin"

Tuberías y filtros en DARWIN

component pipeline (int n) {"

provide input; "

require output; "

array F[n]:filter; "

forall k:0..n-1 {

inst F[k];"

bind F[k].output -- output;"

when k<n-1 bind

F[k].next -- F[k+1].prev;"

}

bind

input -- F[0].prev;"

F[n-1].next -- output;"

} "

Estilo de Arquitectura C2

•! C2 o Chiron-2 no es estrictamente un ADL; es un estilo de

arquitectura de software que se ha impuesto como estándar en el

modelado de sistemas que requieren intensivamente paso de

mensajes y que suelen poseer una interfaz gráfica dominante."

•! Ha sido utilizado eficazmente para implementaciones industriales,

como llo fue el diseño de un sistema de control para plantas de

energía en Japón (1977)"

•! C2 ha sido una de las bases de las modernas arquitecturas

basadas en servicios. "

Características

•! En una arquitectura de estilo C2, los conectores trasmiten mensajes entre

componentes, los cuales mantienen el estado, ejecutan operaciones e intercambian mensajes con otros componentes a través de dos interfaces

(llamadas top y bottom). "

•! Los componentes no intercambian mensajes directamente, sino a través de

conectores. "

•! Cada interfaz de un componente puede vincularse con un solo conector, el

cual a su vez se puede vincular a cualquier número de otros conectores o componentes. "

•! Los mensajes de requerimiento solo se pueden enviar “hacia arriba” en la

arquitectura, y los de notificación solo “hacia abajo”. "

Relevancia de C2

•! La única forma de comunicación es a través de paso de mensajes, de

modo que nunca se utiliza memoria compartida. "

•! Esta limitación se impone para permitir la independencia de sustratos, que

en la jerga de C2 se refiere a la capacidad de reutilizar un componente en

otro contexto. "

•! C2 no presupone nada respecto del lenguaje de programación en que se

implementan los componentes o conectores (que pueden ser Visual

Basic .NET o C#), ni sobre el manejo de threads de control de los componentes, el deployment de los mismos o el protocolo utilizado por los

conectores. "

ADLS’s para C2

•! C2 SADL (Simulation Architecture Description Language) es un ADL que permite describir arquitecturas en estilo C2. "

•! C2SADEL es otra variante cuya herramienta de modelado canónica es DRADEL (Development of Robust Architectures using a Description and Evolution Language). "

•! xArch y xADL, soportan C2 al igual que lo hacen para ADML"

•! Otra variante, SADL1 (Structural Architecture Description Language), fue promovido alguna vez por SRI, pero parece hoy descontinuado."

1: Sin C2 como prefijo

Otros ADLS#: LILEANNA"

•! Es un ADL (o más estrictamente un MIL) que utiliza el lenguaje Ada para la implementación y Anna para la especificación. "

•! Fue desarrollado como parte del proyecto DSSA ADAGE, patrocinado por ARPA. La implementación fue llevada a cabo por Will Tracz de Loral Federal Systems"

•! Sus fundamentos formales son poderosos, pero no están en línea con el estilo de arquitectura orientada a servicios o con modelos igualmente robustos, como los de C2 y Wright."

•! Se utilizó para producir software de navegación de helicópteros. "

Otros ADL’S: ADML

•! ADML (Architecture Description Markup Language) constituye un intento del

OMG por estandarizar la descripción de arquitecturas con base en XML."

•! De ADML se desprenden:"

–! xADL, desarrollado por la Universidad de California en Irvine, que

define XML Schemas para la descripción de familias arquitectónicas, o

sea estilos. La especificaci溶 inicial de xADL 2.0 se encuentra en http://www.isr.uci.edu/projects/xarchuci/."

–! xArch, lenguaje basado en XML, elaborado en Irvine y Carnegie Mellon

para la descripción de arquitecturas."

•! Más información en http://www.enterprise-architecture.info/Images/ADML/

WEB%20ADML.htm."

Debe ser UML considerado como un ADL?

•! Las opiniones están divididas:

–!UML es un lenguaje de diseño no para

representar arquitecturas

–!UML permite representar las arquitecturas

mediante esquemas de vistas con sus

diagramas (4+1 – Krutchen)

–!El diagrama de componentes permite modelar

la arquitectura (Ambler 1998)

Técnicas de apoyo al análisis y evaluación de

arquitecturas propuestas por el SEI

•! Para obtener los casos de negocio y entender los

requerimientos

–! Quality Attribute Workshop (QAW)

•! Para crear o seleccionar la arquitectura

–! Attribute Driven Desing (ADD)

•! Para documentar y comunicar la arquitectura

–! View and Beyond Approach

•! Para analizar y evaluar la arquitectura

–! Architecture Tradeoff Analysis Method (ATAM)

–! Cost Benefit Analysis Method (CBAM)

–! Software Architecture Analysis Method (SAAM)

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

Vista “4+1”

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.