Use Case Modeling

1
Use Case Modeling an approach to Requirements
Determination
2
Some History

• Use case introduced to IT world by Ivar Jacobson
  when working for Ericsson
• Use cases were part of larger SDLC called
  Objectory
• Jacobsons company and the Objectory Model were
  bought by Rational company and incorporated into
  RUP in 1999

3
The Use Case Basics

• Users perform behaviorally-related sequence of
  transactions
• Use cases have two parts
• The use case diagram and
• the use case itself
• Use cases model system by identifying and
  describing events
• Use textual description
• Graphical representation
• Each use case describes a single event
• System functionality defined by collection of all
  use cases

4
Goals of the Use Case

• Interactions that provide value to Actors
• Show interaction between system and external
  entities
• Each interaction should provide value to the
  triggering actor or to another external entity
• Entering data may not have value to the data
  entry operator, but has significant value to a
  database manager

5
Goals of Use Cases

• No implementation-specific language
  (context-free)
• No reference to individuals (vs roles) or
  specific interfaces (such as buttons or menus)
• Examples Whats wrong with the statements below?
• Clerk pushes OK button
• Customer seals envelope with cash and deposit
  slip and inserts into ATM slot
• Customer uses mouse to click on parts selection
  for the zip code they specified in the pull down
  menu and the click on the order finalized
  hyperlink.

6
Goals of Use Cases

• User-appropriate level of detail
• Use cases go from general to detailed
• Techies tend move to details to quickly
• Start at a general level
• Be in users vocabulary
• User-appropriate volume
• May not need too many use cases
• Good to keep number small (large systems may need
  only 70-80)

7
Use Case Elements

• Actors
• The party that initiates a behavior of the system
• Defined by roles
• Person (eg member)
• Company (eg bank)
• Another system (eg inventory)
• Use Cases
• Descriptive scenarios (how actor interacts with
  system)
• Each is a complete event triggered by actor
• Rule of thumb A use case model will contain one
  or two dozen use cases

8
An exampleoffice supplies

• Many possible use cases related to inventory and
  purchasing
• Update stocks
• Buy goods
• Return goods
• Pay by credit card
• And more
• Consider the event of a customer buying a good

9
Use Case example

• Questions to answer
• What is the general information about the event?
• Goal, scope, preconditions, the triggering actor,
  the trigger, etc.
• What is the main success scenario
• What is the chain of transactions that occur if
  the everything goes smoothly?
• What are some of the possible extensions and
  sub-variations?
• Any related information?
• Priority, frequency, superordinate use case,
  subordinate use case
• Open issues and questions
• Schedule (due date)

10
Use Case Modeling

• Definition
• A narrative document that describes the sequence
  of an actor using the system to complete a
  process.
• Stories or cases of the system use
• The UML notation for a use case

Buy Product
Name of use case
11
Use Case Modeling Activities
Identify Functional Areas
Define Detailed Use Cases
Develop Expanded Use Cases and Dependency Diagrams
Define System Context and Identify Actors
Define High Level Use Cases
Define Abstract Use Cases
12
An Example System Bon Appetit

• Assume we are are making a system for the Bon
  Appetit related to its
• Sales
• Stock
• Steps (not really sequential)
• Identify Actors
• Develop High level use cases
• Break Down into functional areas
• Develop Expanded Use Cases
• Create detailed use cases and graph dependencies
• Develop abstract use cases
• Make glossaries

13
Identify the Actors
Customer
Applies for membership
Salesperson
Provides service
Bon Appetit Point of Sale System
Requests service
Checks membership status
Requests stock check
Updates Frequent Drinker status
Responds with stock check
Inventory
Club Member
14
High Level Use Cases

• Model business event for which system is
  responsible
• Business Event
• Actions that an actor initiates with system in
  order to complete an activity
• Example Buy a beverage
• To discover use cases
• Identify all the relevant actors
• List all the events each actor can initiate
• Each event represents one high-level use case

15
Documenting a High Level Use Case

• Assign each case a name
• Identify actor or actors initiating the event
• Write a short (one-two sentences) description of
  each high level case

Use Case Buy Beverage
Actors Customer, Club Member, Salesperson
Description A customer arrives at stall to buy a
beverage. Salesperson checks membership. The
salesperson takes payment and provides receipt.
On completion, customer leaves with beverage
16
Group into Functional Areas

• Difficult to grasp system with hundreds of
  unordered cases
• Use cases need to be organized
• Partition use cases by functional area.
• Each functional area represents major business
  activity supported by system.
• Examples
• Member servicing
• Payments and credit checks
• Inventory control

17
Use Case Functional Area Model
Inventory Control
Customer services
Customer
Buy beverage
Check stocks
Salesperson
Update frequent Drinker card
Inventory
Shipping
Request membership
Member
Request New shipment
18
Expanded Use Case

• Each high level use case must be documented in
  more detail
• Expanded use case provides complete description
  of actor-system interaction
• Contains
• Name of use case
• Name of actor/s
• Description of use case
• Basic course (steps) in use case
• Pre or post conditions
• Assumptions of non behavioral issues (security,
  performance, etc)

19
Expanded Use Case Template
Name
High level use case
Actors
Description
- Description of steps from beginning to end of
interaction - Focus on basic successful course
not exceptions
Basic Course
Precondition
State system must be in for use case to begin
Postcondition
State system in after use case finishes
Assumptions
Conditions that cannot be changed
20
An expanded use case
Use Case Buy Beverage
Actors Customer, Club Member, Salesperson
Description A customer arrives at stall to buy a
beverage. Salesperson checks membership. The
salesperson takes payment and provides receipt.
On completion, customer leaves with beverage

• Basic Course
• Customer waits in line until called by next
  available salesperson
• Customer places order to salesperson
• Salesperson enters order in system and prices are
  totaled
• Customer pays for order
• Salesperson gives customer receipt and change
• Salesperson prepares order
• Customer takes possession of order

Precondition Customer is paying cash
Postcondition Order is correctly captured and
stored
Assumptions Prices for all beverages are stored
correctly in system
21
Expanded Use Case some hints

• In basic course, number the steps
• If there are sub-steps, number as 1.1 or 2.3,
  etc.
• If no specific order, use bullet points or the
  same number
• Be as narrative as possible but avoid having the
  basic course gt one page long
• Be as descriptive as possible
• Customer places order to salesperson better
  than Order placed
• Avoid exception and conditional logic
• This will be done in the detailed use case

22
Detailed use cases

• Includes all previous sections from high-level
  and expanded use cases
• Also includes extensions and sub-variations of
  the use case
• Extensions based on variations on the basic
  course (successful normal sequence of events)
• May also include a set of business rules

23
Business Rules Catalog

• Structural facts
• Fact or condition that must be true (first
  customer contact is salesperson)
• Action restricting
• Prohibiting one or more actions based on
  condition (no checks from bouncers)
• Action triggering
• Instigates action when conditions hold true (send
  shipment as soon as items have been taken from
  inventory)
• Inferences
• Conclusion when a state is achieved (Gold Card
  member when FF miles reach 100000)
• Calculations
• Calculating one value from another (sales amount
  does not include sales tax)

24
Example Buy products

• Basic course
• Buyer calls in with purchase request
• Company captures buyer information
• Company informs buyer of prices, delivery, etc.
• Buyer signs for order
• Company creates order ships to buyer
• Company sends invoice to buyer
• Buyer pays invoice

25
Example contd.

• Extensions
• 3a. Company is out of items requested
• 3a1. Renegotiate order (use case 28)
• 4a. Buyer pays directly with credit card
• 4a1. Take payment by card (use case 32)
• 7a. Buyer returns items
• 7a1. Handle the return items (use case 79)

26
Example Sub-variations

• 1. Buyer may phone, fax, or use web form to order
• 7. Buyer may pay by
• Cash
• Money order
• Credit card
• check

27
Relationships between Use Cases

• The Communicates Relationship
• The Uses Relationship
• The Extends Relationship

triggers
Use case
ltltusesgtgt
Use case A
Use case B
ltltextendsgtgt
Use case A
Use case B
28
Transferring money from an account
Local customer
Remote customer
ltltextendsgtgt
Transfer online
Transfer
ltltusesgtgt
Verify ID
Use Case Dependency Diagram
29
Use Case Dependency Diagrams

• Clarity
• Enhances understanding of system by organizing
  system functions
• Traceability
• Maps use cases to any workflow models previously
  developed
• Validation
• Identifies missing or unneeded use cases by
  indicating preconditions

30
Now you try

• In a CD Club example, consider the use cases
  below
• Ship current offering
• Place order
• Make payment
• Follow up on overdue member
• Send catalog
• Apply for membership
• Ship order
• Turn down current offering
• Mail bill

31
Example of Abstract Use Cases
Place Order
Ship Current offering
ltltusesgtgt
ltltusesgtgt
Check Account Standing
32
Abstract Use Cases

• As use cases are developed, common elements
  emerge
• Abstract use cases help
• Capture commonality
• Manage redundancy
• Facilitate change in use case model

33
Classic mistakes in developing use cases

• Good judgment comes from experience and
  experience comes from bad judgment
• - Frederick Brooks, author of No Silver Bullet

34
Whats wrong with this Use Case Diagram?
35
The mistakes

• Too many use cases do we need such a level of
  complexity?
• Has there been use case decomposition where none
  is needed?
• Have the uses relationships been used
  appropriately?

36
USES relationship

• Uses is supposed to extract commonalities
  between use cases
• More than one use case shares the same piece
  descriptive steps
• Consider the following use cases
• Calculate gross margin
• Create Sales Order
• Add Line Item

37
Uses relationship problems
38
Uses relationship problems
39
Consider the descriptions

• Use Case Enter A Sales Order
• The actor selects a customer from a list
  displayed by the system. Use use case "Lookup
  Customer". The system then displays the sales
  order screen and the actor enters the item code
  and quantity required for each item. The system
  displays a running total of the value of the
  order. Once the order is complete the actor
  confirms the order and the systems resets ready
  for the next order.
• Use Case Lookup Customer
• The actor selects a customer by entering their
  reference number. The system then displays the
  complete details of that customer, name, address
  etc along with a complete history of purchases
  they have made.
• Since the use case Enter a Sales Order
  incorporates the Lookup Customer use case, when
  combined they would read

40
Problems with the uses relationship

• The actor selects a customer from a list
  displayed by the system. The actor selects a
  customer by entering their reference number. The
  system then displays the complete details of that
  customer, name, address etc along with a complete
  history of purchases they have made. The system
  then displays the sales order screen and the
  actor enters the item code and quantity required
  for each item. The system displays a running
  total of the value of the order. Once the order
  is complete the actor confirms the order and the
  systems resets ready for the next order.
• The task of identifying the customer is done
  twice and in two different ways
• And you may not always want to see a customers
  purchase history when entering a sales order
• The uses relationship has been used without
  considering the use case description.

41
Problems with the extends relationship
42
Corrected Use Case Diagram