b r a y d e n . o r g / Software

/ WebHome / StateCharts / StateChartToolFeatures / ScenarioCodeGenerator

This Web


WebHome  
Topic List  
Web Statistics 

All Webs


Books
Main
Random
Software
TWiki  

brayden.org


Home
Monthly Digest
Today's Links
Resumé
Reading List
Books RSS
Random RSS
Software RSS

Other


Dale's Blog

currently-reading
TextDrive

Scenario Code Generator (SCG)

SCG has been pretty handy. It's a Windows application that looks a little like Windows Explorer: a tree view on the left representing the states, interfaces, and 'events', and a large editing area on the right with tabs for selecting what part of a state, transition, or event you will edit. You add new states, interfaces, and events via a popup menu followed by a little properties pane on the right-side of the UI.

I use GraphViz to produce a state machine diagram on demand. This gives us the benefits of having a diagram without the headaches of using a diagram as the state definition input method.

The EventMechanism in SCG is pretty elegant. It knows how to read TypeLibrary? input, so to define the events that will trigger transitions you point SCG at an ActiveX DLL or OCX or TypeLibrary?. It reads the TypeLibrary? contents and presents a list of interfaces exposed by that library. You select an interface (or CoClass). SCG figures out whether there is an associated event interface. Then it gives you the option of saying that your state machine will implement the interface, or sink the events from the event interface. SCG also knows how to parse VB code (ummm, SCG is actually rather VB-centric ... blush) so private (non-COM) classes from your application are also available as event sources.

SCG uses XML as its persistence mechanism. It also has a ReverseEngineering? feature that allows you to make changes to the generated code and easily import it back into the state model - in fact one quickly gets into the habit of doing just that before making editing changes within SCG.

In all, this has been a good tool. However, there are reasons why StateCharts are preferable to finite (flat) state machines. ErrorHandlingInStateCharts? is one - very often there is a sequence of states that all need to do the identical error or mode checking. With a FiniteStateMachine? you need to add that checking to each state. With StateCharts you define a ParentState? that listens for the appropriate event, and its ChildStates? can be coded without worrying about that particular checking.

Here's a screenshot - click on the thumbnail to see a full-sized image.

-- DaleBrayden - 23 Jul 2002

 
 
Current Rev: r1.3 - 28 Feb 2003 - 00:35 GMT - DaleBrayden, Revision History:Diffs | r1.3 | > | r1.2 | > | r1.1
© 2003-2011 by the contributing authors.