Integrating Graph Rewriting and Standard Software Tools

OptimixJ is a graph rewrite tool that can be embedded easily into the standard software process. Applications and models can be developed in Java or UML and extended by graph rewrite systems. We discuss how OptimixJ solves several problems that arise: the model-ownership problem, the embedded graphs problem, the library adaptation problem, and the target code encapsulation problem. We also show how the tool can be adapted to host language extensions or to new host languages in a very simple way, relying on the criterion of sublanguage projection. This reduces the effort for adapting OptimixJ to other host languages considerably. How can we get more people to employ graph rewriting in their daily modelling and programming tasks? One of the standard answers is: “by better tooling”. However, there are two major problems with this answer. Firstly, most graph rewrite tools have employed their proprietary DDL1, basing the graph rewrite specifications and the generated code on this DDL. However, this principle forces applications to use the DDL of the tool and, hence, to base their code on the tool: the tool owns the model. However, in today’s model-based development processes, models are maintained in the language of the application or in UML. And UML tools do not know nor care about other generators (model-ownership problem, Figure 1). The second problem is a person-power problem. Graph rewrite tooling is lagging behind the development in standard software engineering, mainly because the graph rewrite tool developer community is rather small and has not so much person-power available as e.g., the community that develops UML tools. So, the tool gap keeps on increasing. It almost looks like an inverted Zenon’s paradox: every time the graph rewrite tool developer has realized a step towards a tool, the rest of the world has done already two steps into other directions. ? Work partially supported by European Community under the IST programme Future and Emerging Technologies, contract IST-1999-14191-EASYCOMP. The authors are solely responsible for the content of this paper. It does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of data appearing herein. 1 In the following, we distinguish data definition languages (DDL), which are used for type declarations, from data manipulation languages (DML), which are used for procedural and rule-based behavior description. This paper presents solutions for both problems. It presents a tool, OptimixJ, which works seamlessly together with Java and jUML2. The tool does not superimpose its own graph model to the standard languages, but refers to the graph models in the users’ specification, enabling reuse of standard models. Hence, the tool does not force users to change their software process when working with graph rewriting. Changing to OptimixJ can be done step-by-step, in a piece-meal growth; users can start with small additional graph rewrite specifications that work on standard models, and, being more experienced, go on with larger specifications. We believe that this philosophy is somewhat more realistic than the philosophy of current tools: graph rewriting is a powerful technique for several application fields, but not for all of them. Users need flexibility and do not want to be constrained by the full-metal jacket of a monolithic graph rewrite tool. Nevertheless, they want to be able to decide when they use graph rewriting. However, even this integration feature will not be sufficient, because new modelling and programming languages are evolving all the time. For instance, Java 1.5 will integrate generic data structures. A graph rewrite tool that is integrated with Java has to be extended to generic data types, which can be a very laborious process. Hence, we have to require for a successful tool that it must be extensible to new versions of the host language3 very quickly and easily. This is the case for OptimixJ. We show this by investigating its architecture in more detail. In fact, OptimixJ exploits a novel sublanguage projection concept to adapt its rewrite specification to a host language. Using the adapter, graph rewrite systems can be type-checked against the host data model, enabling reuse of standard models. Additionally, when such an adapter is exchanged, a new host language can be connected to the tool. Instead of writing a full new compiler for host language plus graph rewriting extension, only specific parts of the tool’s architecture need to be reimplemented. This simplifies the construction of new tools enormously. Apart from these two main problems, several other minor problems hobble the use of graph rewrite systems in the modern development process. Firstly, many UML tools implement associations with neighbor sets, i.e., implement graphs not in a closed form, but embed them into the nodes (embedded graph problem). Usually, the graph rewrite tools cannot handle this. Secondly, if the model is owned by the UML tool, the GRS generator should be able to know, which node attributes belong to graphs and which ones don’t. In particular, the UML tools use data types of the host language library to type the associations. Usually, the GRS tool cannot adapt to arbitrary host language libraries, because it does not know whether a class has a graph-like semantics or not (host library adaptation problem). Next, modern object-oriented languages enforce encapsulation of code and data in classes. While, in general, this is a well-accepted structuring principle for systems, the encapsulation prevents that classes are extended later on (target code extension problem). Hence, a generator has either full control over a class, or none at all. It is no longer possible, as in the target language C, to augment a module stemming from the applica2 jUML is assumed to be the variant of UML that maps directly to Java. For instance, class diagrams should not employ multiple inheritance. 3 The host language is the language to which all specifications and programs should be translated. Fig. 1. The standard scenario of graph rewrite system (GRS) tools in the software process. The tool maintains its own DDL, forcing the application to use generated type definitions, or proprietary graph classes. tion model with additional procedures generated by the GRS tool.4 Often, this problem is solved by delegation: graph nodes and objects from the application are realised in different physical objects, delegating work to each other. However, delegation is subject to object schizophrenia [1] and slows down navigations in large graphs ([2], Chapter 9). OptimixJ can be fully integrated with standard software engineering languages and tools, such as Java and jUML. When using OptimixJ, the model is owned by the major development tool and the graph rewrite system only enriches the generated code (Section 1). Models from jUML structure diagrams can be used, legacy Java implementations can be augmented with GRS code. Hence, the graph rewrite systems adapt to the data model of the application, which is a major advantage. OptimixJ allows for embedded graph representations that are used by UML tools. OptimixJ is adapted to the JDK, all graph types of the JDK can be employed. New Java container libraries can be integrated easily. Since OptimixJ provides executable GRS, it can be used as an executable form of OCL and we investigate the commonalities and differences (Section 3). Due to sublanguage projection, OptimixJ is easy to port to other DDL (Section 4). Finally, we compare to related work (Section 5). We believe that the tool and its underlying concepts can provide a valuable contribution to an intensified use of graph rewrite systems in the industrial software development. 4 This problem does not occur in all object-oriented languages. For instance, C++ has an extension operator :: that allows for extending a class remotely, and this operator can be used to augment the classes generated from the model. 1 OptimixJ in Action OptimixJ is a graph rewrite tool that can generate implementations of algorithmic attributed graph rewrite systems with 1-context [3]. It is an extension of Optimix [4], but seamlessly integrated with the host language Java. Hence, OptimixJ can be employed very easily in a standard object-oriented software process. We start with a simple example. Consider the following Java class Person, which models relationships of persons in families (father, mother, children, a.s.o.). The main program builds up a little database of persons, and starts some processing. public class Person { public Person father; public Mother mother; public Person[] parents; public Person[] children; public Vector ancestors; public Vector childrenWithAgeAbove18; public Vector oldChildren; public String id; public int age; public Person(String id) { father = new Person() ; mother = new Vector(); parents = new Person[10]; children = new Person[10]; ancestors = new Vector(); this.id = id; childrenWithAgeAbove18 = new Vector(); } public static void main(String[] s) { Person gDad = new Person("grand_dad"); Person gMom = new Person("grand_mom"); Person child1 = new Person("child1"); Person child2 = new Person("child2"); Person father = new Person("father"); Person mother = new Person("mother"); child1.age = 23; child2.age = 13; child2.setFather(father); child2.setMother(mother); child1.setFather(father); child1.setMother(mother); father.setFather(gDad); father.setMother(gMom); Vector persons = new Vector(); persons.add(father); persons.add(child2); persons.add(child1); Person[] dummy = new Person[1]; makeChildrenConsistent((Person[])persons.toArray(dummy)); calculateOldChildren((Person[])persons.toArray(dummy)); } } This class is incomplete because the methods makeChildrenConsistent and calculateOldChildren are realized by graph rewrite systems. We store it in a file Person.jox, indicating its incompleteness. The rewrite systems can be defined in a separate specification Person.ox. OptimixJ generates their implementation and inserts them into Person.jox, producing the final Person.java. module Person; grs MakeChildrenConsistent(persons:Person[]) { range C <= persons; rules // Datalog syntax: :-. parent(C,M) :mother(C,M); // (1) consistency of relations parent(C,F) :father(C,F); children(P, C) :parent(C, P); } grs calculateOldChildren(persons:Person[]) { range parent <= persons; rules // Business rule syntax: if then ; if parent in child.parents then parent in child.ancestors; if parent in child.parents and ancestor in parent.ancestors then ancestor in child.ancestors; if child in parent.children, child matches Person{age=>Val}, Val >= 18 then child in parent.childrenWithAgeAbove18; if child in parent.childrenWithAgeAbove18 then add g:GrownUpChild,// (2) Building up a new node domain g in parent.oldChildren;// (3) Put into new relationship } end Person While makeChildrenConsistent inverts several relations in the model, calculateOldChildren computes a transitive closure and allocates new nodes of a new type GrownUpChild. From this GRS definition, OptimixJ generates two methods fragments, which are embedded into class Person and stored in file Person.java: public class Person { public static void makeChildrenConsistent(persons:Person[]) {...} public static void calculateOldChildren(Person[] persons) {...} ... other members as above ...