InTra: A Pragmatic Approach of Using Rule-Based Model

Transformation to Reduce Complexity of UML and SysML Models

Philippe Barbie, Martin Becker and Andreas Sch

afer

Fraunhofer IESE, Fraunhofer-Platz 1, 67663, Kaiserslautern, Germany

Keywords:

Model Transformation, Interaction-Based Transformation, Rule-Based-Modelling, Interaction-Patterns,

Complexity, MBSE, SysML, UML.

Abstract:

While UML and SysML are important concepts for digitally representing complex systems, we are still con-

fronted with the problems of comprehensibility and maintainability. Even models with comparatively few

elements can quickly become confusing and hard to read, due to their relationship density. This leads to

potential errors, both for the initial modelling and the later model evolution and evaluation phase. Driven

by the needs of a large-scale modelling project in the ﬁeld of communication systems, we have researched

approaches to cope with the inherent model complexity by following a modelling approach, that is based on

interaction patterns. In this paper, we will give an introduction to the challenge of the consistently increasing

complexity of system models in the ﬁeld of model-based systems engineering (MBSE). We will motivate our

need for rule-based modelling in order to handle a real industry use case and outline the problems of system

modeling, which could be solved by using a new rule-based modelling approach. InTra (Interaction-based

Transformation) is an approach to signiﬁcantly reduce the complexity of a system model, by reducing the

number of connectors through the use of interaction rules. By doing so, we were able to create an abstracted

variant of the same system model, but with a highly reduced number of connectors used and thus an overall

reduced model complexity.

1 INTRODUCTION

The complexity of modern systems and the associ-

ated modelling effort is steadily increasing (Antinyan,

2020) (Warrilow, 2020) (Baduel, 2018) (St

utzel,

2021). In a survey with 127 participants in 14

companies conducted in 2001, 84% of the partici-

pants answered the question ’What motivates your

company to introduce systems engineering?’ with

the reason of constantly increasing product com-

plexity (St

utzel, 2021). It is inspiring to observe

that both David Long and Baduel et al. mention

the particular need for improvement in modelling

methodology to cope with the growing complexity

of future system models (Warrilow, 2020) (Baduel,

2018). Since the early 2000’s, a variety of dif-

ferent transformation approaches have been devel-

oped. While many of those approaches have their

focus on transforming system or software models

into executable code, there are also some languages

that concentrate on model-to-model transformation.

Some of the more popular approaches are, e.g.

PROGRES (RWTH Aachen, 2021), AGG (Taentzer,

2003), AToM

(McGill, 2021), GReAT (Balasub-

ramanian, 2006) (ISIS, 2021), GROOVE (Twente,

2021), BOTL (Braun, 2003) and Fujaba (Fujaba De-

velopment Group, 2021), even though some of them

are not developed any further (Kahani, 2019) (Sch

urr,

2021).

In this paper we will investigate whether it is pos-

sible to use a model transformation approach to sig-

niﬁcantly reduce the complexity of system models,

by transforming them into a rule-based representa-

tion. We developed a speciﬁc rule-based model trans-

formation approach called InTra (Interaction-based

Transformation), based on the problems introduced

by a real industrial communication system, with over

5,000 user roles and over 9,000 communication rela-

tionships. This approach has the goal to decrease a

system’s complexity, by reducing it to its basic struc-

ture and combining it with applicable relationship pat-

terns, thus decreasing the number of connectors in the

resulting model by an order of magnitude. Having a

large industry-related model, based on realistic data,

was especially useful when developing the approach

and testing its feasibility. To the best of our knowl-

edge, this is the ﬁrst approach that uses model-to-

model transformation techniques to reduce a model’s

Barbie, P., Becker, M. and Schäfer, A.

InTra: A Pragmatic Approach of Using Rule-Based Model Transformation to Reduce Complexity of UML and SysML Models.

DOI: 10.5220/0011615600003402

In Proceedings of the 11th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2023), pages 97-104

ISBN: 978-989-758-633-0; ISSN: 2184-4348

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

Figure 1: Notation of a transformation rule for graph models, according to (Varr

o, 2007).

information complexity. In this case, model transfor-

mation is not used, to transform the model into a dif-

ferent state of development, but to transform between

different representations of the same model state.

The paper is structured as follows. Section 2 of-

fers a general overview of the ﬁeld of graph-based

model transformation. Section 3 describes the in-

dustrial setting in which we developed and tested the

InTra approach. Section 4 elaborates the problems,

which led us into the development of a rule-based

model transformation approach. Section 5 explains

the InTra approach in general and why model trans-

formation is a necessary part of it. Section 6 will

present the basic functionality and application of In-

Tra, based on a simple family tree example model.

Section 7 explains InTra’s own model transformation

language, which is completely based on model ele-

ments itself. Section 8 describes the experiences and

results that were achieved in the given industrial set-

ting from Section 3. Section 9 reviews relevant ex-

isting work in the ﬁeld, e.g. work that helped us to

derive necessary requirements for the development of

a model transformation approach. Finally Section 10

concludes the paper.

2 TRANSFORMATION OF

GRAPH-MODELS

While models exist in many different forms, such as

relational databases or text-based structures, in this

paper the scope will be centered around the transfor-

mation of graph models. Graphs are powerful data

structures that are able to represent interactions be-

tween system components in an easily comprehensi-

ble way. Essentially, any system that consists of com-

ponents with relations may be naturally described by

a graph in which the vertices represent the entities and

the edges represent the relations (Ghamarian, 2011).

A transformation rule for graph models usually con-

sists of two parts: Pattern-Matching and Rewriting

(Wieber, 2015).

Pattern Matching describes the structure of the pat-

tern, which is to be searched in the model. At all

places where a given subgraph is found that matches

the pattern, a transformation can take place. This ﬁrst

section of a transformation rule is also called ’Left-

hand-side (LHS)’ (Wieber, 2015) (Czarnecki, 2006).

Rewriting, the second part of a transformation rule

describes the ﬁnal state, which has to be realized on

all found pattern matching subgraphs. This part of

the transformation rule is also called ’Right-hand-side

(RHS)’ (Wieber, 2015) (Czarnecki, 2006).

In the example shown in Figure 1, taken from

(Varr

o, 2007), the LHS deﬁnes a class CS, which is

a child of a class CP, which has an attribute relation-

ship to attribute A. The RHS of the interaction rule

shows as a result of an applied model transformation,

a deleted relationship between class CS and attribute

A and the creation of a new relationship between the

child class CP and attribute A.

3 INDUSTRIAL CONTEXT

In a previous industry project, we had to model an ar-

chitecture representing a communication system with

over 5,000 user roles to capture individual require-

ments of those user roles and their communication.

The basic procedure was to model each user-role in

each scenario and map the communication between

those user roles via information exchange relation-

ships. Each of those information exchange relation-

ships contains at least one piece of information. Since

this is not comprehensibly representable without any

system structure, the user roles were grouped accord-

ing to their communication hierarchies. This included

further reﬁnements in subgroups, as well as the map-

ping in superiors and subordinate user roles. Nev-

ertheless, there was an average of three information

exchanges per user-role in each communication sce-

nario. One of the technical requirements for the sys-

tem, which was set by the customer, was to use the

well established modelling tool Enterprise Architect

by Sparx Systems. As source of information, more

than 50 domain experts were interviewed and asked

what communication relationships exist in their spe-

ciﬁc working environment. The information collected

had to be modelled into the system context, attributed,

managed and delivered back for review. Even though

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

the information was available inside the model, it was

difﬁcult and time-consuming to comprehend, verify,

and maintain the resulting system. As a result, even

subject matter experts had major problems in under-

standing the communication relationships they should

be already familiar with. Furthermore it was an es-

sential requirement, that the resulting model diagrams

could also be well understood by those who are not fa-

miliar with MBSE and system architectures. Unfortu-

nately, for reasons of conﬁdentiality, the correspond-

ing system model and its contents cannot be made

available to the readership within this paper.

4 PROBLEM STATEMENT

It can be observed that the technological barriers are

not posing the greatest problem in here, but rather

those of human cognitive perception. Mapping the

structure and interrelationships of complex systems

as a digital model is a major challenge. To be able

to comprehend, understand and maintain what is rep-

resented beyond that, is an even greater task. Of

course, UML and SysML offer a variety of methods

to decompose the system to reach lower complexity.

On the other hand, even using the best decomposi-

tion, you eventually reach the point where you need

to represent the relations between the system com-

ponents in the model. Normally this is done using

elements and connectors, but even with just a few el-

ements, this may mean a large number of information

ﬂows on a single diagram. Yet, it is the understand-

ing of this connector-representation between system

elements, that is a major cognitive challenge for the

human brain (Koning, 2002).

In the study User preference of graph layout aes-

thetics: a UML study (Purchase, 2000) on the bet-

ter comprehensibility of UML diagrams, 93% of the

participants stated that crossing connectors in the di-

agram are an enormous obstacle to comprehensibil-

ity. 91% testiﬁed that bends in the connectors were

a major barrier. These were the two most frequently

mentioned comprehension barriers in the study.

In order to solve the problems mentioned above

and to counteract the challenge of increasing com-

plexity in system models, we will elaborate our ap-

proach named InTra (Interaction-based Transforma-

tion), which signiﬁcantly reduces the number of con-

nectors in the model, but at the same time preserves

their information content in a comprehensible way.

5 InTra APPROACH

The approach introduced in this article is designed to

signiﬁcantly reduce the complexity of a system model

with the help of individual interaction rules that work

on the basic system structure. In this way it is pos-

sible to reduce the number of connectors even during

the initial modelling phase, thus keeping the resulting

model complexity small, which in turn improves the

readability and maintainability. The term ’rule-based’

describes the idea of recognizing repeating interaction

patterns in the basic structure of the model, and the

deﬁnition of rules for those patterns, which describe

the interaction concept behind those relationships. By

including these rules, it is no longer necessary to store

the said relations by connectors in the model. The

creation of a rule is useful, if an interaction between

certain element types or constellations always runs in

the same way. Although in this rule-based form it is

a lot harder to evaluate the model with simulations or

programs, it is fully completed and understandable in

its rule-based abstracted form. This means, that all

information of the relations to be captured is already

mapped in the model, partly abstracted as interaction

rules to be interpreted. By expressing this information

as rules, the representation of the model is changed,

but its information content remains the same. Avoid-

ing the redundancy of information in this way also

reduces the risk of errors in the further processing of

the model, since changes only need to be made to one

rule instead of all the connectors that a single rule rep-

resents. Furthermore, the usage of interaction rules

makes the model easier to understand for domain ex-

perts. This is the case because domain-speciﬁc inter-

actions can be represented very efﬁciently and com-

prehensibly as interaction rules. Nevertheless, an ex-

perienced system architect should be responsible for

identifying the basic structure of the system, recog-

nizing repetitive patterns in the relationships between

model elements, deﬁning and conﬁguring interaction

rules for those patterns, and ﬁnally linking them to the

relevant parts of the system’s basic structure.

In an optional second phase of model transforma-

tion, the deﬁned interaction rules are able to trans-

form the model into a rule-independent version, suit-

able for data usage through e.g. simulations, by us-

ing the automatic model transformation algorithm of

InTra. Therefore linked interaction rules are parsed

by the algorithm, to deﬁne active ﬁlters for the pattern

matching of the target model. Pattern matching will

then ﬁnd valid interaction paths inside the model and

apply the deﬁned rewriting effects between all start

and endpoints of those found paths. Even though the

rule-based version of the model is fully expressive, we

InTra: A Pragmatic Approach of Using Rule-Based Model Transformation to Reduce Complexity of UML and SysML Models

Figure 2: Extended family tree model with multiple incorporated relationship types.

need a way to (back-)convert the model to the tradi-

tional representation, as a backbone for our method-

ology. Furthermore, the transformation into indepen-

dent relations can help modelers to understand the

statement of a complex interaction rule and makes the

model readable again for simulations and other exter-

nal programs. For this reason we use model trans-

formation techniques to be able to switch between

rule-based and rule-independent representation of the

model.

6 APPLICATION SHOWCASE

An illustrative example, although not productively us-

able, is a family tree as presented in Figure 2, which

shall serve as an example to visualize the InTra ap-

proach. A family tree is a good way to explain the

idea of InTra, because we already use the concepts

of rule-based modelling subconsciously when think-

ing about family trees. The shown tree model consists

of actors (elements), their gender (attributes), and the

relationships between family members (connectors).

As you can see, the model in Figure 2 shows sev-

eral family relations in only one diagram. Normally,

in a family tree we would expect exclusively Child

connectors, and we would still be able to read other

family relations from the model subconsciously. This

cognitive concept is very similar to rule-based InTra

approach. By using interaction rules to embed infor-

mation into a model, that can be abstracted from ex-

isting information, we are able to reduce the model to

its relevant basic system structure. In this case it is

sufﬁcient to only keep the Child relations, as we are

used to from regular family trees, to be able to repre-

sent all other relationships with the help of rules.

For easier explanation we will concentrate on only

a small part of the given family tree, which can be

seen in Figure 3. Based on the here shown Child

relations, which are part of the model’s basic struc-

ture, we will build interaction rules that represent all

other visible connectors. For example, each male or

female source element of a Child relation is a fa-

ther or a mother of the target element of that rela-

tion, respectively. To replace this kind of relation

with an interaction-rule, such rule must be deﬁned to

search for incoming Child connectors for each pos-

sible element and follow that connector exactly one

hop against its direction. Thereupon, the found par-

ent element must be distinguished between male (M)

or female (W), respecting the gender attribute (SEX ), in

order to then represent any Father or Mother rela-

tion in the model. Once these two rules are associated

with the family tree model, all Mother, and Father

connectors can be removed from the model without

deleting their information content.

Another, only slightly more complex example are

the grandparent relationships. For this purpose the

above described rules need to be modiﬁed only mini-

mally. Instead of following only one Child connector

from target to source, the rule must follow exactly two

Child connectors (two hops) in a row. The genders

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

100

Figure 3: Small excerpt of the family tree shown in Figure 2.

of the intermediate steps are irrelevant for the eval-

uation of the current rules. Thereupon, the distinc-

tion between female and male works exactly as for

the Mother and Father rule and replaces all relations

Grandmother and Grandfather respectively.

Table 1: Overview of the number of connectors replaced by

interaction rules in the family tree model.

Interaction-Rule Replaced connectors

Daughter Rule 26

Son Rule 24

Mother Rule 25

Father Rule 25

Sister Rule 34

Brother Rule 28

Grandmother Rule 33

Grandfather Rule 33

Granddaughter Rule 30

Grandson Rule 36

Aunt Rule 15

Uncle Rule 17

Niece Rule 21

Nephew Rule 11

Sum 358

By using this approach in the example model from

Figure 3, this model will result in only containing ac-

tors and Child connectors. Thus only 6 of the 16 con-

nectors shown in Figure 3 are still part of the model,

which is a reduction of 62.5%. However, the infor-

mation content of the other 10 connectors is not lost,

but merely abstracted in the form of interaction rules.

With increasing number of elements and connectors

in the model, interaction rules are a powerful tool to

reduce the overall complexity, since a single rule can

replace a large number of relations, and still remain

comprehensible and maintainable.

Applying the InTra approach in the same way to

the large family tree from Figure 2, using interac-

tion rules for all family relationships Daughter, Son,

Mother, Father, Sister, Brother, Grandmother,

Grandfather, Granddaughter, Grandson, Aunt,

Uncle, Niece and Nephew leads to even clearer re-

sults. Table 1 gives an overview about how many

connectors could be replaced by each of the 14 in-

teraction rules in the family tree example from Figure

2. A total of 358 connectors could be abstracted by

rules. This leaves 50 child relations, from which all

other connections can be derived through model trans-

formation. This corresponds to a reduction of 87%

of connectors in the family tree model from Figure

2. Nevertheless, this approach can be productively

applied to other system models with greater practical

relevance but similar reduction potential.

7 RULE DEFINITION

InTra was implemented as an addin for the modelling

tool Enterprise Architect and was programmed in C#.

With the help of this plug-in it is possible to use the

InTra: A Pragmatic Approach of Using Rule-Based Model Transformation to Reduce Complexity of UML and SysML Models

101

Figure 4: InTra RuleConfiguration: Mother.

proposed approach directly inside Enterprise Archi-

tect, without the need of additional tools or program-

ming knowledge.

As presented in Figure 4, interaction rules in In-

Tra are deﬁned as model elements themselves, and

thus become part of the model in which they are used.

The shown rule consists of a RuleConfiguration,

which holds the rule’s Name and HopCount, a Pat-

tern Matching (Left-Hand-Side) area and a Rewrit-

ing (Right-Hand-Side) area. The names chosen for

these parts of a rule follow the common practice

of several authors, including (Varr

o, 2007), (Wieber,

2015) and (Kahani, 2019), among others. In con-

trast to the representation of LHS and RHS in Fig-

ure 1 from (Varr

o, 2007), InTra does not use a di-

rect subgraph representation for rule deﬁnition, but

rather deﬁnes LHS and RHS with the help of in-

teraction rules, by using diagram-based interaction

constraints for both vertices and edges of the target

model. The Pattern Matching area deﬁnes condi-

tions which need to be fulﬁlled by elements (deﬁned

as WayPoint conditions) and connectors (deﬁned as

LinkConfiguration conditions), respectively, to de-

ﬁne a certain pattern of interaction and thus ﬁnd a

set of valid interaction paths in the linked model seg-

ment. The Rewriting area describes the modiﬁcations

that are made to the model if a valid interaction path

is found and model transformation shall be executed.

Rewriting effects can be the creation or the removal

of certain kind of connectors between a start and end

WayPoint of a found interaction path. For the deﬁ-

nition of ﬁlter conditions the element’s and connec-

tor’s attributes Name, Alias, EA-Type, Stereotype,

minimal Multiplicity, maximal Multiplicity,

Embedment and any kind of Tagged Value can be

analysed. Therefore the values of those attributes can

be compared by direct text comparison, regular ex-

pressions and numeric comparison operators like <,

<=, >, >=, == and ><, formulated as Tagged Value of

a WayPoint or a LinkConfiguration. To deﬁne a

Pattern Matching for possible interaction paths in the

model, the mentioned conditions are connected with

the core of the rule by the connectors From, Over, To

and RelatedBy. A valid interaction path must be-

gin with an element conforming to a From WayPoint,

be linked to other elements by connectors conform-

ing to a RelatedBy LinkConfiguration, end in a

element conforming to a To WayPoint and must be

connected to exactly (HopCount-1) elements in be-

tween, which are conforming to a Over WayPoint.

Multiple WayPoints or LinkConfigurations of the

same type will result in a logical OR for that spe-

ciﬁc condition pattern. While the rule shown in Fig-

ure 4 represents the most basic form of an inter-

action rule, a so called RuleConfiguration, there

is also the possibility to combine several of these

rather simple rules in a more complex rule, a so

called RuleChain. Thus, RuleConfigurations can

be thought of as atomic rule pieces that can be as-

sembled into a more complex RuleChain. Rules can

therefore be decomposed and offer high reusability.

An example RuleChain for the family model from

Figure 2 is the Sister rule shown in Figure 5. The

rule evaluation of a RuleChain always starts with a

RuleChainStart element. From there on, the con-

tained RuleConfigurations are executed one after

another (AppendRule), until a RuleChainEnd ele-

ment is reached. Each interaction path found by a

RuleConfiguration is thereby extended by the next

RuleConfiguration in the chain, by passing all To

WayPoints of one rule to the next one as possible

From WayPoints. The resulting interaction path of a

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

102

RuleChain thus consists of start elements of the ﬁrst,

and end elements of the last rule of the chain. Thus,

it is certainly not a successive execution of transfor-

mation rules, but rather a narrowing down of the so-

lution space, based on conditions that sequentially

build upon each other. Each RuleChain deﬁnes its

own effects and reductions as LinkConfigurations,

which are linked to the endpoint of the chain anal-

ogous to a RuleConfiguration, using an Effect

or Reduction connector. In our Example from Fig-

ure 5 initially the Parent RuleConfiguration is

evaluated, which identiﬁes the parents of a person.

Then, these elements are passed as potential From

WayPoints of the Daughter RuleConfiguration.

Evaluating this rule ﬁnds all daughters of a person,

and in this particular case all daughters of a person

who is parent of a different person. So, in summary,

the two rules in succession ﬁnd all daughters of all

parents of a person, which corresponds to all sisters

of that person. Some attentive readers may wonder

at this point what happens if the source element itself

is female. If the source element itself is female, it is

correctly not identiﬁed as a sister of herself, because

connectors that have already been visited by one of

the RuleConfigurations are not visited again dur-

ing Pattern Matching of a RuleChain. For this rea-

son, it is also impossible to get caught in cycles dur-

ing the model transformation. The fact that interac-

tion rules themselves are also deﬁned as model el-

ements has the additional advantage that interaction

rules themselves can also be transformed via other In-

Tra rules. Due to this property InTra rules can be seen

as rules of higher order (Mens, 2006).

Figure 5: InTra RuleChain: Sister.

8 INDUSTRIAL APPLICATION

RESULTS

In the communication model introduced in Section 3,

the InTra approach could be successfully applied to

abstract the communication relationships in multiple

views of the model, thus highly reducing the com-

plexity of the system. This has proven to be extremely

helpful, especially with regard to the readability and

maintainability of the model. By building 128 in-

teraction rules and creating 255 links between rules

and parts of the model, the number of information ex-

changes in the model could be reduced from 9,355

to 2,615. This is a reduction of 72 %. Therefore, it

could be proven, that the InTra approach is able to

be applied lucratively in realistic, productive systems

and model environments. Furthermore, it was possi-

ble to explain the contents of the model to the domain

experts more easily with the help of interaction rules.

Subsequently, we received feedback from the future

model users, that they perceived the new approach to

be comprehensible and helpful.

9 RELATED WORK

In preparation for the development of the InTra ap-

proach, the current state of the art on the topic was ex-

amined, whereby it was necessary to ﬁnd out, which

generic requirements a transformation approach must

fulﬁll in order to be considered suitable. These re-

quirements were identiﬁed based on the taxonomies

and comparative characteristics of the contributions

of (Czarnecki, 2006), (Ghamarian, 2011), (Kahani,

2019) and (Mens, 2006). All listed works offered the

possibility of identifying important criteria regarding

the requirements for rule-creation, model transforma-

tion and general usability of the approach, but espe-

cially (Czarnecki, 2006) and (Czarnecki, 2002) pro-

vided a majority of useful properties and were able

to give a good view on existing model transformation

approaches. They also provided their ﬁndings based

on a feature diagram according to (Kang, 1990) in a

structured and comprehensible way. (Kahani, 2019)

and (Varr

o, 2007) give an excellent introduction into

the ﬁeld of graph-based model transformation. Both

(Valiente, 1997) and (McCreesh, 2020) are dealing

with the challenge of the NP-complete complexity of

the subgraph-isomorphism problem, which describes

the usual run-time limit for the Pattern Matching in

traditional model transformation approaches.

InTra: A Pragmatic Approach of Using Rule-Based Model Transformation to Reduce Complexity of UML and SysML Models

103

10 CONCLUSION

In this paper we investigated the usage of model

transformation techniques to reduce the complexity

of large system models, to improve the usability

and comprehensibility. We elaborated on the com-

mon problems of system modeling, gave an overview

about the ﬁeld of graph-based model transformation,

introduced our own rule-based model transformation

approach InTra, described how rules can be deﬁned

and applied and gave an example of the results that

can be expected by using the approach in large system

models. We also highlighted the advantages of the

approach and how it can be used to tackle the prob-

lems that may arise in large models. We were able to

successfully use the approach in the industrial setting

described in Section 3, and presented our results and

experiences in Section 8. As application showcase we

presented a family tree model in which arbitrary fam-

ily relations could be derived using the existing child

relations and the given basic structure of the model.

We were able to show that the approach in this ex-

ample was well suited to reduce the system complex-

ity without affecting the information content of the

model. The InTra rule-based modelling approach has

the potential to make the growing complexity of to-

day’s system models more manageable, comprehen-

sible and maintainable through the use of rules.

However, it is primarily necessary to identify fur-

ther real industry scenarios, similar to the one from

Section 3, in order to further test the approach for

its abilities in real world scenarios. Potential cases

should primarily have a clear basic system structure

and reoccurring relation patterns. Likewise, the mod-

els should be quite large, in order to justify a rule-

based reduction of connectors. Case studies based on

further practical application could be used to inves-

tigate and enhance the InTra approach. In addition,

it is necessary to investigate with further empirical

studies, if a reduction in the number of connectors

actually leads to a reduction in complexity in terms

of human perception, and whether interaction rules

are truly more comprehensible for the viewer than

the sum of connectors they replace. Nevertheless, it

should be considered that domain experts and sys-

tem architects will perceive models in different ways,

which could lead to diverging results.

REFERENCES

Antinyan, V. (2020). Revealing the Complexity of Automo-

tive Software. Volvo Car Group.

Baduel, R. (2018). SysML Models Veriﬁcation and Valida-

tion in an Industrial Context: Challenges and Experi-

mentation.

Balasubramanian, D. (2006). The Graph Rewriting and

Transformation Language: GReAT.

Braun, P. (2003). BOTL The Bidirectional Object Oriented

Transformation Language.

Czarnecki, K. (2002). Classiﬁcation of Model Transforma-

tion Approaches.

Czarnecki, K. (2006). Feature-Based Survey of Model

Transformation Approaches.

Fujaba Development Group (2021). Fujaba Tool Website.

https://web.cs.upb.de/archive/fujaba/. Website Uni-

versity of Paderborn.

Ghamarian, A. H. (2011). Modelling and analysis using

GROOVE.

ISIS (2021). GReAT Tool Website. https://www.isis.

vanderbilt.edu/tools/GReAT.

Kahani, N. (2019). Survey and classiﬁcation of model trans-

formation tools.

Kang, K. C. (1990). Feature-Oriented Domain Analysis

(FODA) Feasibility Study.

Koning, H. (2002). Practical Guidelines for the Readability

of IT-architecture Diagrams.

McCreesh, C. (2020). The Glasgow Subgraph Solver: Us-

ing Constraint Programming to Tackle Hard Subgraph

Isomorphism Problem Variants.

McGill (2021). AToM3 Introduction Website. McGill Uni-

versity.

Mens, T. (2006). A Taxonomy of Model Transformation.

Purchase, H. C. (2000). User Preference of Graph Layout

Aesthetics: A UML Study.

RWTH Aachen (2021). PROGRES Tool Website. http://

www-i3.informatik.rwth-aachen.de.

Sch

urr, A. (2021). PROGRES - A Graph Transfor-

mation Programming Environment. https://www.es.

tu-darmstadt.de/.

utzel, B. (2021). Systems Engineering in Deutschland -

Die deutsche Unternehmenslandschaft im Vergleich.

Studie 2021 — Publisher: Prozesswerk GmbH.

Taentzer, G. (2003). AGG: A Graph Transformation Envi-

ronment for Modeling and Validation of Software.

Twente (2021). GROOVE Tool Website. https://groove.ewi.

utwente.nl/about. Twente University.

Valiente, G. (1997). An algorithm for graph pattern-

matching.

Varr

o, D. (2007). The model transformation language of the

VIATRA2 framework.

Warrilow, R. (2020). Lost in Translation? – How MBSE is

Evolving to address Today’s Complexity Challenges.

Wieber, M. S. (2015). Qualit

atssicherung von Modelltrans-

formationen -

Uber das dynamische Testen program-

mierter Graphersetzungssysteme.

MODELSWARD 2023 - 11th International Conference on Model-Based Software and Systems Engineering

104