We Helped With This JAVA Programming Homework: Have A Similar One?

Updated August 2016

Programming Assignments Guidelines

General Guidelines  

There will be four assigned programming assignments (labs), each constituting 10% of the total grade. Programming assignments will consist of JAVA, using JAVA 6.0 or higher, coded and executed only by the student. 

Late Policy 

Programming assignments must be submitted to the course website by Tuesday midnight of the specified module.  Assignments received after that are considered late and will be penalized 5 points for each day late. Assignments more than one week late cannot be accepted, except by prior arrangement with the instructor. Problems with your system do not constitute a legitimate excuse for lateness, so make plans to deal with the unavailability of your system. Programs must compile and produce legitimate output.

Style  

Your code must incorporate a consistent, well-documented style.  Required points of style include: 

•       Include clear, concise, and adequate inline comments           Write substantive, descriptive blocks for each module

•       Write a substantive, descriptive block for the entire program.

•       Comments should describe the function performed, not restate the code in English. 

•       Comments should explain the purpose of a function or method, its inputs, and outputs.

•       Comments should explain the algorithm being applied, a particular approach to a problem, or restrictions in using the code           Use white space liberally. 

•       Write one driver that executes your entire code. 

•       Consistent, well-delineated use of both upper and lower case is encouraged. 

•       Using indentation to show nesting of control statements is encouraged. 

•       Set tabs to only 2-3 spaces and keep line lengths to about 78 columns to reduce wrap around. 

•       Keep code modular. One page is a good rough guide to module size. 

•       Do not use GOTOs or global variables 

•       Use include files so that a link step is not necessary. 

Input 

You must correctly handle any required input, turning in output to show that it does. 

•       Generate your own test cases. You will lose points for not providing adequate additional input.        Generate input that checks extreme cases 

•       Generate input with errors that might reasonably occur due to typos or a novice user. Assume if it is possible to make a stupid mistake, someone will do so. 

•       When testing, approach your code as a total novice, then on a second pass, as though you are an experienced end-user.   Show that your code does everything it is supposed to do      Show all reasonable error cases are handled.

•       Use named files to handle I/O.  There will be a penalty for hardcoded file names. 

•       Enter file names as command line prompts.

•       Do NOT use GUI/console input.  

•       If you want credit for something, then it is important to demonstrate it with an appropriate I/O set.

Output 

Output is not part of the analysis. Output files must: 

    Echo the input as well as contain answers to the required input.         Be user friendly with additional labels, lines, and white space             Have statistical information as needed. 

Source Code 

You are expected to write your own code except as provided in a specific assignment. Do NOT use code from the internet or other sources to be part of your assignment, except Lab 4. Use of standard libraries is restricted to standard I/O calls and standard math functions, etc. In other words, you can't use the library stack code.

Analysis

The emphasis in the analysis document is on points such as correct application of concepts, technique, analysis of algorithmic efficiency, and lessons learned.   

The analysis should discuss the following points

•       Description of your data structures

•       Justification of your data structure choices and implementation 

•       Discussion of the appropriateness to the application

•       Description and  justification of your design decisions  

•       Efficiency with respect to both time and space

•       What you learned, 

•       What you might do differently next time    Specific requirements in the lab handout

•       Discussion of anything you did as an enhancement

•       Provide supporting details of your discussion  points

•       Do not reiterate the requirements of the assignment

•       Do not include pseudocode, code or output

•       Use Times New Roman Size 12 font, single spaced, with .75-inch margins on all sides.  

•       Include your name inside the file. 

A Complete Assignment  

A complete lab assignment consists of the following, in a single zip file attachment, with your name as part of the file name: SmithJLab1.zip. Include your name inside each file. Do not paste content into the boxes in the assignment item. 

1.  A written, analysis of the project, submitted as a PDF, with your name as part of the file name. 

2.  The source code. Include all your source files, except standard libraries.

3.  The compiled code. Include your compiled Java code

4.  Copies of all your input data sets (as text files/s: .txt), required and student generated test input

5.  Copies of all your output (as text files/s: .txt)

6.  A README files which specifies the version of Java and the IDE use, along with anything else we need to know to properly compile and execute your code.

Grading on Programming Assignments  

The grade for each lab assignment is broken down as follows: 

•       40% - Correctness - In problem solution and results.

•       20% - Style/Proper Coding - Following a reasonable, consistent style with STRONG documentation, with appropriate use of structures, modularity, error checking, etc.

•       10% - Input/Output - Labeled, formatted, correct use of prompts, correctly handles specified inputs and outputs as well as additional cases provided by the student, is user friendly.

•       20% - Analysis 

•       10% - Enhancements - Recognition of superior work on one of the required aspects of the assignments or work above and beyond the requirements. If you do something extra, please make sure it is reflected in the I/O set so you get proper credit. Discuss it in your analysis. We can't give you credit for something unless we are aware of it. If you add an extra feature to your code, make sure it is "in addition to", not "in place of" a required component of the problem.

This grading policy is a reflection of the expectation that you can already write minimal, working code. If the unexpected comes up, please let me know. I will be happy to discuss your grade with you anytime.

Examples of Programming Assignment Grades:

94-100% - This is a very strong lab that correctly implements all the required elements, and includes corresponding example I/O cases, and uses a reasonable and consistent style.  Each module has an introductory comment block giving an extensive, high level description of the module, detailed descriptive comments in the declarations sections and occasional detailed comments throughout the code.  Error checking is strong and covers boundary conditions and additional cases beyond the minimum specified input. Output contain all the required elements, is user friendly, formatted in a visually pleasing manner, and contains useful descriptive statistics about the results. Extra features may have been added. The analysis addresses the design decisions incorporated into the code development and explicitly justifies the specific data structures used and the specific implementation used. It considers both the theoretical and observed efficiency and explains any discrepancy that may exist, using Big Oh and theta notation appropriately.  It summarizes what the user learned in the lab, from language and structure specific experiences through big-picture concepts. It displays the writer's command of the topic in the assignment by identifying additional work that addresses known problems and/or continues to improve and expand the scope. It contains graphs or tables enabling the reader to more readily assimilate the results of the lab. It is formatted as required.

86-94% - This is good solid lab. Correctness errors, if any, are minimal. Documentation, style and error checking are good. Error checking may have some small omissions. There is some extra input, but less than might reasonably be expected  Output looks fine and can be followed without any problem. There are probably no extra features, or just small, easy ones. The analysis is good, mostly formatted as required, but is less comprehensive. Some areas may be treated only superficially, or omitted altogether.

80-86% - This is a good lab, with room for improvement.  There may be small correctness errors, sometimes due to a misunderstanding of the requirements.  Error checking, style, and documentation are standard.  Output minimally covers what it needs to. There are few, if any, extra input cases.  The analysis does not do a very good job of justifying the design decisions and structure choices and may not be formatted as required. Other aspects of the analysis, especially algorithmic efficiency, may be omitted.

70-80% - This is a weak lab.  It may do everything correctly but minimally, with no extras thrown in, minimal documentation, and a very sketchy, superficial analysis, probably not formatted as required. Alternatively, this may be a well done lab aimed for the categories above, with a moderately serious correctness error or a significant omission of a required component.

<70% - This is a lab with major errors in correctness and minimal efforts on style, and error checking.  Documentation may be nonexistent or extremely minimal. There are probably no additional I/O cases, no extra features.  The analysis is probably under a page in length, not formatted as required,  and addresses only one or two required topic areas.

If you are disappointed in your programming assignment score, you may fix and resubmit it before Module 12 for the summer or before Module 14 in the Fall and Spring terms.  Submissions after that must be arranged on a case by case basis with your section facilitator.  Fixes will only be accepted on issues of correctness, modularity, error checking, and use of named files.  Fixes will not be accepted on documentation, input sets, Enhancements, or Analysis. Fixes are subject to a 20% penalty in fairness to those with a

correct original submission, e.g. if you fix something which had a ten point deduction you will only get back 8 points.

Academic Integrity

IMPORTANT: You are expected to do your own work. Help from other sources must be acknowledged. It is okay to discuss the problem with others for perspective or to make sure you understand it correctly, but the code you write must be your own.

Downloading code from other sources for the programming assignments, while strongly discouraged, should absolutely be properly accredited. It is prohibited except for the Lab on Sorting.

Practical Points

•       Reread this before turning in lab.

•       Reread the handout of the assignment before turning in assignment.

•       Check that your analysis is correctly formatted.

•       Turn in a README file, noting any special requirements.

•       Compile and execute your code to verify that it works properly.

•       Exercise the features of your code with an extensive I/O set.  Create test input containing errors/              Fully document your code.

•       Provide input files with the required input and your supplemental input.

•       DO NOT turn in other’s work.

•       Provide output to all the required input cases and your supplemental cases.

•       Do NOT turn in an assignment that does not compile.

•       Remember that your code will be compiled and executed in a different environment than the one you are using. 

•       Consolidate everything in a single zip file, with your name as part of the file name: JSmithLab1.zip.  I/O files should be text. The Analysis should be a PDF.

•       If you need to resubmit, just go ahead and resubmit to the course website. It should be accepted, even after the due date.

Advice on Programming

•       The single most important thing you can do to smooth the code development process and reduce the overall time required is to work out the entire problem on paper, including debugging. Resist the temptation to jump into the editor and type just to make yourself feel productive.

•       Once you actually start to implement on the computer, adopt either a top-down or bottom up approach, and stick with it. Implement a single module and fully debug it before you go onto the next module. Then when you add a new module, if there are problems you can more easily locate them (in other words, if you combine two working pieces of code, any problems occurring have to be in the interface between them).

•       Remember that a debugger is a piece of software and is subject to bugs. If you cannot find a problem, then consider debugging the old fashioned way with write statements. 

•       Back it up. Disk space is cheap and you cannot back up your code too often. It is very easy to lose track of all the changes and iterations, so consider a version numbering system like V2.1 where changing the 1st number represents a big change and changing the second number represents a minor change.

•       The final piece of advice: "If it ain't broke, don't fix it". Less experienced programmers sometimes start changing things willy-nilly in a frustrated effort to address code problems they can't figure out. Get help, or at least save a copy, first.