Java Reference
In-Depth Information
Java model, or do we pass our DNC model straight to Xpand templates for Java
generation? Or should we create a model specific for Java EE? Yet another
option is to define a textual concrete syntax using TMF that provides the model-
to-text transformation. These are general questions you need to consider when
doing Model-Driven Software Development (MDSD), and the answer will vary
depending on your requirements, technology preference, relative efficiency, or
other factors. In this topic, we examine two approaches. This section focuses on
the transformation of a Domain-Neutral Component (DNC) model to a Java
domain model. The next chapter looks at the template approach for generating
Java from the DNC domain model. This enables us to examine each approach in
detail and to cover the relative strengths and weaknesses of each.
First, we need a Java domain model. The WebTools project maintains a Java
EMF Model (JEM), which originated in the Visual Editor project. At this point,
you need to install WebTools if you're not using the DSL Toolkit from Amalgam,
which includes the JEM model in its distribution. Although the model suits our
needs, it also presents some challenges, such as the fact that it extends Ecore
itself. We chose this model instead of implementing our own from scratch, to
illustrate the challenges you might face working with an existing model, where
certain restrictions and workarounds are inevitable. To make it even more
“real,” the version of the model used in this section included an annotation, indi-
cating that it was indeed a work in progress.
The first step is to learn this model. The
Metamodel Explorer
provides you
with a means to do this, as does the familiar process of importing the project into
your workspace and generating an Ecore diagram, as shown in Figure 6-19. Keep
in mind that this model extends Ecore itself, so what you see in Figure 6-19 is
only the Java extension of our familiar Ecore model.
Figure 6-19
JEM model
Search WWH ::
Custom Search