Task C

Task D

The Properties of “Process A” are accessible by: “Process A,” “Task A,” “Sub-Process A,” “Task B,” “Sub-Process B,” “Sub-Process C,” “Task C,” and “Task D.”

The Properties of “Sub-Process A” are accessible by: “Sub-Process A” and “Task B.”

The Properties of “Task C” are accessible by: “Task C.”

Data Inputs and Outputs

Activities and Processes often need data in order to execute. In addition they can produce data during or as a result of execution. Data requirements are captured as Data Inputs and InputSets. Data that is produced is captured using Data Outputs and OutputSets. These elements are aggregated in a InputOutputSpecification class.

Certain Activities and CallableElements contain a InputOutputSpecification element to describe their data requirements. Execution semantics are defined for the InputOutputSpecification and they apply the same way to all elements that extend it. Not every Activity type defines inputs and outputs, only Tasks, CallableElements (Global Tasks and Processes) MAY define their data requirements. Embedded SubProcesses MUST NOT define Data Inputs and Data Outputs directly, however they MAY define them indirectly via

MultiInstanceLoopCharacteristics.

Figure 10.57 – InputOutputSpecification class diagram

The InputOutputSpecification element inherits the attributes and model associations of BaseElement (see Table 8.5). Figure 10.54 presents the additional attributes and model associations of the

InputOutputSpecification element.

Table 10.58 – InputOutputSpecification Attributes and Model Associations

Data Input

A Data Input is a declaration that a particular kind of data will be used as input of the InputOutputSpecification. There may be multiple Data Inputs associated with an

InputOutputSpecification.

The Data Input is an item-aware element. Data Inputs are visually displayed on a Process diagram to show the inputs to the top-level Process or to show the inputs of a called Process (i.e., one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling Process).

Visualized Data Inputs have the same notation as Data Objects, except that they MUST contain a small, unfilled block arrow (see Figure 10.58).

Data Inputs MAY have incoming Data Associations:

If the Data Input is directly contained by the top-level Process, it MUST not be the target of Data Associations within the underlying model. Only Data Inputs that are contained by Activities or Events MAY be the target of Data Associations in the model.

If the Process is being called from a Call Activity, the Data Associations that target the Data Inputs of the Call Activity in the underlying model MAY be visualized such that they connect to the

corresponding Data Inputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations target the Data Inputs of the Call Activity and not the Data Inputs of the called Process.

Figure 10.58 – A DataInput

The “optional” attribute defines if a DataInput is valid even if the state is “unavailable.” The default value is false. If the value of this attribute is true, then the execution of the Activity will not begin until a value is assigned to the DataInput element, through the corresponding Data Associations.

States

DataInput elements can optionally reference a DataState element, which is the state of the data contained in the DataInput. The definition of these states, e.g., possible values, and any specific semantics are out of scope of this International Standard. Therefore, BPMN adopters can use the DataState element and the BPMN extensibility capabilities to define their states.

Figure 10.59 – Data Input class diagram

The DataInput element inherits the attributes and model associations of BaseElement (see Table 8.5) and ItemAwareElement (Table 10.52). Table 10.59 presents the additional attributes and model associations of the

DataInput element.