General

  • Does the name of each class clearly reflect the role it plays?
  • Does a class define any attributes, responsibilities, or operations that are not functionally coupled to the other attributes, responsibilities, or operations defined by that class?
  • Are there any class attributes, operations or relationships that should be generalized, that is, moved to an ancestor?
  • Is the complete life-cycle of an instance of the class described? Each object must be created, used, and removed by one or more use-case realizations.
  • Are all specific requirements on the class in the requirement specification addressed?
  • Are the demands on the class (as reflected in the class description and by the objects in sequence diagrams) consistent with any state diagram that models the behavior of the class and its objects?
  • Does the class represent a single well-defined abstraction? If not, consider splitting it.
  • Do the classes offer the behavior the use-case realizations and other classes require?
  • Are the responsibilities of the class at a consistent level of abstraction? A mixture of abstract (application-level) and low-level (mechanical) responsibilities indicates that the class could be split up into smaller classes, e.g., an application-level class and a lower-level class implementing a required data structure or mechanism.
  • Does the class have responsibilities which are not completely related? Would it be possible for the class in question to exist in a system where some of its responsibilities were being used, but not others? If so, this indicates that the class is an aggregate that needs further decomposition. Classes should have a minimal number of clearly related responsibilities.
  • Are some class purposes semantically identical and thus indicative of redundant or overlapping classes? Are they so similar as to be nearly identical? This may indicates a missing abstraction, where commonality can be captured in a super class, or a subset of responsibilities can be implemented by one or more component actors which can be reused.
  • Does each class have a well-defined responsibility? Is the definition clear?
  • Is the purpose of an class too broad?  Does it handle too many purposes? It may be a candidate for an aggregate class instead, with the multiple purposes handled by the aggregated classes.
  • Is the purpose of the class too narrow, with little behavior? Should it be combined with another class?

Generalization/Specialization

  • Compared to the model as a whole, is the depth of the generalization hierarchy for the class very flat or overly deep?  This can be an indication that the designer may not be using generalization appropriately?
  • Has obvious commonality been reflected in the inheritance hierarchy?
  • Is there evidence of inheritance inversion (superclasses appear to be merges of the attributes of the subclasses)?
  • Does the inheritance hierarchy contain intermediate abstract classes with orthogonal properties? This manifests itself with duplicated subclasses on both sides of an inheritance tree. For example, class vehicle has subclasses 2-wheeled and 4-wheeled, each of which have subclasses gas-powered and electric-powered. How do you decide whether the first subclass criteria should be number-of-wheels or type-of-engine? These could separated out into component pieces (like engine and chassis, or whatever), to remove these considerations from the inheritance hierarchy for a vehicle.
  • Is inheritance being used primarily for implementation considerations? I.e. to reuse bits of code rather than as a way of capturing common design abstractions?

Naming Conventions

  • Do class names indicate use, as much as possible. Good class naming is an art. In particular naming super classes in an inheritance hierarchy is not easy. A good name captures abstractions, but is still specific enough to give an accurate idea of potential use.
  • Do class names follow the naming conventions documented in the Artifact: Design Guidelines?

Operations

  • Are the names of the operations descriptive, and are the operations understandable to those who want to use them?
  • Is the state description of the class and its objects' behavior correct?
  • Does the class offer the behavior required of it?
  • Are there too many parameters for an operation?
  • Have you defined parameters for each operation?
  • Have you assigned operations for the messages of each object completely?
  • Are the implementation specifications (if any) for an operation correct?
  • Do the operation signatures conform to the standards of the target programming language?

Attributes

  • Are all the relationships of the class related to potential changes in the rest of the classes?
  • Does each attribute a single conceptual thing?
  • Are the names of the attributes descriptive?
  • Are all the identified attributes and relationships actually needed by the use-case realizations?

Relationships

  • Do the role names of the aggregations and associations describe the relationship between the associated class to the relating class?
  • Are the multiplicities of the relationships correct?

Flaws that need to be fixed should give rise to change proposals.

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)