Subsections


Synchronization

One of the most challenging tasks is the synchronization between the source code and the UML diagrams. With the layered architecture of Jupe it consists of synchronizing the source layer and the UML2 layer. There are two major cases to treat. On the one hand, changes in the source code have to be propagated to the UML2 layer. This should happen each time the user has performed a change in the source code. On the other hand, changes in the UML2 layer should be propagated to the source. E.g. a newly added class in a diagram has to be generated in the source code, too.

We finished the first sense of synchronization, source code to UML, whereas the other way is still to do.

Source to UML

The Eclipse platform provides a way to react on changes of the source code by the user in the form of so-called builders. A builder is a mechanism used by the Eclipse workspace that allows plugins to process changes of resources at specific times. Typically, builders are used to implement processing that transforms resources from one form to another. A good example is the Java builder which is part of the Java Development Tools. It is an incremental builder that gets called each time the user changes a file or directory. The Java builder processes the change by executing the Java compiler. Builders are connected to a project using special properties, named natures. E.g. a project having the Java nature will be processed by the Java builder.

We are using an incremental builder to process changes in Java files and packages. A project whose source code should be synchronized with the UML2 layer has to have the Jupe nature. Consequently, the Jupe builder gets called after every change and can propagate it to UML2. The changes are described with the help of a so-called Delta. They are processed using a visitor (following the visitor design pattern described in [3]).

The visitor forwards the change to so-called handlers, depending on the type of the changed resource. We created an interface IChangeHandler as base for all handlers. They have to treat three kinds of change: adding, removing and changing resources. The interface is independent of the programming language.

We developed two instantiations of IChangeHandler. One for files, FileHandler, and one for folders, FolderHandler. They are specific for Java and analyse the change in order to propagate it to UML2. E.g. a change in a class is processed by comparing all relevant properties of the class, its attributes and its methods. The handler transmits the changes to the UML2 layer, which in turn propagates them to its listeners (see section 3.2), including the model layer. This again causes changes in the editpart and figure layers and finally the adapted diagrams are visible to the user.

The synchronization creates a number of problems which aren't completely solved in the moment. We don't guard against states where UML2 layer and source code are not consistent, for example because the plugin didn't work for some time. Furthermore, there is no possibility for the user to choose the exact behaviour of the synchronization mechanism. For instance it would be interesting to configure if all new classes in the source code are automatically added to the diagrams.

UML to source

This sense of synchronization is not treated up to now. Code generation from diagrams is a very important feature for the plugin, but we didn't had the time to work on it.

http://jupe.binaervarianz.de