The Word template can be bought through a template package. Case studies and reports are freely available in the table below.
Word Template
Case Study
Report
---
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 participates.
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.
Tailoring
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.
Artifacts >
Analysis & Design Artifact Set >
Design Class
