UNIVERSIDAD TECNOLGICA DE PEREIRA INGENIERA DE SISTEMAS Y COMPUTACIN

CURSO DE INGENIERA DEL SOFTWARE II

El Diseo Arquitectoico 1
Los grandes sistemas siempre se descomponen en subsistemas que proporcionan algn
conjunto de servicios relacionados. El proceso de diseo inicial de identificar estos subsistemas
y establecer un marco de trabajo para el control y las comunicaciones de los subsistemas se
llama diseo arquitectnico. El resultado de este proceso de diseo es una descripcin de la
arquitectura del software.
El diseo arquitectnico es la primera etapa en el proceso de diseo y representa un enlace
crtico entre el diseo y el proceso de requerimientos. El proceso de diseo arquitectnico se
preocupa de establecer un marco de trabajo estructural que identifique los componentes
mayores de un sistema y la comunicacin entre estos componentes.
Bass y otros (2003) discuten tres ventajas de disear y documentar explcitamente una
arquitectura de software:
1. Comunicacin con Interesados: La arquitectura es una presentacin de alto nivel del
sistema que puede ser usada como foco para discutir con un amplio rango de
interesados.
2. Anlisis del Sistema: Hacer explcita la arquitectura del sistema en una etapa temprana
del desarrollo del sistema requiere algn anlisis. Las decisiones de diseo
arquitectnico tienen un profundo efecto sobre si el sistema puede cumplir
requerimientos crticos tales como desempeo, confiabilidad y mantenibilidad.
3. Reusabilidad a Gran Escala: Un modelo de la arquitectura del sistema es una
descripcin compacta y manejable de cmo el sistema est organizado y cmo
interoperan los componentes. La arquitectura del sistema es a menudo la misma para
sistemas similares y puede soportar reusabilidad del software a gran escala. Puede ser
posible desarrollar arquitecturas de lnea de productos donde la misma arquitectura es
usada a travs de un rango de sistemas relacionados.
Hofmeister y otros (2000) discuten cmo la etapa de diseo arquitectnico forza a los
diseadores de software a considerar aspectos clave del diseo de manera temprana en el
proceso. Ellos sugieren que la arquitectura del software puede servir como un plan de diseo
que es usado para negociar requerimientos y como un medio para estructurar discusiones con
clientes, desarrolladores y administradores. Tambin sugieren que es una herramienta esencial
para administrar la complejidad. Esconde los detalles y le permite a los diseadores enfocarse
en las abstracciones clave del sistema.
La arquitectura del sistema afecta el desempeo, robustez, distribuibilidad y mantenibilidad de
un sistema. El estilo y estructura particulares escogidos para una aplicacin puede entonces
depender de los requerimientos no funcionales:

Tomado de: Ian Sommerville, Software Engineering, Pearson Education, 8 Ed., 2007, ISBN 978-0-32131379-9.

UNIVERSIDAD TECNOLGICA DE PEREIRA INGENIERA DE SISTEMAS Y COMPUTACIN

CURSO DE INGENIERA DEL SOFTWARE II
1. Desempeo: Si el desempeo es un requerimiento crtico, la arquitectura debe ser
diseada para localizar las operaciones crticas en un pequeo nmero de
subsistemas, con tan poca comunicacin como sea posible entre estos subsistemas.
Esto puede significar el uso de componentes de grano relativamente grande en lugar
de componentes de grano fino para reducir la comunicacin entre componentes.
2. Seguridad: Si la seguridad es un requerimiento crtico, se debe usar una estructura en
capas para la arquitectura, con los activos ms crticos protegidos en las capas ms
internas y con un alto nivel de validacin de seguridad aplicado a estas capas.
3. Proteccin: Si la proteccin es un requerimiento crtico, la arquitectura debera estar
diseada de tal manera que las operaciones relacionadas con la proteccin estn
localizadas en un solo subsistema o en un pequeo nmero de subsistemas. Esto
reduce el costo y los problemas de la validacin de proteccin y hace posible
proporcionar sistemas relacionados con la proteccin.
4. Disponibilidad: Si la disponibilidad es un requerimiento crtico, la arquitectura debera
ser diseada para incluir componentes redundantes de tal manera que sea posible
reemplazar y actualizar componentes sin parar el sistema.
5. Mantenibilidad: Si la mantenibilidad es un requerimiento crtico, la arquitectura del
sistema debera ser diseada usando componentes de grano fino, auto contenidos que
puedan ser cambiados rpidamente. Los productores de datos deberan estar
separados de los consumidores y se deberan evitar las estructuras de datos
compartidas.
Obviamente hay conflictos potenciales entre algunas de estas arquitecturas. Por ejemplo, usar
componentes de grano grueso mejora el desempeo y usar componentes de grano fino
mejora la mantenibilidad. Si ambos son requerimientos importantes para el sistema, se debe
encontrar alguna solucin de compromiso. Algunas veces esto se puede cumplir usando
diferentes estilos arquitectnicos para diferentes partes del sistema.
Hay un traslape significativo entre el proceso de requerimientos y el diseo arquitectnico.
Idealmente, la especificacin de un sistema no debera incluir ninguna informacin de diseo.
En la prctica esto no es realista excepto para sistemas muy pequeos. La descomposicin
arquitectnica es necesaria para estructurar y organizar la especificacin. Se puede usar un
modelo arquitectnico como punto de inicio para la especificacin de subsistemas.
Un diseo de subsistemas es una descomposicin abstracta de un sistema en componentes de
grano grueso, cada uno de los cuales puede ser un sistema substancial por derecho propio. Las
cajas dentro de las cajas indican que el subsistema ha sido descompuesto a su vez en
subsistemas. Las flechas significan que los datos y las seales de control se pasan de
subsistema a subsistema en la direccin de las flechas. Los diagramas de bloques presentan un
grfico de alto nivel de la estructura del sistema, que la gente de diversas disciplinas
interesada en el sistema puede comprender fcilmente.
Por ejemplo, la siguiente figura es un modelo abstracto de la arquitectura para un sistema de
robot empacador que muestra los subsistemas que tienen que ser desarrollados. Este sistema
de robot puede empacar diferentes clases de objetos. Usa un subsistema de visin para
escoger objetos en una cinta transportadora (conveyor), identifica el tipo de objeto y
2

UNIVERSIDAD TECNOLGICA DE PEREIRA INGENIERA DE SISTEMAS Y COMPUTACIN

CURSO DE INGENIERA DEL SOFTWARE II
selecciona la clase correcta de empaquetamiento. El sistema entonces mueve los objetos
desde la cinta transportadora de envos a ser empacados. Ubica los objetos empacados sobre
otra cinta transportadora.

Bass y otros (2003) reclaman que diagramas simples de cajas y lneas no son representaciones
arquitectnicas tiles porque no muestran la naturaleza de las relaciones entre componentes
del sistema ni muestran las propiedades visibles externamente de los componentes. Desde el
punto de vista de un diseador de software, esto es absolutamente correcto. Sin embargo,
este tipo de modelo es efectivo para comunicarse con los interesados en el sistema y para
planeacin de proyectos, porque no est superpoblado de detalles. Los interesados pueden
comprender una visin abstracta del sistema. El modelo identifica los subsistemas clave que
van a ser desarrollados de manera independiente para que los administradores puedan
comenzar a asignar personas para planear el desarrollo de estos sistemas. Los diagramas de
cajas y lneas ciertamente no deberan ser la nica representacin usada del sistema; sin
embargo, son uno de los muchos modelos tiles.
El problema general de decidir cmo descomponer el sistema en subsistemas es difcil. Por
supuesto, los requerimientos del sistema son un factor mayor y usted debera tratar de crear
un diseo donde haya una cercana concordancia entre requerimientos y subsistemas. Esto

UNIVERSIDAD TECNOLGICA DE PEREIRA INGENIERA DE SISTEMAS Y COMPUTACIN

CURSO DE INGENIERA DEL SOFTWARE II
significa que, si el requerimiento cambia, este cambio probablemente ser localizado en lugar
de distribuido a travs de varios subsistemas.

1. Decisiones de Diseo Arquitectnico

El diseo arquitectnico es un proceso creativo donde usted trata de establecer una
organizacin del sistema que satisfaga los requerimientos funcionales y no funcionales del
sistema. Como es un proceso creativo, las actividades dentro del proceso difieren radicalmente
dependiendo del tipo de sistema siendo desarrollado, la hoja de vida y experiencia del
arquitecto del sistema y los requerimientos especficos del sistema. Entonces es ms til
pensar el proceso de diseo arquitectnico desde el punto de vista de las decisiones en lugar
del punto de vista de las actividades. Durante el proceso de diseo arquitectnico, los
arquitectos de sistemas tienen que tomar una cantidad de decisiones fundamentales que
afectan profundamente el sistema y su proceso de desarrollo. Con base en su conocimiento y
experiencia, ellos tienen que responder las siguientes preguntas fundamentales:
1. Hay una arquitectura genrica de aplicacin que pueda actuar como una plantilla para
el sistema que est siendo diseado?
2. Cmo ser distribuido el sistema a travs de una cantidad de procesadores?
3. Qu estilo o estilos arquitectnicos son apropiados para el sistema?
4. Cual ser el enfoque fundamental utilizado para estructurar el sistema?
5. Cmo las unidades estructurales del sistema se descomponen en mdulos?
6. Qu estrategia ser usada para controlar la operacin de las unidades del sistema?
7. Cmo se evaluar el diseo arquitectnico?
8. Cmo debera ser documentada la arquitectura del sistema?
Aunque cada sistema de software es nico, los sistemas en el mismo dominio de aplicacin a
menudo tienen arquitecturas similares que reflejan los conceptos fundamentales del dominio.
Estas arquitecturas de aplicacin pueden ser genricas, tales como la arquitectura de sistemas
de administracin de la informacin, o mucho ms especficas. Por ejemplo, las aplicaciones de
lneas de productos son aplicaciones que estn construidas alrededor de una arquitectura
ncleo con variantes que satisfacen los requerimientos especficos del cliente. Cuando se
disea una arquitectura del sistema, hay que decidir qu tienen en comn su sistema y clases
de aplicacin ms amplias, y decidir cunto conocimiento de estas arquitecturas de aplicacin
puede ser reutilizado.
Para sistemas embebidos y sistemas diseados para computadoras personales, usualmente
slo hay un procesador y usted no tendr que disear una arquitectura distribuida a travs de
muchos computadores distintos. Sin embargo, la mayora de los sistemas son ahora sistemas
distribuidos donde el software del sistema est distribuido en muchas computadoras
diferentes. La eleccin de la arquitectura distribuida es una decisin clave que afecta el
desempeo y la confiabilidad del sistema.
La arquitectura de un sistema de software se puede basar en un modelo arquitectnico
particular o estilo. Un estilo arquitectnico es un patrn de organizacin del sistema tal como
una organizacin cliente-servidor o una arquitectura en capas. Una conciencia de estos estilos,
sus aplicaciones, y sus fortalezas y debilidades es importante. Sin embargo, las arquitecturas
4

UNIVERSIDAD TECNOLGICA DE PEREIRA INGENIERA DE SISTEMAS Y COMPUTACIN

CURSO DE INGENIERA DEL SOFTWARE II
de la mayora de los grandes sistemas no se apegan a un solo estilo. Partes diferentes del
sistema pueden ser diseadas usando diferentes estilos arquitectnicos. En algunos casos, la
arquitectura del sistema global puede ser una arquitectura compuesta que es creada
combinando diferentes estilos arquitectnicos.
La nocin de Garlan y Shaw de un estilo arquitectnico cubre las siguientes tres preguntas de
diseo. Usted ha escogido la estructura ms apropiada tal como cliente servidor, o estructura
en capas, que le permitir cumplir los requerimientos del sistema. Para descomponer las
unidades estructurales del sistema en mdulos, usted decide sobre la estrategia de
descomposicin de subsistemas en sus componentes o mdulos. El enfoque que usted use le
permite diferentes tipos de arquitectura a ser implementada. Finalmente, en el proceso de
modelamiento del control, usted toma decisiones acerca de cmo se controla la ejecucin de
los subsistemas. Usted desarrolla un modelo general de relaciones de control entre las partes
establecidas del sistema.
Evaluar un diseo arquitectnico es difcil porque la verdadera prueba de una arquitectura
est en qu tan bien cumple sus requerimientos funcionales y no funcionales despus de que
ha sido desplegada. Sin embargo, en algunos casos usted puede hacer algunas evaluaciones
comparando su diseo contra diseos de referencia o contra modelos arquitectnicos
genricos.
El producto de un proceso de diseo arquitectnico es un documento de diseo
arquitectnico. Este puede incluir una cantidad de representaciones grficas junto con texto
descriptivo asociado. Debera describir cmo el sistema se estructura en subsistemas, el
enfoque adoptado y cmo cada subsistema se estructura en mdulos. Los modelos grficos del
sistema presentan diferentes perspectivas sobre la arquitectura. Los modelos arquitectnicos
que pueden ser desarrollados pueden incluir:
1. Un modelo de estructura esttico: muestra los subsistemas o componentes que van a
ser desarrollados como unidades independientes.
2. Un modelo dinmico de procesos: muestra cmo el sistema est organizado en
procesos en tiempo de corrida. Este puede ser diferente del modelo esttico.
3. Un modelo de interfaces: define los servicios ofrecidos por cada subsistema a travs
de su interfaz pblica.
4. Un modelo de relaciones: muestra las relaciones tales como flujo de datos, entre los
subsistemas.
5. Un modelo de distribucin: muestra cmo los subsistemas pueden ser distribuidos
entre las computadoras.
Varios investigadores han propuesto el uso de lenguajes de descripcin arquitectnica (ADLs)
para describir arquitecturas de sistemas. Bass y otros (2003) describen las principales
caractersticas de estos lenguajes. Los elementos bsicos de los ADLs son los componentes y
los conectores, e incluyen reglas y guas para arquitecturas bien formadas. Sin embargo, como
todos los lenguajes especializados, los ADLs slo pueden ser comprendidos por expertos en el
lenguaje y son inaccesibles a los especialistas en el dominio de la aplicacin. Esto los hace
difciles de analizar desde un punto de vista prctico. Seguramente sern usados en un

UNIVERSIDAD TECNOLGICA DE PEREIRA INGENIERA DE SISTEMAS Y COMPUTACIN

CURSO DE INGENIERA DEL SOFTWARE II
pequeo nmero de aplicaciones. Los modelos y notaciones informales tales como UML
permanecern siendo la notacin ms ampliamente usada para descripciones arquitectnicas.