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.