Desarrollo de Aplicaciones basado en Componentes y Frameworks

Desarrollo de Aplicaciones basado en Componentes y Frameworks Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación Universidad de Málaga. España av@lcc. uma. es Raúl Monge Departamento de Informática Universidad Técnica Federico Santa María. Chile rmonge@inf. utfsm. l

Contenido Global del Curso: Arquitecturas de Software n Marcos de Trabajo (Frameworks) n Programación orientada a Componentes n 2

1ª Parte: Arquitecturas del Software Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación Universidad de Málaga. España av@lcc. uma. es

Contenido Estilos Arquitectónicos n Lenguajes de Descripción de Arquitecturas n Programación Orientada a Componentes n 4

Introducción Sistemas Abiertos u Características y Problemática n Estilos Arquitectónicos n Lenguajes de Descripción de arquitecturas n Ingeniería del Software basada en Componentes (CBSE) u Arquitectura Software y COTS n 5

Sistemas Abiertos Concurrentes n Reactivos n Independientemente extensibles n Heterogéneos n Evolutivos n Distribuidos n 6

Problemas específicos Gestión de la evolución (del sistema y de sus componentes) n Compatibilidad de componentes n Falta de visión global del sistema n Dificultad para garantizar la seguridad n Retrasos y errores en las comunicaciones n Fallos y errores en los propios componentes n 7

Arquitectura del Software u u AS Estructura de los componentes de un programa o sistema, sus interrelaciones, y los principios y reglas que gobiernan su diseño y evolución en el tiempo. (Garlan y Perry, 1995) Estructura o estructuras de un sistema, lo que incluye sus componentes software, las propiedades observables de dichos componentes y las relaciones entre ellos. (Bass, Clements y Kazman, 1998) 8

Disciplina u u Nivel diseño del software donde se definen la estructura y propiedades globales del sistema. (Garlan y Perry, 1995) La Arquitectura del Software se centra en aquellos aspectos del diseño y desarrollo que no pueden tratarse de forma adecuada dentro de los módulos que forman el sistema. (Shaw y Garlan, 1996) 9

Caracterización Arquitectura vs. Algoritmos + Datos u organización del sistema n Interacción de componentes vs. Definición/uso u componentes y conectores n Estilo Arquitectónico vs. Instancia u restricciones en la forma de una familia de instancias n Arquitectura vs. Métodos de Diseño u espacio de diseños arquitectónicos n 10

Descripción de una AS n Representación de alto nivel de la estructura de un sistema o aplicación, que describe: u partes que la integran, u interacciones entre ellas, u patrones que supervisan su composición, y u restricciones para aplicar dichos patrones. 11

Arquitectura Productor/Consumidor Emisor Buffer Receptor 12

Objetivos de la AS Comprender y manejar la estructura de las aplicaciones complejas n Reutilizar dicha estructura (o parte de ella) n Planificar la evolución de la aplicación n Analizar la corrección de la aplicación y su grado de cumplimiento frente a los requisitos iniciales n Permitir el estudio de propiedades específicas n 13

Ventajas de las A. S. Resaltan aquellos aspectos estucturalmente importantes, tanto funcionales como no funcionales n Eliminan muchos riesgos y errores de diseño, desarrollo e implantación n Permiten un desarrollo paralelo, aumentando la productividad n 14

El “territorio” de las AS Adaptado de P. Kruchten, B. Selic, W. Kozaczynski. “Describing Software Architecture with UML”, 2001 15

Modelo, Vista y Punto de Vista n Modelo (model) u n Vista (view) u u n Una descripción completa de un sistema a un determinado nivel de abstracción Una proyección de un modelo desde una perspectiva Omite las entidades y elementos que no son relevantes Punto de vista (viewpoint) u u La definición (o descripción) de una vista Prescribe su contenido, significado y representación 16

Niveles de Abstracción n Estilos arquitectónicos t n Modelos y arquitecturas de referencia t n arquitectura reutilizable en aplicaciones de un mismo dominio Familias y líneas de productos t n particularizan un estilo y definen los conceptos asociados Marcos de Trabajo t n familias de sistemas que siguen el mismo patrón estructural arquitectura de una aplicación con diferentes configuraciones Instancias t arquitectura de una aplicación concreta 17

Estilos Arquitectónicos n Componentes t n Conectores t n invariantes del estilo Mecanismos de control t n mecanismos de interacción entre componentes Patrones y restricciones de interconexión t n unidades computacionales y de datos coordinación entre componentes Propiedades t ventajas e inconvenientes 18

Clasificación de estilos Sistemas de flujo de datos n Sistemas basados en llamada y retorno n Sistemas de componentes independientes n Sistemas centrados en los datos n Máquinas virtuales n Sistemas heterogéneos n 19

Estilos y subestilos (I) Sistemas de flujo de datos Sucesión de transformaciones de los datos de entrada u Subestilos: pipe & filter y procesamiento por lotes Sistemas basados en llamada y retorno Reflejan la estructura del lenguaje de programación u Subestilos: programa principal-subrutina, OO, capas Sistemas de componentes independientes Componentes distribuidos que se comunican por paso de mensajes u 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 u Subestilos: repositorio y pizarras (blackboards) Máquinas virtuales Simulan una funcionalidad no nativa del entorno u Subestilos: intérpretes y sistemas basados en reglas Sistemas heterogéneos Localmente, jerárquicamente o simultáneamente heterogéneos 21

Descripción de Arquitecturas n Diagramas informales de cajas y líneas • n Lenguajes de programación modular • • n n 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) • n Imprecisos, ambiguos y no analizables 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: u Descripción de componentes, conectores y enlaces entre ellos. u Herramientas para la verificación de la arquitectura y el prototipado rápido. n Existen LDAs de propósito general y otros de dominio específico (DSLs) n 23

Arquitectura Productor/Consumidor storage writer Sender Enlaces puertos/roles ¿ analizables ? Puertos: describen el comportamiento de las componentes Receiver Buffer retrieval reader Roles: describen el comportamiento de los conectores 24

Requisitos de un ADL n Composición u n Configuración u n Debe permitir reutilizar componentes, conectores, y arquitecturas Heterogeneidad u n Debe describir los roles abstractos que juegan los componentes Reutilización u n Debe describir la arquitectura independientemente de los componentes Abstracción u n Debe describir el sistema como una composición de partes Debe permitir combinar descripciones heterogéneas Análisis u Debe permitir diversas formas de análisis de la arquitectura 25

Ejemplos de LDAs n n Ejemplos: u UNICON (Shaw et al. 1995) u Rapide (Luckham et al. 1995) u Darwin (Magee y Kramer, 1996; 1999) u Wright (Allen y Garlan, 1997; 1998) u 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 n Una pipe de Unix connector Unix-pipe protocol is type pipe role source is Source Max. Conns(1) end source role sink is Sink Max. Conns(1) end sink end protocol . . . implementation is builtin end implementation end Unix-Pipe 27

Ejemplos de LDAs : Wright n Una pipe de Unix connector Pipe = role WRITER = write WRITER close role READER = let Exit. Only = close in let Do. Read = (read READER □ read. Eo. F Exit. Only in Do. Read Exit. Only glue = let Read. Only = READER. read. Only □ READER. read. Eo. F READER. close □ READER. close in let Write. Only = WRITER. write Write. Only □ WRITER. close in WRITER. write glue □ READER. read glue □ WRITE. close Read. Only □ READER. close Write. Only 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 Distr. App(Num: Integer) return Interface. Distr. App 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 Distr. App; 29

Ejemplos de LDAs : Darwin cabeza : Filtro entrada ant cauce : Pipeline sig salida entrada salida : Pipeline salida 30

LDAs del grupo GISUM n n LDC + LDS (Fuentes y Troya, 1998) u Modelo de componentes pasivos y conectores reactivos u Formalismo de especificación de comportamiento de conectores (TDFs, -cálculo, etc. ) LEDA (Canal, Pimentel y Troya, 2000) u Basado en el álgebra de procesos -cálculo u Permite especificar arquitecturas dinámicas 31

Lenguajes de especificación de servicios LDC: Componentes Propagación de eventos n Interfaz n Tipo Atributos Mensajes + eventos Componente: Tipo Atributos Método()-----> 32

Lenguajes de especificación de servicios LDC: Componentes def component Do. M(fich: ”String”) propagates list. Movies(list-movies=”List”) end interface is type File fich: ”String” getlist. Movies(category=”String”) throws list. Movies(list-movies=”List”) enddef Do. M 33

Lenguajes de especificación de servicios LDC: Conectores n Parametrización u Componentes participantes Gestión de eventos Relación de uso Conector componente, set(componente) Protocolo Tipo ASTM Protocolo en TDF 34

Lenguajes de especificación de servicios LDC: Conectores def connector MSelector(newphase: component) handles list. Movies(list-movies=”List”), service(movie=”String”) service(category-movie=”Command”) end messages Do. M. getlist. Movies(category=”String”) Participant. init. Service(panel=”Do. Mpanel”) Participant. display. Service(data=”List”) Participant. service(command=”Command”) end protocol is type Service std(SDL) {. . . } enddef MSelector 35

Lenguajes de especificación de servicios LDS: Conexiones n Conexiones u En base a eventos u Instanciación de la relación de uso Adaptar componentes a conectores Renombrar métodos y eventos 36

Lenguajes de especificación de servicios LDS: Conexiones participant Participant get. Access. Params() --> join. Response() join() ----------> scaccess 1 acdb subscribed, non-subscribed access(params) SCAccess ACDB: File <----- check. Access() join (scaccess 1 : SCAccess(nombre)) scaccess 1[acdb] to participant with {access(params), join} acdb with {subscribed, non-subscribed}; 37

Lenguajes de especificación de servicios LCF n n Organización de servicios genéricos Servicio de organización común Configurated. Data. Base: File read. Parameter() ------> read. Location() ----> close() Vo. D genérico Organización Configurated. Service: File add. File() add. Parties() add. Location() add. Parameter() close() Vo. D versión 1 38

Lenguajes de especificación de servicios LCF Tipo de servicio Asignación de nombres lógicos a físicos Configuración de parámetros globales Clases de componentes y conectores set parties unicast set msap <url> set movie remote set participant local put text “Fich. clientes” parname acdb: : acdbfich value=”” put text “Tipo acceso” implementation scaccess value=”” 39

Un ejemplo en LEDA (I) component Buffer { interface storage : Storage; retrieval : Retrieval; } role Storage(put) { spec is put? (x). Storage(put) } role Retrieval(get) { spec is get? (item, empty). . (x) item!(x). Retrieval(get) + . empty!(). Retrieval(get); } 40

Un ejemplo en LEDA (II) component Sender { interface writer : Writer; } component Receiver { interface reader : Reader; } role Writer(write) { spec is (data) write!(data). Writer(write); } role Reader(read) { spec is (return, empty) read!(return, empty). ( return? (item). Reader(read) + empty? (). Reader(read) ); } 41

Un ejemplo en LEDA (III) component Producer. Consumer { interface. . . composition p: Sender; c: Receiver; b: Buffer; attachments p. writer(write) <> b. storage(write); b. retrieval(read) <> c. reader(read); } 42

Lenguajes de especificación de servicios LDS n Parámetros globales Configuración con LCF Componentes simples conjunto lista de tipos components chair : Manager(name) audience : set(Participant) ===> devices : {Textual. Chat, File. Movie} end item(audience) 43

Comparación de LDAs Entidades Dinamismo Verificación Propiedades Desarrollo Ejecución Reutilizac. Uni. Con Comp/Con No No No Gen. Cod. Wright Comp/Con No Compat. No No Darwin Comp Sí Seg. /Viveza No Gen. Cod. Rapide Comp Limitado Análisis Herencia Restricciones Simul. / Gen. Cod. LDS Comp/Con Sí Posible Gen. Cod. LEDA Comp Sí Compat. /Ext. /Gener. Simul. / Gen. Cod. Extensión 44

Arquitectura Software vs. COTS u Arquitectura del Software Orientados a la reutilización independiente de patrones arquitectónicos y de componentes t Modelos formales t Tecnología desarrollada en el entorno académico t u COTS Componentes con interfaces estándares (IDLs) t No aparece la noción de conector o “enchufe” t Mercado global de componentes centrado en la reutilización de componentes t Tecnología madura: Open. Doc/CORBA, OLE/COM t 45

Ingeniería del Software basada en Componentes n n Componentes unidos a una arquitectura Partes de la interfaz de un componente para soportar la noción de arquitectura: u Tiempo de Composición t u Tiempo de Diseño t u Elementos para generar una aplicación a partir de COTS Interfaces funcionales y dependencias de componentes Tiempo de Ejecución t Servicios de composición dinámica en runtime 46

AS: problemas y líneas abiertas 1. 2. 3. 4. 5. 6. Definición de AS Expresión de parámetros de calidad Medidas Herramientas Relación con el dominio de aplicación ‘Vistas’ arquitectónicas 47

P 1. Definición de AS n Una AS es algo más que una descripción de la estructura de una aplicación u ¿Qué es ese algo más? u ¿Cómo se expresa? n Otras definiciones alternativas de AS: “A Software Architecture is a collection of categories of elements that share the same likelihood of change. Each category contains software elements that exhibit shared stability characteristics” 48

P 2. Parámetros de Calidad n Actualmente no se tienen en cuenta. u u “. . . ilities”: portability, traceability, . . . “. . . nesses”: correcness, robustness, . . . n Propios del tiempo de ejecución (dinámicos): u Performance, security, availability, functionality, usability, etc. n Intrínsecos a la AS (estáticos): u Modifiability, portability, reusability, integrability, testability, etc. 49

P 3. Medidas n Necesarias para poder hablar de Ingeniería del Software n Deberían estimar, de forma cuantitativa: u Tamaño u Estructura u Calidad del diseño u. . . n Funcionales (estructuradas)/Orientadas a Objeto 50

P 4. Herramientas n Diseño n Documentación n Pruebas n Análisis de propiedades (formales) n Generación de código/prototipos 51

P 5. Dominio de Aplicación n Análisis de los dominios de la aplicación y de la solución para derivar AS: Mejor y más estable estructura u Mejor capacidad de evolución u AS solución más natural e integrada en el entorno de la aplicación u 52

P 6. “Vistas” Arquitectónicas n Varias “vistas” arquitectónicas n Algunas técnicas, otras específicas del dominio, otras tecnológicas n RM-ODP o TINA ya las definen n Problemas: consistencia e integración 53

Bibliografía u u u P. Clements (1996), Coming Attractions in Software Architecture, Technical Report, Software Engineering Institute, Carnegie Mellon University (USA). P. Donohoe (Ed. ) (1999), Software Architecture, Kluwer Academic Publishers. D. Garlan y D. E. Perry (1995), Introduction to the Special Issue on Software Architecture, IEEE Transactions on Software Engineering, 21(4): 269– 274. D. Garlan, R. Allen y J. Ockerbloom (1995), Architectural Mismatch: Why Reuse is So Hard, IEEE Software, Nov. 1995, pp. 17– 26. I. Jacobson, G. Booch y J. Rumbaugh (1999), The Unified Software Development Process, Addison-Wesley 54

Bibliografía u u D. Krieger y R. M. Adler (1998), The Emergence of Distributed Component Platforms, IEEE Computer, March 1998, pp. 43– 53. D. Luckham et al. (1995), Specification and Analysis of System Architecture Using Rapide, IEEE Transactions on Software Engineering, vol. 21, no. 4, April 1995, pp. 336– 355. J. Magee y J. Kramer (1996), Dynamic Structure in Software Architectures, Software Engineering Notes, vol. 21, no. 6, Nov. 1996, pp. 3– 14. N. Medvidovic y D. Rosenblum (1997), A Framework for Classifying and Comparing Architecture Description Languages, Proc. ESEC/FSE, LNCS, Springer, pp. 60– 76. 55

Bibliografía u u u W. Pree (1996), Framework Patterns, SIGS Publications. M. Shaw et al. (1995), Abstractions for Software Architecture and Tools to Support Them, IEEE Transactions on Software Engineering, vol. 21, no. 4, April 1995, pp. 314 – 334. M. Shaw y D. Garlan (1996), Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall. S. Sparks et al. (1996), Managing Object-Oriented Framework Reuse, IEEE Computer, Sept. 1996, pp. 52– 61. C. Szyperski (1998), Component Software: Beyond Object. Oriented Programming, Addison-Wesley. A. W. Brown and K. C. Wallnau, The Current State of CBSE, IEEE Software, Sept/Oct. 1998 56