validacion de arquitectura - cs.uns.edu.arece/ads/downloads/clases/2018 15 ayds... · validacion de...

VALIDACION DE ARQUITECTURA

ELSA ESTEVEZ

UNIVERSIDAD NACIONAL DEL SUR

DEPARTAMENTO DE CIENCIAS E INGENIERIA DE LA COMPUTACION

Arquitectura y Diseño de Sistemas Bahía Blanca | 21 de mayo de 2018 | 2

CONTENIDO

1 VALIDACION DE ARQUITECTURA

Motivación

Técnicas

2 ATAM - ARCHITECTURE TRADEOFF ANALYSIS METHOD

Caracteristicas

Pasos

Resumen


VALIDACION DE RQUITECTURA – MOTIVACION

Por qué es necesario validar la arquitectura?

o Correctitud

Validar abstracciones

Chequear la correctitud técnica

o Comunicación

Vender la arquitectura

Explicar la arquitectura

o Proceso de desarrollo de software

Validar las suposiciones

Proveer puntos de decisión claves

Asegurar la integridad técnica entre el sistema que se está construyendo

y el que fue diseñado.


TECNICAS DE VALIDACION

1) Presentaciones

2) Revisiones formales y walkthroughs estructurados

3) Evaluación usando escenarios

4) Prototipos y pruebas de concepto

5) Esqueleto del sistema


PRESENTACION – 1

o presentar una explicación informal de la arquitectura propuesta a los interesados

o se debe estructurar la presentación de tal forma que comprometa a la audiencia a hacer un análisis del impacto de lo presentado

Ventajas

o son rápidas de crear y de personalizar para distintas audiencias

o requiere poca preparación (o quizás ninguna) por parte de los asistentes.

o se puede obtener retroalimentación inmediatamente a partir de reacciones o preguntas de la audiencia


PRESENTACION – 2

Limitaciones

o se logra un nivel de análisis superficial durante la presentación

o su efectividad depende fuertemente de la calidad del material presentado

o es fácil obtener un falso sentido de seguridad si la audiencia no estácomprometida

o la carencia de una preparación previa por parte de los asistentes, podría provocar la falta de una análisis profundo de sus fortalezas y debilidades


PRESENTACIÓN – DISCUSIÓN


REVISIONES FORMALES Y WALKTHROUGHS ESTRUCTURADOS - 1

o se definen 3 roles entre los asistentes: moderador, presentador y revisor

o se envía el documento a ser revisado unos días antes de la reunión, junto con punteros a información de background que ayuda a preparar a los asistente

o involucra:

1) reunir a un grupo de personas de interés

2) recorrer el objeto de revisión (documento) página a página

3) realizar comentarios

4) discutir intereses

5) acordar accionables

6) registrar resultados

Ventajas

o involucra a los participantes de manera más profunda que una presentación, logrando un análisis más valioso


REVISIONES FORMALES Y WALKTHROUGHS ESTRUCTURADOS - 2

Limitaciones

o es mas costoso de realizar que una presentación

costo de preparación de los participantes

tiempo de la reunión

o su efectividad depende de la preparación previa a la reunión


REVISIONES FORMALES Y WALKTHROUGH - DISCUSIÓN

¿Cuánto más costoso que una presentación?

¿ Cuáles son los costos y beneficios comparados con una presentación?


ESCENARIOS – 1

o evalúa cuán bien la arquitectura direcciona las necesidades de los interesados en términos de los atributos de calidad que la arquitectura exhibe

o consta de 5 pasos fundamentales:

1) entender los requerimientos

2) entender la arquitectura propuesta

3) identificar escenarios priorizados

4) analizar la arquitectura

5) armar un reporte con los resultados y sacar conclusiones sobre la idoneidad de la arquitectura

o en sistemas no demasiado grandes ni complejos, podría ser utilizada de manera informal

o en situaciones más complejas, conviene ir a un método más formal como ATAM (Architecture Tradeoff Analysis Method) o SAAM (Software ArchitectureAnalysis Method)


ESCENARIOS – 2

Ventajas

o puede proveer un análisis detallado y sofisticado de las fortalezas y debilidades

o conducen a un mejor entendimiento de los tradeoffs planteados en la arquitectura

o ayudan a entender las decisiones tomadas, por qué se tomaron y su impacto

Limitaciones

o son considerablemente más complejas y costosas

o se requiere cierto entrenamiento y experiencia para liderarlas

o alternativas como ATAM requieren que todos los interesados puedan participar de manera profunda, comprometida y constructiva


ESCENARIOS - DISCUSIÓN

¿Cuánto más costoso que una presentación?

¿ Cuáles son los costos y beneficios comparados con una presentación?


PROTOTIPOS Y PRUEBAS DE CONCEPTO – 1

Definición – PROTOTIPO

Es un sub-conjunto funcional del sistema generalmente presentado a los usuarios para obtener retroalimentación y validación

Definición – PRUEBA DE CONCEPTO

Código diseñado para probar si un elemento de riesgo de la arquitectura propuesta es viable, resaltando cualquier problema o escollo que se encuentre

o son frecuentemente usadas para mitigar riesgos técnicos o para ayudar a diseñar la interfaz de usuario

o debieran descartarse luego de hecha la prueba

o manejar las expectativas de los interesados, ya que pueden creer que es el sistema final


PROTOTIPOS Y PRUEBAS DE CONCEPTO – 2

Ejemplo:

demostrar que una arquitectura soporta gran volumen de transacciones

demostrar que las interfaces gráficas son viables

demostrar que el acceso a dispositivos de hardware específicos es viable

Ventajas

o pueden proveer validaciones concretas sobre decisiones técnicas

o proveen la oportunidad de aprender y entender sobre las tecnologías de implementación del sistema antes de usarlas en el sistema

o permiten incrementar la confianza de los interesados en la gente, tecnología y procesos utilizados.

Limitaciones

o pueden ser bastante costosos de construir - en tiempo y dinero


PROTOTIPOS - DISCUSIÓN

¿Cuáles son las ventajas y desventajas de usar prototipos?

¿Cómo se compara con otros enfoques?


ESQUELETO DEL SISTEMA – 1

o se crea una primera versión, llamada esqueleto, que implementa la estructura del sistema, pero que sólo contiene un subconjunto mínimo de funcionalidad

o permite probar el procesamiento end-to-end de manera tal de demostrar que la estructura general del sistema es apropiada

o sirven de base para la fase de construcción propiamente dicha


ESQUELETO DEL SISTEMA – 2

Ventajas

o es el tipo de validación más minucioso y convincente sobre una arquitectura

o el esqueleto es un entregable tangible que puede ser usado más allá de la actividad de validación

Limitaciones

o probablemente sea la manera más costosa de evaluar una arquitectura

o el equipo encargado de construir el esqueleto necesita tener gran experiencia y disciplina en el desarrollo


ESQUELETO DEL SISTEMA - DISCUSIÓN

¿Qué diferencia hay con un prototipo?

¿Cuáles son los costos y beneficios comparados con otros enfoques de validación?


CONTENIDO

1 VALIDACION DE ARQUITECTURA

Motivación

Técnicas

2 ATAM - ARCHITECTURE TRADEOFF ANALYSIS METHOD

Caracteristicas

Pasos

Resumen


ATAM

o desarrollado en el año 2000 por el Software Engineering Institute (SEI) en la Universidad de Carnegie Mellon

o ha sido usado durante mucho tiempo para evaluar arquitecturas de software en distintas industrias (automotriz, financiera, etc.)

o está diseñado tal que…

los evaluadores no necesiten estar familiarizados con la arquitectura o las metas de negocio

el sistema no necesita estar construido

pueda haber un gran número de interesados


ATAM – PROPOSITO – 1

1) Identificar tempranamente…

o Riesgos – decisiones arquitecturalmente importantes que no han sido tomadas, o que han sido tomadas pero cuyas consecuencias aun no se conocen bien

o Puntos sensibles – decisiones para las cuales un ligero cambio produce una diferencia significativa en algún atributo de calidad

o Puntos de tradeoffs – decisiones que afectan de manera contrapuesta a más de un atributo de calidad

Evaluar las consecuencias de las decisiones arquitectónicas en función de los

requerimientos de los atributos de calidad


ATAM – PROPOSITO – 2

2) Planificar acciones de mitigación

3) Mejorar la documentación de arquitectura

• mejorando la definición de los requerimientos de atributos de calidad que influencian a la arquitectura

• mejorando la documentación de las decisiones de diseño


PARTICIPANTES – 1

o El equipo de evaluación

• es externo al proyecto y generalmente consiste de 3 a 5 personas

• pertenecen a la misma organización o son consultores externos

• se asignan diferentes roles: líder de equipo, líder de evaluación, escriba de escenarios, escriba de procedimiento, “cuestionador“

o Quienes toman decisiones en el proyecto

• quienes están autorizados para hablar por el proyecto y tomar decisiones sobre el mismo - líder de proyecto, representante de los clientes, arquitecto


PARTICIPANTES – 2

o Interesados de arquitectura

• Son aquellos cuya capacidad de hacer su trabajo gira en torno a cómo la arquitectura promueve atributos de calidad como modificabilidad, seguridad, alta disponibilidad, etc. - desarrolladores, testeadores, integradores, usuarios, ingenieros de performance, etc.

• Su trabajo durante una evaluación es articular los objetivos de los atributos de calidad específicos que la arquitectura debe cumplir para que el sistema sea considerado un éxito.


SALIDAS

o una presentación concisa de la arquitectura

o articulación de los objetivos de negocio

o escenarios de atributos de calidad priorizados

o conjunto de riesgos y no-riesgos

o un conjunto de temas de riesgo

• en base a los riesgos detectados, se identifican debilidades sistémicas en la arquitectura - en el proceso de la arquitectura, y/o en el equipo

o mapeo de decisiones de arquitectura y requerimientos de calidad

o conjunto de puntos sensibles y puntos de tradeoff identificados

Las salidas se usan para construir un reporte final que resume el método, las

actuaciones realizadas, captura los escenarios y su análisis, y cataloga hallazgos


OTRAS SALIDAS – 1

o Resultados intangibles

• el sentido de comunidad por parte de los interesados

• canales de comunicación abiertos entre el arquitecto y los interesados

• mejor entendimiento general de la arquitectura, tanto de sus fortalezas como de sus debilidades


OTRAS SALIDAS – 2


FLUJO CONCEPTUAL


FASES DEL PROCESO

1. Presentar ATAM

2. Presentar los conductores del negocio

3. Presentar la arquitectura

4. Identificar los enfoques arquitectónicos

5. Generar el árbol de utilidad de los atributos de calidad

6. Analizar los enfoques arquitectónicos

7. Brainstorming y priorización de escenarios

8. Analizar los enfoques arquitectónicos

9. Presentar Resultados

Fase 1

Fase 2

Fase 3

Preparación de la evaluación


FASES DEL PROCESO – DESCRIPCION


PASO 1

Presentar ATAM

o El equipo de evaluación presenta un resumen de ATAM

o Se responden preguntas

o Se define el contexto y las expectativas del resto de las actividades

Técnicas Utilizadas

Salidas

• Generación de árbol de utilidad• Elicitación y análisis de la arquitectura• Construcción de escenarios

• Escenarios priorizados• Enfoques y estilos arquitectónicos identificados• Preguntas usadas para entender/evaluar la arquitectura• Árbol de utilidad• Riesgos y no riesgos descubiertos• Puntos sensibles y de tradeoff descubiertos


PASO 1 – ÁRBOL DE UTILIDAD (EJEMPLO)

Utilitdad

Seguridad

Confidencialidad

Datos del usuario protegidos de

acceso por canales ocultos

Integridad

Recursos críticos ay b protegidos de

manipulación maliciosa

DisponibilidadNo se permite

acceso por redes no autorizadas

Performance Eficiencia

Se demuestra e eficiencia mejorada

con respecto a sistema actual en X


PASO 2

Presentar los conductores del negocio

o Uno de los que toman decisiones en el proyecto (generalmente el gerente de proyecto o cliente) presenta un pantallazo del sistema desde una perspectiva de negocio

La presentación debería incluir:

o las funciones más importantes del sistema

o cualquier restricción técnica, gerencial, económica o política

o los objetivos y el contexto del negocio y cómo se relacionan con el proyecto

o los principales interesados

o los conductores de la arquitectura - atributos de calidad que influencian la arquitectura


PASO 3

Presentar la arquitectura

o El arquitecto líder (o equipo de arquitectura) realiza una presentación describiendo la arquitectura

o La presentación debiera transmitir la esencia de la arquitectura y no perderse en áreas secundarias, ni adentrarse en los detalles profundos de sólo algunos aspectos

o El arquitecto debe presentar las vistas que consideró más importantes durante la creación de la arquitectura y también aquellas que ayuden a razonar sobre los requerimientos de los atributos de calidad más importantes para el sistema.

• restricciones técnicas, como sistema operativo, hardware, middleware prescripto a usar

• otros sistema con los que se debe interactuar

• enfoques arquitectónicos (patrones, estilos, tácticas) usados para cumplir los requerimientos


PASO 3

Ejemplo de template de presentación (~20 transparencias, 60 minutos)


PASO 4

Identificar enfoques arquitectónicos

o Hasta el momento, el equipo de evaluación tiene una buena idea sobre los patrones, estilos y tácticas usados por el arquitecto para diseñar el sistema:

o Estudió la documentación de la arquitectura (Fase 0)

o Atendió a la presentación de arquitectura del Paso 3

o Pudo proponer nuevos enfoques que no se mencionaron explícitamente

o En este paso, el equipo de evaluación simplemente cataloga los patrones, estilos y tácticas identificados en función de los requerimientos de atributos de calidad relacionados.

o La lista es capturada y servirá como entrada para el análisis posterior.


PASO 5

Generar el árbol de utilidad de los atributos de calidad

o Las metas relacionadas con los atributos de calidad para la arquitectura en consideración fueron identificados en el Paso 2.

o En este paso, el equipo de evaluación trabaja con quienes toman decisiones en el proyecto para identificar, priorizar y refinar las metas relacionadas con los atributos de calidad más importantes para el sistema.


PASO 5

Generar el árbol de utilidad de los atributos de calidad

o un árbol de utilidad es un modelo jerárquico conducido por los principales requerimientos de calidad

o el primer nivel de nodos se corresponde con los principales atributos de calidad

o los nodos internos especifican distintos aspectos de cada atributo

o las hojas son escenarios de calidad

Los escenarios son priorizados en base a dos criterios:

• importancia del escenario para el negocio

• grado de dificultad de la arquitectura para soportar el escenario


PASO 5

EJEMPLO


PASO 6

Analizar enfoques arquitectonicos

o El equipo de evaluación examina los escenarios más prioritarios de a uno. El arquitecto explica cómo la arquitectura soporta a cada escenario

o Los miembros del equipo de evaluación (especialmente los cuestionadores) interpelan dichos enfoques arquitectónicos que el arquitecto usó para direccionar el escenario

o El equipo de evaluación:

• genera preguntas específicas sobre los enfoques de arquitectura que abordan un escenario

• identifica y registra las decisiones arquitectónicas, las preguntas y respuesta, los riesgos y no-riesgos, y los puntos sensibles y tradeoffs.


PASO 6

Analizar enfoques arquitectonicos – Ejemplos de análisis de escenarios

o La frecuencia de heartbeat afecta al tiempo en el cual el sistema puede

detectar un componente fallido. Algunos valores serían inaceptables (riesgo)

o La cantidad de clientes de base de datos simultáneos afectará a la cantidad de

transacciones que una base de datos puede procesar por segundo. Por lo

tanto, la asignación de clientes a servidores será un punto sensible.

o La frecuencia de heartbeat determina el tiempo para la detección de una falla.

Una frecuencia mayor conduce a mejorar la disponibilidad, pero también

consume más tiempo de procesamiento y ancho de banda de comunicación,

potencialmente reduciendo la performance (tradeoffs)

1 Heartbeat es un programa que corre automaticamente un script especial cada vez que el sistema es

inicializado. Originalmente diseñado para clusters basados en dos nodos Linux


PASO 6

Analizar enfoques arquitectonicos – Ejemplos de analisis de escenarios

o Las reglas para escribir módulos de lógica de negocio en la segunda capa de un

estilo 3-capas no están claramente articuladas. Esto podría resultar en la

replicación de funcionalidad, comprometiendo la modificabilidad de la tercera

capa (riesgo)

o Asumiendo una tasa de arribo de mensajes de 1 por segundo, un tiempo de

procesamiento de menos de 30 ms, y la existencia de un proceso de prioridad

mayor, un deadline de 1 segundo parece razonable (no riesgo)

o La disponibilidad de un sistema depende de la cantidad de backups activos y

pasivos (punto sensible)


PASO 6

Analizar enfoques arquitectonicos –

Ejemplo de análisis de enfoque de

arquitectura


FIN FASE 1

INTERVALO

o El equipo de evaluación resume lo que aprendió e interactúa informalmente (de manera no-presencial) con el arquitecto durante el intervalo de una o dos semanas.

o Más escenarios podrían ser analizados durante el intervalo, o también podrían surgir nuevas preguntas o clarificaciones, y ser resueltas.


FASE 2

o La Fase 2 incorpora participantes adicionales a la lista de interesados.

o Se repite el Paso 1 para que los interesados entiendan el método y el rol que juegan.

o El líder del equipo de evaluación:

o resume los resultados de los Pasos 2 al 6

o comparte la lista de riesgos, no-riesgos, puntos sensibles y tradeoffsdetectados hasta el momento


PASO 7

Brainstorming y priorización de escenarios

o El equipo de evaluación le pide a los interesados que propongan escenarios que son significativos con respecto a sus roles

• mantenimiento - escenario de modificabilidad

• usuario final - escenarios correspondientes a la funcionalidad y usabilidad

• aseguramiento de calidad - escenarios sobre testeabilidad y replicación del estado del sistema que permita reproducir una falla

o El brainstorming permite entender qué significa el éxito del sistema para los interesados


PASO 7

Brainstorming y priorización de escenarios

o Los escenarios propuestos se priorizan:

• primero se intentan combinar algunos escenarios (si fuera posible)

• los interesados votan cuáles son los escenarios más prioritarios

o La lista de escenarios priorizada es comparada con la del árbol de utilidad

• si concuerdan, indica que el arquitecto estuvo alineado con los interesados

• si se descubrieron nuevos escenarios, podría ser un riesgo si la diferencia es grande, ya que indicaría que hubo alguna desincronización en las metas importantes para el sistema entre los interesados y el arquitecto.


PASO 8

Analizar los enfoques arquitectónicos

o este paso es similar la Paso 6, pero sobre los nuevos escenarios generados y priorizados.

o este paso podría cubrir el top 5 o 10 de escenarios, de acuerdo a lo que el tiempo permita.


PASO 9

Presentar resultados

o El equipo de evaluación agrupa riesgos en temas de riesgo , en base a algunos intereses comunes o deficiencias sistémicas

• Riesgos referentes a documentación desactualizada podrían agruparse en un tema de riesgo indicando que la documentación no tiene la suficiente consideración

• Riesgos referentes a la incapacidad de un sistema para funcionar ante varias fallas de hardware y/o software, podría conducir a un tema de riesgo sobre la atención insuficiente a la capacidad de backup o a proveer alta disponibilidad.

o Para cada tema de riesgo, el equipo de evaluación identifica cuáles de los conductores del negocio listados en el Paso 2 que son afectados

• Esto cierra el circuito y eleva los riesgos para ser considerados en la gestión del proyecto.


PASO 9

Presentar resultados

La información recolectada durante el proceso es resumida y presentada a los interesados:

o los enfoques arquitecturales documentados

o el conjunto de escenarios y su priorización

o el árbol de utilidad

o los riesgos descubiertos

o los no-riesgos documentados

o los puntos de sensibilidad y los puntos de tradeoff encontrados

o los temas de riesgo y los drivers del negocio amenazados


ATAM - RESUMEN

ATAM es un método útil y probado para identificar riesgos en la arquitectura de un sistema

o las revisiones de arquitectura se han difundido en los últimos años

o existen variaciones de ATAM para diferentes propósitos

DIFICULTADES

o se requiere cierta disciplina para lograr progreso en las reuniones

o pueden existir problemas culturales

o reunir a los principales interesados puede ser complicado

o ante presiones de tiempo, las revisiones se recortan

o la organización no necesariamente se hace cargo o utiliza los riesgos y otros resultados


ATAM – RESUMEN DE BENEFICIOS

o financiero - ahorra dinero detectando problemas que a posteriori requerirían mayor inversión para ser resueltos

o fuerza la preparación, documentación y entendimiento

o captura las justificaciones

o atrapa errores en la arquitectura antes de construirla

o asegura que la arquitectura cumpla con los escenarios principales

o logra una arquitectura más general y flexible

o reduce los riesgos


ATAM – RESUMEN DE COSTOS

o 1 o 2 semanas de tiempo de 8-10 personas muy bien remuneradas, más 2 días de otras 10-12 personas (proceso formal completo)

o retraso en la construcción del proyecto

o fuerza que el diseño de la arquitectura sea por adelantado


BIBLIOGRAFIA

Software System Architecture

Rozanski, Woods2005 - Addison-Wesley

Software Architecture in Practice

3rd Edition

Bass, Clements, Kazman2012 - Addison-Wesley

ATAM: Method for Architecture Evaluation

Kazman, Klein, Clements2000 – SEI

https://www.sei.cmu.edu/reports/00tr004.pdf

https://www.sei.cmu.edu/reports/00tr004.pdf

Elsa Estevez

[email protected]

validacion de arquitectura - cs.uns.edu.arece/ads/downloads/clases/2018 15 ayds... · validacion de...

Documents