Los patrones de diseo son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.

En otras palabras, brindan una solucin ya probada y documentada a problemas de desarrollo de software que estn sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrn: su nombre, el problema (cuando aplicar un patrn), la solucin (descripcin abstracta del problema) y las consecuencias (costos y beneficios). 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: Aqullos que expresan un esquema organizativo estructural fundamental para sistemas de software. Patrones de diseo: Aqullos 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. 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. Caractersticas:

Las plantillas son de bajo costo. Se utililizan en diferentes tipos de aplicaciones: web, escritorio, app mviles. El cdigo es reutilizable; comprada la plantilla, se adquiere la propiedad intelectual de la misma.

Patrones orientados a objetos (Anlisis y diseo a objetos) Tareas del patrn: Identificacin de casos de uso. Definicin del modelo conceptual. Especificacin de diagrama de servicio. Definicin de clases. Identificacin de casos de uso Definicin: el caso de uso describe una funcionalidad parcial del sistema que se desarrolla Notacin: Diagrama de casos de uso.

Modelo conceptual Abarca las abstracciones del mundo real en trminos de claves y objetos. El Modelo Conceptual ilustra: Conceptos (Objetos) en el dominio del problema. Es el instrumento (artefacto) ms importante de Crear en el AOO. Es la representacin de cosas del mundo real y NO de componentes de software. En l NO se Definen operaciones. Puede representarse mediante un diagrama de Estructura esttico (notacin UML). Caractersticas El modelo conceptual se convierte en el insumo bsico del diagrama de clases. Diagrama de secuencia Describe espacial y temporal el flujo normal de eventos entre los diferentes conceptos presentes en el sistema.

Definicin de clases: Se especifican las clases presentes en el sistema y se parametrizan (mtodos y atributos para cada clase).

Patrones de diseo vista-control Ofrece un nmero mayor de ventajas con respecto al patrn orientado a objetos. Tiene tres componentes (capas de desarrollo) Capa vista: en trminos de la interfaz de usuario. Capa lgica: se almacena e implementan los objetos de la aplicacion, tiene dos presentaciones Capa conceptos Ejemplo: Usuario y contrasea Capa conceptos Ejemplo: Nombre del usuario y comparar contrasea . 3-Capa de almacenamiento: gestin de archivos, Bases de datos. Ejemplo: gestin de archivos con los nombres de los usuarios El patrn vista-control sugiere un diseo TOP-DOWN con una importancia centrada en la interfaz de usuario la cual debe ser obtenida a partir de los requisitos del producto software. Requisitos Es una necesidad que tiene un usuario o cliente de un producto software

Necesidad se traduce en trminos de funciones.

Caractersticas: Todos los requisitos no deben dar posibilidad a la ambigedad Los requisitos deben permitir entender el domino de la aplicaron Los requisitos se deben obtener del cliente o usuario Diagrama de casos de uso

Actor: fuente o sumidero "Externo" al sistema que interacta con el desencadenado una serie de eventos interrelacionados.

Atributo del sistema: Son requisitos no funcionales, que son necesidades propias del producto software. Aplicacin Medio fsico (Hardware) memoria, etc. Tolerancia a fallos. Metfora de la interfaz: Describe el estndar utilizado para desarrollar la interfaz.

Tcnicas para levantar requisitos: 1-Entrevista. 2-JAD (Joint applications Development). 3-Sketch ans story board. 4-Concept Moping. 5-Brainstorming (lluvia de ideas). 6-Layout. 7-Use case. 8-Patrones. 9-Chek List. Patrn Arquitectnico de capas La arquitectura del SI es una descripcin de los Subsistemas y componentes, y las relaciones entre ellos. Determina: La organizacin estructural del SI. La seleccin de los elementos estructurales. Las interfaces entre ellos. El comportamiento de los componentes. Un componente es una parte fsica y reemplazable de un sistema. Catlogo parcial de patrones arquitectnicos Llamada y retorno estilo ms usado en los grandes SI Descomposicin modular jerrquica Orientado a objetos

En capas Centrado en los datos permite la manipulacin compartida de datos Repositorio Pizarra Flujo de datos permite la transformacin incremental de los datos Batch secuencial Tubos y filtros Modelo vista controlador para sistemas interactivos

Patroness Grasp (General reponsability assignament software pattern) En diseo orientado a objetos, GRASP son patrones generales de software para asignacin de responsabilidades, es el acrnimo de "General Responsibility Assignment Software Patterns" . Aunque se considera que ms que patrones propiamente dichos, son una serie de "buenas prcticas" de aplicacin recomendable en el diseo de software. Patrones de software para asignar responsabilidades Funcin: Definir en las clases de anlisis. 1-La clase con mayor jerarqua para implementar en ella los mtodos. Clase patrn 2-Asignar responsabilidades a las clases. Elementos para definir un patrn Grasp. Diagrama de paquetes Diagrama de secuencia Diagrama de paquetes Paquete: Agrupacin de casos de uso con aspectos similares en su funcionalidad . ejemplo:

diagrama de secuencia

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre objetos en un sistema segn UML. En ingls se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"

Patrones Grasp Patrn experto. Patrn creador. Patrn bajo acoplamiento. Patrn alta cohesin. Patrn controlador.

Patrn experto Determina en un modelo conceptual (Diagrama de clases) la clase que posee la mayor jerarqua para asignarle una responsabilidad "La responsabilidad que se quiera evaluar y debe ser implementado por un mtodo"

Ventajas del patrn experto Garantizar el encapsulamiento de la informacin Facilita el bajo acoplamiento en las aplicaciones Patrn creador Se utiliza cuando se quiere a partir de una clase con alta jerarqua obtener clases descendiente o instancias a partir de las clases obtenidas. Tipos de clases: Clases abstractas (1) Clases concretas (2) (1) son las clases que dan origen a otras solamente. (2) son las clases a partir de las cuales se pueden obtener instancias.

El patrn creador define dos estructuras dentro de la jerarqua Estructura AKO Estructura APO

AKO(A King of): una clase de APO(A Punto of): una parte de Patron bajo Acoplamiento Es la idea de tener las clases lo menos ligadas entre s que se pueda. De tal forma que en caso de producirse una modificacin en alguna de ellas, se tenga la mnima repercusin posible en el resto de clases, potenciando la reutilizacin, y disminuyendo la dependencia entre las clases 1. Acoplamiento de Contenido: Cuando un mdulo referencia directamente el contenido de otro mdulo. (En lenguajes de alto nivel es muy raro) 2. Acoplamiento Comn: Cuando dos mdulos acceden (y afectan) a un mismo valor global. 3. Acoplamiento de Control: Cuando un mdulo le enva a otro un elemento de control que determina la lgica de ejecucin del mismo. Patron alto cohesin Nos dice que la informacin que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase. 1. Cohesin Coincidente: El mdulo realiza mltiples tareas, sin ninguna relacin entre ellas. 2. Cohesin Lgica: El mdulo realiza mltiples tareas relacionadas, pero, en tiempo de ejecucin, slo una de ellas ser llevada a cabo. 3. Cohesin Temporal: Las tareas llevadas a cabo por un mdulo tienen, como nica relacin el deber ser ejecutadas al mismo tiempo. 4. Cohesin de Procedimiento: La nica relacin que guardan las tareas de un mdulo es que corresponden a una secuencia de pasos propia del producto. 5. Cohesin de Comunicacin: Las tareas corresponden a una secuencia de pasos propia del producto y todas afectan a los mismos datos. 6. Cohesin de Informacin: Las tareas llevadas a cabo por un mdulo tienen su propio punto de arranque, su codificacin independiente y trabajan sobre los mismos datos. El ejemplo tpico: OBJETOS 7. Cohesin Funcional: Cuando el mdulo ejecuta una y slo una tarea, teniendo un nico objetivo a cumplir, se dice que tiene Cohesividad Funcional.

Patrn controlador

Es el encargado de definir las estructuras para los patrones experto y creador . Experto: Diagrama de secuencia. Creadas: Jerarqua: AKO, APO.

Patrones Gof Gang-of-Four (pandilla de los cuatro) Descritos en el libro Design Patterns(Gama1995) definieron un catlogo con 23 Patrones bsicos. Los patrones de diseo (design patterns) 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 es 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 reusable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias. Relacin de principales patrones GoF (Gang Of Four) Patrones creacionales 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 un 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 poseen idntica informacin. Proxy: Mantiene un representante de un objeto. 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.