Bowling Alley Management System Team

1
Bowling Alley Management SystemTeam ?
2
Project Architecture
3
ControlDesk

• Behavior
• User login
• User register
• Start game
• Print report
• Email report

• User login
• Manages all games being played and the current
  forming game
• Generates reports for emailing and printing
• Assigns parties to lanes
• Starts games

• State
• Forming party
• Games

4
BowlerDatabase

• Holds all registered users
• Ability to write/retrieve information from hard
  disk

• Behavior
• Open database
• Add user
• Remove user
• Write database
• Close database

• State
• All bowlers in the database
• Filename of the database

5
Game

• Behavior
• Get final score at end of game
• Update bowler statistics at end
  of game
• Creates the ScoreGUI when the game is started
• Directs pinsetter input

• Creates single game objects for each bowler
• Manages frames and calculates scores for each
  bowler
• Handles strikes, spares, splits
• Knows when all bowlers are finished

• State
• Current party playing
• Score
• Pinsetter

6
Bowler

• Keeps track of the users
• Nick name
• Full name
• Email address
• Statistics (including overall average and scores
  from all previous sessions)

• Behavior
• Updating statistics from a recently completed
  game
• Retrieving records

• State
• User properties
• Previous session data

7
ControlDeskGUI

• This is the class that users use to input data
  such as nickname, full name and email address.
  The current party is displayed as people are
  added to it.
• Once the party has been created, the user can
  click yes next to the start game question and the
  game will be started. Otherwise, the user can
  click no next to the start game question and keep
  entering party members up to the max of 5.
• The user can click the View Statistics tab to see
  his/her current stats for a completed game.
  There are also choices to print and/or email the
  stats. There are list boxes to select a game and
  to select a player for a given game.
• The user can quit the program by closing the
  window or by going to file quit.

8
Registration Tab
Option to quit in file menu
Current party members
Input fields
Begin game with this button
Click here to add to party
9
Statistics Tab
List of all the current games.
List of players for the given game
Statistics for a game that has been completed.
Click this button to print the statistics
Click this button to email the statistics
10
ScoreGUI
This GUI displays the users nickname to the left
of the list of frames. The pins are displayed as
numbers 1-10. Buttons that can be pressed
include the distress button in times of trouble,
the reset button to reset the pins, bowl to bowl
a single ball manually, and Auto Bowl will bowl
the whole game.
11
Email example
12
Graphical User Interface Report

• Five subjects (none of whom are currently in
  software engineering) were asked to use the
  graphical user interface of the bowling
  application in order to determine the extent of
  ease of use.
• Summary of subjects
• 2nd year Computer Science student.
• 3rd year Psychology student.
• 1st year Computer Engineering student.
• 1st year Computer Science student.
• 2nd year Information Technology student.
• Improvements for the current user interface
• Pressing enter after entering a bowlers nickname
  is not intuitive. It would be better to have
  tabbing enabled and to have a submit or login
  button.
• The Bowling window should have a Quit and New
  Game button.
• The email field for a bowler should be validated
  just in case a user types their email address
  incorrectly.
• Clicking the distress button should bring up a
  message on the main GUI window, not to the
  console screen.
• The buttons on the bowling window should be
  phased out as soon as the game is over so that
  the user knows that the game is over.
• Assets of the current user interface
• The drop-down menu for viewing different game
  scores is very useful.
• The different colors for different games help to
  keep track of different games.
• The tabs are fast and easy to use.

13
Rationale

• Originally, Game was designed to hold all the
  ScoreFrame objects for every Bowler and manage
  the entire scoring process. This has been changed
  with an inner class SingleGame which handles the
  scoring and frames of a single bowler. Game now
  manages the Party of bowlers and the interaction
  of their SingleGames.

14
Strengths

• Lubricated
• Components can be changed without modifying a
  great deal of code in other components.
• New views can be added to models without changing
  the model.
• Components know only of what they observe.

15
Strengths

• Speed
• Each FrameGUI displayed only updates when the
  ScoreFrame is changed.
• No large updates or complete redraws of ScoreGUI.
• Changes in one component only affect a few. For
  example, changes in Game will not affect the
  PinSetterGUI.

16
Weakness

• Intuitive
• Parts of the GUIs are not as intuitive as they
  should be.
• There is no check to see if a user would like to
  log in as an already registered user or to create
  a new nickname.
• No way to remove people from the forming party.
• Solution
• Have a separate GUI for registering users and use
  the Registration tab only for returning users.

17
Give Two More Weeks

• Fix the GUIs.
• Create a more flashy PinSetterGUI.
• Have a BowlerDatabase editor.
• Implement Distress button.
• Implement Game viewing in ControlDeskGUI.