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 subcaso 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étdos 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
No hay comentarios:
Publicar un comentario