Systems Analysis II Use Case Diagrams - PowerPoint PPT Presentation


PPT – Systems Analysis II Use Case Diagrams PowerPoint presentation | free to view - id: 161702-ZDc1Z


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Systems Analysis II Use Case Diagrams


... could be through any mechanism keyboard, mouse, touch screen, card reader, etc. ... 'Shipping clerk navigates to the New Shipment Screen. ... – PowerPoint PPT presentation

Number of Views:46
Avg rating:3.0/5.0
Slides: 38
Provided by: gle9


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Systems Analysis II Use Case Diagrams

Systems Analysis II Use Case Diagrams
  • INFO 355
  • Glenn Booker

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

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

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

  • 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.

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

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

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
  • E.g. an existing human resource system, or
    accounting system

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

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

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

Sample Use Case Diagram
Use Case Diagram Notation
  • Lines connect actors to the use cases they can
  • 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

  • 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

  • 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

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

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

Documenting Use Cases
  • Use cases can be documented to varying levels of
  • 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)

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

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
  • Main Success Scenario (MSS)

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
  • Open Issues for scope issues, if any

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

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
  • See Summary of UML Diagrams handout for details
    on MSS writing

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
  • A MSS describes a use case in more detail than
    you would typically consider necessary

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

Main Success Scenario
  • Typical actor activities in a MSS are
  • Navigate through the interface to a defined
  • Shipping clerk navigates to the New Shipment
  • 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
  • Notice every field entered is not specified

Main Success Scenario
  • Describe when an actor selects something on an
  • Dispatch manager selects the number of drivers
  • 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

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

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
  • System updates the screen to show the list of

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.

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

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)

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

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

  • 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

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

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