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. Let's define human behavior (HB) as a combination of intentions, thoughts, perceptions and states. The execution of a human behavior, and its purpose, is influenced by all of these factors. Human beings usually perform activities following 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 diferent ifelds, including the healthcare sector [9]. Let's consider, as an example, elderly people afected 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, intending their behavior as the execution of activities. Routines consist of frequent behaviors, composed by actions, carried out in situations that are the cause of
Modeling of human behavior (as a sequence of routine)
1 Modeling of an individual routine (as a sequence of activities)
Modeling of activities (as a sequence of observable units) 2
A 3 1 4 1
2 B
D
C
SCDITUAOJECDTOUIAJOWEFWEFWEFTWTYSDTYJI
those actions. People develop, acquire and adapt their routines through repeated
practice [
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
A process describing human behavior difers 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 [
Human beings establish routines and performs them repetitively [
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 [
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 specicfi 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 diferent 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 diferent meanings.
Human beings can also perform multiple actions at the same time: concurrency 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 characteristics 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 afected 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: executions 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 time and place. According to these parameters, the behavior is part of one routine rather than another.
D. Diferent 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 diferent other behaviors. E. Instances of diferent HB could be observed over the same time period. Human beings could perform activities simultaneously or intertwine the execution of diferent behaviors with each other. E.g., watch television while ironing.
F. Diferent instances of the same HB could result in diferent sequences of observable 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 (direct 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 afected.
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 diferent 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
activities (e.g., to calculate the conformity [
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
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
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 [
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 meaning 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 process 3. 4
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 behavior 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. 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 hierarchical 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 stochasticity 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 flexibility 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 dificulty of identifying the real process, excluding anomalies and outliers. The stochastic aspect is also questioned by the concurrency and the fuzziness of human behavior. In fact, several activities could be performed simultaneously but we are unable to completely include or exclude one of them, or distribute the probability of execution among them, but it can be considered as a fuzzy behavior. One ifnal 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.