case study of inspecting an Automatic Teller Machine system to evaluate ... In this paper, we describe an automated approach to program inspection that utilizes ...
An Automated Approach to Speci…cation-Based Program Inspection Shaoying Liu1 , Fumiko Nagoya1 , Yuting Chen1 , Masashi Goya1 , and John A McDermid2 1 Department of Computer Science Faculty of Computer and Information Sciences Hosei University, Tokyo, Japan 2 Department of Computer Science University of York, UK
Abstract In this paper, we describe how formal speci…cation is adopted to improve the commonly used veri…cation and validation technique known as program inspection, in order to establish a more rigorous, repeatable, and e¢ cient inspection process than the conventional practice. We present a systematic approach to inspecting program code on the basis of the relation between functional scenarios de…ned in a speci…cation and execution paths implemented in its program. We report a prototype tool for the approach to support both forward and backward inspection strategies, and a case study of inspecting an Automatic Teller Machine system to evaluate the performance of the approach and the tool.
1
Introduction
Program inspection has become a commonly used technique for veri…cation of programs in industry since it was developed by Michael E. Fagan at IBM in the 1970s [1]. The essence of the technique is to detect errors in programs by human inspectors through reading and analyzing programs, based on some criteria. Many researchers have contributed to the progress of the technology by establishing various reading techniques [2, 3, 4, 5] and inspection processes [6, 7, 8], but most of the existing techniques do not take formal speci…cation into account in program inspection, simply because formal speci…cation is not available in most industrial software development projects. With the continual development of formal methods, however, many industrial sectors have gradually adopted formal speci…cation techniques [9, 10, 11, 12]. Although formal This work is supported by the Ministry of Education, Culture, Sports, Science, and Technology of Japan under Grant-in-Aid for Scienti…c Research on Priority Areas (No. 16016279).
1
2
speci…cations are becoming more widely used, formal proof has achieved less industrial acceptance, due to cost and limitations of tools. However, inspection can be a practical approach for veri…cation and validation, especially when the application domain is not safety-critical; even in safety critical applications inspection has an importance. The problem is how to make inspection techniques rigorous so that they can be applied e¤ectively and repeatedly in practice. In this paper, we describe an automated approach to program inspection that utilizes the power of formal speci…cation to tackle the problem. Our inspection approach shares Parnas’idea described in [13] in that the use of formal speci…cation is advocated, but develops the idea further to establish precise and detailed instructions on how a formal speci…cation can be used to help systematic program inspection. Speci…cally, a functional speci…cation is treated as a document to de…ne a collection of functional scenarios. Each scenario de…nes a speci…c functional requirement or service in terms of taking input and generating output. A scenario can be de…ned by a predicate expression in the model-oriented speci…cation languages at the unit level (e.g., operation) or a series of state transitions at the system level. Our inspection approach suggests that the program be examined to ensure that every functional scenario de…ned in the speci…cation is implemented correctly by a set of execution paths in the program. An execution path is a sequence of operations and/or conditions in a program, starting from one of the start operations or conditions and terminates at one of the end operations or conditions of the program. The case study described in Section 6 shows that derivation of both functional scenarios in a speci…cation and necessary execution paths in a program can be automatically performed by a software tool, hence inspection can be performed systematically and e¢ ciently. Our major contributions in this paper include (1) the establishment of the principle and strategies for program inspection based on the relation between functional scenarios and their corresponding execution paths, (2) the design of the algorithms and rules for automating the activities involved in our inspection approach, (3) the implementation of a prototype software tool to support the activities involved in an inspection process, and (4) the presentation of a case study of inspecting an Automated Teller Machine (ATM) system to evaluate the performance of the approach and the tool. The remainder of this paper is organized as follows. Section 2 describes the principles underlying the inspection approach. Section 3 discusses the issues of how to derive functional scenarios from a speci…cation and execution paths from a program, respectively. Section 4 discusses the process of inspecting execution paths in a program. Section 5 reports a prototype tool for our inspection approach, while Section 6 presents a case study using the tool. Finally, in Section 7 we conclude the paper and point out future research.
3
2
The Principle of Speci…cation-Based Inspection
To facilitate the discussion of the principle, we …rst need to de…ne all the related notions concerned with both speci…cations and programs. This paper focuses on the description of how our inspection approach is applied to an operation de…ned with pre- and postconditions, and will discuss the extension of the approach to software integration level in a future publication.
2.1
Basic Concepts in Speci…cation
Without losing generality in model-oriented speci…cations (e.g., VDM, Z, B, SOFL), we can assume that an operation is de…ned by pre- and postconditions. De…nition 1 An operation OP is a …ve tuple [OPiv ; OPov ; OPev ; OPpre ; OPpost ], where OPiv denotes the set of all the input variables, OPov the set of all the output variables, and OPev the set of all the related external variables (state variables), OPpre and OPpost represent the pre- and postconditions of OP , respectively, and it satis…es the following condition: V ariables(OPpre ) [ V ariables(OPpost ) (OPiv [ OPov [ OPev ). where V ariables(C) denotes the set of all variables occurring in predicate C (such as OPpre and OPpost ). For example, let C = x > 0 ^ y < x + 1. Then V ariables(C) = fx; yg. All the other concepts concerned with operations de…ned below are based on the structure of an operation de…ned in De…nition 1. De…nition 2 Let OPeviv denote the set of all ‘rd’ external variables and decorated ‘wr’ external variables (e.g., ~x) of OP . Let OPevov denote the set of all ‘wr’ undecorated external variables of OP . Then OPev = OPeviv [ OPevov . An ‘rd’(readable) external variable of operation OP provides an unmodi…able input value to the operation. A ‘wr’(writable) external variable (e.g., x) provides both an input value, represented by the decorated variable (e.g., ~x), and represents an output value, denoted by the undecorated variable (e.g., x) of operation OP . We call the variables of OPeviv input external variables and the variables of OPevov output external variables of OP , respectively. De…nition 3 A predicate C in OPpost is called a guard condition if and only if it contains neither output variables of OPov nor output external variables of OPevov (part of OPev ). Note that an implication of this de…nition is that both the boolean values true and f alse if they appear in OPpost are guard conditions. De…nition 4 A predicate expression D in OPpost is called a de…ning condition if and only if it does not contain any guard condition as its constituent expression.
4
For example, let the operation Search be de…ned as follows: Search = [fxg; findexg; flistg; true; x 2 elems(list) ^ (9i2inds(list) list(i) = x ^ index = i) _ :x 2 elems(list) ^ index = 0], where x (input variable) denotes an integer, index (output variable) a natural number, and list (a readable external variable) a sequence of integers; elems(list) denotes the set of all elements on the sequence list, and inds(list) represents the index set of list. If input x is a member of list, its index (location) in the list will be represented by the variable index as the result of the operation; otherwise, index = 0 will be the result. In this speci…cation, the conditions x 2 elems(list) and :x 2 elems(list) are both guard conditions, while (9i2inds(list) list(i) = x^index = i) and index = 0 are both de…ning conditions. De…nition 5 Let OP be an operation and OPpost = C1 ^ D1 _ C2 ^ D2 _ _ Cn ^ Dn , where Ci (i 2 f1; 2; :::; ng) is a guard condition and Di is a de…ning condition. Then, a functional scenario fs of OP is a conjunction Ci ^ Di , and such a form of postcondition is called a functional scenario form or FSF for short. Consider the operation Search above as an example. Its postcondition is in a FSF in which the two functional scenarios x 2 elems(list) ^ (9i2inds(list) list(i) = x ^ index = i) and :x 2 elems(list) ^ index = 0 are included. Since any predicate can be converted into an equivalent disjunctive normal form (if quanti…ed expressions are treated as atomic predicates) and any postcondition in a disjunctive normal form can be converted into an equivalent FSF using Algorithm 1 described in Section 3, the postcondition of any operation can be converted into an equivalent FSF. Note that simply treating a disjunctive clause in the disjunctive normal form of a postcondition as a functional scenario is not necessarily correct in supporting our inspection approach. For example, let x > 0 ^ (y = x _ y = x) _ x 0 ^ y = x + 1 be the postcondition of an operation, where x is the input and y the output. It states that when x > 0, y is de…ned either as x or as x (the speci…er does not care which de…nition will be implemented). In this case, if we convert it into the disjunctive normal form x > 0 ^ y = x _ x > 0 ^ y = x _ x 0 ^ y = x + 1, and treat each of the two disjunctive clauses x > 0 ^ y = x and x > 0 ^ y = x as an individual functional scenario, and require the existence of corresponding execution paths in the program to implement both of them, we may not …nd a satisfactory answer in the program, since the programmer may (legitimately) have decided to implement only clause x > 0^y = x as a re…nement of x > 0^(y = x_y = x). If the testing of the precondition of an operation is enforced in its implementation (in case it is not tested by the environment before the operation is called), we must take the precondition into account as well in forming the FSF of the operation; that is, we need to convert the conjunction OPpre ^ OPpost rather than merely OPpost into an equivalent FSF. Since this does not increase technical di¢ culties compared to the conversion of OPpost , for simplicity we only consider OPpost in deriving functional scenarios discussed in this paper.
5
2.2
Basic Concepts Relating to Programs
In this section, we de…ne all the necessary concepts relating to programs, such as program graph and execution path. The program graph of a program is intended to be a syntactically alternative representation of the program that only involves conditions and basic operations, and it o¤ers the base for deriving execution paths in our inspection approach. De…nition 6 A program graph is a directed graph, represented by a four tuple (V , So , R, Eo ), where V is a set of vertices, each representing either an operation or a condition; So V is the set of start vertices; R V V is a relation over V ; and Eo V is a set of end vertices. A program graph contains a set of vertices denoted by V . Each vertex can be either an operation or a condition. Each operation is de…ned by a basic statement (assignment or method call) in a programming language, say Java, and each condition is represented by a logical expression. Note that we deliberately disallow operations in V that are de…ned by compound statements (e.g., if-else, while, for statements) in Java, because each of them can be decomposed into either a single execution sequence or a set of execution sequences of basic statements. There is a unique set of vertices, denoted by So , whose elements are contained in V ; each element of So represents a starting point of an execution of the program. There is also a set of end vertices, denoted by Eo , whose elements are included in V ; each element of Eo represents a terminating point of an execution of the program. In addition to the individual vertices in V , a program de…nes behaviors resulting from either conditional or unconditional executions of operations in V in certain orders. The relation R de…nes the order of execution of vertices. If a vertex is an operation, by execution of the vertex we mean the execution of the operation; but if it is a condition, by execution of the vertex we mean the evaluation of the condition. Let the pair (x; y) 2 R represents a sequential execution of vertex x, then vertex y. Note that (x; y) 6= (y; x) holds in general. A program graph can be depicted graphically. For example, the program graph Searchg , which implements the operation Search described in Section 2, is de…ned as follows: Searchg = (fi = 1; i
