Casos de uso: del backlog al diagrama
EventoUAB ya tiene historias de usuario priorizadas y estimadas. Antes de diseñar nada, el equipo necesita una vista de una sola página que responda: ¿quién usa el sistema, para lograr qué, y dónde termina lo que vamos a construir? Esta guía convierte esas historias en un diagrama de casos de uso con actores, frontera, relaciones include/extend y una descripción escrita de cada caso.
Bienvenido
Las historias de usuario son excelentes para conversar y estimar, pero tienen un límite: son muchas, sueltas, y cuesta ver el conjunto. Un diagrama de casos de uso junta todas esas metas en un mapa: quién interactúa con el sistema, qué puede lograr cada quién, y qué queda adentro y afuera del producto.
Al finalizar esta guía sabrás identificar actores y casos de uso a partir de un backlog, dibujar la frontera del sistema, distinguir «include» de «extend», y escribir la descripción de un caso de uso con su flujo principal y sus flujos alternativos.
Encontrarás actividades cortas y autocorregibles —selección múltiple, clasificación, emparejamiento y completar espacios— repartidas a lo largo de la guía, y una sección de ejercicios de razonamiento donde se te da un escenario y debés predecir la respuesta correcta antes de comprobarla.
🧍 Actores
Quién está afuera del sistema e interactúa con él.
🎯 Casos de uso
Metas concretas que un actor logra usando el sistema.
🔗 Relaciones
Cuándo un caso de uso incluye a otro y cuándo solo lo extiende.
Actores, casos de uso y frontera
Un diagrama de casos de uso tiene solo tres ingredientes. Con ellos, el Sprint 1 de EventoUAB cabe en una imagen.
| Elemento | Qué es | En EventoUAB |
|---|---|---|
| Actor | Alguien (o algo) que está afuera del sistema e interactúa con él. Se dibuja como un muñeco. | Estudiante responsable de un club; personal de Bienestar Estudiantil. |
| Caso de uso | Una meta concreta que un actor logra usando el sistema. Se dibuja como una elipse con verbo + objeto. | Reservar espacio, Cancelar reserva. |
| Frontera del sistema | El rectángulo que separa lo que el equipo va a construir (adentro) de quienes lo usan (afuera). | El recuadro "Sistema: EventoUAB". |
1. Un caso de uso se nombra desde la meta del actor ("Reservar espacio"), nunca desde un paso o una tecnología ("Guardar en la tabla reservas"). 2. Los actores van siempre afuera de la frontera: si lo programa tu equipo, no es un actor, es parte del sistema.
También puede ser otro sistema que interactúa con el tuyo, por ejemplo un servicio externo de correo. Lo que lo hace actor es que está fuera de lo que construye el equipo, no que sea humano.
¿Cuál de estas opciones es un actor del diagrama de EventoUAB?
¿Qué es cada una de estas frases dentro de un análisis de EventoUAB?
De historias a casos de uso
Las historias de la guía anterior ya traen casi todo lo que hace falta: el "Como..." es el actor, y el "quiero..." es el caso de uso. El "para..." no se dibuja, pero sigue siendo el criterio para decidir si ese caso vale la pena.
| Historia del backlog | Actor | Caso de uso |
|---|---|---|
| Como estudiante responsable de un club, quiero ver qué espacios están libres, para elegir un horario sin escribirle a nadie. | Estudiante | Ver disponibilidad |
| Como estudiante responsable de un club, quiero reservar un espacio, para no coordinar por WhatsApp. | Estudiante | Reservar espacio |
| Como estudiante responsable de un club, quiero cancelar una reserva que ya no voy a usar, para liberar el espacio. | Estudiante | Cancelar reserva |
| Como personal de Bienestar, quiero dar de alta y de baja espacios, para que el catálogo esté siempre actualizado. | Bienestar | Gestionar espacios |
Cada caso de uso del diagrama debe poder rastrearse hasta al menos una historia del backlog, y cada historia del Sprint 1 debe aparecer en el diagrama. Un caso sin historia suele ser alcance inventado; una historia sin caso, un hueco en el análisis.
Une cada historia con el caso de uso que sale de ella.
Include y extend
Cuando un caso de uso crece, a veces conviene sacar una parte a otro caso de uso. Hay dos formas de conectarlos, y la diferencia está en una sola pregunta: ¿esa parte ocurre siempre o solo a veces?
| Relación | Cuándo se usa | Hacia dónde apunta la flecha | En EventoUAB |
|---|---|---|---|
| «include» | La parte ocurre siempre; el caso base no se completa sin ella. | Del caso base hacia el caso incluido. | Reservar espacio → Iniciar sesión; Reservar espacio → Notificar confirmación. |
| «extend» | La parte ocurre solo a veces, bajo una condición; el caso base funciona sin ella. | Del caso opcional hacia el caso base. | Pedir proyector o sonido → Reservar espacio. |
Preguntate: "¿puedo terminar el caso base sin esa parte?". Si no podés (reservar sin haber iniciado sesión), es include. Si podés (reservar sin pedir proyector), es extend. Y recordá: con extend, la flecha sale del caso opcional y llega al base.
Completá las tres frases sobre las relaciones del diagrama.
1. Reservar espacio no se completa sin iniciar sesión, así que se conectan con .
2. Pedir proyector o sonido ocurre solo si el estudiante lo necesita, así que se conecta con .
3. En una relación «extend», la flecha sale .
Describir un caso de uso
La elipse es solo el título. El valor real de un caso de uso está en su descripción escrita: qué pasa paso a paso cuando todo sale bien y qué pasa cuando no.
| Caso de uso: Reservar espacio | |
|---|---|
| Actor | Estudiante responsable de un club. |
| Precondición | El estudiante inició sesión (caso incluido). |
| Flujo principal | 1. El estudiante elige un espacio, una fecha y una hora. 2. El sistema verifica que el espacio esté libre en ese horario. 3. El estudiante confirma la reserva. 4. El sistema registra la reserva y la muestra en "mis reservas". |
| Flujo alternativo | 2a. El horario ya está ocupado: el sistema avisa que no está disponible y vuelve al paso 1. |
| Postcondición | El espacio queda marcado como ocupado en ese horario. |
El alternativo 2a es el criterio "Dado que el espacio ya está reservado, cuando otro estudiante intenta reservarlo, entonces el sistema muestra que no está disponible" de la guía anterior, contado como pasos. Los criterios de aceptación y los flujos alternativos son dos formas de decir lo mismo; más adelante, los casos de prueba salen de ahí.
En el paso 2 el sistema detecta que el horario elegido ya está ocupado. ¿Cuál es el flujo alternativo bien escrito?
Ejercicios de razonamiento
En estas preguntas no se te pide recordar una definición: se te da un escenario y debés razonar la respuesta antes de comprobarla.
Un integrante del equipo dibuja una elipse llamada "Guardar reserva en PostgreSQL" y la conecta con el actor Estudiante.
¿Qué problema tiene ese caso de uso?
Cada vez que se confirma una reserva, el sistema envía un correo al estudiante. El estudiante nunca "pide" ese correo: ocurre solo, sin excepción.
¿Cómo se conecta "Notificar confirmación" con "Reservar espacio"?
Actividades de repaso
Un repaso integrador de todo el módulo. Cada actividad se corrige al instante; tu progreso se guarda automáticamente en este navegador.
¿Qué diferencia a un actor de un caso de uso?
Si Reservar espacio necesita siempre que el estudiante inicie sesión, la relación correcta entre ambos casos es «extend».
¿Para qué sirve rastrear cada caso de uso hasta una historia del backlog?
¿Dónde se dibuja un actor respecto de la frontera del sistema?
Cheat Sheet
| Término | Idea clave |
|---|---|
| Actor | Quien está afuera del sistema e interactúa con él. Puede ser una persona u otro sistema. |
| Caso de uso | Una meta concreta del actor, nombrada con verbo + objeto. No es un paso ni un detalle técnico. |
| Frontera del sistema | El rectángulo que separa los casos de uso (adentro) de los actores (afuera). |
| «include» | Parte que ocurre siempre. La flecha va del caso base al incluido. |
| «extend» | Parte que ocurre solo a veces. La flecha va del caso opcional al base. |
| Descripción | Actor, precondición, flujo principal, flujos alternativos y postcondición. |
| Trazabilidad | Cada caso sale de al menos una historia; cada historia del sprint aparece en el diagrama. |
¿Sabías que...?
📡 Nacieron en las telecomunicaciones
Ivar Jacobson formuló la idea de caso de uso a fines de los años 80, mientras trabajaba en Ericsson, y más tarde fue uno de los autores de UML, el lenguaje donde hoy se dibujan estos diagramas.
🤖 Sirven para pedirle código a una IA
Una IA a la que le pedís "hacé el sistema de reservas" suele inventar funciones que nadie pidió. Un caso de uso con su flujo principal le acota el alcance: le dice exactamente qué metas existen y cuáles no.
🧭 Lo que viene en la próxima guía
Ya sabemos quién hace qué. El siguiente paso es el modelo de dominio: las entidades que el sistema debe recordar (Espacio, Reserva, Club), con sus atributos y relaciones.