[lecture notes in computer science] applications of graph transformations with industrial relevance...

Lecture Notes in Computer Science 7233Commenced Publication in 1973Founding and Former Series Editors:Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board

David HutchisonLancaster University, UK

Takeo KanadeCarnegie Mellon University, Pittsburgh, PA, USA

Josef KittlerUniversity of Surrey, Guildford, UK

Jon M. KleinbergCornell University, Ithaca, NY, USA

Alfred KobsaUniversity of California, Irvine, CA, USA

Friedemann MatternETH Zurich, Switzerland

John C. MitchellStanford University, CA, USA

Moni NaorWeizmann Institute of Science, Rehovot, Israel

Oscar NierstraszUniversity of Bern, Switzerland

C. Pandu RanganIndian Institute of Technology, Madras, India

Bernhard SteffenTU Dortmund University, Germany

Madhu SudanMicrosoft Research, Cambridge, MA, USA

Demetri TerzopoulosUniversity of California, Los Angeles, CA, USA

Doug TygarUniversity of California, Berkeley, CA, USA

Gerhard WeikumMax Planck Institute for Informatics, Saarbruecken, Germany

Andy Schürr Dániel VarróGergely Varró (Eds.)

Applications ofGraph Transformationswith Industrial Relevance4th International Symposium, AGTIVE 2011Budapest, Hungary, October 4-7, 2011Revised Selected and Invited Papers

13

Volume Editors

Andy SchürrTechnische Universität Darmstadt, Real-Time Systems LabMerckstraße 25, 64283 Darmstadt, GermanyE-mail: [email protected]

Dániel VarróBudapest University of Technology and EconomicsDepartment of Measurement and Information SystemsMagyar tudósok krt. 2, 1117 Budapest, HungaryE-mail: [email protected]

Gergely VarróTechnische Universität Darmstadt, Real-Time Systems LabMerckstraße 25, 64283 Darmstadt, GermanyE-mail: [email protected]

ISSN 0302-9743 e-ISSN 1611-3349ISBN 978-3-642-34175-5 e-ISBN 978-3-642-34176-2DOI 10.1007/978-3-642-34176-2Springer Heidelberg Dordrecht London New York

Library of Congress Control Number: 2012949456

CR Subject Classification (1998): G.2.2, E.1, D.2.1-2, D.2.4-5, D.2.11, F.2.2, F.3.1-2,F.4.2, I.2.8

LNCS Sublibrary: SL 2 – Programming and Software Engineering

© Springer-Verlag Berlin Heidelberg 2012This work is subject to copyright. All rights are reserved, whether the whole or part of the material isconcerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting,reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publicationor parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965,in its current version, and permission for use must always be obtained from Springer. Violations are liableto prosecution under the German Copyright Law.The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply,even in the absence of a specific statement, that such names are exempt from the relevant protective lawsand regulations and therefore free for general use.

Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India

Printed on acid-free paper

Springer is part of Springer Science+Business Media (www.springer.com)

Preface

This volume compiles all finally accepted papers presented at the 4th Inter-national Symposium on Applications of Graph Transformations with IndustrialRelevance (AGTIVE 2011), which took place in October 2011 in Budapest, Hun-gary. The submissions underwent a thorough, two-round review process bothbefore and after the symposium to enable the authors to carefully incorporatethe suggestions of reviewers.

AGTIVE 2011 was the fourth practice-oriented scientific meeting of the graphtransformation community. The aim of the AGTIVE series as a whole is to serveas a forum for all those scientists of the graph transformation community who areinvolved in the development of graph transformation tools and the application ofgraph transformation techniques usually in an industrial setting. In more detail,our intentions were to:

1. Bring the practice-oriented graph transformation community together2. Study and integrate different graph transformation approaches3. Build a bridge between academia and industry

The first AGTIVE symposium took place at Kerkrade, The Netherlands, in1999. Its proceedings appeared as vol. 1779 of the Springer LNCS series. Thesecond symposium was held in 2003 in Charlottesville, Virginia, USA. The pro-ceedings appeared as LNCS vol. 3062. The third symposium took place in Kassel,Germany, in 2007, while the proceedings were published as LNCS vol. 5088.

AGTIVE 2011 was hosted by Budapest, the capital of Hungary, which wasfounded in 1873 as the unification of the separate historic towns of Buda (theroyal capital since the fifteenth century), Pest (the cultural center), and Obuda(built on the ancient Roman settlement of Aquincum). The city is bisected bythe River Danube, which makes Budapest a natural geographical center and amajor international transport hub. Budapest has a rich and fascinating history,a vibrant cultural heritage, yet it has managed to maintain its magic and charm.It has also been called the City of Spas with a dozen thermal bath complexesserved by over a hundred natural thermal springs.

Thirty-six papers were submitted to AGTIVE 2011, which were evaluatedtwice by at least three reviewers. In all, 26 regular research papers, applica-tion reports, and tool demonstration papers were accepted in the first roundfor presentation at the symposium. These presentations covered a wide rangeof application areas such as model migration, software reengineering and con-figuration management, generation of test specifications, 3D reconstruction ofplant architectures, chemical engineering, reconfiguration of self-adaptive sys-tems, security aspects of embedded systems, and so forth. Furthermore, manycontributions proposed new graph transformation concepts and implementationtechniques needed to solve real-world problems in a scalable way.

VI Preface

In addition, two invited talks were presented at AGTIVE 2011 reporting onstate-of-the-art, industrial rule-based modeling techniques and applications forbusiness-critical applications.

– Zsolt Kocsis (IBM): “Best Practices to Model Business Services in ComplexIT Environments”

– Mark Proctor (Red Hat) : “Drools: A Rule Engine for Complex Event Pro-cessing”

In the second review round, the Program Committee selected 18 submissions(of which 13 full research, two application report, and three tool demonstrationpapers) for publication in the proceedings. Thus, the final acceptance rate was50%.

The AGTIVE 2011 Symposium was organized in strong collaboration be-tween the Department of Measurement and Information Systems and the De-partment of Automation and Applied Informatics at the Budapest University ofTechnology and Economics, and the Real-Time Systems Lab at the TechnicalUniversity Darmstadt. We would like to give special thanks to members of theorganizing team, namely, Gabor Bergmann, Abel Hegedus, Akos Horvath, LaszloLengyel, Gergely Mezei, Istvan Rath, Gabor Toth, and Zoltan Ujhelyi. We alsoacknowledge the additional financial support provided by the SecureChange andthe CERTIMOT projects, and the Alexander von Humboldt Foundation. Thereview process was administered by using the EasyChair conference managementsystem.

July 2012 Andy SchurrDaniel Varro

Gergely Varro

Organization

Program Co-chairs

Andy Schurr TU Darmstadt, GermanyDaniel Varro BME, HungaryGergely Varro TU Darmstadt, Germany

Organizing Committee

Gabor Bergmann Gergely MezeiAbel Hegedus Istvan RathAkos Horvath Gabor TothLaszlo Lengyel Zoltan Ujhelyi

Program Committee

Luciano Baresi University of Milan, ItalyBenoit Baudry INRIA, FrancePaolo Bottoni University of Rome La Sapienza, ItalyJordi Cabot INRIA, FranceKrzysztof Czarnecki University of Waterloo, CanadaJuan de Lara Universidad Autonoma de Madrid, SpainHartmut Ehrig Technical University of Berlin, GermanyGregor Engels University of Paderborn, GermanyNate Foster Cornell University, USAHolger Giese Hasso Plattner Institute, GermanyReiko Heckel University of Leicester, UKZhenjiang Hu National Institute of Informatics, JapanAudris Kalnins University of Latvia, LatviaGabor Karsai Vanderbilt University, USAEkkart Kindler Technical University of Denmark, DenmarkVinay Kulkarni Tata Consultancy Services, IndiaJochen Kuster IBM Research, SwitzerlandTihamer Levendovszky Vanderbilt University, USATom Mens University of Mons-Hainaut, BelgiumMark Minas Universitat der Bundeswehr Munchen,

GermanyManfred Nagl RWTH Aachen, GermanyRichard Paige University of York, UK

VIII Organization

Ivan Porres Abo Akademi University, FinlandArend Rensink University of Twente, The NetherlandsLeila Ribeiro University of Rio Grande do Sul, BrazilIngo Sturmer Model Engineering Solutions GmbH, GermanyGabriele Taentzer Philipps-Universitat Marburg, GermanyPieter Van Gorp Eindhoven University of Technology,

The NetherlandsBernhard Westfechtel University of Bayreuth, GermanyKang Zhang University of Texas at Dallas, USAAlbert Zundorf Kassel University, Germany

Additional Reviewers

Becker, BasilBranco, MoisesBruseke, FrankBuchmann, ThomasChrist, FabianDiskin, ZinovyDoberkat, Ernst-ErichGeiger, Nina

Hegedus, AbelHermann, FrankJanssens, DirkJubeh, RubenKoch, AndreasKrause, ChristianLambers, LeenMaier, Sonja

Marchand, JonathanMosbah, MohamedRutle, AdrianSyriani, EugeneUhrig, SabrinaWinetzhammer, Sabine

Sponsoring Institutions

Department of Measurement and Information Systems, BME, HungaryDepartment of Automation and Applied Informatics, BME, HungaryFachgebiet Echtzeitsysteme, Technische Universitat Darmstadt, GermanyAlexander von Humboldt Foundation, Germany

Table of Contents

Invited Talk Abstracts

Best Practices to Model Business Services in Complex ITEnvironments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Zsolt Kocsis

Drools: A Rule Engine for Complex Event Processing . . . . . . . . . . . . . . . . . 2Mark Proctor

Session 1: Model-Driven Engineering

Graph Transformation Concepts for Meta-model EvolutionGuaranteeing Permanent Type Conformance throughout ModelMigration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Florian Mantz, Stefan Jurack, and Gabriele Taentzer

A Graph Transformation-Based Semantics for Deep Metamodelling . . . . . 19Alessandro Rossini, Juan de Lara, Esther Guerra,Adrian Rutle, and Yngve Lamo

Reusable Graph Transformation Templates . . . . . . . . . . . . . . . . . . . . . . . . . . 35Juan de Lara and Esther Guerra

Session 2: Graph Transformation Applications

Towards an Automated 3D Reconstruction of Plant Architecture . . . . . . . 51Florian Scholer and Volker Steinhage

Generating Graph Transformation Rules from AML/GT State MachineDiagrams for Building Animated Model Editors . . . . . . . . . . . . . . . . . . . . . . 65

Torsten Strobl and Mark Minas

Session 3: Tool Demonstrations

AGG 2.0 – New Features for Specifying and Analyzing Algebraic GraphTransformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Olga Runge, Claudia Ermel, and Gabriele Taentzer

Integration of a Pattern-Based Layout Engine into Diagram Editors . . . . 89Sonja Maier and Mark Minas

X Table of Contents

Tool Demonstration of the Transformation Judge . . . . . . . . . . . . . . . . . . . . 97Steffen Mazanek, Christian Rutetzki, and Mark Minas

Session 4: Graph Transformation ExplorationTechniques

Knowledge-Based Graph Exploration Analysis . . . . . . . . . . . . . . . . . . . . . . . 105Ismenia Galvao, Eduardo Zambon, Arend Rensink,Lesley Wevers, and Mehmet Aksit

Graph Grammar Induction as a Parser-Controlled Heuristic SearchProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Luka Furst, Marjan Mernik, and Viljan Mahnic

Planning Self-adaption with Graph Transformations . . . . . . . . . . . . . . . . . . 137Matthias Tichy and Benjamin Klopper

Session 5: Graph Transformation Semanticsand Reasoning

From Graph Transformation Units via MiniSat to GrGen.NET . . . . . . . . 153Marcus Ermler, Hans-Jorg Kreowski, Sabine Kuske, andCaroline von Totth

Locality in Reasoning about Graph Transformations . . . . . . . . . . . . . . . . . . 169Martin Strecker

Contextual Hyperedge Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Frank Drewes, Berthold Hoffmann, and Mark Minas

Session 6: Application Reports

The Added Value of Programmed Graph Transformations – A CaseStudy from Software Configuration Management . . . . . . . . . . . . . . . . . . . . . 198

Thomas Buchmann, Bernhard Westfechtel, andSabine Winetzhammer

A Case Study Based Comparison of ATL and SDM . . . . . . . . . . . . . . . . . . 210Sven Patzina and Lars Patzina

Session 7: Bidirectional Transformations

Applying Advanced TGG Concepts for a Complex Transformation ofSequence Diagram Specifications to Timed Game Automata . . . . . . . . . . . 222

Joel Greenyer and Jan Rieke

Table of Contents XI

Automatic Conformance Testing of Optimized Triple Graph GrammarImplementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Stephan Hildebrandt, Leen Lambers, Holger Giese,Dominic Petrick, and Ingo Richter

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Best Practices to Model Business Services

in Complex IT Environments

Zsolt Kocsis

IBM Hungary

Abstract. Managing complex business services on top of IT solutionsis much more then managing solely the IT infrastructure beneath. Busi-ness services management requires the management of all resources andimplementation layers by knowing the business logic, and includes ser-vices relevant information from different business aspects. To achieve aneffective service modeling, the analysis must include resource models,connection models, error and error propagation models in a way thatthe models could be maintained to ensure long term business benefits.

This invited talk gives an insight of the business services modeling,a possible best practice to build such models in a complex, event basedfault management environment and shows the actual outcomes of a re-cent project at a leading telecommunication company.

A. Schurr, D. Varro, and G. Varro (Eds.): AGTIVE 2011, LNCS 7233, p. 1, 2012.c© Springer-Verlag Berlin Heidelberg 2012

Drools: A Rule Engine

for Complex Event Processing

Mark Proctor

Red Hat

Abstract. Drools is the leading Java based Open Source rule engine.It is a hybrid chaining engine meaning it can react to changes in dataand also provides advanced query capabilities. Drools provides built intemporal reasoning for complex event processing and is fully integratedwith the jBPM project for BPMN2 based workflow. Ongoing research in-cludes (but is not limited) to planning, ontological reasoning (semanticweb), imperfect reasoning, truth maintenance and distributed collabora-tion through intelligent agents.

This talk will provide an introduction into Drools what it is and howit works. We will explain the concepts of forward and backward chainingwithin the context of Drools as well as exploring the rule engine syntaxand how it has been extended for temporal reasoning for complex eventprocessing.

A. Schurr, D. Varro, and G. Varro (Eds.): AGTIVE 2011, LNCS 7233, p. 2, 2012.c© Springer-Verlag Berlin Heidelberg 2012

Graph Transformation Concepts for Meta-modelEvolution Guaranteeing Permanent Type Conformance

throughout Model Migration

Florian Mantz1,�, Stefan Jurack2, and Gabriele Taentzer2

1 Bergen University College, [email protected]

2 Philipps-Universitat Marburg, Germany{sjurack,taentzer}@mathematik.uni-marburg.de

Abstract. Meta-modeling has become the key technology to define domain-specific modeling languages for model-driven engineering. However, these mod-eling languages can change quite frequently which requires the evolution of theirmeta-models as well as the co-evolution (or migration) of their models. In thispaper, we present an approach towards meta-model model co-evolution based ongraph transformation concepts that targets to consider this challenge in a formalsetting. Models are specified as graphs while model relations, especially type-instance relations, are defined by graph morphisms specifying type conformanceof models to their meta-models. We present a basic approach to automatic deduc-tion of model migrations from meta-model evolution steps which are specifiedby single transformation rules. Throughout that migration process, type confor-mance is ensured permanently. A first implementation is given using existingtechnology, namely the Eclipse Modeling Framework (EMF) and the EMF modeltransformation tool Henshin which is based on graph transformation concepts.Our evolution approach is presented at two small evolution scenarios for Petrinets and state machines.

Keywords: meta-model evolution, model migration, Henshin, graph transforma-tion, Eclipse Modeling Framework.

1 Introduction

Model-driven engineering (MDE) is a software engineering discipline that uses modelsas main artifacts throughout software development processes, adopting model transfor-mation for code generation. Models in MDE describe application-specific system de-sign which is automatically translated into code. A commonly used technique to definemodeling languages is meta-modeling.

In contrast to traditional software development where programming languages donot change often, domain-specific modeling languages and therefore meta-models, canchange frequently: Modeling language elements are renamed, extended by additionalattributes, or refined by a hierarchy of sub-elements. The evolution of a meta-model

� This work was partially funded by NFR project 194521 (FORMGRID).

A. Schurr, D. Varro, and G. Varro (Eds.): AGTIVE 2011, LNCS 7233, pp. 3–18, 2012.c© Springer-Verlag Berlin Heidelberg 2012

4 F. Mantz, S. Jurack, and G. Taentzer

requires the consistent migration of its models and is therefore a considerable researchchallenge in MDE (see Fig. 1).

Work in this direction already exists and several approaches have been developedto face this problem. Approaches use out-place and in-place transformation strategieswhich either create new migrated models like in [13] or change models in-place as in[6]. Most migration approaches are out-place. Out-place transformations have to trans-late all model parts, i.e., also those which do not change. In contrast, in-place trans-formations consider those model parts only that are affected by meta-model changesand can also support incremental migrations of large models. To the best of our knowl-edge, existing approaches do not ensure the permanent type conformance for in-placemodel migration processes. In general, existing approaches can be classified into thefollowing categories: A model migration strategy is specified manually using a (spe-cialized) model transformation language like in [13]. We consider a model migration tobe change-based, i.e., if a difference model of two meta-model versions is calculated, anevolution rule is deduced and a migration definition like the one in [3] is automaticallyderived. Model migration is defined to be operator-based, if a set of coupled changestrategies for meta-model evolution and model migration are provided to perform re-curring adaptations like in [6].

�

�

�

�

Meta-modelevolution ��

�

�

�

�

Meta-model′

�

�

�

�

Model

conforms to

��

migration ��

�

�

�

Model′

conforms to

��

��

Fig. 1. Meta-model evolution and model migration

In this paper we explain how graph transformation concepts can be applied to meta-model evolution and model migration. Since graph transformations are in-place trans-formations, we migrate model parts only if they are affected by meta-model changes.In addition, we face the challenge of keeping models permanently type conformant tothe evolving meta-model. We focus on an approach that is promising to formalize meta-model evolution with model migration while providing a prototypical implementation.The goal is to gain witness about completeness and correctness of model migrationdefinitions before their application. Therefore we start with basic migration scenarioswhich will become more complex in the future. In addition, we develop an automaticderivation strategy for migration rules that does not rely on default migration opera-tions. In our approach, we consider an in-place approach which uses an intermediatemeta-model allowing the incremental transformation of large models. Using this mi-gration strategy, models may also consist of many diagrams conforming to differentmeta-model versions. For example, consider a large UML 1.4 model consisting of manydiagrams shared by several modelers. While some modelers are still working on theirUML 1.4 diagrams others may already migrate their diagrams to a newer version ofUML.

Graph Transformation Concepts for Meta-model Evolution 5

In this paper, models are consistently migrated using in-place transformations and acommon meta-model. In contrast to our earlier work in [7], this coupled change oper-ation can be generated from a simpler specification now, not only for one specific casebut for a certain set of meta-model evolutions. Although there are several restrictionsto evolution cases, the approach is already useful in various cases. Up to now, we studymeta-model evolution steps which can be specified by single transformation rules with-out additional application conditions. Our migration strategy generates a migration rulerM on the model level which is isomorphic to rule rI evolving a corresponding meta-model. Rule rM corresponds to rule rI replacing each typing element in rule rI by acorresponding instance element.

We realize our approach based on the Eclipse Modeling Framework (EMF) [5], amodeling framework widely used in practice. Ecore, the core language of EMF, com-plies with Essential MOF (EMOF) being part of OMG’s Meta Object Facility (MOF)2.0 specification [10]. The model transformation tool chosen to implement our ap-proach is called Henshin [14]. It implements algebraic graph transformation concepts[4] adapted to EMF models and specifies its transformation systems as EMF modelsthemselves. Henshin contains a control concept for rule applications called transfor-mation units and furthermore, a Java(Script)-based computation engine for attributes.Since Henshin can be applied to any EMF model, we use it on two modeling levels: (1)to specify meta-model evolution rules and (2) to define a generator for migration rules.

This paper is structured as follows: In Section 2 we introduce our approach at arunning example. In Sections 3 and 4, we explain the specification and derivation ofmeta-model evolution rules respectively model migration rules. Afterwards we discussthe implementation with EMF and Henshin in Section 5. Finally, in Sections 6 and 7,we consider related work and conclude our work.

2 Motivating Example

To motivate our approach, we consider two small evolution scenarios on Petri netsand state machines based on simple EMF-models (see Fig. 2). The essential part ofthe Ecore model is presented in Row 1 of Fig. 2. Its main elements are EClassand EReference. EReferences specify directed relations and their multiplicities.Furthermore they can be defined as containment references. For model storage, it isimportant that an EMF model forms a containment tree. For now, we neglect con-tainment relationships here, but take them up again for the implementation. In addi-tion, EClasses can have EAttributes typed over EDatatypes. Note that meta-references eStructuralFeatures and eType appear in the model twice, due toits flat presentation. In the original Ecore model, these meta-references are inheritedfrom a common super class. Note also that EClass and EReference are objects inthis “meta-meta-model”. The Ecore model itself is recursively typed and EClass andEReference are both typed by EClass themselves.

Rows 2 and 4 of the example (Fig. 2) show meta-models in meta-model syntax.These meta-models are instances of our simplified Ecore meta-meta-model. Row 2shows an evolution of a Petri net meta-model while Row 4 shows different versions ofa state machine meta-model. Container classes are not shown due to space limitations.


However, it is always assumed that each model contains a root object with containmentreferences to all other objects. The typing of meta-model elements is given by its syntax.Arrows are typed by EReference, nodes by EClass, attributes by EAttributeand data types by EDatatype.

Rows 3 and 5 of the example (Fig. 2) show instance models of the Petri net andstate machine meta-models. The instance model typing is also given by its syntax. Forexample, place symbols in cell A3 are typed by EClass “Place” in cell A2. Note thatthe direction of incoming arrows in the Petri net meta-model in cell A2 does not corre-spond to the direction of their instance elements in cell A3. This is not a mistake but themeta-modeler’s decision how to define the meta-model syntax of models. Examples ofinstance models in meta-model syntax are given in Fig. 3 which shows cells A3 and B3of Fig. 2.

Rows 2 and 4 in Fig. 2 show two similar evolutions steps on two different meta-models. Rows 3 and 5 show their migrated models which may include additional valuesentered by the modeler. Cell A3 shows a simple Petri net which models a synchronouscommunication between “Alice” and “Bob”. Cell B3 shows an extended version of themodel. Weights at outgoing arrows are added allowing to express that “Alice” producesmore messages than “Bob” during the communication. However, before the modelercan specify these weights it is required to evolve the meta-model and migrate the model.Afterwards he can change the default values. The outgoing arrow has to be specified asEClass in the meta-model since classes only can contain EAttributes. After re-placing reference “outArr” by EClass “OutArr” and two additional references, anEAttribute “weight” for the weight at outgoing arrows can be added. If the mod-eler wants to use colored tokens in addition, the meta-model has to be evolved again.It is shown in cell C2 a meta-model with an additional attribute “color”, a correspond-ingly migrated model in cell C3. The modeler transforms the EAttribute “token”of EClass “Place” into an own EClass where EAttribute “color” can be added.The old EAttribute “token” becomes the new EAttribute “count” in EClass“Token” which is connected by a new EReference with multiplicity 1:1.

All model migrations required should be implemented in a rule-based manner be-cause a meta-model may have many instances which have to be migrated. It may also bean advantage to encode the meta-model evolution steps as rules. The evolution changesshown are quite general as we can see when we inspect the changes made to the statemachine metamodel in Row 4 in Fig. 2. First, its instance models are extended by la-beled transitions, then more information to actions is added such as the priority attribute“prio”. Hence, we think that it is promising to encode meta-model evolution steps asreusable, parametrized transformation rules, applicable to any meta-model (see Figs. 4and 5). Mappings are shown by numbers. Input parameter names start with “Var”. Fur-thermore string manipulation functions can be used in rules. The rule in Fig. 4 replacesan EReference by an EClass linked by two EReferences. In addition, the newEClass gets an new EAttribute which is specified by the modeler applying thisrule. The purpose of this evolution step is to prepare the meta-model for attributed linksin the model.


0..1

eType

0..*

eStructural-

Features

0..1

eType

EReference

name: EString

lower: Int

upper: Int

EClass

name: EString

typed

Ecore

meta-meta

model

PetriNet

meta-models

1..1

beginOutArr

1..*

inArr

endOutArr

token

1..1

Transition

name: EString

Place

name: EString

OutArr

weight:EInt=1

Token

count: EInt

color:EString="grey"

1..1 beginOutArr

1..*

inArr

1..1

endOutArr

Transition

name: EString

Place

name: EString

token: EInt

OutArr

weight:EInt=1

1..*

inArr

Transition

name: EString

Place

name: EString

token: EInt

1..*

outArr

Send Message

to Bob

Send Message

to Alice

Alice

Bob

Send Message

to Bob

Send Message

to Alice

Alice

Bob

1

1

Send Message

to Bob

Send Message

to Alice

Alice

Bob

1

1

PetriNet

models

typed

typed

typed

AB

C

1 2 3

Running

doWork()

Ready

Blocked

Ready

Blocked

waiting

for input

input

entered

schedule

preemptRunning

doWork()

Ready

Blockedwaiting

for input

input

entered

schedule

preemptRunning

doWork()

with Prio 1

typed

typed

typed

Statemachine

models

5

1..1 beginTransition

1..1 endTransition

State

name: EString

action: EString

Transition

name: EString=""


1..1 endTransition

State

name: EString

Transition

name: EString=""

Statemachine

meta-models

ER2

MR2

MR2

ER2

4

Action

do: EString

prio: EInt=1

1..1 action

EDatatype

name: EString

ER1

MR1

MR1

ER1

EAttribute

name: EString

defaultValueLiteral: EString

0..*

eStructuralFeatures

1..1


1..1 endTransition

State

name: EString

action: EString

Transition

Fig

.2.M

eta-

mod

elev

olut

ion

and

mod

elm

igra

tion


A B

PetriNetM1-models

3:Place

name="Alice"

token=1

:Transition

name="Send Message To Alice"

:Transition

name: "Send Message To Bob"

:inArr

:inArr

:OutArr

weight=1

:OutArr

weight=1

:Place

name="Bob"

token=0

:begin-

OutArr

:endOutArr

:endOutArr

:begin-

OutArr

:Place

name="Alice"

token=1

:Transition


:Transition

name="Send Message To Bob"

:inArr

:inArr

:outArr

:outArr

:Place

name="Bob"

token=0

Fig. 3. Models in meta-model syntax

The rule application for the first change in cell A2 of our motivating example has thefollowing arguments: VarSrcNodeName="Transition",VarArrName="out-Arr", VarAttr="weight", VarType="EInt" and VarAttrDefault="1".The rule in Fig. 5 creates an EClass associated to an existing one. This new EClassgets the name of a former EAttribute. To store its value a new attribute is created inthis new EClass choosing a new name. Furthermore an additional new EAttribute“VarAttr2” is added to this new EClass as in the first rule. The purpose of this evolu-tion step is to encapsulate several attributes in a separate class.

LHS 1

2

1..1

"end"+format(VarArrName)

"begin"+format(VarArrName)

1..1

function format(String s){return

s.charAt(0).toUpperCase() + s.substring(1)}

format(VarArrName)

VarAttr: VarType=VarAttrDefault

RHS

1@VarSrcNodeName 2VarArrName

Fig. 4. Meta-model evolution Rule “EReference2EClass” for replacing an EReference by anEClass. In addition the new EClass contains a new EAttribute and is linked by twoEReferences.

1@VarSrcNodeName

VarAttr1:Type1

LHS1

1..1

varAttr1

format(VarAttr1)

VarAttr1New: Type1

VarAttr2: VarType2=VarAttr2Default

RHS

function format(String s){return

s.charAt(0).toUpperCase() + s.substring(1)}

Fig. 5. Meta-model evolution Rule “EAttribute2AssociatedEClass” for replacing an attribute byan associated EClass containing the EAttribute renamed.


3 Meta-model Evolution

Since we want to use in-place transformations to perform the migration task we cannotapply the meta-model evolution rules directly. A direct application would destroy thetyping morphisms as soon as we delete some of its elements. Hence, we have to dometa-model evolution and model migration in the following three steps (see Fig. 6):(1) extend the meta-model, (2) migrate all instance models, and (3) remove elementsto be deleted from the meta-model. Following this process we can migrate models us-ing an intermediate meta-model. The main advantage of this migration process is thepermanent type conformance of instance models throughout their migration.

Extend metamodel MM

to MMi

Migrate models comforming to

metamodel MMi

Reducemetamodel MM

to MM'i

Fig. 6. Meta-model evolution, model migration process

To apply this process to meta-model evolution rules such as the ones in Figs. 4 and 5,we provide a transformation system (see Fig. 7) that generate the necessary artifactsfor us. The transformation system derive the required meta-model evolution rules (toextend respectively restrict the metamodel) as well as model migration rule. This rulederivation is explained in the next sections.

Transformation system for model migrationMetamodel evolution rule for deletion

Metamodel evolution rule for creation

Metamodel evolution ruleGenerator

transformation systemIN OUT

Fig. 7. Meta-model evolution rules

As mentioned before, meta-model evolution rules such as presented in Fig. 4 andFig. 5 are not directly applied to evolve a meta-model in an in-place transformationapproach. Rules like these two are called input rules since we use them to generate newrules to perform our migration approach.

As an example, a direct rule application of an input rule called “EReference2EClass”is illustrated in Fig. 8 in the usual meta-model syntax, while Fig. 9 shows this ruleapplication in meta-meta-model syntax.

Since in our approach, rules follow algebraic graph transformation concepts, theycan be formalized by using the well-known DPO-approach to graph transformation [4].In [2], the theory (including node type inheritance) is enhanced with containment struc-tures and constraints to capture all main EMF concepts. An abstract presentation ofan input rule called rI and its application is shown in Fig. 10. Models are specifiedby graphs and the type conformance of models to their meta-models is formalized bygraph homomorphisms between instance and type graphs.


1..1 beginOutArr

1..* inArr

1..1 endOutArr

Transitionname: EString

Placename: EStringtoken: EInt

OutArrweight:EInt=1

1..* inArrTransition

name: EString

Placename: EStringtoken: EInt

1..*outArr

EReference

2

EClass

M2 M2'

Fig. 8. Example meta-model evolution step: Before and after an application of Rule “ERefer-ence2EClass” in meta-model syntax

EReference 2 EClass

:EClassname="Transition"

:EAttributename="name"

eStructural-Features

:EDatatypename="EString"

eType

:EClassname="Place"



:EDatatypename="EInt"

eType

:EAttributename="token"


:EReferencename="inArr"upper=1lower=*


eTypeeType

:EReferencename="outArr"upper=1lower=*


eType

M2

:EClassname="Transition"



:EDatatypename="EString"

eType

:EClassname="Place"



:EDatatypename="EInt"

eType

:EAttributename="token"


:EReferencename="inArr"upper=1lower=*


eTypeeType

:EAttributename="weight"defaultValueLiteral="1"

eType

:EClassname="OutArr"

:EReferencename="beginOutArr"upper=1lower=1

:EReferencename="endOutArr"upper=1lower=1



eType

eType


M2'

Fig. 9. Example meta-model evolution step: Before and after an application of Rule “ERefer-ence2EClass” in meta-meta-model syntax

As first step in our new approach, we split up rule rI into two rules called rC and rDsuch that [[rI ]] = [[rC ]], [[rD]] = [[rC , rD]] where [[rI ]] is the set of all possible applicationsof rule rI . An illustration of this rule splitting is given in Fig. 11. Numbers in roundbrackets indicate the rule application order. Rule rC creates elements only and rulerD deletes elements only. Between the applications of these two rules we perform the


M3

LM2

��

rI ��

��

RM2

��

M2

��

[[rI ]] �� M2′

Fig. 10. Input rule rI

migration transformation system which is considered in the next section. The LHS ofrule rC is equal to the LHS of rule rI . The RHS of rule rC as well as the LHS of rulerD correspond to LHS ∪ RHS of rule rI . The RHS of rule rD is equal to the RHS ofrule rI .

M3

LM2

��

rC ��

��

IM2

��

rD ��

��

RM2

��

��

M2

��

(1)[[rC ]] �� M2I(2)[[rD]] ��

M2′

��

Fig. 11. Meta-model evolution rules

There are two general restrictions: Firstly, all changes must be expressible by “add”and “delete” operations i. e. an explicit move operation is not possible. This restrictionis caused by the nature of graph transformation. Secondly, an intermediate meta-modelcontaining all elements of the initial and revised meta-model must be constructible. Thismay not always be the case due to constraints of the meta-meta-model. For example,a meta-modeling language may prohibit multiple containers for the same object. How-ever, multiple containment references may be required in the intermediate meta-modelif the modeler wants to move an element from one container to another.

An example application of rules rC and rD is illustrated in the upper part of Fig. 13for the concrete input rule “EReference2EClass”. The application of rule rC adds basi-cally the structure EReference “beginOutArr”, EClass “OutArr”, EReference“endOutArr” to meta-model M2. The application of rule rD deletes EReference“outArr” from the intermediate meta-model M2I .

4 Model Migration

Models have to be migrated in a sensible way and may be done in more than one mean-ingful way. Hence often, this task cannot be fully automatized. For this reasons we start


in this first version of our new approach with meta-model evolution rules that allowa sensible unique derivation of migration rules. The aim is to relax the restrictions onmeta-model evolution rules in the future by enhancing their definition with additionalinformation that guide the rule derivation process to other cases. Given a meta-modelevolution rule as input, our current strategy is to generate one isomorphic model migra-tion rule called rM by replacing each type element t of rule rI with an instance elementof type t.

Fig. 12 shows the relation between meta-model evolution and model migration rulesas well as their applications in a formal manner. The top of Fig. 12 shows the meta-model evolution rules rC and rD introduced in the previous section. Between theirapplication, we execute the model migration rule rM as often as possible. Rule rC trans-forms type graph M2 into an intermediate type graph M2I . An instance graph M1 isalso type conformant to type graph M2I since M2 is included. Then, instance graphM1 is changed to instance graph M1′ by rule rM . Rule rM adds and deletes instanceelements according to the input rule rI . Afterwards, rule rD is applied transformingtype graph M2I into the final type graph M2′. Instance graph M1′ will also conformto this type graph since instances of types deleted by rule rD have already been deletedby rule rM before.

LM2

��

rC �� IM2

��

rD �� RM2

��

M2(1)[[rC ]] �� M2I

(n+1)[[rD]] �� M2′

LM1

��

rM ��

��

��

RM1

��

��

��

M1(2..n)[[rM ]] ��

��

M1′

��

Fig. 12. Model migration transformation system

Currently, our deduction strategy for migration rules can be applied if meta-modelevolution rules match graph parts only that cannot be varied on the instance level. For-bidden patterns are those that allow variance as e.g., loops and classes that are targetof more than one reference. Whether a meta-model evolution rule belongs this classof rules can be checked in advance by analysing the meta-model evolution rule andconstraints on the meta-model.

An example meta-model evolution with model migration by rule rC , rM and rDis illustrated in Fig. 13. The process starts with applying rule rC to meta-model M2yielding M2I . After this rule application, model M1 is still type conformant sincenothing has been deleted in its meta-model M2I . Then, the migration of model M1follows by applying the derived rule rM shown in Fig. 14 as often as possible. Finally


the process ends with the application of rule rD which deletes meta-model elementsthat are not used in the migrated model M1′ anymore since they have been replaced byother elements in the migration step before. Hence model M1′ is still type conformant.Note that rule rM shown in Fig. 14 is presented in meta-model syntax. The typing isexpressed using the usual “:”-notation. Compare also Fig. 14 with Fig. 4 to see that thestructural parts of both rules are isomorphic. Note furthermore that the migration rulerM does not require any variables anymore. The newly created EAttribute “weight”is initialized with the default value “1”. However, the second meta-model evolutionRule “EAttribute2AssociatedEClass” requires an input parameter to transfer attributevalues.

1..1 beginOutArr

1..*

inArr

1..1

endOutArr

Transition

name: EStringPlace

name: EString

token: EInt

OutArr

weight:EInt=1

r Dr C

1..*

inArrTransition

name: EString

Place

name: EString

token: EInt1..*

outArr

M2 M2'

1..1 begin-

OutArr1..1

endOutArr

Transition

name: EStringPlace

name: EString

token: EInt

1..*

inArr

OutArr

weight:EInt=1

1..*

outArr

M2I

:Place

name="Alice"

token=1

:Transition


:Transition

name: "Send Message To Bob"

:inArr

:inArr

:OutArr

weight=1

:OutArr

weight=1

:Place

name="Bob"

token=0

:begin-

OutArr

:endOutArr

:endOutArr

:begin-

OutArr

:Place

name="Alice"

token=1

:Transition


:Transition

name="Send Message To Bob"

:inArr

:inArr

:outArr

:outArr

:Place

name="Bob"

token=0

M1 M1'typedtyped typed

r M r A , r D = EReference 2 EClass

typed

r I

Fig. 13. Example meta-model evolution with model migration

1:Transition 2:Place:OutArr

LHS 1

2

:OutArrweight=1

:endOutArr

:beginOutArrRHS

Fig. 14. Derived model migration rule for meta-model evolution Rule “EReference2EClass”


5 Implementation by Henshin Model Transformations

The prototypical implementation1 is realized by Henshin model transformations. Hen-shin input rules are transformed to applicable meta-model evolution and model migra-tion rules by use of higher-order transformations also specified with Henshin. Beforewe discuss the implementation realisation, we consider its current limitations:

1. The number of meta-model elements i.e., classes, references and attributes, to bedeleted by the evolution rule is maximal one. This restriction is given only by thecurrent implementation.

2. Newly created package elements have to be created within the context of the deletedpackage element, i.e., in the same package. This restriction is due to the handlingof containment relationships in our implementation.

3. The intermediate meta-model might lead to an invalid Ecore instance not fulfill-ing all constraints. For this reason the restriction is by now that the intermediatemeta-model must be constructible. For example, in the intermediate meta-modelafter application of Rule “EAttribute2AssociatedEClass”, an EClass requires anEAttribute and an EReference with the same name. However, this is notpossible in EMF because of an implicit naming constraint. This problem can besolved by two subsequent evolution steps replacing an attribute by a reference witha new name first and renaming it to the original name afterwards.

4. Attribute values cannot yet be transfered, since evolution rules do not provide aspecification mechanism for such value transfers yet. At the moment, the migrationrule generator is restricted to the deletion of attributes from the meta-model: Bysetting an attribute value to null it is changed to its default value, which is notstored in the model.

5.1 Specification of Input Rules

Input rules are normal Ecore rules obeying the restrictions given above. In our imple-mentation, Rule “EReference2EClass” in Fig. 4 can be specified straight forward. Acontainment relationship of the newly created EClass has to be specified in addition.

Rule “EAttribute2Associated EClass” in Fig. 5 can be specified in a restricted formonly. The value transfer of attribute “VarAttr1” cannot be specified, as already dis-cussed. However, a specification mechanism for attribute value transfers is imaginable.In addition, we have to deal with another restriction: The name of the EReference tobe create shall be specified by the name of an EAttribute. The intermediate meta-model would require that EClass “1” in the figure contains an EAttribute and anEReference with the same name. However, this is not possible in EMF. By now, wesolve this problem by choosing another name for the EReference to create in a firststep and adding a second step doing a renaming.

5.2 Derivation of Meta-model Evolution Rule

Our approach contains a model transformation system which creates two rules fromscratch by the following coarse-grained algorithm: (1) Two rules rC and rD are created

1 http://www.mathematik.uni-marburg.de/˜swt/agtive-mm-evolution/

http://www.mathematik.uni-marburg.de/~swt/agtive-mm-evolution/


as copies of rule rI . This is done by coping all elements, i.e., objects, links, mappingsand parameters. (2) The RHS of rule rC and the LHS of rule rD are extended to LHSI∪RHSI .

5.3 Derivation of Model Migration Rules

A model migration rule should perform corresponding actions on the model level as rulerI does on the meta-model level. Therefore the creation of a migration rule is requiredresembling rule rI adapted to the model level: Type elements of rule rI have to be re-placed by corresponding instance elements. Note that in EMF this translation is not thatstraight forward. Rule rI is formulated in the meta-meta-model syntax, while rule rMis specified in meta-model syntax: eReferences are objects in the meta-meta-modelsyntax and have to be translated into references in the meta-model syntax. CompareFig. 3 with Fig. 9 to see which structures are mapped to each other. Fig. 9 shows a ruleapplication of Rule “EReference2EClass” in meta-meta-model syntax. Fig. 3 shows amodel in meta-model syntax before and after the meta-model change in Fig. 9. Fur-thermore, while the creation of an EAttribute does not need to be considered on themodel level its deletion has to be treated in a special way: These attributes have to be setto null in the model as mentioned before (see Alg. 1). Newly created attributes existimplicitly in each model. Their default values can be specified in their meta-model. Themove of attributes is not implemented yet. In addition, the creation of rule rM requiresthat the elements of rule rI can be used as types in migration rule rM . Therefore weneed an intermediate step: We generate a rule which generates the migration rule rMfor a specific meta-model. With this trick we can refer to the elements of rule rI as typesin this “generator generator” rule. However, we think that Henshin would profit from afeature supporting this step. In addition, the execution logic for applying migration rulerM as often as possible has to be implemented with Henshin. This is done by gener-ating not only the migration rule but a transformation system containing the migrationrule and additional elements steering the rule application. If the evolution rule does cre-ations only, the corresponding migration rule is applied exactly once. This procedure isformulated in the coarse-grained Algorithm 1 below.

5.4 Performance

The performance of this prototypical tool implementation is acceptable although theremight be potentials for improvements. The derivation of one migration rule such as theone in Fig. 14 needs around 18 seconds on a standard laptop with an Intel(R) Core(TM)2Duo CPU @ 2.40 GHz. The time spent to derive a migration rule was independentfrom the meta-model size in our test case: We applied rule “EReference2Class” to thePetri net and the State machine meta-models as well as to the Ecore meta-model. Theperformance of model migrations depend only on the used model transformation tool.We tested the derived model migration Rule “EReference2EClass” (see Fig. 14) withPetriNet models of different sizes. For a large PetriNet model with 1000 places and 1000transitions where each one has one in and out arrow, our prototypical implementationneeds around 240 seconds to complete the migration.


Algorithm 1. Calculate model migrator(Rule rI ) := TransformationSystem1: TransformationSystem s := new HenshinTransformationSystem()2: Rule rM :=s.add(newRule())3: List E := All elements of LHSMM and RHSMM in rule rI4: for each element e in E do5: if e not instance of Attribute then6: Translate element e into its instance element i in rM .7: if i instance of Node then8: Create a containment reference for i.9: Map corresponding instance node elements in LHSM and RHSM .

10: else11: // i instance of Edge:12: Link the corresponding instance node elements in LHSM resp. RHSM .13: end if14: else15: if e is deleted by rule rI /*Exist only in RHSM*/ then16: // Delete attribute value in EMF instance:17: Translate element e into e = null in RHSM .18: else19: Do nothing. // New attributes exist implicitly in EMF models20: end if21: end if22: end for23: if rule rM is not deleting then24: Embed rule rM in s with a transformation unit calling rule rM once.25: else26: Embed rule rM in s with transformation unit calling rule rM as often as possible.27: end if28: return s

6 Related Work

Co-evolution of structures has been considered in several areas of computer sciencesuch as database schemata, grammars, and meta-models. Especially schema evolutionhas been a subject of research in the last decades. Recently, research activities havestarted to consider meta-model evolution and to investigate the transfer of schema evo-lution concepts to meta-model evolution. For further details we refer to Hermanns-dorfer [6]. In the following, we focus our comparison on in-place and out-placeapproaches for meta-model evolution being presented in the literature.

In [13], Sprinkle et al. introduce a visual graph transformation-based language formeta-model evolution. The language uses out-place transformations and copies modelelements automatically if their meta-model elements have not been changed. In con-trast, an in-place approach does not need automatic copying of non-changed elementssince a model can be changed directly.

In [9], Narayanan et al. introduce the Model Change Language (MCL) which mainlyfollows the work of [13]. Transformations are specified in a graph transformation basedmanner. The resulting model is checked for type conformance.


In [3], Cicchetti et al. present an changed-based approach. A difference model isautomatically computed that acts as input for a higher-order transformation, producinga migration transformation. ATL [1] rules are generated. Helper classes are used tospecify the transformation behavior.

Rose et al. in [12] introduce an automatic coping approach that uses an elaboratedcopy strategy. They present the text-based model migration language Epsilon Flock thatcan be used not only to copy unchanged model parts automatically but also those thatpass a less strict conformance check. The idea is that a strict equivalence is often notrequired e.g., an integer object can be copied into a long object automatically. In addi-tion, Epsilon Flock provides an abstraction mechanism to deal with different modelingframeworks.

In [6], the authors present a meta-model evolution approach called COPE that usesin-place transformations. A general difficulty of in-place transformations is that mod-els and meta-models need to be changed in a coordinated manner as shown above, toguarantee a permanent conformance of models with their meta-model. However, COPEdecouples models and meta-models during transformation and therefore cannot guaran-tee type conformance during model migration. Conformance is checked at runtime. Atransaction concept comparable to the transaction concept in database systems is usedto prevent models to get corrupted.

In [11] several tools for meta-model evolution are compared, namely: AtlanModMatching Language (AML), Ecore2Ecore, COPE, Epsilon Flock. Except COPE, alltools in [11] use out-place transformations. AML is build on top of ATL and imple-ments model matching strategies which execute a set of heuristics. Ecore2Ecore uses amapping model to describe mappings between two Ecore models. Migration is specifiedby the use of this model and hand-written Java code.

In [8], Meyers et al. also suggest to use existing in-place transformation languagesfor model migration. Their approach mainly bases on the earlier work of Cicchetti et. al.in [3] but uses in-place transformations. It starts with a given set of difference modelsrepresented by a sequence of method calls that reflect a change in the meta-model and amodel migration strategy. During the migration each model should stay conform to anintermediate meta-model as in our approach, however in their example implementation,they rely on COPE procedures.

7 Conclusion and Future Work

In this paper, an rule-based approach to meta-model evolution and model migrationis presented using in-place model transformation based on graph transformation con-cepts. The approach is illustrated at two example evolutions of Petri net and statemachine models showing that specific migration rules can be derived for different meta-models. The implementation is realized using existing technology, namely EMF and theEMF model transformation tool Henshin. Although our currently implemented migra-tion strategy has a number of limitations, a variety of evolution case can be handledalready now. In the future, the strategy for automatic deduction of migration rules hasto be further elaborated to cover a larger set of meta-model evolution scenarios elim-inating existing limitations step-by-step. Our intention is to develop the formal basis


along with the elaboration of new strategies. The formalization of this work helps us togain witness about the completeness and correctness of model migration.

References

1. Atlas Transformation Language: User Guide, http://wiki.eclipse.org/ATL/User_Guide

2. Biermann, E., Ermel, C., Taentzer, G.: Precise Semantics of EMF Model Transformations byGraph Transformation. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., Volter, M. (eds.)MODELS 2008. LNCS, vol. 5301, pp. 53–67. Springer, Heidelberg (2008)

3. Cicchetti, A., Di Ruscio, D., Eramo, R., Pierantonio, A.: Automating co-evolution in model-driven engineering. In: Proc. of the 12th International IEEE Enterprise Distributed ObjectComputing Conference, pp. 222–231. IEEE Computer Society (2008)

4. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals of Algebraic Graph Transfor-mation. Monographs in Theoretical Computer Science. An EATCS Series. Springer (2006)

5. EMF: Eclipse Modeling Framework (2010), http://www.eclipse.com/emf6. Herrmannsdoerfer, M., Benz, S., Juergens, E.: COPE - Automating Coupled Evolution of

Metamodels and Models. In: Drossopoulou, S. (ed.) ECOOP 2009. LNCS, vol. 5653, pp.52–76. Springer, Heidelberg (2009)

7. Jurack, S., Mantz, F.: Towards metamodel evolution of EMF models with Henshin. Tech.rep., ME 2010: International Workshop on Model Evolution at MoDELS 2010 (WorkshopOnline Proceedings) (2010), http://www.modse.fr

8. Meyers, B., Wimmer, M., Cicchetti, A., Sprinkle, J.: A generic in-place transformation-basedapproach to structured model co-evolution. In: Amaral, V., Vangheluwe, H., Hardebolle, C.,Lengyel, L. (eds.) Workshop on Multi-Paradigm Modeling 2010. ECEASST, vol. 42 (2011)

9. Narayanan, A., Levendovszky, T., Balasubramanian, D., Karsai, G.: Automatic DomainModel Migration to Manage Metamodel Evolution. In: Schurr, A., Selic, B. (eds.)MODELS 2009. LNCS, vol. 5795, pp. 706–711. Springer, Heidelberg (2009)

10. OMG: Meta-Object Facility 2.0. (2010), http://www.omg.org/spec/MOF/2.0/11. Rose, L.M., Herrmannsdoerfer, M., Williams, J.R., Kolovos, D.S., Garces, K., Paige, R.F.,

Polack, F.A.C.: A Comparison of Model Migration Tools. In: Petriu, D.C., Rouquette, N.,Haugen, Ø. (eds.) MODELS 2010, Part I. LNCS, vol. 6394, pp. 61–75. Springer, Heidelberg(2010)

12. Rose, L.M., Kolovos, D.S., Paige, R.F., Polack, F.A.C.: Model Migration with Epsilon Flock.In: Tratt, L., Gogolla, M. (eds.) ICMT 2010. LNCS, vol. 6142, pp. 184–198. Springer, Hei-delberg (2010)

13. Sprinkle, J., Karsai, G.: A domain-specific visual language for domain model evolution. Jour-nal of Visual Languages and Computing 15(3-4) (2004)

14. The EMF Henshin Transformation Tool: Project Web Site, http://www.eclipse.org/modeling/emft/henshin/

http://wiki.eclipse.org/ATL/User_Guide

http://wiki.eclipse.org/ATL/User_Guide

http://www.eclipse.com/emf

http://www.modse.fr

http://www.omg.org/spec/MOF/2.0/

http://www.eclipse.org/modeling/emft/henshin/

http://www.eclipse.org/modeling/emft/henshin/

A Graph Transformation-Based Semanticsfor Deep Metamodelling

Alessandro Rossini1, Juan de Lara2, Esther Guerra2, Adrian Rutle3, and Yngve Lamo3

1 University of Bergen, [email protected]

2 Universidad Autónoma de Madrid, Spain{Juan.deLara,Esther.Guerra}@uam.es

3 Bergen University College, Norway{aru,yla}@hib.no

Abstract. Metamodelling is one of the pillars of model-driven engineering, usedfor language engineering and domain modelling. Even though metamodelling istraditionally based on a two-level approach, several researchers have pointed outlimitations of this solution and proposed an alternative deep (also called multi-level) approach to obtain simpler system descriptions. However, deep metamod-elling currently lacks a formalisation that can be used to explain fundamental con-cepts such as deep characterisation through potency and double linguistic/onto-logical typing. This paper provides different semantics for such fundamental con-cepts based on graph transformation and the Diagram Predicate Framework.

1 Introduction

Model-driven engineering (MDE) promotes the use of models as the primary assets insoftware development, where they are used to specify, simulate, generate and main-tain software systems. Models can be specified using general-purpose languages likeUML, but to fully unfold the potential of MDE, models are specified using domain-specific languages (DSLs) which are tailored to a specific domain of concern. One wayto define DSLs in MDE is by specifying metamodels, which are models that describethe concepts and define the syntax of a DSL.

The OMG has proposed MOF as the standard language to specify metamodels, andsome popular implementations exist, most notably the Eclipse Modeling Framework(EMF) [21]. In this approach, a system is specified using models at two metalevels:a metamodel defining allowed types and a model instantiating these types. However,this approach may have limitations [4,5,13], in particular when the metamodel includesthe type-object pattern [4,5,13], which requires an explicit modelling of types and theirinstances at the same metalevel. In this case, deep metamodelling (also called multi-level metamodelling) using more than two metalevels yields simpler models [5].

Deep metamodelling was proposed in the seminal works of Atkinson and Kühne [4],and several researchers and tools have subsequently adopted this approach [1,2,16].However, there is still a lack of formalisation of the main concepts of deep metamod-elling like deep characterisation through potency and double linguistic/ontological typ-ing. Such a formalisation is needed in order to explain the main aspects of the approach,

A. Schürr, D. Varró, and G. Varró (Eds.): AGTIVE 2011, LNCS 7233, pp. 19–34, 2012.c© Springer-Verlag Berlin Heidelberg 2012

20 A. Rossini et al.

study the different semantic variation points and their consequences, as well as to clas-sify the different semantics found in the tools implementing them [1,2,3,16,15].

In this paper, we present a formal approach to deep metamodelling based on theDiagram Predicate Framework (DPF) [19,20], a diagrammatic specification frameworkfounded on category theory and graph transformation. DPF has been adopted up to nowto formalise several concepts in MDE, such as (MOF-based) metamodelling, modeltransformation and model versioning. The proposed formalisation helps in reasoningabout the different semantic variation points in the realisation of deep metamodellingas well as in classifying the existing tools according to these options.

Paper Organisation. Section 2 introduces deep metamodelling through an example inthe domain of component-based web applications. Section 3 presents the basic conceptsof DPF. Section 4 explains different concepts of deep metamodelling through its form-alisation in DPF. Section 5 compares with related research, and Section 6 concludes.

2 Deep Metamodelling

This section introduces deep metamodelling through an example, illustrating the lim-itations of two metalevels when defining DSLs which incorporate the type-object pat-tern [4,5,13]. Moreover, it discusses some open questions that are tackled in this paper.

2.1 Overview of Deep Metamodelling

The MeTEOriC project aims at the model-driven engineering of web applications. Herewe describe a small excerpt of one of the modelling problems encountered in this pro-ject. A full description of this case study is outside the scope of this paper, but is de-scribed at: http://astreo.ii.uam.es/~jlara/metaDepth/Collab.html.

In MeTEOriC, a DSL is adopted to define the mash-up of components (like GoogleMaps and Google Fusion Tables) to provide the functionality of a web application. Asimplified version of this language can be defined using two metalevels (see Fig. 1(a)).The metamodel corresponds to the DSL for component-based web applications. In thismetamodel, the metaclass Component defines component types having a type identifier,whereas the metaclass CInstance defines component instances having a variable nameand a flag indicating whether it should be visualised. Moreover, the metaassociationtype defines the typing of each component instance. The model at the adjacent meta-level below represents a component-based web application which shows the positionof professors’ offices on a map. In this model, the classes Map and Table are instancesof the metaclass Component and represent component types, whereas the classes UAM-Camp and UAMProfs are instances of the metaclass CInstance and represent componentinstances of Map and Table, respectively.

The type-object relation between component types and instances is represented ex-plicitly in the metamodel by the metaassociation type between the metaclasses Com-ponent and CInstance. However, the type-object relation between allowed and actualdata links is implicit since there is no explicit relation between the metaassociationsdatalink and dlinstance, and this may lead to several problems. Firstly, it is not pos-sible to define that the data link instance offices is typed by the data link type geopos,

http://astreo.ii.uam.es/~jlara/metaDepth/Collab.html

A Graph Transformation-Based Semantics for Deep Metamodelling 21

ModelMetamodel

name="UAMCampus"visualise=true

UAMCampcamptype

id="GoogleMaps"

Map

trg

o ces

src

trg

geopos

src name="UAMProfs"visualise=false

UAMProfsprofstype

id="FusionTable"

Table

name: Stringvisualise: Boolean

CInstance src*

dlinstance

*trg

*type1id: String

Componenttrg*

datalink

src*

(a)

Model M3

Model M2

Model M1

name="UAMProfs"visualise=false

UAMProfs

srctrgo cesname="UAMCampus"

visualise=true

UAMCamp

id="FusionTable"

Table

srctrg0..1geopos*

id="GoogleMaps"

Map

@2@2

@1id: Stringname: Stringvisualise: Boolean

@2Component src*

@2datalink

*trgcontext Componentinv: self.trg-> excludes(self)

@2

(b)

Fig. 1. A simple language for component systems in two and three metalevels

which could be particularly ambiguous if the model contained multiple data link typesbetween the component types Map and Table. Moreover, it could be possible to specifya reflexive data link instance from the component instance UAMProfs to itself, whichshould not be allowed since the component type Table does not have any reflexive datalink type. Although these errors could be detected by complementing the metamodelwith attached OCL constraints, these constraints are not enough to guide the correctinstantiation of each data link, in the same way as a built-in type system would do ifthe data link types and instances belonged to two different metalevels. In the completedefinition of the DSL, the component types can define features, such as the zoomingcapabilities of the map component. Again, these features would be represented usingthe type-object pattern with metaclasses Feature (associated to Component) and Fea-tureInstance (associated to CInstance). These metaclasses need to be correctly instanti-ated and associated to the component instances, which leads to complex constraints andeven more cluttered models. Hence, either one builds manually the needed machinery toemulate two metalevels within the same one, or this two-metalevel solution eventuallybecomes convoluted and hardly usable.

The DSL above can be defined in a simpler way using three metalevels (Fig. 1(b))and deep characterisation, i.e., the ability to describe structure and express constraintsfor metalevels below the adjacent one. In this work, we adopt the deep characterisationapproach described in [4], where each model element has a potency. In the originalproposal of [4], the potency is a natural number which is attached to a model element todescribe at how many subsequent metalevels this element can be instantiated. Moreover,the potency decreases in one unit at each instantiation at a deeper metalevel. When itreaches zero, a pure instance that cannot be instantiated further is obtained. In Section 4,we provide a more precise definition for potency.

In deep metamodelling, the elements in the top metalevel are pure types, the ele-ments in the bottom metalevel are pure instances, and the elements at intermediatemetalevels retain both a type and an instance facet. Because of that, they are all calledclabjects, which is the merge of the words class and object [5]. Moreover, since in deepmetamodelling the number of metalevels may change depending on the requirements,


we find it more convenient to number the metalevels from 1 onwards starting from thetop-most. The model M1 contains the definition of the DSL (Fig. 1(b)). In this model,clabject Component has potency 2, denoting that it can be instantiated at the two sub-sequent metalevels. Its attribute id has potency 1, denoting that it can be assigned avalue when Component is instantiated at the adjacent metalevel below. Its other two at-tributes name and visualise have potency 2, denoting that they can be assigned a valueonly two metalevels below. The association datalink also has potency 2, denoting thatit can be instantiated at the two subsequent metalevels. The attached OCL constraintin the model M1 forbids to reflexively connect indirect instances of Component. Thisconstraint has potency 2, denoting that it has to be evaluated in the model M3 only. Aselements in M2 retain a type facet, we can add cardinality constraints to geopos, whilethis would need to be emulated in Fig. 1(a). The DSL in Fig. 1(b) is simpler than theone in Fig. 1(a), as it contains less model elements to define the same DSL.

The deep characterisation is very useful in the design of this DSL. For instance, inthe model M1, the designer can specify the attributes name and visualise which shouldbe assigned a value in indirect instances of Component, i.e., UAMCamp and UAMProfs.Moreover, the model M1 does not need to include a clabject CInstance or an associationdlinstance since the clabjects UAMCamp and UAMProfs are instances of the clabjectsMap and Table, respectively, which in turn are instances of the clabject Component.

The dashed grey arrows in Fig. 1(b) denote the ontological typing for the clabjects,as they represent instantiations within a domain; e.g., the clabjects Map and Tableare ontologically typed by the clabject Component. In addition, deep metamodellingframeworks usually support an orthogonal linguistic typing [5,16] which refers to themetamodel of the metamodelling language used to specify the models; e.g., the clab-jects Component, Map and UAMCamp are linguistically typed by Clabject, whereas theattributes id, name and visualise are linguistically typed by Attribute.

2.2 Some Open Questions in Deep MetamodellingDeep metamodelling allows a more flexible approach to metamodelling by introducingricher modelling mechanisms. However, their semantics have to be precisely defined inorder to obtain sound, robust models. Even if the literature (and this section) permitsgrasping an intuition of how these modelling mechanisms work, there are still openquestions which require clarification.

Some works in the literature give different semantics to the potency of associations.In Fig. 1(b), the associations are instantiated like clabjects. In this case, the associationdatalink with potency 2 in the model M1 is first instantiated as the association geoposwith potency 1 in the model M2, and then instantiated as the association offices withpotency 0 in the model M3; i.e., the instantiation of offices is mediated by geopos. Incontrast, the attributes name and visualise with potency 2 in the model M1 are assigneda value directly in the model M3; i.e., the instantiation of name and visualise is not me-diated. Some frameworks such as EMF [21] represent associations as Java references,so the associations could also be instantiated like attributes. In this case, the associ-ation datalink would not need to be instantiated in the model M2 in order to be able toinstantiate it in the model M3. This would have the effect that one could add an associ-ation between any two component instances in the model M3, not necessarily betweeninstances of Table and instances of Map.


Another ambiguity concerns constraints, since some works in the literature supportpotency on constraints [16] but others do not [3]. In Fig. 1(b), the attached OCL con-straint in the model M1 is evaluated in the model M3 only. In other cases, it might beuseful to have a potency which denotes that a constraint has to be evaluated at everymetalevel. In addition, it is feasible to attach potencies to multiplicity constraints aswell. In Fig. 1(b), all the multiplicity constraints are evaluated at the adjacent metalevelbelow. In other cases, it might be useful to attach a potency to multiplicity constraints.For instance, a potency 2 would have the effect that one could control the number ofdata link instances in the model M3.

Finally, another research question concerns the relation between metamodelling stackswith and without deep characterisation. One could define constructions to flatten deepcharacterisation; e.g., given the three-metalevel stack of Fig. 1(b), one could obtain an-other three-metalevel stack without potencies but with some elements replicated alongmetalevels, making explicit the semantics of potency. This would allow the migrationof deeply characterised systems into tools that do not support potency.

Altogether, we observe a lack of consensus and precise semantics for some of theaspects of deep metamodelling. The contribution of this work is the use of DPF toprovide a neat semantics for different aspects of deep metamodelling: deep character-isation through potency and double linguistic/ontological typing. As a distinguishingnote, we propose two possible semantics of potency for each model element, i.e., clab-jects, attributes, associations and constraints. To the best of our knowledge, this is thefirst time that the two semantics have been recognised.

3 Diagram Predicate Framework

This section presents the basic concepts of DPF that are used in the formalisation ofdeep metamodelling. The interested reader can consult [9,8,10,18,19,17,20] for a moredetailed presentation of the framework.

In DPF, a model is represented by a specification S. A specification S = (S,CS :Σ) consists of an underlying graph S together with a set of atomic constraints CS

which are specified by means of a predicate signature Σ. A predicate signature Σ =(ΠΣ , αΣ) consists of a collection of predicates π ∈ ΠΣ , each having an arity (or shapegraph) αΣ(π). An atomic constraint (π, δ) consists of a predicate π ∈ ΠΣ togetherwith a graph homomorphism δ : αΣ(π) → S from the arity of the predicate to theunderlying graph of a specification.

Fig. 2 shows a specification T which is compliant with the requirements “a compon-ent must have exactly one identifier”, “a component may be connected to other com-ponents” and “a component can not be connected to itself”. In T, these requirements are

enforced by the atomic constraints ([mult(1, 1)], δ1 : (1a−→ 2) → (Component

id−→String)) and ([irreflexive], δ2 : (1

a−→ 1)→ (Componentdatalink−−−−→ Component)).

Similar to E-graphs [11], attributes of nodes can be represented in DPF by edges fromthese nodes to nodes representing data types. For example, the attribute id:String of the

clabject Component in Fig. 1(b) is represented in DPF by an edge Componentid−→ String

(see Fig. 2).


The semantics of graph nodes and arrows has to be chosen in a suitable way forthe corresponding modelling environment [20]. In object-oriented structural modelling,each object may be related to a set of other objects. Hence, it is appropriate to interpret

nodes as sets and arrows Xf−→ Y as multi-valued functions f : X → ℘(Y ).

The semantics of predicates of the signature Σ (see Fig 2) is described using themathematical language of set theory. In an implementation, the semantics of a predicateis typically given by the code of a corresponding validator such that the mathematicaland the validator semantics should coincide. A semantic interpretation [[..]]Σ of a signa-ture Σ consists of a mapping that assigns to each predicate symbol π ∈ ΠΣ a set [[π]]Σ

of graph homomorphisms ι : O → αΣ(π), called valid instances of π, where O mayvary over all graphs. [[π]]Σ is assumed to be closed under isomorphisms.

The semantics of a specification is defined in the fibred way [8,10]; i.e., the semanticsof a specification S = (S,CS :Σ) is given by the set of its instances (I, ι). To checkthat an atomic constraint is satisfied in a given instance of a specification S, it is enoughto inspect only the part of S which is affected by the atomic constraint. This kind ofrestriction to a subpart is obtained by the pullback construction [6]. An instance (I, ι)of a specification S consists of a graph I and a graph homomorphism ι : I → S suchthat for each atomic constraint (π, δ) ∈ CS we have ι∗ ∈ [[π]]Σ , where the graphhomomorphism ι∗ : O∗ → αΣ(π) is given by the following pullback:

αΣ(π)δ

S

O∗

P.B.

δ∗

ι∗

I

ι

In DPF, two kinds of conformance relations are distinguished: typed by and conformsto. A specification S is typed by a graph T if there exists a graph homomorphism ι :S → T, called the typing morphism, between the underlying graph of the specificationS and T. A specification S is said to conform to a specification T if there exists atyping morphism ι : S → T between the underlying graphs of S and T such that (S, ι)is a valid instance of T; i.e., such that ι satisfies the atomic constraints CT .

Fig. 2 shows two specifications S and S′, both typed by T. However, only S con-forms to T, since S′ violates the atomic constraints CT . This is because the missingid-typed edge violates the multiplicity constraint ([mult(1, 1)], δ1), while the edgesource violates the irreflexivity constraint ([irreflexive], δ2).

π ∈ ΠΣ αΣ(π) Proposed vis. Semantic interpretation

[irreflexive] 1a

Xf

∀x ∈ X : x /∈ f(x)

[mult(m, n)] 1 a 2 X f Y ∀x ∈ X : m ≤ |f(x)| ≤ n,with 0 ≤ m ≤ n and n ≥ 1

[irr]

[m..n]

S'S

Σ

T

Plotsource“GoogleMaps”

idMapMap

String[1..1]idComponentdatalink[irr]

Fig. 2. A signature Σ and specifications T, S and S′, where only S conforms to T


4 Formalisation of Deep Metamodelling

This section formalises different concepts of deep metamodelling through DPF. Firstly,we introduce different interpretations of potency. Secondly, we define the syntax of po-tency in terms of DPF. Thirdly, we define models in a deep stack together with doublelinguistic/ontological typing in terms of DPF. Finally, we present an operational se-mantics of potency in terms of constraint-aware graph transformation.

4.1 Multi- and Single-Potency

As discussed in Section 2.2, different interpretations of potency are possible. In this pa-per, two kinds of potency are distinguished, namely multi- and single-potency, denotedby the superscripts �p and�p, respectively.

A multi-potency �p on a clabject/reference at metalevel i denotes that this clab-ject/reference can be instantiated at all metalevels from i + 1 to i + p (see Fig. 3). Apotency �p on an atomic constraint at metalevel i denotes that this constraint is eval-uated at all metalevels from i + 1 to i + p. Note that attributes only retain either typeor instance facet but not both, therefore the multi-potency on attributes can not be con-sidered. This “multi-” semantics is the usual semantics of potency on clabjects found inthe literature.

Metalevel Clabject Reference

i A�p Aa�p

N

i+ 1 B�p-1 Bb�p-1

O

......

......

...

i+ p− 1 L�1 Ll�1

Y

i+ p M�0 Mm�0

Z

Fig. 3. Intuition on the multi-semantics of potency

In contrast, a single-potency�p on a clabject/reference at metalevel i denotes thatthis clabject/reference can be instantiated at metalevel i+p only, but not at the interme-diate metalevels (see Fig. 4). A potency�p on an attribute at metalevel i denotes thatthis attribute can be instantiated (i.e., can be assigned a value) at metalevel i + p only.A potency�p on an atomic constraint at metalevel i denotes that this atomic constraintis evaluated at metalevel i+ p only.


Metalevel Clabject Reference Attribute

i A�p Aa�p

N Aa�p

DT

......

......

......

......

i+ p B�0 Mb�0

Z Mb�0

DV

Fig. 4. Intuition on the single- semantics of potency

4.2 Syntax of Potency

The syntax of multi- and single-potencies can be represented in DPF by a tag signature,which has the same components of a predicate signature but a different semantic coun-terpart (see Section 4.3 and 4.4). A tag signature Ψ = (ΘΨ , αΨ) consists of a collectionof tags θ ∈ ΘΨ , each having an arity αΨ(θ) and a proposed visualisation. Table 1 showsthe tag signature Ψ for specifying potencies.

Table 1. The tag signature Ψ for specifying potencies

θ ∈ ΘΨ αΨ(θ) Proposed visual.

<multi(p)>1 1 X�p

<multi(p)>21

a2 X

f�p

Y

<multi(p)>π1

a2 X

f

π�pY

θ ∈ ΘΨ αΨ(θ) Proposed visual.

<single(p)>1 1 X�p

<single(p)>2 1a

2 Xf�p

Y

<single(p)>π1

a2 X

f

π�pY

The tags θ ∈ ΘΨ are divided into two families <multi(p)> and <single(p)> formulti- and single-potency, respectively. They are parametrised by the (non-negative)integer p, which represents the potency value that is attached to an element. Morespecifically, the tags <multi(p)>1 and <single(p)>1 are used for attaching poten-cies to clabjects, <multi(p)>2 and <single(p)>2 for references and attributes, and<multi(p)>π and <single(p)>π for atomic constraints (with compatible arity).

Given the tag signature Ψ, a potency (θ, γ) consists of a tag θ ∈ ΘΨ and a graphhomomorphism γ : αΨ(θ)→ Si. Note that potencies can only be attached to clabjects,references, attributes and atomic constraints. This restriction can be defined by adoptingtyped tag signatures in which each tag is typed linguistically by a specification. Thisdetail is omitted in this paper for brevity.

In the following, we adopt potencies to define models in a deep stack.

4.3 Double Linguistic/Ontological Typing

A model at metalevel i in a deep stack can be represented in DPF by a (deep) spe-cification Si. A specification (Si, λi, ωi) = (Si, Ci : Σ,Pi : Ψ, λi, ωi) consists of an


underlying graph Si, a set of atomic constraints Ci specified by means of a predicatesignature Σ and a set of potencies Pi specified by means of a tag signature Ψ (seeFig. 5). Moreover, Si conforms linguistically to the specification LM; i.e., there existsa linguistic typing morphism λi : Si → LM such that (Si, λi) is a valid instance ofLM. The specification LM corresponds to the metamodelling language used to specifyall specifications in a deep stack. Furthermore, Si conforms ontologically to the spe-cification Si−1; i.e., there exists an ontological typing morphism ωi : Si → Si−1 suchthat (Si, ωi) is a valid instance of Si−1 and the ontological typing is compatible withthe linguistic typing, i.e., ωi;λi−1 = λi.

LM Si−1

λi−1

ΣCi−1

Ci

Si

ωiλi

=

ΨPi

Pi−1

Fig. 5. Double linguistic/ontological typing

A specification S1 at the top metalevel 1 of a deep stack is a special case as itselements are pure types (see Section 2). As such, S1 conforms only linguistically tothe specification LM; i.e., there is no specification S0, hence, there is no ontologicaltyping morphism ω1 : S1 → S0.

Example 1 (Deep Stack). Building on the example in Section 2, Fig. 6(a) shows thespecification LM while Figs. 6(b), (c) and (d) show the specifications S1, S2 and S3

of a deep stack corresponding to a simplified version of the one in Fig. 1(b). The figurealso shows the ontological typings as dashed, grey arrows.

In S1 the potency �2 on Component and datalink is specified by (<multi(2)>1

, γ1 : 1 → Component) and (<multi(2)>2, γ2 : (1a−→ 2) → (Component

datalink−−−−→Component)), respectively. Similarly, the potencies �1 on id and ([mult(1, 1)], δ1)are specified by (<single(1)>2, γ3) and (<single(1)>2, γ4; δ1), respectively.

The specifications S1, S2 and S3 conform linguistically to LM; i.e., there existlinguistic typing morphisms λ1 : S1 → LM , λ2 : S2 → LM and λ3 : S3 → LMsuch that (S1, λ1), (S2, λ2) and (S3, λ3) are valid instances of LM. For instance, λ2 isdefined as follows:

λ2(Map) = λ2(Table) = Clabjectλ2(geopos) = Referenceλ2(idMap) = λ2(idTable) = Attributeλ2(“GoogleMaps”) = λ2(“FusionTable”) = DataType

Moreover, S2 conforms ontologically to S1; i.e., there exists an ontological typingmorphism ω2 : S2 → S1 such that (S2, ω2) is a valid instance of S1:

ω2(Map) = ω2(Table) = Componentω2(geopos) = datalinkω2(idMap) = ω2(idTable) = idω2(“GoogleMaps”) = ω2(“FusionTable”) = String


S3(d)

S2(c)

S1(b)

LM(a)

“UAMProfs”

nameTableUAM 0UAMProfs

0

o ces 0

“UAMCampus”

nameMapUAM 0UAMCamp

0

“FusionTable”

idTable 0Table

1

geopos 1

“GoogleMaps”

idMap 0Map

1

String[1..1] 2name 2

[1..1] 1id 1Component

2

[irr] 2datalink 2

[0..1] 2

DataType

Attribute

Clabject

Reference

Fig. 6. The specifications LM , S1, S2 and S3

Finally, S3 should conform ontologically to S2, but this is not the case as the ontolo-gical typing morphism ω3 is undefined for some elements of S3:

ω3(UAMCamp) = Mapω3(UAMProfs) = Tableω3(offices) = geoposω3(nameMapUAM)=ω3(nameTableUAM)=ω3(“UAMCampus”)=ω3(“UAMProfs”)=∅

In the following, we adopt constraint-aware graph transformation to define an opera-tional semantics of single-potency and obtain a specification S3 which conforms onto-logically to S2.

4.4 Semantics of Potency through Graph Transformation

Recall that a single-potency �p on a type at metalevel i denotes that this type can beinstantiated at metalevel i + p only. Hence, there are always p metalevels between aninstance with potency 0 and its type. However, in strict metamodelling, an instance withpotency 0 at metalevel i + p should be ontologically typed by a type with potency 1 atmetalevel i + p − 1. To address this problem we define a semantics of single-potencywhich transforms a deep stack into a flattened stack without deep characterisation, inwhich an instance with potency 0 at metalevel i+p has its type at metalevel i+p−1. Thistransformation adds to each metalevel i + 1 a replica of a type with potency decreasedto p− 1 and then deletes from metalevel i the original type, until p = 1. We specify thistransformation with constraint-aware transformation rules [11].

A transformation rule t = L Kl r

R consists of three specifications L,K and R. L and R are the left-hand side (LHS) and right-hand side (RHS) of thetransformation rule, respectively, while K is their interface. L \K describes the part of a


specification which is to be deleted, R\K describes the part to be added andK describesthe part to be preserved by the rule. Roughly speaking, an application of transformationrule means finding a match of the left-hand side L in a source specification S andreplacing L by R, leading to a target specification S′.

Since the transformation a specification undergoes is dependent of the potencies inthe specification at the metalevel above, the transformation rules take as input and out-put coupled specifications. A coupled specification CSi = ((Si, λi, ωi), (Si+1, λi+1))consists of a specification (Si, λi, ωi) coupled with the specification (Si+1, λi+1). Thismeans that the application of transformation rules modifies specifications at two adja-cent metalevels i and i+ 1.

Table 2 shows some of the transformation rules which define the operational se-mantics of single-potency. In general, all these rules follow a general pattern whichadds to metalevel i + 1 a replica of an element with single-potency decreased to p− 1and then deletes from metalevel i the original element; i.e.:

– Rules tc0 and tdt0: add to metalevel i+ 1 a replica of a clabject/data type.– Rules tr1 and ta1: add to metalevel i+ 1 a replica of a reference/attribute.– Rules tacr2 and taca2: add to metalevel i+ 1 a replica of an atomic constraint.– Rules tacr3 and taca3: delete from metalevel i the original atomic constraint.– Rules tr4 and ta4: delete from metalevel i the original reference/attribute.– Rule tc5: deletes from metalevel i the original clabject.

Note that the rules tc0, tc5, taca2 and taca3 are analogous to the rules tr1, tr4, tacr2and tacr3, respectively, and are omitted from Table 2 for brevity.

The transformation uses negative application conditions (NACs) and layers [11] tocontrol rule application. Since non-deleting rules can be applied multiple times via thesame match, each rule has a NAC equal to its RHS. Moreover, since the rules are to beapplied only if the matched potency is greater than 1, rules have another NAC demand-ing p ≤ 1. The subscripts from 0 to 4 denote the layer to which a rule belongs, so thatrules of layer 0 are applied as long as possible before rules of layer 1, etc.

According to this layering, the transformation adds a replica of a reference only afterit adds a replica of a clabject and before it deletes the original clabject. This ensures thatthe rule which adds a replica of a reference matches both clabjects with multi-potencyand their instances as well as clabjects with single-potency and their replicas. Moreover,this ensures that the replica of the reference has as source and target an instance ofthe considered clabject with multi-potency or a replica of the considered clabject withsingle-potency. The layering of rules for data types, attributes and atomic constraintsfollow the same rationale.

Note that the notation A:Clabjecta:Attribute

DT:DataType in the rules denotes thatλi(A) = Clabject, λi(a) = Attribute and λi(DT) = DataType.

Example 2 (Deep Stack and Application of Transformation Rules). Building onExample 1, Figs. 7(b), (c) and (d) show the specifications S1, S2 and S3 of the deepstack, after the application of the transformation rules. In particular, the added elementsare shown in Fig. 7(c) in green colour while the deleted elements are shown in Fig. 7(b)in red colour.


Table 2. The transformation rules for flattening the semantics of single-potencies

CL = CK CR = NAC

tdt0 A:Clabjecta:Attribute�p

DT:DataType

B:Clabject

ωLi

DT:DataType

A:Clabjecta:Attribute�p

DT:DataType

B:Clabject

ωRi

DT:DataType

ωRi

ta1 A:Clabjecta:Attribute�p

DT:DataType

B:Clabject

ωLi

DT:DataType

ωLi

A:Clabjecta:Attribute�p

DT:DataType

B:Clabject

ωRi

aB:Attribute�p-1

DT:DataType

ωRi

ωRi

tr1 A:Clabjecta:Reference�p

N:Clabject

B:Clabject

ωLi

O:Clabject

ωLi

A:Clabjecta:Reference�p

N:Clabject

B:Clabject

ωRi

aB:Reference�p-1

O:Clabject

ωRi

ωRi

tacr2 A:Clabjecta:Reference

π�p

N:Clabject

B:Clabject

ωLi

aB:ReferenceO:Clabject

ωLiωL

i

A:Clabjecta:Reference

π�p

N:Clabject

B:Clabject

ωRi

aB:Reference

π�p-1

O:Clabject

ωRiωR

i

CL CK = CR

tacr3 A:Clabjecta:Reference

π�p

N:Clabject

B:Clabject

ωLi

aB:Reference

π�p-1

O:Clabject

ωLiωL

i

A:Clabjecta:Reference

N:Clabject

B:Clabject

ωRi

aB:Reference

π�p-1

O:Clabject

ωRiωR

i

tr4 A:Clabjecta:Reference�p

N:Clabject

B:Clabject

ωLi

aB:Reference�p-1

O:Clabject

ωLi

ωLi

A:Clabject N:Clabject

B:Clabject

ωRi

aB:Reference�p-1

O:Clabject

ωRi

ta4 A:Clabjecta:Attribute�p

DT:DataType

B:Clabject

ωLi

aB:Attribute�p-1

DT:DataType

ωLi

ωLi

A:Clabject DT:DataType

B:Clabject

ωRi

aB:Attribute�p-1

DT:DataType

ωRi


S3(d)

S2(c)

S1(b)

LM(a)

“UAMProfs”

nameTableUAM 0UAMProfs

0

o ces 0

“UAMCampus”

nameMapUAM 0UAMCamp

0

“FusionTable”

idTable 0Table

1

geopos 1

“GoogleMaps”

idMap 0Map

1

++nameTable 1++[1..1

]1

++[0..1] 1

++nameMap 1++[1..1] 1

++String

String--[1..1] 2--name 2

[1..1] 1id 1Component

2

[irr] 2datalink 2

--[0..1] 2

DataType

Attribute

Clabject

Reference

Fig. 7. The specifications S1, S2 and S3, after applying the rules

Firstly, the application of tdt0 and ta1 adds to S2 the node String and the edgesnameMap and nameTable with potency�1. In this way, the ontological typing morph-ism ω3 can be defined for all the elements of S3, which makes S3 conform ontologic-ally to S2:

ω3(nameMapUAM) = nameMapω3(nameTableUAM) = nameTableω3(“UAMCampus”) = ω3(“UAMProfs”) = String

Secondly, the application of tacr2 and taca2 adds to S2 the atomic constraints([mult(0, 1)], δ1), ([mult(1, 1)], δ2) and ([mult(1, 1)], δ3) with potency �1 onthe edges geopos, nameMap and nameTable, respectively. In this way, these atomicconstraints are evaluated at metalevel 0.

Thirdly, the application of tacr3 and taca3 deletes from S1 the atomic constraints([mult(0, 1)], δ1) and ([mult(1, 1)], δ3) on the edges datalink and name, respect-ively. In this way, these atomic constraints are not evaluated at metalevel 1.

Finally, the application of taca4 deletes from S1 the edge name. In this way, it isnot possible to instantiate name at metalevel 1.

The presented flattening gives the semantics of potencies, so that an equivalent multi-level system is obtained, but without using deep characterisation. However, one canapply further flattenings using graph transformation, as shown in Fig. 8:

1. First, one can remove the double linguistic/ontological typing, keeping just one typ-ing. This can be done by adding the linguistic metamodel on top of the ontologicalstack, and replicating such metamodel elements at all metalevels except 0 and 1.

2. Second, one can flatten a multi-level system into two metalevels. The first variantof this flattening is to merge all models of the ontological stack into a single model,and then consider this merged model as an instance of the linguistic metamodel.


Two-level systemwith ontological on top

Two-level systemwith linguistic on top

Multi-level system

Multi-level systemwith dual typing

Deeply characterisedmulti-level systemwith dual typing

Fig. 8. Flattenings for multi-level systems

The second variant is to merge all models of the ontological stack, except the top-most one, into a single model, and then consider this merged model as an instanceof the top-most model. In this variant, given a system like the one in Fig. 1(b), onewould obtain a two-level system like the one in Fig. 1(a).

5 Related Work

A first strand of research focuses on multi-level metamodelling. In [12], MOF is ex-tended with multiple metalevels to enable XML-based code generation. Nivel [2] isa double metamodelling framework based on the weighted constraint rule language(WCRL). XMF [7] is a language-driven development framework allowing an arbit-rary number of metalevels. Another form of multi-level metamodelling can be achievedthrough powertypes [13], since instances of powertypes are also subtypes of anothertype and hence retain both a type and an instance facet. Multi-level metamodelling canalso be emulated through stereotypes, although this is not a general modelling techniquesince it relies on UML to emulate the extension of its metamodel. The interested readercan consult [5] for a thorough comparison of potencies, powertypes and stereotypes.

A second strand of research focuses on deep characterisation. DeepJava [15], META-DEPTH [16], and the works of Gutheil [14], Atkinson [3], and Aschauer [1] all supportdeep characterisation through potency. While these works agree on that clabjects areinstantiated using the multi-potency semantics, they differ in other design decisions.Firstly, some works are ambiguous about the instantiation semantics for associations.In [15], the associations can be represented as Java references; hence we interpret thatthey are instantiated using the single-potency semantics. In [14], the connectors are ex-plicitly represented as clabjects but their instantiation semantics is not discussed; hencewe interpret that they are instantiated using the multi-potency semantics. Secondly, notall works adhere to strict ontological metamodelling. In [1], the ontological type ofan association does not need to be in the adjacent metalevel above, but several meta-levels above. Note that our single-potency semantics makes it possible to retain strictmetamodelling for associations through a flattening construction that replicates theseassociations. Finally, some works differ in how they tackle potency on constraints andmethods. Potency on constraints is not explicitly shown in [3] and not considered in [1],whereas potency on methods is only supported by DeepJava and METADEPTH.

Table 3 shows a summary of the particular semantics for deep characterisation im-plemented by the above mentioned works and compares it with the semantics supportedby our formalisation. It is worth noting that no tool recognises the fact that multiplicityconstraints are constraints as well and hence can have a potency.


Table 3. Comparison of different deep characterisation semantics

Clabjects Associations Strictness Constraints Mult. constraintsDeepJava [15] � � yes � N.A.Atkinson et al. [3] � � yes � �1Aschauer et al. [1] � � no N.A. �1METADEPTH [16] �, � �, � yes � �1DPF formalisation �, � �, � yes �, � �, �


In this paper, we presented a formalisation of concepts of deep metamodelling usingDPF and graph transformation. In particular, we provided a precise definition of thedouble linguistic/ontological typing and two different semantics for potency on differentmodel elements, as well as an operational semantics of potency using a flattening basedon graph transformation.

We believe that distinction of two possible semantics for potency is important toachieve more flexible tools, allow their comparison and their interoperability. For in-stance, in our case study (see Fig. 1), the multi-potency on the association datalinkhas the effect that one can only add associations between instances of the componentTable and instances of the component Map in the model M3. On the contrary, a single-potency on the association datalink would have the effect that one could add associ-ations between any two component instances in the model M3, not necessarily betweeninstances of Table and instances of Map. We found both semantics especially useful inthis case study.

To the best of our knowledge, this work is the first attempt to clarify and formalisesome aspects of the semantics of deep metamodelling. In particular, this work explainsdifferent semantic variation points available for deep metamodelling, points out newpossible semantics, currently unexplored in practice, as well as classifies the existingtools according to these options.

In the future, we plan to investigate the effects of combining different potency val-ues to interdependent model elements. This includes the investigation of the effects ofoverriding the potency of a clabject using inheritance, as this may lead to contradictorycombinations of potencies. We also plan to formalise the linguistic extensions proposedin [16]. Finally, we will incorporate the lessons learnt from this formalisation into theMETADEPTH tool, in particular the possibility of assigning potency to multiplicity con-straints.

Acknowledgements. Work partially funded by the Spanish Ministry of Science (projectTIN2008-02081), and the R&D programme of the Madrid Region (project S2009 /TIC-1650).

References

1. Aschauer, T., Dauenhauer, G., Pree, W.: Multi-level modeling for industrial automation sys-tems. In: EUROMICRO 2009, pp. 490–496. IEEE Computer Society (2009)


2. Asikainen, T., Männistö, T.: Nivel: A metamodelling language with a formal semantics. Soft-ware and Systems Modeling 8(4), 521–549 (2009)

3. Atkinson, C., Gutheil, M., Kennel, B.: A flexible infrastructure for multilevel language en-gineering. IEEE Transactions on Software Engineering 35(6), 742–755 (2009)

4. Atkinson, C., Kühne, T.: Rearchitecting the UML infrastructure. ACM Transactions on Mod-eling and Computer Simulation 12(4), 290–321 (2002)

5. Atkinson, C., Kühne, T.: Reducing accidental complexity in domain models. Software andSystems Modeling 7(3), 345–359 (2008)

6. Barr, M., Wells, C.: Category Theory for Computing Science, 2nd edn. Prentice-Hall (1995)7. Clark, T., Sammut, P., Willans, J.: Applied Metamodelling: A Foundation for Language

Driven Development, 2nd edn., Ceteva (2008)8. Diskin, Z.: Mathematics of Generic Specifications for Model Management I and II. In: En-

cyclopedia of Database Technologies and Applications, pp. 351–366. Information ScienceReference (2005)

9. Diskin, Z., Kadish, B., Piessens, F., Johnson, M.: Universal Arrow Foundations for VisualModeling. In: Anderson, M., Cheng, P., Haarslev, V. (eds.) Diagrams 2000. LNCS (LNAI),vol. 1889, pp. 345–360. Springer, Heidelberg (2000)

10. Diskin, Z., Wolter, U.: A diagrammatic logic for object-oriented visual modeling. In: Proc. ofthe 2nd Workshop on Applied and Computational Category Theory (ACCAT 2007). ENTCS,vol. 203(6), pp. 19–41. Elsevier (2008)

11. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals of Algebraic Graph Transform-ation. Springer (March 2006)

12. Gitzel, R., Ott, I., Schader, M.: Ontological extension to the MOF metamodel as a basis forcode generation. Computer Journal 50(1), 93–115 (2007)

13. Gonzalez-Perez, C., Henderson-Sellers, B.: A powertype-based metamodelling framework.Software and Systems Modeling 5(1), 72–90 (2006)

14. Gutheil, M., Kennel, B., Atkinson, C.: A Systematic Approach to Connectors in a Multi-levelModeling Environment. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., Völter, M. (eds.)MODELS 2008. LNCS, vol. 5301, pp. 843–857. Springer, Heidelberg (2008)

15. Kühne, T., Schreiber, D.: Can programming be liberated from the two-level style? Multi-levelprogramming with DeepJava. In: OOPSLA 2007: 22nd Annual ACM SIGPLAN Confer-ence on Object-Oriented Programming, Systems, Languages and Applications, pp. 229–244.ACM (2007)

16. de Lara, J., Guerra, E.: Deep Meta-modelling with METADEPTH. In: Vitek, J. (ed.) TOOLS2010. LNCS, vol. 6141, pp. 1–20. Springer, Heidelberg (2010)

17. Rossini, A.: Diagram Predicate Framework Meets Model Versioning and Deep Metamodel-ling. Ph.D. thesis, Department of Informatics, University of Bergen, Norway (2011)

18. Rossini, A., Rutle, A., Lamo, Y., Wolter, U.: A formalisation of the copy-modify-mergeapproach to version control in MDE. Journal of Logic and Algebraic Programming 79(7),636–658 (2010)

19. Rutle, A.: Diagram Predicate Framework: A Formal Approach to MDE. Ph.D. thesis, De-partment of Informatics, University of Bergen, Norway (2010)

20. Rutle, A., Rossini, A., Lamo, Y., Wolter, U.: A formal approach to the specification andtransformation of constraints in MDE. Journal of Logic and Algebraic Programming 81(4),422–457 (2012)

21. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: EMF: Eclipse Modeling Framework2.0., 2nd edn. Addison-Wesley Professional (2008)

Reusable Graph Transformation Templates

Juan de Lara and Esther Guerra

Department of Computer ScienceUniversidad Autonoma de Madrid, Spain{Juan.deLara,Esther.Guerra}@uam.es

Abstract. Model-Driven Engineering promotes models as the principalartefacts of the development, hence model transformation techniques –like graph transformation – become key enablers for this developmentparadigm. In order to increase the adoption of Model-Driven Engineer-ing in industrial practice, techniques aimed at raising the quality andproductivity in model transformation development are needed.

In this paper we bring elements from generic programming into graphtransformation in order to define generic graph transformations that canbe reused in different contexts. In particular, we propose the definitionand instantiation of graph transformation templates whose requirementsfrom generic types are specified through so-called concepts, as well asmixin layers that extend meta-models with the extra auxiliary elementsneeded by templates.

1 Introduction

Model-Driven Engineering (MDE) is a software development paradigm that pro-motes the use of models as the principal assets of the development. Hence, modelmanipulation techniques – like graph transformation (GT) [3] – become enablingtechnologies for this approach.

In order to foster the use of MDE in industry, techniques aimed at raising thequality of the generated software and to speed up the productivity of engineersare needed. One way to improve productivity is to increase the reusability ofmodel transformations, so that they can be applied in different contexts. Unfor-tunately, building transformations in MDE is a type-centric activity, in the sensethat transformations are defined over the specific types of concrete meta-models,and it is difficult to reuse them for other meta-models even if they share charac-teristics. For example, even if many languages share the semantics of Petri nets,like activity diagrams or process modelling languages, such semantics is nor-mally defined over some specific meta-model (a concrete realization of a Petrinet meta-model) and cannot be easily reused for other meta-models.

The present work aims at providing mechanisms to enable the correct reuseof GT systems across different meta-models. For this purpose, we build uponsome ideas from generic programming [5] to define generic GT systems that wecall GT templates. These generic GT systems are not defined over the types ofconcrete meta-models, but over variable types that need to be bound to types


36 J. de Lara and E. Guerra

of some specific meta-model. However, not every meta-model qualifies as a validbinding for the variable types used in a GT template. Hence, in order to ensurea correct reuse, we specify the requirements that meta-models need to satisfyusing a so-called concept [10,6]. A concept gathers the structural requirementsthat need to be found in a meta-model to be able to instantiate a GT templateon the meta-model types and apply the template to the meta-model instances.

In addition, GTs sometimes need auxiliary model elements to perform somecomputations. For example, in order to define the semantics of Petri nets, we mayneed an edge referencing the transition that is currently being fired, or in object-oriented systems we may need to introduce an auxiliary edge to flatten the inher-itance hierarchy. These extra elements do not belong to the meta-model of thelanguage, but are auxiliary devices needed by the transformation. Hence, a GTtemplate cannot demand specific meta-models to include such extra devices aspart of its requirements. Instead, we define so-called mixin layers [10,15]. Theseare meta-models with parameters, that are applied to specific meta-models, in-creasing them with extra elements by a gluing construction. Mixins are generic,and hence applicable to any meta-model that satisfies the requirements given bya set of concepts. In this way, a GT template can be defined over the types ofthe mixin and the types of the concepts such mixin needs.

This paper continues our research on model transformation reuse by means ofgenericity [10,13]. While in [13] we added genericity to model-to-model transfor-mations expressed in the ATL language, here we focus on in-place transforma-tions expressed using GT. The use of a formal framework helps in formulatingtemplate instantiations (i.e., bindings) precisely, identifying the needed condi-tions for correct template reuse, and understanding the composition mechanismof mixins. The formal semantics of DPO graph transformation yields tighterconditions for correct template reuse than in our previous works [10,13].

Paper Organization. First, Section 2 introduces our approach. Then, Section 3defines meta-models algebraically. Section 4 explains how to bind concepts tometa-models, providing a mechanism to instantiate GT templates. Section 5shows how to define and apply mixins. Section 6 provides further examples.Finally, Section 7 compares with related work and Section 8 concludes.

2 Overview of the Approach

Frequently, very similar transformations are developed for different meta-models.The reason is that although similar, each transformation is developed to workwith the types of a particular meta-model, so that its use with types of otherunrelated meta-models is not possible. This results in a waste of effort as thesame problems and solutions have to be tackled repeatedly. For example, there isa catalogue of well-known refactorings for object-oriented systems [4]; however,if we encode them as GT rules, we need a different encoding for each meta-model we use. In this way, we need to encode a different transformation forthe UML meta-model, the Java meta-model, or the meta-model of any otherobject-oriented notation we may like to work with.

Reusable Graph Transformation Templates 37

Analogously, there are languages with similar semantics. For example, manylanguages share the semantics of Petri nets, such as activity diagrams or domain-specific languages for manufacturing (parts are produced and consumed at ma-chines) and networking (packets are sent and received by computers). However,if we specify their semantics through a GT system, we need to encode a differentsystem for the meta-model of each language.

Therefore, a mechanism to define GT systems for families of meta-modelssharing some requirements would promote the reutilization of transformations.For this purpose, we use so-called concepts [10,6] to gather the requirementsof a family of meta-models, needed by a reusable GT system to work. Theserequirements are structural, and hence a concept has the form of a meta-model aswell. However its elements (nodes, edges, attributes) are interpreted as variablesto be bound to elements of specific meta-models. The rules of a GT template usethe variables in the concept instead of the types of a specific meta-model. Asa result we obtain reusability because the concept can be bound to a family ofmeta-models, and the GT template becomes applicable to any of them.

This situation is illustrated in Fig. 1, where a GT template has been definedover the variable types of a concept C. As an example, C may define the corestructural elements that characterize Petri net-like languages, and the transfor-mation may include rules (defined over the type variables in C) to refactor Petrinet-like models, according to the catalogue in [12]. The concept can be bound toa set L(C) of meta-models sharing the structure required by the concept. In thisway, the rules can be applied on instances of any meta-model MM ∈ L(C). Wehave depicted the set of models conformant to a meta-model MM as L(MM).

Concept C

Meta-model n

binding

Meta-model 1

binding

…

L(C)

typed on

Model-1Model-1Model1 1

L(meta-model 1)

Model-1Model-1Modeln 1

L(meta-model n)

conforms to

…

conforms to

applicable to

Holder Process*

*

Token

tokens1

in

out

:Process

LHS

:Holder :Process:Holder

:Token

RHS

GT Template

Fig. 1. Scheme of the approach: concept, GT template and binding

In addition, oftentimes, GTs make use of auxiliary graph elements to imple-ment some model manipulations. For example, when defining the semantics ofPetri nets, we need an auxiliary node to mark which transition is being fired, aswell as the processed input and output places, in order to add/remove tokensto/from the appropriate places. The types of these auxiliary elements do notbelong to the meta-model of the language (Petri nets), but are auxiliary ele-ments needed just for the simulation. If this simulator is built as a GT templateover a concept, then this concept cannot include the auxiliary elements (and no


binding will be provided for them) because the meta-models will hardly everinclude such extra devices.

In order to solve this problem, we define so-calledmixin layers as an extensionmechanism for meta-models. A mixin is a generic meta-model defining all extraelements needed by a GT template but which are not present in a concept. Inaddition, it includes some formal parameters acting as gluing points betweenthe mixin and the concept. Thus, the GT template can use the variable typesdefined on both the mixin and the concept. Once we bind the concept into aspecific meta-model, this is extended with the new types defined by the mixin,and the template can be applied on instances of this extended meta-model.

This scheme is shown in Fig. 2. In particular, the mixin adds some auxiliaryelements to simulate Petri net-like languages (a pointer to the process beingfired and to the processed holders of tokens). The mixin defines as gluing pointsthe nodes Holder and Process, whose requirements are given by a concept C(structure of Petri net-like languages). Binding the concept to a specific meta-model will increase the meta-model with the elements of the mixin. The GTtemplate is defined over the types resulting from gluing C and the mixin, and isapplicable to instances of meta-models to which we can bind C.

Concept C

mixin layer ML

typed on

applicable to

MM n

MM 1

…

L(C)

MM n’

MM 1’

…

L(ML)

applyML

M1 1

L(MM 1)

L(MM n)

Mn 1

…

Holder Process*

*

Token

tokens1

in

out

defined over

requirementsfor ext. points

extensionpoints Holder Process

Currentinp

out

** 0..1

Holder Process

conforms

conforms

typed

typed

binding

binding

active: boolean

:Process

RHS

:Current

active=true

:Process

LHS

GT Template

Fig. 2. Scheme of the approach: adding auxiliary elements through a mixin layer

3 An Algebraic Setting for Models and Meta-models

In our setting, we consider attributed,1 typed graphs [3] of the form G = 〈V ;E;A;D; srcE , tarE : E → V ; srcA : A → V ; tarA : A → D〉, made of a set V ofvertices, a set E of edges, a set A of attributes, a set D of data nodes, andfunctions src and tar that return the source and target vertices of an edge, andthe owning vertex and data value of an attribute.

In order to represent meta-models, we consider type graphs with inheritanceand with cardinality constraints in associations, in the style of [16]. In this way, a

1 For simplicity, we do not consider abstract nodes or attributes in edges.


meta-model MM = 〈G; I ⊆ V ×V ; card : E → N× (N∪{∗})〉 is made of a graphG, together with a set I of inheritance relations, and a function card that returnsthe cardinality of target ends of edges. We assume EMF-like references for edges(i.e., with cardinality only in the target end) so that UML-like associations (i.e.,with cardinality in both ends) should be modelled as a pair of edges in bothdirections. Given a node n ∈ V , we define its clan as the set of its direct andindirect children, including itself. Formally, clan(n) = {n′ ∈ V |(n′, n) ∈ I∗},where I∗ is the reflexive and transitive closure of I. For simplicity, we avoidadding an algebra to MM .

Similar to [16], we give semantics to cardinality constraints by means of pos-itive and negative atomic graph constraints [3] of the form PC(a : P → Q) and¬PC(a : P → Q). The former require that for each occurrence of P in a graphG, we find a commuting occurrence of Q. Formally, for each m : P → G we needm′ : Q → G s.t. m = m′ ◦ a. Negative atomic constraints demand that for eachoccurrence of P in a graph, there is no commuting occurrence of Q. If G satisfiesa constraint a, we write G |= a.

In particular, we generate graph constraints regulating the minimum andmaximum number of instances at association ends. Thus, for each edge e in themeta-model with card(e) = [l, h], if l > 0 we generate a positive graph constraintas shown to the left of Fig. 3, and if h �= ∗ we generate a negative graph constraintas shown to the right of the same figure.

A

B

e

meta-modelfragment

:A

:B

:A

:B

…

P Qnegative constraint due to upper bound

:A

:B

:A

:B

…

P Qpositive constraint due to lower bound

Fig. 3. Graph constraints generated from cardinality constraints

Next we define morphisms between meta-models as a graph morphism withsome extra constraints given by the inheritance hierarchy. We will use this notionlater to define the binding between a concept and a meta-model.

A morphism MM →MM ′ between two meta-models (short MM-morphism)is given by a clan morphism [9] f : GMM → MM ′ from the graph GMM ofthe first meta-model to the second meta-model, preserving the inheritance hi-erarchy. A clan morphism is similar to a standard E-Graph morphism [3], butit also takes into account the semantics of inheritance. Hence, for each edgee of GMM that is mapped to an edge e′ of GMM ′ , we allow the source nodeof e to be mapped to any node in the clan of the source node of e′. Formally,fV (srcE(e)) ∈ clan(src′E(fE(e))), and similar for the target of edges. In addition,we allow mapping an attribute of a node to an attribute of a supertype the nodeis mapped into. Formally, fA(srcA(a)) ∈ clan(src′A(fA(a))). As in [7], the mor-phism has to preserve the inheritance hierarchy as well, hence if (u, v) ∈ IMM ,then (f(u), f(v)) ∈ I∗MM ′ . Please note that we purposely neglect cardinality


constraints in MM-morphisms because the semantics of these is given by graphconstraints. We will deal with this issue when defining the binding between aconcept and a meta-model.

A model M can be seen as a meta-model with empty inheritance hierarchyand no cardinality constraints. Therefore, we can represent the typing function

Mtype−→MM as an MM-morphism. In addition, we say that M conforms to MM

(written M |=type MM) if there is a typing Mtype−→ MM and M satisfies all

graph constraints derived from the cardinality constraints in MM .

A

Be[0,*]

int f

MMA’

EC’ e’[2,3]

MM’

B’

[1,*]

d

C

inta a’

:B:e

3

M

:C:a

type

Fig. 4. MM-morphisms

Example. Fig. 4 shows anMM-morphismf between two meta-models, where wehave represented attributes as arrows toa datatype (see a) and mapped elementswith primas (e.g., node A is mapped tonode A’). The attribute in node B ismapped to an attribute defined in E,which is a supertype of the node mappedto B, and the same for the edge e. Regard-ing the preservation of the inheritance hi-erarchy, MM-morphisms permit introduc-ing intermediate nodes in the hierarchy ofthe target meta-model (like node E which is between the image nodes A’ and B’)as well as mapping several nodes in an inheritance relation into a single node.

The figure also shows a typing MM-morphism type : M → MM using theUML notation for typing. We can compose MM-morphisms, hence M is alsotyped by f ◦ type : M → MM ′. However, conformance is not compositional ingeneral, as M conforms to MM (M |=type MM) but not to MM ′ due to itscardinality constraints (M �f◦type MM ′). Finally, given M ′ |=type MM ′, wehave that the pullback object of MM → MM ′ ← M ′ is typed by MM , butneed not be conformant to MM .

4 Graph Transformation Templates

GT templates are standard GT systems specified over the variable types of aconcept, which has the form of a meta-model. As an example, Fig. 5 shows tothe left the concept TokenHolder, which describes the structural requirementsthat we ask from Petri net-like languages, namely the existence of classes playingthe roles of token, holder (places in Petri nets) and process (transitions). We canuse this concept to define generic GT systems for the simulation and refactoringof models in languages with this semantics. For instance, the right of the samefigure shows one of the behaviour-preserving refactoring rules proposed in [12]expressed in a generic way, using the types of the concept. The rule removesself-loop holders with one token provided they are connected to a single process.

In order to use the GT template, we need to bind the concept to a specificmeta-model. This binding is an MM-morphism with some extra constraints de-rived from the particular GT template to be reused. As an example, Fig. 6 shows


Holder Processin*

TokenHolder (Concept)

Holder Process

Token

1 out*tokens

Token

LHSNAC1NAC2 RHS

ESH (elimination of self-loop holders)

p:Process

i1:in o:out

LHS

p:Process

i1:in i2:in

NAC1

q:Process

i3:in

NAC2

p:Process

RHS

t:Token h:Holderh:Holderh:Holder

Fig. 5. Concept TokenHolder (left), and GT template over the concept (right)

a binding attempt from the TokenHolder concept to a meta-model to define fac-tories. Factory models contain machines interconnected by conveyors which maycarry parts. Both conveyors and machines need to be attended by operators.Hence, our aim is to apply the rule template ESH on instances of the Factoriesmeta-model. However, there is a problem because this rule deletes holders, andwe have bound holders to conveyors, which are always connected to some op-erator as required by the cardinality constraints. Thus, if we try to apply therule (using DPO semantics), it will always fail as we will obtain a dangling edge.This shows that the binding should ensure some correctness conditions, whichwe present in the remaining of the section.


Conveyor Machinein*

Part1 out*

parts

Element

name: String

Operator1

attendedby

bind

Holder Processin*

Token

1 out*tokens

{ (Holder,Conveyor), (out,out),

(Token, Part), (tokens,parts),

(Process, Machine), (in,in) }

Factories

Fig. 6. Binding a concept to a meta-model: first attempt

Cbind �� MM

M ′type′��

emb ��

P.B.

��

∗��

M

type

��

∗��

��

M ′f emb′ �� Mf

The general instantiation scheme of a GT template fora given binding is shown in the diagram to the right. Thetemplate is typed over the concept C, which needs to bebound to a meta-model MM by a special kind of MM-morphism bind : C → MM . The binding provides a re-typing for the rules of the template, which then becomeapplicable to instance graphs of MM . In order to ensurea correct application of the template, we must guarantee that for every modelM |=type MM , if we consider only the elements M ′ given by the concept C(obtained by the pullback in the diagram), and M ′ |= C, then, for each possiblesequence of rule applications over M ′, there is a sequence of rule applications(using the same order) applicable toM . Moreover, there should be an embeddingfrom the final model M ′

f into Mf .Although this issue resembles the one handled by the embedding and extension

theorems [3], there are fundamental differences. The main one is that our goal isto discard invalid bindings and initial models that would lead to an incorrect ap-plication of the GT template before applying it. On the contrary, the mentioned


theorems check the feasibility of each particular derivation M ′ ⇒∗ M ′f checking

some conditions after the transformation is performed. Hence, our view gainsin efficiency. Moreover, the embedding and extension theorems do not considerinheritance and cardinalities in type graphs.

In order to ensure that a GT template will behave as expected for a givenmeta-model, we generate two kinds of constraints. The first kind works at themeta-model level and forbids bindings that would always lead to an incorrectexecution of the template, as some rules of the template would be inapplicable forany possible model due to dangling edges or violations of cardinality constraints.However, some bindings may lead to incorrect executions only for some initialmodels. Thus, our second kind of constraints detects potential incorrect templateexecutions for a particular instance of a meta-model. If a binding and an initialmodel satisfy these constraints, then the template can be safely applied to themodel. Next we explain in detail each constraint type.

Constraints for Bindings. These constraints act as application conditions forthe binding. Fig. 7(a) illustrates how they work. Assume we want toapply our refactoring GT template to models that conform to the Factory meta-model. The first step is therefore binding the TokenHolder concept to the meta-model, as indicated in the figure. Looking at the rule in Fig. 5 we notice thatit deletes holders. As holders are mapped to conveyors, and conveyors are al-ways attended by one operator, applying the rule to a model with a conveyorwill always produce a dangling edge making the rule not applicable. Since thisis not the behaviour expected from the original template, this binding is notallowed. In order to detect these situations, we attach the atomic constraint

¬PC(TokenHolderq→MandatoryEdge) shown in the figure to the binding, in

a similar way as application conditions are attached to the LHS of a rule. Thisconstraint forbids a binding if the holder is connected to some node Z through anedge with lower cardinality bigger than 0. As this is the case should we identifye and attendedby, the binding is not allowed.


q

Conveyor Machinein*

1

out*

parts

Element

name: String

Operator1attendedby

bind

MandatoryEdge

ext { … (Z,Operator),

(e,attendedby) }

Holderin*

Token

1 out*tokens

Holder*

Token

1 out*tokens

in

Z[l..h]

e

{ (Holder,Conveyor), (out,out),

(Token, Part), (tokens,parts),

(Process, Machine), (in,in) }

with l>0

Process Process

Part

A

P

…

A Xe [l..h]

Q…

l>0with:

Concept C

q

(a) (b)

Fig. 7. (a) Evaluating constraint in a binding. (b) Scheme of constraints for bindings.


The structure of the generated constraints for bindings is shown in Fig. 7(b).The constraints use MM-morphisms and must be satisfied by the function bind.They are generated for each node type that is created or deleted by the GTtemplate. Thus, if the template creates or deletes an object of type A, we generatea constraint that has the concept C as premise, and the concept with a class X(existing or not in C) connected to A through an edge e with lower cardinalitybigger than 0 as consequence. We also demand that the match of the edge e doesnot belong to bind(C). If a rule deletes an A object, the intuitive meaning is thatit will produce a dangling edge because of this mandatory edge, disabling therule application. This breaks the correctness criteria because we could apply therule in a model M ′ conformant to the concept but not in a model M conformantto the meta-model. Therefore we forbid such a binding. If a rule creates an Aobject, we generate the same constraint because applying the grammar to amodel M typed over MM would only produce incorrect models, as the createdobject would need to be connected to an object of type X through an unforeseenedge type e. Please note that the generated constraint takes into account thecase where the edge e has been defined in an ancestor of the class bound to A,as we use MM-morphisms. On the contrary, the constraint does not detect ifthere is a subtype defining an unbounded mandatory edge and does not forbidthe binding in such a case. Indeed, in this situation, there may be initial modelswhere the template can be safely applied, therefore this scenario is handled bya second set of constraints working at the model level (see below).

Regarding cardinalities, we forbid binding edges with cardinality [l..h] to edgeswith cardinality [l′..h′] if both intervals do not intersect, as from a model M |=MM we would never obtain a model M ′ |= C performing the pullback. Inaddition, if a GT template creates or deletes instances of the source or targetclasses of an edge e defined in a concept C, then we can map the edge to e′ =bind(e) only if card(e) = card(e′). This condition is not required for edges whosesource and target are not created or deleted by the template; however, the initialmodel must satisfy the cardinality constraints of the concept in any case (i.e.,the pullback object M ′ must satisfy M ′ |= C).

Constraints for Initial Models. These constraints check whether a GT tem-plate can be safely executed on a given initial model. For instance, assume thatthe cardinality of attendedby is [0..1] in the meta-model of Fig. 7(a), so thatthe binding is allowed. Still, given an initial model like the one in Fig. 8(a), ourgeneric refactoring will not be applied to the conveyor as it has one operator,hence leading to a dangling edge as discussed before. This differs from the orig-inal template behaviour where such dangling edges do not occur. However, wecan safely apply the rule to any model where conveyors have no operator, whichwe check by generating the constraint in the upper part of the figure.

Fig. 8(b) shows the structure of the generated constraints for initial models.These constraints restrict the instances of the meta-model MM to which theconcept C is bound. They are generated for each node type in the meta-modelthat is deleted by the GT template, as well as for its subtypes, whenever the typesdeclare an edge not included in the binding. Formally, if a generic rule deletes an


:Conveyor:out

name=“belt1” name=“press”

:in

:Operator:Part

:Conveyor:Operator

PQ

q

m m’=

:bind(A)

P

:bind(A) :Z

Qwith e MM\bind(C)

:e

:bind(A)

P

:bind(A) :X

Q

:d

bind(A)

Z

MM…

e

with d MM\bind(C)

bind(A)

X

MM…

d

(a) (b)

:Conveyor

:Machine

Fig. 8. (a) Evaluating constraint in model. (b) Scheme of constraints for initial models.

object of type B, we generate a constraint for each A ∈ clan(bind(B)) and foreach edge e in which A participates whose type belongs to MM \bind(C). This isa sufficient condition to avoid violating the correctness criteria (the instantiatedtemplate could fail due to dangling edges) but it is not a necessary condition.

5 Mixin Layers

We now define mixin layers with the purpose of extending meta-models with anyauxiliary element needed to execute a GT template. A mixin layer is a meta-model where some of its elements are identified as parameters. Parameters areinterpreted as variable types that have to be instantiated to types of the specificmeta-model where we want to apply the mixin. However, not every meta-modelis eligible to be extended by a particular mixin, and not every type is a validinstantiation of the mixin parameters. The requirements needed by a meta-modeland its types are given by one or more concepts.

We define a mixin layerML asML = 〈MM,Conc = {Ci}i∈I , Par = {Pj}j∈J〉,where MM is a meta-model, Conc is a set of concepts expressing the require-ments for meta-models to be extensible by the mixin, and Par is a set of pa-rameters identifying the mixin extension points. Each element Pj in the set ofparameters has the form Pj = 〈GMM ← Gj → GCi〉, a span relating the graph-ical elements in the mixin (GMM ) with the graphical elements in one of theconcepts (GCi∈Conc).

Example. We are building a generic simulator for Petri net-like languages bymeans of a GT template defined over the concept TokenHolder. However, apartfrom the elements already present in this concept, the simulator must use aux-iliary nodes and edges to model the firing of transitions. Adding these elementsto the concept is not an option because it would imply that the definition ofevery language to be simulated with the template should be modified manuallyto include these auxiliary elements in its meta-model. Instead, we define a mixinwhich increases any meta-model to be simulated with these auxiliary elementsin a non-intrusive way. Fig. 9 shows the mixin (dotted box named “Simulationmixin”) which declares two parameters (shaded classes Holder and Process).


Additionally, the concept TokenHolder gathers the requirements for the eligiblemeta-models for the mixin. The relation between the mixin and the concept isexpressed as a span of MM-morphisms. This is used to build the meta-modelshown to the right by a gluing construction (a colimit, even though in the partic-ular case of the figure it is also a pushout). This meta-model contains all variabletypes that the GT template can use.

Holder Processinout

**

Token

tokens1

inp

outp

** 0..1

TokenHolderconcept

Simulation mixin

Parameters

Holder Process

Holder Processin

out**

Token

tokens1

Holder Process

inp

outp

** firing

P.O.

firing

0..1

active: boolean

Current

active: boolean

Current

Fig. 9. Specifying a mixin for the simulation of Petri net-like languages

Fig. 10 shows some rules of the generic simulator defined over the mixin.The rule to the left selects one enabled process to be fired, marking it with aninstance of the Current class from the mixin. Its application condition checksthe enabledness of the process (i.e., each input holder has a token). The ruleto the right removes one token from an input holder of the process being fired,marking it as processed. Additional rules produce tokens in output holders, andunmark the processed holders and process to allow further firings.

p:Process

RHS

c:Current

active=true

p:Process

LHS

NAC c:Current

p:Process

:in

if...

h:Holder

p:Process

:in

then

h:Holder

select transition

t:Token

:firing

RHS = NACLHS

remove token

:inp

p:Process

c:Current

active=true

:in

h:Holdert:Token

p:Process

c:Current

active=true

:in

h:Holder

:firing :firing

Fig. 10. Some rules of the GT template for the simulation of Petri net-like languages.The template is defined over the mixin Simulation shown in Fig. 9.

A mixin becomes applicable by binding its concepts to a meta-model. Fig. 11shows the binding of concept TokenHolder to the Factory meta-model. Then,the bound meta-model is extended with the elements defined in the mixin meta-model but not in the concept (class Current and edges inp, outp and firing).Thus, we can apply the GT template to instances of the resulting meta-model.


Conveyor Machinein*out*

Element

name: String

Operator0..1

attendedby

=

bind

meta-model

firinginp

outp

**

mixin applied to meta-model

TokenHolderconcept

Parameters

Holder Process

Holderin

out**

Token

tokens

1

0..1

Part1

parts

Process


Element

name: String

Operator0..1

attendedby

Part1

partsSimulation mixin

Holder Process

inp

outp

** firing0..1

active: boolean

Current

active: boolean

Current

Fig. 11. Applying mixin Simulation to a meta-model

The left of Fig. 12 presents formally how a mixin is applied to a meta-model.The mixin in the figure defines a meta-model MMml, a set of concepts Ci andparameters MMml ← Gj → Ci. The gluing of the mixin meta-model and theconcepts is obtained by calculating their colimit,2 yielding object MMml. This isthe meta-model over which a GT template is defined. For instance, the templaterules shown in Fig. 10 use the meta-model to the right of Fig. 9. Next, the mixincan be applied by binding its concepts to a particular meta-model (or in generalto a set of meta-models, as it is not necessary to bind all concepts to the samemeta-model). The colimit of the different mixin parameters MMml ← Gj → Ci

and the bound meta-models yields MM , which is used to retype the templatefor its application on the bound meta-models. By the colimit universal property,there is a unique commuting u : MMml →MM , which acts as binding betweenthe meta-model over which the GT template is specified and the extended specificmeta-model. The right of Fig. 12 shows this unique binding for the example.

6 Additional Examples

Next we show a further example illustrating the applicability of our proposal.Software Engineers have developed a catalog of refactorings to improve the

quality of software systems without changing its functionality [4]. One of themost well known catalogs is specially tailored for object-oriented systems [4].This catalog describes rules applicable to any object-oriented language, but theirencoding for a particular object-oriented notation cannot be reused to refactorother notations. Thus, a developer should encode different rule sets for the Javameta-model, the UML meta-model, and so on.

In our approach, we can define the refactorings once over a concept and thenbind the concept to several meta-models, obtaining reuse for each bound meta-model. Fig. 13 shows (a simplification of) the concept, together with bindingsfor two meta-models. The one to the left defines simple UML class diagrams.

2 In the category of MM-objects and MM-morphisms.


u

firinginp

outp

** 0..1


Element

name: String

Operator0..1

attendedby

Part1

parts

active: boolean

Current

Holder Process

inp

outp

** firing0..1

active: boolean

Current

in

out**Token

tokens1

G1

��

�� C1

bind1 ��

��

�� MM1

��

��

MMml... MMml

u �� MM

Gj

�� Ci

bindi ��

��MMn

��

Fig. 12. Binding and applying a mixin (left). Resulting binding for the example (right).

The right meta-model is for Rule-Based Access Control (RBAC) [14], and per-mits the definition of properties and permissions for roles that can be hierarchi-cally arranged. Children roles inherit the properties and permissions of parentroles.

OO (concept)

Class

name: String

atts *

Attribute

name: String

Method

name: String

methods*

bind1

{ (Class, Class), (Class.name, Element.name),

(Attribute, Field), (Attribute.name, Element.name),

(Method, Method), (Method.name, Element.name),

(parent, superclasses), (attrs, features),

(methods, features) }

Simple UML (meta-model)

parent*

Element

name: String

Package Class

StructuralFeature

superclasses*

*

featu

res

Field Method

Reference

Simple RBAC (meta-model)

Role

name: String

super

*Property

name: Stringvalue: String

props

*

permission

*Operation

name: String

bind2

{ (Class, Role),

(Class.name, Role.name),

(Attribute, Property),

(Attribute.name, Property.name),

(Method, Operation), (Method.name, Operation.name),

(parent, super), (attrs, props),

(methods, permission) }

Subject

assignment *

Session*

Fig. 13. Concept for object-oriented systems, and two possible bindings

Fig. 14 shows the generic rules for the pull-up attribute refactoring [4], whichmoves an attribute to a superclass when all its children classes define it. The firstrule detects the refactoring opportunity and moves the attribute from one of thechildren classes to the superclass. Then, the second rule removes the attributefrom the rest of children. We can also implement a more refined version of thisrefactoring by defining a mixin that declares a pointer for classes, which the rulescan use to indicate the parent class being refactored (i.e., class p in the rules).

The binding bind1 in Fig. 13 allows applying the generic refactoring to UMLmodels and pull-up fields. Nonetheless, using a different binding permits refac-toring references and methods as well, mapping Attribute to Method or toReference. Similarly, the binding bind2 permits refactoring properties in rolehierarchies, but we can bind Attribute to Operation to pull-up operations.


p:Class

:parenta:Attribute

name = n

LHS

Pull-up attribute 1

p:Class

:parenta:Attribute

name = n

RHS

p:Class

a:Attribute

name = n

NAC1

a1:Attribute

name = n

p:Class

:parent

if... thena:Attribute

name = n p:Class

:parenta2:Attribute

name = n

a:Attribute

name = n

c:Class c:Class

d:Classd:Class

p:Class

a:Attribute

name = n

c:Class

:parent

b:Attribute

name = n

LHS

Pull-up attribute 2

p:Class

a:Attribute

name = n

c:Class

:parent

RHS

Fig. 14. Rules of the GT template implementing refactoring pull-up attribute

7 Related Work

In object-oriented programming, mixins and traits are classes that provide extrafunctionality without being instantiated. Instead, other classes may inherit fromthe mixin, which is a means to collect functionality. We have generalized this ideato mixin layers. These are parameterised meta-models adding auxiliary elementsto a set of meta-models sharing the characteristics specified by a concept.

In previous work [10], we brought ideas from generic programming into MDE,implementing them in the MetaDepth tool. In particular, we were able to writegeneric model manipulations as EOL programs, an OCL-like language with sideeffects. Here we have adapted these ideas to the algebraic framework of GT,which presents several advantages: (i) we were able to formulate correctnesscriteria for instantiation and application of GT templates; (ii) in contrast toEOL programs, GT permits analysing the effects of transformations, and this isuseful to discard bindings leading to incorrect applications of the GT templates;(iii) formalizing bindings as morphisms provides a more precise description ofthe binding constraints, which we could not do in [10] because the behaviour ofEOL programs cannot be easily analysed; and (iv) the algebraic formalization ofmixins helped us in understanding how they work. Moreover, we discovered thata pattern-based approach to genericity (like the one presented here) imposesless restrictive conditions for the binding than one based on a scripting language(like EOL or OCL). This is so as MM-morphisms allow defining the target ofa reference in a supertype (cf. reference e′ in Fig. 4). In EOL, a navigationexpression c.e may lead to an E object, which may not have all properties ofa B′ object (as expected by the generic operation). On the contrary, in GTone provides a pattern with an explicit type for its objects (e.g., B which getsmapped to B′), hence filtering the undesired E objects.

Parameterized modules were proposed in algebraic specification in the eight-ies [2]. A parameterized module is usually represented with a morphism par : P →M from the formal parameters to the module. In this paper, we propose usingconcepts to restrict how the formal parameters can be bound to the actual pa-rameters in mixins. We can also think as GT templates as parameterized models(by a concept). In this case, the special semantics of DPO GT induce additionalconstraints in the binding. Our MM-morphisms are based on S-morphisms [7],


but we support attributes and do not require morphisms to be subtype preserv-ing. Our composition mechanism is also related to Aspect-Oriented Modelling [8],which focuses on modularizing and composing crosscutting concerns.

In the context of GT, there are some proposals for adding genericity to rules.For example, the VIATRA2 framework [1] supports generic rules where typescan be rule parameters. MOFLON has also been extended with generic andreflective rules using the Java Metadata Interface [11]. These rules can receivestring parameters that can be composed to form attribute or class names, andmay contain nodes that match instances of any class. Still, none of these toolsprovide mechanisms (like concepts and bindings) to control the correctness of ruleapplications, or extension mechanism (like mixins) for meta-models. We believethat the ideas presented in this paper can be adapted to these two approaches.

8 Conclusions and Future Work

In this paper we have adapted generic programming techniques to increase thereusability of GTs. In particular, we have defined GT templates, which are nottyped over a specific meta-model, but over concepts specifying the structuralrequirements that a meta-model should fulfil if we want to apply the templateon its instances. Hence, the GT template can be instantiated for any meta-model satisfying the concept, obtaining reusable transformations. Besides, manyGT systems use auxiliary elements that have to be included ad-hoc in the meta-models. We have proposed a non-intrusive solution consisting on the definition ofmixin layers declaring any extra device used by the template. The requirementsthat a meta-model should fulfil to be extended through the mixin are given bya concept. Again, we obtain reusability because a template that uses types of amixin can be applied to any meta-model that satisfies the mixin requirements.

As for future work, currently we forbid bindings that can lead to an incorrectexecution of a GT template. However, it may be sometimes possible to semi-automatically adapt the template to make it work correctly. In addition, nowwe require an exact match of the concept in the meta-models, but to increasereusability, we plan to provide techniques to resolve some heterogeneities in thebinding, in the line of [13]. On the practical side, we plan to include the lessonslearnt regarding correct binding and correct reuse in our MetaDepth tool.

Acknowledgements. Work funded by the Spanish Ministry of Economy andCompetitivity (project TIN2011-24139) and the Region of Madrid (project S2009/TIC-1650).

References

1. Balogh, A., Varro, D.: Advanced model transformation language constructs in theVIATRA2 framework. In: Proc. of the 21st Annual ACM Symposium on AppliedComputing, SAC 2006, pp. 1280–1287. ACM (2006)


2. Ehrig, H., Mahr, B.: Fundamentals of Algebraic Specification 2: Module Specifica-tions and Constraints. Monographs in Theoretical Computer Science. An EATCSSeries, vol. 21, Springer (1990)

3. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals of Algebraic GraphTransformation. Springer (2006)

4. Fowler, M.: Refactoring: Improving the Design of Existing Code. Addison-Wesley,Boston (1999)

5. Garcıa, R., Jarvi, J., Lumsdaine, A., Siek, J., Willcock, J.: A comparative studyof language support for generic programming. ACM SIGPLAN Notices 38(11),115–134 (2003)

6. Gregor, D., Jarvi, J., Siek, J., Stroustrup, B., Dos Reis, G., Lumsdaine, A.: Con-cepts: Linguistic support for generic programming in C++. ACM SIGPLAN No-tices 41(10), 291–310 (2006)

7. Hermann, F., Ehrig, H., Ermel, C.: Transformation of Type Graphs with Inheri-tance for Ensuring Security in E-Government Networks. In: Chechik, M., Wirsing,M. (eds.) FASE 2009. LNCS, vol. 5503, pp. 325–339. Springer, Heidelberg (2009)

8. Kienzle, J., Al Abed, W., Fleurey, F., Jezequel, J.-M., Klein, J.: Aspect-OrientedDesign with Reusable Aspect Models. In: Katz, S., Mezini, M., Kienzle, J. (eds.)Transactions on AOSD VII. LNCS, vol. 6210, pp. 272–320. Springer, Heidelberg(2010)

9. de Lara, J., Bardohl, R., Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: At-tributed graph transformation with node type inheritance. Theoretical ComputerScience 376(3), 139–163 (2007)

10. de Lara, J., Guerra, E.: Generic Meta-modelling with Concepts, Templates andMixin Layers. In: Petriu, D.C., Rouquette, N., Haugen, Ø. (eds.) MODELS 2010,Part I. LNCS, vol. 6394, pp. 16–30. Springer, Heidelberg (2010)

11. Legros, E., Amelunxen, C., Klar, F., Schurr, A.: Generic and reflective graph trans-formations for checking and enforcement of modeling guidelines. Journal of VisualLanguages and Computing 20(4), 252–268 (2009)

12. Murata, T.: Petri nets: Properties, analysis and applications. Proceedings of theIEEE 77(4), 541–580 (1989)

13. Sanchez Cuadrado, J., Guerra, E., de Lara, J.: Generic Model Transformations:Write Once, Reuse Everywhere. In: Cabot, J., Visser, E. (eds.) ICMT 2011. LNCS,vol. 6707, pp. 62–77. Springer, Heidelberg (2011)

14. Sandhu, R.S., Coyne, E.J., Feinstein, H.L., Youman, C.E.: Role-based access con-trol models. IEEE Computer 29(2), 38–47 (1996)

15. Smaragdakis, Y., Batory, D.: Mixin layers: An object-oriented implementationtechnique for refinements and collaboration-based designs. ACM Transactions onSoftware Engineering and Methodology 11(2), 215–255 (2002)

16. Taentzer, G., Rensink, A.: Ensuring Structural Constraints in Graph-Based Modelswith Type Inheritance. In: Cerioli, M. (ed.) FASE 2005. LNCS, vol. 3442, pp. 64–79.Springer, Heidelberg (2005)

Towards an Automated 3D Reconstructionof Plant Architecture

Florian Scholer and Volker Steinhage

Institute of Computer Science III, University of BonnRomerstraße 164, 53117 Bonn, Germany

{schoele,steinhag}@iai.uni-bonn.dehttp://ivs.informatik.uni-bonn.de/

Abstract. Non-destructive and quantitative analysis and screening of plant phe-notypes throughout plants’ lifecycles is essential to enable greater efficiency incrop breeding and to optimize decision making in crop management.

In this contribution we propose graph grammars within a sensor-based systemapproach to the automated 3D reconstruction and semantic annotation of plantarchitectures. The plant architectures in turn will serve for reliable plant pheno-typing. More specifically, we propose to employ Relational Growth Grammars toderive semantically annotated 3D reconstruction hypotheses of plant architecturesfrom 3D sensor data, i.e., laser range measurements. Furthermore, we suggest de-riving optimal reconstruction hypotheses by embedding the graph grammar-baseddata interpretation within a sophisticated probabilistic optimization framework,namely a Reversible Jump Markov Chain Monte Carlo sampling.

This paper presents the design of the overall system framework with the graphgrammar-based data interpretation as the central component. Furthermore, wepresent first system improvements and experimental results achieved in the appli-cation domain of grapevine breeding.

Keywords: 3D Reconstruction, Relational Growth Grammar, Reversible JumpMarkov Chain Monte Carlo, Plant Phenotyping, Grapevine Breeding.

1 Introduction

This work is part of CROP.SENSe.net [4], an interdisciplinary research network whosegoal is the assessment of traits of plants for more efficient plant breeding and crop man-agement. The network is subdivided into several projects, each of which is concernedwith different approaches. Here we are focussed on the 3D reconstruction of plants andthe semantics, i.e., the botanical annotation of all reconstructed plant components fromsensor data as a basis for phenotyping.

The foremost aim is a reconstruction algorithm that can handle arbitrary plants. Weenhance the strict geometric reconstruction by semantic annotations. These annotationsare attached to the components of the plant on the one hand and to the relations betweencomponents on the other. They comprise additional information about the componentor relation. This information in turn is used to assess phenotypic traits of the plant, likeits (estimated) yield. To achieve this we currently work on grapevine as an exemplar


http://ivs.informatik.uni-bonn.de/

52 F. Scholer and V. Steinhage

plant. There we face several challenges. (1) Diversity in cultivar architectures: Thereis a huge number of different grapevine cultivars, each of which has its own character-istics regarding the architecture like the number of bunches of grapes or the way thetrunk grows (straight up or protruding). (2) Diversity in plant part architectures: Everygrapevine has three parts. The trunk, the leaves and the bunches of grapes. Every suchpart has a different architecture in different levels of complexity; the leaves have differ-ent venations and contours depending on the cultivar, or the bunches of grapes can bemore or less compact. (3) Occlusions: A reconstruction of the complete plant is verydifficult since many parts of it are occluded. When in full bloom one side of the plantonly shows the foliage, blocking sight from that perspective. In bunches of grapes onecan only sense the outer berries, the inner ones are occluded. (4) Inconsistent naming:Because grapevines are grown all over the world sometimes there are different namesfor the same cultivar or one name is used for different cultivars [21]. For a first app-proach we concentrate on so-called stem skeletons, i.e., bunches of grapes where theberries were removed. An example can be seen in Fig. 1.

Fig. 1. A sample stem skeleton

The core piece of our approach is a model of the plant architecture for a pruning ofthe space of all reconstruction hypotheses and integrating this model into a samplingmethod to intelligently explore the hypothesis space.

For the modeling of plant architectures there are different possibilities. The mostpopular formalism for the modeling of plants are Lindenmayer systems (L-systems)[10,11]. An L-system is a parallel string rewriting grammar, where one has an alpha-bet of characters, an arbitrary start word (axiom) over characters from the alphabetand a set of production rules or productions that replace a character by a string. L-systems were first introduced in 1968 as a means to model the development of filamen-tous organisms. What distinguishes an L-system from other formal grammars is thatthe production rules are executed in parallel. This is motivated by the plant domain,since all parts of a plant also grow in parallel. The basic L-system formalism suffersfrom several shortcomings. For example, local context is restricted to a fixed length, thenumber of relations between components is restricted, there can only be relations be-tween components represented by neighboring characters in the string, or the fact that a

Towards an Automated 3D Reconstruction of Plant Architecture 53

one-dimensional string is no well suited representation of three-dimensional, branchedplant structures. Some of the shortcomings were eliminated by extensions, like parame-terized L-systems, stochastic L-systems or table L-systems [16]. But disadvantages likethe limited number of relations or the unsuited representation as a string remain sincethey are inherent in L-systems.

Therefore we opt for a grammar based functional-structural plant modeling, namelyRelational Growth Grammars (RGGs) [8,9], that meets most of the disadvantages ofL-systems. A Relational Growth Grammar is a parallel graph transformation system,meaning that, as in an L-system the productions are applied in parallel, only they areapplied to graphs rather than strings. This has several benefits for plant modeling ingeneral and for our purposes in particular. Arbitrary relations between arbitrary plantparts can be modeled as labeled edges of the graph, whereas the nodes may be arbitrarycomponents of plants. Furthermore, whole sets of subgraphs can be rewritten with asingle production rule, as opposed to replacing a single character with a string. Otheradvantages are that branches are directly represented, that the context of a rule is notlimited in size or location and that therefore local as well as global sensitivity can bemodeled. Since strings can be seen as a graph with a linear sequence of nodes (one nodefor each character in the string), RGGs can be interpreted as a superset of L-systems,meaning that with the RGG formalism one can mimic every L-system, but has evenmore descriptive power.

With this formalism we can directly include the semantic annotations as well as therelations within our model. For example, a frustum (part of a stem skeleton) can beconnected to a sphere (berry) via a attached to relation, or it can be connected to asphere that forms a joint via a connected to relation. The relations can also be used forthe creation of a cohesive volume of the generated structure, see Sect. 4.3.

The remainder of this article is organized as follows. In Sect. 2 we introduce anoverview of related work regarding the modeling and reconstruction (of plants) andresearch on grapevines. Section 3 gives an introductory overview of the approach fol-lowed by Sect. 4, which gives a summary of what is already achieved and what is cur-rently being implemented. The article is closed with Sect. 5, that concludes and showswhat we are planning for the future of the project.

2 Related Work

Besides L-Systems and RGGs there are the so-called Shape Grammars [20]. Similar toL-systems and RGGs, Shape Grammars have an initial shape and a set of replacementrules that operate on parts of a given shape and replace such a part with a new shape.A difference is that the rule execution does not happen in parallel. On the basis ofShape Grammars Muller et al. [14] developed CGA shape, a Shape Grammar for theprocedural modeling of building shells. Ganster and Klein [5] developed an integratedenvironment and a visual language for the procedural modeling with the aim to ease thedevelopment of models.

Regarding the sensing of objects, Schnabel et al. [17] consider cases where objectscan only be sensed in a way that the sensor data contain holes in the objects. At firstthe input point cloud is approximated by primitive shapes (planes, spheres, cylinders,


cones, tori). Then, these primitives are used as a guidance to complete unsensed areasand form a complete structure. This approach is limited to situations, where primitiveshave been detected in the vicinity of holes, whereas our approach is more general andis able to approximately fill parts that are not represented in the sensor data by help ofthe domain knowledge. For example, in a bunch of grapes we can argue that, dependingon the cultivar, the number of reconstructed berries and the sensed size of the bunch,we can expect n more berries that are occluded by the outer berries and we could evenapproximate their location.

There are other approaches that especially concentrate on the 3D reconstruction ofplants. For example, in [1] a method is introduced which also uses some kind of domainknowledge of trees to guide the reconstruction process within three-dimensional laserrange data. Their aim is to provide information for the creation of computer models oftree function. In this approach, a single branch consists of a set of fixed-length segments(cylinders) and two angles to its parent. The angles and the radius of a segment aredrawn according to certain probability distributions. Also, they use data of structurallysimple trees. We do not use fixed length but rather variable length segments dependingon the sensor data. Additionally, we are currently gathering knowledge about grapevinecultivars in order to model the plant’s architecture more precisely. Moreover, an RGGis capable of modeling the functional as well as the structural dimensions of a plantat the same time and within the same model, rendering the separate functional modelunneeded.

In [19] L-systems are used as one step in the reconstruction of foliaged trees basedon image data. They segment each image of one tree into tree and background, and con-struct a skeleton of the tree with only a few branching levels. This skeleton is used as theaxiom of an L-system which is then used to generatively add higher order branchingsand leaves. They do not leverage the fact that such a grammar can be used as a guidancefor the reconstruction.

There is also current research on the modeling and reconstruction of grapevines fol-lowing different approaches. Keightley and Bawden introduced a method for the volu-metric modeling of grapevine biomass [7]. On the basis of three-dimensional laser scanpoint clouds they estimate the volume of grapevine trunks and compare their estimateswith the values gathered by submerging the trunks in water and measuring the overflow-ing water. The trunks were placed on a turntable and scanned at ten specific angles froma distance of 8.5 m. They concentrate on the scanning itself and how different scans canbe combined. In our approach the biomass is only one of several phenotypical featuresto be determined and therefore only a part of the overall goal.

In [15] a stochastic growth model of grapevine is introduced concentrating on howthe plant develops in dependance of the trophic relationships between plant parts andwater depletion. Louarn et al. [13] model the canopy structure of grapevines and usethis in [12] to analyze the influence of trellis systems and shoot positioning on thecanopy structure and light interception. A former investigation of the development ofthe architecture of inflorescences (early state of a bunch) and bunches was performed by[18]. They analyzed four grapevine cultivars for phenotypical features that contributeto differences in bunch compactness.


3 Overview of the Approach

3.1 General Overview

In the fields of data interpretation and 3D reconstruction the goal is to find a hypothesisthat in some way best explains the given data. Usually there is a huge, or even infinitenumber of possible hypotheses. Therefore one has to find a way to generate hypotheses,prune the space of all hypotheses, and select hypotheses in a smart way.

For the generation of hypotheses and the pruning of the hypthesis space we use theaforementioned Relational Growth Grammar formalism. Hypothesis generation occursthrough execution of the production rules. The pruning takes effect through the factthat the productions determine where components are allowed, thus incorporating ge-ometric constraints. Additionally, they also give semantic constraints, e.g., a berry isonly allowed at the end of a twig, not in between. Both kinds of constraints are directlyencoded into the productions.

We use Reversible Jump Markov Chain Monte Carlo (RJMCMC) [6] sampling forthe selection of hypotheses. With this approach we can, within one cohesive framework,select a proper model to interpret the data as well as optimize the parameters of theselected model.

Figure 2 shows an overview of the components of the reconstruction algorithm anda resulting structure. Interpretation of the sensor data is done by optimizing a model-based interpretation that relies on the rules of the RGG. Optimization is done by theRJMCMC-sampling of the hypothesis space. The sampler selects the best generatedresult. For the sake of clarity, the semantic annotations are not shown in the image.

RGGModel

RJMCMCSampler

. . .

Fig. 2. Components of the reconstruction algorithm and its result. The RGG model generatesseveral reconstruction hypotheses according to the replacement rules. The sampler evaluates themwith regards to the sensor data and chooses the best one. The annotations are not shown for thesake of clarity.


3.2 Sensor Data

As sensor data we use three-dimensional point clouds. The point clouds are generatedby an ultrahigh precision laser rangefinder Perceptron ScanWorks V5 mounted onto aRomer Infinite 2.0 articulated arm. The rangefinder produces line scans of 7640 pointsper line at a frequency of 60 Hz and an average point to point resolution of 0.0137 mm.By moving the scanner around the software provided by the vendor accumulates theline scans into one single coordinate frame according to the joint angles of the arm. Theresult is a three-dimensional point cloud. Figure 3 shows three sample point clouds ofthe stem skeletons of different cultivars.

(a) (b) (c)

Fig. 3. Sample point clouds of three stem skeletons of different cultivars

3.3 Domain Knowledge

For the interpretation of the sensor data we use a Relational Growth Grammar based ondomain knowledge. Rules and parameters of the stem skeleton are derived by measur-ing the topological skeletons of the corresponding point clouds of the training set. Foran overview of properties of skeletonization algorithms see [3]. We currently use the”SkelTre” algorithm by Bucksch [2]. This algorithm organizes the given point cloudby an octree and constructs an initial graph structure over that octree. It then iterativelysimplifies the initial graph by finding special node configurations within it, the so-calledE-pairs and V-pairs, until no more such pairs can be found. An example of a point cloudand its topological skeleton can be seen in Fig. 4. From the final topological skeletonwe then extract features like the lengths of internodes, the angles of internodes to theirpreceeding internode, or the branching depth of a node. All the gathered data are thenstored in a database.

3.4 Modeling with Relational Growth Grammars

As a software tool for the implementation of RGGs we use GroIMP, which was de-veloped alongside the RGG formalism and is available as an open source distribution.It is furthermore easily extensible through a simple plugin interface. GroIMP offers auser-adjustable interface (see Fig. 5 for a screenshot), a text editor with syntax high-lighting and different modes for visualization like a wireframe visualization, raytracerbased and hardware accelerated OpenGL visualization. GroIMP can read and/or write


Fig. 4. A point cloud and its topological skeleton

a wide range of file formats. It allows direct access to the data structure enabling theuser to inspect current values of parameters of nodes in the graph or even to deleteparts of the graph. For a plant modeler this is useful, for example, for an analysis ofthe plant’s behavior in the next development steps. Furthermore, it introduces XL (eX-tended L-systems) as the programming language for implementing RGGs, which is anextension of the well known Java programming language. Therefore nodes in the graphare objects in the sense of Object Oriented Programming.

Fig. 5. A screenshot of GroIMP. The interface consists of different, user-adjustable parts. Hereone can see a text editor for the grammar code in the upper right. The lower right part shows apart of the current graph. The upper left shows a 3D visualization of the nodes in the graph thatcorrespond to drawable components. The lower left shows a list of files contained in the project.

In general, the structure of an RGG production looks as follows:

(∗C∗), L, (E) ==> R {P};

C is the context of the rule and L is to be replaced by R. All of those are sets of graphs.E is a set of logical expressions as a condition for the execution of the rule and P is


procedural code. An example RGG (taken from GroIMP) implemented in XL looks asfollows:

protected void init() [

Axiom ==> A(1);

]

public void run() [

A(x) ==> F(x)[RU(30) RH(90) A(x*0.8)]

[RU(-30) RH(90) A(x*0.8)];

]

Where the init() method implements the initial structure and the run() method a devel-opmental production. A is a green sphere of fixed size, F is a cylinder of fixed radiusand variable length, and RH and RU are rotations about the local z- and y-axis, respec-tively. The bracket characters [ and ] introduce branches in the graph. Figure 6 showsthe result after five executions of the run() method.

Fig. 6. Result of the simple example RGG after five iterations

A rule with context and an additional Boolean condition might look as follows:

(* x:Node *), B, (x instanceof A) ==> F(5) B;

This rule says that a node of type B is only to be replaced by an F node and a new Bnode, if somewhere in the graph there is a node of type A. The rule is applicable to theleft graph in Fig. 7 but not to the right one. In contrast to the fixed length contexts ofL-systems, this RGG rule is applicable no matter how many nodes there are on the pathfrom B to the A node and they do not even have to be on the same path.

Besides standard replacing rules, XL allows a second kind of rule: execution rules.Those are identified by a ::> arrow and are often used to alter the values of parametersof nodes without replacing them, e.g.,

f:Factor <-encodes- g:Gene(gc) ::>

f[concentration] :+=

Math.max(0,

sum(((*Factor(ca,)-Activates(s,m)->g*),

m * ca / (s + ca))) + gc);


RootC

C

A

C

B

C(a)

RootC

C

C

B

C(b)

Fig. 7. The production rule (* x:Node *), B, (x instanceof A) ==> F(5) B; is only applicable tothe left graph, not to the right one

This rule (taken from a GroIMP example) searches for all pairs of nodes of typesFactor and Gene, where there is an edge with label encodes from the Gene-Nodeto the Factor-Node and assigns identifiers f and g, respectively. It then updates theconcentration parameter of Node f by calling the standard max method of the JavaProgramming Language. Execution rules are useful when only the functional part of aplant (like photosynthesis or the flow of nutrients) has to be updated but not its structure.

This example also demonstrates how arbitrary relations can be used. In the examplea gene regulatory network is constructed and the Activates(,) relation, which is a JavaClass, is used to determine how much a Gene is activated or repressed by a Factor.

3.5 Reconstruction

As stated, the main challenge is that in reconstruction we have a possibly inifinite num-ber of possible hypotheses to interpret the sensor data. Our two main ingredients forsolving the problem are the Reversible Jump Markov Chain Monte Carlo (RJMCMC)sampler on the one hand and the RGG model on the other.

The basic Markov Chain Monte Carlo (MCMC) sampler works by performing so-called jumps within a space of hypotheses, where each hypothesis has the same size,i.e., number of parameters. A jump generates a new hypothesis on the basis of the cur-rent one. MCMC therefore samples from the probability distribution over all possiblehypotheses by simulating a Markov Chain. But this is not powerful enough for our pur-poses, since the number of parameters of different hypotheses can vary largely. For suchcases Green developed the RJMCMC sampler [6]. This method allows jumps betweendifferent hypothesis spaces, where the hypotheses have the same size within one spacebut differ in size between spaces. In other words, the sampler jumps within the unionof all the spaces. An important property of the jumps is that they have to be reversible,i.e., it has to be possible to jump back to earlier states from any given later state. Oncea hypothesis is generated it has to be evaluated and decided if it is put into the chain orif it is rejected. If it is accepted the hypothesis is the basis for the hypothesis in the nextiteration. Otherwise it is discarded and the next hypothesis is constructed on the basisof the old one.

To make sure, that the reconstruction terminates, i.e., the sampler stops jumping inthe hypothesis space, we incorporate Simulated Annealing. There one has a temperature


that starts at a high value and is decreased during the process. Jumps are chosen relativeto the temperature and stop at a given low temperature

As stated before, the RGG model gives geometric and semantic constraints on thestructure. Through the parameters of the components it also is a compact representationof all possible (at least as far as the model allows) exemplars of a certain cultivar. Onthe other hand a specific value-to-parameter assignment relates to a certain exemplar.

Applied to our task at hand the interplay between sampler, model, and data turnsout to be as follows. At iteration t of the algorithm, the sampler randomly choosesa jump that is to be performed next, dependent on the current temperature. Each jumpcorresponds to one replacement rule in the RGG model and that rule is then executed onthe hypothesis ht−1, resulting in a new hypothesis ht . Now, ht is evaluated with respectto the data. If it is accepted, ht is the basis for the next iteration, otherwise ht is set toht−1. After an update of the temperature this process is repeated until the temperaturefalls below a threshold value.

We propose a list of jump/RGG-rule pairs as follows, where frustums are used tomodel the twigs of the stem skeleton (see Sect. 4.2).

1. Parameter update: Simply changes a randomly chosen parameter of a randomlychosen component.

2. Add branch: Adds a completely new branch to the object. The model defines whereand how branches may be added.

3. Delete branch: Deletes one already existing branch.4. Edit branch: Changes the number of twigs at a branch by adding or deleting twigs.5. Split frustum: Splits one frustum into two and inserts a sphere in between, to acco-

modate to the curvature of the object under consideration.6. Merge frustums: Merges two frustums that are connected via a sphere to a single

frustum.

Figure 8 shows a sketch of the reconstruction process. It starts with an initial struc-ture at the initial temperature T0. At first the topology is changed by adding / deletingbranches, resulting in the second depicted hypothesis. In the following further topologychanges and parameter updates occur resulting in the last depcited hypothesis at thefinal temperature Tf inal .

Fig. 8. Sketch of the reconstruction process: At first mostly topology changes occur, at lowertemperatures mostly parameter updates are carried out


4 First Results and Current Developments

4.1 Acquired Data

For a first data acquisition we laser scanned a total of 25 stem skeletons from five differ-ent cultivars. This is already sufficient for evaluating a first approach to reconstruction.We first rely on sensor data gathered in controlled situations. Later we will switch to”real” data gathered in the field.

Additional to the laser scanning we also perform the skeletonization measurementsdescribed in Sect. 3.3 and collect all those information in a database.

The reason why we chose stem skeletons for a first data acquisition is that if we wantto reconstruct the architecture of a bunch of grapes, stem skeletons are exactly this.Besides, in order to find the berries in the sensor data it is useful to have knowledgeabout where to expect them. This is exactly what a stem skeleton can tell us.

4.2 Modeling Stem Skeletons

The most basic approach to modeling stem skeletons is to use cylinders for the twigsor parts of twigs. For long twigs one could use a chain of cylinders with decreasing ra-dius. An example of this approach can be seen in Fig. 9(a). This rather simple examplealready shows the shortcomings of that approach. There are sharp crossovers as well asgaps between cylinders. To generate a more realistic look one could constrain the lengthof a cylinder, resulting in a greater number of cylinders and therefore an increased com-putation time since more cylinders have to be handled. We therefore follow a differentapproach. This uses frustums instead of cylinders to cope with the sharp crossovers onthe one hand and fills gaps with additional spheres on the other. Figure 9(b) shows thesame example as before but with the more advanced modeling approach. As can be seenthis generates a much more realistic look. But not only the appearance is more realistic,this model also is a more precise structural representation of the plant architecture.

(a) (b)

Fig. 9. This figure shows in a simplified example the effects of two different modeling approaches.Left: Chain of cylinders of decreasing radius. Right: Frustums with spheres at intersections. Ob-viously, the frustum-based approach generates a more realistic look.


The model presented here is still a prototype and has to be extended to capture thefull structure of stem skeletons. Additionally the domain knowledge generated by theskeletonization (Sect. 3.3) has to be incorporated. Also, this model does not result in aphotorealistic rendering of the plant but a more simplistic one, but this is no concern,since we aim at a precise structural representation of the plant architecture for derivingphenotypic features.

4.3 Volume Generation

As stated before we want to derive phenotypical features from the reconstructed geo-metrical structure. So far we only have a set of intersecting geometric primitives, not”real” objects. Especially we have frustums that intersect those spheres that are regardedas berries and we have frustums that intersect spheres at joints. Therefore we have tocombine primitives to complex objects on the one hand and remove intersecting vol-umes on the other. This gives rise to two challenges: (1) We must be able to performsuch operations on the primitives, (2) we must be able to detect, when to apply whichoperation.

One solution for challenge (1) are the well known Boolean operations union, inter-section and difference. Since GroIMP does not yet fully support those operations we hadto implement them. The Boolean operations take as input sets of triangles describingthe surface of the primitives and return a set of triangles describing the surface of thecomplex object. Figure 10(a) shows an example of a joint consisting of two frustumsand one sphere. Figure 10(b) depicts the union of the three primitives.

(a) (b)

Fig. 10. Application of Boolean operations. (a) shows a joint with two frustums and one sphereand (b) its union.

For a solution to challenge (2), we can use the relations that we employ in the RGGmodel of the plant. Those relations can not only tell which components are connectedand how, but also what Boolean operation should be performed on the connected com-ponents. For example, the relation connected to for a frustum and a joining sphere cantell us that those two primitives should be unified. In contrast, the relation attached tofor a frustum and a sphere (a ”berry sphere”) tells us that we have to subtract the inter-section of the two primitives from the sphere to get the correct volume of the berry.


Challenge (1) has been solved by implementing the needed Boolean operations while(2) still has to be incorporated into the RGG model and then into the Boolean operations.


We have presented the concept of a 3D reconstruction approach of plant architecturebased on the interpretation of three-dimensional laser scan point clouds. Our main ideais to use an intelligent sampling method and to constrain the space of all hypothesesby incorporating domain knowledge. As a sampler we use the Reversible Jump MarkovChain Monte Carlo method and for the modeling we rely on Relational Growth Gram-mars. As an example, we investigate stem skeletons of grapevine bunches. Furthermore,we will derive phenotypical features based on the reconstruction of the plants. In thedomain of grapevine breeding this can, for example, be used to detect whether a newlybred cultivar shows a susceptibility to diseases like Botrytis cinerea.

For the future of this project we are planning several enhancements. For example, wewant to broaden the input by using semantic surface meshes. The surface representa-tion is based on a triangulation, generated from laser scan point clouds or point cloudscreated by stereo images. Then, the surface is augmented with semantic informationfrom an image segmentation method leading to a semantic surface mesh. Additionalto the knowledge modeled as an RGG this gives us further geometric and semanticconstraints.

A further goal is the implementation of anaylsis tools for the structures generated bythe grammar, like the total weight of a bunch or its compactness.

For the more distant future we aim at a general approach for the reconstruction ofarbitrary grapevine cultivars and all of their parts, not only the bunches. Based on this,the aim is a general reconstruction approach for arbitrary plants.

Acknowledgements. This work was largely done within the sub-project D2 ”Inter-preted Plant Architecture” as part of CROP.SENSe.net, the German network of com-petence for phenotyping science in plant breeding and crop management. We thankthe Federal Ministry of Science and Research (BMBF) and the European RegionalDevelopment Fund (ERDF) for funding. We thank all partners of sub-project D2 forworthful discussions. Especially, we thank Reinhard Topfer and Katja Herzog fromthe Julius-Kuhn-Institute, Siebeldingen, Germany for providing the stem skeletons. Wethank Heiner Kuhlmann and Stefan Paulus from the Department of Geodesy of theUniversity of Bonn, Germany for generating the laser rangefinder measurements.

References

1. Binney, J., Sukhatme, G.S.: 3D tree reconstruction from laser range data. In: InternationalConference on Robotics and Automation, pp. 1321–1326. IEEE (2009)

2. Bucksch, A.K.: Revealing the Skeleton from Imperfect Point Clouds. Ph.D. thesis, DelftUniversity of Technology (2011)

3. Cornea, N., Silver, D., Min, P.: Curve–skeleton properties, applications, and algorithms.IEEE Transactions on Visualization and Computer Graphics 13(3), 530–548 (2007)


4. CROP.SENSe.net, http://www.cropsense.uni-bonn.de/5. Ganster, B., Klein, R.: An integrated framework for procedural modeling. In: Spring Confer-

ence on Computer Graphics, pp. 150–157. Comenius University, Bratislava (2007)6. Green, P.J.: Reversible jump Markov chain Monte Carlo computation and Bayesian model

determination. Biometrika 82(4), 711–732 (1995)7. Keightley, K.E., Bawden, G.W.: 3D volumetric modeling of grapevine biomass using Tripod

LiDAR. Computers and Electronics in Agriculture 74(2), 305–312 (2010)8. Kniemeyer, O.: Design and Implementation of a Graph Grammar Based Language for

Functional-Structural Plant Modelling. Ph.D. thesis, Technical University Cottbus (2008)9. Kurth, W., Kniemeyer, O., Buck-Sorlin, G.: Relational Growth Grammars – A Graph Rewrit-

ing Approach to Dynamical Systems with a Dynamical Structure. In: Banatre, J.-P., Fradet,P., Giavitto, J.-L., Michel, O. (eds.) UPP 2004. LNCS, vol. 3566, pp. 56–72. Springer, Hei-delberg (2005)

10. Lindenmayer, A.: Mathematical models for cellular interactions in development I. Filamentswith one-sided inputs. Journal of Theoretical Biology 18(3), 280–299 (1968)

11. Lindenmayer, A.: Mathematical models for cellular interactions in development II. Simpleand branching filaments with two-sided inputs. Journal of Theoretical Biology 18(3), 300–315 (1968)

12. Louarn, G., Dauzat, J., Lecoeur, J., Lebon, E.: Influence of trellis system and shoot position-ing on light interception and distribution in two grapevine cultivars with different architec-tures: An original approach based on 3D canopy modelling. Australian Journal of Grape andWine Research 14(3), 143–152 (2008)

13. Louarn, G., Lecoeur, J., Lebon, E.: A three-dimensional statistical reconstruction model ofgrapevine (Vitis vinifera) simulating canopy structure variability within and between culti-var/training system pairs. Annals of Botany 101(8), 1167–1184 (2008)

14. Muller, P., Wonka, P., Haegler, S., Ulmer, A., Van Gool, L.: Procedural modeling of buildings.ACM Transactions on Graphics 25(3), 614–623 (2006)

15. Pallas, B., Loi, C., Christophe, A., Cournede, P.H., Lecoeur, J.: A stochastic growth modelof grapevine with full interaction between environment, trophic competition and plant devel-opment. In: International Symposium on Plant Growth Modeling, Simulation, Visualizationand Applications, pp. 95–102. IEEE (2009)

16. Prusinkiewicz, P., Lindenmayer, A.: The Algorithmic Beauty of Plants. Springer (1990)17. Schnabel, R., Degener, P., Klein, R.: Completion and reconstruction with primitive shapes.

Eurographics 28(2), 503–512 (2009)18. Shavrukov, Y.N., Dry, I.B., Thomas, M.R.: Inflorescence and bunch architecture development

in Vitis vinifera L. Australian Journal of Grape and Wine Research 10(2), 116–124 (2004)19. Shlyakhter, I., Rozenoer, M., Dorsey, J., Teller, S.: Reconstructing 3D tree models from in-

strumented photographs. IEEE Computer Graphics and Applications 21, 53–61 (2001)20. Stiny, G., Gips, J.: Shape grammars and the generative specification of painting and sculpture.

In: The Best Computer Papers of 1971, pp. 125–135. Auerbach Publications (1972)21. Weihl, T.: Ein Identifikationsverfahren fur Rebsorten. Ph.D. thesis, Universitat Hohenheim

(1999)

http://www.cropsense.uni-bonn.de/

Generating Graph Transformation Rules

from AML/GT State Machine Diagramsfor Building Animated Model Editors

Torsten Strobl and Mark Minas

Universitat der Bundeswehr Munchen, Germany{Torsten.Strobl,Mark.Minas}@unibw.de

Abstract. Editing environments which feature animated illustrations ofmodel changes facilitate and simplify the comprehension of dynamic sys-tems. Graphs are well suited for representing static models andsystems, and graph transformations are the obvious choice for imple-menting model changes and dynamic aspects. In previous work, we havedevised the Animation Modeling Language (AML) as a modeling ap-proach on a higher level. However, AML-based specification could not yetbe translated into an implementation automatically. This paper presentsa language extension called AML/GT and outlines how AML/GT mod-els can be translated into graph transformation rules automatically andalso provides some implementation details.

1 Introduction

Visual models are considered to be important tools of software development.Particularly, the area of domain-specific languages (DSLs) is an interesting topicfor research and industry. Therefore, some tools like GenGEd [3], AToM 3 [6] orDiaGen/DiaMeta [8] support the creation of editors for DSLs with little effort.For this purpose, many of these tools generate editors out of mostly text-basededitor specifications and use graphs for representing models internally, togetherwith graph transformations (GTs) for changing them.

However, visual models are not restricted to static structures. They can alsocontain execution semantics, for instance the popular example of Petri nets.Editors for such models usually support animated simulations.

This paper continues our work extending the DiaMeta toolkit in order to facil-itate the implementation of editors for complex animated models and languageswith preferably minimal effort. Our first step was to allow the specification ofevent-based model changes through graph transformation rules (GTRs) [15]. It isbased on the idea of a static graph representing an animated model that changeswhile time passes by. Graph transformations happen instantaneously, and theycan be used for starting, stopping or modifying animations, whereas other ap-proaches (e.g., GenGEd [3]) represent animations by graph transformations thatdo not happen instantaneously, but last as long as the animation takes.

Case studies showed that such GTR-based specifications are yet too unstruc-tured for a convenient specification of animated systems. Therefore, in a second


66 T. Strobl and M. Minas

Fig. 1. Avalanche board Fig. 2. Avalanche pieces

step, the modeling language AML (Animation Modeling Language) has beenintroduced for supporting structured design and specification of animated sys-tems [16]. The language offers, among other features, the behavioral specificationof individual components and a convenient way for describing animations forparticular states. In that way, AML is a helpful tool for creating editor specifica-tions manually, but it was not yet possible to automatically generate GTR-basedspecifications from AML-based specifications. This paper closes this gap and in-troduces AML/GT as an extension of AML as well as a tool that automaticallytransforms an AML/GT-based specification into a GTR-based specification forDiaMeta which can then be used to generate the implementation of the animatedsystem. As a running example, an editor called Avalanche is created.

The rest of the paper is structured as follows: Section 2 outlines the runningexample Avalanche. Section 3 describes how animated editors can be realizedwith DiaMeta in short. AML is revisited in Section 4 and its extension AML/GTis introduced in Section 5. The translation of AML/GT state machines intoGTRs is elaborated in Section 6. Section 7 gives some implementation details.Finally, Section 8 shows related work, and Section 9 concludes the paper.

2 Avalanche

This section sketches Avalanche (see Fig. 1) which has been implemented as amodel editor and serves as example throughout this paper. Although Avalanche

is based on a board game, gaming aspects are ignored and it is treated as aninteractive dynamic system. A detailed view on Avalanche and its implementa-tion using DiaMeta is presented in [15]. In addition, an animated example canbe found online.1

In Avalanche marbles are falling down the lanes of an inclined board. Theboard itself can be built by four types of block pieces (see Fig. 2). The top

1 http://www.unibw.de/inf2/DiaGen/animated

http://www.unibw.de/inf2/DiaGen/animated

Generating GTRs from AML/GT State Machine Diagrams 67

Fig. 3. Avalanche board and corresponding hypergraph

of each lane is limited by a Start piece. A Marble can be placed there, andit starts falling as shown in Fig. 1 (a) then. While falling, the Marble can bestopped by the upper side of a Switch (b). On the other hand, if a Marble hitsthe bottom side (c), a Switch is tilted to the neighboring lane. In this case, apreviously stopped Marble can be released (d). It is also possible that a Marblehits another Marble, which is currently blocked by a Switch. Then, the fallingMarble bounces off and changes its lane (e). Finally, a Marble can reach an Endpiece where it is removed from the board (f).

3 Specification of Animated Model Editors

Avalanche shall be implemented as animated model editor which allows thecreation of individual boards (e.g., the board in Fig. 3). The user can put marblesin Start pieces. Afterwards, they start falling, and the animated model showsthe game mechanics. Important aspects are the interaction between marblesand switches and that new marbles can arrive at any time, for example. Thecode for the Avalanche editor shall be generated from a specification for theDiaMeta system. Therefore, this section introduces some basics of DiaMeta andthe applied generation process.

Internally, models of DiaMeta based editors are represented by typed, at-tributed hypergraphs. DiaMeta supports three types of (hyper)edges in suchhypergraphs. Component hyperedges represent model components. Theseedges visit nodes that represent the component’s attachment areas. Such ar-eas may be spatially related, e.g., overlap, which is represented by so-calledrelation edges between the corresponding nodes. Relation edges are created orremoved automatically whenever attachment areas of components start or endbeing spatially related [8]. Finally, link hyperedges can be used for connect-ing nodes of component hyperedges. Such edges can be created and removedexplicitly.


In Fig. 3 an Avalanche board is shown together with its internal hypergraph.Because of such underlying graphs, it is possible to specify model changes viaGTs. Our approach of implementing animated editors is also based on GTs, so abrief description follows. A detailed elaboration, however, can be found in [15],which also includes the underlying formalism.

The internal graph does not necessarily represent a static model. Instead,a constant graph may describe how visible components are animated, e.g.,by determining where, when and how a component started moving. Then, thevisualization of the graph can involve the current animation time for illustratingan animated scene. The hypergraph in Fig. 3 actually shows a marble withappended startedAt edge, which stands for a currently falling marble during thevisualization of the model.

Besides such (graphical) animations, there are also time-dependent modelchanges caused by GTs. These GTs are the result of internal and externalevents. External events are sent to the system from an external source, e.g.,from a user sending a command to the editor, whereas the occurrence of in-ternal events is based on the system state. Such events are specified (andimplemented) by GTRs, or rather graph transformation programs in DiaMeta.They are equipped with application conditions to trigger them when externalevents happen, or with a time calculation rule (TCR) that computes thetime when the internal event occurs. This calculation usually depends on theattribute values of the related components.

However, the behavior of the Avalanche editor is not specified directly viaGTRs and event details as described above in this paper. Instead, the modelinglanguage AML/GT (see Sections 4 and 5) is used and GTRs will be generated.

4 Animation Modeling Language (AML)

The presented specification approach comes along with the Animation ModelingLanguage (AML). This section provides an overview focused on aspects relevantfor this paper. Some more details, origin, and goals of AML are presented in [16].

AML models describe both the structure and relations of graphical compo-nents and their dynamic behavior including animations. The language is basedon UML 2.3 [11]. AML refines UML class diagrams for the static structure andUML state machine diagrams for the dynamic part (see Fig. 4).

The following extensions are available for the static structure:

– Media Components are the main structural element of AML. They extendregular UML classes by aspects of visual components. They always includebasic attributes like xPos, yPos, angle and other attributes which determinespatial aspects or drawing state.

– Inner Properties are similar to UML properties, but their specified typemust be a media component. In addition, they can be arranged hierarchically.In this way, inner properties can model the compositions of graphical subelements within their containing media components.


Fig. 4. AML metamodel (excerpt)

– Sensors are owned by media components and observe states, animationsand interactions of its owner.

The three most important kinds of sensors are:

– User Sensors are triggered if the user interacts with the sensor owner in aspecific way, e.g., if the user clicks on a component.

– Constraint Sensors are triggered if its guard expression (by default anOCL expression [10]) evaluates to true, which may also happen during ananimated situation. Collision Sensors are a special subtype of constraintsensors. They can observe when the owner collides with another component,called opponent.

– Message Sensors are enabled if the sensor’s owner receives a message of adeclared type from another component, called opponent, too.

Fig. 5 shows an AML/GT model, i.e., an AML model with GT extensions de-scribed in the next section, but it illustrates plain AML elements, too. The innerproperty lever 2 ,2 e.g., represents the graphical lever within the media compo-nent Switch 1 which represents the whole board piece. It is also shown how thedefault value of the lever ’s attribute angle is redefined there. The user sensorPutMarble 3 is triggered if the user clicks on a Start component, which is thesensor owner 4 indicated by the solid line. The collision sensor MarbleEnd 5 istriggered if its owner Marble collides with the bottom of an End piece, which isconnected via a dashed opponent arrow 6 .

Behavior and animations of media components are described by state ma-chine diagrams and their regions 8 . Each state machine models the states andtransitions of components of one media component type.

For the description of graphical animations, AML supports special statescalled animation states 9 that contain so-called animation instructions 10 .Each animation instruction computes the value of an attribute of the state ma-chine’s media component while time passes by. E.g., animation instruction 10

defines that the angle of a Switch lever changes from −30◦ to 30◦ within threeseconds as soon as the Switch enters state LeftRight .

2 Numbers in black circles refer to the ones in Fig. 5.


Transitions can be labeled like in regular UML by trigger[guard]/effect. Thetrigger describes an event that may cause the transition. Intuitive keywordslike at or after 11 indicate certain points in time or time delays. AML alsosupports sensor triggers specified by the name of the sensor 12 that must beowned by the state machine’s component. The transition is enabled when theassociated sensor is triggered. Finally, transitions without trigger specification 13

are triggered as soon as the state’s internal activities (e.g., active animationinstructions) terminate (completion event).

A guard may restrict transition triggers; a transition is only enabled if theguard condition is satisfied, too, like in UML.

In AML, effects as well as entry and exit behaviors of states are restrictedto so-called action sequences consisting of an arbitrary series of the followingactions:

– Set actions 14 can change an attribute of the corresponding component orone of its inner properties.

– Create actions 15 allow the creation of media components.– Call actions 16 are used for calling operations.– Send actions can send messages to other media components.

The execution of transitions is performed sequentially. Since a system withdiscrete time model may have multiple enabled transitions at the same time andthe UML specification does not define full semantics of conflicting transitions,enabled AML transitions are executed with the following priority, starting withthe highest one: sensor events, time events, without trigger/with guard, withouttrigger/without guard. In addition, each sensor can have an explicitly specifiednumeric priority value. Such values must be used to order a set of simultaneouslyoccurring sensor events. If there are still conflicts, a transition must be chosenrandomly.

5 Animation Modeling Language for GTs (AML/GT)

AML enables developers to model Avalanche and to translate it to a GTR-basedDiaMeta specification manually as described in [16]. For an automated trans-lation, however, AML models lack important information. Therefore, AML hasbeen extended to AML/GT which addresses this issue. Technically, AML/GT isrealized as a (UML) profile for extending AML models. This section describessome of its elements in the context of the Avalanche model shown in Fig. 5.

Some media components represent visual components that the user can placeon the screen using the generated Avalanche editor. They are marked by a smallsquare next to the media component icon, e.g., Switch 1 , and are then repre-sented by component hyperedges (see Section 3). In addition, inner properties ofmedia components can be marked by small circles 17 . Such properties are rep-resented by nodes of this component hyperedge. Inner properties which modelgraphical aspects of the component are marked by a small eye 2 .


Fig. 5. Avalanche specification (AML/GT model)

A Switch hyperedge, for example, visits the nodes topL, topR, bottomL andbottomR which represent the four corners of the corresponding component. Thetypes of these nodes are TS (“top/switch”) or B (“bottom”), resp., as speci-fied in Fig 5 1 . Fig. 5 also shows how attributes of the inner property’s mediacomponent type are redefined by new default values 2 .

Moreover, associations between media components can be interpreted as edgetypes which can be used to connect the nodes of component hyperedges. Asso-ciations corresponding to link hyperedges are marked with stereotype link 18 .


Fig. 6. Exemplary transi-tion for Switch

Fig. 7. GTR for DoSwitch transition

Relation edges indicating spatial relationships between attachment areas of vi-sual components correspond to binary associations with stereotype relation 19 .The specification of such an attachment area is marked by a small square 20 .

6 Translating AML/GT State Machines into GTRs

After the basic introduction of AML/GT, this section shows how AML/GTmodels are translated into GTRs. These GTRs become part of the specificationof the animated editor which is then used by DiaMeta to generate the editor asdescribed in Section 7.

Each AML/GT state machine describes the behavior of a media component,and each of its states corresponds to a subgraph of the animated diagram’s hy-pergraph. It contains the component hyperedge of the media component andsome additional link hyperedges. This subgraph represents the situation whenthe modeled media component is in this state, i.e., such a subgraph, called in-variant pattern in the following, represents an invariant of the state and is vi-sually denoted inside the state box. For example, the state Left in Fig. 6 containsthe link edge switchedTo next to the component hyperedge itself. By connectingnode n1 with node n0 , the edge indicates that the switch’s lever is currentlyblocking the Switch’s left lane. In the same figure, there is also a transition tostate LeftRight . Fig. 7 shows the GTR realizing this state transition.

In order to create the required set of GTRs, the algorithm has to iterate overall transitions with or without triggers (a completion event trigger is assumed inthe latter case). During this process, the triggers have priorities according tothe rules at the end of Section 4. Each GTR of the resulting set can be specifiedwith this priority then. GTs with higher priority can be processed first, if thereis more than one GT scheduled at the same point in time.

The following steps show how single GTRs are created. They are based on theexample in Fig. 8 and its example trigger MarbleChangeLaneLeft 1 . The illus-trated transition is responsible for changing a Marble’s state from Falling toSwitchingLane, i.e., the Marble has to move to another lane because it has hitthe left side of a Switch which is currently blocked by anotherMarble. The graph


Fig. 8. Generating a GTR from a state machine transition

pattern shown within the collision sensor MarbleChangeLaneLeft represents thiscondition.

The LHS of the rule is created first. It consists of the invariant pattern ofthe transition’s source state, extended by subgraphs of the transition’s guard(e.g., Fig. 5 13 ) as well as graph patterns describing the behavior of sensorsbeing used as transition triggers (e.g., Fig. 5 7 ). In the example shown in Fig. 8,there is no transition guard, but the graph pattern located within collision sensorMarbleChangeLaneLeft has to be added. In general, the LHS is constructed fromseveral graph patterns. Negative application conditions are possible, too, butthey are not required here.

As a basic principle, the creation of the LHS from all these graph patternsis performed by building the union of them and then gluing them in a suit-able way. Gluing is rather straight forward because each of the graph patternsrefers to the same “owner” of the state machine which is represented by its com-ponent hyperedge and its visited nodes. Therefore, the LHS may contain thecomponent hyperedge of its owner only once, i.e., all instances of this hyperedgeand its visited nodes must be glued. Further nodes can be glued as well. In theexample, node s0 of the source state graph pattern must be glued with s0 ofthe pattern within the sensor. This is specified by the correspondence state-ment lhs node s0 := s0 2 . However, because equally labeled nodes are gluedautomatically, such a statement is omitted in Fig. 5.

The RHS of the rule is built in a similar way. It is constructed from theinvariant of the transition’s target state and, again, all graph patterns of thetransition as for the LHS. The latter have to be added, too, because applyingthe rule shall just change the state of the owner’s state machine, i.e., change itsinvariant pattern; the rest of the diagram’s hypergraph must remain unchanged.

The owner’s component hyperedge again determines which edges and nodesmust be glued. The gluing of an additional node is specified by the correspondence


statement rhs node s0 := oa1 2 . The node labeled s0 of state SwitchingLanedoes obviously not correspond to the node with the same label of state Falling;it should rather correspond to the node oa1 representing the switch’s attachmentareawhere themarble is switching to as soon as the specified transition is executed.

The rule must not add or delete any nodes since each node represents anattachment area of a component, and animations do not add or remove mediacomponents (except if created or deleted explicitly; see below). Therefore, nodeswithout correspondence in either LHS or RHS must be added to the other side 3 .

After creating the main parts of the GTR, additional elements must be added,i.e., further application conditions, a TCR necessary for scheduling events, at-tribute changes, and maybe other types of processing.

Further application conditions are usually expressions which check at-tribute values of graph elements. For this, the AML/GT model can containOCL expressions (conditions), or other Boolean expressions (Java) in case ofDiaMeta. Such expressions must be adapted to a syntax which is compatible tothe GT system and added to the GTR accordingly.3

As described above, the source state’s invariant pattern is part of the cor-responding GTR’s LHS. However, just relying on the invariant pattern of thesource state is generally not sufficient as the inv broken trigger shows (see below).Therefore, a state attribute is added to the component hyperedge 5 which ischecked before the rule may be applied 4 . There must be one such attribute foreach UML region because of concurrent and hierarchical states.

Another type of application conditions are path expressions. In Fig. 8, apath expression called pathDown is required 6 . It verifies that the Marble iscurrently falling down the lane which leads through the blocked left side ofthe Switch. In DiaMeta this expression is specified as an arbitrary sequence oftopBottom(0,1), Switch(0,2), Switch(1,3), or Straight(0,1) edges. The numberswithin the parenthesis specify the hyperedge tentacles the path must follow:the first number specifies the ingoing tentacle and the second one specifies theoutgoing tentacle when following the path through the hypergraph.

AML/GT allows specifying actions at different places. They may be spec-ified with each transition; they are executed as soon as the transition fires(e.g., Fig. 5 14 ) or as an action associated with an entry into a state (e.g.,Fig. 5 9 ). Actions are easily translated into GTRs in DiaMeta since it al-lows arbitrary Java code when executing a rule. Call actions result in thecalls of media component operations (generated Java code; e.g., Fig. 5 9 ), andset actions involve the change of attributes of the component hyperedge dur-ing the GT (e.g., Fig. 5 14 ). Finally, create actions can construct components(e.g., Fig. 5 15 ): AML/GT allows declaring component hyperedges (here Marble)including its initial attributes, its nodes, and link edges. These edges and nodesmust be added to the RHS of the GTR, and attributes must be set accordingly.

3 Single graph transformation rules are not sufficient in the following; graph transfor-mation programs are actually needed. However, for simplicity, we still use the term“graph transformation rule” (GTR) instead of “graph transformation program”.


Further actions must be added to each GTR (Fig. 8 7 ). First, the state at-tribute and the state entry time must be updated (such an attribute must beavailable for each region again). And second, the attributes which are consideredanimated during an active animation state must be updated because attributesdo not change their values during animations in our approach (cf. Section 3). In-stead, the changing value is calculated using a formula considering the animationtime. Therefore, an update which applies the last calculated value is required.

A generated GTRs must be executed at a specific point in time which ismodeled by a transition’s trigger. A transition triggered by a user sensor istranslated into a GTR that can be induced by the user in the editor. By default,the GTR is bound to a GUI button starting the GTR if it is applicable. Othersensor triggers require a TCR 8 for scheduling the GT (see Section 3).

Transitions with time event triggers are translated into GTRs representinginternal events with a TCR reflecting the absolute or relative time when theevent may be triggered. Relative time always refers to the state entry time.

Transitions without explicit trigger must be executed as soon as the patternof the LHS can be matched and animations of the source state have been finished(an additional condition). They are translated into GTRs representing internalevents as well. Its TCR must return the point in time when animations havebeen finished. If there is no animation, the GTR must be applied without anytime delay, i.e., the TCR always returns the current time.

Constraint and collision sensors result in internal event specifications, too.They usually check animated attributes (see above). However, generating a cor-responding TCR is not straight forward. For a collision sensor, e.g., a TCR isrequired which calculates the collision time based on the components’ trajecto-ries. Currently, such a TCR has to be provided manually. Using a physics enginemay solve this problem in the future.

Finally, two special cases for generating GTRs from the Avalanche model aredescribed. Termination states are used as the only means to delete compo-nent hyperedges and, therefore, media components. Such states are visualizedas a small X. If a transition ends in a termination state, it is translated into aGTR that removes the corresponding component hyperedge and its nodes, sothe resulting RHS corresponds to the LHS without the component’s edge andits nodes.

Inv broken is an AML/GT keyword that may be used as a transition trigger.It has lowest priority and is fired if the transition’s source state must be leftbecause its invariant pattern is “broken”. This may happen if some link edgesbeing part of the invariant pattern are deleted when some other component andits link edges are deleted due to a user action.

For instance, a Switch may be removed by the user even if a Marble is con-nected to one of its nodes via startedAt (state Falling in Fig. 5 21 ). Becausethe specification in Fig. 5 requires a marble to be connected to the componentwhere it started falling, the Marble would be in an inconsistent state then. Theinv broken trigger is used to represent the fact that the pattern invariant of thecurrent state is suddenly no longer true although the state has not yet been left.


Fig. 9. Overview of the editor generation process

This triggers the state’s inv broken transition and activates its termination statewhich removes the Marble, too.

The translation of such an inv broken transition into a GTR is straight for-ward: The GTR must check the component hyperedge’s state attribute (seeabove) and whether the invariant pattern is violated. The latter is simply repre-sented as a negative context, i.e., the GTR may be applied if the component isin the corresponding state, but its invariant pattern can (no longer) be matched.

In order to support all features of AML/GT state machines, further specialcases must be considered when generating GTRs as well. Namely, compositestates, concurrency and message passing must be processed specifically.These topics are not discussed here, but it is clear that they can be translatedto GTRs, too.

7 Implementation

The translation process outlined in the previous section has been completelyimplemented, also covering those topics that have been omitted here, e.g., com-posite states, orthogonal regions or message passing. It is possible now to spec-ify animated editors (e.g., for Avalanche) using a visual specification tool (theAML/GT editor) and to generate the editor from this specification. This sectionsketches the process, which is outlined in Fig. 9, and some design decisions.

For the creation of AML/GT models, the editor designer uses the AML/GTeditor (see Fig. 10), which has been generated using the DiaMeta toolkit, too.AML/GT models are automatically translated into the specified animated edi-tor. Some Java code of the editor is directly generated from the AML/GT model(“M2T” in Fig. 9). This is necessary for support code which has to be providedmanually when using DiaMeta without AML/GT. The “M2T” transformationhas been realized with Acceleo, a Model-to-Text translation language which isoriented towards the MOFM2T specification of the OMG [9].

The translation process from an AML/GT model into an editor specificationfor DiaMeta (“editor specification” in Fig. 9) as outlined in the previous sec-tion is performed by the “M2M” component in Fig. 9. It uses Eclipse QVTo,which implements the OMG specification of MOF QVT Operational [12],


Fig. 10. Screenshot of the Avalanche editor

a Model-to-Model technology. The target model of this transformation is thenative, XML-oriented DiaMeta specification which also includes the GTRs.

There are several reasons for choosing these technologies instead of using theDiaMeta framework for creating the specification from AML/GTmodels. First ofall, the GT system of DiaMeta has been created for structured editing in editorsand therefore lacks convenient features for complex model transformations. Inaddition, both source (AML/GT) and target model (DiaMeta specification) donot consist of graphs only, but also contain embedded text or must produce Javacode which are less suited for being modeled as graphs. Finally, standardizedlanguages have been favored in order get a more future-proof, general and stabletransformation. The mentioned languages have already been supported by acouple of tools (Eclipse plugins), too.

Besides the AML/GT model, the editor designer has to provide the abstractsyntax4 of the animated visual language, i.e., its meta-model. DiaMeta simplyuses EMF for metamodelling. Any EMF-based tool for specifying Ecore mod-els [14] can be used here. Furthermore, generating TCRs from collision sensorsstill needs manual code (see Section 6), so future solutions require a generic apriori collision detection algorithm.

Finally, the “editor generator” creates the Java code of the animated editorusing the code generator of DiaMeta. The screenshot in Fig. 10 shows the gen-erated Avalanche editor with created Avalanche board and a falling marble.This editor has been generated from the AML/GT model shown in Fig. 5.

8 Related Work

Although it has not been the primary intention of AML/GT, it can be consideredas a visual language for programmed graph rewriting and model transformation.A good starting point for reading into this topic is provided in [4], which com-pares AGG, Fujaba, and PROGRES as graph transformation languages andalso mentions GReAT . Another overview is presented in [18] which focuses

4 All descriptions in this paper and AML/GT concern the concrete syntax only.


on model transformation aspects including the tools AToM 3, VIATRA2 , andVMTS . However, AML/GT cannot compete with these rather general-purposelanguages and tools because the GTRs generated are restricted to the very spe-cific field of animation specification. For example, a regular transition can onlyadd or remove link hyperedges. In general, it is specialized for describing thebehavior of components.

Furthermore, there are many other systems and languages which are also in-tended for describing behavior, especially in the context of statecharts, UML,and MDE, e.g., Executable UML (xUML). Many of such languages try to ex-tend or constrain UML in order to get a language with the possibility to describesystems more precisely than UML. However, many of them have a specific appli-cation domain. AML and AML/GT, which also extend and constrain standardUML, focus on visual appearance and graphical animations next to the expres-siveness of UML statecharts and hypergraphs. Therefore, they are especiallysuited for specifying animated visual languages and generating editors. To thebest of our knowledge, they are the only languages featuring this combination,so the following related work has more or less other domains.

Fujaba, for example, supports so-called story diagrams [2] which combineUML collaboration diagrams with activity diagrams. GTRs can be drawn withinactivities which allow the creation of complex transformation flows. Originally,the main purpose was to generate Java code from such models, but areas ofapplication evolved and many extensions are available in the meantime. Forexample, Fujaba Real-Time [1] allows the modeling of embedded systems basedon statecharts with real-time capabilities. The modeling of visual aspects ofcomponents, however, is not provided. On the other side, AML/GT is not suitedfor embedded systems and does not provide the modeling of real-time constraints.

Another modular and hierarchical model-based approach is presented in [17].The semantic domain of the models presented there is the Discrete Event Sys-tem Specification (DEVS ). It is used for describing control structures for pro-grammed graph rewriting. Although the formalism has a solid foundation, itrequires the user to have a specialized expertise while UML-based approachesare well-known to the majority of all users. Moreover, it also lacks the possibilityto define the structure of components or graphic related issues.

In [13] a visual language for model transformations and specifying model be-havior has been introduced which allows the specification of in-place transforma-tion rules. These rules can be compared to GTRs in a graph-based environment.There are some further extensions like rule periodicity, duration, exceptions, etc.State-based modeling on a more coherent level, which is also the intention of thispaper, is not provided.

Finally, the animation approach used in this paper and the translation of statemachines into GTRs is related to other approaches. The differences between ouranimation approach and those approaches in similar systems (e.g., [3]) havebeen discussed in previous work [15] already. Translating state machines intoequivalent GTR systems is not a new idea either. E.g., there are several papersdescribing the semantics of (UML) state machines based on GTs, e.g., in [5].


The translation process described in Section 6 is rather tailored to its specificapplication within animated editors. Finally, the way graph patterns are usedin state machines and sensors of AML/GT can be considered as alternativeto OCL [10]. We also would like to point towards agent-based modeling [7] asanother field of application for AML/GT.

9 Conclusions

We have pursued our approach of modeling animated editors with the UML-based language AML. The language extension AML/GT offers additional el-ements which are necessary to create specifications of dynamic systems in ahypergraph-based environment automatically.

Applying a modeling language like AML/GT promises that complex systemscan be specified in a clear and accessible way. Using state machines for individualcomponents particularly complies with an intuitive perspective on many systems.At the same time, the underlying GTs provide an established foundation andexact semantics, and they facilitate the comprehension of the execution process.

The algorithmic translation of AML/GT model into the specification formatof DiaMeta has been completely implemented. The aim of creating a higher-levelmodeling language, which does not require further specifications for generatinginteractive, animated editors, has been accomplished. Future work will concen-trate on how collisions between animated components can be detected withoutcomputing their trajectories in advance. Using a physics engine as used in manygame settings appears to be promising.

References

1. Burmester, S., Giese, H.: The Fujaba Real-Time Statechart Plugin. In: Giese, H.,Zundorf, A. (eds.) Proc. of the 1st International Fujaba Days 2003, pp. 1–8 (2003);Technical Report tr-ri-04-247, Universitat Paderborn, Informatik

2. Diethelm, I., Geiger, L., Zundorf, A.: Systematic Story Driven Modeling, a CaseStudy. In: Giese, H., Kruger, I. (eds.) Proc. of the 3rd International Workshopon Scenarios and State Machines: Models, Algorithms, and Tools (SCESM 2004),ICSE Workshop (2004)

3. Ermel, C.: Simulation and Animation of Visual Languages Based on Typed Alge-braic Graph Transformation. Ph.D. thesis, Technical University Berlin (2006)

4. Fuss, C., Mosler, C., Ranger, U., Schultchen, E.: The Jury is Still Out: A Com-parison of AGG, Fujaba, and PROGRES. In: Ehrig, K., Giese, H. (eds.) Proc. ofthe 6th International Workshop on Graph Transformation and Visual ModellingTechniques. ECEASST, vol. 6 (2007)

5. Kuske, S.: A Formal Semantics of UML State Machines Based on Structured GraphTransformation. In: Gogolla, M., Kobryn, C. (eds.) UML 2001. LNCS, vol. 2185,pp. 241–256. Springer, Heidelberg (2001)

6. de Lara, J., Vangheluwe, H.: AToM3: A Tool for Multi-formalism and Meta-modelling. In: Kutsche, R.-D., Weber, H. (eds.) FASE 2002. LNCS, vol. 2306,pp. 174–188. Springer, Heidelberg (2002)


7. Macal, C.M., North, M.J.: Tutorial on agent-based modeling and simulation. In:Kuhl, M.E., Steiger, N.M., Armstrong, F.B., Joines, J.A. (eds.) Proc. of the 37thWinter Simulation Conference, pp. 2–15. ACM (2005)

8. Minas, M.: Generating Meta-Model-Based Freehand Editors. In: Zundorf, A.,Varro, D. (eds.) Proc. of the 3rd International Workshop on Graph-Based Tools.ECEASST, vol. 1 (2006)

9. Object Management Group (OMG): MOF Model To Text Transformation Lan-guage, v1.0 (January 2008), http://www.omg.org/spec/MOFM2T/1.0

10. Object Management Group (OMG): Object Constraint Language, v2.2 (February2010), http://www.omg.org/spec/OCL/2.2

11. Object Management Group (OMG): Unified Modeling Language: Superstructure,v2.3 (May 2010), http://www.omg.org/spec/UML/2.3/Superstructure

12. Object Management Group (OMG): MOF Query/View/Transformation, v1.1(January 2011), http://www.omg.org/spec/QVT/1.1

13. Rivera, J.E., Duran, F., Vallecillo, A.: A Graphical Approach for Modeling Time-Dependent Behavior of DSLs. In: DeLine, R., Minas, M., Erwig, M. (eds.) Proc. ofthe 2009 IEEE Symposium on Visual Languages and Human-Centric Computing,pp. 51–55. IEEE Computer Society (2009)

14. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: EMF: Eclipse ModelingFramework, 2nd edn. Addison-Wesley (2009)

15. Strobl, T., Minas, M.: Specifying and Generating Editing Environments for In-teractive Animated Visual Models. In: Kuster, J., Tuosto, E. (eds.) Proc. of the9th International Workshop on Graph Transformation and Visual Modeling Tech-niques. ECEASST, vol. 29 (2010)

16. Strobl, T., Minas, M., Pleuß, A., Vitzthum, A.: From the Behavior Model of anAnimated Visual Language to its Editing Environment Based on Graph Transfor-mation. In: de Lara, J., Varro, D. (eds.) Proc. of the 4th International Workshopon Graph-Based Tools. ECEASST, vol. 32 (2010)

17. Syriani, E., Vangheluwe, H.: Programmed Graph Rewriting with Time forSimulation-Based Design. In: Vallecillo, A., Gray, J., Pierantonio, A. (eds.)ICMT 2008. LNCS, vol. 5063, pp. 91–106. Springer, Heidelberg (2008)

18. Taentzer, G., Ehrig, K., Guerra, E., de Lara, J., Lengyel, L., Levendovszky, T.,Prange, U., Varro, D., Varro-Gyapay, Sz.: Model Transformation by Graph Trans-formation: A Comparative Study. In: Proc. Workshop Model Transformation inPractice (Satellite Event of MoDELS 2005) (2005)

http://www.omg.org/spec/MOFM2T/1.0

http://www.omg.org/spec/OCL/2.2

http://www.omg.org/spec/UML/2.3/Superstructure

http://www.omg.org/spec/QVT/1.1

AGG 2.0 – New Features for Specifying

and Analyzing Algebraic Graph Transformations

Olga Runge1, Claudia Ermel1, and Gabriele Taentzer2

1 Technische Universitat Berlin, Germany{olga.runge,claudia.ermel}@tu-berlin.de

2 Philipps-Universitat Marburg, [email protected]

Abstract. The integrated development environment AGG supports thespecification of algebraic graph transformation systems based on at-tributed, typed graphs with node type inheritance, graph rules withapplication conditions, and graph constraints. It offers several analy-sis techniques for graph transformation systems including graph parsing,consistency checking of graphs as well as conflict and dependency de-tection in transformations by critical pair analysis of graph rules, animportant instrument to support the confluence check of graph transfor-mation systems. AGG 2.0 includes various new features added over thepast two years. It supports the specification of complex control structuresfor rule application comprising the definition of control and object flowfor rule sequences and nested application conditions. Furthermore, newpossibilities for constructing rules from existing ones (e.g., inverse, mini-mal, amalgamated, and concurrent rules) and for more flexible usabilityof critical pair analyses have been realized.

Keywords: graph transformation tool, AGG 2.0.

1 Introduction

AGG [15,13] is a well-established tool environment for algebraic graph transfor-mation systems, developed and extended over the past 20 years. Graphs in AGGare defined by a type graph with node type inheritance and may be attributed byany kind of Java objects. Graph transformations can be equipped with arbitrarycomputations on these Java objects described by Java expressions.

The AGG environment consists of a graphical user interface comprising sev-eral visual editors, an interpreter, and a set of validation tools. The interpreterallows the stepwise transformation of graphs as well as rule applications as longas possible. AGG supports several kinds of validations which comprise graphparsing, consistency checking of graphs, applicability checking of rule sequences,and conflict and dependency detection by critical pair analysis of graph rules.Applications of AGG include graph and rule-based modeling of software, valida-tion of system properties by assigning an operational semantics to some systemmodel, graph transformation-based evolution of software, and the definition ofvisual languages by graph grammars.


82 O. Runge, C. Ermel, and G. Taentzer

Model transformations have recently been identified as a key subject in model-driven development (MDD). Graph transformations offer useful concepts forMDD, while the software engineering community can generate interesting chal-lenges for the graph transformation community. In the past two years, those newchallenges also lead to the augmentation of AGG by new tool features. In thispaper, we describe some of those challenges, the formal approaches developed tosolve them, and the impact they had on recent developments of new features ofAGG, leading to AGG 2.0.

2 Rule Application Control

Application Conditions. For graph transformation rules, well-known negative orpositive application conditions (NACs, PACs) may be used that forbid or requirea certain structure to be present in the graph for the rule to be applied. As a gen-eralization, application conditions (introduced as nested application conditionsin [9]) further enhance the expressiveness of graph transformations by providinga more powerful mechanism to control rule applications (see [8] for an extensivecase study).

An application condition ac of rule r : L → R is of the form true or ∃(a, c)where a : L → C is a graph morphism from L to a condition graph C, and c isa condition over C. Application conditions may be nested, negated,1 quantifiedby FORALL and combined by using the logical connectors AND and OR. Givenapplication condition ac, a match m : L → G satisfies ac, written m |= ac, ifac = true. A match m : L → G satisfies condition ac = ∃(a, c) if there is aninjective graph morphism q : C → G such that q ◦ a = m and q satisfies c. Thesatisfaction of conditions is extended to Boolean conditions in the usual way. Arule L → R is applicable only if the application condition ac is satisfied for itsmatch m : L→ G.

An example is shown in Figure 1, where the activation of an elementary Petrinet transition is checked: Rule ActivationCheck sets the transition attribute isActi-

vated to true if two conditions, called PreCond and PostCond are satisfied: PostCondis the NAC shown in Figure 1 (b) which forbids the existence of a marked placein the transition’s post-domain, and PreCond is a nested application conditionshown in Figure 1 (c) which requires that on each place in the transition’s pre-domain, there must be one token. Note that this condition cannot be expressedby using simple NACs or PACs. Figure 1 (a) shows the context menu entries forgenerating general application conditions (GACs) in AGG 2.0.

Object Flow for Rule Sequences. Object flow between rules has been definedin [11] as partial rule dependencies relating nodes of the RHS of one rule to(type-compatible) nodes of the LHS of a (not necessarily direct) subsequent rulein a given rule sequence. Object flow thus enhances the expressiveness of graphtransformation systems and reduces the match finding effort.

1 An application condition of the form ¬∃a is called negative application condition.

AGG 2.0 – Specifying and Analyzing Algebraic Graph Transformations 83

Fig. 1. Nested application conditions in AGG

In AGG 2.0, object flow can be defined between subsequent rules in a rulesequence, and the rule sequence can be applied to a given graph respecting theobject flow. An example is the definition of a Petri net transition firing step bythe rule sequence (ActivationCheck, RemovePre*, AddPost*, DeActivate) with objectflow. The sequence defines that rule ActivationCheck (see Figure 1) is appliedonce, followed by rules RemovePre (removing a token from a pre-domain place),AddPost (adding a token to a post-domain place), which are shown in Figure 2,and DeActivate (setting the transition attribute isActivated back to false).

Fig. 2. Rules RemovePre and AddPost for Petri net firing

In the sequence, rules RemovePre and AddPost are applied as long as possible(denoted by “*”), and rule DeActivate is applied once. To restrict the applicationof the rule sequence to exactly one transition, we need to express that the tran-sition in the matches of all rules is the same. This is done by defining the objectflow, e.g., by mapping the transition from the RHS of rule ActivationCheck to theLHSs of rules RemovePre and AddPost as shown in Figure 3.

Fig. 3. Object flow definition for rule sequences in AGG

An example of a firing step by applying the rule sequence with object flowis shown in Figure 4, where the left transition in the net was selected, foundactivated and fired.


Fig. 4. Transition firing step resulting from applying a rule sequence with object flow

3 Constructing Rules from Existing Ones

Obviously, the definition of a rule sequence with object flow is neither simple norvery intuitive to model Petri net transition firing steps for transitions with anarbitrary number of pre- and post-domain places. A way closer to the inherentPetri net semantics (a transition removes the tokens from all of its pre-domainplaces and adds tokens to all of its post-domain places in one atomic step)would be to construct a single rule modelling the firing behaviour of a transition.AGG 2.0 supports various ways to automatic rule construction.

Construction of Concurrent Rules. A concurrent rule summarizes a given rule se-quence in one equivalent rule [5,12]. In a nutshell, a concurrent rule p∗Eq = (L←K → R) is constructed from two rules p = (Lp ← Kp → Rp) and q = (Lq ←Kq → Rq) that may be sequentially dependent via an overlapping graph E

Lp

�� (1)

Kp��

�� (2)

Rpep

��

�Lq

eq

�� (3)

Kq��

�� (4)

Rq

��L Cp�� E

(5)

Cq�� R

K

��

��

by the diagram to the right, where(5) is pullback (intersection ofgraphs Cp and Cq in E), and allremaining squares are pushouts.(A pushout is a union of twographs over an interface graph.)The concurrent rule (p1∗. . .∗pn)Ewith E = (E1, . . . , En−1) for a sequence is constructed in an iterated way by(p1 ∗ . . . ∗ pn)E = p1 ∗E1 p2 ∗E2 . . . ∗En−1 pn. In AGG 2.0, we can construct aconcurrent rule from a rule sequence with the following options concerning theoverlappings of one rule’s RHS with the succeeding rule’s LHS: (1) computemaximal overlappings according to rule dependencies; (2) compute all possibleoverlappings (this usually yields a large number of concurrent rules); (3) computeoverlappings based on the previously defined object flow between given rules; (4)compute the parallel rule (no overlapping), where rule graphs are disjointly uni-fied, with NACs constructed according to [12]. As example, Figure 5 shows theconcurrent rule constructed from rule sequence (ActivationCheck, RemovePre(3),

AddPost(2), DeActivate).2 Since an object flow is defined for this sequence, wechoose option (3) by object flow for computing rule overlappings. Constraintson the type graph (e.g., “a Token node is connected to exactly one Place node”)prevent the generation of unnecessary NACs.

2 Note that a concurrent rule can be constructed only for a finite rule sequence.


Fig. 5. Concurrent rule generated from a rule sequence in AGG

Construction of Amalgamated Rules. If a set of rules p1, . . . , pn share a common

subrule p0, a set of “amalgamable” transformations G(pi,mi)=⇒ Gi (1 ≤ i ≤ n)

leads to an amalgamated transformation Gp,m=⇒ H via the amalgamated rule

p = p1+p0 . . .+p0pn constructed as gluing of p1, . . . , pn along p0. We call p0 kernelrule, and p1, . . . , pn multi-rules. A kernel rule together with its embeddings inseveral multi-rules is called interaction scheme. An amalgamated transformation

Gp

=⇒ H is a transformation via the amalgamated rule p [8].This concept is very useful to specify ∀-quantified operations on recurring

graph patterns (e.g., in model refactorings). The effect is that the kernel rule isapplied only once while multi-rules are applied as often as suitable matches arefound. For formal details on amalgamation and a large case study, see [8].

Figure 6 shows the interaction scheme with a kernel rule and two multi-rulesspecifying the firing of a Petri net transition with arbitrary many pre- and post-domain places. The kernel rule has the same application condition as rule Activa-

tionCheck (see Figure 1). Note that we do not need the isActivated flag any morebecause the check and the complete firing step is performed by a single appli-cation of the amalgamated rule. The amalgamated rule constructed for examplealong a match to an activated transition with three pre- and two post-domainplaces is similar to the rule in Figure 5 but has no NACs because the match intothe host graph is predefined by construction.

Construction of Inverse Rules. For a given rule, the inverse rule has LHS andRHS exchanged. Moreover, application conditions are shifted over the rule.Figure 7 shows the inverse rule of rule AddPost (see Figure 2), where an existingtoken is removed. The shifted NAC requires that there is exactly one token onthe place for the rule to be applicable.

Construction of Minimal Rules. A new challenge from MDD comes from thefield of model versioning, where the new notion of graph modification [14], aspan G← D → H has been established to formalize model differences for visualmodels. Based on graph modifications, so-called minimal rules may be extractedfrom a given span to exploit conflict detection techniques for rules. A minimalrule comprises the effects of a given rule in a minimal context. Via contextmenu, AGG 2.0 supports the extraction of a minimal rule from a selected rule(interpreted as graph modification). For example, the minimal rule of the rule inFigure 5 does not contain the arcs connecting the places and transitions, since


Fig. 6. Interaction scheme defining a transition firing step in Petri nets

Fig. 7. Inverse rule of Rule AddPost

these arcs are not changed by the rule. It contains the place nodes (because edgesconnected to them are deleted or generated), the token nodes (either deleted orgenerated) and the transition node (its attribute is changed).

4 Tuning the Critical Pair Analysis

The critical pair analysis (CPA) checks rule pairs for conflicts of rule applicationsin a minimal context. An example for a conflict in a minimal context is shownin Figure 8, where the classical forward conflict in Petri nets is detected whenanalyzing the rule pair (RemovePre, RemovePre). As indicated in the conflict view,we have a delete-use conflict since two transitions need to remove the same tokenfrom their common pre-domain place.

Fig. 8. CPA of rule pair (RemovePre, RemovePre), detecting a forward conflict


Selection of rules for CPA. So far, the CPA could be evoked on a graph grammar,yielding the critical pairs for each possible rule pair of the grammar. AGG 2.0provides free selection of rule sets to be analyzed. This feature has shown to bevery convenient, e.g., for a case study, where self-healing systems are modeled byseveral rule sets (normal system behaviour rules, context-changing rules, repairrules). These sets are analyzed for conflicts with each other [6].

Modularization of a model into different sub-grammars. In AGG 2.0, rule setsmay be imported into an existing grammar (provided the type graph of theimported grammar is a subgraph of the type graph of the importing grammar).This supports modularization of a model without destroying the possibility toanalyze the complete system.

Interrupt and resume running CPA. This usability feature is very handy forcomplex computations which may take some time. A partial CPA result may bestored and reloaded in AGG 2.0.

Generation of Filter NACs. If during CPA, critical pairs are found that areanalyzed by the user as not causing real conflicts, additional NACs for these rulesmay be generated automatically that contain the critical overlapping region. Anew CPA of the rules together with the new Filter NACs does not show theprevious critical pair anymore [10].

5 Related Work and Conclusions

AGG is one of the standard graph transformation tools implementing the al-gebraic approach as presented in [5]. Other graph transformation tools, suchas Fujaba [7], ViaTra [4], VMTS [3], GrGen [16], and Groove [17], implementdifferent kinds of graph transformation approaches. Some kinds of rule applica-tion control structures are offered by all of these tools, e.g., Fujaba uses storydiagrams, a kind of activity diagrams. Groove also supports nested applicationconditions as well as universal quantification using amalgamation.

Concerning the verification of graph transformation systems, VIATRA andGroove concentrate on some kind of model checking, while AGG is the only toolthat consequently implements the theoretical results available for algebraic graphtransformation. These results are mainly concerned with conflict and dependencydetection of rules and static applicability checks for rule sequences. The analysisfeatures offered by AGG are also used by our graph transformation-based toolsTiger (a tool for generating visual editor and simulator plug-ins in Eclipse [2])and Henshin (an EMF model transformation engine [1]).

AGG 2.0 extends the existing features now coherently with support for ap-plication conditions and object flow, and for automatic construction of amalga-mated, concurrent, inverse and minimal rules. Moreover, the critical pair analysishas become more usable due to experiences made in several case studies.


References

1. Arendt, T., Biermann, E., Jurack, S., Krause, C., Taentzer, G.: Henshin: AdvancedConcepts and Tools for In-Place EMF Model Transformations. In: Petriu, D.C.,Rouquette, N., Haugen, Ø. (eds.) MODELS 2010, Part I. LNCS, vol. 6394, pp.121–135. Springer, Heidelberg (2010)

2. Biermann, E., Ehrig, K., Ermel, C., Hurrelmann, J.: Generation of simulation viewsfor domain specific modeling languages based on the Eclipse Modeling Framework.In: Automated Software Engineering (ASE 2009), pp. 625–629. IEEE Press (2009)

3. Budapest University of Technology and Economics: Visual Modeling and Trans-formation System (VMTS) (2010), http://www.aut.bme.hu/Portal/Vmts.aspx

4. Eclipse Consortium: VIATRA2 (Visual Automated Model Transformations)Framework (2011), http://www.eclipse.org/gmt/VIATRA2/

5. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals of Algebraic GraphTransformation. EATCS Monographs in Theoretical Computer Science. Springer(2006)

6. Ehrig, H., Ermel, C., Runge, O., Bucchiarone, A., Pelliccione, P.: Formal Analysisand Verification of Self-Healing Systems. In: Rosenblum, D.S., Taentzer, G. (eds.)FASE 2010. LNCS, vol. 6013, pp. 139–153. Springer, Heidelberg (2010)

7. Fujaba Development Group: Fujaba Tool Suite (2011), http://www.fujaba.de/8. Golas, U., Biermann, E., Ehrig, H., Ermel, C.: A visual interpreter semantics for

statecharts based on amalgamated graph transformation. In: Echahed, R., Habel,A., Mosbah, M. (eds.) Selected Papers of International Workshop on Graph Com-putation Models (GCM 2010). ECEASST, vol. 39 (2011)

9. Habel, A., Pennemann, K.H.: Correctness of high-level transformation systemsrelative to nested conditions. Mathematical Structures in Computer Science 19,1–52 (2009)

10. Hermann, F., Ehrig, H., Golas, U., Orejas, F.: Efficient analysis and execution ofcorrect and complete model transformations based on triple graph grammars. In:Proc. Int. Workshop on Model Driven Interoperability, pp. 22–31. ACM (2010)

11. Jurack, S., Lambers, L., Mehner, K., Taentzer, G., Wierse, G.: Object Flow Def-inition for Refined Activity Diagrams. In: Chechik, M., Wirsing, M. (eds.) FASE2009. LNCS, vol. 5503, pp. 49–63. Springer, Heidelberg (2009)

12. Lambers, L.: Certifying Rule-Based Models using Graph Transformation. Ph.D.thesis, Technische Universitat Berlin (2009)

13. Taentzer, G.: AGG: A Graph Transformation Environment for Modeling and Val-idation of Software. In: Pfaltz, J.L., Nagl, M., Bohlen, B. (eds.) AGTIVE 2003.LNCS, vol. 3062, pp. 446–453. Springer, Heidelberg (2004)

14. Taentzer, G., Ermel, C., Langer, P., Wimmer, M.: Conflict Detection for ModelVersioning Based on Graph Modifications. In: Ehrig, H., Rensink, A., Rozenberg,G., Schurr, A. (eds.) ICGT 2010. LNCS, vol. 6372, pp. 171–186. Springer, Heidel-berg (2010)

15. TFS-Group, TU Berlin: AGG 2.0 (2011), http://tfs.cs.tu-berlin.de/agg16. Universitat Karlsruhe: Graph Rewrite Generator, GrGen (2010),

http://www.info.uni-karlsruhe.de/software.php/id=7

17. University of Twente: Graphs for Object-Oriented Verification (GROOVE) (2011),http://groove.cs.utwente.nl/

http://www.aut.bme.hu/Portal/Vmts.aspx

http://www.eclipse.org/gmt/VIATRA2/

http://www.fujaba.de/

http://tfs.cs.tu-berlin.de/agg

http://www.info.uni-karlsruhe.de/software.php/id=7

http://groove.cs.utwente.nl/

Integration of a Pattern-Based Layout Engine

into Diagram Editors

Sonja Maier and Mark Minas

Universitat der Bundeswehr Munchen, Germany{sonja.maier,mark.minas}@unibw.de

Abstract. In this paper, we outline our pattern-based layout approachand its integration into a diagram editor. In particular, we summarizeeditor features that were made possible by the approach. Each layout pat-tern encapsulates certain layout behavior. Several layout patterns may beapplied to a diagram simultaneously, even to overlapping diagram parts.Our approach includes a control algorithm that automatically deals withsuch situations. To support the user in an interactive environment, it isnot sufficient to apply the same layout behavior in every situation. In-stead, the user also wants to select and alter the layout behavior atruntime. Our approach as well as the editor features described in thispaper are specifically designed for such an environment.

1 Introduction

A layout engine usually runs continuously within diagram editors and improvesthe layout in response to user interaction in real-time. Layout improvement in-cludes all sorts of changes concerning the position or shape of diagram compo-nents. For instance in Figure 1, if class C is moved, the end point of the connectedassociation is updated accordingly. It is, however, not reasonable to completelyautomate layout improvements in diagram editors. The editor user would alsolike to influence the layout at runtime.

We have developed a pattern-based layout approach that is tailored to such anenvironment [2]. A layout pattern, which encapsulates certain layout behavior,consists of a (pattern-specific) meta model together with some assertions and alayout algorithm, which are defined using this meta-model. A pattern may beapplied to a diagram, which means that a pattern instance is created and boundto (parts of) the diagram. The assertions “define” a valid layout of the diagram(part), and the layout algorithm is responsible for “repairing” the layout whenassertions are violated. The diagram layout is affected by this pattern instanceuntil it is deleted. A diagram layout is usually defined by several instances oflayout patterns whose layout algorithms cannot be executed independently. Acontrol algorithm automatically coordinates when and how these layout algo-rithms are executed [3].

In this paper, we give an overview of the layout approach with the help ofa class diagram editor as a simple example.1 We focus on some editor featuresthat support the user during the process of layout improvement:

1 A screencast is available at www.unibw.de/inf2/DiaGen/Layout .


www.unibw.de/inf2/DiaGen/Layout

90 S. Maier and M. Minas

User-controlled and Automatic Layout: The editor user can apply layoutpatterns for user-selected parts of the diagram. These pattern instances affectthe diagram layout until the user deletes them. Furthermore, the specificationof the diagram editor describes when layout patterns are automatically applieddepending on the diagram’s syntactic structure.

Pattern Instance Visualization: Pattern instances created by the editor userare visualized in the diagram.

Syntax Preservation: The editor makes sure that the layout engine does notmodify the syntactic structure of the diagram.

Layout Suggestions: The editor can automatically suggest application of lay-out patterns when the user selects some part of the diagram.

Automatic as well as user-controlled layout and pattern instance visualization aswell as syntax preservation have been described or at least sketched earlier [2,3],but layout suggestions have not been published yet. The concepts described inthis paper have been completely implemented and examined in several diagrameditors.

The term layout pattern has been coined by Schmidt et al. in the context ofsyntax-directed editors [5]. They use tree grammars for specifying the digramlanguage syntax whereas we use meta-models, which are more widely acceptedthan grammars. In their approach, layout is computed via attribute evaluationwhereas we support several ways of layout computation, in particular constraintsolving techniques and off-the-shelf graph drawing algorithms. There also existsome editors including a layout engine that are somewhat related to our ap-proach. One of these editors is Dunnart [1], a graph editor, which is based ondeclarative constraints and which provides some user-controlled layout behavior.Most of these tools have in common that the layout engine is hand-coded andhard-wired in the editor. Our approach supports modular specification of layouton an abstract level and using this layout behavior in different editors.

Section 2 introduces the class diagram editor as a running example and de-scribes its layout capabilities. Our layout approach is sketched in Section 3.Section 4 outlines the integration of the approach into an editor. Section 5 con-cludes the paper.

2 Running Example

Figure 1 shows a class diagram editor, which has been created with the edi-tor generation framework DiaMeta [4]. DiaMeta allows for generating visuallanguage editors from specifications of their visual languages. The core of thespecification is a meta-model (called language-specific meta model, LMM, in thefollowing) of the diagram language, here class diagrams. The meta-model de-scribes the language’s abstract as well as concrete syntax.

Several layout patterns have been integrated into the class diagram editor:Non-Overlap removes overlapping of packages and classes that are (directly)

Layout Support for Diagram Editors 91

Fig. 1. Running example: Class diagram editor

contained in the same package by applying a force-directed layout algorithm.Containment ensures the correct nesting of packages and classes. List arrangesattributes of classes as a list. Minimal Size enforces a minimal size of packagesand classes. Edge Connector ensures that associations and generalizations stayattached to classes. Alignment (horizontal & vertical) aligns certain packagesand classes vertically or horizontally respectively. Equal Distance (horizontal& vertical) makes sure that certain packages and classes have an equal distanceto each other. Equal Size (width & height) makes sure that certain packagesand classes have the same height or width respectively. Finally, Layered Layoutassigns each class to a certain horizontal layer such that generalization arrowsalways point upward.

3 Layout Engine

Each layout pattern is defined on a pattern-specific meta-model (PMM) whereasthe diagram language is specified using a language-specific meta-model (LMM)as outlined in Sections 1 and 2. Figure 2 shows three PMM examples: The Con-tainment PMM used by the Containment pattern, List PMM used for the Listpattern, and Graph PMM used for the Layered Layout pattern. The PMMs areapparently independent of a concrete diagram language and its meta-model. Inorder to use a layout pattern for a certain diagram language, the language’sLMM must be mapped to the pattern’s PMM. This mapping identifies the roles


(a) Containment PMM (b) List PMM (c) Graph PMM

Fig. 2. Pattern-specific meta-models (PMMs)

that the components of the visual language play in the layout pattern. Pat-tern instantiation then means that the diagram’s model, i.e., the LMM instance(LM), is transformed into a pattern instance model, i.e., a PMM instance (PM),following this mapping.

When the editor user draws or modifies a diagram, the editor automaticallyupdates its diagram model (LM). In addition, the editor automatically updatesall pattern instance models (PMs), creates new ones and deletes existing onesdepending on the modified syntactic structure of the diagram or depending onuser actions (cf. Section 4.1). The PM attribute values reflect the attributesof the corresponding diagram model. The pattern’s assertions (cf. Section 1)are checked on these attribute values. The layout algorithm modifies the PMattribute values when one or more assertions are violated. These values arethen transformed back to the corresponding LM attribute values following themapping between LMM and PMM. The layout is updated this way.

Of course, the layout algorithms must not modify the PM attributes and,therefore, the diagram model attributes independently. The modifications mustrather be coordinated. This is the task of the control algorithm, which was de-scribed in detail in [3]. Via backtracking, this algorithm determines the order inwhich the layout algorithms of the pattern instances change the diagram. Thismust be done at runtime because the layout can only be computed as soon as allattribute values – including the attribute values the user changed – are known.The idea of the control algorithm is that changes made by the user are propa-gated through the diagram, trying to find a layout satisfying all assertions. Start-ing with the component(s) (or more precisely, attribute(s)) changed by the user,all pattern instances are checked that involve these components. Each patterninstance whose assertions are violated changes one or more attribute value(s) byits encapsulated layout algorithm in order to “repair” it. Afterwards, all furtherpattern instances that involve these attributes are checked. This procedure iscontinued until all pattern instances are satisfied, or until the algorithm signalsa failure. A failure is signaled if there does not exist a “valid” layout, whichmight be the case if two or more pattern instances contradict each other. Thealgorithm also signals a failure in case layout computation would take longerthan a user-configurable threshold.

With the help of layout patterns, different layout algorithms can be combined.The following three types of layout algorithms are currently supported:


– Standard graph drawing algorithms may be used, e.g., the Sugiyamaalgorithm for the creation of a layered layout. These algorithms can be usedoff-the-shelf from graph drawing libraries.

– Declarative constraintsmay be used to specify the layout algorithm whichthen uses a constraint solver for computing the layout. With this type oflayout algorithm, global layout behavior such as “several classes have anequal distance to each other” can be defined.

– In addition, our own version of rule-based layout algorithms may beused, which is specifically tailored to the interactive nature of visual languageeditors. The rule-based layout algorithm consists of a set of assertions that“define” the layout, and a set of rules that “repair” violated assertions andhence update the layout after user modifications.

It is possible to define quite complex layout behavior with these types of lay-out algorithms. However, layout patterns should be chosen carefully because thediagram layout is computed and updated at runtime. Especially using a con-straint solver may lead to a bad performance, e.g., if it aims at minimizing edgecrossings.

4 Integration of the Layout Engine into an Editor

We specified several layout patterns, and integrated them into various visuallanguage editors. For instance, they were integrated into the class diagram editorpresented earlier, into a graph editor, into a GUI forms editor that allows theuser to create GUIs, or into a VEX editor that allows the user to draw lambdaexpressions visually.

The creation of the layout modules as well as their inclusion in different visuallanguage editors turned out to be (more or less) straightforward. Furthermore,the concept of layout patterns allowed us to develop some features that increasedthe usability of the editors. Some of these features will be described in thefollowing.

4.1 Automatic and User-Controlled Layout

A layout pattern may be applied to a diagram if some part of the diagram modelcan be transformed to a pattern instance model. This situation must be spec-ified when generating the editor. This is done as follows: The generated editoruses a graph (actually a hypergraph) for representing the diagram model. Thishypergraph corresponds to the language-specific meta-model (LMM). Patterninstance models (PMs) are internally represented by graphs, too. Transforma-tions of the diagram model to the PMs are realized by graph transformations.The situation that a layout pattern may be applied to a diagram, therefore, issimply the situation that such a graph transformation may be applied.

The layout engine supports two modes of layout pattern instantiation: auto-matic and user-controlled application of layout patterns. Automatic instanti-ation means that the diagram editor tries to transform the diagram model to


pattern instance models, i.e., to apply the graph transformations whenever pos-sible. This mode of pattern instantiation makes sense for layout aspects that areessential for a diagram language. In the class diagram editor, these are the ap-plication of the non-overlap pattern, containment pattern, list pattern, minimalsize pattern, and edge connector pattern to the corresponding diagram parts.

However, automatic instantiation does not make sense in situations where theuser would like to modify the layout for, e.g., mere aesthetic reasons. In the classdiagram editor, these are, e.g., the horizontal alignment of classes. Applying sucha layout pattern to every possible situation does not make sense. The editor userrather has to indicate the situations where he wishes to apply a pattern. Thisis realized by user-controlled instantiation. The editor specification mustcontain graph transformation rules (actually graph transformation programs inDiaMeta) for a layout pattern. By selecting a layout pattern and one or morecomponents, the editor user chooses a part of a diagram for which the layoutpattern shall be instantiated. The selected diagram components correspond tocertain graph components of the diagram model. The editor then tries to applya graph transformation specified for the selected layout pattern to the diagrammodel that corresponds to the selected graph components of the diagram model.After creation, the pattern instance is updated after each diagram modificationuntil it is deleted, either by the editor user who explicitly deletes this patterninstance, or when the diagram is modified in a way such that the layout patterndoes no longer fit. In the class diagram editor, the equal distance pattern, thealignment pattern, the equal size pattern and the layered layout pattern arecontrolled by the user. All pattern instances that were created by the user areshown in a list at the bottom-right of the editor.

In the example shown in Figure 1, the user has created the following patterninstances: Classes Person, Student and Professor and the corresponding gen-eralizations are rearranged by a layered layout algorithm. Classes Person, A andB are aligned horizontally at the top and at the bottom. Some pattern instanceshave been automatically created. When the user modifies the diagram, the twoalignment pattern instances and the layered layout pattern instance preserve thelayout that was chosen by the user. The non-overlap pattern instance moves theclasses that are contained in the package university to assure that they do notoverlap. The containment pattern instance moves the package and the classes topreserve the correct nesting of the package university and its contained classes.The list pattern instance correctly arranges the attributes in the class Person.The minimal size pattern instance enforces a minimal size of the package and theclasses. Finally, the edge connector pattern instance updates the start and endpoint of the association and the generalizations to keep them correctly connectedto the classes.

4.2 Pattern Instance Visualization

Experiments have shown that users of diagram editors have trouble “under-standing” the layout dependencies between components if current layout patterninstances are not displayed. Therefore, diagram editors display currently active


layout pattern instances in the diagram. In the example shown, instances of thehorizontal alignment pattern are visualized via colored lines, and instances ofthe layered layout pattern via colored boxes. It is possible to create instancesof the same layout pattern several times in one diagram. To distinguish thesepattern instances, they are highlighted in different colors.

If the user selects one of the pattern instances in the list at the bottom-rightof the editor, the involved components are highlighted via a gray cross in themiddle of each component. For instance, in the editor shown in Figure 1, the userhas selected the layered layout pattern instance, and hence the classes Person,Student and Professor and the two generalizations are highlighted.

4.3 Syntax Preservation

Freehand editors allow to arrange diagram components on the screen withoutany restrictions, and the syntax is defined by the location of the components onthe screen. Because a layout pattern instance does not know about the diagramsyntax, it can easily rearrange components such that the diagram’s syntacticstructure is modified. This is usually unwanted behavior, and it should be pos-sible to prevent it. For instance, in the class diagram editor, a syntax changemay occur if the layout engine moves one class on top of another class (this ispossible only if the non-overlap pattern is turned off) that has an associationconnected to it. Then it is not clear to which class this association is connected.

Syntax preservation has been added for DiaMeta editors. It is achieved bycomparing the internal graph representation of the diagram model before andafter a layout modification. If the graph structure is changed by the layoutengine, the user changes that led to this violation are undone.

4.4 Layout Suggestions

To further support the editor user, the editor is able to suggest layout patternsthat could be applied to a user-selected part of the diagram. Layout suggestionsare computed by “trying out” each layout pattern. For each layout pattern,pattern matching is performed in the user-selected part of the diagram. For themaximal match found, a pattern instance is created. The layout engine then triesto find a valid solution, taking into account the newly created pattern instance(s)and all other pattern instances currently present in the diagram. The patternis applicable if the layout engine is able to compute a valid layout. In addition,the attribute changes that are performed by the layout engine are examined. Ametric is used to rate the applicability of the different layout patterns. Layoutpatterns that result in minor diagram changes are favored over layout patternsthat result in major diagram changes.

This feature can be used as follows: After selecting one or more components,the user can click the button Compute Layout Suggestions. The buttons on theright side of the editor are then highlighted in a certain color. Gray indicatesthat the corresponding pattern cannot be applied because it either does not fitthe chosen diagram part or is inconsistent with the currently active pattern in-stances. Blue indicates that the corresponding pattern can be applied. Asterisks


are added to the label if the application of the pattern results in minor changesof the diagram, and they are omitted if it results in major changes.

In Figure 1, layout suggestions for classes Professor, C and D were computed.Button Horizontal Alignment (top), e.g., is highlighted in blue, and asterisks areadded as only minor diagram changes would be necessary after applying thepattern, whereas button Vertical Alignment (left) is highlighted in blue, and noasterisks are added as major diagram changes would be necessary.

5 Conclusions

We have sketched our pattern-based layout approach and the integration of thelayout engine into a diagram editor. We focused on some features that are madepossible by the pattern-based layout approach, namely user-controlled layout,pattern instance visualization, syntax preservation and layout suggestions. Wehave further features in mind that are enabled by the pattern-based approachand that could also be included, e.g., automatic layout after diagram import.

Our pattern-based approach as well as the features described have been com-pletely integrated into DiaMeta. Furthermore, we created several visual lan-guage editors that include the layout engine, and we observed that the layoutengine produces good results, and that the overall performance is satisfactory.

During the development of the layout approach and its integration into severaleditors, some questions arose: Which layout patterns should be included in acertain visual language editor? How should a layout pattern be visualized? As anext step, we plan to perform a user study to answer these questions.

References

1. Dwyer, T., Marriott, K., Wybrow, M.: Dunnart: A Constraint-Based Network Di-agram Authoring Tool. In: Tollis, I.G., Patrignani, M. (eds.) GD 2008. LNCS,vol. 5417, pp. 420–431. Springer, Heidelberg (2009)

2. Maier, S., Minas, M.: Pattern-based layout specifications for visual language editors.In: Proc. of the 1st International Workshop on Visual Formalisms for Patterns.ECEASST, vol. 25 (2009)

3. Maier, S., Minas, M.: Combination of different layout approaches. In: Proc. of the2nd International Workshop on Visual Formalisms for Patterns. ECEASST, vol. 31(2010)

4. Minas, M.: Generating meta-model-based freehand editors. In: Proc. of the 3rdInternational Workshop on Graph Based Tools. ECEASST, vol. 1 (2006)

5. Schmidt, C., Kastens, U.: Implementation of visual languages using pattern-basedspecifications. Software: Practice and Experience 33(15), 1471–1505 (2003)

Tool Demonstration of the Transformation Judge

Steffen Mazanek, Christian Rutetzki, and Mark Minas

Universitat der Bundeswehr, Munchen, [email protected], [email protected],

[email protected]

http://www.unibw.de/inf2/

Abstract. The transformation judge is a novel system for the auto-matic evaluation and comparison of graph and model transformationsthat have been submitted as solutions for common transformation taskssuch as those accepted as case studies for the transformation tool con-test. The most important feature of this system is the correctness checkthat is done by black-box-testing. But also performance data and otherinformation about the solutions are collected. So, for academic as well asindustrial users of transformation tools, the judge could be a good start-ing point for choosing a particular transformation tool for their respec-tive task, since they can easily explore and compare different solutionsfor similar tasks.

In this demonstration we show the most important use cases of thejudge, i.e., uploading of cases and corresponding solutions as well as theautomatic evaluation and comparison of solutions.

1 Introduction

We have almost completed our work on the so-called transformation judge,1

which is an online judge system for graph and model transformations, i.e., itallows to automatically evaluate solutions for common transformation tasks.The idea of an online judge originally stems from the domain of programmingcontests, where such systems are used to give immediate feedback about thecorrectness of submitted solutions. In this context, however, correctness onlymeans that a certain set of reference inputs is transformed by the submittedprogram into the corresponding reference outputs, i.e., black-box-tests are per-formed. Both inputs as well as outputs are given as plain text in this domainand the actual output can be compared with the reference output character bycharacter; with graphs/models as the main artefacts this step certainly is morecomplicated. Several online judge systems are available that, among others, differin the supported set of programming languages. Most widely known is the UVaOnline Judge,2 which is used in the well-known ACM programming contests,3

but also by people who just want to train and improve their programming skills.

1 http://sites.google.com/site/transformationjudge/2 http://uva.onlinejudge.org/3 http://icpc.baylor.edu/


http://www.unibw.de/inf2/

http://sites.google.com/site/transformationjudge/

http://uva.onlinejudge.org/

http://icpc.baylor.edu/

98 S. Mazanek, C. Rutetzki, and M. Minas

From the organization of the transformation tool contest TTC4 the idea wasborn to provide an online judge for the graph and model transformation commu-nity. In previous editions of the contest the solution submitters presented theirsolutions for the respective transformation cases in front of a critical audiencethat acted as a jury and ranked the presented approaches according to severalcriteria. Of course, such a voting is highly inappropriate for criteria such as cor-rectness, but there was no other option at that time. Actually, correctness waseven among the most subjective criteria as indicated by a very high variance inthe votings. The transformation judge solves this problem by carrying over theonline judge concept from programming contests. Moreover, the transformationjudge allows to compare transformation approaches with respect to further crite-ria such as performance, lines of code or user rating and, even more importantly,across various cases. So, for both academic and industrial users of transformationtools, the judge, once populated with cases and solutions, could be a good start-ing point for choosing a particular transformation tool for their respective task,since they can easily explore and compare different solutions for similar tasks.Finally, the transformation judge will be a platform for beginners, who want toget an impression of the different transformation approaches. To simplify thislearning step a Hello World case [7] that comprises very basic transformationtasks was selected as one of the cases for TTC 2011 [11] and resulted in an initialfill of the judge.

There are several challenges when developing a transformation judge com-pared to a conventional judge for programming algorithms, most importantly:

– Many transformation tools are still at the prototypical level, in contrast tothe programming languages supported by the conventional judges.

– The different transformation approaches deal with varying input and outputformats.

– Several transformation approaches are integrated into complex graphicaltools and difficult to invoke in headless mode.

– Regarding security, one needs to be not only careful with the actual trans-formations but also with the zoo of transformation tools to be integratedinto the judge.

– For most cases, the output of a transformation cannot be compared ona per-character-basis with the reference output as in conventional judges,because graphs/models have different possible, equivalent string represen-tations; even worse, in general it is inherently expensive to compare twographs/models of reasonable sizes in practical time.

This demonstration paper describes the most important use cases of the judge,i.e., the upload of cases and corresponding solutions as well as the automaticevaluation and comparison of solutions. For a better understanding, also thearchitecture of our system is briefly introduced.

4 http://planet-research20.org/ttc2011/

http://planet-research20.org/ttc2011/

Tool Demonstration of the Transformation Judge 99

Case submitter

Solution submitter

User

CC cases

SS solutions

Transformation

Judge

CC SS

RR evaluation

results

Fig. 1. The main roles of judge users

2 Use Cases of the Transformation Judge

The main roles of judge users and the basic process behind the judge are shownin Figure 1. Case submitters upload cases, which basically consist of a taskdescription, an input metamodel, an output metamodel and a set of pairs ofreference input models with their corresponding output models. They can alsoset some more parameters such as the maximal execution time after which asolution is terminated. After the publication of the case, solution submittersupload their respective solutions. To this end, the actual transformation codeneeds to be uploaded and the used transformation language needs to be selectedfrom a list of supported transformation languages. Besides the case and solutionsubmitters there are also normal users who benefit from the system by exploringand comparing the various evaluation results.

Fig. 2. Use cases of a normal user


Fig. 3. Use cases of case and solution submitters

Figure 2 shows the system’s use cases from the perspective of a normal user.More precisely we distinguish anonymous users from registered users, and cer-tain functions such as commenting or voting on solutions can only be used byregistered users.

Figure 3 shows the system’s use cases from the perspective of case and solutionsubmitters. A case, i.e., a transformation task, consists of a name, a descriptionfile, the determined model compare procedure and a set of model pairs (referenceinputs and expected outputs) that are used for black-box testing the solutions.Since a case, and thus the model pairs, can be changed during the update of thecase, there need to be mechanisms for versioning and also for checking whetherthe already uploaded solutions still pass the black-box test. This mechanism canbe triggered by the case submitter and is called “Revalidate solutions” in thefigure. Solutions that still comply to the new version of the case are automaticallyconnected with this new version.

3 System Architecture

The judging system is implemented in a modular way following a service-orientedapproach. All supported transformation tools and also the comparison tool areaddressed as webservices. Figure 4 shows how the transformation judge actu-ally evaluates a solution. After the upload of a solution to the judge websiteits evaluation can be triggered. First, the required case- and solution-relateddata need to be gathered from the database. It is passed to the evaluation man-ager that is responsible for controlling the computation of an evaluation result.To this end, first the transformation tool responsible for the specific solutionneeds to be invoked, which is done via its webservice. The result that is passedback consists of logging information, performance data, and, most importantly,the output model. This model needs to be compared with the expected out-put, i.e., the reference output model. This job is performed by the comparatorwebservice, which returns some logging information including a human readable


ComparorWebserviceComparor

Webservice

ComparorWebserviceComparor

WebserviceTransformation

WebserviceTransformation

Webservice

TransformationWebservice


User & SystemManagement



DB

EvaluationManager

EvaluationManager

EvaluationManager

ComparatorWebserviceComparor

Webservice

ComparatorComparorComparor

WebserviComparCompar

WebserWebserceiicece

ComparatorWebservice



TransformationT f tiT f tiWebservi

TransformaTransformaW bW b

ceii


Fig. 4. The steps for the evaluation of a solution

description of the comparison result and, if applicable, a formal difference model.The transformation and compare step need to be repeated for each pair of ref-erence input/output models. From all these results an overall evaluation resultis constructed, passed back and shown to the user, who can publish his solu-tion afterwards. If he is not satisfied with the evaluation result he can improvehis solution until it passes the test. Note that all communication between thewebservices is performed asynchronously.

In order to integrate a transformation tool, the tool developers need to con-tribute their tool as an executable file that has to follow a particular call schema.GReTL [2], ETL [5] and plain Java are already supported and ATL [4], VIATRA[1] and PETE [10] will follow soon. The judge then wraps these executables intowebservices.

Restrictions

The judge currently has the following restrictions:

– The judge (for now) only provides support for EMF models, i.e., input andoutput metamodels have to conform to EMF’s Ecore metamodel.5 Note thatEMF is a de facto modeling standard nowadays and many transformationtools are based on EMF or at least provide EMF import/export facilities.

– The judge (for now) only provides support for transformation tasks thatrequire exactly one input and one output model and metamodel, respectively.

– The whole transformation currently has to be uploaded as a single file.

Focusing on the EMF format also has allowed us to integrate model comparisonin a quite straightforward way, because there are several tools available that cancompare EMF models. EMFCompare6 [9] probably is the most widely used tool

5 http://www.eclipse.org/emf/6 http://www.eclipse.org/emf/compare/

http://www.eclipse.org/emf/

http://www.eclipse.org/emf/compare/


Fig. 5. Screenshot of the evaluation screen

for this purpose and, thus, we integrated this tool. Our experiences regardingthe use of model comparison tools for our purpose and also the issues we had todeal with are described in detail in [8].

4 Related Work

Besides the already mentioned UVa judge, there are also several smaller systemssuch as the sphere judge [6] or the z-training judge,7 which support differentprogramming languages or provide further features. The latter, for instance,provides interactive graders as a means for the evaluation of intermediate re-sults of a computation. Such a feature might be interesting for the evaluationof very complex or step-wise transformations. We have decided to implementour transformation judge from scratch instead of extending an existing system,because discussions with both the developers of the sphere and the z-trainingjudge revealed that it would have been a high effort to adapt these systemsto support transformation tasks. Also, a modular architecture with tool-specificwebservices was an important argument for a completely new system.

Further, there are several approaches that address the evaluation and com-parison of transformations, among them the yearly tool contest. One of the mostimportant contributions, however, is the benchmark proposed by Varro et al. as

7 http://www.z-training.net/

http://www.z-training.net/


a means for the systematic comparison of the performance of transformationtools [12]. Setting up such a benchmark from scratch is a huge effort, becausethe different systems ideally should be installed in the same environment or atleast on comparable hardware. The transformation judge can be used for bench-marking as a side effect, because performance data is collected automaticallywhile running the transformations.

5 Conclusion

We have only put a few quite basic transformation tasks into the judge so far.The judge deals with them easily and provides quite readable information. Ithas successfully verified the GReTL solutions [3] to some subtasks of this year’sHello-World case. Note that GReTL is a graph transformation tool. This showsthat the judge is not only dedicated to model transformation tools (althoughmany graph transformation tools do still not support EMF).

At the moment the webservices for both the transformation and the comparetools can only be accessed by the judge server itself. However, it would be pos-sible to make them publicly available. This would, e.g., enable users to comparemodels in a very lightweight way and to invoke different transformation tools. So,users would not need to install tools locally in order to evaluate their suitabilityfor the task at hand.

Note that the transformation judge is not online yet. The described function-ality is mostly implemented, but there are a few security issues that still need tobe addressed. A screenshot of the web interface is shown in Figure 5. Moreover,screencasts of the system are available at the project website: http://sites.google.com/site/transformationjudge/.

Due to the challenges listed in this paper, the transformation judge is inter-esting from a software engineering perspective. However, its real value hopefullywill be revealed in the future when the different transformation approaches canbe compared in an objective way across a reasonable number of cases.

Plenty of work remains to be done in the future. For instance, it would begood to divide the test cases into public and private ones, the further for de-bugging solutions and the latter for the real competition, i.e., without exposingthe models. Also, we need to compute a better indicator for conciseness thanjust lines of code. And, finally, we have to address the current restrictions of thesystem to make it more widely applicable.

Acknowledgements. A great thank you to the transformation tool developersthat helped with the integration of their respective tools (Tassilo Horn, LouisRose, Massimo Tisi). Also many thanks to Aleksandar Zlateski, the developerof z-training judge, for a lot of advice regarding the implementation of an onlinejudge and Cedric Brun and Patrick Konemann for EMFCompare tips. Finally,a special thank you to Pieter van Gorp, who discussed this project with us fromthe very beginning.




References

1. Csertan, G., Huszerl, G., Majzik, I., Pap, Z., Pataricza, A., Varro, D.: VIATRA –Visual automated transformations for formal verification and validation of UMLmodels. In: 17th IEEE International Conference on Automated Software Engineer-ing (ASE 2002), pp. 267–270. IEEE Computer Society (2002)

2. Ebert, J.: Metamodels taken seriously: The TGraph approach. In: Proc. of the 12thEuropean Conference on Software Maintenance and Reengineering, CSMR 2008,p. 2. IEEE (April 2008)

3. Horn, T.: Saying Hello World with GReTL – A solution to the TTC 2011, instruc-tive case. In: Van Gorp et al. [11]

4. Jouault, F., Allilaire, F., Bezivin, J., Kurtev, I.: ATL: A model transformationtool. Science of Computer Programming 72(1-2), 31–39 (2008)

5. Kolovos, D.S., Paige, R.F., Polack, F.A.C.: The Epsilon Transformation Language.In: Vallecillo, A., Gray, J., Pierantonio, A. (eds.) ICMT 2008. LNCS, vol. 5063, pp.46–60. Springer, Heidelberg (2008)

6. Kosowski, A., Ma�lafiejski, M., Noinski, T.: Application of an Online Judge & Con-tester System in Academic Tuition. In: Leung, H., Li, F., Lau, R., Li, Q. (eds.)ICWL 2007. LNCS, vol. 4823, pp. 343–354. Springer, Heidelberg (2008)

7. Mazanek, S.: Hello world! An instructive case for the Transformation Tool Contest.In: Van Gorp et al. [11], http://sites.google.com/site/helloworldcase/

8. Mazanek, S., Rutetzki, C.: On the importance of model comparison tools for theautomatic evaluation of the correctness of model transformations. In: Proceedingsof the 2nd International Workshop on Model Comparison in Practice, pp. 12–15.ACM (2011)

9. Mulder, A., Schill, H., Wendehals, L.: Modellvergleich mit EMF Compare – Teil 1:Funktionsweise des Frameworks. Eclipse Magazin 4, 43–47 (2009)

10. Schatz, B.: Formalization and Rule-Based Transformation of EMF Ecore-BasedModels. In: Gasevic, D., Lammel, R., Van Wyk, E. (eds.) SLE 2008. LNCS,vol. 5452, pp. 227–244. Springer, Heidelberg (2009)

11. Van Gorp, P., Mazanek, S., Rose, L. (eds.): Proc. of the Fifth TransformationTool Contest, Zurich, Switzerland. Electronic Proceedings in Theoretical ComputerScience, vol. 74 (2011)

12. Varro, G., Schurr, A., Varro, D.: Benchmarking for Graph Transformation. In:Erwig, M., Schurr, A. (eds.) Proc. IEEE Symposium on Visual Languages, pp.79–100. IEEE Computer Society Press (2005)

http://sites.google.com/site/helloworldcase/

Knowledge-Based Graph Exploration Analysis

Ismênia Galvão1, Eduardo Zambon2,�, Arend Rensink2,Lesley Wevers2, and Mehmet Aksit1

1 Software Engineering Group,{i.galvao,m.aksit}@ewi.utwente.nl2 Formal Methods and Tools Group,

Computer Science Department,University of Twente

PO Box 217, 7500 AE, Enschede, The Netherlands{zambon,rensink}@cs.utwente.nl, [email protected]

Abstract. In a context where graph transformation is used to explorea space of possible solutions to a given problem, it is almost always nec-essary to inspect candidate solutions for relevant properties. This meansthat there is a need for a flexible mechanism to query not only graphsbut also their evolution. In this paper we show how to use Prolog queriesto analyse graph exploration. Queries can operate both on the level ofindividual graphs and on the level of the transformation steps, enablinga very powerful and flexible analysis method. This has been implementedin the graph-based verification tool groove. As an application of thisapproach, we show how it gives rise to a competitive analysis techniquein the domain of feature modelling.

Keywords: Graph exploration analysis, Prolog, groove, feature mod-elling.

1 Introduction

The practical value of graph transformation (GT) is especially determined by thefact that graphs are a very general, widely applicable mathematical structure.Virtually every artefact can be understood in terms of entities and relationsbetween them, which makes it a graph; and consequently, changes in such anartefact can be specified through GT rules.

On the other hand, capability does not automatically imply suitability. Forinstance, though it is possible to express structural properties as (nested) graphconditions – see, for instance, [19,13] – in practice, if one wants to query a givenstructure, writing graphical conditions to express and test for such queries isnot always the most obvious or effective way to go about it. This is particularlytrue if the queries have not been predefined but are user-provided. Instead, thereare dedicated languages suitable for querying relational structures, such as, forinstance, SQL or Prolog.� The work of this author is supported by the GRAIL project, funded by NWO (Grant

612.000.632).


106 I. Galvão et al.

The need for a powerful and flexible query language becomes even more clearwhen one wants to combine static (structural) properties with dynamic ones, soas to include the future or past evolution of the structure. For instance, temporallogic has been especially introduced to express dynamic properties and checkthem efficiently (see [2] for an overview). However, besides lacking accessibility,temporal logic is propositional, meaning that it takes structural properties asbasic building blocks; there is very little work on logics that can freely mixstatic and dynamic aspects of a system.

An example domain that requires this combination of static and dynamic as-pects is feature modelling. A feature model is a graph in which nodes representpossible features (of some system under design) and edges express that onefeature requires another, is in conflict, or is related in some other way. Graphtransformation can be used to actually select features (in such a way that theconstraints are met). The outcome is a (partially) resolved model, the qualityof which is not only determined by the choices actually made but also by thepossible choices still remaining. Thus, one would like to query a feature modelfor both its static properties (the choices actually made) and for its dynamicproperties (the potential further transformation steps).

In this paper, we describe how one can use Prolog to query static and dynamicproperties of graphs, simultaneously and uniformly. Besides the transformedgraphs this requires a graph transition system (GTS), which is itself a graphwith nodes corresponding to state graphs and edges to rule applications. Thebasic building block of Prolog is a predicate, which expresses a relation betweenits arguments. Example predicates in our setting are:

– The relation between a graph and its nodes or edges;– The relation between an edge and its source or target node, or its label;– The relation between a state of the GTS and its corresponding graph;– The relation between one state of the GTS and the next.

A collection of Prolog predicates forms a knowledge-base, which is queried duringthe analysis of a GTS. Using an extension of the transformation tool groovethat supports Prolog queries, we demonstrate the capabilities of this approachon a case study based on feature modelling. This domain was chosen due to itsapplicability on the development process of software industries.

The paper is organised as follows. We first present the basic concepts for queryinggraphs using Prolog (Section 2); then we describe the application to featuremodelling in Section 3. An analysis of the results can be found in Section 4.Conclusion and ideas for future work are given in Section 5.

2 Prolog in groove

The Prolog programming language [7] is the de facto representative of the logicprogramming paradigm. Unlike imperative languages, Prolog is declarative: a

Knowledge-Based Graph Exploration Analysis 107

s0� ��

s1� ��

s2� ��

Fig. 1. Example GTS with three states and two transitions

Prolog program is composed of predicates about objects and their relations,and computations are performed by running queries over predicates. Given aquery asking whether a predicate holds for a certain (given) object, the Prologinterpreter uses a resolution procedure that yields a yes or no answer. On theother hand, if a query has free variables, the Prolog engine will enumerate allobjects which can be assigned to the variables so as to make the predicate true.

groove [22,11] is a graph transformation tool set which can recursively ex-plore and collect all possible rule applications over a start graph: this is referredto as the exploration of the state space of a graph grammar. The state spaceis stored as a graph transition system (GTS), where each state of the systemcontains a graph and each transition is labelled by a rule application. groovehas a graphical interface called the Simulator, for editing graphs and rules, andfor exploring and visualising the GTS. The main technical contribution of thispaper is the integration of a Prolog interpreter into the groove Simulator.

2.1 Functionality Overview

Before executing Prolog queries, the standard groove functionality is used toperform a state space exploration of the graph grammar under analysis. Theexploration produces a GTS, which can then be inspected in queries. At thispoint it is important to stress the difference between states and state graphs. Astate is an element of the GTS; it is implemented as an object with a uniqueidentity and an associated state graph. A state graph is a host graph over whichthe transformation rules are applied.

We illustrate the Prolog functionality on the basis of a very small example.Figure 1 shows a GTS with three states, represented by dashed boxes: the startstate s0 and two successor states s1 and s2. Each of the states contains a stategraph, consisting of two nodes connected by an e-labelled edge. The state graphof s1 is obtained from the state graph of s0 by applying rule a2b (not shownhere) which renames an A-node to a B-node. Analogously, the state graph of s2

is produced by applying rule a2c. Now consider the following Prolog query:

?− state(X), state_graph(X,GX), has_node_type(GX,’A’),state_next(X,Y), state_graph(Y,GY), has_node_type(GY,’C’).

The query is composed of six predicates, interpreted conjunctively from left toright (the meaning of characters + and ? will be discussed in Section 2.2):

• state(?State) iterates over the states of the currently explored GTS.• state_graph(+State, ?Graph) binds the state graph of the given state to the

second argument; i.e., it retrieves the state graph associated with the givenstate.


• has_node_type(+Graph, +Type) succeeds if the given graph has at least onenode of the given type.

• state_next(+State, ?NextState) iterates over all successors of the given state.

The purpose of the query is to search for a state (variable Y) with a graph (GY)that has at least one node of type C and that has a predecessor state (X) whosegraph (GX) contains a node of type A. Running this query produces the followingresult, which correctly binds Y to state s2:

X = s0GX = Nodes: [n0, n1]; Edges: [n0−−A−−>n0, n1−−D−−>n1, n0−−e−−>n1]Y = s2GY = Nodes: [n0, n1]; Edges: [n0−−C−−>n0, n1−−D−−>n1, n0−−e−−>n1]YesMore?No

The output also shows the bindings for the other variables in the query. Thevalues printed for variables GX and GY are the toString representations of thebound graphs, which show their internal structure – this explains the edge listswith three elements.1 In the last two lines of the listing above, the user askedthe interpreter if there are more results for the query. Since there are no otherstates that satisfy the query constraints, the answer is negative. If the GTShad more states satisfying the query, continuing the execution would eventuallyproduce all of them. This is a consequence of the Prolog resolution procedure,which backtracks to predicate state_next, binding Y with other successors of X,as well as to state, binding X with other states of the GTS.

In addition to using the built-in groove predicates, users can also definetheir own Prolog predicates. This ability to expand the Prolog knowledge-base(illustrated on Section 3.3) improves the extensibility of the framework.

2.2 Implementation Overview

Figure 2 shows the main elements of the integration of Prolog into the Simu-lator. groove is written in Java, so in order to ease the coupling, we chosethe GNU Prolog for Java library2 [10] as our Prolog interpreter. The Simulatorstate in Figure 2 stands for the current snapshot of the Simulator configurationin memory. It contains Java objects that represent, among others, host graphs,transformation rules, and the GTS. The main block of Figure 2 is the glue code,which connects the Prolog interpreter to the rest of the Simulator. The glue coderegisters itself in the interpreter and is called back when a Prolog query is run.When called, the glue code inspects the Simulator state and tries to bind theJava objects with terms (variables) of the query.

1 groove uses an internal graph representation where nodes have very little structure;node types and flags are stored as special self-edges.

2 http://www.gnu.org/software/gnuprologjava/

http://www.gnu.org/software/gnuprologjava/


GROOVE Simulator

Simulator State

Host Graphs

Rules

GTS

· · ·

GlueCode

PrologInterpreter

inspect

register

call

unify terms

Fig. 2. Integration of the Prolog interpreter in the groove Simulator

Built-in Predicates. Each built-in groove predicate requires some glue code,written partly in Prolog and partly in Java. When the Prolog interpreter is cre-ated, an initialisation phase registers the built-in predicates with the interpreter.For instance, gts(−GTS) is a built-in predicate that binds the Java GTS objectto a Prolog variable. Predicate registration is done with the following query:

:− build_in(gts/1, ’groove.prolog.builtin.Predicate_gts’).

Predicate build_in is a special interpreter command for creating new predicates.The first argument specifies the predicate name and arity, the second one givesthe name of the Java class that implements the predicate functionality. Here isa simplified listing for the Java Predicate_gts class.

1 public class Predicate_gts extends PrologCode {2 public int execute(Interpreter interpreter, boolean backtracking, Term[] args) {3 GTS gts = getSimulatorState().getGTS();4 if (gts == null) {5 return FAIL;6 }7 return interpreter.unify(args[0], gts);8 }9 }

When gts(X) is evaluated in a query, the interpreter calls execute of Predicate_gts.The third argument of the method is an array of Prolog terms that correspondsto the arguments of the predicate — in this case, X. The method first inspectsthe Simulator state to retrieve the GTS object (line 3). If the object is null thequery fails, otherwise the object is bound to X (line 7).

Argument Modes. In the above, we have specified predicate signatures inwhich the parameter names were prefixed with special characters. These indicatethe interaction of the Prolog interpreter with arguments at that position:


+ Input parameter: the argument must already be bound to an object of theappropriate type. For example, has_node_type(+Graph,+Type) succeeds if thegiven graph has a node of the given type.

– Output parameter: the argument should be free, i.e., not bound to an object;it will receive a value through the query. For example, gts(−GTS) assigns theobject that represents the current GTS of the Simulator.

? Bidirectional parameter: can be used either as input or as output. For exam-ple, state(?State) may be used in two ways. If the argument is already boundto a state, the predicate either succeeds or fails depending on whether thatstate is part of the current GTS or not. If the argument is free, it will bebound to a state; backtracking will iterate over the remaining states.

Backtracking. The Prolog resolution procedure is a search for valid bindings,in the course of which it may backtrack and re-evaluate predicates to retrievefurther solutions. This implies that the implementation of the built-in predicatesmust handle backtracking. For example, the following is the Java glue code forpredicate state_next.

1 public class Predicate_state_next extends PrologCode {2 public int execute(Interpreter interpreter, boolean backtracking, Term[] args) {3 PrologCollectionIterator it;4 if (backtracking) {5 it = interpreter.popBacktrackInfo();6 } else {7 State state = getSimulatorState().getState(args[0]);8 it = new PrologCollectionIterator(state.getNextStateSet(), args[1]);9 interpreter.pushBacktrackInfo(it);

10 }11 return it.nextSolution();12 }13 }

The backtracking flag (line 2) is used by the interpreter to indicate if the predicateis being evaluated for the first time in a query or if it is being called againafter backtracking. During the first run, the else block (lines 7–9) is executed.First the state object is retrieved along with its set of successor states (callto state.getNextStateSet()). This set is put into a special iterator along with theargument to be bound (line 8), which is then passed to the interpreter andstored as backtrack information (line 9). When the method is called again duringbacktracking, the same iterator is retrieved from the interpreter (line 5) and thenext solution is returned.

3 Application to Feature Modelling

Feature models [15] are commonly used to support the configuration of productsin software product lines [18]. They model variability by expressing commonali-ties, variations and constraints between the different features that could be part


MandOpt

Featureselectedname: string

AltRequires

FeatureModelconfigured

ExcludesOr

FeatureTreeviolated

Constraintviolated

1feature1 0..* mandatory1feature2

2..*

or

0..*constraint

2..*alt

1tree

0..* optional

root1

Fig. 3. A type graph for feature models

of a product. A feature usually represents an aspect of the software in an earlyphase of the software life cycle, and the impact of the combination of features ispropagated across the phases until the actual product is implemented.

The analysis of feature models [5,25] is mostly concerned with verifying theirstatic properties with respect to allowed specifications and valid configurationsof the model. However, the specification of feature models and their configura-tion process go beyond the information in the model: they often involve multiplegroups with distinct interests and expertise, which informally express extra prop-erties of the features. Moreover, the definition of possible products depends onforces like market demands, user preferences, and the availability of assets at aspecific time (such as the software components for the related products). Thus,feature modelling is a domain which can strongly profit from the ability to defineand query static and dynamic properties of models, leading to richer analysistechniques. In particular, we can identify the following tasks in the analysis:

1. Model additional knowledge about features;2. Define domain properties independently on the models, in a declarative way;3. Simulate the configuration process;4. Query for valid configurations with respect to conditions not expressed in

the feature model;5. Analyse alternative configuration paths and investigate the evolution of con-

figuration stages.

We proceed to show how the Prolog extension for groove can be used to im-plement these tasks. First we give an overview of the relevant concepts in termsof a type graph, some example rules and a small example model; then we focuson the use of Prolog to query the resulting state space of the grammar.

3.1 Feature Model Type Graph

Figure 3 shows a type graph for feature models (in groove), based on thedefinitions given in [25]. The type FeatureModel represents a feature modelcomposed of two parts: a FeatureTree whose nodes represent Features, and a set


FeatureTree+ violated! violated

Featureselected

Orselected

or

(a)

Requires− violated

Featureselected

Feature+ selected! selected

feature2feature1

(b)

FeatureTree! violated

FeatureModel+ configured! configured

Constraintviolated

constraint tree

(c)

Fig. 4. Examples of graph production rules for feature model configuration. grooverules are represented in a single graph, with different colours and line strokes usedto distinguish different elements: black (continuous thin) elements are matched andpreserved, and red (dashed fat) elements are Negative Application Conditions (NACs).Node flags preceded by a character have especial roles: + indicates flag creation; − isflag deletion, and ! is a NAC on the flag.

of explicit Constraints between these features. The constraint Requires indicatesthat if the target node of feature1 is selected for a product, then the targetnode of feature2 should be selected as well. The constraint Excludes indicatesthat the target nodes of feature1 and feature2 cannot be both selected for thesame product. Type Feature has three subtypes: MandOpt, Or and Alt. Theedges from each of these subtypes to a Feature indicate which kinds of childfeatures each subtype can have. Leaf features of the tree are MandOpt featureswithout children. Finally, the flags configured , violated , and selected in the typegraph are used in GT rules to assist the configuration process and to enforce theidentification of valid configurations.

3.2 Product Configuration

A specific feature model is a graph instantiating Figure 3, initially without anyflags. The model is then configured using GT rules that encode the followingconstraints (some of which were discussed above):

1. The root feature must be selected first;2. When a MandOpt is selected, all mandatory children must also be selected;3. When an Or is selected, at least one of its children must also be selected;4. When an Alt is selected, exactly one of its children must also be selected;5. When a non-root feature is selected, its parent feature must also be selected.

Child features are selected on demand and violations of constraints are checkedat each step. This applies both to the implicit conditions of the FeatureTreeand to the explicit Requires and Excludes constraints in the model.

Each of the steps above is performed by a combination of graph transformationrules. For example, Figure 4(a) shows a rule used to detect a violation on theselection of a child feature of an Or (step 3); the rule in Figure 4(b) selects


a feature which is required by another, previously selected one and removesthe violation of the Requires constraint; and the rule in Figure 4(c) checks theconditions for the complete feature model to be correctly configured and marksit as configured . A valid configuration of the feature model is found when neitherthe constraints nor the feature tree are violated. Note that a tree violation ismodelled independently of the violation of explicit constraints between pair offeatures. A tree has a violation when one of the requirements listed above is notsatisfied, e.g., when the root feature is not selected. Each valid configurationselects a set of features that gives rise to a potential product of the product line.

Starting from the initial feature model, state space exploration generates a GTSresulting from all possible interleavings of rule applications. Each state representsthe feature model with a partial selection of features, some of which may form validconfigurations. Figure 5shows a completely configured featuremodel, immediatelyafter the application of the rule shown in Figure 4(c) (named FeatureModelConfig-uration in the grammar). This configuration has a set of selected features and noconstraint violations (violated flags). Note that the mandatory part of feature En-ergySaving does not have to be selected since the feature itself, which is optional,was not selected. Once generated, the GTS can be queried using Prolog.

3.3 Querying the State Space

We now come to the main point of the example, which is how Prolog may beused to analyse the state space. For instance, the following user-defined predicateextracts completely configured products:

product(Product) :−rule(’FeatureModelConfiguration’, Rule), % Get the rule object% Get the graph resulting from rule applicationrule_application_result(Rule, Graph),% Collect all features selected to compose the product.findall(Feature, selected_feature(Graph, Feature), Product).

The predicate searches for graphs resulting from the application of rule Feature-ModelConfiguration and then collects all selected features in this graph (usingfindall, which is a higher-order predicate provided by GNU Prolog). Successivecalls of product generate all valid models. For the initial, unconfigured version ofthe feature model this yields 50 products, including the one shown in Figure 5(composed of features HomeAuto, Surveil, AccidentDet, AlarmAuto, Alarm, andBell). Predicate product uses the following auxiliary predicate, which consultsinformation of the GTS.

rule_application_result(Rule, Graph) :−state(Source), % Get a source statestate_transition(Source, Transition), % Get a transition from source statetransition_event(Transition, Event), % Get the rule application event of the transitionruleevent_rule(Event, Rule), % Ensure that the given rule is the one that was appliedtransition_target(Transition, Target), % Get the target state of the transitionstate_graph(Target, Graph). % Get the graph of target state


MandOptname = "Siren"

MandOptselectedname = "HomeAuto"

Altname = "WhiteGoodsCtrl"

FeatureTree

MandOptname = "Remote"

MandOptname = "ClimateCtrl"

MandOptselectedname = "AccidentDet"

FeatureModelconfigured

Orselectedname = "Alarm"

MandOptname = "EnergySaving"

MandOptname = "SmartCtrl"

Orselectedname = "Surveil"

MandOptselectedname = "Bell"

MandOptname = "MotionDet"

Requires

MandOptselectedname = "AlarmAuto"

root

tree

or

mandatoryor

optional

feature1

feature2

alt

constraint

mandatory

alt

optional

optional

or

or

mandatory

Fig. 5. A valid configuration of the feature model

This predicate uses the rule application event associated with transitions ofthe GTS to ensure that the given rule is the one that was indeed applied inthe Transition. It is important to note that the GTS has a total of 312 states,representing all intermediate states that lead to one of the 50 configured featuremodels. These intermediate states allow the analysis of different evolution paths(formed by different rule application sequences) that lead to the same solution.Furthermore, the grammar contains rules to re-validate constraint violations,making it possible to reach a valid configuration even if a constraint was violatedin an intermediate state.

Another useful capability provided by the Prolog extension is the possibility todefine a knowledge base of additional model-related information. As an exam-ple, suppose that we are interested in products that satisfy a certain budgetconstraint. The following Prolog code sets the costs for each feature of the modeland defines what it means for a product to be within budget.

% Extra facts about feature costs.cost(’HomeAuto’, 1). cost(’Surveil’, 0). cost(’WhiteGoodsCtrl’, 10).cost(’AlarmAuto’, 10). cost(’EnergySaving’, 5). cost(’Siren’, 15).


cost(’AccidentDet’, 25). cost(’ClimateCtrl’, 10). cost(’Bell’, 10).cost(’MotionDet’, 25). cost(’Alarm’, 5). cost(’SmartCtrl’, 10). cost(’Remote’,10 ).

% Computes the cost of a product.sum_costs([], 0).sum_costs([H|T], Total) :− sum_costs(T, CT), cost(H, CH), Total is CH+CT.

% Checks if the given product is within the given budget.within_budget(Budget, Product) :− sum_costs(Product, Cost), Cost =< Budget.

The following query returns products with total cost smaller or equal to 70:

?− product(P), within_budget(70, P).

For our running example, this gives 11 products within the budget constraint.

4 Discussion and Related Work

In the previous section we showed how the Prolog extension for groove supportsthe graph-based representation of feature models, how extra model attributes canbe specified as Prolog predicates and how state space exploration can be usedto search for feature model configurations. Going back to the list of tasks inSection 3 (page 111), we see that, in fact, all of them are fulfilled.

4.1 Performance

There are two major points of evaluation regarding run-time performance ofthe tool set: (i) the time used to explore the state space and store the GTS;and (ii) the time needed to run the Prolog queries on a given GTS. Item (i)covers the standard functionality of groove, for which an extensive body ofwork exists [21,20,8,12], comprising performance evaluations of several aspectsof groove implementation and also comparisons with other tools. Item (ii)concerns the functionality introduced by the Prolog extension, which requires anew analysis.

For the running example of Section 3 the time necessary for building the GTSand performing the Prolog queries is negligible (around 2 milliseconds in total),since the state space is small. To properly exercise the tool, we used a grammarimplementing a solution for the leader election case study [16] proposed at theGraBaTs 2009 tool contest. The purpose of this case is to verify a protocol for theelection of a leader among a ring of processes. The state space size is exponentialon the number of processes, giving rise to very large transition systems.

The results of the experiments are given in Table 1. Column # States showsthe GTS size for an increasing number of processes. Columns ExplorationTime and Query Time give the time in milliseconds needed to explore thestate space and run the Prolog queries, respectively. We used a query similar tothe one given in Section 3.3, that collects all states of the GTS where a leader hasbeen elected. The last column lists the number of results returned by the query.


Table 1. Performance comparison of Prolog queries against state space size.

Growth Exploration Growth Query Growth# States Ratio Time (ms) Ratio Time (ms) Ratio # Results

10 251 < 1 252 5.2 347 1.4 3 4.1 10

473 9.1 1,000 2.9 30 9.0 846,358 13.4 6,001 6.0 294 9.9 1,008

113,102 17.8 140,961 23.5 12,238 41.6 15,840

From the times given in Table 1 it can be seen that the bulk of the running timeis spent on building the GTS, unsurprisingly. From the growth ratios we see thatthe query time increases linearly over the GTS size until the second-to-last line.However, at the last line of the table, the query time exhibits a larger growth,which can be explained by the large amount of backtracking done by the Prologinterpreter while running the query.

Although further experimentation is certainly in order, we consider these ini-tial performance results of the Prolog extension satisfactory.

4.2 Related Feature Modelling Approaches

The analysis of feature models is useful for several reasons, such as to efficientlyresolve the configuration constraints and to optimise the configuration calcula-tion. This analysis is the object of research in many directions, which differ in theexpressiveness of the models and in the configuration strategies. For example,generalised feature trees [25], propositional formulas [4] and constraint satisfac-tion problems [5] have been used for the purpose of analysing feature models.Although some of these algorithms are known to be quite efficient, the majordrawback of such approaches is the rigidity of the analysis method. A reviewof the current techniques for the automated analysis of feature models is givenin [6].

Extra feature attributes can be modelled in our approach in at least two ways:first, by adding new attributes to the graphs; or secondly, by defining predicatesin Prolog that represent such attributes. We chose the last form because thevalues of the attributes used can be quite volatile in this application domain.Again, it is possible to annotate the graph with all kinds of information, but thiswould hamper the flexibility of the approach.

We want to draw attention to the issue of staged configuration of productlines. A stage corresponds to the elimination of a set of configuration options;the selection of features is deferred through stages until no variability is left.Czarnecki et al. [9] handle staged configuration using a feature model notationthat supports the definition of feature cardinality. They explore the variabilityin a feature model per stage, which contains the features that can be selected.Hubaux et al. [14] propose a way to guide the configuration process using work-flows which enforce the staged configuration in a certain order. Both approaches


also handle inter-related feature models, in which the configuration order mattersbut is predefined and fixed over the whole configuration process.

We are able to generate all configuration stages of a feature model, as graphstates, and to inspect these stages in several ways: by querying in which orderthe features (especially the variable features) are selected, or also by makingseveral kinds of inspections in these stages. For example, our groove solutionsupports the analysis of configuration contexts in which a constraint has beenviolated. We can also add extra constraints which are combinations of conditionsin previous stages.

4.3 Related Tools

progres [23] is a specification language which provides several mechanisms fordefining graph properties, including derived attributes, restrictions and paths(unary and binary relations on nodes, which may be defined both textually andgraphically), graphical queries (called graph tests in progres), and constraints(structural conditions going beyond the expressive facilities of graph schemas).In contrast to the groove/Prolog integration, progres does not support ad-hoc queries on graphs, and it also does not support queries on graph transitionsystems.

Among other tools for the verification of graph transformation (GT) systemswe can cite Augur2 [17] and enforce [1]. Augur2 uses abstraction to verifyGT grammars with infinite state spaces. enforce acts as proof checker for thecorrectness high-level programs written as graph transformations. While boththese tools could be used to analyse the evolution of a graph to some degree,the explicit-state model checking approach of groove gives an advantage, sinceit provides a simpler representation of intermediate states that eases the under-standability for the layman user. For a more comprehensive comparison betweengroove and other GT tools see [11].

Concerning other existing combinations of graph transformation tools withProlog, as far as we are aware, there are only two similar approaches, embodiedby viatra2 [26] and vmts [27], both of which are GT-based tools for modeltransformation.

viatra2. Varró and Balogh [3] describe how viatra2 and Prolog can be used toimplement their so called Model Transformation by Example (MTBE) approach.

The purpose of MTBE is to semi-automatically derive model transformationrules from example relations between source and target model elements. Theseexample relations are represented in viatra2 using a mapping model, formed bythe source and target meta-models and a reference meta-model to interconnectthem. The mapping model is translated to Prolog clauses and an inductive learn-ing program is run, producing Prolog inference rules representing hypothesis thatare satisfied under the given clauses. These inference rules are then translatedback to a viatra2 representation and give rise to model transformation rulesthat can operate on instances of the source and target meta-models, following


the example relations given in the mapping model. This process can be repeatedin order to iteratively refine the rules produced.

From the above, it should be clear that the intended use of Prolog in thesetting of viatra2 is quite different from ours, and hence there is little basis fora deeper comparison.

vmts. At the GraBaTs 2009 tool contest, Siroki et al. [24] presented a solutionto the leader election case study using vmts and Prolog.

The goal of their approach is to check if the outcome of a set of model trans-formation rules applied to a given input model complies to certain properties.To perform this analysis, first the input model, the transformation rules andthe control flow graph specifying the order for rule applications are all trans-lated from the vmts format to a Prolog representation. Subsequently, the Prologresolution procedure is used to enumerate the possible output models of thetransformation. Finally, these output models are checked by Prolog predicatesthat express the properties one wants to assert.

Their use of Prolog resolution plays the same role as the state space explo-ration functionality of groove. However, their approach suffers from the needto translate vmts objects to Prolog. The Prolog resolution procedure is not ad-equate for the exploration of a graph-based state space and therefore gives poorperformance. Another consequence of the translation is the low readability ofthe generated Prolog clauses.


Summarising, the highlights of the approach described in this paper are:

– Prolog is tightly integrated with graph-based state space exploration;– Queries can uniformly combine static and dynamic aspects of graphs;– The framework supports user-defined Prolog facts and predicates.

We have demonstrated these advantages by applying the approach in the domainof feature modelling, where it gives rise to a competitive alternative to existing,more rigid frameworks.

We have implemented the above as an extension to groove. Although manyof the examples given in this paper could have been solved in groove using othermeans, the Prolog-based solutions are more convenient and elegant. Therefore,the extension improves usability, which is a key factor for success.

On a more general level, this paper shows that there is much to be gained whengraph transformation is connected to other techniques, and that this connectioncan be done in a simple, uniform way.

Future Work. There are two main points planned as future work.

– Prolog-based application conditions. One can associate Prolog queries to indi-vidual GT rules, to play the role of additional application conditions. When


a rule with a query is matched, the query is executed in the Prolog inter-preter, and only if the query succeeds the rule is applied. This functionalityis orthogonal to other application conditions already present in groove,such as NACs, and would give another option for controlling the flow of ruleapplications, in addition to rule priorities and control programs.

– Prolog-based state space exploration. One can also extend the groove explo-ration strategies with a condition based on a Prolog query. Every time a newstate is produced, the query is run, and if the query is successful the stateis added to the GTS. The effect is comparable to a global post-applicationcondition.

Availability. The Prolog extension described in this paper is implemented ingroove version 4.4.0, available at http://groove.cs.utwente.nl. The gram-mar for the solution given in Section 3 can also be downloaded at the sameaddress.

Acknowledgement. The integration of Prolog into groove is originally due toMichiel Hendriks.

References

1. Azab, K., Habel, A., Pennemann, K.H., Zuckschwerdt, C.: ENFORCe: A system forensuring formal correctness of high-level programs. In: Zündorf, A., Varró, D. (eds.)Proc. of the 3rd Int. Workshop on Graph-Based Tools. ECEASST, vol. 1 (2007)

2. Baier, C., Katoen, J.P.: Principles of Model Checking. MIT Press (2008)3. Balogh, Z., Varró, D.: Model transformation by example using inductive logic pro-

gramming. Software and System Modeling 8(3), 347–364 (2009)4. Batory, D.: Feature Models, Grammars, and Propositional Formulas. In: Obbink,

H., Pohl, K. (eds.) SPLC 2005. LNCS, vol. 3714, pp. 7–20. Springer, Heidelberg(2005)

5. Benavides, D., Trinidad, P., Ruiz-Cortés, A.: Automated Reasoning on FeatureModels. In: Pastor, Ó., Falcão e Cunha, J. (eds.) CAiSE 2005. LNCS, vol. 3520,pp. 491–503. Springer, Heidelberg (2005)

6. Benavides, D., Segura, S., Ruiz-Cortés, A.: Automated analysis of feature models20 years later: A literature review. Information Systems 35, 615–636 (2010)

7. Clocksin, W.F., Mellish, C.S.: Programming in Prolog. Springer (1984)8. Crouzen, P., van de Pol, J.C., Rensink, A.: Applying formal methods to gossiping

networks with mCRL and groove. In: Haverkort, B.R.H.M., Siegle, M., van Steen,M. (eds.) ACM SIGMETRICS Performance Evaluation Review, vol. 36, pp. 7–16.ACM, New York (2008)

9. Czarnecki, K., Helsen, S., Eisenecker, U.: Staged Configuration Using Feature Mod-els. In: Nord, R.L. (ed.) SPLC 2004. LNCS, vol. 3154, pp. 266–283. Springer, Hei-delberg (2004)

10. Diaz, D., Codognet, P.: The GNU Prolog system and its implementation. In: ACMSymposium on Applied Computing (SAC), vol. 2, pp. 728–732. ACM, New York(2000)

11. Ghamarian, A., de Mol, M., Rensink, A., Zambon, E., Zimakova, M.: Modellingand analysis using groove. International Journal on Software Tools for TechnologyTransfer (STTT) (March 2011)

http://groove.cs.utwente.nl


12. Ghamarian, A.H., Jalali, A., Rensink, A.: Incremental pattern matching in graph-based state space exploration. In: de Lara, J., Varró, D. (eds.) Proc. of the 4th Int.Workshop on Graph-Based Tools. ECEASST, vol. 32 (2010)

13. Habel, A., Pennemann, K.-H., Rensink, A.: Weakest Preconditions for High-LevelPrograms. In: Corradini, A., Ehrig, H., Montanari, U., Ribeiro, L., Rozenberg, G.(eds.) ICGT 2006. LNCS, vol. 4178, pp. 445–460. Springer, Heidelberg (2006)

14. Hubaux, A., Classen, A., Heymans, P.: Formal modelling of feature configura-tion workflows. In: Muthig, D., McGregor, J.D. (eds.) Software Product LinesConference (SPLC). ACM International Conference Proceeding Series, vol. 446,pp. 221–230. ACM (2009)

15. Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S.: Feature-orienteddomain analysis (FODA) feasibility study. Tech. rep., Carnegie-Mellon UniversitySoftware Engineering Institute (November 1990)

16. König, B.: Case Study: Leader Election, http://is.tm.tue.nl/staff/pvgorp/events/grabats2009/cases/grabats2009verification.pdf

17. König, B., Kozioura, V.: Augur 2 – A new version of a tool for the analysis ofgraph transformation systems. In: Bruni, R., Varró, D. (eds.) Proc. of the 5th In-ternational Workshop on Graph Transformation and Visual Modeling Techniques.ENTCS, vol. 211, pp. 201–210. Elsevier (2008)

18. Pohl, K., Böckle, G., van der Linden, F.J.: Software Product Line Engineering:Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus(2005)

19. Rensink, A.: Representing First-Order Logic Using Graphs. In: Ehrig, H., Engels,G., Parisi-Presicce, F., Rozenberg, G. (eds.) ICGT 2004. LNCS, vol. 3256, pp.319–335. Springer, Heidelberg (2004)

20. Rensink, A.: Isomorphism checking in groove. In: Zündorf, A., Varró, D. (eds.)Proc. of the 3rd Int. Workshop on Graph-Based Tools. ECEASST, vol. 1 (2007)

21. Rensink, A., Schmidt, Á., Varró, D.: Model Checking Graph Transformations: AComparison of Two Approaches. In: Ehrig, H., Engels, G., Parisi-Presicce, F.,Rozenberg, G. (eds.) ICGT 2004. LNCS, vol. 3256, pp. 226–241. Springer, Hei-delberg (2004)

22. Rensink,A.: The GROOVESimulator: A Tool for State Space Generation. In: Pfaltz,J.L., Nagl, M., Böhlen, B. (eds.) AGTIVE 2003. LNCS, vol. 3062, pp. 479–485.Springer, Heidelberg (2004)

23. Schürr, A., Winter, A.J., Zündorf, A.: The PROGRES approach: Language andenvironment. In: Ehrig, H., Engels, G., Kreowski, H.J., Rozenberg, G. (eds.) Hand-book of Graph Grammars and Computing by Graph Transformation, pp. 487–550.World Scientific Publishing Co., Inc., River Edge (1999)

24. Siroki, L., Vajk, T., Madari, I., Mezei, G.: vmts Solution of Case Study: LeaderElection, http://is.tm.tue.nl/staff/pvgorp/events/grabats2009/submissions/grabats2009_submission_18-final.pdf

25. van den Broek, P.M., Galvao, I.: Analysis of feature models using generalised fea-ture trees. In: Workshop on Variability Modelling of Software-Intensive Systems,No. 29 in ICB-Research Report, Universität Duisburg–Essen, Germany, pp. 29–35(January 2009)

26. viatra2– Visual Automated Model Transformations Framework,http://www.eclipse.org/gmt/VIATRA2/

27. vmts– Visual Modeling and Transformation System, http://vmts.aut.bme.hu/

http://is.tm.tue.nl/staff/pvgorp/events/grabats2009/cases/grabats2009verification.pdf

http://is.tm.tue.nl/staff/pvgorp/events/grabats2009/cases/grabats2009verification.pdf

http://is.tm.tue.nl/staff/pvgorp/events/grabats2009/submissions/grabats2009_submission_18-final.pdf

http://is.tm.tue.nl/staff/pvgorp/events/grabats2009/submissions/grabats2009_submission_18-final.pdf

http://www.eclipse.org/gmt/VIATRA2/

http://vmts.aut.bme.hu/

Graph Grammar Induction

as a Parser-Controlled Heuristic Search Process

Luka Furst1, Marjan Mernik2, and Viljan Mahnic1

1 University of Ljubljana, Faculty of Computer and Information Science,Trzaska cesta 25, SI-1000 Ljubljana, Slovenia

{luka.fuerst,viljan.mahnic}@fri.uni-lj.si2 University of Maribor, Faculty of Electrical Engineering and Computer Science,

Smetanova ulica 17, SI-2000 Maribor, [email protected]

Abstract. A graph grammar is a generative description of a graph lan-guage (a possibly infinite set of graphs). In this paper, we present a novelalgorithm for inducing a graph grammar from a given set of ‘positive’and ‘negative’ graphs. The algorithm is guaranteed to produce a gram-mar that can generate all of the positive and none of the negative inputgraphs. Driven by a heuristic specific-to-general search process, the algo-rithm tries to find a small grammar that generalizes beyond the positiveinput set. During the search, the algorithm employs a graph grammarparser to eliminate the candidate grammars that can generate at leastone negative input graph. We validate our method by inducing grammarsfor chemical structural formulas and flowcharts and thereby show its po-tential applicability to chemical engineering and visual programming.

Keywords: Graph grammars, graph grammar induction, graph gram-mar parsing, heuristic search.

1 Introduction

Despite a large variety of applications [1,5,17], graph grammars have seldombeen used for classifying, compressing, or characterizing graph sets. However,these potential roles would become far more important if grammars could beautomatically induced from graphs. For example, by inducing a graph grammarfrom a set of chemical structural formulas, one could acquire a classifier to dis-tinguish, e.g., biologically active substances from others, a way to compress largechemical databases, or a set of rules characterizing a given group of chemicals.

In this paper, we present a novel approach to inducing graph grammars frompositive and (optionally) negative graph examples. Our algorithm is guaranteedto produce a grammar that can generate all of the positive and none of the neg-ative examples. By formulating grammar induction as a best-first search processbiased towards small grammars, the algorithm may be expected to induce agrammar that generalizes beyond the observed examples. The search proceedsin the specific-to-general direction, starting with a trivial grammar that can


122 L. Furst, M. Mernik, and V. Mahnic

generate exactly the positive input graph set. As the algorithm progresses, itproduces increasingly smaller and more general candidate grammars. To pre-vent over-generalization, the algorithm is coupled with a graph grammar parser,which is used to check whether a given candidate grammar can generate anynegative input graph. If it can, it is immediately discarded.

In the domain of graph grammar induction, only few approaches have beenformulated as a parser-controlled search process. However, the main contributionof this paper is the generalization operator in the search process, i.e., the way ofproceeding from more specific to more general grammars.

The grammars induced by our algorithm constitute a subclass of the LayeredGraph Grammars (LGG) formalism [18] and can therefore be parsed using theRekers-Schurr parser [18,8]. The parsability of the target formalism makes itpossible to induce a grammar from both positive and negative examples, whichresults in a grammar suitable for classification purposes.

In this paper, we present two nontrivial applications of our algorithm. First,we induce a grammar of flowcharts comprising atomic, sequential, conditional,and iterative statements. As a second application, we induce a grammar of thestructural formulas of a subset of hydrocarbons (chemical compounds comprisingcarbon and hydrogen atoms). The potential applications of inducing grammarsfrom chemical formulas have already been mentioned. Induction of flowchartgrammars (and diagram grammars in general) may find its uses in visual pro-gramming tools. Graph grammars are often difficult to create ‘by hand’. Usingour approach, a tool could automatically induce a parsable graph grammar froma few user-provided sample graphs.

The rest of this paper is structured as follows: In Sect. 2, we give a review ofrelated work. Section 3 defines the basic concepts. Our approach is described inSect. 4 and experimentally validated in Sect. 5. Section 6 concludes the paper.

2 Related Work

The work on graph grammar induction has been fairly scarce. This fact can beattributed partly to the complexity of the problem itself and partly to the lackof efficient general parsers, which stems from the NP-hardness of the parsingproblem for many classes of graph grammars.

One of the first graph grammar induction approaches was proposed by Jeltschand Kreowski [10]. Their algorithm induces a hyperedge replacement (HR) gram-mar [19, Chap. 2] from a set of positive graphs by successive generalizations ofthe trivial initial grammar. Our approach is based on a similar idea, but weemploy a fairly different generalization operator and embed the generalizationscheme into a search algorithm.

Jonyer et al. [11] also induce grammars from positive graphs in a specific-to-general direction. In each generalization step, their algorithm determines the‘best’ (according to the Minimum Description Length principle) subgraph S inthe input set, replaces it with a single nonterminal vertex v, and adds the produc-tion v ::= S to the grammar. The generated productions are not equipped with

Graph Grammar Induction as a Parser-Controlled Heuristic Search Process 123

any embedding rules and can therefore only represent chains of similar graphsconnected with single edges. An improved version of this approach, proposedby Kukluk et al. [13], induces grammars that can represent sequences of graphssharing common edges. Recently, Brijder and Blockeel [4] presented a methodto induce a node-label controlled (NLC) grammar [19, Chap. 1] from a singlegraph containing a set of isomorphic subgraphs.

None of the approaches mentioned above makes use of a parser. Therefore,they cannot accept negative graphs, and the induced grammars are not suitablefor classification purposes. An approach that does employ a parser, although onlyto validate the final grammar produced by the induction algorithm, was proposedby Ates et al. [2]. They induce grammars from the Spatial Graph Grammarformalism [12], which is parsable in polynomial time but fairly restricted.

Our approach induces grammars that are both parsable and fairly powerful,at least in comparison to those of Jonyer et al. and Ates et al. Another advantageof our method is that the parser actively participates in the induction process.Unfortunately, the combination of the power and parsability of the target for-malism results in the exponential worst-case complexity of the parser and henceof the entire algorithm.

The problem of graph grammar induction has been inspired by that of stringgrammar induction [16], where many approaches are based on similar ideas asour method, i.e., specific-to-general search, parser-based validation, etc. [7,15].

Graph grammar induction is also related to the problem of metamodel infer-ence [9], where the goal is to induce a metamodel from a given set of models,and to that of model transformation by example [3], where the goal is to in-fer model transformation rules from a set of known transformation pairs. Sincemodel transformation rules can be represented as graph grammars in the TripleGraph Grammar (TGG) formalism [20], the model-transformation-by-exampleproblem can be formulated as a TGG induction problem.

3 Definitions

A directed graph G is a tuple (VG, EG, VLabelsG, ELabelsG, connG, vlabelG,elabelG), where VG, EG, VLabelsG, and ELabelsG are the sets of vertices, edges,vertex labels, and edge labels, respectively, connG : EG → VG×VG is the functiondefining the source and the target vertex for each edge, and vlabelG : VG →VLabelsG and elabelG : EG → ELabelsG are the functions defining the labels ofindividual graph elements. For convenience, let labelG(x) ≡ vlabelG(x) if x ∈ VG

and labelG(x) ≡ elabelG(x) if x ∈ EG. Unlabeled vertices and edges will betreated as if they were labeled with a special label φV and φE , respectively. Let|G| = |VG|+|EG| be the size of the graph G. Undirected graphs are defined in thesame way as directed ones, except that for each edge e, conn(e) is a two-elementset rather than an ordered pair. The subscripts in VG, EG, connG, etc., will beomitted when the associated graph is clear from context.

Graphs G and H are isomorphic (denoted G ≈ H) if there exists a bijec-tive vertex-to-vertex and edge-to-edge mapping (called isomorphism) h : G →


H that preserves labels and adjacencies, i.e., labelH(h(x)) = labelG(x) andconnH(h(e)) = h(connG(e)) for all x ∈ VG ∪ EG and e ∈ EG.

1 A graph His a subgraph of a graph G (denoted H � G) if VH ⊆ VG and EH ⊆ EG. Anoccurrence of a graph H in a graph G is a subgraph H ′ � G such that H ′ ≈ H .Let us define the neighborhood of a subgraph H � G in G (denoted NhG(H))as the set of all vertices in VG \ VH connected to at least one vertex in VH , i.e.,NhG(H) = {v ∈ VG \ VH | ∃w ∈ VH , e ∈ EG : connG(e) = (v, w) ∨ connG(e) =(w, v) ∨ connG(e) = {v, w}}.

Let [u : Ae : t−−→ v : B] (or [u : A e : t v : B]) denote a graph comprising a vertex

u labeled A, a vertex v labeled B, and an edge e labeled t with conn(e) = (u, v)(or conn(e) = {u, v}). Let [u(S)v] denote a graph comprising vertices u and v, asubgraph S such that Nh [u(S)v](S) = {u, v}, and an arbitrary number of edgesconnecting the vertices of S to the vertices u and v.

Let us now define the graph grammar formalism induced by our method. Agraph grammar is the quadruple GG = (T V , T E , NE , P), where T V , T E ,and NE = {#1, #2, . . .} are pairwise disjoint sets of terminal vertex labels,terminal edge labels, and nonterminal edge labels, respectively, and P is a set ofproductions of the form p : L ::= R, where L = LHS (p) (the left-hand side orLHS) and R = RHS(p) (the right-hand side or RHS) are connected graphs suchthat VLabelsL ⊆ VLabelsR ⊆ T V , ELabelsL ⊆ NE , and ELabelsR ⊆ T E ∪ NE .Additionally, each production has to belong to one of the following types:

Type I: Productions of this type take the form λ ::= R, where λ denotes thegraph with no elements (the null graph).

Type II: These productions take the form [u : Ae : #i−−−→ v : B] ::= [u(S)v] or

[u : A e : #i v : B] ::= [u(S)v], where {A,B} ⊆ T V and #i ∈ NE . The sub-graph S will be called the core, and the vertices u and v will be called

the guards. Productions of this type will often be written as [A#i−−→ B] ::=

[A(S)B ] or [A #i B] ::= [A(S)B].

Type III: These productions take the form [u : Ae : #i−−−→ v : B ] ::= [u

r−→ v] or[u : A e : #i v : B] ::= [u r v], where {A,B} ⊆ T V , #i ∈ NE , and r ∈ T E ∪NE . Productions of this type will often be written as [A

#i−−→ B] ::= [Ar−→ B ]

or [A #i B ] ::= [A r B].

For example, the grammar GG7 in Fig. 2 contains one production of each type(p7,1 belongs to type I, p7,2 to type II, and p7,3 to type III). The guard verticeson production RHSs are marked with small black circles. In the case of directedgrammars (e.g., in Fig. 1), the RHS guards are marked with ‘S’ and ‘T’. Theletter ‘S’ marks the vertex that coincides with the source vertex on the LHS.

To apply a type-II production p : [u : Ae : #i−−−→ v : B] ::= [u(S)v] to a graph G,

one has to (1) find an occurrence L′ of the graph [u : Ae : #i−−−→ v : B ] in G, (2)

replace in L′ the edge that corresponds to e with a copy S′ of the graph S, and

1 For any function f : A → B, let f((x, y)) = (f(x), f(y)) and f({x, y}) = {f(x),f(y)}.


(3) connect the vertices of S′ to the vertices corresponding to u and v in thesame way as the vertices of S are connected to the vertices u and v in RHS(p).

To apply a type-III production [u : Ae : #i−−−→ v : B ] ::= [u

r−→ v] to a subgraph

[u′ : Ae′ : #i−−−−→ v′ : B], the edge e′ has to be replaced with an edge labeled r .

To reverse-apply a production, this procedure is simply reversed. Undirectedproductions are applied and reverse-applied in the same way as directed ones. Asample grammar and a series of production applications is shown in Fig. 1. Thenotation L ::= R1 | . . . |Rs is an abbreviation for L ::= R1, . . . , L ::= Rs.

Fig. 1. Top row : The reference grammar for the flowcharts language. Bottom row : Aderivation of a sample flowchart. The application of the production p8 is highlighted.

A grammar GG covers a graph G if GG can generate G, i.e., if G can bederived from the null graph using the productions of GG . The language of agrammar GG is the set of all terminal-labeled graphs covered by GG. A parseris an algorithm that determines whether a given graph G belongs to the languageof a given grammar GG .

The RHSs of the type-I productions of a grammar GG will be collectivelycalled the base graphs of GG and denoted B(GG). The size of a grammar willbe defined as |GG| =

∑p∈P(GG) |p|, where |p| = |RHS(p)| if p is a type-I pro-

duction, and |p| = |RHS(p)|+ |LHS (p)| − 2 = |RHS(p)|+1 otherwise. (The twoguards are common to the LHS and RHS, hence ‘−2’.) A grammar GG1 is larger(or smaller) than a grammar GG2 if |GG1| > |GG2| (or |GG1| < |GG2|).

Our target grammar formalism can be regarded as a subset of both LGGand HR formalisms. Hyperedge replacement grammars consist of productionsfor replacing individual hyperedges with hypergraphs. A hyperedge is an edgethat connects an arbitrary sequence or multiset of vertices. (An ordinary edgeis therefore a special case of a hyperedge.) A hypergraph is a graph composed ofvertices and hyperedges. Type-I productions can be thus viewed as HR produc-tions with zero-arity hyperedges on their LHSs. Type-II and type-III productionsalso specify HR rules, since the guard vertices do not participate in the replace-ment process itself; rather, they only determine the context of replacement. Theguards correspond to external vertices in the HR terminology.


4 The Proposed Graph Grammar Induction Algorithm

In this section, we will often refer to Fig. 2, which shows the induction of agrammar from a single positive graph, namely the structural formula of butane.In this example, the final result is the grammar GG7.

4.1 Overview

The pseudocode of the induction algorithm is shown in Fig. 3. The inductionalgorithm induces a graph grammar from a set of positive graphs (G+) and (op-tionally) a set of negative graphs (G−) such that G+ ∩ G− = ∅. The algorithmaccepts two additional parameters (positive integers): beamWidth specifies thebeam width in the search process, and maxVertexCount determines the maxi-mum vertex count in the search for production cores (explained later).

The induction algorithm operates as a specific-to-general beam search pro-cess. Its search space can be visualized as a graph in which the vertices repre-sent individual candidate grammars and the edges represent possible elementarygeneralizations of candidate grammars. A candidate grammar is a grammar thatcovers all of the positive input graphs and none of the negative ones. An elemen-tary generalization step transforms a given candidate grammar GG into a newcandidate grammar that is at least as general as GG.

The goal of the algorithm is to find a candidate grammar of the minimumsize. By restricting its search to the space of candidate grammars, the algorithmis guaranteed to produce a correct grammar in terms of the coverage of the inputgraphs. Its preference for small grammars is likely to result in a grammar thatgeneralizes beyond the observed examples.

The algorithm starts with the most specific candidate grammar. This gram-mar, denoted GG1, consists of productions {λ ::= G |G ∈ G+} and thus coversprecisely the positive input set. During its execution, the algorithm maintains apriority queue of all candidate grammars that have been generated but not yetgeneralized. In each step, the algorithm removes the smallest grammar from thequeue and applies to it all possible elementary generalizations, producing a newset of candidate grammars. Each resulting grammar is verified by our improvedversion of the Rekers-Schurr parser [8]. If a grammar covers at least one negativeinput graph, it is immediately discarded; otherwise, it is placed into the queue.To reduce the computational effort, only the beamWidth smallest grammars arekept in the queue. When the queue becomes empty, the algorithm outputs thesmallest grammar created during the search process.

4.2 Elementary Generalizations

To perform a single step forward in our specific-to-general search, a given candi-date grammar is ‘slightly’ generalized or merely restructured without changingits generative power. This is achieved by elementary generalizations of two types,called ‘type A’ and ‘type B’.


Fig. 2. Inducing a grammar from the structural formula of butane


1 procedure induceGrammar(G+, G−, beamWidth, maxVertexCount )2 GG1 := the grammar with productions λ ::= G for each G ∈ G+;3 GGmin := GG1;4 Queue := {GG1};5 while Queue �= ∅ do6 GG := the smallest grammar from Queue;7 if |GG | < |GGmin| then GGmin := GG end;8 Queue := Queue \ {GG};9 NewProductions := findProductions(GG , maxVertexCount );

10 foreach p ∈ NewProductions do11 GG ′ := type-A generalization of GG via the production p;12 if GG ′ does not cover any graph from G− then13 GG ′′ := type-B generalization of GG ′ (if it exists);14 if GG ′′ exists and does not cover any graph from G− then15 Queue := Queue ∪ {GG ′′}16 else Queue := Queue ∪ {GG ′} end17 end18 end;19 retain the beamWidth smallest grammars in Queue and discard the others20 end;21 return GGmin

22 end

Fig. 3. The induction algorithm

Type-A Generalization. A type-A generalization of a candidate grammarGGadds a new type-II production p to GG and reverse-applies it to all occurrencesof RHS(p) in the base graphs of GG , resulting in a new grammar GG ′. InFig. 2, the addition of the production p3,2 to the grammar GG1 results in thegrammar GG3. The grammar GG3 is thus a type-A generalization of GG1 viathe production p3,2.

How can we find a type-II production p to transform a grammar GG intoGG ′? Since the base graphs of GG ′ are obtained by reverse-applying p to thebase graphs of GG , the base graphs of GG must contain at least one occurrenceof RHS(p), i.e., at least one subgraph of the form [u(S)v]. We thus search thebase graphs of GG for all possible subgraphs of the form [u(S)v]. Each suchsubgraph is an occurrence of the RHS of some type-II production, and each suchproduction is eligible to enrich the grammar GG . Since we cannot determine the‘best’ type-II production in advance, we have to consider all such productions,and thus we obtain many possible type-A generalizations of GG .

To simplify the explanation, let us first focus on undirected graphs and gram-mars. The process of finding type-II productions to generalize an undirectedgrammar GG is outlined in Fig. 4. The auxiliary procedure findSubgraphs (omit-ted for lack of space) finds all subgraphs comprising up to maxVertexCountvertices in the set of base graphs of GG . More precisely, the procedure creates aset of pairs (Subgraph, Occurrences), where Subgraph is a graph and Occurrences


is a set of pairs (Match, Host) such that Match is an occurrence of the graphSubgraph in the graph Host ∈ B(GG). The procedure findSubgraphs first findsall single-vertex subgraphs and then iteratively produces larger subgraphs assingle-vertex extensions of individual occurrences of smaller subgraphs. This ap-proach was inspired by a large selection of algorithms sharing similar goals [6],especially by the VSiGraM approach [14], which could be used in place of it.

1 procedure findProductions(GG , maxVertexCount )2 SubsAndOccs := findSubgraphs(B(GG),maxVertexCount );3 Productions := ∅;4 foreach (Subgraph ,Occurrences) ∈ SubsAndOccs do5 foreach (Match ,Host) ∈ Occurrences do6 if |NhHost (Match)| = 2 then7 call the two vertices in NhHost (Match) u and v ;8 A := label(u); B := label(v);

9 I := {i | [A #i B] is a subgraph in GG} ;10 if I = ∅ then k := 1 else k := max(I) + 1 end;11 foreach i ∈ I ∪ {k} do

12 Productions := Productions ∪ {[A #i B] ::= [A(Subgraph)B]}13 end14 end15 end16 end;17 return Productions18 end;

Fig. 4. Finding eligible type-II productions to generalize an undirected grammar GG

After receiving a set of subgraph-occurrence pairs, the procedure findProduc-tions searches this set for all subgraphs that can serve as possible productioncores (not entire RHSs!). For a subgraph S to serve as the core of a production,S must have exactly two neighbors in the base graph in which it occurs. Such asubgraph S gives rise to a type-II production p : [A #i B ] ::= [A(S)B], where #i

could stand for any nonterminal label. If the graph [A #i B] already occurs as asubgraph somewhere in the grammar, then the production p actually generalizesthe grammar GG; otherwise, GG is merely restructured. To take both possibili-ties into account, we create a separate production [A #i B] ::= [A(S)B] for each

i such that [A #i B] occurs as a subgraph in GG and for a single value of i thatdoes not meet this condition (lines 9–13 in Fig. 4). For example, the grammarGG3 in Fig. 2 is extended by the productions p5,3 (giving the grammar GG5)and p6,3 (giving the grammar GG6), which differ only in their LHS edge labels.

In the case of directed graphs and grammars, a production core [A(S)B ] can

serve as theRHS in two distinct production families, namely [A#i−−→ B] ::= [A(S)B]

and [B#i−−→ A] ::= [B(S)A]. Since neither of these families can be considered prefer-

able in advance, both should be added to the resulting production set. The family


[A#i−−→ B ] ::= [A(S)B] contains a production for each i such that [A

#i−−→ B] occursas a subgraph in GG and for a single value of i that does not meet this condition.The other family is defined in an analogous fashion.

After each type-A generalization step, the resulting grammar is simplifiedby reverse-applying its type-II productions to its base graphs wherever possibleand as many times as possible. This procedure is not essential for the inductionprocess, but can make the grammar considerably smaller.

Type-B Generalization. A type-B generalization of a candidate grammarGGreplaces two ‘similar’ productions of GG with a set of new productions, givinga grammar GG ′ that is at least as general as GG . In Fig. 2, the grammar GG5

is generalized to GG7 by replacing the productions p5,2 and p5,3 with p7,2 andp7,3. The notion of ‘similar’ productions is based on the concept of unifiability.

Edge labels l and m are unifiable (denoted l ∼= m) if (l = m)∨(l ∈ NE)∨(m ∈NE). The unification of unifiable edge labels l and m (denoted unif (l,m)) is thelabel l if l ∈ NE ; otherwise, unif (l, m) = m. Graphs G and H are unifiableif there exists a unifying isomorphism h : G → H , i.e., a bijective vertex-to-vertex and edge-to-edge mapping such that label(h(v)) = label (v), conn(h(e)) =h(conn(e)), and label (h(e)) ∼= label (e) for all v ∈ VG and e ∈ EG. The unificationof such graphs G and H (denoted unif (G,H)) is a graph obtained from G bysetting label (e) := unif (label (e), label(h(e))) for all edges e ∈ G.

Type-B generalization can be applied to a pair of directed productions p and

q if they take the form p : [u : Ae : #i−−−→ v : B] ::= [u(S)v] and q : [u′ : A

e′ : #i−−−−→v′ : B] ::= [u′(S′)v′] and if there exists a unifying isomorphism h : RHS(p) →RHS(q) such that h(u) = u′ and h(v) = v′. A type-B generalization step replaces

the productions p and q with a set that comprises: (1) a production [A#i−−→ B] ::=

[A(S′′)B], where S′′ = unif (S, S′) (let g : S′′ → S and g′ : S′′ → S′ denote the

corresponding unifying isomorphisms); (2) a production [P#j−−→ Q] ::= [P

r−→ Q ]for each edge e of S′′ such that label (conn(e)) = (P ,Q), label(e) = #j, andlabel(g(e)) = r ∨ label (g′(e)) = r . Undirected productions are treated in ananalogous manner.

5 Experimental Results

5.1 Application to Flowcharts

In our first series of experiments, we applied the induction algorithm to varioussets of valid flowchart graphs. Our goal was to induce a grammar that generates(a superset of) the language generated by the reference grammar in Fig. 1.We experimented with different sets of randomly generated flowchart graphsand different input parameters. Each input set comprised between 10 and 50graphs with up to 25 vertices. Different sets gave rise to different grammars,but in many cases, the algorithm induced the grammar shown in Fig. 5 or somevariation thereof. The productions p1 through p8 in Fig. 5 are equivalent to


the productions of the reference grammar despite the fact that all nonterminaledges are reversed. (Note the positions of the markers ‘S’ and ‘T’; in every type-II production, the source vertex on the LHS coincides with the bottom vertexon the RHS.) The induced grammar can therefore generate any valid flowchart.

Fig. 5. A grammar induced from various sets of valid flowcharts

5.2 Application to Chemical Structural Formulas

In our second series of experiments, we tried to induce a grammar of linear hydro-carbons with single and double bonds (LHSDB). This graph language comprisesthe structural formulas of chemical compounds consisting of carbon atoms (ver-tices labeled C) and hydrogen atoms (vertices labeled H). The carbon atomsform a chain connected with single and double bonds (edges). The hydrogenatoms are connected to the carbon atoms by means of single bonds so that ev-ery carbon atom has exactly four incident bonds. Some positive and negativeexamples of the LHSDB language are shown in Fig. 8. Our reference grammarfor this language is depicted in Fig. 6.

Fig. 6. The reference grammar for the LHSDB language

To make the induction problem more challenging, the induced grammar wasrequired to cover only valid (though not necessarily linear) hydrocarbons. Wethus demanded that the induced grammar cover all valid LHSDB graphs andthat every graph covered by the induced grammar represent a valid hydrocarbon.Experiments showed that such a grammar probably cannot be induced frompositive graphs alone. Moreover, a correct grammar could not be induced from‘almost any’ pair of input sets. A favorable combination of positive and negativeinput graphs had to be sought more systematically.


To determine whether a correct LHSDB grammar can be induced and fromwhat set of examples this can be achieved, we prepared a set of 42 positiveexamples (G+

0 ) and a set of 200 negative examples (G−0 ). The positive set com-

prised all correct LHSDB graphs with up to 6 carbon vertices. The negativeset was obtained by randomly removing one or two hydrogen atoms in correctLHSDB graphs with up to four carbon vertices. We then tried to find such subsetsS+ ⊆ G+

0 and S− ⊆ G−0 that the grammar induced from them would cover all

graphs from G+0 and none from G−

0 . The sets S+ and S− were obtained by a sim-ple procedure shown in Fig. 7. The resulting sets are displayed in Fig. 8, and thegrammar induced from them (using beamWidth = 10 and maxVertexCount = 5)is shown in Fig. 9. The size of the induced grammar equals 59. For comparison,the size of the reference grammar (Fig. 6) amounts to 54.

1 procedure findInputExamples(G+0 , G−

0 , beamWidth , maxVertexCount )2 S+ := {the smallest graph in G+

0 };3 S− := ∅;4 GG := induceGrammar(S+, S−, beamWidth , maxVertexCount );5 Missed+ := {G ∈ G+

0 |GG does not cover G};6 Missed− := {G ∈ G−

0 |GG covers G};7 while (Missed+ �= ∅) ∨ (Missed− �= ∅) do8 if Missed− �= ∅ then S− := S− ∪ {the smallest graph from Missed−}9 else S+ := S+ ∪ {the smallest graph from Missed+} end;

10 GG := induceGrammar(S+, S−, beamWidth, maxVertexCount );11 Missed+ := {G ∈ G+

0 |GG does not cover G};12 Missed− := {G ∈ G−

0 |GG covers G}13 end;14 return (S+,S−)15 end

Fig. 7. Extraction of a pair of small favorable input graph sets (S+ and S−) from apair of larger disjoint graph sets (G+

0 and G−0 )

The grammar of Fig. 9 meets the requirements stated above. By mathematicalinduction on the length of carbon vertex chains, we could prove that every validLHSDB graph can be generated by the induced grammar. To prove that thegrammar generates only valid hydrocarbon graphs, we would have to show thatevery vertex introduced by the grammar eventually obtains the correct numberof incident edges (four in the case of carbon vertices and one in the case ofhydrogen vertices). To see this, consider that any subgraph C #1 H expands

into C (. . .) H and that any subgraph C #2 H expands into C=(. . .) H.Given the input sets S+ and S− of Fig. 8, the induction algorithm was

shown to be robust to the parameters beamWidth and maxVertexCount, pro-vided that beamWidth ≥ 1 and maxVertexCount ≥ 3. The values 1 and 2for maxVertexCount cannot possibly produce any meaningful results, since theproduction p5 in Fig. 9, which seems to be an indispensable part of any valid


Fig. 8. The positive input set (S+) and the negative input set (S−) for the inductionof an LHSDB grammar

Fig. 9. The grammar induced from the input sets of Fig. 8

grammar, has three vertices in its core. We systematically varied both param-eters and ran the induction algorithm for each pair of values. The resultinggrammars were tested on a set of positive and negative graphs disjoint from G+

0

and G−0 .

5.3 Computational Complexity

Owing to the exhaustive subgraph enumeration procedure, which is the basisof type-A generalization, and to the Rekers-Schurr parser, our algorithm hasexponential worst-case complexity in terms of time and memory consumption.The complexity of subgraph search could be reduced at the cost of missing somesubgraphs. For example, the approaches of Jonyer et al. [11], Kukluk et al. [13],and Ates et al. [2] place an upper limit on the number of created subgraphs andhence run in a polynomial time and space at the cost of suboptimal results. Theimproved version of the Rekers-Schurr parser runs in polynomial time and spacefor many grammars [8], but its worst-case complexity is still exponential. Thisfact should not come as a surprise, since the problem of graph grammar parsingis NP-hard even for very restricted classes of grammars [19].

Table 1 shows the performance of our induction algorithm on the input graphset of Fig. 8 with respect to the parameters beamWidth andmaxVertexCount. Wemeasured the number of generated candidate grammars and the total executiontime of the algorithm on an 1.86-GHz Intel Core 2 Duo machine. The results for


different values of beamWidth (with maxVertexCount fixed at 5) are shown onthe left side of the table, and those for different values of maxVertexCount (withbeamWidth = 10) are displayed on the right side.

Figure 10 shows how the execution time depends on the number of inputexamples. To obtain the left chart, the number of negative examples was fixedat 200, and the number of positive examples was varied from 1 to 42 in the orderof increasing graph size. To draw the right chart, the number of positive exampleswas fixed at 42, and the number of negative examples was varied from 1 to 200 inno particular order. In both cases, the input examples were drawn from the setof 42 positive and 200 negative examples that were supplied to the procedure ofFig. 7 when searching for a favorable input set for hydrocarbons. The parametersbeamWidth and maxVertexCount were fixed at 10 and 5, respectively.

Table 1. The number of generated grammars and the total execution time with respectto the parameters beamWidth and maxVertexCount

beamWidth maxVertexCount

1 10 100 1000 3 5 7 9

Number of generated grammars 116 148 590 24 435 95 148 195 224Execution time (in seconds) 6.8 7.2 12.2 370 3.4 7.2 12.4 17.5

Fig. 10. Total execution time with respect to the number of input examples

The algorithm takes a little less than three minutes to finish if provided withthe entire set of 42 positive and 200 negative examples. However, the user isnot required to wait until the algorithm halts in order to obtain a meaningfulgrammar. Since the algorithm generates only grammars that are consistent withthe input set, its result (the current minimum grammar) is valid at any pointduring its execution. The longer the algorithm runs, the smaller and the moregeneral grammars it produces, but all induced grammars are valid with respectto the input set.


6 Conclusion

We have presented a novel graph grammar induction algorithm. Given a pair ofdisjoint graph sets, G+ and G−, the algorithm tries to find the smallest gram-mar that covers all graphs from G+ and none from G−. The induction processis realized as a parser-controlled specific-to-general search. We applied the pro-posed method to two meaningful and nontrivial graph languages. The algorithmexhibited a surprising inductive power when provided with favorable input.

In our ‘chemical’ example, a favorable input set was found by the algorithmin Fig. 7, which requires a pair of (large) initial input sets. To make the inputselection process more ‘user-friendly’, we are working on a tool with the follow-ing interaction scenario: First, the user prepares a (small) set of positive inputgraphs. The tool induces a grammar from this set and generates a set of randomgraphs covered by the induced grammar. The user can then visually inspect thegenerated graphs and add to the negative input set all those that do not belongto the target language. If there are no such graphs, he or she may prepare someadditional positive graphs and, by the help of the built-in parser, add to thepositive input set all those graphs that are not covered by the induced grammar.After that, the tool induces a new grammar based on the updated input sets.The process repeats until the user is satisfied with the induced grammar.

At present, our research is focused on more general target grammar for-malisms. In the formalism presented in this paper, a grammar for arbitraryhydrocarbons most probably does not exist. In the unrestricted LGG formalism,such a grammar comprises four simple productions (see the grammar GGHC inFig. 3 in [8]).

References

1. Aschenbrenner, N., Geiger, L.: Transforming Scene Graphs Using Triple GraphGrammars – A Practice Report. In: Schurr, A., Nagl, M., Zundorf, A. (eds.)AGTIVE 2007. LNCS, vol. 5088, pp. 32–43. Springer, Heidelberg (2008)

2. Ates, K., Kukluk, J.P., Holder, L.B., Cook, D.J., Zhang, K.: Graph grammar in-duction on structural data for visual programming. In: Proc. of the 18th IEEEInternational Conference on Tools with Artificial Intelligence, pp. 232–242. IEEEComputer Society, Washington, DC (2006)

3. Balogh, Z., Varro, D.: Model transformation by example using inductive logic pro-gramming. Software and Systems Modeling 8(3), 347–364 (2009)

4. Brijder, R., Blockeel, H.: On the inference of non-confluent NLC graph grammars.Journal of Logic and Computation (to appear, 2012)

5. Buchmann, T., Dotor, A., Uhrig, S., Westfechtel, B.: Model-Driven Software De-velopment with Graph Transformations: A Comparative Case Study. In: Schurr,A., Nagl, M., Zundorf, A. (eds.) AGTIVE 2007. LNCS, vol. 5088, pp. 345–360.Springer, Heidelberg (2008)

6. Cook, D.J., Holder, L.B.: Mining Graph Data. John Wiley & Sons, New Jersey(2006)

7. Dubey, A., Jalote, P., Aggarwal, S.K.: Learning context-free grammar rules froma set of programs. IET Software 2(3), 223–240 (2008)


8. Furst, L., Mernik, M., Mahnic, V.: Improving the graph grammar parser of Rekersand Schurr. IET Software 5(2), 246–261 (2011)

9. Javed, F., Mernik, M., Gray, J., Bryant, B.R.: MARS: A metamodel recoverysystem using grammar inference. Information and Software Technology 50(9-10),948–968 (2008)

10. Jeltsch, E., Kreowski, H.J.: Grammatical Inference Based on Hyperedge Replace-ment. In: Ehrig, H., Kreowski, H.-J., Rozenberg, G. (eds.) Graph Grammars 1990.LNCS, vol. 532, pp. 461–474. Springer, Heidelberg (1991)

11. Jonyer, I., Holder, L.B., Cook, D.J.: MDL-based context-free graph grammar induc-tion and applications. International Journal of Artificial Intelligence Tools 13(1),65–79 (2004)

12. Kong, J., Zhang, K., Zeng, X.: Spatial graph grammars for graphical user interfaces.ACM Transactions on Computer–Human Interaction 13(2), 268–307 (2006)

13. Kukluk, J.P., Holder, L.B., Cook, D.J.: Inferring graph grammars by detectingoverlap in frequent subgraphs. Applied Mathematics and Computer Science 18(2),241–250 (2008)

14. Kuramochi, M., Karypis, G.: Finding frequent patterns in a large sparse graph.Data Mining and Knowledge Discovery 11(3), 243–271 (2005)

15. Nakamura, K., Matsumoto, M.: Incremental learning of context free grammarsbased on bottom-up parsing and search. Pattern Recognition 38(9), 1384–1392(2005)

16. Parekh, R., Honavar, V.: Grammar inference, automata induction, and languageacquisition. In: Dale, R., Somers, H.L., Moisl, H. (eds.) Handbook of Natural Lan-guage Processing, pp. 727–764. Marcel Dekker, New York (2000)

17. Plasmeijer, R., van Eekelen, M.: Term Graph Rewriting and Mobile Expressions inFunctional Languages. In: Nagl, M., Schurr, A., Munch, M. (eds.) AGTIVE 1999.LNCS, vol. 1779, pp. 1–13. Springer, Heidelberg (2000)

18. Rekers, J., Schurr, A.: Defining and parsing visual languages with layered graphgrammars. Journal of Visual Languages and Computing 8(1), 27–55 (1997)

19. Rozenberg, G. (ed.): Handbook of Graph Grammars and Computing by GraphTransformations, vol. 1: Foundations. World Scientific, River Edge (1997)

20. Schurr, A.: Specification of Graph Translators with Triple Graph Grammars. In:Mayr, E.W., Schmidt, G., Tinhofer, G. (eds.) WG 1994. LNCS, vol. 903, pp. 151–163. Springer, Heidelberg (1995)

Planning Self-adaption

with Graph Transformations

Matthias Tichy1 and Benjamin Klopper2

1 Software Engineering Division,Chalmers University of Technology and University of Gothenburg,

Gothenburg, [email protected]

2 National Institute of Informatics (NII), Tokyo, [email protected]

Abstract. Self-adaptive systems autonomously adjust their behavior inorder to achieve their goals despite changes in the environment and thesystem itself. Self-adaption is typically implemented in software andoften expressed in terms of architectural reconfiguration. The graph trans-formation formalism is a natural way to model the architectural recon-figuration in self-adaptive systems. In this paper, we present (1) how weemploy graph transformations for the specification of architectural recon-figuration and (2) how we transform graph transformations into actionsof the Planning Domain Definition Language (PDDL) in order to use off-the-shelf tools for the computation of self-adaptation plans. We illustrateour approach by a self-healing process and show the results of a simulationcase study.

Keywords: Self-adaptive systems, graph transformations, planning,PDDL.

1 Introduction

The complexity of today’s systems enforces that more and more decisions aretaken by the system itself. This is resembled by the current trend to systemswhich exhibit self-x properties like self-healing, self-optimizing, self-adaption.Self-x properties cause additional complexity and dynamics within the system.Therefore, appropriate development approaches have to be employed. The archi-tecture is one of the key issues in building self-x systems [19,17]. In particular,self-adaptation can be realized by adapting the architectural configuration byadding and removing components as well as replacing them.

Kramer and Magee [17] presented a three-layer architecture for self-managedsystems consisting of the following layers: (1) goal management, (2) change man-agement, and (3) component control. The component control layer contains thearchitectural configuration of the self-adaptive system, i.e., the components andtheir connections which are active in a certain state. Besides the execution ofthe components, this layer is responsible for the execution of reconfiguration


138 M. Tichy and B. Klopper

plans. These plans, which describe the orderly adding, removing, and replacingof components and connectors, are executed to transform the current configura-tion into a new one in reaction to a new situation or event. They are stored inthe change management layer and computed by the goal management layer.

Several approaches [25,18,28,4,26] employ graph transformations for the speci-fication of architectural reconfiguration of self-adaptive systems. Graph transfor-mations enable the application of formal verification approaches (e.g., [21,3]) andcode generation [9] for execution during runtime by providing a sound formal basis.However, all of these approaches only address the modeling aspect of reconfigura-tion and do not address the computation of reconfigurationplans tomeet the goals.

In this paper, we present how graph transformations can be integrated withautomated planning approaches [12] to compute reconfiguration plans. We modelthe system structure using class diagrams and employ story patterns [9,29] asspecific graph transformation formalism. Additionally, we extend story patternsby modeling elements for temporal properties to enable temporal planning. Simi-lar to [6], we translate these models to the Planning Domain Definition Language[10] to enable the application of off-the-shelf planning software like SGPlan [5].

In the next section, we introduce the running example, which is about self-healing as a special case of self-adaptation, which is used to illustrate our ap-proach. Section 3 gives a short introduction how we model the structure and theself-adaption behavior of our running example. The translation of the models tothe planning domain definition language is described in section 4. Thereafter, wepresent an extension of our approach to durative actions and temporal planningin Section 5. In Section 6, we present results of simulation experiments for ourself-healing application scenario. After a discussion of related work in Section 7,we conclude with an outlook on future work in Section 8.

2 Example

As an application example, we consider the self-healing process in an automotiveapplication as presented in [16]. While it is currently not the case, we assumethat, in the future, it is possible that software components can be deployed,started and stopped on electronic control units (ECU) at runtime. Currently, thedeployment of software components to ECUs is done at design time but onlinereconfiguration gains interest and will eventually be realized. The AUTOSARstandard [11] with its standardized interfaces and the run-time environment(RTE) is the first step towards a system that can be reconfigured.

Our self-healing process reacts to failures of software components and hard-ware nodes (ECUs) by, for example, starting failed software components onworking nodes, moving software components from a source to a target node,disconnecting and reconnecting software components. While the original self-healing process [16] considers redundant software components, we do not con-sider redundancy in this paper in order to keep the examples smaller.

Figure 1 shows an example of our self-healing process. On the left hand sideof that figure, four nodes are shown which execute five component instances.node1 has experienced a failure and, thus, component c1 is not working anymore.

Planning Self-adaption with Graph Transformations 139

The self-healing process now reacts to this failure by computation and subse-quently execution of a self-healing plan. This self-healing plan is comprised of theactions transfer which transfers the code of a component to a node, the actioncreateInstance which instantiates the component of a node, and destroy whichdestroys a component instance on a node. For this example, the plan basicallyresults in moving component c2 from node2 to node3 in order to free up spaceto subsequently instantiate the failed component c1 on node node2.

State after execution of self-healing planState after failure of node1

node2node1

c1

Self-Healing

Self-Healing Plan

1) Transfer(c2, node2, node3)2) Destroy(c2)3) CreateInstance(c2, node3)4) CreateInstance(c1, node2)

c2

node4node3

c3

c5c4

node2node1

c1

node4node3

c3

c5c4 c2

Fig. 1. Self-healing a failure of node1

A good example of a safety-relevant automotive subsystem is an adaptivecruise control (ACC). An ACC is an advanced tempomat, its functionality isto accelerate the car to the driver specified velocity, if no obstacle is detected.If an obstacle is detected, the car is first decelerated and then controls the gapbetween the car and the obstacle (mostly another car). The adaptive in its namecomes from this change of behavior. Figure 2 shows the software componentsof a sample adaptive cruise control system. In this paper, we do not specificallytarget the self-healing of this adaptive cruise control system but address thegeneral case of self-healing component-based systems as a running example.

Fig. 2. Software components of an adaptive cruise control system [16]

3 Modeling with Graph Transformations

We employ the story pattern [9,29] graph transformation formalism, which istightly integrated with the UML. It employs class diagrams for the specifica-tion of structure (similar to typed graphs in graph transformations) and refinedcollaboration diagrams for the specification of a graph transformation.


3.1 Specification of Structure

Figure 3 shows the class diagram for our self-healing scenario. Each componentrepresents a software component. Pairs of components may have to communicatewith each other. Nodes represent the computation hardware which are used toexecute the software components. Before a component can be started on a node,the software code of the component has to be deployed to that specific node.Nodes are connected to other nodes. Components which communicate with eachother must be executed either on the same node or on connected nodes. Eachconnection provides a certain transfer rate.

+requiresMem:Int+size:Int+isDeployed:bool

Component

+avMem:Int

Node

+value:Int

TransferRate

*isDeployedTo

0..1isRunningOn

1*

sender

1*receiver

* avCon*reqCon

ComponentInstance

0..1instance

Fig. 3. Class diagram modeling the structure of the self-healing system

For the subsequent translation to PDDL, we require that for each class themaximum number of instances is specified by the developer. For our example,this maximum number of instances is known during design-time as the numberof component types is known as well as the number of nodes. The number ofcomponent instances is equal to the number of component types as we specificallychoose to have only a single instance of each component type in the system. Thus,this requirement is feasible for our scenario. This requirement is also typical inembedded systems. However, in other applications or domains this requirementmight not hold.

3.2 Specification of Self-adaption Actions

The reconfiguration actions are specified with story patterns which are typedover the class diagram presented in Figure 3, i.e., they transform instances ofthis class diagram.

Story patterns follow the single pushout [22] formalism. The left hand sideand the right hand side are merged into a single graph in story patterns. Inthis graph, all nodes and edges which are in the left hand side but not in theright hand side are marked as delete. These nodes and edges are deleted bythe execution of the rule. All nodes and edges which are in the right hand sidebut not in the left hand side are marked as create. They are created by theexecution of the rule. Simple negative application conditions can be modeled byappropriately annotating edges and nodes in the diagram. It is not allowed thatnegative nodes are attached to negative edges [29]. In contrast to standard storypatterns, we do not support bound objects.


source:Node avMem >= c.requiresMemavMem := avMem - c.requiresMem

k:Node

isDeployed := true

c:Component

isDeployedTo

isDeployedTo

isDeployedTo<<create>>

Fig. 4. Story pattern which specifies the deployment of a component c to node k

Figure 4 shows a story pattern which specifies the transfer of the code of acomponent c from a source node source to a target node k to enable starting thecomponent on that node. The fact that the code of a component is available on anode is modeled as the existence of an isDeployedTo link between the componentand the node. Additionally, the story pattern specifies that the amount of avail-able memory on node k must be greater than the required memory of componentc prior to execution. After execution the available memory is reduced.

isDeployedTocomp:Component node:Nodeotherci:ComponentInstance

ci:ComponentInstance

<<create>>

isRunningOn

instance

instance

Fig. 5. Story pattern which specifies the instantiation of a component on a node

Figure 5 shows the story pattern concerning the instantiation of a componenton a node. This story pattern can be executed if (1) the component’s code hasbeen previously deployed to the node and (2) the component is not alreadyinstantiated anywhere in the system. The first condition is expressed by the linkisDeployedTo between comp and node. The second condition is expressed by thenegative object otherci.

3.3 Specification of Goals

Finally, the goal has to be modeled for the self-healing system. Using only theleft hand side of story patterns as in [8], it is possible to model a concretesituation which shall be reached by the computed plan. Though, this is rathercumbersome, especially for a large number of objects. Instead we use enhancedstory patterns [24] which extend story patterns with subpatterns and quantifiers.Figure 6 shows the specification of the goal that for every component there shouldexist a component instance which is running on a node.

We do not provide modeling support for the initial state as the initial state issimply the current state of the self-adaptive system during runtime.


forall exists

instancec:Component ci:ComponentInstance n:Node

isRunningOn

Fig. 6. Enhanced story pattern modeling the goal

4 Translation to PDDL

There exist several different representations for planning problems [12]. Set-theoretic approaches represent states by a set of propositions. Each action spec-ifies which propositions have to hold in the state for the action to be applicable.Additionally, an action specifies which propositions will be added and removedto create a new state. The classical representation uses first-order literals andlogical operators instead of propositions.

The Planning Domain Definition Language (PDDL) has been developed as astandard language for planning problems in order to compare different tools andalgorithms. In order to be applicable for a wide variety of planning problems andtools, several extensions with respect to the classical representation have beenadded to the PDDL, e.g., typing, durative actions for temporal planning, fluentsfor representation of numerical values.

A planning problem in PDDL consists of two parts – the domain and theproblem. The domain defines the types, the predicates, the functions, and theactions. A PDDL action is defined by a name, a list of parameters, a preconditionand an effect. All objects which are referred to in the precondition and the effecthave to be included in the list of parameters. The action can only be executed ifthe precondition is satisfied. The effect holds after the execution of the action.The problem defines the objects as well as the initial state and the goal state.The planning system then tries to compute a sequence of actions (including thearguments for the action parameters) which transforms the initial state into thegoal state.

The PDDL extension :typing enables the modeling of types and generaliza-tion in the planning model. Thus, classes are translated to types in the domaindefinition; the associations are translated to predicates over the types. Story pat-terns are translated to actions in the planning domain. The left hand is translatedto the precondition and the right hand side to the effect. Although the elementsof both models map well to each other, there are details to consider.

4.1 Types, Predicates and Functions

Basically, classes are translated to types. Generalizations in the class diagramsare translated as well. Listing 1 shows the types generated from the class diagramof Figure 3. All types extend the general predefined type object denoted by thesuffix “- object”.


Listing 1: Mapping of classes to types in the PDDL1 (:types2 Component Node TransferRate ComponentInstance - object3 )

Associations are translated to predicates over the source and target types. Wesupport unidirectional and bidirectional associations. For example, the unidirec-tional association isDeployedTo between Component and Node is translated to thepredicate (isDeployedTo ?component - Component ?node - Node). Listing 2 showsthe predicates which are generated from the associations of the class diagram.For bidirectional associations, only one direction is translated to predicates inorder to minimize the planning domain as bidirectional navigability is alreadyprovided by an unidirectional reference in PDDL.

Listing 2: Translation of associations to predicates1 (:predicates2 (exist ?object - object)3 (isRunningOn ?component - Component ?node - Node)4 (reqConn ?component - Component ?component - Component)5 (instance ?component - Component ?componentinstance - ComponentInstance)6 (isDeployedTo ?component - Component ?node - Node)7 (avConnections ?node - Node ?node - Node)8 (sourceTransferRate ?node - Node ?transferrate - TransferRate)9 (targetTransferRate ?node - Node ?transferrate - TransferRate)

10 (runningOn ?componentinstance - ComponentInstance ?node - Node)11 (isDeployed ?component - Component)12 )

The PDDL prohibits the creation and deletion of objects to preserve a fi-nite state space. As node creation and deletion is an important feature of graphtransformations, we decided to emulate object creation and deletion by using thespecial predicate (exist ?object - object). We require a fixed number of objects ofeach type in the initial state of the planning problem. We emulate object cre-ation and deletion by setting the exist predicate appropriately. Finally, Booleanattributes are also translated to predicates, e.g., the attribute isDeployed.

Functions provide mappings from object tuples to the realm of real numbers.This enables the translation of all numerical attributes from class diagrams.For example, the function (avMem ?n - Node) stores the amount of that node’smemory which is increased and reduced depending on the number of componentswho are instantiated on a given node.

4.2 Actions

In the following, we present how story patterns are translated to PDDL actions.The preconditions and the effects of PDDL actions mirror naturally the left handside and right hand side of a graph transformation. Listing 4 shows the PDDLaction for the story pattern from Figure 4. We translate all nodes of the story


Listing 3: Translation of integer attributes to functions1 (:functions2 (requiresMem ?component - Component)3 (size ?component - Component)4 (avMem ?node - Node)5 (value ?transferrate - TransferRate)6 )

pattern to parameters of the action. The planner will bind these parameters toobjects in such a way that the precondition is satisfied. The action transfer hasthree parameters for the two nodes source and k and the component c. The

Listing 4: Transfer of component code from source to target node1 (:action transfer2 :parameters (3 ?source - Node ?k - Node ?c - Component4 )5 :precondition (and6 (exist ?source) (exist ?k) (exist ?c)7 (not (= ?source ?k))8 (isDeployedTo ?c ?source)9 (not (isDeployedTo ?c ?k))

10 (>= (avMem ?k) (requiresMem ?c))11 )12 :effect (and13 (isDeployedTo ?c ?k)14 (isDeployed ?c)15 (decrease (avMem ?k) (requiresMem ?c))16 )17 )

precondition requires that all bound objects are indeed existing (line 6). Thestory pattern formalism uses a graph isomorphism, i.e., that two nodes of thegraph transformation cannot be bound to the same node in the host graph.Consequently, we check in line 7 that the two nodes source and k are different.We translate the isDeployedTo-edge to the predicate in line 8.

The effect of the action simply states that the isDeployedTo predicate holdsfor the component c and the node k as the semantics of PDDL effects are thateverything remains unchanged except the explicitly stated effect.

Attribute Expressions. Arithmetic expressions are supported by PDDL func-tions. The precondition can contain comparisons concerning functions. Valuesare assigned to functions in the effect. Concerning the transfer action, the pre-condition checks whether the available memory is greater or equal than thememory required by the component in line 10. In line 15, the available memoryis decreased by this required amount of memory. Finally, the assignment of theBoolean variable isDeployed is part of the effect as well (line 14).


Negative Nodes and Edges. Story patterns enable the specification of simplenegative application conditions by annotating nodes and edges that the node orthe edge must not match.

The story pattern of Figure 4 contains a negative edge isDeployedTo betweencomponent c and node k. Thus, the story pattern is only applicable if the com-ponent c has not been already deployed to the node k. This is translated to anegated predicate as shown in line 9.

The case of a negative node is more complex. The semantics of a negativenode [29] is that the matching of the left hand side minus the negative nodemust not be extendable to include a matching of the negative node as well. Thisis translated to a negative existential quantification over the objects of this typeincluding the edges connected to the negative node as in lines 8 to 10 of Listing 5which is the PDDL translation of the story pattern shown in Figure 5.

Again, special care has to be taken concerning injective matching. If a nodeis already positively matched, it will be excluded from the negative existentialquantification.

Object Creation and Deletion. There exist several possibilities to emulateobject creation and deletion. Naively, objects can be emulated by predicateswhich are set to true and false accordingly. This does only work for the casethat it is not required that an object is identifiable. This is typically not suitablefor graph transformations. As mentioned earlier, we decided to allocate a fixednumber of objects of each class and use the additional predicate exist to denotewhether the object exists or not.

Listing 5 shows the PDDL translation of Figure 5. Similar to Listing 4, weinitially check for all nodes which are in the left hand side of the story patternwhether they exist in line 6. The object which will be created by the story patternmust not exist prior to the execution with the predicate in line 7. It is createdin the effect (line 16).

Listing 5: Creating objects1 (:action createInstance2 :parameters (3 ?comp - Component ?node - Node ?ci - ComponentInstance4 )5 :precondition (and6 (exist ?comp) (exist ?node)7 (not (exist ?ci))8 (not (exists (?otherci - ComponentInstance)9 (instance ?comp ?otherci)

10 ))11 (not (instance ?comp ?ci)) (not (runningOn ?ci ?node))12 )13 :effect (and14 (instance ?comp ?ci)15 (runningOn ?ci ?node)16 (exist ?ci)17 )18 )


Listing 6 shows how objects are destroyed by an action. The story patternformalism follows the single pushout approach [22]. Therefore, we do not requirethat the dangling condition is satisfied and simply delete all edges related to thenode (lines 6 and 7). The class diagram (see Figure 3) holds the informationwhich edges we have to remove when destroying an object.

Listing 6: Destroying objects1 (:action destroy2 :parameters (?ci - ComponentInstance))3 :precondition (and (exist ?ci))4 :effect (and5 (not (exist ?ci))6 (forall (?o - Node) (not (runningOn ?ci ?o)))7 (forall (?o - Component) (not (instance ?o ?ci)))8 )9 )

The model of the goal state shown in Figure 6 is translated to the PDDL in asimilar way as the left hand side of story pattern with appropriate handling ofthe quantification.

5 Adding Temporal Properties

PDDL 2.1 [10] introduced syntax and semantics for temporal planning. Temporalplanning relaxes the assumption of classical planning that events and actionshave no duration. This abstraction is often not suitable as in reality actions dooccur over a time span. Therefore, durations can be annotated to actions intemporal planning. As this allows concurrent actions, preconditions and effectshave to be annotated. Three different temporal annotations are supported whichcan be combined: (1) at start, the precondition has to be satisfied at the beginningof the action, (2) at end, the precondition has to be satisfied at the end of theaction, and (3), over all, the precondition has to be satisfied during the action.Effects have to be annotated with at start or at end.

tr:TransferRatesource target

source:Node avMem >= c.requiresMem <<atstart>>,<<overall>>avMem := avMem - c.requiresMem <<atstart>>

k:Node

isDeployed := true

c:Component

<<atstart>>,<<overall>>isDeployedTo

isDeployedTo

isDeployedTo<<create>>

duration = c.size / tr.value

Fig. 7. Story pattern which specifies the deployment of a component c to node kincluding a duration


In general, story patterns do not consider time. Timed story patterns [14] areonly concerned with when the pattern is executed, but not about the durationof its execution. We extend the story pattern by a duration fragment, which isused for the specification of the duration. Figure 7 shows this extension. Theduration is computed based on the component size and the transfer rate for theconnection between the nodes in our example. We annotate elements of the storypattern with the stereotypes �atstart�, �atend�, �overall� to specify therequired temporal properties.

Listing 7: durative-action transfer1 (:durative-action transfer2 :parameters (?c - component ?k - Node ?source - Node ?tr - TransferRate)3 :duration (= ?duration (/ (size ?c) (value ?tr)))4 :condition (and5 . . .6 (over all (isDeployedTo ?c ?source))7 (at start (isDeployedTo ?c ?source))8 (at start (sourceTransferRate ?rate ?source))9 (at start (targetTransferRate ?rate ?target))

10 . . .11 )12 :effect (and13 (at end (isDeployedTo ?c ?k))14 (at end (isDeployed ?c ))15 (at start (decrease (avMem ?k) (requiresMem ?c)))16 )17 )

In contrast to the PDDL, we assume the following defaults in the case thatthe developer does not specify temporal stereotypes for the sake of visual clarity.All elements of the left hand side are assumed to have the stereotype�atstart�whereas all effects are assumed to have the stereotype �atend�.

Listing 7 shows an excerpt from the durative action generated from the storypattern of Figure 7. The specification of the duration is shown in line 3. Duringthe whole execution of the action, the component c must be deployed to thesource node. As the temporal plan can schedule actions in parallel, we requirethat at the beginning of the action the available memory of node k must alreadybe decreased by the required amount of component c.

6 Simulation Experiments

In order to show the feasibility of our approach, we conducted simulationexperiments for the self-healing scenario. The scenario has been extended byresources which are required by components and provided by nodes, communi-cation buses between the nodes as well as redundant allocation of componentsto nodes. The discrete event-based simulation environment simulates (1) failuresof nodes, (2) repairs of nodes, and (3) periodic self-healing activities which arecomprised of computing and executing self-healing plans. We abstract from theactual behavior of the components and restrict the simulation to the failures


and the self-healing process. The plans are computed by the SGPlan automatedplanning software. The simulated system consists of 12 component types and 5nodes connected by two communication buses. Node failures are randomly dis-tributed by a negative exponential distribution fλ(x) = λe−λx with a failurerate of λ = 0.0001. Every 5 time units, the self-healing part of the system checkswhether any component type is not instantiated. In that case the planner iscalled and the resulting plan is executed.

Fig. 8. Results from the simulation experiments

On the left side of Figure 8, the number of available component instancesat each point of a single simulation run for 100.000 time units is shown. Thecomplete system is available if each component type is instantiated on a node,i.e., if 12 component instances are available. At 53 points in time, a node failswhich results in the failure of the components which are instantiated on thatnode. 10 of that 53 failures did happen to nodes which had no component typesinstantiated and, thus, resulted in no reduction of the number of componentinstances. After computing and executing the self-healing plan in reaction to anode failure, the number of available component instances increases to 12 again.

In the middle of Figure 8, the average availability of the system during thesame simulation run is shown. We define availability as the probability thatall component types of the system are instantiated at a certain point of time.The system starts with no instantiated components. Consequently, the averageavailability rises at the start of the simulation and reacts heavily to node failures.At the end of the simulation run, it is stable at 0.9995.

On the right side of that figure, we report the time taken by the planner tocompute the plan as well as the planning length based on 277 calls to the planner.The planner is executed on an Intel Core2Duo with two cores at 2,53 GHz and4 GB of RAM. Though, the planner uses only one core.

7 Related Work

In [4], a model-driven approach for self-adaption has been presented which alsoapplied graph transformations for the specification of component reconfigura-tions. The graph transformations are used to specify goals, but the approach


supports only the monitoring of these goals and not the computation of recon-figuration plans to achieve them. In general, planning is an important method inself-adapting and self-configuring systems. For instance, Arshad et al. [2] intro-duced a PDDL planning domain for automated deployment and reconfigurationof software in a distributed system. Satzger et al. [23] introduced a PDDL basedplanning approach for organic computing systems. Sykes et al. present in [13]an approach for planning architectural reconfiguration of component based sys-tems based on the aforementioned three layer-architecture. They employ modelchecking as a planning technique based on labeled transition systems. This al-lows them to compute reactive plans, which generates actions sequence fromevery state in the state spaces towards the goal state.

None of the approaches supports the system developer appropriately in defin-ing the required planning domains and offer techniques to check the correctnessof the defined planning domain. A development process based on graph trans-formation naturally enables the support of respective modeling and verificationtools and methods.

Vaquero et al. [27] present an approach for transforming UML models, usecases, class diagrams, state machines, and timing diagrams, to Petri Nets aswell as PDDL in order to facilitate analysis and testing of requirements. Theshown mapping from class diagrams to PDDL is similar to the one presentedin this paper. In contrast to the approach by Vaquero et al., we use graphtransformations for the specification of behavior which are more suitable for thespecification of architectural reconfiguration.

There are only few tools and methodologies which support the designer indeveloping a planning model that complies to certain properties. For instance,Howey [15] et al. introduce VAL an automated tool that checks if plans gener-ated by a planning system satisfy the specification made in the correspondingPDDL domain. Differently, PDVer is a tool that can be applied to check thecorrectness of Planning Domains [20]. However, PDVer does not formally verifythe state transitions enabled by the planning domain, but heuristically generatesand executes a number of test cases.

There are only a few approaches in the area of automated planning withgraph transformations [6,8]. Edelkamp and Rensink present in [6] the combi-nation of graph transformation and planning. They report that the employedplanner (FF) can handle significantly bigger models than the graph transforma-tion tool Groove. In contrast to our paper, Edelkamp and Rensink do not presenthow to automatically translate graph transformations to the input language ofthe employed planner. Estler [8] uses an A* as well as a Best First search for thecomputation of plans based on graph transformations. Instead of developing anown algorithm for planning, we employ standard off-the-shelf planning softwarewhich enables us to exploit their good performance and rich modeling properties,e.g., for temporal planning.



We presented how graph transformation was used to specify actions for self-adaptive systems and how we use standard off-the-shelf automated planners tocompute reconfiguration plans which order the execution of the reconfigurationactions. As a specific case of self-adaption we illustrated our approach by a self-healing process. We extended the employed story pattern formalism by severaladditional annotations for the specific case of durative actions in temporal plan-ning. Based on this extensions, we showed how we translate story pattern to thePlanning Domain Definition Language (PDDL) which is the standard planninglanguage.

We have partially implemented the translation using the Eclipse ModelingFramework and Xpand as model-to-text translation environment. We used theEMF-based version of Fujaba, which is currently under development. We arecurrently working on finishing the implementation of the presented translation ofattribute expressions as well as all syntax elements which are related to temporalplanning.

Durative actions in the PDDL also include continuous effects which specifythe continuous change of values during execution of the action, e.g., the physicalposition of an autonomous car based on its speed. It remains to be seen whetherit makes sense to add those aspects to story patterns. Adding this might lead toa hybrid graph transformation formalism analogous to hybrid automata [1].

To reflect the specific strength and weaknesses of different planners as wellas the differing requirements of application domains, it is reasonable to providedifferent translation schemes for story patterns to PDDL. The implementationand comparison of these different translations with respect to their effect onplanners is an important part of our future research.

Story diagrams add control flow to story patterns. In order to use story di-agrams for self-healing, we have to translate the control flow to PDDL as well.For the case of non-temporal planning, this works by numbering all story pat-terns and adding a sequence function which stores the current activity number.The control flow is then translated to appropriately handling this function inthe precondition and the effect.

Acknowledgments. We thank Steffen Ziegert, Julian Suck, Florian Nafz, andHella Seebach for discussions about the topic. We thank Christopher Gerking forthe implementation of the prototypical translation of story patterns to PDDLas well as Alexander Stegmeier for the implementation of the simulation en-vironment. Matthias Tichy was member of the software engineering group atthe University of Paderborn, Germany, and the organic computing group at theUniversity of Augsburg, Germany, while developing this approach. BenjaminKlopper is a visiting researcher at NII and scholarship holder of the GermanAcademic Exchange Service (DAAD).


References

1. Alur, R., Courcoubetis, C., Halbwachs, N., Henzinger, T.A., Ho, P.H., Nicollin,X., Olivero, A., Sifakis, J., Yovine, S.: The algorithmic analysis of hybrid systems.Theoretical Computer Science 138(1), 3–34 (1995)

2. Arshad, N., Heimbigner, D., Wolf, A.: Deployment and dynamic reconfigurationplanning for distributed software systems. Software Quality Journal 15(3), 265–281(2007)

3. Becker, B., Beyer, D., Giese, H., Klein, F., Schilling, D.: Symbolic invariant ver-ification for systems with dynamic structural adaptation. In: Proc. of the 28thInternational Conference on Software Engineering, pp. 72–81. ACM Press (2006)

4. Becker, B., Giese, H.: Modeling of correct self-adaptive systems: A graph transfor-mation system based approach. In: Proc. of the 5th International Conference onSoft Computing as Transdisciplinary Science and Technology, pp. 508–516. ACM,New York (2008)

5. Chen, Y., Wah, B.W., Hsu, C.W.: Temporal planning using subgoal partitioningand resolution in SGPlan. J. Artif. Intell. Research 26, 323–369 (2006)

6. Edelkamp, S., Rensink, A.: Graph transformation and AI planning. In: Edelkamp,S., Frank, J. (eds.) Knowledge Engineering Competition. Australian National Uni-versity, Canberra (2007)

7. Ehrig, H., Engels, G., Kreowski, H.-J., Rozenberg, G. (eds.): TAGT 1998. LNCS,vol. 1764. Springer, Heidelberg (2000)

8. Estler, H.C., Wehrheim, H.: Heuristic search-based planning for graph transforma-tion systems. In: Proc. of the Workshop on Knowledge Engineering for Planningand Scheduling (KEPS 2011), pp. 54–61 (2011)

9. Fischer, T., Niere, J., Torunski, L., Zundorf, A.: Story diagrams: A new graphrewrite language based on the Unified Modeling Language and Java. In: Ehriget al. [7], pp. 296–309

10. Fox, M., Long, D.: PDDL2.1: An extension to PDDL for expressing temporal plan-ning domains. J. Artif. Intell. Research 20, 61–124 (2003)

11. Furst, S., Mossinger, J., Bunzel, S., Weber, T., Kirschke-Biller, F., Heitkamper,P., Kinkelin, G., Nishikawa, K., Lange, K.: AUTOSAR – A worldwide standard ison the road. In: Proc. of the 14th International VDI Congress Electronic Systemsfor Vehicles 2009. VDI (2009)

12. Ghallab, M., Nau, D., Traverso, P.: Automated Planning – Theory and Practice.Morgan Kaufmann Publishers (2004)

13. Heaven, W., Sykes, D., Magee, J., Kramer, J.: A Case Study in Goal-Driven Ar-chitectural Adaptation. In: Cheng, B.H.C., de Lemos, R., Giese, H., Inverardi, P.,Magee, J. (eds.) Self-Adaptive Systems. LNCS, vol. 5525, pp. 109–127. Springer,Heidelberg (2009)

14. Heinzemann, C., Suck, J., Eckardt, T.: Reachability analysis on timed graph trans-formation systems. ECEASST 32 (2010)

15. Howey, R., Long, D., Fox, M.: VAL: Automatic plan validation, continuous effectsand mixed initiative planning using PDDL. In: Proc. of the Int. Conference onTools with Artificial Intelligence, pp. 294–301. IEEE Computer Society (2004)

16. Klopper, B., Honiden, S., Meyer, J., Tichy, M.: Planning with utilities and statetrajectories constraints for self-healing in automotive systems. In: Proc. of the 4thIEEE International Conference on Self-Adaptive and Self-Organizing Systems, pp.74–83. IEEE Computer Society (2010)


17. Kramer, J., Magee, J.: Self-managed systems: An architectural challenge. In: Futureof Software Engineering 2007, pp. 259–268. IEEE Computer Society (2007)

18. Le Metayer, D.: Describing software architecture styles using graph grammars.IEEE Transactions on Software Engineering 24(7), 521–533 (1998)

19. Oreizy, P., Medvidovic, N., Taylor, R.N.: Architecture-based runtime software evo-lution. In: Proc. of the 20th International Conference on Software Engineering, pp.177–186. IEEE Computer Society (1998)

20. Raimondi, F., Pecheur, C., Brat, G.: PDVer, a tool to verify PDDL planning do-mains. In: Proc. of ICAPS 2009 Workshop on Verification and Validation of Plan-ning and Scheduling Systems (2009)

21. Rensink, A.: The GROOVE Simulator: A Tool for State Space Generation. In:Pfaltz, J.L., Nagl, M., Bohlen, B. (eds.) AGTIVE 2003. LNCS, vol. 3062, pp. 479–485. Springer, Heidelberg (2004)

22. Rozenberg, G.: Handbook of Graph Grammars and Computing by Grah Transfor-mation, vol. 1: Foundations. World Scientific (1997)

23. Satzger, B., Pietzowski, A., Trumler, W., Ungerer, T.: Using Automated Planningfor Trusted Self-organising Organic Computing Systems. In: Rong, C., Jaatun,M.G., Sandnes, F.E., Yang, L.T., Ma, J. (eds.) ATC 2008. LNCS, vol. 5060, pp.60–72. Springer, Heidelberg (2008)

24. Stallmann, F.: A Model-Driven Approach to Multi-Agent System Design. Ph.D.thesis, University of Paderborn (2009)

25. Taentzer, G., Goedicke, M., Meyer, T.: Dynamic change management by dis-tributed graph transformation: Towards configurable distributed systems. In: Ehriget al. [7], pp. 179–193

26. Tichy, M., Henkler, S., Holtmann, J., Oberthur, S.: Component story diagrams:A transformation language for component structures in mechatronic systems. In:Postproc. of the 4th Workshop on Object-oriented Modeling of Embedded Real-Time Systems. HNI Verlagsschriftenreihe (2008)

27. Vaquero, T.S., Silva, J.R., Ferreira, M., Tonidandel, F., Beck, J.C.: From require-ments and analysis to PDDL in itSIMPLE3.0. In: Proc. of the International Com-petition on Knowledge Engineering for Planning and Scheduling (2009)

28. Wermelinger, M., Fiadeiro, J.L.: A graph transformation approach to softwarearchitecture reconfiguration. Sci. Computer Programming 44(2), 133–155 (2002)

29. Zundorf, A.: Rigorous Object Oriented Software Development. University of Pader-born (2002)

From Graph Transformation Units

via MiniSat to GrGen.NET

Marcus Ermler, Hans-Jorg Kreowski, Sabine Kuske, and Caroline von Totth�

University of Bremen, Department of Computer SciencePO Box 33 04 40, 28334 Bremen, Germany

{maermler,kreo,kuske,caro}@informatik.uni-bremen.de

Abstract. In logistics and other application areas, one faces many in-tractable and NP-hard problems like scheduling, routing, packing, plan-ning, and various kinds of optimization. Many of them can nicely andcorrectly be modeled by means of graph transformation. But a graphtransformation engine fails to run the solutions properly because it doesnot have any mechanisms to overcome or circumvent the intractability.In this paper, we propose to combine the graph transformation engineGrGen.NET with the SAT solver MiniSat to improve the situation. SATsolvers have proved to run efficiently in many cases in the area of chipdesign and verification. We want to take these positive experiences upand to use the SAT solver as a tentative experiment for assisting thegraph transformation engine in finding solutions to NP-hard problems.

1 Introduction

Rule-based systems are nondeterministic in general because several rules may beapplicable to some system state or one of the rules at several matches. In somecases, the nondeterminism is desired or harmless. A game would be extremelyboring if there would be always a single step to perform (or none at all). A de-terministic Chomsky grammar generates a single terminal word or the empty setand is more or less meaningless therefore. Sorting by exchanging two elementsper step that are in the wrong order is nondeterministic, but yields always thesame result whenever done as long as possible. Shortest paths, Eulerian cycles,minimum spanning trees or maximum flows can be computed nondeterminis-tically in polynomial time with different results in general, but each result isacceptable. In many other cases, nondeterminism makes trouble. Even if eachsingle run takes polynomial time, there may be an exponential number of runsfor a given initial state and only a few of them may yield acceptable final statesor none at all. Hence, if one runs such a rule-based system for some initial stateonce or for a small fixed number of attempts and no final state occurs, there may

� The authors would like to acknowledge that their research is partially supportedby the Collaborative Research Centre 637 (Autonomous Cooperating Logistic Pro-cesses: A Paradigm Shift and Its Limitations) funded by the German Research Foun-dation (DFG).


154 M. Ermler et al.

be none or there may be one, but reachable by another run only. An exhaustivesearch is exponential, and any heuristic search may terminate fast, but fail toyield proper results in general. Many computational problems of this trouble-some kind are of practical interest, and a good part of them can be found in theclass of NP-hard problems (cf., e.g., [9]). For instance, many problems in logistics(and similar application domains) like scheduling, route planning and packingare NP-hard so that no efficient exact solutions are known and means are neededto overcome this intractability. Apart from using heuristics, another approach iscarried out with some success in the area of chip design and verification: the useof SAT solvers (cf., e.g., [1,2,8]).

In this paper, we advocate the latter idea as an attempt to lessen the in-tractability of NP-hard problems in the area of graph transformation [18]. Agraph-transformational specification of an NP-hard problem may be given by agraph transformation unit [11,12]. It specifies a set of derivations for each inputgraph which is of exponential size in general and only some of the derivationsrepresent a proper solution of the problem (if it is solvable for the input at all). Agraph transformation engine like GrGen.NET (see, e.g., [10]) can build up somederivations, but it has no means to guarantee success and the derived graphsmay be far away from optimal solutions. To improve the situation, the graphtransformation engine needs help.

We propose a prototypical system that combines GrGen.NET with the SATsolver MiniSat [5] and works as follows:

(1) A graph transformation unit of a special form is translated into a proposi-tional formula in conjunctive normal form which describes all successful deriva-tions.

(2) The formula is solved by the SAT solver yielding a variable assignment inthe positive case that establishes one of the successful derivations.

(3) The variable assignment is translated into a control expression that guidesthe graph transformation engine to execute just the successful derivation and tovisualize it in this way.

Altogether, this combination of GrGen.NET and MiniSat means that the graphtransformation engine yields an exact solution of an NP-hard problem for someinput whenever the SAT solver provides some positive result. To demonstrate theusefulness of our proposal, we discuss the job-shop scheduling problem, which isconsidered to be one of the most difficult scheduling problems in logistics (cf.,e.g., [3,4,17]). It should be noted that the translation of graph transformationunits into propositional formulas was already considered in [13] and is used inthis paper with slight modifications. The interpretation of the variable assign-ments as successful derivations is new and very helpful because the intermediaterepresentations as propositional formulas and variable assignments are very large(even for small input graphs) and very difficult to read. In contrast to this, theexecution on GrGen.NET provides visualizations of the results.

The paper is organized as follows. In Sec. 2, the notion of graph transformationunits is recalled. In Sec. 3, it is shown how the job-shop scheduling problem can

From Graph Transformation Units via MiniSat to GrGen.NET 155

be modeled as a graph transformation unit. In Sec. 4 graph transformationunits are translated into propositional formulas so that they can be put into aSAT solver. Sec. 5 presents the prototypical implementation that combines theSAT solver MiniSat with the graph transformation engine GrGen.NET. Sec. 6contains the conclusion.

2 Graph Transformation Units

Graph transformation units transform initial graphs to terminal graphs by ap-plying rules according to control conditions. The components of graph transfor-mation units are briefly recalled in the following.

Graphs. Graphs can be helpful to represent and visualize complex systemstates. Graph transformation units transform graphs and are independent ofa concrete class of graphs. This means that transformed graphs belong to anunderlying class G that can be chosen freely. For our running example, we usethe class of edge-labeled directed graphs without multiple edges. For a set Σ oflabels such a graph is a pair G = (V,E) where V is a finite set of nodes andE ⊆ V × Σ × V is a finite set of labeled edges. The components V and E arealso denoted by VG and EG. An edge of the form (v, x, v) is a loop. In graphdrawings we omit loops and write their labels inside their incident nodes.

The empty graph with no nodes and no edges is denoted by ∅. A graph G is asubgraph of a graph G′ if VG ⊆ VG′ and EG ⊆ EG′ . An injective graph morphismfrom a graph G to a graph H is an injective mapping g : VG → VH that preservesstructure and labels, i.e., (g(v), x, g(v′)) ∈ EH for each edge (v, x, v′) ∈ EG. Thesubgraph of H induced by g is denoted by g(G).

Graph Class Expressions. A graph class expression is any expression thatspecifies a subset of the underlying graph class G. A typical graph class expressionis a type graph [6] which specifies the class of graphs of this type. Class diagramscan also be regarded as graph class expressions that specify all object diagramscovered by the class diagram. In this paper, we use concrete graphs as graphclass expressions where each graph G specifies itself.

Rules. Rules are applied to graphs in order to transform them. Like the graphclass, the rule class can be chosen freely as long as it is suitable to transformthe graphs in G. For our job-shop example, we use a rule class R that is similarto double-pushout rules. Concretely, such a rule r is a triple of graphs (L,K,R)where K is a subgraph of L and R. L is the left-hand side, K the gluing graphand R the right-hand side. We depict rules in the form L→ R where the commonnodes and edges are represented by using identical relative positions.

A rule r = (L,K,R) is applied to a graph G according to the following steps.Choose an injective graph morphism g from L to G such that the removal of theitems in g(L)− g(K) from G does not produce dangling edges. Then remove the


items in g(L)− g(K) from G yielding D and add R disjointly to D. Afterwards,glue R and D as follows. (1) Merge each v ∈ VK with g(v). (2) If there is anedge (v, x, v′) ∈ ER−EK with v, v′ ∈ VK and an edge (g(v), x, g(v′)) ∈ ED thenthese edges are identified.

For each r ∈ R, the relation =⇒r

denotes all pairs (G,G′) ∈ G × G such that

G can be transformed to G′ by applying r. For each P ⊆ R the relation =⇒P

is

equal to⋃

r∈P =⇒r

and∗

=⇒P

denotes the reflexive and transitive closure of =⇒P

.

A sequence of rule applications is called a derivation.

Control Conditions. A control condition is any expression that specifies a setof derivations. Control conditions are employed to restrict the nondeterminismof graph transformation. In this paper, we use the following class C of controlconditions. Every rule r is a control condition in C which requires one applicationof r, i.e., it permits the set of derivations {G=⇒

rG′ | G,G′ ∈ G}. For every set

P ⊆ R, the expression P !(k) is in C and prescribes to apply the rules of P aslong as possible but at most k times. Finally, for each c1, c2 ∈ C, the expressionsc1; c2 and c1|c2 are in C where c1; c2 means to apply c1 and afterwards c2 andc1|c2 means to apply c1 or c2.

The introduced components give rise to the concept of graph transformationunits defined as follows.

Graph Transformation Units. A graph transformation unit is a system tu =(I, P, C, T ) where I and T are graph class expressions called the initial graph classexpression and the terminal graph class expression, P ⊆ R, and C ∈ C. The graphtransformation unit tu specifies all pairs (G,G′) ∈ ∗

=⇒P

such that G is specified

by I, G′ is specified by T , and the underlying derivation is allowed by C. Such aderivation is called successful. In general graph transformation units can importother graph transformation unit, a feature not considered in this paper.

3 Modeling the Job-Shop Scheduling Problem

In this section, we model the job-shop scheduling problem as graph transforma-tion unit.

3.1 The Job-Shop Scheduling Problem

The job-shop problem is a classical scheduling problem that consists of a finiteset M of machines, a finite set J ⊆ M+ of jobs where for each j ∈ J and eachm ∈ M count(m, j) ≤ 1, and a mapping pt : T → N>0 with T = {(m, j) ∈M × J | count(m, j) = 1}.1 The mapping pt associates a processing time withevery task t ∈ T .

1 M+ denotes the set of nonempty words over M . For a symbol a and a word w,count(a,w) counts the number of occurrences of a in w.


A feasible schedule is a mapping start : T → N such that (1) for each jobj = m1 · · ·mk ∈ J with k > 1, start(mi, j) + pt(mi, j) ≤ start(mi+1, j), fori = 1, . . . k − 1; and (2) for each m ∈ M and all j, j′ ∈ J with j �= j′,start(m, j) + pt(m, j) ≤ start(m, j′) or start(m, j′) + pt(m, j′) ≤ start(m, j).The first property means that the machines of each job j must be visited se-quentially in the order in which they occur in j. The second property assuresthat each machine can process at most one job at the same time.

The makespan of each schedule start is defined as the maximum number in{start(t) + pt(t) | t ∈ T }. A best schedule is one where makespan is minimized.If a deadline is given, an interesting question is whether there exists a scheduleat all the makespan of which meets the deadline. This decision problem variantof the job-shop scheduling problem is NP-complete [9].

In the following we do not allow interruptions in schedules, i.e., all machinesperform a processing step if possible.

3.2 The Graph Transformation Unit jobshop

Let JSP = (M,J, pt) be a job-shop scheduling problem and let l ∈ N. Then wecan construct a graph transformation unit jobshop(M,J, pt , l) such that the se-mantics of jobshop(M,J, pt , l) is not empty if and only if there is a feasible sched-ule the makespan of which is at most l. The components of jobshop(M,J, pt , l)are the following.

The initial graph contains a node with an idle-loop for each machine and anode for each task. Moreover, there is a node with a makespan-loop and a 0-loop.For each job j = m1 · · ·mk, there is a next -edge pointing from task node (mi, j)to the task node (mi+1, j) (i = 1, . . . , k−1). There is also an edge from (mi, j) tothe machine nodemi labeled with pt(mi, j). Moreover, the first task node (m1, j)is connected to the machine node m1 via a waiting-edge. An example of an initialgraph with three machines and three jobs generated by GrGen.NET is given inFig. 1. For a better readability, every task-node of this graph additionally showsa job number and the position where it occurs within the job. For example, thetwo leftmost lower task nodes t11 and t12 are associated with job 1 consisting ofthe machine sequence m1,m2 as indicated by the positions, the next -edges andthe pt-pointers originating from these task nodes. The first task t11 is waitingat machine m1 and it needs 2 time units to be processed.

The graph transformation unit jobshop(M,J, pt , l) contains the rules select,process, switch, finish, activate, and count. The first two rules are given in Fig. 2.The rule select exchanges a waiting-edge from a task to an idle machine for aselected -edge from the machine to the task and makes the machine active. Therule process decreases the residual processing time of a task which is selectedby an active machine by 1 and exchanges the active-loop at the machine for aready-loop. As indicated below the arrow, this rule can only be applied if theremaining processing time has not reached 0.

The rules switch and finish are given in Fig. 3. The rule switch is appliedwhen a task is processed. In this case the corresponding selected -edge and the0-edge are removed. The machine which had selected the task becomes idle and


m3:Machinestate = idle



t31:Taskjob = 3

position = 1

t22:Taskjob = 2

position = 2

t21:Taskjob = 2

position = 1

t12:Taskjob = 1

position = 2

t11:Taskjob = 1

position = 1

mksp:MakeSpanvalue = 0

next

next

waiting

waiting

waiting

pt = 1

pt = 1

pt = 1pt = 1

pt = 2

Fig. 1. An initial graph for job-shop

the next task of the same job is attached via a waiting-edge to its machine. Therule finish is applied when all tasks of the same job are processed. It removesthe selected -edge and the 0-edge and changes the ready-loop of the machine toan idle-loop.

The rule activate in Fig. 4 relabels a ready-loop by an active-loop and therule count increases the counter of the makespan node by one.

The control condition of jobshop(M,J, pt , l) is

(select !; process !; switch!; finish!; activate !; count)l

where for r ∈ {select, process, switch, finish, activate} the expression r! abbre-viates the expression {r}!(|M |) where |M | denotes the number of machines. Thecontrol condition makes sure that in every iteration of select ! ; process ! ; switch!; finish! ; activate! ; count the following happens. (1) Every idle machine witha waiting task becomes active by selecting the task (select !). (2) Every activemachine becomes ready by decreasing the residual processing time of its selectedtask by 1 (process !). (3) If a task (m, j) with a next task (m′, j) is processed, itbecomes an isolated node, m becomes idle, and (m′, j) starts to wait at machinem′. (switch!). (4) If a task (m, j) is processed and has no next task, it be-comes an isolated node and m becomes idle (finish!). (5) Every ready machine is

select

idle

waiting −→

active

selected

process

active

selectedk−→k>0

ready

selectedk − 1

Fig. 2. The graph transformation rules select and process


switch

ready

selected0

next

k −→

idle

k waiting

finish

ready

0 selected −→

idle

Fig. 3. The graph transformation rules switch and finish

activate

ready −→ active

count

makespank

−→ makespank+1

Fig. 4. The graph transformation rules activate and count

activated for the next processing step (activate!). (6) The makespan is increasedby 1 (count).

The terminal graph class expression of jobshop(M,J, pt , l) requires that afterexecuting the control condition all tasks should be finished. Concretely, the ter-minal graph consists of a node for every machine and every task as well as anode with a makespan-loop and an l-loop.

The following observation states the correctness of the presented unit. Theproof is roughly sketched, a complete proof is beyond the scope of the paper.

Observation 1. Let G,G′ ∈ G, let (M,J, pt) be a job shop scheduling problemand let l ∈ N. Then (G,G′) is specified by jobshop(M,J, pt , l) if and only if thereis a feasible schedule start of (M,J, pt) such that the makespan of start is atmost l.

Proof (sketch). Let (G,G′) be specified by jobshop(M,J, pt , l) and let der bea derivation from G to G′, which is permitted by the control condition ofjobshop(M,J, pt , l). Then the following statements hold by induction:

1. The rule select is applied in der exactly once to every task in G.2. In every graph of der , each machine has at most one selected task.3. In each execution of c = select !; process !; switch!; finish!; activate!; count a

machine can select at most one task.4. In each execution of c, every selected task is processed one time unit.5. Each selected task remains selected until it is completely processed.6. A target of a next -edge in G can only be selected in der if its source is

completely processed.7. A task becomes an isolated node if and only if it is completely processed.

Choose start(t) = i, if select is applied to task t in the ith execution of c.Statements 2 to 5 imply that each machine must process a task completely


before selecting a new one. Statement 4 to 6 imply that all tasks are processedin the order in which they occur in the jobs. Hence, start is feasible. Since G′

contains only isolated tasks we get by Statement 7 that all tasks are processed inG′ and this implies together with 4 and 5 that l ≥ max{start(t)+pt(t) | t ∈ T }.

Conversely, let start be a feasible schedule (without interruptions) of (M,J, pt)with makespan l and let t1, . . . , tn be an arrangement of the tasks in T suchthat start(ti) ≤ start(ti+1) for i = 1, . . . , n − 1. Let G be an initial graph ofjobshop(M,J, pt , l). Then by induction on n there is a derivation

G = G0∗

=⇒P

G1∗

=⇒P· · · ∗

=⇒P

Gn∗

=⇒P

G′

where P is the rule set of jobshop(M,J, pt , l) and for i = 0, . . . n− 1 the graphGi+1 is obtained from Gi by applying condition c start(ti+1) − start(ti) timesand all tasks in {t ∈ T | start(t) + pt(t) ≤ start(ti)} are represented as isolatednodes in Gi. Moreover, G′ is obtained from Gn by applying c l − start(tn)times with the effect that all non-isolated tasks of Gn become isolated and themakespan counter (which is in Gn equal to start(tn)) becomes equal to l. Hence,G′ is a terminal graph that is obtained from G by applying condition c l times.Altogether we get that (G,G′) is specified by jobshop(M,J, pt, l).

4 From Graph Transformation Units to PropositionalFormulas

In this section, we shortly describe how graph transformation units can be trans-lated into propositional formulas in such a way that a SAT solver can be usedto decide whether there is a successful derivation in the unit. In the case of thejob-shop scenario, this means that the SAT solver decides whether there is amakespan of length at most l. We recall the constructions and results of [13] andillustrate them with small examples concerning the job shop scheduling prob-lem. Additionally, we extend the class of control conditions used in [13] by theoperators | and !(k) presented in Sec. 2.

Representing Graph Sequences as Propositional Formulas. We assumethat the nodes of each graph G are numbered from 1 to n, i.e, VG = {1, . . . , n} =[n], and we call n the size of G. Every propositional formula with variable set{edge(e, i) | e ∈ [n] × Σ × [n], i ∈ [m]} represents a sequence G1, . . . , Gm ofgraphs for each variable assignment f satisfying the formula. In more detail,graph Gi contains the edge e if and only if f(edge(e, i)) = true.

The graphs of the rule select in Fig. 2 without the idle-loop and the active-loop can be regarded as a small example of a graph sequence G0, G1 where G0 isthe left-hand side of select, G1 the right-hand side, the upper node has number1 and the lower number 2. Hence, by choosing Σ = {waiting , selected}, thissequence can be represented by the formula


edge(1,waiting , 2, 0) ∧ edge(2, selected , 1, 1)∧¬edge(1,waiting , 1, 0) ∧ ¬edge(2, selected , 2, 1)∧∧

i,j∈[2](¬edge(i, selected , j, 0) ∧ ¬edge(i,waiting , j, 1))∧∧i∈[2](¬edge(2,waiting , i, 0) ∧ ¬edge(1, selected , i, 1)).

Rule Applications as Propositional Formulas. For technical simplicity,we assume that the nodes of all three graphs in a rule coincide, i.e., for each(L,K,R) ∈ R the sizes of L, K, and R are equal. For a rule r = (L,K,R) theset of injective mappings from [size(L)] to [n] is denoted byM(r, n). Let r ∈ R,let g ∈ M(r, n) and let i ∈ N. Then the formula

apply (r, g, i) = morph(r, g, i) ∧ rem(r, g, i) ∧ add(r, g, i) ∧ keep(r, g, i)

models the application of rule r to the graph ([n], Ei) with respect to morphismg, where

– morph(r, g, i) =∧

(v,x,v′)∈ELedge(g(v), x, g(v′), i)

– rem(r, g, i) =∧

(v,x,v′)∈EL−ER¬edge(g(v), x, g(v′), i + 1)

– add(r, g, i) =∧

(v,x,v′)∈ERedge(g(v), x, g(v), i+ 1)

– keep(r, g, i) =∧

(v,x,v′)/∈g(EL∪ER)(edge(v, x, v′, i)↔ edge(v, x, v′, i+ 1)).2

The formula morph checks whether g is a graph morphism. The formula remmodels the removal of all edges in g(L) − g(R) and add models the additionof every edge in ER which does not have an image under g. The formula keepprescribes that all edges not in g(L) or g(R) should be present in the resultinggraph ([n], Ei+1) if and only if they are contained in ([n], Ei).

For example, let G0 be the initial graph in Fig. 1 and let g be an injectivemapping from the node set {1, 2} of the rule select (where 1 is the upper node)to the node set of G0. Then the formula

morph(select , g, 0) ∧ rem(select , g, 0) ∧ add(select , g, 0)

is equal to

edge(g(1),waiting , g(2), 0) ∧ edge(g(2), idle , g(2), 0)∧¬edge(g(1),waiting , g(2), 1) ∧ ¬edge(g(2), idle, g(2), 1)∧edge(g(2), selected , g(1), 1) ∧ edge(g(2), active, g(2), 1).

The formula keep(select , g, 0) contains the term edge(e, 0) ↔ edge(e, 1) for allvariables e ∈ ([9] × Σ(M,J,pt,l) × [9]) \ {(g(1),waiting , g(2)), (g(2), idle , g(2)),(g(2), selected , g(1)), (g(2), active, g(2))}where (M,J, pt) is the modeled job shopscheduling problem andΣ(M,J,pt,l) is equal to {waiting , selected , next , idle, active,ready ,makespan} ∪ {pt(t) | t ∈ T } ∪ {0, . . . , l}, for each l ∈ N.

2 g(EL ∪ER) abbreviates the set {(g(v), x, g(v′)) | (v, x, v′) ∈ EL ∪ER}.


Translation of Control Conditions into Propositional Formulas. In or-der to be able to generate propositional formulas from control conditions weassociate a length len with every condition such that len(r) = 1, len(P !(k)) = k,len(c1; c2) = len(c1) + len(c2), and len(c1|c2) = max{len(c1), len(c2)}.

For example, for c = select !; process !; switch!; finish!; activate!; count and l ∈N, we have len(cl) = l · len(c) = l · (4 · |M | + 1) where |M | is the number ofmachines (remember that here r! stands for {r}!(|M |)). Hence, the length of thecontrol condition of the jobshop-unit is equal to l · (4 · |M |+ 1).

Moreover, for each control condition c and each i ∈ N we denote the formulaof c at position i w.r.t. graph size n as fn(c, i) defined as follows.

– fn(r, i) =∨

g∈M(r,n) apply(r, g, i), i.e., fn(r, i) specifies the application of r

to graph Gi = ([n], Ei).

– fn(P !(k), i) =∧i+k−1

j=i

(∨r∈P,g∈M(r,n)

(morph(r, g, j) ∧ apply (r, g, j)

)∨∧

r∈P,g∈M(r,n) ¬morph(r, g, j) ∧ apply(∅, ∅, j))

This means that for j = i to i + k − 1 some rule of P is applied toGj if possible. If there is none of the rules in P applicable to Gj , i.e., if∧

r∈P,g∈M(r,n) ¬morph(r, g, j), the empty rule ∅ = (∅, ∅, ∅) is applied, whichhas no effect.

– fn(c1; c2, i) = fn(c1, i)∧fn(c2, i+ len(c1), i.e., fn(c1; c2, i) applies c1 of graphGi and c2 to graph Gi+len(c1).

– fn(c1|c2, i) = fn(c1; ∅len(c1|c2)−len(c1), i) ∨ fn(c2, ; ∅len(c1|c2)−len(c2), i). Thismeans that fn(c1|c2, i) applies c1 or c2 but if the length of the applied con-dition ci is shorter than the length of c1|c2, then the empty rule is appliedlen(c1|c2)− len(ci) times.

The formula for a control condition C in a graph transformation unit is thenequal to fn(C, 0) for each graph size n.

For example, if c = select !; process !; switch!; finish!; activate !; count , we havefn(c

l, 0) = fn(c, 0) ∧ fn(c, 1 · len(c)) ∧ · · · ∧ fn(c, l · len(c)), and for i = 0, . . . , l,fn(c, i · len(c)) is equal to

fn(select !, i·len(c))∧fn(process !; switch!; finish!; activate!; count), i·len(c)+|M |).

Graph Class Expressions as Propositional Formulas. Every initial graphI can by represented by the formula

prop(I, 0) =∧

e∈EI

edge(e, 0) ∧∧

e/∈EI

¬edge(e, 0).

Similarly, any terminal graph T can be encoded as the formula prop(T, len(C)),which is obtained from prop(I, 0) by replacing I by T and 0 by len(C) where Cis the control condition of the graph transformation unit. To illustrate this witha small graph, we take as I the left-hand side of the rule select (without the idle-loop) and translate it into the corresponding formula prop(I, 0) similarly to the


first example of this section which translated the left as well as the right-handside of select. For Σ = {waiting}, the result is equal to

edge(1,waiting , 2, 0) ∧ ¬edge(1,waiting , 1, 0) ∧∧

i∈[2](¬edge(2,waiting , i, 0)).

More general examples of graph class expressions are considered in [13].

Putting the described formulas together, we can express graph transformationunits as propositional formulas as follows.

Graph Transformation Units as Propositional Formulas. Every graphtransformation unit tu = (I, P, C, T ) can be encoded as the propositional formula

fder (tu) = prop(I, 0) ∧ fn(C) ∧ prop(T, len(C))

where n is the size of I.

As stated in [13], every variable assignment that satisfies the formula specifiesa sequence of graphs corresponding to a successful derivation in tu.

It is worth noting that the employment of a SAT solver only makes senseif the number of literals in the resulting formula is bounded by a polynomial.For graph transformation units in which each allowed derivation is of polynomiallength this is the case (cf. [13]). Fortunately, all derivations of the transformationunit jobshop(M,J, pt , l) consist of l · (4 · |M |+1) rule applications, which impliesthat they have polynomial lengths.

As shown in the next section one can extract a derivation from every satisfyingvariable assignment.

5 Combining MiniSat and GrGen.NET

In this section we take a closer look at a prototypical implementation in Haskellwhich combines the SAT solver MiniSat with the graph transformation engineGrGen.NET. In reference to its task the tool has been called SATaGraT which isthe abbreviation for SAT solver assists graph transformation engine. SATaGraTuses MiniSat 2, GrGen.NET 3.0, and Glasgow Haskell Compiler 6.12 and hasbeen tested on an Intel 3.2 GHz with 8GB RAM.

5.1 System Description

Fig. 5 shows an overview of the structure of the implemented system which isexplained in detail in the following. SATaGraT takes a graph transformationunit as given in Sec. 2 as input and generates a propositional formula as definedin Sec. 4 which describes all possible runs of this unit. In order to obtain asatisfying variable assignment, the generated propositional formula is translatedinto conjunctive normal form and fed into MiniSat, a fast and easy-to-use SATsolver. The satisfiability preserving Tseitin transformation [20] which allows a


Fig. 5. The structure of SATaGraT

conversion with linear time and space requirements is used for the translationinto conjunctive normal form (cnf for short). In cases in which the formula issatisfiable, MiniSat delivers a satisfiying assignment of the variables which isthen used to construct a successful derivation of the initial graph in the originalgraph transformation unit.

MiniSat is fully integrated in SATaGraT, i.e., the generated conjunctive nor-mal form is saved in a file in the DIMACS format as input for MiniSat, thenMiniSat solves the conjunctive normal form, and at last SATaGraT reads theoutput from MiniSat and saves the assignment of the variables in an internalrepresentation. MiniSat returns a list of variable assignments which includes theinformation about the solution as well as all the extra variables of the Tseitintransformation. In Fig. 6, one can see a snippet of the MiniSat-output with thevariable numbers 41820 to 41878 where the truth value of variables preceded by aminus sign is false and the truth value of unsigned variables is true. Such an out-put is obviously cryptic and hard to interpret. Therefore, a suitable visualizationseems quite useful.

Fig. 6. A snippet of the output of MiniSat

In accordance with Sec. 4, the assignment of the variables yields a sequence ofgraphs representing the derivation. These graphs are described by their edges asthe set of nodes remains invariant throughout the derivation process. In order touse GrGen.NET for constructing and running the derivation, the applied rulesand the matchings used have to be extracted from this sequence. The following


program in pseudocode illustrates the idea behind the implemented algorithmfor extracting rules and matchings from the variable assignment, where g(EL) ={(g(v), a, g(v′)) | (v, a, v′) ∈ EL} and g(ER) = {(g(v), a, g(v′)) | (v, a, v′) ∈ ER}for every rule (L,K,R) ∈ P and every injective mapping g ∈ M(r, n) :

FUNCTION ExtractRulesAndMatchings (E0, . . . , EderivLength : SetOfEdges ,P : SetOfRules, n : |V |, derivLength : DerivationLength): (Derivation , SetOfEdges)

FOR m = 1, . . . , derivLength, (L,K,R) ∈ P, g ∈M((L,K,R), n) DOEm := Em − Em−1; Em−1 := Em−1 − Em;IF (Em−1 ⊆ g(EL)) ∧ ((g(EL)− Em−1) ⊆ Em−1) ∧ (Em ⊆ g(ER))∧((g(ER)− Em) ⊆ Em)

THEN derivationExpr := derivationExpr ∪ (Em, (L,K,R), g);ELSE RETURN (derivationExpr , E0);

END;

Consider a sequence G0, . . . , Gk of graphs and a rule set P as defined in Sec. 2.For every graph Gm (with 1 ≤ m ≤ k), every rule r = (L,K,R) ∈ P , and everyg ∈M(r, n) it is checked by comparing the edges of Gm−1 and Gm if r is appliedw.r.t. g in the mth derivation step. The IF-condition assures that (1) the deletededges of the mth derivation step are in g(EL); (2) the edges of g(EL) which arenot deleted are in Gm−1; (3) the edges which are added in the mth derivationstep are in g(ER); and (4) the edges of g(ER) which are not added are in Gm.For some rule sets the algorithm is ambiguous, but for the graph transformationunit jobshop(M,J, pt, l) we receive a unique result.

By extracting a derivation expression from this result it is now possible touse GrGen.NET for the visualization of a solution. Fig. 7 shows an excerpt ofa derivation with the 3 × 3 job-shop graph in Fig. 1 of Sec. 3 as initial graphconsisting of the first and last two steps of 48 steps altogether. Obviously, theGrGen-output is much more transparent than the MiniSat-output in Fig. 6.

The above-mentioned example, with nine nodes total, yields a propositionalformula with 9720861 literals and a cnf formula with 49113 variables and 9723633clauses. This is already an optimized version of the formula generation algorithmwhich takes advantage of node typing to strongly restrict the number of possiblematches. The solving time in MiniSat is 81.26 seconds. The formula turns outto be satisfiable for makespan 3.

5.2 Discussion

As illustrated above, SATaGraT searches for successful derivations via Min-iSat and brings the corresponding output into a readable form by translating itinto a derivation executed by GrGen.NET. Hence, in case of NP-hard problemsSATaGraT can be used for proving and illustrating the existence of successfulderivations. The generated propositional formulas are already pretty large evenfor small graphs and the conversion to cnf represents a bottleneck, both for timeand for memory reasons. All of the four tested cnf converters (Funsat [7], Lim-boole [14], Logic2CNF [15], and Sugar [19]) take between 1.5 and 4+ hours to


Fig. 7. An excerpt of a derivation

handle the cnf conversion for the above nine-node example, with Limboole beingby far the fastest and Funsat the slowest. For the larger examples we tried, thecnf conversion was prematurely aborted due to insufficient memory. In order tohandle not only small input graphs, optimization concerning both the size ofthe generated propositional formulas and the efficiency of the cnf conversion areneeded. The propositional formula encodes all possible derivations of the giventransformation unit. Hence, one idea to shrink the formulas is to drop non-successful derivations in advance. We are hopeful that analyzing the structure ofthe initial graph and the rules of the graph transformation unit will prove usefulin achieving this kind of optimization. We have already implemented a matchingoptimization mentioned above that has reduced the original size of the formulasby up to 95 percent.

6 Conclusion

In this paper, we have proposed a combination of a SAT solver like MiniSatand a graph transformation engine like GrGen.NET. The hope is that this toolincreases the chance to find solutions for instances of NP-hard problems that aremodeled by graph transformation systems. It is known that SAT solvers are em-ployed in chip design and verification with some success, and our idea has beento take up these positive experiences and to carry them over to graph trans-formation. We have designed and implemented the prototypical tool SATaGraT(SAT solver assists graph transformation engine) and have tested it with graphtransformational models of various problems including the job-shop problem.

Our tentative approach meets three goals.


1. The translation of a special type of graph transformation units into proposi-tional formulas as proposed in [13] is supplemented by a follow-up translationof variable assignments satisfying the formulas into successful derivations ofthe original graph transformation units.

2. Both translations are implemented prototypically by the SATaGraT system.3. As the job-shop scheduling example demonstrates, a SAT solver may help

to find solutions of NP-hard graph transformational problems. If the SATsolver within SATaGraT yields a result, it is exact. If the formula is unsatisfi-able, there is no successful derivation. This implies that based on SATaGraTand a SAT solver, it is automatically decidable for the class of consideredtransformation units whether their semantics is empty. If it is not empty,a successful derivation is provided and can be executed and visualized onGrGen.NET. In contrast, if one searches for successful derivations directlyon GrGen.NET, proper results are pure chance with very small probabilityin general.

In the future, the presented work should be further developed with respect tothe following aspects.

– In our very first experiments the sizes of the input graphs are still rathersmall. The problem is that our translation of graph transformation unitsinto propositional formulas yields very large numbers of clauses althoughthe formulas are of polynomial size. Hence, further optimizations are neededto obtain a SATaGraT behavior that is competitive with the benchmarks inthe literature.

– One such optimization may be achieved by using structural analysis on theinput graph and the graph transformation unit to reduce the nondeterminismin the derivation and thus the size of the formula.

– The performance of SATaGraT should be checked against further graphtransformational descriptions of NP-hard graph algorithms.

– In particular, it should be investigated whether SATaGraT may help toimprove upper bounds found so far by non-exact methods applied to concreteproblem instances.

– The presented approach should be compared with other methods for findingexact solutions for NP-hard problems such as fixed parameter algorithms(cf., e.g., [16]).

References

1. Biere, A., Cimatti, A., Clarke, E., Fujita, M., Zhu, Y.: Symbolic model checkingusing SAT procedures instead of BDDs. In: Irwin, M.J. (ed.) Proc. of the 36thAnnual ACM/IEEE Design Automation Conference, pp. 317–320. ACM (1999)

2. Biere, A., Heule, M., van Maaren, H., Walsh, T. (eds.): Handbook of Satisfiability,Frontiers in Artificial Intelligence and Applications, vol. 185. IOS Press (2009)

3. Blazewicz, J., Ecker, K.H., Pesch, E., Schmidt, G., Weglarz, J. (eds.): Handbookon Scheduling: From Theory to Applications. Springer (2007)

4. Brucker, P.: Scheduling Algorithms. Springer (2007)


5. Een, N., Sorensson, N.: An Extensible SAT-solver. In: Giunchiglia, E., Tacchella,A. (eds.) SAT 2003. LNCS, vol. 2919, pp. 502–518. Springer, Heidelberg (2004)

6. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals of Algebraic GraphTransformation. Springer (2006)

7. Funsat (2011), http://hackage.haskell.org/package/funsat-0.6.0 (accessedAugust 26, 2011)

8. Ganai, M., Gupta, A.: SAT-Based Scalable Formal Verification Solutions. Serieson Integrated Circuits and Systems. Springer (2007)

9. Garey, M.R., Johnson, D.S.: Computers and Intractability: A Guide to the Theoryof NP-Completeness. W. H. Freeman (1979)

10. Geiß, R., Kroll, M.: GrGen.NET: A Fast, Expressive, and General Purpose GraphRewrite Tool. In: Schurr, A., Nagl, M., Zundorf, A. (eds.) AGTIVE 2007. LNCS,vol. 5088, pp. 568–569. Springer, Heidelberg (2008)

11. Kreowski, H.J., Kuske, S.: Graph transformation units with interleaving semantics.Formal Aspects of Computing 11(6), 690–723 (1999)

12. Kreowski, H.-J., Kuske, S., Rozenberg, G.: Graph Transformation Units – AnOverview. In: Degano, P., De Nicola, R., Meseguer, J. (eds.) Concurrency, Graphsand Models. LNCS, vol. 5065, pp. 57–75. Springer, Heidelberg (2008)

13. Kreowski, H.-J., Kuske, S., Wille, R.: Graph Transformation Units Guided by a SATSolver. In: Ehrig, H., Rensink, A., Rozenberg, G., Schurr, A. (eds.) ICGT 2010.LNCS, vol. 6372, pp. 27–42. Springer, Heidelberg (2010)

14. Limboole (2011), http://fmv.jku.at/limboole/ (accessed August 26, 2011)15. Logic2CNF (2011), http://projects.cs.kent.ac.uk/projects/logic2cnf/trac/

(accessed August 26, 2011)16. Niedermeier, R.: Invitation to Fixed-Parameter Algorithms. Oxford Lecture Series

in Mathematics and its Applications, vol. 31. Oxford University Press, USA (2006)17. Pinedo, M.: Scheduling: Theory, Algorithms, and Systems. Springer (2008)18. Rozenberg, G. (ed.): Handbook of Graph Grammars and Computing by Graph

Transformation, vol. 1: Foundations. World Scientific (1997)19. Sugar (2011), http://bach.istc.kobe-u.ac.jp/sugar/ (accessed August 26,

2011)20. Tseitin, G.: On the complexity of derivation in propositional calculus. In: Studies

in Constructive Mathematics and Mathematical Logic, Part 2, pp. 115–125 (1968);(reprinted in: Siekmann, J., Wrightson, G. (eds.): Automation of Reasoning, vol. 2,pp. 466–483. Springer (1983))

http://hackage.haskell.org/package/funsat-0.6.0

http://fmv.jku.at/limboole/

http://projects.cs.kent.ac.uk/projects/logic2cnf/trac/

http://bach.istc.kobe-u.ac.jp/sugar/

Locality in Reasoning

about Graph Transformations

Martin Strecker�

IRIT (Institut de Recherche en Informatique de Toulouse)Universite de Toulouse, France

http://www.irit.fr/~Martin.Strecker/

Abstract. This paper explores how to reason locally about global prop-erties of graph transformations, in particular properties involving tran-sitive closure of the edge relations of the graph. We show under whichconditions we can soundly reduce reasoning about all nodes in the graphto reasoning about a finite set of nodes. We then give an effective proce-dure to turn this reduced problem into a Boolean satisfiability problem.

Keywords: Graph transformations, formal methods, verification.

1 Introduction

Proving the correctness of graph transformations is a notoriously hard problem.As opposed to transformations of tree-like structures, such as term rewriting orfunctional programming over inductively defined datatypes, there are no well-defined traversal strategies of a graph, and, still worse, multiple matchings of agraph rewriting rule are possible for a single position in a graph. This lack ofstructure leads to a combinatorial explosion which calls for tool support whenproving properties of graph transformations.

Two major approaches have been developed: The model checking approach(embodied by [12,3,8,11,19]) considers the evolution of a given start graph underapplication of transformation rules. Typical questions of interest are whether cer-tain invariants are maintained throughout all evolutions of a graph, or whethercertain states are reachable. A downside of this approach is that, in principle, itonly allows to talk about the effect of transformations on individual graphs andnot about the correctness of rules in general. (However, in particular cases, therules themselves may generate all interesting instances, such as in the red-blacktrees of [2].)

The theorem proving approach (which we follow in this paper) hoists pre-/postcondition calculi known from imperative programming to programs aboutgraphs. Even before being able to reason about more complex graph transforma-tion programs, one has to be able to prove properties of a single transformationstep, i. e., the consequences of the application of a single rule.

� Part of this research has been supported by the Climt project (ANR-11-BS02-016).


http://www.irit.fr/~Martin.Strecker/

170 M. Strecker

Thus, in [6], a relational approach to transformation verification is describedand a coding in Event-B presented [17]. In [15], a natural deduction-like proofsystem for reasoning about graph transformations is given, [9] establishes a cor-respondence between categorical notions and satisfiability problems, howeverwithout providing automated verification procedures.

So far, in all this work, one question has remained unanswered: what is theglobal impact of applying a rule locally? Under which conditions can reasoningabout a graph with an unbounded (possibly even infinite) number of nodes bereduced to reasoning about the finite number of nodes the rule is applied to? Theglobal properties we are particularly interested in are connectedness and reach-ability, which, in principle, require inductive proofs. We especially concentrateon preservation of transitive closure of the form r∗ ⊆ r′∗, where r resp. r′ arethe arc relations of a graph before resp. after the transformation. Finding goodanswers is essential for automating the verification of graph transformations. Wewill show when and how we can reduce the containment problem r∗ ⊆ r′∗ toa problem of the form r ⊆ r′. This avoids reasoning about possibly unboundedpaths and instead only considers a finite set of nodes and arcs that can be de-rived directly from the transformation rules. We thus arrive at a problem thatcan be decided by Boolean satisfiability checking.

We will further highlight the problem and give an informal overview of ourapproach in Section 2. We then describe our language for specifying graph trans-formations and the property language in Section 3. In Section 4, we show underwhich conditions we can separate a graph into an arbitrarily large “exterior”and a finite “interior”, and in Section 5, we reduce the verification of a givenproperty on this interior to a Boolean satisfiability problem. In Section 6, weconclude with an outlook on future work.

2 Problem Statement

Consider the example in Figure 1, describing a graph transformation rule (inthe upper part) that deletes the edge (n1, n3) and instead inserts two new edges(n1, n2) and (n2, n3). When this transformation is embedded into a larger graph(in the lower part; the image of the rule in the graph has a darker shading), onecan assert that if it is possible to go from a node x to a node y in the originalgraph, then this is also possible after transformation. More formally: if r is theedge relation and r∗ is its reflexive-transitive closure, then (x, y) ∈ r∗ in theoriginal graph implies (x, y) ∈ r∗ in the transformed graph, for arbitrary nodesx and y.

It might appear that this fact can be established by simply looking at thefinite number of nodes of the transformation rule, without taking arbitrary xand y in the graph. Thus, the path (n1, n3) ∈ r∗ of the LHS of the rule can beconstructed by the composition of (n1, n2) and (n2, n3) in the RHS, which seemsto carry over to embeddings of this rule in larger graphs.

Such a reasoning is fallacious, as illustrated in Figure 2, which is taken froma case study describing the data flow in a communication network (a similar

Locality in Reasoning about Graph Transformations 171

n1

n2

n3 n1

n2

n3

x yg1

g2

g3 x yg1

g2

g3

Fig. 1. Simple rerouting

example appears in [1]). The network consists of composite elements (bold bor-ders in the figure) and simple elements. There are two kinds of relations: theflow relation (simple arrows) and the containment relation between simple andcomposite elements (dashed arrows). The reader should not be confused by theterminology: also a node representing a composite element is a regular node andnot a subgraph.

The transformation rule describes the situation where diagrams with com-posite elements are flattened, by rerouting data flows to and from compositeelements to their containing blocs (of course, the containment relation cannotbe part of data paths). One can verify that data paths between non-compositeelements are preserved within the rule: the path from n1 to n4 in the LHS alsoexists in the RHS. Unfortunately, data path preservation does not hold any morein a larger context, when considering nodes outside the image of the transforma-tion rule: For example, the data path from g1 to g6 is lost by the transformation.

To make the statement (“paths between non-composite blocs”) more formal,let us use three kinds of relations: r for edges between simple blocs (straight,non-dashed arrows), and rsc (resp. rcs) for edges from simple to composite (resp.composite to simple) blocs. Let us write ◦ for relation composition. The pathpreservation property now reads: if (x, y) ∈ (r∪ (rcs ◦rsc))∗ in the original graphfor arbitrary x, y, then also in the transformed graph.

Why does local reasoning about a rule carry over to the entire graph in thefirst, but not in the second case? One of the causes appears to be relationcomposition, which hides an existential quantifier: (x, y) ∈ (rcs ◦ rsc) means∃z.(x, z) ∈ rcs ∧ (z, y) ∈ rsc, and there is no way to tell whether this z is one ofthe nodes inside the image of the transformation rule, or whether it lies outsideof it. We will therefore omit relation composition from the relational languageof Section 5.1, but definitely show that local reasoning is safe for the fragmentdefined below.

3 Representing and Reasoning about Transformations

Our way of representing and reasoning about graph transformations is describedin more detail in [18], and we therefore only summarize the elements that are

172 M. Strecker

n1

n2

n5

n3

n4 n1

n2

n5

n3

n4

g1

g2

g5

g3

g4

g6

g1

g2

g5

g3

g4

g6

rsc rcs

rsc rcs

rcs rcs

Fig. 2. Complex rerouting

most important for an understanding of this article. This section might beskipped on a first reading and only be consulted for the terminology used lateron.

The approach is entirely logical and consists of coding all relevant notions ofgraph transformations in a higher-order proof assistant, such as rules, matching,morphisms and rewriting itself. (In our case, the Isabelle [14] system is used, andsome of the definitions below are directly extracted from the Isabelle sources.)This gives a fine control over the transformation process, such as the propertiesof the morphisms mapping rules into graphs. For example, we assume throughoutthis article that these morphisms are injective, but this property can easily beconfigured differently, however with a non-negligible impact on efficiency of thereasoning procedures.

A graph is defined to be a record consisting of a set of nodes and a set ofedges (pairs of nodes), indexed by an edge type ′et. Furthermore, nodes can begiven a node type:

record ( ′nt , ′et , ′h) graph =nodes :: obj setedges :: ′et ⇒ (obj ∗ obj ) setnodetp :: obj ⇒ ′nt

A graph transformation consists of an applicability condition that defines amatching in a target graph, and an effect that specifies how the matched nodesand edges are transformed: which nodes and edges have to be deleted and whichhave to be generated, and how the newly generated nodes have to be typed. Inorder to be able to manipulate the applicability condition syntactically, we donot express it with the aid of the built-in logic of our proof assistant, but ratheruse a special-purpose syntax that we do not spell out any further here. As anillustration, here is the definition that specifies the transformation of Figure 1.The precondition rerouting-precond expresses that there is a type of nodes, Node,and a relation r, that the nodes n1 , n2 , n3 have type Node and there is an edgeof type r between n1 and n3. The transformation itself specifies which edges are


deleted (e-del) and generated (e-gen). This specification is indexed by the noderelation, hence the lambda-abstraction over et. No nodes are deleted or addedin this example.

datatype nodetp = Nodedatatype edgetp = r

definitionrerouting-precond :: nat ⇒ nat ⇒ nat ⇒ (nodetp, edgetp, ′h) path-form wherererouting-precond n1 n2 n3 = (Conjs-form [

(S-form (Type-set Node) n1 ), (S-form (Type-set Node) n2 ),(S-form (Type-set Node) n3 ), (P-form (Edge-pth r) n1 n3 ) ])

definition rerouting :: (nodetp, edgetp, ′h) graphtrans wherererouting =(| appcond = rerouting-precond 1 2 3 ,n-del = {}, n-gen = {},e-del = λ et . {(1 ,3 )}, e-gen = λ et . {(1 ,2 ), (2 ,3 )},n-gentp = empty |)A morphism is a map from nodes (in the transformation rule) to nodes (in

the target graph):

types graphmorph = nat ⇒ obj option

We now have all ingredients for defining the function apply-graphtrans-rel thatapplies a graph transformation under a given morphism to a graph and producesa transformed graph (see [18] for more details):

consts apply-graphtrans-rel ::[( ′nt , ′et , ′h) graphtrans, graphmorph, ( ′nt , ′et , ′h) graph, ( ′nt , ′et , ′h) graph]⇒ bool

Usually, we are not interested in the behavior of a transformation for one partic-ular morphism, but for any morphism that satisfies the applicability condition.The following relation abstracts away from the morphism and just describes thata graph gr is transformed into a graph gr ′ by a graph transformation gt :

definition apply-transfo-rel ::[( ′nt , ′et , ′h) graphtrans, ( ′nt , ′et , ′h) graph, ( ′nt , ′et , ′h) graph] ⇒ bool whereapply-transfo-rel gt gr gr ′ = apply-graphtrans-rel gt (select-morph gt gr) gr gr ′

The proof obligations we set out to prove typically have the form: if the trans-formation transforms gr into gr ′, then P (gr , gr ′) holds, where P is a predicateputting into correspondence the node and edge sets of gr and gr ′. For example,the path preservation property of Figure 1 is stated as:

(applicable-transfo rerouting gr ∧ apply-transfo-rel rerouting gr gr ′)=⇒ (edges gr r)∗ ⊆ (edges gr ′ r)∗

More specifically, the properties P we will examine in the following are simplepreservation properties r ⊆ s or path preservation properties r∗ ⊆ s∗, where rrepresents the edge relation of gr and s the edge relation of gr ′ (“nodes connected

174 M. Strecker

in gr are also connected in gr ′”), or inversely (“nodes connected in gr ′ werealready connected in gr”, rather expressing a preservation of separation).

The way the transformations are defined, references to gr ′ can be eliminated.To illustrate this point, let us continue with our example. Unfolding definitionsand carrying out some simplifications, our proof obligation reduces to the fol-lowing (hypotheses are contained in [[ ... ]], and some inessential ones have beenremoved):

[[n1 ∈ nodes gr ; n2 ∈ nodes gr ; n3 ∈ nodes gr ; nodetp gr n1 = Node;nodetp gr n2 = Node; nodetp gr n3 = Node; (n1 , n3 ) ∈ edges gr r ]]=⇒ (edges gr r)∗

⊆ (insert (n1 , n2 ) (insert (n2 , n3 ) (edges gr r − {(n1 , n3 )})))∗

4 Graph Decompositions

The essential step of our approach consists in splitting up a graph into an interiorregion (the image of nodes of a rule in a graph under a given graph morphism),and an exterior. Since we are here mostly concerned with the node relations of agraph, we define the interior and exterior of a relation r with respect to a regionA as follows:

definition interior-rel A r = r ∩ (A × A)definition exterior-rel A r = r − (A × A)

Visually speaking, the interior of a relation wrt. a region A comprises all arcsconnecting nodes a1, a2 both of which are contained in A, whereas the exteriorconsists of the arcs connected to at least one node e outside of A.

a1 a2

e

r

s s

Fig. 3. Interior (dark shade) and exterior (light shade) of a relation

The interior and exterior of a relation add up to the whole relation again:

lemma interior-union-exterior : interior-rel A r ∪ exterior-rel A r = r

and from this, we obtain by simple set-theoretic reasoning a first decompositionlemma:

lemma interior-exterior-decompos-subset-equal :(exterior-rel A r ⊆ exterior-rel A s ∧ interior-rel A r ⊆ interior-rel A s)= (r ⊆ s)


When read from right to left, this lemma reduces reasoning of a relation con-tainment property of the form r ⊆ s to reasoning about the interior and exteriorof these relations.

Our principal interest in this paper is reasoning about preservation of (reflex-ive) transitivity properties, i. e., properties of the form r∗ ⊆ s∗ or r+ ⊆ s+. Eventhough applicable in principle, the above decomposition lemma is of no much use,as will become apparent in Section 5. We therefore provide the following special-ized form (a similar lemma holds for the transitive closure as well):

lemma interior-exterior-decompos-rtrancl-subset :(exterior-rel A r)∗ ⊆ (exterior-rel A s)∗ ∧ (interior-rel A r)∗ ⊆ (interior-rel A s)∗

=⇒ r∗ ⊆ s∗

Its correctness can be seen by using the property (I ∗ ∪ E∗)∗ = (I ∪ E )∗ oftransitive closures and lemma interior-union-exterior to show that ((interior-relA r)∗ ∪ (exterior-rel A r)∗)∗ = r∗ and then use simple set-theoretic reasoning.

As witnessed by this lemma, proving r∗ ⊆ s∗ by decomposition into interiorand exterior is sound, but contrary to interior-exterior-decompos-subset-equal,the above lemma is an implication and not an equality. One may therefore wonderwhether this decomposition does not make us lose completeness, by possiblyreducing a provable to an unprovable statement.

Indeed, the inverse does not hold in general. For example, r∗ ⊆ s∗ =⇒(interior-rel A r)∗ ⊆ (interior-rel A s)∗ is not satisfied for r = {(a1, a2)},s = {(a1, e), (e, a2)} and A = {a1, a2}. Note that in this case, interior-rel As = {}, whereas interior-rel A r = {(a1, a2)} (also see Figure 3).

However, by choosing the interior large enough, we obtain the inverse of lemmainterior-exterior-decompos-rtrancl-subset (here, Field is the union of the domainand the range of a relation):

lemma decompos-complete-interior :Field s ⊆ A =⇒ r∗ ⊆ s∗ =⇒ (interior-rel A r)∗ ⊆ (interior-rel A s)∗

lemma decompos-complete-exterior :Field r ⊆ A =⇒ r∗ ⊆ s∗ =⇒ (exterior-rel A r)∗ ⊆ (exterior-rel A s)∗

In practice, this means that the interior has to comprise all known elements ofthe relations r and s (differently said: all free variables occurring in them).

We have thus recovered completeness of our decomposition for a class ofgraphs that comprises also the graphs for which this decomposition is in facttrivial (i. e., Field s ⊆ A and Field r ⊆ A hold). It also highlights the problemof performing this decomposition if the fields of the involved relations are notentirely known, as in the case of relation composition.

Let us conclude this section by applying the above procedure to our example.Since the variables n1 , n2 , n3 are free in our goal, we choose A = {n1 , n2 , n3}and obtain two new subgoals, the first having the conclusion

(exterior-rel {n1 , n2 , n3} (edges gr r))∗

⊆ (exterior-rel {n1 , n2 , n3}(insert (n1 , n2 ) (insert (n2 , n3 ) (edges gr r − {(n1 , n3 )}))))∗

and the second one being similar, for interior-rel.

176 M. Strecker

5 Reduction to Boolean Satisfiability

As indicated before, we are interested in proving properties of the form r ⊆ s orr∗ ⊆ s∗, and we have seen in Section 2 that some relation constructors, such asrelation composition, are problematic. In Section 5.1, we therefore give a moreprecise characterisation of the structure of the relation expressions r and s wewill use in the following.

After decomposition of the graph into an exterior and an interior, we areleft to simplifying each of these parts separately. In Section 5.2 and Section 5.3respectively, we will see that for our relation algebra, the resulting problems areindeed decidable.

5.1 Relation Expressions

We assume that our relational expressions r are built up inductively accordingto the following grammar:

r ::= rb| {}| insert (n1, n2) r| r ∪ r| r ∩ r| r − r

Here, rb are basic, non-interpreted relations, and n1, n2 are variables representingnode names. Our grammar contains set difference A − B and not simply setcomplement − B because the former behaves better with some of the reductionsin Section 5.2 and Section 5.3.

We assume that FV (r) returns all the free variables in r, i. e., the set of allthe n1 and n2 occurring in insert-expressions of r.

It should be noted that this grammar enables to capture at least the effectsof transformations that arise from application of rules as defined in Section 3.

5.2 Reduction of the Exterior

Decomposition of Sec. 4 has left us with a first subgoal of the form (exterior-relA r) ⊆ (exterior-rel A s) or (exterior-rel A r)∗ ⊆ (exterior-rel A s)∗. We nowexhaustively apply the following rewrite rules (technically, in our framework,they are added to Isabelle’s simplification set):

exterior-rel A {} = {}exterior-rel A (insert (x , y) r) = ({(x , y)} − (A × A)) ∪ exterior-rel A rexterior-rel A (r ∩ s) = (exterior-rel A r) ∩ (exterior-rel A s)exterior-rel A (r ∪ s) = (exterior-rel A r) ∪ (exterior-rel A s)exterior-rel A (r − s) = (exterior-rel A r) − (exterior-rel A s)


and furthermore the simplification {(x , y)} − (A × A) = {} if x ,y ∈ A, as wellas trivial simplifications of operations with the empty set.

An easy inductive argument shows that, if FV (r) ⊆ A, these simplificationsreduce any expression exterior-rel A r to a Boolean combination, consisting ofoperators ∪, ∩, −, and only involving expressions exterior-rel A r b, where therb are basic relations.

If our original goal had the form (exterior-rel A r) ⊆ (exterior-rel A s), weare now left with a goal R ⊆ S, with R and S such Boolean combinations.Since the basic rb are uninterpreted, this goal can be proved or disproved withpropositional reasoning.

If our original goal had the form (exterior-rel A r)+ ⊆ (exterior-rel A s)+,we are now left with a goal R+ ⊆ S+, which we can reduce to R ⊆ S, using thefact that (reflexive) transitive closure is monotonic, and then proceed as before.This reduction is obviously sound. It is also complete: if R ⊆ S is not provable,any counterexample can be turned into a counterexample in which the basicexpressions exterior-rel A r b are interpreted as either empty or non-empty overa one-element domain. Over this domain, a relation and its transitive closurecoincide, so that we obtain a counterexample of R+ ⊆ S+. A slightly moreinvolved argument also holds for reflexive-transitive closure.

5.3 Reduction of the Interior

We now show how we can verify the properties in the interior, for goals having theform (interior-rel A r) ⊆ (interior-rel A s) or (interior-rel A r)∗ ⊆ (interior-relA s)∗. Even though it appears intuitively plausible that these questions aredecidable for a finite interior A, it is not sufficient to use traditional graphalgorithms, because our relations r and s are composite.

For simplification, we proceed in several stages:

1. we push inside applications of interior-rel, leaving applications of the forminterior-rel A r b for basic relations r b;

2. we explicitly calculate interior-rel A r b, which completely eliminates all oc-currences of interior-rel ;

3. if necessary, we explicitly calculate the (reflexive) transitive closure of thesets thus obtained, which essentially gives a propositional problem;

4. we solve the problem with a propositional solver.

For the first stage, we use the following rewrite rules:

interior-rel A {} = {}interior-rel A (insert (x , y) r) = ({(x , y)} ∩ (A × A)) ∪ (interior-rel A r)interior-rel A (r ∩ s) = (interior-rel A r) ∩ (interior-rel A s)interior-rel A (r ∪ s) = (interior-rel A r) ∪ (interior-rel A s)interior-rel A (r − s) = (interior-rel A r) − (interior-rel A s)

Note that A is a finite, concrete set, so that we can further simplify with:

178 M. Strecker

x ∈ A ∧ y ∈ A =⇒ ({(x , y)} ∩ (A × A)) = {(x , y)}x /∈ A ∨ y /∈ A =⇒ ({(x , y)} ∩ (A × A)) = {}At the end of this first step, we are now left with a Boolean combination of

relations of the style interior-rel A r b, where r b is basic. The following equality:

r ∩ (insert a A) × (insert a A) =(r ∩ (A × A)) ∪ (r ∩ ({a} × (insert a A))) ∪ (r ∩ ((insert a A) × {a}))

is the basis for a simplification scheme that recurses over A and eliminates allinterior-rel :

interior-rel {} r = {}interior-rel (insert a A) r =(interior-rel A r) ∪(interior-rel-elem-r a (insert a A) r) ∪ (interior-rel-elem-l a (insert a A) r)

Here, we have defined

definition interior-rel-elem-r a B r = r ∩ ({a} × B)definition interior-rel-elem-l b A r = r ∩ (A × {b})with the following reductions:

interior-rel-elem-r a {} r = {}interior-rel-elem-r a (insert b B) r =(if (a, b) ∈ r then {(a, b)} else {}) ∪ interior-rel-elem-r a B rinterior-rel-elem-l b {} r = {}interior-rel-elem-l b (insert a A) r =(if (a, b) ∈ r then {(a, b)} else {}) ∪ interior-rel-elem-l b A r

Before taking the third step, we have to massage the goal by if-splitting, thusdistinguishing, in the above rules, between the cases (a, b) ∈ r and (a, b) /∈ r.This is a source of a considerable combinatorial explosion: for each basic relationr b occurring in the goal, and for n nodes, we potentially get 2(n

2) combinations,the problem being aggravated by the fact that the relations are not directed. Wewill come back to this point in Section 6.

To complete the transformation, we symbolically compute the closure. Weshow the recursive equation for transitive closure:

(v , w) ∈ (insert (y , x) r)+ =((v , w) ∈ r+ ∨ ((v = y) ∨ (v , y) ∈ r+) ∧ ((x = w) ∨ (x , w) ∈ r+))

After these transformations, we obtain a Boolean combination of

– membership in an elementary relation: (x , y) ∈ r (or their negation)– (in)equalities x = y or x �= y between nodes

This fragment can readily be decided by standard propositional solvers.

6 Conclusions

We have presented a method of automatically proving properties of graph trans-formations in a restricted relational language with transitive closure, by decom-posing the abstract graph in which a rule is to be applied in an interior and an


exterior region on which the proof problems can be verified by essentially propo-sitional means. Seen from a different angle: the present paper establishes a gen-eral framework in which the difficultly automizable inductive proofs arising fromtransitive closure operations have already been carried out on the meta-level. Fora particular application, it therefore suffices to use finitary proof methods.

The transformations in Section 5.2 might give rise to problems of set contain-ment for Boolean set operations, which is in principle NP-complete, but seems tobe very efficient in practice. The reason is that the simplifications in Section 5.2only verify that a decomposition has been applied correctly.

However, in their current form, the transformations in Section 5.3 are of expo-nential complexity. Intuitively, this is because we have to check for the presenceof any possible combination of edges in the graph in which the rule has to beapplied. It seems difficult to see how to do better, because contrary to tree-likestructures, graph transformations allow for a large number of matchings. We arecurrently working on a proof of the complexity of this decision problem.

We can extend our work in different directions: On the practical side, wewould like to develop simplification strategies that perform essential reductionsbefore case splitting introduces a combinatorial explosion.

On the theoretical side, it is interesting to further explore the boundary be-tween decidable and undecidable fragments, hopefully leading to a more expres-sive relational fragment than the one of Section 5.1. Several logics for reasoningabout graphs [5] and for pointer structures in programs have been proposed,and an in-depth comparison still has to be done. The decidable fragment in [10],based on transitive closure logic, only allows for a single edge relation, whereasthe logical language in [20] assumes a set of distinguished starting points fortalking about reachability, but does not examine reachability between arbitrarypoints.

The decidable logic described in [13] concentrates on the preservation of datastructure variants (such as doubly-linked lists) in pointer manipulating pro-grams, but does not allow to reason about global graph properties.

Separation Logic (SL) [16] is a specialized logic for reasoning in a pre-/ post-condition style about pointer-manipulating programs. It advocates splitting theheap into disjoint areas, thus reducing the complexity of reasoning about pointermanipulations which may have a global impact due to aliasing. Just like Hoarelogic, SL as such does not aim at being a decidable logic. The decidable fragmentdescribed in [4] is so weak that it is not closed under the heap-manipulating oper-ations of a programming language. It only enables to describe simple propertiesof lists, but not more general properties of connectivity.

The relation of SL and graph rewriting is discussed in [7], however withoutreference to particular decision procedures.

Probably the best way to come to terms with the complexity of graph rewrit-ing is to identify particular classes of graphs that are better behaved. This mightbe tree-like graphs or at least graphs in which the non-determinism of rule ap-plication is strongly restricted.

180 M. Strecker

Acknowledgements. I am grateful for my colleagues Ralph Matthes, ChristianPercebois and Hanh-Ni Tran for discussions about the problem of locality ingraph rewriting and for helpful feedback on preliminary versions of this article.

References

1. Asztalos, M., Lengyel, L., Levendovszky, T.: Towards automated, formal verifica-tion of model transformations. In: Proc. of the 3rd International Conference onSoftware Testing, Verification, and Validation, pp. 15–24. IEEE Computer Society,Los Alamitos (2010)

2. Baldan, P., Corradini, A., Esparza, J., Heindel, T., Konig, B., Kozioura, V.: Ver-ifying red-black trees. In: Proc. of Concurrent Systems with Dynamic AllocatedHeaps, COSMICAH 2005 (2005); Proceedings available as report RR-05-04 (QueenMary, University of London)

3. Baldan, P., Corradini, A., Konig, B.: A framework for the verification of infinite-state graph transformation systems. Information and Computation 206(7), 869–907(2008)

4. Berdine, J., Calcagno, C., O’Hearn, P.: A decidable fragment of separation logic.In: Lodaya, K., Mahajan, M. (eds.) FSTTCS 2004. LNCS, vol. 3328, pp. 97–109.Springer, Heidelberg (2004)

5. Caferra, R., Echahed, R., Peltier, N.: A term-graph clausal logic: Completenessand incompleteness results. Journal of Applied Non-classical Logics 18(4), 373–411(2008)

6. da Costa, S.A., Ribeiro, L.: Formal verification of graph grammars using mathe-matical induction. In: Proc. of the 11th Brazilian Symposium on Formal Methods(SBMF 2008). ENTCS, vol. 240, pp. 43–60. Elsevier (2009)

7. Dodds, M.: Graph Transformation and Pointer Structures. Ph.D. thesis, Universityof York (2008)

8. Ghamarian, A.H., de Mol, M.J., Rensink, A., Zambon, E., Zimakova, M.V.: Mod-elling and analysis using GROOVE. Tech. Rep. TR-CTIT-10-18, Centre for Telem-atics and Information Technology, University of Twente, Enschede (2010)

9. Habel, A., Pennemann, K.H.: Correctness of high-level transformation systemsrelative to nested conditions. Mathematical Structures in Computer Science 19(02),245–296 (2009)

10. Immerman, N., Rabinovich, A., Reps, T., Sagiv, M., Yorsh, G.: The Bound-ary Between Decidability and Undecidability for Transitive-Closure Logics. In:Marcinkowski, J., Tarlecki, A. (eds.) CSL 2004. LNCS, vol. 3210, pp. 160–174.Springer, Heidelberg (2004)

11. Kastenberg, H.: Graph-Based Software Specification and Verification. Ph.D. thesis,University of Twente (2008), http://eprints.eemcs.utwente.nl/13615/

12. Konig, B., Kozioura, V.: Augur 2 – A new version of a tool for the analysis ofgraph transformation systems. In: Proc. of the 5th Int. Workshop on Graph Trans-formation and Visual Modeling Techniques. ENTCS, vol. 211, pp. 201–210. Elsevier(2008)

13. McPeak, S., Necula, G.C.: Data Structure Specifications via Local Equality Ax-ioms. In: Etessami, K., Rajamani, S.K. (eds.) CAV 2005. LNCS, vol. 3576, pp.476–490. Springer, Heidelberg (2005)

14. Nipkow, T., Paulson, L.C., Wenzel, M.: Isabelle/HOL. LNCS, vol. 2283. Springer,Heidelberg (2002)

http://eprints.eemcs.utwente.nl/13615/


15. Pennemann, K.H.: Resolution-Like Theorem Proving for High-Level Conditions.In: Ehrig, H., Heckel, R., Rozenberg, G., Taentzer, G. (eds.) ICGT 2008. LNCS,vol. 5214, pp. 289–304. Springer, Heidelberg (2008)

16. Reynolds, J.C.: Separation logic: A logic for shared mutable data structures. In:Proc. of the 17th Annual IEEE Symposium on Logic in Computer Science, pp.55–74. IEEE Computer Society (2002)

17. Ribeiro, L., Dotti, F.L., da Costa, S.A., Dillenburg, F.C.: Towards theorem provinggraph grammars using Event-B. In: Ermel, C., Ehrig, H., Orejas, F., Taentzer, G.(eds.) Proc. of the International Colloquium on Graph and Model Transformation2010. ECEASST, vol. 30 (2010)

18. Strecker, M.: Modeling and verifying graph transformations in proof assistants. In:Mackie, I., Plump, D. (eds.) International Workshop on Computing with Termsand Graphs. ENTCS, vol. 203, pp. 135–148. Elsevier (2008)

19. Varro, D., Balogh, A.: The model transformation language of the VIATRA2 frame-work. Science of Computer Programming 68(3), 214–234 (2007)

20. Yorsh, G., Rabinovich, A.M., Sagiv, M., Meyer, A., Bouajjani, A.: A logic of reach-able patterns in linked data-structures. The Journal of Logic and Algebraic Pro-gramming 73(1-2), 111–142 (2007)

Contextual Hyperedge Replacement

Frank Drewes1, Berthold Hoffmann2, and Mark Minas3

1 Umea Universitet, Sweden2 DFKI Bremen and Universitat Bremen, Germany3 Universitat der Bundeswehr Munchen, Germany

Abstract. In model-driven design, the structure of software is com-monly specified by meta-models like uml class diagrams. In this paperwe study how graph grammars can be used for this purpose, using state-charts as an example. We extend context-free hyperedge-replacement—which is not powerful enough for this application—so that rules may notonly access the nodes attached to the variable on their left-hand side,but also nodes elsewhere in the graph. Although the resulting notionof contextual hyperedge replacement preserves many properties of thecontext-free case, it has considerably more generative power—enough tospecify software models that cannot be specified by class diagrams.

1 Introduction

Graphs are ubiquitous in science and beyond. When graph-like diagrams areused to model system development, it is important to define precisely whethera diagram is a valid model or not. Often, models are defined as the valid instan-tiations of a meta-model, e.g., the valid object diagrams for a class diagram inuml. A meta-model is convenient for capturing requirements as it can be refinedgradually. It is easy to check whether a given model is valid for a meta-model.However, it is not easy to construct valid sample models for a meta-model, andthey give no clue how to define transformations on all valid models. Also, theirabilities to express structural properties (like hierarchical nesting) are limited;constraints (e.g., in the logic language ocl) have to be used for more complicatedproperties like connectedness.

In contrast to meta-models, graph grammars derive sets of graphs construc-tively, by applying rules to a start graph. This kind of definition is strict, caneasily produce sample graphs by derivation, and its rules provide for a recursivestructure to define transformations on the derivable graphs. However, it must notbe concealed that validating a given graph, by parsing, may be rather complex.

General graph grammars generate all recursively enumerable sets of graphs[16] so that there can be no parsing algorithm. Context-free graph grammarsbased on node replacement or hyperedge replacement [6] do not have the powerto generate graphs of general connectivity, like the language of all graphs, of allacyclic, and all connected graphs etc. We conclude that practically useful kindsof graph grammars should lie in between context-free and general ones. We takehyperedge replacement as a solid basis for devising such grammars, as it has


Contextual Hyperedge Replacement 183

a comprehensive theory, and is very simple: A step removes a variable (repre-sented as a hyperedge) and glues the fixed ordered set of nodes attached to it todistinguished nodes of a graph. The authors have been working on several ex-tensions of hyperedge replacement. Adaptive star replacement [2], devised withD. Janssens and N. Van Eetvelde, allows variables to be attached to arbitrary,unordered sets of nodes. Its generative power suffices to define sophisticated soft-ware models like program graphs [3]. Nevertheless, it inherits some of the strongproperties of hyperedge replacement. Unfortunately, adaptive star rules tend tohave many edges, which makes them hard to understand—and to construct.Therefore the authors have devised contextual graph grammars, where variablesstill have a fixed, ordered set of attached nodes, but replacement graphs maybe glued, not only with these attachments, but also with nodes occurring else-where in the graph, which have been generated in earlier derivation steps [11]. Aswe shall show, their generative power suffices to define non-context-free models.Typically, contextual rules are only modest extensions of hyperedge replacementrules, and are significantly easier to write and understand than adaptive starrules. This qualifies contextual hyperedge grammars as a practical notation fordefining software models. When we add application conditions to contextualrules, as we have done in [11], even subtler software models can be defined.Since conditions are a standard concept of graph transformation, which havebeen used in many graph transformation systems (see, e.g., progres [15]), suchrules are still intuitive.

This paper aims to lay a fundament to the study of contextual hyperedge re-placement. So we just consider grammars without application conditions for themoment, as our major subjects of comparison, context-free hyperedge replace-ment and adaptive star replacement, also do not have them. With context-freehyperedge replacement, contextual hyperedge replacement shares decidabilityresults, characterizations of their generated language, and the existence of aparsing algorithm. Nevertheless, it is powerful enough to make it practicallyuseful for average structural models.

The remainder of this paper is structured as follows. In Section 2 we introducecontextual hyperedge replacement grammars and give some examples. In partic-ular, we discuss a grammar for statecharts in Section 3. Normal forms for thesegrammars are presented in Section 4. In Section 5 we show some of their limita-tions w.r.t. language generation, and sketch parsing in Section 6. We concludewith some remarks on related and future work in Section 7.

2 Graphs, Rules, and Grammars

In this paper, we consider directed and labeled graphs. We only deal with ab-stract graphs in the sense that graphs that are equal up to renaming of nodesand edges are not distinguished. In fact, we use hypergraphs with a generalizednotion of edges that may connect any number of nodes, not just two. Such edgeswill also be used to represent variables in graphs and graph grammars.

184 F. Drewes, B. Hoffmann, and M. Minas

We consider labeling alphabets C = C �C �X that are sets whose elements arethe labels (or “colors”) for nodes, edges, and variables, with an arity functionarity : C �X → C∗.1

A labeled hypergraph over C (graph, for short) G = 〈G, G, attG, �G, �G〉 consistsof disjoint finite sets G of nodes and G of hyperedges (edges, for short) respec-tively, a function attG : G → G∗ that attaches sequences of pairwise distinctnodes to edges so that �∗G(attG(e)) = arity(�G(e)) for every edge e ∈ G,2 and

labeling functions �G : G→ C and �G : G→ C �X . Edges are called variables ifthey carry a variable name as a label; the set of all graphs over C is denoted byGC .

For a graph G and hyperedge e ∈ G, we denote by G− e the graph obtainedby removing e from G. Similarly, for v ∈ G, G − v is obtained by removing vfrom G (together with all edges attached to v).

Given graphs G and H , a morphism m : G → H is a pair m = 〈m, m〉 offunctions m : G→ H and m : G→ H that preserves labels and attachments:

�H ◦ m = �G, �H ◦ m = �G, attH(m(e)) = m∗(attG(e)) for every e ∈ G

As usual, a morphism m : G→ H is injective if both m and m are injective.The replacement of variables in graphs by graphs is performed by applying a

special form of standard double-pushout rules [5].

Definition 1 (Contextual Rule). A contextual rule (rule, for short) r =(L,R) consists of graphs L and R over C such that

– the left-hand side L contains exactly one edge x, which is required to be avariable (i.e., L = {x} with �L(x) ∈ X) and

– the right-hand side R is an arbitrary supergraph of L− x.

Nodes in L that are not attached to x are the contextual nodes of L (and of r);r is context-free if it has no contextual nodes. (Context-free rules are known ashyperedge replacement rules in the literature [7].)

Let r be a contextual rule as above, and consider some graph G. An injectivemorphism m : L → G is called a matching for r in G. The replacement of thevariable m(x) ∈ G by R (via m) is the graph H obtained from the disjoint unionof G−m(x) and R by identifying every node v ∈ L with m(v). We write this asH = G[R/m].

Note that contextual rules are equivalent to contextual star rules as introducedin [11], however without application conditions.

The notion of rules introduced above gives rise to a class of graph grammars.We call these grammars contextual hyperedge-replacement grammars, or brieflycontextual grammars.

1 A∗ denotes finite sequences over a set A; the empty sequence is denoted by ε.2 For a function f : A → B, its extension f∗ : A∗ → B∗ to sequences is defined byf∗(a1, . . . , an) = f(a1) . . . f(an), for all ai ∈ A, 1 � i � n, n � 0.


Definition 2 (Contextual Hyperedge-Replacement Grammar). A con-textual hyperedge-replacement grammar (contextual grammar, for short) is atriple Γ = 〈C,R, Z〉 consisting of a finite labeling alphabet C, a finite set Rof rules, and a start graph Z ∈ GC .

If R contains only context-free rules, then Γ is a hyperedge replacement gram-mar. We let G ⇒R H if H = G[R/m] for some rule (L,R) and for a matchingm : L→ G. Now, the language generated by Γ is given by

L(Γ ) = {G ∈ GC\X | Z ⇒∗R G}.

Contextual grammars Γ and Γ ′ are equivalent if L(Γ ) = L(Γ ′). The classes ofgraph languages generated by hyperedge-replacement grammars and contextualgrammars are denoted by HR and CHR, respectively.

Notation (Drawing Conventions for Graphs and Rules). Graphs aredrawn as in Figure 2 and Figure 4. Circles and boxes represent nodes and edges,respectively. The text inscribed to them is their label from C. (If all nodes carrythe same label, these are just omitted.) The box of an edge is connected to thecircles of its attached nodes by lines; the attached nodes are ordered counter-clockwise around the edge, starting in its north. The boxes of variables are drawnin gray. Terminal edges with two attached nodes may also be drawn as arrowsfrom the first to the second attached node. In this case, the edge label is ascribedto the arrow.

In figures, a contextual rule r = (L,R) is drawn as L : : =R. Small numbersabove nodes indicate identities of nodes in L and R. L : : =R1|R2 · · · is shortfor rules L : : =R1, L : : =R2, . . . with the same left-hand side. Subscripts “n” or“n|m· · · ” below the symbol : : = define names that are used to refer to rules inderivations, as in Figure 1 and Figure 3.

Example 1 (The Language of All Graphs). The contextual grammar in Figure 1generates the set A of loop-free labeled graphs with binary edges, and Figure 2shows a derivation with this grammar. Rules 0 and d generate n � 0 variableslabeled with G; the rules nx generate a node labeled with x, and the rules eainsert an edge labeled with a between two nodes that are required to exist inthe context.

G : : =0|d

〈〉∣∣∣ G G G : : =

x

x , for all x ∈ Cx G y : : =

a

x ya , for all a ∈ C, where arity(a) = xy Z = G

Fig. 1. A contextual grammar (generating the language of all graphs)

G5⇒d G

G

GG

G G3⇒nA A

A

AG

G G3⇒ea A

A

A

a a

a

Fig. 2. A derivation with the rules in Figure 1


It is well known that the languageA cannot be defined by hyperedge-replacementgrammars [7, Chapter IV, Theorem 3.12(1)].3 Thus, as CHR contains HR bydefinition, we have:

Observation 1. HR � CHR.

Flow diagrams are another example for this observation: In contrast to structuredand semi-structured control flow diagrams, unrestricted control flow diagramsare not in HR, because they have unbounded tree-width [7, Chapter IV, Theorem3.12(7)]. However, they can be generated by contextual grammars.

0

D

: : =h|a|b

0

|

0

D

|

0

⊕�

D D

0

D

1

: : =g

0

1

Z =D

Fig. 3. Rules generating unrestricted control flow diagrams

D

⇒b

⊕�

D D

⇒b

D D

D

⊕�

⊕�

⇒h

D

D

⊕�

⊕� 3⇒

a

D

D

⊕�

⊕�

2⇒g

⊕�

�⊕

Fig. 4. A derivation of an unstructured control flow diagram

Example 2 (Control Flow Diagrams). Unrestricted control flow diagrams repre-sent sequences of low-level instructions according to a syntax like this:

I : : = [� :]halt | [� :]x := E | [�1 :] if E then goto �2 | [�1 :]goto �2

The rules in Figure 3 generate unrestricted flow diagrams. The first three rules,h, a, and b, generate control flow trees, and the fourth rule g, which is notcontext-free, inserts gotos to a program state in the context. In Figure 4, theserules are used to derive an “ill-structured” flow diagram.

Note that flow diagrams cannot be defined with class diagrams, because subtypingand multiplicities do not suffice to define rootedness and connectedness of graphs.

3 It is well-known that node replacement (more precisely, confluent edNCE graphgrammars) cannot generate A either [6, Thm. 4.17]. Hence, Observation 1 holdssimilarly for node replacement.


3 A Contextual Grammar for Statecharts

Statecharts [9] are an extension of finite automata modeling the state transitionsof a system in reaction on events. The statechart in Figure 5 describes an auction.Blobs denote states, and arrows denote transitions between them. Black blobsare initial states, blobs with a black kernel are final states, and the others areinner states. Inner states may be compound, containing compartments, separatedwith dashed lines, which contain sub-statecharts that act independently from oneanother, and may themselves contain compound states, in a nested fashion. Textinside a blob names the purpose of a state or of its compartments, and labels attransitions name the event triggering them. (We consider neither more generalevent specifications, nor more special types of states.)

The structure of statecharts can be specified by the class diagram shown inFigure 6. The dotted circle with a gray kernel is abstract, for inner or stop states.An inner state may be composed of compartments (denoted as dashed blobs),which in turn are composed of other states (defining the sub-charts). In exampleslike Figure 5, a compound state is drawn as a big blob with solid lines whereinthe compartments are separated by dashed lines.

The class diagram captures several structural properties of statecharts: Itforbids isolated initial and final states and transitions to initial states; eachcompartment contains exactly one initial state, and compound states and theircompartments form a tree hierarchy as the associations uniting and containingare compositions (indicated by the black diamonds at their sources).

Example 3 (A Grammar for Statecharts). The contextual rules in Figure 7 gen-erate statecharts according to the class diagram in Figure 6. (Let us ignore theparts underlaid in gray for a moment.) The charts in these rules are drawn sothat the compositions uniting and containing are just represented by drawingthe blob of their target within the blob of their source. We assume (for regu-larity) that the topmost statechart is contained in a compartment, see the startgraph Z. The rules for S add transitions to current states, which are either initialor inner states (drawn as gray nodes). The target of the transition is either anew final state (rule f), or a new inner state, to which further transitions may be

Getting Evaluating

Checking

Cancelled

Rejected

Purchased

Auction

Bidding

Payment

offer

continue

accept

authorize

reject

cancel ∗

+t

+ ∗t

containing

∗

uniting

∗

containing

1

Fig. 5. A statechart modeling an auction Fig. 6. A class diagramfor statecharts


S : : =f|m

St

∣∣∣∣∣

S T S

S 10 : : =T

10t

10if �

S : : =c

C C : : =0|p

C

∣∣∣∣

S C

T

1

: : =t|n

1t

∣∣∣∣∣

1 1 tif ∃ Z = S

Fig. 7. Contextual rules for statecharts (with application conditions)

added (rule m), or an inner state that exists in the context, but not necessarilyin the same compartment (rule T). Rule m inserts a variable named T that maygenerate a concrete transition (rule t), or leave the states separate (rule n). (Thisis necessary since the transitions to an inner state in a compartment need notcome from a state in that compartment, like states Canceled and Rejected inFigure 5.) Finally, inner states may be filled (by rules 0 and p for the variableC) with compartments, each containing a statechart as in the start graph Z.

Every state in a chart should be reachable from an initial state. Reachabilitycannot be expressed by class diagrams alone. In order to specify this propertyin a meta-model, the inner state must be extended with an auxiliary attributethat determines this condition by inspecting its direct predecessors, and with alogical constraint, e.g., in ocl, which requires that the value of the attribute istrue for every instance of a state.

Example 2 shows that contextual grammars can express reachability as such.In statecharts, reachability is combined with hierarchical nesting of sub-states,and cannot be specified with contextual rules. However, we may extend contex-tual rules with application conditions, as proposed in [11]. The parts underlaid ingray add application conditions to two rules of Figure 7. In Rule n, the conditionrequires that the target node of variable T is the target of another transition. Itis easy to show that this guarantees reachability from initial states. The condi-tion for rule T expresses yet another consistency requirement: The source andtarget of a transition must not lie in sister compartments of the same compoundstate.

4 Normal Forms of Contextual Grammars

In this section, we study the basic properties of contextual grammars. As it turnsout, these properties are not fundamentally different from the properties knownfor the context-free case. This indicates that contextual hyperedge replacement is


a modest generalization of hyperedge replacement that, to the extent one mightreasonably hope for, has appropriate computational properties.

Let us first look at some normal forms of contextual grammars. We say thata restricted class C of contextual grammars is a normal form of contextualgrammars (of a specified type) if, for every contextual grammar (of that type),one can effectively construct an equivalent grammar in C.

Lemma 1. Contextual grammars in which each rule contains at most one con-textual node are a normal form of contextual grammars.

Proof. This is straightforward. Suppose we wish to implement a rule (L,R)whose left-hand side contains a variable with k attached nodes and l � 1 con-textual nodes. We use l rules to collect the l contextual nodes one by one, finallyending up with a variable that is attached to k + l nodes. The original rule isthen turned into a context-free rule. ��

In the context-free case, so-called epsilon rules and chain rules can easily be re-moved from a grammar. A similar modification is possible for contextual gram-mars. In this context, a rule (L,R) with L = {x} is an epsilon rule if R = L−x,and a chain rule if R − y = L − x for a variable y ∈ R. Note that both epsilonand chain rules are more general than in the context-free case, because L maycontain contextual nodes. In particular, chain rules can make use of these con-textual nodes to “move” a variable through a graph. In the case of epsilon rules,the effect of contextual nodes is that the removal of a variable is subject to thecondition that certain node labels are present in the graph.

Lemma 2. Contextual grammars with neither epsilon nor chain rules are anormal form of those contextual grammars that do not generate the empty graph.

Proof Sketch. While the overall structure of the proof is similar to the corre-sponding proof for the context-free case, its details are slightly more compli-cated. Therefore, we give only a very rough sketch of the proof. The full proofwill be given in a forthcoming extended version of this article.

The proof works as follows. First, it is shown that epsilon rules may be re-moved by composing non-epsilon rules with epsilon rules that remove some ofthe variables in the right-hand side of the original rule. Afterwards, chain rulesare removed by replacing them with rules that correspond to a sequence of chainrules applied in succession, followed by the application of a non-chain rule.

The notion of composition used here has to take contextual nodes into ac-count. Suppose we are given rules r1 = (L1, R1) and r2 = (L2, R2), such thatR1 contains a variable with the same name as the variable in L2. We need to beable to combine both rules even if R1 does not supply r2 with all the necessarycontextual nodes. We do this by enriching L1 with the contextual nodes neededby r2. However, if r1 contains nodes (with the right labels) that are isolated inboth L1 and R1, these are used instead rather than adding even more contex-tual nodes to the left-hand sides. This is a necessary precaution, because thecomposition of chain rules may otherwise create an infinite set of rules.


The removal of epsilon rules is non-trivial, because we have to make sure toavoid introducing deadlocks. To see this, suppose a rule r1 creates a variablee1 that can be removed by an epsilon rule containing a contextual node labeleda1. Similarly, assume that r2 creates a variable e2 that can be removed by anepsilon rule containing a contextual node labeled a2. Assume furthermore that r1generates an a2-labeled node and r2 generates an a1-labeled node. Then, givena graph that contains the left-hand sides of r1 and r2, we can apply r1 andr2, followed by the epsilon rules that delete e1 and e2. However, if we composer1 with the first epsilon rule and r2 with the second one, neither of the composedrules may be applicable, because the first contains an a1-labeled contextual nodeand the second contains an a2-labeled contextual node. Fortunately, the problemcan be solved by a guess-and-verify strategy, thanks to the fact that the numberof contextual nodes in the left-hand sides of rule is bounded. Roughly speaking,the guess-and-verify strategy makes sure that the required contextual nodes willbe generated somewhere in the graph.

Finally, let us sketch how to remove chain rules, assuming that the gram-mar does not contain epsilon rules. For this, the following observation is crucial.Consider a derivation G0 ⇒R G1 ⇒R · · · ⇒R Gm that consists of m− 1 appli-cations of chain rules followed by a single application of another rule. Supposethe variables replaced are x1, . . . , xm, and let 1 � i1 < · · · < in = m be thoseindices such that xm = xin is a direct descendant of xin−1 , which is a direct de-scendent of xin−2 , and so on. Then all derivation steps that replace variables in{xi1 , . . . , xin} can be postponed until after the other m−n steps. This is becausethe chain rules do not create nodes that the other rules may use as contextualnodes. In other words, we can assume that ij = m − n + j for all j ∈ [n]. As aconsequence, it is safe to modify Γ by adding all rules obtained by composing asequence of chain rules with a single non-chain rule and remove all chain rules.Thanks to the observation above, the language generated stays the same. ��

Note that, unfortunately, it seems that the normal forms of the previous twolemmas cannot be achieved simultaneously.

Definition 3 (Reducedness of Contextual Grammars). In Γ = 〈C,R, Z〉,a rule r ∈ R is useful if there is a derivation of the form Z ⇒∗

R G⇒r G′ ⇒∗R H

such that H ∈ GC\X . Γ is reduced if every rule in R is useful.

Note that, in the case of contextual grammars, usefulness of rules is not equiv-alent to every rule being reachable (i.e., for some G′, the part of the derivationabove up to G′ exists) and productive (i.e., for some G, the part starting fromG exists), because it is important that the pairs (G,G′) are the same.

Theorem 1. Reducedness is decidable for contextual grammars.

Proof Sketch. Let us call a variable name ξ useful if there is a useful rule whoseleft-hand side variable has the name ξ. Clearly, it suffices to show that it can bedecided which variable names are useful. To see this, note that we can decidereducedness by turning each derivation step into two, first a context-free step


that nondeterministically “guesses” the rule to be applied and remembers theguess by relabeling the variable, and then a step using the guessed rule. Thenthe original rule is useful if and only if the new variable name recording the guessis useful.

Assume that the start graph is a single variable without attached nodes.Then, derivations can be represented as augmented derivation trees, where thevertices represent the rules applied. Suppose that some vertex ω represents therule (L,R), where L contains the contextual nodes u1, . . . , uk. Then the augmen-tation of ω consists in contextual references (ω1, v1), . . . , (ωk, vk), where each ωi

is another vertex of the tree, and the vi are distinct nodes, each of which isgenerated by the rule at ωi and carries the same label as ui. The pair (ωi, vi)means that the contextual node ui was matched to the node vi generated at ωi.Finally, in order to correspond to a valid derivation, there must be a linear order≺ on the vertices of the derivation tree such that ω ≺ ω′ for all children ω′ of avertex ω, and ωi ≺ ω for each ωi as above.

4

Now, to keep the argument simple, assume that every rule contains at mostone contextual node (see Lemma 1), and also that the label of this node differsfrom the labels of all nodes the variable is attached to. (The reader should easilybe able to check that the proof generalizes to arbitrary contextual grammars.)The crucial observation is the following. Suppose that, for a given label a ∈ C, ωa

is the first vertex (with respect to ≺) that generates an a-labeled node va. Then,in each other vertex ω as above, if the rule contains an a-labeled contextual nodeu, the corresponding contextual reference (ω′, v) can be replaced with (ωa, va).This may affect the graph generated, but does not invalidate the derivation tree.We can do this for all vertices ω and node labels a. As a consequence, at most |C|vertices of the derivation tree are targets of contextual references. Moreover, itshould be obvious that, if the derivation tree is decomposed into s(t(u)), wherethe left-hand sides of the rules at the roots of t and u are the same, then s(u) isa valid derivation tree, provided that no contextual references in s and u pointto vertices in t. It follows that, to check whether a variable name is useful, weonly have to check whether it occurs in the (finite) set of valid derivation treessuch that (a) all references to nodes with the same label are equal and (b) forevery decomposition of the form above, there is a contextual reference in s or uthat points to a vertex in t. ��

Clearly, removing all useless rules from a contextual grammar yields an equiv-alent reduced grammar. Thus, we can compute a reduced contextual grammarfrom an arbitrary one by determining the largest subset of rules such that therestriction to these rules yields a reduced contextual grammar.

Corollary 1. Reduced contextual grammars are a normal from of contextualgrammars.

4 To be precise, validity also requires that the variable replaced by the rule at ω is notattached to vi.


By turning a grammar into a reduced one, it can furthermore be decided whetherthe generated language is empty (as it is empty if and only if the set of rules isempty and the start graph contains at least one variable).

Corollary 2. For a contextual grammar Γ , it is decidable whether L(Γ ) = ∅.

5 Limitations of Contextual Grammars

Let us now come to two results that show limitations of contextual grammarssimilar to the known limitations of hyperedge-replacement grammars. The firstof these results is a rather straightforward consequence of Lemma 2: as in thecontext-free case, the languages generated by contextual grammars are in NP,and there are NP-complete ones among them.

Theorem 2. For every contextual grammar Γ , it holds that L(Γ ) ∈ NP. More-over, there is a contextual grammar Γ such that L(Γ ) is NP-complete.

Proof. The second part follows from the fact that this holds even for hyperedge-replacement grammars, which are a special case of contextual grammars. For thefirst part, by Lemma 2, it may be assumed that Γ contains neither epsilon norchain rules. It follows that the length of each derivation is linear in the size of thegraph generated. Hence, derivations can be nondeterministically “guessed”. ��

It should be pointed out that the corresponding statement for hyperedge-replacement languages is actually slightly stronger than the one above, because,in this case, even the uniform membership problem is in NP (i.e., the input is(Γ,G) rather than just G). It is unclear whether a similar result can be achievedfor contextual grammars, because the construction given in the proof of Lemma 2may, in the worst case, lead to an exponential size increase of Γ .

Theorem 3. For a graph G, let |G| be either the number of nodes of G, thenumber of edges of G, or the sum of both. For every contextual grammar Γ , ifL(Γ ) = {H1, H2, . . . } with |H1| � |H2| � . . ., there is a constant k such that|Hi+1| − |Hi| � k for all i ∈ N.

Proof Sketch. The argument is a rather standard pumping argument. Considera contextual grammar Γ without epsilon and chain rules, such that L(Γ ) isinfinite. (The statement is trivial, otherwise.) Now, choose a derivation Z =G0 ⇒ G1 ⇒ · · · ⇒ Gn of a graph Gn ∈ L(Γ ), and let xi be the variable in Gi

that is replaced in Gi ⇒ Gi+1, for 0 � i < n. If the derivation is sufficiently long,there are i < j such that xi and xj have the same label and xj is a descendantof xi (in the usual sense). Let i = i1 < · · · < ik = j be the indices l, i � l � j,such that xl is a descendant of xi. The steps in between those given by i1, . . . , ik(which replace variables other than the descendants of xi) may be necessary tocreate the contextual nodes that “enable” the rules applied to xi1 , . . . , xik−1.However, in Gj , these contextual nodes do all exist, because derivation steps donot delete nodes. This means that the sub-derivation given by the steps in which


xi1 , . . . , xik−1 are replaced can be repeated, using xj as the starting point (andusing, in each of these steps, the same contextual nodes as the original step).This pumping action can, of course, be repeated, and it increases the size of thegenerated graph by at most a constant each time. As there are neither epsilonnor chain rules, this constant is non-zero, which completes the proof. ��

Corollary 3. The language of all complete graphs is not in CHR.

6 Parsing

In [11], a parser has been briefly sketched that can be used for contextual hy-peredge replacement grammars with application conditions and, therefore, forcontextual grammars. The following describes the parser in more detail, includ-ing the grammar transformations that are necessary before it can be applied.

The parser adopts the idea of the Cocke-Younger-Kasami (CYK) parser forstrings, and it requires the contextual grammar to be in Chomsky normal form(CNF), too. A contextual grammar is said to be in CNF if each rule is eitherterminal or nonterminal. The right-hand side of a terminal rule contains exactlyone edge which is terminal, whereas the right-hand side of a nonterminal rulecontains exactly two edges which are variables. Rules must not contain isolatednodes in their right-hand sides. In the following, we first outline that everycontextual grammar Γ can be transformed into a grammar Γ ′ in CNF so thata parser for Γ ′ can be used as a parser for Γ . We then consider a contextualgrammar in CNF and sketch a CYK parser for such a grammar.

If the right-hand side of a rule contains an isolated node, it is either (i) acontextual node, or (ii) a node generated by the rule, or (iii) attached to thevariable of the left-hand side. In case (i), we simply remove the node from therule. However, the parser must make sure in its second phase (see below) thatthe obtained rule is only applied after a node with corresponding label has beencreated previously. Case (ii) can be avoided if we transform the original rule setR to R′ where each node generated by a rule is attached to a unary hyperedgewith a new label, say ν ∈ C. Instead of parsing a graph G we have to parse agraph G′ instead where each node is attached to such a ν-edge. Finally, case (iii)can be avoided by transforming R′ again, obtaining R′′. The transformationprocess works iteratively: Assume a rule L : : =R with R containing isolatednodes of kind (iii). Let x ∈ L with label ξ be the variable in L. This rule isreplaced by a rule L′ : : =R′ where L′ and R′ are obtained from L and R byremoving the isolated nodes of kind (iii) and by attaching a new variable to theremaining nodes of att(x), introducing a new variable name ξ′ ∈ X . We nowsearch for all rules that have ξ-variables in their right-hand sides. We copy theserules, replace all variables labeled ξ by ξ′-variables in their right-hand sides,5 andadd the obtained rules to the set of all rules. This process is repeated until norule with isolated nodes is left. Obviously, this procedure terminates eventually.

5 This procedure assumes that no rule contains more than one ξ-edge in its right-handside. It is easily generalized to rules with multiple occurrences of ξ-edges.


We assume that the start graph is a single variable labeled ζ, for some ζ ∈ Xwith arity(ζ) = ε. Thus, no ζ-edge will ever be replaced by a ζ′-edge. It is clearthat Z ⇒∗

R′ G iff Z ⇒∗R′′ G for each graph G ∈ GC\X .

Afterwards, chain rules are removed (see Lemma 2), and the obtained con-textual grammar is transformed into an equivalent grammar in CNF using thesame algorithm as for string grammars.6 Based on this grammar, the parser an-alyzes a graph G in two phases. The first phase creates trees of rule applicationsbottom-up. The second phase searches for a derivation by trying to find a suit-able linear order ≺ on the nodes of one of the derivation trees, as in the proofof Theorem 1.

In the first phase, the parser computes n sets S1, S2, . . . , Sn where n is the num-ber of edges in G. Each set Si eventually contains all graphs (called “Si-graphs”in the following) that are isomorphic to the left-hand side of any rule, except fortheir contextual nodes which are left out, and that can be derived to any subgraphof G that contains exactly i edges, if any required contextual nodes are provided.

Set S1 is built by finding each occurrence s of the right-hand side R of anyterminal rule (L,R) and adding the isomorphic image s′ of L to S1, but leavingout all of its contextual nodes. Graph s′ additionally points to its “child” graph s.

The remaining sets Si, i > 1, are then constructed using nonterminal rules.A nonterminal rule (L,R) is reversely applied by selecting appropriate graphs sand s′ in sets Si and Sj , respectively, such that R ∼= s ∪ s′. A new graph s′′ isthen7 added to the set Sk where s′′ is isomorphic to L without its contextualnodes. Note that k = i + j since each Si-graph can be derived to a subgraph ofG with exactly i edges. Graph s′′ additionally points to its child graphs s ands′. Therefore, each instance of the start graph Z in Sn represents the root of atree of rule applications and, therefore, a derivation candidate for G. Note thatcontextual nodes are not explicitly indicated in these trees because they havebeen removed from the Si-graphs. Contextual nodes are rather treated as if theywere generated by the rules. However, they can be easily distinguished fromreally generated ones by inspecting the rules used for creating the Si-graphs.

The second parser phase tries to establish the linear order ≺ on the nodes ofthe derivation tree. The order must reflect the fact that each contextual nodemust have been generated earlier in the derivation. This process is similar totopological sorting, and it succeeds iff a derivation of G exists.

The run-time complexity of this parser highly depends on the grammar sincethe first phase computes all possible derivation trees. In bad situations, it is com-parable to the exponential algorithm that simply tries all possible derivations.

6 This is possible iff the L(Γ ) does not contain the empty graph which is easily ac-complished since chain rules have been removed.

7 Furthermore, the parser must check whether the subgraphs of G being derivable froms and s′ do not have edges in common. This is easily accomplished by associatingeach graph in any set Si with the set of all edges in the derivable subgraph of G.A rule may be reversely applied to s and s′ if the sets associated with s and s′ aredisjoint.


In “practical” cases without ambiguity (e.g., for control flow diagrams,cf. Example 2), however, the parser runs in polynomial time. Reasonably fastparsing has been demonstrated by DiaGen [12] that uses the same kind ofparser.

A simpler, more efficient way of parsing can be chosen for grammars with thefollowing property: A contextual grammar Γ = (C,R, Z) is uniquely reductiveif its derivation relation ⇒R has an inverse relation ⇒R−1 (called reductionrelation) that is is terminating and confluent. Then every graph has a reductionsequence G⇒∗

R−1 Y so that no rule ofR−1 applies to Y . Confluence of reductionimplies that the graph Y is unique up to isomorphism so thatG is in the languageof Γ if and only if Y equals Z up to isomorphism.

Let Γ be a contextual grammar with neither epsilon, nor chain rules (ByLemma 2, each contextual grammar without epsilon rules can be transformedinto such a normal form). Then every right-hand side of a rule contains at leastone terminal edge or one new node, and reductions G⇒∗

R−1 Y terminate, aftera linear number of steps. Confluence of terminating reductions ⇒R−1 can beshown by checking that their critical pairs are strongly convergent [13]. So itcan be decided whether Γ is uniquely reductive.

Since the construction of a single reduction step is polynomial for a fixed setof rules, the complexity of parsing is polynomial as well. Note, however, thatparsing does not yield unique derivation structures if the reduction relation hascritical pairs.

Example 4 (Parsing of Control Flow Diagrams). The grammar in Example 2does not contain epsilon or chain rules. The right-hand sides of the rules mayoverlap in their interface node. Overlap in interface nodes alone does not lead toa critical pair, because the rules are still parallelly independent. The right-handsides of the recursive rules for assignment and branching may also overlap invariables. This gives no critical pair either, because the inverse rules cannot beapplied to the overlap: they violate the dangling condition. The rules are thusuniquely reductive.

7 Conclusions

In this paper we have studied fundamental properties of contextual grammars.They have useful normal forms, namely rules with at most one contextual node,grammars without epsilon and chain rules, and reduced grammars.With context-free grammars, they share certain algorithmic properties (i.e., decidability ofreducedness and emptiness, as well as an NP-complete membership problem) andthe linear growth of their languages. Nevertheless, contextual grammars are morepowerful than context-free ones, as illustrated in Figure 8. Let NR, ASR, cCHR,and cASR denote the classes of graph languages generated by node replacement,adaptive star replacement, conditional contextual hyperedge replacement, andconditional adaptive star grammars, respectively. HR is properly included inNR [6, Section 4.3], as is NR in ASR [2, Corollary 4.9]. The proper inclusionof HR in CHR is stated in Observation 1. Corollary 3 implies that CHR neither


cCHR CHR

cASR ASR NR

HR

Fig. 8. Inclusion of languages studied in this paper and in [2,11]

includes NR, nor ASR, nor cCHR, because these grammars generate the languageof complete graphs. We do not yet know whether ASR includes CHR; the relationof cCHR to ASR and cASR is open as well. Example 2 indicates that contextualgrammars allow for a finer definition of structural properties of models than classdiagrams. Application conditions do further increase this power, as discussed inSection 3.

Some work related to the concepts shown in this paper shall be mentionedhere. Context-exploiting rules [4] correspond to contextual rules with a positiveapplication condition, and are equivalent to the context-embedding rules usedto define diagram languages in DiaGen [12]. The context-sensitive hypergraphgrammars discussed in [7, Chapter VIII] correspond to context-free rules with apositive application condition. We are not aware of any attempts to extend nodereplacement in order to define graph languages as they are discussed in this pa-per. The graph reduction specifications [1] mentioned in Section 6 need not usenonterminals, and their rules may delete previously generated subgraphs. Theyare therefore difficult to compare with contextual grammars. Example 4 showsthat some contextual rules specify graph reductions, and may thus use theirsimple parsing algorithm. Shape analysis aims at specifying pointer structuresin imperative programming languages (e.g., leaf-connected trees), and at veri-fying whether this shape is preserved by operations. Several logical formalismshave been proposed for this purpose [14]. For graph transformation rules, shapeanalysis has been studied for shapes defined by context-free grammars [10] andby adaptive star grammars [3]. We are currently working on shape analysis ofgraph transformation rules w.r.t. contextual grammars.

Future work on contextual grammars shall clarify the open questions con-cerning their generative power, and continue the study of contextual rules withrecursive application conditions [8] that has been started in [11]. Furthermore,we aim at an improved parsing algorithm for contextual grammars that are un-ambiguous modulo associativity and commutativity of certain replicative rules.

Acknowledgements. We wish to thank Annegret Habel for numerous usefulcomments on the contents of this paper, and the reviewers for their advice toenhance the “smack of industrial relevance” of this paper.


References

1. Bakewell, A., Plump, D., Runciman, C.: Specifying pointer structures by graph re-duction. Mathematical Structures in Computer Science (2011) (accepted for pub-lication)

2. Drewes, F., Hoffmann, B., Janssens, D., Minas, M.: Adaptive star grammars andtheir languages. Theoretical Computer Science 411(34-36), 3090–3109 (2010)

3. Drewes, F., Hoffmann, B., Janssens, D., Minas, M., Van Eetvelde, N.: ShapedGeneric Graph Transformation. In: Schurr, A., Nagl, M., Zundorf, A. (eds.)AGTIVE 2007. LNCS, vol. 5088, pp. 201–216. Springer, Heidelberg (2008)

4. Drewes, F., Hoffmann, B., Minas, M.: Context-exploiting shapes for diagram trans-formation. Machine Graphics and Vision 12(1), 117–132 (2003)

5. Ehrig, H., Ehrig, K., Prange, U., Taentzer, G.: Fundamentals of Algebraic GraphTransformation. EATCS Monographs on Theoretical Computer Science. Springer(2006)

6. Engelfriet, J.: Context-Free Graph Grammars. In: Handbook of Formal Languages.Beyond Words, vol. 3, ch. 3, pp. 125–213. Springer (1999)

7. Habel, A.: Hyperedge Replacement: Grammars and Languages. LNCS, vol. 643.Springer, Heidelberg (1992)

8. Habel, A., Radke, H.: Expressiveness of graph conditions with variables. In: Ermel,C., Ehrig, H., Orejas, F., Taentzer, G. (eds.) International Colloquium on Graphand Model Transformation 2010. ECEASST, vol. 30 (2010)

9. Harel, D.: On visual formalisms. Communication of the ACM 31(5), 514–530 (1988)10. Hoffmann, B.: Shapely hierarchical graph transformation. In: Proc. of the IEEE

Symposia. on Human-Centric Computing Languages and Environments, pp. 30–37.IEEE Computer Press (2001)

11. Hoffmann, B., Minas, M.: Defining models – Meta models versus graph grammars.In: Kuster, J.M., Tuosto, E. (eds.) Graph Transformation and Visual ModelingTechniques 2010. ECEASST, vol. 29 (2010)

12. Minas, M.: Concepts and realization of a diagram editor generator based on hyper-graph transformation. Science of Computer Programming 44(2), 157–180 (2002)

13. Plump, D.: Hypergraph Rewriting: Critical Pairs and Undecidability of Confluence.In: Sleep, M.R., Plasmeijer, M.J., van Eekelen, M.C. (eds.) Term Graph Rewriting,Theory and Practice, pp. 201–213. Wiley & Sons (1993)

14. Sagiv, M., Reps, T., Wilhelm, R.: Solving shape-analysis problems in languageswith destructive updating. ACM Transactions on Programming Languages andSystems 20(1), 1–50 (1998)

15. Schurr, A., Winter, A., Zundorf, A.: The Progres Approach: Language and Envi-ronment. In: Ehrig, H., Engels, G., Kreowski, H.-J., Rosenberg, G. (eds.) Handbookof Graph Grammars and Computing by Graph Transformation. Applications, Lan-guages, and Tools, vol. 2, ch. 13, pp. 487–550. World Scientific (1999)

16. Uesu, T.: A system of graph grammars which generates all recursively enumerablesets of labelled graphs. Tsukuba Journal of Mathematics 2, 11–26 (1978)

The Added Value of Programmed GraphTransformations – A Case Study

from Software Configuration Management

Thomas Buchmann, Bernhard Westfechtel, and Sabine Winetzhammer

Lehrstuhl Angewandte Informatik 1, University of BayreuthD-95440 Bayreuth, Germany

[email protected]

Abstract. Model-driven software engineering intends to increase the productiv-ity of software engineers by replacing conventional programming with the devel-opment of executable models at a high level of abstraction. It is claimed that graphtransformation rules contribute towards this goal since they provide a declarative,usually graphical specification of complex model transformations. Frequently,graph transformation rules are organized into even more complex model trans-formations with the help of control structures, resulting in full-fledged supportfor executable behavioral models.

This paper examines the added value of programmed graph transformationswith the help of a case study from software configuration management. To thisend, a large model is analyzed which was developed in the MOD2-SCM projectover a period of several years. The model was developed in Fujaba, which pro-vides story diagrams for programming with graph transformations. Our analysisshows that the model exhibits a strongly procedural flavor. Graph transforma-tion rules are heavily used, but typically consist of very small patterns. Further-more, story diagrams provide fairly low level control structures. Altogether, thesefindings challenge the claim that programming with graph transformations isperformed at a significantly higher level of abstraction than conventional pro-gramming.

1 Introduction

Model-driven software engineering is a discipline which receives increasing attention inboth research and practice. Object-oriented modeling is centered around class diagrams,which constitute the core model for the structure of a software system. From class di-agrams, parts of the application code may be generated, including method bodies forelementary operations such as creation/deletion of objects and links, and modificationsof attribute values. However, for user-defined operations only methods with empty bod-ies may be generated which have to be filled in by the programmer. Here, programmedgraph transformations may provide added value for the modeler. A behavioral modelfor a user-defined operation may be specified by a programmed graph transformation.A model instance being composed of objects, links, and attributes is considered as anattributed graph. A graph transformation rule specifies the replacement of a subgraph ina declarative way. Since it may not be possible to model the behavior of a user-defined


The Added Value of Programmed Graph Transformations 199

operation with a single graph transformation rule, control structures are added to modelcomposite graph transformations.

But what is the added value of programmed graph transformations? Typical argu-ments which have been frequently repeated in the literature in similar ways are thefollowing ones:

1. A graph transformation rule specifies a complex transformation in a rule-based,declarative way at a much higher level of abstraction than a conventional programcomposing elementary graph operations.

2. Due to the graphical notation, programming with graph transformations is intuitiveand results in (high-level) programs which are easy to read and understand.

This paper examines the added value of programmed graph transformations by analyz-ing a large model which was developed in the MOD2-SCM project (Model-Driven andModular Software Configuration Management) [3] over a period of several years. Themodel was developed in Fujaba [8], which provides story diagrams for programmingwith graph transformations. We analyze the MOD2-SCM model both quantitatively andqualitatively to check the claims stated above.

2 MOD2-SCM

The MOD2-SCM project [3] is dedicated to the development of a model-driven productline for Software Configuration Management (SCM) systems [1]. In contrast to com-mon SCM systems, which have their underlying models hard-wired in hand-written pro-gram code, MOD2-SCM has been designed as a modular and model-driven approachwhich (a) reduces the development effort by replacing coding with the creation of exe-cutable models and (b) provides a product line supporting the configuration of an SCMsystem from loosely coupled and reusable components.

To achieve this goal, we used Fujaba [8] to create the executable domain model ofthe MOD2-SCM system. The main part of the work was to (1) create a feature model[4], that captures the commonalities and variable parts within the domain software con-figuration management and (2) to create a highly modular domain model whose looselycoupled components can be configured to derive new products. To this end, a model li-brary consisting of loosely coupled components that can be combined in an orthogonalway has been built around a common core.

The success of a product line heavily depends upon the fact that features that havebeen declared as independent from each other in the feature model are actually inde-pendent in their realizing parts of the domain model. Thus, a thorough analysis of thedependencies among the different modules is crucial [3] in order to derive valid prod-uct configurations. In order to keep track of the dependencies in large domain models, atool based upon UML package diagrams has been developed and integrated with Fujabato support the modeler during this tedious task [2]. In the context of the MOD2-SCMproject, graph transformations were used to specify the behavior of the methods thathave been declared in the domain model.

In this paper, we will discuss the added value of graph transformations especiallyin the development of large and highly modular software systems. The added value

200 T. Buchmann, B. Westfechtel, and S. Winetzhammer

of Fujaba compared with other CASE tools is the ability to generate executable codeout of behavioral models. Behavioral modeling in Fujaba is performed with story dia-grams which are similar to interaction overview diagrams in UML2 [6]. Within storydiagrams, activities and transitions are used to model control flow. Fujaba supports twokinds of activities: (1) statement activities, allowing the modeler to use source codefragments that are merged 1:1 with the generated code, and (2) story activities. A storyactivity contains a story pattern consisting of a graph of objects and links. A static pat-tern encodes a graph query, a pattern containing dynamic elements represents a graphtransformation rule. Story patterns may be decorated with constraints and collaborationcalls. A story activity may be marked as a “for each” activity, implying that the follow-ing activities are performed for each match of the pattern. In addition to activity nodes,story diagrams contain start, end, and decision nodes.

In the following section, we analyze the domain model of MOD2-SCM with a spe-cific focus on story diagrams.

3 Analysis

3.1 Quantitative Analysis

Tool support was required to analyze the structure and complexity of the MOD2-SCMspecification. Due to the size of the project, determining the numbers listed in Tables 1and 2 would have been a tedious task. Therefore, we wrote a Fujaba plug-in that directlyoperates on Fujaba’s abstract syntax graph to acquire the numbers we were interestedin. We conclude from the collected numbers:

Table 1. Type and number of language elements

Model element(structural model)

Totalnumber

Totalnumber Model element

(behavioral model)

Totalnumber

Totalnumber(structural model) MOD2 SCM CodeGen2 (behavioral model) MOD2 SCM CodeGen2

Packages 68 18 Story diagrams 540 339

Classes 175 162 Story patterns 988 850

Abstract Classes 18 28 Objects 1688 1997

I t f 32 10 N ti bj t 42 22Interfaces 32 10 Negative objects 42 22

Attributes 177 181 Multi objects 25 9

Methods 650 443 Links 725 1121Methods 650 443 Links 725 1121

Generalizations 220 247 Paths 13 7

Associations 148 166 Statement activities 264 64Associations 148 166 Statement activities 264 64

Collaboration calls 1183 711

For each activities 27 88

1. The number of story patterns per story diagram is rather low (an average of 1.83story patterns were used per story diagram). This indicates a procedural style of themodel and methods of lower complexity.


Table 2. Significant ratios of language elements

Metric MOD2 SCM CodeGen2 Metric MOD2 SCM CodeGen2

Cl / k 2 57 9 N i bj / 0 04 0 03Classes/package 2.57 9 Negative objects/pattern 0.04 0.03

Attributes/class 1.01 1.12 Multi objects/pattern 0.03 0.01

Methods/class 3 71 2 73 Paths/pattern 0 01 0 01Methods/class 3.71 2.73 Paths/pattern 0.01 0.01

Patterns/story diagram 1.83 2.51 Statement activities/story pattern 0.27 0.08

Objects/pattern 1.71 2.35 Collaboration calls/story pattern 1.20 0.84Objects/pattern 1.71 2.35 Collaboration calls/story pattern 1.20 0.84

Links/pattern 0.73 1.32

2. Within a story pattern, only a few objects and links are used (1.71 objects and 0.73links, respectively).

3. The number of collaboration calls is rather high (an average number of 1.2 collab-oration calls per pattern was determined).

4. Given the fact that we tried to use story patterns as much as possible, the fraction ofstatement activities is still rather high (0.27 statement activities per story activity).Furthermore, the seamless integration of hand-written Java code and story patternsprovides lots of advantages, but it also implies one big disadvantage: The model isno longer platform-independent. For example, changing the code generation tem-plates to generate C# code is no longer possible without manually changing eachstatement activity in the domain model as well.

5. Complex elements within story patterns (negative objects, multi-objects or paths)were used only very rarely within the domain model.

Generally, the specification of the MOD2-SCM system is highly procedural and es-sentially lies at the same level of abstraction as a conventional program. The averagecomplexity of the implemented methods is rather low. Furthermore, the graph transfor-mation rules are mostly limited to finding simple patterns in the object graph and toinserting a single new object at the appropriate position and/or calling another method.

3.2 Qualitative Analysis

In addition to interpreting the numbers shown in the previous section, we took a closerlook at the story diagrams of the domain model to examine the expressive power of themodeling language and the readability of story diagrams. With respect to story patterns,we observed:

6. Story patterns are easy to read due to the graphical notation. Furthermore, storypatterns potentially have a high expressive power, but this power is only rarelyexploited since the highly modular architecture results in a fine-grained decompo-sition of the domain model.

We drew the following conclusions concerning control flow:


AbstractDeltaStorage::appendDelta(...) : Boolean

1 : String predVID := (String) oidVidMap.get(newItem.getOID())2 : String predStorageID := transformToStorageID(...)

S f S ( )3 : String storageID := transformToStorageID(...)

[f il ]predStorageContent := (IDeltifiableItem) this.restore(...)

[failure]

false

thisnewDelta := Delta := new Delta(...)

storageID := storageID

stores [failure]

f l

<<create>>

predStorageItem : AbstractStorageItem

storageID == predStorageID

stores hasNextfalse

[success]

storageID == predStorageIDtrue

Fig. 1. Story diagram of average complexity

7. It is evident that Fujaba does not provide any ”higher“-level control structures.In fact, in terms of control structures, the level of abstraction provided by Fujabalies even below conventional programming languages, as story diagrams are verysimilar to flow charts.

8. In many cases, Java statement activities are mixed up with story patterns, e.g., forexception handling. Fujaba does not catch external exceptions raised in the exe-cution of story patterns, e.g., by external Java methods executed via collaborationcalls. Such low-level details need to be handled in Java.

9. Furthermore, Fujaba itself does not provide any mechanisms to iterate over standardcollections. Collections are implicitly used within for-each activities, but no explicitsupport is provided for the user.

10. The graphical programming style may result in loss of the overall picture if thediagrams are too large and complex. Readability suffers especially (but not only)when the story diagram does not fit onto a single screen.

4 Examples

In this section, we give some examples that reinforce the statements of the previoussection. Figure 1 represents a method implementation which we consider to be of av-erage complexity (according to the collected metrics data). It is a typical example forthe observations (1) – (5) made in Section 3.1 as well as observation (6). The methodis used to append a forward delta in order to store a new state of a versioned object.The first story pattern consists only of collaboration calls that retrieve different requiredparameters. The second pattern retrieves the content of the predecessor version (whichmust have been stored as a delta). This content is used in the third pattern (the onlygraph transformation rule) to compute the difference and to store it at the appropriateposition in the object graph.

All story patterns occurring in Figure 1 are quite simple. Figure 2 shows a (mod-erately) complex story pattern which stores a backward delta. The enclosing story di-agram is called when a version stored as baseline is to be replaced with a successor


AbstractDeltaStorage::insertDeltaForBaseline(...) : Boolean

. . .

thisstores oldBaseline : Baseline

storageID == baselinestorageID

successorDelta : DeltasuccessorDelta : DeltahasNext

<<delete>>

replacementDelta := Delta := new Delta(...)

storageID := baselineStorageID

storeshasNext<<create>>

hasNext

newBaseline : Baseline := addNewBaseline(...)<<create>>

[failure][success]

throw new ItemNotFoundException(...);

falsetrue

Fig. 2. A (moderately) complex story pattern

version. To this end, the old baseline is replaced with a new baseline and a backwarddelta. In fact this is one of the most complex patterns throughout the whole MOD2-SCMmodel, which does not include any patterns with more than 6 objects. This example il-lustrates a strength of story patterns: The effect of a graph transformation is documentedin an easily comprehensible way. However, most patterns are much simpler, implyingthat the equivalent Java code would as well be easy to grasp (observation (6)).

Figure 3 shows the story diagram with the highest number of story patterns through-out the MOD2-SCM project. The story diagram is used to update the local version in-formation within the user’s workspace after changes have been committed to the server.This method is very complex if we take the average number of patterns per story dia-gram into account. However, its individual steps are not complex at all. Listing 1 showsthe purely hand-written implementation in Java. Essentially, the method consists of asingle loop iterating over a list of object identifiers. Two of the story patterns containplain Java code since Fujaba does not supply high level constructs for iterating overstandard collections (observation (9)). The remaining story patterns are also very sim-ple (observation (5)). Thus, it is not a big challenge to code this story diagram in Java.

The story diagrams presented so far do not contain statement activities, except for asmall activity in Figure 2. We used statement activities only when they were impossibleor awkward to avoid. Observation (4) showed that our attempt to eliminate story patternswas only successful to a limited extent. The next two examples demonstrate the reasonsfor that.

The first example (Figure 4) shows a story diagram which is used to configure theMOD2-SCM repository server at runtime according to the features selected by the user.This method is inherently procedural and consists of a large number of conditionalstatements for handling the different cases. The modeler decided to code the methodbody as a single statement activity. Splitting this activity up into many decision nodesand activity nodes containing small code fragments would have resulted in a huge andunreadable diagram (observation (7)).


MOD2SCMServerWorkspaceModule::processUpdateResult(pmiList : PMIList, oidVidMap : Map, replace : Boolean) : Boolean

thishasModules

workspaceManager : AbstractWorkspaceManageroidIterator : pmiList.getOIDList().iterator()

info{oidIterator.hasNext()}

[failure] [success]

info

changed == truechanged := false

{replace}

info

changed == false

oldItem IProd ctModelItem

observes notifies

this info

changed == false

1: processUpdateResultInsertNewItem(...)

<<delete>> <<delete>>

1: String oid := (String) oidIterator.next()

{replace}oldItem : IProductModelItemInsertNewItem(...)

workspaceManager

stores

newItem := pmiList.select(oid)this 1: notifyMergeNecessary(info, newInfo)

info

changed == true

newInfo : WSInfo

oID := oid

info : WSInfo

oID := oid

stores

<<create>>

<<create>>

workspaceManagerinfo : WSInfo

oID == oid

stores

changed true

{!replace}

oID : oidcurrentVID := (String) oidVidMap.get(oid)

It

observes notifies

[success]

[failure]

processUpdateResultCleanUpDeletedItems()newItem

Fig. 3. Story diagram that contains a high number of patterns

Listing 1. Manual implementation of the method shown in Figure 3

1 public boolean processUpdateResult(PMIList pmiList, Map<String, String>oidVidMap, boolean replace) {

2 Iterator oidIterator = pmiList.getOIDList().iterator();3 while (oidIterator.hasNext()) {4 String oid = (String) oidIterator.next();5 IProductModelItem newItem = pmiList.select(oid);6 WSInfo info = getWorkspaceManager().getWSInfos().get(oid);7 if (info != null) {8 IProductModelItem oldItem = info.getItem();9 if (!replace && info.isChanged()) {

10 WSInfo newInfo = new WSInfo(oid, (String) oidVidMap.get(oid));11 newInfo.setItem(newItem);12 newInfo.setObservable(newItem);13 notifyMergeNecessary(info, newInfo);14 }15 if (replace && info.isChanged())16 info.setChanged(false);17 if (!info.isChanged() && oldItem != null) {18 info.setItem(null);19 info.setObservable(null);20 }21 } else {22 info = new WSInfo(oid);23 getWorkspaceManager().addWSInfo(info);24 }25 if (!info.isChanged())26 processUpdateResultInsertNewItem(oldItem, newItem, info, oidVidMap);27 }28 processUpdateResultCleanUpDeletedItems();29 }


AbstractRuntimeConfigurableServerFactory::assignFactories(...) : Void

AbstractRepositoryModule versionedItemFactory = null;if (configuration.contains(VersionEnum.VERSIONFIRST) || ...) {

versionedItemFactory = new ComplexRepositoryModule();if (configuration.contains(BlockEnum.ITEM)) {

System.err.println(...);configuration remove(BlockEnum ITEM);configuration.remove(BlockEnum.ITEM);configuration.add(BlockEnum.SERVER);

}} else if (configuration.contains(...) || ...) {

...} else

versionedItemFactory = new AtomicRepositoryModule();HistoryModule historyFactory = null;HistoryModule historyFactory null;AbstractIDCreatorModule vIDFactory = null;

...

Fig. 4. Story diagram that represents a highly procedural example

MOD2SCMWorkspaceManager::save() : Void

synchronized(getItemManager()) {

<<create>>wsManagerFile : File := new File(...)

try {

<<create>>

try {

outputStream := new ObjectOutputStream(...)<<create>>

1 : writeObject(this) 2 : close()

this number OfSavingTries = 0;this.number OfSavingTries = 0;} catch (Exception e) {

...} finally {

...}

Fig. 5. Story diagram that illustrates the JSP syndrome

Figure 5 is a good example how hand-written code fragments are placed around storypatterns (observation (8)). The story diagram is used to save the state of the workspacemanager. To ensure that the execution is synchronized, the body is embedded into asynchronization statement. Furthermore, if the write operation fails, the save methodis re-executed (until the maximum number of tries is exceeded). Again, this methodimplementation is highly procedural and story driven modeling does not seem to bethe most appropriate formalism for this task. The story diagram is written in a JSP-likestyle, including statement activities containing fragments of Java text which do not evencorrespond to complete syntactical units.

Figure 6 shows a story diagram that is used to calculate differences on text files basedupon the well-known Longest Common Subsequence (LCS) algorithm. Figure 6 depicts


Diff:calculateDiffInternal() : Void

mtcontains[i]

aArrow : ArrowstartOld = aArrow.getEndpositionRow();endOld = aArrow.getEndpositionRow();startNew = aArrow.getEndpositionColumn();endNew = aArrow.getEndpositionColumn();

this

old oldList : ElementList

newList : ElementListnew

hashas

endNew aArrow.getEndpositionColumn();

while (!(aArrow instanceof DiagonalArrow &&i < mt.sizeOfArrow()) {

[i < mt.sizeOfArrow()]

[else]

C : Matrix mt : MatrixTracehas

int i = 0;int startOld = 0;int endOld = 0;i t t tN 0

while (aArrow instanceof VerticalArrow &&i < mt.sizeOfArrow()) {

endOld++; i++;if (i < mt.sizeOfArrow())

aArrow = mt.getFromArrow(i);

this

aAdd : DBAdd

consists of {last}

int startNew = 0;int endNew = 0;

g ( );}...

}<<create>>

endingLineNew := endNewbeginningLineOld := startOldbeginningLineNew := startNew + 1lengthAdd := endNew - startNewthis

this

consists of {last}<<create>>

1 : setDataBoxContent(newList)

aDelete : DBDelete

endingLineOld := endOldb i i Li Old t tOld 1

consists of {last}aChange : DBChange

endingLineOld := endOldendingLineNew := endNewbeginningLineOld := startOld + 1b i i Li N N 1 [else]

<<create>>

beginningLineOld := startOld + 1beinningLineNew := startNewlengthDel := endOld - startOld

1 : setDataBoxContent(oldList)

beginningLineNew := startNew + 1lengthDel := endOld – startOldlengthAdd := endNew - startNew

1 : setDataBoxContent(oldList newList)

[else]

[startNew != endNew]

(oldList, newList)

[else][else][startOld != endOld &&startNew != endNew]

[startOld != endOld]

Fig. 6. Story diagram for the LCS algorithm which may be coded easily in Java

the part of the algorithm where the LCS has been determined and the difference (rep-resented by add, change, or delete blocks) is being computed. The original algorithmperforms best when working with arrays that contain the indices of the longest com-mon subsequences in two text fragments. Nevertheless, the student who implementedthis part of the MOD2-SCM system tried to raise the algorithm to the object-orientedlevel and to make use of Fujaba to be able to easily integrate it into the already existingMOD2-SCM domain model. Working with indices was still necessary, though objectsfor the matrices and the trace within the matrix representing the longest common sub-sequence have been created. The result is a mixture of statement activities and storypatterns, which makes it hard to keep track of the actual control flow within the shownstory diagram (unstructured control flow, observation (10)).

5 Discussion

5.1 Results from the MOD2-SCM Project

In this paper, we examined the added value of programmed graph transformations withthe help of a case study from software configuration management. Based on this casestudy, may we convince hard-core Java programmers to program with graph transfor-mations instead? The examination of the story diagrams developed in the MOD2-SCMproject suggests the answer “no”. Altogether, story diagrams are written in a stronglyprocedural style at a level of abstraction which hardly goes beyond Java and is evenpartially located below Java or other current programming languages.

The authors of the MOD2-SCM model made extensive use of story patterns. How-ever, our quantitative analysis showed that story patterns are typically composed of avery small number of objects and links. Furthermore, advanced features such as neg-ative objects/links, multi-objects, and paths are only very rarely used. Altogether, thepotential of story patterns - the declarative specification of complex graph transforma-tions - is only exploited to a severely limited extent.


As far as story patterns are concerned, the graphical notation is intuitive and en-hances readability, in particular in the case of more complex graph transformations.With respect to control flow, however, the graphical notation may have a negative im-pact on readability. Essentially, story diagrams are conventional flow charts, which arewell known for the “goto considered harmful” syndrome. Control structures knownfrom structured programming are missing. In this respect, story diagrams fall behindconventional programming languages such as Java.

5.2 Generalization of Results

Let us summarize the most important general observations derived from the case study:

1. The behavioral model is highly procedural.2. The expressive power of graph transformation rules (story patterns) is hardly ex-

ploited.

It might be argued that these findings are specific to the case study since providing aproduct line requires the fine-grained decomposition of the overall domain model intoa set of rather small reusable components. However, this style of development is notonly applied to product lines, but it should anyhow be applied in any large developmentproject. To check this assumption, we ran our metrics tool on Fujaba’s CodeGen2 model(the bootstrapped Fujaba code generator). The results were very similar to the datacollected from the MOD2-SCM project (see again Tables 1 and 2).

It could also be argued that the authors of the story diagrams lacked the expertiseto fully exploit the features of the modeling language. Although some minor parts ofthe MOD2-SCM project were developed by students who did not have much experi-ence in programming with graph transformations, the biggest part of the system wasimplemented by experienced Fujaba modelers. Furthermore, the analysis of CodeGen2,which was developed by the authors of Fujaba themselves, yielded similar results.

Finally, it might be argued that the procedural style of the Fujaba models is dueto the modeling language. However, this argument does not explain the fact that ad-vanced features of story patterns such as paths, constraints, negative objects and links,and multi-objects were only rarely used. Nevertheless, we decided to examine a largespecification written in another language to check this argument. The specification wasdeveloped in a Ph.D. thesis in the ECARES project, which was concerned with reverseengineering and reengineering of telecommunication systems [5]. The specification waswritten in PROGRES [7], a language for programming with graph transformations pro-viding many advanced features (multiple inheritance, derived attributes and relations,object-orientation, genericity, graph transformation rules with similar features as in Fu-jaba, high-level control structures, backtracking, and atomic transactions).

The data displayed in Tables 3 and 4 were collected from the complete specification,as developed in the Ph.D. thesis by Marburger. By and large, the results are consistentwith the metrics data collected from the Fujaba models:

1. The ECARES specification has a strongly procedural flavor. This is indicated bythe ratio of the number of graph tests and graph transformation rules related to thenumber of programmed graph queries and transactions: There are twice as manyprogrammed methods as elementary graph tests and transformation rules.


Table 3. Type and number of language elements in ECARES

Model element Total number Model element Total number

Packages 21 Optional nodes 9

Node classes or types 190 Set nodes 40

Generalizations 193 Edges 374

Intrinsic attributes 87 Negative nodes and edges 13

Derived attributes 9 Positive and negative paths 92

M t tt ib t 8 T ti ( d t th d ) 299Meta attributes 8 Transactions (update methods) 299

Edge types 21 Queries 8

Textual path declarations 32 Assignments 659Textual path declarations 32 Assignments 659

Graphical path declarations 40 Calls 684

Graph tests 55 Sequences 335Graph tests 55 Sequences 335

Graph transformation rules 92 Conditional statements 270

Mandatory nodes 559 Loops 83y p

Table 4. Significant ratios of language elements in ECARES

Metric Value Metric Value

(Cl )/ k 9 05 (N i d d )/ hi l d fi i i 0 07(Classes + types)/package 9.05 (Negative nodes + edges)/graphical definitions 0.07

Attributes/(classes + types) 0.55 Set nodes/graphical definitions 0.21

(Graph tests + graph transformation rules + ( h )/ h l d f(Graph tests + graph transformation rules +queries + transactions)/(classes + types) 2.39 (Positive + negative paths)/graphical definitions 0.49

(Graph tests + graph transformation rules)/(queries + transactions) 0.48 (Assignments + calls)/(queries + transactions) 4.37

Nodes/graphical definitions 2.99 Control structures/(queries + transactions) 2.24

Edges/graphical definitions 2.00

2. Graphical definitions (graph tests, graph transformation rules, and graphical pathdeclarations) are rather small. On average, a graphical definition contains about 3nodes and 2 edges. These numbers are a bit larger than in MOD2-SCM and Code-Gen2. However, it has to be taken into account that relationships are represented inECARES always as nodes and adjacent edges. Thus, a graph transformation rulefor inserting a relationship requires at least 3 nodes and 2 edges. In the publicationson ECARES, considerably more complex rules were selected for presentation, butthese rules are not representative.

3. The data differ with respect to the utilization of advanced features in graphicaldefinitions. In particular, paths are used in about 50% of all graphical definitions.Eliminating paths would result in larger graphical definitions. Thus, altogether thegraphical definitions are slightly more complex than in the studied Fujaba models.

6 Conclusion

We investigated the added value of programmed graph transformations with the help ofa large case study from software configuration management. Our analysis showed thatthe model developed in the MOD2-SCM project exhibits a strongly procedural flavor.Furthermore, graph transformation rules are heavily used, but consist typically of very


small and simple patterns. Finally, we have reinforced our findings with metrics datacollected from other projects utilizing programmed graph transformations.

Examining a few large models does not suffice to evaluate the added value of pro-grammed graph transformations. However, our analysis indicates that the level of ab-straction is not raised as significantly as expected in comparison to conventional pro-gramming. In the models we studied, the modeling problem seems to demand for aprocedural solution. Furthermore, modularization of a large model may result in a fine-grained decomposition such that each method only has to deal with small patterns andhas to provide a small piece of functionality. Further case studies are required to checkwhether these effects also apply to other applications.

References

1. Buchmann, T., Dotor, A.: Towards a model-driven product line for SCM systems. In: McGre-gor, J.D., Muthig, D. (eds.) Proc. of the 13th Int. Software Product Line Conference, vol. 2,pp. 174–181. SEI (2009)

2. Buchmann, T., Dotor, A., Klinke, M.: Supporting modeling in the large in Fujaba. In: vanGorp, P. (ed.) Proc. of the 7th International Fujaba Days, pp. 59–63 (2009)

3. Dotor, A.: Entwurf und Modellierung einer Produktlinie von Software-Konfigurations-Management-Systemen. Ph.D. thesis, University of Bayreuth (2011)

4. Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S.: Feature-oriented domainanalysis (FODA) feasibility study. Tech. rep., Carnegie-Mellon University Software Engineer-ing Institute (1990)

5. Marburger, A.: Reverse Engineering of Complex Legacy Telecommunication Systems.Berichte aus der Informatik. Shaker-Verlag (2005)

6. OMG: OMG Unified Modeling Language (OMG UML), Superstructure V2.2 (version 2.2)(February 2009)

7. Schürr, A., Winter, A., Zündorf, A.: The PROGRES Approach: Language and Environment.In: Handbook of Graph Grammars and Computing by Graph Transformation, vol. 2: Applica-tions, Languages, and Tools, pp. 487–550. World Scientific (1999)

8. Zündorf, A.: Rigorous object oriented software development. Tech. rep., University of Pader-born, Germany (2001)

A Case Study Based Comparison

of ATL and SDM

Sven Patzina and Lars Patzina

Center for Advanced Security Research Darmstadt (CASED), Germany{sven.patzina,lars.patzina}@cased.de

Abstract. In model driven engineering (MDE) model-to-model trans-formations play an important role. Nowadays, many model transforma-tion languages for different purposes andwith different formal foundationshave emerged. In this paper, we present a case study that compares the At-las Transformation Language (ATL) with Story Driven Modeling (SDM)by focusing on a complex transformation in the security domain. Addi-tionally, we highlight the differences and shortcomings revealed by thiscase study and propose concepts that are missing in both languages.

Keywords: Atlas Transformation Language, Story Driven Modeling,Live Sequence Charts, Monitor Petri nets, transformation.

1 Introduction

Model-driven engineering (MDE) demands model-to-model transformations be-tween models on different abstraction levels. Based on this idea, a model-baseddevelopment process for security monitors [15] is developed that allows for theabstract specification and automated generation of correct security monitors insoftware (C, Java) and hardware (VHDL, Verilog). Specifications are modeled asuse and misuse cases with extended Live Sequence Charts (LSCs). Due to the ex-pressiveness of LSCs, the process foresees a more explicit intermediate language– the Monitor Petri nets (MPNs), a Petri net dialect with special start and endplaces and deterministic execution semantics. This more explicit representationwith a less complex syntax is easier to process than the LSCs itself.

In this context, a rule-based model-to-model transformation language is in-tended for the complex step from LSCs to MPNs, because a rule-based approachseems to be less error-prone compared to a manual implementation of the pat-tern matching process for each transformation in a general-purpose program-ming language. Nowadays, various transformation languages have emerged witha different purpose, feature set, and formal foundation. On one side, there arelanguages that are based on graph grammar theory such as SDM [6] and on theother side, languages such as ATL [9], whose semantics has been formalized byusing e.g., abstract state machines [5] and rewriting logics [18]. In contrast toexisting comparisons that use classical examples [4] or more complex examplesby focusing on special properties such as inheritance [21], this case study differsin the application domain.


A Case Study Based Comparison of ATL and SDM 211

In this paper, we show the differences, advantages and disadvantages of theAtlas Transformation Language (ATL) in version 3.1 and Story Driven Modeling(SDM) on an example of a real-world transformation. Our main contributionsare the application of two transformation languages to a complex, real-worldexample in the security domain and specific proposals for extending the conceptsof the transformation languages.

In the following, Sec. 2 introduces the transformation scenario. Then Sec. 3presents the requirements and analyses appropriate languages for our purpose– ATL and SDM. In Sec. 4, selected rules of the transformation in ATL andSDM that show concepts and differences are compared, and the evaluation isdescribed. The result of the comparison and suggestions for additional featuresfor the two transformation languages are shown in Sec. 5. Section 6 concludesthe paper.

2 Running Example

In this section, a Car-to-Infrastucture scenario, where a car communicates witha tollbridge, will be presented and used in the remainder of this paper. The ex-ample is based on metamodels that are reduced versions of those used in the casestudy, depicted as Ecore/MOF diagrams in Figure 1a) and b). Figure 1c) showsa communication protocol (use case) in concrete LSC syntax and Figure 1d) thecorresponding MPN representation.

LSCs are an extension of Message Sequence Charts that in addition offer adistinction between hot and cold elements. Thereby, hot elements are mandatoryand have to occur and cold elements are optional. Additionally, LSCs can havetwo forms, a universal LSC with a prechart (precondition) before the mainchartor an existential LSC without a precondition.

The LSC in Figure 1c) shows an existential LSC that models the exchangeof asynchronous messages between LSC objects in a mainchart. When the carapproaches the tollbridge, it sends a connect() message to the tollbridge thatis represented as hot message. The tollbridge acknowledges this message withan ack(). After receiving this message, the car has to send some informationdata_a(). Then the car is allowed to send additional information data_b(),modeled as cold message. The communication has to be terminated by the carby sending a disconnect() message.

The metamodel of the LSC diagrams is depicted in Fig. 1a), where LSC sand the derived ExistentialLSC s are contained in the root class LSCDocument.Furthermore, ExistentialLSC s contain LSCObjects and a Mainchart. A Messagestarts and ends on a Location that is contained in the related LSCObject as anordered set.

Similar to LSC s, MPN s have an MPNDocument as root class, depicted inFigure 1b). The MPN, derived from the use case LSC, is represented in Fig-ure 1d). This MPN is a more operational description of the behavior expressedby the LSC. MPN s are composed of different kinds of places (depicted as circles),transitions (realized as black bars), and arcs that connect places and transitions.

212 S. Patzina and L. Patzina

MPN

initial place

standard place

end place

transition

arc

LSC

hot message

cold message

LSC object

mainchart

b)a)

c) d)

Ecore Diagram lscmetamodel

LSCDocument

+ name: EString

LSC

+ isMisuseCase: EBoolean

+ name: EString

ExistentialLSC

Mainchart

LSCObject

+ name: EString

Location

+ temperature: Temperature

Message

+ condition: EString

+ content: EString

+ temperature: Temperature

+ type: MessageType

Temperature

«enum»

+ COLD

+ HOT

MessageType

«enum»

+ ASYNC

+ SYNC

+chart0..1

LSCContainsMainchart+lsc 0..1

+lsc

0..1

LSCContainsObjects

+objects *

+locations *

ObjectContainsLocations

+object 0..1

+lscs *

DocumentContainsLSCs

+document 1

+containingLocations0..*

ChartHasLocations

+chart 0..1

+outMsg 1

MessageHasStartLocation

+startLoc 1

+incMsg 1

+endLoc 1

+message0..*

ChartContainsMessage

+chart 0..1

MessageHasEndLocation

Ecore Diagram mpnmetamodel

MPNDocument

+ name: EString

MPN

+ isMisuseCase: EBoolean

+ name: EString

Place

+ name: EString

Transition

+ code: EString

+ condition: EString

+ event: EString

PlaceArc

TransitionArc

StandardPlaceInitialPlace

EndPlace

+document 1

MPNDocContainsMPNs

+mpns 0..*

+mpn 0..1

MPNContainsPlaces

+places 0..*

+place 1

PlaceContainsPlaceArcs

+placearcs 0..*

+place

1

PlaceHasTransArcs

+transitionarcs

0..*

+mpn 1 MPNContainsTransitions+transitions 0..*

+transition 1 TransitionContainsTransArcs+transitionarcs 0..*

+transition1

TransitionHasPlaceArcs +placearcs

0..*

car :Vehicle

tollbridge

:RSU

connect()

ack()

data_a()

data_b()

disconnect()

(T2)

(T3)

(T3)

(T4)

Tra

nsfo

rma

tions

«MPNInitial»

car

«MPNInitial»

tollbridge

s.connect()

r.connect()

s.ack()

r.ack()

s.data_a

r.data_a()s.data_b()

r.data_b()

s.disconnect()

r.disconnect()

stop

s.disconnect()

r.disconnect()

Fig. 1. Metamodels and models of the LSC-to-MPN example


The transformation from LSCs to MPNs basically consists of four transfor-mation steps, highlighted in grey in the concrete example. (T1) It starts withthe creation of an MPN for each LSC. (T2) Each LSC object is represented asan initial place annotated with the name of the object. (T3) A hot asynchronousmessage such as the connect()message is split in one transition for the sendingand one for the receiving event and three standard places. These are connectedwith arcs where one place is on the sender side, one is on the receiver side, andone secures the order of sending and receiving of the message. This pattern isalso used for cold messages with additional bypass-transitions that realize theoptional nature of cold messages. (T4) The pattern is finalized by an end placewhere all possible paths through the MPN are synchronized by transitions withthe event “stop”.

3 Related Work

In the last years, publications about comparisons between different transfor-mation languages evolved. On the one side, there is the Transformation ToolContest1 event series, where solutions for special transformation problems aresubmitted and compared. As [2] stated, this contest can be used as source forinsights of the strong and weak points of transformation tools, but has no clearfocus on achieving really comparable results. On the other side, publicationscope with small classical examples such as UML2RDBMS [4], concentrate onlyon graph-based transformation languages [17] or focus on a small subset of prop-erties such as inheritance [21]. The transformation from extended LSCs to thecorresponding MPN representation is in contrast to the afore mentioned com-parisons based on a complex, real-world example located in the security domain.

Based on the transformation steps (T1 to T4 ) that are derived from the ex-ample in Section 2 the following requirements can be formulated:

R1) 1-to-1 (Model). For each LSC diagram, a single MPN should be gener-ated. Therefore, for each source model one target model is created. (T1)

R2) m-to-n (Element). One or more elements in the source model have tobe mapped to one or more elements in the target model. (T3)

R3) Traceability Links. For processing optional elements, traceability linksare needed to be able to add bypass-transitions in the target model. (T3)

R4) Attributes. The language must be able to handle attributes of modelelements. It has to check and generate attributes in the target model. (T2)

R5) In-place. For optimizations of the target model, some kind of in-placetransformation on the target model is required. (T4)

R6) Deletion. For post-processing, it is necessary to delete elements from thetarget model to remove redundant places and unnecessary transitions. (T4)

R7) Recursive Rules. For the synchronization at the end of an LSC, with anunknown number of places and LSC objects during specification, recursiveoperations on model elements are needed. (T4)

1 http://planet-research20.org/ttc2011/

http://planet-research20.org/ttc2011/


Table 1. Requirements for the LSC-to-MPN transformation

Req. ATL [9] ETL [11] QVTo [14] PROGRES [16] SDM [6] TGG [10] VIATRA2 [20]

R1) � � � �1 �1 � �R2) � –2 � � � � �R3) � o3 � o3 o3 � o3

R4) � � � � � – �R5) o4 � o4 � � – �R6) o5 �6 � � � – �R7) o7 � � �8 �8 – �R8) � � � � � o9 �R9) � � � – � � ��fulfilled; o partly fulfilled; - not fulfilled; 1in-place; 2only 1-to-n; 3manual; 4refining mode;5new transformation; 6with EOL; 7as helper; 8control flow and path expressions; 9bidirectional

R8) Unidirectional. Some elements of the LSC have no bijective mapping.A fixed loop of n iterations is, e.g., unwound to n representations of itscontent. (T1)

R9) Tool Support. For the realization of the development process, a reliableimplementation of the transformation language is needed.

Based on these requirements, Table 1 compares state-of-the-art rule-based modeltransformation languages. While PROGRES, SDM, TGG, and VIATRA2 arebased on graph transformation (GT) principles, ATL, ETL, and OperationalQVT (QVTo) are not formalized. First approaches for ATL are made usingabstract state machines [5] and rewriting logics [18]. The introduced GT lan-guages, excluding TGGs, are hybrid and support the modeling of control flow.In contrast to all other approaches, TGGs are fully declarative and bidirectionaltransformations have to be specified as mappings of source and target elementssimultaneously. This hampers the specification of the rules, because no bijectivemapping as stated in R8 exists, and R7 is not supported. So TGG does not fitto the requirements.

There are two groups, on one hand ATL, ETL, and QVTo and on the otherhand PROGRES, SDM, and VIATRA2. Because many comparisons betweenlanguages within one of the groups exist, e.g., [8,17], one language from eachgroup is chosen.

ATL, the commonly used model transformation language in the Eclipse com-munity and SDM that is used in the meta-CASE tool MOFLON [1] will becompared because of their differences. In SDM the rules, embedded in activitiesof an activity diagram, are scheduled by an explicitly modeled control flow. Con-trary to SDM, the rules of an ATL 3.1 transformation are conditioned by OCLexpressions and functionality can be delegated to helper functions. Using theseconcepts the execution sequence is derived from implicit relations between therules.


rule LSCDocument2MPNDocument {from

lscDocument: LSCMM!LSCDocumentto

mpnDocument: MPNMM!MPNDocument(name <- lscDocument.name

)}

rule LSC2MPN{from

lsc: LSCMM!LSCto

mpn: MPNMM!MPN(isMisuseCase <- lsc.isMisuseCase,name <- lsc.name,document <- lsc.document

)}

(T1) LSCDocument2MPNDocument

Transformator::transform (lscDocument:

LSCDocument): MPNDocument

(T1) LSC2MPN

<<create>>

mpn: MPN

isMisuseCase:=lsc.isMisuseCase

name:=lsc.name

(T3) MatchMainchartOfExistentialLSC

elsc:= (ExistentialLSC) lsc

chart: Mainchart

mpnsynchronizeObjectsFinal(mpn, lsc);

mpnDocument

(T2) LSCObjects2InitialPlaces

addInitialPlaces(mpn, lsc);

addElements(mpn, chart, chart);

<<create>>

mpnDocument: MPNDocument

name:=lscDocument.name

lscDocument lsc: LSC

[end]

+lscs +document

+document

<<create>>

+mpns

+chart

+lsc

[failure]

[success]

[each time]

ATL

SDM

(T3) Messages2MPNSubnet(T4) Messages2MPNSubnet

Fig. 2. Initial rules of the transformation (T1)

4 Comparison of the Transformations

In this section, rules of the LSC-to-MPN transformation are presented that showcommonalities and differences of ATL and SDM. Thereby, the requirements de-rived above that are not satisfied by one or both languages (R3, R5, R6 and R7)are examined and additional missing features are suggested. After that, the im-plementation of the transformations is evaluated.

4.1 Transformations

The SDM part of Figure 2 maps the basic steps of the transformation, derived inSection 2 to the activities of the SDM: (T1) LSCDocument to MPNDocumentand LSC to MPN, (T2) LSCObjects to InitialPlaces, (T3) Messages to an MPNsubnet, and (T4) the synchronization to EndPlaces in MPN.(T1) The first transformation rules in Figure 2 translate the LSCDocumentwith its LSC s to an MPNDocument with corresponding MPN s. The ATL rule,LSCDocument2MPNDocument, corresponds to the first activity in the SDM. Inthe SDM rule, lscDocument is already bound as a parameter and an MPNDoc-ument is created in the first activity. Contrary to the SDM, the ATL rule needsno already matched (bound) objects for the navigation. So an LSCDocument ismatched in the from part (left side) and an MPNDocument is created in the topart (right side) of the rule. The second rule LSC2MPN is very similar in bothlanguages. In the SDM, the activity around the pattern is a foreach-activity thatuses the bound lscDocument to find all LSC s and adds for each lsc an MPNwith the same attributes to the mpnDocument.

These first transformation rules already reveal the main difference of the twolanguages. While SDM explicitly relies on a control flow between the declarative


rule LSCObject2InitialPlace{

fromlscObject: LSCMM!LSCObject

toinitialPlace: MPNMM!InitalPlace(

name <- lscObject.name,mpn <- thisModule.resolveTemp(

lscObject.lsc, 'mpn'))

}

ATL SDM

LSCObject2InitialPlace

Transformator::addInitialPlaces (mpn: MPN,

lsc: LSC): void

lsc lscObject: LSCObject

<<create>>

initialPlace: InitialPlace

name:=lscObject.name

mpn

<<create>>

link: TraceabilityLinkthis

+link

<<create>>+object

+link<<create>>

+places

+lsc +objects

+mpn

<<create>>

+elements

[end]+transformator

<<create>>

+link

Fig. 3. Creation of initial places of MPN (T2)

patterns, ATL should be used as long as possible in a declarative way [9]. Besidethe implementation of SDM in MOFLON, there exists a backward compatibleextension that allows for implicit rule scheduling [13].(T2) For every matched LSC in the activity LSC2MPN, the transformationsteps are executed. The next activity calls the rule depicted in Figure 3 thattranslates all LSCObjects to InitialPlaces of the MPN. The ATL rule matchesevery LSCObject specified in the from part of the rule, which corresponds to theunbound object lscObject in the SDM. The to part of the ATL rule correspondsto the pattern at the bottom of the SDM activity.

Here, another difference between ATL and SDM emerges. In ATL each appli-cation of a rule automatically produces traceability links between the matchedsource and the created target elements. Such a mechanism does not exist instandard SDM. Therefore, an additional metamodel containing the transforma-tion rules as operations and constructs for the management of traceability links(TraceabilityLink) has to be explicitly modeled as shown in [7]. Traceability linksin ATL have to be used for adding a reference to the already created MPN. Thisis done by the predefined helper resolveTemp and name matching. As parame-ters the elements of the source model and the name of the element in the targetmodel, defined in the rule that has matched the source elements, are passed.(T3) When defining more complex rules such as the transformation of asyn-chronous messages, two different approaches have to be used. In SDM, enabledby the explicit control flow modeling, the transformation can be defined in onerule, whereas, in ATL three rules have to be specified.

For the SDM in Figure 4, the manually added traceability links are used toidentify all places in the MPN that have not been synchronized via a hot messagein the LSC. In the activity CreatePlacesForAsyncMessage three StandardPlacesfor the LSC message are created. The following foreach-activity CreatePlaces-ForStartLocation generates a transition with corresponding arcs for every placethat has a link to the source of the message (LSCObject). This includes thebypass-transitions for cold messages. The statement -activity TraceabilityLink-ForStartLocation calls an SDM method that manages the traceability links. Thesecond part of the SDM, which is collapsed, performs the similar transformationfor the target of the message.


SDM

ATL

Transformator::addAsyncMessage (mpn: MPN, startObject: LSCObject, endObject: LSCObject, message: Message): void

CreatePlacesForAsyncMessage

<<create>>sPA: StandardPlace mpn

<<create>>sPS: StandardPlace

<<create>>sPB: StandardPlace

ConnectPlacesForStartLocation

this startObjectlink: TraceabilityLink

place: Place<<create>>

pAA: PlaceArc

mpn

<<create>>

tA: Transition

event:="s."+message.getContent()

<<create>>tAS: TransitionArc

sPS

<<create>>tAA: TransitionArc

sPA

TraceabilityLinksForStartLocation

ConnectLocationsForEndLocations

TracebilityLinksForEndLocation

addLocationPlace(message.getStartLocation(), link, place, sPA);

addLocationPlace(message.getEndLocation(), link, place, sPB);

+transition

<<create>>+placearcs

[each time]

[end]

[end]

[each time]

+transition

<<create>>

+transitionarcs

+transition

<<create>>

+transitionarcs

+mpn

<<create>>

+places

+place

<<create>>

+transitionarcs

+place

<<create>>

+placearcs

+mpn

<<create>>

+transitions

+mpn<<create>>

+places

+mpn

<<create>>+places

+link

+places

+transformator +link +link +object

+place

<<create>>

+transitionarcs

rule AsyncMPNPattern{ from lscAM : LSCMM!Message(lscAM.isMessageAsync) to sPA : MPNMM!StandardPlace( mpn <- thisModule.resolveTemp(lscAM.endLocation.object.lsc, 'mpn') ), sPS : MPNMM!StandardPlace( placeArcs <- tAS, mpn <- thisModule.resolveTemp(lscAM.endLocation.object.lsc, 'mpn') ), sPB : MPNMM!StandardPlace( placeArcs <- tAB, mpn <- thisModule.resolveTemp(lscAM.endLocation.object.lsc, 'mpn') ), tA : MPNMM!Transition( transitionArcs <- tAA, transitionArcs <- tAS,

event <- 's.'.concat(lscAM.content), mpn <- thisModule.resolveTemp(lscAM.endLocation.object.lsc, 'mpn') ), tAA : MPNMM!TransitionArc( place <- sPA ), tAS : MPNMM!TransitionArc( place <- sPS ), pAA : MPNMM!PlaceArc( transition <- tA, place <- thisModule.getPlaceOfPrevMsgSender(lscAM) ), ... } rule bypassTransition{ from firstLoc : LSCMM!Location, secondLoc : LSCMM!Location(firstLoc.isBypassCombination(secondLoc)) to pA : MPNMM!PlaceArc( transition <- t, place <- secondLoc.getPlaceForLocAndInst ), t : MPNMM!Transition( event <- secondLoc.getEventName, transitionArcs <- tA, mpn <- thisModule.resolveTemp(firstLoc.object.lsc, 'mpn') ), tA : MPNMM!TransitionArc( place <- thisModule.getPlaceForLocAndInst(secondLoc) )}rule bypassTransitionWithFollowingAsyncSend extends bypassTransition{ from firstLoc : LSCMM!Location, secondLoc : LSCMM!Location(firstLoc.isBypassCombination(secondLoc) and secondLoc.isAsyncSendingLocation) to tAS : MPNMM!TransitionArc( transition <- t, place <- thisModule.resolveTemp(secondLoc.outgoingMessage, 'sPS') ), pAS : MPNMM!PlaceArc ( place <- thisModule.resolveTemp(secondLoc.outgoingMessage, 'sPS'), transition <- thisModule.resolveTemp( Tuple{fL = firstLoc.getOppositeLocation, sL = secondLoc.getOppositeLocation}, 't') ) }

Fig. 4. SDM and ATL rules for asynchronous messages (T3)


stop stop stop …

… …

… X X

PO1 PO2 POn

Fig. 5. Synchronization of open places at the end of an MPN (T4)

In ATL the transformation, depicted in Figure 4, is split into three rules thatmatch different source elements. Where AsyncMPNPattern matches all messagesin the LSC model and translates the messages, the two bypassTransition rulescreate the additional transitions for cold messages. For that, the messages haveto be matched again. This can be done by splitting the transformation in twosequential transformations, losing the traceability links of the former steps, or asdone here, by matching other source elements (combination of locations). Theto parts of the ATL rules and their helpers extensively use traceability links.(T4) The LSC presented in Section 2 ends with a hot message, so that only theplaces belonging to the last message have to be synchronized via a transitionwith stop event. For handling one or more cold messages at the end of a chart,all combinations of places that have not been synchronized from different LSCobjects have to be connected to an own transition. As shown in Figure 5, theCartesian product (po1, po2, . . .) ∈ PO1 × PO2 × . . . has to be derived, wherePOn contains all unsynchronized places of the n-th LSCObject.

Such a pattern with two variable dimensions – the number of LSCObjectsand the number of Places for each object – cannot be described in a declarativemanner in ATL and SDM. Therefore, a recursive traversal is needed that canonly be realized imperatively. In SDM, this can be handled locally in the controlflow by calling rules recursively, whereas, in ATL this has to be implementedfully imperatively in global helpers.

4.2 Evaluation of the Transformations

To validate the semantical equivalence of the two transformations, both ap-proaches have been fed with the same set of input models, and the output mod-els have been compared manually with each other. The input models with up tofive messages have been chosen to cover different sequences of messages basedon the temperature, the type, and the direction between the two LSC objects.Caused by the manual review of the output models, these input models are ascompact as possible to realize all combinations with respect to the specificationsof the transformations.

To evaluate the equivalence for more complex models, an “automatic” compar-ison2 of the output MPNs is needed. Therefore, the part of the SDMtransformation that is presented in this paper has been transferred to the eMoflon

2 Test suite provided at: http://www.moflon.org/emoflon

http://www.moflon.org/emoflon


tool, a new version of MOFLON based on EMF. Hereby, EMFCompare allowsfor an automatic comparison of the output models (MPNs).

5 Desirable Features

In this section, proposals for additional features of these two languages are made.These originate from (R) the basic requirements of Section 3, (T) the transfor-mation in Section 4, and (S) additional requirements for the monitor generationprocess scenario.

Implicit Traceability Links (R3, T2, T3). The explicit modeling of traceabil-ity links in SDM alloy the readability of the transformation rules caused by theadditional patterns to create these links. An implicit generation as realized for sub-graph copying [19] would be desirable for the here studied more general case.

In-PlaceTransformation (R5,R6).For post-processing purposes in theMPNtarget model SDM, as an in-place language, is favorable, because recursive dele-tions and modifications can be modeled within the control flow. Using the refiningmode of ATL 3.1 (realized by copy rules) allows a kind of in-place transformation,but this approach fails when post-processing steps have to be repeated iterativelyon the changed model until there is no new match. This is caused by the write-only target model that has to be used as source model in a repeated external callof the transformation. In the implementation of ATL 3.2 an extended support forin-place transformations and explicit deletions has been added, but with the draw-back that some advanced imperative features are not supported.

Patterns of Dynamic Size (R7, T4). In complex transformations some prob-lems occur that are typically resolved in programming languages with a recursiveapproach, which is needed to compute the Cartesian product of an unknown num-ber of sets each containing an unknown number of elements. Figure 5 shows thisusing the example of the synchronization of all places at the end of the transfor-mation, presented in Section 4.1. To eliminate the imperative part for this issue, atemplate concept for patterns is needed that allows the dynamic runtime initial-ization of parts of patterns by a quantity of instances in the model.

Explicit Modeling of Control Flow (T1, T3). When a complex transfor-mation should be described in ATL, every object can only be bound by onerule, which leads to a shortage of unbound elements for other rules, as presentedin Section 4.1 in T3. This forces the developer to design more complex holisticrules or split the complete transformation into independent sequential steps. Bysplitting the transformation, traceability links created in a previous step are notaccessible in the current step.

Reusability of Matched Patterns (T2). In SDM, set patterns can be used tomatch many objects of the same type at once. The results can be passed betweenrules and returned as result but cannot be used for further pattern matching.By extending the set concept and allowing, additionally, the passing of matchedpatterns, the control flows in SDM rules could be reduced.


Deterministic and Correct Result (S). In the presented monitor genera-tion process the correctness of the resulting model has to be ensured. Therefore,properties such as a deterministic generation of target models, as guaranteedby the declarative part of ATL [8], are desirable. As shown in the previous sec-tion, it is often impossible to provide a purely declarative solution for complextransformations. Hence, in both ATL and SDM the developer has to cope withnon-determinism in the modeled transformation. To address this issue, test prac-tices, as suggested in [3], have to be developed for ATL and SDM.

Integration into Software (S). The tools for ATL and SDM provide dif-ferent approaches for the integration of transformations in software products.MOFLON and FUJABA use SDM specifications to generate Java code andATL is translated into byte-code that is interpreted by a special virtual ma-chine (ATL VM). Hence, the SDM code is preferable for seamless integrationin a standalone tool [6]. When developing a tool integrated in Eclipse, bothapproaches are suitable.


In this paper, we have presented a case study about the comparison of thetransformation languages ATL and SDM in the context of a model-based secu-rity monitor development process. We have highlighted shortcomings that haveevolved during the case study and suggested additional concepts to improve themodeling of transformations. Both languages lack some features and should beextended. One major disadvantage of ATL is the missing possibility to explicitlymodel the control flow, and the resulting problem that elements can be boundonly once in a transformation.

A more satisfactory model transformation language for our monitor generationprocess could be based on an SDM-like hybrid language that is extended bystatic type and determinism analysis from PROGRES and Critical Pair Analysisfrom AGG [12]. The language should support recursive patterns as implementedin VIATRA. Additionally, a possibility for implicit traceability links should besupported. Furthermore, an improved parameter handling for passing matchedpatterns and set patterns between part rules is also desirable.

As stated, all these concepts have been proposed for different transformationlanguages, but were never combined in an implementation of a graph transfor-mation language. Therefore, further research has to determine the compatibilityof these extensions, e.g., determinism and recursive patters.

References

1. Amelunxen, C., Konigs, A., Rotschke, T., Schurr, A.: MOFLON: A Standard-Compliant Metamodeling Framework with Graph Transformations. In: Rensink,A., Warmer, J. (eds.) ECMDA-FA 2006. LNCS, vol. 4066, pp. 361–375. Springer,Heidelberg (2006)

2. van Amstel, M., Bosems, S., Kurtev, I., Ferreira Pires, L.: Performance in ModelTransformations: Experiments with ATL and QVT. In: Cabot, J., Visser, E. (eds.)ICMT 2011. LNCS, vol. 6707, pp. 198–212. Springer, Heidelberg (2011)


3. Baudry, B., Dinh-Trong, T., Mottu, J.M., Simmonds, D., France, R., Ghosh, S.,Fleurey, F., Le Traon, Y.: Model transformation testing challenges. In: ECMDAWorkshop on Integration of MDD and MDT. IRB Verlag (2006)

4. Czarnecki, K., Helsen, S.: Feature-based survey of model transformation ap-proaches. IBM Systems Journal 45, 621–645 (2006)

5. Di Ruscio, D., Jouault, F., Kurtev, I., Bezivin, J., Pierantonio, A.: ExtendingAMMA for supporting dynamic semantics specifications of DSLs. Tech. rep. LINA(2006)

6. Fischer, T., Niere, J., Torunski, L., Zundorf, A.: Story Diagrams: A New GraphRewrite Language Based on the Unified Modeling Language and Java. In: Ehrig,H., Engels, G., Kreowski, H.-J., Rozenberg, G. (eds.) TAGT 1998. LNCS, vol. 1764,pp. 296–309. Springer, Heidelberg (2000)

7. Hildebrandt, S., Watzoldt, S., Giese, H.: Executing graph transformations with theMDELab story diagram interpreter. In: Transformation Tool Contest (2011)

8. Jouault, F., Kurtev, I.: Transforming Models with ATL. In: Bruel, J.-M. (ed.)MoDELS 2005. LNCS, vol. 3844, pp. 128–138. Springer, Heidelberg (2006)

9. Jouault, F., Allilaire, F., Bezivin, J., Kurtev, I.: ATL: A model transformationtool. Science of Computer Programming 72(1-2), 31–39 (2008)

10. Klar, F., Rose, S., Schurr, A.: TiE – a tool integration environment. In: Proc. ofthe 5th ECMDA-TW. CTIT Workshop Proc., vol. WP09-09, pp. 39–48 (2009)

11. Kolovos, D.S., Paige, R.F., Polack, F.A.C.: The Epsilon Transformation Language.In: Vallecillo, A., Gray, J., Pierantonio, A. (eds.) ICMT 2008. LNCS, vol. 5063, pp.46–60. Springer, Heidelberg (2008)

12. Mens, T., Taentzer, G., Runge, O.: Detecting structural refactoring conflicts usingcritical pair analysis. In: Proc. of the Workshop on Software Evolution throughTransformations. ENTCS, vol. 127, pp. 113–128. Elsevier (2005)

13. Meyers, B., Van Gorp, P.: Towards a hybrid transformation language: Implicit andexplicit rule scheduling in story diagrams. In: Proc. of the 6th Int. FujabaDays (2008)

14. OMG: MOF 2.0 QVT Spec. Object Management Group (January 2011),http://www.omg.org/spec/QVT/1.1/

15. Patzina, S., Patzina, L., Schurr, A.: Extending LSCs for Behavioral Signature Mod-eling. In: Camenisch, J., Fischer-Hubner, S., Murayama, Y., Portmann, A., Rieder,C. (eds.) SEC 2011. IFIP AICT, vol. 354, pp. 293–304. Springer, Heidelberg (2011)

16. Schurr, A.: Programmed Graph Replacement Systems. In: Handbook of GraphGrammars and Computing by Graph Transformation, vol. 1: Foundations, pp.479–546. World Scientific (1997)

17. Taentzer, G., Ehrig, K., Guerra, E., de Lara, J., Lengyel, L., Levendovszky, T.,Prange, U., Varro, D.: Varro-Gyapay, Sz.: Model transformation by graph trans-formation: A comparative study. In: Proc. of Workshop MTiP (2005)

18. Troya, J., Vallecillo, A.: Towards a Rewriting Logic Semantics for ATL. In: Tratt,L., Gogolla, M. (eds.) ICMT 2010. LNCS, vol. 6142, pp. 230–244. Springer, Hei-delberg (2010)

19. Van Gorp, P., Schippers, H., Janssens, D.: Copying subgraphs within model repos-itories. In: Proc. of the 5th Int. Workshop on Graph Transformation and VisualModeling Techniques. ENTCS, vol. 211, pp. 133–145. Elsevier (2008)

20. Varro, D., Balogh, A.: The model transformation language of the VIATRA2 frame-work. Science of Computer Programming 68(3), 214–234 (2007)

21. Wimmer, M., Kappel, G., Kusel, A., Retschitzegger, W., Schonbock, J., Schwinger,W., Kolovos, D., Paige, R., Lauder, M., Schurr, A., Wagelaar, D.: A Comparisonof Rule Inheritance in Model-to-Model Transformation Languages. In: Cabot, J.,Visser, E. (eds.) ICMT 2011. LNCS, vol. 6707, pp. 31–46. Springer, Heidelberg (2011)

http://www.omg.org/spec/QVT/1.1/

Applying Advanced TGG Concepts for a

Complex Transformation of Sequence DiagramSpecifications to Timed Game Automata�

Joel Greenyer1,�� and Jan Rieke2,��

1 Politecnico di Milano, Piazza Leonardo Da Vinci, 32, 20233 Milano, [email protected]

2 University of Paderborn, Zukunftsmeile 1, 33102 Paderborn, [email protected]

Abstract. Declarative model transformation languages like QVT-R andTGGs are particularly convenient because mappings between modelscan be specified in a rule-based way, describing how patterns in onemodel correspond to patterns in another. The same mapping specificationcan be used for different transformation and synchronization scenarios,which are important in model-based software engineering. However, eventhough these languages already exist for a while, they are not widely usedin practice today. One reason for that is that these languages often donot provide sufficiently rich features to cope with many problems thatoccur in practice. We report on a complex model transformation thatwe have solved by TGGs. We present advanced extensions of the TGGlanguage that we have integrated in our tool, the TGG Interpreter.

Keywords: model transformation, Triple Graph Grammar (TGG), case.

1 Introduction

Declarative model transformation languages like QVT-Relations and TGGs areparticularly convenient because mappings between models can be specified in arule-based way, describing how particular patterns in one model correspond toparticular patterns in another. The same mapping specification can often be in-terpreted for different application scenarios, e.g., for the forward transformationfrom a given source model to a target model or for the backward transformationfrom a given target model to a source model. It can furthermore be used to keepcorresponding models synchronized when changes occur to either one.

� This work was developed in the course of the Collaborative Research Center614, Self-optimizing Concepts and Structures in Mechanical Engineering, Univ. ofPaderborn, and was published on its behalf, funded by the Deutsche Forschungs-gemeinschaft.

�� This work was elaborated mainly while the author was working at the Universityof Paderborn, Germany.

�� Supported by the International Graduate School Dynamic Intelligent Systems.


Applying Advanced TGG Concepts for a Complex Transformation 223

However, even though these languages already exist for a while and a range of(mostly academic) tools have been developed in the past, these languages are notwidely used in practice today. One reason for that is that these languages often donot provide sufficiently rich features to cope with many practical transformationproblems. As a consequence, the formalisms may seem appealing at first, butmany developers faced with real-life problems quickly return to “program” theirtransformations, using an operational language.

In this paper, we report on a complex model transformation that we havesolved by TGGs (Sect. 3). We present advanced extensions of the TGG languagethat we have integrated in our tool, the TGG Interpreter. First, we describethe integration of OCL for describing attribute value constraints and applicationconditions (Sect. 4). We especially support the definition of custom operationsthat can be reused in the TGG rules, making them more readable.

Second, we present how constraints on stereotypes in UML domains can beconveniently specified in the TGG rules (Sect. 5). This extension is crucial be-cause today many specific languages are defined by providing profiles for UML.

Third, we present a rule generalization concept, revising the one presentedearlier by Klar et al. [15] (Sect. 6). By using generalization, we greatly reducedthe number of redundant patterns that needed to be specified for our example.

Last, in our case study we experienced that there are many transformationrules where in some cases we wish to create elements in the target model, butin other cases we wish to reuse elements or whole patterns that were created inthe target model by previous rule applications. We present an advanced conceptfor controlling the reuse of model patterns in the target domain in Sect. 7.

Furthermore, we informally discuss important properties of our TGG exten-sions and the transformation algorithm in Sect. 8, report on related work inSect. 9, and conclude in Sect. 10. But first, we briefly introduce TGGs.

2 Triple Graph Grammars

Triple Graph Grammars (TGGs) [20] allow us to define sets of correspondinggraphs. An element of this set is typically a triple consisting of two independentgraphs that are linked via a third graph, called the correspondence graph. Be-cause of this triple structure, such a graph is also called a triple-graph. Thesedifferent graphs in a triple-graph are typed over different type graphs. TGGrules are non-deleting graph production rules that describe how, based on astart graph or axiom, triple-graphs can be created. Triple-graphs that can becreated by a TGG are called valid triple-graphs.

Transferred to the “modeling world”, TGGs define sets of corresponding mod-els, also called triple-models, where the independent models, called domain mod-els, are instances of different meta-models. The domain models are linked via acorrespondence model, which is an instance of a correspondence meta-model.

TGGs can be interpreted for different application scenarios. In this paper, wefocus on the forward transformation scenario: A model of one domain is given,called the source domain in the following. A TGG can now be operationalized

224 J. Greenyer and J. Rieke

Fig. 1. The interpretation of a TGG rule for the forward transformation

to create a model of the opposite domain, called the target domain, and a cor-respondence model, such that the resulting models form a valid triple-model.

A TGG rule consists of nodes and edges that represent objects and links inthe domain models. Since a TGG rule is a non-deleting graph grammar rule, thenodes and edges appear either on the left-hand side (lhs) and right-hand side(rhs) of the rule, or they appear on the right-hand side only. The former nodesand edges are also called context nodes and context edges, the latter are calledproduced nodes and produced edges. Context nodes are displayed as white boxeswith a black border; produced nodes are displayed as green boxes with a darkgreen border and a “++” label. Context edges are displayed as black arrows;produced edges are displayed as dark green arrows with a “++” label.

Fig. 1 shows an abstract illustration of a TGG rule and how it is applied ina forward transformation scenario. Consider a state during the transformationwhere some rules were already applied and some elements in the source modelwere already translated to some target model elements. After a rule application,when an object in the model is matched by a node or created according to anode, we say that this object is bound to that node. A TGG rule is applied as fol-lows: First, a match of the rule’s context and source domain graph pattern mustbe found in the source model and the already created target and correspondencemodel. In this match, context nodes must be matched only to already bound ob-jects and source produced nodes must only be matched to yet unbound objects.If such a match can be found, target and correspondence model elements canbe created according to the produced target and correspondence pattern of therule. All matched and created objects are bound to the according rule nodes. Asa consequence, a model object can only be bound once to a produced node. Wecall this the bind-only-once semantics of produced nodes. Each model object in avalid triple-model is produced by exactly one produced TGG node of one TGGrule application. Thus, the bind-only-once semantics ensures that the resultingmodels form a valid triple-model according to the TGG.1

In our TGG Interpreter, we not only track which objects are bound towhich nodes. We also track which links are bound to which edges. The set of allnode and edge bindings after a rule application is called a rule binding.

1 Most TGG transformation engines, like Moflon [1], essentially implement the samesemantics. However, these tools mostly do not capture a node/object binding inan explicit data structure: an object is considered bound if there is a link from acorrespondence object pointing to it.


Also constraints on attribute values and application conditions can be formu-lated in a TGG rule, as explained in more detail in Sect. 4. Furthermore, wehave introduced the concept of reusable nodes and reusable edges, displayed ingray with a “##” label. They can be interpreted either as produced nodes andedges or as context nodes and edges [10], as explained in more detail in Sect. 7.

3 Example

The transformation example is a mapping from Modal Sequence Diagram (MSD)specifications to networks of Timed Game Automata (TGA), which is performedin order to find inconsistencies in the specification with Uppaal Tiga [3,9].

MSDs: MSDs are a formalism for specifying interactions among objects thatmay, must, or must not happen, proposed as a formal interpretation of UMLsequence diagrams by Harel and Maoz [13]. In an MSD specification, the inter-action among system and environment objects is specified in sequence diagramswhere messages have a hot or cold temperature. The left of Fig. 2 shows anMSD specification with three MSDs. Hot messages are displayed as solid redarrows; cold messages are displayed as dashed blue arrows. On the top left, acollaboration diagram shows the object system, which here consists only of anenvironment object e:Env and a system object s:S.

In short, the semantics of an MSD specification is as follows: If in a sequence ofinteractions a message is sent in the system that corresponds to the first messagein an MSD, an active copy of that MSD, or active MSD, is created. (We onlyallow a single active copy of an MSD at a time.) Upon the occurrence of furthermessages in the system that correspond to the subsequent messages in the MSD,the active MSD progresses. This progress is captured by the cut, which marksthe occurred messages in the active MSD. If the cut is immediately prior to amessage on its sending and receiving lifeline, this message is enabled. If a hotand executed message is enabled, it means that this message must eventuallyoccur and that no message must occur that corresponds to another messagein the diagram that is not currently enabled. Due to these liveness and safetyrequirements, there can be inconsistencies in an MSD specification. An MSDspecification is inconsistent if there exists a sequence of environment events forwhich the system objects cannot avoid a violation of these requirements.

Timed Game Automata in Uppaal Tiga: Uppaal Tiga is an extension ofthe Uppaal model checker [2]. In Uppaal, a system is modeled as a network ofTimed Automata (TA). Such a TA network consists of parallel automata thateach consist of locations and edges. The edges in the parallel automata can besynchronized via channels. A transition in a TA network is one edge or multiplesynchronized edges firing in the parallel automata. The edges can also have guardconditions and update expressions that assign values to variables. Variables andside-effect-free functions can be declared globally for the whole TGA network orlocally, only visible within one automaton in the network.

In Uppaal Tiga, the Timed Automata are extended to Timed Game Au-tomata (TGA), in which the edges can be either controllable or uncontrollable.


hotViolation

Fig. 2. MSD-to-TGA transformation overview

If only controllable edges participate in a transition, the transition is controllableby the system; if at least one edge is uncontrollable, the transition is controllableby the environment. Uppaal Tiga can check different kinds of properties in aTGA network, for example if some state is reachable by the system even thoughthe environment will always try to keep the system from reaching that state [3].

The MSD-to-TGA Mapping: An MSD specification can be mapped to aTGA network so that Uppaal Tiga can check whether the system is alwaysable to avoid a state that corresponds to a violation of the requirements [8,9]. Ifthat is the case, the MSD specification is consistent, otherwise it is inconsistent.

The mapping principle is illustrated in Fig. 2: For an MSD specification, oneenvironment automaton and one system automaton is created. For each MSD inthe specification, one MSD automaton is created. Together, these automata forma TGA network. The environment and system automata encode the behavior ofthe environment and system objects sending messages in the system. The MSDautomata encode the progress of the cut in the active MSD and violations thatmay occur in the MSD. The cut is encoded by globally declared lifeline variablesthat are created for each lifeline in each MSD.

If the environment chooses to send message x from object e:Env to the objects:S, this works as follows in the TGA network. First, the environment takesan edge in the environment automaton, assigning an according constant valueto the variable event (➀). Then the environment automaton takes an edge thatemits over the broadcast channel events. This may synchronize edges in the MSDautomata that represent the message. For each message in the MSD there is an


edge in the MSD automaton. This edge has a guard that ensures that it is onlysynchronized if the message sent is enabled in the current cut of the active MSD.It has an update label where the lifeline variables corresponding to the message’ssending and receiving lifelines are increased, encoding the progress of the cut.Fig. 2 shows the edge (➁) that corresponds to the first message in MSD D1.

Each message in each MSD is furthermore mapped to an integer constant dec-laration that represents the message in the above process. The constant namefor a message has the form <name of sending object> <name of receiving ob-ject> <name of message>. The constant value is always the value of a previ-ously created constant plus one. Of course, there must not be two variables orconstants with the same name in the TGA specification. Thus, many diagrammessages may be mapped to the same constant declaration if they have the samesender, receiver and message name. For example, the three messages called x inthe MSDs D1 and D2 must all be mapped to a single declaration of the constante s x. Similarly, each message in each MSD is mapped to an edge in the envi-ronment or system automaton (depending on whether it is a message sent by anenvironment or system object), which assigns the corresponding constant to thevariable event (Fig. 2 (➀)). Again, there must not be two edges that assign thesame value to the event variable in the environment or MSD automaton.

For each MSD, furthermore an edge is created in the MSD automaton thatis taken if a message is sent that is violating the active MSD in the current cut,i.e., the according message is not currently enabled, but nevertheless appearsin the MSD. The guard and update labels of this edge (Fig. 2 (➂)) are notshown in detail here. What’s more important is that, in order to know whether acurrently“sent”message appears in the MSD, a Boolean function eventInMSD(intev) is created in the local declarations of each MSD automaton for each MSDin the specification. This function has a return statement that consists of adisjunction that for each message in the MSD contains a statement that rendersthe disjunction true if the value of the variable event corresponds to that messagein the MSD. There must not be two redundant sub-expressions in the disjunction,so there is for example only one sub-expression (ev == e_s_x) even though themessage x appears in the MSD D1 two times.

In summary, the transformation from MSD to TGA is complex for the fol-lowing reasons. First, the resulting TGA models are complex, and, second, wehave to distinguish several different cases when translating elements (e.g., differ-ent kinds of messages: hot and cold; messages sent from environment or systemobjects; messages at the beginning, middle, or end of an MSD). Third, complexstring concatenations are required for variable and constant definitions, and,fourth, certain elements must not exist twice in the target model.

We realized this mapping by a TGG transformation from UML to an EMF2-based Uppaal Tiga model. The transformation can be downloaded as part ofScenarioTools.3 The TGG Interpreter can also be installed separately.4

2 http://www.eclipse.org/emf/3 http://www.cs.uni-paderborn.de/index.php?id=scenariotools4 http://www.cs.uni-paderborn.de/index.php?id=tgg-interpreter

http://www.eclipse.org/emf/

http://www.cs.uni-paderborn.de/index.php?id=scenariotools

http://www.cs.uni-paderborn.de/index.php?id=tgg-interpreter


Fig. 3. Message2Edge: A TGG rule for translating messages

4 OCL Integration

This transformation is an example where many string attribute values in thetarget model must be concatenated from different pieces of information in thesource model. In order to describe such string concatenations and other querieson the models, we have integrated OCL [18] in TGGs.

In a TGG rule, OCL expressions can be used in attribute value constraintsand application conditions. They are displayed as yellow rounded rectangles inthe TGG rule. In the OCL expressions, the names of nodes in the same rule canbe used as variables, which are bound to the same object as the node is boundto when the rule is matched in the model (or when target model objects arecreated). The TGG rule in Fig. 3 shows a range of attribute value constraints.

This rule maps messages in the UML model to a range of elements in the TGAmodel. This diagram shows the concrete syntax of the TGG rule editor that ispart of our TGG Interpreter tool suite. The domains are represented by theviolet nodes at the top of the diagram that link the nodes in the domain via thethin dotted gray lines. In this rule, a message in the UML model is mapped toan edge in the MSD automaton, represented by the node msgEventEdge:Edge.This edge is added to the automaton represented by the node msdAT:Template(an automaton definition is called a template in Uppaal). The source and targetlocation of the edge is the location represented by the node :Location. Further-more, the rule maps a message to the corresponding global constant declarationand the sub-expression of the return statement in the function eventInMSD(intev) that is declared locally for the corresponding MSD automaton (see bottomright in Fig. 2).

An attribute value constraint always points to a node, which is called itsslot node. The top row of the attribute value constraint’s rounded rectanglespecifies the constrained attribute, which is called the constraint’s slot attribute.The bottom row specifies an OCL expression, which is called the constraint’svalue expression. An attribute value constraint specifies that the slot node can


only be bound to an object if the value of the slot attribute equals the valuespecified by the value expression. During a forward transformation, attributevalue constraints in the target domain are interpreted as assignments.

Application conditions are also displayed as yellow rounded rectangles, butthey do not specify a slot node or slot attribute. They only specify an OCLexpression, called the condition expression, which must evaluate to a Booleanvalue. Application conditions come in two flavors: They can be either precondi-tions or postconditions. Preconditions must evaluate to true in order to applythe rule. At the end of the transformation, all postconditions of all applied rulesmust evaluate to true.

Operationally, the attribute value constraints are considered as follows. Weconsider a forward transformation scenario for simplicity. The TGG engine em-ploys a graph matching algorithm that starts with an initial matching of somesource or context node in the TGG rule, and tries to find a pattern in the do-main models that is isomorphic to the source and context pattern (as explainedin Sect. 3). During the graph matching process, the TGG engine tries to evalu-ate the value expression of an attribute value constraint as soon as a candidateobject for matching the slot node is found. If the result of the evaluation equalsthe value that the candidate object carries for the slot attribute, we say thatthe attribute value constraint holds. A node can be bound to an object if all at-tached attribute value constraints hold; then the graph matching can continue,otherwise the algorithm backtracks.

When evaluating the value expression, it may however happen that a vari-able in the expression is unbound because it corresponds to a node in the rulethat is not yet bound. In this case, the attribute value constraint is marked fora delayed evaluation. It is evaluated as soon as all the nodes that appear asvariables in its value expression are bound. If the constraint holds, the graphmatching continues. If it turns out that the constraint does not hold, the graphmatching backtracks. When backtracking, another binding for nodes that ap-pear as variables in the constraint’s value expression may be found so that theattribute value constraint holds, but the graph matching may also backtrack tofind another candidate object for the constraint’s slot node.

When creating elements in the target model, the attribute value constraintsare interpreted as assignments. This means that when an object is created in thetarget model according to a node, the value expression of each attached attributevalue constraint is evaluated. The value is then assigned to the slot attribute ofthe object created for the slot node. There may also be a delayed evaluation ifthe value expression of one constraint refers to a node that was not yet created.

At the end of the transformation, all attribute value constraints of all appliedTGG rules are checked once again. The transformation is only correct if allattribute value constraints hold.

Preconditions are evaluated as soon as all the nodes that appear as variablesin the condition expression are bound. The graph matching backtracks if thecondition expression evaluates to false. Postconditions are evaluated for all rule


applications at the end of the transformation. The transformation is only correctif all postconditions are satisfied.

The above section for example mentions the naming scheme for the constantthat represents a particular message in the TGA network. This name appears notonly in the global declarations, but also in the update and guard labels and thelocal declarations of the different automata. In order to avoid that complex OCLexpressions occur redundantly in the TGG rules, the TGG Interpreter al-lows the transformation engineer to define custom derived attributes for domainmodel elements within the transformation definition. These custom attributescan be defined in a separate OCL file and the OCL expressions within the TGGrules can refer to these attributes. For the MSD-to-TGA mapping, we have forexample defined the custom derived attribute typeName for UML messages. Itproduces the string <name of sending object> <name of receiving object> <nameof message> as explained above. This derived attribute is used three times withinOCL expressions in the TGG rule shown in Fig. 3.

5 Stereotype Constraints

With the powerful UML tools that are being developed around the Eclipse imple-mentation of UML2,5 model-based development in practice increasingly employsUML and its lightweight profile extension mechanism [19]. We have for exampleused a profile to add the temperature attribute of messages in MSDs to UMLsequence diagrams (similar to Harel and Maoz [12]) or to mark objects in thecollaboration diagram as system or environment objects (see Fig. 2).

In transformations involving stereotyped UML models, it is crucial to be ableto specify that a certain UML object has a particular stereotype applied or not.For this purpose, we have extended TGG rules by stereotype constraints that canbe added to nodes in UML domains. Stereotype constraints specify that a nodecan only bind a UML object if a certain stereotype is or is not applied to thatelement. These constraints are shown within a node’s label. An entry in doubleangle brackets represents a required stereotype. If preceded by the keyword not,this stereotype must not be applied.

The node msg:Message of the rule in Fig. 3 shows an example where thestereotype ModalMessage must be applied and the stereotype ForbiddenMessagemust not be applied. When a UML object is created according to a node with apositive stereotype constraint, the stereotype is applied to the object.

If a positive stereotype constraint is added to a node, it is possible to addattribute value constraints where the slot attribute is an attribute defined bythe stereotype that the stereotype constraint refers to. The TGG rule in Fig. 4shows an example where the attribute value constraint added to the node spec-Part:Property refers to the attribute partKind, an attribute defined by the stereo-type SpecificationPart.

5 http://www.eclipse.org/uml2/

http://www.eclipse.org/uml2/


6 TGG Rule Generalization

Generalization is a powerful mechanism in object-orientation for reusing and ex-tending existing solutions. Klar et al. have introduced this concept to TGG rules[15] and realized it within theMoflon tool suite. In our example transformation,there are different kinds of messages that need to be mapped to the TGA model.Some elements in the TGA model must be created for all messages, some mustbe created e.g., only for environment messages. For this purpose, we adopted therule generalization concept proposed by Klar et al. with some improvements.

A TGG rule describes a relation between sets of objects. Klar et al. argue that“generalization usually means that a member of a more specialized type also is amember of the more general type” and, thus, whenever a more specialized TGGrule is applicable, also the more general rule should be applicable [15, Sect. 4.1].We call this the guiding principle of TGG rule generalization in the following.

To ensure that, Klar et al. define a number of syntactical constraints for aTGG rule that specializes another. These constraints require, first (1), that aspecialized rule contains a copy of the general rule [15, rule 14]. Second (2),context nodes in the specialized rule may be replaced by nodes with a morespecialized type [15, rule 15]. Third (3), produced nodes in the general rule canbe converted to context nodes in the specialized rule [15, rule 15]. Forth (4), newnodes and edges may be added to the context and produced pattern of the rule[15, rule 16], and, fifth (5), further attribute value constraints and applicationconditions may be added to the rule [15, rule 17]. Last (6), the specialized rulemust have a higher priority than the more general rule [15, rule 10]. Prioritiesare numbers assigned to rules; the Moflon transformation engine will first tryto apply rules with a higher number. This way it is ensured that a more generalrule is only applied when any specialization of that rule cannot be applied.

In the TGG Interpreter, a specialized TGG rule also basically consists ofa copy of the more general rule (as (1) above) and nodes, edges, and constraintsmay be added to the specialized rule (as (4) and (5) above). Furthermore, nodesmay be replaced by nodes with a more special type class. In contrast to (2)above, this is allowed also for produced nodes, since it does not violate the guid-ing principle of TGG rule generalization. However, it is not allowed to convertproduced nodes to context nodes in the more specialized rule (as (3) above).This is not allowed because, due to the bind-only-once semantics of producednodes, this would violate the guiding principle of TGG rule generalization.

Another difference in the TGG rules of the TGG Interpreter tool suitecompared to the Moflon tool suite is that in order to create a specialized rule,the transformation engineer does not literally need to create a copy of the moregeneral rule first. Instead, the rule diagram of the more specialized rule justcontains the added nodes, edges, and constraints, and such nodes from the moregeneral rule to which additional edges and constraints are attached. Also, thespecialized rule contains the nodes from the more general rule which are givena more specialized type. All other nodes from the more general rule are only“copied” into the specialized rule during transformation-time. This makes therule set better maintainable and the rule diagrams more concise.


Fig. 4. EnvironmentMessage2Edge: A TGG rule for translating a minimal environmentmessage

Nodes of a more general rule that recur in the specialized rule are called re-fining nodes. They have the same name as the node that they represent and aredisplayed with a dashed border. Figure 4 shows a specialization of the TGG rulein Fig. 3. This specialized rule maps an environment message (also) to an edgein the environment automaton. The nodes coll:Collaboration and msg:Messageare refining nodes that appear in this rule because patterns that are added inthis specialized rule are attached to these nodes. A message is an environmentmessage if the SpecificationPart stereotype is applied to the property in the col-laboration diagram that is represented by the sending lifeline of the message;moreover, the stereotype application must carry the value Environment for thepartKind attribute. This is expressed by the pattern added to the UML domainof this rule. In the target domain, the message is mapped to an edge in theenvironment automaton with an update label as explained in Sect. 3.

Another difference to the rule generalization approach presented by Klar etal. is that we do not use priorities to ensure that the transformation engine willalways try to apply more specialized rules before trying to apply more generalrules. Instead of priorities we define that a more specialized rule has precedenceover its more generalized rule. The transformation engine will not try to applya rule if it did not try to apply another rule with precedence over that rule.The difference in this approach is that the precedence induces a partial orderamong the TGG rules whereas the priorities define a total order. The advantageof the precedence is that it is less restrictive and will not unnecessarily restrictthe non-determinism among the rules; if we for example employ heuristics forapplying TGG rules in a smart order for increasing the transformation speed,such heuristics will have more freedom to select the next rule to apply.

Note that the precedences are only relevant in the operational interpretationof the rules, i.e., they are only a directive for the transformation engine to tryto apply certain rules first in a particular application scenario. By contrast, thevalid triple-models are defined as those that can be produced by the TGG rulesregardless of the precedences.


7 Reusable Patterns

As described in Sect. 3, each diagram message in each MSD is mapped to aninteger constant declaration. The “same” diagram message can appear severaltimes in several MSDs and must be mapped to the same constant declaration.To handle the case where yet no constant declaration exists for a message, wewould need a rule where this constant declaration is represented by producednodes. To handle the case where the constant declaration for a message alreadyexists, we would need a rule where the constant declaration is represented bycontext nodes. The previous rule cannot be used for this case because of the bind-only-once semantics of the produced nodes. If there are many different elementsthat may or may not already exist, this leads to a large number of rules that mustbe created for mapping the same element. For that reason, we have introducedthe concept of reusable nodes and reusable edges to TGGs [10]. The semanticsof a rule with a reusable node is equivalent to two rules where the node is aproduced node in one rule and a context node in the other. A transformationengine may therefore nondeterministically decide to interpret a reusable node asa produced node or as a context node. The same holds for reusable edges.

Reusable nodes can also appear in the source domain. The nodes representingthe lifeline and the property in Fig. 4 are reusable nodes because they may ormay not have been bound previously.

In the target domain, it is sometimes crucial to force the transformation engineto reuse a certain object structure, i.e., interpret the reusable nodes as contextnodes. This is typically the case if creating another object structure instead ofreusing one creates an invalid or inappropriate model. In the above case, theremust for example not be two constant declarations with the same name. Further-more, once an edge is created for an environment message in the environment au-tomaton (see Fig. 4), this edge should be reused, because there should not be twoedges from and to the same locations with identical guard, update and synchro-nization labels. Such constraints are sometimes part of a domain meta-model;sometimes they are only formulated for the purpose of a transformation. We callthese constraints global constraints [10] and define that a triple-model producedby a TGG is only valid if all global constraints are satisfied. At the end of atransformation, our TGG Interpreter validates the constraints formulated inthe domain meta-models and the transformation-specific global constraints thatcan be formulated via OCL in an external file.

If the global constraints are not satisfied at the end of a transformation, thismeans that the transformation engine may have to backtrack over the rule appli-cations, reusing existing objects where previously it created them or creating newobjects where it previously reused others. The latter could be required if globalconstraints formulate a lower bound, for example that there must be always atleast two objects with certain properties in a model.

The TGG Interpreter, however, currently cannot backtrack over rule ap-plications. Since in most cases the global constraints formulate upper bounds,such as that there must be only one object with certain properties in the model,it is in most cases sufficient to try reusing objects wherever this is possible.


The TGG Interpreter therefore implements a reuse-before-create semanticsfor reusable nodes. This is similar to the check-before-enforce semantics in QVT-Relations [17, Sect. 7.2.3]. In contrast to QVT-Relations, however, the reuse-before-create semantics is only one possible operational interpretation of reusablenodes in TGGs—it is not part of the general TGG semantics.

The reuse of an object or a link is decided for each reusable node and edge.Sometimes, however, this could lead to unintended effects. Consider the tworeusable nodes assignEnvEventEdge:Edge and :TextualStatement in the TGG ruleof Fig. 4. In a case where some environment messages were previously translated,there would be an uncontrollable edge in the environment automaton that thereusable node assignEnvEventEdge:Edge could always reuse. However, the updatelabel statement attached to that edge may not be reusable, because the edgedoes not correspond to the “same” message. In this case, a second update labelstatement would be attached to the same edge, which is not what we intended.

As a solution, we have introduced the concept of reusable patterns. A reusablepattern is a set of reusable nodes and edges in a rule. It is represented by a smallgray node with a “##” label that is connected to reusable nodes. The reusablepattern consists of all the connected nodes the reusable edges between them.

The semantics of a TGG rule with a reusable pattern is equivalent to tworules where all the nodes and edges in the pattern are produced nodes and edgesin one rule and all the nodes and edges in the pattern are context nodes andedges in the other rule. Operationally, the TGG Interpreter will first try toreuse the pattern structure and will only try to create it if that is not possible.

8 Properties of the TGG Extensions

As described in Sect. 2 and 4, a triple-model is valid according to a TGG if (a) itcan be produced by a sequence of TGG rule applications, (b) all postconditionsand attribute value constraints hold for each applied TGG rule, and (c) allglobal constraint hold. If after a transformation all model domain elements arebound, the bind-only-once semantics and the final checking of above-mentionedconstraints ensure that only valid triple-models are effectively created by theTGG Interpreter. This ensures the correctness of the results.

Also note that the precedence concept introduced for the rule generalizationdoes not violate the correctness of a transformation. Intuitively, this is becausethe precedences are not considered when applying rules to produce the validtriple-models. Therefore, if a rule is applied in a forward transformation, theresulting bound triple-model always could have been created by a sequence ofTGG rule applications that create all parts of the triple-model in parallel.

One general issue when operationally interpreting TGG rule in transforma-tion scenarios is that at several steps during the transformation, different choicescan be made on applying rules. This non-determinism leads to the problem thatcertain sequences of rule applications lead to producing a valid triple-model, butothers do not. Our TGG Interpreter currently does not support backtrackingover rule applications. Therefore, in some cases, we may not find a valid trans-formation result if one exists, i.e., our transformation algorithm is not complete.


Reusable nodes and rule inheritance potentially increase the variety of choicesthat the transformation engine has during a transformation. We plan to imple-ment a backtracking mechanism in our TGG Interpreter. The backtrackingmechanism should especially be able to consider choosing a more general ruleinstead of selecting only the most special ones applicable. It should also be ableto change the interpretation for a reusable node or pattern (interpreting it as aproduced node/pattern instead of a context node/pattern or vice versa).

As mentioned above, it may happen that several valid triple-models can be cre-ated from a source model, in which case the transformation result is not unique.We currently support no analysis methods that help to determine whether atransformation result is unique. Hermann et al. [14] present an approach thatuses critical pair analysis to determine whether the transformation result of aTGG may not be unique.

9 Related Work

Dang and Gogolla [4] presented an approach for using OCL for specifying at-tribute value constraints and application conditions within TGGs. In their ap-proach, they specify TGG rules textually, including a number of OCL statements.Then an OCL framework can execute the TGG rules, including the assignmentof attribute values in the target domain. Compared to the approach presentedhere, however, they cannot define custom derived attributes for domain elements.

Golas et al. [7] show how to integrate application conditions in TGGs. They ex-tend a formal framework for TGGs to show the termination, information preser-vation, correctness and completeness of transformations based on the extendedTGGs. Their application conditions are restricted to formulating constraints onthe context part of the rule. Also they assume that constraints in the sourcemodel are only evaluated in the scope of the already bound part of the sourcemodel. In the TGG Interpreter, constraints are evaluated with respect tothe whole source model. We plan to investigate restrictions to our constraintsthat are necessary to ensure the completeness and information preservation ofour transformations. Klar et al. [16] show that efficient translators for TGGwith NACs are still preserving the fundamental TGG properties. However, theseNACs are restricted to forbidding the existence of model elements.

To the best of our knowledge, there are no other TGG or QVT engines whichprovide a convenient support for constraints on stereotypes in UML models.Giese et al. [6] present a TGG-based transformation of a UML model with aSysML profile, but no indication is given on if and how constraints on stereotypeapplications are supported by their transformation engine.

Besides TGGs in Moflon, we are not aware of another relational transfor-mation engine supporting a rule generalization concept. The comparison withother, non-relational model transformation languages is beyond the scope of thispaper. We refer to Wimmer et al. [21], who compare the TGG rule generalization


concept of Klar et al. to the rule generalization concept of ATL6 and ETL.7

Guerra et al. [11] present a technique to specify transformations declarativelyby relations between models that must or must not exist. Similar to rule gener-alization, it is a promising approach to make transformation specifications moreintuitive. They also support attribute constraints.

Geiger et al. present a TGG engine [5] in which produced nodes can bematched multiple times to target objects. This violates the bind-only-once se-mantics for produced nodes, which is crucial for creating valid triple-models.

10 Conclusion and Outlook

In this paper, we reported on practically relevant TGG extensions that we elabo-rated and implemented in the TGG Interpreter. We extended TGGs by OCLfor specifying attribute value constraints, application conditions, and custom at-tributes. We also integrated support for specifying constraints on stereotypeapplications and elaborated a rule generalization concept, refining the ideas ofKlar et al. [15]. Last, we extended the concept of reusable nodes to reusablepatterns to better control the reuse of model structures in target models.

With these extensions, TGGs become a powerful and flexible formalism forsolving many complex model transformation and synchronization problems. Weused these extensions in different transformation scenarios. Especially, the rulegeneralization improves the maintainability of the rule set. Complex OCL con-straints and conditions also frequently occur in practical transformations.

We have also identified some open challenges. For example, using rule general-ization in our example, we still ended up with some redundant rule patterns. Weare therefore planning a more flexible rule extension mechanism. Furthermore,the reuse-before-create semantics of reusable patterns may not be practical inall cases. Therefore it could be useful to attach specific constraints on reusablepatterns to more specifically control the reuse of model patterns. In addition,implementing backtracking over rule applications is also planned for the future.

References

1. Amelunxen, C., Konigs, A., Rotschke, T., Schurr, A.: MOFLON: A Standard-Compliant Metamodeling Framework with Graph Transformations. In: Rensink,A., Warmer, J. (eds.) ECMDA-FA 2006. LNCS, vol. 4066, pp. 361–375. Springer,Heidelberg (2006)

2. Bengtsson, J., Larsen, K., Larsson, F., Pettersson, P., Yi, W.: UPPAAL – A ToolSuite for Automatic Verification of Real-time Systems. In: Alur, R., Henzinger, T.A.,Sontag, E.D. (eds.) HS 1995. LNCS, vol. 1066, pp. 232–243. Springer, Heidelberg(1996)

3. Cassez, F., David, A., Fleury, E., Larsen, K.G., Lime, D.: Efficient On-the-FlyAlgorithms for the Analysis of Timed Games. In: Abadi, M., de Alfaro, L. (eds.)CONCUR 2005. LNCS, vol. 3653, pp. 66–80. Springer, Heidelberg (2005)

6 http://www.eclipse.org/atl7 http://www.eclipse.org/gmt/epsilon/doc/etl/

http://www.eclipse.org/atl

http://www.eclipse.org/gmt/epsilon/doc/etl/


4. Dang, D.-H., Gogolla, M.: On Integrating OCL and Triple Graph Grammars. In:Chaudron, M.R.V. (ed.) MODELS 2008. LNCS, vol. 5421, pp. 124–137. Springer,Heidelberg (2009)

5. Geiger, N., Grusie, B., Koch, A., Zundorf, A.: Yet another TGG engine? In: Nor-bisrath, U., Jubeh, R. (eds.) Int. Fujaba Days. Kasseler Informatikschriften (2011)

6. Giese, H., Hildebrandt, S., Neumann, S.: Model Synchronization at Work: KeepingSysML and AUTOSAR Models Consistent. In: Engels, G., Lewerentz, C., Schafer,W., Schurr, A., Westfechtel, B. (eds.) Graph Transformations and Model-DrivenEngineering. LNCS, vol. 5765, pp. 555–579. Springer, Heidelberg (2010)

7. Golas, U., Ehrig, H., Hermann, F.: Formal Specification of Model Transformationsby Triple Graph Grammars with Application Conditions. In: Rachid Echahed,A.H., Mosbah, M. (eds.) Int. Workshop on Graph Computation Models. ElectronicCommunications of the EASST, vol. 39 (2011)

8. Greenyer, J.: Synthesizing modal sequence diagram specifications with Uppaal-Tiga. Tech. Rep. tr-ri-10-310, University of Paderborn (2010)

9. Greenyer, J.: Scenario-Based Design of Mechatronic Systems. Ph.D. thesis, Uni-versity of Paderborn (2011)

10. Greenyer, J., Kindler, E.: Comparing Relational Model Transformation Technolo-gies: Implementing Query/View/Transformation with Triple Graph Grammars.Software and Systems Modeling 9(1), 21–46 (2010)

11. Guerra, E., de Lara, J., Orejas, F.: Pattern-Based Model-to-Model Transformation:Handling Attribute Conditions. In: Paige, R. (ed.) ICMT 2009. LNCS, vol. 5563,pp. 83–99. Springer, Heidelberg (2009)

12. Harel, D., Kleinbort, A., Maoz, S.: S2A: A Compiler for Multi-modal UML Se-quence Diagrams. In: Dwyer, M.B., Lopes, A. (eds.) FASE 2007. LNCS, vol. 4422,pp. 121–124. Springer, Heidelberg (2007)

13. Harel, D., Maoz, S.: Assert and negate revisited: Modal semantics for UML se-quence diagrams. Software and Systems Modeling 7(2), 237–252 (2008)

14. Hermann, F., Ehrig, H., Orejas, F., Golas, U.: Formal Analysis of Functional Be-haviour for Model Transformations Based on Triple Graph Grammars. In: Ehrig,H., Rensink, A., Rozenberg, G., Schurr, A. (eds.) ICGT 2010. LNCS, vol. 6372,pp. 155–170. Springer, Heidelberg (2010)

15. Klar, F., Konigs, A., Schurr, A.: Model transformation in the large. In: ESEC-FSE2007, pp. 285–294. ACM, New York (2007)

16. Klar, F., Lauder, M., Konigs, A., Schurr, A.: Extended Triple Graph Grammarswith Efficient and Compatible Graph Translators. In: Engels, G., Lewerentz, C.,Schafer, W., Schurr, A., Westfechtel, B. (eds.) Graph Transformations and Model-Driven Engineering. LNCS, vol. 5765, pp. 141–174. Springer, Heidelberg (2010)

17. Object Management Group (OMG): MOF Query/View/Transformation (QVT) 1.1Specification, OMG document formal/2011-01-01

18. Object Management Group (OMG): Object Constraint Language (OCL 2.2) spec-ification, OMG document formal/2010-02-01

19. Object Management Group (OMG): UML 2.3 Superstructure Specification, OMGdocument formal/2010-05-03

20. Schurr, A.: Specification of Graph Translators with Triple Graph Grammars. In:Mayr, E.W., Schmidt, G., Tinhofer, G. (eds.)WG1994. LNCS, vol. 903, pp. 151–163.Springer, Heidelberg (1995)

21. Wimmer, M., Kappel, G., Kusel, A., Retschitzegger, W., Schonbock, J., Schwinger,W., Kolovos, D., Paige, R., Lauder, M., Schurr, A., Wagelaar, D.: A Comparisonof Rule Inheritance in Model-to-Model Transformation Languages. In: Cabot, J.,Visser, E. (eds.) ICMT 2011. LNCS, vol. 6707, pp. 31–46. Springer, Heidelberg (2011)

Automatic Conformance Testing of Optimized

Triple Graph Grammar Implementations�

Stephan Hildebrandt, Leen Lambers, Holger Giese,Dominic Petrick, and Ingo Richter

Hasso Plattner Institute at the University of PotsdamProf.-Dr.-Helmert-Straße 2-314482 Potsdam, Germany

{stephan.hildebrandt,leen.lambers,holger.giese}@hpi.uni-potsdam.de,{dominic.petrick,ingo.richter}@student.hpi.uni-potsdam.de

Abstract. In model-driven development, model transformations can bespecified using an operational (imperative) or relational (declarative) ap-proach. When using a relational approach, approved formal concepts arenecessary to derive a conform operationalization. In general, though, itis not sure if implementations realize these formal concepts in an entirelycorrect way. Moreover, usually, available formal concepts neither coverevery technicality, nor cover each additional optimization an implemen-tation relies on. Consequently, conformance needs to be validated alsoon the implementation level. Conformance means that for each sourcemodel S and target model T related according to the relational specifi-cation, a corresponding implementation transforms S into T (and T intoS in case that the specification is bidirectional).

We present an automatic conformance testing approach for TGG im-plementations, where the Triple Graph Grammar (TGG) approach is animportant representative of relational model transformation approaches.We show that the grammar character of TGGs is very convenient for theautomatic generation of conformance test cases. In particular, test inputmodels can be generated together with their expected result obtaining acomplete oracle. We show how to measure test suite quality and evaluateour approach on our own TGG implementation.

Keywords: Conformance testing, model transformation, triple graphgrammar, relational specification, model-driven development.

1 Introduction and Motivation

When models and model transformations become most important artefacts asproposed in the MDE approach, it is essential to be able to rely on their correct-ness. In particular, model transformations holding errors may cause problems in

� This work was partially developed in the course of the project – Correct ModelTransformations – Hasso Plattner Institut, Universitat Potsdam and was pub-lished on its behalf and funded by the Deutsche Forschungsgemeinschaft. Seehttp://www.hpi.uni-potsdam.de/giese/projekte/kormoran.html?L=1


http://www.hpi.uni-potsdam.de/giese/projekte/kormoran.html?L=1

Automatic Conformance Testing of Optimized TGG Implementations 239

the complete development chain. When using a relational model transformationapproach, errors may arise because of faulty operationalizations. Therefore, inthis paper, we concentrate on conformance testing for relational model trans-formation specifications and their implementations. Conformance means thatfor each source model S and target model T related according to the relationalspecification, a corresponding implementation transforms S into T (and T intoS in case that the specification is bidirectional).

The Triple Graph Grammar (TGG) approach is an important representa-tive of the relational model transformation approach. Basic theoretical conceptsdescribing the derivation of TGG operationalizations are available ever sincethe TGG approach emerged [31]. To a certain extent, formal reasoning can beapplied to prove conformance of the TGG and a corresponding operational-ization [32,21,15]. In general, though, it is not sure if implementations realizeeach formal concept describing a conform operationalization in an entirely cor-rect way. Moreover, usually, TGG formalizations neither cover every technicalityTGG implementations rely on, nor cover each additional optimization augment-ing efficiency of the model transformation execution. In practice, there existdifferent TGG implementations, realizing slightly different dialects, such as Fu-jaba TGG Engine [5], MOFLON [1], or ATOM3 [25]. Furthermore, even for asingle tool holds that different tool versions with different optimizations exist.Consequently, in order to ensure the correct automation of model transforma-tions, conformance needs to be validated also on the implementation level. Inprinciple, back-to-back testing could be adopted to validate that different TGGimplementations are equivalent, and regression testing could be adopted to val-idate that an implementation and its optimized version are conform. However,apart from that this may become very tedious, it does not ensure conformancewith the specification. Therefore, in this paper we present an automatic confor-mance testing approach for TGGs and their implementations. We are confidentthat our approach is a good basis to develop conformance testing approachesalso for other relational specification techniques such as QVT relational [29]. Inparticular, making use of [19] where an implementation of QVT relational withTGGs is presented.

For our conformance testing approach we exploit the following typical fea-tures of TGGs: (1) Because of its grammar character a TGG may serve as an”executable” model transformation contract being able to generate all correctlyrelated input/output models obtaining a complete oracle. (2) A TGG describesbidirectional model transformations. We aim at providing the TGG implemen-tation developer with automatic conformance testing support by generating testcases (exploiting the first feature) for forward as well as backward transforma-tions (exploiting the second feature).

With conformance testing we mean that we search for errors in the imple-mentation violating conformance with the specification [30] instead of findingerrors in the specification itself. Moreover, we generate test cases that start witha ”correct” input according to the specification, i.e., we present an approachfor positive, not negative testing. Note that our test approach is designed to

240 S. Hildebrandt et al.

-name : stringBlockDiagram

-name : stringSystemBlock

-name : stringBlock

1*

1*

BD2CD

SB2CL

BL2CL

-name : stringClassDiagram

-name : stringClass

-text : stringStereotype

-name : stringAssociation

1*1

*

1

*

source

target

Block Diagram Meta Model

Correspondence Meta Model

Class Diagram Meta Model

Fig. 1. Example metamodels

be applied to different versions or optimizations of the same TGG tool or evendifferent TGG implementations, e.g., MOFLON [1] or the TGG Interpreter [19].However, in the latter case, the problem of different input formats of TGG Rulesposes an obstacle in practice. Different TGG implementations usually expectTGG rules in different technical formats. Therefore, a format conversion wouldbe required before other TGG implementations can be tested with our frame-work. Furthermore, TGGs may specify non-deterministic forward and backwardrelations between source and target models. However, a model transformation isusually expected to return a deterministic result for a given input. Moreover, asexplained in Sect. 3.3, having non-deterministic TGGs, it may not be possible touse our automatic test approach. Therefore, we impose some restrictions on theTGG rules (as explained more in detail in [15,16]) that can be verified staticallyto guarantee determinism.

Paper Outline. In Section 2, we introduce TGGs as relational model transfor-mation specification technique and explain what it means for implementationsto be conform with such a specification. We continue in Section 3 with a descrip-tion of how to automate conformance testing of TGG implementations and howa corresponding test environment looks like. We also concentrate on measuringtest suite quality. In Section 4, we show the results of testing our own TGG im-plementation and evaluate our approach. We give a description of related workin Section 5. Section 6 gives a summary and an overview on future work.

2 Conform Triple Graph Grammar Implementations

In general, three kinds of transformations can be performed with TGGs: For-ward, backward, and correspondence transformations. A forward (backward)transformation takes a source (target) model as input and creates the corre-spondence and target (source) model. A correspondence transformation requiresa source and target model and creates only the correspondence model. Subse-quently, we concentrate on forward transformations. Analogous results can bederived for the backward case (which is symmetric) and the correspondence case.


bd1:BD

sb2:SB

bl3:BL

cn1:BD2CD

cn3:BL2CL

cn2:SB2CL

cd1:CD

cl2:CL

cl3:CL

as3:AS

source

target

a++: Created by TGG axiom; r1++: TGG rule 1; r2++: TGG rule 2

r2++r2++

r2++r2++

r2++r2++ r2++

r2++

r2++r2++

S C T

name := "bd1" name := "bd1"

name := "sb2" name := "sb2"

name := "bl3"

name := "bl3"

name := "bl3"

r1++r1++ r1++

r1++ r1++r1++r1++

Fig. 2. Forward transformation via the relational scheme

TGGs as Relational Specification Technique: To illustrate the followingexplanations, we will use a model transformation from simple SDL block dia-grams1 to UML class diagrams. The source and target metamodel of this modeltransformation are shown in Fig. 1. When using TGGs to specify model trans-formations, apart from the source and target metamodel, there is also a so-calledcorrespondence metamodel. Its elements store traceability information, allowingto find elements from the source model that correspond to the target model,i.e., the correspondence model partly overlaps with the source and target mod-els. TGGs relate three different models: A source model, a target model, anda correspondence model connecting the source and target model to a so-calledtriple graph. Further on, we use a triple of variables SCT to denote one triplegraph, where S denotes its source component, C its correspondence component,and T its target component. In our example, block and class diagrams are thesource and target graphs connected by a correspondence graph, constituting atriple graph (see Fig. 2). A TGG consists of an axiom SACATA (the grammar’sstart graph)2 and several TGG rules that are always creating.3 The TGG forthe transformation of block and class diagrams is shown in Fig. 3.4 Elementsthat are preserved are drawn black, elements that are created are drawn greenand marked with ”++”. The TGG can be used to build triple graphs, repre-senting correctly related source and target models, as follows: Starting from theaxiom, the rules of the TGG are applied wherever they match in an arbitraryorder leading to a derivation tree like shown in Fig. 4. Each arrow represents a

1 This is a simplified version of SDL block diagrams(http://www.itu.int/ITU-T/studygroups/com17/languages/Z100.eps)

2 In particular, we use a so-called axiom rule, which is applied once to the emptygraph and thereby sets some attribute values creating the concrete axiom.

3 We restrict our explanations to TGG rules without application conditions, but itis possible to apply our test framework also to more expressive TGGs holding ap-plication conditions[22,21,19]. In our TGG implementation it is possible to expressapplication conditions using OCL constraints.

4 Note, that the types defined in Fig. 1 are abbreviated in Fig. 3.

http://www.itu.int/ITU-T/studygroups/com17/languages/Z100.eps


bd1:BD cn1:BD2CD cd1:CD

bd1:BD cn1:BD2CD cd1:CD

++++

++++

++

sb2:SB cn2:SB2CL cl2:CL

++++

++++

++

++++

sb2:SB cn2:SB2CL cl2:CL

bl3:BL cn3:BL2CL

as3:AS

cl3:CL

source

target

++

++++

++

++

++

++++

++++

++

++

cn1:BD2CD cd1:CDbd1:BD

Axiom Rule (BlockDiagram to ClassDiagram)

Rule 1 (SystemBlock to Class)

Rule 2 (Block to Class and Association)

SA CA TA

SL1 CL1 TL1

SR1 CR1 TR1

SL2 CL2 TL2

SR2 CR2 TR2

name := cd1.name name := bd1.name

name := cl2.name name := sb2.name

name := cl3.name

name := bl3.name

name := bl3.name

Fig. 3. Example TGG rules and axiom rule

rule application and each node represents a triple graph of the so-called TGGlanguage L(TGG) containing all correctly related models according to the TGG.Applying TGG rules in this manner is used later on to automatically generatesource and target test models (see Sect. 3).

The most straightforward way to derive a forward translation from the re-lational TGG follows the so-called relational scheme: Given a source graph S,then the forward translation via the relational scheme returns a set of triplegraphs that can be generated by the TGG starting from SACATA and have Sas a source component. Fig. 2 shows a block diagram S with a correspondingclass diagram T connected by a correspondence model. Assuming that we wantto transform the depicted block diagram S, T is a valid forward transformationresult following the relational scheme because the triple graph SCT is createdaccording to the TGG in Fig. 3. The annotations in Fig. 2 indicate which rulescreate the corresponding elements. The attribute assignments ensure equality ofthe name attributes of corresponding elements. However, while all three mod-els are created in parallel, the actual name values can be chosen arbitrarily.Note that the generation of SCT corresponds conceptually to one path in thederivation tree of Fig. 4.

Conform TGG Implementation: In practice, when performing a forwardtransformation via some TGG, one of the models already exists and a modeltransformation system has to create the other one. Therefore, operational ruleshave to be generated from the TGG, which create consistently related target


S C T

Legend:

S21 C21 T21

S22 C22 T22

S23 C23 T23

S24 C24 T24S25 C25 T25

S26 C26 T26

Relational Scheme

... ... ......

SA CA TA

S11 C11 T11 S12 C12 T12 S13 C13 T13

Legend:

L(TGG)Cij TijSij

Implementation

S S C1 T1S CA TA ...

L(TGG) ?

S translated elements of S

C TS

S

Fig. 4. Relational scheme and implementation

model elements for given source model elements. For each of the aforementionedtransformation directions, separate operational rules can be derived and they areapplied to the model to be translated in some specific optimal way. This resultsin a linear derivation for the implementation like shown in Fig. 4. Thereby, inorder to ensure conformance with the relational scheme, it is important that theresulting triple graph belongs to the aforementioned triple graph language. Forexample, Fig. 2 shows a forward translation following the relational scheme froma block diagram into a class diagram. A conform implementation would start itstranslation with the BlockDiagram and transforms it into the depicted ClassDi-agram. The following section is concerned with testing this kind of conformance.

Our TGG Implementation: We have developed an implementation5 of TGGsbased on Eclipse and the Eclipse Modeling Framework.6 The system can per-form model transformations (see [15,16] for more information and formal details)and model synchronizations[18]. It utilizes several optimizations to increase per-formance of model transformations, for example, limiting the pattern matchingprocess to parts of the source model. Fig. 5 shows an overview of the tool’s ar-chitecture and the test framework, which will be presented in Sect. 3. The corecomponent of our tool architecture is the TGG Engine, which performs modeltransformations specified by a set of TGG Rules, which can be edited by a TGGEditor. While TGGs are a purely relational formalism, an operational form hasto be derived to make them executable. In our implementation, a set of StoryDiagrams [11] is generated for each TGG rule by an Operational Rules Gener-ator. Story Diagrams combine UML activity diagrams to express control flow,and graph transformation rules to express pattern matching and modifications

5 Downloadable from our Eclipse update site http://www.mdelab.de/update-site6 http://www.eclipse.org/emf

http://www.mdelab.de/update-site

http://www.eclipse.org/emf


TGG EditorOperational

Rules Generator

TGG Rules

Story Diagrams

TGG Engine

Source Model

Target Model

Test Model Generator

ExpectedTarget Model

EMFCompare ?

Impl.Coverage

Data

TGG Monitor

Spec.Coverage

Data

create generate

execute

generate

generate

TGG Implementation

Fig. 5. Test environment

on graphs. For each TGG rule, three story diagrams are generated, one for eachtransformation direction. These Story Diagrams are executed by a Story Dia-gram Interpreter [17]. The TGG Engine invokes the interpreter to execute theappropriate Story Diagrams.

3 Automatic Conformance Testing of TGGImplementations

3.1 Test Objective

As explained in Sect. 2, the TGG language L(TGG) contains all correctly re-lated source and target models SCT according to the TGG. Our test objectiveis checking conformance of the TGG implementation with the TGG. A TGGand its implementation are conform if for each SCT belonging to L(TGG) itholds that S is translated forward into T and T is translated backward into Sby the TGG implementation. In particular, we want to analyze that for eachnode SijCijTij in Fig. 4, it holds that Sij is translated forward into Tij by theimplementation and Tij is translated backward into Sij .

7

In our implementation, possible sources of errors are the TGG Engine andthe Operational Rules Generator because these components make up the TGGImplementation. Causes may originate from an implementation that does not re-alize each formal concept describing a conform operationalization in an entirely

7 In principle, one could also include the correspondence component into the test objec-tive. However, we ignore the correspondences here, because we are mainly interestedin the model transformation result T.


correct way. Moreover, an implementation might include erroneous optimiza-tions, or domain-specific technicalities not considered in the TGG formalizationso far. In Sect. 4, we present such technical specialties.

3.2 Test Case Definition and Random Generation

Given the test objective, we can define a test case for the forward case (backwardanalogous) as follows: it consists of a source graph S and the expected targetgraph T such that there exists a triple graph SCT in the TGG languageL(TGG).

Usually, one major problem when generating test cases for model transfor-mations is how to obtain the expected target models as test oracles (see Sect. 5on related work). However, in the case of TGGs, their grammar character (seeSect. 2 and Fig. 4) allows us to automatically generate triple graphs SCT in arandom way, representing a test case input with a source graph S and expectedtarget graph T . This random generation procedure is implemented by the TestModel Generator (cf. Fig. 5). First, it creates the elements of the axiom (thegrammar’s start graph). Then it randomly applies all TGG rules a predefinednumber of times to extend the start graph. At this point, the source S and targetmodel T are extracted from the triple graph SCT .

3.3 Test Case Execution

A test case consists of a test case input S and the expected target graph T ,generated randomly as described in the last section. The source model S istransformed by the TGG implementation under test to create a second targetmodel T ′. According to the test objective, the expected target model T andT ′ must be equal to pass the test successfully, otherwise one has detected aconformance error. Here, we exploit the fact that the model transformation isdeterministic (cf. Sect. 1), i.e., there is only one target graph T corresponding toS. Otherwise, we would have to generate the set of all target models to a specificsource model, and check whether the created target model T ′ is contained inthat set. This would greatly increase computation effort if it is at all possible(e.g., the number of possible target models could be infinite).

Technically, we compare the expected target model T and computed model T ′

using EMFCompare. It uses a heuristic to find pairs of corresponding elementsin both models. All elements of the two models are compared by a similaritymetric based on types, values of attributes and references of both elements.EMFCompare is able to detect identical models based on this metric. Moreover,it outputs information about differences between both models. More informationcan be found in [34]. Note that although this technical solution is quite satis-factory already, model comparison is a research topic on its own as describedin [26].

If a conformance error has been detected, we need some means to find itscause. To this extent, we provide a TGG Monitor logging the internal state of theTGG Engine during a model transformation execution allowing the developerto inspect the model transformation step-by-step.


3.4 Test Suite Quality

The grammar character of TGGs gives us a means to randomly generate testcases. However usually, an infinite number of them exists so we have to limit thesize of test cases. Therefore, we need some well-considered techniques to measurethe quality of a test suite, consisting of a finite set of test cases. To this extent, weapply different test adequacy criteria. We not only consider the TGG as an oracle,but we consider it also to develop specification coverage criteria. Moreover, weevaluate the quality of our test suite with respect to implementation coverage.

Specification coverage is analyzed by checking for a given test suite whichTGG rules it covers. In particular, if each TGG rule was used at least once8 togenerate test case inputs and corresponding expected results of the test suite,then the correct implementation of each TGG rule is tested. Therefore, we havethe following TGG rule coverage criterion: Given a test suite, each TGG rule hasbeen applied at least once in order to generate the test suite. TGG rule coveragecan be measured by evaluating test cases that were randomly generated (seeSect. 3.2). During random generation of test cases, the Test Model Generator(see Fig. 5) records, which of the TGG rules have been applied such that it canprovide us also with coverage data.

11..* 1..*10..*

0..* 0..*

0..*

11..* 1..*10..*

0..* 0..*

0..*

1..*

1++++

++++

++

1..*

0..*

1..*

0..*

++

++

SourceNode

SourceNode

CorrespondenceNode

CorrespondenceNode

TargetNode

TargetNode ++

++

Fig. 6. Prototypical structure of TGG rules in our implementation

As mentioned in [20,24] errors in a rule-based implementation often arise be-cause of dependencies. Rule dependency coverage then describes how many ofthese dependencies are covered by test suite. In particular, TGG rules mightcreate relations between source and target elements depending on the existenceof another relation between specific source and target elements (these rules aresaid to be in a produce-use relation accordingly). For the corresponding forwardrules in the implementation, this means that specific source elements shouldbe translated only if some related source elements have been translated beforealready. For example, rule 2 in Fig. 3 depends on the axiom and rule 1. It ispossible to find out these dependencies statically on specification level usingAGG [4] and systematically generate test cases covering them. For efficiency

8 In principle, TGGs exist in which specific rules are never applicable. For these kindof inconsistent TGGs the rule coverage criterion will never be fulfilled.


reasons, we implemented a simple dependency detection algorithm that exploitscertain TGG rule properties specific to our TGG implementation summarizedby the prototypical structure shown in Fig. 6. Amongst other criteria, this pro-totypical structure is required to ensure deterministic transformations [15] and,moreover, allows us to implement specific optimizations. Due to the fact that allmodel elements are connected to a single correspondence node, we can computedependencies based on the produce-use relation between correspondence nodetypes only. This leads to an over-approximation because dependencies might bedetected that do not really exist.

Implementation coverage considers the concrete model transformation im-plementation of the TGG and computes for a given set of test cases which parts ofthe implementation have been covered when executing the test cases. This infor-mation helps to find out, whether all relevant parts of the TGG implementationare covered by the test cases. Our implementation (see Fig. 5) is model-based(story diagrams) and we have a TGG Engine triggering the interpretation ofthese models by surrounding code. Therefore, we consider two kinds of coverage:Story diagram coverage and code coverage.

Story Diagram Coverage: The story diagrams generated by the Operational RulesGenerator contain large parts of the model transformation algorithm, e.g., forbookkeeping of transformed elements, detecting inconsistencies in the input mod-els, optimizing rule application. A detailed measurement of story diagram cov-erage shows whether a test case covers all relevant parts of the story diagrams.Some coverage criteria for Activity Diagrams are described by Chen et al. [7],e.g., activity coverage, which is the ratio between checked activities and all activ-ities in the activity diagram, and transition coverage, which is the ratio betweenchecked transitions and all transitions in the activity diagram. Story diagramcoverage as used here is the ratio between all executed elements (i.e., activitiesand transitions as well as nodes and links of graph transformation rules) andthe total number of elements in all executed story diagrams of a transformationdirection.

Code Coverage: Elaborate code coverage techniques have been developed alreadyin the past decades. We use the code coverage tool EclEMMA9 to measure state-ment coverage of the TGG Engine. Here, we cannot expect full code coverage,since the TGG Engine contains code, e.g., for executing model transformationsvia the GUI, or executing a specific transformation direction, respectively.

4 Testing Our TGG Implementation and Evaluation

We have executed conformance test cases for three different TGGs, which rep-resent typical uses of model transformations: Model-to-model transformations(SDL2UML), model-to-text transformations (Automata2PLC), and a large prac-tical model transformation from an industrial project (SystemDesk2AUTOSAR).The SDL2UML TGG is a slightly more complex version of the TGG presented in

9 http://www.eclemma.org/

http://www.eclemma.org/


Fig. 3. The TGG contains six rules, where the largest rules contain 17 nodes. Au-tomata2PLC [14] is a transformation from automata models to abstract syntaxtrees (AST) of a language for programmable logic controllers (PLC). It con-sists of five rules with up to 20 nodes in a rule. In contrast to the other twotransformations, which are bidirectional, this transformation can only transformfrom automata to PLC models but not reverse. The SystemDesk2AUTOSARtransformation [18] was created in an industrial research project. It transformsmodels from the modeling tool dSPACE SystemDesk to AUTOSAR, a standard-ized modeling language in the automotive domain. This transformation consistsof 50 rules and the largest of them contain 31 nodes.

Test cases were generated with 10, 100, and 1000 random rule applications.TGG rules are creating, therefore the test model size correlates to the number ofrule applications. For example, the rules of SDL2UML TGG create one elementin the SDL model and five elements in the UML model on average. Therefore,1000 random rule applications of that TGG lead to an SDL model with 1000elements and a UML model with about 5000 elements. Five test cases weregenerated for each of the three numbers of rule applications, each TGG, andeach possible transformation direction. From each group of five test cases thetest case with the highest rule coverage was selected for further execution. Thisamounts to a total of 15 executed test cases. Executing a test case with 1000 ruleapplications takes about two minutes on an Intel i5 750 CPU with 2.67 GHz. Thesmaller test cases take less then a minute. For the two smaller TGGs, we couldeasily achieve complete rule and dependency coverage, even for the smallest testmodels. However, for the very large SystemDesk2AUTOSAR TGG, we couldnot achieve complete specification coverage. Rule coverage for test models with10 rule applications was only 37% and went up to 71% (both directions) for thetest models with 1000 rule applications. Dependency coverage was only 19% forthe largest test models. The SystemDesk2AUTOSAR TGG contains many ruleswith quite complex preconditions. For some of them, it is rather improbable tocreate a triple graph satisfying the required precondition with a purely randomapproach. Therefore, specification coverage increases with a higher number ofrule applications, but is still far from complete coverage. Here, a systematicapproach (possibly making use of model checking [13]) to generate test modelswould be required.

For the SDL2UML TGG, we achieved a story diagram coverage of 82% forthe largest test models. Story diagram coverage of the Automata2PLC TGG is97% for all test models. Like specification coverage, story diagram coverage ofthe SystemDesk2AUTOSAR TGG was rather low, only 36% for the largest testmodels. Naturally, story diagram coverage is connected to specification coverage,because the story diagrams can only be completely executed if specificationcoverage is complete. In addition, the generated story diagrams contain codefor error handling, which is never executed in the test cases. Therefore, storydiagram coverage of the SDL2UML and Automata2PLC TGGs can only beimproved with test cases using faulty input models (negative testing).


Code coverage of the TGG Engine (49%) is quite constant over all test cases.When looking into detail, we can see that all code parts of the TGG Engine thatare relevant to the test cases are covered.

The results of the test cases indicate, that the SDL2UML TGG and its im-plementation are indeed conform, because EMFCompare did not find any differ-ences between transformed and expected target models. The test cases for theother two TGGs failed indicating that complete conformance with their imple-mentations could not be shown, mainly because of domain-specific technicalitiesnot covered by TGG formalizations so far. Until now, we did neither find errorsrelated to the faulty interpretation of formal concepts for TGG operationaliza-tions nor for optimizations augmenting efficiency of the model transformationexecution.

In the Automata2PLC test case, we discovered that the transformation doesnot maintain the order of model elements in references. The TGG Implementa-tion creates target elements in a different order than the Test Model Generator,which is reported by EMFCompare. This is not a problem for models withoutordered references. However, in the PLC target model all references are orderedreferences. The PLC model is an abstract-syntax tree of a textual language. Theorder of the elements in the syntax tree directly reflects the order of the corre-sponding text blocks of the textual syntax. Therefore, this order is relevant like inmost other textual languages. The Automata input model does not have orderedreferences. It consists of states connected by transitions. For the PLC model, wehave to derive an order in some way. However, there is no formalization of TGGstaking ordered references into account.

The SystemDesk2AUTOSAR test cases revealed another subtle problem inthe forward and backward directions. For example, SystemDesk models containa Library element, which does not have a counterpart in AUTOSAR (this prob-lem occurs in several places, not just with Libraries, and it also occurs in theopposite direction, i.e., there are elements in AUTOSAR that do not have a di-rect counterpart in SystemDesk). While all elements in SystemDesk must havea UUID (universally unique identifier), each Library gets a new random UUIDwhen it is created. Of course, the Library in the expected target model has adifferent UUID than the Library element in the transformed target model. There-fore, EMFCompare reports a difference between both models, although they areotherwise identical. One can argue that this transformation is not deterministicbecause it creates random UUIDs in the target model. One idea to overcome thisproblem would be to assign a static UUID for the Library in the TGG rule thatcreates it. However, this is not an option in practice because then the Library’sUUID would not be universally unique anymore, which would cause problems inthe modeling tools. Therefore, another idea is to derive the Library’s UUID fromthe source model in some way to achieve determinism. However, a proper way todo that has yet to be defined. Another possibility is to adapt EMFCompare sothat it ignores UUIDs for Library (and other affected) elements. However, thisadaptation of the test framework would be specific to these models. Summariz-ing, the concepts of UUIDs as well as ordered references should be considered


by TGG formalizations such that conform TGG implementations can be builtproperly. Existing TGG formalizations are defined on attributed graphs. Onthe contrary, models are based on metamodeling standards like MOF or EMFincluding additional concepts specific to the technical modeling domain.

Finally, we still have the following limitation of the test framework: The exam-ple TGGs that we tested only contain string attributes without complex attributecomputations. During generation of the input and expected target models, theseattributes are set to arbitrary values. For complex data types and attribute com-putations, more complex techniques like classical data partitioning techniqueshave to be integrated with the Test Model Generator. Especially, if the attributes’values have to satisfy certain constraints.

5 Related Work

Compiler testing as oldest line of related work is based on the grammar-basedgeneration of test data. [23] gives a survey on compiler testing methods andpresents a number of coverage criteria. The rule coverage criterion is the mostbasic one and we use this coverage criterion as an orientation in our grammar-based generation of input test models for TGG implementations (see Section 3).

There is some work on validating and verifying relational (or declarative)model transformation specifications themselves (e.g., [6,27]). In this work, weassume that the specification has been validated and aim at testing conformanceof the specification with its implementation.

A number of conformance testing approaches relying on graph transformationas a specification technique exist [9,20,2]. Instead of focusing on model trans-formation specifications and implementations, they are rather concerned withconformance testing of behavioral specifications w.r.t. (actual) behavior in re-fined models or (generated) code.

There are a number of testing approaches proposed for model transformationimplementations. Most black-box methods are concerned with generating(as e.g., [33,8,12]) qualified test input models taking into consideration the inputmetamodel (and corresponding constraints). For example, in [12] meta-model cov-erage is considered using data-partitioning techniques. It is required, for example,that models must contain representatives of association ends, which differ in theircardinalities. On the contrary, [24] proposes white-box criteria to qualify test in-put models. We concentrate on generating conformance test cases using the modeltransformation specification as an ”executable contract” generating not only testinputmodels, but also expected results obtaining a complete oracle. [3,28] mentionthat, in general, describing the oracle is a difficult task because even simplest ex-pected results may become quite complex. The availability of formal requirementsfor the model transformation is desirable and can be used for building the oracle.In particular, [10] presents an approach for specifying MOF-based metamodelsand their interrelationships, model transformation specification, implementationand test case generation using constructive logic. [10] uses the specification as par-tial oracle and does not generate expected results as we do. Moreover, it proposes


a new uniform framework, whereas we rely on TGGs as existing model transfor-mation specification technique for which several tools are already available.


We have presented and evaluated an approach to automatic conformance testingfor optimized TGG implementations. The grammar character of TGGs is usedto generate test cases including expected results. We are confident that ourapproach is a good basis to develop automatic conformance testing also for otherrelational specification techniques.

As future work we consider a number of extensions to this approach. (1) OurTGG implementation supports not only batch model transformations, but alsomodel synchronization. We would like to develop an automatic conformance testapproach also for the latter case. (2) Since we concentrate on positive testing,the approach should be extended to negative testing to find out if a TGG im-plementation handles inconsistent input models in a reasonable way. This is nottrivial, since parsing would be involved to find out if a model would be an in-consistent input according to the TGG. (3) As in the approaches for generatingtest input models based on the source metamodel of a model transformation, itwould be interesting to integrate metamodel constraints. Certain models con-sistent according to the TGG are potentially inconsistent w.r.t. the metamodelconstraints and become negative test input models. (4) We have described firsttest case generation strategies and coverage criteria. We plan to apply mutationtesting or more systematic generation strategies (possibly making use of modelchecking) to qualify test cases. (5) As mentioned in the introduction, our aim isto generalize this automatic test approach to other relational model transforma-tion approaches such as QVT Relational.

Acknowledgement. We thank the anonymous reviewers for their valuablecomments.

References

1. Amelunxen, C., Klar, F., Konigs, A., Rotschke, T., Schurr, A.: Metamodel-basedtool integration with MOFLON. In: ICSE 2008, pp. 807–810. ACM Press (2008)

2. Baldan, P., Konig, B., Sturmer, I.: Generating Test Cases for Code Generatorsby Unfolding Graph Transformation Systems. In: Ehrig, H., Engels, G., Parisi-Presicce, F., Rozenberg, G. (eds.) ICGT 2004. LNCS, vol. 3256, pp. 194–209.Springer, Heidelberg (2004)

3. Baudry, B., Ghosh, S., Fleurey, F., France, R., Le Traon, Y., Mottu, J.M.: Barriersto systematic model transformation testing. Communications of the ACM 53, 139–143 (2010)

4. Biermann, E., Ermel, C., Lambers, L., Prange, U., Runge, O., Taentzer, G.: In-troduction to AGG and EMF Tiger by modeling a conference scheduling system.International Journal on Software Tools for Technology Transfer 12(3-4) (2010)


5. Burmester, S., Giese, H., Niere, J., Tichy, M., Wadsack, J.P., Wagner, R., Wende-hals, L., Zundorf, A.: Tool integration at the meta-model level within the FUJABATool Suite. International Journal on Software Tools for Technology Transfer 6(3),203–218 (2004)

6. Cabot, J., Clariso, R., Guerra, E., de Lara, J.: Verification and validation of declar-ative model-to-model transformations through invariants. Journal of Systems andSoftware 83(2), 283–302 (2010)

7. Chen, M., Mishra, P., Kalita, D.: Coverage-driven automatic test generation forUML Activity Diagrams. In: Proceedings of the 18th ACMGreat Lakes Symposiumon VLSI, pp. 139–142. ACM (2008)

8. Ehrig, K., Kuster, J.M., Taentzer, G., Winkelmann, J.: Generating Instance Modelsfrom Meta Models. In: Gorrieri, R., Wehrheim, H. (eds.) FMOODS 2006. LNCS,vol. 4037, pp. 156–170. Springer, Heidelberg (2006)

9. Engels, G., Guldali, B., Lohmann, M.: Towards Model-Driven Unit Testing. In:Kuhne, T. (ed.) MoDELS 2006. LNCS, vol. 4364, pp. 182–192. Springer, Heidelberg(2007)

10. Fiorentini, C., Momigliano, A., Ornaghi, M., Poernomo, I.: A Constructive Ap-proach to Testing Model Transformations. In: Tratt, L., Gogolla, M. (eds.) ICMT2010. LNCS, vol. 6142, pp. 77–92. Springer, Heidelberg (2010)

11. Fischer, T., Niere, J., Torunski, L., Zundorf, A.: Story Diagrams: A New GraphRewrite Language Based on the Unified Modeling Language and Java. In: Ehrig,H., Engels, G., Kreowski, H.-J., Rozenberg, G. (eds.) TAGT 1998. LNCS, vol. 1764,pp. 296–309. Springer, Heidelberg (2000)

12. Fleurey, F., Steel, J., Baudry, B.: Validation in model-driven engineering: Testingmodel transformations. In: First International Workshop on Model, Design andValidation, pp. 29–40. IEEE Computer Society (2004)

13. Fraser, G., Wotawa, F., Ammann, P.E.: Testing with model checkers: A survey.Software Testing, Verification and Reliability 19(3), 215–261 (2009)

14. Giese, H., Glesner, S., Leitner, J., Schafer, W., Wagner, R.: Towards verified modelto code transformations. In: Proc. of the 3rd Workshop on Model Design andValidation. ACM/IEEE, Genova, Italy (2006)

15. Giese, H., Hildebrandt, S., Lambers, L.: Toward bridging the gap between formalsemantics and implementation of triple graph grammars. Tech. Rep. 37, HassoPlattner Institute at the University of Potsdam (2010)

16. Giese, H., Hildebrandt, S., Lambers, L.: Toward bridging the gap between formalsemantics and implementation of triple graph grammars. In: Lucio, L., Vieira, E.,Weißleder, S. (eds.) Proceedings of Models Workshop on Model-Driven Engineer-ing, Verification and Validations, pp. 19–24. IEEE Computer Society (2010)

17. Giese, H., Hildebrandt, S., Seibel, A.: Improved flexibility and scalability by in-terpreting story diagrams. In: Magaria, T., Padberg, J., Taentzer, G. (eds.) Pro-ceedings of the 8th International Workshop on Graph Transformation and VisualModeling Techniques. Electronic Communications of the EASST, vol. 18 (2009)

18. Giese, H., Hildebrandt, S., Neumann, S.: Model Synchronization at Work: KeepingSysML and AUTOSAR Models Consistent. In: Engels, G., Lewerentz, C., Schafer,W., Schurr, A., Westfechtel, B. (eds.) Graph Transformations and Model-DrivenEngineering. LNCS, vol. 5765, pp. 555–579. Springer, Heidelberg (2010)

19. Greenyer, J., Kindler, E.: Comparing relational model transformation technologies:Implementing Query/View/Transformation with triple graph grammars. Softwareand Systems Modeling 9(1), 21–46 (2010)

20. Heckel, R., Mariani, L.: Automatic Conformance Testing of Web Services. In: Ce-rioli, M. (ed.) FASE 2005. LNCS, vol. 3442, pp. 34–48. Springer, Heidelberg (2005)


21. Hermann, F., Ehrig, H., Golas, U., Orejas, F.: Efficient analysis and execution ofcorrect and complete model transformations based on triple graph grammars. In:Proceedings of the 1st International Workshop on Model-Driven Interoperability,pp. 22–31. ACM (2010)

22. Kindler, E., Wagner, R.: Triple graph grammars: Concept, extensions, implemen-tations and application scenarios. Tech. rep., Software Engineering Group, Depart-ment of Computer Science, Universitat Paderborn (2007)

23. Kossatchev, A.S., Posypkin, M.A.: Survey of compiler testing methods. Program-ming and Computer Software 31, 10–19 (2005)

24. Kuster, J.M., Abd-El-Razik, M.: Validation of Model Transformations – First Ex-periences Using a White Box Approach. In: Kuhne, T. (ed.) MoDELS 2006. LNCS,vol. 4364, pp. 193–204. Springer, Heidelberg (2007)

25. de Lara, J., Vangheluwe, H.: Using AToM3 as a Meta-CASE environment. In:International Conference on Enterprise Integration Systems (2002)

26. Lin, Y., Zhang, J., Gray, J.: Model comparison: A key challenge for transformationtesting and version control in model driven software development. In: Control inModel Driven Software Development. OOPSLA/GPCE: Best Practices for Model-Driven Software Development, pp. 219–236. Springer (2004)

27. Lin, Y., Zhang, J., Gray, J.: A testing framework for model transformations. In:Beydeda, S., Book, M., Gruhn, V. (eds.) Model-Driven Software Development, pp.219–236. Springer (2005)

28. Mottu, J.M., Baudry, B., Traon, Y.L.: Model transformation testing: Oracle issue.In: Proceedings of the 2008 IEEE International Conference on Software TestingVerification and Validation Workshop, pp. 105–112. IEEE Computer Society (2008)

29. Object Management Group: MOF 2.0 QVT 1.0 Specification (2008)30. Richardson, D., O’Malley, O., Tittle, C.: Approaches to specification-based testing.

In: Kemmerer, R. (ed.) Proc. of the ACM SIGSOFT 1989 Third Symposium onSoftware Testing, Analysis, and Verification, pp. 86–96. ACM Press (1989)

31. Schurr, A.: Specification of Graph Translators with Triple Graph Grammars. In:Mayr, E.W., Schmidt, G., Tinhofer, G. (eds.) WG 1994. LNCS, vol. 903, pp. 151–163. Springer, Heidelberg (1995)

32. Schurr, A., Klar, F.: 15 years of Triple Graph Grammar: Research Challenges, NewContributions, Open Problems. In: Ehrig, H., Heckel, R., Rozenberg, G., Taentzer,G. (eds.) ICGT 2008. LNCS, vol. 5214, pp. 411–425. Springer, Heidelberg (2008)

33. Sen, S., Baudry, B., Mottu, J.-M.: Automatic Model Generation Strategies forModel Transformation Testing. In: Paige, R. (ed.) ICMT 2009. LNCS, vol. 5563,pp. 148–164. Springer, Heidelberg (2009)

34. Toulme, A.: Presentation of EMF Compare utility. In: Eclipse Modeling Sympo-sium 2006, pp. 1–8 (2006),http://www.eclipsecon.org/summiteurope2006/index.php?page=detail/&id=6

http://www.eclipsecon.org/summiteurope2006/index.php?page=detail/&id=6

Author Index

Aksit, Mehmet 105

Buchmann, Thomas 198

de Lara, Juan 19, 35Drewes, Frank 182

Ermel, Claudia 81Ermler, Marcus 153

Furst, Luka 121

Galvao, Ismenia 105Giese, Holger 238Greenyer, Joel 222Guerra, Esther 19, 35

Hildebrandt, Stephan 238Hoffmann, Berthold 182

Jurack, Stefan 3

Klopper, Benjamin 137Kocsis, Zsolt 1Kreowski, Hans-Jorg 153Kuske, Sabine 153

Lambers, Leen 238Lamo, Yngve 19

Mahnic, Viljan 121Maier, Sonja 89Mantz, Florian 3

Mazanek, Steffen 97Mernik, Marjan 121Minas, Mark 65, 89, 97, 182

Patzina, Lars 210Patzina, Sven 210Petrick, Dominic 238Proctor, Mark 2

Rensink, Arend 105Richter, Ingo 238Rieke, Jan 222Rossini, Alessandro 19Runge, Olga 81Rutetzki, Christian 97Rutle, Adrian 19

Scholer, Florian 51Steinhage, Volker 51Strecker, Martin 169Strobl, Torsten 65

Taentzer, Gabriele 3, 81Tichy, Matthias 137

von Totth, Caroline 153

Westfechtel, Bernhard 198Wevers, Lesley 105Winetzhammer, Sabine 198

Zambon, Eduardo 105

[lecture notes in computer science] applications of graph transformations with industrial relevance...

Documents