Semantic Inspection of Software Artifacts from Theory to Practice (Linköping studies in science and technology)

211 Pages·2004·0.68 MB·English

by  Tim Heyer

Linko¨ping Studies in Science and Technology
Dissertation No. 725
Semantic Inspection of Software Artifacts
From Theory to Practice
by
Tim Heyer
Department of Computer and Information Science
Link¨opings universitet
SE–581 83 Linko¨ping, Sweden
Linko¨ping 2001

Abstract
Providingmeansforthedevelopmentofcorrectsoftwarestillremainsacentralchallenge
of computer science. In this thesis we present a novel approach to tool-based inspection
focusing on the functional correctness of software artifacts. The approach is based on
conventional inspection in the style of Fagan, but extended with elements of formal
verification in the style of Hoare. In Hoare’s approach a program is annotated with
assertions. Assertions express conditions on program variables and are used to specify
theintendedbehavioroftheprogram. Hoareintroducedalogicforformallyprovingthe
correctness of a program with respect to the assertions.
Our main contribution concerns the predicates used to express assertions. In contrast
to Hoare, we allow an incomplete axiomatization of those predicates beyond the point
whereaformalproofofthecorrectnessoftheprogrammaynolongerbepossible. Inour
approachpredicatesmaybedefinedinacompletelyinformalmanner(e.g.usingnatural
language). Our hypothesis is, that relaxing the requirements on formal rigor makes it
easier for the average developer to express and reason about software artifacts while
stillallowingtheautomaticgenerationofrelevant,focusedquestionsthathelpinfinding
defects. Thequestionsareaddressedintheinspection,thusfillingthesomewhatloosely
defined steps of conventional inspection with a very concrete content. As a side-effect
our approach facilitates a novel systematic, asynchronous inspection process based on
collecting and assessing the answers to the questions.
Wehaveadaptedthemethodtotheinspectionofcodeaswellastheinspectionofearly
designs. More precisely, we developed prototype tools for the inspection of programs
written in a subset of Java and early designs expressed in a subset of UML. We claim
that the method can be adapted to other notations and (intermediate) steps of the
softwareprocess. Technically,ourapproachisworkingandhassuccessfullybeenapplied
to small but non-trivial code (up to 1000 lines) and designs (up to five objects and
ten messages). An in-depth industrial evaluation requires an investment of substantial
resources over many years and has not been conducted. Despite this lack of extensive
assessment, our experience shows that our approach indeed makes it easier to express
and reason about assertions at a high level of abstraction.
iii
iv
Acknowledgements
Firstofall,IwouldliketothankmysupervisorsUlfNilsson,AndersTo¨rne,andStaffan
Bonnier,fortheirinspiringideasandmanyfruitfuldiscussions. Furthermore,Ithankthe
rest of the members of the Theoretical Computer Science Laboratory (TCSLAB) and
the Real-Time Systems Laboratory (RTSLAB) for the good and stimulating working
environment.
I am grateful to Ulf Hammar and Stefan Frennemo at ABB Industrial Systems AB for
remarksthathaveledtoimprovementsofthesemanticcodeinspectionapproach. Many
thanks also to P¨ar Emanuelson, Tony Olsson, and Jan Lindgren at Ericsson SoftLab
AB. Their experience in the development of large-scale, industrial software helped to
improve the semantic design inspection approach. Furthermore, I would like to express
my gratitude to NUTEK and VINNOVA for their financial support.
Last, but certainly not least, I thank my wife Katrin Wand and my family for their
patience and for enduring our long separation.
v
vi
Contents
1. Introduction 1
2. Background 5
2.1. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Our Approach 11
4. Code Inspection 19
4.1. Specification of Java Programs . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. Our Java Subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2. Class Invariants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3. Interface Specifications. . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.4. Other Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Program Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3. The Generation of Questions . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.1. Prerequisites and Limitations . . . . . . . . . . . . . . . . . . . . . 31
4.3.2. An Axiomatic Semantics. . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.3. Applying the Semantics to Generate Verification Conditions . . . . 39
4.4. A Prototype Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
vii
Contents
4.4.2. Using the Protoype. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.3. Possible Extensions to the Prototype . . . . . . . . . . . . . . . . . 45
4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5.1. Railway Interlocking Systems . . . . . . . . . . . . . . . . . . . . . 46
4.5.2. Implementation of an Interlocking System . . . . . . . . . . . . . . 48
4.5.3. Inspection of the Table Generator . . . . . . . . . . . . . . . . . . 58
5. Design Inspection 67
5.1. Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2. Specification Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3. Design Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.1. Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.2. Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.4. The Generation of Questions . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.4.1. Prerequisites and Limitations . . . . . . . . . . . . . . . . . . . . . 90
5.4.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.4.3. Simplifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.4.4. Alternatives and Extensions . . . . . . . . . . . . . . . . . . . . . . 110
5.5. A Prototype Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.6. An Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.6.1. The Use-Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . 118
5.6.2. The Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 119
5.6.3. The Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.6.4. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.6.5. Omitting a Message . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.6.6. Intermediate Assertion to Weak. . . . . . . . . . . . . . . . . . . . 133
6. The Inspection Process 135
viii
Contents
7. Related Work 141
7.1. Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.2. Software Inspections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.2.1. Criticism to Conventional Inspection . . . . . . . . . . . . . . . . . 143
7.2.2. Inspection Based on Informal Annotations . . . . . . . . . . . . . . 145
7.2.3. Tool Support for Software Inspections . . . . . . . . . . . . . . . . 146
7.3. Formalizations of UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
7.4. Sequence Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.4.1. Message Sequence Charts . . . . . . . . . . . . . . . . . . . . . . . 149
7.4.2. Live Sequence Charts . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.5. Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7.5.1. Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7.5.2. Dynamic Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.5.3. Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
8. Conclusion and Future Work 153
A. Topology.java 167
B. LockTab.java 173
C. ExclTab.java 181
D. TableGen.java 183
E. Assertions 189
E.1. Use-Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
E.2. Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
E.3. Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
ix
Contents
F. Questions 195
x