Supplementary Assessment CSC2058 2022-23
Deadline for submission on Canvas: 15:00, Friday 4th 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 real- world 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:
Page 1
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 on- screen 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 2
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 3
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:
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 4
From the ‘Analysis’ chapter of the Module Notes:
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
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
:BookingSystem
User
/Selected : Booking
:Staff selectBooking(id)
*getDetails()
<<destroy>> updateDisplay()
cancel()
confirm()
return 'yes'
Class diagram (analysis model)
Use case realisation (sequence diagram)
P.T.O for an important note and some general instructions.
/Current : Booking
Page 5
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 use- case 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 <<extend>> and <<include>>: 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
Page 6
