The following is a summary of the steps you performed to record the results of Use-Case Analysis:
Create the analysis model
Create a use-case realization
Create diagrams for the use-case realization
Create analysis classes
Document class responsibilities
Create class diagrams to document analysis classes
1. Create the analysis model
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
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
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
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.