métodos de evaluación de arquitecturas de software5
TRANSCRIPT
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
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.
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.
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.
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
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