Arquitectura de Software III: Elaboración. Contenido del curso

Transcripción

1 Arquitectura de Software III: Elaboració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 Estilos Patrones Líneas de productos Recuperación de arquitectura Principios y evaluación de arquitecturas Principios y axiomas Evaluación de arquitecturas Prácticas de arquitectura Organizaciones y Mercados Componentes Contenido del curso 2 1

2 III: Elaboración Estilos Patrones Líneas de productos Recuperación de arquitectura 3 Diseños reutilizables Frameworks aplicaciones o sistemas incompletos Diseños Reutilizables Estilos formas típicas de sistemas Patrones heurísticas para solución con formas típicas Líneas de productos generalizaciones de aplicaciones exitosas 4 2

3 Object-Oriented Frameworks Framework orientado a objetos diseño reusable que modela parte de un sistema de software con un conjunto de clases abstractas... que encarnan la colaboración entre sus instancias Forma de (re)uso hot spots : clases abstractas construir sub-clases específicas al sistema Resultan de procesos de análisis de dominio Pueden reducir el esfuerzo de desarrollo porque permiten reusar diseño y código Difícil desarrollarlos porque deben ser fáciles de usar y tener poder expresivo para cubrir variacioens del dominio 5 Estilos de arquitectura 3

4 Propuestos por Shaw+Garlan (1996) Estilos de arquitectura Identificados vía estudio de comunidades Estilo = definición de una familia de sistemas en términos de un patrón de organización estructural Un estilo define: vocabulario de tipos de componentes y conectores restricciones de combinación uno o más modelos semánticos para determinar propiedades del todo a partir de las partes 7 Estilos Procesamiento descompuesto en sub-unidades Pipes and filters Tipos de datos abstractos (estado encapsulado) Basado en eventos (invocación implícita) Sistemas en capas Repositorios Intérpretes Control de procesos (bucles) Estilos heterogéneos Mezclas de estilos Ejemplos Unix: capas, pipes, event-driven 8 4

5 Vocabulario: filtros y pipes Estilo: pipes & filters Estructuras permisibles: salidas a entradas Invariantes: filtros son independientes (no comparten estado con otros filtros) Especializaciones: pipelines (topología lineal) sistema secuencial en lotes ( batch ) Ejemplos programación shell Unix 9 Estado compartido por varios componentes Estilo: repositorio Vocabulario: repositorio (estructura central) y componentes Especializaciones blackboard bases de datos Nota: nada se dice sobre la implementación de la comunicación ni del repositorio 10 5

6 Catálogos de estilos son listas de soluciones Crítica Estilos A veces la categorización sorprende No es ortogonal Ejemplo: blackboard y bases de datos como especializaciones de repositorio blackboard: mecanismo de comunicación vía elemento central base de datos: mecanismo de integridad transaccional (propiedades ACID) Un blackboard puede implantarse vía una base de datos Niveles de abstracción diferentes Otra posible implantación LDAP-based XML replication (f Dynamic Web Publ) 11 Patrones 6

7 Definición Patrones de Diseño An object-oriented design pattern describes communicating objects and classes that are customized to solve a generic design problem in a particular context [Gamma95] Ventajas Idea abstracta reusable Vocabulario de comunicación Bloques básicos Capturan mejores prácticas de diseño 13 Propósito Patrón: Abstract Factory Proveer una interfaz para crear familias de objetos sin necesitar especificar las clases concretas Contexto Queremos crear una instancia de una clase Instancias de la clase son creadas en varios lugares del código Decisión sobre clase concreta de instancia postergada hasta ejecución Solución Crear una clase Abstract Factory que sea responsable por crear instancias de clases concretas El cliente ignora cuál instancia concreta está siendo creada por la Abstract Factory Diferentes implementaciones del Abstract Factory devuelven diferentes instancias 14 7

8 Estructura Patrón: Abstract Factory Client Abstract Factory Abstract Product Concrete Factory Concrete Product 15 Colaboraciones Patrón: Abstract Factory :Client :Abstract Factory createproduct create :Abstract Product 16 8

9 Patrones de arquitectura Patrones de arquitectura Patrones de arquitectura Derivados de patrones de diseño Propuesta inicial: Buschman et al. Categorías y conceptos diferentes del diseño Patrones de EAA ( Enterprise Application Architecture ) Propuesta más detallada pero micro : Fowler et al. Soluciones a problemas específicos de tecnologías 3 capas modernas Patrones de EAI ( Enterprise Application Integration ) Sistemas grandes heterogéneos distribuidos 18 9

10 Categorías de patrones Patrones de Buschman+ Estructurales ( from mud to structure ) Capas ( layers ) Pipes & Filtros Pizarra ( blackboard ) Sistemas distribuidos Broker Sistemas interactivos MVC: Model-View-Controller Presentación-Abstracción-Control Sistemas adaptables Reflexión Micro-kernel 19 Patrón de arquitectura: MVC MVC: Model-View-Controller Modelo: elemento de interés para observar/manipular Vista: representación (gráfica u otra) Controlador: manejo y control de vistas de un modelo Ejemplos famosos Smalltalk Struts (framework para aplicaciones Web) Especializaciones Observer-Oberved Publisher-Subscriber 20 10

11 MVC quizás es un mal nombre (Ya estaba en uso) Publisher-Subscriber vs. MVC Es diseño o es arquitectura? Diseño o Arquitectura? Posible criterio: si el resultado son aplicaciones (software) o productos, es arquitectura Y si son clases, es diseño 21 Comparación Patrones y estilos Estilo: solución en uso Patrón: solución y método para evaluar su adecuación a un problema Las capas son estilo o patrones? No nos confundamos: estilos y patrones no existen Son palabras que algunas autoridades han usado para describir ciertas cosas Un estilo llamado capas es una categoría (descriptiva, factual) de soluciones Un patrón llamado capas es una heurística (normativa) de cómo y cuándo usar cierta solución 22 11

12 Uso heterodoxo de patrones Patrones pueden ser usados para sólo analizar un problema Ignorando la solución de software propuesta Refinar con una solución en otro nivel de abstracción Ejemplo Problema: comunicar al profesor con sus alumnos topología 1:M, mensajes infrecuentes, conexiones esporádicas Solución: usar publisher-subscriber Refinamiento: usar lista de correos para implantar producto existente (minimizamos desarrollo y sus riesgos) se ajusta exactamente a las propiedades arriba Nota: este mecanismo también permite otras políticas de comunicación, por lo que dependemos de uso disciplinado 23 Fowler et al. Topología basada en 3 capas: dominio (negocio) datos presentación (Web) Tecnología concurrencia sesiones y estados distribución Patrones de Fowler [1] 24 12

13 Patrones de concurrencia Control de concurrencia optimista vs. pesimista Transacciones Patrones de datos Mapeos relacional-objetos campo identidad clave extranjera tabla de asociaciones mapeo de dependencias valor embutido herencia en una tabla clase en una tabla Metadatos Patrones de Fowler [2] 25 Patrones de presentación MVC Vistas: con plantillas transformaciones 2 pasos Sesión y estado Estado de sesión en el cliente Estado de sesión en el servidor Estado de sesión en base de datos Patrones de Fowler [2] 26 13

14 Propuestos por Hohpe [PLoP 2002] Patrones de EAI Análisis Qué se requiere para hacer funcionar la mensajería entre aplicaciones? Aspectos (dimensiones) Transportar (canales) Diseñar (mensajes) Rutear Transformar Producir y consumir Administrar y probar 27 Patrones de EAI (Cont.) 28 14

15 Patrones de EAI: ejemplo 29 Avance notable...desde estilos descriptivos...a patrones clásicos de sistemas...a patrones de integración Patrones Frutos de la experiencia Heurísticas sistematizadas Patrones: Resumen 30 15

16 Estilos y patrones Shaw y Garland (1996) introdujeron estilos de arquitectura p.ej. en capas, pipes y filtros... (detalles en breve) Patrones de diseño Heurísticas sistematizadas Originados en comunidad de POO [Gamma+] Patrón =... una solución (descripción) a un problema en un contexto (evaluación de fuerzas y comentarios) Proceso: patrones Elaboración, aprobación y publicación Comunidad fuerte y combativa 31 Líneas de productos 16

17 Líneas de productos Líneas de productos surgen (muchas veces) como generalizaciones de aplicaciones exitosas Respuesta supra-aplicación a portabilidad, modificabilidad, usabilidad... Acomoda variaciones en requisitos, plataformas, usuarios... Implicaciones para la organización Estructura Se requiere propiedad central de aspectos clave (ver discusión sobre componentes) Relaciones con clientes Unidades dueñas de productos son clientes internos 33 Líneas de productos: problemas Gran problema: evolución sincronizada Casos: Evolución de la línea de productos misma Nuevas versiones de componentes existentes Nuevos componentes Nuevas funciones Evolución de cada producto individualmente Fuerzas centrífugas (productos divergen) Prioridades divergen aún para áreas comunes Propagación de cambios a productos ya entregados 34 17

18 Recuperación de arquitecturas Análisis... Recuperación de arquitecturas de estructura de propiedades Mapeamientos a arquitectura de referencia a framework (propio del dominio) a familia de productos En general, a un vocabulario que permita razonar sobre arquitectura Observaciones No basta (ni se requiere) ingeniería reversa Puede haber limitaciones estructurales 36 18

19 Proceso de recuperación Basado en identificar propiedades arquitectónicas [Bellay/Gall/Jazayeri] Propiedades independientes del dominio (propias del sistema) Propiedades específicas del dominio (como seguridad, rendimiento...) Propiedades de la familia de productos (usadas para generar variantes) Proceso 1. Recuperar propiedades arquitectónicas de un sistema 2. Identificar arquitectura de la familia de productos 3. Documentar arquitectura y permitir razonamiento 37 Razones para recuperar arquitecturas De un sistema Re-documentar Permitir razonamiento y evaluación Rediseñar la arquitectura yendo del as is al to be Mantener y reparar estimando impacto de cambios De una línea de productos Desarrollar sucesores permitir reuso, factorización Mantener y reparar productos individuales Desarrollar otras familias de productos 38 19

20 Técnicas para elaborar arquitecturas Resumen enfoque: documentar arquitecturas para reutilización y reutilizarlas Evolución histórica desde descripciones a heurísticas hacia dimensiones Líneas de productos & recuperación de arquitectura Procesos técnicos con implicaciones organizacionales 39 [Shaw/Garlan 1996] Referencias [1] Mary Shaw, David Garlan Software Architecture: Perspectives on an Emerging Discipline Prentice Hall (1996) [Buschman+ 1996] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal Pattern-Oriented Software Architecture (en la 2da.Ed, Volume 1: A System of Patterns) Wiley (1996) [Fowler 2002] Martin Fowler with David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford Patterns of Enterprise Application Architecture Addison-Wesley (2002) 40 20

21 [Hohpe 2002] Gregor Hohpe Enterprise Integration Patterns PLoP 2002 Referencias [2] [Gamma 95] Erich Gamma, R. Heml, Ralph Johson, John Vlissides Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley (1995) 41 21