estilos en arquitectura de software carlos reynoso universidad de buenos aires...
TRANSCRIPT
Estilos en Arquitectura de Software
Carlos ReynosoUNIVERSIDAD DE BUENOS AIRES
[email protected]://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
[email protected]://carlosreynoso.com.ar