3.

3: Realización de diagramas de 
secuencia:  capas software y patrones 
f
GRASP

A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo

OCW
2013
 3.3.- ¿ Cómo realizar los diagramas de
3.3.- 30

secuencia a partir de los flujos de eventos

de casos de uso
uso??
Caso de Uso

: ACTOR
Flujo de Eventos
-Actor proporciona…
-El
El sistema
it …
Flujo de Eventos Alternativo
- Si ocurre X…

: ACTOR

¿ .
?
 ¿ Cómo realizar los diagramas de
secuencia a partir de los flujos de
eventos de casos de uso?
uso?
Caso de Uso
Usando PATRONES
: ACTOR
Flujo de Eventos de DISEÑO
-Actor proporciona…
-El sistema …
Flujo de Eventos Alternativo
- Si ocurre X…

: ACTOR
Aplicando una
¿ .
? ARQUITECTURA
SOFTWARE en varios
niveles/capas
 Realización de diagramas de
secuencia
 Diseñaremos un diagrama de secuencia a
partir del flujo de eventos del caso de uso
Tomar Préstamo Copia Libro (TPCL)
 aplicando
d una arquitectura software
f en varios niveles
 diferenciando los niveles/capas de presentación
(interacción con el usuario), lógica del negocio o
acceso a datos.
 aplicando patrones GRASP cuando lo consideremos
necesario
 CU: Tomar Préstamo Copia
p Libro
Tomar Préstamo <<extends>>
extends
Copia Libro Reservar Libro
- No disponible

Socio

Flujo de eventos:
• El socio p
proporciona
p su número de socio y la
signatura del libro que quiere tomar en préstamo
• El sistema comprueba si existe alguna
g copia no
prestada de dicho libro
• Si no hay copias disponibles:
EXTENDS RESERVAR LIBRO
• Se comprueba que el socio no se pasa de su número
máximo
á i d
de lib
libros en préstamo
é t
• Se registra el nuevo préstamo con la fecha actual
 Modelo del Dominio
LIBRO

signatura, título, autores,

editorial, perPréstamo,
fechaPublicación,... reserva

0..*
1 esCopiaDe

1..* suCopia reservadoPor

COPIA_LIBRO 0..* SOCIO
00..12
12
numCopia 0..1 dni, numSocio, nombre,
tomaEnPréstamo prestadaA
estado: {disp,prest,reser} dirección, teléfono,
tomóEnPréstamo fuePrestadaA numMaxPrest...
0..* 0..*
CATÁLOGO
1 0..* PRÉSTAMO_CL
HISTÓRICO_CL
fechaPrest
fechaIni, fechaFin
0..*
1 TRABAJADOR
REVISTA
0..12 0..1 numSegSocial
título, volumen, tomaEnPréstamo prestadaA
número, editorial, tomóEnPréstamo fuePrestadaA categoría: {trab, encargado}
fechaPublicación,...

PRÉSTAMO_RV HISTÓRICO_REV
fechaIni, fechaFin
fechaPrest
 3.3.1- Capas lógicas en el software:
3.3.1-
Presentación,, lógica del negocio y acceso a
Presentación
datos
 En
E los
l flujos
fl j de
d eventos hay
h acciones
i dde dif
diferente
naturaleza o relacionadas con el/la:
 3.3.1.1.
3.3.1.1.-- Presentación
 interfaces
i f de
d usuario
i y la
l interacción
i ió con ell mismo
i

 3.3.1.2.
3.3.1.2.-- Lógica
g del negocio g
 resolver los problemas del negocio
 implementar las reglas propias del negocio

 3.3.1.3.
3.3.1.3.-- Acceso a datos
 Recuperar
Recuperar,, insertar
insertar,, actualizar y borrar objetos del dominio
 Se dará persistencia a los objetos del modelo del dominio utilizando
una BDOO
 EJ: CU: Tomar Préstamo Copia Libro
PRESENTACIÓN
Tomar Préstamo <<extends>>
Copia Libro Reservar Libro LÓGICA DEL NEGOCIO
ACCESO A DATOS
Socio - No disponible

Flujo
j de eventos:
• El socio proporciona su número de socio y la
signatura del libro que quiere tomar en préstamo
• El sistema comprueba si existe alguna copia no
prestada de dicho libro
libro.
• Si no hay copias disponibles/ copias disponibles
EXTENDS RESERVAR LIBRO
• Se comprueba que el socio no se pasa de su
número máximo de libros en préstamo
• Se registra el nuevo préstamo con la fecha actual
 3.3.2-- Patrones de responsabilidad
3.3.2
GRASP
 3.3.2.1.
3.3.2.1.-- Patrón CONTROLADOR
 3.3.2.2.
3.3.2.2.-- Patrón EXPERTO
 3.3.2.3.
3 3 2 3 - Patrón
3.3.2.3.- P ó CREADOR
C ADO
 3.3.2.4.
3 3 2 4 - Patrón BAJO ACOPLAMIENTO
3.3.2.4.-
 3.3.2.5.
3 3 2 5 - Patrón ALTA COHESIÓN
 ¿Qué es un patrón
patrón?
?
 Un PATRÓN es una SOLUCIÓN para un
PROBLEMA que se repite
 Idea propuesta en 1979 por Christopher Alexander,
profesor de arquitectura
p q
 "Cada patrón describe un problema que ocurre
i fi id d dde veces en nuestro entorno, asíí como lla
infinidad
solución al mismo,, de tal modo que
q podemos
p utilizar
z
esta solución un millón de veces más adelante sin
tener que volver a pensarla otra vez
vez."
 ¿Qué es un patrón de diseño
diseño?
?
 La idea de PATRÓN aplicada al DESARROLLO
SOFTWARE
 Un PATRÓN Ó de DISEÑO
Ñ es una SOLUCIÓNÓ a
un PROBLEMA de DISEÑO
 Un patrón debe ser
 EFECTIVO:
T ha
h servido
d para resolver
l problemas
bl
similares
 REUTILIZABLE: aplicable a diferentes problemas de
diseño
 Patrones GRASP
 GRASP Generall Responsibility
GRASP: ibili Assignment
i
Software Patterns
 L patrones GRASP describen
Los d ib los
l principios
i i i
fundamentales del diseño de objetos y sus
r p
responsabilidades
bilid d
 GRASP: significa “entender”, “comprender”
 El nombre GRASP sugiere la importancia de
COMPRENDER (GRASP) los principios
f d
fundamentalesl para diseñar
di ñ software
f orientado
i d a
objetos de manera correcta
 L 5 prim
Los primeros
r p patrones
tr n GRASP son:
n EXPERTO
EXPERTO,
CREADOR, ALTA COHESIÓN, BAJO
ACOPLAMIENTO y CONTROLADOR
 3.3.1.1.
3 3 1 1.- ¿Cómo se representa la interfaz de
3.3.1.1
usuario en un diagrama de secuencia?
 Se define un objeto de una clase INTERFAZ (también
llamada clase FRONTERA) que está especializada en
comunicarse con el ACTOR (sabe aceptar eventos de
entrada del usuario y mostrar resultados de salida)
 Ese objeto
j representará
p a una interfaz de usuario
gráfico habitualmente (interfaz AWT/Swing, página
HTML, JJSP, ASP.NET,…))

Los objetos de clases INTERFAZ/FRONTERA son los

que implementan la capa/nivel de PRESENTACIÓN
 Diagrama de secuencia TPCL (1)

obj1: IU_CU_TPCL
IU CU TPCL
: ACTOR
1: dar Invocación a
código
ódi lib
libro l LÓGICA
la ÓGICA
2: dar código DEL
socio NEGOCIO
3: pulsar 4:¿A qué MÉTODO de
b ó
botón qué OBJETO debe
llamar?
 3.3.1.2.- Invocación a Lógica del Negocio
3.3.1.2.-
3 3 2 1 - Patrón CONTROLADOR
3.3.2.1.-
3.3.2.1.
Nombre: CONTROLADOR
Nombre:
PROBLEMA: ¿A quién se le asigna la responsabilidad de
recibir o manejar eventos de entrada al sistema
sistema??
[Un evento de entrada al sistema es un evento generado por un actor
externo,, que se asocia con una operación del sistema.]
externo sistema.]
SOLUCIÓN:Ó A un objeto (clase
clase)) que representa al sistema
global, dispositivo o subsistema .
Es un único OBJETO para todo el sistema donde se colocan
TODAS LAS OPERACIONES DEL SISTEMA. También se suele
llamar objeto “FACADE”
FACADE (o FACHADA)
FACHADA).

El CONTROLADOR es el qque ofrecerá las

operaciones de la LÓGICA DEL NEGOCIO
 Diagrama
g de secuencia TPCL (2)
( )
:Controlador_
obj1:
bj1 IU_CU_TPCL
IU CU TPCL LogNegocio
: ACTOR
1: dar códigog
libro lib
2:: dar
da código
cód go
socio soc
3: ppulsar 5: ¿¿A quién
q enviar
botón 4:tomarPrestamo(lib,soc) esa petición?

Controlador_LogNegocio

tomarPrestamo(lib:int, soc:int)
 3.3.1.3.- Acceso al nivel de datos /
3.3.1.3.-
objetos del modelo del dominio
 ¿A quién le pide el controlador la ejecución de
esa operación, en quién delega? ¿Qué objeto/s
puede/n
p / ejecutar
j esa operación?
p
 ¿Qué necesita hacer el método?
 ENCONTRAR ALGÚN
DATO/INFORMACIÓN (Patrón EXPERTO)
 CREAR NUEVOS OBJETOS (Patrón CREADOR)

El CONTROLADOR de la LÓGICA del NEGOCIO

puede necesitar acceder al nivel o capa de DATOS
 3.3.2.2..- Patrón EXPERTO
3.3.2.2
Nombre: EXPERTO
Nombre:
PROBLEMA:
P O : ¿A
¿ qu
quién
é se lee pide
p de que busque uun
determinado dato o genere información
información??
SOLUCIÓN: N Al objeto
bj (clase
clase)) qque cuenta con los datos o
información necesaria
COMPRA

fecha, código
¿A quién se le pide
el total de la compra?
1

1..*

LÍNEA_COMPRA PRODUCTO
cantidad
tid d * 1
valor, descripción

NOTA IMPORTANTE: si es un objeto del dominio,

dominio hay que
asegurarse de que se encuentra cargado en la memoria principal.
En ese caso, ese objeto del dominio sería el EXPERTO.
 Acceso al nivel de datos para cargar los
objetos
bj t del
d l dominio
d i i
Los objetos
j del dominio que
q
queramos invocar deben estar
cargados en la memoria principal
principal. :AccesoBD
Lo haremos usando un objeto de
una clase
l (AccesoBD)
(A BD) que será:
á 1)
experto en acceder a la BDOO, o cc=getCompra(codC1)
getCompra(codC1)
bien 2) controlador de la BDOO
porque
po que también
ta b é se encargará
e ca ga á de las
as …
operaciones de inserción, borrado insertarCompra(codC2)
y modificación,
modificación además de las
operaciones de recuperación.
Ejemplo
j p de aplicación
p de patrón
p EXPERTO

El sistema comprueba
compr eba si ha
hay alguna
alg na copia libre de ese libro

¿Q objeto
¿Qué j ppuede saber si hayy alguna
g copia
p
libre del libro con la signatura proporcionada?
¡
¡Pero no está
cargado en la
El OBJETO de memoria
la clase LIBRO
O
principal! ¡No
sabemos su
referencia!
Ejemplo
j p de aplicación
p de patrón
p EXPERTO

Se comprueba
compr eba qquee el socio no se pasa de ssu número
máximo de libros en préstamo
¿Qué objeto puede saber si el socio con el
número de socio pproporcionado
p no se ppasa de
su número máximo de préstamos?

El OBJETO de
¡Pero no está
la clase SOCIO cargado en la
memoria
principal! ¡No
sabemos su
referencia!
Ejemplo de aplicación de patrón
EXPERTO/CONTROLADOR

¿Qué objeto puede obtener el objeto LIBRO

y el objeto SOCIO, conocidas la signatura y
el número de socio?

El OBJETO que gestiona

l BASE de
la d DATOS
(
(AccesoBD)
)
 Diagrama
g de secuencia TPCL (3)
( )
obj1:
j IU_CU_TPCL :Controlador_
:AccesoBD
L N
LogNegocioi
: ACTOR
1: dar código
libro lib
2: dar código
socio soc
3: pulsar botón
4:tomarPrestamo(lib,soc)
5:l=getLibro(lib)

6:s=getSocio(soc)
 Diagrama de secuencia TPCL (4)
(4)
obj1: IU_CU_TPCL
IU CU TPCL :Controlador_
:AccesoBD
LogNegocio
: ACTOR
1: dar código l: Libro s: Socio
libro lib
2: dar código
socio soc
3: pulsar botón 4:tomarPrestamo
(lib,soc) 5:l=getLibro(lib)

6:s=getSocio(soc)

7:clibre=getCopiaLibre()
7:clibre getCopiaLibre()

[hay clibre] 8: max=isMaximo()

[max] 9: newPrestamo(clibre, s)???
 3 3 2 3 - Patrón
3.3.2.3.-
3.3.2.3. P t ó CREADOR
Nombre: CREADOR
Nombre:
PROBLEMA: ¿Quién
¿Quién debe crear los objetos de una
clase
l A? A
SOLUCIÓN: Esa responsabilidad
p se le añadirá a la
clase B si se cumple alguna de estas condiciones:
condiciones:
 L clase
La l B guarda rd los
l objetos
bj t ded lla clase
l A
 La clase B está formada por objetos de A
(AGREGACIÓN/COMPOSICIÓN)
AG GA Ó / S Ó
 Cuando hay que crear un objeto de A, B tiene todos los
datos de inicialización necesarios
(B es un EXPERTO en la creación de A)
 3.3.2.3.-- Patrón CREADOR
3.3.2.3.

COMPRA ¿Quién crea los objetos de

“Línea_compra”
f h código
fecha, ódi que se guardan
d en “Compra”
“C ”
(o que forman la compra)?
1

1..*

LÍNEA_COMPRA
Í PRODUCTO
* 1
cantidad
valor, descripción
 Ejemplo de aplicación de patrón
CREADOR
Se registra el nuevo préstamo con la fecha actual

¿Qué objeto guarda los

préstamos?

El objeto de la clase
SOCIO

Nota: también podría ser el objeto de la

clase COPIA_LIBRO
 Diagrama
g de secuencia TPCL (5)
( )
obj1: IU_CU_TPCL
IU CU TPCL :Controlador_
:AccesoBD
LogNegocio
: ACTOR
1: dar código l: Libro
libro lib
2: dar código
socio soc
s: Socio
S i
3: pulsar botón 4:tomarPrestamo
(lib,soc) 5:l=getLibro(lib)

6:s=getSocio(soc)

7:clibre=getCopiaLibre()
7:clibre getCopiaLibre()

[hay clibre] 8: max=isMaximo() : Prestamo

[max] 9: newPrestamo(clibre) 10: new()

 Ejemplo de aplicación de patrón
CREADOR (continuación)
Se registra el nuevo préstamo con la fecha actual

¿Qué objeto guarda los

préstamos?

El objeto de la clase ¡¡¡Pero el objeto

¡¡¡ j de AccesoBD
SOCIO también, ya que debe dar
ppersistencia al nuevo
préstamo !!!!
 Diagrama de secuencia TPCL (6)
(
(alternativa 1)
obj1: IU_CU_TPCL
IU CU TPCL :Controlador_
LogNegocio :AccesoBD
: ACTOR
1: dar código l: Libro
libro lib
2: dar código
socio soc
s: Socio
S i
3: pulsar botón 4:tomarPrestamo
(lib,soc) 5:l=getLibro(lib)

6:s=getSocio(soc)

7:clibre=getCopiaLibre()
7:clibre getCopiaLibre()

[hay clibre] 8: max=isMaximo() p: Prestamo

[max] 9: p=newPrestamo(clibre)
11: store(p) 10: new()
 Diagrama de secuencia TPCL (6)
(alternativa 2)
obj1: IU_CU_TPCL
IU CU TPCL :Controlador_
:AccesoBD
LogNegocio
: ACTOR
1: dar código l: Libro
libro lib
2: dar código
socio soc
s: Socio
S i
3: pulsar botón 4:tomarPrestamo
(lib,soc) 5:l=getLibro(lib)

6:s=getSocio(soc)

store(p)
7:clibre=getCopiaLibre()
7:clibre getCopiaLibre()

[hay clibre] 8: max=isMaximo() p: Prestamo

10: newPrestamo(clibre)
11: new()
[no max] 9: newPrestamo(clibre, s)
 ¿Qué alternativa de diseño escoger?
¿ g
:Controlador_ ( l
(alternativa
i 1)
LogNegocio s: Socio
[no max] 9: newPrestamo(clibre) p: Prestamo
Prestamo_CL
CL

10: new()
:AccesoBD

11: store(p)

store(p)

:Controlador_
C l d
LogNegocio s: Socio
:AccesoBD

[no max] 9: newPrestamo(clibre, s) p: Prestamo

10: newPrestamo(clibre)
11: new()

store(p)
(alternativa 2)
 3.3.2.4.-- Patrón BAJO ACOPLAMIENTO
3.3.2.4.
Nombre: BAJO
Nombre: J ACOPLAMIENTO
PROBLEMA: ¿Cómo¿Cómo reducir las
d
dependencias
d i entre clases?
clases
l ?
SOLUCIÓN: Asignar la responsabilidad
de manera que el acoplamiento
permanezca bajo
Existe acoplamiento entre A y B si A usa B
(A tiene atributo del tipo B, o bien un
método que usa o devuelve B,…)
 Ejemplo:
Ejemplo
j p : BAJO ACOPLAMIENTO
(1) (2)

El diseño (2) tiene acoplamiento más bajo:

- En ambos Venta está acoplada a Pago
- En (1) TPV está acoplada a Pago y a Venta
- En
E (2) TPV estátá acoplada
l d aVVenta,
t ¡pero no a P
Pago !
Nota: el nivel de acoplamiento no se puede considerar de manera
aislada a otros patrones como el EXPERTO y el ALTA COHESIÓN
 3.3.2.5.-- Patrón ALTA COHESIÓN
3.3.2.5.
Nombre: ALTA COHESIÓN
Nombre:
PROB MA ¿Cuánto
PROBLEMA: ¿Cuánto
C á están
á relacionadas
l i d las l
responsabilidades
p de una clase
clase?? ¿¿Cómo
Cómo
mantener la complejidad manejable?
manejable?
SOLUCIÓN: Asignar una responsabilidad de
manera que la cohesión permanezca alta alta..
Una clase tiene baja cohesión
cohesión,, si es una clase
que tiene muchas responsabilidades no
relacionadas,, que hace demasiado trabajo
relacionadas trabajo,, que
no delega
delega.. Son clases difíciles de entender
entender,,
reutilizar,, mantener,…
reutilizar mantener,…
 Ejemplo:
Ejemplo
j p : ALTA COHESIÓN
(1) (2)

El diseño (1) tiene una cohesión más baja:

- Tiene una clase (TPV) que se encarga de crear el Pago,
Pago
no ha delegado la creación del Pago en Venta.

Nota: el nivel de cohesión no se puede considerar de manera aislada

a otros patrones como el EXPERTO y el BAJO ACOPLAMIENTO
 ¿Qué
¿ alternativa escoger?
g (1)
( )

 Teniendo en cuenta únicamente los

patrones ALTA COHESIÓN
p
/BAJO ACOPLAMIENTO parece
que la mejor alternativa es la (2)
 Sin
S embargo,
b conviene tener en
cuenta quién tiene la responsabilidad
de p
proporcionar
p la PERSISTENCIA
DE OBJETOS
 ¿Qué
¿ alternativa escoger?
g (2)
( )
 La alternativa (1) sería más interesante si quisiéramos que el
nivel de ACCESO A DATOS no conociera las CLASES
PROVINIENTES DEL MODELO DEL DOMINIO, que
simplemente recuperara o diera persistencia a objetos
objetos..
 E ese caso la
En l cohesión
h ió ded lla clase
l A
AccesoBD
BD sería
í mayor, ya que tendría
dí
menos responsabilidades,
responsabilidades, pero la cohesión de la clase
ControladorLogNegocio sería menor ya que tendría que ocuparse
también de la persistencia de los objetos (pidiéndoselo a AccesoBD
AccesoBD))
 La alternativa (2) sería más interesante si quisiéramos que el nivel de
ACCESO A DATOS conociera i ell MODELO DEL DOMINIO DOMINIO, y
fuera un experto en RECUPERAR, INSERTAR ACTUALIZAR y
BORRAR objetos de la BD).
 La cohesión de la clase AccesoBD sería menor,
menor, ya que tendría más
responsabilidades,, pero a cambio,
responsabilidades cambio, la cohesión del controlador aumentaría
aumentaría,, ya que
l operaciones
las i que implicaran
i li actualizar
actualizar,
li , insertar
i
insertar,
, borrar
b y algunas
l d las
de l dde
recuperar en la BD se las pediría a la clase AccesoBD y no a las clases del
dominio..
dominio
Decisión de diseño para el Acceso a Datos
 Cualquier operación que IMPLIQUE un ACCESO a la BD
(RECUPERACIÓN, INSERCIÓN, ACTUALIZADO O
BORRADO de un objeto de la BD) se enviará al objeto de
la clase ACCESOBD, que será la EXPERTA en
comunicación con el SGBDOO.
SGBDOO
 Solamente cuando el controlador de la lógica del negocio
conozca lal referencia
f i exacta del
d l objeto
bj deld l dominio
d i i all que
quiera preguntar (no modificar,
modificar, insertar o borrar)
borrar) podrá
solicitarle
li i l lal ejecución
j ió de
d algún
l ú método
é d
:Controlador_
(alternativa 2)
LogNegocio
g g :AccesoBD s: Socio

[no max] 9: newPrestamo(clibre, s) p: Prestamo

10 newPrestamo(clibre)
10: P ( lib )
11: new()

store(p)
 Diagrama de clases para el caso de uso
Era la clase IU_CU_TPCL
en el diagrama de secuencia Era la clase Acceso BD com.db4o.*

en el diagrama de secuencia
<<JFrame>>
TomarPrestamoCopia <<Interfaz Remota RMI>>
uses GestorLibro uses
+gestorLibro: GestorLibro Libro

+setLogicaNegocio(GestorLibro) +tomarPrestamo(numSocio, sign) +Copia getCopiaLibre(Socio s)

C i
Copia
DB4o

+abrirBD()
ServidorGestorBiblioBDOO uses +void cerrarBD() Reserva
+inicializarBD()
+tomarPrestamo(numSocio, sign) +Libro
Lib getLibro(String
tLib (St i sign)
i )
+Socio getSocio(int ns)
+void newPrestamo(Socio s, Copia c)
Prestamo

Era la clase Controlador_LogNegocio

g g
Socio

en el diagrama de secuencia +boolean hasReservaDisponible(Libro l)

+boolean isMaximo()