Architecture Trade-off Analysis Method (ATAM)

Architecture Trade-off Analysis Method (ATAM)

Architecture Trade-off Analysis Method (ATAM),el Método de Análisis de Acuerdos de Arquitectura, es un método de evaluación de arquitectura de software desarrollado e impulsado por el Instituto de Ingeniería de Software, (Software Engineering Institute, SEI), este centra su actividad de evaluación en la interacción entre los diferentes atributos de calidad arquitectónica y basa sus evaluaciones sobre los escenarios desarrollados por los involucrados y un equipo de evaluación.

Descripción del Método

El método se concentra en la identificación de los estilos arquitectónicos o enfoques arquitectónicos utilizados. Propone el término enfoque arquitectónico, dado que no todos los arquitectos están familiarizados con el lenguaje de estilos arquitectónicos, aún haciendo uso indirecto de estos. De cualquier forma, estos elementos representan los medios empleados por la arquitectura para alcanzar los atributos de calidad, así como también permiten describir la forma en la que el sistema puede crecer, responder a cambios, e integrarse con otros sistemas, entre otros.

La entrada a ATAM consiste en una arquitectura de sistema y las perspectivas de los actores involucrados con ese sistema. Está basado en la generación de escenarios para evaluar la arquitectura. En cuyo caso los casos de uso representan las condiciones operativas que la arquitectura debe apoyar, demostrando la eficacia de la arquitectura para satisfacer estas condiciones de funcionamiento. Después que un conjunto de escenarios se genera por las partes interesadas, la evaluación se llevará mediante la aplicación de los escenarios a la arquitectura y desarrollar una comprensión de los mecanismos arquitectónicos que se utilizan para lograr determinados objetivos de calidad y las implicaciones de esos mecanismos. Cada Atributo de calidad se examina desde el punto de vista de tres perspectivas: lo que los estímulos externos hacen, lo que la arquitectura responde o el cambio ocurrido, ¿qué mecanismos se utilizan dentro de la arquitectura para controlar la respuesta; y cómo es medida la respuesta a estos estímulos? Para obtener un mejor “rendimiento”, por ejemplo, los estímulos externos son eventos que llegan al sistema, los mecanismos son la programación, la concurrencia, y 3^ro gestión de los recursos y las mediciones de latencia o rendimiento.

Para “modificabilidad”, por ejemplo, los estímulos externos son los cambios en el sistema, los mecanismos para controlar el costo de los cambios son la encapsulación y la indirección de datos, y la medición es el costo de un conjunto de cambios.

Los casos representan el cambio esperado, modificaciones del sistema que pueden causar cambios en la arquitectura, y demostrar la eficiencia con que la arquitectura responde a estos cambios.

Productos de una evaluación

Hay tres tipos diferentes de productos en una evaluación:

1^ro "sensibilidad" o "trade-off", señala. Un punto de sensibilidad es una propiedad de la arquitectura que es fundamental para el logro de un atributo de calidad específico (por ejemplo, mediante el cifrado se logra la confidencialidad). Un punto de equilibrio es un punto de sensibilidad que es sensible a atributos de calidad múltiples (por ejemplo, el cifrado requiere de tiempo y afecta a latencia).

2^do marco para razonar sobre el sistema. El marco para el razonamiento acerca del sistema puede tener una variedad de formas. Puede ser la discusión que sigue de la la exploración de un escenario; puede ser un modelo o una parte de un modelo y una discusión de cómo este modelo podría ser analizado cuando se crea una instancia; o puede ser una fórmula que representa la forma de calcular un valor de un atributo de calidad en particular.

3^ro lista de cuestiones no abordadas o decisiones que no sean tomado en cuenta todavía. La lista de cuestiones no abordadas o las decisiones que aún no se han planteado desde la etapa inicial del ciclo de vida del sistema, hasta el momento de la evaluación. Una arquitectura representa una colección de decisiones. Algunas de estas decisiones se saben por el equipo de desarrollo que no se ha hecho y se registra en una lista para un nuevo examen. Otras son noticias para el equipo de desarrollo y las partes interesadas y la evaluación ayuda a identificar y documentar.

Resultados

• Presentación de la arquitectura.
• Articulación de los objetivos de negocio.
• Requerimientos de calidad (escenarios).
• Puntos de sensibilidad o de trade-off.
• Riesgos y No-Riesgos.

Actividades

ATAM incluye las siguientes actividades:

• Descripción de las Vistas de Arquitectura y estilos: la arquitectura se presenta en la medida, especificando cada detalle como se hace actualmente. Durante este paso, el arquitecto también identifica la calidad y los planteamientos arquitectónicos específicos (atributos y estilos).

• Recopilación y cartografía de los escenarios: Los escenarios que se suscitaron, priorizados por las partes interesadas. El arquitecto a continuación, elabora los mapas de los escenarios de alta prioridad, adicionándolo a la descripción de la arquitectura.

• Identificación de Riesgos / Sensibilidad / soluciones de compromiso: como resultado de la asignación de escenarios y el análisis subsiguiente, los grupos de riesgos, los puntos de sensibilidad, y las compensaciones quedan documentados.

Beneficios

• Dentro de los beneficios de la utilización de este método se encuentran:

• La organizada interacción que se establece entre los actores, arquitectos y equipo de evaluación.
• Toda la documentación arquitectónica que genera el proceso de evaluación.
• Desde el punto de vista financiero produce una disminución de los gastos.
• Ayuda a la preparación, documentación y entendimiento de la solución.
• Identifica errores arquitecturales antes de la construcción del sistema.
• Asegura la incorporación de escenarios para la validación de la arquitectura.
• Desarrollo de una arquitectura más general y flexible.
• Reducir riesgos del proyecto.

Vocabulario

• Escenario – descripción breve describiendo la interacción entre un stakeholders con el sistema.
• Stakeholder – individuo, grupo u organización interesado en, o relacionado con el sistema.
• Vista arquitectural – representación de todo el sistema desde una perspectiva de un conjunto de elementos o problemas de interés.
• Requerimientos funcionales – especifica lo que el software debe hacer.
• Requerimientos no-funcionales – especifica qué tan bien debería hacerse el sistema.

Roles

• Grupo de evaluación de la arquitectura

• Grupo entre 3-5 personas.

• Pertenecientes a la misma organización del grupo de desarrolladores o consultores.

• Tomadores de decisión del proyecto (decision makers): responsables del proyecto en capacidad de solicitar cambios.

• Incluyen gerente de proyecto, usuarios del sistema y arquitecto de la solución.
• Stakeholders de la arquitectura: articulación de las metas de los atributos de calidad en el sistema para que sea exitoso.
• Incluye ingenieros desarrolladores, integradores, el grupo de pruebas, usuarios, etc.

Véase También

Análisis de Arquitecturas de Software (SAAM).

Active Reviews for Intermediate Designs (ARID).

Architecture Level Modifiability Analysis (ALMA).

Performance Assessment of Software Architecture (PASA).

Scenario Based Architecture Level Usability Analysis (SALUTA).

Survivable Network Analysis (SNA).

Fuentes

Bass y Otros. 2005. Recommended Best Industrial Practice for Software Architecture Evaluation. s.l. : Software Engineering Institute, 2005.

Bass, L., Clements, P y Kazman, R. Software Architecture in practice. 1998.

Clements, Paul, Bergey, Dave y Mason, John.  Using the SEI Architecture Tradeoff Analysis Method to Evaluate WIN-T: A Case Study. s.l. : Software Engineering institute: Software Technology Initiative, 2005. pág. 13. ISSN: B0006RK3T0 .