This section provides a summary of the BPMN graphical objects and their relationships. More details on the concepts will be provided in Business Process Diagram Graphical Objects and Business Process Diagram Connecting Objects.
A goal for the development of BPMN is that the notation be simple and adoptable by business analysts. Also, there is a potentially conflicting requirement that BPMN provide the power to depict complex business processes and map to BPM execution languages. To help understand how BPMN can manage both requirements, the list of BPMN graphic elements is presented in two groups.
First, there is the list of core elements that will support the requirement of a simple notation. These are the elements that define the basic look-and-feel of BPMN. Most business processes will be modeled adequately with these elements. Second, there is the entire list of elements, including the core elements, which will help support requirement of a powerful notation to handle more advanced modeling situations. And further, the graphical elements of the notation will be supported by non-graphical attributes that will provide the remaining information necessary to map to an execution language or other business modeling purposes.
It should be emphasized that one of the drivers for the development of BPMN is to create a simple mechanism for creating business process models, while at the same time being able to handle the complexity inherent to business processes. The approach taken to handle these two conflicting requirements was to organize the graphical aspects of the notation into specific categories. This provides a small set of notation categories so that the reader of a BPMN diagram can easily recognize the basic types of elements and understand the diagram. Within the basic categories of elements, additional variation and information can be added to support the requirements for complexity without dramatically changing the basic look and feel of the diagram. The four basic categories of elements are:
Flow objects are the main graphical elements to define
the behavior of a Business Process. There are three Flow Objects:
There are three ways of connecting the Flow Objects to
each other or other information. There are three Connecting Objects:
There are two ways of grouping the primary modeling
elements through "Swimlanes:"
Artifacts are used to provide additional information about the Process. There are four standardized Artifacts, but modelers or modeling tools are free to add as many Artifacts as required. There may be addition BPMN efforts to standardize a larger set of Artifacts for general use or for vertical markets. The current set of Artifacts include:
See BPD Core Element Set. displays a list of the core modeling elements that are depicted by the notation:
See BPD Complete Element Set. displays a more extensive list of the business process concepts that could be depicted through a business process modeling notation.
Text Annotation objects can be used by the modeler to display additional information about a Process or attributes of the objects within the Process.
·
Flow objects and Flow MAY have labels (e.g., its name and/or other
attributes) placed inside the shape, or above or below the shape, in any
direction or location, depending on the preference of the modeler or modeling
tool vendor.
·
The fills that are used to for the graphical elements MAY be white
or clear.
·
The notation MAY be extended to use other fill colors to suit the
purpose of the modeler or tool (e.g., to highlight the value of an object
attribute).
·
Flow objects and markers MAY be of any size that suits the
purposes of the modeler or modeling tool.
·
The lines that are used to draw the graphical elements MAY be
black.
·
The notation MAY be extended to use other line colors to suit the
purpose of the modeler or tool (e.g., to highlight the value of an object
attribute).
·
The notation MAY be extended to use other line styles to suit the
purpose of the modeler or tool (e.g., to highlight the value of an object
attribute) with the condition that the line style MUST NOT conflict with any
current BPMN defined line style. Thus, the line styles of Sequence Flow,
Message Flow, and Associations MUST NOT be modified.
An incoming Sequence Flow can connect to any location on a Flow Object (left, right, top, or bottom). Likewise, an outgoing Sequence Flow can connect from any location on a Flow Object (left, right, top, or bottom). Message Flow also have this capability. BPMN allows this flexibility, however, we also recommend that modelers use judgment or best practices in how Flow Objects should be connected so that readers of the Diagrams will find the behavior clear and easy to follow. This is even more important when a Diagram contains Sequence Flow and Message Flow. In these situations it is best to pick a direction of Sequence Flow, either left to right or top to bottom, and then direct the Message Flow at a 90° angle to the Sequence Flow. The resulting Diagrams will be much easier to understand.
See Sequence Flow Connection Rules. displays the BPMN Flow Objects and shows how these objects can connect to one another through Sequence Flow. The á symbol indicates that the object listed in the row can connect to the object listed in the column. The quantity of connections into and out of an object is subject to various configuration dependencies are not specified here. Refer to the sections in the next chapter for each individual object for more detailed information on the appropriate connection rules. Note that if a sub-process has been expanded within a Diagram, the objects within the sub-process cannot be connected to objects outside of the sub-process. Nor can Sequence Flow cross a Pool boundary.
See Message Flow Connection Rules.
displays the BPMN modeling objects and shows how these objects can connect to
one another through Message Flow. The ó symbol indicates that the object listed in the row can
connect to the object listed in the column. The quantity of connections into
and out of an object is subject to various configuration dependencies are not
specified here. Refer to the sections in the next chapter for each individual
object for more detailed information on the appropriate connection rules. Note
that Message Flow cannot connect to objects that are within the same
This is a unique Id that distinguishes the Diagram from other Diagrams. |
|
Name is an attribute that is text description of the Diagram. |
|
This holds the name of the language in which text is written. The default is English. |
|
A Language MAY be provided so that the syntax of expressions used in the Diagram can be understood. |
|
A Language MAY be provided so that the syntax of queries used in the Diagram can be understood. |
|
This defines the date on which the Diagram was created (for the current Version). |
|
This defines the date on which the Diagram was last modified (for this Version). |
|
A BPD SHALL contain one or more Pools. The boundary of one of the Pools MAY be invisible (especially if there is only one Pool in the Diagram). Refer to the See Pool. for more information about Pools. |
|
A BPD MAY contain zero or more Message Flows. A Message Flow MUST connect two separate Pools in the Diagram. |
|
The modeler MAY add optional text documentation about the Diagram. |
A Process is an activity performed within a company or organization. In BPMN a Process is depicted as a graph of Flow Objects, which are a set of other activities and the controls that sequence them. The concept of process is intrinsically hierarchical. Processes may be defined at any level from enterprise-wide processes to processes performed by a single person. Low-level processes may be grouped together to achieve a common business goal.
Note that BPMN defines the term Process fairly specifically and defines a Business Process more generically as a set of activities that are performed within an organization or across organizations. Thus a Business Process, as shown in a Business Process Diagram, may contain more than one separate Process. Each Process may have its own Sub-Processes and would be contained within a Pool (See Pool.). The individual Processes would be independent in terms of Sequence Flow, but could have Message Flow connecting them.
The following table displays the set of attributes of a Process:
This is a unique Id that identifies the object from other objects within the Diagram. |
|
Name is an attribute that is text description of the object. |
|
ProcessType (None | Private | Abstract | Collaboration) None : String |
ProcessType is an attribute that provides information about which lower-level language the Pool will be mapped.By default, the ProcessType is None (or undefined). A Private ProcessType MAY be mapped to an executable BPEL4WS process. An Abstract ProcessType is also called the public interface of a process (or other web services) and MAY be mapped to an abstract BPEL4WS process. A Collaboration ProcessType will have two Lanes that represent business roles (e.g., buyer or seller) and will show the interactions between these roles. These Pools MAY be mapped to languages such as ebXML or WS Choreography. However, these mappings are not provided in this version of the specification. If the Process is to be used to create a BPEL4WS document, then the attribute MUST be set to Executable or Abstract. |
Status (None | Ready | Active | Cancelled | Aborting | Aborted | Completing | Completed) None : String |
The Status of a Process is determined when the Process is being executed by a process engine. The Status of a Process can be used within Assignment Expressions. |
The GraphicalElements attribute identifies all of the objects (e.g., Events, Activities, Gateways, and Artifacts) that are contained within the Business Process. |
|
One or more assignment expressions MAY be made for the object. The Assignment SHALL be performed as defined by the AssignTime attribute. The details of the Assignment is defined in the See Assignment.. |
|
Modeler-defined Properties MAY be added to a Process. These Properties are "local" to the Process. All Tasks, Sub-Process objects, and Sub-Processes that are embedded SHALL have access to these Properties. The fully delineated name of these properties are "<process name>.<property name>" (e.g., "Add Customer.Customer Name"). If a process is embedded within another Process, then the fully delineated name SHALL also be preceded by the Parent Process name for as many Parents there are until the top level Process. Further details about the definition of a Property can be found in the See Property.. |
|
AdHoc is a boolean attribute, which has a default of False. This specifies whether the Process is Ad Hoc or not. The activities within an Ad Hoc Process are not controlled or sequenced in a particular order, their performance is determined by the performers of the activities. If set to True, then the Ad Hoc marker SHALL be placed at the bottom center of the Process or the Sub-Process shape for Ad Hoc Processes. |
|
AdHocOrdering (0-1) (Sequential | Parallel) Parallel : String |
If the Process is Ad Hoc (the AdHoc attribute is True), then the AdHocOrdering attribute MUST be included. This attribute defines if the activities within the Process can be performed in Parallel or must be performed sequentially. The default setting is Parallel and the setting of Sequential is a restriction on the performance that may be required due to shared resources. |
If the Process is Ad Hoc (the AdHoc attribute is True), then the AdHocCompletionCondition attribute MUST be included. This attribute defines the conditions when the Process will end. |
|
This attribute is included for mapping to BPEL4WS. This specifies whether or not a BPEL4WS joinFailure fault will be suppressed for all activities in the BPEL4WS process. |
|
This attribute is included for mapping to BPEL4WS. It specifies whether or not a compensation can be performed after the Process has completed normally. |
|
The modeler MAY add one or more defined Categories that can be used for purposes such as reporting and analysis. |
|