CS 3304 Fall 1999 Program Assignments

The programming assignments for this course are each in a different programming language. A fundamemental element of each assignment will be that to a large extent you will be required, after a brief class room introduction, to learn the corresponding programming language on your own. Thus it will be important that you take the time to learn the language BEFORE you attempt to complete the corresponding assignment.

Program Submission Guidelines

For each assignment, you are to hand in a report in which you document the steps you undertook to complete the assigned work, and documentation (informal proof) that your implementation was properly operational. The programs will NOT be run against a test suite; instead you should create your own test suite, show that it is adequate to validate the program, and then show the results of the validation testing. In particular, simply showing your program operates on the sample input is not sufficient to receive full credit.

Notes on testing are available for your use.

Each program report should follow the outline below:

• Documentation (30%):
  • Cover Sheet--your name, assignment number, and date submitted.
  • Design--a discussion of the structure of your program and the method by which it solves the problem at hand.
  • Operation--a brief description of how this program is run, how and/or where input is provided to the program (e.g., from standard input, from a file specified on the command line, etc.), and an explanation of the output and where it is provided (e.g., standard output, another file, etc.)
  • Restrictions/Limitations--any limits or restrictions on the scope of the program, such as illegal input, limits on the length of the input, etc.

• Program Text (40%):
  • Unit Headers and Descriptions--each program unit should be preceded by a comment block that gives the specifications for that unit, particularly detailing its interface requirements
  • Well Commented--the program source (besides the header) should include comments to explain the specific actions of the elements of the program tied in to the design description in the documentation
  • Well Structured--careful use of indentation, small abstract program units, logical division of the problem, etc.
  • Careful Use of Identifiers--identifiers should be chosen to give a sense of readability to the program, and should NOT be repeated in other program units unless they have a common meaning

• Test Plan (30%):
  Your task is to demonstrate convincingly that your program fulfills the requirements set forth in the assignment. Your Test Plan documents the tests that you have designed and conducted, as well as the results of each test. Your Test Plan should be divided into the following sections:
  • Unit Tests--each individual program unit should be tested individually. Unit testing may be able to be shown through displaying the intermediate results during integration and integration testing; otherwise each program unit should be tested individually. For each such unit, describe the each test performed:
    • Description--a description of the nature and expected output of the test.
    • Justification--the rationale for choosing this particular test and the benefits to be gained by using it (be sure to show what level of correctness you are striving to achieve).
    • Test Result--include captures of the actual input and output from the test steps with appropriate commentary.
  • Integration Tests--After units have been tested individually, you can combine them into "clusters" that make sense. Clusters of units can be tested separately if appropriate. Finally, clusters are combined until the whole program is complete. Each "cluster" should be tested, with the tests documented as above for unit tests (e.g., Description, Justification, and Result). Testing of the entire program is the final step of integration, and should be documented in the same manner.
  • Error Tests--if there were limitations or restrictions listed in your documentation writeup, then you should include a set of tests on the whole program that demonstrate that the program responds appropriately to such error conditions.
  • Limit Tests--otherwise known as "boundary tests" or "stress tests" check for the final program for responses to such things as a null input, the longest possible input string, etc.