Standards: Classes

Class	A class is a description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics.
Related Information:	Standards: Analysis Classes Standards: Design Classes Standards: Attributes - General Standards: Attributes - Analysis Standards: Attributes - Design Standards: Responsibilities Standards: Operations RUP Guidelines: Design Class RUP Artifact: Analysis Class

Topics

Introduction

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.

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).

Rose: Within Rose the documentation should be added in the "Documentation" tab of the class specification.