Standards: Classes -
General
Topics
Introduction
In this section we outline the standards that are applicable to all classes.
For the specific standards related to the different kinds of classes see:
Standards: Analysis Classes
Standards: Design Classes
For information on attributes, responsibilities and operations see:
Standards: Attributes - General
Standards: Attributes - Analysis
Standards: Attributes - Design
Standards: Responsibilities
Standards: Operations
Background
A class is a description of a set of objects that share the same attributes,
operations, relationships and semantics. A class implements one or more
interfaces. Classes are used to capture the vocabulary of the system being
developed. Classes can be used to represent software things, hardware things and
even things that are purely conceptual.
When we are modeling we need to be careful about what we model as attributes and what
we model as associations between classes. The Rational Unified Process Modeling
Guidelines contains a good discussion of the criteria to consider when deciding whether to
model a concept as a set of attributes or to reify it as a class (See RUP Guidelines: Design Class). Remember you should model the
properties of objects as attributes if, and only if, they are properties of that object
alone (i.e. they are not and cannot be shared).
During analysis modeling we are really dealing with analysis types these will
be represented in Rose by the use of the Class model item (See RUP Artifact: Analysis Class). When
modeling classes during
analysis we will model the classes in terms of responsibilities, relationships and
attributes. The responsibilities represent the services offered by the class, the
relationships provide the ability for the classes to collaborate to deliver the services
that they offer and attributes represent a short hand way of describing a
"knowledge" responsibility. To quote Martin Fowler in "Analysis
Patterns: Reusable Object Models": "Conceptual models are linked to interfaces
(types) not implementations (classes)."
Naming Standards
Class names are short nouns or noun phrases drawn from the vocabulary of the system you
are modeling. The name should clearly explain what the class and its objects stand
for. The name can consist of several words if this makes its meaning clearer. It is
more important to make the name clear than to make it short.
Capitalize the first letter of every word in a class name; Party and
PersonalAccount. Class names should be singular rather than plural; Order and Task,
but not Orders and Tasks.
Avoid similar names and synonyms because they make it difficult to distinguish
classes.
General Documentation Standards
You should briefly describe each class. You should also briefly describe the
responsibilities of each class, including its objects' roles and behavior in the system.
Include this description on the class and use it as a summary of the responsibilities of
the objects of the class.
The names of abstract classes will be italicized. In Rose this is done
automatically when the Abstract check box is checked on the "detail" tab of the
class specification.
The format of the class description will be:
Description: [Class description goes here]
Responsibilities:
[Responsibility 1]
[Brief Description of responsibility]
Mechanisms
[Mechanism 1]
[Characteristics of mechanism]
Note: a lot of the Analysis Mechanisms are characterized by adding additional comments
to the class documentation the documentation standards for the individual
mechanisms are defined as part of the mechanism's themselves. Typical mechanisms
include Persistency and Error Handling (See RUP Concepts: Analysis Mechanisms and RUP Concepts: Design Mechanisms for further details).
For more information on documenting the responsibilities see Standards:
Responsibilities.
Rose: Within Rose the documentation should be added in the
"Documentation" tab of the class specification.
Stereotypes
The applicable set of stereotypes varies between Analysis and Design - See Standards: Analysis Class and Standards: Design Class for details.
Examples
None
|