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

lifeline box representing one instance of class Sale, selected from the sales ArrayList 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

lifeline box representing one instance of class Sale, selected from the sales ArrayList 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