Los patrones de diseño 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.
Objetivos de los patrones
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".
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).
- Clarificació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.
- Patrones orientado a objetos
- (análisis y diseño a objetos)
Tareas del patrón:
1-Identificacion de casos de uso.
2-Definición del modelo conceptual.
3-Especificación de diagrama de servicio.
4-Definición de clases.
Definición: el caso de uso describe una funcionalidad parcial del sistema que se desarrolla
Notación: Diagrama de casos de uso
Ejemplo:
Ejemplo: de una vídeo tienda
Se especifican las clases presentes en el sistema y se parametrizan(métodos y atributos para cada clase)
Ejemplo:
Patrones de diseño vista-control
Ofrece un numero mayor de ventajas con respecto al patrón orientado a objetos.
Ejemplo:
Necesidad se traduce en términos de funciones
Características:
1-Todos los requisitos no deben dar posibilidad a la ambiquedad
2-Los requisitos deben permitir entender el domino de la aplicaron
3-Los requisitos se deben obtener del cliente o usuario
Ref: Notación para identificar la funcionalidad del sistema
Identificacion 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 objetosEjemplo:
Caracteristicas
El modelo conceptual se convierte en el insumo basico del diagrama de clasesDiagrama de secuencia
Describe espacial y temporal el frujo normal de eventos entre los diferentes conceptos presentes en el sistema.Ejemplo: de una vídeo tienda
Definición de clases
Se especifican las clases presentes en el sistema y se parametrizan(métodos y atributos para cada clase)
Ejemplo:
Patrones de diseño vista-control
Ofrece un numero mayor de ventajas con respecto al patrón orientado a objetos.
Tiene tres componentes (capas de desarrollo)
1-Capa vista: en términos de la interfaz de usuario.
2-Capa lógica: se almacena e implementan los objetos de la aplicacion,tiene dos presentación
- Capa conceptos
Ejemplo: Usuario y contraseña
- Capa conceptos
3-Capa de almacenamiento: gestión de archivos,Bases de datos
Ejemplo: gestión de archivos con los nombres de los usuarios
Ejemplo: gestión de archivos con los nombres de los usuarios
Ejemplo:
El patrón vista-control sugiere un diseño TOP-DOWN con una importancia contrada 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 softwareNecesidad se traduce en términos de funciones
Características:
1-Todos los requisitos no deben dar posibilidad a la ambiquedad
2-Los requisitos deben permitir entender el domino de la aplicaron
3-Los requisitos se deben obtener del cliente o usuario
Tabla de funciones
Ref | Descripción | Categoría |
Ejemplo:
R.1:Cuando es una funcionalidad del alto nivel
R.1.1:Cuando una funcionalidad esta incluida <<include>> o extendida <<extend>>
en una funcionalidad de alto nivel
Descripción:Relato detallado de la función que debe incluir el o los activos
Categoría | Descripción |
Evidente Oculta Superflua | La función debe ser implementada por el sistema y su ejecución debe ser vista por el usuario La función no debe ser visualizada por el usuario La función no afecta el funcionamiento general del sistema si es oculta o si es evidente |
Notación: levantar los requisitos
Diagrama de casos de uso
Atributo del sistema:
Son requisitos no funcionales,que son necesidades propias del producto software
Ejemplos:
- Aplicacion
- Medio fisico(Hardware) memoria,etc.
- Tolerancia a fallos.
- Metafora de la interfaz:Describe el standar utilizado para desarrollar la interfaz .
Tecnicas 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
Los patrones arquitectónicos y los patrones de diseño no son lo mismo. Si bien los patrones de diseño sirven para responder a necesidades muy comunes o resolver problemas frecuentes y suelen "afectar" o, mejor dicho, aplicarse a partes pequeñas de código, los patrones arquitectónicos son paradigmas de más alto nivel que se aplican en general a toda una aplicación o proyecto y que sirven para asegurar que la aplicación cumple ciertos objetivos o requisitos globales. La arquitectura Modelo-Vista-Controlador es un patrón de mucho más alto nivel que los de diseño. Es de la arquitectura global y por lo tanto todos los recursos del proyecto deben cumplirlo.
Patrones de software para asignar responsabilidades
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
Los patrones arquitectónicos y los patrones de diseño no son lo mismo. Si bien los patrones de diseño sirven para responder a necesidades muy comunes o resolver problemas frecuentes y suelen "afectar" o, mejor dicho, aplicarse a partes pequeñas de código, los patrones arquitectónicos son paradigmas de más alto nivel que se aplican en general a toda una aplicación o proyecto y que sirven para asegurar que la aplicación cumple ciertos objetivos o requisitos globales. La arquitectura Modelo-Vista-Controlador es un patrón de mucho más alto nivel que los de diseño. Es de la arquitectura global y por lo tanto todos los recursos del proyecto deben cumplirlo.
Arquitectura
- La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.
- Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información.
- La Arquitectura de Software establece los fundamentos para que analistas, diseñadores, programadores, etc. trabajen en una línea común que permita alcanzar los objetivos del sistema de información, cubriendo todas las necesidades.
- Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
- La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.
La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.
Las capas permiten determinar conceptos como:
- Acoplamiento: Clases
- Cohesión: Métodos
Todo aplicación de software debe tener "bajo acoplamiento y alto cohesión"
Patrón de clases
- Las clases se deben especificar de la menos acoplada a la mas acoplada
- Las clases de deben implementar de la mas acoplada a las menos acoplada
Patrones "Grasp"
General reponsability assignament software pattern
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: Agrupacion de casos de uso con aspectos similares en su funcionalidad
Ejemplo:
Diagrama de secuencia
Patrones Grasp
1- Patrón experto.
2-Patrón creador.
3-Patrón bajo acoplamiento.
4-Patrón alta cohesión.
5-Patrón controlador .
1-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
2-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
Ejemplo
El patrón creador define dos estructuras dentro de la jerarquia
- Esctructura AKO
- Estructura APO
AKO(A King of): una clase de
APO(A Punt of): una parte de
Ejemplo: en la biblioteca
Ejemplo: en la Publicación
La clase revista puede
Asignar numero de ejemplares
- Asignar un nombre
- Asignar editorial
Los dos patrones se relacionan en términos de funcionamiento
3-Bajo Acoplamiento
4-Alto cohesión
El bajo acoplamiento define que las clases: deben implementar la menor cantidad de métodos para garantizar independencia y alta cohesión
5-Patrón controlador
Es el encargado de definir las estructuras para los patrones experto y creador
Experto: Diagrama de secuencia
Creadas: Jerarquía: AKO,APOPatrones 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.
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 uno 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.
