System Design
Diagramas de casos de uso
Explica cómo representar actores, objetivos y límites del sistema mediante diagramas de casos de uso sin convertirlos en flujos ni modelos de permisos.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo representar actores, objetivos y límites del sistema mediante diagramas de casos de uso sin convertirlos en flujos ni modelos de permisos.
Un diagrama de casos de uso es un mapa de objetivos y actores dentro de una frontera. Sirve para comunicar alcance y responsabilidades externas, no para describir orden temporal, pantallas ni arquitectura interna.
El diagrama responde tres preguntas:
¿quién interactúa?
¿qué objetivo persigue?
¿qué pertenece al sistema?Su valor está en resumir una vista que luego se desarrolla con especificaciones textuales, reglas, escenarios y pruebas.
En sistemas con muchos usuarios y capacidades, una lista plana no muestra:
Sin embargo, un diagrama incorrecto puede dar una falsa sensación de precisión y ocultar más de lo que comunica.
actor externo
→ persigue objetivo
→ usa comportamiento dentro de fronteraUn actor es un rol o sistema externo. No representa necesariamente una persona concreta ni una tabla de permisos.
Rectángulo que delimita los casos cuya responsabilidad pertenece al sistema estudiado. Sistemas externos quedan fuera como actores.
Rol humano, servicio, dispositivo o proceso que interactúa para obtener un resultado.
Objetivo expresado como verbo + resultado: Registrar venta, Consultar pedido, Reconciliar pago.
Indica que un actor participa en el caso. No expresa flujo de datos ni orden.
El caso base siempre utiliza otro comportamiento necesario.
Registrar venta
include → Calcular totalÚsalo cuando la subfunción tiene significado reutilizable. No fragmentes cada paso.
Añade comportamiento condicionado en un punto de extensión del caso base.
Aplicar descuento especial
extend → Registrar venta
condición: autorización del managerNo es sinónimo de “opcional” ni de una flecha temporal.
Un actor o caso especializado hereda relaciones relevantes. Debe existir sustitución semántica, no solo una jerarquía organizacional.
flowchart LR
Customer["Cliente"] --> Create(("Crear pedido"))
Customer --> Track(("Consultar estado"))
Operator["Operador"] --> Confirm(("Confirmar pedido"))
Operator --> Cancel(("Cancelar pedido"))
Manager["Manager"] --> Override(("Autorizar excepción"))
Payment["Pasarela de pago"] --> Process(("Procesar pago"))Mermaid aproxima la vista, pero no implementa formalmente toda la notación UML. Si include, extend o generalización son importantes, explícalos en texto o utiliza una herramienta UML apropiada.
Gestionar pedidos con Validar campo email.Pocos casos de alto nivel para comunicar alcance.
Casos de objetivo de usuario dentro de pedidos, pagos o inventario.
Subfunciones y relaciones para un área compleja.
Un solo diagrama con 40 casos y 15 actores suele ser menos útil que varias vistas coherentes.
Actores:
Objetivos:
Una mala versión agregaría Hacer clic en guardar, Validar formulario y Actualizar tabla, que son detalles del flujo o implementación.
Un sistema externo puede participar sin obtener el objetivo principal. Por ejemplo, la pasarela procesa pago mientras el cliente busca completar el pedido.
En la especificación textual, distingue actor principal y secundarios. El diagrama solo muestra asociaciones, por lo que el texto conserva esa semántica.
Antes de usar include, pregunta si el comportamiento realmente es un objetivo o subfunción reutilizable. Autenticar usuario no necesita aparecer incluido en todos los casos si es una condición transversal conocida; el diagrama se volvería ilegible.
Utiliza extend cuando el caso base es completo por sí mismo y otro comportamiento se activa bajo condición. Si el comportamiento siempre es necesario, corresponde include o parte del flujo principal.
Modela roles relevantes, no una persona duplicada. Una misma persona puede actuar como Cajero y Manager en momentos diferentes.
La frontera es del sistema, no de la empresa. Si está fuera del software diseñado, es actor externo.
Puede ser un job temporal o reacción a evento. Identifica el disparador; no todo comienza con una persona.
Varios actores pueden asociarse al mismo caso si persiguen el mismo resultado bajo diferencias menores.
El diagrama no reemplaza una matriz de autorización ni reglas de alcance.
La asociación no indica “primero” o “después”. Usa activity o sequence diagram.
Crear, leer, editar, eliminar pueden ocultar intenciones distintas. Usa lenguaje del dominio.
Suele indicar actores demasiado genéricos o casos demasiado amplios.
Base de datos y servicio interno no son actores en una vista de sistema si forman parte de la frontera.
include y extend decorativos añaden ruido y semántica falsa.
No cubre reglas, garantías, datos ni errores.
Aporta al definir alcance, iniciar conversaciones con stakeholders y organizar casos. Puede omitirse en sistemas pequeños donde una tabla actor–objetivo comunica mejor. No produzcas UML por obligación.
include, extend y generalización tienen semántica específica.include y extend.Modelado de procesos: as-is y to-be muestra cómo esos objetivos atraviesan personas, sistemas y handoffs en la operación real.