UML and RationalRose

UML and Rational Rose Notes
1
Objectives
 To become familiar with the Unified Modeling
Language (UML) notation
 To create UML diagrams
 To review and critique UML models
 To use the Rational Unified Process to do
object-oriented software development

 To use Rational Rose as a tool to develop UML
documents, models, diagrams
2
Requirements
 Introductory knowledge of object-oriented
terminology and concepts
 Have used some techniques for finding
classes, attributes, and associations (e.g.,

CRC, Shlaer-Mellor, Coad-Yourdon)
3
Organization
 Introduction
◦ Requirements Gatherings Approaches
◦ Traditional Deliverables
 Unified Modeling Language
◦ Rational Unified Process
◦ 4+1 Architectural Views and their Deliverables
 Use Case Model
 Logical View
 Process View
 Deployment View
 Implementation View (Component View in Rose)
 Using Rational Rose
◦ Case Study and Exercises
4
 Requirements Gatherings Introduction
– Goals and Challenges
– Standard Approaches
– Example Requirements List
– Documenting Operational Requirements
 Traditional Deliverables
– Requirements Specification Documents
– Analysis Diagrams:
 Context Diagram,
 Entity Relationship Diagram,
 Data/Control Flow Diagram
– Prototype
5
Requirements Gathering
© Dr. Maria M. Larrondo

Petrie, 2001 6
Goals of Requirements Gathering
 Find out what the users need
 Document needs in a Requirements
Specification
◦ Avoid premature design assumptions
◦ Resolve conflicting requirements
◦ Clarify ambiguous requirements
◦ Eliminate redundant requirements
◦ Discover incomplete or missing requirements
◦ Separate functional from nonfunctional
requirements
 Ensure Requirements Traceability
Petrie, 2001 7
Requirement Specifications seldom clearly
capture customer needs
What user wanted How customer described it How analyst specified it How designer implemented it

Petrie, 2001 8
Challenges in Requirements Gathering
 Consider a scenario illustrating the normal state of
flux:
Often you are using new business procedures, and
your job has changed to head development of a brand
new application your company has announced, and
you are scheduling training for you and your team to master
a new computer environment and new software development
techniques and new tools using a new programming
language,
how do you figure out and document how the new
application is supposed to work in a way that is clearly
understood by:
end users, analysts, training staff customers,
designers, support staff marketing staff,
implementers, maintenance staff,managers, testers, . . . ?

Petrie, 2001 9
Standard Approaches for
Requirements Gathering
 Elicit requirements through user interviews
 Gathering representatives of stakeholders:
* executives developers maintenance
users support staff ...
in one room at during uninterrupted session(s) to decide on
requirements under an experienced leader/consensus
maker:
Joint requirements planning (JRP)
 focus on what the system will do
Joint application design (JAD)
 focus on how the system will work
produce a document which includes a list of requirements
 Developing a Rapid Prototype

Petrie, 2001 10
Example Requirements List 1 (1
ofTable
3)of Requirements with review comments by Kulak & Guiney 1
Requirement Kulak and Guiney Comments

The system will support client inquiries from 4 access points: in Four access points are how; we should
person, paper-based mail, voice communication, and electronic focus on who needs access and from
communication (Internet, dial-up, and LAN/WAN where
The telephone system must be able to support an 800 number Can't use 888 or 877? Missing who needs
system what kind of access from where
The telephone system must be able to handle 97,000 calls/yr. and Valuable statistics. This requirement is
must allow for a 15% annual growth. It is estimated that 19% of actually pretty good.
these calls will be responded to in an automated manner and 81%
will be routed to call center staff for response. 50% of calls can be
processed without reference to the electronic copy of the paper file,
and approximately 50% will require access to system files.
For the calls that require access to system information, response "optical disk" is a design assumption.
times for the electronic files must be less than 20 seconds for the Response times are good non-functional
first image located on the optical disk, less than 3 seconds for requirements if not linked to design
electronic images on a server, and less than 1 second for data files. assumptions (hardware device types).
1
Daryl Kulak and Eamonn Guiney. Use Cases: Requirements in Context ,
Addison-Wesley, New York, NY, 2000.
[KG00p16-18]
Petrie, 2001 11
Example Requirements List 1 (2 of 3)
Table of Requirements with review comments by Kulak & Guiney
The telephone system must be able to support voice recognition of Pretty good one. Can you find anything
menu selections, touch-tone menu selections, and default to a wrong?
human operator. The telephone menu will sequence caller choices
in order of most frequently requested information to the least
requested
The telephone system must be able to provide a voice response This seems to be trying to provide some
menu going from a general menu to a secondary menu. pretty obvious advice to a dumb designer
The system must allow for the caller to provide address information "Through a digital recording"? This is a
through a digital recording and to indicate whether it is permanent. design assumption
The system must allow for the caller to provide address information Sound familiar? (It's redundant)
through voice recognition and to indicate whether it is permanent.
The telephone system must be able to store and maintain processor Simplify it: "The system must be able to
IDs and personal identification numbers to identify callers and to identify callers and route calls to the
route calls properly to the appropriate internal response telephone. appropriate internal response telephone".
The telephone system must be able to inform callers of the Great!
anticipated wait time based on the number of calls, average duration
of calls, and the number of calls ahead of them.
[KG00p16-18]
Petrie, 2001 12
The journal will contain entries for key events that have occurred This is a design for a journal. Why have
within the administration of an individual's account. The system it? What is its purpose?
will capture date, processor ID, and key event description. The
system will store pointers to images that are associated with a
journal entry as well as key data system screens that contain more
information regarding the entry.
If an individual double-clicks on an event in a member's journal, the Double-click is a user interface design
system will display the electronic information and the images assumption
associated with the event.
The system will restrict options on the information bar by processor This one has many user interface design
function. When an icon is clicked, the screen represented by the assumptions.
icon will be displayed and the system will display appropriate
participant information.
Note: Each requirement should have a number to provide traceability.
[KG00p16-18]
Petrie, 2001 13
6.7.1.2 The system must Too vague. Implies fiscal year has some impact on how customer transactions
provide the capability to are organized, but does not specify what that is. Implies some data entry, but
capture all of the customer needs to be stated more specifically. May be trying to make a statement about
transactions for fiscal year volume, meaning old transactions can't be archived until they are a year old?
6.7.1.3 The system will Saying "restricted" is OK, but details about the restriction (who can, who can't)
provide restricted remote should be stated clearly in this context. Also vague is the reference to remote
inquiry access (via dial-in) to inquiry. How remote? Saying "remote access" when referring to mobile
view images and data employees working in the field but still within a couple of miles of the office or
separately or simultaneously worldwide access. Can have huge implications on system.
6.7.1.4 The system will Makes several technical design assumptions. Barcoding is a solution, not a
barcode documents requirement. This system probably needs a way to identify each document
automatically prior to uniquely, but it doesn't have to be barcodes. If all existing systems use document
distribution. At a minimum, barcoding (not the case with this system), should write a nonfunctional
the codes will be used to requirements that states, "Unique identification of all documents will be done
identify to which work through barcoding". By specifying barcoding in the functional specifications,
queue the documents should changing to glyphs, optical character recognition (OCR) will be more difficult.
be routed within the The reference to queues makes an assumption about a workflow-package-
organization when they are oriented system. Better to state: "At a minimum, the unique id will ensure
returned routing to a specific worker in the organization when documents are returned."
[KG00p3-7]
Petrie, 2001 14
6.7.1.5 When a workflow is initiated, the Look at references to workflow. Requirements document has
system must be able to prefetch the specified a workflow solution! This whole entry is suspicious.
documents that are in electronic image Seems to be saying that we must cache documents by two different
format by document type or grouping of criteria: by type or by process. Criteria are good requirements, but
documents by process caching(prefetching) is a solution to address performance
problems.
6.7.1.6 The system must create an entry in Assumes presence of a journal file containing entries inserted when
the journal file whenever a letter is created a letter is created. Seems focused on front end ("do this") instead
of back end ("in order to get this"). Why put entries in a journal
file? To create a list of all letters created, when and by whom?
This would make a better, clearer requirement.
6.7.1.7 System must maintain list of Seems to be focused on how rather than what. Instead of
current, open work processes and identify specifying the steps a system must go through, clearly document
work process to be executed and workflow the end in mind. Example: "When a new document image is
queue for process. When documents are brought into the system, it should be routed to the worker who has
scanned, system determines whether there the account open for the same SSN as the new document and
is a process open for that SSN. If there is, should be made obvious to that worker. If no worker has an open
the system routes document to appropriate account, the document should be made available to any worker."
workflow queue, displays work process
script, and highlight current work process.
[KG00p3-7]
Petrie, 2001 15
Eliciting Operational Requirements

Problems with traditional ways of specifying problems:

1. customer may not adequately convey the needs of the user.

2. developer may not be an expert in the application domain,
which inhibits communications.

3. users and customers may not understand the requirements
produced by the developer

4. developer's requirements specifications typically specifies
system attributes such as
• functions, • performance factors,
• design constraints, • system interfaces and
• quality attributes,
but typically contains little or no information concerning
operational characteristics of the specified system.
[FT97] R. E. Fairley and R. H. Thayer, "The Concept of Operations: The Bridge from Operational Requirements to Technical
Specifications," Software Engineering, M. Dorfman and R. H. Thayer (eds.), IEEE Computer Society Press, Los Alamitos, CA,
1997.

Petrie, 2001 16
Guidelines for Operational Concept Document

Operational Concept Document (OCD) describes the mission of
the system, its operational and support environments, and the
functions and characteristics of the computer system within an
overall system.

Several guidelines and standards exist to prepare an OCD:
• Mil-Std 498 for Department of Defense SW development
• IEEE Standard 1498 for commercial SW development,
• AIAA OCD 1992 for the American Inst. of Aeronautics and
Astronautics (for embedded real-time systems)
• ConOps 1997 Concept of Operations Document Guidelines proposed
by
Fairley and Thayer [FT97] because they felt the above guidelines
were
[FT97] R. E. Fairley and R. H. Thayer, "The Concept of Operations: The Bridge from Operational Requirements to Technical
systems-oriented
Specifications," andM.developer-oriented
Software Engineering, Dorfman and R. H. Thayer (eds.),instead of user-oriented.
IEEE Computer Society Press, Los
Alamitos, CA, 1997.

Petrie, 2001 17
The Concept of Operations Document

Identifies
• classes of users and
• modes of operation
• normal mode • emergency mode
• maintenance mode • backup mode
• degraded mode • diagnostic mode

Users communicate
• essential needs
• desirable needs -- prioritized
• optional needs -- prioritized

Prioritized user needs provide the basis for
• establishing an incremental development process, and
• making trade-offs among
operational needs, schedule and budget.
[FT97]
Petrie, 2001 18
Concept Analysis
Concept Analysis Team, include representatives from
• user organization • training
• buyer organization • operational support
• developer organization or development experts/consultants

Results of concept analysis are recorded in the ConOps document
written in narrative prose using users' language, and using visual
forms (diagrams, illustrations, graphs, etc.) wherever possible.

Each operational scenario needs a test scenario to validate the
system in user's environment. Validate proposed system by
walking thru all scenarios, include both normal and abnormal
operations:
• exception handling, • stress load handling,
• handling incomplete data, • handling incorrect data.
[FT97]
Petrie, 2001 19
Outline for a Concept of Operations Document
1 Scope 5 Concepts of Operations for the New or
1.1 Identification Modified Proposed System
1.2 System Overview 5.1 Background, Objectives & Scope
1.3 Document Overview 5.2 Operational Policies & Constraints
2 Referenced Documents 5.3 Description of Proposed System
3 The Current System or Situation 5.4 Modes of Operation
3.1 Background, Objectives, & Scope 5.5 User Classes
3.2 Operational Policies & Constraints 5.5.1 Organization Structures
3.3 Description 5.5.2 Profiles of User Classes
3.4 Modes of Operation Classes 5.5.3 Interactions among User
3.5 User Classes 5.6 Other Involved Personnel
3.5.1 Organizational Structure 5.7 Support Environment
3.5.2 Profiles of User Classes 6 Proposed Operational Scenarios
3.5.3 Interactions 7 Summary of Impacts
3.5.4 Other Involved Personnel 7.1 Operational Impacts
3.6 Support Environment
4 Justification for and Nature of Proposed 7.2 Organizational Impacts
Changes & New Features 7.3 Impacts During Developments
4.1 Justification
4.2 Description 8 Analysis of Proposed System
4.3 Priorities among Changes/ Features 8.1 Summary of Improvements
4.4 Changes/Features Considered but 8.2 Disadvantages & Limitations
Not Included 8.3 Alternatives/Tradeoffs considered
4.5 Assumptions and Constraints
9 Notes, Appendices, and Glossary
[FT97]
Petrie, 2001 20
Rapid Prototype
[www.dilbert.com 2/24/2000]
Having a prototype during requirements phase gives you

something to work from when communicating with the
users and client, and results in a user-centered GUI design

Petrie, 2001 21
Traditional Expressions of
Functional Requirements
 Requirements specifications
◦ Hard to read. Contract-like.
 Context Diagram
◦ Specifies users, software, hardware that interface with system
 Data-flow Diagrams (DFD)

◦ Useful for technical people but tend to confuse users
◦ Useful in design of non-object-oriented systems
 Entity-relationship diagrams (ERD)
◦ Critical to database design but are not easily understood by
users
 Prototypes
◦ Good communication tool to elicit information from user.
◦ Great for proof-of-concept tasks.
◦ Useful in developing user interface designs.
Petrie, 2001 22
Unified Modeling
Language (UML)

Petrie, 2001 23
UML Diagrams
 Instead of the Context, Data-Flow and
Entity-Relationship Diagrams used in
Structured Analysis, UML produces 9 types
of diagrams
◦ Use Case Diagram
◦ Sequence Diagram
◦ Collaboration Diagram
◦ Statechart Diagram
◦ Activity Diagram
◦ Class Diagram
◦ Object Diagram
◦ Component Diagram
◦ Deployment Diagram
Petrie, 2001 24
Use Cases

Petrie, 2001 25
History of Use Cases
 Ivar Jacobson and his team at Ericsson in
Sweden introduced Use Cases in their book:
I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard.
Object-Oriented Software Engineering: A Use Case Driven
Approach, ACM Press, 1992.
 Use Cases were included as part of their overall
system development lifecycle methodology, called
Objectory, which was sold to Rational Software.
Now Use Cases are part of the Rational Unified
Process, created by the "three amigos":
I. Jacobson, G. Booch and J. Rumbaugh. The Unified
Software Development Process, Addison-Wesley, 1999.

Petrie, 2001 26
What is a Use Case?
 The Use Cases describe the behavior of a
system from a user's standpoint using actions
and reactions.
 The Use Case Diagram defines the system's
boundary, and the relationships between the
system and the environment:
◦ different human users roles interact with our system
◦ other software systems/applications
◦ hardware systems/devices
 Use Cases support the specification phase by
providing a means of capturing and
documenting requirements

Petrie, 2001 27
Use Case Deliverables
 There are two parts to document a use case:
◦ the use case diagram,
 provides visual overview of important interactions
 captures scope (identifies external entities)
◦ the use case itself
 documents in a textual form the details of the
requirements, what the use case must do.
 A use case is actually a page or two of text
representing each oval in the use case diagram
 A project should have a standard template for use
cases.

Petrie, 2001 28
Use Case Diagram
actor system
Real Estate System
Buyer Sell Property
Seller
Advisor use case
interaction

Petrie, 2001 29
Use Case Documentation Template
Use Case Number: A unique numeric identifier Use Case Name: A unique descriptive identifier
Iteration: Facade (Outline and high-level description), Filled (Broader, deeper), Focused (Narrower, pruned), Finished
Summary: Briefly state the purpose of the use case in one or two sentences to provide a high-level definition of the
functionality provided by the use case.
Basic Course of Events: 4. Include the following:
4.1 What interaction the use case has with the actors
1. This is a numbered list. The use case number is used
togetherfor with this number to provide requirements 4.2 What data is needed by the use case
traceability 4.3 When and how the use case starts and ends
4.4 The normal sequence of events for the use case
2. Write this as a flow of events describin what the system should
4.5 The description of alternate or exceptional flows,
do, not how the system should do it.
what happens if ...
3. Write it in the language of the domain, not technical jargon 5. The description of each step grows in detail as analysis
progresses
Alternative Paths: What happens if ... invalid information is entered, unusual types of processing occurs, or uncommon
conditions occur, how is the flow completed?
Exception Paths: What happens if... an error occurs, how is the flow affected?
Extension Points: Describes an <<extend>> relationship, shows steps which are extended by optional steps in another case
Trigger: Describe entry criteria for use case, may describe business need, may be time-related, or completion of other case
Assumptions: Critical section for project manager. Things (out of scope of system) you assume to be true but might not be true
Preconditions: List things that must be in place before interaction can occur. (Part of contract between use case & outside world.
Postconditions: List things that will be satisfied if use case is completed successfully. Independent of alternative paths taken.
Related Business Rules: Written and unwritten company business rules that relate to requirements presented in this use case
Author: This is placed at the bottom, together with the date to allow critical information to be speed read
Date: Facade, Filled, Focused, Finished dates
[KG0042]
Petrie, 2001 30
Use Case Documentation Example
Use Case Number: 1 Use Case Name: Sell Property
Iteration: Filled (Four stages of iteration are Facade, Filled, Focused, and Finished)
Summary: System Context Use Case. The seller lists the property, a buyer purchases the property, and the agent guides them
through the process and offers advice, caution, and recommendations
Basic Course of Events: 9. System responds by notifying seller and seller's agent
10. Seller responds to the offer with a counteroffer.
1. Seller selects an agent
11. System responds by notifying buyer and buyer's agent.
2. System responds by assigning an agent and notifying the
seller's agent. 12. Buyer and seller agree to terms
3. Seller lists the property to sell. 13. System responds by recording the agreement
4. System responds by displaying this property in the property 14. Buyer indicates a loan is required
listing and linking it for searches 15. System responds by locating an appropriate loan provider
5. Buyer selects an agent. 16. Buyer and loan provider agree to loan terms.
6. Buyer reviews the property listings by entering search criteria 17. System responds by recording terms of loan
7. System displays properties matching buyer's search criteria 18. Buyer and seller close on property.
8. Buyer finds a property and makes an offer on it. 19. System responds by recording details of close.
Alternative Paths: N/A

Exception Paths: N/A
Extension Points: N/A
Trigger: N/A
Assumptions: N/A
Preconditions: N/A
Postconditions: N/A
Related Business Rules: N/A
Author: Rumpel Stilskin
Date: March 10, 2001 – Facade; April 20, 2001 -- Filled
[KG00p25-26]
Petrie, 2001 31
A Simpler Use Case Template
 A simpler template for Use Case
documentation is recommended by Terry
Quatrani [TQ98]
 For each use case:
X Flow of Events for the <name> Use Case

X.1 Preconditions
X.2 Main Flow
X.3 Subflows (if applicable)
X.4 Alternative Flows
where X is a number from 1 to the number of
[TQ98] Terrythe use
Quatrani. casewith Rational Rose and UML, Addison-Wesley, Reading, Mass., 1998.
Visual Modeling

Petrie, 2001 32
Associations in Use Case Diagram
 Associations can exist
◦ between an actor and a use case,
◦ between use cases, and
◦ between actors
 Types of Use Case Associations
◦ Communicates between actor and use case
 named or unnamed relationship showing participation of actor in use case,
use a solid line connecting actor to use case
◦ Generalization between actors
◦ Adornments = Stereotyped Associations between use
cases
 <<extend>>
indicates relationship between use cases in which a special use case (the
non-arrow end) extends an original use case (the arrow end)
 <<include>>
reuses steps in a use case instead of cut-and-pasting steps into multiple
use case documents, by pulling out common steps into a new use case
and specifying with an arrowed line the <<include>> association
between this new use case and those use cases requiring the steps
 <<uses>>
An instance of the source use case includes behavior described by the
target
Shows a stereotyped generalization relationship between use cases

Petrie, 2001 33
Example of Generalization between Use Case
Actors
Service Representative
Customer Service Representative Field Service Representative
[KG00p40]

Petrie, 2001 34
Example of Communicates Use
Case Relationship
Sell Property
Buyer
Triggers
Sell Property
Buyer

Petrie, 2001 35
Example <<uses>> and <<extends>>
Use Case Relationships
Transfer by computer
Remote Customer Local Customer

<<extends>>
Transfer
<<uses>>
Identification
[PM97] Pierre-Alain Muller. Instant UML, Wrox Press, Birmingham, UK.

[PM97p97]

Petrie, 2001 36
Example <<include>> and
<<extends>> Use Case Relationships
Schedule Customer
Appointment
Office Administrator <<extends>>

<<includes>>
Schedule Recurring
Schedule Designer Customer Appointment
<<includes>>
Enter Customer Order
[KG00p41]

Petrie, 2001 37
Course Registration Exercise
Problem Statement:
At the beginning of each semester, students may request a course
catalog containing a list of course offerings needed for the semester.
Information about each course, such as professor, department and
prerequisites are included to help students make informed decisions.
The new system will allow students to select four course offerings for
the coming semester. In addition, each student will indicate two
alternative choices in case a course offering becomes filled or canceled.
No course offering will have more than ten students or fewer than
three students. A course offering with fewer than three students will be
canceled. Once the registration process is completed for a student, the
registration system sends information to the billing system so the
student can be billed for the semester.
Professors must be able to access the online system to indicate which
courses they will be teaching, and to see which students signed up for
their course offerings.
For each semester, there is a period of time that students can change
their schedule. Students must be able to access the system during this
time to add or drop courses.
Exercise: Create a Use Case Diagram and Use Case Documentation.
[TQ98p17]
Petrie, 2001 38
Introduction to Rational Rose
Rational Rose 2000 (v6.5)
1 month trial version needs key
www.rational.com

Petrie, 2001 39
Rational Rose Environment
Standard menu
Standard toolbar
Diagram toolbar
(unique to each
Browser window type of diagram)
(used to organize
Diagram
and navigate) window
Can be hidden,
docked or floating
Status bar
Documentation
window

Petrie, 2001 40
The View Menu
 Allows you to control the desk top
arrangement by hiding, or displaying:
◦ The Browser Window
◦ The Documentation Window
◦ The Status Bar
◦ The Standard Toolbar
◦ The Diagram Toolbox
 Right clicking on one of the above items (on
one of the components in them) allow the item
to be
◦ Docked
◦ Floating
◦ Hidden

Petrie, 2001 41
The Toolbars
 Right Clicking on a Toolbar/Toolbox button
allows you to:
◦ Dock the Toolbar
◦ Float the Toolbar
◦ Use Large Buttons
◦ Customize
 If the Toolbar/Toolbox is not visible, select it
using the View  Toolbars menu

Petrie, 2001 42
The Tools Menu
 Under the Tools menu item, can:
◦ Generate Code in
 Ada
 Java
 Oracle8
 C++
 XML_DTD
◦ Reverse Engineer Models from Code
◦ Add Version Control
◦ ...

Petrie, 2001 43
The Browser Window
• Used to navigate through the
models and documentation
using an textual outline
• Expand and contract using +
or - in front of the View
• Select model/component
• Browser may be made Views from the
Browser window
visible or hidden by
• using the View menu, or
• right-clicking on an item in the
Browser window.
• Browser may be docked or
floating by
• right-clicking on one of the
items in the Browser window.

Petrie, 2001 44
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
View Target Audience:
Use-Case View End User
Logical View Analyst/Designer
Process View System Integrator
Deployment View System Engineer
Implementation View Programmer
in Rose: Component View
[PK 94] Philippe Kruchten. Software Architecture and Iterative Development. Rational Software Corporation,
Santa Clara, CA, April 1994.

Petrie, 2001 45
4 Views + 1 Architectural View
in Rose:
Component View
[RR00]
Petrie, 2001 46
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 [RR00]

Petrie, 2001 47
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 [RR00]

Petrie, 2001 48
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

Petrie, 2001 49
The Deployment View
 For System Engineers
 Used only for distributed systems
 Captures how executables and other run-
time components are to be mapped to
platforms or computer nodes
 Includes:
◦ Performance – Delivery
◦ Scalability – Installation
◦ Availability
◦ Fault Tolerance
◦ Deployment Diagram

Petrie, 2001 50
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

Petrie, 2001 51
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.

Petrie, 2001 52
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

Petrie, 2001 53
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

Petrie, 2001 54
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

Petrie, 2001 55
Creating the 4+1 Views

Petrie, 2001 56
The Rational Unified Process
Inception Phase:
• establish business rationale for project
Inception • decide project scope
• get go-ahead from project sponsor
Elaboration Phase:
Elaboration • collect more detailed requirements
• do high-level analysis and design
• establish baseline architecture
Construction • create construction plan
1 2 3 ... Construction Phase:

• build, test and validate the project
Transition Phase:
Transition • beta-test
• tune performance
• train users

Petrie, 2001 57
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

Petrie, 2001 58
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 [TQ98p21-22]
◦ 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?

Petrie, 2001 59
Creating Actors in Rational Rose
1. Right-click on the Use Case View package in
the browser to make the shortcut menu visible.
2. Select the NewActor menu option. A new
actor called New Class will appear in the
browser under Use Case View
3. The New Class actor to the desired name
4. Move cursor to the Documentation Window and
add the documentation.
5. Repeat until all actors are added and
documented

Petrie, 2001 60
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 [TQ98p25]
◦ 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?

Petrie, 2001 61
Creating Use Cases in Rational Rose
1. Right-click on the Use Case View in the

Browser to make shortcut menu visible.
2. Select the NewUse Case menu option.
3. With the unnamed use case selected, enter
the desired name.
4. Move cursor to documentation window and
add a brief description.
5. Repeat for each use case.

Petrie, 2001 62
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 .

Petrie, 2001 63
The Use Case View
for the
Case Study:
Course Registration System

Petrie, 2001 64
The Actors
 In the Course Registration System, answering the
questions suggested to find actors yields:
◦ Students want to register for courses
◦ Professors want to select courses to teach
◦ Registrar must create the curriculum and generate a catalog for the
semester
◦ Registrar must maintain all the information about courses,
professors, and students
◦ Billing System must receive billing information from the system
 Actors identified from above:
◦ Student – person registered/registering in classes at the
University
◦ Professor – person certified to teach classes at the University
◦ Registrar – person who maintains the Course Registration
System
◦ Billing System – external software system that does student
billing

Petrie, 2001 65
Add Actors to System
[TQ98p24-25]
Petrie, 2001 66
The Use Cases
 Answering the questions to find use cases yields:
◦ The Student actor needs to use the system to register for courses
◦ After the course selection process is completed, the Billing System must
be supplied with billing information
◦ The Professor actor needs to use the system to select the courses to
teach for a semester, and must be able to receive a course roster from
the system
◦ The registrar is responsible for the generation of the course catalog for
a semester, and for the maintenance of all information about the
curriculum, the students, and the professors needed by the system
 Based on the needs, the following cases are
identified:
1.Register for courses
2.Select courses to teach
3.Request course roster
4.Maintain course information
5.Maintain professor information
6.Maintain student information
7.Create course catalog
[TQ98p24-25]
Petrie, 2001 67
Add Use Cases to the System
Give a brief description of
each use case i the
Documentation window
This is the summary

description for
Register for courses
[TQ98p28-29]
Petrie, 2001 68
The Flow of Events
 Exercise: Form a team and agree on a standard
template to use for documenting flow of events
for the use cases.
◦ Look at Quatrani's recommended template [TQ98]
and
 The following flow of event for the Select
Courses to Teach use case follows Quatrani's
recommended template [TQ98]
 For each use case:
X Flow of Events for the <name> Use Case
X.1 Preconditions
X.2 Main Flow
X.3 Subflows (if applicable)
X.4 Alternative Flows
where X is a number from 1 to the number of the use case

Petrie, 2001 69
The Flow of Events (1 of 4)
[TQ98p30]
Petrie, 2001 70
[TQ98p31]
Petrie, 2001 71
[TQ98p31-2]
Petrie, 2001 72

Petrie, 2001 73
Use Case Diagram (1 of 2)
[TQ98p38]
Petrie, 2001 74
Use Case Diagram (2 of 2)
[TQ98p31]
Petrie, 2001 75
Exercises
 Individually create a Problem Statement and Use Case
Diagram for one of the following Vending Machines:
1. Hot Drink Vending Machine that mixes and dispenses two
sizes of hot drinks (coffee, tea, hot chocolate) with/without
cream and sugar/sweetener.
2. Ice Cream Vending Machine that dispenses prepackaged ice
cream (individual cups, bars, cones, sandwiches – pre-
wrapped)
3. Carousel Vending Machine that dispenses a variety of food
(many with expiration date) on a stack of see-thru carousels
containing a number of individual food compartments. Each
carousel has a door. The customer turns the carousels until
the item is positioned in front of a door.. The action of
sliding open the door, selects and dispenses the food.
 Meet in a team of 3-4, discuss each Problem Statement
and Use Case Diagram, features (such as sensors,
credit cards payment) that would enhance the
marketing of the product. Produce a group Problem
Statement and Use Case Diagram.
◦ Turn in all the statements/diagrams with the author's name,
clearly mark the group approved ones with all the team
members' names and initials. Select one
© Dr. Maria team member and
M. Larrondo
an alternate that will walkthrough the statement and diagram

Petrie, 2001 76
The Logical View
Develop Class Diagrams
Develop Interaction Diagrams
Develop State Diagrams
Develop Activity Diagrams

Petrie, 2001 77
Developing the Logical View
 One of the main diagram produced in the logical
view is the Class Diagram.
 The Rational Unified Process suggests using a
model-view-controller perspective to partition the
system by separating the view from the domain from
the control needed by the system.
 Typical Class Stereotypes:
◦ Entity Classes (or Domain Classes)
 may reflect real-world entity or may perform tasks internal to the system.
 may be used in multiple applications; are surrounding independent
◦ Boundary Classes
 model system interfaces between the actors and the application
 are surrounding dependent
◦ Control Classes
 coordinate events needed to realize one or more use cases
 typically are application-dependent

Petrie, 2001 78
Top-Down or Buttom-Up?
 Top-Down – Identify Packages first, then Classes
◦ Right click on Logical View in the Browser, select NewPackage,
or drag-drop toolbox icon into the Class Diagram, name the
package and fill documentation. More details are added using
Specification Window.
◦ To insert new classes into the package: Right click on the package in
the Browser, and select NewClass, name the class and fill
documentation description
◦ To insert existing classes into the package: In the Logical View in
the Browser, click on class and drag into package.
 Buttom-Up – Identify classes first, then group
◦ Right click on Logical View in the Browser, select NewClass,
name the class and fill documentation. Repeat until most classes
are identified.
◦ Organize classes into groups by creating packages
◦ Insert the classes into the appropriate package: In the Logical
View in the Browser, click on class© and drag
Dr. Maria M. into package
Larrondo
Petrie, 2001 79
Select a Use Case and SubFlow
 Look at a use case: Select Courses to Teach
 Select a subflow: Add a Course Offering
 Although the flow is written sequentially, in the real
world many steps may occur concurrently
The professor logs onto the Registration System and enters password. The
system verifies the password is valid (E1) and prompts the professor to select
the current semester or a future semester (E2). The professor enters the desired
semester. The system prompts the professor to select the desired activity: ADD,
DELETE, REVIEW, PRINT, or QUIT. The professor chooses ADD, the S-1: Add a
Course Offering subflow is selected.
S-1 Add a Course Offering
The system displays the course screen containing a field for a course name and
number. The professor enters the name and number of a course (E-3). The
system displays the course offerings for the entered course (E-4). The professor
selects a course offering. The system links the professor to the selected course
offering (E-5). The use case then begins again.
E-3: An invalid course name/number is entered. The user can re-enter a valid
name/number combination or terminate the use case
E-4: Course offerings cannot be displayed. The user is informed that this option
is not available at the current time. The use case begins again.
E-5: A link between the professor and the course offering cannot be created.
The information is saved and the system will create the link at a later time. The
use case continues Petrie, 2001 80
What is a Scenario?
 What is a scenario?
◦ A use case is a class, not an instance; it describes
the functionality as a whole and includes possible
alternatives, exceptions and errors that are
possible during the execution of the use case.
◦ A scenario is an instantiation of a use case or a
collaboration. It represents an actual usage of the
system -- a specific execution path through the
flow of events.
Example from [EP98]:
Use Case: Signing Insurance
Scenario: "John Doe contacts the system by telephone and
signs for car insurance for his new Toyota Corolla"
Petrie, 2001 81
Scenarios
 Scenarios are used to complement (not
replace) and clarify a use case description in
terms a user can understand
 A set of scenarios are used to illustrate the
use case or collaboration. Make sure to select
scenarios that illustrate normal and abnormal
(using exceptions and alternate flows).
◦ When a scenario is viewed as a use case, describe
only the external behavior toward the actors
◦ When a scenario is viewed as an instance of a
collaboration, describe the internal implementation
of the involved classes, their operations and
communications
 A scenario is presented as a numbered
sequence of steps.
Petrie, 2001 82
Relationship between Use Case,
Collaboration, and Scenario
Scenario
[EP98p61]
Petrie, 2001 83
Relationship between Use
Case, Collaboration, and
Scenario
©
Petrie, 2001
Dr. Maria M. Larrondo
[EP98p63]
84
Identify Classes and Create
Packages
Identify Boundary Classes
Identify Entity Classes
Identify Control Classes
Create Packages

Petrie, 2001 85
Identify Boundary Classes
 Identify Boundary Classes
◦ With what actors does the use case interact?
Professor
 What information do we need to keep track of?
 what options is the professor allowed to use
 add, modify, delete, review, print course offering
ProfessorCourseOptions
 What information do we
◦ Class to take care of use case subflow:
AddACourseOffering
 What general flows do we need to support?

Petrie, 2001 86
Identify Entity Classes
 Domain Classes identified:
◦ Course
◦ CourseOffering
◦ ProfessorInformation keeps track of professor's
course assignment

Petrie, 2001 87
Identify Control Classes
 Add control classes to handle the flow of
events for the use case:
◦ ProfessorCourseManager

Petrie, 2001 88
Create Packages
 Classes identified:  Group classes into
◦ Boundary Classes packages:
ProfessorCourseOptions Three Logical Groups:
AddACourseOffering Interfaces
◦ Entity Classes UniversityArtifacts
Course
People
CourseOffering
ProfessorInformation
◦ Control Classes
ProfessorCourseManager

Petrie, 2001 89
Petrie, 2001 90
References
 References used:
[EP ] Hans-Erik Eriksson and Magnus Penker. UML Toolkit, John Wiley &
Sons, New York, NY, 1998. ISBN 0-471-19161-2
[MF97] Martin Fowler with Kendall Scott. UML Distilled: Applying the
Standard Object Modeling Language, Addison-Wesley, Reading, Mass,
1997. ISBN 0-201-32563-2
[KG00] Daryl Kulak and Eamonn Guiney. Use Cases: Requirements in Context ,
Addison-Wesley, New York, NY, 2000. ISBN 0-201-65767-8
[PK 94] Philippe Kruchten. Software Architecture and Iterative Development .
Rational Software Corporation, Santa Clara, CA, April 1994.
[PM97] Pierre-Alain Mueller. Instant UML, WROX Press, Chicago, IL
[TQ98] Terry Quatrani. Visual Modeling with Rational Rose and UML ,
Addison-Wesley, Birmingham, UK, 1998. ISBN 1-861000-87-1

Petrie, 2001 91
Useful URLs
http://members.aol.com/acockburn -- Alistair Cockburn's
papers on use cases

Petrie, 2001 92

UML and RationalRose

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UML and RationalRose

Uploaded by

Copyright:

Available Formats

UML and Rational Rose Notes

object-oriented software development

documents, models, diagrams

classes, attributes, and associations (e.g.,

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

Requirement Kulak and Guiney Comments

Note: Each requirement should have a number to provide traceability.

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

Having a prototype during requirements phase gives you

© Dr. Maria M. Larrondo

 Data-flow Diagrams (DFD)

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

Real Estate System

Buyer Sell Property

Advisor use case

© Dr. Maria M. Larrondo

Alternative Paths: N/A

X Flow of Events for the <name> Use Case

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

Customer Service Representative Field Service Representative

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

Remote Customer Local Customer

[PM97] Pierre-Alain Muller. Instant UML, Wrox Press, Birmingham, UK.

© Dr. Maria M. Larrondo

Office Administrator <<extends>>

Enter Customer Order

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

A Use Case Diagram [RR00]

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

diagram type, and changes automatically

selecting it from those listed under the

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

1 2 3 ... Construction Phase:

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

© Dr. Maria M. Larrondo

1. Right-click on the Use Case View in the

© Dr. Maria M. Larrondo