Information Technology Reference
In-Depth Information
diagrams are made up of classes, interfaces, relationships and collaborations. More
than one diagram may be necessary to describe a specific class, as varying levels of
specificity are needed to describe the class in a specific context.
6.6.6 Use Case Diagrams
This walkthrough will set out one example of how to go about a use case analysis.
There are many variations of how to develop a use case analysis, and finding the
right method can take time. First, a use-case realization describes how a particular
use case is realized within the design model, in terms of collaborating objects. The
Realization step sets up the framework within which an emerging system is
analyzed. This is where the first, most general, outline of what is required by the
system is documented. This entails a rough breakdown of the processes, actors,
and data required for the system. These are what comprise the classes of the
analysis.
Once the general outline is completed, the next step is to describe the behavior
of the system that will be visible to the potential user of the system. While internal
behaviors can be described as well, this is more related to designing a system
rather than gathering requirements for it. The benefit of briefly describing internal
behaviors would be to clarify with potential users that the system is not missing a
vital component externally due to it not being completed internally. The overall
goal of this step is to provide just enough detail to understand what classes are
required for the system. Too much detail can make it difficult to change the system
later on.
The next step narrows down the class list into those classes that are capable of
performing the behavior needed to make the system function successfully. If no
classes yet exist for a system, they must be created before this step can be com-
pleted. Classes can be created in many ways from many sources. A few examples
are: previous—but similar—systems, enterprise models, and data mining. Once
classes are created and narrowed down, relationships must be developed between
classes, now called analysis classes, which model the tasks of the system.
For each analysis class identified in the previous step, the responsibilities of the
class must be detailed clearly. This will ensure that an individual class has a task to
complete for which no other class in the system will also perform. The respon-
sibilities of the different classes should not overlap.
After detailing the responsibilities of each analysis class, the relationships
between the classes must be clarified next. There are four parts to this step. First,
identify the classes to be used. Then, identify possible relationships between the
classes. Next, for those with relationships, describe the nature of the relationship.
Finally, if applicable, identify the multiplicity of the relationship, meaning
determine how many of the first class correspond to one object in the second class
of the relationship.
