System Design
Casos de uso
Explica cómo modelar objetivos completos mediante actores, precondiciones, flujo principal, alternativas, excepciones y postcondiciones.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo modelar objetivos completos mediante actores, precondiciones, flujo principal, alternativas, excepciones y postcondiciones.
Los casos de uso desarrollan el comportamiento de extremo a extremo desde la perspectiva del actor principal.
actor + objetivo + trigger
→ interacción con el sistema
→ alternativas y excepciones
→ garantía mínima o de éxitoSirven cuando una historia breve no alcanza para explicar un flujo con varios estados, reglas o participantes.
“Registrar venta” puede ocultar búsqueda de productos, validación de caja, cálculo, pago, inventario, comprobante y recuperación ante fallos. Si solo se documenta el happy path, el diseño queda incompleto.
El caso de uso obliga a responder:
objetivo del actor
→ contrato de interacción
→ sistema protege reglas y estado
→ resultado observableEl caso de uso no debe describir cada clic. Se mantiene estable aunque cambie la interfaz o el framework.
Usa verbo + resultado: Registrar venta, Transferir inventario, Solicitar devolución.
Mezclar niveles produce diagramas y documentos incoherentes.
Quien obtiene el resultado. Puede ser persona, sistema o proceso automático.
Evento que inicia: solicitud, fecha, mensaje o condición.
Condiciones conocidas antes de empezar. No deben convertirse en excusa para omitir validación.
Qué permanece cierto incluso si el objetivo no se completa.
Estado final cuando se completa correctamente.
Secuencia más común y comprensible.
Alternativas, errores, timeouts, permisos, duplicados y concurrencia.
ID y nombre:
Nivel:
Objetivo:
Actor principal:
Actores secundarios:
Trigger:
Precondiciones:
Garantía mínima:
Garantía de éxito:
Flujo principal:
Extensiones por paso:
Reglas relacionadas:
Datos afectados:
Frecuencia y criticidad:
Preguntas abiertas:CU-04: Registrar venta
Actor principal: Cajero
Trigger: el cliente presenta productos para pagar
Precondiciones: sesión válida y caja abierta
Garantía mínima: una venta fallida no altera inventario ni caja
Garantía de éxito: venta, líneas, pago y movimientos quedan registrados de forma consistenteCada extensión debe indicar desde qué paso ocurre y cómo continúa o termina.
La garantía mínima evita estados parciales:
si el pago falla
→ no confirmar venta
→ no descontar stock definitivamente
→ conservar correlación para reconciliar si el resultado es inciertoNo siempre todo puede ser una única transacción. Cuando hay servicios externos, el caso de uso debe describir estados intermedios y compensación.
El caso base siempre incorpora otro comportamiento necesario. Úsalo para reutilización real, no para dividir cada paso.
Un comportamiento adicional se activa bajo una condición en un punto definido. No significa simplemente “opcional”.
Un actor o caso especializado hereda relaciones y añade diferencias. Evita jerarquías que solo reflejan organigrama.
Estas relaciones pertenecen al modelo UML; no expresan secuencia temporal.
Una historia puede implementar una parte del caso. Un proceso puede incluir Registrar pedido, Preparar pedido y Entregar pedido.
Valida en el punto de decisión crítico, no solo al iniciar.
La precondición observada no garantiza que siga igual; protege la transición.
Modela estado pendiente, reconciliación e idempotencia.
Debe devolver el resultado existente o continuar de forma segura.
Puede abarcar horas o días; persiste estado y eventos, no mantiene una transacción abierta.
Define desde qué estados, efectos y compensaciones.
Editar pedido puede mezclar objetivos diferentes. Nombra la intención real.
Hace el caso frágil ante cambios de canal.
Oculta la mayor parte del diseño operativo.
Enlaza una fuente de reglas para evitar duplicación.
Un caso lógico no necesita repositorios ni tablas. Añádelos en secuencias técnicas cuando sean relevantes.
Si contiene varios objetivos independientes, sepáralo por nivel.
Aporta cuando hay múltiples pasos, estados, actores, reglas o integraciones. Para CRUD simple con pocos riesgos, una historia y criterios pueden ser suficientes.
Guardar formulario es un mal nombre de caso de uso?include?Diagramas de casos de uso resume visualmente actores, objetivos y frontera sin sustituir esta especificación textual.