Christopher Pina

CST 438: Project Report

Battleship: Project Report

I. Project Introduction and Background

The goal of this project was to produce a web version of the game of

Battleship. Our teams goal was to develop a single player version of the

classic board game. The game would allow a player to visit a specific URL.

The player would be greeted by a welcome screen that displays the game

rules and allows the user to request the start of anew game through a single

button. The player would then be taken to the game screen where they

should be able to view their game board with the placement of their ships.

The player would also be able to see the opponents board. The player

should have the option to enter coordinates from the opponents board to

attempt to sink the opponents ships. The game ends when either player

sinks their opponents fleet.

The broader goal of this project was to demonstrate our ability to

develop REST applications. The game would use a java servlet to handle all

server requests. The application would use JSON objects to transfer data

between the servlet and client. It was our teams goal to develop an

application that was lightweight and flexible. We also set out to develop a

client for the application. The client was built using JSPs with JavaScript and

JQuery. The client submits requests to the server using JSON and receives

JSON objects that are parsed and displayed to the user. Beyond the technical

specifications, our team chose this project because we wanted to take on a

challenging project that would demonstrate our understanding of the course

 Christopher Pina
CST 438: Project Report
material. We wanted to develop a functional application that was also fun to

work on as a team.

II. Quality
Our goal for this project was to develop a functional web application,

but we wanted our application to have a solid foundation. Our team was

dedicated to producing quality code. Quality code at a minimum is defect

free. The code must compile without errors or issues. Quality code has to be

lightweight and efficient. It is also crucial that good quality code be reusable

and flexible. In order to achieve quality code our team focused on code

review. The team was committed to sharing any changes to the code as early

and often as possible. This practice allowed other members of the team to

review any code changes before further development could take place. The

team also implemented continuous testing by developing automated unit

tests to verify the output of all basic methods. Our team developed test

cases for every single class that allowed for automated testing through JUnit.

As part of our commitment to quality code, our team also developed a

working environment that welcomed feedback. Our team developed

excellent communication and a willingness to help each other early in the

process. This allowed members of our team to be comfortable providing and

receiving feedback during code review. As was described in 11 Practices for

Peer Code review, one of the most important factors in producing quality

code is developing a good review culture. Our team was able to accomplish

this in a short period of time, which was crucial to our success.

 Christopher Pina
CST 438: Project Report
One aspect of code quality that we were unable to address as a team

was non-functional requirements. With such a short time frame most of our

focus was on producing a working piece of code that met all of the functional

requirements. With more time our team would absolutely have to address

several of these non-functional requirements. One of the most important

features to address in a REST-JSON application is security. We would need to

develop a way for the server application to verify that the client has the

required permissions to utilize the application. Regarding performance, if we

wanted to develop the application further to include the ability to play a

multiplayer game, we would need to ensure that performance requirements

were met. A multiplayer game that is played live would require a higher

performance level than the single player application we have developed.

These non-functional requirements are just as important as any functional

requirements and must be addressed by the development team.

III. Team Velocity
Completing software projects on time and within budget is crucial to

the success of any development team. In order to accurately estimate

completion time and cost, which is vital to any client, development teams

need to have an accurate gauge of their productivity. To measure

productivity, software development teams use team velocity. Team velocity is

a measurement of the number of story points completed by the team over a

period of time, usually one iteration. Using team velocity, a development

team can estimate the number of iterations the project will take based on

the number of story points left to complete and the teams measured
 Christopher Pina
CST 438: Project Report
performance over the first few iterations. Our teams velocity can be used to

estimate completion times and therefore estimating development costs of

future projects. Team velocity can also be used during an iterative

development process to adjust deadlines and estimated completion times.

IV. Communication
Communication between team members is crucial in agile

development. Our team had excellent communication throughout the

project. The entire team was open to ideas and willing to step in and support

whenever it was needed. For the first few weeks the team relied primarily on

chat sessions. We discussed requirements and basic implementation details

within chat. The chat functionality of Google hangouts stores a

conversations history which allowed team members to read through all

previous discussions and provide ideas whenever they were available. This

was incredibly helpful in balancing everyones hectic schedules. Team

members did make an effort to join the team chat at a scheduled time a few

times per week. These quick meetings were usually held at night after code

had been committed to our GitHub repository. These chat meetings were

valuable in establishing the basic architecture of our program. However,

once we were ready to tackle advanced functionality and requirements chat

meetings no longer seemed appropriate. Our team was forced to transition

to using Google hangout that allowed us to talk to each other and share our

screens when necessary. This more formal meeting was incredibly beneficial.

The team was able to share ideas more freely and having the ability to talk

to the team directly led to more in depth discussions. Of course, a more

Christopher Pina
CST 438: Project Report
formal meeting also had its drawbacks. When one member of our team was

unable to attend the meeting there was no real way to keep a history of

every conversation that took place. Our team did maintain a log with notes

throughout the meeting, but it is not as robust as the chat history feature. If I

were to change anything in my approach to this project it would absolutely

be to communicate via Google hangout sooner in the process instead of

relying so heavily on chat sessions.

For the most part communication was excellent, however, there were

some challenges in development that could have been avoided with

improved communication methods. Since it was our teams first time working

together we did not have much time to get to know each others strengths

and weaknesses. This led to one of our team members taking on a handful of

requirements that may have been better handled by someone else on the

team with more experience with that particular technology. This did not have

an impact on our final product since the team was able to provide feedback

during code review, but assigning requirements based on team strengths

could have improved our team velocity. However, this challenge probably

had more to do with external aspects of the project such as it being a class

assignment, working remotely and working with a brand new team.

Working with a brand new team was definitely a challenge, but chat

history and well documented code was crucial to overcoming this limitation.

The initial code committed to the repository lacked documentation, but

methods, variables and classes were properly named. Anyone joining the

project would be able to easily determine what the code does simply by
 Christopher Pina
CST 438: Project Report
reading the names of most objects. The project required minimal comments

and documentation, but what was necessary was added to the final version

of the code as the project was added to the server. Any new member of the

team would be able to follow the documentation, organization and structure

of the program to get themselves up to speed.

V. Process and Design
The first step of the project for our team was requirement gathering.

Most of our broader requirements were established early on and did not

change. The Battleship game has very specific rules that defined the scope

of the project to a certain degree. These requirements remained constant

throughout. However, the implementation of the game and the design of the

game changed as we moved through the development process. Our team

velocity and time constraints forced us to change the requirements. The

game play remained the same, but the functionality of the game changed in

order to design something more basic that could be accomplished within the

allotted time frame. For example, our team decided to randomly choose the

placement of the ships on the board instead of allowing the user to set the

board themselves. Changes in requirements forced us to factor portions of

our code. Based on the original requirements we implemented methods that

allowed players to set their battleships on the game board. When we decided

to remove this functionality, the methods were usable but had to be

refactored to allow the game controller to randomly set the ships for all

players. As requirements changed and code had to be refactored the benefits

of agile development became clear. Defining requirements earlier in the

 Christopher Pina
CST 438: Project Report
process would have been helpful, but overall a waterfall development

process would not have provided the flexibility that we needed for this

project. Using a formal process would have been even more cumbersome for

our team during this project.

The advantage that we had during development was that we were able

to easily implement a design pattern within the system. The battleship game

uses the model-view-controller design pattern. The game maintains a clear

separation between the internal workings of the program and the visual

representation for the user. The view is represented by the JSP files that are

displayed on the users browser. These JSP files are responsible for displaying

the game and all game data to the user as well as receiving all user input.

Game data is stored in the GameModel objects, which are responsible for

housing all game data for both players. The link between these two

components is the GameController object, which is responsible for updating

the view based on the model object.

VI. Diagrams

Domain Model
Christopher Pina
CST 438: Project Report

The diagram shows the applications most important classes and their

relationships. The basic objects of the application include Point, Location and

Ship. Ships have a location and locations have points. Ships are the core of

the application since they are used to build Player objects. A Player object

stores a number of ships as well as any guesses (points) made by the player.

The application requires two distinct player classes, one for the user and a

second for the Computer Player. The Computer Player class extends the

Player class, but adds guessing functionality. All player data is stored in the

Game Model class. Game Models are stored as new games in the Game

Controller. The Game Controller class utilizes an inner class to handle the

creation of a new Rest Request. It also extends the HttpServlet class.

Deployment Model
Christopher Pina
CST 438: Project Report

The most important aspect of this application is the ability of the client to

submit requests to the server without the server necessarily knowing any

details of the client. The deployment diagram above shows that in the

Battleship game the client operates on a different system than the server

application. The client uses JSPs along with JavaScript to process the

response from the server. The diagram shows that requests submitted by the

client are directed to the applications Game Controller.

Requirements/User Stories

One of the key requirements of the application is for the player to be able to

start a new game upon arrival. This requirement can be further described

with the following user stories and UML:

Player should be greeted with a welcome page

Christopher Pina
CST 438: Project Report
Player should have the ability to start a new game

Ship locations should be set at random for both players

Player should be able to see state of opponents board.