Está en la página 1de 121

Arquitectura de Software: Estilos y Patrones

APU. Adriana Sandra Almeira APU. Vanina Perez Cavenago

Directora: Mg. Zulema Beatriz Rosanigo

Tesina presentada a la Facultad de Ingeniería de la Universidad Nacional de la Patagonia San Juan Bosco como parte de los requisitos para la obtención del título Licenciatura en Informática.

Trelew, Marzo 2007 Facultad de Ingeniería Universidad Nacional De La Patagonia San Juan Bosco Argentina

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

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

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

Pag ii

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

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

.................................................................Clases Cliente y Servidor ..............Patrón Broker......................................74 5...........21 .......................................Distribución de los componentes del patrón Broker.31 4..86 7...............................................23 .................................................Patrón de Diseño Bridge .....36 4...........94 7.....5 ...........22 ................................................Estructura Patrón Pipe and Fliter ..............................................................Diagrama de casos de uso ..............................................................................................................5 .............1 ................................................1 .......................................13 ...............45 4................................................................Clase Servidor Interno ...............80 6.............Patrón de Diseño Composite ...................Esquema de estructuración en capas ............................................................................................22 4...Clase Microkernel ...Patrón de Diseño Builder ....................................Circuito de Imágenes por rechazo ....................................................3 .....................Estructura del patrón de diseño Type Object ......................................................................20 ...Clases Repositorio y Fuente de datos....................................................4 ...Clases Nivel Base y Meta Nivel ...................1 .......92 7.............................................Estructura del patrón de diseño Decorador............Clases Cliente y Adapter.....................Circuito de Reclamos de Cheques .....................Clase de la capa J..........Esquema dentro de cada una de las entidades....................................60 5.........................3 ............................................4 ...........Clase Modelo............................................2 ....45 4.............................82 6............Patrón Layers....10 ........14 ........2 ..45 4..................................10 3............................................................................................................................. Model-View-Controller y Layers............... ...........................................Patrón de Diseño Strategy.....Tabla de Figuras Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura 3.............................26 4..................................44 4...................22 4........Estructura del patrón Broker ............57 5....................................................Clases Pipe y Filter ................................................. ..............................3 ...................................50 5..55 5.....77 6.....................................12 4................................................................................Patrón de Diseño Null Object.......................................62 5.......................12 ...................................................................Esquema de tres partes : contexto – problema ........30 4............Patrón de Diseño Template Method .................5 ................................25 ....6 .................Circuito de Imágenes por reclamo ...49 4........................................................Estructura del Patrón MVC ....................15 ............................26 ...Integración del patrón Broker........................91 7.......Estructura de un sistema Microkernel........7 .......................................................................................25 4............................................................18 ..............5 ................................13 ..............................................18 4.....17 ............Patrón de Diseño Adapter ........... .......................................................................Clase Protocolo Metaobjeto .........................................................................................................................................................9 ........8 ......Integración de clases de los Agentes PAC.......10 ..................................2 ...19 .........Clases Control ........................36 4.1 ..................41 4........................................................Patrón de Diseño State .................11 ..........................8 ..............................................................31 4..................................................94 Pag v Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago ........................................................................................................................Clase Broker.............................................................................11 .................... .....................................2 .......20 4.......93 7.........................................................................7 .........................................................Esquema del protocolo de red OSI .........92 7...................................69 5............................12 ...............................Esquema dentro de cada una de las entidades...................Categoría de Patrones según el tipo de problemas ............Patrón de Diseño Abstract Factory.................................................25 4..................................................44 4....................59 5......................................Clases de los Agentes PAC....................................64 5........................................Esquema a gran escala ...............................Patrón de Diseño Command ....9 ...............15 ..............................................Clases Blackboard y Fuente de Conocimiento ....................................................................83 7.....30 4..........22 4.........14 ............68 5.........65 5...........1 ...53 5........................................Clase Bridge................Estructura del Patrón Arquitectónico Blackboard............72 5....... .................................16 .........................solución .......40 4............................93 7........Circuito de Depósito de Cheques ............Patrón de Diseño Observer .............32 4..........4 .............Patrón de Diseño Prototype ........................................70 5........................18 4........Clase Servidor Externo ...............................................................49 4..........88 7......................................Patrón de Diseño Proxy ...................................................................................................................................................................................................3 ........8 .................Diagrama de clases del patrón Broker.......24 ........Clases Controlador y Vista.......................2 ........36 4.........................7 ................4 .................................66 5.........Clase Protocolo Metaobjeto .........................82 6................................6 ..............................................................9 ..80 6....27 ............................................6 ......................Clases Proxy del lado del Cliente y Proxy del lado del Servidor.........................................................Patrón Broker....................................................

..........95 Diagrama de clases del patrón Model-View-Controller ...........................16 7..................... 102 Aplicación Patrón Decorator .................................................................98 Integración del patrón Broker..................13 7.. 101 Clase Cheque ........11 7.............................................................99 Estructura de Capa de Servicio. 105 Recepción de Cheques .................15 7.....................................................................................................................................23 7......20 7........ 103 Depósito de Cheques ............... 100 Componentes del Modelo ..................................................19 7...........................................................10 7...........................................................................................................................25 - Diagrama de secuencia de la interacción entre componentes ................... ................. .................................................97 Diagrama de secuencia para la conexión de un usuario al sistema......17 7.....97 Distribución de los componentes del patrón Model-View-Controller ...Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura 7......................................... 107 Patrón Observer ............................ Capa de Acceso a Datos y Base de Datos................18 7.................. 102 Clase ChequeOtraSucursal......................................................................................................... 101 Clase Sucursal .............................................12 7..........................................21 7...........14 7..........................................................22 7...................... 109 Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag vi .................. Model-View-Controller y Layers..................... 101 Clase Cuenta .......... 106 Aplicación del Patrón State en el Componente Recepción de Cheques.................24 7..........................

análisis y descripción de la estructura del software dando lugar a aspectos arquitectónicos del mismo. Dentro de esta orientación se enmarca el creciente interés al estudio. Actualmente la elaboración de especificaciones. En consecuencia. patrones arquitectónicos y patrones de diseño. integración y pruebas. 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. construcción de prototipos. 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. El proceso de desarrollo se ha ido convirtiendo poco a poco en una labor de ingeniería. forman parte de la Ingeniería del Software respondiendo a la creación de nuevos modelos.Capítulo 1 Introducción El proceso del desarrollo de sistemas de software ha ido en aumento en los últimos años. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 1 . notaciones. Objetivos El propósito de la presente tesina es reunir y analizar la información necesaria sobre la teoría de estilos. 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. 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. la construcción de aplicaciones con reutilización de otras existentes y desarrollo de productos que presentan una arquitectura común. 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. poniendo de manifiesto la relevancia de un estudio específico de la estructura del software. En particular se tomará como caso de estudio. Para diseñar una arquitectura de software podemos partir con patrones de soluciones ya probados que han funcionado. el diseño del sistema. extensibles. técnicas y métodos. 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. El diseño e implementación ha pasado de una concepción monolítica y uniforme a una visión heterogénea y distribuida. fáciles de modificar. mantener y reusar.

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

es una forma de diseño de software que se manifiesta tempranamente en el proceso de creación de un sistema. La arquitectura es algo más integrado que la suma del análisis por un lado y el diseño por el otro. ya que las decisiones que se tomen tendrán gran influencia a lo largo de todo el ciclo de vida de la aplicación. mientras que las del diseño conciernen a interacciones de tipo procedural. La arquitectura de software también se relaciona con el diseño. Ésta se ocupa de componentes y no de procedimientos. a grandes rasgos. limitaciones económicas y tecnológicas.Capítulo 2 Arquitectura de Software Hoy en día las organizaciones hacen uso de sistemas de software complejos. La vista arquitectónica es una vista abstracta. la arquitectura brinda una visión global del sistema. Se puede ver que la noción clave de la arquitectura es la organización y está relacionada con aspectos de rendimiento. A medida que la arquitectura de alto nivel se refina. Esto permite entenderlo. de las interacciones entre esos componentes y no de las interfaces. 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. una vista del sistema que incluye los componentes principales del mismo. Es decir. usabilidad. de gran tamaño y combinando distintas tecnologías y plataformas de hardware. Otra definición reconocida es la aportada por Clements: “La Arquitectura de Software es. los procedimientos y los tipos. pues. reutilización. 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 relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución”. organizar su desarrollo. Según David Garlan la Arquitectura de Software establece un puente entre el requerimiento y el código. de las restricciones a ejercer sobre los componentes y las interacciones y no de los algoritmos. resultando en la transformación de la arquitectura en diseño. sus puntos de conexión pierden grado de abstracción. plantear la reutilización del software y hacerlo evolucionar. Esto exige a los desarrolladores de software diseñar muy cuidadosamente la arquitectura bajo la cual funcionan sus sistemas. distribuyéndose así a través de los elementos arquitectónicos de más bajo nivel. 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. 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”. 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. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 3 . Si bien no hay una definición oficial de Arquitectura de Software. Las interacciones entre componentes en la arquitectura están en relación con un protocolo de alto nivel.

Según la especificación de estas propiedades. ¿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. fiabilidad. El diseño arquitectónico debería tener la capacidad de utilizar bloques de construcción arquitectónica reutilizados.La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí. adaptabilidad y otras características del sistema. Los modelos estructurales representan la arquitectura como una colección organizada de componentes de programa. . . . capacidad. dado que están describiendo la misma cosa. seguridad. Las vistas de una arquitectura pueden formularse por medio de uno o varios lenguajes.La visión estática: describe cuáles son los componentes de la arquitectura. . Por lo general. los diagramas de flujo de datos. aunque pueden ser aplicados en cualquier ámbito de la informática y las ciencias en general. 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: . de las cuales. etc. Cada paradigma de desarrollo exige vistas. La descripción del diseño arquitectónico debería ocuparse de cómo consigue la arquitectura del diseño los requisitos de rendimiento.La visión funcional: describe qué hace cada componente. hay por lo menos tres que son esenciales en cualquier arquitectura: . 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.Propiedades extra-funcionales. Existe cierta aceptación en el uso de UML (Unified Modeling Language.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. El más obvio es el lenguaje natural..Familias de sistemas relacionados. cada uno de estos aspectos se describe en forma más comprensible si se utilizan diversos modelos o vistas. el diseño arquitectónico puede representarse usando uno o más modelos diferentes. ya que todas las vistas deben ser coherentes entre sí. 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 . 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.La Arquitectura de Software debe representar distintos aspectos del software. pero también existen otros como los diagramas de estado.

“Cada patrón es una regla de 3 partes, que expresa una relación entre un contexto, un problema y una solución. Como un elemento en el mundo, cada patrón es una relación entre un contexto, un sistema de fuerzas que ocurren repetidamente en ese contexto y una configuración espacial que permite que esas fuerzas se resuelvan entre sí. Como elemento de un lenguaje, un patrón es una instrucción que muestra como puede ser usada esta configuración espacial una y otra vez para resolver el sistema de fuerzas, siempre que el contexto lo haga relevante.” Si bien Christopher Alexander aplicó los patrones originalmente a la construcción, también puede aplicarse al software. Los patrones de software permiten que se reutilice tanto el diseño como la arquitectura, adoptando estructuras estáticas y dinámicas de soluciones exitosas en la solución de nuevos problemas. Esto nos lleva a citar una frase del libro “Pattern Oriented Software Architecture, Volumen 1” [Buschmann+96]: “Los patrones ayudan a construir sobre la experiencia colectiva de ingenieros de software experimentados. Estos capturan la experiencia existente y que ha demostrado ser exitosa en el desarrollo de software, y ayudan a promover las buenas prácticas de diseño. Cada patrón aborda un problema específico y recurrente en el diseño o implementación de un software.” Las técnicas generales para la arquitectura de software no apuntan a la solución de problemas específicos. Varios de los métodos existentes de análisis y diseño fallan a este nivel, ya que solamente proveen técnicas generales para construir software. La creación de arquitecturas específicas sigue basada en la intuición y experiencia. Los patrones son bloques de construcción mental útiles para proceder con aspectos de diseño limitados y específicos en el momento del desarrollo de un sistema de software, su concepto dominante es la reutilización.

Origen e historia de patrones
En la década del 90 fue la época del surgimiento de los patrones, definidos en dos orientaciones diferentes, las cuales fueron plasmadas en dos libros fundamentales sobre el tema, “Design Patterns” escrito por la Banda de los Cuatro (GoF)1 [Gamma95] en 1995 y el libro “Pattern-Oriented Software Architecture, A System of patterns”2 de la serie POSA [Buschmann+96] en 1996. El primero de ellos presenta un conjunto de patrones de diseño de software bajo el paradigma de la orientación a objetos, mientras que el segundo despliega un marco levemente más ligado a la Arquitectura de Software. Este surgimiento no ha hecho más que expandirse desde esos años. Aunque el arquitecto Christopher Alexander hacía referencia a patrones de edificios y urbanos, lo que él proponía se puede aplicar de igual forma a patrones de software, donde las soluciones se plantean en términos de componentes, interfaces y relaciones en lugar de paredes y puertas.

1 2

Del 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.
Pag 5

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

Años más tarde, las ideas llegaron por fin a la informática. Si bien el concepto de arquitectura implícita en el trabajo actual con patrones, está más cerca de la implementación, la reutilización de patrones guarda estrecha relación con la tradición del diseño concreto orientado a objetos. En pos de la Arquitectura de Software en estos años se homogeneizó la terminología utilizada, se tipificaron los estilos arquitectónicos, patrones arquitectónicos, se elaboraron lenguajes de descripción de arquitectura y también se consolidaron las vistas arquitectónicas.

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

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

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.

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

Pag 7

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

Ayudar a implementar aspectos particulares de diseño en un lenguaje de programación específico. 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í.Patrones Arquitectónicos . 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. 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.Estructurar un sistema de software dentro de subsistemas.Soportar el refinamiento de subsistemas y componentes o la relación entre ellos. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 9 . especificando responsabilidades y organizando las relaciones entre ellos. Plantean una organización estructural fundamental para un sistema de software.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: . Para refinar dicha escala podemos agrupar los patrones que representan un rango similar de abstracción en tres categorías: . expresando un conjunto de subsistemas predefinidos.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. . . 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.

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

Genera una solución a un problema indirectamente (un enfoque necesario para los problemas de diseño más difíciles). La solución a un problema puede arribarse aplicando un solo patrón o combinaciones de varios patrones resolviendo problemas más pequeños. Contexto: El contexto extiende la dicotomía problema-solución describiendo la situación en la cual ocurre el problema.. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 11 . En general. . Las restricciones que se deben considerar. todos ellos integrados por un gran patrón que los contenga. 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. o como balancear mejor las fuerzas asociadas a él. El esquema denota una regla que establece una relación entre un contexto dado.No describe módulos sino estructuras y mecanismos de relación entre ellas. 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. - Pone especial atención a la estética y a las utilidades. Solución: La solución parte de un patrón que muestra como resolver un problema recurrente. determinando cual es el problema en concreto que se debe resolver y tratando de balancear sus fuerzas. ayudando a comprender los detalles del mismo y a justificar los diseños y las implementaciones. Esquema de un patrón Todo patrón se representa con un esquema de tres partes: Contexto – Problema – Solución. Comienza con su especificación general. tanto generales como particulares en la cual puede ser aplicado un patrón. Las propiedades deseables que la solución debería tener. las fuerzas atacan al problema desde varios puntos. Es difícil especificar el contexto correcto para un patrón. un cierto problema que tiene lugar en ese contexto y una solución apropiada al problema. El análisis de patrones revela que sus componentes y relaciones no son tan atómicas como se ve a primera vista. siendo prácticamente imposible determinar todas las situaciones. Tiene un componente humano significante. 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.

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. 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. para formalizar un patrón según la nomenclatura sugerida por [Buschmann+96]. el cual captura la esencia de un patrón independientemente de su dominio.Guías que sugieren como implementar el patrón. Estos otros patrones proveen soluciones alternativas a un problema. para transformar una arquitectura dada en una que usan los patrones. debe definirse: . . y además provee todos los detalles necesarios para implementarlo y considerar las consecuencias de su aplicación. esto ayuda a compararlos.2 . Además de esta estructura. Los patrones se definen uniformemente. Estas fuerzas son conflictivas y difíciles de calcular. La estructura básica Contexto – Problema – Solución.Un nombre el cual tiene que ser representativo de su esencia. - Ventajas y desventajas potenciales de un patrón clarificando las consecuencias de su aplicación.En el caso de los patrones. El siguiente diagrama resume un esquema. especialmente cuando se buscan soluciones alternativas a un problema.Variantes de un patrón o patrones relacionados con el que se esta definiendo y cuales son sus diferencias. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 12 .Diagramas y escenarios que ilustren los aspectos estáticos y dinámicos de la solución.Esquema de tres partes : contexto – problema .solución Los patrones se definen utilizando formatos consistentes. éstos relacionan conjuntos de objetivos y restricciones que se encuentran en el desarrollo de cada elemento que se va a crear. que de idea del problema que aborda y de su solución. . 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. Una buena definición de un patrón permite entenderlo inmediatamente. . antes mencionada.

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. Muchos sistemas de software no pueden ser estructurados de acuerdo a un patrón arquitectónico simple.Sistemas Interactivos: En esta categoría entran dos patrones el Model-ViewController (MVC) y el Presentation–Abstraction–Control (PAC). o la combinación de varios.Sistemas Distribuidos: incluye el patrón Broker y hace referencia a dos patrones que se encuentran en otras categorías. Ayudan a evitar un “mar” de componentes u objetos. La selección de un patrón arquitectónico debería ser conducida por las propiedades generales de la aplicación a estudiar. Diferentes patrones arquitectónicos implican diferentes consecuencias. En particular apoyan una descomposición controlada de una tarea del sistema global en subtareas cooperantes. 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. dando soporte a requerimientos del Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 13 . Cada patrón ayuda a lograr una propiedad específica del sistema global como es la adaptabilidad de la interfaz de usuario. Esta categoría incluye los patrones Layers. la elección del patrón debería estar influenciada más allá de los requerimientos no funcionales de la aplicación. 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. es solamente el primer paso cuando se diseña la arquitectura de software de un sistema. Ambos apoyan la estructuración de sistemas de software que ofrecen la interacción usuariocomputadora. si el sistema propuesto es un sistema interactivo o uno que tendrá diferentes variantes. Pipes and Filters y Blackboard. como la modificabilidad y la fiabilidad. . Los patrones que dan soporte a propiedades similares pueden ser agrupados en las siguientes categorías: . Por ejemplo. . . especifican sus responsabilidades e incluyen reglas y guías para organizar las relaciones entre ellos. El patrón Broker provee una infraestructura completa para aplicaciones distribuidas.Del fango a la estructura. Proveen un conjunto de subsistemas predefinidos. aún si direccionan al mismo o problemas similares. Microkernel y Pipes and Filters.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.

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

. Un patrón estructural de clases utiliza la herencia para componer interfaces o implementaciones. los cuales se orientan hacia las arquitecturas generales principales. un ejemplo es el patrón Observer. Idioms En contraste con los patrones de diseño. se puede citar como ejemplo el patrón Command. como representante de este tipo de patrón se puede mencionar al patrón Composite. 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. por lo general. 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. . Los idioms se aproximan o se solapan con áreas que son. los idioms describen cómo resolver problemas de implementación específicos en un lenguaje de programación determinado. 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. Los Idioms pueden también realizar directamente la implementación concreta de un patrón de diseño particular.De Comportamiento: se relaciona con algoritmos. regidas por guías de programación. por ejemplo el patrón Adapter. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 15 . Un patrón estructural de objetos describe la forma en que se componen objetos para obtener nueva funcionalidad.Estructural: controla como se componen las clases u objetos en la construcción de estructuras mayores.

A continuación describiremos con más detalle cada uno de ellos. 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. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 16 . Deben dar soporte a muchos requerimientos de sistema que pueden solamente ser direccionados por diferentes patrones arquitectónicos. Pipes and Filters y Blackboard donde: . Muchos sistemas de software no pueden ser estructurados de acuerdo a un patrón arquitectónico simple. una arquitectura MVC usualmente es más eficiente que una arquitectura PAC. 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. Por ejemplo. Es útil explorar varias alternativas antes de decidir sobre un patrón arquitectónico específico. La combinación de filters permite construir familias de sistemas relacionados. Los datos se pasan a través de los pipes entre filters adyacentes.El patrón Layers ayuda a estructurar aplicaciones que pueden ser descompuestas en grupos de subtareas. En este patrón varios subsistemas especializados ensamblan sus conocimientos para construir una solución posiblemente parcial o aproximada. En forma similar los patrones Reflection y Microkernel apoyan la adaptación de sistemas de software a la evolución de requisitos. . Por otro lado. .El patrón Blackboard es útil para problemas en los cuales no se conoce ninguna estrategia de solución determinística. Por ejemplo.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. Por ejemplo el patrón PAC y el MVC ambos se prestan para aplicaciones interactivas.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. aún si encaminan al mismo o a problemas similares. PAC soporta multitareas y tareas específicas de interfaces de usuarios mejor de lo que lo hace MVC. en el que cada grupo pertenece a un nivel particular de abstracción. Diferentes patrones arquitectónicos implican diferentes consecuencias.

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

lo que da una vista conceptual del sistema. Se deben trabajar los niveles de abstracción colocando una capa sobre otra hasta que se coloque en el tope.1 Figura 4.Layer J . Se debe estructurar el sistema en un número apropiado de capas y ubicarlas unas encima de otras. Cliente Layer N El Nivel mas alto de abstracción Layer N .1 . comenzando por el nivel más bajo de abstracción – Capa 1. 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. el nivel de funcionalidad – Capa N. Los servicios de cada capa implementan una estrategia para combinar servicios de las capas inferiores con algún significado. Estructura Una capa individual se puede describir como sigue: Clase Layer J Responsabilidades . Cada capa individual escuda todas las capas inferiores de accesos directos por capas superiores.Provee servicios usados por la capa J+1 .2 . Es esencial que dentro de una capa individual todo el trabajo del componente constitutivo trabaje al mismo nivel de abstracción.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.Delega las subtareas a la capa 1 Colaborador .Solución Si observamos la solución desde un alto nivel de abstracción esta es extremadamente simple. Esta estructura puede ser comparada con una pila.1 Layer 1 El Nivel mas bajo de abstracción Figura 4. Pag 18 Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago .Esquema de estructuración en capas Consecuencias El patrón Layers tiene varias ventajas: o Reusabilidad. Esta es la base del sistema.

cambiar o agregar un hardware. El patrón Layer también impone desventajas: o Baja eficiencia. y testeo independiente de las capas. o o arquitectura de capas con muy pocas capas no explota completamente la potencial reusabilidad. Esto permite usar productos de diferentes vendedores en distintas capas. Las interfaces estandarizadas entre capas limitan el efecto de cambios de código a la capa a modificar. Un nuevo dispositivo de E/S. La decisión de la granularidad de las capas y la asignación de tareas es dificultosa. Si servicios de alto nivel en capas superiores necesitan obligatoriamente de las capas inferiores. Estos niveles a su vez se dividen en subniveles y llevándolos cada uno a capas diferentes.o Estandarización. por ejemplo. Una arquitectura en capas es usualmente menos eficiente que una estructura monolítica. cambiabilidad y portabilidad de este patrón. pero es indispensable para lograr calidad en la arquitectura. por ejemplo. La implementación de capas individuales puede ser reemplazada por una implementación semánticamente equivalente sin grandes esfuerzos. Una Ejemplo Un ejemplo típico donde se utiliza el patrón Layers es en la estructura del protocolo de comunicación OSI. o Portabilidad. Trabajo innecesario. La arquitectura estaría dividida en las siguientes capas: Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 19 . Dificultad al establecer la correcta granularidad de las capas. Por otro lado. transforman los mensajes de alto nivel mediante el agregado de cabeceras e información de control. del sistema operativo y todo lo que afecta solamente a una capa. Este trabajo excesivo tiene un impacto negativo en la performance. Los cambios de hardware. se puede modificar sin alterar al resto de las capas. Esta es una arquitectura en donde hay varios niveles de comunicación. Capas inferiores pueden necesitar hacer tareas que no han sido solicitadas para brindar un determinado servicio a una capa superior. Los diseñadores hacen uso de varios subprotocolos y los colocan en capas. Esto permite la portabilidad del sistema. puede ser puesto en operación instalando el driver correcto. Implementaciones diferentes de la misma interfaz pueden ser usadas en forma indistinta. y puede llevar mucho tiempo. Las capas superiores no se verán afectadas por el cambio. partiendo desde el hardware pasando por la comunicación punto a punto y llegando a los protocolos de aplicaciones. todo dato relevante debe ser transferido a través de varias capas intermedias. también muchas capas introducen complejidad innecesaria de sobrecarga en la separación y la transformación de argumentos y valores de retorno. Niveles de abstracción claramente definidos y comúnmente aceptados habilitan el desarrollo de tareas e interfaces estandarizadas. La comunicación de protocolos. Cada capa lleva a cabo una tarea específica para la comunicación y utiliza los servicios que le brinda su capa inmediata inferior. o Cambiabilidad.

Pipes and Filters El patrón arquitectónico Pipes and Filters provee una estructura para sistemas que procesan flujo de datos. Mantener la independencia entre capas de esta manera. imposibilitando la comunicación entre capas no adyacentes. Combinando filters se permite la construcción de una familia de sistemas relacionados. cambiando o reordenando los pasos del procesamiento se planifica la futura flexibilidad.3 . . construyendo de sistemas que usen los componentes existentes del proceso. permite realizar modificaciones en una capa sin que esto afecte al resto de las capas.El sistema es desarrollado por varios desarrolladores. y con su capa inmediatamente superior para brindarle servicio. Por lo tanto. La estratificación en capas es considerada una mejor práctica que la implementación del protocolo como un bloque monolítico.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.Los requerimientos probablemente son cambiables. donde cada paso de procesamiento es encapsulado en un componente filter y los datos pasan entre filters adyacentes.Esquema del protocolo de red OSI Donde cada una de ellas se comunica solo con su capa inmediatamente inferior para solicitarle servicios. 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: . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 20 .La tarea de un sistema global se descompone naturalmente en varias fases del proceso.

un programa.los refina concentrando o extrayendo la información y . Cada paso de procesamiento es implementado por un componente filter. refina o transforma la entrada de datos. La entrada al sistema es provista por una fuente de datos.los transforma entregándolos en alguna otra representación.logrando. por ejemplo. Estructura Los filters son la unidad de procesamiento de los pipelines. . La fuente de datos. es el primero en salir. y entre el último filter y los datos de salida.Debería ser posible presentar o almacenar resultados finales en formas diferentes. . . . Un filter enriquece. un archivo de texto. de esta forma. . los filters y la salida de datos están conectados secuencialmente por pipes. etc.El sistema debería permitir diferentes fuentes de entrada de datos. 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. Los pipes sincronizan dos componentes filtres adyacentes. Un filter consume y entrega datos incrementalmente – en vez de consumir todas sus entradas antes de producir cualquier salida. baja latencia y habilitando un proceso realmente paralelo. Una implementación concreta de filter puede combinar cualquiera de estos tres principios básicos. una terminal. Solución El patrón Pipes and Filters divide la tarea del sistema en varios pasos de procesamiento. como puede ser una conexión a la red o un sensor de hardware que provee lecturas de temperaturas. La secuencia de filters combinada por pipes es llamada Procesamiento Pipelines. La sincronización es hecha en el buffer como el primero en entrar.Pasos de procesamiento que no son adyacentes no deberían compartir información. entre la fuente de datos y el primer filter. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 21 .Pequeños pasos de procesamiento deberían ser fáciles de reusar en diferentes contextos de grandes componentes. . Los pipes denotan la conexión entre filters.Debería posibilitar futuros perfeccionamientos de sistemas intercambiando o recombinando pasos de procesamiento. Cada pipe implementa el flujo de datos entre pasos de procesamiento adyacentes.Enriquece los datos computando y agregándole información.Al realizar el diseño del sistema – especialmente la interconexión de pasos de procesamiento – se deben considerar las siguientes fuerzas: . El flujo de datos de salida es un almacenamiento como puede ser un archivo.

6 .Estructura Patrón Pipe and Fliter Consecuencias El patrón Pipes and Filters tiene las siguientes ventajas: o No son necesarios archivos intermedios. El uso de este patrón quita la necesidad de archivos intermedios.5 . Pag 22 Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago .Toma los datos de la entrada .La fuente de datos datos . o un sensor entregando una sucesión de números.Consumir la salida Figura 4.Suministra datos de salida Colaborador . El almacenamiento de datos reúne los resultados del extremo del pipeline. Ejemplos de tales fuentes de datos son un archivo que contiene líneas de texto.Sincroniza los vecinos activos Colaborador .Pipe Responsabilidades .Pipe Clase Pipe .Filter Responsabilidades .4 . pero es posible su utilización.El repositorio de Figura 4. pero permite investigar los datos intermedios usando la unión “T” en el pipeline. Es posible calcular resultados usando programas separados sin pipes.Transfiere los datos Almacena los datos . Clase La fuente de datos Colaborador . guardando los resultados intermedios en archivos.Clases Repositorio y Fuente de datos La estructura del patrón arquitectónico Pipe and Filter es: filter pipe filter pipe filter pipe pipe filter pipe pipe pipe filter pipe filter Figura 4.Pipe Clase El repositorio de datos Colaborador .Clase Filter Responsabilidades .Clases Pipe y Filter La fuente de datos representa la entrada al sistema.Realiza una función en los datos de entrada .Entrega la entrada al pipeline para procesar Responsabilidades . y provee una secuencia de valores de datos de algún tipo o estructura.

Las Ventajas precedentes hacen esto más fácil para el prototipo de un sistema de procesamiento de datos de los filters existentes. Algunos filters consumen todas sus entradas antes de producir cualquier salida. 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. Permite la recombinación de filters facilitando el reuso de sus El prototipado rápido de los pipelines. Un pipeline sin una fuente o un almacenamiento de datos puede ser embebido como un filter dentro de un pipeline más grande. Esto se debe a varias razones: • • o El costo de transferir datos entre filters puede ser relativamente alto comparado con el costo de realizar cómputos en un solo filter. o Flexibilidad por recombinación. 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.o Flexibilidad por el intercambio de filters. Después que se tiene la implementación de la función del sistema principal usando un pipeline. Esto puede ser debido a que el filter esta mal codificado. 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. Los filters tienen una interfaz simple que permite su intercambio fácilmente dentro del procesamiento del pipeline. se puede optimizar incrementalmente. 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. o o Reusabilidad. Este es el mayor beneficio. o Manejo de errores. permitiendo la creación de nuevos procesos pipelines reestructurando los filters o agregando uno nuevo. Ejemplo Unix ha popularizado el paradigma pipe and Filter. 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. produce y consume datos incrementalmente pueden realizar sus funciones en paralelo. En Blackboard varios subsistemas especializados asocian sus conocimientos para construir una posible solución parcial o aproximada. o Eficiencia del procesamiento en paralelo. El comando shell y la disponibilidad de varios programas filters hacen de Unix un sistema popular. componentes. combinado con la reusabilidad de los componentes filters. Como un sistema para diseñadores de software. Si cada filter en un pipeline Aplicar patrones Pipes and Filters imponen algunas desventajas: o Compartir el estado de la información es caro o poco flexible. El manejo de errores es una gran debilidad del patrón Pipes and Filters. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 23 .

Datos inciertos y soluciones aproximadas están relacionados . El conjunto de todas las soluciones posibles se llama espacio de solución. y todos los programas trabajan en conjunto en pos de una solución. tienen representaciones diferentes.El empleo de algoritmos separados induce a un potencial paralelismo. En muchos casos no existe una estrategia predeterminada de “cómo resolver el problema parcial”. .La búsqueda completa del espacio de solución no sería factible en un tiempo razonable.Un algoritmo normalmente trabaja sobre los resultados de otros algoritmos. 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. . Las soluciones potenciales de la tarea del sistema global están en el nivel más alto. reconocimiento de imágenes y reconocimiento de lenguaje. como también resultados intermedios y finales. De ser posible se debería evitar una solución estrictamente secuencial. Hay diferentes algoritmos que resuelven problemas parciales. cambiadas o rechazadas. y los algoritmos se llevan a cabo según paradigmas diferentes. Las siguientes fuerzas influyen en soluciones a los problemas de este tipo: . Cada paso de la transformación también puede generar varias soluciones alternativas.La entrada. . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 24 . se podría necesitar experimentar con algoritmos diferentes para la misma subtarea.Contexto Un dominio poco definido en el cual no se conoce o no es factible alguna posible solución concreta. Ejemplos de dominios en los que ocurren tales problemas son visualización. para ello se debe combinar conocimientos. La característica de estos problemas es cuando se necesitan descomponer en subproblemas que requieren varios campos de especialización. Cada una de estas soluciones representa un problema parcial y un cierto estado del proceso de la solución. 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. Las soluciones a los subproblemas requieren diferentes representaciones y paradigmas. 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. Durante el proceso problema-solución el sistema trabaja con soluciones parciales combinadas. y es organizado en niveles de abstracción.Debido a que el dominio es imperfecto. Cada programa se especializa en resolver una parte particular de la tarea global. . Si bien los programas son independientes unos de otros. El nivel más bajo de solución consiste en una representación interna de la entrada.

Blackboard . Proporciona una interfaz que habilita a todas las fuentes de conocimiento para leer y escribir en ella.7 . La pizarra es el almacenamiento central de datos que guarda también los elementos del espacio de solución y el control de datos. En este caso. y un componente de control. Las fuentes de conocimiento son subsistemas separados e independientes que resuelven aspectos específicos del problema global y modelan el dominio del mismo.Computa un resultado . es más probable que cada paso de razonamiento introduzca Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 25 . Clase Control .Monitorea el Blackboard .Estructura El sistema se divide en un componente llamado pizarra. Cada fuente de conocimiento es responsable de conocer las condiciones bajo las cuales puede contribuir a una solución.8 . La base para esta estrategia es el dato sobre la pizarra.Maneja las activaciones de las fuentes de conocimiento Colaborador .Actualiza el blackboard Figura 4. Sus resultados se llaman datos de control y también se ponen en la pizarra.Evalúa su propia pertinencia . el sistema falla al entregar un resultado. Establece las evaluaciones de la fuente de conocimiento y activaciones de acuerdo a una estrategia de aplicación conocida. 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. En la práctica. que ayuda a la toma de decisiones de control. una colección de fuentes de conocimiento. evaluando el estado actual del proceso de la solución para determinar si puede hacer una contribución. es posible que la pizarra pueda alcanzar el estado en el cual ninguna fuente de conocimiento es aplicable.Clases Control Teóricamente. y producir un resultado que puede causar un cambio en el contenido de pizarra.Fuente de Responsabilidades Conocimiento Figura 4.Blackboard Responsabilidades .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. Clase Blackboard Responsabilidades . Ellas sólo leen y escriben en la pizarra.Maneja los datos centrales Colaborador Clase Fuente de Conocimiento Colaborador .

el patrón Blackboard experimenta con la mayor cantidad posible de algoritmos diferentes. Cambiabilidad y mantenibilidad. por lo tanto sus resultados no son a menudo reproducibles. y que el número de posibles próximos pasos “explote”. Los cómputos de este patrón no siguen un algoritmo determinístico.varias hipótesis nuevas. Normalmente puede resolver correctamente sólo un cierto porcentaje de las tareas dadas. El problema es por consiguiente restringir las alternativas a ser tomadas. resultados son sólo hipótesis. aporta las siguientes ventajas: o Experimentación. Los requisitos previos para reusar son que la fuente de conocimiento y el sistema Blackboard subyacente entiendan el mismo protocolo y datos. Las fuentes de conocimiento son independientes para ciertas o Tolerancia a fallos y robustez. tareas.9 . Fuente de conocimiento Pizarra Control Figura 4.Estructura del Patrón Arquitectónico Blackboard Consecuencias. En dominios en que no existe alguna posible solución y una búsqueda completa del espacio de la solución no es factible. La arquitectura Blackboard soporta la cambiabilidad y mantenibilidad porque las fuentes de conocimiento individuales. Además. En una arquitectura Blackboard todos los El patrón Blackboard tiene algunas desventajas: o Dificultad de testeo. Una arquitectura Blackboard ayuda haciéndolas reusables. La forma en que el patrón Blackboard descompone el problema y aplica el conocimiento. o cuando finalizan los recursos del sistema de espacio o tiempo. el algoritmo de control y la estructura de datos central están estrictamente separados. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 26 . o No se garantiza ninguna buena solución. El sistema se detiene cuando se encuentra una hipótesis aceptable. y también permite intentar con diferentes heurísticas de control. que son o o Reusabilidad. y cual es el resultado final. Sólo sobrevivirán aquellas fuertemente soportadas por los datos y otras hipótesis. hipótesis erróneas son parte del proceso de solución. Una fuente de conocimiento especial o un procedimiento en el componente de control determina cuando el sistema se debe detener.

HASP trata con múltiples flujos de entrada. Algunas aplicaciones son naturalmente distribuidas. multiprocesadores y redes son fácilmente escalables. La arquitectura Blackboard no provee la ejecución en paralelo. o o Baja eficiencia. La estrategia de control no puede diseñarse de una manera íntegra. 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. Los Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 27 . aún las pequeñas compañías usan sistemas distribuidos. En la mayoría de los casos. La performance puede mejorar enormemente si se utiliza en forma combinada. Como la información se recolecta continuamente. En este sistema. por ejemplo Fiabilidad. usan recursos disponibles en toda la red. hay información redundante como también nueva y diferente. Alto esfuerzo de desarrollo.o Dificultad de establecer una buena estrategia de control. o No soporta paralelismo. Performance y Escalabilidad. La mayoría de estos sistemas toman años para evolucionar. el poder de cómputo de varios nodos de red. y requiere un acercamiento experimental. ¿Pero cuáles son las ventajas de los sistemas distribuidos que los hacen interesantes? Economía. Además. 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. aplicaciones de base de datos en un modelo Cliente-Servidor. Un ejemplo de uso es un sistema HASP diseñado para detectar submarinos enemigos. Redes de computadoras que incorporan PCs y workstations ofrecen una mejor relación costo/performance que un mainframe. Un sistema Blackboard interpreta estas señales. una máquina en una red o una CPU en un sistema multiprocesador puede dejar de funcionar sin afectar el resto del sistema. Ejemplo Se ha usado tradicionalmente el patrón Blackboard para aplicaciones que requieren complejas interpretaciones de procesamiento de señales. El acceso concurrente a los datos centrales en la pizarra se debe sincronizar. 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. Padece el exceso computacional del rechazo de las hipótesis erróneas. como también en sistemas que involucran el acceso compartido a datos con agentes escasamente acoplados. Distribución inherente. La pizarra es usada como una “tabla de situación” que evoluciona con el tiempo. Sistemas Distribuidos Hoy día. 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. Las aplicaciones distribuidas.

La recombinación de filters permite construir familias de sistemas relacionados. Este patrón separa la funcionalidad central mínima de la funcionalidad extendida y las partes específicas del cliente. Dividiendo la funcionalidad en los componentes independientes del sistema. se torna potencialmente distribuible y escalable.Los sistemas Microkernel emplean una arquitectura Cliente-Servidor en los cuales clientes y servidores corren sobre el componente microkernel. Desde el punto de vista de un diseñador.El patrón Pipes and Filters mantiene una estructura para sistemas que procesan un flujo de datos. en lugar de una aplicación monolítica. mantenibles y cambiables. Problema Construir un sistema de software complejo como un conjunto de componentes desacoplados que interoperan. sin embargo tienen un inconveniente significante. Una aplicación que usa un objeto debería sólo Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 28 . . Este patrón es descripto más adelante en este capítulo dentro de la clasificación de patrones adaptables. Contexto El ambiente es un sistema distribuido y posiblemente heterogéneo con componentes independientes que cooperan entre sí. . transmitir los resultados y excepciones). necesitan software totalmente diferente a los sistemas centralizados. Un componente broker es responsable de coordinar la comunicación (remitir las demandas. El patrón Microkernel se aplica a sistemas de software que tienen la necesidad de adaptar el sistema a requerimientos cambiantes. El microkernel también sirve como un socket para comunicar estas partes y coordinar su colaboración. pero puede protegerse con sistemas auxiliares. así como transmitir resultados y excepciones. Tres modelos relacionados a sistemas distribuidos en esta categoría: . Un componente Broker es responsable de coordinar la comunicación.El patrón Broker puede usarse para estructurar sistemas de software distribuidos con componentes desarticulados que se comunican mediante invocación remota de servicios. es por ello que lo ubicamos junto al patrón Layers en la clasificación anterior. El mayor beneficio de estos sistemas. 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. Los datos son pasados a través de pipes entre filters adyacentes. Los sistemas distribuidos. remitir las demandas. Cada paso del proceso es encapsulado en un componente filter.nodos centrales como los servidores de archivos son las excepciones a esto. los resultados son altamente flexibles. Este patrón se utiliza más por estructurar la funcionalidad central de una aplicación que por su naturaleza distribuida. está en el diseño apto para la adaptación y cambio. 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.

agregar o quitar componentes en tiempo de ejecución. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 29 . Estas interfaces son realizadas a través de un lenguaje de definición de interfaz (IDL). Hay dos tipos de servidores: • • Servidores que ofrecen los servicios comunes a muchos dominios de aplicación. agregar. haciendo la distribución transparente al diseñador.Si se necesitase intercambiar. Solución Introducir un componente broker para lograr una mejor separación de clientes y servidores. - La arquitectura debería ocultar de los usuarios de componentes y servicios. una aplicación puede acceder a servicios distribuidos simplemente enviando mensajes a un objeto apropiado. Los componentes clientes son aplicaciones que acceden a los servicios de por lo menos un servidor. Los clientes acceden funcionalmente a los servidores enviando las solicitudes a través del broker.ver la interfaz ofrecida por el objeto. Usando el patrón Broker. Las tareas de un broker incluyen localizar al servidor apropiado. en lugar de enfocarse en la comunicación inter-proceso de bajo nivel. detalles específicos del sistema e implementación. La arquitectura Broker tiene la ventaja de ser flexible. remitir la solicitud al servidor y transmitir respuestas y excepciones al cliente. 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. Se debe usar la arquitectura Broker para equilibrar las siguientes fuerzas: . y reubicar los objetos. lo que le permite realizar cambios en forma dinámica. Logra esta meta introduciendo un modelo de objeto en el que se encapsulan los servicios distribuidos dentro de los objetos. 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 componentes deberían poder acceder a los servicios proporcionados por otros aunque sean remotos. . El patrón Broker reduce la complejidad involucrada desarrollando las aplicaciones distribuidas. Las invocaciones de servicios remotos deben ser transparentes respecto de su ubicación. eliminar. Servidores que implementan la funcionalidad específica por un solo dominio de aplicación o tarea. Las interfaces se agrupan por su funcionalidad semánticamente relacionada. No debería necesitar conocer los detalles de implementación de un objeto o su ubicación física.

el broker local encuentra una ruta al broker remoto y envía la solicitud usando esta ruta. incluso mientras el sistema está corriendo.Proxy del lado del Cliente Clase Servidor Responsabilidades . 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. . Si el servidor especificado es direccionado por otro broker.Interopera con otros brokers a través de los puentes.Implementa los servicios . Localiza servidores Colaborador . en el que los roles de clientes y servidores están estáticamente definidos.Broker Figura 4.Clase Broker Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 30 . Todas las respuestas y excepciones de la ejecución de un servicio son remitidas por el broker al cliente que envió la solicitud. 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.Cliente .Clases Cliente y Servidor El componente broker es responsable de la transmisión de solicitudes de los clientes a los servidores. .Proxy del lado del cliente . Clase Cliente Responsabilidades .Proxy del lado del servidor .Broker .Ofrece APIs. tal como los servicios de nombre o soporte de marshaling.La interacción entre los clientes y los servidores está basada en un modelo dinámico. éste pasa la solicitud directamente al servidor.Implementa la funcionalidad del usuario .Se registra a si mismo con el broker local .Puente Figura 4.Servidor . el cual posibilita a los servidores poder también actuar como clientes.Transfiere mensajes. También debe tener alguna forma de localizar al receptor de una solicitud basada en su único identificador del sistema.Envía solicitudes al Server a través del Proxy del lado del cliente Colaborador . .10 . Clase Broker Responsabilidades . Si el servidor esta actualmente inactivo. como de la transmisión de respuestas y excepciones al cliente. Desde el punto de vista de una aplicación se puede considerar a los clientes como aplicaciones y a los servidores como bibliotecas. . Cuando una solicitud llega a un servidor que es mantenida por el broker local. se puede integrar en el broker servicios adicionales. Dependiendo de los requisitos de todo el sistema.Proxy del lado del Servidor .11 .Se recupera de errores. Este modelo de interacción dinámica difiere de la noción tradicional de Cliente-Servidor. el broker lo activa.Envía respuestas y excepciones hacia el cliente a través del Proxy del lado del servidor Colaborador .Registra y da de baja servidores.

desempaquetar los mensajes entrantes.Llama a los servicios con/en el servidor . y llamar al servicio apropiado. el cliente ve a un objeto remoto como si fuese local. Los componentes proxies del lado del servidor son generalmente análogos a los proxies del lado del cliente. Un bridge construye una capa que encapsula todos estos detalles específicos del sistema.12 .Broker Figura 4.Encapsula funcionalidad especifica del sistema . La creación y eliminación de bloques de memoria. Clase Proxy del lado del Cliente Responsabilidades .Media entre el cliente y el broker Colaborador . realizar el unmarshaling de los parámetros. Si se transmiten las solicitudes sobre la red. Esta capa adicional proporciona transparencia. realiza el unmarshaling de los datos y lo envía al cliente. los diferentes brokers tienen que comunicarse independientemente del uso de redes y sistemas operativos diferentes. Clase Bridge Colaborador .Media entre el Servidor y el broker Colaborador . Los componentes bridges son componentes opcionales usados para ocultar los detalles de implementación cuando dos broker ínter-operan en una red heterogénea.Cliente . el proxy del lado del cliente recibe el mensaje entrante desde el broker.Encapsula funcionalidad especifica del sistema .Broker Clase Proxy del lado del Servidor Responsabilidades . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 31 . Este responde a un patrón de diseño cuya descripción se hace en el capítulo siguiente. La diferencia es que son responsables de la recepción de las solicitudes. 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.Los componentes proxies del lado del cliente representan una capa entre el cliente y el broker.Clases Proxy del lado del Cliente y Proxy del lado del Servidor. Además se usan para realizar el marshaling de los resultados y excepciones antes de enviarlos al cliente.Media entre el broker local y el bridge de un broker remoto Figura 4.13 .Bridge Responsabilidades .Broker .Clase Bridge.Encapsula la funcionalidad de una red especifica .Servidor . El marshaling de parámetros y resultados. Cuando se retorna los resultados o excepciones desde un servidor.

Si los servidores cambian pero sus interfaces permanecen iguales. De igual forma. algunas implementaciones broker establecen sólo el enlace de comunicación inicial entre un cliente y un servidor. El sistema Broker oculta detalles del sistema operativo y del o Interoperabilidad. 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. 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.Hay dos tipos diferentes de sistemas Broker: aquellos que usan comunicación directa y aquellos que usan comunicación indirecta. en estos casos. Cambiabilidad y extensibilidad. Al construir nuevas aplicaciones clientes.14 . no tiene otro efecto en los clientes y servidores más que cambios en la performance. frecuentemente están Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 32 . proxies y bridges. Proxy del lado del cliente Broker Proxy del lado del Servidor Cliente Bridge Servidor Figura 4. El uso de proxies y bridges es una razón importante para facilitar la implementación de cambios. los clientes no necesitan saber dónde se localizan los servidores. Diferentes sistemas Broker pueden interoperar si entienden un protocolo común para el intercambio de mensajes. se recomienda estructurar los componentes del broker en capas o o Portabilidad. Para lograr una buena performance. basadas en la funcionalidad de la aplicación en servicios existentes.Estructura del patrón Broker Consecuencias El patrón arquitectónico Broker tiene algunas ventajas importantes: o Transparencia. no tiene impacto funcional en los clientes. sistema de red a clientes y servidores usando capas de indirección como las API’s. o Reusabilidad. 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. Esta comunicación implica que requerimientos de los servidores y clientes usen y entiendan el mismo protocolo. Como el broker es responsable de localizar un servidor usando un único identificador. mientras el resto de la comunicación se hace directamente entre los componentes participantes -mensajes. Modificando la implementación interior del broker pero no las API’s que él provee. 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.

distribuido. Se describen dos patrones que brindan una organización estructural fundamental para software de sistemas interactivos: Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 33 . porque el broker introduce capas de indirección que permite ser portable. o interfaces que deben ajustarse para articular en los procesos de negocio de un cliente. Se puede aumentar la fiabilidad a través de la replicación de componentes.El patrón arquitectónico Broker impone algunas desventajas: o Eficiencia restringida. Al especificar la arquitectura de tales sistemas. Sin embargo. Una aplicación cliente desarrollada de servicios probados es más robusta y fácil de testear. están sujetas a cambio y modificación. Sistemas que dependen directamente de un mecanismo concreto para la comunicación interproceso dan mejor performance que una arquitectura Broker. El centro de los sistemas interactivos esta basado en los requerimientos funcionales del sistema. o Baja tolerancia a fallos. Comparado con un sistema de software no El siguiente aspecto da ventajas así como también desventajas: o Testing y debugging. Estos sistemas proporcionan un acceso conveniente a sus servicios. todas las aplicaciones que dependen del servidor o el broker son incapaces de continuar con éxito. 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. CORBA es una tecnología orientada a objetos para objetos distribuidos sobre sistemas heterogéneos. El objetivo es robustecer la utilidad de una aplicación. sin embargo. flexible y cambiable. En caso que un servidor o un broker falle durante la ejecución de un programa. Sistemas Interactivos Los sistemas actuales permiten un grado alto de interacción del usuario. generalmente. un sistema Broker puede ofrecer menos tolerancia a fallos. 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. Por ejemplo. con la ayuda de interfaces de usuario gráficas. realizar el testeo y la depuración de un sistema Broker es un trabajo tedioso debido a la cantidad de componentes involucrados. y normalmente permanece estable. Las interfaces de usuario. Ejemplo El patrón arquitectónico Broker es utilizado para especificar la arquitectura CORBA. el desafío es mantener la funcionalidad central independiente de la interfaz de usuario. es probable que se requiera a los sistemas contar con diferentes interfaces de usuario. lo cual permite a los usuarios aprender la aplicación y producir resultados rápidamente. Un lenguaje de definición de interfaz esta disponible para soportar la interoperabilidad de objetos clientes y servidores.

El patrón Presentation-Abstraction-Control (PAC) define una estructura para los sistemas interactivos en forma de una jerarquía de agentes de cooperantes. 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.. tal como organizar eficazmente la comunicación entre diferentes partes de la funcionalidad central y la interfaz de usuario. forman la interfaz del usuario. abstracción y control. Un gerente quiere usar el mismo sistema pulsando iconos y botones. . El modelo contiene la funcionalidad central y los datos. uno para cada implementación de interfaz de usuario ya que los cambios resultantes se distribuyen por muchos módulos. Las vistas despliegan el información al usuario. También dirige problemas que MVC deja sin resolver. Problema Las interfaces del usuario son especialmente propensas a cambios en los requerimientos. Los controladores se ocupan de las entradas del usuario. MVC brinda probablemente la más conocida organización arquitectónica para los sistemas de software interactivos. Un mecanismo de propagación de cambio asegura la consistencia entre la interfaz del usuario y el modelo. Un data entry ingresa la información a través del teclado. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y consiste de tres componentes: presentación. PAC es una alternativa para estructurar aplicaciones interactivas. Esto puede producir la necesidad de desarrollar y mantener varios sistemas de software substancialmente diferentes. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 34 .El patrón Model-View-Controller (MVC) divide una aplicación interactiva en tres componentes. las Vistas despliegan la información al usuario y los Controladores manejan la entrada del usuario. Contexto Aplicaciones interactivas con una interfaz de usuario flexible. En consecuencia. se debe contar con distintas interfaces de usuario para los mismos datos. en conjunto. si la interfaz de usuario se entreteje herméticamente con el centro funcional. Las vistas y controladores juntos forman la interfaz de usuario. El Modelo contiene la funcionalidad central y los datos. Construir un sistema con la flexibilidad requerida es caro y propenso errores. Un cliente puede requerir una adaptación específica de la interfaz. Estos dos últimos componentes. Model-View-Controller El patrón arquitectónico Model-View-Controller (MVC) divide una aplicación interactiva en tres componentes. Diferentes usuarios pueden definir requisitos contradictorios sobre la interfaz de usuario en base a sus necesidades. y sobre todo aplicable a sistemas que cuentan con varios subsistemas confiados en si mismo. Un mecanismo de propagación de cambios asegura la consistencia entre la interfaz de usuario y el modelo.

Todas las vistas y controladores seleccionados indican en el registro que necesitan actualizar sobre los cambios producidos. Es un componente totalmente independiente de las representaciones específicas de salidas o del comportamiento de la entrada.Los cambios en los datos se deben reflejar inmediatamente en las vistas y el comportamiento. 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. pero cada vista tiene una relación uno a uno con un controlador.Las siguientes fuerzas influyen en la solución: . Este mecanismo es el único eslabón entre el modelo. las vistas y los controladores. una vista recupera los valores de datos actuales del modelo para ser mostrados. Los eventos son traducidos para servir a las demandas del modelo o las vistas. El modelo notifica a todas las vistas siempre que sus datos hayan cambiado. normalmente como eventos que codifican los movimientos del mouse o entrada del teclado.Los cambios a la interfaz del usuario deben ser fáciles. El usuario interactúa con el sistema solamente a través de los controladores. entrada y salida. vista y controlador. Las vistas recuperan los nuevos datos del modelo y actualizan la información mostrada. permiten múltiples vistas del mismo modelo. e incluso posibles en tiempo de ejecución.La misma información es presentada en forma diferente en diferentes vistas. se deben reflejar los cambios en todas las otras vistas que dependen de esos datos. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 35 . . Si el usuario cambia el modelo a través del controlador de una vista. El modelo encapsula los datos centrales y tiene la funcionalidad de la aplicación. Cuando es llamado el procedimiento de actualización. Solución La separación de los componentes modelo. Cada vista define un procedimiento de actualización que se activa por el mecanismo de propagación de cambios. Estructura El Model-View-Controller (MVC) divide una aplicación interactiva en tres áreas: procesamiento. Los controladores reciben la entrada. Pueden existir múltiples vistas de un mismo modelo. Diferentes vistas presentan la información del modelo al usuario de distintas maneras. y los pone en la pantalla El mecanismo de propagación de cambios mantiene un registro de los componentes dependientes dentro del modelo. .

17 .Se registran vistas y controladores dependientes .Modelo Clase Vista Responsabilidades .Vista . Múltiples vistas pueden ser implementadas y usadas con un simple modelo. Clase Controlador Colaborador .Vista .Crea e inicializa su controlador asociado .Traduce eventos a solicitudes para el modelo o muestra solicitudes para la vista . Los controladores aceptan la entrada del usuario como eventos. Si la conducta de un controlador depende del estado del modelo.Acepta las entradas del usuario como eventos .Recupera los datos desde el Modelo Responsabilidades . Las vistas ofrecen a menudo funcionalidad que permite a los controladores manejar la forma en que se muestran los datos. Los eventos se traducen en las demandas para el modelo o la vista asociada. MVC separa al modelo de los Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago . Cada vista crea su controlador. Depende de la plataforma de la interfaz del usuario la forma en que estos eventos se entregan al controlador.Estructura del Patrón MVC Consecuencias La aplicación Model-View-Controller tiene varias ventajas: o componentes de la interfaz de usuario.15 .Implementa la actualización Colaborador .Clase Modelo Colaborador .Muestra la información al usuario .16 .Controlador Responsabilidades .Vista . Pag 36 Múltiples vistas del mismo modelo.Modelo Figura 4.Clase Modelo Durante la inicialización todas las vistas son asociadas con el modelo y registradas por el mecanismo de propagación de cambios. Esto es útil para operaciones de usuarios activos que no afectan al modelo.Clases Controlador y Vista La integración de los componentes en este patrón es Vista Controlador Modelo Figura 4.Implementa los procedimientos de actualización . como es hacer un scroll.Notifica a los componentes dependientes de los cambios Figura 4. se registra con el mecanismo de propagación de cambios e implementa un procedimiento de actualización.Provee la funcionalidad central de la aplicación .

exportar una aplicación MVC a una nueva plataforma no afectaría la funcionalidad central de la aplicación. Guardando en caché los datos dentro de la vista. Como el modelo es independiente de todo el código de la o El potencial del framework. Dependiendo de la interfaz del modelo. Seguir estrictamente la estructura MVC. o Acoplamiento de vistas y controladores con un modelo. solo es necesario la implementación conveniente para esa plataforma. 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. Solicitar innecesariamente al modelo datos inalterados debilita la performance si las actualizaciones son frecuentes. Esto implica que cambios en la interfaz del modelo probablemente rompan el código de vista y controlador. en el momento correcto.o Vistas sincronizadas. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 37 . o viceversa. 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. este patrón. 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. o o Conexión entre vistas y controladores. Ejemplo El patrón MVC se ve frecuentemente en aplicaciones interactivas. Esto sincroniza todas las vistas y controladores dependientes. Es improbable que una vista sea usada sin su controlador. mejora la performance. Es posible basar una aplicación framework en Las desventajas de MVC son: o Incremento de la complejidad. Los componentes vista y controlador hacen llamadas directas al modelo. Este problema se magnifica si el sistema usa múltiples vistas y controladores. o Ineficacia en la vista para acceder a los datos. una vista puede necesitar hacer múltiples llamadas al modelo para obtener todos los datos a mostrar. interfaz de usuario. en un editor gráfico. Controladores y vistas son componentes separados pero estrechamente relacionados que impiden su rehúso individual. Cambios en vistas y controladores. con la excepción de vistas de sólo lectura que comparten un controlador que ignore todas las entradas. no siempre es la mejor manera de construir una aplicación interactiva. como por ejemplo. Excesivos número de actualizaciones. o o Cambiabilidad. de los componentes vistas y controladores. 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. También se sostiene que el uso de los componentes separados del modelo.

más otros agentes que mantienen el modelo de datos del sistema y ofrecen funcionalidad que opera sobre esos datos y. debido a que las interacciones usuario-computadora difieren a menudo ampliamente. otros agentes adicionales responsables de las diversas tareas como el manejo de errores o la comunicación con otros sistemas de software. El aspecto de la presentación es particularmente propenso cambios. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y tiene tres componentes: presentación. Las fuerzas siguientes afectan la solución: Los agentes a menudo mantienen su propio estado y datos. Cada agente depende de todos los agentes de niveles más altos y así hasta llegar al agente de nivel superior. Los cambios de agentes individuales. mensajes. Los agentes individuales deberían cooperar eficazmente para proporcionar la tarea global de la aplicación. Los agentes interactivos deberían proporcionar su propia interfaz de usuario. Los sistemas evolucionan con el tiempo. además. o la extensión del sistema con nuevos agentes. Como ser. Cada componente de un agente PAC tiene una tarea específica: • • El componente presentación proporciona la conducta visible del agente. Pag 38 Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago . En esta arquitectura de cooperación de agentes. Para lograr esto. no deberían afectar a todo el sistema. cada agente se especializa en una tarea específica.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. agentes especializados en la interacción usuario-computadora que aceptan la entrada del usuario y el despliegue de los datos. Esta subdivisión separa los aspectos de interacción usuario-computadora del agente central funcional y su comunicación con otros agentes. y todos juntos proporcionan la funcionalidad del 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. La jerarquía entera refleja las dependencias transitivas entre agentes. Problema Los sistemas interactivos pueden verse a menudo como un conjunto agentes cooperantes. y consiste en tres componentes: presentación. se necesitaría un mecanismo de intercambio de datos. Contexto El desarrollo de una aplicación interactiva con ayuda de agentes. y eventos. abstracción. El componente abstracción mantiene el modelo de datos que fundamenta al agente y proporciona la funcionalidad para operar sobre esos datos. y control. abstracción y control.

mediante la funcionalidad de sus componentes: . La funcionalidad de sus componentes es: .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. como las hojas de cálculo o gráficos permitiendo a los usuarios realizar acciones sobre estos. algunos agentes de nivel intermedio y más aun agentes de nivel inferior. • • Los agentes PAC de nivel inferior representan un concepto semántico específico del dominio de la aplicación.El componente abstracción mantiene agentes específicos de datos. además incluye las partes de la interfaz del usuario que no pueden ser asignadas a subtareas particulares. . . pero ningún otro agente PAC depende de estos datos. Puede incluir los elementos de interfaz del usuario común a toda la aplicación. 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. Por ejemplo un agente de este nivel puede mantener varias vistas de los mismos datos.• El componente control conecta los componentes presentación y abstracción. y proporciona la funcionalidad de comunicación con otros agentes.El componente presentación muestra una vista específica del concepto semántico correspondiente. El agente PAC de nivel superior proporciona el centro funcional del sistema.El componente presentación tiene a menudo pocas responsabilidades. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 39 . también pueden implementar servicios del sistema. Los agentes PAC de nivel inferior representan su propio contenido semántico de los conceptos en los cuales los usuarios del sistema pueden actuar. . Debe haber agentes de nivel superior. Mantiene la información sobre la interacción del usuario con el sistema. Los agentes PAC de nivel medio representan cualquier combinación o relación entre los agentes de niveles más bajos. . Este concepto semántico puede ser de tan bajo nivel como un objeto gráfico simple. principalmente acceder y manipular el modelo global de datos. Estructura La responsabilidad principal del agente PAC de nivel superior es habilitar el modelo de datos global del software.El componente control mantiene la consistencia entre los otros dos componentes. Coordina y mantiene la información de la jerarquía de agentes PAC. y proporciona acceso a todas las funciones de usuario que él puede brindar.

Estos componentes se comunican con los agentes de alto nivel para intercambiar eventos y datos. mientras que los datos entrantes se remiten a su componente abstracción.Agente de nivel . Los eventos entrantes son remitidos al componente presentación del agente de nivel inferior. Los agentes PAC de nivel intermedio pueden cumplir dos papeles diferentes: composición y coordinación entre el agente de nivel inferior. 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.Agente de nivel Inferior Responsabilidades .Agente de nivel Responsabilidades .18 .Proveer la funcionalidad central del sistema .Agente de nivel Intermedio . por ejemplo al coordinar múltiples vistas de los mismos datos. incluyendo su interacción humanocomputadora asociada.Agente de nivel superior .Clases de los Agentes PAC. por ejemplo los mensajes del error.Agente de nivel .Controlar los agentes PAC de niveles mas bajos . Si observamos la integración de los componentes PAC con su correspondiente estructura interna Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 40 .Proveer una vista especifica del software o un servicio del sistema. Sus componentes deben: • • • mantener los datos específicos del agente.Controlar la jerarquía PAC Inferior Intermedio Clase Agente de nivel Intermedio Colaborador . Intermedio superior Figura 4. el componente presentación.Compone a los agentes PAC de nivel mas bajo en simples unidades de abstracción superior Clase Agente de nivel Colaborador Inferior . en caso del componente abstracción. son enviados a un agente de nivel superior asociado. . Clase Agente de nivel Colaborador superior .Agente de nivel Responsabilidades . Los eventos y datos de salida.

o o Multitarea. o Complejidad en el componente control. Agentes separados representan diferentes conceptos semánticos en el dominio de la aplicación. Los componentes control son los mediadores de la comunicación entre los otros dos componentes de un agente. Nuevos agentes se integran fácilmente en una arquitectura PAC existente sin mayores cambios para el resto. Consecuencias El patrón arquitectónico Presentation-Abstraction-Control tiene varias ventajas: o Separar intereses. o Decremento en la eficacia. procesos. si un agente de nivel inferior recupera los datos del agente de nivel superior. Las desventajas de este patrón son las siguientes: o Incremento en la complejidad del sistema. La implementación de cada concepto semántico dentro de una aplicación como su propio agente. o máquinas. todos los agentes del nivel intermedio de la jerarquía PAC estarán involucrados en este intercambio de datos. por consiguiente.Presentación Control Abstracción Agentes de Nivel Superior Presentación Control Abstracción Presentación Control Abstracción Agentes de Nivel Intermedio Presentación Control Abstracción Presentación Control Abstracción Presentación Control Abstracción Agentes de Nivel Inferior Figura 4. Los agentes pueden distribuirse fácilmente en diferentes hilos. Por ejemplo. crucial para una colaboración eficaz entre agentes. Todos ellos se comunican entre sí a través de una interfaz predefinida.19 . Cambiabilidad y extensibilidad. impactar en la eficacia del sistema. y entre los diferentes agentes. puede resultar en una estructura compleja del sistema. y para la calidad global de la arquitectura del sistema. Esto permite modificar individualmente el modelo de datos que está debajo de un agente o cambiar su interfaz de usuario. El costo de comunicaciones entre agentes puede Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 41 . Los cambios dentro de los componentes presentación o abstracción de un agente no afectan a otros agentes en el sistema.Integración de clases de los Agentes PAC. La calidad de la implementación del componente control es. Cada agente mantiene su propio estado y datos en forma coordinada e independiente de otro agente.

La aplicación tiene un agente PAC intermedio que coordina a los tres agentes de vista del nivel inferior y los mantiene consistentes.El patrón Microkernel se aplica a los sistemas de software que deben adaptarse a requisitos cambiantes del sistema. El microkernel también sirve como socket para conectar extensiones y coordinar sus colaboraciones. como el tipo de estructuras y mecanismos de llamadas a función.El patrón Reflection provee un mecanismo para estructuras cambiantes y conductas dinámicas de sistemas de software. por otra parte el sistema debe ser fácil de mantener y sencillo para adaptarlo a requisitos cambiantes. Apoya la modificación de aspectos fundamentales. Los cambios a la información contenidos en el meta nivel. También puede ser necesario proporcionar servicios que difieran de un cliente a otro. 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. Los cambios no deberían afectar la funcionalidad central. Su aplicación se construye sobre el meta nivel. Los usuarios del sistema sólo interactúan con los agentes de nivel superior. diferentes versiones adaptan la interfaz del usuario según sus necesidades específicas. Por lo tanto.Ejemplo Considerar un sistema de información de censos que permite observar el crecimiento demográfico con representaciones proporcionales. Puede ser necesario adaptarlos a nuevos estándares o plataformas. la mayor preocupación al especificar la arquitectura de un sistema de software. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 42 . Separa la funcionalidad central mínima de la funcionalidad extendida y las partes específicas de los clientes. por consiguiente. El almacenamiento de datos por si mismo no es parte de la aplicación. o diseños de abstracción claves. Sistemas Adaptables Los sistemas evolucionan con el tiempo .se agrega nueva funcionalidad y los servicios van cambiando. Los usuarios interactúan con el software a través de interfases gráficas. 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. afectan al comportamiento del nivel base. En este patrón. en este ejemplo se puede definir un agente PAC de nivel superior que provea el acceso al almacenamiento de datos subyacente del sistema. El agente de la hoja de cálculo se conecta directamente al agente PAC de nivel superior. Una aplicación debe soportar su propia modificación y extensión a priori. 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. Por ejemplo una versión soporta la asignación de recursos dependiendo de las necesidades de cada región. una aplicación es dividida en dos partes. otras interfases de usuarios y bibliotecas. Ellos deben soportar nuevas versiones de operar sistemas operativos. Sin embargo. Diseñar para cambios es. En esta sección se describen dos modelos que ayudan al diseño para sistemas que se adaptan al cambio: . otras plataformas. .

Los ejemplos más conocidos son las plataformas de la aplicación como los sistemas operativos e interfaces de usuario gráficas. El microkernel también sirve como un socket para conectar estas extensiones y coordinar su colaboración.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.Microkernel El patrón arquitectónico Microkernel se aplica a los sistemas de software que pueden adaptarse a cambios en los requerimientos. Para construir esta vista. Las siguientes fuerzas necesitan particular atención al diseñar tales sistemas: . 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. . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 43 . Los servidores externos implementan su propia vista del microkernel subyacente. . Contexto El desarrollo de varias aplicaciones usando interfaces de programación similares que cuentan con la misma funcionalidad central. Solución Encapsular los servicios fundamentales de la plataforma de aplicación en un componente Microkernel. extensible y adaptable para permitir una fácil integración de tecnologías emergentes. 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. usan las interfaces del microkernel. Los clientes se comunican con servidores externos usando medios de comunicación proporcionados por el microkernel. requiriendo de la plataforma subyacente de aplicación para emular los estándares existentes.Las aplicaciones podrían ser categorizadas en grupos que usan la misma funcionalidad central de formas diferentes.La plataforma de aplicación debería ser portable. 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. Éste separa una función mínima central de la funcionalidad extendida y partes específicas del cliente.La plataforma de aplicación debería cubrir una continua evolución del hardware y software. Cada servidor externo es un proceso separado que representa una plataforma de aplicación. proporciona interfaces que permiten a otros componentes acceder a su funcionalidad. . Además.

Cada uno de estos servidores corre en un proceso separado. Éste implementa servicios centrales como los medios de comunicación o el mantenimiento. Los clientes sólo ven las vistas particulares del dominio de la aplicación subyacente y de la plataforma específica.Servidor Interno Figura 4. Los servidores externos exponen su funcionalidad exportando interfaces de la misma manera que lo hace el propio microkernel. Clase Microkernel Responsabilidades . Recibe solicitudes de servicio de aplicaciones del cliente. Diferentes servidores externos implementan políticas diferentes para dominios de aplicación específicos.Clase Servidor Interno Un servidor externo es un componente que usa el microkernel para implementar su propia vista del dominio de aplicación subyacente.Ofrece facilidades de comunicación . Estructura El patrón Microkernel define cinco tipos de componentes participantes: El microkernel representa el componente principal del patrón. ejecuta los servicios apropiados y retorna los resultados a los clientes. interpreta estas solicitudes. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 44 .Microkernel Responsabilidades . Los servidores internos pueden encapsular algunas dependencias sobre el hardware subyacente o sistema de software. Otros componentes cuentan con todos o algunos de estos servicios básicos.Encapsula algunos sistemas específicos Figura 4.20 .21 . esto lo hacen indirectamente usando una o más interfaces que comprenden la funcionalidad expuesta por el microkernel.Encapsula sistemas dependientes . control y coordinación de recursos como procesos y archivos.Un sistema Microkernel puede verse como una plataforma de aplicación que integra otras plataformas de aplicación. Estos servidores sólo son accesibles por el microkernel.Maneja y controla los recursos Colaborador . Además el componente microkernel encapsula muchas dependencias específicas del sistema.Provee los mecanismos centrales . Clase Servidor Interno Colaborador .Clase Microkernel Un servidor interno representa un componente separado que extiende la funcionalidad provista por el microkernel por medio de las demandas de servicio.Implementa servicios adicionales .

Ocultan al cliente dependencias del sistema tales como los mecanismos de comunicación . Servidor Externo llama Microkernel activa Servidor Interno Inicializa comunicacion envía requerimientos Adapter llama servicios Cliente Figura 4. Ellos son parte del espacio de dirección del cliente.Adapter Clase Adapter Responsabilidades . El componente microkernel colabora el servidor externo. Los adaptadores representan interfaces entre los clientes y sus servidores externos.Clase Servidor Externo Un cliente es una aplicación que está asociada con solo un servidor externo.24 .Microkernel Responsabilidades .Encapsula algunos sistemas específicos Figura 4. El servidor interno es solo accesible por el componente microkernel. Cada cliente es asociado con un adaptador usado como un bridge entre el cliente y el servidor externo. Los adaptadores también protegen a los clientes de los detalles de implementación específicos del microkernel.Microkernel Figura 4.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 .Mantiene las interfases programadas de los clientes .Invoca métodos del servidor externo en nombre de los clientes Colaborador . el servidor interno y adaptadores. y solamente accede a la interfaz de programación que éste le proporciona.Clase Servidor Externo Colaborador .Servidor Externo . y les permite a los clientes acceder a los servicios del servidor de una manera portable.Representa a una aplicación Colaborador . Clase Cliente Responsabilidades .Clases Cliente y Adapter El siguiente diagrama muestra la estructura estática de un sistema Microkernel.22 .23 .

Proporciona todos los mecanismos necesarios para habilitar a los servidores externos a implementar sus políticas. Complejidad de diseño e implementación. o multiprocesadores con memoria local. Windows). Un sistema Microkernel distribuido es aplicable al desarrollo de sistemas operativos o sistemas de base de datos para redes de computadora. permite agregar nuevos servidores externos que implementen sus propias vistas especializadas. La migración del microkernel a un nuevo ambiente de hardware solamente requiere modificaciones en las partes dependientes del hardware. 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. podríamos aplicar este patrón. En dicha configuración. Además. es sencillo escalar el sistema Microkernel a la nueva configuración. Ejemplo Por ejemplo si necesitáramos un sistema operativo que se pueda portar a otro hardware. Además. Para lograr fiabilidad se requiere disponibilidad y tolerancia a fallos. se agrega un nuevo servidor externo. o Flexibilidad y Extensibilidad. Para extender el sistema con capacidades adicionales solo requiere la suma o extensión de servidores internos. Si el sistema Microkernel trabaja sobre una red de máquinas. o Separación de política y mecanismo. y que ejecute programas escritos para sistemas operativos populares existentes (Unix. 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. incrementando la disponibilidad y la tolerancia a fallos de una máquina o servidor. o o Fiabilidad. Escalabilidad. cuando se agrega una nueva máquina a la red. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 46 . o Transparencia. lo provoca que aumento en la mantenibilidad y cambiabilidad de todo el sistema. la arquitectura Microkernel permite a cada componente acceder a otros componentes sin necesidad de conocer su ubicación. Para implementar una vista adicional. En un sistema distribuido los componentes pueden La arquitectura Microkernel también tiene las siguientes desventajas: o o Performance.o Portabilidad. Esta arquitectura permite correr el mismo servidor en más de una máquina. Desarrollar un sistema Microkernel es una tarea no trivial. distribuirse sobre una red de máquinas. La performance es menor que la de un sistema del software monolítico diseñado para ofrecer una vista específica.

Las técnicas necesarias para un sistema cambiable.Los sistemas de software adaptables normalmente tienen una estructura interna compleja. . Una buena solución es especificar una arquitectura que esté abierta a la modificación y extensió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. Contar con un mecanismo uniforme para todos los tipos de cambios es más fácil de usar y entender. La implementación de servicios de la aplicación se extiende sobre varios componentes pequeños con diferentes relaciones entre ellos. Problema Los sistemas del software evolucionan con el tiempo. Los cambios en la información contenida en el meta nivel afectan la conducta del nivel base subsiguiente. En este patrón. . El sistema resultante puede entonces adaptarse a los cambios en los requisitos bajo demanda.Reflection El Patrón arquitectónico Reflection provee un mecanismo para estructura cambiante y conducta dinámica de sistemas de software. Para conservar dichos sistemas mantenibles. 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.Cada cambio en el sistema debe ser implementado y debe probarse cuidadosamente. se prefiere esconder esta complejidad del mantenimiento del sistema. . Soporta la modificación de aspectos fundamentales como los tipos de estructuras y mecanismos de llamada a función. Aspectos que están sujetos a cambios son encapsulados dentro de componentes separados. son también las que hacen difícil y compleja su modificación. El software que activamente soporta y controla su propia modificación debe cambiarse en forma eficaz y segura. como la parametrización. subclases. La implementación se construye en el meta nivel. Varias fuerzas son asociadas con este problema: .Los cambios pueden ser a cualquier escala. Contexto Construcción de Sistemas que soportan su propia modificación a priori. Deben estar abiertos a modificaciones en respuesta a cambios tecnológicos y de requerimientos. .Incluso pueden cambiar aspectos fundamentales de sistemas de software por ejemplo los mecanismos de comunicación entre los componentes. Diseñar un sistema que encuentre un amplio rango de diferentes requisitos a priori puede ser una tarea ardua. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 47 .

Esto conlleva a una arquitectura que esta dividida en dos partes principales: un meta nivel y un nivel base. Al menos cada sistema interno puede describirse de esta manera. El propio protocolo es responsable de verificar la exactitud de la especificación del cambio y realizar dicho cambio. 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. Hay tres fuentes para tal información: • • • proporcionado por el ambiente en tiempo de ejecución del sistema. definido por el usuario. 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 . Cada metaobjeto encapsula la información seleccionada sobre un solo aspecto de la estructura. Por ejemplo. Los metaobjetos construyen la información. 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. la conducta o estado del nivel base. El nivel base define la lógica de la aplicación. Estructura El meta nivel consiste en un conjunto de metaobjetos. y por otra explícitamente accesible y modificable. La interfaz de un metaobjeto permite al nivel base acceder al mantenimiento de la información o al servicio que ofrece. Cada manipulación de los metaobjetos a través de su protocolo afecta el comportamiento del nivel base subsiguiente. pero sin modificar el código del nivel base. 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. Se especifica una interfaz para manipular los metaobjetos llamada protocolo del metaobjeto (MOP). Cambiando el metaobjeto. Sólo detalles del sistema que son probables de cambiar o qué varía de cliente a cliente debe encapsularse por los metaobjetos. Por ejemplo. Por ejemplo. la cual está por una parte sólo implícitamente disponible. 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.Solución Se deben seleccionar aspectos de la estructura y la conducta que sean accesible a la adaptación y el cambio. Su implementación usa los metaobjetos para permanecer independiente de esos aspectos que son probables de cambiar. 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. cambia la manera en que los componentes del nivel base se comunican. y permite a los clientes especificar los cambios particulares como la modificación de mecanismo de llamada a función del metaobjeto.

proceso.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.Provee una interface interna para facilitar las modificaciones al meta nivel Colaborador . El nivel base también específica la colaboración fundamental y las relaciones estructurales entre los componentes que incluye.Nivel Base Figura 4. Un metaobjeto no permite al nivel base modificar su estado interno. Usando los servicios del metaobjeto.Clase Protocolo Metaobjeto Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 49 . Clase Protocolo Metaobjeto Responsabilidades .Encapsula el sistema interno que puede cambiar . 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.Nivel Base Figura 4. ésta también es parte del nivel base. Los componentes de nivel base se conectan directamente a los metaobjetos de los cuales ellos dependen. 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. Esto soporta la implementación de funciones que operan en varios metaobjetos. Los clientes del protocolo metaobjeto. 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. El mismo protocolo es responsable de realizar estos cambios.Meta Nivel Clase Meta Nivel Responsabilidades .26 .25 . Esto permite seguir siendo flexible -su código es independiente de aspectos que pueden estar sujetos al cambio y adaptación. El componente de nivel base siempre consulta el mismo 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.Ofrece una interfaz para cambios en el meta nivel -Lleva a cabo los cambios Colaborador .Implementa la lógica de la aplicación Colaborador . los cuales pueden ser componentes de nivel base u otras aplicaciones. Si el software incluye una interfaz de usuario. Clase Nivel Base Responsabilidades . pueden especificar modificaciones a metaobjetos o a sus relaciones usando el nivel base. Por ejemplo. El protocolo Metaobjeto normalmente se diseña como un componente separado.Meta Nivel . La manipulación sólo es posible a través del protocolo del metaobjeto o por su propio cómputo.

No se necesita tocar el código o Cambiar un sistema del software es fácil.27 . modifica Meta Nivel Recupera información MetaobjetoA MetaobjetoB MOP modifica Nivel Base usa ComponenteA usa usa Interfase de Usuario provee acceso a ComponenteB Figura 4. por si mismo. El meta nivel y el nivel base son dos capas cada una de las cuales proporcionan su propia interfase. Los metaobjetos pueden encapsular cada aspecto del comportamiento del sistema. Esconde la complejidad interna de una aplicación a cambiar y toma el control sobre cada modificación. o Soportar varios tipos de cambios. Por ejemplo modificar un esquema de base de datos sin suspender la ejecución de los objetos en la aplicación que lo usa.Clase Protocolo Metaobjeto Consecuencias El patrón Reflection proporciona las siguientes ventajas: o existente al modificar un sistema reflexivo. o el pasaje de código al protocolo metaobjeto que incluye errores semánticos. se pasa el nuevo código al meta nivel como un parámetro del protocolo metaobjeto. La capa del meta nivel define el protocolo metaobjeto para modificar los metaobjetos. del estado y su estructura. Pag 50 Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago . Una arquitectura basada en este patrón soporta así potencialmente los cambios de casi cualquier tipo o escala. Además deben descubrirse errores potenciales dentro de las especificaciones de cambio antes de realizar el cambio. es responsable de integrar sus solicitudes de cambio realizando modificaciones y extensiones al código del meta nivel y. El protocolo metaobjeto provee un mecanismo seguro y uniforme para realizar estos cambios. Este protocolo. recompila las partes cambiadas y realiza un enlace con la aplicación mientras está se esta ejecutando. En cambio. El patrón Reflection tiene algunas desventajas significantes: o Las modificaciones al meta nivel pueden causar daño. Cada cambio debe tener sólo efecto limitado en otras partes del software. si es necesario. se especifica un cambio llamando a una función del protocolo metaobjeto. La capa de nivel base específica la interfaz del usuario para explotar la funcionalidad de la aplicación. Aun el protocolo metaobjeto más seguro no prevé a los usuarios de especificar modificaciones incorrectas. Al extender el software. Dichas modificaciones pueden causar serios daños al software o su ambiente.La estructura general de una arquitectura reflexiva es muy similar a un sistema Layer. Modificaciones no explicitas de código fuente.

El sistema finalmente establece la ejecución de una lista de métodos aplicables. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 51 . En CLOS más de un método puede ser ejecutado en respuesta a una invocación dada. se soportan sólo cambios que puedan realizarse a través del protocolo del metaobjeto. Baja eficiencia. . Escasa cambiabilidad.Luego ordena los métodos aplicables en orden decreciente de precedencia. Esta capacidad reflexiva requiere procesamiento extra: recuperación de información. metaobjetos cambiantes. Como resultado. Aunque un patrón Reflection ayuda con el desarrollo de software cambiable. por ejemplo cambios o extensiones al código del nivel base. 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.o o Incremento en el número de componentes. Siempre que el nivel base sea incapaz de decidir cómo continuar con el cómputo. y la comunicación entre los dos niveles disminuye la performance global del sistema. Puede suceder que un sistema software reflexivo incluya más metaobjetos que componentes de nivel base. A través de CLOS. no es posible integrar fácilmente todos los cambios imprevistos a una aplicación. o Ejemplo CLOS (Common Lisp Object System) es un clásico ejemplo de un lenguaje de programación reflexiva. . Básicamente. Esto es causado por la compleja relación entre el nivel base y el meta nivel. El proceso de invocaciones de funciones genéricas es definido en el protocolo del metaobjeto de CLOS. pide ayuda al meta nivel. chequeo de consistencia.El primer sistema determina los métodos que son aplicables a la invocación dada. Los sistemas de software reflexivos son normalmente más lentos que los sistemas no-reflexivos. 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: . este ejecuta una cierta secuencia de funciones genéricas del meta nivel.

Si existiera tal patrón. Abstract Factory Crea familias de objetos relacionados o dependientes sin necesidad de especificar su clase concretamente. métodos y atributos de la aplicación que juegan el rol de aquellos prescritos por el patrón. describiendo las clases. .Proveer una librería de una clase de productos y es necesario revelar simplemente sus interfaces. pero ocultar sus implementaciones.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. Es decir. los patrones de creación abstraen el proceso de instanciación. no se vea afectado el resto del sistema. métodos y relaciones que resuelven un problema de diseño en particular.Ser independiente de cómo se crean. En general. de tal forma que al variar su implementación. debido a que la mayor parte de los sistemas Orientados a Objetos necesitan crear instancias de clases. Patrones de Creación Estos patrones facilitan la creación de objetos en un sistema. tratan de ocultar las clases y métodos concretos de creación. se deben identificar las clases. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 52 . El proceso de construcción de aplicaciones utilizando patrones de diseño se reduce a que. de cómo sus objetos son creados. Los patrones de creación muestran la guía de cómo crear objetos. . busca en los catálogos un patrón que lo resuelva. Cada patrón provee información sobre su diseño. cada vez que el diseñador encuentra un problema.Debería ser configurado mediante una de las múltiples familias de productos posibles. 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. Aplicabilidad Se usa el patrón Abstract Factory cuando el sistema a desarrollar debe: . ayudan a independizar a un sistema. se componen y se representan sus productos. . Los patrones han sido agrupados y organizados en catálogos cada uno dando diferentes clasificaciones y descripciones.Se diseña una familia de objetos relacionados que deben ser usados en conjunto.

ella aísla a los clientes de la implementación de clases. Debido a que una fabrica encapsula la responsabilidad y la creación de objetos de productos. concretos. AbstractFactory CreateProductA() CreateProductB() AbstractProductA Client ProductA2 ConcreteFactory 1 CreateProductA() CreateProductB() ConcreteFactory 2 CreateProductA() CreateProductB() ProductA1 AbstractProductB ProductB2 ProductB1 Figura 5. es importante que una aplicación utilice objetos de solo una clase a la vez.Patrón de Diseño Abstract Factory Consecuencias El patrón Abstract Factory tiene las siguientes ventajas: o Aísla clases concretas: Ayuda a controlar las clases de objetos que crea una aplicación. Cliente: usa solo interfaces declaradas. o Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 53 . o Facilita el cambio en familias de productos: La clase de una fábrica concreta aparece solo una vez en la aplicación.1 . permitiéndoles manipular instancias a través de sus interfaces abstractas. AbstractFactory: Declara una interfaz para operaciones que crean objetos de productos ConcreteFactory: Implementa las operaciones para crear objetos de productos 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. 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.Participantes abstractos.

Participantes Builder: Especifica una interfaz abstracta para crear partes de un objeto de Producto. ConcreteBuilder crea la representación interna del producto y define el proceso por el cual es ensamblado. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 54 . . scroll-bars. Builder Separa el proceso de construcción de un objeto complejo de su representación.La construcción de procesos debe permitir diferentes representaciones para el objeto que se construye. Por lo cual agregar un nuevo producto requiere extender la interfaz de la fábrica. provee una interfaz para consultar el producto. lo cual implica cambios en el código de la clase Abstract Factory y todas sus subclases.) ya que su forma de implementación es dependiente del sistema operativo subyacente. 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. y además. Director: construye un objeto usando el patrón Builder Producto: Representa al objeto complejo bajo construcción. porque su interfaz fija el conjunto de productos que se pueden crear. Ejemplo Un ejemplo de uso del patrón Abstract Factory es su uso en la creación de widgets (ventanas.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. Se declara una fábrica abstracta Widget.El algoritmo para crear objetos complejos debe ser independiente de las partes que constituyen el objeto y la forma en que son ensamblados. para que el mismo proceso de construcción pueda crear diferentes representaciones. define y controla la representación que crea. Aplicabilidad Se utiliza el patrón Builder cuando: . botones. etc. ConcreteBuilder: Construye y ensambla partes del producto mediante la implementación del patrón Builder.

y la forma en que éste se ensambla. Cada ConcreteBuilder contiene el código para crear y ensamblar un tipo de producto en particular. un calendario para agendar las actividades y citas y una lista de tareas a realizar donde se listan a las mismas. etc. de tal forma que pueda registrar información como por ejemplo fechas de inicio y finalización de la misma. o Ejemplo Las PIMs son bases de datos especiales. tal clase no aparece en la interfaz del Builder. luego diferentes Directores pueden usarlos para construir distintos productos desde el mismo conjunto de partes. o 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. Esto brinda mayor control sobre el proceso de construcción y consecuentemente en la estructura interna del producto resultante.2 . por lo que se define un constructor que permite establecer el estado del nuevo objeto Cita. una descripción de la cita. La interfaz permite al Builder ocultar la representación y la estructura interna del producto. las llamadas por realizar y cosas que queden por hacer.Patrón de Diseño Builder Consecuencias Las consecuencias más importantes son: o Permite variar la representación interna de un producto: El objeto Builder provee al director de una interfaz abstracta para construir el producto. El código se escribe una vez. La información es introducida por un usuario cuando se crea la cita. asistentes a la cita. Una PIM incluirá normalmente una libreta de direcciones. un lugar de encuentro. 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. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 55 . Para lograr la gestión de citas pueden definir una clase llamada Cita para la información de cada evento. Solamente cuando se finaliza el producto. Los clientes no necesitan conocer nada de la clase que define la estructura interna del producto.Director Construct() Builder BuildPart() Product for all objects in structure { builder -> BuildPart() } ConcreteBuilder BuildPart() GetResult() Figura 5. Mayor control en el proceso de construcción: El patrón Builder construye el producto paso a paso bajo el estricto control del Director. el director lo recupera del constructor.

Es por ello que se delega la responsabilidad de la creación de citas a una clase especial. Participantes Prototype: Declara una interfaz para clonarse. y puede llamar a los métodos de ConstructorCita que son relevantes para cada tipo de cita.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 . Además. . Si necesita crear subclases de Cita. puede crear otra clase constructor o heredar de la que ya existe. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 56 . algunas pueden tener fecha de inicio y fin.Son necesarios diferentes tipos de información dependiendo del tipo de cita. Aplicabilidad Se utiliza este patrón cuando un sistema debe ser independiente de cómo se crean. ConcretePrototype: Implementa una operación para clonarse. ConstructorCita. lo que simplificará mucho el código de la propia Cita. La clase ConstructorCita contiene métodos para crear las partes de Cita. esa tarea es más fácil que la alternativa de gestionar la inicialización de objetos por medio de constructores. Cliente: Crea un nuevo objeto por medio de una solicitud de clonación al prototype. Prototype El patrón Prototype (Prototipo). el código que utilizan esos objetos solicitará una copia del objeto que necesite. se componen y se representan sus productos. crea objetos nuevos copiándolos. clonando una instancia creada previamente. Entonces. En cualquier caso. una copia significa otra instancia del objeto. la clase ConstructorCita puede asegurar que la información que recibe cuando se crea la cita es válida. Cuando se consideran todas estas opciones la creación de un objeto Cita no es una tarea trivial. ayudando así a que se cumplan las reglas de negocio. además cuando: . Se puede necesitar una lista de asistentes. El único requisito que debe cumplir el objeto es la posibilidad de clonarse.Cuando instancias de una clase pueden tener una de las combinaciones de diferentes estados.Las clases a instanciar son especificadas en tiempo de ejecución .Cuando es necesario la creación de distintas variantes de un objeto. otras una sola fecha.

debido a que el cliente puede agregar o quitar prototipos en tiempo de ejecución. lo cual evita tener toda una jerarquía de clases Creadoras de objetos. Agregar y quitar productos en tiempo de ejecución: El patrón Prototype o Especificar nuevos objetos variando sus valores: En sistemas altamente o 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. Esto es más flexible que la forma en que lo brinda otro patrón de creación. Este patrón cuenta con las siguientes ventajas: o permite que se incorpore una clase producto en el sistema simplemente registrando una instancia de prototipo. o El patrón Prototype presenta la siguiente desventaja: o Cada subclase de Prototype debe ser implementada por la operación Clone. en realidad. Un cliente puede variar su comportamiento delegando responsabilidades al prototipo.3 . 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.Patrón de Diseño Prototype Consecuencias El patrón Prototype oculta las clases producto del cliente.Client Operation() Prototype Clone() p = prototype . clonar un prototipo es similar a instanciar una clase. Este tipo de diseño le permite a los usuarios definir nuevas “clases” sin programar.> Clone() ConcretePrototype 1 Clone() ConcretePrototype 2 Clone() return copy of self return copy of self Figura 5. tarea que puede resultar complicada cuando las clases ya existen y los objetos que estas incluyen no soportan ser copiados o tienen referencias circulares. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 57 . Se define una nueva clase de objetos clonando clases existentes y registrando las instancias como prototipos de objetos cliente. Este patrón puede disminuir el número de clases que necesita el sistema. 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.

haciendo que una clase a la que le fuera imposible utilizar la primer interfase. Aplicabilidad El patrón Adapter se recomienda utilizar cuando: . lo que de otra forma sería incompatible. Client: participa en la formación de objetos para la interfaz Target. Una forma seria crear un nuevo objeto Dirección y luego copiar los valores apropiados del objeto Dirección existente. Es decir. distintos tipos de 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. Adapter El patrón Adapter se aplica para convertir una interfaz de una clase en otra. necesitan ser adaptados. Adaptee (Adaptado): especifica una interfaz existente que define los métodos que Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 58 . Esta solución tiene un problema: viola el principio de encapsulación de la orientación a objetos. el prototipo. Además también dificulta la reutilización de la clase Dirección. 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. Participantes Target : define la interfaz específica del dominio que usa Client. con clases que no necesariamente tienen interfaces compatibles.Es necesario el uso de una clase existente. para trabajar unos con otros y formar estructuras de mayor tamaño. permite que éstas trabajen juntas. 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. 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.Se requiere crear una clase reusable que coopere con clases no relacionadas. es decir. Patrones Estructurales Detallan la manera en que se pueden relacionar. haga uso de ella por medio de la segunda. .Ejemplo Si nos referimos al ejemplo planteado en el patrón de diseño Builder. 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. y su interfaz es distinta a la que se necesita. El código utilizado para realizar la copia realmente pertenece a la clase Dirección.

o Adaptadores Pluggables: Una clase es más reutilizable cuando se minimiza las asunciones que otras clases deben hacer para utilizarla. o Existen otras consideraciones a tener en cuenta en el momento de utilizar el patrón Adapter: o ¿Cuantas veces el Adapter realiza adaptaciones? Varía en la cantidad de trabajo que hace Adapter para adaptar Adaptee a la interfaz Target. permitiendo que dos elementos incompatibles se comuniquen entre sí. Este libro traduce expresiones comunes (mensajes) de un idioma a otro.Patrón de Diseño Adapter Consecuencias El Patrón Adapter presenta las siguientes ventajas y desventajas: o Reutilización de Código: El patrón Adapter ofrece una opción para la reutilización del código. Es decir.4 . Por medio de la construcción de la adaptación de una interfaz en una clase. o encapsula un objeto para que pueda ser utilizado por el Adaptee. desde una simple conversión (cambiar los nombres de las operaciones) hasta soportar un conjunto de operaciones totalmente diferentes. Existe una variedad de tareas que se puede requerir que Adapter lleve a cabo. Transferencia de argumentos: Mediante el objeto Adapter se crean objetos apropiados cuando no hay una correspondencia directa entre el Target y el Adaptee. permitiendo la interacción de dos o más objetos que supuestamente son incompatibles.Adapter(Adaptador): adapta la interfaz de Adaptee a la interfaz Target. Ejemplo Un ejemplo del mundo real en el que podemos aplicar este patrón es en un libro de frases de idiomas extranjeros. al adaptar la interfaz de una clase permite incorporar una clase propia en un sistema existente que puede esperar diferentes interfaces para dicha clase. Client Target Request() Adaptee SpecificRequest() (Implementación ) Adapter Request() SpecificRequest() Figura 5. El trabajo depende de que tan similar o diferentes sean las interfaces de Target con las de Adaptee. se elimina la posibilidad de que otras clases vean la misma interfaz. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 59 .

el patrón Bridge permite combinar diferentes abstracciones e implementaciones y extenderlas en forma independiente. .Las abstracciones y sus implementaciones deben ser extensibles a través de subclases. RefinedAbstraction: extiende la interfaz definida por Abstraction.Se necesita compartir una implementación entre varios objetos. y Abstraction define operaciones de alto nivel basadas en esas primitivas.5 . En este caso. de forma que ambas puedan modificarse de manera independiente sin necesidad de alterar por ello la otra. Participantes: Abstraction: define una interfaz abstracta. Se desea ocultar completamente la implementación de una abstracción a los clientes.Los clientes no deben tener que recompilar el código cuando se lleven a cabo modificaciones en la implementación de una abstracción.Bridge Mediante el patrón Bridge es posible desacoplar una abstracción de su implementación. . Implementor: define la interfaz para la implementación de clases.Se desea evitar una vinculación permanente entre la abstracción y su implementación. y este hecho debe ocultarse a los clientes. Client Abstraction Operation() imp->OperationImp (). Este puede ser el caso en que la implementación debe ser seleccionada o modificada en tiempo de ejecución. Implementor OperationImp() ConcreteImplementorA RefinedAbstraction OperationImp() ConcreteImplementorB OperationImp() Figura 5. ya que por lo general. la interfaz Implementor provee sólo operaciones primitivas. ConcreteImplementor: implementa y define la implementación de la interfaz de Implementor.Patrón de Diseño Bridge Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 60 . Mantiene una referencia a un objeto de tipo Implementor. Esta interfaz no es necesario que corresponda exactamente con la interfaz de Abstraction. Aplicabilidad: Se puede utilizar el patrón Bridge cuando: . .

ya que configurada en tiempo de ejecución. Aplicabilidad Se recomienda utilizar el patrón Composite cuando: . puede ser posibilidad hecho de tiempo de o o Ejemplo Mejora la extensibilidad: se puede extender en forma independiente las jerarquías de Abstraction e Implementor. Participantes Component: Declara la interfaz para objetos en la composición. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 61 . . de esta forma el cliente tratará a todos los objetos en la composición de la estructura uniformemente.Consecuencias o Separa interfaz e implementación: Una implementación de una abstracción no esta permanentemente confinada a una interfase. debido a que como todos ellos poseen una interfaz común los trata de igual manera a todos. Además permite que dichos objetos sean tratados de manera semejante. Implementa comportamientos por defecto para la interfaz común a todas las clases. El desacoplar Abstraction e Implementor hace que se elimine en compilación las dependencias sobre una clase de implementación. Leaf: Representa las hojas en el árbol de la composición. un objeto tiene la de cambiar su implementación en tiempo de ejecución. Además.Es necesario representar la jerarquía completa de objetos. 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. sin hacer distinciones entre ellos. clientes de los detalles de implementación. Define el comportamiento para objetos primitivos.Se necesita que el cliente no note la diferencia entre una composición de objetos y un objeto individual. Declara una interfaz para acceder y administrar sus componentes hijos. Composite: Define el comportamiento para componentes que tienen hijos. Oculta a los clientes los detalles de implementación: Se puede proteger a los Ejemplos de la aplicación de este patrón son los sistemas de interfaz gráfica que deben ser portables entre plataformas. Almacena los componentes hijos. Esto reduce el tratamiento de los objetos creados.

dificulta restringir los componentes de una composición. pero a su vez puede manipular conjuntamente sólo una parte del dibujo.6 . sin hacer distinción si es una figura simple o compuesta Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 62 . Para los clientes es transparente si están tratando con una hoja o un componente compuesto. o Es sencillo agregar componentes nuevos: Nuevos componentes Composite o subclases Leaf trabajan automáticamente con estructuras existentes y códigos de clientes. Ejemplo Un ejemplo clásico de aplicación de este patrón se observa en las aplicaciones gráficas. El patrón Composite presenta las siguientes desventajas: o Puede hacer el diseño demasiado general: Al agregar nuevos componentes de forma fácil. Los Clients no deben ser cambiados por nuevas clases Component.Patrón de Diseño Composite Consecuencias El patrón Composite tiene las siguientes ventajas: o Define jerarquías de clases formada por objetos primitivos. Client Component Operation() Add(Component) Remove(Component) GetChild(int) children Leaf Operation() Composite Operation() Add(Component) Remove(Component) GetChild(int) forall g in children g.Client: opera con objetos en la composición a través de la interfaz Component. donde el usuario puede crear dibujos complejos a partir de dibujos sencillos y básicos (Hojas). especialmente cuando se requiere que una composición tenga solo ciertos componentes. o Clientes más simples: Los clientes pueden tratar en forma uniforme estructuras compuestas y objetos individuales. Los objetos primitivos pueden estar compuestos dentro de objetos complejos los cuales a su vez pueden ser compuestos y así recursivamente.Operation (). Figura 5. Esto simplifica el código del cliente.

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

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

Pag 63

Client

Subject Request() …..

RealSubject Request() ...

Proxy 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:
• •

Proxy Remoto: 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.

objeto. Ejemplo

Proxy de Protección: realiza tareas de control cuando se accede a un

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.

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

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:

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.

ConcreteClass: Es una subclase de AbstractClass e implementa los métodos abstractos
definidos.

AbstractClass templateMethod() subOperation1() subOperation2()
//skeleton code subOperation 1() ; //more skeleton code subOperation 2() ; //even more code

ConcreteClass subOperation1() subOperation2()

Figura 5.8 - Patrón de 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.

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

Pag 65

Ejemplo Los métodos de plantilla se utilizan sobre todo en frameworks para.9 . otorgar flexibilidad a los usuarios del framework permitiendo ejecutar su propio código en determinados puntos. Observer: Define la interfaz para objetos que deben ser notificados. Almacena el estado que debe ser consistente con el del Subject. de manera que cuando uno de los objetos cambia su estado.Una abstracción tiene dos aspectos.Cuando un cambio en un objeto implica cambiar otros y no se conoce de antemano cuantos objetos deben actualizarse . Aplicabilidad: Se puede utilizar el patrón Observer cuando se presentan las siguientes situaciones: . . buscando un bajo acoplamiento. Observer El patrón Observer define una dependencia del tipo uno-a-muchos entre objetos. 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. el observer se encarga de notificar este cambio a todos los otros objetos dependientes. uno dependiente del otro. Subject Attach(Observer) Dettach(Observer) Notify() observers Observer Update() for all o in observers { o->Update() } ConcreteSubject GetState() subjectState subject ConcreteObserver Update() observerState observerStare= subject->GetState() . Participantes: Subject: Proporciona métodos para suscribir y borrar Observers. Implementa la interfaz de actualización para mantener su estado consistente con el del Subject. return subjectState Figura 5. simplemente redefiniendo estos métodos (abstractos en la clase original).Patrón de Diseño Observer Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 66 . Encapsulándolos en objetos separados se permite variarlos y reusarlos de forma independiente. a la vez que se garantiza que las operaciones se ejecutan en el orden correcto. Conoce sus Observers.Cuando un objeto debe ser capaz de hacer notificaciones a otros sin hacer suposiciones de quiénes son.

Para ello se encapsula la petición como un objeto. procesos de identificación y/o transacciones .Independizar el momento de petición del de ejecución . ni el receptor real de la misma. o Soporte para comunicación tipo broadcast: La notificación se extiende a todos los objetos de la lista. Es decir. 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. Se añaden y quitan observadores en cualquier momento. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 67 . especificando que órdenes se necesitan ejecutar en ciertas situaciones bajo otras órdenes. .Consecuencias Ventajas: 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.Dar soporte para deshacer comandos. . Command Este patrón permite solicitar una operación a un objeto sin conocer realmente el contenido de esta operación. un parámetro de una orden puede ser otra orden a ejecutar. Aplicabilidad: Se puede utilizar el patrón Command cuando se necesita: . y dependiendo de cada una de ellas los datos son actualizados de distinta forma y en distintos momentos. Este patrón presenta una forma sencilla y versátil de implementar un sistema basado en comandos facilitando su uso y ampliación. 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. no conoce el costo de enviar un “cambio” al subject. Podría producirse una actualización en cascada.Desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas (primitivas). Desventajas: o Actualizaciones Costosas: Un observer no conoce cuántos observers más existen y por lo tanto.Implementar CallBacks. deshacer operaciones y restaurar el estado a partir de un momento dado.Facilitar la parametrización de las acciones a realizar . El subject no conoce ninguna clase observer concreta. facilitando la parametrización de los métodos. permite gestionar colas o registros de mensajes. Al encapsular un mensaje como un objeto.

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. pueden ser manipulados y extendidos como cualquier otro objeto. un sistema transaccional. deshacer permitiendo llevar un registro de las operaciones que sí pueden volver a ser aplicadas. ConcreteCommand: Define una enlace entre el objeto Receiver y una acción. Los Command son objetos de primera clase. Una clase puede servir como un Receiver. por ejemplo. Implementa Execute() por invocación a la operación correspondiente en el Receiver. 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 . Se facilita la ampliación del conjunto de comandos ya que las clases existentes no cambian State El patrón State permite que un objeto cambie en tiempo de ejecución su comportamiento cuando cambia su estado interno. Independiza el objeto que invoca una operación de un objeto que conoce como implementarla.Patrón de Diseño Command Consecuencias o o o 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. Permite implementar un mecanismo de rehacer. Invoker Client Command Execute() Receiver Action() ConcreteCommand Execute() State receiver->Action().Participantes: Command: Declara una interfaz para la ejecución de una operación.10 . Figura 5. en caso de una caída del sistema.

11 . o Las transiciones de estados son explicitas: Cuando un objeto define su estado actual mediante la asignación de un valor a una variable. Cuando un objeto es un estado específico. Como todos los códigos específicos a un estado conviven en una subclase de State. Introducir objetos Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 69 .Los métodos tienen largas y múltiples sentencias condicionales que dependen del estado del objeto. o 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. .. State: Define una interfaz para encapsular el comportamiento asociado a un estado particular del objeto. El patrón State ubica cada rama del condicional en clases separadas. solo es necesario definir nuevas subclases. ConcreteSate: Cada subclase implementa un comportamiento asociado con un estado Context currentState setCurrentState(State s) State someMethod() ConcreteStateA someMethod() ConcreteStateB someMethod() Figura 5. del objeto. Estos estados generalmente son representados por constantes enumeradas y largas sentencias “switch/case” dentro de los métodos. Participantes: Context: Define la interfaz que utilizan los clientes y mantiene una referencia al estado actual del objeto. agregar nuevos estados se transforma en una tarea muy sencilla. mira en la subclase State correspondiente y todo el posible comportamiento de ese estado se incluye en esa clase.Patrón de Diseño State Consecuencias El uso del patrón State presenta las siguientes ventajas e inconvenientes: o Comportamiento de las particiones de estados basadas en el estado: Esto da una visión más clara del comportamiento. su transición de estado no tiene una representación explícita.El comportamiento de un objeto depende de su estado y este cambia con mucha frecuencia.

permitiendo que el algoritmo varíe independientemente del cliente que haga uso de él. Context ContextInterface() strategy Strategy AlgorithmInterface() ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() ConcreteStrategyC AlgorithmInterface() Figura 5.Se necesiten diferentes variantes de un algoritmo. .separados por diferentes estados hace que la transición se torne más explícita. Un objecto TCPConnection puede estar en uno de los varios estados posibles de la conexión: establecida. facilitando el reconocimiento de un cambio entre estados. puede definir una interfaz para permitir a Strategy acceder a sus datos. Aplicabilidad: Se puede utilizar el patrón Strategy cuando: . cerrada. 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. este responderá de forma diferente dependiendo del estado en que se encuentre. Context: Mantiene una referencia a un objeto Strategy. Cuando un objeto TCPCOnnection recibe solicitudes desde otros objetos. o Utiliza un gran número de clases: Si bien puede verse como una desventaja.12 .Patrón de Diseño Strategy Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 70 . . ConcreteStrategy: Implementa un algoritmo usando la interfaz de Strategy.Un algoritmo use datos que el cliente no tenga por qué conocer. escuchando. Participantes: Strategy: Declara la interfaz común para todos los algoritmos soportados. Se configura con un objeto ConcreteStrategy. Ejemplo Un ejemplo del uso del patrón State es considerar clases TCPConnection que representan el estado de la conexión de una red.Una clase defina varios comportamientos y estos aparezcan en forma condicional en sus operaciones.Se quiera ofrecer la posibilidad de configurar una clase con una gama de comportamientos disponibles. Strategy El patrón Strategy define una familia de algoritmos. . encapsula cada uno y los hace intercambiables.

La herencia puede ayudar a factorizar la funcionalidad común de los algoritmos. A veces una clase requiere de un colaborador pero no necesita que este haga algo. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 71 .cuando necesita abstraer el manejo de objetos nulos fuera del cliente.algunos casos del colaborador que no deben hacer nada.Consecuencias Ventajas 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. . Puede haber parámetros muy costosos de crear y NO usados por estrategias muy simples.un objeto requiere de un colaborador. Puede producirse sobrecarga de comunicación en el paso de parámetros entre Context y Strategy. Aplicabilidad: Se puede utilizar el patrón Null Object cuando: . Elimina las sentencias condicionales. etc. El Objeto Nulo no realiza nada aunque esto no significa que no sea inteligente. diversos algoritmos. 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. Este oculta los detalles de sus colaboradores. . ordenación por burbuja. Incrementan el número de objetos en una aplicación. El patrón Null Object no introduce esta colaboración. quick sort. Sin embargo. merge sort. la clase desea tratar a un colaborador que no hace nada de la misma manera que trata a uno que realmente proporciona conducta. Null Object El patrón Null Object provee un objeto como un substituto por la falta de un objeto de un tipo dado. proveer diferentes implementaciones del mismo o o Desventajas o o o 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. Strategy puede comportamiento. hace uso de una colaboración que ya existe.

Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 72 .13 . Implementa su interfase pero no hace nada. Client uses AbstractObject +request() RealObject +request() NullObject +request() do nothing Figura 5. 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. Siempre que el código del cliente espere un objeto real. Esto simplifica el código del cliente. Pueden usarse los objetos nulos en lugar de los objetos reales cuando se espera que el objeto no haga nada. Hacer el código de “no hacer nada” en el objeto nulo facilita su reuso. Hace el código del cliente simple. 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. porque evita tener que escribir código de comprobación. AbstractObject: declara la interfase para el colaborador de Cliente e implementa la conducta por defecto para la interfase común a todas las clases. Cuando hay más de una manera de no hacer nada. o o Encapsula la tarea de “no hacer nada” en el código del objeto nulo. El significado de “no hacer nada” depende de qué clase de conducta Client esta esperando. Si el “no hacer nada” necesita ser modificado. todos los clientes continuarán usando el mismo comportamiento actualizado de no hacer nada. Luego de esto. también puede tomar un objeto nulo. Los clientes normalmente no saben si ellos están tratando con un colaborador real o uno.Participantes: Client: requiere a un colaborador. el código puede cambiarse en un lugar. Los clientes pueden tratar a los colaboradores reales y los colaboradores nulos uniformemente. puede necesitarse más de una clase NullObject.Patrón de Diseño Null Object Consecuencias Ventajas o Define jerarquías de la clase que consisten en objetos reales y en objetos nulos. ya que se ocupa el colaborador nulo especialmente.

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. Puede ser necesario la creación de una nueva clase NullObject para cada nueva clase AbstractObject.Desventajas o La conducta de no hacer nada hace difícil distribuir o mezclar el comportamiento real de varias colaboraciones de objetos. Sin embargo. y también permite al sistema crear instancias de esas instancias de tipo clase. Simplemente se realiza un NullMovementStrategy que no mueve la pelota y un NullColorStrategy que no cambian el color de la pelota. Aunque un objeto del sistema pueda crear nuevas instancias bajo demanda. si comenzamos por crear las estrategias más simples posiblemente se asegure todo el trabajo. Probablemente los métodos en estas clases no hacen "nada". 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. 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 Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 73 . el patrón Strategy exige a la pelota tener objetos que llevan a cabo las interfaces de estrategia. Type Object Desacopla instancias de sus clases para que estas clases puedan ser implementadas como instancias de una clase. no mueve y ni cambia el color. porque éstas son instancias. Aquí es donde el patrón Null Object es útil. Ése es no hacer nada. El patrón Type Object permite crear las nuevas "clases" dinámicamente en tiempo de ejecución. la estrategia más simple no sería ninguna estrategia. Sin embargo. El Objeto Nulo siempre actúa como un objeto que no hace nada y no se transforma en un Objeto Real. o o o Ejemplo Considere por ejemplo una simple pantalla que despliega pelotas que se mueven sobre la pantalla y tienen efectos de color especiales. usualmente no puede crear nuevas clases sin una recompilación. Ahora. Algunas veces una clase requiere no sólo un número indeterminado de instancias sino también una cantidad desconocida de subclases. 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. 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.

Tiene un TypeObject asociado que describe su tipo. . Representa instancias de TypeClass. tiene una instancia separada para cada tipo de Object. Representa un único ítem que tiene un único contexto. Cada objeto tiene un puntero su tipo correspondiente.Aplicabilidad Se recomienda aplicar el patrón de diseño Type Object cuando: . Object: Es una instancia de Class. Establece todas las propiedades de un Object que son las mismas de todos los Objects del mismo tipo.Se necesita jerarquizar los grupos recursivamente de modo que ese grupo sea a su vez un ítem de otro grupo. Establece todas las propiedades de ése ítem que puede diferir entre ítems del mismo tipo. . Participantes El patrón Type Object tiene dos clases concretas. aTypeClass TypeObject1 TypeClass typeAttribute type Class attribute aTypeClass TypeObject2 aClass Object1B type aClass Object1A type Figura 5. una que representa objetos y otra que representa sus tipos. Class: Es la clase de Object.14 . Representa un tipo de Object.Las instancias de una clase necesitan estar agrupadas para implementar los atributos y/o comportamiento común.Estructura del patrón de diseño Type Object Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 74 . .La clase necesita una subclase por cada grupo para implementar los atributos y/o comportamientos del grupo. . TypeObject: Es una instancia de TypeClass.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. TypeClass: Es la clase de TypeObject. Delega propiedades definidas por su tipo a su TypeObject. .Se necesita poder cambiar una subclase de un objeto después de que se instanció sin tener que mutar a una nueva clase.

en este caso debe ser la aplicación por si misma quien establece y mantiene la relación TypeObject-Object. En vez de un gran número de clases. Implementación compleja: El patrón saca diferentes implementaciones de las subclases y las coloca en diferentes estados de las instancias de TypeObject. 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. Considerando que cada subclase podría implementar un método en forma diferente. es difícil de entender. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 75 . Evita la explosión de subclases: El sistema no necesita un gran número de subclases para representar diferentes tipos de Objects. El cliente realiza solicitudes de Object. De igual manera que un objeto conoce cual es su clase. y el Object decide que requerimiento envía al TypeObject. una cosa y su tipo. dando el mismo efecto que si sufriera un cambio de clase. un Object conoce cual es su TypeObject. Las desventajas de la utilización del patrón TypeObject son: o Diseño complejo: El patrón divide un objeto lógico en dos clases. 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. El Object debe decidir cual tipo de comportamiento delegan a cual TypeObject. o o Oculta la separación de instancias y tipos: Un Object cliente no necesita estar consciente de la separación entre Object y TypeObject. Su relación. Pero considerando que el sistema objeto o lenguaje automáticamente establece y mantiene la relación claseinstancia. el sistema puede usar un TypeClass y varios TypeObjects. Subclases independientes: TypeClass y Class pueden tener sus subclases independientemente. Los clientes que conocen al TypeObject pueden colaborar con ellos directamente sin ir a través de los Objects. Esto es mucho más simple que mutar un objeto a una nueva clase.Consecuencias Las ventajas de un patrón TypeObject son: o Crea clases en tiempo de ejecución: El patrón permite crear nuevas clases dinámicamente. Esta confusión va en decremento de la simplicidad y la mantenibilidad. o o o 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. Es difícil reconocer o explicar la relación entre un TypeObject y un Object. Cambio dinámico de tipo: El patrón permite que el Object cambie dinámicamente su TypeObject. o o Manejador de referencia: Cada objeto debe guardar una referencia a su TypeObject.

Consta de dos clases: una que representa los objetos.Se desea realizar cambios en forma dinámica de forma transparente a los usuarios. sean agrupadas de acuerdo con comunes atributos y/o comportamiento.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. son necesarios los siguientes participantes: de los objetos a los que se les pueden añadir responsabilidades de forma dinámica. Unidad (Class). sin las restricciones propias de la creación de subclases. 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. mantiene una referencia a un objeto Component que puede ser un objeto ConcreteComponent u otro Decorador. 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. referencia.Ejemplo Supongamos que nos interesa modelar unidades de medida. evitando una explosión de numerosas subclases. y otra que representa sus tipos.Sea posible introducir o quitar responsabilidades de los componentes en tiempo de ejecución. Aplicabilidad Es útil hacer uso del patrón Decorator cuando: . Component: Componente que contiene el comportamiento genérico. . en este caso Unidad. . es decir. Define la interfaz Decorador: Puede ser una clase o una interfaz. también proporciona soporte para contener otros decoradores. Participantes Para implementar el patrón Decorador. Define los comportamientos estándar de todos los decoradores. TipoUnidad (TypeClass). ConcreteDecorator: Añade responsabilidades al objeto Component al que hace Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 76 .

Se crea a partir de la clase Ventana la subclase abstracta VentanaDecorator y. un DecoratorComponent no es idéntico al Component. heredando de ella.operation () newAttribute operation() newOperation() Figura 5. 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.Estructura del patrón de diseño Decorador Consecuencias El patrón de diseño Decorador cuenta con las siguientes ventajas: o o Más flexible: Ofrece la oportunidad de ajustar y aumentar fácilmente el comportamiento de un objeto en tiempo de ejecución. VentanaDecorator Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 77 . Por esto no se puede confiar en la identidad de los objetos cuando se usan Decorators. El patrón Decorator ayuda a resolver esta situación de una manera sencilla y extensible. BordeDecorator y BotonDeAyudaDecorator. pequeños que son muy parecidos. Hay que tener en cuenta también las siguientes desventajas: o Un Decorator y su Component no son idénticos: Desde el punto de vista de la identidad de los objetos. o Ejemplo Propagación de objetos: El patrón Decorator hace que haya muchos objetos Supongamos que tenemos una clase existente Ventana y queremos añadirle funcionalidad para que muestre un borde alrededor. o Nuevas responsabilidades: Permite que la adición de nuevas responsabilidades (nuevas clases de Decorators) independiente de las clases los Objetos que ellas extienden.15 . 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. habría que programar todos los comportamientos en el propio componente.Component operation() ConcreteComponent operation() Decorator setComponent(Component c) operation() ConcreteDecorator component. En otro caso.

Podemos crear tantos Decorators como queramos heredando de VentanaDecorator. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 78 .encapsula el comportamiento de Ventana y utiliza composición recursiva para que sea posible añadir tantas "capas" de Decorators como se desee.

Participantes Externos al sistema . generando los archivos conteniendo el detalle de las operaciones para su posterior envío. • Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 79 . quedando estos en poder de las Entidades Depositarias independientemente de su lugar de captación y su domicilio de pago. eliminándose en todo el país el traslado físico de los mismos. debita el importe a sus clientes libradores y abona a la Entidad Depositaria. Este sistema permite la captura descentralizada de cheques de cualquier importe. Participantes Los distintos participantes en el sistema son los que a continuación se detallan: Participantes Internos al sistema: . Transmitiéndose los registros electrónicos y las imágenes de los cheques superiores a un importe determinado. 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.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. .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. la generación de los registros electrónicos y sus respectivas imágenes (digitalización). y previa verificación de la misma.Entidad Girada: Es quien recibe la información electrónica de los cheques.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. 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.

1 .Esquema a gran escala Esquema solución dentro de cada Entidad: Entidad Depositaria / Girada Suc 1 Sistema de Escaneo de Cheques CASA MATRIZ 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 Cámara Compensadora Sistema de Escaneo de Cheques Server de la Sucursal Servidor Central 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 . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 80 .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 3 Suc 4 Suc 2 Suc 3 Suc 4 Suc 1 Suc 1 Entidad Depositaria / Girada Camara Compensadora Entidad Depositaria / Girada Figura 6.Esquema dentro de cada una de las entidades.

Cheques Recibidos: Se recepciona y procesa un archivo conteniendo los registros electrónicos de cheques procedentes de otros bancos para su cobro. importe y fecha. sucursal.Cheques: Corresponde a la generación de un archivo conteniendo los registros electrónicos de los cheques. . . En el circuito de cheques enviados.Rechazos de Cheques: Luego de imputar los cheques recibidos. correspondiente a cada ítem de cada uno de los circuitos. . es decir que no se pagan por diversos motivos (Ej: Sin fondo. código postal. Se entiende por registro electrónico al conjunto de datos que definen a un cheque . Estos rechazos corresponden a cheques enviados por la Entidad Depositaria anteriormente. etc.Rechazos de Cheques: Se recepciona y procesa un archivo con los registros electrónicos de los cheques rechazados por la Entidad Girada. 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 a la recepción de archivos se identifican tres sesiones.).banco.Imágenes: Se recepciona y procesa un archivo con todas las imágenes de los cheques que han sido capturados en otros bancos. 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. . . Falla Técnica. Respecto al envío de archivos se identifican tres sesiones. número de cuenta.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. los cheques son escaneados en las sucursales. se genera un archivo conteniendo aquellos cheques que se necesitan rechazar. En el circuito de cheques recibidos. capturados en otros bancos el día anterior. denominando sesión al proceso de envío o recepción de archivos desde/hacia la Cámara Compensadora. 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. número de cheque. Cuenta Inexistente. .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. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 81 .

Presentación de Cheques Recepción de Rechazos

Recepción de Cheques Rechazo de Cheques Recepción de Imagenes Entidad Depositaria

Entidad Girada

Presentación de Imágenes

Camara Compensadora

Figura 6.3 - Esquema dentro de cada una de las 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, 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.

Entidad Girada

Presentación de Rechazos Recepción de Rechazos Recepción de Imagenes Rechazo de Imagenes

Recepción de Rechazos Rechazo de Rechazo Presentación de Imágenes 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

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. - Imágenes por reclamo: Se genera un correspondientes a los reclamos recibidos. archivo con todas las imágenes

- 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

Presentación de Reclamos Recepción de Rechazos Recepción de Imagenes Rechazo de Imagenes

Recepción de Reclamos Rechazo de Reclamos Presentación de Imágenes 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.

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

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

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

Pag 84

eliminándose en todo el país el traslado físico de los mismos. 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. 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. Se presenta el análisis y diseño realizado para nuestro trabajo.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. Análisis En la presente sección se describirá el análisis del sistema. las cuales. Como se mencionara en el capítulo anterior. este sistema permite la captura descentralizada de cheques de cualquier importe. que permitan modelar el sistema anteriormente descripto de modo que resulte una aplicación extensible. 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. quien separa y distribuye los archivos a las Entidades Giradas. describiendo especialmente los patrones utilizados y las razones de su selección. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 85 . Esta etapa comienza con el estudio del proceso de gestión de cobro de cheques en el sistema bancario.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. La figura 7. La Entidad Depositaria presenta cheques para su posterior cobro a la Entidad Girada donde se ha librado el valor. quedando estos en poder de las Entidades Depositarias independientemente de su lugar de captación y su domicilio de pago. fácil de modificar. mantener y reusar.

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. cambiando su estado a lo largo del mismo. en forma Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 86 .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.Entidad Depositaria Entidad Girada Deposito por Caja Registración del Cheque Si Si es Cheque propio Pago o Rechazo según saldo suficiente No 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) No Cheque rechazado? 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? Si Aceptación de imagen SI Marcar rechazo de reclamo Procesar rechazo de imágenes por rechazo Generar rechazo de imágenes por rechazo Figura 7.1 . De esta forma el cheque entra en el circuito para gestionar su cobro.

el cual es enviado a la Entidad Depositaria. la sucursal marcará dicha imagen como rechazada. imagen ilegible. Una vez que las imágenes se encuentran en la sucursal.Código de rechazo que no genera imagen: Concluye el circuito de cheques rechazados.Rechazado: La Entidad Girada genera un archivo conteniendo todos los cheques que desea informar como rechazados. impactando un movimiento de débito y un movimiento de crédito.En caso de tener algún problema de visualización. 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.centralizada se genera Girada. por ejemplo. En caso de: . se realiza el chequeo visual de las mismas. monetaria. donde debe chequear si corresponden a imágenes de cheques rechazados: .Código de rechazo que si genera imagen: Se buscan las imágenes correspondientes a los cheques que se han rechazado. Una vez obtenidos todos los rechazos. . Como proceso. .Si corresponden a cheques rechazados se envía a la sucursal para su chequeo visual. y lo envía a la Entidad Depositaria. ya sea en forma automática o porque una sucursal la marcó. mostrando de esta manera el ingreso de los cheques al circuito y su posterior rechazo. . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 87 . se plantean dos situaciones. La tarea posterior a la imputación monetaria de los cheques rechazados es analizar su código de rechazo asociado. con sus respectivos códigos de rechazo.En caso de poder contar con la imagen sin problemas de visualización se acepta la imagen dando por concluido el circuito de rechazos.Aceptado: en este caso. se genera un archivo y se envía a la Entidad Girada. efectuando consecuencia de este rechazado o aceptado: el archivo conteniendo todos los cheques a enviar a la Entidad se recepciona. se genera el archivo de rechazo de imágenes por rechazo. . el cheque puede ser . La Entidad Depositaria al recibir los cheques rechazados debe reflejar estos en las respectivas cuentas de los clientes depositantes. 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. se procesa el archivo y se realiza su imputación los débitos en las cuentas corrientes correspondientes. . se genera en forma automática el rechazo de la imagen. Concluyendo de esta manera con el circuito de digitalización de cheques. cheque mal escaneado.Si no corresponden a cheques rechazados. etc. Una vez aquí.

2 .Circuito de Reclamos de Cheques Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 88 .2 se muestra dicho circuito. En la siguiente figura 7.La Entidad Girada recibe y procesa dicho archivo. Como consecuencia de ellos existe a disposición de esta entidad la posibilidad de efectuar reclamos sobre los cheques que ha recibido. 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. De esta manera se concluye con el circuito de imágenes por rechazo. Entidad Depositaria Entidad Girada Realizar reclamo en sucursal Recepción y procesamiento de archivo de reclamos Generar archivo de reclamo Verificación de reclamos Si Cheque enviado ? No Buscar imagen correspondiente al cheque reclamado Generar rechazo de reclamo Recibir rechazo de reclamos Generar archivo con imagen Recibir archivo con imágenes por cheques reclamados 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.

se marca dicha imagen como rechazada. cheque mal escaneado.Si corresponden a cheques reclamados se envía a la sucursal para su verificación visual. se genera el archivo de rechazo de imágenes por reclamo. Comienza en las sucursales quienes son las encargadas de realizar los reclamos.La posibilidad de efectuar reclamos se puede realizar sobre cualquier tipo de cheque recibido.Si el reclamo no 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. luego en forma centralizada se genera un archivo y se envían a la Entidad Depositaria. . se genera en forma automática el rechazo de la imagen. se realiza la verificación de las mismas. ya sea en forma automática o porque una sucursal la marcó. 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. concluyendo con el circuito de imágenes por reclamo.Si no corresponden a cheques reclamados. Al recibir el archivo la Entidad Girada.Si se puede visualizar correctamente. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 89 . La Entidad Girada cuando recibe el archivo con imágenes por reclamo efectúa la recepción y procesamiento del mismo. se acepta la imagen y se da por finalizado el circuito de reclamos. . Una vez en la sucursal. donde chequea si corresponde a los reclamos efectuados: . . el que es enviado a la Entidad Depositaria. . La Entidad Depositaria recibe y procesa dichos rechazos. 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. 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: . Modelo de casos de uso Con la información obtenida a partir de las circuitos descriptos de escaneo de cheques. como por ejemplo imagen ilegible.Si el reclamo corresponde a un cheque enviado. se marca en forma automática el reclamo con un nuevo código de rechazo.Si tiene errores al visualizarse. tanto aceptado como rechazado. se genera un archivo conteniendo los rechazos de imágenes por reclamo y se envía a la Entidad Girada. lo procesa y da por concluido el circuito de reclamos. Una vez que se marcan todos los rechazos. La Entidad Girada es la única que puede realizar reclamos respecto de los cheques que ha recibido. etc.

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) . 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. envío de imágenes por reclamo/rechazo.Verificación si corresponde a un cheque propio o un cheque de otra sucursal u otro banco. 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. Para que un usuario pueda acceder al sistema deberá identificarse previamente.Cheques Enviados con visualización de su imagen. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 90 . enviado. . .Verificación y validación de números de cuentas depositarias en el momento del depósito del cheque. una vez autenticado podrá tener acceso a la información (registro electrónico y/o imagen) e ingresar nuevos cheques. recepción de imágenes por reclamo/rechazo).Consultar la historia de un cheque (recibido. Apertura y cierre de operaciones: .Desplegar la información existente en la base de datos.Realizar la apertura del día en la Sucursal: Se reciben archivos del sistema centralizador: • • • Cheques Presentados Cheques rechazados recibidos Reclamos recibidos . el sistema estará compuesto por los siguientes grupos de casos de uso: Validación: .Listados de Cheques ingresados al sistema.En los procesos se identifican dos actores: Usuario y Sistema Centralizador. .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.Cheques Recibidos con visualización de su imagen. . rechazado. . . Con estas funcionalidades definidas. aceptado.

Generar Rechazos de Imágenes recibidas por Reclamos .ABM de Reclamos . 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.Generar Rechazos de Imágenes recibidas por Rechazos Sistema de Escaneo de Cheques 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. En este proceso la imagen capturada del cheque se asocia al registro electrónico del mismo definiendo en él.3 . path y nombre del archivo físico de la imagen. caso contrario.Depósito de cheques: (Utilizado por el usuario): . Administración de datos: tener a disposición ABM que permitan .Diagrama de casos de uso Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 91 .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. 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 caso de se un cheque propio el mismo se registra y es pagado o no por caja.

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. La lógica de una interfaz de usuario cambia con más frecuencia que los almacenamientos de datos y la lógica de negocio. El sistema en estudio tiene el comportamiento de un sistema Distribuido e Interactivo como ya lo mencionamos.Patrón Broker: Soporta la distribución y la integración de componentes. sin alterar el comportamiento del modelo.Patrón Model-View-Controller: Interacción usuario-computadora. Cproxy Broker Sproxy Cliente Servidor Figura 7.Patrón Broker Para el diseño de aplicaciones con interfaces gráficas se utiliza el patrón Model-ViewController. . con la finalidad de mejorar la reusabilidad. ser flexible y extensible y representar las relaciones de control entre las partes. Los cuales se ajustan a los siguientes patrones arquitectónicos: . De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o los datos. Por lo cual. Vista Modelo Controlador Figura 7. que mezcle los componentes de interfaz y de negocio. Nos interesa que la aplicación que usa un objeto lo haga a través de la interfaz ofrecida por ese objeto.4 . lo que implica un mayor riesgo de cometer errores. manteniéndolas actualizadas ante cualquier cambio del estado del modelo y poder incorporar nuevos controladores si fuera necesario. Si se realiza un gran diseño. se realiza un diseño que desacople la vista del modelo.5 . cuando se necesite cambiar la interfaz. 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. Nos interesa poder mantener múltiples vistas de un mismo modelo.Patrón Broker Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 92 . se deberá realizar un arduo trabajo para poder modificar los componentes de negocio.

Patrón Layers Una vez identificados los patrones a utilizar los integramos de la siguiente manera: Broker Layer Capa N Cproxy Capa N . Model-View-Controller y Layers La distribución es preferente.Integración del patrón Broker. por lo cual.1 Sproxy Cliente Vista Controlador Capa 0 Servidor Modelo Figura 7..7 . con componentes independientes que cooperan entre sí. . en grupos o subtareas. Al partir la funcionalidad en componentes independientes. lo cual conlleva a mayor flexibilidad y facilidad en el mantenimiento y futuros cambios. Lo que se intenta resolver es el problema de construir un sistema de software complejo como un conjunto de componentes desacoplados que interoperan. .Los detalles de comunicación quedan dentro del proxy cliente y del proxy servidor. Por lo tanto: . de reemplazado por implementaciones Capa N-1 Capa 0 Figura 7. en lugar de una aplicación monolítica. implementamos un proxy para el cliente y otro proxy para el servidor. lo referente a comunicaciones y a acceso a la en las cuales cada grupo de subtareas tiene modo que un componente pueda ser alternativas sin afectar al resto del sistema. el sistema se vuelve potencialmente escalable y distribuido. un nivel de abstracción particular. y posiblemente heterogéneo.Creamos un objeto que actué de broker al sistema remoto.Creamos una interfaz para definir el comportamiento remoto del sistema.Luego. . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 93 . Broker es el primer patrón a aplicar ya que el ambiente es el de un sistema distribuido. Capa N Nos interesa poder descomponer todo base de datos.Patrón Layers: Independencia de plataforma.6 .

el usuario invoca un método de un objeto servidor remoto solicitándole la fecha del día.Diagrama de clases del patrón Broker Si aplicamos a nuestro caso de estudio cada componente del patrón los mismos.Distribución de los componentes del patrón Broker. El proxy cliente empaqueta los datos y reenvía la solicitud al broker. 4. respetando la siguiente estructura: Proxy del lado del Cliente empaquetarDatos desempaquetarDatos enviarSolicitudes regresarResultados transfiere mensajes Broker cicloPrincipal registrarServicio encontrarServidor encontrarCliente enviarSolicitud enviarRespuesta transfiere mensajes Proxy del lado del Servidor empaquetarDatos desempaquetarDatos llamarServicios enviarResultados llama llama Cliente llamarServidor inicializarTarea utilizarAPIBroker Servidor inicializarse ejecutarCicloPrincipal ejecutarServicio utilizarAPIBroker Figura 7. el broker envía el mensaje al proxy servidor correspondiente. La aplicación usuario solicita proxy cliente la fecha del día para realizar la apertura. en este caso al Host Central.8 . El broker localiza el servidor al cual se esta realizando la petición. Puesto que el servidor esta disponible localmente. Durante la ejecución del programa. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 94 .Para el cliente es transparente la forma de comunicación entre los componentes. Se inicia la aplicación usuario. En este diagrama se ve el caso en que el usuario realiza la apertura del día: 1. 2. Ahora veremos un diagrama de secuencia que representa la interacción entre los componentes del sistema. 3.9 . estarían ubicados de la siguiente forma en el esquema: Entidad Depositaria / Girada CLIENTE (A) PROXY DEL LADO DEL CLIENTE (A) BROKER PROXY DEL LADO DEL SERVIDOR Suc 1 CASA MATRIZ SERVIDOR Sistema de Escaneo de Cheques Server de la Sucursal Sistema Centralizador Host_Central Servidor Central CLIENTE (B) SERVIDOR PROXY DEL LADO DEL CLIENTE (B) Figura 7.

el servidor regresa el resultado al proxy servidor. El proxy servidor desempaqueta todos los parámetros e información relevante. Si bien existen dos patrones arquitectónicos Model-View-Controller (MVC) y Presentation-Abstraction-Control (PAC) que son aplicables a sistemas interactivos. Cliente Proxy del Cliente Llamar servidor Envia Solicitud De apertura de dia Broker Proxy del Servidor Servidor 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 resultados Figura 7. y lo pasa al broker. hemos optado por el MVC. 8. El proxy cliente recibe la respuesta. Después que la ejecución del servicio se completa. El broker envía la respuesta al proxy cliente. El proceso cliente continúa con sus operaciones. 6. 7. el cual lo empaqueta en un mensaje con información relevante. desempaqueta el resultado y lo regresa a la aplicación usuario. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 95 .10 . según la clasificación realizada por [Buschmann+96] y descripta anteriormente en este trabajo.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.5. Obteniendo de esta manera la fecha del día. e invoca el servicio apropiado.

El componente control es similar a lo que seria el componente control en la arquitectura MVC. Como se ha visto los elementos de este patrón son: .Analizando los patrones. En el diseño de nuestro caso de estudio finalmente se optó utilizar el patrón MVC por las siguientes razones: . El componente presentación es exactamente igual que el componente vista en el patrón MVC. El componente abstracción contiene los datos al igual que el componente modelo en el patrón MVC.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 embargo. sin el detalle de cada uno de ellos). por lo cual no fue el patrón elegido para el caso de estudio propuesto. Los servidores contienen los diferentes componentes del modelo y los clientes los componentes vista y controlador. él puede contener solo parte de la estructura de datos de la aplicación.Modelo: datos y reglas de negocio. y no juega un papel activo en la notificación de los cambios. abstracción y control. además agrega innecesariamente una mayor complejidad en el diseño. provocando que el sistema quede dividido en múltiples componentes presentación.Vista: muestra la información del modelo al usuario. observamos que cada agente PAC consiste de los componentes presentación.Controlador: gestiona las entradas del usuario. Este procesa los eventos externos y actualiza los componentes abstracción y presentación. Cabe destacar que estos tres componentes forman cada uno de los agentes PAC.El sistema tiene la funcionalidad central que no está distribuida sino se ubica en un único centro . los cuales a su vez forman una estructura jerárquica en forma de árbol de agentes cooperando. Es diferente del componente control del patrón MVC en que pasa las actualizaciones realizadas a su agente PAC padre. . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 96 . abstracción y control manteniendo una analogía parcial con el patrón MVC. La siguiente figura muestra la conectividad de cada uno de los componentes y las tareas que lleva a cabo cada uno de ellos. Cada agente es responsable de un aspecto especifico de la funcionalidad de la aplicación.

por parte de los objetos de la vista. es decir. interpreta el evento y activa el procedimiento de validación y verificación de clave y contraseña en el modelo. como dijimos ingresando la clave y contraseña.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) Controlador (A) Modelo Suc 1 CASA MATRIZ Host_Central Sistema de Escaneo de Cheques Server de la Sucursal Sistema Centralizador Servidor Central Vista (B) Controlador (B) Figura 7. El controlador gestiona el evento que llega a través de un manejador de eventos. El usuario interactúa con la interfaz de usuario (vista) de alguna forma. 2.Observador Llamar actualizar actualizar() Modelo Datos SeteoDeObservers conectar(Observador) desconectar(Observador) notificar() conseguirDatos Servicio() Vista Conectar MiModelo conserguirDatos MiControlador inicializar (Modelo) hacerControlador() crear activar () mostrar() Controlador MiModelo Manipular MiVista display inicializar (Modelo. actualizándolo con la acción solicitada por el usuario. la notificación de acción solicitada por el usuario.12 . 3. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 97 . Vista) conectar manejarEventos() llamada a servicios Figura 7. El controlador accede al modelo.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. El controlador recibe. 1.

El modelo realiza el servicio requerido. El controlador original recobra el control y retorna desde su procedimiento manejador de eventos. El modelo notifica del cambio a todas las vistas y controladores registrados con el mecanismo de propagación de cambios. 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 . 8. Cada vista solicita a su controlador los datos modificados del modelo y los refleja en pantalla. Controlador Manejador de eventos Modelo Vista servicio notifica actualiza display Toma_datos actualiza Toma datos Figura 7.4. llamando a sus procedimientos de actualización. 7. 6.Diagrama de secuencia para la conexión de un usuario al sistema.13 . como por ejemplo el perfil del usuario que se ha conectado. Esto produce un cambio en sus datos 5. por ejemplo mostrando el nombre del usuario que se ha conectado. La interfaz de usuario espera nuevas interacciones del usuario. comenzando con el ciclo nuevamente. internos. 9. Cada controlador registrado recupera los datos del modelo para activar o desactivar ciertas funciones del usuario. Esta necesidad de comunicación nos lleva a estructurar dichos componentes en capas mediante la utilización del patrón Layers. 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.

Integración del patrón Broker. También aplicamos el patrón Layers para desarrollar la tarea de acceso a datos en el servidor. En ambos caso hacemos uso de software ya existente.O Cproxy Comunicaciones Sproxy Cliente Vista Controlador Servidor Modelo Figura 7. encarga de transportar los mensajes que intercambian los distintos componentes. La integración final de todos los patrones sería: Broker Layer S. esta estratificado en capas por lo cual es una aplicación más del patrón Layers. Capa Sistema Operativo: Es la capa de software que permite gestionar los mecanismos de comunicación. El sistema operativo a utilizar en nuestro caso de estudio será alguna de las diferentes plataformas existentes. que a su vez. como ya sabemos. independizar el servicio de su implantación y de los protocolos de comunicaciones. El protocolo de comunicaciones que utilizamos es TCP/IP.sistema operativo. esto permite una mejor organización. además. Separando dos capas independientes. se Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 99 . Se identifican las capas: Capa de Comunicación: En esta capa se encuentra el protocolo de comunicación. permite la convivencia de distintos servicios en un mismo sistema y la transparencia del mismo. Model-View-Controller y Layers.14 . que realice las tareas propias del Sistema Operativo. una capa de nivel más bajo que realice las tareas específicas de comunicación y otra capa ubicada sobre la anterior. 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.

la aplicación necesita disponer de un modo de organizar las tareas y almacenar el estado hasta que el proceso se haya completado. Se realiza la implementación de las consultas y operaciones de datos como procedimientos almacenados para mejorar el rendimiento y la facilidad de mantenimiento. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 100 . actualizar y recuperar datos.Estructura de Capa de Servicio. Esta capa es fundamental para que los cambios de base de datos no afecten a la aplicación en general.Capa de Servicio Capa de Acceso a Datos Procedimiento Almacenado Tablas y Vistas Figura 7.15 . que coordina la conversación con los llamadores del servicio. En la capa de servicio cada tarea dentro de esta capa se puede encapsular en un método de un componente. El Componente Modelo Una vez planteado el modelo arquitectónico de nuestro caso de estudio. Los componentes de acceso a datos exponen métodos para insertar. 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. Recibe las solicitudes de la capa de servicio y las convierte en solicitudes a la base de datos específica. Para los procesos más complejos que requieren varios pasos y transacciones de ejecución larga.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. 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. el próximo paso a seguir es el desarrollo del diseño del componente modelo del patrón ModelView-Controller aplicado anteriormente. De acuerdo a nuestro análisis previo. . eliminar. Capa de acceso a datos. Capa de Acceso a Datos y Base de Datos. esta capa se encarga de administrar el almacenamiento y obtener el acceso a los datos. el modelo se conforma por tres componentes que interactúan entre sí. Además.

18 . . Sucursal Banco … apertura () generarArchEnvio () generarArchImgRech() generarArchRechazo () cierre() .. gestión de cobro y rechazo de cheques. tipo de moneda y tipo de cuenta. Entre otras cosas.. Figura 7. responsable de la apertura y cierre de operaciones.16 .Recepción de Cheques es el encargado de la recepción y procesamiento de los cheques recibidos. TipoMoneda TipoCuenta Figura 7.17 .Componentes del Modelo Las principales entidades que intervienen en cada subcomponente del modelo son: Sucursal: Representa a una sucursal bancaria. Posee uno o más titulares que son Clientes del Banco. Cliente Cuenta numero extraer() depositar() saldo() puedoDebitar () debitar() acreditar() existeCuenta() Sucursal … apertura () generarArchEnvio () generarArchImgRech () generarArchRechazo () cierre() .. MODELO Deposito de Cheques Solicita imagen Reclamos de Cheques Solicita imagen Recepción de Cheques Figura 7. así como también el la recepción y gestión de imágenes a enviar..Clase Sucursal Cuenta: Representa una cuenta bancaria de una sucursal de banco. donde se recibe y se envía archivos desde y hacia el Sistema Centralizador.. es responsable de procesar depósitos y extracciones.Reclamos de Cheques efectúa la carga y procesamientos del envío de reclamos.Clase Cuenta Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 101 .

20 . y se requiere que dinámicamente sea considerado como cheque depositado. su cobro debe ser gestionado en otro banco. el cheque existe como entidad.Clase ChequeOtraSucursal. y es responsable de generar el registro con su información para enviar al sistema centralizador. Por otro lado. Cuenta Cheque numero importe() fechaEmision() puedeDebitar () debitar() miCuenta numero extraer() depositar() saldo() puedoDebitar () debitar() acreditar() existeCuenta() Figura 7. cada una de estas subclases debiera admitir la posibilidad de depositarse en otra sucursal. aplicamos el patrón Decorator. Cuenta numero extraer() depositar() saldo() puedoDebitar () debitar () acreditar() existeCuenta() miCuenta cuentaDeposito Cheque numero importe() fechaEmision() puedeDebitar () debitar() miCheque ChequeOtraSucursal … generarRegistro () procesarRechazo() asociarImagen() … Figura 7. Si Cheque tuviera ya otras subclasificaciones como por ejemplo Cheque Diferido. tiene un importe y una fecha.Clase Cheque Cuando un cheque es depositado en una cuenta. 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. siendo la composición la mejor manera. puede ser que corresponda a la misma sucursal o no. ya que estos cheques tienen un tratamiento especial. podríamos pensar en subclasificar a Cheque e incorporar el nuevo comportamiento. Es responsable de saber si puede debitarse en la cuenta a la que pertenece y de hacerlo si se lo solicita. conoce la cuenta en la que se depositó. Para modelar el cheque depositado en otra sucursal. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 102 . Este segundo caso es el que nos interesa en particular. Por ello.19 .Cheque: Representa a un cheque de una cuenta bancaria. procesar el depósito o el rechazo según lo que ocurra. la subclasificación no es la forma más adecuada de representarlo. Además de la información propia del cheque.

Al efectuar el depósito de un cheque por caja. dólares. 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. Todos Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 103 . Si bien aplicamos el patrón Decorator. el cual debe contar con los siguientes datos: tipo de cuenta (cuenta corriente. Cuenta numero ChequeOtraSucursal … generarRegistro () procesarRechazo () asociarImagen () … importe() ^miCheque. tipo de moneda (pesos. El depósito se realiza en la cuenta del cliente depositante. Caso contrario será un cheque depositado.).Cheque Cuenta numero …. caja de ahorros. pero no son depositados en una cuenta. Considerando a cheques normales aquellos cheques que son presentados en caja para su cobro. La separación de estas clases se debe a que cada una de ellas tiene un comportamiento particular. etc. En nuestro caso solo nos centraremos en el comportamiento de los cheques depositados.importe() Figura 7. sucursal y número. miCuenta numero importe() fechaEmision() puedeDebitar () debitar () ChequeNormal numero ChequeDepositado numero acreditar() importe() fechaEmision() puedeDebitar () debitar() cuentaDeposito … . 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. etc. euros..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. Depósito de Cheques Aquí se modelizan los procedimientos del depósito de un cheque. se cargan todos los datos referentes a la boleta y al cheque. Así como también la apertura y recepción de los rechazos correspondientes a cheques depositados y enviados el día anterior.. en los diagramas subsiguientes utilizamos la interfaz cheque sin representar sus subclases para dar mayor simplicidad al esquema del modelo.).21 .

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

. su imputación monetaria y generación de rechazos. 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. entonces se debita su importe del saldo de la cuenta. se mantiene en estado Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 105 .22 - 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. chequeOtraSucursal Banco TipoMoneda sucursal:: apertura () RecepcionProcesamientoChequesRechazados() RecepcionProcesamientoChequesPresentados() RecepcionProcesamientoChequesReclamados() RecepcionProcesamientoChequesRechazados() Por cada cheque rechazado Buscar Registro electrónico en ChequeOtraSucursal Si lo encuentra ChequeOtraSucursal .. En caso de ser rechazado con el requerimiento de imagen. Si el cheque puede debitares. tomando en este momento el estado aceptado.Deposito de Cheques Sucursal Cliente Cuenta numero extraer() depositar() saldo() puedoDebitar () debitar () acreditar() existeCuenta() numero … apertura() cierre() generarArchEnvio () generarArchImgRech() . Todos los cheques recibidos se encuentran en estado recibido y luego comienza el procesamiento para generar su imputación monetaria en las cuentas. pasando luego definitivamente a estado rechazado. rechazadoConCodigo hasta que se reciba la imagen correspondiente. 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. 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.procesarRechazo() sino excepcion cheque no encontrado finsi TipoCuenta miCuenta Cheque numero cuentaDeposito ChequeOtraSucursal Estado importe() estado fechaEmision() puedeDebitar () debitar () … generarRegistro () miCheque procesar() asociarImagen() … Imagen CodigoRechazo Estado Fecha Depositado EnEspera Rechazado Aceptado Figura 7.

Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Una vez recepcionado el archivo de rechazos el cheque adoptará el estado aceptado o Pag 106 .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. permitiendo la incorporación de nuevos estados sin afectar lo ya desarrollado. 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. chequeOtraSucursal TipoMoneda TipoCuenta cuentaDeposito ChequeOtraSucursal … generarRechazo () procesarRegistro() asociarImagen() … Sucursal:: apertura () RecepcionProcesamientoChequesPresentados () Por cada cheque presentado a debitar Si cheque .. 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. cuyo propósito permite cambiar fácilmente el comportamiento de un objeto en tiempo de ejecución.23 . Un cheque que ha sido depositado por caja y digitalizado.. Los objetos son estados. rechazado según tenga un código de rechazo asociado o no.. debitar () sino generarRechazo ( cheque) finsi fin miCuenta Cheque Estado estado numero importe() fechaEmision() puedeDebitar () debitar() miCheque Imagen Cheque:: debitar () miCuenta. permanecerá en estado depositado. Al utilizar el patrón State ponemos todo el comportamiento asociado a un estado en un objeto.Recepción Cheques Banco Cliente Cuenta numero extraer() depositar() saldo() puedoDebitar () debitar() acreditar() existeCuenta() Sucursal numero .puedeDebitarse () ent cheque . apertura () generarArchRechazo () cierre () . que se mantienen a través de los atributos y el comportamiento que se define en los métodos. evitando el uso de switch monolíticos para los diversos casos así como también la replicación de código. 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. En nuestro caso de estudio vemos que el objeto ChequeOtraSucursal cambia su comportamiento de acuerdo al estado en que se encuentra.debitar (this.importe()) CodigoRechazo Estado Fecha Recibido RechazadoConCodigo Rechazado Aceptado Figura 7..

finalizando de esta manera con el circuito de reclamos.El comportamiento del cheque en la Recepción de Cheques. rechazado o rechazadoConCodigo dependiendo de la situación. Al inicio del día. se encuentra en estado recibido. Reclamos Enviados Cuando la sucursal hace un reclamo. Si no corresponde. 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. como ya dijimos este corresponde a un cheque anteriormente recibido. Al ser recibido.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. Reclamos Recibidos Por cada reclamo recibido se busca el cheque correspondiente a ese reclamo. CodigoRechazo ChequeOtraSucursal Estado … setEstado() procesarRegistro() … procesar() Fecha Recibido procesar() RechazadoConCodigo procesar() Rechazado procesar() Aceptado procesar () Figura 7. Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 107 . también tendrá cambios de estados. Un esquema de aplicación del patrón State para representar los cambios de estados de los cheques se muestra a continuación.24 . que luego de ser imputado cambiará a estado aceptado. En ambos casos al realizar el cierre de operaciones se envían los archivos al Sistema Centralizador para su gestión. Si corresponde a un cheque digitalizado en esta sucursal se ubica su imagen y se asocia al registro electrónico. se genera el rechazo del reclamo. 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.

Mientras la vista en las sucursales muestra información con un alto nivel de detalle (cheque por cheque). Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 108 . estado consultando.Una forma de representar este componente seria agregando un nuevo estado al cheque. cada una con su correspondiente controlador. En nuestro caso de estudio contaremos con vistas ubicadas en cada una de las sucursales y otras en el Sistema Centralizador. enviados. Los Componentes Vista y Controlador Tanto la vista como el controlador dependen del componente modelo lo cual no sucede en forma inversa. 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. La vista maneja la visualización de la información del modelo al usuario. Esta separación permite construir y probar el componente modelo independientemente de la representación visual. Una vez finalizada esta notificación vuelve a tomar el control el controlador. el objeto de datos notifica este cambio a todos los observers restantes.) El controlador interpreta las acciones del usuario informando al modelo y a la vista para que cambien según resulte apropiado. rechazados y reclamados de todas las sucursales. La vista en el Sistema Centralizador muestra la información referente a cheques recibidos. 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. como ya se ha mencionado. es decir estado reclamado. estado escaneando. 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 tiene diversas vistas. También se muestra el estado en que se encuentra cada una de las sucursales (por ejemplo estado apertura del día. Un ejemplo dentro de nuestro caso de estudio es cuando se deposita un cheque y se cargan todos los datos de la cuenta. y en base a este nuevo estado se realizaran los procesamientos antes indicados ante la presencia de un reclamo enviado o un reclamo recibido. la vista en el Sistema Centralizador sólo muestra un resumen de las transacciones realizadas por sucursal. rechazados y reclamados correspondientes a esa sucursal específicamente. enviados. La vista en una sucursal determinada sólo muestra la información referente a cheques recibidos. etc. 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. 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. de manera que si desde uno de los observers se cambian los datos.

El subject mantiene una lista de sus 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 añadir(Observer) eliminar(Observer) notificar() observer do: { :each|each avisar] Observer avisar() ConcreteSubject estado obtenerEstado() definirEstado() return estado.25 . determinamos que el componente modelo es quien cumple el papel del subject y los componentes vista y controlador actúan como observers. Figura 7. Asociando los componentes del patrón de diseño Observer con los componentes del patrón arquitectónico Model-View-Controller.Un componente de este patrón cumple el rol de subject. 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. ConcreteObserver estadoObserver avisar() estadoObserver= subject->obtenerEstado ().Patrón Observer Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 109 . quien contiene métodos mediante los cuales cualquier observer o vista se puede suscribir a él referenciándose a así mismo.

La gran variedad de patrones existentes hace que podamos utilizarlos en casi todo el diseño del sistema.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.Recopilación de los principales patrones arquitectónicos y patrones de diseño con claros ejemplos de aplicación. sino resolver cada problema de diseño que surge con un patrón apropiado. Aún sin proponernos. Por esto se debe ser cuidadoso al momento de seleccionar patrones y analizar muy bien las ventajas y desventajas de su aplicación. haciendo hincapié en la reutilización de soluciones a problemas ya pensados y resueltos con anterioridad. también añaden complejidad. es decir. observamos que en forma intuitiva muchas veces se hace uso de patrones sin una aplicación formalizada. 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.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. Siempre hay que recordar que los patrones son un punto de partida y no dogmas incuestionables. Los patrones no son siempre la solución adecuada o mejor para un problema. Otros posibles trabajos futuros se enumeran a continuación: Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 110 . es muy probable que encontremos un patrón que la resuelva. 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: . Si bien añaden flexibilidad. ante una situación. . . proporcionando un conjunto de subsistemas predefinidos.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. 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.

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. . Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 111 . . Facilitar la aplicación contribuye a lograr mejoras en calidad. productividad y costos.La aplicación de los patrones en diseños preexistentes: En algunas áreas. existen muy buenas microarquitecturas probadas y testeadas.

org/articulo. Patterns of Enterprise Application Architecture. AddisonWesley. Sommerlad. Introduccion al Diseño con Patrones Departamento de Tecnologías de la Información y las Comunicaciones (TIC). Wiley. 2005. Casanovas.usal.udc. 1996. [Fowler05] M. Design Patterns: Elements of Reusable Object-Oriented Software. H.pdf [Griman+05] A. http://www. Patrones de Diseño Software. Helm. 1998.pdf [Lago04] R. Vlissides.ve/publicaciones/03%20evaluacion/evaluacion_0 8. 2004. Usabilidad y Arquitectura del Software. Diaz. P. http://www. http://www.es/~fbellas/teaching/pfc3/IntroPatrones. Lago.es/~fgarcia/doc/patrones1. and J. De Alexander a la Tecnología de http://zarza.pdf [Buschmann+96] F. 2005. F. Universidad de A Coruña. García Peñalvo.proactivacalidad.lisi. R.Bibliografía [Bellas] F.tic.net/articulo/lenguajes_patrones/ [Fowler97] M. M. Fowler. L. Pérez. Gamma R. Cómo desarrollar una arquitectura software: los lenguajes de patrones. 1995.php?id_art=355 [Casanovas04] [Diaz06] M. Mendoza. 2006 http://www.html#algunos_patrones Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 112 . Rohnert. Fowler. J. Meunier. Ed.com/java/patrones/index. Bellas Permuy. Stal Pattern-Oriented Software Architecture: a system of patterns. 2004 http://www. Estudio de la influencia de mecanismos arquitectónicos en la calidad del software. Bushmann. 1997. Grimán. Patrones. [Garcia98] Objetos. Analysis Patterns: Reusable Object Models. Addison-Wesley. M. R. Johnson. [Gamma+95] E.usb.programacion.alzado. AddisonWesley.

itesm. Patrones de Diseño.asp [Reynoso+04] C.blogspot.uba. and Bridge Patterns.aqs. http://today.html [Martin04] [Montaldo05] D.pdf [Pressman98] R. http://www.A. Type Object Pattern. Marzo de 2004. Pearson Educación S.com/2006/04/type-object-pattern. [Reynoso04] C. http://www. Versión 1.cem.0. Prentice Hall. Marzo 2004 http://www. 2003.es/web/files/designpatterns. Rottenstein. Pressman. Editorial Mc Graw Hill. [Tallon98] A. 2006 http://1879. 1998.0.com/spanish/msdn/arquitectura/roadmap_arq /intro. N. Una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado.[Larman03] C. R. 2º Edición. Patrones de Diseño Aplicados a JAVA. Ingeniería del Software – Un Enfoque Práctico. Cuarta Edición. Maximizando reuso en software para Ingeniería Estructural Modelos y Patrones. Template Method.mx:8005/web/200413/cb00894/patrones/p atrones. The Strategy. [Rottenstein06] V. 2000.asp [Rosanigo00] Z. Stelting. Rosanigo. 2003. ITESM CEM. UML y Patrones. Tallón.microsoft.html Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 113 .com/spanish/msdn/arquitectura/roadmap_arq /style.html [Stelting+03] S. Versión 1. Reutilización de ideas. Martin. Introducción a la Arquitectura de Software. Reynoso. 2004. Kicillof. http://www. Introducción a los Patrones.pdf [Ortiz04] A. 2005. http://webdia. Patrones de Diseño de Arquitecturas de Software Enterprise. Larman. Editorial Prentice Hall. Maassen.net/pub/a/today/2004/10/29/patterns. O.fi. 2004. Estilos y Patrones en la Estrategia de Arquitectura de Microsoft. Montaldo.Ortiz Ramirez.microsoft. Reynoso.java.ar/materias/7500/montaldotesisdegradoingenieriainformatica.

Patrones y Antipatrones: una Introducción.asp Arquitectura de Software: Estilos y Patrones Adriana Almeira – Vanina Perez Cavenago Pag 114 . 2002.microsoft. S.[Tanembaum02] A. 2006. Tanembaum. Editorial Prentice Hall.net/voices/ MTJ_2864. Distributed System – Principles and Paradigms. Welicki. http://www. [Welicki06] L.com/spanish/msdn/comunidad/mtj.