Design and Implementation of a Simple Game in Java

The assignment revolves around developing a straightforward gaming application comprising several key classes such as ComputerPlayer (an abstract base class), Get15GUI, Get15Model, NaivePlayer, and SmartPlayer. These classes interact cohesively as depicted in the BlueJ-generated class diagram. Both Naïve and Smart players extend from the abstract ComputerPlayer class, implementing unique strategies for gameplay. The design emphasizes a straightforward inheritance structure that could be refined to minimize code duplication by centralizing common functionalities in the parent class. Testing is performed exhaustively using both GUI tests and unit tests with Junit, focusing on specific scenarios like game resetting post-rounds, ensuring no residual bugs remain. This project not only enhances software development skills but also emphasizes strategic problem-solving from design to debugging phases.

Design
This project entails the development of a simple game. The developed program has six main
classes, namely;
 ComputerPlayer: This is an abstract class that models a computer player. The Naïve and
Smart computer players extends this class and provides implementation to the abstract
method “move()” defined in this class.
 Get15GUI: This class creates the graphical user interface for this game. The class uses a
null layout to position various components; with each component
 Get15Model: the model class contains all data and processing logic for the game.
 NaivePlayer: Naïve computer play contains an implementation of the move method
defined in the abstract class. For the naïve player, a move is generated randomly without
any consideration for the appropriateness of the move.
 SmartPlayer: the smart computer player class implements the move method and adds
additional features that allows the play make informed and sometimes aggressive moves
to ensure that the computer wins or forces a draw.
The classes are generally lined to one another as shown in the class diagram below, which is generated
from BlueJ IDE.
As seen from the class diagram, both the smart and naïve players inherit the Computer Player and
provides implementations for all the abstract methods.

Testing
Testing the application focused on classes that had some logical computations. As such, the GUI
class was not tested by use of Junit tests, rather it was tested through running of the application.
Testing the application commenced after completion of coding. Initial tests were on the GUI to
confirm its proper working. This was followed by intensive testing by use of Junit tests.
Testing Strategy
A black box testing approach was applied in the testing of the application. The focus was on
testing the proper working of the various methods developed in the main classes of the
application, without exploring the inner working of the methods.
GUI Testing
The graphical user interface was tested manually, with the aim of identifying if it conformed to
the expected levels of operations. Each and every button on the GUI was tested under different
conditions. The tests particularly focused on identifying if the GUI could process button clicks,
whether a new game could be stated at any given moment, whether a user could exit the game
and whether buttons selected by computer player were automatically disabled to prevent errors
and double selection.
Fig 1.0 GUI Testing; selecting starting player

Fig 2.0 GUI TESTING; playing against a Naïve Computer Player. Confirmation that selected
buttons are automatically disabled to minimize chances of error.
Fig 3.0 GUI response after clicking the New Game button. Confirmation that the game can be
restarted at any given time; the game requests the user to select the starting play and enables all
the buttons that had been disabled.
Unit Testing
After successfully testing the GUI manually, the next step was to test the inner working of the
application by use of Junit tests. The classes tested through this approach was the Get15Model.
The choice of these classes for unit testing was motivated by the fact that the classes contained
methods with logical computations. Various methods were tested to ascertain their proper
working under different conditions and with different data sets.
Test ID: J01
Description: This test unit tests the generate board method. This board simulates an internally
held board similar to that used in a Tic Tac Toe game. The board helps ease the process of
making smart moves by a smart computer player. The test seeks to identify if the method
generates a board as expected.
Pre-Condition: Initialize class Get15Model to allow testing of the method
Test Data: A 3x3 board with every index in the array being set with an empty string. The empty
positions mean the value at that position has not been taken yet.
Expected Results: we expect that array holding the board to be identical to the array passed by
the method getBoard of the Get15Model class.

Results: Passed: The test was successful.
Test ID: J02
Description: Test of isFree method, of class Get15Model
Pre-Condition: Initialize class Get15Model to allow testing of the method
Test Data:
 A 3x3 board with every index in the array being set with an empty string.
 0: An index to test whether the value at that index of the board is taken or available.
Expected Results: value should be available since playing is just stating and no value has been
taken yet.
Results: Passed: The test was successful.
Test ID: J03
Description: Test of isWinner method, of class Get15Model.
Pre-Condition: Initialize class Get15Model to allow testing of the method
Test Data:
 A 3x3 board with some indexes of the array having been set as unavailable, indicating
they have been taken.
 Index 3, 4, 5 of the board set with the character X, which indicates that they have been
taken by the human player
Expected Results: We expect the human player to be a winner, since index 3,4 and 5 holds the
values; 4,5 and 6 respectively, which adds up to 15.
Results: Passed: The test was successful.

Test ID: J04
Description: Test of isWinner method, of class Get15Model.
Pre-Condition: Initialize class Get15Model to allow testing of the method
Test Data:
 A 3x3 board with some indexes of the array having been set as unavailable, indicating
they have been taken.
 Index 0,3, 4 of the board set with the character X, which indicates that they have been
taken by the human player
Expected Results: We don’t expect the human player to be a winner, since index 0,3,4 holds the
values; 1,4,5 respectively, which adds up to 10, meaning the player has not won.
Results: Passed: The test was successful.
Reflection
Working on this assignment gave me a hands-on practice in design, development and testing of a
software. Being a beginner in software development, I made numerous errors and mistakes,
which took me hours to identify and resolve. In particular, one major mistake was to miss the
implementation of abstract methods in the classes inheriting from the abstract class. This resulted
in errors that took me sometime to identify. The design I implemented for this application was
simple and straightforward. The fact that I first visualized diagrammatically how all classes were
to be related made it possible for me to implement the application without much design
problems. However, in future implementations, I will need to improve on the inheritance
structure, by putting all common functionalities in the parent class, thus avoiding duplicated code
in each child class in the inheritance structure.
The assignment has taught me a lot in the area of software development. At the start of the
project, I lost valuable time wondering where to start. This is because I had jumped into coding
without first analyzing the problem and putting up a clear implementation plan. I however
corrected this mistake in time and drew up a plan as well as a clean analysis of the program, thus
facilitating a smooth implementation of the various features.
Due to the thorough testing and re-coding of the application, no bugs have been left. This is
because I spent much time running the application and debugging. Initially, the main bug was
with regards to starting a new game. I realized that after playing the first round, the New Game
button was not resetting the internal structures of the game. Thus the subsequent rounds were full
of errors. I however realized the mistake in time and fixed appropriately.

Bibliography
Barnes, D.J., Kölling, M. and Gosling, J., 2017. Objects first with Java: A practical introduction using
Bluej. Pearson.
Baesens, B., Backiel, A. and Vanden Broucke, S., 2015. Beginning Java programming: the object-
oriented approach. John Wiley & Sons.