1.

Descripciones arquitectnicas
Cada uno de nosotros tiene una imagen mental de lo que significa la palabra
arquitectura. Sin embargo, la realidad es que tiene significados diferentes para
distintas personas. La conclusin es que los diversos participantes vern una
arquitectura desde puntos de vista diferentes motivados por varios conjuntos de
preocupaciones. Esto implica que una descripcin arquitectnica en realidad es un
conjunto de productos del trabajo que reflejan puntos de vista distintos del
sistema.
Por ejemplo, el arquitecto de un gran edificio de oficinas debe trabajar con
distintos participantes. La preocupacin principal del propietario de la edificacin
(un participante) es garantizar el placer esttico y que brinde suficiente espacio de
oficinas e infraestructura para garantizar su rentabilidad. Por tanto, el arquitecto
debe desarrollar una descripcin con el empleo de perspectivas del edificio que se
apeguen a las preocupaciones del dueo. Los puntos de vista empleados son
dibujos del edificio en tres dimensiones (para ilustrar el aspecto esttico) y un
conjunto de planos en dos dimensiones que expliquen la preocupacin por el
espacio de oficinas y la infraestructura.
Pero el espacio de oficinas tiene muchos otros participantes, incluido el fabricante
de acero estructural que proveer dicho material para la estructura del edificio.
Necesita informacin arquitectnica detallada sobre el acero que soportar al
edificio, incluso de las vigas tipo I, sus dimensiones, conectividad, materiales y
muchos otros detalles. A estas preocupaciones se abocan diferentes productos del
trabajo que representan distintos puntos de vista de la arquitectura.
Los planos especializados (otro punto de vista) de la estructura de acero de la
edificacin se centran slo en una de las muchas preocupaciones del fabricante.
La descripcin de la arquitectura de un sistema basado en software debe tener
caractersticas anlogas a las mencionadas para el edificio de oficinas. Tyree y
Ackerman [Tyr05] recalcan esto as: Los desarrolladores desean lineamientos
claros y decisivos sobre la forma de proceder con el diseo. Los consumidores
desean la comprensin clara de los cambios ambientales que deben ocurrir y las
garantas de que la arquitectura satisfar las necesidades de negocios. Otros
arquitectos desean una comprensin clara y notable de los aspectos clave de la
arquitectura. Cada uno de estos deseos se refleja en un punto de vista diferente
representado con el uso de una perspectiva distinta.
IEEE Computer Society hizo la propuesta IEEE-Std-1471-2000, Recommended
Practice for Architectural Description of Software-Intensive Systems, [IEE00], con
los siguientes objetivos:
1) establecer un marco conceptual con un vocabulario que se use durante el
diseo de la arquitectura del software, 2) proporcionar lineamientos detallados
para representar una descripcin arquitectnica y 3) estimular las mejores
prcticas del diseo arquitectnico.

El estndar IEEE define una descripcin arquitectnica (DA) como un conjunto de

productos para documentar una arquitectura. La descripcin en s se representa
con el uso de perspectivas mltiples, donde cada perspectiva es una
representacin del sistema completo desde el punto de vista de un conjunto de
preocupaciones relacionadas [de un participante]. Una perspectiva se crea de
acuerdo con reglas y convenciones definidas en un punto de vista: especificacin
de las convenciones para construir y usar una perspectiva [IEE00]. En este
captulo se estudian varios productos del trabajo que se utilizan para desarrollar
distintas perspectivas de la arquitectura del software.
2. GNEROS ARQUITECTNICOS
Aunque los principios subyacentes del diseo arquitectnico se aplican a todos los
tipos de la arquitectura, con frecuencia ser el gnero arquitectnico el que dicte el
enfoque especfico para la estructura que deba construirse. En el contexto del
diseo arquitectnico, el gnero implica una categora especfica dentro del
dominio general del software. Dentro de cada categora hay varias subcategoras.
Por ejemplo, dentro del gnero edificios, se encuentran los siguientes estilos
generales: casas, condominios, edificios de departamentos, edificios de oficinas,
edificios industriales, bodegas, etc. Dentro de cada estilo general habr estilos
ms especficos (vase la seccin 9.3). Cada estilo tendr una estructura que
puede describirse con el uso de un conjunto de patrones predecibles.
En su texto evolutivo Handbook of Software Architecture [Boo08], Grady Booch
sugiere los siguientes gneros arquitectnicos para sistemas basados en software:
Inteligencia artificial: Sistemas que simulan o incrementan la cognicin
humana, su locomocin u otros procesos orgnicos.
Comerciales y no lucrativos: Sistemas que son fundamentales para la
operacin de una empresa de negocios.
Comunicaciones: Sistemas que proveen la infraestructura para transferir y
manejar datos, para conectar usuarios de stos o para presentar datos en la
frontera de una infraestructura.
Contenido de autor: Sistemas que se emplean para crear o manipular
artefactos de texto o multimedios.
Dispositivos: Sistemas que interactan con el mundo fsico a fin de brindar
algn servicio puntual a un individuo.
Entretenimiento y deportes: Sistemas que administran eventos pblicos o que
proveen una experiencia grupal de entretenimiento.
Financieros: Sistemas que proporcionan la infraestructura para transferir y
manejar dinero y otros ttulos.
Juegos: Sistemas que dan una experiencia de entretenimiento a individuos o
grupos.
Gobierno: Sistemas que dan apoyo a la conduccin y operaciones de una
institucin poltica local, estatal, federal, global o de otro tipo.
Industrial: Sistemas que simulan o controlan procesos fsicos.

 Legal: Sistemas que dan apoyo a la industria jurdica.

Mdicos: Sistemas que diagnostican, curan o contribuyen a la investigacin
mdica.
Militares: Sistemas de consulta, comunicaciones, comando, control e
inteligencia (o C4I), as como de armas ofensivas y defensivas.
Sistemas operativos: Sistemas que estn inmediatamente instalados en el
hardware para dar servicios de software bsico.
Plataformas: Sistemas que se encuentran en los sistemas operativos para
brindar servicios avanzados.
Cientficos: Sistemas que se emplean para hacer investigacin cientfica y
aplicada.
Herramientas: Sistemas que se utilizan para desarrollar otros sistemas.
Transporte: Sistemas que controlan vehculos acuticos, terrestres, areos o
espaciales.
Utilidades: Sistemas que interactan con otro software para brindar algn
servicio especfico.
Desde el punto de vista del diseo arquitectnico, cada gnero representa un
desafo nico. Por ejemplo, considere la arquitectura del software de un sistema
de juego. Esta clase de sistemas, en ocasiones llamados aplicaciones interactivas
de inmersin, requieren el cmputo de algoritmos intensivos, grficas avanzadas
en computadora, fuentes de datos continuas en multimedios, interactividad en
tiempo real a travs de dispositivos de entrada convencionales y no
convencionales, y otras preocupaciones especializadas.
Alexander Francois [Fra03] sugiere una arquitectura del software para
inmerpresencia1 que se aplica a un ambiente de juegos. l describe la
arquitectura de la manera siguiente:
La ASI (Arquitectura de Software de Inmerpresencia) es un modelo nuevo
de arquitectura de software para disear, analizar e implementar
aplicaciones que realizan un procesamiento distribuido, asncrono y paralelo
de flujos de datos generales. El objetivo de la ASI es proveer un marco
universal para la implementacin distribuida de algoritmos y su fcil
integracin en sistemas complejos [] El modelo de procesamiento de
datos extensibles subyacentes y el modelo de procesamiento hbrido
(depsito y transmisin de mensajes compartidos), asncrono y en paralelo
permiten la manipulacin natural y eficiente de flujos de datos generales
con el uso indistinto de libreras ya existentes o cdigo original. La
modularidad del estilo facilita el desarrollo de cdigo distribuido, pruebas y
reutilizacin, as como el diseo e integracin rpida del sistema y su
mantenimiento y evolucin.
El anlisis detallado del ASI queda fuera del alcance de este libro. No obstante, es
importante reconocer que el gnero de sistemas de juegos puede abordarse con
un estilo arquitectnico (vase la seccin 9.3) diseado especficamente para

resolver preocupaciones de sistemas de juego. Si el lector tiene especial inters,

consulte [Fra03].
3. ESTILOS ARQUITECTNICOS
Cuando un constructor usa la frase vestbulo central colonial para describir una
casa, la mayor parte de personas familiarizadas con viviendas en Estados Unidos
se har una imagen general de ella y de cul es su probable distribucin. El
constructor us un estilo arquitectnico como mecanismo descriptivo para
diferenciar la casa de otros estilos (por ejemplo, de dos aguas, finca campestre,
Cabo Cod, etc.). Pero, lo que es ms importante, el estilo arquitectnico tambin
es una plantilla para la construccin. Deben definirse ms detalles, especificar sus
dimensiones finales, agregar caractersticas personalizadas, determinar los
materiales de construccin, pero el estilo (un vestbulo central colonial) orienta al
constructor en su trabajo.
El software construido para sistemas basados en computadora tambin tiene uno
de muchos estilos arquitectnicos. Cada estilo describe una categora de sistemas
que incluye 1) un conjunto de componentes (como una base de datos o mdulos
de cmputo) que realizan una funcin requerida por el sistema, 2) un conjunto de
conectores que permiten la comunicacin, coordinacin y cooperacin entre los
componentes, 3) restricciones que definen cmo se integran los componentes
para formar el sistema y 4) modelos semnticos que permiten que un diseador
entienda las propiedades generales del sistema al analizar las propiedades
conocidas de sus partes constituyentes [Bas03].
Un estilo arquitectnico es una transformacin que se impone al diseo de todo el
sistema. El objetivo es establecer una estructura para todos los componentes del
sistema. En el caso en el que ha de hacerse la reingeniera de una arquitectura ya
existente (vase el captulo 29), la imposicin de un estilo arquitectnico dar
como resultado cambios fundamentales en la estructura del software, incluida la
reasignacin de las funciones de los componentes [Bos00].
Un patrn arquitectnico, como un estilo de arquitectura, impone la transformacin
del diseo de una arquitectura. Sin embargo, un patrn difiere de un estilo en
varias formas fundamentales: 1) el alcance del patrn es menos amplio y se centra
en un aspecto de la arquitectura ms que en el total de sta, 2) un patrn impone
una regla a la arquitectura, describe la manera en la que el software manejar
ciertos aspectos de su funcionalidad en el nivel de la infraestructura (por ejemplo,
la concurrencia) [Bos00], 3) los patrones arquitectnicos (vase la seccin 9.4)
tienden a abocarse a aspectos especficos del comportamiento en el contexto de
la arquitectura (por ejemplo, cmo manejarn la sincronizacin o las interrupciones
las aplicaciones en tiempo real). Los patrones se utilizan junto con un estilo
arquitectnico para dar forma a la estructura general de un sistema. En la seccin
9.3.1 se consideran los estilos y patrones arquitectnicos comunes para el
software.

4. Breve taxonoma de estilos de arquitectura

Aunque en los ltimos 60 aos se han creado millones de sistemas basados en
computadoras, la gran mayora se clasifica en un nmero relativamente pequeo
de estilos de arquitectura:
4.1.

Arquitecturas centradas en los datos. En el centro de esta arquitectura se halla

un almacenamiento de datos (como un archivo o base de datos) al que acceden
con frecuencia otros componentes que actualizan, agregan, eliminan o modifican
los datos de cierto modo dentro del almacenamiento. La figura 9.1 ilustra un estilo
comn centrado en datos. El software cliente accede a un repositorio (depsito)
central. En ciertos casos ste es pasivo. Es decir, el software cliente accede a los
datos en forma independiente de cualesquiera cambios que stos sufran o de las
acciones del software de otro cliente. Una variante de este enfoque transforma el
depsito en un pizarrn que enva notificaciones al software cliente cuando hay
un cambio en datos de inters del cliente.
Las arquitecturas centradas en datos promueven la integrabilidad [Bas03]. Es
decir, los componentes del software pueden ser cambiados y agregarse otros
nuevos, del cliente, a la arquitectura sin problemas con otros clientes (porque los
componentes del cliente operan en forma independiente). Adems, pueden
pasarse datos entre clientes con el uso de un mecanismo de pizarrn (el
componente pizarrn sirve para coordinar la transferencia de informacin entre
clientes). Los componentes del cliente ejecutan los procesos con independencia.

4.2.

Arquitecturas de flujo de datos. Esta arquitectura se aplica cuando datos de entrada

van a transformarse en datos de salida a travs de una serie de componentes
computacionales o manipuladores.
Un patrn de tubo y filtro (vase la figura 9.2) tiene un conjunto de componentes,
llamados filtros, conectados por tubos que transmiten datos de un componente al
siguiente. Cada filtro trabaja en forma independiente de aquellos componentes

que se localizan arriba o abajo del flujo; se disea para esperar una entrada de
datos de cierta forma y produce datos de salida (al filtro siguiente) en una forma
especificada. Sin embargo, el filtro no requiere ningn conocimiento de los
trabajos que realizan los filtros vecinos.
Si el flujo de datos degenera en una sola lnea de transformaciones, se denomina
lote secuencial. Esta estructura acepta un lote de datos y luego aplica una serie de
componentes secuenciales (filtros) para transformarlos.