Artifact: Design Class

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: |
Guidelines: Design Class |
|
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.
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 or
state diagrams. |
Owned by an enclosing package, via the aggregation
"owns". |
Classes relevant to the analysis of the system, and that are considered architecturally
significant, are identified and described during the elaboration phase. The remaining
classes are identified and described during the construction phase.
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.
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.
| |

|