Game of Go

This example shows the use of the DFD in a complete model. The initial specification came from a usenet post by Robert Martin on comp.object in October 1998:

I had to change the rules for a square being claimed: I didn't like the fact that a space can be claimed by both players. So in that case, I decided that neither player should claim it. This doesn't effect the relative scores of the players. The change simplies the model a little.

I originally modelled it as a single domain; but I split it into 2 after realising that the description of the grid was not relevant to the model. So my model just contains spaces and neighbours. I'll concentrate on the main application domain first.

The Application Domain (Game of Go)

The control-interface to the game of go is:

Input Wormholes

Start Game

Used to request the start of a new game.

Place Stone

Places a stone of a specified color in a specified space.

End Game

Used when the players agree to end the game.

Output Wormholes

Request Move

Requests a move from a specified player

Move was Invalid

Informs that the move was invalid; implicity requests another attempt.

Game Complete

Notifies that the game is over (a result of an End Game request).

Domain Level Diagrams

The Object Information Model

The M1 DFD

This is used to calculate the scores:

The M2 DFD

This is used to work out if a stone is alive:


There are 3 input wormholes, each requiring an SDFD. They are all very trivial:

Start Game

Place Stone

End Game

Active Objects

There are 2 active objects in the model: "Game" which models the sequencing of turns (and also kills stones between turns) and "Player", which models the turn.


The STD of "Game" is:

State 1: Ready for New Game

  • No current player
  • (wormhole) game complete

State 2: Starting Game

  • all occupied spaces become empty
  • all recently killed spaces become available
  • (event) current player is "white"

State 3: Game in Progrss

  • all not-alive stones are killed (occupied spaces migrate to empty)
  • increment players' dead-stones count accordingly
  • previous empty spaces killed by current player are now available
  • event to next player that its their turn

State 4: Ending Game

  • (event) cancel current turn

ADFD for "Game" state 1. "Ready for New Game"

ADFD for "Game" state 2. "Starting Game"

ADFD for "Game" state 3. "Game In Progress"

ADFD for "Game" state 4. "Ending Game"


State Model for "Player":

State 1: Waiting for Turn

  • (event) turn is complete

State 2: Requesting Move

  • this player is current player
  • (wormhole) request the move

State 3: Waiting for Valid Move

  • if move is to occupied space then error (wormhole)
  • if move is to recently killed space then error (wormhole)
  • otherwise migrate the selected empty space to be occupied
  • and signal that turn is complete (self-generate event)

ADFD for "Player" state 1. "Waiting for Turn"

ADFD for "Player" state 2. "Requesting Move"

ADFD for "Player" state 3. "Waiting for Valid Move"

The Board domain

This domain consists of a set of mathematically linked passive objects. Its purpose is to define the structure of the board on which the game of go is played.

The only other diagram required to completely describe this domain is the DFD. Note that I have used the notational convenience of labelling attributes on the output of an object-node (Intersection) instead of drawing 2 separate boxes with 4 dataflows, for the individual attributes:

© Dave Whipp, Nov 1998