Work Product Descriptor: Design Class

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.

Representation Options

UML Representation: Class.

A Class may have the following 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".

Stereotypes can be used to qualify design classes or to constrain implementation in some way. For example, a stereotype can be used to indicate that the class represents a particular programming language construct.

See Guideline: Design Class for more information.