arquitecturas de software 2 - estilos...5 universidad rey juan carlos arquitectura de software...
Post on 26-May-2020
8 Views
Preview:
TRANSCRIPT
Estilos Arquitectónicos
Diseño y Arquitectura de Software
Grado en Ingeniería de Software
Carlos E. Cuesta
carlos.cuesta@urjc.es
Universidad Rey Juan Carlos 2
Arquitectura de Software Estilos Arquitectónicos
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.
Universidad Rey Juan Carlos 3
Arquitectura de Software Estilos Arquitectónicos
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
Clasificación General de los Estilos
Universidad Rey Juan Carlos 4
Arquitectura de Software Estilos Arquitectónicos
Arquitectura Filtro-Tubería (Pipes & Filters)
Incorporada como elemento base en Unix (McIlroy)
Hoy con un significado mucho más amplio
Tuberías
Filtros
Universidad Rey Juan Carlos 5
Arquitectura de Software Estilos Arquitectónicos
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
Universidad Rey Juan Carlos 6
Arquitectura de Software Estilos Arquitectónicos
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
se transmiten en forma completa entre
filtros
Universidad Rey Juan Carlos 7
Arquitectura de Software Estilos Arquitectónicos
Arquitecturas de Sistemas OO
Se incluyen otros Tipos Abstractos de Datos
obj objetos
op Operaciones
(invocaciones a
métodos)
Universidad Rey Juan Carlos 8
Arquitectura de Software Estilos Arquitectónicos
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
Universidad Rey Juan Carlos 9
Arquitectura de Software Estilos Arquitectónicos
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
Universidad Rey Juan Carlos 10
Arquitectura de Software Estilos Arquitectónicos
Invocación Implícita (Basada en Eventos)
?
?
? ?
? ?
?
! !
! !
!
!
!
Objetos o
Procesos
Invocación
Implícita
Emisión de
eventos
Universidad Rey Juan Carlos 11
Arquitectura de Software Estilos Arquitectónicos
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
?
?
? ?
? ?
?
! !
! !
!
!
!
Universidad Rey Juan Carlos 12
Arquitectura de Software Estilos Arquitectónicos
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
?
?
? ?
? ?
?
! !
! !
!
!
!
Universidad Rey Juan Carlos 13
Arquitectura de Software Estilos Arquitectónicos
Sistemas basados en Capas
Aplicaciones
Usuarios
Utilidad básica
Nivel
Núcleo
Llamadas a
Procedimientos
Universidad Rey Juan Carlos 14
Arquitectura de Software Estilos Arquitectónicos
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
Universidad Rey Juan Carlos 15
Arquitectura de Software Estilos Arquitectónicos
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
Universidad Rey Juan Carlos 16
Arquitectura de Software Estilos Arquitectónicos
Sistemas basados en repositorios
Pizarra
(datos Compartidos)
ks7
ks8
ks6 ks5
ks4
ks3
ks2 ks1
Memoria compartida
(típicamente asociativa)
Procesamiento
Accesos Directos
Universidad Rey Juan Carlos 17
Arquitectura de Software Estilos Arquitectónicos
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)
Pizarra
(datos Compartidos)
ks7
ks8
ks6 ks5
ks4
ks3
ks2 ks1
Universidad Rey Juan Carlos 18
Arquitectura de Software Estilos Arquitectónicos
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.
Pizarra
(datos Compartidos)
ks7
ks8
ks6 ks5
ks4
ks3
ks2 ks1
Universidad Rey Juan Carlos 19
Arquitectura de Software Estilos Arquitectónicos
Máquina virtual (o intérprete)
Datos
(Estado del
programa)
Programa
siendo
interpretado
Máquina de
Interpretación
simulada
Estado Interno
Del Interprete
Instrucción
seleccionada
Datos
seleccionados
Entradas
Salidas
Universidad Rey Juan Carlos 20
Arquitectura de Software Estilos Arquitectónicos
Máquina virtual o intérprete
Descripción
Formado por cuatro componentes
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
Ventajas
Solución software a problemas hardware.
Desventajas
No siempre es aplicable
Reducido a lenguajes de programación
Universidad Rey Juan Carlos 21
Arquitectura de Software Estilos Arquitectónicos
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
Universidad Rey Juan Carlos 22
Arquitectura de Software 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
Universidad Rey Juan Carlos 23
Arquitectura de Software 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
Universidad Rey Juan Carlos 24
Arquitectura de Software 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)
Universidad Rey Juan Carlos 25
Arquitectura de Software 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.
2003 Addison Wesley
Software Architectures (USC CS 578)
http://sunset.usc.edu/classes/cs578_2005/
top related