5.1 Actores, objetivos y semántica de casos de uso

Al terminar esta lección

• Distinguir un actor (rol externo) de una persona, una tabla o un componente interno, y clasificarlo como primario o secundario.
• Detectar CRUD disfrazado y elegir la granularidad de un caso de uso a partir del objetivo del actor.
• Justificar, o descartar, una relación include o extend con su dirección, condición y razón.
• Redactar un caso de uso textual con garantías y alternativos, y revisarlo con un cliente usando ejemplos en vez de notación.

5. La frontera del sistema y los casos de uso

Hasta ahora entendimos el negocio y elegimos un problema. El siguiente riesgo es más sutil: dos personas imaginan comportamientos distintos bajo la misma frase. Cuando alguien dice "registrar el pedido", el vendedor piensa en cargar líneas, la dueña en que quede comprometido con el cliente, depósito en que aparezca algo para preparar y un desarrollador en un INSERT. Los cuatro asienten en la reunión y construyen cuatro cosas distintas.

Los casos de uso son una herramienta para forzar el acuerdo antes de escribir código. Hacen explícito quién busca qué resultado, qué debe ocurrir para conseguirlo y qué debe seguir siendo verdad si algo falla. En esta lección vemos los conceptos y su semántica. En la 5.2 los usamos sobre el caso real de Nexo, y en la 5.3 los construís vos.

5.1 UML entra porque tenemos una pregunta, no porque toca en el programa

Un diagrama de casos de uso responde principalmente dos cosas: qué roles externos interactúan con el sistema y qué objetivos de valor pueden alcanzar. No describe pantallas, endpoints ni secuencia interna. El rectángulo es la frontera del sistema, las elipses son objetivos y los actores son roles externos. Si cambiar React por otra interfaz altera tu diagrama, probablemente modelaste tecnología.

Esa es la prueba de independencia: el diagrama y el texto deben sobrevivir a un cambio de framework, de base de datos y de pantalla. Lo que no sobrevive a esos cambios es diseño, y el diseño tiene su lugar más adelante (módulos 7 y 8). Acá solo decidimos comportamiento observable desde afuera.

Esto también explica por qué, en el módulo 4, el alcance quedó como IN/OUT/BLOCKED y no como una lista de pantallas. Los casos de uso toman el IN y le ponen forma de objetivos con dueño. Cada elipse debería poder rastrearse hasta un requerimiento IN y hasta una pregunta que el diagrama ayuda a contestar. Si una elipse no remite a nada, sobra.

5.2 Primera versión: deliberadamente incompleta

Con lo que sabíamos después de la primera reunión, una versión razonable era pequeña. Registrar pedido parecía incluir consultar catálogo y crédito aparecía como una excepción separada. Depósito todavía no estaba bien modelado porque desconocíamos cómo la reserva afectaría su trabajo.

Fijate en lo que el diagrama sí comunica y en lo que esconde. Comunica que hay dos actores, que "Registrar pedido" necesita consultar el catálogo y que la autorización de crédito es un objetivo con su propio actor. Esconde que no hay nadie que prepare el pedido, que no sabemos si el precio se calcula o se consulta, y que "Consultar catálogo" probablemente no sea un objetivo sino un paso interno.

Una primera versión incompleta es útil si deja visible qué asumimos. El error sería presentarla como terminada. Por eso la etiquetamos como hipótesis de modelado y la ponemos a prueba con episodios reales.

5.3 Actores: roles, no personas ni tablas

Problema que resuelve. Si modelás personas, el diagrama cambia cada vez que alguien renuncia o se toma vacaciones. Si modelás tablas o componentes, mezclás el adentro con el afuera y nadie sabe dónde está la frontera.

Definición operativa. Un actor es un rol externo al sistema que interactúa con él para conseguir un objetivo o para colaborar con uno ajeno. Se distingue entre:

• Actor primario: tiene un objetivo que el sistema ayuda a cumplir. Es quien inicia la interacción.
• Actor secundario: el sistema necesita su colaboración para cumplir el objetivo del primario. Otro sistema (el ERP, un proveedor) o una persona que responde algo.

El mismo empleado puede cumplir dos actores distintos si persigue objetivos distintos, y dos personas pueden compartir un actor. Laura, en administración, puede autorizar un sobregiro (Responsable de crédito) y otro día consultar un saldo (otro rol, con otro objetivo). "Laura" no es actor; "Responsable de crédito" sí.

Ejemplo en Nexo.

Contraejemplos. PostgreSQL no es actor: es parte interna de la solución. El worker que envía el pedido a preparación tampoco: es un mecanismo, y si aparece en el diagrama, el diagrama ya describe arquitectura. Un portal B2B para que el cliente cargue sus propios pedidos es un actor candidato (el cliente mayorista), pero de un slice posterior; en el primer release el vendedor es quien carga.

El servicio fiscal merece una nota. Es un actor legítimo en el modelo general, porque está fuera de la frontera y participa de un objetivo ("Emitir comprobante"). Pero la decisión de alcance del primer release es que la emisión fiscal queda fuera: el sistema deja el pedido marcado como pendiente de facturación y nada más. El diagrama puede mostrarlo como horizonte, sin que el slice lo implemente.

Cómo se verifica. Para cada actor, respondé tres preguntas. ¿Está fuera de la frontera? ¿Tiene un objetivo o una colaboración que podría nombrar sin mencionar tecnología? ¿Puedo señalar la fuente (reunión, documento, observación) que lo respalda? Si alguna falla, no es actor.

5.4 Granularidad: detectar CRUD disfrazado

Problema que resuelve. Sin un criterio de tamaño, los casos de uso terminan siendo uno por tabla ("Crear pedido", "Editar pedido", "Eliminar pedido") o uno por pantalla. Ambos producen listas de operaciones que no dicen nada del negocio y que nadie puede probar de punta a punta.

Definición operativa. Un CRUD describe operaciones sobre datos; un caso de uso describe una intención del actor y el comportamiento del sistema para cumplirla. Una unidad tiene la granularidad correcta si cumple tres condiciones:

1. El actor reconoce un objetivo ("vine a hacer esto") y puede nombrarlo sin verbos de persistencia.
2. Termina en un resultado observable que se puede demostrar de punta a punta.
3. Sus variantes comparten la misma garantía mínima.

Alistair Cockburn llama a este tamaño "nivel de objetivo de usuario" en su libro sobre cómo escribir casos de uso efectivos: ni el paso suelto de una pantalla ni el proceso de negocio que dura semanas. No necesitás memorizar la taxonomía; te alcanza con la pregunta de las tres condiciones.

Ejemplo en Nexo. "Registrar pedido mayorista" cumple las tres: el vendedor lo reconoce, termina en un pedido con estado o en un rechazo explícito, y todas sus variantes (aprobado, pendiente de autorización, rechazado) comparten la garantía de no dejar efectos parciales. "Autorizar excepción de crédito" también: tiene actor, autoridad, evidencia y resultado propios.

Contraejemplos. "Crear pedido" es CRUD disfrazado: nombra la operación sobre el dato y no el objetivo. "Agregar línea" es un paso dentro de registrar el pedido. "Gestionar pedidos" es un cajón que contiene diez objetivos distintos. A veces una operación CRUD sí coincide con un objetivo real; "Registrar nuevo cliente" puede ser legítimo si el negocio reconoce ese alta como transacción con reglas propias. La palabra crear/modificar/eliminar no la vuelve automáticamente caso de uso, ni la descalifica.

Cómo se verifica. Aplicá la prueba del actor: leé el nombre del caso en voz alta frente a quien lo ejecuta. Si responde "yo no hago eso, hago otra cosa", el nombre describe una operación del sistema y no un objetivo.

5.5 include y extend sin superstición

Problema que resuelve. Las relaciones entre casos prometen reducir duplicación y mostrar condiciones. En la práctica se usan por reflejo, con las flechas al revés, y terminan comunicando exactamente lo contrario de lo que el equipo quería decir.

Definición operativa de include. Una relación de inclusión significa que el caso base incorpora explícitamente el comportamiento del incluido y no puede completar su objetivo sin ejecutarlo. La flecha va del caso base hacia el incluido. En la práctica, include se justifica cuando el comportamiento común merece identidad porque aparece en varios casos, o porque aislarlo reduce una complejidad significativa sin perder intención.

Definición operativa de extend. Modela comportamiento que se incorpora bajo una condición y cuyo caso base puede cumplir su objetivo sin esa extensión. La flecha va desde el caso de extensión hacia el base, y la condición se escribe sobre la flecha. Si el caso base queda incompleto sin la extensión, no es extend; es include o directamente parte del flujo.

Ejemplo en Nexo. El mapa de relaciones del modelo validado (Figura 6, más abajo) se puede leer así:

Leelo con la prueba de completitud. ¿Puede CU-01 cumplir su objetivo sin calcular precio, sin evaluar crédito o sin reservar? No: son obligatorios, por eso include. ¿Puede CU-01 cumplir su objetivo sin que intervenga el Responsable de crédito? Sí, cuando el crédito alcanza. Por eso la autorización es una extensión condicionada, y su flecha apunta hacia CU-01. Lo mismo para el faltante: preparar un pedido no requiere resolver faltantes cuando todo está en el estante.

Contraejemplos.

• Dibujar include hacia "Consultar catálogo" porque el vendedor "mira el catálogo antes de cargar". Mirar el catálogo no es un comportamiento obligatorio del caso ni una unidad con intención; es parte de cómo se arma el pedido. Por eso la versión de la Figura 5 es solo una hipótesis.
• Dibujar include para mostrar orden temporal ("primero esto, después aquello"). El orden vive en el curso principal escrito, no en el diagrama.
• Usar extend para algo que sucede siempre, solo para "separar" un caso largo. Si siempre ocurre, es include o un paso del flujo.
• Invertir las flechas: es el error más común y cambia el significado.

Y hay una tercera opción que muchos equipos olvidan: no usar ninguna relación y escribir el alternativo en texto. Si la relación no responde una pregunta del lector, probablemente sobra.

5.6 Nexo B2B · CU-01 evoluciona cuando aparece nueva evidencia

La nueva evidencia modifica actores, relaciones y flujos. Esto no significa que el diagrama anterior "estaba mal" por existir; estaba provisionalmente correcto para el conocimiento disponible. Lo que sería incorrecto es no actualizarlo para evitar retrabajo documental.

Dos aclaraciones sobre la figura. Primero, "Emitir comprobante" con el servicio fiscal aparece como horizonte del modelo; la emisión real queda fuera del primer release, donde el sistema solo deja el pedido marcado como pendiente de facturación. Segundo, la extensión "Autorizar excepción de crédito" ocurre más tarde y la ejecuta otra persona, no el vendedor. UML lo tolera, y en esta lección lo mantenemos como extend porque la condición es explícita y el caso base queda completo. Lo que importa en el fondo es que sea un caso separado, con actor propio, y que el vínculo con CU-01 pase por un estado visible (PENDIENTE_AUTORIZACION).

5.7 La especificación textual es más importante que el dibujo

El diagrama permite discutir alcance. La especificación permite construir. Un caso de uso útil conserva objetivo, actor primario, disparador, precondiciones, curso principal, alternativos, garantía mínima, garantía de éxito, reglas y criterios de aceptación. No hace falta describir botones. El diálogo es entre actor y sistema.

Notá que no hay base de datos, ni worker, ni API en el diagrama. El sistema es una caja. Las flechas internas (S-->>S) son comportamientos que el sistema se compromete a cumplir, no mecanismos.

Las dos garantías, con su verificación

La garantía de éxito dice qué debe ser verdad cuando el objetivo se cumple. La garantía mínima dice qué debe seguir siendo verdad aunque falle. Se redactan como presencia o ausencia de efectos, porque eso es lo que un test puede observar después.

Cuando llegue testing, la garantía mínima se vuelve un escenario ejecutable. Por ejemplo, el borde de crédito, que ya conocés de RN-01, se puede leer directo desde el caso:

1Scenario: un centavo sobre el límite no deja efectos parciales
2  Given un cliente ESTÁNDAR con límite 500.000,00 y saldo deudor 480.000,00
3  And un pedido cuyo total es 20.000,01
4  When el vendedor intenta registrar el pedido
5  Then el resultado es un rechazo por crédito
6  And no existe pedido confirmado
7  And no hay stock reservado

El caso de uso no dice cómo se arma esa transacción. Dice qué tiene que ser cierto después. El "cómo" lo decide arquitectura (módulo 7) y el test lo demuestra (módulo 10).

5.8 Cómo revisar un caso de uso con el cliente

Leerle veinte pasos de una especificación al cliente produce asentimiento, no validación. La revisión debe centrarse en decisiones y ejemplos concretos.

1. Recordá el objetivo: "queremos confirmar qué significa registrar un pedido correctamente".
2. Recorré un ejemplo normal con números reales o representativos.
3. Movelo al borde: un centavo sobre el límite, la última unidad, un SKU discontinuado.
4. Dejá que el cliente corrija el vocabulario ("para nosotros eso no es 'registrado'").

No le pidas al cliente que "apruebe UML". Leé ejemplos. Con un cliente Platino por encima del límite y una sola unidad disponible, preguntá: "¿Qué debería pasar? ¿La unidad queda tomada mientras espera autorización? ¿Por cuánto tiempo?". Cuánto se pasó es un dato para provocar la respuesta, no una regla: la tolerancia Platino (RN-02) sigue sin validar, y por eso en tus ejemplos conviene decir "un poco por encima" o "X% por encima" y no inventar un porcentaje. Si el cliente puede responder casos reales y detectar errores del modelo, el artefacto está cumpliendo su función.

1Sos un revisor adversarial de casos de uso. No generes UML nuevo.
2Adjunto: CU-01 (texto), glosario, RN-01..RN-05 y RN-07 (BLOCKED), evidencia EV-01..EV-05.
3​
4Tarea:
51. Listá cada paso del curso principal que describa interfaz o tecnología en vez de comportamiento actor-sistema.
62. Listá los alternativos que no tengan condición observable o garantía mínima.
73. Buscá un episodio que este caso NO pueda explicar y decí qué le falta.
84. Marcá cualquier valor que parezca inventado (plazos, porcentajes) y no lo corrijas.
9Formato: tabla con columnas problema | línea | evidencia que falta | propuesta (requiere aprobación).

Errores frecuentes

Para llevarte

• Un diagrama de casos de uso solo vale si responde una pregunta: quién interactúa, qué objetivos alcanza, dónde termina la frontera.
• Actor es rol externo. Persona, tabla y worker no lo son; ERP y proveedor externo sí pueden serlo.
• La granularidad se prueba con tres preguntas: objetivo reconocible, resultado demostrable, garantía común.
• include sale del caso base hacia lo obligatorio; extend llega al caso base desde lo condicional. Si dudás, escribilo como alternativo.
• La especificación textual manda sobre el dibujo: garantías mínimas y de éxito redactadas como efectos observables.
• Con el cliente se validan ejemplos, no notación, y los valores desconocidos (TTL, tolerancia Platino) se marcan BLOCKED en vez de inventarse.