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.
Michael Pradel 2006-06-01