Overview

The following is a summary of the steps you performed to record the results of Use-Case Analysis:

1. Create the analysis model (optional)

2. Create a use-case realization
3. Create diagrams for the use-case realization
4. Create analysis classes
5. Document class responsibilities
6. Create class diagrams to document analysis classes

1. Create the analysis model (optional)

The Artifact: Analysis Model is optional; the results of the Task: Use-Case Analysis are typically represented using the Artifact: Design Model. If a separate Analysis Model is to be maintained, it can be represented in Rational Rose by creating a package within the Logical View Named "Analysis Model".

In addition, separate Use-Case realizations (Analysis Use-Case realizations) will need to be created within this Model. See Tool Mentor: Creating Use-Case Realizations, and follow its steps, but create the realizations within the Analysis Model package.

The goal of an analysis model is to create a preliminary mapping of required behavior onto modeling elements in the system. In most cases, it omits the detail of a design model in order to provide an overview of the system functionality. The analysis model eventually transitions into the design model, and the analysis classes directly evolve into design model elements.

2. Create the use-case realization

See Tool Mentor: Creating Use-Case Realizations.

3. Create diagrams for the use-case realization

Use-case realizations may be captured in Rational Rose using either Collaboration Diagrams or Sequence Diagrams.

Collaboration diagrams tend to be easier to draw on a white-board, while Sequence diagrams portray object interactions and time-sequencing in a more intuitive way. The choice of which one to use is largely a matter of taste and project preferences.

For information on creating sequence diagrams, see Tool Mentor: Managing Sequence Diagrams.

For information on creating collaboration diagrams, see Tool Mentor: Managing Collaboration Diagrams

4. Create analysis classes

Use-Case analysis results in the Artifact: Analysis Class. These analysis classes are typically represented in the Design Model, but may be optionally maintained in a separate analysis model (see Artifact: Analysis Model). One of the most common groups of model elements found in the analysis model are the analysis classes, sometimes called analysis objects. The analysis classes are stereotyped classes that represent an early conceptual model for elements in the system that have responsibility and behavior. The three types of analysis classes are Boundary, Control, and Entity.

5. Document class responsibilities

To document a class responsibility, you add an operation to the class. When you enter the operation name, precede it with two forward slashes (//). Using these special characters indicates that the operation is being used to describe the responsibilities of the analysis class. Use the Documentation field of the Operation Specification to describe the responsibility. Note that you can move responsibilities (operations) and attributes between classes by dragging and dropping the operation from one class to another.

6. Create class diagrams to document analysis classes

To visualize the analysis classes, you should create a class diagram and populate it with your analysis classes. Use the Browse > Class Diagram > New to create and name a new diagram. Once you've created a new diagram, you can drag classes from the browser and drop them on the diagram.