Electronic Poker System

Context

This project was completed as the only assigned work for COMP 3004, Object-Oriented Software Engineering. It was a semester long project done in teams of four.

The following statement of context was provided by the course instructor.

Juan Pablo Enterprises owns several charity casinos. These casinos provide table games, slot machines, and a series of fine restaurants. In order to keep up with the increase in demand for Texas Hold’em Poker, Juan Pablo Enterprises wishes to convert their existing table based play to an electronic version. Motivated by the goals of this new electronic version, your team must devise an electronic version of Texas Hold’em Poker. The electronic version will support a client/server based model supporting up to seven (7) concurrent players. Each player will interact with the poker game via the use of a dedicated handheld device.

Documentation

Approximately half of the project grade was attributed to documentation. I played a major role in the writing of the documentation, and our document has been used in subsequent classes as a model for those students to follow. The document contains the usual requirements analysis and use cases. It does not include structural or behavioral diagrams of any kind because the code's models (see below) capture this already.

The document is available to view in PDF format.

Code

This project is somewhat unique in that it was developed by creating models rather than simply coded in the traditional way. Models in Rational Rose RT, augmented with C++ code, generate real C++ code that can be compiled and run as usual. The advantage of developing a project in this manner is that there is no chance for documentation and actual code to be become out of synch since the models themselves act as both. The disadvantage is that you can really only do so much with models, and you will always have to augment them with real code since on their own they do little or nothing.

The main components of the poker system, namely the player queue and server containing poker tables and game logic, were modeled in Rose RT. The GUI front end, representing the hand held devices mentioned in the context statement, was created in Java.

In addition to the documentation, I was in charge of modeling the poker logic. I worked with fellow team mate Elan in this regard (he knew the rules of poker better than I did, so he filled in some of the logic functions).

In the following image, we see a screenshot of the Rose RT state model for the main poker logic unit. The actual game logic was created as a module separate from the rest of the card table so that it could be swapped out with a different card game (such as blackjack). To accommodate this potential change, generic messages were passed between the logic and table units that would work for any card game.

Notice how easy it is to follow the flow of the poker game even without knowing Rose RT syntax itself. Some states probably could have been compressed into one encompassing state, but then decisions would have had to been made inside that new state to determine what to do next. That, of course, defeats the purpose of modeling a state machine in the first place.

The next screenshot shows the sub-state machine for the start_game state. Notice that the game won't start until the minimum players have joined (indicated in the enough_players conditional). When the game has been restarted, the sub-state exits and the small_blind state is taken next.

The round_of_betting state is another major hub in the logic unit. Its sub-state machine is shown below.