580 likes | 909 Vues
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
E N D
Desarrollo de Aplicaciones basado en Componentes y Frameworks Antonio Vallecillo GISUM: Grupo de Ingeniería del Software de la Universidad de Málaga Departamento de Lenguajes y Ciencias de la Computación Universidad de Málaga. España av@lcc.uma.es Raúl Monge Departamento de Informática Universidad Técnica Federico Santa María. Chile rmonge@inf.utfsm.l
Contenido Global del Curso: • Arquitecturas de Software • Marcos de Trabajo (Frameworks) • Programación orientada a 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 av@lcc.uma.es
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 • 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
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)
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.
Emisor Receptor Buffer Arquitectura Productor/Consumidor
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 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 • 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 • 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 • 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) • 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) • 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 • 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) • 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)
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
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
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
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
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;
cabeza : Filtro cauce : Pipeline entrada ant sig entrada salida salida : Pipeline salida Ejemplos de LDAs : Darwin
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
Tipo Componente: Tipo • Atributos Atributos • Mensajes + eventos Método()-----> Lenguajes de especificación de servicios LDC: Componentes • Propagación de eventos • Interfaz
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
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
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
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
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};
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
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
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) component ProducerConsumer { interface ... composition p: Sender; c: Receiver; b: Buffer; attachments p.writer(write) <> b.storage(write); b.retrieval(read) <> c.reader(read); }
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
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 • 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 • 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 • 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