1
Arquitectura de SoftwareIII: Elaboración
Hernán AstudilloDepartamento de Informática
Universidad Técnica Federico Santa María<hernan at acm.org>
Sesión 03 Arquitectura de Software -H.Astudillo
2
Contenido del curso– 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
PP
2
Sesión 03 Arquitectura de Software -H.Astudillo
3
III: Elaboración• Estilos• Patrones• Líneas de productos• Recuperación de arquitectura
Sesión 03 Arquitectura de Software -H.Astudillo
4
Diseños Reutilizables• Diseños reutilizables
– “Frameworks”• aplicaciones o sistemas incompletos
– Estilos• formas típicas de sistemas
– Patrones• heurísticas para solución con formas típicas
– Líneas de productos• generalizaciones de aplicaciones exitosas
3
Sesión 03 Arquitectura de Software -H.Astudillo
5
“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
Estilos de arquitectura
4
Sesión 03 Arquitectura de Software -H.Astudillo
7
Estilos de arquitectura• Propuestos por Shaw+Garlan (1996)• 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
Sesión 03 Arquitectura de Software -H.Astudillo
8
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
5
Sesión 03 Arquitectura de Software -H.Astudillo
9
Estilo: “pipes & filters”• Vocabulario: “filtros” y “pipes”• 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
Sesión 03 Arquitectura de Software -H.Astudillo
10
Estilo: repositorio• Estado compartido por varios componentes• 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
6
Sesión 03 Arquitectura de Software -H.Astudillo
11
Crítica – Estilos• Catálogos de estilos son listas de soluciones• 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)
Patrones
7
Sesión 03 Arquitectura de Software -H.Astudillo
13
Patrones de Diseño• Definición
– “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
Sesión 03 Arquitectura de Software -H.Astudillo
14
Patrón: Abstract Factory• Propósito
– 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 porla Abstract Factory
– Diferentes implementaciones del Abstract Factory devuelven diferentes instancias
8
Sesión 03 Arquitectura de Software -H.Astudillo
15
Patrón: Abstract Factory• Estructura
Abstract Factory
Concrete Factory
Abstract Product
Concrete Product
Client
Sesión 03 Arquitectura de Software -H.Astudillo
16
Patrón: Abstract Factory• Colaboraciones
:Client :Abstract Factory
:Abstract Product
createProduct
create
9
Patrones de arquitectura
Sesión 03 Arquitectura de Software -H.Astudillo
18
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
10
Sesión 03 Arquitectura de Software -H.Astudillo
19
Patrones de Buschman+• Categorías de patrones
– 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
Sesión 03 Arquitectura de Software -H.Astudillo
20
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”
11
Sesión 03 Arquitectura de Software -H.Astudillo
21
¿Diseño o Arquitectura?• “MVC” quizás es un mal nombre
– (Ya estaba en uso)• “Publisher-Subscriber” vs. MVC
– ¿Es diseño o es arquitectura?– Posible criterio: si el resultado son aplicaciones (software) o
productos, es arquitectura• Y si son clases, es diseño
Sesión 03 Arquitectura de Software -H.Astudillo
22
Patrones y estilos• Comparación
– 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
12
Sesión 03 Arquitectura de Software -H.Astudillo
23
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
Sesión 03 Arquitectura de Software -H.Astudillo
24
Patrones de Fowler [1]• Fowler et al.• Topología basada en 3 capas:
– dominio (negocio)– datos– presentación (Web)
• Tecnología– concurrencia– sesiones y estados– distribución
13
Sesión 03 Arquitectura de Software -H.Astudillo
25
Patrones de Fowler [2]• 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
Sesión 03 Arquitectura de Software -H.Astudillo
26
Patrones de Fowler [2]• 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
14
Sesión 03 Arquitectura de Software -H.Astudillo
27
Patrones de EAI• Propuestos por Hohpe [PLoP 2002]• 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
Sesión 03 Arquitectura de Software -H.Astudillo
28
Patrones de EAI (Cont.)
15
Sesión 03 Arquitectura de Software -H.Astudillo
29
Patrones de EAI: ejemplo
Sesión 03 Arquitectura de Software -H.Astudillo
30
Patrones: Resumen• Avance notable
– ...desde “estilos” descriptivos– ...a “patrones” clásicos de sistemas– ...a patrones de integración
• Patrones– Frutos de la experiencia– Heurísticas sistematizadas
16
Sesión 03 Arquitectura de Software -H.Astudillo
31
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 ☺
Líneas de productos
17
Sesión 03 Arquitectura de Software -H.Astudillo
33
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
Sesión 03 Arquitectura de Software -H.Astudillo
34
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
18
Recuperación de arquitecturas
Sesión 03 Arquitectura de Software -H.Astudillo
36
Recuperación de arquitecturas• Análisis...
– 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
19
Sesión 03 Arquitectura de Software -H.Astudillo
37
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 sistema2. Identificar arquitectura de la familia de productos3. Documentar arquitectura y permitir razonamiento
Sesión 03 Arquitectura de Software -H.Astudillo
38
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
20
Sesión 03 Arquitectura de Software -H.Astudillo
39
Resumen• Técnicas para elaborar arquitecturas
– 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
Sesión 03 Arquitectura de Software -H.Astudillo
40
Referencias [1]• [Shaw/Garlan 1996]
– 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)
Top Related