1 / 74

Arquitecturas Software y Marcos de Trabajo

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

florence
Download Presentation

Arquitecturas Software y Marcos de Trabajo

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

  2. Contenido • Arquitectura del Software • Estilos Arquitectónicos • Lenguajes de Descripción de Arquitecturas • Programación Orientada a Componentes • MTs y Patrones de Diseño • Patrones de Diseño: su utilidad • MTs (Frameworks) orientados a objetos y a componentes • Clasificación de los MTs

  3. Arquitectura del Software: 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

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

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

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

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

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

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

  10. Emisor Receptor Buffer Arquitectura Productor/Consumidor

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

  12. 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 • MTs • 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

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

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

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

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

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

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

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

  20. Requisitos de un ADL • Composición • Debe describir el sistema como una composió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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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. 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. 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. Comparación de LDAs

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

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

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

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

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

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

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

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

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

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

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

More Related