17. Carriles, acciones, objetos y señales en diagramas de actividades

17.1 Introducción

En un diagrama de actividades, las acciones y decisiones permiten describir un flujo básico. Sin embargo, muchos procesos necesitan más precisión: quién realiza cada acción, qué información se produce o consume, qué evento dispara una parte del proceso y qué señal se envía a otro participante.

Para expresar esos detalles, UML ofrece carriles, nodos de objeto y señales. Estos recursos ayudan a conectar el flujo con responsabilidades, datos y eventos, sin transformar el diagrama en una especificación técnica excesiva.

17.2 Carriles

Los carriles, también conocidos como swimlanes, dividen el diagrama según responsables. Cada carril puede representar una persona, un rol, un área, un sistema, una aplicación o un componente. Las acciones se ubican dentro del carril que corresponde al responsable de ejecutarlas.

Por ejemplo, en un proceso de compra pueden existir carriles para Cliente, Sistema, Pasarela de pago y Depósito. Esto permite ver rápidamente qué parte del proceso realiza cada participante.

17.3 Responsables, datos y eventos en actividades

Un diagrama de actividades puede mostrar responsables mediante carriles, pasos mediante acciones, información mediante nodos de objeto y comunicaciones mediante señales. Estos elementos permiten describir procesos más completos sin perder la lectura general del flujo.

17.4 Cuándo usar carriles

Conviene usar carriles cuando la responsabilidad de las acciones es importante. Si el proceso involucra varios roles, áreas o sistemas, los carriles ayudan a evitar confusiones. También permiten detectar transferencias entre responsables y pasos que quizá estén asignados al participante incorrecto.

No siempre son necesarios. Si todo el flujo pertenece a un único sistema o si la responsabilidad no es relevante para el objetivo del diagrama, los carriles pueden omitirse.

17.5 Carriles por rol

Un carril puede representar un rol de negocio. Por ejemplo, Paciente, Recepcionista, Médico o Administrador. Esta organización es útil cuando se quiere comprender un proceso desde el punto de vista de sus participantes humanos o externos.

Los carriles por rol ayudan a detectar tareas manuales, aprobaciones, validaciones y transferencias de responsabilidad dentro de un proceso.

17.6 Carriles por sistema o componente

También pueden usarse carriles para representar sistemas o componentes. Por ejemplo, Aplicación web, Servicio de turnos, Pasarela de pago y Sistema de notificaciones. Esta organización es más cercana al diseño de software.

Es importante no mezclar criterios sin aclaración. Si algunos carriles son personas y otros son componentes técnicos, el diagrama puede volverse confuso, salvo que esa mezcla sea intencional y útil para explicar la interacción.

17.7 Acciones

Las acciones son pasos concretos del proceso. Deben nombrarse con verbos claros: Validar datos, Registrar solicitud, Calcular importe, Enviar confirmación, Generar factura. Una acción debe ser comprensible dentro del contexto del proceso.

El tamaño de una acción depende del nivel de detalle. En un diagrama de alto nivel, "Procesar pago" puede ser una acción suficiente. En un diagrama más detallado, ese paso puede dividirse en validar datos, solicitar autorización, registrar resultado y emitir comprobante.

17.8 Acciones demasiado grandes o pequeñas

Una acción demasiado grande oculta decisiones importantes. Una acción demasiado pequeña convierte el diagrama en una lista extensa de operaciones mínimas. El equilibrio depende del propósito del modelo.

Si una acción contiene muchas reglas, alternativas o participantes, tal vez convenga descomponerla en otro diagrama. Si varias acciones son pasos triviales sin valor para la comprensión, pueden agruparse.

17.9 Objetos en diagramas de actividades

Los nodos de objeto representan información que se produce, consume o modifica durante el flujo. Pueden representar documentos, solicitudes, pedidos, turnos, comprobantes, archivos o cualquier elemento relevante para el proceso.

Por ejemplo, después de la acción Registrar turno puede aparecer el objeto Turno reservado. Después de Procesar pago puede aparecer Comprobante de pago. Esto ayuda a ver qué información surge de cada paso.

17.10 Flujos de objeto

Un flujo de objeto muestra cómo un objeto pasa de una acción a otra. A diferencia del flujo de control, que indica el avance del proceso, el flujo de objeto resalta datos o elementos que se transforman o se entregan.

Por ejemplo, una Solicitud de inscripción puede ser revisada, aprobada y luego convertirse en Inscripción confirmada. Mostrar estos objetos permite entender mejor qué información se maneja.

17.11 Estados de objetos

Un objeto puede mostrarse con un estado entre corchetes. Por ejemplo, Turno [reservado], Pedido [pagado] o Solicitud [rechazada]. Esto permite indicar cómo cambia la situación del objeto dentro del flujo.

Si el objetivo principal es estudiar todos los estados posibles y sus transiciones, conviene usar un diagrama de estados. En actividades, los estados de objeto se usan para aclarar puntos concretos del proceso.

17.12 Señales

Las señales representan comunicaciones o eventos. Una acción puede enviar una señal y otra parte del sistema puede recibirla. Esto es útil cuando el proceso depende de eventos externos o cuando una acción notifica a otro participante.

Por ejemplo, después de registrar un turno, el sistema puede enviar una señal de Notificación solicitada. Otro componente puede recibirla y encargarse de enviar el mensaje al paciente.

17.13 Recepción de señales

La recepción de una señal indica que el flujo espera o responde a un evento. Por ejemplo, recibir confirmación de pago, recibir aprobación de una solicitud o recibir una respuesta de un sistema externo.

Este recurso ayuda a modelar procesos que no dependen únicamente de acciones internas. También permite representar esperas o interrupciones sin forzar una secuencia lineal.

17.14 Envío de señales

El envío de una señal indica que el proceso comunica algo a otro participante o sistema. Por ejemplo, enviar solicitud de pago, enviar recordatorio, emitir alerta o publicar evento de pedido confirmado.

El envío de señales es útil en procesos donde existen notificaciones, eventos asincrónicos o integraciones con otros sistemas.

17.15 Ejemplo: solicitud de turno

En una solicitud de turno, pueden existir carriles para Paciente, Sistema de turnos y Sistema de notificaciones. El paciente selecciona especialidad y horario. El sistema registra el turno y produce el objeto Turno [reservado]. Luego envía una señal para solicitar el envío de una confirmación.

Este diagrama permite ver responsabilidades, datos generados y comunicación con otro sistema en una única vista.

17.16 Ejemplo: aprobación de solicitud

En un proceso de aprobación, una persona carga una solicitud, el sistema la registra, un responsable la revisa y decide aprobarla o rechazarla. El objeto Solicitud puede pasar por estados como [pendiente], [aprobada] o [rechazada].

Los carriles muestran quién realiza cada acción, y los objetos muestran cómo cambia la información durante el proceso.

17.17 No saturar el flujo

Carriles, objetos y señales agregan información valiosa, pero también aumentan la complejidad visual. Si se incluyen en exceso, el diagrama puede volverse difícil de leer.

Conviene agregar solo los elementos que aportan a la pregunta del diagrama. Si se quiere explicar responsabilidades, los carriles son importantes. Si se quiere explicar transformación de información, los objetos ayudan. Si se quiere explicar eventos, las señales son útiles.

17.18 Criterios de revisión

• ¿Los carriles representan responsables con un criterio claro?
• ¿Cada acción está ubicada en el carril correcto?
• ¿Las acciones tienen nombres claros y proporcionales al nivel del diagrama?
• ¿Los objetos mostrados aportan información relevante?
• ¿Los estados de objetos ayudan a entender cambios importantes?
• ¿Las señales representan eventos o comunicaciones reales?
• ¿El diagrama sigue siendo legible después de agregar estos elementos?

17.19 Errores frecuentes

• Crear carriles sin criterio consistente.
• Ubicar acciones en responsables incorrectos.
• Mezclar roles humanos, capas técnicas y módulos sin aclarar la intención.
• Mostrar objetos que no aportan al entendimiento del flujo.
• Usar señales para representar cualquier flecha del proceso.
• Agregar demasiados estados de objetos en un diagrama que debería ser simple.
• Confundir un diagrama de actividades con un diagrama de secuencia.

17.20 Qué debes recordar de este tema

• Los carriles indican responsables de las acciones.
• Las acciones representan pasos del proceso.
• Los objetos muestran información producida, consumida o modificada.
• Los estados de objeto permiten indicar cambios relevantes durante el flujo.
• Las señales representan eventos o comunicaciones.
• Estos recursos deben usarse solo cuando agregan claridad al proceso.

17.21 Conclusión

Los carriles, objetos y señales permiten enriquecer un diagrama de actividades. Gracias a ellos, el flujo puede mostrar no solo qué pasos ocurren, sino también quién los realiza, qué información circula y qué eventos participan.

En el próximo tema veremos diagramas de estados, que permiten representar el ciclo de vida de objetos importantes.