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:

The game of Go is played on a 19X19 grid of lines.

One player has a pile of white stones and the other player has a pile of black stones.

The players take turns putting stones where the lines intersect; the white player goes first.

Every stone has at most four neighbors, one at each of the adjacent intersections.

Stones on the edge of the board can have only three neighbors. Stones at the corners can have only two.

A stone is alive if:

it is adjacent to an empty intersection

it is adjacent to a live stone of the same color.

Dead stones are removed from the board and players are not allowed to put a stone in that space on their next turn.

An empty intersection is unclaimed if it is adjacent to stones of both colors or adjacent to an unclaimed intersection.

An empty intersection is claimed by a color if it is not unclaimed and is adjacent to a stone of that color, or is adjacent to an empty intersection claimed by that color.

The game ends when both players agree it is over.

The score for each player is the total number of claimed spaces for his color minus the number of his stones that died.

The winning player has the highest score.
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 controlinterface 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:
Wormholes
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.
"Game"
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 notalive stones are killed (occupied spaces migrate to empty)

increment players' deadstones 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"
"Player"
State Model for "Player":
State 1: Waiting for Turn
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 (selfgenerate 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 objectnode (Intersection) instead of drawing 2 separate boxes with 4 dataflows, for the individual attributes: