02341: Model-based Software Engineering (f16)
| Assignment 2: EMF — some more details |
| |
|
In this tutorial, you will refine the simple tree editor that you
had generated in Assignment 1: you
will equip the objects shown in the generated editor with slightly
nicer icons and labels; more importantly, you will properly integrate
the user action for firing a transition with Eclipse's undo/redo-framework,
which will allow the user to undo and redo the firing action.
You will learn:
- how to change icons for objects and menus in the generated editors,
- a bit on item providers and how to properly change the generated
code in order to change the labels of items,
- how to program and execute EMF commands, so that user actions are properly
integrated with the Eclipse command stack, and
- a bit on the structure of the generated code (this is also discussed
in the lecture).
Below, the assignment is broken down into simple steps starting from your
solution for Assignment 1 (if you did
not finish that, do that right away).
- Have a closer look at the generated code. As you know already, there
are three parts (we do not consider the generated test code here):
- The EMF generator generates some graphical icons for all the object
types of the model and for all the child creation menus: star-shaped icons
in different colours, which are not very helpful. In this step, you
should change the icon for one type of object (let's say transitions)
to something more reasonable and also for the respective creation tool.
You can change the icons by copying other GIF images to the folder images/full of the generated edit project. Note
that you can also change the gen model itself: by selecting a class
and changing the attribute "Image" in the "Edit" selction to false,
objects of this type will not be presented with an icon.
Replace at least one of the icons with a reasonable image (you can use
any GIF editor for reating a 16x16 gif image). Note that there are
images for the objects (subfolder obj16) themselves and for the
"tools" for creating them (subfolder ctool16). If you want the
same image for the tool as for the object itself with a plus-sign overlay,
you can actually delete the respective image from the subfolder ctool16.
- In the tree editor for Petri nets (opening a Petri net file in the runtime
workbench), each object is also shown with a label; typically with
the class name followed by the value of one attribute (in your Petri net
example, that probably is the name of the Petri net or the name of the node).
Since, in the Petri net model, arcs do not have an attribute, they just receive
the label "Arc", which makes it difficult to see on a single glance what the
source node and the target node of the arc are.
In this step, you should change the label of an arc so that, for an arc
running from a node with name p1 to a node with t2, the label is "Arc p1 -> t2".
To this end, you need to change the automatically generated ArcItemProvider in the edit code. In this class, you need to change
the method getText(), where the parameter could by any object;
but in this case it will be an Arc. Change this method
so that it returns a String like "Arc p1 -> t2", where "p1" is the name
of the source node and "t2" the name of the target node.
Note that you change automatically generated code now (indicated
by the Java annotation @generated for the respective method). In
order for the generator not to overwrite your manual changes next
time you generate the code from the model again, you need to extend this
annotation to @generated NOT. Actually, you could also delete
the generated annotation completely; but the extension @generated NOT
has the advantage that you can easily search for your manual changes.
If you want to use the generated code in the code that you manually
change, you can rename the generated method "XXX" to "XXXGen" and
then implement the method "XXX" yourself and calling "XXXGen"; the
generator will then change the "XXXGen" instead of "XXX" (assuming
that "XXXGen" is annotated with @generated and "XXX" is
not (see the EMF Book for more details).
- After you start the runtime workbench and open a Petri net file,
you will see the icons and also the labels for arcs, which you
programmed above. But, when you change the source and the target
of the arc, its label will not be updated automatically (the
label will be updated though, when you close the editor and open
it again). The reason why the lables do not upadate right away is
that the
"viewer" is not notified of the user's changes of the source and
the target reference. In order to update the label of the arc
when the source or the target references change, you need to
switch the notification on. This is done in the Gen model.
In order to switch the notifications on, open you Gen model
in the EMF project of the development workbench, navigate
to the Arc and set the property "Notify" for both
the source and the traget reference
to true and save the Gen model. Then you should
regenerate the code from this Gen model;
make sure that you have marked the getText() method
of the above ArcItemProvider with @generated NOT;
otherwise the code generator will overwrite your manual changes.
After you have generated the code, restart the runtime workbench
of Eclipse again (if it is still running shut the running version down
before).
After re-starting runtime workbench, the Petri net
editor should update the labels of arcs right away when the
source or target of the arcs are changed. Note that the
label still does not update, when you change the name of
the source or target node (do you know why?). It will be
updated, though, when you open the file the next time.
- As mentioned above, the way we implemented the "Fire Transition"
action in Assignment 1, is done in a nasty way, and it does not
properly integrate with the Eclipse undo/redo-framework. You will
fix this problem by implementing the transition as a command.
To this end, in your simulator plugin from Assignment 1, add a
dependency to the Eclipse project org.eclipse.emf.edit by using the
MANIFEST / plugin.xml editor.
Then create a class FireTransitionCommand, which
extends the class org.eclipse.emf.common.command.CompoundCommand.
In the constructor
FireTransitionCommand(EditingDomain domain, Transition transition)
of this new class
add a RemoveCommand for each
token that needs to be removed from a place; you do that by the help of this.append(),
and the respective command can be created by new RemoveCommand(domain, place,
PetrinetPackage.eINSTANCE. getPlace_Tokens(), token).
Moreover, add a CreateChildCommand for each token that needs to be added.
You should create the new token via the model's factory (see
Assignment 1); the command could look like
new CreateChildCommand(domain, place,
PetrinetPackage.eINSTANCE.getPlace_Tokens(), token, null).
In the above code snippets, the domain refers to the so-called
editing domain the model is assoicated with, which is passed to the command
as parameter of the constructor (see below); the place
refers to the place which should be changed, PetrinetPackage.eINSTANCE.getPlace_Tokens() refers to the feature
of the place that is changed (in this case, the references to tokens), and token is the token that is supposed to
be removed from or added to the place.
Instead of changing the tokens programmatically now, in the command handler
from Assignment 1, you can create a FireTransitionCommand and
execute it in the respective editing domain by a piece of code,
that looks as follows:
EditingDomain domain = AdapterFactoryEditingDomain.getEditingDomainFor(transition);
if (domain != null)
domain.getCommandStack().execute(
new FireTransitionCommand(domain, transition));
Try your new simulator in the runtime workbench. It should be possible now
to undo and redo the changes that you made by FireTransition actions with
the editor's undo and redo actions.
- In Assignment 1, you have edited the EMF-model
with a simple tree editor. From now own, you might want to use a simple
graphical editor. The version of Eclipse that you for this course comes with
such an editor called EcoreTools. In order to use this editor you need
to switch to the "Modeling" perspective: Windows -> Perspective ->
Open Perspective -> Other..., then selecting "Modeling".
Then, you can create a diagram from your EMF/Ecore model by right-clicking
on your Ecore file, selecting "Initialize Ecore Diagramm...", and following
through the dialogs. In the dialog, "Create a new representation", select
Design -> Entities and the Ecore package that you created for Petri nets
in Assignment 1 and give that diagram (representation)
a description. There should be a file with extension ".aird" now in
the model explorer. When you double click on your diagram in "Representations per
catalog/Design/Entities", you can see and edit graphically the Ecore model.
By clicking on "here" in the open graphical editor, the complete package
is imported and shown as a diagram (you will need to arrange that in a
nicer way, though).
When you change that diagram and save it, the model file itself will be
updated accordingly.
You will find more information on how to use this editor in the Ecore Tools
User Guide: http://www.eclipse.org/ecoretools/doc/
|
| Material on EMF and EcoreTools |
| |
|
|
|
