CFS2160 软件设计

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-
4. 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
5. days, contact the School’s Guidance Team. ([e-mail]), 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:
4. 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.).
5. 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”.
6. 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.
7. 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.
   WX：codehelp