SCXML 1.0

Re http://www.w3.org/TR/scxml/


This schema is a highly useful contribution. We have already started to use it in our application system, which supports automated
testing of mobile and distributed systems.

Considerations for robust and testable state machines are presented in chapter 7 of my book, _Testing Object-Oriented Systems:
Models, Patterns, and Tools_ (TOOS). http://www.rbsc.com/pages/TOOSMPT.htm


I suggest adding two optional attributes: 

1) For each state, an invariant specification:

  <state id="STATE" invariant="anInvariant"></state>

The invariant specifies the name of a procedure (method) which returns a Boolean type. The procedure evaluates conditions defined
over the state variables, which define the named state. 

TOOS, chapter 7, provides a detailed discussion of invariants and their interpretation in composite state machines.


2) For each transition, an "response" specification 

  <transition event="EVENT" response="accept"></transition>

The "response" attribute specifies an action taken when the event is presented to the state machine implementation. This allows a
practical implementation of a "complete specification" of the FSM, i.e., that all state/event pairs are explicitly given. Harel
diagrams (and others like it) do not require an explicit response for every event on every state.  Is often said that unspecified
events are "ignored". This is a convenient simplication for modeling, but when it comes to implementing the state machine, something
concrete must be done when an unspecified event is presented. 

The response attribute is not the same as the processing which may be performed to implement the transition, nor is it the same as a
transition guard. Instead, it designates how unspecified, implicit transitions are to be processed.

The response can be the keywords "accept" "queue", "ignore", "flag", "reject", "mute", "abend".  This allows a complete
specification of the machine and specification of error handling. 

The default value for response would be "accept". 

TOOS, Table 7.3 provides a list of actions and explains the motivation for each response keyword.


Bob Binder

-------------------------------------------------------------------
mVerify Corporation                         www.mVerify.com 
350 N. Orleans St., Suite 950               tel 312 881 2054
Chicago, IL 60654                           cel 312 404 5341
"A Million Users in a Box" (R)              fax 312 881 2001

Received on Friday, 28 October 2005 05:38:27 UTC