,Page1 of7 School of Science COSC2452 Introduction To Programming (OUA) Assignment 2 (v.2020.04.26) – Updated – Please refer to edit history (section 10) for details Assessment Type: Individual assignment; no group or collaborative work. Submit online via Canvas→Assignments→Assignment 2. Marks awarded for meeting requirements as closely as possible. Clarifications/updates may be made via announcements/relevant discussion forums. Due date: 6:00pm, 18/May/2020; Deadlines will not be advanced but they may be extended. Please check Canvas→Assignments→Assignment 2 for the most up to date information. As this is a major assignment in which you demonstrate your understanding, a university standard late penalty of 10% per each working day applies for up to 5 working days late (submissions will not be accepted afterwards), unless special consideration has been granted. All new extensions must be applied for directly via RMIT Special Consideration. Weighting: 18 marks (excluding bonus marks) 1. Overview There is no book containing the music to every song that will be written. There is no book containing the answers to every mathematical calculation that we will need to perform. Similarly, there is no book, set of lecture slides, video, etc. that will give a programmer (you) the solutions to every programming problem. A programmer is able to take fundamental programming concepts and, with the experience they have gained from analysis, evaluation and problem solving, put them together to solve new problems. A programmer is also a developer who can plan, minimise risks, iteratively develop, test and deliver programs to a “client”. As a part of this, a programmer should be able to show snapshots of the various stages of the development. The snapshot should be a runnable Java program that does not need to have all of the features that will be there in the final version of the program. For this assignment, assume that you are a freelance programmer creating a small tool or a utility program of your own choosing to add to your portfolio of simple Java applications. With this project you aim to demonstrate to potential employers or clients how you can: 1. Create a small tool or utility program using (exclusively) a limited set of fundamental code concepts (detailed in section 4.1 below) 2. You are able to analyse and evaluate your code in your code documentation (see requirements in section 4.2below). 3. You are able to perform incremental development using the “minimum viable product” (mvp) principle discussed in the lectures (detailed in section 4.3 below). Note: You must not just “throw in the concepts” to your program just because they need to be there; it should be clear from the code why a certain concept should be there and you must further explain these through your comments. You will also need debug your code on your own and document any issues, etc. There must be two versions of your code (detailed further below). You are given marks on your ability to fulfill all requirements of this document. There are code requirements (14 marks) and documentation requirements (4 marks) for a total of 18 marks. Develop this assignment in an iterative, “mvp” fashion (as opposed to having one final version). You can and should get started now as there are concepts from the week 1 lessons that you can incorporate from now itself. Tip: In Assignment 3, you may extend this program using multiple-classes, objects, file I/O, etc. If there are questions, you must ask via the Canvas→Discussions→Assignment 2 discussion forums in a general manner (replicate your problem in a different context in isolation before posting). ,Page2 of7 4.1) Must use the following Java code concepts in a justifiable way to create a simple tool/program of your choice. Marks will not be awarded if concepts are “thrown in” without justifying their need in the program. Must exclusively use approaches taught in Canvas→Modules and lectures (Tuesday night) when using the concepts below. Refer to rubric in section 9 for full details. Ask via Canvas→Discussions→Assignment 2 when in doubt. C1. Code presentation and format. [2 mark] C2. Exclusive use of GTerm for user interface including appropriate use of (not limited to): buttons, textfields/textareas and list operations [2 mark] C3. else if statements and exclusive use if-statements for condition (non-repeating) execution [2 mark] C4. Only while loops for repetition; no for, do..while, recursion, or any other form of repetition. while-loop condition must fail eventually. Must not use break, continue, return, System.exit or similar branching for terminating loops. [2 mark] C5. Accessing and modifying values in (standard) arrays using while loops. Size of at least one array is determined at run-time (e.g. depending on number of records, etc.). Must demonstrate ability to manipulate (standard) Java arrays on their own without using external classes/libraries when possible. [3 mark] C6. Create methods in addition to the ‘main’ method and the ones required by GTerm. All methods must be explicitly public and non-static. The main method not do anything other than calling the constructor method. If communication between methods present, must be achieved exclusively via parameters and return values [3 mark] 2. Assessment Criteria This assessment will determine your ability to: 1. Follow coding, convention and behavioral requirements provided in this document and in the lessons. 2. Independently solve a problem by using programming concepts taught over the first several weeks of thecourse. 3. Write and debug Java code independently. 4. Document code. 5. Ability to provide references where due. 6. Meeting deadlines. 7. Seeking clarification from your “supervisor” (instructor) when needed via the Canvas→Discussions→ 8. Create a program by recalling concepts taught in class, understanding and applying concepts relevant to solution, analysing components of the problem, evaluating different approaches. 3. Learning Outcomes This assessment is relevant to the following Learning Outcomes: 1. Demonstrate knowledge of basic concepts, syntax and control structures in programming 2. Devise solutions to simple computing problems under specific requirements 3. Encode the devised solutions into computer programs and test the programs on a computer 4. Demonstrate understanding of standard coding conventions and ethical considerations inprogramming. 4. Assessment details Note: Please ensure that you have read sections 1-3 of this document before going further. Your code must meet the following code requirements (section 4.1) and documentation requirements (section 4.2) as a part of the required two file submission (see section 4.3). In places where this specification may not tell you how exactly you should implement a certain feature, the programmer (you) need to use your judgment to choose and apply the most appropriate concepts from class materials. Follow answers given by your “client” or “supervisor” (your coordinating instructor) under Canvas→Discussions→’Assignment 2’ when in doubt. ,Page3 of7 4.3) Development requirements You must demonstrate your understanding of the “minimum viable product” (MVP) concept of application development discussed in lectures by submitting two versions of your program: a. One version (worth 8 marks at most) should be of an early stage of development. This file is referred to as the “MVP” version. This file must also compile and run (although it might not have all of the features of the final version). b. Another version (worth another 8 marks at most) which is the final version of your program which must meet all requirements. The two files must be submitted together as a part of your very last submission. The MVP version must demonstrate at least 3 out of the 6 code concepts including C1 (see section 4.1) and sufficient documentation (see section 4.2); it is also marked based on the rubric in section 9. Additionally, the MVP version’s .java file must be named ending with MVP.java (E.g. if the final version is named Boat.java, the MV
P version must be in a file named BoatMVP.java) for ease of identification. (If no indication is given, the smaller file of the two may be considered the MVP version and the other the full version). If there is only one file, it will only be considered as the MVP version, even if it meets all code and documentation requirements. You must follow from the 1:23:08 point in the 10/Dec lecture for an explanation of the illustrations shown below. If you have further questions, you must also ask via Canvas→Assignments→Assignment 2 forum, as you would ask from a client or a supervisor. 4.2) Documentation requirements. Refer to corresponding rows in the rubric in section 9 for further details. D1. At the start of every code block* and near every important declaration, add code comments where you analyse your code and evaluate it against viable alternative implementations/declarations; marks will be deducted if comments simply state what the code is doing (see rubric in section 9 of this document) [4 marks] D2. Explain any code requirements that you have not met and all bugs (situations that might cause the program to crash or behave abnormally) in the approximate locations they originate within your code. Bugs imposed by limitations in the lesson topics such as input type mismatches need not be corrected in code but they still must be documented, if they exist. If you do not have bugs, you must explicitly say that there are none. [1 mark deduction if undocumented issues present] ,Page4 of7 4.4) Bonus requirements Note: To obtain any bonus marks, you must meet all requirements of the non-bonus/standard requirements. The total mark for assignments+weekly work (the non-exam component) is capped at 50 marks; the exam will be 50 marks. For a full break- down, see Canvas→Assignments. B1: If you make your final submission early, obtain +0.5 bonus marks for each week before the deadline. E.g. submit 1 week before the deadline for +0.5 bonus marks or 2 weeks before the deadline for +1 bonus mark, etc. B2: Include a PDF “user guide” with screenshots of your program and instructions for its functionality (+1 bonus mark). 5. Referencing guidelines What: This is an individual assignment and all submitted contents must be your own. If you have used sources of information other than the contents directly under Canvas→Modules, you must give acknowledge the sources and give references using IEEE referencing style. Where: Add a code comment near the work to be referenced and include the reference in the IEEE style. How: To generate a valid IEEE style reference, please use the citethisforme tool if unfamiliar with this style. Add the detailed reference before any relevant code (within code comments). ,Page5 of7 6. Submission format Submit both your MVP version .java file and final version .java file together (in one go) via Canvas→Assignments→Assignment 2. Only the set of files submitted when you selected ‘submit’ the last time is considered your official submission. i.e. attach both files before selecting ‘submit’ (or ‘re-submit’) button. It is the responsibility of the student to verify their submission. (If B2 functionality is attempted, submit also the PDF required along with .java files in one go.) 7. Academic integrity and plagiarism (standard warning) Academic integrity is about honest presentation of your academic work. It means acknowledging the work of others while developing your own insights, knowledge and ideas. You should take extreme care that you have: Acknowledged words, data, diagrams, models, frameworks and/or ideas of others you have quoted (i.e. directly copied), summarised, paraphrased, discussed or mentioned in your assessment through the appropriate referencing methods, Provided a reference list of the publication details so your reader can locate the source if necessary. This includes material taken from Internet sites. If you do not acknowledge the sources of your material, you may be accused of plagiarism because you have passed off the work and ideas of another person without appropriate referencing, as if they were your own. RMIT University treats plagiarism as a very serious offence constituting misconduct. Plagiarism covers a variety of inappropriate behaviours, including: Failure to properly document a source Copyright material from the internet or databases Collusion between students For further information on our policies and procedures, please refer to the University website. 8. Assessment declaration When you submit work electronically, you agree to the assessment declaration. This week’s programming task requires you to complete the file writing component (with some extra features), originally stated as an optional requirement IIE10. Ensure that you complete IIE10 first (in the IIE10 forum). For IIE11, make a copy of your completed IIE10 project to a new project named IIE11 and make the following changes: a. Allow the user to change the selected object’s values. When an object from the list is selected, the values of its member variables must be put in to separate text-fields. Add a button, which, when pressed, will save those values back in to the selected object. Ask you stuck? Create a post in the relevant forum and as your tutor for help. b. Add a “save to file” button to save the entire list back to a file. Allow the user to choose the file to which they can save (they may choose to overwrite the original file or save to a new file). Also add a “load a file” button to load a new file of the user’s choosing. Ask you stuck? Create a post in the relevant forum and as your tutor for help. c. Optional: Independently investigate and implement BufferedReader to read a file that is stored on a website. Add button named “load from URL”. Tip: You can copy and paste the URL to the data file that you downloaded (for IIE10) to test your code. This programming task requires you to try out file reading as given in Canvas→Modules→Week 10. a. Getting a data file in to ready for reading: Make a copy of a GTerm-based project and name the project as IIE10. To obtain a data file to read, go to the UCI Machine Learning Repository and find a data sets that might be of interest to you. Once you go in to the page of a particular data set, follow the link named “Data Folder”. Here you will find files that end with “.data”. Down, load a .data file to your computer and move it to your IIE10 project folder (if you have gone inside ‘src’ or ‘bin’ or ‘lib’, you have gone too far). Now go back to Eclipse, refresh your project (context select/right click on project name from package/project explorer then select refresh). You should now be able to see the .data file appear inside your project. For example: ,Page6 of7 (Note that somename.data is not inside lib. It is on the same level as IIE10). Double select/click on the .data file in the above (tip: not the same as double-clicking from outisde of Eclipes) and you would be able to see its contents in Eclipse. Ask you stuck? Create a post in the relevant forum and as your tutor for help. b. Reading the data from your program for the first time: As shown in Canvas→Modules→Week 10, using the BufferedReader and FileReader, read the file line by line and add the strings that are read to a GTerm list. You can either hard-code the file name or you can use GTerm’s getFilePath() to choose the file to open. Once your program reads the file, verify that the contents is the same as what was in the file (step a). Ask you stuck? Create a post in the relevant forum and as your tutor forhelp. c. Creating a class to match the data: The data in these files are arranged in rows and columns. Each row is a separate record (e.g. like one object) and the columns are attributes (e.g. like member variable values). The values on each row are separated by commas. Go back to the data set’s description page and find the ‘Attribute Information’. This describes the column names of your data. Create a new Java class to store each record (you can choose the name depending on what a row represents in your chosen data set). Create private
object member variables in your class for each of the attributes/columns. Youwould also need to create a toString method that would summarise the members of the object. Ask you stuck? Create a post in the relevant forum and as your tutor forhelp. d. Loading the file and creating objects instead: Now modify your file reading code (step b) so that each row that is read from the file (as a string) is split by commas then used to create new objects of your class (from step c). Instead of adding the string to the GTerm list, add the object instead to the GTerm list instead. Ask you stuck? Create a post in the relevant forum and as your tutor forhelp. ,Page6 of 7 9. Rubric/assessment criteria for marking Code must be valid, runnable Java to be given a mark (non-compilable code such as JavaScript, pseudocode, incomplete Java code cannot be marked). Must include the two files as detailed in section 4.3 of this document to be eligible for the full 18 marks. Run-time errors will incur up to a 50% penalty (run-time errors due to data type mismatches in inputs are acceptable). Inadequate Partial Complete (Uses only the concepts covered in Modules and lecture materials for meeting stated criteria) C1 More than one one of the criteria in the ‘complete’ level missing/incorrect. One or more criteria of the ‘complete’ level missing/incorrect but demonstrated as a part of meeting overall functional aims of program. MVP version and final version are in separate .java files. All code of a particular version in the same .java file (no multi-Java files). Class name suits program and is not an arbitrary or default name (e.g. not Assignment2.java). Only method declarations are at class-level (e.g. no member variables).Member variables can be used in justifiable ways. All such member variables must be explicitly private and not static. There should be no equal signs near declarations of member variables; these must be initialised in the constructor before the constructor performs any other actions. All references to member variables from methods must start with “this.”. Identifier names are descriptive and follows conventions given in lectures/Java API. Demonstrates understanding of primitive data types vs. class types where relevant. Avoids hard-coding when appropriate. Formatting is consistent in all files. Only relevant code and comments included. All code reachable. Does not use break, continue, System.exit or similar anywhere in the code and does not return from the middle of methods. C2 Missing/incorrect use of input taking OR some criteria in the ‘complete’ level missing/incorrect. One or more criteria of the ‘complete’ level missing/incorrect but demonstrated as a part of meeting overall functional aims of program. Uses GTerm exclusively for user interface (e.g. no Scanner or JOptionPane). Has buttons and methods that are called when buttons pressed. Uses textfields or textareas to take inputs. Uses one or more lists (no need to have a method call at list selection). Can use other methods defined in GTerm. Above demonstrated for meeting overall functional aims of program. C3 Missing/incorrect use of else if OR some criteria in the ‘complete’ level missing/incorrect. One or more criteria of the ‘complete’ level missing/incorrect but demonstrated as a part of meeting overall functional aims of program. Uses if/else/else if appropriately and exclusively for non-repeating conditional execution. Contains at least one reachable else if statement. Conditions do not include tautologies and pathways are not redundant. Every code block in every if/else/else if structure is reachable. Does not use break, continue or return. Above demonstrated as a part of meeting overall functional aims of program. C4 Missing/incorrect use of while loops OR some criteria in the ‘complete’ level missing/incorrect. One or more criteria of the ‘complete’ level missing/incorrect but demonstrated as a part of meeting overall functional aims of program. Uses while loops appropriately and exlusively for repetition. Loop condition must describe all situations under which the loop will repeat and condition must fail eventually. Conditions do not include tautologies. Does not use break, continue or return or similar. Above demonstrated as a part of meeting overall functional aims of program. C5 Missing/incorrect use of arrays OR some criteria in the ‘complete’ level missing/incorrect. One or more criteria of the ‘complete’ level missing/incorrect but demonstrated as a part of meeting overall functional aims of program. Uses standard Java array(s) exclusively (e.g. no ArrayList, etc.) to meet the overall goals of the program. At least one such array has its size determined at run-time. Loops are used for traversing arrays and all array manipulation is performed without using other classes/code (e.g. does not use the Arrays class). C6 Missing/incorrect use of methods OR some criteria in the ‘complete’ level missing/incorrect. One or more criteria of the ‘complete’ level missing/incorrect but demonstrated as a part of meeting overall functional aims of program. Aside from the main method and any methods created for use by GTerm (for buttons and lists), the code has at least two methods. All methods (including ones created for use by GTerm) are explicitly public and only the main method has the only mention of static. Must demonstrate parameters and return values (not all methods need to do this). All methods created to reduce code duplication or to for to reduce code repetition or to improve readability of code. Control/execution within each method always reaches the very last statement of that method (no spaghetti code; avoids return statements in the middle of the method). Above used as a part of meeting overall functional aims of program. D1 Lacks one or more of the ‘partial’ level criteria OR documentation not within .java file. Comments only state what the code is doing but does not analyse or evaluate against viable alternatives. OR One or more of the ‘complete’ level criteria not met. For the class block, the comments analyse the breaking down of the application to smaller tasks/actions (e.g. methods) and organisation to achieve the overall goals of the whole program and evaluates it against viable alternatives. For each method, the comments analyse the breaking down of the task/action to even smaller steps (algorithm specific to that method) to achieve the aims of that method and evaluates it against viable alternatives. For all code blocks of loops and if-statements, etc. the comments analyse the breaking down of the algorithm steps to even smaller implementation statements, to achieve the overall goals of that code block. For every important variable declaration, the comments analyse and evaluate viable alternative declarations (e.g. what other data types could have been used and why this type was used). D2 Does not discuss potential issues in the code OR documentation not in .java file. Identification (without discussion) of the criteria stated under ‘complete’ or discussions exclude some of the criteria under ‘complete’. Explains any code requirements that have not been met, situations that might cause the program to crash or behave abnormally. Able to identify the approximate locations of any issues within the code and comments are given in those locations. Bugs imposed by limitations in the lesson topics discussed. ,Page7 of 7 10. Document Edit History: Version 2020.04.26: a. Section 9, rubric for C1 ‘complete’ changed to include changed policy on member variables. Removed text appears with a strike through and newly added text is in bold. b. Section 4.3 marks breakdown shown was made consistent with the rest of the document. c. Included a second bonus marks criteria (section 4.4) and submission requirements made consistent. Version 2020.04.09: Original version.
