FACULTY OF CES Final mark awarded:_____ FACULTY OF COMPUTING, ENGINEERING and SCIENCE Assessment Cover Sheet and Feedback Form 2016/17 Module Code: CS1D461 Module Title: C++ Programming Module Lecturer: Dr Emlyn Everitt Assessment Title and Tasks: Implementing a Chocolate Vending Machine Assessment No. 4 No. of pages submitted in total including this page: N/A Word Count of submission (if applicable): N/A Date Set: 07/3/2017 Submission Date: 31/3/2017 Feedback Date: Either in tutorial or 20 working days after submission Part A: Record of Submission (to be completed by Student) Extenuating Circumstances If there are any exceptional circumstances that may have affected your ability to undertake or submit this assignment, make sure you contact the Advice Centre on your campus prior to your submission deadline. Fit to sit policy: The University operates a fit to sit policy whereby you, in submitting or presenting yourself for an assessment, are declaring that you are fit to sit the assessment. You cannot subsequently claim that your performance in this assessment was affected by extenuating factors. Plagiarism and Unfair Practice Declaration: By submitting this assessment, you declare that it is your own work and that the sources of information and material you have used (including the internet) have been fully identified and properly acknowledged as required . Additionally, the work presented has not been submitted for any other assessment. You also understand that the Faculty reserves the right to investigate allegations of plagiarism or unfair practice which, if proven, could result in a fail in this assessment and may affect your progress. Details of Submission: Note that all work handed in after the submission date and within 5 working days will be capped at 40% . No marks will be awarded if the assessment is submitted after the late submission date unless extenuating circumstances are applied for and accepted (Advice Centre to be consulted). Work should be submitted as detailed in your student handbook. You are responsible for checking the method of submission. You are required to acknowledge that you have read the above statements by writing your student number (s) in the box: Student Number(s): Section B : Marking and Assessment This assignment will be marked out of 100% This assignment contributes to 40% of the total module marks. All coursework marks gained in this module are combined to form an overall element of assessment. In any coursework referral, the overall element will be capped at 40%. Date Set: Submission Date: Feedback Date: Learning Outcomes This assignment addresses the following learning outcome(s) of the module: LO1. To design, implement and test computer programs to solve a range of technical and mathematical problems. LO2. To follow a secure design methodology and promote code re-use. Marking Scheme Marks Available Marks Awarded 1. Implement the chocolate vending machine state diagram 100 Total 100 Section C : Marker’s Feedback See Assessment Criteria and Feedback below. All marks are subject to confirmation by the Board of Examiners   Source (100 marks) Criteria Professional (1st Class) Senior (Upper 2nd Class) Intermediate (Lower 2nd Class) Amateur (3rd Class) Novice (Narrow Fail) Beginner (Fail) Source Code (100 marks) Modularisation & Generalization Elements are written in a way that invites reuse in other projects. The use of design patterns to facilitate program development is clearly demonstrated. Elements are nearly always written in a way that supports reuse in other projects. The use of design patterns to facilitate program development is demonstrated. Components are mostly well planned and implemented. Elements are generally written in a way that supports code reuse. There is some evidence that the use of design patterns facilitates program development. Components exist, but are not well thought out or are used in an arbitrary fashion. Elements are seldom written in a way that invites code reuse. There is little to suggest that the use of design patterns facilitates program development. Little evidence of eneralization or eneralization. Few elements are written in a way that supports code reuse. There is little if anything to suggest that the use of design patterns facilitates program development. No meaningful evidence of eneralization or eneralization is presented. There is little if anything to suggest that the use of design patterns facilitates program development. Design, Structure & Efficiency Program is designed in a logical manner. Control structures are used effectively and correctly. Data structures, algorithms and patterns are implemented efficiently and appropriately. Program is generally designed in logical manner. Control structures are used correctly. Data structures, algorithms and patterns are implemented effectively. Program design is mostly logical. Control structures are used correctly, although more appropriate structures may have been selected. Reasonable data structures, algorithms and patterns are generally implemented. Program isn’t as clear or logical as it should be. Control structures are frequently used incorrectly. Steps that are obviously inefficient are used. Program isn’t as clear or logical as it should be. Control structures are occasionally used incorrectly. Steps that are clearly inefficient are used. No meaningful evidence of logical, efficient or effective decision making in terms of selected data structures, algorithms and patterns. Readability, Consistency & Naming Coding style guidelines are followed correctly, code is exceptionally easy to read and maintain. All names are consistent with regard to style and are expressive without being verbose. Coding style guidelines are followed correctly. Code is generally readable and maintainable. All names are consistent with regard to style and are expressive without being verbose. Coding style guidelines are almost always followed correctly. Code is generally easy to read. Names are consistent in style and expressive. Isolated cases may be verbose, overly terse or ambiguous. Coding style guidelines are not followed and/or code is less readable than it should be. Names are nearly always consistent, but occasionally verbose, overly terse, ambiguous or misleading. Coding style guidelines are not followed and code is less readable than it should be. Names are inconsistent, verbose, overly terse, ambiguous or misleading. Code is generally unreadable, hard to maintain, inconsistent in terms of style and names are poorly chosen. Comments Initial comments are complete. Internal documentation is complete and well suited to the program. Comments clarify meaning where needed. Initial comments are nearly complete. Internal documentation is nearly complete and generally well suited to the program Comments generally clarify meaning where needed. Initial comments are complete but internal documentation is in some small fashion inadequate. Comments usually clarify meaning. Unhelpful comments may exist. Initial comments are incomplete or internal documentation is inadequate. Comments exist, but are frequently unhelpful or occasionally misleading. Initial comments are incomplete and internal documentation is inadequate. Comments exist, but are frequently unhelpful or misleading. Code is generally poorly commented with little regard to expectations. Tasks Make sure you read the following carefully: marks are often needlessly lost by not delivering what was requested. Scenario You work for ChocDispeser LTD, a well-known manufacturer of chocolate dispensing machines. One day your boss comes to you to say that he wants you to develop the firmware for a new chocolate vending machine based on the following diagram: See Appendix A for additional material   Additional Considerations • Your code should implement all the code in in the appendix. No changes should be made to this code • Your code should implement the state diagram as is (e.g. you should not attempt to add or remove states / transitions). • The only libraries you should include are: and (to support the implementation StateContext only). No other libraries should be used. • When submitting your work, please submit your code in a single .cpp file to Unilearn. • Comments are IMPORTANT. If code is not appropriately commented (see code comments section for further details) then many marks will be lost, and a failure to comment can and will result in coursework failure. Please note: failure to meet these requirements will inevitably result in significant marks being lost. Code Comments It is of particular importance that your code is well commented. The comments you make will form your documentation for this assignment and the quality of those comments will contribute significantly to your overall mark. Comments should attempt to describe the functionality of each section of code and how it fits into the overall behaviour of the program rather than just superficially describing what each line of code does in isolation. Submission and Assessment For assessment, you will need to be demonstrated your code during your tutorial slot. You will also need to submit of your code in a single .cpp file called .cpp to Blackboard.   Appendix A