1 / 56

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

paco
Download Presentation

Desarrollo de Aplicaciones basado en Componentes y Frameworks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Contenido Global del Curso: • Arquitecturas de Software • Marcos de Trabajo (Frameworks) • Programación orientada a Componentes

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

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

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

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

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

  8. AS 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)

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

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

  12. Emisor Receptor Buffer Arquitectura Productor/Consumidor

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

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

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

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

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

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

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

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

  23. 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)

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

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

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

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

  28. Ejemplos de LDAs : Wright • Una pipe de Unix connector Pipe = role WRITER = write  WRITER  close   role READER = let ExitOnly = close  inlet DoRead = (read  READER □ readEoF  ExitOnly in DoRead  ExitOnly glue = let ReadOnly = READER.read  readOnly □ READER.readEoF  READER.close  □ READER.close  inlet WriteOnly = WRITER.write  WriteOnly □ WRITER.close in WRITER.write  glue□ READER.read  glue □ WRITE.close  ReadOnly □ READER.close  WriteOnly

  29. 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;

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

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

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

  33. 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”) • end • enddef DoM

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

  35. 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”) • end • protocolis • type Service • std(SDL) {...} • end • enddef MSelector

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

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

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

  39. 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 puttext “Fich.clientes” parname acdb::acdbfich value=”” • put text “Tipo acceso” implementation scaccess value=”” Lenguajes de especificación de servicios LCF

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

  44. Comparación de LDAs

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

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

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

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

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

More Related