8. EVALUACIN DE ARQUITECTURAS DE SOFTWARE Segn Kazman, el primer paso para la evaluacin de una arquitectura es conocer qu es lo que se quiere evaluar.

As ser posible establecer la base para la evaluacin, puesto que la intencin es saber qu se puede evaluar y qu no. Es interesante el estudio de la evaluacin de una arquitectura ya que las decisiones que se toman sobre la misma determinan los atributos de calidad del sistema, y es lo que hace posible evaluar las decisiones de la arquitectura con respecto al impacto sobre estos atributos. La arquitectura de software posee un gran impacto sobre la calidad de un sistema, por lo que es muy importante estar en capacidad de tomar decisiones acertadas sobre ella, en diversos tipos de situaciones, como: Comparacin de alternativas similares Comparacin de la arquitectura original y la modificada Comparacin de la arquitectura de software con respecto a los requerimientos del sistema Comparacin de una arquitectura de software con una propuesta terica Valoracin de una arquitectura en base a escalas especficas

Kazman asegura que la garanta de una arquitectura correcta cumple un papel fundamental en el xito general del proceso de desarrollo, adems del cumplimiento de los atributos de calidad del sistema. De esta manera, el inters se centra en determinar el momento propicio para efectuar la evaluacin de una arquitectura. El planteamiento de Kazman establece que es posible realizarla en cualquier momento, pero propone dos variantes que agrupan dos etapas distintas: temprano y tarde. En la variante temprano, Kazman especifica que no es necesario especificar la arquitectura completamente para efectuar la evaluacin, y esto abarca desde las fases tempranas de diseo y a lo largo del desarrollo. En lo que Bosch asegura que es posible tomar decisiones sobre la arquitectura a cualquier nivel. En lo que los dos concuerdan es que entre mayor es el nivel de especificacin, mejores son los resultados que produce. La segunda variante propuesta por Kazman consiste en realizar la evaluacin de la arquitectura cuando sta se encuentra establecida y la implementacin se ha completado. Bosch se enfoca ms en la evaluacin del potencial de la arquitectura diseada para alcanzar los atributos de calidad requeridos. Las mediciones que se realizan sobre una arquitectura de software pueden tener distintos objetivos, dependiendo de la situacin en la que se encuentre el arquitecto y la aplicabilidad de las tcnicas que emplea. Los objetivos que menciona Bosch son tres: cualitativos (entre arquitecturas candidatas), cuantitativos (permite establecer comparaciones) y mximos y mnimos tericos (valores mximos o mnimos de los atributos). Muchas veces estos objetivos no obtienen valores numricos, por lo que Kazman y sus colegas explican cules son los puntos de riesgos del diseo evaluado. Una de las diferencias principales entre los planteamientos de Bosch y Kazman es el enfoque que utilizan para efectos de la evaluacin. El mtodo de diseo de arquitecturas planteado por Bosch tiene como principal caracterstica la evaluacin explcita de los atributos de calidad de la arquitectura durante el proceso de diseo de la misma y Kazman proponen que resulta de poco inters la caracterizacin o medicin de atributos de calidad en las fases tempranas del proceso de diseo, dado que estos parmetros son, por lo general, dependientes de la implementacin. Y concuerdan tanto Bosch como Kazman la importancia de la especificacin exhaustiva de los atributos de calidad como base para efectos de la evaluacin de una arquitectura de software.

9. TCNICAS DE EVALUACIN DE ARQUITECTURAS DE SOFTWARE Debido al costo de realizar la evaluacin cuantitativa, en muchos casos los arquitectos de software evalan cualitativamente, para decidir entre las alternativas de diseo. Bosch propone diferentes tcnicas de evaluacin de arquitecturas de software, a saber: evaluacin basada en escenarios, evaluacin basada en simulacin, evaluacin basada en modelos matemticos y evaluacin basada en experiencia. 9.1. Evaluacin basada en escenarios Segn Kazman, un escenario es una breve descripcin de la interaccin de alguno de los involucrados en el desarrollo del sistema con ste y consta de tres partes: el estmulo, el contexto y la respuesta. El estmulo es la parte del escenario que explica o describe lo que el involucrado en el desarrollo hace para iniciar la interaccin con el sistema. El contexto describe qu sucede en el sistema al momento del estmulo. La respuesta describe, a travs de la arquitectura, cmo debera responder el sistema ante el estmulo. Este ltimo elemento es el que permite establecer cul es el atributo de calidad asociado. Kazman y Carriere coinciden en la importancia del uso de los escenarios, no slo para efectos de la evaluacin de arquitecturas de software. Entre las ventajas de su uso estn: Son simples de crear y entender Son poco costosos y no requieren mucho entrenamiento Son efectivos Actualmente las tcnicas basadas en escenarios cuentan con dos instrumentos de evaluacin relevantes, a saber: el Utility Tree propuesto por Kazman y los Profiles, propuestos por Bosch Utility Tree es un esquema en forma de rbol que presenta los atributos de calidad de un sistema de software, refinados hasta el establecimiento de escenarios que especifican con suficiente detalle el nivel de prioridad de cada uno. Un perfil (profile) es un conjunto de escenarios, generalmente con alguna importancia relativa asociada a cada uno de ellos. El uso de perfiles permite hacer especificaciones ms precisas del requerimiento para un atributo de calidad. Segn Bosch, la tcnica de evaluacin basada en escenarios es dependiente de manera directa del perfil definido para el atributo de calidad que va a ser evaluado. 9.2. Evaluacin basada en simulacin Bosch establece que la evaluacin basada en simulacin utiliza una implementacin de alto nivel de la arquitectura de software. El enfoque bsico consiste en la implementacin de componentes de la arquitectura y la implementacin, a cierto nivel de abstraccin, del contexto del sistema donde se supone va a ejecutarse. La finalidad es evaluar el comportamiento de la arquitectura bajo diversas circunstancias. El proceso de evaluacin basada en simulacin sigue los siguientes pasos: Definicin e implementacin del contexto. Consiste en identificar las interfaces de la arquitectura de software con su contexto. Implementacin de los componentes arquitectnicos. La descripcin del diseo arquitectnico debe definir, por lo menos, las interfaces y las conexiones de los componentes.

Implementacin del perfil. Dependiendo del atributo de calidad que el arquitecto de software intenta evaluar. Simulacin del sistema e inicio del perfil. El arquitecto de software ejecutar la simulacin y activar escenarios de forma manual o automtica. Prediccin de atributos de calidad. Dependiendo del tipo de simulacin y del atributo de calidad evaluado, se puede disponer de cantidades excesivas de datos, que requieren ser condensados.

En el mbito de las simulaciones, se encuentra la tcnica de implementacin de Prototipos. 9.3. Evaluacin basada en modelos matemticos Bosch establece que la evaluacin basada en modelos matemticos se utiliza para evaluar atributos de calidad operacionales. Usan los mismos atributos que el de simulacin, por lo cual es una alternativa o pueden trabajar en conjunto. El proceso de evaluacin basada en modelos matemticos sigue los siguientes pasos: Seleccin y adaptacin del modelo matemtico. Centros de investigacin orientados a atributos de calidad han desarrollado modelos matemticos para medir sus atributos de calidad. Representacin de la arquitectura en trminos del modelo. La arquitectura necesita ser representada en trminos del modelo. Estimacin de los datos de entrada requeridos. Es necesario estimar y deducir estos datos de la especificacin de requerimientos y de la arquitectura diseada. Prediccin de atributos de calidad. 9.4. Evaluacin basada en experiencia Bosch establece que en muchas ocasiones los arquitectos e ingenieros de software tienen valiosas ideas que resultan de utilidad para la evasin de decisiones o erradas de diseo. Aunque todas estas experiencias se basan en evidencia anecdtica; es decir, basada en factores subjetivos como la intuicin y la experiencia. Sin embargo, la mayora de ellas puede ser justificada por una lnea lgica de razonamiento, y pueden ser la base de otros enfoques de evaluacin. Existen dos tipos de evaluacin basada en experiencia: la evaluacin informal, que es realizada por los arquitectos de software durante el proceso de diseo, y la realizada por equipos externos de evaluacin de arquitecturas.

10. MTODOS DE EVALUACIN DE ARQUITECTURAS DE SOFTWARE

10.1. Software Architecture Analysis Method (SAAM) El Mtodo de Anlisis de Arquitecturas de Software (Software Architecture Analysis Method, SAAM) es el primero que fue ampliamente promulgado y documentado. Se enfoca en la enumeracin de un conjunto de escenarios que representan los cambios probables a los que estar sometido el sistema en el futuro. Como entrada principal, es necesaria alguna forma de descripcin de la arquitectura a ser evaluada. 10.2. Architecture Trade-off Analysis Method (ATAM) El Mtodo de Anlisis de Acuerdos de Arquitectura (Architecture Trade-off Analysis Method, ATAM) est inspirado en tres reas distintas: los estilos arquitectnicos, el anlisis de atributos de calidad y el mtodo de evaluacin SAAM, explicado anteriormente. El mtodo se concentra en la identificacin de los estilos arquitectnicos o enfoques arquitectnicos utilizados.

10.3. Active Reviews for Intermediate Designs (ARID) Es conveniente para realizar la evaluacin de diseos parciales en las etapas tempranas del desarrollo. Es utilizado para la evaluacin de diseos detallados de unidades del software como los componentes o mdulos. Las preguntas giran en torno a la calidad y completitud de la documentacin y la suficiencia, el ajuste y la conveniencia de los servicios que provee el diseo propuesto. 10.4. Modelo de Negociacin WinWin El modelo WinWin provee un marco de referencia general para identificar y resolver conflictos de requerimientos, mediante la elicitacin y negociacin de artefactos en funcin de las condiciones de ganancia. 10.5. Cost-Benefit Analysis Method (CBAM) Ayuda en la elicitacin y documentacin de los costos, beneficios e incertidumbre, y provee un proceso de toma de decisiones racional. 10.6. Mtodo Diseo y Uso de Arquitecturas de Software propuesto por Bosch Bosch plantea, en su mtodo de diseo de arquitecturas de software, que el proceso de evaluacin debe ser visto como una actividad iterativa, que forma parte del proceso de diseo, tambin iterativo. Una vez que la arquitectura es evaluada, pasa a una fase de transformacin, asumiendo que no satisface todos los requerimientos. Luego, la arquitectura transformada es evaluada de nuevo. 10.7. Mtodo de comparacin de arquitecturas basada en el modelo ISO/IEC 9126 adaptado para arquitecturas de software Mtodo para evaluar y comparar arquitecturas de software candidatas. 11. HERRAMIENTAS DE ANLISIS, DISEO Y EVALUACIN DE ARQUITECTURAS DE
SOFTWARE

Kazman plantea que una herramienta de anlisis y diseo de arquitecturas de software debe cumplir con ciertos requerimientos, entre los que se encuentran: describir cualquier arquitectura, aadir elementos arquitectnicos de forma recursiva, determinar la concordancia de interfaces entre componentes, capacidad para realizar ingeniera de reverso, analizar arquitecturas con respecto a mtricas, asistir al desarrollador en el diseo, debe soportar distintos mtodos de diseo, debe funcionar como un repositorio, proveer la generacin de plantillas de cdigo.