UML Representation: Class, stereotyped as <<boundary>>, <<entity>> or
<<control>>.
An analysis class may have the following properties:
-
name: the name of the class
-
description: brief description of the role of the class in the system
-
responsibilities: a listing of the responsibilities of the class
-
attributes: the attributes of the class
The analysis classes, taken together, represent an early conceptual model of the system. This conceptual model evolves
quickly and remains fluid for some time as different representations and their implications are explored. Formal
documentation can impede this process, so be careful how much energy you expend on maintaining this 'model' in a formal
sense; you can waste a lot of time polishing a model which is largely expendable. Analysis classes rarely survive into
the design unchanged. Many of them represent whole collaborations of objects, often encapsulated by subsystems.
Usually, simple note-cards, such as the example below, are sufficient (this is based on the well-known CRC Card technique - see [WIR90] for details of this technique). On the front side of the card, capture the
name and description of the class. An example for a Course in a course registration system is listed below:
|
Class Name
|
Course
|
|
Description
|
The Course is responsible for maintaining information about a set of course sections having a common
subject, requirements and syllabus.
|
|
Responsibilities
|
To maintain information about the course.
|
|
Attributes
|
|
Name
|
Description
|
Type
|
|
Course Title
|
The name of the course
|
string
|
|
Description
|
A short description of the course
|
string
|
|
On the back of the card, draw a diagram of the class:
Class diagram for Course
There is one analysis class card for each class discovered during the use-case-analysis workshop.
|
