A Graphical DRFSM Interface

In developing the framework for reverse engineering, it has proven desirable to have a quick and easy means for modifying the DRFSM which drives the exploration process. This was accomplished by modifying an existing reactive behavior design tool, GIJoe, to accommodate producing the code of DRFSM DEDS.

GIJoe was designed by Mark Bradakis at the University of Utah[1]. It allows the user to graphically draw finite state machines, and output it as C code. The graphical user interface allows the user to place states and transitions with a mouse. Transitions can be labelled with boolean combinations of symbols, such as ``A and B or C''. When the state machine is complete, the user selects a start state and clicks a ``Compile'' button to output C code which duplicates the structure of the machine. The machine can be saved and later modified for different applications.

The code output by the original GIJoe has an iterative structure that is not conducive to the recursive formulation of dynamic recursive finite state machines. Therefore, it was decided to modify GIJoe to suit our needs. Modifications to GIJoe include:

• Output of recursive rather than iterative code to allow recursive state machines.
• Modification of string parsing to accept recursive transition specification.
• Encoding of an event parser to prioritize incoming events from multiple sources.
• Implementation of the variable transition vector (VTV) acquisition (when making recursive transitions.)

The event parser was encoded to ensure that the automaton makes transitions on only one source of input. Each new event type requires the addition of a suitable event handler. New states and transitions may be added completely within the GIJoe interface. The new code is output from GIJoe and may be linked to the exploration utilities with no modifications. The code produced by the machine in Figure 9 was tested using a text interface before being linked with the rest of the experimental code.

Future modifications may include the addition of ``output'' on transitions, such as ``TouchOccurred/UpdateModel'', allowing easy specification of communication between modules. It should be clear, however, that the code generated by GIJoe is only a skeleton for the machine, and has to be filled by the users according to the tasks assigned to each state.

In general, GIJoe proved to be a very efficient and handy tool for generating and modifying such machines. By automating code generation, one can reconfigure the whole exploration process without being familiar with the underlying code (given that all required user-defined events and modules are available).