Listing 4.3: Amoeba-world.
4.5
Flat Abstract Syntax Graphs
On the one hand, Flat Abstract Syntax Graphs (fasgs) are instances of the meta-models we have shown in Section 4.3.1 through Section 4.3.3. On the other hand, since plain graphs do not provide any means of directly including concepts such as, e.g., inheritance and ordered relations which do occur in the meta- models, they have to be encoded in fasgs through additional graph elements. In this section we will shortly discuss some of the issues that arise when flattening UML diagrams to so-called type graphs. The main issues that are of major importance when specifying the operational semantics are, as mentioned above: • how to incorporate the notion of inheritance in plain graphs such as to be
able to benefit from it when specifying the semantics of the language; • how to model ordered associations in plain graphs, which is required for
correctly specifying the language semantics.
The coming paragraphs give an informal description of how those issues have been resolved. For a more formal specification of the flattening transformation in our approach, the interested reader is referred to [112]. Although in our context we only focus on the two above mentioned issues, Kleppe and Rensink [117] give a rather complete formalization of UML class and object diagrams based on graph models.
The first issue to resolve is the fact that in plain graphs we do not have different types of nodes or edges for modelling different syntax element types or associations between those types and instances thereof. Instead, we introduce typing of elements through edge labels. Node types can then be modelled by self-edges.
4.5.1
Inheritance
Concerning the inheritance structure available in UML and used in Section 4.3 for specifying the abstract syntax of Taal, we ideally want to specify semantics for language constructs as generally as possible. For example, suppose we have the inheritance structure as shown in Fig. 4.5.
Chapter 4. Semantics Through Graph Transformations
D
C B
A -d
Figure 4.5: Example inheritance structure in UML.
For cases in which specific transformation do not distinguish between the two subclasses of class A, we want to specify a single transformation rule that applies on both B- and C-instances. In the usual setting this can only be achieved by including the reflexive and transitive closure of the superType-association in the rule. The main drawback of this approach is that transformation rules become slightly bigger and, more importantly, less intuitive.
An alternative solution is to transform the meta-model to a type graph in which every node is labelled with all names of its superclasses. Furthermore, also all the associations a specific class, say A, has with other classes must be pushed down to all the subtypes of A. Essentially, this is the same as building the closure of the original meta-model, as proposed by Ehrig et al. [64]. The above inheritance structure then results in the type graph as shown in Fig. 4.6.
Figure 4.6: Pushing down node- and edge-inheritance in plain graphs.
Using this approach, the graphs become more complex and less elegant to visualize. This is not a major concern to us in this work for two reasons. On the one hand, we focus on the easy of specifying the semantics of a (programming) language and not so much on the shape of the actual models that reside on the different levels; on the other hand, the graphs of even small programs can already be fairly large, and, eventually, we are not really interested in visualizing the graphs but rather in the transition systems that arise from simulating a program.
4.5 Flat Abstract Syntax Graphs
Finally, the Groove Tool provides functionality of leaving out undesired labels in the visualization of the graphs without effecting the actual graphs on which the transformations are performed.
4.5.2
Ordered Associations
The second issue we discuss concerns the way we model ordered associations between syntax elements. We illustrate our approach by means of the artificial meta-model shown in Fig. 4.2.
B A
{ordered} -b
Figure 4.7: Modelling an ordered association in UML.
Modelling ordered associations in plain graph will be achieved by introducing a label set Labu2g which is disjoint with the set of labels Lab that is used in the graphs elsewhere, i.e. Labu2g ∩ Lab = ∅. The special labels used for modelling the ordered associations properly are orderFirst and orderNext. An orderFirst- edge will be pointing to the first element in the ordered list; any element itself will have an orderNext-edge referring to the next element in the list. The source element of the ordered association has an edge to all elements of the list labelled with the name of the association. Essentially, this all boils down to transforming the meta-model from Fig. 4.7 into the type graph shown in Fig. 4.8.
Figure 4.8: Modelling an ordered association in plain graphs.
The validity of this transformation depends on the fact that the association in Fig. 4.7 is a composition, which means that B-instances can only be associated with at most one A-instance at a time. If the association would be a regular association, we would need some additional graph elements that specify the origin of the ordered association.
Chapter 4. Semantics Through Graph Transformations
4.5.3
The Flower and Vase Example
In order to give an impression on how fasgs look like, Fig. 4.9 depicts the part of the fasg from the textual program from Listing 4.2 modelling the Flower type declaration with its color and length attributes.
Figure 4.9: FASG of the Flower type declaration.