An Approach To OO Program Faults Checking Based On Statement Structure

According to the IEEE standard definitions[2],a fault or "bug"is an incorrect step, instruction or data definition in a program. A fault may result in a failure, which is observed when the system exhibits incorrect external behavior. An error is an internal difference between the computed, observed, or measured values or conditions, and the true, specified, or theoretically correct values or conditions. Finally, a mistake is a human misconception that results in a fault. A fault is the reason, an anomaly is the inner result. A fault couple with an anomaly. To express conveniently, this paper doesn't distinguish a fault and an anomaly any longer. Howden originally classified program faults, and Zeil extended Howden's classification. There have been other fault classifications based on observed instances of faults and on the complexity of faults. According to the Howden/Zeil classification, program faults are categorized as domain faults or computation faults. A domain fault occurs when,due to an error in control flow, program generates incorrect output. A computation fault occurs when a program takes the correct path, but generates incorrect output because of faults in the computations along that path. Domain faults are further classified into two categories. A missing path fault is caused by a missing conditional or clause and the associated statements, and a path selection fault is caused by an incorrect decision at a predicate. Path-selection faults can result from an incorrect predicate (predicate fault) or from an incorrect assignment statement that propagates to a control point, leading to an incorrect decision (assignment fault). Offoutt and Hayes suggest a model for program faults that they use to identify representative collections of faults. Their model characterizes a fault syntactically as the changes needed to correct the fault, and characterizes a fault semantically by viewing the faulty program as containing a computation that produces incorrect output over some subset of the input domain. Using this characterization, they define the size of a fault: the syntactic size of a fault is the fewest number of statements or tokens that must be changed to correct the fault; the semantic size of a fault is the relative size of the input subdomain for which the program produces incorrect output. A fault mainly exhibits a data flow anomaly(DFA), so fault checking is mainly DFA checking. DFA checking is a main aspect of program static analysis. DFA is a kind of abnormal instance which is concerned with variables in the program. DFA manifests potential error in the program. Through the number in the literature[8], the error which is concerned with data is 22 percent. The error which results from DFA is 15 percent at least. The program reliability which includes DFA is suspicious, so we should do our best to check out all DFA and eliminate them. With program static analysis tools, DFA checking can directly discover errors in the program, so it is more effective than testing and debugging. On traditional program (procedure oriented program) faults checking technology, there are some researches[9~12]. Literature [9] puts forward the DFA conception, and gives a way to check DFA which is based on data flow analysis technique. Literature[9] and Literature[10] put forward a way which shows data flow address with path expression and finds DFA through path expression checking. Literature[11] shows a fault about the arithmetic in the Literature[9] and puts forward a more effective arithmetic. Traditional procedure-oriented data flow analysis includes single-procedure data flow analysis and interprocedural data flow analysis. The former is about single-procedure inner variable, and it cann't analyze the variables which are through procedure, such as global variable, reference parameter, variable alias. The method solves the data flow analysis on interprocedural variables which was put forward by Harrold[13]. Some new interprocedural data flow analysis methods have been putforward in the recent year by Sharir[21][22]. Object-Oriented program analysis techniques is current researchful hot object, these techniques are mainly class analysis[24,26] and class testing[36,37,40~43]. As a main object-oriented program analysis domain, the research on object-oriented program faults checking techniques has a stable postpone[14,15,29,35,38,39,44], but the research object about recent techniques only limits to intermethod object-oriented faults in a class, the research on object-oriented faults between base class and deriveclass is very weakness. Inheritance and polymorphism enhance program language expression, and result in new faults types. Aim at the new faults which are resulted in by inheritance in the object-oriented program, this paper puts forward an approach to object-oriented program faults checking based on statement structure. This approach is based on language structure, such as overriding method directly define inherited static variables or noninherited method calls inherited method. If there is the statement structure in the program, we think there maybe exist faults. The statement structures which are put forward benefit many aspects.The main aspect is that if there is some statement structure in the program, it shows that maybe exits faults because of inheritance. Although faults don't have to result in errors, they give a faults checking direction. Another benefit is that the statement structures can be checked by automatic tools. Thus, object-oriented programmer can find and remove faults earlier. Prototype testing system manifests that the approach to object-oriented program faults checking based on statement structure is feasible. This paper educes many meaning topics. The first is the statement structure's existing frequency in the program. The second is that if the frequency is very low, whether the checking tool's value is small or not. The third is that if there exists the statement structure, what's the frequency of...