Download Restrained re-engineering

Requirements of HC-Sim imposed by HC-Sim GUI
Language compatibility
The source code of HC-Sim must be kept C++ compatible. The main reasons are
simplified integration of HC-Sim and HC-Sim GUI, and the ability to throw exceptions
upon error (see Choice of programming language, page 45). Note that this restriction also
works the other way around, since HC-Sim should still be ANSI-C compatible.
Integration code
HC-Sim must include (detachable) code to interact with the GUI in order to store precise
simulation data, and to allow user interaction through the user interface to affect the
simulation.
Cleanup and reset
The original HC-Sim philosophy was run once, cleanup is done automatically when the
program exits. This may be true, to some extent, when running the program once per
simulation. Through the GUI, however, an arbitrary number of simulations are run for
each program session. After each simulation, all files and handles must be closed, and
memory on the heap must be freed. Before running the next simulation, all stateful data
must be reset to initial values.
Merging the requirements
It comes as no great surprise that many of the requirements mentioned are in direct
conflict with one another. Whereas for some of them the requirements imposed by
HC-Sim and those imposed by HC-Sim GUI may be compromised, some of them may
not. Creating a spin-off version of HC-Sim for the sake of integrating it with a GUI is one
way to handle these conflicts. Another solution is to make the program compile one way
when a GUI is present and another way when it is not. In the light of the requirement that
as little code as possible should be added to HC-Sim anyway, the latter would seem
feasible and also more reasonable than creating a whole new project.
Analyzing the feedback
Displaying statistics
Displaying statistics with printlines
In the command-line based version of HC-Sim, each packet whose IP-header has been
compressed or decompressed results in a simple printout to the console. The print includes
the source of the packet along with a short description of the IP-header structure, followed
by an extract of the first bytes of data of the unit. For special events, such as when a
packet is lost, damaged or cannot be decompressed, a warning message is also printed. A
summary of the statistics and results of the simulation are not displayed until the
simulation has been completed. The summary covers information about how long the
simulation was run, how the compression turned out, and how many packets were restored
or failed (see HC-Sim test-run excerpt below).
One obvious flaw of this way of presenting data is the flow of the data itself. Because
packets are generally handled at a rate that by far exceeds a normal human being’s ability
to read, the data will never be interpreted, and hence it has no informational value. And
even if the user would manage to read the printout, for instance by slowing down the
packet rate or printing the output to a file, he would not be able to get a clear view of what
is going on. The reason is that the massive load of data does not yield a structured
overview of the simulation status. The main problem is that the summary is not printed
16