El documento describe el diseño arquitectónico de software, incluyendo qué es, quién lo hace, por qué es importante, los pasos involucrados y el producto final. También cubre conceptos como la arquitectura de software, los géneros arquitectónicos como inteligencia artificial y sistemas operativos, y estilos arquitectónicos como centrados en datos, de flujo de datos y orientados a objetos.

1. 1. Introducción
¿Qué es? El diseño arquitectónico representa la estructura de los datos y de los
componentes del programa que se requieren para construir un sistema basado en
computadora. Considera el estilo de arquitectura que adoptará el sistema, la
estructura y las propiedades de los componentes que lo constituyen y las
interrelaciones que ocurren entre sus componentes arquitectónicos.
¿Quién lo hace? Aunque es un ingeniero de software quien puede diseñar tanto
los datos como la arquitectura, es frecuente que si deben construirse sistemas
grandes y complejos, el trabajo lo realicen especialistas. El diseñador de una base
de datos o data warehouse crea la arquitectura de los datos para un sistema. El
“arquitecto del sistema” selecciona un estilo arquitectónico apropiado a partir de
los requerimientos obtenidos durante el análisis de los datos.
¿Por qué es importante? El lector no intentaría construir una casa sin un plano,
¿o sí? Tampoco comenzaría los planos con el dibujo de la plomería del lugar.
Antes de preocuparse por los detalles, necesitaría tener el panorama general: la
casa en sí. Eso es lo que hace el diseño arquitectónico, da el panorama y asegura
que sea el correcto.
¿Cuáles son los pasos? El diseño de la arquitectura comienza con el diseño de
los datos y continúa con la obtención de una o más representaciones de la
estructura arquitectónica del sistema. Se analizan alternativas de estilos o
patrones arquitectónicos para llegar a la estructura más adecuada para los
requerimientos del usuario y para los atributos de calidad. Una vez seleccionada la
alternativa, se elabora la arquitectura con el empleo de un método de diseño.
¿Cuál es el producto final? Durante el diseño arquitectónico se crea un modelo
de arquitectura que incluye la arquitectura de los datos y la estructura del
programa.

2. Además, se describen las propiedades y relaciones (interacciones) que hay entre
los componentes.
¿Cómo me aseguro de que lo hice bien? En cada etapa se revisan los
productos del trabajo del diseño del software para que sean claros, correctos,
completos y consistentes con los requerimientos y entre sí.
2. Desarrollo
2.1 ARQUITECTURA DEL SOFTWARE
En un libro clave sobre el tema, Shaw y Garlan [Sha96] plantean lo siguiente sobre
la arquitectura 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
implementación o sistemas heredados del pasado. Los desarrolladores de buen
software han adoptado con frecuencia 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.
2.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 componentes 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

3. 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 pequeñas”. Algunas
de éstas se toman en una etapa temprana del diseño y tienen un 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 arquitectónico.
Pero, ¿qué es la arquitectura del software? Bass, Clements y Kazman 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 objeto, pero también puede
ampliarse para que incluya bases de datos y “middleware” que permitan 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, detalles de un algoritmo). Las
relaciones entre los componentes pueden ser tan simples como una invocación de

4. procedimiento de un módulo a otro o tan complejos como un protocolo de acceso
a una base de datos.
Ciertos miembros de la comunidad de la ingeniería de software 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 arquitectura, 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”.
2.3 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 una categoría específica dentro del
dominio general del software. Dentro de cada categoría hay varias subcategorías.
Por ejemplo, dentro del género 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
más específicos. 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 géneros
arquitectónicos para sistemas basados en software:
• Inteligencia artificial: Sistemas que simulan o incrementan la cognición
humana, su locomoción u otros procesos orgánicos.

5. • Comerciales y no lucrativos: Sistemas que son fundamentales para la
operación 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 interactúan con el mundo físico a fin de brindar
algún servicio puntual a un individuo.
• Entretenimiento y deportes: Sistemas que administran eventos públicos o que
proveen una experiencia grupal de entretenimiento.
• Financieros: Sistemas que proporcionan la infraestructura para transferir y
manejar dinero y otros títulos.
• Juegos: Sistemas que dan una experiencia de entretenimiento a individuos o
grupos.
• Gobierno: Sistemas que dan apoyo a la conducción y operaciones de una
institución política local, estatal, federal, global o de otro tipo.
• Industrial: Sistemas que simulan o controlan procesos físicos.
• Legal: Sistemas que dan apoyo a la industria jurídica.
• Médicos: Sistemas que diagnostican, curan o contribuyen a la investigación
médica.
• Militares: Sistemas de consulta, comunicaciones, comando, control e
inteligencia, así como de armas ofensivas y defensivas.

6. • Sistemas operativos: Sistemas que están inmediatamente instalados en el
hardware para dar servicios de software básico.
• Plataformas: Sistemas que se encuentran en los sistemas operativos para
brindar servicios avanzados.
• Científicos: Sistemas que se emplean para hacer investigación científica y
aplicada.
• Herramientas: Sistemas que se utilizan para desarrollar otros sistemas.
• Transporte: Sistemas que controlan vehículos acuáticos, terrestres, aéreos o
espaciales.
• Utilidades: Sistemas que interactúan con otro software para brindar algún
servicio específico.
2.4 ESTILOS ARQUITECTÓNICOS
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
común centrado en datos. El software cliente accede a un repositorio (depósito)
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
depósito en un “pizarrón” que envía notificaciones al software cliente cuando hay
un cambio en datos de interés del cliente. Las arquitecturas centradas en datos
promueven la integrabilidad. 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). Además, pueden pasarse datos entre clientes con el uso de un
mecanismo de pizarrón (el componente pizarrón sirve para coordinar la

7. transferencia de información entre clientes). Los componentes del cliente ejecutan
los procesos con independencia.
Arquitecturas de flujo de datos. Esta arquitectura se aplica cuando datos de
entrada van a transformarse en datos de salida a través de una serie de
componentes computacionales o manipuladores.
Un patrón de tubo y filtro (véase 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 diseña 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 ningún conocimiento de los
trabajos que realizan los filtros vecinos.
Si el flujo de datos degenera en una sola línea de transformaciones, se denomina
lote secuencial.
Esta estructura acepta un lote de datos y luego aplica una serie de componentes
secuenciales (filtros) para transformarlos.
Arquitecturas orientadas a objetos. Los componentes de un sistema incluyen
datos y las operaciones que deben aplicarse para manipularlos. La comunicación
y coordinación entre los componentes se consigue mediante la transmisión de
mensajes.
Arquitecturas en capas. Se define un número de capas diferentes; cada una
ejecuta operaciones que se aproximan progresivamente al conjunto de
instrucciones de máquina. En la capa externa, los componentes atienden las
operaciones de la interfaz de usuario. En la interna, los componentes realizan la
interfaz con el sistema operativo. Las capas intermedias proveen servicios de
utilerías y funciones de software de aplicación.

8. Estos estilos arquitectónicos tan sólo son un pequeño subconjunto de los que
están disponibles.
Una vez que la ingeniería de requerimientos revela las características y
restricciones del sistema que se va a elaborar, se elige el estilo arquitectónico o la
combinación de patrones que se ajusten mejor a esas características y
restricciones. En muchos casos, más de un patrón es apropiado y es posible
diseñar y evaluar estilos arquitectónicos alternativos. Por ejemplo, en muchas
aplicaciones de bases de datos se combina un estilo en capas (apropiado para la
mayoría de sistemas) con una arquitectura centrada en datos.
2.5 Patrones arquitectónicos
A medida que se desarrolle el modelo de requerimientos, se observará que el
software debe enfrentar cierto número de problemas amplios que abarcan toda la
aplicación. Por ejemplo, el modelo de requerimientos para virtualmente cualquier
aplicación de comercio electrónico se enfrenta con el siguiente problema: ¿Cómo
ofrecer una amplia variedad de bienes a un grupo extenso de consumidores y
permitir que los adquieran en línea?
El modelo de requerimientos también define un contexto en el que debe
responderse esta pregunta. Por ejemplo, un negocio de comercio electrónico que
venda equipo de golf de consumo operará en un contexto diferente que otro que
venda equipo industrial de precio alto a corporaciones medianas y pequeñas.
Además, hay varias limitantes y restricciones que afectan la manera en la que se
aborda este problema para resolverlo.
Los patrones arquitectónicos se abocan a un problema de aplicación específica
dentro de un contexto dado y sujeto a limitaciones y restricciones. El patrón
propone una solución arquitectónica que sirve como base para el diseño de la
arquitectura.
En una sección anterior, se dijo que la mayor parte de aplicaciones caen dentro de
un dominio o género específico, y que para éstas son apropiados uno o más

9. estilos de arquitectura. Por ejemplo, el estilo de arquitectura general para una
aplicación podría ser el de llamar y regresar o el que está orientado a objeto. Pero
dentro de ese estilo se encontrará un conjunto de problemas comunes que se
abordan mejor con patrones arquitectónicos específicos. En el capítulo 12 se
presentan algunos de estos problemas y se hace un estudio más completo de los
patrones de arquitectura.
2.6DISEÑO ARQUITECTÓNICO
Cuando comienza el diseño arquitectónico, el software que se va a desarrollar
debe situarse en contexto, es decir, el diseño debe definir las entidades externas
(otros sistemas, dispositivos, personas, etc.) con las que interactúa el software y la
naturaleza de dicha interacción. Esta información por lo general se adquiere a
partir del modelo de los requerimientos y de toda la que se reunió durante la
ingeniería de éstos. Una vez que se ha modelado el contexto y descrito todas las
interfaces externas del software, se identifica un conjunto de arquetipos de
arquitectura.
Un arquetipo es una abstracción (similar a una clase) que representa un elemento
de comportamiento del sistema. El conjunto de arquetipos provee una colección
de abstracciones que deben modelarse en cuanto a la arquitectura si el sistema ha
de construirse, pero los arquetipos por sí mismos no dan suficientes detalles para
la implementación. Por tanto, el diseñador especifica la estructura del sistema,
definiendo y refinando los componentes del software que implementan cada
arquetipo. Este proceso sigue en forma iterativa hasta que se obtiene una
estructura arquitectónica completa. En las secciones que siguen se estudia cada
una de estas tareas de diseño arquitectónico con un poco más de detalle.
3. CONCLUSIONES
Los patrones arquitectónicos, o patrones de arquitectura, también llamados
arquetipos ofrecen soluciones a problemas de arquitectura de software
en ingeniería de software. Dan una descripción de los elementos y el tipo de

10. relación que tienen junto con un conjunto de restricciones sobre cómo pueden ser
usados. Un patrón arquitectónico expresa un esquema de organización estructural
esencial para un sistema de software, que consta de subsistemas, sus
responsabilidades e interrelaciones. En comparación con los patrones de diseño,
los patrones arquitectónicos tienen un nivel de abstracción mayor.
Aunque un patrón arquitectónico comunica una imagen de un sistema, no es una
arquitectura como tal. Un patrón arquitectónico es más un concepto que captura
elementos esenciales de una arquitectura de software. Muchas arquitecturas
diferentes pueden implementar el mismo patrón y por lo tanto compartir las
mismas características. Además, los patrones son a menudo definidos como una
cosa estrictamente descrita y comúnmente disponible. Por ejemplo, la arquitectura
en capas es un estilo de llamamiento-y-regreso, cuando define uno un estilo
general para interaccionar. Cuando esto es descrito estrictamente y comúnmente
disponible, es un patrón.
Uno de los aspectos más importantes de los patrones arquitectónicos es que
encarnan diferentes atributos de calidad. Por ejemplo, algunos patrones
representan soluciones a problemas de rendimiento y otros pueden ser utilizados
con éxito en sistemas de alta disponibilidad. A primeros de la fase de diseño, un
arquitecto de software escoge qué patrones arquitectónicos mejor ofrecen las
calidades deseadas para el sistema.

11. UNIVERSIDAD MAYOR DE SAN ANDRES
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMATICA
DISEÑO ARQUITECTÓNICO Y PATRONES
INGENIERIA DEL SOFTWARE
INTEGRANTES

12.  CASTILLO MARCO
 MAYDANA CALLISAYA ROMAN
 TORREZ MIGUEL
2018