COMP 310
Spring 2010

HW05:  Self-modifying Finite State Machine

Home  Info  Owlspace  Resources

The Demo

The demo should load and display automatically.
It is an Honor Code violation to attempt to reverse compile the supplied demo.

In a nutshell, the demo shows a finite state machine with the ability to transition from state to state.   Run-time selectable options will modify the state transition behavior.  The tool tips in the demo will tell you most of what everything does.

Descriptons of Selected Operations

Description of the Options  (Be sure to change back to No-op after you are done inserting or deleting!)

The Assignment

In this assignment, you are to replicate the behavior of this demo. You will deliberately be given less direction in this assignment, as you will be expected to take on more of the design decisions and implementations yourself.

You will be using Dr. Wong's extended visitor design pattern implementation, whose code will be supplied.  It should be noted that the generics specifications of this implementation should be considered a "work in progress" and any suggestions for improvements are most welcome.  As the required generics specifications are non-trivially complicated and can have subtle concequences, it is highly recommended that any suggestions be approved by Dr. Wong before you attempt to use them in your assignment code.

Read the extended visitor documentation here.  (Note: includes the documentation for the supplied GetIdxAlgo and ILambda classes -- see below)

UML Diagram of the Extended Visitor Design Pattern Implementation
Extended visitor UML

Download the supplied code here.

Assignment Notes:


  1. In the self-modifying finite state machine, each state is an extended visitor host, labelled by its identifying index.
  2. The transitions from one state to another are represented by an extended visitor that when executed by the current state, returns the next state.
  3. While it is possible to create an implementation that mutates the active state into the next state, the management of an informative and intuitive view can be under that scenario can be somewhat tricky and involved -- please let the staff know if plan to persue that sort of implementation.
  4. A very convenient manner of storing states such that they can be easily accessed by their index values is  Map (dictionary) structure, of which the most common implementation is HashMap.
  5. Each state should have a notion of being "active" or "inactive" and that state should be reflected in the UI where the active state is a different color.
  6. Transition algo:
    1. For any undefined states in the transition algo, the default behavior should be to transition to an available state or a "null" state if the states map is empty.
    2. The system should be able to handle available states that never get transitioned to.   To see this in the demo, after a transition algo has been made, make more states and watch the no-op transitions. 
  7. Transition Options:
    1. Since the options for the transition algo are instantiated by the model, who controls what options are available, they need to dynamically added to the JComboBox in the view.
    2. The transition algo should never be checking which option is to be run and doing different things depending on which option is selected.   The option to run should simply be the selected option, independent of whatever it is.
  8. Suggestions
    1. Use a counter that keeps track of the total number of states created since the last time the states were cleared.   Any new state will have an index equal to this count.   This eliminates two hosts having the same index.
    2. Use private methods to help isolate tasks, such as creating a transition algo, creating a IExtVisitorCmd objects, making and managing states, etc.
    3. First write the transition algo without involving the options.  Once that is working, add the option capability in.


  1. You are welcome to redesign the GUI so long as it contains the same functionality in an intuitive, user-friendly manner.
  2. In adherance with the MVC pattern, the states, even though they are dynamically generated, should have a separate view that is completely decoupled from anything in  the model.
  3. In the demo, the states are represented in the view as dynamically created JLabel objects added to a JPanel.  
  4. The greyed-out buttons are due to calling that button's setEnabled() method with the appropriate value when certain operations occur.   This prevents inappropriate interactions.
  5. The JSpinner component uses a SpinnerNumberModel to create an available set of integers from 1 to 100.   The following line of code was added to the autogenerated GUI code (nStatesSpin is the name of the JSpinner variable):
    nStatesSpin.setModel(new SpinnerNumberModel(1, 1, 100, 1));


Assignment requirements:

  1. Use the extended visitor design pattern to represent the states and transitions.
  2. Use MVC throughout, including for individual states.   The model and view should be completely decoupled.
  3. Transition options are dynamically created.
  4. The method invoked in the model my the "Step Transition Algo" button, should do nothing more than:
    1. Deactivate the current state
    2. Run the transition algorithm on the current state, assigning the return value to be the new current state.
    3. Activate the current state.
  5. The view should have tool tips to aid the user in using the program.
  6. View should clearly indicate which state is the active (current) state.
  7. The transition algo options are dynamically added to the view.   The view should have no knowledge of what options are installed.
  8. The transition algo should not be testing to see which option has been selected.


© 2010 by Stephen Wong