Artifacts > Analysis & Design Artifact Set > Design Model... > Design Class
Artifact:
|
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. |
Role: | Designer |
Optionality: | Using any of the «entity», «boundary», and «control» stereotypes is optional. |
Reports: | |
More information: | |
Input to Activities: | Output from Activities: |
The following people use the classes:
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". |
Architecturally significant design classes are identified and described during the elaboration phase. The remaining design classes are identified and described during the construction phase.
A designer is responsible for the integrity of the class, ensuring that:
It is recommended that the designer responsible for a class is also responsible for its enclosing design package; for more information, see Design Package.
The use of the stereotypes «entity», «boundary», and «control» is optional. See Guidelines: Analysis Class for more information on these stereotypes. These may be used if it is seen to be useful in reasoning about the design, or to constrain the implementation in some way, for example, to use predefined constructs or implementation patterns appropriate to each of the stereotypes.
Rational Unified Process |