Computer Science 223
Software Development
Homework 3Identifying Classes
UML Diagrams
Due: September 29
In this assignment, you will practice the initial stages of design, as we have been doing in class. In particular, I provide an English description of a problem (Texas Hold 'Em Poker) and you are expected to identify classes, attributes and methods of those classes, and relationships between classes that you would use to design a program that allows multiple users to play this game. As with the Monopoly example in class, you should focus your attention on identifying classes in the problem domain, not the solution domain. In particular, you can ignore things like the user interface, the file system, networking, etc.
For this assignment, you should turn in one or more class diagrams that provide an overview of the classes and their relationships to each other. Every class (except those being used as enumerated types, see below) should appear on at least one diagram. If the diagram gets cluttered, break it up into multiple diagrams, keeping the most closely-related classes together. Also, keep in mind that it is legitimate for one class to appear on multiple diagrams.
You should also turn in two sequence diagrams. One sequence diagram should show the sequence of method calls required for a player to raise a bet. The second diagram should show the sequence of method calls used to determine which player wins a hand and how that player collects the money in the pot.
Finally, you should turn in an English description of what you consider to be the interesting design decisions that you made. As we have seen in class, it is important to consider tradeoffs when doing design to leave us with a system that is maintainable and understandable. In particular, be sure to consider the following questions as they relate to specific design issues we have discussed so far in class:
The problem is to do an initial design of a program that allows multiple users to play Texas Hold 'Em Poker against other players. Remember that you should focus your efforts on the design of classes from the problem domain. This description is broken down into two parts: terminology shared by many poker games, and rules specific to Texas Hold 'Em.
Poker is played with a standard deck of 52 cards consisting of 4 suits and 13 ranks. Ranks in order from high to low are Ace, King, Queen, Jack, 10, 9, 8, 7, 6, 5, 4, 3, 2. The suits are Diamonds, Hearts, Spades, and Clubs and are unordered.
Poker games generally consist of the following activities:
What makes one poker game different from another is the details of these rules, such as how many cards are dealt, when betting occurs, etc., but there is some common terminology across all games. First, when it is a player's turn to bet, there are generally four options available (but some games may restrict when each option is available):
A betting "round" may actually result in each player betting more than once. The round ends when each player has either folded or put in the exact amount as all the other betters.
When the game ends, the player with the highest hand wins all the money that has been bet. Hands are ranked as follows, from highest to lowest:
In any case where a tie cannot be broken, the pot is split evenly among those who tied.
Here are the sequences of actions for a single hand:
You can use any software you like to draw your UML diagrams. You can even draw them by hand if you do it neatly. Using a UML editor has the distinct advantage, though, that what you create is valid UML! We have available in the lab a UML editor, called Poseidon. To use it, just enter the command Poseidon. (If that doesn't work, the following will: /usr/local/poseidonCE-3.0.1/bin/poseidon.sh) Please try this out well in advance of the due date, preferably when I am around. I know it works for me and for the jcool account, but I'm a little concerned that it might ask new users to register.
Poseidon looks similar to Eclipse in many respects. There is an explorer panel on the left and a large diagram editing error on the right. On the bottom is a panel that you need to use to enter details, like names of attributes (aka variables) and operations (aka methods), cardinalities on edges, etc. I encourage you to give it a try. You can download the free Community edition from http://www.gentleware.com/. There is extensive documentation on-line about how to use Poseidon.
The one limitation with the Community Edition of Poseidon that matters to us is that there is no support for printing. This is not so bad, though, because it does have the ability to create jpg files containing the diagrams you are creating. This is possible using the "Save Graphics As" command in the File menu.
An enumerated type is a type in which the programmer designs the set of values that make up that type. In languages without a mechanism to create enumerated types, like old versions of C and Java prior to 1.5, this is typically done by creating constants to hold each value of the type. This poker game has several places where enumerated types are the right solution. For example, the suit of a card can be any of Diamond, Club, Spade, or Heart. In Java 1.4, we could define this type as follows:
class Suit {
private final String name;
private Suit (String name) {
this.name = name;
}
public String toString() {
return name;
}
public static final Suit CLUBS = new Suit ("Clubs");
public static final Suit HEARTS = new Suit ("Hearts");
public static final Suit DIAMONDS = new Suit ("Diamonds");
public static final Suit SPADES = new Suit ("Spades");
}
Notice how the implementation above makes exactly the four values we want to be in Suit be there. No other class can create new values of this type because the constructor is private. Java 1.5 provides a more direct way of creating enumerated types to get the same effect.
Since we are not writing code with this assignment, it is not so important to know how to create an enumerated type in Java. It is important, though, to recognize when an enumerated type would be useful as in the case of a card's suit here. When you are identifying classes, it is not necessary to display these enumerated types in class diagrams. You can just use them as the types of class attributes and method parameters, much as you would use String in that way. In your English description, please tell me which types are enumerated types and what values they hold.
Identification of classes 15 points Identifying methods of a class 15 points Identifying relationships between classes 15 points Identifying attributes of classes 15 points Class diagrams 15 points Sequence diagrams 10 points Discussion of design tradeoffs 15 points
To turn in your work, please bring printed copies of your UML diagrams and your design discussion to class.