Rational Rose is a Computer Aided Software Engineering (CASE) tool. It is a graphical component modeling and development tool. CASE modeling tools shift the emphasis from coding to requirements and conceptual design.

Rational Rose
Getting Started with Use Cases

11/2/2003
Developed by Bruce La Plante - Examples from "Visual Modeling w/ Rational Rose 2002 by
Terry Quatrani and from "Systems Analysis Design Methods" by Whitten 6th Ed. Use Case Tips
from The Object Primer 3rd Ed. by Scott Ambler
Page 2
Introduction to Rational Rose
 Rational Rose is a Computer Aided
Software Engineering (CASE) tool.
 It is a graphical component modeling and
development tool.
 CASE modeling tools shift the emphasis
from coding to requirements and conceptual
design.
 It provides limited code generation from the
models created in Rational Rose.

11/2/2003
Page 3
Example: Course Registration System
 Registrar maintains in the system the list of valid
courses, students, and professors, and the course
schedule.
 Professors indicate the courses they will teach.
 Students register for the open registration period.
 When a student registers,
the billing system is updated.
 Professors can request a course roster.

11/2/2003
Page 4
Open Rational Rose
 Open Rational Rose from your start menu.
 Click Close on the Create New Model dialog.

11/2/2003
Page 5
Process of Requirements Use-Case Modeling
From Whitten Textbook Chapter 7.
 Objective is to elicit and analyze enough requirements
information to prepare a model that:
• Communicates what is required from a user perspective.
• Is free of specific details about how the system will be built or
implemented.
 To effectively estimate and schedule project, may need to
include preliminary “system implementation assumptions.”
 Steps
1. Identify business actors.
2. Identify business use cases.
3. Construct use-case model diagram.
4. Documents business requirements use-case narratives.

11/2/2003
Page 6
Select Use Case View

11/2/2003
Page 7
Create an Actor – e.g., Student Actor
 Right-click on Use Case View icon to open the
context sensitive menu and select NewActor
 Change Actor name to Student

11/2/2003
Page 8
4 Types of Actors
 Primary business actor
• The stakeholder that primarily benefits from the execution of the use case.
• e.g. the employee receiving the paycheck
 Primary system actor
• The stakeholder that directly interfaces with the system to initiate or
trigger the business or system event.
• e.g. the bank teller entering deposit information
 External server actor
• The stakeholder that responds to a request from the use case.
• e.g. the credit bureau authorizing a credit card charge
 External receiver actor
• The stakeholder that is not the primary actor but receives something of
value from the use case.
• e.g. the warehouse receiving a packing slip

11/2/2003
Page 9
Add Actor Specifications
 Right-click on Actor and select Open Specification.
 Enter Documentation for the Actor.

11/2/2003
Page 10
Add Other Actors (see below)
Actor Actor Description Documentation
Student
A person who is registered to take
classes at the University.
Professor
a person who is certified to teach
classes at the University
Registrar
the person who is responsible for the
maintenance of the Registration system
Billing System
the external system responsible for the
student billing system.

11/2/2003
Page 11
Identify Business Requirements
Use Cases
 During requirements analysis, document only the
most important use cases, often called essential
use cases.
 When looking for use cases, ask the following
questions:
• What are the main tasks of the actor?
• What information does the actor need form the system?
• What information does the actor provide to the system?
• Does the system need to inform the actor of any
changes or events that have occurred?
• Does the actor need to inform the system of any
changes or events that have occurred?

11/2/2003
Page 12
Create a Use Case –
 Right-click on Use Case View icon to open the context sensitive menu
and select NewUse Case
 Change use case name to Register for Courses

11/2/2003
Page 13
Add Use Case Documentation
 Right-click the use case; open it's specification; Add Documentation.
 E.g.: This use case is initiated by the Student. It provides the capability to create,
modify, and/or review a student schedule for a specified semester.

11/2/2003
Page 14
What makes a good Use Case?
 What level of detail should be included?
How big or little should they be?
 For example: Registration includes:
• Student selects courses
• Student selections update the course-offering
• Student's fee charges are assessed
 Is that 1 use case, or 3 use cases ? ? ?

11/2/2003
Page 15
What makes a good Use Case?
 Terry Quatrani's Guideline:
A use case typically represents a major piece of
functionality that is complete from beginning to end.
A use case must deliver something of value to an actor.
 In the registration example, all three
functions belong in one use case.

11/2/2003
Page 16
Add Use Case Glossary to Model
Use-Case Glossary
Use-Case Name Use-Case Description
Participating
Actors and Roles
Register for courses Allows student to create, update, review,
delete schedule entries.
Student,
Registrar
Maintain Course
Information
Allows Registrar to create, update, review,
delete course information in the catalog and
schedule of classes.
Registrar
Maintain Professor
Information
delete professor information.
Registrar
Maintain Student
Information
delete student information.
Registrar,
Student
Create Course Catalog Allows Registrar to create a course
schedule from the catalog for a semester,
with input from professors.
Registrar,
Professor
Select courses to teach Allows Professors to indicate which
courses they will teach in a semester.
Professor,
Registrar
Request course roster Professors can request and get a roster for
the courses they teach.
Professor

11/2/2003
Page 17
Create a Use Case Narrative
 Use the Use Case Templates in MS Word (from Templates)
 Copy to model use case sub-directory and rename.
 Link it to the Use Case.

11/2/2003
Page 18
Link Model Use Case to Narrative

11/2/2003
Page 19
Use Case Relationships
Association – a relationship between an actor and a use
case in which an interaction occurs between them.
• Association modeled as a solid line connecting the actor and the
use case.
• Association with an arrowhead touching the use case indicates
that the use case was initiated by the actor.
• Association lacking arrowhead indicates a receiver actor.
• Associations may be bidirectional or unidirectional.

11/2/2003
Page 20
Extension Use Case
Extension use case – a use case consisting of steps extracted
from a more complex use case in order to simplify the original
case and thus extend its functionality.
• Relationship between the extension use case and the use case it is
extending is called an extends relationship.
• Represented as an arrowheaded line beginning at the extension use
case and point to the use case it is extending.
• Each extends relationship line is labeled “<<extends>>.”

11/2/2003
Page 21
Use Case Includes a use case
Abstract use case – a use case that reduces
redundancy among two or more other use cases by
combining the common steps found in those cases.
• An abstract case is available for use by any other use case
that requires its functionality.
• Relationship between the abstract use case and the use case
that uses it is called a
uses (or includes)
relationship.
• Depicted as an
arrowheaded line
beginning at the
original use case
and pointing to the
use case it is using.
• Each uses
relationship line is
labeled “<<uses>>.”

11/2/2003
Page 22
Creating the Main Use Case Diagram
in Rational Rose
1. Double-click on the Main diagram in the Use
Case view to open the diagram [blank].
2. Click to select an actor in the browser and drag
the actor onto the diagram.
3. Repeat step 2 for each additional actor.
4. Click to select a use case in the browser and
drag the use case onto the diagram.
5. Repeat step 4 as necessary.

11/2/2003
Page 23
Adding Relationships/Associations
 You may need to customize the Rational Rose tool
bar to see all relationship icons. Right-click on
tool bar to customize it.

11/2/2003
Page 24
Adding Relationships/Associations
1. Click to select the Association icon or the Unidirectional
Association icon on the tool bar
2. Click on an actor initiating a communication and
drag the association line to the desired use case.
(See next slide for example diagram.)
Unidirectional Association
Association
Dependency Association

11/2/2003
Page 25
Associations / Relationships

11/2/2003
Page 26
Other Relationship Types
Include Use Case
 Click to select the Dependency Icon from the toolbar.
 Click on the base use case and drag the dependency icon to the
target use case. 
 Double-click on the dependency arrow to open the specification.
 In the Stereotype field, select include, and close the specification.
Extends Use Case
1. Click to select the Dependency Icon from the toolbar.
2. Click on the extending use case and drag the dependency icon to
the base use case. 
3. Double-click on the dependency arrow to open the specification.
4. In the Stereotype field, select extend, and close the specification.

11/2/2003
Page 27
Activity Diagrams
 Represent the Dynamics or Flow a the
system.
 They are like Flow Charts.
 Represents flow across Use Cases, or
 Represents flow within a Use Case

11/2/2003
Page 28
UML Notation for an Activity Diagram
 Activity
 Transition
 Decision
 Synchronization bars

11/2/2003
Page 29
Creating Activity Diagrams in Rational Rose
 Right-Click on the Use Case View in the Model Browser to open the
context menu.
 Select NewActivity Diagram. Give the diagram a name.
 Double click it to open it up.

11/2/2003
Page 30
Place Activities on the Diagram
 Select the Activity Icon from the toolbar, and place it on the diagram
 Name the the activity.

11/2/2003
Page 31
Add Flows and Decision Points
1. Draw Flow lines between activities.
2. Add a decision point (diamond).;
and name it.
3. Create a "guarded transition" by right
clicking the transition, opening the
specification; selecting the Detail
tab; and fill in the Guard Condition.
4. You can straighten the lines out by
selecting the line and clicking:
FormatLine StypeRectilinear

11/2/2003
Page 32
Add Syncronization
Bars,
And Activities
Note: Swim-lanes can be
added to show
responsibilities, but I have
not had good luck with
them in Rose.

11/2/2003
Page 33
Use Case Modeling Tips
 Association between actors and use cases
indicate the need for interfaces.
• Actor – User : Screens/Forms or Reports
• Actor – System: data file transfer or a real-time
data update.
 Write use cases under the assumption that you
can exit at any time without worry.
• Assume that some how the system will handle it.

11/2/2003
Page 34
 Do not over use re-use or get hung-up on
<<include>> and <<extend>
Guidelines:
• Do not try to do functional decomposition in a
use case. Purpose is to describe a series of
actions that offer value to the actors.
• If a use case is 1 sentence,
level of detail too low.

11/2/2003
Page 35
 Write use cases from the point of view of
the actor in the active voice.
• Point is to understand how the users will use
your system.
 Write scenario text, not functional
requirements. There are other models for
defining functional requirements.

11/2/2003
Page 36
 A Use Case is neither a Class specification
nor a Data specification.
• Use a Class Model or a Data Model for that
 Create a Use Case Template
• Customized for your company and your
development process.

11/2/2003
Page 37
 Organize Use Case Diagrams Consistently
• Common practice to draw inheritance and
extend relationships vertically.
• Include relationships are typically drawn
horizontally.
 System should respond to actions of actors.
• Receiver actors? (the exception)

11/2/2003
Page 38
 Alternative courses of action are important.
• Start with the “happy path” – the basic course
of action.
• Alternate courses are introduced to describe
potential usage errors, as well as business logic
errors and/or exceptions.
 Use Cases drive User Documentation –
which describes how to work with the
system. Use cases are a great starting point.

11/2/2003
Page 39
 Use Cases drive Presentations
Part of software development is communicating
your work efforts with project stakeholders.
Because use cases are written from the point of
view of your users, they contain valuable insight
to how they interact with the system.

11/2/2003
Page 40
Summary
 Use Cases are a great tool for recording the
requirements of a system
 Clients / End-users find them easy to
understand.
 Use case pictures give a good overview of
the system and use case narratives provide
more details about a specific use case.
 Activity Diagrams are useful for noting the
flow between and within use cases.

11/2/2003
Page 41
MS Visio Also Supports UML
 Explore Visio's UML Capabilities
 Open Visio and select UML
 Select the Use Case tab on the left side.
 Build a Use Case diagram.
 Can you link a Use Case Narrative?

Rational Rose is a Computer Aided Software Engineering (CASE) tool. It is a graphical component modeling and development tool. CASE modeling tools shift the emphasis from coding to requirements and conceptual design.

Recommended

Recommended

More Related Content

Similar to Rational Rose is a Computer Aided Software Engineering (CASE) tool. It is a graphical component modeling and development tool. CASE modeling tools shift the emphasis from coding to requirements and conceptual design.

Similar to Rational Rose is a Computer Aided Software Engineering (CASE) tool. It is a graphical component modeling and development tool. CASE modeling tools shift the emphasis from coding to requirements and conceptual design. (20)

More from saman zaker

More from saman zaker (14)

Recently uploaded

Recently uploaded (20)

Rational Rose is a Computer Aided Software Engineering (CASE) tool. It is a graphical component modeling and development tool. CASE modeling tools shift the emphasis from coding to requirements and conceptual design.