Supplementary Assessment CSC2058 2022-23
Deadline for submission on Canvas: 15:00, Friday 4
th August 2023
What you must submit:
• A short PDF report
• Your application code
• A short video demo
This is an individual project, to be completed by a single student. However, you will be using techniques that, in
future group work, will help you to explain to colleagues your vision of an evolving software system.
Here are the details…
A Short Software Engineering and Systems Development Exercise
Your task is to gamify the process of putting into place at least some of the components of a community
communications network. The working game is one of your deliverables, but it must be based on a credible realworld scenario, even if, to make the gameplay easier to understand, the real-world scenario is simplified and
represented by just some of its key elements.
In your report, you will set out the requirements for the game in the form of a use case diagram and use case
descriptions. You will show how the use cases are to be realised. You will document the design of the software,
showing your classes and their associations, and you will and set out and complete your testplan. The main body of
the report should be no more than 10 pages. Your title page, and any recommended Appendices (see below), do
not count towards the 10-page limit.
Alongside the report you must code and test the game itself. The main logic of the game must be written in Java (it
should contain several software classes). If you choose to give your game a graphical user interface, you may use
Java Swing, JavaFX or another GUI-building toolkit of your choice. The game must satisfy the requirements set out
below.
The Scenario
To better appreciate the scenario on which the game is based, think what you would have to do if you were the
manager of a team whose mission is to create a ‘community network’ and so become an independent Internet service
provider. That means that your community network will be largely independent from the ‘big’ service providers. In this
case the community network is intended to serve the needs of an urban community that was formerly an economic and
industrial powerhouse, but that more recently has suffered social and economic deprivation as heavy engineering has
declined. Many of the members of the community are now refugees and people seeking asylum. Govan, in Scotland, is
such a community. It featured in this year’s Engineering for People Design Challenge
(https://canvas.qub.ac.uk/courses/19149/files/3247272?module_item_id=876007). You can create a solution for
Govan specifically, or for another community – real or imagined – that faces similar challenges. One of the goals of the
community network is to help residents feel more a part of their immediate community and better able to access public
resources and services.
The concept of ‘community networks’ is outlined in the text Telecommunications Reclaimed: A Hands-On Guide to
Networking Communities, which you will find here: https://www.netcommons.eu/sites/default/files/telecomreclaimed-web-single-page.pdf . Telecommunications Reclaimed and other similar reading material are listed on
website of NYC Mesh, where you will find many practical tips on how to start a community network ‘in the real world’:
https://www.nycmesh.net/blog/how/. At least some of the steps of setting up, launching and maintaining a real
community network should feature in your game.
Page 2
The requirements of the game.
Your game will concentrate on this goal: creating a successful community network.
Conceptually your game will be a boardgame, but it can be a game with fewer squares than the boardgames with
which you might already be familiar. Movement around the board will be determined by the roll of a virtual die or dice.
Each square will represent part of the network solution – e.g., acquiring permissions to install the network; acquiring
and installing network hardware; acquiring and making available end-user equipment; informing and educating
members of the community so that they can access the network and use it safely and productively. Each part of the
solution is completed over a number of steps.
The game can be played by one or more players. When they land on a square, players have the opportunity to
contribute to the task that the square represents. They contribute with whatever resources are appropriate – that
might be money, expertise, time, or some combination of these. By contributing to a task, they help move the task a
step closer to completion. There is a square on which players collect resources – decide what this square would
represent in the real world and give it an appropriate name. When all the tasks are completed, the game ends and
there are suitable on-screen celebrations. If one player runs out of resources, the game ends for all players, and there
are suitable on-screen commiserations. As developer, you decide whether your game is played ‘text-only’ through the
console of the development environment, or whether you will give it a graphical user interface (GUI, see below also).
Whichever you choose, you must ensure that the events of the game and the state of play are conveyed clearly to the
players of the game.
As well as the basic functionality described above, you should aim to include some value-added features. These could
include some of the following, but you might be able to devise some very original value-added features of your own:
- a facility that writes to a text file a neatly formatted record of the steps that were taken on the path to
completing the community network;
- an attractive graphical user interface that might encourage people to use the game as a teaching aid in the
real world;
- a text user interface that prompts players, and lets them formulate their responses, in a very natural,
conversational manner, so that that the process of building the community network ‘comes to life’.
Deliverables
The Working System (30%)
When you have completed your application, upload the following to the Assignment links on Canvas
• Your application code (export your Java project code to a zip archive and upload the .zip file);
• A short video (maximum five minutes; with commentary; MP4 format) showing your application in action.
o While professional production standards are not expected, make sure to show in your video that the
basic functionality and your most important value-added features are working; ensure that any onscreen text is clearly legible. Only the functionality that you show working in the video will be
assessed. (See also the important note on the Video Demo at the end of this document.)
o Plan your video, so that you capture footage at, and in the lead-up to, key moments: you are likely to
omit important detail if you simply start recording ‘in real time’ and wait to see what happens within
five minutes!
o Show the working system in your video – do not spend time showing or discussing lines of code (they
are already in your code upload), and do not provide commentary while showing screens that say
‘welcome’, ‘thank-you’, etc. (that is not showing the application in action).
The working system will be assessed on the correctness and complexity of the interaction it manages, the clarity of its
interface (whether text-based or GUI), the extent to which the working system matches the accompanying
documentation (see below), and the excellence of the value-added features that it offers.
Page 3
The Short PDF Report (70% - made up of the sections detailed below)
Also upload to Canvas your short PDF report. The main body of the report should be no longer than 10 pages (10
pages is the limit, not the target!). Please ensure that your name and student number are included in the header of
each page. As well as your name and student number, please also include on the cover page the declaration that
you will find on the next page. The cover page does not count towards the 10-page limit.
The report should include the following 4 sections…
1 Requirements Documentation (30%)
• A short statement (about half a page) outlining the main features of the real-world solution (equipment,
expertise, processes, etc.) on which your game is based.
• A written use case description for each use case that your game will cover. This is a very simple game. It is likely
to have a very small number of use cases. See the important note on use cases on page 6.
• A UML use case diagram representing your use cases, their relationship to the actor(s), and any relationships
between the use cases.
2 Design Documentation (20%)
• A class diagram: a representation in the UML of the main classes of your game and the relationships between
them – with brief comments.
• A sequence diagram or diagrams: a representation in the UML of the messages within and between the main
classes of your game – with brief comments explaining how each sequence supports the intended functionality.
Show the realisations of your most important use cases and make sure to identify the use case(s) that each
sequence realises.
• If you have built a graphical user interface (GUI), you are not expected to show the fine detail of the GUI classes,
their associations, or the sequences of calls that they make to each other or with the wider system.
• See the important note on diagrams at the end of this document.
3 Implementation-Related Documentation (10%)
• A testplan: a documented set of tests that provides evidence that your game works as intended. If there are too
many tests to include in the main body of your report, you may continue them in an appendix (at the end of your
PDF report). The appendix does not count towards the 10-page limit for the report. See ‘Chapter 6 – Software
Verification’, Slide 50, for a suggested lay-out for black-box-style acceptance tests. If you have used automated
unit tests (JUnit tests), you may include (in the appendix) screen dumps of successful test runs. Coded JUnit tests
are ‘self-documenting’ – you do not have to describe the logic or purpose of each JUnit test in your report.
4 Adherence to Process (10%)
• Describe briefly how you went about developing your game, justifying your approach with reference to
established approaches to development (see Chapter 2 - Software Process). It is likely that you will have adapted
these approaches to suit a one-person project. For example, instead of a daily stand-up, you might want to
include (again in an Appendix, which does not count towards the 10-page limit) a weekly personal log: ‘What did I
do last week? What will I do this week? Is anything blocking my progress (and what are the possible solutions that
I need to investigate)?’
• Describe secure (or assured) system features that are relevant to your game. You can describe secure features
that you have already built into your game, or that would be needed if your game were made available to the
public, or that would have to be considered if the community network that the game represents were to be
implemented in the real world. For example, how would you educate prospective end-users (customers,
members of the community) about good practice when using web-based systems and resources?
• Include a Gantt chart – which should be readable at a glance – that shows the main timelines in your
development.
P.T.O for the important declaration that must be included on the title page of your report.
Page 4
To be included on the title page of your report:
Declaration
By submitting the work, which includes both the working system (code and video) and this report, I declare that:
1. I have read and understood the University regulations relating to academic offences, including collusion and
plagiarism:
http://www.qub.ac.uk/directorates/AcademicStudentAffairs/AcademicAffairs/GeneralRegulations/Procedures/Pr
oceduresforDealingwithAcademicOffences/
2. The submission is my own original work and no part of it has been submitted for any other assignments, except as
otherwise permitted;
3. All sources used, published or unpublished, have been acknowledged;
4. I give my consent for the work to be scanned using a plagiarism detection software.
P.T.O for some useful examples of the diagram types you might use in your report.
Page 5
From the ‘Analysis’ chapter of the Module Notes:
A sample use case description A sample use case diagram
From the ‘Software Project Management’ chapter of the Module Notes – a sample Gantt chart:
From the ‘Software Design’ Chapter of the Module Notes
Class diagram (analysis model) Use case realisation (sequence diagram)
P.T.O for an important note and some general instructions.
Flow of Events for the Select Element use-case
Objective To select an element in the workspace
Precondition There is an active diagram containing at least 1 element
Main Flow 1. The user selects the selection tool (if necessary)
2. The user moves the cursor over an element
3. The user presses the mouse button
4. The element becomes selected and the control points
are displayed
5. The user releases the mouse button
Alternative
Flows
At 3, there may not be an element. In this case no
element is selected
At 3, the element may already be selected. In this case, it
remains selected
Post-condition The element is selected and its control points are
displayed
User
:Staff :BookingSystem selectBooking(id) /Current : Booking
*getDetails() cancel()
confirm()
return 'yes'
/Selected : Booking
<> updateDisplay()
Page 6
An Important Note on Use Cases
Very important: each use case is represented as a single ellipse in a use case diagram, and each use case is a complete set
of sequences of actions in itself. For example, a single use case might describe everything an actor does in order to
Register with a system: enter first name, enter family name, enter DOB, enter house number, etc., etc. (note: this will not
necessarily be one of the use cases in your ‘community network’ project!). All those steps are represented by a single use
case and a single ellipse. An ellipse in a diagram contains the name of a use case. The corresponding use case description
describes what the sequence (flow) of actions would normally be to achieve a desirable outcome, which is the whole point
of the use case! For example, if the Register use case executes successfully, the actor will have become a registered user of
the system – that is the desirable outcome. However, the description of the Register use case should also say what
alternative sequences (flows) are needed at particular steps under certain circumstances – what happens, for instance, if
an actor enters an exclamation mark for the house number during registration! In other words, the use case descriptions
convey much more information than the ellipses in the diagram. Several use cases (several ellipses) will typically appear in
a single use case diagram. Each ellipse represents a use case. Each use case must have a description. Never use a usecase ellipse to represent a single step in a chain or sequence of steps. A single ellipse IS a set of sequences of steps –
normal flow and alternative flows – that achieves some important outcome! So aim to have few rather than many ellipses
in your diagram: each ellipse represents a use case, and each use case requires a description of the steps it involves! There
are no bonus points for a jumble of ellipses. An ellipse without a description is pointless. Decide the important outcomes.
Name the use cases accordingly. Describe the use cases carefully. Remember also that, apart from generalisation, the
only relationships that are shown on the diagram between use cases are <> and <>: these relationships
imply that one use case is extended by another or includes another as actions take place in real time. If a use case must
have occurred at some time in the past before another use case can occur, then the first use case is a precondition of the
second: this information is conveyed in the use case descriptions, not in the diagram! On the diagram it is possible to have
a use case that has a connecting line to an actor but that does not have an arrow from or to another use case.
General Instructions for the PDF Report – including diagrams
Each report should be in A4 format, except where a diagram or chart requires a larger page size for greater legibility. For
the main text, use at least point-size 10 and a standard typeface such as Calibri or Times New Roman. Do not hand-draw
charts or diagrams. Choose content carefully to convey the most important aspects of your system and its development
process. Make especially sure that the diagrams in the PDF version of your report can be clearly read – that includes
any text that the diagrams contain (class names, attribute and method names, etc.). Providing clear diagrams is a sign
of good report writing.
An important aspect of this module is that it allows you to exercise discernment – the ability to exercise good judgement.
In your report you are not being asked to document every conceivable detail of your game. Rather you are encouraged to
show just the right amount of detail so that it is clear that your game has evolved according to a well-managed process –
and so that someone not directly involved in the development can understand what your game does, how it does it, and
why. For example, a class diagram that is simply generated by a software tool once you have coded your application ‘ad
hoc’ might show impressive detail, but it will not necessarily represent good design, and it will be much more difficult to
follow than a simpler diagram, produced with a basic drawing tool, that shows the most important attributes and
methods in your system – for example, the ones that you’ll reference in your sequence diagrams when you show your use
case realisations. A simpler diagram that indicates you have thought about the problem (rather than click ‘Finish’ on the
Class Diagram wizard in Eclipse once the coding is done), is by far the preferable solution.
General Instructions for the Video Demo
Record your video in MP4 format and make sure that it runs in VLC software – check that it does so by using the software
available at https://www.videolan.org/. Please do not record your video in Full HD or 4K. Professional production
standards are not expected, but please ensure that any on-screen text is legible.