Title: Cooperate UML Class Diagram Syntax Models
The example consists of two meta-models that describe a partial representation of a UML class diagram as used in the Cooperate project: A concrete graphical syntax (CGS) model describes the spatial representation of a diagram as defined by the UML standard. A concrete textual syntax (CTS) model describes a textual representation of the diagram. Both models describe the same diagram and therefore have to be kept consistent.
The information to be represented is given as a formal UML model that conforms to the Eclipse UML 2.5 meta-model.
The concrete graphical syntax (CGS) model conforms to the GMF notation meta-model. Basically, it consists of nodes and edges that refer to the UML elements they represent.
We only consider consistency between the CGS and CTS model. Intentionally, we ignore the consistency between the concrete syntax models and the UML model because the editors for the representations keep the UML model and the representation that is beein edited consistent. For instance, when creating a new class in the graphical editor, the editor automatically creates the new class in the UML model and the according shape in the CGS model. Afterwards, only the consistency between CGS and CTS has to be considered.
In order to call the CGS and CTS models consistent, the following high-level constraints have to hold:
- The set of represented UML model elements has to be equal in both models, i.e., no additional elements must be shown and no element must be missing
- All mandatory layout-specific elements of the representations have to exist but concrete values (e.g. the position of a shape) have not to be covered
- The names of the diagrams have to be the same
The detailed mapping is given as QVT-O mapping for the direction
The major assumption is that there are no concurrent changes in both CTS and CGS. If this holds, an incremental transformation can be used to restore consistency. This involves transforming the changed state to the other concrete syntax model and removing invalid or deleted nodes. The following constraints have to hold:
- layout-specific information is only deleted but not changed during the transformation to preserve the layout of the representations
- for every deleted element that represented a UML element, the according elements have to be deleted as well in the other concrete syntax model
- for every added element that represents a UML element, the according elements have to be created in the other concrete syntax model
- the consistency restoration only uses the states of the involved models rather than change operations
The example originates from the Cooperate project. It covers a common taks of keeping multiple views consistent.
Stephan Seifermann, Jörg Henß