|
|
Compuerta Inclusiva - Ejemplo
Por ejemplo, para cumplir con una orden de trabajo hay que analizar cuántas HH se requieren, y si es o no posible cubrirlas con el personal contratado, o si se requieren horas extras y/o contratar personal adicional.
Puede que se requieran pocas HHs y haya horas normales disponibles para cubrirlas, en ese caso solo se ejecutará la Tarea Asignar personal disponible. En otra situación, puede no haber horas normales disponibles, pero sí suficientes horas extras disponibles, entonces solo se ejecutará Autorizar horas extras.
Pueden darse todas las combinaciones, incluso puede ser necesario Asignar personal disponible, Autorizar horas extras y, además, Contratar personal externo en caso que haya horas normales y extras disponibles, pero no sean suficientes para cubrir las necesidades.
La decisión de cómo cubrir las HH necesarias se toma en la Tarea Cuantificar el Trabajo. Después se pasa a la Compuerta Inclusiva Divergente que indica los tres caminos posibles, de los cuales se pueden tomar uno, dos e incluso los tres en forma paralela. A continuación, la Compuerta Inclusiva Convergente sincroniza los caminos tomados. Finalmente, se ejecuta Asignar tareas, y el Proceso finaliza.
Compuerta Inclusiva Configuración Divergente
La Compuerta Inclusiva Divergente tiene la siguiente Configuración:
- Un Flujo de Secuencia de Entrada.
- Dos o más Flujos de Secuencia de Salida.
- Opcionalmente, uno de los Flujos de Secuencia de Salida es un Flujo por Defecto. Este Flujo se marca con una línea diagonal y es Incondicional. Si tiene una Condición, es ignorada. Solo puede haber un Flujo por Defecto.
- Cada Flujo de Secuencia de Salida, excepto el Flujo por Defecto, tiene una Condición.
- Todas las Condiciones son independientes.
La Compuerta no tiene asociada una Condición, son los Flujos de Secuencia salientes los que tienen Condiciones.
El Flujo por Defecto actúa como un "mecanismo de escape", es decir, para asegurar que el Proceso pueda continuar en caso de que todas las Condiciones de los demás Flujos sean falsas.
Nótese que la configuraciones de la Compuertas Inclusiva y Exclusiva Divergentes son similares, solo difieren en que en la Exclusiva los Flujos de Salida están ordenados para poder saber cuándo terminar la evaluación de las Condiciones.
Compuerta Inclusiva - Configuración Divergente
Compuerta Inclusiva Funcionamiento Divergente
Cuando llega un Token a una Compuerta Inclusiva Divergente:
- Las Condiciones se evalúan en cualquier orden.
- El proceso continúa por todos los Flujos cuya Condición es verdadera.
- Si ninguna Condición es verdadera se sigue el Flujo por Defecto, si existe. Si no existe, entonces el Proceso no puede continuar, se considera un Modelo Inválido.
La Compuerta Inclusiva Divergente implementa la Divergencia Inclusiva.
Por ejemplo, si la Compuerta tiene tres Flujos de Salida, con un Flujo por Defecto, entonces habrá 4 posibles ejecuciones. Cuando ambas condiciones son falsas, se sigue el Flujo por Defecto. Cuando ambas condiciones son verdaderas, se siguen ambos Flujos. Cuando solo una de las Condiciones es verdadera, se sigue ese Flujo.
Compuerta Inclusiva - Funcionamiento Divergente
Si la Compuerta tiene n Flujos de Salida distintos al Flujo por Defecto, entonces habrá 2n casos. En el ejemplo n = 2, entonces hay 4 casos. Para n = 3, pasan a ser 8. El Flujo por Defecto cubre el caso cuando todas las Condiciones son falsas.
Si tiene Flujo por Defecto, entonces debe tener a lo menos dos Flujos Condicionales. Si solo tuviera un Flujo Condicional se comportaría como una Compuerta Exclusiva Binaria.
Buenas Prácticas
Puesto que las Condiciones son independientes, en una misma Compuerta Inclusiva Divergente podrían mezclase varios dominios. Por ejemplo, algunas Condiciones podrían referirse a rangos de precios, otras a tipos de cliente, etc.
Buenas Prácticas para facilitar el modelado y lectura de la Compuerta Inclusiva Divergente:
- Todas las Condiciones están lógicamente relacionadas entre sí. A menudo referidas a una característica de un objeto del negocio: diferentes estados de una factura, diferentes rangos de precios, etc.
- Junto a la Compuerta se coloca una frase, posiblemente en forma de pregunta, que describe el conjunto de las Condiciones.
- Las Condiciones no son mutuamente excluyentes. Es decir, varias Condiciones pueden ser verdaderas al mismo tiempo.
- En lo posible, el conjunto de las Condiciones cubre todas las variantes posibles. Es decir, en una situación normal, el Proceso siempre puede proseguir.
- El Flujo por Defecto, si se usa, indica el camino a seguir cuando todas las Condiciones son falsas.
Por ejemplo, al vender un producto se pueden ofrecer servicios adicionales: envío, ensamblado, garantía extendida. El cliente puede elegir algunos o todos los servicios adicionales.
Compuerta Inclusiva - Buenas Prácticas
Flujo por Defecto
Si las Condiciones cubren todo el rango de posibilidades y siempre se cumple a lo menos una de ellas, entonces no es necesario un Flujo por Defecto, ya que el Proceso siempre puede continuar.
En el ejemplo anterior se asume que el cliente alige al menos un servicio adicional, pero cabe la posibilidad de que no elija ninguno. Entonces sí es necesario agregar un Flujo por Defecto.
BPMN indica que, si el Flujo por Defecto tiene una Condición, ésta es ignorada. En este caso, la Condición actúa como un rótulo que explica al lector del diagrama por qué se sigue ese camino.
Compuerta Inclusiva - Flujo por Defecto
En la Compuerta Exclusiva, cuando todas las Condiciones son mutuamente excluyentes, el Flujo por Defecto se puede usar para resaltar el Flujo de Salida más importante y/o frecuente. Sin embargo, en la Compuerta Inclusiva esto no es posible, pues en caso de que una de la Condiciones sea verdadera, se seguirá el respectivo Flujo y no el Flujo por Defecto, aunque éste tenga un rótulo que parezca ser "verdadero".
Si en el ejemplo anterior cambiamos el Flujo Condicional Envío por un Flujo por Defecto, el comportamiento de la Compuerta no será el correcto.
Compuerta Inclusiva - Flujo por Defecto
Flujos Condicionales
Una Compuerta Inclusiva divergente puede ser vista como un conjunto de "decisiones binarias" (Sí/No) independientes, pero relacionadas. Dado que cada camino es independiente, se pueden tomar todas las combinaciones, desde cero hasta todos. Sin embargo, debe diseñarse de modo que siempre se tome al menos un camino.
Usando Flujos de Secuencia Condicionales (marcados con mini-rombos) desde una Actividad, se logra el mismo comportamiento que una Compuerta Inclusiva divergente.
Compuerta Inclusiva vs Flujos Condicionales
Compuerta Inclusiva Configuración Convergente
La Compuerta Inclusiva Convergente sincroniza varios Flujos de Secuencia alcanzables, es decir, aquellos por los cuales debe, en algún momento, llegar un Token. A veces funciona como una Paralela Convergente, pues todos los Flujos son alcanzables, en otros casos debe esperar Tokens por solo un subconjunto de los Flujos.
Como toda Compuerta Convergente, la Compuerta Inclusiva Convergente tiene dos o más Flujos de Secuencia entrantes y un Flujo de Secuencia saliente.
Compuerta Inclusiva - Configuración Convergente
Compuerta Inclusiva Funcionamiento Convergente
Al llegar un Token a una Compuerta Inclusiva Convergente se debe determinar si es necesario esperar o no para sincronizarlo con otros Tokens que llegarán después por otros Flujos.
- Cuando llega el primer Token a la Compuerta comienza un chequeo permanente para determinar si hay que esperar más Tokens.
- Los Flujos por los que aún no han llegado Tokens se separan en dos grupos: aquellos por los que puede, más adelante, llegar un Token (alcanzables), y los que jamás recibirán un Token (no alcanzables).
- Un Flujo es alcanzable si al seguirlo en sentido inverso es posible encontrar un Token, en caso contrario, es no alcanzable.
- Un Flujo alcanzable puede pasar a ser no alcanzable.
- La espera termina cuando todos los Flujos tienen Token, o los Flujos que aún no tienen Token son no alcanzables.
La Compuerta Inclusiva Convergente funciona con "información global", esto significa que necesita conocer el estado de todos los caminos que llegan hasta sus Flujos de Entrada para determinar si puede o no llegar un Token por ellos. Esto la diferencia de las Compuertas Exclusiva y Paralela que funcionan con "información local", es decir, no necesitan saber lo que ocurre en el resto del Proceso, les basta conocer si hay o no Tokens en sus Flujos de Entrada.
La Compuerta Inclusiva Convergente implementa la Convergencia Inclusiva.
Compuerta Inclusiva - Funcionamiento Convergente
El funcionamiento de la Compuerta Inclusiva Convergente se ve con claridad en un Bloque Inclusivo Cerrado: a la Compuerta Inclusiva Convergente llegan los Tokens que fueron generados por la Inclusiva Divergente.
En el siguiente ejemplo, cuando ambas Condiciones son verdaderas, la Compuerta Divergente genera dos Tokens. Cuando la Compuerta Convergente recibe el primer Token debe esperar el segundo que llegará en algún momento.
Compuerta Inclusiva - Funcionamiento Convergente
En el siguiente ejemplo, de la Compuerta Inclusiva Divergente salen tres Tokens. Cuando llega el Token a la Inclusiva Convergente desde la Actividad C, y los otros dos están en B y D, los tres Flujos de Entrada restantes son alcanzables. El Token que está en D puede llegar a través de E o F.
Sin embargo, cuando el Token en D pasa por la Compuerta Exclusiva tomará solo uno de los caminos y llegará la Inclusiva, entonces el otro camino será no alcanzable. Por ejemplo, si se cumple la Condición 4, el Token llega a E y de ahí a la Inclusiva Convergente. Ahora el camino A 🠊 Compuerta 🠊 Condición 3 🠊 D 🠊 Compuerta 🠊 Condición 5 🠊 F no tiene ningún Token, por lo tanto es no es alcanzable.
Compuerta Inclusiva - Funcionamiento Convergente
El lector habrá notado que colocando una compuerta Exclusiva Convergente después de E y F solo llegarán tres Flujos a la Inclusiva Convergente, que serán siempre alcanzables. Ambos modelos son equivalentes, pero es más recomendable usar el Bloque Exclusivo Cerrado en el camino inferior.
Compuerta Inclusiva en modelos no estructurados
Habíamos dicho que un Flujo es alcanzable si al seguirlo en sentido inverso es posible encontrar un Token, en caso contrario, es no alcanzable. Esta definición es válida para los modelos vistos hasta ahora, en los que los caminos que llegan a la Compuerta Inclusiva no se mezclan, ni pasan por la Compuerta misma (dentro de un ciclo). Este es el tipo de modelos recomendados por las Buenas Prácticas.
Sin embargo, BPMN permite crear modelos complejos que requieren una definición más estricta de las condiciones de activación de la Compuerta Inclusiva Convergente.
La Especificación de BPMN (p. 436) indica que:
La Compuerta Inclusiva es activada si
- Al menos un Flujo de Secuencia entrante tiene al menos un Token y
-
Para cada camino directo de Flujos de Secuencia que
- - comienza con un Flujo de Secuencia f que tiene un Token,
- - termina con un Flujo de Secuencia entrante de la Compuerta Inclusiva que no tiene Token, y
- - no pasa por la Compuerta Inclusiva.
-
También hay otro camino directo de Flujos de Secuencia que
- - comienza con f,
- - termina con un Flujo de Secuencia entrante de la Compuerta Inclusiva que tiene un Token, y
- - no pasa por la Compuerta Inclusiva.
Al activarse, se consume un Token por cada Flujo de Secuencia Entrante que tiene un Token.
Según esta definición, no es necesario esperar algunos Tokens "alcanzables" cuando éstos tienen caminos para llegar a Flujos de Entrada que ya tienen un Token.
En un Bloque estructurado cada camino que sale de la Compuerta Divergente sigue de manera independiente hasta llegar a la Compuerta Convergente. Es decir, no hay Flujos de Secuencia que entran o salen del Bloque, y tampoco hay Flujos de Secuencia entre sus caminos internos.
Por su parte, un Bloque que no cumple las restricciones anteriores es un Bloque no Estructurado. El siguiente diagrama muestra un Bloque Inclusivo Cerrado no estructurado.
Compuerta Inclusiva - Bloque no Estructurado (a)
En modelos no estructurados la Compuerta Inclusiva Convergente puede tener un funcionamiento contraintuitivo.
Cuando de la Compuerta Divergente salen dos Tokens (ambas condiciones son verdaderas), en la versión estructurada sólo hay dos posibles escenarios: la Compuerta recibe primero el Token desde E y espera el que llega desde F, y viceversa. Sin embargo, en la versión no estructurada hay seis escenarios posibles. Veamos con detalle cada uno de ellos.
El comportamiento análogo a un Bloque Inclusivo Cerrado estructurado ocurre cuando (1) llega primero el Token por E y la Compuerta espera que llegue el otro desde F, y (2) cuando llega primero por F y el otro Token ya está en E. En ambos casos la Compuerta sincroniza los Tokens y G se ejecuta una vez.
Nótese que el comportamiento no es simétrico: cuando llega primero por el camino superior, da lo mismo dónde esté el Token inferior (en C o en F), pero cuando llega primero por el camino inferior, el Token superior ya debe estar en E.
Compuerta Inclusiva - Bloque no Estructurado (b)
Si el Token del camino superior pasa al camino inferior mientras el Token inferior todavía está en C, entonces llega a la Compuerta Inclusiva Convergente por el camino inferior. Puesto que no hay un Token en el camino superior, la Compuerta se activa y dejar pasar el Token. Después el Token inferior avanza desde C, llega a la Compuerta y la vuelve a activar. Es decir, la Compuerta se activa dos veces, y las Actividades F y G se ejecutan dos veces. El Proceso termina cuando ambos Tokens han llegado al Evento Final.
Compuerta Inclusiva - Bloque no Estructurado (c)
Nótese que puede ocurrir que mientras el Token superior está en F, el Token inferior avanza y llega también a F, entonces habrá dos instanciaciones concurrentes de F. El resultado final será el mismo: dos ejecuciones de F, dos instanciaciones de la Compuerta, dos ejecuciones de G. Una situación similar se produce en el caso siguiente.
Si el Token del camino superior está en D y el del camino inferior llega a la Compuerta Inclusiva Convergente, entonces ésta se activa ya que no hay un Token en el camino superior. Después el Token superior avanza desde D, llega a la Compuerta y la vuelve a activar. Como en el caso anterior, la Compuerta se activa dos veces, y las Actividades F y G se ejecutan dos veces. El Proceso termina cuando ambos Tokens han llegado al Evento Final.
Compuerta Inclusiva - Bloque no Estructurado (d)
Los casos anteriores muestran la mayor complejidad de un Bloque no estructurado, pero la Compuerta Inclusiva Convergente sigue funcionando como hasta ahora habíamos visto.
Sin embargo, cuando el Token del camino inferior llega a la Compuerta Inclusiva Convergente y el del camino superior todavía está en B, la Compuerta se activa porque, a pesar de que existe un Token que puede llegar por el camino superior, la definición del funcionamiento de la Compuerta dice que, si existe un camino por el cual pueda llegar el Token hasta un Flujo de Entrada que ya tiene un Token, entonces no hay que esperar y la compuerta se activa. En este caso, dicho camino existe: Compuerta 🠊 Condición 4 🠊 D 🠊 Compuerta 🠊 F.
Después, una vez que el Token inferior ha pasado la Compuerta Inclusiva Convergente, el token que está en B puede seguir dos caminos para llegar a la Compuerta Inclusiva: (1) Compuerta 🠊 Condición 3 🠊 E, o (2) Compuerta 🠊 Condición 4 🠊 D 🠊 Compuerta 🠊 F.
Compuerta Inclusiva - Bloque no Estructurado (e)
En resumen, en un Bloque Inclusivo Cerrado Estructurado, los dos Tokens que salen de la Compuerta Inclusiva Divergente son esperados por la Inclusiva Convergente y sincronizados, es decir, la Compuerta se activa solo una vez. Pero en el Bloque Inclusivo Cerrado no Estructurado del ejemplo, cuando los Tokens siguen caminos separados y llegan a la Compuerta Inclusiva Convergente desde arriba y desde abajo, la pueden activar una o dos veces, dependiendo de que tan rápido se mueva el Token en el camino superior.
Compuerta Inclusiva en Ciclos
Un Ciclo se crea conectando un Flujo de Secuencia a un objeto anterior en el Proceso. (Se considera que un objeto es "anterior" si tiene un Flujo de Secuencia saliente que comienza un camino que lleva al objeto inicial.) Se usa una Compuerta Exclusiva para controlar el ciclo.
Uno de los Ciclos más usado es el Hacer-Mientras (Do-While), el que tiene un Bloque Interno que termina con una Compuerta Exclusiva Divergente con dos salidas: una que vuelve al inicio del Bloque Interno para repetir el Ciclo, y otra que se sigue cuando el Ciclo termina. Nótese que se podría colocar una Compuerta Exclusiva Convergente antes del inicio del Ciclo, pues llegan dos Flujos de Secuencia directamente a la Actividad que inicia el Bloque Interno. Sin embargo, se acostumbra a dejar el Flujo no Controlado.
Compuerta Inclusiva - Ciclo (a)
Algunos modeladores colocan un Compuerta Inclusiva Convergente al comienzo del Ciclo Hacer-Mientras, pero esto presenta varios problemas. El más sencillo es cuando simplemente está demás, pues basta con colocar una Compuerta Exclusiva Convergente o, lo que es mejor, no colocar ninguna Compuerta. En el peor de los casos, en modelo puede ser inválido (no puede continuar) o tiene un comportamiento errático.
Analizaremos tres casos:
- El Ciclo es iniciado una vez.
- El Ciclo es iniciado varias veces. Entre una iniciación y otra, el Ciclo alcanza a completarse.
- El Ciclo es iniciado varias veces. Entre una iniciación y otra, el Ciclo no alcanza a completarse.
(Cada caso es analizado con el simulador MIDA - Multiple Instances and Data Animator.)
Para visualizar mejor el comportamiento de la Compuerta Inclusiva Convergente hemos separado los distintos casos. Sin embargo, en una misma instanciación podrían darse distintas velocidades relativas de los Ciclos, lo que haría aún más complicado entender su funcionamiento. Además, si el Ciclo que comienza con la Compuerta Inclusiva fuera no estructurado, entonces sería casi imposible predecir su funcionamiento.
El modelador debería limitar el uso de la Compuerta Inclusiva Convergente al Bloque Inclusivo Cerrado, es decir, cuando cierra un Bloque que comienza con una Compuerta Inclusiva Divergente. En cualquier otro caso, el modelador debe tener muy claro el comportamiento que espera de la Compuerta Inclusiva Convergente, y - lo más importante - debe asegurarse que el destinatario del modelo también lo entienda.
El Ciclo es iniciado una vez
Si el Ciclo es iniciado una única vez, entonces la Compuerta Inclusiva recibe solo una vez el Token que inicia el Ciclo, después recibirá solo el Token de retorno. Por lo tanto, nunca llegan ambos Tokens a la vez, es decir, actúa como una Exclusiva Convergente. El mismo comportamiento se logra eliminando la Exclusiva Convergente, es decir, dejando que los Flujos lleguen directamente a la primera Actividad del Ciclo (Flujo no Controlado).
Compuerta Inclusiva - Ciclo (b)
El Ciclo es iniciado varias veces y alcanza a completarse
Para iniciar varias veces el Ciclo superior, que comienza con la Compuerta Inclusiva Convergente, se ha colocado un Ciclo inferior (normal) que inicia al superior en cada repetición. (Para simular de una manera simple las demoras relativas de los Ciclos se han colocado más o menos Actividades en cada uno de ellos.)
Compuerta Inclusiva - Ciclo (c)
Si el Ciclo superior es iniciado varias veces y antes de cada iniciación alcanza a completarse, entonces la Compuerta Inclusiva Convergente siempre espera el Token que llega desde el Flujo de Entrada para activarse. Es decir, la repetición de las Actividades solo depende del Token que llega desde el Ciclo inferior y no del Flujo de Retorno. Por lo tanto, mientras continúa el Ciclo inferior, el modelo se comporta como si la Compuerta Inclusiva Convergente no estuviera, y no hubiera un Flujo de Retorno en el Ciclo superior. Nótese que, si el Ciclo inferior deja de activar el Ciclo superior, entonces éste seguirá por su cuenta, pues la Compuerta Inclusiva se activará cada vez que llegue un Token por el Flujo de Retorno, sin esperar un Token desde el Ciclo inferior.
El Ciclo es iniciado varias veces y no alcanza a completarse
Si desde el Ciclo inferior llegan Tokens más rápido de lo que demora el Ciclo superior en completarse, entonces se acumulan Tokens en el Flujo de Entrada y se tiene un comportamiento errático: el primer Token inicia el Ciclo superior; después se acumulan dos Tokens abajo y cuando llega en Token de retorno se activa la Compuerta; luego se acumulan 3 Tokens y activan la Compuerta sin esperar el Token de retorno; después la Compuerta se activa con dos Tokens desde abajo y dos de retorno…
Compuerta Inclusiva - Ciclo (d)
Buenas Prácticas
Es una Buena Práctica usar la Compuerta Inclusiva Convergente solo cuando cierra un Bloque Inclusivo Cerrado, es decir, cuando en ella convergen Flujos de Secuencia que se originaron en una Compuerta Inclusiva Divergente precedente.
Compuerta Inclusiva - Buenas Prácticas
No es un una Buena Práctica usar la Compuerta Inclusiva Convergente para cerrar otras Compuertas (Exclusiva, Eventos, Paralela y Compleja), pues siempre existe una alternativa mejor, como se explica más adelante en Patrones.
Por lo descrito en las secciones anteriores, no se recomienda usar la Compuerta Inclusiva Convergente en Ciclos y en modelos no estructurados.
Es importante que la estrategia respecto a usar o no usar la Compuerta Inclusiva Convergente sea la misma en todos los diagramas.
Compuerta Inclusiva Patrones de Uso
La Compuerta Inclusiva se usa en Bloques Abiertos y Cerrados. (En Compuertas-Bloques encontrará una exposición exhaustiva sobre los distintos tipos de Bloques relacionados con las Compuertas.)
Los dos Bloques con Compuerta Inclusiva más utilizados son:
- Bloque Inclusivo Abierto: comienza con una Compuerta Inclusiva Divergente con varios caminos no excluyentes que continúan de manera independiente.
- Bloque Inclusivo Cerrado: comienza con una Compuerta Inclusiva Divergente con varios caminos no excluyentes, y termina con una Compuerta Inclusiva Convergente que los sincroniza.
El Bloque Inclusivo-Exclusivo también es válido, pero hay que usarlo con precaución, pues tiene más de un Token de salida.
Los demás Bloques que comienzan o terminan con Compuerta Inclusiva son inválidos o no prácticos.
En las secciones siguientes se describen los Bloques que comienzan con Compuerta Inclusiva Divergente.
Compuerta Inclusiva Bloque Abierto
Un Bloque Inclusivo Abierto comienza con una Compuerta Inclusiva Divergente con varios caminos no excluyentes que continúan de manera independiente.
El o los Tokens que salieron de la Compuerta Divergente llegarán a Eventos Finales. Si no hay otros Tokens activos en el Proceso, éste termina.
Compuerta Inclusiva - Bloque Abierto
Compuerta Inclusiva Bloque Cerrado
Un Bloque Inclusivo Cerrado comienza con una Compuerta Inclusiva Divergente con varios caminos no excluyentes. El Bloque termina con una Compuerta Inclusiva Convergente que los sincroniza.
La Compuerta Convergente produce una sincronización, es decir, espera a que lleguen el o los Tokens que salieron de la Divergente para activarse.
Compuerta Inclusiva - Bloque Cerrado
Explicación del ejemplo.
Compuerta Inclusiva Bloque Inclusivo-Exclusivo
Un Bloque Inclusivo-Exclusivo comienza con una Compuerta Inclusiva Divergente con varios caminos no excluyentes, y termina con una Compuerta Exclusiva Convergente que deja pasar uno a uno los Tokens a medida que van llegando.
El Bloque Inclusivo-Exclusivo debe ser usado con precaución, pues tiene más de un Token de salida.
Compuerta Inclusiva - Bloque Inclusivo-Exclusivo
En el ejemplo, la Actividad E se ejecuta una o dos veces. Dependiendo de que tan rápido salgan los Token del Bloque, y de cuánto se demore la Actividad, las instanciaciones de E pueden ocurrir una después de otra o simultáneamente.
Compuerta Inclusiva Bloque Inclusivo-Paralelo
Un Bloque Inclusivo-Paralelo comienza con una Compuerta Inclusiva Divergente que define varios caminos no excluyentes, y termina con una Compuerta Paralela Convergente que espera un Token en cada Flujo de Entrada para activarse.
Es un Modelo inválido, pues la Compuerta Inclusiva que comienza el Bloque deja pasar uno o más Tokens, pero la Compuerta Paralela que cierra el Bloque espera Tokens por todos sus Flujos de Entrada y queda, de este modo, bloqueada.
Compuerta Inclusiva - Bloque Inclusivo-Paralelo
En solo un caso la Compuerta Convergente Paralela sí se activa, esto ocurre cuando la Compuerta Inclusiva no tiene Flujo por Defecto y todas las Condiciones son verdaderas.
Compuerta Inclusiva Bloque Inclusivo-Eventos
Un Bloque Inclusivo-Eventos comienza con una Compuerta Inclusiva Divergente con varios caminos no excluyentes, y termina con una Compuerta de Eventos Convergente que deja pasar uno a uno los Tokens a medida que van llegando.
La Compuerta de Eventos en configuración Convergente funciona igual que la Compuerta Exclusiva Convergente, es decir, los Tokens que arriban van pasando hacia la salida uno tras otro sin sincronización. Por este motivo, el Bloque Inclusivo-Eventos funciona exactamente igual que el Bloque Inclusivo-Exclusivo.
Por lo tanto, no es práctico usar el Bloque Inclusivo-Eventos, pues no aporta un nuevo comportamiento. Es mejor usar el Bloque Inclusivo-Exclusivo.
Compuerta Inclusiva - Bloque Inclusivo-Eventos
En el ejemplo, la Actividad E se ejecuta una o dos veces. Dependiendo de que tan rápido salgan los Token del Bloque, y de cuánto se demore la Actividad, las instanciaciones de E pueden ocurrir una después de otra o simultáneamente.
Compuerta Inclusiva Bloque Inclusivo-Complejo
Un Bloque Inclusivo-Complejo comienza con una Compuerta Exclusiva Divergente que define varios caminos no excluyentes, y termina con una Compuerta Compleja Convergente que espera varios Tokens para evaluar su lógica de activación.
En el caso general, es un Modelo inválido, pues la Compuerta Exclusiva que comienza el Bloque deja pasar uno o más Tokens, los que pueden no ser suficientes para activar el Discriminador N/M (1 ≤ N < M) que implementa la Compuerta Compleja que cierra el Bloque. Puede implementar un Discriminador 1/M, y también podría, algunas veces, funcionar con otros Discriminadores.
Como se ve en el siguiente ejemplo, si la Compuerta Compleja implementa un Discriminador 2/3, entonces solo se cumplirá la Condición de Activación cuando Condición 1 y Condición 2 sean verdaderas.
Compuerta Inclusiva - Bloque Inclusivo-Complejo
Especificación BPMN
This Decision represents a branching point where Alternatives are based on conditional Expressions contained within the outgoing Sequence Flows (see page 291).[ok]
In some sense it is a grouping of related independent Binary (Yes/No) Decisions. Since each path is independent, all combinations of the paths MAY be taken, from zero to all. However, it should be designed so that at least one path is taken. A Default Condition could be used to ensure that at least one path is taken.[ok]
There are two versions of this type of Decision:[enfoque enredado]
- The first uses a collection of conditional Sequence Flows, marked with mini-diamonds (see top-right figure).
- The second uses an Inclusive Gateway (see bottom-right picture).
A diverging Inclusive Gateway (Inclusive Decision) can be used to create alternative but also parallel paths within a Process flow. Unlike the Exclusive Gateway, all condition Expressions are evaluated. The true evaluation of one condition Expression does not exclude the evaluation of other condition Expressions. All Sequence Flows with a true evaluation will be traversed by a token. Since each path is considered to be independent, all combinations of the paths MAY be taken, from zero to all. However, it should be designed so that at least one path is taken.[ok]
The Inclusive Gateway MUST use a marker that is in the shape of a circle or an “O” and is placed within the Gateway diamond (see Figure 10.108) to distinguish it from other Gateways.[ok]
A default path can optionally be identified, to be taken in the event that none of the conditional Expressions evaluate to true. [ok]If a default path is not specified and the Process is executed such that none of the conditional Expressions evaluates to true, a runtime exception occurs.[técnico]
A converging Inclusive Gateway is used to merge a combination of alternative and parallel paths. A control flow token arriving at an Inclusive Gateway MAY be synchronized with some other tokens that arrive later at this Gateway. The precise synchronization behavior of the Inclusive Gateway can be found on page nnn.[ok]
Default. The Sequence Flow that will receive a token when none of the conditionExpressions on other outgoing Sequence Flows evaluate to true. The default Sequence Flow should not have a conditionExpression. Any such Expression SHALL be ignored.[técnico]
Inclusive Gateway (Inclusive Decision and Inclusive Merge)
The Inclusive Gateway synchronizes a certain subset of branches out of the set of concurrent incoming branches (merging behavior). Further on, each firing leads to the creation of threads on a certain subset out of the set of outgoing branches (branching behavior).[ok]
Operational Semantics: The Inclusive Gateway is activated if [ok]
- At least one incoming Sequence Flow has at least one token and
-
For every directed path formed by sequence flow that
- starts with a Sequence Flow f of the diagram that has a token,
- ends with an incoming Sequence Flow of the inclusive gateway that has no token, and
- does not visit the Inclusive Gateway.
- starts with f,
- ends with an incoming Sequence Flow of the inclusive gateway that has a token, and
- does not visit the Inclusive Gateway.
Upon execution, a token is consumed from each incoming Sequence Flow that has a token. A token will be produced on some of the outgoing Sequence Flows.[ok]
In order to determine the outgoing Sequence Flows that receive a token, all conditions on the outgoing Sequence Flows are evaluated. The evaluation does not have to respect a certain order.[ok]
For every condition which evaluates to true, a token MUST be passed on the respective Sequence Flow.[ok]
If and only if none of the conditions evaluates to true, the token is passed on the default Sequence Flow.[ok]
In case all conditions evaluate to false and a default flow has not been specified, the Inclusive Gateway throws an exception.[técnico]
Exception Issues: The inclusive gateway throws an exception in case all conditions evaluate to false and a default flow has not been specified.[técnico]
Workflow Patterns Support: Multi-Choice (WCP-6), Structured Synchronizing Merge (WCP-7), Acyclic Synchronizing Merge (WCP-37), General Synchronizing Merge (WCP-38).
See Inclusive Decision Pattern on page 463.
