1. Further Investigations into the Development and Evaluation of Reading Techniques for Object-Oriented Code Inspection Alastair Dunsmore, Marc Roper and Murray Wood Dept. Computer and Information Sciences University of Strathclyde Glasgow Scotland, UK marc@cis.strath.ac.uk

2. Introduction and Motivation Inspections have become established as an effective and efficient means of detecting defects Significant lack of information indicating how inspections should be applied to object-oriented (OO) code This paper presents the results of the development and evaluation of three reading techniques to support OO code inspections

3. Previous Work Systematic abstraction-driven inspection technique developed and evaluated + some evidence of success with delocalised defects - less so with defects associated with the dynamic model of OO software OO promotes delocalisation – observed as a significant problem

4. New Developments 1.Systematic –Aims to supports understanding and address delocalisation (employed previously). 2.Checklist –Aims to address defects missed by systematic approach’s linear strategy 3.Use-Case –Aims to address the dynamic aspects of OO code Devised three Reading Techniques with distinct aims:

5. Systematic Technique Code read in an ordered fashion – fewest dependencies first Abstract specification created for each method –Promotes deeper understanding –Provides a summary for reference in future inspections Any instances of delocalisation (external references) should be traced and resolved

6. public boolean isRegistered(String e) { boolean found = false; for (int i=0; i< theUsers.size() & !found; i++) if ((((Person)theUsers.elementAt(i)).getEmail()).equals(e)) found = false; return found; } Returns false if the input String e matches the email address of one of the Person elements in the user collection, otherwise returns false.

7. Checklist Set of specific questions aimed at focussing attention towards common OO defects 18 questions (1 page) built on historical data Schema: –where to look (class, method) –how to detect (questions grouped conceptually – inheritance, data referencing, messaging etc.) Ordered to support the inspector in building up an understanding and minimise context switches

8. For each class FeatureQuestion 1 2 3 InheritanceIs all inheritance required by the design implemented in the class? Is the inheritance appropriate? Class Constructor Are all instance variables initialised with meaningful values? If a call to super is required in the constructor, is it present? For each method 4 Data Referencing Are all parameters used within a method? 5 Are the correct class constants used? 6 etc…

9. Use-Case Based Strategy Examines the response to various input scenarios Does each object react correctly to all the possible ways in which it could be used? Scenarios derived from use cases and traced through sequence diagram –Focus on code when class under inspection is encountered Final state compared with that anticipated

10. Class under inspection Inspector refers to code at this point Scenario

11. Empirical Evaluation 69 3 rd year honours CS students split into 3 groups – one technique/group Code - ~200 lines of Java (2 classes) 14 Defects –seeded and naturally occurring Subjects trained and involved in the experiment Validity threats: –Selection, enthusiasm, learning, subjects, code, defects… 90 minutes to complete the inspection Null hypothesis – no significant difference between number of defects detected using the three techniques

12. Defect Detection Results (Individuals) Significant difference only at the 10% level 23 N = 14 12 10 8 6 4 2 0 Checklist Systematic Use-case No. of Defects

14. Defects discovered by at least 50% of inspectors Checklist Use-Case Systematic 1 2 4 5 7 8 9 11 12

15. Analysis Systematic –Effective with delocalised defects –Supports weaker subjects, and hinders better ones –Full benefits of abstract specifications not explored Checklist –Generally effective, except with errors of omission. –Largest number of false positives -> understanding? –Question construction is crucial - > potential instability? Use-Case –Most demanding. –Inspectors uncomfortable about incomplete coverage –Alternative point of reference -> errors of omission/ commission?

16. Conclusions Resolving delocalised references and understanding system dynamics are significant problems when inspecting OO code Three techniques developed to address these issues Would not discount any –Some evidence of techniques being complementary –Good degree of robustness –Further cost/benefit evaluation necessary in an industrial context Questions?