CAPÍTULO 9 DISEÑO DE LA ARQUITECTURA
9.1 ARQUITECTURA DEL SOFTWARE
Cita:
“La arquitectura de un sistema
es un marco general que descri-
be su forma y estructura: sus
componentes y la manera en la
que ajustan entre sí”.
Jerrold Grochow
PU
NT
O pequeñas” [Tyt05]. Algunas de éstas se toman en una etapa temprana del diseño y tienen un
CLAVE
La arquitectura del software debe
modelar la estructura de un sistema
y la manera en la que los datos y
componentes del procedimiento
colaboran entre sí.
Cita:
“Cásate con tu arquitectura de
prisa, arrepiéntete en tu tiempo
libre.”
Barry Boehm
207
En un libro clave sobre el tema, Shaw y Garlan [Sha96] plantean lo siguiente sobre la arquitec-
tura del software:
Desde el primer programa que se dividió en módulos, los sistemas de software han tenido arquitecturas
y los programadores han sido los responsables de las interacciones entre los módulos y las propiedades
globales del ensamble. Históricamente, las arquitecturas han estado implícitas: accidentes de implemen-
tación o sistemas heredados del pasado. Los desarrolladores de buen software han adoptado con fre-
cuencia uno o varios patrones de arquitectura como estrategias para la organización del sistema, pero
los utilizan de manera informal y no tienen manera de hacerlos explícitos en el sistema resultante.
En el presente, la arquitectura de software eficaz y su representación y diseño explícitos se han
vuelto los temas dominantes en la ingeniería de software.
9.1.1 ¿Qué es la arquitectura?
Cuando se piensa en la arquitectura de una construcción, llegan a la mente muchos atributos
distintos. En el nivel más sencillo, se considera la forma general de la estructura física. Pero, en
realidad, la arquitectura es mucho más que eso. Es la manera en la que los distintos componen-
tes del edificio se integran para formar un todo cohesivo. Es la forma en la que la construcción
se adapta a su ambiente y se integra a los demás edificios en la vecindad. Es el grado en el que
el edificio cumple con su propósito y en el que satisface las necesidades del propietario. Es la
sensación estética de la estructura —el efecto visual de la edificación— y el modo en el que se
combinan texturas, colores y materiales para crear la fachada en el exterior y el “ambiente de
vida” en el interior. Es los pequeños detalles: diseño de las lámparas, tipo de piso, color de las
cortinas… la lista es casi interminable. Y, finalmente, es arte.
Pero la arquitectura también es algo más. Son los “miles de decisiones, tanto grandes como
efecto profundo en todas las demás acciones. Otras se dejan para más adelante, con lo que se
eliminan las restricciones prematuras que llevarían a una mala implementación del estilo arqui-
tectónico.
Pero, ¿qué es la arquitectura del software? Bass, Clements y Kazman [Bas03] definen este
término tan elusivo de la manera siguiente:
La arquitectura del software de un programa o sistema de cómputo es la estructura o estructuras del
sistema, lo que comprende a los componentes del software, sus propiedades externas visibles y las
relaciones entre ellos.
La arquitectura no es el software operativo. Es una representación que permite 1) analizar la
efectividad del diseño para cumplir los requerimientos establecidos, 2) considerar alternativas
arquitectónicas en una etapa en la que hacer cambios al diseño todavía es relativamente fácil y
3) reducir los riesgos asociados con la construcción del software.
Esta definición pone el énfasis en el papel de los “componentes del software” en cualquier
representación arquitectónica. En el contexto del diseño de la arquitectura, un componente del
software puede ser algo tan simple como un módulo de programa o una clase orientada a ob-
jeto, pero también puede ampliarse para que incluya bases de datos y “middleware” que permi-
tan la configuración de una red de clientes y servidores. Las propiedades de los componentes
son aquellas características necesarias para entender cómo interactúan unos componentes con
otros. En el nivel arquitectónico, no se especifican las propiedades internas (por ejemplo, deta-
lles de un algoritmo). Las relaciones entre los componentes pueden ser tan simples como una
invocación de procedimiento de un módulo a otro o tan complejos como un protocolo de acceso
a una base de datos.
208
WebRef
En la dirección www2.umassd.
edu/SECenter/SAResources.
html, se encuentran apuntadores
útiles para muchos sitios de
arquitectura de software.
Cita:
“La arquitectura es demasiado
importante para dejarla en
manos de una sola persona, no
importa cuán brillante sea.”
Scott Ambler
PU
NT
O son transferibles. Es decir, los géneros, estilos y patrones arquitectónicos pueden aplicarse al
CLAVE
El modelo arquitectónico da un punto
de vista de la Gestalt del sistema, lo
que permite que el ingeniero de
software lo examine como un todo.
PAR TE DOS MODELADO
Ciertos miembros de la comunidad de la ingeniería de software [Kaz03] hacen una diferencia
entre las acciones asociadas con la obtención de una arquitectura de software (lo que el autor
llama “diseño de la arquitectura”) y las que se aplican para obtener el diseño del software. Como
dijo un revisor de esta edición:
Hay una diferencia entre los términos arquitectura y diseño. Un diseño es una instancia de una arqui-
tectura, similar a un objeto que es una instancia de una clase. Por ejemplo, considere la arquitectura
de cliente-servidor. Con esta arquitectura es posible diseñar de muchos modos un sistema de software
basado en red, con el uso de una plataforma Java (Java EE) o Microsoft (estructura .NET). Entonces,
hay una arquitectura, pero con base en ella pueden crearse muchos diseños. Así, no es válido mezclar
“arquitectura” y “diseño”.
Aunque el autor está de acuerdo con que un diseño de software es una instancia de una arqui-
tectura específica de software, los elementos y estructuras que se definen como parte de ésta
son el origen de todo diseño que evolucione a partir de ellos. El diseño comienza con la consi-
deración de la arquitectura.
En este libro, el diseño de la arquitectura de software considera dos niveles de la pirámide
del diseño (véase la figura 8.1): el diseño de los datos y el de la arquitectura. En el contexto del
análisis precedente, el diseño de los datos permite representar el componente de datos de la
arquitectura con definiciones de sistemas y clase convencionales (que incluyen atributos y ope-
raciones) en sistemas orientados a objeto. El diseño arquitectónico se centra en la representa-
ción de la estructura de los componentes del software, sus propiedades e interacciones.
9.1.2 ¿Por qué es importante la arquitectura?
En un libro dedicado a la arquitectura del software, Bass et al. [Bas03] identifican tres razones
clave por las que es importante la arquitectura del software:
• Las representaciones de la arquitectura del software permiten la comunicación entre
todas las partes (participantes) interesadas en el desarrollo de un sistema basado en
computadora.
• La arquitectura resalta las primeras decisiones que tendrán un efecto profundo en todo
el trabajo de ingeniería de software siguiente y, también importante, en el éxito último
del sistema como entidad operacional.
• La arquitectura “constituye un modelo relativamente pequeño y asequible por la vía inte-
lectual sobre cómo está estructurado el sistema y la forma en la que sus componentes
trabajan juntos” [Bas03].
El modelo del diseño de la arquitectura y los patrones arquitectónicos contenidos dentro de éste
diseño de otros sistemas y representan un conjunto de abstracciones que permite a los ingenie-
ros de software describir la arquitectura en formas predecibles.
9.1.3 Descripciones arquitectónicas
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 conclusión es
que los diversos participantes verán una arquitectura desde puntos de vista diferentes motivados
por varios conjuntos de preocupaciones. Esto implica que una descripción arquitectónica en rea-
lidad 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 partici-
pantes. La preocupación principal del propietario de la edificación (un participante) es garanti-
zar el placer estético y que brinde suficiente espacio de oficinas e infraestructura para garantizar
su rentabilidad. Por tanto, el arquitecto debe desarrollar una descripción con el empleo de pers-

CONSEJO
El esfuerzo debe centrarse en
representaciones de la arquitectura
que guiarán todos los demás
aspectos del diseño. Hay que dedicar
tiempo a revisar con cuidado la
arquitectura. Un error aquí tendrá un
efecto negativo a largo plazo.
9.2
CAPÍTULO 9 DISEÑO DE LA ARQUITECTURA 209
pectivas del edificio que se apeguen a las preocupaciones del dueño. Los puntos de vista em-
pleados son dibujos del edificio en tres dimensiones (para ilustrar el aspecto estético) y un
conjunto de planos en dos dimensiones que expliquen la preocupación 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 información
arquitectónica 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 abo-
can 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 edificación se
centran sólo en una de las muchas preocupaciones del fabricante.
La descripción de la arquitectura de un sistema basado en software debe tener características
análogas 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 diseño. Los consumidores desean la comprensión clara de los cambios ambientales que de-
ben ocurrir y las garantías de que la arquitectura satisfará las necesidades de negocios. Otros
arquitectos desean una comprensión 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 diseño de la arqui-
tectura del software, 2) proporcionar lineamientos detallados para representar una descripción
arquitectónica y 3) estimular las mejores prácticas del diseño arquitectónico.
El estándar IEEE define una descripción arquitectónica (DA) como “un conjunto de productos
para documentar una arquitectura”. La descripción en sí se representa con el uso de perspecti-
vas múltiples, donde cada perspectiva es “una representación del sistema completo desde el
punto de vista de un conjunto de preocupaciones relacionadas [de un participante]”. Una pers-
pectiva se crea de acuerdo con reglas y convenciones definidas en un punto de vista: “especifica-
ción de las convenciones para construir y usar una perspectiva” [IEE00]. En este capítulo se
estudian varios productos del trabajo que se utilizan para desarrollar distintas perspectivas de
la arquitectura del software.
9.1.4 Decisiones arquitectónicas
Cada perspectiva desarrollada como parte de una descripción arquitectónica se aboca a una
preocupación de un participante específico. Para desarrollar cada perspectiva (y la descripción
arquitectónica en su conjunto), el arquitecto del sistema considera varias alternativas y decide
en última instancia las características arquitectónicas específicas que satisfagan del mejor modo
la preocupación. Entonces, las decisiones arquitectónicas en sí mismas se consideran una pers-
pectiva de la arquitectura. Las razones por las que se tomaron las decisiones dan una visión de
un sistema y su concordancia con las preocupaciones del participante.
Como arquitecto simbólico, el lector puede usar el formato sugerido en el recuadro para do-
cumentar cada decisión importante. Al hacerlo, presenta la racionalidad de su trabajo y deja un
registro histórico que será útil cuando deban hacerse modificaciones del diseño.
GÉNEROS ARQUITECTÓNICOS
Aunque los principios subyacentes del diseño arquitectónico se aplican a todos los tipos de la
arquitectura, con frecuencia será el género arquitectónico el que dicte el enfoque específico para
la estructura que deba construirse. En el contexto del diseño arquitectónico, el género implica