Saying Hello World with UML-RSDS - A Solution to the 2011 Instructive Case

1. A global specification, Cons, of a model transformation, expresses in a platform-independent manner the overall effect of the transformation, as a relation between the source and target models. It is intended to hold true at termination of the transformation.

2. A predicate Asm expresses the assumptions made about the source and target models at the start of the transformation, for example, that the target model is empty and that the source model is syntactically correct wrt the source language.

The specification is therefore independent of any specific model transformation implementation language, and can be used as the basis for development in many such languages. By making explicit the semantic assumptions on source and target models, the specification assists in the verification (formal or informal) of model transformations.

Cons can often be written in conjunctive-implicative form [3], as a conjunction of constraints of the form

where S is a source language entity and T is a target language entity. This pattern is applicable to reexpression transformations such as model migrations, and to abstraction and refinement transformations.

The patterns assist in the derivation of explicit PSM designs from the specification, consisting of a sequence of phases, which apply specific rules or operations to achieve the specification constraints. Provided that the updates defined in Post do not affect the data read in SCond or Post, and that the extent of S is fixed throughout the transformation ( * ), then a constraint of the above form can be implemented by an iteration for s : S do s.op() where op implements the constraint for a particular S object.

This iteration constitutes a single phase in the design. The possible orderings of phases are determined by defining a partial order over the target language entities: T 1 < T 2 if T 1 is used in Cons to define a feature of T 2 (or a feature of a subclass of T 2 ). Any phase that creates T 2 instances must therefore be preceded by all phases that create T 1 instances.

The restriction ( * ) is termed the non-interference condition.

The iterative phase activities derived from the constraints are also terminating and they establish the truth of their corresponding constraint, by construction. The PSM design is derived from the constraints, together with an executable Java implementation, using the UML-RSDS toolset [2]. The resulting executable is a stand-alone implementation of the transformation, operating upon simple text format files defining input and output models.

Here we give the specifications and implementations of the simple transformation tasks in [1]. All of these tasks satisfy the restrictions described above, so they can be specified and designed directly in UML-RSDS. of a use case which represents the transformation. From this an implementation is automatically generated in Java.

Figure 2 shows the basic graph metamodel in the UML-RSDS tools, and the generated design and Java code of the specification. We assume that the following constraint Asm0 of the source model holds:

∀ g : Graph • g.edges.src ⊆ g.nodes and g.edges.trg ⊆ g.nodes

The queries are simple examples of abstraction transformations, and can be specified as follows:

The constraint

on Graph expresses that for each graph there is a result object recording the number of nodes in the graph. An operation op1() is generated to implement the constraint. Likewise for the other queries:

counts the number of looping edges in each graph, and is implemented by an operation op2().

IntResult→exists( r | r.num = g.edges→select(src = {} or trg = {})→size()

counts the number of dangling edges and is implemented by an iteration of an operation op3() on graphs.

IntResult→exists( r | r.num = (g.nodes -(g.edges.src ∪ g.edges.trg))→size()

counts the number of nodes that are not the source or target of any edge.denotes set subtraction and ∪ set union. This is implemented by an operation op4().

We extend the final query problem by defining an auxiliary entity which records the 3-cycles in the graph (Figure 1). Both constraints are on Graph.

The order of nodes in a cycle is not distinguished by C1, if this was required then elements should be ordered (a sequence). Because of Asm0, each three-cycle will consist of nodes in a single graph. The unique existential quantifier ∃ 1 specifies that there must exist exactly one object satisfying the quantified properties, ie, duplicated cycles are not included in cycles.

Each constraint is refined by a specific phase in the design. The exists1 quantifier is implemented by checking that there is no existing ThreeCycle with the required property, before creating such an element.

An alternative approach would be to evaluate the set of three cycles in a single expression:

edges→collect(e1, e2, e3 | {e1, e2, e3})→asSet()→select(s |