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: | - Report: Class Report |
| Examples: | |
| UML Representation: | Class. |
| More Information: | - Guideline: Building Web Applications with the UML - Report: Class Report - Checklist: Design Class - Guideline: Design Class - Guideline: Testing and Evaluating Classes |
| Input to Activities: - Class Design - Database Design - Design Testability Elements - Use-Case Design | Output from Activities: - Capsule Design - Class Design - Identify Design Elements - Identify Design Mechanisms - Incorporate Existing Design Elements - Subsystem 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
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.