Use Case Model
for the
Billiard Game Simulation System
Submitted by
Dan DeBlasio
Devendra Salvi
Juan Sanmiguel
CEN 5016
Spring 2007
Table of Contents
Title
Page
1.0
1.1
1.2
1.3
1.4
2.0
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3.0
3.1
3.2
3.3
4.0
System Summary .................................................................................. 1
Document Scope ......................................................................................... 1
Motivation and Business Case .................................................................... 1
Concept of Operation .................................................................................. 1
Billiard Game Architecture and Interfaces ................................................. 4
1.4.1 Physical Design and Actor Interfaces ............................................. 4
1.4.2 Operational States ........................................................................... 5
Use Case Specifications ........................................................................ 7
Specify Input ............................................................................................... 7
Specify Output ............................................................................................ 7
Construct Table ........................................................................................... 8
Initialize Simulation .................................................................................... 8
Run Simulation ........................................................................................... 9
Output Table ............................................................................................... 9
Report Post Simulation Data ..................................................................... 10
System Requirements.......................................................................... 11
Functional Requirements .......................................................................... 11
Non-functional Requirements ................................................................... 12
3.2.1 Performance Requirements ........................................................... 12
3.2.2 Usability Requirements ................................................................. 12
3.2.3 Integration Requirements .............................................................. 12
Requirements Traceability ........................................................................ 13
Glossary .............................................................................................. 15
Table of Figures
Title
Page
Figure 1.3 Use Case Diagram for BGS ............................................................................... 2
Figure 1.4-1 BGS System Physical Conceptual Design .................................................... 4
Figure 1.4-2 BGS Game State Diagram ............................................................................ 5
Figure 1.4-3 BGS Player Turn State Diagram ................................................................... 5
Figure 1.4-4 BGS System Ball State Diagram................................................................... 6
Figure 3.3-1 Functional Requirements Traceability Matrix ............................................. 13
Figure 3.3-2 Non-Functional Requirements Traceability Matrix ..................................... 14
1.0
System Summary
1.1
Document Scope
This document describes the functional requirements (use cases) and design constraints
(non-functional requirements) of the Billiard Game Simulation (BGS) system as viewed
from the perspective of the client, 8BallTM Billiard Training Institute, and the system’s
typical end user, a Billiards Player. Its purpose is to formally capture and present an
operational view of the Billiard Game Simulation system and to enumerate the system
requirements as understood by the developer, PoolSim, Inc.
1.2
Motivation and Business Case
8BallTM Billiard Training Institute, hereafter referred to as “8Ball”, has observed in
increased interest in learning the game of billiards and a shortage of available tables in
their operating area. As a consequence of this trend, the Marketing department of 8Ball
has decided they need a way to train students with a limited amount of time on an actual
billiards table and to teach them the rules of all the games available. The Research and
Development sector of 8Ball decided that the best way to accomplish this task is to let
the player watch simulated games of pool to learn the physical technicalities of the game
and help them grasp the concepts before actually getting to the table.
Since 8Ball does not employ any persons who would be able to accomplish this task they
have hired PoolSim, Inc (PoolSim) to develop the system for them. In doing so, they
have requested certain requirements be available so that the end user can get the most out
of their using the simulator.
1.3
Concept of Operation
Figure 1.3 presents a functional model of the envisioned BGS system. User-oriented
functions (use cases) are identified by round bubbles appearing inside the box denoting
the physical and logical boundary of the new system. All entities shown outside the
system box represent actors, that is, independent agents that must interact with the
system to accomplish all use cases defined by the diagram. As shown in the figure, there
are three actors: the Billiards Player, an input file and an output file.
Page 1
Figure 1.3 Use Case Diagram for BGS
[Para.1] The User for the pool simulation provides BGS with the input parameters for
the simulation in form of an input file. The User specifies the input file and the output
file. The User initiates the simulation by inputting the type of game, the player details and
other parameters for the game. The User also executes the simulation.
[Para.2] The input file consists of the details for the simulation. The input file specifies
the rules for the game simulation. It also specifies the player details like name and skill
level. The input file also describes the game world conditions for instance, the placement
of balls, number of balls based on the type of game to be simulated and the dimensions of
the table.
[Para.3] The output file will hold the results of the simulation. The reported data will
include, the details of the shot i.e. the angle at which the cue stick hits the cue ball, the
force with which it was hit, the angle a particular ball was hit, the final vector of the balls
including the cue ball, the state of the game when all balls come to rest on the table, the
balls that were pocketed and if a foul was committed.
[Para.4] The user specifies which file will hold the input parameters. The path of the file
and the name of the file are specified as the input file for the simulation system. BGS
reads from the specified input file.
[Para.5] The user also specifies output file where the results of the simulations should be
saved to. The user specifies the path and name of the file BGS writes data to. BGS writes
to the specified output file.
Page 2
[Para.6] Using the input file specified by the user, the system lays out the pool table. The
pool table is constructed as per the dimensions specified in the input file. The numbers of
balls are placed on the table as per the game type specified in the input file. Their
formation is also set as per mentioned in the input file. The setup is used to actually
simulate the game. This initial state is reported to the output file as well, specified by the
user.
[Para.7] Once the table is constructed, the game is initialized using the input values such
as the player details from the input file. This state kicks off the simulation state. The
initial values are used only once throughout the simulation. Once the simulation is run,
this state is not traversed again.
[Para.8] The actual simulation works as a loop until a player wins the game. Every game
state leads to a new game state. The simulation decides on the best shots to be taken. The
simulation will / may vary on every run for the same set of players. The simulation part
decides the next shot to be played using the rules from the input file. It also decides if a
player has fouled or pocketed ball(s). The simulation also monitors which player wins the
game which leads to the end of simulation. After every intermediate state, the event is
written to the output file. This output also include, the new placement of balls on the
table.
[Para.9] The output file contains the initial as well as the final state of the table. The final
table state when either of the players has won will be sent to the output file.
[Para.10] The final result includes the total time taken to finish the simulation and the
number of shots played by either player. This report is written to the output file specified
by the user.
[Para.11] The default game mode, if not specified in the input file, will be ordinary
billiards game. The game will be simulated using rules for billiards. The simulation will
have the table setup in accordance to the billiards game. The simulation for the default or
any other case will be independent of the type of game played. The simulation will be
purely based on the next possible best shot to be simulated.
[Para.12] The game to be simulated is assumed to have only two players. It is also
assumed that the table surface and the balls are uniform. Other assumptions include that
the balls move in straight line void of any spin on them.
Page 3
1.4
Billiard Game Architecture and Interfaces
1.4.1 Physical Design and Actor Interfaces
Figure 1.4-1 illustrates the physical design of the proposed BGS system.
Figure 1.4-1 BGS System Physical Conceptual Design
Notice in the image above that the table is also referred to by some as the slate. This
document will use the term table. The player uses the cue to strike the cue ball. The cue
ball then strikes other balls. The goal is to get the balls (other than the cue ball) into the
six pockets on the ‘table’. The player is not permitted to hit the balls that are not the cue
ball with the cue. There is also a penalty that will be assessed for getting the cue ball in a
pocket, this will be discussed later.
The Billiard Player will only be prompted for two file names. Once this happens the
system is completely self contained, but they will be able to watch the progress of the
virtual game initially though a text interface, then at a later date though a GUI. BGS only
performs one function, simulating a game of billiards, but can be programmed to simulate
any of the various billiard games that might be played by the end user.
The rules of each game will be specified by 8Ball when they have an initial input file to
the user. Since the end user is assumed to be a novice they would not know all the rules
of the game. In addition 8Ball would also enter the users beginning playing level and the
opponents’ user level. This will be used to help simulate the game. In the case where the
user obtains the program without the input file from 8Ball and there are no rules
specified, then the simulator will process a standard billiards game, with no specifics
pertaining to ball shot choice.
Page 4
1.4.2 Operational States
The behavior of the BGS is the interaction of two players. Each player will take a turn
until there are no balls left for them to choose from, at this point the game is finished and
a winner is declared. Figure 1.4-2 shows the state diagram for the system as a whole.
Figure 1.4-2 BGS Game State Diagram
On each player turn, they will hit the cue ball; this in turn (possibly) hits other balls. If
any of the balls go in (that are not the cue ball) then the player continues his turn. Figure
1.4-3 shows how the cycle of one player turn.
Figure 1.4-3 BGS Player Turn State Diagram
Page 5
Once the cue ball is hit by the player the player will have no control over his turn until it
gets a response back that either a ball went in and they can continue or that there turn is
over. Figure 1.4-4 shows how balls interacts with each other, note that the cue ball is just
a ball where the message to move comes from the player not another ball.
Figure 1.4-4 BGS System Ball State Diagram
Page 6
2.0
Use Case Specifications
This section gives the detailed specifications of the use cases described above.
2.1
Specify Input
ID: UC1
Purpose
The purpose of the Specify Input use case is to determine which file will hold the
input parameters used by BGS.
Pre-conditions
There exists an input file for BGS.
Scenario
1. User is asked for an input file.
2. User types in filename and if necessary the file’s path
3a. If filename is accepted BGS will ask for the output file.
3b. If filename is rejected, User is asked for the input file again.
Post-condition
BGS is set to read the input from the file entered.
2.2
Specify Output
ID: UC2
Purpose
The purpose of the Specify Output use case is to determine which file the BGS will
write its outputs too.
Pre-conditions
The system the BGS is on has enough disk space to hold the output file.
Scenario
1. User is asked for an output file.
2. User types in filename and if necessary the file’s path
3a. If filename is accepted BGS will continue.
3b. If filename is rejected, User is asked for the output file again.
Post Condition
BGS is set to output the data to file entered.
Page 7
2.3
Construct Table
ID: UC3
Purpose
The purpose of the Construct Table use case is to create all the objects needed to run
the BGS.
Pre-conditions
BGS is set to read an input file with the simulation parameters
Scenario
1. The BGS reads the input file.
2. BGS creates the pool table, players, balls and rules described by the input file.
3. If there are errors in the input, then the program terminates and reports the
error to the user.
Post-condition
All the objects needed by the BGS are created.
2.4
Initialize Simulation
ID: UC4
Purpose
The purpose of Initialize Simulation use case is set up the game determined by the
information form the input file.
Pre-conditions
All objects defined in the input file have been created.
Scenario
1. The balls are positioned as indicated by the rules file.
2. Players score initialized at zero.
Post Condition
The BGS is ready to begin the simulation
Page 8
2.5
Run Simulation
ID: UC5
Purpose
The purpose of the Run Simulation use case is to start the game simulation.
Pre-conditions
BGS has all the data needed to run the game.
Scenario
1. The game starts.
2. Players will take shots as determined by the rules.
3. Balls move according to the outcome of the shot.
4. Players scores are recorded.
5. Game play continues until a winner can be determined.
Post-condition
BGS is ready to send post simulation information to the output file
2.6
Output Table
ID: UC6
Purpose
The purpose of the Output Table use case is to send the state of the table to the output
file.
Pre-conditions
BGS is set to send data to output file
Scenario
1. Table and other objects are created.
2. The initial conditions of the objects are sent to the output file.
3. Each event is recorded in the output file
4. Status of table and balls are sent to the output file at the end of the game.
Post Condition
Output tabled is update with the current state of the simulation.
Page 9
2.7
Report Post Simulation Data
ID: UC7
Purpose
The purpose of the Report Post Simulation Data use case is to send the post
simulation data to the output file.
Pre-conditions
The game has been completed.
Scenario
1. All post simulation statistics are calculated.
2. Post simulation data sent to the output file
Post Condition
Output file is closed.
Page 10
3.0
System Requirements
The requirements, both functional and non-functional requirements, for the BGS system
are summarized in this section. These requirements have been elicited from the
following sources.
[1] This document, sections 1.0 and 2.0.
[2] Private interviews with Dr. David Workman, Senior Research & Design
Specialist for 8Ball Training Institute, Inc.
[3] Private Interview with James Sunshine, project lead for SimGUI, Ltd.
3.1
Functional Requirements
Req ID
Description
F1
The Billiard Game Simulation system shall simulate a game of
billiards for the user.
The Billiard Game Simulation system shall simulate any of a
number of billiard games, given the constraints that a cue is used,
and that the cue ball is the only one that will be struck by the cue
stick, and no more than two players will play.
The Billiard Game Simulation system shall take in an input file
that is in ASCII standard.
The Billiard Game Simulation system shall take in an input file
that is in the standard OOP data design protocols, and follows the
sample input file structure to be delivered with the source code.
The Billiard Game Simulation system shall take the rules of the
game from the input file. If no rules are given, a standard
billiards game will be simulated.
The Billiard Game Simulation system shall implement a billiard
game with only two players.
The Billiard Game Simulation system shall implement a billiards
table and balls that are free from imperfections.
The Billiard Game Simulation system shall prompt the user for
the input and output file names.
F2
F3
F4
F5
F6
F7
F8
F9
The Billiard Game Simulation system shall provide the user with
an output file that will not only trace the entire simulation from
start to end, but also provide summary statistics.
Page 11
Section/
Para.
[1]1.3[Para.1]
2.5
[1]1.3[Para.2]
[Para.11]
[Para.12]
2.1,2.3
[1]1.3[Para.2]
2.1
[1]1.3[Para.2]
2.1
[1]1.3[Para.11],
2.4
[1]1.3[Para.12]
[1]1.3[Para.12]
[1]1.3[Para.1]
[Para.2]
[Para.3]
[Para.5]
2.1,2.2
[1]1.3[Para.3]
[Para.4]
[Para.5]
[Para.9]
[Para.10]
2.6,2.7
F10
3.2
The Billiard Game Simulation system shall not take any input
from the user once the simulation has started. It runs in a self
contained loop, with no user interruptions.
[1]1.3[Para.6]
[Para.7]
[Para.8]
2.5
Non-functional Requirements
The design constraints fall into three categories: performance, usability, and integration.
The requirements for each of these categories are enumerated in this section as they are
currently understood at the date of publication of this document.
3.2.1 Performance Requirements
Req ID
C1
C2
Description
The program will be written in C++ and must be executed on the
same platform as compilation.
A file system must be in place for the system to use.
Source
[2]
[2]
3.2.2 Usability Requirements
Req ID
C3
C4
C5
Description
The user will have an understanding of the operating environment
in which the program is to be run.
The files which are used by the program must be available and
readable (writable).
The system shall have available processor, ram and hard disk
space available to work with.
Source
[1]
[1]
[2]
3.2.3 Integration Requirements
Req ID
C6
C7
C8
Description
The Billiard Game Simulation system shall be expanded to include
a GUI at a later date.
The GUI requirements will be specified in additional documents to
be presented by SimGUI.
The system will utilize Dr. Workman’s SimMgt Framework.
Page 12
Source
[2]
[3]
[2]
Requirements Traceability
UC1 UC2 UC3 UC4 UC5 UC6 UC7
F1
X
F2
Requirements
3.3
X
F3
X
F4
X
F5
X
X
F6
X
X
F7
X
X
F8
F9
X
X
X
X
F10
X
X
X
X
Figure 3.3-1 Functional Requirements Traceability Matrix
Page 13
Use Cases
UC1 UC2 UC3 UC4 UC5 UC6 UC7
Requirements
C1
C2
X
X
C3
X
X
C4
X
X
X
X
X
X
C5
C6
C7
C8
Figure 3.3-2 Non-Functional Requirements Traceability Matrix
Page 14
4.0
Glossary
Billiard game: In this type of game, the different colored balls on the table have different
scores, e.g. when Red ball is potted, the player scores 3 points. This type of game is won
by a player who scores the maximum points in the agreed period of time.
Billiard player: an external entity which makes use of the Billiard Game Simulation
system for learning purposes.
Cue: the stick used to strike the cue ball. Alias: Cue stick
Cue ball: Cue ball is the plain white ball which acts a striker for the rest of the balls.
Foul: when the simulation has a state which contradicts one or more of the rules
specified in the input file, a foul is said to have occurred. On such an event, another set of
conditions, stated for the foul are simulated by the BGS. Alias: Scratch.
GUI: the output as well as the input of the BGS system will provided to a graphical user
interface, which renders the simulation put forth by the BGS. The GUI can include 2D or
3D graphics.
Input file: It is a text document (ASCII) which contains the input conditions (player info,
rules, etc.) for the BGS. The location of this file is specified by the billiard player.
Input parameters: These are the values which specify the rules for the simulation. These
parameters also include information about the players; the game will be simulated
around, for e.g. player name, player skill level.
Output file: It is a text document (ASCII) which holds the outcome of the entire
simulation provided by the BGS. The location, this file should be saved to, is provided by
the billiard player.
Pool Table: it is an emulation of a real world pool table, which has 6 pockets, of which 4
occupy the corners and two are in the middle of the either ends of length of the table.
Alias: slate.
Post simulation data: This is the data reported when the game is won by a player. This
includes the total time of game and number of strikes.
State of the table: Given any instance, the position of the balls and the cue balls
represent the state of the table. The state of the table also include, the score of both the
players being simulated. This state is written to the output file.
Page 15