Rational Rose (version 2002)

• “The World's Leading Visual Modelling Tool”

 4+1 View of Software Architecture
• Software architecture consists of 5 concurrent
views [PK94]
• Rational Rose provides 5 different
perspectives/views.
• Selecting a view allows users to focus only on
what is architectural significant and meaningful
to them

in Rose: Component View

 View Target Audience:
Use-Case View End User

Logical View Analyst/Designer

Process View System Integrator

Deployment View System Engineer

Implementation View Programmer

 The Use-Case View
• From end-users' perspective

• Concerned with
– Understandability
– Communication
– Usability

• Use Case Model

captures system's intended functions and
interactions with environment
– use case diagrams
– use case flow of events
– supplemental documentation
– activity diagrams (optional)

• requirements specification.
Use Case Model can serve as a contract between
customer and developer instead of the traditional
text requirement specification A Use Case Diagram
 The Logical View
• Concerned with
functional requirements
of the systems
• From analyst/designer
perspective
• Includes
• use case realization diagrams
• class diagrams
• interaction diagrams
• statechart diagrams (optional)
• activity diagrams (optional)
A Class Diagram
 The Process View
• Presents a perspective for the System Integrators
• Non-functional requirements
Include:
– Performance
– Scalability
– Availability
– Fault Tolerance
– Throughput
– Concurrency and synchronization
• threads
• processes
Note: Not necessarily a single processing environment
 The Implementation View
• Called Component View in Rational Rose
• Aimed at Programmers
• Captures organization of static software modules:
– packaging, layering, and configuration management
• source code files
• data files
• components
• executable, etc.
• Concerned with derived requirements:
– ease of development
– software management
– reuse
– constraints imposed by programming language and development tools
– sub-contracting
– off-the-shelf components
4 Views + 1 Architectural View

in Rose:
Component View
Rational Rose diagrams in UML
Use Case

Deployment
Class

Component Object

Activity Collaboration

State Sequence
Rational Rose diagrams in UML
Use Cases plus Dynamic Views

Use Case

Deployment
Class

Component Object

Activity Collaboration

State Sequence

Logical plus Dynamic Views

 Rational Rose Environment

Standard menu
Standard toolbar

Diagram toolbar
(unique to each
type of diagram) Diagram
Browser window
window
(used to organize
and navigate) Can be hidden,
docked or floating
Status bar

Documentation
window
 The Documentation Window
• Used to create, view and modify text
documenting a selected item.
• May be visible or hidden; docked or
floating
– can be changed
• by selecting using View menu or
• right clicking on an item in the Documentation
Window
• The information added to the
documentation window automatically
updates the Documentation field in the
appropriate specification.
 The Diagram Window
• Allows you to create, update, and modify
graphical views of the current model.
• The Diagram Toolbox is unique to the
diagram type, and changes automatically
when you change types of diagrams.
• Select a diagram or add a diagram by
selecting it from those listed under the
appropriate view in the Browser Window
 The Specification Window

• Textual
representation of a
model element
that permits
viewing and
manipulating the
element's model
properties
• Open by right
clicking on a View
in the Browser
Window
 The Log Window
• Reports
– progress
– results
– errors
• Right click in the
Log Window to set
available action
• Ctrl-tab from Log
Windows returns to
previous diagram
 Developing the Use Case View
• In the Inception Phase
– Identify actors
– Identify principal use cases
• In the Elaboration Phase
– More detailed information is added
• associations
• stereotypes
– Additional use cases are added as needed
 Finding Actors
• Actors are NOT part of the system.
• Actors represent anyone or anything that interacts
with (input to or receive output from) the system
• Questions to help find actors

Who is interested in a certain requirement?

– Where is the system used within the organization?
– Who will benefit from the use of the system?
– Who will supply the system with information, use this information, and
remove this information?
– Who will support and maintain the system?
– Does the system use an external resource?
– Does one person play several different roles?
– Do several people play the same role?
– Does the system interact with a legacy system?
 Finding Use Cases
• Use case = a sequence of transactions performed by a
system that yields a measurable result of values for a particular
actor
• The use cases = all the ways the system may be used.
• Questions to help find use cases
• - What are the tasks of each actor?
– Will any actor create, store, change, remove or read information in the
system?
– What use cases will create, store, change, remove, or read this
information?
– Will any actor need to inform the system about sudden, external
changes?
– Does any actor need to be informed about certain occurrences in the
system?
– What use cases will support or maintain the system?
– Can all functional requirements be performed by the use cases?
 Finding Flow of Events
• Flow of events document is typically created in the
elaboration phase
• Each use case is documented with flow of events
– a description of events needed to accomplish required behavior
– written in terms of what the system should do, NOT how it should do it
– written in the domain language, not in terms of the implementation
• Flow of events should include
– When and how the use case starts and ends
– What interaction the use case has with the actors
– What data is needed by the use case
– The normal sequence of events for the use case
– The description of any alternate or exceptional flows
• Each project should use a standard template.
– See the previous slides in the requirements section for two suggested
templates used to document in detail each requirement.