=Paper=
{{Paper
|id=Vol-2839/paper1
|storemode=property
|title=Fragment-Based Case Management Models: Metamodel, Consistency, & Correctness
|pdfUrl=https://ceur-ws.org/Vol-2839/paper1.pdf
|volume=Vol-2839
|authors=Stephan Haarmann
|dblpUrl=https://dblp.org/rec/conf/zeus/Haarmann21
}}
==Fragment-Based Case Management Models: Metamodel, Consistency, & Correctness==
https://ceur-ws.org/Vol-2839/paper1.pdf
Fragment-Based Case Management Models:
Metamodel, Consistency, and Correctness
Stephan Haarmann
Hasso Plattner Institute, University of Potsdam, Potsdam, Germany
stephan.haarmann@hpi.de
Abstract. Knowledge-intensive processes are inherently complex. Thus, model-
ing them is hard as the models have to capture various perspectives often using
sub-models with hidden dependencies, e.g., the behavior of a process is constrained
by cardinality constraints in a domain model. Yet, models are desirable as they are
the primary tool in business process management to analyze, design, implement,
and enact processes. We present a metamodel, consistency and correctness criteria
for fragment-based case management. The criteria can i) be verified automatically
and ii) used to assist modelers at design-time. Thereby, mistakes can be detected
and even prevented during design, so model quality improves.
Keywords: Business Process Management, Process Modeling, Case Management
1 Introduction
Managing knowledge-intensive business processes is hard, and traditional business
process management (BPM) is insufficient for this task [16]. While traditional business
processes are highly structured, well-defined, and repetitive, knowledge-intensive ones
are emergent, multi-variant, data-driven, and non-repeatable [3]. While highly structured
processes are often modeled using imperative modeling languages, purely imperative
models of knowledge-intensive processes are often perplexing.
Knowledge-intensive processes are executed by domain experts called knowlegde-
workers, such as physicians, lawyers, and insurance clerks. The curse of the process is
primarily determined by the decisions of the knowledge-workers, which are based on
experience and case-specific information. Furthermore, knowledge-intensive processes
are usually human-centered with little to no automation.
Novel modeling approaches fitted to knowledge-intensive processes have been pro-
posed. Among them are case management approaches [1, 17]. In case management,
knowledge workers gather, create, and maintain data. A case (process instance) evolves
around this data. Every case has one central object, the case object (sometimes case
folder). A case model describes both the data and the activities involved in a case as
well as dependencies among them. Case management approaches can model knowledge-
intensive processes more concisely than imperative languages. However, creating con-
sistent and correct models can be difficult due to the inherent complexity and hid-
den dependencies. We propose a metamodel, consistency and correctness criteria for
J. Manner, S. Haarmann, S. Kolb, N. Herzberg, O. Kopp (Eds.): 13th ZEUS Workshop,
ZEUS 2021, Bamberg, held virtually due to Covid-19 pandemic, Germany, 25-26 February 2021,
published at http://ceur-ws.org
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License
Attribution 4.0 International (CC BY 4.0).
2 Stephan Haarmann
fragment-based case management (fCM) [9]. fCM models are highly modular and cap-
ture data-centric processes concisely; however, they contain hidden dependencies, e.g.,
the behavior of the process is constrained by cardinality constraints in the data model.
The criteria that we propose can be used to assist modelers to avoid mistakes.
In the next section, we introduce fCM with a metamodel and an example. Based
on this, we present consistency and correctness criteria (Sect. 3). In Sect. 4, we discuss
related work. Finally, we conclude and discuss our contribution (Sect. 5).
2 fCM Metamodel and Example
As depicted in Fig. 1, an fCM case model consists of a data model (domain model), a
process model (fragments), and a goal specification called termination condition [9]. The
data model consists of classes and (binary) associations among them1 . Each class has an
object life cycle (OLC), which defines the behavior of respective objects. A dedicated
case class denotes the central object which is created exactly ones for each case.
An OLC is a finite state transition system. For each class, a set of states and state
transitions is defined. This object behavior is instantiated by the process: knowledge
workers execute activities that create data objects and update their states accordingly.
Activities are included in small control flow graphs, the so-called fragments. Activi-
ties read and write data objects that belong to a single input- and output-set, respectively.
CaseModel
1..* 1 1
1 1..*
DomainModel ObjectLifeCycle Fragment
1
1 1
* caseClass 1 1..* 1..*
1
Association Class 1 1 *
State
ControlFlow
in
1 1 source 1 target
* out
2 * * out * in *
1..* 1 target
AssociationEnd StateTransition 1
ControlFlowNode
+ lowerBound : uint source
+ upperBound : uint
Event Activity XORGateway
* **
1..* 1 outputSet outputSets * * inputSet
1
ObjectConfiguration * DataObjectNode * DataSet
1 *
+ isSet : bool
1
*
* *
DataCondition TerminationCondition
1..*
Fig. 1. fCM metamodel: a case model comprises a domain model including classes and associations,
a set of fragments, and a termination condition.
1
Due to space limitation, we do not consider goal cardinality constraints, which have been
introduced in [6, 8].
Fragment-Based Case Management Models 3
Such objects are specified by data object nodes, which consist of an object configuration
specifying the class and the state of the object and of an indicator (isSet, depicted as |||)
showing whether multiple object’s of the same type in the same state may be read.
Some fragments have start events marking the beginning of a new case. Such an
event can create data objects. Also, a fragment can branch conditionally (XOR-Gateway).
While a fragment is similar to an imperative process model, all fragments operate on
shared data. Thus, data requirements of activities can be used to model dependencies
among fragments declaratively. At run-time, knowledge workers can instantiate and
execute fragments repeatedly and concurrently if the activities’ data-requirements permit.
A case that meets the termination condition can be closed by the knowledge workers.
For an example, consider the paper sub-
<> 1..1 Paper mission and reviewing at an academic confer-
Conference 0..1000
ence. The domain model Fig. 2 comprises the
1..1 1..1
0..1 0..5 classes Conference, Paper, Review, and
3..5
Decision. Conference is the case class.
Decision Review
0..1 For each conference, multiple papers can be
submitted; for each paper, multiple reviews
Fig. 2. Domain model of the paper submis-
can be created; for each paper, a decision is
sion and reviewing phase. made based on at least three reviews.
Figure 3 shows the OLCs for the classes
in Fig. 2. All but one OLC are described by a sequence of states, but OLCs can branch
in case of alternative state progression and even contain disconnected subgraphs in case
of alternative initial states. A decision object can be in one of the two alternative states
accepted and rejected. OLCs do not define initial or final states. Since activities, create
and change data objects, initial and final states are encoded in the process behavior.
Adding them to the OLCs would add redundancy but provide only little value.
The case behavior is defined by a set of fragments (see Fig. 4). The example has
one start event in fragment f1. When the start event occurs, a new case is started; the
conference object is created; and activity “open submission” is enabled. Afterwards, the
requirements of “submit paper” in fragment f2 are satisfied. It can be executed repeatedly.
Eventually, the knowledge workers perform “close submission” (f1) changing the state of
the conference object and disabling fragment f2 consequently. It also changes all papers
co n fe re n ce
scheduled open for closed for reviewing
submissions submissions closed
paper
submitted in_review reviewed
d e cis io n
accepted rejected
re vie w
required available considered
Fig. 3. Object life cycles for the classes in the domain model (Fig. 2)
4 Stephan Haarmann
to state in review (shown by the set indicator |||). Fragment f3 can hence be executed to
assign reviewers to papers. From the domain model, we know that each paper has at most
5 reviews. Therefore, fragment f3 can at most be executed 5 times for each paper. As soon
as a reviewer has been assigned, the review can be created (fragment f4). While there
is a dependency between the fragments f3 and f4, a review can be created before, after,
or during the assignment of other reviewers. The order is determined by the knowledge
workers. Similarly, activity “decide on paper” (fragment f5) can be executed as soon
as all reviews assigned to a particular paper have been created. The activity has three
possible outcomes: if there are less than 5 reviews for the paper, an additional reviewer
may be assigned (output set {review[required]}; if there are at least 3 reviews, the paper
may be rejected (output set {paper[rejected],reviews[considered],paper[reviewed]})
or accepted (output set {paper[accepted],reviews[considered],paper[reviewed]}). The
different output sets are not part of the visual notation. Once all papers of the conference
are in state reviewed, the reviewing can be closed (fragment f1).
The termination condition conference[reviewing closed] is satisfied after
fragment f1 has been executed completely. The case can be closed.
Legend:
conference conference conference conference conference
[open for [closed for [reviewing [open for
[scheduled] submissions] submissions] closed] submissions]
start event
open close close
submission submission reviewing submit paper paper
conference
[submitted]
scheduled
Activity
papers papers papers
[submitted] [in review] [reviewed]
f1 f2
data object
[state] assign
paper review reviews reviews review
reviewer
isSet = true [in review] [required] [available] [considered] [required]
f3
decide on decision
data flow paper paper
[rejected]
[in_review]
control flow decision
review review paper review paper paper
[in review] [accepted] [reviewed]
[required] [available]
f4 f5
Fig. 4. Fragments for the paper submission and reviewing at an academic conference. Fragment
f1 captures the progression of the conference. Fragment f2 handles the paper submission, f3 the
assignment of reviewers, f4 the creation of reviews, and f5 the decision whether a paper is accepted,
rejected, or an additional review is required.
Fragment-Based Case Management Models 5
3 Consistency and Correctness Criteria
As imminent from the example, all parts of the case model play together during a case.
Fragments are connected through shared data, whose structure and behavior is modeled
by the domain model and OLCs. The knowledge workers choose from enabled activities
to progress the case towards the termination condition. Therefore, it is important that i)
the parts are correctly modeled and ii) consistently integrated. In this section, we briefly
sketch some structural correctness and consistency criteria that must be satisfied.
Assumptions. While the domain model focus on structuring the data, associations have
behavioral implications. For one, they may define a partial order in which objects must
be created [15]. In the example, every review requires a paper, but a paper may have no
reviews (yet). Consequently, the review cannot be created before the paper. However,
such an order can only be inferred if one object depends on another. Therefore, we
require that all associations are existential: at least one of the corresponding lower
bounds must be positive. Furthermore, we only allow one association between a pair of
classes and disallow many-to-many associations (one of the association’s upper bounds
must be 1). If these assumptions are satisfied, new associations are only established
when new objects are created, e.g., activity “assign reviewer” reads a paper and creates
and associates a review. If the assumptions are violated, the domain model can be reified:
new classes can be introduced in place of the violating associations.
Additionally, we make assumptions about the structure of fragments. We assume that
fragments are acyclic. This does not limit the expressiveness since loops can be resolved
into repeatable fragments. For example, in a purely imperative process model, activity
“submit paper” would be part of a loop instead of a fragment. We furthermore assume
that each fragment is either initial or non-initial. This means they either start with an
event (e.g., fragment f1 in Fig. 4) or with an activity (all fragments but f1)—never both.
Consistent I/O Behavior. Since fCM models consist of data and behavioral parts, most
dependencies apply to the I/O behavior of activities. Correct I/O behavior depends on the
domain model, the object life cycles, other activities, and even the termination condition.
First, all data requirements must be satisfiable. Therefore, some activity must produce
the object configuration (object in a certain state) required by other activities or the termi-
nation condition. This means, each data configuration used in a data object node or a data
condition should be referred by a data object node that takes part in at least one output set.
For example, the object configuration conference[reviewing closed] must
be written by at least one activity, i.e., “close submission”. Assuming the termination
condition would instead be conference[proceedings published] and the
state would be an allowed successor of reviewing closed, the termination condition would
be insatiable since no activity writes the conference object in the respective state.
Furthermore, for each output set of an activity must exist a respective input set so
that the combination conforms to the constraints of the OLCs and the domain model.
A valid input-output-set combination is OLC conform [9]: all the subsumed state
transitions must be present in the OLCs. If an activity “skip submission” changes the
state of conference from scheduled to closed for submission, the OLC would be violated.
This property is called object life cycle conformance.
6 Stephan Haarmann
Next, each object that is created requires a specific context, a set of objects it depends
on. The required context is defined by the existential associations. In the example, the
decision requires a paper and three to five reviews. This context must be provided by
the input-output-combination. The required objects must either be read or co-created.
If activity “assign reviewer” would not read a paper object, the requirements for the
review would be violated. If execute anyway, the created review object would violate the
cardinality constraints specified in the domain model (cf. Fig. 2).
What about the reviews required for a decision? According to the cardinality con-
straints, a decision existentially depends on three to five reviews. In such cases a set of
objects (isSet=true visualized by |||) must be read, e.g., a set of at least three reviews
must be read to create a decision. We call this mandatory batch behavior.
Finally, if a set of objects is read, it must be clearly defined. Therefore, each input set
that contains a data object node with isSet=true must also contain a data object node
with isSet=false for an associated class. The respective object is used to determine
the set of objects that is co-read when executing the respective activity. In the example,
“decide on paper” reads all reviews that belong to the paper. Without the paper, the set
cannot be determined from the context.
The presented criteria are not domain specific, i.e., they do not only apply to the
example fCM model but to all possible fCM models. Any case model that satisfies all
criteria presented in this section is structural consistent. The structure of one part (e.g.,
the fragments) does not contradict the structure of other parts (e.g., the domain model).
4 Related Work
The fragment-based case management [9] approach is a production case management
approach based on [11]. A metamodel for fCM has been proposed in [5]. The metamodel
is close to [9] and includes elements that are fix for all models, such as generic life cycles
for activities. Additionally, extensions have been proposed that consider associations [7]
and cardinality constraints [6, 8]. The metamodel presented in this paper is the first fCM
metamodel considering associations and cardinality constraints.
Besides fCM there are other approaches combining information from process and
data modeling. Combi et al. [2] and Meyer et al. [12] combine data models, i.e., UML
class diagrams, and process models, i.e., BPMN diagrams. [2] describes and detects
inconsistencies while [12] derives SQL-queries for enactment. Montali et al. [13] intro-
duce DB-nets—a Petri net-based formalism for modeling data-base accessing processes
that adhere to data constraints (e.g., primary key, foreign key, and cardinality constraints).
Therefore, they introduce a transaction mechanism to the processes. Ghilardi et al. [4]
present catalog-nets to formally model processes with access to read only data-bases.
While these approaches elaborate the connection between data and process, they are
purely imperative and not suited for knowledge-intensive processes. However, DB-nets
and catalog nets are interesting formalisms, which may be suited to formalize fCM’s
semantics and to define/verify behavioral correctness notions.
Other case management approaches exist. The two most prominent ones are the
Guard Stage Milestone [10] approach and the derived Case Management Model and
Notation [14] standard. Both approaches arrange activities into stages and compose
Fragment-Based Case Management Models 7
behavior based on (data-based) pre- and post conditions. While the approaches assume
a data model (called information model), they do not specify how it is modeled and
integrated into the process specification.
5 Conclusion
Case models capture knowledge-intensive processes, which are often data-driven, multi-
variant, and non-repeatable. Consequently, models become quite complex as they must
integrate data and flexible processes. In this paper, we present a metamodel, consistency
and correctness criteria for fCM models. All fCM models must satisfy these criteria.
Future work may elaborate them. First, formal definitions should be provided, e.g.,
using first-order logic or the object constraint language. Such definitions can be the base
for implementing i) a verification tool that detects violations of the criteria and ii) a
modeling tool that support case designers. Such a tool can highlight violations and offer
auto-completion/correction. For example, when a case designer models an activity that
creates a data object, all required objects (according to the domain model) can be added
to the activity’s input set if they are created by other activities or output sets otherwise.
Structural correctness and consistency is important and verification is computational
in-expensive compared to state space analysis. However, such criteria cannot guarantee
correct behavior. In future work, we want to investigate behavioral correctness criteria
that apply to case models. A first example is weak termination: in the initial state, it
should be possible to reach a state that satisfies the termination condition.
Furthermore, fCM does not capture all aspects of a case. Knowledge-intensive pro-
cesses are also about knowledge workers, their rights, capabilities, and collaborations
among them [3]. In the future, the fCM metamodel and language may be extended to ac-
count for the user perspective. The correctness and consistency criteria may subsequently
be refined to consider the additional information.
Nevertheless, we believe that the presented metamodel and criteria can lead to tool
support for fCM that may ultimately improve the accessibility of the fCM approach.
References
1. van der Aalst, W.M.P., Weske, M., Grünbauer, D.: Case handling: a new paradigm for business
process support. Data Knowl. Eng. 53(2), 129–162 (2005)
2. Combi, C., Oliboni, B., Weske, M., Zerbato, F.: Conceptual modeling of processes and data:
Connecting different perspectives. In: Conceptual Modeling - 37th International Conference, ER
2018, Xi’an, China, October 22-25, 2018, Proceedings. pp. 236–250 (2018)
3. Di Ciccio, C., Marrella, A., Russo, A.: Knowledge-intensive processes: Characteristics,
requirements and analysis of contemporary approaches. J. Data Semant. 4(1), 29–57 (2015)
4. Ghilardi, S., Gianola, A., Montali, M., Rivkin, A.: Petri nets with parameterised data - modelling
and verification. In: Business Process Management - 18th International Conference, BPM 2020,
Seville, Spain, September 13-18, 2020, Proceedings. pp. 55–74 (2020)
5. Gonzalez-Lopez, F., Pufahl, L.: A landscape for case models. In: Enterprise, Business-Process
and Information Systems Modeling - 20th International Conference, BPMDS 2019, 24th
International Conference, EMMSAD 2019, Held at CAiSE 2019, Rome, Italy, June 3-4, 2019,
Proceedings. pp. 87–102 (2019)
8 Stephan Haarmann
6. Haarmann, S., Montali, M., Weske, M.: Technical report: Refining case models using cardinality
constraints. CoRR abs/2012.02245 (2020), https://arxiv.org/abs/2012.02245
7. Haarmann, S., Weske, M.: Correlating data objects in fragment-based case management. In:
Business Information Systems - 23rd International Conference, BIS 2020, Colorado Springs, CO,
USA, June 8-10, 2020, Proceedings. pp. 197–209 (2020)
8. Haarmann, S., Weske, M.: Data object cardinalities in flexible business processes. In: Business
Process Management Workshops - BPM 2020 International Workshops, Seville, Spain, September
13-18, 2020, Revised Selected Papers. pp. 380–391 (2020)
9. Hewelt, M., Weske, M.: A hybrid approach for flexible case modeling and execution. In:
Business Process Management Forum - BPM Forum 2016, Rio de Janeiro, Brazil, September
18-22, 2016, Proceedings. pp. 38–54 (2016)
10. Hull, R., Damaggio, E., Fournier, F., Gupta, M., Heath III, F.F.T., Hobson, S., Linehan, M.H.,
Maradugu, S., Nigam, A., Sukaviriya, P., Vaculín, R.: Introducing the guard-stage-milestone
approach for specifying business entity lifecycles. In: Web Services and Formal Methods - 7th
International Workshop, WS-FM 2010, Hoboken, NJ, USA, September 16-17, 2010. Revised
Selected Papers. pp. 1–24 (2010)
11. Meyer, A., Herzberg, N., Puhlmann, F., Weske, M.: Implementation framework for production
case management: Modeling and execution. In: 18th IEEE International Enterprise Distributed
Object Computing Conference, EDOC 2014, Ulm, Germany, September 1-5, 2014. pp. 190–199
(2014)
12. Meyer, A., Pufahl, L., Fahland, D., Weske, M.: Modeling and enacting complex data dependencies
in business processes. In: Business Process Management - 11th International Conference, BPM
2013, Beijing, China, August 26-30, 2013. Proceedings. pp. 171–186 (2013)
13. Montali, M., Rivkin, A.: From DB-nets to coloured Petri nets with priorities. In: Application and
Theory of Petri Nets and Concurrency - 40th International Conference, PETRI NETS 2019,
Aachen, Germany, June 23-28, 2019, Proceedings. pp. 449–469 (2019)
14. (OMG), O.M.G.: Case management model and notation (CMMN) (December 2016), https:
//www.omg.org/spec/CMMN
15. Snoeck, M.: Enterprise Information Systems Engineering - The MERODE Approach. The
Enterprise Engineering Series, Springer (2014)
16. Swenson, K.D.: Position: BPMN is incompatible with ACM. In: Business Process Management
Workshops - BPM 2012 International Workshops, Tallinn, Estonia, September 3, 2012. Revised
Papers. pp. 55–58 (2012)
17. Swenson, K.D.: State of the art in case management - 2013 (2012), https://www.aiim.
org/PDFDocuments/CaseManagement2013.pdf
All links were last followed on January 18, 2021.