System Design
Diagramas de actividad
Explica cómo representar flujos, decisiones, paralelismo, responsabilidades y excepciones mediante diagramas de actividad aplicados al comportamiento del sistema.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo representar flujos, decisiones, paralelismo, responsabilidades y excepciones mediante diagramas de actividad aplicados al comportamiento del sistema.
Un diagrama de actividad muestra cómo avanza un flujo mediante acciones, decisiones, ciclos, responsabilidades y trabajo paralelo. Su valor está en hacer visible la lógica del proceso, no en decorar documentación.
Activity Diagram responde:
¿qué camino sigue el proceso?
¿qué condiciones cambian el camino?
¿qué actividades pueden ocurrir en paralelo?
¿quién es responsable?Puede representar procesos de negocio, casos de uso, algoritmos de alto nivel o coordinación operativa.
Una descripción textual extensa dificulta detectar:
El diagrama ofrece una vista navegable, pero necesita explicación y artefactos relacionados para conservar reglas y garantías.
Marcan comienzo y terminación. Varios finales pueden representar resultados distintos, pero deben nombrarse o explicarse.
Trabajo atómico al nivel del diagrama: Validar pedido, Reservar stock, Solicitar pago.
Una decisión divide por condiciones mutuamente comprensibles; merge reúne caminos alternativos.
Fork inicia actividades paralelas; join espera su sincronización. No confundas una lista de tareas con ejecución simultánea real.
Indica qué actividad puede comenzar después de otra.
Puede mostrar datos que se producen o consumen cuando aporta claridad.
Separan responsabilidades entre actores, áreas o sistemas.
acción
→ decisión [condición]
→ uno o varios caminos
→ sincronización
→ resultadoEl diagrama no muestra mensajes detallados entre componentes; para eso se utiliza un Sequence Diagram.
flowchart TD
Start((Inicio)) --> Validate[Validar pedido]
Validate --> Valid{¿Datos válidos?}
Valid -->|No| Reject[Rechazar con errores]
Reject --> EndRejected((Fin rechazado))
Valid -->|Sí| Stock[Intentar reservar stock]
Stock --> Available{¿Reserva completa?}
Available -->|No| Release[Revertir reservas parciales]
Release --> NotifyOut[Informar falta de stock]
NotifyOut --> EndRejected
Available -->|Sí| Pay[Solicitar pago]
Pay --> Paid{¿Pago confirmado?}
Paid -->|No| Release2[Liberar reserva]
Release2 --> Pending[Registrar pago pendiente o rechazo]
Pending --> EndRejected
Paid -->|Sí| Confirm[Confirmar pedido]
Confirm --> Fork[Iniciar efectos posteriores]
Fork --> Notify[Enviar notificación]
Fork --> Prepare[Enviar a preparación]
Notify --> Join[Sincronización no requerida para respuesta]
Prepare --> Join
Join --> EndOk((Fin exitoso))Cada salida debe tener guard:
[stock suficiente]
[stock insuficiente]Evita sí/no cuando la pregunta no está visible o cuando existen más de dos resultados.
Las condiciones deben ser completas y no solaparse accidentalmente.
Utiliza fork solo si las ramas pueden progresar simultáneamente sin dependencia inmediata.
Ejemplo:
confirmar pedido
→ publicar evento
→ generar comprobanteSi generar comprobante necesita el resultado del evento, no son paralelas.
El join puede esperar todas las ramas o una condición específica según la notación y el proceso. Explica la semántica para evitar suposiciones.
Ejemplo conceptual:
Cliente | Sistema | Operaciones | PasarelaPermiten ver transferencias de responsabilidad. Muchas flechas entre lanes pueden indicar acoplamiento, espera o proceso fragmentado.
No uses lanes para capas técnicas si la audiencia necesita proceso de negocio; crea otra vista técnica.
Muestra camino, decisiones y paralelismo.
Muestra participantes y mensajes ordenados.
Muestra estados válidos de una entidad y eventos de transición.
Ofrece semántica más rica para timers, mensajes, errores, compensación y procesos organizacionales.
Selecciona el diagrama según la pregunta, no según preferencia visual.
Un ciclo debe indicar:
reintentar pago [intentos < 3 y error transitorio]
→ esperar backoff
→ volver a solicitarUn loop sin límite puede esconder riesgo operacional.
No dibujes cada error posible. Incluye los que cambian responsabilidad, estado o resultado:
Los detalles técnicos menores pueden vivir en contratos o runbooks.
Preparar pedido, Asignar entrega.
Reservar inventario, Confirmar pago.
Insertar outbox, Publicar evento.
No mezcles los tres sin propósito. Un diagrama puede enlazar otro de mayor detalle.
Puede ser válida si termina el proceso; si no, probablemente hay flujo incompleto.
Quizá una tabla de decisión comunica mejor.
Representa espera, timeout y escalamiento; no como una acción instantánea.
BPMN o state machine puede ser más adecuado.
Define qué ramas se detienen y cuáles compensan.
Indica colección, errores parciales y política de continuación.
El lector no puede comprender por qué se elige una rama.
Validación es menos claro que Validar pedido.
Puede implicar garantías y sincronización inexistentes.
Divide por subprocesos con entradas y salidas claras.
Pierde valor de diseño y envejece rápido.
El flujo parece correcto, pero no explica qué queda persistido.
Mermaid ayuda a comunicar; no siempre preserva toda la semántica formal.
Conviene para workflows, aprobaciones, procesos con ramas y coordinación. Para una interacción lineal entre pocos componentes, sequence diagram suele ser mejor. Para lifecycle persistente, state diagram.
Escenarios e interacciones narra casos concretos en orden temporal antes de representar mensajes técnicos.