Graph transformations and software engineering: Success stories and lost chances

Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

Contents lists available at SciVerse ScienceDirect

Journal of Visual Languages and Computing journal homepage: www.elsevier.com/locate/jvlc

Graph transformations and software engineering: Success stories and lost chances$ Giovanni Toffetti a,n, Mauro Pezze a,b a b

University of Lugano, Switzerland University of Milano Bicocca, Italy

a r t i c l e i n f o

Keywords: Graph transformation Software engineering Model Model transformation Visual language Dynamic system Evolving system

abstract Textual as well as visual and diagrammatic notations are essential in software engineering, and are used in many different contexts. Chomsky grammars are the key tool to handle textual notations, and find many applications for textual languages. Visual and diagrammatic languages add spatial dimensions that reduce the applicability of textual grammars and call for new tools. Graph transformation systems have been studied for over 40 years and are a powerful tool to deal with syntax, semantics and transformation of diagrammatic notations. The enormous importance of visual and diagrammatic languages and the strong support that graph transformation provide to the manipulation of diagrammatic notations would suggest a big success of graph transformation in software engineering. Graph transformation systems find their application both as language generating devices and specification means for system evolution, and thus can have many applications in software engineering. In this paper we discuss the main features of graph transformation and how they can help software engineers. We look back to the many attempts to use graph transformations in software engineering in the last 15 years, identify some success stories, and discuss to what extent graph transformation succeeded, when they have not succeeded yet, what are the main causes of failures, and how they can help software engineering in the next 15 years. & 2012 Elsevier Ltd. All rights reserved.

1. Introduction Informatics is about information and its representation. Both scientists and practitioners use many textual and diagrammatic notations to represent any kind of concept, from data to models, all the way to programs and computation. Understanding and defining notations is essential to use them properly, and formal languages are the best means to avoid ambiguities and misinterpretations, and

$ This paper has been recommended for acceptance by Shi Kho Chang. n Corresponding author. Tel.: þ 41 58 666 4300. E-mail addresses: [email protected] (G. Toffetti), [email protected] (M. Pezze ).

enable automatic information processing. Formal string grammars that Chomsky studied since the fifties are the most common way to specify the infinite set of all valid statements (the syntax) of textual (sequential) languages. As such, to name but one important application, they play a fundamental role in compilers. Diagrammatic notations introduce new dimensions beyond the sequential successor relation that characterizes textual notations, and classic Chomsky grammars cannot capture these new dimensions. In the context of diagrammatic representations, the simplest and most natural abstraction is a graph, and graph grammars, or more generally graph transformation, are the most suitable specification for diagrammatic languages (graphs). As stated by Heckel: ‘‘Graph transformation has originally

1045-926X/$ - see front matter & 2012 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.jvlc.2012.10.003

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

2

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

evolved in reaction to shortcomings in the expressiveness of classical approaches to rewriting, like Chomsky grammars and term rewriting, to deal with non-linear structures’’ [1]. Graphs are particularly suited for modeling and representing many structured and dynamic contexts, for instance software architectures, distributed communications, call graphs and many more. Graph transformation systems are not only an intuitive way to represent the syntax of graphs, but also to formalize how graphs evolve. As stated by Ehrig et al.: ‘‘Graph transformation allows one to model the dynamics in all these descriptions, since it can describe the evolution of graphical structures’’ [2]. Research on graph transformation started over 40 years ago, and right from its inception identified the main application directions. In 1969, Pfaltz and Rosenfeld gave the first examples of classes of graph grammars, called Web grammars, setting the path to using graph grammars as formal specifications of diagrammatic languages [3]. In 1971, Pratt addressed string to graph language mappings with pair grammars, paving the way to the coming generalization of pair grammars into triple grammars [4] and their application to model transformation [5]. Finally, in 1973, Ehrig et al. introduced the algebraic approach to graph transformation, which has proven a fundamental instrument in studying and demonstrating several properties of graph transformation systems [6]. Further application areas and methodologies were identified early on, both applying graph transformation in a generative and in an analytic approach. For example in the 1980s, Dolado and Torrealda used a generative ¨ approach to generate Forrester diagrams [7], while Gottler proposed a generative approach to automatically derive diagram editors from graph transformation [8], becoming a cornerstone for many more approaches to develop domain-specific languages together with their editors and CASE tools. On the other end, Bunke proposed an analytic application of graph transformation to ‘‘read’’ diagrammatic notations (interpreting diagrams and flowcharts) [9]. The 1990s saw the interest in graph transformations spreading to other communities that applied graph transformation in different fields, such as software architectures [10,11] and reconfiguration for fault tolerance [12] to name a few. Over 40 years of theoretical and applied research have shown the efficacy and the limits of graph transformation systems. Graph transformation systems are an essential tool to formally define diagrammatic languages, find many applications in informatics, and are widely accepted in the academic community. However, notwithstanding a constant effort from the graph transformation community to promote industrial acceptance with dedicated workshops and symposia, for example the series GraphGrammars and Their Application to Computer Science, widespread application of graph transformation in common practice is still lacking. In this paper we discuss the impact of graph transformation on software engineering. We do not aim to survey all the relevant applications of graph transformation to software engineering, but we focus on identifying the way

graph transformation can be used in software engineering looking at a set of key application areas. We illustrate the different way of using graph transformation by discussing some sample work and analysing the key elements of success and the reasons behind the lack of wide adoption so far. The next section introduces graph transformation to make the paper self contained. Section 3 discusses the role that graph transformation has played in software engineering. Section 4 illustrates the suitability of graph transformation in software engineering by presenting few sample cases. Section 5 discusses the impact of graph transformation in academia and in industry. Section 6 concludes and discusses the future of graph transformation in software engineering. 2. Graph transformation in a nutshell Graph transformations have been defined in many ways with different notations to represent concepts such as rules, matching and gluing models, application conditions and more. In this section we summarize the main elements of graph transformation referring to the intuitive presentation of Heckel [1] using the PacMan video game as an example. The interested readers can find a clear introduction and classification of graph transformation systems in the paper by Blostein et al. [13] and a complete and formal definition in the ‘‘Handbook of graph grammars and computing by graph transformation’’ by Rozenberg and Ehrig [14]. Graph transformation defines transformations over graphs by means of rules. A graph is a set of nodes and (directed or undirected) edges. Both nodes and edges can be typed to represent different concepts, for example a person or an object, and can have attributes, defined as name and value pairs [1]. A very expressive way to define types is by means of another graph, called type graph. A type graph is a graph that represents the types of nodes and edges, their attributes, and what is considered valid in an instance graph based solely on type information and cardinality. For instance, Fig. 1 shows the relationships between a particular situation in the PacMan game (labelled ‘‘snapshot’’) and its representation as a graph (labelled ‘‘instance graph G’’) that correspond to the generalization and typing relationships between the ‘‘concepts’’ in the game and the type of nodes and edges in

Fig. 1. Instance and type graph from Heckel [1].

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

‘‘type graph TG’’. A type graph typically contains a single instance of node per type, while edges represent both edge types, the types of nodes they can connect, and the allowed cardinality. The type graph in Fig. 1 states that the graph of the game is composed of a number of connected fields, that instances of ‘‘Ghost’’, ‘‘Marble’’, and ‘‘PacMan’’ can have only a single edge towards a field (indicating the fact that they may occupy only a single position at a time in the gameboard), and that PacMan has an attribute named ‘‘marbles’’ of type int. Montanari et al. give another clear and practical example of type graphs applied to Entity-Relationship modeling [15]. Once the types of nodes and edges are defined, we can define the rules, also called productions, that represent the core of graph transformation systems. A rule is composed of a left-hand side (LHS) and a right-hand side (RHS). The LHS indicates the pre-conditions for applying the rule, while the RHS indicates the post-conditions. A rule can be applied to a graph when the LHS matches a subgraph (through a morphism in the graph category), and the application of the rule replaces the matched subgraph with the RHS of the rule. Fig. 2 shows an example of rule (top of the figure) taken from [1]. The LHS of the rule is the graph L and the RHS is the graph R. Partial morphism p ties nodes and edge instances in the LHS with the corresponding graph elements in the RHS, for instance, field f1 in the LHS with field f1 in the RHS. The bottom part of the figure shows the application of the rule to transform the graph G into H. The matching elements of LHS and G are represented by the mapping OL, where O stands for ‘‘occurrence’’. The rule is applied in three main steps: match the LHS to a subgraph of G, modify G by deleting all the elements of the matched subgraph that are not preserved in RHS (LHS\RHS), modify G by adding the new elements introduced by RHS (RHS\LHS) obtaining H. Deleting a subgraph (step 2) may leave dangling edges, that is, edges not connected to two nodes, and hence produce invalid graphs. A common solution to this problem is to augment the rules with a graph K that indicates elements that must exist in the graph to apply the rule and are preserved by the application of the rule, thus preventing edges from remaining partially disconnected during the application of the rule. The graph K is called interface graph and the approach is called double-pushout approach (DPO) [6]. In DPO the match between the rule

3

and instance graphs has to maintain the gluing condition satisfying both single conditions: 1. identification condition: two elements x and y of L may only be mapped not injectively if they will be preserved by the rule; 2. dangling condition: if a node is deleted, all its adjacent edges are deleted. The rule in Fig. 2 is an example of the Single Pushout approach (SPO), which uses direct derivation without interface graph. SPO is more expressive than DPO, but less structure preserving, as it is easier to delete edges. Rules can be applied directly to a specific subgraph, when the users specify the rule to apply and the matching to be used or undirectly to the whole graph, when rules are applied in any order, until no further rules apply. Another common solution is to organize rules into ordered layers: for each layer rules are applied repeatedly until no further matchings are possible. The expressiveness of graph transformation has been enhanced with several extensions, the most common being constraints and (negative) application conditions. Application conditions (ACs) and negative application conditions (NACs) specify either the context in the graph that must (AC) or must not (NAC) be matched, respectively. ACs and NACs are powerful constraints at rule level that allow more complex specifications than type graphs when reasoning at the instance-level. For example, imagine we want to design a simple grammar to build a generic network topology (nodes, links) with one condition: each pair of nodes should be connected by at most one link. We would need only two rules: one (R1) to create nodes (empty LHS, a single node in the RHS), and another (R2) to connect previously unconnected nodes. The LHS of the rule R2 is composed of two nodes, its RHS contains the same two nodes connected with a new link, and the NAC would be equal to the RHS, preventing the application of the rule to two already connected nodes. The key characteristics of application conditions is that the context to which they refer can be arbitrarily far from the nodes to which the rule is applied, allowing the designer of the rule to specify elaborated conditions. Some popular tools, such as PROGRES,1 further enhance the expressive power of rules and conditions by set nodes and paths. Set nodes, also called multi-objects, are used as a short-hand notation to represent a set of rules in which the set node appears one or more times. This allows to specify for example rules that delete all the instances of a give node type. Paths indicate sequences of directed edges of arbitrary length, and allow to represent concepts such as for instance multi-hop connectivity in graphs. 3. Graph transformation in software engineering Graphs are a natural visual representation of structured information, With nodes modeling entities and

Fig. 2. Rule and application from Heckel [1].

1 http://www-i3.informatik.rwth-aachen.de/tikiwiki/tiki-index.php? page=Research:þ Progres.

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

4

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

(hyper) edges (n-ary) relationships among entities, they provide a simple visual abstraction of the reality. In particular, they provide a powerful means to represent nodes and edges with types, attributes, and composition constraints. In software engineering, modeling is a basic tool used at all abstraction levels and during the whole software development process. Models and in particular diagrammatic models based on graphs are used to represent and analyze software procedures, processes, components, functioning, architectures, interactions, as well as the entire software life cycle in its various phases and declinations, like re-factoring, testing, bug assignments, deployment and composition. Thus, graph transformation systems have a natural application in several areas of software engineering. Software engineers have exploited three main features of graph transformation systems: 1. their ability to provide an intuitive diagrammatic representation of modeling concepts [16], 2. their suitability to formally specify graph languages and mechanisms to guarantee that (or verify whether) a graph is a valid language production [17,18], and 3. their flexibility in modeling and reasoning about graph evolution through rules with the possibility to prove dynamic properties, for example by studying parallel/ sequential rule applications [19,20]. So far, graph transformation systems have been applied in various contexts: modeling several aspects of software and the software development process to prove, classify, reason over their characteristics; defining visual languages and their tools to produce domain-specific development environments, with focus on the syntax and the specification of the visual language; modeling transformations and mappings across notations and languages; checking and proving the consistency of dynamic systems with focus on the semantics and the dynamics of the systems (for instance, the different configurations over time and their representations). The paper by Blostein et al. provides a thorough analysis of the state of the practical use of graph rewriting systems up to 1996 [13]. At that time, despite the advantages in terms of abstraction, correctness and convergence, graph transformation systems had not attained widespread practical use. Blostein et al. identified as important factors hindering the industrial application of graph transformation in software engineering the lack of both education and tools with consequent lack of experimental data about the advantages of graph transformation in the field. In the last 15 years, the graph transformation community has produced a consistent amount of educational material, a series of symposia dedicated to practical uses of graph

transformation (AGTIVE), as well as a set of development tools that have moved from research prototypes to products used in industrial scale projects, like Fujaba. Blostein et al. identified also lack of graph rewriting system modularization, grammar evolution, and graph inspection support as key technical factors hindering the industrial applicability of graph transformation. These problems are grounded in the lack of design techniques and patterns, efficiency, appropriate choice of rule organization (i.e., graph grammars, unordered, ordered, and event-based graph rewriting systems), structure of large rule collections and common extensions to rewrite mechanisms (for instance application conditions and setrules). Notwithstanding the research effort, some of the considerations of Blostein et al. are still valid today, and are still affecting the industrial success of graph transformation. In the following section, we sample some applications of graph transformation to software engineering, highlighting how different features of graph transformation have been exploited in different contexts and discussing the limits of the solutions. 4. Application examples The many applications of graph transformation in software engineering exploit the ability of modeling both static and dynamic aspects of diagrammatic representation, the possibility of reasoning about model evolution and the ability of supporting visual languages and their semantics. In this section we present some examples of applications that exploit the different features of graph transformation. The examples represent applications in different fields and aim to indicate how graph transformation can meet different needs, without claiming neither completeness nor generality. 4.1. Modeling static and dynamic aspects While capturing the syntactic aspects of diagrammatic notations is quite simple, formally modeling and reasoning about the dynamic semantics of diagrammatic notations is difficult. Graph transformation represents well both static and dynamic aspects, as well as the interplay between syntax and semantics, and provides a powerful means to analyze the diagrams and their evolution. In this section we illustrate the ability of modeling both static and dynamic aspects referring to applications of graph transformation to software architecture styles and security. 4.1.1. Software architecture styles Software architecture styles constrain the freedom of software architects who shall follow specific conventions in identifying and composing subsystems and components. Designing architectures compliant with a given style requires the ability to enforce some rules that often reflect dynamically evolving constraints on diagrams. Graph transformation is an ideal means to define composition rules that can be dynamically adapted to new needs and requirements, and can be used to derive syntax

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

driven editors, analyze the compliance of architecture designs with a given style and define transformations to change architectural style. To represent and verify software architecture styles we need both a formal framework and a natural (graphical) way to express software design choices, features that characterize graph transformation. Le Metayer suggested to define entities (such as procedures, modules and processes) as graph nodes, communication links as edges, and the constraints that characterize the architecture style as graph transformation rules [11]. In Le Metayer’s approach, entities evolve by changing internal and public variables according to the semantics of the programming language, while a coordinator manages the architecture itself and maintains the consistency of the architecture style by adding and removing nodes and edges using conditional graph rewriting based on the values of public variables of the entities. In a nutshell, Le Metayer uses two sets of graph transformation rules. The ‘‘architectural style rules’’ define an architectural style in the sense that all architectures generated as derivations from the axiom yield some topological properties by construction. The ‘‘coordinator transformation rules’’ represent instead a dynamic view of the architecture, that is its evolution through the coordinator rewrite system. To prove that the coordinator maintains the properties of the architectural style at all times, a static verification of the coordinator rules can be obtained with respect to the architectural style grammar. The intuitiveness and formality of the notation, as well as the separation of the logic of the coordinator and the entities, support the definition and evaluation of properties of information flows for different architectural styles. The static verification algorithm works as follows. It first builds a reduction graph, which is defined as a cyclic graph in which the origin is the left hand side of a coordinator rule, the terminal node is the axiom of the architectural style grammar, and the internal nodes (called application contexts) are derived by applying the architectural style grammar reversed (switching the LHS with the RHS of each rule). It then checks whether the right hand side of the coordination rule in all the application contexts given by the reduction graph can be reduced to the axiom of the architectural style grammar. The two steps have to be applied for each coordination rule. Intuitively, this amounts to checking whether each

5

application of the coordinator rules preserves the architectural style properties of an architecture. Le Metayer clearly indicates the advantages of graph transformation for enforcing architectural styles and indicates the limitations of the approach: graph grammars reduce the complexity of the checks, but preclude some specifications of entity organizations (for instance, unbounded depth trees and square grids) as well as global conditions on the architecture due to the local nature of set rewriting. 4.1.2. Role-based access control Access control (AC) is a common security mechanism used to determine and enforce which entities (programs or users) can have access to objects, for example files or devices, and with which permissions, for example read, write or execute. Role-based access control (RBAC) uses the notion of roles assigned to users within an organization to eliminate or at least reduce the errors in AC managers. RBAC are defined as constraints over roles, role evolution and resource accesses. The set of constraints and the dynamics of RBAC can be extremely complex, and can evolve over time following changes in roles and access control policies. Consistency and completeness of access control rules are very important to prevent security leaks, but verifying that a complex set of evolving rules is consistent and complete is a hard problem. Koch et al. suggest that graph transformation can define formally and intuitively a set of RBAC constraints and can support automatic verification of important security properties [21]. Koch’s framework provides an intuitive visual description of AC in terms of graphs, an expressive specification language for different AC schemas, the specification of static and dynamic consistency conditions through graphs, and an executable specification that can leverage on existing tools to verify the properties of a graph-based RBAC description. The approach relies on a specific type graph as a first constraint for graphs representing RBAC. As shown in Fig. 3, the type graph models concepts such as users that can be associated to roles, and have sessions. Roles are associated to permissions on a set of objects. Hierarchies of roles are modeled with the semantics of (reverse) inheritance of permissions: For example a higher level role has a superset of the permissions of the lower level role. Negative application conditions (NACs) are used to limit

Fig. 3. A graphical specification of user-role, role-permission and permission-object assignment from [21].

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

6

the application of rules to guarantee some required properties (for example, a user can be member of at most one role, but can be authorized for a different role if the role is inherited from the role of assignment). Finally, rules with set nodes are used as a short-hand notation representing a set of rules in which the set node appears zero or more times, and the concept of path is used to represent a sequence of directed edges of arbitrary length. Graphs transformations can model common RBAC concepts and schemas, and support the proof of the correctness of a graph-based RBAC specification with respect to common consistency requirements, for example dynamic separation of duties can be specified as graphical constraints that are expressed as undesired subsystem states, and can be automatically verified. Given a rule r of the RBAC specification and a graphical constraint C, Koch’s algorithm derives a set of application conditions for r that guarantee its consistency with C. The algorithm works in three steps: (1) find all possible gluings of the RHS of r with C (if there are gluings it means the rule can alter a graph so that there is a match for C, hence there is an inconsistency); (2) apply r 1 (the inverse rule of r) to each gluing obtaining all the application conditions for r leading to inconsistency; and (3) prune application conditions by discarding the ones that are satisfied by C (that is the ones that are already inconsistent). The remaining application conditions are added as NACs to r preventing it from transforming a graph consistent with the graphical constraint C into an inconsistent graph with respect to C. 4.2. Model evolution The scale of development and the ubiquity of software increasingly require methodologies to assess and enforce software quality. With the aim to improve the software development process across all its phases, modeling techniques are being applied to represent and reason about several aspects and concerns, all the way from formal requirement collections to platform specifications, deployment and collaboration diagrams. Maintaining consistency across heterogeneous models at different abstraction levels is a difficult task. Model transformation systems represent a natural approach to deal with multi-models frameworks, and are increasingly applied in this context to automatically generate code from models, maintain the consistency across several notations when updating a model, map informal onto formal representations to be used for proving properties and for reflecting changes to the formal representation into the informal one. The most relevant contribution of graph transformation to model transformation are triple graph grammars (TGGs), which generalize Pratt’s pair grammars [5], and ¨ in 1994 [4]. TGGs aim to have been introduced by Schurr provide a mapping between different graphs that represent different modeling languages and notations and that can be used to automate model transformations. They are called triple because their rules consist of elements from three different (type) graphs: the source, the target, and the correspondence graphs, as shown in the example of

Fig. 4. TGG schema that defines a correspondence structure (center) between elements of class diagrams (left) and relational database schemata (right) (from [22]).

Fig. 4. The source and target graphs represent the notations to be mapped, while the correspondence graph acts as an explicit representation of the correspondence relations between elements of the source and target graphs. Any TGG can be compiled into a pair of forward and backward graph translations (respectively, FGT and BGT) that can then be used to transform a graph in the source language into a graph in the target language (FGT) and back (BGT). These feature makes TGG extremely appropriate to specify and implement mappings across software engineering models and artifacts. An interesting application of model transformation is the need of mixing informal and formal notations. The long debate between supporters of formal versus informal models indicate that we need both the ability of defining properties using formal models and the flexibility that is typical of informal models. Baresi and Pezze introduced an interesting application of pairs of graph transformation systems to support the on the fly generation of formal notations from evolving informal diagrams to combine flexibility and formality [16]. Practitioners can modify the semantics of informal diagrammatic notations by simply modifying graph transformation rules that adapt the formal models to the next interpretation. ¨ As discussed in a recent paper by Schurr and Klar, TGGs have found many practical applications, the most notable one being the OMG’s model transformation language QVT that adopted some fundamental ideas from TGGs [22]. Inefficient parsing, limited negative application condition semantics, lack of modularization, refinement, and reuse are still hindering the wide-spread application of TGGs. While some of these limitations have been addressed from the theoretical perspective in some recent works (e.g. [23,24]), a single implementation catering for all these issues is not available yet. 4.3. Visual languages Visual languages and in particular diagrammatic notations have been extensively used to represent complex models. The impossibility of matching the many needs of different application domains has triggered the interest in domain-specific languages, which are visual notations or full-fledged visual programming languages that concentrate on a clearly identified domain and its underlying assumptions to offer representations that are both compact and expressive for a specific problem domain [25]. Domain specific languages are applied in niche areas sometimes too small to justify the big effort required to design the visual language, define its semantics, and implement the associated editing tools. Providentially,

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

7

Fig. 5. Abstract and concrete syntax of visual languages from [18].

Fig. 6. Rule describing the insertion of an association class (dashed arrows represent the coupling between abstract and concrete syntax) (from [18]).

‘‘the syntax and static semantics of a visual language can be unambiguously defined using graph transformation’’ [26], and indeed several application of graph transformation with this purpose are common in literature. An extensive and rigorous exposition on the subject can be found in the work of Bardohl et al. [18]. The common definition of a visual language separates the concrete from the abstract syntax of the language, as depicted in Fig. 5. The concrete syntax represents the diagrammatic symbols, for example boxes, bubbles and arrows, from the spatial relations, for example containment, connection and positioning that are used in the visual notation. The concrete syntax of a visual language is usually given by means of a spatial relationship graph (SRG). The abstract syntax predicates on the concepts represented by the concrete symbols and relations, for example classes and relationships in a class diagram, and is commonly given as an abstract syntax graph (ASG). Fig. 6 shows an example of a visual language rule representing both the abstract (top) and the concrete syntax (bottom). Graph transformation systems can naturally specify both the SRGs and ASGs, and thus support the generation of parsers for newly defined visual languages. Bardohl et al. write ‘‘Despite the wide-spread usage of visual modeling ythere is a considerable lack of formalisms for defining their syntax and semantics. yAs a consequence, most published visual languages come with informal and imprecise definitions, and the development of their tools often requires far too many person years’’ [18]. Graph transformation can solve the problem and boost the use of domain specific visual languages.

The most popular editors generated from graph transformation systems support either syntax directed or freehand editing. Syntax directed editors offer a set of predefined editing operations that designers can use to create diagrams, while freehand editors provide parsers for diagrams that users can edit freely with any editing tool. The complexity of building efficient diagram parsers privileges syntax directed over freehand editors. Syntax driven editors can be either grammar- or transformation-based. Grammar-based editors specify the language independently from the editor using a grammar, while transformationbased editors define the language by means of the editing rules. Grammar-based approaches provide a more concise syntax definition, while transformation-based editors offer the possibility of modeling intermediate editing steps that might be invalid in the visual language syntax but are often needed to simplify the editing process,2 hence is the preferred solution. Recently, graph transformation approaches have been combined with meta-modeling solutions to specify visual language tools. An example is provided by de Lara et al. [17]. 5. Academic and industrial impact In the former chapter we sampled several applications of graph transformation that have been proposed in the 2 For example, in WebML [27] an operation unit is required to be triggered by an activating link, but the editing steps in the CASE tool include (1) create an operation unit and (2) add incoming/outgoing links. A warning mechanism is used after model editing to verify consistency.

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

8

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

last 15 years. The wide range of application fields and studies indicate that the scientific community believes in the possibility of overcoming the problems highlighted by Blostein et al. 15 years ago. Most of the work surveyed in the former chapter is still part of research projects, but there are some albeit few industrial success stories that indicate how graph transformation could move from research project to industrial best practice. Once for all, we would like to mention the project on mechatronics coordinated by the University of Paderborn that aims to develop a new generation transportation systems, in which unmanned, independent and lightweight trains combine each other into convoys to optimize the service offered to passengers [28]. The ambitious project has moved in a decade from visionary research to pre-competitive industrial prototype, and needs to deal with real time constraints in a hybrid embedded systems that shall evolve and self-adapt to different traffic and environmental condition. The project relies on graph transformation to describe and analyze the combination of heterogeneous components, the system evolution and the system self-adapting behavior [19]. As a side effect, the project has produced Fujaba, a CASE tool that supports model-based software engineering and re-engineering, and is based on graph transformation. Fujaba is the result of 15 years of development, the tool is mature and available for open use and for being applied to industrial scale projects. However, it seems that the applications of Fujaba to industrial problems are still academically driven, since the main applications are still either connected to university research projects or are purely academic. Taking a more general perspective, the need of methodologies to assess and enforce software quality is every day more clear, as software has become ubiquitous, and is influencing every moment of our lives. While modeling techniques and guidelines continuously gain wider acceptance in industrial practice, graph transformation systems are just starting to be directly applied to study program behaviour discovery and verification [29], and graph grammar inspired concepts have a relevant impact in model transformation and mapping, for example in model to model mapping and in code generation as mapping from models to code. Promising results are achieved by combining graph transformation, programming languages and mathematical modeling tools. The mutual effects that these different approaches have on each other contribute in advancing and improving the available tools and techniques. One notable example is the impact of triple graph grammars on OMG’s model transformation language QVT [22]. Moreover, graph transformation systems can be improved by adopting suitable external concepts. For instance, Legros et al. use graph rewriting rules to enforce modeling guidelines for the automotive industry. To reduce the number of rules in common scenarios, they extend graph transformation modularity by adopting programming language concepts such as generics and reflection [30]. However, also in these cases, graph transformations successfully influence tools and languages for practitioners (for example, as in QVT), but are not applied directly in wide practice.

5.1. Formal approaches in practice To shed light on the possible causes of the still limited industrial success of graph transformation, we recognize a typical development process of formal approaches from their inception to the adoption by a scientific community, discuss the impact of the approaches, and try to identify the factors that promoted or inhibited the successful transition to widespread industrial practice. If we examine formal methods popular in computer science, we can identify some common maturation steps. At first, a challenging set of problems raises the interest of one or few researchers, thus providing the seed for a new subject of study. Often enough, a seminal paper also proposes a first draft of notation and approach to formalize and reason about the problem at hand. A new area of research is born when the approach is deemed relevant by a scientific community, or, in other terms, when enough researchers believe that it is applicable and might solve a family of relevant problems, and researchers are willing to expand and improve it. Resistance to change by a scientific community is the first obstacle an approach needs to surmount to achieve academic adoption. Academic endorsement in a scientific community typically results in years of theoretical improvement, proofs, and several attempts to apply the approach to various problem instances. When the approach is perceived as mature, the research community tries to push it to beyond the boundaries of the specialized research area towards wider research interests and practical applicability. Effort is invested in training networks to attract researchers from other areas, and to illustrate the benefits of the approach, interdisciplinary links are sought, prototype tools to tackle tutorial use cases are designed and developed. If the approach succeeds in crossing the research field boundary and becomes a conceptual tool for different academic disciplines, publications in different areas spread the ideas triggering interest in the wider academic community. Still, more obstacles are on the way to achieve (industrial) impact. The academic community often identifies the causes for the unsuccessful industrial adoption of a well studied formal method in some common pitfalls: the steep learning curve, the theoretical limits that might reduce the benefits or hinder direct application to real life scenarios, the lack of software tools or available resources (for example, state space explosion) to tackle industrial problems and the lack of recognition of adoption advantages. Thus, academic communities typically focus on tools, blaming their prototype nature for the lack of diffusion or interest in a large user community. The underlying assumption is that industrial interest could provide the resource investment needed to bridge the gap between prototype software implementation and commercial tool development, and that mature tools are the enabling factor for practitioners’ adoption. We argue that often enough learning materials and tools are available and up to the task, but other catalysts are needed to trigger the industrial interest.

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

In the following we look at some relevant formal methods, with different degrees of adoption in practice, and we identify the availability of a killer application as the main catalyst that can foster industrial adoption or confine the interest to the formal method in a focused community only. Petri nets: Petri nets are a well know and widely used formal method that is well suited to model the concurrent behavior of distributed systems [31]. The extensive mathematical theory for process analysis that has been developed for Petri nets can prove important behavioral properties such as reachability, liveness, and boundedness. Several academic and industrial tools have been developed and are available for the specification and analysis of Petri nets that have been used in some relevant industrial projects, and Petri nets are generally taught in most computer science curricula [32,33]. Despite the availability of mature industrial tools, the documentation of some success stories and the strong educational support, Petri nets are not commonly adopted in industry, and are not more successful than graph transformation in this respect. Petri nets still miss a killer application, that is, an open and relevant problem that can be naturally and straightforwardly solved by means of Petri nets. Symbolic execution: Symbolic execution is a well studied program analysis technique that provides the essential bridge from the complexity of program behavior to the more orderly world of logic. It can determine the conditions under which a particular control flow path is taken, and can thus both identify infeasible program paths (those that can never be taken) and conditions to execute (possibly undesirable) paths. Symbolic execution has been used in several domains: (1) for proving properties of (small) critical sub-systems, such as a safety kernel of medical devices, (2) formally verifying critical properties (for example, security properties) that are particularly resistant to dynamic testing, and (3) formally verifying algorithm descriptions and logical designs that are much less complex than their implementations in program code. Despite the many application domains, symbolic execution found little practical application from the seventies, when it was first introduces till the late nineties. In the late nineties, Bush and Pincus adapted symbolic execution to the dynamic analysis of pointers. Their PREfix tool [34] successfully spread in industrial practice and is now included in the Microsoft Visual Studio suite. Pointer analysis is the first killer application that has promoted symbolic execution to an industrially applicable technique. Recently the combination of symbolic and concrete execution, also known as concolic execution [35], is finding an interesting industrial application in the formal proof of properties of device drivers. A strong theoretical framework, powerful tools and fast computers are key enabling factors, but the catalyst is a killer application. Formal (string) grammars: Formal grammars are a successful formal method in computer science, and the Chomsky hierarchy is well known to any CS student. Differently from Petri nets or Symbolic execution,

9

grammars have found their killer application in the design of programming languages and compilers from the very beginning. Anyone running a compiler is leveraging on formal grammars. End users do not usually see the grammars, and might even ignore their existence, but it is undeniable that formal grammars have a major impact on software, both in industry and research. Similarly, visual programming languages, their specifications, and the generation of editors from such specifications may seem the obvious killer application for graph transformation. Unfortunately, differently from programming languages, whose compilation into executable code is the main reasons of their existence, visual programming languages do not own their success to the ability of compiling them into executable code, and as such do not represent the killer application of graph transformation systems, yet. In fact high level programming languages and formal grammars were born to facilitate the design of executable code, while visual programming languages derive from the experience with specification and design languages that are not perceived as a mere abstraction over executable code. When visual languages will become a common programming tool and the bidimensional relation between elements of the languages will be the key semantic feature, graph transformation may be a strong competitor for industrial success. Relational model: Codd’s relational model [36] was devised as a solution to provide abstraction from internal representation, data independence, and consistency of data in large data stores. To achieve this, Codd proceeded in applying relation theory to shared data systems, providing a way of describing data with its ‘‘natural structure only’’, that is ‘‘independently of any additional superimposed structure for machine representation’’ (for instance, ordering, indexing). In his seminal paper, Codd formalizes the relational model, introduces normalization and the most common operations (for example, selection, projection, join) of relational algebra. Relational databases are today a ubiquitous technology that can be found anywhere from data center all the way to smart phones. Surprisingly, acceptance of the approach has been far from simple. In fact, the relational model was the target of skepticism mainly due to its formal origin: ‘‘Instead of welcoming a theoretical foundation as providing soundness, the attitude seems to be: if it’s theoretical, it cannot be practical’’ [37]. To win industrial acceptance of the relational model, in his Turing award lecture, Codd provided a convincing illustration of the benefits of the approach in terms of improved productivity for programmers and end users. These advantages stem from a few principles: (1) data independence separating logical and physical aspects of database management, (2) improved communication by relying on a common representation between users and programmers, and (3) a set-processing metaphor sparing programmers from the need of thinking in terms of iteration. In the same lecture, Codd made claims on theoretical achievable performance of relational database implementations. Only years later he was proven right. Meanwhile, the relational model had already supplanted the hierarchical and the network model for databases.

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

10

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

5.2. Future directions Relational models and formal grammars from one side, symbolic execution and even more Petri nets from the other side suggest that the key factor of the industrial success of a formal approach does not stem from robust tools, relevant applications, widespread education, but from the ability of addressing a strong industrial need that we have identified as the killer applications. Despite the many attempts to apply graph transformation to industrially relevant problems, the community seems not to have found a winning killer application yet. Visual languages are welcome as such domain by many experts of graph transformation systems, but graph transformations, although important, do not play an irreplaceable role yet. The recent years are seeing an increasing impact of systems that because of their nature and complexity cannot be designed and fixed at design time, but change and evolve at runtime. Managing such systems requires the ability to capture and reason about their structure and dynamic evolution. Graph transformation systems are good candidates for these tasks. Notable examples are self-organizing or adhoc networks that have a potentially unbounded number of nodes, no centralized management, and evolve over time as nodes join or leave [20]. Another emerging area with highly dynamic and evolving characteristics is the area of autonomic and self adaptive systems. These systems are designed to adapt at runtime to different and evolving execution conditions. A particularly interesting area where graph transformations can be applied is the study of the behavior and interaction of several concurrent control loops in autonomic systems [38]. 6. Conclusions In this paper, we have analyzed the impact of graph transformation in industry and have indicated in the lack of a killer application the reasons for the still limited industrial success of graph transformation. In a thorough paper of 15 years ago, Blostein et al. indicated education and technical problems as factors that hinder the industrial success of graph transformation. Although some of the key technical problems identified by Blostein et al., and in particular lack of modularization and structure, are not completely solved yet, the projects surveyed in this paper indicate interesting advances in tools, techniques and patterns. Many research experiences and few relevant industrial scale projects produced tools and methodologies that are ready for industrial usage. In this paper we observe that despite the advances in tools, education and experience, graph transformation systems are still foreign to industrial practice, and argue that lack of extensive education and widespread tools are the consequence and not the cause of the limited industrial success, which depends on the lack of a core problem domain well addressed by graph transformation instead. Identifying a successful killer application is mostly a matter of a combination of different unpredictable factors and can be hardly planned in advance. In this paper we observe that we may find killer applications not only in

the domain of visual languages that seems to be the natural domain for applying graph transformation and has attracted the attention of the community for many years, but also in the emerging domain of evolving and self adaptive systems. The importance of mastering dynamically evolving systems at runtime is becoming a necessity in many relevant application domains like distributed systems and autonomic computing, and is opening new opportunities for graph transformation systems. References [1] R. Heckel, Graph transformation in a nutshell, Electronic Notes in Theoretical Computer Science 148 (2006) 187–198. [2] H. Ehrig, K. Ehrig, U. Prange, G. Taentzer, Fundamentals of Algebraic Graph Transformation, Monographs in Theoretical Computer Science. An EATCS Series, Springer, 2006. [3] J. Pfaltz, A. Rosenfeld, Web grammars, in: International Joint Conference on Artificial Intelligence, 1969, pp. 609–619. ¨ [4] A. Schurr, Specification of graph translators with triple graph grammars, in: WG’94, 1994, pp. 151–163. [5] T. Pratt, Pair grammars, graph languages and string-to-graph translations, Journal of Computer and System Sciences 5 (6) (1971) 560–595. [6] H. Ehrig, M. Pfender, H. Schneider, Graph-grammars: an algebraic approach, in: 14th Annual Symposium on Switching and Automata Theory, IEEE, 1973, pp. 167–180. [7] J. Dolado, F. Torrealdea, Formal manipulation of Forrester diagrams by graph grammars, IEEE Transactions on Man and Cybernetics 18 (6) (1988) 981–996. ¨ [8] H. Gottler, Graph grammars and diagram editing, in: GraphGrammars and Their Application to Computer Science, Springer, 1987, pp. 216–231. [9] H. Bunke, Attributed programmed graph grammars and their application to schematic diagram interpretation, IEEE Transactions on Pattern Analysis and Machine Intelligence 6 (1982) 574–582. [10] T. Dean, J. Cordy, A syntactic theory of software architecture, IEEE Transactions on Software Engineering 21 (4) (1995) 302–313. [11] D.L. Me´tayer, Describing software architecture styles using graph grammars, IEEE Transactions on Software Engineering 24 (7) (1998) 521–533. [12] M. Derk, L. DeBrunner, Reconfiguration for fault tolerance using graph grammars, ACM Transactions on Computer Systems 16 (1) (1998) 41–54. [13] D. Blostein, H. Fahmy, A. Grbavec, Issues in the practical use of graph rewriting, in: Graph Grammars and Their Application to Computer Science, Springer, 1996, pp. 38–55. [14] G. Rozenberg, H. Ehrig, Handbook of Graph Grammars and Computing by Graph Transformation, vol. 1, World Scientific, 1997. ¨ [15] A. Corradini, H. Ehrig, M. Lowe, U. Montanari, J. Padberg, The category of typed graph grammars and its adjunctions with categories, in: J.E. Cuny, H. Ehrig, G. Engels, G. Rozenberg (Eds.), TAGT, Lecture Notes in Computer Science, vol. 1073, Springer, 1994, pp. 56–74. [16] L. Baresi, M. Pezze , Formal interpreters for diagram notations, ACM Transactions on Software Engineering and Methodology 14 (1) (2005) 42–84. [17] J. de Lara, H. Vangheluwe, Defining visual notations and their manipulation through meta-modelling and graph transformation, Journal of Visual Languages and Computing 15 (3–4) (2004) 309–330. domain-Specific Modeling with Visual Languages.. ¨ [18] R. Bardohl, G. Taentzer, M. Minas, A. Schurr, Application of Graph Transformation to Visual Languages, World Scientific Publishing Co., Inc., River Edge, NJ, USA, 1999, pp. 105–180. [19] T. Eckardt, C. Heinzemann, S. Henkler, M. Hirsch, C. Priesterjahn, ¨ W. Schafer, Modeling and verifying dynamic communication structures based on graph transformations, Computer Science-Research and Development 20 (2011) 1–20. [20] M. Saksena, O. Wibling, B. Jonsson, Graph grammar modeling and verification of ad hoc routing protocols, in: Proceedings of the Theory and Practice of Software, 14th International Conference on Tools and algorithms for the Construction and Analysis of Systems, Springer-Verlag, 2008, pp. 18–32. [21] M. Koch, L.V. Mancini, F. Parisi-Presicce, A graph-based formalism for RBAC, ACM Transactions on Information and System Security 5 (2002) 332–365.

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003

G. Toffetti, M. Pezze / Journal of Visual Languages and Computing ] (]]]]) ]]]–]]]

¨ [22] A. Schurr, F. Klar, 15 years of triple graph grammars, Graph Transformations (2008) 411–425. [23] F. Hermann, H. Ehrig, C. Ermel, F. Orejas, Concurrent model synchronization with conflict resolution based on triple graph grammars, in: J. de Lara, A. Zisman (Eds.), Fundamental Approaches to Software Engineering, Lecture Notes in Computer Science, vol. 7212, Springer, Berlin/Heidelberg, 2012, pp. 178–193. http://dx.doi.org/10.1007/ 978-3-642-28872-2_13. ¨ [24] F. Klar, M. Lauder, A. Knigs, A. Schurr, Extended triple graph grammars with efficient and compatible graph translators, in: G. Engels, C. Lewerentz, W. Schfer, A. Schrr, B. Westfechtel (Eds.), Graph Transformations and Model-Driven Engineering, Lecture Notes in Computer Science, vol. 5765, Springer, Berlin/Heidelberg, 2010, pp. 141–174. ¨ [25] H. Gottler, Diagram editors¼graphs þ attributes þ graph grammars, International Journal of Man–Machine Studies 37 (4) (1992) 481–502. ¨ [26] D. Blostein, A. Schurr, Computing with graphs and graph transformations, Software: Practice and Experience 29 (3) (1999) 197–217. [27] S. Ceri, P. Fraternali, A. Bongio, Web modeling language: a modeling language for designing web sites, Computer Networks 33 (1–6) (2000) 137–157. ¨ ¨ [28] C. Henke, M. Tichy, T. Schneider, J. Bocker, W. Schafer, System architecture and risk management for autonomous railway convoys, in: Proceedings of the 2nd Annual IEEE International Systems Conference, 2008. [29] C. Zhao, J. Kong, K. Zhang, Program behavior discovery and verification: a graph grammar approach, IEEE Transactions on Software Engineering (2010) 431–448.

11

¨ [30] E. Legros, C. Amelunxen, F. Klar, A. Schurr, Generic and reflective graph transformations for checking and enforcement of modeling guidelines, Journal of Visual Languages and Computing 20 (2009) 252–268. [31] C. Petri, Communication with automata: Volume 1 Supplement 1, Technical Report, Applied Data Research Inc, Princeton, NJ, 1966. [32] K. Jensen, L. Kristensen, L. Wells, Coloured Petri nets and CPN tools for modelling and validation of concurrent systems, International Journal on Software Tools for Technology Transfer 9 (2007) 213–254. [33] M.H. Matcovschi, C. Mahulea, C. Lefter, O. Pastravanu, Petri net toolbox in control engineering education, in: IEEE Conference on Computer Aided Control Systems Design, 2006, pp. 2298–2303. [34] W.R. Bush, J.D. Pincus, D.J. Sielaff, A static analyzer for finding dynamic programming errors, Software: Practice and Experience 30 (7) (2000) 775–802. [35] K. Sen, Concolic testing, in: Proceedings of the 22nd IEEE/ACM International Conference on Automated Software Engineering (ASE ’07), ACM, New York, NY, USA, 2007, pp. 571–572, http://dx.doi. org/10.1145/1321631.1321746. [36] E.F. Codd, A relational model of data for large shared data banks, Communications of the ACM 13 (6) (1970) 377–387, http://dx.doi.org/ 10.1145/362384.362685. [37] E.F. Codd, Relational database: a practical foundation for productivity, Communications of the ACM 25 (2) (1982) 109–117, http://dx.doi.org/ 10.1145/358396.358400. [38] Y. Brun, G. Di Marzo Serugendo, C. Gacek, H. Giese, H. Kienle, ¨ M. Litoiu, H. Muller, M. Pezze , M. Shaw, Engineering self-adaptive systems through feedback loops, Software Engineering for SelfAdaptive Systems 20 (2009) 48–70.

Please cite this article as: G. Toffetti, M. Pezze , Graph transformations and software engineering: Success stories and lost chances, Journal of Visual Languages and Computing (2012), http://dx.doi.org/10.1016/j.jvlc.2012.10.003