CSE 331: Batch processing
In this lecture, we will read a different Sum and ask what its
specification has to say. Lecture 1's Sum and this one are
both batch programs: a batch program reads its input,
computes, writes its output, and exits. This Sum's input
includes its command-line arguments, the words typed after
java Sum. The user chooses them, and they change what Sum
does. Unless they name a file, Sum reads its numbers from
standard input, by default the keyboard. What a user sees of
Sum has three parts: standard output for its results,
standard error for its messages, and an exit status, a
number that says whether the run succeeded.
Sum's specification has to say what each part is, on every
run. We will test Sum's user manual against runs its author
may not have pictured, and find responses the manual leaves
out. A script, a program that runs other programs, relies
on what Sum promises, as a client in Lecture 2 does. Like
any user, though, a script owes Sum nothing. So Sum
checks what it is given. Its checks stand at the edge of the
program, between the user and the computation. If we split
Sum into methods, the checks stay in main. A method
inside may then have a precondition, since its client is
main, code that can be held to a promise.