Chapter 1. OO Design Reviews

Revision History
Revision 1.9	1999-11-08	SR
Initial development of review checklist.
Revision 2.0	2006-01-25	RW
Model checks modified for UML version 2.0.

Table of Contents

	Note
	Portions of this checklist are copyrighted 1999, by Spencer Rugaber.

	Note
Legend: (c) for items that should be checked before the actual review; (d) for items that should be part of the detail design review;

Note

Legend:

(c) for items that should be checked before the actual review; (d) for items that should be part of the detail design review;

	Note
	For CS4911, the design review with the instructor will emphasize the VALIDATION section.

OBJECT CLASSES

(c) Does each attribute have an associated data type?
(c) Are all data types primitives? If the data type is not primitive, should it be replaced by an association to an existing class?
(d) Have initial values been specified for attributes?
(c) Are attributes marked as final (constant) if appropriate?
(c) Have derived attributes been indicated?
(c) Have class attributes been indicated?
Are attributes independent? If not, should they be marked as derived?
(d) Are naming conventions used? Are visibility modifiers (public, protected, private) as restrictive as possible?

(d) Are the arguments/results of the methods specified (name, type)?
For a polymorphic method, is it specified with a virtual method definition at the appropriate place in the class hierarchy?
(d) If the method is polymorphic, is its signature consistent?
(c) Are methods annotated to indicate whether they alter the state or merely examine (and possibly return) it ({query} or {update})?
(d) Are method preconditions indicated?
Is the function/responsibility of the method indicated? Does it exhibit high cohesion or could it be further decomposed?
(d) Are method state alterations/postconditions described?
(c) Are any of the methods restrictions on methods of a parent class?
(c) Have class methods been indicated?
(c) If an method in a class overrides a method in the parent class, is the return type of the overriding method a subtype of the return type of the overridden method (covariance)?
(c) If a method in a class overrides a method in the parent class, is the type of each parameter of the the overriding method a supertype of the type of the parameter in the overridden function (contravariance)?
If a method should not be overridden in a subclass, is it marked {final}?

(c) Is the cardinality/multiplicity of each association indicated?
Can ternary associations be replaced by binary associations meaningfully?
(d) Is navigability of each association indicated?
(c) Are role names given for each of the classes involved in a recursive association?
Have qualifications been provided to reduced the multiplicity of associations?
Can a one-to-one association be made multiple?
(c) Have any referential integrity constraints been indicated?
(c) Does each association require a persistent representation? If not, could it be better modeled as a method?
Should the association be normalized by introducing intermediate classes and associations?
If there are attributes or methods associated with an association, is an association class used?

(d) Are aggregations marked as composite or simple as appropriate?
Is the association truly an aggregation (part of) relationship, or should it be a normal association?

(c) Have common attributes of several classes been factored into a superclass?
(c) Is the association transitive? Does it comply with Liskov substitution principle?
(c) Have common methods been moved to the superclass?
(c) If a set of sibling subclasses differ only in the value of one attribute, could the situation be better modeled by an (enumerated) attribute in the parent class?
Does the set of subclasses completely partition the parent class?

Is there an interaction diagram for each non-trivial use case scenario?
Do messages in the diagram correspond to actual messages in the class diagram?
Do all classes in the diagram map to actual classes in the class diagram?
Are classes providing services the logical providers?
Does the sequence of messages in the diagram accomplish the goal of the use case?
Are object activations correctly shown?
Are alternatives, options and iteration correctly depicted?
Are static methods shown with the metaclass stereotype?

If the application uses a database:

Is an entity-relation diagram prepared for the data model?
Are there primary keys for each entity?
Is the data normalized?
Are foreign keys identified as required?
Are security and access (Create, Read, Update, Delete [CRUD]) rights documented?

Do all important UI screens have prototypes?
Do the prototypes follow good UI design principles? Are they appropriate for the target user demographic?
Is a navagibility graph or other documentation provided to show how screens are related?
Are there prototypes for each use case with a user-system boundary?

(c) Have all necessary diagrams of the problem space been provided (class, sequence, state, activity, deployment, component)?
Has the class hierarchy been examined for reuse possibilities?
Have potential frameworks been identified and documented?
Does the documentation include a description of the collaboration pattern (intra-framework protocol) for the framework?
Does the documentation include rationale discussing archtectural decisions and trade-offs?
Are all required architectural views provided? (conceptual, process, module, physical)?
Is there a dynamic description of the architecture that describes how the components will interoperate at runtime?
Have the system boundaries been specified?
Have appropriate architecural styles been used or considered?
Have appropriate design patterns been applied where appropriate?

Have the use cases/requirements document been examined to determine if all system constraints have been indicated as associations or been assigned to methods to satisfy?
Have the use cases/requirements document been surveyed for objects, attributes, and methods (nouns, adjectives, and verbs)?
(c) Are model features annotated with relevant use case/requirement numbers?
Have all requirements been addressed by one of the models?
Does the design exhibit conceptual integrity throughout?

Suggest five plausible modifications to the requirements/feature list. Evaluate which classes are affected by each change. Judge the value of the design by the localization of the changes.
Select a few likely scenarios for changes to the design. Create the corresponding interaction diagrams. Look at message traffic patterns. Detect situations where responsibility for a relatively small task is shared among several objects, resulting in heavy bilateral traffic.
Have a variety of viewpoints been examined (e. g. services, administration, debugging)?
For each quality attribute (testability, maintainability, portabilty, reliability, etc.), do a quick walk-through of the design emphasizing how the design fufills that attribute.