Fragments
Fragments represent sub-processes (cf. F2) that are modeled with BPMN elements (cf. F1). Therefore, some guidelines from Corradini et al. are used here, since they also apply to the modeling of fragments. They are marked by the reference [Corradini et al. 2018].
Description: In fragments, the designer should use the following subset of BPMN elements: activities (including types), start and intermediate events (including types), control flow, XOR gateways, data objects, data associations, and annotations. For further information on these elements please refer to the BPMN standard documentation.
References: [Hewelt and Weske, 2016], [Haarmann, 2020]
Description: The designer should use a fragment to represent a structured part of a process. A structured part of a process is indicated by a set of activities with low variability in execution. The process should be split up whenever a decision requires human involvement to determine the further execution path. When a fragment is started, the intention should be to execute it till the end, even though in some cases the case may terminate before.
Motivation: With too many small fragments, the decision space becomes very complex which makes grasping possible execution paths very difficult.
Example: Consider following example showing two fragments from the introduced use case. The different fragments give an impression of how fragments can be modeled in general. The left fragment consists of two activities that are connected with a control flow. This means that the activity Conduct court session is always followed by the activity Pass sentence. This behavior is quite typical for semi-structured processes, i.e., that a set of activities is executed in a certain order. In comparison, the right fragment consists of a single activity. This expresses the fact that the Appeal activity is optional and can be selected and executed flexibly at runtime. It therefore also represents a part of the process.
References: [Hewelt and Weske, 2016], [Haarmann, 2020]
Description: A minimal fragment consists of at least one task. Often, the designer should include data objects for pre-conditions to enable the activity correctly (cf. F4).
Motivation: Fragments exist to give the knowledge worker the opportunity to select the next activities to be executed. If there are no activities in a fragment, the fragment should not be modeled as such.
Example: Consider following example of a fragment of the criminal justice use case consisting of one activity and data conditions. The activity Imprison defendant is enabled if its pre-condition (data object Defendant in state [sentenced to imprisonment]) is met. Executing the activity results in a state transition for the data object Defendant from state [sentenced to imprisonment] to [imprisoned].
Description: Whenever possible (and known), the designer should add data pre- and postconditions to activities via data objects and states. There is no separate data precondition for a fragment. It is implicitly given by the precondition of its first activity.
Motivation: It is not required to model data conditions since a minimal fragment can consists of only one activity (cf. F3). Nevertheless, it supports process execution in terms of optionality and readability. An activity without any conditions can always be executed but does not add any knowledge/read any data.
Example: Pre- and post-conditions allow to differentiate between control flow enablement and data flow enablement. Consider following example showing two fragments of the criminal justice use case. The fragment on the left hand-side do have pre- and post-conditions whereas the fragment on the right hand-side do not have conditions. This means that the right fragment is always data flow enables since the data pre-condition is always met (because there is none). If knowledge workers select this fragment, it directly becomes control flow enabled and the activity Imprison defendant can be executed. In contrast, the left fragment is only data flow enabled if and only if the pre-condition (Defendant in state [sentenced to imprisonment]) is met. If, for example, the data object Defendant is in another state and knowledge workers select this fragment it would only be control flow enabled but not data flow enabled.
We recommend to always use pre- and post conditions if possible to allow the differentiation between these two enablements.
References: [Haarmann, 2020], [Haarmann et al., 2020]
Description: If no explicit in- or output sets are provided, pre- and postconditions consisting of multiple data objects require/produce all of the data objects, representing a logical AND. If this is not the desired behavior, the designer should explicitly define in- and output sets. Input and output sets are determined, for example, by different shapes as indicators (see example below).
In addition to BPMN, the following labeling of data objects is allowed:
- "Data Class [state1 | state2]" to indicate that both states are possible for that data object (in respective in- and output sets).
- Similarly, "Data Class [*]" indicates that all states are possible.
Example: Consider following execution example of input/output sets of the criminal justice use case. We now want to execute the activity Pass sentence. So let's have a look at its pre-conditions consisting of multiple data objects. We can differentiate into two input sets shown on the top left and on the bottom left meaning that the activity Pass sentence can be executed either if the data object Defendant is in state [in hearing] AND the Personal judgement is in state [announced] (marked in blue, top left) or if the data object Defendant is in state [in hearing] AND the Personal judgement is in state announced AND the Sentence is in state [appealed] (marked in red, bottom left).
Let's have a look at the post-conditions of the activity Pass sentence shown on the right. In both cases the data object Sentence is transitioned to state [announced]. The data object Defendant, however, can be either transitioned into state [innocent] (marked in blue, top right) or into state [sentenced to imprisonment] (marked in red, bottom right). These two options are not marked as an output set since both state transitions are always executed. The alternative of Defendant is defined via an OR as explained above.
References: [Haarmann et al., 2020]
Description: The designer should use start events to indicate the initial fragments of the process. Only initial fragments can be executed right after case instantiation. They create the case class data object. Thus, they can only be executed once within the same case. Nevertheless, multiple fragments can iclude start events.
Motivation: Originally, start events were used for each fragment [Hewelt and Weske, 2016]. However, that way they do not add any semantics to the process model because a fragment is enabled if the data preconditions are fulfilled.
Example: Consider following example of the criminal justice use case showing the start fragment of the process. The fragment is the very beginning of each process execution and therefore contains a start event.
References: [Haarmann, 2020]
Description: The designer should not use BPMN end events in fragments. The process termination is defined through the goal state.
Motivation: Although fCM originally had included end events for each fragment [Hewelt and Weske, 2016], they are not used in the current version. The process is terminated only because of data objects that are in special states and not because of completed fragments. Therefore, designers should not use end events since they could imply a wrong understanding while having no value adding semantics.
Example: Consider the case when the activity Request sentence reduction has been completed. The defendant would be waiting for a decision on that request. However, it might be that by the time a decision is made in that regard, the defendant finishes serving their sentence and gets released, leading to the Defendant data object being in state [released], thus fulfilling the Goal State. Therefore, the process could terminate before the decision on the sentence reduction is made. Using an end event at the end of the upper fragment might lead to the assumption that it would be mandatory to finish the fragment before the case could terminate.
References: [Haarmann, 2020]
Description: The designer should use XOR gateways to represent automated decisions since knowledge workers do not necessarily have to get involved. For every decision that requires intervention of knowledge workers, the designer should model additional fragments instead of an XOR gateway.
Motivation: Syntactically, fCM always allows decisions to be modeled using XOR gateways or additional fragments. According to the Semiotic Clarity principle presented in [Moody, 2009], there should be a 1:1 correspondence between semantic constructs and notations to facilitate mental mapping. Therefore, these two notations should be used to clearly distinguish automated and manual decisions in a process.
Example: Consider following example of the criminal justice use case. We want to take a look at the different types of decisions taking place during process execution. Three activities (The mandatory activities Finish sentence and Release defendant, and the optional activity Conduct Treatment) are modeled in two different ways. On the top they are modeled as a subprocess in one single fragment whereas at the bottom they are modeled via three fragments. In the upper fragment the decision whether a treatment has to be conducted is modeled as an automated decision since the fragment includes the XOR gateway. The three fragments on the bottom model the same decision as a decision taken by knowledge workers since they actively have to select the fragment containing the activity Conduct treatment to enable the control flow.
References: [Moody, 2009]
Description: The designer should not use a gateway at the beginning of a fragment.
Motivation: During execution, the knowledge worker would have to manually start a gateway instead of an activity. This would have questionable semantics.
Description: The designer should limit the use of annotations to reduce complexity and overwhelming when reading the model.
References: [Corradini et al., 2018]
Description: The designer should label activities with a combination of one verb (present tense) and one object. Data objects should be labeled via a qualified noun and a state in squared brackets. States should be labeled using past participles or non-active verbs. In general, the designer should try to use short, simple and unique keywords for labeling.
Example:
References: [Corradini et al., 2018]
Description: The designer can use multiple dotted arrows per activity for ingoing/outgoing data flow but only one black arrow to model ingoing/outgoing sequence flow.
Example:
References: [Hewelt and Weske, 2016], [Haarmann, 2020]
[Corradini et al., 2018] Corradini, F., Ferrari, A., Fornari, F., Gnesi, S., Polini, A., Re, B., & Spagnolo, G. O. (2018). A guidelines framework for understandable BPMN models. Data & Knowledge Engineering, 113, 129-154.
[Haarmann, 2020] Haarmann, S. (2020). Fragment-Based Case Management Models: Metamodel, Consistency, and Correctness. Central-European Workshop on Services and their Composition (ZEUS 2020), 1, 1.
[Haarmann et al., 2020] Haarmann, S., Montali, M., & Weske, M. (2020). Technical Report: Refining Case Models Using Cardinality Constraints. arXiv preprint arXiv:2012.02245.
[Hewelt and Weske, 2016] Hewelt, M., & Weske, M. (2016, September). A hybrid approach for flexible case modeling and execution. In International Conference on Business Process Management (pp. 38-54). Springer, Cham.
[Moody, 2009] Moody, D. (2009). The “physics” of notations: toward a scientific basis for constructing visual notations in software engineering. IEEE Transactions on software engineering, 35(6), 756-779.