Artifact: Design Class

Artifacts > Analysis & Design Artifact Set > Design Model... > Design Class

Design Class	A class is a description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics.
UML representation:	Class.
Role:	Designer
Optionality:	Using any of the «entity», «boundary», and «control» stereotypes is optional.
Reports:	Class Report <class name>
More information:	Guidelines:Designing Classes in Visual Basic Guidelines:Building Web Applications with the UML Guidelines:Design Class Guidelines:Testing and Evaluating Classes Checkpoints:Design Class
Purpose Properties Timing Responsibility Tailoring

Input to Activities:

Implement Component

Perform Unit Tests

Use-Case Design

Design Test Classes and Packages

Output from Activities:

Capsule Design

Identify Design Elements

Identify Design Mechanisms

Incorporate Existing Design Elements

Subsystem Design

Class Design

Purpose

The following people use the classes:

Implementers for a specification when they implement the classes.
Designers of other parts of the system to understand how their functionality can be used, and what their relationships means.
Use-case designers, to instantiate them in use-case realizations.
Those who design the next version of the system to understand the functionality in the design model.
Those who test the classes to plan testing activities.

Properties

Property Name	Brief Description	UML Representation
Name	The name of the class.	The attribute "Name" on model element.
Brief Description	A brief description of the role and purpose of the class.	Tagged value, of type "short text".
Responsibilities	The responsibilities defined by the class.	A (predefined) tagged value on the superclass "Type".
Relationships	The relationships, such as generalizations, associations, and aggregations, in which the class participate.	Owned by an enclosing package, via the aggregation "owns".
Operations	The operations defined by the class.	Owned by the superclass "Type" via the aggregation "members".
Attributes	The attributes defined by the class.	- " -
Special Requirements	A textual description that collects all requirements, such as non-functional requirements, on the class that are not considered in the design model, but that need to be taken care of during implementation.	Tagged value, of type "short text".
Diagrams	Any diagrams local to the class, such as interaction diagrams, class diagrams, or statechart diagrams.	Owned by an enclosing package, via the aggregation "owns".

Timing

Architecturally significant design classes are identified and described during the elaboration phase. The remaining design classes are identified and described during the construction phase.

Responsibility

A designer is responsible for the integrity of the class, ensuring that:

The class fulfills the requirements made on it from the use-case realizations in which it participates.
The class is as independent as possible of other classes.
The properties of the class, including its responsibilities, uni-directional relationships, operations, and attributes, are justified and kept consistent with each other.
The role of the class in bi-directional relationships in which it is involved is clear and intuitive.
The visibilities of its members, primarily operations and attributes, are correct. A visibility can be "public," "private," and so on.
The scope of its members, primarily operations and attributes, are correct. A scope is "true" for a type/class scope, and "false" for an object/instance scope.
The Special Requirements are readable and suit their purpose.
The diagrams describing the class are readable and consistent with the other properties.

It is recommended that the designer responsible for a class is also responsible for its enclosing design package; for more information, see Design Package.

Tailoring

The use of the stereotypes «entity», «boundary», and «control» is optional. See Guidelines: Analysis Class for more information on these stereotypes. These may be used if it is seen to be useful in reasoning about the design, or to constrain the implementation in some way, for example, to use predefined constructs or implementation patterns appropriate to each of the stereotypes.

Copyright © 1987 - 2001 Rational Software Corporation

Rational Unified Process