Object-Oriented Modeling
Using UML
CS 3331
Section 2.4 Modeling Requirements with
Use Cases
1
Outline




Intro. to UML
Use cases and use case diagrams
Use case scenarios
Case study
2
Unified Modeling Language (UML)



Notation for object-oriented modeling
Standardized by Object Management Group
(OMG)
Consists of 12+ different diagrams
Use case diagram
 Class diagram
 State machine diagram
 Sequence diagram
 Activity diagram
 Deployment diagram
 …
Q: Why so many different diagrams?

3
Modeling Requirements

What’re requirements?


Requirements vs. design
How to describe requirements?
4
Describing Requirements



One way to describe a system is to
create a “story”, the interaction between a
user and the system.
This story should be just one path
through the system, start to finish, that a
user will want to take.
E.g., ATM
5
Use Cases
A use case defines a sequence of
actions performed by a system that
yields an observable result of value
to a user (called an actor).
 Characteristics




A use case is typically initiated by an actor.
A use case provides value to an actor.
A use case is complete.
6
Documenting Use Cases

Use case diagrams,
consisting of:



system
actors
use cases
system boundary
Goldmine
Check grades
actor
Student
use case
7
Elements of Use Case Diagram

Actor:


Use case:



Represents a role played by external entities that
interact with the system
Describes what the system does (i.e., functionality)
Interaction between an actor and the system
Relationship:



Extension (or generalization) among actors
Association between actors and use cases
Dependency among use cases: include, extend, and
generalization
8
Example: Goldmine
Goldmine
Check schedule
User
Check grades
<<include>>
User
Validate user
Student
View roster
<<include>>
Student
Instructor
<<extend>>
Instructor
Enter grades
9
Relationships between Use Cases

Include dependency



Extend dependency



Always initiated (idea similar to method call)
Explicitly stated in including use case
Conditionally initiated (similar to callback or exception
handling)
Implicitly (or not) stated in extended use case
Generalization

Similar to subclassing (generalization/specialization)
Register
international student
Register student
10
Guidelines
1.
Identify actors


2.
Identify uses cases by asking for each actor

3.
Roles played by external entities that interact with the
system (humans, machines or other systems)
Importance: define the boundary of the system
Tasks, data, events, etc. it wants to perform, …
Identify relationships between/among:



Actors and use cases
Use cases
Actors
11
Exercise (5 minutes)


Form a group (of three or four)
Draw a use case diagram for the
Battleship game by identifying



Actors
System boundary
Use cases
12
Use Cases Revisited


How to describe a use case itself?
A scenario is a sequence of steps describing an
interaction between a user and a system.
The customer browses the catalog and adds desired items
to the shopping basket. When the customer wishes to pay,
the customer describes the shipping and credit card
information and confirms the sale. The system checks the
authorization on the credit card and confirms the sale both
immediately and with a follow-up email.
What if the credit card authorization fail? A separate
scenario!
13
Use Cases (Cont.)


A use case is a set of scenarios tied
together by a common user goal (e.g.,
success and failure together, and other
alternative paths).
A use case can be documented by
describing all its scenarios.
14
Use Case Scenarios
Use Case: Check Grades
Description: View the grades of a specific year and semester
Actors: Student
Precondition: The student is already registered
Main success scenario:
User
1. The student requests to
show his/her grades.
System
2. The system carries out “Validate user”, e.g.,
for user “miner” with password “allAs”.
3. The system prompts for the year and semester.
4. The user provides the year
and semester, e.g., Fall 2015.
5. The system displays the grades of the courses
taken in the given semester, i.e., Fall 2015.
Alternative:
The student enters “All” for the year and semester, and the system displays
grades of all courses taken so far.
Exceptional:
The “Validate User” use case fails; the system repeats the validation use case.
15
Guidelines
1.
Identify a main success scenario (MSS)


2.
Check each step of the MSS to identify


3.
Assume that every thing goes well, i.e., no exceptions
and no errors.
Write each step of the scenario, from start to end.
Alternatives, exceptions, and error cases
If significant, introduce new (secondary) scenarios for
them.
Merge the MSS and alternatives/exceptions into
a single coherent description.
* Avoid design/implementation dependent terms, e.g., menu selection or
menu selection.
16
Style Guidelines (Ambler, 2005)








Use case names begin with strong verbs.
While use cases do not imply timing, order cases from top to
bottom to imply timing (improves readability).
The primary actors should appear in the top left.
Actors are associated with one or more use cases.
Do not use arrows on the actor-use case relationship.
Do not show actors interacting with each other.
Apply <<include>> when you know exactly when to invoke
the use case. These should rarely nest more than 2 deep.
Avoid using <<extend>>.
17
Case Study: E-book Store
Identify the main actors and the key use cases for an e-bookstore,
and draw a use case diagram. Describe the use case scenario for
the most important use case.
The core requirements of the e-bookstore are to allow its
customers to browse and order books, music CDs, and computer
software through the Internet. The main functionalities of the
system are to provide information about the titles it carries to help
customers make purchasing decisions; handle customer
registration, order processing, and shipping; and support
management of the system, such as adding, deleting, and
updating titles and customer information.
18
Sample Solution
Register
<<include>>
Manage
Catalog
Catalog
manager
Logon
<<extend>>
Customer
Shop
<<include>>
Process
Order
Inventory
manager
Manage
Account
System
administrator
19
Sample Solution (Cont.)
Use Case: Shop
Description: Browse the catalog and place an order
Actors: Customer
Precondition: The customer is already registered
Main scenario:
User
Repeat the following until done:
Search and browse titles
Select a title to buy
Done with shopping and check out
Confirm order and payment method
System
Carry out “Logon”
Show info about the titles
Add the title to the shopping cart
Display shopping cart contents and
shipping and billing address
Validate payment method
Process order; issue e-receipt and notify
warehouse for shipping
Alternative:
The customer saves the shopping cart without checking out.
Exceptional:
Customer authentication fails: repeat the logon procedure.
Payment validation fails: prompt the customer for new payment information.
20
Exercise


Form a group (of three or four).
Document the use cases of the Battleship
game by identifying and defining their use
case scenarios.
21