Finite State Machine Simulator Design Document The State Machine Simulator was developed by Kyril Faenov as a term project for Object Oriented Programming class in Fall, 1995. Overview: -------- State Machine Simulator (SMS for short) allows user to edit in a drag-and-drop fashion a finite state machine and simulate, step-by-step its execution with specified input string of tokens. It allows 10 states (numbered 0 through 9) and 26 different tokens ('a' through 'z'). State machines and associated input strings can be saved and loaded to/from files. SMS is implemented in Java - Sun Microsystem's new OO language, that is emerging as a preferred language for Internet programming. (For more info on Java see Java's WWW home page at http://java.sun.com/). Being implemented in Java, SMS can be executed as an applet within HTML pages, while being browsed by Java-enabled browsers like Netscape 2.0. It conforms to the Beta API and can also be executed standalone by AppletViewer provided with the Java Development Kit. Class Hierarchy: --------------- SMS consists of the following classes: Simulator Input (abstract class - parent of FileInput and TokenInput) FileInput TokenInput TokenSelection AboutBox QuitDialog Machine State Transition InputString Help +----------+-----------+----Simulator---+-----------------+ | | | | | | | | | | | | | | | | | | v v v | v v AboutBox QuitDialog FileInput | TokenInput TokenSelection | | | | | | | | | | +--------+-------+-----------------+ | | | | | | | | v | | Help | v | Machine------------------------+ | | | | | | v v State InputString | ^ ^ | | | v | | Transition----------------------+ Class Descriptions: ------------------ Simulator a subclass of Java Applet and server as the root class. It creates and lays out the interface, initiates Help and Machine instances, dispatches repaint requests to them and handles user input. User input comes from pressing on control buttons or clicking with the mouse anywhere in the applet's panel. Button presses typically either display a sub-panel giving user a chance to enter some required data, or change the control state, which defines how to interpret mouse clicks. When mouse is clicked anywhere in the panel, actions are taken depending on the control state. Simulator interacts with the machine object when in needs to pass it new user input or requests certain actions. Simulator does not know anything about States, Transitions or Input String - it only sees the entire Machine. AboutBox and QuitDilaog are simple panels with no relation to the machine itself. AboutBox displays the program title and QuitDialog asks confirmation to exit the program, and if users answers yes - exits the application. FileInput, TokenInput and TokenSelection are means of entering information to the state machine. They are an extension of the Simulator in this respect. This is why they know about the Machine and Help instances. TokenSelection also uses two constants from the InputString class, even though it does not use any instances of that class. FileInput and TokenInput are subclasses of Input abstract class. They share common structure - text line for input and OK button. All the subclasses implement is passing the data to the Machine itself. Machine class keeps track of states. It contains an array of them and forwards all commands to them. Simulator passes the Machine x and y coordinates on the screen and Machine figures out what state is located there, and performs the necessary operations on it. It also is responsible for the current input string. Machine can simulate the token processing by forwarding the current token, obtained from the InputString between states. Machine can save and load itself recursively to/from files. It forces states and input string to load/save themselves. State class represents one state. It knows how to draw itself on the screen, knows its own location and keeps track of all the Transitions originating from it. It simulates taking and passing the token, and implements state machine logic by keeping track of how many transitions can handle the current token. It can load and save itself and all the transitions belonging to it from/to a file. It saves/loads the transitions by requesting that they do it themselves. Transition class knows of the states that it originates from and ends at. It draws itself on the screen depending on the location of the two states it is attached to. It contains the array of flags that tell it which tokens it can fire for. This is the basis for checking if particular transition is to be taken for a given token. It can save and load itself to/from a file. It uses the state constants from InputString class to find out how many possible tokens there is. It does not use any instances of it. InputString simulates a string of tokens. It knows how to draw itself on the string, knows its positions within the string and can be persuaded to change it. It returns current token, checking that it is valid. It can also save and load itself from/to a file. For more information, please refer to comments in the source code.