The availability of event logs with speci c characteristics is nowadays one of the challenges of the process mining eld in order to be able to validate and evaluate the proposed techniques. Although some e ort has been done towards the generation of synthetic logs from imperative models, the generation of event logs starting from declarative models is still a very young research stream. Few works have focused on the generation of event logs taking into account the control ow perspective or focusing on a particular data attribute as the resources carrying out the activities. However, none of them, so far, has dealt with the generation of event logs from declarative models providing full support for data attributes. MP-Declare Log Generator is a tool for the generation of event logs starting from Multi-Perspective Declare models, a language for expressing declarative constraints on both control ow and data. The implementation of the tool is based on the Alloy model checker and is provided as a standalone desktop application.
The growth of the techniques in the process mining eld and, in particular, of a number of more and more accurate and e cient discovery algorithms has led to an increasing need to evaluate and compare them, thus demanding for event logs (and corresponding gold-standard models) able to demonstrate their correctness and scalability. Although some real-life logs are publicly available, their number is still quite limited. Most companies, indeed, are not willing to share their own event logs, e.g., due to privacy issues or because they depend on third parties. Moreover, real-life logs are not always the best choice for evaluating process mining approaches, as they do not o er control over di erent parameters such as the log size, the length of the traces or the amount of noise. Having control over these characteristics is of the utmost importance to be able to evaluate a process mining algorithm in a complete and predictable way, e.g., in order to be able to understand how much robust is the mining algorithm with respect to the noise or scalable with respect to the log size.
Most of the modeling languages and tools for process mining mainly focus on the control ow perspective of a process. However, in real life, activities (and execution traces) may contain data, as for example who is executing the activity, what type of resources was used or what amount was paid (e.g., in a selling process). This makes evaluating process mining algorithms using real-life logs even harder, because the amount and type of data cannot be changed, and hence di erent aspects of the algorithm cannot be evaluated separately.
While some work on the generation of event logs starting from imperative
models has been recently carried out [
The generation of logs from declarative process models is not an easy task, and it becomes even harder when providing data support. It indeed poses two interesting challenges. First, since there are no well-de ned execution paths like in imperative models, di erent constraints might in uence and contradict each other, and some models do not even have valid nite traces. In these scenarios, it might be really hard to nd traces for some models due to the combinatorics of the problem, so it is important for the log generator to work e ciently. Second, when generating a log, it is preferable to get diverse traces rather than similar ones so that the log contains more useful information about possible process execution patterns. MP-Declare Log Generator aims at facing both these challenges by e ciently generating event logs in a reasonable amount of time and guaranteeing a high heterogeneity of the generated traces. 2
In this section, we illustrate MP-Declare, a Multi-Perspective version of Declare
introduced in [
The rst concept we use here is the one of payload of an event. Consider, for example, that the execution of an activity BookAccomodation (B) is recorded in an event log and, after the execution of B at timestamp B, the attribute HotelN ame and P rice have values P aradise and 90. In this case, we say that, when B occurs, two special relations are valid event(B) and pB(P aradise; 90). In the following, we identify event(B) with the event itself B and we call (P aradise; 90) the payload of B.
The standard semantics of Declare is extended by requiring two additional conditions on data, i.e., the activation condition 'a and the correlation condition 'c. As an example, we consider the response constraint \activity BookAccomodation is always eventually followed by activity CollectTickets" having BookAccomodation as activation and CollectTickets as target. The activation condition is a relation over the attributes of the payload of the activation that must be valid when the activation occurs. If the activation condition does not hold, the constraint is not activated. The activation condition has the form pA(x) ^ ra(x), meaning that when A occurs with payload x, the relation ra over x must hold. For example, we can say that whenever BookAccomodation occurs, and the price is lower than 50 euros, eventually the tickets are collected. In case BookAccomodation occurs but the amount is higher than 50 euros, the constraint is not activated. The correlation condition is a relation that must be valid when the target occurs. It has the form pB(y) ^ rc(x; y), where rc is a relation over the payloads of both A and B. For example, we can say that whenever BookAccomodation occurs for a certain application ID, eventually BookTrasport must follow for the same application ID. 3
Synthetic log generators are essential for di erent types of tasks. They allow the
evaluation of the correctness and scalability of process mining algorithms [
MP-Declare Log Generator aims at lling this gap by leveraging the Alloy
model checker [
In the rst step, the MP-Declare model is parsed and separate statements for
activities, data, bindings of data to activities and constraints are collected. In
the second step - the preprocessing step - since Alloy does not support numeric
variables, intervals for numeric values are generated according to the constraints.
In the third step, the Alloy code corresponding to the MP-Declare model is
generated. After this, the Alloy analyzer is run. The analyzer generates the
CNF (conjunctive normal form) for the model, which is then solved using a SAT
(boolean satis ability problem) solver [
Although the tool is still at an initial stage of development and can be improved with further features, it already o ers to users (and to the BPM community) a very useful instrument for the generation of synthetic logs. In particular, MP-Declare Log Generator has revealed to be mature enough to face the e ciency and the heterogeneity challenges characterizing this type of tools (see Section 1). Indeed, empirical results have shown that MP-Declare Log Generator is able to deal with logs of 1000 traces with an execution time of the order of seconds and that the diversity of the generated logs is comparable with the diversity of real-life logs.