---
title: "9.3 Pool and Participant"
chapter: "9 Collaboration"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "111-119"
---
> 9 Collaboration · páginas 111-119 · [índice](../README.md)
## 9.3 Pool and Participant
A **Pool** is the graphical representation of a Participant in a **Collaboration**. A *Participant* (see page 113) can be a specific PartnerEntity (e.g., a company) or can be a more general PartnerRole (e.g., a buyer, seller, or manufacturer). A **Pool** MAY or MAY NOT reference a **Process**. A **Pool** is NOT REQUIRED to contain a **Process**, i.e., it can be a “black box.” A **Pool** is a square-cornered rectangle that MUST be drawn with a solid single line (see Figure 9.2).
The use of text, color, size, and lines for a **Pool** MUST follow the rules defined in “Use of Text, Color, Size, and Lines in a Diagram” on page 39.
*Figure 9.2 – A Pool* (p. 111)
To help with the clarity of the Diagram, a **Pool** extends the entire length of the Diagram, either horizontally or vertically. However, there is no specific restriction to the size and/or positioning of a **Pool**. Modelers and modeling tools can use **Pools** in a flexible manner in the interest of conserving the “real estate” of a Diagram on a screen or a printed page. A **Pool** acts as the container for the **Sequence Flows** between **Activities** (of a contained **Process**). The **Sequence Flows** can cross the boundaries between **Lanes** of a **Pool** (see page 304 for more details on **Lanes**), but cannot cross the boundaries of a **Pool**. That is, a **Process** is fully contained within the **Pool**. The interaction between **Pools** is shown through **Message Flows**. Another aspect of **Pools** is whether or not there is any **Activity** detailed within the **Pool**. Thus, a given **Pool** MAY be shown as a “White Box,” with all details (e.g., a **Process**) exposed, or as a “Black Box,” with all details hidden. No **Sequence Flows** are associated with a “Black Box” **Pool**, but **Message Flows** can attach to its boundaries (see Figure 9.3).
*Figure 9.3 – Message Flows connecting to the boundaries of two Pools* (p. 112)
For a “White Box” **Pool**, the **Activities** within are organized by **Sequence Flows**. **Message Flows** can cross the **Pool** boundary to attach to the appropriate **Activity** (see Figure 9.4).
*Figure 9.4 – Message Flows connecting to Flow Objects within two Pools* (p. 112)
A **Collaboration** can contain two (2) or more **Pools** (i.e., *Participants*). However, a **Process** that represents the work performed from the point of view of the modeler or the modeler’s organization can be considered “internal” and is NOT REQUIRED to be surrounded by the boundary of the **Pool**, while the other **Pools** in the Diagram MUST have their boundary (see Figure 9.5).
*Figure 9.5 – Main (Internal) Pool without boundaries* (p. 113)
**BPMN** specifies a marker for **Pools**: a *multi-instance* marker May be displayed for a **Pool** (see Figure 9.6). The marker is used if the *Participant* defined for the **Pool** is a *multi-instance Participant*. See page 116 for more information on *Participant* multiplicity. The marker for a **Pool** that is a *multi-instance* MUST be a set of three vertical lines in parallel. The marker, if used, MUST be centered at the bottom of the shape.
*Figure 9.6 – Pools with a Multi-Instance Participant Markers* (p. 113)
### 9.3.1 Participants
A *Participant* represents a specific PartnerEntity (e.g., a company) and/or a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that are *Participants* in a **Collaboration**. A *Participant* is often responsible for the execution of the **Process** enclosed in a **Pool**; however, a **Pool** MAY be defined without a **Process**. Figure 9.7 displays the class diagram of the *Participant* and its relationships to other **BPMN** elements. When *Participants* are defined they are contained within a **Collaboration**, which includes the sub-types of **Choreography**,
*Figure 9.7 – The Participant Class Diagram* (p. 114)
The *Participant* element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 9.2 presents the additional attributes and model associations for the *Participant* element.
**Table 9.2 – Participant attributes and model associations**
| Attribute Name | Description/Usage |
| --- | --- |
| **name**: string [0..1] | Name is a text description of the *Participant*. The name of the *Participant* can be displayed directly or it can be substituted by the associated PartnerRole or PartnerEntity. Potentially, both the PartnerEntity name and PartnerRole name can be displayed for the *Participant*. |
| **processRef**: Process [0..1] | The processRef attribute identifies the **Process** that the Participant uses in the *Collaboration*. The **Process** will be displayed within the *Participant’s* Pool. |
| **partnerRoleRef**: PartnerRole [0..*] | The partnerRoleRef attribute identifies a PartnerRole that the *Participant* plays in the Collaboration. Both a PartnerRole and a PartnerEntity MAY be defined for the *Participant*. This attribute is derived from the participantRefs of PartnerRole. |
| **partnerEntityRef**: PartnerEntity [0..*] | The partnerEntityRef attribute identifies a PartnerEntity that the *Participant* plays in the *Collaboration*. Both a PartnerRole and a PartnerEntity MAY be defined for the *Participant*. This attribute is derived from the participantRefs of PartnerEntity. |
| **interfaceRef**: Interface [0..*] | This association defines Interfaces that a *Participant* supports. The definition of Interfaces is provided on page 102. |
| **participantMultiplicity**: participantMultiplicity [0..1] | The participantMultiplicityRef model association is used to define *Participants* that represent more than one (1) instance of the *Participant* for a given interaction. See the next sub clause for more details on ParticipantMultiplicity. |
| **endPointRefs**: EndPoint [0..*] | This attribute is used to specify the address (or endpoint reference) of concrete services realizing the *Participant*. |
#### PartnerEntity
A PartnerEntity is one of the possible types of *Participant* (see above). The PartnerEntity element inherits the attributes and model associations of BaseElement (see Figure 8.5). Table 9.3 presents the additional attributes and model associations for the PartnerEntity element.
**Table 9.3 – PartnerEntity attributes**
| Attribute Name | Description/Usage |
| --- | --- |
| **name**: string | Name is a text description of the PartnerEntity. |
| **participantRef**: Participant [0..*] | Specifies how the PartnerEntity participates in **Collaborations** and **Choreographies**. |
#### PartnerRole
A PartnerRole is one of the possible types of *Participant* (see above). The PartnerRole element inherits the attributes and model associations of BaseElement (see Figure 8.5). Table 9.4 presents the additional attributes and model associations for the PartnerRole element.
**Table 9.4 – PartnerRole attributes**
| Attribute Name | Description/Usage |
| --- | --- |
| **name**: string | Name is a text description of the PartnerRole. |
| **participantRef**: Participant [0..*] | Specifies how the PartnerRole participates in **Collaborations** and **Choreographies**. |
#### Participant Multiplicity
ParticipantMultiplicity is used to define the multiplicity of a Participant. For example, a manufacturer can request a quote from multiple suppliers in a **Collaboration**.
*Figure 9.8 – A Pool with a Multiple Participant* (p. 116)
The following figure shows the Participant class diagram.
*Figure 9.9 – The Participant Multiplicity class diagram* (p. 116)
The *multi-instance* marker will be displayed in bottom center of the **Pool** (*Participant* - see Figure 9.9, above), or the **Participant** Band of a **Choreography Activity** (see page 321), when the ParticipantMultiplicity is associated with the *Participant*, and the maximum attribute is either not set, or has a value of two or more. Table 9.5 presents the attributes for the ParticipantMultiplicity element.
**Table 9.5 – ParticipantMultiplicity attributes**
| Attribute Name | Description/Usage |
| --- | --- |
| **minimum**: integer = 0 | The minimum attribute defines minimum number of Participants that MUST be involved in the **Collaboration**. If a value is specified in the maximum attribute, it MUST be greater or equal to this minimum value. |
| **maximum**: integer [0..1] = 1 | The maximum attribute defines maximum number of Participants that MAY be involved in the **Collaboration**. The value of maximum MUST be one or greater, AND MUST be equal or greater than the minimum value. |
Table 9.6 presents the *Instance* attributes of the ParticipantMultiplicity element.
**Table 9.6 – ParticipantMultiplicity Instance attributes**
| Attribute Name | Description/Usage |
| --- | --- |
| **numParticipants**: integer [0..1] | The current number of the multiplicity of the *Participant* for this **Choreography** or **Collaboration** *Instance*. |
#### ParticipantAssociation
These elements are used to do mapping between two elements that both contain *Participants*. There are situations where the *Participants* in different diagrams can be defined differently because they were developed independently, but represent the same thing. The ParticipantAssociation provides the mechanism to match up the *Participants*. A ParticipantAssociation is used when an (*outer*) diagram with *Participants* contains an (*inner*) diagram that also has *Participants*. There are four usages of ParticipantAssociation. It is used when:
1. A Collaboration references a Choreography for inclusion between the Collaboration’s Pools (Participants). The *Participants* of the **Choreography** (the inner diagram) need to be mapped to the *Participants* of the **Collaboration** (the outer diagram).
2. A Call Conversation references a Collaboration or GlobalConversation. Thus, the Participants of the **Collaboration** or GlobalConversation (the inner diagram) need to be mapped to the *Participants* referenced by the **Call Conversation** (the outer element). Each **Call Conversation** contains its own set of
3. A Call Choreography references a Choreography or GlobalChoreographyTask. Thus, the Participants of the **Choreography** or GlobalChoreographyTask (the inner diagram) need to be mapped to the *Participants* referenced by the **Call Choreography** (the outer element). Each **Call Choreography** contains its own set of
4. A Call Activity within a Process that has a definitional Collaboration references another Process that also has a *definitional* **Collaboration**. The *Participants* of the *definitional* **Collaboration** of the called **Process** (the inner diagram) need to be mapped to the *Participants* of the *definitional* **Collaboration** of the calling **Process** (the outer diagram).
A ParticipantAssociation can be owned by the outer diagram or one its elements. Figure 9.10 shows the class diagram for the ParticipantAssociation element.
*Figure 9.10 – ParticipantAssociation class diagram* (p. 118)
The ParticipantAssociation element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 9.7 presents the additional model associations for the ParticipantAssociation element.
**Table 9.7 – ParticipantAssociation model associations**
| Attribute Name | Description/Usage |
| --- | --- |
| **innerParticipantRef**: Participant | This attribute defines the *Participant* of the referenced element (e.g., a **Choreography** to be used in a **Collaboration**) that will be mapped to the parent element (e.g., the **Collaboration**). |
| **outerParticipantRef**: Participant | This attribute defines the *Participant* of the parent element (e.g., a **Collaboration** references a **Choreography**) that will be mapped to the referenced element (e.g., the **Choreography**). |
### 9.3.2 Lanes
A **Lane** is a sub-partition within a **Process** (often within a **Pool**) and will extend the entire length of the **Process** level, either vertically (see Figure 10.123) or horizontally (see Figure 10.124). See page 304 for more information on **Lanes**.