- 3.1 DSL Considerations
- 3.2 Eclipse Modeling Framework
- 3.3 Developing the Mindmap Domain Model
- 3.4 Developing the Requirements Domain Model
- 3.5 Developing the Scenario Domain Model
- 3.6 Developing the Business Domain Model
- 3.7 Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
)
Figure 3-7 Requirements domain model
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.
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
*/
@Override
public String getText(Object object) {
StringBuilder sb = new StringBuilder();
sb.append(((Requirement)object).getId());
sb.append(" (");
Version version = ((Requirement)object).getVersion();
if (version != null) {
sb.append(((Requirement)object).getVersion().getMajor());
sb.append(".");
sb.append(((Requirement)object).getVersion().getMinor());
sb.append(".");
sb.append(((Requirement)object).getVersion().getService());
} else {
sb.append("0.0.0");
}
sb.append(") : ");
sb.append(((Requirement)object).getTitle());
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.