Technical Manual

[ Return to Technical Manual Index ]

System Structure - GUI/Model Communication

General Overview

The GUI/Model communication could have been implemented in two different manners. In the first implementation, Java's NMI would have been used to invoke methods within the model, which would have been developed as C++ Library. The following is a diagram of the basic structure of such an implementation:

NMI Diagram

In the second implementation, the one that is used, communication is accompolished via the standard output and standard error streams, after the model is started via an exec call within the Java code. The following diagram illustrates this structure:

Streams Diagram

Data Flow Overview

GUI Activity Diagram

To begin execution of the model, the start button at the bottom of the file tab is clicked. Once the start button is clicked, a flow of data is begun which results in the execution of the model.

When the start button is clicked, a CommandObj, a java data object which maintains all of the necessary attributes needed to invoke the model, is built, and its fields are set. Another object, ModelTalker, is then instantiated, and, since it is implemented as a Java thread, it is started with the CommandObj passed as one of its parameters.

The ModelTalker then begins execution within its own thread. Here it uses the CommandObj to start the Model, passing in the proper command line arguements to the C++ program. Once the model is started, the ModelTalker gets the standard output and standard error streams from the C++. It then instantiates and starts two thread objects, StderrTalker, and StdoutTalker, passing them as parameters the CommandObj. More importantly, it passes StderrTalker the standard error stream taken from the C++ model, and it passes to StdoutTalker the standard output stream taken from the model.

The two thread objects then begin their own separate execution. StderrTalker creates an instance of JOuputWindow, stderrWin, makes it visible, and begins passing the text received via the standard input stream to the stderrWin, where it can be displayed in the scrolling text window. The basic function of StderrTalker is to redirect the verbose output of the model to a Java window.

StdoutTalker, is similar to StderrTalker, except its purpose is to setup the visualization windows for the model, parse the visualization information generated by the model, and direct the visualization info to the proper JGraphicWindow where it can be displayed. The model generates visualization information, and writes it to standard out using our own specialized protocol. To learn about this protocol, click here.

The JOutputWindow is a simple window with a single scrollable text field which receives lines of text and appends that text to the end of the text field.

The JGraphicWindow contains a JChart which uses a line graph in order to display the values of a particular variable over time.

Java Implementation Details ( Class by Class ) Link to Java Class Descriptions

The Visualization Protocol ( These are suggestions for implementation)

The variables that are to be graphed must be specified by the user in some manner within the GUI. These specifications must then be stored in the CommandObj, so that these options can be eventually passed to the StdoutTalker object. There has to be some restrictions on the number of variables that can be graphed at any one time.

Within StdoutTalker the information garnered from the CommandObj must be used to instantiate the various JGraphicWindows, associate each JGraphicWindow with the variable(s) that it will graph, and register the JGraphicWindows as GraphicOutputEvent listeners.

The stream protocol produced by the model over the standard output stream should follow a attribute-value format. It should pass streams in the following format :

vname=<variable name>&value=<variable value>&time=<time>

This stream can then be easily parsed by StdoutTalker. Once parsed, StdoutTalker would build a GraphicOutputEvent using the values parsed, and the, using the variable name, it would determine the appropriate JGraphicWindow to fire the GraphicOutputEvent to.

Java Class descriptions

Suggestions for Implementing this as an Applet

Applet Framework

Implementing this program using an Applet that can run the C++ model from any browser will require quite a bit of changes, primarily due to the overhead required by the distributed nature of an Applet.

As seen in the diagram above, a Java servlet will have to be created in order to communicate with the GUI. This servlet will be the class which will need to take over responsibilty for starting the model, and for writing the standard out, and standard error streams back to the client side classes.

Changes will need to be made in order to account for the communication across the network.

Also, due to the security restrictions imposed on Applets, the filechooser will not work.

Originating Author: Skip Walker, first draft 4/6/99