A Generic Framework for Automated Quality Assurance of Software Models –implementation of an Abstract Syntax Tree

—Abstract Syntax Tree's (AST) are used in language tools, such as compilers, language translators and transformers as well as analysers; to remove syntax and are therefore an ideal construct for a language independent tool. AST's are also commonly used in static analysis. This increases the value of ASTs for use within a universal Quality Assurance (QA) tool. The Object Management Group (OMG) have outlined a Generic AST Meta-model (GASTM) which may be used to implement the internal representation (IR) for this tool. This paper discusses the implementation and modifications made to the previously published proposal, to use the Object Management Group developed Generic Abstract Syntax Tree Meta-model core-components as an internal representation for an automated quality assurance framework. I. INTRODUCTION To ensure the reliability of output, it is imperative that Software Quality Assurance (QA) is adopted in the development and maintenance of scientific software systems [1]. The integration of such techniques can either be performed manually, which is labour intensive, or utilise automated toolkits [2] [3] which alleviate these problems. The automated toolkits are limited in the respect that they are language-, paradigm-or problem-specific. This paper proposes a framework that would address these limitations by introducing a taxonomy of generic techniques combined with a generic internal representation (IR) of languages. The framework also covers a range of different language paradigms. This paper also proposes a form of IR representation that could be used as an intermediary between QA techniques and source code.


I.
INTRODUCTION To ensure the reliability of output, it is imperative that Software Quality Assurance (QA) is adopted in the development and maintenance of scientific software systems [1].The integration of such techniques can either be performed manually, which is labour intensive, or utilise automated toolkits [2] [3] which alleviate these problems.The automated toolkits are limited in the respect that they are language-, paradigm-or problem-specific.
This paper proposes a framework that would address these limitations by introducing a taxonomy of generic techniques combined with a generic internal representation (IR) of languages.The framework also covers a range of different language paradigms.This paper also proposes a form of IR representation that could be used as an intermediary between QA techniques and source code.
When considering the broad range of programming paradigms the differences between the languages, such as the constructs and data types, need to be addressed.This paper focuses on addressing issues in procedural and object-oriented languages as these are the most widely adopted paradigms in the development of scientific software [4].

II. ABSTRACT SYNTAX TREES
In order to address syntactical differences, Abstract Syntax Trees (AST) are adopted as 'a formal representation of the software syntactical structure' [5].At a surface level, the underpinning constructs of many procedural languages appear similar, and removing syntax from these would make all ASTs analogous.However, the resulting ASTs produced following analysis of source code are based on a broad range of factors, such as the context-free grammar used to define the language syntax [6].It is therefore highly likely that the generated ASTs for simple algorithms implemented in different programming languages can prove to be fundamentally different.These differences can become even more significant when addressing additional language features, such as data types.

III. CURRENT APPLICATIONS OF ASTS
The primary usage of ASTs is to facilitate the implementation of compiler tools.For this purpose, ASTs are built from token streams after lexical analysis of source code [7].However, the usage of ASTs now encompasses the implementation of many language related tools, such as interpreters, document generators and syntax-directed editors, etc. [8].
One such use that an AST can support is in duplicate code detection, whereby an AST designed to support data matching efficiency [8] requires only a pattern to be found.The significance of this is that only an initial node needs to be identified which is subsequently followed by a predetermined pattern of nodes.This technique is similar to that found in the plagiarism detection techniques, which makes use of code comparison, described by Cui et al [9].Equally, code analysis techniques can be implemented using node counting.Removing code comments and disregarding layout metrics produces better comparison metrics from this technique compared to those collected from source code [10].
A major development of ASTs lies in language translation, which occurs by producing an AST for a specific language.The AST can then be parsed whilst introducing the syntax of the output language.www.ijacsa.thesai.orgAfter the tree has been parsed, the resultant code should be complete and functional in the output language syntax [11] [12].A working example of this technique is adopted by Mono as a working and functional example of the approach in action [13].Mono is a framework that allows the use of the .NET platform upon other devices than just windows via the use of language translation.

IV. GENERATING ASTS
In order to generate ASTs, ANother Tool for Language Recognition (ANTLR) is a tool which uses a grammar input and can produce recognisers, compilers and translators [14].Of significance to the project presented within this paper is that the ANTLR compilers can build ASTs from source code [14].Utilising ANTLR, an example of the fundamental differences that can be generated in ASTs from simple algorithms is presented.In this example, a simple "Hello World" program written in Java and C#.It can be seen from the ASTs depicted in Figure 1 and Figure 2 that there are fundamental differences between the representations of a simple program in two similar objectoriented programming languages that are included in the ANTLR repository [15].
Clearly there are some similarities between the ASTs; for example the class node has the name, modifiers and body.However, the significant differences between the AST's is directly related to the grammar files.

V. LANGUAGE INDEPENDENCE
A key requirement for the successful implementation of the proposed analysis framework requires language independence to be implemented in order to separate any reliance on the QA procedures from the syntax and semantics of the source code programming language.The Object Management Group (OMG) has initiated a number of projects to investigate the development of generic ASTs.Broadly there have been two tiers adopted for the approach, the Abstract Syntax Tree Metamodel (ASTM) and the Knowledge Discovery Metamodel (KDM).The KDM is a standard to facilitate interoperability for exchange of data between tools that may be provided by different vendors [16].The KDM complements the ASTM and both are designed to work together.The extent to which they do is questionable as the link between the ASTM and KDM can best be described as fuzzy [17].However the KDM is less relevant in the development of the proposed framework, as the KDM focus on migration of software artifacts and not representation of language, so the focus is on ASTM and the Generic ASTM (GASTM) which is defined in the ASTM specification [18].

VI. TESTING / QUALITY ASSURANCE AND AUTOMATED APPROACHES
There is a wide range of toolkits developed for testing software [19] [20] [21] [22] [23] [24] and, broadly, these are targeted at the automation of testing to reduce workload required to test software applications.An initial survey of the available toolkits has revealed that most tools that apply QA techniques to multiple languages only do so on a small-scale.Generally this is in the range of 2 -5 languages [2], and also focused on languages which share a programming paradigm.It is also noted that the more generic toolkits with a broader coverage of programming paradigm instead have a restriction in terms of the areas of testing which are covered [2].
There are two types of analysis within QA; dynamic and static [25] [26].Whilst both offer advantages, combining these techniques results in a broader impact as a result of QA [18] [19].Static analysis facilitates an abstract view of a program and examination of source code without code execution [27], and also supports the identification of such potential issues as memory corruption errors, buffer overruns, out-of-bound array accesses, or null pointer de-references [28].
Dynamic analysis is the analysis of code as it is executing, and therefore extracting accurate values of variables under set circumstances is a key target [25].This technique can be used to run functional, logical, interface and bottom-up tests amongst a range of supported testing [25].The combination of static and dynamic analysis allows for a larger coverage of QA www.ijacsa.thesai.orgtechniques and a tool which implements both of these analysis types would be more comprehensive [29] [30].

VII. PROPOSAL FOR ABSTRACT SYNTAX TREE
A proposal for the use of the GASTM as a form of Internal Representation (IR) for automated quality assurance was theorized under the ideas that both static and dynamic analysis could be implemented upon this IR via the processes described by the flow diagrams in figure 3, 4 and 5 [31].It was identified that by using the GASTM, static analysis could be possible via implementing tree walkers.In essence this would entail replacing source code analysers, and could implement automated quality assurance techniques such as metric and pattern matchers as well as allowing the GASTM to be converted to a control flow graph for data flow analysis.Dynamic analysis however is a more complicated matter.By using a generic monitor class, nodes could be inserted into a program before conversion into a runnable language.These inserted nodes would call method in the generic monitor class allowing for information about data, properties or runtime information to be pulled out and recorded or analyses whilst the program is running.

VIII. IMPLEMENTATION
LIQA (Language Independent Quality Assurance), is the implementation of the research discussed in this paper.Utilizing tools that have been previous developed by third parties, LIQA implements a middle layer to facilitate interaction using bespoke code and breaks down a subset of the Java language forming the GASTM representation of the source code.

A. LIQA Functionality
LIQA was designed for practical use within a lab setting.A GUI (Graphic User Interface) was developed to control the overall work flow as well as visual representation of the GASTM IR (Internal Representation) structure to allow quick assessment of correctness.This has been accompanied by a feature to create and load projects into the software.

B. GASTM Representation
The diagram shown below (figure 7) is the graphical output from LIQA and is a sample of the function definition 'HelloWorld' as shown in figure 6.
public class HelloWorld { public static void print() { printout("Hello, World"); } } Fig. 6.HelloWorld Java As was identified earlier, the IR can become very complicated from even a simple program.After the Java code has been parsed into the classes that represent the GASTM nodes, the object is then walked using a separate class to 'pretty print' the IR into XML which is then taken and placed in a SVG (Scalable Vector Graphics) format culminating in figure 7.
Several modifications have had to be made to the GASTM representation developed by Modisco [32], these modifications have been made for one of two reasons.The small change of implementing java.io.Serializable on the classes GASTMFactoryImpl, GASTMObjectImpl, GASTMPackageImpl, GASTMSemanticObjectImpl, GASTMSourceObjectImpl and GASTMSyntaxObjectImpl, was to enable the IR to be saved as a binary file thus making it simple to implement a project based file system and allow users to save their work.
The other modifications listed below were implemented to better mirror the properties of some of the selected procedural languages.The ClassType and ClassTypeImpl were modified to include a link to the AccessKind class via the methods getAccessKind and setAccessKind.This was because in Java, C#, C++ and recent high-level languages allow programmers to assign classes with the access modifier i.e. public, private or protected.
The FunctionMemberAttribute and FunctionMemberAttributeImpl have had the property IsStatic added, which is a boolean variable.The methods to modify the property setIsStatic and getISStatic have also been added.This was as Java, C#, and C++ allow programmers to assign functions with the static modifier.

C. Tools used in development
LIQA utilizes several tools to achieve various tasks, these tasks (and therefore tools) are not all necessary however they make LIQA easier to use and simple to test for issues.The tools used as listed below: The Modisco library has a Java representation of the GASTM core objects and therefore can be used instead of having to write the object in Java or another language.This links with the JavaCC tool which generated a Java tokenizer using a grammar located in the JavaCC library which is used by LIQA to convert the source code and generate the GASTM IR via the Modisco library.These two tools were required to make the production of LIQA a quicker and simple process.However the other tools are used to simplify the use of LIQA and simplify fault finding within the parsing and IR generating process.After the IR is generated it is then walked by LIQA and written to and .xsdfile.

D. Limitations
The limitations of LIQA are underpinned by a variety of contributing factors and are segmented to specific sections of the program.LIQA itself has the limitation of only being able to handle single file programs rather than full programs/projects built up over multiple files.This is due to time constraint.Although extending LIQA to handle full programs/projects would be a simple process, at this stage of the it is not required as LIQA is only a 'proof of concept' for the larger framework.
The following limitations are to the Java language parser and are either due to time constraints for this research however will be part of future development and not being required to test the basic function of the IR, or are due to the GASTM not supporting the specific syntax.The following limitations are due to the GASTM core limitations, the program that is being analyzed cannot contain: <= , >= , += , -= , /= , *= The GASTM cannot handle these operators however considering the operators can be broken down i.e. 'x += 1' = 'x = x + 1' and 'x <= 2' = 'x < 3' it would be possible to integrate these into the IR.Due to time constraints, the lack of importance with these operators, as they can be replaced and effort it would take to code the conversion, they have not been included within the parser that generates the IR from the tokens.
The following limitations are due to be implemented in further developments of LIQA.However they are not necessary for testing the framework at this stage.

E. Analysis Test
After the initial implementation of the GASTM IR was finished, a proof of concept addition was made to LIQA, this was to implement a single form of static and dynamic analysis to test the proposal before a deeper analysis of quality assurance techniques takes place.
For dynamic analysis a simple profiler was developed, this required a tree walker which analyses the IR to find all the function definitions and the variable definitions in them allowing the user control over which methods and variables were monitored, after the user made their choice LIQA then inserts nodes to monitor the variable values wherever modified and counts method calls through the monitor class interface.The monitor class must be written in the original language as it may require language specific method calls itself in later development.
For static analysis a simple metric was written using a similar tree walker as the one for the profiler however this returned Logical Lines of Code value and is currently setup for further metrics to be included.

F. Proposal Modifications
During the implementation small changes had to be made to the proposal as technological limitations arose, the only change that was significant is the formulation of a plausible and feasible way of running a GASTM IR that has been modified to perform dynamic analysis.This was achieved by running a conversion back into source code from the GASTM IR via a tree walker, this would have to be implemented with every language due to library and specific method calls that are unique to that language.A further implementation of LIQA could include a method and parameter mapping system which would also allow for language conversion.The tree walker however provides a further form of quality assurance as some coding standards require code to be formatted is a specific way, as the tree walker generates the code a formatting system can be applied for easier maintenance.
A smaller modification is to the flow of data with regards to how static analysis is run, the DFD (figure 8) shows the initial stage of the IR being converted to a CFG, though not all static analysis techniques utilize a CFG the conversion must take place for those that do before the application of a static quality assurance techniques can be applied.The tree walker is utilized by all techniques not just the conversion to a CFG and would also be required before a technique can be applied.

IX. CONCLUSION
This paper presented the implementation of an internal representation fit to allow both quality assurance via static and dynamic analysis and also to allow the representation of multiple languages.The major issues of this implementation are differences in languages and how to apply the analysis upon the final structure.
The ASTM is a standard prepared by OMG for language based tools and implements a set of core components that can represent a subset with many procedural and object oriented languages.It is therefore an obvious choice for this internal representation.www.ijacsa.thesai.orgThe implementation of the proposal within the tool LIQA represents a proof of concept showing that the GASTM is a suitable IR and that quality assurance techniques can be applied to this.However exactly what techniques can be applied is uncertain, it is certain that at least a simple level of static and dynamic analysis can be performed.Further work will demonstrate what techniques can be applied and these techniques will be derived from many tools currently used as industry standards.