Desarrollo de Aplicaciones basado en Componentes y Frameworks Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento.

Presentación del tema: "Desarrollo de Aplicaciones basado en Componentes y Frameworks Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento."— Transcripción de la presentación:

1 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

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

3 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 1ª Parte: Arquitecturas del Software

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

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

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

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

8 8 Arquitectura del Software  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) AS

9 9 Disciplina  Nivel del 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)

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

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

12 12 Emisor Receptor Buffer Arquitectura Productor/Consumidor

13 13 Objetivos de la AS Comprender y manejar la estructura de las aplicaciones complejas Comprender y manejar la estructura de las aplicaciones complejas Reutilizar dicha estructura (o parte de ella) Reutilizar dicha estructura (o parte de ella) Planificar la evolución de la aplicación 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 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 Permitir el estudio de propiedades específicas

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

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

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

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

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

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

20 20 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

21 21 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

22 22 Descripción de Arquitecturas Diagramas informales de cajas y líneas Diagramas informales de cajas y líneas Imprecisos, ambiguos y no analizables Imprecisos, ambiguos y no analizables Lenguajes de programación modular Lenguajes de programación modular Mezclan aspectos de programación y estructurales Mezclan aspectos de programación y estructurales El análisis se basa en emparejamiento de nombres El análisis se basa en emparejamiento de nombres Lenguajes de interconexión de módulos (MILs o IDLs) Lenguajes de interconexión de módulos (MILs o IDLs) Implican un determinado mecanismo de interacción Implican un determinado mecanismo de interacción UML como notación arquitectónica UML como notación arquitectónica Lenguajes de Descripción de Arquitectura (LDAs) Lenguajes de Descripción de Arquitectura (LDAs)

23 23 Lenguajes de Descripción de Arquitecturas (LDAs) Un LDA es un lenguaje o notación para describir una arquitectura software: 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) Existen LDAs de propósito general y otros de dominio específico (DSLs)

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

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

26 26 Ejemplos de LDAs Ejemplos: 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 Problema: No cubren todo el ciclo de vida de las aplicaciones software (sólo diseño preliminar), no llegan a la implementación

27 27 Ejemplos de LDAs : UNICON Una pipe de Unix Una pipe de Unix connector Unix-pipe protocol is protocol is type pipe type pipe role source is Source role source is Source MaxConns(1) MaxConns(1) end source end source role sink is Sink role sink is Sink MaxConns(1) MaxConns(1) end sink end sink end protocol end protocol... implementation is builtin end implementation end Unix-Pipe

28 28 Ejemplos de LDAs : Wright Una pipe de Unix Una pipe de Unix connector Pipe = role WRITER = write  WRITER  close   role WRITER = write  WRITER  close   role READER = let ExitOnly = close  role READER = let ExitOnly = close  in let DoRead = (read  READER □ readEoF  ExitOnly in let DoRead = (read  READER □ readEoF  ExitOnly in DoRead  ExitOnly in DoRead  ExitOnly glue = let ReadOnly = READER.read  readOnly 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 in WRITER.write  glue □ READER.read  glue □ WRITE.close  ReadOnly □ READER.close  WriteOnly □ WRITE.close  ReadOnly □ READER.close  WriteOnly

29 29 Ejemplos de LDAs : RAPIDE type Application is interface extern action Receive(p:params); // evento de entrada extern action Receive(p:params); // evento de entrada public action Results(p:params); // evento de salida public action Results(p:params); // evento de salidabehaviour (?M in String) Receive(?M) => Results(?M); // transición de eventos (?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; P : array(Integer) of Application; Q: array(Integer) of Resource; //Dual of Application Q: array(Integer) of Resource; //Dual of Applicationconnect for i:Integer in 1..Num generate for i:Integer in 1..Num generate (?M in String) P(i). Receive(?M) to Q(i).Results(?M); (?M in String) P(i). Receive(?M) to Q(i).Results(?M); P(i).Results(?M) to Q(i). Receive(?M); P(i).Results(?M) to Q(i). Receive(?M); end generate; end generate; end DistrApp;

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

31 31 LDAs del grupo GISUM LDC + LDS (Fuentes y Troya, 1998) 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) LEDA (Canal, Pimentel y Troya, 2000)  Basado en el álgebra de procesos  -cálculo  Permite especificar arquitecturas dinámicas

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

33 33 LDC: Componentes def component DoM(fich:”String”) propagates listMovies(list-movies=”List”) end interface is type File fich:”String” getlistMovies(category=”String”) throws listMovies(list-movies=”List”) end enddef DoM Lenguajes de especificación de servicios

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

35 35 LDC: Conectores def connector MSelector(newphase:component) handles listMovies(list-movies=”List”),service(movie=”String”) service(category-movie=”Command”) end messages DoM.getlistMovies(category=”String”) Participant.initService(panel=”DoMpanel”) Participant.displayService(data=”List”) Participant.service(command=”Command”) end protocol is type Service std(SDL) {...} end enddef MSelector Lenguajes de especificación de servicios

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

37 37 LDS: Conexiones (scaccess1 : SCAccess(nombre)) scaccess1[acdb] to participant with {access(params), join} acdb with {subscribed,non-subscribed}; subscribed, non-subscribed Participant getAccessParams() --> joinResponse() join() -------------------> SCAccess ACDB:File <--------- checkAccess() join access(params) Lenguajes de especificación de servicios participantacdbscaccess1

38 38 LCF Organización de servicios genéricos Organización de servicios genéricos Servicio de organización común Servicio de organización común readLocation() --------> close() ConfiguratedDataBase: File readParameter() ------> ConfiguratedService: File addFile() addParties() addLocation() addParameter() close() Organización VoD genérico VoD versión1 Lenguajes de especificación de servicios

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

40 40 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); }

41 41 Un ejemplo en LEDA (II) component Sender { interface writer : Writer; } 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) ); } component Receiver { interface reader : Reader; }

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

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

44 44 Comparación de LDAs EntidadesDinamismo Verificación Propiedades Desarrollo Reutilizac. Ejecución UniConComp/ConNoNoNoGen.Cod. WrightComp/ConNoCompat.NoNo DarwinCompSíSeg./VivezaNoGen.Cod. RapideCompLimitado Análisis Restricciones HerenciaSimul./Gen.Cod. LDSComp/ConSíPosibleExtensiónGen.Cod. LEDACompSíCompat./Ext.Ext./Gener. Simul./ Gen.Cod.

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

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

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

48 48 P1. Definición de AS Una AS es algo más que una descripción de la estructura de una aplicación Una AS es algo más que una descripción de la estructura de una aplicación  ¿Qué es ese algo más?  ¿Cómo se expresa? Otras definiciones alternativas de AS: 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” “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”

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

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

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

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

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

54 54 Bibliografía  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

55 55 Bibliografía  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.

56 56 Bibliografía  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