Transformation-Based Operationalization of Graph Languages

Graph Languages' emerged during the seventies from the necessity to process data structures with complex interrelations. Nowadays, various variants of these languages can be found for querying [1][2], in-place transforming [3] [4], and translating graph structures [5] [6]. Still, new graph languages supporting different paradigms and usage scenarios are proposed regularly. In fact, languages tailored for a dedicated application domain can be restricted to a concise and clear syntax representation, thus reducing effort to learn and apply them. Effectively aiding the development of graph languages, even though considering the already existing ones, therefore remains an important working topic. Constructing specialized graph languages, considering them as special case of domain-specific modeling languages, is supported by various frameworks and so-called Meta-CASE tools, e.g. [7]. Operational implementations of these languages is usually achieved by customizing template-based code generators. However, graph languages, in contrast to purely static modeling languages, are inherently complex to implement due to the required pattern matching facility, and the possibly required non-deterministic execution engine. As alternative to the usual code generation approach, I propose a solution to implement graph languages by transformation. The approach is based on an extensible core graph language, to which rules modeled in a specialized graph language are transformed. Extensions can be added to the core language to approximate both languages's conceptual levels, and thus to narrow their "semantic gap". In contrast, a code generation module would have to span a significantly larger gap from a high-level specification language to an imperative or object-oriented programming language. A coarse-grained overview on the presented approach is given in Figure 1. Technically, this platform is built on top of the graph-oriented database DRAGOS [8]. Thanks to DRAGOS' exchangeable backends, language implementations gain access to established storage solutions like relational databases or model repositories. To construct a new graph language, developers usually build an editor based on the language's concrete syntax model, be that a textual or visual one. Based on this, a partly generic export facility transfers instances of this language, e.g. entered by the user at runtime, into the graph database as abstract syntax trees (ASTs). This intermediate storage facility decouples further processing from the actual concrete syntax and from the applied editing technology. Afterwards, as the first curved arrow suggests, the ASTs are transformed into instances of the provided core graph language, DRAGULA. This transformation, which needs to precisely capture the specialized language's intended semantics, can be modeled in a rule-based way. For this purpose, a simple uni-directional model transformation language is provided. Technically, this language's rule instances are stored in all additional repository in the database, and are transformed to the core language, too. Finally, the generated core language rules can be evaluated by the corresponding engine, thereby referring to the database's data repository. Both the rule engine and the data repository are subject to user interaction, e.g. to select rules for invocation or to directly inspect the stored graphs. This talk primarily discusses the first curved arrow, whereas the second one has been described in [9], and the core language's extensibility in [10].