1. Uso de patrones de
arquitectura
Profesor Pedro Veloso Hernández
Master Ingeniería de Software
UPM
2. ¿ que es un Patrón de diseño?
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.
Fuente Wikipedia
"Each pattern describes a problem which occurs over
and over again in our environment, and then describes the core
of the solution to that problem, in such a way that you can use this solution
a million times over, without ever doing it the same way twice" [AIS+77].
Desing Patterns, Christopher Alexander
E-book Version
Los escaladores usan a menudo patrones de diseño, usado
Arneses, cuerdas, mosquetones, que usan dadas ciertas
Condiciones de soporte, forma, y para situaciones que deben
Resolver como : salvataje, cruzar dos personas en un solo
Intento, saltarse una gran roca, etc.
3. ¿ que es un patrón UML?
Los patrones UML son colaboraciones parametrizadas
, esto es , son un grupo de clases/objetos
colaborando entre sí que se pueden abstraer de un
conjunto de escenarios general.
Los patrones son un medio excelente para lograr
reutilización y desarrollo robusto.
A medida que los patrones se descubren en todo
nuevo proyecto, se puede reutilizar la plantilla básica
del patrón desde modelos previos con los nombres de
las variables apropiadas modificados para el proyecto
en curso.
"Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno
, así como la solución al mismo, de tal modo que podemos utilizar esta solución
un millón de veces más adelante sin tener que volver a pensarla otra vez."
4. Condiciones para usar un patrón
UML
Los patrones generalmente describen cómo
resolver un problema abstracto y la tarea
del usuario del patrón consiste en modificar
los elementos del patrón para cumplir las
demandas del compromiso actual.
Antes de comenzar a usar un patrón
primero debe ser creado como un diagrama
estándar de UML o existir como tal en
algún repositorio
5. Vamos a un ejemplo
Este es un ejemplo de patrones de diseño propuesto en GOF “ Abstract Factory”
patrones descriptos en el libro "Design Patterns - Elements of Reusable Object-Oriented
Software" de Gamma et al., más conocidos como 'La Banda de los Cuatro', 'Gang of Four‘
o GoF en forma abreviada.
6. Cuando “ no” usar patrones de
diseño
Del mismo modo que no es aconsejable optimizar
prematuramente, no se deben utilizar patrones de
diseño antes de tiempo.
Seguramente sea mejor implementar algo primero y
asegurarse de que funciona, para luego utilizar el
patrón de diseño para mejorar las flaquezas; esto es
cierto, sobre todo, cuando aún no ha identificado
todos los detalles del proyecto ( comprensión del
dominio del problema)
Los patrones de diseño pueden incrementar o
disminuir la capacidad de comprensión de un diseño o
de una implementación,
7. ¿ que familias de patrones de
diseño utilizaremos?
Para este curso, usaremos dos
familias de patrones de diseño
propuestos en la bibliografía
sugerida. Cabe destacar que existen
muchas familias de patrones de
diseño, por lo que nos basaremos en
los mas usados, en función del
objetivo que nos hemos planteado en
este curso.
Las familias serán GRASP Y GAO
8. Descripción de familias de patrones
GRASP : son patrones generales de
software para asignación de
responsabilidades, es el acrónimo de
"General Responsibility Assignment
Software Patterns" .
son una serie de "buenas prácticas" de
aplicación recomendable en el diseño de
software.
Patrones GRASP; Experto , Creador , Bajo
Acoplamiento ,Alta Cohesión ,Controlador
9. Descripción de familias de
patrones
GOF: Es la abreviación del grupo Gang of
Four, compuesto por Erich Gamma, Richard
Helm, Ralph Jhonson y John Vlisides,
quienes en su publicación “ Design
Patterns” ( década de los 90s), describen
23 patrones de diseño comúnmente
utilizados y de gran aplicabilidad en
problemas de diseño usando modelamiento
UML.
Estos patrones se agrupan en las siguientes
categorías : Creacionales, estructurales y
de comportamiento.
10. Relación de familias de patrones de
diseño
PATRONES
GRASP
GOF
Experto
Creador
Bajo acoplamiento
Alta Cohesión
Controlador
Creacionales
Estructurales
Comportamiento
Fabrica, constructor, método
de fabricación, prototipo ,
instancia única
Adaptador, puente, objeto
Compuesto, envoltorio, fachada,
Peso ligero, proxy
Cadena responsabilidad, orden,
Intérprete, iterador, mediador, recuerdo,
Observador, estado, estrategia,
método plantilla, visitante
12. Experto
El GRASP de experto en información es el
principio básico de asignación de
responsabilidades en diseño O.O.
Nos indica que la responsabilidad de la
creación de un objeto debe recaer sobre la
clase que conoce toda la información
necesaria para crearlo.
Nótese, que el cumplimiento de una
responsabilidad requiere a menudo
información distribuida en varias clases de
objetos.
13. Ejemplo del patrón experto
Ejemplo
En la aplicación del punto de venta,
alguna clase necesita conocer el
gran total de la venta. Comience
asignando las responsabilidades con
una definición clara de ellas. A partir
de esta recomendación se plantea la
pregunta:
¿Quién es el responsable de conocer el
gran total de la venta?
Desde el punto de vista del patrón
Experto, deberíamos buscar la clase
De objetos que posee la información
necesaria para calcular el total.
En conclusión, para cumplir con la responsabilidad
de conocer y dar el total de la venta, se asignaron
tres responsabilidades a las tres clases
de objeto así:
Venta ( conoce total de la venta)
Ventaslineaproductos ( conoce subtotal de la linea de
productos)
Especificaciondeproducto (conoce el precio del producto)
14. Creador
El patrón creador nos ayuda a identificar quién
debe ser el responsable de la creación (o
instanciación) de nuevos objetos o clases.
El patrón Creador guía la asignación de
responsabilidades relacionadas con la creación de
objetos, tarea muy frecuente en los sistemas
orientados a objetos.
El propósito fundamental de este patrón es
encontrar un creador que debemos conectar con el
objeto producido en cualquier evento.
Al escogerlo como creador, se da soporte al bajo
acoplamiento.
15. Ejemplo patrón creador
Ejemplo
En la aplicación del punto de venta, ¿quién
Debería encargarse de crear una Instancia
VentasLineadeProducto?
Desde el punto de vista del patrón Creador,
deberíamos buscar una clase que agregue,
contenga y realice otras operaciones sobre este
tipo de instancias
Una Venta contiene (en realidad, agrega)
muchos objetos VentasLineadeProducto;
por ello, el patrón Creador sugiere que
Venta es idónea para asumir la
responsabilidad de crear las instancias
VentasLineadeProducto.
Esta asignación de responsabilidades
requiere definir en Venta un método de
hacer-LineadeProducto.
16. 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
Los beneficios de este factor es que no se afectan
por cambios de otros componentes, son fáciles de
entender por separado y fáciles de reutilizar.
17. Ejemplo bajo acoplamiento
Ejemplo: En el caso del punto de
Ventas se tienen tres clases
Pago, TPDV y Venta y se quiere
crear una instancia de Pago y
asociarla a Venta.
¿Que clase es la responsable de
realizarlo?
Según el patrón de Bajo
Acoplamiento la relación debería
ser a través de TPDV.
Esta última asociación es mejor
Dado que Venta realiza la
creación del Pago y no TPDV por
lo tanto se reduce la dependencia
de este último con el resto de las clases.
18. Alta Cohesión
Nos dice que la información que almacena
una clase debe de ser coherente y está en
la mayor medida de lo posible relacionada
con la clase.
La cohesión es una medida de cuán
relacionadas y enfocadas están las
responsabilidades de una clase.
Una clase con alta cohesión, compartirá la
responsabilidad de una operación, con otras
clases
Una clase con baja cohesión, concentrará
las responsabilidades de una o muchas
operaciones .
19. Ejemplo alta cohesión
Ejemplo: En el caso
del punto de ventas
se tienen tres clases
Pago, TPDV y Venta y
se quiere crear una
instancia de Pago y
asociarla a Venta.
Este diseño delega a Venta la responsabilidad
de crear el pago.
Este diseño es conveniente ya que da soporte a
una alta cohesión y a
un bajo acoplamiento.
¿Qué pasa si el sistema tiene 50
operaciones, todas recibidas por la
clase TPDV ?
La clase se iría saturando con tareas
y terminaría perdiendo la cohesión
20. Controlador
El patrón controlador es un patrón que sirve como
intermediario entre una determinada interfaz y el
algoritmo que la implementa, de tal forma que es la
que recibe los datos del usuario y la que los envía a
las distintas clases según el método llamado.
Este patrón sugiere que la lógica de negocios debe
estar separada de la capa de presentación, esto para
aumentar la reutilización de código y a la vez tener un
mayor control.
Un Controlador es un objeto de interfaz no destinada
al usuario que se encarga de manejar un evento del
sistema. Define además el método de su operación.
21. Ejemplo de controlador
Por ejemplo, cuando un
cajero que usa un sistema
de Terminal en el punto
de venta oprime el botón
"Terminar Venta”, está
generando un evento
sistémico que indica que
“la venta ha terminado
Nótese que la clase TPDVApplet - parte de la capa
de presentación - transmite un mensaje
introducirProducto al objeto TPDV.
?No intervino en el proceso de la operación, ni la
decisión de cómo manejarla, el applet se
limitó a delegarla a la capa del dominio.
23. Creacionales
1.-Fabrica abstracta (Abstract Factory) : Proporciona un interfaz
para crear las familias de objetos relacionados o dependientes sin
especificar sus clases concretas.
2.-Constructor (Builder): Separa la construcción de un objeto
complejo de su representación , de modo que el mismo proceso de
construcción pueda crear representaciones diferentes.
3.-Método fabricación(Factory Method) : Define un interfaz
para crear un objeto, pero dejar a subclases decidir sus instancias .
El Método De la fábrica deja a una clase la creación de ejemplares o
copias a subclases.
4.-Prototipo(Prototype) : Crea nuevos objetos creándolos de una
instancia ya existente.
5.-Instancia única (Singleton) : Asegure que una clase sólo tiene
una instancia , y proporcionarle un punto global de acceso a dicha
instancia
24. Estructurales
6.-Adaptador (adapter) :Convierte la interfaz de una clase en otra
interfaz que otra clase puede usar . debido a que la interfaces es
incompatibles con dicha clase
7.-Puente ( bridge) :Desacopla una abstracción de su implementación
de modo que los dos puedan variar por separado.
8.-Peso ligero (Flyweight ) :Reduce la redundancia cuando gran cantidad
de objetos poseen idéntica información.
9.-Fachada (Facade) : Proporciona un interfaz unificada a un juego de
interfaces en un subsistema. La fachada define un interfaz de nivel más alto
que hace el subsistema fácil de usar.
10.-Envoltorio (Decorator) :Adjunta responsabilidades adicionales a un
objeto dinámicamente. Los decoradores proporcionan una alternativa
flexible a la subclasificación para ampliar la funcionalidad.
11.-Objeto compuesto (Composite) :El objeto compuesto permite
tratar a jerarquías de objetos en individuales y composiciones de objetos
uniformemente como si se tratase de objetos simples
12.-Proxy : Mantiene un representante de un objeto
25. Comportamiento
13.-Cadena responsabilidad (Chain of Responsibility ): Encadena los
objetos de encubrimiento y pasa la petición a lo largo de la cadena hasta que
un objeto la maneja. Permite establecer la línea que deben llevar los mensajes
para que los objetos realicen la tarea indicada.
14.-Orden (Command) : Encapsula una operación en un objeto, permitiendo
ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
15.-Intérprete (Interpreter) :Considerando un lenguaje , define un
representación para su gramática con un intérprete que usa la representación
para interpretar sentencias en el mismo lenguaje.
16.-Iterador (Iterator) :Proporciona un modo de tener acceso a los
elementos de un objeto agregado secuencialmente sin exponer su
representación subyacente.
17.-Mediador (Mediator) :Define un objeto que coordine la comunicación
entre objetos de distintas clases, pero que funcionan como un conjunto.
18.-Recuerdo (Memento) : Sin violar encapsulación, captura y externaliza
el estado interno de un objeto de modo que el objeto pueda ser restaurado a
este estado más tarde.
26. Comportamiento
19.-Observador (Observer) : Define de uno a varios la
dependencia entre objetos de modo que cuando se produce un
cambio de estado del objeto, todos sus dependientes sean
notificados y puestos al día automáticamente.
20-Estado (State) :Permite que un objeto modifique su
comportamiento cada vez que cambie su estado interno
21.-estrategia (Strategy) : Define una familia de algoritmos
( métodos ), encapsula cada uno, y los hace permutables. La
estrategia deja al algoritmo ( método ) variar por separado de los
clientes ( objetos ) que lo usan o invocan .
22.-método plantilla ( template method) :Define el esqueleto de
un algoritmo en una operación, aplazando algunos pasos a
subclases. El Método de Plantilla deja a subclases redefinir los ciertos
pasos de un algoritmo sin cambiar la estructura del algoritmo.
23.-Visitante (Visitor) :Permite definir nuevas operaciones sobre
una jerarquía de clases sin modificar las clases sobre las que opera.
![¿ que es un Patrón de diseño?
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.
Fuente Wikipedia
"Each pattern describes a problem which occurs over
and over again in our environment, and then describes the core
of the solution to that problem, in such a way that you can use this solution
a million times over, without ever doing it the same way twice" [AIS+77].
Desing Patterns, Christopher Alexander
E-book Version
Los escaladores usan a menudo patrones de diseño, usado
Arneses, cuerdas, mosquetones, que usan dadas ciertas
Condiciones de soporte, forma, y para situaciones que deben
Resolver como : salvataje, cruzar dos personas en un solo
Intento, saltarse una gran roca, etc.](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)