Discussion

Edge-attribution. One of the limitations of our approach is that it does not sup- port edge attribution in a straightforward way, in contrast to the approach pro- posed by, for example, Ehrig et al. [65]. The Groove Tool Set has been set up as a lightweight and easy to use graph transformation tool mainly targeted towards the generation and verification of state spaces of systems specified through graph production systems. One of the fundamental choices in its design is that edges do not have identities. That is, edges are identified by means of their source node, label, and target node. In other work [22] we have shown that arbitrary graph structures can be translated to graph structures in which the edges of the original graph are represented by nodes having outgoing source and target edges, yielding equivalent results in terms of direct derivations. One could argue that edge-attribution is often applied as a technique to more elegantly model entities of the system under consideration, although without edge-attribution, the formalism is equally expressive.

Special Algebra Graphs. Our way of applying abstractions on uniform attributed graphs is by specifying so-called abstraction morphisms, which maps a specific algebra graph to another algebra graph such that the latter is less precise than the former. Using this approach, it is not possible to use abstraction domains in which concrete values are mapped to multiple abstract values, since such mappings cannot be specified as homomorphisms. An often used example is the partitioning of the integer domain as depicted in Fig. 3.26, where

• the value all represents all integers, i.e., all = Z, • pos = {n ∈ Z | n ≥ 0},

• neg = {n ∈ Z | n ≤ 0}, • spos = {n ∈ Z | n > 0}, • sneg = {n ∈ Z | n < 0},

Chapter 3. Uniform Attributed Graphs

all

pos neg

spos zero sneg

Figure 3.26: An example abstract integer domain.

The abstract value all generalizes all other abstract values, whereas the value neggeneralizes the values sneg and zero, and the value pos generalizes the val- ues spos, and zero. The algebra graph over this abstract domain cannot be obtained be any algebra graph morphism from the algebra graph representing the regular integer algebra. One could, however, specify the algebra graph over the above abstract domain by hand (since it is finite) and then perform graph transformations using that algebra graph.

Galois Connections. One can verify that our abstraction morphisms with cor- responding concretization morphisms actually specify Galois connections [48]. The elements of the abstract lattice are then sets of abstract graphs in which every set contains all attributed graphs over a fixed abstract algebra graph. However, as we are not interested in computing fixpoints of computations but rather in the transition relation among individual abstract graphs within the same set of abstract graphs, this does not provide useful theory in the current framework.

4

Semantics Through Graph Transformations

4.1

Introduction

Since the Unified Modeling Language (UML) [144] has been accepted as a stan- dard for modelling software program artifacts, it is applied in different phases of the software engineering process such as e.g. requirements engineering, and

system design. Until recently, the focus has mainly been on using UML models

for documentation-like purposes only. Using the UML in this way does not provide any means for combating the major problems of, e.g., maintenance and evolution. That is, UML itself does not facilitate automatic transformations between models at different levels of abstraction or their synchronization when introducing small or major modifications.

The introduction of the Model Driven Architecture (MDA) framework [143, 86, 118, 138] caused a paradigm shift, which made researchers develop new ap- proaches in which software artifacts were no longer only used for static purposes but rather as models being subject to transformations. Specific transformations might actually produce model or code that can be executed. In the MDA frame- work, models and model transformations are central concepts; the models are specified in diverse (modeling and programming) software languages (SLs), and the model transformations define relations between these languages. That is, a transformation specifies the transformation from a model in one language (of- ten called the source language) into a model in another language (the target language). By specifying the transformations at the level of the language (in contrast to the level of the models in that language), the transformation specifi-

Chapter 4. Semantics Through Graph Transformations

cation supports the transformation of any model in the source language. Model transformations are intended to be correctness preserving: they should not in- troduce errors or essential changes. This, however, can be guaranteed only if the meaning of the SLs involved is defined with sufficient precision. Unfortunately, this is often lacking: many SLs have a well-defined syntax but only an informal

semantics, e.g. described by text or, in the case of a programming language, by

a compiler.

On the longer-term, we aim at developing intuitive, though formal, ways in which all aspects of SLs, besides their concrete syntax, can be defined in a consistent and rigorous manner. As a common formal foundation we use graphs and graph transformations, which we believe to be powerful enough to capture all relevant SL aspects. Furthermore, the research that has been carried out in the field of graph transformations over the past four decades offers many theoretical results that can practically be applied in our context.

In this thesis we focus on the one hand on specifying the behaviour of systems by means of graph transformations and on the other hand on verifying the correctness of such systems. We have developed a small programming language called Taal including all ingredients to be truly object-oriented [197] such as classes, objects, inheritance, and methods. Alternatively, we could have taking an existing object-oriented programming language such as, e.g., Java [93]. The advantage of starting with a fresh small programming language is that we do not (yet) have to deal with more complex concepts such as exception handling and multi-threading. By extending the language with such features incrementally, we are able to investigate the effect on the semantics specification. One of the disadvantages is that we cannot directly apply our approach to moderate-sized systems written in existing programming languages like Java.

In our approach, states (or snapshots) of Taal programs are modelled as graphs. By specifying the execution semantics of Taal as graph transformation rules, we can simulate the execution of the program through performing graph transformations. Such simulations result in transition systems that contain paths representing all the possible executions of the program under simulation. Those transition systems can then be input to various analysis procedures. A particular kind of analysis is the application of verification methods such as

model checking. By verifying whether all (or some) execution paths of the pro-

gram satisfy particular properties, one obtains (more) insight in the (correctness of the) behaviour of the program.

In the context of MDA, one could be interested in whether a program (or model) in some programming (or modelling) language that is obtained by some transformation from another program (or model) in the same or, even more