Diagramas de Interacción UML y GRASP

escuela técnica superior
de ingeniería informática
Diagramas de interacción UML
+
Patrones de Asignación de
Responsabilidades
(GRASP)
Departamento de
Lenguajes y Sistemas Informáticos
Ingeniería del Software de Gestión II
Objetivos
♦ ¿Dónde estamos?
♦ Aprender Sintaxis de los Diag. De Interacción
UML
♦ Introducir el concepto de los GRASP
♦ Conocer los distintos GRASP
escuela técnica superior
de ingeniería informática
Diagramas de
interacción UML
Departamento de
Lenguajes y Sistemas Informáticos
Ingeniería del Software de Gestión II
Índice
♦ Introducción
♦ Diagramas de secuencia
♦ Diagramas de colaboración
Índice
♦ Introducción
♦ Diagramas de secuencia
♦ Diagramas de colaboración
Introducción
♦ Dos notaciones para un mismo objetivo:
“ilustrar el modo en el que los objetos
interaccionan por medio de mensajes”
♦ Nos permiten modelar la vista dinámica
♦ Ayuda a implementar la lógica de los métodos
Índice
♦ Introducción
♦ Diagramas de secuencia
♦ Diagramas de colaboración
Diagramas de secuencia
♦ Cada objeto se representa con una caja y cada
mensaje con una flecha
♦ Las líneas que se extienden hacia abajo indican la
línea de tiempo de cada objeto
: Register
: Sale
doX
doA
a found message
whose sender will not
be specified
doB
doC
doD
execution specification
bar indicates focus of
control
typical sychronous message
shown with a filled-arrow line
Representación de clases e
instancias
lifeline box representing an
unnamed instance of class Sale
:Sale
lifeline box representing a
named instance
s1 : Sale
lifeline box representing the class
Font, or more precisely, that Font is
an instance of class Class – an
instance of a metaclass
«metaclass»
Font
List is an interface
lifeline box representing an
instance of an ArrayList class,
parameterized (templatized) to
hold Sale objects
sales:
ArrayList<Sale>
lifeline box representing
one instance of class Sale,
selected from the sales
ArrayList <Sale> collection
sales[ i ] : Sale
related
example
in UML 1.x we could not use an
interface here, but in UML 2, this (or
an abstract class) is legal
x : List
Mensajes a “self” o “this”
: Register
doX
clear
Creación y destrucción de
instancias
♦ Creación:
: Register
note that newly created
objects are placed at their
creation "height"
: Sale
makePayment(cashTendered)
create(cashTendered)
: Payment
authorize
♦ Destrucción:
: Sale
create(cashTendered)
: Payment
...
«destroy»
X
the «destroy» stereotyped
message, with the large
X and short lifeline
indicates explicit object
destruction
Fragmentos
♦ Mecanismo a través del cual se puede realizar la
especificación de bloques repetitivos, opcionales,
alternativos, entre otros
♦ Principales tipos de fragmentos:
Operador
alt
Significado
Indica que el fragmento de diagrama es una alternativa
loop
Indica que el fragmento de diagrama se ejecuta
repetidas veces
opt
Indica que el fragmento de diagrama es opcional.
par
Indica que el fragmento de diagrama incluye varias hebras
Alternativas
:A
:B
doX
alt
[ x < 10 ]
calculate
[ else ]
calculate
:C
Repeticiones
lineItems[i] :
SalesLineItem
: Sale
t = getTotal
loop
lineItems[i] is the expression to
select one element from the
collection of many
SalesLineItems; the ‘i” value
refers to the same “i” in the guard
in the LOOP frame
[ i < lineItems.size ]
st = getSubtotal
i++
an action box may contain arbitrary language
statements (in this case, incrementing ‘i’)
it is placed over the lifeline to which it applies
lineItems[i] :
SalesLineItem
: Sale
t = getTotal
loop
st = getSubtotal
This lifeline box represents one
instance from a collection of many
SalesLineItem objects.
Opcionalidad
: Foo
: Bar
xx
opt
[ color = red ]
calculate
yy
Marcos
sd AuthenticateUser
:A
:B
:B
:C
:C
authenticate(id)
doX
doA
doM1
doB
doM2
authenticate(id)
ref
ref
AuthenticateUser
DoFoo
sd DoFoo
:B
:C
interaction occurrence
doX
note it covers a set of lifelines
doY
note that the sd frame it relates to
has the same lifelines: B and C
doZ
Mensajes polimórficos
Payment {abstract}
Payment is an abstract
superclass, with concrete
subclasses that implement the
polymorphic authorize operation
authorize() {abstract}
...
CreditPayment
DebitPayment
authorize()
...
authorize()
...
object in role of abstract
superclass
polymorphic message
:Register
:Payment {abstract}
doX
authorize
:DebitPayment
stop at this point – don’t show any
further details for this message
:Foo
authorize
:CreditPayment
:Bar
authorize
doA
doX
doB
separate diagrams for each polymorphic concrete case
Índice
♦ Introducción
♦ Diagramas de secuencia
♦ Diagramas de colaboración
Diagramas de colaboración
♦ Cada objeto se representa con una caja, las relaciones
entre objetos con líneas y los mensajes con flechas que
indican la dirección
♦ Se especifica el orden relativo mediante números en cada
mensaje
1: makePayment(cashTendered)
2: foo
: Register
:Sale
2.1: bar
link line
Representación de clases e
instancias (Igual que en los DS)
lifeline box representing an
unnamed instance of class Sale
:Sale
lifeline box representing a
named instance
s1 : Sale
lifeline box representing the class
Font, or more precisely, that Font is
an instance of class Class – an
instance of a metaclass
«metaclass»
Font
List is an interface
lifeline box representing an
instance of an ArrayList class,
parameterized (templatized) to
hold Sale objects
sales:
ArrayList<Sale>
lifeline box representing
one instance of class Sale,
selected from the sales
ArrayList <Sale> collection
sales[ i ] : Sale
related
example
in UML 1.x we could not use an
interface here, but in UML 2, this (or
an abstract class) is legal
x : List
Numeración de los mensajes
first
second
third
msg1
1: msg2
:A
:B
1.1: msg3
2.1: msg5
2: msg4
:C
fourth
fifth
2.2: msg6
sixth
:D
Mensajes a “self” o “this”
msg1
: Register
1: clear
Creación de instancias
Three ways to show creation in a
communication diagram
create message, with optional initializing parameters. This will
normally be interpreted as a constructor call.
1: create(cashier)
: Register
:Sale
1: create(cashier)
: Register
:Sale {new}
«create»
1: make(cashier)
: Register
if an unobvious creation message name is used, the
message may be stereotyped for clarity
:Sale
Alternativas
unconditional after
either msg2 or msg4
:E
1a and 1b are mutually
exclusive conditional paths
2: msg6
1a [test1] : msg2
msg1
:A
:B
1b [not test1] : msg4
:D
1b.1: msg5
1a.1: msg3
:C
Repeticiones
runSimulation
: Simulator
1 * [ i = 1..n ]: num = nextInt
: Random
iteration is indicated with a * and an optional
iteration clause following the sequence number
Repeticiones
t = getTotal
: Sale
1 * [i = 1..n]: st = getSubtotal
this iteration and recurrence clause indicates
we are looping across each element of the
lineItems collection.
lineItems[i]:
SalesLineItem
This lifeline box represents one instance from a
collection of many SalesLineItem objects.
lineItems[i] is the expression to select one
element from the collection of many
SalesLineItems; the ‘i” value comes from the
message clause.
t = getTotal
: Sale
1 *: st = getSubtotal
Less precise, but usually good enough to imply
iteration across the collection members
lineItems[i]:
SalesLineItem
Opcionalidad
conditional message, with test
message1
: Foo
1 [ color = red ] : calculate
: Bar
Mensajes polimórficos
polymorphic message
doX
:Register
stop at this point – don’t show any
further details for this message
authorize
authorize
:DebitPayment
:Payment {abstract}
object in role of abstract
superclass
authorize
doA
doB
doX
:Foo
:CreditPayment
separate diagrams for each polymorphic concrete case
:Bar
Mensajes polimórficos
Diagrama de Secuencia
Vs.
Diagrama de Colaboración
Bibliografía
♦ Específica:
♦ “http://www.uml.org/”, Especificación de la OMG.
♦ De Apoyo:
♦ “http://www.sparxsystems.com.au/UML_Tutorial.htm”,
www.sparxsystems.com.au/UML_Tutorial.htm
Tutorial on-line de UML.
Cuestiones de Examen
♦ En Problemas:
♦ Dibuje un diagrama de secuencia explicando el
proceso de carga en un repositorio de
Subversion, de un proyecto en Eclipse, la
modificación de un fichero y su actualización en
dicho repositorio.
♦ Dado un determinado sistema… realice un
diagrama de secuencia que ilustre la ejecución
del método “registrado” para determinadas
condiciones…
escuela técnica superior
de ingeniería informática
Patrones de
Asignación de
Responsabilidades
(GRASP)
Departamento de
Lenguajes y Sistemas Informáticos
Ingeniería del Software de Gestión II
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Alta Cohesión
♦ Bajo Acoplamiento
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Alta Cohesión
♦ Bajo Acoplamiento
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Introducción
♦ Principio (RAE)
♦ Cada una de las primeras proposiciones o verdades
fundamentales por donde se empiezan a estudiar las
ciencias o las artes
♦ Cualquier disciplina con cierto grado de madurez cuenta con
un conjunto de principios
♦ (E ) Indique todos los principios relacionados con el DOO
que conozca
♦ (E ) Explique claramente los principios identificados.
♦ ¿Es posible comunicar los principios de manera sistemática?
Introducción
♦ Durante mucho tiempo estos principios se han transmitido
independientemente
♦ El diseño de aplicaciones software es una de las actividades
en las que aún predomina el arte sobre el método.
♦ ¿Es posible transmitirlos de una manera homogénea,
compacta que permita su aplicación sistemática?
♦ Según C. Larman Sí. El ha propuesto un conjunto de
principios a los que ha denominado GRASP (General
Responsability Assignment Software Pattern)
Introducción
♦ GRASP (pillar, comprender,…) Larman la eligió
para sugerir la importancia de comprender
estos principios como paso clave para diseñar
con éxito
♦ GRASP: describen los principios fundamentales
del DOO y la asignación de responsabilidades
expresados como patrones
Introducción
♦ Descripción de un GRASP
♦ Problema
♦ Solución
♦ Ejemplo
♦ Discusión
♦ Contraindicaciones
♦ Beneficios
♦ Patrones relacionados
♦ También conocido como
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Alta Cohesión
♦ Bajo Acoplamiento
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Experto en Información
Modelo del dominio que usaremos en los ejemplos
Experto en Información
1) Problema: ¿un principio general del DOO para la
asignación de responsabilidades a las clases?
♦ Una buena asignación facilita el mantenimiento, la eficiencia, la
comprensión, …
2) Solución: Asigne una responsabilidad al experto en
información (la clase que tiene la información necesaria
para llevar a cabo la responsabilidad)
3) Ejemplo:
1) ¿quién debe ser el
responsable de conocer
el total de una venta?
Sale
time
1
Contains
1..*
Sales
LineItem
quantity
*
Described-by
1
Product
Description
description
price
itemID
Experto en Información
♦
La aplicación de este o cualquier otro GRASP permite
refinar el diseño
t = getTotal
Sale
:Sale
time
...
New method
getTotal()
this notation will imply we
are iterating over all
elements of a collection
Sale
time
...
t = getTotal
: Sale
1 *: st = getSubtotal
lineItems[ i ] :
SalesLineItem
getTotal()
SalesLineItem
quantity
New method
getSubtotal()
Experto en Información
♦
En este caso se ha aplicado en tres ocasiones
Sale
time
...
t = getTotal
: Sale
1 *: st = getSubtotal
lineItems[ i ] :
SalesLineItem
1.1: p := getPrice()
getTotal()
SalesLineItem
quantity
:Product
Description
getSubtotal()
Product
Description
description
price
itemID
New method
♦
¿Qué otro diseño se podría haber propuesto?
getPrice()
Experto en Información
4) Discusión:
♦ Expertos de información parcial
♦ Suele conducir a diseños donde los objetos
se hacen responsables de las mismas
operaciones de los objetos inanimados a los
que representan
♦ Analogía en el mundo real. Normalmente se
otorgan responsabilidades a los individuos
que pueden disponer de toda la información
necesaria para llevar a cabo una tarea
♦
¿quién debería ser el responsable de realizar el
informe de cuentas de una empresa?
Experto en Información
5) Contraindicaciones
♦ En ocasiones su aplicación puede aumentar
el acoplamiento y reducir la cohesión
♦ ¿quién debería de almacenar una Venta en la
BBDD?
–
Siguiendo el EI se decidiría por la misma clase Venta. Esto podría
llevar a una situación en que cada clase tenga la responsabilidad
de acceder a la BBDD (vía JDBC p.e.)
»
La clase no está centrada únicamente en la lógica
»
Todas las clases estarían acopladas con las diferentes
clases de acceso a BBDD
»
Probablemente se duplicaría mucho código
♦ ¿quién debería ser el responsable de
autenticar?
Experto en Información
6) Beneficios
♦
Se mantiene el encapsulamiento de la
información Æ menor acoplamiento
♦
♦
¿Qué pasaría si la clase Venta averiguara el total
preguntando directamente a todos los Productos
involucrados?
Se distribuye el comportamiento entre las clases que
contienen la información requerida Æ clases más
ligeras Æ mayor cohesión
7) Patrones relacionados
♦
Bajo acoplamiento y alta cohesión
8) También conocido como
♦
♦
♦
♦
Colocar las responsabilidades con los datos
Eso que conoces, hazlo
Hacerlo yo mismo
Colocar los servicios con los atributos que trabaja
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Alta Cohesión
♦ Bajo Acoplamiento
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Creador
1) Problema: ¿Quién debe ser el responsable de la
creación de una nueva instancia de una clase?
2) Solución: Asigne a la clase B la responsabilidad de
crear una instancia de la clase A si se da alguna de las
siguientes circunstancias:
1) B agrega (compartidamente o no) a A
2) B tiene los datos de inicialización de A
3) B registra a A
4) B utiliza ‘estrechamente’ a A
5) B es experto en la creación de A
3) Ejemplo
♦ ¿Quién debería ser responsable de la creación de
una instancia de LineaDeVenta?
♦ Según este patrón, debería ser Venta
Creador
♦
Esto nos llevaría a una situación del tipo
: Register
: Sale
makeLineItem(quantity)
create(quantity)
: SalesLineItem
Creador
4) Discusión:
♦ La intención básica es encontrar un creador
que necesite dialogar con el objeto creado
en algún momento Æ Bajo acoplamiento
♦ Se puede ver como un caso particular del
Experto (cuando B tiene los datos de
inicialización de A).
♦
No es tan evidente, con frecuencia hay un objeto
principal que construye las partes y se las pasa
al contenedor
Creador
5) Contraindicaciones
♦
En ocasiones la creación posee una complejidad
significativa resultando más conveniente delegar
esta responsabilidad en una clase diseñada a tal
efecto
6) Beneficios
♦
Favorece el bajo acoplamiento
♦
¿Qué pasaría si la clase Registro creara las
LíneasDeVenta? (“No hables con extraños”)
7) Patrones relacionados
♦
♦
Bajo acoplamiento y alta cohesión
Fábricas
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Bajo Acoplamiento
♦ Alta Cohesión
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Bajo Acoplamiento (evaluativo)
Acoplamiento. Es una medida de la fuerza con que un
elemento está conectado a, tiene conocimiento de, confía
en, otros elementos
Un elemento fuertemente acoplado
♦ Se resiente de los cambios en los elementos relacionados
♦ Son difíciles de entender de manera aislada
♦ Difíciles de reutilizar (requiere las clases ‘acopladas’)
1) Problema: ¿Cómo evitar estos inconvenientes?
2) Solución: Asigne responsabilidades de manera que el
acoplamiento permanezca bajo
♦ ¿Es una solución?
♦ Principio evaluativo: lo aplica un diseñador cada vez que tiene
que evaluar una decisión de diseño
Bajo Acoplamiento
3) Ejemplo:
¿Qué clase debería ser responsable de crear una instancia
de Payment y asociarla con una instancia de Sale?
Bajo Acoplamiento
♦
Puesto que Register registra el pago (Payment) en el dominio del
mundo real, el GRASP Creador sugiere ...
♦
Register está acoplado con Payment y con Sale. Sale también
está acoplado con Payment.
♦
¿Cómo podríamos reducir el acoplamiento?
Bajo Acoplamiento
4) Discusión:
♦
En la práctica, el nivel de acoplamiento no puede
evaluarse si tener en cuenta otros GRASP como la
cohesión o el experto
♦
Una subclase está fuertemente acoplada a su
superclase. Esta decisión deber ser estudiada
cuidadosamente
♦
¿Qué inconvenientes encuentra en hacer que todas
las clases que requieren persistencia deriven de una
superclase PersistentObject?
♦
¿Se resiente de los cambios en los elementos relacionados?
♦
¿Es difícil de entender de manera aislada?
♦
¿requiere de las clases acopladas para poder ser reutilizada?
Bajo Acoplamiento
4) Discusión:
♦
No existe medida que indique si el acoplamiento es
demasiado alto Æ lo que debe tener en cuenta el
diseñador es el impacto que provoca una decisión
en el grado de acoplamiento
♦ ¿Qué ocurriría si intentáramos reducir el
máximo el acoplamiento?
♦
… Antipatrón BLOB
Bajo Acoplamiento
5) Contraindicaciones
♦ Escoger las batallas
♦ El alto acoplamiento no es inherentemente
malo, lo es sólo con elementos “inestables” (en
su contrato sintáctico, semántico, ... O su
simple presencia)
–
Una aplicación J2EE puede acoplarse con seguridad con
la biblioteca java.util.*
♦ No se debe invertir esfuerzos en reducir el
acoplamiento cuando no hay motivos
reales para hacerlo (Generalizitis)
–
Si se preveen diferentes métodos de pago puede merecer
la pena desacoplar Register de Payment y utilizar el PD
Strategy para los diferentes pagos
Bajo Acoplamiento
6) Beneficios
♦ Se amortigua el impacto de los cambios
en los elementos inestables
♦ Se facilita el entendimiento
♦ Facilita la reutilización
7) Antecedentes
♦ Acoplamiento y cohesión son principios
realmente fundamentales que fueron
propuestos por Larry Constantine a
finales de los 60 (40 años…)
8) Patrones relacionados
♦ Alta Cohesión
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Bajo Acoplamiento
♦ Alta Cohesión
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Alta Cohesión (evaluativo)
Cohesión (funcional). Es una medida de la fuerza con la que
se relacionan y del grado de focalización de las
responsabilidades de un elemento.
Un elemento con baja cohesión tiene muchas
responsabilidades:
♦ Difíciles de entender, reutilizar y mantener
♦ Delicadas, frágiles (muchas probabilidades de verse
afectada en los cambios)
1) Problema: ¿Cómo mantener manejable la
complejidad?
2) Solución: Asigne responsabilidades de manera
que la cohesión permanezca alta
♦ ¿Es una solución?
♦ También es un principio evaluativo
Alta Cohesión
3) Ejemplo:
¿Qué clase debería ser responsable de crear una instancia
de Payment y asociarla con una instancia de Sale?
Alta Cohesión
♦
Puesto que Register registra
el pago (CashPayment) en el
dominio del mundo real, el
GRASP Creador sugiere ...
: Register
: Sale
makePayment()
create()
p : Payment
addPayment( p )
♦
¿Qué pasaría si Register siguiera
haciéndose responsable de las
operaciones de sistema?
♦
Iría perdiendo cohesión progresivamente
: Register
♦
¿Cómo se podría conseguir
una mejor cohesión?
: Sale
makePayment()
makePayment()
create()
: Payment
Alta Cohesión
4) Discusión:
♦
No es fácil cuantificar el grado de cohesión de un elemento. Para
G. Booch, un elemento es altamente cohesivo si:
♦
♦
todos sus elementos trabajan juntos para proporcionar algún
comportamiento bien delimitado
Escenarios que ilustran diferentes grados de cohesión funcional
♦
♦
♦
♦
Muy baja cohesión. Una clase responsable de muchas cosas en
áreas funcionales diferentes (Clase InterfazBDR-RPC)
Baja cohesión. Una clase responsable de una tarea compleja de
un área funcional (Clase InterfazBDR). (No es el caso de la
fachada JDBC)
Alta cohesión. Una clase con responsabilidad “moderada” en un
área funcional que colabora con otras para llevar a cabo las
tareas (La fachada de JDBC)
Moderada cohesión. Una clase tiene responsabilidades “ligeras”
y únicas en unas pocas áreas diferentes que están lógicamente
relacionadas con el concepto de la clase, pero la relación entre
ellas no es fuerte
Alta Cohesión
4) Discusión:
♦
♦
Una clase altamente cohesiva suele:
♦
tener un número relativamente pequeño de
métodos, con funcionalidad altamente relacionada
♦
no realiza mucho trabajo
♦
Colabora con otras clases para compartir el
esfuerzo
Una de las posibles analogías en el mundo real
♦
Un trabajador con muchas responsabilidades (que
no mucha responsabilidad) suele ser poco efectivo
Alta Cohesión
4) Discusión:
♦
Diseño modular
♦
Cohesión y acoplamiento son principios conocidos
desde hace mucho. A partir de ellos se define el
principio de modularidad
♦
♦
Un diseño es modular si se descompone en un
conjunto de módulos cohesivos y débilmente
acoplados
Cohesión y acoplamiento: el ying y el yang de la IS
♦
Una mala cohesión causa, normalmente, un mal
acoplamiento
♦
La filosofía china los considera como fuerzas opuestas
pero complementarias
♦
Un buen diseño siempre logra un buen equilibrio entre
cohesión y acoplamiento
Alta Cohesión
5)Contraindicaciones
♦ Existen pocas situaciones que
justifiquen la aceptación de una baja
cohesión (Fachadas)
6) Beneficios
♦
♦
♦
♦
Se incrementa claridad y comprensión
Se simplifica el mantenimiento
Favorece el bajo acoplamiento
Facilita la reutilización
7) Patrones relacionados
♦ Bajo acoplamiento
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Bajo Acoplamiento
♦ Alta Cohesión
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Fabricación Pura
1) Problema: ¿Cómo proceder cuando las soluciones
encontradas comprometen la cohesión y el acoplamiento?
2) Solución: Asigne un conjunto cohesivo de
responsabilidades a una clase artificial (no representa
ningún concepto del dominio del problema)
♦
Tal clase es una fabricación de la imaginación e idealmente
debería ser pura (diseñada exclusivamente para dicho fin)
3) Ejemplo
♦
Este problema suele darse cuando se sigue un enfoque
seamless desde el análisis hasta la implementación
♦
Suponga que se necesita dar persistencia a la clase Sale en
una BDR. Según el EI se puede justificar la asignación de dicha
responsabilidad a la clase Sale. ¿Implicaciones?
♦
Las nuevas responsabilidades reducirían la cohesión
♦
Aumenta el acoplamiento con elementos que no son del dominio
(interfaces JDBC p.e.)
♦
Probablemente se duplique código
Fabricación Pura
3) Ejemplo:
♦ Una solución razonable puede ser definir una clase
(PersistentStore) cuya única responsabilidad es
almacenar objetos de cualquier tipo. Esta clase es una
invención de la imaginación. Ahora, la clase Sale
♦ Tiene mayor cohesión y mejor acoplamiento
♦ La clase PersistentStore es relativamente cohesiva
♦ La clase PersistentStore tiene mayor probabilidad de ser
reutilizada
4) Discusión:
♦
Por regla general, además de las clases definidas a partir del
modelo del dominio, los diseñadores definen clases por
conveniencia (se inspiran en una descomposición de
comportamiento en lugar de una descomposición de la
representación)
Fabricación Pura
5) Contraindicaciones
♦
El uso desmedido de fabricaciones puras puede
derivar en clases “función” o “algoritmo” (sólo
tienen un método).
♦
Un indicio de esta situación es cuando la mayoría
de objetos tienen pasar casi toda su información
a otros objetos para poder realizar las
responsabilidades
6) Beneficios
♦
Las fabricaciones puras suelen ser muy
cohesivas y reutilizables
7) Patrones relacionados
♦
♦
♦
Alta Cohesión y Bajo Acoplamiento
Suelen asumir las responsabilidades en base al EI
Muchos patrones GoF usan fabricaciones puras:
adaptador, estrategia, comando, …
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Bajo Acoplamiento
♦ Alta Cohesión
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Indirección
1) Problema: ¿Dónde asignar responsabilidades para
evitar/reducir el acoplamiento directo entre elementos y
mejorar la reutilización?
2) Solución: Asigne la responsabilidad a un objeto que medie
entre los elementos. Ahora el acoplamiento es indirecto
3) Ejemplo
♦
En el ejemplo de la “Fabricación Pura”, la clase PersistenObject
desacopla Sale de las clases que gestionan la BBDD
♦
Adaptación del cálculo de impuestos (Sale es ahora más
reutilizable)
: Sale
:TaxMasterAdapter
t = getTotal
TCP socket
communication
taxes = getTaxes( s )
xxx
...
...
«actor»
:TaxMasterSystem
the adapter acts as a level of
indirection to external systems
Indirección
4) Discusión:
♦
“La mayoría de los problemas en diseño se resuelven mediante
indirección”
♦
La mayoría de los problemas en ejecución se pueden resolver
eliminando alguna indirección
5) Beneficios
♦ Disminuye el acoplamiento
6) Patrones relacionados
♦ Variaciones protegidas
♦ Bajo Acoplamiento
♦ Muchos patrones GoF usan indirección: adaptador,
fachada, puente, observador, mediador
Índice
♦ Introducción
♦ Experto en Información
♦ Creador
♦ Bajo Acoplamiento
♦ Alta Cohesión
♦ Fabricación Pura
♦ Indirección
♦ Variaciones Protegidas
Variaciones Protegidas
♦
Un punto de variación representa a una variación
contemplada en la especificación de requisitos o
documento de entrada del diseño. Por ejemplo:
♦ “el formato de compresión podrá ser PCX, GIF, BMP,
TIFF y JPEG”
♦
Un punto de evolución es un punto de variación
sobre cuya existencia se conjetura (especula). Por
ejemplo, a partir del requisito anterior, el diseñador
puede especular sobre la evolución del sistema y
tomar la decisión de protegerse sobre la variación del
formato de compresión para dar cabida en el futuro a
nuevos formatos (p.e a HSI-JPEG). El diseñador
experto se reconoce, entre otros rasgos, por su
acierto a la hora de definir estos puntos.
Variaciones Protegidas
1) Problema: Cómo diseñar un elemento de modo
que sus variaciones o inestabilidades afecte lo
menos posible en otros elementos
2) Solución: Identifique los puntos de variaciones
previstas o de inestabilidad y asigne
responsabilidades para crear una interfaz
estable alrededor de ellos
3) Ejemplo: Ejemplo anterior del Calculador de
impuestos.
♦ ¿Cómo se han resuelto estos puntos de variación?
♦ Usamos una Interfaz adaptador que es implementada por
cada uno de los adaptadores necesarios para distintos
sistemas de impuestos
Variaciones protegidas
4) Discusión:
♦
Este patrón fue propuesto en 1996 por A. Cockburn, aunque
lleva más de 30 años bajo otros nombres
♦
Mecanismos motivados por VP
♦
Básicos: encapsulación, interfaces, polimorfismo, indirección, …
♦
Diseños dirigidos por datos: (amplia familia de técnicas) Ficheros
de configuración, hojas de estilo, ficheros de propiedades, …
Protegen de la variación de los parámetros involucrados
♦
–
Búsqueda de servicios: JNDI, TraderService, UDDI
–
A partir de ficheros de configuración
Ocultación de la estructura. Proteger de los cambios en la
estructura aplicando la regla “No hables con extraños” (Ley de
Demeter)
–
Los objetos directos son “conocidos”, los indirectos son “extraños”
Dinero cantidad= venta.getPago().getCantidadEntregada():
Dinero cantidad= venta.getCantidadEntregadaEnPago();
Variaciones protegidas
4) Discusión:
♦
Principio de sustitución de Liskov
♦
Formaliza el principio de protección contra las variaciones en
implementaciones diferentes de una interfaz, o una subclase que
extiende a una superclase
–
El fragmento de código que hace referencia a un tipo T debería trabajar correctamente con
cualquier implementación o subclase de T que lo sustituya
Variaciones protegidas
public class Rectangle
public class LiskovTest
{
{
protected float height, width;
public void run()
public void setHeight (float h) {
{
height= h;
Rectangle r= new Rectangle();
}
test(r);
public void setWidth (float w){
Square s= new Square();
width= w;
test(s);
}
}
public float getHeight(){
void test(Rectangle r)
return height;
{
}
r.setHeight(5);
public float getWidth(){
r.setWidth(4);
return width;
if (r.getHeight()*r.getWidth()==20)
}
System.out.println(“Test was ok”);
}
else
public class Square extends Rectangle
System.out.println(“Test wasn’t ok”);
{
}
……
}
}
Variaciones protegidas
public class Square extends Rectangle
{
public void setHeight (float h)
{
super.setHeight(h);
super.setWidth(h);
}
public void setWidth (float w)
{
super.setHeight(w);
super.setWidth(w);
}
}
La semántica
intuitiva no
coincide con
la real
Variaciones protegidas
5) Contraindicaciones
♦
El coste de diseñar la protección de un punto de variación o de
evolución es superior que rehacer un diseño simple
♦
inexpertos Æ diseños frágiles
♦
intermedios Æ diseños excesivamente flexibles
♦
Expertos Æ diseño simple y frágil en el que existe un equilibrio
entre el coste de cambio y su probabilidad
6) Beneficios
♦
Facilita la adición de las extensiones asociadas a las
variaciones
♦
Se reduce el impacto y coste de los cambios (se reduce el
acoplamiento)
7) Patrones relacionados
♦
La mayoría de los principios y patrones de diseño son mecanismos VP
♦
Puntos de variación y evolución también se conocen como puntos
calientes
Variaciones protegidas
8) También conocido como
♦ Principio de ocultación de la información
♦ “On the criteria to be used in decomposing systems into
modules” (Parnas, 1972)
–
… proponemos en lugar de eso que uno comience con una lista de decisiones de
diseño difíciles o con altas probabilidades de cambio. Cada módulo se diseña
entonces para ocultar dichas decisiones a otros …
♦ Principio abierto-cerrado (Meyer, 1988)
♦ Los módulos deberían ser tanto abiertos como cerrados.
Abiertos para ser extendidos y cerrados para ser usados
–
¿Se preserva este principio con el PD Estrategia?
Bibliografía
♦ Específica:
♦ “UML y Patrones”,
Patrones Craig Larman (1999).
♦ De Apoyo:
♦ “Applying UML and Patterns - An Introduction to
Object-Oriented Analysis and Design and Iterative
Development”,
Development Craig Larman (2004).
♦ “http://davidhayden.com/blog/dave/category/33.aspx”
http://davidhayden.com/blog/dave/category/33.aspx
, Reflexiones sobre los GRASP.
♦ “Head First - Design Patterns”,
Patterns Ed.- O’Reilly (2004).
Cuestiones de Examen
♦
En TEST:
♦ Marque las dos opciones que contienga(n) los principios
más importantes:
♦
♦
♦
♦
♦
Cohesión y Acoplamiento
Variaciones Protegidas
Indirección y Fabricación Pura
Ninguna de las anteriores_______________
Si aplicamos de manera desmedida el principio “bajo
acoplamiento” sin tener en cuenta al resto, ¿cuál(es) de
las siguientes situaciones ocurrirá?
♦
♦
♦
♦
Conseguiremos un nivel de acoplamiento óptimo
(acoplamiento cero), aunque no tendremos una buena
cohesión.
Tendremos muchas clases, muy poco relacionadas entre
ellas.
Antipatrón blob.
Ninguna de las anteriores________________
Cuestiones de Examen
♦
En TEST:
♦ ¿Qué problema pretende resolver el principio
“Indirección”?
♦ Problemas de Cohesión.
♦ Problemas de Acoplamiento.
♦ La asignación de responsabilidades de manera
correcta.
♦ Ninguna de las anteriores________________
♦ ¿Cuál de los siguientes principios está incluido
dentro del GRASP “Variaciones Protegidas”?
♦ Principio de sustitución de Liskov.
♦ Principio de Hollywood.
♦ Principio “elige tus batallas”.
♦ Ninguna de las anteriores________________
Cuestiones de Examen
♦ En Problemas de Diseño:
♦ Dado un modelo UMl inicial y propuestos
diferentes cambios:
– Proponga un nuevo diseño que tenga en cuenta esta variabilidad
y que no disminuya la cohesión.
– Indique cuál es el patrón/es GRAS que se han aplicado en el
nuevo diseño propuesto y explique las razones para ello.
– Discutir la cohesión y el acoplamiento de la solución
propuesta junto con las responsabilidades de cada clase.
¡Gracias!
♦ ¿Podemos mejorar esta lección?
♦ Mándanos un email a [email protected]
[email protected]
[email protected]
[email protected]
♦ Visite la web de la asignatura www.lsi.us.es