Arquitecturas de Software

Transcripción

1 Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña

2 Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO Invocación Implícita Basada en Eventos Sistemas en Capas Sistemas basados en depósitos Máquina Virtual o Interprete 2

3 Introducción Motivación Incremento en el tamaño y complejidad del software Necesidad de aprender de la experiencia: reutilización de estructuras asociadas a problemas similares Una adecuada estructura general es tan importante como las implementaciones concretas de las partes. Definición La arquitectura de software de un programa o de un sistema computacional esta definida por la estructura, comprendida por los elementos de software, la propiedades visibles de esos elementos y las relaciones entre ellos. 3

4 Introducción Incluyendo: la descripción de los componentes con los cuales se construyen los sistemas las interacciones entre esos componentes patrones para guiar la composición restricciones sobre dichos patrones Componentes: servidores, clientes, bases de datos, filtros, capas en un sistema jerárquico, etc. Interacciones: llamadas a procedimientos, protocolos C/S, protocolos de acceso a BD, etc. 4

5 Introducción De qué se ocupa Diseño preliminar o de alto nivel. Organización a alto nivel del sistema, incluyendo aspectos como la descripción y análisis de propiedades relativas a su estructura y control global, los protocolos de comunicación y sincronización utilizados, la distribución física del sistema y sus componentes, etc. Otros aspectos relacionados con el desarrollo del sistema y su evolución y adaptación al cambio: composición, reconfiguración, reutilización, escalabilidad, mantenibilidad, etc. 5

6 Introducción De qué no se ocupa Diseño detallado. Diseño de algoritmos. Diseño de estructuras de datos. 6

7 Indican: Los tipos de componentes y conectores involucrados. Patrones y restricciones de interconexión o composición entre ellos: Invariantes del estilo (restricciones) Asociados a cada estilo hay una serie de propiedades que lo caracterizan, determinando sus ventajas e inconvenientes, condicionando la elección de uno u otro estilo. 7

8 Clasificación General de los Estilos Sistemas Basados en Flujos de Datos Máquinas Virtuales Interpretes Pipes and filters (tuberías y filtros) Sistemas basados en el conocimiento Batch Sequential Sistemas Call/Return Sistemas Centrados en Datos (repositorios) Sistemas Principal/subrutinas Bases de Datos Sistemas OO Sistemas de HiperTexto Capas jerárquicas Sistemas de pizarra Componentes Independientes Procesos de comunicación Sistemas de Acontecimientos 8

9 Pipes and Filters (tuberías y filtros) Filters Pipes 9

10 Pipes and Filters (tuberías y filtros) 10 Descripción Cada componente tiene un conjunto de entradas y un conjunto de salidas. Cada componente lee las entradas y las transforma en salidas. Restricciones: Los filtros deben ser independientes. No deben compartir estado con otros filtros. Los filtros realizan la labor independientemente del flujo de entrada. Especializaciones Pipelines Bounded pipes Typed pipes

11 Pipes and Filters (tuberías y filtros) 11 Ventajas Permite entender el sistema global en términos de la combinación de componentes Soporta de buena manera la reutilización. Los filtros son idependientes de sus vecinos Facilidad de Mantenimiento y mejora Facilidad de diagnóstico (rendimiento, deadlocks) Soportan la ejecución concurrente Desventajas No aconsejado para cuando se necesita interactividad Problemas de performance ya que los datos se transmiten en forma completa entre filtros

12 Tipos Abstractos de Datos y OO Obj: objetos Op:invocaciones a métodos 12

13 Tipos Abstractos de Datos y OO Descripción Las representaciones de los datos y las operaciones están encapsulados en un tipo abstracto de datos u objeto Los componentes son objetos Las invocaciones de métodos son los conectores Restricciones: Ventajas Los objetos son responsables de la integridad de sus representaciones Dicha representación es ocultada al resto de los objetos Gracias al invariante de ocultación es posible reemplazar la Implementación si que afecte a los clientes 13

14 Tipos Abstractos de Datos y OO Desventajas Para invocar métodos de un objeto se debe conocer su identidad Efectos colaterales 14

15 Invocación Implícita Basada en Eventos!!!!!!! Objetos o Procesos Invocación Implícita 15

16 Invocación Implícita Basada en Eventos Descripción En lugar de invocaciones de procedimientos explicitas o directas, un componente anuncia uno o más eventos y otros componentes registran el interés en un evento asociando un procedimiento a dicho evento. La ocurrencia de un evento causa la invocación implicita de procedimientos en otros módulos. Los componentes son los módulos cuyas interfaces ofrecen un conjunto de procedimientos y de eventos Los conectores incluyen llamadas a procedimientos tradicionales así como el ligado de eventos con llamadas a procedimientos!!!!!!! 16

17 Invocación Implícita Basada en Eventos Restricciones: Quien anuncia el evento no conoce a que componentes afecta el evento No se pueden hacer asunciones acerca del orden de procesamiento Ventajas Provee un robusto soporte de reusabilidad Facilita la evolución del sistema Desventajas Perdida de control en el comportamiento del sistema Problemas en el intercambio de datos Es difícil asegurar la corrección global del sistema!!!!!!! 17

18 Sistemas en Capas Aplicaciones Llamadas a Procedimientos Utilidad básica Nivel Núcleo Usuarios 18

19 Sistemas en Capas Descripción Organizado jerárquicamente en capas, donde cada capa provee servicios a la capa superior y es servido por la capa inferior Los componentes son cada una de las capas Los conectores son los protocolos de interacción entre las capas Restricciones: Ventajas La interacción está limitada a las capas adyacentes Facilita la descomposición del problema en varios niveles de abstracción. Aplicaciones 19

20 Sistemas en Capas Soporta la mejora, los cambios solo afectan a las capas vecinas Se pueden cambiar las implementaciones respetando las interfaces con las capas adyacentes. Desventajas No todos los sistemas pueden estructurarse en capas. Es difícil encontrar la separación en capas adecuada Aplicaciones 20

21 Sistemas basados en depósitos ks1 ks2 Procesamiento ks8 ks7 Pizarra (datos Compartidos) ks3 ks4 Accesos Directos ks6 ks5 Memoria 21

22 Sistemas basados en depósitos Descripción Existen dos tipos de componentes Una estructura central de datos (representa el estado del proceso) Componentes independientes (operan en función del depósito de datos) Las interacciones entre el repositorio y los demás componentes es variable: La entrada de los datos es seleccionada por los componentes El estado de los datos del repositorio selecciona el proceso a ejecutar (pizarra) ks8 ks1 ks2 ks3 ks7 Pizarra (datos Compartidos) ks4 22 ks6 ks5

23 Sistemas basados en depósitos Ventajas Posibilita la integración de agentes. Adecuado para la resolución de problemas no deterministas. Se puede resumir el estado de conocimiento en cada momento del proceso Desventajas Estructura de datos común a todos los agentes Problemas de carga a la hora de chequear y vigilar el estado de la pizarra. ks1 ks2 ks8 ks7 Pizarra (datos Compartidos) ks3 ks4 23 ks6 ks5

24 Máquina virtual o intérprete Entradas Datos (Estado del programa) Programa siendo interpretado Salidas Máquina de Interpretación simulada Instrucción seleccionada Datos seleccionados Estado Interno Del Interprete 24

25 Máquina virtual o intérprete Descripción Formado por cuatro componentes Ventajas Un motor de simulación o interpretación Una memoria que contiene el código a interpretar Una representación del estado de la interpretación Una representación del estado del programa que se esta simulando Solución software a problemas hardware. Desventajas No siempre es aplicable Reducido a lenguajes de programación 25

26 Otros Estilos Procesos distribuidos Sistemas cliente/servidor Sistemas en 3 capas Programa Principal/Subrutinas Típica de lenguajes procedurales Un programa principal gestiona el control de ejecución de las subrutinas Transición de Estados Arquitecturas Heterogéneas Se da por la mezcla de estilos Existen diferentes maneras de combinar 26

27 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) Requisitos Composición Debe describir el sistema como una composición de partes 27

28 Lenguajes de Descripción de Arquitecturas (LDAs) 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 28

29 Lenguajes de Descripción de Arquitecturas (LDAs) Ejemplos Lenguaje Unificado de Modelado (UML) Lenguajes de interconexión de módulos y de descripción de interfaz (CORBA-IDL) Lenguajes de descripción de arquitectura: Unicon (Mary Shaw y colaboradores - CMU) Wright (Allen y Garlan) Darwin (Magee y Kramer - IC) Rapide (Luckham) C2 (Medvidovic) LEDA (U. Málaga) 29

30 Bibliografía Software Architecture Perspective on an Emerging discipline M. Shaw, D. Garlan Ed. Prentice Hall. Software Architecture in Practice (2nd Edition) L. Bass, P. Clements, R. Kazman Ed. Addison Wesley Arquitecturas de SW: Servicios Avanzados Multimedia Basados en Componentes: arquitecturas.ppt 30