áòøöó ù óò ð × òó óò è øöóò

Introdui
on al
Dise~
no on Patrones
Dise~
no de Sistemas Informatios
AYER: Programai
on estruturada
pero sigue en uso...
Separaion entre dise~no y odiaion
Parte de la idea de que la mayora de los errores se
introduen durante el dise~no.
Supone que los requerimientos se onoen de antemano y permaneen inalterados durante el ilo de
vida.
(Horowitz 1993) Cambios o nuevos requerimientos:
30% del oste de desarrollo
70% del oste del mantenimiento
Alternativa: Desarrollo en espiral
El dise~
no e implementaion proede de forma
inremental on gran interaion on el usuario
a n de mitigar riesgos.
Ejemplo: Rapid Strutured Prototyping
Inonveniente: Separaion del modelo de datos del
modelo del proeso.
Cambios en uno pueden oasionar efetos imprevisibles en el otro.
1
HOY: Analisis, Dise~no e Implementaion OO
Orientaion a Objetos:
An
alisis, Dise~no: UML
Implementai
on: Lenguaje OO (Java, C++, Delphi,...)
Suposiion fundamental: los objetos del dominio
son las entidades mas estables del sistema.
Un dise~
no basado en estos objetos del dominio
sera mas resistente al ambio.
Fusiona los modelos de proeso y de datos
Ventaja adiional: redue el vao entre el software y los modelos de negoio.
Tres elementos fundamentales:
An
alisis OO, analizar el dominio del problema
para onstruir un modelo del mundo real utilizando objetos
Dise~
no OO, renamiento de los modelos de analisis para rear espeiaiones adiionales que
enriqueen el modelo de analisis on detalles
proximos a la implementaion
Implementai
on, odiaion del dise~no posiblemente utilizando un lenguaje OO
2
Analisis vs Dise~no OO
Limites difusos entre analisis y dise~no OO
An
alisis: investigai
on
(desripion del problema y requerimientos)
Dise~
no: solui
on logia
(forma en que se umplen los requerimientos:
asignaion de responsabilidades, interaiones
entre objetos, et.)
Soporte
An
alisis de requerimientos: asos de uso
An
alisis: modelo oneptual
no
es
una
desripi
on
de
omponentes
software,
sino que representa el dominio del problema.
Dise~no: diagrama de lases, olaboraion, estado
Cuestiones laves en el dise~no OO:
>
omo se asignan responsabilidades a las lases?
>
omo deben interatuar los objetos?
>qu
e lases deber
an haer qu
e?
3
Dise~no e Implementai
on OO
Problema: Sigue habiendo interaiones molestas
debidas al uso inadeuado de la OO, por ejemplo,
mal empleo de la enapsulaion.
Problema: Vao existente entre analisis, dise~no e
implementaion
El programador debe tomar deisiones de dise~
no
Sobrespeiai
on
Nuevo enfoque: Dise~
no on Patrones
Nuevo ollar para un perro viejo: Abstrai
on
Idea de Christopher Alexander (arquiteto), que
aplia el onepto a la onstruion urbanstia.
(1977)
(1979)
A Pattern Language: Towns, Buildings, Constrution
The Timeless Way of Building
4
Dise~no on Patrones
Objetivo: Agrupar una oleion de soluiones de
dise~no que son validas en distintos ontextos y que
han sido apliadas on exito en el pasado.
Patron de Dise~no: Soluion a un problema de dise~no
no trivial que es efetiva y reusable.
Es efetiva en el sentido de que ya resolvi
o el
problema on anterioridad satisfatoriamente.
Es reusable si se puede apliar a un abanio de
problemas de dise~no en distintas irunstanias.
Los patrones son soluiones de sentido omun que
ya deberan formar parte del onoimiento de un
dise~nador experto.
Failitan la omuniaion entre dise~nadores al estableer un maro de referenia: terminologa, justiaion.
Failitan el aprendizaje al dise~nador inexperto
Esenia: estableer parejas problema-soluion.
5
Aportaiones de los Patrones de Dise~no
Identiar los Objetos Apropiados
Parte ompliada de la OO: Desomponer un sistema en objetos (enapsulaion, granularidad, dependenias, exibilidad, rendimiento, evoluion, reusabilidad, ...)
Determinar la Granularidad de los Objetos
Espeiar las Interfaes
Identian los elementos lave en las interfaes y
las relaiones existentes entre distintos interfaes
Failita la distinion \sublase o subtipo"
Espeiar las Implementaiones
Reutilizar
Failita la deision \herenia o omposiion" (herenia de aja blana frente a herenia de aja negra)
Gamma et al.:
Favoreer omposii
on sobre herenia
Uso de la delegai
on
Relaionar Estruturas en Tiempo de Compilaion
y en Tiempo de Ejeuion
Dise~nar para el Cambio
6
Componentes de un Patron (Culinario)
Nombre
Desripion
Clasiaion
Ejemplo motivador
Contexto/alane
Componentes involurados
Algoritmo de preparaion
Reetas relaionadas
7
Componentes de un Patron de Dise~no (GoF)
Nombre y Clasiaion
Estrutural, reai
on, omportamiento
Proposito
(Intent)
Otros nombres
(Also Known As)
Motivaion
Esenario que presenta un problema de dise~
no
Solui
on para el esenario utilizando el patr
on
Apliabilidad
Estrutura
(situaiones en las que se puede apliar)
(diagrama de lases, olaborai
on, estado)
Partiipantes
Clases y objetos partiipantes
Responsabilidades
Colaboraiones entre partiipantes
Conseuenias
(ventajas e inonvenientes de su apliai
on)
Implementaion
(t
enias y peligros en la implementai
on)
Codigo de Ejemplo
Usos onoidos
(ejemplos del patr
on en sistemas reales)
Patrones relaionados
8