Tesina Arquitectura de Software

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 requisitos para la obtención 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.

Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

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 E stilos Arquitectónicos................................................................................................ 6 E stilo Vs Patrones ...................................................................................................... 7 L enguajes de Descripción Arquitectónicas .................................................................... 7 F ramework................................................................................................................ 8 CAPÍTULO 3 ..................................................................................................................9 P ATRONES ....................................................................................................................... 9 Clasificación de Patrones según la naturaleza del problema ........................................... 9 Características de un buen patrón ..............................................................................10 E squema 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 P ATRONES ARQUITECTÓNICOS .............................................................................................16 Del Fango a la Estructura ..........................................................................................16 Layers..................................................................................................................17 Pipes and Filters ...................................................................................................20 Blackboard ...........................................................................................................23 S istemas Distribuidos ................................................................................................27 Broker..................................................................................................................28 S istemas Interactivos ................................................................................................33 Model-View-Controller ...........................................................................................34 Presentation-Abstraction-Control ............................................................................38 S istemas Adaptables .................................................................................................42 Microkernel ..........................................................................................................43 Reflection.............................................................................................................47 CAPÍTULO 5 ................................................................................................................52 P ATRONES DE DISEÑO .......................................................................................................52 P atrones de Creación ................................................................................................52 Abstract Factory....................................................................................................52 Builder.................................................................................................................54 Prototype .............................................................................................................56 P atrones Estructurales...............................................................................................58 Adapter................................................................................................................58 Bridge..................................................................................................................60 Composite............................................................................................................61 Proxy...................................................................................................................63 P atrones de Comportamiento.....................................................................................64 Template Method..................................................................................................65 Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag iii

Observer..............................................................................................................66 Command ............................................................................................................67 State ...................................................................................................................68 Strategy...............................................................................................................70 Null Object ...........................................................................................................71 Type Object .........................................................................................................73 Decorador ............................................................................................................76 CAPÍTULO 6 ................................................................................................................79 C ASO DE ESTUDIO: SISTEMA DE CHEQUES ...............................................................................79 P articipantes ............................................................................................................79 E squema 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 L imites del sistema ...................................................................................................83 Visión Arquitectónica.................................................................................................84 CAPÍTULO 7 ................................................................................................................85

APLICACIÓN DE P ATRONES ..................................................................................................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 Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

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. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

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. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

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: Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

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 “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 2

inglés “Gang of Four” integrada por : Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides. Los autores son Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael Stal.

Arquitectura de Software: Estilos y Patrones Patrones Adriana Almeira – Vanina Perez Cavenago Cavenago

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. Pone énfasis en la integridad de los datos. Son útiles - Estilos Centrados en Datos: Pone 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

Capítulo 3

Patrones Clasificación de Patrones según la naturaleza del problema 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. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

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

S e g ú n e l P r o b l e m a

Cimientos Sistemas Distribuidos Sistemas Interactivos

Pipes-Filter Broker Model-View-Controller

Sistemas Adaptables

Microkernel Reflection

Diseño

Layers

Creación Descomposición Estructural Organización del Trabajo Control de Acceso Variación de Servicios Extensión de servicios Administración Adaptación

Abstract Factory Prototype

Builder

Whole Part Composite Chain of Responsability Command Mediator Master-Slave Proxy, Facade, Iterator Bridge, Strategy, State Decorator Visitor Memento Adapter

Comunicación

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-ViewController (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. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

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

Colaborador - Layer J - 1

Responsabilidades - Provee servicios usados por la capa J+1 - Delega las subtareas a la capa 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

o

o

o

Estandarización . Niveles de abstracción claramente definidos y comúnmente aceptados habilitan el desarrollo de tareas e interfaces estandarizadas. Implementaciones diferentes de la misma interfaz pueden ser usadas en forma indistinta. Esto permite usar productos de diferentes vendedores en distintas capas. Portabilidad . Las interfaces estandarizadas entre capas limitan el efecto de cambios de código a la capa a modificar. Los cambios de hardware, del sistema operativo y todo lo que afecta solamente a una capa, se puede modificar sin alterar al resto de las capas. Esto permite la portabilidad del sistema, y testeo independiente de las capas. Cambiabilidad . La implementación de capas individuales puede ser reemplazada por una implementación semánticamente equivalente sin grandes esfuerzos, por ejemplo, cambiar o agregar un hardware. Un nuevo dispositivo de E/S, puede ser puesto en operación instalando el driver correcto. Las capas superiores no se verán afectadas por el cambio.

El patrón Layer también impone desventajas: o

o

o

Baja eficiencia. Una arquitectura en capas es usualmente menos eficiente que una estructura monolítica. Si servicios de alto nivel en capas superiores necesitan obligatoriamente de las capas inferiores, todo dato relevante debe ser transferido a través de varias capas intermedias, y puede llevar mucho tiempo. La comunicación de protocolos, por ejemplo, transforman los mensajes de alto nivel mediante el agregado de cabeceras e información de control. Trabajo innecesario . Capas inferiores pueden necesitar hacer tareas que no han sido solicitadas para brindar un determinado servicio a una capa superior. Este trabajo excesivo tiene un impacto negativo en la performance. Dificultad al establecer la correcta granularidad de las capas . Una arquitectura de capas con muy pocas capas no explota completamente la potencial reusabilidad, cambiabilidad y portabilidad de este patrón. Por otro lado, también muchas capas introducen complejidad innecesaria de sobrecarga en la separación y la transformación de argumentos y valores de retorno. La decisión de la granularidad de las capas y la asignación de tareas es dificultosa, pero es indispensable para lograr calidad en la arquitectura.

Ejemplo Un ejemplo típico donde se utiliza el patrón Layers es en la estructura del protocolo de comunicación OSI. Los diseñadores hacen uso de varios subprotocolos y los colocan en capas. Esta es una arquitectura en donde hay varios niveles de comunicación, partiendo desde el hardware pasando por la comunicación punto a punto y llegando a los protocolos de aplicaciones. Estos niveles a su vez se dividen en subniveles y llevándolos cada uno a capas diferentes. Cada capa lleva a cabo una tarea específica para la comunicación y utiliza los servicios que le brinda su capa inmediata inferior. La arquitectura estaría dividida en las siguientes capas:


Pag 19

Aplicación (Capa 7) Presentación (Capa 6) Sesión (Capa 5) Transporte (Capa 4) Red (Capa 3) Enlace de Datos (Capa 2) Física (Capa 1)

Figura 4.3 - Esquema del protocolo de red OSI

Donde cada una de ellas se comunica solo con su capa inmediatamente inferior para solicitarle servicios, y con su capa inmediatamente superior para brindarle servicio, imposibilitando la comunicación entre capas no adyacentes. Mantener la independencia entre capas de esta manera, permite realizar modificaciones en una capa sin que esto afecte al resto de las capas. La estratificación en capas es considerada una mejor práctica que la implementación del protocolo como un bloque monolítico. Pipes and Filters

El patrón arquitectónico Pipes and Filters provee una estructura para sistemas que procesan flujo de datos, donde cada paso de procesamiento es encapsulado en un componente filter y los datos pasan entre filters adyacentes. Combinando filters se permite la construcción de una familia de sistemas relacionados. Contexto Procesamiento de flujo de datos Problema La construcción de un sistema que debe procesar o transformar un flujo de entrada de datos. La implementación de tal sistema como un componente simple no puede ser factible por varias razones: El sistema es desarrollado por varios desarrolladores, - La tarea de un sistema global se descompone naturalmente en varias fases del proceso, - Los requerimientos probablemente son cambiables. -

Por lo tanto, cambiando o reordenando los pasos del procesamiento se planifica la futura flexibilidad, construyendo de sistemas que usen los componentes existentes del proceso. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 20

Al realizar el diseño del sistema – especialmente la interconexión de pasos de procesamiento – se deben considerar las siguientes fuerzas: -

-

Debería posibilitar futuros perfeccionamientos de sistemas intercambiando o recombinando pasos de procesamiento. Pequeños pasos de procesamiento deberían ser fáciles de reusar en diferentes contextos de grandes componentes. Pasos de procesamiento que no son adyacentes no deberían compartir información. El sistema debería permitir diferentes fuentes de entrada de datos, como puede ser una conexión a la red o un sensor de hardware que provee lecturas de temperaturas. Debería ser posible presentar o almacenar resultados finales en formas diferentes.

Solución El patrón Pipes and Filters divide la tarea del sistema en varios pasos de procesamiento. Estos pasos se conectan por un flujo de datos a través del sistema -los datos de salida de un paso son la entrada para el paso siguiente. Cada paso de procesamiento es implementado por un componente filter. Un filter consume y entrega datos incrementalmente – en vez de consumir todas sus entradas antes de producir cualquier salida- logrando, de esta forma, baja latencia y habilitando un proceso realmente paralelo. La entrada al sistema es provista por una fuente de datos, por ejemplo, un archivo de texto. El flujo de datos de salida es un almacenamiento como puede ser un archivo, una terminal, un programa, etc. La fuente de datos, los filters y la salida de datos están conectados secuencialmente por pipes. Cada pipe implementa el flujo de datos entre pasos de procesamiento adyacentes. La secuencia de filters combinada por pipes es llamada Procesamiento Pipelines. Estructura Los filters son la unidad de procesamiento de los pipelines. Un filter enriquece, refina o transforma la entrada de datos. Enriquece los datos computando y agregándole información, - los refina concentrando o extrayendo la información y - los transforma entregándolos en alguna otra representación. -

Una implementación concreta de filter puede combinar cualquiera de estos tres principios básicos. Los pipes denotan la conexión entre filters, entre la fuente de datos y el primer filter, y entre el último filter y los datos de salida. Los pipes sincronizan dos componentes filtres adyacentes. La sincronización es hecha en el buffer como el primero en entrar, es el primero en salir.


Pag 21

Clase Filter

Clase Pipe

Colaborador - Pipe

Colaborador - La fuente de

Responsabilidades

Responsabilidades

- Toma los datos de la entrada - Realiza una función en los datos de entrada - Suministra datos de salida

- Transfiere los datos Almacena los datos - Sincroniza los vecinos activos

datos - El repositorio de datos - Filter

Figura 4.4 - Clases Pipe y Filter

La fuente de datos representa la entrada al sistema, y provee una secuencia de valores de datos de algún tipo o estructura. Ejemplos de tales fuentes de datos son un archivo que contiene líneas de texto, o un sensor entregando una sucesión de números. El almacenamiento de datos reúne los resultados del extremo del pipeline. Clase La fuente de datos

Clase

Colaborador - Pipe

El repositorio de datos

Responsabilidades

Responsabilidades

- Entrega la entrada al pipeline para procesar

- Consumir la salida

Colaborador - Pipe

Figura 4.5 - Clases Repositorio y Fuente de datos

La estructura del patrón arquitectónico Pipe and Filter es: filter pipe

pipe

pipe

pipe

filter

pipe filter

filter

filter pipe

pipe

filter

pipe

Figura 4.6 - Estructura Patrón Pipe and Fliter

Consecuencias El patrón Pipes and Filters tiene las siguientes ventajas: o

No son necesarios archivos intermedios, pero es posible su utilización . Es posible calcular resultados usando programas separados sin pipes, guardando los resultados intermedios en archivos. El uso de este patrón quita la necesidad de archivos intermedios, pero permite investigar los datos intermedios usando la unión “T” en el pipeline.


Pag 22

o

o

o

o

o

Flexibilidad por el intercambio de filters . Los filters tienen una interfaz simple que permite su intercambio fácilmente dentro del procesamiento del pipeline. Flexibilidad por recombinación . Este es el mayor beneficio, combinado con la reusabilidad de los componentes filters, permitiendo la creación de nuevos procesos pipelines reestructurando los filters o agregando uno nuevo. Un pipeline sin una fuente o un almacenamiento de datos puede ser embebido como un filter dentro de un pipeline más grande. Reusabilidad . Permite la recombinación de filters facilitando el reuso de sus componentes. El prototipado rápido de los pipelines . Las Ventajas precedentes hacen esto más fácil para el prototipo de un sistema de procesamiento de datos de los filters existentes. Después que se tiene la implementación de la función del sistema principal usando un pipeline, se puede optimizar incrementalmente. Eficiencia del procesamiento en paralelo . Si cada filter en un pipeline produce y consume datos incrementalmente pueden realizar sus funciones en paralelo.

Aplicar patrones Pipes and Filters imponen algunas desventajas: o

o

Compartir el estado de la información es caro o poco flexible . Aplicar el patrón Pipes and Filters es ineficiente si las fases de procesamiento necesitan compartir una gran cantidad de datos globales Desventaja en el procesamiento en paralelo . Esto se debe a varias razones: El costo de transferir datos entre filters puede ser relativamente alto comparado con el costo de realizar cómputos en un solo filter. Algunos filters consumen todas sus entradas antes de producir cualquier salida, Esto puede ser debido a que el filter esta mal codificado. Manejo de errores. El manejo de errores es una gran debilidad del patrón Pipes and Filters. Se debería por lo menos definir una estrategia común para el reporte de errores y usarse a lo largo de todo el sistema.

•

•

o

Ejemplo Unix ha popularizado el paradigma pipe and Filter. El comando shell y la disponibilidad de varios programas filters hacen de Unix un sistema popular. Como un sistema para diseñadores de software, tareas frecuentes tales como la compilación de un programa y la creación de documentación son realizadas por pipelines en un sistema Unix tradicional. La flexibilidad de los pipes de Unix hizo del sistema operativo una plataforma conveniente para el reuso binario de programas filters y para la integración de aplicación. Blackboard

El patrón arquitectónico Blackboard es útil para los problemas en los cuales no se conoce ninguna estrategia de solución determinística. En Blackboard varios subsistemas especializados asocian sus conocimientos para construir una posible solución parcial o aproximada. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 23

Contexto Un dominio poco definido en el cual no se conoce o no es factible alguna posible solución concreta. Problema El patrón Blackboard se utiliza para problemas que no tienen una solución determinística factible en la transformación de datos en estructuras de datos de alto nivel. Ejemplos de dominios en los que ocurren tales problemas son visualización, reconocimiento de imágenes y reconocimiento de lenguaje. La característica de estos problemas es cuando se necesitan descomponer en subproblemas que requieren varios campos de especialización. Las soluciones a los subproblemas requieren diferentes representaciones y paradigmas. En muchos casos no existe una estrategia predeterminada de “cómo resolver el problema parcial”, para ello se debe combinar conocimientos. Cada paso de la transformación también puede generar varias soluciones alternativas. Las siguientes fuerzas influyen en soluciones a los problemas de este tipo: -

-

La búsqueda completa del espacio de solución no sería factible en un tiempo razonable. Debido a que el dominio es imperfecto, se podría necesitar experimentar con algoritmos diferentes para la misma subtarea. Hay diferentes algoritmos que resuelven problemas parciales. La entrada, como también resultados intermedios y finales, tienen representaciones diferentes, y los algoritmos se llevan a cabo según paradigmas diferentes. Un algoritmo normalmente trabaja sobre los resultados de otros algoritmos. Datos inciertos y soluciones aproximadas están relacionados El empleo de algoritmos separados induce a un potencial paralelismo. De ser posible se debería evitar una solución estrictamente secuencial.

Solución La idea detrás de la arquitectura Blackboard es una colección de programas especializados e independientes que trabajan cooperativamente sobre una estructura de datos común. Cada programa se especializa en resolver una parte particular de la tarea global, y todos los programas trabajan en conjunto en pos de una solución. Si bien los programas son independientes unos de otros, la dirección tomada por el sistema es principalmente determinada por el estado de progreso actual que es evaluado por un componente de control central. Durante el proceso problema-solución el sistema trabaja con soluciones parciales combinadas, cambiadas o rechazadas. Cada una de estas soluciones representa un problema parcial y un cierto estado del proceso de la solución. El conjunto de todas las soluciones posibles se llama espacio de solución, y es organizado en niveles de abstracción. El nivel más bajo de solución consiste en una representación interna de la entrada. Las soluciones potenciales de la tarea del sistema global están en el nivel más alto. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 24

Estructura El sistema se divide en un componente llamado pizarra, una colección de fuentes de conocimiento, y un componente de control. La pizarra es el almacenamiento central de datos que guarda también los elementos del espacio de solución y el control de datos. Proporciona una interfaz que habilita a todas las fuentes de conocimiento para leer y escribir en ella. Las fuentes de conocimiento son subsistemas separados e independientes que resuelven aspectos específicos del problema global y modelan el dominio del mismo. Ninguno de ellos puede resolver en forma aislada la tarea del sistema -una solución se construye integrando los resultados de varias fuentes de conocimiento. Ellas sólo leen y escriben en la pizarra. Cada fuente de conocimiento es responsable de conocer las condiciones bajo las cuales puede contribuir a una solución, evaluando el estado actual del proceso de la solución para determinar si puede hacer una contribución, y producir un resultado que puede causar un cambio en el contenido de pizarra. Clase Blackboard

Colaborador

Clase

Fuente de Conocimiento

Responsabilidades

Responsabilidades

- Maneja los datos centrales

- Evalúa su propia pertinencia - Computa un resultado - Actualiza el blackboard

Colaborador - Blackboard

Figura 4.7 - Clases Blackboard y Fuente de Conocimiento

El componente de control ejecuta un loop que monitorea los cambios en la pizarra y decide qué acción tomará luego. Establece las evaluaciones de la fuente de conocimiento y activaciones de acuerdo a una estrategia de aplicación conocida. La base para esta estrategia es el dato sobre la pizarra, que ayuda a la toma de decisiones de control. Sus resultados se llaman datos de control y también se ponen en la pizarra. Clase Control

Responsabilidades

Colaborador - Blackboard - Fuente de Conocimiento

- Monitorea el Blackboard - Maneja las activaciones de las fuentes de conocimiento

Figura 4.8 - Clases Control

Teóricamente, es posible que la pizarra pueda alcanzar el estado en el cual ninguna fuente de conocimiento es aplicable. En este caso, el sistema falla al entregar un resultado. En la práctica, es más probable que cada paso de razonamiento introduzca Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 25

varias hipótesis nuevas, y que el número de posibles próximos pasos “explote”. El problema es por consiguiente restringir las alternativas a ser tomadas. Una fuente de conocimiento especial o un procedimiento en el componente de control determina cuando el sistema se debe detener, y cual es el resultado final. El sistema se detiene cuando se encuentra una hipótesis aceptable, o cuando finalizan los recursos del sistema de espacio o tiempo. Fuente de conocimiento Pizarra

Control

Figura 4.9 - Estructura del Patrón Arquitectónico Blackboard

Consecuencias. La forma en que el patrón Blackboard descompone el problema y aplica el conocimiento, aporta las siguientes ventajas: o

o

o

o

Experimentación . En dominios en que no existe alguna posible solución y una búsqueda completa del espacio de la solución no es factible, el patrón Blackboard experimenta con la mayor cantidad posible de algoritmos diferentes, y también permite intentar con diferentes heurísticas de control. Cambiabilidad y mantenibilidad . La arquitectura Blackboard soporta la cambiabilidad y mantenibilidad porque las fuentes de conocimiento individuales, el algoritmo de control y la estructura de datos central están estrictamente separados. Reusabilidad . Las fuentes de conocimiento son independientes para ciertas tareas. Una arquitectura Blackboard ayuda haciéndolas reusables. Los requisitos previos para reusar son que la fuente de conocimiento y el sistema Blackboard subyacente entiendan el mismo protocolo y datos. Tolerancia a fallos y robustez . En una arquitectura Blackboard todos los resultados son sólo hipótesis. Sólo sobrevivirán aquellas que son fuertemente soportadas por los datos y otras hipótesis.

El patrón Blackboard tiene algunas desventajas: o

o

Dificultad de testeo . Los cómputos de este patrón no siguen un algoritmo determinístico, por lo tanto sus resultados no son a menudo reproducibles. Además, hipótesis erróneas son parte del proceso de solución. No se garantiza ninguna buena solución . Normalmente puede resolver correctamente sólo un cierto porcentaje de las tareas dadas.


Pag 26

o

o

o

o

Dificultad de establecer una buena estrategia de control . La estrategia de control no puede diseñarse de una manera íntegra, y requiere un acercamiento experimental. Baja eficiencia . Padece el exceso computacional del rechazo de las hipótesis erróneas. Alto esfuerzo de desarrollo . La mayoría de estos sistemas toman años para evolucionar. Se atribuye esto a los dominios mal estructurados del problema y una programación basada en prueba/error para definir estrategias de control y fuentes de conocimiento. No soporta paralelismo . La arquitectura Blackboard no provee la ejecución en paralelo. El acceso concurrente a los datos centrales en la pizarra se debe sincronizar.

Ejemplo Se ha usado tradicionalmente el patrón Blackboard para aplicaciones que requieren complejas interpretaciones de procesamiento de señales, como también en sistemas que involucran el acceso compartido a datos con agentes escasamente acoplados. Un ejemplo de uso es un sistema HASP diseñado para detectar submarinos enemigos. En este sistema, un hidrófono (dispositivo que captura las ondas acústicas transmitidas en el agua) muestra en el monitor un área del mar colectando señales sonoras. Un sistema Blackboard interpreta estas señales. El sistema HASP es un sistema basado en eventos en el sentido que la ocurrencia de un evento particular implica que nueva información este disponible. La pizarra es usada como una “tabla de situación” que evoluciona con el tiempo. Como la información se recolecta continuamente, hay información redundante como también nueva y diferente. HASP trata con múltiples flujos de entrada. Además el bajo nivel de datos del hidrófono acepta descripciones de alto nivel de la situación recogida de inteligencia u otras fuentes.

Sistemas Distribuidos Hoy día, aún las pequeñas compañías usan sistemas distribuidos. ¿Pero cuáles son las ventajas de los sistemas distribuidos que los hacen interesantes? Economía . Redes de computadoras que incorporan PCs y workstations ofrecen una mejor relación costo/performance que un mainframe. Performance y Escalabilidad . Las aplicaciones distribuidas, usan recursos disponibles en toda la red. La performance puede mejorar enormemente si se utiliza en forma combinada, el poder de cómputo de varios nodos de red. Además, multiprocesadores y redes son fácilmente escalables. Distribución inherente . Algunas aplicaciones son naturalmente distribuidas, por ejemplo aplicaciones de base de datos en un modelo Cliente-Servidor. Fiabilidad . En la mayoría de los casos, una máquina en una red o una CPU en un sistema multiprocesador puede dejar de funcionar sin afectar el resto del sistema. Los Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 27

nodos centrales como los servidores de archivos son las excepciones a esto, pero puede protegerse con sistemas auxiliares. Los sistemas distribuidos, sin embargo tienen un inconveniente significante, necesitan software totalmente diferente a los sistemas centralizados. Tres modelos relacionados a sistemas distribuidos en esta categoría: El patrón Pipes and Filters mantiene una estructura para sistemas que procesan un flujo de datos. Cada paso del proceso es encapsulado en un componente filter. Los datos son pasados a través de pipes entre filters adyacentes. La recombinación de filters permite construir familias de sistemas relacionados. Este patrón se utiliza más por estructurar la funcionalidad central de una aplicación que por su naturaleza distribuida, es por ello que lo ubicamos junto al patrón Layers en la clasificación anterior. - El patrón Microkernel se aplica a sistemas de software que tienen la necesidad de adaptar el sistema a requerimientos cambiantes. Este patrón separa la funcionalidad central mínima de la funcionalidad extendida y las partes específicas del cliente. El microkernel también sirve como un socket para comunicar estas partes y coordinar su colaboración. Este patrón es descripto más adelante en este capítulo dentro de la clasificación de patrones adaptables. - Los sistemas Microkernel emplean una arquitectura Cliente-Servidor en los cuales clientes y servidores corren sobre el componente microkernel. El mayor beneficio de estos sistemas, está en el diseño apto para la adaptación y cambio. - El patrón Broker puede usarse para estructurar sistemas de software distribuidos con componentes desarticulados que se comunican mediante invocación remota de servicios. Un componente broker es responsable de coordinar la comunicación (remitir las demandas, transmitir los resultados y excepciones). -

Broker

El patrón arquitectónico Broker puede usarse para estructurar sistemas de software distribuidos con componentes desacoplados que interactúan por invocaciones de servicios remotos. Un componente Broker es responsable de coordinar la comunicación, remitir las demandas, así como transmitir resultados y excepciones. Contexto El ambiente es un sistema distribuido y posiblemente heterogéneo con componentes independientes que cooperan entre sí. Problema Construir un sistema de software complejo como un conjunto de componentes desacoplados que interoperan, en lugar de una aplicación monolítica, los resultados son altamente flexibles, mantenibles y cambiables. Dividiendo la funcionalidad en los componentes independientes del sistema, se torna potencialmente distribuible y escalable. Desde el punto de vista de un diseñador, no debe haber ninguna diferencia esencial entre el software en vías de desarrollo para los sistemas centralizados y el desarrollo para un sistema distribuido. Una aplicación que usa un objeto debería sólo Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 28

ver la interfaz ofrecida por el objeto. No debería necesitar conocer los detalles de implementación de un objeto o su ubicación física. Se debe usar la arquitectura Broker para equilibrar las siguientes fuerzas: Los componentes deberían poder acceder a los servicios proporcionados por otros aunque sean remotos. Las invocaciones de servicios remotos deben ser transparentes respecto de su ubicación. - Si se necesitase intercambiar, agregar o quitar componentes en tiempo de ejecución. - La arquitectura debería ocultar de los usuarios de componentes y servicios, detalles específicos del sistema e implementación. -

Solución Introducir un componente broker para lograr una mejor separación de clientes y servidores. Los servidores se registran con el broker y hacen que sus servicios estén disponibles a los clientes a través de métodos de interfaces. Los clientes acceden funcionalmente a los servidores enviando las solicitudes a través del broker. Las tareas de un broker incluyen localizar al servidor apropiado, remitir la solicitud al servidor y transmitir respuestas y excepciones al cliente. Usando el patrón Broker, una aplicación puede acceder a servicios distribuidos simplemente enviando mensajes a un objeto apropiado, en lugar de enfocarse en la comunicación inter-proceso de bajo nivel. La arquitectura Broker tiene la ventaja de ser flexible, lo que le permite realizar cambios en forma dinámica, agregar, eliminar, y reubicar los objetos. El patrón Broker reduce la complejidad involucrada desarrollando las aplicaciones distribuidas, haciendo la distribución transparente al diseñador. Logra esta meta introduciendo un modelo de objeto en el que se encapsulan los servicios distribuidos dentro de los objetos. Estructura El patrón arquitectónico Broker comprende seis tipos de componentes participantes: Un componente servidor que implementa objetos que exponen su funcionalidad a través de interfaces que consisten en operaciones y atributos. Estas interfaces son realizadas a través de un lenguaje de definición de interfaz (IDL). Las interfaces se agrupan por su funcionalidad semánticamente relacionada. Hay dos tipos de servidores: •

•

Servidores que ofrecen los servicios comunes a muchos dominios de aplicación. Servidores que implementan la funcionalidad específica por un solo dominio de aplicación o tarea.

Los componentes clientes son aplicaciones que acceden a los servicios de por lo menos un servidor. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 29

La interacción entre los clientes y los servidores está basada en un modelo dinámico, el cual posibilita a los servidores poder también actuar como clientes. Este modelo de interacción dinámica difiere de la noción tradicional de Cliente-Servidor, en el que los roles de clientes y servidores están estáticamente definidos. Desde el punto de vista de una aplicación se puede considerar a los clientes como aplicaciones y a los servidores como bibliotecas. Note que los clientes no necesitan saber la ubicación de los servidores a los cuales ellos acceden. Esto es importante porque permite agregar nuevos servicios y mover los servicios existentes a otras ubicaciones, incluso mientras el sistema está corriendo. Clase

Colaborador Cliente

Responsabilidades - Implementa la funcionalidad del usuario - Envía solicitudes al Server a través del Proxy del lado del cliente

- Proxy del lado del Cliente

- Broker

Clase

Colaborador Servidor

Responsabilidades - Implementa los servicios - Se registra a si mismo con el broker local - Envía respuestas y excepciones hacia el cliente a través del Proxy del lado del servidor

- Proxy del lado del Servidor

- Broker

Figura 4.10 - Clases Cliente y Servidor

El componente broker es responsable de la transmisión de solicitudes de los clientes a los servidores, como de la transmisión de respuestas y excepciones al cliente. También debe tener alguna forma de localizar al receptor de una solicitud basada en su único identificador del sistema. Un broker ofrece APIs a los clientes y a los servidores para que incluyan operaciones para registrar y para invocar los métodos del servidor. Cuando una solicitud llega a un servidor que es mantenida por el broker local, éste pasa la solicitud directamente al servidor. Si el servidor esta actualmente inactivo, el broker lo activa. Todas las respuestas y excepciones de la ejecución de un servicio son remitidas por el broker al cliente que envió la solicitud. Si el servidor especificado es direccionado por otro broker, el broker local encuentra una ruta al broker remoto y envía la solicitud usando esta ruta. Dependiendo de los requisitos de todo el sistema, se puede integrar en el broker servicios adicionales, tal como los servicios de nombre o soporte de marshaling. Clase

Colaborador Broker

Responsabilidades - Registra y da de baja servidores. - Ofrece APIs. - Transfiere mensajes. - Se recupera de errores. - Interopera con otros brokers a través de los puentes. Localiza servidores

- Cliente - Servidor - Proxy del lado del cliente - Proxy del lado del servidor - Puente

Figura 4.11 - Clase Broker


Pag 30

Los componentes proxies del lado del cliente representan una capa entre el cliente y el broker. Esta capa adicional proporciona transparencia, el cliente ve a un objeto remoto como si fuese local. Los proxies permiten el ocultamiento de los detalles de implementación desde los clientes como: •

•

•

El mecanismo de comunicación inter-procesos usados para transferencia de mensaje entre clientes y broker. La creación y eliminación de bloques de memoria. El marshaling de parámetros y resultados.

Cuando se retorna los resultados o excepciones desde un servidor, el proxy del lado del cliente recibe el mensaje entrante desde el broker, realiza el unmarshaling de los datos y lo envía al cliente. Los componentes proxies del lado del servidor son generalmente análogos a los proxies del lado del cliente. La diferencia es que son responsables de la recepción de las solicitudes, desempaquetar los mensajes entrantes, realizar el unmarshaling de los parámetros, y llamar al servicio apropiado. Además se usan para realizar el marshaling de los resultados y excepciones antes de enviarlos al cliente. Clase Proxy del lado del Cliente

Colaborador - Cliente - Broker

Clase Proxy del lado del Servidor Responsabilidades

Responsabilidades

Colaborador - Servidor - Br ok er

- Llama a los servicios con/en el servidor - Encapsula funcionalidad especifica del sistema - Media entre el Servidor y el broker

- Encapsula funcionalidad especifica del sistema - Media entre el cliente y el broker

Figura 4.12 - Clases Proxy del lado del Cliente y Proxy del lado del Servidor.

Los componentes bridges son componentes opcionales usados para ocultar los detalles de implementación cuando dos broker ínter-operan en una red heterogénea. Si se transmiten las solicitudes sobre la red, los diferentes brokers tienen que comunicarse independientemente del uso de redes y sistemas operativos diferentes. Un bridge construye una capa que encapsula todos estos detalles específicos del sistema. Este responde a un patrón de diseño cuya descripción se hace en el capítulo siguiente. Clase Bridge

Responsabilidades

Colaborador - Broker - Bridge

- Encapsula la funcionalidad de una red especifica - Media entre el broker local y el bridge de un broker remoto

Figura 4.13 - Clase Bridge. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 31

Hay dos tipos diferentes de sistemas Broker: aquellos que usan comunicación directa y aquellos que usan comunicación indirecta. Para lograr una buena performance, algunas implementaciones broker establecen sólo el enlace de comunicación inicial entre un cliente y un servidor, mientras el resto de la comunicación se hace directamente entre los componentes participantes -mensajes, excepciones y respuestas son transferidas entre proxies del lado del cliente y proxies del lado del servidor sin usar al broker como una capa intermedia. Esta comunicación implica que requerimientos de los servidores y clientes usen y entiendan el mismo protocolo.

Proxy del lado del cliente

Broker

Proxy del lado del Servidor

Cliente

Bridge

Servidor

Figura 4.14 - Estructura del patrón Broker

Consecuencias El patrón arquitectónico Broker tiene algunas ventajas importantes: o

o

o

o

o

Transparencia. Como el broker es responsable de localizar un servidor usando un único identificador, los clientes no necesitan saber dónde se localizan los servidores. De igual forma, los servidores no se preocupan de la ubicación de los clientes que les realizan requerimientos ya que ellos reciben todas las solicitudes del componente broker local. Cambiabilidad y extensibilidad. Si los servidores cambian pero sus interfaces permanecen iguales, no tiene impacto funcional en los clientes. Modificando la implementación interior del broker pero no las API’s que él provee, no tiene otro efecto en los clientes y servidores más que cambios en la performance. El uso de proxies y bridges es una razón importante para facilitar la implementación de cambios. Portabilidad. El sistema Broker oculta detalles del sistema operativo y del sistema de red a clientes y servidores usando capas de indirección como las API’s, proxies y bridges. Cuando se requiere usar puertos es suficiente en la mayoría de los casos poner el puerto en el componente broker y sus APIs en una nueva plataforma y recompilar a los clientes y servidores, en estos casos, se recomienda estructurar los componentes del broker en capas Interoperabilidad. Diferentes sistemas Broker pueden interoperar si entienden un protocolo común para el intercambio de mensajes. Este protocolo es interpretado y manejado por bridges que son los responsables de traducir el protocolo específico del broker en el protocolo común y viceversa. Reusabilidad . Al construir nuevas aplicaciones clientes, frecuentemente están basadas en la funcionalidad de la aplicación en servicios existentes.


Pag 32

El patrón arquitectónico Broker impone algunas desventajas: o

o

Eficiencia restringida. Aplicaciones que usan una implementación Broker son normalmente más lentas que las aplicaciones cuya distribución del componente es estática y conocida. Sistemas que dependen directamente de un mecanismo concreto para la comunicación interproceso dan mejor performance que una arquitectura Broker, porque el broker introduce capas de indirección que permite ser portable, flexible y cambiable. Baja tolerancia a fallos. Comparado con un sistema de software no distribuido, un sistema Broker puede ofrecer menos tolerancia a fallos. En caso que un servidor o un broker falle durante la ejecución de un programa, todas las aplicaciones que dependen del servidor o el broker son incapaces de continuar con éxito. Se puede aumentar la fiabilidad a través de la replicación de componentes.

El siguiente aspecto da ventajas así como también desventajas: o

Testing y debugging . Una aplicación cliente desarrollada de servicios probados es más robusta y fácil de testear. Sin embargo, realizar el testeo y la depuración de un sistema Broker es un trabajo tedioso debido a la cantidad de componentes involucrados.

Ejemplo El patrón arquitectónico Broker es utilizado para especificar la arquitectura CORBA. CORBA es una tecnología orientada a objetos para objetos distribuidos sobre sistemas heterogéneos. Un lenguaje de definición de interfaz esta disponible para soportar la interoperabilidad de objetos clientes y servidores.

Sistemas Interactivos Los sistemas actuales permiten un grado alto de interacción del usuario, generalmente, con la ayuda de interfaces de usuario gráficas. El objetivo es robustecer la utilidad de una aplicación. Estos sistemas proporcionan un acceso conveniente a sus servicios, lo cual permite a los usuarios aprender la aplicación y producir resultados rápidamente. Al especificar la arquitectura de tales sistemas, el desafío es mantener la funcionalidad central independiente de la interfaz de usuario. El centro de los sistemas interactivos esta basado en los requerimientos funcionales del sistema, y normalmente permanece estable. Las interfaces de usuario, sin embargo, están sujetas a cambio y modificación. Por ejemplo, es probable que se requiera a los sistemas contar con diferentes interfaces de usuario, o interfaces que deben ajustarse para articular en los procesos de negocio de un cliente. Estas arquitecturas requieren que las interfaces de usuario puedan ser modificadas sin causar efectos en la funcionalidad de una aplicación específica o al modelo de datos. Se describen dos patrones que brindan una organización estructural fundamental para software de sistemas interactivos:


Pag 33

El patrón Model-View-Controller (MVC) divide una aplicación interactiva en tres componentes. El modelo contiene la funcionalidad central y los datos. Las vistas despliegan el información al usuario. Los controladores se ocupan de las entradas del usuario. Las vistas y controladores juntos forman la interfaz de usuario. Un mecanismo de propagación de cambios asegura la consistencia entre la interfaz de usuario y el modelo. - El patrón Presentation-Abstraction-Control (PAC) define una estructura para los sistemas interactivos en forma de una jerarquía de agentes de cooperantes. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y consiste de tres componentes: presentación, abstracción y control. Esta subdivisión separa los aspectos de interacción de hombre-computadora de los agentes de su centro funcional y su comunicación con otros agentes. -

MVC brinda probablemente la más conocida organización arquitectónica para los sistemas de software interactivos. PAC es una alternativa para estructurar aplicaciones interactivas, y sobre todo aplicable a sistemas que cuentan con varios subsistemas confiados en si mismo. También dirige problemas que MVC deja sin resolver, tal como organizar eficazmente la comunicación entre diferentes partes de la funcionalidad central y la interfaz de usuario. Model-View-Controller

El patrón arquitectónico Model-View-Controller (MVC) divide una aplicación interactiva en tres componentes. El Modelo contiene la funcionalidad central y los datos, las Vistas despliegan la información al usuario y los Controladores manejan la entrada del usuario. Estos dos últimos componentes, en conjunto, forman la interfaz del usuario. Un mecanismo de propagación de cambio asegura la consistencia entre la interfaz del usuario y el modelo. Contexto Aplicaciones interactivas con una interfaz de usuario flexible. Problema Las interfaces del usuario son especialmente propensas a cambios en los requerimientos. Un cliente puede requerir una adaptación específica de la interfaz. Diferentes usuarios pueden definir requisitos contradictorios sobre la interfaz de usuario en base a sus necesidades. Un data entry ingresa la información a través del teclado. Un gerente quiere usar el mismo sistema pulsando iconos y botones. En consecuencia, se debe contar con distintas interfaces de usuario para los mismos datos. Construir un sistema con la flexibilidad requerida es caro y propenso errores, si la interfaz de usuario se entreteje herméticamente con el centro funcional. Esto puede producir la necesidad de desarrollar y mantener varios sistemas de software substancialmente diferentes, uno para cada implementación de interfaz de usuario ya que los cambios resultantes se distribuyen por muchos módulos.


Pag 34

Las siguientes fuerzas influyen en la solución: La misma información es presentada en forma diferente en diferentes vistas. - Los cambios en los datos se deben reflejar inmediatamente en las vistas y el comportamiento. - Los cambios a la interfaz del usuario deben ser fáciles, e incluso posibles en tiempo de ejecución. -

Solución La separación de los componentes modelo, vista y controlador, permiten múltiples vistas del mismo modelo. Si el usuario cambia el modelo a través del controlador de una vista, se deben reflejar los cambios en todas las otras vistas que dependen de esos datos. El modelo notifica a todas las vistas siempre que sus datos hayan cambiado. Las vistas recuperan los nuevos datos del modelo y actualizan la información mostrada. Estructura El Model-View-Controller (MVC) divide una aplicación interactiva en tres áreas: procesamiento, entrada y salida. El modelo encapsula los datos centrales y tiene la funcionalidad de la aplicación. Es un componente totalmente independiente de las representaciones específicas de salidas o del comportamiento de la entrada. Los controladores reciben la entrada, normalmente como eventos que codifican los movimientos del mouse o entrada del teclado. Los eventos son traducidos para servir a las demandas del modelo o las vistas. El usuario interactúa con el sistema solamente a través de los controladores. Diferentes vistas presentan la información del modelo al usuario de distintas maneras. Pueden existir múltiples vistas de un mismo modelo, pero cada vista tiene una relación uno a uno con un controlador. Cada vista define un procedimiento de actualización que se activa por el mecanismo de propagación de cambios. Cuando es llamado el procedimiento de actualización, una vista recupera los valores de datos actuales del modelo para ser mostrados, y los pone en la pantalla El mecanismo de propagación de cambios mantiene un registro de los componentes dependientes dentro del modelo. Todas las vistas y controladores seleccionados indican en el registro que necesitan actualizar sobre los cambios producidos. Cualquier cambio de estado del modelo hace que se active el mecanismo de propagación de cambios y se propaguen las modificaciones en cada componente del sistema. Este mecanismo es el único eslabón entre el modelo, las vistas y los controladores.


Pag 35

Clase

Colaborador

Modelo

Responsabilidades

- Vista - Controlador

- Provee la funcionalidad central de la aplicación - Se registran vistas y controladores dependientes - Notifica a los componentes dependientes de los cambios

Figura 4.15 - Clase Modelo

Durante la inicialización todas las vistas son asociadas con el modelo y registradas por el mecanismo de propagación de cambios. Cada vista crea su controlador. Las vistas ofrecen a menudo funcionalidad que permite a los controladores manejar la forma en que se muestran los datos. Esto es útil para operaciones de usuarios activos que no afectan al modelo, como es hacer un scroll. Los controladores aceptan la entrada del usuario como eventos. Depende de la plataforma de la interfaz del usuario la forma en que estos eventos se entregan al controlador. Los eventos se traducen en las demandas para el modelo o la vista asociada. Si la conducta de un controlador depende del estado del modelo, se registra con el mecanismo de propagación de cambios e implementa un procedimiento de actualización. Clase Controlador

Responsabilidades

Clase Vista

Colaborador - Vista - Modelo

Responsabilidades

- Acepta las entradas del usuario como eventos - Traduce eventos a solicitudes para el modelo o muestra solicitudes para la vista - Implementa la actualización

Colaborador - Vista - Modelo

- Crea e inicializa su controlador asociado - Muestra la información al usuario - Implementa los procedimientos de actualización - Recupera los datos desde el Modelo

Figura 4.16 - Clases Controlador y Vista

La integración de los componentes en este patrón es Vista

Controlador

Modelo

Figura 4.17 - Estructura del Patrón MVC

Consecuencias La aplicación Model-View-Controller tiene varias ventajas: o

Múltiples vistas del mismo modelo. MVC separa al modelo de los componentes de la interfaz de usuario. Múltiples vistas pueden ser implementadas y usadas con un simple modelo.


Pag 36

o

o

o

o

Vistas sincronizadas. El mecanismo de propagación de cambios del modelo asegura que todos los observadores registrados son notificados de los cambios en los datos de la aplicación, en el momento correcto. Esto sincroniza todas las vistas y controladores dependientes. Cambios en vistas y controladores. La separación conceptual de MVC permite intercambiar los objetos de las vistas y los controladores de un modelo incluso en tiempo de ejecución. Cambiabilidad. Como el modelo es independiente de todo el código de la interfaz de usuario, exportar una aplicación MVC a una nueva plataforma no afectaría la funcionalidad central de la aplicación, solo es necesario la implementación conveniente para esa plataforma, de los componentes vistas y controladores. El potencial del framework . Es posible basar una aplicación framework en este patrón.

Las desventajas de MVC son: o

o

o

o

o

Incremento de la complejidad . Seguir estrictamente la estructura MVC, no siempre es la mejor manera de construir una aplicación interactiva. También se sostiene que el uso de los componentes separados del modelo, la vista y el controlador para los menús y los elementos de texto simples implica un aumento de la complejidad sin ganar mucha flexibilidad. Excesivos número de actualizaciones . Si una sola acción del usuario implica varias actualizaciones, el modelo debe pasar por alto las notificaciones intermedias innecesarias de los cambios dado que no todas las vistas están interesadas en que el modelo propague cada una de las modificaciones. Conexión entre vistas y controladores . Controladores y vistas son componentes separados pero estrechamente relacionados que impiden su rehúso individual. Es improbable que una vista sea usada sin su controlador, o viceversa, con la excepción de vistas de sólo lectura que comparten un controlador que ignore todas las entradas. Acoplamiento de vistas y controladores con un modelo . Los componentes vista y controlador hacen llamadas directas al modelo. Esto implica que cambios en la interfaz del modelo probablemente rompan el código de vista y controlador. Este problema se magnifica si el sistema usa múltiples vistas y controladores. Ineficacia en la vista para acceder a los datos. Dependiendo de la interfaz del modelo, una vista puede necesitar hacer múltiples llamadas al modelo para obtener todos los datos a mostrar. Solicitar innecesariamente al modelo datos inalterados debilita la performance si las actualizaciones son frecuentes. Guardando en caché los datos dentro de la vista, mejora la performance.

Ejemplo El patrón MVC se ve frecuentemente en aplicaciones interactivas, como por ejemplo, en un editor gráfico. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 37

Presentation-Abstraction-Control

El patrón arquitectónico Presentation-Abstraction-Control (PAC) define una estructura para los sistemas de software interactivos en forma de jerarquía de agentes cooperantes. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y tiene tres componentes: presentación, abstracción, y control. Esta subdivisión separa los aspectos de interacción usuario-computadora del agente central funcional y su comunicación con otros agentes. Contexto El desarrollo de una aplicación interactiva con ayuda de agentes. Problema Los sistemas interactivos pueden verse a menudo como un conjunto agentes cooperantes. Como ser, agentes especializados en la interacción usuario-computadora que aceptan la entrada del usuario y el despliegue de los datos, más otros agentes que mantienen el modelo de datos del sistema y ofrecen funcionalidad que opera sobre esos datos y, además, otros agentes adicionales responsables de las diversas tareas como el manejo de errores o la comunicación con otros sistemas de software. En esta arquitectura de cooperación de agentes, cada agente se especializa en una tarea específica, y todos juntos proporcionan la funcionalidad del sistema. Las fuerzas siguientes afectan la solución: -

-

Los agentes a menudo mantienen su propio estado y datos. Los agentes individuales deberían cooperar eficazmente para proporcionar la tarea global de la aplicación. Para lograr esto, se necesitaría un mecanismo de intercambio de datos, mensajes, y eventos. Los agentes interactivos deberían proporcionar su propia interfaz de usuario, debido a que las interacciones usuario-computadora difieren a menudo ampliamente. Los sistemas evolucionan con el tiempo. El aspecto de la presentación es particularmente propenso cambios. Los cambios de agentes individuales, o la extensión del sistema con nuevos agentes, no deberían afectar a todo el sistema.

Solución La estructura de una aplicación interactiva es como un árbol de jerarquía de agentes PAC. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación, y consiste en tres componentes: presentación, abstracción y control. La jerarquía entera refleja las dependencias transitivas entre agentes. Cada agente depende de todos los agentes de niveles más altos y así hasta llegar al agente de nivel superior. Cada componente de un agente PAC tiene una tarea específica: •

•

El componente presentación proporciona la conducta visible del agente. El componente abstracción mantiene el modelo de datos que fundamenta al agente y proporciona la funcionalidad para operar sobre esos datos.


Pag 38

•

El componente control conecta los componentes presentación y abstracción, y proporciona la funcionalidad de comunicación con otros agentes.

Debe haber agentes de nivel superior, algunos agentes de nivel intermedio y más aun agentes de nivel inferior. El agente PAC de nivel superior proporciona el centro funcional del sistema, además incluye las partes de la interfaz del usuario que no pueden ser asignadas a subtareas particulares. Los agentes PAC de nivel medio representan cualquier combinación o relación entre los agentes de niveles más bajos. Por ejemplo un agente de este nivel puede mantener varias vistas de los mismos datos. Los agentes PAC de nivel inferior representan su propio contenido semántico de los conceptos en los cuales los usuarios del sistema pueden actuar, como las hojas de cálculo o gráficos permitiendo a los usuarios realizar acciones sobre estos. Estructura La responsabilidad principal del agente PAC de nivel superior es habilitar el modelo de datos global del software, mediante la funcionalidad de sus componentes: El componente presentación tiene a menudo pocas responsabilidades. Puede incluir los elementos de interfaz del usuario común a toda la aplicación. - La interfaz del componente abstracción ofrece funciones para manipular el modelo de los datos y para recuperar su información. - El componente control tiene tres responsabilidades: Permite a los agentes de nivel inferior hacer uso de los servicios de los agentes de nivel superior, principalmente acceder y manipular el modelo global de datos. Coordina y mantiene la información de la jerarquía de agentes PAC. El componente control usa esta información para asegurarse de la correcta colaboración e intercambio de datos entre agente de nivel superior e inferior. Mantiene la información sobre la interacción del usuario con el sistema. -

•

•

•

Los agentes PAC de nivel inferior representan un concepto semántico específico del dominio de la aplicación, también pueden implementar servicios del sistema. Este concepto semántico puede ser de tan bajo nivel como un objeto gráfico simple. La funcionalidad de sus componentes es: El componente presentación muestra una vista específica del concepto semántico correspondiente, y proporciona acceso a todas las funciones de usuario que él puede brindar. - El componente abstracción mantiene agentes específicos de datos, pero ningún otro agente PAC depende de estos datos. - El componente control mantiene la consistencia entre los otros dos componentes. -


Pag 39

Estos componentes se comunican con los agentes de alto nivel para intercambiar eventos y datos. Los eventos entrantes son remitidos al componente presentación del agente de nivel inferior, mientras que los datos entrantes se remiten a su componente abstracción. Los eventos y datos de salida, por ejemplo los mensajes del error, son enviados a un agente de nivel superior asociado. Los agentes PAC de nivel intermedio pueden cumplir dos papeles diferentes: composición y coordinación entre el agente de nivel inferior, por ejemplo al coordinar múltiples vistas de los mismos datos. Sus componentes deben: •

•

•

mantener los datos específicos del agente, en caso del componente abstracción, el componente presentación, implementar su interfaz de usuario y el componente control, tener las mismas responsabilidades que los componentes control de los agentes de nivel inferior y nivel superior.

Clase Agente de niv el superior

Responsabilidades - Proveer la funcionalidad central del sistema - Controlar la jerarquía PAC

Colaborador - Agente de niv el Intermedio

- Agente de niv el Inferior

Clase Agente de niv el Inferior

Responsabilidades - Proveer una vista especifica del software o un servicio del sistema, incluyendo su interacción humanocomputadora asociada.

Clase Agente de nivel Intermedio

Responsabilidades - Controlar los agentes PAC de niveles mas bajos . - Compone a los agentes PAC de nivel mas bajo en simples unidades de abstracción superior

Colaborador - Agente de niv el superior

- Agente de niv el Intermedio - Agente de niv el Inferior

Colaborador - Agente de niv el superior

- Agente de niv el Intermedio

Figura 4.18 - Clases de los Agentes PAC.

Si observamos la integración de los componentes PAC con su correspondiente estructura interna


Pag 40

Pr esentación

Abstr acción Agentes de Nivel Superior

Control

Pr esentación

Abstr acción

Pr esentación

Abstr acción Agentes de Nivel Intermedio

Control

Pr esentación

Abstracción

Control

Pr esentación

Abstracción

Pr esentación

Abstracción Agentes de Nivel Inferior

Control

Control

Control

Figura 4.19 - Integración de clases de los Agentes PAC.

Consecuencias El patrón arquitectónico Presentation-Abstraction-Control tiene varias ventajas: o

o

o

Separar intereses . Agentes separados representan diferentes conceptos semánticos en el dominio de la aplicación. Cada agente mantiene su propio estado y datos en forma coordinada e independiente de otro agente. Cambiabilidad y extensibilidad . Los cambios dentro de los componentes presentación o abstracción de un agente no afectan a otros agentes en el sistema. Esto permite modificar individualmente el modelo de datos que está debajo de un agente o cambiar su interfaz de usuario. Nuevos agentes se integran fácilmente en una arquitectura PAC existente sin mayores cambios para el resto. Todos ellos se comunican entre sí a través de una interfaz predefinida. Multitarea . Los agentes pueden distribuirse fácilmente en diferentes hilos, procesos, o máquinas.

Las desventajas de este patrón son las siguientes: o

o

o

Incremento en la complejidad del sistema. La implementación de cada concepto semántico dentro de una aplicación como su propio agente, puede resultar en una estructura compleja del sistema. Complejidad en el componente control. Los componentes control son los mediadores de la comunicación entre los otros dos componentes de un agente, y entre los diferentes agentes. La calidad de la implementación del componente control es, por consiguiente, crucial para una colaboración eficaz entre agentes, y para la calidad global de la arquitectura del sistema. Decremento en la eficacia . El costo de comunicaciones entre agentes puede impactar en la eficacia del sistema. Por ejemplo, si un agente de nivel inferior recupera los datos del agente de nivel superior, todos los agentes del nivel intermedio de la jerarquía PAC estarán involucrados en este intercambio de datos.


Pag 41

Ejemplo Considerar un sistema de información de censos que permite observar el crecimiento demográfico con representaciones proporcionales. Este ofrece una hoja de cálculos para el ingreso de los datos y varias formas de tablas y gráficos para representar las regiones. Los usuarios interactúan con el software a través de interfases gráficas. Sin embargo, diferentes versiones adaptan la interfaz del usuario según sus necesidades específicas. Por ejemplo una versión soporta la asignación de recursos dependiendo de las necesidades de cada región. Por lo tanto, en este ejemplo se puede definir un agente PAC de nivel superior que provea el acceso al almacenamiento de datos subyacente del sistema. El almacenamiento de datos por si mismo no es parte de la aplicación. Para realizar el nivel inferior se especifican cuatro agentes de PAC: un agente de la hoja de cálculo para los datos de entrada y tres agentes de vista para cada tipo de diagrama para representar los datos. La aplicación tiene un agente PAC intermedio que coordina a los tres agentes de vista del nivel inferior y los mantiene consistentes. El agente de la hoja de cálculo se conecta directamente al agente PAC de nivel superior. Los usuarios del sistema sólo interactúan con los agentes de nivel superior.

Sistemas Adaptables Los sistemas evolucionan con el tiempo - se agrega nueva funcionalidad y los servicios van cambiando. Ellos deben soportar nuevas versiones de operar sistemas operativos, otras plataformas, otras interfases de usuarios y bibliotecas. Puede ser necesario adaptarlos a nuevos estándares o plataformas. También puede ser necesario proporcionar servicios que difieran de un cliente a otro. Diseñar para cambios es, por consiguiente, la mayor preocupación al especificar la arquitectura de un sistema de software. Una aplicación debe soportar su propia modificación y extensión a priori. Los cambios no deberían afectar la funcionalidad central, o diseños de abstracción claves, por otra parte el sistema debe ser fácil de mantener y sencillo para adaptarlo a requisitos cambiantes. En esta sección se describen dos modelos que ayudan al diseño para sistemas que se adaptan al cambio: El patrón Microkernel se aplica a los sistemas de software que deben adaptarse a requisitos cambiantes del sistema. Separa la funcionalidad central mínima de la funcionalidad extendida y las partes específicas de los clientes. El microkernel también sirve como socket para conectar extensiones y coordinar sus colaboraciones. - El patrón Reflection provee un mecanismo para estructuras cambiantes y conductas dinámicas de sistemas de software. Apoya la modificación de aspectos fundamentales, como el tipo de estructuras y mecanismos de llamadas a función. En este patrón, una aplicación es dividida en dos partes. Un meta nivel que proporciona información sobre las propiedades seleccionadas del sistema y un nivel base que incluye la lógica de la aplicación. Su aplicación se construye sobre el meta nivel. Los cambios a la información contenidos en el meta nivel, afectan al comportamiento del nivel base. -


Pag 42

Microkernel

El patrón arquitectónico Microkernel se aplica a los sistemas de software que pueden adaptarse a cambios en los requerimientos. Éste separa una función mínima central de la funcionalidad extendida y partes específicas del cliente. El microkernel también sirve como un socket para conectar estas extensiones y coordinar su colaboración. Contexto El desarrollo de varias aplicaciones usando interfaces de programación similares que cuentan con la misma funcionalidad central. Problema Desarrollar un software para un dominio de aplicación que necesita cubrir un gran espectro de estándares y tecnologías similares es una tarea no trivial. Los ejemplos más conocidos son las plataformas de la aplicación como los sistemas operativos e interfaces de usuario gráficas. Las siguientes fuerzas necesitan particular atención al diseñar tales sistemas: La plataforma de aplicación debería cubrir una continua evolución del hardware y software. - La plataforma de aplicación debería ser portable, extensible y adaptable para permitir una fácil integración de tecnologías emergentes. - Las aplicaciones podrían ser categorizadas en grupos que usan la misma funcionalidad central de formas diferentes, requiriendo de la plataforma subyacente de aplicación para emular los estándares existentes. - La función central de la plataforma de aplicación debería separarse en un componente con tamaño de memoria mínimo, y servicios que consuman la menor cantidad de posible procesamiento. -

Solución Encapsular los servicios fundamentales de la plataforma de aplicación en un componente Microkernel. El microkernel incluye la funcionalidad que habilita a otros componentes que corren en procesos separados a comunicarse entre sí y también es responsable de mantener los recursos del sistema tales como archivos o procesos. Además, proporciona interfaces que permiten a otros componentes acceder a su funcionalidad. La funcionalidad central que no puede ser implementada dentro del microkernel sin aumentar su tamaño o complejidad innecesariamente se debe separar en servidores internos. Los servidores externos implementan su propia vista del microkernel subyacente. Para construir esta vista, usan las interfaces del microkernel. Cada servidor externo es un proceso separado que representa una plataforma de aplicación. Los clientes se comunican con servidores externos usando medios de comunicación proporcionados por el microkernel. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 43

Un sistema Microkernel puede verse como una plataforma de aplicación que integra otras plataformas de aplicación. Estructura El patrón Microkernel define cinco tipos de componentes participantes: El microkernel representa el componente principal del patrón. Éste implementa servicios centrales como los medios de comunicación o el mantenimiento, control y coordinación de recursos como procesos y archivos. Otros componentes cuentan con todos o algunos de estos servicios básicos, esto lo hacen indirectamente usando una o más interfaces que comprenden la funcionalidad expuesta por el microkernel. Además el componente microkernel encapsula muchas dependencias específicas del sistema. Los clientes sólo ven las vistas particulares del dominio de la aplicación subyacente y de la plataforma específica. Clase Microkernel Responsabilidades

Colaborador - Servidor Interno

- Provee los mecanismos c entrales - Ofrece facilidades de comunicación - Encapsula sistemas dependientes - Maneja y controla los recursos

Figura 4.20 - Clase Microkernel

Un servidor interno representa un componente separado que extiende la funcionalidad provista por el microkernel por medio de las demandas de servicio. Estos servidores sólo son accesibles por el microkernel. Los servidores internos pueden encapsular algunas dependencias sobre el hardware subyacente o sistema de software. Clase Servidor Interno

Colaborador - Microkernel

Responsabilidades - Implementa servicios adicionales - Encapsula algunos sistemas específicos

Figura 4.21 - Clase Servidor Interno

Un servidor externo es un componente que usa el microkernel para implementar su propia vista del dominio de aplicación subyacente. Diferentes servidores externos implementan políticas diferentes para dominios de aplicación específicos. Los servidores externos exponen su funcionalidad exportando interfaces de la misma manera que lo hace el propio microkernel. Cada uno de estos servidores corre en un proceso separado. Recibe solicitudes de servicio de aplicaciones del cliente, interpreta estas solicitudes, ejecuta los servicios apropiados y retorna los resultados a los clientes. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 44

Clase

Colaborador

Servidor Externo

- Microkernel

Responsabilidades - Mantiene las interfases programadas de los clientes - Encapsula algunos sistemas específicos

Figura 4.22 - Clase Servidor Externo

Un cliente es una aplicación que está asociada con solo un servidor externo, y solamente accede a la interfaz de programación que éste le proporciona. Los adaptadores representan interfaces entre los clientes y sus servidores externos, y les permite a los clientes acceder a los servicios del servidor de una manera portable. Ellos son parte del espacio de dirección del cliente. Los adaptadores también protegen a los clientes de los detalles de implementación específicos del microkernel. Clase Cliente

Clase

Colaborador - Adapter

Colaborador Adapter

- Servidor Externo

Responsabilidades

Responsabilidades

- Representa a una aplicación

- Ocultan al cliente dependencias del sistema tales como los mecanismos de comunicación - Invoca métodos del servidor externo en nombre de los clientes

- Microkernel

Figura 4.23 - Clases Cliente y Adapter

El siguiente diagrama muestra la estructura estática de un sistema Microkernel. El componente microkernel colabora el servidor externo, el servidor interno y adaptadores. Cada cliente es asociado con un adaptador usado como un bridge entre el cliente y el servidor externo. El servidor interno es solo accesible por el componente microkernel. llama Servidor Externo

activa Microkernel

Servidor Interno

Inicializa comunicacion envía requerimientos

Adapter

llama servicios

Cliente

Figura 4.24 - Estructura de un sistema Microkernel

Consecuencias El patrón de Microkernel ofrece algunas ventajas importantes: Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 45

o

Portabilidad . Ofrece un alto grado de portabilidad por dos razones: En la mayoría de los casos no se necesita servidores externos o aplicaciones clientes portables si se traslada el sistema Microkernel a un nuevo ambiente de software o hardware. La migración del microkernel a un nuevo ambiente de hardware solamente requiere modificaciones en las partes dependientes del hardware. Flexibilidad y Extensibilidad. Para implementar una vista adicional, se agrega un nuevo servidor externo. Para extender el sistema con capacidades adicionales solo requiere la suma o extensión de servidores internos. Separación de política y mecanismo . Proporciona todos los mecanismos necesarios para habilitar a los servidores externos a implementar sus políticas, lo provoca que aumento en la mantenibilidad y cambiabilidad de todo el sistema. Además, permite agregar nuevos servidores externos que implementen sus propias vistas especializadas. Escalabilidad . Un sistema Microkernel distribuido es aplicable al desarrollo de sistemas operativos o sistemas de base de datos para redes de computadora, o multiprocesadores con memoria local. Si el sistema Microkernel trabaja sobre una red de máquinas, cuando se agrega una nueva máquina a la red, es sencillo escalar el sistema Microkernel a la nueva configuración. Fiabilidad . Para lograr fiabilidad se requiere disponibilidad y tolerancia a fallos. Esta arquitectura permite correr el mismo servidor en más de una máquina, incrementando la disponibilidad y la tolerancia a fallos de una máquina o servidor. Transparencia . En un sistema distribuido los componentes pueden distribuirse sobre una red de máquinas. En dicha configuración, la arquitectura Microkernel permite a cada componente acceder a otros componentes sin necesidad de conocer su ubicación. 



o

o

o

o

o

La arquitectura Microkernel también tiene las siguientes desventajas: o

o

Performance . La performance es menor que la de un sistema del software monolítico diseñado para ofrecer una vista específica. Complejidad de diseño e implementación . Desarrollar un sistema Microkernel es una tarea no trivial. Además, la separación entre los mecanismos y las políticas requieren el conocimiento del dominio en profundidad y un esfuerzo considerable durante el análisis y el diseño.

Ejemplo Por ejemplo si necesitáramos un sistema operativo que se pueda portar a otro hardware, y que ejecute programas escritos para sistemas operativos populares existentes (Unix, Windows), podríamos aplicar este patrón.


Pag 46

Reflection

El Patrón arquitectónico Reflection provee un mecanismo para estructura cambiante y conducta dinámica de sistemas de software. Soporta la modificación de aspectos fundamentales como los tipos de estructuras y mecanismos de llamada a función. En este patrón, una aplicación es dividida en dos partes: un meta nivel que provee información sobre las propiedades del sistema seleccionadas y un nivel base que incluye la lógica de la aplicación. La implementación se construye en el meta nivel. Los cambios en la información contenida en el meta nivel afectan la conducta del nivel base subsiguiente. Contexto Construcción de Sistemas que soportan su propia modificación a priori. Problema Los sistemas del software evolucionan con el tiempo. Deben estar abiertos a modificaciones en respuesta a cambios tecnológicos y de requerimientos. Diseñar un sistema que encuentre un amplio rango de diferentes requisitos a priori puede ser una tarea ardua. Una buena solución es especificar una arquitectura que esté abierta a la modificación y extensión. El sistema resultante puede entonces adaptarse a los cambios en los requisitos bajo demanda. Varias fuerzas son asociadas con este problema: -

-

-

-

-

Cada cambio en el sistema debe ser implementado y debe probarse cuidadosamente. El software que activamente soporta y controla su propia modificación debe cambiarse en forma eficaz y segura. Los sistemas de software adaptables normalmente tienen una estructura interna compleja. Aspectos que están sujetos a cambios son encapsulados dentro de componentes separados. La implementación de servicios de la aplicación se extiende sobre varios componentes pequeños con diferentes relaciones entre ellos. Para conservar dichos sistemas mantenibles, se prefiere esconder esta complejidad del mantenimiento del sistema. Las técnicas necesarias para un sistema cambiable, como la parametrización, subclases, son también las que hacen difícil y compleja su modificación. Contar con un mecanismo uniforme para todos los tipos de cambios es más fácil de usar y entender. Los cambios pueden ser a cualquier escala, desde proveer un conjunto de teclas rápidas para comandos usados normalmente como también adaptar una aplicación framework para un cliente específico. Incluso pueden cambiar aspectos fundamentales de sistemas de software por ejemplo los mecanismos de comunicación entre los componentes.


Pag 47

Solución Se deben seleccionar aspectos de la estructura y la conducta que sean accesible a la adaptación y el cambio. Esto conlleva a una arquitectura que esta dividida en dos partes principales: un meta nivel y un nivel base. El meta nivel proporciona una representación propia del software para darle el conocimiento de su propia estructura y conducta y consiste en metaobjetos que encapsulan y representan la información sobre el software. El nivel base define la lógica de la aplicación. Su implementación usa los metaobjetos para permanecer independiente de esos aspectos que son probables de cambiar. Por ejemplo, los componentes del nivel base sólo pueden comunicarse entre sí a través de un metaobjeto que implementa un mecanismo específico de llamada a función definida por el usuario. Cambiando el metaobjeto, cambia la manera en que los componentes del nivel base se comunican, pero sin modificar el código del nivel base. Se especifica una interfaz para manipular los metaobjetos llamada protocolo del metaobjeto (MOP), y permite a los clientes especificar los cambios particulares como la modificación de mecanismo de llamada a función del metaobjeto. El propio protocolo es responsable de verificar la exactitud de la especificación del cambio y realizar dicho cambio. Cada manipulación de los metaobjetos a través de su protocolo afecta el comportamiento del nivel base subsiguiente. Estructura El meta nivel consiste en un conjunto de metaobjetos. Cada metaobjeto encapsula la información seleccionada sobre un solo aspecto de la estructura, la conducta o estado del nivel base. Hay tres fuentes para tal información: •

•

•

proporcionado por el ambiente en tiempo de ejecución del sistema, definido por el usuario, como el mecanismo de llamada a función o recuperado del nivel base en tiempo de ejecución.

Todos los metaobjetos en conjunto proporcionan una misma representación de una aplicación. Los metaobjetos construyen la información, la cual está por una parte sólo implícitamente disponible, y por otra explícitamente accesible y modificable. Al menos cada sistema interno puede describirse de esta manera. Por ejemplo, en un sistema distribuido puede haber metaobjetos que proporcionan la información sobre la ubicación física de componentes de nivel base. Otro componente de nivel base pueden usar estos metaobjetos para determinar si sus compañeros de comunicación son locales o remotos. Sólo detalles del sistema que son probables de cambiar o qué varía de cliente a cliente debe encapsularse por los metaobjetos. La interfaz de un metaobjeto permite al nivel base acceder al mantenimiento de la información o al servicio que ofrece. Por ejemplo, un metaobjeto que proporciona la información de la ubicación acerca de un componente distribuido proporcionara las funciones para acceder al nombre e identificador del componente, información sobre el proceso en el cual esta ubicado e información acerca del host en el cual corre el Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 48

proceso. Un metaobjeto no permite al nivel base modificar su estado interno. La manipulación sólo es posible a través del protocolo del metaobjeto o por su propio cómputo. Mediante los modelos de nivel base y las implementaciones de la aplicación lógica del software representan varios de los servicios que ofrece el sistema como también el modelo de datos subyacente. El nivel base también específica la colaboración fundamental y las relaciones estructurales entre los componentes que incluye. Si el software incluye una interfaz de usuario, ésta también es parte del nivel base. El nivel base usa la información y los servicios provistos por los metaobjetos como la información de la ubicación de los componentes y mecanismos de llamada a función. Esto permite seguir siendo flexible -su código es independiente de aspectos que pueden estar sujetos al cambio y adaptación. Usando los servicios del metaobjeto, los componentes de nivel base no necesitan codificar la información sobre las ubicaciones concretas de sus pares de comunicación -ellos consultan los metaobjetos apropiados para esta información. Los componentes de nivel base se conectan directamente a los metaobjetos de los cuales ellos dependen. El componente de nivel base siempre consulta el mismo metaobjeto. Clase Nivel Base

Colaborador - Meta Nivel

Clase Meta Nivel

Colaborador - Nivel Base

Responsabilidades

Responsabilidades

- Encapsula el sistema interno que puede cambiar - Provee una interface interna para facilitar las modificaciones al meta nivel

- Implementa la lógica de la aplicación

Figura 4.25 - Clases Nivel Base y Meta Nivel

El protocolo metaobjeto (MOP) sirve como una interfaz externa al meta nivel y realiza la implementación de un sistema reflexivo. Los clientes del protocolo metaobjeto, los cuales pueden ser componentes de nivel base u otras aplicaciones, pueden especificar modificaciones a metaobjetos o a sus relaciones usando el nivel base. El mismo protocolo es responsable de realizar estos cambios. El protocolo Metaobjeto normalmente se diseña como un componente separado. Esto soporta la implementación de funciones que operan en varios metaobjetos. Por ejemplo, modificando metaobjetos que encapsulen información de ubicación a cerca de componentes distribuidos eventualmente requieren una actualización correspondiente al mecanismo de llamada a función de metaobjetos. Clase Colaborador Protocolo Metaobjeto Responsabilidades

- Meta Nivel - Nivel Base

- Ofrece una interfaz para cambios en el meta nivel -Lleva a cabo los cambios

Figura 4.26 - Clase Protocolo Metaobjeto Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 49

La estructura general de una arquitectura reflexiva es muy similar a un sistema Layer. El meta nivel y el nivel base son dos capas cada una de las cuales proporcionan su propia interfase. La capa de nivel base específica la interfaz del usuario para explotar la funcionalidad de la aplicación. La capa del meta nivel define el protocolo metaobjeto para modificar los metaobjetos. modifica MetaobjetoA

Meta Nivel

MetaobjetoB

modifica

Recupera información

Nivel Base

MOP

usa ComponenteA

usa

usa

ComponenteB

Interfase de Usuario provee acceso a

Figura 4.27 - Clase Protocolo Metaobjeto

Consecuencias El patrón Reflection proporciona las siguientes ventajas: o

o

o

Modificaciones no explicitas de código fuente. No se necesita tocar el código existente al modificar un sistema reflexivo. En cambio, se especifica un cambio llamando a una función del protocolo metaobjeto. Al extender el software, se pasa el nuevo código al meta nivel como un parámetro del protocolo metaobjeto. Este protocolo, por si mismo, es responsable de integrar sus solicitudes de cambio realizando modificaciones y extensiones al código del meta nivel y, si es necesario, recompila las partes cambiadas y realiza un enlace con la aplicación mientras está se esta ejecutando. Cambiar un sistema del software es fácil. El protocolo metaobjeto provee un mecanismo seguro y uniforme para realizar estos cambios. Esconde la complejidad interna de una aplicación a cambiar y toma el control sobre cada modificación. Soportar varios tipos de cambios. Los metaobjetos pueden encapsular cada aspecto del comportamiento del sistema, del estado y su estructura. Una arquitectura basada en este patrón soporta así potencialmente los cambios de casi cualquier tipo o escala.

El patrón Reflection tiene algunas desventajas significantes: o

Las modificaciones al meta nivel pueden causar daño. Aun el protocolo metaobjeto más seguro no prevé a los usuarios de especificar modificaciones incorrectas. Dichas modificaciones pueden causar serios daños al software o su ambiente. Por ejemplo modificar un esquema de base de datos sin suspender la ejecución de los objetos en la aplicación que lo usa, o el pasaje de código al protocolo metaobjeto que incluye errores semánticos. Además deben descubrirse errores potenciales dentro de las especificaciones de cambio antes de realizar el cambio. Cada cambio debe tener sólo efecto limitado en otras partes del software.


Pag 50

o

o

o

Incremento en el número de componentes . Puede suceder que un sistema software reflexivo incluya más metaobjetos que componentes de nivel base. Baja eficiencia . Los sistemas de software reflexivos son normalmente más lentos que los sistemas no-reflexivos. Esto es causado por la compleja relación entre el nivel base y el meta nivel. Siempre que el nivel base sea incapaz de decidir cómo continuar con el cómputo, pide ayuda al meta nivel. Esta capacidad reflexiva requiere procesamiento extra: recuperación de información, metaobjetos cambiantes, chequeo de consistencia, y la comunicación entre los dos niveles disminuye la performance global del sistema. Escasa cambiabilidad . Aunque un patrón Reflection ayuda con el desarrollo de software cambiable, se soportan sólo cambios que puedan realizarse a través del protocolo del metaobjeto. Como resultado, no es posible integrar fácilmente todos los cambios imprevistos a una aplicación, por ejemplo cambios o extensiones al código del nivel base.

Ejemplo CLOS (Common Lisp Object System) es un clásico ejemplo de un lenguaje de programación reflexiva. En CLOS las operaciones definidas por objetos son llamadas funciones genéricas y su procesamiento se refiere a invocaciones a funciones genéricas Una invocación a una función genérica es dividida en tres fases: El primer sistema determina los métodos que son aplicables a la invocación dada. - Luego ordena los métodos aplicables en orden decreciente de precedencia. - El sistema finalmente establece la ejecución de una lista de métodos aplicables. En CLOS más de un método puede ser ejecutado en respuesta a una invocación dada. -

El proceso de invocaciones de funciones genéricas es definido en el protocolo del metaobjeto de CLOS. Básicamente, este ejecuta una cierta secuencia de funciones genéricas del meta nivel. A través de CLOS, los usuarios del protocolo metaobjeto pueden variar la conducta de una aplicación modificando estas funciones genéricas o las funciones genéricas del metaobjeto llamados por ellos.


Pag 51

Capítulo 5

Patrones de Diseño Los patrones de diseño se han convertido en una técnica importante para el reuso del conocimiento de software. Cada patrón provee información sobre su diseño, describiendo las clases, métodos y relaciones que resuelven un problema de diseño en particular. Los patrones han sido agrupados y organizados en catálogos cada uno dando diferentes clasificaciones y descripciones. El proceso de construcción de aplicaciones utilizando patrones de diseño se reduce a que, cada vez que el diseñador encuentra un problema, busca en los catálogos un patrón que lo resuelva. Si existiera tal patrón, se deben identificar las clases, métodos y atributos de la aplicación que juegan el rol de aquellos prescritos por el patrón.

Patrones de Creación Estos patrones facilitan la creación de objetos en un sistema, debido a que la mayor parte de los sistemas Orientados a Objetos necesitan crear instancias de clases. Los patrones de creación muestran la guía de cómo crear objetos. Las decisiones que se deben tomar al momento de la creación de los objetos normalmente serán resueltas dinámicamente decidiendo qué clases instanciar o qué objetos delegarán responsabilidades sobre otros objetos. Es decir, los patrones de creación abstraen el proceso de instanciación, ayudan a independizar a un sistema, de cómo sus objetos son creados. En general, tratan de ocultar las clases y métodos concretos de creación, de tal forma que al variar su implementación, no se vea afectado el resto del sistema. Abstract Factory

Crea familias de objetos relacionados o dependientes sin necesidad de especificar su clase concretamente. Aplicabilidad Se usa el patrón Abstract Factory cuando el sistema a desarrollar debe: Ser independiente de cómo se crean, se componen y se representan sus productos. - Debería ser configurado mediante una de las múltiples familias de productos posibles. - Se diseña una familia de objetos relacionados que deben ser usados en conjunto. - Proveer una librería de una clase de productos y es necesario revelar simplemente sus interfaces, pero ocultar sus implementaciones. -


Pag 52

Participantes AbstractFactory: Declara una interfaz para operaciones que crean objetos de productos abstractos. ConcreteFactory: Implementa las operaciones para crear objetos de productos concretos. AbstractProduct: declara una interfaz para objetos de un tipo de producto ConcreteProduct: Define un objeto de producto que va a ser creado por su correspondiente ConcreteFactory. Cliente: usa solo interfaces declaradas.

AbstractFactory CreateProductA() CreateProductB()

Client AbstractProductA

ProductA2 Con creteFactory1

Con creteFactory2

CreateProductA() CreateProductB()

CreateProductA() CreateProductB()

ProductA1

AbstractProductB

Pro duct B2

Pro ductB1

Figura 5.1 - Patrón de Diseño Abstract Factory

Consecuencias El patrón Abstract Factory tiene las siguientes ventajas: o

o

o

Aísla clases concretas : Ayuda a controlar las clases de objetos que crea una aplicación. Debido a que una fabrica encapsula la responsabilidad y la creación de objetos de productos, ella aísla a los clientes de la implementación de clases, permitiéndoles manipular instancias a través de sus interfaces abstractas. Facilita el cambio en familias de productos : La clase de una fábrica concreta aparece solo una vez en la aplicación, lo que facilita su cambio en una aplicación. Promueve la consistencia entre los productos: Cuando los objetos de productos en una familia son designados a trabajar juntos, es importante que una aplicación utilice objetos de solo una clase a la vez.


Pag 53

El patrón Abstract Factory tiene las siguientes desventajas: o

Es difícil mantener nuevos tipos de productos : No es fácil extender una fábrica abstracta para que produzca nuevos tipos de productos, porque su interfaz fija el conjunto de productos que se pueden crear. Por lo cual agregar un nuevo producto requiere extender la interfaz de la fábrica, lo cual implica cambios en el código de la clase Abstract Factory y todas sus subclases.

Ejemplo Un ejemplo de uso del patrón Abstract Factory es su uso en la creación de widgets (ventanas, scroll-bars, botones, etc.) ya que su forma de implementación es dependiente del sistema operativo subyacente. Se declara una fábrica abstracta Widget, la cual implica varias fabricas concretas de widgets adaptadas a cada situación en particular (diferentes aplicaciones utilizan widgets de forma diferente ) de las cuales el usuario no se da cuenta de su existencia. Builder

Separa el proceso de construcción de un objeto complejo de su representación, para que el mismo proceso de construcción pueda crear diferentes representaciones. Aplicabilidad Se utiliza el patrón Builder cuando: El algoritmo para crear objetos complejos debe ser independiente de las partes que constituyen el objeto y la forma en que son ensamblados. - La construcción de procesos debe permitir diferentes representaciones para el objeto que se construye. -

Participantes Builder : Especifica una interfaz abstracta para crear partes de un objeto de Producto . ConcreteBuilder : Construye y ensambla partes del producto mediante la implementación del patrón Builder, define y controla la representación que crea, y además, provee una interfaz para consultar el producto. Director: construye un objeto usando el patrón Builder Producto : Representa al objeto complejo bajo construcción. ConcreteBuilder crea la representación interna del producto y define el proceso por el cual es ensamblado.


Pag 54

Director Construct()

Builder BuildPart() Product

for all objects in structure { builder -> BuildPart() }

ConcreteBuilder BuildPart() GetResult()

Figura 5.2 - Patrón de Diseño Builder

Consecuencias Las consecuencias más importantes son: o

o

o

Permite variar la representación interna de un producto: El objeto Builder provee al director de una interfaz abstracta para construir el producto. La interfaz permite al Builder ocultar la representación y la estructura interna del producto, y la forma en que éste se ensambla. Como el producto se construye a través de una interfaz abstracta de debe definir un nuevo tipo de constructor para cambiar la representación interna de un producto. Aísla los códigos de construcción y representación: El patrón Builder agrega modularidad encapsulando la forma en que un objeto es construido y la forma en que es representado. Los clientes no necesitan conocer nada de la clase que define la estructura interna del producto, tal clase no aparece en la interfaz del Builder. Cada ConcreteBuilder contiene el código para crear y ensamblar un tipo de producto en particular. El código se escribe una vez, luego diferentes Directores pueden usarlos para construir distintos productos desde el mismo conjunto de partes. Mayor control en el proceso de construcción: El patrón Builder construye el producto paso a paso bajo el estricto control del Director. Solamente cuando se finaliza el producto, el director lo recupera del constructor. Esto brinda mayor control sobre el proceso de construcción y consecuentemente en la estructura interna del producto resultante.

Ejemplo Las PIMs son bases de datos especiales. Una PIM incluirá normalmente una libreta de direcciones, un calendario para agendar las actividades y citas y una lista de tareas a realizar donde se listan a las mismas, las llamadas por realizar y cosas que queden por hacer. Para lograr la gestión de citas pueden definir una clase llamada Cita para la información de cada evento, de tal forma que pueda registrar información como por ejemplo fechas de inicio y finalización de la misma, una descripción de la cita, un lugar de encuentro, asistentes a la cita, etc. La información es introducida por un usuario cuando se crea la cita, por lo que se define un constructor que permite establecer el estado del nuevo objeto Cita.


Pag 55

Son necesarios diferentes tipos de información dependiendo del tipo de cita. Se puede necesitar una lista de asistentes, algunas pueden tener fecha de inicio y fin, otras una sola fecha. Cuando se consideran todas estas opciones la creación de un objeto Cita no es una tarea trivial. Es por ello que se delega la responsabilidad de la creación de citas a una clase especial, ConstructorCita, lo que simplificará mucho el código de la propia Cita . La clase ConstructorCita contiene métodos para crear las partes de Cita , y puede llamar a los métodos de ConstructorCita que son relevantes para cada tipo de cita. Además, la clase ConstructorCita puede asegurar que la información que recibe cuando se crea la cita es válida, ayudando así a que se cumplan las reglas de negocio. Si necesita crear subclases de Cita , puede crear otra clase constructor o heredar de la que ya existe. En cualquier caso, esa tarea es más fácil que la alternativa de gestionar la inicialización de objetos por medio de constructores. Prototype

El patrón Prototype (Prototipo), crea objetos nuevos copiándolos, clonando una instancia creada previamente. Aplicabilidad Se utiliza este patrón cuando un sistema debe ser independiente de cómo se crean, se componen y se representan sus productos, además cuando: Las clases a instanciar son especificadas en tiempo de ejecución - Para evitar la construcción de una jerarquía de la clase de fábricas que se asemeja a la jerarquía de la clase de productos - Cuando instancias de una clase pueden tener una de las combinaciones de diferentes estados. - Cuando es necesario la creación de distintas variantes de un objeto. Entonces, el código que utilizan esos objetos solicitará una copia del objeto que necesite, una copia significa otra instancia del objeto. El único requisito que debe cumplir el objeto es la posibilidad de clonarse. -

Participantes Prototype: Declara una interfaz para clonarse. ConcretePrototype : Implementa una operación para clonarse. Cliente : Crea un nuevo objeto por medio de una solicitud de clonación al prototype .


Pag 56

Client

Prototype

Operation()

Clone()

p = prototype -> Clone()

Con creteProt otype1

Con creteProt otype2

Clone()

Clone()

return copy of self

return copy of self

Figura 5.3 - Patrón de Diseño Prototype

Consecuencias El patrón Prototype oculta las clases producto del cliente. Este patrón cuenta con las siguientes ventajas: o

o

o

o

Agregar y quitar productos en tiempo de ejecución: El patrón Prototype permite que se incorpore una clase producto en el sistema simplemente registrando una instancia de prototipo. Esto es más flexible que la forma en que lo brinda otro patrón de creación, debido a que el cliente puede agregar o quitar prototipos en tiempo de ejecución. Especificar nuevos objetos variando sus valores: En sistemas altamente dinámicos permite definir nuevos comportamientos a través de composición de objetos especificando valores para variables de un objeto sin definir nuevas clases. Se define una nueva clase de objetos clonando clases existentes y registrando las instancias como prototipos de objetos cliente. Un cliente puede variar su comportamiento delegando responsabilidades al prototipo. Este tipo de diseño le permite a los usuarios definir nuevas “clases” sin programar, en realidad, clonar un prototipo es similar a instanciar una clase. Este patrón puede disminuir el número de clases que necesita el sistema. Reducir la subclasificación : Este patrón permite clonar un prototipo en vez de solicitar a un método fábrica que cree un nuevo objeto, lo cual evita tener toda una jerarquía de clases Creadoras de objetos. Permite configurar una aplicación con clases dinámicamente: Una de las mayores ventajas de este patrón es permitir en tiempo de ejecución cargar dinámicamente las clases en una aplicación.

El patrón Prototype presenta la siguiente desventaja: o

Cada subclase de Prototype debe ser implementada por la operación Clone, tarea que puede resultar complicada cuando las clases ya existen y los objetos que estas incluyen no soportan ser copiados o tienen referencias circulares.


Pag 57

Ejemplo Si nos referimos al ejemplo planteado en el patrón de diseño Builder, en el PIM tal vez se necesite copiar una dirección con el fin de que el usuario no tenga que introducir manualmente toda la información cuando crea un nuevo contacto. Una forma seria crear un nuevo objeto Dirección y luego copiar los valores apropiados del objeto Dirección existente. Esta solución tiene un problema: viola el principio de encapsulación de la orientación a objetos. Para alcanzar la solución se deberían hacer llamadas a los métodos para copiar la información de Dirección fuera de la clase Dirección . Esto significa que se hace más difícil mantener el código de la clase Dirección porque se extiende a lo largo de todo el proyecto. Además también dificulta la reutilización de la clase Dirección. El código utilizado para realizar la copia realmente pertenece a la clase Dirección , entonces se podría definir un método copy() que produzca un duplicado del objeto Dirección con los mismos datos que el objeto original, el prototipo. Por lo tanto una llamada al método en un objeto Dirección existente resuelve el problema de una forma mucho más fácil de mantener y más aceptable según las prácticas correctas de programación orientada a objetos.

Patrones Estructurales Detallan la manera en que se pueden relacionar, distintos tipos de objetos, para trabajar unos con otros y formar estructuras de mayor tamaño. Adapter

El patrón Adapter se aplica para convertir una interfaz de una clase en otra, haciendo que una clase a la que le fuera imposible utilizar la primer interfase, haga uso de ella por medio de la segunda. Es decir, permite que éstas trabajen juntas, lo que de otra forma sería incompatible. Aplicabilidad El patrón Adapter se recomienda utilizar cuando: Es necesario el uso de una clase existente, y su interfaz es distinta a la que se necesita. - Se requiere crear una clase reusable que coopere con clases no relacionadas, es decir, con clases que no necesariamente tienen interfaces compatibles. -

Participantes Target : define la interfaz específica del dominio que usa Client . Client : participa en la formación de objetos para la interfaz Target . Adaptee (Adaptado): especifica una interfaz existente que define los métodos que necesitan ser adaptados. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 58

Adapter(Adaptador): adapta la interfaz de Adaptee a la interfaz Target . Client

Adaptee

Target Request()

SpecificRequest()

(Implementación )

Adapter Request()

SpecificRequest()

Figura 5.4 - Patrón de Diseño Adapter

Consecuencias El Patrón Adapter presenta las siguientes ventajas y desventajas: o

o

Reutilización de Código: El patrón Adapter ofrece una opción para la reutilización del código, permitiendo la interacción de dos o más objetos que supuestamente son incompatibles. Transferencia de argumentos: Mediante el objeto Adapter se crean objetos apropiados cuando no hay una correspondencia directa entre el Target y el Adaptee, o encapsula un objeto para que pueda ser utilizado por el Adaptee.

Existen otras consideraciones a tener en cuenta en el momento de utilizar el patrón Adapter: o

o

¿Cuantas veces el Adapter realiza adaptaciones? Varía en la cantidad de trabajo que hace Adapter para adaptar Adaptee a la interfaz Target. Existe una variedad de tareas que se puede requerir que Adapter lleve a cabo, desde una simple conversión (cambiar los nombres de las operaciones) hasta soportar un conjunto de operaciones totalmente diferentes. El trabajo depende de que tan similar o diferentes sean las interfaces de Target con las de Adaptee. Adaptadores Pluggables : Una clase es más reutilizable cuando se minimiza las asunciones que otras clases deben hacer para utilizarla. Por medio de la construcción de la adaptación de una interfaz en una clase, se elimina la posibilidad de que otras clases vean la misma interfaz. Es decir, al adaptar la interfaz de una clase permite incorporar una clase propia en un sistema existente que puede esperar diferentes interfaces para dicha clase.

Ejemplo Un ejemplo del mundo real en el que podemos aplicar este patrón es en un libro de frases de idiomas extranjeros. Este libro traduce expresiones comunes (mensajes) de un idioma a otro, permitiendo que dos elementos incompatibles se comuniquen entre sí.


Pag 59

Bridge

Mediante el patrón Bridge es posible desacoplar una abstracción de su implementación, de forma que ambas puedan modificarse de manera independiente sin necesidad de alterar por ello la otra. Aplicabilidad: Se puede utilizar el patrón Bridge cuando: -

-

-

Se desea evitar una vinculación permanente entre la abstracción y su implementación. Este puede ser el caso en que la implementación debe ser seleccionada o modificada en tiempo de ejecución. Las abstracciones y sus implementaciones deben ser extensibles a través de subclases. En este caso, el patrón Bridge permite combinar diferentes abstracciones e implementaciones y extenderlas en forma independiente. Los clientes no deben tener que recompilar el código cuando se lleven a cabo modificaciones en la implementación de una abstracción. Se desea ocultar completamente la implementación de una abstracción a los clientes. Se necesita compartir una implementación entre varios objetos, y este hecho debe ocultarse a los clientes.

Participantes: Abstraction : define una interfaz abstracta. Mantiene una referencia a un objeto de tipo Implementor . RefinedAbstraction: extiende la interfaz definida por Abstraction . Implementor : define la interfaz para la implementación de clases. Esta interfaz no es necesario que corresponda exactamente con la interfaz de Abstraction ; ya que por lo general, la interfaz Implementor provee sólo operaciones primitivas, y Abstraction define operaciones de alto nivel basadas en esas primitivas. ConcreteImplementor : implementa y define la implementación de la interfaz de Implementor . Client Abstraction

Implementor

Operation()

OperationImp() imp->OperationImp();

RefinedAbstraction

ConcreteImplementorA

ConcreteImplementorB

OperationImp()

OperationImp()

Figura 5.5 - Patrón de Diseño Bridge


Pag 60

Consecuencias o

o

o

Separa interfaz e implementación: Una implementación de una abstracción no esta permanentemente confinada a una interfase, ya que puede ser configurada en tiempo de ejecución. Además, un objeto tiene la posibilidad de cambiar su implementación en tiempo de ejecución. El hecho de desacoplar Abstraction e Implementor hace que se elimine en tiempo de compilación las dependencias sobre una clase de implementación. Mejora la extensibilidad: se puede extender en forma independiente las jerarquías de Abstraction e Implementor. Oculta a los clientes los detalles de implementación: Se puede proteger a los clientes de los detalles de implementación.

Ejemplo Ejemplos de la aplicación de este patrón son los sistemas de interfaz gráfica que deben ser portables entre plataformas, estos sistemas necesitan que la implementación subyacente sea aplicada cuando la aplicación se inicia en un sistema operativo diferente. Composite

El patrón Composite admite construir objetos complejos por medio de la composición recursiva de objetos similares u otros más simples en una estructura en forma de árbol. Además permite que dichos objetos sean tratados de manera semejante, sin hacer distinciones entre ellos. Esto reduce el tratamiento de los objetos creados, debido a que como todos ellos poseen una interfaz común los trata de igual manera a todos. Aplicabilidad Se recomienda utilizar el patrón Composite cuando: Es necesario representar la jerarquía completa de objetos. - Se necesita que el cliente no note la diferencia entre una composición de objetos y un objeto individual, de esta forma el cliente tratará a todos los objetos en la composición de la estructura uniformemente. -

Participantes Component : Declara la interfaz para objetos en la composición. Implementa comportamientos por defecto para la interfaz común a todas las clases. Declara una interfaz para acceder y administrar sus componentes hijos. Leaf : Representa las hojas en el árbol de la composición. Define el comportamiento para objetos primitivos. Composite : Define el comportamiento para componentes que tienen hijos. Almacena los componentes hijos. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 61

Client : opera con objetos en la composición a través de la interfaz Component. children

Component

Client

Operation() Add(Component) Remove(Component) GetChild(int)

Leaf Operation()

Composite Operation() Add(Component) Remove(Component) GetChild(int)

forall g in children g.Operation();

Figura 5.6 - Patrón de Diseño Composite

Consecuencias El patrón Composite tiene las siguientes ventajas: o

o

o

Define jerarquías de clases formada por objetos primitivos . Los objetos primitivos pueden estar compuestos dentro de objetos complejos los cuales a su vez pueden ser compuestos y así recursivamente. Clientes más simples : Los clientes pueden tratar en forma uniforme estructuras compuestas y objetos individuales. Para los clientes es transparente si están tratando con una hoja o un componente compuesto. Esto simplifica el código del cliente. Es sencillo agregar componentes nuevos: Nuevos componentes Composite o subclases Leaf trabajan automáticamente con estructuras existentes y códigos de clientes. Los Clients no deben ser cambiados por nuevas clases Component .

El patrón Composite presenta las siguientes desventajas: o

Puede hacer el diseño demasiado general: Al agregar nuevos componentes de forma fácil, dificulta restringir los componentes de una composición, especialmente cuando se requiere que una composición tenga solo ciertos componentes.

Ejemplo Un ejemplo clásico de aplicación de este patrón se observa en las aplicaciones gráficas, donde el usuario puede crear dibujos complejos a partir de dibujos sencillos y básicos (Hojas), pero a su vez puede manipular conjuntamente sólo una parte del dibujo, sin hacer distinción si es una figura simple o compuesta


Pag 62

Proxy

El patrón Proxy se emplea como intermediario para acceder a un objeto, controlando el acceso a él. Aplicabilidad El patrón Proxy es aplicable cuando se necesita referenciar a un objeto en forma más refinada y versátil que con un simple puntero. En las siguientes situaciones es conveniente el uso del patrón Proxy: Un proxy remoto provee una representación local de un objeto ubicado en un espacio de dirección diferente. - Un proxy virtual crea objetos de gran tamaño bajo demanda. - Un proxy de protección controla el acceso al objeto original, controlando quien accede a cada método y otorgando los permisos basándose en el invocador. - Una referencia elegante lleva a cabo acciones extras cuando se acceden a objetos referenciados. El uso normal incluye: Contar el número de referencias al objeto para que pueda ser liberado automáticamente cuando no haya más referencias a él. Cargar un objeto persistente a memoria cuando es referenciado por primera vez. Chequear que el objeto este resguardado antes de ser accedido para asegurarse que ningún otro objeto lo pueda modificar. -

•

•

•

Participantes Proxy : Mantiene una referencia que le permite acceder al objeto real. Mantiene una interfaz idéntica a Subject lo que permite que un Proxy sustituya al objeto real. Controla al acceso al objeto real y puede ser responsable de crearlo o eliminarlo. Según el tipo de proxy puede: •

•

•

Proxy remoto: Codificar peticiones y sus argumentos para enviar al RealSubject en otro espacio de dirección Proxy virtual: Guarda información adicional del RealSubject Proxy de protección: Comprueba los permisos de acceso al RealSubject.

Subject : Define la interfaz común a Proxy y RealSubject RealSubject : Define el objeto real que representa el Proxy


Pag 63

Subject

Client

Request() …..

RealSubject

Proxy

Request() ...

Request() ...

… realSubject ->Request(); .. .

Figura 5.7 - Patrón de Diseño Proxy

Consecuencias El patrón Proxy introduce un nivel de indirección cuando se accede a un objeto. La indirección adicional tiene varios usos y ventajas, dependiendo de la clase de proxy: prox y: •

•

•

Proxy Remoto: oculta oculta al cliente el hecho que un objeto reside en un espacio de memoria distinto. Proxy Virtual: tiene un sustituto con el que interactúa y no crea el producto real hasta que realmente lo necesita, y optimiza el hecho de crear un objeto bajo demanda. Proxy de Protección: realiza tareas de control cuando se accede a un objeto.

Ejemplo Se desea resguardar una lista de usuarios registrados, pero no se sabe exactamente donde resguardarla. La decisión consiste que, en base al valor de un checkbox (en el que el usuario elige si está conectado a internet o no), se debe enviar los datos al servidor (en formato XML) o guardarlos en disco. Esta es una tarea para realizarse bajo el patrón Proxy, ya que se quiere aislar el proceso de guardar los datos del resto del programa, simplemente se desea pedir que se guarden dichos datos pero no cómo o dónde se debe guardar. Eso es lo que realiza este patrón. El proxy guarda una referencia a un objeto, que es quien realmente se encargará de ejecutar la acción. Pero es el proxy el que crea ese objeto, por lo que puede crear una instancia de una u otra clase dependiendo de ciertas condiciones en tiempo de ejecución

Patrones de Comportamiento Los patrones de comportamiento describen la forma de como organizar, administrar, y combinar conductas y responsabilidades de objetos, centrándose en la comunicación entre ellos. Frecuentemente, describen como los distintos elementos colaboran entre si para conseguir un objetivo.


Pag 64

Template Method

El patrón Template Method proporciona un método abstracto que permite que las subclases redefinan partes del método sin reescribirlo completamente manteniendo su estructura inicial. Aplicabilidad: Se utiliza el patrón Template Method para Proporcionar un esqueleto para un método permitiendo a las subclases redefinir partes específicas del mismo. - Centralizar partes de un método que se definen en todos los subtipos de una clase, pero que siempre tiene una pequeña diferencia en cada subclase. - Controlar las operaciones que se necesitan redefinir en las subclases. -

Participantes: Participantes: AbstractClass : Define operaciones primitivas abstractas que subclases concretas definen para implementar pasos de un algoritmo. Implementa un método template() definiendo el esqueleto de un algoritmo. Este método llama tanto a operaciones primitivas como a operaciones definidas en AbstractClass en AbstractClass . ConcreteClass : Es una subclase de AbstractClass de AbstractClass e e implementa los métodos abstractos definidos. AbstractClass templateMethod() subOperation1() subOperation2()

//skeleton code subOperation1(); //more skelet on code subOperation2(); //even //even more code

ConcreteClass subOperation1() subOperation2()

Figura 5.8 - Patrón de Diseño Diseño Template Method

Consecuencias El patrón Template Method cuenta con una ventaja muy importante y es que facilita la reutilización de código, evitando que el código se duplique en muchas subclases Este patrón tiene como desventaja que si el método template() llama a demasiados métodos abstractos, se cansará pronto de utilizar AbstractClass como superclase. Es recomendable tener un número limitado de métodos abstractos.


Pag 65

Ejemplo Los métodos de plantilla se utilizan sobre todo en frameworks para, a la vez que se garantiza que las operaciones se ejecutan en el orden correcto, otorgar flexibilidad a los usuarios del framework permitiendo ejecutar su propio código en determinados puntos, simplemente redefiniendo estos métodos (abstractos en la clase original). Observer

El patrón Observer define una dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, el observer se encarga de notificar este cambio a todos los otros objetos dependientes. Aplicabilidad: Se puede utilizar el patrón Observer cuando se presentan las siguientes situaciones: Una abstracción tiene dos aspectos, uno dependiente del otro. Encapsulándolos en objetos separados se permite variarlos y reusarlos de forma independiente. - Cuando un cambio en un objeto implica cambiar otros y no se conoce de antemano cuantos objetos deben actualizarse - Cuando un objeto debe ser capaz de hacer notificaciones a otros sin hacer suposiciones de quiénes son, buscando un bajo acoplamiento. -

Participantes: Subject : Proporciona métodos para suscribir y borrar Observers. Conoce sus Observers. Observer : Define la interfaz para objetos que deben ser notificados. ConcreteSubject : Almacena el estado que es de interés para los objetos ConcreteObserver y envía notificaciones a sus Observers cuando cambia su estado. ConcreteObserver : Mantiene una referencia a un objeto ConcreteSubject. Almacena el estado que debe ser consistente con el del Subject. Implementa la interfaz de actualización para mantener su estado consistente con el del Subject. Subject Attach(Observer) Dettach(Observer) Notify()

observers

Observer Update()

for all o in observers { o->Update() }

subject

ConcreteSubject GetState() subjectState

ConcreteObserver Update() observerState

observerStare= subject->GetState();

return subjectState

Figura 5.9 - Patrón de Diseño Observer


Pag 66

Consecuencias Ventajas: o

o

Acoplamiento mínimo entre Subject y Oberver: Todo lo que sabe un subject es que tiene una lista de observers que responden a la interfaz observer. El subject no conoce ninguna clase observer concreta. Soporte para comunicación tipo broadcast: La notificación se extiende a todos los objetos de la lista. Se añaden y quitan observadores en cualquier momento.

Desventajas: o

Actualizaciones Costosas: Un observer no conoce cuántos observers más existen y por lo tanto, no conoce el costo de enviar un “cambio” al subject. Podría producirse una actualización en cascada.

Ejemplo Un ejemplo clásico de la aplicación del patrón Observer se da cuando tenemos una aplicación la cual consta de distintas vistas, y dependiendo de cada una de ellas los datos son actualizados de distinta forma y en distintos momentos. Command

Este patrón permite solicitar una operación a un objeto sin conocer realmente el contenido de esta operación, ni el receptor real de la misma. Para ello se encapsula la petición como un objeto, facilitando la parametrización de los métodos. Al encapsular un mensaje como un objeto, permite gestionar colas o registros de mensajes, deshacer operaciones y restaurar el estado a partir de un momento dado. Ofrece una interfaz común que permite invocar las acciones de forma uniforme y extender el sistema con nuevas acciones de forma más simple. Este patrón presenta una forma sencilla y versátil de implementar un sistema basado en comandos facilitando su uso y ampliación. Aplicabilidad: Se puede utilizar el patrón Command cuando se necesita: -

-

Facilitar la parametrización de las acciones a realizar Independizar el momento de petición del de ejecución Implementar CallBacks, especificando que órdenes se necesitan ejecutar en ciertas situaciones bajo otras órdenes. Es decir, un parámetro de una orden puede ser otra orden a ejecutar. . Dar soporte para deshacer comandos, procesos de identificación y/o transacciones Desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas (primitivas).


Pag 67

Participantes: Command : Declara una interfaz para la ejecución de una operación. ConcreteCommand : Define una enlace entre el objeto Receiver y una acción. Implementa Execute() por invocación a la operación correspondiente en el Receiver . Client : Crea un objeto ConcreteCommand y setea su receptor Invoker : Solicita al command que envíe la respuesta a su solicitud Receiver : Conoce la forma en que las operaciones son asociadas con el envío de una solicitud. Una clase puede servir como un Receiver . Invoker

Command Execute()

Client

Receiver ConcreteCommand

Action( )

Execute() State

receiver->Action();

Figura 5.10 - Patrón de Diseño Command

Consecuencias o

o

o

Independiza el objeto que invoca una operación de un objeto que conoce como implementarla. Los Command son objetos de primera clase, pueden ser manipulados y extendidos como cualquier otro objeto. Se facilita la ampliación del conjunto de comandos ya que las clases existentes no cambian

Ejemplo Este patrón permite estructurar un sistema en torno a operaciones de alto nivel que se implementan en término de operaciones, por ejemplo, un sistema transaccional. Permite implementar un mecanismo de rehacer, deshacer permitiendo llevar un registro de las operaciones que sí pueden volver a ser aplicadas, por ejemplo, en caso de una caída del sistema. State

El patrón State permite que un objeto cambie en tiempo de ejecución su comportamiento cuando cambia su estado interno. Aplicabilidad: Se puede utilizar el patrón State en cualquiera de los siguientes casos: Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 68

El comportamiento de un objeto depende de su estado y este cambia con mucha frecuencia. - Los métodos tienen largas y múltiples sentencias condicionales que dependen del estado del objeto. Estos estados generalmente son representados por constantes enumeradas y largas sentencias “switch/case” dentro de los métodos. El patrón State ubica cada rama del condicional en clases separadas. -

Participantes: Context : Define la interfaz que utilizan los clientes y mantiene una referencia al estado actual del objeto. State : Define una interfaz para encapsular el comportamiento asociado a un estado particular del objeto. ConcreteSate : Cada subclase implementa un comportamiento asociado con un estado del objeto. Context

State

currentState setCurrentState(State s)

someMethod()

ConcreteStateA someMethod()

ConcreteStateB someMethod()

Figura 5.11 - Patrón de Diseño State

Consecuencias El uso del patrón State presenta las siguientes ventajas e inconvenientes: o

o

o

Comportamiento de las particiones de estados basadas en el estado: Esto da una visión más clara del comportamiento. Cuando un objeto es un estado específico, mira en la subclase State correspondiente y todo el posible comportamiento de ese estado se incluye en esa clase. Localiza comportamiento para un estado específico y particiona el comportamiento para diferentes estados: El patrón State ubica todos los comportamientos asociados a un estado particular en un objeto. Como todos los códigos específicos a un estado conviven en una subclase de State , agregar nuevos estados se transforma en una tarea muy sencilla, solo es necesario definir nuevas subclases. Las transiciones de estados son explicitas: Cuando un objeto define su estado actual mediante la asignación de un valor a una variable, su transición de estado no tiene una representación explícita. Introducir objetos


Pag 69

separados por diferentes estados hace que la transición se torne más explícita, facilitando el reconocimiento de un cambio entre estados. Utiliza un gran número de clases: Si bien puede verse como una desventaja, no lo es, debido a que presenta una visión mucho más clara que el uso de largas sentencias switch en los métodos.

o

Ejemplo Un ejemplo del uso del patrón State es considerar clases TCPConnection que representan el estado de la conexión de una red. Un objecto TCPConnection puede estar en uno de los varios estados posibles de la conexión: establecida, escuchando, cerrada . Cuando un objeto TCPCOnnection recibe solicitudes desde otros objetos, este responderá de forma diferente dependiendo del estado en que se encuentre. Strategy

El patrón Strategy define una familia de algoritmos, encapsula cada uno y los hace intercambiables, permitiendo que el algoritmo varíe independientemente del cliente que haga uso de él. Aplicabilidad: Se puede utilizar el patrón Strategy cuando: Se quiera ofrecer la posibilidad de configurar una clase con una gama de comportamientos disponibles. - Se necesiten diferentes variantes de un algoritmo. - Un algoritmo use datos que el cliente no tenga por qué conocer. - Una clase defina varios comportamientos y estos aparezcan en forma condicional en sus operaciones. -

Participantes: Strategy : Declara la interfaz común para todos los algoritmos soportados. ConcreteStrategy : Implementa un algoritmo usando la interfaz de Strategy . Context : Mantiene una referencia a un objeto Strategy, puede definir una interfaz para permitir a Strategy acceder a sus datos. Se configura con un objeto ConcreteStrategy . strategy Context

Strategy

ContextInterface()

AlgorithmInterface()

ConcreteStrategyA AlgorithmInterface()

ConcreteStrategyB AlgorithmInterface()

ConcreteStrategyC AlgorithmInterface()

Figura 5.12 - Patrón de Diseño Strategy Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 70

Consecuencias Ventajas o

o

o

Familias de algoritmos relacionados: Mediante herencia a partir de clases Strategy este patrón define una familia de algoritmos o comportamientos para contextos reusables. La herencia puede ayudar a factorizar la funcionalidad común de los algoritmos. Elimina las sentencias condicionales. Strategy puede proveer diferentes implementaciones del mismo comportamiento.

Desventajas o

o

o

Puede producirse sobrecarga de comunicación en el paso de parámetros entre Context y Strategy. Puede haber parámetros muy costosos de crear y NO usados por estrategias muy simples. Incrementan el número de objetos en una aplicación.

Ejemplo Un ejemplo básico y sencillo para observar el uso de este patrón consiste en la implementación de un algoritmo de búsqueda determinado. De esta forma tenemos una interfaz (una función que recibe una lista y la ordena) pero con distintas formas de realizar la ordenación, diversos algoritmos, ordenación por burbuja, merge sort, quick sort, etc. Null Object

El patrón Null Object provee un objeto como un substituto por la falta de un objeto de un tipo dado. El Objeto Nulo no realiza nada aunque esto no significa que no sea inteligente. Este oculta los detalles de sus colaboradores. A veces una clase requiere de un colaborador pero no necesita que este haga algo. Sin embargo, la clase desea tratar a un colaborador que no hace nada de la misma manera que trata a uno que realmente proporciona conducta. Aplicabilidad: Se puede utilizar el patrón Null Object cuando: un objeto requiere de un colaborador. El patrón Null Object no introduce esta colaboración, hace uso de una colaboración que ya existe. - algunos casos del colaborador que no deben hacer nada. - cuando necesita abstraer el manejo de objetos nulos fuera del cliente. -


Pag 71

Participantes: Client : requiere a un colaborador. AbstractObject : declara la interfase para el colaborador de Cliente e implementa la conducta por defecto para la interfase común a todas las clases. RealObject : define una subclase concreta de AbstractObject cuyas instancias proveen un comportamiento útil que espera Client NullObject : proporciona una interfase idéntica a AbstractObject para que un objeto nulo pueda ser sustituido para un objeto real. Implementa su interfase pero no hace nada. El significado de “no hacer nada” depende de qué clase de conducta Client esta esperando. Cuando hay más de una manera de no hacer nada, puede necesitarse más de una clase NullObject. Client

uses

AbstractObject +request()

RealObject +request()

NullObject +request()

do nothing

Figura 5.13 - Patrón de Diseño Null Object

Consecuencias Ventajas o

o

o

Define jerarquías de la clase que consisten en objetos reales y en objetos nulos. Pueden usarse los objetos nulos en lugar de los objetos reales cuando se espera que el objeto no haga nada. Siempre que el código del cliente espere un objeto real, también puede tomar un objeto nulo. Hace el código del cliente simple. Los clientes pueden tratar a los colaboradores reales y los colaboradores nulos uniformemente. Los clientes normalmente no saben si ellos están tratando con un colaborador real o uno. Esto simplifica el código del cliente, porque evita tener que escribir código de comprobación, ya que se ocupa el colaborador nulo especialmente. Encapsula la tarea de “no hacer nada” en el código del objeto nulo. Hacer el código de “no hacer nada” en el objeto nulo facilita su reuso. Múltiples clientes que tienen la necesidad de que sus colaboradores no hagan nada querrán que la tarea de “no hacer nada” lo hagan todos de la misma forma. Si el “no hacer nada” necesita ser modificado, el código puede cambiarse en un lugar. Luego de esto, todos los clientes continuarán usando el mismo comportamiento actualizado de no hacer nada.


Pag 72

Desventajas o

o

o

o

La conducta de no hacer nada hace difícil distribuir o mezclar el comportamiento real de varias colaboraciones de objetos. La misma conducta de no hacer nada no puede agregarse fácilmente a la conducta de varias clases a menos que esas clases deleguen todo el comportamiento a una clase que puede ser una clase del objeto nulo. Puede ser necesario la creación de una nueva clase NullObject para cada nueva clase AbstractObject. Puede ser dificultoso la implementación si varios clientes no están de acuerdo de cómo el objeto nulo no debe hacer nada o cuando su interfaz a AbstractObject no se encuentra bien definida. El Objeto Nulo siempre actúa como un objeto que no hace nada y no se transforma en un Objeto Real.

Ejemplo Considere por ejemplo una simple pantalla que despliega pelotas que se mueven sobre la pantalla y tienen efectos de color especiales. Esto se logra fácilmente creando una clase Pelota para representar las pelotas y usando un patrón Startegy para controlar el movimiento de la pelota y otro patrón Strategy para controlar el color de la pelota. Sería entonces trivial escribir las estrategias para tipos diferentes de movimiento y efectos de color y crear pelotas con cualquier combinación de movimiento y color. Sin embargo, si comenzamos por crear las estrategias más simples posiblemente se asegure todo el trabajo. Ahora, la estrategia más simple no sería ninguna estrategia. Ése es no hacer nada, no mueve y ni cambia el color. Sin embargo, el patrón Strategy exige a la pelota tener objetos que llevan a cabo las interfaces de estrategia. Aquí es donde el patrón Null Object es útil. Simplemente se realiza un NullMovementStrategy que no mueve la pelota y un NullColorStrategy que no cambian el color de la pelota. Probablemente los métodos en estas clases no hacen "nada". Type Object

Desacopla instancias de sus clases para que estas clases puedan ser implementadas como instancias de una clase. El patrón Type Object permite crear las nuevas "clases" dinámicamente en tiempo de ejecución, porque éstas son instancias, y también permite al sistema crear instancias de esas instancias de tipo clase. Algunas veces una clase requiere no sólo un número indeterminado de instancias sino también una cantidad desconocida de subclases. Aunque un objeto del sistema pueda crear nuevas instancias bajo demanda, usualmente no puede crear nuevas clases sin una recompilación. Un diseño en el cual una clase tiene un número desconocido de subclases puede convertirse en una en la cual la clase tiene un número desconocido de instancias


Pag 73

Aplicabilidad Se recomienda aplicar el patrón de diseño Type Object cuando: -

Las instancias de una clase necesitan estar agrupadas para implementar los atributos y/o comportamiento común. La clase necesita una subclase por cada grupo para implementar los atributos y/o comportamientos del grupo. La clase requiere un gran número de subclases y/o la variedad total de subclases que quizás se requieren y se desconoce. Se necesita poder crear nuevas grupos en tiempo de ejecución que quizás no se predijeron durante el diseño. Se necesita poder cambiar una subclase de un objeto después de que se instanció sin tener que mutar a una nueva clase. Se necesita jerarquizar los grupos recursivamente de modo que ese grupo sea a su vez un ítem de otro grupo.

Participantes El patrón Type Object tiene dos clases concretas, una que representa objetos y otra que representa sus tipos. Cada objeto tiene un puntero su tipo correspondiente. TypeClass : Es la clase de TypeObject, tiene una instancia separada para cada tipo de Object. TypeObject : Es una instancia de TypeClass. Representa un tipo de Object. Establece todas las propiedades de un Object que son las mismas de todos los Objects del mismo tipo. Class : Es la clase de Object. Representa instancias de TypeClass. Object : Es una instancia de Class. Representa un único ítem que tiene un único contexto. Establece todas las propiedades de ése ítem que puede diferir entre ítems del mismo tipo. Tiene un TypeObject asociado que describe su tipo. Delega propiedades definidas por su tipo a su TypeObject. aTypeClass TypeObject1

aClass Object1A type

TypeClass typeAttribute

type

Class attribute

aTypeClass TypeObject2

aClass Object1B type

Figura 5.14 - Estructura del patrón de diseño Type Object


Pag 74

Consecuencias Las ventajas de un patrón TypeObject son: o

o

o

o

o

o

Crea clases en tiempo de ejecución: El patrón permite crear nuevas clases dinámicamente. Estas nuevas clases no son clases, sino instancias llamadas TypeObjects que son creadas por TypeClass de igual manera que cualquier instancia creada por su clase. Evita la explosión de subclases: El sistema no necesita un gran número de subclases para representar diferentes tipos de Objects. En vez de un gran número de clases, el sistema puede usar un TypeClass y varios TypeObjects. Oculta la separación de instancias y tipos: Un Object cliente no necesita estar consciente de la separación entre Object y TypeObject. El cliente realiza solicitudes de Object, y el Object decide que requerimiento envía al TypeObject. Los clientes que conocen al TypeObject pueden colaborar con ellos directamente sin ir a través de los Objects. Cambio dinámico de tipo: El patrón permite que el Object cambie dinámicamente su TypeObject, dando el mismo efecto que si sufriera un cambio de clase. Esto es mucho más simple que mutar un objeto a una nueva clase. Subclases independientes: TypeClass y Class pueden tener sus subclases independientemente. Múltiples tipos de objetos: El patrón permite que un Object tenga múltiples TypeObjects donde cada uno define alguna parte del tipo del Object. El Object debe decidir cual tipo de comportamiento delegan a cual TypeObject.

Las desventajas de la utilización del patrón TypeObject son: o

o

o

Diseño complejo: El patrón divide un objeto lógico en dos clases. Su relación, una cosa y su tipo, es difícil de entender. Es difícil reconocer o explicar la relación entre un TypeObject y un Object. Esta confusión va en decremento de la simplicidad y la mantenibilidad. Implementación compleja: El patrón saca diferentes implementaciones de las subclases y las coloca en diferentes estados de las instancias de TypeObject. Considerando que cada subclase podría implementar un método en forma diferente, el TypeClass puede implementar el método de una única forma y cada estado del TypeObject debe hacer que la instancia se comporte en forma diferente. Manejador de referencia: Cada objeto debe guardar una referencia a su TypeObject. De igual manera que un objeto conoce cual es su clase, un Object conoce cual es su TypeObject. Pero considerando que el sistema objeto o lenguaje automáticamente establece y mantiene la relación claseinstancia, en este caso debe ser la aplicación por si misma quien establece y mantiene la relación TypeObject-Object.


Pag 75

Ejemplo Supongamos que nos interesa modelar unidades de medida. Para plantear la relación entre la unidad y su tipo aplicamos el Patrón Type Object que permite que varias instancias de una clase, en este caso Unidad, sean agrupadas de acuerdo con comunes atributos y/o comportamiento, evitando una explosión de numerosas subclases. Consta de dos clases: una que representa los objetos, Unidad (Class), y otra que representa sus tipos, TipoUnidad (TypeClass). Decorador

El patrón de diseño Decorador proporciona una forma flexible de incorporar o eliminar funcionalidad de un componente dinámicamente sin modificar su aspecto o su funcionalidad. Aplicabilidad Es útil hacer uso del patrón Decorator cuando: Se desea realizar cambios en forma dinámica de forma transparente a los usuarios, sin las restricciones propias de la creación de subclases. - Sea posible introducir o quitar responsabilidades de los componentes en tiempo de ejecución. - Sea imposible utilizar herencia debido a que daría lugar a la aparición de multitud de subclases para poder dar soporte a todas las combinaciones posibles. -

Participantes Para implementar el patrón Decorador, son necesarios los siguientes participantes: Component : Componente que contiene el comportamiento genérico. Define la interfaz de los objetos a los que se les pueden añadir responsabilidades de forma dinámica. Decorador : Puede ser una clase o una interfaz. Define los comportamientos estándar de todos los decoradores, también proporciona soporte para contener otros decoradores, es decir, mantiene una referencia a un objeto Component que puede ser un objeto ConcreteComponent u otro Decorador. ConcreteDecorator : Añade responsabilidades al objeto Component al que hace referencia.


Pag 76

Component operation()

ConcreteComponent operation()

Decorator setComponent(Component c) operation()

ConcreteDecorator component.operation()

newAttribute operation() newOperation()

Figura 5.15 - Estructura del patrón de diseño Decorador

Consecuencias El patrón de diseño Decorador cuenta con las siguientes ventajas: o

o

o

Más flexible: Ofrece la oportunidad de ajustar y aumentar fácilmente el comportamiento de un objeto en tiempo de ejecución. Evita que las clases altas de la jerarquía estén demasiado cargadas de funcionalidad: Es mucho más sencilla la tarea relacionada con la propagación, debido a que sólo se deberá escribir una serie de clases cada una de las cuales contendrá una parte específica de la funcionalidad. En otro caso, habría que programar todos los comportamientos en el propio componente. Nuevas responsabilidades: Permite que la adición de nuevas responsabilidades (nuevas clases de Decorators) independiente de las clases los Objetos que ellas extienden.

Hay que tener en cuenta también las siguientes desventajas: o

o

Un Decorator y su Component no son idénticos: Desde el punto de vista de la identidad de los objetos, un DecoratorComponent no es idéntico al Component. Por esto no se puede confiar en la identidad de los objetos cuando se usan Decorators. Propagación de objetos: El patrón Decorator hace que haya muchos objetos pequeños que son muy parecidos.

Ejemplo Supongamos que tenemos una clase existente Ventana y queremos añadirle funcionalidad para que muestre un borde alrededor. El patrón Decorator ayuda a resolver esta situación de una manera sencilla y extensible. Se crea a partir de la clase Ventana la subclase abstracta VentanaDecorator y, heredando de ella, BordeDecorator y BotonDeAyudaDecorator. VentanaDecorator Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 77

encapsula el comportamiento de Ventana y utiliza composición recursiva para que sea posible añadir tantas "capas" de Decorators como se desee. Podemos crear tantos Decorators como queramos heredando de VentanaDecorator.


Pag 78

Capítulo 6

Caso de estudio: Sistema de Cheques Tomaremos como caso de estudio los lineamientos fundamentales de la operatoria que deben realizar los Bancos para la implementación de un nuevo sistema en la gestión de cobro de Cheques. Este sistema permite la captura descentralizada de cheques de cualquier importe, eliminándose en todo el país el traslado físico de los mismos, quedando estos en poder de las Entidades Depositarias independientemente de su lugar de captación y su domicilio de pago. Las Entidades deben contar en cada una de sus sucursales con los medios necesarios para poder llevar a cabo la captura de los datos de los cheques depositados, la generación de los registros electrónicos y sus respectivas imágenes (digitalización). Transmitiéndose los registros electrónicos y las imágenes de los cheques superiores a un importe determinado.

Participantes Los distintos participantes en el sistema son los que a continuación se detallan: Participantes Internos al sistema: Las Sucursales de la Entidad Depositaria : Son quienes efectúan la digitalización y carga de todos los datos correspondientes al cheque depositado por el cliente en caja. - Entidad Girada: Es quien recibe la información electrónica de los cheques, y previa verificación de la misma, debita el importe a sus clientes libradores y abona a la Entidad Depositaria. -

Participantes Externos al sistema -

Cámara Compensadora: Es la administradora de la compensación electrónica de medios de pagos y sus funciones se detallan a continuación: Refundición de los archivos recibidos de las Entidades Depositarias y clasificación de éstos por Entidad Girada, generando los archivos con el detalle de transacciones para su posterior envío Refundición de los archivos de rechazos recibidos de las Entidades Giradas y la clasificación de éstos por Entidad Depositaria, generando los archivos conteniendo el detalle de las operaciones para su posterior envío. •

•


Pag 79

Esquema Operativo Los diagramas muestran la forma en la que participan cada uno de los integrantes del sistema: Esquema a gran escala:

Suc 2

Suc 2

Suc 3

Suc 3

Suc 4

Suc 4

Suc 1

Suc 1

Entidad Depositaria / Girada

Entidad Depositaria / Girada

Camara Compensadora

Figura 6.1 - Esquema a gran escala

Esquema solución dentro de cada Entidad: Entidad Depositaria / Girada Suc 1 CASA MATRIZ

Sistema de Escaneo de Cheques

Server de la Sucursal Sistema de Escaneo de Cheques

Suc 2 Sistema Centralizador Host_Central Sistema de Escaneo de Cheques

Server de la Sucursal

Suc 3



Servidor Central

Cámara Compensadora

Suc 4 Sistema de Escaneo de Cheques Sistema de Escaneo de Cheques

Sistema de Escaneo de Cheques Server de la Sucursal Sistema de Escaneo de Cheques

Figura 6.2 - Esquema dentro de cada una de las entidades.


Pag 80

Definición del Sistema Podemos especificar tres grandes circuitos que consisten en el envío/recepción diario de archivos a la Cámara Compensadora donde se encuadran cada una de las sesiones, denominando sesión al proceso de envío o recepción de archivos desde/hacia la Cámara Compensadora, correspondiente a cada ítem de cada uno de los circuitos. Circuito de Cheques

Las Entidades transmitirán a la Cámara Compensadora archivos conteniendo los registros electrónicos correspondiente a los cheques que dicha Entidad presenta para su compensación electrónica en sesiones diariamente. Se entiende por registro electrónico al conjunto de datos que definen a un cheque - banco, sucursal, código postal, número de cheque, número de cuenta, importe y fecha. En el circuito de cheques enviados, los cheques son escaneados en las sucursales, una vez realizado el cierre son remitidos al Sistema Centralizador (registros electrónicos e imágenes), donde se gestionan los distintos archivos para su posterior envío. Respecto al envío de archivos se identifican tres sesiones. Cheques: Corresponde a la generación de un archivo conteniendo los registros electrónicos de los cheques. - Imágenes: Se genera un archivo conteniendo todas la imágenes correspondientes a los cheques escaneados en el día, que superen un importe determinado. - Rechazos de Cheques: Luego de imputar los cheques recibidos, capturados en otros bancos el día anterior, se genera un archivo conteniendo aquellos cheques que se necesitan rechazar, es decir que no se pagan por diversos motivos (Ej: Sin fondo, Cuenta Inexistente, Falla Técnica, etc.). -

En el circuito de cheques recibidos, los archivos están conformados por cheques que han sido capturados en otros bancos el día anterior y son recibidos para su imputación en sus respectivas cuentas. Respecto a la recepción de archivos se identifican tres sesiones. Cheques Recibidos: Se recepciona y procesa un archivo conteniendo los registros electrónicos de cheques procedentes de otros bancos para su cobro. - Imágenes: Se recepciona y procesa un archivo con todas las imágenes de los cheques que han sido capturados en otros bancos. - Rechazos de Cheques: Se recepciona y procesa un archivo con los registros electrónicos de los cheques rechazados por la Entidad Girada. Estos rechazos corresponden a cheques enviados por la Entidad Depositaria anteriormente. -


Pag 81

Entidad Girada

Pres entación de C heques

Rec epc ión de C heques

Rec epc ión de R echaz os

R ec haz o de C heques

Presentac ión de Imágenes

R ecepc ión de Imagenes

Entidad Depositaria

Camara Compensadora

Figura 6.3 - Esquema dentro de cada cada una de las entidades. entidades.

Circuito de Imágenes por Rechazo

Luego del proceso de recepción de los cheques y su imputación contable, se genera el archivo de Cheques rechazados. Para indicar el rechazo de un cheque, se asocia a su registro electrónico un código de rechazo. Dependiendo del código de rechazo, rechazo, la Entidad Depositaria deberá enviar, o no, a la Entidad Girada la imagen del mismo. El envío de los archivos se realiza por diferentes sesiones: Imágenes por rechazo: Una vez recibidos los archivos de rechazos se deberá enviar a la Entidad Girada las imágenes de aquellos cheques que según su código de rechazo lo requieran. - Rechazo de Imágenes por rechazo: En caso de recibir imágenes de una Entidad Depositaria que no correspondan a los cheques rechazados oportunamente, se deberá generar un archivo indicando el rechazo de la imagen. -

La recepción de los archivos se realiza por diferentes sesiones: Imágenes por Rechazo: Una vez enviados los archivos de rechazos a la Entidad Depositaria, se deberá recibir de la misma, un archivo conteniendo las imágenes correspondientes a los cheques rechazados por los códigos que generan envío de imagen. - Rechazo de Imágenes por rechazo: En esta sesión se recibirán rechazos de aquellas imágenes que se enviaron por rechazo y no se corresponden con los datos del registro electrónico del cheque rechazado. -

Pres entac ión de R ec haz os

Entidad Girada

R ec epc ión de R ec hazos

Recepción de Rechazos

Rechazo de Rechazo

Recepción de Imagenes

Presentación de Imágenes

Rechazo de I magenes magenes

Recepción de Rechazo de Imágenes

Entidad Depositaria

Camara Compensadora

Figura 6.4 - Circuito de Imágenes por rechazo Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Cavenago

Pag 82

Circuito de Imágenes por Reclamos

El circuito de intercambio de imágenes por reclamo de cheques, es similar al que se usa en el circuito de imágenes de cheques rechazados. Los reclamos se efectúan sobre cheques recibidos que, al gestionar su cobro no se contaba con la imagen. Esta operación es solicitada por el cliente librador del cheque. Mediante diferentes sesiones se gestiona el envío de los archivos: Reclamos de cheques: Se genera un archivo conteniendo todos los registros electrónicos correspondientes a reclamos efectuados en sucursales. genera ra un arch archivo ivo con todas todas las las imág imágene eness - Imágenes por reclamo: Se gene correspondientes a los reclamos recibidos. - Rechazo de Imágenes por reclamo: en caso de recibir imágenes de la Entidad Depositaria que no corresponden a los cheques reclamados, se genera un archivo indicando el rechazo de la imagen. -

La recepción de los archivos se realiza por diferentes sesiones: Cheques reclamados: Se procesa el archivo conteniendo los registros electrónicos que indican las imágenes reclamadas que se deben enviar. - Imágenes por reclamo: Se procesa el archivo que contiene las imágenes correspondientes a los cheques reclamados. - Rechazo de Imágenes por reclamo: Se procesa el archivo que indica que se han enviado imágenes que no se correspondían con los reclamos recibidos. -

Entidad Girada

Pres ent ac ión de Rec lamos

R ec epc ión de R eclamos

Recepción de Rechazos

Rechazo de Reclamos

Recepción de Imagenes

Presentación de Imágenes

Rechazo de I magenes

Recepción de Rechazo de Imágenes

Entidad Depositaria

Camara Compensadora

Figura 6.5 - Circuito de Imágenes por reclamo

Limites del sistema El caso de estudio se limita a realizar el análisis y diseño arquitectónico del sistema correspondiente a la captura descentralizada de los cheques en sucursales de las Entidades Depositarias y la recepción/envío de la información desde/al Host Central en Casa Matriz, el cual será el responsable de gestionar la comunicación con la Cámara Compensadora a través del Servidor Central.


Pag 83

Visión Arquitectónica Realizando un diagnóstico del sistema de estudio consideramos que se ajusta a un esquema distribuido e interactivo. Distribuido: El sistema está distribuido sobre una intranet en la Entidad Bancaria. La Entidad Bancaria cuenta con sucursales geográficamente separadas y con diferentes tecnologías de comunicación. - El núcleo de la funcionalidad se encuentra en un Servidor Central ubicado en Casa Matriz. - Las sucursales acceden a esta funcionalidad por medio de PCs. -

Interactivo: Aplicación instalada en sucursales. sucursales. usuario. - Variedad de tipos de interfaz de usuario. - Formularios, menús, cajas de diálogos, para interacción basada en eventos. -

Independencia de plataformas -

Distintos servidores de base de datos, clientes con diferentes sistemas operativos.

Para realizar la definición de la arquitectura de base que capture toda la estructura de los subsistemas fundamentales de la aplicación, como primer paso, debemos definir la infraestructura identificando las propiedades de todo el sistema global, Distribuido e Interactivo, es decir: Seleccionar los patrones arquitectónicos adecuados. - Combinar los patrones arquitectónicos seleccionados. - Identificar los subsistemas funcionales: Utilizar los métodos de análisis y diseño convencional. - Integrar los subsistemas funcionales con la infraestructura del sistema -


Pag 84

Capítulo 7

Aplicación de Patrones En este capítulo nos proponemos identificar patrones arquitectónicos y definir microarquitecturas y modelos de diseño basados en objetos, que permitan modelar el sistema anteriormente descripto de modo que resulte una aplicación extensible, fácil de modificar, mantener y reusar. Se presenta el análisis y diseño realizado para nuestro trabajo, describiendo especialmente los patrones utilizados y las razones de su selección.

Análisis En la presente sección se describirá el análisis del sistema. Esta etapa comienza con el estudio del proceso de gestión de cobro de cheques en el sistema bancario. Como se mencionara en el capítulo anterior, este sistema permite la captura descentralizada de cheques de cualquier importe, eliminándose en todo el país el traslado físico de los mismos, quedando estos en poder de las Entidades Depositarias independientemente de su lugar de captación y su domicilio de pago. La Entidad Depositaria presenta cheques para su posterior cobro a la Entidad Girada donde se ha librado el valor. La Entidad Depositaria procesa en sus aplicativos esta transacción y efectúa el envío de la información electrónica a la Cámara Compensadora, quien separa y distribuye los archivos a las Entidades Giradas, las cuales, recibirán los archivos y se encargaran de impactar los movimientos de los cheques en las cuentas libradoras A continuación se verá con más detalle el comportamiento de cada uno de los circuitos antes mencionados en forma integrada, posibilitando ver claramente cada una de las sesiones dependiendo de la Entidad que lo realiza (Depositaria/Girada) y como es la relación entre ellas. La figura 7.1 representa el flujo de datos entre las entidades involucradas correspondiente al circuito de escaneo de cheques en conjunto con el circuito de imágenes por rechazo.


Pag 85

Entidad Depositaria

Entidad Girada

Deposito por Caja

Registración del Cheque

Si

Si es Cheque propio

No

Pago o Rechazo según saldo suficiente

Escaneo de cheques

Generación y envío de archivo de cheques escaneados

Recepción y procesamiento de archivo de cheques escaneados

Imputación de cheques (Debito)

Imputación de cheques (Crédito)

Cheque rechazado?

No

Si Recepción de cheques rechazados

Generación de cheques rechazados

Imputación de cheques (Crédito y Debito)

No

Código de rechazo genera imagen? Si

Búsqueda de la imagen correspondiente al cheque rechazado

Generación de archivo con imágenes por rechazo

Recepción y procesamiento de Imágenes por rechazo

Corresponde imagen?

Si

Chequear imagen en Sucursal

No

No

Imagen válida para sucursal?

Marcar rechazo de reclamo

Si

Aceptación de imagen

SI Procesar rechazo de imágenes por rechazo

Generar rechazo de imágenes por rechazo

Figura 7.1 - Circuito de Depósito de Cheques

El proceso comienza con el depósito en la Entidad Depositaria del o los cheques por parte del cliente. De esta forma el cheque entra en el circuito para gestionar su cobro, cambiando su estado a lo largo del mismo. La Entidad Depositaria es la responsable de realizar la digitalización de todos los cheques así como la integración de sus datos. Una vez concluida esta tarea, en forma Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 86

centralizada se genera el archivo conteniendo todos los cheques a enviar a la Entidad Girada. Una vez aquí, se recepciona, se procesa el archivo y se realiza su imputación monetaria, efectuando los débitos en las cuentas corrientes correspondientes. Como consecuencia de este proceso, se plantean dos situaciones, el cheque puede ser rechazado o aceptado: Aceptado: en este caso, la Entidad Depositaria al día siguiente al no recibir rechazo, procede a la acreditación del importe del cheque en la cuenta depositaria correspondiente. Concluyendo de esta manera con el circuito de digitalización de cheques. - Rechazado: La Entidad Girada genera un archivo conteniendo todos los cheques que desea informar como rechazados, con sus respectivos códigos de rechazo, y lo envía a la Entidad Depositaria. -

La Entidad Depositaria al recibir los cheques rechazados debe reflejar estos en las respectivas cuentas de los clientes depositantes, impactando un movimiento de débito y un movimiento de crédito, mostrando de esta manera el ingreso de los cheques al circuito y su posterior rechazo. La tarea posterior a la imputación monetaria de los cheques rechazados es analizar su código de rechazo asociado. En caso de: Código de rechazo que no genera imagen: Concluye el circuito de cheques rechazados. - Código de rechazo que si genera imagen: Se buscan las imágenes correspondientes a los cheques que se han rechazado, se genera un archivo y se envía a la Entidad Girada. -

La Entidad Girada cuando recibe el archivo con imágenes por rechazo debe arbitrar los medios para efectuar la recepción y procesamiento del mismo, donde debe chequear si corresponden a imágenes de cheques rechazados: Si corresponden a cheques rechazados se envía a la sucursal para su chequeo visual. - Si no corresponden a cheques rechazados, se genera en forma automática el rechazo de la imagen. -

Una vez que las imágenes se encuentran en la sucursal, se realiza el chequeo visual de las mismas. En caso de poder contar con la imagen sin problemas de visualización se acepta la imagen dando por concluido el circuito de rechazos. - En caso de tener algún problema de visualización, por ejemplo, imagen ilegible, cheque mal escaneado, etc, la sucursal marcará dicha imagen como rechazada. -

Una vez obtenidos todos los rechazos, ya sea en forma automática o porque una sucursal la marcó, se genera el archivo de rechazo de imágenes por rechazo, el cual es enviado a la Entidad Depositaria.


Pag 87

La Entidad Girada recibe y procesa dicho archivo. De esta manera se concluye con el circuito de imágenes por rechazo. Como vemos en este último caso, nos encontramos en la situación en que la Entidad Girada aún no cuenta con las imágenes de los cheques que ha rechazado. Como consecuencia de ellos existe a disposición de esta entidad la posibilidad de efectuar reclamos sobre los cheques que ha recibido. En la siguiente figura 7.2 se muestra dicho circuito. Entidad Depositaria

EntidadGirada

Realizar reclamo en sucursal

Recepción y procesamiento de archivo de reclamos

Generar archivo de reclamo

Verificación de reclamos

Si

No

Cheque enviado?

Buscar imagen correspondiente al cheque reclamado

Generar rechazo de reclamo Recibir rechazo de reclamos

Recibir archivo con imágenes por cheques reclamados

Generar archivo con imagen

No

Corresponde la imagen?

Si Controlar imagen en sucursal

Imagen válida para sucursal?

Si

No Marcar rechazo

Generar rechazo de imágenes por reclamo Procesar rechazo de imágenes por reclamo

Figura 7.2 - Circuito de Reclamos de Cheques


Pag 88

La posibilidad de efectuar reclamos se puede realizar sobre cualquier tipo de cheque recibido, tanto aceptado como rechazado. Los reclamos sirven para obtener las imágenes de aquellos cheques cuyo importe sea inferior al importe predefinido para el envío de imágenes del circuito de cheques. La Entidad Girada es la única que puede realizar reclamos respecto de los cheques que ha recibido. Comienza en las sucursales quienes son las encargadas de realizar los reclamos, luego en forma centralizada se genera un archivo y se envían a la Entidad Depositaria. Una vez que la Entidad Depositaria ha recibido y procesado el archivo se verifica que el reclamo corresponda a un cheque escaneado y enviado por ésta: Si el reclamo no corresponde a un cheque enviado, se marca en forma automática el reclamo con un nuevo código de rechazo, se genera un archivo conteniendo los rechazos de imágenes por reclamo y se envía a la Entidad Girada. Al recibir el archivo la Entidad Girada, lo procesa y da por concluido el circuito de reclamos. - Si el reclamo corresponde a un cheque enviado, se busca la imagen asociada a este y se genera un archivo con todas las imágenes y se envía a la otra entidad. -

La Entidad Girada cuando recibe el archivo con imágenes por reclamo efectúa la recepción y procesamiento del mismo, donde chequea si corresponde a los reclamos efectuados: Si corresponden a cheques reclamados se envía a la sucursal para su verificación visual. - Si no corresponden a cheques reclamados, se genera en forma automática el rechazo de la imagen. -

Una vez en la sucursal, se realiza la verificación de las mismas. Si se puede visualizar correctamente, se acepta la imagen y se da por finalizado el circuito de reclamos. - Si tiene errores al visualizarse, como por ejemplo imagen ilegible, cheque mal escaneado, etc, se marca dicha imagen como rechazada. -

Una vez que se marcan todos los rechazos, ya sea en forma automática o porque una sucursal la marcó, se genera el archivo de rechazo de imágenes por reclamo, el que es enviado a la Entidad Depositaria. La Entidad Depositaria recibe y procesa dichos rechazos, concluyendo con el circuito de imágenes por reclamo. Modelo de casos de uso

Con la información obtenida a partir de las circuitos descriptos de escaneo de cheques, rechazos y reclamos se definen los actores y los casos de uso involucrados en los procesos para finalizar con las restricciones generales que debe cumplir el sistema.


Pag 89

En los procesos se identifican dos actores: Usuario y Sistema Centralizador . El primero representa a los usuarios que realizan el escaneo y la carga de los cheques en sucursales y el segundo representa al Sistema Central que gestiona la información de todas las sucursales. Para que un usuario pueda acceder al sistema deberá identificarse previamente, una vez autenticado podrá tener acceso a la información (registro electrónico y/o imagen) e ingresar nuevos cheques. Con estas funcionalidades definidas, el sistema estará compuesto por los siguientes grupos de casos de uso: Validación: Validar el ingreso correcto de un actor al sistema a través de su nombre de usuario y su password y obtener la fecha en forma centralizada. - Verificación y validación de números de cuentas depositarias en el momento del depósito del cheque. - Verificación si corresponde a un cheque propio o un cheque de otra sucursal u otro banco. -

Apertura y cierre de operaciones: Realizar la apertura del día en la Sucursal: Se reciben archivos del sistema centralizador: Cheques Presentados Cheques rechazados recibidos Reclamos recibidos - Realizar el cierre del día provocando la generación y envío de los archivos correspondientes a Cheques depositados Reclamos enviados Rechazos enviados -

•

•

•

•

•

•

Búsqueda de información: (Utilizado por el usuario) -

-

Desplegar la información existente en la base de datos. Permitir ver sólo los registros electrónicos/imagen de los cheques ingresados al sistema por esa sucursal y aquellos cheques que fuesen enviados a esa sucursal para gestionar su cobro. Listados de Cheques ingresados al sistema. Cheques Recibidos con visualización de su imagen. Cheques Enviados con visualización de su imagen. Consultar la historia de un cheque (recibido, enviado, aceptado, rechazado, envío de imágenes por reclamo/rechazo, recepción de imágenes por reclamo/rechazo).


Pag 90

Depósito de cheques: (Utilizado por el usuario): -

Depósito y digitalización de cheques: Esta tarea se realiza en el momento que el cliente se presenta por caja y efectúa el depósito del cheque. En caso de se un cheque propio el mismo se registra y es pagado o no por caja, caso contrario, si es un cheque que pertenece a otra sucursal o a otro banco el cheque es digitalizado con escaners especiales que capturan en forma automática los datos de los cheques (banco, sucursal, código postal, número de cheque y número de cuenta) por lo que resta la integración manual por parte del usuario del número de cuenta depositaria e importe del cheque depositado. En este proceso la imagen capturada del cheque se asocia al registro electrónico del mismo definiendo en él, path y nombre del archivo físico de la imagen.

Administración de datos: tener a disposición ABM que permitan ABM de Reclamos - Generar Rechazos de Imágenes recibidas por Reclamos - Generar Rechazos de Imágenes recibidas por Rechazos -


Validación

Apertura y cierre de operaciones

Búsqueda de Información

Usuario

Depósito de Cheques

Sistema Centralizador

Administración de datos

Figura 7.3 - Diagrama de casos de uso


Pag 91

Diseño El Modelo Arquitectónico

El objetivo principal del diseño arquitectónico es representar componentes que interactúen entre ellos y tener asignadas tareas específicas, ser flexible y extensible y representar las relaciones de control entre las partes. El sistema en estudio tiene el comportamiento de un sistema Distribuido e Interactivo como ya lo mencionamos. Los cuales se ajustan a los siguientes patrones arquitectónicos: -

Patrón Broker: Soporta la distribución y la integración de componentes. Nos interesa que la aplicación que usa un objeto lo haga a través de la interfaz ofrecida por ese objeto, despreocupándose de los detalles de su implementación o su ubicación física y que las invocaciones de servicios remotos sean transparentes respecto de su ubicación. Cproxy

Broker

Sproxy

Cliente

Servidor

Figura 7.4 - Patrón Broker

Para el diseño de aplicaciones con interfaces gráficas se utiliza el patrón Model-ViewController. La lógica de una interfaz de usuario cambia con más frecuencia que los almacenamientos de datos y la lógica de negocio. Si se realiza un gran diseño, que mezcle los componentes de interfaz y de negocio, cuando se necesite cambiar la interfaz, se deberá realizar un arduo trabajo para poder modificar los componentes de negocio, lo que implica un mayor riesgo de cometer errores. Por lo cual, se realiza un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o los datos. -

Patrón Model-View-Controller: Interacción usuario-computadora. Nos interesa poder mantener múltiples vistas de un mismo modelo, manteniéndolas actualizadas ante cualquier cambio del estado del modelo y poder incorporar nuevos controladores si fuera necesario, sin alterar el comportamiento del modelo. Vista

Modelo

Controlador

Figura 7.5 - Patrón Broker Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 92

-

Patrón Layers: Independencia de plataforma. Nos interesa poder descomponer todo lo referente a comunicaciones y a acceso a la base de datos, en grupos o subtareas, en las cuales cada grupo de subtareas tiene un nivel de abstracción particular, de modo que un componente pueda ser reemplazado por implementaciones alternativas sin afectar al resto del sistema. Capa N

Capa N-1

Capa 0

Figura 7.6 - Patrón Layers

Una vez identificados los patrones a utilizar los integramos de la siguiente manera: Broker Layer Capa N

Cproxy

Sproxy Capa N - 1

Cliente Vista

Controlador

Servidor Capa 0 Modelo

Figura 7.7 - Integración del patrón Broker, Model-View-Controller y Layers

La distribución es preferente, por lo cual, Broker es el primer patrón a aplicar ya que el ambiente es el de un sistema distribuido, y posiblemente heterogéneo, con componentes independientes que cooperan entre sí. Lo que se intenta resolver es el problema de construir un sistema de software complejo como un conjunto de componentes desacoplados que interoperan, lo cual conlleva a mayor flexibilidad y facilidad en el mantenimiento y futuros cambios, en lugar de una aplicación monolítica. Al partir la funcionalidad en componentes independientes, el sistema se vuelve potencialmente escalable y distribuido. Por lo tanto: Creamos un objeto que actué de broker al sistema remoto. - Creamos una interfaz para definir el comportamiento remoto del sistema. - Luego, implementamos un proxy para el cliente y otro proxy para el servidor. - Los detalles de comunicación quedan dentro del proxy cliente y del proxy servidor . -


Pag 93

Para el cliente es transparente la forma de comunicación entre los componentes, respetando la siguiente estructura: Proxy del lado del Cliente empaquetarDatos desempaquetarDatos enviarSolicitudes regresarResultados

transfiere mensajes

transfiere mensajes

Broker

Proxy del lado del Servidor empaquetarDatos desempaquetarDatos llamarServicios enviarResultados

cicloPrincipal registrarServicio encontrarServidor encontrarCliente enviarSolicitud enviarRespuesta

llama

llama

Servidor

Cliente

inicializarse ejecutarCicloPrincipal ejecutarServicio utilizarAPIBroker

llamarServidor inicializarTarea utilizarAPIBroker

Figura 7.8 - Diagrama de clases del patrón Broker

Si aplicamos a nuestro caso de estudio cada componente del patrón los mismos, estarían ubicados de la siguiente forma en el esquema: Entidad Depositaria / Girada PROXY DEL LADO DEL CLIENTE (A)

CLIENTE (A)

BROKER

PROXY DEL LADO DEL SERVIDOR

CASA MATRIZ

Suc 1

SERVIDOR




Host_Central

Servidor Central CLIENTE (B)

PROXY DEL LADO DEL CLIENTE (B)

SERVIDOR

Figura 7.9 - Distribución de los componentes del patrón Broker.

Ahora veremos un diagrama de secuencia que representa la interacción entre los componentes del sistema. En este diagrama se ve el caso en que el usuario realiza la apertura del día: 1. Se inicia la aplicación usuario. Durante la ejecución del programa, el usuario invoca un método de un objeto servidor remoto solicitándole la fecha del día. 2. La aplicación usuario solicita proxy cliente la fecha del día para realizar la apertura. 3. El proxy cliente empaqueta los datos y reenvía la solicitud al broker . 4. El broker localiza el servidor al cual se esta realizando la petición, en este caso al Host Central. Puesto que el servidor esta disponible localmente, el broker envía el mensaje al proxy servidor correspondiente. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 94

5. El proxy servidor desempaqueta todos los parámetros e información relevante, e invoca el servicio apropiado. 6. Después que la ejecución del servicio se completa, el servidor regresa el resultado al proxy servidor , el cual lo empaqueta en un mensaje con información relevante, y lo pasa al broker . 7. El broker envía la respuesta al proxy cliente . 8. El proxy cliente recibe la respuesta, desempaqueta el resultado y lo regresa a la aplicación usuario. Obteniendo de esta manera la fecha del día. El proceso cliente continúa con sus operaciones.

Cliente

Proxy del Cliente

Proxy del Servidor

Broker

Servidor

Llamar servidor Envia Solicitud De apertura de dia

Empaquetar datos

Reexpedir Solicitud

Encontrar Servidor Host Central Desempaquetar datos Llamar_servicio

Ejecutar servicio de apertura de dia Enviar fecha del día Empaquetar datos

Reexpedir respuesta Encontrar cliente Regresar Desempaquetar datos

Recibe r esultados

Figura 7.10 - Diagrama de secuencia de la interacción entre componentes

A continuación se integra el patrón Model-View-Controller en el patrón Broker. Si bien existen dos patrones arquitectónicos Model-View-Controller (MVC) y Presentation-Abstraction-Control (PAC) que son aplicables a sistemas interactivos, según la clasificación realizada por [Buschmann+96] y descripta anteriormente en este trabajo, hemos optado por el MVC.


Pag 95

Analizando los patrones, observamos que cada agente PAC consiste de los componentes presentación, abstracción y control manteniendo una analogía parcial con el patrón MVC. El componente control es similar a lo que seria el componente control en la arquitectura MVC. Este procesa los eventos externos y actualiza los componentes abstracción y presentación. Es diferente del componente control del patrón MVC en que pasa las actualizaciones realizadas a su agente PAC padre. El componente abstracción contiene los datos al igual que el componente modelo en el patrón MVC. Sin embargo, él puede contener solo parte de la estructura de datos de la aplicación, y no juega un papel activo en la notificación de los cambios. El componente presentación es exactamente igual que el componente vista en el patrón MVC. Cabe destacar que estos tres componentes forman cada uno de los agentes PAC, los cuales a su vez forman una estructura jerárquica en forma de árbol de agentes cooperando. Cada agente es responsable de un aspecto especifico de la funcionalidad de la aplicación, provocando que el sistema quede dividido en múltiples componentes presentación, abstracción y control, por lo cual no fue el patrón elegido para el caso de estudio propuesto, además agrega innecesariamente una mayor complejidad en el diseño. En el diseño de nuestro caso de estudio finalmente se optó utilizar el patrón MVC por las siguientes razones: El sistema tiene la funcionalidad central que no está distribuida sino se ubica en un único centro - La misma información es representada en diferentes vistas de manera distinta (ej: una sucursal tiene una vista detallada de cada uno de los cheques por ella escaneados y el Sistema Centralizador ve sólo la cantidad de cheques escaneados por una sucursal, sin el detalle de cada uno de ellos). -

Como se ha visto los elementos de este patrón son: Modelo : datos y reglas de negocio. - Vista : muestra la información del modelo al usuario. - Controlador : gestiona las entradas del usuario. -

Los servidores contienen los diferentes componentes del modelo y los clientes los componentes vista y controlador . La siguiente figura muestra la conectividad de cada uno de los componentes y las tareas que lleva a cabo cada uno de ellos.


Pag 96

Observador actualizar()

Llamar actualizar

Modelo

Vista Conectar MiModelo conserguirDatos MiControlador

Datos SeteoDeObservers conectar(Observador) desconectar(Observador) notificar() conseguirDatos Servicio()

inicializar (Modelo) hacerControlador() crear activar() mostrar()

Controlador MiModelo Manipular MiVista display inicializar( Modelo, Vista) conectar manejarEventos()

llamada a servicios

Figura 7.11 - Diagrama de clases del patrón Model-View-Controller

En la siguiente figura se muestra cada componente del patrón en nuestro caso de estudio: Entidad Depositaria / Girada

Vista (A)

Modelo

Contr olador (A)

CASA MATRIZ

Suc 1

Host_Central Sistema de Es caneo de Cheques



Servidor Central Vista (B)

Controlador (B)

Figura 7.12 - Distribución de los componentes del patrón Model-View-Controller

Ahora veremos cual es la conducta dinámica de este patrón al realizar la conexión al sistema tras ingresar clave y contraseña. 1. El usuario interactúa con la interfaz de usuario (vista ) de alguna forma, como dijimos ingresando la clave y contraseña. 2. El controlador recibe, por parte de los objetos de la vista , la notificación de acción solicitada por el usuario. El controlador gestiona el evento que llega a través de un manejador de eventos. 3. El controlador accede al modelo , actualizándolo con la acción solicitada por el usuario, es decir, interpreta el evento y activa el procedimiento de validación y verificación de clave y contraseña en el modelo . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 97

4. El modelo realiza el servicio requerido. Esto produce un cambio en sus datos internos. 5. El modelo notifica del cambio a todas las vistas y controladores registrados con el mecanismo de propagación de cambios, llamando a sus procedimientos de actualización. 6. Cada controlador registrado recupera los datos del modelo para activar o desactivar ciertas funciones del usuario, como por ejemplo el perfil del usuario que se ha conectado. 7. Cada vista solicita a su controlador los datos modificados del modelo y los refleja en pantalla, por ejemplo mostrando el nombre del usuario que se ha conectado. 8. El controlador original recobra el control y retorna desde su procedimiento manejador de eventos. 9. La interfaz de usuario espera nuevas interacciones del usuario, comenzando con el ciclo nuevamente.

Controlador Manejador de eventos

Modelo

Vista

servicio notifica actualiza display Toma_datos

actualiza Toma datos

Figura 7.13 - Diagrama de secuencia para la conexión de un usuario al sistema.

Los componentes de los patrones antes mencionados requieren establecer conexiones que les permitan comunicarse teniendo en cuenta que estamos considerando que el caso de estudio es un sistema distribuido. Esta necesidad de comunicación nos lleva a estructurar dichos componentes en capas mediante la utilización del patrón Layers. Se tomó la decisión de hacer uso de este patrón debido a que claramente se observa la necesidad de comunicación entre los distintos componentes lo cual nos lleva a pensar que deberíamos independizar la tarea de comunicación de las tareas del Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 98

sistema operativo. Separando dos capas independientes, una capa de nivel más bajo que realice las tareas específicas de comunicación y otra capa ubicada sobre la anterior, que realice las tareas propias del Sistema Operativo. En ambos caso hacemos uso de software ya existente. La integración final de todos los patrones sería: Broker Layer S.O

Cproxy

Cliente Vista

Controlador

Comunicaciones

Sproxy

Servidor Modelo

Figura 7.14 - Integración del patrón Broker, Model-View-Controller y Layers.

Capa Sistema Operativo: Es la capa de software que permite gestionar los mecanismos de comunicación, independizar el servicio de su implantación y de los protocolos de comunicaciones, además, permite la convivencia de distintos servicios en un mismo sistema y la transparencia del mismo. El sistema operativo a utilizar en nuestro caso de estudio será alguna de las diferentes plataformas existentes. Capa de Comunicación: En esta capa se encuentra el protocolo de comunicación, se encarga de transportar los mensajes que intercambian los distintos componentes. El protocolo de comunicaciones que utilizamos es TCP/IP, que a su vez, como ya sabemos, esta estratificado en capas por lo cual es una aplicación más del patrón Layers. La principal ventaja de la estructuración por capas es que cada capa cumple con funciones y servicios determinados que brinda a la otra capa, esto permite una mejor organización. También aplicamos el patrón Layers para desarrollar la tarea de acceso a datos en el servidor. Se identifican las capas:


Pag 99

Capa de Servicio

Capa de Acceso a Datos

Procedimiento Almacenado

Tablas y Vistas

Figura 7.15 - Estructura de Capa de Servicio, Capa de Acceso a Datos y Base de Datos.

En la capa de servicio cada tarea dentro de esta capa se puede encapsular en un método de un componente. Para los procesos más complejos que requieren varios pasos y transacciones de ejecución larga, la aplicación necesita disponer de un modo de organizar las tareas y almacenar el estado hasta que el proceso se haya completado. Además, permite realizar el uso directo por parte de componentes de presentación o su encapsulación como servicio y llamada a través de una interfaz de servicios, que coordina la conversación con los llamadores del servicio. Capa de acceso a datos, esta capa se encarga de administrar el almacenamiento y obtener el acceso a los datos. Los componentes de acceso a datos exponen métodos para insertar, eliminar, actualizar y recuperar datos. Recibe las solicitudes de la capa de servicio y las convierte en solicitudes a la base de datos específica. Esta capa es fundamental para que los cambios de base de datos no afecten a la aplicación en general. Puede utilizar un componente de acceso a datos para centralizar la administración de la conexión y todo el código relacionado con un origen de datos. Se realiza la implementación de las consultas y operaciones de datos como procedimientos almacenados para mejorar el rendimiento y la facilidad de mantenimiento. El Componente Modelo

Una vez planteado el modelo arquitectónico de nuestro caso de estudio, el próximo paso a seguir es el desarrollo del diseño del componente modelo del patrón Model View-Controller aplicado anteriormente. De acuerdo a nuestro análisis previo, el modelo se conforma por tres componentes que interactúan entre sí. -

Deposito de Cheques se encarga de la tarea de realizar y reflejar el depósito de los cheques en sucursales y su posterior envío y del proceso de rechazo de los mismos.


Pag 100

Recepción de Cheques es el encargado de la recepción y procesamiento de los cheques recibidos, gestión de cobro y rechazo de cheques. - Reclamos de Cheques efectúa la carga y procesamientos del envío de reclamos, así como también el la recepción y gestión de imágenes a enviar. -

MODELO

Deposito de Cheques Solicita imagen Reclamos de Cheques Solicita imagen Recepción de Cheques

Figura 7.16 - Componentes del Modelo

Las principales entidades que intervienen en cada subcomponente del modelo son: Sucursal: Representa a una sucursal bancaria, responsable de la apertura y cierre de operaciones, donde se recibe y se envía archivos desde y hacia el Sistema Centralizador. Sucursal Banco … apertura() generarArchEnvio () generarArchImgRech() generarArchRechazo() cierre() .. .

Figura 7.17 - Clase Sucursal

Cuenta: Representa una cuenta bancaria de una sucursal de banco. Posee uno o más titulares que son Clientes del Banco, tipo de moneda y tipo de cuenta. Entre otras cosas, es responsable de procesar depósitos y extracciones. Cliente

Cuenta

Sucursal

numero

TipoMoneda

TipoCuenta

extraer() depositar() saldo() puedoDebitar() debitar() acreditar() existeCuenta()

… apertura() generarArchEnvio() generarArchImgRech() generarArchRechazo() cierre() .. .

Figura 7.18 - Clase Cuenta Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 101

Cheque: Representa a un cheque de una cuenta bancaria, tiene un importe y una fecha. Es responsable de saber si puede debitarse en la cuenta a la que pertenece y de hacerlo si se lo solicita. Cuenta Cheque

numero

numero importe() fechaEmision() puedeDebitar() debitar()

miCuenta


Figura 7.19 - Clase Cheque

Cuando un cheque es depositado en una cuenta, puede ser que corresponda a la misma sucursal o no. Este segundo caso es el que nos interesa en particular, ya que estos cheques tienen un tratamiento especial, su cobro debe ser gestionado en otro banco. Además de la información propia del cheque, conoce la cuenta en la que se depositó, y es responsable de generar el registro con su información para enviar al sistema centralizador, procesar el depósito o el rechazo según lo que ocurra. Para modelar el cheque depositado en otra sucursal, podríamos pensar en subclasificar a Cheque e incorporar el nuevo comportamiento. Si Cheque tuviera ya otras subclasificaciones como por ejemplo Cheque Diferido, cada una de estas subclases debiera admitir la posibilidad de depositarse en otra sucursal. Por otro lado, el cheque existe como entidad, y se requiere que dinámicamente sea considerado como cheque depositado. Por ello, la subclasificación no es la forma más adecuada de representarlo, siendo la composición la mejor manera. Cuenta numero extraer() depositar() saldo() puedoDebitar() debitar() acreditar() existeCuenta()

cuentaDeposito

miCuenta

ChequeOtraSucursal

Cheque numero

miCheque

importe() fechaEmision() puedeDebitar() debitar()

… generarRegistro() procesarRechazo() asociarImagen() …

Figura 7.20 - Clase ChequeOtraSucursal.

Para generalizar más este esquema y dar la posibilidad a que un cliente pueda trabajar indistintamente con un Cheque o con un Cheque Depositado, aplicamos el patrón Decorator. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 102

Cheque Cuenta numero

numero miCuenta

…..


ChequeNormal

ChequeDepositado

numero

numero acreditar() importe() fechaEmision() puedeDebitar() debitar()

ChequeOtraSucursal

Cuenta

cuentaDeposito

numero …. .

importe() ^miCheque.importe()

… generarRegistro() procesarRechazo() asociarImagen() …

Figura 7.21 - Aplicación Patrón Decorator

Consideramos la clase cheque como una interfaz permitiendo de esta manera un tratamiento indistinto tanto a los cheques normales como a los cheques depositados. Considerando a cheques normales aquellos cheques que son presentados en caja para su cobro, pero no son depositados en una cuenta. Caso contrario será un cheque depositado, que a su vez puede ser un cheque propio (cuya cuenta origen pertenece a la sucursal del deposito) o un cheque de otro banco u otra sucursal. La separación de estas clases se debe a que cada una de ellas tiene un comportamiento particular. En nuestro caso solo nos centraremos en el comportamiento de los cheques depositados. Si bien aplicamos el patrón Decorator, en los diagramas subsiguientes utilizamos la interfaz cheque sin representar sus subclases para dar mayor simplicidad al esquema del modelo. Depósito de Cheques

Aquí se modelizan los procedimientos del depósito de un cheque, desde su registración por caja y digitalización hasta el procesamiento y generación de archivo para su posterior envío al Sistema Centralizador al efectuar el cierre de operaciones en la sucursal. Así como también la apertura y recepción de los rechazos correspondientes a cheques depositados y enviados el día anterior. Al efectuar el depósito de un cheque por caja, se cargan todos los datos referentes a la boleta y al cheque. El depósito se realiza en la cuenta del cliente depositante, el cual debe contar con los siguientes datos: tipo de cuenta (cuenta corriente, caja de ahorros, etc.), tipo de moneda (pesos, dólares, euros, etc.), sucursal y número. Todos Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 103

estos datos en su conjunto son necesarios para indicar la existencia y validez de la cuenta. Otro dato requerido es la fecha del depósito. En caso de que el cheque corresponda a una cuenta de la sucursal donde se realiza el depósito, el mismo será debitado de su cuenta origen en si el saldo es suficiente y será acreditado en la cuenta del cliente depositante. Por lo tanto el cheque adopta el estado aceptado . Caso contrario, es decir, si corresponde a un cheque de otra sucursal o de otro banco, pasamos a la fase de digitalización, quedando el cheque en estado depositado. Cada cheque tiene en su parte inferior un código de barras que, al ser digitalizado, permite la captura automática del banco, sucursal, código postal, número de cheque y número cuenta al que pertenece el cheque, restando sólo la tarea de completar en forma manual su importe, quedando de esta forma generado el registro electrónico del cheque con su imagen digitalizada. Al finalizar el día, la sucursal realiza el cierre de operaciones, este proceso toma todos los cheque que se encuentran en estado depositado y genera un archivo para su envío, esto provoca que los cheques cambien al estado enEspera . El archivo generado es transferido al Sistema Centralizador, quien una vez recibidos los archivos de todas las sucursales los procesa conformando un único archivo para enviar a la Cámara Compensadora. Al día siguiente, al realizar la apertura de operaciones en la sucursal, se reciben los rechazos de los cheques depositados el día anterior. En este procedimiento se contrastan los cheques enviados con los rechazos recibidos. Si no se recibe rechazo de un cheque, el mismo cambia su estado a aceptado y es acreditado en la cuenta depositaria asociada. Si se recibe rechazo de un cheque, se procesa el rechazo del mismo, esto implica la realización de un movimiento de debito y crédito en la cuenta depositaria asociada, provocando que el cheque cambie su estado a rechazado . Este proceso también involucra el análisis del código de rechazo recibido. Si este código implica generar imagen se busca la imagen del cheque y se conforma un registro con la imagen. Con la realización del cierre de operaciones en la sucursal, se genera un archivo con las imágenes a enviar y este archivo es transferido al Sistema Centralizador.


Pag 104

Deposito de Cheques Sucursal Cliente

Cuenta

… apertura() cierre() generarArchEnvio() generarArchImgRech() ...

numero

TipoMoneda

Banco

numero


chequeOtraSucursal

sucursal:: apertura() Recepc ionProcesamient oChequesR echazados() Recepc ionProcesamient oChequesPres entados() Recepc ionProcesamient oChequesR eclamados()

TipoCuenta

miCuenta cuentaDeposito

Cheque

ChequeOtraSucursal

RecepcionProcesamientoChequesRechazados() Por cada cheque rechazado Buscar Registro electrónico en ChequeOtraSucursal Si lo encuentra ChequeOtraSucursal.procesarRechazo() sino excepcion cheque no encontrado finsi

numero

Estado

… generarRegistro() miCheque procesar() asociarImagen() …

importe() estado fechaEmision() puedeDebitar() debitar()

CodigoRechazo

Depositado

Estado

EnEspera

Figura 7.22 -

Rechazado

Imagen

Fecha

Aceptado

Depósito de Cheques

Recepción de Cheques

El componente Recepción de Cheques es el encargado de la recepción y procesamiento de los cheques recibidos, su imputación monetaria y generación de rechazos. Al momento de la apertura de operaciones de la sucursal, se reciben los cheques que han sido escaneados en otros bancos para gestionar su cobro. Todos los cheques recibidos se encuentran en estado recibido y luego comienza el procesamiento para generar su imputación monetaria en las cuentas. Si el cheque puede debitares, entonces se debita su importe del saldo de la cuenta, tomando en este momento el estado aceptado . En caso de no poder debitarse se marca el cheque con un código de rechazo y se genera el registro adoptando el cheque el estado rechazadoConCodigo o rechazado dependiendo si se requiere la imagen o no. En caso de ser rechazado con el requerimiento de imagen, se mantiene en estado rechazadoConCodigo hasta que se reciba la imagen correspondiente, pasando luego definitivamente a estado rechazado . Al realizar el cierre de operaciones de la sucursal se tomaran todos los cheques rechazados y se generara un archivo que será enviado al Sistema Centralizador para su gestión.


Pag 105

Recepción Cheques

Banco

Sucursal

Cliente

numero

Cuenta

... apertura() generarArchRechazo() cierre() ...

numero extraer() depositar() saldo() puedoDebitar() debitar() acreditar() existeCuenta()

TipoMoneda

chequeOtraSucursal

TipoCuenta ChequeOtraSucursal miCuenta

cuentaDeposito

Cheque Estado

estado

numero

miCheque


Cheque:: debitar() miCuenta.debitar(this.importe())

CodigoRechazo

Recibido

Sucursal:: apertura() RecepcionProcesamientoChequesPresentados() Por cada cheque presentado a debitar Si cheque.puedeDebitars e() ent cheque .debitar() sino generarRechazo(cheque) finsi fin

… generarRechazo() procesarRegistro() asociarImagen() …

Imagen

Estado

RechazadoConCodigo

Fecha

Rechazado

Aceptado

Figura 7.23 - Recepción de Cheques

Para los casos de la representación y comportamiento de los cheques a través de su estado podríamos hacer uso del patrón State, cuyo propósito permite cambiar fácilmente el comportamiento de un objeto en tiempo de ejecución. Los objetos son estados, que se mantienen a través de los atributos y el comportamiento que se define en los métodos. El comportamiento dinámico del objeto se alcanza delegando todas las llamadas a métodos que confían en ciertos valores para un objeto que representa el estado y al modificar esos objetos también se obtiene un comportamiento diferente. Una alternativa en lugar de la aplicación del patrón State es la utilización de una sentencia de selección múltiple como switch para decidir que tareas se realizan de acuerdo al valor del estado que adopta el cheque. Al utilizar el patrón State ponemos todo el comportamiento asociado a un estado en un objeto, evitando el uso de switch monolíticos para los diversos casos así como también la replicación de código, permitiendo la incorporación de nuevos estados sin afectar lo ya desarrollado. En nuestro caso de estudio vemos que el objeto ChequeOtraSucursal cambia su comportamiento de acuerdo al estado en que se encuentra. Un cheque que ha sido depositado por caja y digitalizado, permanecerá en estado depositado , hasta que el cierre de operaciones en la sucursal genere el archivo de envío provocando el cambio de estado de los cheques a enEspera. Una vez recepcionado el archivo de rechazos el cheque adoptará el estado aceptado o rechazado según tenga un código de rechazo asociado o no. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 106

El comportamiento del cheque en la Recepción de Cheques, también tendrá cambios de estados. Al ser recibido, se encuentra en estado recibido , que luego de ser imputado cambiará a estado aceptado , rechazado o rechazadoConCodigo dependiendo de la situación. Un esquema de aplicación del patrón State para representar los cambios de estados de los cheques se muestra a continuación. CodigoRechazo ChequeOtraSucursal Estado … setEstado() procesarRegistro() …

procesar()

Recibido procesar()

RechazadoConCodigo procesar()

Fecha

Rechazado procesar()

Aceptado procesar()

Figura 7.24 - Aplicación del Patrón State en el Componente Recepción de Cheques Reclamos de Cheques

El componente Reclamo de Cheques es el encargado de la recepción y procesamiento de cheques reclamados tanto enviados como recibidos. Al inicio del día, la sucursal recibe los reclamos que se han efectuado por otros bancos para su procesamiento así como también las imágenes reclamadas que se han recibido por reclamos efectuados a otros bancos. Reclamos Recibidos Por cada reclamo recibido se busca el cheque correspondiente a ese reclamo. Si corresponde a un cheque digitalizado en esta sucursal se ubica su imagen y se asocia al registro electrónico. Si no corresponde, se genera el rechazo del reclamo. En ambos casos al realizar el cierre de operaciones se envían los archivos al Sistema Centralizador para su gestión. Reclamos Enviados Cuando la sucursal hace un reclamo, como ya dijimos este corresponde a un cheque anteriormente recibido. La sucursal genera un registro con los reclamos a realizar y al cierre del día se envían al Sistema Centralizador. Cuando el banco destinatario del reclamo cumple con la imagen y esta es recibida en la sucursal se debe asociar al registro electrónico del cheque recibido, finalizando de esta manera con el circuito de reclamos.


Pag 107

Una forma de representar este componente seria agregando un nuevo estado al cheque, es decir estado reclamado , y en base a este nuevo estado se realizaran los procesamientos antes indicados ante la presencia de un reclamo enviado o un reclamo recibido. Los Componentes Vista y Controlador

Tanto la vista como el controlador dependen del componente modelo lo cual no sucede en forma inversa, como ya se ha mencionado. Esta separación permite construir y probar el componente modelo independientemente de la representación visual. El modelo tiene diversas vistas , cada una con su correspondiente controlador . La vista maneja la visualización de la información del modelo al usuario. En nuestro caso de estudio contaremos con vistas ubicadas en cada una de las sucursales y otras en el Sistema Centralizador. La vista en una sucursal determinada sólo muestra la información referente a cheques recibidos, enviados, rechazados y reclamados correspondientes a esa sucursal específicamente. La vista en el Sistema Centralizador muestra la información referente a cheques recibidos, enviados, rechazados y reclamados de todas las sucursales. Mientras la vista en las sucursales muestra información con un alto nivel de detalle (cheque por cheque), la vista en el Sistema Centralizador sólo muestra un resumen de las transacciones realizadas por sucursal. También se muestra el estado en que se encuentra cada una de las sucursales (por ejemplo estado apertura del día, estado consultando, estado escaneando, etc.) El controlador interpreta las acciones del usuario informando al modelo y a la vista para que cambien según resulte apropiado. Existe un controlador por cada vista , el cual permite relacionar la solicitud de servicio realizada en la vista asociándola al evento que detecta el controlador . Un ejemplo dentro de nuestro caso de estudio es cuando se deposita un cheque y se cargan todos los datos de la cuenta, el evento de pulsar la tecla enter activará a través del controlador una petición de servicio al modelo que será una llamada al método existeCuenta(). El modelo ejecuta el método y notifica del resultado de la verificación a la vista y controlador registrados con el mecanismo de propagación de cambios. Una vez finalizada esta notificación vuelve a tomar el control el controlador . El mecanismo de propagación de cambios realizado aquí se lleva a cabo a través de la implementación del patrón de diseño Observer. Este patrón como ya mencionamos nos permite definir una dependencia de uno a muchos entre un objeto de datos y n objetos (observers ) que representan estos datos, de manera que si desde uno de los observers se cambian los datos, el objeto de datos notifica este cambio a todos los observers restantes.


Pag 108

Un componente de este patrón cumple el rol de subject, quien contiene métodos mediante los cuales cualquier observer o vista se puede suscribir a él referenciándose a así mismo. El subject mantiene una lista de sus observers . Los observers deben implementar métodos determinados mediante los cuales el subject es capaz de notificar a sus observers "suscriptos" los cambios que sufre para que todos ellos puedan refrescar el contenido representado. Asociando los componentes del patrón de diseño Observer con los componentes del patrón arquitectónico Model-View-Controller, determinamos que el componente modelo es quien cumple el papel del subject y los componentes vista y controlador actúan como observers. Un ejemplo de aplicabilidad del patrón Observer es cuando se reciben los archivos de imágenes por reclamo o por rechazo y se notifica a las sucursales la recepción de las mismas informando que están a disposición para su toma y procesamiento. Subject Observer añadir(Observer) eliminar(Observer) notificar()

avisar()

observer do: { :each|each avisar]

ConcreteSubject

ConcreteObserver

estado

estadoObserver

obtenerEstado() definirEstado()

avisar()

estadoObserver= subject->obtenerEstado();

return estado;

Figura 7.25 - Patrón Observer


Pag 109

Capítulo 8

Conclusiones y Trabajos Futuros Conclusiones La resolución de este trabajo nos permitió introducirnos en el tema de patrones como herramienta para la resolución de problemas, haciendo hincapié en la reutilización de soluciones a problemas ya pensados y resueltos con anterioridad. Aún sin proponernos, observamos que en forma intuitiva muchas veces se hace uso de patrones sin una aplicación formalizada. La gran variedad de patrones existentes hace que podamos utilizarlos en casi todo el diseño del sistema, es decir, ante una situación, es muy probable que encontremos un patrón que la resuelva. Los patrones no son siempre la solución adecuada o mejor para un problema. Si bien añaden flexibilidad, también añaden complejidad. Por esto se debe ser cuidadoso al momento de seleccionar patrones y analizar muy bien las ventajas y desventajas de su aplicación. Siempre hay que recordar que los patrones son un punto de partida y no dogmas incuestionables. Como conclusión final y en base a nuestra experiencia podemos decir que diseñar con patrones no es aplicar todos los patrones que se conocen en el diseño del software, sino resolver cada problema de diseño que surge con un patrón apropiado, teniendo en cuenta que un uso excesivo de patrones fácilmente terminará en una arquitectura compleja.

Contribuciones El principal aporte de este trabajo consiste en: Recopilación de los principales patrones arquitectónicos y patrones de diseño con claros ejemplos de aplicación. - Brindar elementos necesarios para poder optar por uno u otro patrón frente a una problemática en particular describiendo sus componentes principales y mecanismos de comunicación. - Mostrar la evolución del análisis y diseño de un sistema bancario modelando la estructura básica a través de los patrones arquitectónicos, proporcionando un conjunto de subsistemas predefinidos, incluyendo reglas y pautas para su organización para luego refinar estos subsistemas o componentes mediante el uso de patrones de diseño. -

Trabajos futuros La siguiente tarea a realizar es la implementación y validación del modelo. Otros posibles trabajos futuros se enumeran a continuación: Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago

Pag 110

La aplicación de los patrones en diseños preexistentes: En algunas áreas, existen muy buenas microarquitecturas probadas y testeadas. Facilitar la aplicación contribuye a lograr mejoras en calidad, productividad y costos. - Independencia de la plataforma: La gran cantidad de arquitecturas de software y hardware y la coexistencia de diferentes estándares demandan investigación y trabajo en esta línea para lograrlo. - Aplicación de lenguajes ADLs al trabajo desarrollado correspondiente al caso de estudio. - Integración con otras aplicaciones bancarias. -


Pag 111

Bibliografía [Bellas]

[Buschmann+96]

F. Bellas Permuy. Introduccion al Diseño con Patrones Departamento de Tecnologías de la Información y las Comunicaciones (TIC). Universidad de A Coruña. http://www.tic.udc.es/~fbellas/teaching/pfc3/IntroPatrones.pdf F. Bushmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal Pattern-Oriented Software Architecture: a system of patterns . Ed. Wiley. 1996.

[Casanovas04]

J. Casanovas. Usabilidad y Arquitectura del Software . 2004. http://www.alzado.org/articulo.php?id_art=355

[Diaz06]

M. Diaz. Cómo desarrollar una arquitectura software: los lenguajes de patrones. 2006 http://www.programacion.net/articulo/lenguajes_patrones/

[Fowler97]

M. Fowler. Analysis Patterns: Reusable Object Models. AddisonWesley. 1997.

[Fowler05]

M. Fowler. Patterns of Enterprise Application Architecture . AddisonWesley. 2005.

[Gamma+95]

E. Gamma R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software , Addison-Wesley. 1995.

[Garcia98]

F. García Peñalvo. P atrones. De Alexander a la Tecnología de Objetos . 1998. http://zarza.usal.es/~fgarcia/doc/patrones1.pdf

[Griman+05]

A. Grimán, M. Pérez, L. Mendoza. Estudio de la influencia de mecanismos arquitectónicos en la calidad del software. 2005. http://www.lisi.usb.ve/publicaciones/03%20evaluacion/evaluacion_0 8.pdf R. Lago. Patrones de Diseño Software . 2004 http://www.proactivacalidad.com/java/patrones/index.html#algunos_patrones

[Lago04]


Pag 112

[Larman03]

C. Larman. UML y Patrones. Una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado . 2º Edición. Editorial Prentice Hall. 2003.

[Martin04]

R. Martin. The Strategy, Template Method, and Bridge Patterns. 2004. http://today.java.net/pub/a/today/2004/10/29/patterns.html

[Montaldo05]

D. Montaldo. Patrones de Diseño de Arquitecturas de Software Enterprise . 2005. http://www.fi.uba.ar/materias/7500/montaldotesisdegradoingenieriainformatica.pdf A.Ortiz Ramirez. Introducción a los Patrones . ITESM CEM. 2004. http://webdia.cem.itesm.mx:8005/web/200413/cb00894/patrones/p atrones.pdf

[Ortiz04]

[Pressman98]

R. Pressman. Ingeniería del Software – Un Enfoque Práctico . Cuarta Edición. Editorial Mc Graw Hill. 1998.

[Reynoso04]

C. Reynoso. Introducción a la Arquitectura de Software . Versión 1.0. Marzo 2004 http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq /intro.asp C. Reynoso, N. Kicillof, Estilos y Patrones en la Estrategia de Arquitectura de Microsoft . Versión 1.0. Marzo de 2004. http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq /style.asp Z. Rosanigo. Maximizando reuso en software para Ingeniería Estructural Modelos y Patrones. 2000.

[Reynoso+04]

[Rosanigo00]

[Rottenstein06]

V. Rottenstein. Type Object Pattern . 2006 http://1879.blogspot.com/2006/04/type-object-pattern.html

[Stelting+03]

S. Stelting, O. Maassen, Patrones de Diseño Aplicados a JAVA , Pearson Educación S.A. Prentice Hall. 2003.

[Tallon98]

A. Tallón. Patrones de Diseño. Reutilización de ideas. http://www.aqs.es/web/files/designpatterns.html


Pag 113

Tesina Arquitectura de Software

Recommend Documents