Figure 173: Annotation
BPMN models are focused on sequence and message flows, and on exchanged data. If other aspects relevant to a business process need to be mapped, it is possible to use artifacts.
So far, the BPMN specification has defined three standard types of artifacts: Annotations, groups, and associations. In addition to these, modelers and tool vendors are free to define their own artifacts, thus complementing BPMN with required constructs.
Annotations and groups have already been used in several examples, e.g. in figure 10 and figure 146.
Figure 173: Annotation
An annotation is used for adding explanations, remarks, etc. to a certain model element (figure 173). Thus, annotations increase the understanding of a model. They do not have any effect on the control flow logic of the model.
On the other hand, annotations can also be used for documenting exit conditions of a loop, for example (cf. figure 110). The exit conditions themselves naturally do have an effect on the control flow logic of the process. In BPMN, however, the exit conditions, etc. are rather defined by attribute values of the respective modeling elements. The presentation in the model by annotations is only for documentation purposes. Usually, they are not evaluated, e.g. by process engines.
An annotation is represented by an opening square bracket. It can be connected with any element in a BPMN model via a dotted association, e.g. for adding a comment or explanation to this element.
Associations must be distinguished from sequence and message flows. The representation by a dotted line is the same as that of a data association. The BPMN specification indeed differentiates between associations and data associations, but this difference is mainly relevant in the context of process execution. If the direction is relevant, an association can also be drawn with an arrow. Such a directed association is used for assigning a compensation activity to another activity (cf. figure 147).
A group is drawn as a rounded rectangle. Its border consists of a line of dots and dashes (figure 174). The dots and dashes must be clearly visible. Otherwise, it could be confused with a sub-process.
Like all artifacts, a group is purely a graphical object without any relevance for the logic of a BPMN diagram. Therefore, it is possible to use it without any restrictions, for highlighting interesting parts of a model, or for grouping elements which are related to each other. It is also allowed to draw groups across the borders of pools and lanes. As a purely graphical element, a group cannot be the source or the target of a sequence or message flow. Flows can rather cross group borders as desired.
As already mentioned, any BPMN construct can be graphically changed and adapted, as long as the original BPMN shape is still clearly recognizable and cannot be confused with other types of elements. For example, it is possible to use different colors and fonts. When using colors, it must be considered that some information is denoted by different shadings. In choreography activities, initiating partners are differentiated from the other partners by white and gray bands. When using other colors, the difference must be made clear by lighter and darker coloring.
Care must be taken, too, when changing line styles and widths, since these usually have a meaning. For example, an end event must have a thicker border than a start or intermediate event. Solid, dashed, and dotted lines must also be clearly visible, in order to distinguish between sequence flows, message flows, and associations. The solid borders of sub-processes and the dot and dash borders of groups must be preserved, as well.
The graphical symbols of modeling elements can be modified. However, the BPMN basic symbols must remain recognizable. An activity can be appended with an additional icon, but it must still be represented by a rounded rectangle. Likewise, the envelope symbol of a message event must not be replaced by an entirely different symbol. It must also remain visible whether the symbol in an event is filled or blank because this depicts the difference between throwing and catching events.
Furthermore, additional attributes can be defined for BPMN elements. This is especially interesting because the pre-defined attributes are mainly used for execution by a process engine. More business-related attributes, such as cost rates, can be added via BPMN’s extension mechanism.
Eventually, it is also possible to define additional artifacts and connect them to the existing BPMN elements via associations. Maybe it is required to show which services are provided by an activity, or which software application or machine is used for it. In many cases, the use of lanes for assigning organizational units or performing roles will not be sufficient. As an example, activities can be performed jointly by several people, or it needs to be differentiated between a role which is responsible for an activity and one which performs this activity.
The BPMN standard does not yet provide specific constructs for integrating such elements from other views of an enterprise model. By using self-defined artifacts, it is easy to create this connection. BPMN explicitly allows for connecting artifacts with objects from other types of models, such as organizational charts or UML diagrams. When using a modeling tool, it needs to be checked whether it already contains such extensions. Alternatively, it may allow for the definition of individual artifacts.
The described possibilities for extending BPMN are such that everybody who knows the BPMN standard can understand an extended BPMN model without any problems. Only the additional information contained in the individual extensions will not be clear to him without additional explanation.
However, if many individual extensions are used, it may be the case that a large portion of relevant information is contained in these extensions. In this case, many advantages of using a standard get lost, such as the common understanding and the exchangeability with other tools.
