Topics and Concepts: Group work on a relatively large project -- including definition of group and individual responsibilities and the importance of regular communication; use of state transition diagrams to model the behavior of a program system; thorough and precise definitions of component interfaces; use of electronic communication media (e-mail, phone, ftp, etc.); data driven analysis, decomposition, and design of a larger project; separate component and integration testing; incremental programming (or programming by iterative enhancement); inheritance, virtual and pure virtual functions.

Project: You are to write a simulator for the game of monopoly. The simulator should work for any number of players from 2 to 8 to be chosen by the user. You are to omit all details concerning the exchange of money, except, perhaps, for the purchase of property and payment of rent. Furthermore:

1. The actual implementation of the draw cards is optional.
2. Buying of hotels and houses is optional.
3. The decision of a player as to whether or not to purchase a property should be based solely on whether the player has enough cash on hand. Bidding to allow other players to purchase a property is optional.

Numerous issues concerning the modeling of the real objects used in the game and of the possible sequences of actions associated with a single move of a player will be discussed in class. It is now time to begin to add some meat to the bones.

I will provide you with some project milestones. We will attempt to solve this problem one step at a time. Considerable planning and a commitment to documentation and verbal and written communication will be required if you expect to complete this project in a timely manner. You will find it useful to first carefully analyze the problem specification (Monopoly Game Rules) and then work on the structural design of your simulator. Only after this has been done should you even begin to think about the C++ implementation.

Phase 1 -- Problem Analysis: (Due date to be specified later)

Your team should meet as soon as possible and begin reading through and studying the Rules of the game. I strongly urge you to actually PLAY the game as part of your analysis. Below is a list of some of the written outcomes (documentation) of your analysis effort.

1. A listing of the problem domain entities (the game board, players, properties, draw cards, etc.) that have to be manipulated when the game of monopoly is played.

2. For each entity identified in 1), a list of the attributes (characteristics) of and the operations (methods) on that entity. The operations will fit into one of two categories -- those that
   • change the state of the entity [for example, changing the state of a property from unowned (owned by the bank) to owned by a particular player].
     and those that
   • ask a question (query) about the state of an entity {for example, a query as to whether or not a property is owned, and if so, by whom?)

   The attributes and operations together will provide a static model of your system, illustrating the structure of each problem domain entity and its relationship to other entities at any given point in time. Initially, our static model will be described mostly in English, at a fairly high level of abstraction. Eventually, we will translate this more abstract model into a C++ class using the data types and operations at our disposal in the language.

3. A state transition diagram providing a dynamic model of the states and related events for one class of objects (such as the players of the game). This diagram should show all of the possible states that can be reached as a result of a player's turn as well as the events that can lead to each of these states.

   An initial list of entities and entity attributes probably can be formulated without playing the game. However, the development of the state transition diagram for an object class and the list of operations required on each entity may be pretty difficult to construct without experience in playing the game and documenting the operations and state transitions as they occur.

   Some other issues:

   • The spaces on the board all may have some attributes and operations in common. Certainly, the property spaces (railroads, utilities, and streets) have attributes in common (and share some common attributes with the non-property spaces (corner spaces, draw card spaces, etc.).

   • Ultimately, we will build a model of the board as a collection (of size 40) of spaces and build a three-level type hierarchy with space as the super type, property and non- property as the middle level subtypes of space, and several third level types: railroad, street and utility, as subtypes of property; and corner, draw card, and tax, as subtypes of non-property.

Suggestions: The entire team should work together to be sure all members understand how the board and other entities will be modeled, and how that states of the problem domain entities and the game events interact. You should also work together on the details of the entity models and the state-transition diagrams. Your focus in this phase should be almost exclusively on data and state transition modeling at a high level of abstraction. I will try to provide you with a few examples of how to format this information (without overwhelming you with additional reading).

To Be Turned In: 1) List of problem domain entities each with a detailed list of attributes and operations. These lists should be entered on the computer using either a word processor or a simple editor. 2) Complete state transition diagrams for a player. Again -- I will try to provide examples before you start putting anything on paper.

Phase 2: Simulator Design

You might consider dividing up your type models work as follows:

• one member of the team should be assigned to handle the design of the property type and its 3 subtypes;

• one member of the team should be assigned to handle the design of the non-property type and its 3 subtypes;

• one member of the team should be assigned to handle the design of the player type (or of a type to represent all k players (2<=k<=8)). [In this latter case, you might first define a type player and then another composite type perhaps called all_players, an indexed collection of base elements of type player.]

At this point, the group needs to begin to map out a description of the responsibilities of each member to the others.

The mapping of each entity model to a C++ class can now begin.

1. A model of each entity attribute should be constructed using either the built-in C++ data types, or additional user-defined data types.

2. Additional detail should be added to the description of each operation. The detail should include:
   • a brief description of the purpose of each operation;

   • a list of arguments with a brief description of the purpose of the argument along with its IN, OUT, or INOUT designation.

   You may well have just three public methods for each type, a constructor (with appropriate initialization), destructor, and an "action" operator. There may be many other functions defined, but these will be private to the class (called by the "action" function)

3. A list of possible exceptions (special situations or errors that can occur for the objects of your type) and the actions to be taken for each. You may never actually handle all of the exceptions that you note, but every exception that comes to mind should be noted.

4. A list of any assumptions that you need to make along the way. (In our case these assumptions will usually be of one or two kinds:
   • an assumption related to a decision to defer handling a certain aspect of the game, such as the shuffling and drawing of the chance and community chest cards;

   • an assumption that involves a clarification or change in the rules of the game, such as whether to do anything special when a player lands of free parking.

NOTE: Chapters 12 and 14 of the Friedman/Koffman text contain some small examples illustrating how some of the above information might be documented. It is advisable to automate these lists so that they can be updated as needed and e-mail to your group members and/or printed. All three team members should try to adopt a similar format for describing his/her types.)

To Be Turned In: Complete printouts of the documentation provided for items 1) - 4) listed above.

Phase 3 - Component Implementation and Testing:

NOTE: You should NOT try to code any class all at one time. Rather begin by coding a small "nucleus" of attributes and methods. Get these compiled and tested, and then incrementally add more attributes and methods and test these. Repeat this process until you have a complete class as described in your Phase 2 lists. You may even wish to complete Phase 4 (below) before adding additional features to your components.

To Be Turned In: Your driver programs, the code for each class implemented, and your revised lists from Phase 2.

Phase 4: Integration Testing

To Be Turned In: The output from your system integration test and your Problem Log. A "live" demonstration of your simulator in action would be appreciated.

Phase 5: System Enhancements (as time permits)

To Be Turned In: The output from your system integration test and your Problem Log. A "live" demonstration of your simulator in action would be appreciated.

Return to Previous Page