OO Design inspection checklist

This inspection checklist was originally created to support my OO courses, but turned out to be very effective for live use on projects. There is a companion checklist that covers use cases, Enjoy.

1. Does the development team understand the Use Cases that this design supports?
2. Can every member of the development team trace a Use Case Scenario through the design s using a small number of high level components?
3. Are the bulk of the Class names understandable and recognizable by the domain experts?
4. Do the Class names reflect the overall responsibility of the Class with respect to the Use Cases and the design?
5. Does the name of every Message reflect the intended outcome of the Method? (There should be no actions that could not be inferred from the Message name.)
6. Does the purpose of the Method match the overall responsibility of the Class that it is in? (Should the method be moved to another class, or does it belong in a different place in the inheritance hierarchy?)
7. Have the Class diagrams been drawn to emphasize the Classes used by a set of Use Cases?
8. Have Packages been used to group related Classes, and are dependencies between packages noted?
9. Are all parameters specified for every message on the interaction diagrams, and is there a way for the sending object to know the parameters it is passing?
10. Is flow of control obvious and correct within the interaction diagrams? (Hyperspace leaps are not allowed.)
11. Do Object names on Interaction Diagrams conform to coding guidelines?
12. Do Parameter names in Messages conform to coding guidelines?
13. For cases when there are more than one message to the same object, could this set of messages be replaced with a single message?
14. Is the design supposed to conform to the Law Of Demeter? (An object can only send Messages to Itself, It’s Attributes and passed parameters)
15. Does each Method have a set of Unit Tests defined?
16. Are all of the Failure Conditions from each Use Case tested for?
17. Does the implementation of every Method on a Class use at least one attribute or method in that class? (If a Method does not refer to it’s object, then it is just a utility function attached to the class, so it should be moved elsewhere.)
18. Overall, is the an even balance of responsibilities between the classes? (No Workaholics allowed)
19. Do the bulk of the Classes have an even balance of methods and attributes? (Trivial accessor methods do not count.)
20. For Messages with similar groups of parameters, can a simple data holder class be defined to simplify the message?
21. Whenever Inheritance is used, is the phrase "Sub-class is a kind of Super-class" correct for the life of the object?
22. Does Interface Inheritance make more sense than Implementation Inheritance?
23. Even where inheritance is not applicable, are consistent names used for similar Methods?
24. Are all Attributes private?
25. Is the visibility of Methods appropriate? (If a Method is not invoked from outside the class it should be private.)
26. Are there any unused Attributes or Methods on a Class? (Unused implies untested which implies code defects.)
27. Is Run Time Type Information used to switch behavior? (This is only needed for interaction with non-object systems.)
28. Are the Classes partitioned so that as many Classes as possible are platform independent?
29. Is the persistence and transaction policy defined?
30. For containers, is ownership of the contained objects defined? (If the container is deleted, are the contents also deleted?)
31. Has the design been tested by the development of an Executable Architecture?

(C) 2000 Software Craftsmanship Inc., all rights reserved.