Architecture Level Modifiability Analysis (ALMA)
El atributo de calidad que analiza ALMA, es la facilidad de modificación. Esto se refiere a la capacidad de un sistema para ser ajustado debido a cambios en requerimientos, o en el entorno, así como la adición de nueva funcionalidad. ALMA es el resultado de los trabajos de investigación realizados por Bengtsson y Lassing [1].
ALMA es un método de evaluación orientado a metas. Existen tres para las que se puede usar:
•Predicción del costo de mantenimiento. Consiste en estimar el esfuerzo requerido para modificar la arquitectura a cambios requeridos en un futuro.
•Evaluación de riesgos. Identifica los tipos de cambios que pueden ser complejos o que sean inflexibles en la arquitectura de software.
•Selección de un conjunto de arquitecturas. Compara dos o más arquitecturas propuestas y selecciona aquella que proporcione mayor soporte a cambios.
ALMA puede utilizarse una vez que concluye la especificación de la arquitectura (evaluación clásica), o aun cuando la arquitectura ya ha sido implementada (evaluación tardía). Este método se apoya en el uso de escenarios de cambio, los cuales describen eventos posibles que provocarían cambios al sistema, y cómo se llevarían acabo éstos.
Este método se realiza a través de los siguientes pasos:
1. Definir la meta de evaluación. Dependiendo del objetivo de la evaluación, se selecciona alguna de las tres metas.
2. Describir la arquitectura de software. Se colecta la información más relevante de la arquitectura: sus principales componentes, las relaciones entre éstos, así como las relaciones con el entorno del sistema.
3. Obtener escenarios. Se definen los escenarios de cambio y se agrupan en categorías. Se eligen aquellos escenarios relacionados con el propósito de evaluación. Por ejemplo: si la meta es estimar el esfuerzo de mantenimiento, se recomienda seleccionar aquellos escenarios que corresponden a los cambios que tienen una alta probabilidad de que ocurran durante la vida operacional del sistema.
4. Evaluar escenarios. Se realiza un análisis de impacto, que consiste en identificar los componentes afectados por los escenarios previamente definidos, determinar el efecto del cambio sobre los componentes, así como determinar los efectos del cambio en otros componentes. Los resultados de este análisis se deben expresar ya sea de manera cuantitativa o cualitativa.
5. Interpretar resultados. Finalmente se interpretan los resultados, así como las conclusiones del análisis dependiendo de la meta de evaluación seleccionada.
Figura 1. Método ALMA
Performance Assessment of Software Architecture (PASA)
El atributo de calidad que analiza PASA, es el desempeño. Que se interesa por conocer, qué tanto tiempo le toma al sistema de software responder cuando uno o varios eventos ocurren, así como determinar el número de eventos procesados en un intervalo de tiempo dado. PASA es el trabajo resultante de Williams y Smith [2], y utiliza diversas técnicas para la evaluación, tales como la aplicación de estilos arquitectónicos, anti-patrones, guías de diseño y modelos.
Al igual que ALMA, PASA se basa en escenarios. Asimismo, puede aplicarse una vez que la arquitectura se ha especificado, o posteriormente, cuando ya ha sido implementada. Los escenarios generados en este método proveen una medida de razonamiento con respecto al desempeño del sistema. Si se requieren análisis más detallados, los escenarios sirven como punto de partida para construir modelos de desempeño.
Para utilizar este método, la arquitectura de software debe estar previamente documentada. En caso de que se encuentre parcialmente documentada, es necesario extraer la información faltante de los miembros del equipo, así como de códigos fuente.
Los pasos para llevar acabo este método son:
1. Presentar el método de evaluación. Se comunica al equipo y directivos el objetivo de la evaluación, y se explica el método PASA.
2. Presentar la arquitectura. El equipo de desarrollo presenta la arquitectura actual de una manera general y sin entrar en detalles.
3. Identificar casos de uso críticos. Se seleccionan los casos de uso que son importantes para la operación del sistema, así como aquellos que demandan una respuesta de tiempo rápida para el usuario, u otros que presentan algún riesgo de desempeño. Recordemos que un caso de uso puede contener varios escenarios, que describen las diferentes formas en que se puede realizar el caso de uso. Los escenarios se especifican en UML como diagramas de secuencia.
4. Seleccionar los escenarios de desempeño principales. Por cada caso de uso crítico, se debe identificar los escenarios significativos con respecto al desempeño.
5. Identificar objetivos de desempeño. Por cada escenario de desempeño principal, se debe especificar al menos un objetivo de desempeño. Mismos que pueden ser expresados de distintas maneras. Por ejemplo: expresarlos en tiempo de respuesta, capacidad de respuesta, restricciones o utilización de recursos. Para poder medirlo, el objetivo de desempeño debe ser cuantitativo.
6. Clarificar la arquitectura y discutirla. En este paso se estudia más a detalle la arquitectura, por lo que se tienen reuniones con el arquitecto y equipo de desarrollo para aclarar dudas. Si existe información acerca del desempeño del sistema, se colectan métricas.
7. Analizar la arquitectura. En este paso se utilizan diferentes técnicas para analizar el desempeño de la arquitectura. Por ejemplo:se identifican estilos arquitectónicos, con la finalidad de detectar efectos negativos en el desempeño, se identifican anti-patrones de desempeño que documentan problemas comunes. Se elaboran modelos de desempeño con el objetivo de identificar problemas en la arquitectura.
8. Identificar alternativas. Si se encontraron problemas de desempeño, se identifican alternativas de solución. Estas pueden incluir el cambio de estilo arquitectónico, modificar la arquitectura para eliminar anti-patrones de desempeño, o alternativas para optimizar la interacción entre componentes.
9. Presentar resultados. Finalmente se elabora un documento con los resultados de la evaluación que incluye los objetivos de la evaluación, hallazgos encontrados, pasos específicos a seguir y recomendaciones.
Figura 2. Método PASA
Las personas involucradas durante la evaluación son: el arquitecto, el equipo de desarrollo y en algunos momentos, el gerente(s) de proyecto. Si se realiza de forma intensiva, la evaluación completa se puede llevar acabo en una semana. PASA se considera un método de evaluación maduro, ya que ha sido probado en varios dominios de aplicación como sistemas web, aplicaciones financieras y sistemas en tiempo real.
Scenario based Architecture Level UsabiliTy Analysis (SALUTA)
SALUTA es el primer método desarrollado para evaluar la arquitectura desde la perspectiva de la facilidad de uso del sistema. SALUTA es el resultado de los trabajos de investigación hechos por Folmer y Gurp [3].
Este método hace uso de un marco de referencia elaborado por los mismos autores en el que se expresan las relaciones que existen entre la facilidad de uso y la arquitectura de software [4]. Este marco de referencia incluye un conjunto integrado de soluciones de diseño tales como patrones de diseño y propiedades que tienen un efecto positivo sobre la facilidad de uso en un sistema de software. SALUTA analiza cuatro atributos que están directamente relacionados con la facilidad de uso en un sistema de software, estos son: facilidad de aprendizaje, eficiencia de uso, confiabilidad y satisfacción. Se recomienda efectuar la evaluación una vez que la especificación de la arquitectura ha finalizado, pero antes de que se implemente.
Este método se basa en escenarios de uso, los cuales se agrupan en uno o más perfiles de uso. Cada uno representa la facilidad de uso requerida por el sistema de software.
SALUTA está compuesto por los siguientes pasos, que se ilustran en la figura 3.
1. Crear perfiles de uso. Se identifican los usuarios y se organizan en categorías. Luego se identifican las tareas más significativas del sistema y el contexto donde será usado el sistema, se determinan los valores para los atributos: facilidad de aprendizaje, eficiencia de uso, confiabilidad y satisfacción. Para reflejar la diferencia en la prioridad de los atributos, se asigna a cada uno un valor numérico no repetido entre 1 y 4. Por último, se seleccionan los escenarios más representativos que tienen mayor prioridad con respecto a sus atributos.
2. Describir la facilidad de uso proporcionada. Se colecta la información de la arquitectura de software para determinar el nivel de soporte en los escenarios de uso. Esto se realiza efectuando un análisis basado en patrones, o basado en propiedades. En ambos análisis se utiliza el marco de referencia para determinar la presencia de patrones o propiedades de facilidad de uso en la arquitectura a evaluar.
3. Evaluar escenarios. Se evalúa cada uno de los escenarios que forman parte del perfil de uso. Por cada escenario se analizan los patrones y propiedades previamente identificados. Se recomienda usar el marco de referencia para analizar cómo un patrón, o propiedad particular afecta a un atributo específico en un escenario de uso. Finalmente, se expresan de manera cuantitativa los resultados del análisis, que indican el grado de soporte de facilidad de uso en cada uno de los escenarios.
4. Interpretar resultados. En este paso se obtienen los resultados de la evaluación, que contienen el grado de facilidad de uso que soporta la arquitectura evaluada.
Figura 3. Método SALUTA
Las personas involucradas durante la evaluación son el arquitecto de software, ingenieros de requerimientos o ingenieros responsables por la facilidad de uso.
Survivable Network Analysis (SNA)
SNA [5] es un método desarrollado por el CERT (Computer Emergency Response Team) que forma parte del SEI. Este método ayuda a identificar la capacidad de supervivencia en un sistema, analizando su arquitectura. La supervivencia, es la capacidad que tiene un sistema para completar su misión a tiempo, ante la presencia de ataques, fallas o accidentes. Un ejemplo de la definición anterior es la siguiente: un cajero automático debe garantizar al usuario los servicios esenciales aun cuando éste se encuentre en presencia de algún ataque externo o falla interna.
SNA utiliza tres propiedades clave para evaluar la supervivencia en un sistema:
•Resistencia. Es la capacidad del sistema para repeler ataques, fallas o accidentes.
•Reconocimiento. Es la capacidad de detectar ataques, fallas o accidentes, y si estos ocurren, evaluar los daños.
•Recuperación. Es la capacidad de mantener en operación los servicios esenciales en presencia de ataques, fallas o accidentes.
Este método puede ser aplicado después de la especificación de una arquitectura, durante la implementación de ésta, o posteriormente.
SNA se basa en escenarios de uso, e identifica dos tipos de escenarios. El primer tipo son los escenarios normales, que se componen de una serie de pasos donde los usuarios invocan a servicios y obtienen acceso a activos, tales como bases de datos. El segundo tipo de escenarios son los de intrusión, en los que se representan diferentes tipos de ataques al sistema.
SNA está compuesto por los siguientes pasos:
1. Definición del sistema. En este paso se obtiene la misión del sistema, se discute el entorno de uso en términos de capacidades y ubicaciones de los usuarios, se analizan posibles riesgos que el sistema pueda presentar en condiciones adversas, finalmente se analiza la arquitectura de software.
2. Definición de las capacidades esenciales. A continuación se seleccionan los servicios esenciales y los activos que usan. Se deben seleccionar aquellos servicios y activos que sean críticos para garantizar en condiciones adversas, la misión del sistema. Una vez seleccionados, estos se trazan a través de la arquitectura, para identificar los componentes que participan en proporcionar los servicios esenciales.
3. Definición de las capacidades que comprometen al sistema. En este paso se selecciona un conjunto representativo de posibles ataques, basados en el entorno de operación del sistema. Se definen los escenarios de intrusión y se trazan a través de la arquitectura, para identificar componentes que comprometan la supervivencia del sistema, logrando así el acceso y daño a éste.
Figura 4. Método SNA
El resultado que se obtiene al final de la evaluación, es un documento que incluye modificaciones recomendadas a la arquitectura, acompañadas del mapa de supervivencia. Las personas involucradas durante la evaluación son: el arquitecto de software, el diseñador principal, los propietarios del sistema y usuarios del mismo.
Tabla 1. Cuadro comparativo entre los métodos de evaluación ALMA, PASA, SALUTA y SNA
Conclusiones
En esta segunda parte hemos presentado el método de evaluación ALMA, que se interesa por predecir la facilidad de modificación en una arquitectur. PASA, que analiza en la arquitectura el desempeño del sistema. SALUTA, que analizando una serie de atributos de calidad predice la facilidad de uso; y SNA, que analiza en la arquitectura, la supervivencia de un sistema ante la presencia de ataques, fallas o accidentes. La Tabla 1 presenta a manera de resumen, un cuadro comparativo entre estos cuatro métodos de evaluación.
Referencias
1. Bengtsson, PerOlof, Nico Lassing and Jan Bosch, Vliet, Hans van. “Architecture-Level Modifiability Analysis (Alma).” The Journal of Systems and Software 69 (2004): 129-147.
2. Williams, Lloyd G. and Connie U. Smith. “PASASM: A Method for the Performance Assessment of Software Architecture.” Paper presented at the Proceedings of the 3rd Workshop on Software Performance, Rome, Italy 2002.
3. Folmer, Eelke, Jilles van Gurp and Jan Bosch. “Scenario-Based Assessment of Software Architecture Usability.” Paper presented at the Proceedings of Workshop on Bridging the Gaps Between Software Engineering and Human-Computer Interaction, ICSE, Portland 2003.
4. Eelke Folmer, Jilles van Gurp and Jan Bosch. Investigating the Relationship Between Usability and Software Architecture, Software process improvement and practice: Wiley, 2003.
5. Mead, Nancy R., Robert J. Ellison, Richard C. Linger, Thomas Longstaff and John McHugh. “Survivable Network Analysis Method.” CMU/SEI, 2000.
Acerca del autor
Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas (CIMAT). Actualmente es profesor de la Universidad de Guadalajara, es miembro de la Association for Computing Machinery (ACM) y del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org
- Log in to post comments