Model Transformation: Code Generation and Multiple Views

at a high level of abstraction using domain-specific syntax and vocabulary. However, in order to integrate existing simulation tools and to allow multi-view editing in the NanoWorkbench, the experiment model has to be transformed. In the following subsec-tions, we discuss these model transformation tasks.

Targeting Existing Simulation Tools

Our application of MDE to nanostructure development is not only concerned with spec-ification and documentation of experiments but also about model execution, which in this case means performing a simulation of the described experiment. The experiment model abstracts from the concrete way an experiment is performed, for instance, which simulation tool is used to run a simulation or how an according real-world experiment

3.1. The NanoWorkbench – A Workbench for Experimental Physics 51

Model

SetupSec +projectName

StructureSec SimulationSec

...

Material +name +index

Objects

Slab +coordinate +...

1..*

Lattice +latticeType +...

...

0..*

... ...

Figure 3.7: TheNanoDSL’s generated metamodel consisting of Java classes and interfaces

Figure 3.8: The generated textual editor for theNanoDSL

52 Chapter 3. Model Synchronization in a Domain-Specific Workbench is set up. In order to use existing simulation tools, valid input for these tools needs to be generated from the experiment model. Both Lumerical FDTD Solutions and Meep accept text files as input which have to containLumerical scriptor Lisp code with Meep library calls, respectively. Code generators targeting these tools can be implemented by model-to-code transformation. Conceptually, every code generator is a different, indi-rectly defined, execution semantics of theNanoDSL.

When we implemented these code generators we experienced that they were conceptu-ally very similar. We decided to merge common parts of these code generators into one model-to-model transformation. This transformation produces an intermediate model which is conceptually closer to the input required by simulation tools. However, the intermediate model still abstracts over the different input formats of the different simu-lation tools. From this intermediate model, much simpler model-to-code transformations are required to target different simulation tools. This not only reduces redundancy be-tween code generators but also allows more static verification of transformations to be applied. In contrast to a model-to-text transformation which produces untyped text, the output type of a model-to-model transformation is explicitly defined by its target meta-model, so that the well-formedness of the transformation output can – at least partly – be statically checked. Thus, implementing code generation as one shared model-to-model transformation and several small model-to-code transformations reduces both the effort to integrate further simulation tools as well as the likeliness to have mistakes in the code generator implementation.

The arrangement of model transformations in the NanoWorkbench is illustrated in Fig. 3.12 on p. 56. The implementation of this shared model-to-model transformation is part of our case study and therefore presented in detail in Sec. 6.1 of Chap. 6.

Multiple Views

Although the domain experts liked the conciseness of the textual NanoDSL, they were used to having a visualization of the geometry of the designed nanostructure from their simulation tools. A visualization of the geometry helps to detect mistakes and provides a quick overview of the nanostructure. To provide a geometry visualization view as part of the NanoWorkbench, we could reuse the model-to-model transformation presented in the previous section. The intermediate model produced by this transformation is already much closer to a declarative geometry description needed for a visualization than the model created directly with the NanoDSL. Therefore, providing a passive – that is, not editable – geometry visualization view is simple. Fig. 3.9 shows a 2D visualization view which accompanies the textual NanoDSL editor. The view displays the result of creating a lattice of holes according to the lattice specification and of applying all specified lattice modification operations. The view is refreshed every time the textually described NanoDSLmodel is saved, by triggering the model-to-model transformation.

However, as the geometry view is a useful abstraction of the experiment description – a perspective focusing on the geometry – certain tasks can be easier achieved by allowing edits directly from that view, such as moving or deleting single holes. This means that ed-its made in the geometry view need to be propagated back to theNanoDSLmodel which

3.1. The NanoWorkbench – A Workbench for Experimental Physics 53

Figure 3.9: The nanostructure view visualizes the geometry of the nanostructure captures the complete experiment description. Editing a system description from sev-eral task-specific perspectives is calledmulti-view modeling ormultimodeling (Hessellund et al., 2007). As already discussed in Chap. 1, providing multi-view editing capabilities in a domain-specific workbench can be achieved by bidirectional model transformation. The implementation of a bidirectional model transformation for an editable geometry view is part of our case study and presented in detail in Sec. 6.2 of Chap. 6. However, realizing view synchronization by bidirectional model transformations is not the only approach to multi-view modeling. In the next section, we discuss different approaches to multi-view modeling and explain that we chose a model transformation based approach because it allows us to reuse existing tools for generating language tools without modification.