PATRONES DE DISEO

INTRODUCCIN El presente proyecto nace con la necesidad de proporcionar al estudiante un tutorial sobre el desarrollo de los patrones de diseo de arquitectura de software Enterprise, examinando todo los problemas que se presenta en la construccin del software dando la prevencin y solucin adecuada. Brindando las pautas necesarias para lograr una alta calidad en este tipo de sistemas como por ejemplo: sistemas B2C (comercio electrnico), sistemas financieros en lnea, sistemas ERP (Enterprise Resource Planning). Estos sistemas por su volumen estn generalmente instalados fsicamente en varios nodos (servidores). Por sus caractersticas de crecimiento es importante en su diseo el concepto de escalabilidad y por la necesidad de prestar servicios en forma continua es necesario el concepto de robustez. Ambos conceptos condicionan el diseo de la arquitectura de este tipo de sistemas. Existen muchas formas de plantear una solucin para este tipo de sistemas, y bsicamente todo sistema Enterprise tiene una estructura cliente / servidor, distribuido en capas verticales. Estas capas consisten generalmente en algunas de las siguientes, una capa cliente, una capa de aplicacin o web server, una capa de acceso a la capa de negocio, una capa de modelo de negocio, una capa de persistencia y una base de datos. Los patrones de diseo arquitectnicos de software proporcionan las herramientas necesarias para crear una buena comunicacin entre las diferentes capas que van a conformar los sistemas. El objetivo principal de esta investigacin es la de crear un tutorial referente a los Patrones de Diseo para que los estudiantes tengan en cuenta los grandes beneficios y los problemas a solucionar cuando se lleva a cabo el desarrollo de Sistemas Enterprise.

PATRONES DE DISEO

PATRONES DE DISEO DE ARQUITECTURAS DE SOFTWARE QU ES UN PATRN DE DISEO? Un Patrn es definido como: Un patrn es una unidad de informacin nombrada, instructiva e intuitiva que captura la esencia de una familia exitosa de soluciones probadas a un problema recurrente dentro de un cierto contexto.1 Cada patrn es una regla de tres partes, la cual expresa una relacin entre un cierto contexto, un conjunto de fuerzas que ocurren repetidamente en ese contexto y una cierta configuracin software que permite a estas fuerzas resolverse por s mismas.2 El diseo es un modelo del sistema, realizado con una serie de principios y tcnicas, que permite describir el sistema con suficiente detalle como para ser implementado. Pero los principios y reglas no son suficientes, en el contexto de diseo podemos observar que los buenos ingenieros tienen esquemas y estructuras de solucin que usan numerosas veces en funcin del contexto del problema. Este es el sentido cabal de la expresin "tener una mente bien amueblada", y no el significado de tener una notable inteligencia. Estos esquemas y estructuras son conceptos reusables y nos permiten no reinventar la rueda. Un buen ingeniero reutiliza un esquema de solucin ante problemas similares. Los patrones de diseo tienen un cierto nivel de abstraccin. No son diseos tales como la realizacin de listas y tablas hash que pueden ser codificadas en clases y reutilizadas. Un algoritmo puede ser un ejemplo de implementacin de un patrn, pero es demasiado incompleto, especfico y rgido para ser un patrn. Una regla o heurstica puede participar en los efectos de un patrn, pero un patrn es mucho ms. Los patrones de diseo son descripciones de las comunicaciones de objetos y clases que son personalizadas para resolver un problema general de diseo en un contexto particular.3

Riehle, D. y Zullighoven, H. (2000). Construccin de software mediante Patrones de Diseo. addison wesley. Mexico. Pag 15 2 Richard, G. (1995). Patrones de Diseo java. Prentice Hall. Londres. Pag 8 3 Lago, R. Soluciones Informticas Proactiva. (Abril 2007). <http://www.proactivacalidad.com/java/patrones/index.html>

PATRONES DE DISEO

Un patrn de diseo nombra, abstrae e identifica los aspectos clave de un diseo estructurado, comn, que lo hace til para la creacin de diseos orientados a objetos reutilizables. Los patrones de diseo identifican las clases participantes y las instancias, sus papeles y colaboraciones, y la distribucin de responsabilidades. Cada patrn de diseo se enfoca sobre un particular diseo orientado a objetos. Se describe cuando se aplica, las caractersticas de otros diseos y las consecuencias y ventajas de su uso. Los patrones de diseo se pueden utilizar en cualquier lenguaje de programacin orientado a objetos, adaptando los diseos generales a las caractersticas de la implementacin particular. Un patrn de diseo es una solucin a un problema de diseo especfico, es decir, que son herramientas que proveen facilidades para hacer software reutilizable y de buena calidad. Describen clases y objetos que se comunican entre s adaptada para resolver problemas de diseo general en un contexto particular. Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, para describir despus el ncleo de la solucin a ese problema, de tal manera que esa solucin pueda ser usada ms de un milln de veces sin hacerlo ni siquiera dos veces de la misma forma.

LOS PATRONES DE DISEO PRETENDEN Proporcionar catlogos de elementos reusables en el diseo de sistemas software Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario comn entre Eliminar diseadores. la creatividad inherente al NO PRETENDEN Imponer ciertas alternativas de diseo frente a otras.

proceso de diseo.

PATRONES DE DISEO

Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores

condensando conocimiento ya existente. No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener problema que soluciona el patrn, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error.4 Para que se pueda considerar un patrn, ste debe pasar por unas pruebas que reciben el nombre de test de patrones. Mientras tanto esa solucin recibe el nombre de protopatrn. Los patrones deben tener las siguientes caractersticas: Solucionar un problema: los patrones capturan soluciones, no slo principios o estrategias abstractas. Ser un concepto probado: los patrones capturan soluciones demostradas, no teoras o especulaciones. La solucin no es obvia: muchas tcnicas de solucin de problemas tratan de hallar soluciones por medio de principios bsicos. Los mejores patrones generan una solucin a un problema de forma indirecta. Describe participantes y relaciones entre ellos: los patrones no slo describen mdulos sino estructuras del sistema y mecanismos ms complejos. Los patrones indican repeticin, si algo no se repite, no es posible que sea un patrn. Pero la repeticin no es la nica caracterstica importante. Tambin necesitamos mostrar que un patrn se adapte para poder usarlo, y que es til. La repeticin es una caracterstica cuantitativa pura, la adaptabilidad y utilidad son caractersticas

http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o 29 ago 2011, a las 22:51. Pag.1 http://artemisa.unicauca.edu.co/~alerios/publicaciones/patrones.pdf pdf->Diego Andrs Gonzlez - Alejandro Ros Pea Pag1 http://siul02.si.ehu.es/~alfredo/iso/06Patrones.pdf pag.4

Asenjo

PATRONES DE DISEO

cualitativas. Podemos mostrar la repeticin simplemente aplicando la regla de tres (en al menos tres sistemas existentes); mostrar la adaptabilidad explicando como el patrn es exitoso; y mostrar la utilidad explicando porque es exitoso y beneficioso. As que aparte de la repeticin, un patrn debe describir como la solucin dada resuelve sus objetivos, y porque sta es una buena solucin. Se puede decir que un patrn es donde la teora y la prctica se juntan para fortalecerse y complementarse, para mostrar que la estructura que describe es til, utilizable y usada.5 DESCRIPCIN DE LOS PATRONES DE DISEO Los patrones de diseo son descripciones de clases cuyas instancias colaboran entre s. Cada patrn es adecuado para ser adaptado a un cierto tipo de problema. Para la descripcin de los patrones de diseo se utiliza un formato consistente. Cada patrn es dividido en secciones de acuerdo con la siguiente plantilla. La plantilla nos muestra una estructura uniforme para la informacin, de tal forma que los patrones de diseo sean fciles de aprender, comparar y utilizar. Nombre del patrn

Esta seccin consiste de un nombre del patrn y una referencia bibliogrfica que indica de donde procede el patrn. El nombre es significativo y corto, fcil de recordar y asociar a la informacin que sigue. Objetivo

Esta seccin contiene unas pocas frases describiendo el patrn. El objetivo es aporta la esencia de la solucin que es proporcionada por el patrn. El objetivo est dirigido a programadores con experiencia que pueden reconocer el patrn como uno que ellos ya conocen, pero para el cual ellos no le han dado un nombre. Despus de reconocer el patrn por su nombre y objetivo, esto podra ser suficiente para comprender el resto de la descripcin del patrn.

Martnez F. (2000). Construccin de Software Java con Patrones de Diseo. Trabajo Investigativo. Espaa. Pag 12 - 15

PATRONES DE DISEO

Aplicabilidad

La seccin Aplicabilidad resume las consideraciones que guan a la solucin general presentada en la seccin Solucin. En que situaciones es aplicable el patrn. Consecuencias La seccin Consecuencias explica las implicaciones, buenas y malas, del uso de la solucin.6 CUALIDADES DE UN PATRN DE DISEO Encapsulacin y abstraccin: Cada patrn encapsula un problema bien definido y su solucin en un dominio particular. Los patrones deberan de proporcionar lmites claros que ayuden a cristalizar el entorno del problema y el entorno de la solucin empaquetados en un entramado distinto, con fragmentos interconectados. Los patrones tambin sirven como abstracciones las cuales contienen dominios conocidos y experiencia, y podran ocurrir en distintos niveles jerrquicos de granularidad conceptual. Extensin y variabilidad: Cada patrn debera ser abierto por extensin o parametrizacin por otros patrones, de tal forma que pueden aplicarse juntos para solucionar un gran problema. Un patrn solucin debera ser tambin capaz de realizar una variedad infinita de implementaciones (de forma individual, y tambin en conjuncin con otros patrones). Generatividad y composicin: Cada patrn, una vez aplicado, genera un contexto resultante, el cual concuerda con el contexto inicial de uno o ms de uno de los patrones del catlogo. Est subsecuencia de patrones podra luego ser aplicada progresivamente para conseguir el objetivo final de generacin de un todo o solucin completa. Los patrones son aplicados por el principio de evolucin fragmentada. Pero los patrones no son simplemente de naturaleza lineal, ms bien esos patrones en un nivel particular de abstraccin y granularidad podran guiar hacia o ser compuestos con otros patrones para modificar niveles de escala. Equilibrio: Cada patrn debe realizar algn tipo de balance entre sus efectos y restricciones. Esto podra ser debido a uno o ms de un heurstico que son

http://www.proactiva-calidad.com/java/patrones/index.html Ramiro Lago (Abril 2007)

PATRONES DE DISEO

utilizados para minimizar el conflicto sin el contexto de la solucin. Las invariaciones representadas en un problema subyacente solucionan el principio o filosofa para el dominio particular, y proveen una razn fundamental para cada paso o regla en el patrn.7 CLASIFICACIN DE LOS PATRONES DE DISEO Los patrones de diseo se clasifican segn su propsito en: Patrones de Creacin: Tratan la creacin de instancias, muestran la gua de cmo crear objetos cuando sus creaciones requieran tomar decisiones. Estas decisiones normalmente sern resueltas dinmicamente decidiendo qu clases instanciar o sobre qu objetos. Los patrones de creacin abstraen la forma en que se crean los objetos, permite tratar las clases a crear genricamente apartando la decisin de qu clases crear o cmo crearlas. Los patrones de Creacin proveen diferentes maneras para remover las referencias explicitas a clases concretas del cdigo donde deben ser utilizadas. Patrones Estructurales: Tratan la relacin entre clases, la combinacin clases y la formacin de estructuras de mayor complejidad, es decir que describen la forma en que los diferentes tipos de objetos pueden ser organizados para trabajar unos con otros. Los patrones estructurales tienen que ver con la forma en que las clases y los objetos son agrupados para formar grandes estructuras. Los patrones estructurales de clase usan la herencia para formar interfaces o implementaciones. Patrones de Comportamiento: Tratan la interaccin y cooperacin entre clases, se utilizan para organizar, manejar y combinar comportamientos Los patrones de comportamiento estn relacionados con los algoritmos y con la asignacin de responsabilidades entre los objetos. Los patrones de comportamiento no describen slo patrones de clases y de objetos, sino que describen los patrones de cmo stos se comunican. Estos patrones caracterizan complicados flujos de control que son difciles de seguir o imaginar en tiempo de ejecucin.8

Richard, G. (1995). Patrones de Diseo java. Prentice Hall. Inglaterra. Pag. 75

http://artemisa.unicauca.edu.co/~alerios/publicaciones/patrones.pdf pdf->Diego Andrs Asenjo Gonzlez - Alejandro Ros Pea pag 3

PATRONES DE DISEO

CATLOGO DE PATRONES DE DISEO

PATRONES
CREACIN SINGLETON ESTRUCTURALES ADAPTER COMPORTAMIENTO CHAIN RESPONSIBILITY ABSTRACT FACTORY BUILDER FACTORY METHOD PROTOTYPE FACADE FLYWEIGHT PROXY MEDIATOR MEMENTO OBSERVER STATE STRATEGY TEMPLATE METHOD VISITOR PATRONES DE CREACIN Los patrones de creacin proporcionan ayuda a la hora de crear objetos, principalmente cuando esta creacin requiere tomar decisiones. Esta toma de decisiones puede ser dinmica. Estos patrones ayudan a estructurar y encapsular estas decisiones. En algunas ocasiones existe ms de un patrn que se puede aplicar a la misma situacin. En otras
http://www.info-ab.uclm.es/asignaturas/42579/pdf/04-Capitulo4a.pdf pdf-> 2003-2004 pag 8

OF

BRIDGE

COMMAND

COMPOSITE DECORATOR

INTERPRETER ITERATOR

PATRONES DE DISEO

ocasiones se pueden combinar mltiples patrones convenientemente. Un patrn de creacin asociado a clases usa la herencia para variar la clase que se instancia, mientras que un patrn de creacin asociado a objetos delegar la instanciacin a otro objeto. Hay dos formas de clasificar los patrones de creacin basndose en las clases de objetos que se crean. Una es clasificar las clases que crean los objetos (Factory Method), otra forma est relacionada con la composicin de objetos; definir un objeto que es responsable de conocer las clases de los objetos producto, en esta caracterstica se apoyan los patrones Abstract Factory, Builder o Prototype. En muchas ocasiones los patrones de creacin compiten en su funcin. Por ejemplo, hay casos donde Protoype y Abstract Factory puede utilizarse indistintamente. En otras ocasiones Builder puede usar a los otros patrones para implementar los componentes que construye. SINGLETON (INSTANCIA NICA) Singleton garantiza la existencia de una nica instancia para una clase y la creacin de un mecanismo de acceso global a dicha instancia. Objetivo Garantiza que una clase slo tenga una instancia y proporciona un punto de acceso global a ella. Aplicabilidad Usar cuando: Debe haber exactamente una instancia de una clase y sta debe ser accesible a los clientes desde un punto de acceso conocido. La nica instancia debera ser extensible mediante herencia y los clientes deberan ser capaces de utilizar una instancia extendida sin modificar su cdigo.

PATRONES DE DISEO

Estructura

Consecuencias Acceso controlado a la nica instancia. Puede tener un control estricto sobre cmo y cundo acceden los clientes a la instancia. Espacio de nombres reducido. El patrn Singleton es una mejora sobre las variables globales. Permite el refinamiento de operaciones y la representacin. Se puede crear una subclase de Singleton. Permite un nmero variable de instancias. El patrn hace que sea fcil cambiar de opinin y permitir ms de una instancia de la clase Singleton. Ms flexible que las operaciones de clase (static en C#, Shared en VB .NET).

PATRONES DE DISEO

ABSTRACT FACTORY (FBRICA ABSTRACTA) Este patrn es el de crear diferentes familias de objetos, como por ejemplo la creacin de interfaces grficas de distintos tipos (ventana, men, botn, etc.). Objetivo Proporciona un contrato para crear familias de objetos relacionados sin tener que especificar la clase concreta. Aplicabilidad Use el patrn Abstract Factory cuando: El cliente debe ser independiente del proceso de creacin de los productos. La aplicacin debe configurarse con una o ms familias de productos. Es necesario crear objetos como un conjunto, de forma que sean compatibles. Desea proporcionar una coleccin de clases y nicamente quiere revelar sus contratos y sus relaciones, no sus implementaciones. Estructura

PATRONES DE DISEO

Consecuencias Ocultacin de las clases de implementacin. Esto tambin permite ofrecer clases sin mostrar su implementacin, pudindonos reservar la posibilidad de cambiar la implementacin en el futuro. Facilidad de sustitucin de conjuntos de clases por otras equivalentes. Consistencia entre productos, al desarrollarse las aplicaciones con un mismo conjunto homogneo de clases, dichas aplicaciones son ms consistentes entre ellas. Aadir nuevos tipos de productos es difcil. Esto es porque Abstract Factory fija el conjunto de productos que puede ser creado. BUILDER (CONSTRUCTOR VIRTUAL) Separa la construccin de un objeto complejo de su representacin, as el mismo proceso de construccin podra crear diferentes representaciones. Objetivo Construir un objeto complejo independientemente de su representacin interna. Aplicabilidad Usamos el patrn Builder cuando: El algoritmo para crear un objeto complejo debe ser independiente de las partes que componen el objeto y cmo se montan. El proceso de construccin debe permitir diferentes representaciones para el objeto que se est construyendo.

PATRONES DE DISEO

Estructura

Consecuencias Permite variar la representacin interna de estructuras compleja, respetando la interfaz comn de la clase Builder. Se independiza el cdigo de construccin de la representacin. Las clases concretas que tratan las representaciones internas no forman parte de la interfaz del Builder. Permite un mayor control en el proceso de creacin del objeto. El Director controla la creacin paso a paso, solo cuando el Builder ha terminado de construir el objeto, lo recupera el Director. Cada ConcreteBuilder tiene el cdigo especfico para crear y modificar una estructura interna concreta. Distintos Director con distintas utilidades (visores, parsers, etc) pueden utilizar el mismo ConcreteBuilder. Reduce el acoplamiento.

PATRONES DE DISEO

FACTORY METHOD (MTODO DE FABRICACIN) Abstraer la instanciacin de clases relegando esta responsabilidad a las mismas clases. Objetivo Es un modelo que utiliza abstraccin de clases para crear y relacionar objetos sin conocer de qu clase es. Aplicabilidad Se utiliza cuando: Una clase no puede anticipar la clase de objetos que deber crear Una clase quiere que sus subclases especifiquen que objetos crea Se quiere localizar el conocimiento de qu clase es la que se crea. Estructura

PATRONES DE DISEO

Consecuencias El mtodo factora elimina la dependencia de clases especficas de la aplicacin en el cdigo. Un inconveniente potencial podra ser que los clientes tendran que hacer subclases de Creador nicamente para crear un Producto Concreto particular. La herencia es apropiada si el cliente tiene que hacerla de todas maneras. Adems: Proporciona una ayuda para crear subclases: crear un objeto en una clase siempre es ms flexible que crearlo directamente. y sirve para conectar jerarquas paralelas. PROTOTYPE (PROTOTIPO) Especifica el tipo de los objetos a crear usando una instancia prototipo, y permite crear objetos copiando este prototipo. Objetivo Reducir el nmero de clases. Aplicabilidad Se utiliza cuando se quiere abstraer el proceso de creacin de objetos y cuando las clases a instanciar se conocen en tiempo de ejecucin. Para reducir el nmero de clases a desarrollar (que implicara una gran cantidad de factoras). Cuando los objetos de una clase tengan pocas combinaciones de estados distintos.

PATRONES DE DISEO

Estructura

Consecuencias Reduce el nmero de clases. Permite crear objetos en tiempo de ejecucin con los atributos o valores de otro existente. La clase cliente no necesita conocer las clases de los objetos a crear, le basta con saber que heredan de Prototype. No es necesario crear una estructura de herencia de clases complicada. La clase cliente puede crear nuevos prototipos variando los existentes. Al implementar cada clase su mtodo clone se garantiza que cada objeto crea una instancia coherente. El mayor inconveniente es que cada subclase del prototipo debe implementar el mtodo clone.

PATRONES DE DISEO

PATRONES ESTRUCTURALES Los patrones estructurales estn relacionados cmo las clases y los objetos se combinan para dar lugar a estructuras ms complejas. Puede hacerse aqu la misma distincin que hacamos en los patrones de creacin y hablar de patrones estructurales asociados a clases (Adapter) y asociados a objetos (Bridge, Composite, Decorator, Facade, Flyweight, Proxy), los primeros utilizarn la herencia, los segundos la composicin. Los patrones estructurales asociados con objetos describen formas de componer los objetos para conseguir nueva funcionalidad. La flexibilidad de la composicin de objetos viene de la posibilidad de cambiar la composicin en tiempo de ejecucin, lo que es imposible con la composicin esttica de clases. ADAPTER (ADAPTADOR) Convierte la interfaz de una clase en otra compatible con las necesidades del cliente. El adaptador permite trabajar conjuntamente a clases que de otra manera no podran debido a las diferentes interfaces. Objetivo A veces una clase diseada para ser reutilizable, no se puede reutilizar nicamente porque su interfaz no se ajusta a la interfaz especfica del dominio que la aplicacin requiere. El ejemplo que se usa en el Design Patterns es el de usar una clase TextView para un editor grfico que usa Figuras, se adapta el TextView a Figura mediante una clase TextShape. Esto se puede conseguir de dos formas, mediante herencia (adaptador de clase) o composicin (adaptador de objeto). Aplicabilidad Para utilizar una clase existente, cuya interfaz no coincide con la que se requiere.

PATRONES DE DISEO

Estructura

Consecuencia El cliente es independiente de las clases finales que utiliza. Es posible utilizar la clase Adaptador para monitorizar que clases llaman a qu mtodos de las clases finales. Adaptador de Clase: La clase adaptadora puede redefinir y ampliar la interfaz de la clase adaptada. La clase adaptadora utiliza la interfaz de la clase adaptada, puede ser que no sean vlidos todas las subclases de la clase adaptada (ya que hereda una clase concreta). No funciona bien si queremos adaptar una clase y todas sus subclases. Slo introduce un objeto, sin indirecciones adicionales. Adaptador de Objeto: La clase adaptadora puede utilizar todas las subclases de la clase adaptada, ya que tiene constancia de los objetos que instancia. Es ms difcil sobrescribir el comportamiento de la clase adaptada. Se podra hacer una subclase de la adaptada y haciendo que la adaptadora haga referencia a esta.

PATRONES DE DISEO

BRIDGE (PUENTE) Separa una abstraccin de su implementacin de forma que ambas pueden evolucionar por separado. Objetivo La herencia permite tener diferentes implementaciones de una abstraccin. Pero la herencia ata una implementacin a la abstraccin permanentemente, lo que hace que sea difcil de modificar, extender y reutilizar las abstracciones y las implementaciones por separado. En ocasiones una jerarqua de clases requiere implementaciones para diferentes plataformas, por lo que hay que separar la abstraccin de la implementacin. Se crearan subclases de extensin y subclases de implementacin, habra que hacer subclases de extensin para cada implementacin. Aplicabilidad Para evitar una vinculacin permanente entre un interfaz y su implementacin, ya que la ligadura se produce en tiempo de ejecucin. Cuando tanto la abstraccin como la implementacin van a formar un rbol de clases derivadas. Para evitar recompilar los clientes cuando cambien las implementaciones. Cuando se tiene proliferacin de clases. Estructura

PATRONES DE DISEO

Consecuencia Separa la interfaz de la implementacin. La implementacin de una abstraccin puede ser configurada en tiempo de ejecucin e incluso cambiarse durante la ejecucin. Tambin elimina las dependencias en tiempo de compilacin de la implementacin. Permite extender las jerarquas de la abstraccin y la implementacin independientemente. Oculta los detalles de la implementacin de los clientes. COMPOSITE (OBJETO COMPUESTO) Componer objetos en estructuras tipo rbol para representar jerarquas parte-todo. Este patrn permite a los clientes tratar a los objetos individuales y a las composiciones de objetos de manera uniforme Objetivo Las aplicaciones grficas frecuentemente requieren agrupar objetos en contenedores hechos de componentes simples. El usuario puede agrupar componentes para formarlos ms complejos, que a su vez se pueden agrupar para formar otros an ms complejos. El problema est en que el cdigo que usa estas clases debe tratar a los objetos simples y a los contenedores de manera diferente, incluso cuando la mayora de las veces el usuario los trata de la misma manera. El patrn composite describe cmo usar la composicin recursiva de manera que el cliente no tenga que hacer esta distincin. Aplicabilidad Cuando se quiere representar jerarquas parte-todo de objetos. Cuando se quiere que el cliente pueda ignorar la diferencia entre composicin y los objetos simples.

PATRONES DE DISEO

Estructura

Consecuencia Se crea una jerarqua de objetos bsicos y de composiciones de stos. Simplifica el cliente al tratar a todos de la misma manera. Facilita agregar nuevas clases ya sean compuestos u hojas, heredando de componente. El cliente no tendr que cambiar el cdigo. El diseo puede ser demasiado general. La desventaja es que al hacer fcil aadir nuevos componentes, es difcil restringir el tipo de componentes en un compuesto, se tendran que hacer chequeos en tiempo de ejecucin. DECORATOR (DECORADOR) Aadir nuevas responsabilidades dinmicamente a un objeto, es una alternativa a crear subclases para aadir funcionalidad. Objetivo Permite aadir nuevas responsabilidades a una instancia concreta y no a toda la clase y subclases. Una manera de aadir responsabilidades es la herencia, pero as es muy inflexible, el cliente no puede elegir cuando quiere y cuando no la nueva responsabilidad.

PATRONES DE DISEO

Una manera ms flexible es envolver el componente en otro objeto que aada esta responsabilidad. A este objeto se le llama decorador. La interfaz del decorador concuerda con la interfaz del componente, de manera que su presencia es transparente para el cliente. El decorador reenva las peticiones al componente y podra realizar acciones adicionales antes o despus del reenvo. La transparencia permite anidar decoradores recursivamente, permitiendo as un nmero ilimitado de

responsabilidades aadidas. El ejemplo en el Design Patterns es aadir un borde una barra de scroll a un TextView (cuadro de texto) Aplicabilidad Para aadir funcionalidades a objetos individuales dinmicamente y de manera transparente (sin afectar a otros objetos). Para funcionalidades que puedan ser retiradas. Cuando la extensin mediante herencia sea poco prctica. A veces una gran cantidad de extensiones independientes son posibles y esto producira una explosin de clases para conseguir todas las combinaciones. Tambin puede ocurrir que la clase no est disponible para heredar de ella (si fuese final en java). Estructura

PATRONES DE DISEO

Consecuencia Ofrece ms flexibilidad que la herencia esttica. Con los decoradores que pueden aadir y retirar responsabilidades a los objetos en tiempo de ejecucin. Se reduce el nmero de clases y el rbol de herencia de clases. Un decorador y su componente no son idnticos. El decorador acta como una cubierta transparente, pero desde el punto de vista de los objetos no son iguales, as que no se debe confiar en la identidad de objetos cuando se trabaja con decoradores. Un diseo que utilice decoradores, se convierte en un sistema compuesto de un montn de objetos que se parecen entre s. Los objetos se diferencian nicamente en la manera en la que estn interconectados, no en su clase o en el valor de sus atributos. Aunque estos sistemas son sencillos de adaptar, pueden ser difciles de aprender y depurar. FACADE (FACHADA) Simplifica el acceso a un conjunto de clases o interfaces en un subsistema. Fachada define una interfaz de alto nivel que hace el subsistema ms fcil de usar. Objetivo Reducir la dependencia entre clases, la fachada ofrece un punto de acceso al resto de clases, si estas cambian o se sustituyen por otras solo hay que actualizar la clase Fachada sin que el cambio afecte a las aplicaciones. Al utilizar se minimiza la comunicacin y, por lo tanto, las dependencias entre subsistemas. Fachada no oculta las clases sino que ofrece una forma ms sencilla de acceder a ellas, en los casos en que se requiere se puede acceder directamente a ellas. Aplicabilidad Para ofrecer un acceso sencillo a subsistemas complejos. Para descomponer un sistema en capas, utilizando la fachada para ofrecer una interfaz de acceso entre las mismas.

PATRONES DE DISEO

Si hay muchas dependencias entre los clientes y la implementacin de una abstraccin. Introducir una fachada ayuda a separar el subsistema de los clientes y otros subsistemas. Estructura

Consecuencia Oculta a los clientes parte de la complejidad de los subsistemas, reduciendo el nmero de objetos que el cliente debe conocer. Disminuye el acoplamiento entre subsistemas y cliente. No evita que las aplicaciones usen directamente las clases del subsistema si lo necesitan.

PATRONES DE DISEO

FLYWEIGHT (PESO LIGERO) Compartir para dar soporte a un gran nmero de objetos pequeos eficientemente. Objetivo Algunas aplicaciones se podran beneficiar del uso de objetos a lo largo de todo el diseo, pero una implementacin ingenua sera demasiado costosa. En el design patterns se usa el ejemplo de un procesador de textos y tener un objeto para cada carcter. El flyweight sera un objeto compartido que se podra usar en varios contextos simultneamente, ellos no pueden hacer asunciones acerca de su contexto. El concepto clave est en la distincin entre estado intrnseco y extrnseco. El estado intrnseco se almacenara en el objeto flyweight, y consistira en informacin independiente del contexto, y por lo tanto compartible. Los clientes seran responsables de la informacin extrnseca y se la pasaran al flyweight cuando este la necesitase. (ej carcter: intrnseco el cdigo del carcter, extrnseco la posicin, fuente, color...) Aplicabilidad Usar un flyweight cuando se cumplan todas las condiciones siguientes: Una aplicacin usa un gran nmero de objetos. Los costes de almacenamiento son altos a causa de esta gran cantidad de objetos La mayora de los estados de un objeto se pueden hacer extrnsecos. Muchos grupos de objetos se podran reemplazar por relativamente pocos objetos compartidos una vez que el estado extrnseco se haya eliminado La aplicacin no depende de la identidad de objetos.

PATRONES DE DISEO

Estructura

Consecuencia Los flyweights pueden introducir costes de ejecucin asociados como transferir, encontrar y computar el estado extrnseco. De todas maneras estos costes se contraponen con ahorro de espacio, que es mayor mientras ms flyweights se comparten. Este ahorro depende de la reduccin en el nmero total de instancias, la cantidad de estado intrnseco por objeto y de si el estado extrnseco es almacenado o calculado. PROXY Un objeto sustituye a otro para controlar el acceso al mismo. Objetivo En ocasiones se desea retrasar la instanciacin de un objeto hasta que sea necesario utilizarlo. As el objeto proxy lo sustituye ofreciendo la misma interfaz, solo cuando es necesario le solicita al objeto real la informacin que necesita. Otro motivo para su uso es sustituir a un sistema remoto, de forma que se accede al mismo a travs de una clase proxy, que permite controlar el acceso al mismo.

PATRONES DE DISEO

Ejemplo del design patterns: imgenes en un documento de texto. Aplicabilidad Proxy Remoto Cuando el objeto est en un sistema remoto. Proxy Virtual Para retrasar la creacin de objetos hasta que sean necesarios. Proxy de Proteccin Para controlar el acceso a un objeto. Proxy de Sincronizacin Para gestionar accesos de mltiples clientes a un recurso. Referencias Inteligentes Para gestin y mantenimiento del acceso a un objeto real, permite contabilizar su utilizacin da cara a gestionar sus recursos e incluso destruirlo cuando ya no se necesita. Tambin permite sincronizar accesos concurrentes al mismo, bloquendolo mientras est en uso. Estructura

Consecuencia Puede mejorar la eficiencia al controlar la instanciacin de recursos y al hacer cach. Aumenta la seguridad. Los clientes se desentienden de la ubicacin de los componentes accedidos.

PATRONES DE DISEO

PATRONES DE COMPORTAMIENTO Estos patrones de diseo estn relacionados con algoritmos y asignacin de responsabilidades a los objetos. Los patrones de comportamiento describen no solamente patrones de objetos o clases sino tambin patrones de comunicacin entre ellos. Nuevamente se pueden clasificar en funcin de que trabajen con clases (Template Method, Interpreter) u objetos (Chain of Responsability, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor). La variacin de la encapsulacin es la base de muchos patrones de comportamiento. Cuando un aspecto de un programa cambia frecuentemente, estos patrones definen un objeto que encapsula dicho aspecto. Los patrones definen una clase abstracta que describe la encapsulacin del objeto.9 CHAIN OF RESPONSIBILITY (CADENA DE RESPONSABILIDADES) Evitar que el receptor se apodere por completo de la peticin, y dar oportunidades a otros receptores a contestar a la peticin. Objetivo La peticin debe ser procesada por los receptores, lo cual quiere decir que, sta peticin queda al margen del uso exclusivo. Pretendemos dar un mayor detalle y especificacin a las peticiones generadas. Las peticiones sern filtradas por todos los receptores a medida que se van generando los resultados esperados. Aplicabilidad Se usa dicho patrn cuando: Hay ms de un objeto que pueden manejar una peticin, y el manejador no se conoce a priori, sino que debera determinarse automticamente. Se quiere enviar una peticin a un objeto entre varios sin especificar explcitamente el receptor.

Sommerville, I. (2002).Ingeniera de Software Sptima Edicin. Pearson. Inglaterra. Pag 244 - 249

PATRONES DE DISEO

El conjunto de objetos que pueden tratar una peticin debera ser especificado dinmicamente. Estructura

Consecuencia Reduccin del acoplamiento: Ni el receptor ni el emisor se conocen explcitamente. Un objeto slo tiene que saber que una peticin ser manejada. Aade flexibilidad para asignar responsabilidades a objetos: Las

responsabilidades de los mensajes pueden cambiar mediante la organizacin del proceso de ejecucin. No se garantiza la recepcin: Puesto que no existe un receptor especfico para los mensajes, stos pueden quedarse sin procesar. COMMAND (ORDEN) Encapsula una peticin como un objeto, esto facilita la parametrizacin de los requerimientos (inicializacin de los parmetros por el constructor), el encolado de mltiples peticiones (estructura de datos de objetos comando) y su reordenacin, y permite implementar el hacer/deshacer (do/undo) mediante mtodos. Por otro lado se facilita la creacin de macros agrupando los comandos ms frecuentes.

PATRONES DE DISEO

Objetivo El concepto de "comando" puede ser ambiguo y complejo en los sistemas actuales y al mismo tiempo muy extendido: intrpretes de comandos del sistema operativo, lenguajes de macros de paquetes ofimticos, gestores de bases de datos, protocolos de servidores de Internet, etc. Este patrn presenta una forma sencilla y verstil de implementar un sistema basado en comandos facilitndose su uso y ampliacin. Aplicabilidad Cuando se requiera: Facilitar la parametrizacin de las acciones a realizar. Independizar el momento de peticin de la ejecucin. Estructura

Consecuencia Se independiza la parte de la aplicacin que invoca los comandos de la implementacin de los mismos. Al tratarse los comandos como objetos, se puede realizar herencia de los mismos, composiciones de comandos (mediante el patrn Composite) Se facilita la ampliacin del conjunto de comandos.

PATRONES DE DISEO

INTERPRETER (INTRPRETE) Dado un Lenguaje, definir la representacin de una gramtica y un interpretador, que pueda computar entradas de ese Lenguaje. Objetivo Existen problemas particulares que pueden expresarse en funcin de algn Lenguaje. Aplicabilidad La Gramtica es Simple. En caso contrario, una mejor alternativa son los Analizadores. La Eficiencia no es uno de los aspectos ms importantes. En este caso hay que traducir el input a una forma intermedia. Estructura

Consecuencia Gramticas Fciles de cambiar y extender. Herencia. Fcil Implementacin.

PATRONES DE DISEO

Similitud. Gramticas Complejas son difciles de Mantener. Multi-Clases. Agregar nuevas formas de interpretar las cosas es Sencillo ITERATOR (ITERADOR) Establece un modo de acceso secuencial a los elementos de un objeto agregado sin exponer su representacin interna. Objetivo Un objeto agregado, tal como una lista, debera proveer un modo de brindar acceso a sus elementos sin exponer su estructura interna. Ms an, quizs se desea recorrer la lista en diferentes formas, dependiendo de lo que usted quiera realizar. Pero, probablemente, la idea no es aumentar la interfaz de la lista con operaciones para recorridos diferentes, an anticipando los que se necesitarn. Tal vez, tambin se necesite tener ms de un recorrido en la misma lista. El patrn Iterator permite llenar todas estas expectativas. La idea principal en este patrn es tomar la responsabilidad del acceso y recorrido de la lista y colocarla dentro del objeto iterator. La clase Iterator define una interfaz para el acceso de los elementos de la lista. Un objeto iterador es responsable de mantener la pista del elemento actual; esto es, que sabe cules elementos ya han sido recorridos. Aplicabilidad Utilize el patrn Iterator: Para tener acceso a los contenidos de un objeto agregado sin tener que exponer su estructura interna. Para soportar mltiples recorridos de objetos agregados. Para proveer una interfaz uniforme para recorridos en estructuras diferentes de agregados (esto es, para soportar iteracin polimorfa).

PATRONES DE DISEO

Estructura

Consecuencia Soporte a variaciones en el recorrido de un agregado, puesto que agregados complejos pueden requerir recorridos en muchas formas. Los iteradores hacen fcil cambiar el algoritmo de recorrido, con slo reemplazar la instancia del iterador a una diferente. Los iteradores simplifican la interfaz de los agregados, ya que la interfaz de los recorridos se encuentra en los iteradores y no en los agregados. Ms de un recorrido puede estar pendiente en un agregado, puesto que cada iterador mantiene la pista de su recorrido. Por lo tanto, se puede tener ms de un recorrido en progreso al tiempo.

PATRONES DE DISEO

MEDIATOR (MEDIADOR) Define un objeto que encapsula cmo interactan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explcitamente, y permite variar la interaccin entre ellos de forma independiente. Objetivo Cuando muchos objetos interactan con otros objetos, se puede formar una estructura muy compleja, con objetos con muchas conexiones con otros objetos. En un caso extremo cada objeto puede conocer a todos los dems objetos. Aplicabilidad Se puede utilizar este patrn cuando: Un conjunto grande de objetos se comunica de una forma bien definida, pero compleja. Dificultad para reutilizar objetos ya que nos referimos a varios objetos para comunicarnos. El comportamiento de muchos objetos que est distribuido entre varias clases, puede resumirse en una o varias por subclasificacin. Estructura

PATRONES DE DISEO

Consecuencia Desacopla a los objetos: el patrn Mediator promueve bajar el acoplamiento entre objetos. Se puede variar y rehusar objetos y mediadores independientemente. Simplifica la comunicacin entre objetos: Los objetos que se comunican de la forma "muchos a muchos" puede ser remplazada por una forma "uno a muchos" que es menos compleja y ms elegante. Adems esta forma de comunicacin es ms fcil de entender. Abstrae como los objetos cooperan: Haciendo a la mediacin un concepto independiente y encapsulndolo en un objeto permite enfocar como los objetos interactan. Esto ayuda a clarificar como los objetos se relacionan en un sistema. Centraliza el control: El mediador es el que se encarga de comunicar a los objetos, este puede ser muy complejo, difcil de entender y modificar MEMENTO (RECUERDO) Este patrn tiene como finalidad almacenar el estado de un objeto (o del sistema completo) en un momento dado de manera que se pueda restaurar en ese punto de manera sencilla. Objetivo Este patrn se usa para poder restaurar el sistema desde estados pasados; tambin para facilitar el hacer y deshacer de determinadas operaciones, para lo que habr que guardar los estados anteriores de los objetos sobre los que se opere (o bien recordar los cambios de forma incremental). Aplicabilidad El patrn Memento se puede utilizar, fundamentalmente, para guardar instancias del estado de un objeto permitindonos la implementacin de utilidades de "deshacer" y "rehacer" o incluso almacenar el estado completo de una aplicacin.

PATRONES DE DISEO

Estructura

Consecuencia Mantiene la encapsulacin. Simplifica la clase Creador. El uso de MEMENTO puede resultar costoso si se hacen muchas copias o las copias son voluminosas. En algunos lenguajes puede no ser trivial definir dos interfaces distintas para el MEMENTO. El objeto (conserje) que se encarga de gestionar los MEMENTOS no sabe cunto ocupan y su almacenamiento puede provocar un coste inesperado. OBSERVER (OBSERVADOR) Notifica automticamente de los cambios de estado de un objeto a todos sus dependientes. Permite de forma dinmica implementar dependencias entre objetos, de forma que los objetos dependientes sean notificados de los cambios que se producen en los objetos de los que dependen. Objetivos Un efecto comn de particionar un sistema en una coleccin de clases que cooperan es la necesidad de mantener la consistencia entre objetos relacionados sin hacer las clases demasiado dependientes entre s, ya que esto reduce su reusabilidad. El ejemplo del Design Patterns es el de modelo y diferentes vistas.

PATRONES DE DISEO

El patrn Observador describe cmo establecer estas relaciones. Tendramos un sujeto y varios observadores. Todos los observadores son notificados cuando el estado del sujeto cambia. Aplicabilidad Cuando un sistema requiere que unos elementos sean conscientes de los cambios producidos en otros. Cuando la dependencia entre instancias se produce de forma dinmica, en tiempo de ejecucin y no siempre. Cuando la dependencia se produce de un objeto hacia muchos y un sistema simple de eventos no sirve porque solo permite notificar a una sola instancia. Cuando se quiere que un objeto notifique a otros sin conocer qu tipo de objetos son. En ocasiones se implementan sistemas de eventos mediante este sistema, por ejemplo en el API de Java, de forma que los objetos que notifican de eventos implementan la interfaz observable y los que reciben las notificaciones de eventos implementan la interfaz observer. Esto permite que muchos objetos reciban eventos de otro objeto en lugar de los sistemas de eventos bsicos que solo permiten notificar a un nico objeto. Estructura

PATRONES DE DISEO

Consecuencia Acoplamiento abstracto y mnimo entre el sujeto y el observador. Soporte para comunicacin broadcast Actualizaciones inesperadas. Cada observador no es consciente del resto de los observadores, se establece una comunicacin entre ellos que no es explica, por lo tanto no se puede saber qu consecuencias puede tener cualquier cambio en el sujeto. Adems el hecho de que el protocolo de actualizacin no indique qu es lo que cambia, agrava este hecho. STATE (ESTADO) Permite que un objeto cambie su comportamiento dependiendo de su estado. El objeto aparentar que cambia de clase. Objetivo Cuando un objeto puede estar en diferentes estados y el resultado de una peticin a este objeto depende del estado en el que se encuentre, debemos utilizar este patrn. La idea es introducir una clase abstracta que represente los distintos estados, para luego hacer subclases. Desde la clase del objeto se tendr una referencia a la clase abstracta, a la que se reenviarn las peticiones recibidas. En el Design Patterns, el ejemplo que se sigue es el de una conexin TCP. Incorpora a los patrones el concepto de "Mquina Abstracta" o autmata, utilizado desde los orgenes de la Informtica y estudiado mucho antes. Ofrece un modelo basado en la programacin orientada a objetos frente a las formas clsicas de programacin de autmatas finitos. Aplicabilidad Cuando el comportamiento de un objeto depende de su estado y debe cambiar este comportamiento en tiempo de ejecucin. Para aquellos sistemas que representemos como una autmata o mquina abstracta

PATRONES DE DISEO

Estructura

Consecuencia Se localiza el comportamiento especfico del estado. Todo el comportamiento asociado con un estado estar en una misma clase. Se pueden aadir fcilmente nuevos estados. Heredando de la superclase. Hace explcitos los cambios de estado. STRATEGY (ESTRATEGIA) Abstraccin para seleccionar un algoritmo de entre una familia de varios. Permite a los algoritmos variar independientemente de los clientes que lo usen. Objetivo Encapsula varios algoritmos alternativos en diferentes clases y ofrece una interfaz nica (mediante una superclase) para acceder a la funcionalidad ofrecida, la eleccin del algoritmo se vuelve transparente para el cliente, pudiendo depender del objeto e incluso variar en tiempo de ejecucin.

PATRONES DE DISEO

Ejemplo del Design Patterns, distintos algoritmos para dividir un texto en lneas. Ejemplo Bruce Eckel, distintos mtodos para hallar el mnimo de una funcin. Una operacin de "Guardar" un documento puede ser distinta segn sea el destino elegido un directorio local o un servidor ftp remoto. La funcionalidad de comprobacin de integridad de un archivo puede realizarse mediante CRC u otro algoritmo. Un sistema puede requerir cifrar un contenido mediante diferentes mtodos de encriptacin. Aplicabilidad Varias clases relacionadas se diferencian slo en su comportamiento. Proporciona un mtodo de configurar una clase con varios comportamientos. Se necesitan diferentes variantes de un algoritmo. Por ejemplo con diferentes necesidades de tiempo/espacio. Un algoritmo usa datos que el cliente no debera conocer. Una clase define muchos comportamientos, y estos aparecen en sentencias de bifurcacin mltiple (switch case) Estructura

PATRONES DE DISEO

Consecuencia Las jerarquas de estrategias permiten definir una familia de algoritmos o comportamientos para que los reutilicen los contextos. El patrn estrategia elimina las sentencias condicionales para seleccionar el comportamiento deseado. Puede proporcionar varias implementaciones para el mismo comportamiento. Los clientes deben conocer las estrategias y sus diferencias. Habr implementaciones que no usen todos los parmetros que nosotros pasemos al mtodo. Se incrementa el nmero de objetos. TEMPLATE METHOD (MTODO PLANTILLA) Define el esqueleto de un algoritmo en una operacin, posponiendo algunos pasos a las subclases. Permite a las subclases redefinir ciertos pasos de un algoritmo sin cambiar la estructura del mismo. Objetivo En el ejemplo de una aplicacin framework que trabaja con documentos, el mtodo abrir documento podra ser un mtodo plantilla que pregunta si se puede abrir y si es as, que lo aada a la lista de documentos abiertos, lo abra y lo lea. Al definir algunos de los pasos de un algoritmo usando mtodos abstractos, el mtodo plantilla fija su orden, pero permite a las subclases variar esas implementaciones para que se ajusten a sus necesidades. Aplicabilidad Para implementar la parte invariante de un algoritmo y permitir a las subclases que implementen la parte que vara. Cuando el comportamiento comn entre las subclases debe ser factorizado y localizado en una clase comn para evitar que se duplique cdigo.

PATRONES DE DISEO

Estructura

Consecuencia Los mtodos plantilla son una tcnica fundamental para la reutilizacin de cdigo, sobre todo en las bibliotecas de clases, porque factorizan el comportamiento comn. Este patrn nos lleva a una estructura de control invertida en la que las superclases llaman a las subclases y no al revs (el principio de Hollywood). VISITOR (VISITANTE) Visitor permite incluir nuevos mtodos a una clase sin tener que modificarla. Visitor es muy utilizado en compiladores, intrpretes y analizadores de cdigo. Objetivo Muchas operaciones necesitan diferenciar distintos tipos de nodo en el rbol (expresiones, variables, etc.). Aplicabilidad Se recomienda el uso de visitor para las siguientes situaciones:

PATRONES DE DISEO

Estructuras jerrquicas (arboles). Muchas clases poco relacionadas entre s. Estructura de objetos con diferentes interfaces y posibilidad de ampliacin. Estructura con altas probabilidades de incluir nuevos mtodos Compiladores, intrpretes. Estructura

Consecuencia Facilita la definicin de nuevas operaciones. Agrupa operaciones relacionadas. Aadir nuevas clases ConcreteElement es costoso. Permite atravesar jerarquas de objetos que no estn relacionados por un padre comn. El visitor puede acumular el estado de una operacin al visitar la estructura de objetos, en vez de pasarlo como argumento o usar variables globales. Rompe la encapsulacin.

PATRONES DE DISEO

OTROS PATRONES DE DISEO DAO El patrn de diseo DAO consiste bsicamente en una clase que es la que interacta con la base de datos. Los mtodos de esta clase dependen de la aplicacin y de lo que los programadores requieran hacer. DAO encapsula el acceso a la base de datos. Por lo que cuando la capa de lgica de negocio necesite interactuar con la base de datos, va a hacerlo a travs de la API que le ofrece DAO. Objetivo El acceso a los datos vara dependiendo de la fuente de los datos. El acceso al almacenamiento persistente, como una base de datos, vara en gran medida dependiendo del tipo de almacenamiento (bases de datos relacionales, bases de datos orientadas a objetos, ficheros planos...) y de la implementacin del vendedor. Aplicabilidad Desacoplar la lgica de negocio de la lgica de acceso a datos, de manera que se pueda cambiar la fuente de datos fcilmente. Poder seleccionar el tipo de fuente de datos durante la instalacin/configuracin de una aplicacin. Estructura

PATRONES DE DISEO

Consecuencias Flexibilidad en la instalacin/configuracin de una aplicacin. Independencia del vendedor de la fuente de datos. Independencia del recurso (BD relacional, BD orientada a objetos, ficheros planos). Realmente esto slo lo conseguiremos con EJB, donde los DAOs no necesitan recibir la conexin en sus mtodos. Reduce la complejidad de la implementacin de la lgica de negocio. MVC (MODELO DE VISTA CONTROLADOR) Para el diseo de aplicaciones con sofisticados interfaces se utiliza el patrn de diseo Modelo-Vista-Controlador. La lgica de un interfaz de usuario cambia con ms frecuencia que los almacenes de datos y la lgica de negocio. Este patrn trata de realizar un diseo que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lgica de negocio o de datos. Elementos del patrn Modelo: datos y reglas de negocio Vista: muestra la informacin del modelo al usuario Controlador: gestiona las entradas del usuario Ventajas Menor acoplamiento Desacopla las vistas de los modelos. Desacopla los modelos de la forma en que se muestran e ingresan los datos. Mayor cohesin Cada elemento del patrn est altamente especializado en su tarea (la vista en mostrar datos al usuario, el controlador en las entradas y el modelo en su objetivo de negocio).

PATRONES DE DISEO

CALIDAD DE LOS SISTEMAS ENTERPRISE En el desarrollo de software, la calidad de diseo acompaa a la calidad de los requisitos, especificaciones y diseo del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementacin; si la implementacin sigue al diseo, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. La calidad del software Enterprise es medible y vara de un sistema a otro o de un programa a otro. Es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia. La calidad es sinnimo de eficiencia, flexibilidad, correccin, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad; logrando estos aspectos se disminuye los costos de mantenimiento y perfeccionamiento durante el tiempo de explotacin de un sistema Enterprise. Para la obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan uniformar la filosofa de trabajo, en reas de lograr una mayor confiabilidad, y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad de los sistemas Enterprise.

PATRONES DE DISEO

GLOSARIO DE TRMINOS Acceso concurrente.- Informacin que suele ser accedida en forma concurrente por varios usuarios. Arquitectura.- Es un entramado de componentes funcionales que aprovechando diferentes estndares, convenciones, reglas y procesos, permite integrar una amplia gama de productos y servicios informticos, de manera que pueden ser utilizados eficazmente dentro de la organizacin. Automatizar.- Hace ms seguros y fiables los sistemas informticos ofreciendo una mayor seguridad y optimizacin de la red informtica. Calidad.- Es herramienta bsica para una propiedad inherente de cualquier cosa que permite que esta sea comparada con cualquier otra de su misma especie. Confiabilidad.- El trmino confiabilidad es usado generalmente para expresar un cierto grado de seguridad de que un dispositivo o sistema opera exitosamente en un ambiente especfico durante un cierto perodo. Eficacia.- Es la capacidad de alcanzar el efecto que espera o se desea tras la realizacin de una accin. Eficiencia.- La capacidad de disponer de alguien o de algo para conseguir un efecto determinado. Encapsulacin.- Es un mecanismo que consiste en organizar datos y mtodos de una estructura, conciliando el modo en que el objeto se implementa, es decir, evitando el acceso a datos por cualquier otro medio distinto a los especificados. Escalabilidad.- Es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para extender el margen de operaciones sin perder calidad. Framework.- Un conjunto estandarizado de conceptos, prcticas y criterios para enfocar un tipo de problemtica particular, que sirve como referencia para enfrentar y resolver nuevos problemas de ndole similar. Innovar.- Es la creacin o modificacin de un producto, y su introduccin en un mercado.

PATRONES DE DISEO

Lgica de negocio.- Es la parte de un sistema que se encarga de las tareas relacionadas con los procesos de un negocio, tales como ventas, control de inventario, contabilidad, etc. Paradigmas.- Significa ejemplo o modelo, conjunto de prcticas que definen una disciplina cientfica durante un perodo especfico de tiempo Patrn de diseo.- a base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces. Reusabilidad.- Es usar artefactos existentes durante la construccin de un nuevo sistema de software. Robustez.- Es aquel que ejecuta diversos procesos de manera simultnea sin generar fallos o llegar a bloquearse (colgarse). Seguridad.- Es el rea de la informtica que se enfoca en la proteccin de la infraestructura computacional y todo lo relacionado con esta (incluyendo la informacin contenida). Sistemas Enterprise.- Son sistemas de informacin gerenciales que integran y manejan muchos de los negocios asociados con las operaciones de produccin y de los aspectos de distribucin de una compaa en la produccin de bienes o servicios. Tabla Hash.- Permite el acceso a los elementos (telfono y direccin, por ejemplo) almacenados a partir de una clave generada (usando el nombre o nmero de cuenta, por ejemplo). Variabilidad.- Cualidad de las cosas que tienden a cambiar o a transformarse.