Diagramas de Casos de Uso: Una Guía Práctica

Un diagrama de casos de uso es un diagrama de comportamiento UML que muestra cómo los usuarios externos o los sistemas interactúan con un sistema. Se centra en lo que hace el sistema desde la perspectiva de un actor, no en los detalles de implementación interna.

Los diagramas de casos de uso son especialmente útiles durante el análisis de requisitos porque proporcionan una visión de alto nivel de la funcionalidad y el alcance del sistema.

1. Lo que muestra un diagrama de casos de uso

Un diagrama de casos de uso típicamente contiene:

• Límite del sistema — define qué está dentro del sistema que se está modelando.

• Actores — usuarios externos, organizaciones, dispositivos o sistemas que interactúan con él.

• Casos de uso — objetivos o servicios que proporciona el sistema.

• Asociaciones — enlaces de comunicación entre actores y casos de uso.

• Relaciones entre casos de uso — como <<incluir>> y <<extender>>.

• Generalización — herencia entre actores o casos de uso.

Un diagrama de casos de uso normalmente no muestra:

• Pasos del algoritmo

• Tablas de base de datos

• Clases de programa

• Flujos de trabajo internos

• Diseños detallados de la interfaz de usuario

• Secuencias de mensajes a lo largo del tiempo

Esos detalles se representan mejor con diagramas de actividad, clase, secuencia o estado.

2. Conceptos clave

Límite del sistema

El límite del sistema es un rectángulo que rodea los casos de uso que pertenecen al sistema.

Por ejemplo, en un sistema de compras en línea:

+--------------------------------------+
|        Sistema de Compras en Línea   |
|                                      |
|  (Explorar Productos)                |
|  (Realizar Pedido)                   |
|  (Realizar Pago)                     |
+--------------------------------------+

Los actores permanecen fuera del límite porque son externos al sistema.

El límite ayuda a aclarar el alcance del sistema. Si una capacidad está fuera del límite, no es implementada por el sistema que se está modelando.

Actores

Un actor es cualquier cosa externa que interactúa con el sistema para lograr un objetivo.

Los actores pueden incluir:

• Usuarios humanos

• Aplicaciones externas

• Dispositivos de hardware

• Otras organizaciones

• Tiempo o eventos programados, cuando se modelan como disparadores externos

Ejemplos:

• Cliente

• Bibliotecario

• Pasarela de pago

• Administrador

• Servicio de correo electrónico

Un actor representa un rol, no necesariamente una persona específica. Por ejemplo, «Cliente» suele ser mejor que «Alex».

Los actores pueden ser:

• Actores principales— inician interacciones para lograr un objetivo.

• Actores de soporte— proporcionan servicios al sistema.

Por ejemplo, un cliente puede iniciar «Realizar Pedido», mientras que una pasarela de pago da soporte a «Procesar Pago».

Casos de uso

Un caso de usorepresenta un objetivo significativo o un servicio proporcionado por el sistema.

Los nombres adecuados de los casos de uso suelen seguir esta forma:

Verbo + objeto

Ejemplos:

• Registrar cuenta

• Buscar en el catálogo

• Presentar solicitud

• Generar informe

• Cancelar reserva

• Procesar pago

Un caso de uso debe describir un resultado observable, en lugar de un paso de implementación interna.

Preferir:

Realizar pedido

en lugar de:

Validar objeto de pedido

El segundo describe una operación interna en lugar de un objetivo del usuario.

Asociaciones

Una asociación es un enlace de comunicación entre un actor y un caso de uso.

Indica que el actor participa o inicia el caso de uso.

Cliente ---- (Realizar pedido)

Las asociaciones normalmente no indican secuencia, flujo de control o dirección. Si el orden de las interacciones es importante, utilice un diagrama de secuencia o de actividad.

3. Relaciones entre casos de uso

<<include>>

Utilice <<include>> cuando un caso de uso siempre utiliza otro caso de uso.

Por ejemplo, realizar un pedido puede requerir siempre autenticación:

(Realizar Pedido) ..> (Autenticar Cliente) : <<include>>

El caso de uso base depende del caso de uso incluido.

Utilice include cuando:

• El comportamiento es obligatorio.

• El comportamiento es reutilizado por múltiples casos de uso.

• Extraer el comportamiento mejora la claridad.

Ejemplo:

(Retirar Efectivo) ..> (Autenticar Tarjeta) : <<include>>
(Consultar Saldo) ..> (Autenticar Tarjeta) : <<include>>

Ambos casos de uso siempre requieren autenticación de tarjeta.

<<extend>>

Utilice <<extend>> cuando un comportamiento adicional es opcional o se inserta condicionalmente en un caso de uso base.

(Aplicar Descuento) ..> (Realizar Pedido) : <<extend>>

El comportamiento de descuento ocurre solo cuando se cumplen las condiciones de elegibilidad.

Utilice extend cuando:

• El comportamiento es opcional.

• Ocurre solo bajo una condición.

• El caso de uso base está completo sin él.

Ejemplos:

• “Agregar envoltura de regalo” extiende “Realizar pedido.”

• “Solicitar reembolso” extiende “Cancelar suscripción.”

• “Enviar correo promocional” extiende “Completar registro.”

La flecha apunta desde el caso de uso extendido hacia el caso de uso base.

Generalización

La generalización representa una relación de “es-un” entre actores o casos de uso.

Por ejemplo:

Cliente Premium --|> Cliente

Un cliente premium es un tipo de cliente y hereda las interacciones del cliente.

La generalización de actores puede ser útil cuando varios actores comparten comportamiento común:

Administrador --|> Empleado
Bibliotecario --|> Empleado

Use la generalización con moderación. Si la relación es simplemente “usa” o “participa en”, una asociación suele ser más apropiada.

4. Actores principales y de apoyo

Considere un escenario de pago en línea:

• El Cliente es el actor principal porque inicia la compra.

• El Pasarela de pago es un actor de apoyo porque procesa el pago a solicitud del sistema.

Un modelo simple podría verse así:

Cliente ---- (Realizar pedido)
(Realizar pedido) ---- Pasarela de pago

La distinción es útil porque aclara quién se beneficia del caso de uso y qué sistemas externos están involucrados.

5. Cómo identificar casos de uso

Una forma práctica de descubrir casos de uso es preguntar:

1. ¿Quién usa el sistema?

2. ¿Qué objetivo quiere lograr cada actor?

3. ¿Qué servicios proporciona el sistema?

4. ¿Qué eventos desencadenan el comportamiento del sistema?

5. ¿Con qué sistemas externos debe interactuar el sistema?

6. ¿Qué comportamiento es siempre requerido?

7. ¿Qué comportamiento es opcional o condicional?

Para cada actor, liste sus objetivos:

El objetivo debe ser significativo para el actor. Evite convertir cada pequeña operación del sistema en un caso de uso.

6. Directrices de nomenclatura

Utilice nombres claros y orientados a objetivos.

Buenos ejemplos:

• Crear cuenta

• Actualizar perfil

• Presentar Reclamación

• Rastrear Envío

• Aprobar Solicitud

• Generar Factura

Evitar nombres vagos:

• Procesamiento del Sistema

• Gestionar Datos

• Función de Usuario

• Ejecutar Operación

Evitar detalles técnicos excesivos:

• Ejecutar Consulta SQL

• Llamar a un Punto de Extremo REST

• Instanciar PaymentService

Estos pueden ser pasos de implementación válidos, pero generalmente no son útiles como casos de uso de alto nivel.

7. Ejemplo: Sistema de Gestión de Biblioteca

Supongamos que un sistema de biblioteca soporta:

• Miembros buscando libros

• Miembros prestando libros

• Miembros devolviendo libros

• Bibliotecarios gestionando el catálogo

• Notificaciones de vencimiento

• Procesamiento de pagos por multas

Actores posibles:

• Miembro

• Bibliotecario

• Servicio de Notificaciones

• Servicio de Pagos

Casos de uso posibles:

• Buscar en el Catálogo

• Pedir Libro

• Devolver libro

• Calcular multa

• Pagar multa

• Gestionar catálogo

• Enviar notificación de vencimiento

Relaciones:

• Pedir libro incluye Verificar membresía.

• Pedir libro incluye Verificar disponibilidad del libro.

• Devolver libro incluye Calcular multa.

• Pagar multa interactúa con el Servicio de Pagos.

• Enviar notificación de vencimiento interactúa con el Servicio de Notificaciones.

8. Ejemplo de PlantUML

El siguiente código de PlantUML crea un diagrama de casos de uso para el sistema de biblioteca:

@startuml
dirección de izquierda a derecha

título Sistema de Gestión de Biblioteca - Diagrama de Casos de Uso

actor Miembro
actor Bibliotecario
actor "Servicio de Notificaciones" como Notificación
actor "Servicio de Pagos" como Pago

rectángulo "Sistema de Gestión de Biblioteca" {

  usecase "Buscar catálogo" como UC_Buscar
  usecase "Pedir libro" como UC_Pedir
  usecase "Devolver libro" como UC_Devolver
  usecase "Verificar membresía" como UC_VerificarMembresía
  usecase "Verificar disponibilidad del libro" como UC_VerificarDisponibilidad
  usecase "Calcular multa" como UC_CalcularMulta
  usecase "Pagar multa" como UC_PagarMulta
  usecase "Gestionar catálogo" como UC_GestionarCatálogo
  usecase "Enviar notificación de vencimiento" como UC_Notificar
}

Miembro --> UC_Buscar
Miembro --> UC_Pedir
Miembro --> UC_Devolver
Miembro --> UC_PagarMulta

Bibliotecario --> UC_GestionarCatálogo
Bibliotecario --> UC_Pedir
Bibliotecario --> UC_Devolver

Pago --> UC_PagarMulta
Notificación --> UC_Notificar

UC_Pedir ..> UC_VerificarMembresía : <<include>>
UC_Pedir ..> UC_VerificarDisponibilidad : <<include>>
UC_Devolver ..> UC_CalcularMulta : <<include>>

UC_Notificar ..> UC_Devolver : <<extend>>

@enduml

9. Explicación del ejemplo

Actores

actor Miembro
actor Bibliotecario
actor "Servicio de Notificaciones" como Notificación
actor "Servicio de Pagos" como Pago

El diagrama modela dos actores humanos y dos servicios externos.

Alias como como Notificación hacen que los nombres largos sean más fáciles de referenciar más adelante.

Límite del sistema

rectángulo "Sistema de Gestión de Biblioteca" {
    ...
}

El rectángulo define el alcance del sistema. Los casos de uso dentro del rectángulo son proporcionados por el sistema de biblioteca.

Asociaciones de Actores

Miembro --> UC_Búsqueda
Miembro --> UC_Prestar

Estas asociaciones muestran que un miembro puede buscar en el catálogo y prestar libros.

La dirección de la flecha no suele ser semánticamente importante en un diagrama de casos de uso básico. Se utiliza principalmente para hacer que el diagrama sea legible.

Relaciones de Inclusión

UC_Prestar ..> UC_ComprobarMiembro : <<include>>
UC_Prestar ..> UC_ComprobarDisponibilidad : <<include>>

Prestar un libro siempre requiere comprobaciones de membresía y disponibilidad, por lo que estos se modelan como casos de uso incluidos.

Relación de Extensión

UC_Notificar ..> UC_Retornar : <<extend>>

Esto indica que el comportamiento de notificación de vencimiento es un comportamiento adicional asociado con la devolución de un libro.

Sin embargo, en un modelo de requisitos real, un diseño más natural podría ser asociar “Enviar Notificación de Vencimiento” con un proceso programado o un actor como “Programador de Biblioteca”. La mejor relación depende de las reglas de negocio reales.

10. Especificación de Caso de Uso Más Detallada

Un diagrama ofrece una visión general, pero cada caso de uso importante debería tener usualmente una especificación textual.

Caso de Uso: Prestar Libro

Un diagrama de casos de uso no debe intentar contener todos estos detalles. El diagrama proporciona el mapa; la especificación proporciona el comportamiento.

11. Referencia de sintaxis de PlantUML

Declaración de actores

actor Cliente
actor "Pasarela de pago" como Gateway

Declaración de casos de uso

usecase "Realizar pedido" como PlaceOrder
usecase "Procesar pago" como ProcessPayment

Crear un límite del sistema

rectángulo "Tienda en línea" {
    caso de uso "Navegar por productos" como Navegar
    caso de uso "Realizar pedido" como Pedido
}

Conectar actores y casos de uso

Cliente --> Navegar
Cliente --> Pedido

Incluir

Pedido ..> ProcesarPago : <<incluir>>

Extender

AplicarCupón ..> Pedido : <<extender>>

Generalización de actores

ClientePremium --|> Cliente

Agrupación por paquetes

Los paquetes pueden agrupar visualmente casos de uso relacionados:

rectángulo "Sistema Bancario" {
  paquete "Gestión de Cuentas" {
    caso de uso "Abrir Cuenta" como AbrirCuenta
    caso de uso "Cerrar Cuenta" como CerrarCuenta
  }

  paquete "Pagos" {
    caso de uso "Transferir Fondos" como TransferirFondos
    caso de uso "Pagar Factura" como PagarFactura
  }
}

Notas

nota a la derecha de PlaceOrder
  El cliente debe estar autenticado
  antes de realizar un pedido.
fin nota

12. Mejora del diseño del diagrama

PlantUML organiza automáticamente los diagramas, pero varias técnicas mejoran la legibilidad.

Controlar la dirección

dirección de izquierda a derecha

Esto es útil cuando los actores deben aparecer en los lados y los casos de uso en el centro.

Otras direcciones comunes incluyen:

dirección de arriba a abajo

Usar alias

En lugar de repetir nombres largos:

usecase "Verificar identidad del cliente" como VerifyIdentity

Luego referenciar:

RegisterAccount ..> VerifyIdentity : <<include>>

Agrupar Casos de Uso Relacionados

Use paquetes o rectángulos anidados para separar áreas funcionales:

package "Gestión de Pedidos" {
    usecase "Crear Pedido" as CreateOrder
    usecase "Cancelar Pedido" as CancelOrder
}

Evitar Cruces Excesivos

Un diagrama se vuelve difícil de leer cuando demasiadas líneas se cruzan. Puedes mejorarlo mediante:

• Colocar actores relacionados cerca de sus casos de uso

• Agrupar casos de uso en paquetes

• Dividir un diagrama grande en varios diagramas más pequeños

• Usar alias para referencias claras

• Evitar relaciones innecesarias

13. Errores Comunes

Modelar Funciones Internas como Casos de Uso

Esto suele ser demasiado técnico:

Validar Conexión a Base de Datos
Serializar Solicitud
Llamar a la API de Pago

Prefiera objetivos con significado externo:

Realizar Pago
Enviar Solicitud
Generar Informe

Tratar a Cada Actor como una Persona

Los sistemas y dispositivos externos también pueden ser actores:

• Pasarela de Pago

• Proveedor de Identidad

• Sistema de Almacén

• Escáner de Código de Barras

• Servicio de Notificación

Usar incluyepara Comportamiento Opcional

Si el comportamiento es opcional, use extender en lugar de incluir.

Incorrecto:

Realizar Pedido ..> Aplicar Cupón : <<incluir>>

Si aplicar un cupón es opcional, use:

Aplicar Cupón ..> Realizar Pedido : <<extender>>

Usando extender para Comportamiento Obligatorio

Si un comportamiento siempre ocurre, generalmente debe modelarse con incluir.

Realizar Pedido ..> Autenticar Cliente : <<incluir>>

Conectar Casos de Uso Directamente Sin Sentido

Una línea entre dos casos de uso debe representar una relación UML válida. Evite conexiones arbitrarias que simplemente impliquen que los casos de uso están de alguna manera relacionados.

Crear Un Solo Diagrama Gigante

Un diagrama de casos de uso debe comunicar claramente a un nivel alto. Si contiene docenas de actores y casos de uso, cree varios diagramas organizados por subsistema o área de negocio.

Mostrar Secuencia

Un diagrama de casos de uso no muestra que un caso de uso ocurra antes que otro. Para la secuencia, use un diagrama de secuencia o un diagrama de actividad.

14. Cuándo Usar Otros Diagramas UML

Los diagramas de casos de uso son mejores para el alcance del sistema y los objetivos del usuario. Combínelos con otros diagramas cuando se necesite más detalle:

15. Proceso de modelado recomendado

1. Defina el límite del sistema.

2. Identifique todos los actores externos.

3. Identifique los objetivos de cada actor.

4. Convierta esos objetivos en casos de uso.

5. Conecte los actores a los casos de uso en los que participan.

6. Identifique el comportamiento reutilizable obligatorio y modeléelo con <<include>>.

7. Identifique el comportamiento opcional o condicional y modeléelo con <<extend>>.

8. Agregue generalización solo donde exista una relación genuina de “es-un”.

9. Revise el diagrama con las partes interesadas.

10. Agregue especificaciones textuales para los casos de uso importantes.

11. Divida el diagrama si se vuelve abigarrado.

16. PlantUML compacto

Puede usar esto como punto de partida:

@startuml
dirección de izquierda a derecha

título Diagrama de casos de uso del sistema

actor Usuario
actor "Sistema externo" como SistemaExterno

rectángulo "Nombre del sistema" {
  usecase "Objetivo principal del usuario" como ObjetivoPrincipal
  usecase "Comportamiento compartido requerido" como ComportamientoRequerido
  usecase "Comportamiento opcional" como ComportamientoOpcional
}

Usuario --> ObjetivoPrincipal
SistemaExterno --> ObjetivoPrincipal

ObjetivoPrincipal ..> ComportamientoRequerido : <<include>>
ComportamientoOpcional ..> ObjetivoPrincipal : <<extend>>

@enduml

El principio central es modelar objetivos visibles externamente, no detalles de implementación interna. Un diagrama de casos de uso sólido hace que el límite del sistema, los actores, las capacidades y las dependencias importantes sean inmediatamente comprensibles.

Referencia