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
[ The program examples have been moved to individual programming
language pages. ]
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
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
- Design--a discussion of the structure of your program and
the method by which it solves the problem at hand. It is important
for your description be specific about the structure of your solution
so that whoever is reading your report will know where to look in
your source code if they have questions about some portion of your
solution. At a minimum, you should provide a structure chart (or
another design representation, depending on the paradigm you
are using), together with a brief description of each component in the
- 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.
- Correctness--the program behaves as specified by the program
- 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 will consist of a series of
test cases that you have devised for your program. Each test case
should be described in the following format:
For programs that permit multiple "actions" in one input stream,
you may optionally include all of your test case input data in a
single input file. You can then run your program on this entire file
and capture the output in a single "test results" file. Printouts of
these files with line numbers can then be included as
part of your test plan. If you use this approach, you can then write
"file input.txt, line 14" for "Test Input" and "file output.txt, line
14" for "Test Result" (for example) when describing the corresponding
- Test Case Name--a brief name that identifies the purpose
of the test case (e.g., "Addition Operation" or "Blank Line
- Description and Justification--the rationale for choosing
this particular test, together with what you can conclude about
your program from a successful outcome.
- Test Input--the input data for the test case.
- Test Result--a capture of the actual input
and output produced by your program when run on the input.
Be sure that in addition to tests for normal functionality, you also
provide error tests that ensure your program appropriate
detects or responds to any limitations, restrictions, error
conditions, or other "non-typical" issues raised in the problem
description or discovered by you during design.