Tool Mentor: Performing Use-Case
Analysis Using Rational Software Architect
Purpose
This section provides links to additional information related to this tool mentor.
The steps in this tool mentor match those in the activity. Links to topics
in the RSA online Help are marked with .
Overview
This tool mentor assumes that a Design Model and Use-Case Model have been created
in accordance with the Model
Structure Guidelines for Rational Software Architect. It also assumes that
the Use-Case Model has been populated with actors and use cases by following
Tool Mentor: Finding Actors and Use Cases Using Rational
Software Architect.
In this tool mentor, the following steps are performed for each use case in
the current iteration:
The following steps are performed once per iteration:
Additional Tool Information
Create the Use-Case Realization 
For each use case to be analyzed:
- Navigate to the package in which the use-case realizations are to be created.
See Model Structure Guidelines for
Rational Software Architect.
- Add a UML Collaboration to that package to represent the use case realization.
Give it the same name as the use case you are realizing. Optionally assign
to it the UML Keyword "Use Case Realization".
- In the package where you created the use case realization, create a free
form diagram. Drag the use case realization onto it. Now drag the use case
itself (from the use case model) onto the diagram. Draw a realization relationship
from the use case realization to the use case. At this point, the traceability
semantics have been established. You may now discard the free-form diagram
if you wish. From this point forward you will be able to use Topic Diagrams
and Traceability Analysis features to examine the derivation and refinement
relationships within your models.
For more information, refer to the
Collaborations
topic in the RSA online Help.
If the use-case description needs to be supplemented with additional internal
behavioral descriptions, this can be done by adding to an existing use-case
description created by following the steps outlined in Tool
Mentor: Detailing a Use Case with Rational Software Architect. If the internal behavior
of the system bears little resemblance to its external behavior, a completely
separate description may be warranted. In this case, attach a separate use-case
specification document (see Artifact:
Use Case for the template) to the collaboration , or if an external (linked)
document is not desired and the description can be concise, capture it in the
model documentation of the collaboration.
See Linking External Files to Model Elements.
- Navigate to the package that will contain the analysis classes. See
Model Structure Guidelines for Rational
Software Architect.
- Create one or more class diagrams to capture the analysis classes. See
Adding Class Diagrams to Model Elements.
- Add the analysis classes. See
Adding Class Diagrams to Model Elements.
- Assign analysis class stereotypes as appropriate. See
Applying Stereotypes.
- Add a brief description to each class. See
Documenting Model Elements.
- Optionally associate a document with each class. See
Linking External Files to Model Elements.
For more information, refer to the
Modeling Static Structure with Class Diagrams
topic in the RSA online Help.
- Navigate to the package in which the analysis-level use-case realization
(a UML Collaboration) was created.
- For each named sub-flow (scenario) of the use case, select the use-case
realization (i.e. the Collaboration) and add a Sequence Diagram to it. This
will also result in a UML Interaction being added to the Collaboration. Name
both the Interaction and the Sequence Diagram to match the name you assigned
to the use case flow in the use case model.
- In the model documentation for the Interaction, type a brief description
of the scenario that the sequence diagram depicts. Also copy and paste this
description to the model documentation of the sequence diagram itself. See
Documenting
Model Elements.
- Drag and drop actors (from the use case model) and analysis classes onto
the diagram to create objects for interaction. Or as needed, create new analysis
classes as participants in the interaction. See
Sequence
Diagrams.
- Add messages between the objects. Semantically speaking, these messages
are instance specifications of operations so you will map them to existing
operations or will create new operations as needed. See
Sequence
Diagrams.
- Describe each message (the element of the Interaction) in its model documentation
field. See
Documenting
Model Elements.
- To describe how the object behaves when it receives the message, assign
an operation to the message. (If the operation does not exist, add one to
the class as described under Describe
Responsibilities below, and then assign the operation to the message.)
Describe each operation (the element of the Analysis Class) in its model documentation
field.
- Define the signatures of any newly created operations.
For more information, refer to the following topics in the RSA online
Help:
Modeling Static Structure with Class Diagrams
Sequence Diagrams
- Describe responsibilities of the class by adding operations. See
Managing Attributes and Operations in Classifiers.
- Add a description to each operation. See
Documenting Model Elements.
Use the following steps below to describe attributes and associations.
The model documentation field of each attribute should describe what information
is to be stored in the attribute. This can be optional when the nature of the
information can be made obvious by providing a precise descriptive name for
the attribute. Specify multiplicity on each attribute.
See the
Adding Attributes to Classifiers in Diagrams
topic in the RSA online Help.
- Navigate to each use-case realization, and add a class diagram to show the
participants in the use-case realization; optionally, you can name it Participants.
See
Adding
Class Diagrams to Model Elements.
- Populate the diagram with all the classes that participate in the realization.
Discover which classes these are, by examining the lifelines in the sequence
diagrams you created previously.
- With the classes placed on the diagram, show any existing associations among
them - see
Relationships.
- Add new association relationships between classes as appropriate. Examination
of the sequence diagrams of the use case realization will reveal which classes
talk to each other, and what types are passed among them as message parameters.
This information will suggest what associations should exist, and in some
cases will suggest other (new or existing) classes that should be added to
the Participants diagram.
- Specify multiplicity on each association end. See
Specifying
Multiplicity of Association Ends.
- Specify navigability on each association end. Where multiplicity is greater
than 1, and you anticipate that a specialized type of container class will
be used to hold the collection of source class instances, make a note of it
either in the attribute's model documentation field or in a note on
the Participants diagram. See
Specifying
Navigability in Association Ends.
Give a name or stereotype the associations to indicate event dependencies. See
Relationships
and
Applying Stereotypes.
Examine the analysis classes and their associations. Identify and resolve
inconsistencies, and remove any duplicates.
The analysis mechanisms used by a class and their associated characteristic
do not need to be captured in a formal way. A note attached to a diagram
or an extension to the description of the class (see
Documenting Model Elements and
Adding Notes to Shapes)
is sufficient to convey the information.
Add traceability dependencies between the Analysis/Design-Model elements and
other models, as specified in project guidelines. For example, there may be
a separate business model, conceptual data model, or model of user interface
screens that you wish to trace analysis classes to. To do this:
- Create a diagram for Traceability. See
Adding Diagrams to Models
.
- Drag and drop elements to be traced onto the diagram. See
Adding Shapes
.
- Add the traceability dependencies (abstraction dependencies optionally stereotyped
<<trace>>). See
Adding Abstraction Relationships
- Generate a traceability report: model elements that have trace relationships, including implicit relationships, to and from implementations
are displayed in the Model Report view. See
Viewing Traceability Relationships
It may be helpful to publish any models to html format. Also note that diagrams
can be copied from RSA to Microsoft Word and other programs.
For more information, refer to
Publishing Models for Review Outside the Modeling Tool and to the following tutorials:
-
Generating Standard Model Reports
-
Generating Custom Model Reports
-
Publishing Models to Web
Tutorials:
Requirements: Create a Use-Case Diagram
Analysis: Create the Analysis Model
Analysis: Realize the Use Cases
Analysis: Create the Sequence Diagram
Samples:
Annotated Use Case Diagram
Annotated Sequence Diagram
Cheat Sheets:
Performing Use-Case Analysis
|