Patrn de diseo

Los patrones de diseo son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces. Un patrn de diseo resulta ser una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias.

Breve resea histrica

En 1979 el arquitecto Christopher Alexander aport al mundo de la arquitectura el libro The Timeless Way of Building; en l propona el aprendizaje y uso de una serie de patrones para la construccin de edificios de una mayor calidad. En palabras de este autor, "Cada patrn describe un problema que ocurre infinidad de veces en nuestro entorno, as como la solucin al mismo, de tal modo que podemos utilizar esta solucin un milln de veces ms adelante sin tener que volver a pensarla otra vez." Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen denominado A Pattern Language, son un intento de formalizar y plasmar de una forma prctica generaciones de conocimiento arquitectnico. Los patrones no son principios abstractos que requieran su redescubrimiento para obtener una aplicacin satisfactoria, ni son especficos a una situacin particular o cultural; son algo intermedio. Un patrn define una posible solucin correcta para un problema de diseo dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones. Ms tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander para desarrollar cinco patrones de interaccin hombre-ordenador (HCI) y publicaron un artculo en OOPSLA-87 titulado Using Pattern Languages for OO Programs. No obstante, no fue hasta principios de la dcada de 1990 cuando los patrones de diseo tuvieron un gran xito en el mundo de la informtica a partir de la publicacin del libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogan 23 patrones de diseo comunes.

Objetivos de los patrones

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 diseadores. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente.

Asimismo, no pretenden:

Imponer ciertas alternativas de diseo frente a otras. Eliminar la creatividad inherente al proceso de diseo.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar 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".

Categoras de patrones
Segn la escala o nivel de abstraccin:

Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.

Patrones de diseo: Aquellos que expresan esquemas para definir estructuras de diseo (o sus relaciones) con las que construir sistemas de software.

Dialectos: Patrones de bajo nivel especficos para un lenguaje de programacin o entorno concreto.

Adems, tambin es importante resear el concepto de "antipatrn de diseo", que con forma semejante a la de un patrn, intenta prevenir contra errores comunes de diseo en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseos muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejn sin salida por haber cometido los mismos errores. Adems de los patrones ya vistos actualmente existen otros patrones como el siguiente:

Interaccin: Son patrones que nos permiten el diseo de interfaces web.

Estructuras o plantillas de patrones

Para describir un patrn se usan plantillas ms o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicacin uniforme entre diseadores. Varios autores eminentes en esta rea han propuesto plantillas ligeramente distintas, si bien la mayora definen los mismos conceptos bsicos. La plantilla ms comn es la utilizada precisamente por el GoF y consta de los siguientes apartados:

Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en la comunidad (normalmente se expresan en ingls).

Clasificacin del patrn: creacional, estructural o de comportamiento. Intencin: Qu problema pretende resolver el patrn? Tambin conocido como: Otros nombres de uso comn para el patrn. Motivacin: Escenario de ejemplo para la aplicacin del patrn. Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrn. Participantes: Enumeracin y descripcin de las entidades abstractas (y sus roles) que participan en el patrn.

Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes. Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin del patrn.

Implementacin: Tcnicas o comentarios oportunos de cara a la implementacin del patrn. Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn. Usos conocidos: Ejemplos de sistemas reales que usan el patrn. Patrones relacionados: Referencias cruzadas con otros patrones.

Relacin de principales patrones GoF (Gang Of Four)

Patrones creacionales

Object Pool (no pertenece a los patrones especificados por GoF): se obtienen objetos nuevos a travs de la clonacin. Utilizado cuando el costo de crear una clase es mayor que el de clonarla. Especialmente con objetos muy complejos. Se especifica un tipo de objeto a crear y se utiliza una interfaz del prototipo para crear un nuevo objeto por clonacin. El proceso de clonacin se inicia instanciando un tipo de objeto de la clase que queremos clonar.

Abstract Factory (fbrica abstracta): permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre s y haciendo transparente el tipo de familia concreta que se est usando.

Builder (constructor virtual): abstrae el proceso de creacin de un objeto complejo, centralizando dicho proceso en un nico punto.

Factory Method (mtodo de fabricacin): centraliza en una clase constructora la creacin de objetos de un subtipo de un tipo determinado, ocultando al usuario la casustica para elegir el subtipo que crear.

Prototype (prototipo): crea nuevos objetos clonndolos de una instancia ya existente. Singleton (instancia nica): garantiza la existencia de una nica instancia para una clase y la creacin de un mecanismo de acceso global a dicha instancia.

Patrones estructurales

Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podra utilizarla.

Bridge (Puente): Desacopla una abstraccin de su implementacin. Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.

Decorator (Envoltorio): Aade funcionalidad a una clase dinmicamente. Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.

Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos que poseen idntica informacin.

Proxy: Mantiene un representante de un objeto. Mdulo: Agrupa varios elementos relacionados, como clases, singletons, y mtodos, utilizados globalmente, en una entidad nica.

Patrones de comportamiento

Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea que deben llevar los mensajes para que los objetos realicen la tarea indicada.

Command (Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin sin necesidad de conocer el contenido de la misma.

Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as como las herramientas necesarias para interpretarlo.

Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementacin de estos.

Mediator (Mediador): Define un objeto que coordine la comunicacin entre objetos de distintas clases, pero que funcionan como un conjunto.

Memento (Recuerdo): Permite volver a estados anteriores del sistema. Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automticamente todos los objetos que dependen de l.

State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.

Strategy (Estrategia): Permite disponer de varios mtodos para resolver un problema y elegir cul utilizar en tiempo de ejecucin.

Template Method (Mtodo plantilla): Define en una operacin el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.

Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarqua de clases sin modificar las clases sobre las que opera.

Patrones de interaccin
El primer intento por aplicar este concepto en el diseo de las interfaces de usuario se dio por Ward Cummingham y Kent Beck quienes adaptaron la propuesta de C. Alexander y crearon cinco patrones de interfaz: Window per task, Few panes, Standard panes, Nouns and verbs, y Short Menu. En aos ms recientes investigadores como Martin Van Welie, Jennifer Tidwell, Jaime Muoz han desarrollado colecciones de patrones de interaccin para la World Wide Web. En dichas colecciones captan la experiencia de programadores y diseadores expertos en el desarrollo de interfaces usables y condensan esta experiencia en una serie de guas o recomendaciones, que puedan ser usadas por los desarrolladores novatos con el propsito de que en poco tiempo adquieran la habilidad de disear interfaces que incidan en la satisfaccin de los usuarios. Los patrones de interaccin buscan la reutilizacin de interfaces eficaces y un manejo ptimo de los recursos de las pginas web, haciendo ms eficaz el consumo de tiempo en el diseo del sitio web y permitiendo a los programadores novatos adquirir ms experiencia.

Aplicacin en mbitos concretos

Adems de su aplicacin directa en la construccin de software en general, y derivado precisamente del gran xito que han tenido, los patrones de diseo han sido aplicados a mltiples mbitos concretos producindose "lenguajes de patrones" y extensos "catlogos" de la mano de diversos autores. En particular son notorios los esfuerzos en los siguientes mbitos:

Patrones de interfaces de usuario, esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-mquina (vase Interaccin persona-computador, Interfaz grfica de usuario).

Patrones para la construccin de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras de software y un nivel de abstraccin importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.

Patrones para la integracin de sistemas (vase Integracin de aplicaciones empresariales), es decir, para la intercomunicacin y coordinacin de sistemas heterogneos.

Patrones de flujos de trabajo, esto es para la definicin, construccin e integracin de sistemas abstractos de gestin de flujos de trabajo y procesos con sistemas empresariales. Vase tambin BPM.

El patrn MVC

MVC: Modelo-Vista-Controlador Es un patrn de arquitectura de las aplicaciones software

Separa la lgica de negocio de la interfaz de usuario

Facilita la evolucin por separado de ambos aspectos Incrementa reutilizacin y flexibilidad

El patrn MVC

Modelo-Vista-Controlador

Un modelo Varias vistas Varios controladores Las vistas y los controladores suelen estar muy relacionados
Los controladores tratan los eventos que se producen en la interfaz grfica (vista)

Esta separacin de aspectos de una aplicacin da mucha flexibilidad al desarrollador

El patrn MVC
1.

Flujo de control

El usuario realiza una accin en la interfaz 2. El controlador trata el evento de entrada

Previamente se ha registrado

El controlador notifica al modelo la accin del usuario, lo que puede implicar un cambio del estado del modelo (si no es una mera consulta) 4. Se genera una nueva vista. La vista toma los datos del modelo
3.

El modelo no tiene conocimiento directo de la vista

La interfaz de usuario espera otra interaccin del usuario, que comenzar otro nuevo ciclo
5.

Introduccin al patrn Arquitectnico MVC MVC, son las siglas de modelo-vista-controlador (o en ingls, model-viewcontroller), que es uno de los tantos patrones de arquitectura de software. Antes de abordar de lleno este patrn, vamos a intentar hacer una introduccin a la arquitectura de software, desmembrndola de lo general hacia lo particular, para al fin llegar al detalle, procurando entender exactamente de que se trata, en el contexto adecuado. Probablemente, este captulo sea el ms complejo (y mucho ms extenso en relacin al Captulo I). Pero si quieres poder aplicar de forma decuada el patrn MVC, debes hacer el esfuerzo de seguirlo con especial inters y actitud entuciasta. Introduccin a la Arquitectura de Software Qu es la arquitectura de software? Es necesario aclarar, que no existe una definicin nica, exacta, abarcativa e inequvoca de arquitectura de software. La bibliografa sobre el tema es tan extensa como la cantidad de definiciones que en ella se puede encontrar. Por lo tanto tratar, no de definir la arquitectura de software, sino ms bien, de introducir a un concepto simple y sencillo que permita comprender el punto de vista desde el cual, este libro abarca a la arquitectura de software pero, sin nimo de que ello represente una definicin ms. A grandes rasgos, puede decirse que la Arquitectura de Software es la forma en la que se organizan los componentes de un sistema, interactan y se relacionan entre s y con el contexto, aplicando normas y principios de diseo y calidad, que fortalezcan y fomenten la usabilidad a la vez que dejan preparado el sistema, para

su propia evolucin. Tal vez ests pensando ...al fin y al cabo, me haz dado una definicin ms.... La respuesta es s. Probablemente no pude contenerme de hacerlo no lo niego -. Pero, no debes tomar lo anterior como una definicin, sino como la forma en la que en este libro, se abarca la arquitectura de software. Tendencias de la Arquitectura de Software Si bien no puede decirse o mejor dicho, no es muy acadmico decirlo, voy a tomarme el atrevimiento de mencionar solo dos tendencias arquitectnicas, A fin de satisfacer la inquietud de curiosos (y de paso, no ocultar que existen), voy a mencionar la existencia de otras dos corrientes: la arquitectura basada en patrones y la arquitectura basada en procesos y metodologas. Personalmente, no las considero como cuatro corrientes Por qu? Porque independientemente de cual te agrade ms, si la AS orientada o objetos o la AS estructural, implican necesariamente dos corrientes que deben aplicarse de forma optativa (o utilizas una o la otra pero no las dos simultneamente), mientras que la AS basada en patrones y la AS basada en procesos, pueden utilizarse como complemento de las dos primeras. Pero esto, es mera filosofa propia, con la cual, no he encontrado demasiado consenso. Pues no los aburrir con ello e iremos a lo prctico. Caractersticas de la Arquitectura de Software: Atributos de calidad La Calidad del Software puede definirse como los atributos implcitamente requeridos en un sistema que deben ser satisfechos. Cuando estos atributos son satisfechos, puede decirse (aunque en forma objetable), que la calidad del software es satisfactoria. Estos atributos, se gestan desde la arquitectura de software que se emplea, ya sea cumpliendo con aquellos requeridos durante la ejecucin del software, como con aquellos que forman parte del proceso de desarrollo de ste. Atributos de calidad que pueden observarse durante la ejecucin del software 1. Disponibilidad de uso 2. Confidencialidad, puesto que se debe evitar el acceso no autorizado al sistema 3. Cumplimiento de la Funcionalidad

requerida 4. Desempeo del sistema con respecto a factores tales como la capacidad de respuesta 5. Confiabilidad dada por la constancia operativa y permanente del sistema 6. Seguridad externa evitando la prdida de informacin debido a errores del sistema 7. Seguridad interna siendo capaz de impedir ataques, usos no autorizados, etc. Atributos de calidad inherentes al proceso de desarrollo del software 8. Capacidad de Configurabilidad que el sistema otorga al usuario a fin de realizar ciertos cambios 9. Integrabilidad de los mdulos independientes del sistema 10. Integridad de la informacin asociada 11.Capacidad de Interoperar con otros sistemas (interoperabilidad) 12.Capacidad de permitir ser Modificable a futuro (modificabilidad) 13.Ser fcilmente Mantenible (mantenibilidad) 14.Capacidad de Portabilidad, es decir que pueda ser ejecutado en diversos ambientes tanto de software como de hardware 15.Tener una estructura que facilite la Reusabilidad de la misma en futuros sistemas 16.Mantener un diseo arquitectnico Escalable que permita su ampliacin (escalabilidad) 17.Facilidad de ser Sometido a Pruebas que aseguren que el sistema falla cuando es lo que se espera (testeabilidad)