Ejemplo de diagrama de casos de uso: actores, casos de uso, include y extend

Un diagrama de casos de uso responde a una pregunta en una página: ¿quién usa este sistema y para qué? Los product managers lo usan para acordar el alcance, los ingenieros para ver cada punto de entrada a un sistema y los testers para comprobar que cada objetivo tiene un camino. También es uno de los diagramas UML que más se dibujan mal: se convierte en un diagrama de flujo, cada botón acaba como caso de uso o include y extend se usan al revés.

Este artículo explica la notación tal como la define la especificación UML 2.5.1, resuelve include frente a extend con una prueba sencilla, desarrolla un ejemplo completo para una app de pedidos de comida, muestra el texto que debería haber detrás de cada óvalo y enumera los errores que hacen inútiles los diagramas de casos de uso.

La notación

El sentido de las flechas viene directamente de la especificación UML 2.5.1, publicada por el OMG en diciembre de 2017: include apunta del caso de uso base al incluido; extend apunta del caso que extiende al caso que extiende. La especificación también permite puntos de extensión, lugares con nombre del caso base donde puede engancharse una extensión, listados dentro del óvalo.

Include frente a extend: una sola prueba

Pregúntate si el caso de uso base está completo sin el otro.

• No está completo sin él: include. Hacer un pedido siempre implica cobrar. «Place order» incluye «Pay for order». La flecha apunta a lo incluido, y el caso base no puede ejecutarse sin ello.
• Está completo sin él: extend. Aplicar un código promocional es opcional; un pedido es perfectamente válido sin código. «Apply promo code» extiende «Place order», en un punto de extensión como «antes del pago», cuando el cliente tiene un código. La flecha apunta al caso base, que ni siquiera sabe que la extensión existe.

Dos reglas más evitan la mayoría de los abusos:

• Usa include para compartir comportamiento que necesitan varios casos de uso, como la autenticación o el pago. No lo uses para partir un caso de uso en pasos; eso es un diagrama de flujo.
• Usa extend con moderación. Si tienes más extends que casos de uso base, estás documentando opciones de interfaz, no objetivos.

Los actores son roles

Un actor es un rol, no una persona ni un puesto de trabajo. La misma persona puede ser cliente por la mañana y gerente de restaurante por la tarde. Los actores también pueden ser sistemas: un proveedor de pagos al que la app llama para autorizar una tarjeta es un actor de apoyo. Algunos equipos modelan los trabajos programados con un actor «Time», una convención habitual para los casos de uso que nadie inicia a mano.

Por convención, los actores principales, que inician casos de uso para alcanzar sus objetivos, van a la izquierda, y los actores de apoyo, a los que recurre el sistema, a la derecha.

Nombrar los casos de uso al nivel adecuado

Nombra los casos de uso con verbo y objeto, desde el punto de vista del actor: «Hacer pedido», no «Pedido», «Pantalla de pedido» ni «Botón Enviar». Cada uno debe ser un objetivo que el actor pueda completar en una sola sesión y que se alegraría de haber alcanzado, lo que Alistair Cockburn llama el nivel del mar de los objetivos de usuario. Los niveles más altos («Gestionar el restaurante») son demasiado amplios para un óvalo; los más bajos («Introducir el número de tarjeta») son pasos dentro de un caso de uso.

Un ejemplo resuelto: pedidos de comida

El diagrama de abajo muestra una app de pedidos de comida con cuatro actores:

• Customer consulta el menú, hace pedidos y sigue las entregas.
• Restaurant staff acepta pedidos.
• Courier entrega pedidos.
• Payment provider, un sistema externo, apoya el pago.

Y siete casos de uso dentro del límite:

1. Browse menu
2. Place order, que incluye Pay for order
3. Pay for order, que apoya el proveedor de pagos
4. Apply promo code, que extiende Place order antes del pago
5. Track delivery
6. Accept order
7. Deliver order

Fíjate en lo que no está en el diagrama: ningún orden de pasos, ninguna pantalla, ningún óvalo «Log in» para cada actor. La autenticación es una precondición, no un objetivo; va en las descripciones o, si tiene comportamiento real, en un único caso de uso incluido.

La descripción detrás de cada óvalo

El diagrama es un índice. El valor está en una descripción breve por caso de uso, por ejemplo:

Use case: Place order
Primary actor: Customer
Precondition: The customer is signed in and the basket is not empty.

Main success scenario:
  1. Customer reviews the basket and delivery address.
  2. System shows the total, including fees and estimated delivery time.
  3. Customer confirms the order.
  4. System takes payment (includes: Pay for order).
  5. System sends the order to the restaurant and confirms it to the customer.

Extensions:
  2a. Customer has a promo code: Apply promo code, then continue at step 2.
  4a. Payment is declined: System asks for another payment method.
  5a. Restaurant does not accept within 5 minutes: System cancels and refunds.

Postcondition: The order is paid and visible to the restaurant.

Las extensiones de la descripción, las ramas numeradas de «y si», son de donde salen los requisitos y los casos de prueba. Son mucho más detalladas que las relaciones extend del diagrama, que solo debería mostrar los objetivos opcionales que merecen un dibujo.

Errores comunes

• Un diagrama de flujo disfrazado. Las flechas entre casos de uso que significan «después» convierten el diagrama en un modelo de proceso. Para el orden del trabajo, usa un diagrama BPMN o un diagrama de actividades.
• Un caso de uso por operación CRUD. «Crear plato», «Actualizar plato» y «Eliminar plato» suelen ser un solo objetivo: «Gestionar menú».
• Pantallas y botones como casos de uso. «Pulsar Pagar» es un paso, no un objetivo.
• Include para descomponer. Si cada caso de uso incluye otros tres, el diagrama describe la estructura del código, no los objetivos del usuario.
• Componentes internos como actores. La base de datos no es un actor; está dentro del sistema. Los sistemas externos a los que llamas sí lo son.
• Sin límite. Sin el rectángulo del sujeto, los lectores no pueden distinguir lo que construyes de aquello de lo que dependes.

Diagramas de casos de uso, historias de usuario y diagramas de secuencia

Funcionan juntos: el diagrama de casos de uso traza el mapa del territorio, las historias lo cortan en piezas entregables y un diagrama de secuencia muestra cómo se ejecuta de verdad un escenario.

El diagrama de casos de uso

Cómo leerlo:

• El rectángulo es el límite del sistema: todo lo que hay dentro es la app de pedidos de comida.
• Los actores de la izquierda inician casos de uso: el cliente tiene tres objetivos; el personal del restaurante y los repartidores, uno cada uno.
• El proveedor de pagos de la derecha es un sistema de apoyo al que la app llama durante el pago.
• La flecha «include» de Place order a Pay for order significa que el pago siempre ocurre. La flecha «extend» de Apply promo code a Place order significa que el código promocional es opcional.
• El bloque Markdown es una clave de notación para quien empieza con UML.

Dibujar diagramas de casos de uso que la gente lea de verdad

• Quédate por debajo de unos 15 casos de uso por diagrama. Si un sistema tiene más, divídelo por actor o por subsistema.
• Pon los actores principales a la izquierda y los de apoyo a la derecha, para que la dirección de lectura coincida con quién inicia qué.
• Etiqueta include y extend de forma explícita, con las comillas angulares, y mantén las flechas discontinuas.
• Deja los detalles para las descripciones. El diagrama debe caber en una diapositiva; el texto puede ser tan largo como haga falta.

Los diagramas de casos de uso combinan bien con las otras vistas UML: el ejemplo de diagrama de clases UML para el modelo de dominio y el ejemplo de diagrama de estados para el ciclo de vida de un pedido.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade un Marco del pack Básico llamado Food ordering app como límite del sistema.
3. Añade dentro del marco siete nodos Caso de uso del pack UML, con los nombres de arriba.
4. Añade cuatro nodos Actor del pack UML: Customer, Restaurant staff y Courier a la izquierda, Payment provider a la derecha.
5. Conecta los actores con sus casos de uso mediante líneas simples. Añade aristas discontinuas con la etiqueta «include» de Place order a Pay for order y «extend» de Apply promo code a Place order.
6. Añade un bloque Markdown del pack Básico con una clave de notación breve.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué diferencia hay entre include y extend en un diagrama de casos de uso? Include significa que el caso de uso base siempre ejecuta el comportamiento incluido, y la flecha apunta al caso incluido. Extend significa comportamiento opcional añadido bajo una condición, y la flecha apunta de la extensión al caso de uso base.

¿Un actor puede ser un sistema? Sí. Cualquier rol externo que interactúe con el sistema puede ser un actor, incluido otro software como un proveedor de pagos. Los componentes internos de tu sistema no son actores.

¿Las flechas deberían conectar actores con casos de uso? UML usa líneas de asociación simples entre actores y casos de uso. Algunos equipos añaden puntas de flecha para indicar quién inicia, pero la notación estándar no lo exige.

¿Cuántos casos de uso debería tener un diagrama? Como orientación, no más de unos 15. Los sistemas más grandes se leen mejor como varios diagramas, divididos por actor o por subsistema.

¿Los diagramas de casos de uso muestran el orden de los pasos? No. Muestran objetivos, no secuencias. El orden de los pasos va en las descripciones de casos de uso, en los diagramas de actividades o en los diagramas de secuencia.

Empieza gratis — un puesto, sin tarjeta de crédito.