Systems Analysis II Use Case Diagrams - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Systems Analysis II Use Case Diagrams

Description:

... 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
Category:

less

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

Title: Systems Analysis II Use Case Diagrams


1
Systems Analysis II Use 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
About PowerShow.com