Initially, it may seem that integrating two applications together via a command pipeline would be difficult to implement and unwieldy to administer. Instead of developing a single application which shares all the necessary information internally, the designer must instead maintain two separate applications, and ensure that they are both able to understand each other's protocol when it comes time for the two software units to share information. Despite this apparent drawback, there are several noticeable benefits from this strategy.
From a purely software engineering perspective, splitting the implementation into two separate units enforces very loose coupling between the two applications, thereby making each of the units more autonomous and cohesive. The two software units do not even share a single global variable between them. As a result, significant changes can be made in one module without adversely affecting the other. By making the two units separate, we only share as much information as necessary between them via the command pipeline. Had the two modules been tightly bound together, the temptation to share numerous data structures between them would be very strong. Subsequent changes to these data structures would have repercussions that would permeate throughout the entire implementation. By modularizing the GUI and the simulator engine, the effects of radical implementation changes in one module do not usually extend into the other module, hence localizing the impact of the changes.
By creating a clear implementation distinction between the GUI and the simulator engine, it becomes much easier to remove one of the modules and replace it with another that has similar capabilities. For example a different GUI written in an entirely different language may be placed on top of the existing simulator engine. The two will still be able to communicate with one another as long as the new GUI provides the simulator engine with the necessary details regarding the structural design of the circuit and can parse the output waveform results generated by the simulator engine.
Alternatively, instead of replacing modules, we could augment the system
relatively seamlessly by adding new modules. For example, if one were
doing a comparison of two different discrete-event simulators, the same
GUI could be employed to invoke either of the simulators. It is a
trivial matter to enhance the GUI to invoke one of several possible
simulator engines.
Of
course, any new modules added to the environment would have to be made
to conform with the four phase communication process described in
Section 5.4.
Another advantage of rigidly partitioning the GUI and the simulator engine into two distinct applications is that it establishes a framework by which the two units may eventually communicate with each other at the socket level. This could lead to several benefits since this implies that the GUI and the simulator engine do not necessarily have to be running on the same machine. For example, several people could conceivably be working on the design of a different circuit subsystem using different GUIs on very limited graphics terminals. The simulator engine they all use, however, could be running on a high-powered machine which is accessible to all. The transmission of the structural circuit information to the so-called ``simulation server'' would be transparent to the end user. With socket support forthcoming in the Tcl core, this option of distributing the GUI and the simulator engine over several machines will become realizable. Of course, an efficient distribution of the GUI and simulator engine over several machines would have to take into consideration the potential communication delays inherent within any network. Similarly, effectively distributing the circuit representation over several machines for simulation would necessitate an intelligent partitioning of the circuit's subcomponents in such a way so as to minimize network traffic between machines.