Inspections are a long drawn-out process that is of relatively little value from a productivity sense when compared to quick reviews. Inspections are more useful where zero-bug levels are sought. Inspections are not an appropriate forum for teaching IC techniques to the inspectors; special tutorial sessions should be used instead for that purpose. The focus in an inspection is on finding any remaining bugs.
Inspections and Intellectual Control
I won't go into the mechanics of inspection meetings here, except to cover the high points; see Gilb for details on inspection meetings. In a nutshell, the inspectors each spend serious time before the meeting (a couple hours each) studying the code, looking for problems. The meeting itself is then an item-reporting session that moves very quickly. Person A states a bug. The author verifies understanding, and the recorder records the bug. No discussion of other possible bugs or how to fix the bug is permitted. No discussion of sections of code that have no reported bug is permitted. The author then fixes the bugs and the recorder verifies that the fixes were made.
After an inspection or quick review is complete, one should add a line to the file saying who did it, when, and the ICL achieved.
Only ICL 9 code can be inspected. The inspectors should ask the following questions, among others:
- Is the spec complete? I.e., outputs are specified for each input case.
- Is the spec correct? I.e. the implementation delivers the specified postconditions, assuming the preconditions and the correct operation of called methods according to their specs.
- Is the spec clear? Wording must be unambiguous and fairly concise.
- Is the MSS complete? I.e. every calling order is listed.
- Is the MSS correct? I.e. no illegal calling orders are listed.
- Is the MSS clear? Could it be stated in pure english or MSS notation more understandably than it currently is?
- Is multithreading right? Check for recursive cases (which don't sync).
- Are exceptions handled?
- Are all lexicon conditions correctly handled?
- Are all superclass/interface conditions correctly handled?
When inspecting code that's commented in this way, first read all the level-1 comments, without looking at lower levels, to make sure they satisfy the overall method conditions. Then go to each level-1 section, and look at only the level-2 comments within it, and so on. There is a strong temptation to read the code sequentially, which means going in and out of all different levels one after another; train yourself to read just the level of interest or the IC advantages of hierarchical comments are lost.
Intramethod Spec Inspection
To prove correctness for a class that uses MSS, it's necessary that all callers coordinate to satisfy the MSS. That is, caller A and B may each separately obey the MSS for their calls on object O, but in combination they might well operate on O in invalid sequences. Verifiers must watch for this using control flow analysis. This means that all users of an object must document the call sequences they make to it as far as necessary for further uses of the object to be done correctly. So part of the postcondition for a class must be the specification of the current method sequence state for any affected objects.
There's a term for this: control flow analysis. The flow of control through the method must be correct for any possible arrangement of callers. For those methods whose preconditions require concerted action by all callers, the postconditions of each calling routine must document the new state of the control-flow-sensitive object.
T. Gilb, D. Graham, Software Inspection, 1993. An in-depth treatment of the details of running inspection sessions: who, where, what, when, and why.
| || |
March 25, 1996: created.
April 10, 1996: modified.
Copyright © 1996,
All Rights Reserved