Arquitecturas de Software - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~mad/Arquitecturas de...

Arquitecturas de Software

Ingeniería del Software IUniversidad Rey Juan Carlos

César Javier AcuñaCésar Javier Acuñ[email protected]@escet.urjc.es

Universidad Rey Juan Carlos - Ingenieria del Software I

2

ARQUITECTURAS SOFTWAREÍndice

� Introducción� Motivación� Definición

� Estilos Arquitectónicos� 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


3

ARQUITECTURAS SOFTWAREIntroducció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.


4


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


5


� ¿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.


6


� ¿De qué no se ocupa?� Diseño detallado.� Diseño de algoritmos.� Diseño de estructuras de datos.


7

ARQUITECTURAS SOFTWAREEstilos 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, determinando sus ventajas e inconvenientes, condicionando la elección de uno u otro estilo.


8

ARQUITECTURAS SOFTWAREEstilos Arquitectónicos

� Sistemas Basados en Flujos de Datos� Pipes and filters (tuberías y

filtros)� Batch Sequential

� Sistemas Call/Return� Sistemas Principal/subrutinas� Sistemas OO� Capas jerárquicas

� Componentes Independientes� Procesos de comunicación� Sistemas de Acontecimientos

� Máquinas Virtuales� Interpretes� Sistemas basados en el

conocimiento

� Sistemas Centrados en Datos (repositorios)� Bases de Datos� Sistemas de HiperTexto� Sistemas de pizarra

Clasificación General de los Estilos


9

ARQUITECTURAS SOFTWAREEstilos Arquitectónicos� Pipes and Filters (tuberías y filtros)

Pipes

Filters


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


� 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

ARQUITECTURAS SOFTWAREEstilos Arquitectónicos� Tipos Abstractos de Datos y OO

Obj: objetosOp:invocaciones a

métodos


13


� 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

� Ventajas� Gracias al invariante de ocultación es posible

reemplazar la Implementación si que afecte a los clientes


14


� Desventajas� Para invocar métodos de un objeto se debe conocer

su identidad� Efectos colaterales


15

ARQUITECTURAS SOFTWAREEstilos Arquitectónicos� Invocación Implícita Basada en Eventos

?

?

??

??

?

! !!!

!

!

!

Objetos o Procesos

Invocación Implícita


16


� 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

?

?

??

??

?

! !!!

!!

!


17


� 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?

?

??

??

?

! !!!

!!

!


18

ARQUITECTURAS SOFTWAREEstilos Arquitectónicos� Sistemas en Capas

Aplicaciones

Usuarios

Utilidad básica

NivelNúcleo

Llamadas aProcedimientos


19


� 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

� Ventajas� Facilita la descomposición del problema en varios

niveles de abstracción.

Aplicaciones


20


� 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


21

ARQUITECTURAS SOFTWAREEstilos Arquitectónicos� Sistemas basados en depósitos

Pizarra(datos Compartidos)

ks7

ks8

ks6 ks5

ks4

ks3

ks2ks1

Memoria

Procesamiento

Accesos Directos


22


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


ks7

ks8

ks6 ks5

ks4

ks3

ks2ks1


23


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


ks7

ks8

ks6 ks5

ks4

ks3

ks2ks1


24

ARQUITECTURAS SOFTWAREEstilos Arquitectónicos� Máquina virtual o intérprete

Datos(Estado del programa)

Programa siendo

interpretado

Máquina deInterpretación

simulada

Estado InternoDel Interprete

Instrucción seleccionadaDatos seleccionados

Entradas

Salidas


25

ARQUITECTURAS SOFTWAREEstilos 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


26

ARQUITECTURAS SOFTWAREEstilos 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

� Transición de Estados� Arquitecturas Heterogéneas

� Se da por la mezcla de estilos� Existen diferentes maneras de combinar


27

ARQUITECTURAS SOFTWARELenguajes 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


28


(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


29


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


30

ARQUITECTURAS SOFTWAREBibliografí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: http://lml.ls.fi.upm.es/~jjmoreno/sbc/arquitecturas_sw.ppt

� Servicios Avanzados Multimedia Basados en Componentes: http://www.lcc.uma.es/~av/misConfs/p1-arquitecturas.ppt

Arquitecturas de Software - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~mad/Arquitecturas de...

Documents

Transcript of Arquitecturas de Software - pegasus.javeriana.edu.copegasus.javeriana.edu.co/~mad/Arquitecturas de...