In this report we present a type graph that models all executable constructs of the Java programming language. Such a model is useful for any graph-based technique that relies on a representation of Java programs as graphs. The model can be regarded as a common representation to which all Java syntax graphs must adhere. We also present the systematic approach that is being taken to generate syntax graphs from Java code. Since the type graph model is comprehensive, i.e., covers the whole language speciﬁcation, the technique is guaranteed to generate a corresponding graph for any valid Java program. In particular, we want to extract such syntax graphs in order to perform static analysis and model checking of programs written in Java. Although we focus on Java, this same approach could be adapted for other programming languages

Rensink, Arend

Zambon, Eduardo

English

In this report we present a type graph that models all executable constructs of the Java programming language. Such a model is useful for any graph-based technique that relies on a representation of Java programs as graphs. The model can be regarded as a common representation to which all Java syntax graphs must adhere. We also present the systematic approach that is being taken to generate syntax graphs from Java code. Since the type graph model is comprehensive, i.e., covers the whole language specification, the technique is guaranteed to generate a corresponding graph for any valid Java program. In particular, we want to extract such syntax graphs in order to perform static analysis and model checking of programs written in Java. Although we focus on Java, this same approach could be adapted for other programming languages

University of Twente Research Information

A Type Graph Model for Java Programs

In this work we present a type graph that models all executable constructs of the Java programming language. Such a model is useful for any graph-based technique that relies on a representation of Java programs as graphs. The model can be regarded as a common representation to which all Java syntax graphs must adhere. We also present the systematic approach that is being taken to generate syntax graphs from Java code. Since the type graph model is comprehensive, i.e., covers the whole language specification, the technique is guaranteed to generate a corresponding graph for any valid Java program. In particular, we want to extract such syntax graphs in order to perform static analysis and model checking of programs written in Java. Although we focus on Java, this same approach could be adapted for other programming languages

A Type Graph Model for Java ProgramsArend Rensink and Eduardo ZambonFormal Methods and Tools Group, EWI-INF, University of TwenteP.O. Box 217, 7500 AE, Enschede, The Netherlands{rensink,zambon}@cs.utwente.nlAbstract. In this work we present a type graph that models all exe-cutable constructs of the Java programming language. Such a model isuseful for any graph-based technique that relies on a representation ofJava programs as graphs. The model can be regarded as a common rep-resentation to which all Java syntax graphs must adhere. We also presentthe systematic approach that is being taken to generate syntax graphsfrom Java code. Since the type graph model is comprehensive, i.e., coversthe whole language specification, the technique is guaranteed to gener-ate a corresponding graph for any valid Java program. In particular, wewant to extract such syntax graphs in order to perform static analy-sis and model checking of programs written in Java. Although we focuson Java, this same approach could be adapted for other programminglanguages.1 IntroductionA graph is a flexible structure that is used to represent several different artifactsin computer science. However, the mathematical definition of a graph alone doesnot allow us to restrict a representation to a certain pattern or form. Suchrestrictions can be enforced by means of a type graph, a model that describesconstraints over the sets of nodes and edges of a graph.A program written in a certain language can be transformed into a syntaxtree by a parser. When additional information such as bindings are included inthe representation, the syntax tree is extended into a syntax graph. One maincontribution of our work is to define a type graph model for syntax graphs thatrepresent programs written in Java. The type graph model is complete, i.e., itcovers the entire language specification up to version 1.6 [10]. We believe thatthis model can be of interest to any graph-based technique that relies on arepresentation of Java programs as graphs. As one example, suppose a visualprogramming/modeling tool that generates Java code from a graph; this couldfor instance, be used in the context of graph transformation-based model trans-formation [1] or code refactoring [3]. By enforcing the graph to be an instanceof this type graph model, the tool can generate syntactically correct code. The research reported herein was carried out as part of the GRAIL project, fundedby NWO (Grant 612.000.632).D. Lee et al. (Eds.): FMOODS/FORTE 2009, LNCS 5522, pp. 237–242, 2009.c© IFIP International Federation for Information Processing 2009238 A. Rensink and E. ZambonIn our current research we aim to perform static analysis [7] and model check-ing [2] of Java programs using GROOVE [8], a tool for state space explorationwhere states are represented as graphs, and the transitions from one state toanother are given by graph transformation rules. A syntax graph is the staticrepresentation of a program as a graph, and it is the required initial structure forthe subsequent elaboration of the states that constitute the dynamic behaviorof the program. Thus, the work here presented is the first, necessary step in ourplanned method for the verification of code.In this document we focus on the approach taken for the construction of thetype graph model. Due to space limitations, it is not possible to actually presentthe model, and we refer the interested reader to the accompanying technicalreport [9], where all the details are given.2 Description of Approach TakenThe task of constructing syntax graphs from given source code consists of twomajor steps, (i) the building of a type graph model to represent the syntacticalelements of the chosen programming language, and (ii) the development of a toolthat constructs a valid syntax graph from syntactically correct code. A syntaxgraph is considered to be valid when it is an instance of the type graph modeldeveloped in step (i). Essentially, the work to be done in (ii) boils down towriting a compiler that produces a syntax graph as its target language, insteadof machine code.We decided to adapt an open-source Java compiler for our purposes. In doingso, the implementation effort is kept to a minimum, since we have only to mod-ify the code generation phase of the compiler to construct the syntax graphs.Also, by analysing the source code of the compiler we are able to elaborate thetype graph model in a very straightforward way. Thus, with this solution, thedefinition of the type graph and the construction of the syntax graph generatorgo hand in hand, and we have the guarantee that a syntax graph generated fromcode is compliant with the type graph model.2.1 Creating the Type GraphIn order to develop our chosen approach we decided to use the Eclipse Java Com-piler [4]. This compiler is also written in Java, and its source code is available foruse under the Eclipse Public License. The compiler source is divided in severalpackages, among which the package org.eclipse.jdt.internal.compiler.ast1 is of particular interest, since it is where the classes that compose theAbstract Syntax Tree (AST) built by the compiler are grouped. By analysingthe package contents we are able to construct the type graph model, which ispresented in [9].1 Through the rest of the paper we adhere to the following convention: elements ofJava code are shown in typewriter font, while elements of the type graph or instancegraphs are shown in sans serif font.A Type Graph Model for Java Programs 239IfStmt Stmt {// fieldsExpr condition;Stmt thenStmt;Stmt elseStmt;...// AST traversal methodtraverse(ASTVisitor v){condition.traverse(v);thenStmt.traverse(v);(elseStmt != )elseStmt.traverse(v);...}...}StmtIfStmtExprthenStmt1condition1elseStmt0..1Fig. 1. Example of the type graph elaboration from the compiler source codeThe ast package contains, for example, classes like Expr and Stmt to repre-sent expressions and statements of the Java language. In fact, every syntacticalelement of the language has a corresponding class in the ast package and thoseclasses are grouped in a certain hierarchy. The top most class is ASTNode, whichdefines a common super type for all elements of the AST. The ast package alsoprovides an AST visitor pattern interface [5], which has methods to navigateover the nodes of the AST in a depth-first-like manner.The way the type graph is elaborated from the elements of the ast packagecan be best explained with an example. Figure 1 shows the relevant code of theclass that represents an “if” statement and the corresponding part of the typegraph constructed from this code. We start with the class name, IfStmt, thatgives rise to an homonymous node type in the type graph. Also, since IfStmt isa subclass of Stmt we create another node type for the super class and we insertan inheritance relation in the type graph, between the corresponding node types.The class fields that are references to other classes of the AST become compo-sitions (in some cases, ordered ones) in the type graph, with labels matchingthe field names. In this example, the fields named condition, thenStmt, andelseStmt give rise to three compositions in the type graph, with correspond-ing labels. Additionally, the way the visitor pattern is implemented in the classprovides some guidance over the cardinalities of the compositions just created.From the implementation of the traverse method we see that fields conditionand thenStmt are always visited. Therefore we can conclude that the IfStmtnode type must have mandatory condition and thenStmt compositions, a factthat is illustrated by the cardinality 1 of those compositions in the type graph.240 A. Rensink and E. ZambonOn the other hand, the check for non-nullness of the elseStmt field indicates thatit may not always exists. Therefore we mark the cardinality of its compositionin the type graph as 0..1.By analysing the classes of interest of the ast package in the same way asdescribed in the example above we can construct a large part of the type graphmodel. However, there are some elements of the type graph that still need to bemanually created. As an example we can cite the associations that resolve nameand type references, which correspond to the binding edges on syntax graphs.The intuition for identifying where these associations must be created is sim-ple: any reference should have an association with a corresponding declaration.However, the information needed to create these associations is not present inthe compiler source code in a uniform way, and therefore manual intervention isnecessary. The rationale behind our decisions over what does or does not haveto be manually inserted into the type graph comes from our intended purposefor the syntax graphs. Thus, we insert only the elements that we deem necessaryfor static analysis and simulation.The resulting type graph obtained from the analysis described in this sectionis formed by 75 node types, mapped directly from the compiler classes. Thecomplete type graph is presented and explained in our technical report [9].2.2 Constructing Syntax Graphs from CodeTo construct syntax graphs from Java code we must change the back end ofthe Eclipse Java Compiler. By stopping the compiler after parsing and codeanalysis but before machine code generation we are able to profit from the workdone by the compiler until this stage. Specifically, name and type references arealready resolved, simplifying the construction of the syntax graph. We developeda syntax graph generator that implements the AST visitor interface provided bythe compiler and we plugged it in the compiler back end. To build the syntaxgraph, our generator visits the AST, performing the following steps.– For each node in the AST the generator creates a corresponding node inthe syntax graph. The types of a syntax graph node are obtained throughreflection. By using reflection in Java, one is able to query the virtual machinefor run-time information of objects. In our case we obtain the class hierarchyof an AST node via reflection and store this information as a label of thesyntax graph node.– For the construction of edges in the syntax graph we keep an auxiliary map-ping of AST nodes into syntax graph nodes. This mapping, along with thebindings produced by the compiler, is sufficient for creating the edges, in-cluding the ones that resolve references.For each node type of the type graph we created a test case input program.With these test cases we can inspect the syntax graphs produced by our tooland check for implementation errors. An example of such test case is given inFig. 2, along with the syntax graph generated. The complete set of input testcases can be found in the corresponding technical report [9]. The syntax graphA Type Graph Model for Java Programs 241Fig. 2. Example of a syntax graph built from code. The dashed box represents a systemwide compilation unit where primitive types of the language are declared.in Fig. 2 has a node labeled TypeDecl, which represents a class. The name of thedeclared class is stored as an attribute of the node, which also has three outgoingedges that correspond to the field and method compositions. It is important tonote that name and type reference nodes have an outgoing edge that bindsthe reference to its corresponding declaration. We consider the existence of a“system” compilation unit, where the primitive types of the language, and alsothe classes of java.lang.*, are declared. Part of this “system” compilation unitis shown in the bottom of Fig. 2 (within the dashed box), with the declarationof the primitive type int.3 Conclusion and Future WorkTo sum up, the contributions of our work are threefold.– We have created a comprehensive type graph that covers all executable ele-ments of the Java programming language. Such type graph can be of interestas a model for tools that represent Java programs as graphs.242 A. Rensink and E. Zambon– We have shown a straightforward and systematic approach for the construc-tion of the type graph model by analysing a compiler source code. Althoughour described method focused on Java, we believe that it can be adapted(with varying degrees of difficulty) to other programming languages as well.– We explained how the back end of a compiler can be adapted in order toautomatically construct a syntax graph representation from source code.The work described in this paper is the first step in our planned approachfor the verification of Java programs. Now that we are able to generate syntaxgraphs from code the next step is the construction of flow graphs, structures thatmodel the sequential execution relation between elements of the syntax graph.We plan to define graph transformations rules over syntax graphs for flow graphconstruction, as described in [6]. Together, a syntax graph and a flow graph forma program graph. The subsequent step is then use the GROOVE tool to simulatethe execution of program graphs. Another important aspect of this step is thatwe want to apply abstract interpretation techniques to simplify the programgraphs and thus improve the performance of the simulation.References1. Alanen, M., Lundkvist, T., Porres, I.: Creating and reconciling diagrams afterexecuting model transformations. Sci. Comput. Program. 68(3), 155–178 (2007)2. Baier, C., Katoen, J.P.: Principles of Model Checking. MIT Press, New York (2008)3. Baumer, D., Gamma, E., Kiezun, A.: Integrating refactoring support into a Javadevelopment tool. In: OOPSLA 2001 Companion (2001)4. Eclipse Foundation: JDT core component development resources,http://www.eclipse.org/jdt/core/dev.php5. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements ofReusable Object-Oriented Software. Addison-Wesley Professional Computing Se-ries. Addison-Wesley Publishing Company, New York (1995)6. Kastenberg, H., Kleppe, A., Rensink, A.: Defining object-oriented execution seman-tics using graph transformations. In: Gorrieri, R., Wehrheim, H. (eds.) FMOODS2006. LNCS, vol. 4037, pp. 186–201. Springer, Heidelberg (2006)7. Nielson, F., Nielson, H.R., Hankin, C.: Principles of Program Analysis. Springer,New York (1999)8. Rensink, A.: The GROOVE simulator: A tool for state space generation. In: Pfaltz,J.L., Nagl, M., Böhlen, B. (eds.) AGTIVE 2003. LNCS, vol. 3062, pp. 479–485.Springer, Heidelberg (2004)9. Rensink, A., Zambon, E.: A type graph model for Java programs. Technical ReportTR-CTIT-09-01, University of Twente, Enschede (February 2009)10. Sun Microsystems: The Java language specification,http://java.sun.com/docs/books/jls/

NARCIS 

Abstract. In this work we present a type graph that models all executable constructs of the Java programming language. Such a model is useful for any graph-based technique that relies on a representation of Java programs as graphs. The model can be regarded as a common representation to which all Java syntax graphs must adhere. We also present the systematic approach that is being taken to generate syntax graphs from Java code. Since the type graph model is comprehensive, i.e., covers the whole language specification, the technique is guaranteed to generate a corresponding graph for any valid Java program. In particular, we want to extract such syntax graphs in order to perform static analysis and model checking of programs written in Java. Although we focus on Java, this same approach could be adapted for other programming languages

A Type Graph Model for Java Programs

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information

University of Twente Research Information

NARCIS

CiteSeerX