An Integrated Framework for Running Extended Class Models

Johannes Schr

opfer

Chair of Applied Computer Science I, University of Bayreuth, 95440 Bayreuth, Germany

Keywords:

Model-Driven Development, Projectional Editing, SOIL, Ecore, OCL, Code Generation.

Abstract:

Model-driven software engineering often deals with combinations of structural and behavioral models. In this

area, class models are common artifacts expressing the structure of software systems. From class models,

source code can be generated which captures the structural elements. To be runnable, the generated code

usually has to be completed by implementing behavior. The Eclipse Modeling Framework (EMF) is a popular

environment for model-driven software development. In this context, class models are speciﬁed as instances of

the Ecore metamodel. From Ecore models, Java code is generated that lacks in the implementation of method

bodies (typically, only method heads are generated). Our approach supports code generation from extended

metamodels comprising structural elements, behavior, and constraints. To this end, we build a projectional

editor for a textual modeling language based on SOIL, an imperative extension of OCL. The editor allows for

specifying extended class models from which Java code can be generated. Our goal is to reuse the standard

EMF code generator. The resulting Java source code is fully executable such that after creating the extended

class model, no user interaction is required any more. In this paper, we present the idea of our approach and

the current state of implementation.

1 INTRODUCTION

The Eclipse Modeling Framework (EMF) (Steinberg

et al., 2009) constitutes a popular ecosystem for

model-driven development. This includes support

for implementing models and metamodels with ap-

propriate model editors. It serves as the basic con-

text for many tools and frameworks regarding per-

sistence, user interfaces, and model transformations

For model editors, several kinds of representations

are considered. The default representation within the

EMF core constitutes the EMF tree editor. Frame-

works as GMF

and Sirius

(Madiot and Paganelli,

2015) provide graphical editors by representing the

models as diagrams. Further representations as trees,

forms, or tables are supported by EMF Parsley

(Bet-

tini, 2014).

Recently, human-readable textual syntax became

more and more popular. The term “human-readable”

refers to intuitive textual syntax that resembles the

syntax of programming languages in contrast to

XML, for instance, which was designed for data ex-

change instead. As an example for this trend towards

https://www.eclipse.org/modeling/emf/

https://www.eclipse.org/modeling/gmp/

https://www.eclipse.org/sirius/

https://www.eclipse.org/emf-parsley/

human-readable textual syntax, ALF (OMG, 2017)

was designed to represent UML models using textual

notation. ALF models may contain both structural

as well as behavioral model elements. It is limited

to fUML (Foundational UML) (OMG, 2021) which

refers to a subset of UML and provides execution se-

mantics.

As another textual language, SOIL (Simple OCL-

based Imperative Language) (B

uttner and Gogolla,

2014) uses OCL and adds imperative elements. Thus,

operation bodies of class models can be completely

described. SOIL is implemented in the tool USE

(UML-based Speciﬁcation Environment) (Gogolla

et al., 2007) that poses a validator for models de-

scribed by UML and OCL and therefore helps devel-

opers to analyze models with respect to model and be-

havior. Using SOIL allows for specifying UML mod-

els containing structural elements as classes, associa-

tions, and attributes, behavioral elements as operation

bodies, and invariants as constraints between different

model elements.

For textual editors, two kinds of editor approaches

are differentiated. In case of parser-based editors, the

text is treated as the primary artifact which is persisted

and directly modiﬁed using editor commands. From

the text, the transient model that is represented by the

text is derived to perform syntactic and semantic ana-

Schröpfer, J.

An Integrated Framework for Running Extended Class Models.

DOI: 10.5220/0011794800003402

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

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)

Table 1: Overview of the different kinds of SOIL statements (B

uttner and Gogolla, 2014).

object creation v := new c

attribute assignment e

.a := e

variable assignment v := e

operation call e

.op(e

, . . . , e

)

operation call with result v := e

.op(e

, . . . , e

)

block of statements [declare v

: t

, . . . , v

: t

] [begin] s

;. . . ;s

[end]

conditional execution if e then s

[else s

] end

iteration for v in e do s end

lyzes. By contrast, projectional editors invert this ap-

proach and employ the underlying model as the pri-

mary artifact which is persisted. Editor commands

directly affect the model and changes are propagated

to the text as its representation. While for experi-

enced modelers and programmers, projectional edi-

tors may feel less natural than syntax-based ones; on

the other hand, projectional editors come along with

several beneﬁts as the guarantee of syntactic correct-

ness – the representation is derived from the projec-

tion rules – or a more ﬂexible tool integration – by re-

ferring to the underlying model containing deﬁnitely

identiﬁable model elements instead of its representa-

tion.

In the EMF context, Xtext

(Bettini, 2016) con-

stitutes a popular framework that allows for building

parser-based textual editors for domain-speciﬁc lan-

guages. Xtext provides an editor to deﬁne the gram-

mar of the language. From the grammar, the function-

ality of the editor is generated. The generated artifacts

can be extended which facilitates implementing static

semantics as scoping of named elements, validation

rules, quick ﬁxes, or value converters.

Projectional editors were devised several decades

ago as components of integrated programming en-

vironments. Currently, the Meta Programming Sys-

tem (MPS)

by JetBrains (Campagne, 2015) poses

a contemporary framework that provides support for

developing projectional editors with different kinds

of notation (including textual concrete syntax). In

(Schr

opfer et al., 2020), we presented our approach

of a framework for projectional textual model edi-

tors in EMF context. By specifying projection rules

describing the contextfree syntax and programming

editor providers with respect to static semantics – by

means of Xtend similar to Xtext –, a projectional ed-

itor can be conﬁgured for a speciﬁc domain-speciﬁc

language. That approach extends the original idea

of projectional editors since also the representation

is persisted. That allows users to persistently supply

https://www.eclipse.org/Xtext/

https://www.jetbrains.com/mps/

layout information and therefore build a customized

view of the underlying model.

This paper presents a projectional editor for tex-

tually represented class models based on SOIL as a

new use case for the projectional editor framework.

This projectional editor constitutes the start artifact of

a tool chain comprising different model transforma-

tions. The goal is generating fully executable Java

source code from the class models. After specifying

a class model containing both structural and behav-

ioral elements by the user in the projectional editor,

Java source code can be generated which comprises

completely implemented methods. Therefore, no ad-

ditional code fragments have to be inserted by the

user. To this end, we reuse the default code genera-

tion mechanism provided by EMF.

Section 2 gives an overview of the background of

this paper. Section 3 describes the idea of the ap-

proach and Section 4 outlines details of the imple-

mentation. Section 5 discusses related work while

Section 6 concludes the paper.

2 BACKGROUND

The textual language SOIL (Simple OCL-based Im-

perative Language) (B

uttner and Gogolla, 2014) ex-

tends the Object Constraint Language (OCL) (OMG,

2014) by adding different kinds of imperative con-

structs. Table 1 shows the statements provided in

SOIL. By adding textual notation for structural model

elements, class models including operation bodies

and invariants may be completely expressed in tex-

tual notation. To this end, classes, associations, and

enumerations are provided. Classes may contain at-

tributes, operations, and invariants. Associations con-

tain attributes which pose their member ends. For the

rest of the paper, we refer to SOIL models as com-

plete models containing structural elements, behavior

(expressed by SOIL statements), and invariants.

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

1 model g rap h

3 class G rap h

4 attributes

5 siz e : I nt eg e r derive:

6 ver tice s - > s ize () + v er t ic es

7 -> c ol l ec t ( out go in g ) - > s ize ()

8 constraints

9 inv No nE m pt y : si ze > 0

10 class V ert ex

11 attributes

12 la b el : S tri ng init: ’ New ’

13 operations

14 ad dE dge ( trg : V e rt ex ) : Bo o le an

15 body:

16 declare e : Edg e = ne w Ed ge .

17 e. sou rc e := s e lf ;

18 e. tar ge t := tr g ;

19 result := true;

20 pre: trg <> null

21 class Ed ge

23 assoc C on ta in s

24 gr a ph : G r ap h

25 ve rt ic es : V e rt ex [0 ..* ] comp

26 assoc H as Ou tg oi ng

27 so urc e : Ve rte x

28 ou tg oi ng : Ed ge [ 0. .*] comp

29 assoc I sT ar ge tO f

30 ta rge t : Ve rte x

31 in co mi ng : Ed ge [ 0. .*]

Listing 1: An example SOIL model (in the context of

graphs) in concrete syntax.

A small example model in textual syntax is given

in Listing 1. The model named graph consists of the

classes Graph, Vertex, and Edge as well as the asso-

ciations Contains, HasOutgoing, and IsTargetOf. The

associations Contains and HasOutgoing contain com-

posite attributes (notated by comp), i.e., they describe

compositions. A graph directly contains its vertices

as child elements. An edge is modeled as the child

element of its source vertex. The derived attribute

Graph::size describes the sum of the number of ver-

tices and the number of edges; its semantics is given

by an OCL expression. For the graph, the invariant

named NonEmpty is deﬁned that enforces a size larger

than 0. A vertex has a label where New is the initial

value. The operation Vertex::addEdge creates a new

edge with the target vertex speciﬁed as parameter; its

body is speciﬁed by a sequence of statements; further-

more, an OCL precondition is given.

As visible in Listing 1, for simpliﬁcation, we

slightly deviate from the SOIL syntax presented in

Table 1. The modiﬁcations hardly affect the con-

crete syntax but make the implementation of the pro-

jectional editor more convenient. We allow expres-

sion statements, i.e., statements each of which con-

tains one expression only; this captures the statements

for object creation and operation calls (note that the

shown object creation is used as the initializer expres-

sion for the local variable and not as an own state-

ment). Attribute assignments, variable assignments,

and operation calls with result are modeled as general

assignments. The sequence of declarations of local

variables at the beginning of a block is ﬁnished by a

dot. Semicolons are used after all assignments and

expression statements (and only in these cases). We

completely omit the keywords begin and end as they

are redundant and have only a small impact on the

readability.

To build the projectional editor, we apply the

framework presented in (Schr

opfer et al., 2020). After

creating the metamodel for the textual language, the

projection rules describing the contextfree syntax are

deﬁned. Additional functionality regarding static se-

mantics may be implemented as methods in generated

class stubs; this includes rules for scoping of named

elements and further validation checks which can be

speciﬁed in a declarative way.

Figure 1 gives an overview of the functionality of

the editor framework. Two roles of users are differen-

tiated: While the DSL developer conﬁgures the editor

for a speciﬁc DSL metamodel (in our case, the SOIL

metamodel), the modeler uses the conﬁgured editor to

invoke different kinds of commands. As the context

is the Eclipse Modeling Framework, the basic artifact

required to employ the framework is an Ecore model

as the metamodel describing the abstract syntax of

the DSL. Referring to the metamodel, the syntax is

deﬁned by specifying projection rules. In addition,

static semantics may be implemented by completing

editor provider class stubs. From the text ﬁle of pro-

jection rules, a model is derived. When the projec-

tional editor is run, the editor providers are called and

the syntax deﬁnition model is interpreted. The mod-

eler can invoke two kinds of commands: While data

Context: Eclipse Modeling Framework

Ecore

Syntax

Deﬁnition

Projectional

Editor

Providers

Abstract

Syntax Tree

Representation

Model

DSL

Developer

Modeler

interprets

uses

customizes

speciﬁes

issues

command

modiﬁes

semantics

modiﬁes

layout

propagates

changes

based on

Figure 1: Overview of roles and functionality of the projec-

tional editor framework (Schr

opfer et al., 2020).

An Integrated Framework for Running Extended Class Models

EPackage

EClassiﬁer

EDataType

EClass

EStructuralFeature

EOperation

EReference EAttribute

EParameter

0..1

ePackage

eClassiﬁers

eContainingClass

0..1

eStructuralFeatures

0..1

eContainingClass

eOperations

eOperation

0..1

eParameters

eSuperTypes

eOpposite

0..1

Figure 2: Cutout of the Ecore metamodel (Steinberg et al., 2009).

commands modify the underlying abstract syntax tree

(in our case, the SOIL model) and the changes are

propagated to its representation, view commands only

affect the representation model which is also persisted

in order to store the customized layout.

The context is the Eclipse Modeling Framework

(EMF) (Steinberg et al., 2009) with the Ecore meta-

model describing the abstract syntax of class models.

From Ecore models, Java source code can be gener-

ated. As Ecore models only cover structural elements,

all the generated Java methods have an empty body

which has to be implemented by the user afterwards.

In addition, EMF allows for mechamisms to conﬁgure

tree editors.

Figure 2 shows a cutout of the Ecore meta-

model. Packages (EPackage instances) contain clas-

siﬁers, i.e., classes (EClass instances) and data types

(EDataType instances). Classes can have superclasses

(EClass::eSuperTypes) and contain structural fea-

tures divided into attributes (EAttribute instances) and

references (EReference instances); while attributes

refer to data types, references are typed with classes

similar to association ends in UML. A pair of two

references can be grouped (EReference::eOpposite).

Note that Ecore does not support the concept of as-

sociations that are commonly used in UML (and

SOIL) models. In addition, classes contain opera-

tions (EOperation instances) that comprise parameters

(EParameter instances).

For the model-to-model transformation, we use

BXtendDSL. The framework BXtendDSL (Bank

et al., 2021) provides support for bidirectional and

incremental model transformations referring to ar-

bitrary metamodels as Ecore models. Traces be-

tween source and target model are persisted within

a correspondence model. The framework contains

a DSL which allows for declarative projection rules.

To express more complex transformations, generated

Xtend methods can be implemented.

For the model-to-text transformation, Acceleo is

applied. The tool Acceleo

poses an implementation

of the Mof2Text standard (OMG, 2008). The text gen-

eration is built by means of templates containing static

as well as dynamic fragments which refer to the meta-

model elements (in our case: SOIL elements).

3 CONCEPT

This section presents the conceptual idea our ap-

proach is based upon. After an overview of the tool

chain comprising the different artifacts and their de-

pendencies, we show an example model and describe

the respectively resulting models and ﬁles when the

transformations in the different steps of the tool chain

are applied.

3.1 Overview of the Tool Chain

Figure 3 illustrates the different conceptual steps of

the workﬂow. The SOIL model created and modi-

ﬁed in the editor contains all the information of the

class model including structure, behavior, and con-

straints. A model-to-model transformation creates an

Ecore model and converts the structural elements of

the class model – i.e., classes, associations, attributes,

and operations – to analogous elements of the Ecore

model. As the initial Ecore model only contains in-

formation about the structural elements of the class

model, if the EMF code generator was applied, the

generated Java method bodies would be empty. For

the operation bodies within the SOIL model, a model-

https://www.eclipse.org/acceleo/

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

SOIL Model Partial Ecore Model

Java Method Bodies Ecore Model

Generator Model

Complete Java Code

Model-to-model

Transformation

Model-to-text

Transformation

Direct

Mapping

GenModel-source

Annotations

GenModel

Builder

EMF Code

Generator

Figure 3: Overview of the tool chain.

to-text transformation creates Java source code for the

method bodies. From the initial partial Ecore model,

an extended Ecore model is established which pro-

vides annotations containing the information of the

generated method bodies. To this extended Ecore

model, the default EMF mechanism is applied and the

generator model is created.

Finally, Java source code is generated by the de-

fault EMF code generator. The resulting code con-

tains Java interfaces and Java classes with ﬁelds and

methods which correspond to the classes, structural

features, and operations in the Ecore (and SOIL)

model. In addition, the Java methods contain state-

ments which correspond to the statements in the SOIL

model. Pre- and postconditions of the operations are

checked in the Java methods. As a consequence, the

source code is fully executable and therefore does not

require additional elements written by the user.

Within the SOIL model, besides classes with at-

tributes and operations, invariants are speciﬁed, as

well. For the invariants, we plan a model-to-text

transformation in order to create OCL ﬁles. The gen-

graph

Graph

Vertex

Edge

/size : EInt label : EString = New

addEdge(trg : Vertex) : EBoolean

graph

0..1

0..*

vertices

0..1

source

outgoing

0..*

0..1

target

incoming

0..*

Figure 4: The partial Ecore model as target of the model-to-

model transformation for the example SOIL model (List-

ing 1).

erated OCL ﬁles can be directly run by the tool Com-

plete OCL. Since the invariants are not directly con-

nected to the generated Java code, we omit this part

of the tool chain in this paper.

3.2 Demonstration for an Example

Model

We refer to the SOIL model described in Section 2

(textually notated in Listing 1). From the structural

elements of the SOIL model, a partial Ecore model

is built. The created Ecore model as the target model

of the model-to-model transformation is depicted us-

ing class diagram notation in Figure 4. For the SOIL

classes in the model, corresponding EClass instances

as child elements of a respective EPackage instance

are created. The attributes and operations contained in

the SOIL classes are mapped to respective EAttribute

instances and EOperation instances. For associations,

no adequate concept is given by Ecore; rather, the as-

sociation ends – i.e., the attributes within the associ-

ations – are modeled as EReference instances which

are contained in the respective member classes. Each

pair of references that arise from attributes contained

in the same association is grouped.

The SOIL statements contained in the operation

bodies are converted to Java source code by means

of the model-to-text transformation. The resulting

Java method bodies are inserted in the Ecore model

by means of GenModel-source annotations. For the

resulting complete Ecore model, the generator model

is built and the EMF code generator is run. Listing 2

shows the generated Java methods for the derived at-

tribute and the operation. The precondition is checked

An Integrated Framework for Running Extended Class Models

when the method starts. If it is not satisﬁed, an excep-

tion is thrown (cf. lines 8–11). Analogously, post-

conditions lead to checks at the end of a method. The

predeﬁned result variable is mapped to a local vari-

able (cf. line 13) that is ﬁnally returned (cf. line 20).

1 public int g etS iz e () {

2 return ge tV er ti ce s ( ) . siz e () + U til . co l le ct (

3 g e t V e r t i c e s () ,

4 v -> v . g et Ou tg oi ng () ) . siz e () ;

5 }

7 public boolean a ddE dg e ( V er tex trg ) {

8 if ( trg = = null) {

9 throw new Un s u p po r t e dO p e r at io n Ex ce p ti on (

10 " P re co nd it io n n ot s at is fi ed ") ;

11 }

13 boolean r es ult = false;

14 Edg e e = G r a p h Fa ct or y . e I N ST AN CE . c r e a t e Ed ge () ;

16 e. s et So ur c e (this);

17 e. s et Ta rg e t ( trg ) ;

18 re sul t = true;

20 return r es ult ;

21 }

Listing 2: The generated Java methods for the example

SOIL model (Listing 1).

4 IMPLEMENTATION

In this section, we outline the current state of the im-

plementation of our approach. Furthermore, we de-

scribe the ideas of the remaining steps. After de-

tails regarding the projectional editor for the language

SOIL, we depict the implementation of the conceptual

tool chain.

4.1 Projectional SOIL Editor

We created the metamodel for class models contain-

ing SOIL statements as an Ecore model. Based on the

SOIL metamodel, a sequence of projection rules was

speciﬁed in a speciﬁc editor. For each non-abstract

class, a projection rule was deﬁned. The projectional

editor framework distinguishes between block pat-

terns – e.g., the deﬁnitions of classes or operations

which pose blocks with head lines and bodies – and

line patterns – e.g., arithmetic OCL expressions or

references to variables. From the text ﬁle of the pro-

jection rules, a model is built which is interpreted by

the editor at runtime.

Listing 3 illustrates the projection rule for assign-

ments. The projection rule constitutes a line pattern

and consists of line elements. For both delimiters

(operator := and ﬁnal semicolon), constants are in-

serted. The right-hand side of the assignment is an

arbitrary expression; to this end, the rule Expression

is referenced. For the left-hand side, variable refer-

ences (referring to local variables), attribute call ex-

pressions (referring to attributes as child elements of

classes), and result expressions (used for return val-

ues of operations) are applicable; to embody alterna-

tives, pipe characters within a pair of parentheses are

used. Eventually, the keyword nospace suppresses

a blank character before the semicolon; by default,

blank characters are set between line elements in the

editor.

1 def A ss ig nm en t

2 ( Va ri ab l e R ef er en c e | A t t r i bu te Ca ll | R es ult )

3 ’:= ’ E xp re ss io n nospace ’; ’

4 enddef

Listing 3: The projection rule for SOIL assignments (line

pattern).

Furthermore, static semantics are implemented by

means of methods in Xtend class stubs generated by

the framework. While the method for default scop-

ing is redeﬁned in the respective class stub, validation

rules are speciﬁed in a declarative way. For each val-

idation rule, a method is deﬁned with the respective

context model element as its parameter. A validation

result is added by invoking a method. To this end,

the three severities error, warning, and information

are provided.

1 @ Rul e

2 def c h ec k A s si g n m en t T y pe C o m pa t i b il i ty (

3 A s s i gn me nt amt ) {

4 if (! amt . g et Ri gh t () . is Co mp at i b l e T o (

5 amt . get Le ft () ))

6 r e p o r t E r r o r ( AS S I G NM EN T_ TY PE _C O M P AT IB IL IT Y ,

7 " Right - ha nd s ide not co mp at ib le " +

8 " to left - h a nd side ",

9 amt ,

10 So il Pa ck ag e . Lit er al s . AS SI GN ME NT _ R I GH T )

11 }

Listing 4: The validation rule for type checking of SOIL

statements (Xtend method).

Listing 4 shows the deﬁnition of a validation rule

for assignments. To compare the types, an auxiliary

method isCompatibleTo is used (not shown here). In

case the types are not compatible, an error is ﬁred. To

this end, the method reportError has several parame-

ters: The ﬁrst parameter is a unique string ID and the

second parameter poses the description that is visible

in the user interface; the context object is speciﬁed as

the third parameter; ﬁnally, the optional fourth param-

eter allows for deﬁning the affected structural feature

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

which allows for a more precise visualization of the

error (in this case, the right-hand side of the expres-

sion).

4.2 Tool Chain of Model

Transformations

The model-to-model transformation mapping SOIL

elements to Ecore elements is currently implemented

by means of BXtendDSL. In a text editor, the trans-

formation rule can be speciﬁed in a declarative way.

Details which cannot be expressed by the declarative

rule, are implemented in an imperative way by com-

pleting Xtend methods generated from the transfor-

mation rule. The framework BXtendDSL allows for

incremental and bidirectional model-to-model trans-

formations. This will allow an additional workﬂow

covered by future work where the Ecore model is

modiﬁed and the changes are propagated to the SOIL

model.

1 rule A t tr ib ut e 2E At tr i bu te

2 src At tr ib u te at t | filter;

3 trg EA tt ri bu te eAt t ;

5 att . n ame <- -> eA tt . n ame ;

6 att . o rd er ed <- -> eA tt . o rd er ed ;

7 att . u ni que < -- > e A tt . uni que ;

8 att . l owe r < -- > e Att . lo we rB ou nd ;

9 att . u ppe r < -- > e Att . up pe rB ou nd ;

10 att . d er iv ed <- -> eA tt . d er iv ed ;

12 att . t ype -- > e A tt . eTy p e ;

13 att . in i t i a l i z e r - -> eA t t . d e fa ul t V a lu eL it e ra l ;

14 att . d er iv ed -- > e A tt . ch a ng ab le ;

15 att . d er iv ed -- > e A tt . tr a ns ie nt ;

16 att . d er iv ed -- > e A tt . vol at il e ;

Listing 5: Example BXtendDSL transformation rule that

maps SOIL attributes to Ecore attributes.

The larger part of the SOIL model corresponds di-

rectly to the Ecore model. Nevertheless, the concept

of associations is not given by the Ecore metamodel.

Rather, association ends are mapped to references that

are contained in the respective member classes. List-

ing 5 shows the transformation rule which maps at-

tributes in SOIL classes to Ecore attributes. Since

only a subset of the attributes comprised by the SOIL

model are transformed – the attributes contained in

classes (and not in associations) – we need a ﬁlter

for the source (cf. line 2). Several values can be di-

rectly mapped notated by the bidirectional arrow (cf.

lines 5–10). For the additional values – only given

by the Ecore model –, for the type of the attribute –

a SOIL type cannot directly mapped to an Ecore type

–, and for the initial (default) value, additional map-

pings are required. For these cases (cf. lines 12–16),

the unidirectional arrow is set which results in gen-

erated Xtend method stubs. By implementing these

methods imperatively in a second step, the semantics

of the more complex mappings can be speciﬁed (not

shown here).

Large parts of the model-to-text transformation

which generates Java source code for operation bodies

have already been implemented by using Acceleo. We

plan the integration of the generated Java source code

in the Ecore model by means of annotations analo-

gously to previous work (Buchmann and Schw

agerl,

2015). EMF provides different kinds of annotations to

store information that is not directly supported by the

Ecore metamodel. Information which is relevant for

code generation may be attached by using GenModel-

source annotations that are only relevant for code

generation. An annotation is implemented as a map

details of key-value entries. For operations in Ecore

models – i.e., EOperation instances –, the key body

is provided; the value is the Java code that poses the

body of the generated Java method. Analogously, for

derived structural features in Ecore models – i.e., ES-

tructuralFeature instances –, the key get is provided;

the value is the Java code for the body of the generated

Java getter method. Listing 6 depicts the structure of

EAnnotation instances.

1 < e Op er at io ns na m e =" ad dE dge " e Ty p e = " ec ore :

ED at aT yp e h ttp :// www . e cl ip se . o rg / em f / 200 2/

Ec o re #// EB oo le an " >

2 < eA nn ot at io ns s o ur ce =" h t tp :// www . e cl ip se . o rg /

emf /2 002 / Ge nM od e l " >

3 < det ai ls key = " bo dy " v a lu e =" Edge e =

Gr ap hF ac to ry . e IN ST AN C E . cr ea te Ed ge () ;

..." / >

4 </ e A nn ota ti ons >

5 ...

6 </ eO per ati on s >

Listing 6: XMI serialization of a GenModel-source

annotation for an Ecore operation in the context of the graph

example.

5 RELATED WORK

This section describes related work in the research

area of executable models. In the EMF OCL im-

plementation, the tool OCLinEcore

provides a tex-

tual editor for Ecore models. An Ecore model may

be displayed by the editor using textual notation for

the structural elements. Within the editor, invariants

as well as behavior for operations and derived struc-

tural features may be speciﬁed. To this end, the editor

deviates from the ofﬁcial OCL standard notation and

https://wiki.eclipse.org/OCL/OCLinEcore

An Integrated Framework for Running Extended Class Models

employs additional keywords (invariant and derivation

instead of inv and dev). In contrast to SOIL, no ad-

ditional statements may be used which prevents side

effects. Furthermore, the textual editor is not projec-

tional but parser-based and directly refers to the Ecore

model; as a result, references are used instead of asso-

ciations (that are familiar for modelers used to UML),

for instance. Eventually, the OCL implementations

do not affect the generated Java source code; rather,

mechanisms are used to delegate the invocations of

operations to the expressions written in OCL syntax.

Besides SOIL, the modeling language ALF

(OMG, 2017) recently gained more and more atten-

tion. It provides a textual concrete syntax for fUML

(OMG, 2021) that refers to a subset of UML and

adds proper execution semantics. In contrast to SOIL,

the language ALF does not reuse an expression lan-

guage. Furthermore, ALF completely misses the con-

cept of derived structural features. Invariants as con-

straints between model elements cannot be modeled,

as well. An extension of the tool Valkyrie (Schr

opfer

and Buchmann, 2019) supports creating models in-

cluding structural elements and behavior and gener-

ating Java source code from them. Within an inte-

grated user interface, the structural elements are spec-

iﬁed by diagrams in a graphical editor. For operations

and derived structural features, the behavior may be

speciﬁed by using ALF in a textual parser-based ed-

itor that is visible together with the diagram editor.

In the background, a bidirectional transformation be-

tween UML and ALF is performed.

The tool Papyrus (Guermazi et al., 2015) poses

another application that refers to ALF. Papyrus allows

for creating UML, SysML, and MARTE models using

various diagram editors. Papyrus comes along with

a code generation engine that facilitates generating

source code from class models; besides Java source

code, also C++ is supported. Using a textual parser-

based ALF editor, UML model elements may be de-

scribed by ALF notation. In addition, the behavior of

activities can be speciﬁed in the ALF editor. The pri-

mary goal of the Papyrus ALF integration is provid-

ing alternative representations – graphical and textual

syntax – of the same UML model and not generating

source code to execute the behavioral speciﬁcations.

As a commercial tool, MagicDraw UML (Seide-

witz, 2017) also provides behavioral modeling with

ALF which integrates the ALF Reference Implemen-

tation

. Using ALF syntax, bodies of activities may

be modeled. The Cameo Simulation Toolkit

is re-

quired to execute UML activity, state machine, and

http://alf.modeldriven.org

https://docs.nomagic.com/display/CST190/Cameo+Si

mulation+Toolkit+Documentation

interaction models in MagicDraw. Similar to Papyrus,

the ALF fragments are compiled to activity models

that are integrated within the wider UML modeling

context.

The language QVTo (Operational QVT) as a part

of the QVT (Query/View/Transformation) standard

(OMG, 2016) allows for specifying unidirectional

model transformations in an imperative way. To this

end, mappings between model elements can be spec-

iﬁed by using an imperative language based on OCL

called Imperative OCL. In contrast to SOIL, Imper-

ative OCL uses imperative expressions as a subtype

of OCL expressions. This circumstance comes along

with problems which are discussed in (B

uttner and

Kuhlmann, 2008). While SOIL and ALF aim at an in-

tegration of the imperative elements into the model to

decribe its behavior, QVTo employs imperative con-

structs to deﬁne the transformation between models.

In the context of Ecore models, Xcore

provides

a textual concrete syntax that captures both structure

and behavior. The textual syntax of Xcore does not

base upon an ofﬁcial standard. From Xcore models,

executable Java source code is generated. The behav-

ioral model elements are described in a strongly pro-

cedural way. As a consequence, an object-oriented

way of modeling – as known from OCL or ALF –

is only possible to a limited extent. For instance, no

concept of object creation by means of constructors is

supported by Xcore.

As a graphical modeling language, Fujaba (The

Fujaba Developer Teams from Paderborn, Kassel,

Darmstadt, Siegen and Bayreuth, 2005) bases upon

graph transformations that allows for expressing both

the structural and the behavioral part of a software

system on the modeling level. A code generation en-

gine facilitates the transformation of Fujaba speciﬁ-

cations into executable Java source code. Fujaba em-

ploys story diagrams to specify the behavior of a soft-

ware system. Similar to UML, story diagrams con-

tain activities for which story patterns are used. A

story pattern constitutes a graph transformation rule

where a single graphical notation comprises both the

left-hand as well as the right-hand side of the transfor-

mation rule. Therefore, manipulations of the runtime

object graph may be described by story patterns in a

declarative way on a high level of abstraction. Never-

theless, the control ﬂow in activity diagrams in on the

same level as in control ﬂow diagrams which leads

to a rather basic level of abstraction in respect to the

control ﬂow of methods. As a case study (Buchmann

et al., 2011) revealed, software systems only contain a

low number of problems which require complex story

patterns. The resulting story diagrams nevertheless

https://wiki.eclipse.org/Xcore

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

are big and look complex because of the limited ca-

pabilities to express the control ﬂow.

Future work will cover the mapping of invariants

that are also elements of the SOIL model. The EMF

OCL implementation offers the tool Complete OCL

It allows for running invariants to check an EMF-

based model. Our goal is just reusing this mechanism:

From the invariants within one SOIL model, one text

ﬁle is generated comprising the respective OCL in-

variants that are directly runnable by Complete OCL.

Thus, invariants can be checked on demand. In (Hei-

denreich et al., 2008), the authors present an approach

that maps invariants in the context of data queries.

The proposed framework allows for mapping UML

models to arbitrary data schemas. The referring OCL

invariants result in sentences in corresponding declar-

ative query languages where semantical data integrity

on implementation level is forced.

6 CONCLUSION

This paper presented an approach of a tool chain that

allows for generating fully executable Java source

code from class models. In a projectional editor, class

models can be speciﬁed textually comprising struc-

tural elements (classes, associations, attributes), be-

havior (operations including body statements), and

invariants (constraints between model elements). To

represent the statements in the operations of the class

model, the textual language SOIL is used. The result-

ing Java code comprises code artifacts corresponding

to all class model elements, in particular fully imple-

mented method bodies. Therefore, no additional code

fragments inserted by the user are required.

This work is still ongoing. We already imple-

mented a primary version of the projectional text edi-

tor and large parts of the model-to-text transformation

that maps SOIL statements to Java code. Currently,

the model-to-model transformation which maps struc-

tural elements speciﬁed in the textual editor to Ecore

model elements is built. Future work will deal with

the integration of the target code of the model-to-text

transformation in the Ecore model which is gener-

ated as the target of the model-to-model transforma-

tion; to this end, annotations are going to play a ma-

jor role. Also the question whether these annotations

can be directly included by the model-to-text trans-

formation will be discussed. Regarding the model-

to-model transformation, supporting the backward di-

rection may pose a wise extension; that would allow

for propagating changes of the Ecore model to the

https://help.eclipse.org/latest/index.jsp?topic=%2Forg

.eclipse.ocl.doc%2Fhelp%2FCompleteOCLTutorial.html

SOIL model presented by the projectional editor. Fur-

thermore, the question of processing invariants in the

class model is going to be considered.

Eventually, after completing the implementation,

an evaluation of the approach will follow. For a range

of class models from various contexts, the size and

complexity of the respective SOIL models should be

compared with the corresponding Ecore models (only

containing structural information) and the Java source

code that has to be written manually after applying

the EMF code generator to the (partial) Ecore model.

In this context, an additional model-to-model trans-

formation may be useful that transforms (already ex-

isting) UML models to corresponding SOIL models;

this extension could allow for reusing models from

different existing projects and tools within the context

of the EMF environment.

ACKNOWLEDGEMENTS

The author wants to thank Jonas Adler for implement-

ing major parts of the model-to-text transformation

which maps the behavioral SOIL model elements to

Java code fragments in the scope of his bachelor’s the-

sis.

REFERENCES

Bank, M., Buchmann, T., and Westfechtel, B. (2021). Com-

bining a declarative language and an imperative lan-

guage for bidirectional incremental model transforma-

tions. In Hammoudi, S., Pires, L. F., Seidewitz, E.,

and Soley, R., editors, Proceedings of the 9th Interna-

tional Conference on Model-Driven Engineering and

Software Development (MODELSWARD 2021), pages

15–27. INSTICC, SciTePress.

Bettini, L. (2014). Developing user interfaces with EMF

parsley. In Holzinger, A., Cardoso, J., Cordeiro, J.,

van Sinderen, M., and Mellor, S. J., editors, Pro-

ceedings of the 9th International Conference on Soft-

ware Paradigm Trends (ICSOFT 2014), pages 58–66.

SciTePress.

Bettini, L. (2016). Implementing Domain-Speciﬁc Lan-

guages with Xtext and Xtend. Packt Publishing Ltd.,

Birmingham B3 2PB, UK, second edition.

Buchmann, T. and Schw

agerl, F. (2015). On a-posteriori in-

tegration of ecore models and hand-written java code.

In Lorenz, P., van Sinderen, M., and Cardoso, J., edi-

tors, Proceedings of the 10th International Conference

on Software Paradigm Trends (ICSOFT 2015), pages

95–102. INSTICC, SciTePress.

Buchmann, T., Westfechtel, B., and Winetzhammer, S.

(2011). The added value of programmed graph trans-

formations – A case study from software conﬁguration

management. In Sch

urr, A., Varr

o, D., and Varr

o, G.,

An Integrated Framework for Running Extended Class Models

editors, Applications of Graph Transformations with

Industrial Relevance – 4th International Symposium

(AGTIVE 2011), Revised Selected and Invited Papers,

volume 7233 of Lecture Notes in Computer Science,

pages 198–209. Springer.

uttner, F. and Gogolla, M. (2014). On ocl-based impera-

tive languages. Sci. Comput. Program., 92:162–178.

uttner, F. and Kuhlmann, M. (2008). Problems and en-

hancements of the embedding of OCL into QVT im-

perativeocl. Electron. Commun. Eur. Assoc. Softw. Sci.

Technol., 15.

Campagne, F. (2015). The MPS Language Workbench, vol-

ume I. Fabien Campagne, second edition.

Gogolla, M., B

uttner, F., and Richters, M. (2007). USE:

A uml-based speciﬁcation environment for validating

UML and OCL. Sci. Comput. Program., 69(1-3):27–

34.

Guermazi, S., Tatibouet, J., Cuccuru, A., Seidewitz, E.,

Dhouib, S., and G

erard, S. (2015). Executable model-

ing with fuml and alf in papyrus: Tooling and exper-

iments. In Mayerhofer, T., Langer, P., Seidewitz, E.,

and Gray, J., editors, Proceedings of the 1st Interna-

tional Workshop on Executable Modeling co-located

with ACM/IEEE 18th International Conference on

Model Driven Engineering Languages and Systems

(MODELS 2015), volume 1560 of CEUR Workshop

Proceedings, pages 3–8. CEUR-WS.org.

Heidenreich, F., Wende, C., and Demuth, B. (2008). A

framework for generating query language code from

OCL invariants. Electron. Commun. Eur. Assoc. Softw.

Sci. Technol., 9.

Madiot, F. and Paganelli, M. (2015). Eclipse sirius demon-

stration. In Kulkarni, V. and Badreddin, O., editors,

Proceedings of the MoDELS 2015 Demo and Poster

Session co-located with ACM/IEEE 18th International

Conference on Model Driven Engineering Languages

and Systems (MoDELS 2015), volume 1554 of CEUR

Workshop Proceedings, pages 9–11. CEUR-WS.org.

OMG (2008). MOF Model to Text Transformation Lan-

guage, v1.0. Object Management Group, Needham,

MA, formal/2008-01-16 edition.

OMG (2014). Object Constraint Language. Object Man-

agement Group, Needham, MA, formal/2014-02-03

edition.

OMG (2016). Meta Object Facility (MOF) 2.0

Query/View/Transformation Speciﬁcation. Object

Management Group, Needham, MA, formal/2016-06-

03 edition.

OMG (2017). Action Language for Foundational UML

(Alf). Object Management Group, Needham, MA,

formal/2017-07-04 edition.

OMG (2021). Semantics of a Foundational Subset for Ex-

ecutable UML Models (fUML). Object Management

Group, Needham, MA, formal/2021-03-01 edition.

Schr

opfer, J. and Buchmann, T. (2019). Integrating UML

and ALF: an approach to overcome the code gen-

eration dilemma in model-driven software engineer-

ing. In Hammoudi, S., Pires, L. F., and Selic, B.,

editors, Model-Driven Engineering and Software De-

velopment – 7th International Conference (MODEL-

SWARD 2019), Revised Selected Papers, volume 1161

of Communications in Computer and Information Sci-

ence, pages 1–26. INSTICC, Springer.

Schr

opfer, J., Buchmann, T., and Westfechtel, B. (2020).

A generic projectional editor for EMF models. In

Hammoudi, S., Pires, L. F., and Selic, B., editors,

Proceedings of the 8th International Conference on

Model-Driven Engineering and Software Develop-

ment (MODELSWARD 2020), pages 381–392. IN-

STICC, SciTePress.

Seidewitz, E. (2017). A development environment for the

alf language within the magicdraw UML tool (tool

demo). In Combemale, B., Mernik, M., and Rumpe,

B., editors, Proceedings of the 10th ACM SIGPLAN

International Conference on Software Language En-

gineering (SLE 2017), pages 217–220. ACM.

Steinberg, D., Budinsky, F., Paternostro, M., and Merks,

E. (2009). EMF Eclipse Modeling Framework. The

Eclipse Series. Addison-Wesley, Boston, MA, 2nd

edition.

The Fujaba Developer Teams from Paderborn, Kassel,

Darmstadt, Siegen and Bayreuth (2005). The Fujaba

Tool Suite 2005: An Overview About the Develop-

ment Efforts in Paderborn, Kassel, Darmstadt, Siegen

and Bayreuth. In Giese, H. and Z

undorf, A., editors,

Proceedings of the 3rd international Fujaba Days,

pages 1–13.

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