You are on page 1of 22


SEIS 635 Group Project

Chris Hansohn - Amir Muhawesh

Topic Description
Blackjack has been chosen as the program of choice for our semester project for several
reasons. Blackjack is readily represented by domain objects such as card, deck, etc while
also having clear relationships between objects (hand holds cards etc). Furthermore,
Blackjack has clear and distinct rules and that can be translated directly into code without any
ambiguity, the rules are concise and clear and do not allow for misinterpretation. This allows us
to create the program without the need for a domain expert, as it would with something like
accounting or tax software. Although this may seem like a fairly obvious factor, it is one that is
important not to overlook.
Blackjack also presents itself as a program that can easily be broken down into easily
manageable iterations, which still maintaining its integrity if all of the iterations are not reached.
For example, in Blackjack, we can breakdown the iterations as follows:

Basic interaction and domain objects

Expanded rules
Adding betting and a bank
Multiple players
Adding a GUI
With these iterations, we would technically be able to stop after the second iteration and
still have a program which follows the basic rules of the game. If we decide to shrink the scope,
add or change members of the group, or pick back up on the project in the future, we will have
clear and concise milestones to work with.

Breakdown and Requirements:

The goal of Blackjack is to get a hand of cards whose value is greater than the dealers
hand without exceeding 21. Each card has a value from 1 to 11, and the ace is worth 1 or 11
depending on which gives you a better value. Number cards are worth their number value, and
all picture cards are worth 10. (A cards suit has no effect on the cards value)
All players must place their bets before any dealing begins, with a cap, such as 50 or
100 dollars placed on each bet, per game.
Once all bets have been placed, the dealer deals the cards. He starts with the first
player, and deals a card up to each player, finishing with himself. The process is repeated, but
the dealer's card is dealt face down, this is the hole card. Dealing is complete when the dealer
has dealt each player two cards.
Actual play and vary depending on what the dealers card is. If the dealers facing up
card is worth 10 (ten count) or is an ace (eleven), the dealer is required to check his hole card.
If the hole card gives him a total of 21 play automatically ends and the game moves to
settlement. If the hole card does not give him 21, gameplay moves on as normal. If the dealers
up card is not a 10-count or an ace, play automatically moves to the first player. If the player has
a blackjack, play skips to the next player. If the player doesn't have 21, the player has two
choices: to hit or to stand:


If the player isnt happy with his hand, he can draw another card, which is known as a
hit. The player can keep hitting until he goes over 21 (busts) or stands (stops needing cards).
If the player is happy with his hand, he can choose to stand, and get no more cards.
After the player busts or stands, gameplay moves on to the next player. This process repeats
itself until each player has played. After each player plays, the dealer plays his own hand. The
dealer usually has rules about when to hit and when to stand. This is so the casino doesnt have
to worry about the dealer taking a risk and losing themselves money. The average choice the
casino makes is if its less than 15 or 16 to hit and if its greater than to stand. These rules are
based on statistics of when hitting will cause the dealer to bust. When the dealer completes his
turn, the game moves into settlement where scoring and payout occur.

After the dealer finishes his turn or gets a blackjack, play moves onto settlement. During
settlement, each player who busted loses what he betted. Each player with a hand less
than the dealers hand is considered as losing, and each player with a hand better than the
dealer wins his bet, and each player with a count equal to the dealers has a standoff and no
payout is made. Bets are paid out evenly among the players. If a player has a Blackjack and the
dealer doesnt, the player is paid at 3:2 odds. For example, if the player bet 50 dollars he is paid
75 dollars.


The Deck: Blackjack is played with four 52-card decks which are combined into one large deck.

Players: Blackjack can contain up to seven players.

Doubling Down: After receiving his two cards, players can choose to double down, by doing
this, he doubles his bet, receives another card, ending his turn.

When the dealers face up card is an ace, the player can place an insurance bet. The
insurance bet is equal to half of the original bet. If the dealers hole card gives the dealer a
blackjack, the player breaks even. If the dealers hole card does not give the dealer blackjack,
the player loses his insurance.

Splitting pairs:
A player has a pair if the first two cards dealt have the same value. If the player is dealt
a pair, he can split the hand into two new hands. If the player splits the pair, the dealer deals
each new hand another card, and the player must place an equal bet on the new hand. A player
can split any pair that results from another split (except for a pair of aces). A 21 resulting from a
split is not treated as a blackjack. After splitting, the hands treated as a normal hand would be.

There will be two actors in this system, the Dealer and the Player. The Player is the
primary actor in our system.


Use Cases:

Fully Dressed Use cases:

Use Case Name: Deal Cards
Starting with the first player, the dealer deals a card face up to each player ending with himself.
The dealer then repeats the process, but deals his own card face down. Dealing finishes and
play continues when the dealer has dealt every player, including himself, two cards.
Primary Actor: Dealer
Main Success Scenario:
1. Dealer deals one card face up to every player including himself.
2. Dealer deals a second card face up to all non-dealer players.
3. Dealer deals a card face down to himself.
A new game has already started
Post conditions:
All players and the dealer have been dealt a hand with two cards
The turn of the first player who does not have blackjack starts
Play continues for each player who does not have blackjack
3A. Alternative Flow: Dealer has blackjack
If the dealer has a natural 21 or blackjack, the game ends. The
Players do not get to take a turn

Use Case Name: Player hits

The player decides he is not happy with his hand, the player has not busted, and decides to hit
again. If the player doesnt bust, he can either hit again or stand. If the player ends up busting,
play moves to the next player.
Primary Actor: Player
Main Success Scenario:
1. Player decides he is not satisfied with his hand.
2. The player requests another card from the dealer.
3. The player can decide to hit again, or stand if his hand totals less than or
equal to 21.

Players hand is valued at less than or equal to 21

Player doesnt have blackjack
Dealer doesnt have blackjack
Post conditions:
A new card is added to the players hand
Alternative Flow 3A: Player busts:
New card causes players hand to exceed 21. Player busts (loses). Next
players/dealers turn begins.
Alternative Flow 3A - B The players hand is greater than 21, but player has an ace
The new card causes player to bust, but the player has an ace. The value of the ace changes
from eleven to one, which bringing the players hand to less than or equal to 21. The player can
decide to hit again or stand.

Use Case Name: Player stands

The player is happy with the hand he is dealt and stands.

Primary Actor: Player
Main Success Scenario:
Player stands:
The player is happy with the hand he is dealt and stands.

Player has a hand whose value is less than or equal to 21

Player doesnt have blackjack
Dealer doesnt have blackjack
Post conditions:
Players turn is complete

Use Case Name: Dealer Hits

The dealer must hit if his hands total is less than 17 (as decided as a business rule not a rule of
the game). If the dealer does not bust after the hit and his hands total is still less than 17, he
must hit again. The dealer must stand on any total greater than or equal to 17. When the dealer
busts or stands play terminates.
Primary Actor: Dealer
Main Success Scenario:
1. The dealer hits if his hand is less than 17
2. New card added to dealers hand
3. If the total is less than 17, dealer must hit again
Dealer has a hand whose total is less than 17
There has to be a player currently standing
Post conditions:
New card in dealers hand
Play ends
Alternative Flow: 3A Dealer busts:
New card causes dealers hand to be greater than 21. Dealer busts.
Alternative Flow: 3A Dealer stands:
New card causes dealers hand to be greater than or equal to 17. Dealer stands.

Alternative Flow: 3A Dealer has ace, stands

The new card causes the dealers hand to be greater than or equal to 21, but includes an
ace. The value of the ace changes from 11 to 1 bringing the dealers total to 17;
dealer stands.

Alternative Flow: 3A Dealer has ace, hits

New card causes dealers hand to be greater than or equal to 21, but includes an
ace. The value of the ace changes from 11 to 1 bringing the dealers total to less
than 17; dealer hits.

Use Case Name: Dealer Stands

The dealers hand is greater than or equal to 17, and stands.

Primary Actor: Dealer
Main Success Scenario:
1. The dealers hand is greater than or equal to 17, and stands.
Dealers hand greater than or equal to 17
Must be a player in the standing state
Post conditions:
Play is complete
Alternative Flow: 1A No standing players
If there are no standing players, the dealer will automatically stand

Domain Model Diagram

Our domain diagram turned out to be fairly straightforward, as the objects in the program are
fairly easily represented by classes in our diagram. We will have a deck shuffler, which shuffles
four decks of cards upon request of the dealer. The dealer then calls two cards from the deck
pile, which pulls two cards from the deck. The dealer will deal a hand to himself and the player,
then proceed to play against the player, while checking the rules against the Blackjack rules list.
Play terminates when all conditions are met.

Domain Model:

System Sequence Diagram - High Level Game Flow

Design Diagram Initial Class Diagram

Design Diagram Final Class Diagram

Design Diagram Object Interaction Diagram

Team Organization:
Whenever more than one mind is at work on a project, collaboration and communication
are crucial for everything to stay on track, from inception to implementation. From inception, our
primary method of communication was email and text. Most of the development for our project
happened outside of class time and was a result of pre-agreed milestones. This proved to be
necessary, as our schedules tended to overlap and commute times to middle ground made
meeting in person regularly unrealistic.
All development was done using Eclipse pulling from a Google Code repository using
Mercurial. Eclipse was chosen due to the familiarity of both team members with the IDE. Google
code was chosen for several reasons:


Both team members are regular Google users

Support for both Mercurial and Git

Simple and scalable as the project grows

Google Reliability

Using version control for the project was a no-brainer, it is difficult to imagine what large
scale development was like before cloud storage and repositories existed. Comparing and
merging code seemed like it would have been a nightmare. One issue that was raised during
development with Google Code is its awkward handling of non-code artifacts such as
documents and images. Although it allows for uploading of these items, it seems to only allow
users to download them as raw data, and there is no on-line viewer for these items, it acts as a
repository only, which is nice, but forced us to use Google Drive in addition Google Code.
Mercurial was chosen as the version control system of choice for similar reasons as
Eclipse was chosen familiarity of the team members with the system. Although it is worth
noting a project of this scale, which simply involved pulling, pushing and committing code
offered no real differences between Git and Mercurial on this level.
An area that proved to be fairly problematic was the use of Magic Draw. For our code,
we had a remote repository to share, for our project paper and presentation, we had Google
Docs which kept us in sync, with Magic Draw, we had no such convenience however. This
problem was compounded by our reliance on Magic Draw to agree on designs for our program
as well as generating the initial code. We found ourselves having to append the date onto the

filename in order to keep track of what the most recent revision of the diagrams was. Still, with
this naming convention, there was no promise that a team member would not modify and save a
file, forgetting to rename it or send the update to the other team member, causing an unwanted
and unknown branch to occur.
Conclusion and Hindsight:
Although this project was similar in description to the final project of 610 (create a
working program), there was little similarity beyond that. This project focused and emphasized
the analysis and design of the program as crucial to the development process, highlighted it as
not only helpful but compulsory. A majority of our time was spent coming up with and agreeing
upon the domain model, class diagram, and use cases before any line of code was written.
When the time came to begin writing code, the transition seemed natural and appropriate, as we
both had a solid idea of how program was going to flow and fit together. The project in 610
involved simply picking an idea and jumping head first into the coding without requiring any kind
of analysis or design, resulting in a kind of code and pray style of programming. This project
connected the dots between simply knowing syntax and understanding how objects should
interact and being able to implement both together to come up with a functioning program.
One issue that popped up unexpectedly was scope creep and feature creep. Although
this was discussed in the Project management class, we found it difficult to keep under control.
It is extremely difficult to estimate needed to complete certain tasks with any kind of accuracy,
and overestimating doesnt seem to work. Initially, it was the project managers hope to
complete four iterations, banking on the fact that each iteration was fairly small and well
segmented from the rest of the project.

Basic interaction and domain objects

Expanded rules
Adding betting and a bank
Adding a GUI
We found that although the project was well broken up into each iteration, the initial
iteration took much longer than anticipated, causing us to fall short our initial goal of completing
all four iterations. (we completed only the first one). This was not an issue of needing to start
earlier, but needing to be able to better estimate needed for development and planning.
Conversely however, using iterations allowed us to identify the fact that we were coming up
short on time, and focus on hitting the wall of iteration one solidly instead of leaking into
iteration two and having code that was not complete. Focusing on accurate estimation of

development time would be our primary focus if we were to repeat this project.