32. Alternative Simulation Frameworks
Part of
CS:2820 Object Oriented Software Development Notes, Fall 2015
|
Discrete-event simulation was first developed in the 1960s, before anyone understood object-oriented programming. Much of the early work was done in the FORTRAN programming language. FORTRAN, at that time, had very limited control structures and a very limited data model. Variables could be integers, floating-point numbers, or double-precision floating point numbers. There was no character data type, but characters could be processed as integers. There was nothing resembling structures, or classes, but there were arrays. This was very limiting, but still sufficient.
If we were building our road network simulation in FORTRAN back the, we might begin by designing the event set. Each event might be described by a logical record containing:
Of course, since FORTRAN did not have record structures of any sort, we'd have to make do with arrays. For each integer value of I, the array entries ETIME(I), EVEHICLE(I), EROAD(I), EINTERS(I), and ENEXT(I), would describe one event. The time field is floating point, while the other fields are all integers. Logically, there is an array of vehicles indexed by vehicle number, an array of roads, indexed by road number, and an array of intersections indexed by intersection number. Events themselved are arranged in a logical array of events indexed by event number, but note, event numbers are arbitrary. The next field organizes events into a linked list, sorted in chronological order, with the head of the list being the head of the event set, the next event to simulate.
That's a data structure. ........ Javadoc, or rather, the style of commenting that Javadoc uses, is an example of a broad class of techniques described as literate programming. The old, low-tech approach to programming is to develop code and documentation as entirely separate documents. You write the program here, and you create a web page or other document describing the program there, using unrelated tools and unrelated languages. Perhaps you write the program in C++ and then write the documentation using Microsoft Word.
In 1984, Donal Knuth published a book, Literate Programming, that encourages a different approach. In Knuth's model, the programmer creates a single document that incorporates program fragments woven into the documentation for that program. Knuth provided two tools for processing this document. One tool traverses the document, weaving together the program fragments into a program in the target programming language, while the other tool traverses the document, typesetting human readable text to document that program.
Knuth's tools for supporting literate programming were WEB (for Pascal programs) and later CWEB (for C programs). Noweb was derived from this as a language-independent literate programming environment, and many others have followed in this direction.
Javadoc is not quite the same as Knuth's idea, but it is in the same broad category. Unlike Knuth's idea, Javadoc does not allow the order or structure of the Java program to be assembled "out of order" or rather, in the order that makes sense to the programmer, as opposed to the language. It does, however, support the idea of creating a single document from which documentation and code can be derived.
Let's look at a simplified small example class from our highway network simulator:
// ScanSupport.java
import java.util.regex.Pattern;
import java.util.Scanner;
public class ScanSupport {
public interface ErrorMessage {
abstract String myString();
}
public static void lineEnd( Scanner sc, ErrorMessage message ) {
String skip = sc.nextLine();
if (!"".equals( skip )) {
Errors.warning(
message.myString() +
" -- expected a newline"
);
}
}
private static final Pattern name = Pattern.compile( "[A-Za-z]\\w*" );
public static String nextName( Scanner sc, ErrorMessage message ) {
if (sc.hasNext( name )) {
return sc.next( name );
} else {
Errors.warning(
message.myString() +
" -- expected a name"
);
return null;
}
}
}
The only comment above is the one identifying the file name. There are numerous places in this code where we can put Javadoc