[1]Grischa Liebel [2]Jil Klünder [3]Regina Hebig

[1]Department of Computer Science, Reykjavik University, Menntavegur 1,
Reykjavik, 102, Iceland

[2]Software Engineering Group, Leibniz University Hannover, Welfengarten 1,
Hannover, 30167, Germany

[3]Department of Software Engineering, University of Rostock, Albert-Einstein-
Straße, Rostock, 18057, Germany

4]Department of Software Engineering, Humboldt-Universität zu Berlin, Unter
den Linden 6, 10099, Berlin, Germany

5]Unaffiliated Researcher, Frankfurt, Germany

6]Department of Software Engineering II, University of Passau, Innstraße 33,
Passau, 94032, Germany

7]XITASO GmbH, Austraße 35, 86153, Augsburg, Germany

8]Department of Computer Science, University of Antwerp, Middelheimlaan 1,
2020, Antwerp, Belgium

9]Department of Informatics, Karlsruhe Institute of Technology, Am
Fasanengarten 5 Karlsruhe, 75131, Germany

10]SMT-EMI6, Carl Zeiss SMT GmbH, Rudolf-Eber-Straße 2, 73447, Oberkochen,
Germany

11]Department of Computer Science and Engineering, Chalmers $|$ University of
Gothenburg, Gothenburg, 41127, Sweden

12]Department of Interdisciplinary Didactics, Karlsruhe Institute of
Technology, Engesserstr. 2 Karlsruhe, 75131, Germany

13]Department of Computer Science, Saarland University, Saarland Informatics
Campus, Saarbrücken, 66123, Germany

14]Institute of Software Engineering and Languages, Ulm University, James-
Franck-Ring, 89081, Ulm, Germany

15]Department of Computer Science, NOVA School of Science & Technology, Campus
de Caparica, 2829-516 Caparica, Portugal

16]Department of Engineering Design and Teaching Innovation, University of
Ottawa, 800 King Edward Avenue, Ottawa, K1N6N5, Canada

17]KASTEL - Institute of Information Security and Dependability, Karlsruhe
Institute of Technology, Am Fasanengarten 5 Karlsruhe, 75131, Germany

18]Department of Computer Science, University of Bern, Bern, 3012, Switzerland

19]Department of Mathematics and Computer Science, Eindhoven University of
Technology, De Zaale, 5600 MB, Eindhoven, The Netherlands

20]Instituto Universitario Mixto de Tecnología Informática, Universitat
Politècnica de València, Camino de Vera s/n, 46022 Valencia, Spain

# Human Factors in Model-Driven Engineering: Future Research Goals and
Initiatives for MDE

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Christopher Lazik<EMAIL_ADDRESS>Inês Nunes
<EMAIL_ADDRESS>Isabella Graßl<EMAIL_ADDRESS>Jan-
Philipp Steghöfer<EMAIL_ADDRESS>Joeri Exelmans
<EMAIL_ADDRESS>Julian Oertel<EMAIL_ADDRESS>Kai
Marquardt<EMAIL_ADDRESS>Katharina Juhnke<EMAIL_ADDRESS>Kurt Schneider<EMAIL_ADDRESS>Lucas Gren
<EMAIL_ADDRESS>Lucia Happe<EMAIL_ADDRESS>Marc Herrmann
<EMAIL_ADDRESS>Marvin Wyrich<EMAIL_ADDRESS>Matthias Tichy<EMAIL_ADDRESS>Miguel Goulão<EMAIL_ADDRESS>Rebekka Wohlrab<EMAIL_ADDRESS>Reyhaneh Kalantari
<EMAIL_ADDRESS>Robert Heinrich<EMAIL_ADDRESS>Sandra
Greiner<EMAIL_ADDRESS>Satrio Adi Rukmono<EMAIL_ADDRESS>Shalini Chakraborty<EMAIL_ADDRESS>Silvia Abrahão<EMAIL_ADDRESS>Vasco Amaral<EMAIL_ADDRESS>*  *  *  [  [  [  [  [  [  [  [  [  [  [
[  [  [  [  [  [

###### Abstract

Purpose: Software modelling and Model-Driven Engineering (MDE) is
traditionally studied from a technical perspective. However, one of the core
motivations behind the use of software models is inherently human-centred.
Models aim to enable practitioners to communicate about software designs, make
software understandable, or make software easier to write through domain-
specific modelling languages. Several recent studies challenge the idea that
these aims can always be reached and indicate that human factors play a role
in the success of MDE. However, there is an under-representation of research
focusing on human factors in modelling.

Methods: During a GI-Dagstuhl seminar, topics related to human factors in
modelling were discussed by 26 expert participants from research and industry.

Results: In breakout groups, five topics were covered in depth, namely
modelling human aspects, factors of modeller experience, diversity and
inclusion in MDE, collaboration and MDE, and teaching human-aware MDE.

Conclusion: We summarise our insights gained during the discussions on the
five topics. We formulate research goals, questions, and propositions that
support directing future initiatives towards an MDE community that is aware of
and supportive of human factors and values.

###### keywords:

MDE, Modelling, Modeling, Human Factors, Workshop

##  1 Introduction

The use of software models to design, analyse, generate, and document
software, often called Model-Driven Engineering (MDE), is at the core of
software engineering (SE) research and practice. Strong communities have been
built around modelling technologies, as evidenced by several international
conferences specialising in the topic, e.g., the CORE A-ranked Models
conference111https://modelsconference.org.

Models are aimed at enabling practitioners to communicate about software
designs [1], at making software understandable [2], or at making software
easier to write through domain-specific modelling languages [3]. The modelling
community traditionally studies these aspects from a technical perspective,
considering aspects such as the technical design of language workbenches,
specifications of modelling standards, grammar generation from meta models,
and model transformation languages. However, one of the core motivations
behind the use of software models is inherently human-centred, and several
recent studies indicate that human factors play a role in the success of MDE
[4, 5]. Such research focusing on human factors in modelling is currently
under-represented, including topics such as:

  * •

human factors that influence the way models are used;

  * •

design of modelling languages and technologies that account for human factors,
such as cognitive ergonomics and accessibility issues;

  * •

the potential of models in supporting humans in SE, e.g., during software
comprehension, for explainable AI, or usability design.

To address this gap in existing work, we gathered a group of 26 researchers
related to human factors and modelling research in Schloss Dagstuhl in
November 2023 to constructively discuss ways forward in research related to
human factors in MDE222https://www.dagstuhl.de/23473. In the following, we
summarise the discussions during the seminar, as well as the recommendations
and suggested actions resulting from them.

##  2 Overview of Discussed Topics

The insights presented in this paper emerge from discussions at a GI-Dagstuhl
seminar on ”Human Factors in Model-Driven
Engineering”333https://www.dagstuhl.de/23473. Details about the participants
of the seminar can be found in the appendix A.

Using the 1-2-4-ALL
microstructure444https://www.liberatingstructures.com/1-1-2-4-all/, we
elaborated goals, outcomes, and topics to be discussed over the week. In this
practice, participants are encouraged to individually brainstorm specific
topics for a limited amount of time, such as the goals, outcomes, and topics
for the seminar. This step is followed by pairing up with another participant,
comparing the individual results and agreeing on joint results. The same is
repeated with groups of four and, finally, with all participants.

In the first step, the participants elicited their goals and expected outcomes
of the workshop with the 1-2-4-ALL microstructure. The most frequently
mentioned (and aligned) goals were (1) to formulate a research agenda
respectively to build a roadmap, (2) to exchange ideas, (3) to make MDE more
practical, (4) to unify projects, (5) to develop ideas for empirical research
on MDE in industry, and (6) to use more models (of humans).

The requested outcomes of the workshop were quite manifold, but all
participants agreed upon establishing contacts and collaborations for specific
subtopics and finding new friends. From a research perspective, the mentioned
outcomes included writing joint papers, research proposals, or a book; finding
approaches to integrate human factors in software engineering; to establish
concepts to integrate MDE in development workflows; to identify best practices
for research in industrial settings; to find strategy guidelines for teaching
MDE; and to develop a new paradigm for human behaviour.

In the next step, the group of participants identified a total of ten topics
to be discussed over the week:

  1. 1.

Factors of Modeller Experience

  2. 2.

Collaboration and MDE

  3. 3.

Diversity and Inclusion in MDE

  4. 4.

Modelling Human Factors

  5. 5.

Teaching Human-aware MDE

  6. 6.

Research Methods

  7. 7.

AI complementing MDE

  8. 8.

MDE ecosystem maturity

  9. 9.

Usability in live modelling

  10. 10.

Sustainability and well-being

As ten topics were considered too many to be discussed in detail over a week,
and as the number of goals and outcomes was too large, a voting with three
votes per participant helped prioritise the topics. This resulted in the final
five topics (Topics 1 to 5 in the list above) being discussed throughout the
week. The same voting also allowed us to condense the outcomes into:

  * •

New active contacts

  * •

Concepts to embed MDE in development workflows

  * •

Best practices for research in industrial settings

  * •

A collaborative paper

The identified two main goals are (1) to elicit ideas for empirical research
on MDE in industry and (2) to use more models of and for humans.

In the following sections, we will describe the outcomes of the discussions
surrounding each topic in more detail.

##  3 Topic 1: Factors of Modeller Experience

In the breakout group for Topic 1, we discussed the factors that contribute to
the Modeller Experience (MX). The motivation was to recognise MX’s key role in
MDE adoption and its lack of detailed definition in scholarly work. Our
discussion aimed to systematise MX by identifying and defining its
contributing factors within MDE.

A fundamental insight is that MX varies in organisations’ modelling contexts.
For example, those using formal MBSE approaches, such as in the automotive
sector, differ markedly in their modelling practices compared to organisations
using informal modelling processes. This has led us to recognise four key
modelling workflows, each reflecting distinct aspects of MX in industrial
environments: 1) Low-code; 2) Everything-as-code; 3) MBSE in the Automotive
Domain; and 4) Informal Modelling. We have only considered the last three of
these workflows in this work.

The main objective of this work is to address the following questions: What
factors contribute to MX in the different modelling workflows identified? By
answering this question, we hope to better understand the needs of
practitioners based on their type of workflow and, consequently, be able to
provide better solutions in our research. We also believe that characterising
modelling solutions using our workflows and factors will make it easier to
define a target audience and delineate the research scope.

To answer this question, a focus group of ten modelling experts from academia
and industry brainstormed using the ‘1-2-4-all’ technique to identify factors
more tailored towards the modeller, such as required training,
maintainability, immediate benefits, and integration into the programming
ecosystem. The participants then discussed how these different factors were
related to each other.

The result of the intense discussions is the set of factors shown in Figure 1.
They are split into inherent factors (which are inevitable based on the
characteristics of the addressed problem), technical factors and non-technical
factors and are described as follows.

Figure 1: Factors of modeller experience and their relationships. Inherent
factors are shown in orange, technical factors in green, and non-technical
ones in blue.

#### Inherent factors

Language Complexity:

Measures the effort to solve modelling problems using a language. Perceived
complexity impacts adoption, as suggested by France et al. [6], who highlight
the challenge of managing language complexity in practice.

Language Choice:

Involves selecting, extending, or defining modelling languages that provide
suitable domain-specific abstractions, considering factors like vendor lock-
in, which affects interoperability. The chosen language directly influences
MX, as highlighted in literature reviews [7]. Language choice is influenced by
the system domain, the “sphere of knowledge, influence, or activity” [8] the
system works in. A modelling language also covers several viewpoints, i.e.,
abstractions that specify the system restricted to certain concerns, created
with specific purposes [9].

#### Technical factors

Integration:

Refers to the capability of modelling approaches to align with existing
development processes and platforms. It involves the ease of chaining multiple
tools together for end-to-end functionalities and the flexibility of tools to
adapt to various processes without requiring additional methods or tools [10].

Tool UX:

Concerns users’ perceptions and responses that result from the use and/or
anticipated use of modelling tools [11]. It includes perceptions of utility,
ease of use and efficiency, as well as the maturity of tools. Companies with
lower adoption of MDE often perceive tool maturity to be worse than those with
higher adoption [12].

Versioning is the ability to track and merge model changes, facilitating model
maintenance, and is one of the main enablers of Collaboration, as stated in
[13]. MX in a team is highly dependent on combining different engineers’ work
and identifying differences between different versions of the same model. This
suggests that versioning is also an important factor of MX. In the literature,
support for collaboration has consistently emerged as a desired attribute of
modelling tools for practitioners[14, 15, 16, 17, 18]. In the more general
field of SE, collaborative tools are found to positively impact productivity
[19, 20]. The lack of adequate version management support has been identified
as a drawback of Model-Based Engineering (MBE) tools within the embedded
systems domain [21]. The main issue is that visual modelling languages are
notoriously difficult to version – because changes in the layout and changes
in the semantics can be difficult to distinguish, and text-based diffing and
merging tools that are integrated into tools like git or its frontends like
GitHub or GitLab are not capable of diffing them visually at all. Specialised
tools, such as EMF Compare555https://eclipse.dev/emf/compare/, have improved
over the years, but they still do not achieve the level of integration
developers are already used to with code. Recent work combining textual and
visual representations of the same models attempts to address these issues
[22] fundamentally.

Technical Capabilities:

The capabilities resulting from the combination of the modelling language and
tool to, e.g., reason about the modelled system’s properties or generate
downstream artefacts.

#### Non-technical factors

Modeller-Intrinsic Motivation:

Is driven by perceived benefits and positive emotions from modelling and leads
modellers to use modelling. Intrinsic motivation stands in contrast to
extrinsic motivation, where the incentive originates from an external source
rather than the inherent appeal of the task [23]. Intrinsic motivation is a
key predictor of developer experience in software development [24].

Organisation-Intrinsic Motivation:

Internal motivations within organisations significantly influence the adoption
of modelling, driven by perceived benefits in productivity, quality, cost, and
collective well-being. The literature highlights these benefits, particularly
in the embedded software industry where efficiency and quality are key
adoption motivators for MDE [25]. Additionally, factors like organisational
culture, expertise, and internal advocacy significantly influence MDE adoption
[26].

Organisation-Extrinsic Motivation:

External factors influencing an organisation’s adoption and approach to
modelling include standards, regulations, tool availability, and customer
demands. Adherence to regulations, especially in the embedded systems
industry, is a significant driver for adopting MDE [27].

Training:

Factors related to skills and knowledge in using modelling languages and
tools. The importance of training for MDE adoption is highlighted [26], with
challenges in the insufficiency of training resources [28] and developer
training efforts.

The working group believes that these factors are important aspects that
affect MX and that understanding their relationships is crucial to
understanding why modelling works (or does not) in an organisation or project
and how to improve MX. To test this idea, we will apply these factors to the
workflows already mentioned above. In these workflows, we captured typical
well-known scenarios from practice and literature: informal modelling with and
without digitally captured diagrams, architectural modelling in the classical
model-based systems engineering sense in the automotive industry, and
modelling as part of work on infrastructure-as-code. We believe that these
scenarios are archetypes and that, by applying the factors to them, we can
learn more about their applicability and gain insights into their relevance.

As a result of this effort, we envision some possible future research
questions:

  * •

Is there evidence that the proposed MX factors are relevant in practice? While
we brought together significant experience in modelling from practice and
research, our current understanding of the factors and their relationships
should be validated in industrial settings with the help of practitioners. To
achieve this, we plan to conduct an empirical study, possibly using a mixed-
method design with interviews and a survey.

  * •

Do existing modelling tools address the factors we have identified? On the one
hand, answering this question will allow us to validate the relevance of the
proposed factors. On the other hand, this mapping will also allow us to
identify factors unsupported by a modelling approach or tool and are,
therefore, candidates for further exploration.

A forthcoming paper that describes the factors in more detail and maps them to
the archetypical workflows will be a first step towards answering these
questions.

##  4 Topic 2: Collaboration and MDE

In the breakout group for Topic 2, we discussed the topic of collaboration and
MDE, which may be parsed in at least three ways: First, we can associate
_modelling together_ to solve a problem, such as with interactive editors or
version control systems trimmed for supporting modelling in teams. Second, we
can associate using models to _express_ collaborative development and, third,
using models to _leverage communication and, thus, collaboration_ (between
different roles in a software project). While the first two options may
provide several possibilities for research, in the sequel, we focus on the
third direction of using models to support communication in software projects.

###  4.1 Motivation

In software projects, different roles and teams need to exchange information.
Although models provide an abstraction layer based on which humans in
different roles can communicate, models are not sufficiently used to _share_
information between roles. Since they provide abstractions which are trimmed
to the purpose of the role, another role may not understand them. Thus, the
missing capabilities of models for collaboration in software projects provoke
lost, inconsistent, or untraceable information, such as requirements, design,
and implementation decisions. The following example illustrates these issues.

#### Motivating Example

Let us consider the transition from the requirements engineering to the
architecture and design phase: requirements analysts should provide
information on the results of their work to the software architect.
Understanding which requirements must be satisfied and what they mean is
crucial for project success. Consequently, it is essential that requirements
analysts and software architects (and later on any other involved person in
the process, such as developers, testers, etc.) form the same understanding of
the requirements’ meaning.

In case of a plan-driven process, a specification with use cases and use case
diagrams results from the requirements engineering phase, representing one
possibility to model the elicited requirements. Although use case diagrams are
an established means of modelling requirements, it is debatable whether they
suffice for software architects to understand for what software they should
provide an architecture. Instead, both roles communicate informally and
verbally, which always introduces the risk of misunderstandings or lost
information.

Using persisted models provided by the requirements engineers, such as use
case diagrams, can support establishing a shared understanding, but in
practice, they tend to be neglected, particularly in communicating between
project roles [29, 30].

###  4.2 Characteristics of Models for Supporting Collaboration

To solve the problem of refused communication between roles using models, we
first need to examine which characteristics of models hinder or benefit
communication and, thus, collaboration between different roles. In the
following, we present key characteristics that we elicited in extensive focus
group discussions and refined based on discussions with all participants.

Figure 2: Characteristics of models to benefit communication in collaborations

First, two main characteristics of models are decisive, the formality and the
acceptance state, as depicted in orange in Figure 2. We consider “acceptance”
as the goal (necessary requirement) to be satisfied when we want a model to be
used for communication. We identified the “formality” of the model as the
independent variable which we can control. Although formality does not
directly influence acceptance, several mediating factors exist that formality
influences (e.g., the ease of use) and which, in turn, influence acceptance.

Furthermore, the figure distinguishes the characteristics of a model that are
technical-centred (visualised as rectangles) and human-centred (visualised as
ellipses), and some that are shared by both (visualised as parallelograms).
The association of an attribute to the human or the technical support for the
model depends on the measurement. Human-centred characteristics completely
depend on the human’s assessment (and, hence, vary depending on the person
interacting with the model) whereas one should be able to measure technical-
centred attributes objectively. The figure presents relationships between the
different characteristics with clear increasing or decreasing effect (“the
more X, the more Y”, “the less X, the less Y”; denoted as “++”) or with
contradicting effect (“the more X, the less Y” or “the less X, the more Y”;
denoted as “+-” and vice versa, respectively). For example, the more formal a
model is, the more complex it is to create, as it requires more effort to
define it properly. Conversely, for instance, the more comprehensible a model
is, the contained information is of higher reliability which, in turn,
positively affects the acceptance of a model.

In summary, based on the figure we can conclude that the amount of formalism
influences negatively the ease of annotation, creation, and comprehension. In
contrast, the more formal a model is, the higher the likelihood it is
unambiguous, transformable, traceable and, in turn, reliable and usable,
positively affecting its acceptance.

###  4.3 Research Agenda

As a result of eliciting these characteristics, we propose to pursue the
following steps to optimise using models for effective communication and
collaborations:

  1. 1.

Investigate why different roles do not use models for communication across
their field.

  2. 2.

Empirically elicit characteristics in frequently used models which complicate
or ease the communication across roles and stakeholders.

  3. 3.

Compare the characteristics with human needs to communicate provide guidelines
that enhance existing models to facilitate communication across roles

  4. 4.

Derive metrics for measuring the quality of the enhanced models.

By pursuing these steps, we will first derive insights from practice and
research, which may require interdisciplinary models. Furthermore, the
elicited characteristics allow us to define guidelines to optimally use models
in communication. Eventually providing metrics may increase the practical
usage of models in communication across heterogeneous roles in software
projects.

##  5 Topic 3: Diversity and Inclusion in MDE

In the breakout group for Topic 3, we critically discussed diversity and
inclusion as related to MDE and formulated a research roadmap for the topic.
The diversity dimensions we consider are age, educational background, cultural
background, gender, experience level, cognitive diversity (i.e.,
neurodiversity), and colour blindness of the modeller and the model end user.
We either have evidence suggesting differences concerning MDE for these
dimensions, or we hypothesise a potential impact. For instance, cognitive
diversity, user age, gender, or cultural background might all affect preferred
working methods and problem-solving styles. In turn, these preferences might
align well or conflict with MDE tools, notations, and workflows.

Several discussions and brainstorming sessions based on these diversity
dimensions led us to six distinct research directions related to Diversity and
Inclusion in MDE. An overview of these directions and their connections is
depicted in Figure 3. In the following, we discuss each direction separately.

Figure 3: Overview of identified dimensions of research topics relevant for
diversity in MDE.

###  5.1 Universal Design

Universal Design is “the design and composition of an environment so that it
can be accessed, understood and used to the greatest extent possible by all
people regardless of their age, size, ability or
disability”666https://universaldesign.ie/what-is-universal-design/. We
transfer this concept to MDE, proposing that a better understanding of what
needs different diverse groups have will lead to improvements in MDE and
related practice. Improving modelling tools, languages, techniques, and
practices (MTLTPs) accordingly will ultimately benefit all people and the
field, not only the specific group targeted.

Thus, the central goal of this research direction is to understand the needs
for MTLTPs with respect to several diversity dimensions. To address this goal,
we need to investigate what aspects of modelling are affected by diversity
concerns, and which barriers exist for diverse stakeholders. This relates to
tooling and visual aspects, e.g., modelling notations and layout, but also
comprises cognitive aspects, such as preferred workflow, model comprehension,
and information processing style. Understanding these effects and the involved
dimensions will allow for the creation of guidelines for better tool and
practice design surrounding MDE that benefit all users.

###  5.2 Awareness of Biases

MTLTPs are purposefully designed but may contain biases, which raises concerns
about their inherent subjectivity and their reflection on the modeller’s
background.

We hypothesise the presence of biases in MTLTPs toward specific diversity
dimensions, highlighting the importance of studying these biases. The
objective is to compile scenarios illustrating how MTLTPs might yield biased
results, providing insights for refining design guidelines.

For instance, cultural biases may emerge in language design, affecting text
length and layout preferences. In modelling videos from India, we observe that
reference names and annotations tend to be longer than the common European
approach, which might relate to low & high context cultures [31].
Additionally, gender bias is noticeable in teaching materials through
stereotypical representations, potentially contributing to inequities [32].

The overarching objective of this dimension is twofold: (1) Make biases
explicit in models and (2) raise awareness to guide future MTLTP design. This
involves examining real-world examples of biases from diverse literature,
assessing student assignments and critically evaluating teaching materials,
papers on modelling, and content analysis of teaching videos.

###  5.3 Effects of Diversity on Modelling

The exploration of the effects of diversity on modelling centres on
recognising that models are created, maintained, and interpreted by
individuals with unique characteristics, influencing their interactions with
models.

Given the impact of diverse group compositions on communication and
collaboration methods, the primary objective is to understand better how
various diversity dimensions influence the modelling process within group
dynamics, and subsequently affect the features of resulting models.

Examples from other SE sub-fields, such as programming, demonstrate that
individuals from different age groups [33] or genders [34] exhibit varied
working approaches, stress coping mechanisms, and conflict resolution
strategies, influencing the outcomes, such as code quality [34].

The long-term goal involves creating awareness of expected differences,
developing inclusive modelling tools, and enhancing accessibility in modelling
explanations through comparative analysis of modelling discussions and
decisions among diverse groups via participatory observations.

###  5.4 Modelling as a Tool to Analyse Biases

Models are a tool for abstraction. As such, we hypothesise that they may be
more suitable for analysing and detecting certain biases that may be otherwise
obfuscated in more detailed artefacts defined at lower abstraction levels,
such as source code. This research direction aims to understand how we can
leverage models to detect potential biases. This could be done by creating
methods for systematically reasoning about diversity through models, or by
using models in the context of participatory design to involve diverse
stakeholders in the modelling process.

For example, reasoning about requirements models may facilitate detecting
missing requirements that affect marginalised or underrepresented groups. In
addition, models can also be created to help detect bias or avoid it [35].
Finally, models may be used to analyse potential biases in datasets built for
machine learning, which could affect data collection, assumptions about the
data, specific valid scenarios, or data quality.

###  5.5 Diversity in Teaching Modelling

The effective teaching of MDE and modelling requires consideration of various
diversity dimensions and their implications for modelling practices.
Recognising and mitigating barriers to learning and adopting modelling
techniques is crucial to fostering an inclusive and accessible educational
environment.

To overcome these barriers, tailored teaching strategies and methodologies are
crucial. For example, enhancing self-efficacy in female students has been
shown to be essential for engaging them in computer science disciplines,
including MDE [36]. Furthermore, the absence of timely feedback during the
learning process can result in frustration, adversely affecting students’
willingness to embrace and learn modelling. Students on the autistic spectrum
may encounter difficulties with free-hand modelling exercises, owing to a need
for clear processes and well-defined rules [37].

Addressing the needs of diverse groups during teaching can potentially reduce
barriers to adoption. Key questions for exploration include how teaching
methods and tools impact different groups, identifying teaching strategies
that may conflict with diverse needs, and understanding how to mitigate
conflicts arising from diversity within student groups to ensure a positive
learning experience. The long-term goal is to develop and promote inclusive
MDE teaching practices through collaborative efforts involving representatives
of diverse groups. Evaluating developed teaching methods on a larger scale,
including international perspectives, will be essential to gauge effectiveness
and ensure inclusion.

###  5.6 New Tools to Address Diversity in Stakeholders

Enabling more diversity in modelling also asks for a technical view on MDE.
Tools and languages, including Domain-Specific Languages (DSLs), provide the
basis for modelling. Thus, the tools and modelling languages in use need to be
designed to be inclusive of the needs of diverse users. If tools are not
designed according to the requirements of a diverse group of users, they
introduce additional obstacles to the modelling process [35].

We hypothesise that the literature already provides substantial approaches
that offer potential solutions. For example, the dedicated creation of DSLs or
Blended Modelling [38] environments for specific stakeholders or domain
experts can be further used to address stakeholder diversity as well. By
offering a variety of concrete syntaxes related to the same abstract syntax,
different groups can choose the concrete syntax that successfully addresses
their particular needs.

To succeed in the goal of providing tools and modelling languages that are
inclusive of the needs of diverse users, we propose studying the following
high-level questions:

  * •

How can modelling tools successfully address the needs of diverse groups?

  * •

How can tools address collaborative modelling when users prefer different
syntaxes/representations?

  * •

How can blended modelling languages or DSLs be designed for the use of diverse
groups?

The long-term goal of the research on this issue should be to develop
guidelines limiting the barriers to using modelling tools. These guidelines
can also help evaluate newly developed tools on their inclusiveness for
diverse groups.

##  6 Topic 4: Modelling Human Factors

In the breakout group for Topic 4, we discussed that when modelling human
factors, many possible aspects could be considered. We strived for an
interdisciplinary topic between software engineering and psychology to find a
concrete aspect that we could work on during the seminar.

###  6.1 Motivation

Over the last few years, the awareness of human issues and individual human
aspects in SE has grown. There are currently specialised development processes
(such as Human-Centred Design) that emphasise human involvement. Therefore, we
discussed what other aspects of humans could be integrated into our existing
approaches. Previous psychology research has aimed to model or represent
different aspects influencing human behaviour. Humans are complex beings,
which makes it difficult to create holistic models. However, individual human
aspects can be modelled currently with sufficient significance.

###  6.2 Human Values

One of these aspects are human values, as proposed within Schwartz’s theory of
basic human values [39]. These values are modelled in relation to each other,
as depicted in Figure 4, where nearby values are related, whereas bipolar
values are conflicting.

Figure 4: Circular model of Schwartz’s theory of basic human values. (Source:
Schwartz et al. [39])

From the SE perspective, human values are crucial. Human values of end users
play an important role in software projects: values such as trustworthiness,
fairness, etc., are becoming increasingly important, and companies therefore
want to be associated with such positive values. Until now, human values have
hardly been explicitly taken into account in the development process (e.g., as
non-functional requirements).

###  6.3 Process

We envision a human value-centric software process that deliberately consists
largely of familiar building blocks but puts them together in a new way. This
is because the human values of end users are often vaguely formulated at the
beginning and have different meanings for different people. Therefore, in the
development process, these values must be captured during the requirements
elicitation and passed on to the stakeholders and developers. Traceability is
crucial so that human values do not remain an abstract concept but are linked
to design and implementation artefacts.

###  6.4 Novelty

Building on existing concepts such as user involvement and personas, our
envisioned approach aims to transcend individual human desires to focus on
emerging human values, using the Schwartz model as an example. It provides a
pragmatic technique for constructing personas as a collection of human
aspects, focusing on human values. The approach suggests a systematic
progression from high-level needs to decisions that guide the implementation
of value-related requirements. It proposes a systematic framework suitable for
ordinary software organisations. The approach is not limited to human-centred
design professionals but also considers developers, business owners, and other
stakeholders to address the challenges related to the ambiguity of human
values. Additionally, we are developing important research questions to
enhance and evaluate this approach effectively.

###  6.5 Directions

After the seminar, we worked on a systematic approach to represent human
values and ensure traceability. In the near future, we will publish a separate
research article that describes the detailed approach.

##  7 Topic 5: Teaching Human-aware MDE

Models or sketches for thinking are universally beneficial due to their
ability to clarify complex ideas and improve understanding. In the realm of
software and systems engineering, models serve as essential tools for
simplifying complex systems, enabling a shared language among stakeholders,
enhancing collaboration efficiency, and improving decision-making processes.
Effective modelling, especially in open-ended problems, necessitates
structured thinking and a clear purpose, ensuring that all aspects of the
system are considered and appropriately addressed.

Teaching human-aware MDE goes beyond the dissemination of tools and
techniques; it involves nurturing a mindset geared towards prioritisation, in-
depth analysis, and strategic approaches to complex issues. This section
discusses the educational frameworks and pedagogical strategies essential for
cultivating such a mindset.

###  7.1 Pedagogical Challenges

#### The Confidence in Modelling Skills

A key challenge in teaching modelling skills is students’ lack of confidence
in their modelling abilities. This often stems from a fear of making mistakes
or not having complete knowledge of the modelled domain, leading to scepticism
towards their models. This scepticism towards models can be significantly
mitigated by teaching structured thinking, which provides a clear, strategic
framework for tackling modelling problems.

A significant problem faced by computer science students is the premature
focus on implementation during initial designs, which inhibits the development
and utilisation of abstraction skills. This focus on implementation is a
manifestation of difficulties in separating problem space and solution space
[40].

It is crucial for educational approaches to focus on exploring the problem
space and abstract thinking. Abstraction in modelling involves the process of
identifying and focusing on the essential aspects of a real-world problem or
system while disregarding the less significant details. This selective focus
allows modellers to create simplified representations (models) of complex
systems that retain only the features pertinent to the problem at hand. The
goal is to make the problem more manageable and the system more understandable
without oversimplifying it to the point of losing essential characteristics.

In contrast to the typical computer science view where complexity is hidden in
nested levels of abstraction, abstraction in modelling is driven by the need
to explore and understand the problem space. This involves:

Problem Space Exploration:

Understanding the various elements, relationships, and processes that
constitute the system. This step is crucial for identifying what should be
included in the model and what can be left out.

Purpose-relevant Information Extraction:

Determining which aspects of the system are relevant to the goals of the
modelling effort. This means different models might be created from the same
system for different purposes, each abstracting different facets or details
based on what is most relevant to the problem or question being addressed.

Creation of Usable Models:

Developing a representation of the system that is both simpler than the
reality but still retains all necessary detail to be effective for solving the
problem or answering the question at hand. This involves a balance between
simplification and accuracy, ensuring that the model is both tractable and
valid within the context of its intended use.

Abstraction, therefore, is a critical skill in modelling because it allows the
modeller to construct meaningful and usable models without becoming
overwhelmed by the complexities of the real world. It involves a deliberate
process of filtering out noise and focusing on the essence of the problem,
which requires a deep understanding of both the system being modelled and the
context in which the model will be applied. This skill enables modellers to
navigate the vast problem spaces they encounter and develop effective
solutions and strategies. This will better prepare students to contribute
effectively in the rapidly evolving technological landscape. Abstraction
skills are difficult to teach as they require balancing detail and
generalisation.

#### The Crucial Role of Feedback

Feedback is an indispensable component in the learning process, as it supports
learning and builds confidence. The lack of relevant and constructive feedback
contributes to the challenges students and teachers face. Furthermore, the
previously mentioned lack of confidence of students in their modelling
abilities is often exacerbated by the absence of relevant and constructive
feedback on the quality of their models.

However, providing quality feedback on models presents unique challenges. For
example:

Assessing completeness:

In complex domains, it can be difficult to determine if a model
comprehensively covers all relevant concepts.

Evaluating correctness:

The correctness of a model goes beyond just accurately representing individual
concepts; it also involves the relationships between these concepts.

Navigating multiple valid models:

For a given problem within a domain, there can be several different yet
equally valid models. This complicates the feedback process as there is no
single “right” model against which students’ work can be benchmarked.

Understanding model quality:

There is no tangible, universally accepted definition of model quality; hence
providing feedback on model quality can be abstract and challenging for
students to grasp.

Addressing these challenges necessitates a nuanced approach to feedback that
recognises the complexities involved in modelling.

#### The Embracing of and Motivation for Modelling

Many students find it difficult to appreciate the significance of modelling.
Modelling can be seen as an overwhelming abstract and annoying task, being in
the way to start programming. This view can lead to a lack of interest in
mastering modelling techniques and recognising their application across
various fields.

The true benefit of modelling manifests itself in collaborative, iterative,
and long-term projects. However, these situations are rarely utilised in
education. For instance, while group projects are common, they rarely focus
explicitly on fostering collaborative modelling skills. Additionally, the
typical duration of university courses, spanning from a few weeks to a
semester, limits the depth of engagement students can have with complex
modelling projects, thus restricting the potential for meaningful teamwork and
iterative learning.

Finally, our observations suggest that the ability of students to read and
comprehend existing models is underdeveloped. This deficiency stems from
educational practices that focus on creating new models, neglecting the
equally important skill of model interpretation. Students seldom receive
assignments that require them to analyse and understand existing models, which
leads to a lack of familiarity and confidence in dealing with pre-established
frameworks. Furthermore, this leads students to adopt a skewed understanding
of modelling. This gap undermines their confidence in modelling and impairs
their ability to effectively contribute to ongoing projects or adapt existing
models to new contexts.

###  7.2 Addressing the Challenges

Addressing the challenges outlined above requires an integrated approach to
teaching modelling that highlights practical benefits, encourages active
collaboration, incorporates activities and assignments that focus on the
critical analysis of existing models, and demystifies the various techniques
and notations used.

#### Strategies for Assessing Modelling Skills

The challenge in teaching modelling skills is finding an equilibrium between
the need for tangible, assessable outcomes and maintaining the holistic nature
of of modelling, which is critical for students’ comprehension and application
in real-world scenarios. Educators must navigate this balance to cultivate
both technical competence and an appreciation for the value of modelling in
the broader interdisciplinary educational context.

To address this challenge, educators should consider implementing a
multifaceted approach that includes incremental learning and constructive
feedback on modelling assignments, structured thinking exercises that promote
abstract reasoning and problem decomposition, and practical training through
real-life case studies and examples. This approach, including critical essays,
analysis papers, Socratic discussion seminars, peer reviews and case studies,
fosters a more profound understanding of the importance and applicability of
modelling in various contexts.

#### Strategies for Delivering Constructive and Relevant Feedback

It can be beneficial to follow a structured guideline when assessing student
models to elevate the quality of students’ models and provide better feedback.
A key element of this strategy involves differentiating feedback between
syntax and semantics. By distinguishing between these two dimensions,
educators can provide more targeted feedback that addresses student models’
form and substance. Moreover, feedback should be positive and constructive,
highlighting what students have done well and pointing out areas for
improvement. This approach encourages learning by reinforcing successful
strategies and providing clear, actionable suggestions for addressing
weaknesses. Such feedback fosters a learning environment that values growth
and clear, targeted improvement.

Feedback must be specific and refer to concrete instances within the model to
be effective. For example, rather than making a general statement about the
model’s organisation, an instructor might point out how the placement of a
particular element enhances the model’s clarity and coherence. Additionally,
feedback should clearly differentiate between the problem space and the
solution space. This distinction helps students understand whether issues
arise from their understanding of the problem or the resolution methods they
have chosen to solve.

When measuring the quality of student models, visual aesthetics and the layout
of diagrams can serve as an initial proxy for model quality, as they often
reflect the student’s attention to detail and organisational skills. However,
one should be careful not to overemphasise form over function. The naming of
model elements is also critical, as names should be descriptive, concise, and
appropriate to the level of abstraction while also conforming to established
conventions.

Finally, an attempt at completeness should be made by comparing the list of
concepts in the problem description with those present in the model,
identifying any missing or unnecessary elements. Educators can significantly
enhance students’ modelling skills through such thorough and thoughtful
feedback, providing them with the tools and understanding necessary to develop
high-quality, meaningful models.

#### Strategies for Teaching Structured Thinking

Structured thinking is a foundational skill for modellers, fostering
confidence in their models and underlining the relevance of modelling. It
enables the breakdown of complex problems into manageable parts, facilitating
clear analysis. Teaching structured thinking involves introducing students to
frameworks and methodologies that guide the systematic exploration of problems
and the development of coherent, logical models. Techniques such as mind
mapping, decision trees, and logical frameworks can be instrumental in this
process.

This educational approach should focus on iterative learning, where students
iteratively refine their critical and strategic thinking abilities.
Encouraging reflective practice, where students evaluate their thought
processes and modelling decisions, can significantly enhance their
understanding and application of structured thinking in modelling. Exercises
designed to simulate real-world scenarios can provide practical experience in
applying structured thinking, thereby enhancing students’ confidence in their
modelling abilities and the perceived value of modelling.

##  8 Discussion

The topics summarised in Sections 3 to 7 outline various topics, goals, and
research questions for future work. The five topics cover specific aspects
concerning those topics in depth. However, there are various connection points
between the five topics that are worth highlighting. These connections are
sketched in Figure 5.

Figure 5: Overview of the seminar topics.

Overall, we observe that topics 1, 2, 3, and 5 are well-connected. Topic 1,
_Factors of Modeller Experience_ , provides a broad frame of technical and
non-technical factors that can affect modeller experience. Topic 2,
_Collaboration and MDE_ , and Topic 3, _Diversity and Inclusion in MDE_ ,
consider specific cases of such factors, i.e., diversity-related factors and
communication/collaboration-related factors. These specific cases might give
rise to additional MX-related factors, or moderate their effect. Jointly, the
three topics promote the message that considering technical factors alone is
insufficient for successful use and adoption of MDE, and to understand how and
why MDE is applied in practice. These observations lead us to the following
proposition:

Proposition 1: We propose that modelling is not an objective process, but
various technical and non-technical factors affect the individual modelling
experience. The community needs to (1) investigate what these factors are, and
(2) investigate to what extent the factors affect modelling practice and
adoption.

Topics 1 to 3 also all discuss that specific contexts need to be distinguished
and studied separately, which is introduced as archetype workflows in _Factors
of Modeller Experience_. While named differently, specific examples of such
workflows are covered in _Diversity and Inclusion in MDE_ with respect to
diversity & inclusion, and in _Collaboration and MDE_ with respect to
collaborative aspects of MDE. Collecting such archetype workflows could be an
important goal for the MDE community as a whole, as it would allow to better
reason about the (external) validity of various empirical studies. We
summarise this as follows:

Proposition 2: We propose that various different contexts or workflows need to
be considered in MDE research to allow for more precise conclusions to be
drawn. The community needs to collect and validate representative workflows of
the application of MDE in practice.

Jointly addressing Propositions 1 and 2 could help the MDE community increase
the validity of research results, e.g., in reasoning about success factors of
MDE-related interventions in industry.

Topic 5, _Teaching Human-aware MDE_ , connects naturally to Topics 1 to 3 as,
ultimately, students (and future engineers) need to be taught the complexity
of modelling beyond purely syntactical and technical factors. On the one hand,
this necessitates that educators are aware of relevant human factors and
dimensions that affect MX so that MX does not negatively affect the classroom,
ultimately leading to a lower acceptance of MDE. On the other hand, it also
requires highlighting these factors to the student population to ensure
transfer to and awareness in practice. We summarise these observations as
follows.

Proposition 3: Education in MDE needs to mirror research efforts in the sense
that educators (1) need to understand the effect of human factors on modeller
(and student) experience, and (2) need to convey the importance of these human
factors to the student population, so that knowledge transfer to practice
takes place.

Topic 4, _Modelling Human Factors_ , is somewhat disconnected in contrast to
the close coupling of the remaining topics. This group takes a different
approach, namely how models can be used to analyse or consider human factors
in SE. Topic 3, _Diversity and Inclusion in MDE_ , covers this angle as well
in two sub-points, i.e., that models can be a means to better understand
diversity-related biases, and that existing contributions in the MDE community
can be used to better support diverse needs among modellers and consumers of
models in practice. This angle can be compared to previous discussions on how
knowledge in the MDE community can serve other research fields, e.g., for
climate modelling [41, 42]. However, in these previous cases, authors have
advocated applying MDE-related knowledge to better understand phenomena in the
scientific disciplines of engineering and natural sciences. Instead, we raise
the point that the many contributions of the MDE community and their technical
sophistication can and should be used for human factors. Overall, we propose
the following.

Proposition 4: Human factors are increasingly important in SE research and
practice. Therefore, the community needs to apply their MDE-related knowledge
and experience to models of human factors in SE.

In addition to the research goals and questions suggested by the individual
groups, and the propositions made above, connections between individual topics
can lead to further interesting avenues for future work. For instance, Topic
2, _Collaboration and MDE_ naturally connects to several of the other topics
for issues concerning collaboration or teamwork. Specifically, Modeller
Experience, as covered in Topic 1, might vary from individual model use in
cases of collaborative modelling. _Versioning_ is highlighted as a technical
factor contributing to MX and essential for successful collaborative MDE.
However, further technical and non-technical factors could similarly affect MX
in collaborative settings. Finally, _Collaboration and MDE_ has a joint
connection to Topic 3, _Diversity and Inclusion in MDE_. Collaborative
modelling in a diverse group of people can lead to diverse, and potentially
conflicting viewpoints, opinions, and preferences. This influence of diversity
needs to be better understood to enable successful collaborative modelling
practices. Similarly, in education, collaborative modelling in diverse groups
needs to be learned and practised to enable university graduates to deal with
this diversity in practice. Topic 1, _Factors of Modeller Experience_ , has an
additional connection to _Diversity and Inclusion in MDE_. That is, several
non-technical factors related to MX might be affected by the diversity of the
modeller(s) or the model’s users. For example, preferences on factors such as
layout, tooling, or amount of information contained in a model can potentially
affect MX. At a higher level of abstraction, it is worth considering whether
diversity-related topics add additional factors not considered in _Factors of
Modeller Experience_ , such as cultural factors, or if they are simply
moderators to the listed factors. In summary, we therefore propose the
following.

Proposition 5: In addition to the points raised in Proposition 1 to 4, the
community needs to pay considerable attention to how collaboration and group
diversity affects modelling.

##  9 Conclusion

This paper summarises the discussions we, a group of 26 researchers and
practitioners connected to MDE and human factors research, had during a one-
week seminar at Schloss Dagstuhl. We focused on five topics which we elicited
jointly at the start of the seminar. In our opinion, these five topics require
urgent attention in the MDE research community. We formulated research goals,
questions, and propositions that support directing future initiatives towards
an MDE community that is aware of and supportive of human factors and values.

The topics raised represent the collective opinions and knowledge of the
various experts present at the seminar, and are often not evidence-based.
Naturally, this means that others might disagree with our positions, and
empirical evidence might prove us wrong in various ways in the future. We
encourage the community to engage with us in constructive discussions on our
positions and suggestions.

Finally, several suggested topics did not receive enough attention during the
seminar. The list of goals, outcomes, and topics we presented in Section 2 of
this report can serve as an inspiration to explore further directions in
addition to the ones we proposed.

Acknowledgments We thank Schloss Dagstuhl for the opportunity to conduct the
workshop and the GI (Gesellschaft für Informatik) for supporting it.

##  Appendix A Appendix: Goals and Setup of the GI-Dagstuhl Seminar

The results presented in this paper emerge from discussions at a GI-Dagstuhl
seminar777https://www.dagstuhl.de/en/seminars/gi-dagstuhl-seminars. These
seminars are similar to the well-known traditional Dagstuhl
seminars888https://www.dagstuhl.de/en/seminars/dagstuhl-seminars but cater
towards early-career researchers, such as PhD students and postdocs.

The primary goals of the seminar were (1) to establish closer collaborations
and shape future goals in human factors in MDE and (2) to broaden the
perspective of the seminar topic through insights into related research areas.
To address (1), we invited early-career researchers who study human factors in
software modelling through contacts and existing publications in the HuFaMo
workshop series, held as a part of the Models conference every year.
Additionally, we invited a few selected senior researchers in this community.
To address (2), we invited participants who conduct research not directly
related to MDE but related to the human factors seminar theme, such as
psychology or human-centred software engineering. Finally, connected to both
goals, we invited experienced industrial participants interested in MDE, to
anchor discussions in industrial needs.

###  A.1 Participants

The aforementioned goals led to a diverse group of 26 participants, with 11
women and 15 men, 3 participants from industry, another 2 who used to work in
industry, 9 participants before finishing their PhD, and 5 senior
participants. Given the nature of Dagstuhl seminars, most of the participants
came from Germany (15), followed by Iceland (2), Portugal (2), and Sweden (2).
One participant each came from Belgium, Canada, Switzerland, the Netherlands,
and Spain.

###  A.2 Seminar Structure

After a first unofficial get-together on Sunday, we started the seminar early
on Monday, 19th November 2023. We ended after lunch on Friday, 24th November
2023, spending a total of 4.5 days on in-depth discussion. Throughout the
workshop, we followed several of the practices recommended as a part of
Liberating Structures999https://www.liberatingstructures.com/, i.e., simple
practices for structuring workshops and discussions engagingly and
inclusively.

Monday was used to brainstorm seminar outcomes and topics. From Tuesday until
Friday, we discussed the five most popular topics in breakout groups. Finally,
we recorded results as a joint working document from Thursday onwards. In
parallel to these activities, we had eight selected presentations from junior
participants and one selected presentation on psychological theories from an
established researcher.

###  A.3 Reflections on the Seminar Format

During one week, the author group discussed and reflected on human factors in
MDE in a GI-Dagstuhl Seminar. The format we chose is akin to similar seminars,
e.g., regular Dagstuhl Seminars, Lorentz Center
Workshops101010https://www.lorentzcenter.nl/what-is-a-lorentz-center-
workshop.html, or NII Shonan
Meetings111111https://shonan.nii.ac.jp/proposal/guidelines/. However, the
seminar was aimed primarily towards early researchers, and we, on purpose,
invited people with non-MDE backgrounds, i.e., conducting research in
education and psychology. Additionally, we invited several practitioners with
a background in MDE research. This diverse group composition led to many
interesting and novel discussions, as participants were more likely to think
“out of the box”, i.e., make connections to non-MDE research topics or
industrial practice. Similarly, the juniority of the group as a whole might
indeed have created more novel discussions, as many participants were not as
mechanised in their thoughts on what MDE research is and should be. Hence, we
believe the diverse group composition was a success and will consider this for
future seminars with similar aims.

## References

  *   * [1] Jolak, R. _et al._ Software engineering whispers: The effect of textual vs. graphical software design descriptions on software design communication.  _Empirical software engineering_ 25, 4427–4471 (2020).
  * [2] Ho-Quang, T., Hebig, R., Robles, G., Chaudron, M. R. & Fernandez, M. A.  Juristo, N. & Shepherd, D. (eds) _Practices and perceptions of uml use in open source projects_.  (eds Juristo, N. & Shepherd, D.) _2017 IEEE/ACM 39th International Conference on Software Engineering: Software Engineering in Practice Track (ICSE-SEIP)_ , 203–212 (IEEE, 2017).
  * [3] Götz, S., Tichy, M. & Groner, R.  Claimed advantages and disadvantages of (dedicated) model transformation languages: a systematic literature review.  _Software and Systems Modeling_ 20, 469–503 (2021).
  * [4] Liebel, G., Tichy, M. & Knauss, E.  Use, potential, and showstoppers of models in automotive requirements engineering.  _Software & Systems Modeling_ 18, 2587–2607 (2019).
  * [5] Höppner, S., Haas, Y., Tichy, M. & Juhnke, K.  Advantages and disadvantages of (dedicated) model transformation languages: A qualitative interview study.  _Empirical Software Engineering_ 27, 159 (2022).
  * [6] France, R. & Rumpe, B.  Briand, L. C. & Wolf, A. L. (eds) _Model-driven development of complex software: A research roadmap_.  (eds Briand, L. C. & Wolf, A. L.) _Future of Software Engineering (FOSE ’07)_ , 37–54 (2007).
  * [7] Kalantari, R. & Lethbridge, T. C.  Characterizing ux evaluation in software modeling tools: A literature review.  _IEEE Access_ 10, 131509–131527 (2022).
  * [8] Evans, E.  _Domain-Driven Design Reference: Definitions and Pattern Summaries_ (Dog Ear Publishing, Alaska, USA, 2014).
  * [9] González-Huerta, J., Insfrán, E. & Abrahão, S.  Moreira, A., Schätz, B., Gray, J., Vallecillo, A. & Clarke, P. (eds) _Defining and validating a multimodel approach for product architecture derivation and improvement_.  (eds Moreira, A., Schätz, B., Gray, J., Vallecillo, A. & Clarke, P.) _Model-Driven Engineering Languages and Systems: 16th International Conference, MODELS 2013, Miami, FL, USA, September 29–October 4, 2013. Proceedings 16_ , 388–404 (Springer, 2013).
  * [10] Whittle, J., Hutchinson, J., Rouncefield, M., Burden, H. & Heldal, R.  A taxonomy of tool-related issues affecting the adoption of model-driven engineering.  _Software & Systems Modeling_ 16 (2015).
  * [11] Technical Committee ISO/TC 159/SC 4.  ISO 9241-210:2019 Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems.  Tech. Rep., International Organization for Standardization (ISO) (2019).  URL https://www.iso.org/standard/77520.html.
  * [12] Mohagheghi, P., Gilani, W., Stefanescu, A. & Fernandez, M. A.  An empirical study of the state of the practice and acceptance of model-driven engineering in four industrial cases.  _Empirical Software Engineering_ 18, 89–116 (2013).
  * [13] Pietron, J.  Guerra, E. & Iovino, L. (eds) _Enhancing collaborative modeling_.  (eds Guerra, E. & Iovino, L.) _Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings_ (Association for Computing Machinery, 2020).
  * [14] Ozkaya, M.  Are the uml modeling tools powerful enough for practitioners? a literature review.  _IET Software_ 13 (2019).
  * [15] Badreddin, O., Khandoker, R., Forward, A., Masmali, O. & Lethbridge, T. C.  Wasowski, A., Paige, R. & Øystein Haugen (eds) _A decade of software design and modeling: A survey to uncover trends of the practice_.  (eds Wasowski, A., Paige, R. & Øystein Haugen) , MODELS ’18, 245–255 (Association for Computing Machinery, New York, NY, USA, 2018).
  * [16] Bordeleau, F., Liebel, G., Raschke, A., Stieglbauer, G. & Tichy, M.  Burgueño, L. _et al._ (eds) _Challenges and research directions for successfully applying mbe tools in practice_.  (eds Burgueño, L. _et al._) _Proceedings of MODELS 2017 Satellite Event: Workshops (ModComp, ME, EXE, COMMitMDE, MRT, MULTI, GEMOC, MoDeVVa, MDETools, FlexMDE, MDEbug), Posters, Doctoral Symposium, Educator Symposium, ACM Student Research Competition, and Tools and Demonstrations co-located with ACM/IEEE 20th International Conference on Model Driven Engineering Languages and Systems (MODELS 2017), Austin, TX, USA, September, 17, 2017_ , Vol. 2019 of _CEUR Workshop Proceedings_ , 338–343 (CEUR-WS.org, 2017).  URL http://ceur-ws.org/Vol-2019/mdetools_1.pdf.
  * [17] David, I., Aslam, K., Malavolta, I. & Lago, P.  Collaborative model-driven software engineering—a systematic survey of practices and needs in industry.  _Journal of Systems and Software_ 199, 111626 (2023).
  * [18] Franzago, M., Di Ruscio, D., Malavolta, I. & Muccini, H.  Collaborative model-driven software engineering: a classification framework and a research map.  _IEEE Transactions on Software Engineering_ 44, 1146–1175 (2017).
  * [19] Hidayanto, A. N. & Setyady, S. T.  Impact of collaborative tools utilization on group performance in university students.  _Turkish Online Journal of Educational Technology-TOJET_ 13, 88–98 (2014).
  * [20] UR RAHMAN, A., Khan, K., Kamal, S. W., Naveed, H. & Bacha, M.  Use of collaborative tools and modern technologies as critical success factor in global software development.  _Journal on Software Engineering_ 15 (2020).
  * [21] Liebel, G., Marko, N., Tichy, M., Leitner, A. & Hansson, J.  Dingel, J., Schulte, W., Ramos, I., Abrahão, S. & Insfran, E. (eds) _Assessing the state-of-practice of model-based engineering in the embedded systems domain_.  (eds Dingel, J., Schulte, W., Ramos, I., Abrahão, S. & Insfran, E.) , 166–182 (2014).
  * [22] Exelmans, J., Pietron, J., Raschke, A., Vangheluwe, H. & Tichy, M.  Dubois, C. & Cohen, J. (eds) _Optimistic versioning for conflict-tolerant collaborative blended modeling_.  (eds Dubois, C. & Cohen, J.) _FPVM 2022: 2nd International Workshop on Foundations and Practice of Visual Modeling, July 4–8, 2022, Nantes, France_ , Vol. 3250, 1–12 (2022).
  * [23] Ryan, R. & Deci, E.  Intrinsic and extrinsic motivations: Classic definition and new directions.  _Contemporary Educational Psychology_ 25, 54–67 (2000).
  * [24] Kuusinen, K., Petrie, H., Fagerholm, F. & Mikkonen, T.  Sharp, H. & Hall, T. (eds) _Flow, intrinsic motivation, and developer experience in software engineering_.  (eds Sharp, H. & Hall, T.) , 104–117 (2016).
  * [25] Akdur, D., Garousi, V. & Demirors, O.  A survey on modeling and model-driven engineering practices in the embedded software industry.  _Journal of Systems Architecture_ 91 (2018).
  * [26] Hutchinson, J., Whittle, J., Rouncefield, M. & Kristoffersen, S.  Taylor, R. N., Gall, H. & Medvidovic, N. (eds) _Empirical assessment of mde in industry_.  (eds Taylor, R. N., Gall, H. & Medvidovic, N.) _Proceedings of the 33rd International Conference on Software Engineering_ , ICSE ’11, 471–480 (Association for Computing Machinery, New York, NY, USA, 2011).
  * [27] Vogelsang, A., Amorim, T., Pudlitz, F., Gersing, P. & Philipps, J.  Felderer, M. _et al._ (eds) _Should i stay or should i go? on forces that drive and prevent mbse adoption in the embedded systems industry_.  (eds Felderer, M. _et al._) _Product-Focused Software Process Improvement_ , 182–198 (Springer International Publishing, Cham, 2017).
  * [28] Kalantari, R. & Lethbridge, T.  Blouin, A., Abrahão, S., Palanque, P. & Selic, B. (eds) _Unveiling developers’ mindset barriers to software modeling adoption_.  (eds Blouin, A., Abrahão, S., Palanque, P. & Selic, B.) _ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion_ (IEEE, 2023).  Human Factors in Modeling workshop (HuFaMo).
  * [29] Petre, M.  Cheng, B. H. C. & Pohl, K. (eds) _Uml in practice_.  (eds Cheng, B. H. C. & Pohl, K.) _Proceedings of the 2013 International Conference on Software Engineering_ , ICSE ’13, 722–731 (IEEE, 2013).
  * [30] Mussbacher, G. _et al._ Dingel, J., Schulte, W., Ramos, I., Abrahão, S. & Insfran, E. (eds) _The relevance of model-driven engineering thirty years from now_.  (eds Dingel, J., Schulte, W., Ramos, I., Abrahão, S. & Insfran, E.) _Model-Driven Engineering Languages and Systems_ , 183–200 (Springer International Publishing, 2014).
  * [31] Hall, E. T.  _Beyond culture_ (Anchor, 1976).
  * [32] Medel, P. & Pournaghshband, V.  Caspersen, M. E., Edwards, S. H., Barnes, T. & Garcia, D. D. (eds) _Eliminating gender bias in computer science education materials_.  (eds Caspersen, M. E., Edwards, S. H., Barnes, T. & Garcia, D. D.) _Proceedings of the 2017 ACM SIGCSE technical symposium on computer science education_ , 411–416 (2017).
  * [33] Baltes, S. & Diehl, S.  Leavens, G. T., Garcia, A. & Păsăreanu, C. S. (eds) _Towards a theory of software development expertise_.  (eds Leavens, G. T., Garcia, A. & Păsăreanu, C. S.) _Proceedings of the 2018 26th acm joint meeting on european software engineering conference and symposium on the foundations of software engineering_ , 187–200 (2018).
  * [34] Catolino, G., Palomba, F., Tamburri, D. A., Serebrenik, A. & Ferrucci, F.  Kazman, R. & Pasquale, L. (eds) _Gender diversity and women in software teams: How do they affect community smells?_ (eds Kazman, R. & Pasquale, L.) _2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Society (ICSE-SEIS)_ , 11–20 (IEEE, 2019).
  * [35] Nunes, I., Moreira, A. & Araujo, J.  Gire: Gender-inclusive requirements engineering.  _Data & Knowledge Engineering_ 143, 102108 (2023).
  * [36] Vrieler, T., Nylén, A. & Cajander, Å.  Computer science club for girls and boys–a survey study on gender differences.  _Computer Science Education_ 31, 431–461 (2021).
  * [37] Baron-Cohen, S. & Belmonte, M. K.  Autism: a window onto the development of the social and the analytic brain.  _Annu. Rev. Neurosci._ 28, 109–126 (2005).
  * [38] David, I. _et al._ Blended modeling in commercial and open-source model-driven software engineering tools: A systematic study.  _Software and Systems Modeling_ 22, 415–447 (2023).
  * [39] Schwartz, S. H.  An overview of the schwartz theory of basic values.  _Online readings in Psychology and Culture_ 2, 11 (2012).
  * [40] Stikkolorum, D. R.  _Studies into interactive didactic approaches for learning software design using UML_.  Ph.D. thesis, Leiden University (2022).
  * [41] Easterbrook, S.  Lethbridge, T., Cabot, J. & Egyed, A. (eds) _Modelling the climate system: Is model-based science like model-based engineering?(keynote)_.  (eds Lethbridge, T., Cabot, J. & Egyed, A.) _2015 ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS)_ , 1–1 (IEEE, 2015).
  * [42] Blair, G.  Baudry, B., Combemale, B., Kienzle, J. & Pretschner, A. (eds) _Grand challenges, grand responses?(keynote)_.  (eds Baudry, B., Combemale, B., Kienzle, J. & Pretschner, A.) _2016 ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems (MODELS)_ (ACM, 2016).