Tesina Arquitectura de Software

Arquitectura de Software: Estilos y Patrones
APU. Adriana Sandra Almeira APU. Vanina Perez Cavenago
Directora: Mg. Zulema Beatriz Rosanigo
Tesina presentada a la Facultad de Ingeniera de la Universidad Nacional de la Patagonia San Juan Bosco como parte de los requisitos para la obtencin del ttulo Licenciatura en Informtica.
Trelew, Marzo 2007 Facultad de Ingeniera Universidad Nacional De La Patagonia San Juan Bosco Argentina
A nuestras familias por el apoyo incondicional durante la realizacin de la presente tesina. A Mg. Zulema Beatriz Rosanigo por su direccin, incentivo y paciencia a lo largo del desarrollo de este trabajo.
Adriana Sandra Almeira Vanina Perez Cavenago
Resumen
La temtica ms 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 arquitectnicos como a patrones de diseo. En este trabajo se trata una aplicacin que, de un modo didctico, sirva para la comprensin y utilizacin tanto de patrones arquitectnico como patrones de diseo de forma clara y correcta en la construccin de software. El proyecto est dividido en dos partes fundamentales, una introduccin terica a la Arquitectura de Software, Estilos, Patrones Arquitectnicos y Patrones de Diseo y un caso prctico donde se plasma el anlisis y aplicacin de dichos patrones.

Adriana Almeira Vanina Perez Cavenago
Pag ii
ndice
CAPTULO 1 .................................................................................................................. 1
INTRODUCCIN ................................................................................................................. 1
Objetivos .................................................................................................................. 1 Organizacin del texto................................................................................................ 2
CAPTULO 2 .................................................................................................................. 3
ARQUITECTURA DE SOFTWARE .............................................................................................. 3
Qu son los patrones? .............................................................................................. 4 Origen e historia de patrones...................................................................................... 5 Estilos Arquitectnicos................................................................................................ 6 Estilo Vs Patrones ...................................................................................................... 7 Lenguajes de Descripcin Arquitectnicas .................................................................... 7 Framework................................................................................................................ 8
CAPTULO 3 .................................................................................................................. 9
PATRONES ....................................................................................................................... 9
Clasificacin de Patrones segn la naturaleza del problema ........................................... 9 Caractersticas de un buen patrn ..............................................................................10 Esquema de un patrn ..............................................................................................11 Categoras de Patrones..............................................................................................13
Patrones Arquitectnicos .......................................................................................13 Patrones de Diseo ...............................................................................................14 Idioms .................................................................................................................15
CAPTULO 4 ................................................................................................................ 16
PATRONES ARQUITECTNICOS .............................................................................................16
Del Fango a la Estructura ..........................................................................................16
Sistemas Distribuidos ................................................................................................27 Sistemas Interactivos ................................................................................................33

Model-View-Controller ...........................................................................................34 Presentation-Abstraction-Control ............................................................................38
Layers..................................................................................................................17 Pipes and Filters ...................................................................................................20 Blackboard ...........................................................................................................23 Broker..................................................................................................................28
Sistemas Adaptables .................................................................................................42

Microkernel ..........................................................................................................43 Reflection.............................................................................................................47
CAPTULO 5 ................................................................................................................ 52
PATRONES DE DISEO .......................................................................................................52
Patrones de Creacin ................................................................................................52
Patrones Estructurales...............................................................................................58
Abstract Factory....................................................................................................52 Builder .................................................................................................................54 Prototype .............................................................................................................56 Adapter................................................................................................................58 Bridge..................................................................................................................60 Composite ............................................................................................................61 Proxy ...................................................................................................................63 Template Method..................................................................................................65
Pag iii
Patrones de Comportamiento.....................................................................................64
Observer ..............................................................................................................66 Command ............................................................................................................67 State ...................................................................................................................68 Strategy ...............................................................................................................70 Null Object ...........................................................................................................71 Type Object .........................................................................................................73 Decorador ............................................................................................................76
CAPTULO 6 ................................................................................................................ 79
CASO DE ESTUDIO: SISTEMA DE CHEQUES ...............................................................................79
Participantes ............................................................................................................79 Esquema Operativo...................................................................................................80 Definicin del Sistema ...............................................................................................81

Circuito de Cheques ..............................................................................................81 Circuito de Imgenes por Rechazo..........................................................................82 Circuito de Imgenes por Reclamos........................................................................83
Limites del sistema ...................................................................................................83 Visin Arquitectnica.................................................................................................84 CAPTULO 7 ................................................................................................................ 85

APLICACIN DE PATRONES ..................................................................................................85 Modelo de casos de uso ........................................................................................89
Anlisis ....................................................................................................................85 Diseo .....................................................................................................................92

El Modelo Arquitectnico .......................................................................................92 El Componente Modelo........................................................................................100 Depsito de Cheques.......................................................................................103 Recepcin de Cheques.....................................................................................105 Reclamos de Cheques .....................................................................................107 Los Componentes Vista y Controlador ...................................................................108
CAPTULO 8 ..............................................................................................................110
CONCLUSIONES Y TRABAJOS FUTUROS..................................................................................110
Conclusiones ..........................................................................................................110 Contribuciones........................................................................................................110 Trabajos futuros .....................................................................................................110
BIBLIOGRAFA .........................................................................................................112

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

Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura
7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 7.23 7.24 7.25
Diagrama de secuencia de la interaccin entre componentes ............................................95 Diagrama de clases del patrn Model-View-Controller .......................................................97 Distribucin de los componentes del patrn Model-View-Controller ....................................97 Diagrama de secuencia para la conexin de un usuario al sistema.....................................98 Integracin del patrn Broker, Model-View-Controller y Layers. .........................................99 Estructura de Capa de Servicio, Capa de Acceso a Datos y Base de Datos........................ 100 Componentes del Modelo .............................................................................................. 101 Clase Sucursal .............................................................................................................. 101 Clase Cuenta ................................................................................................................ 101 Clase Cheque ............................................................................................................... 102 Clase ChequeOtraSucursal. ........................................................................................... 102 Aplicacin Patrn Decorator .......................................................................................... 103 Depsito de Cheques .................................................................................................... 105 Recepcin de Cheques .................................................................................................. 106 Aplicacin del Patrn State en el Componente Recepcin de Cheques.............................. 107 Patrn Observer ........................................................................................................... 109

Pag vi
Captulo 1 Introduccin
El proceso del desarrollo de sistemas de software ha ido en aumento en los ltimos aos, demandando la construccin de grandes y complejos sistemas que requieren la combinacin de diferentes tecnologas y plataformas de hardware y software para alcanzar la funcionalidad requerida. El diseo e implementacin ha pasado de una concepcin monoltica y uniforme a una visin heterognea y distribuida. El proceso de desarrollo se ha ido convirtiendo poco a poco en una labor de ingeniera, poniendo de manifiesto la relevancia de un estudio especfico de la estructura del software. Actualmente la elaboracin de especificaciones, el diseo del sistema, construccin de prototipos, integracin y pruebas, forman parte de la Ingeniera del Software respondiendo a la creacin de nuevos modelos, notaciones, tcnicas y mtodos. Dentro de esta orientacin se enmarca el creciente inters al estudio, anlisis y descripcin de la estructura del software dando lugar a aspectos arquitectnicos del mismo. Estos aspectos se refieren a todo lo relativo a la estructura de alto nivel de los sistemas: su organizacin en subsistemas y la relacin entre ellos; la construccin de aplicaciones con reutilizacin de otras existentes y desarrollo de productos que presentan una arquitectura comn. En consecuencia, el modelado de una arquitectura a nivel conceptual permite al diseador decidir cuestiones que tendrn influencia a lo largo de todo el ciclo de vida de la aplicacin. Para disear una arquitectura de software podemos partir con patrones de soluciones ya probados que han funcionado. El objetivo que se persigue con el uso de los patrones dentro del mundo del desarrollo de software es establecer un catlogo de referencia para ayudar a los ingenieros de software a solucionar problemas de ingeniera de software dando lugar a un lenguaje comn con el cual comunicar la experiencia entorno a dichos problemas y a su solucin.
Objetivos
El propsito de la presente tesina es reunir y analizar la informacin necesaria sobre la teora de estilos, patrones arquitectnicos y patrones de diseo, la diversidad de los mismos y la forma de conjugar stos segn la naturaleza de la problemtica a resolver facilitando el desarrollo de aplicaciones manejables, extensibles, fciles de modificar, mantener y reusar. En particular se tomar como caso de estudio, una aplicacin bancaria que aborda la operatoria que realizan los bancos para la gestin de cobro de cheques a travs de la captura descentralizada de los mismos en las sucursales de las entidades depositarias y la centralizacin de la informacin en un repositorio comn.
Adriana Almeira Vanina Perez Cavenago Pag 1
Finalmente se propondr un modelo de arquitectura para este caso de estudio, utilizando adecuadamente patrones que faciliten las posibilidades de reuso y de extensin.
Organizacin del texto

La presente tesina se organiza de la siguiente manera: En el captulo 2 se define la Arquitectura de Software, la importancia dentro del ciclo de vida del sistema de software, y el rol que juegan los estilos y patrones, introduciendo principios y conceptos bsicos. El captulo 3 expone la clasificacin de los patrones segn la naturaleza del problema definiendo el esquema de un patrn, caractersticas y la categorizacin de acuerdo a su nivel de abstraccin. El captulo 4 describe los patrones arquitectnicos en sus diferentes categoras definiendo su triloga contexto-problema-solucin, los beneficios y desventajas que reportan en su implementacin. Algunos ejemplos de patrones arquitectnicos de [Buschamann+96] son utilizados para ilustrar las diferentes categoras. El captulo 5 introduce los conceptos de patrones de diseo, su aplicabilidad en la resolucin de problemas, como interactan sus componentes y las ventajas y desventajas que conlleva su uso. Algunos ejemplos de patrones de diseo de [Gamma+95] ilustran las distintas categoras presentadas. El captulo 6 presenta el caso de estudio. Se detallan los lineamientos fundamentales de la operatoria que deben realizar los Bancos para la implementacin de un sistema en la gestin de cobro de Cheques. Se define el sistema con los correspondientes circuitos y limites. El captulo 7 analiza y disea conceptos del sistema. En la seccin de anlisis se detallan los circuitos de las diferentes operatorias, ayudando a identificar los distintos casos de uso que forman parte del sistema. En la seccin de diseo, se toman los temas tratados en los captulos anteriores, y con ellos se logra la aplicacin de los patrones, evaluando entre las distintas alternativas de patrones frente a una problemtica comn. Como resultado se obtiene el modelado de una alternativa de solucin, pasando por diferentes niveles de abstraccin, desde la general, el sistema como un todo, a lo particular, resolviendo detalles de diseo para pequeos problemas especficos. El captulo 8 presenta las conclusiones y futuros trabajos.

Pag 2
Captulo 2 Arquitectura de Software

Hoy en da las organizaciones hacen uso de sistemas de software complejos, de gran tamao y combinando distintas tecnologas y plataformas de hardware. Esto exige a los desarrolladores de software disear muy cuidadosamente la arquitectura bajo la cual funcionan sus sistemas, ya que las decisiones que se tomen tendrn gran influencia a lo largo de todo el ciclo de vida de la aplicacin. Si bien no hay una definicin oficial de Arquitectura de Software, podemos decir que abarca todo lo relativo a la estructura de alto nivel de los sistemas: su organizacin en subsistemas y la relacin entre ellos. Segn David Garlan la Arquitectura de Software establece un puente entre el requerimiento y el cdigo. A su vez el documento de IEEE Std 1471-2000 define: La Arquitectura de Software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y evolucin. Otra definicin reconocida es la aportada por Clements: La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las formas en que los componentes interactan y se coordinan para alcanzar el objetivo del sistema. La vista arquitectnica es una vista abstracta, aportando el ms alto nivel de compresin y la supresin o diferimiento del detalle inherente a la mayor parte de las abstracciones. Es decir, la arquitectura brinda una visin global del sistema. Esto permite entenderlo, organizar su desarrollo, plantear la reutilizacin del software y hacerlo evolucionar. Se puede ver que la nocin clave de la arquitectura es la organizacin y est relacionada con aspectos de rendimiento, usabilidad, reutilizacin, limitaciones econmicas y tecnolgicas. La arquitectura de software tambin se relaciona con el diseo, pues, es una forma de diseo de software que se manifiesta tempranamente en el proceso de creacin de un sistema. La arquitectura se encuentra en un nivel de abstraccin por encima del diseo de software que se concentra en el modelado de abstracciones de ms bajo nivel. Las interacciones entre componentes en la arquitectura estn en relacin con un protocolo de alto nivel, mientras que las del diseo conciernen a interacciones de tipo procedural. A medida que la arquitectura de alto nivel se refina, sus puntos de conexin pierden grado de abstraccin, distribuyndose as a travs de los elementos arquitectnicos de ms bajo nivel, resultando en la transformacin de la arquitectura en diseo. La arquitectura es algo ms integrado que la suma del anlisis por un lado y el diseo por el otro. sta se ocupa de componentes y no de procedimientos; de las interacciones entre esos componentes y no de las interfaces; de las restricciones a ejercer sobre los componentes y las interacciones y no de los algoritmos, los procedimientos y los tipos.

Pag 3
La Arquitectura de Software debe representar distintos aspectos del software. Por lo general, cada uno de estos aspectos se describe en forma ms comprensible si se utilizan diversos modelos o vistas. Se debe destacar que cada uno de ellos establece una descripcin parcial de la misma arquitectura y es deseable que exista cierto solapamiento entre ellos, ya que todas las vistas deben ser coherentes entre s, dado que estn describiendo la misma cosa. Cada paradigma de desarrollo exige vistas, de las cuales, hay por lo menos tres que son esenciales en cualquier arquitectura: - La visin esttica: describe cules son los componentes de la arquitectura. - La visin funcional: describe qu hace cada componente. - La visin dinmica: describe cmo se comportan los componentes a lo largo del tiempo y como interactan entre s. Las vistas de una arquitectura pueden formularse por medio de uno o varios lenguajes. El ms obvio es el lenguaje natural, pero tambin existen otros como los diagramas de estado, los diagramas de flujo de datos, etc.. Existe cierta aceptacin en el uso de UML (Unified Modeling Language, lenguaje unificado de modelado) como nico lenguaje para todos los modelos o vistas. Segn Sahw y Garlan existen un conjunto de propiedades que se deben especificar como parte del diseo arquitectnico: - Propiedades estructurales. Este aspecto de la representacin del diseo arquitectnico define los componentes de un sistema y la forma en que se empaquetan e interactan unos con otros. - Propiedades extra-funcionales. La descripcin del diseo arquitectnico debera ocuparse de cmo consigue la arquitectura del diseo los requisitos de rendimiento, capacidad, fiabilidad, seguridad, adaptabilidad y otras caractersticas del sistema. - Familias de sistemas relacionados. El diseo arquitectnico debera tener la capacidad de utilizar bloques de construccin arquitectnica reutilizados. Segn la especificacin de estas propiedades, el diseo arquitectnico puede representarse usando uno o ms modelos diferentes. Los modelos estructurales representan la arquitectura como una coleccin organizada de componentes de programa. Los modelos estructurales aumentan el nivel de abstraccin de diseo intentando identificar estructuras de diseo arquitectnico repetibles (patrones) que se pueden encontrar en tipos similares de aplicaciones.
Qu son los patrones?

Los patrones son una disciplina de resolucin de problemas en la ingeniera del software que ha surgido con mayor nfasis en la comunidad de orientacin a objetos, aunque pueden ser aplicados en cualquier mbito de la informtica y las ciencias en general. El arquitecto Christopher Alexander define el trmino patrn de la siguiente manera:

Pag 4
Cada patrn es una regla de 3 partes, que expresa una relacin entre un contexto, un problema y una solucin. Como un elemento en el mundo, cada patrn es una relacin entre un contexto, un sistema de fuerzas que ocurren repetidamente en ese contexto y una configuracin espacial que permite que esas fuerzas se resuelvan entre s. Como elemento de un lenguaje, un patrn es una instruccin que muestra como puede ser usada esta configuracin 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 construccin, tambin puede aplicarse al software. Los patrones de software permiten que se reutilice tanto el diseo como la arquitectura, adoptando estructuras estticas y dinmicas de soluciones exitosas en la solucin 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 prcticas de diseo. Cada patrn aborda un problema especfico y recurrente en el diseo o implementacin de un software. Las tcnicas generales para la arquitectura de software no apuntan a la solucin de problemas especficos. Varios de los mtodos existentes de anlisis y diseo fallan a este nivel, ya que solamente proveen tcnicas generales para construir software. La creacin de arquitecturas especficas sigue basada en la intuicin y experiencia. Los patrones son bloques de construccin mental tiles para proceder con aspectos de diseo limitados y especficos en el momento del desarrollo de un sistema de software, su concepto dominante es la reutilizacin.
Origen e historia de patrones

En la dcada 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 patterns2 de la serie POSA [Buschmann+96] en 1996. El primero de ellos presenta un conjunto de patrones de diseo de software bajo el paradigma de la orientacin a objetos, mientras que el segundo despliega un marco levemente ms ligado a la Arquitectura de Software. Este surgimiento no ha hecho ms que expandirse desde esos aos. Aunque el arquitecto Christopher Alexander haca referencia a patrones de edificios y urbanos, lo que l propona se puede aplicar de igual forma a patrones de software, donde las soluciones se plantean en trminos de componentes, interfaces y relaciones en lugar de paredes y puertas.
1 2
Del ingls 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

Aos ms tarde, las ideas llegaron por fin a la informtica. Si bien el concepto de arquitectura implcita en el trabajo actual con patrones, est ms cerca de la implementacin, la reutilizacin de patrones guarda estrecha relacin con la tradicin del diseo concreto orientado a objetos. En pos de la Arquitectura de Software en estos aos se homogeneiz la terminologa utilizada, se tipificaron los estilos arquitectnicos, patrones arquitectnicos, se elaboraron lenguajes de descripcin de arquitectura y tambin se consolidaron las vistas arquitectnicas.
Estilos Arquitectnicos
Un estilo arquitectnico es una lista de tipos de componentes que describen los patrones o las interacciones a travs de ellos. Un estilo afecta a toda la arquitectura de software y puede combinarse en la propuesta de solucin. Los estilos ayudan a un tratamiento estructural que concierne ms bien a la teora, la investigacin acadmica y la arquitectura en el nivel de abstraccin ms elevado, expresando la arquitectura en un sentido ms formal y terico. Una vez que se han identificado los estilos, es lgico 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, tcitamente se est haciendo referencia a una clasificacin de las posibles configuraciones disponibles, en cuyo contexto adquiere un significado distintivo. No tiene sentido hablar de estilos si no se clarifica cul es la tipologa 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 cuestin no es clasificarlas sino que al optar por una forma arquitectnica se define una situacin pragmtica. Una vez que los estilos adquieren una dimensin semntica precisa y diferencial, a su significado se asocian conceptos, herramientas, problemas, experiencias y antecedentes especficos. Existe una clasificacin de familias de estilos, entre los que podemos destacar: - Estilos de Flujo de Datos: Esta familia de estilos destaca la reutilizacin 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 actualizacin de datos. - Estilos de Llamada y Retorno: Pone mayor atencin sobre la modificabilidad y la escalabilidad del sistema. Son estilos que se utilizan para sistemas en gran escala. - Estilos de Cdigo Mvil: Su mayor inters est en la portabilidad. Como ejemplo estn los intrpretes.

Pag 6
Estilo Vs Patrones
Los estilos expresan componentes y las relaciones entre stos, con las restricciones de su aplicacin y la composicin asociada, as como tambin las reglas para su construccin. As mismo, se considera como un tipo particular de estructura fundamental para un sistema de software, junto con un mtodo asociado que especifica cmo construirlo. Por otra parte, los patrones arquitectnicos capturan existencia, experiencia comprobada en el desarrollo del software y ayudan a promover buenas prcticas de diseo. Cada patrn es especfico a un problema recurrente en el diseo e implementacin de un sistema de software. Un patrn, como ya se ha comentado, se considera un par problema solucin, resultado de la experiencia en el diseo de arquitecturas de sistemas y propone los patrones arquitectnicos como descripcin de un problema particular y recurrente de diseo, que aparece en contextos de diseo especfico, y presenta un esquema genrico demostrado con xito para su solucin. El esquema de solucin se especifica mediante la descripcin de los componentes que la constituyen, sus responsabilidades y desarrollos, as como tambin la forma como stos colaboran entre s. Por ltimo, un patrn de diseo provee un esquema para refinar los subsistemas o componentes de un sistema de software, o las relaciones entre ellos. Describe la estructura comnmente recurrente de los componentes en comunicacin, que resuelve un problema general de diseo en un contexto particular. Su aplicacin 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 implementacin, el comportamiento de los componentes del subsistema. Los estilos y patrones ayudan al arquitecto a definir la composicin y el comportamiento del sistema de software. Se puede afirmar que una combinacin adecuada de ellos permite alcanzar los requerimientos de calidad esperados.
Lenguajes de Descripcin Arquitectnicas

Como fue indicado anteriormente, la Arquitectura del Software tiene como objetivo el conocimiento, anlisis y reutilizacin de la arquitectura de sistemas de software. Para explicitar dicha arquitectura, se requiere hacer uso de algn lenguaje. Los Lenguajes de Descripcin Arquitectnicas (ADLs) son lenguajes que se focalizan en la descripcin de la estructura de alto nivel de una aplicacin pero a su vez permiten un nivel de detalle suficiente para describir propiedades de inters de dicha aplicacin. 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 propsito general, adaptable a soluciones de cualquier estilo arquitectnico.

Pag 7
Los conceptos tratados en una descripcin arquitectnica son: - Componentes. Representan unidades de computacin o de almacenamiento de datos. - Conectores. Modelan las interacciones entre componentes y las reglas que se aplican a dichas interacciones. - Configuraciones arquitectnicas. Grafos de componentes y conectores que describen la estructura arquitectnica del sistema. El objetivo de los ADLs es describir la interfaz de cada componente, no su comportamiento interno, formando de esta manera sistemas ms grandes. La descripcin de la interfaz incluye los mtodos que ofrece o requiere el componente, informacin sobre la funcionalidad del mismo, los patrones de interaccin que utiliza en su funcionamiento, y otras caractersticas diversas. Los requisitos que deben cumplir los ADLs son los siguientes: - Composicin: Describir el sistema como una composicin de partes. - Configuracin: Describir la arquitectura independientemente de los componentes. - Abstraccin: Describir los roles abstractos que juegan los componentes. - Reutilizacin: Permitir reutilizar componentes, conectores, y arquitecturas. - Heterogeneidad: Permitir combinar descripciones heterogneas. - Anlisis: Permitir diversas formas de anlisis de la arquitectura. Existen varios ejemplos de ADLs, entre los que se encuentran: Unicon, Wright, Darwin, Rapide, etc. cada uno con sus propias caractersticas.
Framework
Un framework es un diseo reutilizable del sistema completo o de alguna de sus partes y se expresa mediante un conjunto de clases abstractas y la forma de interactuar de sus instancias. Un simple framework puede involucrar a muchos patrones de diseo; es decir, estos patrones son ms pequeos que los framework, lo que implica, que los patrones son menos abstractos que ellos, son elementos microarquitectnicos de los frameworks.

Pag 8
Captulo 3 Patrones
Clasificacin de Patrones segn la naturaleza del problema
Considerando algunos de los patrones existentes se observa que ellos pueden cubrir varios rangos de escala y abstraccin: - Estructurar un sistema de software dentro de subsistemas. - Soportar el refinamiento de subsistemas y componentes o la relacin entre ellos. - Ayudar a implementar aspectos particulares de diseo en un lenguaje de programacin especfico. Para refinar dicha escala podemos agrupar los patrones que representan un rango similar de abstraccin en tres categoras: - Patrones Arquitectnicos - Patrones de Diseo - Idioms Patrones Arquitectnicos Los patrones arquitectnicos son plantillas que describen los principios estructurales globales que construyen las distintas Arquitecturas de Software viables. Plantean una organizacin estructural fundamental para un sistema de software, expresando un conjunto de subsistemas predefinidos, especificando responsabilidades y organizando las relaciones entre ellos. La seleccin de un patrn arquitectnico es adems una decisin fundamental de diseo cuando se desarrolla un sistema de software. Patrones de Diseo Un patrn de diseo provee un esquema para refinar componentes de un sistema de software y la forma en que se relacionan entre s. Describe una estructura generalmente recurrente de comunicacin de componentes que resuelve un problema de diseo general dentro de un contexto particular. Los patrones de diseo son patrones de granularidad media, ya que tienen menor nivel de abstraccin que los patrones arquitectnicos pero tienden a ser independientes de un lenguaje de programacin en particular o de un paradigma de programacin.
La aplicacin de un patrn de diseo no tiene un efecto fundamental en la estructura del sistema de software global, pero tiene gran ingerencia sobre la arquitectura de un subsistema. Idioms Los Idioms estn relacionados con la implementacin de diseo de problemas particulares. Un Idiom es un patrn de bajo nivel especfico para un lenguaje de programacin. Describe como implementar aspectos particulares de componentes o las relaciones entre ellos usando las caractersticas dadas por el lenguaje. Los Idioms representan el nivel ms bajo de patrones y direccionan tanto aspectos de diseo como de implementacin. A continuacin se presenta una clasificacin de patrones segn la categora del problema
Categora de Patrones
Arquitectura Cimientos Sistemas Distribuidos Sistemas Interactivos Sistemas Adaptables Creacin Descomposicin Estructural Organizacin del Trabajo Control de Acceso Variacin de Servicios Extensin de servicios Administracin Adaptacin Comunicacin Estructuracin y Configuracin 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, Facade, Iterator Bridge, Strategy, State Decorator Adapter Forwarder-Receiver Client-Dispatcher-Server Publisher-Subscriber Extension Interface Flyweight Visitor Memento Builder Diseo
Caractersticas de un buen patrn

Segn James Coplien, un buen patrn es aquel que: - Resuelve un problema, ya que representa una solucin, no suposiciones o estrategias abstractas. - Captura soluciones a problemas, que han sido repetidamente probadas y no son solo teoras o especulaciones.
Segn el Problema
Figura 3.1 - Categora de Patrones segn el tipo de problemas
- Genera una solucin a un problema indirectamente (un enfoque necesario para los problemas de diseo ms difciles). - No describe mdulos sino estructuras y mecanismos de relacin entre ellas.
-
Pone especial atencin a la esttica y a las utilidades. Tiene un componente humano significante.
El anlisis de patrones revela que sus componentes y relaciones no son tan atmicas como se ve a primera vista. La solucin a un problema puede arribarse aplicando un solo patrn o combinaciones de varios patrones resolviendo problemas ms pequeos, todos ellos integrados por un gran patrn que los contenga.
Esquema de un patrn
Todo patrn se representa con un esquema de tres partes: Contexto Problema Solucin. El esquema denota una regla que establece una relacin entre un contexto dado, un cierto problema que tiene lugar en ese contexto y una solucin apropiada al problema. Contexto: El contexto extiende la dicotoma problema-solucin describiendo la situacin en la cual ocurre el problema. Es difcil especificar el contexto correcto para un patrn, siendo prcticamente imposible determinar todas las situaciones, tanto generales como particulares en la cual puede ser aplicado un patrn. Un acercamiento ms pragmtico es listar todas las situaciones conocidas que pueden ocurrir donde un problema es direccionado por un patrn en particular. Esto no garantiza que se cubran todas las situaciones en las cuales pueda ser relevante el patrn pero al menos nos da una gua valuable. Problema: Esta parte del esquema de descripcin de patrn representa el problema que nace repetidamente en un contexto dado. Comienza con su especificacin general, determinando cual es el problema en concreto que se debe resolver y tratando de balancear sus fuerzas. Solucin: La solucin parte de un patrn que muestra como resolver un problema recurrente, o como balancear mejor las fuerzas asociadas a l. Al plantear el problema se deben tener en cuenta las fuerzas o aspectos que deberan ser considerados como seran:

Los requisitos que las soluciones deben cumplir. Las restricciones que se deben considerar. Las propiedades deseables que la solucin debera tener.
En general, las fuerzas atacan al problema desde varios puntos, ayudando a comprender los detalles del mismo y a justificar los diseos y las implementaciones.

Pag 11
En el caso de los patrones, stos relacionan conjuntos de objetivos y restricciones que se encuentran en el desarrollo de cada elemento que se va a crear. Estas fuerzas son conflictivas y difciles de calcular. El siguiente diagrama resume un esquema, el cual captura la esencia de un patrn independientemente de su dominio.
Patrones Contexto Plantea la situacin dando comienzo al diseo del problema Problema Conjunto de fuerzas que aparecen repetidamente en el contexto Solucin Configura el balance entre fuerzas Estructuras con componentes y relaciones Comportamiento en tiempo de ejecucin
Figura 3.2 - Esquema de tres partes : contexto problema - solucin
Los patrones se definen utilizando formatos consistentes. Una buena definicin de un patrn permite entenderlo inmediatamente, y adems provee todos los detalles necesarios para implementarlo y considerar las consecuencias de su aplicacin. Los patrones se definen uniformemente, esto ayuda a compararlos, especialmente cuando se buscan soluciones alternativas a un problema. La estructura bsica Contexto Problema Solucin, antes mencionada, captura las caractersticas esenciales de un patrn y brinda ideas claves sobre ste facilitando la toma de decisin ante distintos patrones alternativos. Adems de esta estructura, para formalizar un patrn segn la nomenclatura sugerida por [Buschmann+96], debe definirse: - Un nombre el cual tiene que ser representativo de su esencia, que de idea del problema que aborda y de su solucin. - Diagramas y escenarios que ilustren los aspectos estticos y dinmicos de la solucin. - Guas que sugieren como implementar el patrn, para transformar una arquitectura dada en una que usan los patrones. - Variantes de un patrn o patrones relacionados con el que se esta definiendo y cuales son sus diferencias. Estos otros patrones proveen soluciones alternativas a un problema.
-
Ventajas y desventajas potenciales de un patrn clarificando las consecuencias de su aplicacin. Esta seccin brinda informacin til para decidir si se usa o no para ofrecer una solucin adecuada a un problema especfico.

Pag 12
Categoras de Patrones
Patrones Arquitectnicos
Los patrones arquitectnicos representan el nivel ms alto dentro del sistema de patrones y expresan el esquema de la estructura fundamental de la organizacin para sistemas de software. Proveen un conjunto de subsistemas predefinidos, especifican sus responsabilidades e incluyen reglas y guas para organizar las relaciones entre ellos. Cada patrn ayuda a lograr una propiedad especfica del sistema global como es la adaptabilidad de la interfaz de usuario. Los patrones que dan soporte a propiedades similares pueden ser agrupados en las siguientes categoras: - Del fango a la estructura. Ayudan a evitar un mar de componentes u objetos. En particular apoyan una descomposicin controlada de una tarea del sistema global en subtareas cooperantes. Esta categora incluye los patrones Layers, Pipes and Filters y Blackboard. - Sistemas Distribuidos: incluye el patrn Broker y hace referencia a dos patrones que se encuentran en otras categoras, Microkernel y Pipes and Filters. El patrn Broker provee una infraestructura completa para aplicaciones distribuidas. Los patrones Microkernel y Pipes and Filters consideran la distribucin como un concepto secundario y estn ubicados bajo sus respectivas categoras primarias. - Sistemas Interactivos: En esta categora entran dos patrones el Model-ViewController (MVC) y el PresentationAbstractionControl (PAC). Ambos apoyan la estructuracin de sistemas de software que ofrecen la interaccin usuariocomputadora. - Sistemas Adaptables: Los patrones Reflection y Microkernel apoyan fuertemente la extensin de aplicaciones y su adaptacin a desenvolverse con la tecnologa y cambios en los requisitos funcionales. La seleccin de un patrn arquitectnico debera ser conducida por las propiedades generales de la aplicacin a estudiar. Por ejemplo, si el sistema propuesto es un sistema interactivo o uno que tendr diferentes variantes, la eleccin del patrn debera estar influenciada ms all de los requerimientos no funcionales de la aplicacin, como la modificabilidad y la fiabilidad. La seleccin de un patrn arquitectnico, o la combinacin de varios, es solamente el primer paso cuando se disea la arquitectura de software de un sistema. Hay puntos que son recomendables para tener en cuenta al momento de elegir un patrn arquitectnico:

Es til explorar varias alternativas antes de decidir sobre un patrn arquitectnico especfico. Diferentes patrones arquitectnicos implican diferentes consecuencias, an si direccionan al mismo o problemas similares. Muchos sistemas de software no pueden ser estructurados de acuerdo a un patrn arquitectnico simple, dando soporte a requerimientos del

Pag 13
sistema que solamente pueden ser solucionados mediante la aplicacin de diferentes patrones arquitectnicos. Un patrn arquitectnico particular, o una combinacin de stos, no es una arquitectura de software completa, es un framework estructural para un sistema de software que debe ser luego especificado y refinado. Esto incluye la tarea de integrar la funcionalidad de las aplicaciones con el framework y detallar sus componentes y relaciones. Dentro de los patrones arquitectnicos se pueden citar: Layers, Pipes and Filters, Blackboard, Broker, Model-ViewController, Presentation AbstractionControl, Microkernel y Reflection. En el captulo siguiente se ver con ms detalle cada uno de estos patrones.
Patrones de Diseo
Los patrones de diseo son soluciones bien documentadas que los desarrolladores emplean para dar solucin a nuevos problemas apoyados en la experiencia de haberlas utilizado con xito en el pasado. Los profesionales identifican partes de un problema que son anlogos a otros problemas que han resuelto anteriormente. Luego, retoman la solucin utilizada y la generalizan. Por ltimo, adecan la solucin general al contexto de su problema actual. De esta forma, los patrones de diseo brindan una forma eficaz de compartir la experiencia dentro de la comunidad de la programacin orientada a objetos. Si bien los patrones de diseo no son exclusivos de este tipo de programacin, es en este paradigma donde ha tenido una mayor aceptacin, debido a que permite realizar una muy buena representacin del mundo real adaptndose muy bien a las metforas arquitectnicas propuestas por el arquitecto Christopher Alexander. Los objetos pueden articularse en estructuras ms complejas, al igual que la arquitectura, agregando adems la nocin de tiempo por medio del intercambio de mensajes entre objetos. Los patrones de diseo se han transformado en una tcnica difundida para la reutilizacin de conocimiento de diseo de software. Su principal motivacin es el hecho de encontrar con mucha frecuencia problemas similares, en diseos diferentes. Un patrn de diseo es una estructura de clases que se presenta en forma repetida en distintos diseos orientados a objetos, la cul es empleada para resolver un problema determinado de manera flexible y adaptable en forma dinmica. Dentro de los patrones de diseo existen variaciones segn su nivel de granularidad y abstraccin, lo que permite clasificarlos bajo dos criterios: Propsito, refleja qu hace un patrn teniendo en cuenta si es de Creacin, Estructural o de Comportamiento; y mbito, especifica si un patrn se aplica primariamente a una clase o a un objeto. - De Creacin: abstrae el proceso de instanciacin de objetos, su misin es permitir construir sistemas independientes de la forma de creacin, composicin o representacin de objetos. Un patrn de creacin de clases utiliza la herencia para variar la clase que es instanciada, un ejemplo de este tipo de patrn es Factory Method. Un patrn de creacin de objetos delega la instanciacin en otro objeto, por ejemplo el patrn Builder.
- Estructural: controla como se componen las clases u objetos en la construccin de estructuras mayores. Un patrn estructural de clases utiliza la herencia para componer interfaces o implementaciones, por ejemplo el patrn Adapter. Un patrn estructural de objetos describe la forma en que se componen objetos para obtener nueva funcionalidad, adems se aade la flexibilidad de cambiar la composicin en tiempo de ejecucin, lo cual no es posible con la composicin de clases estticas, como representante de este tipo de patrn se puede mencionar al patrn Composite. - De Comportamiento: se relaciona con algoritmos, la forma en la que interactan las clases u objetos y la asignacin de responsabilidades entre ellos. Los patrones de comportamiento de clases utilizan la herencia para distribuir el comportamiento entre las clases, se puede citar como ejemplo el patrn Command. Por su parte los patrones de comportamiento de objetos cooperan como un grupo de objetos interconectados para realizar una tarea que un solo objeto no puede realizar por s solo, un ejemplo es el patrn Observer.
Idioms
En contraste con los patrones de diseo, los cuales se orientan hacia las arquitecturas generales principales, los idioms describen cmo resolver problemas de implementacin especficos en un lenguaje de programacin determinado. Los Idioms pueden tambin realizar directamente la implementacin concreta de un patrn de diseo particular. Los idioms se aproximan o se solapan con reas que son, por lo general, regidas por guas de programacin.

Pag 15
Captulo 4 Patrones Arquitectnicos

La seleccin de un patrn arquitectnico debera ser conducida por las propiedades generales de la aplicacin a estudiar. Es til explorar varias alternativas antes de decidir sobre un patrn arquitectnico especfico. Por ejemplo el patrn PAC y el MVC ambos se prestan para aplicaciones interactivas. En forma similar los patrones Reflection y Microkernel apoyan la adaptacin de sistemas de software a la evolucin de requisitos. Diferentes patrones arquitectnicos implican diferentes consecuencias, an si encaminan al mismo o a problemas similares. Por ejemplo, una arquitectura MVC usualmente es ms eficiente que una arquitectura PAC. Por otro lado, PAC soporta multitareas y tareas especficas de interfaces de usuarios mejor de lo que lo hace MVC. Muchos sistemas de software no pueden ser estructurados de acuerdo a un patrn arquitectnico simple. Deben dar soporte a muchos requerimientos de sistema que pueden solamente ser direccionados por diferentes patrones arquitectnicos. Por ejemplo, tener que disear tanto para flexibilidad de componentes distribuidos en una red de computadoras heterogneas como tambin para adaptabilidad de las interfases de usuarios. Se deben combinar varios patrones para estructurar tal sistema.
Del Fango a la Estructura

En esta categora se encuentran los patrones que ayudan a evitar un mar de componentes u objetos apoyando una descomposicin controlada de una tarea del sistema global en subtareas cooperantes. Dentro de esta clasificacin de patrones arquitectnicos se encuentran diferentes tipos de patrones que proporcionan subdivisiones de alto nivel del sistema: Layers, Pipes and Filters y Blackboard donde: - El patrn Layers ayuda a estructurar aplicaciones que pueden ser descompuestas en grupos de subtareas, en el que cada grupo pertenece a un nivel particular de abstraccin. - El patrn Pipes and Filters provee una estructura para sistemas que procesan un flujo de datos. Cada paso del proceso esta encapsulado en un componente filter. Los datos se pasan a travs de los pipes entre filters adyacentes. La combinacin de filters permite construir familias de sistemas relacionados. - El patrn Blackboard es til para problemas en los cuales no se conoce ninguna estrategia de solucin determinstica. En este patrn varios subsistemas especializados ensamblan sus conocimientos para construir una solucin posiblemente parcial o aproximada. A continuacin describiremos con ms detalle cada uno de ellos.
Layers
El patrn arquitectnico Layers ayuda a estructurar aplicaciones que pueden descomponerse en grupos o subtareas, en las cuales cada grupo de subtareas tiene un nivel de abstraccin particular. Contexto Un sistema extenso que requiere descomposicin. Problema Considerar que se disea un sistema cuya caracterstica dominante es una mezcla de problemas de altos y bajos niveles, donde las operaciones de alto nivel confan en operaciones de bajo nivel. Algunas partes del sistema manejan problemas de bajo nivel como interrupciones por hardware, entradas de sensor, lectura de bits de un archivo o seales elctricas, y en el otro extremo, problemas de nivel ms alto, como por ejemplo la interfaz de una aplicacin multi-usuario. Un patrn tpico de comunicacin consiste en el pasaje de solicitudes desde la capa superior hacia la de nivel ms bajo y las respuestas en direccin opuesta enviando datos o notificando acerca de eventos. Tales sistemas adems requieren de alguna estructura horizontal que es ortogonal a su subdivisin vertical. Este es el caso donde varias operaciones estn en el mismo nivel de abstraccin pero son independientes unas de otras. El sistema tiene como objetivo la portabilidad a otras plataformas. En ese caso se necesitan balancear las siguientes fuerzas: - Los cambios en el cdigo fuente de un componente no afectaran a otros. - Las interfaces deberan ser estables, y podran ser estandarizadas. - Las partes del sistema deberan ser cambiables. Los componentes deberan ser capaces de ser reemplazados por implementaciones alternativas sin afectar al resto del sistema. Hacer un diseo para realizar cambios generales es lo que hace ms fcil la evolucin elegante del mismo. - Responsabilidades similares deberan ser agrupadas para ayudar a entender y mantener al sistema. Cada componente debera ser coherente - si un componente implementa problemas divergentes puede perder su integridad. - Componentes complejos necesitan ms descomposicin. - El cruzamiento de lmites de los componentes puede hacer que se pierda performance.
-
Si el sistema fuese construido por un equipo de programadores, el trabajo debe ser dividido de acuerdo a lmites claros.

Pag 17
Solucin Si observamos la solucin desde un alto nivel de abstraccin esta es extremadamente simple. Se debe estructurar el sistema en un nmero apropiado de capas y ubicarlas unas encima de otras, comenzando por el nivel ms bajo de abstraccin Capa 1. Esta es la base del sistema. Se deben trabajar los niveles de abstraccin colocando una capa sobre otra hasta que se coloque en el tope, el nivel de funcionalidad Capa N, lo que da una vista conceptual del sistema. Es esencial que dentro de una capa individual todo el trabajo del componente constitutivo trabaje al mismo nivel de abstraccin. Los servicios de cada capa implementan una estrategia para combinar servicios de las capas inferiores con algn significado. Estructura Una capa individual se puede describir como sigue:
Clase Layer J Responsabilidades - Provee servicios usados por la capa J+1 - Delega las subtareas a la capa 1 Colaborador - Layer J - 1
Figura 4.1 - Clase de la capa J
La principal caracterstica estructural del patrn Layers es que los servicios de una Capa J son solamente usados por la Capa J+1 no se pueden saltear capas. Esta estructura puede ser comparada con una pila. Cada capa individual escuda todas las capas inferiores de accesos directos por capas superiores.
Cliente Layer N El Nivel mas alto de abstraccin
Layer N - 1
Layer 1
El Nivel mas bajo de abstraccin
Figura 4.2 - Esquema de estructuracin en capas
Consecuencias El patrn Layers tiene varias ventajas:

o
Reusabilidad. Si una capa individual incluye una abstraccin bien definida y

tiene una interfaz bien definida y documentada, la capa puede ser reusada en mltiples contextos.
Pag 18

Estandarizacin. Niveles de abstraccin claramente definidos y comnmente

aceptados habilitan el desarrollo de tareas e interfaces estandarizadas. Implementaciones diferentes de la misma interfaz pueden ser usadas en forma indistinta. Esto permite usar productos de diferentes vendedores en distintas capas.
Portabilidad. Las interfaces estandarizadas entre capas limitan el efecto de
cambios de cdigo a la capa a modificar. Los cambios de hardware, del sistema operativo y todo lo que afecta solamente a una capa, se puede modificar sin alterar al resto de las capas. Esto permite la portabilidad del sistema, y testeo independiente de las capas.
Cambiabilidad. La implementacin de capas individuales puede ser reemplazada por una implementacin semnticamente equivalente sin grandes esfuerzos, por ejemplo, cambiar o agregar un hardware. Un nuevo dispositivo de E/S, puede ser puesto en operacin instalando el driver correcto. Las capas superiores no se vern afectadas por el cambio.
El patrn Layer tambin impone desventajas: o
Baja eficiencia. Una arquitectura en capas es usualmente menos eficiente que una estructura monoltica. Si servicios de alto nivel en capas superiores necesitan obligatoriamente de las capas inferiores, todo dato relevante debe ser transferido a travs de varias capas intermedias, y puede llevar mucho tiempo. La comunicacin de protocolos, por ejemplo, transforman los mensajes de alto nivel mediante el agregado de cabeceras e informacin de control. Trabajo innecesario. Capas inferiores pueden necesitar hacer tareas que no
han sido solicitadas para brindar un determinado servicio a una capa superior. Este trabajo excesivo tiene un impacto negativo en la performance.
arquitectura de capas con muy pocas capas no explota completamente la potencial reusabilidad, cambiabilidad y portabilidad de este patrn. Por otro lado, tambin muchas capas introducen complejidad innecesaria de sobrecarga en la separacin y la transformacin de argumentos y valores de retorno. La decisin de la granularidad de las capas y la asignacin de tareas es dificultosa, pero es indispensable para lograr calidad en la arquitectura.
Dificultad al establecer la correcta granularidad de las capas. Una
Ejemplo Un ejemplo tpico donde se utiliza el patrn Layers es en la estructura del protocolo de comunicacin OSI. Los diseadores hacen uso de varios subprotocolos y los colocan en capas. Esta es una arquitectura en donde hay varios niveles de comunicacin, partiendo desde el hardware pasando por la comunicacin punto a punto y llegando a los protocolos de aplicaciones. Estos niveles a su vez se dividen en subniveles y llevndolos cada uno a capas diferentes. Cada capa lleva a cabo una tarea especfica para la comunicacin y utiliza los servicios que le brinda su capa inmediata inferior. La arquitectura estara dividida en las siguientes capas:

Pag 19
Aplicacin (Capa 7) Presentacin (Capa 6) Sesin (Capa 5) Transporte (Capa 4) Red (Capa 3) Enlace de Datos (Capa 2) Fsica (Capa 1)
Figura 4.3 - Esquema del protocolo de red OSI
Donde cada una de ellas se comunica solo con su capa inmediatamente inferior para solicitarle servicios, y con su capa inmediatamente superior para brindarle servicio, imposibilitando la comunicacin entre capas no adyacentes. Mantener la independencia entre capas de esta manera, permite realizar modificaciones en una capa sin que esto afecte al resto de las capas. La estratificacin en capas es considerada una mejor prctica que la implementacin del protocolo como un bloque monoltico.
Pipes and Filters

El patrn arquitectnico Pipes and Filters provee una estructura para sistemas que procesan flujo de datos, donde cada paso de procesamiento es encapsulado en un componente filter y los datos pasan entre filters adyacentes. Combinando filters se permite la construccin de una familia de sistemas relacionados. Contexto Procesamiento de flujo de datos Problema La construccin de un sistema que debe procesar o transformar un flujo de entrada de datos. La implementacin de tal sistema como un componente simple no puede ser factible por varias razones: - El sistema es desarrollado por varios desarrolladores, - La tarea de un sistema global se descompone naturalmente en varias fases del proceso, - Los requerimientos probablemente son cambiables. Por lo tanto, cambiando o reordenando los pasos del procesamiento se planifica la futura flexibilidad, construyendo de sistemas que usen los componentes existentes del proceso.
Al realizar el diseo del sistema especialmente la interconexin de pasos de procesamiento se deben considerar las siguientes fuerzas: - Debera posibilitar futuros perfeccionamientos de sistemas intercambiando o recombinando pasos de procesamiento. - Pequeos pasos de procesamiento deberan ser fciles de reusar en diferentes contextos de grandes componentes. - Pasos de procesamiento que no son adyacentes no deberan compartir informacin. - El sistema debera permitir diferentes fuentes de entrada de datos, como puede ser una conexin a la red o un sensor de hardware que provee lecturas de temperaturas. - Debera ser posible presentar o almacenar resultados finales en formas diferentes. Solucin El patrn Pipes and Filters divide la tarea del sistema en varios pasos de procesamiento. Estos pasos se conectan por un flujo de datos a travs del sistema -los datos de salida de un paso son la entrada para el paso siguiente. Cada paso de procesamiento es implementado por un componente filter. Un filter consume y entrega datos incrementalmente en vez de consumir todas sus entradas antes de producir cualquier salida- logrando, de esta forma, baja latencia y habilitando un proceso realmente paralelo. La entrada al sistema es provista por una fuente de datos, por ejemplo, un archivo de texto. El flujo de datos de salida es un almacenamiento como puede ser un archivo, una terminal, un programa, etc. La fuente de datos, los filters y la salida de datos estn conectados secuencialmente por pipes. Cada pipe implementa el flujo de datos entre pasos de procesamiento adyacentes. La secuencia de filters combinada por pipes es llamada Procesamiento Pipelines. Estructura Los filters son la unidad de procesamiento de los pipelines. Un filter enriquece, refina o transforma la entrada de datos. - Enriquece los datos computando y agregndole informacin, - los refina concentrando o extrayendo la informacin y - los transforma entregndolos en alguna otra representacin. Una implementacin concreta de filter puede combinar cualquiera de estos tres principios bsicos. Los pipes denotan la conexin entre filters, entre la fuente de datos y el primer filter, y entre el ltimo filter y los datos de salida. Los pipes sincronizan dos componentes filtres adyacentes. La sincronizacin es hecha en el buffer como el primero en entrar, es el primero en salir.

Pag 21
Clase Filter Responsabilidades

- Toma los datos de la entrada - Realiza una funcin en los datos de entrada - Suministra datos de salida
Colaborador - Pipe
Clase Pipe
- Transfiere los datos Almacena los datos - Sincroniza los vecinos activos
Colaborador - La fuente de
datos datos - Filter
Responsabilidades - El repositorio de
Figura 4.4 - Clases Pipe y Filter
La fuente de datos representa la entrada al sistema, y provee una secuencia de valores de datos de algn tipo o estructura. Ejemplos de tales fuentes de datos son un archivo que contiene lneas de texto, o un sensor entregando una sucesin de nmeros. El almacenamiento de datos rene los resultados del extremo del pipeline.
Clase
La fuente de datos
Colaborador - Pipe
Clase
El repositorio de datos
Colaborador - Pipe
Responsabilidades
- Entrega la entrada al pipeline para procesar
Responsabilidades
- Consumir la salida
Figura 4.5 - Clases Repositorio y Fuente de datos
La estructura del patrn arquitectnico Pipe and Filter es:

filter pipe filter pipe filter pipe pipe filter pipe pipe pipe filter pipe filter
Figura 4.6 - Estructura Patrn Pipe and Fliter
Consecuencias El patrn Pipes and Filters tiene las siguientes ventajas: o
No son necesarios archivos intermedios, pero es posible su utilizacin. Es posible calcular resultados usando programas separados sin pipes, guardando los resultados intermedios en archivos. El uso de este patrn quita la necesidad de archivos intermedios, pero permite investigar los datos intermedios usando la unin T en el pipeline.
Pag 22

Flexibilidad por el intercambio de filters. Los filters tienen una interfaz simple
que permite su intercambio fcilmente dentro del procesamiento del pipeline.
Flexibilidad por recombinacin. Este es el mayor beneficio, combinado con la
reusabilidad de los componentes filters, permitiendo la creacin de nuevos procesos pipelines reestructurando los filters o agregando uno nuevo. Un pipeline sin una fuente o un almacenamiento de datos puede ser embebido como un filter dentro de un pipeline ms grande. componentes.
o o
Reusabilidad. Permite la recombinacin de filters facilitando el reuso de sus El prototipado rpido de los pipelines. Las Ventajas precedentes hacen esto
ms fcil para el prototipo de un sistema de procesamiento de datos de los filters existentes. Despus que se tiene la implementacin de la funcin del sistema principal usando un pipeline, se puede optimizar incrementalmente. produce y consume datos incrementalmente pueden realizar sus funciones en paralelo.
Eficiencia del procesamiento en paralelo. Si cada filter en un pipeline
Aplicar patrones Pipes and Filters imponen algunas desventajas: o
Compartir el estado de la informacin es caro o poco flexible. Aplicar el patrn Pipes and Filters es ineficiente si las fases de procesamiento necesitan compartir una gran cantidad de datos globales Desventaja en el procesamiento en paralelo. Esto se debe a varias razones:

El costo de transferir datos entre filters puede ser relativamente alto comparado con el costo de realizar cmputos en un solo filter. Algunos filters consumen todas sus entradas antes de producir cualquier salida, Esto puede ser debido a que el filter esta mal codificado.
Manejo de errores. El manejo de errores es una gran debilidad del patrn

Pipes and Filters. Se debera por lo menos definir una estrategia comn para el reporte de errores y usarse a lo largo de todo el sistema.
Ejemplo Unix ha popularizado el paradigma pipe and Filter. El comando shell y la disponibilidad de varios programas filters hacen de Unix un sistema popular. Como un sistema para diseadores de software, tareas frecuentes tales como la compilacin de un programa y la creacin de documentacin son realizadas por pipelines en un sistema Unix tradicional. La flexibilidad de los pipes de Unix hizo del sistema operativo una plataforma conveniente para el reuso binario de programas filters y para la integracin de aplicacin.
Blackboard
El patrn arquitectnico Blackboard es til para los problemas en los cuales no se conoce ninguna estrategia de solucin determinstica. En Blackboard varios subsistemas especializados asocian sus conocimientos para construir una posible solucin parcial o aproximada.
Contexto Un dominio poco definido en el cual no se conoce o no es factible alguna posible solucin concreta. Problema El patrn Blackboard se utiliza para problemas que no tienen una solucin determinstica factible en la transformacin de datos en estructuras de datos de alto nivel. Ejemplos de dominios en los que ocurren tales problemas son visualizacin, reconocimiento de imgenes y reconocimiento de lenguaje. La caracterstica de estos problemas es cuando se necesitan descomponer en subproblemas que requieren varios campos de especializacin. Las soluciones a los subproblemas requieren diferentes representaciones y paradigmas. En muchos casos no existe una estrategia predeterminada de cmo resolver el problema parcial, para ello se debe combinar conocimientos. Cada paso de la transformacin tambin puede generar varias soluciones alternativas. Las siguientes fuerzas influyen en soluciones a los problemas de este tipo: - La bsqueda completa del espacio de solucin no sera factible en un tiempo razonable. - Debido a que el dominio es imperfecto, se podra necesitar experimentar con algoritmos diferentes para la misma subtarea. Hay diferentes algoritmos que resuelven problemas parciales. - La entrada, como tambin resultados intermedios y finales, tienen representaciones diferentes, y los algoritmos se llevan a cabo segn paradigmas diferentes. - Un algoritmo normalmente trabaja sobre los resultados de otros algoritmos. - Datos inciertos y soluciones aproximadas estn relacionados - El empleo de algoritmos separados induce a un potencial paralelismo. De ser posible se debera evitar una solucin estrictamente secuencial. Solucin La idea detrs de la arquitectura Blackboard es una coleccin de programas especializados e independientes que trabajan cooperativamente sobre una estructura de datos comn. Cada programa se especializa en resolver una parte particular de la tarea global, y todos los programas trabajan en conjunto en pos de una solucin. Si bien los programas son independientes unos de otros, la direccin tomada por el sistema es principalmente determinada por el estado de progreso actual que es evaluado por un componente de control central. Durante el proceso problema-solucin el sistema trabaja con soluciones parciales combinadas, cambiadas o rechazadas. Cada una de estas soluciones representa un problema parcial y un cierto estado del proceso de la solucin. El conjunto de todas las soluciones posibles se llama espacio de solucin, y es organizado en niveles de abstraccin. El nivel ms bajo de solucin consiste en una representacin interna de la entrada. Las soluciones potenciales de la tarea del sistema global estn en el nivel ms alto.
Estructura El sistema se divide en un componente llamado pizarra, una coleccin de fuentes de conocimiento, y un componente de control. La pizarra es el almacenamiento central de datos que guarda tambin los elementos del espacio de solucin y el control de datos. Proporciona una interfaz que habilita a todas las fuentes de conocimiento para leer y escribir en ella. Las fuentes de conocimiento son subsistemas separados e independientes que resuelven aspectos especficos del problema global y modelan el dominio del mismo. Ninguno de ellos puede resolver en forma aislada la tarea del sistema -una solucin se construye integrando los resultados de varias fuentes de conocimiento. Ellas slo leen y escriben en la pizarra. Cada fuente de conocimiento es responsable de conocer las condiciones bajo las cuales puede contribuir a una solucin, evaluando el estado actual del proceso de la solucin para determinar si puede hacer una contribucin, y producir un resultado que puede causar un cambio en el contenido de pizarra.
Clase Blackboard Responsabilidades
- Maneja los datos centrales
Colaborador
Clase
Fuente de Conocimiento
Colaborador - Blackboard
Responsabilidades
- Evala su propia pertinencia - Computa un resultado - Actualiza el blackboard
Figura 4.7 - Clases Blackboard y Fuente de Conocimiento
El componente de control ejecuta un loop que monitorea los cambios en la pizarra y decide qu accin tomar luego. Establece las evaluaciones de la fuente de conocimiento y activaciones de acuerdo a una estrategia de aplicacin conocida. La base para esta estrategia es el dato sobre la pizarra, que ayuda a la toma de decisiones de control. Sus resultados se llaman datos de control y tambin se ponen en la pizarra.
Clase
Control - Monitorea el Blackboard - Maneja las activaciones de las fuentes de conocimiento
Colaborador - Blackboard
- Fuente de
Responsabilidades Conocimiento
Figura 4.8 - Clases Control
Tericamente, es posible que la pizarra pueda alcanzar el estado en el cual ninguna fuente de conocimiento es aplicable. En este caso, el sistema falla al entregar un resultado. En la prctica, es ms probable que cada paso de razonamiento introduzca
varias hiptesis nuevas, y que el nmero de posibles prximos pasos explote. El problema es por consiguiente restringir las alternativas a ser tomadas. Una fuente de conocimiento especial o un procedimiento en el componente de control determina cuando el sistema se debe detener, y cual es el resultado final. El sistema se detiene cuando se encuentra una hiptesis aceptable, o cuando finalizan los recursos del sistema de espacio o tiempo.
Fuente de conocimiento Pizarra
Control
Figura 4.9 - Estructura del Patrn Arquitectnico Blackboard
Consecuencias. La forma en que el patrn Blackboard descompone el problema y aplica el conocimiento, aporta las siguientes ventajas: o
Experimentacin. En dominios en que no existe alguna posible solucin y una bsqueda completa del espacio de la solucin no es factible, el patrn Blackboard experimenta con la mayor cantidad posible de algoritmos diferentes, y tambin permite intentar con diferentes heursticas de control. Cambiabilidad y mantenibilidad. La arquitectura Blackboard soporta la
cambiabilidad y mantenibilidad porque las fuentes de conocimiento individuales, el algoritmo de control y la estructura de datos central estn estrictamente separados. tareas. Una arquitectura Blackboard ayuda hacindolas reusables. Los requisitos previos para reusar son que la fuente de conocimiento y el sistema Blackboard subyacente entiendan el mismo protocolo y datos. resultados son slo hiptesis. Slo sobrevivirn aquellas fuertemente soportadas por los datos y otras hiptesis. que son
Reusabilidad. Las fuentes de conocimiento son independientes para ciertas
Tolerancia a fallos y robustez. En una arquitectura Blackboard todos los
El patrn Blackboard tiene algunas desventajas: o
Dificultad de testeo. Los cmputos de este patrn no siguen un algoritmo

determinstico, por lo tanto sus resultados no son a menudo reproducibles. Adems, hiptesis errneas son parte del proceso de solucin.
No se garantiza ninguna buena solucin. Normalmente puede resolver

correctamente slo un cierto porcentaje de las tareas dadas.

Pag 26
Dificultad de establecer una buena estrategia de control. La estrategia de

control no puede disearse de una manera ntegra, y requiere un acercamiento experimental.
o o
Baja eficiencia. Padece el exceso computacional del rechazo de las hiptesis

errneas.
Alto esfuerzo de desarrollo. La mayora de estos sistemas toman aos para
evolucionar. Se atribuye esto a los dominios mal estructurados del problema y una programacin basada en prueba/error para definir estrategias de control y fuentes de conocimiento.
No soporta paralelismo. La arquitectura Blackboard no provee la ejecucin
en paralelo. El acceso concurrente a los datos centrales en la pizarra se debe sincronizar.
Ejemplo Se ha usado tradicionalmente el patrn Blackboard para aplicaciones que requieren complejas interpretaciones de procesamiento de seales, como tambin en sistemas que involucran el acceso compartido a datos con agentes escasamente acoplados. Un ejemplo de uso es un sistema HASP diseado para detectar submarinos enemigos. En este sistema, un hidrfono (dispositivo que captura las ondas acsticas transmitidas en el agua) muestra en el monitor un rea del mar colectando seales sonoras. Un sistema Blackboard interpreta estas seales. El sistema HASP es un sistema basado en eventos en el sentido que la ocurrencia de un evento particular implica que nueva informacin este disponible. La pizarra es usada como una tabla de situacin que evoluciona con el tiempo. Como la informacin se recolecta continuamente, hay informacin redundante como tambin nueva y diferente. HASP trata con mltiples flujos de entrada. Adems el bajo nivel de datos del hidrfono acepta descripciones de alto nivel de la situacin recogida de inteligencia u otras fuentes.
Sistemas Distribuidos
Hoy da, an las pequeas compaas usan sistemas distribuidos. Pero cules son las ventajas de los sistemas distribuidos que los hacen interesantes?
Economa. Redes de computadoras que incorporan PCs y workstations ofrecen una

mejor relacin costo/performance que un mainframe.
Performance y Escalabilidad. Las aplicaciones distribuidas, usan recursos disponibles en

toda la red. La performance puede mejorar enormemente si se utiliza en forma combinada, el poder de cmputo de varios nodos de red. Adems, multiprocesadores y redes son fcilmente escalables. aplicaciones de base de datos en un modelo Cliente-Servidor.
Distribucin inherente. Algunas aplicaciones son naturalmente distribuidas, por ejemplo Fiabilidad. En la mayora de los casos, una mquina en una red o una CPU en un sistema multiprocesador puede dejar de funcionar sin afectar el resto del sistema. Los

Pag 27
nodos centrales como los servidores de archivos son las excepciones a esto, pero puede protegerse con sistemas auxiliares. Los sistemas distribuidos, sin embargo tienen un inconveniente significante, necesitan software totalmente diferente a los sistemas centralizados. Tres modelos relacionados a sistemas distribuidos en esta categora: - El patrn Pipes and Filters mantiene una estructura para sistemas que procesan un flujo de datos. Cada paso del proceso es encapsulado en un componente filter. Los datos son pasados a travs de pipes entre filters adyacentes. La recombinacin de filters permite construir familias de sistemas relacionados. Este patrn se utiliza ms por estructurar la funcionalidad central de una aplicacin que por su naturaleza distribuida, es por ello que lo ubicamos junto al patrn Layers en la clasificacin anterior. El patrn Microkernel se aplica a sistemas de software que tienen la necesidad de adaptar el sistema a requerimientos cambiantes. Este patrn separa la funcionalidad central mnima de la funcionalidad extendida y las partes especficas del cliente. El microkernel tambin sirve como un socket para comunicar estas partes y coordinar su colaboracin. Este patrn es descripto ms adelante en este captulo dentro de la clasificacin de patrones adaptables.
- Los sistemas Microkernel emplean una arquitectura Cliente-Servidor en los cuales clientes y servidores corren sobre el componente microkernel. El mayor beneficio de estos sistemas, est en el diseo apto para la adaptacin y cambio. - El patrn Broker puede usarse para estructurar sistemas de software distribuidos con componentes desarticulados que se comunican mediante invocacin remota de servicios. Un componente broker es responsable de coordinar la comunicacin (remitir las demandas, transmitir los resultados y excepciones).
Broker
El patrn arquitectnico Broker puede usarse para estructurar sistemas de software distribuidos con componentes desacoplados que interactan por invocaciones de servicios remotos. Un componente Broker es responsable de coordinar la comunicacin, remitir las demandas, as como transmitir resultados y excepciones. Contexto El ambiente es un sistema distribuido y posiblemente heterogneo con componentes independientes que cooperan entre s. Problema Construir un sistema de software complejo como un conjunto de componentes desacoplados que interoperan, en lugar de una aplicacin monoltica, los resultados son altamente flexibles, mantenibles y cambiables. Dividiendo la funcionalidad en los componentes independientes del sistema, se torna potencialmente distribuible y escalable. Desde el punto de vista de un diseador, no debe haber ninguna diferencia esencial entre el software en vas de desarrollo para los sistemas centralizados y el desarrollo para un sistema distribuido. Una aplicacin que usa un objeto debera slo
ver la interfaz ofrecida por el objeto. No debera necesitar conocer los detalles de implementacin de un objeto o su ubicacin fsica. Se debe usar la arquitectura Broker para equilibrar las siguientes fuerzas: - Los componentes deberan poder acceder a los servicios proporcionados por otros aunque sean remotos. Las invocaciones de servicios remotos deben ser transparentes respecto de su ubicacin. - Si se necesitase intercambiar, agregar o quitar componentes en tiempo de ejecucin.
-
La arquitectura debera ocultar de los usuarios de componentes y servicios, detalles especficos del sistema e implementacin.
Solucin Introducir un componente broker para lograr una mejor separacin de clientes y servidores. Los servidores se registran con el broker y hacen que sus servicios estn disponibles a los clientes a travs de mtodos de interfaces. Los clientes acceden funcionalmente a los servidores enviando las solicitudes a travs del broker. Las tareas de un broker incluyen localizar al servidor apropiado, remitir la solicitud al servidor y transmitir respuestas y excepciones al cliente. Usando el patrn Broker, una aplicacin puede acceder a servicios distribuidos simplemente enviando mensajes a un objeto apropiado, en lugar de enfocarse en la comunicacin inter-proceso de bajo nivel. La arquitectura Broker tiene la ventaja de ser flexible, lo que le permite realizar cambios en forma dinmica, agregar, eliminar, y reubicar los objetos. El patrn Broker reduce la complejidad involucrada desarrollando las aplicaciones distribuidas, haciendo la distribucin transparente al diseador. Logra esta meta introduciendo un modelo de objeto en el que se encapsulan los servicios distribuidos dentro de los objetos. Estructura El patrn arquitectnico Broker comprende seis tipos de componentes participantes: Un componente servidor que implementa objetos que exponen su funcionalidad a travs de interfaces que consisten en operaciones y atributos. Estas interfaces son realizadas a travs de un lenguaje de definicin de interfaz (IDL). Las interfaces se agrupan por su funcionalidad semnticamente relacionada. Hay dos tipos de servidores:

Servidores que ofrecen los servicios comunes a muchos dominios de aplicacin. Servidores que implementan la funcionalidad especfica por un solo dominio de aplicacin o tarea.
Los componentes clientes son aplicaciones que acceden a los servicios de por lo menos un servidor.
La interaccin entre los clientes y los servidores est basada en un modelo dinmico, el cual posibilita a los servidores poder tambin actuar como clientes. Este modelo de interaccin dinmica difiere de la nocin tradicional de Cliente-Servidor, en el que los roles de clientes y servidores estn estticamente definidos. Desde el punto de vista de una aplicacin se puede considerar a los clientes como aplicaciones y a los servidores como bibliotecas. Note que los clientes no necesitan saber la ubicacin de los servidores a los cuales ellos acceden. Esto es importante porque permite agregar nuevos servicios y mover los servicios existentes a otras ubicaciones, incluso mientras el sistema est corriendo.
Clase Cliente Responsabilidades
- Implementa la funcionalidad del usuario - Enva solicitudes al Server a travs del Proxy del lado del cliente
Colaborador
- Proxy del lado del Cliente
Clase Servidor Responsabilidades

- Implementa los servicios - Se registra a si mismo con el broker local - Enva respuestas y excepciones hacia el cliente a travs del Proxy del lado del servidor
Colaborador
- Proxy del lado del Servidor
- Broker
- Broker
Figura 4.10 - Clases Cliente y Servidor
El componente broker es responsable de la transmisin de solicitudes de los clientes a los servidores, como de la transmisin de respuestas y excepciones al cliente. Tambin debe tener alguna forma de localizar al receptor de una solicitud basada en su nico identificador del sistema. Un broker ofrece APIs a los clientes y a los servidores para que incluyan operaciones para registrar y para invocar los mtodos del servidor. Cuando una solicitud llega a un servidor que es mantenida por el broker local, ste pasa la solicitud directamente al servidor. Si el servidor esta actualmente inactivo, el broker lo activa. Todas las respuestas y excepciones de la ejecucin de un servicio son remitidas por el broker al cliente que envi la solicitud. Si el servidor especificado es direccionado por otro broker, el broker local encuentra una ruta al broker remoto y enva la solicitud usando esta ruta. Dependiendo de los requisitos de todo el sistema, se puede integrar en el broker servicios adicionales, tal como los servicios de nombre o soporte de marshaling.
Clase Broker Responsabilidades
- Registra y da de baja servidores. - Ofrece APIs. - Transfiere mensajes. - Se recupera de errores. - Interopera con otros brokers a travs de los puentes. Localiza servidores
Colaborador
- Cliente - Servidor - Proxy del lado del cliente - Proxy del lado del servidor - Puente
Figura 4.11 - Clase Broker

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

El mecanismo de comunicacin inter-procesos usados para transferencia de mensaje entre clientes y broker. La creacin y eliminacin de bloques de memoria. El marshaling de parmetros y resultados.
Cuando se retorna los resultados o excepciones desde un servidor, el proxy del lado del cliente recibe el mensaje entrante desde el broker, realiza el unmarshaling de los datos y lo enva al cliente. Los componentes proxies del lado del servidor son generalmente anlogos a los proxies del lado del cliente. La diferencia es que son responsables de la recepcin de las solicitudes, desempaquetar los mensajes entrantes, realizar el unmarshaling de los parmetros, y llamar al servicio apropiado. Adems se usan para realizar el marshaling de los resultados y excepciones antes de enviarlos al cliente.
Clase Proxy del lado del Cliente Responsabilidades
- Encapsula funcionalidad especifica del sistema - Media entre el cliente y el broker
Colaborador
- Cliente - Broker
Clase Proxy del lado del Servidor Responsabilidades

- Llama a los servicios con/en el servidor - Encapsula funcionalidad especifica del sistema - Media entre el Servidor y el broker
Colaborador
- Servidor - Broker
Figura 4.12 - Clases Proxy del lado del Cliente y Proxy del lado del Servidor.
Los componentes bridges son componentes opcionales usados para ocultar los detalles de implementacin cuando dos broker nter-operan en una red heterognea. Si se transmiten las solicitudes sobre la red, los diferentes brokers tienen que comunicarse independientemente del uso de redes y sistemas operativos diferentes. Un bridge construye una capa que encapsula todos estos detalles especficos del sistema. Este responde a un patrn de diseo cuya descripcin se hace en el captulo siguiente.
Clase
Bridge
Colaborador - Broker
- Bridge
Responsabilidades
- Encapsula la funcionalidad de una red especifica - Media entre el broker local y el bridge de un broker remoto
Figura 4.13 - Clase Bridge.

Pag 31
Hay dos tipos diferentes de sistemas Broker: aquellos que usan comunicacin directa y aquellos que usan comunicacin indirecta. Para lograr una buena performance, algunas implementaciones broker establecen slo el enlace de comunicacin inicial entre un cliente y un servidor, mientras el resto de la comunicacin se hace directamente entre los componentes participantes -mensajes, excepciones y respuestas son transferidas entre proxies del lado del cliente y proxies del lado del servidor sin usar al broker como una capa intermedia. Esta comunicacin implica que requerimientos de los servidores y clientes usen y entiendan el mismo protocolo.
Proxy del lado del cliente
Broker
Proxy del lado del Servidor
Cliente
Bridge
Servidor
Figura 4.14 - Estructura del patrn Broker
Consecuencias El patrn arquitectnico Broker tiene algunas ventajas importantes: o
Transparencia. Como el broker es responsable de localizar un servidor usando un nico identificador, los clientes no necesitan saber dnde se localizan los servidores. De igual forma, los servidores no se preocupan de la ubicacin de los clientes que les realizan requerimientos ya que ellos reciben todas las solicitudes del componente broker local. Cambiabilidad y extensibilidad. Si los servidores cambian pero sus interfaces permanecen iguales, no tiene impacto funcional en los clientes. Modificando la implementacin interior del broker pero no las APIs que l provee, no tiene otro efecto en los clientes y servidores ms que cambios en la performance. El uso de proxies y bridges es una razn importante para facilitar la implementacin de cambios.
sistema de red a clientes y servidores usando capas de indireccin como las APIs, proxies y bridges. Cuando se requiere usar puertos es suficiente en la mayora de los casos poner el puerto en el componente broker y sus APIs en una nueva plataforma y recompilar a los clientes y servidores, en estos casos, se recomienda estructurar los componentes del broker en capas
Portabilidad. El sistema Broker oculta detalles del sistema operativo y del
Interoperabilidad. Diferentes
sistemas Broker pueden interoperar si entienden un protocolo comn para el intercambio de mensajes. Este protocolo es interpretado y manejado por bridges que son los responsables de traducir el protocolo especfico del broker en el protocolo comn y viceversa. basadas en la funcionalidad de la aplicacin en servicios existentes.
Reusabilidad. Al construir nuevas aplicaciones clientes, frecuentemente estn

Pag 32
El patrn arquitectnico Broker impone algunas desventajas:

o
Eficiencia restringida. Aplicaciones que usan una implementacin Broker son
normalmente ms lentas que las aplicaciones cuya distribucin del componente es esttica y conocida. Sistemas que dependen directamente de un mecanismo concreto para la comunicacin interproceso dan mejor performance que una arquitectura Broker, porque el broker introduce capas de indireccin que permite ser portable, flexible y cambiable. distribuido, un sistema Broker puede ofrecer menos tolerancia a fallos. En caso que un servidor o un broker falle durante la ejecucin de un programa, todas las aplicaciones que dependen del servidor o el broker son incapaces de continuar con xito. Se puede aumentar la fiabilidad a travs de la replicacin de componentes.
Baja tolerancia a fallos. Comparado con un sistema de software no
El siguiente aspecto da ventajas as como tambin desventajas:

o
Testing y debugging. Una aplicacin cliente desarrollada de servicios

probados es ms robusta y fcil de testear. Sin embargo, realizar el testeo y la depuracin de un sistema Broker es un trabajo tedioso debido a la cantidad de componentes involucrados.
Ejemplo El patrn arquitectnico Broker es utilizado para especificar la arquitectura CORBA. CORBA es una tecnologa orientada a objetos para objetos distribuidos sobre sistemas heterogneos. Un lenguaje de definicin de interfaz esta disponible para soportar la interoperabilidad de objetos clientes y servidores.
Sistemas Interactivos
Los sistemas actuales permiten un grado alto de interaccin del usuario, generalmente, con la ayuda de interfaces de usuario grficas. El objetivo es robustecer la utilidad de una aplicacin. Estos sistemas proporcionan un acceso conveniente a sus servicios, lo cual permite a los usuarios aprender la aplicacin y producir resultados rpidamente. Al especificar la arquitectura de tales sistemas, el desafo es mantener la funcionalidad central independiente de la interfaz de usuario. El centro de los sistemas interactivos esta basado en los requerimientos funcionales del sistema, y normalmente permanece estable. Las interfaces de usuario, sin embargo, estn sujetas a cambio y modificacin. Por ejemplo, es probable que se requiera a los sistemas contar con diferentes interfaces de usuario, o interfaces que deben ajustarse para articular en los procesos de negocio de un cliente. Estas arquitecturas requieren que las interfaces de usuario puedan ser modificadas sin causar efectos en la funcionalidad de una aplicacin especfica o al modelo de datos. Se describen dos patrones que brindan una organizacin estructural fundamental para software de sistemas interactivos:

Pag 33
- El patrn Model-View-Controller (MVC) divide una aplicacin interactiva en tres componentes. El modelo contiene la funcionalidad central y los datos. Las vistas despliegan el informacin al usuario. Los controladores se ocupan de las entradas del usuario. Las vistas y controladores juntos forman la interfaz de usuario. Un mecanismo de propagacin de cambios asegura la consistencia entre la interfaz de usuario y el modelo. - El patrn Presentation-Abstraction-Control (PAC) define una estructura para los sistemas interactivos en forma de una jerarqua de agentes de cooperantes. Cada agente es responsable de un aspecto especfico de la funcionalidad de la aplicacin y consiste de tres componentes: presentacin, abstraccin y control. Esta subdivisin separa los aspectos de interaccin de hombre-computadora de los agentes de su centro funcional y su comunicacin con otros agentes. MVC brinda probablemente la ms conocida organizacin arquitectnica para los sistemas de software interactivos. PAC es una alternativa para estructurar aplicaciones interactivas, y sobre todo aplicable a sistemas que cuentan con varios subsistemas confiados en si mismo. Tambin dirige problemas que MVC deja sin resolver, tal como organizar eficazmente la comunicacin entre diferentes partes de la funcionalidad central y la interfaz de usuario.
Model-View-Controller
El patrn arquitectnico Model-View-Controller (MVC) divide una aplicacin interactiva en tres componentes. El Modelo contiene la funcionalidad central y los datos, las Vistas despliegan la informacin al usuario y los Controladores manejan la entrada del usuario. Estos dos ltimos componentes, en conjunto, forman la interfaz del usuario. Un mecanismo de propagacin de cambio asegura la consistencia entre la interfaz del usuario y el modelo. Contexto Aplicaciones interactivas con una interfaz de usuario flexible. Problema Las interfaces del usuario son especialmente propensas a cambios en los requerimientos. Un cliente puede requerir una adaptacin especfica de la interfaz. Diferentes usuarios pueden definir requisitos contradictorios sobre la interfaz de usuario en base a sus necesidades. Un data entry ingresa la informacin a travs del teclado. Un gerente quiere usar el mismo sistema pulsando iconos y botones. En consecuencia, se debe contar con distintas interfaces de usuario para los mismos datos. Construir un sistema con la flexibilidad requerida es caro y propenso errores, si la interfaz de usuario se entreteje hermticamente con el centro funcional. Esto puede producir la necesidad de desarrollar y mantener varios sistemas de software substancialmente diferentes, uno para cada implementacin de interfaz de usuario ya que los cambios resultantes se distribuyen por muchos mdulos.

Pag 34
Las siguientes fuerzas influyen en la solucin: - La misma informacin es presentada en forma diferente en diferentes vistas. - Los cambios en los datos se deben reflejar inmediatamente en las vistas y el comportamiento. - Los cambios a la interfaz del usuario deben ser fciles, e incluso posibles en tiempo de ejecucin. Solucin La separacin de los componentes modelo, vista y controlador, permiten mltiples vistas del mismo modelo. Si el usuario cambia el modelo a travs del controlador de una vista, se deben reflejar los cambios en todas las otras vistas que dependen de esos datos. El modelo notifica a todas las vistas siempre que sus datos hayan cambiado. Las vistas recuperan los nuevos datos del modelo y actualizan la informacin mostrada. Estructura El Model-View-Controller (MVC) divide una aplicacin interactiva en tres reas: procesamiento, entrada y salida. El modelo encapsula los datos centrales y tiene la funcionalidad de la aplicacin. Es un componente totalmente independiente de las representaciones especficas de salidas o del comportamiento de la entrada. Los controladores reciben la entrada, normalmente como eventos que codifican los movimientos del mouse o entrada del teclado. Los eventos son traducidos para servir a las demandas del modelo o las vistas. El usuario interacta con el sistema solamente a travs de los controladores. Diferentes vistas presentan la informacin del modelo al usuario de distintas maneras. Pueden existir mltiples vistas de un mismo modelo, pero cada vista tiene una relacin uno a uno con un controlador. Cada vista define un procedimiento de actualizacin que se activa por el mecanismo de propagacin de cambios. Cuando es llamado el procedimiento de actualizacin, una vista recupera los valores de datos actuales del modelo para ser mostrados, y los pone en la pantalla El mecanismo de propagacin de cambios mantiene un registro de los componentes dependientes dentro del modelo. Todas las vistas y controladores seleccionados indican en el registro que necesitan actualizar sobre los cambios producidos. Cualquier cambio de estado del modelo hace que se active el mecanismo de propagacin de cambios y se propaguen las modificaciones en cada componente del sistema. Este mecanismo es el nico eslabn entre el modelo, las vistas y los controladores.

Pag 35
Clase
Modelo
Colaborador
- Vista - Controlador
Responsabilidades
- Provee la funcionalidad central de la aplicacin - Se registran vistas y controladores dependientes - Notifica a los componentes dependientes de los cambios
Figura 4.15 - Clase Modelo
Durante la inicializacin todas las vistas son asociadas con el modelo y registradas por el mecanismo de propagacin de cambios. Cada vista crea su controlador. Las vistas ofrecen a menudo funcionalidad que permite a los controladores manejar la forma en que se muestran los datos. Esto es til para operaciones de usuarios activos que no afectan al modelo, como es hacer un scroll. Los controladores aceptan la entrada del usuario como eventos. Depende de la plataforma de la interfaz del usuario la forma en que estos eventos se entregan al controlador. Los eventos se traducen en las demandas para el modelo o la vista asociada. Si la conducta de un controlador depende del estado del modelo, se registra con el mecanismo de propagacin de cambios e implementa un procedimiento de actualizacin.
Clase
Controlador
Colaborador
- Vista - Modelo
Clase Vista Responsabilidades

- Crea e inicializa su controlador asociado - Muestra la informacin al usuario - Implementa los procedimientos de actualizacin - Recupera los datos desde el Modelo
Responsabilidades
- Acepta las entradas del usuario como eventos - Traduce eventos a solicitudes para el modelo o muestra solicitudes para la vista - Implementa la actualizacin
Colaborador - Vista - Modelo
Figura 4.16 - Clases Controlador y Vista
La integracin de los componentes en este patrn es

Vista Controlador
Modelo
Figura 4.17 - Estructura del Patrn MVC
Consecuencias La aplicacin Model-View-Controller tiene varias ventajas: o componentes de la interfaz de usuario. Mltiples vistas pueden ser implementadas y usadas con un simple modelo.
Pag 36
Mltiples vistas del mismo modelo. MVC separa al modelo de los

Vistas sincronizadas. El mecanismo de propagacin de cambios del modelo asegura que todos los observadores registrados son notificados de los cambios en los datos de la aplicacin, en el momento correcto. Esto sincroniza todas las vistas y controladores dependientes. Cambios en vistas y controladores. La separacin conceptual de MVC permite
intercambiar los objetos de las vistas y los controladores de un modelo incluso en tiempo de ejecucin. interfaz de usuario, exportar una aplicacin MVC a una nueva plataforma no afectara la funcionalidad central de la aplicacin, solo es necesario la implementacin conveniente para esa plataforma, de los componentes vistas y controladores. este patrn.
Cambiabilidad. Como el modelo es independiente de todo el cdigo de la
El potencial del framework. Es posible basar una aplicacin framework en
Las desventajas de MVC son: o
Incremento de la complejidad. Seguir estrictamente la estructura MVC, no siempre es la mejor manera de construir una aplicacin interactiva. Tambin se sostiene que el uso de los componentes separados del modelo, la vista y el controlador para los mens y los elementos de texto simples implica un aumento de la complejidad sin ganar mucha flexibilidad. Excesivos nmero de actualizaciones. Si una sola accin del usuario implica
varias actualizaciones, el modelo debe pasar por alto las notificaciones intermedias innecesarias de los cambios dado que no todas las vistas estn interesadas en que el modelo propague cada una de las modificaciones.
Conexin entre vistas y controladores. Controladores y vistas son
componentes separados pero estrechamente relacionados que impiden su rehso individual. Es improbable que una vista sea usada sin su controlador, o viceversa, con la excepcin de vistas de slo lectura que comparten un controlador que ignore todas las entradas.
Acoplamiento de vistas y controladores con un modelo. Los componentes

vista y controlador hacen llamadas directas al modelo. Esto implica que cambios en la interfaz del modelo probablemente rompan el cdigo de vista y controlador. Este problema se magnifica si el sistema usa mltiples vistas y controladores.
Ineficacia en la vista para acceder a los datos. Dependiendo de la interfaz
del modelo, una vista puede necesitar hacer mltiples llamadas al modelo para obtener todos los datos a mostrar. Solicitar innecesariamente al modelo datos inalterados debilita la performance si las actualizaciones son frecuentes. Guardando en cach los datos dentro de la vista, mejora la performance.
Ejemplo El patrn MVC se ve frecuentemente en aplicaciones interactivas, como por ejemplo, en un editor grfico.
Presentation-Abstraction-Control
El patrn arquitectnico Presentation-Abstraction-Control (PAC) define una estructura para los sistemas de software interactivos en forma de jerarqua de agentes cooperantes. Cada agente es responsable de un aspecto especfico de la funcionalidad de la aplicacin y tiene tres componentes: presentacin, abstraccin, y control. Esta subdivisin separa los aspectos de interaccin usuario-computadora del agente central funcional y su comunicacin con otros agentes. Contexto El desarrollo de una aplicacin interactiva con ayuda de agentes. Problema Los sistemas interactivos pueden verse a menudo como un conjunto agentes cooperantes. Como ser, agentes especializados en la interaccin usuario-computadora que aceptan la entrada del usuario y el despliegue de los datos, ms otros agentes que mantienen el modelo de datos del sistema y ofrecen funcionalidad que opera sobre esos datos y, adems, otros agentes adicionales responsables de las diversas tareas como el manejo de errores o la comunicacin con otros sistemas de software. En esta arquitectura de cooperacin de agentes, cada agente se especializa en una tarea especfica, y todos juntos proporcionan la funcionalidad del sistema. Las fuerzas siguientes afectan la solucin: Los agentes a menudo mantienen su propio estado y datos. Los agentes individuales deberan cooperar eficazmente para proporcionar la tarea global de la aplicacin. Para lograr esto, se necesitara un mecanismo de intercambio de datos, mensajes, y eventos. Los agentes interactivos deberan proporcionar su propia interfaz de usuario, debido a que las interacciones usuario-computadora difieren a menudo ampliamente. Los sistemas evolucionan con el tiempo. El aspecto de la presentacin es particularmente propenso cambios. Los cambios de agentes individuales, o la extensin del sistema con nuevos agentes, no deberan afectar a todo el sistema.
Solucin La estructura de una aplicacin interactiva es como un rbol de jerarqua de agentes PAC. Cada agente es responsable de un aspecto especfico de la funcionalidad de la aplicacin, y consiste en tres componentes: presentacin, abstraccin y control. La jerarqua entera refleja las dependencias transitivas entre agentes. Cada agente depende de todos los agentes de niveles ms altos y as hasta llegar al agente de nivel superior. Cada componente de un agente PAC tiene una tarea especfica:

El componente presentacin proporciona la conducta visible del agente. El componente abstraccin mantiene el modelo de datos que fundamenta al agente y proporciona la funcionalidad para operar sobre esos datos.
Pag 38

El componente control conecta los componentes presentacin y abstraccin, y proporciona la funcionalidad de comunicacin con otros agentes.
Debe haber agentes de nivel superior, algunos agentes de nivel intermedio y ms aun agentes de nivel inferior. El agente PAC de nivel superior proporciona el centro funcional del sistema, adems incluye las partes de la interfaz del usuario que no pueden ser asignadas a subtareas particulares. Los agentes PAC de nivel medio representan cualquier combinacin o relacin entre los agentes de niveles ms bajos. Por ejemplo un agente de este nivel puede mantener varias vistas de los mismos datos. Los agentes PAC de nivel inferior representan su propio contenido semntico de los conceptos en los cuales los usuarios del sistema pueden actuar, como las hojas de clculo o grficos permitiendo a los usuarios realizar acciones sobre estos. Estructura La responsabilidad principal del agente PAC de nivel superior es habilitar el modelo de datos global del software, mediante la funcionalidad de sus componentes: - El componente presentacin tiene a menudo pocas responsabilidades. Puede incluir los elementos de interfaz del usuario comn a toda la aplicacin. - La interfaz del componente abstraccin ofrece funciones para manipular el modelo de los datos y para recuperar su informacin. - El componente control tiene tres responsabilidades:
Permite a los agentes de nivel inferior hacer uso de los servicios de los agentes de nivel superior, principalmente acceder y manipular el modelo global de datos. Coordina y mantiene la informacin de la jerarqua de agentes PAC. El componente control usa esta informacin para asegurarse de la correcta colaboracin e intercambio de datos entre agente de nivel superior e inferior. Mantiene la informacin sobre la interaccin del usuario con el sistema.
Los agentes PAC de nivel inferior representan un concepto semntico especfico del dominio de la aplicacin, tambin pueden implementar servicios del sistema. Este concepto semntico puede ser de tan bajo nivel como un objeto grfico simple. La funcionalidad de sus componentes es: - El componente presentacin muestra una vista especfica del concepto semntico correspondiente, y proporciona acceso a todas las funciones de usuario que l puede brindar. - El componente abstraccin mantiene agentes especficos de datos, pero ningn otro agente PAC depende de estos datos. - El componente control mantiene la consistencia entre los otros dos componentes.

Pag 39
Estos componentes se comunican con los agentes de alto nivel para intercambiar eventos y datos. Los eventos entrantes son remitidos al componente presentacin del agente de nivel inferior, mientras que los datos entrantes se remiten a su componente abstraccin. Los eventos y datos de salida, por ejemplo los mensajes del error, son enviados a un agente de nivel superior asociado. Los agentes PAC de nivel intermedio pueden cumplir dos papeles diferentes: composicin y coordinacin entre el agente de nivel inferior, por ejemplo al coordinar mltiples vistas de los mismos datos. Sus componentes deben:

mantener los datos especficos del agente, en caso del componente abstraccin, el componente presentacin, implementar su interfaz de usuario y el componente control, tener las mismas responsabilidades que los componentes control de los agentes de nivel inferior y nivel superior.
Clase Agente de nivel Colaborador superior - Agente de nivel Responsabilidades - Agente de nivel
- Proveer la funcionalidad central del sistema - Controlar la jerarqua PAC Inferior Intermedio
Clase Agente de
nivel Intermedio
Colaborador - Agente de nivel

superior - Agente de nivel Intermedio - Agente de nivel Inferior
Responsabilidades
- Controlar los agentes PAC de niveles mas bajos . - Compone a los agentes PAC de nivel mas bajo en simples unidades de abstraccin superior
Clase Agente de nivel Colaborador Inferior - Agente de nivel Responsabilidades - Agente de nivel
- Proveer una vista especifica del software o un servicio del sistema, incluyendo su interaccin humanocomputadora asociada. Intermedio superior
Figura 4.18 - Clases de los Agentes PAC.
Si observamos la integracin de los componentes PAC con su correspondiente estructura interna

Pag 40
Presentacin Control
Abstraccin Agentes de Nivel Superior
Presentacin Control
Abstraccin
Presentacin Control
Abstraccin Agentes de Nivel Intermedio
Presentacin Control
Abstraccin
Presentacin Control
Abstraccin
Presentacin Control
Abstraccin Agentes de Nivel Inferior
Figura 4.19 - Integracin de clases de los Agentes PAC.
Consecuencias El patrn arquitectnico Presentation-Abstraction-Control tiene varias ventajas: o
Separar intereses. Agentes separados representan diferentes conceptos semnticos en el dominio de la aplicacin. Cada agente mantiene su propio estado y datos en forma coordinada e independiente de otro agente. Cambiabilidad y extensibilidad. Los cambios dentro de los componentes
presentacin o abstraccin de un agente no afectan a otros agentes en el sistema. Esto permite modificar individualmente el modelo de datos que est debajo de un agente o cambiar su interfaz de usuario. Nuevos agentes se integran fcilmente en una arquitectura PAC existente sin mayores cambios para el resto. Todos ellos se comunican entre s a travs de una interfaz predefinida.
Multitarea. Los agentes pueden distribuirse fcilmente en diferentes hilos, procesos, o mquinas.
Las desventajas de este patrn son las siguientes: o
Incremento en la complejidad del sistema. La implementacin de cada

concepto semntico dentro de una aplicacin como su propio agente, puede resultar en una estructura compleja del sistema.
Complejidad en el componente control. Los componentes control son los
mediadores de la comunicacin entre los otros dos componentes de un agente, y entre los diferentes agentes. La calidad de la implementacin del componente control es, por consiguiente, crucial para una colaboracin eficaz entre agentes, y para la calidad global de la arquitectura del sistema. impactar en la eficacia del sistema. Por ejemplo, si un agente de nivel inferior recupera los datos del agente de nivel superior, todos los agentes del nivel intermedio de la jerarqua PAC estarn involucrados en este intercambio de datos.
Decremento en la eficacia. El costo de comunicaciones entre agentes puede

Pag 41
Ejemplo Considerar un sistema de informacin de censos que permite observar el crecimiento demogrfico con representaciones proporcionales. Este ofrece una hoja de clculos para el ingreso de los datos y varias formas de tablas y grficos para representar las regiones. Los usuarios interactan con el software a travs de interfases grficas. Sin embargo, diferentes versiones adaptan la interfaz del usuario segn sus necesidades especficas. Por ejemplo una versin soporta la asignacin de recursos dependiendo de las necesidades de cada regin. Por lo tanto, en este ejemplo se puede definir un agente PAC de nivel superior que provea el acceso al almacenamiento de datos subyacente del sistema. El almacenamiento de datos por si mismo no es parte de la aplicacin. Para realizar el nivel inferior se especifican cuatro agentes de PAC: un agente de la hoja de clculo para los datos de entrada y tres agentes de vista para cada tipo de diagrama para representar los datos. La aplicacin tiene un agente PAC intermedio que coordina a los tres agentes de vista del nivel inferior y los mantiene consistentes. El agente de la hoja de clculo se conecta directamente al agente PAC de nivel superior. Los usuarios del sistema slo interactan con los agentes de nivel superior.
Sistemas Adaptables
Los sistemas evolucionan con el tiempo - se agrega nueva funcionalidad y los servicios van cambiando. Ellos deben soportar nuevas versiones de operar sistemas operativos, otras plataformas, otras interfases de usuarios y bibliotecas. Puede ser necesario adaptarlos a nuevos estndares o plataformas. Tambin puede ser necesario proporcionar servicios que difieran de un cliente a otro. Disear para cambios es, por consiguiente, la mayor preocupacin al especificar la arquitectura de un sistema de software. Una aplicacin debe soportar su propia modificacin y extensin a priori. Los cambios no deberan afectar la funcionalidad central, o diseos de abstraccin claves, por otra parte el sistema debe ser fcil de mantener y sencillo para adaptarlo a requisitos cambiantes. En esta seccin se describen dos modelos que ayudan al diseo para sistemas que se adaptan al cambio: - El patrn Microkernel se aplica a los sistemas de software que deben adaptarse a requisitos cambiantes del sistema. Separa la funcionalidad central mnima de la funcionalidad extendida y las partes especficas de los clientes. El microkernel tambin sirve como socket para conectar extensiones y coordinar sus colaboraciones. - El patrn Reflection provee un mecanismo para estructuras cambiantes y conductas dinmicas de sistemas de software. Apoya la modificacin de aspectos fundamentales, como el tipo de estructuras y mecanismos de llamadas a funcin. En este patrn, una aplicacin es dividida en dos partes. Un meta nivel que proporciona informacin sobre las propiedades seleccionadas del sistema y un nivel base que incluye la lgica de la aplicacin. Su aplicacin se construye sobre el meta nivel. Los cambios a la informacin contenidos en el meta nivel, afectan al comportamiento del nivel base.
Microkernel
El patrn arquitectnico Microkernel se aplica a los sistemas de software que pueden adaptarse a cambios en los requerimientos. ste separa una funcin mnima central de la funcionalidad extendida y partes especficas del cliente. El microkernel tambin sirve como un socket para conectar estas extensiones y coordinar su colaboracin. Contexto El desarrollo de varias aplicaciones usando interfaces de programacin similares que cuentan con la misma funcionalidad central. Problema Desarrollar un software para un dominio de aplicacin que necesita cubrir un gran espectro de estndares y tecnologas similares es una tarea no trivial. Los ejemplos ms conocidos son las plataformas de la aplicacin como los sistemas operativos e interfaces de usuario grficas. Las siguientes fuerzas necesitan particular atencin al disear tales sistemas: - La plataforma de aplicacin debera cubrir una continua evolucin del hardware y software. - La plataforma de aplicacin debera ser portable, extensible y adaptable para permitir una fcil integracin de tecnologas emergentes. - Las aplicaciones podran ser categorizadas en grupos que usan la misma funcionalidad central de formas diferentes, requiriendo de la plataforma subyacente de aplicacin para emular los estndares existentes. - La funcin central de la plataforma de aplicacin debera separarse en un componente con tamao de memoria mnimo, y servicios que consuman la menor cantidad de posible procesamiento. Solucin Encapsular los servicios fundamentales de la plataforma de aplicacin en un componente Microkernel. El microkernel incluye la funcionalidad que habilita a otros componentes que corren en procesos separados a comunicarse entre s y tambin es responsable de mantener los recursos del sistema tales como archivos o procesos. Adems, proporciona interfaces que permiten a otros componentes acceder a su funcionalidad. La funcionalidad central que no puede ser implementada dentro del microkernel sin aumentar su tamao o complejidad innecesariamente se debe separar en servidores internos. Los servidores externos implementan su propia vista del microkernel subyacente. Para construir esta vista, usan las interfaces del microkernel. Cada servidor externo es un proceso separado que representa una plataforma de aplicacin. Los clientes se comunican con servidores externos usando medios de comunicacin proporcionados por el microkernel.
Un sistema Microkernel puede verse como una plataforma de aplicacin que integra otras plataformas de aplicacin. Estructura El patrn Microkernel define cinco tipos de componentes participantes: El microkernel representa el componente principal del patrn. ste implementa servicios centrales como los medios de comunicacin o el mantenimiento, control y coordinacin de recursos como procesos y archivos. Otros componentes cuentan con todos o algunos de estos servicios bsicos, esto lo hacen indirectamente usando una o ms interfaces que comprenden la funcionalidad expuesta por el microkernel. Adems el componente microkernel encapsula muchas dependencias especficas del sistema. Los clientes slo ven las vistas particulares del dominio de la aplicacin subyacente y de la plataforma especfica.
Clase Microkernel Responsabilidades
- Provee los mecanismos centrales - Ofrece facilidades de comunicacin - Encapsula sistemas dependientes - Maneja y controla los recursos
Colaborador - Servidor Interno
Figura 4.20 - Clase Microkernel
Un servidor interno representa un componente separado que extiende la funcionalidad provista por el microkernel por medio de las demandas de servicio. Estos servidores slo son accesibles por el microkernel. Los servidores internos pueden encapsular algunas dependencias sobre el hardware subyacente o sistema de software.
Clase
Servidor Interno
Colaborador
- Microkernel
Responsabilidades
- Implementa servicios adicionales - Encapsula algunos sistemas especficos
Figura 4.21 - Clase Servidor Interno
Un servidor externo es un componente que usa el microkernel para implementar su propia vista del dominio de aplicacin subyacente. Diferentes servidores externos implementan polticas diferentes para dominios de aplicacin especficos. Los servidores externos exponen su funcionalidad exportando interfaces de la misma manera que lo hace el propio microkernel. Cada uno de estos servidores corre en un proceso separado. Recibe solicitudes de servicio de aplicaciones del cliente, interpreta estas solicitudes, ejecuta los servicios apropiados y retorna los resultados a los clientes.
Clase
Servidor Externo
Colaborador
- Microkernel
Responsabilidades
- Mantiene las interfases programadas de los clientes - Encapsula algunos sistemas especficos
Figura 4.22 - Clase Servidor Externo
Un cliente es una aplicacin que est asociada con solo un servidor externo, y solamente accede a la interfaz de programacin que ste le proporciona. Los adaptadores representan interfaces entre los clientes y sus servidores externos, y les permite a los clientes acceder a los servicios del servidor de una manera portable. Ellos son parte del espacio de direccin del cliente. Los adaptadores tambin protegen a los clientes de los detalles de implementacin especficos del microkernel.
Clase Cliente Responsabilidades
- Representa a una aplicacin
Colaborador - Adapter
Clase Adapter Responsabilidades

- Ocultan al cliente dependencias del sistema tales como los mecanismos de comunicacin - Invoca mtodos del servidor externo en nombre de los clientes
Colaborador
- Servidor Externo - Microkernel
Figura 4.23 - Clases Cliente y Adapter
El siguiente diagrama muestra la estructura esttica de un sistema Microkernel. El componente microkernel colabora el servidor externo, el servidor interno y adaptadores. Cada cliente es asociado con un adaptador usado como un bridge entre el cliente y el servidor externo. El servidor interno es solo accesible por el componente microkernel.
Servidor Externo llama Microkernel activa Servidor Interno
Inicializa comunicacion enva requerimientos Adapter llama servicios Cliente
Figura 4.24 - Estructura de un sistema Microkernel
Consecuencias El patrn de Microkernel ofrece algunas ventajas importantes:

Pag 45
Portabilidad. Ofrece un alto grado de portabilidad por dos razones:

En la mayora de los casos no se necesita servidores externos o aplicaciones clientes portables si se traslada el sistema Microkernel a un nuevo ambiente de software o hardware. La migracin del microkernel a un nuevo ambiente de hardware solamente requiere modificaciones en las partes dependientes del hardware.
Flexibilidad y Extensibilidad. Para implementar una vista adicional, se agrega
un nuevo servidor externo. Para extender el sistema con capacidades adicionales solo requiere la suma o extensin de servidores internos.
Separacin de poltica y mecanismo. Proporciona todos los mecanismos necesarios para habilitar a los servidores externos a implementar sus polticas, lo provoca que aumento en la mantenibilidad y cambiabilidad de todo el sistema. Adems, permite agregar nuevos servidores externos que implementen sus propias vistas especializadas. Escalabilidad. Un sistema Microkernel distribuido es aplicable al desarrollo de
sistemas operativos o sistemas de base de datos para redes de computadora, o multiprocesadores con memoria local. Si el sistema Microkernel trabaja sobre una red de mquinas, cuando se agrega una nueva mquina a la red, es sencillo escalar el sistema Microkernel a la nueva configuracin.
Fiabilidad. Para lograr fiabilidad se requiere disponibilidad y tolerancia a fallos. Esta arquitectura permite correr el mismo servidor en ms de una mquina, incrementando la disponibilidad y la tolerancia a fallos de una mquina o servidor.
distribuirse sobre una red de mquinas. En dicha configuracin, la arquitectura Microkernel permite a cada componente acceder a otros componentes sin necesidad de conocer su ubicacin.
Transparencia. En un sistema distribuido los componentes pueden
La arquitectura Microkernel tambin tiene las siguientes desventajas: o o
Performance. La performance es menor que la de un sistema del software

monoltico diseado para ofrecer una vista especfica.
Complejidad de diseo e implementacin. Desarrollar un sistema Microkernel
es una tarea no trivial. Adems, la separacin entre los mecanismos y las polticas requieren el conocimiento del dominio en profundidad y un esfuerzo considerable durante el anlisis y el diseo.
Ejemplo Por ejemplo si necesitramos un sistema operativo que se pueda portar a otro hardware, y que ejecute programas escritos para sistemas operativos populares existentes (Unix, Windows), podramos aplicar este patrn.

Pag 46
Reflection
El Patrn arquitectnico Reflection provee un mecanismo para estructura cambiante y conducta dinmica de sistemas de software. Soporta la modificacin de aspectos fundamentales como los tipos de estructuras y mecanismos de llamada a funcin. En este patrn, una aplicacin es dividida en dos partes: un meta nivel que provee informacin sobre las propiedades del sistema seleccionadas y un nivel base que incluye la lgica de la aplicacin. La implementacin se construye en el meta nivel. Los cambios en la informacin contenida en el meta nivel afectan la conducta del nivel base subsiguiente. Contexto Construccin de Sistemas que soportan su propia modificacin a priori. Problema Los sistemas del software evolucionan con el tiempo. Deben estar abiertos a modificaciones en respuesta a cambios tecnolgicos y de requerimientos. Disear un sistema que encuentre un amplio rango de diferentes requisitos a priori puede ser una tarea ardua. Una buena solucin es especificar una arquitectura que est abierta a la modificacin y extensin. El sistema resultante puede entonces adaptarse a los cambios en los requisitos bajo demanda. Varias fuerzas son asociadas con este problema: - Cada cambio en el sistema debe ser implementado y debe probarse cuidadosamente. El software que activamente soporta y controla su propia modificacin debe cambiarse en forma eficaz y segura. - Los sistemas de software adaptables normalmente tienen una estructura interna compleja. Aspectos que estn sujetos a cambios son encapsulados dentro de componentes separados. La implementacin de servicios de la aplicacin se extiende sobre varios componentes pequeos con diferentes relaciones entre ellos. Para conservar dichos sistemas mantenibles, se prefiere esconder esta complejidad del mantenimiento del sistema. - Las tcnicas necesarias para un sistema cambiable, como la parametrizacin, subclases, son tambin las que hacen difcil y compleja su modificacin. Contar con un mecanismo uniforme para todos los tipos de cambios es ms fcil de usar y entender. - Los cambios pueden ser a cualquier escala, desde proveer un conjunto de teclas rpidas para comandos usados normalmente como tambin adaptar una aplicacin framework para un cliente especfico. - Incluso pueden cambiar aspectos fundamentales de sistemas de software por ejemplo los mecanismos de comunicacin entre los componentes.

Pag 47
Solucin Se deben seleccionar aspectos de la estructura y la conducta que sean accesible a la adaptacin y el cambio. Esto conlleva a una arquitectura que esta dividida en dos partes principales: un meta nivel y un nivel base. El meta nivel proporciona una representacin propia del software para darle el conocimiento de su propia estructura y conducta y consiste en metaobjetos que encapsulan y representan la informacin sobre el software. El nivel base define la lgica de la aplicacin. Su implementacin usa los metaobjetos para permanecer independiente de esos aspectos que son probables de cambiar. Por ejemplo, los componentes del nivel base slo pueden comunicarse entre s a travs de un metaobjeto que implementa un mecanismo especfico de llamada a funcin definida por el usuario. Cambiando el metaobjeto, cambia la manera en que los componentes del nivel base se comunican, pero sin modificar el cdigo del nivel base. Se especifica una interfaz para manipular los metaobjetos llamada protocolo del metaobjeto (MOP), y permite a los clientes especificar los cambios particulares como la modificacin de mecanismo de llamada a funcin del metaobjeto. El propio protocolo es responsable de verificar la exactitud de la especificacin del cambio y realizar dicho cambio. Cada manipulacin de los metaobjetos a travs de su protocolo afecta el comportamiento del nivel base subsiguiente. Estructura El meta nivel consiste en un conjunto de metaobjetos. Cada metaobjeto encapsula la informacin seleccionada sobre un solo aspecto de la estructura, la conducta o estado del nivel base. Hay tres fuentes para tal informacin:

proporcionado por el ambiente en tiempo de ejecucin del sistema, definido por el usuario, como el mecanismo de llamada a funcin o recuperado del nivel base en tiempo de ejecucin.
Todos los metaobjetos en conjunto proporcionan una misma representacin de una aplicacin. Los metaobjetos construyen la informacin, la cual est por una parte slo implcitamente disponible, y por otra explcitamente accesible y modificable. Al menos cada sistema interno puede describirse de esta manera. Por ejemplo, en un sistema distribuido puede haber metaobjetos que proporcionan la informacin sobre la ubicacin fsica de componentes de nivel base. Otro componente de nivel base pueden usar estos metaobjetos para determinar si sus compaeros de comunicacin son locales o remotos. Slo detalles del sistema que son probables de cambiar o qu vara de cliente a cliente debe encapsularse por los metaobjetos. La interfaz de un metaobjeto permite al nivel base acceder al mantenimiento de la informacin o al servicio que ofrece. Por ejemplo, un metaobjeto que proporciona la informacin de la ubicacin acerca de un componente distribuido proporcionara las funciones para acceder al nombre e identificador del componente, informacin sobre el proceso en el cual esta ubicado e informacin acerca del host en el cual corre el
proceso. Un metaobjeto no permite al nivel base modificar su estado interno. La manipulacin slo es posible a travs del protocolo del metaobjeto o por su propio cmputo. Mediante los modelos de nivel base y las implementaciones de la aplicacin lgica del software representan varios de los servicios que ofrece el sistema como tambin el modelo de datos subyacente. El nivel base tambin especfica la colaboracin fundamental y las relaciones estructurales entre los componentes que incluye. Si el software incluye una interfaz de usuario, sta tambin es parte del nivel base. El nivel base usa la informacin y los servicios provistos por los metaobjetos como la informacin de la ubicacin de los componentes y mecanismos de llamada a funcin. Esto permite seguir siendo flexible -su cdigo es independiente de aspectos que pueden estar sujetos al cambio y adaptacin. Usando los servicios del metaobjeto, los componentes de nivel base no necesitan codificar la informacin sobre las ubicaciones concretas de sus pares de comunicacin -ellos consultan los metaobjetos apropiados para esta informacin. Los componentes de nivel base se conectan directamente a los metaobjetos de los cuales ellos dependen. El componente de nivel base siempre consulta el mismo metaobjeto.
Clase Nivel Base Responsabilidades
- Implementa la lgica de la aplicacin
Colaborador
- Meta Nivel
Clase Meta Nivel Responsabilidades

- Encapsula el sistema interno que puede cambiar - Provee una interface interna para facilitar las modificaciones al meta nivel
Colaborador
- Nivel Base
Figura 4.25 - Clases Nivel Base y Meta Nivel
El protocolo metaobjeto (MOP) sirve como una interfaz externa al meta nivel y realiza la implementacin de un sistema reflexivo. Los clientes del protocolo metaobjeto, los cuales pueden ser componentes de nivel base u otras aplicaciones, pueden especificar modificaciones a metaobjetos o a sus relaciones usando el nivel base. El mismo protocolo es responsable de realizar estos cambios. El protocolo Metaobjeto normalmente se disea como un componente separado. Esto soporta la implementacin de funciones que operan en varios metaobjetos. Por ejemplo, modificando metaobjetos que encapsulen informacin de ubicacin a cerca de componentes distribuidos eventualmente requieren una actualizacin correspondiente al mecanismo de llamada a funcin de metaobjetos.
Clase Protocolo Metaobjeto Responsabilidades
- Ofrece una interfaz para cambios en el meta nivel -Lleva a cabo los cambios
Colaborador
- Meta Nivel - Nivel Base
Figura 4.26 - Clase Protocolo Metaobjeto Arquitectura de Software: Estilos y Patrones

La estructura general de una arquitectura reflexiva es muy similar a un sistema Layer. El meta nivel y el nivel base son dos capas cada una de las cuales proporcionan su propia interfase. La capa de nivel base especfica la interfaz del usuario para explotar la funcionalidad de la aplicacin. La capa del meta nivel define el protocolo metaobjeto para modificar los metaobjetos.
modifica Meta Nivel Recupera informacin MetaobjetoA MetaobjetoB MOP modifica
Nivel Base
usa ComponenteA
usa
usa Interfase de Usuario provee acceso a
ComponenteB
Figura 4.27 - Clase Protocolo Metaobjeto
Consecuencias El patrn Reflection proporciona las siguientes ventajas: o existente al modificar un sistema reflexivo. En cambio, se especifica un cambio llamando a una funcin del protocolo metaobjeto. Al extender el software, se pasa el nuevo cdigo al meta nivel como un parmetro del protocolo metaobjeto. Este protocolo, por si mismo, es responsable de integrar sus solicitudes de cambio realizando modificaciones y extensiones al cdigo del meta nivel y, si es necesario, recompila las partes cambiadas y realiza un enlace con la aplicacin mientras est se esta ejecutando.
Modificaciones no explicitas de cdigo fuente. No se necesita tocar el cdigo
Cambiar un sistema del software es fcil. El protocolo metaobjeto provee un
mecanismo seguro y uniforme para realizar estos cambios. Esconde la complejidad interna de una aplicacin a cambiar y toma el control sobre cada modificacin.
Soportar varios tipos de cambios. Los metaobjetos pueden encapsular cada
aspecto del comportamiento del sistema, del estado y su estructura. Una arquitectura basada en este patrn soporta as potencialmente los cambios de casi cualquier tipo o escala.
El patrn Reflection tiene algunas desventajas significantes: o
Las modificaciones al meta nivel pueden causar dao. Aun el protocolo metaobjeto ms seguro no prev a los usuarios de especificar modificaciones incorrectas. Dichas modificaciones pueden causar serios daos al software o su ambiente. Por ejemplo modificar un esquema de base de datos sin suspender la ejecucin de los objetos en la aplicacin que lo usa, o el pasaje de cdigo al protocolo metaobjeto que incluye errores semnticos. Adems deben descubrirse errores potenciales dentro de las especificaciones de cambio antes de realizar el cambio. Cada cambio debe tener slo efecto limitado en otras partes del software.
Pag 50

o o
Incremento en el nmero de componentes. Puede suceder que un sistema software reflexivo incluya ms metaobjetos que componentes de nivel base. Baja eficiencia. Los sistemas de software reflexivos son normalmente ms lentos que los sistemas no-reflexivos. Esto es causado por la compleja relacin entre el nivel base y el meta nivel. Siempre que el nivel base sea incapaz de decidir cmo continuar con el cmputo, pide ayuda al meta nivel. Esta capacidad reflexiva requiere procesamiento extra: recuperacin de informacin, metaobjetos cambiantes, chequeo de consistencia, y la comunicacin entre los dos niveles disminuye la performance global del sistema. Escasa cambiabilidad. Aunque un patrn Reflection ayuda con el desarrollo
de software cambiable, se soportan slo cambios que puedan realizarse a travs del protocolo del metaobjeto. Como resultado, no es posible integrar fcilmente todos los cambios imprevistos a una aplicacin, por ejemplo cambios o extensiones al cdigo del nivel base.
Ejemplo CLOS (Common Lisp Object System) es un clsico ejemplo de un lenguaje de programacin reflexiva. En CLOS las operaciones definidas por objetos son llamadas funciones genricas y su procesamiento se refiere a invocaciones a funciones genricas Una invocacin a una funcin genrica es dividida en tres fases: - El primer sistema determina los mtodos que son aplicables a la invocacin dada. - Luego ordena los mtodos aplicables en orden decreciente de precedencia. - El sistema finalmente establece la ejecucin de una lista de mtodos aplicables. En CLOS ms de un mtodo puede ser ejecutado en respuesta a una invocacin dada. El proceso de invocaciones de funciones genricas es definido en el protocolo del metaobjeto de CLOS. Bsicamente, este ejecuta una cierta secuencia de funciones genricas del meta nivel. A travs de CLOS, los usuarios del protocolo metaobjeto pueden variar la conducta de una aplicacin modificando estas funciones genricas o las funciones genricas del metaobjeto llamados por ellos.

Pag 51
Captulo 5 Patrones de Diseo

Los patrones de diseo se han convertido en una tcnica importante para el reuso del conocimiento de software. Cada patrn provee informacin sobre su diseo, describiendo las clases, mtodos y relaciones que resuelven un problema de diseo en particular. Los patrones han sido agrupados y organizados en catlogos cada uno dando diferentes clasificaciones y descripciones. El proceso de construccin de aplicaciones utilizando patrones de diseo se reduce a que, cada vez que el diseador encuentra un problema, busca en los catlogos un patrn que lo resuelva. Si existiera tal patrn, se deben identificar las clases, mtodos y atributos de la aplicacin que juegan el rol de aquellos prescritos por el patrn.
Patrones de Creacin
Estos patrones facilitan la creacin de objetos en un sistema, debido a que la mayor parte de los sistemas Orientados a Objetos necesitan crear instancias de clases. Los patrones de creacin muestran la gua de cmo crear objetos. Las decisiones que se deben tomar al momento de la creacin de los objetos normalmente sern resueltas dinmicamente decidiendo qu clases instanciar o qu objetos delegarn responsabilidades sobre otros objetos. Es decir, los patrones de creacin abstraen el proceso de instanciacin, ayudan a independizar a un sistema, de cmo sus objetos son creados. En general, tratan de ocultar las clases y mtodos concretos de creacin, de tal forma que al variar su implementacin, no se vea afectado el resto del sistema.
Abstract Factory
Crea familias de objetos relacionados o dependientes sin necesidad de especificar su clase concretamente. Aplicabilidad Se usa el patrn Abstract Factory cuando el sistema a desarrollar debe: - Ser independiente de cmo se crean, se componen y se representan sus productos. - Debera ser configurado mediante una de las mltiples familias de productos posibles. - Se disea una familia de objetos relacionados que deben ser usados en conjunto. - Proveer una librera de una clase de productos y es necesario revelar simplemente sus interfaces, pero ocultar sus implementaciones.

Pag 52
Participantes abstractos. concretos.
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. Cliente: usa solo interfaces declaradas.
AbstractFactory CreateProductA() CreateProductB() AbstractProductA
Client
ProductA2 ConcreteFactory 1 CreateProductA() CreateProductB() ConcreteFactory 2 CreateProductA() CreateProductB()
ProductA1
AbstractProductB
ProductB2
ProductB1
Figura 5.1 - Patrn de Diseo Abstract Factory
Consecuencias El patrn Abstract Factory tiene las siguientes ventajas: o
Asla clases concretas: Ayuda a controlar las clases de objetos que crea una
aplicacin. Debido a que una fabrica encapsula la responsabilidad y la creacin de objetos de productos, ella asla a los clientes de la implementacin de clases, permitindoles manipular instancias a travs de sus interfaces abstractas.
Facilita el cambio en familias de productos: La clase de una fbrica concreta aparece solo una vez en la aplicacin, lo que facilita su cambio en una aplicacin. Promueve la consistencia entre los productos: Cuando los objetos de
productos en una familia son designados a trabajar juntos, es importante que una aplicacin utilice objetos de solo una clase a la vez.

Pag 53
El patrn Abstract Factory tiene las siguientes desventajas: o
Es difcil mantener nuevos tipos de productos: No es fcil extender una
fbrica abstracta para que produzca nuevos tipos de productos, porque su interfaz fija el conjunto de productos que se pueden crear. Por lo cual agregar un nuevo producto requiere extender la interfaz de la fbrica, lo cual implica cambios en el cdigo de la clase Abstract Factory y todas sus subclases.
Ejemplo Un ejemplo de uso del patrn Abstract Factory es su uso en la creacin de widgets (ventanas, scroll-bars, botones, etc.) ya que su forma de implementacin es dependiente del sistema operativo subyacente. Se declara una fbrica abstracta Widget, la cual implica varias fabricas concretas de widgets adaptadas a cada situacin en particular (diferentes aplicaciones utilizan widgets de forma diferente ) de las cuales el usuario no se da cuenta de su existencia.
Builder
Separa el proceso de construccin de un objeto complejo de su representacin, para que el mismo proceso de construccin pueda crear diferentes representaciones. Aplicabilidad Se utiliza el patrn Builder cuando: - El algoritmo para crear objetos complejos debe ser independiente de las partes que constituyen el objeto y la forma en que son ensamblados. - La construccin de procesos debe permitir diferentes representaciones para el objeto que se construye. Participantes
Builder: Especifica una interfaz abstracta para crear partes de un objeto de Producto. ConcreteBuilder: Construye y ensambla partes del producto mediante la implementacin del patrn Builder, define y controla la representacin que crea, y adems, provee una interfaz para consultar el producto. Director: construye un objeto usando el patrn Builder Producto: Representa al objeto complejo bajo construccin. ConcreteBuilder crea la
representacin interna del producto y define el proceso por el cual es ensamblado.

Pag 54
Director Construct()
Builder BuildPart() Product
for all objects in structure { builder -> BuildPart() }
ConcreteBuilder BuildPart() GetResult()
Figura 5.2 - Patrn de Diseo Builder
Consecuencias Las consecuencias ms importantes son: o
Permite variar la representacin interna de un producto: El objeto Builder
provee al director de una interfaz abstracta para construir el producto. La interfaz permite al Builder ocultar la representacin y la estructura interna del producto, y la forma en que ste se ensambla. Como el producto se construye a travs de una interfaz abstracta de debe definir un nuevo tipo de constructor para cambiar la representacin interna de un producto.
Asla los cdigos de construccin y representacin: El patrn Builder agrega modularidad encapsulando la forma en que un objeto es construido y la forma en que es representado. Los clientes no necesitan conocer nada de la clase que define la estructura interna del producto, tal clase no aparece en la interfaz del Builder. Cada ConcreteBuilder contiene el cdigo para crear y ensamblar un tipo de producto en particular. El cdigo se escribe una vez, luego diferentes Directores pueden usarlos para construir distintos productos desde el mismo conjunto de partes. Mayor control en el proceso de construccin: El patrn Builder construye el producto paso a paso bajo el estricto control del Director. Solamente cuando se finaliza el producto, el director lo recupera del constructor. Esto brinda mayor control sobre el proceso de construccin y consecuentemente en la estructura interna del producto resultante.
Ejemplo Las PIMs son bases de datos especiales. Una PIM incluir normalmente una libreta de direcciones, un calendario para agendar las actividades y citas y una lista de tareas a realizar donde se listan a las mismas, las llamadas por realizar y cosas que queden por hacer. Para lograr la gestin de citas pueden definir una clase llamada Cita para la informacin de cada evento, de tal forma que pueda registrar informacin como por ejemplo fechas de inicio y finalizacin de la misma, una descripcin de la cita, un lugar de encuentro, asistentes a la cita, etc. La informacin es introducida por un usuario cuando se crea la cita, por lo que se define un constructor que permite establecer el estado del nuevo objeto Cita.

Pag 55
Son necesarios diferentes tipos de informacin dependiendo del tipo de cita. Se puede necesitar una lista de asistentes, algunas pueden tener fecha de inicio y fin, otras una sola fecha. Cuando se consideran todas estas opciones la creacin de un objeto Cita no es una tarea trivial. Es por ello que se delega la responsabilidad de la creacin de citas a una clase especial, ConstructorCita, lo que simplificar mucho el cdigo de la propia Cita. La clase ConstructorCita contiene mtodos para crear las partes de Cita, y puede llamar a los mtodos de ConstructorCita que son relevantes para cada tipo de cita. Adems, la clase ConstructorCita puede asegurar que la informacin que recibe cuando se crea la cita es vlida, ayudando as a que se cumplan las reglas de negocio. Si necesita crear subclases de Cita, puede crear otra clase constructor o heredar de la que ya existe. En cualquier caso, esa tarea es ms fcil que la alternativa de gestionar la inicializacin de objetos por medio de constructores.
Prototype
El patrn Prototype (Prototipo), crea objetos nuevos copindolos, clonando una instancia creada previamente. Aplicabilidad Se utiliza este patrn cuando un sistema debe ser independiente de cmo se crean, se componen y se representan sus productos, adems cuando: - Las clases a instanciar son especificadas en tiempo de ejecucin - Para evitar la construccin de una jerarqua de la clase de fbricas que se asemeja a la jerarqua de la clase de productos - Cuando instancias de una clase pueden tener una de las combinaciones de diferentes estados. - Cuando es necesario la creacin de distintas variantes de un objeto. Entonces, el cdigo que utilizan esos objetos solicitar una copia del objeto que necesite, una copia significa otra instancia del objeto. El nico requisito que debe cumplir el objeto es la posibilidad de clonarse. Participantes
Prototype: Declara una interfaz para clonarse. ConcretePrototype: Implementa una operacin para clonarse. Cliente: Crea un nuevo objeto por medio de una solicitud de clonacin al prototype.

Pag 56
Client Operation()
Prototype Clone()
p = prototype - > Clone()
ConcretePrototype 1 Clone()
ConcretePrototype 2 Clone()
return copy of self
return copy of self
Figura 5.3 - Patrn de Diseo Prototype
Consecuencias El patrn Prototype oculta las clases producto del cliente. Este patrn cuenta con las siguientes ventajas: o permite que se incorpore una clase producto en el sistema simplemente registrando una instancia de prototipo. Esto es ms flexible que la forma en que lo brinda otro patrn de creacin, debido a que el cliente puede agregar o quitar prototipos en tiempo de ejecucin. dinmicos permite definir nuevos comportamientos a travs de composicin de objetos especificando valores para variables de un objeto sin definir nuevas clases. Se define una nueva clase de objetos clonando clases existentes y registrando las instancias como prototipos de objetos cliente. Un cliente puede variar su comportamiento delegando responsabilidades al prototipo. Este tipo de diseo le permite a los usuarios definir nuevas clases sin programar, en realidad, clonar un prototipo es similar a instanciar una clase. Este patrn puede disminuir el nmero de clases que necesita el sistema.
Agregar y quitar productos en tiempo de ejecucin: El patrn Prototype
Especificar nuevos objetos variando sus valores: En sistemas altamente
Reducir la subclasificacin: Este patrn permite clonar un prototipo en vez de solicitar a un mtodo fbrica que cree un nuevo objeto, lo cual evita tener toda una jerarqua de clases Creadoras de objetos. Permite configurar una aplicacin con clases dinmicamente: Una de las mayores ventajas de este patrn es permitir en tiempo de ejecucin cargar dinmicamente las clases en una aplicacin.
El patrn Prototype presenta la siguiente desventaja: o Cada subclase de Prototype debe ser implementada por la operacin Clone, tarea que puede resultar complicada cuando las clases ya existen y los objetos que estas incluyen no soportan ser copiados o tienen referencias circulares.

Pag 57
Ejemplo Si nos referimos al ejemplo planteado en el patrn de diseo Builder, en el PIM tal vez se necesite copiar una direccin con el fin de que el usuario no tenga que introducir manualmente toda la informacin cuando crea un nuevo contacto. Una forma seria crear un nuevo objeto Direccin y luego copiar los valores apropiados del objeto Direccin existente. Esta solucin tiene un problema: viola el principio de encapsulacin de la orientacin a objetos. Para alcanzar la solucin se deberan hacer llamadas a los mtodos para copiar la informacin de Direccin fuera de la clase Direccin. Esto significa que se hace ms difcil mantener el cdigo de la clase Direccin porque se extiende a lo largo de todo el proyecto. Adems tambin dificulta la reutilizacin de la clase Direccin. El cdigo utilizado para realizar la copia realmente pertenece a la clase Direccin, entonces se podra definir un mtodo copy() que produzca un duplicado del objeto Direccin con los mismos datos que el objeto original, el prototipo. Por lo tanto una llamada al mtodo en un objeto Direccin existente resuelve el problema de una forma mucho ms fcil de mantener y ms aceptable segn las prcticas correctas de programacin orientada a objetos.
Patrones Estructurales
Detallan la manera en que se pueden relacionar, distintos tipos de objetos, para trabajar unos con otros y formar estructuras de mayor tamao.
Adapter
El patrn Adapter se aplica para convertir una interfaz de una clase en otra, haciendo que una clase a la que le fuera imposible utilizar la primer interfase, haga uso de ella por medio de la segunda. Es decir, permite que stas trabajen juntas, lo que de otra forma sera incompatible. Aplicabilidad El patrn Adapter se recomienda utilizar cuando: - Es necesario el uso de una clase existente, y su interfaz es distinta a la que se necesita. - Se requiere crear una clase reusable que coopere con clases no relacionadas, es decir, con clases que no necesariamente tienen interfaces compatibles. Participantes
Target : define la interfaz especfica del dominio que usa Client. Client: participa en la formacin de objetos para la interfaz Target.
necesitan ser adaptados.
Adaptee (Adaptado): especifica una interfaz existente que define los mtodos que

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

Client Target Request() Adaptee SpecificRequest()
(Implementacin )
Adapter Request()
SpecificRequest()
Figura 5.4 - Patrn de Diseo Adapter
Consecuencias El Patrn Adapter presenta las siguientes ventajas y desventajas: o
Reutilizacin de Cdigo: El patrn Adapter ofrece una opcin para la reutilizacin del cdigo, permitiendo la interaccin de dos o ms objetos que supuestamente son incompatibles. Transferencia de argumentos: Mediante el objeto Adapter se crean objetos
apropiados cuando no hay una correspondencia directa entre el Target y el Adaptee, o encapsula un objeto para que pueda ser utilizado por el Adaptee.
Existen otras consideraciones a tener en cuenta en el momento de utilizar el patrn Adapter: o
Cuantas veces el Adapter realiza adaptaciones? Vara en la cantidad de
trabajo que hace Adapter para adaptar Adaptee a la interfaz Target. Existe una variedad de tareas que se puede requerir que Adapter lleve a cabo, desde una simple conversin (cambiar los nombres de las operaciones) hasta soportar un conjunto de operaciones totalmente diferentes. El trabajo depende de que tan similar o diferentes sean las interfaces de Target con las de Adaptee.
Adaptadores Pluggables: Una clase es ms reutilizable cuando se minimiza
las asunciones que otras clases deben hacer para utilizarla. Por medio de la construccin de la adaptacin de una interfaz en una clase, se elimina la posibilidad de que otras clases vean la misma interfaz. Es decir, al adaptar la interfaz de una clase permite incorporar una clase propia en un sistema existente que puede esperar diferentes interfaces para dicha clase.
Ejemplo Un ejemplo del mundo real en el que podemos aplicar este patrn es en un libro de frases de idiomas extranjeros. Este libro traduce expresiones comunes (mensajes) de un idioma a otro, permitiendo que dos elementos incompatibles se comuniquen entre s.

Pag 59
Bridge
Mediante el patrn Bridge es posible desacoplar una abstraccin de su implementacin, de forma que ambas puedan modificarse de manera independiente sin necesidad de alterar por ello la otra. Aplicabilidad: Se puede utilizar el patrn Bridge cuando: - Se desea evitar una vinculacin permanente entre la abstraccin y su implementacin. Este puede ser el caso en que la implementacin debe ser seleccionada o modificada en tiempo de ejecucin. - Las abstracciones y sus implementaciones deben ser extensibles a travs de subclases. En este caso, el patrn Bridge permite combinar diferentes abstracciones e implementaciones y extenderlas en forma independiente. - Los clientes no deben tener que recompilar el cdigo cuando se lleven a cabo modificaciones en la implementacin de una abstraccin. Se desea ocultar completamente la implementacin de una abstraccin a los clientes.
- Se necesita compartir una implementacin entre varios objetos, y este hecho debe ocultarse a los clientes. Participantes:
Abstraction: define una interfaz abstracta. Mantiene una referencia a un objeto de tipo Implementor. RefinedAbstraction: extiende la interfaz definida por Abstraction. Implementor: define la interfaz para la implementacin de clases. Esta interfaz no es necesario que corresponda exactamente con la interfaz de Abstraction; ya que por lo general, la interfaz Implementor provee slo operaciones primitivas, y Abstraction
define operaciones de alto nivel basadas en esas primitivas.
ConcreteImplementor: implementa y define la implementacin de la interfaz de Implementor.

Client Abstraction Operation()
imp->OperationImp ();
Implementor OperationImp()
ConcreteImplementorA RefinedAbstraction OperationImp()
ConcreteImplementorB OperationImp()
Figura 5.5 - Patrn de Diseo Bridge

Pag 60
Consecuencias o
Separa interfaz e implementacin: Una implementacin de una abstraccin

no esta permanentemente confinada a una interfase, ya que configurada en tiempo de ejecucin. Adems, un objeto tiene la de cambiar su implementacin en tiempo de ejecucin. El desacoplar Abstraction e Implementor hace que se elimine en compilacin las dependencias sobre una clase de implementacin. puede ser posibilidad hecho de tiempo de
o o Ejemplo
Mejora la extensibilidad: se puede extender en forma independiente las

jerarquas de Abstraction e Implementor.
clientes de los detalles de implementacin.
Oculta a los clientes los detalles de implementacin: Se puede proteger a los
Ejemplos de la aplicacin de este patrn son los sistemas de interfaz grfica que deben ser portables entre plataformas, estos sistemas necesitan que la implementacin subyacente sea aplicada cuando la aplicacin se inicia en un sistema operativo diferente.
Composite
El patrn Composite admite construir objetos complejos por medio de la composicin recursiva de objetos similares u otros ms simples en una estructura en forma de rbol. Adems permite que dichos objetos sean tratados de manera semejante, sin hacer distinciones entre ellos. Esto reduce el tratamiento de los objetos creados, debido a que como todos ellos poseen una interfaz comn los trata de igual manera a todos. Aplicabilidad Se recomienda utilizar el patrn Composite cuando: - Es necesario representar la jerarqua completa de objetos. - Se necesita que el cliente no note la diferencia entre una composicin de objetos y un objeto individual, de esta forma el cliente tratar a todos los objetos en la composicin de la estructura uniformemente. Participantes
Component: Declara la interfaz para objetos en la composicin. Implementa comportamientos por defecto para la interfaz comn a todas las clases. Declara una interfaz para acceder y administrar sus componentes hijos. Leaf: Representa las hojas en el rbol de la composicin. Define el comportamiento para objetos primitivos. Composite: Define el comportamiento para componentes que tienen hijos. Almacena
los componentes hijos.
Client: opera con objetos en la composicin a travs de la interfaz Component.
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.Operation ();
Figura 5.6 - Patrn de Diseo Composite
Consecuencias El patrn Composite tiene las siguientes ventajas: o
Define jerarquas de clases formada por objetos primitivos. Los objetos
primitivos pueden estar compuestos dentro de objetos complejos los cuales a su vez pueden ser compuestos y as recursivamente.
Clientes ms simples: Los clientes pueden tratar en forma uniforme

estructuras compuestas y objetos individuales. Para los clientes es transparente si estn tratando con una hoja o un componente compuesto. Esto simplifica el cdigo del cliente.
Es sencillo agregar componentes nuevos: Nuevos componentes Composite o subclases Leaf trabajan automticamente con estructuras existentes y cdigos de clientes. Los Clients no deben ser cambiados por nuevas clases Component.
El patrn Composite presenta las siguientes desventajas: o
Puede hacer el diseo demasiado general: Al agregar nuevos componentes
de forma fcil, dificulta restringir los componentes de una composicin, especialmente cuando se requiere que una composicin tenga solo ciertos componentes.
Ejemplo Un ejemplo clsico de aplicacin de este patrn se observa en las aplicaciones grficas, donde el usuario puede crear dibujos complejos a partir de dibujos sencillos y bsicos (Hojas), pero a su vez puede manipular conjuntamente slo una parte del dibujo, sin hacer distincin si es una figura simple o compuesta

Pag 62
Proxy
El patrn Proxy se emplea como intermediario para acceder a un objeto, controlando el acceso a l. Aplicabilidad El patrn Proxy es aplicable cuando se necesita referenciar a un objeto en forma ms refinada y verstil que con un simple puntero. En las siguientes situaciones es conveniente el uso del patrn Proxy: - Un proxy remoto provee una representacin local de un objeto ubicado en un espacio de direccin diferente. - Un proxy virtual crea objetos de gran tamao bajo demanda. - Un proxy de proteccin controla el acceso al objeto original, controlando quien accede a cada mtodo y otorgando los permisos basndose en el invocador. - Una referencia elegante lleva a cabo acciones extras cuando se acceden a objetos referenciados. El uso normal incluye:

Contar el nmero de referencias al objeto para que pueda ser liberado automticamente cuando no haya ms 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 ningn otro objeto lo pueda modificar.
Participantes
Proxy: Mantiene una referencia que le permite acceder al objeto real. Mantiene una interfaz idntica 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. Segn el tipo de proxy puede:

Proxy remoto: Codificar peticiones y sus argumentos para enviar al RealSubject en otro espacio de direccin Proxy virtual: Guarda informacin adicional del RealSubject Proxy de proteccin: Comprueba los permisos de acceso al RealSubject.
Subject: Define la interfaz comn a Proxy y RealSubject RealSubject: Define el objeto real que representa el Proxy

Pag 63
Client
Subject Request() ..
RealSubject Request() ...
Proxy Request() ...

realSubject ->Request(); ...
Figura 5.7 - Patrn de Diseo Proxy
Consecuencias El patrn Proxy introduce un nivel de indireccin cuando se accede a un objeto. La indireccin 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 interacta 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 Proteccin: 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 decisin 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 patrn 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 cmo o dnde se debe guardar. Eso es lo que realiza este patrn. El proxy guarda una referencia a un objeto, que es quien realmente se encargar de ejecutar la accin. 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 ejecucin
Patrones de Comportamiento
Los patrones de comportamiento describen la forma de como organizar, administrar, y combinar conductas y responsabilidades de objetos, centrndose en la comunicacin entre ellos. Frecuentemente, describen como los distintos elementos colaboran entre si para conseguir un objetivo.

Pag 64
Template Method
El patrn Template Method proporciona un mtodo abstracto que permite que las subclases redefinan partes del mtodo sin reescribirlo completamente manteniendo su estructura inicial. Aplicabilidad: Se utiliza el patrn Template Method para - Proporcionar un esqueleto para un mtodo permitiendo a las subclases redefinir partes especficas del mismo. - Centralizar partes de un mtodo que se definen en todos los subtipos de una clase, pero que siempre tiene una pequea 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 mtodo template() definiendo el esqueleto de un algoritmo. Este mtodo llama tanto a operaciones primitivas como a operaciones definidas en AbstractClass.
ConcreteClass: Es una subclase de AbstractClass e implementa los mtodos abstractos

definidos.
AbstractClass templateMethod() subOperation1() subOperation2()

//skeleton code subOperation 1() ; //more skeleton code subOperation 2() ; //even more code
ConcreteClass subOperation1() subOperation2()
Figura 5.8 - Patrn de Diseo Template Method
Consecuencias El patrn Template Method cuenta con una ventaja muy importante y es que facilita la reutilizacin de cdigo, evitando que el cdigo se duplique en muchas subclases Este patrn tiene como desventaja que si el mtodo template() llama a demasiados mtodos abstractos, se cansar pronto de utilizar AbstractClass como superclase. Es recomendable tener un nmero limitado de mtodos abstractos.

Pag 65
Ejemplo Los mtodos de plantilla se utilizan sobre todo en frameworks para, a la vez que se garantiza que las operaciones se ejecutan en el orden correcto, otorgar flexibilidad a los usuarios del framework permitiendo ejecutar su propio cdigo en determinados puntos, simplemente redefiniendo estos mtodos (abstractos en la clase original).
Observer
El patrn Observer define una dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, el observer se encarga de notificar este cambio a todos los otros objetos dependientes. Aplicabilidad: Se puede utilizar el patrn Observer cuando se presentan las siguientes situaciones: - Una abstraccin tiene dos aspectos, uno dependiente del otro. Encapsulndolos en objetos separados se permite variarlos y reusarlos de forma independiente. - Cuando un cambio en un objeto implica cambiar otros y no se conoce de antemano cuantos objetos deben actualizarse - Cuando un objeto debe ser capaz de hacer notificaciones a otros sin hacer suposiciones de quines son, buscando un bajo acoplamiento. Participantes:
Subject: Proporciona mtodos para suscribir y borrar Observers. Conoce sus Observers. Observer: Define la interfaz para objetos que deben ser notificados. ConcreteSubject: Almacena el estado que es de inters para los objetos
ConcreteObserver y enva notificaciones a sus Observers cuando cambia su estado.
ConcreteObserver: Mantiene una referencia a un objeto ConcreteSubject. Almacena el

estado que debe ser consistente con el del Subject. Implementa la interfaz de actualizacin para mantener su estado consistente con el del Subject.
Subject Attach(Observer) Dettach(Observer) Notify() observers Observer Update()
for all o in observers { o->Update() }
ConcreteSubject GetState() subjectState
subject
ConcreteObserver Update() observerState

observerStare= subject->GetState() ;
return subjectState
Figura 5.9 - Patrn de Diseo Observer

Pag 66
Consecuencias Ventajas: o
Acoplamiento mnimo entre Subject y Oberver: Todo lo que sabe un subject

es que tiene una lista de observers que responden a la interfaz observer. El subject no conoce ninguna clase observer concreta.
Soporte para comunicacin tipo broadcast: La notificacin se extiende a
todos los objetos de la lista. Se aaden y quitan observadores en cualquier momento.
Desventajas: o
Actualizaciones Costosas: Un observer no conoce cuntos observers ms

existen y por lo tanto, no conoce el costo de enviar un cambio al subject. Podra producirse una actualizacin en cascada.
Ejemplo Un ejemplo clsico de la aplicacin del patrn Observer se da cuando tenemos una aplicacin la cual consta de distintas vistas, y dependiendo de cada una de ellas los datos son actualizados de distinta forma y en distintos momentos.
Command
Este patrn permite solicitar una operacin a un objeto sin conocer realmente el contenido de esta operacin, ni el receptor real de la misma. Para ello se encapsula la peticin como un objeto, facilitando la parametrizacin de los mtodos. Al encapsular un mensaje como un objeto, permite gestionar colas o registros de mensajes, deshacer operaciones y restaurar el estado a partir de un momento dado. Ofrece una interfaz comn que permite invocar las acciones de forma uniforme y extender el sistema con nuevas acciones de forma ms simple. Este patrn presenta una forma sencilla y verstil de implementar un sistema basado en comandos facilitando su uso y ampliacin. Aplicabilidad: Se puede utilizar el patrn Command cuando se necesita: - Facilitar la parametrizacin de las acciones a realizar - Independizar el momento de peticin del de ejecucin - Implementar CallBacks, especificando que rdenes se necesitan ejecutar en ciertas situaciones bajo otras rdenes. Es decir, un parmetro de una orden puede ser otra orden a ejecutar. . - Dar soporte para deshacer comandos, procesos de identificacin y/o transacciones - Desarrollar sistemas utilizando rdenes de alto nivel que se construyen con operaciones sencillas (primitivas).
Participantes:
Command: Declara una interfaz para la ejecucin de una operacin. ConcreteCommand: Define una enlace entre el objeto Receiver y una accin. Implementa Execute() por invocacin a la operacin correspondiente en el Receiver. Client: Crea un objeto ConcreteCommand y setea su receptor Invoker : Solicita al command que enve la respuesta a su solicitud Receiver: Conoce la forma en que las operaciones son asociadas con el envo de una solicitud. Una clase puede servir como un Receiver.
Invoker Client Command Execute()
Receiver Action() ConcreteCommand Execute() State

receiver->Action();
Figura 5.10 - Patrn de Diseo Command
Consecuencias o o o Ejemplo Este patrn permite estructurar un sistema en torno a operaciones de alto nivel que se implementan en trmino de operaciones, por ejemplo, un sistema transaccional. Permite implementar un mecanismo de rehacer, deshacer permitiendo llevar un registro de las operaciones que s pueden volver a ser aplicadas, por ejemplo, en caso de una cada del sistema. Independiza el objeto que invoca una operacin de un objeto que conoce como implementarla. Los Command son objetos de primera clase, pueden ser manipulados y extendidos como cualquier otro objeto. Se facilita la ampliacin del conjunto de comandos ya que las clases existentes no cambian
State
El patrn State permite que un objeto cambie en tiempo de ejecucin su comportamiento cuando cambia su estado interno. Aplicabilidad: Se puede utilizar el patrn State en cualquiera de los siguientes casos:
- El comportamiento de un objeto depende de su estado y este cambia con mucha frecuencia. - Los mtodos tienen largas y mltiples sentencias condicionales que dependen del estado del objeto. Estos estados generalmente son representados por constantes enumeradas y largas sentencias switch/case dentro de los mtodos. El patrn State ubica cada rama del condicional en clases separadas. Participantes:
Context: Define la interfaz que utilizan los clientes y mantiene una referencia al estado
actual del objeto.
State: Define una interfaz para encapsular el comportamiento asociado a un estado

particular del objeto. del objeto.
ConcreteSate: Cada subclase implementa un comportamiento asociado con un estado
Context currentState setCurrentState(State s)
State someMethod()
ConcreteStateA someMethod()
ConcreteStateB someMethod()
Figura 5.11 - Patrn de Diseo State
Consecuencias El uso del patrn State presenta las siguientes ventajas e inconvenientes: o
Comportamiento de las particiones de estados basadas en el estado: Esto da
una visin ms clara del comportamiento. Cuando un objeto es un estado especfico, mira en la subclase State correspondiente y todo el posible comportamiento de ese estado se incluye en esa clase.
Localiza comportamiento para un estado especfico y particiona el comportamiento para diferentes estados: El patrn State ubica todos los
comportamientos asociados a un estado particular en un objeto. Como todos los cdigos especficos a un estado conviven en una subclase de State, agregar nuevos estados se transforma en una tarea muy sencilla, solo es necesario definir nuevas subclases.
Las transiciones de estados son explicitas: Cuando un objeto define su
estado actual mediante la asignacin de un valor a una variable, su transicin de estado no tiene una representacin explcita. Introducir objetos

Pag 69
separados por diferentes estados hace que la transicin se torne ms explcita, facilitando el reconocimiento de un cambio entre estados. o
Utiliza un gran nmero de clases: Si bien puede verse como una desventaja,
no lo es, debido a que presenta una visin mucho ms clara que el uso de largas sentencias switch en los mtodos.
Ejemplo Un ejemplo del uso del patrn State es considerar clases TCPConnection que representan el estado de la conexin de una red. Un objecto TCPConnection puede estar en uno de los varios estados posibles de la conexin: establecida, escuchando, cerrada. Cuando un objeto TCPCOnnection recibe solicitudes desde otros objetos, este responder de forma diferente dependiendo del estado en que se encuentre.
Strategy
El patrn Strategy define una familia de algoritmos, encapsula cada uno y los hace intercambiables, permitiendo que el algoritmo vare independientemente del cliente que haga uso de l. Aplicabilidad: Se puede utilizar el patrn Strategy cuando: - Se quiera ofrecer la posibilidad de configurar una clase con una gama de comportamientos disponibles. - Se necesiten diferentes variantes de un algoritmo. - Un algoritmo use datos que el cliente no tenga por qu conocer. - Una clase defina varios comportamientos y estos aparezcan en forma condicional en sus operaciones. Participantes:
Strategy: Declara la interfaz comn para todos los algoritmos soportados. ConcreteStrategy: Implementa un algoritmo usando la interfaz de Strategy. Context: Mantiene una referencia a un objeto Strategy, puede definir una interfaz para permitir a Strategy acceder a sus datos. Se configura con un objeto ConcreteStrategy.
Context ContextInterface() strategy Strategy AlgorithmInterface()
ConcreteStrategyA AlgorithmInterface()
ConcreteStrategyB AlgorithmInterface()
ConcreteStrategyC AlgorithmInterface()
Figura 5.12 - Patrn de Diseo Strategy Arquitectura de Software: Estilos y Patrones

Consecuencias Ventajas o
Familias de algoritmos relacionados: Mediante herencia a partir de clases
Strategy este patrn define una familia de algoritmos o comportamientos para contextos reusables. La herencia puede ayudar a factorizar la funcionalidad comn de los algoritmos. Elimina las sentencias condicionales. Strategy puede comportamiento. proveer diferentes implementaciones del mismo
o o
Desventajas o o o Ejemplo Un ejemplo bsico y sencillo para observar el uso de este patrn consiste en la implementacin de un algoritmo de bsqueda determinado. De esta forma tenemos una interfaz (una funcin que recibe una lista y la ordena) pero con distintas formas de realizar la ordenacin, diversos algoritmos, ordenacin por burbuja, merge sort, quick sort, etc. Puede producirse sobrecarga de comunicacin en el paso de parmetros entre Context y Strategy. Puede haber parmetros muy costosos de crear y NO usados por estrategias muy simples. Incrementan el nmero de objetos en una aplicacin.
Null Object
El patrn Null Object provee un objeto como un substituto por la falta de un objeto de un tipo dado. El Objeto Nulo no realiza nada aunque esto no significa que no sea inteligente. Este oculta los detalles de sus colaboradores. A veces una clase requiere de un colaborador pero no necesita que este haga algo. Sin embargo, la clase desea tratar a un colaborador que no hace nada de la misma manera que trata a uno que realmente proporciona conducta. Aplicabilidad: Se puede utilizar el patrn Null Object cuando: - un objeto requiere de un colaborador. El patrn Null Object no introduce esta colaboracin, hace uso de una colaboracin que ya existe. - algunos casos del colaborador que no deben hacer nada. - cuando necesita abstraer el manejo de objetos nulos fuera del cliente.

Pag 71
Participantes:
Client: requiere a un colaborador. AbstractObject: declara la interfase para el colaborador de Cliente e implementa la
conducta por defecto para la interfase comn a todas las clases.
RealObject: define una subclase concreta de AbstractObject cuyas instancias proveen un comportamiento til que espera Client NullObject: proporciona una interfase idntica a AbstractObject para que un objeto nulo pueda ser sustituido para un objeto real. Implementa su interfase pero no hace nada. El significado de no hacer nada depende de qu clase de conducta Client esta esperando. Cuando hay ms de una manera de no hacer nada, puede necesitarse ms de una clase NullObject.
Client uses AbstractObject +request()
RealObject +request()
NullObject +request()
do nothing
Figura 5.13 - Patrn de Diseo Null Object
Consecuencias Ventajas o Define jerarquas de la clase que consisten en objetos reales y en objetos nulos. Pueden usarse los objetos nulos en lugar de los objetos reales cuando se espera que el objeto no haga nada. Siempre que el cdigo del cliente espere un objeto real, tambin puede tomar un objeto nulo. Hace el cdigo del cliente simple. Los clientes pueden tratar a los colaboradores reales y los colaboradores nulos uniformemente. Los clientes normalmente no saben si ellos estn tratando con un colaborador real o uno. Esto simplifica el cdigo del cliente, porque evita tener que escribir cdigo de comprobacin, ya que se ocupa el colaborador nulo especialmente. o o Encapsula la tarea de no hacer nada en el cdigo del objeto nulo. Hacer el cdigo de no hacer nada en el objeto nulo facilita su reuso. Mltiples clientes que tienen la necesidad de que sus colaboradores no hagan nada querrn que la tarea de no hacer nada lo hagan todos de la misma forma. Si el no hacer nada necesita ser modificado, el cdigo puede cambiarse en un lugar. Luego de esto, todos los clientes continuarn usando el mismo comportamiento actualizado de no hacer nada.

Pag 72
Desventajas o La conducta de no hacer nada hace difcil distribuir o mezclar el comportamiento real de varias colaboraciones de objetos. La misma conducta de no hacer nada no puede agregarse fcilmente a la conducta de varias clases a menos que esas clases deleguen todo el comportamiento a una clase que puede ser una clase del objeto nulo. Puede ser necesario la creacin de una nueva clase NullObject para cada nueva clase AbstractObject. Puede ser dificultoso la implementacin si varios clientes no estn de acuerdo de cmo el objeto nulo no debe hacer nada o cuando su interfaz a AbstractObject no se encuentra bien definida. El Objeto Nulo siempre acta 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. Esto se logra fcilmente creando una clase Pelota para representar las pelotas y usando un patrn Startegy para controlar el movimiento de la pelota y otro patrn Strategy para controlar el color de la pelota. Sera entonces trivial escribir las estrategias para tipos diferentes de movimiento y efectos de color y crear pelotas con cualquier combinacin de movimiento y color. Sin embargo, si comenzamos por crear las estrategias ms simples posiblemente se asegure todo el trabajo. Ahora, la estrategia ms simple no sera ninguna estrategia. se es no hacer nada, no mueve y ni cambia el color. Sin embargo, el patrn Strategy exige a la pelota tener objetos que llevan a cabo las interfaces de estrategia. Aqu es donde el patrn Null Object es til. Simplemente se realiza un NullMovementStrategy que no mueve la pelota y un NullColorStrategy que no cambian el color de la pelota. Probablemente los mtodos en estas clases no hacen "nada".
Type Object
Desacopla instancias de sus clases para que estas clases puedan ser implementadas como instancias de una clase. El patrn Type Object permite crear las nuevas "clases" dinmicamente en tiempo de ejecucin, porque stas son instancias, y tambin permite al sistema crear instancias de esas instancias de tipo clase. Algunas veces una clase requiere no slo un nmero indeterminado de instancias sino tambin una cantidad desconocida de subclases. Aunque un objeto del sistema pueda crear nuevas instancias bajo demanda, usualmente no puede crear nuevas clases sin una recompilacin. Un diseo en el cual una clase tiene un nmero desconocido de subclases puede convertirse en una en la cual la clase tiene un nmero desconocido de instancias

Pag 73
Aplicabilidad Se recomienda aplicar el patrn de diseo Type Object cuando: - Las instancias de una clase necesitan estar agrupadas para implementar los atributos y/o comportamiento comn. - La clase necesita una subclase por cada grupo para implementar los atributos y/o comportamientos del grupo. - La clase requiere un gran nmero de subclases y/o la variedad total de subclases que quizs se requieren y se desconoce. - Se necesita poder crear nuevas grupos en tiempo de ejecucin que quizs no se predijeron durante el diseo. - Se necesita poder cambiar una subclase de un objeto despus de que se instanci sin tener que mutar a una nueva clase. - Se necesita jerarquizar los grupos recursivamente de modo que ese grupo sea a su vez un tem de otro grupo. Participantes El patrn Type Object tiene dos clases concretas, una que representa objetos y otra que representa sus tipos. Cada objeto tiene un puntero su tipo correspondiente.
TypeClass: Es la clase de TypeObject, tiene una instancia separada para cada tipo de
Object.
TypeObject: Es una instancia de TypeClass. Representa un tipo de Object. Establece todas las propiedades de un Object que son las mismas de todos los Objects del mismo tipo. Class: Es la clase de Object. Representa instancias de TypeClass. Object: Es una instancia de Class. Representa un nico tem que tiene un nico
contexto. Establece todas las propiedades de se tem que puede diferir entre tems del mismo tipo. Tiene un TypeObject asociado que describe su tipo. Delega propiedades definidas por su tipo a su TypeObject.
aTypeClass TypeObject1 TypeClass typeAttribute type Class attribute aTypeClass TypeObject2 aClass Object1B
type
aClass Object1A
type
Figura 5.14 - Estructura del patrn de diseo Type Object

Pag 74
Consecuencias Las ventajas de un patrn TypeObject son: o
Crea clases en tiempo de ejecucin: El patrn permite crear nuevas clases dinmicamente. Estas nuevas clases no son clases, sino instancias llamadas TypeObjects que son creadas por TypeClass de igual manera que cualquier instancia creada por su clase. Evita la explosin de subclases: El sistema no necesita un gran nmero de
subclases para representar diferentes tipos de Objects. En vez de un gran nmero de clases, el sistema puede usar un TypeClass y varios TypeObjects.
Oculta la separacin de instancias y tipos: Un Object cliente no necesita estar consciente de la separacin entre Object y TypeObject. El cliente realiza solicitudes de Object, y el Object decide que requerimiento enva al TypeObject. Los clientes que conocen al TypeObject pueden colaborar con ellos directamente sin ir a travs de los Objects. Cambio dinmico de tipo: El patrn permite que el Object cambie dinmicamente su TypeObject, dando el mismo efecto que si sufriera un cambio de clase. Esto es mucho ms simple que mutar un objeto a una nueva clase. Subclases independientes: TypeClass y Class pueden tener sus subclases
independientemente.
o o
Mltiples tipos de objetos: El patrn permite que un Object tenga mltiples TypeObjects donde cada uno define alguna parte del tipo del Object. El Object debe decidir cual tipo de comportamiento delegan a cual TypeObject.
Las desventajas de la utilizacin del patrn TypeObject son: o
Diseo complejo: El patrn divide un objeto lgico en dos clases. Su relacin, una cosa y su tipo, es difcil de entender. Es difcil reconocer o explicar la relacin entre un TypeObject y un Object. Esta confusin va en decremento de la simplicidad y la mantenibilidad. Implementacin compleja: El patrn saca diferentes implementaciones de
las subclases y las coloca en diferentes estados de las instancias de TypeObject. Considerando que cada subclase podra implementar un mtodo en forma diferente, el TypeClass puede implementar el mtodo de una nica forma y cada estado del TypeObject debe hacer que la instancia se comporte en forma diferente.
Manejador de referencia: Cada objeto debe guardar una referencia a su

TypeObject. De igual manera que un objeto conoce cual es su clase, un Object conoce cual es su TypeObject. Pero considerando que el sistema objeto o lenguaje automticamente establece y mantiene la relacin claseinstancia, en este caso debe ser la aplicacin por si misma quien establece y mantiene la relacin TypeObject-Object.

Pag 75
Ejemplo Supongamos que nos interesa modelar unidades de medida. Para plantear la relacin entre la unidad y su tipo aplicamos el Patrn Type Object que permite que varias instancias de una clase, en este caso Unidad, sean agrupadas de acuerdo con comunes atributos y/o comportamiento, evitando una explosin de numerosas subclases. Consta de dos clases: una que representa los objetos, Unidad (Class), y otra que representa sus tipos, TipoUnidad (TypeClass).
Decorador
El patrn de diseo Decorador proporciona una forma flexible de incorporar o eliminar funcionalidad de un componente dinmicamente sin modificar su aspecto o su funcionalidad. Aplicabilidad Es til hacer uso del patrn Decorator cuando: - Se desea realizar cambios en forma dinmica de forma transparente a los usuarios, sin las restricciones propias de la creacin de subclases. - Sea posible introducir o quitar responsabilidades de los componentes en tiempo de ejecucin. - Sea imposible utilizar herencia debido a que dara lugar a la aparicin de multitud de subclases para poder dar soporte a todas las combinaciones posibles. Participantes Para implementar el patrn Decorador, son necesarios los siguientes participantes: de los objetos a los que se les pueden aadir responsabilidades de forma dinmica.
Component: Componente que contiene el comportamiento genrico. Define la interfaz Decorador: Puede ser una clase o una interfaz. Define los comportamientos estndar
de todos los decoradores, tambin proporciona soporte para contener otros decoradores, es decir, mantiene una referencia a un objeto Component que puede ser un objeto ConcreteComponent u otro Decorador. referencia.
ConcreteDecorator: Aade responsabilidades al objeto Component al que hace

Pag 76
Component operation()
ConcreteComponent operation()
Decorator setComponent(Component c) operation()
ConcreteDecorator
component.operation ()
newAttribute operation() newOperation()
Figura 5.15 - Estructura del patrn de diseo Decorador
Consecuencias El patrn de diseo Decorador cuenta con las siguientes ventajas: o o
Ms flexible: Ofrece la oportunidad de ajustar y aumentar fcilmente el

comportamiento de un objeto en tiempo de ejecucin.
Evita que las clases altas de la jerarqua estn demasiado cargadas de funcionalidad: Es mucho ms sencilla la tarea relacionada con la
propagacin, debido a que slo se deber escribir una serie de clases cada una de las cuales contendr una parte especfica de la funcionalidad. En otro caso, habra que programar todos los comportamientos en el propio componente. o
Nuevas responsabilidades: Permite que la adicin de nuevas responsabilidades (nuevas clases de Decorators) independiente de las clases los Objetos que ellas extienden.
Hay que tener en cuenta tambin las siguientes desventajas: o
Un Decorator y su Component no son idnticos: Desde el punto de vista de
la identidad de los objetos, un DecoratorComponent no es idntico al Component. Por esto no se puede confiar en la identidad de los objetos cuando se usan Decorators. pequeos que son muy parecidos.
o Ejemplo
Propagacin de objetos: El patrn Decorator hace que haya muchos objetos
Supongamos que tenemos una clase existente Ventana y queremos aadirle funcionalidad para que muestre un borde alrededor. El patrn Decorator ayuda a resolver esta situacin de una manera sencilla y extensible. Se crea a partir de la clase Ventana la subclase abstracta VentanaDecorator y, heredando de ella, BordeDecorator y BotonDeAyudaDecorator. VentanaDecorator
encapsula el comportamiento de Ventana y utiliza composicin recursiva para que sea posible aadir tantas "capas" de Decorators como se desee. Podemos crear tantos Decorators como queramos heredando de VentanaDecorator.

Pag 78
Captulo 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 implementacin de un nuevo sistema en la gestin de cobro de Cheques. Este sistema permite la captura descentralizada de cheques de cualquier importe, eliminndose en todo el pas el traslado fsico de los mismos, quedando estos en poder de las Entidades Depositarias independientemente de su lugar de captacin y su domicilio de pago. Las Entidades deben contar en cada una de sus sucursales con los medios necesarios para poder llevar a cabo la captura de los datos de los cheques depositados, la generacin de los registros electrnicos y sus respectivas imgenes (digitalizacin). Transmitindose los registros electrnicos y las imgenes de los cheques superiores a un importe determinado.
Participantes
Los distintos participantes en el sistema son los que a continuacin se detallan: Participantes Internos al sistema: - Las Sucursales de la Entidad Depositaria: Son quienes efectan la digitalizacin y carga de todos los datos correspondientes al cheque depositado por el cliente en caja. - Entidad Girada: Es quien recibe la informacin electrnica de los cheques, y previa verificacin de la misma, debita el importe a sus clientes libradores y abona a la Entidad Depositaria. Participantes Externos al sistema - Cmara Compensadora: Es la administradora de la compensacin electrnica de medios de pagos y sus funciones se detallan a continuacin:
Refundicin de los archivos recibidos de las Entidades Depositarias y clasificacin de stos por Entidad Girada, generando los archivos con el detalle de transacciones para su posterior envo Refundicin de los archivos de rechazos recibidos de las Entidades Giradas y la clasificacin de stos por Entidad Depositaria, generando los archivos conteniendo el detalle de las operaciones para su posterior envo.

Pag 79
Esquema Operativo
Los diagramas muestran la forma en la que participan cada uno de los integrantes del sistema: Esquema a gran escala:
Suc 2
Suc 3 Suc 4
Suc 2
Suc 3 Suc 4
Suc 1
Suc 1
Entidad Depositaria / Girada
Camara Compensadora
Figura 6.1 - Esquema a gran escala
Esquema solucin 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
Server de la Sucursal
Suc 3 Cmara Compensadora
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 - Esquema dentro de cada una de las entidades.

Pag 80
Definicin del Sistema

Podemos especificar tres grandes circuitos que consisten en el envo/recepcin diario de archivos a la Cmara Compensadora donde se encuadran cada una de las sesiones, denominando sesin al proceso de envo o recepcin de archivos desde/hacia la Cmara Compensadora, correspondiente a cada tem de cada uno de los circuitos.
Circuito de Cheques
Las Entidades transmitirn a la Cmara Compensadora archivos conteniendo los registros electrnicos correspondiente a los cheques que dicha Entidad presenta para su compensacin electrnica en sesiones diariamente. Se entiende por registro electrnico al conjunto de datos que definen a un cheque - banco, sucursal, cdigo postal, nmero de cheque, nmero de cuenta, importe y fecha. En el circuito de cheques enviados, los cheques son escaneados en las sucursales, una vez realizado el cierre son remitidos al Sistema Centralizador (registros electrnicos e imgenes), donde se gestionan los distintos archivos para su posterior envo. Respecto al envo de archivos se identifican tres sesiones. - Cheques: Corresponde a la generacin de un archivo conteniendo los registros electrnicos de los cheques. - Imgenes: Se genera un archivo conteniendo todas la imgenes correspondientes a los cheques escaneados en el da, que superen un importe determinado. - Rechazos de Cheques: Luego de imputar los cheques recibidos, capturados en otros bancos el da anterior, se genera un archivo conteniendo aquellos cheques que se necesitan rechazar, es decir que no se pagan por diversos motivos (Ej: Sin fondo, Cuenta Inexistente, Falla Tcnica, etc.). En el circuito de cheques recibidos, los archivos estn conformados por cheques que han sido capturados en otros bancos el da anterior y son recibidos para su imputacin en sus respectivas cuentas. Respecto a la recepcin de archivos se identifican tres sesiones. - Cheques Recibidos: Se recepciona y procesa un archivo conteniendo los registros electrnicos de cheques procedentes de otros bancos para su cobro. - Imgenes: Se recepciona y procesa un archivo con todas las imgenes de los cheques que han sido capturados en otros bancos. - Rechazos de Cheques: Se recepciona y procesa un archivo con los registros electrnicos de los cheques rechazados por la Entidad Girada. Estos rechazos corresponden a cheques enviados por la Entidad Depositaria anteriormente.

Pag 81
Presentacin de Cheques Recepcin de Rechazos
Recepcin de Cheques Rechazo de Cheques Recepcin de Imagenes Entidad Depositaria
Entidad Girada
Presentacin de Imgenes
Camara Compensadora
Figura 6.3 - Esquema dentro de cada una de las entidades.
Circuito de Imgenes por Rechazo

Luego del proceso de recepcin de los cheques y su imputacin contable, se genera el archivo de Cheques rechazados. Para indicar el rechazo de un cheque, se asocia a su registro electrnico un cdigo de rechazo. Dependiendo del cdigo de rechazo, la Entidad Depositaria deber enviar, o no, a la Entidad Girada la imagen del mismo. El envo de los archivos se realiza por diferentes sesiones: - Imgenes por rechazo: Una vez recibidos los archivos de rechazos se deber enviar a la Entidad Girada las imgenes de aquellos cheques que segn su cdigo de rechazo lo requieran. - Rechazo de Imgenes por rechazo: En caso de recibir imgenes de una Entidad Depositaria que no correspondan a los cheques rechazados oportunamente, se deber generar un archivo indicando el rechazo de la imagen. La recepcin de los archivos se realiza por diferentes sesiones: - Imgenes por Rechazo: Una vez enviados los archivos de rechazos a la Entidad Depositaria, se deber recibir de la misma, un archivo conteniendo las imgenes correspondientes a los cheques rechazados por los cdigos que generan envo de imagen. - Rechazo de Imgenes por rechazo: En esta sesin se recibirn rechazos de aquellas imgenes que se enviaron por rechazo y no se corresponden con los datos del registro electrnico del cheque rechazado.
Entidad Girada
Presentacin de Rechazos Recepcin de Rechazos Recepcin de Imagenes Rechazo de Imagenes
Recepcin de Rechazos Rechazo de Rechazo Presentacin de Imgenes Recepcin de Rechazo de Imgenes
Entidad Depositaria
Camara Compensadora
Figura 6.4 - Circuito de Imgenes por rechazo

Pag 82
Circuito de Imgenes por Reclamos

El circuito de intercambio de imgenes por reclamo de cheques, es similar al que se usa en el circuito de imgenes de cheques rechazados. Los reclamos se efectan sobre cheques recibidos que, al gestionar su cobro no se contaba con la imagen. Esta operacin es solicitada por el cliente librador del cheque. Mediante diferentes sesiones se gestiona el envo de los archivos: - Reclamos de cheques: Se genera un archivo conteniendo todos los registros electrnicos correspondientes a reclamos efectuados en sucursales. - Imgenes por reclamo: Se genera un correspondientes a los reclamos recibidos. archivo con todas las imgenes
- Rechazo de Imgenes por reclamo: en caso de recibir imgenes de la Entidad Depositaria que no corresponden a los cheques reclamados, se genera un archivo indicando el rechazo de la imagen. La recepcin de los archivos se realiza por diferentes sesiones: - Cheques reclamados: Se procesa el archivo conteniendo los registros electrnicos que indican las imgenes reclamadas que se deben enviar. - Imgenes por reclamo: Se procesa el archivo que contiene las imgenes correspondientes a los cheques reclamados. - Rechazo de Imgenes por reclamo: Se procesa el archivo que indica que se han enviado imgenes que no se correspondan con los reclamos recibidos.
Entidad Girada
Presentacin de Reclamos Recepcin de Rechazos Recepcin de Imagenes Rechazo de Imagenes
Recepcin de Reclamos Rechazo de Reclamos Presentacin de Imgenes Recepcin de Rechazo de Imgenes
Entidad Depositaria
Camara Compensadora
Figura 6.5 - Circuito de Imgenes por reclamo
Limites del sistema

El caso de estudio se limita a realizar el anlisis y diseo arquitectnico del sistema correspondiente a la captura descentralizada de los cheques en sucursales de las Entidades Depositarias y la recepcin/envo de la informacin desde/al Host Central en Casa Matriz, el cual ser el responsable de gestionar la comunicacin con la Cmara Compensadora a travs del Servidor Central.

Pag 83
Visin Arquitectnica
Realizando un diagnstico 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 geogrficamente separadas y con diferentes tecnologas de comunicacin. - El ncleo de la funcionalidad se encuentra en un Servidor Central ubicado en Casa Matriz. - Las sucursales acceden a esta funcionalidad por medio de PCs. Interactivo: - Aplicacin instalada en sucursales. - Variedad de tipos de interfaz de usuario. - Formularios, mens, cajas de dilogos, para interaccin basada en eventos. Independencia de plataformas - Distintos servidores de base de datos, clientes con diferentes sistemas operativos. Para realizar la definicin de la arquitectura de base que capture toda la estructura de los subsistemas fundamentales de la aplicacin, como primer paso, debemos definir la infraestructura identificando las propiedades de todo el sistema global, Distribuido e Interactivo, es decir: - Seleccionar los patrones arquitectnicos adecuados. - Combinar los patrones arquitectnicos seleccionados. - Identificar los subsistemas funcionales: Utilizar los mtodos de anlisis y diseo convencional. - Integrar los subsistemas funcionales con la infraestructura del sistema

Pag 84
Captulo 7 Aplicacin de Patrones

En este captulo nos proponemos identificar patrones arquitectnicos y definir microarquitecturas y modelos de diseo basados en objetos, que permitan modelar el sistema anteriormente descripto de modo que resulte una aplicacin extensible, fcil de modificar, mantener y reusar. Se presenta el anlisis y diseo realizado para nuestro trabajo, describiendo especialmente los patrones utilizados y las razones de su seleccin.
Anlisis
En la presente seccin se describir el anlisis del sistema. Esta etapa comienza con el estudio del proceso de gestin de cobro de cheques en el sistema bancario. Como se mencionara en el captulo anterior, este sistema permite la captura descentralizada de cheques de cualquier importe, eliminndose en todo el pas el traslado fsico de los mismos, quedando estos en poder de las Entidades Depositarias independientemente de su lugar de captacin y su domicilio de pago. La Entidad Depositaria presenta cheques para su posterior cobro a la Entidad Girada donde se ha librado el valor. La Entidad Depositaria procesa en sus aplicativos esta transaccin y efecta el envo de la informacin electrnica a la Cmara Compensadora, quien separa y distribuye los archivos a las Entidades Giradas, las cuales, recibirn los archivos y se encargaran de impactar los movimientos de los cheques en las cuentas libradoras A continuacin se ver con ms detalle el comportamiento de cada uno de los circuitos antes mencionados en forma integrada, posibilitando ver claramente cada una de las sesiones dependiendo de la Entidad que lo realiza (Depositaria/Girada) y como es la relacin entre ellas. La figura 7.1 representa el flujo de datos entre las entidades involucradas correspondiente al circuito de escaneo de cheques en conjunto con el circuito de imgenes por rechazo.

Pag 85
Entidad Depositaria
Entidad Girada
Deposito por Caja
Registracin del Cheque
Si
Si es Cheque propio
Pago o Rechazo segn saldo suficiente
No Escaneo de cheques
Generacin y envo de archivo de cheques escaneados
Recepcin y procesamiento de archivo de cheques escaneados
Imputacin de cheques (Debito)
Imputacin de cheques (Crdito)
No
Cheque rechazado? Si
Recepcin de cheques rechazados
Generacin de cheques rechazados
Imputacin de cheques (Crdito y Debito)
No
Cdigo de rechazo genera imagen? Si
Bsqueda de la imagen correspondiente al cheque rechazado Generacin de archivo con imgenes por rechazo Recepcin y procesamiento de Imgenes por rechazo
Corresponde imagen?
Si Chequear imagen en Sucursal
No No
Imagen vlida para sucursal?
Si Aceptacin de imagen SI
Marcar rechazo de reclamo
Procesar rechazo de imgenes por rechazo
Generar rechazo de imgenes por rechazo
Figura 7.1 - Circuito de Depsito de Cheques
El proceso comienza con el depsito en la Entidad Depositaria del o los cheques por parte del cliente. De esta forma el cheque entra en el circuito para gestionar su cobro, cambiando su estado a lo largo del mismo. La Entidad Depositaria es la responsable de realizar la digitalizacin de todos los cheques as como la integracin de sus datos. Una vez concluida esta tarea, en forma
centralizada se genera Girada. Una vez aqu, monetaria, efectuando consecuencia de este rechazado o aceptado:
el archivo conteniendo todos los cheques a enviar a la Entidad se recepciona, se procesa el archivo y se realiza su imputacin los dbitos en las cuentas corrientes correspondientes. Como proceso, se plantean dos situaciones, el cheque puede ser
- Aceptado: en este caso, la Entidad Depositaria al da siguiente al no recibir rechazo, procede a la acreditacin del importe del cheque en la cuenta depositaria correspondiente. Concluyendo de esta manera con el circuito de digitalizacin de cheques. - Rechazado: La Entidad Girada genera un archivo conteniendo todos los cheques que desea informar como rechazados, con sus respectivos cdigos de rechazo, y lo enva a la Entidad Depositaria. La Entidad Depositaria al recibir los cheques rechazados debe reflejar estos en las respectivas cuentas de los clientes depositantes, impactando un movimiento de dbito y un movimiento de crdito, mostrando de esta manera el ingreso de los cheques al circuito y su posterior rechazo. La tarea posterior a la imputacin monetaria de los cheques rechazados es analizar su cdigo de rechazo asociado. En caso de: - Cdigo de rechazo que no genera imagen: Concluye el circuito de cheques rechazados. - Cdigo de rechazo que si genera imagen: Se buscan las imgenes correspondientes a los cheques que se han rechazado, se genera un archivo y se enva a la Entidad Girada. La Entidad Girada cuando recibe el archivo con imgenes por rechazo debe arbitrar los medios para efectuar la recepcin y procesamiento del mismo, donde debe chequear si corresponden a imgenes de cheques rechazados: - Si corresponden a cheques rechazados se enva a la sucursal para su chequeo visual. - Si no corresponden a cheques rechazados, se genera en forma automtica el rechazo de la imagen. Una vez que las imgenes se encuentran en la sucursal, se realiza el chequeo visual de las mismas. - En caso de poder contar con la imagen sin problemas de visualizacin se acepta la imagen dando por concluido el circuito de rechazos. - En caso de tener algn problema de visualizacin, por ejemplo, imagen ilegible, cheque mal escaneado, etc, la sucursal marcar dicha imagen como rechazada. Una vez obtenidos todos los rechazos, ya sea en forma automtica o porque una sucursal la marc, se genera el archivo de rechazo de imgenes por rechazo, el cual es enviado a la Entidad Depositaria.

Pag 87
La Entidad Girada recibe y procesa dicho archivo. De esta manera se concluye con el circuito de imgenes por rechazo. Como vemos en este ltimo caso, nos encontramos en la situacin en que la Entidad Girada an no cuenta con las imgenes de los cheques que ha rechazado. Como consecuencia de ellos existe a disposicin de esta entidad la posibilidad de efectuar reclamos sobre los cheques que ha recibido. En la siguiente figura 7.2 se muestra dicho circuito.
Entidad Depositaria Entidad Girada
Realizar reclamo en sucursal
Recepcin y procesamiento de archivo de reclamos
Generar archivo de reclamo
Verificacin 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 imgenes por cheques reclamados
No
Corresponde la imagen ?
Si
Controlar imagen en sucursal
Imagen vlida para sucursal?
Si
No
Marcar rechazo
Generar rechazo de imgenes por reclamo Procesar rechazo de imgenes por reclamo
Figura 7.2 - Circuito de Reclamos de Cheques

Pag 88
La posibilidad de efectuar reclamos se puede realizar sobre cualquier tipo de cheque recibido, tanto aceptado como rechazado. Los reclamos sirven para obtener las imgenes de aquellos cheques cuyo importe sea inferior al importe predefinido para el envo de imgenes del circuito de cheques. La Entidad Girada es la nica que puede realizar reclamos respecto de los cheques que ha recibido. Comienza en las sucursales quienes son las encargadas de realizar los reclamos, luego en forma centralizada se genera un archivo y se envan a la Entidad Depositaria. Una vez que la Entidad Depositaria ha recibido y procesado el archivo se verifica que el reclamo corresponda a un cheque escaneado y enviado por sta: - Si el reclamo no corresponde a un cheque enviado, se marca en forma automtica el reclamo con un nuevo cdigo de rechazo, se genera un archivo conteniendo los rechazos de imgenes por reclamo y se enva a la Entidad Girada. Al recibir el archivo la Entidad Girada, lo procesa y da por concluido el circuito de reclamos. - Si el reclamo corresponde a un cheque enviado, se busca la imagen asociada a este y se genera un archivo con todas las imgenes y se enva a la otra entidad. La Entidad Girada cuando recibe el archivo con imgenes por reclamo efecta la recepcin y procesamiento del mismo, donde chequea si corresponde a los reclamos efectuados: - Si corresponden a cheques reclamados se enva a la sucursal para su verificacin visual. - Si no corresponden a cheques reclamados, se genera en forma automtica el rechazo de la imagen. Una vez en la sucursal, se realiza la verificacin de las mismas. - Si se puede visualizar correctamente, se acepta la imagen y se da por finalizado el circuito de reclamos. - Si tiene errores al visualizarse, como por ejemplo imagen ilegible, cheque mal escaneado, etc, se marca dicha imagen como rechazada. Una vez que se marcan todos los rechazos, ya sea en forma automtica o porque una sucursal la marc, se genera el archivo de rechazo de imgenes por reclamo, el que es enviado a la Entidad Depositaria. La Entidad Depositaria recibe y procesa dichos rechazos, concluyendo con el circuito de imgenes por reclamo.
Modelo de casos de uso

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

Pag 89
En los procesos se identifican dos actores: Usuario y Sistema Centralizador. El primero representa a los usuarios que realizan el escaneo y la carga de los cheques en sucursales y el segundo representa al Sistema Central que gestiona la informacin de todas las sucursales. Para que un usuario pueda acceder al sistema deber identificarse previamente, una vez autenticado podr tener acceso a la informacin (registro electrnico y/o imagen) e ingresar nuevos cheques. Con estas funcionalidades definidas, el sistema estar compuesto por los siguientes grupos de casos de uso: Validacin: - Validar el ingreso correcto de un actor al sistema a travs de su nombre de usuario y su password y obtener la fecha en forma centralizada. - Verificacin y validacin de nmeros de cuentas depositarias en el momento del depsito del cheque. - Verificacin si corresponde a un cheque propio o un cheque de otra sucursal u otro banco. Apertura y cierre de operaciones: - Realizar la apertura del da en la Sucursal: Se reciben archivos del sistema centralizador:

Cheques Presentados Cheques rechazados recibidos Reclamos recibidos
- Realizar el cierre del da provocando la generacin y envo de los archivos correspondientes a

Cheques depositados Reclamos enviados Rechazos enviados
Bsqueda de informacin: (Utilizado por el usuario) - Desplegar la informacin existente en la base de datos. Permitir ver slo los registros electrnicos/imagen de los cheques ingresados al sistema por esa sucursal y aquellos cheques que fuesen enviados a esa sucursal para gestionar su cobro. - Listados de Cheques ingresados al sistema. - Cheques Recibidos con visualizacin de su imagen. - Cheques Enviados con visualizacin de su imagen. - Consultar la historia de un cheque (recibido, enviado, aceptado, rechazado, envo de imgenes por reclamo/rechazo, recepcin de imgenes por reclamo/rechazo).

Pag 90
Depsito de cheques: (Utilizado por el usuario): - Depsito y digitalizacin de cheques: Esta tarea se realiza en el momento que el cliente se presenta por caja y efecta el depsito del cheque. En caso de se un cheque propio el mismo se registra y es pagado o no por caja, caso contrario, si es un cheque que pertenece a otra sucursal o a otro banco el cheque es digitalizado con escaners especiales que capturan en forma automtica los datos de los cheques (banco, sucursal, cdigo postal, nmero de cheque y nmero de cuenta) por lo que resta la integracin manual por parte del usuario del nmero de cuenta depositaria e importe del cheque depositado. En este proceso la imagen capturada del cheque se asocia al registro electrnico del mismo definiendo en l, path y nombre del archivo fsico de la imagen. Administracin de datos: tener a disposicin ABM que permitan - ABM de Reclamos - Generar Rechazos de Imgenes recibidas por Reclamos - Generar Rechazos de Imgenes recibidas por Rechazos

Validacin
Apertura y cierre de operaciones
Bsqueda de Informacin Usuario Depsito de Cheques Sistema Centralizador
Administracin de datos
Figura 7.3 - Diagrama de casos de uso

Pag 91
Diseo
El Modelo Arquitectnico
El objetivo principal del diseo arquitectnico es representar componentes que interacten entre ellos y tener asignadas tareas especficas, ser flexible y extensible y representar las relaciones de control entre las partes. El sistema en estudio tiene el comportamiento de un sistema Distribuido e Interactivo como ya lo mencionamos. Los cuales se ajustan a los siguientes patrones arquitectnicos: - Patrn Broker: Soporta la distribucin y la integracin de componentes. Nos interesa que la aplicacin que usa un objeto lo haga a travs de la interfaz ofrecida por ese objeto, despreocupndose de los detalles de su implementacin o su ubicacin fsica y que las invocaciones de servicios remotos sean transparentes respecto de su ubicacin.
Cproxy Broker Sproxy
Cliente
Servidor
Figura 7.4 - Patrn Broker
Para el diseo de aplicaciones con interfaces grficas se utiliza el patrn Model-ViewController. La lgica de una interfaz de usuario cambia con ms frecuencia que los almacenamientos de datos y la lgica de negocio. Si se realiza un gran diseo, que mezcle los componentes de interfaz y de negocio, cuando se necesite cambiar la interfaz, se deber realizar un arduo trabajo para poder modificar los componentes de negocio, lo que implica un mayor riesgo de cometer errores. Por lo cual, se realiza un diseo que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lgica de negocio o los datos. - Patrn Model-View-Controller: Interaccin usuario-computadora. Nos interesa poder mantener mltiples vistas de un mismo modelo, mantenindolas actualizadas ante cualquier cambio del estado del modelo y poder incorporar nuevos controladores si fuera necesario, sin alterar el comportamiento del modelo.
Vista Modelo Controlador
Figura 7.5 - Patrn Broker Arquitectura de Software: Estilos y Patrones

- Patrn Layers: Independencia de plataforma. 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.
Capa N
Nos interesa poder descomponer todo base de datos, en grupos o subtareas, un nivel de abstraccin particular, de reemplazado por implementaciones
Capa N-1
Capa 0
Figura 7.6 - Patrn Layers
Una vez identificados los patrones a utilizar los integramos de la siguiente manera:
Broker Layer Capa N Cproxy Capa N - 1
Sproxy
Cliente Vista Controlador Capa 0
Servidor Modelo
Figura 7.7 - Integracin del patrn Broker, Model-View-Controller y Layers
La distribucin es preferente, por lo cual, Broker es el primer patrn a aplicar ya que el ambiente es el de un sistema distribuido, y posiblemente heterogneo, con componentes independientes que cooperan entre s. Lo que se intenta resolver es el problema de construir un sistema de software complejo como un conjunto de componentes desacoplados que interoperan, lo cual conlleva a mayor flexibilidad y facilidad en el mantenimiento y futuros cambios, en lugar de una aplicacin monoltica. Al partir la funcionalidad en componentes independientes, el sistema se vuelve potencialmente escalable y distribuido. Por lo tanto: - Creamos un objeto que actu de broker al sistema remoto. - Creamos una interfaz para definir el comportamiento remoto del sistema. - Luego, implementamos un proxy para el cliente y otro proxy para el servidor. - Los detalles de comunicacin quedan dentro del proxy cliente y del proxy servidor.

Pag 93
Para el cliente es transparente la forma de comunicacin entre los componentes, 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.8 - Diagrama de clases del patrn Broker
Si aplicamos a nuestro caso de estudio cada componente del patrn los mismos, estaran ubicados de la siguiente forma en el esquema:
CLIENTE (A) PROXY DEL LADO DEL CLIENTE (A) BROKER PROXY DEL LADO DEL SERVIDOR
Suc 1
CASA MATRIZ
SERVIDOR
Sistema Centralizador
Host_Central
Servidor Central
CLIENTE (B) SERVIDOR
PROXY DEL LADO DEL CLIENTE (B)
Figura 7.9 - Distribucin de los componentes del patrn Broker.
Ahora veremos un diagrama de secuencia que representa la interaccin entre los componentes del sistema. En este diagrama se ve el caso en que el usuario realiza la apertura del da: 1. Se inicia la aplicacin usuario. Durante la ejecucin del programa, el usuario invoca un mtodo de un objeto servidor remoto solicitndole la fecha del da. 2. La aplicacin usuario solicita proxy cliente la fecha del da para realizar la apertura. 3. El proxy cliente empaqueta los datos y reenva la solicitud al broker. 4. El broker localiza el servidor al cual se esta realizando la peticin, en este caso al Host Central. Puesto que el servidor esta disponible localmente, el broker enva el mensaje al proxy servidor correspondiente.
5. El proxy servidor desempaqueta todos los parmetros e informacin relevante, e invoca el servicio apropiado. 6. Despus que la ejecucin del servicio se completa, el servidor regresa el resultado al proxy servidor, el cual lo empaqueta en un mensaje con informacin relevante, y lo pasa al broker. 7. El broker enva la respuesta al proxy cliente. 8. El proxy cliente recibe la respuesta, desempaqueta el resultado y lo regresa a la aplicacin usuario. Obteniendo de esta manera la fecha del da. El proceso cliente contina con sus operaciones.
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 da Empaquetar datos
Reexpedir respuesta Encontrar cliente Regresar Desempaquetar datos Recibe resultados
Figura 7.10 - Diagrama de secuencia de la interaccin entre componentes
A continuacin se integra el patrn Model-View-Controller en el patrn Broker. Si bien existen dos patrones arquitectnicos Model-View-Controller (MVC) y Presentation-Abstraction-Control (PAC) que son aplicables a sistemas interactivos, segn la clasificacin realizada por [Buschmann+96] y descripta anteriormente en este trabajo, hemos optado por el MVC.

Pag 95
Analizando los patrones, observamos que cada agente PAC consiste de los componentes presentacin, abstraccin y control manteniendo una analoga parcial con el patrn MVC. El componente control es similar a lo que seria el componente control en la arquitectura MVC. Este procesa los eventos externos y actualiza los componentes abstraccin y presentacin. Es diferente del componente control del patrn MVC en que pasa las actualizaciones realizadas a su agente PAC padre. El componente abstraccin contiene los datos al igual que el componente modelo en el patrn MVC. Sin embargo, l puede contener solo parte de la estructura de datos de la aplicacin, y no juega un papel activo en la notificacin de los cambios. El componente presentacin es exactamente igual que el componente vista en el patrn MVC. Cabe destacar que estos tres componentes forman cada uno de los agentes PAC, los cuales a su vez forman una estructura jerrquica en forma de rbol de agentes cooperando. Cada agente es responsable de un aspecto especifico de la funcionalidad de la aplicacin, provocando que el sistema quede dividido en mltiples componentes presentacin, abstraccin y control, por lo cual no fue el patrn elegido para el caso de estudio propuesto, adems agrega innecesariamente una mayor complejidad en el diseo. En el diseo de nuestro caso de estudio finalmente se opt utilizar el patrn MVC por las siguientes razones: - El sistema tiene la funcionalidad central que no est distribuida sino se ubica en un nico centro - La misma informacin 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 slo la cantidad de cheques escaneados por una sucursal, sin el detalle de cada uno de ellos). Como se ha visto los elementos de este patrn son: - Modelo: datos y reglas de negocio. - Vista: muestra la informacin del modelo al usuario. - Controlador: gestiona las entradas del usuario. Los servidores contienen los diferentes componentes del modelo y los clientes los componentes vista y controlador. La siguiente figura muestra la conectividad de cada uno de los componentes y las tareas que lleva a cabo cada uno de ellos.

Pag 96
Observador 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, Vista) conectar manejarEventos() llamada a servicios
Figura 7.11 - Diagrama de clases del patrn Model-View-Controller
En la siguiente figura se muestra cada componente del patrn en nuestro caso de estudio:
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.12 - Distribucin de los componentes del patrn Model-View-Controller
Ahora veremos cual es la conducta dinmica de este patrn al realizar la conexin al sistema tras ingresar clave y contrasea. 1. El usuario interacta con la interfaz de usuario (vista) de alguna forma, como dijimos ingresando la clave y contrasea. 2. El controlador recibe, por parte de los objetos de la vista, la notificacin de accin solicitada por el usuario. El controlador gestiona el evento que llega a travs de un manejador de eventos. 3. El controlador accede al modelo, actualizndolo con la accin solicitada por el usuario, es decir, interpreta el evento y activa el procedimiento de validacin y verificacin de clave y contrasea en el modelo.
4. El modelo realiza el servicio requerido. internos.
Esto produce un cambio en sus datos
5. El modelo notifica del cambio a todas las vistas y controladores registrados con el mecanismo de propagacin de cambios, llamando a sus procedimientos de actualizacin. 6. Cada controlador registrado recupera los datos del modelo para activar o desactivar ciertas funciones del usuario, como por ejemplo el perfil del usuario que se ha conectado. 7. Cada vista solicita a su controlador los datos modificados del modelo y los refleja en pantalla, por ejemplo mostrando el nombre del usuario que se ha conectado. 8. El controlador original recobra el control y retorna desde su procedimiento manejador de eventos. 9. La interfaz de usuario espera nuevas interacciones del usuario, comenzando con el ciclo nuevamente.
Controlador Manejador de eventos
Modelo
Vista
servicio notifica actualiza display Toma_datos
actualiza Toma datos
Figura 7.13 - Diagrama de secuencia para la conexin de un usuario al sistema.
Los componentes de los patrones antes mencionados requieren establecer conexiones que les permitan comunicarse teniendo en cuenta que estamos considerando que el caso de estudio es un sistema distribuido. Esta necesidad de comunicacin nos lleva a estructurar dichos componentes en capas mediante la utilizacin del patrn Layers. Se tom la decisin de hacer uso de este patrn debido a que claramente se observa la necesidad de comunicacin entre los distintos componentes lo cual nos lleva a pensar que deberamos independizar la tarea de comunicacin de las tareas del
sistema operativo. Separando dos capas independientes, una capa de nivel ms bajo que realice las tareas especficas de comunicacin y otra capa ubicada sobre la anterior, que realice las tareas propias del Sistema Operativo. En ambos caso hacemos uso de software ya existente. La integracin final de todos los patrones sera:
Broker Layer S.O
Cproxy
Comunicaciones
Sproxy
Cliente Vista Controlador
Servidor Modelo
Figura 7.14 - Integracin del patrn Broker, Model-View-Controller y Layers.
Capa Sistema Operativo: Es la capa de software que permite gestionar los mecanismos
de comunicacin, independizar el servicio de su implantacin y de los protocolos de comunicaciones, adems, permite la convivencia de distintos servicios en un mismo sistema y la transparencia del mismo. El sistema operativo a utilizar en nuestro caso de estudio ser alguna de las diferentes plataformas existentes.
encarga de transportar los mensajes que intercambian los distintos componentes. El protocolo de comunicaciones que utilizamos es TCP/IP, que a su vez, como ya sabemos, esta estratificado en capas por lo cual es una aplicacin ms del patrn Layers. La principal ventaja de la estructuracin por capas es que cada capa cumple con funciones y servicios determinados que brinda a la otra capa, esto permite una mejor organizacin. Tambin aplicamos el patrn Layers para desarrollar la tarea de acceso a datos en el servidor. Se identifican las capas:
Capa de Comunicacin: En esta capa se encuentra el protocolo de comunicacin, se

Pag 99
Capa de Servicio
Capa de Acceso a Datos
Procedimiento Almacenado
Tablas y Vistas
Figura 7.15 - Estructura de Capa de Servicio, Capa de Acceso a Datos y Base de Datos.
En la capa de servicio cada tarea dentro de esta capa se puede encapsular en un mtodo de un componente. Para los procesos ms complejos que requieren varios pasos y transacciones de ejecucin larga, la aplicacin necesita disponer de un modo de organizar las tareas y almacenar el estado hasta que el proceso se haya completado. Adems, permite realizar el uso directo por parte de componentes de presentacin o su encapsulacin como servicio y llamada a travs de una interfaz de servicios, que coordina la conversacin con los llamadores del servicio. Capa de acceso a datos, esta capa se encarga de administrar el almacenamiento y obtener el acceso a los datos. Los componentes de acceso a datos exponen mtodos para insertar, eliminar, actualizar y recuperar datos. Recibe las solicitudes de la capa de servicio y las convierte en solicitudes a la base de datos especfica. Esta capa es fundamental para que los cambios de base de datos no afecten a la aplicacin en general. Puede utilizar un componente de acceso a datos para centralizar la administracin de la conexin y todo el cdigo relacionado con un origen de datos. Se realiza la implementacin de las consultas y operaciones de datos como procedimientos almacenados para mejorar el rendimiento y la facilidad de mantenimiento.
El Componente Modelo
Una vez planteado el modelo arquitectnico de nuestro caso de estudio, el prximo paso a seguir es el desarrollo del diseo del componente modelo del patrn ModelView-Controller aplicado anteriormente. De acuerdo a nuestro anlisis previo, el modelo se conforma por tres componentes que interactan entre s. - Deposito de Cheques se encarga de la tarea de realizar y reflejar el depsito de los cheques en sucursales y su posterior envo y del proceso de rechazo de los mismos.

Pag 100
- Recepcin de Cheques es el encargado de la recepcin y procesamiento de los cheques recibidos, gestin de cobro y rechazo de cheques. - Reclamos de Cheques efecta la carga y procesamientos del envo de reclamos, as como tambin el la recepcin y gestin de imgenes a enviar.
MODELO
Deposito de Cheques Solicita imagen Reclamos de Cheques Solicita imagen Recepcin de Cheques
Figura 7.16 - Componentes del Modelo
Las principales entidades que intervienen en cada subcomponente del modelo son: Sucursal: Representa a una sucursal bancaria, responsable de la apertura y cierre de operaciones, donde se recibe y se enva archivos desde y hacia el Sistema Centralizador.
Sucursal Banco
apertura () generarArchEnvio () generarArchImgRech() generarArchRechazo () cierre() ...
Figura 7.17 - Clase Sucursal
Cuenta: Representa una cuenta bancaria de una sucursal de banco. Posee uno o ms titulares que son Clientes del Banco, tipo de moneda y tipo de cuenta. Entre otras cosas, es responsable de procesar depsitos y extracciones.
Cliente
Cuenta
numero extraer() depositar() saldo() puedoDebitar () debitar() acreditar() existeCuenta()
Sucursal
apertura () generarArchEnvio () generarArchImgRech () generarArchRechazo () cierre() ...
TipoMoneda
TipoCuenta
Figura 7.18 - Clase Cuenta Arquitectura de Software: Estilos y Patrones

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

importe() fechaEmision() puedeDebitar () debitar() miCuenta numero extraer() depositar() saldo() puedoDebitar () debitar() acreditar() existeCuenta()
Figura 7.19 - Clase Cheque
Cuando un cheque es depositado en una cuenta, puede ser que corresponda a la misma sucursal o no. Este segundo caso es el que nos interesa en particular, ya que estos cheques tienen un tratamiento especial, su cobro debe ser gestionado en otro banco. Adems de la informacin propia del cheque, conoce la cuenta en la que se deposit, y es responsable de generar el registro con su informacin para enviar al sistema centralizador, procesar el depsito o el rechazo segn lo que ocurra. Para modelar el cheque depositado en otra sucursal, podramos pensar en subclasificar a Cheque e incorporar el nuevo comportamiento. Si Cheque tuviera ya otras subclasificaciones como por ejemplo Cheque Diferido, cada una de estas subclases debiera admitir la posibilidad de depositarse en otra sucursal. Por otro lado, el cheque existe como entidad, y se requiere que dinmicamente sea considerado como cheque depositado. Por ello, la subclasificacin no es la forma ms adecuada de representarlo, siendo la composicin la mejor manera.
Cuenta
numero extraer() depositar() saldo() puedoDebitar () debitar () acreditar() existeCuenta()
miCuenta
cuentaDeposito
Cheque numero
importe() fechaEmision() puedeDebitar () debitar() miCheque
ChequeOtraSucursal
generarRegistro () procesarRechazo() asociarImagen()
Figura 7.20 - Clase ChequeOtraSucursal.
Para generalizar ms este esquema y dar la posibilidad a que un cliente pueda trabajar indistintamente con un Cheque o con un Cheque Depositado, aplicamos el patrn Decorator.
Cheque Cuenta
numero .. miCuenta numero importe() fechaEmision() puedeDebitar () debitar ()
ChequeNormal
numero
ChequeDepositado numero
acreditar() importe() fechaEmision() puedeDebitar () debitar() cuentaDeposito ..
Cuenta
numero
ChequeOtraSucursal
generarRegistro () procesarRechazo () asociarImagen ()
importe() ^miCheque.importe()
Figura 7.21 - Aplicacin Patrn Decorator
Consideramos la clase cheque como una interfaz permitiendo de esta manera un tratamiento indistinto tanto a los cheques normales como a los cheques depositados. Considerando a cheques normales aquellos cheques que son presentados en caja para su cobro, pero no son depositados en una cuenta. Caso contrario ser un cheque depositado, que a su vez puede ser un cheque propio (cuya cuenta origen pertenece a la sucursal del deposito) o un cheque de otro banco u otra sucursal. La separacin de estas clases se debe a que cada una de ellas tiene un comportamiento particular. En nuestro caso solo nos centraremos en el comportamiento de los cheques depositados. Si bien aplicamos el patrn Decorator, en los diagramas subsiguientes utilizamos la interfaz cheque sin representar sus subclases para dar mayor simplicidad al esquema del modelo. Depsito de Cheques Aqu se modelizan los procedimientos del depsito de un cheque, desde su registracin por caja y digitalizacin hasta el procesamiento y generacin de archivo para su posterior envo al Sistema Centralizador al efectuar el cierre de operaciones en la sucursal. As como tambin la apertura y recepcin de los rechazos correspondientes a cheques depositados y enviados el da anterior. Al efectuar el depsito de un cheque por caja, se cargan todos los datos referentes a la boleta y al cheque. El depsito se realiza en la cuenta del cliente depositante, el cual debe contar con los siguientes datos: tipo de cuenta (cuenta corriente, caja de ahorros, etc.), tipo de moneda (pesos, dlares, euros, etc.), sucursal y nmero. Todos
estos datos en su conjunto son necesarios para indicar la existencia y validez de la cuenta. Otro dato requerido es la fecha del depsito. En caso de que el cheque corresponda a una cuenta de la sucursal donde se realiza el depsito, el mismo ser debitado de su cuenta origen en si el saldo es suficiente y ser acreditado en la cuenta del cliente depositante. Por lo tanto el cheque adopta el estado aceptado. Caso contrario, es decir, si corresponde a un cheque de otra sucursal o de otro banco, pasamos a la fase de digitalizacin, quedando el cheque en estado
depositado.
Cada cheque tiene en su parte inferior un cdigo de barras que, al ser digitalizado, permite la captura automtica del banco, sucursal, cdigo postal, nmero de cheque y nmero cuenta al que pertenece el cheque, restando slo la tarea de completar en forma manual su importe, quedando de esta forma generado el registro electrnico del cheque con su imagen digitalizada. Al finalizar el da, 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 envo, esto provoca que los cheques cambien al estado enEspera. El archivo generado es transferido al Sistema Centralizador, quien una vez recibidos los archivos de todas las sucursales los procesa conformando un nico archivo para enviar a la Cmara Compensadora. Al da siguiente, al realizar la apertura de operaciones en la sucursal, se reciben los rechazos de los cheques depositados el da anterior. En este procedimiento se contrastan los cheques enviados con los rechazos recibidos. Si no se recibe rechazo de un cheque, el mismo cambia su estado a aceptado y es acreditado en la cuenta depositaria asociada. Si se recibe rechazo de un cheque, se procesa el rechazo del mismo, esto implica la realizacin de un movimiento de debito y crdito en la cuenta depositaria asociada, provocando que el cheque cambie su estado a rechazado. Este proceso tambin involucra el anlisis del cdigo de rechazo recibido. Si este cdigo implica generar imagen se busca la imagen del cheque y se conforma un registro con la imagen. Con la realizacin del cierre de operaciones en la sucursal, se genera un archivo con las imgenes a enviar y este archivo es transferido al Sistema Centralizador.

Pag 104
Deposito de Cheques Sucursal Cliente Cuenta

numero extraer() depositar() saldo() puedoDebitar () debitar () acreditar() existeCuenta() numero apertura() cierre() generarArchEnvio () generarArchImgRech() ... chequeOtraSucursal
Banco
TipoMoneda
sucursal:: apertura () RecepcionProcesamientoChequesRechazados() RecepcionProcesamientoChequesPresentados() RecepcionProcesamientoChequesReclamados() RecepcionProcesamientoChequesRechazados() Por cada cheque rechazado Buscar Registro electrnico en ChequeOtraSucursal Si lo encuentra ChequeOtraSucursal .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.22 -
Depsito de Cheques
Recepcin de Cheques El componente Recepcin de Cheques es el encargado de la recepcin y procesamiento de los cheques recibidos, su imputacin monetaria y generacin de rechazos. Al momento de la apertura de operaciones de la sucursal, se reciben los cheques que han sido escaneados en otros bancos para gestionar su cobro. Todos los cheques recibidos se encuentran en estado recibido y luego comienza el procesamiento para generar su imputacin monetaria en las cuentas. Si el cheque puede debitares, entonces se debita su importe del saldo de la cuenta, tomando en este momento el estado aceptado. En caso de no poder debitarse se marca el cheque con un cdigo de rechazo y se genera el registro adoptando el cheque el estado rechazadoConCodigo o rechazado dependiendo si se requiere la imagen o no.
rechazadoConCodigo hasta que se reciba la imagen correspondiente, pasando luego definitivamente a estado rechazado.
Al realizar el cierre de operaciones de la sucursal se tomaran todos los cheques rechazados y se generara un archivo que ser enviado al Sistema Centralizador para su gestin.
En caso de ser rechazado con el requerimiento de imagen, se mantiene en estado

Pag 105
Recepcin Cheques Banco
Cliente Cuenta
numero extraer() depositar() saldo() puedoDebitar () debitar() acreditar() existeCuenta()
Sucursal
numero ... apertura () generarArchRechazo () cierre () ... chequeOtraSucursal
TipoMoneda
TipoCuenta
cuentaDeposito
ChequeOtraSucursal
generarRechazo () procesarRegistro() asociarImagen()
Sucursal:: apertura () RecepcionProcesamientoChequesPresentados () Por cada cheque presentado a debitar Si cheque .puedeDebitarse () ent cheque . debitar () sino generarRechazo ( cheque) finsi fin
miCuenta
Cheque Estado
estado numero importe() fechaEmision() puedeDebitar () debitar() miCheque
Imagen
Cheque:: debitar () miCuenta.debitar (this.importe())
CodigoRechazo
Estado
Fecha
Recibido
RechazadoConCodigo
Rechazado
Aceptado
Figura 7.23 - Recepcin de Cheques
Para los casos de la representacin y comportamiento de los cheques a travs de su estado podramos hacer uso del patrn State, cuyo propsito permite cambiar fcilmente el comportamiento de un objeto en tiempo de ejecucin. Los objetos son estados, que se mantienen a travs de los atributos y el comportamiento que se define en los mtodos. El comportamiento dinmico del objeto se alcanza delegando todas las llamadas a mtodos que confan en ciertos valores para un objeto que representa el estado y al modificar esos objetos tambin se obtiene un comportamiento diferente. Una alternativa en lugar de la aplicacin del patrn State es la utilizacin de una sentencia de seleccin mltiple como switch para decidir que tareas se realizan de acuerdo al valor del estado que adopta el cheque. Al utilizar el patrn State ponemos todo el comportamiento asociado a un estado en un objeto, evitando el uso de switch monolticos para los diversos casos as como tambin la replicacin de cdigo, permitiendo la incorporacin de nuevos estados sin afectar lo ya desarrollado. En nuestro caso de estudio vemos que el objeto ChequeOtraSucursal cambia su comportamiento de acuerdo al estado en que se encuentra. Un cheque que ha sido depositado por caja y digitalizado, permanecer en estado depositado, hasta que el cierre de operaciones en la sucursal genere el archivo de envo provocando el cambio de estado de los cheques a enEspera.
rechazado segn tenga un cdigo de rechazo asociado o no.

Una vez recepcionado el archivo de rechazos el cheque adoptar el estado aceptado o
Pag 106
El comportamiento del cheque en la Recepcin de Cheques, tambin tendr cambios de estados. Al ser recibido, se encuentra en estado recibido, que luego de ser imputado cambiar a estado aceptado, rechazado o rechazadoConCodigo dependiendo de la situacin. Un esquema de aplicacin del patrn State para representar los cambios de estados de los cheques se muestra a continuacin.
CodigoRechazo ChequeOtraSucursal Estado
setEstado() procesarRegistro() procesar()
Fecha
Recibido
procesar()
RechazadoConCodigo
procesar()
Rechazado
procesar()
Aceptado
procesar ()
Figura 7.24 - Aplicacin del Patrn State en el Componente Recepcin de Cheques
Reclamos de Cheques El componente Reclamo de Cheques es el encargado de la recepcin y procesamiento de cheques reclamados tanto enviados como recibidos. Al inicio del da, la sucursal recibe los reclamos que se han efectuado por otros bancos para su procesamiento as como tambin las imgenes reclamadas que se han recibido por reclamos efectuados a otros bancos. Reclamos Recibidos Por cada reclamo recibido se busca el cheque correspondiente a ese reclamo. Si corresponde a un cheque digitalizado en esta sucursal se ubica su imagen y se asocia al registro electrnico. Si no corresponde, se genera el rechazo del reclamo. En ambos casos al realizar el cierre de operaciones se envan los archivos al Sistema Centralizador para su gestin. Reclamos Enviados Cuando la sucursal hace un reclamo, como ya dijimos este corresponde a un cheque anteriormente recibido. La sucursal genera un registro con los reclamos a realizar y al cierre del da se envan 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 electrnico del cheque recibido, finalizando de esta manera con el circuito de reclamos.

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

Tanto la vista como el controlador dependen del componente modelo lo cual no sucede en forma inversa, como ya se ha mencionado. Esta separacin permite construir y probar el componente modelo independientemente de la representacin visual. El modelo tiene diversas vistas, cada una con su correspondiente controlador. La vista maneja la visualizacin de la informacin del modelo al usuario. En nuestro caso de estudio contaremos con vistas ubicadas en cada una de las sucursales y otras en el Sistema Centralizador. La vista en una sucursal determinada slo muestra la informacin referente a cheques recibidos, enviados, rechazados y reclamados correspondientes a esa sucursal especficamente. La vista en el Sistema Centralizador muestra la informacin referente a cheques recibidos, enviados, rechazados y reclamados de todas las sucursales. Mientras la vista en las sucursales muestra informacin con un alto nivel de detalle (cheque por cheque), la vista en el Sistema Centralizador slo muestra un resumen de las transacciones realizadas por sucursal. Tambin se muestra el estado en que se encuentra cada una de las sucursales (por ejemplo estado apertura del da, estado consultando, estado escaneando, etc.) El controlador interpreta las acciones del usuario informando al modelo y a la vista para que cambien segn resulte apropiado. Existe un controlador por cada vista, el cual permite relacionar la solicitud de servicio realizada en la vista asocindola al evento que detecta el controlador. Un ejemplo dentro de nuestro caso de estudio es cuando se deposita un cheque y se cargan todos los datos de la cuenta, el evento de pulsar la tecla enter activar a travs del controlador una peticin de servicio al modelo que ser una llamada al mtodo existeCuenta(). El modelo ejecuta el mtodo y notifica del resultado de la verificacin a la vista y controlador registrados con el mecanismo de propagacin de cambios. Una vez finalizada esta notificacin vuelve a tomar el control el controlador. El mecanismo de propagacin de cambios realizado aqu se lleva a cabo a travs de la implementacin del patrn de diseo Observer. Este patrn como ya mencionamos nos permite definir una dependencia de uno a muchos entre un objeto de datos y n objetos (observers) que representan estos datos, de manera que si desde uno de los observers se cambian los datos, el objeto de datos notifica este cambio a todos los observers restantes.

Pag 108
Un componente de este patrn cumple el rol de subject, quien contiene mtodos mediante los cuales cualquier observer o vista se puede suscribir a l referencindose a as mismo. El subject mantiene una lista de sus observers. Los observers deben implementar mtodos determinados mediante los cuales el subject es capaz de notificar a sus observers "suscriptos" los cambios que sufre para que todos ellos puedan refrescar el contenido representado. Asociando los componentes del patrn de diseo Observer con los componentes del patrn arquitectnico Model-View-Controller, determinamos que el componente modelo es quien cumple el papel del subject y los componentes vista y controlador actan como observers. Un ejemplo de aplicabilidad del patrn Observer es cuando se reciben los archivos de imgenes por reclamo o por rechazo y se notifica a las sucursales la recepcin de las mismas informando que estn a disposicin para su toma y procesamiento.
Subject aadir(Observer) eliminar(Observer) notificar()
observer do: { :each|each avisar]
Observer avisar()
ConcreteSubject estado obtenerEstado() definirEstado()

return estado;
ConcreteObserver estadoObserver avisar()

estadoObserver= subject->obtenerEstado ();
Figura 7.25 - Patrn Observer

Pag 109
Captulo 8 Conclusiones y Trabajos Futuros

Conclusiones
La resolucin de este trabajo nos permiti introducirnos en el tema de patrones como herramienta para la resolucin de problemas, haciendo hincapi en la reutilizacin de soluciones a problemas ya pensados y resueltos con anterioridad. An sin proponernos, observamos que en forma intuitiva muchas veces se hace uso de patrones sin una aplicacin formalizada. La gran variedad de patrones existentes hace que podamos utilizarlos en casi todo el diseo del sistema, es decir, ante una situacin, es muy probable que encontremos un patrn que la resuelva. Los patrones no son siempre la solucin adecuada o mejor para un problema. Si bien aaden flexibilidad, tambin aaden complejidad. Por esto se debe ser cuidadoso al momento de seleccionar patrones y analizar muy bien las ventajas y desventajas de su aplicacin. Siempre hay que recordar que los patrones son un punto de partida y no dogmas incuestionables. Como conclusin final y en base a nuestra experiencia podemos decir que disear con patrones no es aplicar todos los patrones que se conocen en el diseo del software, sino resolver cada problema de diseo que surge con un patrn apropiado, teniendo en cuenta que un uso excesivo de patrones fcilmente terminar en una arquitectura compleja.
Contribuciones
El principal aporte de este trabajo consiste en: - Recopilacin de los principales patrones arquitectnicos y patrones de diseo con claros ejemplos de aplicacin. - Brindar elementos necesarios para poder optar por uno u otro patrn frente a una problemtica en particular describiendo sus componentes principales y mecanismos de comunicacin. - Mostrar la evolucin del anlisis y diseo de un sistema bancario modelando la estructura bsica a travs de los patrones arquitectnicos, proporcionando un conjunto de subsistemas predefinidos, incluyendo reglas y pautas para su organizacin para luego refinar estos subsistemas o componentes mediante el uso de patrones de diseo.
Trabajos futuros
La siguiente tarea a realizar es la implementacin y validacin del modelo. Otros posibles trabajos futuros se enumeran a continuacin:
- La aplicacin de los patrones en diseos preexistentes: En algunas reas, existen muy buenas microarquitecturas probadas y testeadas. Facilitar la aplicacin contribuye a lograr mejoras en calidad, productividad y costos. - Independencia de la plataforma: La gran cantidad de arquitecturas de software y hardware y la coexistencia de diferentes estndares demandan investigacin y trabajo en esta lnea para lograrlo. - Aplicacin de lenguajes ADLs al trabajo desarrollado correspondiente al caso de estudio. - Integracin con otras aplicaciones bancarias.

Pag 111
Bibliografa
[Bellas] F. Bellas Permuy. Introduccion al Diseo con Patrones Departamento de Tecnologas de la Informacin y las Comunicaciones (TIC). Universidad de A Corua. http://www.tic.udc.es/~fbellas/teaching/pfc3/IntroPatrones.pdf [Buschmann+96] F. Bushmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal Pattern-Oriented Software Architecture: a system of patterns. Ed. Wiley. 1996. J. Casanovas. Usabilidad y Arquitectura del Software. 2004. http://www.alzado.org/articulo.php?id_art=355
[Casanovas04]
[Diaz06]
M. Diaz. Cmo desarrollar una arquitectura software: los lenguajes de patrones. 2006 http://www.programacion.net/articulo/lenguajes_patrones/
[Fowler97]
M. Fowler. Analysis Patterns: Reusable Object Models. AddisonWesley. 1997.
[Fowler05]
M. Fowler. Patterns of Enterprise Application Architecture. AddisonWesley. 2005.
[Gamma+95]
E. Gamma R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley. 1995.
[Garcia98]
Objetos. 1998.
F. Garca Pealvo. Patrones. De Alexander a la Tecnologa de
http://zarza.usal.es/~fgarcia/doc/patrones1.pdf [Griman+05] A. Grimn, M. Prez, L. Mendoza.
Estudio de la influencia de mecanismos arquitectnicos en la calidad del software. 2005.
http://www.lisi.usb.ve/publicaciones/03%20evaluacion/evaluacion_0 8.pdf [Lago04] R. Lago. Patrones de Diseo Software. 2004 http://www.proactivacalidad.com/java/patrones/index.html#algunos_patrones

Pag 112
[Larman03]
C. Larman. UML y Patrones. Una Introduccin al Anlisis y Diseo Orientado a Objetos y al Proceso Unificado. 2 Edicin. Editorial Prentice Hall. 2003. R. Martin. The Strategy, Template Method, and Bridge Patterns. 2004. http://today.java.net/pub/a/today/2004/10/29/patterns.html
[Martin04]
[Montaldo05]
D. Montaldo. Patrones de Diseo de Arquitecturas de Software Enterprise. 2005. http://www.fi.uba.ar/materias/7500/montaldotesisdegradoingenieriainformatica.pdf
[Ortiz04]
A.Ortiz Ramirez. Introduccin a los Patrones. ITESM CEM. 2004. http://webdia.cem.itesm.mx:8005/web/200413/cb00894/patrones/p atrones.pdf
[Pressman98]
R. Pressman. Ingeniera del Software Un Enfoque Prctico. Cuarta Edicin. Editorial Mc Graw Hill. 1998.
[Reynoso04]
C. Reynoso. Introduccin a la Arquitectura de Software. Versin 1.0. Marzo 2004 http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq /intro.asp
[Reynoso+04]
C. Reynoso, N. Kicillof, Estilos y Patrones en la Estrategia de Arquitectura de Microsoft. Versin 1.0. Marzo de 2004. http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq /style.asp
[Rosanigo00]
Z. Rosanigo. Maximizando reuso en software para Ingeniera Estructural Modelos y Patrones. 2000.
[Rottenstein06]
V. Rottenstein. Type Object Pattern. 2006 http://1879.blogspot.com/2006/04/type-object-pattern.html
[Stelting+03]
S. Stelting, O. Maassen, Patrones de Diseo Aplicados a JAVA, Pearson Educacin S.A. Prentice Hall. 2003.
[Tallon98]
A. Talln. Patrones de Diseo. Reutilizacin de ideas. http://www.aqs.es/web/files/designpatterns.html

Pag 113
[Tanembaum02]
A. S. Tanembaum. Distributed System Principles and Paradigms. Editorial Prentice Hall. 2002.
[Welicki06]
L. Welicki. Patrones y Antipatrones: una Introduccin. 2006. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/ MTJ_2864.asp

Pag 114

Tesina Arquitectura de Software

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesina Arquitectura de Software

Uploaded by

Copyright:

Available Formats

Arquitectura de Software: Estilos y Patrones

APU. Adriana Sandra Almeira APU. Vanina Perez Cavenago

Directora: Mg. Zulema Beatriz Rosanigo

Arquitectura de Software: Estilos y Patrones

Objetivos .................................................................................................................. 1 Organizacin del texto................................................................................................ 2

Del Fango a la Estructura ..........................................................................................16

Sistemas Distribuidos ................................................................................................27 Sistemas Interactivos ................................................................................................33

Sistemas Adaptables .................................................................................................42

Patrones de Creacin ................................................................................................52

Anlisis ....................................................................................................................85 Diseo .....................................................................................................................92

Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones

Organizacin del texto

Arquitectura de Software: Estilos y Patrones

Captulo 2 Arquitectura de Software

Arquitectura de Software: Estilos y Patrones

Qu son los patrones?

Arquitectura de Software: Estilos y Patrones

Origen e historia de patrones

Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones

Lenguajes de Descripcin Arquitectnicas

Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones

Caractersticas de un buen patrn

Figura 3.1 - Categora de Patrones segn el tipo de problemas

Arquitectura de Software: Estilos y Patrones

Figura 3.2 - Esquema de tres partes : contexto problema - solucin

Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones

Arquitectura de Software: Estilos y Patrones

Captulo 4 Patrones Arquitectnicos

Del Fango a la Estructura

Arquitectura de Software: Estilos y Patrones

Figura 4.1 - Clase de la capa J

El Nivel mas bajo de abstraccin

Figura 4.2 - Esquema de estructuracin en capas

Consecuencias El patrn Layers tiene varias ventajas:

Reusabilidad. Si una capa individual incluye una abstraccin bien definida y

Arquitectura de Software: Estilos y Patrones

Estandarizacin. Niveles de abstraccin claramente definidos y comnmente

Portabilidad. Las interfaces estandarizadas entre capas limitan el efecto de

El patrn Layer tambin impone desventajas: o

Dificultad al establecer la correcta granularidad de las capas. Una

Arquitectura de Software: Estilos y Patrones

Figura 4.3 - Esquema del protocolo de red OSI

Pipes and Filters

Arquitectura de Software: Estilos y Patrones

Clase Filter Responsabilidades

Figura 4.4 - Clases Pipe y Filter

Figura 4.5 - Clases Repositorio y Fuente de datos

La estructura del patrn arquitectnico Pipe and Filter es:

Figura 4.6 - Estructura Patrn Pipe and Fliter

Consecuencias El patrn Pipes and Filters tiene las siguientes ventajas: o

Arquitectura de Software: Estilos y Patrones

Flexibilidad por recombinacin. Este es el mayor beneficio, combinado con la

Eficiencia del procesamiento en paralelo. Si cada filter en un pipeline

Aplicar patrones Pipes and Filters imponen algunas desventajas: o

Manejo de errores. El manejo de errores es una gran debilidad del patrn

Figura 4.7 - Clases Blackboard y Fuente de Conocimiento

Figura 4.8 - Clases Control

Figura 4.9 - Estructura del Patrn Arquitectnico Blackboard