De los requisitos a un diagrama de casos de uso UML

Un diagrama de casos de uso es la vista de más alto nivel de un sistema en UML. Muestra las personas y los sistemas externos que interactúan con él, llamados actores, y los objetivos que pueden lograr, llamados casos de uso. Deja fuera a propósito las pantallas, los datos y el orden de los pasos.

Esa sencillez explica por qué aparece tan pronto en los proyectos y en tantos cursos de ingeniería de software: todos comparten la misma lista de lo que el sistema debe hacer antes de discutir cómo. Un generador de diagramas de casos de uso ahorra el tiempo de dibujo para que la conversación empiece antes.

Empieza por los usuarios. Nombra cada tipo de usuario y lo principal que quiere hacer, por ejemplo "los clientes buscan productos y hacen pedidos". Después nombra los sistemas externos con los que se comunica el software, como un proveedor de pagos, un servicio de correo o una base de datos del gobierno.

Menciona los pasos que comparten varios objetivos, como iniciar sesión o consultar un saldo, para que se conviertan en relaciones include. El comportamiento opcional, como aplicar un código de descuento, se convierte en una relación extend. Las frases cortas y directas funcionan mejor que una especificación larga.

Mira primero el límite: los actores deben quedar fuera y los casos de uso dentro. Luego comprueba que cada actor se conecte al menos con un caso de uso y que cada caso de uso sea un objetivo y no un simple clic. "Pagar pedido" es un buen caso de uso; "Pulsar el botón de pago" es demasiado pequeño.

Después revisa las flechas discontinuas. Un include va del caso de uso principal al paso compartido, y un extend va del comportamiento opcional al caso de uso que amplía. Si una dirección parece incorrecta, corrígela en el editor o pide a la IA que la invierta.

Un diagrama de casos de uso dice qué hace el sistema, pero no cómo. Para el orden de los mensajes dentro de un caso de uso, como un inicio de sesión o un pago, dibuja un diagrama de secuencia. Para los datos que hay detrás, un diagrama ER, y para la estructura del código, un diagrama de clases.

Este sitio tiene un generador para cada una de esas vistas, y todos producen archivos de Draw.io que se abren en el mismo editor. Escribir una descripción y reutilizarla en varios tipos de diagrama mantiene los nombres coherentes desde los requisitos hasta el diseño.