CS239 Advanced Programming

Software Requirements Specification

Programming Assignment 3

The Game of 21

Deadlines

Completed UML diagram for your application (your design) due in class in hardcopy form no later than Tuesday February 19th. You may do this diagram by hand or if you prefer, there is Visual Paradigm installed on the lab computers which can make nice UML diagrams or you may download MS Visio (which is what I used to build the diagrams we have looked at) from the MSDN alliance for free. pdf format visio format
Submit: Monday February 25 before 10PM. NOTE: Submit will not run tests for this assignment. There are too many implementation variants and randomizing factors to be able to set up submit tests.
Report: Tuesday February 26 at the beginning of class. A 10 points/day late penalty will apply for each of the 2 deadlines. If the submit is late, the report is due the next class or lab session day after successful submission. NOTE: due to our first exam on the 28th of February, late penalties will not accrue from Tuesday night through Thursday night. In other words, if you do not get it in by the Tuesday 10pm deadline, the program will only accrue 20 points late if run anytime from Tuesday 10pm through Thursday 10pm. This is to encourage you to spend that time preparing for the exam.
TIMESHEET - Again, keep a detailed timesheet. Count as design any time that you spend on the UML diagram. Also count as design any time you spend planning each method. Make a conscious effort to put more time into design that you did on the last PA. Timesheet is due stapled to the back of the report on Tuesday night. Timesheets and their variants: Excel, OpenOffice, pdf

Introduction

Background: The game of 21 (or Blackjack) is a card game played with any number of players against a dealer. Two cards are dealt for each player one face down and the next face up. The players look at their "hole" or face down card to see the total value of their hand. The dealer and the player each try to get as close to 21 as they can without going over that number with the point values of their cards. Players and the dealer can elect to take a card to try to reach 21. All subsequent cards to the first hole card are dealt face up. Number cards are worth their face value, picture cards are worth 10 points and the Ace is worth either 1 or 11 whichever will yeild the best hand. A player may choose to take cards until they feel like they have the best hand. When all players hold, the hole cards are revealed. Any player exceeding 21 is "busted" and automatically loses the hand. Players bet against the dealer...if the player is closer to 21 they win 1 1/2 times their wager. If the player and dealer tie, the player keeps their wager and if the player loses, the dealer collects the wager.

Our variant: In our variant of the game, the dealer will be the computer and the player the human user. Before the round, the player will choose the size of their wager. Human players begin with $20.00 and may not bet any more than they currently hold. Two cards are dealt to each player. The computer's hole card is not shown until the end of the round. All cards for the player are dealt face up. The computer will go first to either take a card or hold. The computer must take a card if their hand consists of fewer than 15 points (counting an ace as 11). The computer must hold if their hand consists of 15 points or more (again counting the ace as 11). The human player may choose to take a card or not based on their hand. Once both players have held, the computer's hole card is revealed and the points are tallied. During the tally, the ace will be counted in the way that is best for the player. If 11 takes them over 21 then it counts as 1, otherwise, it will count as 11. The player closest to 21 without going over is declared the winner. If the human player wins, 1 1/2 times their wager is added to their betting funds. If the computer player wins, the player loses their wager. If there is a tie, the human player keeps their wager. See the detailed dialog for how play will proceed.

Specific Application Behavior and Rules

See the attached UML shell diagram suggesting some of the "actors" in this game. You may add additional classes and you will be responsible for fleshing out the data and methods for each class. The 21 shell in Visio format can be downloaded here.
You may use the classes you built for the enumeration lab, but will need to make some changes to those objects.

Suit, Rank, and Card - These will be very much like the lab. The points value of the ranks will be different for this game. You will need the abbreviations to show the cards.

Deck - This class will represent a normal 52 card deck, with cards of every suit and rank. You will need to be able to simulate a normal card game where cards are dealt at random to players. There are a number of different ways to do this. Think through very carefully how you might want to implement the deal. You will also need a way to rebuild the deck after each round, since we assume that all dealt cards are returned to the deck and the deck is "reshuffled" to again provide new random cards to the players.

Hand - This class will represent a player's hand. It will contain the cards that have been dealt to that player. You should include at least a method to display the cards (keeping the hole card hidden if the hand belongs to the computer until the last round) and a method to calculate the point value of the hand. You will also need methods to add cards to the hand.

Player - This class will represent a player and will contain the player's hand, their current betting value and the current wager. Methods will include the methods to keep track of money (if a human player), tracking the current bet, adding cards to the hand, getting the points value of the hand, etc.

Game21 - This class will be the controller of the game. All input and output should be done here. This method will control the turns and will display hands and winning information. See the detailed dialog for how play will proceed.

Driver - You will need some kind of driver to start the action. This is not shown on the diagram.

Input

Input from the user will include the amount to bet (which may not exceed the money they have available to them) and whether or not to take a card or hold. The user will also indicate whether or not they want to play again.

Errors

Error checking will include:

When a player is prompted to make a wager, the amount must be a positive non-zero amount and must be less than or equal to the money that they have in their "account". All players begin with $20.00. If the player enters anything other than a number, you must display the error message "You entered " followed by the erroneous value followed by ". This is not a valid number." Reprompt for the correct value. If a player enters an amount that is greater than what they have in their account, you must display the error message, "Your wager exceeds your your funds. Enter an amount less than or equal to " followed by the amount in their account.
When a player is prompted to take a card, the only valid response is y or n (either case). If they enter anything other than a y or an n you must display the message "Your entry " followed by the bad value followed by " is not a correct response." On the next line, reprompt for the answer.
When a player is prompted to continue the game (Play again), the only valid response is y or n (either case). If they enter anything other than a y or an n you must display the message "Your entry " followed by the bad value followed by " is not a correct response." On the next line, reprompt for the answer.

Output

See the detailed dialog below that you find here: Dialog.txt.

Additional Program Requirements

You may elect to use try/catch processing for error checking in this application.
You must have the basic design as described in the UML shell. You may add additional classes that you find necessary.
Your program must conform to the Style Guide for this class.

Hints

In solving problems, the first step is always to understand the problem. Be sure that you read this document carefully before you start designing your classes. Think about the interactions of the different "actors" (classes) before you begin coding. Determine exactly which class will perform which functions and which classes should "see" which other classes.
Start with your lowest level classes and test those thoroughly. Be sure to test your Deck class so that you know that you are getting appropriate dealing behavior.
As you are designing...focus on one class at a time and one method at a time. That makes the job much more manageable.
As you are implementing...focus on one class at a time and one method at a time. Test each method as you build it.
Start early. And test well. There will be no submit testing done for this PA.

Things to watch out for

Do not "cascade" your method calls. For example, if you have a method (A) that calls a method (B), B should conclude returning control back to A. B should not explicitly call A.
Do not include attributes that do not describe the state of that particular object. Use local variables and parameter passing. You should include a Scanner as one of the attributes (instance variables) of the Game21 class and only instantiate it one time.

Honor Code

This work must conform to the JMU Honor Code and the specific requirements of this class. NO help may be provided by another student to another student except as done as part of an in-class exercise. Authorized help is limited to your textbook, the TA’s for any CS139 or CS239 section, and the professor for your section. See collaboration policy.

Grading

This assignment will be graded based on 100 points.
The design document (fleshed out UML diagrams) are worth 20 points.
Program behavior in conformance with the specified requirements is worth 60 points.
Conformance to the class style guide is worth 20 points.