Checkpoints:
Design Classes
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.
| |

|