TranspLanMeta: A Metamodel for TranspLan Modeling Language
Deniz Cetinkaya
1 a
and Mahmood Hosseini
2
1
Department of Computing & Informatics, Bournemouth University, Poole, U.K.
2
JPMorgan and Chase, Bournemouth, U.K.
Keywords:
Requirements Engineering, Transparency Requirements, Requirements Modeling, Transparency, TranspLan,
Metamodeling, Domain-specific Modeling.
Abstract:
Transparency and transparent decision making are essential requirements in information systems. To this end,
a modeling language called TranspLan has been proposed. TranspLan is a domain-specific modeling lan-
guage which is designed for the purpose of analysing and modeling transparency requirements in information
systems. This paper presents a metamodel for transparency requirements modeling. We are introducing a
model-driven approach to TranspLan language specifications to facilitate the use of the language more effi-
ciently in real life cases. Metamodeling is an effective method for formally defining domain specific languages
and moving from specifications to computer-aided modeling. In this paper, we propose a metamodel for Trans-
pLan modeling language which is called as TranspLanMeta. The metamodeling process helps us to transfer
TranspLan language specifications into a machine-readable format. The metamodel has been developed with
GME (Generic Modelling Environment), which is a configurable toolkit for creating domain-specific modeling
and program synthesis environments. By developing TranspLanMeta with GME, an automatically-generated
modeling tool for TranspLan language is provided as well. In this way, an effective approach for accelerating
software development is followed and the auto-generated modeling editor is used to define various models.
This work provides a formal and practical solution for transparency modeling and a well-defined basis for
using transparency requirements models in the further steps of the business process.
1 INTRODUCTION
Transparency and transparent decision making are be-
coming one of the important non-functional require-
ments in information systems. In the light of new
transparency rules and regulations, the need for tools
and languages that enable transparency modeling is
increasing. TranspLan is a domain-specific model-
ing language which is designed for analysing and
modeling transparency requirements in information
systems (Hosseini, 2016). The language was orig-
inally defined as a set of specifications without any
tool support. Introducing a metamodel and tool sup-
port for TranspLan will open new ways for its usage
and practicality. Hence, we are introducing a model-
driven development (MDD) approach to TranspLan
language specifications to facilitate the use of the lan-
guage more efficiently in real-life cases in this paper.
MDD is a software development approach which
aims to face the challenges of software development
process through representing the essential aspects of
a
https://orcid.org/0000-0002-1047-0685
a system as models and generating the final source
code from these models (semi-)automatically (Ro-
drigues da Silva, 2015; Sommerville, 2016). In
MDD literature, the most common method to define
modeling languages is metamodeling. Metamodel-
ing is an effective and practical approach for defin-
ing domain-specific modeling languages. Model-
driven approaches in software and systems engineer-
ing use well-defined modeling languages to specify
models and apply model transformations to automat-
ically generate new models or source code from an
initial design model (Cetinkaya et al., 2015).
In this paper, we propose a metamodel for Trans-
pLan modeling language. The metamodel has been
developed with GME (Generic Modelling Environ-
ment), a configurable toolkit for creating domain-
specific modeling and program synthesis environ-
ments. A modeling editor for transparency model-
ing is automatically generated and configured by us-
ing the metamodel. In this way, an effective approach
for developing a computer-aided, formal and practical
solution for transparency modeling is followed and
Cetinkaya, D. and Hosseini, M.
TranspLanMeta: A Metamodel for TranspLan Modeling Language.
DOI: 10.5220/0010202201470154
In Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2021), pages 147-154
ISBN: 978-989-758-487-9
Copyright
c
 2021 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
147

the auto-generated modeling editor is used to define
various models. As an example, a sample model for
defining transparency requirements for an email ser-
vice provider is shown in this paper. This work helped
us to transfer TranspLan language specifications into
a machine-readable format and it provided a sound
basis for using transparency requirements models in
the further steps of the business process.
The paper is structured as follows: Section 2 in-
troduces TranspLan modeling language. Section 3
presents the metamodel for TranspLan, which we call
TranspLanMeta. Section 4 explains a case example.
Section 5 discusses the benefits and challenges of this
work. Finally, Section 6 presents the conclusions and
the future work.
2 TranspLan: A TRANSPARENCY
MODELING LANGUAGE
TranspLan is a domain-specific modeling language
for the identification, capturing, and analysis of trans-
parency requirements of stakeholders in an informa-
tion system. The design of TranspLan is based on
four proposed transparency reference models (Hos-
seini et al., 2017) as below:
1. Transparency Actors Wheel: which illustrates
transparency stakeholders and the information
flow between them
2. Transparency Depth Pyramid: which illustrates
the depth and meaningfulness of information
3. Transparency Achievement Spectrum: which
illustrates the steps necessary to achieve a useful
transparency
4. Transparency Information Quality: which il-
lustrates the information quality dimensions for
transparency provision
These reference models are in turn based on an
extensive literature study on transparency in different
fields of study such as politics, economy, and journal-
ism (Hosseini, 2016). TranspLan, as a modeling lan-
guage, was first proposed in (Hosseini et al., 2016).
Then, another study was made on TranspLan and its
evaluation, which was later published in (Hosseini
et al., 2018). This study also tweaked the modeling
language, and more specifically, its visual diagram,
for a better and clearer visual and semantic represen-
tation.
TranspLan consists of StakeHolders’ Informa-
tion Exchange Layout Diagram (also called Shield
diagram) for the visual representation of informa-
tion exchanges amongst stakeholders and their trans-
parency requirements. TranspLan is also accompa-
nied by two descriptive specification models for in-
formation elements and stakeholders, called INFOr-
mation eLEment Transparency Specification (also
called Infolet specification) and Stakeholders’ In-
formation Transparency REQuirements Specification
(also called Sitreq specification), respectively. These
specification models explain the information elements
and the stakeholders with their elicited transparency
requirements in the Shield diagram.
2.1 Modeling Constituents and
Representations
The TranspLan language is mainly built based on
three different constituents: stakeholders, informa-
tion elements, and the relationships between stake-
holders and information elements. Relationships can
be decomposed using decomposition relations. An
Information Exchange (IEX) is a combination of all
these constituents and illustrates the flow of infor-
mation amongst different stakeholders. These con-
stituents are described as follows.
• Stakeholders are the people, departments, organ-
isations, etc., which are involved in providing, re-
ceiving, or requesting transparency in any infor-
mation exchange amongst stakeholders. When
categorising stakeholders, they are commonly
represented as one entity, e.g., Student or Finance
Department. However, the exchanged informa-
tion within an information exchange system may
concern all the stakeholders within that system
(referred to as All in TranspLan), and it may also
concern the public audience.
• Information elements are pieces of information
exchanged amongst stakeholders. Stakeholders’
transparency requirements affect the way infor-
mation elements should be formed and presented
to other stakeholders. An Information Element
(IE) has a type, which is related to their trans-
parency meaningfulness. These types can be data
type, process type, or policy type. Examples of in-
formation elements are privacy policy statements,
mortgage documents, and application forms.
• Stakeholder-information relationships exist be-
tween stakeholders and information elements, and
they describe how the IE is associated with the
stakeholder. The production relationship denotes
that the stakeholder produces the IE for other
stakeholders. The obligation relationship denotes
that the stakeholder provides the IE based on co-
ercive supply or requests the IE based on legal de-
mands. The optionality relationship denotes that
MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development
148

the stakeholder provides the IE based on volun-
tary supply or requests the IE based on personal
demands. The restriction relationship denotes that
the IE should not be available to the stakeholder.
The undecidedness relationship denotes that the
relationship between the stakeholder and the IE is
not known or decided yet. For example, a bank
(i.e., the stakeholder) must provide a mortgage
guide (i.e., information element) to their customer
(i.e., the other stakeholder). Therefore, there will
be two relationships, one provision relationship
between the bank and the mortgage document and
one obligation document between the mortgage
document and the bank customer.
• Decomposition relations exist between relation-
ships and can be one of the following: AND rela-
tion, OR relation, and XOR (exclusive or) relation.
• Information exchanges illustrate the flow of in-
formation from an information provider to an in-
formation receiver or requester. For example, the
bank, their customer, and the mortgage document
together constitute an information exchange be-
tween these two stakeholders. An information ex-
change system is a collection of all information
exchanges in an information system.
2.2 TranspLan Mathematical Definition
The TranspLan language and its constituents can be
defined using the ordinary mathematical language as
follows:
[Information element] Let IE = {ie
1
,ie
2
,...,ie
m
}
be the set of information elements, and IE Label and
IE Name be sets of unique labels and names respec-
tively. Every ie
i
∈ IE can be defined as follows:
IE = {ie | ie = (ietype,ielabel,iename,ieused) ∧
ietype ∈ IE type ∧ ielabel ∈ IE label ∧ iename ∈
IE name ∧ ieused ⊂ ielabel}
IE type = {data, process, policy}
[Stakeholder] Let S = {s
1
,s
2
,...,s
n
} be the set of
stakeholders, IE = {ie
1
,ie
2
,...,ie
m
} be the set of in-
formation elements, and R = {r
1
,r
2
,...,r
l
} be the set
of stakeholder-information relationships. The set of
stakeholders and two subsets of S, called PS and RS,
can be defined as follows:
S = {s | s is a stakeholder}
PS = {s | s ∈ S ∧ ie ∈ IE ∧ (s,ie, production) ∈
R}
RS = {s | s ∈ S ∧ ie ∈ IE ∧ rt ∈
{obligatory,optional, restricted,undecided} ∧
(s,ie,rt) ∈ R}
[Stakeholder-information relationship] Let R =
{r
1
,r
2
,...,r
l
} be the set of relationships where each
relationship is between stakeholder s
i
∈ S and infor-
mation element ie
j
∈ IE. Every r
i
∈ R can be defined
as follows:
R = {r | r = (s, ie,rtype) ∧ s ∈ S ∧ ie ∈ IE ∧
rtype ∈ R type}
R type = {production,obligatory,optional,
restricted,undecided}
[Decomposition relation] Let Rel =
{rel
1
,rel
2
,...rel
k
} be the set of relations where
each relation is between two or more relationships
R
1
,R
2
,...,R
j
∈ R. Every Rel
i
∈ Rel can be defined as
follows:
Rel = {rel | rel = (r
1
,r
2
,..,r
j
,reltype) ∧
r
1
,r
2
,..,r
j
∈ R ∧ reltype ∈ Rel type}
Rel type = {and,or, xor}
[Information exchange] Let IEX =
{iex
1
,iex
2
,...,iex
t
} be the set of information
exchanges amongst stakeholders where one stake-
holder s ∈ PS produces some information elements
IESet ⊂ IE that is received or requested by a group of
other stakeholders RSSet ⊂ RS and s /∈ RSSet. Every
information exchange iex
i
can be defined as follows:
IEX = {iex | iex = ((s
i
,ie
i
,r
i
),(s
j
,ie
i
,r
j
)) ∧
s
i
∈ PS ∧ s
j
∈ RS ∧ r
i
= production ∧
(s
i
,ie
i
,r
i
),(s
j
,ie
i
,r
j
) ∈ R }
2.3 Shield Diagram
The Shield diagram is the graphical representation
of the TranspLan language. The constituents of the
TranspLan language can be illustrated in the Shield
diagram as follows.
2.3.1 Stakeholders
Stakeholders are captured in one of the four follow-
ing ways: (1) One stakeholder; (2) All stakeholders
within an information exchange system (for the pur-
pose of facilitating a more efficient, clutter-free visual
design); (3) All stakeholders further enriched by the
exclusion notation (for referring to those stakeholders
who are excluded from the information exchange); (4)
Public stakeholders (for referring to the public, i.e.,
all stakeholders inside and outside the information ex-
change system under study) (See Figure 1).
2.3.2 Information Elements
Information elements capture the type of IE (i.e., data,
process, and policy), a unique IE label, its name, and
a list of all the other IE tags which use, partly or com-
pletely, the current IE (See Figure 1).
TranspLanMeta: A Metamodel for TranspLan Modeling Language
149

Figure 1: Building blocks of Shield and their interpretations (Hosseini et al., 2018).
2.3.3 Stakeholder-information Relationships
Stakeholder-information relationships capture
whether the stakeholder is producing the information,
or receiving the information on an obligatory or
optional basis. They also capture currently unknown
relationships and restricted relationships. Arrows
are intentionally chosen to be dotted to emphasise
that information flow may or may not serve its
transparency purpose because its usefulness must
be decided through complicated procedures and
involvement with stakeholders (See Figure 1).
MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development
150

2.3.4 Decomposition Relations
Decomposition relations describe the relationship
amongst relationships and can be AND (the default
relation), OR, and XOR (See Figure 1).
2.3.5 Information Exchange System
An information exchange system captures the follow-
ing four parts: its name, its description and extra
notes, a list of all stakeholders in the information ex-
change system including two pre-defined All and Pub-
lic stakeholders, and all the information exchanges
amongst the stakeholders (See Figure 1).
3 TranspLanMeta: A
METAMODEL FOR TranspLan
LANGUAGE
TranspLan specification defines an efficient language
to represent transparency requirements. Its formal
definition provides a sound framework for transform-
ing the requirements into further models. Introducing
model-driven approaches and defining a metamodel
for TranspLan language will improve its usability. In
this section, we introduce a metamodel for the Trans-
pLan language given in Figure 2.
Metamodeling is the process of complete and pre-
cise specification of a modeling language in the form
of a metamodel (Cetinkaya et al., 2015). Once the
metamodel is defined, then it can be used to spec-
ify models in that language. Metamodeling envi-
ronments, sometimes called as domain-specific mod-
elling environments, provide powerful tools to define
metamodels as well as to develop modeling environ-
ments for those new modeling languages (Emerson
et al., 2008). A model is an abstraction of a system,
which shows the main properties of the system and
excludes unnecessary details, which in turn leads to
reducing the complexity of the system (Syriani et al.,
2013). A modeling language consists of an abstract
syntax, concrete syntax, and semantics (Atkinson and
K
¨
uhne, 2002; Cetinkaya et al., 2015).
The metamodel, namely TranspLanMeta, is de-
fined with GME (Generic Modelling Environment),
which is a configurable metamodeling toolkit for
defining domain-specific modeling languages and
creating modeling environments (Ledeczi et al., 2001;
Davis, 2003). In GME, metamodels are specified as
modeling paradigms that represents the application
domain. The metamodels contain all the syntactic
and semantic elements to construct the models with
domain specific concepts as well as the relationships
among those concepts. Besides, the rules for the com-
position of the concepts or modeling elements during
the construction of the models are defined. Then, the
metamodels can be used to automatically generate the
target domain-specific modeling environment.
During the development of the metamodel, the
building blocks of the Shield are defined within the
metamodeling environment. First, stakeholders and
information elements are specified as atomic model-
ing elements and then the relationships are introduced
as connections. Overall model is specified as a cou-
pled modeling element and called as Transparency-
Model. Figure 2 shows the metamodel which is us-
ing the notation of GME. Atomic elements are shown
as <<Atom>>and coupled elements are shown as
<<Model>>in the metamodel.
Connections are shown as <<Connection>>in
the metamodel. Different relation types are defined as
different connections whereas they are grouped with
inheritance relation. ProductionConnection is defined
from Stakeholder to InfoElement. RestrictedConnec-
tion is defined from InfoElement to Stakeholder. Re-
quest and Receive connections has six different sub-
types to better express the variations. Similarly, stake-
holder and information element types are defined as
different atomic elements and they are grouped with
inheritance as well. We preferred this approach rather
than defining a type attribute because with specific
modeling elements and connections we could handle
the variations in a more effective and practical way.
The resulting modeling editor became more usable
and we could easily identify the type of the elements.
We applied a prototyping approach where the de-
liverables were built up incrementally. The modeling
editor provides a diagram view as well as an XML
based representation. We defined attributes for some
elements, as well as different decoration types for bet-
ter usability and to be compliant with the language
definition. The resulting editor is a full functional
drag and drop style modeling editor. Some attributes
are assigned default values, for example default in-
formation requitement type is unrequited information
provision since if the type is requited then this should
be defined by the modeler specifically. Figure 3
shows a screenshot of the modeling editor.
OCL (Object Constraint Language) based axiom
checking supports the model validation. Figure 4
illustrates the constraint definition and usage. Fig-
ure 4.a shows how the constraints are attached to
metamodel in the metamodeling stage and Figure 4.b
shows an example constraint definition by updating
the attributes of the constraint. Figure 4.c presents
the output when the constraint is triggered in the mod-
eling stage. The example is NoEmtpyName constraint
TranspLanMeta: A Metamodel for TranspLan Modeling Language
151

LegalUnrequitedRequestConnection
<<Connection>>
VoluntaryUnrequitedReceiveConnection
<<Connection>>
UndecidedRequitedReceiveConnection
<<Connection>>
PersonalUnrequitedRequestConnection
<<Connection>>
AllExceptStakeholders
<<Atom>>
NotIncludedStakeholders : field
PublicStakeholders
<<Atom>>
PolicyInfoElement
<<Atom>>
ProcessInfoElement
<<Atom>>
DataInfoElement
<<Atom>>
UndecidedUnrequitedReceiveConnection
<<Connection>>
UndecidedRequitedRequestConnection
<<Connection>>
UndecidedUnrequitedRequestConnection
<<Connection>>
ReceiveConnection
<<Connection>>
ProvisionType : enum
Medium : field
AllStakeholders
<<Atom>>
RequestConnection
<<Connection>>
DemandType : enum
Medium : field
RestrictedConnection
<<Connection>>
TLConnection
<<Connection>>
Description : field
BooleanType : enum
ProductionConnection
<<Connection>>
TransparencyModel
<<Model>>
Description : field
InfoElement
<<Atom>>
Description : field
InfoElementTag : field
InfoElementName : field
Stakeholder
<<Atom>>
Description : field
StakeholderName : field
CoerciveRequitedReceiveConnection
<<Connection>>
VoluntaryRequitedReceiveConnection
<<Connection>>
LegalRequitedRequestConnection
<<Connection>>
PersonalRequitedRequestConnection
<<Connection>>
CoerciveUnrequitedReceiveConnection
<<Connection>>
dst
0..*
src
0..*
dst
0..*
src
0..*
dst
0..*
src
0..*
src
0..*
dst
0..*
0..*
0..*
0..*
Figure 2: TranspLan language metamodel.
MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development
152

Figure 3: Screenshot of the TranspLan modeling editor.
Figure 4: An example constraint for TranspLanMeta.
and checks that a Stakeholder cannot have an empty
name. Similarly, we are checking that tag numbers are
unique with OCL. Some of the rules are guaranteed
by using the metamodel such as each information el-
ement has one type. We are currently working on the
constraints and improving the metamodel due to some
of the OCL rules are partially running. However, the
mechanism has been tested and works properly, we
only need to revise the OCL rules.
4 CASE EXAMPLE
The auto-generated modeling editor is used to define
various models and tested with different small and
mid scale scenarios. As an example, a sample trans-
parency model for defining the transparency require-
ments for an email service provider is shown in this
paper which was previously presented in (Hosseini
et al., 2018). We have chosen the same example to
be able to compare the outputs. Figure 5 shows the
Customer
07 - Monthly update06 - Weekly update
Email service
provider
Email service
provider
Customer
04 - Terms and
conditions
03 - Spam detection
algorithm
01 - File size
limit
02 - Compressed
files storage
05 - Spamming
policies
..
XOR
OR
...
X
.
.
Figure 5: Sample model developed with the TranspLan
modeling editor.
Table 1: Language constructs vs. TranspLanMeta elements.
Language construct Metamodel element
Stakeholder Stakeholder (Atomic)
Information element InforElement (Atomic)
Producing information ProductionConnection
Requesting information RequestConnection
Receiving information ReceiveConnection
Restricted information RestrictedConnection
sample model. The modeling editor provides an envi-
ronment to be able to exactly replicate the previously
drawn models. The metamodel covers all of the core
modeling elements and relationships. Table 1 shows
how the TranspLanMeta metamodel covers the con-
cepts of the TranspLan language.
All stakeholder types are implemented with differ-
ent icons and various information element types are
implemented with the data type as a vertical text on
the left. All relationship types are implemented as
well, with their associated line styles such as dashed
or solid as well as arrow headings. The relationships
are checked for their directions, for example a pro-
duction relation is only possible from a Stakeholder
to Information Element.
5 DISCUSSION
In this section, we would like to discuss the benefits
of TranspLanMeta and challenges in our work. First
of all, this work helped us to transfer the TranspLan
language specification into a machine readable for-
mat. We followed a well-established model driven
approach and effectively developed a practical solu-
TranspLanMeta: A Metamodel for TranspLan Modeling Language
153

tion for transparency modeling. The auto-generated
modeling editor is used to test both the language spec-
ification and the metamodel.
During the metamodeling process, we needed to
make some decisions. In many cases, the decision
making process was straightforward and supported
by literature. But, in a few occasions we needed to
try all alternatives and choose the best option. For
example, making all relation types as different con-
nection classes was initially seemed to be irrelevant.
However, after some tests and modeling exercises we
preferred this approach rather than defining a type at-
tribute for the base class. Because with specific con-
nections, the resulting modeling editor became more
usable and we could easily identify the type of the el-
ements. In this way, we could decorate different line
types associated with different relation types such as
dashed or solid, empty or arrow headed, etc.
Additionally, we would like to mention that we
highlighted the ambiguity problem about AND, OR,
and XOR relationships present in the language speci-
fication. Currently, this issue is explained in (Hosseini
et al., 2018) and it is assumed to use priority between
logical operators as 1)XOR 2)OR and 3)AND. Al-
though, this assumption solves the issue temporarily,
we need a better mechanism to represent the mathe-
matically equivalent relations. In TranspLanMeta, we
solve this ambiguity problem with grouping the rela-
tions with an attribute. This is equal to using paren-
theses and resulting mathematical equation can be au-
tomatically derived.
6 CONCLUSION
This paper presented a metamodel for transparency
modeling and a modeling tool with a formal ba-
sis. The metamodel is based on TranspLan language,
which is proposed for defining and analysing trans-
parency requirements in information systems (Hos-
seini et al., 2016). We applied a prototyping approach
where the deliverables were built up incrementally.
The modeling editor provides a diagram view as well
as an XML based representation. OCL based axiom
checking supports further model validation.
As a future work, we will develop a plug-in at-
tached to our metamodel to automatically generate
(fully or partially) Sitreq and Infolet information. In
addition, we would like to improve TranspLan lan-
guage specifications to resolve the ambiguity in log-
ical priorities by using the findings throughout the
metamodeling process.
REFERENCES
Atkinson, C. and K
¨
uhne, T. (2002). Rearchitecting the
UML infrastructure. ACM Trans. on Modeling and
Computer Simulation, 12(4):290–321.
Cetinkaya, D., Verbraeck, A., and Seck, M. D. (2015).
Model continuity in discrete event simulation: A
framework for model-driven development of simula-
tion models. ACM Transactions on Modeling and
Computer Simulation, 25(3):17:1–17:24.
Davis, J. (2003). GME: The generic modeling environ-
ment. In Companion of the 18th Annual ACM SIG-
PLAN Conference on Object-oriented Programming,
Systems, Languages, and Applications, OOPSLA ’03,
pages 82–83. ACM.
Emerson, M., Neema, S., and Sztipanovits, J. (2008). Meta-
modeling languages and metaprogrammable tools.
In Handbook of Real-Time and Embedded Systems,
pages Chapter 33, 1–16. Taylor and Francis Group.
Hosseini, M., Shahri, A., Phalp, K., and Ali, R. (2016).
A modelling language for transparency requirements
in business information systems. In Int. Conference
on Advanced Information Systems Engineering, pages
239–254. Springer.
Hosseini, M., Shahri, A., Phalp, K., and Ali, R. (2017). Four
reference models for transparency requirements in in-
formation systems. Requirements Engineering, pages
1–25.
Hosseini, M., Shahri, A., Phalp, K., and Ali, R. (2018).
Engineering transparency requirements: A modelling
and analysis framework. Information Systems.
Hosseini, S. M. M. (2016). Engineering of transparency
requirements in business information systems. PhD
thesis, Bournemouth University.
Ledeczi, A., Maroti, M., Bakay, A., Karsai, G., Garrett,
J., Thomason, C., Nordstrom, G., Sprinkle, J., and
Volgyesi, P. (2001). The generic modeling environ-
ment. In Int. Workshop on Intelligent Signal Process-
ing (WISP’01). IEEE.
Rodrigues da Silva, A. (2015). Model-driven engineering.
Comput. Lang. Syst. Struct., 43(C):139–155.
Sommerville, I. (2016). Software Engineering. Pearson,
10th edition.
Syriani, E., Gray, J., and Vangheluwe, H. (2013). Domain
Engineering: Product Lines, Languages, and Concep-
tual Models, chapter Modeling a Model Transforma-
tion Language, pages 211–237. Springer Berlin Hei-
delberg.
MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development
154