This example is from the area of tool building. UL IMCS has started a new project – Metamodel and Transformation based Tool Framework (TTF). This example has been taken from the TTF subproject - METAclipse framework. According to this framework a diagram presentation metamodel is designed and an engine (Eclipse based) is built which can visualize a correct presentation model (an instance set corresponding to this metamodel) – display a visible diagram containing the given elements. In addition, this engine can intercept tool user actions upon this diagram (such as a request to create new diagram element, edit data visible in a diagram element, move a diagram element etc.). Pure "graphical" actions such as move are performed by the engine directly, but all "logical" actions are converted into commands – special instances (or linked instance groups) which then are performed by appropriate transformations. Thus a specific modeling tool functionality is determined by the standard engine and the supplied set of transformations. These transformations actually determine the complete logic of the tool – what elements can be created and where, how the modification of data is reflected into visible diagram elements, what are correct data and so on.

In particular, these transformations have to maintain the mapping between a domain metamodel (such as whole or part of UML metamodel) and the fixed presentation metamodel for this framework. The mapping determines what kind of diagram element (node, part of node etc) corresponds to the given domain element.

The complete presentation metamodel for TTF is quite complicated, but the Fig.1 shows the most essential part of it – proper diagram element structure. There is the Diagram, which consists of Diagram Elements – Nodes and Edges. Node is still an abstract superclass with its most important subclass being the CompositeNode – an element such as class node, enumeration node in class diagram, action in activity diagram and so on. A CompositeNode can contain Labels – text elements (such as class name, class stereotype, one attribute line, enumeration name in class diagram). In addition, a CompositeNode can contain a Compartment – a related group of Labels – such as the complete set of attributes for a class.

When a domain model element (class, enumeration,…) has been modified by the tool user via Property dialogs (another part of presentation metamodel and engine, not shown here), transformations have to update the relevant diagram elements – those to which the mapping links from the modified element go. This may be one element in one diagram or several elements in several diagrams – as determined by links. In addition, all updates to these diagram elements must be notified to the presentation engine – links must be set to a singleton (i.e., a class which always has exactly one instance) class Changes. Some of the domain elements must be visualized also in the project tree (determined by another part of the presentation metamodel and another kind of mapping links) as DomainElementNodes. If an element is (or remains) selected, its attributes appear in the appropriate fields of property dialog, including the Properties title.

In the example the domain metamodel is the most essential fragment of UML 2 Class model (approximately equivalent to OMG EMOF metamodel). The example presents a solution to the following task for Enumeration instances. After the user has modified an Enumeration name (via Property dialogs, outside the scope of the example), at first it is necessary to check whether the new name is valid – it must be unique within the containing package (which can also be the whole model). Then the enumeration name is updated in the domain instance. The Enumeration instance may be visualized in one or more Class diagrams, in all these places (i.e., the corresponding CompositeNodes) the name Label must be updated. In addition, the enumeration may be used as a type for some attributes (Property instances), the Label corresponding to such an attribute in a class CompositeNode (one or more) must also be updated accordingly. Finally, the relevant DomainElementNode in the project tree and the Properties title must also be updated. All modified presentation instances must be linked to Changes. One more general comment to the task is that a DiagramElement is found to be of an appropriate kind via its diagElementKind_ attribute.

The main MOLA procedure for this task is upd_ModifyEnumName (Fig.2).

Figure 1. Metamodel

Figure 2. upd_ModifyEnumName procedure

upd_ModifyEnumName procedure receives as parameters from the general command manager procedure the reference to the Enumeration instance to be processed (@en) and the new name (@newname, a parameter in MOLA may also be of a primitive type). The procedure uses two primitive-typed variables – @isOK and @qualPref. The @isOK variable is initialized to true value via a textual assignment, then utl_NameUniquePackgElem is invoked (its third parameter is of in-out kind, currently there are no proper functions in MOLA). The invocation results are analyzed in a textual constraint, in case of uniqueness violation a message to user is shown by means of an external procedure invocation. If the check is OK, a simple rule updates the domain instance. Then a loop is started over all CompositeNodes which visualize the given Enumeration (i.e., are linked to it by the mapping link present). In all these nodes the EnumNameLabel must be updated accordingly.

The invocation of upd_UpdateEnumReferences updates all attribute labels, where the attribute is typed to this enumeration. The last rule updates the corresponding project tree node (mapped via treePres) and the title of Properties (the enumeration is still reflected in Properties), but utl_QualifiedNamePref must be invoked to display the full qualified name in the title.

The procedure utl_NameUniquePackgElem (Fig. 3) is quite straightforward, note only the use of MOLA "existential semantics" for the sole rule – we must find at least one instance of PackagableElement with "another identity" (self<>@el), but with the same name. If the pattern matches, there is at least one such element – it doesn't matter, whether there is more. Note also the setting of the in-out parameter by a simple textual assignment.

Figure 3. utl_NameUniquePackgElem procedure

The procedure upd_UpdateEnumReferences (Fig. 4) in a double loop updates all AttributeLabel Labels, which visualize a Property, having this Enumeration as its type.

Finally, the procedure utl_QualifiedNamePref (Fig.5) emulates a while-loop by simple gotos, in order to concatenate all Package names, into which the given Enumeration is included.

Figure 4. upd_UpdateEnumReferences procedure

Figure 5. utl_QualifiedNamePref procedure