Comput Sci Res Dev (2015) 30:285–301DOI 10.1007/s00450-014-0258-8

SPECIAL ISSUE PAPER

Structured development of 3D applications: round-tripengineering in interdisciplinary teams

Bernhard Jung · Matthias Lenk · Arnd Vitzthum

Published online: 1 July 2014© Springer-Verlag Berlin Heidelberg 2014

Abstract While structured software development proces-ses are nowadays common-place, 3D applications are oftenstill developed in an ad-hoc and code-centric manner. Thisstate of affairs is somewhat surprising, as there are manybenefits to a more structured 3D development process. Inparticular, model-based techniques with support for iterativedevelopment could help to ensure the mutual consistencyof the code bases produced by the heterogeneous devel-oper groups, i.e. 3D content developers and programmers.However, a cultural gap exists between 3D content devel-opers and programmers who use completely different toolsand terminologies. Common tools for model-driven devel-opment, for instance based on UML, are inadequate for theoften “creatively oriented” 3Dcontent developers. This paperpresents a model-driven approach for the structured devel-opment of 3D applications in interdisciplinary teams basedon round-trip engineering. Abstract models of the applica-tion are specified in SSIML, a DSL tailored for the devel-opment of 3D applications. In a forward phase, consistentskeletons of 3D scene models and program code are gen-erated from the SSIML model. In a reverse phase, refine-ments of both the 3D scene model and program code areabstracted and synchronized to result in an updated SSIMLmodel. 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, Germanye-mail: lenk@informatik.tu-freiberg.de

B. Junge-mail: jung@informatik.tu-freiberg.de

A. VitzthumBerufsakademie Sachsen, University of Cooperative Education,Dresden, Germanye-mail: arnd.vitzthum@ba-dresden.de

platforms including Web, immersive virtual reality, and aug-mented reality on mobile devices demonstrate the versatilityof our approach.

Keywords Model driven development · Round-tripengineering · 3D applications · Virtual reality · Augmentedreality · Model transformation · Model differences · Modelmerging

1 Introduction

Interactive 3D applications including virtual reality (VR) andaugmented reality (AR) play a central role in many domains,such as product visualization, entertainment, scientific visu-alization, training and education. So far, however, the useof model-driven development (MDD) approaches and visualmodeling languages such as UML is far less common thanin the development of other kinds of software. Arguably, thislack of acceptance of MDD approaches can be attributed tothe specifics of the 3D application development process.

First, 3D development is an interdisciplinary process.Essentially, two groups of developers are involved who usecompletely different tools and terminologies: 3D contentdevelopers and programmers. Misunderstandings betweenthe developer groups can lead to an inconsistent systemimplementation [25]. For example, if the 3D content devel-oper does not follow the conventions for the naming of3D objects, the programmer cannot address these objectsproperly via program code. While MDD approaches maybe instrumental in avoiding such misunderstandings, generalpurpose tools, for instance based on UML, may be appro-priate for programmers, but are certainly inadequate for theoften “creatively oriented” 3D developers. More promising

123

286 B. Jung et al.

seem domain-specific languages (DSL) specifically gearedtowards 3D development.

Second, 3D applications are usually developed in a highlyiterative fashion.Although generally desirable for all kinds ofsoftware, support for an iterative development process is par-ticularly relevant in the 3D domain. Round-trip engineering(RTE) [2,3,11,22] is a model-driven software developmentmethodology that combines forward engineering (model-to-code transformations) with reverse engineering (code-to-model transformations) and synchronizations between codeand model to support iterative development. RTE has provenuseful in the development of “conventional” software asexemplified by several existing integrated tools support-ing the simultaneous editing and synchronization of UMLdiagrams and program code. However, due to the concur-rent development process in conjunction with the preferencefor very different modeling/programming tools between 3Ddesigners and programmers (and software designers), the useof a (yet to be developed) integrated tool for the varioustasks seems not advisable for 3D development. Instead, anapproach is preferable where the distinct developer groupseach can employ their tools of choice.

Third, 3D applications are often implemented for multi-ple platforms, from ordinary PCs, over mobile devices, up toimmersive virtual reality installations. A possible approachcould be the use of cross-platform 3D engines. A disadvan-tage is that this requires the installation of a 3D engine atthe user’s site. In web environments, however, users maynot have administrative rights to install the necessary plug-in. In highly specialized environments, such as CAVEs, asuitable version of the 3D engine may not be available.Therefore, 3D applications often need to be developed withrespect to different programming environments, using differ-ent programming languages. During the iterative develop-ment cycle, cross-platform synchronization should be sup-ported.

In this paper we describe a round-trip engineering appro-ach for the model-driven, iterative development of multi-platform 3D applications. Section 2 introduces this approachat a conceptual level. In Sect. 3, a longer example of model-driven, round-trip development for 3D applications is given,with WebGL-enabled web browsers and immersive virtualreality as deployment platforms. Section 4 presents a secondexample that demonstrates the development of a 3D applica-tion in a web version as well as an augmented reality versionon the Android platform. Section 5 gives an overview of theimplementation of our round-trip engineering process, cover-ing transformations between model and code, synchroniza-tion procedures during iterative development, and adaptercode for the different target platforms. In Sect. 6 we discussour approach and present results from an extensive case studyon 3D development in a larger interdisciplinary team, beforewe finally conclude in Sect. 7.

2 3D development with round-trip engineering

This section gives a conceptual overview of the the pro-posed round-trip engineering approach formulti-platform3Ddevelopment (see Fig. 1). The involved developer groups are:software designers, who design an abstract model of the 3Dapplication; 3D content developers responsible for 3D mod-eling; and programmerswho implement the application logicfor the specific target platforms. For the purposes of this con-ceptual overview, we assumeWebGL-enabled web browserswith JavaScript as programming language and an immer-sive virtual reality CAVE programmed in C++ as target plat-forms. Another target platform supported by our approachare Android-based smartphones and tablets with Java as pro-gramming language. Details on the DSL used for applicationmodeling, forward and reverse transformations, as well asother implementation aspects are given in later sections.

Development begins with the specification of an initialabstract model of the 3D application through the softwaredesigner. As modeling language, we use the scene structureand integration modeling language (SSIML) [25], a DSLtailored for 3D applications. SSIML models comprise bothan abstract description of the 3D scene and a specification

Fig. 1 Round-trip engineering for concurrent development of 3Dapplications on multiple platforms (Web, CAVE, Android)

123

Structured development of 3D applications 287

of the application logic. Cross-references (or interrelation-ships) between the 3D scene description and the applica-tion components specify the events that may be triggered byuser interaction with a 3D object and need to be handled bythe application logic. Note that as an iterative developmentprocess is assumed, it suffices that the initial SSIML modelspecifies only a rough first version of the application that canbe refined in later iterations [24].

During the forward engineering phase of the develop-ment process, the initial SSIML model is transformed toJavaScript, C++ and X3D code skeletons. The 3D contentdevelopers’ task is to model the individual 3D objects andtheir composition in a single X3D scene while programmerselaborate the auto-generated JavaScript and C++ code. In theproposed development process, 3D designers and program-mers may work concurrently, where both are using differenttools appropriate to their task. For example 3D designerscould model the 3D objects using tools like 3DS Max orBlender, while the programmers use an IDE or a simple codeeditor.

However, as software development is a non-trivial process,the implementation of 3D and program code may be incon-sistent with the current SSIML model in various ways: theimplementation could be incomplete or incorrectly reflect themodel, for example by using different names for 3D objects,application classes or their attributes. Moreover, the imple-mentation may also add parts to the application that may rea-sonably be reflected in future versions of the SSIML model.

In order to consolidate the various artifacts, the implemen-tation code is then reverse engineered and synchronized withthe current SSIML model. For each inconsistency betweenthe SSIML model and the current state of the implementa-tion it has to be decided whether the implementation is incor-rect or incomplete or whether the implementation improvesthe overall application in some way and should thereforebe reflected in the next version of the SSIML model. Forinstance, on the one hand, say, the 3D designer may not caretoomuch about attribute names as only the visual appearanceof the 3D objects is usually important for his task. Here, themismatch should be considered as incorrectness of the imple-mentation. On the other hand, a programmer may feel that aclass name in the SSIML model is inconsistent with the con-ventions of her programming language and uses a differentclass name instead. Here, the changed attribute name may beadopted in the next iteration of the SSIML model. To syn-chronize the various code bases and the SSIML model, wepropose two distinct approaches (Sect. 5.2), which providedifferent degrees of interactive control for the responsiblesoftware designer.

Once the implementation is synchronizedwith the SSIMLmodel, possibly resulting in updates to the model, the soft-ware developer may now further expand the SSIML model.This completes the first cycle of the round-trip engineer-

ing process. From the updated SSIML model, again, codeis generated in a forward step. Of course, during the forwardstep it is ensured that the newly generated code still containsthe implementation details of the previous iteration, whichmeans that no code is lost during re-generation. This round-trip process may be repeated for several iterations, until afinal version of the 3D application is reached.

3 Example: 3D development for web and CAVE

We introduce a small example to better illustrate the pro-posed 3D development process. The 3D scene is composedof the following 3D objects: a car chassis (Fig. 2a), sepa-rated windows (Fig. 2b) and different rim types (Fig. 2c).The application shall provide an interactive part to configurethe car, in particular changing the car’s color, replacing therims and toggling the visibility of the windows. Interactionis achieved by directly clicking on the respective 3D objectswithin the 3D scene or by using external GUI elements.

3.1 Modeling 3D applications with SSIML

In the proposed 3D development process, developmentbegins with the specification of an abstract model throughsoftware designers. The application model is specified in theCore component of SSIML, which is a language family ofgraphical DSLs for 3D application development [25].

A SSIML model is composed of a scene model whichallows for modeling abstract 3D scene graphs and an inter-relationship model to create associations of scene graph ele-ments with application components. The 3D scene graph iscomposed of parent and child nodes, with some importantones being the scene root node, group nodes to structure thescene graph, object nodes which represent a specific geo-metric 3D object (for instance, a car chassis) and attributenodes, for example to specify the texture or material of anobject. Group and object nodes can act as child and parentnodes for other nodes, whereas attribute nodes have no fur-ther children. Special attribute nodes, such as sensor nodes,

Fig. 2 a The stand-alone car chassis with b separated windows, c oneof several wheel types

123

288 B. Jung et al.

Fig. 3 A SSIML model contains scene elements (upper area), whichlater result in 3D code. Artifacts in generated application code, such asclasses or event handlers, stem from SSIML application elements andinterrelationships to scene model elements (lower area)

are used to trigger events within the 3D scene to notify appli-cation components within the interrelationship model. Forinstance, when a SSIML object node is connected to a touchsensor, this sensor attribute can notify an associated applica-tion class about an event, like a mouse click.

The car configuration application can be modeled usingSSIML as depicted in Fig. 3. Scene model elements whichwill mainly result in the X3D code are shown in the upperarea. The scene root node has a light and viewpoint attributeand contains the group node “carGroup”. This group nodecontains a “chassis” object which in turn contains four“wheel” objects and the “windowpanes” object. Elements ofthe SSIML interrelationship model (displayed in the lowerarea) will later be translated to application code. The appli-cation class “MaterialConfigurator” is associated with therespectivematerial attributes of the chassis andwindowpanesin order to change their color and transparency values. Thetouch sensor attribute “windowTouchSensor” is connectedto the windowpanes object and triggers a “CLICKED” eventto the application class when the user clicks on the window-panes. The second application class “PartsConfigurator” canaccess the chassis object in order to replace its content, con-cretely to replace the fourwheels by a different kind ofwheel.

3.2 Developing the 3D application

In the current example, a web version and a CAVE-versionof the 3D application are to be developed. Both versions useX3D as scene description language, whereas the applicationis implemented in JavaScript and C++ respectively. In thefollowing subsections, we sketch code mapping+ from eachlanguage to the SSIML model.

3.3 Generation of X3D code from SSIML models

SSIML scenemodel elements (Fig. 3, upper area) aremappedtoX3Dnodes in the followingway: the SSIMLmodel and thescene root node are transformed to an X3D tag and a scenetag, respectively. Each SSIML group node, for example thecarGroup, 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 specifiedin 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 theseinline nodes in order to support scene composition activitiessuch as translating and rotating the 3D objects to their finalpositions in the complete 3D scene (Listing 1).

To recognize artifacts (such as SSIML elements, X3Dnodes or programentities) during the round-trip process, eachartifact is associated with a unique ID. This ID is bound to itselement during the complete development process and maynot be modified or removed. Elements without ID will laterbe treated as newly added elements. During the X3D codegeneration, the ID from the SSIML element is passed to theX3D node. To store IDs in the X3D code we use XML com-ments, each preceding its referred X3D node. The generatedX3D skeleton can already be rendered in X3D viewers as astatic scene without interaction.

3.4 Developing the 3D web application

Web deployment of the car configuration tool makes use ofX3D as scene description language and JavaScript as pro-gramming language. The X3DOM framework is used forintegration of X3D content into HTML pages [5]. Modern,WebGL-enabledweb browsers can displayX3DOMapplica-tions natively, without the need for installing a plug-in. Thegenerated and refined X3D scene can be included in HTML5documents and rendered in modern web browsers (although,in our example, the application logic still needs to be imple-mented in JavaScript).

Similar to X3D code, a corresponding JavaScript codeskeleton (Listing 2) is generated to access the 3D scene. Thegenerated JavaScript functions emulate the class-orientedstructure of programming languages such as Java or C++, inorder to enable consistentmulti-platformadaption. JavaScript

123

Structured development of 3D applications 289

1 <!-- id=938c3fb8 -b229 -40d2 -9044- c5a26727bc09 -->2 <X3D version="3.0" profile="Interaction">3 <!-- id=a1b5540e -4f9f -4674 -8e01 -1877 a37213b1 -->4 <Scene >5 <!-- id=cb7960db -0141 -4f60 -ae3d -552 ab613decd -->6 <WorldInfo title="CarConfigurator" info="" DEF="..." ></WorldInfo >7 <Transform DEF="generatedTransform1" translation="0 0 0" ...>8 <Group DEF="carGroup">9 <Transform DEF="generatedTransform2" translation="0 0 0" ...>10 <Inline DEF="chassis" url="chassis.x3d" ></Inline >11 <Transform DEF="generatedTransform4" ...>12 <Inline DEF="wheel_0" url="wheels.x3d" ></Inline >13 </Transform >14 <Transform DEF="generatedTransform5" ...>15 <Inline DEF="wheel_1" USE="wheel_0" ></Inline >16 </Transform >17 ...18 </Transform >19 </Group >20 </Transform >21 <DirectionalLight DEF="light" color="1 1 1" ...></ DirectionalLight >22 <Viewpoint DEF="viewPoint" position="0 0 10" ...></Viewpoint >23 </Scene >24 </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 includefurther 3D geometries. Some IDs and node attributes have been removed

1 function MaterialConfigurator( ) {2 var chassisColor = document.getElementById( ’chassis__chassisColor’ );3 var windowTransparency = document.getElementById( ’windowpanes__windowTransparency ’ );4 this.windowpanes_CLICKED = function( obj ) {5 };6 //! Insert further application code below !//78 //! Insert further application code above !//9 }1011 function PartsConfigurator( ) {1213 var chassis = return document.getElementById( ’chassis ’ );14 ...15 }1617 function init( ) {18 var materialConfigurator = new MaterialConfigurator( );19 var partsConfigurator = new PartsConfigurator( );20 document.getElementById(’windowpanes ’). addEventListener("click",21 materialConfigurator.windowpanes_CLICKED );22 ...23 }

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

code fragments are related to the original SSIML model ofFig. 3 in the following way: the SSIML application compo-nents MaterialConfigurator and PartsConfigurator are trans-lated to JavaScript functions of the same names which cre-ate suitable JavaScript objects. The MaterialConfigurator’saction relationships to the original SSIMLattributeswindow-Transparency and chassis Color result in member variablesof the JavaScript object. These two variables address X3Dmaterial nodes which can be used to modify the appearance

of the windows and the chassis, respectively. To realize touchsensors with X3DOM, appropriate event listeners (conform-ing to the HTML event model) are attached to the respectiveX3D nodes [5]. This event handling mechanism is commonon many platforms and therefore can easily be adapted. Forthewindowpanes object,which is connected to a touch sensorin the SSIML model, a corresponding event listener is gen-erated in the MaterialConfigurator function and registered inthe init() function. The CLICKED event from the SSIML

123

290 B. Jung et al.

example is mapped to an HTML click event. Further appli-cation logic, for instance to set the transparency value of thematerial, will be manually programmed by elaborating thegenerated code stubs, possibly by also defining additionalhelper functions. Like generated X3D elements, generatedJavaScript elements are also assigned IDs for tracking. Themapping from SSIML elements to corresponding JavaScriptelements is more complex than the mapping to X3D nodes,since multiple SSIML elements may contribute to the sameJavaScript function. For example, the event handler registra-tion within the init() function is comprised of the concernedobject (namely windowpanes), the attached sensor and therelationships which connect the related objects (Listing 2).

3.5 Developing the CAVE application

The second platform supported by our round-trip environ-ment is an ultra high-resolution CAVE consisting of 25 pro-jectors (24 full HD plus 1 SXGA+) that offers a much moreimmersive experience than the web platform. The user caninteractively configure the real sized car by using GUI ele-ments on an iPad and by using a flystick for 3D interac-tion. The 3D scene (Sect. 3.3) is converted from X3D to theVRML format.1 Functionalities to load, access and displaythe 3D scene or to realize the event handling mechanismare implemented with respect to corresponding libraries of aproprietary CAVE framework. The structure of the generatedC++ 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 accessthe 3D scene in a correct manner.

3.6 Multi-platform round-trip engineering

During the edit phase, 3D content developers and program-mers elaborate the generated code skeletons. However, editsmay occur that do not conform to the SSIML model. Inorder to detect these inconsistencies and to derive an updatedSSIML model, the different code bases need to be synchro-nized in the reverse phase of the RTE process.

For our car configurator example we assume the followingthreemodel-relevant changes to the code,which represent thebasic operations update, insert and delete: First, 3D contentdevelopers rename the 3D object “windowpanes” to “win-dows”. Since JavaScript and C++ programmers rely on theoriginal naming, the windowpanes object is no longer acces-sible from the program code, which results in an inconsistent

1 As the predecessor of the X3D format, VRML documents describethe same scene structure as X3D documents, but differ in their textualrepresentation.

application that might crash. Second, 3D content developers,having theCAVEapplication inmind, add a high-detail back-ground to the 3D scene which is however not suitable for theweb application due to the smaller graphics processing powerin web browsers. And third, 3D content developers removethe specified directional light source (maybe because theyprefer other light source types in the present scenario).Modelrelevant changes, of course, may stem from JavaScript pro-grammers, too. For instance, a JavaScript developer renamesthe class element “MaterialConfigurator” to “ColorConfigu-rator” since in her opinion only color values are addressedand modified.

In the reverse engineering step, the now inconsistent codebases must be merged into a consistent SSIML model. Mod-ifications of the various artifacts can be detected using diffalgorithms. Model-relevant changes, introduced by 3D con-tent developers and programmers, can either be accepted orrejected. This may occur in a more automatic way, for exam-ple by configuring merge priorities, or in a more interactivefashion, for example based on suitable visualizations (Fig. 4).A detailed description for synchronization can be found inSect. 5.2.

With respect to the example, the deletion of the directionallight source and the addition of the high-detail backgroundare rejected2 while renaming the windows 3D object andthe application class MaterialConfigurator is accepted forinclusion in the next iteration of the SSIMLmodel. Softwareengineers can now apply further changes to the consolidatedSSIMLmodel, for instance by adding a spoiler object.Duringthe next forward iteration, manually developed source codeand changes from the SSIMLmodel will be re-generated to aconsistent application. Figure 5 shows the final application,in the web3 (Fig. 5a) and CAVE variants (Fig. 5b).

4 Example: augmented reality development for Android

In this section we give an example demonstrating the multi-platform development of a 3D application as an augmentedreality 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, suchas medicine, advertising, (scientific) visualizations, prod-uct configuration, gaming, safety or training simulations.Today’s pervasive and powerful mobile devices, such assmartphones and tablet computers, with built-in camerashave become popular platforms for AR applications. We use

2 CAVE developers may still programmatically add a high-detail back-ground, but the background object will not be part of the platform-independent SSIML model.3 Available at: http://elrond.informatik.tu-freiberg.de/roundtrip3d/carconfigurator.xhtml, (2014).

123

Structured development of 3D applications 291

Fig. 4 The differencevisualization for the carconfiguration application afterone iteration. Modifications toelements are indicated bybackground colors and littledecals. The “windowpanes”object has been renamed to“windows” and the applicationclass “MaterialConfigurator” to“ColorConfigurator”. Theviewpoint and the background(“stage”) are marked as deletedand added, respectively

common Android devices to realize video see-through AR,with marker based tracking fromVuforia by Qualcomm4 anda third-party 3D renderer5 with basic scene graph support.Our proprietary AR library adapts these two low level frame-works to the generated AR code skeleton (which is struc-turally similar to the generated web and CAVE code).

Although our approach allows for deploying the car con-figuration example (Sect. 3.1) for the AR platform with littleeffort, we introduce a further example which is more typ-ical for AR applications. This scenario is a simulation of arobot and has initially been created to illustrate our round-tripapproach for 3D web applications [20]. In the AR scenario,the 3D scene contains a model of an industrial robot and itswork space, which contains a work table and is surroundedby a fence. Two buttons on a console allow for interactivelyrotating the robot arm around its vertical axis. Both virtualobjects, thework area including the robot and the control con-sole, can be independently arranged by placingmarkers in thereal world. The AR application could be used for instance topreview and assess real robot installations in manufacturingenvironments.

4 http://www.qualcomm.com/solutions/augmented-reality, (2014).5 https://github.com/MasDennis/Rajawali, (2014).

Besides SSIML/Core for VR applications, SSIML/ARfacilitates modeling AR applications. The scene model aswell as the interrelationship model (Sect. 3.1) from SSIML/-Core are extended by respective elements from SSIML/AR[23].Originally, SSIML/ARallows formodelingAR specificartifacts, for example by specifying concrete VideoTrack-ers and SceneUpdaters within the interrelationship model toestablish basic tracking relations from real world objects tovirtual objects. Since our AR library not only “glues” 3D ren-dering and tracking with the generated code but also hidestracking mechanisms from the programmer, there is no needtodefine such tracking relations in the abstract domainmodel.Thus, AR applications can be specified by SSIML modelsthat are structurally very similar to SSIML models for weband CAVE applications. In fact, as discussed below, SSIMLmodels for AR applications can also be used for developmentof web and CAVE versions of the software.

Figure 6 depicts the SSIML model for the AR robotscenario. The “RobotScene” root node contains the “main-Group” node which contains two nodes from SSIML/AR,so called hybrid objects. A hybrid object consists of a virtualand a real component.While the virtual component is derivedfrom the SSIMLobject node and represents the geometric 3Dobject, the real component links to an ID of an AR marker

123

292 B. Jung et al.

Fig. 5 a 3D application inWebBrowser; bCAVE-version of the appli-cation

that can be placed in the real world. In our AR framework,both components are registered with each other. The coordi-nates of the real component (obtained from the marker) aremapped to the coordinates of the virtual component in realtime 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 con-tains the “workspace” group node, which in turn containsobjects for fence and work table geometries. The “robot”group, another child of the hybrid object “robotArea”, con-tains transform nodes to manipulate object nodes which linkto the robot’s 3D geometries. The hybrid object “control-Panel” maps the console geometries to a marker and containstwo buttons with touch sensors in order to send “PRESSED”events to the application class “RobotControl”. In the gen-erated Java code, these sensors result in event handler stubs,where programmers implement functionalities to modify thetransformation node “rotationBase” to rotate the robot verti-cally.

Encapsulating tracking functionalities in our library onthe one hand simplifies modeling new AR applications withSSIML/AR and on the other hand allows for easily migrat-ing existing SSIML/Core models to AR models: SSIML/ARmodels can be derived from SSIML/Core models by onlyre-labeling some of the object nodes as hybrid objects and

assigning concrete marker IDs to them. Likewise, SSIM-L/AR models can be used to generate web or CAVE codeby simply ignoring the marker information.

Figure 7 shows the final AR application next to the webversion of the robot scenario,6 both generated from the sameSSIMLmodel (Fig. 6).Round-trip development, as describedin Sect. 3.6, is also supported for the AR platform.

5 Implementation overview

In this section we first briefly describe the implementa-tion of model-to-code and code-to-model transformations inSect. 5.1. A detailed description of the involved models andtransformations is given in [19]. Section 5.2 describes twoapproaches for model and code synchronization includingconflict handling. Section 5.3 gives an overview of adapterswe use to embed our generated code structures in existingruntimes and frameworks.

All functionalities to trigger transformations betweenmodels and code as well as the synchronization betweenthem are accessible from within our Eclipse-based Round-trip environment (Fig. 8).

5.1 Transformations between model and code

Round-trip engineering combines model-driven forwardengineering with reverse engineering as well as a synchro-nization phase (see Sect. 5.2). In our implementation, theoverall, complex conversion betweenmodel and code is real-ized through a sequence of simpler transformations (Fig. 9).During forward engineering, the SSIML model is first con-verted into an intermediatemodel (IM) andmerged into a per-sistent IM.7 The persistent IM stores all data and metadataof the complete application, including all model and codeartifacts. From the persistent IM, target-language specificabstract syntax trees (ASTs) are created which, in turn, areserialized to code in various programming languages (cur-rently X3D, JavaScript, Java, C++). The ASTs contain bothrepresentations of SSIMLmodel elements and code artifactsfrom previous iterations in order to allow for re-generationof code from an altered model. In contrast to the genera-tion gap pattern that strictly separates generated code frommanually programmed code extensions, this approach allowsfor the detection of changes to model relevant artifacts dur-ing the reverse phase. These changes can then be applied tothe SSIML model and transferred to other platforms. Fur-thermore, model elements (and changes applied to them) are

6 http://elrond.informatik.tu-freiberg.de/roundtrip3d/RobotScene/robot.html, (2014).7 In the forward phase of first iteration, the persistent IM is created asa copy of the IM generated from the SSIML model.

123

Structured development of 3D applications 293

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

hybrid nodes, namely “controlPanel” and “robotArea”, contain markerinformation, to automatically map virtual and real world objects in thegenerated AR application

Fig. 7 Left in the AR robot scenario, 3D objects are registered withmarkers, as specified in the SSIMLmodel. Right the web version of theapplication 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 refer-ences to updated elements within the manually programmedcode.8

In the reverse phase, this sequence of conversions is per-formed in backwards order.All edits of the SSIMLmodel anduser code are merged into this persistent IM during the for-ward and, respectively, reverse phases. Forward and reversetransformations between SSIML and the IM are performed

8 Currently, we do not provide further refactoring mechanisms in ourround-trip framework.

with Java using EMF’s reflection API [21]. Conversionsbetween IMs and ASTs are implemented in ETL, a hybridtransformation language with declarative rules and imper-ative bodies [16]. Code serializers and parsers to convertbetween the ASTs and program code are generated throughXtext [9] based on a grammar and a meta model of the targetplatform. Since serializers and parsers only need to recog-nize model relevant language artifacts, it is not necessary tosemantically distinguish between all constructs of the tar-get language. Instead, it suffices that the meta models andgrammars cover relevant subsets of the target platform [12].

5.2 Synchronization

Synchronization of models and code is a core process inround-trip engineering. Edits of the model must be reflectedin the re-generated code, and code-level edits may result inupdates to the model. In our case, the SSIML model, 3Dcode, and application code (possibly for several platforms)need to be synchronized. As software designers, 3D con-tent developers, and programmers work with different toolsappropriate to their tasks, model and code edits cannot betraced in real-time and thus synchronization must occur in anon-simultaneous manner.

Figure 10 conceptually depicts the SSIML language andcovered parts of 3D scene and application languages. Mod-ifications to code artifacts, whether in 3D code or appli-cation code, result in inconsistencies between the modeland its implementation. During the synchronization phase,

123

294 B. Jung et al.

Fig. 8 The SSIML tool enablesthe visual creation of SSMILmodels and integrates round-tripcapabilities for forward andbackward engineering, diffvisualization, and interactivesynchronization

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

it has to be decided whether these inconsistencies are usedto update the specification or whether they are discardedas incorrect implementation. Furthermore, interrelationshipsbetween SSIML scene elements and SSIML application ele-ments (Fig. 6, connections in dark gray area) correspondto scene access and event handling source code artifacts(Fig. 10, darkgrayoverlapping area). SSIMLelementswithinthis area have corresponding counterparts in both 3D codeand application code. Concurrent modifications of corre-sponding artifacts in 3D and application code may lead tomerge conflicts. Merge conflicts need to be resolved duringthe synchronization phase, either by applying just one ofthe options or by discarding all changes. 3D scene elementsand code artifacts which are not covered by the specification

(Fig. 10, outside the SSIML language) cannot cause incon-sistencies or conflicts and therefore can be developed inde-pendently from each other.9

In iterative round-trip development, synchronization canalso be used as a verification method: when no inconsisten-cies or merge conflicts are detected during synchronization, aconsistent version of the 3D application has been developed.

Synchronization comprises four phases: comparison, con-formance checking, merging and reconciliation [15]. In thefollowing, we propose two approaches for model synchro-

9 In case ofmulti-platform development, inconsistenciesmay also arisebetween implementations for the different platforms. Of relevance areonly inconsistent implementations of SSIML elements.

123

Structured development of 3D applications 295

SSIML(possible

specification toimplementationinconsistencies)

Interrelationships(possible

merge conflicts)

application code

3D code

Fig. 10 Abstract illustration of language overlappings: elements of theSSIML language (middle circle) correspond to 3D modeling languageelements (upper circle) and artifacts of application languages (lowercircle). Modifications to these elements in source code cause inconsis-tencies between model and implementation. SSIML interrelationshipelements are reflected in both, 3D and application code. Concurrentmodifications of interrelationship elements may cause merge conflicts

nization, which primarily differ in the first two phases,namely comparison and conformance checking: the firstapproach implements a semi-automatic merge process usingID-based difference detection. It needs to be configured onceby domain experts and then automatically resolves conflictswithout further user interaction. The second synchronizationapproach is an interactive one. It does not need to assignIDs to code and model elements and instead uses a moregeneric matching algorithm. Detected differences are graph-ically presented in SSIML notation. Software designers canthen interactively accept or deny modifications and resolveconflicts.

5.2.1 Semi-automatic merging

In our RTE approach, as shown in Fig. 8, all merging occurson the level of intermediate models. Concretely, IMs (inter-mediate models) derived from the SSIML model or pro-gram code are merged into the persistent IM that representsthe complete 3D application. In the semi-automatic mergingapproach, not only merging but also difference detection isperformed at the intermediate level. As all difference detec-tion and merging occurs between the same type of models,it suffices to implemented only one algorithm each for diffand merge. For reliable matching of elements in differentmodels, unique identifiers (Sects. 3.3 and 3.4) are added tomodel elements and serialized into source code [1]. Duringthe editing phase, identifiers may not be modified, except forthe deletion of the respective code artifact. Newly added codeconstructs obtain a UUID during the reverse transformationinto their intermediate representation.

In the comparison phase, an ID based diff algorithm is runon each IM with the persistent IM resulting in a differencemodel [6]. Within this difference model, corresponding ele-

ments (whethermodified or not) from different languages areidentified and mapped to each other. The diff algorithm alsodetermines the modification type for each element relativeto its previous value in the persistent IM, with modificationtypes being update, insert or delete.

For automatic resolution of inconsistencies and conflicts(cf. Sect. 5.2) an additional configuration is used. This config-uration maps every SSIML element with a priority to everyapplicable target language. The priority defines the prefer-ence of element modifications in the respective language.This configuration has to be defined by domain experts. Forinstance, a domain expert could decide that modifications ofan X3D inline node (originating from a SSIML object node)are preferred over modifications of the respective JavaScriptelement (access to domnode). Since software designers canchange the configuration, the synchronization phase is notfully but semi-automatic.

The semi-automaticmerge approachwas tested in a longerstudent project (see Sect. 6.1). However, participants con-cluded that although it is convenient to have amerge automa-tism, the priority-based configuration to select preferredmodifications was not considered as flexible and transparentenough. Furthermore, automatic modifications to the codecannot easily be comprehended at themodel stage, since eachelement from the derived model has to be compared to eachone from the original model. To address these concerns, oursecond synchronization approach implements a more usercontrolled merge process.

5.2.2 Interactive merging

The second synchronization approach combines graphi-cal visualization of differences with an interactive mergeprocess. This approach aims to provide functionalities forinteractive conflict resolution and thus we assume that alllanguages are merged at once (although sequentially merg-ing code changes from every language into the model is alsopossible).

The approach uses more complex, for example similarity-based algorithms, for difference detection. Therefore, nounique IDs need to be serialized into the source code and thus,code pollution is avoided [17]. Difference detection takesplace at the AST level which is more suitable for similarity-based element matching than the more abstract IM level(Fig. 11). Each AST derived from edited code is comparedwith its version before the edit. Further, all ASTs derivedfrom the various source codes are compared with each otherwhich requires a generic diff algorithm. The SiDiff frame-work [13] offers generic and highly configurable matchingalgorithms, but requires an extensive configuration. Instead,we chose EMF compare [6] that provides similarity-basedmatching and extended this frameworkwith basic setup capa-

123

296 B. Jung et al.

Fig. 11 Multi-platformRTEwith diff detection of abstract syntax treesof the same type, before and after the editing phase. Using the SSIML-based diff visualization, software designers decide about acceptance ofchanges and resolve conflicts. Based on these decisions, intermediaterepresentations of the implementations are merged into the persistentIM

bilities to correctly identify matching elements in differentversions of an AST and in different AST types.

Results from the diff phase are presented to the soft-ware designer in SSIML notation. Elements are graphicallyannotated with difference information, according to recog-nizedmodifications. To illustrate the notation of conflicts andinteraction possibilities within our round-trip environment(Fig. 12),we assumeamerge conflict for the car configurationapplication. For example, the original SSIML object “win-dowpanes” has been renamed to “windows” by 3D design-ers and to “panes” by JavaScript developers. The detectedconflict is highlighted in the graphical SSIML differenceview. Software designers now decide (ideally in a discussionwith 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 torestore the original version of the respective SSIML element.The latter can be useful when developed solutions differ tomuch from their original specification.

In the next forward phase, the updated SSIML modelserves as new specification for platform developers. Differ-ence information from the synchronization phasemay furtherhelp developers to comprehend changes in the re-generatedsource code, similar to log files in common distributed ver-sion control systems.

5.3 Adapter libraries and code skeleton structure

While there is a clear mapping from SSIML scene graphelements to X3D nodes, the mapping from SSIML interrela-tionship model elements to application code artifacts is morecomplex. Several SSIMLelements result in various code arti-facts. Referring to the car configurator example (Fig. 3), the“windowpanes” object, touch sensor and the event relation-ship to the application class, result in interlaced JavaScriptstatements (Listing 2), in particular an event handler regis-tration (line 20) and the associated method (line 4). Further-more, every individual platform provides its ownAPI/frame-work to develop 3D applications, with crucial aspects con-cerning event handling and scene access. Although the gen-eral concepts to cover these aspects are present on all plat-forms, the specific APIs can be very different. More con-cretely, on theWeb, X3D node access is granted to JavaScriptthrough theDOMand event handling conforms to theHTMLevent model [5]. On the Android platform, in contrast, theJava-based 3D library only provides basic inputmechanisms.Therefore, we implemented adapter libraries for each plat-form that provide a more uniform way for scene access andevent handling across the different platforms (Fig. 13, left).

Generated application code skeletons have the followingstructure (Fig. 13, right): in an initialization part, event han-dlers are registered and the scene is loaded, etc. Hook meth-ods and further user definedmethods allow theworkflow tobeextended. SSIML application classes either result in classesof the respective platform (C++or Java), or in first-class func-tions in JavaScript to emulate class oriented structures. Fur-thermore, member variables to access the scene are defined,as specified in the SSIML model. Further code to implementthe application can be stored in hook and event handler meth-ods or in additional user defined methods. Within initializa-tion sections, such as C++ constructors, Android onCreatemethods or JavaScript initialization functions, we use pro-tected regions which allow for more abstract meta modelsandgrammars of the platform.Byproviding hooks, these pro-tected 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 transfor-mation pipelines also becomes more uniform and thus morere-usable. For example, the ASTmeta models for JavaScript,Java, and C++ can partially be re-used, and similarly thetransformation rules for conversion between IMs and ASTs.Overall, the adapter code makes model-to-code mappingsduring 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-

123

Structured development of 3D applications 297

Fig. 12 The interactivemerging view in our round-tripenvironment. Besides adifference visualization usingthe graphical SSIML notation,an additional “sync view”provides functionalities tointeractively accept or rejectchanges and resolve conflicts formodified SSIML elements

Fig. 13 Left adapter libraries wrap platform-specific frameworks(CAVE, Android, Web) to provide structurally similar APIs for codegeneration.Right common structure of generated application logic codeon all platforms

taneous synchronizations of models and code. UML LABuses templates to synchronize between uniform modelingand general-purpose programming languages, such asUML2class diagrams and Java or C# code. In contrast, the pro-posedRTEprocess addresses the special domain of 3Ddevel-opment. 3D and program code is generated from a graphi-

cal DSL and elaborated by different developer groups, eachusing their own specialized development tools.

MoDisco [7] is a reverse engineering tool to retrievegeneric software models from a given implementation withso called discoverers, which have to be implemented or canpartially be derived from meta models. In our case, in con-trast to pure reverse engineering tools, the design of reverseAST-to-IM-to-SSIML transformations can be derived fromthe respective forward transformations.

EMFStore [14] targets collaboration and version controlofmodels. Elementmatchings are established by IDs, similarto our semi-automatic merge approach (Sect. 5.2.1). Further-more, EMFStore records changes to model elements in theeditor and saves editing operations for version control. In ourcase, programmers and 3D content developers use externaltools to elaborate generated source code and thus, recordingediting changes is not possible. Instead, difference calcu-lation is performed on models which are derived from thevarious code bases.

Adapters allow for unified code structures on all plat-forms (Sect. 5.3) by introducing polymorphism, which addsanother level of indirection. ForAndroid, theVirtualMachineinlines function calls during optimization when needed toeliminate indirections. In contrast, indirections are typically

123

298 B. Jung et al.

not resolved by C++ compilers, which leads to an additionallookup in the virtual method table. However, the impact ofadapters to the performance of the CAVE application is neg-ligible.

Synchronization of the various artifacts occurs “on-demand”, in a non-simultaneous fashion in order to support aconcurrent development process. The concurrent work stylealso improves on the typically sequential 3D developmentprocesswhere 3Dmodeling often strictly precedes the imple-mentation of the application logic.

Our multi-tiered RTE implementation achieves complexmodel-to-code transformations through a sequence of sim-pler transformations. In this way, task specific transformationlanguages can be employed and the process of defining trans-formations becomes more manageable overall. Furthermore,subdividing the model-to-code transformation chain simpli-fies the extension to further platforms. Due to adapters andthe similar structure of the generated code for the differentplatforms, meta models and the IM-to-AST transformationscan be re-used to some extent. In addition, SSIML-to-IMtransformations can be completely reused. Since merging isperformed on a platform-independent intermediate stage, asingle model-merging algorithm is used instead of weavingcode of different languages.

Besides SSIML, several other approaches to the structureddevelopment of 3D applications have been proposed. Theinteraction techniques markup language (InTML) integrates3D interaction techniques into VR applications by specify-ing an abstract XML-based model that can be executed in aruntime environment [10]. However, the auto-generated pro-gram code cannot be extended. Thus, the functionality ofthe program is limited to the scope of its modeling languageand multi-platform development depends on the port of theruntime. In contrast to the XML-based notation of InTML,the graphical notation of SSIML is more accessible to cre-atively oriented 3D content developers. Contigra [8] sup-ports the high-level and multi-disciplinary development of3D components, that can be transformed to 3D applications.However, a reverse step to achieve iterative development isnot possible. April [18] can be used to create textual modelsof AR presentations. These models can be transformed tocode for two platforms. Again, a reverse phase is not possi-ble.

In the current state of our implementation, a completeround-trip is possible for 3D web applications and AndroidAR applications. In particular, changes to the SSIMLmodel,X3D, JavaScript andAndroid code can be fully synchronizedwith each other and also be applied to the C++ CAVE code.The reverse engineering step for C++ code is currently onlypartially implemented, such that changes to the C++ codecannot yet be merged into other artifacts.

Layout and formatting information of models and sourcecode is not preserved, except in protected regions and user

defined functions (Sect. 5.3). Formatting capabilities are pro-vided by programming tools and our model editor.

6.1 Case study

We used our round-trip environment so far to develop sev-eral proof of concept applications. Furthermore, our tool hasbeen validated in an extensive student project. The goal wasto create a series of web-based 3D application presenting theworkings of several historic and for pedagogical reasons sim-plified pipe organs, using our round-trip environment. Theproject comprised two phases, each lasting six months.

In the first project phase, we introduced the SSIMLmodeleditor and the JavaScript and X3D code generators, to trainthe students. In this phase, seven students participated withexpertise in the following areas: two students had advancedJavaScript programming skills, three students were experi-enced in 3D modeling, and two students had basic trainingin programming and software development. The latter twostudents were assigned the role of software designers andcreated the SSIML models while the other students wereused according to their core expertise in programming and,respectively, 3D modeling. As result of the first phase, twoprototypical web applications were developed.10

For the second project phase, the students’ task was todevelop a complex schematical 3D organ to exemplify thefunctionality of an organ in the web (Fig. 14). This shouldbe achieved by exploded drawings supported by animations,which guide the user through various levels of detail, from arough overall view of the organ to a detailed representationof each component. The application should be developed inan iterative development process, using our round-trip tool.Five students participated in the second project phase: onestudent with extensive JavaScript programming skills, threestudents with extensive 3D modeling skills and one studentwith basic 3D modeling skills. Four of the five students werefamiliar with SSIML modeling but only one student acted assoftware designer.

Within six months, students completed two round-tripsand thus developed two versions of the 3D application.11

The original SSIML model specification included only oneviewpoint, which should be modified from within JavaScriptcode in order to focus on the selected 3D object from a suit-able perspective. However, defining viewpoint parameters isa more appropriate task for 3Dmodelers, who use 3Dmodel-ing tools andhave a distinct spatial awareness. Thus, 3Dmod-elers added and defined these viewpoints.Additional changesto the code concerned renaming of misspelled terms and the

10 http://vr.tu-freiberg.de/organ-visualization/organ-one, (2014).11 The second iteration served as validation to ensure that a consistentversion of the application had been developed.

123

Structured development of 3D applications 299

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

deletion of the original viewpoint. The size of the final appli-cation is about 240 MB.12

Due to generated X3D and JavaScript code structures,3D modeling and application programming could be per-formed concurrently. Furthermore, the JavaScript developerwas even able to finish his task before 3D developers fin-ished 3D modeling. Therefore, implementation time couldsignificantly be reduced.

As a further result, we could show that our approachalso scales well with large model sizes and applications.Table 1 gives an overview of the number of elements con-tained in each model during one round-trip iteration. TheSSIML model of the complex organ example proved as stillmanageable. Transformations between models and text andmodel merging are performed within several seconds.13 Thenumber of effective lines of code (eloc) for JavaScript con-tains no comments and at least three characters per line. ForX3D, the number of AST elements equals the number ofXML tags and is a more meaningful descriptor than codestatistics.

Furthermore, the students’ feedback on the semi-automa-tic merge process was crucial to initiate and inform the devel-

12 http://vr.tu-freiberg.de/organ-visualization, (2014).13 The current implementation focusses on correctness and only sec-ondarily on performance.

Table 1 Number of model elements during forward and reverse engi-neering, for the car configuration example and aweb-basedvisualizationof 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 describedin Sect. 5.2.2.

7 Conclusion

We presented a round-trip engineering approach supportingthe interdisciplinary development of 3D applications. Froma common model specified in SSIML, a domain specific lan-guage for modeling 3D applications, skeletons of both 3Dand program code are generatedwhich are then elaborated by3D content developers and programmers. In a reverse phase,code level changes are synchronized with the SSIML modelto support an iterative development process. The presentedapproach was designed in such a way, that it honors the inter-disciplinary and concurrent development of 3D applicationsinvolving 3D content developers on the one side and pro-grammers on the other. We demonstrated the feasibility ofour approach with several example 3D applications for mul-tiple platforms, including modern web browsers, a virtualreality CAVE, and Android devices. General benefits of themodel-driven approach include that SSIMLmodels can serveas a communication aid for the involveddeveloper groups andmay be used for documentation purposes. Further, automaticcode generation provides a basic code structure and frees theprogrammers from repetitive implementation tasks.

A multi-tiered transformation pipeline is used to imple-ment the RTE process. Splitting up the forward and reversephases into smaller steps simplifies the extension of our RTEprocess to further platforms, as only platform-specific trans-formations need to be implemented for each additional plat-form. Therefore, themulti-tiered RTE implementation scaleswell with the number of target platforms in 3D applicationdevelopment. Synchronization of code bases and model canoccur in twoways, either in an automated process or an inter-active process based on a graphical difference visualization.

Acknowledgments This research is partially supported by the Deuts-che Forschungsgemeinschaft (DFG).

123

300 B. Jung et al.

References

1. Alanen M, Porres I (2003) Difference and union of models. In:Stevens P, Whittle J, Booch G (eds) UML 2003—the unifiedmodeling language, vol 2863. Lecture notes in computer science.Springer, Berlin, Heidelberg, pp 2–17

2. Antkiewicz M (2007) Round-trip engineering using framework-specific modeling languages. In: Companion to the 22nd ACMSIGPLAN conference on Object-oriented programming systemsand applications companion, ACM, pp 927–928

3. Aßmann U (2003) Automatic roundtrip engineering. Electr NotesTheor Comput Sci 82(5), proceedings of the Fifth Workshop onquantitative aspects of programming languages (QAPL 2007)

4. Azuma RT et al (1997) A survey of augmented reality. Presence6(4):355–385

5. Behr J, Eschler P, Jung Y, Zöllner M (2009) X3DOM: a dom-basedhtml5/x3d integration model. In: Spencer SN, Fellner DW, Behr J,Walczak K (eds) Web3D. ACM, pp 127–135

6. BrunC, PierantonioA (2008)Model differences in the eclipsemod-elling framework. UPGRADE Eur J Inf Prof IX(2):29–34. http://www.cepis.org/upgrade/files/2008-II-pierantonio.pdf

7. Bruneliere H, Cabot J, Jouault F, Madiot F (2010) Modisco: ageneric and extensible framework for model driven reverse engi-neering. In: Proceedings of the IEEE/ACM international confer-ence on automated software engineering. ACM, pp 173–174

8. Dachselt R, Hinz M, Meissner K (2002) Contigra: an XML-basedarchitecture for component-oriented 3D applications. In: Proceed-ings of the seventh international conference on 3DWeb technology.ACM, Web3D ’02, pp 155–163. doi:10.1145/504502.504527

9. Efftinge S, Völter M (2006) oAW xText: a framework for textualDSLs. In: Eclipsecon Summit Europe 2006. http://www.eclipse.org/Xtext

10. Figueroa P, Green M, Hoover HJ (2002) InTml: a description lan-guage for VR applications.Web3D ’02: proceedings of the seventhinternational conference on 3DWeb technology. ACM, New York,pp 53–58

11. Johannes J, Samlaus R, Seifert M (2009) Round-trip support forinvasive software composition systems. In: Bergel A, Fabry J (eds)Software composition. Lecture notes in computer science, vol5634. Springer, pp 90–106. 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 Con-ference on pattern languages of programs (PLoP2003)

13. Kehrer T, Kelter U, Pietsch P, Schmidt M (2012) Adaptability ofmodel comparison tools. In: Proceedings of the 27th IEEE/ACMInternational Conference on automated software engineering.ACM, New York, NY, USA, ASE 2012, pp 306–309. doi:10.1145/2351676.2351731. http://doi.acm.org/10.1145/2351676.2351731

14. Koegel M, Helming J (2010) EMFStore: a model repository forEMF models. In: Proceedings of the 32Nd ACM/IEEE Interna-tional Conference on software engineering, vol 2. ACM,NewYork,ICSE ’10, pp 307–308. doi:10.1145/1810295.1810364. http://doi.acm.org/10.1145/1810295.1810364

15. Kolovos D, Paige R, Polack F (2006) Merging models with theEpsilonmerging language (EML). In:NierstraszO,Whittle J,HarelD, Reggio G (eds) Model driven engineering languages and sys-tems, vol 4199. Springer, Berlin, Heidelberg, chap 16, pp 215–229.doi:10.1007/11880240_16

16. Kolovos DS, Paige RF, Polack F (2008) The epsilon transfor-mation language. In: Vallecillo A, Gray J, Pierantonio A (eds)Theory and practice of model transformations, First InternationalConference, ICMT 2008, Z++rich, Switzerland, July 1–2, 2008,Proceedings, vol 5063. Springer, LNCS, pp 46–60. doi:10.1007/978-3-540-69927-9_4

17. Kolovos DS, Di Ruscio D, Pierantonio A, Paige RF, (2009) Dif-ferent models for model matching: an analysis of approaches tosupport model differencing. In: Comparison and versioning of soft-ware models, (2009) CVSM’09. ICSEWorkshop on, IEEE, pp 1–6

18. Ledermann F, Schmalstieg D (2005) April a high-level frameworkfor creating augmented reality presentations. In: Proceedings of the2005 IEEE Conference 2005 on virtual reality. IEEE, VR ’05, pp187–194

19. Lenk M, Schlegel C, Vitzthum A, Jung B (2012a) Round-trip engineering for 3D applications: models and transforma-tions. Preprint 6/2012, Faculty of Mathematics and Informat-ics, TU Bergakademie Freiberg. http://www.mathe.tu-freiberg.de/forschung/preprints

20. LenkM,VitzthumA, JungB (2012b)Non-simultaneous round-tripengineering for 3D applications. In: Proceedings of the 2012 Inter-national 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, D’Hondt M (2005) Selfsync: adynamic round-trip engineering environment. In: Companion tothe 20th annual ACM SIGPLAN conference on object-orientedprogramming, systems, languages, and applications, ACM, NewYork, NY,USA,OOPSLA ’05, pp 146–147. doi:10.1145/1094855.1094906

23. VitzthumA, Hussmann H (2006)Modeling augmented reality userinterfaces with SSIML/AR. J Multimed 1(3):13–22

24. Vitzthum A, Jung B (2010) Iterative model driven VR and ARdevelopment with round trip engineering. In: Proceedings ofSEARIS Workshop at the IEEE virtual reality 2010 Conference,Shaker

25. VitzthumA, PleußA (2005) SSIML: designing structure and appli-cation integration of 3D scenes. In: Proceedings of the tenth inter-national conference on 3DWeb technology, ACM, New York, NY,USA, Web3D ’05, pp 9–17. doi:10.1145/1050491.1050493

Bernhard Jung holds the chairfor Virtual Reality and Mul-timedia at the Technical Uni-versity Bergakademie Freiberg,Germany. He studied ComputerScience at the University ofStuttgart, Germany, and the Uni-versity of Missouri, St. Louis,USA. Afterwards, he became aresearcher at the University ofBielefeld, Germany, where hecompleted his PhD in ArtificialIntelligence in 1996 as well asa habilitation degree with a the-sis on intelligent virtual environ-

ments in 2002. From 2003 until 2005 he was full professor for MediaInformatics at the University of Luebeck, Germany, before joining theTU Bergakademie Freiberg in 2005. His current research interests areVirtual Reality, Large Data Visualization, Human-Computer Interac-tion, and Advanced Robotics.

123

Structured development of 3D applications 301

Matthias Lenk studied com-puter science at the TUBergakademie Freiberg. There,he joined the Virtual Realityand Multimedia Group in 2011as a PhD student. His currentresearch field in theRoundtrip3Dproject combines model-drivendevelopment with Virtual andAugmented Reality.

Arnd Vitzthum studied Com-puter Science at the DresdenUniversity of Technology. FromMarch 2003 until January 2008he was a PhD student andresearch assistant at the Univer-sity of Munich (LMU), MediaInformatics Group. Until the endof 2009, he was working at theFreiberg University of Miningand Technology as a memberof the “Virtual Workers” projectteam. From January 2010 untilMarch 2011 he led the project“Roundtrip3D” (funded by the

“Deutsche Forschungsgemeinschaft” - DFG). Currently, he is work-ing as lecturer at the University of Cooperative Education in Dresden(StA DD), Saxony. His primary research interests are directed towardsmodel-driven development of VR and AR applications.

123