E STILOS A RQUITECTÓNICOS

Un estilo es un concepto descriptivo que define a grandes rasgos una forma de articulación u organización arquitectónica. Los estilos solo se manifiestan en la arquitectura teórica descriptiva de alto nivel de abstracción. El conjunto de estilos constituyen un catalogo con las formas básicas posibles de estructuras de software, a partir del cual las formas complejas se logran mediante las composición de los estilos fundamentales [RK04]. Como se verá, no existe un catalogo único, sino varias versiones que en su mayoría se superponen en su contenido.

Los estilos conjugan componentes, conectores, configuraciones y restricciones, donde al estipular los conectores como elemento de juicio de primera clase, el concepto de estilo se ubica en una posición que ni el método de modelado orientado a objetos o el UML cubren satisfactoriamente. Si bien una forma describir un estilo seria a través del uso de lenguaje natural o de diagramas, la mejor manera de hacerlo es a través de un lenguaje de descripción arquitectónica o a través de lenguajes formales de especificación.

A diferencia de los patrones de diseño, los estilos se ordenan en seis o siete clases fundamentales y unos veinte ejemplares como máximo.

Anexo 2 – Arquitectura de Software

106 Vale la pena aclara la relación entre estilos, patrones de diseño y patrones de arquitectura. Los patrones de diseño de software buscan codificar y hacer reutilizables un conjunto de principios a fin de diseñar aplicaciones de alta calidad. Se aplican en principio solo en la fase de diseño, aunque la comunidad ha comenzado a definir y aplicar patrones a otras etapas del proceso de desarrollo. Los estilos se han aplicado en la fase de análisis arquitectónico en términos de patrones de arquitectura. Sin bien los patrones de arquitectura son similares a los de diseño, los primeros se concentran en la estructura de alto nivel del sistema. Algunos autores sostienen que los patrones arquitectónicos son virtualmente lo mismo que los estilos, pero si bien existen convergencias entre ambos conceptos, los patrones se refieren más a prácticas de reutilización y los estilos conciernen a teorías sobre la estructura de los sistemas. El concepto de patrones y sus diferentes usos es tratado mas profundamente en el Anexo 1 de la presente tesis.

De los diferentes catálogos de estilos que se pueden encontrar en la literatura, se observa que los mismos se subdividen o articulan en 5 ó 6 clases. A modo de ejemplo se presenta el presentado por David Garlan en su trabajo “Next generation software architectures: Recent research and future directions” [Gar01]:

1. Flujo de datos

• Secuencial en lotes

• Red de flujo de datos (tuberías y filtros) • Bucle de control cerrado

2. Llamada y Retorno

• Programa principal / subrutinas

• Ocultamiento de información (ADT, objeto, cliente/servidor elemental)

3. Procesos interactivos

• Procesos comunicantes

• Sistemas de eventos (invocación implícita, eventos puros)

4. Repositorio Orientado a Datos

• Bases de datos transaccionales (cliente/servidor genuino) • Pizarra • Compilador moderno 5. Datos Compartidos • Documentos compuestos • Hipertexto • Fortran COMMON • Procesos LW 6. Jerárquicos • En capas (intérpretes)

En este trabajo el autor señala los inconvenientes de la vida real que comúnmente va en contra de las taxonomías:

o Los estilos casi siempre se usan combinados

o Cada capa o componente puede ser internamente de un estilo diferente

al de la totalidad

o Varios estilos se encuentran ligados a dominios específicos, o a líneas

de producto particulares.

Es de destacar, que la caracterización de los estilos no constituye un reflejo pormenorizado de su estructura, mas bien son una visión rápida y genérica que acentúa

sus valores esenciales y sus características distintivas. Comúnmente su representación grafica es sumamente informal y minimalista. Shaw y Clements en su trabajo “A field guide to Boxology: Preliminary classification of architectural styles for software systems” [SC96], han llamado a la misma “boxology”.

A continuación se detallan algunos de los estilos citados:

Arquitectura de Pizarra o Repositorio

En este estilo arquitectónico existen dos componentes principales: una estructura de datos que representa el estado actual y una colección de componentes independientes que operan sobre él. A su vez se han definido dos subcategorías:

1. Los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar, entonces el repositorio puede ser una base de datos tradicional. 2. El estado actual de la estructura de datos dispara los procesos a ejecutar, entonces el repositorio es lo que se llama una pizarra pura o tablero de control.

Habitualmente un sistema de pizarra se implementa para resolver problemas en los cuales las entidades en forma individual son incapaces de alcanzar una solución, o para los que no existe una solución analítica, o para los que si existe pero no es viable dada la dimensión del espacio de búsqueda. Todo modelo de este tipo consiste en tres partes, a saber:

• Fuentes de conocimiento, necesarias para resolver el problema • Una pizarra que representa el estado actual de la resolución del

problema

• Una estrategia que regula el orden en el que operan las fuentes.

El comportamiento en general seria el siguiente: en una primera instancia se establece el problema en la pizarra. Las fuentes tratan de resolverlo cambiando el estado. Entre las fuentes la única forma de comunicación es a través de la pizarra. Finalmente, si de la cooperación resulta una solución adecuada, la misma es presentada en la pizarra.

Este estilo de arquitectura se ha utilizado en aplicaciones que requieren complejas interpretaciones de proceso de señales, o en sistemas que involucren acceso compartido a datos, con agentes sin acoplamiento.

En el paper “Architectures for Context” de Terry Winograd [Win01], se presenta este estilo de arquitectura como modelo para administrar el contexto, realizando un comparación del misma con otros dos modelos posibles para este dominio. Plantea que el estilo de pizarra fue desarrollado en el contexto de la inteligencia artificial, donde cada componente o agente tenía información parcial y una nueva fuente podía ser agregada fácilmente. El hecho de un bajo acoplamiento era pagado con la escasa eficiencia de comunicación. Cada comunicación requiere dos saltos y usa en general una estructura de mensajes no optimizada. Los beneficios son la facilidad de configuración y su robustez. En su investigación sobre “Interactive Workspaces” donde exploraron la integración de múltiples dispositivos para múltiples usuarios compartiendo un mismo espacio físico (iRoom), utiliza una arquitectura de comunicación tipo pizarra para soportar “context-aware computing”

Arquitecturas Orientadas a Objetos

En la caracterización clásica de Garlam y Shaw, los objetos representan una clase de componentes los cuales son responsables de preservar la

Anexo 2 – Arquitectura de Software

108 integridad de su propia representación. Se desataca el hecho que la representación interna de un objeto no es accesible desde otros objetos y no se establece como una cuestión definitoria el principio de herencia.

Las características principales de este estilo arquitectónico son las siguientes:

• Los componentes se basan en principios de OO: encapsulamiento,

herencia y polimorfismo. Son asimismo las entidades de modelado, diseño e implementación.

• En general la distribución de objetos es transparente y no tiene

importancia si los objetos son locales o remotos. Un ejemplo de este estilo seria CORBA (Common Object Request Broker Architecture), en el cual un Object Request Broker media las interacciones entre objetos clientes y objetos servidores en ambientes distribuidos.

• Los componentes (objetos), interactúan entre si a través de invocaciones

de funciones y procedimientos.

Se pude considerar este estilo como perteneciente a una familia arquitectónica más amplia que algunos autores llaman Arquitecturas de Llamada-y-Retorno

En cuanto a ventajas se puede mencionar entre otras el hecho que se pueda modificar la implementación de un objeto sin afectar a sus clientes, y que un objeto pueda ser reutilizado en el entorno de desarrollo.

Como desventaja, el principal problema del estilo es el hecho que para poder interactuar con otro objeto se debe conocer su identidad, es decir se debe conocer los métodos o procedimientos que implementa.

En los estudios arquitectónicos de estilos, el modelo de objetos aparece como relativamente subordinado en relación con la importancia que ha tenido en el ámbito de la ingeniería de software. Se podría decir que no es un estilo relevante en cuanto a estilos de implementación.

Arquitectura Basada en Componentes

El objetivo de la tecnología de componentes software es construir aplicaciones complejas mediante ensamblado de módulos (componentes) que han sido previamente diseñados a fin de ser reutilizados en múltiples aplicaciones. La ingeniería de programación que sigue esta estrategia de diseño se le conoce por CBSE (Component-based Software Engineering).

La arquitectura basada en componentes sostiene que una aplicación consiste en muchos componentes prefabricados que se ensamblan entre sí para proporcionar los servicios que se necesitan en la misma.

En la tecnología de componentes la interfaz constituye el elemento básico de interconexión. Cada componente debe describir de forma completa las interfaces que ofrece, así como las interfaces que requiere para su operación. Y debe operar correctamente con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz.

Las características más relevantes son la modularidad, la reutilización y componibilidad y en todos ellos coincide con la tecnología orientada a objetos de la que se puede considerar una evolución. Sin embargo, en la tecnología basada en componentes también se requiere robustez ya que los componentes han de operar en entornos mucho más heterogéneos y diversos.

Existen entornos normalizados para el desarrollo de componentes, un ejemplo de estos seria el modelo COM (Componet Object Model). El mismo define un estándar para objetos y la intercomunicación entre ellos. Toda comunicación se realiza a través de operaciones que son proporcionadas dentro de interfaces.