Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Estilos Arquitectnicos
Juan Carlos Ramos Natalia Depetris UTN - FRSF 2004-2012
Estilos Arquitectnicos
Un estilo arquitectnico en software es anlogo al concepto en construccin de edificios. Consiste de algunas caractersticas claves y reglas para combinar estas caractersticas.
Estilos Arquitectnicos
Un conjunto de tipos de componentes (proceso, repositorio, etc.) que realiza alguna funcin en tiempo de ejecucin. Una distribucin topolgica de las componentes que indica su interrelacin en tiempo de ejecucin. Un conjunto de restricciones semnticas. Un conjunto de conectores que permiten la comunicacin, coordinacin o cooperacin entre los componentes.
Diseo de SWBA - ISI - UTN - FRSF 3
Estilos Arquitectnicos
Un estilo NO es una arquitectura. Un estilo define una clase de arquitecturas. Son ambiguos sobre:
La cantidad de componentes Los mecanismos utilizados para la interaccin La funcin del sistema.
Estilos Arquitectnicos
Centrados en Datos
Repositorio Blackboard Intrprete Sistemas Basados en Reglas Programa Principal y Subrutinas Orientado a Objetos Capas
5
Mquinas Virtuales
Llamada-Retorno
Estilos Arquitectnicos
Permiten definir: Cul es el vocabulario de diseo? Cules son los patrones estructurales disponibles? Cul es el modelo computacional subyacente? Cules son las invariantes esenciales del estilo? Cules son algunos ejemplos de su uso? Cules son las ventajas y desventajas de usar el estilo? Cules son algunas de las especializaciones comunes?
Estilos Arquitectnicos
Flujos de Datos
Estilos Arquitectnicos
Flujo de Datos
Objetivo: alcanzar las cualidades de reuso y modificabilidad. Caracterizado por ver al sistema como una serie de transformaciones sobre piezas sucesivas de entradas de datos. Los datos ingresan al sistema y luego fluyen a travs de las componentes hasta que son asignados a algn destino final.
Diseo de SWBA - ISI - UTN - FRSF 8
Cada componente tiene un conjunto de entradas (inputs) y un conjunto de salidas (outputs) Una componente lee flujo de datos en sus entradas y produce flujos de datos sobre sus salidas. La transformacin interna comienza a producir salidas antes de que se consuma toda la entrada.
Diseo de SWBA - ISI - UTN - FRSF 9
Pipes
10
Los filtros deben ser entidades independientes. No deben compartir estado con otros filtros. Los filtros no conocen la identidad de sus filtros de entrada ni de salida. Pueden restringir qu debe aparecer en las entradas, o garantizar qu saldr por sus salidas. La correctitud de la salida de una red pipe-and-filter no depende (en general) del orden en el cual los filtros realizan el procesamiento incremental.
Diseo de SWBA - ISI - UTN - FRSF 11
Restringen la topologa a una secuencia lineal Restringen la cantidad de datos que puede residir sobre un pipe Restringen que los datos en los pipes sean de un tipo bien definido
Diseo de SWBA - ISI - UTN - FRSF 12
Pipe limitados
Pipes Tipados
Un filtro procesa todos sus datos de entrada como una entidad simple.
13
Anlisis Sintctico
Anlisis Semntico
Permite comprender el comportamiento de entrada / salida de un sistema como la composicin del comportamiento de los filtros individuales. Soportan reuso Facilita el mantenimiento y crecimiento Permiten realizar anlisis de deadlock y rendimiento Soporte de ejecucin concurrente
15
Frecuentemente tienden a una organizacin de procesamiento batch No son buenos para aplicaciones interactivas. Pueden complicarse al tener que mantener dos flujos separados pero relacionados. Puede ser necesario agregar a los filtros conversin de datos de entrada y salida Prdida de performance e incremento de complejidad de los filtros.
Diseo de SWBA - ISI - UTN - FRSF 16
Una solucin pipe-filter: Filtro Split: divide el stream de entrada. Filtros Upper y Lower: manipulan cada substring resultante en forma separada. Filtro Merge: une nuevamente los substrings transformados.
Diseo de SWBA - ISI - UTN - FRSF 17
Split
Merge
Lower
18
Merge
Config
Libreras de Input/Output
19
Este diagrama falla para capturar la composicin arquitectnica Indica los mdulos que estn presentes en el sistema, y qu mdulos se refieren a la implementacin. No muestra los pipes
20
Las relaciones de interaccin estn resaltadas. Las dependencias de implementacin son suprimidas Claramente resalta el diseo arquitectnico
21
22
Estilos Arquitectnicos
Llamada - Retorno
23
Estilos Arquitectnicos
Llamada-Retorno (Call-and-Return)
24
Paradigma de programacin clsico. Objetivo: descomponer un programa en pequeas piezas para alcanzar la modificabilidad. Programa descompuesto jerrquicamente. Hay un camino de control simple: cada componente toma el control de su padre y pasa este a sus hijos.
Diseo de SWBA - ISI - UTN - FRSF 25
Sub 1
Sub 2
Sub 3
26
Son sistemas programa principal y subrutinas descompuesto en partes que residen en computadoras conectadas por una red. Objetivo: incrementar la performance distribuyendo la computacin tomando ventaja de mltiples procesadores. La asignacin de partes a procesadores es diferida hasta tiempo de ejecucin.
Ejemplo
28
La representacin de datos y sus operaciones primitivas estn encapsuladas en un tipo de dato abstracto u objeto. Objetivo: alcanzar la calidad de modificabilidad. Componentes: Objetos o tipos de datos abstractos Conexin: Interactan a travs de invocacin de mensaje o funciones y procedimientos Objetos Manager: responsable de preservar la integridad de un recurso (su representacin).
Diseo de SWBA - ISI - UTN - FRSF 30
Objetos o Managers
Obj3
Invocacin a funciones
Obj2 Obj4
32
34
35
Objetivo: modificabilidad y portabilidad. Organizado jerrquicamente. Invariante: Cada capa provee un servicio a la capa superior y es cliente de la capa inferior. Las capas internas deben estar visibles slo a las capas adyacentes. Pueden exportarse algunas funciones a capas no adyacentes Los conectores son definidos por los protocolos de comunicacin entre capas.
Diseo de SWBA - ISI - UTN - FRSF 36
Sistemas de Capas
Basic Utility
Core
Diseo de SWBA - ISI - UTN - FRSF 37
Sistemas de Capas
Beneficios: Soportan diseo basado en niveles incrementales de abstraccin. Soportan ampliaciones: los cambios en una capa solo afectan a las lindantes. Soportan reuso: se pueden cambiar una capa manteniendo el protocolo.
Diseo de SWBA - ISI - UTN - FRSF 38
Sistemas de Capas
Desventajas: No todos los sistemas pueden ser estructurados como capas. Para mejor performance puede requerirse de alto acoplamiento entre las capas de diferente niveles. Puede ser muy difcil determinar los niveles correctos de abstraccin.
Diseo de SWBA - ISI - UTN - FRSF 39
Sistemas de Capas
Llamadas a procedimientos
Usuarios
Diseo de SWBA - ISI - UTN - FRSF 40
Sistemas de Capas
Ejemplos: Protocolos de comunicacin de capas (modelo OSI).
41
Human-computer interface External systems ATC functional areas: flight management,sector management, and so on. Aeronautical classes ATC classes Support mechanisms: communication, time, storage, resource management, and so on Bindings Common utilities Low-level services
Diseo de SWBA - ISI - UTN - FRSF 42
Estilos Arquitectnicos
Componentes Independientes
43
Estilos Arquitectnicos
Componentes Independientes
Objetivo: alcanzar modificabilidad desacoplando porciones de clculo. Procesos u objetos independientes que se comunican a travs de mensajes.
44
Idea: En vez de invocar un procedimiento directamente, una componente puede anunciar (o lanzar) uno o ms eventos Otros componentes pueden registrar inters sobre estos eventos, asociando un procedimiento con el evento. Cuando un evento es anunciado, el sistema invoca todos los procedimientos registrados para el evento. Un evento anunciado provoca la invocacin implcita de procedimientos.
Diseo de SWBA - ISI - UTN - FRSF 45
Invocacin implcita
Manager
Publisher
Suscriber
Suscriber
Invocacin implcita
Componentes: mdulos con interfaces a procedimientos y eventos. Mdulos: registra procedimientos con eventos del sistema (Suscriben). Estos procedimientos son ejecutados cuando se anuncian los eventos en tiempo de ejecucin (Publicitan).
Diseo de SWBA - ISI - UTN - FRSF 47
Un entorno de programacin. Editores y monitores de variables se registran para los eventos de breakpoint de un debbuger Cuando un breakpoint es alcanzado, el debugger anuncia un evento. El sistema automticamente invoca los mtodos de las herramientas registradas. Los mtodos pueden ubicar la lnea de cdigo fuente involucrada (editor), o mostrar los valores de las variables monitoreadas (monitor). El debbuger simplemente anuncia un evento, pero no sabe que otras herramientas estn interesadas en el evento, o lo que harn cuando el evento sea anunciado.
Diseo de SWBA - ISI - UTN - FRSF 48
49
Invocacin implcita
Invariante: Los anunciadores de eventos no conocen cules componentes sern afectadas por estos eventos. No se puede saber el orden de procesamiento, ni qu procesamiento se har. Normalmente se incluye adems invocacin explcita.
Diseo de SWBA - ISI - UTN - FRSF 50
Invocacin implcita
Ejemplos
Entornos de programacin para integrar herramientas. Sistemas de BD para asegurar restricciones de integridad (BD Activas, triggers). En UI para separar presentacin de datos de manejo de datos. Editores orientados a la sintaxis para soportar chequeo de sintaxis incremental.
Diseo de SWBA - ISI - UTN - FRSF 51
Invocacin Implcita
Beneficios: Provee soporte slido para reuso.
Cualquier componente puede ser introducida en un sistema simplemente registrndola para eventos del sistema. Los componentes pueden ser cambiados sin afectar la interface para otros componentes.
Diseo de SWBA - ISI - UTN - FRSF 52
Invocacin Implcita
Desventaja: Los componentes no pueden controlar el procesamiento realizado por el sistema. Intercambio de datos: pueden ser pasado con los eventos o estar en un repositorio comn Problemas de perfomance y administracin de recursos. No se puede razonar sobre la correctitud de las invocaciones.
Diseo de SWBA - ISI - UTN - FRSF 53
Procesos Comunicantes
Un servidor de datos Uno o ms clientes ubicados en una red Sincrnicas: servidor devuelve control y datos Asincrnicas: solo datos. El cliente tiene su propio thread de control
Diseo de SWBA - ISI - UTN - FRSF 54
Estilos - Ejemplos
Ejemplo de Aplicacin de Estilos Arquitectnicos - Programa Principal Ejemplo de Aplicacin de Estilos Arquitectnicos - Integracin Reactiva
55
Estilos Arquitectnicos
Centrado en Datos
56
Estilos Arquitectnicos
Objetivo: alcanzar la integrabilidad de los datos. Almacenamiento de datos centralizado que se comunica con muchos clientes.
57
Repositorios
Componentes: Estructura de datos central: estado actual. Conjunto de componentes independientes que operan sobre los datos. La interaccin entre el repositorio y las componentes externas vara.
58
Repositorios
Categoras (dependiendo del tipo de control): BD tradicional: si el tipo de transaccin en una entrada dispara la seleccin de procesos a ejecutar. Caja Negra: si el estado actual del repositorio central es el principal disparador de procesos.
59
Repositorios
ks3
ks4
60
Repositorios
Usados para sistemas que requieren interpretacin compleja de procesamiento de seales: reconocimiento de patrones y voz. Entornos de programacin con coleccin de herramientas que comparten un repositorio de programas y fragmentos de programas. Sistemas con acceso a datos compartidos con agentes dbilmente acoplados. Integracin de sistemas pre-existentes.
Diseo de SWBA - ISI - UTN - FRSF 61
Mquinas Virtuales
'Intrpretes'
Incluye el pseudo-programa a ser interpretado y la mquina de interpretacin El pseudo-programa incluye el programa a ser interpretado y el estado de la ejecucin. La mquina de interpretacin incluye la definicin del intrprete y el estado actual de su ejecucin.
62
Mquinas Virtuales
63
Mquinas Virtuales
Una MV est construida sobre un sistema existente y provee una abstraccin virtual, un conjunto de atributos, y operaciones. En la mayora de los casos, separa un lenguaje de programacin o entorno de aplicacin de una plataforma de ejecucin. Una MV puede verse como similar a un software de emulacin.
Diseo de SWBA - ISI - UTN - FRSF 64
VM Unix
Common language runtime (CLR) of Microsoft .NET Java Virtual Machine
Diseo de SWBA - ISI - UTN - FRSF 65
Estilos Arquitectnicos
No se encuentran en el catlogo original, pero son extensiones o variantes de alguno de estos, o nuevos estilos.
66
Una aplicacin Cliente /Servidor caracterizada por la existencia de ms de un 'lugar' para ubicar componentes de software, cada uno de los cuales puede tener diferentes entornos (software y hardware) de trabajo. Tres componentes: Mdulo de Software de Cliente, Mdulo Servicios Compuestos, y Mdulo de Servidores de Acceso a los datos.
Diseo de SWBA - ISI - UTN - FRSF 67
Mdulo del Cliente: todo el manejo de interfaz y las partes de las actividades simples que pueden ser replicadas; Mdulo Servicios: responsable de mantener la lgica principal y que es compartida por todos los clientes; Mdulo de Servidor de Accesos a los datos: encargado de acceder a los datos propiamente dichos.
Diseo de SWBA - ISI - UTN - FRSF 68
Software Cliente
Servicios Compuestos
69
Los productores de datos y los consumidores de estos interactan a travs de sus respectivos servidores y clientes. El productor ubica contenido en el servidor, y este contenido es descripto en un "formato" comn con el cliente del consumidor. El consumidor de datos accede a los datos a travs de un cliente que reconozca e interprete el 'formato' de los datos, y se los pueda mostrar al consumidor en forma adecuada.
Diseo de SWBA - ISI - UTN - FRSF 70
Cliente
71
72
Estilos Heterogneos
Pocos sistemas son construidos a partir de un nico estilo. La mayora son mezclas heterogneas de estilos.
73
Estilos Heterogneos
localizados
simultneos
jerrquicos
Una componente de un estilo puede a su vez estar realizada por otro estilo.
Diseo de SWBA - ISI - UTN - FRSF 74
Estilos Heterogneos
75
Lecturas Recomendadas
Paper: An Introduction to Software Architecture (intro_softarch.pdf) 4. Case Studies 4.2. Case Study 2: Instrumentation Software........................ 22 4.3. Case 3: A Fresh View of Compilers ............................... 26 4.4. Case 4: A Layered Design with Different Styles for the Layers ........................... ........................................ 28 4.5. Case 5: An Interpreter Using Different Idioms for the Components ......................................... 30 4.6. Case 6: A Blackboard Globally Recast as Interpreter .... 33
76
Bibliografa
Software Architecture, Perspectives on an Emerging Discipline, Mary Shaw - David Garlan, Prentice-Hal (1996). Cap. 2 Architectural Styles Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman. Addison-Wesley (1998) An Introduction to Software Architecture, David Garlan, Mary Shaw, Tech Report, 1993 Software Architecture and Design Illuminated, Kai Qian, Chongwei Xu, Xiang Fu, Lixin Tao, Jones and Bartlett Publishers, 2010
77