This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Developing the Mindmap Domain Model
We develop a simple mindmap DSL and use it throughout the book to provide an example of how to use components of the Modeling project as a DSL Toolkit. This model forms the base of our fictitious Requirements Elicitation Project (REP).
This is the beginning of those sections in the book that you can follow in a tutorial fashion. Solution projects are available to save time, although you should be able to begin from scratch and produce these solutions on your own. It’s up to you to follow along or simply review the solutions as we proceed.
Figure 3-4 is a diagram of the basic mindmap DSL we create in this section. Not much explanation should be required here because you can easily see that a Map class serves as the container for Topics and Relationships, which both extend from MapElement. The following sections provide details on setting up a DSL project and creating this model, along with the other DSL artifacts associated with the project.
)
Figure 3-4 Mindmap domain model
3.3.1 Project Setup
Before getting started defining our mindmap domain model, we need a new project. Although EMF and GMF provide their own project wizards, we use the DSL Project Wizard provided by the Amalgam project to hold our DSL artifacts. You can create an equivalent project by starting with a plug-in project and adding the required dependencies, natures, and builders. The DSL project is also a plug-in project, as we’ll eventually want to deploy the project to facilitate revisioning and extension. Furthermore, Xpand and workflow files currently need to be located in source paths to be developed, so we need a Java project anyway. In the future, this should not be required.
For our mindmap project, switch to the DSL perspective and use File → New → DSL Project to create a new project named org.eclipse.dsl.mindmap. The wizard creates a set of folders: /model, /diagrams, /templates, /transformations, and /workflows. Not all of these folders are required for each DSL project, but we use them for our mindmap. The wizard also adds natures and builders for QVT and Xpand/Model Workflow Engine (MWE).
3.3.2 Creating the Mindmap Domain Model
As mentioned earlier, creating an Ecore model involves many starting points. If we had an existing XML Schema for our domain, we could import it and EMF would take care of serializing documents conforming to the schema. If we used the UML2 project and associated the UML2 Tools class diagram to model our domain, we could import it to create an EMF model. We begin using “classic” EMF to create our mindmap DSL from scratch.
Typically, we’d begin with File → New → Other → Eclipse Modeling Framework → Ecore Model (Ctrl+3 → Ecore Model). However, the DSL Toolkit from Amalgam provides some wizard redefinitions to facilitate DSL development and defines capability definitions to hide the original UI contributions from various Modeling projects. To create our model, we select the /model folder and use the File → New → Domain Model (Ctrl+3 → Domain Model) wizard, which is really just the GMF Ecore diagram wizard. Name the model and diagram files mindmap.ecore and mindmap.ecore_diagram, respectively. Optionally, you can use the Ecore Tools component, available from the EMFT project. It provides some capabilities beyond those that the GMF example editor provides.
Before we begin to model the domain, we need to set some defaults in our mindmap Ecore model. First, right-click on the blank diagram surface and select Show Properties View. This shows the properties for the root package in our new Ecore model. Each Ecore model has a single root package, under which we can create a number of additional subpackages. In our case, we set the properties accordingly: name and Ns Prefix should be set to mindmap; Ns URI should be set to http://www.eclipse.org/2008/mindmap.
Using Figure 3-4, model the mindmap domain using the palette and Properties view. It’s a straightforward model to implement, with only a couple noteworthy items: First, the MapElement class is abstract; second, the rootTopics relationship is derived, transient, and volatile. We implement this derived reference using OCL in Section 3.3.5, “Adding OCL.”
The diagram surface has many features to explore, as discussed in Section 10.1, “Overview.” You should note a few things, however, when using the Ecore diagram to create the mindmap domain model:
- Aggregation links create a reference with the Containment property set to true, in contrast with Association links, which are noncontainment references.
- Setting the upper bound property of a link to –1 creates a many relationship and causes the link to be displayed with the familiar 0..* notation.
- References with eOpposites are shown in Figure 3-4 as a single connection, whereas the Ecore diagram shows two separate links.
3.3.3 Creating the Mindmap Generator Model
With our mindmap.ecore model complete, we can validate it and create a generator model. To validate it, open the model in the Sample Ecore Model Editor and right-click on the root package. Select Validate and confirm that no errors exist. If there are errors, correct them and continue. We look into adding validation for our mindmap model later, which leverages a similar validation framework provided for all Ecore models.
To create mindmap.genmodel, right-click the mindmap.ecore file in Explorer view and select New → Other → Domain-Specific Language → Domain Generator Model (Ctrl+3 → Domain Gen). Note that the original EMF wizard is found in New → Other → Eclipse Modeling Framework → EMF Model (Ctrl+3 → EMF Model). We started by selecting our mindmap.ecore model, so the wizard defaults to the same folder and provides the name we want. It also recognizes that we are importing an Ecore model, but we have to load it ourselves, curiously. We have only one root package, so we can finish the wizard and take a look at the generator model properties.
EMF generator models include several properties to consider. For our mindmap, we need to change only a couple from their default settings. In the root, change the Compliance Level from 1.4 to 5.0 (if it’s not already set to 5.0) and change the Model Directory to be /org.eclipse.mindmap/src. (Note that this changes the edit, editor, and tests properties as well.) We need to manually change the Model Plug-in ID property to org.eclipse.mindmap, however. In the properties for the Mindmap root package, we need to set the Base Package property to org.eclipse to match our new plug-in namespace.
This gets us started, so we can move on to code generation. Later, we return to our mindmap model and add constraints, validation, and other enhancements.
3.3.4 Generate and Run
The last thing to do is generate our mindmap plug-ins and code. Technically, we don’t need to generate code at this time because we plan to leverage dynamic instances as long as we can in the development of our DSLs. However, for those new to EMF, it’s worthwhile to continue with generation at this point to see how things work. This is accomplished by right-clicking the root of the mindmap.genmodel in the editor tree and selecting Generate All. This generates our model code, edit code, editor code, and test skeletons, each in their own plug-in projects. We don’t need the generated editor code because a diagram provides our primary means of working with mindmap instance models. For now, we can continue by running the generated editor to verify our model and configuration.
To run our plug-ins and test the functionality of our editor, we need to be in the Plug-in Development Environment perspective to gain access to the appropriate Run option. Select Run → Open Run Dialog (Ctrl+3 → Run C) and create a new Eclipse Application run configuration named requirements in a directory named runtime-requirements. Figure 3-5 is an image of this dialog. Figure 3-6 shows the Arguments page with some arguments for launching on Mac OS X. We use this launch configuration throughout our development of the sample projects, hence the general requirements name.
)
Figure 3-5 Requirements launch configuration
)
Figure 3-6 Requirements launch configuration arguments
Run this configuration to launch a new instance of Eclipse with the new plug-ins installed. We could trim the plug-in list to launch only those plug-ins we need for our application. This makes launching faster and keeps us aware of our underlying plug-in dependencies. In Chapter 8, “DSL Packaging and Deployment,” we fine-tune our launch settings before creating our product configuration.
In the runtime workbench, create a new project and follow New → Example EMF Model Creation Wizards → Mindmap Model, giving it whatever name you want and selecting Map as the Model Object. The default EMF-generated editor appears upon finish, ready for you to create new Topic and Relationship instances within the map.
You again need to open the Properties view to set model element properties and establish subtopics and relationship links. Notice that validation is available for our model instances and enforces the basic structural features defined in our model. For example, we declared 1 for the upper and lower bounds on source and target references of our Relationship class. Creating a new Relationship instance in our model and invoking the Validate menu option brings up a dialog that points out that these required features were not set. As we enhance our model further, EMF and the Validation Framework will provide additional validation, as used by GMF for diagram validation.
3.3.5 Adding OCL
As you should recall, we added a derived, transient, volatile rootTopics reference in our Map class. Section 3.2.4, “Applying OCL,” described the basics of adding OCL and using dynamic templates to generate implementations for invariant constraints, method bodies, and derived features. The example in that section covered the rootTopics implementation using OCL and used a set of dynamic templates that we use in this context as well. At this time, rename the default templates folder to be a templates-domain source folder in the mindmap project, and copy the templates provided in the solution into this folder. We’ll have additional templates later for deployment, so we can separate them into different root folders. Each DSL project that uses OCL to refine its domain model will reuse this set of templates. Then return to Section 3.2.4 and configure the mindmap.ecore model to use OCL to implement the rootTopics feature.
We can leverage OCL in our model in additional places to provide an implementation and avoid having to modify our generated code. Let’s begin by adding a method that returns the full set of subtopics for a given Topic.
Finding All Subtopics
Currently, our model has a subtopics reference on each Topic, along with a method, allSubtopics(), that is intended to return a list of all of a Topic’s subtopics—that is, its subtopics, all of their subtopics, and so on. All methods declared in an Ecore model require an implementation to be provided, so we turn to OCL, where the implementation of this method is trivial, thanks to the nonstandard closure iterator in MDT OCL:
self->closure(subtopics)
We need to add an EAnnotation to the method in our model with Source equal to http://www.eclipse.org/2007/OCL. A child Details Entry is added to the annotation with the previous expression as its Value property and with a Key value of body. When we regenerate our model code, we can see that our implementation is provided:
/**
* The parsed OCL expression for the body of the
* '{@link #allSubtopics <em>All Subtopics</em>}' operation.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @see #allSubtopics
* @generated
*/
private static OCLExpression<EClassifier> allSubtopicsBodyOCL;
private static final String OCL_ANNOTATION_SOURCE =
"http://www.eclipse.org/2007/OCL";
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public EList<Topic> allSubtopics() {
if (allSubtopicsBodyOCL == null) {
EOperation eOperation =
MindmapPackage.Literals.TOPIC.getEOperations().get(0);
OCL.Helper helper = OCL_ENV.createOCLHelper();
helper.setOperationContext(MindmapPackage.Literals.TOPIC,
eOperation);
EAnnotation ocl = eOperation.getEAnnotation(OCL_ANNOTATION_SOURCE);
String body = ocl.getDetails().get("body");
try {
allSubtopicsBodyOCL = helper.createQuery(body);
} catch (ParserException e) {
throw new UnsupportedOperationException(e.getLocalizedMessage());
}
}
Query<EClassifier, ?, ?> query =
OCL_ENV.createQuery(allSubtopicsBodyOCL);
@SuppressWarnings("unchecked")
Collection<Topic> result = (Collection<Topic>) query.evaluate(this);
return new BasicEList.UnmodifiableEList<Topic>(result.size(),
result.toArray());
}
Again, here we see the boilerplate OCL code that configures an OCLExpression if it’s the first invocation, and then it invokes the expression obtained from the annotation. We leave the mindmap model at this point and move on to develop the second domain model in our product line.