Los diagramas de casos de uso son una herramienta esencial en el modelado de sistemas software, especialmente útiles en la fase de análisis de requerimientos del ciclo de vida del software. Forman parte del lenguaje UML (Unified Modeling Language) y sirven para representar las funcionalidades de un sistema desde la perspectiva del usuario.
En este artículo, te explicaremos:
- Qué son los diagramas de casos de uso y por qué son importantes.
- Elementos clave que los componen.
- Cómo crearlos fácilmente usando PlantUML (con ejemplos prácticos).
¿Qué es un Diagrama de Casos de Uso?
Un diagrama de casos de uso es una representación visual de las interacciones entre los usuarios (actores) y un sistema. Su objetivo es:
- Identificar requisitos funcionales.
- Clarificar el alcance del sistema.
- Facilitar la comunicación entre desarrolladores y stakeholders.
¿Cuándo se Usan?
- En la fase de análisis de requisitos, para entender qué debe hacer el sistema.
- Durante el diseño, para refinar flujos de interacción.
Elementos de un Diagrama de Casos de Uso
Elemento | Símbolo | Descripción |
---|---|---|
Actor | 🧑 (Figura humana) | Representa un usuario o sistema externo que interactúa con el software. |
Caso de Uso | ⚪ (Elipse) | Funcionalidad específica que el sistema ofrece (ej: «Iniciar sesión»). |
Relación | ➖ (Línea continua) | Conexión entre un actor y un caso de uso. |
Include | 🏷️ <<include>> | Indica que un caso de uso debe ejecutar otro (dependencia obligatoria). |
Extend | 🏷️ <<extend>> | Muestra una funcionalidad opcional (ej: «Recuperar contraseña»). |
✅ Ejemplo rápido: Si estás diseñando una app para tomar apuntes, un actor sería “Usuario” y un caso de uso sería “Crear nota”.
¿Qué es PlantUML y por qué usarlo?
PlantUML es una herramienta que permite crear diagramas UML usando un lenguaje de texto muy sencillo. Ventajas:
- No necesitas arrastrar ni soltar elementos.
- Puedes versionar tus diagramas con Git.
- ¡Ideal para programadores que prefieren escribir en lugar de dibujar!
Puedes usarlo en casi cualquier IDE con la extensión PlantUML, aunque también existen editores en línea.
Cómo hacer un diagrama de casos de uso en PlantUML
Ejemplo básico
@startuml
left to right direction
actor Usuario
usecase "Crear nota" as UC1
usecase "Editar nota" as UC2
usecase "Eliminar nota" as UC3
Usuario --> UC1
Usuario --> UC2
Usuario --> UC3
@enduml
Este diagrama muestra que un Usuario puede crear, editar y eliminar notas. Simple y claro.
Agregando más actores y relaciones
@startuml
left to right direction
actor Usuario
actor Administrador
usecase "Iniciar sesión" as UC1
usecase "Crear nota" as UC2
usecase "Eliminar nota" as UC3
usecase "Gestionar usuarios" as UC4
Usuario --> UC1
Usuario --> UC2
Usuario --> UC3
Administrador --> UC1
Administrador --> UC4
@enduml
Aquí vemos dos tipos de usuarios con casos de uso compartidos y otros exclusivos. Es un paso hacia un diseño más realista y profesional.
Ejemplo completo: Buscaminas en PlantUML
Ahora pongamos todo esto en práctica con un clásico: el Buscaminas.
¿Qué puede hacer el usuario?
- Iniciar partida
- Marcar casilla
- Descubrir casilla
- Usar pista (opcional)
- Consultar puntuación
Veamos cómo lo modelamos:
@startuml
actor Jugador
usecase "Iniciar partida" as UC1
usecase "Descubrir casilla" as UC2
usecase "Marcar casilla" as UC3
usecase "Verificar victoria" as UC4
usecase "Usar pista" as UC5
usecase "Mostrar puntuación" as UC6
Jugador --> UC1
Jugador --> UC2
Jugador --> UC3
Jugador --> UC5
Jugador --> UC6
UC2 --> UC4 : include
@enduml
Explicación:
- “Descubrir casilla” incluye verificar si se ha ganado: es parte integral del flujo.
- “Usar pista” es opcional, no afecta a otros casos, por eso no tiene relaciones de
include
. - Si quisiéramos complicarlo, podríamos añadir un
<<extend>>
desde “Mostrar puntuación” a un posible “Guardar récord”.
Uso de relaciones extendidas e incluidas
@startuml
actor Usuario
usecase "Gestionar notas" as UC1
usecase "Crear nota" as UC2
usecase "Editar nota" as UC3
usecase "Eliminar nota" as UC4
UC1 --> UC2 : include
UC1 --> UC3 : include
UC1 --> UC4 : include
Usuario --> UC1
@enduml
🔍 Aquí, el caso “Gestionar notas” incluye a los tres subprocesos. Así se mantiene el diagrama limpio y se reutiliza lógica.
¿Qué significan <<include>> y <<extend>> en UML?
Cuando diseñas diagramas de casos de uso en UML, tarde o temprano te encuentras con estas dos palabritas mágicas: <<include>>
y <<extend>>
.
Ambas indican relaciones especiales entre casos de uso, pero tienen significados y usos diferentes. Vamos a verlos paso a paso.
¿Qué es <<include>>
?
<<include>>
se usa cuando un caso de uso reutiliza otro. Es como decir: “esto siempre pasa dentro del otro caso”.
Cuándo usarlo:
- Cuando un comportamiento es compartido por varios casos de uso.
- Cuando una acción es obligatoria y siempre debe ejecutarse.
Ejemplo: Sistema de compra online
@startuml
left to right direction
actor Cliente
usecase "Comprar producto" as UC1
usecase "Iniciar sesión" as UC2
usecase "Procesar pago" as UC3
UC1 --> UC2 : include
UC1 --> UC3 : include
Cliente --> UC1
@enduml
Explicación: Para poder “Comprar producto”, siempre hay que iniciar sesión y procesar el pago. Por eso, se incluye.
¿Qué es <<extend>>
?
<<extend>>
se usa cuando un caso de uso puede tener un comportamiento opcional, que se ejecuta bajo ciertas condiciones.
Cuándo usarlo:
- Cuando una acción no siempre ocurre.
- Para añadir funcionalidades opcionales o alternativas.
Ejemplo: Registro de usuario con confirmación
@startuml
left to right
actor Usuario
usecase "Registrarse" as UC1
usecase "Verificar email" as UC2
UC1 <.. UC2 : extend
Usuario --> UC1
@enduml
Explicación: “Registrarse” puede o no extenderse a “Verificar email”. Dependerá, por ejemplo, de si el usuario ha introducido un correo válido.
Ejemplo: Sistema de Login Básico
@startuml
left to right direction
actor Usuario as U
rectangle Sistema {
(Iniciar sesión) as login
(Recuperar contraseña) as recover
(Registrarse) as register
}
U --> login
U --> recover
U --> register
login .> recover : <<extend>>
@enduml
Explicación:
- El actor Usuario puede interactuar con tres casos de uso.
<<extend>>
indica que «Recuperar contraseña» es una extensión opcional de «Iniciar sesión».
Resumen visual: include
vs extend
Característica | <<include>> | <<extend>> |
---|---|---|
¿Es obligatorio? | Sí | No |
¿Reutiliza funcionalidad? | Sí, siempre se ejecuta | Solo si se da cierta condición |
¿Relación de dependencia? | Fuerte | Débil |
¿Quién llama a quién? | El caso principal llama al incluido | El extendido puede o no activarse |
¿Por qué son importantes los diagramas de casos de uso?
- Ayudan a entender qué espera el usuario del sistema clarificando los requisitos.
- Evitan malentendidos entre equipos.
- Permiten definir el alcance funcional de un proyecto.
- Sirven como base para la programación y las pruebas.
- Priorizan funcionalidades, ayudando a identificar qué es esencial.
- Facilitan la comunicación entre el cliente, los analistas y los programadores.
- Son la base para otros diagramas UML como los de secuencia o las clases.
Consejos prácticos para tus diagramas
- No los sobrecargues: usa varios diagramas si el sistema es complejo usando la técnica divide y vencerás.
- Limita el alcance: No incluyas más de 10-12 casos de uso por diagrama.
- Nombra bien los casos de uso: verbos en infinitivo + objeto (“Consultar historial”, “Registrar usuario”).
- Valida con el usuario: es un diagrama para comunicarte, no para decorar.
- Combínalos con historias de usuario para mayor detalle.
Conclusión
Los diagramas de casos de uso son la forma más clara y sencilla de entender lo que el sistema debe hacer sin entrar aún en detalles técnicos. Con herramientas como PlantUML, crearlos es rápido, limpio y muy útil para tus proyectos de software, incluso en el aula.
Deja una respuesta