BPMN y diagrama de actividad UML

Empecemos por lo que no está en disputa. Las dos notaciones describen un testigo que viaja por un flujo: sale de un inicio, atraviesa trozos de trabajo, se divide en una rama, espera en una unión y acaba deteniéndose. Ese modelo procede del mismo sitio en ambos casos, y por eso los dos diagramas de un proceso de aprobación sencillo son reconociblemente el mismo dibujo con distinto mobiliario.

Si tu proceso es una recta con dos decisiones, la comparación acaba aquí y deberías dibujar la que tus lectores ya conocen. Las diferencias de abajo solo empiezan a morder cuando entran en escena participantes, interrupciones o automatización, que es, todo hay que decirlo, la mayoría de los procesos reales.

1. La calle es una regla, no una etiqueta. Es la diferencia que más importa y de la que menos se repara. Una partición de actividad UML dice quién ejecuta una acción y nada más, así que el flujo de control cruza sus bordes con la misma libertad que cualquier otra cosa. Una calle de BPMN es un participante enteramente aparte, con su propio proceso, y BPMN prohíbe que el flujo de secuencia la cruce: la interacción entre calles tiene que ser un flujo de mensaje. Esa sola regla explica que un diagrama BPMN de dos organizaciones sea una afirmación sobre su independencia, mientras que el equivalente UML es una afirmación sobre reparto de roles.

2. La interrupción es de primera clase en BPMN. Adjunta un evento de borde a una tarea y habrás dicho, con una sola marca, que ese trabajo puede cortarse por un temporizador, un error o un mensaje entrante, y si el camino original continúa después. UML puede expresar lo mismo con una región de actividad interrumpible y una acción de aceptación de evento, pero la construcción se enseña poco, se dibuja poco y se lee bien pocas veces. En la práctica, si el proceso está lleno de escalados y plazos, BPMN lo dibuja con un tercio de la tinta. El vocabulario de eventos es la mayor parte de lo que estás comprando.

3. UML vive dentro de un modelo mayor. Un diagrama de actividad comparte su modelo con el diagrama de clases de al lado, así que una acción puede consumir un objeto de un tipo definido en otro sitio y una herramienta puede comprobar que ese tipo existe. BPMN tiene objetos de datos, pero son locales al proceso por diseño y no llevan detrás nada parecido a un modelo de clases. Si la descripción del proceso tiene que cuadrar con un diseño de sistema, ese vocabulario compartido vale más que cualquier función de notación.

4. Solo BPMN es ejecutable. BPMN 2.0 define una serialización XML que los motores de workflow consumen directamente, y por eso el mismo fichero puede ser una imagen para el negocio y un artefacto de despliegue para ingeniería. UML tiene fUML, un subconjunto ejecutable con semántica definida, y casi ningún motor que lo acepte. Trátalo como la única restricción dura de la lista: si hay un motor al final de la cadena, la notación es BPMN y el resto de este artículo es contexto.

La decisión casi siempre la toma el lector, no el proceso. Las dos notaciones pueden expresar cualquier proceso que vayas a dibujar; solo una la leerán de un vistazo las personas que tienen que aprobarlo.

Donde el público es de verdad mixto - y en un proyecto de cualquier tamaño suele serlo - dibuja el proceso una vez en BPMN para quienes son sus dueños y reserva el diagrama de actividad para las partes del flujo que son de verdad algoritmo y no proceso. Ese reparto va con el público en vez de contra él, y se defiende en revisión mucho mejor que un único diagrama que media sala no puede leer.

Las conversiones en ambos sentidos son rutina, y la manera honrada de hacer una es decidir de antemano qué estás dispuesto a perder. De BPMN a UML el control de flujo se traslada casi a la perfección: las tareas pasan a acciones, las compuertas exclusivas a nodos de decisión y de fusión, las paralelas a bifurcaciones y uniones, y las reglas de las compuertas se corresponden una a una. Lo que entregas es todo lo relativo a participantes y eventos.

En sentido contrario las pérdidas son menores, pero lo que se añade es trabajo: BPMN querrá un evento de inicio, un evento de fin y una calle por cada actor que habías modelado como partición, y se negará a dejar que el flujo de secuencia cruce esas calles. Esa negativa suele ser donde el ejercicio se paga solo, porque fuerza una pregunta que el diagrama de actividad te dejaba esquivar: ¿esto es un proceso o son dos?

Vayas en el sentido que vayas, lo caro es el redibujo, y eso es justo lo que elimina una herramienta con un modelo detrás de las imágenes: deja a los participantes y al trabajo como elementos del modelo y la segunda vista deja de ser un segundo dibujo. Si prefieres verlo antes que leerlo, la plantilla BPMN de partida abre un proceso con calles y carriles y los eventos ya colocados, y la demo de quince segundos devuelve un fichero real al terminar.