Design of a Tool for Specification-Based Program Review

Design of a Tool for Specification-Based Program Review∗ Fumiko Nagoya, Shaoying Liu, and Yuting Chen Faculty of Computer and Information Sciences Hosei University, Japan Email: {fnagoya@st1., sliu@, chenyt@st2.}k.hosei.ac.jp

Abstract

and operations by using mathematical notation and a good modularity of the entire specification architecture by using condition data flow diagrams. We design and implement a tool to support the function-path review method.

Program review is an effective means for enhancing software quality. In this paper we describe the design of a software tool to support our proposed "function-path" approach to reviewing programs based on SOFL specifications. The approach includes four steps: (1) deriving all the functional scenarios from a formal specification, (2) generating all the necessary program paths in a program, (3) establishing the mapping between the functional scenarios in the specification and the program paths as implemented functions in the program, and (4) reviewing all the program paths against their functional scenarios in the specification.

2

Function-path Approach

The relation between a specification and its program can be defined by a function i .

M Definition 1 Let S = {f ‚f ‚...‚fn } be a specification containing functions f ‚f ‚...‚fn and P = {p ‚p ‚...‚pm } be a program containing program paths p ‚p ‚...‚pm . P satisfies S if and only if there exists a function Mi from S to P that satisfies the following condition: Mi : S → power(P ) ∀f ∈S ∃q∈power P · Mi (f ) = q where power(P ) denotes the power set of P and Mi (f ) = q means that the set of program paths q correctly implements function f in the specification. Definition 2 The approach to reviewing program P against its specification S based on the mapping function Mi de1

1

2

2

1

1

1 Introduction

2

2

( )

Review has become a practical technique for static analysis to detect errors in software since Fagan proposed the software inspection technique in 1976 [1]. Unfortunately, since existing practices of software review are usually based on informal processes and checklists, there is a lack of rigor in software review methods and processes. For this reason, the automation of software review is extremely difficult, if not impossible. However, automated approach is important to reviewing large-scale and complex software systems. We propose a rigorous method [2] for reviewing programs that emphasizes the role of their formal specifications. The method uses a formal specification as a standard to check whether the corresponding program correctly implements all the functional scenarios defined in the specification. A functional scenario assigns a conditional activity which describes that a specific kind of output is generated by a specific kind of input. We choose SOFL (Structured Object-Oriented Formal Language) [3] as the target specification language, because it offers precise definitions of data

fined in Definition 1 is called function-path approach.

3 Design of a Software Tool Our tool is designed to support the proposed functionpath approach, and it consists of the functions and operations as shown in Figure 1. The tool can automatically derive the functional scenarios from a process in a SOFL specification, and derive necessary paths from a program. Furthermore, it can also transfer a program in Java into a semantically equivalent control flow diagram to help the user understand its structure and semantics. Based on the functional scenario and control flow diagram, the reviewer can easily map the SOFL specification to the Java program, and perform the review process.

∗ This work is supported by the Ministry of Education, Culture, Sports, Science, and Technology of Japan under Grant-in-Aid for Scientific Research on Priority Areas (No. 16016279).

1

Proceedings of the 10th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS’05) 0-7695-2284-X/05 $20.00 © 2005 IEEE

㪚㫆㫅㫊㫋㫉㫌㪺㫋㫀㫆㫅 㫆㪽㩷㪺㫆㫅㫋㫉㫆㫃㪄㪽㫃㫆㫎 㪄㪻㫀㪸㪾㫉㪸㫄

㪛㪼㫉㫀㫍㪸㫋㫀㫆㫅 㩷㫆㪽㩷㪽㫌㫅㪺㫋㫀㫆㫅㪸㫃㩷 㫊㪺㪼㫅㪸㫉㫀㫆㫊

a path is derived by grouping the statements and conditions based on the true-evaluation and false-evaluation of all the conditions used in conditional and iteration statements. For example, from the conditional statement if (x) then S1 else S2 we derive two paths (or parts of two program paths): x(true); S1 and x(false); S2 . We implemented an algorithm for automatic generation of program paths from a program in Java. When the keyword (e.g., ‘if ’) of a statement (e.g., ‘if (b) S1 else S2 ’) is identified, the algorithm invokes the corresponding operation to deal with the statement to analyze its syntactical structure. As a result, an AST is constructed. The AST is employed as the basis for automatically constructing an equivalent control flow diagram of the program, which is more comprehensible than the textual expression of the program and therefore is helpful for the reviewer to understand the program during a review process.

㪞㪼㫅㪼㫉㪸㫋㫀㫆㫅㩷㫆㪽 㩷㫇㫉㫆㪾㫉㪸㫄㩷㫇㪸㫋㪿㫊

㪜㫍㪸㫃㫌㪸㫋㫀㫆㫅 㪸㫊㫊㫀㫊㫋㪸㫅㪺㪼

㪪㫌㫇㫇㫆㫉㫋㩷㪽㫆㫉㩷 㪸㫊㫊㫆㪺㫀㪸㫋㫀㫆㫅㩷㩷㩷

㪣㪼㫏㫀㪺㪸㫃㩷㪸㫅㪻㩷㫊㫐㫅㫋㪸㫏㩷 㪸㫅㪸㫃㫐㫊㫀㫊

㪞㪼㫅㪼㫉㪸㫋㫀㫆㫅㩷㫆㪽 㫉㪼㫍㫀㪼㫎㫊㩷㫉㪼㫇㫆㫉㫋㩷

Figure 1. Overall structure of the review tool.

3.1 Derivation of Functional Scenarios Any predicate expression can be transformed into an equivalent Disjunctive Normal Form (DNF) by applying the rules in the predicate calculus. We used the basic idea of [4] to transform its propositional structure in specification pe2 is transinto DNF. For example, the predicate pe1 pe2). A parser for lexical formed to (pe1 pe2) ( pe1 and syntax analysis is used to generate an Abstract Syntax Tree (AST) for a process specification, and then all the functional scenarios are derived based on the tree. Figure 2 describes the manipulation of data for converting a predicate to a DNF.

∧

㫇㪼㪈㩷㪓㪔㪕㩷㫇㪼㪉

㪩㫆㫆㫋 㪓㪔㪕 㫇㪼㪈

㫇㪼㪉

4 Conclusion and Future Research We described the design of a tool to support our proposed rigorous review method. The tool offers important functions to support the review based on SOFL specifications, including automatic generation of functional scenarios from a specification, the generation of program paths from a program, and the construction of control flow diagrams for programs. We plan to evaluate the effectiveness of our tool for applying in practice.

⇐⇒

∨ ¬ ∧¬

References

䋨㩷㩷㫇㪼㪈㺢㫇㪼㪉䋩㺣䋨䎀㫇㪼㪈㺢䎀㫇㪼㪉䋩 㪧㫊㪼㫌㪻㫆㩷㪺㫆㪻㪼㩷㪽㫆㫉㩷㫉㪼㪺㫆㫅㫊㫋㫉㫌㪺㫋㫀㫆㫅㩷 㪆㪆㪚㫉㪼㪸㫋㪼㩷㪸㩷㫅㪼㫎㩷㫃㪼㪽㫋㩷㫅㫆㪻㪼㪅㩷㩷 㪘㫅㪻㩷㫅㪼㫎㫃㪼㪽㫋㩷㪔㩷㫅㪼㫎㩷㪘㫅㪻㩿 㪩㫆㫆㫋 㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㫅㫆㪻㪼㪅㫃㪼㪽㫋㪅㪻㪼㪼㫇㪚㫆㫇㫐㩿㪀㪃㩷㩷㩷㩷 㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㫅㫆㪻㪼㪅㫉㫀㪾㪿㫋㪅㪻㪼㪼㫇㪚㫆㫇㫐㩿㪀㪀㪒 㫆㫉 㪆㪆㪚㫉㪼㪸㫋㪼㩷㪸㩷㫅㪼㫎㩷㫉㫀㪾㪿㫋㩷㫅㫆㪻㪼㪅 㪸㫅㪻 㪸㫅㪻 㪘㫅㪻㩷㫅㪼㫎㫉㫀㪾㪿㫋㩷㪔㩷㫅㪼㫎㩷㪘㫅㪻㩿㩷 㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㩷㫅㪼㫎㩷㪥㫆㫋㩿㫅㫆㪻㪼㪅㫃㪼㪽㫋㪅㪻㪼㪼㫇㪚㫆㫇㫐㩿㪀㪀㪃 㫇㪼㪈 㫇㪼㪉 㫅㫆㫋 㫅㫆㫋 㩷㩷㩷㫅㪼㫎㩷㪥㫆㫋㩿㫅㫆㪻㪼㪅㫉㫀㪾㪿㫋㪅㪻㪼㪼㫇㪚㫆㫇㫐㩿㪀㪀㪀㪒 㫇㪼㪈

㫇㪼㪉

[1] M. E. Fagan. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, 15(3):182– 211, 1976. [2] Fumiko Nagoya, Shaoying Liu, and Yuting Chen. An Investigation of the Approach to Specification-based Program Review through Case Studies. In Proceedings of 9th IEEE International Conference on Engineering of Complex Computer Systems, pages 249–258, Florence,Italy, April 14-16 2004. IEEE Computer Society Press.

㪆㪆㪚㫉㪼㪸㫋㪼㩷㪸㩷㫅㪼㫎㩷㪹㫀㫅㪸㫉㫐㩷㫅㫆㪻㪼㩷㪸㫅㪻㩷㫊㪼㫋㩷㫃㪼㪸㫍㪼㫊㪅㩷 㪙㫀㫅㪸㫉㫐㩷㫅㪼㫎㫅㫆㪻㪼㩷㪔㩷㫅㪼㫎㩷㪦㫉㩿㫅㪼㫎㫃㪼㪽㫋㪃㩷㫅㪼㫎㫉㫀㪾㪿㫋㪀㪒 㪆㪆㪩㫆㫆㫋㩷㪿㪸㫊㩷㫋㪿㪼㩷㪹㫀㫅㪸㫉㫐㩷㫅㫆㪻㪼㩷㫀㫅㫊㫋㪼㪸㪻㩷㫆㪽㩷 㩷㩷㩷㫆㫃㪻㩷㫅㫆㪻㪼㪅㩷 㫅㫆㪻㪼㪅㫇㪸㫉㪼㫅㫋㪅㫉㪼㫇㫃㪸㪺㪼㩿㫅㫆㪻㪼㪃㩷㫅㪼㫎㫅㫆㪻㪼㪀㪒 㫅㪼㫎㫅㫆㪻㪼㪅㫃㪼㪽㫋㪅㪸㪺㪺㪼㫇㫋㩿㫋㪿㫀㫊㪀 㫅㪼㫎㫅㫆㪻㪼㪅㫉㫀㪾㪿㫋㪅㪸㪺㪺㪼㫇㫋㩿㫋㪿㫀㫊㪀㪒

[3] S.Liu. Formal Engineering for Industrial Software Development Using the SOFL Method. Springer-Verlag, 2004.

Figure 2. Reconstruction of the parse tree.

[4] J. Dick and A. Faivre. Automating the Generation and Sequencing of Test Cases from Model-based Specifications. In Proceedings of FME ’93: Industrial-Strength Formal Methods, pages 268–284, Odense, Denmark, 1993. SpringerVerlag Lecture Notes in Computer Science Volume 670.

3.2 Generation of Program Paths Program review using the function-path approach requires the examination of the existence of one or more program paths for every functional scenario defined in the specification. Simply speaking, a program path in a program is a sequence of statements and conditions from the startstatement to an end-statement (it is possible to have more than one end-statements) in the program. Usually, such 2

Proceedings of the 10th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS’05) 0-7695-2284-X/05 $20.00 © 2005 IEEE