Ontology Model-based Static Analysis on Java Programs

Transcription

1 Ontology Model-based Static Analysis on Java Programs Lian Yu 1, Jun Zhou, Yue Yi, Ping Li, Qianxiang Wang School of Software and Microelectronics, Peking University, Beijing, , PRC Abstract 1 Typical enterprise and military software systems consist of millions of lines of code with complicated dependence on diverse library abstractions. Manually debugging these codes imposes developers overwhelming workload and difficulties. To address software quality concerns efficiently, this paper proposes an ontology-based static analysis approach to automatically detect bugs in the source code of Java programs. First, we elaborate bug list collected, classify bugs into different categories, and translate bug patterns into SWRL (Semantic Web Rule Language) rules using an ontology tool, Protégé. An ontology model of Java program is created according to Java program specification using Protégé as well. Both SWRL rules and the program ontology model are exported in OWL (Web Ontology Language) format. Second, Java source code under analysis is parsed into the Abstract Syntax Tree (AST), which is automatically mapped to the individuals of the program ontology model. SWRL Bridge takes in the exported OWL file (representing the SWRL rules model and program ontology model) and the individuals created for the Java code, conduits to Jess (a rule engine), and obtains inference results indicating any bugs. We perform experiments to compare bug detection capability with well-known FindBugs tool. A prototype of bug detector tool is developed to show the validity of the proposed static analysis approach. Keywords: Program ontology model, static analysis, bug detector, abstract syntax tree (AST), reasoning. 1. Introduction There are many possible ways to find bugs in software. Code inspections can be very effective at finding bugs, but have the obvious disadvantage of requiring intensive manual effort to apply. There is imperative need to exploit automatic techniques to reduce the effort of inspectors. Dynamic bug finding techniques, such as testing, runtime verification and monitoring, depend on the execution of the program. These bug finding techniques have their advantage and disadvantage. The advantage is that dynamic techniques do not consider infeasible paths in a program. The disadvantage is that they can only find 1 The research is supported by the National High-Tech Research and Development Plan of China (No. 2006AA01Z175) and by IBM Joint Research Program (No. JS ). bugs in the program paths that are actually executed. Constructing a test suite for a complex program will cost a lot of time and effort. In addition, the test suite constructed will be hard to achieve high statement or branch coverage, and the full suite of tests requires lots of time to run [1]. Static techniques explore abstractions of all possible program behaviors, and thus are not limited by the quality of test cases in order to achieve high quality of programs. And the use of static analysis can save lots of time spent on writing and running a large volume of test cases. In recent years, many researches have investigated automatic techniques to find bugs in software. For example, the ESC/Java [8], FindBugs [9], JLint [12] and PMD [16] are all bug finding tools. ESC/Java uses the theorem proving technology to find bugs in a software; FindBugs, JLint, and PMD use the syntax analysis technology to find bugs in a software. FindBugs and JLint also include a dataflow module to detect bugs [2]. Among them, FindBugs is a famous static analysis tool and used in many companies and organizations. It analyzes Java byte-code, performs syntactic and dataflow checks. The bug pattern detectors of FindBugs are implemented using BCEL (Byte Code Engineering Library) [6], which is an open source binary analysis and instrumentation library. However, FindBugs has some disadvantages. First, because FindBugs can only analyze bytecode, so if the Java source code cannot be complied yet, FindBugs could not be used to find any bugs. Moreover the complier will optimize the code and omit some information when the source code is transformed to byte code. So FindBugs cannot detect these bugs which are optimized by the complier. Second, if someone wants to customize or extend FindBugs, he needs to know the BCEL and implement them in Java. In contrast with the FindBugs, our bug detecting tool can find the bugs in the software directly with the source code, and even partially implemented and not yet compiled. In addition, the extension of our BugDetector tool is easier. It just needs to describe the bug type that a tester wants to detect in SWRL [18] (Semantic Web Rule Language), and then the tool will have the ability to detect the bugs of the new type. Most of bug detecting tools only use one or two way to find bugs. The proposed approaches combine the syntax

2 analysis, ontology modeling and reasoning techniques. An AST (Abstract Syntax Tree) is used to model Java source code; ontology techniques are used to model Java program specification and SWRL to model bug patterns; and OWL (Web Ontology Language) format [15] is used to represent the ontology models. Finally, a reasoning tool is used to decide whether source code has targeted bugs. The main contributions of this paper are summarized as follows: The bug detecting tool can find bugs in the software directly using source code, even partial source code without passing compilation. The extension of the tool is easier. A user just needs focusing on analyzing bug logic in stead of programming. Unlike the ESC/Java, FindBugs, JLint, and PMD which only use one or two way to find bugs, our tools combine the syntax analysis, ontology modeling and reasoning techniques. The rest of the paper is organized as follows. Section 2 illustrates the ontology-based static analysis process. Sections 3 through 5 describe bug pattern representation in SWRL, and explain the logic of bug detecting and reasoning. Section 6 carries out the experiments by comparing our approach with the FindBugs. Section 7 presents a survey of related work. Finally, Section 8 concludes the paper and scratches the future work. 2. Process of Ontology Model-based Static Analysis This section presents the whole process of the ontology-based static analysis approach as shown in Figure 1, which consists of four parts: 1) Bug pattern identification; 2) Modeling Java specification and bug patterns in ontology techniques; 3) Modeling Java source code in AST; and 4) Bug reasoning and reporting. 1) Bug Pattern Identification: We collect more than 200 Java programming bugs from our previous projects and Internet public resources as well, classify them into 42 different categories, and abstract bug pattern rules for each category. Then we translate these bug patterns rules in SWRL (Semantic Web Rule Language) format. This process is introduced in Section 3. 2) Modeling Java Specification and Bug Patterns in Ontology: We manually model Java Program Specification and Bug Pattern Rules in SWRL using Protégé tool [17]. In both computer science and information science, an ontology is a data model that represents a set of concepts within a domain and the relationships. Here the data model is ontology models of Java program and bug patterns. Ontology models are exported in OWL format and will be used in the later stages. This part is described in Section 4. 3) Modeling Java Source Code in AST: Java source code of interest is parsed into an Abstract Syntax Tree (AST) according to a language named ANTLR (Another Tool for Language Recognition) [5]. This instance of AST is automatically mapped to the individuals of Java program ontology model using Protégé APIs. This part is depicted in Section ) Bug Reasoning and Reporting: With the input of ontology models of Java program models and bug pattern rules and individuals of AST, SWRL Bridge [18] is used to pass the input all the way to Jess engine [11], which performs reasoning and returns asserted bugs back to the bridge. Finally a bug report is generated. This part is explained in Section Bug Pattern Identification This section describes bug pattern identification and bug pattern representation in ontology techniques. Figure 1. Process of Ontology Model-based Static Analysis

3 Bug Categorization We manually analyze a list of more than 200 Java bugs collected. Table 1 gives four typical bugs and each of which is described in terms of ID, Description and Detail. Note due to the space limitation, we do not list up all the bugs collected in this paper. Table 1: Partial List of Bugs Collected ID: 21 Description: Confusing Name: Apparent method / constructor confusion Detail: This regular method has the same name as the class it is defined in. It is likely that this was intended to be a constructor. If it was intended to be a constructor, remove the declaration of a void return value. If you had accidently defined this method, realized the mistake, defined a proper constructor but can't get rid of this method due to backwards compatibility, deprecate the method. ID: 103 Description: Field: Unread field Detail: This field is never read. Consider removing it from the class ID: 104 Description: Detail: Field: Unused field This field is never used. Consider removing it from the class ID: 105 Description: Field: Unwritten field Detail: This field is never written. All reads of it will return the default value. Check for errors (should it have been initialized?), or remove it if it is useless. We classify them into different categories according to the following principles: The bugs correspond to a same method. For example, for equals() method, the compared targets may be incorrect in different ways, such as array type compared with non-array type, or object type compared with null argument. The bugs are field related, for example, field naming, field modifier, or field usage. The bugs are multi-thread related, for example, a sequence of multi-threaded method call, or certain methods usage. The source code of programs which contain bugs has similar functions, for example, object type cast, or objects comparison. In a word, bugs belonging to a category have something in common. Bugs with ID 103, 104 and 105 all occur when accessing a field in terms of be never read, be never used and be never written, respectively. Therefore, they fall into a same category, as shown in Table 2, in the second bug pattern denoted as This field is never used This field is never written All reads of it will return the default value. This bug pattern is related to the access of a field. On the other hand, some of the bugs we have analyzed have special characters; and they do not share commonality with others collected, such as the bug with ID 21. Those kinds of bugs form a category on their own. Finally we classify all bugs collected into 42 categories, each of which corresponds to one or more bug patterns. Bug Patterns Bug patterns are recurring correlations between signaled errors and underlying bugs in a program. It is a bad programming style that can result in bugs in programs. By identifying these bug patterns, programmers can be warned of making similar mistakes in programming. The notion of defining a bug pattern is that we can t leave everything to Unit Testing. By matching the characteristics of the source code with certain bug pattern, static analysis can generate bug reports. Therefore, bugs can be identified before the testing phase. Table 2 shows two categories out of 42 Bug Patterns. Bug Pattern is its representation, Purpose is the reason why this bug pattern is defined, IDs contains the IDs of bugs falling into the Bug Pattern category, and Meaning is the description of the Bug Pattern. Bug Pattern: Purpose: IDs 21 Meaning: Table 2: Partial List of Bug Patterns A method name and its class name are the same Method has a declaration of returning value type Prevent programmers from mis-defining constructor The type void for returning value is not allowed when defining constructor. In java, there should be no type for returning value when defining constructor. Bug Pattern: This field is never used All reads of it will return the default value Purpose: Prevent unused fields. IDs: 103, 104, 105 Meaning: The field is never read / written / used. Take as an example bug ID=21, the first record in Table 1, which belongs to A method name and its class name are the same Method has a declaration of returning value type category in Table 2, where means logical AND. Bugs in this category define a method with a same name as its class name. If the method has a return type instead of void, it will contradict to the constructor. To automatically detect bugs, each category classified needs to be characterized by decomposing and

4 formalizing as a bug pattern. This paper proposes to use SWRL to represent formally each bug pattern. Next section will illustrate in more details. 4. Modeling Java Program Specification and Bug Patterns This section uses ontology techniques to model Java program specification and bug patterns identified above. Modeling Program and Bug Patterns We create OWL classes to describe all elements of Java program specification using Protégé tool. Table 3 briefly explains the elements modeled, including Java class, method, attribute, modifier, interface, clause, operator, object and primary value. OWL Classes ClassDesc MethodDesc AttributeDesc ModifierDesc InterfaceDesc ClauseDesc Operator Object PrimaryValue Table 3: OWL Classes in Protégé Description Describe the Java class in the Java Syntax Describe the methods in the java class Describe the fields in the java class The modifiers used by the classes, methods and attributes Represent the java interface Represent the statements in the java source code. (It has more than 18 sub classes) The operators used by the statements (It has more than 21 sub classes) Describe the object variables used in the java source code Represent the primary variables Besides describing Java syntax, we also use OWL classes to describe bugs in Java source code. In this paper, we define and implement about 24 bug patterns. Table 4 shows the partial OWL classes of bug patterns, and corresponding descriptions. And all bug patterns listed in the Table 7 and Table 8 (See Section 6: Experiments and Analysis) correspond to the names of OWL classes in Table 4. In addition, about 50 OWL properties are defined to describe relationships between OWL classes of the Java ontology model. For instance, an ifelse statement has a property named IfElseClause_hasCondition describing that it has a condition; meanwhile it has a property named IfElseClause_hasStatements containing the statements when the condition is true, and a property named IfElseClause_hasElseStatements containing the statements when the condition is false. Modeling Bug Patterns in SWRL Semantic Web Rule Language (SWRL) proposal was submitted to W3C by National Research Council of Canada, Network Inference, and Stanford University. SWRL provides a high-level abstract syntax that extends the OWL abstract syntax. The proposed rules are of the form of an implication between an antecedent (body) and consequent (head). The meaning is read as: whenever the conditions specified in the antecedent hold, then the conditions specified in the consequent must also hold. Table 4: Partial OWL Classes of Bug Patterns Defined OWL Class: EqualsMayReturnNullBug Description: The equals method should not return null OWL Class: NullPointerBug Description: Reference a null pointer OWL Class: OverrideEqualsOrHashcodeBug Description: Override only one method of the equals method and the hashcode method OWL Class: EqualsWithObjectBug Description: Should not use the operator == or!= to differ from two objects OWL Class: MaliciousCodeBug Description: A List or Hashtable typed field should not be return to other method caller OWL Class: SwitchClauseWithoutDefaultClauseBug Description: Switch statement without default clause may cause internal risk OWL Class: SwitchSubClauseWithoutBreakClauseBug Description: Case statement without break or return clause may cause internal risk OWL Class: NewStringInstanceBug Description: Using the java.lang.string(string) constructor wastes memory OWL Class: NewIntegerInstanceBug Description: Using new Integer(int) is guaranteed to always result in a new object. Use the valueof(int) instead of it. OWL Class: SelfAssignmentBug Description: This method contains a self assignment of a variable. OWL Class: BlockNotContainAnyClauseInIfElseClause Bug Description: The block of the ifelse statement does not contain any statement. In this paper, the antecedent of a bug pattern is a collection of conditions which are portrayed by OWL classes in Table 3 and their properties, and it also contains the bug pattern name which is depicted as OWL classes in Table 4 and information on what kind of bugs can be found by such a bug pattern. The consequent is the asserted result if all conditions in the antecedent are met. This paper uses the ErrorReport property, which says that one clause or object may contain a bug. We use the OWL classes and properties defined above, and refine bug pattern representations to help automate bug detection. Take the bug pattern to which bug ID=21 belongs as an example again, the corresponding SWRL representation is as follows:

5 First, the body asserts an individual named _c is an instance of the ConditionClause OWL Class. Then it asserts it has two individuals of ObjectDesc named _l and _r, and also a _equal operator. Third, it asserts there is a relation between _c and _l used by the ConditionClause_hasLeft property. And there are also a ConditionClause_hasRight property between _c and _r and a ConditionClause_hasOperator property between _c and _equal. Then it asserts an individual of EqualsWithObjectBug named _bug. At last, if all of the above conditions are satisfied, the head asserts an ErrorReport property between clause _c and _bug. 5. Modeling Java Source Code and Reasoning Bugs To automate static analysis on Java source code, we develop a parser to translate source code into an AST (Abstract Syntax Tree), and a module to map AST instance of the source code to the individuals of Java ontology models. SWRL Bridge is utilized to transform the ontology into a rule engine, which reports back the bug detection results. Building AST and Generating OWL Individuals ANTLR is a language tool that provides a framework for constructing compilers. We write a parser in ANTLR (Another Tool for Language Recognition) grammar, and use ANTLR tool to convert the parser to a Java parser. The Java parser processes Java source code and builds its AST (Abstract Syntax Tree). The created AST has a similar structure as the Java ontology model that we have created in Section 4. An OWL individual generator is developed to automatically create OWL individuals of the Java ontology model based on the Java source code AST using Protégé APIs. Take the following simple Java source code as an example to show the process: The developed parser takes in the Java code as input and generates an AST as follows: The OWL individual generator traverses each node of the tree and sets individuals correspondingly. Take CLASS_DESC as an example. The generator uses class JenaOWLModel s method getowlnamedclass ( ClassDesc ) to get an OWL class, ClassDesc (See Table 3), then invokes its method createowlindividual ( _Class_MyClass_ ) to create the individual, which has two properties, hasmethod and hasmodifier. Their individuals can be generated in a similar way, and are listed in Table 5. Table 5: OWL Individuals in Property OWL Property Name hasmethod hasmodifier Bug Reasoning OWL Individual in Property Detail _Method_foo_ Public_1 Once we have set up OWL individuals of the Java ontology model, we are ready for bug reasoning. Based on the OWL classes, SWRL Rules and the AST Individuals, SWRL Bridge is used to perform syntax transformation from OWL syntax to Jess syntax. Then SWRL Bridge calls Jess Engine, which performs Jess reasoning and returns assertion results to SWRL Bridge. For each OWL classes, the SWRL Bridge will create a define command for Jess, e.g., (deftemplate ClassDesc extends owl:thing). For each OWL Individual, the SWRL Bridge will create the define command for Jess, e.g., (assert(classdesc(name _Class_MyClass_ ))). For each OWL Property in each OWL Individual, the SWRL Bridge will also create an assert command for Jess, e.g., (assert (name _Class_MyClass_ MyClass )). For each SWRL rule, the SWRL Bridge will use a defrule command, e.g., (defrule EqualsChecker1 (Cond ition_hasleft?_c?_l)(condition_hasright?_c?_r) ). After the reasoning, the result will be shown as follows: (assert errorreport( NullPointerBug _Invoke Clause_ _Line_69)). These results will be used to generate a Bug Report.

6 6. Experiments and Analysis In order to evaluate bug detection capability of the proposed approach on Java projects, we have carried out the following four experiments. Because our project is still ongoing, we mainly focus on the bug patterns which our tool, BugDetector, has implemented. 1) Compare the bug hit rate using BugDetector and FindBugs. The higher the hit rate is, the stronger the bug detection capability. 2) Compare the different bug pattern types found by BugDetector and FindBugs. 3) Test the performance of BugDetector when a new bug pattern type is added in. 4) Test BugDetector precision. The experiments are performed on a computer with Centrino 1.6G CPU, 1.5G memory and 120G hard disk; the operating system is Windows XP with JDK 1.5. The experiment targets include Hibernate 3.2.4, Struts 1.3.8, MySQL Connector and Spring FindBugs is version of Comparing Bug Number Found In general, the larger the bug number found, the better the bug detection capability of a tool. As the comparison of two tools is carried on the same targets, the total number of bugs is the same. Therefore, we just need to look at the number bugs found by the two tools. Table 6 shows the experimental results of bugs found by BugDetector and FindBugs. Lines of Code represent the number of NCSS (Non Commented Source Statements); and # of Class Files represents the number of classes in projects. Within column of BugDetector, Time is the total time (in H: M: S format) that BugDetector consumes to detect each target. Total Bugs are the bug number that BugDetector finds. Within column of FindBugs, Related Bugs is the bugs to which our tool is targeting. As our tool is ongoing-developed, only about 40% percent of bug patterns are implemented. Therefore, we compare the types of bugs that the two tools both are intended to target. The result shows that BugDetector finds more bugs than FindBugs does, except for the result of Hibernate. The current Protégé SWRL and underlying Jess engine do not implement negation operator although SWRL specification has the feature, and any bug patterns related to negation will be ignored when performing the bug reasoning. If the situation is improved later, BugDetector will find even more bugs. Comparing with human being, BugDetector is much fast, but inferior to FindBugs in terms of time, where loading takes 46%, reasoning takes 48% and parsing takes 6%. Because the source code is larger than the byte code and the logic of the source code is also more complex than that of the byte-code. Reducing time is one of goals in our next version. This experiment aims to test the feasibility and usability of BugDetector. Bug Pattern Types Found Table 6: Bugs found by BugDetector and FindBugs Table 7 shows the different bug pattern types found by BugDetector and FindBugs respectively. The description of bugs can be found in Table 4 in Section 4. It is observed from Table 7 that for null pointer bug type, the number of bugs found by BugDetector is less than that of Findbugs. This is because we do not cover as many conditions and situation as FindBugs does. Our ongoing work is to remedy the missing situations. We also notice that the bugs of type switch clause without default clause bug cannot be found by the FindBugs at all. In addition, FindBugs cannot find the BlockNotContainAnyClauseInIfElseClauseBug. This is because the FindBugs can only parser the byte-code. But when the Java source code is complied into byte-code, the complier will optimize the code and omit some information forcedly. Take the following source code as an example in Figure 2(a): Figure 2. Optimized Code after Compilation The reason that true branch does nothing varies: 1) developer forgets writing the code there, or; 2) developer comments the block out for debugging, but forgets to de-comment afterwards; or 3) developer can not decide the logic yet due to the vague design and requirements, but forgets to confirm that later. In any cases, this situation should be signified. However, after compiled, it will be represented in the binary code something like Figure 2(b). Name Lines of # of Class BugDetector FindBugs Code Files Time Total Bugs Time Related Bugs Hibernate ,853 1,060 1:18 : : Struts , : :20 52 Mysql Connector , : :19 44 Spring ,061 1, : :31 58

7 Therefore, the action of the complier may lead to the consequence that FindBugs cannot find such kinds of bugs. Table 7: Bug Pattern Detection Capability Bug Pattern Name # of Bugs # of Bugs (BugDetector) (FindBugs) Null Pointer Bug Override Equals Or Hashcode Method Bug Equals May Return Null Bug 8 6 SwitchClause Without DefaultClause Bug 13 0 Equals With Object Bug 49 7 SwitchSubClauseWithoutBre akclausebug NewStringInstanceBug NewIntegerInstanceBug 98 0 MaliciousCodeBug BlockNotContainAnyClauseI nifelseclausebug 22 0 Scalability Figure 3 shows BugDetector time consumption as the number of bug pattern types grows up. This experiment is performed on Struts 1.3.8, and demonstrates that when increasing the bug pattern number, the time-consuming of BugDetector does not change much. This is partially due to the fact that Rete algorithm [4] used for rule-based systems is asymptotically independent of the number of rules. So when increasing the number of bug patterns, i.e., increasing the number of rule, the time-consuming does not be increased drastically. Thus, BugDetector achieves a good scalability. even for if statement. At present, we can not conclude the overall hit rate. Next version still needs to enhance the capability in terms of bug patterns coverage and bug situation coverage. Table 8: BugDetector Precision Bug Pattern Name Counts Hit Hit Rate Null Pointer Bug % Override Equals Or Hashcode Method Bug % Equals May Return Null Bug % SwitchClause Without % DefaultClause Bug Equals With Object Bug % SelfAssignmentBug % BlockNotContainAnyClauseIn IfElseClauseBug Tool Support % To facilitate bug detection, a prototype of BugDetecor is developed as an Eclipse plug-in as shown in Figure 4. Hit percentage Figure 3. Scalability of BugDetector Table 8 shows the precision of BugDetector. Counts are the bug number found by BugDetector, and Hit is actual bugs confirmed by human being. The description of bugs can be found in Table 4 in Section 4. It is observed that BugDetector achieves a high hit rate. That is it reports bugs that are actually the cases. However, we realize the implemented bug patterns in BugDetector are still preliminary, and can not handle all situations, Figure 4. BugDetector Tool Support Prototype It allows a user to start bug detection by clicking a BugDetector button, review the list of bugs in a panel below, and automatically signify the bug position in the program editing area. 7. Related Work One of the well-known tools for finding bugs in software is FindBugs [9], which uses static technique to find a variety of common defects in Java programs. FindBugs tool inherits much of the philosophy from the Lint which can find a variety of common errors in C programs. And our BugDetector tool inherits some of the philosophy from FindBugs, e.g., using bug patterns to describe bugs in the program, while we are using different approaches, ontology techniques to represent bug patterns. Modern Lint-like bug checkers include LCLint [13] and Jlint. JLint like FindBugs, analyzes Java byte-code, performing syntactic checks and dataflow analysis. JLint includes an inter-procedure and inter-file component to

8 find deadlocks by building a lock graph and ensuring that there are never any cycles in the graph. PMD, like FindBugs, uses syntactic technique to detect bug, but it does not use the dataflow technique to find bugs in the software. In the PMD, users can select the detectors or groups of detectors that they want to run. The extension of PMD is very easy; programmers can add new bug pattern detectors using either Java or XPath. ESC/Java uses an automatic theorem-prover to verify that the program matches the best practice of the Java language. The full name of ESC/Java is Extended Static Checking system for Java, extended because ESC catches more errors than are caught by conventional static checkers such as type checkers [3]. If users want to use ESC/Java to find bugs in the program, they just need to add preconditions, post-conditions, and loop invariants to source code in the form of special comments. Bug checker uses static analysis to find code that may cause the program to misbehave at runtime. The output of the bug checker is mainly for users. Style checker examines code to determine if it violates particular coding style rules, such as always put constants on the left hand side of comparisons. The output of the style checker is mainly for developer. Style checker may help prevent certain kinds of bugs, but it dose not limit to find bugs, it also helps developers to improve their coding habit. Because style checking tools are easy to implement and the output of style checking tools is easier to understand, so tools that focus mainly on checking style, such as PMD and CheckStyle [7] are more widely used, even though bug checker are more likely to direct developers to the real bugs in their code. Our BugDetector tool is bug checker, but the output of our tool is easy to understand. All tools reviewed above are static analysis tools on which we mainly focus. Static analyzers analyze the program at compile time, inspecting directly the source code, byte-code or binary code, and never executing the program. Not like the static analysis technology, dynamic analysis technology, such as testing and assertions, checks program at run-time. Many sophisticated bug analysis technologies are provided by runtime analyzers, for example, the integrated debugging environments with automatic test generators or dynamic program instrumentation. Now the notion of static analyzer has a broad acceptance. And like the dynamic bug finding technology the automated bug finding technology is also widely accepted, and greatly used in the development of the software. And still there are many researchers who are very interest in integrating the automated bug finding technology to the development process of the software. 8. Conclusion and Future Work This paper proposes an ontology model-based static analysis approach for Java programs. The approach is developed to automatically detect bugs in Java programs by parsing the Java source code. It eases both the programming and the testing effort in the following ways. By parsing the source code directly, programmers can check their code even when the code is incomplete and with compilation errors in stead of being restricted to complied code like FindBugs. It can also find more kinds of bugs than FindBugs. And automatically detecting bugs in code reduces the effort to write test cases to check problems in codes. While dynamical bug detection and byte-code analysis have been very successful and mature in this domain, we believe that ontology model-based static bug detection and source code analysis can reveal bugs and problems that former methods cannot. A prototype tool is developed to show the validity of the proposed static analysis approach. The experiment results show that the approach can detect some kinds of bugs that FindBugs can not. Our research is still ongoing. We will implement the rest of bug patterns identified, minimize runtime, and realize a full-fledged BugDetector tool. Reference [1] David Hovemeyer and William Pugh, Finding bugs is easy, Oct Companion to the 19th annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pp [2] Nick Rutar, Christian B. Almazan, Jeffrey S. Foster, A Comparison of Bug Finding Tools for Java, Nov Proceedings of the 15th International Symposium on Software Reliability Engineering (ISSRE'04), pp [3] Cormac Flanagan, K. Rustan M. Leino, Mark Lillibridge, Greg Nelson, James B. Saxe and Raymie Stata, Extended Static Checking for Java, Jun Proceedings of the ACM SIGPLAN 2002 Conference on Programming language design and implementation, pp [4] C.L. Forgy, Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem, Artificial Intelligence, vol. 19, pp , [5] ANTLR. [6] BCEL. [7] CheckStyle. [8] ESCJava [9] FindBugs. [10] Hibernate. [11] Jess. [12] JLint. [13] LCLint. [14] MySQL. [15] OWL. [16] PMD/Java. [17] Protégé. [18] SWRL. [19] Struts. [20] Spring.