Arquitectura de Software III: Elaboración -...

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


3

III: Elaboración• Estilos• Patrones• Líneas de productos• Recuperación de arquitectura


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


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


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


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


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


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


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


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


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


15

Patrón: Abstract Factory• Estructura

Abstract Factory

Concrete Factory

Abstract Product

Concrete Product

Client


16

Patrón: Abstract Factory• Colaboraciones

:Client :Abstract Factory

:Abstract Product

createProduct

create

9

Patrones de arquitectura


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


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


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


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


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


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


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


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


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


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


28

Patrones de EAI (Cont.)

15


29

Patrones de EAI: ejemplo


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


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


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


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


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


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


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


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


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)

21


41

Referencias [2]• [Hohpe 2002]

– Gregor Hohpe– Enterprise Integration Patterns– PLoP 2002

• [Gamma 95]– Erich Gamma, R. Heml , Ralph Johson, John Vlissides– Design Patterns: Elements of Reusable Object-Oriented

Software– Addison-Wesley (1995)

Arquitectura de Software III: Elaboración -...

Documents

Transcript of Arquitectura de Software III: Elaboración -...