Model

The model layer is developed for a specific diagram type, class diagrams in our case. We divided it into nodes and connections. All elements are derived from ModelElement. As one node can contain others (e.g. a package usually contains classes), the nodes are structured as a composite with children and parent relations. The root element of this structure is ClassDiagram. The connections are referenced by their source and target nodes.

Figure 4.5: Class diagram of the class diagram model.
Image overview_model

This layer fulfills three main tasks. Firstly, it stores all necessary graphical information which can't be found in UML2. These are defined in NodeElement as location and size. Additionally properties like colors and so on could be stored here, too.

Moreover, all elements are IPropertySources, an interface defined in the Eclipse API. That means that they support a number of properties, which can be accessed with getters and setters using property IDs. The concept is widely used in Eclipse, which allows us to reuse functionalities based on it. E.g. we use a property table to present the characteristics of elements. Elements define three types of property IDs. The layout properties like location and size, which are stored in the model. Further, the UML characteristics, like the visibility of a class, that are in fact stored in UML2. Each model element has a reference to its corresponding UML2 element, which is asked whenever such a property is used in the model. The third type of properties is not visible to the user. These IDs serve to connect the model layer with the editparts.

Finally, the model layer acts as application model for GEF, so that its adoption is also imposed by the use of GEF. As we will see in section 4.4, each model element has a corresponding editpart. Once again, the layers are connected via the observer pattern. As all model elements are IPropertySources, its listeners have to be IPropertyListeners. The property IDs described above are used to indicate to the editparts the kind of event that has occurred in the model.

The model contains commands. These are working steps like creating elements, adding one element to another, moving nodes, reconnecting connections and so on. The command classes derive from a class in the Eclipse API, which allows us to use its redo/undo functionality.

Figure 4.6 shows an enhanced version of the relationship between source code, UML2 and model layer. It demonstrates the case of two opened class diagrams that have common elements. These common elements are represented by two instances of each element that reference the same UML2 element. Each class diagram corresponds to an instance of ClassDiagram. The figure is not absolutely correct, since normally the union of all models is equal to the UML2 model.

Figure 4.6: Source code, UML2 and model.
Image sets2

Michael Pradel 2006-06-01