Programming in ‘C’ Course: Assessed Exercise No 1
At the first lecture I discussed the make-up of this course and explained that the course would be assessed by means of a BLACKBOARD exam (worth 30% of the available marks) that has already taken place, this C assignment task (also worth 30%), then in semester 2 some Matlab in-class assessments (worth 10%) and a final in-class C program writing exam (worth 30%).
1 Administrative details
Your program must be handed in via BLACKBOARD. The hand-in date for this exercise is 11.59pm on Tuesday 17th December. You can hand your work in there anytime between now and that date.
• If you believe you have good reason to ask for an extension to this hand-in date, you may discuss the circumstances with Peter Judd and, at his discretion, a later hand-in date may be negotiated. (But please do the discussing well in advance of the original hand-in date expiring). Please note: being disorganised or lazy and so failing to meet the hand-in date by simply leaving tackling the exercise until it’s too late is not a “good reason” and will not normally result in an extension of the hand-in date!
________________________________________________________________________________________
2.0 What your program should do
You have been asked to write a program to process module results (marks) for individual students so that their final end-of-year mark can be calculated and a year-end progression decision (‘pass’ or ‘fail’ the year) can be made. The rules for processing these results are as follows:
Assume that each student must take four modules that are each assessed by a final examination. Students must also take one course work module. Each module is marked on a 100 point marking scale (that is with a possible mark anywhere in the range of 0 to 100, expressed as a whole number only).
Rules for passing a module
A student will ‘Pass’ a module when they have achieve a mark in that module of 40 or higher. Where a module is considered to be a ‘Pass’ then Credits will also be awarded for that module. When a module is considered to be a ‘Fail’ (that is has a mark of less than 40) then no Credits are awarded. Here are all the modules that these students take & their credit weightings:
Table 1: Module credit weighting
It can be seen that the maximum possible credits that a student may obtain is therefore 60.
U:\K9\C\c-19-20\Tutorials\Assessed Exercise No1\assess-1-2019-20.docx [ Page 1 ] (© Peter Judd/University of Sheffield 2019)
For this assessed exercise you are asked to write and submit a program in ‘C’ to carry out the particular task detailed here.
• Late submission will result in a deduction of 5% of the total mark awarded for each working day after the submission date, this is Faculty policy. (Working days – Monday to Friday – include working days within standard vacation times). The only exceptions to this will usually be where illness or other serious extenuating circumstances have meant missing the hand-in date (medical evidence will often be needed to sustain this exception). In such circumstances you MUST submit an Extenuating Circumstances form (not a self-certification form), available from www.sheffield.ac.uk/ssid/forms/circs, (before completing such a form make sure you read the explanatory notes here first: http://www.sheffield.ac.uk/ssid/forms/circsnotes) hand in to the department Student Support Office (Suite 27, level 1, Solly Street building, Solly Street).
Module title
Credits awarded for a ‘Pass’
Maths 1
10
Maths 2
10
Tech. 1
10
Tech. 2
10
Course Work
20
A student’s year-end overall (weighted) average is calculated by adding (summing) their individual module marks together according to their credit value (weighting) and dividing this total by the total number of credits possible (this is known as a weighted average):
Overall _ Average = ∑ (Module _ mark * possible _ credit _ value) max imum _ possible _ credits
Consider the following example:
Subject
Maths 1
Maths 2
Tech. 1
Tech. 2
Course work
Credits Awarded
Overall Average
Mark Awarded
27
56
67
72
82
64.3
Possible Credits
10
10
10
10
20
Credits Actually Awarded
_
10
10
10
20
50
Table 2: Example of possible student results
Overall _ Average = (27 *10)+ (56 *10)+ (67 *10)+ (72 *10)+ (82 * 20) 10 + 10 + 10 + 10 + 20
Overall _ Average = 270 + 560 + 670 + 720 +1640 = 3860 60 60
Overall _ Average = 64.3333 _ recurring
Overall averages must be reported rounded up to just one decimal place after the decimal point (that is: if the second decimal place is ‘5’ or higher, then one is added to the first decimal place) 64.3333 will therefore be reported as 64.3 (as the second decimal place is ‘3’, which is less than 5, so no change is made to the first decimal place) whereas if, for example, the overall average had been 31.054 then it would have been reported as 31.1 (as the second decimal place value here is ‘5’ and therefore 1 must be added to the first decimal place making 31.1).
Rules for deciding overall Year-End Overall Result: Pass or Fail
The year-end progression (overall result) decision regarding whether a student ‘Passes’ or ‘Fails’ the whole
year is made on the basis of both the credits awarded and the overall average. To ‘Pass’ the year a student must obtain:
• an overall average of 39.5 or higher and
• have been awarded at least 40 credits or more and
• the credits awarded must include 20 credits being awarded for course work module – in other words students cannot ‘Pass’ the whole year without also obtaining a ‘Pass’ in course work.
U:\K9\C\c-19-20\Tutorials\Assessed Exercise No1\assess-1-2019-20.docx [ Page 2 ] (© Peter Judd/University of Sheffield 2019)
2.1 Examples
Consider the following example:
Table 3: Example of possible student results 1
Student overall result is FAIL because of not passing the course work module. Another example:
Table 4: Example of possible student results 2
Student overall result is PASS obeying all requirements. Yet another example:
Table 5: Example of possible student results 3
Student overall result is FAIL because credits awarded is less than 40. One more example:
Table 6: Example of possible student results 4
Student overall result is FAIL as overall average is less than 39.5
2.2 Aim of your program:
• Your task is to write a program that would allow the user to enter the individual module marks obtained
by only one student, for all of the modules described in Table 1 above and would then calculate the
U:\K9\C\c-19-20\Tutorials\Assessed Exercise No1\assess-1-2019-20.docx [ Page 3 ] (© Peter Judd/University of Sheffield 2019)
Subject
Maths 1
Maths 2
Tech. 1
Tech. 2
Course work
Credits Awarded
Overall Average
Overall Result
Mark Awarded
56
92
41
76
39
57.2
Fail
Credits Awarded
10
10
10
10
_
40
Subject
Maths 1
Maths 2
Tech. 1
Tech. 2
Course work
Credits Awarded
Overall Average
Overall Result
Mark Awarded
48
72
12
36
41
41.7
Pass
Credits Awarded
10
10
_
_
20
40
Subject
Maths 1
Maths 2
Tech. 1
Tech. 2
Course work
Credits Awarded
Overall Average
Overall Result
Mark Awarded
0
40
0
0
100
40
Fail
Credits Awarded
_
10
_
_
20
30
Subject
Maths 1
Maths 2
Tech. 1
Tech. 2
Course work
Credits Awarded
Overall Average
Overall Result
Mark Awarded
43
40
41
31
40
39.2
Fail
Credits Awarded
10
10
10
_
20
50
Overall Average, Credits Awarded and Year-End Overall Result decision in the ways described
above.
• In addition the program should also show the user which of their module marks is the highest module
mark and which is the lowest module mark obtained by the student being considered.
2.3 What your program should do in more detail:
i. Firstly the program should announce its purpose to the user.
ii. Next the program should prompt the user to enter each of the 5 individual module marks expected (the module titles are as described in Table 1 above) collecting them and storing them appropriately. The program should reject any entry that is not a whole number in the range 0 to 100 and do so in a user- friendly manner.
iii. The program should then display these marks on the screen laid out neatly (you can decide how you would like the information to appear to the user of your program).
iv. Next the program should calculate the Overall (weighted) Average mark for all the module marks entered and display it appropriately on the screen. This result should be presented rounded up to one decimal place after the decimal point as described in section 2.0 above.
v. The program should then work out the Total Credits Awarded.
vi. Next the program should work out the Year-End Overall Result decision (“Pass” or “Fail”).
vii. The program should then display the Module Marks, Overall Average, Total Credits Awarded and Year-End Result as previously calculated as described above (perhaps your display might present the information in a similar way to that shown in Table 3. Above? Please note: there is no need to draw lines around your table or fill table cells with colour, simply neatly presenting the text and numbers in rows on the screen is sufficient).
viii. Your program should ask the user whether they would like the highest module mark obtained by the student and the lowest module mark obtained by the student to be displayed or not, and do exactly that if the user responds positively to that question.
ix. Finally your program should ask the user if they would like to repeat the whole exercise, and correctly interpret the reply. If the answer is in the affirmative (‘Yes’ or similar), then the program should repeat from step ii above, asking the user for new marks.
When designing you program: be careful to ensure that it makes efficient use of variable space by choosing suitable types for your variables that do not waste memory unnecessarily. Don’t just assume this program will only be compiled to run on a windows PC with the Dev-C compiler, make sure you use the smallest ‘C’ type variables necessary according to the minimum sizes I gave for the standard C types in the lectures. Arrays might be useful in this assignment. Also make appropriate use of the various flow-control statements ‘C’ has to offer to build loops where they would be helpful.
2.4
• Your program must be written in ‘C’ and not ‘C++’. (I teach ‘C’ in my lectures, not C++, so sticking to
• By the time this sheet is handed out you will have already covered, in lectures and tutorials, all the material necessary to allow you to write a suitable program. However, future lectures and background reading of your own may be of additional help.
• Make your program code as easy to “read” (by a human) as possible. For example partition it (in other words break it up) by making your own functions. (Programs that consist of everything inside the single
U:\K9\C\c-19-20\Tutorials\Assessed Exercise No1\assess-1-2019-20.docx [ Page 4 ] (© Peter Judd/University of Sheffield 2019)
Some important advice to consider
techniques I have taught will mean you will be OK). Make sure you save your file with a ‘.c’ filename extension NOT ‘.cpp’. When using Dev-C make sure when saving your file that the “Save File” dialogue has the “Save as type” drop-down menu set for “C source files (*.c)”.
function main only will earn fewer marks than programs that are divided into more than one function). (See my example solution to Lab 5 question 4 file TUT5Q4-4.c in the EEE125 BLACKBOARD course, in the ‘Lab Classes’ section, in the ‘Lab Class Downloads’ folder and finally in the ‘Lab Sheet 5 – Downloads’ showing use of functions). Use well-chosen identifiers for function names and variable names so that the purpose of a particular function or variable is hinted by its name.
• Make sure the program is well commented (i.e. using /* */ marks) so that the purpose of each part is clear. These comments should be concise. Note: there is no need to use comments to explain how a particular ‘C’ construct works, you can assume the reader understands the ‘C’ language itself (e.g. you don’t need to explain how a ‘for’ loop works as such). However you should add comments to explain what your program aims to achieve with particular ‘C’ constructs where it isn’t immediately obvious (e.g. explain what useful task a particular ‘for’ loop is performing for you in your particular program). This is an important skill needed by programmers to ensure their program code is ‘readable’ and ‘understandable’ by others who may have cause to examine them or modify them later. I have given clear guidance in the lectures about how to lay out a program and how to add blocks of comments – check your lecture slides to see what I said.
• A well designed program should make it relatively straightforward for some other programmer to modify your program to include more or fewer exams at a later date.
• Don’t forget: planning your program thoroughly on paper first is by far the most effective way of quickly writing a good program. Don’t rush to coding at the PC too soon. Start by breaking the task down into manageable portions, then plan the sequence of events for each portion with flow charts and pseudo code etc. Flow charts in particular will help you identify the appropriate flow control statements (‘while’, ‘do..while’, ‘for’, ‘if’ etc.) to use.
• Test the output from your program by using various sets of data. I have given you some example data and the expected results in section 2.1 above. Don’t forget to check your program’s behaviour with illegal data (i.e. data outside the range defined for input – marks over 100 for example), does it behave appropriately?
• Don’t forget, “divide and conquer” is a wise approach. Break the task down into manageable portions and tackle them one at a time, don’t try and code up the whole program in one go only to find it doesn’t work. The task of finding a fault (or more likely many faults) in a large program is like ‘looking for a needle in a haystack’ – make sure you have only a small ‘haystack’ to search! Start off with a small program which only does the first few steps of the task, get that working first. Next add a bit more to your program and get that working too. Continue in this way until the program can carry out the complete task
• Above all, be sure to hand something in by the deadline. If you examine my marking scheme carefully (see later) you will see that only a small proportion of the marks are available for accuracy of results etc. there are many more marks available for other aspects of the work I ask for. If you only manage to produce a program that asks for, stores and re-displays the input module marks, calculates the overall average but does not even attempt to calculate the Credit Totals and Year_End Overall Result decision then I can at least give you some marks for that much (which is better than no marks if you hand in nothing!)
• If you need help:
a) Please talk to me or my demonstrators during a timetabled computer lab. session.
b) Be sure to make full use of the ‘C’ books in the library and the web links provided in our BLACKBOARD course.
c) Look at the extra advice on BLACKBOARD, look in the folder called “Useful advice from Peter Judd”. I may add more as time goes by.
d) If you still need help, email me to make an appointment to sit down with me “1 to 1″. I have very little free time. When you send such an email be sure to suggest as many time-slots when you could be available to meet as you can, so that I have a good chance of finding a mutually convenient meeting time. Please note: I now only work for the University on Mondays and Tuesdays.
3 What should you hand in?
U:\K9\C\c-19-20\Tutorials\Assessed Exercise No1\assess-1-2019-20.docx [ Page 5 ] (© Peter Judd/University of Sheffield 2019)
3.1 The program itself:
• You should hand you ‘C’ program file itself in via BLACKBOARD (see instructions in section 3.2 below) and it should be in the form of a source file of ‘C’ code (that is the ASCII text file created in the usual way by using the Dev-C++ Editor when writing a program and saved with the filename and the file name extension for C Source Files: “results.c”). You MUST name the file “results.c ” Please use this name only, it helps me process your work quickly. It must not be called “results.cpp”! (*.cpp implies a C++ file and you must not write in C++!)
• You MUST write your Registration number into a comment string as the first line of your program like this:
/* My Reg Number: 190113134 */
#include
…and so on. You are not required to include your name.
• If you choose to write and test your program using a `C’ compiler other than the Bloodshed Dev-C environment provided for you on the University’s Computer network (as used in the tutorial sessions) then I strongly recommend that you bring the final version of your source code into the University and check it compiles and runs correctly using the Dec-C compiler on the University’s Computer network before handing it in. It is this same Dev-C compiler that I will use to compile and test you program in order to assess it!
3.2 To submit your program via BLACKBOARD:
To submit your program via BLACKBOARD follow these instructions (follow them carefully as you only have one chance to submit!):
a) You only have one chance to submit your file, once submitted you cannot change it, so be sure you are finished and have chosen the correct file to submit and attach it correctly.
b) Once you have finished your C source file and you are happy that it is ready to submit it, open a web browser and login in to in usual way.
c) On the “EEE125 Programming” course home page look for the ‘Assessment and Feedback’ section in the left-hand menu.
d) In the ‘Assessment and Feedback’ section of this left-hand menu you should see a heading called ‘Assessment’. Click on this.
e) You should now see an item titled “C Programming Course, Assessed Exercise No. 1”, make sure you click on this title.
f) Scroll down to section “Assignment Submission”. DO NOT use the Create Submission button. Look below and you will see a line beginning “Attach file” and a button marked “Browse My Computer” Click on this. A file browser window should now open.
g) In the file browser window navigate to your folder and select your ‘C’ source file results.c in the conventional way. (Make absolutely sure you are selecting the C source file – the one you typed – not any of the other associated files the compiler generates when you compile and run your program). To do this, look at the icon displayed beside the file name, make sure you pick the file with the icon showing a small blue ‘.c’ in the corner. Double click on your results.c file to attach it. It should now appear in a list of “Attached files”.
h) Once you are sure you have attached your results.c file then scroll to section “4. Submit” at the bottom of the page and you should see the Submit button on the right hand side, click this button to submit your work. Note: You must NOT write anything in the 3. Add Comments box (I will not read it).
U:\K9\C\c-19-20\Tutorials\Assessed Exercise No1\assess-1-2019-20.docx [ Page 6 ] (© Peter Judd/University of Sheffield 2019)
3.3 Marking Scheme
On the next page you will see the marking scheme I will use to mark your work. Initially, as you can see, I will mark in percentages, “full marks” would be 100%.
Aspect
Comment
Mark
Overall Program Design
Does the program try to meet the specification laid out in this sheet? Is it designed to do all of the things asked for?
20
Choice of V ariables
Have variables been created using appropriate types and do they make efficient use of storage space?
5
Quality of `C’ code
Have the many useful ‘C’ language features discussed in lectures and tutorials been exploited? Are the ‘C’ constructs used appropriately?
10
Readability of code
Is the program’s purpose easily understood from the way it’s structured e.g. does it have an appropriate hierarchical form (exploiting functions?). Is it well (concisely and clearly) commented? Have sensible, self explanatory, identifiers been chosen for function names and variable names?
5
Use of Functions
Have user functions other than main been written at all? Are they used sensibly? Is the choice of return types and parameters sensible?
20
Compile & Run
Does the program compile without errors or serious warnings? Does it run without crashing etc?
10
Accuracy of results
Are the results it produces correct?
20
User interface
Does the “user interface” clearly inform the user what she or he must do at each stage? Are the outputs presented clearly and in an appropriate fashion?
10
Total
100
4 Unfair Means
The basic principle underlying assessed work is that the work submitted for assessment must be entirely your own. No one objects to you discussing the principles of C programming in general with others, but: plagiarism and collusion are not allowed. You must not discuss the details of how you will do this exercise with anyone other than Peter Judd or one of his programming lab. demonstrators. In the context of this exercise, unfair means would include:
1 You MUST NOT allow anyone else to write or dictate to you your program, in whole or in part.
2 You MUST NOT look at someone else’s program for this exercise or copy from someone else’s work or exchange emails or internet chat messages (MSM, Weibo, Whatsapp, Facebook or similar) or by sharing your code via file sharing sites (like Postbin or similar) with someone else which include code from either your program or their program for this exercise. Note: this includes with the lab. Demonstrators or students in other years.
3 Likewise you MUST NOT write program code for, or share program code with, another student on this course or from previous years of study or anyone else.
4 You MUST NOT team up with others to write one program (in whole or in part) together, then all hand in programs containing that same code (in whole or in part).
U:\K9\C\c-19-20\Tutorials\Assessed Exercise No1\assess-1-2019-20.docx [ Page 7 ] (© Peter Judd/University of Sheffield 2019)
5 You MUST NOT copy portions of code from any sources (that are not of your own creation) such as a website or a book or from someone else’s computer, website (even from a website where the language is not English) or memory device. (However: I grant you exceptional permission to copy from any of the examples of code that I have given to you during this course as lecture or tutorial examples – if you do this, then attribute the source of those portions of code to me by writing my name in a comment like this /* taken from Peter Judd’s examples */ immediately before and immediately after the code concerned.)
Remember: the basic principle underlying assessed work such as this is that the work submitted for assessment must be entirely your own. We wish to only give marks for programs written by you alone!
If you are in any doubt about what might constitute unfair means in the context of this exercise then please discuss any areas of uncertainty with me. If you experience any problems with this assignment then seek help from me or the demonstrators present during lab. sessions.
Please note: I will be using a sophisticated program specially designed to detect plagiarism in a set of ‘C’ programs to help me detect evidence of such unfair means in the assessed work that you hand in, so, please don’t take the risk of copying work, submit only work done by you entirely on you own. Where I suspect unfair means to have been used, the department reserves the right to give zero marks to all individuals concerned and/or refer you to the University Discipline Committee and/or place a note in your student record file (We have caught people breaking these recommendations before and done all these things, so do please take note of this warning!).
Good Luck! Peter Judd
U:\K9\C\c-19-20\Tutorials\Assessed Exercise No1\assess-1-2019-20.docx [ Page 8 ] (© Peter Judd/University of Sheffield 2019)