George Blank University Lecturer

1. George Blank University Lecturer

2. Object Oriented Code Inspection For Classroom Inspections in CIS 602 Java Programming

3. Code inspections • Code inspections were a common way of finding defects in procedural programming. Inspections are difficult in object-oriented programming because issues like inheritance, dynamic binding, non-local effects and polymorphism make the structure of object oriented code non-linear and difficult to inspect.

4. Automated Inspection • There are some tools available for the automated inspection of Java code. One such tool is the Code Inspection plug-in for IntelliJ IDEA. See http://www.jetbrains.com/idea/features/code_inspection.html • See a list of tools available at http://java-source.net/open-source/code-analyzers • Automated and manual inspections have some overlapping and some unique values.

5. XP inspections • In eXtreme Programming, inspections are seen as a virtue. The philosophy is “if inspections are good, do them all the time.” • The way this is accomplished in XP is through pair programming, in which all coding is done in pairs, with one person writing code and the other inspecting.

6. Value of Inspections • In my personal experience in Bell Labs, manual inspections had two major benefits: • They were excellent tools to improve quality by finding defects. • They were also excellent for training programmers. • It is for the second reason that I will use them in classroom sections of this course.

7. Distance Learning Students • Since inspections require co-location, I cannot require them for DL students. But I do require you to prepare documents for them the same as classroom students, and I encourage you to get together with each other to do inspections and learn from them.

8. Preparing for Inspection • Advance preparation makes inspections more effective. The following documents are required: • A print out of the code to be inspected • Planning documents for the classes and methods • Abstract specifications for the classes and methods • A summary of problems encountered while developing the code and their solutions.

9. Planning documents • Any of the following planning documents are acceptable for this course: • A fully dressed use case • An interaction diagram • A JUnit test suite (test-first programming) • Story cards and Class Responsibility Collaboration (CRC) cards (XP) • Operation contracts (usually for methods) • Choose the planning documents most appropriate for your code.

10. Fully Dressed Use Case

11. Interaction Diagrams • There are two interaction diagrams—sequence diagrams and communication diagrams. They are equivalent—if you do one in a tool like Rational Rose, it can automatically draw the other. • A sequence diagram is better for showing the order of operations, while a communication diagram is better for showing the messages for a particular object.

12. Sequence Diagram

13. Communication Diagram

14. Partial JUnit Test Suite for Queue

15. Story and CRC Cards • Story cards and CRC cards are informal tools, usually handwritten, often used in eXtreme Programming. XP depends on having a SME (subject matter expert) available to provide additional details to the developers as they code. • Story cards, like use cases, describe a particular scenario for the application. • CRC cards, one per class, describe the class, its responsibilities, and tells what other classes it collaborates with.

16. Story Card Each payroll period, a check and check stub has to be created for each employee. Timesheets Supply hours worked and overtime for hourly workers plus sick time and holidays for all workers. Taxes are calculated from tax details, and deductions are computed for Medical Plan, Dental Plan, Retirement Plan, and 401K Plan. A permanent Record of the Paycheck is maintained in the Pay Ledger.

17. CRC (Class Responsibility Collaboration) Cards Class Name Employee Superclasses Person Sub-classes Manager, Salaried Worker, Hourly Worker Responsibilities Collaborators Calculate Pay Timesheet, Paycheck, Pay Ledger Tax Details Manage benefits Medical Plan, Dental Plan. Retirement Plan, 401K Plan Manage Training Training Record, Certification, Professional License Maintain records Position, Employment History, Dependent

18. Operation Contract

19. Abstract Specifications • Write an abstract specification for each class and method to be inspected, as well as any classes and methods called from within the class. • The abstract specification should be brief and contain • A statement of the purpose of the class or method • A list of all state changes and outputs in terms of inputs and prior state.

20. Abstract Specification Class: Employee Purpose: Maintain information on an employee to be used for payroll, benefits, promotions, training, and legally required records Methods: newHire: create new Employee instance, change hire_date to date hired, add name, address, phone, position, social security number, create new Tax Details instance, create association with Employee instance addDependent: create new Dependent instance, create association with Employee instance (… etc)

21. Roles in Code Inspections • Moderator – controls the process and timing. Does not ask questions or identify defects. • Reader – the author of the code, who reads and explains each line, and responds to questions. • Inspector – (can be several) asks questions and identifies defects. • Recorder – (may be moderator) documents findings. Does not ask questions or identify defects.

22. Sample Inspection Report Date: November 17, 2005 Begin 2:30 pm End 4:00 pm Participants: Moderator G.Blank Reader T. Smith Inspectors P.Shah, A.Patel Recorder (moderator) Material Reviewed Size: 6 classes Author: T.Smith Name and Description: Multi Plotter, Homework # 7.3 for CIS 602 Inspection Outcome: No ReWork ReWork XX ReWork & Reinspection Defects Detected 12 Type 3 Algorithm errors 1 Wrong Message …

23. Reading Java Code • A Java application will begin in a method declared as: public static void main(String[] args) { • The main method must be declared in an accessible public class. It will be in a class that has the same name as it’s class file (not a private or subordinate class.) Control will be transferred to other classes using the new class name with parameters.

24. Starting an Applet • Applets cannot have a main method. Every applet needs at least one of these methods: init, start, or paint. • The browser uses init to notify the applet that it has been loaded and start to tell the applet that it can begin executing. Anything displayed in the applet must use a paint method. If there is no init, the applet starts in start. If no start, then it starts in paint.

25. Starting a Thread • A Java thread starts with a run method, usually by overriding the run method that is a default part of the thread class. • Event handling can be confusing when you read code. Specific events trigger handlers specified by action listener methods.

26. Inspection Checklist • The next few pages list a series of appropriate questions to ask at an inspection. There are many such checklists available on the web. I recommend that you use one in class.

27. Specification and design • Has all functionality specified been implemented? • Is there any excess functionality not specified? • Does all of the specified functionality execute correctly?

28. Initialization and declarations • Are all variables properly initialized before use? • Are all variables and class members of the proper type and mode? • Are all variables declared in the proper scope? • Is a constructor called when a new object is required?

29. Naming conventions • Are organizational standards being followed for naming classes, class members, variables, and parameters? • Are the names properly meaningful, self-documenting, and appropriate?

30. Method Calls • Are parameters listed in the proper order? • Is the correct method called (or is there another one with a similar name) ? • Are method return values used correctly?

31. Arrays • Are there any off-by-one errors in array indexing? • Are array indices protected against going out-of-bounds? • Are constructors called when a new array item is required?

32. Comparing Objects • Are all objects compared with .equals and not ‘==‘ ?

33. Formatting output • Are there any spelling or grammar errors? • Are new lines, spacing, and layout correct? • Are applets the right size? • Do applets use appropriate display and paint methods? • Do applets display correctly?

34. Algorithms • Are the order of operations, operator precedence, and parentheses correct? • Is division by zero possible? • Is there any integer division subject to improper rounding or truncation? • Is there any implicit type conversion? • Are comparison and Boolean operators correct?

35. Exceptions and Errors • Is all necessary code encapsulated in try and catch blocks? • Are all relevant exceptions caught? • Are all caught exceptions handled properly? • Can any legitimate operations be mischaracterized as errors or exceptions?

36. Flow of Control • Are there any switch cases that are not properly terminated by break or return? • Do all switch statements have a default branch? • Are all loops properly formed with correct initialization, increment and termination expressions?

37. Files • Are all files properly declared and opened? • Are all files closed properly, even after an error? • Are EOF conditions detected and properly handled? • Are all file exceptions caught?

38. Security • Are policy files provided where socket, port, or file access require them? • Are policies limited by host, port, and directory, or do they give too much access? • Is permission given for the access port (such as 80 for html) where needed?

39. Refactoring • Is the code properly reusable where appropriate? • Are classes, and methods of an appropriate size (not too small or large)? • Are there any specific refactorings that should be performed? • Is high cohesion and low coupling maintained? • Is any code unnecessarily complex?

40. Improper use of class library Inheritance implementation error Wrong message Wrong object Override error Data flow error Misuse local variable Scope boundary error Domain knowledge Algorithm error Need refactoring Missing operation Unnecessary code Syntax error Typical Defects

41. Bad smells in code • It takes significant coding experience to identify appropriate refactorings. Refactoring is based on “bad smells in code,” the recognition of practices that should be avoided. • Some typical refactorings (from my Refactoring lecture) are listed on the next slide. All are worth understanding for effective code inspections.

42. Add Parameter Change Association Reference to value Value to reference Collapse hierarchy Consolidate conditionals Procedures to objects Decompose conditional Encapsulate collection Encapsulate downcast Encapsulate field Extract class Extract Interface Extract method Extract subclass Extract superclass Form template method Hide delegate Hide method Inline class Inline temp Introduce assertion Introduce explain variable Introduce foreign method A few Refactorings

43. Bibliography • Alastair Dunsmore, Marc Roper, and Murray Wood, Practical Code Inspection for Object Oriented Systems, http://www.cas.mcmaster.ca/wise/wise01/DunsmoreRoperWood.pdf • Martin Fowler, Refactoring, Addison Wesley, 1999