Estilos en Arquitectura de Software

Carlos ReynosoUNIVERSIDAD DE BUENOS AIRES

Billyreyno@hotmail.comhttp://carlosreynoso.com.ar

Temario

• Estilos en Arquitectura de Software– Definición de estilo– Catálogos de estilos– Características de estilos– Uso de estilos (Garlan & Shaw)

• Patrones– Historia, definiciones, clases– Anti-patrones– Refactorización

• Conclusiones

Estilos Arquitectónicos

• Rumbaugh & al 1991– (1) transformaciones en lote, (2) transformaciones continuas, (3) interfaz

interactiva, (4) simulación dinámica de objetos del mundo real, (5) sistemas de tiempo real, (6) administrador de transacciones con almacenamiento y actualización de datos

– Pero: “estilos arquitectónicos”, “arquitecturas comunes”, “marcos de referencia arquitectónicos prototípicos”, “formas comunes”, “clases de sistemas”

• Perry & Wolf, 1992 • Incluyen:

– Componentes– Conectores– Estructuras (topologías)– Restricciones (constraints)

Estilos Arquitectónicos

• Estilos de Flujo de Datos– Tubería y filtros

• Estilos Centrados en Datos– Arquitecturas de Pizarra o

Repositorio

• Estilos de Llamada y Retorno– Model-View-Controller

(MVC)– Arquitecturas en Capas– Arquitecturas Orientadas a

Objetos– Arquitecturas Basadas en

Componentes

• Estilos de Código Móvil– Arquitectura de Máquinas

Virtuales• Estilos heterogéneos

– Sistemas de control de procesos

– Arquitecturas Basadas en Atributos

• Estilos Peer-to-Peer– Arquitecturas Basadas en

Eventos– Arquitecturas Orientadas a

Servicios (SOA)– Arquitecturas Basadas en

Recursos

Estilos derivados

• C2

• GenVoca

• REST

Estilos

• Sirven para sintetizar estructuras de soluciones• Pocos estilos abstractos encapsulan una enorme

variedad de configuraciones concretas• Definen los patrones posibles de las aplicaciones,

permiten evaluar arquitecturas alternativas con ventajas y desventajas conocidas ante diferentes conjuntos de requerimientos no funcionales

Usos de estilos• Mary Shaw, David Garlan, 1996

– IEEE98SA-Styles-Patterns.pdf– Inspirado en trabajo de Parnas, 1972 (“On the criteria to be used in

decomposing systems into modules”) – Datos compartidos vs ocultamiento de información

• Sistema de indexación de palabras claves– Datos compartidos– Tipos abstractos de datos– Invocación implícita– Tubería y filtros

• Comparación de versatilidad, dependencia, modularidad, reutilización, refinamiento, ventajas & desventajas

• Antes de escribir una línea de código• Tablas de comparación de

atributos• Asignación de pesos a prioridades

Paper

Estilos arquitectónicos

Tubería y filtros

Una tubería (pipeline) es una popular arquitectura que conecta componentes computacionales (filtros) a través de conectores (pipes), de modo que las computaciones se ejecutan a la manera de un flujo. Los datos se transportan a través de las tuberías entre los filtros, transformando gradualmente las entradas en salidas. […] Debido a su simplicidad y su facilidad para captar una funcionalidad, es una arquitectura mascota cada vez que se trata de demostrar ideas sobre la formalización del espacio de diseño arquitectónico, igual que el tipo de datos stack lo fue en las especificaciones algebraicas o en los tipos de datos abstractos.

Tubería y filtros

• A.k.a. one-way data flow network• Acoplamiento cero: un filtro debe ser totalmente

independiente de otros• Fielding señala que además de los filtros hay una “mano

invisible” operando en el estilo: el sistema• [Los estilos no ocurren en el vacío: Importancia del

middleware (constraints)]• Ejemplos: UNIX,

compiladores, ambiente Khoros de procesamiento deimágenes, procesos de conversión de formatos

Tubería y filtros

• Un paso en un sistema T-F consiste en una de dos cosas:– Una transformación incremental de los datos por un filtro– Una comunicación de datos entre puertos por un tubo

• Los filtros pueden descomponerse ulteriormente, los tubos no.

• Los datos no se alteran durante su trasmisión• El orden de los datos es el mismo cuando sale de un filtro

que cuando entra al siguiente• Los tubos crean el contexto en el que operan los filtros,

pero no operan independientemente de ellos• Los tubos conectan exactamente dos puertos• Los “filtros” en realidad realizan otras operaciones; sólo

eventualmente son de filtrado

Tubería y filtros

• Variantes: PF uniforme (UNIX: input, stderr, stdout)

• Forma pura– Los filtros puros tienen poco estado interno y procesan

su input localmente.

• Forma degenerada– Los filtros consumen todo su input antes de entregar

algún output. En este caso derivan en una modalidad de proceso en lotes.

Tubería y filtros

• Ventajas:– Es simple de entender e implementar. Es posible

implementar procesos complejos con editores gráficos de líneas de tuberías o con comandos de línea.

– Lineal: la conducta del sistema es la suma de la conducta de los sucesivos filtros

– Fuerza un procesamiento secuencial.– Es fácil de envolver (wrap) en una transacción atómica.– Los filtros se pueden empaquetar, y hacer paralelos o

distribuidos.

Tubería y filtros

• Desventajas:• El patrón puede resultar demasiado simplista,

especialmente para orquestación de servicios que podrían ramificar la ejecución de la lógica de negocios de formas complicadas.

• No maneja con demasiada eficiencia construcciones condicionales, bucles y otras lógicas de control de flujo. Agregar un paso suplementario afecta la performance de cada ejecución de la tubería.

• No es posible que 2 o más filtros cooperen• Eventualmente pueden llegar a requerirse buffers de

tamaño indefinido, por ejemplo en las tuberías de clasificación de datos.

Tubería-Filtros

• Desventajas– No es apto para manejar situaciones interactivas, sobre

todo cuando se requieren actualizaciones incrementales de la representación en pantalla.

– La independencia de los filtros implica que es muy posible la duplicación de funciones de preparación que son efectuadas por otros filtros (p. ej. el control de corrección de un objeto de fecha).

– Es complicado manejar uniformemente gestión de errores en filtros diferentes.

– Generalmente fuerzan mínimo común denominador en representación de datos (texto ASCII). Si se deben procesar datos tokenizados de otra manera, se requieren parsers y serializadores específicos.

– DEMO…

Modelo-Vista-Controlador

Framework desarrollado por Trygve Reenskaug en 1970s

Modelo-Vista-Controlador

• Modelo. – Administra el comportamiento y los datos del dominio de

aplicación, responde a requerimientos de información sobre su estado (usualmente formulados desde la vista) y responde a instrucciones de cambiar el estado (habitualmente desde el controlador). Mantiene el conocimiento del sistema. No depende de ninguna vista y de ningún controlador.

• Vista. – Maneja la visualización de la información.

• Controlador. – Interpreta las acciones del ratón y el teclado, informando al

modelo y/o a la vista para que cambien según resulte apropiado.

MVC - MS

Modelo-Vista-Controlador• Variante pasiva

– Un controlador manipula el modelo exclusivamente. Luego informa a la vista que el modelo ha cambiado y debe refrescar los cambios. No hay forma en que el modelo notifique sus cambios.

– Ejemplo: HTTP. El browser responde al input del usuario, pero no se notifica de los cambios en el servidor. Sólo cuando se pide un refresco se pueden refrescar los cambios.

• Variante activa– El modelo cambia sin intervención del controlador. Ejemplos:

• Display de cotizaciones de bolsa. El modelo detecta los cambios en su estado y notifica a la vista para que refresque.

• Cambio de los menúes visibles de acuerdo con el estado del modelo.

• Variante Documento-Vista– En aplicaciones gráficas, se relaja la distinción entre vista y

controlador. • Hay documentación específica sobre implementación de

MVC en ASP.NET.

Modelo-Vista-Controlador

• Ventajas– Se pueden mostrar distintas variantes de display simultáneamente,

porque la vista no depende del modelo (ni el modelo de la vista)– La interface tiende a cambiar más rápido que las reglas de

negocios. Agregar nuevos tipos de vista no afecta al modelo.

• Desventajas– Puede aumentar un poco la complejidad de la solución. Como está

guiado por eventos, puede ser algo más difícil de depurar.– Si hay demasiados cambios en el modelo, la vista puede caer bajo

un diluvio de refrescos, a menos que se prevea programáticamente (por ejemplo, actualizando varias modificaciones en lotes)

Pizarra

Pizarra

• H. Penny Nii, 1986 (Blackboard systems)• Dos formas:

– Repositorio– Pizarra pura o tablero de control

• Procesamiento de señales• Reconocimiento de habla• Redes neuronales• Agentes débilmente acoplados• Demo: Ejemplo de pizarra con algoritmo genético

Pizarra

• Variante repositorio– Base de datos o almacenamiento persistente– Es pasivo– Los clientes accesan a datos compartidos cuando lo

requieren

• Variante pizarra propiamente dicha– Es activo– Pueden enviar notificación a suscriptores cuando la

información cambia– El estado es el disparador de la acción a ejecutar

Variante: Repositorio

• Ventajas– Forma adecuada de manejar grandes volúmenes de

datos

– Administración centralizada

• Desventajas– Los subsistemas tienen que estar de acuerdo en el

modelo de datos del repositorio

– La evolución de los datos es difícil y cara

– Difícil de distribuir con facilidad

Repositorio

• Compilador implementado sobre repositorio compartido

Máquinas de estado

• Raramente tratadas en la literatura arquitectónica• Estilo en el cual la descripción más clara del

sistema es como un conjunto de estados y transiciones

• Se ha discutido si es un estilo o una vista• Si es un estilo, debería ser posible también

describir el sistema en base a otro estilo (p. ej. analizando como es que las transiciones de estado se implementan)

Máquina virtual

Máquina virtual

• Simulan funcionalidades no nativas a hardware o software

• Un intérprete posee por lo general cuatro componentes: – una máquina de interpretación que lleva a cabo la tarea, – una memoria que contiene el seudo-código a interpretar,– una representación del estado de control de la máquina

de interpretación, y – una representación del estado actual del programa que se

simula.

Máquina virtual

• No fueron creadas con Java• Existen desde 1950

– Máquina universal de bytecodes (UNCOL)– 1968, Alan Kay: MV ligada a objetos– 1972: Kay-Ingalls, MV de Smalltalk– Scripting & lenguajes: Perl, Javascript, Windows Script

Host (WSH), Python, PHP, Pascal , Visual Basic, Tcl/Tk

– CLR: máquina virtual independiente de lenguaje

Máquina virtual

• Ventaja: simulación• Desventaja: especificidad• Ejemplos o demos:

– Lenguaje declarativo en framework procedimental.

– Uso del runtime como intérprete (previa compilación a otro lenguaje o MSIL).

– Runtime universal como MV para cualquier paradigma de lenguaje o scripting

Estilos de Llamada/Retorno

• Usualmente sincrónicos• Parámetros de llamado, argumentos de respuesta• Variantes:

– Programa principal / subrutinas– Arquitecturas RPC– Arquitecturas basadas en objetos– Arquitecturas basadas en mensajes/recursos– Arquitecturas basadas en servicios

• Ventajas– Refinamiento (descomposición funcional) es sencillo

• Desventajas (en Programa Principal / Subrutinas)– La reutilización se limita a los procedimientos

Arquitectura basada en Objetos (1/3)

• A.k.a. Abstracción de dato, tipo de datos abstractos• Deriva de Programa Principal & Subrutinas• Se ha discutido si es un estilo abstracto de arquitectura o

más bien una tecnología concreta de implementación.• Los componentes son objetos• Los conectores son procesos de invocación de

procedimientos y funciones• La comunicación es implícitamente stateful (hablando a

una instancia de objeto creada previamente)• Usualmente involucra protocolos, formatos y transportes

específicos de tecnología

Arquitectura basada en Objetos (2/3)

• La relación de herencia no es un organizador arquitectónico importante– No puede considerarse un conector– En una arquitectura podrían “heredarse” no

sólo objetos, sino conectores y estilos arquitectónicos enteros

Arquitectura basada en Objetos (3/3)

• Ventajas– Encapsulamiento, reutilización, fácil descomposición

en una colección de agentes interactivos

• Desventajas– Propagación de cambios (p. ej. nombres, data types de

argumentos) – Dependencias en cascada

• Si se cambia un objeto, se deben modificar todos los que lo invocan

– Granularidad muy fina para sistemas grandes– Usualmente, un solo valor de retorno

Otros estilos

• Arquitecturas en capas– WinDNA, OSI, XML, C2– Cliente/servidor

• Arquitecturas basadas en componentes– COM, CORBA, J2EE– COTS

• Arquitecturas basadas en eventos– Publish/subscribe

• Arquitecturas basadas en servicios (SOA)– SOAP, Web Services

Comparación

•Algunas herramientas soportan los 3 estilos a partir de unamisma meta-descripción (ej. SCOUT2 de Delta SoftwareTechnology Group http://www.d-s-t-g.com)

Arquitectura basada en eventos

• Modelo de push a veces se vincula con patrón Observador (Observer pattern)

Arquitectura basada en eventos• Ventajas

– Simplicidad– Evolución: se pueden reemplazar componentes suscriptores– Modularidad: una sola modalidad para eventos diversos– Puede mejorar eficiencia, eliminando la necesidad de polling por

ocurrencia de evento

• Desventajas– Posibilidad de desborde– Potencial imprevisión de escalabilidad– Pobre comprensibilidad: Puede ser difícil prever qué pasará en

respuesta a una acción– No hay garantía del lado del publisher que el suscriptor responderá

al evento– No hay mucho soporte de recuperación en caso de falla parcial

Arquitectura basada en eventos

• Dos modelos de arquitectura e implementación• Tightly coupled events (TCE, eventos fuertemente

acoplados)– P. ej. COM Connection Points.– Requiere que ambos componentes estén corriendo

simultáneamente. No hay forma de filtrar evento (p. ej. cuando acción alcance cierto valor)

– Requiere conocer ambas interfaces específicas• Losely coupled events (LCE, eventos débilmente

acoplados)– P. ej. COM+ Events– Almacenamiento de eventos (COM+ Catalog)– Referencia: MSDN Library – COM+ Technical Series: Losely

coupled events

Arquitectura basada en eventos

• Permiten invocación implícita de una herramienta cuando otra herramienta produce un evento

• También se llama Invocación implícita– Un componente anuncia un evento. Otros registran interés en ese

tipo de evento. Cuando se produce, el sistema (la “mano invisible”) lo comunica a los suscriptores.

• Algunos incluyen a MVC en esta clase• Modelo Publish / Subscribe• MS: Registración de Eventos COM+, eventos (listeners)

de BizTalk Server, Notification Service de SQL Server

Arquitectura basada en eventos

• Herramientas en ambiente COM+/.NET• En muchos casos no se requiere programación de

bajo nivel• También hay profusión de herramientas

programáticas y servicios de “mano mágica”• Administrative tools

– Component Services• COM+ Applications

– .NET Utilities, Biztalk Server/Interchange

Código VB.NETCrea interface de evento ILceMsg, event class, event sink & Publisher

Imports SystemImports System.IOImports System.ReflectionImports System.EnterpriseServicesImports System.Runtime.InteropServices

<assembly: ApplicationName("EventDemo")><assembly: ApplicationActivation(ActivationOption.Library)><assembly: AssemblyKeyFile("EventDemoSvr.snk")>

Namespace EventDemo Public Interface ILceMsg Sub EventMethod(message As String) End Interface <EventClass()> _ Public Class LceClass Inherits ServicedComponent Implements ILceMsg Public Sub EventMethod(message As String) implements _ ILceMsg.EventMethod End Sub End Class Public Class LceSink Inherits ServicedComponent Implements ILceMsg Public Sub EventMethod(message As String) implements _ ILceMsg.EventMethod MessageBox.Show(message, "Event sink") End Sub End Class End Namespace

Código VB.NETPublisher

Protected Sub Fire_Click(sender As Object, e As System.EventArgs)_

Handles fireEvent.Click

Dim evt As ILceMsg = CType(New LceClass(), ILceMsg)

evt.EventMethod("Hello events")

End Sub

Arquitectura en Capas

Capas - MS

Arquitectura en capas

• Resulta útil cuando se pueden identificar distintas clases de servicios que pueden ser articulados jerárquicamente.

• Puede verse como una jerarquía de máquinas virtuales cada vez más poderosas y abstractas.

• Los componentes de cada capa consisten en conjuntos de procedimientos.

• Las interacciones entre capas usualmente proceden por invocación de procedimientos.

• Por definición, los niveles de abajo no pueden usar funcionalidad ofrecida por los de arriba.

• Problema de diseño: cómo articular la funcionalidad de cada capa.

Arquitectura en capas

• Ventajas– Modularidad (hasta cierto punto)

• Desventajas– Es difícil razonar a priori sobre la separación en capas requerida– Capas disjuntas requieren drivers de otras capas– Formatos, protocolos y transportes de la comunicación entre capas

suelen ser específicos y propietarios– Algunos componentes pueden estar lógicamente vinculados con

más de una capa– En ocasiones, hay que pasar por encima de capas intermedias– Otras veces, razones de performance hace que se sitúen funciones

en las capas indebidas (lógica de negocios en procedimientos almacenados)

– La multiplicación de capas genera procesos adicionales de comunicación y coordinación

Arquitectura en capas

Abstracto Clases y objetos Específico de aplicación Tipos e instancias XML Schemas (Metadata) Elementos estructurales XML Information Set (InfoSet) Elementos y atributos XML 1.0 + Namespaces Entidades y documentos XML 1.0

Archivos y paquetes Específico de Sistema operativo o Protocolo Concreto Sectores y bitstreams Específico del hardware

Demo: Nivel de abstracción – Serialización SOAP•Alto nivel para especificación funcional

•No se requieren instrucciones de bajo nivel•Bajo nivel para implementación

Estilos heterogéneos

• Estilos naturalmente heterogéneos (Len Bass)– Locacionalmente heterogéneos: distintas partes son de

diferentes estilos– Jerárquicamente heterogéneos: Diferentes partes de un

sistema de un estilo corresponden a otro estilo: cliente/servidor

– Simultáneamente heterogéneos: Diversos estilos pueden describir el mismo sistema (una base de datos multiusuario repositorio o cliente/servidor)

• Estilos compuestos– C2– GenVoca– REST

C2

• Estilo basado en componentes y mensajes para sistemas altamente distribuidos, heterogéneos, con fuerte participación de interface usuario– Más tarde, estilo de propósito general

• Arquitecturas C2 son redes de componentes concurrentes enganchados por conectores– No hay conexiones componente a componente– Todas las comunicaciones por intercambio de

mensajes a través de buses• Objetivo de reutilización de componentes

y conectores

C2

• La literatura no señala desventajas• Combina estilo basado en eventos con arquitectura en

capas• Cada componente tiene 2 puntos de conexión

(interfaces), top & bottom• El top (bottom) de un componente sólo se puede ligar

al bottom (top) de sólo un bus.• No es posible tener ciclos. Un componente no puede

recibir un mensaje generado por él mismo.

C2

• Un componente puede enviar eventosde request al bus por encima, y eventos de notificación al bus por debajo.

• Cuando un componente recibe un request desde abajo, lo pasa a todos los componentes y buses por encima que pueden manipularlo– En tiempo de instanciación, cada componente comunica al bus de

abajo los requests que puede manejar

• Cuando un bus recibe una notificación desde arriba, la comunica a los componentes y buses que tiene por debajo.

C2

• ATM

GenVoca

• Batory & O’Malley, 1992• Estilo independiente de dominio, de composición

jerárquica– Componentes intercambiables– Reutilización en gran escala

• Paradigma “Lego” de diseño y composición de sistemas• Extrapolado de sistemas en 2 dominios bien entendidos

– Avoca – Suites de software de red– Genesis - DBMS

GenVoca

• Componente: cluster de clases estrechamente intervinculadas

• Ambito (Realm): conjunto de componentes que realizan:– La misma interface de diferentes maneras– Diferentes conductas– Diferentes implementaciones– Componentes en un ámbito son plug-compatibles

• Arquitectura (sistema) es una expresión de tipos:– Composición de componentes– Interconexiones implícitas en parámetros– Composición jerárquica es posible

GenVoca

• Los ámbitos y sus componentes definen una gramática cuyas frases son aplicaciones

• El conjunto de todas las frases define un lenguaje• El conjunto de todas las composiciones de

componentes define una línea de productos• Agregar un nuevo componente al ámbito equivale

a agregar una nueva regla a la gramática

GenVoca

• Los componentes se comunican por llamado directo

• No hay soporte de multicast ni invocación implícita

• No hay soporte para concurrencia• No hay soporte para interacciones heterogéneas

– Hay que reformular componentes para incluirlos en GenVoca

Estilo REST• REST - REpresentational State Transfer (Roy Fielding, 2000)

• SOA sin Web Services, ni SOAP ni RPC

• Arquitectura con modelo de datos (recursos, URIs y representaciones XML)

• Composición de diversos estilos: repositorio replicado, cache, cliente-servidor, sistema en capas, sistema sin estado, máquina virtual, código a demanda e interfaz uniforme

Modelo REST

• Una aplicación REST transfiere representaciones entre componentes usando conectores

• Componentes: incluyen agentes de usuario (Mozilla, cURL) y servidores de origen (Apache, IIS)

• Los componentes de REST obedecen estas restricciones:– las interaciones son stateless– los recursos se identifican mediante URIs– no hay tal cosa como servicios ni objetos, sólo recursos– no se permite el paso de cookies y se propone el reemplazo de MIME

(Multipurpose Internet Mail Extensions) por su discrepancia arquitectónica con la semántica de HTTP

– hypermedia es la máquina de estado de la aplicación

– no hay necesidad de toolkits: sólo URIs y XML

SOAP versus REST

• Polémica sobre el estilo dominante en SOA.– Abundancia de pullas:

• “Give SOAP a REST” - “Otra vez SOAP” - “REST could burst the SOAP bubble”, “Slippery SOAP”

– REST enfatiza el papel de los intermediarios: caches, proxies, gateways, etc

– REST es adecuado para transferencias y transformaciones simples. Transacciones complejas requieren sin duda SOAP.

– No hay herramientas para implementar REST rigurosamente; sí en cambio las hay para SOAP RPC.

– Idem en relación con middlewares

SOAP vs REST

– 80 implementaciones independientes de SOAP 1.1 en 2002

– ebXML adoptó SOAP como protocolo de base– SOAP incorporó ideas de ebXML a través de WS-*

• Integridad de mensajes, no-repudio, mensajería confiable, flujo de procesos de negocios, negociación de protocolos

– SOAP puede alcanzar mejor performance porque puede ser stateful y no tiene que trasmitir información de estado.

SOAP vs REST

• A la larga el comité de WSA en W3C no optó entre REST y SOAP, sino que reformuló SOAP 1.2 adoptando ideas de REST

• “Intercambio asincrónico de documentos” ha ganado mindshare a expensas de “RPC”

• “Web services como objetos distribuidos” tiene cada vez menos adeptos

• DTD y tecnologías similares han sido eliminadas– Documentos específicos en bibliografía del CD

Arquitecturas Orientadas a Servicios (SOA)

• Presentación separada…

Patterns

• Christopher Alexander, 1977• Un patrón es una solución a un problema en

un contexto• Un patrón codifica conocimiento específico

acumulado por la experiencia en un dominio

• Un sistema bien estructurado está lleno de patrones

Patterns

• Los patrones se organizan en lenguajes de patrones (o conjuntos estructurados)– Conjunto de patrones relacionados que describen de

qué manera y bajo qué circunstancias se relacionan problemas con sus soluciones.

– La organización de los patrones en un lenguaje encarna una perspectiva específica sobre el tema: específicamente, de qué forma un problema se divide en problemas más pequeños.

Patterns - Alexander

• “Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de tal manera que puedes usar esa solución un millón de veces más, sin hacer jamás la misma cosa dos veces.”

• Ejemplos: galería, paseo, patio compartido, columnata, estacionamiento

Clases de Definiciones[Informales]

• A la moda: “Tópico caliente” muy actual, montones de “hype”, buzzword de OOD.

• Literaria: Forma de ingeniería de documentación de resolución de problemas en ingeniería de software

• Pragmática: Describe soluciones prácticas a problemas “de la vida real”

• Recurrente: Identifica buenas estructuras de diseño que recurren en la práctica

• Generativa: Muestra cómo/cuándo aplicar la solución, y genera la estructura de diseño deseada

• Emergente: Grandes soluciones emergen indirectamente de aplicar patrones en sucesión y de concertarlos todos juntos.

Definiciones

• Una abstracción de una forma concreta que aparece recurrentemente en contextos específicos, no arbitrarios.

• Una solución recurrente a un problema común en un contexto determinado, y un sistema de fuerzas. [Alexander]

• Una “gema” de insight instructivo con un nombre, que encapsula la esencia de una solución probada a un problema recurrente en un contexto dado, en medio de preocupaciones en competencia mutua.

• Una “best practice” exitosamente recurrente que se ha probado satisfactoriamente “en el campo”.

• Una forma literaria de capturar la sabiduría y experiencia de los diseñadores expertos, y de comunicarla a los novicios.

Historia

• Christopher Alexander, 1977• Literate programming (Don Knuth), ca. 1984 • Kent Beck and Ward Cunningham, Tektronix,

OOPSLA'87 (uso ideas de los “patterns” de Alexander para el diseño del GUI de Smalltalk)

• Erich Gamma, Ph. D. thesis, 1988-1991 • James Coplien, Advanced C++ Idioms libro, 1989-1991 • Gamma, Helm, Johnson, Vlissides ("Gang of Four")

Object-Oriented Design Patterns, 1991-1994 • POSA 1, 1996…

Elementos de un patrón• Nombre

– Define un vocabulario de diseño– Facilita abstracción

• Problema– Describe cuando aplicar el patrón– Conjunto de fuerzas: objetivos y restricciones– Prerrequisitos

• Solución– Elementos que constituyen el diseño (template)– Forma canónica para resolver fuerzas

• Consecuencias– Resultados, extensiones y tradeoffs

Architectural Patterns (1/2)

• POSA – Frank Buschmann, Regine Meunier, Hans Rohner, Peter Sommerlad, Michael Stal. 1996

• ”expresa un esquema de estructuración fundamental para los sistemas de software. Proporciona un conjunto de subsistemas predefinidos, especifica sus responsabilidades e incluye reglas y lineamientos para organizar las relaciones entre ellos."

• 79 patrones arquitectónicos en The Patterns Almanac

Architectural Patterns (2/2)

- Architectural patterns• Esquemas de organización fundamentales para el

software

– Design patterns• Estructuras comúnmente recurrentes de componentes

en comunicación que resuelven un problema general de diseño

– Idioms• Patrones específicos de bajo nivel específicos de un

lenguaje de programación

Gof5 (POSA) Patterns

• Arquitectónicos– Pipes & filter– Blackboard– Microkernel– Capas – Sistemas distribuidos– Broker

• Diseño– Todo-Parte (descomposión estructural)– Master-slave (organización de trabajo)– Proxy– Command processor

• Idioms– Singleton

GOF – Design Patterns (textual)Abstract Factory– Provide an interface for creating families of related or

dependent objects without specifying their concrete classes.

• Adapter– Convert the interface of a class into another interface

clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

• Bridge– Decouple an abstraction from its implementation so that

the two can vary independently.

GOF – Design Patterns (textual)• Decorator

– Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

• Facade– Provide a unified interface to a set of interfaces in a

subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

• Factory Method– Define an interface for creating an object, but let subclasses

decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

GOF – Design Patterns (textual)

Observer– Define a one-to-many dependency between objects so that when one

object changes state, all its dependents are notified and updated automatically.

• Prototype– Specify the kinds of objects to create using a prototypical instance, and

create new objects by copying this prototype.

• Proxy– Provide a surrogate or placeholder for another object to control access to it.

• Singleton• Ensure a class only has one instance, and provide a global point of access

to it.

Comentario Problemas Soluciones Fase de Desarrollo

Patrones de Arquitectura

Relacionados a la interacción de objetos dentro o entre niveles arquitectónicos

Problemas arquitectónicos, adaptabilidad a requerimientos cambiantes, performance, modularidad, acoplamiento

Patrones de llamadas entre objetos (similar a los patrones de diseño), decisiones y criterios arquitectónicos, empaquetado de funcionalidad

Diseño inicial

Patrones de Diseño

Conceptos de ciencia de computación en general, independiente de aplicación

Claridad de diseño, multiplicación de clases, adaptabilidad a requerimientos cambiantes, etc

Comportamiento de factoría, Clase-Responsabilidad-Contrato (CRC)

Diseño detallado

Patrones de Análisis

Usualmente específicos de aplicación o industria

Modelado del dominio, completitud, integración y equilibrio de objetivos múltiples, planeamiento para capacidades adicionales comunes

Modelos de dominio, conocimiento sobre lo que habrá de incluirse (p. ej. logging & reinicio)

Análisis

Patrones de Proceso o de Organización

Desarrollo o procesos de administración de proyectos, o técnicas, o estructuras de organización

Productividad, comunicación efectiva y eficiente

Armado de equipo, ciclo de vida del software, asignación de roles, prescripciones de comunicación

Planeamiento

IdiomasEstándares de codificación y proyecto

Operaciones comunes bien conocidas en un nuevo ambiente, o a través de un grupo. Legibilidad, predictibilidad.

Sumamente específicos de un lenguaje, plataforma o ambiente

Implementación, Mantemimiento, Despliegue

Extensiones

• Anti-patterns (Brown & al)

• Refactoring (Opdyke, Fowler)

• Patrones en métodos

• Patrones de organización (Coplien)

• Patrones de management

• Organización de patrones

Organización de Patrones

• Propuesta por MS para Enterprise Solution Patterns Using Microsoft .NET (ESP)

• Propósito:– Identificar relaciones entre patrones– Agrupar patrones en clusters– Identificar patrones a diversos niveles de abstracción– Aplicar patrones a múltiples aspectos de una solución– Organizar patrones en un frame– Usar patrones para describir en forma concisa una

solución…

Ejemplos de ESP

Niveles de abstracciónVistas

Frame

Documento

Ventajas y desventajas

• Ventajas– Conceptualización de grano más grueso y semántica

más rica que la de objetos abstractos– Diseño y desarrollo modular

• Desventajas– Excesiva proliferación requiere elementos de más alto

nivel– Muy lejos todavía del modelo “Lego” (Garlan)– Más bien se parece a un juego de muchos tipos de

piezas sin garantía que encajen totalmente– Sesgados hacia OOP / OOD

Observación

• Philippe Kruchten en The Rational Edge, Abril 2001:• "Architecture is an art."• Whoa. Let's not fool ourselves. Some architects may like

to portray themselves as magicians: "Hire me. I'll look at your project, retreat onto my mountain, levitate for a while in trance, then come down with the solution." The artistic, creative part of software architecture is usually very small. Most of what architects do is copy solutions that they know worked in other similar circumstances, and assemble them in different forms and combinations, with modest incremental improvements.

Referencias

• Carlos Billy Reynoso. “Estilos y patrones en la estrategia arquitectónica de Microsoft”. Http://www.microsoft.com/spanish/msdn/arquitectura, 2003.

• Len Bass, Paul Clements y Rick Kazman. Software Architecture in Practice. Reading, Addison-Wesley, 1998. [Hay edición reciente]

• Roy Thomas Fielding. “Architectural styles and the design of network-based software architectures”. Tesis doctoral, University of California, Irvine, 2000.

• David Garlan. “What is style”. Proceedings of Dagshtul Workshop on Software Architecture. Febrero de 1995.

• Mary Shaw y Paul Clements. “A field guide to Boxology: Preliminary classification of architectural styles for software systems”. Documento de Computer Science Department and Software Engineering Institute, Carnegie Mellon University. Abril de 1996. Publicado en Proceedings of the 21st International Computer Software and Applications Conference, 1997.

Referencias

• Christian Thilmany. .NET Patterns: Architecture, design and process. Addison Wesley, 2003. [disponible]

• Documentación exhaustiva sobre estilos en CD del curso, incluyendo todos los papers de dominio público.

Call to action

• Profundizar en la descripción de estilos individuales en la bibliografía suministrada

• Vincular patrones de arquitectura con estilos.• Vincular ambos con tácticas arquitectónicas según las

metodologías del SEI.• Establecer el papel de los estilos y patrones de arquitectura

en las disciplinas de MSF 3.0.• Analizar específicamente patrón (estilo) de arquitectura en

capas en la descripción de MS.• Prever lo mismo para Arquitecturas Orientadas a Servicios.

¿Preguntas?

http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/arquitectura_soft.mspx

Billyreyno@hotmail.comhttp://carlosreynoso.com.ar