Al terminar esta lección
- Reconstruir cómo cada evidencia (un pedido, una objeción, una validación) obligó a cambiar una versión de CU-01, y registrar ese cambio con su fuente.
- Especificar garantías mínimas y de éxito, y alternativos con condición observable y resultado de negocio.
- Decidir dónde termina un caso de uso y cuándo un evento sin dueño exige un caso nuevo (CU-02).
- Conducir un playback de CU-01 con el cliente sin inventar valores BLOCKED como el TTL de la reserva.
5.9 Nexo B2B · Construir CU-01 como un contrato que evoluciona
El caso de uso de Nexo cambió cinco veces: de v0 a v4 hay cuatro cambios, y cada uno nació de una evidencia que la versión anterior no podía explicar. Esa trazabilidad es lo que separa un artefacto vivo de un documento escrito de memoria. Vamos a recorrer las cinco versiones, con el texto real de cada una.
v0: el caso que modela una pantalla
CU-01 Crear pedido
Actor: Vendedor
1. El vendedor selecciona el cliente.
2. El vendedor agrega productos.
3. El vendedor guarda.
Tres pasos, ninguna garantía, ninguna regla. No es inútil: demuestra que el equipo había modelado una pantalla imaginada en lugar del objetivo del actor. El pedido 48172 la rompe inmediatamente. Llegó el jueves a las 10:02 por WhatsApp como foto de una hoja con 23 códigos: dos mal escritos y uno discontinuado. Antes de guardar hay que resolver códigos ambiguos, determinar precio (con acuerdos que no están en el ERP), evaluar un saldo que supera el límite y verificar stock. Para AX-442, el ERP muestra 8 unidades, 6 ya están reservadas por pedidos previos y el pedido pide 3: faltan 1.
v1: precio, crédito y stock como pasos obligatorios
CU-01 Registrar pedido mayorista
Actor primario: Vendedor
Curso principal:
1. El vendedor identifica al cliente y envía las líneas.
2. El sistema valida productos y cantidades.
3. El sistema determina el precio de cada línea.
4. El sistema evalúa crédito y rechaza si saldo + pedido supera el límite.
5. El sistema verifica stock y reserva.
6. El sistema registra el pedido.
Parece mejor hasta que se prueba con un cliente de contado, que paga al retirar. El flujo de crédito no aplica igual: no hay saldo que superar. La versión 1 había codificado una secuencia universal que en realidad depende de la condición comercial del cliente. Se corrige para expresar una regla condicional: el sistema evalúa crédito o condición de pago, según el cliente. Es una regla nueva que ventas confirma y que todavía no tiene número de RN.
v2: el sobregiro como estado, no como error
La segunda versión incorpora una rama de sobregiro. El equipo la dibuja primero con extend desde "Autorizar crédito" hacia "Registrar pedido", pero con el vendedor como actor de ambos, y el flujo tratándola como un paso opcional. Al revisar el objetivo, descubre que la autorización no es un detalle opcional del vendedor: cuando se supera el umbral y la política lo permite, el pedido queda pendiente hasta que un actor distinto y autorizado decide, en otro momento. Se modela como caso separado (CU-02) con su propio actor, y el flujo principal referencia el estado pendiente sin falsear la notación.
Curso principal:
1. El vendedor identifica al cliente y envía las líneas.
2. El sistema valida productos y cantidades.
3. El sistema determina el precio de cada línea.
-4. El sistema evalúa crédito y rechaza si saldo + pedido supera el límite.
-5. El sistema verifica stock y reserva.
-6. El sistema registra el pedido.
+4. El sistema evalúa la condición comercial del cliente (crédito o contado).
+5. Si el crédito requiere autorización, deja el pedido en PENDIENTE_AUTORIZACION
+ y crea la solicitud para el Responsable de crédito (CU-02).
+6. Si el resultado es aprobado, reserva stock y registra el pedido.
El cambio importa más por lo que evita que por lo que agrega. Antes, "superar el límite" era un rechazo y el vendedor perdía el pedido; el responsable comercial mostró tres pedidos de las últimas semanas que fueron autorizados a mano. Rechazar era destruir un caso legítimo del negocio.
v3: las garantías
Hasta acá el caso describía qué hace el sistema cuando todo sale bien. La versión 3 hace explícito qué debe seguir siendo verdad cuando algo falla.
+Garantía de éxito:
+Pedido identificado, precio calculado por fuente autorizada, condición comercial
+resuelta y reserva persistida de forma consistente.
+
+Garantía mínima:
+Ante rechazo o fallo no existe pedido confirmado con reserva parcial.
+Cualquier estado pendiente conserva la causa y el actor que debe resolverlo.
Estas garantías viajan después a transacciones, contratos y tests. Con ellas aparece también un hueco: ¿qué pasa con la reserva mientras el pedido espera autorización? La respuesta de negocio llega en la sesión de playback que vemos más abajo.
v4: validada con tres personas
La versión 4 se valida con tres personas distintas. La vendedora corrige el momento en que se considera "registrado": para ella, un pedido pendiente de autorización todavía no está registrado como compromiso con el cliente. Laura, de administración, aclara que una autorización no modifica el límite permanente del cliente: autoriza este pedido. Sergio, de depósito, insiste en diferenciar reservado de preparado, porque reservar no mueve un solo bulto. Ninguna corrección cambia la notación por estética. Cambia el significado del sistema y, por lo tanto, los artefactos derivados.
Este es el texto de v4, con el orden canónico de pasos (primero se evalúa crédito y recién después se reserva, dentro de la misma unidad consistente):
CU-01 Registrar pedido mayorista
Actor primario: Vendedor
Objetivo: dejar un pedido comercialmente aceptado o un resultado explícito de por qué no puede aceptarse.
Precondiciones:
- vendedor autenticado y autorizado para operar el cliente
- maestros de cliente/producto disponibles o fallo explícito de integración
Curso principal:
1. El vendedor identifica al cliente y envía líneas (SKU, cantidad) y método de entrega (retiro o envío).
2. El sistema valida identidad, cantidades (unidad de venta y múltiplos) y productos (equivalencias vigentes).
3. El sistema resuelve el precio autorizado de cada línea desde fuentes servidoras y calcula el total.
4. El sistema evalúa crédito con saldo, límite y política vigentes.
5. El sistema reserva stock por depósito en la misma unidad consistente que registra el pedido.
6. Si el resultado es aprobado, confirma el pedido y conserva evidencia de precio, reserva y decisión.
7. El sistema marca el pedido como pendiente de facturación.
8. Devuelve número, estado y resumen.
Alternativos relevantes:
A1. SKU inválido: rechaza antes de crear efectos parciales.
A2. Stock insuficiente: no confirma; informa faltantes y alternativas permitidas.
A3. Crédito requiere autorización: deja el pedido en PENDIENTE_AUTORIZACION con la causa, toma una reserva
blanda con vencimiento (RN-07, plazo BLOCKED) y crea la solicitud para CU-02. La reserva firme llega con la autorización.
A4. Reutilización conflictiva de requestId: devuelve conflicto sin segundo pedido.
A5. Dependencia de maestros no disponible: falla de forma visible sin inventar valores.
Garantía mínima:
No existe pedido confirmado con precio no autorizado, reserva negativa o decisión de crédito ausente.
Garantía de éxito:
Pedido confirmado una sola vez, con trazabilidad suficiente para explicar precio, crédito, stock y actor.
Dos decisiones de redacción merecen atención. Primero, el paso 7 deja la facturación fuera: el primer release no emite comprobantes, solo marca el pedido para que una integración posterior lo tome. Segundo, el paso 1 incluye el método de entrega como dato requerido, pero el caso no se extiende hasta despachar. Saber dónde terminar es parte de la granularidad.
La trazabilidad de todo esto cabe en un registro corto. Este es el tipo de artefacto que vas a producir en el taller:
cu: CU-01
versiones:
- id: v1
cambio: "Precio, crédito y stock pasan a ser pasos obligatorios; el nombre pasa a ser un objetivo."
evidencia: "Pedido 48172: 23 códigos, acuerdo de precio, saldo sobre el límite, falta 1 unidad de AX-442."
fuente: "reconstrucción del pedido (módulo 3)"
- id: v2
cambio: "Sobregiro como PENDIENTE_AUTORIZACION y CU-02 separado; crédito o contado según el cliente."
evidencia: "Cliente de contado; tres pedidos autorizados manualmente en semanas recientes."
fuente: "responsable comercial; administración"
- id: v3
cambio: "Se agregan garantía mínima y de éxito."
evidencia: "Pregunta abierta: qué debe seguir siendo cierto si falla un paso."
fuente: "revisión interna del equipo"
- id: v4
cambio: "Momento de 'registrado'; autorización no cambia el límite permanente; reservado vs preparado."
evidencia: "Validación con vendedora, administración y depósito."
fuente: "sesión de validación (tres personas)"
5.10 Cómo leer un caso de uso con el cliente sin enseñarle UML
No proyectes diez páginas y preguntes "¿está aprobado?". Elegí ejemplos. Podés decir: "Voy a probar si entendimos. Cliente estándar, límite 500.000, deuda 480.000, pedido 30.000. ¿Qué debería pasar?". Después movés un centavo sobre el borde. Luego probás un cliente con autorización, un SKU faltante y una sustitución que cambia el total. Cada respuesta confirma o rompe una regla. El cliente está validando comportamiento, no notación.
Analista: "Si el pedido supera el límite, ¿reservamos igual mientras esperamos autorización?"
Responsable comercial: "Sí, pero no por días. Un rato."
Analista: "Todavía no tenemos un número. Lo voy a dejar como política pendiente porque afecta stock. ¿Quién puede definirlo?"
Marta, la dueña: "Depósito y comercial lo vemos juntos."
Analista: "Perfecto. Entonces el flujo pendiente existe, pero el TTL queda BLOCKED. No lo voy a fijar en 24 horas porque sería inventarlo."
Esa respuesta profesional hace visible una incertidumbre sin frenar todo el proyecto. Podés seguir especificando partes independientes y preparar un experimento técnico, pero no podés convertir el valor en contrato. El gate debe bloquear solo aquello que depende del TTL, no el aprendizaje completo.
Probá vos el mismo playback. El simulador siguiente tiene una trampa realista: la tentación de cerrar la reunión con un número cualquiera.
Playback de CU-01: qué pasa con la reserva mientras se espera autorización
Estás en la oficina de Nexo con Marta, la dueña, y el responsable comercial. Te quedan 15 minutos de la sesión de validación de CU-01. Falta cerrar el comportamiento del alternativo A3.
Marta (dueña)
Cuando un cliente se pasa del límite, Laura lo autoriza o no. Lo que no quiero es que mientras tanto se nos escape la mercadería.
¿Qué respondés?
5.11 Cuándo NO hacer un diagrama de casos de uso
Si el proyecto es una automatización pequeña con un único actor, una frontera obvia y dos comportamientos inequívocos, quizá una especificación textual con criterios de aceptación sea suficiente. El diagrama tiene valor cuando permite discutir frontera, roles o granularidad. No gana puntos por existir. De la misma manera, un proyecto complejo puede necesitar varios diagramas separados por contexto en vez de un póster ilegible con cuarenta elipses. La regla sigue siendo la misma: el artefacto debe responder una pregunta.
En Nexo, el diagrama sí se justificó por una razón concreta: había cuatro actores que no se habían sentado juntos (ventas, crédito, depósito y un servicio fiscal) y una disputa de frontera sobre quién confirma el pedido. Donde el equipo no tuvo esa pregunta, no dibujó nada. Por ejemplo, el alta de clientes se resolvió con tres líneas de texto.
5.12 El caso de uso como herramienta de negociación
Un caso de uso vale cuando ayuda a descubrir comportamiento. El dibujo por sí solo tiene poco contenido; la especificación textual fuerza a ordenar precondiciones, disparador, curso normal, alternativos y garantías. Esa estructura crea preguntas que una lista de features no crea. ¿Qué pasa si el precio cambia entre cotización y confirmación? ¿Qué ocurre si el crédito requiere autorización? ¿Cuándo se considera reservado el stock? ¿Qué debe quedar intacto si falla un paso posterior?
Los alternativos no son "errores". Son caminos legítimos provocados por condiciones del negocio. Un cliente que requiere autorización de crédito no necesariamente produce error; puede producir un estado pendiente y una tarea para un aprobador. Si modelamos todo lo que no es happy path como excepción HTTP, perdemos comportamiento del negocio.
Alternativo A3: débil vs verificable
A3. Si el crédito no alcanza, mostrar error.
- No dice qué estado queda.
- No dice quién resuelve ni cómo.
- No dice qué pasa con la mercadería.
- Un tester no puede derivar un oráculo.
A3. Crédito requiere autorización: el pedido queda en PENDIENTE_AUTORIZACION con la causa; se toma una reserva blanda con vencimiento (RN-07, plazo BLOCKED); se crea la solicitud para el Responsable de crédito. Efectos que no deben ocurrir: pedido CONFIRMADO, reserva firme, cambio del límite permanente del cliente.
5.13 Cómo elegir la granularidad correcta
Un caso de uso debe representar un objetivo del actor, no cada botón ni un proceso gigantesco. "Gestionar pedidos" suele ser demasiado amplio. "Agregar línea" suele ser demasiado pequeño. "Registrar pedido mayorista" puede ser una buena unidad si termina en un resultado reconocible y cruza las reglas necesarias. La prueba práctica es preguntar si el actor diría "vine a hacer esto" y si podemos demostrar el resultado de punta a punta.
Nexo B2B · CU-01 se vuelve incómodo, y eso es bueno
La primera versión de CU-01 decía: el cliente selecciona productos, el sistema valida stock y crédito, crea el pedido y confirma. Parece razonable. En la revisión con ventas aparece una pregunta: "¿y si el cliente compra por caja pero nosotros vendemos algunas piezas sueltas?". El concepto cantidad ya no es trivial. Puede existir unidad de venta, múltiplo y conversión.
En vez de agregar enseguida campos packSize y unitConversion, registramos un descubrimiento de dominio. Pedimos ejemplos. Algunos SKU solo se venden por caja cerrada, otros permiten unidad, y los acuerdos de clientes especiales pueden cambiar el múltiplo. Ahora la validación de cantidad tiene una regla propia y casos frontera: cantidad 0, cantidad negativa, cantidad que no es múltiplo de la caja, acuerdo que cambia el múltiplo.
Luego administración aclara que un cliente con exposición superior al límite puede quedar PENDIENTE_AUTORIZACION en lugar de ser rechazado. CU-01 cambia: el curso principal cubre aprobación automática; un alternativo produce solicitud de autorización y toma, como máximo, una reserva blanda con vencimiento hasta saber qué política corresponde. La garantía mínima también cambia.
Depósito agrega otra condición: algunos pedidos se retiran y otros se envían por transportista. Eso no tiene por qué partir CU-01 si el objetivo sigue siendo registrar un pedido confirmado. El método de entrega puede ser dato requerido y afectar pasos posteriores. El caso de uso no se expande hasta "despachar". Saber dónde terminar es parte de la granularidad.
Estas decisiones dejan huella en el contrato que más adelante se especifica (módulo 6). El método de entrega entra como dato requerido, y el precio, en cambio, no entra: el cliente no impone unitPrice.
export type CreateOrderCommand = {
requestId: string;
sellerId: string; // lo fija el servidor desde la sesión
clientId: string;
items: Array<{ sku: string; quantity: number }>; // sin unitPrice: RN-03
deliveryMethod: "pickup" | "delivery";
preferredDepositId?: string; // CBA o CEN
};
export type CreateOrderResult =
| { kind: "confirmed"; orderId: string; totalCents: number }
| { kind: "pending_authorization"; orderId: string }
| { kind: "rejected"; reason: "credit" | "stock" | "invalid_sku" }
| { kind: "conflict"; reason: "request_id_reused" }
| { kind: "temporarily_unavailable"; dependency: "master_data" };
Mirá la correspondencia: A1 es invalid_sku, A2 es stock, A3 es pending_authorization, A4 es conflict y A5 es temporarily_unavailable. Cinco alternativos, cinco resultados con nombre. Eso es lo que significa que un alternativo sea "un resultado de negocio" y no un error genérico. (Este tipo se desarrolla en la lección 6.1; acá solo lo usamos para ver cómo un caso bien escrito se convierte en contrato.)
La evolución importa más que el diagrama final. Cada cambio tiene una fuente. Podés señalar qué conversación introdujo la regla de múltiplos, qué evidencia creó el alternativo de autorización y por qué despacho queda fuera del CU-01.
5.14 Revisar casos de uso contra episodios históricos
Antes de aprobar un CU, tomá pedidos reales y simulá el flujo. Si un episodio no puede explicarse, puede faltar un alternativo, una regla o un concepto. Si el CU exige algo que nunca ocurre, quizá introdujimos solución accidental. Esta revisión es más fuerte que preguntar si el documento "se entiende".
| Episodio | Recorrido contra CU-01 v4 | Qué revela |
|---|---|---|
| Pedido 48172: 23 códigos, dos mal escritos y uno discontinuado | Paso 2: la validación de productos rechaza o propone equivalencia vigente | Hace falta que la equivalencia (A-184 a A-184B desde 2026-05-01) sea una regla con vigencia |
| Pedido 48172: AX-442 con 8 en ERP, 6 reservadas y 3 pedidas | Paso 5 falla: A2 stock insuficiente, falta 1 | El alternativo debe informar faltantes y alternativas permitidas, sin sustitución automática (política BLOCKED) |
| Cliente de contado que paga al retirar | Paso 4: evalúa condición comercial, no crédito | CU-01 depende del tipo de cliente |
| Pedido 48603: stock suficiente en ERP, faltante en picking después de confirmar | Fuera de CU-01: el objetivo ya terminó | Aparece un caso posterior de depósito (Resolver quiebre de preparación) |
Scenario: stock insuficiente informa faltantes sin efectos parciales
Given el depósito CBA tiene AX-442 con 8 unidades en el ERP y 6 reservadas
And un cliente estándar con crédito suficiente
When el vendedor registra un pedido de 3 unidades de AX-442
Then el resultado es un rechazo por stock con faltante de 1 unidad
And el sistema informa las alternativas permitidas
And no existe pedido confirmado
And las reservas de AX-442 siguen en 6
El escenario sale casi sin esfuerzo del recorrido, y eso es una buena señal: un caso de uso bien escrito permite derivar pruebas sin adivinar.
5.15 Casos de uso y estados: no duplicar modelos
Un caso de uso cuenta interacción orientada a un objetivo. Una máquina de estados explica cómo un objeto puede evolucionar y qué transiciones son válidas. Si el comportamiento de un pedido depende fuertemente del estado, ambos modelos pueden complementarse. Pero no conviene copiar cada paso del CU como estado. "Validando crédito" puede ser una actividad momentánea, no una condición durable que el negocio reconoce.
El criterio es observabilidad y consecuencias. PENDIENTE_AUTORIZACION importa porque cambia qué acciones están permitidas, quién debe actuar y qué debe mostrarse. "CALCULANDO_TOTAL" probablemente no.
Microtaller · Encontrar estados falsos
Tomá diez nombres de estados candidatos y clasificá cuáles representan condición durable del dominio y cuáles son progreso de UI o de proceso. Para los verdaderos, indicá evento que entra, eventos que salen y acciones prohibidas mientras están activos. Empezá con este calentamiento.
¿Estado durable o progreso de proceso?
Un estado es durable si el negocio lo reconoce, cambia qué se puede hacer y quién debe actuar.
PENDIENTE_AUTORIZACION
CALCULANDO_TOTAL
CONFIRMADO
VALIDANDO_CREDITO
MOSTRANDO_ERROR
CANCELADO
EN_PREPARACION
Nexo B2B · Un evento sin dueño revela un hueco
La máquina de estados incluye PENDIENTE_AUTORIZACION -> CONFIRMADO con evento autorizar. En la revisión alguien pregunta: "¿quién ejecuta autorizar y desde qué caso de uso?". El diagrama no puede responder. Esto obliga a especificar el objetivo del actor aprobador y su autorización contextual.
El modelo de estados no agregó documentación por deporte. Detectó que una transición crítica no tenía operación ni responsable. Después del cambio, CU-02 Autorizar excepción de crédito referencia la misma RN y exige auditoría.
CU-02 Autorizar excepción de crédito
Actor primario: Responsable de crédito
Disparador: existe un pedido en PENDIENTE_AUTORIZACION
Objetivo: decidir, con evidencia, si un pedido que excede la política automática se confirma o se cancela.
Precondiciones:
- pedido en PENDIENTE_AUTORIZACION
- el responsable tiene permiso explícito para autorizar crédito (distinto del permiso de vendedor)
Curso principal:
1. El responsable abre la solicitud y ve cliente, saldo, límite, total y causa.
2. El sistema muestra la regla aplicada (RN-01 y, para Platino, RN-02) y el estado de la reserva blanda.
3. El responsable decide autorizar y registra un motivo (obligatorio).
4. El sistema confirma que haya disponibilidad al momento de decidir y convierte la reserva en firme.
5. El sistema confirma el pedido y registra actor, instante, regla aplicada, pedido y motivo.
6. El sistema informa el resultado al vendedor.
Alternativos relevantes:
A1. El responsable rechaza: el pedido pasa a CANCELADO, se libera la reserva y se registra el motivo.
A2. Ya no hay disponibilidad: no confirma; informa al responsable y el pedido sigue pendiente.
A3. La reserva blanda venció: se re-verifica disponibilidad como en A2 (el plazo de vencimiento es RN-07, BLOCKED).
A4. Responsable sin permiso: forbidden, sin filtrar datos; el intento queda auditado.
Garantía mínima:
Una autorización no modifica el límite permanente del cliente y no deja pedido confirmado sin evidencia de la decisión.
Garantía de éxito:
Pedido confirmado con la decisión explicable: quién, cuándo, por qué regla y con qué motivo.
La autorización no cambia el límite permanente: es una frase corta que sale de la validación de v4 y que, sin ser escrita, un desarrollador razonable podría implementar al revés ("ya que lo autorizó, subimos el límite").
Encontrá lo que no debería estar en este borrador de CU-02
Hacé clic en las líneas que contradicen lo validado con el cliente o inventan valores.
5.16 Un caso de uso como instrumento para encontrar decisiones escondidas
La mayor parte del valor aparece en la especificación textual. Es ahí donde una frase aparentemente simple se vuelve precisa. "Confirmar pedido" obliga a declarar precondiciones, disparador, curso normal, alternativos, garantías de éxito y garantía mínima. Cada uno de esos elementos puede revelar una decisión que el modelo visual no muestra. En Nexo, si una reserva falla por crédito o por stock, no debería quedar un pedido confirmado parcialmente ni cantidades retenidas sin dueño. Esa condición guía transacciones y pruebas más adelante.
include se justifica cuando un comportamiento común forma parte obligatoria de varios casos y conviene extraerlo para evitar duplicación conceptual. extend representa comportamiento adicional condicionado que amplía un caso base en un punto definido. Usarlos para mostrar orden temporal, llamar servicios internos o "decorar" reutilización produce diagramas formalmente atractivos y semánticamente confusos.
La evolución del caso de uso es parte de la enseñanza. Una primera versión puede ser incorrecta y útil si deja visible qué asumimos. La condición es no enamorarse del artefacto. Cada nuevo episodio debe intentar romperlo. Si un pedido real no puede recorrerse por el flujo sin inventar pasos, el caso está incompleto. Si aparecen ramas que solo existen por una pantalla elegida, se contaminó con diseño.
Qué puede hacer el agente: comparar consistencia entre actores, flujos, RN y escenarios; detectar alternativos mencionados en el texto pero ausentes en el diagrama; y buscar episodios que el caso no explica.
Qué no debe decidir: qué objetivo pertenece al negocio, cuándo una excepción merece su propio caso, ni valores BLOCKED. Un agente que "completa" el TTL con 24 horas está inventando una regla.
Contexto mínimo útil: la versión actual de CU-01 y CU-02, RN-01 a RN-05 y RN-07, y 3 a 5 episodios reales (48172, 48603, cliente de contado).
Cómo verificar: cada hallazgo debe señalar una línea del caso y un episodio concreto. Rechazá cualquier propuesta que agregue un estado, un actor o un número sin fuente.
Prompt de trabajo:
Actuá como revisor adversarial de CU-01 v4 y CU-02 (adjuntos).
Contexto: RN-01..RN-05 y RN-07 (BLOCKED), pedidos 48172 y 48603 (resumen adjunto).
1. Recorré cada pedido paso por paso y decime en qué paso el caso no lo puede explicar.
2. Para cada brecha indicá: línea afectada, evidencia que falta, y si pertenece al mismo objetivo.
3. Listá alternativos sin garantía mínima.
4. NO propongas valores para reglas BLOCKED. Si ves una dependencia de RN-07, marcala como bloqueada.
Respondé en una tabla: brecha | línea | pedido | propuesta (requiere aprobación humana).
Cuando recibas la salida, verificá que el agente no haya resuelto en silencio la reserva durante la espera, y que no haya movido el momento del "registrado" sin evidencia. Esos son los dos puntos donde un resumen plausible ocultaría una decisión.
Nexo B2B · CU-01 visto a través de cuatro pedidos reales
El pedido 48172 rompe v0. Antes de guardar hay que resolver códigos ambiguos, determinar precio, evaluar crédito y verificar stock. La versión 0 no es inútil: demuestra que el equipo había modelado una pantalla imaginada en lugar del objetivo del actor.
El pedido de un cliente de contado, que paga al retirar, rompe v1: el flujo de crédito no aplica igual y el caso se corrige para expresar una regla condicional según condición comercial, no una secuencia universal.
El pedido 48603 agrega otra presión. Tiene stock suficiente en el ERP, pero depósito encuentra un faltante durante picking. Ese evento ocurre después de la confirmación, por lo que no pertenece como alternativo interno de "Registrar pedido" si el objetivo ya terminó. Aparecen dos casos de depósito (CU-03 Preparar pedido y CU-04 Resolver quiebre de preparación), este último como extensión del primero. Esta decisión mejora la granularidad y evita que CU-01 intente explicar todo el ciclo de vida.
Cuando el equipo presenta CU-01 a la dueña, no le pide que apruebe UML. Le cuenta tres historias: pedido normal, pedido que excede crédito y pedido con última unidad. Señala qué debe ocurrir y qué nunca debe ocurrir. Marta puede discutir esas historias sin conocer símbolos. El diagrama queda como mapa para el equipo, la especificación textual como contrato y los ejemplos como puente con pruebas futuras.
Comprobá tu criterio
Un curso alternativo rechaza el pedido por crédito. ¿Qué falta si solo dice «mostrar error»?
En la sesión de validación, Laura aclara que una autorización de crédito 'no cambia el límite del cliente'. ¿Qué hacés con eso?
Errores frecuentes
| Síntoma | Causa | Corrección |
|---|---|---|
| CU-01 describe pantallas ("hace clic en Confirmar") | Se modeló la interfaz imaginada, como en v0 | Reescribí cada paso como diálogo actor-sistema y verificá que sobreviva a un cambio de interfaz |
| Rechazar por crédito destruye pedidos legítimos | El sobregiro se trató como error en lugar de resultado de negocio | Modelalo como PENDIENTE_AUTORIZACION y creá el caso del actor que decide (CU-02) |
| Una transición del modelo de estados no tiene caso de uso | Nadie preguntó quién la ejecuta | Para cada evento de la máquina de estados, nombrá el actor y el caso que lo dispara |
| El caso intenta explicar picking y despacho | Falta de criterio de fin del objetivo | Cortá donde el actor reconoce el resultado; lo posterior es otro caso (CU-03, CU-04) |
| La especificación incluye "24 horas" para la reserva | Se rellenó un vacío con una cifra plausible | Marcá RN-07 BLOCKED con responsables y definí el flujo sin el número |
| La validación con el cliente fue "¿está bien?" | Se leyó el documento en lugar de recorrer ejemplos | Armá tres historias con cifras (normal, sobre el límite, última unidad) y registrá cada respuesta |
Para llevarte
- CU-01 cambió cinco veces (v0 a v4) y cada cambio tuvo una evidencia y una fuente: registrarlo es parte del trabajo.
- El orden canónico del caso es validar, calcular precio, evaluar crédito y reservar en la misma unidad consistente.
- Un alternativo es un resultado de negocio con condición observable y efectos que no deben ocurrir, no un error genérico.
- Una transición sin dueño en la máquina de estados es una señal de que falta un caso de uso (CU-02).
- Marcá BLOCKED lo que depende de un dato que nadie confirmó (RN-07) y seguí especificando lo demás.
- Validá con ejemplos y episodios históricos; el cliente puede discutir pedidos, no notación.
¿Cómo valoras el contenido técnico de esta lección?
Tu feedback nos ayuda a mejorar los laboratorios prácticos de Eje Z.