|
|
La Compuerta Compleja permite crear modelos sofisticados, que pueden ser difíciles de entender para las personas no especializadas que leen un diagrama BPMN. Por este motivo, limitaremos la exposición principal de la Compuerta Compleja a la implementación de un Discriminador Estructurado N/M, que es un modelo fácil de entender y aplicar.
Un Discriminador Estructurado N/M (1 ≤ N < M) consiste en una Compuerta Compleja Convergente que tiene M Flujos de Entrada y un Flujo de Salida. Los Flujos de Entrada provienen de una Compuerta Paralela Divergente. La Compuerta Compleja espera que lleguen N Tokens para activarse y enviar un Token por su Flujo de Salida. Después queda a la espera de los restantes M-N Tokens. Cuando éstos llegan, los consume y vuelve a esperar N Tokens para activarse.
En Compuerta Extendida se entrega una descripción detallada de la Compuerta Compleja para modelos más sofisticados.
El ejemplo describe la siguiente lógica de negocio: para comenzar a preparar el informe de evaluación de la tesis se necesita la evaluación del profesor guía y de uno de los profesores informantes. Mientas se prepara el informe de evaluación puede llegar la evaluación del otro profesor informante y ser usado en la preparación del informe. Si se ha terminado el informe de evaluación y aún no se recibe la evaluación del otro profesor informante, entonces se aborta la respectiva Actividad de recepción y el Proceso termina.
Compuerta Compleja - Ejemplo
En el ejemplo, la Compuerta Compleja implementa un Discriminador 1/2, es decir, se activa cuando llega un Token por uno de sus dos Flujos de Entrada. Ese Token, junto con el que viene de Recibir evaluación del profesor guía, activa la Compuerta Paralela Convergente. El segundo Token que llega a la Compuerta Compleja es consumido sin activar su Flujo de Salida y, por lo tanto, no llega a la Compuerta Paralela Convergente. Sin embargo, la segunda evaluación recibida desde un profesor informante no se pierde, en la medida que es recibida y almacenada puede ser utilizada para preparar el informe de evaluación.
Nótese que el Proceso termina con un Evento Final Terminador, que tiene el efecto de abortar cualquier Actividad que esté ejecutándose y luego terminar el Proceso. Esto es necesario porque puede ocurrir que se haya terminado la Actividad Preparar informe de evaluación mientras todavía se espera la evaluación del otro profesor informante.
Compuerta Compleja Divergente
La Compuerta Compleja Divergente desvía el Flujo del Proceso por uno o más de entre varios caminos posibles. El desvío se basa en Condiciones asociadas a cada Flujo de Salida. Es decir, tiene la misma Configuración y el mismo comportamiento que la Compuerta Inclusiva Divergente.
Para evitar el uso de dos Compuertas que funcionan igual, se recomienda no usar la Compuerta Compleja Divergente. En su lugar, debería usarse la Compuerta Inclusiva Divergente.
Compuerta Compleja - Divergente
Cuando la Compuerta Compleja es a la vez Convergente y Divergente, el funcionamiento puede diferir del descrito aquí, para mayor detalle ver Compuerta Extendida.
Compuerta Compleja Configuración Convergente
La Compuerta Compleja Convergente que implementa un Discriminador Estructurado N/M tiene la siguiente Configuración:
- Tiene M Flujos de Entrada, con M ≥ 2.
- Los Flujos de Entrada provienen de caminos paralelos que se originan en una Compuerta Paralela Divergente. Además, los caminos son independientes, es decir, no hay Flujos de Secuencia que salgan o lleguen a ellos.
- La Compuerta tiene una Condición que indica cuántos Tokens (1 ≤ N < M) , en diferentes Flujos de Entrada, deben llegar para activar el Flujo de Salida.
- Un Flujo de Salida Condicional que deja pasar un Token cuando llegan los primeros N Tokens, pero no emite un Token cuando llegan los restantes M-N Tokens.
Por ejemplo, un Discriminador 2/3 tiene 3 Flujos de Entrada. Cuando llegan Tokens por 2 de los Flujos, la Compuerta se activa y emite un Token por el Flujo de Salida. Luego espera un Token por el tercer Flujo de Entrada, cuando llega lo consume y no emite un Token por el Flujo de Salida.
Compuerta Compleja - Configuración Convergente
Compuerta Compleja Funcionamiento Convergente
La Compuerta Compleja pasa, alternativamente, por dos estados: waiting-for-start (esperando inicio) y waiting-for-reset (esperando reinicio). Comienza en estado waiting-for-start.
- En waiting-for-start, la Compuerta espera a que se cumpla la Condición de Activación, es decir, que lleguen Tokens por N de los Flujos de Entrada. Para comenzar a evaluar la Condición de Activación debe haber al menos un Token en algún Flujo de Entrada.
- Cuando la condición se vuelve verdadera, la Compuerta consume un Token de cada Flujo de Entrada que tiene al menos un Token, genera un Token por el Flujo de Salida y pasa a estado waiting-for-reset.
- En waiting-for-reset, la Compuerta espera un Token en cada uno de los Flujos de Entrada por los que no llegaron Tokens en la fase anterior.
- Cuando llegan los Tokens pendientes, la Compuerta los consume y vuelve a estado waiting-for-start.
La Compuerta Compleja Convergente implementa la Convergencia Discriminante.
Compuerta Compleja - Funcionamiento Convergente
Revisemos el ejemplo de la Evaluación de Tesis con más detalle. La Compleja Convergente comienza en estado waiting-for-start, cuando llega la evaluación del informante 2 se cumple la Condición 1/2, por lo tanto, se activa la Compuerta y pasa al estado waiting-for-reset. Cuando llega la evaluación del informante 1 la Compuerta vuelve al estado waiting-for-start.
Compuerta Compleja - Funcionamiento - Ejemplo
Buenas Prácticas
Es una Buena Práctica usar la Compuerta Compleja Convergente solo cuando cierra un Bloque Paralelo-Complejo que implementa un Discriminador Estructurado N/M.
Una Compuerta Compleja Convergente con tres Flujos de Entrada puede implementar dos Discriminadores: 1/3 y 2/3. El siguiente ejemplo muestra un Bloque Paralelo-Complejo con un Discriminador Estructurado 2/3.
Compuerta Compleja - Buenas Prácticas
Las Compuertas Exclusiva, Paralela, Eventos e Inclusiva tiene un comportamiento predeterminado conocido, el lector del diagrama sólo necesita ver el Marcador interno de la Compuerta para saber cómo ésta funciona.
En el caso de la Compuerta Compleja Convergente, el lector debe conocer la Condición de Activación, que es un atributo interno de cada Compuerta, para saber como funcionará. Un diagrama puede contener varias de estas Compuertas, cada una con una lógica diferente de activación.
Como hemos visto en los ejemplos, para facilitar la lectura del diagrama, se acostumbra a colocar una Nota de Texto junto a la Compuerta con la descripción de la Condición de Activación: "Un informe recibido", "El informe del profesor guía y de uno de los informantes", etc.
Es importante que la forma de usar la Compuerta Compleja Convergente sea la misma en todos los diagramas.
Compuerta Compleja Compuerta Extendida
Hasta ahora hemos visto cómo la Compuerta Compleja Convergente estricta implementa un Discriminador Estructurado N/M. Además, hemos indicado que la Compuerta Compleja Divergente estricta es, en su funcionamiento, equivalente a la Inclusiva Divergente, y, por lo tanto, no se recomienda utilizarla.
Sin embargo, la Compuerta Compleja permite crear modelos más sofisticados, aunque más difíciles de entender y, a veces, contraintuitivos. En modelo se puede complejizar en cuatro direcciones:
- La lógica de activación puede ser más sofisticada que la de un Discriminante N/M.
- Los Flujos que llegan a la Compuerta Compleja podrían tener orígenes variados y no ser, necesariamente, independientes.
- La Compuerta Compleja Convergente podría activarse (emitir un Token) dos veces: en waiting-for-start y en waiting-for-reset.
- La Compuerta Compleja podría ser a la vez Convergente y Divergente.
Condición de Activación
La Condición de Activación determina qué combinación de Tokens serán sincronizados para activar la Compuerta.
En el Discriminante N/M la Condición de Activación indica cuántos Flujos de Entrada deben tener Token, por ejemplo: "1 de 3", "3 de 5", etc.
Sin embargo, la lógica de activación puede ser más sofisticada, por ejemplo: "un Token en el primer Flujo y uno de cualquiera de los otros", "un Token en el primer Flujo y en el tercer Flujo, o tres Tokens en cualquiera de los Flujos", etc.
El siguiente diagrama modela la misma lógica del ejemplo de la evaluación de tesis, pero ahora la condición de la Compuerta Compleja requiere que el Flujo que viene de Recibir evaluación del profesor guía siempre tenga un Token, y solo uno de los Flujos que vienen de los informantes. En la versión anterior, la obligatoriedad de la evaluación del profesor guía se modelaba con una Compuerta Paralela Convergente.
Compuerta Compleja - Condición de Activación
Caminos no Estructurados
En el Discriminante Estructurado N/M todos los Flujos de Entrada provienen de caminos estructurados independientes que nacen de una Compuerta Paralela Divergente. Esto garantiza que los M-N Tokens pendientes llegarán a la Compuerta Compleja, en un momento u otro.
Compuerta Compleja - Caminos Estructurados
Sin embargo, los Flujos que llegan a la Compuerta Compleja podrían tener orígenes variados y no ser, necesariamente, independientes. Por este motivo, algunos o todos Tokens pendientes podrían no llegar. Para determinar cuáles Tokens esperar y cuáles no, se utiliza la lógica de activación de la Compuerta Inclusiva Convergente.
(El ejemplo siguiente es análogo al de la Compuerta Inclusiva en modelos no estructurados. Es recomendable estudiar primero dicho ejemplo antes de continuar.)
El siguiente diagrama muestra un Bloque Paralelo-Complejo semejante al anterior, pero no estructurado. Como veremos, el sólo hecho de que exista un paso entre los dos caminos paralelos cambia el funcionamiento del proceso, aunque no se use.
Compuerta Compleja - Caminos no Estructurados
Si el Token del camino superior llega a E y el del camino inferior llega a F y pasa a la Compuerta Compleja, entonces ésta se activa, emite un Token y cambia a estado waiting-for-reset. Después el Token en E pasa a la Compuerta Compleja, es consumido y la Compuerta vuelve al estado waiting-for-start. Este es el comportamiento esperado del Discriminador 1/2.
Sin embargo, cuando el Token del camino inferior llega a la Compuerta Compleja y el del camino superior todavía está en B, la Compuerta se activa, emite un Token y pasa al estado waiting-for-reset, como es esperable. Pero inmediatamente pasa al estado waiting-for-start porque, a pesar de que existe un Token que puede llegar por el camino superior, la definición del funcionamiento de la Compuerta Compleja dice que si existe un camino (Compuerta 🠊 Condición 2 🠊 D 🠊 Compuerta 🠊 F) por el cual pueda llegar el Token hasta un Flujo de Entrada que ya tiene un Token o desde el cual se consumió un Token en la primera fase, entonces no hay que esperarlo.
Después, el Token que está en B sigue por el camino superior (Compuerta 🠊 Condición 1 🠊 E) y llega a la Compuerta Compleja, que está en estado waiting-for-start. Se vuelve a activar el Discriminador: deja pasar el Token y pasa al estado waiting-for-reset, y - puesto que no hay Token que pueda llegar desde abajo - pasa inmediatamente al estado waiting-for-start.
Compuerta Compleja - Caminos no Estructurados
En resumen, cuando los caminos son independientes los dos Tokens que salen de la Compuerta Paralela activan solo una vez el Discriminador 1/2 (el primero que llega pasa, y el otro es consumido). Pero cuando hay un paso entre los caminos, aunque no se use, el Discriminador 1/2 se puede activar una o dos veces, dependiendo de que tan rápido se mueva el Token en el camino superior. Este es un comportamiento contraintuitivo, el modelador debe tener muy claro el comportamiento que espera de la Compuerta Compleja, y - lo más importante - debe asegurarse que el destinatario del modelo también lo entienda.
La Compuerta se activa dos veces
En el Discriminador Estructurado N/M, la Compuerta Compleja se activa (es decir, emite un Token por su Flujo de Salida) solo en la primera fase, cuando está en estado waiting-for-start.
La Compuerta Compleja Convergente siempre debe emitir Token cuando se cumple la Condición de Activación, en la primera fase. En caso contrario, se considera un modelo no válido. En la segunda fase, cuando llegan los Token restantes, la Compuerta Compleja puede, opcionalmente, emitir un Token.
El que se emita o no un Token depende de la Condición asociada al Flujo de Salida. En el Discriminador Estructurado N/M la Condición del Flujo de Salida es "estado es waiting-for-start", que es verdadera en la primera fase, y falsa en la segunda (porque el estado pasa a waiting-for-reset).
Compuerta Compleja - Doble Activación
Si la Condición del Flujo de Salida es "estado es waiting-for-reset", el modelo es no válido, pues la Condición es falsa en la primera fase, y - como ya se dijo - es obligatorio emitir un Token en dicha fase.
Compuerta Compleja - Doble Activación
Si la Condición del Flujo de Salida es siempre verdadera (constante "true"), entonces la Compuerta emite dos Tokens, uno en cada fase. (Otra Condición verdadera en ambas fases es "estado es waiting-for-start o estado es waiting-for-reset".)
Compuerta Compleja - Doble Activación
Configuración Convergente-Divergente
Como hemos visto, la Compuerta Compleja Convergente estricta tiene un estado (waiting-for-start o waiting-for-reset) que puede ser usado en la Condición de su Flujo de Salida. Esto puede ser extendido a una Compleja Convergente-Divergente, es decir, una con varios Flujos de Entrada y varios Flujos de Salida.
En el siguiente ejemplo, si en ambas fases se mantiene el precio a $200 y es un cliente normal, entonces en la primera fase se sigue el flujo superior, pues en la Compuerta está en estado waiting-for-start. Y en la segunda fase, el flujo de en medio, pues el estado es waiting-for-reset. (Recordemos que la Compuerta Compleja Divergente se comporta como una Inclusiva Divergente, es decir, sigue todos aquellos Flujos cuya Condición es verdadera; y el Flujo por Defecto, si todas son falsas.)
Compuerta Compleja - Convergente-Divergente
Es una Buena Práctica que una Compuerta sea Convergente o Divergente, pero no ambas a la vez. En el caso de las Compuertas Exclusiva, Paralela, Eventos e Inclusiva, una Convergente-Divergente puede ser separada en una Convergente seguida de una Divergente.
Sin embargo, una Compleja Convergente-Divergente puede utilizar el valor de su estado (waiting-for-start y waiting-for-reset) en las Condiciones de sus Flujos de Salida. Por este motivo, una Compleja Convergente-Divergente no es necesariamente igual a una Compleja Convergente seguida de una Compleja Divergente.
Compuerta Compleja - Convergente-Divergente
Semántica de Ejecución
La Especificación de BPMN describe el funcionamiento de la Compuerta Compleja en los siguientes términos.
La Compuerta Compleja tiene una Condición de Activación que determina qué combinación de tokens entrantes se sincronizará para la activación de la Compuerta.
El Compuerta Compleja pasa por dos estados: waiting-for-start (esperando inicio) y waiting-for-reset (esperando reinicio), comienza en waiting-for-start. En este estado espera a que la Condición de Activación sea verdadera. La Condición de Activación no se evalúa hasta que haya al menos un Token en algún Flujo de Entrada. Cuando se hace verdadera, se consume un Token de cada Flujo de Entrada que tenga un Token.
Luego evalúa todas las Condiciones de los Flujos de Salida (en cualquier orden) para determinar qué flujos de secuencia reciben un token. Para determinar los Flujos de Salida que recibirán Tokens, se evalúan todas las Condiciones de los Flujos de Salida (en cualquier orden). Aquellos cuya Condición es verdadera reciben un Token. Si ninguna Condición es verdadera se sigue el Flujo por Defecto, si existe. Si no se especifica un Flujo por Defecto, entonces se produce un error, el Proceso se bloquea.
La Compuerta cambia su estado a waiting-for-reset.
Cuando está en waiting-for-reset, la Compuerta espera un Token en cada uno de los Flujos de Entrada que no tenían Token en la primera fase (La Compuerta recuerda los Flujos de Entrada de los que consumió Tokens en la primera fase), a menos que no se espere dicho Token de acuerdo con la lógica de funcionamiento de la Compuerta Inclusiva Convergente.
Más precisamente, la Compuerta se reinicia cuando:
-
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 de Entrada de la Compuerta Compleja que no tiene Token y no ha consumido un Token en la primera fase, y
- - no pasa por la Compuerta Compleja.
-
También hay otro camino directo de Flujos de Secuencia que
- - comienza con f,
- - termina con un Flujo de Secuencia de Entrada de la Compuerta Compleja que tiene un Token o desde el cual se consumió un Token en la primera fase, y
- - no pasa por la Compuerta Compleja.
Cuando la Compuerta se reinicia, consume un Token de cada Flujo de Secuencia de Entrada que tiene un Token y del cual aún no había consumido uno en la primera fase. Luego evalúa todas las Condiciones de los Flujos de Salida (en cualquier orden) para determinar qué flujos de secuencia reciben un token. Aquellos cuya Condición es verdadera reciben un Token. Si ninguna Condición es verdadera se sigue el Flujo por Defecto, si existe. Es posible que la Compuerta no produzca ningún Token en esta segunda fase y no se produce un error. Además, las Condiciones de los Flujos de Salida puede evaluarse de manera diferente en las dos fases, por ejemplo, haciendo referencia al estado de la Compuerta.
La Compuerta vuelve al estado waiting-for-start.
El estado de la Compuerta Compleja se representa mediante el atributo booleano waitingForStart, que inicialmente es verdadero y se vuelve falso después de la activación. Este atributo se puede utilizar en las Condiciones de los Flujos de Salida para indicar dónde se producen Tokens en la activación y dónde se producen en el reinicio. Se recomienda que cada Flujo de Salida obtenga un Token al activarse o al reiniciarse la Compuerta, pero no en ambos. Al menos un Flujo de Salida debe recibir un Token al momento de la activación, pero no es obligatorio producir un Token al reiniciar.
Compuerta Compleja Patrones de Uso
La Compuerta Compleja sólo se usa en el Bloque Paralelo-Complejo que comienza con una Compuerta Paralela Divergente con varios caminos concurrentes, y termina con una Compuerta Compleja que implementa un Discriminador N/M.
Los demás Bloques que comienzan o terminan con Compuerta Compleja son inválidos o no prácticos.
En las secciones siguientes se describen los Bloques que comienzan con Compuerta Compleja Divergente.
Compuerta Compleja Bloque Abierto
Un Bloque Complejo Abierto comienza con una Compuerta Compleja Divergente con varios caminos no excluyentes que continúan de manera independiente.
La Compuerta Compleja en Configuración Divergente funciona igual que la Compuerta Inclusiva Divergente. Por este motivo, el Bloque Complejo Abierto es equivalente al Bloque Inclusivo Abierto.
Por lo tanto, no es práctico usar el Bloque Complejo Abierto, pues no aporta un nuevo comportamiento. Es mejor usar el Bloque Inclusivo Abierto.
Compuerta Compleja - Bloque Abierto
Compuerta Compleja Bloque Cerrado
Un Bloque Complejo Cerrado comienza con una Compuerta Compleja 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.
La Compuerta Compleja en Configuración Divergente funciona igual que la Compuerta Inclusiva Divergente. Por este motivo, el Bloque Complejo Cerrado es equivalente al Bloque Inclusivo-Complejo.
Es un Modelo inválido, pues la Compuerta Compleja que comienza el Bloque deja pasar uno o más Tokens, los que pueden no ser suficientes para activar el Discriminador (N/M) que implementa la Compuerta Compleja que cierra el Bloque.
Compuerta Compleja - Bloque Cerrado
Compuerta Compleja Bloque Complejo-Exclusivo
Un Bloque Complejo-Exclusivo comienza con una Compuerta Compleja 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.
La Compuerta Compleja en Configuración Divergente funciona igual que la Compuerta Inclusiva Divergente. Por este motivo, el Bloque Complejo-Exclusivo es equivalente al Bloque Inclusivo-Exclusivo.
Por lo tanto, no es práctico usar el Bloque Complejo-Exclusivo, pues no aporta un nuevo comportamiento. Es mejor usar el Bloque Inclusivo-Exclusivo. (Recuérdese que el este Bloque debe ser usado con precaución, pues tiene más de un Token de salida.)
Compuerta Compleja - Bloque Complejo-Exclusivo
Compuerta Compleja Bloque Complejo-Paralelo
Un Bloque Complejo-Paralelo comienza con una Compuerta Compleja Divergente que define varios caminos incluyentes, y termina con una Compuerta Paralela Convergente que espera un Token en cada Flujo de Entrada.
La Compuerta Compleja en Configuración Divergente funciona igual que la Compuerta Inclusiva Divergente. Por este motivo, el Bloque Complejo-Paralelo es equivalente al Bloque Inclusivo-Paralelo.
Es un Modelo inválido, pues la Compuerta Compleja 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 Compleja - Bloque Complejo-Paralelo
Compuerta Compleja Bloque Complejo-Eventos
Un Bloque Complejo-Eventos comienza con una Compuerta Compleja 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 Compleja en Configuración Divergente funciona igual que la Compuerta Inclusiva Divergente. Además, 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 Complejo-Eventos es equivalente al Bloque Inclusivo-Exclusivo.
Por lo tanto, no es práctico usar el Bloque Complejo-Eventos, pues no aporta un nuevo comportamiento. Es mejor usar el Bloque Inclusivo-Exclusivo.
Compuerta Compleja - Bloque Complejo-Eventos
Compuerta Compleja Bloque Complejo-Inclusivo
Un Bloque Complejo-Inclusivo comienza con una Compuerta Compleja Divergente con varios caminos no excluyentes. El Bloque termina con una Compuerta Inclusiva Convergente que los sincroniza.
La Compuerta Compleja en Configuración Divergente funciona igual que la Compuerta Inclusiva Divergente. Por este motivo, el Bloque Complejo-Inclusivo es equivalente al Bloque Inclusivo Cerrado (Inclusivo-Inclusivo).
Por lo tanto, no es práctico usar el Bloque Complejo-Inclusivo, pues no aporta un nuevo comportamiento. Es mejor usar el Bloque Inclusivo Cerrado.
Compuerta Compleja - Bloque Complejo-Inclusivo
Especificación BPMN
The Complex Gateway can be used to model complex synchronization behavior. An Expression activationCondition is used to describe the precise behavior. For example, this Expression could specify that tokens on three out of five incoming Sequence Flows are needed to activate the Gateway. What tokens are produced by the Gateway is determined by conditions on the outgoing Sequence Flows as in the split behavior of the Inclusive Gateway. If tokens arrive later on the two remaining Sequence Flows, those tokens cause a reset of the Gateway and new token can be produced on the outgoing Sequence Flows. To determine whether it needs to wait for additional tokens before it can reset, the Gateway uses the synchronization semantics of the Inclusive Gateway.[ok]
The Complex Gateway MUST use a marker that is in the shape of an asterisk and is placed within the Gateway diamond (see Figure 10.113) to distinguish it from other Gateways.[ok]
Operational Semantics
The Complex Gateway is in one of the two states: waiting for start or waiting for reset, initially it is in waiting for start. If it is waiting for start, then it waits for the activationExpression to become true. The activationExpression is not evaluated before there is at least one token on some incoming Sequence Flow. When it becomes true, a token is consumed from each incoming Sequence Flow that has a token.[ok]
The Gateway changes its state to waiting for reset. The Gateway remembers from which of the incoming Sequence Flows it consumed tokens in the first phase.[ok]
To determine which outgoing Sequence Flow receive a token, all conditions on the outgoing Sequence Flows are evaluated (in any order). Those and only those that evaluate to true receive a token. If no condition evaluates to true, and only then, the default Sequence Flow receives a token. If no default flow is specified an exception is thrown.[ok]
When waiting for reset, the Gateway waits for a token on each of those incoming Sequence Flows from which it has not yet received a token in the first phase unless such a token is not expected according to the join behavior of an inclusive Gateway.[ok]
More precisely, the Gateway being waiting for reset, resets when for every directed path formed by sequence flow that [ok]
- starts with a Sequence Flow f of the diagram that has a token,
- ends with an incoming Sequence Flow of the Complex Gateway that has no token and has not consumed a token in the first phase, and that
- does not visit the Complex Gateway.
There is also a directed path formed by Sequence Flow that [ok]
- starts with f,
- ends with an incoming Sequence Flow of the Complex Gateway that has a token or from which a token was consumed in the first phase, and that,
- does not visit the Complex Gateway.
If the Complex Gateway is contained in a Sub-Process, then no paths are considered that cross the boundary of that Sub-Process. [ok]
When the Gateway resets, it consumes a token from each incoming Sequence Flow that has a token and from which it had not yet consumed a token in the first phase. It then evaluates all conditions on the outgoing Sequence Flows (in any order) to determine which Sequence Flows receives a token. Those and only those that evaluate to true receive a token. If no condition evaluates to true, and only then, the default Sequence Flow receives a token. The Gateway changes its state back to the state waiting for start. Note that the Gateway might not produce any tokens in this phase and no exception is thrown. Note that the conditions on the outgoing Sequence Flows MAY evaluate differently in the two phases, e.g., by referring to the state of the Gateway (runtime attribute waitingForStart).[ok]
Note that if the activationCondition never becomes true in the first phase, tokens are blocked indefinitely at the Complex Gateway, which MAY cause a deadlock of the entire Process.[ok]
Exception issues: The Complex Gateway throws an exception when it is activated in the state waiting for start, no condition on any outgoing Sequence Flow evaluates to true and no default Sequence Flow is specified.[ok]
The Complex Gateway has, in contrast to other Gateways, an internal state, which is represented by the boolean instance attribute waitingForStart, which is initially true and becomes false after activation. This attribute can be used in the conditions of the outgoing Sequence Flows to specify where tokens are produced upon activation and where tokens are produced upon reset. It is RECOMMENDED that each outgoing Sequence Flow either get a token upon activation or upon reset but not both. At least one outgoing Sequence Flow should receive a token upon activation but a token MUST NOT be produced upon reset.[ok]
Attribute activationCondition. Determines which combination of incoming tokens will be synchronized for activation of the Gateway.[técnico]
Attribute default: SequenceFlow [0..1] The Sequence Flow that will receive a token when none of the conditionExpressions on other Sequence Flows evaluate to true. The default Sequence Flow should not have a conditionExpression. Any such Expression SHALL be ignored.[técnico]
Attribute activationCount: integer Refers at runtime to the number of tokens that are present on an incoming Sequence Flow of the Complex Gateway.[técnico]
Attribute waitingForStart: boolean = true Represents the internal state of the Complex Gateway. It is either waiting for start (=true) or waiting for reset (=false).[técnico]
Workflow Patterns Support: Structured Discriminator (WCP-9), Blocking Discriminator (WCP-28), Structured Partial Join (WCP-30), Blocking Partial Join (WCP-31).
