Ejemplos de diagramas de casos de uso

La biblioteca es el primer ejemplo estándar por una razón: todo el mundo conoce ya el dominio, así que lo único que queda por mirar es la notación. Dos actores, cinco casos de uso, y una frontera que dice de cuáles es responsable el software.

Fíjate en qué son las elipses. Tomar prestado un libro es un objetivo - un socio quiere marcharse con un libro - y sigue siendo un objetivo tanto si el mostrador es una persona, un quiosco de autoservicio o una aplicación. Esa independencia del mecanismo es la prueba de un caso de uso: si sustituir la interfaz cambiaría la etiqueta, la etiqueta es un paso.

Dos relaciones hacen trabajo de verdad. Comprobar la membresía está incluida por Tomar prestado un libro, lo que significa que siempre ocurre como parte de él, y la flecha va del préstamo al comportamiento incluido. No tiene actor propio, y eso es correcto: nadie llega a la biblioteca queriendo que le comprueben la membresía. Pagar una multa por retraso extiende Devolver un libro: ocurre solo a veces, y la flecha va al revés, del comportamiento opcional a la base.

El segundo ejemplo añade la pieza que la mayoría de los primeros diagramas deja fuera: un sistema del que dependes y que no controlas.

La Payment gateway es un actor secundario. No inicia nada - en este diagrama todo lo empieza el cliente - pero el sistema la llama, así que va fuera de la frontera con una línea hacia el caso de uso que la necesita. Dibujarla es lo que hace que un diagrama de casos de uso se gane su sitio en una conversación de alcance: la frontera muestra ahora exactamente de qué comportamiento respondes tú y cuál estás comprando.

Aplicar un código de descuento extiende Realizar un pedido porque la mayoría de los pedidos no lo llevan. Si casi todos lo llevaran, sería un include en su lugar. La pregunta no es si el comportamiento es importante, sino si ocurre siempre.

Cuatro elipses es un tamaño razonable. Una tienda real tiene cientos de comportamientos, y el diagrama no crece con ellos: dibujas uno por conversación, acotado a la pregunta que se está haciendo, que es la disciplina de la que va acotar un modelo.

La mayoría de los diagramas de casos de uso malos lo son exactamente de una forma, y vale la pena verla una vez.

Cuatro elipses, un actor, una frontera, ni un solo error de notación, y el diagrama no vale nada. Cada etiqueta es un paso de una interfaz en vez de un objetivo que tiene una persona. Nadie quiere escribir un nombre de usuario; quiere iniciar sesión, y hasta eso suele ser solo al servicio de otra cosa.

El diagrama entero se reduce a un único caso de uso, y los cuatro pasos pertenecen a su descripción textual o, si la ramificación importa de verdad, a un diagrama de actividad. Esa es la reparación estándar: la secuencia se va a actividad, los objetivos se quedan aquí.

Los dos diagramas buenos de arriba son el mismo diagrama con otros sustantivos, y eso es lo útil de esta notación: en cuanto tienes la forma en la mano, el siguiente lleva diez minutos.