Enterprise Architecture Model Transformation Engine

Erik Heiland

, Peter Hillmann

and Andreas Karcher

Universit

at der Bundeswehr M

unchen,

Werner-Heisenberg-Weg 39, 85577 Neubiberg, Germany

Keywords:

Enterprise Architecture, Model Transformation, Meta-model Mapping, ArchiMate, BPMN.

Abstract:

With increasing linkage within value chains, the IT systems of different companies are also being connected

with each other. This enables the integration of services within the movement of Industry 4.0 in order to im-

prove the quality and performance of the processes. Enterprise architecture models form the basis for this

with a better buisness IT-alignment. However, the heterogeneity of the modeling frameworks and description

languages makes a concatenation considerably difﬁcult, especially differences in syntax, semantic and rela-

tions. Therefore, this paper presents a transformation engine to convert enterprise architecture models between

several languages. We developed the ﬁrst generic translation approach that is free of speciﬁc meta-modeling,

which is ﬂexible adaptable to arbitrary modeling languages. The transformation process is deﬁned by various

pattern matching techniques using a rule-based description language. It uses set theory and ﬁrst-order logic

for an intuitive description as a basis. The concept is practical evaluated using an example in the area of a

large German IT-service provider. Anyhow, the approach is applicable between a wide range of enterprise

architecture frameworks.

1 INTRODUCTION

One major purpose of Enterprise Architecture (EA)

Models is the support of the management in control-

ling an organization. With process descriptions, it is

an essential toolkit for the integration and automation

of processes in a value chain. The diversity of over

50 EA Frameworks (Matthes, 2011) becomes a prob-

lem when multiple stakeholders would like to work

together. Especially, if the collaborating stakeholder

uses different EA frameworks, which are not direct

compatible. Model transformation is a core technol-

ogy to overcome these challenges by converting mod-

els from one framework to another. It enables the de-

coupling of concrete and detailed modeling by means

of the syntax of different meta-models. Furthermore,

model transformation supports analyzing models to

automatically check on conceptional ﬂaws or improve

maturity level. All in all, model transformation leads

to the integration of heterogeneous languages to a uni-

form, homogeneous and consistent model. This en-

ables a model-driven EA from the highest abstraction

level to the technical realization in detail via a uniﬁed

tool chain. Each abstraction layer offers their service

https://orcid.org/0000-0002-6636-8356

https://orcid.org/0000-0003-4346-4510

to the upper layer whereas services of lower layers

are used through a standardized interface. However,

we are currently still far away from this ideal vision to

obtain a consistent overview of an enterprise with the

possibility of a technical deep dive. The development

process is thwarted by description language disrup-

tion. Furthermore, the questions on veriﬁcation and

validation are also open to ensure that the produced

results are comprehensible. This requires the devel-

opment of new approaches that are easy and intuitive

usable for the people.

In this paper, we present a generic transformation

engine for EA models. The combination of general

transformation principles, rule based approach, and

pattern matching is efﬁcient in the context of model

transformation management. The design is focused

on simple applicability as well as on a veriﬁable pro-

cess. It is not restricted to a speciﬁc modeling lan-

guage and can be used for cross EA frameworks. For

this purpose, we demonstrate that the usage of our en-

gine is intuitive, ﬂexible, and easy to use. Then the

approach is summarized and a short outlook is given.

Heiland, E., Hillmann, P. and Karcher, A.

Enterprise Architecture Model Transformation Engine.

DOI: 10.5220/0010191001370144

In Proceedings of the 10th International Conference on Operations Research and Enterprise Systems (ICORES 2021), pages 137-144

ISBN: 978-989-758-485-5

137

2 REQUIREMENTS

Consider the following scenario, a supplier of car

parts is merged in an automotive manufacturer. The

existing IT systems should be integrated in the current

landscape and processes for an consistent infrastruc-

ture. The interfaces to applications and data structures

are available in the form of an architecture building

blocks as UML models. Nevertheless, the modeling

of processes at the automotive manufacturer and the

supplier has been done in different languages and in

diverse levels of detail up to now. The automotive

manufacturer used Business Process Model and Nota-

tion (BPMN) with many details whereas the supplier

used ArchiMate only for the main aspects.

In particular, the problem lies in the several and

dispersed data storages. These are characterized by

different formats (e.g. date as text or numeric), degree

of detail (e.g. place as address or city) and meaning

(e.g. light as spotlight or ambience). A more difﬁcult

problem is the use of relationships to display infor-

mation. On the one hand, it is an application, and on

the other hand, it must be a service based on at least

one server supported by a role. Nevertheless, the cus-

tomer demands the documentation of the desired IT

solution generally in the form of architecture models,

similar to a formalized requirement speciﬁcation.

There are several challenges in the alignment of

heterogeneous frameworks: tool compatibility, lan-

guage syntax, exchange formats, and semantic and

expressiveness of the meta models.

In this paper, we focus on providing a solution

to address semantic heterogeneity, without depending

on a single tool or framework.

Considering the manifold of EA modeling possi-

bilities, we focus on a wide applicable approach. For

a generic transformation language, the following re-

quirements have to be considered:

• Easy applicability by intuitive and several descrip-

tion possibilities

• Separation of content description, rule deﬁnition,

and tool environment to avoid dependencies

• Complete functional scope for conversion with

an independent transformation engine for a wide

adaptability

• Chaining and interlinking of transformation rules

Beside these main requirements, there are further mi-

nor demands. A transformation language has to avoid

the usage of explicit meta-models to be ﬂexible adapt-

able as a generic approach, and to focus on the content

to be converted. The meta-model is inherent included

in the model anyway. The syntactical correctness

of the generated target model in relation to a meta-

model is independent of the transformation itself. It

is checked afterwards. Furthermore, a transformation

language fulﬁlling the commutative and associative

property allows a bijective transformation and com-

patibility.

3 RELATED WORK

In the literature, there are over 60 tools for model

transformation, which have been analyzed in various

surveys (Kahani et al., 2018; Kahani and Cordy, 2015;

Jakumeit et al., 2014). Most of them are not available

any more. Furthermore, existing tools are not usable

in practice or in industrial context, because these are

too complex and mainly meta-model speciﬁc for aca-

demic purpose. Current approaches for the problem

can be divided in three categories Enterprise model

Transformation, Enterprise ontologies, and Ontology

alignment.

3.1 Enterprise Model Transformation

With regard to the technical realization of the map-

ping of Enterprise Architecture Frameworks we con-

sider solutions from the ﬁeld of model transforma-

tion. Numerous tools exist for model-to-model trans-

formation. The survey of Kahani (Kahani et al.,

2018) classiﬁed 60 of them according to several cri-

teria. Most of them implement the OMG standard

QVT (OMG, 2016) or similar, using OCL (OMG,

2014) or other expression languages to deﬁne trans-

formation rules. Our approach addresses domain ex-

perts in enterprise architecture modeling who do not

necessarily have experience in programming, meta-

modeling, or model transformation. Therefore, we

follow the deﬁnition of Acretoaie (Acret¸oaie et al.,

2018) of ”end-model-users”, who need a solution that

is as intuitive and easy to learn as possible. Their Vi-

sual Model Transformation Language (VTML) is the

only language known to us that pursues such an ap-

proach. However, it only allows endogenous transfor-

mations, which means that source and target models

conform to the same meta-model (Westfechtel, 2018).

This conﬂicts with our mandatory requirement for a

model transformation between heterogeneous frame-

works.

3.2 Enterprise Ontologies

Ontologies described in machine-readable form like

OWL (World Wide Web Consortium, 2012) are a suit-

able starting point for the semantic alignment of enter-

ICORES 2021 - 10th International Conference on Operations Research and Enterprise Systems

138

prise models. Hinkelmann (Hinkelmann et al., 2016)

describes the advantages of describing enterprise ar-

chitectures as ontologies in terms of enterprise analy-

sis and decision making. Beside this, there are differ-

ent methods for developing ontologies (Forbes et al.,

2018) and various projects regarding the design of en-

terprise ontologies (Fedotova et al., 2018).

We consider methods that deal with the semantic

enrichment of existing enterprise models, respectively

their meta-models, with regard to the improvement

of the compatibility to other frameworks. Hadidi (Al

Hadidi and Baghdadi, 2019) developed a domain on-

tology for extended and virtual Enterprises to improve

knowledge sharing within such collaborations. The

adaptation requires that the existing business mod-

els are already described as ontologies. Furthermore,

only a small subset of possible architectural elements

is provided under the concept framework, into which

the models must be classiﬁed. This abstraction is not

sufﬁcient for us as preparation for a semantic align-

ment of different frameworks.

3.3 Ontology Alignment

The semantic coordination of heterogeneous enter-

prise architecture frameworks is a prerequisite for

transformation at model level. One aspect of our

research is the derivation of transformation rules by

aligning the frameworks on the basis of their repre-

sentation as ontologies. This excludes a merging of

both ontologies, since the result must contain the re-

lational connections between both ontologies. Vari-

ous general matching techniques are discussed by Ra-

mar (Ramar and Gurunathan, ) and Hu (Hu et al.,

2017). Furthermore, there are more than 90 tool-

based approaches for (semi-)automatic matching, of

which only a few are still available and applica-

ble (Ganzha et al., 2016).

Chen (Chen et al., 2019) examined tools with

a focus on visualization of the alignments, which

appear to be most suitable for a practical applica-

tion in the context of EA mapping. Nevertheless,

the research approaches only fulﬁll a subset of the

corresponding relationships between two frameworks

that are relevant for us. According to the deﬁni-

tion of Ochieng (Ochieng and Kyanda, 2018), ontol-

ogy matching tools serve to identify equivalent and

disjunctive concepts, as well as subsumption. For

example, we still need statements about aggrega-

tion and case-based equivalence depending on exist-

ing instances. However, the semantic integration ap-

proaches can only support the enterprise architecture

transformation.

To the best of our knowledge, there is no holistic

approach that meets all the identiﬁed requirements on

a language independent enterprise model transforma-

tion.

4 DESIGN FOR GENERIC

ENTERPRISE MODEL

TRANSFORMATION

From the requirements described in Section 2, a solu-

tion is derived that can handle the diversity of meta-

models and languages within this context. We focus

on a generic design to bridge tool boundaries, descrip-

tion formats and semantic differences.

4.1 Transformation Organization and

Rule Structure

Based on the domain of EA Transformation, we

have to deal with a multitude of heterogeneous meta-

models. Content is typically described in terms of

elements and relations, whereby other formats (e.g.

textual, tables, etc.) are also possible. The diversity

of description languages and degrees of formalization

should not inﬂuence the functionality of a transforma-

tion language, which is why a decoupling is proposed

at this point. In order to different description forms

for transformation rules, a variability is also provided

here. Figure 1 provides an overview of our concept of

a holistic approach for a generic transformation lan-

guage.

Figure 1: Transformation Engine Overview.

There are many possibilities to describe an Enter-

prise Model Transformation (EMT). We decided upon

a rule-based approach with loose coupling. It allows

the decomposition of complex model transformations

into understandable parts. In contrast to coherent de-

scriptions, these rules can be more easily reused for

other transformations or replaced by others. Based on

rules, a graphical description can be invented on top

of it, which provides better readability for humans.

An overview of the most important concepts of the

language is presented in Figure 2.

A Rule Set contains 1..n Transformation Rules and

Enterprise Architecture Model Transformation Engine

139

Figure 2: EMT Description Components.

forms the basis for an overall transformation. Each

rule is an executable unit, which can be independent

or linked to other rules within a common rule set. A

rule consists of a Source Term, which represents the

input condition, and a Target Term, which contains

the build rules for the target model:

RuleSet ::= TransformationRule*

TransformationRule ::= ’rule(’Name’:

’SourceTerm’->’TargetTerm’)’

SourceTerm ::= SourceElement | SourceGroup |

SourceRelationship

TargetTerm ::= ...

Terms are abstract constructs and can be instanti-

ated by elements, relations and groups. Elements and

relations are referred in the following as transforma-

tion items, if statements apply to both types. Groups

are used to encapsulate logically related statements

and can be nested into each other at will. For the

logical combination of input conditions the operators

AND, OR, and XOR can be used.

Transformation items are used for the actual query

of the model contents to be transformed. They have

a reference to a metatype that is used to identify po-

tential content according to its type. If the content is

not to be ﬁltered by the metatype, a wildcard is set

here using the * - operator. Constraints can be used

to reﬁne the statement, for example to restrict it by

namespaces or existing attributes. They also serve to

aggregate statements about the entire model, which

can inﬂuence the number of execution processes of

the rule.

The production rules are deﬁned within the target

term. A distinction is made between two types: cre-

ation of new elements or relations and enrichment of

existing objects from other rules. Target Groups al-

ways represent an AND link of all statements. Trans-

formation references are used to link rules with each

other. Value references are used to specify the target

items, for example by assigning names, attributes and

tags.

4.2 Content Query Techniques

In the following, the primarily used query techniques

are introduced in order to provide a detailed under-

standing of how the transformation engine works.

4.2.1 Content Filtering and Aggregation

Each condition speciﬁed within a source term is used

to query the existence of a certain constellation within

the overall model. The transformation items, which

query a subset of the model by their type A, form the

basis for this. The processing of these contents a

..a

takes place iteratively by default as shown in equation

(1). As each rule is self-contained, deterministic re-

sults are obtained. Thus race conditions are excluded.

The iterative rule matching process run until no rule

matches anymore. To ensure that the transformation

is executed correctly, an exact and speciﬁc description

must be ensured when creating the rules, whereby the

rules must not overlap.













→ Exec {a

}

→ Exec {a

}

(1)

This means that whenever an item corresponding

to the type exists, the rule is executed and the respec-

tive contents are forwarded to the target model gener-

ation. Content can be further speciﬁed by additional

criteria through Search Conditions, e.g., ﬁltering by

name or some property.

If the transformation is not to be executed for ev-

ery existing element or for every relationship between

two elements, the contents must ﬁrst be aggregated.

Loop constraints are introduced for this purpose. This

type of aggregation forms the iteration into an exis-

tence check condition. This means for elements, in-

stead of triggering an execution per element, a query

is made for the existence of a number of existing el-

ements according to the condition. For example, it is

possible to check whether at least one element of the

speciﬁed type exists. The effect on the execution of

the rules are explained in Equation (2).













→



A{c(≥1)}

, a

...

, a



−→Exec{a

, a

...

, a

}

(2)

As a stand-alone condition, exactly one execution

takes place if the statement is true. The operands

available are at least (≥), more than (>), exactly (=),

ICORES 2021 - 10th International Conference on Operations Research and Enterprise Systems

140

less than (<) and at the most (≤). Ranges can also

be queried by combining several loop constraints.

For the aggregation of source relationships there

are 4 different possibilities besides the standard iter-

ation over all relations of the type. The conﬁgura-

tion is achieved by setting loop constraints on the re-

lations source (S), target (T) and the relation (R) it-

self. Table 1 shows the possible combinations, where

1 means that at least one loop constraint has been as-

signed.

Table 1: Different Query Patterns for Relationships.

S R T Result

0 0 0 Iteration over all relationships of the type

0 1 1

Iteration over distinct source elements, aggre-

gation of relations and target elements

1 1 0

Iteration over distinct target elements, aggrega-

tion of relations and source elements

0 1 0

Iteration over all source - target combinations,

aggregation of corresponding relations

1 1 1

Aggregation of all relations, source and target

elements to one statement

4.2.2 Logical Operations

If several source terms are grouped, the provided con-

tents are combined using the deﬁned logical opera-

tors. For this purpose, calculations using AND, OR,

and XOR are possible. The quantity comparisons take

place in pairs and refer to the names of the transfor-

mation items. Contents of identically named parame-

ters are merged and checked for compliance with the

statement, while differently named parameters are ap-

pended. Finally, the valid content sets are transmitted

to the target term for execution.

4.3 Rule Concatenation

Transformation references allow the reuse of already

created output items from other rules. This allows

splitting of complex model areas into partial trans-

formations and incremental enrichment. As shown in

Figure 3, the target element is created in one rule and

enriched with attributes and relations in another.

The referenced rule works like a function that re-

turns the speciﬁed target values, based on the input

parameters passed to it. If the called rule has not yet

been executed, this occurs at the latest when the func-

tion is called in order to generate its value range. De-

pending on the deﬁnition of the rules and the input

parameters passed, a transformation reference can re-

turn zero, exactly one or more values for the applica-

tion of further transformation steps.

Figure 3: Mapping Example using Transformation Refer-

ences.

Figure 4: Transformation Reference with Intermediate Ele-

ments.

They can also be used on the source side of a rule.

This mechanism can be used, for example, to con-

catenate transformation rules across multiple frame-

works. It is also possible to mark certain elements

and relations as intermediate. Thus, they act as vari-

ables, which become accessible for further rules by

references. These elements are removed at the end of

the transformation. Figure 4 shows an example, how

a variable is enriched step by step with a name and

how this variable is ﬁnally used to create an element.

Such structures can be useful, for example, to convert

a tree structure into a ﬂat one, such as a pivot table.

4.4 Meta Model Assignment

The advantage of the presented EMT language is that

it allows the deﬁnition of mapping rules without ex-

plicitly described meta models. Thus, no proﬁle or

schema is required, types can be simply declared and

assigned to rules. A connection is made via the name,

which must also be assigned to each content element

in the form of the type. The assignment of several

meta types for content objects is possible. This can

be useful for more aggregated considerations. Ta-

ble 2 shows an example of how elements can be as-

signed to the higher-level types in addition to the di-

rect metatype.

These overlapping results offer several possibili-

ties for model queries. For example, the following

Enterprise Architecture Model Transformation Engine

141

Table 2: Assignment of multiple metatypes based on ele-

ments of ArchiMate (The Open Group, 2016).

Content Metatype 1 Metatype 2

Customer BusinessActor Business (A)

Financial App. ApplicationComponent Application (A)

Payment Proc. ApplicationService Application (B)

Rep. DB Updates TechnologyService Technology (B)

Quoted Price DataObject Application (P)

r1 AggregationRelationship Relation (E)

r2 CompositionRelationship Relation (E)

execution conditions can be formulated:

• all elements from type

’BusinessActor’: element(A:BusinessActor)

• all active structure elements within the model:

element(A:Active)

• all behavior elements from application Layer:

element(A:Behavior)∧(element(A:Application))

The concept is also suitable for other languages where

type inheritance is possible. This is the case, for ex-

ample, with UML proﬁles where specialized stereo-

types are derived from meta classes. In addition to ag-

gregation, the multiple assignment can also be used to

deﬁne synonyms to compensate potential format dif-

ferences, like ”archimate:BusinessActor” and ”Busi-

ness Actor”.

4.5 Adaption of Content- and Rule

Description Interpreters

The generic structure allows the separation of the ac-

tual transformation from the description format of the

source and target model, as well as the rule descrip-

tion. To formalize the contents according to the syn-

tax of the transformation language, interfaces are de-

ﬁned that can be implemented by developers with lit-

tle effort. Thus, the transformation language can be

used for each individual EA and domain-speciﬁc lan-

guage (DSL).

4.5.1 Transformation Content

The transformation language processes content that

must be prepared according to a deﬁned interface.

A distinction is made between entities and relations.

Both deﬁne attributes for name, id, and metatypes. In

addition, relations contain references to their source

and target entities.

The GetValue(expression) function is used by the

transformation engine to address additional object-

speciﬁc attributes for creating and enriching target ob-

jects using value references. The deﬁnition of the syn-

tax used for this can be determined by the user. The

Figure 5: Using different Content Interpreters for convert-

ing the Transformation Output.

second function SetValue(referenceResult) is used to

generate the target models from the generic output

format of the transformation. A variety of evalua-

tions are also possible here, depending on the spec-

iﬁed value references.

For example, the transformation of process mod-

els from BPMN (Object Management Group, 2013)

to ArchiMate is realized independently of the target

language. Afterwards, a different content interpreter

can be used to import the content or to generate a

model according to the ArchiMate Model Exchange

Format (The Open Group, 2017), an UML proﬁle for

ArchiMate or the ArchiMEO ontology (Hinkelmann

et al., 2013) (see Figure 5).

4.5.2 Rule Description

The transformation rules can be deﬁned using the pro-

vided grammar according to ﬁst-order logic and made

available to the transformation engine. The mapping

of language constructs to model elements is simple

due to the clear structure. Therefore, different visual

notations can be further applied, which allow the de-

scription of the mapping rules in arbitrary modelling

tools. Thus, an enterprise architect can model the

transformation rules in its familiar environment.

4.6 Transformation Management

The mapping of complete EA frameworks can

quickly contain over 100 chained transformation

rules. Therefore, grouping as well as monitoring and

debugging is necessary to ensure rule consistency and

correct execution. Our approach in the direction to

transformation management includes the following

aspects:

• Dependency Check: The relationship between in-

dividual rules must be comprehensible. This en-

sures that rules do not refer to each other, gen-

erating endless loops, and content is not mapped

redundantly and further processed at different

points.

• Content Matching: It must be comprehensible

how the query mechanisms work on the model

ICORES 2021 - 10th International Conference on Operations Research and Enterprise Systems

142

Table 3: Aligning ArchiMate with BPMN (Lankhorst et al.,

2017).

ArchiMate BPMN

Business Actor, Role Participant/Pool, Lane

Application Component Participant/Pool, Lane

Business Collaboration

Application Collaboration Collaboration

Business/Application Process Process

Triggering Sequence ﬂow

Access Data association

and which content is transformed. For this pur-

pose, it must also be possible to make partial

queries to the individual source terms in complex

rules as well as single rule execution.

• Traceability: After the transformation it must be

possible to determine which rules were responsi-

ble for which target content under consideration

of which content.

Especially the last aspect is relevant for an incremen-

tal transformation. Our approach provides traceability

via assignment tables. Each rule maintains a direc-

tory of inputs and outputs as well as their execution

status. An already created object can be reused and

adapted exactly as described in Subsection 4.3. The

ﬁnal transfer of the change from this generic trans-

formation output format to the target format must be

the task of the content interpreter. The prerequisite is

that the reference between target and output format,

is retained during interpretation, for example via the

global identiﬁers of the objects.

5 PROOF OF CONCEPT

For demonstration of the transformation language, we

applied a graphical syntax in the area of business

process modeling. Therefore, we developed a proto-

type in C# as a plug-in for Enterprise Architect from

SparxSystems, which allows the deﬁnition and execu-

tion of transformation rules. In the following exam-

ple, we show an excerpt of the mapping approach be-

tween BPMN and ArchiMate to demonstrate the ex-

pressiveness and applicability of our solution, listed

in Table 3.

We focus on the transformation of different facts

and omit the deﬁnition of value references for better

clarity. These references are placed using annotations

or attributes, as shown in previous Figures 2, 3, and 4.

The described transformation of processes, links

and actors is presented in Figure 6. This short sce-

nario shows that only a few language building blocks

are necessary to form the model expressions to map

between EA models. According to our scenario, the

Figure 6: Demonstration Example of the application of

EMT.

supplier processes could be integrated into the auto-

motive manufacturer’s process model. The integrated

process landscape ensures coordinated processes and

a uniform overall understanding for such an extended

enterprises (Al Hadidi and Baghdadi, 2019). Busi-

ness changes could be communicated through incre-

mental model adjustments and responded to compli-

cations accordingly.

First, we map all Business Actor and Business

Role elements to Participant/Pool elements (Rule 1).

Therefore all elements from type actor or role are

combined in a source group under the parameter A

and transformed to an element B with type ’Partici-

pant / Pool’. A differentiated view could be consid-

ered for the creation of pools or lanes, depending on

related processes and collaboration between the ac-

tors.

For the transformation of processes, we differ-

entiate between tasks and sub-processes on the tar-

get side. Processes with at least one aggregation or

composition relationship to an underlying process be-

comes sub-processes (Rule 2). In this example, we as-

sume the assignment of multiple meta-types as shown

in Table 2. It will use the meta-link ”Aggregate” to

consider both relationships.

A Business Process becomes a task if it does not

aggregate any other sub-processes. This task is em-

bedded into the higher sub-processes of Rule 2, if any

exist (Rule 3). For this purpose, we use a relation with

the type ”Nested Element”, which must be interpreted

manually by the content interpreter when creating the

Enterprise Architecture Model Transformation Engine

143

BPMN model.

Finally, we want to transform the direct trigger

relations between Business Processes into Sequence

Flows (Rule 4). Since, we do not know in this context

whether the processes have become a sub-process or

a task, we reference both rules (2 and 3) and insert a

placeholder for the target type. Since the input con-

ditions of both rules are mutually exclusive, only one

returns the desired activity at a time.

6 CONCLUSION AND FUTURE

WORK

Model transformation is a complex challenge due to

the heterogeneity of languages and frameworks. Es-

pecially when it comes to automated model genera-

tors, the difﬁculty lies in the many details of the en-

terprise models. For this purpose, we have presented a

concept that is language independent. The system of-

fers ﬂexible description possibilities for model trans-

formation using a rule-based approach with simple

expressions. It uses the idea of set theory and proposi-

tional logic for its description, so that only little pre-

vious knowledge is necessary for their use. The es-

tablished rules can be chained with each other. In

comparison to current approaches, the concept is easy

to use and can be applied widely. Based on the de-

veloped system, a natural, formal textual description

language will be deﬁned in the next step.

REFERENCES

Acret¸oaie, V., St

orrle, H., and Str

uber, D. (2018). VMTL: a

language for end-user model transformation. Software

& Systems Modeling, 17(4):1139–1167.

Al Hadidi, F. and Baghdadi, Y. (2019). Ontology for Enter-

prise Interactions: Extended and Virtual Enterprises.

In Poesie des Allt

aglichen, volume 12, pages 365–379.

Springer, Wiesbaden.

Chen, J., Xue, X., Huang, L., and Ren, A. (2019). An

Overview on Visualization of Ontology Alignment

and Ontology Entity. In Conference on Intelligent

Data Analysis and Applications, volume 891, pages

369–380. Springer.

Fedotova, A. V., Tabakov, V. V., Ovsyannikov, M. V., and

Bruening, J. (2018). Ontological Modeling for Indus-

trial Enterprise Engineering. In “Intelligent Informa-

tion Technologies for Industry”, volume 874, pages

182–189. Springer.

Forbes, D. E., Wongthongtham, P., Terblanche, C., and

Pakdeetrakulwong, U. (2018). Ontology Engineering.

In Ontology Engineering Applications in Healthcare

and Workforce Management Systems, pages 27–40.

Springer.

Ganzha, M., Paprzycki, M., Pawłowski, W., Szmeja, P.,

Wasielewska, K., and Fortino, G. (2016). Tools for

Ontology Matching—Practical Considerations from

INTER-IoT Perspective. In Internet and distributed

computing systems, volume 9864, pages 296–307.

Springer.

Hinkelmann, K., Gerber, A., Karagiannis, D., Thoenssen,

B., van der Merwe, A., and Woitsch, R. (2016). A

new paradigm for the continuous alignment of busi-

ness and IT: Combining enterprise architecture mod-

elling and enterprise ontology. Computers in Industry,

79:77–86.

Hinkelmann, K., Maise, M., and Thonssen, B. (2013). Con-

necting enterprise architecture and information ob-

jects using an enterprise ontology. In Enterprise Sys-

tems Conference, pages 1–11. IEEE.

Hu, X., Feng, Z., Chen, S., Huang, K., Li, J., and Zhou, M.

(2017). Accurate Identiﬁcation of Ontology Align-

ments at Different Granularity Levels. IEEE, 5:105–

120.

Jakumeit, E., Buchwald, S., Wagelaar, D., Dan, L.,

Heged

us,

A., Herrmannsd

orfer, M., Horn, T., Kalnina,

E., Krause, C., Lano, K., Lepper, M., Rensink, A.,

Rose, L., W

atzoldt, S., and Mazanek, S. (2014). A

survey and comparison of transformation tools based

on the transformation tool contest. Science of Com-

puter Programming.

Kahani, N., Bagherzadeh, M., Cordy, J., Dingel, J., and

Varr

o, D. (2018). Survey and classiﬁcation of model

transformation tools. Software & Systems Modeling.

Kahani, N. and Cordy, J. R. (2015). Comparison and Eval-

uation of Model Transformation Tools.

Lankhorst, M. M., Aldea, A., and Niehof, J. (2017).

Combining ArchiMate with Other Standards and Ap-

proaches. In Enterprise architecture at work, pages

123–140. Springer.

Matthes, D. (2011). In Enterprise Architecture Frameworks

Kompendium, pages 37–57. Springer Berlin Heidel-

berg.

Object Management Group (2013). Business Process

Model and Notation.

Ochieng, P. and Kyanda, S. (2018). Large-Scale Ontology

Matching. ACM Computing Surveys, 51(4):1–35.

OMG (2014). Object Constraint Language v 2.4.

OMG (2016). Meta Object Facility 2.0

Query/View/Transformation Speciﬁcation.

Ramar, K. and Gurunathan, G. Technical Review on Ontol-

ogy Mapping Techniques.

The Open Group (2016). ArchiMate 3.0 speciﬁcation. Open

Group Series. Van Haren Publishers.

The Open Group (2017). ArchiMate Model Exchange File

Format for the ArchiMate Modeling Language, Ver-

sion 3.0.

Westfechtel, B. (2018). Case-based exploration of bidirec-

tional transformations in QVT Relations. Software &

Systems Modeling, 17(3):989–1029.

World Wide Web Consortium (2012). OWL 2 Web Ontol-

ogy Language.

ICORES 2021 - 10th International Conference on Operations Research and Enterprise Systems

144