Systems Analysis II Use Case Diagrams

1
Systems Analysis IIUse Case Diagrams

• INFO 355
• Glenn Booker

2
Purpose of Use Cases

• Use cases are developed to capture the functional
  requirements of a system
• Some non-functional aspects may be described as
  well, but dont count on use cases to capture all
  non-functional requirements
• A use case is a significant type of activity
  performed, using the system, by one or more actors

3
Use Cases and OO

• Though use cases are often associated with object
  oriented analysis, use cases are not object
  oriented
• They could be used to help capture functional
  requirements for any type of system

4
Use Case Diagram

• A use case diagram summarizes all the major use
  cases for a system
• To define a use case diagram, need
• List of Use Cases
• Actors
• External Systems (if any)
• System Boundary

5
Actors

• Actors are types of users of the system the
  role of someone who uses the system
• Actors must interact directly with the system
• Interaction could be through any mechanism
  keyboard, mouse, touch screen, card reader, etc.

6
Actors

• Examples of actors include
• Customer (if they interact directly)
• Manager (could be more specific)
• Administrator
• Clerk
• Foreman

7
External Systems

• External systems are any non-human (generally
  computerized) actor which your system needs to
  perform one or more use cases
• Can be a Timer, to initiate automatically
  repeating use cases
• Are systems you dont control, and are outside
  the scope of your system development

8
External Systems

• Could include systems owned by vendors
• E.g. a service to maintain your online catalog
• Could be a custom legacy system which isnt being
  replaced
• E.g. an existing human resource system, or
  accounting system

9
System Boundary

• The use case diagram includes a box to show the
  boundaries of your system
• Actors are not within the boundary
• External systems are not within the boundary
• Box is labeled with your systems name
• The use case diagram also acts like a context
  diagram

10
Naming Use Cases

• Each use case should have a brief name, typically
  2-4 words
• Start with a verb, and end with a noun
• Cancel Customer Order
• Place Order
• Validate New Customer
• Number use cases sequentially

11
Use Case Diagram Notation

• Actors are represented by stick people, with
  their role below them
• Use cases are represented by ovals
• External systems are represented by rectangles,
  with ltltactorgtgt before the system name
• ltltactorgtgt is a stereotype

12
Sample Use Case Diagram
13
Use Case Diagram Notation

• Lines connect actors to the use cases they can
  perform
• Hence a major purpose of the use case diagram is
  to show what functions the system can perform,
  and who can use them
• Notice there is no indication of when use cases
  are performed, or any of the logic behind them

14
Generalization

• A common concept for the use case diagram is when
  one actor has some special use cases, but also
  can do everything some other actors can
• A manager or supervisor can do everything their
  staff can do, plus additional functions
• Show this using generalization

15
Generalization

• Notice the triangle at the top of the line
  between Manager and Staff
• This means that Manager inherits all use cases
  which Staff can do
• Also can use generalization in Class diagrams
• Helps keep use case diagram simpler and easier to
  read

16
Included Use Cases

• When documenting use cases, might find a clear
  set of activities that appears in two or more
  use cases
• Can pull those activities out and make that an
  included use case
• In Visio, lines to an included use case have the
  stereotype ltltusesgtgt
• In other applications, stereotype is
  ltltincludesgtgt

17
Included Use Cases

• The included use case is documented separately
  from the use cases which use it

18
Documenting Use Cases

• Use cases can be documented to varying levels of
  detail
• Well define two of them
• Casual use case documentation
• Detailed use case documentation
• These are local terms for the level of
  documentation, not Cockburns
• (thats pronounced CO-burn)

19
Casual Use Case Documentation

• Consists of
• Use case number and name
• Objective A sentence to elaborate on the main
  purpose of the use case
• Primary Actor what actor initiates the use case
• Main Success Scenario a step-by-step
  description of the events which should occur
  during this use case

20
Detailed Use Case Documentation

• Consists of
• Use case number and name
• Objective
• Primary Actor
• Secondary Actor(s) other actors who play a
  significant role in this use case
• Trigger what event forces the start of this use
  case?
• Main Success Scenario (MSS)

21
Detailed Use Case Documentation

• Extensions when performing the MSS, what other
  events could occur?
• Extensions often include alternate methods of
  processing, different ways to do the same thing,
  and error conditions
• Performance time how long it should typically
  take to perform this use case
• Frequency how often will this use case be
  performed?
• Open Issues for scope issues, if any

22
Beyond Detailed

• The MSS and/or extensions should cite included
  use cases, where appropriate
• Additional documentation is possible beyond the
  detailed template just given see Cockburns site

23
Main Success Scenario

• The Main Success Scenario describes the
  interaction between actors and the system in
  order to perform a use case
• They are critical to write well, since later
  documentation depends upon them (e.g. sequence
  diagrams)
• See Summary of UML Diagrams handout for details
  on MSS writing

24
Main Success Scenario

• Where to begin?
• For most use cases, you can assume the actor has
  logged into the system (if needed) and are
  starting at the applications Main Menu or its
  equivalent
• A MSS describes a use case in more detail than
  you would typically consider necessary

25
Main Success Scenario

• The MSS describes the most common way a use case
  will be performed successfully
• If there are multiple processing options, pick
  the most frequent one for the MSS, and describe
  the rest in the Extensions
• In the MSS, assume all actions will be
  successful describe how to handle unsuccessful
  outcomes in the Extensions

26
Main Success Scenario

• Typical actor activities in a MSS are
• Navigate through the interface to a defined
  objective
• Shipping clerk navigates to the New Shipment
  Screen.
• Notice we didnt say HOW they navigate, just that
  its accomplished somehow
• Enter data onto an interface
• Shipping clerk enters the data for a new
  shipment.
• Notice every field entered is not specified

27
Main Success Scenario

• Describe when an actor selects something on an
  interface
• Dispatch manager selects the number of drivers
  needed.
• Indicate when an actor completes an activity,
  such as by submitting data
• Shipping clerk submits the new shipment data.
• This prompts the system to do something with the
  data

28
Main Success Scenario

• The only remaining type of actor action is to
  exit the application, which often isnt part of a
  MSS
• So there are few things an actor might do during
  a MSS
• System actions can be much more complex

29
Main Success Scenario

• Typical system actions include
• Create a new interface screen
• System displays Define Shipment screen.
• Change or update the contents of an existing
  screen
• System updates the screen to show the list of
  artifacts.

30
Main Success Scenario

• Communicate with an external system
• System gets current stock price from NYSE.
• System emails drivers with shipment info.
• Perform an included use case
• System performs Validate Credit Card use case.
• Perform background processing
• System validates new customer data.
• System computes the sales tax.

31
Main Success Scenario

• Notice that the MSS includes steps which arent
  visible to the actors!
• Other background processing might include
• System prioritizes the list of drivers.
• System produces weekly sales summary.
• In short, background processing can include any
  activity needed to prepare for presenting the
  results to the actor

32
Main Success Scenario

• Finally, make sure a MSS achieves the objective
  of the use case!
• System saves new customer data.
• System updates order status.
• System deletes completed orders.
• (These steps are typically performing one of the
  CRUD functions)

33
Main Success Scenario

• Writing a MSS might involve making assumptions
  about where or how data is stored
• Might assume there is a place that stores
  Customer Data, or Shipment Data, etc.
• External systems should be named consistently
  throughout design

34
Main Success Scenario

• Throughout a MSS, look for actions which need to
  be repeated
• Specify in generic terms how many times steps
  need to be repeated
• For each book to be checked out,
• For each driver assigned to a shipment,
• Repeat five times, or until login is successful

35
Extensions

• Extensions, or alternate scenarios, handle when
  something doesnt go normally during a use case
• Extensions are numbered, starting with the MSS
  step from which they depart
• If an extension starts from step 5, the extension
  is 5.a
• If that extension needs multiple steps, they are
  5.a.1, 5.a.2, etc.
• A second extension from step 5 is 5.b

36
Extensions Handle

• Failure conditions when a MSS step cant be
  performed successfully
• If a search yields no results
• If payment is insufficient
• Cant connect to an external system
• Alternate processing when a MSS step can be
  processed differently
• Handle domestic versus international orders
• Handle different forms of payment

37
Extensions Handle

• Optional processing steps are described, but the
  rest of the MSS isnt affected if they arent
  used
• Adding sales tax to an order
• Adding gift wrapping to an order