G6046代做、Software代写、代做Java语言、Java程序设计调试

日期：2020-08-01 11:19

Software Engineering G6046 resit coursework specification

Due date Monday 24 August 2020 by 4PM

Submission format Electronic submission only via Canvas. Please ZIP all your files together

into a single ZIP archive and upload that ZIP onto Canvas. Ensure that

your ZIP file unpacks correctly before submission and that it contains

all the work for your submission. For text documents please use Word

or PDF file formats only.

You MUST include your codebase in your submission. Do not include

links to GitHub or other code repositories.

1) Introduction

This resit coursework is an individual project. You have been provided with some basic starter code,

written in Java, loosely based on the “World of Zuul” adventure. This is a simple game that allows

you to navigate a series of rooms in a game world. The starter code provides the basic ability to build

a game world and navigate it using simple text commands like “go north”. To start the basic game,

instantiate an object of the Game class and invoke the play() method. Your task is to build upon

this basic game and increase its functionality to make the game more complex and interesting to

play, and to use good Software Engineering principles to create a well-designed, documented and

properly tested program that can be easily understood, adapted and worked upon by other

developers.

You will need to:

• Develop an appropriate software design, expressed using an appropriate combination of

high and low level design techniques including class diagrams, use case diagrams and

sequence diagrams.

• Write the software. You have been given some starter code written in Java. You are

expected to develop the software further in Java. You can implement your work in another

language, but you must obtain the agreement of the course convenor before doing so, and

you should be prepared to explain why you wish to opt for an alternative language. In

general, it is likely that it will be harder to complete this resit coursework if you do not work

in Java. The software will ideally require some kind of Graphical User Interface, but this is

not a core requirement, and your focus should be on demonstrating your understanding of

the broader Software Engineering principles, and on meeting the deliverables as set out in

this document.

• Develop a test plan for the software, both at a unit testing level and at a system level, to

demonstrate that your software meets all the user requirements set for it.

• Write a short report to document the work that you have done.

• Give a demonstration of your completed software system.

Assessment criteria for this resit coursework project can be found at the end of this document. The

assessment criteria will focus on:

• The quality of your software engineering skills.

• Your ability to deliver a project that meets the stated system requirements.

• Your ability to deliver a working and reliable software system.

2) World of Zuul

The starter code that you have been given is a modified (simpler) version of the base code for

popular “World of Zuul” game first conceived by David Barnes and Michael Kolling. The starter code

can be downloaded from Canvas. You can also find out more about World of Zuul online, and in the

classic Barnes and Kolling books “Objects first with Java” (https://www.bluej.org/objects-first/).

3) System requirements

Your task is to enhance the starter code to make the game fuller and more interesting. The system

requirements for this enhanced game are as follows:

Functional requirements (“Shall”: mandatory, “should: desirable”)

F1 The game shall consist of new fewer than 12 separate room spaces, linked together

by exits that allow the user to navigate between rooms using either text based

commands or a simple direction button driven graphic user interface.

F2 Each room space shall fall into one of the following categories: a room with one or

more objects in it, a room with an enemy character that must be defeated, a

corridor, or an endpoint that the player must reach to win the game.

F3 No fewer than 3 rooms shall be equipped with locks such that the player may only

enter them after picking up a key game item.

F4 The player shall be able to issue commands that permit travel in the direction north,

south, east and west. The ability to travel in each direction shall be determined by

the connectivity of the room spaces.

F4 No fewer than 6 rooms shall contain in game items. In game items shall include keys

(required to unlock room spaces), swords (to fight an enemy character), a spell (for

example to make an opaque object visible) or a health pack (to restore health after

fighting an enemy).

F5 The player shall start with 100 health points. Each time the player makes a move

the health points shall be reduced by 1. Fighting an enemy shall cause loss of health

points, depending on the nature and strength of the enemy character.

F6 The game shall end (as a loss) is the player’s health points falls to 0.

F7 The player shall be able to issue commands that permit them to pickup game

objects and carry them in a personal inventory (backpack). An item may only be

used when it is in the backpack. Once a game object has been used, it must be

removed from the backpack inventory.

F8 When objects are put down in a room, they must persist in that room space, such

that they remain where they were last placed by the player.

F9 The player shall be able to issue commands to examine game objects before

choosing to pick them up.

F10 The player shall be able to issue commands to review the contents of the backpack

inventory.

F11 The player shall be able to issue commands to use game objects such as spells and

weapons. The nature of these spells and weapons and their role in the overall game

play is left as choices for the developer.

F12 The game shall be completed when all rooms have been explored and all enemy

characters have been defeated.

F13 A “back” command should be available such that the player moves back to the last

room space occupied.

F14 A map option should be developed such that the layout of the room space is

revealed to the user graphically as the room spaces are explored.

Non-functional requirements (“Shall”: mandatory, “should: desirable”)

NF1 The software shall be written in Java (note comments in section 1)

NF2 The software should be playable either by text command entry or by simple button

driven graphical user interface.

NF3 The software should have a simple button driven graphical user interface. Each

command should have its own button that becomes active when the corresponding

activity is permissible. For example, a pickup button should only become active

when there is an object in the current room that can be picked up.

NF4 Any graphical user interface shall present a simple single frame graphical

representation of the current room.

NF5 The game should offer multi player user experience such that each player takes it in

turns to move and has their own backpack.

You should refer back to these requirements when you are developing an appropriate set of system

level tests. Remember, the job of testing is to demonstrate that software if “fit for purpose”. This

can be defined as when the software meets all of the system requirements set out for it.

4) Other requirements

You may further extend the game in any way you consider appropriate, but your main objective

should be delivering a piece of software that meets the system requirements set out in the previous

section. You may obtain feedback on the work and requirements at any time by emailing the course

convenor.

5) Deliverables

Submission will be via the Esubmissions system on Canvas. You will need to produce:

• A project log: This should document the work that you did. The log should record what you

did and achieved for each substantive working day that you spent om the project. The log

entries do not need to be detailed, but they should record important decisions made, and

key achievements. An example log might read as follows:

“26 June: decided that a new class BackPack was required. Identified key attribute

sand methods for this class. Updated the class diagram to v2. Started to implement

the new BackPack class – needs another day of coding. Decided to implement 6

unit tests for this class.”

The purpose of this project log is to demonstrate that you made a proper sustained effort

through the duration of this resit coursework.

• A design document: documenting both high level and low level designs of your software

systems. Such a document MUST include a full class diagram and UML use case diagram,

with descriptions of any new classes that you have created as part of your solution, and

should include sequence diagrams to show how your classes and their methods work

together to deliver key use cases.

• The code base: including all non-code files or other data necessary to allow your submission

to be compiled and executed by the assessors. The code should be properly documented

(e.g. using Javadocs), and be commented to an appropriate standard.

• A testing document: showing how you tested the software at both unit test and system test

levels. It is acceptable for bugs and other issues to remain in the software as long as they are

clearly identified, documented and that you have provided appropriate commentary to

explain why they exist and what you would do about them. Your unit tests should

demonstrate that all classes operate in their intended manner, and the system tests should

demonstrate that the software meets the functional and non-functional requirements set

for it.

• A short report: documenting how the project went for you, with a critical analysis of your

performance, and any issues that remain unresolved in your work.

When you upload your deliverables, please use Word or PDF formats for text documents. Do not use

Mac Pages files as these are not widely supported. For code deliverables, please remember to

include any project (e.g. Eclipse, BlueJ), initialisation or other external files your code needs to be

run.. Do not upload files that are in obscure formats. Assemble all of your documents together and

create a single ZIP file with everything inside. Upload the zip file onto the Esubmissions system.

Check that your ZIP file unpacks correctly before uploading it.

You will be also be required to give a short demonstration of your project at the end of the

submission period. This will be an informal demonstration to the module convenor.

6) Assessment criteria

Your submission will be assessed against the following criteria:

Marks Description Evidenced by

5 Project log Notes of progress as a word processed

document.

5 High level design documents UML use case diagram(s)

15 Low level design documents Class diagram, sequence diagrams to validate

classes for all use cases

40 Codebase Full code

10 Code documentation Javadocs annotations, descriptions of all classes,

in line commenting

20 Testing documentation Evidence of unit testing, evidence of system level

testing validated against requirements

5 Short report Word processed document (1-2 sides maximum)

7) Final observations

If you do not understand something, contact the module convenor.

Remember that this is not just a coding assignment. This is a Software Engineering assignment, so

just creating a program, even if it works, is not sufficient to pass. You need to demonstrate that you

have applied Software Engineering principles to design, document and test a piece of software,

And keep regular backups of your work ……. “I lost the USB stick” just doesn’t cut any ice.

Dr Kingsley Sage

Module convenor, G6046 Software Engineering

School of Informatics and Engineering

Khs20@sussex.ac.uk

July 2020

END.