Java Reference
In-Depth Information
// implement a simple with no save-as dialogs
public void doSave(IProgressMonitor progressMonitor) {
updateState(getEditorInput());
validateState(getEditorInput());
performSave( false , progressMonitor);
}
At this point, with our database created earlier, we can launch the runtime
instance and open a new diagram using the Database
Open Scenario Diagram
menu. As with the file-based version, you can modify, close, and reopen the dia-
gram. In fact, the two versions continue to function properly, although the data-
base version presents some complications when working with transformations.
With some custom code, you can overcome this by loading and exporting mod-
els from the database to a local file, or by modifying the invocation method for
QVT, as the default launch configuration expects files.
Additional functionality is added to the scenario diagram in Section 10.9,
“Extending Diagrams.”
4.6 Developing the Color Modeling Diagram
Our final sample application diagram is similar to a UML Class diagram, which
gives us an opportunity to explore GMF compartment support for attributes and
operations. We want this business domain modeling diagram to be simple, so we
leave out some features of the UML and even object-oriented programming, such
as navigability and strong aggregation. To begin, we need to consider how to rep-
resent the different archetypes using color. Starting with the figure gallery, we
could create a distinct figure for each archetype and indicate the proper col-
oration. Unfortunately, this “hard-codes” the color and results in a fair amount
of duplication, even if we use the Figure Ref element. We'd prefer a single
archetype figure with a corresponding node in the graphical definition. Further-
more, we'd prefer to give users the opportunity to select the default shade of each
archetype color using diagram preferences.
Concerning the mapping model, we know from our previous diagrams that
adding constraints to node mappings determines their uniqueness and allows the
canonical update of the diagram to function properly. If our domain model used
a simple enumeration type to distinguish archetypes, we could initialize the value
of the archetype's type enum value using a Feature Seq Initializer . The
problem is that the generated code will generate a figure class for each archetype,
and by using the type enum in the constraint, a change of the value in the
Properties will cause the view to be “orphaned” when the update takes place. A
new view will be created for the element and placed by default in the upper-left
corner of the diagram. This is clearly not what we want.
 
Search WWH ::




Custom Search