Comput Sci Res Dev (2015) 30:285301

DOI 10.1007/s00450-014-0258-8

SPECIAL ISSUE PAPER

Structured development of 3D applications: round-trip

engineering in interdisciplinary teams
Bernhard Jung Matthias Lenk Arnd Vitzthum

Published online: 1 July 2014

Springer-Verlag Berlin Heidelberg 2014

Abstract While structured software development processes are nowadays common-place, 3D applications are often
still developed in an ad-hoc and code-centric manner. This
state of affairs is somewhat surprising, as there are many
benefits to a more structured 3D development process. In
particular, model-based techniques with support for iterative
development could help to ensure the mutual consistency
of the code bases produced by the heterogeneous developer groups, i.e. 3D content developers and programmers.
However, a cultural gap exists between 3D content developers and programmers who use completely different tools
and terminologies. Common tools for model-driven development, for instance based on UML, are inadequate for the
often creatively oriented 3D content developers. This paper
presents a model-driven approach for the structured development of 3D applications in interdisciplinary teams based
on round-trip engineering. Abstract models of the application are specified in SSIML, a DSL tailored for the development of 3D applications. In a forward phase, consistent
skeletons of 3D scene models and program code are generated from the SSIML model. In a reverse phase, refinements of both the 3D scene model and program code are
abstracted and synchronized to result in an updated SSIML
model. This process is repeated in the subsequent iterations.
Several examples of 3D application development on diverse
B. Jung M. Lenk (B)
Virtual Reality and Multimedia, Institute of Computer Science,
Technical University Bergakademie Freiberg, Freiberg, Germany
e-mail: lenk@informatik.tu-freiberg.de
B. Jung
e-mail: jung@informatik.tu-freiberg.de
A. Vitzthum
Berufsakademie Sachsen, University of Cooperative Education,
Dresden, Germany
e-mail: arnd.vitzthum@ba-dresden.de

platforms including Web, immersive virtual reality, and augmented reality on mobile devices demonstrate the versatility
of our approach.
Keywords Model driven development Round-trip
engineering 3D applications Virtual reality Augmented
reality Model transformation Model differences Model
merging

1 Introduction
Interactive 3D applications including virtual reality (VR) and
augmented reality (AR) play a central role in many domains,
such as product visualization, entertainment, scientific visualization, training and education. So far, however, the use
of model-driven development (MDD) approaches and visual
modeling languages such as UML is far less common than
in the development of other kinds of software. Arguably, this
lack of acceptance of MDD approaches can be attributed to
the specifics of the 3D application development process.
First, 3D development is an interdisciplinary process.
Essentially, two groups of developers are involved who use
completely different tools and terminologies: 3D content
developers and programmers. Misunderstandings between
the developer groups can lead to an inconsistent system
implementation [25]. For example, if the 3D content developer does not follow the conventions for the naming of
3D objects, the programmer cannot address these objects
properly via program code. While MDD approaches may
be instrumental in avoiding such misunderstandings, general
purpose tools, for instance based on UML, may be appropriate for programmers, but are certainly inadequate for the
often creatively oriented 3D developers. More promising

123

286

seem domain-specific languages (DSL) specifically geared

towards 3D development.
Second, 3D applications are usually developed in a highly
iterative fashion. Although generally desirable for all kinds of
software, support for an iterative development process is particularly relevant in the 3D domain. Round-trip engineering
(RTE) [2,3,11,22] is a model-driven software development
methodology that combines forward engineering (modelto-code transformations) with reverse engineering (code-tomodel transformations) and synchronizations between code
and model to support iterative development. RTE has proven
useful in the development of conventional software as
exemplified by several existing integrated tools supporting the simultaneous editing and synchronization of UML
diagrams and program code. However, due to the concurrent development process in conjunction with the preference
for very different modeling/programming tools between 3D
designers and programmers (and software designers), the use
of a (yet to be developed) integrated tool for the various
tasks seems not advisable for 3D development. Instead, an
approach is preferable where the distinct developer groups
each can employ their tools of choice.
Third, 3D applications are often implemented for multiple platforms, from ordinary PCs, over mobile devices, up to
immersive virtual reality installations. A possible approach
could be the use of cross-platform 3D engines. A disadvantage is that this requires the installation of a 3D engine at
the users site. In web environments, however, users may
not have administrative rights to install the necessary plugin. In highly specialized environments, such as CAVEs, a
suitable version of the 3D engine may not be available.
Therefore, 3D applications often need to be developed with
respect to different programming environments, using different programming languages. During the iterative development cycle, cross-platform synchronization should be supported.
In this paper we describe a round-trip engineering approach for the model-driven, iterative development of multiplatform 3D applications. Section 2 introduces this approach
at a conceptual level. In Sect. 3, a longer example of modeldriven, round-trip development for 3D applications is given,
with WebGL-enabled web browsers and immersive virtual
reality as deployment platforms. Section 4 presents a second
example that demonstrates the development of a 3D application in a web version as well as an augmented reality version
on the Android platform. Section 5 gives an overview of the
implementation of our round-trip engineering process, covering transformations between model and code, synchronization procedures during iterative development, and adapter
code for the different target platforms. In Sect. 6 we discuss
our approach and present results from an extensive case study
on 3D development in a larger interdisciplinary team, before
we finally conclude in Sect. 7.

123

B. Jung et al.

2 3D development with round-trip engineering

This section gives a conceptual overview of the the proposed round-trip engineering approach for multi-platform 3D
development (see Fig. 1). The involved developer groups are:
software designers, who design an abstract model of the 3D
application; 3D content developers responsible for 3D modeling; and programmers who implement the application logic
for the specific target platforms. For the purposes of this conceptual overview, we assume WebGL-enabled web browsers
with JavaScript as programming language and an immersive virtual reality CAVE programmed in C++ as target platforms. Another target platform supported by our approach
are Android-based smartphones and tablets with Java as programming language. Details on the DSL used for application
modeling, forward and reverse transformations, as well as
other implementation aspects are given in later sections.
Development begins with the specification of an initial
abstract model of the 3D application through the software
designer. As modeling language, we use the scene structure
and integration modeling language (SSIML) [25], a DSL
tailored for 3D applications. SSIML models comprise both
an abstract description of the 3D scene and a specification

Fig. 1 Round-trip engineering for concurrent development of 3D

applications on multiple platforms (Web, CAVE, Android)

Structured development of 3D applications

of the application logic. Cross-references (or interrelationships) between the 3D scene description and the application components specify the events that may be triggered by
user interaction with a 3D object and need to be handled by
the application logic. Note that as an iterative development
process is assumed, it suffices that the initial SSIML model
specifies only a rough first version of the application that can
be refined in later iterations [24].
During the forward engineering phase of the development process, the initial SSIML model is transformed to
JavaScript, C++ and X3D code skeletons. The 3D content
developers task is to model the individual 3D objects and
their composition in a single X3D scene while programmers
elaborate the auto-generated JavaScript and C++ code. In the
proposed development process, 3D designers and programmers may work concurrently, where both are using different
tools appropriate to their task. For example 3D designers
could model the 3D objects using tools like 3DS Max or
Blender, while the programmers use an IDE or a simple code
editor.
However, as software development is a non-trivial process,
the implementation of 3D and program code may be inconsistent with the current SSIML model in various ways: the
implementation could be incomplete or incorrectly reflect the
model, for example by using different names for 3D objects,
application classes or their attributes. Moreover, the implementation may also add parts to the application that may reasonably be reflected in future versions of the SSIML model.
In order to consolidate the various artifacts, the implementation code is then reverse engineered and synchronized with
the current SSIML model. For each inconsistency between
the SSIML model and the current state of the implementation it has to be decided whether the implementation is incorrect or incomplete or whether the implementation improves
the overall application in some way and should therefore
be reflected in the next version of the SSIML model. For
instance, on the one hand, say, the 3D designer may not care
too much about attribute names as only the visual appearance
of the 3D objects is usually important for his task. Here, the
mismatch should be considered as incorrectness of the implementation. On the other hand, a programmer may feel that a
class name in the SSIML model is inconsistent with the conventions of her programming language and uses a different
class name instead. Here, the changed attribute name may be
adopted in the next iteration of the SSIML model. To synchronize the various code bases and the SSIML model, we
propose two distinct approaches (Sect. 5.2), which provide
different degrees of interactive control for the responsible
software designer.
Once the implementation is synchronized with the SSIML
model, possibly resulting in updates to the model, the software developer may now further expand the SSIML model.
This completes the first cycle of the round-trip engineer-

287

ing process. From the updated SSIML model, again, code

is generated in a forward step. Of course, during the forward
step it is ensured that the newly generated code still contains
the implementation details of the previous iteration, which
means that no code is lost during re-generation. This roundtrip process may be repeated for several iterations, until a
final version of the 3D application is reached.

3 Example: 3D development for web and CAVE

We introduce a small example to better illustrate the proposed 3D development process. The 3D scene is composed
of the following 3D objects: a car chassis (Fig. 2a), separated windows (Fig. 2b) and different rim types (Fig. 2c).
The application shall provide an interactive part to configure
the car, in particular changing the cars color, replacing the
rims and toggling the visibility of the windows. Interaction
is achieved by directly clicking on the respective 3D objects
within the 3D scene or by using external GUI elements.
3.1 Modeling 3D applications with SSIML
In the proposed 3D development process, development
begins with the specification of an abstract model through
software designers. The application model is specified in the
Core component of SSIML, which is a language family of
graphical DSLs for 3D application development [25].
A SSIML model is composed of a scene model which
allows for modeling abstract 3D scene graphs and an interrelationship model to create associations of scene graph elements with application components. The 3D scene graph is
composed of parent and child nodes, with some important
ones being the scene root node, group nodes to structure the
scene graph, object nodes which represent a specific geometric 3D object (for instance, a car chassis) and attribute
nodes, for example to specify the texture or material of an
object. Group and object nodes can act as child and parent
nodes for other nodes, whereas attribute nodes have no further children. Special attribute nodes, such as sensor nodes,

Fig. 2 a The stand-alone car chassis with b separated windows, c one

of several wheel types

123

288

B. Jung et al.

3.2 Developing the 3D application

In the current example, a web version and a CAVE-version
of the 3D application are to be developed. Both versions use
X3D as scene description language, whereas the application
is implemented in JavaScript and C++ respectively. In the
following subsections, we sketch code mapping+ from each
language to the SSIML model.
3.3 Generation of X3D code from SSIML models

Fig. 3 A SSIML model contains scene elements (upper area), which

later result in 3D code. Artifacts in generated application code, such as
classes or event handlers, stem from SSIML application elements and
interrelationships to scene model elements (lower area)

are used to trigger events within the 3D scene to notify application components within the interrelationship model. For
instance, when a SSIML object node is connected to a touch
sensor, this sensor attribute can notify an associated application class about an event, like a mouse click.
The car configuration application can be modeled using
SSIML as depicted in Fig. 3. Scene model elements which
will mainly result in the X3D code are shown in the upper
area. The scene root node has a light and viewpoint attribute
and contains the group node carGroup. This group node
contains a chassis object which in turn contains four
wheel objects and the windowpanes object. Elements of
the SSIML interrelationship model (displayed in the lower
area) will later be translated to application code. The application class MaterialConfigurator is associated with the
respective material attributes of the chassis and windowpanes
in order to change their color and transparency values. The
touch sensor attribute windowTouchSensor is connected
to the windowpanes object and triggers a CLICKED event
to the application class when the user clicks on the windowpanes. The second application class PartsConfigurator can
access the chassis object in order to replace its content, concretely to replace the four wheels by a different kind of wheel.

123

SSIML scene model elements (Fig. 3, upper area) are mapped

to X3D nodes in the following way: the SSIML model and the
scene root node are transformed to an X3D tag and a scene
tag, respectively. Each SSIML group node, for example the
carGroup, is mapped to a corresponding group tag in X3D.
SSIML object nodes are transformed to X3D inline nodes.
A generated X3D inline node links to the X3D file specified
in the encapsulatedContent attribute of the SSIML object,
or, if that attribute is undefined, to a newly generated URL.
Additionally, an X3D transform node is generated for these
inline nodes in order to support scene composition activities
such as translating and rotating the 3D objects to their final
positions in the complete 3D scene (Listing 1).
To recognize artifacts (such as SSIML elements, X3D
nodes or program entities) during the round-trip process, each
artifact is associated with a unique ID. This ID is bound to its
element during the complete development process and may
not be modified or removed. Elements without ID will later
be treated as newly added elements. During the X3D code
generation, the ID from the SSIML element is passed to the
X3D node. To store IDs in the X3D code we use XML comments, each preceding its referred X3D node. The generated
X3D skeleton can already be rendered in X3D viewers as a
static scene without interaction.
3.4 Developing the 3D web application
Web deployment of the car configuration tool makes use of
X3D as scene description language and JavaScript as programming language. The X3DOM framework is used for
integration of X3D content into HTML pages [5]. Modern,
WebGL-enabled web browsers can display X3DOM applications natively, without the need for installing a plug-in. The
generated and refined X3D scene can be included in HTML5
documents and rendered in modern web browsers (although,
in our example, the application logic still needs to be implemented in JavaScript).
Similar to X3D code, a corresponding JavaScript code
skeleton (Listing 2) is generated to access the 3D scene. The
generated JavaScript functions emulate the class-oriented
structure of programming languages such as Java or C++, in
order to enable consistent multi-platform adaption. JavaScript

Structured development of 3D applications

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

289

<! - - id =938 c3fb8 - b229 -40 d2 -9044 - c 5 a 2 6 7 2 7 b c 0 9 - - >

< X3D v e r s i o n = " 3.0 " p r o f i l e = " I n t e r a c t i o n " >
<! - - id = a1b5540e -4 f9f -4674 -8 e01 - 1 8 7 7 a 3 7 2 1 3 b 1 - - >
< Scene >
<! - - id = cb7960db -0141 -4 f60 - ae3d -552 a b 6 1 3 d e c d - - >
< W o r l d I n f o t i t l e = " C a r C o n f i g u r a t o r " info = " " DEF = " ... " > </ WorldInfo >
< T r a n s f o r m DEF = " g e n e r a t e d T r a n s f o r m 1 " t r a n s l a t i o n = " 0 0 0 " ... >
< G r o u p DEF = " c a r G r o u p " >
< T r a n s f o r m DEF = " g e n e r a t e d T r a n s f o r m 2 " t r a n s l a t i o n = " 0 0 0 " ... >
< I n l i n e DEF = " c h a s s i s " url = " c h a s s i s . x3d " > </ Inline >
< T r a n s f o r m DEF = " g e n e r a t e d T r a n s f o r m 4 " ... >
< I n l i n e DEF = " w h e e l _ 0 " url = " w h e e l s . x3d " > </ Inline >
</ Transform >
< T r a n s f o r m DEF = " g e n e r a t e d T r a n s f o r m 5 " ... >
< I n l i n e DEF = " w h e e l _ 1 " USE = " w h e e l _ 0 " > </ Inline >
</ Transform >
...
</ Transform >
</ Group >
</ Transform >
< D i r e c t i o n a l L i g h t DEF = " l i g h t " c o l o r = " 1 1 1 " ... > </ D i r e c t i o n a l L i g h t >
< V i e w p o i n t DEF = " v i e w P o i n t " p o s i t i o n = " 0 0 10 " ... > </ Viewpoint >
</ Scene >
</ X3D >

Listing 1 X3D code skeleton that has been generated from the SSIML model (Fig. 3). Inline nodes, such as the chassis object, are used to include
further 3D geometries. Some IDs and node attributes have been removed

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

function MaterialConfigurator ( ) {
var c h a s s i s C o l o r = d o c u m e n t . g e t E l e m e n t B y I d ( c h a s s i s _ _ c h a s s i s C o l o r );
var w i n d o w T r a n s p a r e n c y = d o c u m e n t . g e t E l e m e n t B y I d ( w i n d o w p a n e s _ _ w i n d o w T r a n s p a r e n c y );
this . w i n d o w p a n e s _ C L I C K E D = f u n c t i o n ( obj ) {
};
// ! I n s e r t f u r t h e r a p p l i c a t i o n code below !//
// ! I n s e r t f u r t h e r a p p l i c a t i o n code above !//
}
function PartsConfigurator ( ) {
var c h a s s i s = r e t u r n d o c u m e n t . g e t E l e m e n t B y I d ( c h a s s i s );
...
}
f u n c t i o n init ( ) {
var m a t e r i a l C o n f i g u r a t o r = new M a t e r i a l C o n f i g u r a t o r ( );
var p a r t s C o n f i g u r a t o r = new P a r t s C o n f i g u r a t o r ( );
d o c u m e n t . g e t E l e m e n t B y I d ( w i n d o w p a n e s ). a d d E v e n t L i s t e n e r ( " c l i c k " ,
m a t e r i a l C o n f i g u r a t o r . w i n d o w p a n e s _ C L I C K E D );
...
}

Listing 2 Generated JavaScript code skeleton with functions and member variables to access the 3D scene. Comments, where IDs are stored, have
been removed for better readability

code fragments are related to the original SSIML model of

Fig. 3 in the following way: the SSIML application components MaterialConfigurator and PartsConfigurator are translated to JavaScript functions of the same names which create suitable JavaScript objects. The MaterialConfigurators
action relationships to the original SSIML attributes windowTransparency and chassis Color result in member variables
of the JavaScript object. These two variables address X3D
material nodes which can be used to modify the appearance

of the windows and the chassis, respectively. To realize touch

sensors with X3DOM, appropriate event listeners (conforming to the HTML event model) are attached to the respective
X3D nodes [5]. This event handling mechanism is common
on many platforms and therefore can easily be adapted. For
the windowpanes object, which is connected to a touch sensor
in the SSIML model, a corresponding event listener is generated in the MaterialConfigurator function and registered in
the init() function. The CLICKED event from the SSIML

123

290

example is mapped to an HTML click event. Further application logic, for instance to set the transparency value of the
material, will be manually programmed by elaborating the
generated code stubs, possibly by also defining additional
helper functions. Like generated X3D elements, generated
JavaScript elements are also assigned IDs for tracking. The
mapping from SSIML elements to corresponding JavaScript
elements is more complex than the mapping to X3D nodes,
since multiple SSIML elements may contribute to the same
JavaScript function. For example, the event handler registration within the init() function is comprised of the concerned
object (namely windowpanes), the attached sensor and the
relationships which connect the related objects (Listing 2).

B. Jung et al.

The second platform supported by our round-trip environment is an ultra high-resolution CAVE consisting of 25 projectors (24 full HD plus 1 SXGA+) that offers a much more
immersive experience than the web platform. The user can
interactively configure the real sized car by using GUI elements on an iPad and by using a flystick for 3D interaction. The 3D scene (Sect. 3.3) is converted from X3D to the
VRML format.1 Functionalities to load, access and display
the 3D scene or to realize the event handling mechanism
are implemented with respect to corresponding libraries of a
proprietary CAVE framework. The structure of the generated
C++ application is similar to the JavaScript code (Sect. 3.4).
SSIML application classes result in respective C++ classes.
Relevant member variables and method stubs, such as the
windows_touch event handler are automatically generated.
The programmer can rely on the generated interface to access
the 3D scene in a correct manner.

application that might crash. Second, 3D content developers,

having the CAVE application in mind, add a high-detail background to the 3D scene which is however not suitable for the
web application due to the smaller graphics processing power
in web browsers. And third, 3D content developers remove
the specified directional light source (maybe because they
prefer other light source types in the present scenario). Model
relevant changes, of course, may stem from JavaScript programmers, too. For instance, a JavaScript developer renames
the class element MaterialConfigurator to ColorConfigurator since in her opinion only color values are addressed
and modified.
In the reverse engineering step, the now inconsistent code
bases must be merged into a consistent SSIML model. Modifications of the various artifacts can be detected using diff
algorithms. Model-relevant changes, introduced by 3D content developers and programmers, can either be accepted or
rejected. This may occur in a more automatic way, for example by configuring merge priorities, or in a more interactive
fashion, for example based on suitable visualizations (Fig. 4).
A detailed description for synchronization can be found in
Sect. 5.2.
With respect to the example, the deletion of the directional
light source and the addition of the high-detail background
are rejected2 while renaming the windows 3D object and
the application class MaterialConfigurator is accepted for
inclusion in the next iteration of the SSIML model. Software
engineers can now apply further changes to the consolidated
SSIML model, for instance by adding a spoiler object. During
the next forward iteration, manually developed source code
and changes from the SSIML model will be re-generated to a
consistent application. Figure 5 shows the final application,
in the web3 (Fig. 5a) and CAVE variants (Fig. 5b).

3.6 Multi-platform round-trip engineering

4 Example: augmented reality development for Android

During the edit phase, 3D content developers and programmers elaborate the generated code skeletons. However, edits
may occur that do not conform to the SSIML model. In
order to detect these inconsistencies and to derive an updated
SSIML model, the different code bases need to be synchronized in the reverse phase of the RTE process.
For our car configurator example we assume the following
three model-relevant changes to the code, which represent the
basic operations update, insert and delete: First, 3D content
developers rename the 3D object windowpanes to windows. Since JavaScript and C++ programmers rely on the
original naming, the windowpanes object is no longer accessible from the program code, which results in an inconsistent

In this section we give an example demonstrating the multiplatform development of a 3D application as an augmented
reality version on Android devices and a version for the web.
Augmented reality (AR), in contrast to pure virtual reality,
interactively enriches the real world with virtual 3D objects
[4]. AR applications can be found in many domains, such
as medicine, advertising, (scientific) visualizations, product configuration, gaming, safety or training simulations.
Todays pervasive and powerful mobile devices, such as
smartphones and tablet computers, with built-in cameras
have become popular platforms for AR applications. We use

3.5 Developing the CAVE application

As the predecessor of the X3D format, VRML documents describe

the same scene structure as X3D documents, but differ in their textual
representation.

123

CAVE developers may still programmatically add a high-detail background, but the background object will not be part of the platformindependent SSIML model.

Available at: http://elrond.informatik.tu-freiberg.de/roundtrip3d/

carconfigurator.xhtml, (2014).

Structured development of 3D applications

291

Fig. 4 The difference

visualization for the car
configuration application after
one iteration. Modifications to
elements are indicated by
background colors and little
decals. The windowpanes
object has been renamed to
windows and the application
class MaterialConfigurator to
ColorConfigurator. The
viewpoint and the background
(stage) are marked as deleted
and added, respectively

common Android devices to realize video see-through AR,

with marker based tracking from Vuforia by Qualcomm4 and
a third-party 3D renderer5 with basic scene graph support.
Our proprietary AR library adapts these two low level frameworks to the generated AR code skeleton (which is structurally similar to the generated web and CAVE code).
Although our approach allows for deploying the car configuration example (Sect. 3.1) for the AR platform with little
effort, we introduce a further example which is more typical for AR applications. This scenario is a simulation of a
robot and has initially been created to illustrate our round-trip
approach for 3D web applications [20]. In the AR scenario,
the 3D scene contains a model of an industrial robot and its
work space, which contains a work table and is surrounded
by a fence. Two buttons on a console allow for interactively
rotating the robot arm around its vertical axis. Both virtual
objects, the work area including the robot and the control console, can be independently arranged by placing markers in the
real world. The AR application could be used for instance to
preview and assess real robot installations in manufacturing
environments.
4

http://www.qualcomm.com/solutions/augmented-reality, (2014).

https://github.com/MasDennis/Rajawali, (2014).

Besides SSIML/Core for VR applications, SSIML/AR

facilitates modeling AR applications. The scene model as
well as the interrelationship model (Sect. 3.1) from SSIML/Core are extended by respective elements from SSIML/AR
[23]. Originally, SSIML/AR allows for modeling AR specific
artifacts, for example by specifying concrete VideoTrackers and SceneUpdaters within the interrelationship model to
establish basic tracking relations from real world objects to
virtual objects. Since our AR library not only glues 3D rendering and tracking with the generated code but also hides
tracking mechanisms from the programmer, there is no need
to define such tracking relations in the abstract domain model.
Thus, AR applications can be specified by SSIML models
that are structurally very similar to SSIML models for web
and CAVE applications. In fact, as discussed below, SSIML
models for AR applications can also be used for development
of web and CAVE versions of the software.
Figure 6 depicts the SSIML model for the AR robot
scenario. The RobotScene root node contains the mainGroup node which contains two nodes from SSIML/AR,
so called hybrid objects. A hybrid object consists of a virtual
and a real component. While the virtual component is derived
from the SSIML object node and represents the geometric 3D
object, the real component links to an ID of an AR marker

123

292

B. Jung et al.

assigning concrete marker IDs to them. Likewise, SSIML/AR models can be used to generate web or CAVE code
by simply ignoring the marker information.
Figure 7 shows the final AR application next to the web
version of the robot scenario,6 both generated from the same
SSIML model (Fig. 6). Round-trip development, as described
in Sect. 3.6, is also supported for the AR platform.

5 Implementation overview
In this section we first briefly describe the implementation of model-to-code and code-to-model transformations in
Sect. 5.1. A detailed description of the involved models and
transformations is given in [19]. Section 5.2 describes two
approaches for model and code synchronization including
conflict handling. Section 5.3 gives an overview of adapters
we use to embed our generated code structures in existing
runtimes and frameworks.
All functionalities to trigger transformations between
models and code as well as the synchronization between
them are accessible from within our Eclipse-based Roundtrip environment (Fig. 8).
Fig. 5 a 3D application in Web Browser; b CAVE-version of the application

that can be placed in the real world. In our AR framework,

both components are registered with each other. The coordinates of the real component (obtained from the marker) are
mapped to the coordinates of the virtual component in real
time so that the virtual component superimposes the real one
[23]. The 3D scene is modeled in a straightforward manner:
the hybrid object robotArea references a marker and contains the workspace group node, which in turn contains
objects for fence and work table geometries. The robot
group, another child of the hybrid object robotArea, contains transform nodes to manipulate object nodes which link
to the robots 3D geometries. The hybrid object controlPanel maps the console geometries to a marker and contains
two buttons with touch sensors in order to send PRESSED
events to the application class RobotControl. In the generated Java code, these sensors result in event handler stubs,
where programmers implement functionalities to modify the
transformation node rotationBase to rotate the robot vertically.
Encapsulating tracking functionalities in our library on
the one hand simplifies modeling new AR applications with
SSIML/AR and on the other hand allows for easily migrating existing SSIML/Core models to AR models: SSIML/AR
models can be derived from SSIML/Core models by only
re-labeling some of the object nodes as hybrid objects and

123

5.1 Transformations between model and code

Round-trip engineering combines model-driven forward
engineering with reverse engineering as well as a synchronization phase (see Sect. 5.2). In our implementation, the
overall, complex conversion between model and code is realized through a sequence of simpler transformations (Fig. 9).
During forward engineering, the SSIML model is first converted into an intermediate model (IM) and merged into a persistent IM.7 The persistent IM stores all data and metadata
of the complete application, including all model and code
artifacts. From the persistent IM, target-language specific
abstract syntax trees (ASTs) are created which, in turn, are
serialized to code in various programming languages (currently X3D, JavaScript, Java, C++). The ASTs contain both
representations of SSIML model elements and code artifacts
from previous iterations in order to allow for re-generation
of code from an altered model. In contrast to the generation gap pattern that strictly separates generated code from
manually programmed code extensions, this approach allows
for the detection of changes to model relevant artifacts during the reverse phase. These changes can then be applied to
the SSIML model and transferred to other platforms. Furthermore, model elements (and changes applied to them) are
6

http://elrond.informatik.tu-freiberg.de/roundtrip3d/RobotScene/
robot.html, (2014).

In the forward phase of first iteration, the persistent IM is created as

a copy of the IM generated from the SSIML model.

Structured development of 3D applications

Fig. 6 The SSIML model for the AR robot application. Scene model
elements are located on the outer area while elements from the SSIML
interrelationship model are positioned on the dark gray, inner area. Both

293

hybrid nodes, namely controlPanel and robotArea, contain marker

information, to automatically map virtual and real world objects in the
generated AR application

with Java using EMFs reflection API [21]. Conversions

between IMs and ASTs are implemented in ETL, a hybrid
transformation language with declarative rules and imperative bodies [16]. Code serializers and parsers to convert
between the ASTs and program code are generated through
Xtext [9] based on a grammar and a meta model of the target
platform. Since serializers and parsers only need to recognize model relevant language artifacts, it is not necessary to
semantically distinguish between all constructs of the target language. Instead, it suffices that the meta models and
grammars cover relevant subsets of the target platform [12].
5.2 Synchronization
Fig. 7 Left in the AR robot scenario, 3D objects are registered with
markers, as specified in the SSIML model. Right the web version of the
application also allows for rotating the robot by pressing the buttons

directly reflected within serialized source code. Therefore,

inconsistencies after code re-generation are limited to references to updated elements within the manually programmed
code.8
In the reverse phase, this sequence of conversions is performed in backwards order. All edits of the SSIML model and
user code are merged into this persistent IM during the forward and, respectively, reverse phases. Forward and reverse
transformations between SSIML and the IM are performed
8

Currently, we do not provide further refactoring mechanisms in our

round-trip framework.

Synchronization of models and code is a core process in

round-trip engineering. Edits of the model must be reflected
in the re-generated code, and code-level edits may result in
updates to the model. In our case, the SSIML model, 3D
code, and application code (possibly for several platforms)
need to be synchronized. As software designers, 3D content developers, and programmers work with different tools
appropriate to their tasks, model and code edits cannot be
traced in real-time and thus synchronization must occur in a
non-simultaneous manner.
Figure 10 conceptually depicts the SSIML language and
covered parts of 3D scene and application languages. Modifications to code artifacts, whether in 3D code or application code, result in inconsistencies between the model
and its implementation. During the synchronization phase,

123

294

B. Jung et al.

Fig. 8 The SSIML tool enables

the visual creation of SSMIL
models and integrates round-trip
capabilities for forward and
backward engineering, diff
visualization, and interactive
synchronization

Fig. 9 Multi-platform RTE implementation with involved models and transformations. This workflow also depicts the semi-automatic synchronization process, without further user interaction, on the intermediate stage

it has to be decided whether these inconsistencies are used

to update the specification or whether they are discarded
as incorrect implementation. Furthermore, interrelationships
between SSIML scene elements and SSIML application elements (Fig. 6, connections in dark gray area) correspond
to scene access and event handling source code artifacts
(Fig. 10, dark gray overlapping area). SSIML elements within
this area have corresponding counterparts in both 3D code
and application code. Concurrent modifications of corresponding artifacts in 3D and application code may lead to
merge conflicts. Merge conflicts need to be resolved during
the synchronization phase, either by applying just one of
the options or by discarding all changes. 3D scene elements
and code artifacts which are not covered by the specification

123

(Fig. 10, outside the SSIML language) cannot cause inconsistencies or conflicts and therefore can be developed independently from each other.9
In iterative round-trip development, synchronization can
also be used as a verification method: when no inconsistencies or merge conflicts are detected during synchronization, a
consistent version of the 3D application has been developed.
Synchronization comprises four phases: comparison, conformance checking, merging and reconciliation [15]. In the
following, we propose two approaches for model synchro9

In case of multi-platform development, inconsistencies may also arise

between implementations for the different platforms. Of relevance are
only inconsistent implementations of SSIML elements.

Structured development of 3D applications

295

3D code

SSIML
(possible
specification to
implementation
inconsistencies)

Interrelationships
(possible
merge conflicts)
application code

Fig. 10 Abstract illustration of language overlappings: elements of the

SSIML language (middle circle) correspond to 3D modeling language
elements (upper circle) and artifacts of application languages (lower
circle). Modifications to these elements in source code cause inconsistencies between model and implementation. SSIML interrelationship
elements are reflected in both, 3D and application code. Concurrent
modifications of interrelationship elements may cause merge conflicts

nization, which primarily differ in the first two phases,

namely comparison and conformance checking: the first
approach implements a semi-automatic merge process using
ID-based difference detection. It needs to be configured once
by domain experts and then automatically resolves conflicts
without further user interaction. The second synchronization
approach is an interactive one. It does not need to assign
IDs to code and model elements and instead uses a more
generic matching algorithm. Detected differences are graphically presented in SSIML notation. Software designers can
then interactively accept or deny modifications and resolve
conflicts.
5.2.1 Semi-automatic merging
In our RTE approach, as shown in Fig. 8, all merging occurs
on the level of intermediate models. Concretely, IMs (intermediate models) derived from the SSIML model or program code are merged into the persistent IM that represents
the complete 3D application. In the semi-automatic merging
approach, not only merging but also difference detection is
performed at the intermediate level. As all difference detection and merging occurs between the same type of models,
it suffices to implemented only one algorithm each for diff
and merge. For reliable matching of elements in different
models, unique identifiers (Sects. 3.3 and 3.4) are added to
model elements and serialized into source code [1]. During
the editing phase, identifiers may not be modified, except for
the deletion of the respective code artifact. Newly added code
constructs obtain a UUID during the reverse transformation
into their intermediate representation.
In the comparison phase, an ID based diff algorithm is run
on each IM with the persistent IM resulting in a difference
model [6]. Within this difference model, corresponding ele-

ments (whether modified or not) from different languages are

identified and mapped to each other. The diff algorithm also
determines the modification type for each element relative
to its previous value in the persistent IM, with modification
types being update, insert or delete.
For automatic resolution of inconsistencies and conflicts
(cf. Sect. 5.2) an additional configuration is used. This configuration maps every SSIML element with a priority to every
applicable target language. The priority defines the preference of element modifications in the respective language.
This configuration has to be defined by domain experts. For
instance, a domain expert could decide that modifications of
an X3D inline node (originating from a SSIML object node)
are preferred over modifications of the respective JavaScript
element (access to domnode). Since software designers can
change the configuration, the synchronization phase is not
fully but semi-automatic.
The semi-automatic merge approach was tested in a longer
student project (see Sect. 6.1). However, participants concluded that although it is convenient to have a merge automatism, the priority-based configuration to select preferred
modifications was not considered as flexible and transparent
enough. Furthermore, automatic modifications to the code
cannot easily be comprehended at the model stage, since each
element from the derived model has to be compared to each
one from the original model. To address these concerns, our
second synchronization approach implements a more user
controlled merge process.

5.2.2 Interactive merging

The second synchronization approach combines graphical visualization of differences with an interactive merge
process. This approach aims to provide functionalities for
interactive conflict resolution and thus we assume that all
languages are merged at once (although sequentially merging code changes from every language into the model is also
possible).
The approach uses more complex, for example similaritybased algorithms, for difference detection. Therefore, no
unique IDs need to be serialized into the source code and thus,
code pollution is avoided [17]. Difference detection takes
place at the AST level which is more suitable for similaritybased element matching than the more abstract IM level
(Fig. 11). Each AST derived from edited code is compared
with its version before the edit. Further, all ASTs derived
from the various source codes are compared with each other
which requires a generic diff algorithm. The SiDiff framework [13] offers generic and highly configurable matching
algorithms, but requires an extensive configuration. Instead,
we chose EMF compare [6] that provides similarity-based
matching and extended this framework with basic setup capa-

123

296

B. Jung et al.

5.3 Adapter libraries and code skeleton structure

Fig. 11 Multi-platform RTE with diff detection of abstract syntax trees

of the same type, before and after the editing phase. Using the SSIMLbased diff visualization, software designers decide about acceptance of
changes and resolve conflicts. Based on these decisions, intermediate
representations of the implementations are merged into the persistent
IM

bilities to correctly identify matching elements in different

versions of an AST and in different AST types.
Results from the diff phase are presented to the software designer in SSIML notation. Elements are graphically
annotated with difference information, according to recognized modifications. To illustrate the notation of conflicts and
interaction possibilities within our round-trip environment
(Fig. 12), we assume a merge conflict for the car configuration
application. For example, the original SSIML object windowpanes has been renamed to windows by 3D designers and to panes by JavaScript developers. The detected
conflict is highlighted in the graphical SSIML difference
view. Software designers now decide (ideally in a discussion
with the concerned developers) how conflicts are resolved,
either by applying one or none of the changes. Furthermore,
non-conflicting modifications can be accepted or rejected to
restore the original version of the respective SSIML element.
The latter can be useful when developed solutions differ to
much from their original specification.
In the next forward phase, the updated SSIML model
serves as new specification for platform developers. Difference information from the synchronization phase may further
help developers to comprehend changes in the re-generated
source code, similar to log files in common distributed version control systems.

123

While there is a clear mapping from SSIML scene graph

elements to X3D nodes, the mapping from SSIML interrelationship model elements to application code artifacts is more
complex. Several SSIML elements result in various code artifacts. Referring to the car configurator example (Fig. 3), the
windowpanes object, touch sensor and the event relationship to the application class, result in interlaced JavaScript
statements (Listing 2), in particular an event handler registration (line 20) and the associated method (line 4). Furthermore, every individual platform provides its own API/framework to develop 3D applications, with crucial aspects concerning event handling and scene access. Although the general concepts to cover these aspects are present on all platforms, the specific APIs can be very different. More concretely, on the Web, X3D node access is granted to JavaScript
through the DOM and event handling conforms to the HTML
event model [5]. On the Android platform, in contrast, the
Java-based 3D library only provides basic input mechanisms.
Therefore, we implemented adapter libraries for each platform that provide a more uniform way for scene access and
event handling across the different platforms (Fig. 13, left).
Generated application code skeletons have the following
structure (Fig. 13, right): in an initialization part, event handlers are registered and the scene is loaded, etc. Hook methods and further user defined methods allow the workflow to be
extended. SSIML application classes either result in classes
of the respective platform (C++ or Java), or in first-class functions in JavaScript to emulate class oriented structures. Furthermore, member variables to access the scene are defined,
as specified in the SSIML model. Further code to implement
the application can be stored in hook and event handler methods or in additional user defined methods. Within initialization sections, such as C++ constructors, Android onCreate
methods or JavaScript initialization functions, we use protected regions which allow for more abstract meta models
and grammars of the platform. By providing hooks, these protected regions can be used without restricting programmers.
A further advantage of the similar structure of JavaScript,
C++, and Java code is that the implementation of the transformation pipelines also becomes more uniform and thus more
re-usable. For example, the AST meta models for JavaScript,
Java, and C++ can partially be re-used, and similarly the
transformation rules for conversion between IMs and ASTs.
Overall, the adapter code makes model-to-code mappings
during multi-platform development much more manageable.

6 Discussion
Many existing RTE tools, such as UML LAB or Together,
offer support for software development with focus on simul-

Structured development of 3D applications

297

Fig. 12 The interactive

merging view in our round-trip
environment. Besides a
difference visualization using
the graphical SSIML notation,
an additional sync view
provides functionalities to
interactively accept or reject
changes and resolve conflicts for
modified SSIML elements

Fig. 13 Left adapter libraries wrap platform-specific frameworks

(CAVE, Android, Web) to provide structurally similar APIs for code
generation. Right common structure of generated application logic code
on all platforms

taneous synchronizations of models and code. UML LAB

uses templates to synchronize between uniform modeling
and general-purpose programming languages, such as UML2
class diagrams and Java or C# code. In contrast, the proposed RTE process addresses the special domain of 3D development. 3D and program code is generated from a graphi-

cal DSL and elaborated by different developer groups, each

using their own specialized development tools.
MoDisco [7] is a reverse engineering tool to retrieve
generic software models from a given implementation with
so called discoverers, which have to be implemented or can
partially be derived from meta models. In our case, in contrast to pure reverse engineering tools, the design of reverse
AST-to-IM-to-SSIML transformations can be derived from
the respective forward transformations.
EMFStore [14] targets collaboration and version control
of models. Element matchings are established by IDs, similar
to our semi-automatic merge approach (Sect. 5.2.1). Furthermore, EMFStore records changes to model elements in the
editor and saves editing operations for version control. In our
case, programmers and 3D content developers use external
tools to elaborate generated source code and thus, recording
editing changes is not possible. Instead, difference calculation is performed on models which are derived from the
various code bases.
Adapters allow for unified code structures on all platforms (Sect. 5.3) by introducing polymorphism, which adds
another level of indirection. For Android, the Virtual Machine
inlines function calls during optimization when needed to
eliminate indirections. In contrast, indirections are typically

123

298

not resolved by C++ compilers, which leads to an additional

lookup in the virtual method table. However, the impact of
adapters to the performance of the CAVE application is negligible.
Synchronization of the various artifacts occurs ondemand, in a non-simultaneous fashion in order to support a
concurrent development process. The concurrent work style
also improves on the typically sequential 3D development
process where 3D modeling often strictly precedes the implementation of the application logic.
Our multi-tiered RTE implementation achieves complex
model-to-code transformations through a sequence of simpler transformations. In this way, task specific transformation
languages can be employed and the process of defining transformations becomes more manageable overall. Furthermore,
subdividing the model-to-code transformation chain simplifies the extension to further platforms. Due to adapters and
the similar structure of the generated code for the different
platforms, meta models and the IM-to-AST transformations
can be re-used to some extent. In addition, SSIML-to-IM
transformations can be completely reused. Since merging is
performed on a platform-independent intermediate stage, a
single model-merging algorithm is used instead of weaving
code of different languages.
Besides SSIML, several other approaches to the structured
development of 3D applications have been proposed. The
interaction techniques markup language (InTML) integrates
3D interaction techniques into VR applications by specifying an abstract XML-based model that can be executed in a
runtime environment [10]. However, the auto-generated program code cannot be extended. Thus, the functionality of
the program is limited to the scope of its modeling language
and multi-platform development depends on the port of the
runtime. In contrast to the XML-based notation of InTML,
the graphical notation of SSIML is more accessible to creatively oriented 3D content developers. Contigra [8] supports the high-level and multi-disciplinary development of
3D components, that can be transformed to 3D applications.
However, a reverse step to achieve iterative development is
not possible. April [18] can be used to create textual models
of AR presentations. These models can be transformed to
code for two platforms. Again, a reverse phase is not possible.
In the current state of our implementation, a complete
round-trip is possible for 3D web applications and Android
AR applications. In particular, changes to the SSIML model,
X3D, JavaScript and Android code can be fully synchronized
with each other and also be applied to the C++ CAVE code.
The reverse engineering step for C++ code is currently only
partially implemented, such that changes to the C++ code
cannot yet be merged into other artifacts.
Layout and formatting information of models and source
code is not preserved, except in protected regions and user

123

B. Jung et al.

defined functions (Sect. 5.3). Formatting capabilities are provided by programming tools and our model editor.
6.1 Case study
We used our round-trip environment so far to develop several proof of concept applications. Furthermore, our tool has
been validated in an extensive student project. The goal was
to create a series of web-based 3D application presenting the
workings of several historic and for pedagogical reasons simplified pipe organs, using our round-trip environment. The
project comprised two phases, each lasting six months.
In the first project phase, we introduced the SSIML model
editor and the JavaScript and X3D code generators, to train
the students. In this phase, seven students participated with
expertise in the following areas: two students had advanced
JavaScript programming skills, three students were experienced in 3D modeling, and two students had basic training
in programming and software development. The latter two
students were assigned the role of software designers and
created the SSIML models while the other students were
used according to their core expertise in programming and,
respectively, 3D modeling. As result of the first phase, two
prototypical web applications were developed.10
For the second project phase, the students task was to
develop a complex schematical 3D organ to exemplify the
functionality of an organ in the web (Fig. 14). This should
be achieved by exploded drawings supported by animations,
which guide the user through various levels of detail, from a
rough overall view of the organ to a detailed representation
of each component. The application should be developed in
an iterative development process, using our round-trip tool.
Five students participated in the second project phase: one
student with extensive JavaScript programming skills, three
students with extensive 3D modeling skills and one student
with basic 3D modeling skills. Four of the five students were
familiar with SSIML modeling but only one student acted as
software designer.
Within six months, students completed two round-trips
and thus developed two versions of the 3D application.11
The original SSIML model specification included only one
viewpoint, which should be modified from within JavaScript
code in order to focus on the selected 3D object from a suitable perspective. However, defining viewpoint parameters is
a more appropriate task for 3D modelers, who use 3D modeling tools and have a distinct spatial awareness. Thus, 3D modelers added and defined these viewpoints. Additional changes
to the code concerned renaming of misspelled terms and the
10
11

http://vr.tu-freiberg.de/organ-visualization/organ-one, (2014).

The second iteration served as validation to ensure that a consistent

version of the application had been developed.

Structured development of 3D applications

299
Table 1 Number of model elements during forward and reverse engineering, for the car configuration example and a web-based visualization
of an organ
SSIML

IM

ASTX3D

ASTJS

elocJS

CarConfig.
Forward

27

27

13

25

13

Reverse

55

56

24

25

57

Organ Vis.
Forward

221

221

137

850

342

Reverse

333

340

144

847

752

The number of effective lines of code (eloc) is listed for JavaScript (JS)

opment of the interactive synchronization method described

in Sect. 5.2.2.

7 Conclusion

Fig. 14 Web-based 3D application explaining the functionality of a

pipe organ

deletion of the original viewpoint. The size of the final application is about 240 MB.12
Due to generated X3D and JavaScript code structures,
3D modeling and application programming could be performed concurrently. Furthermore, the JavaScript developer
was even able to finish his task before 3D developers finished 3D modeling. Therefore, implementation time could
significantly be reduced.
As a further result, we could show that our approach
also scales well with large model sizes and applications.
Table 1 gives an overview of the number of elements contained in each model during one round-trip iteration. The
SSIML model of the complex organ example proved as still
manageable. Transformations between models and text and
model merging are performed within several seconds.13 The
number of effective lines of code (eloc) for JavaScript contains no comments and at least three characters per line. For
X3D, the number of AST elements equals the number of
XML tags and is a more meaningful descriptor than code
statistics.
Furthermore, the students feedback on the semi-automatic merge process was crucial to initiate and inform the devel12
13

We presented a round-trip engineering approach supporting

the interdisciplinary development of 3D applications. From
a common model specified in SSIML, a domain specific language for modeling 3D applications, skeletons of both 3D
and program code are generated which are then elaborated by
3D content developers and programmers. In a reverse phase,
code level changes are synchronized with the SSIML model
to support an iterative development process. The presented
approach was designed in such a way, that it honors the interdisciplinary and concurrent development of 3D applications
involving 3D content developers on the one side and programmers on the other. We demonstrated the feasibility of
our approach with several example 3D applications for multiple platforms, including modern web browsers, a virtual
reality CAVE, and Android devices. General benefits of the
model-driven approach include that SSIML models can serve
as a communication aid for the involved developer groups and
may be used for documentation purposes. Further, automatic
code generation provides a basic code structure and frees the
programmers from repetitive implementation tasks.
A multi-tiered transformation pipeline is used to implement the RTE process. Splitting up the forward and reverse
phases into smaller steps simplifies the extension of our RTE
process to further platforms, as only platform-specific transformations need to be implemented for each additional platform. Therefore, the multi-tiered RTE implementation scales
well with the number of target platforms in 3D application
development. Synchronization of code bases and model can
occur in two ways, either in an automated process or an interactive process based on a graphical difference visualization.

http://vr.tu-freiberg.de/organ-visualization, (2014).

The current implementation focusses on correctness and only secondarily on performance.

Acknowledgments This research is partially supported by the Deutsche Forschungsgemeinschaft (DFG).

123

300

References
1. Alanen M, Porres I (2003) Difference and union of models. In:
Stevens P, Whittle J, Booch G (eds) UML 2003the unified
modeling language, vol 2863. Lecture notes in computer science.
Springer, Berlin, Heidelberg, pp 217
2. Antkiewicz M (2007) Round-trip engineering using frameworkspecific modeling languages. In: Companion to the 22nd ACM
SIGPLAN conference on Object-oriented programming systems
and applications companion, ACM, pp 927928
3. Amann U (2003) Automatic roundtrip engineering. Electr Notes
Theor Comput Sci 82(5), proceedings of the Fifth Workshop on
quantitative aspects of programming languages (QAPL 2007)
4. Azuma RT et al (1997) A survey of augmented reality. Presence
6(4):355385
5. Behr J, Eschler P, Jung Y, Zllner M (2009) X3DOM: a dom-based
html5/x3d integration model. In: Spencer SN, Fellner DW, Behr J,
Walczak K (eds) Web3D. ACM, pp 127135
6. Brun C, Pierantonio A (2008) Model differences in the eclipse modelling framework. UPGRADE Eur J Inf Prof IX(2):2934. http://
www.cepis.org/upgrade/files/2008-II-pierantonio.pdf
7. Bruneliere H, Cabot J, Jouault F, Madiot F (2010) Modisco: a
generic and extensible framework for model driven reverse engineering. In: Proceedings of the IEEE/ACM international conference on automated software engineering. ACM, pp 173174
8. Dachselt R, Hinz M, Meissner K (2002) Contigra: an XML-based
architecture for component-oriented 3D applications. In: Proceedings of the seventh international conference on 3D Web technology.
ACM, Web3D 02, pp 155163. doi:10.1145/504502.504527
9. Efftinge S, Vlter M (2006) oAW xText: a framework for textual
DSLs. In: Eclipsecon Summit Europe 2006. http://www.eclipse.
org/Xtext
10. Figueroa P, Green M, Hoover HJ (2002) InTml: a description language for VR applications. Web3D 02: proceedings of the seventh
international conference on 3D Web technology. ACM, New York,
pp 5358
11. Johannes J, Samlaus R, Seifert M (2009) Round-trip support for
invasive software composition systems. In: Bergel A, Fabry J (eds)
Software composition. Lecture notes in computer science, vol
5634. Springer, pp 90106. http://dblp.uni-trier.de/db/conf/soco/
sc2009.html#JohannesSS09
12. Jones J (2003) Abstract syntax tree implementation idioms. In:
Pattern languages of program design proceedings of the 10th Conference on pattern languages of programs (PLoP2003)
13. Kehrer T, Kelter U, Pietsch P, Schmidt M (2012) Adaptability of
model comparison tools. In: Proceedings of the 27th IEEE/ACM
International Conference on automated software engineering.
ACM, New York, NY, USA, ASE 2012, pp 306309. doi:10.1145/
2351676.2351731. http://doi.acm.org/10.1145/2351676.2351731
14. Koegel M, Helming J (2010) EMFStore: a model repository for
EMF models. In: Proceedings of the 32Nd ACM/IEEE International Conference on software engineering, vol 2. ACM, New York,
ICSE 10, pp 307308. doi:10.1145/1810295.1810364. http://doi.
acm.org/10.1145/1810295.1810364
15. Kolovos D, Paige R, Polack F (2006) Merging models with the
Epsilon merging language (EML). In: Nierstrasz O, Whittle J, Harel
D, Reggio G (eds) Model driven engineering languages and systems, vol 4199. Springer, Berlin, Heidelberg, chap 16, pp 215229.
doi:10.1007/11880240_16
16. Kolovos DS, Paige RF, Polack F (2008) The epsilon transformation language. In: Vallecillo A, Gray J, Pierantonio A (eds)
Theory and practice of model transformations, First International
Conference, ICMT 2008, Z++rich, Switzerland, July 12, 2008,
Proceedings, vol 5063. Springer, LNCS, pp 4660. doi:10.1007/
978-3-540-69927-9_4

123

B. Jung et al.
17. Kolovos DS, Di Ruscio D, Pierantonio A, Paige RF, (2009) Different models for model matching: an analysis of approaches to
support model differencing. In: Comparison and versioning of software models, (2009) CVSM09. ICSE Workshop on, IEEE, pp 16
18. Ledermann F, Schmalstieg D (2005) April a high-level framework
for creating augmented reality presentations. In: Proceedings of the
2005 IEEE Conference 2005 on virtual reality. IEEE, VR 05, pp
187194
19. Lenk M, Schlegel C, Vitzthum A, Jung B (2012a) Roundtrip engineering for 3D applications: models and transformations. Preprint 6/2012, Faculty of Mathematics and Informatics, TU Bergakademie Freiberg. http://www.mathe.tu-freiberg.de/
forschung/preprints
20. Lenk M, Vitzthum A, Jung B (2012b) Non-simultaneous round-trip
engineering for 3D applications. In: Proceedings of the 2012 International Conference on software engineering research and practice,
SERP
21. Steinberg D, Budinsky F, Paternostro M, Merks E (2009) EMF:
eclipse modeling framework, 2nd edn. Addison-Wesley, Boston
22. Van Paesschen E, De Meuter W, DHondt M (2005) Selfsync: a
dynamic round-trip engineering environment. In: Companion to
the 20th annual ACM SIGPLAN conference on object-oriented
programming, systems, languages, and applications, ACM, New
York, NY, USA, OOPSLA 05, pp 146147. doi:10.1145/1094855.
1094906
23. Vitzthum A, Hussmann H (2006) Modeling augmented reality user
interfaces with SSIML/AR. J Multimed 1(3):1322
24. Vitzthum A, Jung B (2010) Iterative model driven VR and AR
development with round trip engineering. In: Proceedings of
SEARIS Workshop at the IEEE virtual reality 2010 Conference,
Shaker
25. Vitzthum A, Pleu A (2005) SSIML: designing structure and application integration of 3D scenes. In: Proceedings of the tenth international conference on 3D Web technology, ACM, New York, NY,
USA, Web3D 05, pp 917. doi:10.1145/1050491.1050493

Bernhard Jung holds the chair

for Virtual Reality and Multimedia at the Technical University Bergakademie Freiberg,
Germany. He studied Computer
Science at the University of
Stuttgart, Germany, and the University of Missouri, St. Louis,
USA. Afterwards, he became a
researcher at the University of
Bielefeld, Germany, where he
completed his PhD in Artificial
Intelligence in 1996 as well as
a habilitation degree with a thesis on intelligent virtual environments in 2002. From 2003 until 2005 he was full professor for Media
Informatics at the University of Luebeck, Germany, before joining the
TU Bergakademie Freiberg in 2005. His current research interests are
Virtual Reality, Large Data Visualization, Human-Computer Interaction, and Advanced Robotics.

Structured development of 3D applications

301

Matthias Lenk studied computer science at the TU

Bergakademie Freiberg. There,
he joined the Virtual Reality
and Multimedia Group in 2011
as a PhD student. His current
research field in the Roundtrip3D
project combines model-driven
development with Virtual and
Augmented Reality.

Arnd Vitzthum studied Computer Science at the Dresden

University of Technology. From
March 2003 until January 2008
he was a PhD student and
research assistant at the University of Munich (LMU), Media
Informatics Group. Until the end
of 2009, he was working at the
Freiberg University of Mining
and Technology as a member
of the Virtual Workers project
team. From January 2010 until
March 2011 he led the project
Roundtrip3D (funded by the
Deutsche Forschungsgemeinschaft - DFG). Currently, he is working as lecturer at the University of Cooperative Education in Dresden
(StA DD), Saxony. His primary research interests are directed towards
model-driven development of VR and AR applications.

123