For the Bingo application, a use case should, technically speaking, start with a player joining the game and end with a player declaring Bingo. For our purposes, it is easier to separate the use case into three separate sections:

Join a Game
HostServer Draws a Number
Client Declares Bingo

"Join a Game" occurs once per game for each player or client. "Draw a Number" occurs for all the players/clients, and can occur 4-100 times before one of the players/clients decides to "Declare Bingo."

Definitions

"Player" refers to the human user while "client" refers to the software agent. The baseline version of the Bingo application is non-interactive, so there is no player in the list of actors.

Use cases

Use case: Join a Game

Primary Actor(s): Client
AnsweringServer

Secondary Actor(s): HostServer

Brief Description: The Client prompts the AnsweringServer to provide the current GameID (creating a new game as needed), the PlayerID, a Bingo "card," and a record of all the draws up to that point.

Preconditions: The Client, AnsweringServer, and HostServer are active, with the Client subscribed to the Java Message Service (JMS) and the latter two connected to the database.

Flow of Events:

The Client makes a request to the AnsweringServer to join a game.
The AnsweringServer creates a PlayerID and a Bingo card and stores them within the database.
The AnsweringServer retrieves from the Database the GameID and the Draws for the current game.
The AnsweringServer sends all four pieces of data to the Client.

Postconditions: The Client joins the game.

Priority: High.

Alternative flows and exceptions: If there is no game currently running, the AnsweringServer creates a new GameID and stores it in the database, and it sets a flag within the database to inform the HostServer to begin drawing numbers.

Use case: Draw a Number

Primary Actor(s): HostServer
Client

Secondary Actor(s): JMS
AnsweringServer

Brief Description: Every n seconds, the HostServer"draws" a new number and broadcasts that number to all the clients.

Preconditions: Each client has already joined a game.

Flow of Events:

The HostServer "draws" a new number. (In terms of actual implementation, all the draws are generated at the beginning of the game, so the HostServer merely updates an index within the database.)
The HostServer communicates the number and the draw order to the JMS, which broadcasts both to the subscribed Clients.

Postconditions: The number is broadcasted

Priority: High.

Alternative flows and exceptions: If, for instance, the Client recieves from the JMS the 12th and 14th draw, it will realize that it is missing the 13th draw. It will then query the AnsweringServer for a record of all the draws for the current game (with some particular GameID).

Use case: Declare Bingo

Primary Actor(s): Client
AnsweringServer
HostServer

Secondary Actor(s): JMS

Brief Description: The Client declares to the AnsweringServer that it has Bingo. The AnsweringServer confirms that, records the first winner, and informs the Client whether it won. Upon seeing that a winner has been declared, the HostServer announces that the current game is over.

Preconditions: At least one Client has joined a game, and at least four numbers have been drawn. The Client believes it has Bingo.

Flow of Events:

The Client tells the AnsweringServer that it has Bingo, giving the AnsweringServer the GameID and its own PlayerID.
The AnsweringServer retrieves from the database the Bingo card for that particular PlayerID and the current draws for that particular GameID.
The AnsweringServer uses those two pieces of data to verify that the Client has Bingo, vertically, horizontally, or diagonally (with the center spot being "free," that is, marked at the start).
If the Client has Bingo, the AnsweringServer stores its PlayerID in the database as the winner of the game with that particular GameID and stops the game.
The HostServer, upon performing its usual checks of the database, discovers that a winner has been declared and broadcasts a message to all the Clients (via the JMS) that the game is over.
Clients are then free to join a new game, and the first instance of joining will create that new game.

Postconditions: Match the preconditions for Joining a Game.The Client, AnsweringServer, and HostServer are active, with the Client subscribed to the Java Message Service (JMS) and the latter two connected to the database.

Priority: High.

Alternative flows and exceptions: If the Client does not have Bingo, the AnsweringServer informs the Client that it doesn't have Bingo.
If the Client has Bingo but another PlayerID has already been registered as the winner, the Answering Server informs the Client that it does have Bingo but it is not the winner.

Use case:	Join a Game
Primary Actor(s):	Client AnsweringServer
Secondary Actor(s):	HostServer
Brief Description:	The Client prompts the AnsweringServer to provide the current GameID (creating a new game as needed), the PlayerID, a Bingo "card," and a record of all the draws up to that point.
Preconditions:	The Client, AnsweringServer, and HostServer are active, with the Client subscribed to the Java Message Service (JMS) and the latter two connected to the database.
Flow of Events:	The Client makes a request to the AnsweringServer to join a game. The AnsweringServer creates a PlayerID and a Bingo card and stores them within the database. The AnsweringServer retrieves from the Database the GameID and the Draws for the current game. The AnsweringServer sends all four pieces of data to the Client.
Postconditions:	The Client joins the game.
Priority:	High.
Alternative flows and exceptions:	If there is no game currently running, the AnsweringServer creates a new GameID and stores it in the database, and it sets a flag within the database to inform the HostServer to begin drawing numbers.

Use case:	Draw a Number
Primary Actor(s):	HostServer Client
Secondary Actor(s):	JMS AnsweringServer
Brief Description:	Every n seconds, the HostServer"draws" a new number and broadcasts that number to all the clients.
Preconditions:	Each client has already joined a game.
Flow of Events:	The HostServer "draws" a new number. (In terms of actual implementation, all the draws are generated at the beginning of the game, so the HostServer merely updates an index within the database.) The HostServer communicates the number and the draw order to the JMS, which broadcasts both to the subscribed Clients.
Postconditions:	The number is broadcasted
Priority:	High.
Alternative flows and exceptions:	If, for instance, the Client recieves from the JMS the 12th and 14th draw, it will realize that it is missing the 13th draw. It will then query the AnsweringServer for a record of all the draws for the current game (with some particular GameID).

Use case:	Declare Bingo
Primary Actor(s):	Client AnsweringServer HostServer
Secondary Actor(s):	JMS
Brief Description:	The Client declares to the AnsweringServer that it has Bingo. The AnsweringServer confirms that, records the first winner, and informs the Client whether it won. Upon seeing that a winner has been declared, the HostServer announces that the current game is over.
Preconditions:	At least one Client has joined a game, and at least four numbers have been drawn. The Client believes it has Bingo.
Flow of Events:	The Client tells the AnsweringServer that it has Bingo, giving the AnsweringServer the GameID and its own PlayerID. The AnsweringServer retrieves from the database the Bingo card for that particular PlayerID and the current draws for that particular GameID. The AnsweringServer uses those two pieces of data to verify that the Client has Bingo, vertically, horizontally, or diagonally (with the center spot being "free," that is, marked at the start). If the Client has Bingo, the AnsweringServer stores its PlayerID in the database as the winner of the game with that particular GameID and stops the game. The HostServer, upon performing its usual checks of the database, discovers that a winner has been declared and broadcasts a message to all the Clients (via the JMS) that the game is over. Clients are then free to join a new game, and the first instance of joining will create that new game.
Postconditions:	Match the preconditions for Joining a Game.The Client, AnsweringServer, and HostServer are active, with the Client subscribed to the Java Message Service (JMS) and the latter two connected to the database.
Priority:	High.
Alternative flows and exceptions:	If the Client does not have Bingo, the AnsweringServer informs the Client that it doesn't have Bingo. If the Client has Bingo but another PlayerID has already been registered as the winner, the Answering Server informs the Client that it does have Bingo but it is not the winner.