CS 1705  Home  Syllabus    Lab Times  Office Hours  Topic Calendar Contact Us      Discussion Forum Course Materials  Course Notes  BlueJ  cs1705 Package API  Test Case API  Java API  Java SDK  Java Tutorial Assignments  Homework  Labs  Lab Grading  Programs  Program Grading  Web-CAT Grader  Choose Lab Section			All program assignments are submitted electronically using the Tools->Submit... menu entry in BlueJ. Programs are due at midnight the evening of the date specified.   No.    Program    Due     1   Maze Solver   09/14     2   Trash Man   09/22     3   DUML Translation   10/12     4   Tetris Brain   10/26     5   Web Log Analyzer   11/16     6   Adventure   12/05   Commenting Requirements Read the course information on commenting your code. Tutorial on Input and Output Read the course information on 'Files and Stream-based Input and Output. Program Grading Program assignments will be graded according to the following general criteria, which are similar to those used for lab assignments: The solution adequately addresses the problem at hand.  Specifically: The solution clearly represents a good-faith attempt to address the requirements for the assignment. The program compiles and executes. You have written enough tests to demonstrate that your code meets the requirements of the problem. The program runs correctly, in that it passes all of your tests. The solution constitutes a high quality product expected of a professional.  Specifically: The program is easy to read and to understand, i.e., it is well commented and adheres to the course standards for layout and format.  For example, operation and object names are appropriate and thoughtfully chosen, and all potentially confusing/complex program code (including non-trivial if-statements, loops, procedure calls, etc.) is adequately documented.  See the example programs in the text and on-line for suggestions about how to comment your code. See the PaintBox example in the course notes for suggestions on how to format your programs for readability. The general design of the program is clear and reasonable.  For example, the program makes good use of classes and operations; and the algorithms used are appropriate for the task, are clearly explained, and are implemented in a sensible, understandable way. All classes, interfaces, and methods include an appropriate JavaDoc description. Classes must include @author and @version tags (use the date you wrote the code as the version value), together with a description of what the class represents and what it is for. Methods must include a description of their behavior, together with descriptions of each parameter (@param tags) and the return value, if any (@return tag). Again, see the PaintBox example in the course notes for typical content. Each program assignment will receive a score broken down as follows:  Weight   Criteria  40% Design/Readability is assessed by TAs as they manually review your code and enter comments on-line. You can view feedback from the TAs through Web-CAT. TAs are able to consider and comment on any aspect of your submission, although the most prominent issues they look for are: Class Design: Does each class capture a clear, identifiable abstraction? Is the division of responsibilities between classes clean, understandable, and justifiable? Method Design: Does each method have a clear, understandable purpose? Is the logic within the method easy to read and understand? Is the method too long? Does the method try to do too many things, instead of having a single, focused purpose? Naming: Are names for classes, methods, variables, parameters, and other entities well-chosen? Does each name properly reflect the role of the corresponding entity? Names should be chosen so that a naive reader's first intuition about what the name represents is always right. Do names follow established conventions? Briefly, naming conventions are: classes and interfaces start with an upper case letter, methods, variables, and parameters start with lower case letters, underscores are avoided, and multi-word names use capitalization to indicate where each word starts. Test Case Design: Have you provided tests for each class you have written? Have you provided tests for each method you have written? Do your test cases provide sufficient assertions to check for all intended conditions? Could an "incorrect" program pass your test cases? In each test class, have you properly set up a "test fixture" consistent with the test case methods? Commenting: see the commenting guidelines. TAs also have the option of reviewing (and imposing additional deductions for) any of the automated grading issues. 20% Style/Coding is automatically assessed when you submit your program. Web-CAT uses industrial static analysis tools to look for coding violations or poor coding practices that are simple to spot. All errors, warnings, and suggestions can be viewed on-line in the marked-up version of your source code. Your goal should be to eliminate all remarks generated for your submission by Web-CAT. Sometimes, Web-CAT will produce remarks about your code without deducting points. That makes it easier for beginners to proceed without getting discouraged, but there is no excuse for not fixing every issue noted in the feedback on your code. After all, the TAs can see the comments about your code too! 40% Correctness/Testing is automatically assessed when you submit your program. Note that it is not enough that you produce a working solution. In addition, you are responsible for providing tests sufficient to demonstrate that your program's behavior covers everything required by the assignment. Unless you write test cases that exercise your code, your code will not be automatically executed or evaluated. Your test cases should contain assertions that capture all of the relevant aspects of the behavior being tested. Web-CAT automatically computes a score based on three factors: How many of your tests are passed by your code? Your tests are executed, and the number passed is counted. How much of your code is executed by your tests? Web-CAT will highlight in pink any code that was not executed by any of your tests. Web-CAT counts the number of methods you have written that remain untested in any way. Do your tests appear to be consistent with the behavior required in the problem? In some cases, you may not be testing all of the conditions required in the assignment, and your program may then violate the required behavior even though it passes all of your tests. Web-CAT computes a percentage for each of these factors and then multiplies them together. Doing poorly on any of these factors will drag the correctness/testing score down.  100%   Total  The general intent is for the cumulative score on the program assignment to reflect the following assessment:  Score   Interpretation  100 the solution meets all criteria well 90-99 the solution is not quite what was required, but the mistake is superficial 80-89 the solution meets most criteria, but there is some room for improvement 60-79 the solution is just satisfactory; it meets some criteria but there is significant room for improvement 40-59 the solution is barely acceptable; there are serious shortcomings in meeting most criteria; it needs a lot of improvement 0-39 the solution is not acceptable Students often wonder why a seemingly small error can cause a relatively large grade deduction.  The reason is that software that does not work properly even in the smallest detail -- not in these assignments, of course, but in the "real world" -- can be costly or even dangerous to its users; and software that is difficult to change can be costly to companies that develop it.  Most employers of software professionals therefore have high standards for quality.  We want you to get used to this: to understand that "almost right" isn't good enough for most employers, and that as a professional it shouldn't be good enough for you even if it were good enough for your employer.  Therefore, an error that prevents your program from working (especially from compiling properly so it can run at all) can result in a significant grade deduction.  This means it is usually better to continue working on a program after it is due, taking a deduction for lateness, than to submit a buggy program.  Once you start getting 2-3 days late, however, it's probably a toss-up unless you're sure you are going to get it working soon!