Class Diagram Example - Tic Tac Toe

Object Oriented Software Development

Home

Announcements

Schedule

Homework

Lecture Notes

Projects

Miscellaneous

We had a very good discussion in class this morning (22SE99) about the class diagram for the game of tic tac toe. The major concerns seemed to be:
  • The appropriate notation for the link between the player and the grid (is it a dependency, or a two way relationship?)
  • How do we define "player"? Does a player live outside of the game?
I've included both my class diagram (Figure 1) and a class diagram using Professor Chesney's style (Figure 2) in this document, and I'll try to talk through some of these important issues.

First of all, let's make it clear that we are modeling a "real" game of tic tac toe that two "real" people might play, not a computer implementation of the game. We all seemed to agree that a game of tic tac toe was made up of two players and a grid containing 9 symbols, and that each symbol could be either X,O, or nothing at all. We also agreed that each player has a symbol assigned to him or her.

The first big issue came when we were dicussing whether the player was dependent on the grid (because they make their move based on the current state of the game) or whether the grid was dependent on the player (because the players moves effect the state of the game). Remember that, in a dependency, the dependee shouldn't have to know anything about the dependent. It seems intuitive to say that the grid knows nothing about the players, but this is where our problems started.

My Approach:


Figure 1: My class diagram

We could argue all day long about whether this is a one- directional relationship (dependency) or whether it is a two-directional relationship (association). When I was solving it (see Figure 1), I took a step back and thought about what information I was trying to convey with the graph. I think the most appropriate (because it is most helpful to a 3rd party viewer) solution is to create an association and to give that association an appropriate name; I chose "populates". Now there is no confusion as to the roles of the player and grid classes.

As for the Player class. There was a concern about whether a player exists outside the game (in other words, should the association between the game and the player be an aggregation or a composition). I think that the best way to model this is to have a player class that only exists within a game, which has a more general "Person" class (which exists outside the game) as a member. My primary logic for this involves the symbol member of the player class. It doesn't make sense for a class that exists outside of a game to have a tic tac toe symbol associated with it. It does, however, make sense to have the player class tied in some way to the outside world.

Professor Chesney's Approach:


Figure 2: Professor Chesney's style class diagram

Professor Chesney takes a very different approach to this problem. He thinks that simplicity and readablity is much more valuable than syntax. In his model, the person exists outside of the game (notice the aggregation is NOT a composition), and that person has some game specific attributes. Professor Chesney says that this is the right way to diagram it because we are not just looking at a general person, but at a person in the context of the game.

You'll also notice that his diagram does not include an enumeration class for the Symbol. Adding this class might add unnecessary complexity to our diagram. This changes our Grid class to a Grid location class (so that we can still illustrate the 1 to 9 multiplicity), and each Grid Location has a Symbol attribute with "empty" as the default value. Professor Chesney thinks that a better place to enumerate the possible values of the Symbol type would be in the Data Dictionary.

So which method should you use?

Both of these methods are technically correct, and they both have some advantages and disadvantages. I think that the first class diagram gives the audience more information about the relationship with a player and the outside world. There is, however, one major problem with this method. I probably shouldn't call my class "Player", because the word implies that there exists an is-a relationship with the "Person" class. In other words, you would like to be able to say that a player is a person. In my model, my player class is not just a person. It is a collection of game pieces, including a person and a symbol. This is a delicate distinction, and you should make sure you understand this difference.

Professor Chesney's method helps avoid this problem by simply associating the person with the tic tac toe game. Perhaps there is no need for an extra "player" class. Ultimately the decision is up to you, the designer. As for the homeworks for this class, you should draw your diagrams the way that you feel presents the most useful information, and you should be able to justify all of your decisions so that we know what you're thinking.

I hope that this clears up some of the issues from class. Please email me if there are any more concerns.

For problems or questions regarding this web page contact eecs486@umich.edu.