Diagrama de secuencia
En un diagrama
de secuencia ponemos
varios de los objetos o clases que forman parte de nuestro programa y ponemos
qué llamadas van haciendo unos a otros para realizar una tarea determinada.
Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo
que llamo sub caso de uso). En nuestro ejemplo
de ajedrez, podemos hacer diagramas de secuencia para "jugar partida"
o bien para partes de "jugar partida", como puede ser "mover
pieza".
El detalle del diagrama depende de la fase en la que estemos, lo
que pretendamos contar con el diagrama y a quién. En una primera fase de diseño
podemos poner clases grandes y ficticias, que representen un paquete/librería
o, si nuestro programa está compuesto por varios ejecutables corriendo a la
vez, incluso clases que representen un ejecutable.
Si estamos en una fase avanzada, estamos diseñando el programa y
queremos dejar bien atados los detalles entre dos programadores, que cada uno
va a programar una de las clases que participan, entonces debemos posiblemente
ir al nivel de clase real de codificación y método, con parámetros y todo, de
forma que los programadores tengan claro que métodos van a implementar, que
deben llamar de la clase del otro, etc. Incluso si es un diagrama para
presentar al cliente, podemos hacer un diagrama de secuencia en el que sólo
salga el actor "jugador" y una única clase "juego ajedrez"
que representa nuestro programa completo, de forma que el cliente vea qué datos
y en qué orden los tiene que meter en el programa y vea qué salidas y
resultados le va a dar el programa.
El siguiente puede ser un diagrama de secuencia de
nuestro ejemplo del ajedrez a un nivel de diseño muy preliminar
Aquí ya hemos decidido que
vamos a hacer tres librerías/paquetes, una para la interface de usuario, otra
para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y
otra para el algoritmo de juego del ordenador. Hemos puesto una clase
representando cada uno de los paquetes y hemos representado el caso de usa
"mover pieza".
En el diagrama de secuencia no se ponen situaciones erróneas
(movimientos inválidos, jaques, etc.) puesto que poner todos los detalles puede
dar lugar a un diagrama que no se entiende o difícil de leer. El diagrama puede
acompañarse con un texto en el que se detallen todas estas situaciones erróneas
y particularidades. Si se quiere dejar muy claro que un determinado error se
contempla, por ejemplo, un movimiento no válido por el usuario, entonces sí se
puede poner en el diagrama de secuencia, siempre que no "embarulle"
demasiado.
En este diagrama sencillo ya vamos dejando algunas cosas claras,
como por ejemplo, que la interface de usuario hace llamadas y, por tanto, ve a
los otros dos, mientras que algoritmo sólo ve al tablero/reglas. El
tablero/reglas aparentemente ve a la interface de usuario, pero no nos interesa
si seguimos un patrón
modelo-vista-controlador, así que ese "Refresca pantalla" lo
implementaremos con un patrón
observador, pero eso son detalles que quizás no vienen al caso ahora.
