Data Model
Description: For representing data models, the designer should use a subset of UML Class Diagrams. Supported notation elements are: Classes with names and (typed) attributes, associations with multiplicities between them. In addition, goal multiplicity constraints may be defined using a diamond symbol as introduced in [Haarmann et al., 2021].
Example: To give an impression about how a data model can look like, please have a look at the figure shown below: The data model of the case model of the example use case of criminal justice.
References: [Haarmann et al., 2021]
Description: The designer should specify a case class in every fCM data model. The case class does not necessarily contain much information and may be an abstract class, however, it is the class that all the other classes are connected to.
Example:
References: [Haarmann, 2020], [Hewelt and Weske, 2016]
Description: The designer should directly or indirectly connect every class in the data model to the case class via existential associations.
Motivation: When every class in the data model is directly or indirectly connected to the case class via existential associations, each created data object can always be assigned to exactly one case object.
Example:
References: [Haarmann, 2020]
Description: The designer should define multiplicities on each association in the data model. They should be as specific/narrow as possible while complying with D3. In addition, the designer can add goal multiplicities, indicating how many data objects of each class have to be associated with each other in order to represent a valid final state.
Example: In the example, multiplicities are specified for each association. Only for the association between Personal judgement and Sentence an additional goal multiplicity is specified, meaning that in the end there has to be at least one sentence for each personal judgement in order for the case to terminate. However, since at the personal judgements are made before the sentence, the global multiplicity has to be 0..1.
References: [Haarmann, 2020], [Haarmann and Weske, 2020]
Description: Important and essential information for the process should be encoded in data object states. However, the designer can use attributes if required. For instance, attributes must be used for continuous values.
Motivation: Fragment-based Case Management is highly data-driven. Therefore, important changes in data should be visible to designers and knowledge workers as states. Attributes can be used for automated decisions and to provide context information to the knowledge worker. Their use depends on the specific needs, tasks and context of the process model.
Example: Consider the optional treatment defined in the sentence. If the judge orders a treatment, it is an important step in the process when it is completed. The exact treatment (psychological, physiological, etc.) is instance-specific and should not be defined generally in a state. Therefore it is specified here as an attribute. The state that is reached as soon as the treatment has been completed is assigned to the case class in order to emphasize its importance (cf. O2).
Description: Multiplicity constraints should not contradict themselves.
Example: If a data class is linked to itself via several (indirect) connections in a "circle", the designer should apply the following rule for multiplicities along this "circle": Since each data class A of the "circle" has at least two connections to the other data classes of the "circle", no lower bound of A should be greater than any other upper bound of A. Concretely, the lower model cannot be correct because a Sentece must be connected to exactly six Personal judgements. However, a Defendant can only be connected to up to five personal judgements which results in a contradiction.
References: [Haarmann and Weske, 2020]
Description: When there is a circle in the data model, the designer should be careful in defining the multiplicities. Beside taking guideline D6 into account, the designer should avoid infinitely cyclic dependencies as defined in [Montali and Calvanese, 2016].
References: [Montali and Calvanese, 2016]
[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 and Weske, 2020] Haarmann, S., & Weske, M. (2020, September). Data Object Cardinalities in Flexible Business Processes. In International Conference on Business Process Management (pp. 380-391). Springer, Cham.
[Haarmann et al., 2021] Haarmann, S., Montali, M., & Weske, M. (2021, June). Refining Case Models Using Cardinality Constraints. In International Conference on Advanced Information Systems Engineering (pp. 296-310). Springer, Cham.
[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.
[Montali and Calvanese, 2016] Montali, M., & Calvanese, D. (2016). Soundness of data-aware, case-centric processes. International Journal on Software Tools for Technology Transfer, 18(5), 535-558.