COMP2050 Coursework #2
Boon-Giin, Lee; Heng, Yu
[email protected]; [email protected]
University of Nottingham Ningbo China, School of Computer Science
1 Synopsis
Coursework 2 is about maintaining and extending a modern version of classic retro game (Packman). To
get started, download zip file ”BestPackmanEverV5.zip”. The zip file contains only ”src” folder, so you
have to set up your own JavaFX project in Eclipse and import the src folder. You will be asked to make
some changes and additions to the project.
NOTE This coursework is about maintaining and extending existing code. So, for the maintenance
part, you have to use the existing code as a basis, and not write your own Pacman game from scratch.
IMPORTANT Make sure you understand what you are writing in your Javadocs. We reserve the
right to briefly interview you if we think that you do not understand what you write about. So, when
you write your Javadocs, do not simply copy/paste large portions of text from existing articles or other
resources - as this does not demonstrate your understanding of the topic. You might also run into issues
with plagiarism.
You should roughly spend 50 hours on this coursework.
Table 1: Coursework Summary
Weight 50%
Format
• Class Diagram (as PDF).
• Source Code in Form of Eclipse Project (*.zip, NOT *.rar).
• Documentation (Javacs)
• Video in 2-3 Minutes
Submission Date 9th December 2019, Monday by 4 p.m.
Late Policy Standard Policy
Submission Method Electronic Submission via Moodle
Feedback Date 2nd January 2020 (Expected)
Feedback Method Individual Comments via Turnitin in Moodle page
2 Deliverable
Set up a Git repository on the university’s Git server as PRIVATE (link) and use it for version control
activities. The project should be name with ”FirstnameLASTNAME-StudentID” for consistency, e.g.,
RuibinBAI-20031168. PLEASE to be NOTE that the university’s Git server ONLY can be ACCESSED
when CONNECTED to eduroam. Follow the instructions (”Add Users to Group”) to add two GitLab
members ”z2019017” and ”z2019078” with role permission as ”Maintainer” for your coursework assess-
ment.
1
COURSEWORK 2 COMP2050 SOFTWARE MAINTENANCE
Four directories (folders) should be created, namely, ”src”, ”documentation”, ”diagram” and ”video”.
• ”src” - Contains all the source codes of the project.
• ”documentation” - The documentation should be delivered in form of Javadocs. We will mainly look
at the Javadocs to find out how you maintained and extended the game. If it is not obvious from there,
we might miss it. Also, we have only a limited amount of time to look at each coursework submitted.
So, please make sure to provide informative but concise Javadocs.
• ”diagram” - Provide a high level class diagram in PDF format (landscape orientation is highly recom-
mended for clearer view) that shows the structure of the final version of your game (considering only
classes, interfaces, relationships and multiplicity)
• ”video” - Make a video showing your software in action, demonstrating and explaining its functionality.
You could highlight 2-3 achievements you are very proud of in your video.
REPORT A maximum of one page PDF report should be submitted in the Moodle page to provide any
brief description of software maintenance you have done especially related to refactoring and additions.
You can also highlight any important things that you wish us to pay attention to. Be simple but precise.
You should name your report as ”cw2-StudentID-report.pdf”, e.g., ”cw2-20031168-report.pdf”. A zip file
should be created containing your entire project and submitted as supplementary file. Your project must
be able to import into Eclipse using the import wizard. Please name your ZIP (NOT *.RAR or other
archive types) file as ”cw2-StudentID-project.zip”, e.g., ”cw2-20031168-project.zip”. Failure to adhere to
these rules may result in our refusal to mark your coursework.
IMPORTANT The mark and feedback of the coursework will be released in the Turnitin under the
report section but assessment will be mainly based on your project in university’s GitLab server.
3 Plagiarism
You are gently reminded that we are at liberty to use plagiarism detection software on your submission.
Plagiarism will not be tolerated, and academic offenses will be dealt with in accordance with UNNC
policy and as detailed in the student handbook. This means you may informally discuss the coursework
with other students but your submission must be your own. Please also note that it is not permitted for
you to copy and paste text from another source without correct referencing.
4 Assessment
This coursework is worth 100% of this module and as such is marked out of 50. The marks will be split
as follows:
• [15%] Git Use - Version control? Utilization of Git?
• [30%] Refactoring - MVC pattern? Design principles?
• [30%] Additions - Interesting features? Creative ideas?
• [15%] Documentation - Javadoc? High-level class diagrams?
• [10%] Video - Interactive? Presentation quality? Explanations?
NOTE Good programming practice will gain higher marks. Furthermore, nicely presented and easiness
of using interfaces will be rewarded. A proportion of the marks will depend on you supplying a working
version of your game, and submitting a video of it in use.
IMPORTANT It is always a good practice to refer to the assessment rubric to understand how to
secure high mark in the coursework. The rubric is provided for your reference, make sure to check it out
at the last page.
UNIVERSITY OF NOTTINGHAM NINGBO CHINA, SCHOOL OF COMPUTER SCIENCE 2
COURSEWORK 2 COMP2050 SOFTWARE MAINTENANCE
5 Task
Do some basic maintenance of the delivered code base, e.g., adding meaningful Javadocs, organizing files
in a meaningful way into packages, breaking up large classes in a meaningful way to support the idea of
single repository, improving encapsulation etc.
Extend the delivered code base by adding:
• A START screen, displaying a picture related to the game and a button that allows going to a SETUP
screen.
• A START screen: Allowing to choose background and wall colour for the game field (allowing a
choice of at least 8 colours) and a button to go back to the START screen.
• A high score pop-up, appearing at the end of each round, showing the scores from each round,
highest at the top.
• Two doors at the side of the play field to allow the pacman and the ghosts to transit between them
(leaving at door 1 and immediately re-appearing at door 2 and vice versa) as showed in the Fig. 1.
IMPORTANT You need to use Java 8 for the implementation. The project files you are submitting
need to be compatible with Eclipse.
Figure 1: Pacman with Door 1 and 2.
5.1 Tips & Hints
To get higher marks, you can perform some of the tasks as follow in addition to the previous:
• Refactor the code by adding some design patterns to enhance maintainability.
• Considering organizing the code to adhere to the MVC pattern.
• Create a permanent high score list, e.g., using a file to store scores.
• Load level descriptions from file and allow running the game with different layouts.
• Load proper character figure.
• ...
UNIVERSITY OF NOTTINGHAM NINGBO CHINA, SCHOOL OF COMPUTER SCIENCE 3
COURSEWORK 2 COMP2050 SOFTWARE MAINTENANCE
6 References
If you use any text or information from any resources such as books, journals, articles, proceedings etc.,
you have to provide those references. A guide for references and citation can be found here.
Finally, if you have any questions, you are always welcome to post your questions in the forum under the
topic Coursework#2-Q&A.
7 Q & A
If you have any questions, kindly utilize the ”Q&A Forum” under the topic Coursework#2-Q&A.
REMINDER Make sure you follow strictly the instructions/guideline provided for posting the ques-
tions in the forum.
UNIVERSITY OF NOTTINGHAM NINGBO CHINA, SCHOOL OF COMPUTER SCIENCE 4
Criteria F - 0 D - 40 C2 - 50 C1 - 60 B2 - 70 B1 - 80 A - 100
Git Use [15%] No evidence of
git repository
set up on this
project.
Remote Git repos-
itory is set up but
low usage activities
recorded. Evi-
dence of local Git
repository is found
but little-to-no
knowledge of git use
evidence presented.
Remote Git repository is
set up but low usage ac-
tivities recorded. Evi-
dence of local git reposi-
tory is found but little-
to-no evidence of com-
mitments and purpose
use of Git are presented.
Remote Git repository is
set up with basic usage
evidenced. Local reposi-
tory is found with basic
commitment and poor
explanation. The pur-
pose use of git is not suf-
ficiently presented.
Remote Git repository is set
up with basic usage evidenced.
Local repository operation is
found with moderate commit-
ment and with proper and de-
tailed explanations. Branching
feature is incorporated.
Remote Git repository is set
up with extensive usage evi-
denced. Local repository oper-
ation is found with high com-
mitment and with informative
and clear explanations. Princi-
pal use of branching is greatly
illustrated.
Remote Git repository is set up
with rich set of usage evidenced.
Local repository operation is found
with high commitment and stun-
ning explanation, branching is used
extensively. Git work flow is clearly
explained, demonstrated profes-
sional way of exercising git tool for
software development and mainte-
nance, satisfying the aim of this
module.
Refactoring
[30%]
No evidence of
code refactor-
ing presented
in this project.
There is little
evidence that
code refactoring
is presented with
no improvement to
this project.
There is some evidence
that relevant code refac-
toring principles have
been incorporated into
this project. At best,
there are loose princi-
ples.
Your code refactoring
refers to couple of refac-
toring principles with at
least one design patterns
documented, but largely
lacks precision and cita-
tions.
Your code refactoring shows
evidence that aligned with
MVC pattern and at least two
design principles, but your ter-
minology may be imprecise.
You may be missing some key
concepts or some of your refac-
toring may be incorrect or your
references may be incorrect.
Your code refactoring shows sig-
nificant evidence that were sup-
ported by the MVC pattern and
at least two design principles.
Your terminology may is precise
and correct. Appropriate refer-
ences have been used. You made
improvement to the ghost AI al-
gorithm.
The majority code refactoring prin-
ciples are justified by appropriate
citations with three or more de-
sign principles. Those principles
are clearly articulated, use pre-
cise terminology, and cite appropri-
ate source. You successfully im-
plemented the original behavior of
ghost AI.
Additions
[30%]
None additions
documented or
presented in
this project.
Some detailing that
hint towards addi-
tional features or
ideas, but not ex-
plained.
Some detail and expla-
nation of very small ad-
ditional features, ideas
and tasks. Poorly ex-
plained.
2+ tasks are imple-
mented with clear addi-
tional features and ideas
implemented. Briefly ex-
plained.
3+ tasks are implemented
with clear additional features,
ideas and tasks implemented.
Clearly explained but poorly
reasoned/justified.
All tasks are completed. 5+ ad-
ditional features and ideas im-
plemented and well justified.
All tasks are completed. Several
additional features and ideas are
included. All are well explained
and justified. The implementation
demonstrates creativity beyond ex-
pectation.
Documentation
[15%]
No documenta-
tion provided
in this project.
Little-to-no high
level diagrams
provided and pack-
age information is
missing. Javadoc
folder created, but
with low com-
mitment, quality,
lack of justified
explanations.
High level class dia-
grams provided, but in-
sufficient package infor-
mation. Javadoc folder
created with moderate
commitment but a num-
ber of quality issues ex-
ists, includes poor ex-
planations of parameters
and methods.
High level class diagrams
provided with package
information, but with
some errors. Javadoc
folder created with high
commitment, explana-
tions of parameters and
methods, but does not
comply with OO design
considerations.
High level class diagrams
provided with organized and
justified package information,
but with some minor errors.
Javadoc folder created with
high commitment, well ex-
plained and justified, comply
with some OO design con-
siderations but with minor
errors.
High level class diagrams pro-
vided with clear explanations
of package information and pre-
sented in appropriate layout.
Javadoc folder created with high
commitment, all codes are with
clear explanations, justified and
show consistency in the project.
Also, comply with OO design
concepts.
The high level class diagrams pro-
vided in professional, clear and con-
sidered manner with high quality
package information includes rela-
tionship between classes. Javadoc
presented with stunning explana-
tions, correct format and identical
quality with Java online libraries
documentation.
Video [10%] No video sub-
mitted on this
project.
Video showed with
no explanations.
Insufficient and lack of
informative contents
presented in the video.
Meaningful information
and small references of
improvements presented,
but with errors in the
video.
Informative contents with rel-
evant references of improve-
ments presented, but with mi-
nor errors in the video.
A number of high quality, im-
pactful and relevant references
to your OO designs improve-
ments and refactoring efforts,
supported with texts explana-
tions in the video.
A wealth of high quality, impactful
and relevant references to your OO
design improvements and refactor-
ing efforts, supported with text and
audio explanations. Video contents
not lengthy, straight to the points
with clear and appropriate pronun-
ciation.
5