Arquitectura de Software IV: Procesos y evaluación. Contenido del curso

Transcripción

1 Arquitectura de Software IV: Procesos y evaluación Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María <hernan at acm.org> Introducción, motivación y contexto Representación de arquitecturas Elaboración de arquitecturas Principios y evaluación de arquitecturas Ejemplo de notación ad-hoc Principios y axiomas Calidad y evaluación de arquitecturas Método ATAM Prácticas de arquitectura Organizaciones y Mercados Componentes Contenido del curso 2 1

2 IV: Principios y evaluación Ejemplo de notación ad-hoc Principios y axiomas Calidad y evaluación de arquitecturas Método ATAM 3 Ejemplo de notación ad-hoc 2

3 5 capas usadas en este proyecto Las 5 capas 1) Lóbulos agregan funciones de negocios que requieren mecanismos similares 2) Componentes piezas (gran escala) de software o datos ofrecen servicios para manipular una unidad conceptual componentes típicos: lifecycle, reporting, importing 3) Servicios y conectores 4) Módulos piezas que puedan ser tratadas como una única entidad por el ambiente de programación 5) Infraestructura técnica topologías de redes/nodos estrategias de despliegue 5 Componentes típicos Componentes típicos: lifecycle permiten CRUD de una entidad manejada pelo sistema que puede ser interna o la imagen de una entidad externa ofreciendo estrategias básicas de recuperacion reporting generan informes sobre una entidad manejada por el sistema ofreciendo estrategias de recuperación complejas/múltiples con un mecanismo para describir contenido y formato importing aceptan y convierten datos externos en forma significativa mecanismo para describir conversiones 6 3

4 Ej.-Nivel 1: lóbulos age ncy FMS reconciliation public monies CA$H-LINK FI payment payment mediator analysis enabler sync activity FRB other sys STAR 7 Ej.-Nivel 1: caracterist. lóbulos Characteristic Payment mediator Analysis enabler Timeliness Near-time processing Batch processing Typical transactions OLTP-like DSS-like Synchronicity Event-driven Data-driven Availability 24x7 Daily Location Distributed, fail-over Centralized (internal replication) Reliability Extremely high ($) Plain old high 8 4

5 Ej.-Nivel 2: componentes Components overview (level 3-deposit) FA 93 (fedwire 25 (Fedwire rev.) rev. instrs.) 68 (funds transfer instrs.) age ncy CA$H-LINK LHS 98 (transf. remitt. detail) remittance detail activity reporting FMS CA$H-LINK RHS public monies 69 (publ. $ adj.) public monies lifecycle payment lifecycle payment mediator payments history 1 (dep. rep.) 23 (dep. adjust.) 2 (del./rev. dep) 107 (identif. unclassif.) 105 (classif. dep.) 121&122 (del. ACH req.) 37 (fedwires) 73 (REX dep. tix) 24 (fedwire correction) 29 (FRB deposit) depositing 74 (Fedwire dep. tix) FRB transfers 57 (create REC/DEC) REC/DEC activity other sys activity importing 27 (PAD jrnl.) 120 (NTDO DDA balance) synchronization 9 (record STAR trans.) 46 (STAR reps.) 35 (publ. $ rep.) FI REX 32 (ACH return) TRA CS 36 (REC/DEC) spec FI RFC STAR FRB 9 Ej-Niv.2: matriz de rastreab. Event Actors Component(s) #93 (Fedwire reversal) Agency Payment lifecycle #68 (funds transfer instrcutions) #25 (Fedwire reversal instructions) FA Payment lifecycle FA Payment lifecycle #1 (deposit report) FI Payment lifecycle #22 (deposit adjustment) FI Payment lifecycle #3 (deposit deletion/reversal) #102 (identif. Unclassified deposit) FI Payment lifecycle FI Payment lifecycle 10 5

6 Ej-Niv.3: componentes refinados Element Element kind Decomposition (used components) Additional properties Platform or product Payment lifecycle Load-balanced Component Lifecycle Fault-tolerant Ad-hoc Interaction to FI/FA Collection Fault-tolerant (duplicated to RHS) Payment mediator Fault-tolerant (duplicated) Component Persistence-LHS Java/Oracle Depositing Legacy-based Component Collection 11 Nuevamente la funcionalidad Pasar del dominio al software (entidades del dominio? entidades de software) Actividades propuestas definir contexto identificar arquetipos descomponer en componentes describir instancias del sistema 12 6

7 Principios y axiomas Propuestos por Witt, Baker & Merritt Principios y axiomas Principios de diseño Enfoques específicos al proceso de diseño que llevan a buenos diseños No reemplazan análisis ni proceso, pero concentran la atención en aspectos clave Basados en experiencia (con axiomas intermedios) 14 7

8 Separación de intereses Axiomas Resolver problemas complejos con soluciones intermedias expresadas en problemas menores independientes Comprensión Limitar comprensión a 7+2 elementos Traducción Un diseño correcto en un contexto lo seguirá siendo si se reemplaza su contexto con uno de servicios equivalentes Transformación Un diseño correcto lo seguirá siendo si se reemplaza sus componentes con otros equivalentes 15 Diseño modular Principios División en módulos con bajo acoplamiento y alta cohesión Especificaciones públicas de diseños ocultos Diseño portátil Lograr portabilidad con interfaces abstractas al contexto Diseño dúctil Elementos del diseño corresponden elementos del dominio Control intelectual Registrar diseños como jerarquías de abstracciones incrementalmente detalladas Integridad conceptual Vía aplicación uniforme de un número limitado de formas 16 8

9 Arquitectura basada en funcionalidad Idea: pasar del dominio al software (entidades del dominio? entidades de software) ejemplo: 3 capas Actividades (no pasos) definir contexto identificar arquetipos separar en componentes describir instancias del sistema evaluar y transformar, si corresponde Actividades concurrentes (en principio) 17 Método propuesto por Bosch 1. Identificar límites del sistema determinar qué no es software 2. Identificar core abstractions (arquetipos) pocas abstracciones combinables para generar funcionalidad estables 3. Descomponer arquitectura en componentes 4. Describir instancias del sistema Arquetipos Arquetipos no son componentes Arquetipo: tipo de funcionalidad, transversal al sistema Componentes: pieza del sistema mismo 18 9

10 Calidad y Evaluación de Arquitecturas [Bass+ 1997] Calidad Proceso Calidad según el proceso... Producto de un arquitecto o un grupo coherente ( integridad intelectual ) Requisitos claros y priorizados Arquitectura bien documentada Revisada por los stakeholders Analizada (en aspectos cuantificables) y formalmente revisada (en aspectos cualitativos) Prototipable y de construcción incremental Políticas explícitas para lidiar con conflictos específicos (p.ej. uso de ancho de banda o memoria) 20 10

11 [Bass+ 1997] Calidad Producto Calidad según la estructura del producto... Organizada en módulos claros y encapsulados Minimizar dependencias en implantación de los módulos Aislar probables cambios en módulos específicos Distinguir y documentar estructura modular ( build time ) y estructura computacional ( run time ) Mecanismos internos coherentes y consistentes 21 Evaluación de arquitecturas (en inglés: assessment, no evaluation ) Enfoques basados en... escenarios simulación modelado matemático (p.ej. filas) experiencia (!) Formalismos CMU-SEI 22 11

12 5 niveles de descripción Relación calidad-modelo Computaciones procesos computacionales Binarios artefactos entregados Software textos Especificación descripciones Proceso Nociones de calidad Mantenibilidad propiedad de los textos y descripciones Estabilidad / Disponibilidad propiedad de las computaciones Portabilidad propiedad de los textos y de los artefactos (en general) 23 Atributos de calidad Calidad del sistema a construir (detalle a seguir) Observables vía ejecución No observables vía ejecución Calidad de la arquitectura con respecto al negocio Oportuno ( time to market ) Eficiente (costo y tiempo) Larga vida útil Uso efectivo de sistemas existentes Calidad intrínseca de la arquitectura Integridad conceptual Parsimonia, minimalidad

13 Noción de arquitecturas elegantes Análogo a programas o demostraciones elegantes (p.ej. unicidad del neutro aditivo) (p.ej. recorrido recursivo de árboles) Elegancia Evaluación Reconocible después de haber visto muchas arquitecturas Aún no bien identificado Tal vez no definible formalmente (considerar: elegancia como identificacion de arquetipo del negocio) 25 Calidad del sistema a construir Observables Rendimiento Seguridad y Disponibilidad Autenticación y autorización MTBF Funcionalidad Tareas especificadas Usabilidad Eficiente y efectivo desde punto de vista del usuario No observables Modificabilidad (mantenibilidad) Mínima redundancia Portabilidad Reusabilidad (total o parcial) Integrable y fácil de probar 26 13

14 Calidad no tiene sentido sin evaluación Evaluación de calidad Pero en la práctica, en pocos casos se evalúa Evaluar es difícil Atributos de calidad aún no son bien entendidos Arquitecturas tienen alto nivel de abstracción Descripciones arquitecturales informales Falta de experiencia en evaluación 27 Técnicas de medición Enfoques para evaluar Métricas Interpretaciones cuantitativas de mediciones observables Experimentos (incl. simulación y prototipos) Análisis Modelado matemático a priori Técnicas de interrogación Escenarios (p.ej. SAAM, ATAM) Cuestionarios Checklists 28 14

15 Métricas usadas Tamaño de módulos, del diseño mismo, del código... Complejidad Modularidad Cohesión Acoplamiento Métricas El problema no es medir, sino interpretar las mediciones Las gerencias adoran las métricas 29 Método ATAM 15

16 [Clements/Kazman/Klein 2002] Método ATAM ATAM: Architecture Tradeoff Analysis Method método estructurado para hacer análisis repetible asegurar que las preguntas correctas serán hechas temprano enseña a evaluadores a buscar conflictos y su resolución Usos análisis de sistema a construir análisis de sistemas existentes (legado) 31 Presentación intercambio de información vía presentaciones ATAM Pasos Investigación y análisis evaluación de requisitos para atributos de calidad vs. enfoques arquitectónicos Prueba verificación de resultados vs. necesidades de stakeholders Reporte presentación de resultados 32 16

17 Presentación ATAM Presentación intercambio de información vía presentaciones 1. Presentar el ATAM evaluador líder describe método a participantes y define expectativas 2. Presentar los objetivos de negocio jefe de proyecto o contraparte describe objetivos del negocio que serán primarios al proyecto 3. Presentar la arquitectura arquitecto describe la arquitectura, concentrándose en cómo cumple los objetivos del negocio 33 ATAM Investigación y análisis Investigación y análisis evaluación de requisitos para atributos de calidad vs. enfoques arquitectónicos 4. Identificar enfoques arquitectónicos arquitecto los identifica pero no analiza (aún) 5. Generar el árbol de utilidad de atributos de calidad se elicita requisitos para utilidad del sistema (rendimiento, diponibilidad, seguridad, modificabilidad, usabilidad ) especificados hasta nivel de escenarios anotados con estímulos y respuestas priorizados 6. analizar enfoques de arquitectura se identifica riesgos, no-riesgos, puntos de sensibilidad y puntos de compromiso para escenarios de alta prioridad 34 17

18 Prueba ATAM Prueba verificación de resultados vs. necesidades de stakeholders 7. Hacer brainstorm y priorizar escenarios grupo completo de stakeholders elicita grupo de escenarios más completo se prioriza escenarios (votación) 8. Analizar los enfoques de arquitectura similar a #6 pero sólo para escenarios priorizados en #7 permite descubrir riesgos, no-riesgos, puntos de sensibilidad y puntos de compromiso adicionales 35 Reporte presentación de resultados 9. Presentar resultados a stakeholders ATAM Reporte 36 18

19 Estudio crítico de caso Knowledge-Based Risk Manager (KBS) Ejemplo no publicado en detalle Comentarios No muy largo (42 pp.) Dirigido a múltiples audiencias Cuenta una historia y ofrece una metáfora Exhibe rastreabilidad (refinamiento derivable) Destacado Mucho detalle Ejemplo: KBS Todas las suposiciones explicitadas Razón: arquitectos no estaban seguros de entender lo pedido!! 38 19

20 [Witt/Baker/Merritt 1994] Referencias [1/2] Bernard Witt, F. Terry Baker, Everett Merritt Software Architecture and Design: Principles, Models and Methods Van Nostrand Reinholt (1994) [Bosch 2000] Jan Bosch Design and Use of Software Architectures Addison Wesley (2000) [Jazayeri+ 2000] Mehdi Jazayeri, Alexander Ran, Frank van der Linden Software Architectures for Product Families Addison Wesley (2000) 39 [Clements/Kazman/Klein 2002] Referencias [2/2] Paul Clements, Rick Kazman, Mark Klein Evaluating Software Architectures: Methods and Case Studies Addison Wesley (2002) [Bass/Clements/Kazman 2003] Len Bass, Paul Clements, Rick Kazman Software Architecture in Practice (2nd Ed.) Addison Wesley (2003) 40 20