Developing Maintainable Software
Coursework Specification Sheet
Boon-Giin, Lee; Heng, Yu
boon-giin. .cn; heng. .cn
University of Nottingham Ningbo China, School of Computer Science
1 Introduction
This coursework is about maintaining and extending a re-implementation of classic arcade game called
Bubble Bobble. The new implementation has never been completed, but at least it runs, once it is set
up properly. More information about the original Bubble Bobble game and its history is available here.
In addition, you will find lots of opportunities on the Internet to play the original game online.
Set up a remote git repository at the schools GitLab server. Your remote repository need to be
named “AE2DMS-CW-StudentID” (e.g. “AE2DMS-CW-20211101”) and needs to be set to PRI-
VATE. Then follow the “Add Users to Group” instructions to add two members “z2019017” (Bryan) &
“z2019078” (Heng Yu) with role permission as “Maintainer” to the remote repository. It is expected to
have only THREE members in the remote repository. Clone the remote repository to your local storage.
Next, please download “COMP2059-BubbleBobble.zip” from Moodle. Set up a project in your preferred
IDE (IntelliJ is highly recommended) and embed the files that you just downloaded. Name the project
“BubbleBobble”. Note that the zip file you downloaded from Moodle only provides source code and
resources but no project files. Add a .gitignore file to the local repository, ensuring executable files such
as .jar are excluded from uploading to the remote repository. Then, do an initial push to upload the
project from your local repository to your remote repository. Now, you are ready for coding with version
control. It is important to remind you that this coursework is about maintaining and extending existing
code. Hence, for the maintenance part, you must use the existing code as a basis, and not write your
own Bubble Bobble game from scratch.
NOTE The school’s GitLab server ONLY can be ACCESSED internally. For remote students that
have difficulty to access the school’s server, use the official GitLab server instead. To add Bryan and
Heng Yu to the remote repository, you can search for the existing members using our UNNC email ad-
dresses.
You should roughly spend 98 hours on this coursework.
Table 1: Important Dates
Issue Date November 1st, 2021 on Monday by 12 p.m.
Submission Date December 13th, 2021 on Monday by 12 p.m.
Late Policy Standard Policy
Feedback Date January 17th, 2022 (Expected)
Feedback Method Moodle
1
https://bubblebobble.fandom.com/wiki/Bubble_Bobble
https://csprojects.nottingham.edu.cn
https://csprojects.nottingham.edu.cn/help/user/group/index.md
https://moodle.nottingham.ac.uk/mod/resource/view.php?id=5600352
https://www.gitlab.com
COURSEWORK COMP2059 DMS
2 Assessment
The marks will be split as follows (total 100%):
• 15% for git use (e.g. push, branch, merge, providing .gitignore).
• 40% for refactoring.
• 20% for additions.
• 15% for documentation (README.md, Javadocs and class diagram).
• 10% for video, explaining your refactoring activities and additions.
3 Deliveries
• A “README.md” file (maximum of 500 words, not including test cases, you can’t replace text(s)
with figure(s) or screenshot(s)), documenting the work you conducted (highlighting the key changes you
made for maintenance and extension, where you made them, and why you made them). WARNING:
If you don’t mention here, don’t blame us later, if we miss it, and no appeal is allowed! You should
clearly state all the changes and maintenance made with proper references to the code (don’t use
screenshot) in the README.md file. Otherwise, they will be treated as non-implemented. In addition,
convert the README.md to PDF (online converter), name it as “README-StudentID.pdf”, e.g.
“README-20211101.pdf” and submit to Moodle.
• High level class diagram in “Diagram” folder that shows the structure of the final version of your
game (considering only classes (excluding fields and methods, unless they are relevant for under-
standing design principles/patterns), interfaces, relationships and multiplicity). If you use software
to reverse engineer your class diagram, make sure the delivered diagram is correct and follows the
above requirements. Name your diagram as “ClassDiagram-StudentID.pdf” (e.g. “ClassDiagram-
20211101.pdf”) in PDF format.
• The source code documentation (Javadocs) should be delivered in form of a “Javadocs” folder inside
your project. Besides reading your README.md file, we will 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. Please make
sure to provide informative but concise Javadocs.
• Finally, you have to make a video (very briefly) up to 2 minutes in “Video” folder, showing your
software running and then (for the main part), explaining your refactoring activities and additions.
You should also highlight two achievements you are most proud of. Please name your video as
“Video-StudentID.mp4”, e.g. “Video-20211101.mp4”.
• You are expected to use Java SDK 16 and JavaFX 16/17 for the implementation. The project (“Bubble-
Bobble” folder) you are submitting need to be compatible with IntelliJ IDE. To avoid disappointment
later, download the project from your remote repository (in zip file) and test run your project on
different computers. This should help to uncover hard-coded path dependencies.
To pass the assessment (40%)
• Set up a PRIVATE git repository on the school’s GitLab server and use it actively for version control
activities.
• Do some basic maintenance of the delivered code base (this should include things like adding meaningful
README.md and Javadocs, organising files in a meaningful way into packages, breaking up large
classes in a meaningful way to support the idea of single responsibility, improving encapsulation etc.).
• Perform perfective maintenance by replacing Swing with JavaFX for GUI implementation.
• Extend the delivered code base by adding:
– A START screen, displaying a picture related to the game with some setup options to choose
different colours for the game (allowing a choice at least 8 colours) and two buttons that allows
going to the GAME screen and another going to a INFO screen explaining the game operation.
– A HIGH SCORE pop-up, appearing at the end of each round, showing the scores from each
round, highest at the top.
UNIVERSITY OF NOTTINGHAM NINGBO CHINA, SCHOOL OF COMPUTER SCIENCE 2
https://www.markdowntopdf.com/
https://moodle.nottingham.ac.uk/mod/turnitintooltwo/view.php?id=5551813
COURSEWORK COMP2059 DMS
For higher marks: In addition to the previous, do some of the following …
• Refactor the code by adding some design patterns to enhance maintainability, and perform different
types of design patterns.
• Organise the code to adhere to the MVC pattern.
• Create a permanent high score list (using a file to store scores).
• Add interesting levels to the game (either based on your own ideas or the original game).
• Add meaningful JUnit tests. These tests are evaluated as part of documentation (README.md).
• Use build files (Maven or Gradle).
• Additions of game feature or other implementations that are innovative and beyond
creativity – Come up with your own ground breaking idea … surprise us 😀
NOTE See Fig. 1 for the template of remote repository.
Figure 1: Template View of GitLab repository.
4 Important Notes
Make sure you understand what you are writing in your Javadocs. We reserve the right to briefly in-
terview 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.
Good programming practice such as providing comments in the code will gain higher marks. Further-
more, nicely presented and easiness of using interfaces will be rewarded. High quality additions of game
features are expected to gain higher mark. Implementation of basic and simple features (i.e. START
screen, INFO screen, OPTIONS screen, HIGH-SCORE screen, sound effects etc.) will not gain you above
the “Good” performance, however, implementation of at least THREE creative features allows you to
gain above the “Good” performance (see Marking Rubric).
The mark and feedback will be uploaded to the Moodle coursework submission page.
UNIVERSITY OF NOTTINGHAM NINGBO CHINA, SCHOOL OF COMPUTER SCIENCE 3
COURSEWORK COMP2059 DMS
Assessment Details:
• This coursework is contributing 75% to your overall grade and will be marked out of 100.
• To give you an idea about what we are looking for when we do the marking, we have attached our draft
marking scheme as an appendix. Please note that this is only a guide for us and does not guarantee
your marks when you have done certain things! There is always an aspect of quality that needs to be
considered as well. We also reserve the right to revise the marking scheme (within limits), if we see
the need for this during the marking process.
Penalties (besides late submission penalty, which follows UNNC standards):
• Using wrong document formats (word or image instead of PDF) or video formats (swf or avi instead
of mp4) will lead to a penalty of -5 each.
• Failing to comply with any naming conventions requested will lead to a penalty of -2 each.
• Incorrect folder name and structure as requested will lead to a penalty of -2 each.
• README.md (report) over 500 words limit will lead to a penalty of -1 per word.
• Fail to add both module convenors into the GitLab remote repository where assessment is impossible
will result in 0 mark for the coursework.
5 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. If you are unclear about
this process, please discuss with the module conveners during the computing lab sessions or at the end
of lecture sessions.
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.
7 Q & A
If you have any questions, you are always welcome to post your questions using “Question Form”.
Bryan and Heng Yu will try to response quickly and give high-level interim formative feedback via email
or FAQ. Always refer to FAQ doc provided, as there will be a lot of useful tips and answered questions.
REMINDER We are however might refuse to answer very detailed technical questions, or very general
questions like “What do you think about my project so far?”, “Is this count as creative addition?”. Please
make your own judgement and perhaps perform self-evaluation if the addition is creative.
Have Fun, Code Well, All the Best!
UNIVERSITY OF NOTTINGHAM NINGBO CHINA, SCHOOL OF COMPUTER SCIENCE 4
https://ieeeauthorcenter.ieee.org/wp-content/uploads/IEEE-Reference-Guide.pdf
Criteria Fail Very Poor Poor Good Very Good Excellent Exceptional
Git Use [15%] [ 0% ]
No evidence of
git repository
set up on this
project.
[ 1% – 2% ]
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.
[ 3% – 4% ]
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.
[ 5% – 7% ]
Remote git repository is
set up with basic usage
evidenced. Local reposi-
tory is found with basic
commitment and basic
explanation. The pur-
pose use of git is pre-
sented briefly.
[ 8% – 11% ]
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.
[ 12% – 13% ]
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.
[ 14% – 15% ]
Remote git repository is set up with
rich set of usage evidenced. Local
repository operation is found with
high commitment and stunning ex-
planation, branching is used exten-
sively. Git work flow is clearly ex-
plained, demonstrated professional
way of exercising git tool for
software development and mainte-
nance, satisfying the aim of this
module.
Refactoring
[40%]
[ 0% ]
No evidence of
code refactor-
ing presented
in this project.
[ 1% – 5% ]
There is little
evidence that
code refactoring is
presented with no
significant improve-
ment made to the
project.
[ 6% – 15% ]
There is some evidences
that relevant code refac-
toring principles have
been incorporated into
the project, including
JavaFX. At best, there
are loose principles.
[ 16% – 25% ]
Evidence of refactoring
with at least few com-
plete different OO de-
sign patterns and princi-
ples documented, includ-
ing JavaFX GUI, but
largely lacks precision
and citations.
[ 26% – 30% ]
Code refactoring shows ev-
idence that aligned with
JavaFX MVC design pattern
and at least THREE different
OO design patterns, but
terminology may be imprecise.
Some key concepts may be
missing and/or some of the
refactoring may be incorrect.
[ 31% – 35% ]
Code refactoring shows signif-
icant evidence that were sup-
ported by the JavaFX MVC
GUI design pattern and at least
FOUR different OO design pat-
terns. Your terminology may is
precise and correct. Appropriate
references have been used.
[ 36% – 40% ]
The majority code refactoring prin-
ciples are justified by appropri-
ate citations with JavaFX MVC
GUI design pattern and FIVE or
more different OO design patterns.
Those patterns are clearly articu-
lated, use precise terminology, and
cite appropriate source.
Additions
[20%]
[ 0% ]
None addi-
tions of game
features doc-
umented or
presented in
this project.
[ 1% – 4% ]
Some detailing that
hint towards addi-
tional game features
with little-to-none
explained.
[ 5% – 9% ]
Some detail and expla-
nation of very small ad-
ditional game features.
Poorly explained.
[ 10% – 12% ]
Basic additional game
features are imple-
mented and meet the
requirements. The
additions are evaluated
based on difficulty and
complexity.
[ 13% – 15% ]
3+ additional game features
are nicely implemented.
Clearly explained but poorly
reasoned/justified. The addi-
tions are evaluated based on
implementation difficulty and
complexity.
[ 16% – 18% ]
4+ additional game features im-
plemented and well justified.
The additions are evaluated
based on implementation diffi-
culty and complexity.
[ 19% – 20% ]
5+ additional game features are im-
plemented which demonstrates cre-
ativity beyond expectations. All
are well explained and justified.
The additions are evaluated based
on implementation difficulty and
complexity.
Documentation
[15%]
[ 0% ]
No documenta-
tion is provided
in this project.
[ 1% – 2% ]
Little-to-no high
level diagram
is provided and
package informa-
tion is missing.
README.md and
Javadocs are cre-
ated, but with low
commitment, qual-
ity, lack of justified
explanations.
[ 3% – 4% ]
High level class dia-
gram is provided, but in-
sufficient package infor-
mation. README.md
and Javadocs are created
with moderate commit-
ment but a number of
quality issues exists, in-
cludes poor explanations
of parameters and meth-
ods.
[ 5% – 7% ]
High level class diagram
is provided with package
information, but with er-
ror(s). README.md
and Javadocs are cre-
ated with high commit-
ment, including explana-
tions of parameters and
methods, but with er-
ror(s).
[ 8% – 11% ]
High level class diagram
is provided with organized
and justified package in-
formation, but with minor
error(s). README.md and
Javadocs are created with high
commitment, well explained
and justified with organized
format, but with minor
error(s).
[ 12% – 13% ]
High level class diagram is pro-
vided with clear explanations
of package information and pre-
sented in appropriate layout.
README.md and Javadocs are
created with high commitment,
all codes are with clear explana-
tions, justified and show consis-
tency in the project with orga-
nized format. Basic test cases
are presented with error(s).
[ 14% – 15% ]
The high level class diagram is pro-
vided in professional and considered
manner with high quality package
information. Javadocs is presented
with stunning explanations, cor-
rect format and identical quality
with online Java API documenta-
tion. High quality of README.md
with clear illustrations and orga-
nized format. Test cases are pre-
sented in organised manner.
Video [10%] [ 0% ]
No video sub-
mitted on this
project.
[ 1% ]
Video showed with
no explanations.
[ 2% – 3% ]
Insufficient and lack of
informative contents
presented in the video.
[ 4% – 5% ]
Meaningful information
and small references of
improvements presented
in the video but no text
and/or no audio expla-
nations.
[ 6% – 7% ]
Informative contents with rel-
evant references of improve-
ments presented, but with no
text and/or no audio explana-
tions.
[ 8% – 9% ]
A moderate quality of game
demonstration and relevant ref-
erences to improvements in the
video, supported with text and
audio explanations.
[ 10% ]
A wealth of high quality, impactful
of game demonstration and relevant
references to improvements, sup-
ported with text and audio explana-
tions. Video contents not lengthy,
straight to the points with clear and
appropriate pronunciation.
555
Introduction
Assessment
Deliveries
Important Notes
Plagiarism
References
Q & A