MTODOS DE EVALUACIN DE

ARQUITECTURAS DE SOFTWARE
Alexander Quiroz
Efran Oviedo
Mtodos
1
Problema a evaluar
2
Seleccin del mtodo
3
Agenda
MTODOS
ATAM
ALMA
SNA
Comparacin
ATAM (Architecture Tradeoff Analysis
Method)
Analiza varios objetivos de calidad: (Performance,
modificabilidad, disponibilidad usabilidad,
seguridad).
reas : Estilos arquitectnicos, anlisis de
atributos de calidad y el mtodo de evaluacin
SAAM (Software Architecture Analysis Method).
Analiza la interaccin entre los objetivos de
calidad.
Busca conflictos y su resolucin.
ATAM - Aplicacin

Presentacin
1. Presentacin de ATAM
2. Presentacin de los Objetivos de Negocio
3. Presentacin de la Arquitectura

Investigacin y Anlisis
4. Identificar las aproximaciones arquitecturales
5. Generar el rbol de atributos de utilidad
6. Analizar las aproximaciones arquitecturales

Testing
7. Lluvia de ideas y priorizacin de escenarios
8. Analizar las aproximaciones arquitecturales

Reporte
9. Presentacin de Resultados
ATAM - Esquema
ALMA (Architecture Level
Modifiability Analysis)
Analiza un objetivo de calidad: facilidad de la
modificacin
Metas: Costo del mantenimiento, evaluacin
de riesgos, seleccin de un conjunto de
arquitecturas
Uso de escenarios de cambio.
ALMA - Aplicacin
1. Definir la meta de evaluacin.
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
misin a tiempo ante la presencia de ataques,
fallas o accidentes).
Propiedades: Resistencia, Reconocimiento,
Recuperacin.
Escenarios: normales, de intrusin.
ALMA - Aplicacin
1. Definicin del sistema.
2. Definicin de las capacidades esenciales.
3. Definicin de las capacidades que
comprometen al sistema.
4. Analizar la supervivencia.
SNA - Esquema
Comparacin (ALMA ATAM- SNA)
Caracterstica ATAM ALMA SNA
Meta Evaluar Arquitecturas de
Software basada en los
atributos de calidad
especificados para el
sistema.
Predecir el costo de
mantenimiento, evaluar
riesgos, comparacin 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 modificacin Supervivencia
Tipo de
Evaluacin
Temprana / Clsica Clsica Temprana / Clsica
Tcnica de
Evaluacin
Escenarios normales de uso,
escenarios de crecimiento,
escenarios de exploracin,
rboles de utilidad y lluvia de
ideas estructurada
Escenarios de cambio Escenarios normales de uso,
Escenarios
de intrusin.
No de pasos 9 5 4
Personas
involucradas
Arquitecto, skateholders,
equipo de desarrollo,
decision makers, usuarios del
sistema
Arquitecto y equipo de
desarrollo.
Arquitecto, diseador
principal, propietarios del
sistema, usuarios.
PROBLEMA A
EVALUAR
Descripcin
Criterios de Evaluacin
Descripcin del problema
Gestin del funcionamiento de un restaurante:
Presentacin de mens
Recepcin de pedidos en las mesas
Gestin en cocina de solicitudes, elaboracin y
aviso de terminacin de pedidos
Entrega de platos
Facturacin
Aprovisionamiento
Consumo de alimentos
Criterios de Evaluacin
Criterio Peso Observaciones
Facilidad de modificacin 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
Evaluacin temprana y
tarda
0.2 Permite detectar posibles problemas a
tiempo
SELECCIN DEL
MTODO
Proceso de eleccin
Aplicacin del mtodo
Proceso de eleccin
Criterio/Mtodo ATAM ALMA SNA
Facilidad de modificacin X X
Seguridad / Supervivencia X X
Usabilidad X
Evaluacin temprana y
tarda
X X
Mtodo escogido: ATAM
Aplicacin /Anlisis ATAM
Fase 1 Presentacin En la Fase 0 se acuerdan tiempo, fechas,
costos, esfuerzo y se forma el equipo de
evaluacin.
1Presentar el
mtodo ATAM
Se presenta el mtodo a los skateholders
explicando 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 tcnicas 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 tcnicas de
software como por ejemplo uso de sistema
operativo.
Fase 2 Investigacin y
anlisis
4Identificar los
enfoques
arquitectnicos
El equipo de ATAMle pide al Arquitecto que identifique las
propuestas arquitectnicas o estilos de arquitectura
utilizados, ya que stos definirn las estructuras
importantes definidas para el sistema y las caractersticas
implicadas.
5Generar el rbol de
utilidad
Se genera el rbol de utilidad donde principalmente el
Arquitecto pero tambin los principales stakeholders,
identifican, priorizan y refinan los requerimientos de
atributos de calidad ms importantes del sistema, segn
se mencion previamente, identificando los escenarios en
el rbol y su importancia en las dos dimensiones definidas.
6Analizar los
enfoques
arquitectnicos
Se analizan las propuestas arquitectnicas segn el rbol
de utilidad generado, esto es, que tan adecuados son el
uno para el otro, evaluando como cada propuesta
arquitectnica influye en la obtencin o no del atributo de
calidad requerido, e identificando los riesgos, no riesgos,
puntos de sensibilidad y concesin asociados a dicha
evaluacin.
Fase 3 Testing
7Brainstorming y
priorizacin de escenarios
Lluvia de ideas y priorizacin de escenarios: se
confirman e identifican nuevos escenarios segn varios
stakeholders involucrados, los que tambin 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 haba
sido considerado
previamente.
8Analizar los enfoques
arquitectnicos
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 Presentacin de Informes
9Presentar resultados El equipo de ATAM presenta los resultados a los
stakeholders y entrega la documentacin
correspondiente a las salidas del ATAM: documento de
propuestas arquitectnicas, 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 concesin encontrados, ms la relacin entre los
riesgos encontrados y su impacto en las pautas del
negocio definidas.
Aplicacin /Stakeholders
Skateholders
Camareros
Cocineros
Jefe de Cocina
Proveedores
Gerente Restaurante
Cajero
Cliente
Barman
Administrador sistema
Externos: gobierno
(impuestos, normativa,
contador, vigilancia y control)
Actividades:
Arquitecto de software Project Manager
a. Restricciones tcnicas a. Costos del proyecto
b. Tiempos de
implementacin de la
solucin b. Recursos
c. Definicin de recursos
tcnicos
c. Capacidad / Recursos
(gestin)
d. Manejo de proveedores
Aplicacin / Escenarios
Ranking Escenarios
1 Presentacin/usabilidad de la solucin
2 Tiempo de respuesta del pedido de la
solicitud del pedido
3 Envo/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 fallos
6 Concurrencia
7 Registrar/Asignar mesas (administrar)
8 Realizar pedido / Gestin de pedido
9 Administrar usuarios
Aplicacin / Escenarios
Ranking Escenarios
10 Gestionar fidelizacin (sistema)
11 Gestionar productos
12 Gestionar platos
13 Gestionar bebidas
14 Imprimir facturas
15 Calculo del costo al hacer el pedido
16 Proceso de calculo de cantidad de
alimentos consumidos al finalizar el da
17 Administracin de inventarios
18 Administracin de proveedores y pedidos
(compras)
19 Proceso de cierre de caja
Aplicacin / Arquitectura
Capa Cliente PCs
Tablet PCs
BI
Capa Negocios Contenedor Compras
Contenedor Transacciones
Consumidor de servicios SOA FW
Capa Acceso a datos ORM
Broker
Internet
Capa
Almacenamiento Bases de datos relacional
Bases de datos SQL
FW
Web Services Ventas
Web Services Pedidos
Aplicacin / rbol de utilidad
Atributo de calidad Refinamiento del
Atributo
Escenarios
Usabilidad Usabilidad de
componentes
Usabilidad
Performance Tiempo de respuesta Tiempo de respuesta del
pedido
(M,M)
Throughput Envo/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)
Aplicacin / rbol de utilidad
Atributo de calidad Refinamiento del
Atributo
Escenarios
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 nmero de
pedidos
(M,M)
Portabilidad Portabilidad en los
componentes de la
capa de presentacin
Presentar al usuario el servicio en
diferentes medios (L,M)
Bibliografa
GOMEZ, Omar. Evaluando la arquitectura de
software. Mtodos de Evaluacin.
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, Martn
Germn. Evaluacin de Arquitecturas de
Software con ATAM (Architecture Tradeoff
Analysis Method): un caso de estudio. Abril
22 de 2014
PREGUNTAS?