-
Notifications
You must be signed in to change notification settings - Fork 0
Views
The VirtualModel interface representing a V-SUM implements the ViewProvider interface, such that views can be created from a VirtualModel. The interface provides the createSelector method, from which you receive a selector that allows you to select the elements you want to have in your view. You can then call createView on that selector to finally receive a view onto the VirtualModel.
Views can be decorated with different traits. They can record changes performed to the models within them using the ChangeRecordingView and they can derive changes from changed states of the models performed in external editor using the ChangeDerivingView. The latter uses a StateBasedChangeResolutionStrategy, which implements a heuristic to derive made changes.
This documentation needs to be and will be extended in the future.
A state-based change resolution can be used whenever no changes are tracked but need to be derived from the difference between the old and new state of models. Such a strategy resolves state-based changes to fine-grained change sequences. The default streategy uses EMFCompare in its standard configuration.
A custom strategy can be provided by implementing StateBasedChangeResolutionStrategy interface.
If there is no specific state-based change propagation strategy implemented, the default strategy can be used. This strategy uses EMFCompare as the baseline algorithm. EMFCompare provides the differences between the two states in an own change format. These changes are replayed on a checkpoint of the old state of the model. The replay is observed by Vitruv change recorders. These change recorders then provide fine-grained change sequences in the Vitruv change format.
There is a potentially unlimited number of (valid) change sequences that describe the changes between any two states. This means there needs to be work done to determine which is the "right" change sequence, or if there even is such a thing.
Another problem of state-based differences is the loss of information. Since the two states only provide limited insight into the evolution of the model, some information is lost. For example, the order of fine-grained changes is lost. Moreover, renaming a model element cannot be differentiated from deleting that element and inserting another one.
This motivates the need for heuristics that solve these problems. Since potential heuristics are dependent on the specific domains, the strategy mechanism is a key feature since it allows metamodel-specific, state-based change propagation.
The Projective UML Editor for Java (ProjUmlEd4J) is a Sirius-based editor that display ordinary Java code as a UML model. It does not require an explicit UML model as it extracts all necessary information from the Java code and adds additional information, like multiplicities of associations, as annotations to the code. Therefore, this UML editor is only a projection from the Java code, resulting in an always consistent representation of UML class diagram and Java code.
The source code and further information on the development can be found in the GitHub-Repository for Vitruv-Projective-UML-Editor.
Assuming you have installed the editor in your Eclipse, you simply need to do the following:
- Right click on a package in the package explorer -> Select Create UML class diagram
- The editor will open and is ready to use. After saving any changes in the UML editor, the source code is automatically updated. After modifying the underlying source code, the UML editor is reloaded.