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.
| Spring 2000 Program Assignments | ||||
| No. | Due | Title | Language | Sample Input |
|---|---|---|---|---|
| 1 | 2/15/00 | Infix Expression Evaluator | Pascal | See Assigment |
| 2 | 3/07/00 | Infix Expression Evaluator | Scheme | See Assignment |
| 3 | 4/04/00 | Five Suitcases | Prolog | N/A |
| 4 | 4/25/00 | Infix Expression Evaluator | Prolog | See Assignment |
[ 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 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. 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 diagram.
- 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 assignment.
- 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:- Test Case Name--a brief name that identifies the purpose of the test case (e.g., "Addition Operation" or "Blank Line Detection").
- 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.