Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.”
En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios).
Los patrones de diseño pretenden:
· Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
· Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
· Formalizar un vocabulario común entre diseñadores.
· Estandarizar el modo en que se realiza el diseño.
· Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.
Asimismo, no pretenden:
· Imponer ciertas alternativas de diseño frente a otras.
· Eliminar la creatividad inherente al proceso de diseño.
· No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, 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".
Categorías de patrones
· Según la escala o nivel de abstracción:
· Patrones de arquitectura: Aquéllos que expresan un esquema organizativo estructural fundamental para sistemas de software.
· Patrones de diseño: Aquéllos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.
· Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.
Estructuras o plantillas de patrones
Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos.
La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:
· Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).
· Clasificación del patrón: creacional, estructural o de comportamiento.
· Intención: ¿Qué problema pretende resolver el patrón?
· También conocido como: Otros nombres de uso común para el patrón.
· Motivación: Escenario de ejemplo para la aplicación del patrón.
· Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
· Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.
· Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.
· Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.
· Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.
· Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.
· Código de ejemplo: Código fuente ejemplo de implementación del patrón.
· Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
· Patrones relacionados: Referencias cruzadas con otros patrones.
Características:
· Las plantillas son de bajo costo.
· Se utililizan en diferentes tipos de aplicaciones: web, escritorio, app móviles.
· El código es reutilizable; comprada la plantilla, se adquiere la propiedad intelectual de la misma.
Patrones orientados a objetos
(Análisis y diseño a objetos)
Tareas del patrón:
· Identificación de casos de uso.
· Definición del modelo conceptual.
· Especificación de diagrama de servicio.
· Definición de clases.
Identificación de casos de uso
Definición: el caso de uso describe una funcionalidad parcial del sistema que se desarrolla
Notación: Diagrama de casos de uso.
Modelo conceptual
Abarca las abstracciones del mundo real en términos de claves y objetos.
El Modelo Conceptual ilustra:
• Conceptos (Objetos) en el dominio del problema.
• Es el instrumento (artefacto) más importante de
Crear en el AOO.
• Es la representación de cosas del mundo real y
NO de componentes de software. En él NO se
Definen operaciones.
• Puede representarse mediante un diagrama de
Estructura estático (notación UML).
Características
El modelo conceptual se convierte en el insumo básico del diagrama de clases.
Diagrama de secuencia
Describe espacial y temporal el flujo normal de eventos entre los diferentes conceptos
presentes en el sistema.
Definición de clases:
Definición de clases:
Se especifican las clases presentes en el sistema y se parametrizan (métodos y atributos para cada clase).
Patrones de diseño vista-control
Ofrece un número mayor de ventajas con respecto al patrón orientado a objetos.
Tiene tres componentes (capas de desarrollo)
- Capa vista: en términos de la interfaz de usuario.
- Capa lógica: se almacena e implementan los objetos de la aplicacion, tiene dos presentaciones
Capa conceptos
Ejemplo: Usuario y contraseña
Capa conceptos
Ejemplo: Nombre del usuario y comparar contraseña .
3-Capa de almacenamiento: gestión de archivos, Bases de datos.
Ejemplo: gestión de archivos con los nombres de los usuarios El patrón vista-control sugiere un diseño 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 términos de funciones.
Características:
- Todos los requisitos no deben dar posibilidad a la ambigüedad
- 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 interactúa con el desencadenado una serie de eventos interrelacionados.
Atributo del sistema: Son requisitos no funcionales, que son necesidades propias del producto software.
Aplicación
Medio físico (Hardware) memoria, etc.
Tolerancia a fallos.
Metáfora de la interfaz: Describe el estándar utilizado para desarrollar la interfaz.
Técnicas 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.
Patrón Arquitectónico de capas
La arquitectura del SI es una descripción de los
Subsistemas y componentes, y las relaciones entre ellos.
· Determina:
· La organización estructural del SI.
· La selección de los elementos estructurales.
· Las interfaces entre ellos.
· El comportamiento de los componentes.
· Un componente es una parte física y reemplazable de un sistema.
Catálogo parcial de patrones arquitectónicos
· Llamada y retorno
· estilo más usado en los grandes SI
· Descomposición modular jerárquica
· Orientado a objetos
· En capas
· Centrado en los datos
· permite la manipulación compartida de datos
· Repositorio
· Pizarra
· Flujo de datos
· permite la transformación incremental de los datos
· Batch secuencial
· Tubos y filtros
· Modelo – vista – controlador
· para sistemas interactivos
Patroness Grasp (General reponsability assignament software pattern)
En diseño orientado a objetos, GRASP son patrones generales de software para asignación de responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns" . Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software.
Patrones de software para asignar responsabilidades
Función:
Definir en las clases de análisis.
1-La clase con mayor jerarquía para implementar en ella los métodos.
Clase patrón
2-Asignar responsabilidades a las clases.
Elementos para definir un patrón Grasp.
Diagrama de paquetes
Diagrama de secuencia
Diagrama de paquetes
Paquete: Agrupación 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 interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"
Patrones Grasp
· Patrón experto.
· Patrón creador.
· Patrón bajo acoplamiento.
· Patrón alta cohesión.
· Patrón controlador.
Patrón experto
Determina en un modelo conceptual (Diagrama de clases) la clase que posee la mayor jerarquía para asignarle una responsabilidad "La responsabilidad que se quiera evaluar y debe ser implementado por un método"
Ventajas del patrón experto
- Garantizar el encapsulamiento de la información
- Facilita el bajo acoplamiento en las aplicaciones
Patrón creador
Se utiliza cuando se quiere a partir de una clase con alta jerarquía 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 patrón creador define dos estructuras dentro de la jerarquía
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 modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases
1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)
2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.
3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.
Patron alto cohesión
Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.
1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.
2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.
3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación el deber ser ejecutadas “al mismo tiempo”.
4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.
5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.
6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS
7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.
Patrón controlador
Es el encargado de definir las estructuras para los patrones experto y creador .
Experto: Diagrama de secuencia.
Creadas: Jerarquía: AKO, APO.
Patrones Gof
Gang-of-Four (“pandilla de los cuatro”) Descritos en el libro Design Patterns(Gama1995) definieron un catálogo con 23 Patrones básicos. Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. 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 diseño en distintas circunstancias.
Relación de principales patrones GoF (Gang Of Four)
Patrones creacionales
Abstract Factory (Fábrica 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 creación de un objeto complejo, centralizando dicho proceso en un único punto.
Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear.
Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.
Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la creación 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 podría utilizarla.
Bridge (Puente): Desacopla una abstracción de su implementación.
Composite (Objeto compuesto): Permite tratar objetos compuestos como si de un simple se tratase.
Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
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 idéntica información.
Proxy: Mantiene un representante de un objeto.
Patrones de comportamiento
Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
Mediator (Mediador): Define un objeto que coordine la comunicación 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 automáticamente 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 métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
Template Method (Método plantilla): Define en una operación 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 jerarquía de clases sin modificar las clases sobre las que opera.
