代做CFS2160设计程序、Python，C++，Java编程语言代写

日期：2021-03-14 03:33

THE UNIVERSITY OF HUDDERSFIELD

School of Computing and Engineering

ASSIGNMENT SPECIFICATION

Module details

Module Code CFS2160

Module Title Software Design and Development

Course Title/s MEng/BSc Software Engineering, MSci/BSc Computer Science,

MComp/BSc Computing, BSc Computer Science with..., BSc

Computer Systems Engineering

Assessment weighting, type and contact details

Title Coursework 2: Developing a Full Program

Weighting 50%

Mode of working for

assessment task

Individual

Note : if the assessment task is to be completed on an individual

basis there should be no collusion or collaboration whilst working on

and subsequently submitting this assignment.

Module Leader Ilias Tachmazidis Contact details:

Submission and feedback details

Hand-out date 18 January 2021

How to submit your

work.

Via Brightspace (to be automatically checked by TurnItIn)

Submission date/s and

times

04-05-2021 23:59 BST

Expected amount of

independent time you

should allocate to

complete this

assessment

30 hours, including time spent in practicals for the module

Submission type and

format

A ‘zip’ file (or similar) containing the software developed and an

accompanying report. Details below.

Date by which your

grade and feedback will

be returned

25 May 2021

4

Additional guidance information

Your

responsibility

It is your responsibility to read and understand the University regulations

regarding conduct in assessment.

Please pay special attention to the assessment regulations (section 4) on

Academic Misconduct.

In brief: ensure that you;

1. DO NOT use the work of another student - this includes students from

previous years and other institutions, as well as current students on the

module.

2. DO NOT make your work available or leave insecure, for other students to

view or use.

3. Any examples provided by the module tutor should be appropriately

referenced, as should examples from external sources.

Further guidance can be found in the SCEN Academic Skills Resource and UoH

Academic Integrity Resource module in Brightspace.

If you experience difficulties with this assessment or with time management,

please speak to the module tutor/s, your Personal Academic Tutor, or the

School’s Guidance Team.

Requesting a

Late

Submission

You are reminded to ‘back-up’ your work as late submission requests will not

be given for lost work, which includes work lost due to hardware and software

failure/s.

Late submission requests will only be approved if you can demonstrate

genuine, unexpected circumstances along with independent supporting

evidence (e.g. medical certificate) that may prevent you submitting an

assessment on time.

Submit your request for Late Submission via MyHud/MyStudies within 2

working days of the due date.

Late submission requests, up to a maximum of 10 working days, but typically 1-

5 working days, will be considered provided that there is appropriate evidence

which clearly indicates reasons for the request.

You will have 5 working days after submitting a request to provide the

evidence. Failure to submit evidence will result in the request being rejected

and your work being marked as a late submission (see below).

If you are unable to submit work within the maximum late submission period of

10 days, contact the School’s Guidance Team. (sce.guidance@hud.ac.uk), as

you may need to submit a claim for Extenuating Circumstances (ECs).

4

Additional guidance information

Extenuating

Circumstances

(ECs)

An EC claim is appropriate in exceptional circumstances, when an extension is

not sufficient due to the nature of the request, or it concerns an examination or

In-Class Test (ICT).

You can access the EC claim form on the Registry website; where you can also

find out more about the process.

You will need to submit independent, verifiable evidence for your claim to be

considered.

Once your EC claim has been reviewed you will get an EC outcome email from

Registry. If you are unsure what it means or what you need to do next, please

speak to the Student Support Office – Room SJ1/01

An approved EC will extend the submission date to the next assessment period

(e.g July resit period).

Late

Submission

(No ECs

approved)

Late submission, up to 5 working days, of the assessment submission deadline,

will result in your grade being capped to a maximum of a pass mark.

Submission after this period, without an approved extension, will result in a 0%

grade for this assessment component.

Tutor Referral

available

NO

Resources • Please note: you can access free Office365 software and you have 1 Tb

of free storage space available on Microsoft’s OneDrive – Guidance on

downloading Office 365.

4

Coursework 2: Developing a Full Program

1. Assignment Aims

To develop skills in modelling using UML.

To develop skills in defining classes.

To develop skills in writing programs.

To develop skills in testing programs.

To demonstrate the need to document software.

2. Learning Outcomes:

This assignment addresses all learning outcomes for the module.

3. Assessment Brief

You are required to design, implement, test and document a Java program (set of classes) for one (1)

of the following problem specifications:

Problem 1 - Supermarket Checkout Simulation

A large supermarket chain would like a simulation of their checkout system for training and

development purposes. You will need to define classes to represent the checkout system. You

should try to design your system and the classes that you will need before starting coding.

Your simulation must have a graphical user interface to display the state of the checkouts at all

times.

To obtain a bare pass your checkout simulation should:

• Include a minimum of two checkouts

• Include of list of products (for simplicity no more than 10 are required) that can be “scanned” with

appropriate product code, description, and price

• Enable items to be “scanned” using the product code

• Keep track of the total cost of items “scanned” for each customer

• Enable goods to be paid for in cash

• Print out a list of items “scanned”

To gain a higher mark you will need to implement some extensions to your checkout simulation.

Some suggestions might be:

• The facility to have more than two checkouts in the system i.e. an arbitrary number of checkouts

• The facility to have different types of checkouts such as 10 items or less, cash only etc.

• Enable the system to keep track of total payments made by all customers

4

• The facility to pay for goods by credit card

• A loyalty card

• Stock control

Problem 2 - Who wants to be a Zillionaire?

The problem is to define classes suitable for playing a game of ‘Who Wants to be a Zillionaire’. This

game is a cross between the successful TV quiz shows ‘Who Wants to be a Millionaire’ and

‘Mastermind’. Players choose a category on which to answer questions. Questions are of a multiplechoice

nature with the answer being one of four possibilities. If the player answers the question

correctly an amount of ‘money’ is credited to that player. Questions have a difficulty level according

to the amount of ‘money’ players are awarded for answering that question correctly. The questions

are asked in ascending order of difficulty and, therefore, value. Players take turns to answer

questions. If a player cannot answer a question, help is available as follows:

• Ask the Public. This involves a simulation of each possible answer being given a rating according to

the likelihood that it is the correct answer. Ratings for all four possible answers must add up to 100%

in total.

• Half-and-half. Two of the possible answers are removed leaving only the right answer and one wrong

answer.

Players are only allowed to use each help facility once per game. If a wrong answer is given that

player is out of the game. The winner is the player with the most money credited at the end of the

game.

To obtain a bare pass your game should have most of the following functionality:

• Allow two players to play the game

• Include a selection of questions that players could be asked

• Allow a player to choose the category of each question (for simplicity have three categories, one of

which should be general knowledge)

• Display a question at random from the available questions

• Provide a facility for the player to enter the answer to each question

• Inform the player whether the answer is correct, or not

• Keep track of the amount of ‘money’ credited to each player

• Implement the help facilities

• Allow a player to win

To gain a higher mark you will need to implement some extensions to your game. Some suggestions

might be:

• Allow more than two players to play the game.

• Facility for easily adding extra questions.

• Add another help facility, e.g. ‘Give us a Clue’.

• Ensure that the same question is not asked twice in any one game.

• Include the use of sound or animation to make the game more interesting.

• Display the ratings for ‘Ask the Public’ in graphical format e.g. a bar chart.

4

Getting started: You will need to identify the use cases and define classes to represent the problem

you have chosen to implement. In addition, your system must include a graphical user interface

showing the state of the system at all times. This interface must be written using JavaFX. You

should try to design your user interface and the classes that you will need before starting coding.

When you are ready to begin coding start with a basic program that has a very simple user interface

and some of the simpler functionality to obtain a pass. When this is working properly improve the

user interface and try implementing some of the more complex functionality. Finally, add one or

more extensions to gain a better mark.

Remember that the extensions given are just suggestions, and you do not need to implement them

all (or indeed any of them, if you can think of some of your own) to gain a high mark. However,

there is no limit to the extensions you can implement; the only limit is your imagination (and

programming skills!).

Formative Feedback: You are invited to submit for formative feedback a one-page use-case diagram

and a one-page class diagram of the design of your software. These should be as complete as

possible and so the use-case diagram should show the actors and associated use cases, and the class

diagram should show fields, methods, visibility etc., as well as relationships between the classes.

Bring your diagrams to any practical class before March 8, 2021.

Final Submission: By the deadline of 04-05-2021 23:59 BST, you must submit:

1. An electronic copy of your classes (including test classes). Electronic copies should be within an

IntelliJ project. All code should be professionally written (including comments and indentation, use

of sensible variable names, etc.).

2. An electronic report that includes:

• The final design documentation for your system, to include as a minimum a one-page use-case

diagram showing the actors and associated use cases and a one-page class diagram of the design of

your software. Note that this should be an updated version of the diagrams you presented for

formative feedback, improved to take into account any feedback received or any changes made as the

software has been implemented. This design documentation should be produced using the Visual

Paradigm UML modelling software. You should also include brief notes (maximum of 500 words) to

explain your design.

• A test plan showing the application tests that you have used. This could include the use of JUnit

Testing where appropriate, along with full system testing. You should include a list of test cases,

based upon the system requirements. Examples might be to ‘Scan an item’ in the supermarket

checkout simulation program, or to ‘Start a Game’ in the ‘Who wants to be a Zillionaire?’ game. You

should include all the test cases you can think of along with a pass/fail indicator to say whether your

software passes that particular test (the obvious implication here being that you need to list test

cases for features that do not actually work). You should also include screen shots of your software to

show how it works as you perform these tests. These screen shots should provide a ‘walk through’ of

the software.

How and where to hand in: Please create a folder labelled with your student ID and name (e.g.:

LastName_FirstName_u1234567). Place your IntelliJ project in this folder with your report.

4

Compress the folder using standard compression software and submit the compressed file

(preferably a ‘zip’ file) to Brightspace. There will be a link for this under “Assessment”.

4. Marking Scheme

The reports will be marked as follows:

• the UML models will be assessed for completeness, correctness, and adherence to UML standards,

and will contribute 30% of the marks for this assignment

• the testing will be marked on completeness and correctness (including tests to show what does not

work - this is essential) and will contribute 30% of the marks for this assignment.

• the submitted code will be examined and assessed on completeness, correctness, code quality and

adherence to software development standards, and will contribute 40% of the marks for this

assignment.

A marking sheet for this will be made available to students via Brightspace in advance of the

submission date.

5. Grading Rubric

The following grade descriptors give an idea of the standard of work required to achieve each grade:

Grade A (70%+)

The code will be complete, well written, well-structured according to object-oriented principles, and

reliable. It will be accompanied by high quality and accurate UML documentation and thorough

testing. The software will perform all core requirements and a significant number of additional

requirements and will have a high-quality user interface.

Grade B (60-69%)

The code will be mostly complete, well written, well-structured according to object-oriented

principles, and mostly reliable. It will be accompanied by good quality and mostly accurate UML

documentation and detailed testing. The software will perform all core requirements and some

additional requirements and will have a good quality user interface.

Grade C (50-59%)

The code will be mostly complete, well written, well-structured according to object-oriented

principles, and mostly reliable, but may have a few minor bugs or functional omissions. It will be

accompanied by good quality and mostly accurate UML documentation and reasonable testing. The

software will perform almost all core requirements and at least one additional requirement and will

have a reasonably good user interface.

4

Grade D (40-49%)

The code will perform the majority of the core requirements but will have few if any additional

features. The structure and quality of the code will be sub-optimal but workable. The report may

have errors and omissions but will at least attempt to provide a usable UML model and some testing.

Grade E (30-39%)

The code is buggy and does not provide a usable proof of concept implementation. The report is

incomplete and/or has significant errors in the models and the testing.

Grade F (0-29%)

Very poor attempt with no working software and a poor report with significant errors and omissions.

Grade U (0%)

No work submitted.