Problem Statement

We require a"Connect-Four" game to be runnable on the internet.

Description of the game

There are a number of columns (typically 6 or 7) in which pieces may be stacked some number of rows (typically 6 or 7) high.

Gravity rule: The first piece in a column goes to the bottom, the second sits on the first and so on.

There are two players, each having their own pieces, distinguished from the other player's by colour (white and black).

Players take turns, starting with white.

A player may put their piece in any column that is not already filled. The piece always fall to the lowest unfilled position in the column.

A player wins by getting four of their own pieces into a straight line either abreast (four pieces in the same row in four adjacent columns), stacked (four pieces stacked immediately one on top of the other in the same column) or diagonally (for example at r2c2, r3c3, r4c4, and r5c5). To count pieces must be the same colour (belong to the same player), be adjacent and must lie in a straight line.

The game ends (in a win) when one player manages to get 4 pieces into line as defined above, or both players run out of pieces (a draw, if neither achieves a "line").

The Problem

 To design a first cut version of the game that will let one player play against the computer. The player selects where they want their next piece to go by using a mouse. The computer will display the piece appropriately then play its own. The computer will also act as a referee in cases where the player does something illegal (like adding a piece to a column that is already full). Note: you are not required to figure out what the strategy is that the computer player should use, only how to encapsulate that strategy with one or more classes.

Available Resources

You may assume Java is available and that a class mouseBox exists that can detect a mouse click within its boundaries.

MouseBox(int x, int y, int width, int height): constructor, creates a visible, clickable box on the screen of size specified by width & height whose top lefthand corner is at (x,y)

mouseClicked(): an empty function designed to be overridden in a sub-class. This function is called whenever the mouse is clicked inside the box.

setIcon(string gifFile): the named gif file is displayed in the centre of the box as an icon.

setMessage(string msg): the message is displayed in the box and clipped against it.

setBackground(Color c): set the box's background color to c

paint(): although this has to be public beause it is called by the awt painting system, it should neither be called by you, nor over-ridden.


  1. A Charter Statement
  2. Use Cases
  3. Class Diagram showing the structure of your design worked out at the specification level (that is, show the public interface for each class).
  4. One or more collaboration or sequence diagrams to show at least a normal move

Designs will be judged based on clarity, simplicity, completeness and quality of documentation.


Charter Statement

We will design and build a Connect-4 game to be run on a single computer, played by a single human player according to the rules given in the problem statement with the computer as opponent. The computer will also act as referee, informing the human player when he/she has made an illegal move. The phase 1 game will be a six row by six column game with each player having 15 pieces.

Use Cases & Class Diagram

Identifying Candidate Classes

One simple trick to get started is to note all the unique nouns in the Charter Statement. Listing them gives us

game | computer | player | rule | problem statement | opponent | referee | move | row | column | piece

where we have immediately eliminated computer and problem statement as being too general to be part of our model.

Identifying Candidate Actors

Although only two parties are involved, the human player and the computer, there are really three roles, the human player, the computer opponent and the computer referee. However, only the player is an actor because the computer referee and the computer opponent are actually part of our program and not acting from outside of it.

Developing the Use Cases

The only real use case then is making a move—or move for short. If we were allowing users to configure the game, which we would probably do in version 2, then we would have a configure use case as well. Here is the documentation for the move use case. It was derived by imagining sitting in front of the computer and playing the game. (In a big project we might rapid prototype). Since the computer's response is automated we have included it in the move.

Developing a Class Diagram

What classes are we actually going to need? What do they do?

In procedural programming we think in terms of global control. In object oriented programming we have to let go of that perspective and think of objects as acting locally, in collaboration with nearby objects.

Procedural programs are like dictatorships or monarchies, centralized, hierarchial with control that flows from the top.

Object-oriented programs are more like modern societies characterized by diffuse control and a large number of collaborating interactions.

One of the crucial first steps is figuring out what classes we need. To do that we need to establish the CRC—Class name, Responsibility, Collaborators.

A useful way to do this is on index cards—called CRC cards. Or we can do it directly in UML. Whichever way, for each class we establish:

Class Name
It cannot be overemphasized how important it is to get names right. The more important the class, the more important this is.
A succint statement of a class's responsibility. That's singular, not plural. Ideally each class should only have one responsibility.
The classes which this class has to collaborate with. Ultimately, an object-oriented program is nothing but a network of collaborating classes working together to get the job done.


Lets try it in Rational Rose