|
General
-
The name of the class clearly reflects the role it plays.
-
The description of the class clearly conveys the purpose of the class.
-
The class represents a single well-defined abstraction.
-
The class's attributes and operations are all essential to fulfilling the responsibilities of the class.
-
Each class represents a small, consistent and unique set of responsibilities.
-
The responsibilities of the class are well-defined, clearly stated, and clearly related to the purpose of the
class.
-
Each class is relatively self-contained, and is loosely coupled to other classes.
-
The responsibilities of the class are at a consistent level of abstraction (i.e. high-level (application-level)
and low-level (implementation-level) responsibilities are not mixed).
-
Classes in the same inheritance hierarchy possess unique class attributes, operations and relationships (i.e.
they inherit all common attributes, operations and relationships).
-
The complete life-cycle of an instance of the class is accounted for. Each object is created, used, and removed
by one or more use-case realizations.
-
The class satisfies the behavioral requirements established by the use-case realizations.
-
All requirements on the class in the requirement specification are addressed.
-
The demands on the class (as reflected in the class description and by the objects in sequence diagrams) are
consistent with the class's state machine.
-
All responsibilities of the class are related, such that it is not possible for the class to exist in a system
where some of its responsibilities are used, but not others.
-
No two classes have essentially the same purpose.
|
Generalization/Specialization
-
The generalization hierarchy is balanced, such that there are no classes for which the hierarchy is unusually
flat or deep.
-
Obvious commonality has been reflected in the inheritance hierarchy.
-
There are no superclasses which appear to be merges of the attributes of the subclasses.
-
There are no intermediate abstract classes in the inheritance hierarchy with orthogonal properties, examples of
which include duplicated subclasses on both sides of an inheritance tree.
-
Inheritance is used to capture common design abstractions, not primarily for implementation considerations,
i.e. to reuse bits of code or class structure.
|
Naming Conventions
-
Class names indicate purpose.
-
Class names follow the naming conventions specified in project design guidelines.
|
Operations
-
The name of each operation is descriptive and understandable.
-
The state machine and the operations are consistent.
-
The state machine and operations completely describe the behavior of the class.
-
The parameters of each operation are correct in terms of both number, name and type.
-
Implementation specifications for each operation, where defined, are correct.
-
Operation signatures conform to the standards of the target programming language.
-
Each operation is used by at least one use-case realization.
|
Attributes
-
All relationships of the class are required to support some operation of the class.
-
Each attribute represents a single conceptual thing.
-
The name of each attribute is descriptive, and correctly conveys the information it stores.
|
Relationships
-
The role names of aggregations and associations describe the relationship between the associating and
associated classes.
-
The multiplicities of the relationships are correct.
|
State Machines
-
The state machine is as simple as possible while still expressing the required behavior.
-
The state machine does not contain any superfluous states or transitions.
-
The state machine has a clear context.
-
All referenced objects are visible to the enclosing object.
-
The state machine is efficient, and carries out its behavior with an optimal balance of time and resources as
defined by the actions it dispatches.
-
The state machine is understandable.
-
-
The state and transition names are understandable in the context of the domain of the system.
-
The state names indicate what is being waited for or what is happening, rather than what has happened.
-
The state and transition names are unique within the state machine (although not a strict requirements,
it aids in debugging to enforce unique names).
-
Logical groupings of states are contained in composite states.
-
Composite states have been used effectively to reduce complexity?
-
Transition labels reflect the underlying cause of the transition.
-
There are no code fragments on state transitions which are more than 25 lines of detail code; instead,
functions have been used effectively to reduce transition code complexity.
-
State machine nesting has been examined to ensure that nesting depth is not too deep to be
understandable; one or two levels of substates are usually sufficient for most complex behaviors.
-
Active classes have been used instead of concurrent substates; active classes are nearly always a better
alternative and more understandable than concurrent substates.
-
In real-time systems, capsules have been used to represent logical threads of control.
-
Error or maintenance states have been accounted for.
-
Substates have been used in lieu of extended state variables; there is no evidence of transition guard
conditions testing several variables to determine which to state the transition should occur.
-
The state machine does not resemble a flow chart.
-
The state machine does not appear to have been overly de-composed, consisting of nested state machines with a
single sub-state. In cases where the nested sub-state is a placeholder for future design work or subclassing,
this may be temporarily acceptable providing that the choice has been a conscious one.
|
|
