DEPARTAMENTO DE SISTEMAS. Evaluación de Arquitecturas de Software (ATAM)

Transcripción

1 Evaluación de Arquitecturas de Software ()

2 Agenda Introducción Otros mecanismos

3 Introducción Cómo estar seguro que la arquitectura seleccionada es la correcta? Cómo validar que las decisiones hechas fueron las correctas? Intuición Experiencia Ignorar el Problema

4 Introducción Por qué evaluar? Entre más temprano se encuentre un problema mucho mejor La evaluación es un mecanismo relativamente barato para evitar desastres

5 Cuándo Evaluar? Early Durante el diseño de la Arquitectura Antes de la implementación Late Solo cuando la arquitectura y su implementación han sido terminados

6 Quiénes Participan? Participantes Equipo de Evaluación Stakeholders Cúal es el resultado de la Evaluación de la Arquitectura La arquitectura es adecuada para el sistema? Cúal de las arquitecturas candidatas es la más apropiada?

7 La Arquitectura es Adecuada? Una evaluación de Arquitectura no va a decir: si o no, bien o mal o 6.5 sobre 10. La evaluación dice dónde hay riesgos [1]

8 Atributos de Calidad Los atributos de calidad son la base de una evaluación arquitectural Pero simplemente nombrarlos no es suficiente.. El sistema debe ser robusto.. El sistema debe ser altamente modificable

9 Atributos de Calidad Los atributos de calidad no son cantidades absolutas Existen en el contexto de objetivos específicos GQM de nuevo!!! Un sistema es modificable o no con respecto a un tipo de cambio particular El sistema es seguro con respecto a una amenaza particular

10 El producto de la Arquitectura Requerimientos de calidad priorizados Correspondencia de aproximaciones para lograr los atributos de calidad Riesgos Catálogo de aproximaciones arquitecturales utilizadas Puntos de Sensibilidad Puntos de negociación

11 Beneficios y Costos de la Evaluación Beneficios Descubre problemas temprano Producir una mejor arquitectura Congrega a los stakeholders Obliga a tomar decisiones sobre los atributos de calidad Prioriza objetivos en conflicto Obliga una clara explicación de la Arquitectura Mejora la Documentación de la Arquitectura

12 Beneficios y Costos de la Evaluación Costos Tiempo de los Stakeholders Posiblemente cambios en el cronograma del proyecto

13 The Tradeoff Architecture Method No solo evalua cómo la arquitectura satisface objetivos de calidad particulares También hace explícito como los objetivos de calidad interactuan entre ellos Basado en tres elementos Estilos Arquitecturales Atributos de Calidad The software Architecture Analysis Method (SAAM)

14 está conformado por un conjunto de pasos Presentación 1. Presentación de 2. Presentación de los Objetivos de Negocio 3. Presentación de la Arquitectura Investigación y Análisis Testing 4. Identicar las aproximaciones arquitecturales 5. Generar el árbol de atributos de utilidad 6. Analizar las aproximaciones arquitecturales 7. Lluvía de ideas y priorización de escenarios 8. Analizar las aproximaciones arquitecturales Reporte 9. Presentación de Resultados

15 1. Presentación del Presentado por el líder de evaluación Se explica el proceso Se presentan los 9 pasos Se explican las técnicas a utilizarce para generar ideas, priorizar escenarios, etc. Se explican los productos a obtenerser al final de la evaluación

16 2. Presentar los Objetivos de Negocio El gerente de proyecto presenta el sistema a desarrollar Funcionalidad principal Restricciones De negocio Técnicas Objetivos de Negocio Stakeholders involucrados Atributos de Calidad y su relación con los objetivos de negocio

17 3. Presentar la Arquitectura El arquitecto líder presenta la arquitectura Puntos de Vista Aproximaciones y Estilos seguidos

18 4. Identificar Aproximaciones Arquitecturales El equipo de trabajo identifica las aproximaciones arquitecturales pero no las analiza

19 5. Generación del Arbol de atributos de utilidad El equipo de evaluación y los stakeholders identifican y priorizan los atributos de calidad Los Arboles de Utilidad ofrecen un mecanismo para traducir objetivos de negocio en escenarios de calidad

20 Tomado de [1] pag 51

21 5. Arbol de Atributos (Cont.) Las hojas del árbol se prioriza en dos dimensiones Usar (High / Medium / Low) Importancia para el éxito del sistema Grado de dificultad para completar el escenario Escenarios con (H,H) son prioritarios

22 Estimulo Inicio de transacciones Artefacto Sistema Ambiente Bajo operaciones normales Respuesta Transacciones procesadas Medida Rta. Promedio de latencia dos segundos Fuente Usuario

23 6. Analizar las aproximaciones arquitecturales Se utilizan como entradas los artefactos de los puntos 4 y 5 En este paso se busca Identificar Riesgos Indentificar Puntos de Sensibilidad Generar Tradeoffs

24 Punto de Sensibilidad Propiedad de uno o mas componentes que es crítica para el logro de un atributo de calidad particular Tradeoff Propiedad que afecta más de un atributo o punto de sensibilidad

25 Los puntos de sensibilidad se utilizan para determinar Riesgos No riesgos Ejemplo Tener un backup de la BD afecta la recuperación El número de clientes simultáneos a la BD afecta el desempeño

26 Ejemplo Tradeoff Tener un backup de la BD afecta el desempeño luego es un tradeoff entre desempeño y recuperación

27 DEPARTAMENTO DE SISTEMAS Tomado de [1] pag 58

28 7. Lluvia de Ideas y Priorización de Escenarios Los escenarios son utilizados para Representar Intereses de los Stakeholders Entender los requerimientos de calidad Clases de Escenarios Casos de Uso Crecimiento Exploratorios

29 8. Analizar Aproximaciones Arquitecturales Se utilizan los escenarios del paso 7 Se ejecutan las mismas actividades del paso 6 Este ciclo se repite hasta no obtener más escenarios

30 9. Presentación de Resultados Aproximaciones Arquitecturales Riesgos No riesgos Puntos de Sensibilidad Tradeoffs

31 Bibliografia [1] Evaluating Software Architecture Paul Clements, Rick Kazman and Mark Klein.