Estilos Arquitectónicos

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Estilos Arquitectónicos"

Alicia Camacho Castilla
hace 8 años
Vistas:

1 Diseño y Arquitectura de Software Grado en Ingeniería de Software Carlos E. Cuesta [email protected]

2 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 Determinan sus ventajas e inconvenientes Condicionan la elección de uno u otro estilo. 2

3 Clasificación General de los Estilos Sistemas Basados en Flujos de Datos Filtro-Tubería Secuencial por Lotes Sistemas Call/Return Sistema Modular Arquitectura Orientada a Objetos Jerarquía de Capas Componentes Independientes Procesos en Comunicación Sistemas de Eventos Máquinas Virtuales Intérpretes Sistemas basados en conocimiento (KBS) Sistemas de Control Lazo Abierto o Cerrado Sistemas Centrados en Datos (repositorios) Bases de Datos Sistemas de HiperTexto Modelo REST (también) Arquitectura de Pizarra 3

4 Arquitectura Filtro-Tubería (Pipes & Filters) Incorporada como elemento base en Unix (McIlroy) Hoy con un significado mucho más amplio Filtros Tuberías 4

5 Filtros y Tuberías (Pipes & Filters) Descripción Cada componente tiene un conjunto de entradas y un conjunto de salidas. Un componente lee 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 del estilo Pipelines Bounded pipes Typed pipes 5

6 Filtros y Tuberías (Pipes & Filters) 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 independientes de sus vecinos Facilidad de Mantenimiento y mejora Facilidad de diagnóstico (rendimiento, deadlocks) Soportan la ejecución concurrente Desventajas No aconsejable para cuando se necesita interactividad Problemas de rendimiento ya que los datos 6 se transmiten en forma completa entre filtros

7 Arquitecturas de Sistemas OO Se incluyen otros Tipos Abstractos de Datos obj objetos op Operaciones (invocaciones a métodos) 7

8 Arquitectura de Sistemas 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: Los objetos son responsables de la integridad de sus representaciones Dicha representación es ocultada al resto de los objetos 8

9 Tipos Abstractos de Datos y OO Ventajas Gracias al invariante de ocultación es posible reemplazar la implementación sin que afecte a los clientes ( clientes del objeto) Desventajas Para invocar métodos de un objeto se debe conocer su identidad Parece obvio pero no lo es en absoluto Efectos colaterales 9

10 Invocación Implícita (Basada en Eventos) Emisión de eventos Objetos o Procesos Invocación Implícita 10

11 Invocación Implícita Basada en Eventos Descripción En lugar de invocaciones de procedimientos explícitas 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 implícita 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 la ligadura de eventos con llamadas a procedimientos 11

12 Invocación Implícita (Basada en Eventos) Restricciones: Quien anuncia el evento no conoce a qué componentes afecta éste No se pueden hacer asunciones acerca del orden de procesamiento Ventajas Provee un robusto soporte para la reutilización Facilita la evolución del sistema Desventajas Pérdida de control en el comportamiento del sistema Problemas en el intercambio de datos Es difícil asegurar la corrección global del sistema 12

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

14 Sistemas basados 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: La interacción está limitada a las capas adyacentes Aplicaciones 14

15 Sistemas basados en Capas Ventajas Facilita la descomposición del problema en varios niveles de abstracción. Soporta fácilmente la evolución del sistema; los cambios sólo 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. A menudo es difícil encontrar la separación en capas adecuada Aplicaciones 15

16 Sistemas basados en repositorios ks1 ks2 Procesamiento ks8 ks7 Pizarra (datos Compartidos) ks3 ks4 Accesos Directos ks6 ks5 Memoria compartida (típicamente asociativa) 16

17 Sistemas basados en repositorios 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 ks7 ks1 Pizarra (datos Compartidos) ks2 ks3 ks4 17 ks6 ks5

18 Sistemas basados en repositorios 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 18 ks6 ks5

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

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

21 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 Sistemas de Transición de Estados Arquitecturas Heterogéneas Se da por la mezcla de estilos Existen diferentes maneras de combinar 21

22 Lenguajes de Descripción de Arquitecturas (LDA) Un LDA (ADL) es un lenguaje o notación para describir una arquitectura software: Descripción de los componentes, los conectores y enlaces entre ellos A menudo existen también 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/DSSA) Requisitos de un LDA Composición Debe describir el sistema como una composición de partes 22

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

24 Lenguajes de Descripción de Arquitecturas (LDA) Ejemplos Lenguajes de Descripción de Arquitectura: Unicon (Mary Shaw y colaboradores, CMU) Wright (Allen y Garlan, SEI) Darwin (Magee y Kramer, IC) Rapide (Luckham, Stanford) C2 (Medvidovic, UCI/USC) LEDA (Canal, U. Málaga) Se trata o no de un ADL Lenguaje Unificado de Modelado (UML) Lenguajes de interconexión de módulos y de descripción de interfaz (CORBA-IDL) 24

25 Bibliografía Software Architecture Perspectives on an Emerging Discipline M. Shaw, D. Garlan 1997 Prentice Hall. Design and Use of Software Architectures J. Bosch 2000 Addison Wesley Documenting Software Architectures: Views and Beyond P. Clements, F. Bachmann, L. Bass et al Addison Wesley Software Architectures (USC CS 578) 25

Documentos relacionados

Arquitecturas de Software

Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña [email protected] Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO