Does each class diagram have a mission statement?
Each class diagram should have an explicit mission statement defining the intent or purpose of the diagram. This is
usually shown in a comment at the upper left hand corner of the diagram.
Typical missions include
-
Showing the elements realizing an analysis or design collaboration
-
Showing a generalization taxonomy
-
Showing the structure of a single class (e.g. nested parts)
-
Showing the features of a single class (e.g. attributes, operations, ports, and interfaces
|
Does the diagram show all elements relevant to the mission of the diagram?
The diagrams should show all elements relevant to the purpose of the diagram. These may include the following:
-
Classes
-
Objects
-
Parts
-
Ports
-
Interfaces
-
Constraints
-
Requirements
-
Event Receptions
-
Operations
-
Attributes
-
Packages
|
Do all structural elements have singular nouns for names?
All classes, objects, and attributes are things and so should have noun or noun phrases for names. The names should be
singular, since relations show multiplicity not names. |
Are PIM Classes from problem domain vocabulary?
Class diagrams showing analysis collaborations (from the Platform Independent Model) should name classes, object,
attributes, operations, functions, services, etc. from the problem domain vocabulary not from the solution
technology or design domain. |
Are all reusable classes defined within a common shared model or package?
To facilitate reusability, it is recommended that shared and reusable classes be put into a shared common model or package. |
Do all operations and events have strong verb names?
An operation or event indicates a behavioral thing and so should have a verb or verb phrase for its name. |
Are only necessary features public?
Following the principle of encapsulation, class features that don't need to be shared should be made protected or private.
Attributes should always be thus protected, and when necessary, access should be provided through mutator and accessor
methods. |
Are friend dependencies used infrequently?
Friend dependencies should be used when class are inherently tightly coupled and so it makes sense to bypass the normal
access rights; however, this should be an infrequent occurrence. A friend dependency should meet an explicit need not
easily otherwise met. |
Are usage dependencies only used when a class is indirectly used?
The usage dependency forces the class to be in the compilation scope and is commonly used only when a class is used
indirectly by another, such as when an operation uses a formal parameter typed by the used class but the main class does
not have another relation to the used class. |
Is port usage limited inside subsystems and components?
Ports are a means of connecting to parts across an encapsulation boundary. However, they take up extra computing cycles and
use extra memory so their use should be limited to providing access to parts. They should not, in general, be used to
connect elements within the same encapsulation scope. |
Do all ports have explicitly defined interfaces?
Ports are typed by the interfaces they provide and/or require. Each port should have at least one interface that defines
its contract but may have more. |
Are ports named in terms of their semantic content?
Port names should reveal their usage or content. |
Do interfaces only expose essential detail?
Interfaces should avoid exposing implementation details. For example, an ordered container should have operations such as
first() and next() but not leftChild() and rightChild() since the latter expose the implementation as a binary tree. |
Are Quality of Service constraints explicitly depicted?
Quality of Service - if within the scope of the diagram's mission - should be shown as constraints on effected elements,
such as relations, interfaces, classes, operations, and attributes. |
Whenever a class invokes services of another, is an explicit association required?
Association depict the relation between classes that allows one class to invoke the services of another. |
Is multiplicity depicted at the role ends of all associations?
Multiplicity is a crucial piece of information and so should be depicted on all kinds of associations (including
aggregation and composition). The exception is the whole end of a composition which is, by definition, always '1'. |
Are default names not used?
Tools often provide default names for classes, attributes, operations, role ends, etc. These should all be renamed to
semantically relevant names. |
Do all elements at a non-unary association role end serve the same semantic purpose?
If a role end has a multiplicity greater than 1, then the objects at that end should be interchangeable in terms of their
purpose. For example, a waveform may contain 20,000 data points, but each data point serves the same semantic purpose as
all the rest. |
Does the diagram use different associations for semantically distinct roles?
If a class relates to another in more than one semantic way, there should be an association for each distinct semantic
purpose. For example, a controller may relate to a data queue class in two ways (one per instance), one for input data and
one for output data. This are semantically distinct intents and so require two associations. |
Are the associations unidirectional?
Most associations represent a client-server relation and so are really unidirectional. Occasionally, an association
represents a peer-peer relation; in this case, a bidirectional association is appropriate. |
Do all associations use the same line style?
Associations of all kinds - association, aggregation, and composition, should all use a common line style to aid
readability. This might be straight, curved, or (most common) rectilinear. |
Is a composite responsible for creation and destruction of the part?
When there is a composition relation, the composite whole should be responsible for both the creation and destruction of
the part. |
Does generalization only depict "is a kind of" ?
Sometimes generalization is (incorrectly) used to depict "is a use of". For example, a elevator "UpButton" is not a
different kind of button than a "DownButton" and so these are not different subclasses of "Button". Instead,
"upButton" or "downButton" should be used as the association role name since it depicts a usage of the instance. |
Does parameterization specializes classes on data type, and generalization specialized on behavior?
Classes specialized by inheritance (generalization) perform different operation implementation on the same data types;
parameterized classes perform the same operation implementation on different data types. |
|