arquitecturas de software 2 - estilos...5 universidad rey juan carlos arquitectura de software...

Estilos Arquitectónicos

Diseño y Arquitectura de Software

Grado en Ingeniería de Software

Carlos E. Cuesta

[email protected]

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.



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



Arquitectura Filtro-Tubería (Pipes & Filters)

Incorporada como elemento base en Unix (McIlroy)

Hoy con un significado mucho más amplio

Tuberías

Filtros



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



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



Arquitecturas de Sistemas OO

Se incluyen otros Tipos Abstractos de Datos

obj objetos

op Operaciones

(invocaciones a

métodos)



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



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



Invocación Implícita (Basada en Eventos)

?

?

? ?

? ?

?

! !

! !

!

!

!

Objetos o

Procesos

Invocación

Implícita

Emisión de

eventos



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

?

?

? ?

? ?

?

! !

! !

!

!

!



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

?

?

? ?

? ?

?

! !

! !

!

!

!



Sistemas basados en Capas

Aplicaciones

Usuarios

Utilidad básica

Nivel

Núcleo

Llamadas a

Procedimientos




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




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



Sistemas basados en repositorios

Pizarra

(datos Compartidos)

ks7

ks8

ks6 ks5

ks4

ks3

ks2 ks1

Memoria compartida

(típicamente asociativa)

Procesamiento

Accesos Directos




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




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



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



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



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


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



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

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)


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/

http://sunset.usc.edu/classes/cs578_2005/

arquitecturas de software 2 - estilos...5 universidad rey juan carlos arquitectura de software...

Documents