Artifact: Design Class
|
A class is a description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics. | |
| Other Relationships: |
Part Of Design Model
| |
|---|---|---|
| Role: | Designer | |
| Optionality/Occurrence: | Design Classes are a fundamental part of an object-oriented design approach. | |
| Templates and Reports: | ||
| Examples: | ||
| UML Representation: | Class. | |
| More Information: | ||
| Input to Activities: | Output from Activities: |
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
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 Guidelines: Design Class for more information.
