VPasCode: Diagramas de actividad UML con PlantUML – Un tutorial práctico

Un diagrama de actividad UML modela cómo fluye el trabajo a través de un proceso: las acciones realizadas, las decisiones tomadas, el trabajo paralelo y las rutas de finalización. PlantUML le permite describir ese modelo como texto y luego renderizarlo como un diagrama, un enfoque útil cuando desea diagramas que sean fáciles de revisar, examinar y mantener junto con la documentación del proyecto. La sintaxis actual de actividades de PlantUML utiliza palabras clave legibles como inicio, si, repetir, y bifurcación; su sintaxis de actividades más antigua aún es compatible, pero se recomienda la sintaxis más nueva para nuevos diagramas.

1. Qué modelar

Utilice un diagrama de actividad para explicar un proceso o algoritmo, por ejemplo:

• Un flujo de trabajo de pago de cliente

• Un proceso de aprobación

• Una tubería de importación de datos

• Los pasos en un caso de uso

• Trabajo dividido entre personas, equipos o componentes del sistema

Una actividad es una unidad de trabajo, como «Validar pedido». Un flujo de control conecta las actividades e indica su orden. Un decisión elige entre rutas alternativas; flujos paralelos muestran el trabajo que puede proceder concurrentemente. El diagrama debe aclarar el comportamiento, no intentar documentar cada detalle de implementación.

Una regla práctica útil: si la pregunta principal es «¿Qué sucede a continuación y bajo qué condición?», un diagrama de actividad es una buena opción.

2. Conceptos básicos de PlantUML

Un diagrama de PlantUML comienza con @startuml y termina con “@enduml. En la sintaxis de actividad actual:

• inicio marca el nodo inicial.

• :Acción; define una acción.

• si (...) entonces (...) ramifica según una condición.

• fin si cierra la condicional.

• detener finaliza un flujo.

• repetir y repetir mientras modela la repetición.

• bifurcar, bifurcar de nuevo, y fin bifurcación modela el trabajo en paralelo.

Las acciones se escriben en orden y están implícitamente conectadas. Puedes añadir etiquetas a las ramas y usar partición para agrupar el trabajo por responsabilidad o rol.

Aquí tienes un ejemplo mínimo:

@startuml
start
:Recibir solicitud;
:Validar solicitud;
stop
@enduml

3. Decisiones y rutas alternativas

Usar si cuando el proceso toma una decisión. Las etiquetas de las ramas deben comunicar los resultados de la condición, no simplemente repetir la condición.

@startuml
start
:Recibir pedido;
:Verificar inventario;

si (¿Todos los artículos disponibles?) entonces (Sí)
  :Reservar artículos;
  :Solicitar pago;
else (No)
  :Notificar al cliente;
  stop
endif

:Confirmar pedido;
stop
@enduml

Aquí, si introduce una decisión y endif la cierra. Las Sí y No etiquetas hacen visibles las alternativas. Cuando las rutas continúan hacia una acción compartida después de endif, se vuelven a unir al flujo.

Consejo de modelado: Sea explícito sobre lo que ocurre en cada resultado significativo. Si una ruta de error, tiempo de espera o rechazo es relevante para las partes interesadas, muéstrela en lugar de dejarla implícita.

4. Bucles y reintentos

Use un bucle cuando una acción o grupo de acciones pueda repetirse. Este ejemplo sigue solicitando entrada hasta que pasa la validación:

@startuml
start
:Leer datos enviados;

repeat
  :Validar datos;
  if (¿Válido?) then (Sí)
    :Guardar datos;
    break
  else (No)
    :Mostrar errores de validación;
    :Pedir al usuario que corrija los datos;
  endif
repeat while (¿El usuario continúa?) es (Sí) no (No)

stop
@enduml

Los bucles pueden ser difíciles de leer si su condición de salida es vaga. Indique qué provoca un nuevo intento y qué termina la repetición, especialmente cuando los reintentos son limitados o pueden cancelarse.

5. Trabajo paralelo y sincronización

Use fork cuando acciones independientes pueden ocurrir concurrentemente, y end fork cuando las rutas deben sincronizarse antes de que el proceso continúe.

@startuml
start
:Pedido confirmado;

fork
  :Enviar correo de confirmación;
fork again
  :Preparar lista de picking del almacén;
fork again
  :Actualizar panel de ventas;
end fork

:Marcar pedido como en proceso;
stop
@enduml

Un fork no significa necesariamente personas separadas; puede representar comportamiento concurrente del sistema. Úsalo solo cuando las acciones realmente puedan ocurrir en paralelo. Si una tarea debe terminar antes de que comience otra, modela las tareas de forma secuencial en su lugar.

6. Carriles con particiones

Las particiones agrupan acciones según el rol, equipo o sistema responsable. Esto puede hacer claras las transferencias sin cambiar el proceso en sí. PlantUML soporta agrupar actividades con partition.

@startuml
start

partition Cliente {
  :Enviar pedido;
}

partition "Servicio de Pedidos" {
  :Validar pedido;
  if (¿Pedido válido?) then (Sí)
    :Crear registro de pedido;
  else (No)
    :Devolver errores de validación;
    stop
  endif
}

partition Almacén {
  :Preparar envío;
}

partition "Servicio de Pedidos" {
  :Enviar confirmación;
}

stop
@enduml

Elige las etiquetas de carril que coincidan con la división real de responsabilidades. Evita crear una nueva partición para cada componente pequeño; demasiados carriles pueden hacer que el diagrama sea más difícil de escanear.

7. Objetos de datos y notas

Algunos flujos de trabajo se benefician de mostrar entradas o salidas importantes. Los diagramas de actividad de PlantUML admiten estereotipos de nodo de objeto; las notas también pueden añadir contexto sin convertir cada etiqueta de acción en un párrafo.

@startuml
start
:Recibir solicitud de pago;

:Autorizar pago;
nota derecha
  Utiliza la respuesta de autorización
  del proveedor de pagos.
fin nota

:Registrar resultado del pago;
stop
@enduml

Mantén las etiquetas de las actividades principales breves. Coloca las reglas de negocio, suposiciones o aclaraciones en las notas cuando los lectores las necesiten, pero no sean pasos en sí mismos del flujo.

8. Ejemplo completo: pago en línea

Este ejemplo más grande combina particiones, una decisión, un camino alternativo y trabajo en paralelo.

@startuml
título Pago en línea

start

partition Cliente {
  :Revisar carrito;
  :Enviar pago;
}

partition "Servicio de Pedidos" {
  :Validar carrito y dirección;

  if (¿Carrito y dirección válidos?) then (Sí)
    :Calcular total;
  else (No)
    :Mostrar errores de validación;
    stop
  endif
}

partition "Servicio de Pagos" {
  :Autorizar pago;

  if (¿Pago aprobado?) then (Aprobado)
    :Capturar pago;
  else (Rechazado)
    :Devolver fallo de pago;
    stop
  endif
}

partition "Servicio de Pedidos" {
  :Crear pedido;
}

fork
  partition "Servicio de Notificaciones" {
    :Enviar confirmación del pedido;
  }
fork again
  partition Almacén {
    :Poner pedido en cola para preparación;
  }
end fork

partition "Servicio de Pedidos" {
  :Mostrar confirmación del pedido;
}

stop
@enduml

Léelo de arriba a abajo: el cliente envía el pago, el servicio de pedidos lo valida, se autoriza el pago y se crea el pedido. Después, la confirmación y la preparación en el almacén se ejecutan en paralelo. Si la validación o el pago fallan, el flujo termina a través de la ruta de fallo correspondiente.

9. Flujo de trabajo de diagramas como código

Un flujo de trabajo práctico es:

Flujo de trabajo de diagramas como código

Un flujo de trabajo práctico es:

1. Describe el proceso en lenguaje sencillo. Identifica su inicio, fin, acciones principales, decisiones, excepciones, tareas en paralelo y roles responsables.

2. Escribe un primer borrador de PlantUML.Enfócate en la lógica antes del estilo.

3. Renderiza e inspeccionalo.Verifica que el resultado se lea de forma natural y que las ramas y los bucles sean comprensibles.

4. Revisa la lógica con las partes interesadas.El renderizado verifica la sintaxis, no si el proceso es correcto.

5. Revisa el código fuente y guárdalo junto con el proyecto.Los diagramas basados en texto son fáciles de comparar y revisar junto con otra documentación.

Para el renderizado local, la herramienta de línea de comandos de PlantUML puede generar archivos de diagramas; los editores basados en navegador son convenientes para borradores rápidos y vistas previas. PlantUML también ofrece un editor en navegador, mientras que VPasCode proporciona un editor basado en navegador con vista previa en vivo y soporte para diagramas de actividad de PlantUML.

1. Describe el proceso en lenguaje sencillo.Identifica su inicio, fin, acciones principales, decisiones, excepciones, tareas paralelas y roles responsables.

2. Escribe un primer borrador de PlantUML.Enfócate en la lógica antes del estilo.

3. Renderiza e inspeccionalo.Verifica que el resultado se lea de forma natural y que las ramas y los bucles sean comprensibles.

4. Revisa la lógica con las partes interesadas.El renderizado verifica la sintaxis, no si el proceso es correcto.

5. Revisa el código fuente y guárdalo junto con el proyecto.Los diagramas basados en texto son fáciles de comparar y revisar junto con otra documentación.

Para el renderizado local, la herramienta de línea de comandos de PlantUML puede generar archivos de diagramas; los editores basados en navegador son convenientes para borradores rápidos y vistas previas. PlantUML también ofrece un editor en navegador, mientras que VPasCode proporciona un editor basado en navegador con vista previa en vivo y soporte para diagramas de actividad de PlantUML.

10. Uso de Visual Paradigm VPasCode y asistencia de IA

VPasCode es el editor de texto a diagramas basado en navegador de Visual Paradigm. Su soporte de PlantUML incluye diagramas de actividad, y su editor proporciona renderizado en vivo. Visual Paradigm también describe la generación de diagramas con lenguaje natural integrada y la asistencia de IA para modificar o corregir el código del diagrama.

Un flujo de trabajo útil asistido por IA:

1. Solicita el comportamiento, no solo el tipo de diagrama.Por ejemplo:
   “Crea un diagrama de actividad de PlantUML para el proceso de pago en línea. Incluye la validación del carrito, la validación de la dirección, la autorización del pago, los caminos de fallo, la creación del pedido y la confirmación paralela por correo electrónico y la preparación en el almacén. Usa particiones para Cliente, Servicio de Pedidos, Servicio de Pago, Servicio de Notificaciones y Almacén. Usa la sintaxis actual de diagramas de actividad de PlantUML.”

2. Inspecciona el código generado.Verifica que utilice @startuml/@enduml, de que cada rama representa una condición real y que los caminos fallidos o alternativos están gestionados.

3. Rénderealo en VPasCode. Utiliza la vista previa para detectar errores de sintaxis, etiquetas confusas o diseños excesivamente complejos.

4. Refina el PlantUML tú mismo o con ediciones dirigidas por IA. Solicita un cambio específico, como «Añadir un camino de tiempo de espera de pago» o «Hacer que la preparación del almacén sea secuencial después de la creación del pedido».

5. Valida el proceso con alguien que lo conozca.La IA puede redactar un diagrama plausible, pero no puede establecer que el proceso real de tu organización sea correcto.

Los controles exactos y la disponibilidad de funciones de VPasCode pueden variar según la edición del producto; confirma las opciones actuales en el editor que estás utilizando.

11. Flujo de trabajo de modelado de Visual Paradigm

Usa VPasCode cuando quieras trabajar directamente con el código fuente del diagrama y la vista previa. Usa el entorno de modelado de Visual Paradigm cuando la tarea requiera edición gráfica o un trabajo de modelado más amplio. La guía de Visual Paradigm describe un flujo de trabajo de generar o importar un diagrama y luego refinarlo en el editor visual; las rutas de importación exactas pueden depender del producto y la versión.

Una entrega sensata es:

1. Borrador e iteración en PlantUML.

2. Comparte el diagrama renderizado y el código fuente para su revisión.

3. Ábrelo o impórtalo en el editor correspondiente de Visual Paradigm si necesitas edición visual u otras capacidades de modelado.

4. Mantén el código fuente de PlantUML como la versión mantenida si es la fuente de verdad elegida por el equipo; evita realizar silenciosamente ediciones conflictivas en dos lugares.

12. Errores comunes y lista de verificación de calidad

Antes de compartir un diagrama, verifica:

• ¿Tiene un inicio claro y un final significativo?

• ¿Describe cada acción una pieza de trabajo reconocible?

• ¿Están las decisiones claramente etiquetadas?

• ¿Se incluyen caminos de rechazo, error, tiempo de espera o cancelación donde son relevantes?

• ¿Las condiciones de bucle hacen claro el comportamiento de repetición y salida?

• ¿Las acciones paralelas son genuinamente independientes y se muestra la sincronización donde es necesario?

• ¿Las particiones representan límites de propiedad útiles?

• ¿Puede un lector entender el flujo sin leer etiquetas de acción largas?

• ¿El diagrama renderizado coincide con el proceso real?

Un buen diagrama de actividad no es el más largo ni el más detallado. Es el diagrama más pequeño que hace claros el flujo de trabajo, las decisiones, las responsabilidades y las excepciones importantes.

Referencia rápida de sintaxis

Los ejemplos utilizan la sintaxis actual de diagramas de actividad de PlantUML. Para construcciones poco comunes o comportamientos de renderizado específicos de versión, consulte la referencia de diagramas de actividad de PlantUML.