MÉTODOS DE EVALUACIÓN DE

ARQUITECTURAS DE SOFTWARE

Alexander Quiroz

Efraín Oviedo

• Métodos1

• Problema a evaluar2

• Selección del método3

Agenda

MÉTODOS

• ATAM

• ALMA

• SNA

• Comparación

ATAM (“Architecture Tradeoff Analysis Method”)

• Analiza varios objetivos de calidad: (Performance, modificabilidad, disponibilidad usabilidad, seguridad).

• Áreas : Estilos arquitectónicos, análisis de atributos de calidad y el método de evaluación SAAM (Software Architecture Analysis Method).

• Analiza la interacción entre los objetivos de calidad.

• Busca conflictos y su resolución.

ATAM - Aplicación

• Presentación1. Presentación de ATAM2. Presentación de los Objetivos de Negocio3. Presentación de la Arquitectura

• Investigación y Análisis4. Identificar las aproximaciones arquitecturales5. Generar el árbol de atributos de utilidad6. Analizar las aproximaciones arquitecturales

• Testing7. Lluvia de ideas y priorización de escenarios8. Analizar las aproximaciones arquitecturales

• Reporte9. Presentación de Resultados

ATAM - Esquema

ALMA (“Architecture Level Modifiability Analysis”)

• Analiza un objetivo de calidad: facilidad de la modificación

• Metas: Costo del mantenimiento, evaluación de riesgos, selección de un conjunto de arquitecturas

• Uso de escenarios de cambio.

ALMA - Aplicación

1. Definir la meta de evaluación.2. Describir la arquitectura de software.3. Obtener escenarios.4. Evaluar escenarios.5. Interpretar resultados.

ALMA - Esquema

SNA (“Survivable Network Analysis”)

• Analiza un objetivo de calidad: Supervivencia (capacidad de un sistema para completar su misión a tiempo ante la presencia de ataques, fallas o accidentes).

• Propiedades: Resistencia, Reconocimiento, Recuperación.

• Escenarios: normales, de intrusión.

ALMA - Aplicación

1. Definición del sistema.2. Definición de las capacidades esenciales.3. Definición de las capacidades que comprometen al sistema.4. Analizar la supervivencia.

SNA - Esquema

Comparación (ALMA – ATAM- SNA)Característica ATAM ALMA SNA

Meta Evaluar Arquitecturas de Software basada en los atributos de calidad especificados para el sistema.

Predecir el costo de mantenimiento, evaluarriesgos, comparación entre arquitecturas.

Identificar la capacidad de supervivencia en un sistema ante la presencia de ataques, fallas o accidentes.

Atributo de Calidad

Principalmente performance, modificabilidad, disponibilidad, usabilidad y seguridad

Facilidad de modificación Supervivencia

Tipo de Evaluación

Temprana / Clásica Clásica Temprana / Clásica

Técnica de Evaluación

Escenarios normales de uso,escenarios de crecimiento, escenarios de exploración,árboles de utilidad y lluvia de ideas estructurada

Escenarios de cambio Escenarios normales de uso, Escenariosde intrusión.

No de pasos 9 5 4

Personas involucradas

Arquitecto, skateholders, equipo de desarrollo, decision makers, usuarios del sistema

Arquitecto y equipo de desarrollo.

Arquitecto, diseñador principal, propietarios del sistema, usuarios.

PROBLEMA A

EVALUAR

• Descripción

• Criterios de Evaluación

Descripción del problema

Gestión del funcionamiento de un restaurante:

• Presentación de menús

• Recepción de pedidos en las mesas

• Gestión en cocina de solicitudes, elaboración y aviso de terminación de pedidos

• Entrega de platos

• Facturación

• Aprovisionamiento

• Consumo de alimentos

Criterios de Evaluación

Criterio Peso Observaciones

Facilidad de modificación 0.2 El problema a evaluar tiene muchas posibilidades de presentar cambios a futuro

Seguridad / Supervivencia 0.3 Clientes maliciosos pueden estar interesados en alterar el sistema.

Usabilidad 0.3 Debe ser agradable para el cliente

Evaluación temprana y tardía

0.2 Permite detectar posibles problemas a tiempo

SELECCIÓN DEL

MÉTODO

• Proceso de elección

• Aplicación del método

Proceso de elección

Criterio/Método ATAM ALMA SNA

Facilidad de modificación X X

Seguridad / Supervivencia X X

Usabilidad X

Evaluación temprana y tardía

X X

Método escogido: ATAM

Aplicación /Análisis ATAMFase 1 Presentación En la Fase 0 se acuerdan tiempo, fechas,

costos, esfuerzo y se forma el equipo de evaluación.

1Presentar el método ATAM

Se presenta el método a los skateholdersexplicando el proceso a seguir y el involucramiento y responsabilidad de cada uno en el proyecto.

2Presentar los objetivos de negocio

Se detallan los pasos a seguir, las técnicas a utilizar y los resultados a obtener.

3Presentar la arquitectura

El Arquitecto presenta la Arquitectura de Software definida incluyendo por lo menos los estilos utilizados, otros sistemas con que se debe interactuar, restricciones técnicas de software como por ejemplo uso de sistema operativo.

Fase 2 Investigación y análisis

4Identificar los enfoques arquitectónicos

El equipo de ATAM le pide al Arquitecto que identifique laspropuestas arquitectónicas o estilos de arquitecturautilizados, ya que éstos definirán las estructurasimportantes definidas para el sistema y las característicasimplicadas.

5Generar el árbol de utilidad

Se genera el árbol de utilidad donde principalmente elArquitecto pero también los principales stakeholders,identifican, priorizan y refinan los requerimientos deatributos de calidad más importantes del sistema, segúnse mencionó previamente, identificando los escenarios enel árbol y su importancia en las dos dimensiones definidas.

6Analizar los enfoques arquitectónicos

Se analizan las propuestas arquitectónicas según el árbolde utilidad generado, esto es, que tan adecuados son eluno para el otro, evaluando como cada propuestaarquitectónica influye en la obtención o no del atributo decalidad requerido, e identificando los riesgos, no riesgos,puntos de sensibilidad y concesión asociados a dichaevaluación.

Fase 3 Testing7Brainstorming y

priorización de escenariosLluvia de ideas y priorización de escenarios: se confirman e identifican nuevos escenarios según varios stakeholders involucrados, los que también se priorizan y se comparan con los identificados en el árbol de utilidad. Pueden suceder tres casos: el escenario ya está en el árbol de utilidad, no está pero encaja en alguna rama y se convierte en una nueva hoja, no está y no encaja en ninguna rama, lo que significa que no había sido consideradopreviamente.

8Analizar los enfoques arquitectónicos

se realiza lo mismo que Se realiza lo mismo que en el sexto paso para el nuevo árbol de utilidad con todos los escenarios incluidos.

Fase 4 Presentación de Informes9Presentar resultados El equipo de ATAM presenta los resultados a los

stakeholders y entrega la documentación correspondiente a las salidas del ATAM: documento de propuestas arquitectónicas, conjunto de escenarios priorizados, conjunto de preguntas basadas en los atributos, árbol de utilidad, los riesgos descubiertos, los no riesgos documentados, los puntos de sensibilidad y de concesión encontrados, más la relación entre los riesgos encontrados y su impacto en las pautas del negocio definidas.

Aplicación /Stakeholders

SkateholdersCamarerosCocinerosJefe de CocinaProveedoresGerente RestauranteCajeroClienteBarmanAdministrador sistemaExternos: gobierno (impuestos, normativa, contador, vigilancia y control)

Actividades:Arquitecto de software Project Managera. Restricciones técnicas a. Costos del proyectob. Tiempos de implementación de la solución b. Recursosc. Definición de recursos técnicos

c. Capacidad / Recursos (gestión)d. Manejo de proveedores

Aplicación / Escenarios

Ranking Escenarios1 Presentación/usabilidad de la solución2 Tiempo de respuesta del pedido de la

solicitud del pedido3 Envío/tiempo de respuesta de

proveedores (solicitudes de compra)4 Disponibilidad (7 x 24) de lunes a viernes

de 7 a.m. a 9 p.m. y los fines de semana hasta las 11 p.m.

5 Tolerancia a fallos6 Concurrencia7 Registrar/Asignar mesas (administrar)8 Realizar pedido / Gestión de pedido9 Administrar usuarios

Aplicación / Escenarios

Ranking Escenarios

10 Gestionar fidelización (sistema)11 Gestionar productos12 Gestionar platos13 Gestionar bebidas14 Imprimir facturas15 Calculo del costo al hacer el pedido16 Proceso de calculo de cantidad de

alimentos consumidos al finalizar el día17 Administración de inventarios18 Administración de proveedores y pedidos

(compras)19 Proceso de cierre de caja

Aplicación / ArquitecturaCapa Cliente PCs

Tablet PCs

BI

Capa Negocios Contenedor Compras

Contenedor Transacciones

Consumidor de servicios SOA FW

Capa Acceso a datos ORM

Broker

InternetCapa

Almacenamiento Bases de datos relacional

Bases de datos SQL

FW

Web Services Ventas

Web Services Pedidos

Aplicación / Árbol de utilidadAtributo de calidad Refinamiento del

AtributoEscenarios

Usabilidad Usabilidad de componentes

Usabilidad

Performance Tiempo de respuesta Tiempo de respuesta del pedido(M,M)

Throughput Envío/tiempo de respuesta de proveedores (solicitudes de compra)(M,M)

Latencia Elaborar 1 pedido cada 2 minutos(M,M)

Carga de trabajo Aumentar un pedido no aumentará los tiempos de latencia en mas de un 15%(H,H)

Aplicación / Árbol de utilidadAtributo de calidad Refinamiento del

AtributoEscenarios

Confiabilidad Confiabilidad del servicio

Confiabilidad 7x24(H,H)

Disponibilidad Disponibilidad de los componentes

(7 x 24) de lunes a viernes de 7 a.m. a 9 p.m. y los fines de semana hasta las 11 p.m.(H,H)

Mantenibilidad Cambios en un subsistema no requiere cambios en otro subsistema

Cambiar el motor de la base de datos implica un cambio en un subsistema (L,M)

Concurrencia Concurrencia de mesas/pedidos

Numero de mesas vs número de pedidos(M,M)

Portabilidad Portabilidad en los componentes de la capa de presentación

Presentar al usuario el servicio en diferentes medios (L,M)

Bibliografía

• GOMEZ, Omar. Evaluando la arquitectura de software. Métodos de Evaluación. www.osgg.net. Abril 17 de 2014

• Paul Clements, Rick Kazman and Mark Klein. “Evaluating Software Architecture”. Traducido por Universidad de los Andes. Dpto de Sistemas. Abril 22 de 2014

• Andrea Delgado, Alberto Castro, Martín Germán. Evaluación de Arquitecturas de Software con ATAM (Architecture Tradeoff Analysis Method): un caso de estudio. Abril 22 de 2014

¿PREGUNTAS?