UML2

As described in section 3.2, UML2 offers an implementation of the UML metamodel. The public API mostly consists of interfaces for the different parts of UML. We use a relatively small subset of it which is partially presented in figure 4.4. Element is an abstract base interface that is used as common superclass for most other interfaces. The elements of UML2 are structured as composites. They can have children, called members, and usually have a parent element. The root of the composite structure is Model. The Jupe plugin uses exactly one instance of it with the help of a singleton mechanism. Operation describes a method of a class or interface. The other interfaces also present parts of a UML model and are self-explaining.

In order to use UML2 we developed some convenience classes. Firstly, you find UML2ModelFactory to create the different elements. UML2 provides several ways to create them, but none of them works for all elements we use. So we provide for example methods to create new instances of Class in a specified package or in the default package. Moreover, we introduced UML2ModelRoot. It holds the reference to the Model and offers methods to find types using their name, e.g. for packages and classes. Besides, you can use some convenience methods, e.g. to get the absolute name of an element.

Figure 4.3: Source code and UML2.
Image sets1

As illustrated in figure 4.3, the UML2 model presents only a subset of the source code. The main reason is performance. The Jupe plugin aims to be usable for large projects with more than 100.000 lines of code. Presenting them completely in UML2 when only a small part is actually in class diagrams is obviously no good idea. Apart from synchronization questions (described in chapter 5) this poses the problem of references from elements in UML2 to elements that are not included. E.g. class A is in UML2 and has an attribute of type B which is in the source, in a used library or even part of the programming language. The solution we found is a hidden package. It contains primitive types like boolean and int, as well as all referenced classes and interfaces that are not part of our UML2 model.

UML2 provides a mechanism to react on changes in its elements following the observer pattern. Each element can act as a so-called Notifier that sends messages to listeners which are called Adapters. We are using that functionality to connect the UML2 layer with the model layer without any dependency on it. As described in section 4.3, the instances of model classes 4.1 are bound to a specific diagram, whereas the instances of UML2 are unique. E.g. in a situation with two opened class diagrams containing the same class, there is only one instance of Class, but two instances of the corresponding element in the model. The observer mechanism cares about updating one diagram if the other one has been changed. In consequence, it allows the decoupling from UML2 layer and model layer (and thus orthogonality), as well as the update of several representations of UML2.

The UML2 layer is independent from the diagram type. As the source layer, it can be reused for any other diagram type including the already developed convenience classes.

Figure 4.4: Class diagram of the uml2 model.
Image overview_uml2

Michael Pradel 2006-06-01