Courses/Computer Science/CPSC 203/CPSC 203 Template/Labs Template/Week 1 - Lab 2

From wiki.ucalgary.ca
Jump to: navigation, search

Introduction

Today's tutorial introduces the scenarios behind developing use case diagrams.

Introduction to Use Cases (part 2)

In the previous lab you were introduced to use cases and a few particular scenarios of them. Today you will be continuing with the subject from the previous lab, and presented with material for group exercises. It should be noted that some of these systems merge the physical and digital worlds together -- as that is the very nature of some workflows: You may purchase a ticket for a movie online, but you will physically go through a parking gate and verify your ticket there. Coming up with new agents within or new aspects to the following scenarios is encouraged.

Scenario

Six months from now, the Grand Cineplex Odeon II is opening in downtown Calgary. It will sport a multilevel parking garage free for movie-goers, enhanced online ticket purchasing, more combos of soda and popcorn, and make a larger dent in your monthly bank statement. They have started the planning for their system infrastructure and part of this involves developing a use case diagram for their system.

Actors

  • Customers (Movie-goers)
  • Ticket Salesperson
  • Managers

Use Cases / Workflows

Customers
  • Purchase tickets (online)
  • Print tickets (kiosk)
  • Check status of movie (sold out, x% full, etc..)
  • Check available seating (which seats, or if it's a "free-for-all")
  • Reserve seating (if possible)
  • Get parking entrance receipt (by authenticating their ticket, they can enter the parking garage 15 minutes before, and park till 15 minutes after their movie)
  • Pay for parking (if they went in earlier or stayed too late)
Ticket Salesperson
  • Print tickets
  • Purchase tickets
  • Check status of movie
  • Check available seating
  • Reserve seating
Managers
  • See sales statistics
  • Refund tickets
  • Print tickets
  • Purchase tickets
  • Check status of movie
  • Check available seating
  • Reserve seating

Use Case Descriptions

Name: Purchase Tickets
Description: Purchase tickets for a movie
Primary Actors: Customer, Sales
Secondary Actors: Manager
Preconditions:

  1. Movie not sold out
  2. Movie playing

Main Flow:

  1. Customer logs into online system
  2. Customer selects movie theatre
  3. Customer selects movie
  4. Customer pays for movie

Postconditions:

  1. Customer has a ticket ID and/or printed out ticket for a movie

Alternative Flows:

  1. In-Theatre Purchase
    1. Salesperson or Manager verifies available tickets for a playing movie
    2. They get payment and processes it



Name: Check Movie Status
Description: Returns the movie status (tickets left, playing times, etc..)
Primary Actors: Customer, Sales
Secondary Actors: Manager
Preconditions:

  1. Movie exists

Main Flow:

  1. Check the number of available seats, movie times, etc..
  2. Return to user

Postconditions:

  1. None

Alternative Flows:

  1. None

Name: Check Available Seating
Description: Returns the seating chart and available seats for a given movie
Primary Actors: Customers, Sales
Secondary Actors: Managers
Preconditions:

  1. Movie exists
  2. Movie allows for seat reservations

Main Flow:

  1. Return available seats for chosen movie

Postconditions:

  1. None

Alternative Flows:

  1. None

Name: Reserve Seating
Description: Reserves seat(s) for a given movie
Primary Actors: Customers, Sales
Secondary Actors: Managers
Preconditions:

  1. Movie exists
  2. Ticket purchased for movie

Main Flow:

  1. Check to see if the seat is available
  2. Reserve it
  3. Print a new ticket if this is done in-theatre, otherwise update the e-ticket number.

Postconditions:

  1. Chosen seat is no longer available.

Alternative Flows:

  1. Movie does NOT allow reserved seats
    1. Return an error message to user

Name: Get parking receipt
Description: Prints a parking stub for customers upon them entering in their ticket id. Allows them to park in the garage.
Primary Actors: Customer
Secondary Actors: None
Preconditions:

  1. Customer has valid ticket.
  2. Ticket not used prior for the same movie at the same time.

Main Flow:

  1. Check movie time -- if the current time is sooner than 15 minutes prior to the start of the movie, charge $5/hr rounding up.
  2. Print stub

Postconditions:

  1. Entry for that ticket ID logged as having a parking permit.

Alternative Flows:

  1. None

Name: Pay for parking
Description: The workflow when a customer wishes to exit the garage
Primary Actors: Customer
Secondary Actors: None
Preconditions:

  1. None

Main Flow:

  1. Parking stub is given back to machine.
  2. Fee displayed, if any.
  3. Fee paid by customer, if any.
  4. Gate opens, customer may leave.

Postconditions:

  1. None

Alternative Flows:

  1. No parking stub
    1. Default fee of all-day given. $120.

Name: Print tickets
Description: Allows for an in-theatre kiosk or a clerk to print tickets for customers
Primary Actors: Customer, Sales
Secondary Actors:Manager
Preconditions:

  1. Valid ticket

Main Flow:

  1. Actor inputs ticket id
  2. Kiosk (or machine, or whatever) prints tickets.

Postconditions:

  1. None

Alternative Flows:

  1. None

Name: See Sales Statistics
Description: Allows a manager to see sales of tickets for the night and other statistics
Primary Actors: Managers
Secondary Actors: None
Preconditions:

  1. None

Main Flow:

  1. Output sales statistics to screen

Postconditions:

  1. None

Alternative Flows:

  1. None

Refund Tickets

Description: Allows a manager to refund a ticket if something goes wrong
Primary Actors: Managers
Secondary Actors: None
Preconditions:

  1. Valid ticket, non-expired (as in, movie is still playing under 40% or hasn't played yet)

Main Flow:

  1. Input of valid ticket
  2. Money refunded

Postconditions:

  1. Ticket invalidated

Alternative Flows:

  1. If the movie has not played yet
    1. Available tickets are increased by one
    2. All reserved seats for that ticket are unreserved and available

Exercise

Develop a use case diagram for a shipping company such as UPS or FedEx.

Requirements

  • Customers must be able to arrange for a pickup of a package to be delivered
  • Customers must be able to check the status of a package, assuming there is a tracking number for it
  • Customers must be able to refuse a package
  • Delivery people must be able to determine the next address to deliver a package to, and get directions for it
  • Delivery people must be able to confirm a package has been delivered, and store the signature of the signer.
  • Front staff must be able to accept new packages to be shipped, as well as charge customers.
  • Auditors must be able to look at past parcel sending history for a particular location or customer.
Retrieved from "http://wiki.ucalgary.ca/index.php?title=Courses/Computer_Science/CPSC_203/CPSC_203_Template/Labs_Template/Week_1_-_Lab_2&oldid=52420"