School of Computing, Edinburgh Napier University Assessment Brief Pro Forma
1. Module number
SET07109
2. Module title
Programming Fundamentals
3. Module leader
Simon Powers
4. Tutor with responsibility for this Assessment
Student¡¯s first point of contact
Simon Powers
S.Powers@napier.ac.uk
5. Assessment
Practical Skills Assessment 1
6. Weighting
24% of module assessment
7. Size and/or time limits for assessment
You should spend approximately 24 hours working on this assessment.
8. Deadline of submission
15/03/2021 at 15:00
Your attention is drawn to the penalties for late submissions.
9. Arrangements for submission
Submit to the Moodle Dropbox by 15:00 on Monday 15th March.
You are advised to keep your own copy of the assessment.
10. Assessment Regulations
All assessments are subject to the University Regulations.
11. The requirements for the assessment
See attached specification.
12. Special instructions
See attached specification.
13. Return of work
Feedback will be provided at the demonstration session. Final marks will be returned via Moodle. Additional one-to-one feedback will be given to any student that requests it in a subsequent practical session.
14. Assessment criteria
See attached specification.
SET07109 Programming Fundamentals Coursework 1: Creating an application to analyse Javadoc comments in Java source code
1 Overview
This is the first coursework for SET07109 Programming Fundamentals. This coursework is worth 24% of the total marks available for this module.
In this coursework you are to build a command line application, called jdoc, that reads in a file of Java source code contained in a .java file, and analyses the Javadoc comments within it. To do this, your application will treat the .java file as a text file, and will use functions from the C standard library such as fgets to read in a line at a time into a character array and process it. The specification below will go into detail about exactly how your application should behave.
Your application must be written entirely in C, and must only use prewritten functions from the C standard library (see http: //www.cplusplus.com/reference/clibrary/ for a list of the functions in the C standard library). If you are not sure if a function you are using is in the C standard library then you should ask the module leader. You are free, of course, to write your own functions in C. Applications written in C++ or any other language will not be marked.
2 Background: Javadoc comments
Javadoc comments are a special type of comment that are placed before class names and method names in a .java file. They begin with /** and end with */, e.g.
1
/**
* This is the first line in the comment.
* This is another line in the comment.
* The comment ends on the line below.
*/
Javadoc comments can contain special tags. Your application will process the following tags: @author, which is followed by the name of the author of the class, @param, which is followed by a description of a parameter that a method takes in, and @return, which describes what a method returns. For example, a class called Student may be prefixed with a Javadoc comment immediately before the public class line giving the author of the class as follows:
/**
* A class to represent a student.
* @author Brian Kernighan
*/
public class Student {
Similarly, a method to get the name of a student may be prefixed with a Javadoc comment like this immediately before the public String getName ( ) line:
/**
* Query for the name of the student.
* @return the name of the student
*/
public String getName ( ) {
Finally, a method to set the name of a student may be prefixed with a Javadoc comment like this immediately before the public void setName ( String name ) line:
/**
* Sets the name of the student.
* @param name the name of the student
*/
public void setName ( String name ) {
2
3 Application specification
Your application is required to read in a .java file with Javadoc comments and output the following to the console:
1. The total number of lines in the .java file (including any blank lines).
2. The number of non-blank lines in the .java file, where a non-blank line is defined as a line that contains at least one character that is not a space, tab or newline.
3. The number of Javadoc comments in the file. Recall from above that a Javadoc comment begins with /** and ends with */.
Your application is also required to write all of the Javadoc comments in the .java file out to a separate output text file. Each Javadoc comment must be followed in the output file by the class or method name that it belongs to (e.g. public class Student or public String getName ( )).The name of the input .java to be processed should be specified by a -i command line argument, and the name of the output text file should be specified by a -o command line argument (see Section 1.8 of the Workbook for a re- minder of how command line arguments work). For example, if the input file is Student.java, and the output file is Student doc.txt, then your jdoc application should be run as follows from the command prompt:
jdoc -i Student.java -o Student_doc.txt
Finally, your application should print information about the class and methods in the .java file to the console, as follows. First, it should print the name of the class in the .java file, followed by the name of the author (which it will get following the @author tag in the Javadoc comment), to the console, e.g.:
Class Student
Author: Brian Kernighan
Second, for each method it should print to the console the name of the method, followed by details of any of its parameters as specified by @param tags, and details of what it returns as specified by @return tags, e.g.:
Method getName
Returns: the name of the student
3
Method setName
Parameter: name the name of the student
Note that the method name must be printed before the parameter or return information, and that the @param and @return tags are being replaced with the word Parameter: and Returns: in the console output, respectively.
You are supplied on Moodle with two example .java files that we will use to test your application, along with examples of what the correct output should be.
4 Advice
The application functionality described in the specification has been pre- sented in increasing order of difficulty. You do not need to get it all working to obtain a pass mark. You should begin with the easier functionality around counting the number of lines and comments first. If you cannot get the com- mand line arguments working then you may hardcode in the names of the input and output files for demonstration purposes (although you will lose some marks for this). Read carefully the mark scheme in Table 1 at the end of this document.
You should watch Lecture 4b again which covers how to read in a text file line by line using fgets. There is a detailed case study of this in Section 4.6.2 of the Workbook, which you should work through before beginning the coursework. You should also carefully study Section 4.6.3 of the Workbook on tokenising (splitting) strings, as you will need to do this to process the @ tags, for example. You should examine the functions available in the C standard library to see those that may assist you. Documentation for the functions in the C standard library is available here: http://www.cplusplus.com/ reference/clibrary/.
You should make use of your timetabled practical sessions before the hand-in date, where the teaching team will provide you with feedback on your solution as you develop it, and help with any problems and bugs that you might have. You may also make use of the School of Computing Pro- gramming Surgeries for additional drop-in help. The times for these are listed in the General channel on the module Teams site.
5 Code quality
Code quality includes meaningful variable names, use of a consistent style for variable names, correct indentation, and suitable comments. Variable
4
names must begin with a lower case letter. Constants should be written in uppercase, and used instead of literal values where appropriate.
The source code should have a comment at the top detailing the name of the author and the purpose of the program. Every function should be preceded by a comment describing its purpose, and the meaning of any pa- rameters that it accepts. Any complex sections of code should be commented.
You must remember to close any files that you open when your application has finished with them.
You must include a makefile to build the application. The makefile must also contain a clean configuration to delete object and executable files.
Your code will be assessed on all of these criteria.
6 Submission and Demonstration
Your code must be submitted to the Moodle Assignment Dropbox by 15:00 on Monday 15th March. If you submit late without prior au- thorisation from your Personal Development Tutor your grade will be capped at 40%.
The submission must be your own work, written by you for this module. Collusion is not permitted. The university regulations define collusion as
¡°Conspiring or working together with (an)other(s) on a piece of work that you are expected to produce independently.¡±
Please acknowledge all sources of help and material through comments in the source code giving a link to the material that you have consulted, e.g. include a URL to any Stack Overflow code segments that you have incorporated in your work. If you use Git or other version control then please make sure that your coursework is stored in a private repository to prevent access by others. If it is suspected that your submission is not your own work then you will be referred to the Academic Conduct Officer for investigation.
All coursework must be demonstrated to a member of the teaching team after submission. If the coursework is not demonstrated then this will result in a grade of 0. The demonstration session is the point where the teaching team will give you feedback on your work. Final marks will be returned within three working weeks via Moodle. Further one-on-one feedback will be made available in the subsequent practical sessions to any student who requests it.
The submission to Moodle must take the form of the following: 1. The code file(s) required to build your application.
5
2. A makefile to allow building of your application.
3. A readme file explaining how to use the jdoc application, as well as how to build it from the source, and the tool chain used for building (e.g. Microsoft Compiler, Clang, etc.).
These files must be bundled together into a single archive (a zip file) using your matriculation number as a filename. For example, if your matriculation number is 1234 then your file should be called 1234.zip. All submissions must be uploaded to Moodle by the time indicated.
7 Mark Scheme
The marking scheme for this coursework is shown in Table 1 at the end of this document.
BE WARNED! This coursework is intended to be challenging and will take time to think through and implement a solution. You will need a thorough understanding of the material covered in the first 4 units of the module. If you do not complete these you will struggle. DO NOT LEAVE THIS WORK TO THE LAST MINUTE!
We hope you enjoy the process of designing and implementing a complete application from scratch. If you have any queries please contact the module leader as a matter of urgency.
Description
Marks
Outputs total number of lines in .java file
2
Outputs number of non-blank lines in .java file
2
Outputs number of Javadoc comments
2
Output file produced to specification
4
Console output of class and method details as per specification
5
-i command line argument to specify input file name works
1
-o command line argument to specify output file name works
1
Commenting standard in specification met
1
Code quality: Variable names, indentation, file handling
3
Makefile builds application successfully
1
Makefile written to specification, including a clean target
1
Submission collated correctly, including readme
1
Total
24
Table 1: Mark scheme. 6