Back to the Model: UML Miner and the Power of Process Mining

Pasquale Ardimento

1 a

, Mario Luca Bernardi

2 b

, Marta Cimitile

3 c

and Michele Scalera

1 d

Department of Informatics, University of Bari Aldo Moro, Via Orabona 4, Bari, Italy

Department of Engineering, University of Sannio, Benevento, Italy

Department of Law and Digital Society, Unitelma Sapienza University, Rome, Italy

Keywords:

UML Class Diagrams, Software Modeling, Process Mining, Conformance Checking, Computing Education.

Abstract:

Comprehension of the Uniﬁed Modeling Language is essential for learners in the context of software modeling.

However, current UML learning tools provide minimal guidance to novice modelers as they are insufﬁcient

in analyzing modeling behaviour adopted during the diagram creation process. In order to address this gap,

we present an enhanced version of UML Miner, a plugin for Visual Paradigm, that systematically records

and analyzes UML modeling activities through the use of Process Mining techniques. UML Miner tracks all

modeling events, resulting in event logs that warrant conformance checking against expert modeling practices.

This tool establishes ﬂexible, yet structured learning pathways through Declarative Process Mining, support-

ing trace-based and event-based ﬁltering, customized violation reports, and integration with external process

mining tools. This work emphasizes the potential of process mining in computing education, demonstrating

how conformance checking can strengthen UML modeling proﬁciency.

1 INTRODUCTION

Graphical modeling languages, such as the UML

(Uniﬁed Modeling Language), are essential for de-

veloping, understanding, and communicating various

views of a system. In software engineering and com-

puting education, improving the quality of modeling

practices among students and novice modelers has

been a long-standing challenge. To address this, edu-

cators have increasingly turned to software modeling

principles, tools, and environments, as well as learn-

ing analytics techniques like Process Mining (PM).

These approaches enable the study of individual be-

haviors during software diagram modeling, allowing

educators to provide personalized feedback based on

the practices of more skilled modelers. Despite the

availability of UML tools for educational purposes

(Crahen et al., 2002; Foss et al., 2022; Alhazmi et al.,

2021), most lack a focus on conformance checking,

a process mining technique that compares actual pro-

cess executions (recorded in event logs) against pre-

deﬁned process models representing expected behav-

https://orcid.org/0000-0001-6134-2993

https://orcid.org/0000-0002-3223-7032

https://orcid.org/0000-0003-2403-8313

https://orcid.org/0000-0002-2455-2032

iors. While recent advancements have introduced AI-

powered UML modeling tools, such as ChatUML,

DiagrammingAI, and AI UML Diagram Generator,

these tools primarily aim to facilitate diagram creation

and improve modeling efﬁciency. However, they do

not address the need for feedback on the modeling

process itself, particularly for novice modelers. Al-

though process mining has been applied to analyze

student behaviors in development activities (Ardi-

mento et al., 2019c; Ardimento et al., 2019b; Ardi-

mento et al., 2019a), its application to support novice

UML modelers remains unexplored. To bridge this

gap, we present an enhanced version of UML Miner,

a plugin for the Visual Paradigm (VP) environment.

UML Miner records event logs generated from a mod-

eler’s interactions with VP, enabling the analysis of

their modeling process. By leveraging process dis-

covery and conformance checking, the tool provides

insights into how students approach complex model-

ing tasks and compares their behaviors to those of ex-

perienced modelers. A prototype of UML Miner was

previously introduced at the Models 2023 conference

(Ardimento et al., 2023), and this work extends its

capabilities to offer more comprehensive support for

novice UML modelers. The current version of the tool

introduces several signiﬁcant extensions compared to

the previous version. These enhancements include:

Ardimento, P., Ber nardi, M. L., Cimitile, M. and Scalera, M.

Back to the Model: UML Miner and the Power of Process Mining.

DOI: 10.5220/0013500100003964

In Proceedings of the 20th International Conference on Software Technologies (ICSOFT 2025), pages 207-214

ISBN: 978-989-758-757-3; ISSN: 2184-2833

207

• Capturing Complex Relationships and Behav-

iors. To achieve this, we have enabled the cap-

ture of complex relationships and behaviors in

UML Miner through the use of templates. These

templates deﬁne constraints applied to activities

within the modeling process, providing a struc-

tured approach to representing intricate dependen-

cies. The semantics of these constraints are for-

malized using various logical frameworks, such

as Linear-Time Temporal Logic, allowing precise

reasoning about process behavior over time.

• Enhanced Filtering Capabilities, allowing users

to dynamically ﬁlter modeling events based on

speciﬁc analytical needs that may arise in the con-

text of UML software modeling. The tool en-

ables ﬁltering across multiple dimensions, such

as element type (e.g., classes, associations, at-

tributes), modeling actions (e.g., creation, modi-

ﬁcation, deletion) and temporal aspects (e.g., se-

quence of edits, time spent on speciﬁc elements).

Additionally, it supports both trace-based ﬁltering

(for entire modeling sessions) and event-based ﬁl-

tering (for speciﬁc modeling actions), ensuring a

ﬂexible and targeted approach to analyzing stu-

dents’ modeling behaviors.

The structure of this paper is organized as follows.

Section 2 introduces the modeling language used to

represent the modeling process in the tool. Section 3

describes the core functionalities of the tool, and Sec-

tion 4 presents an example scenario. Section 5 con-

cludes the paper, which provides directions for future

research.

2 BACKGROUND:

DECLARATIVE PROCESS

MINING

PM enables the analysis of event logs generated dur-

ing process execution, allowing insights into behav-

ior and identiﬁcation of inefﬁciencies (van der Aalst,

2016). In our tool, we adopted a declarative modeling

approach, which is particularly suitable for software

modeling, where different strategies may be valid as

long as fundamental constraints are respected.

Unlike imperative models, which specify all pos-

sible execution paths, declarative models deﬁne con-

straints that govern allowed behaviors. We use the

Declare language (Pesic et al., 2007), in which con-

straints are speciﬁed through reusable templates, for-

malized using temporal logics such as LTL. De-

clare supports various constraint types (Alman et al.,

2020b; Alman et al., 2020a), including: Existence:

ensuring an activity occurs at least once, Relation:

expressing dependencies between two activities, Neg-

ative relation: specifying that an activity must not

follow another, Choice: requiring the selection be-

tween alternative activities.

Constraints apply over traces, i.e., sequences of

modeling events. When a constraint is activated, it

imposes an obligation on subsequent events; it is ful-

ﬁlled if respected and violated otherwise. If never

activated, it is vacuously satisﬁed (Kupferman and

Vardi, 2003). We also adopt the notion of semantic

vacuity (Burattin et al., 2012), which ensures a con-

straint is meaningful only when it is both activated

and fulﬁlled at least once.

3 UML MINER

UML Miner establishes a monitored modeling envi-

ronment where all modeling activities are systemati-

cally captured and recorded in event logs. This en-

sures a detailed trace of the steps taken by students

during the creation of class diagrams. It also enables

the discovery of the actual process model adopted by

each student, leveraging Declare Templates to reveal

the sequence and logic of their actions. Furthermore,

a conformance checking technique can be applied to

compare a given process model with the correspond-

ing event log, determining the degree of alignment be-

tween the two.

This environment facilitates both the discovery of

actual process models and their evaluation in terms

of conformance with a reference process, such as the

one derived from the teachers’ solution. Figure 1 il-

lustrates the architecture of UML Miner, highlighting

its core components:

• Log Recorder, which captures modeling activi-

ties;

• Process Discoverer, which reconstructs the pro-

cess model;

• Conformance Checker, which assesses align-

ment with reference models;

• Log Filtering, which reﬁnes event logs for further

analysis.

• Violations Exporter, which generates a cus-

tomized report listing all adopted modeling be-

haviors, indicating for each whether it deviates

from or aligns with a reference model, e.g. the

instructor’s reference model.

As shown in Figure 1, the tool is designed with

maximum ﬂexibility. Process discovery can be per-

formed internally, using a declarative approach, or

ICSOFT 2025 - 20th International Conference on Software Technologies

208

externally by exporting event logs to external pro-

cess mining tools. These logs, formatted in the stan-

dard XES (eXtensible Event Stream) format, are com-

patible with a wide range of process mining tools.

Similarly, conformance checking can also be con-

ducted outside the VP environment, as long as the

event logs conform to the deﬁned schema for record-

ing modeling activities. The ﬂexibility of the sys-

tem comes from its ability to integrate with exter-

nal tools and processes. For example, by exporting

event logs, users can apply any process discovery al-

gorithm or representation language supported by ex-

ternal tools. Additionally, UML Miner supports con-

formance checking internally by generating outputs

in various textual formats, while an extended version

based on the RuM tool (Alman et al., 2021) provides

graphical visualizations of both discovered process

models and conformance checking results.

3.1 Log Recorder

The Log Recorder is a core component of UML

Miner, designed to capture and record all modeling

events performed across UML diagrams within the

VP environment. Performing as a background dae-

mon, it operates continuously and autonomously, en-

suring uninterrupted monitoring of modeling activi-

ties. The Log Recorder initiates automatically upon

VP startup and remains active until VP is terminated,

without interfering with the user’s modeling tasks.

For each VP project, UML Miner generates a unique

event log that comprehensively documents all work-

ing sessions associated with the project. A work-

ing session is deﬁned as the sequence of modeling

events that occur between the opening and closing of

a project. The Log Recorder begins to capture events

immediately upon project creation and stores them in

a dedicated event log ﬁle. If a project is reopened, the

tool appends a new trace to the existing log ﬁle, pre-

serving a complete history of the project’s modeling

activities.

To facilitate structured analysis, the Log Recorder

categorizes modeling events into the following types.

• ProjectEvent: Captures high-level events related

to the VP project, such as creating or deleting dia-

grams, adding or removing UML model elements,

opening or saving the project, and renaming the

project. For example, adding a new UML dia-

gram or removing a class from the project triggers

a ProjectEvent.

• DiagramEvent: Tracks events speciﬁc to individ-

ual UML diagrams, such as adding or removing

UML model elements within a diagram. This en-

sures granular tracking of diagram-level modiﬁca-

tions.

• ModelElementPropertyEvent: Records

changes to the properties of UML model el-

ements, whether at the project or diagram level.

Properties can be atomic (e.g., class visibility)

or composite (e.g., class attributes with prop-

erties like name, visibility, type modiﬁer, and

multiplicity). Atomic properties are intrinsic to

model elements and assume default values if not

explicitly deﬁned, whereas composite properties

are user-deﬁned and include unique identiﬁers

(IDs). For instance, modifying a class attribute

logs both the property and its updated value,

along with metadata speciﬁc to the property type.

• ModelsRelationshipEvent: Documents events

involving relationships between UML model el-

ements, such as associations, aggregations, gener-

alizations, or ”extends” relationships between use

cases. Each relationship event logs speciﬁc prop-

erties, including the relationship ID, the source

model element ID, and the target model element

ID.

• ExtensionMechanismEvent: Captures events re-

lated to UML extension mechanisms, such as

stereotypes and tagged values applied to model el-

ements. Since a single model element may have

multiple stereotypes or tagged values, these are

stored in a vector for efﬁcient retrieval and analy-

sis.

The Log Recorder ensures comprehensive event

tracking, even in scenarios where a UML model ele-

ment is added to a project but not yet included in any

diagrams. However, to maintain focus on meaning-

ful modeling activities, the tool deliberately excludes

stylistic or formatting-related information (e.g., dia-

gram layout or element colors) from the event logs.

This design choice ensures that the logs remain con-

cise and relevant for process mining and conformance

checking tasks.

3.2 Deﬁning UML Event Log Structure

To ensure interoperability and enable external analy-

sis, the modeling event data collected by UML Miner

are serialized according to the IEEE XES standard.

The event log encodes trace-level and event-level in-

formation related to the UML modeling process.

Figure 2 shows the metamodel representing the

structure of UML modeling event logs.

Each Log consists of multiple Trace elements. A

trace corresponds to a modeling session and includes

metadata such as:

Back to the Model: UML Miner and the Power of Process Mining

209

Figure 1: UML Miner architecture.

• concept:name (trace name),

• identity:id (trace/session identiﬁer),

• AuthorName (student or modeler),

• ProjectName,

• CaseTimestamp (timestamp of the session).

Each trace is composed of a sequence of Event

elements, where each event corresponds to a speciﬁc

modeling action performed by the user. For every

event, the log records:

• the name and instance of the activity

(concept:name, concept:instance),

• the timestamp of execution (time:timestamp),

• information about the UML element involved

in the activity, including its ID, type, and

name (UMLElementId, UMLElementType,

UMLElementName),

• information about the diagram context, such as its

ID, type, and name (DiagramId, DiagramType,

DiagramName).

Depending on the type of event, additional at-

tributes may also be present:

• UMLElementChildren, for events involving hier-

archical elements like packages,

• PropertyName and PropertyValue, for events

related to property updates (e.g., renaming an ele-

ment),

• RelationshipFrom, RelationshipTo, and their

IDs, for events involving relationships such as as-

sociations or generalizations.

This structure allows the log to describe the se-

quence, timing, and context of modeling operations

performed in the UML editor. The metamodel also

provides a foundation for trace-based analysis, pro-

cess discovery, and conformance checking. The rep-

resentation is ﬂexible enough to include custom clas-

siﬁers and extensions relevant to UML modeling se-

mantics.

3.3 Process Discoverer

The behavior recorded in an event log serves as the

basis for further analysis. This behavior is then struc-

tured and interpreted by extracting process models

from the event log, a procedure known as process

ICSOFT 2025 - 20th International Conference on Software Technologies

210

Figure 2: Metamodel representing the structure of the UML Event Log.

discovery. The process models discovered for UML

class diagram modeling are represented as a set of

constraints, where each constraint speciﬁes a particu-

lar aspect of the modeling process. These constraints

describe either the cardinality of a modeling activity

(e.g., the number of times a class or attribute is de-

ﬁned in a trace) or the relationships between different

modeling activities (e.g., how the creation of a class

requires or prohibits the deﬁnition of a relationship

with another class).

In the context of class diagram, the modeling

events include activities such as the creation of a class,

the deﬁnition of an operation, the addition of an at-

tribute, or the establishment of a relationship between

classes. For instance, a constraint might specify that

a class must always have at least one attribute, or that

creating an association between two classes must fol-

low the deﬁnition of those classes.

The discovered models can be exported in two for-

mats: the Declare format and a textual format. The

textual format represents the entire model as a set of

natural language sentences, making it accessible to

users who may not have prior knowledge of the De-

clare framework. For example, a textual representa-

tion could state, ”Every class must include at least one

attribute,” or ”If a class deﬁnes an operation, it must

eventually deﬁne at least one attribute.” Conversely,

the Declare format is designed to allow these models

to be utilized in conformance checking tasks within

tools like UML Miner.

Declare uses templates, which are parameterized

temporal logic patterns, to deﬁne constraints. These

templates are equipped with a graphical notation to

facilitate the representation of process maps and can

be expressed in natural language, eliminating the need

for teachers to be familiar with formal logic. Declare

constraints are instantiated templates, where template

parameters are replaced with speciﬁc modeling activ-

ities for class diagram creation.

The following list illustrates some examples of

templates used for class diagram modeling. A com-

plete list and a complete description of these tem-

plates can be found in (Pesic, 2008):

• Unary: Existence templates: These apply con-

ditions to the occurrence of single modeling activ-

ities. For example, EXISTENCE(CreateClass)

ensures that at least one class is created in the pro-

cess.

• Binary: Relation templates: These deﬁne

relationships between pairs of modeling activ-

ities. For instance, RESPONSE(CreateClass,

DefineAttribute) mandates that if a class

is created, at least one attribute must be de-

ﬁned for it at some point later. The binary

templates partition their parameters into an

activation and a target. For example, in

RESPONSE(CreateClass, DefineAttribute),

the activation is CreateClass, while the target is

DefineAttribute.

• Negative templates: These impose restrictions.

For instance, NOTRESPONSE(CreateClass,

DefineOperation) states that creating a class

must not be immediately followed by deﬁning an

operation for that class.

• Choice templates: These specify that it is

necessary to choose between several activi-

ties. For example, CHOICE(CreateClass,

DefineAttribute, DefineMethod) indicates

that after creating a class, the modeler must

choose between deﬁning an attribute or deﬁning

a method for that class, but not both simulta-

neously. The choice enforces ﬂexibility in the

design process, ensuring that only one of these

actions is selected.

By combining textual and graphical representa-

tions, the Declare framework provides a ﬂexible ap-

proach to analyzing the processes involved in class

diagram modeling. The textual format aids in com-

prehending the high-level rules governing the mod-

eling process, while the graphical Declare notation

supports detailed analysis and conformance checking

tasks, such as assessing whether a student’s modeling

process aligns with expected behavioral rules.

Back to the Model: UML Miner and the Power of Process Mining

211

3.4 Conformance Checker

The Conformance Checker in UML Miner is specif-

ically designed to detect and analyze discrepancies

between the class modeling process followed by stu-

dents and the reference process model deﬁned by the

teacher. This capability relies on the implementa-

tion of the Declare Analyzer method (Burattin et al.,

2016), which enables thorough conformance check-

ing. The analysis can be performed at two levels:

trace-level conformance and constraint-level confor-

mance.

The Declare Analyzer requires two key inputs:

• An event log: This log contains all the recorded

modeling activities for a given project, as captured

by UML Miner.

• A process model in Declare language: This model

deﬁnes a set of constraints that describe the ex-

pected behavior of the modeling process.

The conformance checking algorithm iterates

through all traces in the event log. For each trace,

it evaluates each constraint by iterating through all

events within the trace. Speciﬁc template-dependent

operations are then invoked to calculate the number

of violations (deviations from the model) and fulﬁll-

ments (compliances with the model). The Declare

Analyzer identiﬁes both fulﬁlled and violated con-

straints, thereby pinpointing events that adhere to the

model and those that deviate from it.

The conformance-checking results are presented

at three granular levels:

• Per event log: Provides an overall assessment of

how well the entire project aligns with the refer-

ence model.

• Per trace: Offers detailed insights into speciﬁc

sequences of modeling events, identifying the ex-

act deviations and fulﬁllments within individual

sessions.

• Per constraint: Delivers a clear explanation of

how each deﬁned constraint has been upheld or

violated, ensuring high explainability for individ-

ual process rules.

Figure 3 displays a segment of a conformance-

checking report for student 1. The report lists con-

straint violations and fulﬁllments against the refer-

ence model, offering detailed insights into the trace,

constraint, activities, and related properties. Below is

an excerpt from the report:

Each row in the report corresponds to an evalua-

tion result, providing the following key information:

• Trace ID: Unique identiﬁer of the modeling ses-

sion.

Figure 3: Excerpt from a conformance checking report for

the creation of a class diagram.

• Constraint Name: Name of the MP-Declare con-

straint being checked.

• Activity Details: The speciﬁc activity or sequence

of activities evaluated.

• Result Type: Indicates whether the activity ful-

ﬁlled or violated the constraint.

• Diagram and Element Details: Information on the

UML diagram and elements associated with the

activity, such as diagram type, element name, and

element type.

• Property Changes: Details of any property modi-

ﬁcations, including property name and new value.

Using these detailed conformance-checking re-

sults, UML Miner provides actionable insights into

the alignment of the modeling process with prede-

ﬁned constraints, facilitating the identiﬁcation and

resolution of inconsistencies.

3.5 Log Filtering

This component offers several types of basic ﬁl-

ters, organized into ﬁve categories: attributes, perfor-

mance, endpoints, followers, and timeframes. This

functionality allows users to apply a combination of

trace-based ﬁlters (which ﬁlter entire sequences of ac-

tivities) and event-based ﬁlters (which target speciﬁc

events within traces). In the context of UML model-

ing, this feature has been speciﬁcally adapted for class

diagrams, enabling ﬁltering based on parameters such

as Diagram ID, Diagram Type, Diagram Name, UML

Element ID, UML Element Type, and UML Element

Name. This feature is particularly useful for teach-

ers, as it enables them to focus on speciﬁc concepts

or constructs explained during lectures. For example,

it can isolate activities related to key class diagram

ICSOFT 2025 - 20th International Conference on Software Technologies

212

components or concepts discussed in class. Addition-

ally, it allows the removal of irrelevant information

from the logs, retaining only the data deemed essen-

tial for a particular analysis. Instructors can also use

it to focus on speciﬁc sessions, such as the ﬁrst or

the last modeling session. Events can be ﬁltered by

timestamp, type, and element to focus analysis.

4 EXAMPLE SCENARIO

To illustrate the use of UML Miner, consider the fol-

lowing modeling task assigned in an Object-Oriented

Programming course: Design a class diagram for a

library management system. The task includes core

entities such as Book, Author, Member, and Loan,

with structural constraints such as one-to-many as-

sociations (for example, an author can write multi-

ple books) and attribute requirements (e.g., each Book

must have a Title and an ISBN).

Step 1: Recording the Modeling Behavior

As students begin modeling the diagram in the VP

environment, every modeling action is automatically

captured by the Log Recorder. For example:

• CreateClass: Book

• CreateClass: Author

• AddAssociation: Book ↔ Author

• SetAttribute: Book.title

These activities are collected as event logs and

grouped into traces, one for each modeling session.

Step 2: Structuring the Log

Each event is encoded in compliance with the XES

standard, including:

• Trace attributes: session ID, project ID, student

ID, and timestamp.

• Event attributes: activity name, element type

and ID, diagram context, and any modiﬁed prop-

erties.

This standardized structure ensures that modeling ses-

sions are portable and analyzable across multiple Pro-

cess Mining tools.

Step 3: Discovering the Actual Process

The collected logs are analyzed by the Process Dis-

coverer, which reconstructs the actual modeling pro-

cess followed by the student using Declare templates.

For example, the system might detect the following

behavioral constraints:

• EXISTENCE(CreateClass: Book)

• RESPONSE(CreateClass: Author,

AddAssociation: Book ↔ Author)

• NOTRESPONSE(AddAssociation,

SetNavigability)

These constraints describe how actions relate to one

another, exposing students’ modeling strategies be-

yond the ﬁnal diagram alone.

Step 4: Comparing with the Reference

Process

The instructor provides a reference process model

derived from expert solutions. The Conformance

Checker then compares each student trace against

the reference model and identiﬁes violations. For in-

stance, the following deviation was found:

[Class Book created], [Class Author cre-

ated], [Association added between Book and

Author], [Navigability property not set]

This violation highlights a missing activity in the

expected modeling ﬂow. Although the ﬁnal diagram

includes the association, the omission of the naviga-

bility deﬁnition reveals a gap in the student’s model-

ing practice.

Step 5: Filtering for Focused Feedback

(Log Filtering)

To support targeted feedback, instructors can use the

Log Filtering functionality to isolate traces involving

speciﬁc modeling concepts or behaviors, such as:

• All traces involving aggregation relationships.

• Traces where attributes were created or

deleted.

• The ﬁrst modeling session only.

This enables educators to analyze only relevant data

and to tailor feedback based on speciﬁc constructs

discussed in class.

This process-oriented example demonstrates how

UML Miner captures and analyzes modeling behav-

ior in depth. By making explicit connections be-

tween modeling actions and expected practices, the

tool enhances instructional support and promotes re-

ﬂective learning in UML modeling tasks. Additional

resources, including software, example assignments,

and guidelines for creating consistent class diagram

tasks, are available at https://sites.google.com/view/

uml-miner/.

Back to the Model: UML Miner and the Power of Process Mining

213

5 CONCLUSIONS AND FUTURE

WORK

This work extends our effort to provide tailored feed-

back for identifying gaps in students’ modeling prac-

tices. The proposed tool detects sequences of activi-

ties in UML class diagram design that reveal incorrect

use of inheritance, enabling educators to deliver tar-

geted support, such as focused tutorials. Moreover,

it supports real-time assessment, facilitating timely

interventions during the modeling process. Future

work includes validating the approach across differ-

ent UML diagrams and improving RAG-LLM func-

tionalities to provide natural language feedback. In-

tegrating real-time feedback will also enable students

to self-correct, promoting active learning. Longitu-

dinal studies may help assess the long-term impact

of these interventions on modeling skill development

and teaching strategies.

REFERENCES

Alhazmi, S., Thevathayan, C., and Hamilton, M. (2021).

Learning UML sequence diagrams with a new con-

structivist pedagogical tool: SD4ED. In Sherriff, M.,

Merkle, L. D., Cutter, P. A., Monge, A. E., and Sheard,

J., editors, SIGCSE ’21: The 52nd ACM Techni-

cal Symposium on Computer Science Education, Vir-

tual Event, USA, March 13-20, 2021, pages 893–899.

ACM.

Alman, A., Ciccio, C. D., Haas, D., Maggi, F. M., and

Mendling, J. (2020a). Rule mining in action: The rum

toolkit. In Ciccio, C. D., Depaire, B., Weerdt, J. D.,

Francescomarino, C. D., and Munoz-Gama, J., edi-

tors, Proceedings of the ICPM Doctoral Consortium

and Tool Demonstration Track 2020 co-located with

the 2nd International Conference on Process Mining

(ICPM 2020), Padua, Italy, October 4-9, 2020, vol-

ume 2703 of CEUR Workshop Proceedings, pages 51–

54. CEUR-WS.org.

Alman, A., Di Ciccio, C., Haas, D., Maggi, F. M., and

Nolte, A. (2020b). Rule mining with rum. In 2020 2nd

International Conference on Process Mining (ICPM),

pages 121–128. IEEE.

Alman, A., Di Ciccio, C., Maggi, F. M., Montali, M., and

van der Aa, H. (2021). Rum: Declarative process

mining, distilled. In Polyvyanyy, A., Wynn, M. T.,

Van Looy, A., and Reichert, M., editors, Business Pro-

cess Management, pages 23–29, Cham. Springer In-

ternational Publishing.

Ardimento, P., Aversano, L., Bernardi, M. L., Carella, V. A.,

Cimitile, M., and Scalera, M. (2023). UML miner:

A tool for mining UML diagrams. In ACM/IEEE In-

ternational Conference on Model Driven Engineering

Languages and Systems, MODELS 2023 Companion,

aster

as, Sweden, October 1-6, 2023, pages 30–34,

aster

as, Sweden. IEEE.

Ardimento, P., Bernardi, M. L., Cimitile, M., and Maggi,

F. M. (2019a). Evaluating coding behavior in software

development processes: A process mining approach.

In 2019 IEEE/ACM International Conference on Soft-

ware and System Processes (ICSSP), pages 84–93.

Ardimento, P., Bernardi, M. L., Cimitile, M., and Ruvo,

G. D. (2019b). Learning analytics to improve cod-

ing abilities: a fuzzy-based process mining approach.

In 2019 IEEE International Conference on Fuzzy Sys-

tems, FUZZ-IEEE 2019, New Orleans, LA, USA, June

23-26, 2019, pages 1–7. IEEE.

Ardimento, P., Bernardi, M. L., Cimitile, M., and Ruvo,

G. D. (2019c). Mining developer’s behavior from

web-based IDE logs. In Reddy, S., editor, 28th IEEE

International Conference on Enabling Technologies:

Infrastructure for Collaborative Enterprises, WET-

ICE 2019, Naples, Italy, June 12-14, 2019, pages 277–

282. IEEE.

Burattin, A., Maggi, F. M., and Sperduti, A. (2016). Con-

formance checking based on multi-perspective declar-

ative process models. Expert Systems with Applica-

tions, 65:194–211.

Burattin, A., Maggi, F. M., van der Aalst, W. M. P., and

Sperduti, A. (2012). Techniques for a posteriori anal-

ysis of declarative processes. In Chi, C., Gasevic, D.,

and van den Heuvel, W., editors, 16th IEEE Interna-

tional Enterprise Distributed Object Computing Con-

ference, EDOC 2012, Beijing, China, September 10-

14, 2012, pages 41–50. IEEE Computer Society.

Crahen, E., Alphonce, C., and Ventura, P. (2002). Quick-

uml: A beginner’s uml tool. In Companion of the

17th Annual ACM SIGPLAN Conference on Object-

Oriented Programming, Systems, Languages, and Ap-

plications, OOPSLA ’02, page 62–63, New York, NY,

USA. Association for Computing Machinery.

Foss, S., Urazova, T., and Lawrence, R. (2022). Learn-

ing UML database design and modeling with au-

toer. In K

uhn, T. and Sousa, V., editors, Proceed-

ings of the 25th International Conference on Model

Driven Engineering Languages and Systems: Com-

panion Proceedings, MODELS 2022, Montreal, Que-

bec, Canada, October 23-28, 2022, pages 42–45.

ACM.

Kupferman, O. and Vardi, M. Y. (2003). Vacuity detection

in temporal model checking. Int. J. Softw. Tools Tech-

nol. Transf., 4(2):224–233.

Pesic, M. (2008). Constraint-based workﬂow management

systems : shifting control to users. Phd thesis 1 (re-

search tu/e / graduation tu/e), Industrial Engineering

and Innovation Sciences. Proefschrift.

Pesic, M., Schonenberg, H., and van der Aalst, W.

M. P. (2007). DECLARE: full support for loosely-

structured processes. In 11th IEEE International

Enterprise Distributed Object Computing Conference

(EDOC 2007), 15-19 October 2007, Annapolis, Mary-

land, USA, pages 287–300. IEEE Computer Society.

van der Aalst, W. M. P. (2016). Process Mining - Data

Science in Action, Second Edition. Springer.

ICSOFT 2025 - 20th International Conference on Software Technologies

214