Вы находитесь на странице: 1из 49

PATRONES PARA MEJORAR LA EFICIENCIA Y ESCALABILIDAD DE ARQUITECTURAS DISTRIBUIDAS

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

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

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. - 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. 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. El siguiente diagrama resume un esquema, el cual captura la esencia de un patrn independientemente de su dominio.

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-View-Controller (MVC) y el PresentationAbstractionControl (PAC). Ambos apoyan la estructuracin de sistemas de software que ofrecen la interaccin usuario-computadora. - 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. 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 sistema que solamente pueden ser solucionados mediante la aplicacin de diferentes patrones arquitectnicos. 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. 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 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.

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

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. o 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. o 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. o 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 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. o 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. o Dificultad al establecer la correcta granularidad de las capas. Una arquitectura de capas con muy pocas capas no explota completamente la potencial reusabilidad, cambiabilidad y portabilidad de este 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

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

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

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. o Flexibilidad por el intercambio de filters. Los filters tienen una interfaz simple que permite su intercambio fcilmente dentro del procesamiento del pipeline. o 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. o Reusabilidad. Permite la recombinacin de filters facilitando el reuso de sus componentes. o 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. o Eficiencia del procesamiento en paralelo. Si cada filter en un pipeline produce y consume datos incrementalmente pueden realizar sus funciones en paralelo. Aplicar patrones Pipes and Filters imponen algunas desventajas: o 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 o 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. o 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. - 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.

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. o 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. o Reusabilidad. Las fuentes de conocimiento son independientes para ciertas 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. o Tolerancia a fallos y robustez. En una arquitectura Blackboard todos los resultados son slo hiptesis. Slo sobrevivirn aquellas que son fuertemente soportadas por los datos y otras hiptesis. 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. o No se garantiza ninguna buena solucin. Normalmente puede resolver correctamente slo un cierto porcentaje de las tareas dadas. o 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 Baja eficiencia. Padece el exceso computacional del rechazo de las hiptesis errneas. o 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. o No soportaparalelismo. 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. Distribucin inherente. Algunas aplicaciones son naturalmente distribuidas, por ejemplo aplicaciones de base de datos en un modelo Cliente-Servidor. 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 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).

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

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. o 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. o Portabilidad. El sistema Broker oculta detalles del sistema operativo y del 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 o 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. o Reusabilidad. Al construir nuevas aplicaciones clientes, frecuentemente estn basadas en la funcionalidad de la aplicacin en servicios existentes. 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.

o Baja tolerancia a fallos. Comparado con un sistema de software no distribuido, un sistema Broker puede ofrecer menos tolerancia a fallos. En caso que un servidor o un broker falle durante la 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. 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. Se describen dos patrones que brindan una organizacin estructural fundamental para software de sistemas interactivos:

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

Consecuencias La aplicacin Model-View-Controller tiene varias ventajas: o Mltiples vistas del mismo modelo. MVC separa al modelo de los componentes de la interfaz de usuario. Mltiples vistas pueden ser implementadas y usadas con un simple modelo. 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. o 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. o Cambiabilidad. Como el modelo es independiente de todo el cdigo de la 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. o El potencial del framework. Es posible basar una aplicacin framework en este patrn.

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

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

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.

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. o 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. o 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. o 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. o Decremento en la eficacia. El costo de comunicaciones entre agentes puede impactar en la eficacia del sistema. Por ejemplo, si un agente de nivel inferior recupera los datos del agente de nivel superior, todos los agentes del nivel intermedio de la jerarqua PAC estarn involucrados en este intercambio de datos. 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. 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. Estructura

El patrn de Microkernel ofrece algunas ventajas importantes: o 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. o 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. o 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. o 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. o 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. o Transparencia. En un sistema distribuido los componentes pueden 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. La arquitectura Microkernel tambin tiene las siguientes desventajas: o Performance. La performance es menor que la de un sistema del software monoltico diseado para ofrecer una vista especfica. o 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. - 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.

El patrn Reflection proporciona las siguientes ventajas:

o Modificaciones no explicitas de cdigo fuente. No se necesita tocar el cdigo 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. o 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. o 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. o Incremento en el nmero de componentes. Puede suceder que un sistema software reflexivo incluya ms metaobjetos que componentes de nivel base. o 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. o 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.

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.

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

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

o o

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.

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

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 Agregar y quitar productos en tiempo de ejecucin: El patrn Prototype 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. Especificar nuevos objetos variando sus valores: En sistemas altamente 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. 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.

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. Adaptee (Adaptado): especifica una interfaz existente que define los mtodos que necesitan ser adaptados. Adapter(Adaptador): adapta la interfaz de Adaptee a la interfaz Target.

Figura 5.4 - Patrn de Diseo Adapter Consecuencias El Patrn Adapter presenta las siguientes ventajas y desventajas:

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

Figura 5.5 - Patrn de Diseo Bridge Consecuencias o Separa interfaz e implementacin: Una implementacin de una abstraccin no esta permanentemente confinada a una interfase, ya que puede ser configurada en tiempo de ejecucin. Adems, un objeto tiene la posibilidad de cambiar su implementacin en tiempo de ejecucin. El hecho de desacoplar Abstraction e Implementor hace que se elimine en tiempo de compilacin las dependencias sobre una clase de implementacin. Mejora la extensibilidad: se puede extender en forma independiente las jerarquas de Abstraction e Implementor. Oculta a los clientes los detalles de implementacin: Se puede proteger a los clientes de los detalles de implementacin.

o o

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

Figura 5.6 - Patrn de Diseo Composite Consecuencias El patrn Composite tiene las siguientes ventajas:

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. 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: o Contar el nmero de referencias al objeto para que pueda ser liberado automticamente cuando no haya ms referencias a l. o 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

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. Proxy de Proteccin: realiza tareas de control cuando se accede a un objeto.

Ejemplo Se desea resguardar una lista de usuarios registrados, pero no se sabe exactamente donde resguardarla. La 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. 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.

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

Figura 5.9 - Patrn de Diseo Observer 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. o Dar soporte para deshacer comandos, procesos de identificacin y/o transacciones o 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.

Figura 5.10 - Patrn de Diseo Command Consecuencias o o o 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.

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. 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. ConcreteSate: Cada subclase implementa un comportamiento asociado con un estado del objeto.

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 separados por diferentes estados hace que la transicin se torne ms explcita, facilitando el reconocimiento de un cambio entre estados. 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.

Figura 5.12 - Patrn de Diseo Strategy 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 proveer diferentes implementaciones del mismo comportamiento.

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

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

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.

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

o o

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.

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

Figura 5.14 - Estructura del patrn de diseo Type Object 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.

o o

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. 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 clase-instancia, en este caso debe ser la aplicacin por si misma quien establece y mantiene la relacin TypeObject-Object.

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: Component: Componente que contiene el comportamiento genrico. Define la interfaz de los objetos a los que se les pueden aadir responsabilidades de forma dinmica. 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. ConcreteDecorator: Aade responsabilidades al objeto Component al que hace referencia.

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. 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. Propagacin de objetos: El patrn Decorator hace que haya muchos objetos pequeos que son muy parecidos.

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

Вам также может понравиться