Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Maestría en Ingeniería
Curso de Arquitectura de Software
Sesión 7
Fernando Barraza A.
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.