BPMN*

To reduce the ambiguity within BPMN and simplify the development process, several constraints and clarifications are added. The modified notation is named as BPMN*, which is still conformity with BPMN. In this paragraph, the modified notations are described, while the directly inherited ones are left out.

The name of each category in BPMN* is extended with prefix "BP" to differentiate from the terms we used in CA-PLAN (e.g. the term "BP Artifact" differs from the artifact in CA-PLAN).

• BP Flow Object

o BP Event

In BPMN, there are three types of events: start, end, and intermediate events. An intermediate event may behave in two ways, which shall be defined separately. In BPMN*, the BP Event associated with a BP Activity is called an interrupt event, while the rest of the intermediate events are called halt event. An interrupt event is associated with an interruption handling routine that reacts to the designate triggers. A halt event is placed in normal flows to halt the flow and represents an expected delay or waiting. The halted flow is not recovered until the designate trigger occurs.

In addition, for the readability of a process diagram, each process in BPMN*

must explicitly designate start events and end events. For example, the diagram in lower part in figure 3_3 has an implicit start event that is forbidden in BPMN*.

Figure 3_3 Explicit and implicit start event example

o BP Activity

~ 20 ~ 

In BPMN, an activity of sending or receiving messages is also defined as an event. These definitions for event and activity concepts are confused. It is clarified in BPMN* that when the source or target of message flow is an activity, there is corresponding sending or receiving event implicitly. For example, both two diagrams in figure 3_4 are equivalent. (Since the idea of the end event results is to summarize the process, the upper one is recommended).

Therefore end and intermediate (halt) event constraints are applied to send and receive tasks accordingly.

Figure 3_4 BP Event and BP Message Flow example

The pre-condition and post-condition based on additional attributes are added into each BP Activity, which constrain the starting and the normal finishing (since there may be an interruption) conditions accordingly.

o BP Gateway

In BPMN, there are four explicit and one implicit gateway, which are not distinctively differentiated from each other. Moreover, a contradiction in BPMN specification (exclude gateway used in merging in p.75 & p.119 [1]) is admitted by the author.

In BPMN*, gateways are reclassified as exclusive (data-based XOR), event (event-based XOR), inclusive (OR), parallel (AND), uncontrolled, and complex. An uncontrolled gateway is abstracted from BPMN, which represents none of control capabilities of other gateways. In other words, an uncontrolled gateway is a divergence or a convergence without centralized controls. It is classified as a gateway because of the essence of BP Gateways, that all splitting and joining of the flows shall be under the control of gateways.

~ 21 ~ 

Figure 3_5 Example of uncontrolled gateway

Each of the six types of gateways may function as split (branch) or join (merge);

they are described in the table 3_1. Note that the term "incoming flow" or "outgoing flow" here is used to represent a token flow.

Table 3_1 BPMN* gateways

Split control Join control Exclusive The first of the outgoing flows

whose condition is met is chosen.

A default choice may be set while none is satisfied.

Event The first outgoing flow whose associated event is triggered is chosen.

The first arrived incoming flow is taken as merge result, while others are blocked.

Inclusive No control is applied on the outgoing flows. A default choice may be set while none is satisfied.

The inclusive join may easily cause structure problems and is excluded from BPMN*.

~ 22 ~ 

~ 23 ~ 

outgoing flows.

Note that all outgoing flows are expected to be activated.

All the incoming flows are chosen to merge.

Note that all incoming flows are expected to be activated.

Uncontrolled No control is applied on the outgoing flows.

No control is applied on the incoming flows.

Complex One or more outgoing flows are chosen (activate) based on the

"outgoing condition" of complex gateway.

One or more incoming flows are chosen to merge based on the

"incoming condition" of complex gateway.

• BP Swimlane

Each process is contained with a BP Pool, which represents a distinct domain.

For each BPD of the collaboration sub-models (i.e. private, abstract, and collaboration process), there shall be at least one BP Pool specified for local domain. In our cases, a BP Pool is used to indicate a WD.

As for the BP Lane, it is preserved for attribute assignments and annotations.

• BP Connecting Object

A BP Message Flow may be considered as a control flow which synchronizes the processes among business entities. It is named synchronous flow and definitely specifies the sequences of processes among business entities. For example, in the upper part of figure 3_6 represents the execution sequences: send task, remote process, then receive task.

Otherwise, it is used to merely represent the communicative behavior of

processes. In this case, it is named as communication annotation. For example, in the lower part of figure 3_6 does not define the order between local and remote process.

~ 24 ~ 

Figure 3_6 Example of BP Message Flow usages

As for the rest of BP Connecting Objects, i.e. BP Sequence Flow and BP Associations are remaining unchanged from BPMN.

• BP Artifact

No modification is made; they inherit the properties from BPMN objects directly.

Remote Process

Remote Process Local Process

Send task

Receive task

Local Remote

Synchronous flow

Local Remote

Communication annotation

~ 25 ~