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 Raúl Monge Departamento de Informática Universidad Técnica Federico Santa María. Chile

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

1ª Parte: Arquitecturas del Software
Servicios Avanzados Multimedia basados en Componentes 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

Servicios Avanzados Multimedia basados en Componentes
Contenido Estilos Arquitectónicos Lenguajes de Descripción de Arquitecturas Programación Orientada a Componentes

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

Sistemas Abiertos Concurrentes Reactivos Independientemente extensibles Heterogéneos Evolutivos Distribuidos

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

Arquitectura del Software
Servicios Avanzados Multimedia basados en Componentes 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

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)

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

Descripción de una AS 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.

Arquitectura Productor/Consumidor Emisor Buffer Receptor

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

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

El “territorio” de las AS
Servicios Avanzados Multimedia basados en Componentes El “territorio” de las AS Adaptado de P. Kruchten, B. Selic, W. Kozaczynski. “Describing Software Architecture with UML”, 2001

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

Niveles de Abstracción
Servicios Avanzados Multimedia basados en Componentes 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

Estilos Arquitectónicos
Servicios Avanzados Multimedia basados en Componentes 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

Clasificación de estilos
Servicios Avanzados Multimedia basados en Componentes 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

Estilos y subestilos (I)
Servicios Avanzados Multimedia basados en Componentes 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

Estilos y subestilos (II)
Servicios Avanzados Multimedia basados en Componentes 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

Descripción de Arquitecturas
Servicios Avanzados Multimedia basados en Componentes 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)

Lenguajes de Descripción de Arquitecturas (LDAs)
Servicios Avanzados Multimedia basados en Componentes 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)

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

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

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

Ejemplos de LDAs : UNICON
Servicios Avanzados Multimedia basados en Componentes 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 end sink end protocol ... implementation is builtin end implementation end Unix-Pipe

Ejemplos de LDAs : Wright
Servicios Avanzados Multimedia basados en Componentes 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

Ejemplos de LDAs : RAPIDE
Servicios Avanzados Multimedia basados en Componentes 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;

Ejemplos de LDAs : Darwin
Servicios Avanzados Multimedia basados en Componentes Ejemplos de LDAs : Darwin entrada cabeza : Filtro ant salida : Pipeline cauce : Pipeline sig

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

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

Lenguajes de especificación de servicios 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”) enddef DoM

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

Lenguajes de especificación de servicios 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”) protocol is type Service std(SDL) {...} enddef MSelector

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

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

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

Lenguajes de especificación de servicios LCF set parties unicast Tipo de servicio Asignación de nombres lógicos a físicos set msap <url> 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=””

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

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

Un ejemplo en LEDA (III)
Servicios Avanzados Multimedia basados en Componentes 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); }

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

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

Arquitectura Software vs. COTS
Servicios Avanzados Multimedia basados en Componentes 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

Ingeniería del Software basada en Componentes
Servicios Avanzados Multimedia basados en Componentes Ingeniería del Software basada en Componentes Componentes unidos a una 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

AS: problemas y líneas abiertas
Servicios Avanzados Multimedia basados en Componentes AS: problemas y líneas abiertas Definición de AS Expresión de parámetros de calidad Medidas Herramientas Relación con el dominio de aplicación ‘Vistas’ arquitectónicas

P1. Definición de AS 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: “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”

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

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

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

P5. Dominio de Aplicación
Servicios Avanzados Multimedia basados en Componentes P5. Dominio de Aplicación 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

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

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

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.

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

Desarrollo de Aplicaciones basado en Componentes y Frameworks

Presentaciones similares

Presentación del tema: "Desarrollo de Aplicaciones basado en Componentes y Frameworks"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Desarrollo de Aplicaciones basado en Componentes y Frameworks

Presentaciones similares

Presentación del tema: "Desarrollo de Aplicaciones basado en Componentes y Frameworks"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback