Work Product (Artifact): Design Class
This work product is a description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics.
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.
Relationships
Container Artifact
RolesResponsible: Modified By:
Input ToMandatory: Optional: External:
  • None
Output From
Properties
Optional
PlannedYes
Illustrations
Reports
Tailoring
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.

More Information
Checklists
Concepts
Guidelines

©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.