Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones APU. Adriana Sandra Almeira APU. Vanina Perez Cavenago Directora: Mg. Zulema Beatriz Rosanigo Tesina presentada a la Facultad de Ingeniería de la Universidad Nacional de la Patagonia San Juan Bosco como parte de los requisitos para la obtención del título Licenciatura en Informática. Trelew, Marzo 2007 Facultad de Ingeniería Universidad Nacional De La Patagonia San Juan Bosco Argentina

A nuestras familias por el apoyo incondicional durante la realización de la presente tesina. A Mg. Zulema Beatriz Rosanigo por su dirección, incentivo y paciencia a lo largo del desarrollo de este trabajo. Adriana Sandra Almeira Vanina Perez Cavenago

Resumen La temática más exitosa en arquitectura de software en los últimos tiempos es, sin lugar a dudas, la de los estilos y patrones, tanto en lo que concierne a los patrones arquitectónicos como a patrones de diseño. En este trabajo se trata una aplicación que, de un modo didáctico, sirva para la comprensión y utilización tanto de patrones arquitectónico como patrones de diseño de forma clara y correcta en la construcción de software. El proyecto está dividido en dos partes fundamentales, una introducción teórica a la Arquitectura de Software, Estilos, Patrones Arquitectónicos y Patrones de Diseño y un caso práctico donde se plasma el análisis y aplicación de dichos patrones. Pag ii

Índice CAPÍTULO 1...1 INTRODUCCIÓN... 1 Objetivos... 1 Organización del texto... 2 CAPÍTULO 2...3 ARQUITECTURA DE SOFTWARE... 3 Qué son los patrones?... 4 Origen e historia de patrones... 5 Estilos Arquitectónicos... 6 Estilo Vs Patrones... 7 Lenguajes de Descripción Arquitectónicas... 7 Framework... 8 CAPÍTULO 3...9 PATRONES... 9 Clasificación de Patrones según la naturaleza del problema... 9 Características de un buen patrón...10 Esquema de un patrón...11 Categorías de Patrones...13 Patrones Arquitectónicos...13 Patrones de Diseño...14 Idioms...15 CAPÍTULO 4...16 PATRONES ARQUITECTÓNICOS...16 Del Fango a la Estructura...16 Layers...17 Pipes and Filters...20 Blackboard...23 Sistemas Distribuidos...27 Broker...28 Sistemas Interactivos...33 Model-View-Controller...34 Presentation-Abstraction-Control...38 Sistemas Adaptables...42 Microkernel...43 Reflection...47 CAPÍTULO 5...52 PATRONES DE DISEÑO...52 Patrones de Creación...52 Abstract Factory...52 Builder...54 Prototype...56 Patrones Estructurales...58 Adapter...58 Bridge...60 Composite...61 Proxy...63 Patrones de Comportamiento...64 Template Method...65 Pag iii

Observer...66 Command...67 State...68 Strategy...70 Null Object...71 Type Object...73 Decorador...76 CAPÍTULO 6...79 CASO DE ESTUDIO: SISTEMA DE CHEQUES...79 Participantes...79 Esquema Operativo...80 Definición del Sistema...81 Circuito de Cheques...81 Circuito de Imágenes por Rechazo...82 Circuito de Imágenes por Reclamos...83 Limites del sistema...83 Visión Arquitectónica...84 CAPÍTULO 7...85 APLICACIÓN DE PATRONES...85 Análisis...85 Modelo de casos de uso...89 Diseño...92 El Modelo Arquitectónico...92 El Componente Modelo...100 Depósito de Cheques...103 Recepción de Cheques...105 Reclamos de Cheques...107 Los Componentes Vista y Controlador...108 CAPÍTULO 8...110 CONCLUSIONES Y TRABAJOS FUTUROS...110 Conclusiones...110 Contribuciones...110 Trabajos futuros...110 BIBLIOGRAFÍA...112 Pag iv

Tabla de Figuras Figura 3.1 - Categoría de Patrones según el tipo de problemas...10 Figura 3.2 - Esquema de tres partes : contexto problema - solución...12 Figura 4.1 - Clase de la capa J...18 Figura 4.2 - Esquema de estructuración en capas...18 Figura 4.3 - Esquema del protocolo de red OSI...20 Figura 4.4 - Clases Pipe y Filter...22 Figura 4.5 - Clases Repositorio y Fuente de datos...22 Figura 4.6 - Estructura Patrón Pipe and Fliter...22 Figura 4.7 - Clases Blackboard y Fuente de Conocimiento...25 Figura 4.8 - Clases Control...25 Figura 4.9 - Estructura del Patrón Arquitectónico Blackboard...26 Figura 4.10 - Clases Cliente y Servidor...30 Figura 4.11 - Clase Broker...30 Figura 4.12 - Clases Proxy del lado del Cliente y Proxy del lado del Servidor...31 Figura 4.13 - Clase Bridge...31 Figura 4.14 - Estructura del patrón Broker...32 Figura 4.15 - Clase Modelo...36 Figura 4.16 - Clases Controlador y Vista...36 Figura 4.17 - Estructura del Patrón MVC...36 Figura 4.18 - Clases de los Agentes PAC....40 Figura 4.19 - Integración de clases de los Agentes PAC....41 Figura 4.20 - Clase Microkernel...44 Figura 4.21 - Clase Servidor Interno...44 Figura 4.22 - Clase Servidor Externo...45 Figura 4.23 - Clases Cliente y Adapter...45 Figura 4.24 - Estructura de un sistema Microkernel...45 Figura 4.25 - Clases Nivel Base y Meta Nivel...49 Figura 4.26 - Clase Protocolo Metaobjeto...49 Figura 4.27 - Clase Protocolo Metaobjeto...50 Figura 5.1 - Patrón de Diseño Abstract Factory...53 Figura 5.2 - Patrón de Diseño Builder...55 Figura 5.3 - Patrón de Diseño Prototype...57 Figura 5.4 - Patrón de Diseño Adapter...59 Figura 5.5 - Patrón de Diseño Bridge...60 Figura 5.6 - Patrón de Diseño Composite...62 Figura 5.7 - Patrón de Diseño Proxy...64 Figura 5.8 - Patrón de Diseño Template Method...65 Figura 5.9 - Patrón de Diseño Observer...66 Figura 5.10 - Patrón de Diseño Command...68 Figura 5.11 - Patrón de Diseño State...69 Figura 5.12 - Patrón de Diseño Strategy...70 Figura 5.13 - Patrón de Diseño Null Object...72 Figura 5.14 - Estructura del patrón de diseño Type Object...74 Figura 5.15 - Estructura del patrón de diseño Decorador...77 Figura 6.1 - Esquema a gran escala...80 Figura 6.2 - Esquema dentro de cada una de las entidades...80 Figura 6.3 - Esquema dentro de cada una de las entidades...82 Figura 6.4 - Circuito de Imágenes por rechazo...82 Figura 6.5 - Circuito de Imágenes por reclamo...83 Figura 7.1 - Circuito de Depósito de Cheques...86 Figura 7.2 - Circuito de Reclamos de Cheques...88 Figura 7.3 - Diagrama de casos de uso...91 Figura 7.4 - Patrón Broker...92 Figura 7.5 - Patrón Broker...92 Figura 7.6 - Patrón Layers...93 Figura 7.7 - Integración del patrón Broker, Model-View-Controller y Layers...93 Figura 7.8 - Diagrama de clases del patrón Broker...94 Figura 7.9 - Distribución de los componentes del patrón Broker...94 Pag v

Figura 7.10 - Diagrama de secuencia de la interacción entre componentes...95 Figura 7.11 - Diagrama de clases del patrón Model-View-Controller...97 Figura 7.12 - Distribución de los componentes del patrón Model-View-Controller...97 Figura 7.13 - Diagrama de secuencia para la conexión de un usuario al sistema...98 Figura 7.14 - Integración del patrón Broker, Model-View-Controller y Layers....99 Figura 7.15 - Estructura de Capa de Servicio, Capa de Acceso a Datos y Base de Datos...100 Figura 7.16 - Componentes del Modelo...101 Figura 7.17 - Clase Sucursal...101 Figura 7.18 - Clase Cuenta...101 Figura 7.19 - Clase Cheque...102 Figura 7.20 - Clase ChequeOtraSucursal....102 Figura 7.21 - Aplicación Patrón Decorator...103 Figura 7.22 - Depósito de Cheques...105 Figura 7.23 - Recepción de Cheques...106 Figura 7.24 - Aplicación del Patrón State en el Componente Recepción de Cheques...107 Figura 7.25 - Patrón Observer...109 Pag vi

Capítulo 1 Introducción El proceso del desarrollo de sistemas de software ha ido en aumento en los últimos años, demandando la construcción de grandes y complejos sistemas que requieren la combinación de diferentes tecnologías y plataformas de hardware y software para alcanzar la funcionalidad requerida. El diseño e implementación ha pasado de una concepción monolítica y uniforme a una visión heterogénea y distribuida. El proceso de desarrollo se ha ido convirtiendo poco a poco en una labor de ingeniería, poniendo de manifiesto la relevancia de un estudio específico de la estructura del software. Actualmente la elaboración de especificaciones, el diseño del sistema, construcción de prototipos, integración y pruebas, forman parte de la Ingeniería del Software respondiendo a la creación de nuevos modelos, notaciones, técnicas y métodos. Dentro de esta orientación se enmarca el creciente interés al estudio, análisis y descripción de la estructura del software dando lugar a aspectos arquitectónicos del mismo. Estos aspectos se refieren a todo lo relativo a la estructura de alto nivel de los sistemas: su organización en subsistemas y la relación entre ellos; la construcción de aplicaciones con reutilización de otras existentes y desarrollo de productos que presentan una arquitectura común. En consecuencia, el modelado de una arquitectura a nivel conceptual permite al diseñador decidir cuestiones que tendrán influencia a lo largo de todo el ciclo de vida de la aplicación. Para diseñar una arquitectura de software podemos partir con patrones de soluciones ya probados que han funcionado. El objetivo que se persigue con el uso de los patrones dentro del mundo del desarrollo de software es establecer un catálogo de referencia para ayudar a los ingenieros de software a solucionar problemas de ingeniería de software dando lugar a un lenguaje común con el cual comunicar la experiencia entorno a dichos problemas y a su solución. Objetivos El propósito de la presente tesina es reunir y analizar la información necesaria sobre la teoría de estilos, patrones arquitectónicos y patrones de diseño, la diversidad de los mismos y la forma de conjugar éstos según la naturaleza de la problemática a resolver facilitando el desarrollo de aplicaciones manejables, extensibles, fáciles de modificar, mantener y reusar. En particular se tomará como caso de estudio, una aplicación bancaria que aborda la operatoria que realizan los bancos para la gestión de cobro de cheques a través de la captura descentralizada de los mismos en las sucursales de las entidades depositarias y la centralización de la información en un repositorio común. Pag 1

Finalmente se propondrá un modelo de arquitectura para este caso de estudio, utilizando adecuadamente patrones que faciliten las posibilidades de reuso y de extensión. Organización del texto La presente tesina se organiza de la siguiente manera: En el capítulo 2 se define la Arquitectura de Software, la importancia dentro del ciclo de vida del sistema de software, y el rol que juegan los estilos y patrones, introduciendo principios y conceptos básicos. El capítulo 3 expone la clasificación de los patrones según la naturaleza del problema definiendo el esquema de un patrón, características y la categorización de acuerdo a su nivel de abstracción. El capítulo 4 describe los patrones arquitectónicos en sus diferentes categorías definiendo su trilogía contexto-problema-solución, los beneficios y desventajas que reportan en su implementación. Algunos ejemplos de patrones arquitectónicos de [Buschamann+96] son utilizados para ilustrar las diferentes categorías. El capítulo 5 introduce los conceptos de patrones de diseño, su aplicabilidad en la resolución de problemas, como interactúan sus componentes y las ventajas y desventajas que conlleva su uso. Algunos ejemplos de patrones de diseño de [Gamma+95] ilustran las distintas categorías presentadas. El capítulo 6 presenta el caso de estudio. Se detallan los lineamientos fundamentales de la operatoria que deben realizar los Bancos para la implementación de un sistema en la gestión de cobro de Cheques. Se define el sistema con los correspondientes circuitos y limites. El capítulo 7 analiza y diseña conceptos del sistema. En la sección de análisis se detallan los circuitos de las diferentes operatorias, ayudando a identificar los distintos casos de uso que forman parte del sistema. En la sección de diseño, se toman los temas tratados en los capítulos anteriores, y con ellos se logra la aplicación de los patrones, evaluando entre las distintas alternativas de patrones frente a una problemática común. Como resultado se obtiene el modelado de una alternativa de solución, pasando por diferentes niveles de abstracción, desde la general, el sistema como un todo, a lo particular, resolviendo detalles de diseño para pequeños problemas específicos. El capítulo 8 presenta las conclusiones y futuros trabajos. Pag 2

Capítulo 2 Arquitectura de Software Hoy en día las organizaciones hacen uso de sistemas de software complejos, de gran tamaño y combinando distintas tecnologías y plataformas de hardware. Esto exige a los desarrolladores de software diseñar muy cuidadosamente la arquitectura bajo la cual funcionan sus sistemas, ya que las decisiones que se tomen tendrán gran influencia a lo largo de todo el ciclo de vida de la aplicación. Si bien no hay una definición oficial de Arquitectura de Software, podemos decir que abarca todo lo relativo a la estructura de alto nivel de los sistemas: su organización en subsistemas y la relación entre ellos. Según David Garlan la Arquitectura de Software establece un puente entre el requerimiento y el código. A su vez el documento de IEEE Std 1471-2000 define: La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. Otra definición reconocida es la aportada por Clements: La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar el objetivo del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de compresión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones. Es decir, la arquitectura brinda una visión global del sistema. Esto permite entenderlo, organizar su desarrollo, plantear la reutilización del software y hacerlo evolucionar. Se puede ver que la noción clave de la arquitectura es la organización y está relacionada con aspectos de rendimiento, usabilidad, reutilización, limitaciones económicas y tecnológicas. La arquitectura de software también se relaciona con el diseño, pues, es una forma de diseño de software que se manifiesta tempranamente en el proceso de creación de un sistema. La arquitectura se encuentra en un nivel de abstracción por encima del diseño de software que se concentra en el modelado de abstracciones de más bajo nivel. Las interacciones entre componentes en la arquitectura están en relación con un protocolo de alto nivel, mientras que las del diseño conciernen a interacciones de tipo procedural. A medida que la arquitectura de alto nivel se refina, sus puntos de conexión pierden grado de abstracción, distribuyéndose así a través de los elementos arquitectónicos de más bajo nivel, resultando en la transformación de la arquitectura en diseño. La arquitectura es algo más integrado que la suma del análisis por un lado y el diseño por el otro. Ésta se ocupa de componentes y no de procedimientos; de las interacciones entre esos componentes y no de las interfaces; de las restricciones a ejercer sobre los componentes y las interacciones y no de los algoritmos, los procedimientos y los tipos. Pag 3

La Arquitectura de Software debe representar distintos aspectos del software. Por lo general, cada uno de estos aspectos se describe en forma más comprensible si se utilizan diversos modelos o vistas. Se debe destacar que cada uno de ellos establece una descripción parcial de la misma arquitectura y es deseable que exista cierto solapamiento entre ellos, ya que todas las vistas deben ser coherentes entre sí, dado que están describiendo la misma cosa. Cada paradigma de desarrollo exige vistas, de las cuales, hay por lo menos tres que son esenciales en cualquier arquitectura: - La visión estática: describe cuáles son los componentes de la arquitectura. - La visión funcional: describe qué hace cada componente. - La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí. Las vistas de una arquitectura pueden formularse por medio de uno o varios lenguajes. El más obvio es el lenguaje natural, pero también existen otros como los diagramas de estado, los diagramas de flujo de datos, etc.. Existe cierta aceptación en el uso de UML (Unified Modeling Language, lenguaje unificado de modelado) como único lenguaje para todos los modelos o vistas. Según Sahw y Garlan existen un conjunto de propiedades que se deben especificar como parte del diseño arquitectónico: - Propiedades estructurales. Este aspecto de la representación del diseño arquitectónico define los componentes de un sistema y la forma en que se empaquetan e interactúan unos con otros. - Propiedades extra-funcionales. La descripción del diseño arquitectónico debería ocuparse de cómo consigue la arquitectura del diseño los requisitos de rendimiento, capacidad, fiabilidad, seguridad, adaptabilidad y otras características del sistema. - Familias de sistemas relacionados. El diseño arquitectónico debería tener la capacidad de utilizar bloques de construcción arquitectónica reutilizados. Según la especificación de estas propiedades, el diseño arquitectónico puede representarse usando uno o más modelos diferentes. Los modelos estructurales representan la arquitectura como una colección organizada de componentes de programa. Los modelos estructurales aumentan el nivel de abstracción de diseño intentando identificar estructuras de diseño arquitectónico repetibles (patrones) que se pueden encontrar en tipos similares de aplicaciones. Qué son los patrones? Los patrones son una disciplina de resolución de problemas en la ingeniería del software que ha surgido con mayor énfasis en la comunidad de orientación a objetos, aunque pueden ser aplicados en cualquier ámbito de la informática y las ciencias en general. El arquitecto Christopher Alexander define el término patrón de la siguiente manera: Pag 4

Cada patrón es una regla de 3 partes, que expresa una relación entre un contexto, un problema y una solución. Como un elemento en el mundo, cada patrón es una relación entre un contexto, un sistema de fuerzas que ocurren repetidamente en ese contexto y una configuración espacial que permite que esas fuerzas se resuelvan entre sí. Como elemento de un lenguaje, un patrón es una instrucción que muestra como puede ser usada esta configuración espacial una y otra vez para resolver el sistema de fuerzas, siempre que el contexto lo haga relevante. Si bien Christopher Alexander aplicó los patrones originalmente a la construcción, también puede aplicarse al software. Los patrones de software permiten que se reutilice tanto el diseño como la arquitectura, adoptando estructuras estáticas y dinámicas de soluciones exitosas en la solución de nuevos problemas. Esto nos lleva a citar una frase del libro Pattern Oriented Software Architecture, Volumen 1 [Buschmann+96]: Los patrones ayudan a construir sobre la experiencia colectiva de ingenieros de software experimentados. Estos capturan la experiencia existente y que ha demostrado ser exitosa en el desarrollo de software, y ayudan a promover las buenas prácticas de diseño. Cada patrón aborda un problema específico y recurrente en el diseño o implementación de un software. Las técnicas generales para la arquitectura de software no apuntan a la solución de problemas específicos. Varios de los métodos existentes de análisis y diseño fallan a este nivel, ya que solamente proveen técnicas generales para construir software. La creación de arquitecturas específicas sigue basada en la intuición y experiencia. Los patrones son bloques de construcción mental útiles para proceder con aspectos de diseño limitados y específicos en el momento del desarrollo de un sistema de software, su concepto dominante es la reutilización. Origen e historia de patrones En la década del 90 fue la época del surgimiento de los patrones, definidos en dos orientaciones diferentes, las cuales fueron plasmadas en dos libros fundamentales sobre el tema, Design Patterns escrito por la Banda de los Cuatro (GoF) 1 [Gamma95] en 1995 y el libro Pattern-Oriented Software Architecture, A System of patterns 2 de la serie POSA [Buschmann+96] en 1996. El primero de ellos presenta un conjunto de patrones de diseño de software bajo el paradigma de la orientación a objetos, mientras que el segundo despliega un marco levemente más ligado a la Arquitectura de Software. Este surgimiento no ha hecho más que expandirse desde esos años. Aunque el arquitecto Christopher Alexander hacía referencia a patrones de edificios y urbanos, lo que él proponía se puede aplicar de igual forma a patrones de software, donde las soluciones se plantean en términos de componentes, interfaces y relaciones en lugar de paredes y puertas. 1 Del inglés Gang of Four integrada por : Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides. 2 Los autores son Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael Stal. Pag 5

Años más tarde, las ideas llegaron por fin a la informática. Si bien el concepto de arquitectura implícita en el trabajo actual con patrones, está más cerca de la implementación, la reutilización de patrones guarda estrecha relación con la tradición del diseño concreto orientado a objetos. En pos de la Arquitectura de Software en estos años se homogeneizó la terminología utilizada, se tipificaron los estilos arquitectónicos, patrones arquitectónicos, se elaboraron lenguajes de descripción de arquitectura y también se consolidaron las vistas arquitectónicas. Estilos Arquitectónicos Un estilo arquitectónico es una lista de tipos de componentes que describen los patrones o las interacciones a través de ellos. Un estilo afecta a toda la arquitectura de software y puede combinarse en la propuesta de solución. Los estilos ayudan a un tratamiento estructural que concierne más bien a la teoría, la investigación académica y la arquitectura en el nivel de abstracción más elevado, expresando la arquitectura en un sentido más formal y teórico. Una vez que se han identificado los estilos, es lógico y natural pensar en reutilizarlos en situaciones semejantes que se presenten en el futuro. Cuando se habla de una arquitectura en tres capas, o una arquitectura cliente-servidor, tácitamente se está haciendo referencia a una clasificación de las posibles configuraciones disponibles, en cuyo contexto adquiere un significado distintivo. No tiene sentido hablar de estilos si no se clarifica cuál es la tipología total en la que cada uno de ellos engrana. Definir una arquitectura como, por ejemplo, orientada a servicios ciertamente la tipifica, la distingue, la singulariza. La cuestión no es clasificarlas sino que al optar por una forma arquitectónica se define una situación pragmática. Una vez que los estilos adquieren una dimensión semántica precisa y diferencial, a su significado se asocian conceptos, herramientas, problemas, experiencias y antecedentes específicos. Existe una clasificación de familias de estilos, entre los que podemos destacar: - Estilos de Flujo de Datos: Esta familia de estilos destaca la reutilización y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos. - Estilos Centrados en Datos: Pone énfasis en la integridad de los datos. Son útiles para sistemas que se centran en el acceso y actualización de datos. - Estilos de Llamada y Retorno: Pone mayor atención sobre la modificabilidad y la escalabilidad del sistema. Son estilos que se utilizan para sistemas en gran escala. - Estilos de Código Móvil: Su mayor interés está en la portabilidad. Como ejemplo están los intérpretes. Pag 6

Estilo Vs Patrones Los estilos expresan componentes y las relaciones entre éstos, con las restricciones de su aplicación y la composición asociada, así como también las reglas para su construcción. Así mismo, se considera como un tipo particular de estructura fundamental para un sistema de software, junto con un método asociado que especifica cómo construirlo. Por otra parte, los patrones arquitectónicos capturan existencia, experiencia comprobada en el desarrollo del software y ayudan a promover buenas prácticas de diseño. Cada patrón es específico a un problema recurrente en el diseño e implementación de un sistema de software. Un patrón, como ya se ha comentado, se considera un par problema solución, resultado de la experiencia en el diseño de arquitecturas de sistemas y propone los patrones arquitectónicos como descripción de un problema particular y recurrente de diseño, que aparece en contextos de diseño específico, y presenta un esquema genérico demostrado con éxito para su solución. El esquema de solución se especifica mediante la descripción de los componentes que la constituyen, sus responsabilidades y desarrollos, así como también la forma como éstos colaboran entre sí. Por último, un patrón de diseño provee un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. Describe la estructura comúnmente recurrente de los componentes en comunicación, que resuelve un problema general de diseño en un contexto particular. Su aplicación no tiene efectos en la estructura fundamental del sistema, pero sí sobre la de un subsistema, debido a que especifica en mayor nivel de detalle, sin llegar a la implementación, el comportamiento de los componentes del subsistema. Los estilos y patrones ayudan al arquitecto a definir la composición y el comportamiento del sistema de software. Se puede afirmar que una combinación adecuada de ellos permite alcanzar los requerimientos de calidad esperados. Lenguajes de Descripción Arquitectónicas Como fue indicado anteriormente, la Arquitectura del Software tiene como objetivo el conocimiento, análisis y reutilización de la arquitectura de sistemas de software. Para explicitar dicha arquitectura, se requiere hacer uso de algún lenguaje. Los Lenguajes de Descripción Arquitectónicas (ADLs) son lenguajes que se focalizan en la descripción de la estructura de alto nivel de una aplicación pero a su vez permiten un nivel de detalle suficiente para describir propiedades de interés de dicha aplicación. De esta manera es posible comprobar, ya desde los primeros pasos del desarrollo de un sistema, si éste cumple o no determinados requisitos. De un modo general, se puede decir que los ADLs pretenden que se pueda analizar visualmente el sistema sin sufrir el aprendizaje de una sintaxis especializada. Dicha herramienta ha sido consensuada y estandarizada siendo de propósito general, adaptable a soluciones de cualquier estilo arquitectónico. Pag 7

Los conceptos tratados en una descripción arquitectónica son: - Componentes. Representan unidades de computación o de almacenamiento de datos. - Conectores. Modelan las interacciones entre componentes y las reglas que se aplican a dichas interacciones. - Configuraciones arquitectónicas. Grafos de componentes y conectores que describen la estructura arquitectónica del sistema. El objetivo de los ADLs es describir la interfaz de cada componente, no su comportamiento interno, formando de esta manera sistemas más grandes. La descripción de la interfaz incluye los métodos que ofrece o requiere el componente, información sobre la funcionalidad del mismo, los patrones de interacción que utiliza en su funcionamiento, y otras características diversas. Los requisitos que deben cumplir los ADLs son los siguientes: - Composición: Describir el sistema como una composición de partes. - Configuración: Describir la arquitectura independientemente de los componentes. - Abstracción: Describir los roles abstractos que juegan los componentes. - Reutilización: Permitir reutilizar componentes, conectores, y arquitecturas. - Heterogeneidad: Permitir combinar descripciones heterogéneas. - Análisis: Permitir diversas formas de análisis de la arquitectura. Existen varios ejemplos de ADLs, entre los que se encuentran: Unicon, Wright, Darwin, Rapide, etc. cada uno con sus propias características. Framework Un framework es un diseño reutilizable del sistema completo o de alguna de sus partes y se expresa mediante un conjunto de clases abstractas y la forma de interactuar de sus instancias. Un simple framework puede involucrar a muchos patrones de diseño; es decir, estos patrones son más pequeños que los framework, lo que implica, que los patrones son menos abstractos que ellos, son elementos microarquitectónicos de los frameworks. Pag 8

Clasificación de Patrones según la naturaleza del problema Capítulo 3 Patrones Considerando algunos de los patrones existentes se observa que ellos pueden cubrir varios rangos de escala y abstracción: - Estructurar un sistema de software dentro de subsistemas. - Soportar el refinamiento de subsistemas y componentes o la relación entre ellos. - Ayudar a implementar aspectos particulares de diseño en un lenguaje de programación específico. Para refinar dicha escala podemos agrupar los patrones que representan un rango similar de abstracción en tres categorías: - Patrones Arquitectónicos - Patrones de Diseño - Idioms Patrones Arquitectónicos Los patrones arquitectónicos son plantillas que describen los principios estructurales globales que construyen las distintas Arquitecturas de Software viables. Plantean una organización estructural fundamental para un sistema de software, expresando un conjunto de subsistemas predefinidos, especificando responsabilidades y organizando las relaciones entre ellos. La selección de un patrón arquitectónico es además una decisión fundamental de diseño cuando se desarrolla un sistema de software. Patrones de Diseño Un patrón de diseño provee un esquema para refinar componentes de un sistema de software y la forma en que se relacionan entre sí. Describe una estructura generalmente recurrente de comunicación de componentes que resuelve un problema de diseño general dentro de un contexto particular. Los patrones de diseño son patrones de granularidad media, ya que tienen menor nivel de abstracción que los patrones arquitectónicos pero tienden a ser independientes de un lenguaje de programación en particular o de un paradigma de programación. Pag 9

La aplicación de un patrón de diseño no tiene un efecto fundamental en la estructura del sistema de software global, pero tiene gran ingerencia sobre la arquitectura de un subsistema. Idioms Los Idioms están relacionados con la implementación de diseño de problemas particulares. Un Idiom es un patrón de bajo nivel específico para un lenguaje de programación. Describe como implementar aspectos particulares de componentes o las relaciones entre ellos usando las características dadas por el lenguaje. Los Idioms representan el nivel más bajo de patrones y direccionan tanto aspectos de diseño como de implementación. A continuación se presenta una clasificación de patrones según la categoría del problema Categoría de Patrones Arquitectura Cimientos Layers Pipes-Filter Sistemas Distribuidos Broker Sistemas Interactivos Model-View-Controller Sistemas Adaptables Microkernel Reflection Diseño Según el Problema Creación Abstract Factory Prototype Builder Descomposición Estructural Organización del Trabajo Control de Acceso Variación de Servicios Whole Part Composite Chain of Responsability Command Mediator Master-Slave Proxy, Facade, Iterator Bridge, Strategy, State Extensión de servicios Decorator Visitor Administración Adaptación Comunicación Memento Adapter Forwarder-Receiver Client-Dispatcher-Server Publisher-Subscriber Estructuración y Configuración Manejo de Recursos Extension Interface Flyweight Figura 3.1 - Categoría de Patrones según el tipo de problemas Características de un buen patrón Según James Coplien, un buen patrón es aquel que: - Resuelve un problema, ya que representa una solución, no suposiciones o estrategias abstractas. - Captura soluciones a problemas, que han sido repetidamente probadas y no son solo teorías o especulaciones. Pag 10

- Genera una solución a un problema indirectamente (un enfoque necesario para los problemas de diseño más difíciles). - No describe módulos sino estructuras y mecanismos de relación entre ellas. - Pone especial atención a la estética y a las utilidades. Tiene un componente humano significante. El análisis de patrones revela que sus componentes y relaciones no son tan atómicas como se ve a primera vista. La solución a un problema puede arribarse aplicando un solo patrón o combinaciones de varios patrones resolviendo problemas más pequeños, todos ellos integrados por un gran patrón que los contenga. Esquema de un patrón Todo patrón se representa con un esquema de tres partes: Contexto Problema Solución. El esquema denota una regla que establece una relación entre un contexto dado, un cierto problema que tiene lugar en ese contexto y una solución apropiada al problema. Contexto: El contexto extiende la dicotomía problema-solución describiendo la situación en la cual ocurre el problema. Es difícil especificar el contexto correcto para un patrón, siendo prácticamente imposible determinar todas las situaciones, tanto generales como particulares en la cual puede ser aplicado un patrón. Un acercamiento más pragmático es listar todas las situaciones conocidas que pueden ocurrir donde un problema es direccionado por un patrón en particular. Esto no garantiza que se cubran todas las situaciones en las cuales pueda ser relevante el patrón pero al menos nos da una guía valuable. Problema: Esta parte del esquema de descripción de patrón representa el problema que nace repetidamente en un contexto dado. Comienza con su especificación general, determinando cual es el problema en concreto que se debe resolver y tratando de balancear sus fuerzas. Solución: La solución parte de un patrón que muestra como resolver un problema recurrente, o como balancear mejor las fuerzas asociadas a él. Al plantear el problema se deben tener en cuenta las fuerzas o aspectos que deberían ser considerados como serían: Los requisitos que las soluciones deben cumplir. Las restricciones que se deben considerar. Las propiedades deseables que la solución debería tener. En general, las fuerzas atacan al problema desde varios puntos, ayudando a comprender los detalles del mismo y a justificar los diseños y las implementaciones. Pag 11

En el caso de los patrones, éstos relacionan conjuntos de objetivos y restricciones que se encuentran en el desarrollo de cada elemento que se va a crear. Estas fuerzas son conflictivas y difíciles de calcular. El siguiente diagrama resume un esquema, el cual captura la esencia de un patrón independientemente de su dominio. Patrones Contexto Plantea la situación dando comienzo al diseño del problema Problema Conjunto de fuerzas que aparecen repetidamente en el contexto Solución Configura el balance entre fuerzas Estructuras con componentes y relaciones Comportamiento en tiempo de ejecución Figura 3.2 - Esquema de tres partes : contexto problema - solución Los patrones se definen utilizando formatos consistentes. Una buena definición de un patrón permite entenderlo inmediatamente, y además provee todos los detalles necesarios para implementarlo y considerar las consecuencias de su aplicación. Los patrones se definen uniformemente, esto ayuda a compararlos, especialmente cuando se buscan soluciones alternativas a un problema. La estructura básica Contexto Problema Solución, antes mencionada, captura las características esenciales de un patrón y brinda ideas claves sobre éste facilitando la toma de decisión ante distintos patrones alternativos. Además de esta estructura, para formalizar un patrón según la nomenclatura sugerida por [Buschmann+96], debe definirse: - Un nombre el cual tiene que ser representativo de su esencia, que de idea del problema que aborda y de su solución. - Diagramas y escenarios que ilustren los aspectos estáticos y dinámicos de la solución. - Guías que sugieren como implementar el patrón, para transformar una arquitectura dada en una que usan los patrones. - Variantes de un patrón o patrones relacionados con el que se esta definiendo y cuales son sus diferencias. Estos otros patrones proveen soluciones alternativas a un problema. - Ventajas y desventajas potenciales de un patrón clarificando las consecuencias de su aplicación. Esta sección brinda información útil para decidir si se usa o no para ofrecer una solución adecuada a un problema específico. Pag 12

Categorías de Patrones Patrones Arquitectónicos Los patrones arquitectónicos representan el nivel más alto dentro del sistema de patrones y expresan el esquema de la estructura fundamental de la organización para sistemas de software. Proveen un conjunto de subsistemas predefinidos, especifican sus responsabilidades e incluyen reglas y guías para organizar las relaciones entre ellos. Cada patrón ayuda a lograr una propiedad específica del sistema global como es la adaptabilidad de la interfaz de usuario. Los patrones que dan soporte a propiedades similares pueden ser agrupados en las siguientes categorías: - Del fango a la estructura. Ayudan a evitar un mar de componentes u objetos. En particular apoyan una descomposición controlada de una tarea del sistema global en subtareas cooperantes. Esta categoría incluye los patrones Layers, Pipes and Filters y Blackboard. - Sistemas Distribuidos: incluye el patrón Broker y hace referencia a dos patrones que se encuentran en otras categorías, Microkernel y Pipes and Filters. El patrón Broker provee una infraestructura completa para aplicaciones distribuidas. Los patrones Microkernel y Pipes and Filters consideran la distribución como un concepto secundario y están ubicados bajo sus respectivas categorías primarias. - Sistemas Interactivos: En esta categoría entran dos patrones el Model-View- Controller (MVC) y el Presentation Abstraction Control (PAC). Ambos apoyan la estructuración de sistemas de software que ofrecen la interacción usuariocomputadora. - Sistemas Adaptables: Los patrones Reflection y Microkernel apoyan fuertemente la extensión de aplicaciones y su adaptación a desenvolverse con la tecnología y cambios en los requisitos funcionales. La selección de un patrón arquitectónico debería ser conducida por las propiedades generales de la aplicación a estudiar. Por ejemplo, si el sistema propuesto es un sistema interactivo o uno que tendrá diferentes variantes, la elección del patrón debería estar influenciada más allá de los requerimientos no funcionales de la aplicación, como la modificabilidad y la fiabilidad. La selección de un patrón arquitectónico, o la combinación de varios, es solamente el primer paso cuando se diseña la arquitectura de software de un sistema. Hay puntos que son recomendables para tener en cuenta al momento de elegir un patrón arquitectónico: Es útil explorar varias alternativas antes de decidir sobre un patrón arquitectónico específico. Diferentes patrones arquitectónicos implican diferentes consecuencias, aún si direccionan al mismo o problemas similares. Muchos sistemas de software no pueden ser estructurados de acuerdo a un patrón arquitectónico simple, dando soporte a requerimientos del Pag 13

sistema que solamente pueden ser solucionados mediante la aplicación de diferentes patrones arquitectónicos. Un patrón arquitectónico particular, o una combinación de éstos, no es una arquitectura de software completa, es un framework estructural para un sistema de software que debe ser luego especificado y refinado. Esto incluye la tarea de integrar la funcionalidad de las aplicaciones con el framework y detallar sus componentes y relaciones. Dentro de los patrones arquitectónicos se pueden citar: Layers, Pipes and Filters, Blackboard, Broker, Model-View Controller, Presentation Abstraction Control, Microkernel y Reflection. En el capítulo siguiente se verá con más detalle cada uno de estos patrones. Patrones de Diseño Los patrones de diseño son soluciones bien documentadas que los desarrolladores emplean para dar solución a nuevos problemas apoyados en la experiencia de haberlas utilizado con éxito en el pasado. Los profesionales identifican partes de un problema que son análogos a otros problemas que han resuelto anteriormente. Luego, retoman la solución utilizada y la generalizan. Por último, adecúan la solución general al contexto de su problema actual. De esta forma, los patrones de diseño brindan una forma eficaz de compartir la experiencia dentro de la comunidad de la programación orientada a objetos. Si bien los patrones de diseño no son exclusivos de este tipo de programación, es en este paradigma donde ha tenido una mayor aceptación, debido a que permite realizar una muy buena representación del mundo real adaptándose muy bien a las metáforas arquitectónicas propuestas por el arquitecto Christopher Alexander. Los objetos pueden articularse en estructuras más complejas, al igual que la arquitectura, agregando además la noción de tiempo por medio del intercambio de mensajes entre objetos. Los patrones de diseño se han transformado en una técnica difundida para la reutilización de conocimiento de diseño de software. Su principal motivación es el hecho de encontrar con mucha frecuencia problemas similares, en diseños diferentes. Un patrón de diseño es una estructura de clases que se presenta en forma repetida en distintos diseños orientados a objetos, la cuál es empleada para resolver un problema determinado de manera flexible y adaptable en forma dinámica. Dentro de los patrones de diseño existen variaciones según su nivel de granularidad y abstracción, lo que permite clasificarlos bajo dos criterios: Propósito, refleja qué hace un patrón teniendo en cuenta si es de Creación, Estructural o de Comportamiento; y Ámbito, especifica si un patrón se aplica primariamente a una clase o a un objeto. - De Creación: abstrae el proceso de instanciación de objetos, su misión es permitir construir sistemas independientes de la forma de creación, composición o representación de objetos. Un patrón de creación de clases utiliza la herencia para variar la clase que es instanciada, un ejemplo de este tipo de patrón es Factory Method. Un patrón de creación de objetos delega la instanciación en otro objeto, por ejemplo el patrón Builder. Pag 14

- Estructural: controla como se componen las clases u objetos en la construcción de estructuras mayores. Un patrón estructural de clases utiliza la herencia para componer interfaces o implementaciones, por ejemplo el patrón Adapter. Un patrón estructural de objetos describe la forma en que se componen objetos para obtener nueva funcionalidad, además se añade la flexibilidad de cambiar la composición en tiempo de ejecución, lo cual no es posible con la composición de clases estáticas, como representante de este tipo de patrón se puede mencionar al patrón Composite. - De Comportamiento: se relaciona con algoritmos, la forma en la que interactúan las clases u objetos y la asignación de responsabilidades entre ellos. Los patrones de comportamiento de clases utilizan la herencia para distribuir el comportamiento entre las clases, se puede citar como ejemplo el patrón Command. Por su parte los patrones de comportamiento de objetos cooperan como un grupo de objetos interconectados para realizar una tarea que un solo objeto no puede realizar por sí solo, un ejemplo es el patrón Observer. Idioms En contraste con los patrones de diseño, los cuales se orientan hacia las arquitecturas generales principales, los idioms describen cómo resolver problemas de implementación específicos en un lenguaje de programación determinado. Los Idioms pueden también realizar directamente la implementación concreta de un patrón de diseño particular. Los idioms se aproximan o se solapan con áreas que son, por lo general, regidas por guías de programación. Pag 15

Capítulo 4 Patrones Arquitectónicos La selección de un patrón arquitectónico debería ser conducida por las propiedades generales de la aplicación a estudiar. Es útil explorar varias alternativas antes de decidir sobre un patrón arquitectónico específico. Por ejemplo el patrón PAC y el MVC ambos se prestan para aplicaciones interactivas. En forma similar los patrones Reflection y Microkernel apoyan la adaptación de sistemas de software a la evolución de requisitos. Diferentes patrones arquitectónicos implican diferentes consecuencias, aún si encaminan al mismo o a problemas similares. Por ejemplo, una arquitectura MVC usualmente es más eficiente que una arquitectura PAC. Por otro lado, PAC soporta multitareas y tareas específicas de interfaces de usuarios mejor de lo que lo hace MVC. Muchos sistemas de software no pueden ser estructurados de acuerdo a un patrón arquitectónico simple. Deben dar soporte a muchos requerimientos de sistema que pueden solamente ser direccionados por diferentes patrones arquitectónicos. Por ejemplo, tener que diseñar tanto para flexibilidad de componentes distribuidos en una red de computadoras heterogéneas como también para adaptabilidad de las interfases de usuarios. Se deben combinar varios patrones para estructurar tal sistema. Del Fango a la Estructura En esta categoría se encuentran los patrones que ayudan a evitar un mar de componentes u objetos apoyando una descomposición controlada de una tarea del sistema global en subtareas cooperantes. Dentro de esta clasificación de patrones arquitectónicos se encuentran diferentes tipos de patrones que proporcionan subdivisiones de alto nivel del sistema: Layers, Pipes and Filters y Blackboard donde: - El patrón Layers ayuda a estructurar aplicaciones que pueden ser descompuestas en grupos de subtareas, en el que cada grupo pertenece a un nivel particular de abstracción. - El patrón Pipes and Filters provee una estructura para sistemas que procesan un flujo de datos. Cada paso del proceso esta encapsulado en un componente filter. Los datos se pasan a través de los pipes entre filters adyacentes. La combinación de filters permite construir familias de sistemas relacionados. - El patrón Blackboard es útil para problemas en los cuales no se conoce ninguna estrategia de solución determinística. En este patrón varios subsistemas especializados ensamblan sus conocimientos para construir una solución posiblemente parcial o aproximada. A continuación describiremos con más detalle cada uno de ellos. Pag 16

Layers El patrón arquitectónico Layers ayuda a estructurar aplicaciones que pueden descomponerse en grupos o subtareas, en las cuales cada grupo de subtareas tiene un nivel de abstracción particular. Contexto Un sistema extenso que requiere descomposición. Problema Considerar que se diseña un sistema cuya característica dominante es una mezcla de problemas de altos y bajos niveles, donde las operaciones de alto nivel confían en operaciones de bajo nivel. Algunas partes del sistema manejan problemas de bajo nivel como interrupciones por hardware, entradas de sensor, lectura de bits de un archivo o señales eléctricas, y en el otro extremo, problemas de nivel más alto, como por ejemplo la interfaz de una aplicación multi-usuario. Un patrón típico de comunicación consiste en el pasaje de solicitudes desde la capa superior hacia la de nivel más bajo y las respuestas en dirección opuesta enviando datos o notificando acerca de eventos. Tales sistemas además requieren de alguna estructura horizontal que es ortogonal a su subdivisión vertical. Este es el caso donde varias operaciones están en el mismo nivel de abstracción pero son independientes unas de otras. El sistema tiene como objetivo la portabilidad a otras plataformas. En ese caso se necesitan balancear las siguientes fuerzas: - Los cambios en el código fuente de un componente no afectarían a otros. - Las interfaces deberían ser estables, y podrían ser estandarizadas. - Las partes del sistema deberían ser cambiables. Los componentes deberían ser capaces de ser reemplazados por implementaciones alternativas sin afectar al resto del sistema. Hacer un diseño para realizar cambios generales es lo que hace más fácil la evolución elegante del mismo. - Responsabilidades similares deberían ser agrupadas para ayudar a entender y mantener al sistema. Cada componente debería ser coherente - si un componente implementa problemas divergentes puede perder su integridad. - Componentes complejos necesitan más descomposición. - El cruzamiento de límites de los componentes puede hacer que se pierda performance. - Si el sistema fuese construido por un equipo de programadores, el trabajo debe ser dividido de acuerdo a límites claros. Pag 17

Solución Si observamos la solución desde un alto nivel de abstracción esta es extremadamente simple. Se debe estructurar el sistema en un número apropiado de capas y ubicarlas unas encima de otras, comenzando por el nivel más bajo de abstracción Capa 1. Esta es la base del sistema. Se deben trabajar los niveles de abstracción colocando una capa sobre otra hasta que se coloque en el tope, el nivel de funcionalidad Capa N, lo que da una vista conceptual del sistema. Es esencial que dentro de una capa individual todo el trabajo del componente constitutivo trabaje al mismo nivel de abstracción. Los servicios de cada capa implementan una estrategia para combinar servicios de las capas inferiores con algún significado. Estructura Una capa individual se puede describir como sigue: Clase Layer J Responsabilidades - Provee servicios usados por la capa J+1 - Delega las subtareas a la capa - 1 Colaborador - Layer J - 1 Figura 4.1 - Clase de la capa J La principal característica estructural del patrón Layers es que los servicios de una Capa J son solamente usados por la Capa J+1 no se pueden saltear capas. Esta estructura puede ser comparada con una pila. Cada capa individual escuda todas las capas inferiores de accesos directos por capas superiores. Cliente Layer N El Nivel mas alto de abstracción Layer N - 1 Layer 1 El Nivel mas bajo de abstracción Figura 4.2 - Esquema de estructuración en capas Consecuencias El patrón Layers tiene varias ventajas: o Reusabilidad. Si una capa individual incluye una abstracción bien definida y tiene una interfaz bien definida y documentada, la capa puede ser reusada en múltiples contextos. Pag 18