OXO Game
This project is about how to computerise a game of noughts and crosses or tic tac toe as the Americans call it.
As with the medical case study we make a choice of which UML modelling techniques are best for us in this project. Indeed one of the modelling techniques is not a UML one at all: it's CRC cards. You'll remember a way of NOT (yes not) using CRC cards is by creating a trial class diagram, with duties assigned to the various classes and then having a look at how objects that belong to these classes will collaborate to fulfil the requirements set down in the scenarios of the use case model. To see how the objects collaborate, we draw interaction diagrams (such as sequence or collaboration diagrams), about one for each scenario. If the interaction diagrams look to be a mess with too many classes having too much to do and some having almost nothing to do except serve as data holders, then we go back to our class model and revise it and go through the whole process again. Soon we'll be submerged in a mountain of crumpled up paper as attempt after attempt may fail.
Solution: CRC cards, this allows us to do mentally, with the help of these 6 by 4 inch index cards what has been just described above. We tentatively assign responsibilities to classes writing these responsibilities on to the cards in pencil. We wave the cards around in the air as we think about how objects of these classes will send messages to each other to collectively fulfil user requirements. By using pencil erasers we may do some reassigning of responsibilities among the classes.
CRC cards:
We'll see eventually that a selection of the cards below get to be classes (the black italicised ones, although it's kind of jumping the gun at this stage to mention this) and that the responsibilities we gave these classes are reflected, more or less, in the messages that are sent from object to object in the collaboration diagram below. (Each object is an instance of one of the classes.)
Actually initially we start off with the following set of classes:
Player, Current Position, OXOToken, OXOMove and OXOGame,
and end up with
OXOToken, OXOMove, OXOGame, Board and Square.
-----------------------------------------------------------------------
Player
Responsibilities
Collaborators
Maintain any required user data
Identify a player
?
Provide a visual symbol for the player
-----------------------------------------------------------------------
Current Position ( gets dropped in favour of Board and
Square)
Responsibilities
Collaborators
Maintain data seen by user;
position; whose turn it is;
?
eventually who is the winner.
Accept a user move and package
it for validation.
-----------------------------------------------------------------------
OXOToken
Responsibilities
Collaborators
Represent a token of the game.
Maintain the position of the token?
?
[Or is this CurrentPosition's job]
Provide a visual symbol for the token.
-----------------------------------------------------------------------
OXOMove
Responsibilities
Collaborators
Encapsulate what changes in
one player's turn.
?
Know how to confirm itself.
-----------------------------------------------------------------------
OXOGame
Responsibilities
Collaborators
Understand the rules of the game:
validate moves, determine winner
?
retain any information about past.
moves.
-----------------------------------------------------------------------
Board (introduced later)
Responsibilities
Collaborators
Maintain data seen by user;
Square
position; whose turn it is;
eventually who is the winner.
Accept a user move and package
it for validation.
-----------------------------------------------------------------------
Square (introduced later)
Responsibilities
Collaborators
Maintain data pertaining to a
Token
single square of the board: where
it is; whether it contains a token,
and if so what kind. Say whether a
point falls inside the Square.
-----------------------------------------------------------------------
Having done so much preparation using CRC cards, maybe we'll get away with only one trial version of an interaction diagram. Here we go:
Collaboration Diagram for the scenario involving an X move in noughts and crosses. (usually we've used sequence diagrams as our preferred version of interaction diagrams):
We could possibly draw separate collaboration diagrams for some other scenarios:
1. legal move, not finishing the game, by O
2. a winning X move
3. an illegal O move, in which O tries to put an O on top of an X instead of an
empty square.
Anyway, I've been digressing , so back to the main theme:
Note the nested decimalised numbering system in the diagram above. Another way, although unofficial, of doing the numbering would be straightforward numbers, 1, 2, 3, 4, 5, 6, rather than 1, 2, 3, 4, 4.1, 4.2. (Recall, incidentally, that if we'd drawn this diagram as a sequence diagram [a diagram type that with which you're much more familiar] we'd have no numbers because the time sequence of messaging is discovered just by reading from top to bottom of the page!)
Here's an explanation of the collaboration diagram above:
The human player interacts with a screen representation of the noughts and crosses board, controlled by the Board. The player clicks somewhere on the board, which causes (by standard Java mechanisms) a message to be sent to the Board, with information about where the click happened. The Board, with the help of its Squares, works out from the co-ordinates which Square of the Board has been clicked in. The Board knows that it is Player X's turn, so the meaning of the click is that X wishes to place a token on the square. It creates a new OXOMove object which knows which Square and which Player are concerned, and passes the OXOMove to OXOGame for validation. OXOGame checks that there is not yet any OXOToken on the Square. There isn't, so this is a valid move. OXOGame must then check whether this moves finishes the game. It doesn't. OCOGame's reply to the validate message says that the move is OK. Board asks that OXOMove to update the position it displays to the user - so that OXOMove creates a new X OXOToken on the Square that it refers to, forgets the OXOMove object which is no longer needed (so it will be garbage collected), records that the next move is to be made by O, and waits for the next click, which will represent O's move.
And the corresponding class diagram that shows the classes that the objects in the collaboration diagram above are instances of:
Class Diagram:
A note about the solid diamond: The solid diamond represents composition, a specific sort of association. If the object at the "one" end dies, then the objects at the "many" end die too! Thus the board is composed of its squares. Similarly an aircraft is composed of its parts, so if the aircraft dies its parts die too. (If they're recycled, then they're participating in a spare-parts warehousing system.) Draw a diagram to show the relationship between a software class Aircraft instance and its Parts instances.
State Diagram for the current position class:
Discussion Questions:
1. Are there any other modelling techniques, UML or
otherwise, that you would like to see as an aid to describing the system?
2. Is it worth drawing a state diagram for any of the other classes?
3. Do you think that it would make economic sense to develop a computerised
version of noughts and crosses, or any other board game for that matter.
After all what's wrong with the traditional way of playing these games?
Discuss.