Arquitectura del Sistema

Documentacin basada en los textos:

UML y Patrones: una introduccin al anlisis y diseo
orientado a objetos y al proceso unificado, 2 edicin,
Craig Larman, Ed. Prentice-Hall, 2002 (2003 la edicin
en Espaol), Captulo 30 pp. 417-442, Captulo 23 pp.
346-355
Una Arquitectura Software Basada en Agentes y
Recomendaciones Metodolgicas para el Desarrollo de
Entornos Virtuales de Entrenamiento con Tutora
Inteligente, Gonzalo Mndez, Tesis Doctoral,
Universidad Politcnica de Madrid, 2008

1. Introduccin
El campo de las arquitecturas software, como rea de investigacin, es relativamente
nuevo. En (Shaw y Clements, 2006b; Shaw y Clements, 2006a) se hace un repaso de la
historia de esta disciplina, y aunque la primera mencin de arquitectura software data
del ao 1969, cuando Ian P. Sharp utiliz el trmino en una conferencia de la OTAN
(Randell y Buxton, 1970), no es hasta mediados de los aos 90 cuando de verdad ha
empezado a despegar, considerando los expertos en el rea que es aproximadamente a
partir del ao 2000 cuando ha alcanzado su mayor apogeo (Shaw y Clements,2006a;
Kruchten et al., 2006).
Se define arquitectura software como la estructura del sistema, que comprende
elementos software, las propiedades de esos elementos visibles externamente y las
relaciones entre ellos. La arquitectura software conforma el esqueleto de cualquier
sistema software, y es la principal responsable de los atributos de calidad del sistema.
Una arquitectura adecuada, correctamente diseada, documentada y evaluada,
constituye la base para que un proyecto finalice con xito (Bass et al., 2003).
Esta definicin implica que la arquitectura de un sistema define componentes y la
interaccin existente entre ellos, pero no detalles internos a esos componentes, que se
puede considerar que no pertenecen a la arquitectura de la aplicacin. Adems, la
arquitectura del sistema se puede ver desde un nmero no determinado de perspectivas,
todas ellas vlidas siempre que valgan para algn fin: anlisis, comunicacin o
comprensin.
Se define estilo arquitectnico como la abstraccin de distintas arquitecturas software
(Klein et al., 1999). As, las conocidas como arquitectura cliente-servidor o arquitectura
en tres capas seran, en realidad, estilos arquitectnicos.
Se han desarrollado diversos mtodos para disear, documentar y evaluar arquitecturas
software, como pueden ser el Attribute-Driven Design (ADD), Attribute-Based
Architectural Styles (ABAS), Quality Attribute Workshop (QAW), Active Reviews for

Intermediate Designs (ARID), Architecture Tradeoff Analysis Method (ATAM), CostBenefit Analysis Method (CBAM) y Views and Beyond (V&B). Resultan
especialmente interesantes porque no son tcnicas independientes, sino que se
proporcionan formas de combinar unas con otras (Nord et al., 2004).
Attribute-Driven Design (ADD) es un mtodo de diseo arquitectnico dirigido por
los atributos de calidad que se quiere que posea el sistema, ms que por la funcionalidad
de la aplicacin, que queda en un segundo nivel (Bass et al., 2001).
Las entradas para el mtodo ADD son los requisitos de calidad del sistema expresados
en forma de escenarios generales, y la salida es una arquitectura conceptual (Hofmeister
et al., 2000), la cual ayuda a alcanzar los atributos de calidad deseados y proporciona la
estructura necesaria para dotar al sistema de la funcionalidad requerida.
Attribute-Based Architectural Styles (ABAS) (Klein y Kazman, 1999), por su parte,
es a la arquitectura lo que los patrones de diseo a los objetos, es decir, son soluciones
basadas en estilos arquitectnicos que han surgido de la experiencia de resolver
problemas que se presentan de manera frecuente. ABAS utiliza los atributos de calidad
para definir un marco de aplicacin de un estilo arquitectnico concreto,
proporcionando un razonamiento, cuantitativo o cualitativo, que fundamente la
utilizacin de un estilo arquitectnico en un diseo determinado.
Architecture Tradeoff Analysis Method (ATAM) (Kazman et al., 2000) es la
evolucin de un mtodo anterior llamado SAAM (Software Architecture Analysis
Method) (Kazman et al., 1994), para el anlisis de arquitecturas software basado en la
utilizacin de escenarios, en el que la evaluacin de una arquitectura no se realiza para
identificar de manera precisa el comportamiento de un atributo de calidad, lo cual no es
posible en fases tempranas del diseo por falta de informacin, sino para descubrir qu
decisiones de diseo afectan de una u otra forma a los atributos de calidad. Esto se hace
a travs de la identificacin de:
Riesgos: decisiones aplazadas o decisiones cuyo efecto no se alcanza a valorar.
Puntos sensibles: partes de la arquitectura que pueden tener mucha influencia en
algn atributo de calidad.
Puntos de compromiso: partes de la arquitectura cuya modificacin significa
mejorar algn atributo de calidad a costa de empeorar otro. Es lo que sucede, en
algunos casos, con la modificabilidad y el rendimiento.
El objetivo es poder tomar decisiones razonadas acerca del diseo para, en sucesivos
anlisis, dedicar ms esfuerzo a completar esas partes de la arquitectura.
Active Reviews for Intermediate Designs (ARID) (Clements, 2000) es un mtodo de
anlisis de arquitecturas resultado de combinar Active Design Reviews (ADR), (Parnas
yWeiss, 1985) y ATAM. Resulta ms ligero que ATAM y es til para ser aplicado en
etapas ms tempranas del diseo arquitectnico e, incluso, sobre partes del sistema en
lugar de sobre el sistema completo. La evaluacin se basa en detallar el funcionamiento
del sistema en una serie de escenarios predefinidos, a travs de lo cual se pueden
identificar posibles puntos problemticos de la arquitectura.
Su utilidad no se encuentra en la sustitucin de ATAM, sino que ms bien prepara el
camino en sistemas en los que, por su complejidad, puedan ser necesarias revisiones de
la arquitectura en etapas intermedias del diseo.

Quality Attribute Workshop (QAW) (Barbacci et al., 2003) es un mtodo creado para
complementar ATAM. Su utilidad reside en la identificacin de los atributos de calidad
que dirigen el proceso de diseo de la arquitectura, por lo que su aplicabilidad es previa
al diseo arquitectnico. Ms concretamente, lo que pretende definir este mtodo es el
significado de los atributos de calidad en el contexto del sistema en desarrollo, la
manera de descubrir, caracterizar y priorizar los atributos de calidad, y la forma de
utilizar esta informacin. El resultado de este proceso es una lista de factores que van a
dirigir el diseo de la arquitectura y una lista de escenarios que servirn para evaluar los
atributos de calidad.
Cost-Benefit Analysis Method (CBAM) (Kazman et al., 2002) es un mtodo para
evaluar los beneficios, costes y riesgos de las diferentes decisiones que se toman para
disear la arquitectura software del sistema. Al igual que QAW, tambin est pensado
para su integracin con ATAM, ya que los resultados producidos por la evaluacin de la
arquitectura, especialmente las estrategias arquitectnicas a seguir, se utilizan como
entrada en CBAM para tomar decisiones basadas en criterios econmicos.

2. Documentacin de una Arquitectura

Views and Beyond (V&B) (Clements et al., 2002a) es la propuesta realizada en el SEI
para documentar la arquitectura software de un sistema. De acuerdo con la definicin de
arquitectura como la estructura o estructuras del sistema, V&B propone la definicin de
una serie de vistas relevantes de la arquitectura software del sistema, documentando
cada una de ellas, as como las caractersticas que afecten a ms de una o a todas en
general. El nmero y el tipo de las vistas de un sistema no estn determinados a priori,
aunque en general se pueden agrupar en vistas de mdulos, vistas de componentes y
conectores, vistas de localizacin y combinaciones de ellas. Para documentar las vistas
de una manera sistemtica y homognea han creado unas plantillas que contienen la
estructura de la informacin que debe aportarse sobre cada vista.
En la misma lnea se mueve el estndar IEEE 1471-2000 (IEEE, 2000), que define un
marco conceptual para describir arquitecturas y la informacin que debe incluir una
documentacin que cumpla el estndar. Tambin utilizan el concepto de vista como una
representacin del sistema desde el punto de vista de un conjunto de intereses.
En (Clements, 2005) se realiza una comparacin entre las dos formas de documentar
una arquitectura, y se demuestra que utilizando V&B es posible satisfacer los requisitos
impuestos por el estndar IEEE 1471-2000.

3. Arquitectura Software y el Proceso Unificado

Otro factor que est impulsando la utilizacin de arquitecturas software es la adopcin
del Proceso Unificado de desarrollo de software. En (Kroll y Kruchten, 2003) se
describe el proceso unificado como dirigido por casos de uso y centrado en la
arquitectura, es decir, que utiliza la arquitectura software del sistema como elemento
central del desarrollo para coordinar a todos los miembros del equipo. Tambin manejan
la idea del uso de vistas para describir la arquitectura del sistema (Kruchten, 1995). Sin
embargo, existen diferencias importantes respecto al trabajo realizado en el SEI.
La primera y quiz ms importante es la menor claridad de los conceptos que se
manejan, ya que definen repetidamente el concepto de arquitectura como el conjunto de

elementos arquitectnicamente significativos, definicin recursiva que viene a aportar

poca luz al panorama de las arquitecturas software.
En segundo lugar, se alejan bastante de la importancia que pueden tener los atributos de
calidad del sistema, y se llega a proponer que, cuando se est en dificultades para
cumplir los plazos de un proyecto, las alternativas pasan por recortar funcionalidades
menores de la aplicacin o reducir la calidad de la misma. Esta cuestin no se planteara
de considerar los atributos de calidad como parte de la arquitectura, pues llegados al
punto de ver que no se cumple con lo planificado, lo ms probable es que los atributos
de calidad ya estuviesen incluidos en el planteamiento del sistema desde etapas
tempranas del desarrollo.
En tercer lugar, las evaluaciones de la arquitectura se plantean siempre sobre
arquitecturas ejecutables, es decir, sobre prototipos del sistema o de la parte del sistema
que se quiere evaluar. Esto implica, por un lado, la necesidad de implementar un
prototipo para poder evaluar la arquitectura, y por otro, un gasto extra de recursos para
evaluar decisiones que pueden no ser vlidas, por lo que una evaluacin previa evitara
el desarrollo de algunos de los prototipos y, por tanto, el gasto de recursos.
Finalmente, el modelo de las 4+1 vistas de la arquitectura marca la necesidad de
documentar, para cada sistema en desarrollo, las siguientes vistas:
Vista lgica: existe para cualquier sistema y muestra su estructura.
Vista de proceso: vlida en sistemas distribuidos y concurrentes para mostrar el
paralelismo entre distintas entidades.
Vista de implementacin: organizacin de los elementos de implementacin,
como cdigo fuente, ejecutables y libreras.
Vista de despliegue: muestra dnde se sita cada componente en tiempo de
ejecucin y cmo se comunican entre ellos.
Vista de casos de uso: contiene los requisitos ms significativos, tanto
funcionales como no funcionales, que tienen ms impacto en la arquitectura.
Sirve para unir y coordinar las cuatro vistas anteriores.
Como se puede ver, en este caso s se definen las vistas que tienen que existir,
limitndolas a 5, y obligando a la coordinacin a travs de la vista de casos de uso. Esto
convierte esta manera de documentar en poco adecuada para sistemas que no sean
fcilmente descritos a travs de casos de uso, si bien es cierto que, de ser ste el caso, es
poco probable que se utilice el Proceso Unificado como mtodo de desarrollo.
Tanta es la diferencia entre las dos visiones, y tantas lagunas parece tener el Proceso
Unificado, que ya se han realizado esfuerzos para incluir las tcnicas desarrolladas en el
SEI dentro de ste (Kazman et al., 2004).
En UML los componentes de la arquitectura se muestran usando PAQUETES. Un
paquete es un artificio de representacin, que no tiene por qu corresponder con ningn
elemento software concreto. Los paquetes pueden anidarse:

4. Arquitectura por Capas

Una aproximacin habitual a la arquitectura del sistema consiste en dividirlo en 3
niveles o capas:
Presentacin: Se encarga de las ventanas, informes, etc.
Negocio o Lgica de la aplicacin: Incluye los elementos del dominio y la
operativa por la cual funcionan.
Almacenamiento: Se encarga de manejar el mecanismo de almacenamiento de
datos elegido.

Una arquitectura de mltiples niveles tiene varias ventajas:

Desarrollo: Asignacin de distintos niveles a distintos equipos de trabajo.
Despliegue: Distintos niveles pueden estar distribuidos en distintos procesos y/o
mquinas.
Reutilizacin: Un nivel bien construido es ms fcilmente reutilizable.
En este curso nos ocupamos principalmente del diseo de la capa de la Lgica de
Negocio. En ocasiones se descompone esta capa en varios sub-niveles:
5

 Aplicacin: Se encarga de la gestin del flujo de trabajo, el estado de la sesin,

transiciones entre ventanas/pantallas
Objetos del Dominio: Contiene los conceptos del dominio, como venta, cuenta,
cliente, etc. Implementa las reglas de negocio o de dominio
Servicios del Dominio: Servicios del negocio de bajo nivel muy generales que se
pueden usar en varios dominios.
Habitualmente aparece, por debajo de la capa de Lgica de Negocio, una capa de
Servicios Tcnicos, que a su vez se puede descomponer en varios niveles:
Frameworks: de seguridad, persistencia
Base: Libreras, estructuras de datos, hilos de ejecucin, manejo de ficheros, etc.

5. El Nivel de Presentacin
Idealmente, ningn otro nivel debera tener visibilidad directa sobre los elementos del
nivel de presentacin.
Esto se puede conseguir aplicando el Principio de Separacin Modelo-Vista.

Problema: Conviene desacoplar los objetos del dominio (modelo) de la presentacin

(vista) y reducir al mnimo el impacto que los cambios de la interfaz de usuario tienen
en ellos.
Solucin:
Los objetos del dominio no tendrn visibilidad sobre los objetos de la interfaz
Los datos del dominio no deben guardarse en las clases de la interfaz
Las clases de la interfaz son muy ligeras, slo se encargan de la entrada y salida
Con esto se consigue:
Que el modelo de objetos del dominio sea ms cohesivo, sin ocuparse de detalles
de presentacin.
Reducir el impacto que posibles cambios en la interfaz puedan tener en el nivel
del dominio.
Permitir que se puedan conectar distintas interfaces a la misma aplicacin
(terminales de venta, web, etc.).
Mejor portabilidad
El problema de la Separacin Modelo-Vista es cmo mostrar informacin al usuario
desde el nivel del dominio? Existen dos alternativas:
Tirar-desde-arriba (pull-from-above): muestreo (polling) desde una clase de
presentacin al nivel del dominio para ver si hay algn dato nuevo que mostrar
Empujar-Desde-Abajo (push-from-below):
o Utilizando una Fachada (de GoF) del nivel de Presentacin
o Utilizando el patrn Publicar-Suscribir o patrn Observador (de GoF)

BIBLIOGRAFA COMPLEMENTARIA
Barbacci, M. R. et al. (2003) Quality Attribute Workshops, Third Edition. Inf. Tec.
CMU/SEI-2003-TR-016, Software Engineering Institute - Carnegie Mellon University,
Pittsburg, PA, USA.
Bass, L. et al. (2001) Quality Attribute Design Primitives and the Attribute Driven
Design Method. En F. van der Linden (ed.), PFE '01: Revised Papers from the 4th
International Workshop on Software Product-Family Engineering, tomo 2290 de
Lecture Notes in Computer Science, pags. 169-186. ACM, Springer-Verlag.
Bass, L. et al. (2003) Software Architecture in Practice. Addison-Wesley, Boston, MA,
second edition
Clements, P. C. (2000) Active Reviews for Intermediate Designs. Inf. Tec. CMU/SEI2000-TN-009, Software Engineering Institute Carnegie Mellon University, Pittsburg,
PA, USA.
Clements, P. (2005) Comparing the SEI's Views and Beyond Approach for
Documenting Software Architectures with ANSI-IEEE 1471-2000. Inf.Tec. CMU/SEI2005-TN-017, Software Engineering Institute Carnegie Mellon University.

Hofmeister, C. et al. (2000) Applied Software Architecture. AddisonWesley

Kazman, R. et al. (1994) SAAM: A Method for Analyzing the Properties Software
Architectures. En Proceedings of the 16th International Conference on Software
Engineering, pags. 81-90. Sorrento, Italy.
Kazman, R. et al. (2000) ATAM: Method for Architecture Evaluation. Inf.Tec.
CMU/SEI-2000-TR-004, Software Engineering Institute Carnegie Mellon University,
Pittsburg, PA, USA.
Kazman, R. et al. (2002) Making Architecture Design Decisions: An Economic
Approach. Inf. Tec. CMU/SEI-2002-TR-035, Software Engineering Institute - Carnegie
Mellon University, Pittsburg, PA, USA.
Kazman, R. et al. (2004) Integrating Software-Architecture-Centric Methods into the
Rational Unified Process. Inf. Tec. CMU/SEI-2004-TR-011, Software Engineering
Institute - Carnegie Mellon University, Pittsburg, PA, USA.
Klein, M. y Kazman, R. (1999) Attribute-Based Architectural Styles. Inf. Tec.
CMU/SEI-99-TR-022, Software Engineering Institute Carnegie Mellon University,
Pittsburg, PA, USA.
Klein, M. H. et al. (1999) Attribute-Based Architecture Styles. En Software
Architecture, Proceedings of the First Working IFIP Conference on Software
Architecture (WICSA1), pags. 225-243. Kluwer Academic Publishers, San Antonio,
Texas, USA.
Kroll, P. y Kruchten, P. (2003) The Rational Unified Process Made Easy. A
Practitioner's Guide to the RUP. Object Technology. Addison Wesley. Kruchten, P.
(1995) The 4+1 View Model of Architecture. IEEE Software, 6(12): pags. 45-50.
Kruchten, P. et al. (2006) The Past, Present and Future of Software Architecture. IEEE
Software, 23(2): pags. 22-30.
Nord, R. L. et al. (2004) Integrating the Quality Attribute Workshop (QAW) and the
Attribute-Driven Design (ADD) Method. Inf. Tec. CMU/SEI-2004-TN-017, Software
Engineering Institute Carnegie Mellon University, Pittsburg, PA, USA.
Parnas, D. L. y Weiss, D. (1985) Active Design Reviews: Principles and Practice. En
Proceedings, Eighth International Conference on Software Engineering, pags. 132-136.
Randell, B. y Buxton, J. (eds.) (1970) Software Engineering Techniques: Report of a
Conference Sponsored by the NATO Science Committee. Scientific Affairs Division,
NATO.
Shaw, M. y Clements, P. (2006a) The Golden Age of Software Architecture. IEEE
Software, 23(2): pags. 31-39.
Shaw, M. y Clements, P. (2006b) The Golden Age of Software Architecture: A
Comprehensive Survey. Inf. Tec. CMU-ISRI-06-101, Institute for Software Research
International, Carnegie Mellon University, Pittsburgh, PA, USA.