In this section, the semantic of several Modelio BPMN metaclasses are explained to in order to bring them back to concrete and practical considerations.

BPMN Process bpmnprocess.png

A BPMNProcess is the description of a particular workflow seen as the sequence of BPMNTask, BPMNEvent and other similar elements that make it up.

The generic term workflow elements designates the different elements used to define the workflow of a process, whatever their exact nature.

The term workflow designates the workflow elements of a process and their sequence.

A BPMNProcess can be created under a Package, a GeneralClass or an Operation.

The term process designates a BPMNProcess seen from the user (although in practice the user will not even see instances of BPMNProcess but rather instances of BPMNParticipant.)

BPMN Collaboration bpmncollaboration.png

A BPMNCollaboration is the description of how several BpmnProcess are collaborating through BpmnMessageFlows exchanged between BpmnParticipants.

BPMN Participant

In the metamodel, the exact behavior of a "system" described in BPMN, is represented as a collaboration between several so-called participants. These participants are of kind BPMNParticipant.

At the metamodel level, a BPMNParticipant is the representative of a BPMNProcess. End-users require more classification to distinguish between participants. This is described later.

Right now, let just say that describing a system in BPMN consists in creating (at least one) BPMN Collaboration in which several participants, representing several processes, collaborate to achieve the system’s behavior.

Participant classification

The initial key point is that a participant ( BPMNParticipant ) is an object that represents a process ( BPMNProcess ), being a kind of 'instance' of the process.

Several situations may occur:

  1. The participant does not represent any process (BPMNProcess)

  2. The participant represents a process (BPMNProcess)

    • The associated process (BPMNProcess) owns the BPMN Collaboration owning the participant.

    • The associated process (BPMNProcess) doesn’t own the BPMN Collaboration owning the participant.

The reason why the above distinction between participants is important is that Modelio will use specific representations for the different participants and allow/forbid particular interactions in the diagram depending on the exact nature of the participants.

Case 1:

In this situation, no process is associated to the participant which is perfectly allowed by the metamodel.

Such a participant without any bound process, is used to reference an external and unknown process of which only the existence, affirmed by the very existence of the participant, is known. In other word, the BPMN analyst user can affirm that the process exists (his name is probably known) but the process is defined elsewhere (if defined at all), out of the scope of the project or out of the responsibility of the user. Such a participant is called an external participant bpmnparticipant.png,

Obviously, the internal workflow of the participant is not specified, its workflow elements and their sequence are totally unknown.

Case 2.a:

In this case a participant is associated to a process that owns the BPMN Collaboration owning the participant.

Such a participant is called a local participant bpmnparticipant.local.png.

A participant of this type can retrieve the exact workflow of the associated BPMNProcess. Modelio will therefore allow edition of this BPMNProcess associated directly from the represented participant.

Case 2.b:

The case number 2.b corresponds to referencing a process (BPMNProcess) known and modeled in the current project but not related with the BPMN Collaboration owning the participant.

The participant is thus representing a process of another "system", Modelio treats this "distance" as a prohibition to modify the process associated directly from the participant. If the user needs to modify this process, he has to work directly on it.

Note that his logic easily matches the logic of SVN grains as managed by Teamwork. Unless it is checked-out at the Teamwork level, the associated process is visible but not modifiable in the current context.

Such participants are called referenced participants bpmnparticipant.referenced.png,

Participant classification summary table
Kind Associated process Usage Modelio behavior in diagrams

bpmnparticipant.png external participant

No associated process

Used to represent external process

No displayable workflow. No workflow edition.

bpmnparticipant.local.png local participant

Owning the Participant’s BPMN Collaboration

Used to represent internal processes that are under the control of the current user

The process workflow can be displayed by the participant.
Workflow edition is possible directly from the participant representation.

bpmnparticipant.referenced.png referenced participant

Defined in the current project but not owning the Participant’s BPMN Collaboration

Used to represent internal processes that are not under the responsibility of the current user

The process workflow can be displayed by the participant.
Edition is not allowed directly from the participant representation. The user willing to modify the process must 'navigate' to the corresponding BPMN Model.

BPMN Message Flow

Message flows (BPMNMessageFlow) are used for exchanges between participants within a BPMN Collaboration. They carry messages (BPMNMessage) containing information.

When a message flow is established between two participants, it is possible to specify the source by specifying a particular workflow element in the source participant’s BPMNProcess, the same possibility exists for the target participant.

However, as mentioned above, a participant may not be associated with a workflow (external participant), in which case it is not possible to specify a particular source or target workflow element. Such message flows (BPMNMessageFlow) are however allowed, they are only less precise and less specified than the others. This situation corresponds to the referencing of external processes on which the user does not have the hand.

Message flow examples between different participants:

MessageFlows.png
  • M1 and M2: these message flows connect a local participant and a referenced participant, both participant workflows are known, therefore it was possible to precisely specify the message sources and targets.

  • M3 and M4: these message flows connect a referenced participant and an external participant, only the referenced participant workflow is known, therefore it was not possible to precisely specify a source and target in the External Participant.