=Paper=
{{Paper
|id=Vol-2952/paper_293a
|storemode=property
|title=Human Behavior as a Process Model:
Which Language to Use?
|pdfUrl=https://ceur-ws.org/Vol-2952/paper_293a.pdf
|volume=Vol-2952
|authors=Gemma Di Federico,Andrea Burattin,Marco Montali
|dblpUrl=https://dblp.org/rec/conf/bpm/FedericoBM21
}}
==Human Behavior as a Process Model:
Which Language to Use?==
https://ceur-ws.org/Vol-2952/paper_293a.pdf
Human Behavior as a Process Model:
Which Language to Use?⋆
Gemma Di Federico1 , Andrea Burattin1 , and Marco Montali2
1
Technical University of Denmark, Kgs. Lyngby, Denmark
gdfe@dtu.dk
2
Free University of Bozen-Bolzano, Bolzano, Italy
Abstract. Repetitive human behavior could be represented in the form
of a process. Existing process modeling notations, however, are not able
to handle all the features of these processes. We identify a set of key
properties that a process modeling language needs to fulfill to capture
human behavior.
1 Representing Human Behavior as a Process
Let’s define human behavior (HB) as a combination of intentions, thoughts, per-
ceptions and states. The execution of a human behavior, and its purpose, is
influenced by all of these factors. Human beings usually perform activities fol-
lowing some structures or patterns. Whenever we deal with the organization
of activities in structures that are performed repetitively, we can leverage the
notion of process [5]. This regularity, hence, can be exploited to study human
behavior using Business Process Management techniques. The problem arises
when trying to model a human-related process with current process modeling
languages: unlike a business process, human behavior is more dynamic and less
structured. The behavior is not fixed, but its execution varies and adapts over
time, based on feedback, preferences and other contextual factors [1].
The importance of modeling human behavior is recognized in many different
fields, including the healthcare sector [9]. Let’s consider, as an example, elderly
people affected with Dementia: they tend to have a very repetitive behavior.
Changes in such a behavior could represent a symptom of the worsening of their
disease [8]. Therefore a model representing their daily practices, in combination
with data referring to the activities being performed, could be used to identify
deviations in behavior.
The ability to automatically capture, process and analyze human behaviors
represents a valuable opportunity to monitor human-related processes. How the
human beings behave can be observed from the viewpoint of the daily routine, in-
tending their behavior as the execution of activities. Routines consist of frequent
behaviors, composed by actions, carried out in situations that are the cause of
⋆
Copyright © 2021 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
2 G. Di Federico, et al.
Modeling of human behavior
𝑅1 𝑅2 𝑅3 𝑅1 𝑅4 𝑅1 𝑅2
(as a sequence of routine)
Modeling of an individual routine
(as a sequence of activities) A B D C
Modeling of activities
(as a sequence of observable units) SCDITUAOJECDTOUIAJOWEFWEFWEFTWTYSDTYJI
Fig. 1. A simplified hierarchical structure of human behavior
those actions. People develop, acquire and adapt their routines through repeated
practice [1]. However, human behavior is flexible and governed by uncertainty,
even if we are able to identify the general underlying process [3].
The first step towards the analysis of human behavior is to represent an
unstructured process in form of a model. Once we have identified the process
modeling language that is able to faithfully represent the process, it will be
possible to automatically derive and analyse these type of processes. The problem
we want to highlight in this paper consists of devising the right process modeling
language. In Sec. 2 we investigate what characterizes human behavior and we
identify the requirements that a process modeling language must fulfill. In Sec. 3
we analyze the requirements with respect to the main features of the existing
languages.
2 Peculiarities of Human Behavior
A process describing human behavior differs from a business process in many
respects. In this section we depict the main characteristics of activities performed
by human beings, deriving a specific characterization of their behavior.
While human behavior is a mixture of intentions, perception, states [10];
routines are intermediate structures of aggregated tangible actions that human
behavior results into (i.e., the actual sequence of activities carried out during a
day). In our investigation, we will focus our attention on routines as a proxy to
human behavior. HB may be interpreted as a sequence of routines. A routine
is composed of a series of activities which, at a lower level of abstraction, are
sequences of observable units. As highlighted in Fig. 1, the structure of HB
is hierarchical. In fact, a routine could be composed of other routines, and an
activity could be composed of other activities.
Human beings establish routines and performs them repetitively [1]. But rou-
tines are not fixed, instead they vary over the time and they heavily depend on
the contingent situations, as an outgrowth of the uncertainty of human behav-
ior [6]. This evolution is caused by the assumption that human beings usually
do not fit into the same routine, so the set of behaviors part of a routine varies.
Variations can be an alternative way to accomplish a task or the introduction
of a new behavior. For example, the breakfast routine changes often, according
to the seasons and our preferences. As a consequence, there may be multiple
Human Behavior as a Process Model: Which Language to Use? 3
variations that describe the same routine. To detect variability in behaviors, we
need to identify what is the reference behavior, so what the invariants are (that
is the goal) [7]. In the example above, we need to identify what is the objective
and which are the variations.
When modeling human processes, psychological and external factors should
also be taken into account, as they result in a close dependence between behavior
and context. The behavior is completely guided by the participant, who decides
how and when to perform certain actions [4], but it is also case-dependent because
the activities are combined based on specific circumstances (or context) [11]. As
a consequence, based on these variables, human beings choose how and which
routine put in place.
A routine is composed by set of activities. Although it is possible to predict
the set of activities that make up a behavior, we cannot define with certainty
their order of execution. Since human beings do not always act in the same way,
even a behavior is not performed following a rigid sequence of activities, resulting
in the variability of behaviors. E.g., the working routine is made up of several
activities, and part of them do not have a rigid and specific execution order.
Additionally, human beings usually repeat certain activities several times
throughout the day and, whenever a behavior is executed, it may be part of
a different circumstance. For example the behavior of “preparing a meal” is
executed several times during the day, but the meaning varies according to the
circumstances. In fact, it can be (a) the preparation of a pasta dish (i) for lunch
or (b) the preparation of a meat dish (ii) for dinner. At a high level of abstraction
they all refer to the behavior of preparing a meal but, when observed within a
process, they have different meanings.
Human beings can also perform multiple actions at the same time: concur-
rency typically takes the form of mixing activities in a period of time. E.g., you
can talk on the phone while walking or watch a movie while eating supper.
Uncertainty, evolution, dependencies, variability, repetition and concurrency
are all aspects that the process model should be able to represent. A process
model that is not capable of capturing all these components is deemed not to
have enough representative power to capture human behavior. As a consequence,
we would not be able to identify patterns and relations in a routine.
Starting from the description presented above, we have devised a list of char-
acteristics that a process modeling language needs to possess.
A. HB can be formalized as a set of sequences of observable units (that are
activities), with corresponding likelihoods, which are affected by the context.
B. HB is intrinsically hierarchical. As depicted in Fig. 1, HB could be seen as a
set of routines, that are in turn hierarchically structured. I.e., sequences of
HB are grouped into routines; a routine is composed by set of activities (or
other routines). For example, the daily routine includes the morning and the
working routine. Each of them is, in turn, made up of a set of behaviors.
C. HB can be instantiated, giving value to all the measures of a context: ex-
ecutions of a behavior are bound to other contextual parameters. E.g., the
“sleeping” activity could be a nap or the deep night sleep, depending on
4 G. Di Federico, et al.
time and place. According to these parameters, the behavior is part of one
routine rather than another.
D. Different instances of the same behavior could be observed in a sequence.
E.g., the “preparing a meal” activity is performed several times during a
day, thus it is repeatedly observed during the daily routine sequence. Each
instance could belong to distinct routines, implying different other behaviors.
E. Instances of different HB could be observed over the same time period. Hu-
man beings could perform activities simultaneously or intertwine the exe-
cution of different behaviors with each other. E.g., watch television while
ironing.
F. Different instances of the same HB could result in different sequences of ob-
servable units (within the same set). The sequence of activities that compose
a behavior do not necessarily have a rigid execution order. E.g., the behavior
of “doing the laundry” is made up of various activities which do not have a
precise order: put in clothes/ the detergent/ the softener/ the color catcher.
G. As mentioned above, HB comprises sequences of observable units and their
likelihood. These could change over time based on the context.
H. The context where HB happens can be formalized as a set of measures (di-
rect or computed value, internal or external to the process instance) that
characterize an instance. E.g., if it is snowy, it is more likely that a person
goes often to the window. According to this weather condition, the behaviour
is affected.
I. HB does not have a fixed start and a fixed end. It is not always possible to
define exactly the initial and final actions of a given behavior.This is mainly
the case when there is a process that is characterized by a high variability,
such as the activity of preparing a meal. In this case the process can be
initiated from different points, in fact there is no specific action that defines
the beginning, or the end of it.
There are also two additional, and more specific, requirements. Firstly, the model
must have an unambiguous semantic in order to allow establishing direct links
between the observed execution of the model and the observed execution of ac-
tivities (e.g., to calculate the conformity [2] w.r.t. activities). Secondly, the model
must be understandable and should clearly express its structure and relations,
in order to allow to know how the process is carried out.
In the following section, we will identify the main properties of the existing
process modeling languages, and we will associate each of them to our list of
requirements for modeling HB. By doing so, we are able to identify which class
of modeling languages best reflects our needs.
3 Process Modeling Language Requirements
Starting from the characterization presented in the previous section, we have
identified the requirements that a process modeling language needs to fulfill in
order to prove itself as a suitable candidate to model human behavior. A process
model representing human behavior must reflect the dynamic nature of these
Human Behavior as a Process Model: Which Language to Use? 5
behaviors, the flexibility and variations, such as the evolution. There are plenty
of process modeling languages, and we need to identify the one that is able to
express the aspects listed above to the largest extent. In the remainder of the
section we list the requirements expected by process modeling languages:
– The language must be able to handle true concurrency: human beings can
perform multiple activities at the same time.
– The language must support hierarchies as HB is also hierarchical.
– The language must represent at least the basic control flow patterns [12] to
properly capture the activities in HB.
– The language must allow for the definition of data flow conditions, as well as
include the provisioning of external data: HB is influenced by the context,
which can be a direct or computed value, internal or external to the process.
Therefore the model must handle this data.
– The language must allow a certain level of flexibility in the execution flow,
as HB is not strictly enforced. Moreover, a stochastic language is preferred,
in order to support the evolution and the variation of the process.
– The language should be both a continuous or a discrete system. HB is subject
to change and, as such, the set of sequences of observable units could change
too, both in terms of structure (the sequence itself) and likelihood, at specific
points in time or continuously.
– The language must be able to represent processes that are not end-to-end.
A set of sequences, part of a behavior, does not have a clear start and end
activities.
– The language must have a formal operational semantic to describe how the
process is interpreted, since the objective is to understand in detail the mean-
ing of the process.
– In addition to the previous point, the language must represent white box
models to explain the behaviors of a routine and to identify the variables
that influence the behavior.
This list of process modeling languages properties could be used to select the
language that best reflects the requirements of a human behavior process3 .
4 Future Work to Tackle the Problem
When considering the requirements that a modeling language must support, in
order to model HB, a very important aspect to consider is the context. In fact
the model adapts itself according to specific conditions detected at that moment.
The process modeling language, therefore, should include conditions on data as
well as the provisioning of external data. Moreover, HB can be interpreted as
a sequence of routines that can be nested. In fact, a routine is composed by a
sequence of activities, that in turn could be other routines. That is, the behav-
ior is hierarchical. On the contrary, starting from low-level activities (namely
3
An initial comparison of the languages is reported in https://doi.org/10.11583/
DTU.14745693.
6 G. Di Federico, et al.
observable units), as the level of abstraction increases, the concept of behavior
emerges in a broader sense. Hence, the model must represent behaviors in a hi-
erarchical way. The set of activities that compose a behavior could change over
the time, therefore the model must handle variations and respond to evolution:
the process model changes over the time. Another tricky aspect is the stochas-
ticity of HB. Two considerations must be made: the model cannot limit human
behavior, and the model cannot allow for all the behaviors. It is not possible
to predict the exact behaviors, as they are guided by a certain degree of flex-
ibility and uncertainty. Consequently, we cannot limit the model by defining a
rigid sequence of activities, but we cannot even admit the execution of all the
behaviors, as the concept of process would be lost. However, we can assert that
all behaviors can be performed, but some are more likely than others. This also
supports the evolution of behaviors described above, letting the possibility to
admit behaviors during the execution of the process. The limit, however, is that
the possibility of representing all possible behaviors would increase the difficulty
of identifying the real process, excluding anomalies and outliers. The stochastic
aspect is also questioned by the concurrency and the fuzziness of human be-
havior. In fact, several activities could be performed simultaneously but we are
unable to completely include or exclude one of them, or distribute the probabil-
ity of execution among them, but it can be considered as a fuzzy behavior. One
final note concerns the fact that that the process is not end to end. Therefore,
it does not have a well-defined start and end, but can be instantiated from any
point. The language must be able to handle this cyclic nature of the process.
Given the identified list of requisites, it is now necessary to proceed towards
a thorough evaluation of the process modeling languages. One of the existing
language, or the combination of several of them, may be the most appropriate
way to represent processes related to human behavior.
References
1. Banovic, N., Buzali, T., Chevalier, F., Mankoff, J., Dey, A.K.: Modeling and un-
derstanding human routine behavior. In: Proc. of CHI. pp. 248–260 (2016)
2. Carmona, J., van Dongen, B., Solti, A., Weidlich, M.: Conformance checking: Re-
lating Processes and Model. Springer (2018)
3. da Cunha Mattos, T., Santoro, F., Revoredo, K., Nunes, V.T.: A formal represen-
tation for context-aware business processes. Comput. Ind. 65(8) (2014)
4. Di Ciccio, C., Marrella, A., Russo, A.: Knowledge-intensive processes: characteris-
tics, requirements and analysis of contemporary approaches. J. Data Semant. 4(1)
(2015)
5. Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A.: Fundamentals of business
process management. Springer (2013)
6. Feldman, M.S., Pentland, B.T.: Reconceptualizing organizational routines as a
source of flexibility and change. Adm. Sci. Q. 48(1), 94–118 (2003)
7. Guizzardi, R., Reis, A.N.N.: A method to align goals and business processes. In:
International Conference on Conceptual Modeling. pp. 79–93. Springer (2015)
8. Kales, H.C., Gitlin, L.N., Lyketsos, C.G.: Assessment and management of behav-
ioral and psychological symptoms of dementia. BMJ 350 (2015)
Human Behavior as a Process Model: Which Language to Use? 7
9. Lull, J., Bayo, J., Shirali, M., Ghassemian, M., Fernandez-L., C.: Interactive Pro-
cess Mining in IoT and Human Behaviour Modelling, pp. 217–231. Springer (2021)
10. Sanchez-Calzon, A.B., Fernandez-L., C., Pileggi, F., Meneu, T.: Impact of semantic
technologies to human behavior modeling: A psychosocial rationalization. In: Proc.
of ICAART. pp. 547–552 (2012)
11. Stefanini, A., Aloini, D., Benevento, E., Dulmin, R., Mininno, V.: A process mining
methodology for modeling unstructured processes. Knowl. Process. Manag. 27(4),
294–310 (2020)
12. Van der Aalst, W.M., Ter Hofstede, A.H., Kiepuszewski, B., Barros, A.P.: Workflow
patterns. Distrib. Parallel Databases 14(1), 5–51 (2003)