RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Developing a DSL Abstract Syntax with Eclipse : Page 4

Walk through the development of a domain-specific language (DSL) using the Eclipse Modeling Framework (EMF) and supporting components.


3.4 Developing the Requirements Domain Model

In a similar fashion to our mindmap model, we create a new org.eclipse. dsl.requirements DSL project here to hold our requirements model. This forms the base of our fictitious Requirements Management Project (RMP). We create the new requirements.ecore model using the Domain Model Wizard and GMF Ecore diagram, and we complete it to match the diagram and description of Figure 3-7.

Basically, a model contains a collection of RequirementGroups, which contain a number of children groups and Requirements. Requirements have child references and contain Version and optional Comment elements. A number of enumerations for Priority, State, Type, and Resolution are also in the model. A Requirement can also have a number of dependent requirements, which become the basis for our dependency diagram. Note that the author attributes are simple strings. We could create a Team model and reference these elements to assign to our requirements and comments. We also could have a separate Discussion model to use here and in our mindmap, as a topic might have an associated discussion thread. Many possibilities exist, but for the purposes of our sample application, we keep it simple.

Figure 3-7. Requirements domain model

3.4.1 Requirements Generator Model

We create a requirements.genmodel in the usual manner, using the new Domain Generator Model (Ctrl+3 –> Domain Gen) wizard and selecting our requirements.ecore model as the input. We'll make some adjustments to this genmodel and to the generated Edit code because we intend to use the generated EMF editor as part of our solution.

For the display string of a requirement in the editor selection tree, we want to have it be id (major.minor.service):title, where major, minor, and service are from the contained Version element. We'll be using the Properties view to edit the details of the requirement, so we'll have plenty of horizontal space to use in the editor, allowing even longer requirement titles to fit. Another option is to navigate using the Project Explorer view, but this is narrow and does not allow for much information display. Furthermore, we'll have a second tab in the editor to display a requirements dependency diagram, which will also require a bit of editor space. To accomplish the task, we'll select the requirement element in the genmodel and change its Edit Label Feature to be our id:Estring attribute. Unfortunately, we cannot set two attributes to display for the label, as we can for GMF diagrams. This means we have to modify the generated code.

Before generation, we need to check the other properties and make changes accordingly. As with the mindmap and other models, we want to generate our model, edit, and editor code to their own projects, so we can change the Model Plug-in ID and Model Directory properties to be org.eclipse.requirements.model. We generate the three plug-ins and open the org.eclipse. requirements.provider.RequirementItemProvider class from our Edit plug-in. Modify the getText() method as seen next. Note that if we wanted to preserve the generated method to allow the label feature of the generator model to have an effect, we could use the getTextGen() method approach, as described in the EMF documentation.

 * This returns the label text for the adapted class.
 * Modified to show id (major.minor.service) : title
 * @generated NOT
public String getText(Object object) {
  StringBuilder sb = new StringBuilder();
  sb.append(" (");
  Version version = ((Requirement)object).getVersion();
    if (version != null) {
    } else {
    sb.append(") : ");
    String label = sb.toString();
    return label == null || label.length() == 0 ?
      getString("_UI_Requirement_type") : label;

We've eliminated the redundant Requirement prefix from our label because we're using a custom icon to distinguish Requirements from Requirement Groups, Comments, and so on. For our RequirementGroup element, we can similarly modify the getText() method to display only the name attribute; we can modify the Comment element to display created, author, and subject.

3.5 Developing the Scenario Domain Model

Because we're basing the notation for our Scenario diagram on the Business Process Modeling Notation (BPMN) standard, we could simply use its description of the underlying domain model and semantics to develop our DSL. A better approach would have been to find an XSD for BPMN and simply import it into EMF. Unfortunately, no such schema is published with the specification—even worse, a new specification from the OMG, the Business Process Definition Metamodel (BPDM), is slated to provide a domain model for BPMN2. Also unfortunate is that this specification has no serialized format that we can use and is overly complicated for our Scenario DSL. This leaves us to create our own scenario model.

Figure 3-8. Scenario domain model

In a new org.eclipse.dsl.scenario project, we can create our scenario.ecore model as the base of our fictitious Requirements Scenario Project (RSP) project. Figure 3-8 is the model to create using our Ecore diagram.

Elements of a scenario model are maintained in the Process class, which itself extends Element. A Connection maintains target and source references for Elements that are connected in Sequence or Message flows. An Association also connects elements. Elements come in a variety of types, including Tasks, Events, DataObjects, and Gateways. These elements all map in a straightforward manner to notation elements because the model is inherently graphical in nature. The model is actually similar to the description provided in the BPMN specification, although it is a subset.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date