explain how to create UML class diagram for this task. show all the steps. thanks

Computer Networking: A Top-Down Approach (7th Edition)
7th Edition
ISBN:9780133594140
Author:James Kurose, Keith Ross
Publisher:James Kurose, Keith Ross
Chapter1: Computer Networks And The Internet
Section: Chapter Questions
Problem R1RQ: What is the difference between a host and an end system? List several different types of end...
icon
Related questions
Question

 explain how to create UML class diagram for this task. show all the steps. thanks

 

Create design diagrams for a variant of the game Othello:
https://www.worldothello.org/about/about-othello/othello-rules/official-rules/english
The goal is only to include information that makes sense to put into a UML Class Diagram to help in a later
implementation. The correctness of diagrams and their completeness are significant considerations. Clear
diagrams and the inclusion of concise supplemental information to communicate design intentions will also count.
There is no implementation submission for this assignment. Focus on the design described, not the
planned implementation.
In this variant of Othello, some positions on the board will be unplayable. The starting position may vary, and the
rules for flipping pieces may be adjusted.
The program should draw the board using ASCII characters on the screen. Positional labelling along the top and
side will allow the input of movement coordinates via keyboard. Messages detailing the result of moves and
instructions for how the current player may take their turn will be output by the program at the start of every turn.
This description shows traditional Othello disks, but the actual implementation would show ASCII characters.
When a game starts a menu will be shown, with numeric options given:
1. Start a New Game
2. Load a Game
3. Quit
If a user chooses to quit, the program should close. Suppose the user Chooses to load a game. In that case, the
program should ask for a filename. After loading the game, the program would continue from where it left off. If
the user chooses to start a new game, two player names are requested, and a game will start.
When laying out the board before starting, note that some squares are unplayable. This rule does not come from
standard Othello, but keep in mind that such unplayable squares will be the same for every game in the final
implementation.
Transcribed Image Text:Create design diagrams for a variant of the game Othello: https://www.worldothello.org/about/about-othello/othello-rules/official-rules/english The goal is only to include information that makes sense to put into a UML Class Diagram to help in a later implementation. The correctness of diagrams and their completeness are significant considerations. Clear diagrams and the inclusion of concise supplemental information to communicate design intentions will also count. There is no implementation submission for this assignment. Focus on the design described, not the planned implementation. In this variant of Othello, some positions on the board will be unplayable. The starting position may vary, and the rules for flipping pieces may be adjusted. The program should draw the board using ASCII characters on the screen. Positional labelling along the top and side will allow the input of movement coordinates via keyboard. Messages detailing the result of moves and instructions for how the current player may take their turn will be output by the program at the start of every turn. This description shows traditional Othello disks, but the actual implementation would show ASCII characters. When a game starts a menu will be shown, with numeric options given: 1. Start a New Game 2. Load a Game 3. Quit If a user chooses to quit, the program should close. Suppose the user Chooses to load a game. In that case, the program should ask for a filename. After loading the game, the program would continue from where it left off. If the user chooses to start a new game, two player names are requested, and a game will start. When laying out the board before starting, note that some squares are unplayable. This rule does not come from standard Othello, but keep in mind that such unplayable squares will be the same for every game in the final implementation.
When starting a new game, the user will be offered different starting positions. They will enter a number
corresponding to one of these choices:
1. An offset starting position, the user will be subsequently asked to choose a number between 1 and 4 to
indicate one of the following options:
1) A non-standard, offset starting position. 2) A non-standard, offset starting position.
3) A non-standard, offset starting position. 4) A non-standard, offset starting position.
2. Standard Starting Positions
Whether through starting a new game or loading an existing game, the current player will be given
options to play. The options for the current player are as follows:
. A player may choose to save, concede or make a move
When a game is over, the Game should explicitly record (in variables) the winning player or if it was a tie.
An appropriate message should be displayed.
Create a UML class diagram that includes Game, Board, Position, Piece and Player. A Game should have
a Board, and a Board should have Players. The Position class should be abstract, with PlayablePosition
and UnplayablePosition inheriting from it. Position should have a pure virtual method canPlay():bool,
with the return value being true for playable positions that are empty.
Polymorphism must (and should) be used.
There is some latitude on how one could approach the design, but one would want a play() method that
loops and Board will want to store its pieces internally. Based on where the program stores information in
the resulting design, a save method should exist, as should a static load method. A makeMove method
and methods to determine whether a move converts any pieces will be needed. A method to check if
there are any valid moves left will be needed. Think about the game problem and rules and include any
additional methods, mindful of what should be public and private.
Classes should showConstructors to communicate, at a high level, how the life-cycle of the elements of
the game (or their construction) will work.
It is ok to indicate via UML Note that access/mutator methods are not shown/can be interpreted based
on fields. Use UML Notes to provide clarifications on salient decisions. Generally, if a note would be
helpful for someone trying to implement based on this design, then it is probably a good note. A note
should not describe implementation details. A note should explain how things in the diagram fit together
clearly, filling in details that are not well-communicated through simple box-line diagrams.
A UML diagram may be split into simpler diagrams, identifying stub classes via UML note indicating a
detailed version elsewhere. Splitting up a UML diagram can make a complex diagram easier to read.
Suppose two classes have a relation in one diagram. In that case, they must have the same relation in
another diagram, even if they are stubs.
Transcribed Image Text:When starting a new game, the user will be offered different starting positions. They will enter a number corresponding to one of these choices: 1. An offset starting position, the user will be subsequently asked to choose a number between 1 and 4 to indicate one of the following options: 1) A non-standard, offset starting position. 2) A non-standard, offset starting position. 3) A non-standard, offset starting position. 4) A non-standard, offset starting position. 2. Standard Starting Positions Whether through starting a new game or loading an existing game, the current player will be given options to play. The options for the current player are as follows: . A player may choose to save, concede or make a move When a game is over, the Game should explicitly record (in variables) the winning player or if it was a tie. An appropriate message should be displayed. Create a UML class diagram that includes Game, Board, Position, Piece and Player. A Game should have a Board, and a Board should have Players. The Position class should be abstract, with PlayablePosition and UnplayablePosition inheriting from it. Position should have a pure virtual method canPlay():bool, with the return value being true for playable positions that are empty. Polymorphism must (and should) be used. There is some latitude on how one could approach the design, but one would want a play() method that loops and Board will want to store its pieces internally. Based on where the program stores information in the resulting design, a save method should exist, as should a static load method. A makeMove method and methods to determine whether a move converts any pieces will be needed. A method to check if there are any valid moves left will be needed. Think about the game problem and rules and include any additional methods, mindful of what should be public and private. Classes should showConstructors to communicate, at a high level, how the life-cycle of the elements of the game (or their construction) will work. It is ok to indicate via UML Note that access/mutator methods are not shown/can be interpreted based on fields. Use UML Notes to provide clarifications on salient decisions. Generally, if a note would be helpful for someone trying to implement based on this design, then it is probably a good note. A note should not describe implementation details. A note should explain how things in the diagram fit together clearly, filling in details that are not well-communicated through simple box-line diagrams. A UML diagram may be split into simpler diagrams, identifying stub classes via UML note indicating a detailed version elsewhere. Splitting up a UML diagram can make a complex diagram easier to read. Suppose two classes have a relation in one diagram. In that case, they must have the same relation in another diagram, even if they are stubs.
Expert Solution
steps

Step by step

Solved in 3 steps

Blurred answer
Recommended textbooks for you
Computer Networking: A Top-Down Approach (7th Edi…
Computer Networking: A Top-Down Approach (7th Edi…
Computer Engineering
ISBN:
9780133594140
Author:
James Kurose, Keith Ross
Publisher:
PEARSON
Computer Organization and Design MIPS Edition, Fi…
Computer Organization and Design MIPS Edition, Fi…
Computer Engineering
ISBN:
9780124077263
Author:
David A. Patterson, John L. Hennessy
Publisher:
Elsevier Science
Network+ Guide to Networks (MindTap Course List)
Network+ Guide to Networks (MindTap Course List)
Computer Engineering
ISBN:
9781337569330
Author:
Jill West, Tamara Dean, Jean Andrews
Publisher:
Cengage Learning
Concepts of Database Management
Concepts of Database Management
Computer Engineering
ISBN:
9781337093422
Author:
Joy L. Starks, Philip J. Pratt, Mary Z. Last
Publisher:
Cengage Learning
Prelude to Programming
Prelude to Programming
Computer Engineering
ISBN:
9780133750423
Author:
VENIT, Stewart
Publisher:
Pearson Education
Sc Business Data Communications and Networking, T…
Sc Business Data Communications and Networking, T…
Computer Engineering
ISBN:
9781119368830
Author:
FITZGERALD
Publisher:
WILEY