Artifact: 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. |
| Worker: | Designer |
| Optionality: | Using any of the ½entity╗, ½boundary╗, and ½control╗ stereotypes is optional. |
| Reports: | Class Report |
| 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
Entity Classes
- Entity classes are useful in all systems handling long-lived (persistent) objects.
Boundary Classes
- Boundary classes are useful in all systems that demand some sort of interaction between the system and its users, or between the system and other systems.
Control Classes
- Control classes are useful in all systems with complex behavior - systems that offer more than "fill-in-the-blank" use cases.
