Escuela Técnica Superior de Ingeniería Informática Departamento: Ingeniería de Software y Sistemas Informáticos Trabajo de Investigación Arquitecturas Software: Gestión de los atributos de calidad de un sistema y su incorporación en ArchE para la mejora del análisis, evaluación y soporte en la toma de decisiones durante el desarrollo arquitectónico Alumno: Jesús Martín Fernández jesus.martin@dicoruna.es septiembre 2010
Tabla de contenidos 1. Introducción 2. El Ciclo de las Arquitecturas de Negocio (ABC) 3. Comprendiendo la Arquitectura Software 4 Comprendiendo los atributos de calidad del software: 4.1 Funcionalidad y arquitectura 4.2 Los escenarios de atributos de calidad 4.3 Los principales atributos de calidad en detalle 5 El Proceso de la Arquitectura Software 5.1 Establecer los Requisitos Software 5.2 Diseño de la Arquitectura 5.3 Validación del Diseño 5.4 El Diseño Dirigido por Atributos de Calidad (ADD) 6 Cómo alcanzar los atributos de calidad 6.1 Tácticas arquitectónicas de disponibilidad 6.2 Tácticas arquitectónicas de rendimiento/desempeño 6.3 Tácticas arquitectónicas de modificabilidad 6.4 Tácticas arquitectónicas de seguridad 6.5 Tácticas arquitectónicas de usabilidad 6.6 Tácticas arquitectónicas de testeabilidad 7 Comprendiendo los Patrones Arquitectónicos en términos de Tácticas y Modelos 8 Diseño de la Arquitectura Software con ArchE 8.1 ArchE como sistema experto 8.2 Conceptos clave 8.3 Actividades básicas 8.4 Marcos de razonamiento: creando modelos de atributos de calidad 9 Utilizando ArchE en un caso práctico: CTAS 9.1 Descripción del caso práctico 9.2 Casos de uso 9.3 Especificación de los requisitos y sus relaciones en ArchE 9.4 Ejemplos prácticos 9.5 Valoración de ArchE 10 Conclusiones Referencias 1
Lista de Figuras Figura 1: Figura 2: Figura 3: Figura 4: Figura 5: Figura 6: Figura 7: Figura 8: Figura 9: Figura 10: Figura 11: Figura 12: Figura 13: Figura 14: Figura 15: Figura 16: Figura 17: Figura 18: Figura 19: Figura 20: Figura 21: Figura 22: Figura 23: Figura 24: Figura 25 Figura 26 Figura 27 Figura 28 Figura 29 Figura 30 Figura 31 Figura 32 Figura 33 El Ciclo de las Arquitecturas de Negocio Relaciones entre los conceptos Modelo de Referencia, Patrón Arquitectónico, Arquitectura de Referencia y Arquitectura Software Modelo Arquitectónico de 4+1 Vistas de Philippe Kruchten Relación entre las arquitecturas software, los atributos de calidad, los objetivos de negocio y la funcionalidad del sistema Partes de los escenarios de calidad El Proceso de la Arquitectura Software Entradas y salidas en la determinación de los requisitos arquitectónicos Entradas y salidas en el diseño de la arquitectura El modelo de ciclo de vida de la arquitectura software Los pasos del Diseño Dirigido por Atributos de Calidad (ADD) Utilización de tácticas para controlar los estímulos Resumen de las tácticas de disponibilidad Resumen de las tácticas de rendimiento Resumen de las tácticas de modificabilidad Resumen de las tácticas de seguridad Resumen de las tácticas de usabilidad Resumen de las tácticas de testeabilidad Estructura del patrón intermediario Estructura del patrón modelo-vista-controlador Estructura del patrón micro-núcleo Estructura del patrón reflexión Flujo global en ArchE Conceptos clave en ArchE y sus relaciones Implementación de un marco de razonamiento Estructura arquitectónica del sistema ArchE Diagrama de secuencia de la interacción entre ArchE y los marcos de razonamiento Diagrama de casos de uso de CTAS Relación de escenarios de CTAS Pantalla de ArchE para añadir/modificar una relación entre responsabilidades Modelo inicial propuesto por ArchE para CTAS Gráfico inicial de responsabilidades del sistema CTAS Vista de Evaluación de Resultados de CTAS Vista de evaluación de resultados mostrando la evaluación de resultados de aplicar las tácticas sobre los escenarios 2
Figura 34 Vista de evaluación inicial de resultados del ejemplo 1 Figura 35 Vista de evaluación de resultados del ejemplo 1 después de la primera iteración Figura 36 Vista de evaluación de resultados del ejemplo 1 después de la segunda iteración Figura 37 Modelo final propuesto por ArchE para el ejemplo 1 Figura 38 Figura 39 Pantalla de ArchE para añadir o modificar un escenario Vista de mapeos entre escenarios y responsabilidades Figura 40 Pantalla de ArchE para añadir o modificar un mapeo entre un escenario y una responsabilidad Figura 41 Modelo final propuesto por ArchE para el ejemplo 2 Figura 42 Gráfico final de responsabilidades del ejemplo 2 3
Lista de Tablas Tabla 1: Comparativa entre estilo arquitectónico y patrón arquitectónico Tabla 2: Actores del sistema CTAS Tabla 3: Atributos de calidad del sistema CTAS Tabla 4: Relación de casos de uso del sistema CTAS por actor Tabla 5: Relación de funciones del sistema CTAS Tabla 6: Relación de responsabilidades del sistema CTAS Tabla 7: Mapeo de escenarios a responsabilidades Tabla 8: Tabla de generación de escenarios generales de modificabilidad Tabla 9 Tabla de generación de escenarios generales de rendimiento Tabla 10 Relación de preguntas formuladas por ArchE para el diseño inicial del sistema CTAS Tabla 11 Descripción del escenario del ejemplo 2 Tabla 12 Descripción del escenario del ejemplo 3 Tabla 13 Descripción del escenario del ejemplo 4 Tabla 14 Descripción del escenario del ejemplo 5 Tabla 15 Descripción del escenario del ejemplo 6 4
1. Introducción La arquitectura del software está reconocida desde hace ya algunos años como una disciplina crucial en la ingeniería del software. De hecho, la arquitectura del software de un sistema se considera como clave en la comunicación y en la comprensión del sistema. Pero el proceso de análisis y diseño de la arquitectura del software es complejo. Las arquitecturas están determinadas por requisitos, tanto funcionales como de atributos de calidad, que a su vez están fuertemente condicionados por los objetivos de negocio de la organización y por sus restricciones. La introducción de los patrones arquitectónicos permitió gestionar mejorar el proceso de diseño de la arquitectura software y reducir la complejidad de la tarea. Sin embargo, aunque los patrones arquitectónicos han ayudado mucho en el diseño arquitectónico, estos patrones siguen siendo complejos y en cualquier caso siguen existiendo muchos detalles por resolver, como son por ejemplo las interacciones entre los distintos patrones. Los objetivos de este trabajo son múltiples. En primer lugar describir cómo los atributos de calidad ejercen una influencia decisiva sobre el diseño arquitectónico de los sistemas software. En segundo lugar mostrar cómo estos atributos de calidad pueden ser codificados de forma que puedan ser utilizados para analizar las arquitecturas y tomar mejores decisiones en el diseño arquitectónico. En tercer lugar analizar cómo la utilización de tácticas arquitectónicas y el diseño dirigido por atributos de calidad permiten mejorar el diseño arquitectónico. Para ello analizaré cada conjunto de tácticas arquitectónicas asociadas a cada uno de los principales atributos de calidad y veremos como estas tácticas nos ayudan a alcanzar los requisitos de atributos de calidad de nuestro sistema. Finalmente me centraré en el núcleo del trabajo que es analizar el asistente arquitectónico ArchE y ver en qué medida es capaz de incorporar los conceptos introducidos en los apartados anteriores, en especial las tácticas arquitectónicas y el diseño dirigido por atributos de calidad, de forma que ayude a los diseñadores a generar el diseño de las arquitecturas software que satisfagan los requisitos tanto funcionales como de atributos de calidad. En primer lugar se presenta el denominado ciclo ABC (Architectural Business Cycle). de arquitecturas de negocio. Considero de gran importancia empezar describiendo el ciclo de dependencias que existen sobre las arquitecturas, dado que de esta forma nos resultará más fácil comprender las ideas subyacentes en la arquitectura software, en los procesos de diseño y en los objetivos finales que se persiguen. La principal referencia bibliográfica utilizada fue [Bass 2003]. A continuación trato de explicar detalladamente el concepto de arquitectura software junto con todas sus implicaciones. También presento algunas definiciones de conceptos inter-relacionados como son los patrones arquitectónicos, los modelos de referencia y las arquitecturas de referencia. A partir de estos conceptos me centro en poner de manifiesto la importancia de la arquitectura software, que es lo que va a justificar el resto del trabajo. Incluyo, por su gran importancia, un apartado relativo a la documentación de las arquitecturas software: las estructuras y las vistas, para finalmente presentar el modelo arquitectónico de 4+1 vistas de Philippe Kruchten que hoy en día está institucionalizado como una de las bases conceptuales del Proceso Unificado de desarrollo de software para describir de forma completa la arquitectura de los sistemas software. Para esta parte del trabajo recopilé información de las siguientes referencias bibliográficas [Bass 2003, Clements 2003, Gorton 2006 y Shaw 96]. 5
Aprovecho también para hacer un recorrido por el proceso de la arquitectura software dado que nos resultará útil para posteriormente comprobar cómo la herramienta ArchE implementa los distintos pasos del proceso software, identificando los requisitos arquitectónicos, diseñando la arquitectura y validando los diseños de forma iterativa. Especial atención merece el apartado en el que se presenta el diseño dirigido por atributos de calidad (ADD Atribute Driven Design). ADD toma como entrada un conjunto de requisitos de atributos de calidad representados como escenarios y utiliza el conocimiento existente relativo a la relación entre atributos de calidad y arquitecturas software, para diseñar la arquitectura. Con respecto al apartado dedicado a ADD, las referencias que utilicé fueron [Bachmann 2000, Wood 2007 y Wojcik 2006]. El siguiente apartado se centra en determinar cómo alcanzar los atributos de calidad del software a través de las tácticas arquitectónicas. Hasta este punto se han caracterizado los atributos de calidad de un sistema en términos de una colección de escenarios, pero no se ha dicho nada de cómo el arquitecto es capaz de obtener estas cualidades requeridas por el sistema. Es el momento de ver de qué manera las tácticas arquitectónicas nos permiten crear diseños que satisfagan los requisitos de calidad especificados. Esta parte del trabajo está basada en las siguientes publicaciones [Barbacci 1996, Bachmann 2002 y Bachmann 2003]. Avanzando un poco más en los conceptos ya presentados, el siguiente apartado trata de explicar los patrones arquitectónicos en términos de tácticas y modelos arquitectónicos. Explico detalladamente los principales patrones arquitectónicos, indicando los problemas que se plantean, de qué forma se solucionan dichos problemas y cómo se implementan las distintas tácticas en los patrones arquitectónicos. Se trata también de un apartado muy importante de este trabajo, dado que serán estas tácticas las que trataremos de aplicar a través de la herramienta ArchE para mejorar nuestros diseños arquitectónicos y ser capaces de satisfacer tanto los requisitos funcionales como los de atributos de calidad del sistema a desarrollar. La principal referencia bibliográfica utilizada fue [Buschmann 1996], aunque también utilicé otras como [Bachmann 2007 y Scott 2007]. Una vez comprendidos todos los conceptos presentados en detalle hasta este punto, nos centramos en analizar la herramienta ArchE y ver de qué manera es capaz de soportar estos conceptos y ofrecer asistencia a los diseñadores para obtener mejores arquitecturas software. En primer lugar presentamos ArchE como sistema experto, sus conceptos clave y sus actividades básicas. ArchE es una herramienta que pretende servir como asistente en el diseño de las arquitecturas software. Para ello ArchE incorpora en un sistema experto conocimientos de teorías relativas a atributos de calidad, junto con las relaciones que existen entre los requisitos de los atributos de calidad y el diseño arquitectónico. ArchE utiliza estas teorías para predecir la respuesta de las arquitecturas a los atributos de calidad en situaciones concretas. Este apartado del trabajo es fundamental y en el utilizo ideas y conceptos obtenidos de buena parte de las referencias indicadas, aunque es cierto que existen algunas publicaciones específicas de ArchE como [Bachmann 2003 y SEI 2007], y otras relativas a sistemas expertos y marcos de razonamiento como [Bass 2005 y Friedman- Hill 2003] que me resultaron de gran ayuda. Como punto final del trabajo y apartado fundamental del mismo, utilicé la herramienta ArchE en un caso práctico: CTAS, que es el ejemplo que acompaña a la herramienta. El objetivo es analizar el funcionamiento de ArchE, su usabilidad para los propósitos identificados y su utilidad para alcanzar los objetivos establecidos. Las principales publicaciones utilizadas fueron el manual de usuario de ArchE obtenido de [SEI 2007] y [Bachmann 2007]. 6
En primer lugar presento en detalle el caso práctico CTAS, indicando la descripción de los actores identificados, el diagrama de casos de uso y los requisitos de atributos de calidad del sistema. A continuación detallo cómo a través de la herramienta ArchE podemos especificar los requisitos funcionales en forma de responsabilidades, los requisitos de atributos de calidad en forma de escenarios y como establecer las relaciones entre responsabilidades y escenarios. El siguiente paso es mostrar cómo ArchE, a partir de la información que le ha sido facilitada, es capaz de proponer un diseño inicial del sistema e indicar cuáles de los escenarios son satisfechos. Además, veremos cómo ArchE también nos propone las mejores tácticas arquitectónicas para mejorar nuestro diseño y nos solicita toda aquella información que pueda necesitar para poder realizar sus estimaciones y cálculos. A partir del caso inicial incluyo seis ejemplos en los cuales planteo distintas situaciones, en general la agregación de nuevos escenarios al sistema. Estos ejemplos me servirán para analizar la usabilidad de ArchE, su funcionalidad y determinar en qué medida ArchE es capaz de incorporar los métodos y conceptos analizados en los apartados anteriores. El objetivo final del presente trabajo de investigación es pues analizar y evaluar la herramienta ArchE para determinar su utilidad en el diseño de la arquitectura software, ver de qué manera es capaz de gestionar los atributos cualitativos del sistema, transformarlos en escenarios, utilizar el diseño dirigido por atributos de calidad y aplicar las tácticas arquitectónicas para mejorar la toma de decisiones en el desarrollo arquitectónico, de acuerdo con los objetivos de negocio de la organización. 7
2. El Ciclo de las Arquitecturas de Negocio (ABC) Lo primero que se debe tener presente es el hecho de que todo sistema informático se construye para satisfacer unos determinados objetivos de negocio, y un aspecto clave en su desarrollo es la arquitectura software del sistema. La cuestión que nos planteamos en este momento es la relación que existe entre la arquitectura software de un sistema y el entorno en el cual dicho sistema va a ser construido y va a existir. Como respuesta nos encontramos que toda arquitectura software es el resultado de una serie de influencias de su propio entorno: técnicas, sociales y del negocio. De hecho la propia arquitectura software va a afectar el ambiente técnico, social y de negocio que le rodea, y que posteriormente influenciará futuras arquitecturas. Este ciclo de influencias, del entorno a la arquitectura y de la arquitectura al entorno, se denomina Ciclo de las Arquitecturas de Negocio (ABC Arquitecture Business Cycle). En todo desarrollo software la gestión de los requisitos explicita solamente algunas de las propiedades deseadas del sistema final. En general no todos los requisitos de un sistema están directamente relacionados con las propiedades deseadas en dicho sistema. Las arquitecturas software normalmente son influenciadas por: Los objetivos de la organización La composición de la organización La formación y la experiencia de los arquitectos El ambiente técnico A su vez las arquitecturas afectan a los factores que las influencian: La composición de la organización Los objetivos de la organización Los requisitos del cliente La experiencia de los arquitectos La figura 1 muestra gráficamente este ciclo de influencias. Figura 1 El Ciclo de las Arquitecturas de Negocio (ABC Architecture Business Cycle) Las arquitecturas en primer lugar están influenciadas por todas aquellas personas que están interesadas en la construcción del sistema software: clientes, usuarios finales, desarrolladores, jefe de proyecto, encargados del mantenimiento e incluso las 8
personas responsables de comercializar el producto final. El conjunto de todas estas personas se conoce con el nombre de stakeholders. El problema que surge es que cada stakeholder tiene diferentes preocupaciones, intereses y objetivos, algunos de los cuales pueden ser incluso contradictorios. En la práctica no resulta habitual que los catálogos de requisitos de un sistema incluyan todos los requisitos de calidad del sistema deseado en un formato que pueda ser verificado. Además de por los objetivos de la organización expresados a través de los requisitos del sistema, las arquitecturas software son influenciadas por la propia estructura y/o naturaleza de la organización. En general se distinguen tres tipos de influencias: - Una organización que haya invertido recientemente en activos tales como determinadas arquitecturas o productos basados en ellas, estimará que un nuevo proyecto software deberá aprovechar esta circunstancia y reutilizar al máximo dichas arquitecturas y/o productos relacionados. - Una organización puede desear realizar una inversión a largo plazo en una determinada infraestructura con el fin de alcanzar unos objetivos estratégicos. En este caso un nuevo sistema software se verá como una oportunidad para financiar y extender dicha infraestructura. - Muchas veces la propia estructura de la organización puede dar forma a la arquitectura software. Las arquitecturas claramente son influenciadas por la experiencia y la formación de los arquitectos. Si un arquitecto ha tenido buenos resultados utilizando un determinado enfoque arquitectónico es muy probable que en el próximo proyecto utilice la misma aproximación. De la misma forma, si sus experiencias previas con un determinado enfoque han sido malas, el arquitecto se mostrará reacio a probar otra vez con dicho enfoque. Por lo tanto muchas veces las decisiones arquitectónicas están fuertemente condicionadas por la educación y la formación del arquitecto, el contacto satisfactorio con patrones arquitectónicos o con sistemas que han funcionado particularmente bien o mal. En algunos casos los arquitectos también desearán experimentar determinadas técnicas o nuevos patrones de diseño que han estudiado en algún libro o curso reciente. Un caso especial es el entorno técnico en el momento del diseño de una arquitectura. Este entorno técnico normalmente incluye las prácticas estándar de la industria, o las técnicas de ingeniería del software más frecuentes en las comunidades profesionales. En general, la mayoría de los arquitectos software estará fuertemente condicionado por este entorno técnico. Podemos concluir, por tanto, que los arquitectos son influenciados por los requisitos del sistema de acuerdo con la visión de los stakeholders, por la estructura y objetivos de la propia organización, por el entorno técnico disponible y por sus propios conocimientos y experiencia. Ahora bien, las arquitecturas también afectan a aquellos factores que las han influenciado. Las relaciones entre los objetivos de negocio, los requisitos del sistema, la experiencia del arquitecto y las arquitecturas forman un círculo que se realimenta continuamente y que debe ser gestionado con el propósito de manejar el crecimiento de la organización y aprovechar las inversiones previas en arquitecturas y en la construcción de sistemas. 9
El Ciclo de las Arquitecturas de Negocio funciona de la siguiente forma: 1. La arquitectura afecta a la estructura de la organización. Las arquitecturas prescriben unidades de software que deben ser desarrolladas u obtenidas para integrarse y formar un sistema. Estas unidades son la base para el desarrollo de la estructura de un proyecto. Los equipos de trabajo se forman para desarrollar estas unidades de software y las actividades de desarrollo, prueba e integración giran en torno a ellas. De la misma forma, los presupuestos y calendarios de trabajo distribuyen los recursos de acuerdo con partes de dichas unidades. Los equipos de trabajo tienden, por tanto, a arraigarse en la estructura de la organización 2. La arquitectura puede afectar a los objetivos de la organización. Por ejemplo, si una compañía desarrolla con éxito un producto, la arquitectura subyacente puede proporcionar oportunidades para producir de forma eficiente productos similares, de forma que la organización puede ajustar sus objetivos para aprovechar esta situación. 3. La arquitectura también puede influir en los requisitos del cliente para el siguiente sistema, ofreciéndole la oportunidad de recibir un sistema basado en la misma arquitectura y que, por tanto, será más fiable, más económico y más rápido de desarrollar que si fuese desarrollado desde cero. En muchos casos el cliente se mostrará predispuesto a relajar ciertos requisitos con tal de beneficiarse de estas economías. 4. Los sistemas construidos afectarán la experiencia de los arquitectos. Los sistemas desarrollados satisfactoriamente mediante una determinada herramienta o tecnología podrán dar lugar al desarrollo de nuevos sistemas similares en el futuro. De la misma forma, arquitecturas que han fracasado en un proyecto serán probablemente rechazadas en futuros proyectos. 5. En algunos casos determinados sistemas influenciarán y de hecho cambiarán la cultura de la ingeniería del software, esto es, el entorno técnico en el cual los sistemas serán construidos. La arquitectura software es, por tanto, mucho más que el resultado de los requisitos funcionales de un sistema. Es también el resultado de los conocimientos y experiencia del arquitecto, de su entorno técnico y de los objetivos de negocio de la organización. La arquitectura influencia a su vez el entorno que la rodea proporcionando nuevas experiencias técnicas y oportunidades de negocio. 10
3. Comprendiendo la Arquitectura Software Len Bass [Bass 2003] define la arquitectura software de un sistema informático como la estructura del sistema incluyendo los elementos software, las propiedades de dichos elementos que son visibles externamente y las relaciones entre ellos. De la definición anterior se obtienen algunas consideraciones importantes. La primera se refiere al hecho de que la arquitectura define elementos de software, incorpora información acerca de cómo estos elementos se relacionan entre sí y omite expresamente información que no se refiere a dicha interacción. Por lo tanto una arquitectura es, en primer lugar, una abstracción del sistema que aísla detalles de sus elementos que no afectan a la forma en que son utilizados, se relacionan o interaccionan entre sí. La arquitectura se preocupa por el lado público de los elementos, los detalles privados que sólo se refieren a la implementación interna del sistema no forman parte de la arquitectura. En segundo lugar, la definición de arquitectura software implica que todo sistema informático posee una arquitectura software, dado que todo sistema puede ser visto como un conjunto de elementos y las relaciones entre ellos. En tercer lugar nos encontramos con que el comportamiento de cada elemento es parte de la arquitectura en la medida en que dicho comportamiento puede ser observado desde el punto de vista de otro elemento. Este comportamiento es lo que permite a los elementos interaccionar entre sí, lo cual forma parte claramente de la arquitectura. Por último, otra importante conclusión de la definición es que ésta no está vinculada al hecho de que la arquitectura de un sistema sea buena o mala (en el sentido de que permita al sistema alcanzar sus requisitos funcionales o de rendimiento). Otras definiciones importantes son las de patrones arquitectónicos, modelos de referencia y arquitecturas de referencia. Un patrón arquitectónico es la descripción de los elementos y sus tipos de relaciones junto con las restricciones relativas a cómo pueden ser usados. Un patrón puede considerarse como un conjunto de restricciones sobre una arquitectura, de forma que el conjunto de restricciones establece una familia de arquitecturas que satisfacen dichas restricciones. Una de los aspectos más importantes de los patrones arquitectónicos es que tienen asociados conocidos atributos de calidad. Mientras que unos patrones representan soluciones conocidas a problemas de rendimiento, otros aseguran una alta disponibilidad o grandes niveles de seguridad. Un modelo de referencia describe una división en la funcionalidad junto con el flujo de datos entre los elementos. Se trata de una descomposición estándar de un problema conocido en una serie de partes que cooperativamente solucionan el problema. Por su lado una arquitectura de referencia es un modelo de referencia que está vinculado a elementos software, que cooperativamente implementan la funcionalidad definida en el modelo de referencia, y al flujo de datos entre dichos elementos. Mientras que un modelo de referencia divide la funcionalidad, la arquitectura de referencia vincula dicha funcionalidad con la descomposición del sistema en elementos que cooperativamente ofrecen la misma funcionalidad. 11
En la figura 2 se muestran las relaciones entre los distintos conceptos que acabamos de presentar. Las flechas indican que los conceptos subsiguientes contienen elementos de diseño adicionales. Modelo de Referencia Arquitectura de Referencia Arquitectura Software Patrón Arquitectónico Figura 2. Relaciones entre los conceptos Modelo de Referencia, Patrón Arquitectónico, Arquitectura de Referencia y Arquitectura Software. Para comprender el significado de la arquitectura software resulta de gran valor comprender las razones por las cuales resulta tan importante. Podemos considerar que existen tres razones fundamentales en la importancia de la arquitectura del software. La primera se refiere a la comunicación entre los stakeholders. La arquitectura representa una abstracción del sistema que puede ser utilizada como base para la negociación, consenso, comunicación y el entendimiento mutuo. En segundo lugar las arquitecturas facilitan la posibilidad de tomar decisiones lo antes posible; de hecho las arquitecturas establecen las primeras decisiones relativas al diseño de los sistemas. Por último, las arquitecturas software constituyen un modelo abstracto del sistema que permite comprender cómo está estructurado el sistema y cómo sus elementos trabajan juntos. Estos modelos pueden además ser transferidos entre sistemas, de forma que pueden ser aplicados a otros sistemas que presenten requisitos funcionales y atributos de calidad similares. La arquitectura software representa el primer conjunto de decisiones de diseño que se realiza de un sistema. Estas decisiones, las más tempranas en realizarse, son trascendentales siendo las más difíciles de realizar y las que entrañan mayor carga de trabajo si resulta necesario cambiarlas durante el posterior proceso de desarrollo. La arquitectura también define restricciones en la implementación de los sistemas. De hecho una implementación se dice que exhibe una arquitectura si es conforme con las decisiones de diseño estructural descritas en dicha arquitectura. Esto significa que toda implementación debe ser dividida en elementos que deben interaccionar entre sí de acuerdo con la forma preestablecida y cada elemento debe cumplir con todas sus responsabilidades tal y como establece la arquitectura. La arquitectura no sólo prescribe la estructura de los sistemas, también tiene una gran influencia en la estructura de los proyectos de desarrollo e incluso en la estructura de la propia organización. Dado que la arquitectura de un sistema incluye la descomposición de más alto nivel del sistema, ésta es típicamente utilizada como base para realizar la estructura de descomposición de trabajos (WBS Work Breakdown Structure), la cual establece las unidades de planificación, programación y presupuesto, canales de comunicación, control de configuración, procedimientos y planes de prueba, etc. La arquitectura permite o impide alcanzar los atributos de calidad de un sistema. El hecho de que un sistema sea capaz de exhibir los atributos de calidad deseados o 12
requeridos está substancialmente condicionado por su arquitectura. Las estrategias para alcanzar los atributos de calidad son fundamentalmente de carácter arquitectónico, aunque las arquitecturas por sí solas son incapaces de garantizar la calidad o la funcionalidad deseada. Lógicamente las decisiones a lo largo de todo el ciclo de vida de un sistema afectan a la calidad final, pero si queremos asegurar la calidad una buena arquitectura será necesaria. La arquitectura también permite realizar estimaciones más precisas del presupuesto y la planificación de los proyectos. Las estimaciones basadas en el entendimiento de las piezas del sistema son siempre más precisas que aquellas que están basadas en el conocimiento del sistema completo. Cada equipo podrá realizar estimaciones más precisas sobre las piezas individuales de las que está encargado, que el propio jefe de proyecto. Además los equipos podrán responsabilizarse mejor de hacer realidad dichas estimaciones. Por otro lado la definición inicial de una arquitectura supone que los requisitos de un sistema han sido revisados y de alguna manera validados. En lo que se refiere a la arquitectura como modelo reutilizable, cabe decir que cuanto antes se aplique la reutilización en el ciclo de vida de un sistema, mayor será el beneficio que podrá ser obtenido. Es por esta razón que aun cuando la reutilización de código es muy beneficiosa, la reutilización a nivel arquitectónico proporciona unas enormes ventajas estratégicas. La cuestión es que no solo el código puede ser reutilizado, también es posible reutilizar los requisitos de una arquitectura de gran éxito. Cuando las decisiones arquitectónicas pueden ser reutilizadas sobre múltiples sistemas diferentes, también son transferidas todas las ventajas relativas a las tempranas decisiones de diseño. Estructuras y Vistas de la Arquitectura Los sistemas informáticos son cada vez más y más complejos, lo que hace que su comprensión resulte difícil. En general resulta más adecuado restringir nuestra atención a un pequeño número de estructuras de forma simultánea, ya que de esta forma nos resultará más sencillo captar tanto la idea global como los detalles subyacentes. De la misma forma, para comunicarnos de forma más eficiente acerca de la arquitectura de un sistema, resulta necesario tener claro de que estructura o estructuras arquitectónicas estamos hablando en cada momento. Es por esta razón que introducimos los conceptos de estructuras y vistas arquitectónicas. Una vista es una representación de un conjunto coherente de elementos arquitectónicos y de las relaciones entre ellos. Una estructura arquitectónica es el conjunto de elementos arquitectónicos tal y como existen en el software y/o hardware. Las estructuras arquitectónicas suelen dividirse en tres grandes grupos dependiendo de la naturaleza de los elementos que muestran: Estructuras modulares. Los elementos que representan son módulos, considerados como unidades de implementación del sistema. Los módulos son áreas asignadas de responsabilidad funcional. Estructuras de componentes y conectores. En este caso los elementos son los componentes en tiempo de ejecución y los conectores (vehículos de comunicación entre los componentes). Estructuras de asignación. Este tipo de estructuras tratan de mostrar las relaciones entre los elementos software y los elementos en uno o más entornos externos en los cuales el software es creado y ejecutado. Estos tres tipos de estructuras arquitectónicas se corresponden con los tres grandes tipos de decisiones involucrados en el diseño arquitectónico: 13
Cómo se estructura el sistema en términos de unidades de código (módulos). Cómo se estructura el sistema en términos de elementos que tienen un comportamiento en tiempo de ejecución (componentes) e interaccionan entre sí (conectores). Cómo está relacionado el sistema con otras estructuras no software dentro de su entorno. Las estructuras basadas en módulos incluyen los siguientes tipos: Descomposición. Esta estructura muestra la descomposición de grandes módulos en otros sub-módulos más pequeños, que pueden ser comprendidos más fácilmente. Los módulos representan un punto de partida en el diseño y de forma recursiva el arquitecto va detallando las responsabilidades de las distintas unidades de código y asignándolas a los módulos para el subsiguiente diseño detallado y su eventual implementación. Esta estructura suelen utilizarse como la base para la organización del desarrollo del proyecto. Usos. Las unidades de esta estructura pueden ser módulos, procedimientos o recursos en las interfaces de los módulos. Las unidades están relacionadas entre sí por relaciones de uso. Una unidad se dice que usa otra unidad si para la corrección de la primera es necesaria una versión correcta de la segunda. La habilidad para descomponer fácilmente un sistema que funciona, permite el desarrollo incremental. Capas. Las capas son conjuntos coherentes de funcionalidad relacionada. Las capas normalmente se diseñan como abstracciones que ocultan la implementación específica a las capas inferiores. En una estructura de capas estricta, la capa n sólo puede utilizar los servicios de la capa n 1. Clases o generalizaciones. Este tipo de vistas soporta razonamientos sobre colecciones de elementos que tienen comportamientos similares, de forma que es posible parametrizar las diferencias a través de sub-clases. Las estructuras de clases permiten razonar en términos de re-utilización y adición incremental de funcionalidad. Las estructuras de componentes y conectores incluyen los siguientes tipos: Procesos de comunicación. Esta estructura trata los aspectos dinámicos de un sistema en tiempo de ejecución. Las unidades que se representan son procesos o hilos de ejecución que están conectados entre sí por operaciones de comunicación, sincronización y/o exclusión. Se trata de un tipo de estructura que facilita la comprensión del rendimiento y disponibilidad de los sistemas en ejecución. Concurrencia. Este tipo de estructura permite al arquitecto determinar oportunidades para el paralelismo, así como localizar puntos en los que puedan producirse problemas de congestión. Las unidades que se representan son componentes y los conectores son hilos de ejecución lógicos. Datos compartidos o repositorios. Representan componentes y conectores que crean, almacenan y acceden datos persistentes. Estas estructuras muestran cómo los datos son producidos y consumidos por los elementos software en tiempo de ejecución. Pueden utilizarse para mejorar el rendimiento y la integridad de los datos. Cliente-Servidor. Los componentes son los clientes y los servidores, mientras que los conectores son los protocolos y los mensajes que comparten para llevar a cabo el trabajo del sistema. Se trata de estructuras útiles para separar responsabilidades, para la distribución física y para el balanceo de carga. 14
Las estructuras de asignación incluyen los siguientes tipos: Despliegue. Estas estructuras muestran cómo se asigna el software a los procesos hardware y a los elementos de comunicación. Los elementos representados son procesos software, entidades hardware (procesadores) y canales de comunicación. Las relaciones muestran las asignaciones de los elementos software a unidades físicas en las que residen. Se trata de estructuras especialmente interesantes en sistemas distribuidos, que permiten razonar aspectos como el rendimiento, la integridad de datos, la disponibilidad y la seguridad. Implementación. Muestran cómo los elementos software se transforman en la estructura de ficheros durante el desarrollo del sistema, su integración y en el control de la configuración. Se trata de estructuras útiles en la gestión de las actividades de desarrollo y en la construcción de procesos. Asignación de trabajo. Esta estructura asigna las responsabilidades para implementar e integrar los módulos a los equipos de desarrollo apropiados. Aunque normalmente pensamos en la estructura de un sistema en términos de su funcionalidad, existen otras propiedades del sistema, tales como la distribución física, los procesos de comunicación y sincronización, que deben ser considerados a nivel arquitectónico. Es, en este sentido, que cada tipo de estructura proporciona un método para razonar sobre unos atributos de calidad u otros. Cada estructura proporciona una perspectiva diferente del diseño de un sistema, pero no son independientes entre sí, sino que los elementos de una estructura están relacionados con los elementos de otras estructuras. Kruchten propuso un modelo arquitectónico de vistas, denominado 4+1, con objeto de asegurar que las diferentes estructuras de un sistema no entran en conflicto unas con otras y que en su conjunto describen el sistema correctamente, cumpliendo con sus requisitos. Actualmente esta aproximación se ha popularizado y se ha institucionalizado como una de las bases conceptuales del Proceso Unificado de desarrollo de software. Kruchten propuso las siguientes cuatro vistas para describir la arquitectura de un sistema software: 1. Vista lógica. Su preocupación es la funcionalidad que el sistema proporciona a los usuarios finales. Los diagramas UML utilizados para su representación son: diagramas de clases, de secuencia y de comunicación. Se trata de la estructura de módulos. 2. Vista de desarrollo. Esta vista muestra el sistema desde el punto de vista del programador, muestra la organización de los módulos software, las librerías, subsistemas y unidades de desarrollo. Se centra en la gestión del software. Utiliza los diagramas de componentes y de paquetes. Se trata de una estructura de asignación 3. Vista de procesos. Esta vista se ocupa de los aspectos dinámicos del sistema, explica los procesos del sistema y cómo se comunican entre sí. Utiliza los diagramas de actividades para representar problemas de concurrencia, distribución de la funcionalidad, rendimiento o escalabilidad. Se trata de las estructuras de componentes y conectores. 4. Vista física. Describe el sistema desde el punto de vista del ingeniero de sistemas. Está centrada en la topología de los componentes software en la capa software y en la comunicación entre ellos. También se conoce como vista de despliegue, y se trata de una estructura de asignación. Utiliza diagramas de despliegue para su representación. 15
Vista Lógica Vista de Desarrollo Escenarios Vista de Procesos Vista Física Figura 3 Modelo Arquitectónico de 4+1 Vistas de Philippe Kruchten La descripción de la arquitectura se ilustra mediante un pequeño conjunto de casos de uso o escenarios que forman la quinta vista del modelo. Los escenarios describen secuencias de interacciones entre objetos y entre procesos. Se utilizan para identificar elementos arquitectónicos y para ilustrar y validar el diseño de la arquitectura. Para representar esta vista se utilizan los diagramas de casos de uso. En la figura 3 se muestra el Modelo de 4+1 Vistas, y se pueden observar además las interdependencias entre las vistas. Por ejemplo la dependencia de la vista lógica y la vista de desarrollo muestra como el modelo lógico (una clase) se puede implementar en un módulo, paquete, etc. La dependencia entre la vista lógica y la vista de procesos identifica características como quien invoca a quien (autonomía) o desde donde son accesibles las operaciones (persistencia, distribución). 16
Comprendiendo los Atributos de Calidad del Software 4.1 Funcionalidad y Arquitectura Como hemos visto en los apartados anteriores, los objetivos de negocio de una organización determinan los atributos de calidad necesarios en un sistema y que deben ser alcanzados a través de las arquitecturas software. Estos atributos de calidad son adicionales a la propia funcionalidad del sistema, y aunque están íntimamente relacionados, a menudo son los requisitos de funcionalidad los que guían los procesos de desarrollo de software. Como resultado de ello muchas veces los sistemas deben ser rediseñados no porque su funcionalidad sea deficiente, sino por las dificultades en su mantenimiento o en su portabilidad, o por problemas de rendimiento o de seguridad. Los atributos de calidad y la funcionalidad suelen considerarse conceptos ortogonales, en el sentido de que es posible elegir de forma independiente el nivel deseado para cada uno de ellos. La funcionalidad es, en buena parte, independiente de la estructura. De hecho, en general, la funcionalidad puede ser obtenida mediante la utilización de múltiples estructuras diferentes (si la funcionalidad fuese el único requisito entonces el sistema podría existir como un único módulo monolítico sin ninguna estructura interna). La arquitectura software lo que hace es establecer restricciones sobre la estructura del sistema cuando resulta necesario alcanzar determinados atributos de calidad. Objetivos de Negocio / Misión de la organización Atributos de Calidad S I S T E M A Determina el nivel de calidad Dirige / Guía Arquitectura Software Dirige / Guía Calidad del Software Capacidades del Sistema Figura 4 Relación entre las arquitecturas software, los atributos de calidad, los objetivos del negocio y la funcionalidad del sistema Los atributos de calidad más comunes son: rendimiento, disponibilidad, seguridad, usabilidad, modificabilidad, y testeabilidad o capacidad de prueba. Pero podríamos citar otros atributos como, por ejemplo, la fiabilidad, la portabilidad o la interoperabilidad. Más adelante definiremos y profundizaremos en los principales atributos de calidad. Vamos a ver como para obtener los mejores resultados a la hora de diseñar un sistema software, es necesario que todo el equipo de desarrollo, junto con el resto de la organización, comprenda y esté de acuerdo con los atributos de calidad del sistema a desarrollar. También veremos que para poder obtener los atributos de calidad de un sistema deberemos tener en cuenta todas las fases del ciclo de vida. Ningún atributo de calidad depende exclusivamente del diseño, de la implementación o del despliegue. 17
Los resultados satisfactorios solamente se alcanzan cuando consideramos tanto la arquitectura del sistema como los detalles de su implementación. La arquitectura es crítica en la obtención de muchos atributos de calidad de un sistema, de modo que es necesario diseñar y evaluar estos atributos de calidad durante la fase de definición de la arquitectura del sistema. Pero, en cualquier caso, no debemos olvidar que la arquitectura por si sola es incapaz de lograr alcanzar los atributos de calidad. La arquitectura establece las bases pero es necesario que durante el diseño, la implementación y el despliegue del sistema se preste gran atención a todos los detalles. Como ejemplo práctico podemos analizar qué es lo que ocurre con el rendimiento de un sistema. El rendimiento tiene claramente dependencias tanto arquitectónicas como no arquitectónicas: depende del grado de comunicación necesaria entre los componentes del sistema (arquitectónica), de cómo la funcionalidad ha sido distribuida entre los componentes (arquitectónica), de cómo los recursos compartidos se han asignado (arquitectónico), de la selección de algoritmos que implementan la funcionalidad (no arquitectónico) o de cómo se han codificado dichos algoritmos (no arquitectónico). En todo proceso de desarrollo software resulta imprescindible identificar los atributos de calidad del sistema, determinar qué es requerido y qué es deseable para cada uno de ellos. Una vez definidos los atributos de calidad del sistema, el siguiente paso es determinar en qué medida la aplicación que se está desarrollando puede alcanzar las expectativas establecidas. Si no resulta posible alcanzar los atributos de calidad de acuerdo con lo establecido, entonces será necesario cambiar la arquitectura, de forma que se consiga satisfacer todos los requisitos de los atributos de calidad. A continuación tendremos que revisar los requisitos funcionales y verificar si han sufrido modificaciones y, en su caso, reajustar la aplicación. 4.2 Los Escenarios de Atributos de Calidad El siguiente problema que se plantea al tratar de establecer los atributos de calidad de un sistema es que, en general, la definición de un atributo de calidad no es operativa y además los atributos de calidad tienden a solaparse unos con otros. Incluso a menudo tienen efectos en cadena: el éxito de uno de ellos suele tener efectos, a veces positivos otras veces negativos, en el logro de otros atributos de calidad. Como solución a estos problemas se considera la utilización de los escenarios como medio para caracterizar los atributos de calidad. Los escenarios constan de seis partes (ver figura 5): Origen del estímulo: es la entidad que genera el estímulo. Puede ser una persona, un sistema informático,... Estímulo: es el evento que está actuando sobre el sistema. Entorno: las condiciones concretas en las cuales el estímulo se ha producido. Artefacto: el sistema completo o las partes del sistema que son estimuladas. Respuesta: se trata de la actividad realizada como consecuencia del estímulo. Medida de la respuesta: toda vez que ocurre una respuesta, ésta debe ser medida con objeto de evaluar si el requisito ha sido alcanzado. 18
Figura 5 Partes de los Escenarios de Atributos de Calidad Cuando hablamos de escenarios de atributos de calidad se distingue entre escenarios generales: aquellos que son independientes de un sistema y que potencialmente pueden pertenecer a cualquier sistema, y los escenarios concretos: aquellos que son específicos de un sistema en particular. En concreto podemos decir que la caracterización de los atributos de calidad es una colección de escenarios generales, pero si queremos traducir estos atributos a requisitos concretos para un determinado sistema, los escenarios generales tienen que ser convertidos a escenarios concretos. Será esta colección de escenarios concretos la que podrá ser usada para representar los requisitos de calidad de un sistema, dado que cada escenario concreto aporta la información suficiente que necesita el arquitecto y los detalles de la respuesta permiten evaluar si el sistema final alcanza los requisitos de calidad establecidos. 4.3 Los principales Atributos de Calidad en detalle A continuación vamos a analizar con más detalle los seis atributos de calidad que se pueden considerar como más comunes e importantes. El propósito es identificar los conceptos que subyacen y además proporcionar una vía para generar escenarios generales para cada uno de ellos. Disponibilidad. La disponibilidad de un sistema se refiere a la posibilidad de que se produzcan fallos en el funcionamiento de un sistema y a las consecuencias que se puedan derivar. Lo primero que es necesario indicar es que el fallo de un sistema se produce cuando el sistema no es capaz de ofrecer el servicio que se espera de acuerdo con su especificación. Estos fallos pueden ser observados tanto por otros sistemas como por personas. Las principales inquietudes son: cómo detectar los fallos, con qué frecuencia ocurren, qué ocurre cuando se produce un fallo, cuánto tiempo puede estar un sistema fuera de servicio como consecuencia de un fallo, cómo pueden prevenirse los fallos de un sistema y cuáles serían las notificaciones requeridas cuando se produce un fallo. Una vez que se ha producido el fallo de un sistema, un concepto muy importante es el del tiempo necesario para su reparación. Desde que el fallo de un sistema es observable por otros usuarios, el tiempo de reparación es el tiempo transcurrido hasta que el fallo deja de ser observable. La disponibilidad ( de un sistema suele definirse como la probabilidad de que un sistema esté operativo cuando es necesario: 19