Developing a DSL Abstract Syntax - Eclipse Modeling Project: A Domain-Specific Language Toolkit - page 53

With our base model complete, we can create our dnc.ecore model. To ref-
erence our oocore.ecore model in our newly created dnc.ecore model, we
need to use the EMF Load Resource context menu in the default EMF editor.
Fortunately, the dialog that appears now contains options to Browse Registered
Packages , Browse File System , and Browse Workspace . At one time, you needed
to enter platform:/ URIs into the field to load a registered package. In our
case, the oocore.ecore model is easily found in our workspace.
In creating our DNC model (Figure 3-11), several options exist, as always.
You've seen that using an enumeration to define the type is one solution, as was
used in the Mindmap domain model's Relationship class and Type enum.
This approach has some drawbacks, including the loss of polymorphic behavior
in our templates and transformation scripts. To illustrate the differences, let's go
ahead and create an Archetype abstract class that extends our oocore::Class
class. Each of our archetypes will extend the Archetype class. We also add an
Association class that extends oocore::Reference and add a property to
signify aggregation. Although it is not a true Association class in the UML
sense, it aids us in developing our diagram and hiding some complexities of the
underlying model to the Practitioner. As we develop the diagram and other DSL
artifacts, we'll revisit this model and refine it as necessary, potentially pulling up
some functionality into the domain model to aid in our color modeling and
model transformations.

Figure 3-11 Domain-neutral component domain model