OBJECT ORIENTED DESIGN PROBLEM

You are required to produce a DESIGN of all required classes to the problem scenario below. Each class should contain its appropriate characteristics including member variables, and/or methods, etc. For each class, provide detailed description to explain its function PROBLEM DESCRIPTION Rummikub is a tile-based game for 2 to 4 players, combining elements of the card game rummy and mahjong. There are 106 tiles in the game, including 104 numbered tiles (valued 1 to 13 in four different colors, two copies of each) and two jokers. Players have 14 or 16 tiles initially and take turns putting down tiles from their racks into sets (groups or runs) of at least three, drawing a tile if they cannot play. In the Sabra version (the most common and popular), the first player to use all their tiles scores a positive score based on the total of the other players' hands, while the losers get negative scores. An important feature of the game is that players can work with the tiles that have already been played. At the beginning, place the tiles into the pouch and mix them thoroughly. Each player picks a tile; the one who selects the highest number goes first and play proceeds in a clockwise direction. Return the tiles to the pouch and mix them. Each player takes 14 tiles and places them on his rack. Playing There are two kinds of sets: A group is a set of either three or four tiles of the same number in different colors 77 77. A run is a set of three or more consecutive numbers, all in the same color 2 205. The number 1 is always played as the lowest number; it cannot follow the number 13. In order to place tiles on the table, each player must make an initial play of at least 30 points in one or more sets. These points must come from the tiles on the player's rack and not from tiles already played on the table. A tile is worth its face value. A Joker may be used for any tile and its point value is that of the tile it represents. The penalty for holding a Joker if another player wins the round is 30 points. If a player cannot enter the round or purposely chooses not to, the player must take a tile from the pouch and the turn ends. After players have made their initial plays, they can also build on other sets on the table with tiles from their racks. If a player cannot add onto the other sets, the player picks a tile from the pouch and the turn ends. A player cannot lay down a tile he has just picked; he must wait until his next turn. Play continues until one player empties his rack and calls, "Rummikub". That ends the round and players tally their points (see Scoring). When the pouch is empty, play continues until no more plays can be made; that ends the round. Requirement You are required to define classes in object-oriented fashion shown in Class Diagrams, to the above problem. Be reminded that NOT ALL of the above description are useful as some of them are only useful on actual implementation of game. You ARE NOT required to implement the game. You are simply asked to define classes with appropriate characteristics (variables / methods) for the game. To describe classes, Class Diagram in UML style should be adopted. Below examples will be shown to you for the basic illustration for class diagram. You are NOT required to show relationship between classes so that links between class diagram is not required. Suggestions to begin with Class: Player Class name Data type Visibility -private + public Member variables Player -name: string -rack: Tile* +getRack(): Tile* +getName(): string +deal(Tile*) : void trummikub(): void +add Tile(Tile) : void Method name Member methods Return type A player class (may not be completed) is shown as above. The player class defines a Player in the game: name: name of player rack: An array of Tile objects that are held by the player. getRack() - returns the Tile object pointer pointing to an array of Tile objects getName() - returns name of the player deal(Tile*) - gives out 1 or more Tile objects held by the player. I Pre-condition: 1. rack is not empty Post-condition: 1. # of Tile objects in the player's rack is deducted by n. rummikbub() - prints message "Rummikbub!" when the player's rack is empty. | Pre-condition: 1. rack is empty Post-condition: 1. a "Rummikub!" message will be shown on screen add Tile(Tile) - insert 1 Tile object to the array, rack Pre-condition: when player could not deal card(s) Post-condition: 1. a Tile object will be added to the array rack 2. The total number of Tiles in the Deal object is deducted by 1. Class: Tile Tile -value : int -colour : string +getValue(): int +getColour(): string setValue(): void +setColour(): void A Tile class represent a single Tile in Rummikub game. Each Tile object contains 2 variables: value and colour: - value: value of a Tile object ranged from 1 to 13 - colour: colour of a Tile object (red, yellow, green, and blue) getValue() - returns value of a Tile object getColour() - returns colour of a Tile object setValue() - modifies a Tile object's value setColour() modifies a Tile object's colour The above classes may not be completed and there must be more classes to be designed in order to give the full picture of the game. Be reminded that not only substantial classes like Player, Tile, and Deck; there are "intangible" classes required to be defined in order to operate the game. For instance, you may need a Menu class to provide a user-interface (UI) for players to input their choices. You may also need a "Manager" that manages the game. Marking Criteria: Completeness of classes (13) o Classes should be defined enough in order to operate Rummikub. o Proper variable(s) and/or method(s) should be defined with proper data type and return type. o Characteristics (variables / methods) should be kept in just-enough" approach. "Just-enough" means no redundant variables and methods are created. Class description (8) Each class should be accompanied with proper description. o Pre- / Post-conditions of each method should be stated as detailed as possible. UML style (2) o Class diagrams should be written in UML style. Readability (2) o Overall readability of the document. You are required to produce a DESIGN of all required classes to the problem scenario below. Each class should contain its appropriate characteristics including member variables, and/or methods, etc. For each class, provide detailed description to explain its function PROBLEM DESCRIPTION Rummikub is a tile-based game for 2 to 4 players, combining elements of the card game rummy and mahjong. There are 106 tiles in the game, including 104 numbered tiles (valued 1 to 13 in four different colors, two copies of each) and two jokers. Players have 14 or 16 tiles initially and take turns putting down tiles from their racks into sets (groups or runs) of at least three, drawing a tile if they cannot play. In the Sabra version (the most common and popular), the first player to use all their tiles scores a positive score based on the total of the other players' hands, while the losers get negative scores. An important feature of the game is that players can work with the tiles that have already been played. At the beginning, place the tiles into the pouch and mix them thoroughly. Each player picks a tile; the one who selects the highest number goes first and play proceeds in a clockwise direction. Return the tiles to the pouch and mix them. Each player takes 14 tiles and places them on his rack. Playing There are two kinds of sets: A group is a set of either three or four tiles of the same number in different colors 77 77. A run is a set of three or more consecutive numbers, all in the same color 2 205. The number 1 is always played as the lowest number; it cannot follow the number 13. In order to place tiles on the table, each player must make an initial play of at least 30 points in one or more sets. These points must come from the tiles on the player's rack and not from tiles already played on the table. A tile is worth its face value. A Joker may be used for any tile and its point value is that of the tile it represents. The penalty for holding a Joker if another player wins the round is 30 points. If a player cannot enter the round or purposely chooses not to, the player must take a tile from the pouch and the turn ends. After players have made their initial plays, they can also build on other sets on the table with tiles from their racks. If a player cannot add onto the other sets, the player picks a tile from the pouch and the turn ends. A player cannot lay down a tile he has just picked; he must wait until his next turn. Play continues until one player empties his rack and calls, "Rummikub". That ends the round and players tally their points (see Scoring). When the pouch is empty, play continues until no more plays can be made; that ends the round. Requirement You are required to define classes in object-oriented fashion shown in Class Diagrams, to the above problem. Be reminded that NOT ALL of the above description are useful as some of them are only useful on actual implementation of game. You ARE NOT required to implement the game. You are simply asked to define classes with appropriate characteristics (variables / methods) for the game. To describe classes, Class Diagram in UML style should be adopted. Below examples will be shown to you for the basic illustration for class diagram. You are NOT required to show relationship between classes so that links between class diagram is not required. Suggestions to begin with Class: Player Class name Data type Visibility -private + public Member variables Player -name: string -rack: Tile* +getRack(): Tile* +getName(): string +deal(Tile*) : void trummikub(): void +add Tile(Tile) : void Method name Member methods Return type A player class (may not be completed) is shown as above. The player class defines a Player in the game: name: name of player rack: An array of Tile objects that are held by the player. getRack() - returns the Tile object pointer pointing to an array of Tile objects getName() - returns name of the player deal(Tile*) - gives out 1 or more Tile objects held by the player. I Pre-condition: 1. rack is not empty Post-condition: 1. # of Tile objects in the player's rack is deducted by n. rummikbub() - prints message "Rummikbub!" when the player's rack is empty. | Pre-condition: 1. rack is empty Post-condition: 1. a "Rummikub!" message will be shown on screen add Tile(Tile) - insert 1 Tile object to the array, rack Pre-condition: when player could not deal card(s) Post-condition: 1. a Tile object will be added to the array rack 2. The total number of Tiles in the Deal object is deducted by 1. Class: Tile Tile -value : int -colour : string +getValue(): int +getColour(): string setValue(): void +setColour(): void A Tile class represent a single Tile in Rummikub game. Each Tile object contains 2 variables: value and colour: - value: value of a Tile object ranged from 1 to 13 - colour: colour of a Tile object (red, yellow, green, and blue) getValue() - returns value of a Tile object getColour() - returns colour of a Tile object setValue() - modifies a Tile object's value setColour() modifies a Tile object's colour The above classes may not be completed and there must be more classes to be designed in order to give the full picture of the game. Be reminded that not only substantial classes like Player, Tile, and Deck; there are "intangible" classes required to be defined in order to operate the game. For instance, you may need a Menu class to provide a user-interface (UI) for players to input their choices. You may also need a "Manager" that manages the game. Marking Criteria: Completeness of classes (13) o Classes should be defined enough in order to operate Rummikub. o Proper variable(s) and/or method(s) should be defined with proper data type and return type. o Characteristics (variables / methods) should be kept in just-enough" approach. "Just-enough" means no redundant variables and methods are created. Class description (8) Each class should be accompanied with proper description. o Pre- / Post-conditions of each method should be stated as detailed as possible. UML style (2) o Class diagrams should be written in UML style. Readability (2) o Overall readability of the document