(Microsoft PowerPoint - Tema 2 - Introducci\363n a los PPDD.ppt)

escuela técnica superior
de ingeniería informática
Introducción a los
Patrones de Diseño
Departamento de
Lenguajes y Sistemas Informá
Informáticos
Ingeniería del Software II
El Camino
♦ Qué es un Patrón de Diseño (PD)
♦ Qué no es un PD
1
Qué es un Patrón de Diseño
♦ ¿Qué es el diseño?¿Qué es un patrón? ¿Qué es un
patrón de diseño?
♦ El diseño es una actividad
♦ El cómo frente al qué
♦ Hacerlo correcto frente a hacer lo correcto
♦ Asignar responsabilidades a las clases
♦ ¿Es una actividad difícil?
♦ Debe serlo pues está bien remunerada
♦ “Un martillo no te hace un buen arquitecto”.
Conocer un lenguaje OO no te hace un buen
diseñador (aunque es imprescindible)
♦ Los requisitos no funcionales son “conflictivos”
Qué es un Patrón de Diseño
♦ Por lo tanto el diseñador debe …
♦ Encontrar una solución que consiga el equilibrio
óptimo entre las propiedades no funcionales
♦ Si damos el mismo documento de requisitos a 10
diseñadores, obtendremos 10 diseños diferentes
♦ ¿Qué diferencia hay entre los diseñadores
expertos y los novatos?
♦ Recetas para los problemas habituales. No
están reinventando la rueda continuamente
♦ Utilizan recetas exitosas
♦ ¿Cómo se describen estas recetas?
2
Qué es un Patrón de Diseño
♦ Orígenes de los PP.DD
♦ Definiciones
♦ Clasificación
♦ Ejemplo: PD Singleton
Qué es un Patrón de Diseño
Orígenes de los PP.DD
♦ Definiciones
♦ Clasificación
♦ Ejemplo: PD Singleton
3
Qué es un PD
Orígenes de los PP.DD
♦ Christopher Alexander
(Viena, 1936)
1977
1979
Qué es un PD
Orígenes de los PP.DD
Ward
Cunnighan
OOPSLA 87
Kent Beck
1.
2.
3.
4.
5.
Window per Task
Few Panes
Standard Panes
Nouns and Verbs
Short Menus
4
Qué es un PD
Orígenes de los PP.DD
♦ 1990. Erich Gamma asiste a una charla de
Bruce Andersen en un taller del OOPSLA,
titulada “Architecture Handbook”. Esta
realizando su tesis doctoral y necesita
desarrollar un Framework C++ para
aplicaciones gráficas multiplataforma (ET++)
♦1991. Andersen organiza un taller donde Gamma coincide con:
Richard
Helm
Ralph
Johnson
John
Vlissides
Qué es un PD
Orígenes de los PP.DD
♦ 1993. Beck y Booch “sufragan” un retiro en las montañas de
colorado. Nace el HillSide
♦1994. Hillside organiza la primera edición del PLOP
(Patterns Languages of Program Design). La banda
de los cuatro venden más de 750 ejemplares de su
libro (10 veces más que cualquier libro hasta
entonces)
5
Qué es un PD
Orígenes de los PP.DD
Lecciones aprendidas
♦ Los PP.DD han surgido tomando ideas de otras disciplinas (la
arquitectura las toma a su vez de la Biología)
♦ Los PP.DD han tenido su origen en la Academia y no en la
industria (es de los pocos ejemplos)
♦ Las tesis doctorales sirven para algo
♦ El mundo anglosajón suele hacer un uso intensivo de los
grupos de presión en todos los ámbitos
Qué es un PD
♦ Orígenes de los PP.DD
Definiciones
♦ Clasificación
♦ Ejemplo: PD Singleton
6
Qué es un PD
Definiciones
♦ De manera general
Patrón: Modelo que sirve de
muestra para sacar otra cosa
igual (RAE)
Patrón de diseño: Una solución
general a un problema general
que puede adaptarse a un
problema concreto
http://www.textile-creation-club.com/esp/patrones.htm
Qué es un PD
Definiciones
♦ En Arquitectura
Cada patrón describe un problema que ocurre
una y otra vez en nuestro entorno. También
describe el núcleo de la solución al problema, de
forma que puede utilizarse un millón de veces
sin hacer dos veces lo mismo
•
•
•
•
•
Técnica de descripción
Par problema-solución
Recurrente
Sólo el núcleo, no es una solución completa
Reutilizable
7
Qué es un PD
Definiciones
♦ En Ingeniería del Software (Gamma95, pág. 360)
A design pattern systematically names, motivates,
and explains a general design that addresses a
recurring design problem in OO systems.
It describes the problem, the solution, when to
apply the solution, and its consequences. It also
gives implementation hints and examples.
The solution is a general arrangement of object and
classes that solve the problem. The solution is
customized and implemented to solve the problem
in a particular context.
Qué es un PD
Definiciones
♦ En Ingeniería del Software (Larman, pag. 204)
Un patrón es un par problema/solución con nombre
que se puede aplicar en nuevos contextos con
consejos acerca de cómo aplicarlo en nuevas
situaciones y discusiones sobre sus compromisos
♦ Existe consenso en:
♦ Par (problema, solución)
♦ Reutilizar conocimiento vs reutilizar software
♦ Problemas recurrentes (¿Cuándo se considera
recurrente?)
8
Qué es un PD
♦ Orígenes de los PP.DD
♦ Definiciones
Clasificación
♦ Ejemplo: PD Singleton
Clasificación
Plantilla de descripción de la GoF
1. Nombre y clasificación: expresa sucintamente la esencia del patrón
2. Intención: frase corta que responde a qué hace y qué resuelve
3. También conocido como: otros nombres conocidos para el PD
4. Motivación: un escenario que ilustra como el PD resuelve un problema
concreto
5. Aplicabilidad: otras situaciones en las que resulta aplicable el PD
6. Estructura: diagramas de clases
7. Participantes: responsabilidad de cada clase participante
8. Colaboraciones: diagrama de colaboración y/o de secuencias
9. Consecuencias: ventajas e inconvenientes
10.Implementación: dificultades, técnicas y trucos a tener en cuenta al
aplicar el PD
11.Código de ejemplo: ejemplo de implementación y de uso del PD
12.Usos conocidos: ejemplos de uso en sistemas reales
13.Patrones relacionados: diferencias con los patrones más
relacionados
9
Clasificación
Catálogo de la GoF
Creacional
Fábrica Abstracta, Método Fábrica,
Constructor, Prototipo, Singular
Estructural
Adaptador, Puente, Compuesto,
Decorador,
Fachada, Peso Mosca, Apoderado
De
Comportamiento
Cadena de Responsabilidad, Comando,
Iterador, Mediador, Memento,
Observador, Estado, Estrategia,
Visitante,
Método Plantilla
Clasificación
Relaciones entre patrones
10
Clasificación
Catálogo de Grand
♦ Parte de la de Gamma y la extiende con 9
categorías más:
♦ Fundamentales
♦ Particionamiento
♦ Concurrencia
♦ GRASP
♦ GUI
♦ Organización del código
♦ Optimización del código
♦ Robustez
♦ Prueba
Qué es un PD
♦ Orígenes de los PP.DD
♦ Definiciones
♦ Clasificación
Ejemplo: PD Singleton
11
Facade
1.
Nombre/Clasificación: Facade (Fachada). Estructural.
2.
Intención: Proporcionar una interfaz unificada para
un conjunto de interfaces en un subsistema,
haciéndolo más fácil de usar
3. Motivación: Reducir la complejidad y minimizar
dependencias
clases clientes
Fachada
Fachada
clases del subsistema
Facade
♦ Motivación
♦ Estructurar un entorno de programación
Linkador
Linkador
Editor
Editor
Depurador
Depurador
Clases del
Clases del
subsistema de
subsistema de
compilación
compilación
Compilador
Compilador
Compilar()
Compilar()
AnaSin
AnaSin
ASA
ASA
AnaLex
AnaLex
TabSim
TabSim
Token
Token
12
Facade
4)
5)
Aplicabilidad:
♦
Se quiera proporcionar una interfaz sencilla para un
subsistema complejo
♦
Se quiera desacoplar un subsistema de sus clientes
y de otros subsistemas, haciéndolo mas
independiente y portable
♦
Se quiera dividir los sistemas en niveles: las
fachadas serían el punto de entrada a cada nivel
Estructura
Clases
Clasesdel
del
subsistema
subsistema
Fachada
Fachada
BB
AA
CC
DD
EE
Facade
6)
Participantes
♦ Fachada: delegar las peticiones de los clientes en
los objetos del subsistema
♦ Clases del subsistema: implementar la
funcionalidad del subsistema
7)
Colaboraciones
♦ Los clientes se comunican con el subsistema a través
de la fachada, que reenvía las peticiones a los
objetos del subsistema apropiados y puede realizar
también algún trabajo de traducción
♦ Los clientes que usan la fachada no necesitan
acceder directamente a los objetos del sistema
13
Facade
8.
Ejemplo: Fachada para el acceso a BBDD vía JDBC
♦
Para consultar una base de datos es necesario
colaborar con objetos de al menos cinco clases
diferentes
1. Connection. Conexión a la BBDD
2. DatabaseMetadata. Acceso a nombres de tablas y campos
3. Statement. Crea la sentencia SQL
4. ResultSet. Recuperar la información en crudo
5. ResultSetMetaData. Accede a los campos del ResultSet
♦
Es más que evidente que se puede simplificar la
colaboración
Facade
9) Consecuencias
♦
Oculta a los clientes de la complejidad del
subsistema y lo hace más fácil de usar
♦
Favorece un acoplamiento débil entre el
subsistema y sus clientes, consiguiendo que los
cambios de las clases del sistema sean
transparentes a los clientes
♦
Facilita la división en capas y reduce
dependencias de compilación
♦
No se impide el acceso a las clases del sistema
14
Facade
10) Implementación
♦
Se puede reducir aún más el acoplamiento haciendo
que la fachada sea una clase abstracta, de forma que
se pueda escoger entre distintas implementaciones
del subsistema
♦
Java y las últimas versiones de C++ facilitan la
definición de clases privadas a un subsistema.
11) Patrones relacionados
♦
Las fachadas suelen ser Singletons
♦
Indirección (GRASP)
♦
Controlador (GRASP). Los controladores suelen
actuar como puntos de entrada (fachadas) de la capa
lógica
El Camino
♦ Qué es un Patrón de Diseño (PD)
Qué no es un PD
15
El camino
Bibliotecas
♦ Frameworks
♦ Idioms
♦ Antipatrones
♦ Refactorizaciones
Bibliotecas (Toolkits)
♦ También conocidas como librerías y Toolkits
♦ Conjunto de clases diseñado para ser reutilizados:
TADs, manejo de periféricos, gráficos, gestión de
documentos XML, … Pueden verse como el equivalente
en OO de las bibliotecas de subrutinas
♦ Influencia baja/local en el diseño de la aplicación
cliente
♦ Una cuestión clave de su diseño reside en conseguir
facilidad de uso para el máximo número de escenarios
sin complicar la interfaz ni reducir el rendimiento
♦ Bibliotecas vs PP.DD
♦ ¿Son comparables?
♦ ¿Qué contienen?
♦ ¿Cuál es su tamaño medio?
16
El Camino
♦ Bibliotecas
Frameworks
♦ Idioms
♦ Antipatrones
♦ Refactorizaciones
En el origen de los tiempos
♦ Un framework era un entorno
de desarrollo (IDE)
♦ “Componentes” habituales:
♦ Editor de textos
♦ Ayuda integrada
♦ Compilador
♦ Biblioteca de controles visuales
♦ Biblioteca de controles datos
♦ Constituían un marco de
trabajo para el desarrollo de
aplicaciones
♦ Visual Basic popularizó el
concepto en la industria
17
Qué es un framework hoy
♦ Conjunto de clases parcialmente funcional (no es
una aplicación) para un dominio de aplicación
♦ Les falta aquello que es propio de la aplicación
♦ Ejemplos: AWT, Swing, Struts, Junit, Compact
Framework, James (genuinamente andaluz), …
♦ Gran influencia en el diseño de la aplicación cliente
♦ Frameworks vs PP.DD
♦ ¿Son comparables?
♦ ¿Qué contienen?
♦ ¿Cuál es su tamaño medio?
El principio de Hollywood
18
El principio de Hollywood
Main() {
i1 = new I1();
i2 = new I2();
i1 = i2.m(i1.g());
}
Ventajas e inconvenientes
♦ Reutilización de diseño y
código
♦ Es difícil encontrar el
framework apropiado
♦ Experiencia del diseñador ♦ Es difícil usar más de un
framework al mismo
del framework
tiempo
♦ Costes de producción
♦ Son difíciles de construir y
reducidos
de aprender a usar
19
El camino
♦ Bibliotecas
♦ Frameworks
Idioms
♦ Antipatrones
♦ Refactorizaciones
Idioms
♦ Una forma característica de utilizar un LP [Fiadeiro]
♦ Patrón de bajo nivel específico de un LP. Describen
soluciones a problemas de implementación de un
determinado LP [Buschmann]
♦ gestión de memoria en C++
♦ Idiom K-R: while (*dest++=*src++)
♦ Para algunos, el Singleton no es un patrón de diseño
♦ Una colección de idioms conforman un estilo
♦ Las diferencias entre PP.DD e idioms son difusas
♦ Algunos PP.DD de hoy serán idioms mañana
♦ Iterator, singleton [Gamma]
♦ interface [Grand]
♦ Los PP.DD son casi independientes del L.P
20
El camino
♦ Bibliotecas
♦ Frameworks
♦ Idioms
Antipatrones
♦ Refactorizaciones
Antipatrones
♦ Se aprende de los errores más que de los aciertos
♦ Recetas que no deben emplearse
♦ Intentan reutilizar conocimiento de modo similar a
los PP.DD
♦ Ejemplos
♦ The blob
♦ Poltergeists
♦ Cut and paste
♦ Spaguetti code
♦ ….
♦ http://www.antipatterns.com/
21
El camino
♦ Bibliotecas
♦ Frameworks
♦ Idioms
♦ Antipatrones
Refactorizaciones
Refactorizaciones
♦
M. Fowler las ha popularizado
♦
No siempre se consigue un diseño adecuado ¿qué hacer en
tales situaciones?
♦ Nada. En ocasiones es lo más rentable
♦ Refactorizar en las sucesivas operaciones de
mantenimiento
♦
La refactorización mantiene invariable la funcionalidad
♦
Están organizadas en catálogos
♦
Muchas de ellas están muy relacionadas con PP.DD
♦ Pull-up. Muy relacionada con el PD Template Method
22
Bibliografía
♦ Se recomienda revisar los siguientes enlaces:
♦ WIKIPEDIA (design patterns, antipatterns, framework, idioms)
♦ Historia de los patrones (http://c2.com/cgi-bin/wiki?HistoryOfPatterns)
♦ Refactorización (http://c2.com/cgi-bin/wiki?HistoryOfPatterns)
Cuestiones
♦ Resolver los test de exámenes de convocatorias anteriores
23
Cuestiones
!Gracias!
♦ ¿Podemos mejorar esta lección?
♦ Mándanos un email a aruiz@us.es
♦ Visite la web de la asignatura www.lsi.us.es
24