Software Design Methodologies: UML in Action: Dr. Mohamed Fayad, J.D. Edwards Professor

Software Design Methodologies:
UML in Action
Dr. Mohamed Fayad, J.D. Edwards Professor

Department of Computer Science & Engineering
University of Nebraska, Lincoln
Ferguson Hall, P.O. Box 880115
Lincoln, NE 68588-0115
http://www.cse.unl.edu/~fayad
May-June 2001 ISISTAN Research Institute – Tandil,

Argentina
Lesson 12:
Use Case Modeling
2
May-June 2001 ISISTAN Research Institute – Tandil, L12-S2 Use Case Modeling
Argentina -- M.E. Fayad
Lesson Objectives
 Overview of Previous Lecture

 Discuss the following:
Objectives – What is use case modeling?

– Use Case Modeling -- Core concepts
– Use Case Diagram tour
– When to model use cases
– Use Case Modeling tips
– Examples: Library & University Registration
3
What is use case modeling?
 use case model: a view of a system

that emphasizes the behavior as it
appears to outside users. A use case
model partitions system functionality
into transactions (‘use cases’) that
are meaningful to users (‘actors’).
4
Use Case Modeling: Core Elements
Construct Description Syntax
use case A sequence of actions, including
variants, that a system (or other
entity) can perform, interacting with U seC aseN am e
actors of the system.

actor A coherent set of roles that users
of use cases play when interacting
with these use cases.
A c to rN a m e
system Represents the boundary between

boundary the physical system and the actors
who interact with the physical
system.
5
Use Case Modeling: Core Relationships
association The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
extend A relationship from an extension use
case to a base use case, specifying
how the behavior for the extension <<extend>>
use case can be inserted into the

behavior defined for the base use
case.
generalization A taxonomic relationship between a
more general use case and a more
specific use case. 6
Use Case Modeling: Core Relationships (cont’d)
include An relationship from a base use case <<include>>
to an inclusion use case, specifying
how the behavior for the inclusion use
case is inserted into the behavior
defined for the base use case.
7
Use Case Diagram Tour
 Shows use cases, actor and their

relationships
 Use case internals can be specified by
text and/or interaction diagrams
 Kinds
– use case diagram
– use case description
8
Use Case Diagram
Telephone Catalog
Check
status
Place Salesperson
order
F ill o r d e r s
Customer Shipping Clerk
Establish
credit
9
Supervisor
Fig. 3-44, UML Notation Guide
Use Case Relationships
Supply Order
Customer Data Product Arrange
Payment
«include» «include» «include»
Place Order
Extension points «extend»

1 * additional requests : the salesperson asks for
after creation of the order the catalog
Request
Catalog

Actor Relationships
1 * Place
Order
Salesperson
Establish
1 *
Supervisor
Credit
11
Use Case Description: Change Flight
 Actors: traveler, client account db, airline reservation system
 Preconditions:
 Traveler has logged on to the system and selected ‘change

flight itinerary’ option
 Basic course
 System retrieves traveler’s account and flight itinerary from

client account database
 System asks traveler to select itinerary segment she wants to
change; traveler selects itinerary segment.
 System asks traveler for new departure and destination
information; traveler provides information.
 If flights are available then
 …
12
 System displays transaction summary.
 Alternative courses
 If no flights are available then …
When to model use cases
 Model user requirements with use cases.

 Model test scenarios with use cases.
 If you are using a use-case driven method
– start with use cases and derive your structural
and behavioral models from it.
 If you are not using a use-case driven method
– make sure that your use cases are consistent
with your structural and behavioral models.
13
Use Case Modeling Tips
 Make sure that each use case describes a significant chunk of
system usage that is understandable by both domain experts and
programmers
 When defining use cases in text, use nouns and verbs accurately
and consistently to help derive objects and messages for
interaction diagrams
 Factor out common usages that are required by multiple use cases
– If the usage is required use <<include>>
– If the base use case is complete and the usage may be optional,
consider use <<extend>>
 A use case diagram should
– contain only use cases at the same level of abstraction
– include only actors who are required
 Large numbers of use cases should be organized into packages
Sample Problem Statement: Library System
 You have been contracted to develop a

computer system for a university library. The
library currently uses a 1960s program,
written in an obsolete language, for some
simple bookkeeping tasks, and a card index,
for user browsing. You are asked to build an
interactive system which handles both of
these aspects online.*
15
*Example from: “Using UML”, by: Pooley and Stevens
First Step!
 Time to start gathering the user requirements.

– Different users will have different, sometimes
conflicting priorities
– Users will not, necessarily know what they
want
– It is very possible to miss something vital
– The managers do not always know what the
users have to do
– Users can be, and frequently are, hostile.
Why? What can be done about it?
16
The Use Case Model
 We must now identify the users of the system

and the tasks they must undertake with the
system. The details of the use case should
be documented, using a Use Case Template.
17
The Use Case Template
Use Case Template

PACKAGE: _________________ [Description (an over view of the package)].
USE CASES: [A package will have one or more Use Cases].
Use Case No.: [1.1]
Use Case Title: [A descriptive title]
[Ex. adding a new patient, or adding a new role].
Actors: _______, _______, _______, _______.
[Any users of the Use Case, ex. human, machine, other systems or subsystems].
Corresponding Roles: _______, _______, _______, _______.
[There is a different role per actor in every Use Case].
Classes: _______, _______, _______, _______.
[List all the classes within the Use Case Description].
Enduring Business Themes (EBT): _______, _______, _______
Business Objects (BO): _______, _______, _______, _______.
Industrial Objects (IO): _______, _______, _______, _______.
[This represents a clear classification of all the classes within the use case description].
Description of the Use Case:
[Describes the data flow and the logic flow of the Use Case].
18
Documenting Use Cases
 A flow of events description is created for each use case

– Written from an actors point of view
 Details what the system must provide to the actor when
the use case is executed
 Typical contents
– How the use case starts and ends
– Normal flow of events
– Alternate flow of events
– Exceptional flow of events
19
Copyright © 1997 by Rational Software Corporation
Actors
 An actor is someone or something that must interact with the
system under development
BookBorrower
Browser
Librarian
JournalBorrower
Use Cases
Actors are examined to determine their needs
– BookBorrower
• Checkout and return books
– Browser
• locate and peruse items of interest
– Librarian
• maintain order and accountablility
– JournalBorrower
• checkout and return journals
Checkout Book Return Book Checkout Journal
Use Case Model
 The usual course through the system when actor is using the
system is called the basic course. Other courses would be
modeled as extending Use Cases.
 An example of a basic course would be:
– Borrow copy of book A BookBorrower presents a book. The
system checks that the potential borrower is a member of the
library, and that s/he does not already have the maximum
permitted number of books on loan. This maximum is six unless
the member is a staff member, in which case it is 12. If both
checks succeed, the system records that this library member has
this copy of the book on loan.
**Example from: “Using UML”, by: Pooley and Stevens
22
Use Case Diagram for the first iteration
23
What Requirements would an ideal system satisfy?
 Books and Journals: The library contains books and

journals. It may have several copies of a given book. Some
of the books are for short term loans only. All other books
may be borrowed by any library member for three weeks.
Only members of staff may borrow journals. Members of the
library can normally borrow up to six items at a time, but
members of staff may borrow up to 12 items at one time.
New books and journals arrive regularly, and are sometimes
disposed of. The current year’s journals are sent away to be
bound into volumes at the end of each year.*
24
What Requirements would an ideal system satisfy?
 Borrowing: It is essential that the system keep track of

when books and journals are borrowed and returned, since
the current system already does that. The new system
should produce reminders when a book is overdue. There
may in future be a requirement for users to be able to extend
the loan of a book if it is not reserved.
 Browsing: The system should allow users to search for a
book on a particular topic, by a particular author, etc., to
check whether a copy of the book is available for loan, and if
not, to reserve the book. Anyone can browse in the library.*

25
Use Case Diagram for the library
26
Example II: University Registration
 The ESU University wants to computerize

their registration system
– The Registrar sets up the curriculum for a semester
• One course may have multiple course offerings
– Students select 4 primary courses and 2 alternate courses
– Once a student registers for a semester, the billing system is
notified so the student may be billed for the semester
– Students may use the system to add/drop courses for a period of
time after registration
– Professors use the system to receive their course offering rosters
– Users of the registration system are assigned passwords which
are used at logon validation
Actors
Registrar
Professor
Student
Billing System
28
Use Cases
 Actors are examined to determine their needs
– Registrar
• maintain the curriculum
– Professor
• request roster
– Student
• maintain schedule
– Billing System
• receive billing information from registration
Maintain Curriculum Request Course Roster Maintain Schedule

Maintain Curriculum: Flow of Events (description)
 This use case begins when the Registrar logs onto the
Registration System and enters his/her password. The system
verifies that the password is valid (E-1) and prompts the
Registrar to select the current semester or a future semester (E-
2). The Registrar enters the desired semester. The system
prompts the professor to select the desired activity: ADD,
DELETE, REVIEW, or QUIT.
 If the activity selected is ADD, the S-1: Add a Course subflow is
performed.
 If the activity selected is DELETE, the S-2: Delete a Course
subflow is performed.
 If the activity selected is REVIEW, the S-3: Review Curriculum
subflow is performed.
 If the activity selected is QUIT, the use case ends. 30
Use Case Diagram
 Use case diagrams are created to visualize the relationships
between actors and use cases
Request Course Roster
Student Professor
Maintain Schedule
Billing System Maintain Curriculum
Registrar

Uses and Extends Use Case Relationships
 As the use cases are documented, other use case
relationships may be discovered
– A uses relationship shows behavior that is common to
one or more use cases
– An extends relationship shows optional behavior
<<uses>>
Register for courses
<<uses>>
Logon validation
Maintain curriculum

Possible Problems with Use Cases
1. Use Cases emphasize ordering. This can be

considered to be incompatible with object
technology.
2. Over modeling – Leads to requirement inflation.
33
Cautions
Do not invent requirements!

– Use cases are about the user’s requirements,
not about what you, as the designer might
think that the system could usefully do!
34
Acknowledgements
 Object Modeling with OMG UML:

Introduction to UML
– Cris Kobryn
– Chief Scientist, InLine Software
Co-Chair UML Revision Task Force
August
© 1999-2000 2000
OMG and Tutorial Contributors: EDS, IBM, Enea Data, InLine Software,
IntelliCorp, Kabira Technologies, Klasse Objecten, ObjectTime Ltd., Rational Software, Unisys
 “Using UML: Software Engineering With Objects and

Components”
by: Rob Pooley and Perdita Stevens
“Analysis and Design with UML”

35

Sample Use Case from Philips Project (1)
 Use Case No.: 1.1.1

 Use Case Title: Find Candidate
 Actors: Registrar
 Roles: Data Entry Clerk (Registrar),
 Classes: IDSession, PersonProfile, PersonIdentifier, PersonTraits ,
CandidateListGenerator, DataManager
 Enduring Business Themes: (EBT): identity, security,
 Business Objects: IDSession, IDManager, DataManager,
PersonIdentifier
 Industrial Objects: CandidateList, PersonTraits, PersonProfiles,
SecurityManager, TraitGatekeeper
36
 Description of the Use Case:

 1. The Registrar enters the information about a person into the
System.
 2. IDSession clears the request with Security.
 3. The System tells the Person-Identifier to search for candidates.
 4. The Person-Identifier gives the request to its DataManager
 5. The DataManager determines a list of candidates, using its
CandidateListGenerator and its set of PersonProfiles and returns it to
the System.
 6. The Registrar chooses the candidate from the list that represents
the person.
37

 Use Case Title: Register New ID
 Actors: Registrar
 Roles: Data Entry Clerk (Registrar),
 Classes: IDSession, IDManager, PersonProfile, PersonTraits,
CandidateList, PersonIdentifier
 Enduring Business Themes (EBT): identity, security
 Business Objects (BO): IDSession, IDManager, PersonIdentifier
 Industrial Objects (IO): PersonProfile, PersonTraits, CandidateList
38
 1. The Registrar enters the information about a person into the IDSession.
 2. The IDSession has security clear the request.
 3. The IDSession has the PersonIdentifier search for candidates.
 4. The Person-Identifier determines that no candidates fit the criteria.
 5. The Person-Identifier gives this information to the system.
 6. The informs the Registrar that no candidates exist.
 7. System asks the Registrar if the person should be added as new.
 8. Registrar tells System to add new person.
 9. System sends traits to ID-Manager.
10. ID-Manager creates a new profile.
39

 Exceptional Flow of Events 01: If any of the identifying information

entered by the Registrar is incomplete or invalid the system displays
corresponding error message(s). The system will not validate the
New Person until all identifying information is made available.

 Exceptional Flow of Events 02: In case the system determines that
one or more of the identifying information for a person matches one or
more person(s) already in the system the Registrar is displayed with a
screen listing all the person(s) meeting the search criteria. The
Registrar is then given the opportunity to either create the person in
the system with a new ID or pick one from the selection list.
40

 Use Case Title: Get Patient Profile using Patient ID
 Actors / Roles: Nurse, Patient, and Profile Access
 Classes:
 Enduring Business Themes (EBT): Diagnosis, Customer Service
and Complete Medical History
 Business Objects (BO): Profile Access, Identify Person and
Identity
 Industrial Objects (IO): Identity Access
41

 1. The Nurse enters the Person ID for the person.
 2. The Person Identification system determines the validity of the
Person ID.
 3. The Get Profile System returns the profile the specified Person ID.
 Exceptional Flow of Events 01: If the Person ID is invalid an error
message is displayed. The nurse then can decide either to search the
system with person identification information or redirect the person to a
Registrar.
42
Bibliography and Suggested Reading
 “Object-Oriented Software Engineering: A use Case Driven Approach”, by Ivar
Jacobsen
 “Use Case Modeling: Capturing User Requirements” by Edward Kenworthy (
http://www.zoo.co.uk/~z0001039/PracGuides/pg_use_cases.htm)
 “Structuring Use Cases With Goals” by Alistair Cockburn
(http://members.aol.com/acockburn/papers/usecases.htm)
 “Use Cases Fundamentals” by Alistair Cockburn
(http://members.aol.com/acockburn/papers/AltIntro.htm)
 “OOSC2: The Use Case Principle” by Bertrand Meyer (
http://www.elj.com/elj/v1/n2/bm/use-cases/ )
 “The Roles of Use Cases in Analysis” by Daniel A. Rawsthorne, PhD
(http://www.pols.co.uk/usecasezone/UseCaseConcepts.html )
 “The Misuse of Use Cases” By Dr. Timothy Korson
(http://www.software-architects.com/publications/korson/Korson9803om.htm )
 “Constructing Useful Use Cases” By Dr. Timothy Korson
(http://www.korson-mcgregor.com/publications/korson/usecase3/index.html )
Discussion Questions
• What are the use case modeling good, bad, and ugly?
• Define: Actor, role, and use case
• What are the differences between use cases and
scenarios?
• What are the differences between use case and a
process?
44
Questions for the Next Lecture
 Define:
– Enduring themes
– Business Objects
– Industrial Objects
 Discuss the ways to analyze a problem.
 What is a problem?
 What are the elements of problem
analysis?
45

Software Design Methodologies: UML in Action: Dr. Mohamed Fayad, J.D. Edwards Professor

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Software Design Methodologies: UML in Action: Dr. Mohamed Fayad, J.D. Edwards Professor

Hochgeladen von

Copyright:

Verfügbare Formate

Software Design Methodologies:

Dr. Mohamed Fayad, J.D. Edwards Professor

May-June 2001 ISISTAN Research Institute – Tandil,

 Overview of Previous Lecture

Objectives – What is use case modeling?

 use case model: a view of a system

actors of the system.

system Represents the boundary between

use case can be inserted into the

 Shows use cases, actor and their

«include» «include» «include»

Extension points «extend»

Fig. 3-45, UML Notation Guide

 Traveler has logged on to the system and selected ‘change

 System retrieves traveler’s account and flight itinerary from

 If no flights are available then …

 Model user requirements with use cases.

 You have been contracted to develop a

 Time to start gathering the user requirements.

 We must now identify the users of the system

Use Case Template

 A flow of events description is created for each use case

Checkout Book Return Book Checkout Journal

 Books and Journals: The library contains books and

 Borrowing: It is essential that the system keep track of

*Example from: “Using UML”, by: Pooley and Stevens

 The ESU University wants to computerize

Maintain Curriculum Request Course Roster Maintain Schedule

Copyright © 1997 by Rational Software Corporation

Request Course Roster

Billing System Maintain Curriculum

Copyright © 1997 by Rational Software Corporation

Copyright © 1997 by Rational Software Corporation

1. Use Cases emphasize ordering. This can be

Do not invent requirements!

 Object Modeling with OMG UML:

 “Using UML: Software Engineering With Objects and

“Analysis and Design with UML”

 Use Case No.: 1.1.1

 Description of the Use Case:

 Use Case No.: 1.2.1

 Exceptional Flow of Events 01: If any of the identifying information

 Use Case No.: 1.3.1

 Description of the Use Case:

Das könnte Ihnen auch gefallen