Patrones

El cliente llega a un terminal PDV con mercancas y/o
servicios que comprar.

2. El cajero comienza una nueva venta.
3. El cajero introduce el identificador del artculo.
4. El sistema registra la lnea de venta y presenta la
descripcin del artculo, precio y suma parcial. El precio
se calcula a partir de un conjunto de reglas de precios.
5. El cajero repite los pasos 3-4 hasta que se indique
6. El sistema presenta el total con los impuestos
calculados.
7. El cajero le dice al cliente el total y pide que le pague.
8. El cliente paga y el sistema gestiona el pago.
9. El sistema registra la venta completa y enva la
informacin de la venta y el pago al sistema de
contabilidad externo (para la contabilidad y las
comisiones) y al sistema de inventario (para actualizar el
stock)
10. El sistema presenta el recibo.
11. El cliente se va con el recibo y las mercancas (si es el
caso).
1.
Realizado por Alberto Garay (dpto.de Informtica)
v 1.3.2
v 1.3.2
Ayudan a definir el comportamiento del sistema, descubrindonos

cules son los efectos producidos tras la accin de cada operacin
identificada por los DSS.
Se harn los que se consideren ms interesantes, pero si se
quisieran realizar de forma completa habra que hacer uno por
cada operacin de DSS, y por tanto varios por cada escenario de
cada Caso de Uso.
Se basan en hacer unas fotos imaginarias de cmo estn las
instancias de nuestras clases conceptuales antes y despus de la
accin de una operacin, y observar las diferencias
Tienen dos secciones fundamentales.
Centraremos el estudio de los cambios bajo tres aspectos

fundamentales.
Precondiciones: Asunciones previas a la ejecucin

Postcondiciones: Descripcin de los cambios observados despus de la
ejecucin. (ejemplo)
Qu instancias han sido creadas o eliminadas?
Qu atributos han cambiado de valor?
Qu asociaciones entre instancias se han creado o destruido?
Es probable que se descubran nuevas clases conceptuales en este

proceso.
v 1.3.2
Asignacin de responsabilidades: patrones GRASP y GoF
v 1.3.2
Una
vez obtenidos los artefactos que

definen los requisitos en la fase de
anlisis (CdU, MD, DSS y Contratos),
nos centraremos en encontrar las
clases SW y definir sus mtodos
(DCD)
Asimismo investigaremos cmo
colaboran entre s los objetos que se
crean a partir de ellas (DI)
v 1.3.2
La
idea clave es sentirse como el gran

directivo de una empresa, que tiene que
decidir cmo repartir las tareas entre sus
empleados para conseguir unos objetivos.
Al igual que en este smil, se han de
cumplir reglas de sentido comn como no
asignar demasiado trabajo a una persona,
saber delegar (cohesin), pocos
interlocutores entre equipos (bajo
acoplamiento)
v 1.3.2
En
la fase anterior (de anlisis), se

supone que se han identificado las
responsabilidades que se deben
desarrollar.
En esta fase de diseo, el objetivo
fundamental es asignar estas
responsabilidades a ciertas clases y
objetos.
v 1.3.2
Cuando
se habla de responsabilidad, nos

referimos a la capacidad de un objeto para:
Conocer (datos privados, objetos relacionados,
datos derivables o calculables)

Hacer (crear un objeto, hacer un clculo, iniciar
una accin en otro objeto, controlar y coordinar
actividades de otros objetos)
Cada
responsabilidad se materializar en
un mtodo de una determinada clase.
Asignar una responsabilidad consiste en
decidir a qu clase agregar dicho mtodo.
v 1.3.2
10
Ejemplo:
Se decide, al objeto Venta, otorgarle la

responsabilidad de crear objetos de tipo Pago
v 1.3.2
11
Los
patrones son heursticas que nos ayudan

a asignar responsabilidades a los objetos.
Son tcnicas complejas de diseo que se
resumen en una o unas pocas palabras.
Describen una solucin ptima o habitual
para un problema conocido.
Se basan en la experiencia de los
desarrolladores.
Son problemas viejos, cuyas soluciones,
basadas en la experiencia de los analistas y
los programadores, sirven para solucionar
de forma sencilla otros nuevos que se le
asemejan.
v 1.3.2
12
Los
patrones nos proponen buenas

costumbres consejos (best practices),
a la hora de hacer un diseo, cuya
eficacia viene avalada por la experiencia
demostrada a travs de los aos.
Al igual que los patrones, existen
tambin los llamados antipatrones que
definen aquellos diseos que se han de
tener muy en cuenta como ejemplos a no
seguir.
v 1.3.2
13
Problema
(P): planteamiento del

problema que se pretende solucionar.
Solucin (S): solucin ptima para el
problema antes planteado.
Nombre: ttulo que resume al par
problema-solucin antes descrito.
en este nombre radica el xito de los
patrones, ya que con una sola palabra se

pueden transmitir de forma precisa y
consensuada (para la comunidad de
programadores y analistas) tcnicas y
conceptos complejos.
v 1.3.2
14
Principios bsicos de diseo
v 1.3.2
15
Son
los patrones bsicos que

cualquier analista/diseador debe
aprender y dominar.
Son las siglas de General
Responsibility Assignment Software
Patterns.
Tambin denota un juego de
palabras, ya que grasp significa
agarrar con firmeza, aprehender.
v 1.3.2
16
5 patrones GRASP bsicos

Experto
Creador
Alta cohesin
Bajo acoplamiento
Controlador
Otros patrones GRASP:
Polimorfismo
Indireccin
Fabricacin pura
Variaciones protegidas
v 1.3.2
17
P:
Cul es el principio ms bsico

para asignar responsabilidades?
S: Asignarla a aquel objeto que
tenga ms informacin (o toda,
preferiblemente) a su alcance, para
poder ejercitar la responsabilidad
que se est intentando asignar.
v 1.3.2
18
Ej.
Quin es el responsable de conocer

el total de una venta?
Buscaremos en el DCD, y si falta informacin,
podramos utilizar el MD para inspirarnos
v 1.3.2
19
Nos percatamos que la venta es la experta y le asignamos la

responsabilidad global.
No tiene toda la informacin, pero puede pedirla de forma
ms directa que otros (delegar)
Aparecen otras subresponsabilidades que tambin debemos
asignar.
1.1: p:= getPrecio :( Especificacin

)
Del Producto
Especificacin
Del Producto
descripcin
precio
artID
getPrecio ( )
v 1.3.2
20
P:
Quin debera ser el responsable

de crear un objeto?
S: Aquel que contenga, agregue o
colabore ms estrechamente con
dicho objeto.
v 1.3.2
21
Ej.
Quin debera ser el responsable

de crear lneas de venta?
R: La venta, porque es la que las
colecciona.
v 1.3.2
22
P: Cmo soportar bajas dependencias, bajo

impacto del cambio e incremento de la
reutilizacin?
S: Asignar responsabilidades de manera que
el acoplamiento permanezca bajo.
Acoplamiento: Medida de la fuerza con que un
elemento est conectado a otros.

Se dice que A y B se acoplan cuando.
A
A
A
A
A
tiene un atributo B
invoca servicios de B
referencia a instancias de la clase B
hereda de B
implementa B
El alto acoplamiento puede derivar en:

Cambios en clases derivadas provocan cambios locales
Difciles de entender de manera aislada.
Difciles de reutilizar, pues requiere la presencia de las clases con
que se relaciona.
v 1.3.2
23
Ej. quin es el responsable de crear un Pago y

asociarlo con una Venta?
El registro registra los pagos en el mundo real.
Si lo hacemos as sube el acoplamiento, luego
decidimos que sea la propia Venta quien lo cree y

agregue.
En la mayora de los casos complementa a otros
patrones, como el Experto, el Creador o el Alta
cohesin, es decir, la aplicacin de estos patrones
suele llevar a diseos con bajo acoplamiento.
No siempre es deseable el bajo acoplamiento:

ej. Servicios tcnicos estables, frameworks de
persistencia, logging, en general servicios transversales

o aspectuales.
v 1.3.2
24
P:
Cmo mantener la complejidad de una

clase manejable?
S: Asignar responsabilidades de forma
que la cohesin permanezca alta.
Cohesin: Es una medida de la fuerza con la
que se relacionan las responsabilidades de un

objeto entre s.
Es deseable objetos que no hagan demasiadas tareas
y que adems, stas tengan que ver entre s.
La baja cohesin provoca clases difciles de entender,
mantener y reutilizar. Adems son clases delicadas y
afectadas por los cambios.
Indican la incapacidad de delegar (objetos Blob o
superobjetos)
v 1.3.2
25
Ej. Anterior.
Si asignamos la operacin al registro, puede tener sentido en
trminos de cohesin, pero si por cada operacin que le llega,

l hace todo el trabajo, empezar a descohesionarse y se
convertir en un objeto saturado que hace demasiado trabajo
No se puede considerar la cohesin de forma

aislada, sino en conjuncin con otros principios
como bajo acoplamiento y experto en
informacin
Ejemplos de excepciones en las que puede ser
deseable la baja cohesin.
Objetos servidores distribuidos. Para evitar el coste
(en rendimiento de una red) de crear nuevas

sesiones, habr tan slo un objeto remoto de grano
grueso muy poco cohesionado que recibir todo tipo
de peticiones.
v 1.3.2
26
P:
Quin debe ser el responsable de

recibir en primera instancia y gestionar
un evento del sistema?
S: Una clase que represente a todo el
sistema, o a cada Caso de Uso.
El objeto u objetos controladores:
Recibirn los mensajes identificados en los DSS.
Se encargarn de delegar cada una de esas
tareas en las clases adecuadas.
No deben pertenecer a la UI, ya que excedera su
propia lgica y objetivo que es interactuar con el
usuario e intercambiar informacin con el
sistema.
v 1.3.2
27
Candidatos:
-Registro: Representa
a todo el sistema PDV
-ProcesarVentaManej
ador:
Clase ficticia que nos
inventamos para
recoger todas
las operaciones
asociadas al
Caso de Uso Procesar
Venta
como por ejemplo
finalizarVenta()
v 1.3.2
28
S (mejor)
NO (peor)
v 1.3.2
29
Cules son los distintos aspectos de las

responsabilidades de un controlador?
Recepcionista: punto de entrada para cualquier
operacin proveniente de la interfaz de usuario.

Supercontenedor: conocer (tener visibilidad) sobre todos
los objetos del sistema a los que tiene que delegar cada
una de las responsabilidades requeridas, o al menos a
objetos que conozcan a stos de forma indirecta.
Sesin: recuerdan (conservan una referencia) a ciertos
objetos (precondiciones de contratos) entre una
operacin y otra.
Controladores descohesionados:
Si es necesario, se puede optar por repartir sus
responsabilidades en otros controladores: uno por cada

caso de uso, escenario y/o aspecto. En este caso podra
ser interesante tener un solo controlador de entrada que
delegue en sus ayudantes
v 1.3.2
30
De
dnde salen las responsabilidades

Alguien debe crear una lnea de vent
que se han de asignar?
De los
contratos:
Alguien debe calcular el total de la ve
De los
Casos
de Uso:
v 1.3.2
31
Fabricacin pura:
Utilizar clases que no representen ningn objeto ni ente
real (del negocio que se est definiendo), con el fin de
mejorar la cohesin y el acoplamiento.
Indireccin:
implementar un intermediario entre dos componentes

para mejorar el acoplamiento y la cohesin
Polimorfismo:
utilizar polimorfismo para asignacin de responsabilidades

que dependan del tipo, mejorando as el acoplamiento y
la reutilizacin de cdigo diseando objetos pluggables
(enchufables)
Variaciones protegidas:
Envolver los puntos calientes o componentes limtrofes

(que conectan con otros sistemas) en interfaces que
polimrficamente soporten varias implementaciones.
v 1.3.2
32
P: Quin debe ejercer una responsabilidad

cuando patrones como el experto, u otras
soluciones, conducen a malos diseos por baja
cohesin, alto acoplamiento o poca
reutilizabilidad?
R: Asignar un conjunto de responsabilidades a
una clase altamente cohesiva aunque no
represente ningn concepto real.
Ventajas e inconvenientes.
V: Provoca diseos ms cohesionados.
I: Las clases que se suelen crear son alrededor de un
algoritmo o funcionalidad y no de un concepto al que se le
asigna funcionalidad.
I: En un caso degenerado haremos programacin clsica
agrupando funcionalidades como hacamos con los mdulos.
Evitar esta situacin teniendo presente el patrn experto en
la mayora de los casos, y creando las clases a partir del MD
v 1.3.2
33
Almacenamiento
persistente para la clase

Venta. Experto sugiere que sea ella.
Las operaciones asociadas sern muchas y no
relacionada con la Venta => pierde cohesin.

Venta se acoplar a interfaces como JDBC, que
no forman parte de mi negocio ni mi dominio.
El cdigo de persistencia ser muy similar
(reutilizable) para todas las dems clases.
Solucin: crear una clase Persistente de la que
hereden todas las clases que quieran persistir.
v 1.3.2
34
P:Cmo
asignar responsabilidades
para que dos objetos no se acoplen
directamente? Cmo desacoplar
objetos para disminuir el
acoplamiento y favorecer la
reutilizacin?
S: Asociar la responsabilidad a un
objeto mediador que lo desacople
del servicio en cuestin
v 1.3.2
35
Evitar
que la venta se acople directamente

con las APIs de clculo de impuestos.
Ponemos otra API ms amable por
delante que simplifique la operativa.
v 1.3.2
36
El
almacenamiento persistente
puede ser un ejemplo de indireccin
tambin.
Normalmente las indirecciones son
fabricaciones puras que nos
permiten reducir el acoplamiento
entre dos capas
El controlador o una fachada-Facade
son ejemplos de ello, tambin.

v 1.3.2
37
P: Cmo manejar las alternativas
basadas en el tipo? Cmo crear

componentes de SW conectables* ?
S: Cuando el comportamiento vara
segn el tipo (clase) asignar
responsabilidades utilizando operaciones
polimrficas para los tipos en los que
vara dicho comportamiento.
* Posibilidad de cambiar un componente en el servidor sin

que afecte al Realizado
cliente
por Alberto Garay (dpto.de Informtica)
v 1.3.2
38
v 1.3.2
39
P:
Cmo disear objetos, subsistemas

y sistemas de manera que las
variaciones o inestabilidades en estos
elementos no tengan un impacto no
deseable en otros elementos cliente.
S: Identificar los puntos de
variaciones previstas o inestabilidad y
asignar responsabilidades para crear
una interfaz estable alrededor de ellos.
v 1.3.2
40
Patrones creacionales, arquitecturales y de comportamiento
v 1.3.2
41
La pandilla de los cuatro (Gang of Four)

Son los cuatro autores que escribieron Design
patterns, un libro muy popular, que ilustraba

la naturaleza de 23 patrones.
A estos patrones se les conoce como

patrones GoF en honor a sus autores.
Hay muchos ms patrones, pero los GoF
son principios slidos, bsicos y
ampliamente utilizados por toda la
comunidad de expertos.
v 1.3.2
42
Creacionales Definen las distintas casusticas

para asignar responsabilidades de creacin a un
objeto.
Abstract factory, Builder, Factory, Prototype, Singleton.
Estructurales Definen cmo se deben conectar

unos objetos con otros para que los cambios en un
componente afecten lo menos posible al resto.
Adapter, Bridge, Composite, Decorator, Facade, Flyweight,
Proxy
De comportamiento: Formas de encapsular

procesos (por ejemplo un iterador, es un objeto que encapsula la
accin de moverse por una coleccin ).
ChainOfResponsibility, Command, Interpreter, Iterator, Mediator,
Memento, Observer, State, Strategy, TemplateMethod, Visitor
v 1.3.2
43
P: Cmo resolver interfaces incompatibles o

proporcionar una interfaz estable para
componentes parecidos, pero con diferentes
interfaces?
S: Convierta la interfaz original de un
componente en otra interfaz mediante un
objeto adaptador intermedio.
En realidad este patrn concreta una solucin
para un problema genrico de adaptacin de un

subsistema a otro, utilizando principios bsicos
de patrones GRASP como poner una indireccin
a una interfaz inestable, para conseguir mediante
polimorfismo, variaciones protegidas.
v 1.3.2
44
EnchufeEuropeo
public Electricite enchufar
( ) {}
Bombilla
void
void
suministrar(Electricidad
suministrar(Electricidad
e)
e)
public Electricity plugIN( )

{}
utiliza
AdaptadorEuropeo
EnchufeEuropeo ee=new
EnchufeEuropeo()
public
Electricidad
enchufar( ) {
Electricite e=ee.enchufar( )
return (this.converte(e));
}
private Electricidad
converte(Electricite
e) {}
EnchufeAmerican
o
utiliza
implementaimplementa
AdaptadorAmericano
<<interface>>
<<interface>>
IAdaptadorIndustrial
public Electricidad
enchufar( ) ;
Lmpara
EnchufeAmericano ea=new
EnchufeAmericano( )
public Electricidad enchufar( ) {
Electricity e=ea.plugIN( )
return (this.convert(e));
}
private Electricidad convert
(Electricity e)
EnchufeAmericano
ei
=
new
EnchufeEuropeo
ei=
EnchufeInfustrial
ei=
IAdaptadorIndustr
ei;
EnchufeAmericano
ei new
=new
new ei;
EnchufeEuropeo
ei=
new
EnchufeInfustrial
ei=
new
EnchufeIndustrial
EnchufeAmericano(
)
EnchufeEuropeo(
)
EnchufeIndustrial(
)
ial
ei
EnchufeEuropeo(
) )
EnchufeIndustrial(
ei;
{}
ei;
Bombilla
Bombilla b=new
b=new
Bombilla();
Bombilla()
public void
encender()
{Electricidad e;
e=ei.enchufar();
EnchufeIndustri
al
v 1.3.2public Electricidad45
v 1.3.2
46
v 1.3.2
47
P:
Quin debe ser el responsable de

creacin de un objeto cuando existen
consideraciones especiales, como
una lgica de creacin compleja, o el
deseo de separar las
responsabilidades de la creacin,
para favorecer la cohesin, etc.
S: Crear un objeto de fabricacin
pura denominado Factora que
maneje la creacin.
v 1.3.2
48
Quin debera crear el AdaptadorDeImpuestos.
Podra sugerirnos el creador, que la Venta (que lo utiliza), lo
haga, pero, su relacin con l no es tan estrecha

(estructural, agregacin de atributo). Adems podra haber
otros objetos que lo utilizaran.
Por otra parte, no le incumbe a la venta asuntos
arquitecturales como qu componente de SW conectar en
un caso u otro.
Crearemos una factora que tendr la responsabilidad

de crear y mantener una referencia a este adaptador,
u otros que necesitemos.
Quien necesite utilizarlo, slo debe tener visibilidad sobre
la factora y llamar a un accesor getAdaptador.
Cada adaptador miembro de la factora se definir con

el tipo de la Interfaz genrica, no el de cada
adaptador, de esta manera, en funcin del adaptador
real que haya en nuestro sistema, polimrficamente,
se utilizarn las funciones de uno o de otro (comunes
en su interfaz)
v 1.3.2
49
v 1.3.2
50
P: Cmo asegurarse de que de una clase tan

slo se instanciar un objeto (un singleton)
? Cmo asegurarse de que dicho objeto es
visible globalmente por el resto?
S: Defina un mtodo esttico en la clase que
devuelva el singleton.
Adicionalmente, hacer el constructor por defecto
del singleton privado.

La referencia al singleton estar almacenada en un
atributo esttico de la clase, ya que no se puede
acceder a atributos no-estticos desde ambientes
estticos
v 1.3.2
51
En
el caso NuevaEra, cmo podemos acceder a

la factora, si no queremos acoplarla
artificialmente a las clases que la utilizan como
la Venta.
Haremos la factora un singleton accesible
globalmente.
Alguien que quiera acceder al mtodo de un
adaptador (por ejemplo una Venta para calcular
los impuestos de la misma) podra hacerlo
desde cualquier punto del cdigo as.
FactoriaDeServicios.getInstancia().getAdaptadorCalculadorDeImpuestos().getImpu
estos(this);
v 1.3.2
52
Instanciacin perezosa o impaciente?

Perezosa por evitar copar recursos caros si no se
utiliza el Singleton, y sobre todo por si hay lgica

compleja al realizar la creacin.
Por qu no hacer todos los mtodos del Singleton

estticos?
Porque no permiten herencia ni por tanto polimorfismo
Porque protocolos como RMI no los soportan
Porque podran no ser un singleton en otra aplicacin
(reutilizacin)
Aumenta el Singleton el acoplamiento?

No, aumenta slo su potencialidad de acoplamiento.
Depende de nosotros decidir quin habla con el

Singleton para decidir quin se acopla con l?
v 1.3.2
53
v 1.3.2
54
P:
Cmo tener un acceso poco

acoplado a un subsistema, resistente
a los cambios, y altamente
reutilizable?
S: Definir un objeto, que establezca
una interfaz cohesiva y nica para
acceder a dicho subsistema.
v 1.3.2
55
P:
Cmo notificar desde un objeto

emisor a un conjunto de objetos
receptores el acontecimiento de un
evento manteniendo el acoplamiento
bajo entre el emisor y los receptores?
S: Definir una interfaz Listener que
implementen los suscriptores, de manera
que el emisor mantenga (en trminos de
dicha interfaz) una lista de los
suscriptores interesados en un evento, y
les avise cuando ste acontezca,
llamando a un mtodo de dicha interfaz.
v 1.3.2
56
v 1.3.2
57
Pasos a dar:
1.
2.
3.
4.
5.
Se define una interfaz PropertyListener, con

operacin onPropertyEvent
Se define la ventana (o clase) que implementa
la interfaz y hacemos que implemente
PropertyListener
Cuando se crea la ventana, se le pasa la Venta
La ventana se suscribe mediante
addPropertyListener a la ocurrencia del suceso
Property, mediante addPropertyListener()
Cuando ocurre el evento del tipo Property en
la Venta (p.ej. Venta finalizada), la Venta itera
entre sus suscriptores y les enva un mensaje
onPropertyEvent a cada uno
v 1.3.2
58
P:
Cmo disear diversos algoritmos /

polticas que estn relacionadas? Cmo
hacer que estos algoritmos puedan
cambiar fcilmente y con un mnimo
impacto en el cdigo que los utiliza?
S: Definir cada algoritmo / poltica en una
clase independiente que implementen
una interfaz comn, y
conectar/desconectar dichas estrategias
segn se requiera.
v 1.3.2
59
El
objeto estrategia se conecta a un

objeto de contexto (aqul a quien se
le ha de aplicar el algoritmo)
P.ej. Cuando se enva getTotal() a una
Venta, delega parte de su trabajo en la

estrategia, para calcular su precio.
Normalmente
el mtodo del objeto de

contexto y el de la estrategia se
llaman igual.
Normalmente el objeto de contexto le
manda a la estrategia una referencia a
this para futuras colaboraciones
v 1.3.2
60
Sirve para extraer una funcionalidad o algoritmo

de una clase, ya que su implementacin
depende de circunstancias que exceden la lgica
de la clase.
Para ello el cdigo se pone en una clase aparte y
la clase inicial guarda un vnculo permanente a
su algoritmo extrado, pero siempre referenciado
en trminos de una Interfaz (para poder
cambiarlo en el futuro transparentemente)
Cuando llamemos al algoritmo, debemos pasarle
una referencia a nosotros mismos ya que el
algoritmo extrado (segn el experto)
presumiblemente necesitaba informacin de la
clase de la que fue extrado para hacer sus
clculos.
v 1.3.2
61
v 1.3.2
62
v 1.3.2
63
Quin debera conectar /desconectar las

estrategias?
Una solucin adecuada podra ser una factora
singleton de estrategias a la que se pidiera la
estrategia adecuada.
sta conectar / desconectar cada estrategia en
funcin de un criterio (propiedad del sistema leda
de un fichero, estado de algn otro objeto, etc.)
Normalmente la estrategia tendr visibilidad sobre
el objeto de cuya clase se ha extrado el
algoritmo el que debiera actuar (caso de
estrategia de descuento sobre Venta, o
EstrategiaOrdenacion sobre vector)
v 1.3.2
64
La
estrategia se suele crear en una

factora singleton, distinta a las Factoras
de servicios vistas anteriormente (para no
perder cohesin)
El objeto de contexto ha de poder acceder
a la factora adecuada, bien porque tenga
visibilidad de atributo, o en el caso de
factora Singleton, por su naturaleza
visible global.
Ser la factora la que decida en funcin
de un criterio (p.ej. una propiedad del
sistema) que estrategia utilizar en cada
momento.
v 1.3.2
65
v 1.3.2
66
P:
Cmo tratar un grupo o una

estructura compuesta del mismo modo
que a un objeto no compuesto?
S: Todas las clases de objetos han de
implementar un interfaz comn, as
como el que representa a un conjunto
de los dems.
El Composite aparte de implementar la
Interfaz agregar a un conjunto de objetos

del tipo de la interfaz
v 1.3.2
67
Uno
de los problemas que resuelve es:

si se pueden aplicar varias estrategias,
cmo se resuelve el conflicto?
Se crea una estrategia compuesta que
decide cul utilizar en funcin de un
criterio o poltica (p.ej. En el caso
nuevaEra, se aplicar el descuento
mejor para el cliente, de todos los que
se le podran aplicar)
v 1.3.2
68
v 1.3.2
69
v 1.3.2
70
Cundo se crean stas estrategias?

Cundo se aaden nuevas
estrategias a un Composite?
Tres posibles puntos en el caso nuevaEra

1. Descuento actual a nivel de tienda. Se aade
cuando se crea la Venta.
2. Descuento por el tipo de cliente, se aade
cuando se informa al PDV del tipo de cliente.
3. Descuento segn el tipo de producto, se
aade cuando se introduce el producto en la
Venta
v 1.3.2
71
Ej. nuevaEra (al crear la Venta aadimos una estrategia inicial al

Composite con el porcentaje actual de descuento de la tienda (lo
leer la factora p.ej. de una BD o de algn sitio externo que se
pueda cambiar fcilmente)
v 1.3.2
72
Si el descuento depende del tipo de cliente

segn el escenario descrito en el CdU
correspondiente, se puede proceder como
sigue
v 1.3.2
73
v 1.3.2
74
v 1.3.2
75
Conceptos genricos
v 1.3.2
76
Diseo
(14).
Programacin (25).
Programacin orientada a objeto (13).
Gestin (21).
Gestin de proyectos (3).
Metodolgicos (9).
Gestin de configuracin (2).
Organizacionales (16).
Otros (78).
v 1.3.2
77
Base de datos como comunicador de procesos(database

as an IPC): Usar unabase de datospara comunicar
procesos en uno o varios ordenadores, cuando la
comunicacin entre procesosdirecta es ms adecuada.
Blob: VaseObjeto todopoderoso.
BOMQ(Batch Over MQ): Abuso en el empleo de integracin
basada en mensajes en tiempo real para transferencias
espordicas de gran tamao en segundo plano.
Clase Gorda: Dotar a unaclasecon demasiados atributos
y/omtodos, hacindola responsable de la mayora de la
lgica de negocio.
Botn mgico(magic pushbutton): Tender, desarrollando
interfaces, a programar la lgica de negocio en los
mtodos de interaccin, implementando los resultados de
las acciones del usuario en trminos no suficientemente
abstractos.
Carrera de obstculos(race hazard): Incapacidad de prever
las consecuencias de diferentes sucesiones de eventos.
v 1.3.2
78
Entrada chapuza(input kludge): No especificar e implementar

el manejo deentradasinvlidas.
Fbrica de combustible (gas factory): Disear de manera
innecesariamente compleja.
Gran bola de lodo(big ball of mud): Construir un sistema sin
estructura definida.
Interfaz inflada(interface bloat): Pretender que una interfaz sea
tan potente que resulta extremadamente difcil de implementar.
Inversin de abstraccin(abstraction inversion): No exponer las
funcionalidades implementadas que los usuarios necesitan,
forzando a que se reimplementen a ms alto nivel.
Punto de vista ambiguo (ambiguous viewpoint): Presentar un
modelo sin concretar ciertos aspectos, postergando as
decisiones conflictivas.
Re-dependencia(re-coupling): Introducir dependencias
innecesarias entre objetos.
Sistema de caeras de calefaccin (stovepipe system):
Construir un sistema difcilmente mantenible, ensamblando
componentes poco relacionados.
v 1.3.2
79
Nomenclatura heroica(heroic naming): Identificar los

miembros de un programa (interfaces, clases, propiedades,
mtodos...) con nombres que provocan que el conjunto
aparente estandarizacin con la ingeniera del software
pero que en realidad oculta una implementacin anrquica.
Accin a distancia(action at a distance): Provocar la
interaccin no prevista de componentes muy distantes de
un sistema.
Acumular y arrancar(accumulate and fire): Establecer una
coleccin de variables globales para ser usadas por un
conjunto desubrutinas.
Ancla del barco(boat anchor): Retener partes del sistema
que ya no tienen utilidad.
Bucle activo(busy spin): Utilizarespera activacuando
existen alternativas.
Cdigo duro(hard code): Hacer supuestos sobre el entorno
del sistema en demasiados lugares de laimplementacin.
v 1.3.2
80
Complejidad no indispensable (accidental complexity): Dotar

de complejidad innecesaria a una solucin.
Cdigo espagueti(spaghetti code): Construir sistemas cuya
estructura es difcilmente comprensible, especialmente
debido a la escasa utilizacin deestructuras de programacin
.
Cdigo ravioli(ravioli code): Construir sistemas con multitud
de objetos muy dbilmente conectados.
Comprobacin de tipos en lugar de interfaz (checking type
instead of interface): Comprobar que un objeto es de un tipo
concreto cuando lo nico que se necesita es verificar si
cumple un contrato determinado.
Confianza ciega(blind faith): Descuidar la comprobacin de
los resultados que produce una subrutina, o bien de la
efectividad de un parche o solucin a un problema.
Doble comprobacin de bloqueo (double-checked locking):
Comprobar, antes de modificar un objeto, si es necesario
hacer esa modificacin, pero sin bloquear para comprobarlo,
de manera que dicha comprobacin puede fallar.
v 1.3.2
81
Fallo de cach(caching failure): Olvidar restablecer una marca de

error cuando ste ya ha sido tratado.
Lava seca(lava flow): Cdigo muerto e informacin de diseo
olvidada permanecen congelados en un diseo cambiante. Esto es
anlogo a un flujo de lava en el que se van endureciendo pedazos
de roca. La solucin incluye un proceso de gestin de la
configuracin que elimina el cdigo muerto y permite evolucionar
o rehacer el diseo para acrecentar la calidad.
Lgica super-booleana(superboolean logic): Emplear
comparaciones o abstracciones de lalgicabooleanainnecesarias.
Manejo de excepciones(exception handling): Emplear el
mecanismo de manejo de excepciones dellenguajepara
implementar la lgica general del programa.
Manejo de excepciones intil (useless exception handling):
Introducir condiciones para evitar que se produzcan excepciones
entiempo de ejecucin, pero lanzar manualmente una excepcin
si dicha condicin falla.
Momento del cdigo(code momentum): Establecer demasiadas
restricciones sobre una parte del sistema debido a la asuncin de
muchas de sus propiedades desde otros lugares del propio
sistema.
v 1.3.2
82
Nmeros mgicos(magic numbers): Incluir en los algoritmos

nmeros concretos sin explicacin aparente.
Ocultacin de errores(error hiding): Capturar un error antes
de que se muestre al usuario, y reemplazarlo por un mensaje
sin importancia o ningn mensaje en absoluto.
Packratting: Consumir memoria en exceso debido a no liberar
objetos reservados dinmicamente una vez ya han dejado de
ser necesarios.
Programacin por excepcin(coding by exception): Aadir
trozos decdigopara tratar casos especiales a medida que se
identifican.
Secuencia de bucle por casos(Loop-switch sequence):
Programar un conjunto de pasos secuenciales usando un bucle
en combinacin con unaestructura de control por casos.
Cadenas mgicas(magic strings): Incluir
cadenas de caracteresdeterminadas en el cdigo fuente para
hacer comparaciones, como tipos de eventos, etc.
Bala de plata(silver bullet): Asumir que nuestra solucin
tcnica favorita puede resolver un problema mucho mayor.
v 1.3.2
83
Acoplamiento secuencial(sequential coupling): Construir

una clase que necesita que sus mtodos se invoquen en
un orden determinado.
BaseBean: Heredar funcionalidad de unaclase utilidaden
lugar de delegar en ella.
Fallo de clase vaca(empty subclass failure): Crear una
clase que no supera eltest de la subclase vaca, es decir,
que se comporta de manera diferente cuando se invoca
desde una subclase que no aade modificacin alguna.
Llamar a super(callsuper): Obligar a las subclases a
llamar a un mtodo de la superclase que ha sido
sobrescrito.
Modelo de dominio anmico(anemic domain model):
Usar unmodelo del dominiosin ningunalgica de
negocio. Esto no es un enfoque orientado a objetos
porque cada objeto debera tener tanto propiedades
como comportamiento asociado.
v 1.3.2
84
Objeto orga: (orgy object) Objeto con acceso libre a sus

atributos.
Objeto sumidero(object cesspool): Reutilizar objetos no
adecuados realmente para el fin que se persigue.
Objeto todopoderoso (god object): Concentrar demasiada
funcionalidad en una nica parte del diseo (clase).
Poltergeist: Emplear objetos cuyo nico propsito es pasar la
informacin a terceros objetos.
Problema del crculo-elipse(circle-ellipse problem):
Crearvariablesdetipopensando en los valores de posibles
subtipos.
Problema del yoy(yo-yo problem): Construir estructuras
(por ejemplo, de herencia) que son difciles de comprender
debido a su excesiva fragmentacin.
Singletonitis: Abuso de la utilizacin del patrnsingleton.
YAFL(yet another layer,y otra capa ms): Aadir capas
innecesarias a un programa, biblioteca o framework. Esta
tendencia se extendi bastante despus de que se publicase
el primer libro sobre patrones.
v 1.3.2
85
Productividad a toda costa : La empresa busca la productividad a costa de la calidad

del software y de la calidad de vida de sus empleados, intenta homogeneizar los
puestos de trabajo quitando en la medida de lo posible los permisos a los
programadores para que no daen los sistemas operativos, monitoriza a los equipos
de trabajo y acta cortando la visibilidad de ciertas pginas o las reuniones de
programadores, al final se consigue que se vaya la gente de la empresa cuando la
situacin es insostenible, esto suele ocurrir en ciclos de uno o dos aos.
Responsable ausente(absentee manager): Situacin en la que el principal
responsable o coordinador se ausenta o permanece en paradero desconocido o no
localizable durante importantes perodos de tiempo.
Todo lo que tienes es un martillo (all you have is a hammer): Gestin gris y plana,
incapaz de tratar a los subordinados de manera personalizada y acorde con sus
necesidades particulares.
Negociador de jaula de acero (cage match negotiator): Se aplica cuando un
coordinador, gestor o responsable aplica una filosofa de "xito a cualquier precio".
Dos caras(doppelganger): Coordinador o compaero que en un determinado
momento puede ser agradable y de trato fcil, pero igualmente puede volverse
irracional y despiadado de modo inesperado.
Rodeos improductivos (fruitless hoops): Gestor o coordinador que solicita grandes
cantidades de datos (en ocasiones sin relevancia alguna) antes de tomar una
decisin.
v 1.3.2
86
Niito de oro(golden child): Situacin en la que ciertas

responsabilidades, oportunidades, reconocimientos o recompensas
van a parar a un determinado miembro del equipo como
consecuencia de una relacin personal o en clara contradiccin con su
rendimiento real.
Pollo sin cabeza(headless chicken): Se aplica al gestor, coordinador o
responsable que vive en una permanente situacin de pnico y
medidas desesperadas.
Lder pero no gestor(leader not manager): Un buen lder no tiene por
qu ser necesariamente un buen gestor, coordinador o responsable.
Gestin clonada(managerial cloning): Situacin en la que los
coordinadores o gestores son contratados e instruidos para actuar y
trabajar todos del mismo modo, a imagen y semejanza de sus propios
jefes.
Gestor pero no lder(manager not leader): Un coordinador brillante en
sus deberes administrativos y de gestin, pero que carece de
habilidades de liderazgo.
Abuso de la mtrica(metric abuse): Utilizacin manipuladora o
incompetente de las medidas y las mtricas.
Sr. Amigo de todos(Mr. Nice Guy): Se aplica al gestor que pretende
convertirse en amigo de todos.
v 1.3.2
87
Hroe del proletariado(proletariat hero): El "empleado para todo" que siempre es puesto
como ejemplo ante sus compaeros, pero que realmente es la excusa perfecta para
demandas crecientes y constantes incrementos de expectativas.
Estrellas nacientes(rising upstart): Se aplica a quienes, teniendo potencial, no son
capaces de respetar la progresin profesional establecida, y pretenden sortear los plazos y
requisitos de aprendizaje y madurez.
Ejecutivo sin carcter(spineless executive): Gestor, coordinador o responsable que no
tiene el coraje de enfrentarse a las situaciones, asumir las responsabilidades de los
errores, o dar la cara por sus subordinados.
Caballero de tres cabezas(three-headed knight): Gestor indeciso, poco firme, dubitativo.
Arma definitiva(ultimate weapon): Individuos altamente competentes en los que la
organizacin o sus compaeros confan tanto que se convierten en el canal por el que
todo pasa.
Recin llegado(warm body): Trabajador que apenas cubre las expectativas mnimas y por
tanto circula de proyecto en proyecto o de equipo en equipo.
Arquitecto a obrero(super builder): Creencia por la que se asigna a un buen diseador de
software al desarrollo de cdigo pensando en que tardara mucho menos en teclearlo.
Cantamaanas(singermorning): Gerente que ante el desconocimiento de las aplicaciones
que lleva, y el estado de parcheo imposible de mantener en el que se encuentran, paga
los enfados de el cliente con los programadores que heredaron la aplicacin. Tambin se
refiere al compaero incompetente que "succiona" a los dems compaeros.
v 1.3.2
88
Humo
y espejos(smoke and mirrors):

Mostrar cmo ser una funcionalidad
antes de que est implementada.
Mala gestin(bad management):
Gestionar un proyecto sin tener
suficientes conocimientos sobre la
materia.
Software inflado(software bloat):
Permitir que las sucesivas versiones de
un sistema exijan cada vez ms recursos.
v 1.3.2
89
Desarrollo conducido por quien prueba(tester driven development): Permitir que un

proyecto software avance a base de extraer sus nuevos requisitos de los informes de
errores.
Desfactorizacin(de-factoring): Eliminar funcionalidad y reemplazarla con
documentacin.
Factor de improbabilidad(improbability factor): Asumir que es improbable que un
error conocido cause verdaderos problemas.
Martillo de oro(golden hammer): Asumir que nuestra solucin favorita es
universalmente aplicable, haciendo bueno el refrna un martillo, todo son clavos.
Optimizacin prematura(premature optimization): Realizar optimizaciones sin
disponer de la informacin suficiente para hacerlo con garantas, sacrificando
decisiones de diseo.
Programacin de copiar y pegar(copy and paste programming): Programar copiando
y modificando cdigo existente en lugar de crear soluciones genricas.
Programacin por permutacin(programming by permutation): Tratar de aproximarse
a una solucin modificando el cdigo una y otra vez para ver si acaba por funcionar.
Reinventar la rueda(reinventing the wheel): Enfrentarse a las situaciones buscando
soluciones desde cero, sin tener en cuenta otras que puedan existir ya para afrontar
los mismos problemas.
Reinventar la rueda cuadrada(reinventing the square wheel): Crear una solucin
pobre cuando ya existe una buena.
v 1.3.2
90
Conflicto de extensiones(extension conflict):

Problemas con diferentes extensiones que
tratan de gestionar las mismas partes del
sistema (especfico deMac OS).
Infierno de dependencias(dependency hell):
Escenario de problemas producidos por las
versiones de otros productos que se necesitan
para hacer funcionar un tercero.
Infierno DLL(DLL hell): Problemas con las versiones,
disponibilidad o proliferacin de DLLs (especfico de

Microsoft Windows)
Infierno JAR(JAR hell): Problemas con diferentes
versiones o ubicaciones de ficheros JAR (Java),
tpicamente causados por la falta de comprensin
del modelo de carga de clases.
v 1.3.2
91
Avance del alcance(scope creep): Permitir que el alcance de un

proyecto crezca sin el control adecuado.
Bloqueo del vendedor(vendor lock-in): Construir un sistema que
dependa en exceso de un componente proporcionado por un
tercero.
Diseo de comit(design by committee): Contar con muchas
opiniones sobre un diseo, pero adolecer de falta de una visin
unificada.
Escalada del compromiso(escalation of commitment): No ser
capaz de revocar una decisin a la vista de que no ha sido
acertada.
Funcionalitis acechante(creeping featuritis): Aadir nuevas
funcionalidades al sistema en detrimento de su calidad.
Gestin basada en nmeros(management by numbers): Prestar
demasiada atencin a criterios de gestin cuantitativos, cuando
no son esenciales o difciles de cumplir.
Gestin champin(mushroom management): Tratar a los
empleados sin miramientos, sin informarles de las decisiones
que les afectan (mantenindolos cubiertos y en la oscuridad,
como los championes).
v 1.3.2
92
Gestin porque lo digo yo(management by perkele): Aplicar una

gestin autoritaria con tolerancia nula ante las disensiones.
Migracin de coste(cost migration): Trasladar los gastos de un
proyecto a un departamento o socio de negocio vulnerable.
Obsolescencia continua(continuous obsolescence): Destinar
desproporcionados esfuerzos a adaptar un sistema a nuevos entornos.
Organizacin de cuerda de violn(violin string organization): Mantener
una organizacin afinada y en buen estado, pero sin ninguna
flexibilidad.
Parlisis del anlisis(analysis paralysis): Dedicar esfuerzos
desproporcionados a la fase de anlisis de un proyecto, eternizando el
proceso de diseoiterandosobre la bsqueda de mejores soluciones o
variantes.
Peligro moral(moral hazard): Aislar a quien ha tomado una decisin a
raz de las consecuencias de la misma.
Sistema de caeras(stovepipe): Tener una organizacin estructurada
de manera que favorece el flujo de informacin vertical, pero inhibe la
comunicacin horizontal.
Te lo dije(I told you so): Permitir que la atencin se centre en que la
desoda advertencia de un experto se ha demostrado justificada.
Vaca del dinero(cash cow): Pecar de autocomplacencia frente a
nuevos productos por disponer de un productolegacymuy lucrativo.
v 1.3.2
93
Arrojar al otro lado del muro(thrown over the wall).

Billete lobo(wolf ticket): Declarar compatibilidad con un
estndar cuando esta no existe.
Blowhard Jamboree.
Cadena sin longitud(string without length).
Cajas de dilogos en cascada (cascading dialog boxes).
Callejn sin salida(dead end): Encontrar un problema que
impide continuar trabajando, pero la direccin no permite
corregir el problema. El equipo queda estancado.
Caminar por un campo de minas (walking through a mine
field): Trabajar con un componente pobremente probado
(usualmente inestable), y por tanto poco confiable.
Chivo expiatorio(scape goat).
Codificacin brutal: Presionar a los programadores a trabajar
sobre una arquitectura sin disear y sin requisitos evidentes.
Comit designado(appointed team): Crear un comit o
grupo de trabajo para resolver un problema y no ocuparse
de lograr que el grupo funcione.
v 1.3.2
94
Compensacin equitativa(egalitarian compensation): Compensar al personal por

el trabajo individual hecho.
Contenedor mgico(magic container).
Cuerpos tibios(warm bodies).
Culto al carguero(cargo cult).
Cultura del miedo(fear culture)): Ambiente en el que cada empleado tiene
miedo de mostrar el resultado de su trabajo por miedo a ser despedido por tener
errores.
Cultura del hroe(hero culture).
Decisin aritmtica(decision by arithmetic).
Desarrollo distribuido geogrficamente(geographically distributed
development).
Desarrollo marcado por las herramientas(autogenerated stovepipe): Preferir una
solucin generada automticamente sobre la mejor solucin.
Descomposicin funcional(functional decomposition): Traducir un programa de
un lenguaje estructurado a unoOOusando una sola clase y muchos mtodos
privados.
Disear por disear(design for the sake of design): Realizar un diseo
excesivamente complejo sin necesidad real.
Diseo con arquitectura impuesta(architecture as requirement): Imponer que el
diseo considere, obligatoriamente, el uso de herramientas o mtodos no
necesariamente idneos.
Diseo de fregadero(kitchen sink design).
Diseadores empricos(architects don't code): Incapacidad del grupo de diseo
para evaluar la complejidad del objeto diseado.
v 1.3.2
95
El correo electrnico es peligroso(email is dangerous): Peligro de olvidar que detrs

de los emails recibidos hay personas de carne y hueso.
El gestor controla el proceso(manager controls process).
El traje nuevo del emperador(emperor's new clothes): Temor a sealar los defectos
de un producto o proceso que un gerente o manager cree que funciona bien.
El viejo gran duque de York(the grand old Duke of York).
Ellos me entendieron(they understood me): Explicar a programadores o
diseadores junior lo que se espera de ellos muy brevemente, y asumir que
entendieron lo que se les pidi.
Embudo de excepciones(exception funnel): Atrapar una excepcin e ignorarla, sin
reportarlo.
Entrenar al entrenador(train the trainer).
Es un problema de operadores(it is an operator problem).
Esconder las armas(cover your assets).
Falsa economa(false economy): Permitir que los recortes de presupuesto afecten la
eficiencia de los trabajadores (las prdidas terminan siendo mayores que lo
ahorrado).
Falso punto final subrogado(false surrogate endpoint).
Fechas en punto flotante(floating point times).
Haz tu propia base de datos(roll your own database).
Ingenieros compatibles e intercambiables(plug compatible interchangeable
engineers).
Introduccin de dificultad por analoga(analogy breakdown): Disear por analoga
con problemas resueltos, posiblemente introduciendo dificultades no inherentes al
problema, o descuidando dificultades propias del nuevo caso que se maneja.
v 1.3.2
96
Invocar a constructores con nulos(passing nulls to constructors).

La disputa familiar(the feud).
La experiencia mata el diseo(architecture by implication):
Descuidar el diseo por confiar excesivamente en la experiencia
previa.
Los clientes son tontos(customers are idiots): Pensar que uno
sabe ms que el cliente, y por tanto no es necesaria una
investigacin con el cliente.
Manaco del control(control freak).
Mquina de Rube Goldberg(Rube Goldberg machine): Realizar
implementaciones muy complejas para tareas sencillas.
Matar al mensajero(shoot the messenger).
Matar dos pjaros de un tiro(kill two birds with one stone).
Matrimonio sumarsimo(sumo marriage).
Mazorca de maz(corn cob).
Mecanismos de recompensa discordantes(discordant reward
mechanisms).
Mezclador de software(software merger).
Miedo al xito(fear of success): Permitir que las nicas razones
de que los trabajos no se completen sean de ndole social.
v 1.3.2
97
Moneda en punto flotante(floating point currency): Utilizar una representacin

en punto flotante para valores que representan dinero, lo que puede provocar
prdida de precisin.
Morir planificando(death by planning).
Nacionalismo(national ism).
Navaja suiza(swiss army knife): Intentar crear un producto que solucione
varios problemas poco relacionados entre s.
No es mi trabajo(Not my job): No solucionar algn problema evidente
argumentando que es problema o fallo de otro.
No especificar(specify nothing).
No inventado aqu(not invented here).
Otra reunin ms lo resolver(yet another meeting will solve it).
Otro programador ms(yet another programmer).
Presunto heredero(heir apparent).
Proceso a prueba de idiotas(idiot proof process).
Programador discordante(net negative producing programmer).
Proyecto del da de la marmota(ground hog day project): Discutir los mismos
temas en todas las reuniones, slo para llegar a la conclusin de que "algo
debe hacerse".
Prueba incompleta(asynchronous unit testing): Descuidar en la etapa de
pruebas, algunas unidades en todos los casos, o todas las unidades en algunos
casos.
v 1.3.2
98
Quiero estimaciones ahora(give me estimates now): Dar

estimaciones sin tener suficientes datos para hacerlas.
Requisitos esparcidos por la pared(requirements tossed over the
wall).
Requisitos ocultos(Hidden requirements).
Si funciona, no lo toques(if it is working don't change).
Somos tontos(we are idiots): Pensar que el conocimiento interno
del problema es peligroso (por riesgo de que sea pobre o
equivocado), y pedir validacin del cliente para cada caracterstica
o decisin mayor.
Tarjetas CRCI(CRCI cards).
Tormenta de reproches(blame storming).
Torre de vud(tower of voodoo).
Trampa para osos(bear trap): Invertir mucho en una herramienta
poco adaptada o factible, de manera que despus es imposible
deshacerse de ella.
nico punto de salida de funcin(single function exit point).
Valor por defecto indefinido(zero means null): Escoger un valor
arbitrario para representar la indefinicin, sin garantizar que ese
valor no puede realmente ocurrir.
Violencia intelectual(intellectual violence).
v 1.3.2
99
Agradezco
a Craig Larman todos los

conocimientos y diagramas extrados
de su libro UML y patrones, que
ilustran muchos ejemplos de estas
diapositivas.
Id like to thank Craig Larman for all the
knowledge, skills and figures included
in this presentation, which are excerpts
of his book UML and patterns
v 1.3.2
100

Patrones

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Patrones

Загружено:

Авторское право:

Доступные форматы

El cliente llega a un terminal PDV con mercancas y/o

servicios que comprar.

Realizado por Alberto Garay (dpto.de Informtica)

Realizado por Alberto Garay (dpto.de Informtica)

Ayudan a definir el comportamiento del sistema, descubrindonos

Centraremos el estudio de los cambios bajo tres aspectos

Precondiciones: Asunciones previas a la ejecucin

Es probable que se descubran nuevas clases conceptuales en este

Asignacin de responsabilidades: patrones GRASP y GoF

Realizado por Alberto Garay (dpto.de Informtica)

vez obtenidos los artefactos que

idea clave es sentirse como el gran

la fase anterior (de anlisis), se

se habla de responsabilidad, nos

datos derivables o calculables)

Realizado por Alberto Garay (dpto.de Informtica)

Se decide, al objeto Venta, otorgarle la

Realizado por Alberto Garay (dpto.de Informtica)

patrones son heursticas que nos ayudan

patrones nos proponen buenas

(P): planteamiento del

patrones, ya que con una sola palabra se

Principios bsicos de diseo

Realizado por Alberto Garay (dpto.de Informtica)

los patrones bsicos que

5 patrones GRASP bsicos

Cul es el principio ms bsico

Realizado por Alberto Garay (dpto.de Informtica)

Quin es el responsable de conocer

podramos utilizar el MD para inspirarnos

Realizado por Alberto Garay (dpto.de Informtica)

Nos percatamos que la venta es la experta y le asignamos la

1.1: p:= getPrecio :( Especificacin

Realizado por Alberto Garay (dpto.de Informtica)

Quin debera ser el responsable

Realizado por Alberto Garay (dpto.de Informtica)

Quin debera ser el responsable

Realizado por Alberto Garay (dpto.de Informtica)

P: Cmo soportar bajas dependencias, bajo

Acoplamiento: Medida de la fuerza con que un

elemento est conectado a otros.

El alto acoplamiento puede derivar en:

Ej. quin es el responsable de crear un Pago y

decidimos que sea la propia Venta quien lo cree y

No siempre es deseable el bajo acoplamiento:

persistencia, logging, en general servicios transversales

Cmo mantener la complejidad de una

que se relacionan las responsabilidades de un

trminos de cohesin, pero si por cada operacin que le llega,

No se puede considerar la cohesin de forma

Objetos servidores distribuidos. Para evitar el coste

(en rendimiento de una red) de crear nuevas

Quin debe ser el responsable de

Realizado por Alberto Garay (dpto.de Informtica)

Realizado por Alberto Garay (dpto.de Informtica)

Cules son los distintos aspectos de las

operacin proveniente de la interfaz de usuario.

Si es necesario, se puede optar por repartir sus

responsabilidades en otros controladores: uno por cada

dnde salen las responsabilidades

Alguien debe calcular el total de la ve

implementar un intermediario entre dos componentes

utilizar polimorfismo para asignacin de responsabilidades

Envolver los puntos calientes o componentes limtrofes