University of Toronto
Scarborough College
Fall 1997
CSC A06F: Introduction to Computer Programming

ASSIGNMENTS

Please re-read the course information handout about due dates, late penalties, and plagiarism.

The assignment sheet tell you what to hand in. In addition, hand in a 3.5" diskette with your program saved on it. (The TAs may need to run your program to check its status.) Place everything into a large envelope (8x11 size will do). Please don't seal the envelope; a simple staple will do. Attach the cover sheet to the outside of the envelope.

A cover sheet is included with this handout. Copy it and fill in all the details.

Place your assignment in the drop box labelled for your tutorial in the Math Aid room S-506F. Place late assignments there as well.

How to do well on your assignments

Your programming assignments will be marked by the tutors. Read this section carefully so that you won't lose marks just because you didn't understand what the tutor was looking for.

The marker's basic questions

What you hand in will be judged not only on whether it works, but on how clear it is and on how well you show that it works.

The question ``how clear is your program?'' relates to the program's style. When you have a choice to make in programming, make the choice that helps your tutor to understand what you're doing.

In evaluating your testing, your tutor is asking ``Have you shown that your program works?'' It might be obvious to you that your program works. It is not obvious to anyone else. You must hand in the input and output from a systematic set of test runs so that your tutor can see why you think your program works.

The section below shows you some of the marking instructions that are given to tutors.

Use the ``Java Coding Guidelines'' in Appendix G of your Lewis and Loftus textbook.

What to hand in

All assignments will require you to submit two items: the program itself, and the test cases. In addition, some assignments may require ``external documentation''.

Your program printout must be paragraphed or indented. The Visual Age for Java editor helps you indent, but if you are using another editor you will have to indent yourself.

The printouts of your test cases must include both the input and the output for each test. Annotate the tests so that the marker will understand the meaning of each item. For example, beside a test run that demonstrates that a program works with the null string as input, you might write--by hand--``Input: null string. Works''. Or, if your program fails to work with a negative number as input, you might write, ``Negative input. Program fails''. (In that case, you might also want to add a brief explanation of why the failure doesn't matter or doesn't affect the other test runs.)

Later assignments will probably need more description. It's common to require ``external documentation'', meaning a supplementary report that describes how the program works, how it is organized, what tests you performed, and so on.

Your hand-ins must include the cover page with all the required information filled in. A template for a cover page is provided below.

Some excerpts from the tutors' marking guide

Here are some of the instructions that the tutors are given on how to grade the assignments:

A program that basically `works' gets at least 5 marks out of 10; one that does not work should receive less than 5. A program is considered not to work if:

• it causes error messages indicating syntactic or other errors;

• it does not terminate when it should;

• it does not produce output, or its output is inappropriate for the input.

Working programs are judged in the following areas:

Completeness: A good program handles not just the standard situation, but also well-chosen special cases.

• Is 0 an acceptable input? a negative value? a list of 0 items? Sometimes a sensible response can be given to unusual input; for example, the sum of the first 0 terms of a series is 0, but the sum of the first -3 terms is nonsensical. The program should handle the ``special but sensible'' cases properly, and produce suitable error messages in other cases.

Style: The text of the program should communicate its purpose clearly to a human reader. See Appendix G of the textbook.

• Are the variable names chosen well? Are the variables declared in the right place (where they're needed, not at the beginning of the program)?

• Are ``magic numbers'' avoided and constants declared instead?

• Are the blocks of the program--loops, if-statements, and (later in the course) subprograms--well chosen and well laid out?

• Is the program indented properly, using OOT's paragraphing command. Are blank lines used to advantage?

• Is the user given appropriate messages? For example, when input is needed from the user, there should be a prompt; and output messages should be formatted to be readable. If you have trouble deciphering the output, there is something wrong.

Comments:

• Are there comments describing the function of major blocks? Are they clear, grammatical, and correctly spelled?

• Are important variables defined in comments? Clearly?

• Is there an initial comment stating the purpose of the program and giving the student's name, student number, course, section and tutor's name?

Testing:

• Are the standard cases covered? the obvious boundary cases? the not-so-obvious special cases? the error cases that the program is supposed to cover?

• Are the test outputs annotated so that you can tell what they're supposed to prove?

 

How to prepare your assignments

All CSC A06 assignments involve creating a program and test cases. This section gives an overview of the major steps involved.

Preparing your program

First, of course, you will write your program (by hand, on paper). When you have a complete first draft, you'll type your program in, run it, and debug it as necessary, using either Visual Age for Java or JDK. (Between sessions on Visual Age, make sure you export your program(s) to a .java file, or they will be lost when you logout). Also, save your program frequently during editing, in case of system failure!

When you're finished, you'll usually need to print the program file, along with your test data and results, to hand in for grading.

Test data

What is a test file? Ordinarily you can test a program by running it within Visual Age for Java, or by using JDK, and typing test data as input. Then you look at the screen to see if the output is correct. (With JDK, the input and output will be mixed up together on the screen; this is ok.) But as you debug and test your program, you'll have to type the same test data each time you test your program. You can save having to do this by creating a test file.

A test file is a file containing the data that you would type during a test run. For example, if your program requires a name and two numbers as input, you might type a line such as

Jim 12 43.6

and that's exactly what should be in your test file.

Even though the contents of the test file are obviously not a Java program, you can use the same editor to prepare the test file (in Visual Age for Java, you should use the Scrapbook editor rather than the Workbench). Start up an your editor, type the desired test data, and save your data to a file. You'll be asked for a file name, of course, so tell it a suitable name such as test23.dat.

Now you need to get your program to take its input data from the contents of test23.dat instead of from the keyboard. And you need to make it output to a file instead of the screen, so you can print the results.

Test results

You'll have to be at the `command prompt' in either DOS or Unix in order to work with data input and output files. Here are the essential steps.

If you use Visual Age for Java:

• Export the .java files to a directory (for printing).

• Export the .class files to a directory.

• Start up a DOS window, and continue with the steps for JDK. Of course, you'll have to have installed JDK, or do this on a machine with JDK installed on it. (You might actually be able to do the steps below in Visual Age, but I'm not sure how. If you can figure it out, you won't have to drop down to the DOS prompt.)

If you use JDK on DOS or Unix (fissure):

• Run the program on each test file. If your program is called MyProgram.class, and you have 2 test files, then give these commands:

          java MyProgram < test1.dat > test1.out
          java MyProgram < test2.dat > test2.out

  The ``<'' and ``>'' symbols indicate redirection of the input and output to use files instead of the keyboard and the screen. You won't have to type any input, and you won't see any output on the screen.

• Print the program files, i.e., the .java files. (Could do this from Windows.)

• Print each test data file: test1.dat, test2.dat, ...

• Print each test output file: test2.out, test2.out, ...

Why is this such a pain?

That is, why do I have to save everything and switch to old-fashioned DOS? After all, using computers on a day-to-day basis isn't like this at all.

The reason is that program testing is a difficult business, often tedious and error-prone but vital to the success of the product, that only programmers have to deal with. When things get more complicated than the assignments in this course, programmers often write other programs (some are called 'batch' files) to automate the process of testing as much as possible.)

About this document ...

This document was generated using the LaTeX2HTML translator Version 96.1 (Feb 5, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 -no_navigation doing-assign.tex.

The translation was initiated by Philip Edmonds on Mon Sep 29 17:18:44 EDT 1997