Lidia Fuentes y Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación.

Presentación del tema: "Lidia Fuentes y Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación."— Transcripción de la presentación:

1 Lidia Fuentes y 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 {lff,av}@lcc.uma.eshttp://www.lcc.uma.es/~{lff,av} Arquitecturas Software y Marcos de Trabajo

2 2 Contenido Arquitectura del Software Arquitectura del Software 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 MTs y Patrones de Diseño MTs y Patrones de Diseño Patrones de Diseño: su utilidad Patrones de Diseño: su utilidad MTs (Frameworks) orientados a objetos y a componentes MTs (Frameworks) orientados a objetos y a componentes Clasificación de los MTs Clasificación de los MTs

3 3 Arquitectura del Software: Introducción Sistemas Abiertos Sistemas Abiertos Características y Problemática 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 Arquitectura Software y COTS

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

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

6 6 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. 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. 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

7 7 Disciplina Nivel del diseño del software donde se definen la estructura y propiedades globales del sistema. 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. 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)

8 8 Caracterización Arquitectura vs. Algoritmos + Datos Arquitectura vs. Algoritmos + Datos organización del sistema organización del sistema Interacción de componentes vs. Definición/uso Interacción de componentes vs. Definición/uso componentes y conectores componentes y conectores Estilo Arquitectónico vs. Instancia Estilo Arquitectónico vs. Instancia restricciones en la forma de una familia de instancias 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 espacio de diseños arquitectónicos

9 9 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, partes que la integran, interacciones entre ellas, interacciones entre ellas, patrones que supervisan su composición, y patrones que supervisan su composición, y restricciones para aplicar dichos patrones. restricciones para aplicar dichos patrones.

10 10 Emisor Receptor Buffer Arquitectura Productor/Consumidor

11 11 Objetivos de la A.S. 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

12 12 Niveles de Abstracción Estilos arquitectónicos Estilos arquitectónicos familias de sistemas que siguen el mismo patrón estructural 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 particularizan un estilo y definen los conceptos asociados MTs MTs arquitectura reutilizable en aplicaciones de un mismo dominio 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 arquitectura de una aplicación con diferentes configuraciones Instancias Instancias arquitectura de una aplicación concreta arquitectura de una aplicación concreta

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

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

15 15 Estilos y subestilos (I) Sistemas de flujo de datos Sistemas de flujo de datos Sucesión de transformaciones de los datos de entrada Subestilos: pipe & filter y procesamiento por lotes Subestilos: pipe & filter y procesamiento por lotes Sistemas basados en llamada y retorno Sistemas basados en llamada y retorno Reflejan la estructura del lenguaje de programación Subestilos: programa principal-subrutina, OO, capas Subestilos: programa principal-subrutina, OO, capas Sistemas de componentes independientes Sistemas de componentes independientes Componentes distribuidos que se comunican por paso de mensajes Subestilos: sistemas cliente/servidor y de eventos Subestilos: sistemas cliente/servidor y de eventos

16 16 Estilos y subestilos (II) Sistemas centrados en los datos Sistemas centrados en los datos Acceso compartido a un banco de datos central Subestilos: repositorio y pizarras (blackboards) Subestilos: repositorio y pizarras (blackboards) Máquinas virtuales Máquinas virtuales Simulan una funcionalidad no nativa del entorno Subestilos: intérpretes y sistemas basados en reglas Subestilos: intérpretes y sistemas basados en reglas Sistemas heterogéneos Sistemas heterogéneos Localmente, jerárquicamente o simultáneamente heterogéneos

17 17 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)

18 18 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. Descripción de componentes, conectores y enlaces entre ellos. Herramientas para la verificación de la arquitectura y el prototipado rápido. 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)

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

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

21 21 Ejemplos de LDAs Ejemplos: Ejemplos: UNICON (Shaw et al. 1995) UNICON (Shaw et al. 1995) Rapide (Luckham et al. 1995) Rapide (Luckham et al. 1995) Darwin (Magee y Kramer, 1996; 1999) Darwin (Magee y Kramer, 1996; 1999) Wright (Allen y Garlan, 1997; 1998) Wright (Allen y Garlan, 1997; 1998) Executable Connectors (Ducasse y Richner, 1997) 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

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

23 23 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.readEoF READER.close READER.close READER.close in let WriteOnly = WRITER.write WriteOnly WRITER.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

24 24 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;

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

26 26 LDAs del grupo GISUM LDC + LDS (Fuentes y Troya, 1998) LDC + LDS (Fuentes y Troya, 1998) Modelo de componentes pasivos y conectores reactivos Modelo de componentes pasivos y conectores reactivos Formalismo de especificación de comportamiento de conectores (TDFs, -cálculo, etc.) 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 Basado en el álgebra de procesos -cálculo Permite especificar arquitecturas dinámicas Permite especificar arquitecturas dinámicas

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

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

29 29 LDC: Conectores Parametrización Parametrización Componentes participantes 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

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

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

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

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

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

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

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

37 37 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; }

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

39 39 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.

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

41 41 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 Tiempo de Composición Elementos para generar una aplicación a partir de COTS Elementos para generar una aplicación a partir de COTS Tiempo de Diseño Tiempo de Diseño Interfaces funcionales y dependencias de componentes Interfaces funcionales y dependencias de componentes Tiempo de Ejecución Tiempo de Ejecución Servicios de composición dinámica en runtime Servicios de composición dinámica en runtime

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

43 43 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? ¿Qué es ese algo más? ¿Cómo se expresa? ¿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

44 44 P2. Parámetros de Calidad Actualmente no se tienen en cuenta. Actualmente no se tienen en cuenta....ilities: portability, traceability,......ilities: portability, traceability,......nesses: correcness, robustness,......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. 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. Modifiability, portability, reusability, integrability, testability, etc.

45 45 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 Tamaño Estructura Estructura Calidad del diseño Calidad del diseño...... Funcionales (estructuradas)/Orientadas a Objeto Funcionales (estructuradas)/Orientadas a Objeto

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

47 47 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 y más estable estructura Mejor capacidad de evolución Mejor capacidad de evolución AS solución más natural e integrada en el entorno de la aplicación AS solución más natural e integrada en el entorno de la aplicación

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

49 49 Bibliografía P. Clements (1996), Coming Attractions in Software Architecture, Technical Report, Software Engineering Institute, Carnegie Mellon University (USA). 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. 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 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. 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 I. Jacobson, G. Booch y J. Rumbaugh (1999), The Unified Software Development Process, Addison-Wesley

50 50 Bibliografía D. Krieger y R. M. Adler (1998), The Emergence of Distributed Component Platforms, IEEE Computer, March 1998, pp. 43–53. 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. 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. 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. N. Medvidovic y D. Rosenblum (1997), A Framework for Classifying and Comparing Architecture Description Languages, Proc. ESEC/FSE, LNCS, Springer, pp. 60–76.

51 51 Bibliografía W. Pree (1996), Framework Patterns, SIGS Publications. 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 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. 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. 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. 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 A.W. Brown and K.C. Wallnau, The Current State of CBSE, IEEE Software, Sept/Oct. 1998

52 52 Marcos de Trabajo (Application Frameworks) * Un MT es un diseño reutilizable de todo o parte de un sistema, representado por un conjunto de clases abstractas y la forma en la que sus instancias interactúan * Un MT es el esqueleto de una aplicación que debe ser adaptado a necesidades concretas por el programador de la aplicación

53 53 Caracterización de los MTs Arquitectura especializada para un dominio de aplicación Arquitectura especializada para un dominio de aplicación Define interfaces de componentes Define interfaces de componentes Establece reglas de interacción entre ellos Establece reglas de interacción entre ellos Implementa alguno de los componentes Implementa alguno de los componentes El usuario encaja sus componentes en el marco El usuario encaja sus componentes en el marco

54 54 Desarrollo de Software basado en MTs Ventajas: Ventajas: Aumenta la reutilización Aumenta la reutilización Minimiza riesgos Minimiza riesgos Reducción de los costes de producción Reducción de los costes de producción Mejora de la calidad final del producto Mejora de la calidad final del producto è Orientado a objetos (C++, Java) è Composicional Diseño del MT

55 55 Utilización de un MT Valorar la adecuación de un MT a un problema Valorar la adecuación de un MT a un problema Comprender su arquitectura Comprender su arquitectura Identificar los hot spots Identificar los hot spots Adaptar/Extender el MT Adaptar/Extender el MT El problema de la documentación El problema de la documentación No existe documentación o es pobre No existe documentación o es pobre No es estándar No es estándar No tiene una semántica formal No tiene una semántica formal Dirigida a diferentes tipos de usuarios Dirigida a diferentes tipos de usuarios

56 56 Documentación de MT (I) Entornos gráficos Entornos gráficos Grafos (Eusel et al. 1997, Florijn et al. 1997) Grafos (Eusel et al. 1997, Florijn et al. 1997) Secuencias de mensajes (Lange et al. 1995) Secuencias de mensajes (Lange et al. 1995) Aportan conocimiento más profundo del MT Aportan conocimiento más profundo del MT Sin una metodología para usar ese conocimiento Sin una metodología para usar ese conocimiento Útil sólo en la fase de identificación del MT Útil sólo en la fase de identificación del MT Contratos de Reutilización Contratos de Reutilización Definen la cooperación entre los diseñadores del MT y los encargados de extenderlo o adaptarlo (Steyaert et al. 1996, Codenie et al. 1997) Definen la cooperación entre los diseñadores del MT y los encargados de extenderlo o adaptarlo (Steyaert et al. 1996, Codenie et al. 1997)

57 57 Documentación De MT(II) Patrones de Diseño (Design Patterns) Patrones de Diseño (Design Patterns) Útil tanto para diseñar la arquitectura de un MT como para documentar el diseño Útil tanto para diseñar la arquitectura de un MT como para documentar el diseño Lange y Nakamura, 1995 Lange y Nakamura, 1995 Odenthal y Quiebel-Cirkel, 1997 Odenthal y Quiebel-Cirkel, 1997 Meijler y Engel, 1997 Meijler y Engel, 1997 Herramientas visuales Herramientas visuales Enfoque de mayor aceptación actualmente Enfoque de mayor aceptación actualmente Notaciones visuales para representar componentes, conectores y enlaces Notaciones visuales para representar componentes, conectores y enlaces Tendencia: Complementar con LDAs Tendencia: Complementar con LDAs

58 58 Extensión de MTs Atendiendo a la forma en que un MT puede ser extendido podemos clasificar éstos en: Atendiendo a la forma en que un MT puede ser extendido podemos clasificar éstos en: MTs de caja de cristal MTs de caja de cristal MTs de caja blanca MTs de caja blanca MTs de caja negra MTs de caja negra MTs de caja gris MTs de caja gris

59 59 Ejemplo de MT: MultiTel ClassEvent type : String from : String args : Object[] Component usp :LocalUSP type : String event (e :ClassEvent) SetLocalUSP (usp :LocalUSP) Componente publicclassVCManagerextendsComponent { publicvoidshowSchedControl(){ if(sched==null){ try{ sched=newScheduleFrame(usp,this); sched.show(); }catch(Exception e){ System.out.println("Exception"+e); e.printStackTrace(); } } } publicvoidturnRequest(Stringuser){ message("User "+user+" hasrequestedtheturn"); Objectargs[]={user}; if (/*Managerdecision */) event("takeTurn",args);... } }

60 60 MultiTel: Conectores public void catchEvent(ClassEvent e) throws Exception { try { synchronized(state) { Method m; m=(state.getClass().getMethod(e.type,e.args)); state=(State)m.invoke(state,e.args);} if (state=null) finalizeConnector(); else startState(); } catch (Exception e) {} } State sender : Pid start () SConn_State1 Event1 () Event2 () SConn_State2 Event3 () Event4 () Connector catchEvent (e : ClassEvent) SConn_Prot Event1 ()... Conector Paquete reflective de Java Patrón de diseño State

61 61 MultiTel: Conectores packagemtsb.vc; publicclass SSchedMPTU1_Idleextends SSchedMPTU1_Prot{ public SSchedMPTU1_Idle(LocalUSPusp){ super(usp); } publicvoidstart(){ sendMessage("Manager","showSchedControl"); sendMessage("Manager","showClassControl"); broadcast(Participant,initTurn); } publicvoidturnRequest(Stringuser){ message("User "+user+" hasrequestedtheturn"); Objectarg[]={user}; sendMessage( scheduler,"turnRequest",arg); } publicStatetakeTurn(){ Object[]arg={usp.user}; sendMessage("VirtualConnection","emit",arg); return (State)new SSchedMPTU1_Speaking(usp); }... } Connector Statestate; catchEvent(ClassEvent e)

62 62 MultiTel: Composición dinámica de componentes y conectores C3P USP P1,P2,cc1,cc2 =CA cc1=Access P1=Participant AS Búsqueda del contexto global Event(e)catchEvent(e) Composición dinámica event(ClassEvent event){ for(i=0;i<numberOfConnectors();i++){ if(service.catchEvent(i, event.type,event.from,role)){ String location =service.connectorLocation(i); String to =service.connectorName(i); Connector ref =service.connectorRef(i); String newname=service.getEventRenaming(...); ClassEvent renamed=event.rename(newname); if(location.equals("local")){ if(ref!=null){ propagateEvent(to,renamed); } if (location.equals(remote)) { Vector usps=getGlobalContext(); for(int j=0;j<usps.size();j++){ USP r=getRemoteUSP(remoteusp); if(r.isThisConnector(to).booleanValue()){ transmitEvent(remote,to,renamed); } else // URL.... }

63 63 Extensión de MultiTel: programación de un servicio publicclassTeleUniextendsServiceUSP{ publicvoid defComponents (){ component("Participant",{"participant,local","manager,remote"},"mtsb.vc.TUParticipant"); component("Manager",{"participant,remote","manager,local"},"mtsb.vc.TUManager"); component("ACDB",{"participant,local","manager,remote"},"mtsb.vc.VCACDB");... } publicvoid defConnectors (){ connector("SCAccess",{"participant,local","manager,remote"},"mtsb.vc.SCAccess1"); connector("SMAccess",{"participant,remote","manager,local"},"mtsb.vc.SMAccess1");... } publicvoid loadConnections (){ String[] events1={"join"}; handlesEventsFrom("SMAccess",events1,"Manager"); String[] events2={"access"}; handlesEventsFrom("SCAccess",events2,"Participant");... } publicvoid participantInitialContext (){ try{ createComponent("Participant,SCAccess"); }catch(Exception e){System.out.println("InitialContext Error"); } } publicvoid managerInitialContext (){ try{ createComponent("Manager, ACDB,SMAccess, SSchedMP,..."); }catch(Exception e){ System.out.println("InitialContext Error ");e.printStackTrace();} } publicvoid loadOrganizationParameters (){ // Loadvalueforthe "scheduler"parameterof SSchedMPconnector }... }

64 64 Clasificación De Los Marcos De Trabajo (I) Horizontales: Horizontales: Infraestructuras de comunicaciones Infraestructuras de comunicaciones Interfaces de usuario Interfaces de usuario Entornos visuales Entornos visuales Plataformas de componentes distribuidos, etc Plataformas de componentes distribuidos, etc Verticales: Verticales: Telecomunicaciones (TINA, MultiTEL) Telecomunicaciones (TINA, MultiTEL) Fabricación Fabricación Multimedia (JMF), etc. Multimedia (JMF), etc.

65 65 Clasificación De Los Marcos De Trabajo (II) Software de base Software de base Infraestructuras de comunicaciones Infraestructuras de comunicaciones Plataformas de componentes Plataformas de componentes Generales Generales Programación de GUIs Programación de GUIs Entornos de programación visual Entornos de programación visual Programación de redes Programación de redes De Empresa De Empresa específicos de un dominio, a medida específicos de un dominio, a medida

66 66 Components Frameworks Específicos para el desarrollo de aplicaciones basadas en componentes reutilizables Específicos para el desarrollo de aplicaciones basadas en componentes reutilizables Presentan características especiales: Presentan características especiales: Composición tardía, interconexión dinámica, extensibilidad black-box, etc Composición tardía, interconexión dinámica, extensibilidad black-box, etc Suelen definirse como implementación concreta de varios patrones de diseño sobre una plataforma de componentes concreta Suelen definirse como implementación concreta de varios patrones de diseño sobre una plataforma de componentes concreta

67 67 ¿ Cuándo Resulta Conveniente Definir Un MT ? Mercado competitivo Mercado competitivo Plazos de desarrollo muy cortos Plazos de desarrollo muy cortos Dominio de aplicación complejo Dominio de aplicación complejo Solucionar problemas repetitivos Solucionar problemas repetitivos Ej: aplicaciones multimedia distribuidas

68 68 Interacción de MTs Problemas Problemas Cohesión entre las clases de un MT Cohesión entre las clases de un MT Solapamiento de dominio Solapamiento de dominio Falta de estándares de MT Falta de estándares de MT Soluciones Soluciones Adaptadores o wrappers Adaptadores o wrappers Patrones de diseño Patrones de diseño Mediadores software Mediadores software

69 69 Patrones de Diseño (Design Patterns) Complementarios con los MT Complementarios con los MT Granularidad más fina que los MT Granularidad más fina que los MT Un MT suele estar compuesto por una colección de patrones de diseño. Un MT suele estar compuesto por una colección de patrones de diseño. * Un patrón de diseño ofrece una solución abstracta a un problema de diseño que aparece muy frecuentemente, expresada mediante un conjunto de relaciones e interacciones entre sus componentes

70 70 Ventajas e Inconvenientes Ventajas: Ventajas: Permiten reutilizar soluciones de problemas comunes. Permiten reutilizar soluciones de problemas comunes. Están probados y son lo suficientemente flexibles para adaptarse a necesidades específicas. Están probados y son lo suficientemente flexibles para adaptarse a necesidades específicas. Inconvenientes: Inconvenientes: Su elevado número (falta de catalogación). Su elevado número (falta de catalogación). Su complejidad. Su complejidad. Composición poco definida. Composición poco definida.

71 71 PD: Adaptador * El PD Adapter o Wrapper se utiliza para convertir la interfaz de una clase en otra interfaz, que es la esperada por el objeto cliente. Adapta interfaces incompatibles clienteDestino Peticion() Adapter Peticion() Servidor OtraPeticion() p.OtraPeticion()

72 72 PD: Puente * El PD Bridge se utiliza para desacoplar la definición abstracta de un objeto de su implementación. De esta forma ambas pueden evolucionar independientemente Abstraccion Operacion() OperacionRedefinida Implementacion OperacionImpl() ImplementaA OperacionImpl() ImplementaB OperacionImpl() imp.OperacionImpl()

73 73 Bibliografía M. Fayad, R. Johnson y D. Schmidt, Building Application Framework, Wiley & Sons, 1999. M. Fayad, R. Johnson y D. Schmidt, Building Application Framework, Wiley & Sons, 1999. M. Fayad, R. Johnson y D. Schmidt, Implementing Application Frameworks, Wiley & Sons, 1999. M. Fayad, R. Johnson y D. Schmidt, Implementing Application Frameworks, Wiley & Sons, 1999. M. Fayad y R. Johnson, Domain-Specific Application Frameworks, Wiley & Sons, 1999. M. Fayad y R. Johnson, Domain-Specific Application Frameworks, Wiley & Sons, 1999. M. Fayad, Object-Oriented Application Frameworks, Communications of the ACM, Vol. 40, No. 10, Octubre 1997. M. Fayad, Object-Oriented Application Frameworks, Communications of the ACM, Vol. 40, No. 10, Octubre 1997. E. Gamma et. al., Design Patterns, Addison-Wesley, 1995. E. Gamma et. al., Design Patterns, Addison-Wesley, 1995. J. Bosch, Design Patterns & Frameworks: On the Issue of Language Support, Actas del Workshop Language Support for Design Patterns and Frameworks del ECOOP97. J. Bosch, Design Patterns & Frameworks: On the Issue of Language Support, Actas del Workshop Language Support for Design Patterns and Frameworks del ECOOP97.

74 74 Bibliografía M. Mattsson, J. Bosch y M. Fayad, Framework Integration, problems, causes, solutions, Communication of the ACM, Vol. 42, no. 10, octubre 1999. M. Mattsson, J. Bosch y M. Fayad, Framework Integration, problems, causes, solutions, Communication of the ACM, Vol. 42, no. 10, octubre 1999. G. Odenthal y K. Quibeldey-Cirkel, Using Patterns for Design and Documentation, actas del ECOOP97, pp.511-529, 1997. G. Odenthal y K. Quibeldey-Cirkel, Using Patterns for Design and Documentation, actas del ECOOP97, pp.511-529, 1997. D. Schmidt, A Family of Design Patterns For Flexibly Configuring Network Services in Distributed Systems, actas del ICCDS96, 1996. D. Schmidt, A Family of Design Patterns For Flexibly Configuring Network Services in Distributed Systems, actas del ICCDS96, 1996. A. Deimel, The SAP R/3 Business Framework, software - Concepts & Tools, Vol. 19, pp.29-36, 1998. A. Deimel, The SAP R/3 Business Framework, software - Concepts & Tools, Vol. 19, pp.29-36, 1998. Research on Design Patterns for Concurrent, Parallel, and Distributed Systems. http://siesta.cs.wustl.edu/~schmidt/patterns.html Research on Design Patterns for Concurrent, Parallel, and Distributed Systems. http://siesta.cs.wustl.edu/~schmidt/patterns.html http://siesta.cs.wustl.edu/~schmidt/patterns.html http://hillside.net/patterns/ http://hillside.net/patterns/ http://hillside.net/patterns/ http://hillside.net/patterns/books/ http://hillside.net/patterns/books/ http://hillside.net/patterns/books/