Estilos en Arquitectura de Software

Presentación del tema: "Estilos en Arquitectura de Software"— Transcripción de la presentación:

1 Estilos en Arquitectura de Software
Carlos Reynoso UNIVERSIDAD DE BUENOS AIRES

2 Temario Estilos en Arquitectura de Software Patrones Conclusiones
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

3 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)

4 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

5 Estilos derivados C2 GenVoca REST

6 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

7 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

8 Estilos arquitectónicos

9 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.

10 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 de imágenes, procesos de conversión de formatos

11 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

12 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.

13 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.

14 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.

15 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…

16 Modelo-Vista-Controlador
Framework desarrollado por Trygve Reenskaug en 1970s

17 Modelo-Vista-Controlador
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

18 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.

19 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)

20 Pizarra

21 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

22 Pizarra Variante repositorio Variante pizarra propiamente dicha
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

23 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

24 Repositorio Compilador implementado sobre repositorio compartido

25 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)

26 Máquina virtual

27 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.

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 Comparación Algunas herramientas soportan los 3 estilos a partir de una misma meta-descripción (ej. SCOUT2 de Delta Software Technology Group

36 Arquitectura basada en eventos
Modelo de push a veces se vincula con patrón Observador (Observer pattern)

37 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

38 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

39 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

40 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

41 Código VB.NET Crea interface de evento ILceMsg, event class, event sink & Publisher
Imports System Imports System.IO Imports System.Reflection Imports System.EnterpriseServices Imports 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 MessageBox.Show(message, "Event sink") End Namespace

42 Código VB.NET Publisher
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

43 Arquitectura en Capas Capas - MS

44 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.

45 Arquitectura en capas Ventajas Desventajas
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

46 Arquitectura en capas 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

47 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

48 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

49 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.

50 C2 Un componente puede enviar eventos de 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.

51 C2 ATM

52 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

53 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

54 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

55 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

56 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

57 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

58 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

59 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.

60 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

61 Arquitecturas Orientadas a Servicios (SOA)
Presentación separada…

62 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

63 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.

64 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

65 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.

66 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.

67 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, James Coplien, Advanced C++ Idioms libro, Gamma, Helm, Johnson, Vlissides ("Gang of Four") Object-Oriented Design Patterns, POSA 1, 1996…

68 Elementos de un patrón Nombre Problema Solución Consecuencias
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

69 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

70 Architectural Patterns (2/2)
• 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

71 Gof5 (POSA) Patterns Arquitectónicos Diseño Idioms 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

72 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.

73 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.

74 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.

75

76 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 Idiomas Está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

77 Extensiones Anti-patterns (Brown & al) Refactoring (Opdyke, Fowler)
Patrones en métodos Patrones de organización (Coplien) Patrones de management Organización de patrones

78 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…

79 Ejemplos de ESP Niveles de abstracción Vistas Documento Frame

80 Ventajas y desventajas
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

81 Observación "Architecture is an art."
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.

82 Referencias Carlos Billy Reynoso. “Estilos y patrones en la estrategia arquitectónica de Microsoft” Len Bass, Paul Clements y Rick Kazman. Software Architecture in Practice. Reading, Addison-Wesley, [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 Publicado en Proceedings of the 21st International Computer Software and Applications Conference, 1997.

83 Referencias Christian Thilmany. .NET Patterns: Architecture, design and process. Addison Wesley, [disponible] Documentación exhaustiva sobre estilos en CD del curso, incluyendo todos los papers de dominio público.

84 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.

85 Billyreyno@hotmail.com http://carlosreynoso.com.ar
¿Preguntas?