11 (Gp:) Emisor(Gp:) Receptor
(Gp:) Buffer
Arquitectura Productor/Consumidor
12 Objetivos de la AS Comprender y manejar la estructura de las aplicaciones complejas Reutilizar dicha estructura (o parte de ella) Planificar la evolución de la aplicación Analizar la corrección de la aplicación y su grado de cumplimiento frente a los requisitos iniciales Permitir el estudio de propiedades específicas
13 Ventajas de las A.S. Resaltan aquellos aspectos estucturalmente importantes, tanto funcionales como no funcionales Eliminan muchos riesgos y errores de diseño, desarrollo e implantación Permiten un desarrollo paralelo, aumentando la productividad
14 El “territorio” de las AS
15 Modelo, Vista y Punto de Vista Modelo (model) Una descripción completa de un sistema a un determinado nivel de abstracción Vista (view) Una proyección de un modelo desde una perspectiva Omite las entidades y elementos que no son relevantes Punto de vista (viewpoint) La definición (o descripción) de una vista Prescribe su contenido, significado y representación
16 Niveles de Abstracción Estilos arquitectónicos familias de sistemas que siguen el mismo patrón estructural Modelos y arquitecturas de referencia particularizan un estilo y definen los conceptos asociados Marcos de Trabajo arquitectura reutilizable en aplicaciones de un mismo dominio Familias y líneas de productos arquitectura de una aplicación con diferentes configuraciones Instancias arquitectura de una aplicación concreta
17 Estilos Arquitectónicos Componentes unidades computacionales y de datos Conectores mecanismos de interacción entre componentes Patrones y restricciones de interconexión invariantes del estilo Mecanismos de control coordinación entre componentes Propiedades ventajas e inconvenientes
18 Clasificación de estilos Sistemas de flujo de datos Sistemas basados en llamada y retorno Sistemas de componentes independientes Sistemas centrados en los datos Máquinas virtuales Sistemas heterogéneos
19 Estilos y subestilos (I) Sistemas de flujo de datos Sucesión de transformaciones de los datos de entrada Subestilos: pipe & filter y procesamiento por lotes Sistemas basados en llamada y retorno Reflejan la estructura del lenguaje de programación Subestilos: programa principal-subrutina, OO, capas Sistemas de componentes independientes Componentes distribuidos que se comunican por paso de mensajes Subestilos: sistemas cliente/servidor y de eventos
20 Estilos y subestilos (II) Sistemas centrados en los datos Acceso compartido a un banco de datos central Subestilos: repositorio y pizarras (blackboards) Máquinas virtuales Simulan una funcionalidad no nativa del entorno Subestilos: intérpretes y sistemas basados en reglas Sistemas heterogéneos Localmente, jerárquicamente o simultáneamente heterogéneos
21 Descripción de Arquitecturas Diagramas informales de cajas y líneas Imprecisos, ambiguos y no analizables Lenguajes de programación modular Mezclan aspectos de programación y estructurales El análisis se basa en emparejamiento de nombres Lenguajes de interconexión de módulos (MILs o IDLs) Implican un determinado mecanismo de interacción UML como notación arquitectónica Lenguajes de Descripción de Arquitectura (LDAs)
22 Lenguajes de Descripción de Arquitecturas (LDAs) Un LDA es un lenguaje o notación para describir una arquitectura software: Descripción de componentes, conectores y enlaces entre ellos. Herramientas para la verificación de la arquitectura y el prototipado rápido. Existen LDAs de propósito general y otros de dominio específico (DSLs)
23 (Gp:) Sender (Gp:) Receiver (Gp:) Buffer (Gp:) Arquitectura Productor/Consumidor
(Gp:) Enlaces puertos/roles ¿ analizables ?
(Gp:) Puertos: describen el comportamiento de las componentes
(Gp:) writer (Gp:) storage (Gp:) reader (Gp:) retrieval
(Gp:) Roles: describen el comportamiento de los conectores
24 Requisitos de un ADL Composición Debe describir el sistema como una composición de partes Configuración Debe describir la arquitectura independientemente de los componentes Abstracción Debe describir los roles abstractos que juegan los componentes Reutilización Debe permitir reutilizar componentes, conectores, y arquitecturas Heterogeneidad Debe permitir combinar descripciones heterogéneas Análisis Debe permitir diversas formas de análisis de la arquitectura
25 Ejemplos de LDAs Ejemplos: UNICON (Shaw et al. 1995) Rapide (Luckham et al. 1995) Darwin (Magee y Kramer, 1996; 1999) Wright (Allen y Garlan, 1997; 1998) Executable Connectors (Ducasse y Richner, 1997) Problema: No cubren todo el ciclo de vida de las aplicaciones software (sólo diseño preliminar), no llegan a la implementación
26 Ejemplos de LDAs : UNICON Una pipe de Unix
connector Unix-pipe protocol is type pipe role source is Source MaxConns(1) end source role sink is Sink MaxConns(1) end sink end protocol
… implementation is builtin end implementation end Unix-Pipe
27 Ejemplos de LDAs : Wright Una pipe de Unix connector Pipe = role WRITER = write ? WRITER ? close ? ? role READER = let ExitOnly = close ?? in let DoRead = (read ? READER ? readEoF ? ExitOnly in DoRead ? ExitOnly glue = let ReadOnly = READER.read ? readOnly ? READER.readEoF ? READER.close ?? ? READER.close ?? in let WriteOnly = WRITER.write ? WriteOnly ? WRITER.close?? in WRITER.write ? glue ? READER.read ? glue ? WRITE.close ? ReadOnly ? READER.close ? WriteOnly
28 Ejemplos de LDAs : RAPIDE type Application is interface extern action Receive(p:params); // evento de entrada public action Results(p:params); // evento de salida behaviour (?M in String) Receive(?M) => Results(?M); // transición de eventos end Application;
architecture DistrApp(Num: Integer) return InterfaceDistrApp is P : array(Integer) of Application; Q: array(Integer) of Resource; //Dual of Application connect for i:Integer in 1..Num generate (?M in String) P(i). Receive(?M) to Q(i).Results(?M); P(i).Results(?M) to Q(i). Receive(?M); end generate; end DistrApp;
29 Ejemplos de LDAs : Darwin (Gp:) entrada (Gp:) cabeza : Filtro (Gp:) ant (Gp:) salida (Gp:) salida (Gp:) : Pipeline (Gp:) entrada (Gp:) salida (Gp:) cauce : Pipeline (Gp:) sig
30 LDAs del grupo GISUM LDC + LDS (Fuentes y Troya, 1998) Modelo de componentes pasivos y conectores reactivos Formalismo de especificación de comportamiento de conectores (TDFs, ?-cálculo, etc.) LEDA (Canal, Pimentel y Troya, 2000) Basado en el álgebra de procesos ?-cálculo Permite especificar arquitecturas dinámicas
| Página siguiente |