This demo introduces Declare MoGeS, an automated approach for generating and specializing Declare process models that can be employed as input for log generation. The specialization of Declare models is particularly interesting to produce event logs that encompass a subset of the behavior of other logs. Declare MoGeS seamlessly integrates with existing log generators, streamlining the log generation process.
specialization primarily involves adding constraints to an initial model, resulting in limited
variations of process models. To address this limitation, the second objective of the demo is to
propose an automated approach to generate specializations by adapting constraints from an
initial model, thereby enabling controlled variations [
Given that the demo has to be able to (1) generate artificial declarative process models and (2) specialize declarative process models that can serve as input to generate event logs, the developed declare Model Generator and Specializer (Declare MoGeS) adheres to the following requirements.
• Declarative Modeling Language – describe business processes in a flexible declarative language (declare). • Consistency – the generated and specialized models only consist of non-contradictory constraints. • Specialization of Process Models – enable refinement and tailoring of model behavior. • Balance Between Randomness and User Control – allow for variations of process models, and, at the same time, enough control over the generated models. • Compatibility Output Models with Existing Log Generators – The output model is a declare model saved in a file format 1 suitable as input for existing log generators.
_), a set of declare templates that can be selected to generate a model (_), and the probability that a particular declare template is chosen (_) serve as inputs for model generation.
eventually form the created model. Next, a declare constraint is selected by randomly choosing a template from _, taking into account the _. Afterward, activities from an alphabet of size ℎ_ are chosen to obtain a _.
tions. First, the _ must be consistent with the constraints already present in the model, i.e., their conjunction must be satisfiable . We refer to the existing set of constraints as the temporary model. For instance, consider a temporary model consisting of the constraints
Input : Size of the alphabet of : ℎ_
Initialize: = [] ← 0 ← 0 while < _ do _ = random(_, _, ) if _ is consistent w.r.t. and _ is not redundant w.r.t. then ← ∪ _ ← + 1 ← 0 else ← + 1 if > then print No model found with the given parameters return return
[Response(a,b), ChainResponse(b,c)]. The constraint ChainResponse(b,d) would be inconsistent because it contradicts ChainResponse(b,c). Second, the new constraint should not be redundant.
implies Response(b,d) (i.e. if b occurs, then d should occur eventually after b). In this case, adding Response to the model when a ChainResponse is already included is redundant.
the Linear Temporal Logic over finite traces (LTLf) encoding of the declare constraints. If both conditions are met, the _ is added to the model, or discarded otherwise.
process continues until the _ is met (model is returned) or until times in a row, a _ cannot be added to the model (a message is shown to the user and the model () is returned).
model, the user provides an initial model consisting of constraints that need to be specialized (). Optionally, the user can input a set of constraints from the initial model that should be kept in the specialized model (). Furthermore, a specialization percentage (_) that defines the probability a constraint will be specialized is set. Input : Initial declare model:
Specialization percentage: _
Output: A specialization of for each _ in do if _ can be specialized then if () < _ then Generate if ̸∈ then
← ∪ else ←
∪ _ else if _ ̸∈ then
← ∪ _ return
The process of specialization (algorithm 2) starts with an _ from . If _ can be specialized, then a specialization is added to the in some cases. The _ is taken into account to determine whether a specialization should be added or not. Otherwise, the _ is added to the . This process ends when all constraints from the initial model are considered. The specialized model is a specialization of the initial model .
Declare MoGeS is implemented in Python and stored in a GitHub repository2. Additionally, a comprehensive video tutorial demonstrating the tool’s usage can be found within the same repository, providing users with an informative resource for getting started with Declare MoGeS.
In computational tests, we tested the Declare MoGeS by conducting a total of 2392 runs, each aimed at artificially generating and automatically specializing each of the generated declare process models at four distinct percentages (30%, 50%, 70%, and 100%). Approximately 75% of the runs resulted in the generation of models containing between 5 to 25 constraints, all achieved within an 11-minute time frame. Furthermore, it’s worth noting that models with fewer than 16 constraints were generated almost instantly, with a median time of less than a second. However,
for models comprising more than 35 constraints, the execution time could exceed an hour. This prolonged execution was primarily attributed to the computationally intensive consistency and non-redundancy checks performed by BLACK.
process models to facilitate log generation. The efectiveness of the approach is demonstrated and evaluated, highlighting its ability to swiftly generate and specialize declare models containing
rating a data-aware aspect. After integration, studies can evaluate data-aware process discovery algorithms using logs generated from data-aware input models. Additionally, it is interesting to extend the study beyond the predefined templates ofered by the declare language. Future research will delve into exploring LTL formulas that surpass the existing templates.
granted to support this research. Nicola Gigante acknowledges the support of the PURPLE project, 1st Open Call for Innovators of the AIPlan4EU H2020 project, a project funded by EU