Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
COMP6018 Advanced Object Oriented Programming
Module No: COMP 6018
Module title: Advanced Object-Oriented Programming
I declare that the work submitted is my own and that the work I submit is fully in accordance with the University regulations regarding assessments (www.brookes.ac.uk/uniregulations/current)School of Engineering, Computing & Mathematics Marking grid is attached at the end of this assignment.
For this coursework, you will produce two versions of the one-player game of Battleships1 . One version will have a Graphical User Interface (GUI) and the other version will have a command-line interface (CLI). The GUI version will be constructed according to the principles of Model View Controller, and the CLI version will use the same model. The two versions will from now on be called the GUI version and the CLI version
Battleships is a game in which a (human) player must guess the locations of ships that the computer has secretly arranged on a 10 × 10 grid. Each ship occupies several consecutive squares and may be arranged either vertically or horizontally. There are various types of ship, each composed of a different number of squares. These are shown in red below.
What the player will see is not the locations of the ships but the locations of the attempts they have made. In the diagram these are indicated by Xs but you must indicate whether they are hits or misses by labelling them as either H for hit or M for miss. You may use symbols or a graphical notation instead for aesthetic reasons so long as the meaning is clear.
ASSIGNMENT IN DETAIL: FUNCTIONAL REQUIREMENTS
ASSIGNMENT IN DETAIL: NON-FUNCTIONAL REQUIREMENTS
FR1
The GUI and CLI versions will both show a 10 × 10 grid indicating for each location that the user has tried whether that was a hit or a miss.
FR2
The player selects a grid location for the GUI version by clicking on it.
FR3
The player selects a grid location for the CLI version by entering an upper case alphanumeric string eg A1, J10 according to the row and column labels.
FR4
There is one ship of length 5, one of length 4, one of length 3 and two of length 2 and none of length 1.
FR5
Ships may be adjacent to one another but cannot intersect.
FR6
The board must be secretly arranged by the computer at the start in accordance with FR4 and FR5. You may use a hard-coded board for this initially but note FR7.
FR7
In both versions, it is possible for the user to load in a text file with a configuration of ships in accordance with FR4 and FR5. You can design any text file format that fits FR4 and FR5. An error message will be shown if the text file does not conform to the format.
FR8
Both versions must indicate when a whole ship is sunk and should at the end of the game report how many tries were needed to sink the whole fleet.
|
NFR1 |
The GUI version must be constructed according to the principles of MVC, as restated below. |
|
NFR2 |
The CLI version will use the Model part of the GUI version directly without using the View or Controller; nor should it define a new view or controller. |
|
NFR3 |
The code must be documented with asserts, unit testing, class diagram, comments as described below. |
|
NFR4 |
The code must be of good quality as described below. |
The class diagram should have all methods and attributes showing. A class diagram with insufficient detail or syntactically nonsensical or not realisable as an actual Java program will make it more difficult for us to give you feedback and will receive a low mark if submitted with the final report.
SUMMATIVE FEEDBACK DELIVERABLES
|
Deliverable description and instructions
1. Your code will be uploaded to the GitHub repository as regular commits a long time in advance of the deadline. In addition
2. Upload a Word document or PDF which must:
3. You may be asked to attend a demonstration on Zoom to answer questions about the video and if you are then you must do so.
|
Weighting out of 100% |
|
Code for Model (in repository and report):
This should have an interface designed to be convenient for the Controller, View and JUnit class to use with no superfluous public methods, no references to those three classes and contain no GUI code. It may consist of several classes but there must be a class called Model or similar that provides the interface and this class should extend Observable.
|
15% |
|
Code for Controller (in repository and report):
This should forward only valid requests to the Model, querying the Model if necessary tofind out if the request is valid, and must also enable / disable any buttons needed toimplement the above functional requirements. It must have no GUI code, though it maysend messages to the View.
|
5%
|
|
View using the Swing framework (in repository and report):
It should implement Observer and therefore have an update method that is called whenthe Model changes. This will be marked according to how many of the functionalrequirements have been met.
|
10% |
|
CLI version of program, using the Model (in repository and report):
A single class using the Model which when run implements the same functionalrequirements as the GUI except that all of the information about each square should be recorded in a separate line of text rather than mimicking the ring structure shown in thediagram.
|
10% |
|
Specification of Model with asserts (in repository and report):
This should include invariants for the class as well as pre and post conditions for eachpublic method in the model and should preferably be in logic with partial credit for descriptions in English.
|
10% |
|
Unit testing of the Model in JUnit (in repository and report):
There should be three tests, significantly different from each other. You should explain in the comments the scenario i.e. the situation you are testing for. You should use write (andthen call) methods for the Model that set it into the state desired for the test. It should beeasy to see what state the Model is being set to by reading the code for the unit tests. Your Model may use a separate Board class but the testing should be of the Model class andthe specification should be applied to that class also.
|
10% |
|
Code quality (in repository and report):
Use of the code quality practices described in Lecture/practical 1, plus the additionalpractices of light relevant commenting and correct formatting. Short elegant programs are preferred, and code smells are to be avoided. Note that high marks for this category willonly be possible if the GUI fulfils most of the requirements.
|
10% |
|
Class diagram (in report):
This should show how the Model, View and Controller are related to each other, as well ashow they interact with library classes such as Observable. Simplicity and clarity will be rewarded. It will be marked according to its accuracy as a representation of the program.
|
10% |
|
Video (URL in report):
Five-minute video that shows you using the program. It will be marked according to timing, presentation and how well you show that you have met the FRs and NFRs in both versions. If the marker has any questions about the video, then you will be invited to a Zoom presentation. |
10% |
|
GitHub Commits (in repository):
You must make regular commits to the GitHub repository that you will be given.
|
10% |
Coursework
|
|
F |
P |
B/C |
A+ |
|
Model 15% |
only basic functionality implemented or slightly more than basic but references to View or Controller or superfluous methods |
no superfluous methods and no references to View or Controller but only the basics of functionality implemented |
no superfluous methods and no references to View or Controller but only the basics of functionality implemented |
convenient to use with no superfluous methods, all required functionality and no references to View or Controller, extends Observable, calls setChanged and notifyObservers |
|
Controller 5% |
zero of the requirements: only valid requests, querying Model first, enables/disables buttons without GUI code |
one out of only valid requests, querying Model first, enables/disables buttons without GUI code |
two out of only valid requests, querying Model first, enables/disables buttons without GUI code |
only valid requests, has references to both Model and View, converting UI interactions into methods to change the Model, querying Model first, enables/disables buttons without GUI code |
|
GUI View 10% |
no view update method or update method implementing very few of the FRs |
update method in view implementing some of the FRs |
update method in view implementing most of the FRs |
update method in view implementing all the FRs, uses Swing, has Model and Controller as attributes, displays board and allows Controller to change the view e.g. enable/disable options, implements Observer and calls addObserver |
|
CLI class 10% |
CLI version implementing very few of the FRs |
CLI version implementing some of the FRs |
CLI version implementing most of the FRs |
CLI version implementing all of the FRs, using same Model as the GUI version, but no Controller and is demonstrated on the video |
|
Specificati on of Model with asserts 10% |
a few pre/post conditions described in English |
suitable pre/post conditions for most public methods but in English |
suitable pre/post conditions for most public methods expressed in some logic |
suitable pre/post conditions for all public methods and class invariants all expressed as statements of formal logic |
|
Unit testing of Model with JUnit 10% |
one test with the scenario poorly described or not at all |
tests all essentially similar or only one or two or scenario being tested poorly described |
third test not significantly different or scenario being tested not described with sufficient care |
three significantly different tests of the model with all scenarios exactly described and with all inputs satisfying the preconditions |
|
Code quality practices 10% |
most code quality practices not observed or program is too small to demonstrate good code quality practices |
some code quality practices observed but many not or program is too small to demonstrate good code quality practices |
most code quality practices observed but some clearly not |
all code quality practices observed including light correct commenting, suitable identifier names (constants, methods, classes etc) in appropriate cases, indentation, lack of code smells (long methods, repeated code, lack of modularity) |
|
Class diagram 10% |
Inadequate class diagram with serious mistakes in attributes and relationships between classes |
Adequate class diagram with mistakes in both attributes and relationships between classes |
Good class diagram with only a few mistakes in attributes, visibility or relationships between classes |
Excellent class diagram with all attributes indicated with correct visibilities and correct relationships between classes all shown |
|
Video Presentati on 10% |
Very poor presentation with insufficient coverage of FRs and NFRs, poorly presented and overly long |
Passable presentation covering FRs or NFRs or well-presented or at least appropriate length |
Quite good presentation but missing some details of FRs and NFRs or poorly presented or overly long |
Excellent presentation with full explanation of most FRs and NFRs, well presented and within time limit |
|
GitHub 10% |
Some minimal code in the repository |
Updates to the repository but mostly for the last few days before submission |
Evidence of regular updates to the repository over a period of several weeks |
Clear pattern of regular updates over a period of two months according a clear version policy with informative commit messages |