0% found this document useful (0 votes)
69 views29 pages

EFSM Code Generation v4 1x2

This document discusses code generation from extended finite state machines (EFSMs). It begins with an example of an EFSM modeling a keyboard and formal definitions of EFSM components like states, events, actions, and transitions. It then outlines different coding schemes for implementing EFSMs, including nested switch statements, state tables, and object-oriented designs. The document aims to introduce EFSM modeling and techniques for generating code from EFSM specifications.

Uploaded by

Kapil
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
69 views29 pages

EFSM Code Generation v4 1x2

This document discusses code generation from extended finite state machines (EFSMs). It begins with an example of an EFSM modeling a keyboard and formal definitions of EFSM components like states, events, actions, and transitions. It then outlines different coding schemes for implementing EFSMs, including nested switch statements, state tables, and object-oriented designs. The document aims to introduce EFSM modeling and techniques for generating code from EFSM specifications.

Uploaded by

Kapil
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 29

Code Generation from Extended

Finite State Machines

Insup Lee
Department of Computer and Information Science
University of Pennsylvania

Originally prepared by Shaohui Wang


Modified by Insup Lee for CIS 541, Spring 2010

Outline

 Definition of Extended Finite State Machines

 General Code Generation Schemes

 Introduction to The EFSM Toolset

Spring '10 CIS 541 2


EXTENDED FINITE STATE
MACHINES

Extended Finite State Machines

 A Keyboard Example

 Formal Definitions

 Variants
EFSM: A Keyboard Example
initial self
transition transition trigger action list

state ANY_KEY / generate lowercase code


keystrokes++ guard

default ANY_KEY [keystrokes > 100,000]

final
state variable
CAPS_LOCK CAPS_LOCK
variable

state capsLocked ANY_KEY [keystrokes > 100,000]


transition
guard
ANY_KEY / generate uppercase code
keystrokes++
Spring '10 CIS 541 6

EFSM: Definitions

 An EFSM consists of
o Extended States, Guards, Events, Actions, and Transitions.
 A state is a situation or condition of a system
during which
o some (usually implicit) invariant holds,
o the system performs some activity, or
o the system waits for some external event.
 An extended state is a state with “memory”
o E.g., using 100,000 states to count 100,000 key strokes;
or, using one extended state with a variable “count”.

Spring '10 CIS 541 7


States vs Extended States
Example: Counting Number of Keystrokes (<= 100,000)

States Extended States


 One state represents one  One state represents all
number  Needs one state with one
 Needs 100,000 states variable

key key key …. key


key / keystrokes++
Keystrokes=100,000

Keystrokes=2

Keystrokes=1
No concept of variable „keystrokes‟, using One state and one variable to
different states to represent them. represent all.
Spring '10 CIS 541 8

EFSM: Definitions

 Guards are
o boolean conditions on extended state variables which
enables or disables certain operations (e.g., change of
states).
o evaluated dynamically based on the extended state
variable values.
o immediate consequence of using extended state variables.
 An event
o is an occurrence in time and space that has significance to
the system.
o may also be parametric which conveys quantitative info.
Spring '10 CIS 541 9
EFSM: Definitions

 Actions
o are performed when an event instance is dispatched.
o include
 changing a variable;
 performing I/O;
 invoking a function;
 generating another event instance; or
 changing to another state (state transition).
 Transitions
o can be triggered by events.
o can also have a guard.

Spring '10 CIS 541 10

EFSM Variants: An Example

 Two Communicating EFSMs


o with event channel “press”

 How to model “pressing twice fast”?


o need time variables – timed automata

Spring '10 CIS 541 13


EFSM: Variants

 Input/output Variables
o can serve as enhanced messages in communicating EFSMs
 Communicating EFSMs
o input/output events are properly defined to convey info
o EFSMs communicate by sending and receiving events via channels
 Timed Automata
o “clock” variables are added, increasing automatically as
 clock ticks (discrete) or
 time elapses (continuous)
 Hierarchical EFSMs
o inside a state, the system behavior is also like an EFSM

Spring '10 CIS 541 14

STATE MACHINE CODING


SCHEMES
State Machine Coding Schemes

 State Machine Interface


 A Running Example
 Coding Schemes
o Nested Switch Statement
o State Table
o Object-oriented State Design Pattern
o Multiple-threaded Implementation
 Tradeoffs between EFSM Implementations

State Machine Interface

 Three methods
o init() – take a top-level initial transition
o dispatch() – dispatch an event to the state machine
o tran() – take an arbitrary state transition
 Each coding scheme virtually implements these
 To use an EFSM in the main logic of the code
o create an EFSM instance
o invoke init() once
o call dispatch()
 repetitively in a loop
 or sporadically based on detected events
o dispatch() will then call the corresponding trans() function

Spring '10 CIS 541 17


The C Comment Parser Example

 A comment in the C language: /* comments */


CHAR

code
SLASH SLASH

star CHAR,
SLASH
slash
CHAR

STAR
STAR
STAR
comment

CHAR,
SLASH

The Nested Switch Statement

 Nest switch statement with


o a scalar state variable in the first level for states,
o an event signal in the second level, and
o transition logic (actions) in the innermost level

 Two alternatives
o Switch with events first and then states
o Use one switch that combines both.

Spring '10 CIS 541 19


The Nested Switch Statement: Example
enum Signal { // enumeration for CParser signals
CHAR_SIG, STAR_SIG, SLASH_SIG
};

enum State { // enumeration for CParser states


CODE, SLASH, COMMENT, STAR
};

class CParser1 {
private:
State myState; // the scalar state-variable
long myCommentCtr; // comment character counter
state machine interface
/* ... */ // other CParser1 attributes
public:
void init() { myCommentCtr = 0; tran(CODE); } // default transiton
void dispatch(unsigned const sig);
void tran(State target) { myState = target; }
long getCommentCtr() const { return myCommentCtr; }
};

Spring '10 CIS 541 20

The Nested Switch Statement: Example


first switching the states
void CParser1::dispatch(unsigned const sig) {
switch (myState) {
then switch signals inside each state
case CODE:
switch (sig) { finally the
case SLASH_SIG:
business
tran(SLASH); // transition to SLASH
logic
break;
}
break;
then switch signals inside each state
case SLASH: case COMMENT:
switch (sig) { switch (sig) {
case STAR_SIG: case STAR_SIG:
myCommentCtr += 2; tran(STAR);
tran(COMMENT); break;
break; then switch signals inside each state
case CHAR_SIG:
case CHAR_SIG: case SLASH_SIG:
case SLASH_SIG: ++myCommentCtr;
tran(CODE); break;
break; }
} break;
break;

Spring '10 CIS 541 21


The Nested Switch Statement: Example
one more time, for state STAR
case STAR:
switch (sig) {
case STAR_SIG:
++myCommentCtr; // count STAR as comment
break;
case SLASH_SIG:
myCommentCtr += 2; // count STAR-SLASH as comment
tran(CODE); // transition to CODE
break;
case CHAR_SIG:
myCommentCtr += 2; // count STAR-? as comment
tran(COMMENT); // go back to COMMENT
break;
}
break;
}
}

Spring '10 CIS 541 22

The Nested Switch Statement

 Nest switch statement with


o a scalar state variable in the first level for states,
o an event signal in the second level, and
o transition logic (actions) in the innermost level
 Advantages
o Simple and straightforward – just enumeration of stats and triggers
o Small memory footprint – only a state variable necessary
 Disadvantages
o Does not promote code reuse
 all elements of an EFSM must be coded specifically for problem at hand.
o Manual code is prone to errors
 when logic becomes complex
o Difficult to maintain in view of design change

Spring '10 CIS 541 23


State Table

 A table of arrays of transitions for each state


o function pointers are stored for easy management
o fast event dispatching
 store states and signals as integers, then calculate with pointer offsets
trans *t = tableAddress + state * numSignals + sig;

Signals 
CHAR_SIG STAR_SIG SLASH_SIG

code doNothing(),
States 
slash
slash doNothing(), a2(), doNothing(),
code comment code
comment a1(), doNothing(), a1(),
comment star comment
star a2(), a1(), a2(),
comment star code

* a1() and a2() are respective action functions

Spring '10 CIS 541 24

State Table

 Advantages
o Direct mapping from a tabular representation of an EFSM
o Fast event dispatching
o Code reuse of the “generic event dispatching process”
 Disadvantages
Signals 
o Table maybe large
CHAR_SIG STAR_SIG SLASH_SIG
and wasteful
code doNothing(),
States 

slash
slash doNothing(), a2(), doNothing(),
code comment code
comment a1(), doNothing(), a1(),
comment star comment
star a2(), a1(), a2(),
comment star code

* a1() and a2() are respective action functions

Spring '10 CIS 541 25


State Table: Example
a generic state table class
class StateTable {
public:
struct for transitions
typedef void (StateTable::*Action)();
struct Tran {
Action action; struct for transitions
unsigned nextState;
};
StateTable(Tran const *table, unsigned nStates, unsigned nSignals)
: myTable(table), myNsignals(nSignals), myNstates(nStates) {}
fast dispatching
virtual ~StateTable() {} // virtual xctor
void dispatch(unsigned const sig) {
register Tran const *t = myTable + myState*myNsignals + sig;
(this->*(t->action))();
myState = t->nextState;
}
void doNothing() {} private:
protected: Tran const *myTable;
unsigned myState; unsigned myNsignals;
}; unsigned myNstates;

Spring '10 CIS 541 26

State Table: Example


table size
// specific Comment Parser state machine ...
enum Event { CHAR_SIG, STAR_SIG, SLASH_SIG, MAX_SIG }; constructing
enum State { CODE, SLASH, COMMENT, STAR, MAX_STATE }; customized state
table
class CParser2 : public StateTable { // CParser2 state machine
public:
CParser2() : StateTable(&myTable[0][0], MAX_STATE, MAX_SIG) {}
void init() { myCommentCtr = 0; myState = CODE; } // initial tran
long getCommentCtr() const { return myCommentCtr; }
private:
void a1() { myCommentCtr += 1; } // action method
void a2() { myCommentCtr += 2; } // action method
private:
static StateTable::Tran const myTable[MAX_STATE][MAX_SIG];
long myCommentCtr; business logic
// comment character counter
}; implemented as
private functions
static field of the table
holding the
state table

Spring '10 CIS 541 27


State Table: Example
filling out the table
#include "cparser2.h" statically

StateTable::Tran const CParser2::myTable[MAX_STATE][MAX_SIG] = {


{{&StateTable::doNothing, CODE },
{&StateTable::doNothing, CODE },
{&StateTable::doNothing, SLASH}},

{{&StateTable::doNothing, CODE },
{static_cast<StateTable::Action>(&CParser2::a2), COMMENT },
{&StateTable::doNothing, CODE }},

{{static_cast<StateTable::Action>(&CParser2::a1), COMMENT },
{&StateTable::doNothing,STAR },
{static_cast<StateTable::Action>(&CParser2::a1), COMMENT }},

{{static_cast<StateTable::Action>(&CParser2::a2), COMMENT },
{static_cast<StateTable::Action>(&CParser2::a1), STAR },
{static_cast<StateTable::Action>(&CParser2::a2), CODE }}
};

Spring '10 CIS 541 28

State Design Pattern [Gamma+ 95, Douglass 99]

 An abstract state class


o defines a common interface for handling events
o each event corresponds to a virtual method
 Concrete states are subclasses of an abstract state class
 A context class delegates all events for processing to the
current state object (myState variable)
 State transitions are explicit and are accomplished by
reassigning the (myState variable)
 Adding new events corresponds adding it to the abstract
state class
 Adding new states is to subclass the abstract state class

Spring '10 CIS 541 29


State Design Pattern [Gamma+ 95, Douglass 99]
(1)

(1) A class for abstract states, contains all possible


signals as virtual methods.
Spring '10 CIS 541 30

State Design Pattern [Gamma+ 95, Douglass 99]

(2)

(2) A state in an EFSM is an object of a subclass of the


CParserState. (CodeState, SlashState, etc.)
Spring '10 CIS 541 31
State Design Pattern [Gamma+ 95, Douglass 99]

(3)

(3) The parser has exactly one object for each concrete
state class (e.g., myCodeState, mySlashState, etc.)…
Spring '10 CIS 541 32

State Design Pattern [Gamma+ 95, Douglass 99]

(4)

(4) … as well as a myState variable, which can points to


any of them.
Spring '10 CIS 541 33
State Design Pattern [Gamma+ 95, Douglass 99]

(5)

(5) State transition is just reassigning myState variable.

Spring '10 CIS 541 34

State Design Pattern [Gamma+ 95, Douglass 99]

(6)

(6) Event dispatching relies on C++ virtual function


dispatching rules. (If concrete class has the method, use
it; otherwise use the virtual methods.) – Fast dispatching.
Spring '10 CIS 541 35
State Design Pattern: Example
The same story
once more, in code.
class CParserState { // abstract State
public:
virtual void onCHAR(CParser3 *context, char ch) {}
virtual void onSTAR(CParser3 *context) {}
virtual void onSLASH(CParser3 *context) {}
};
class CodeState : public CParserState { (1) A class for abstract states,
// concrete State "Code"
public:
contains all possible signals as
virtual void onSLASH(CParser3 *context);
};
class SlashState : public CParserState {
virtual methods.
// concrete State "Slash"
public:
virtual void onCHAR(CParser3 *context, char ch);
virtual void onSTAR(CParser3 *context);
};
(2) A state in an EFSM is an object of
class CommentState : public CParserState { //concrete State "Comment"
....
}; a subclass of the CParserState.
class StarState : public CParserState {
....
(CodeState, SlashState, etc.)
// concrete State "Star"

};

Spring '10 CIS 541 36

State Design Pattern: Example


The same story
once more, in code.
class CParser3 { // Context class
friend class CodeState;
friend class SlashState; (3) The parser has exactly
friend class CommentState;
friend class StarState;
one object for each concrete
static CodeState myCodeState; state class (e.g.,
static SlashState mySlashState;
static CommentState myCommentState; myCodeState, mySlashState,
static StarState myStarState; (4) … as well as a myState
etc.)…
CParserState *myState; variable, which can points to
long myCommentCtr; (5)
any State transition is just
of them.
reassigning myState variable.
public:
(6)
void init() { myCommentCtr = 0; tran(&myCodeState);Event
} dispatching relies
on C++ virtual function
void tran(CParserState *target) { myState = target; }
long getCommentCtr() const { return myCommentCtr; }
dispatching
void onCHAR(char ch) { myState->onCHAR(this, ch); } rules. (If concrete
void onSTAR() { myState->onSTAR(this); }
void onSLASH() { myState->onSLASH(this); } class has the method, use it;
};
otherwise use the virtual
methods.) – Fast dispatching.
Spring '10 CIS 541 37
State Design Pattern: Example
The same story
once more, in code.
#include "cparser3.h“

CodeState CParser3::myCodeState;
SlashState CParser3::mySlashState;
CommentState CParser3::myCommentState;
StarState CParser3::myStarState;

void CodeState::onSLASH(CParser3 *context) {


context->tran(&CParser3::mySlashState);
}
void SlashState::onCHAR(CParser3 *context, char ch) {
context->tran(&CParser3::myCodeState);
} (7) Implementation of
....
void StarState::onSTAR(CParser3 *context) { individual actions are writing
}
context->myCommentCtr++;
transition functions on need.
void StarState::onSLASH(CParser3 *context) { (Default behavior is
context->myCommentCtr += 2;
context->tran(&CParser3::myCodeState); doNothing() as in the
}
virtual function.)
Spring '10 CIS 541 38

State Design Pattern [Gamma+ 95, Douglass 99]

 Advantages
o It localizes state specific behavior in separate (sub)classes.
o Efficient state transition – reassigning a pointer.
o Fast event dispatching – using C++ mechanism for function look up.
o Parameterized events made easy – passing function parameters.
o No need for enumeration of states or events beforehand.
 Disadvantages
o Adding states requires creating subclasses.
o Adding new events requires adding handlers to state interface.
o In some situations where C++ or Java is not supported (e.g., some
embedded systems), mockups of OO design maybe an overkill.

Spring '10 CIS 541 39


Multiple-threaded Implementation

 Approach I
o Each EFSM is implemented inside one thread.
o Threads run simultaneously, scheduled in round-robin.
o EFSMs share variables in the process.
 Advantage
o Straightforward transformation from model.
o EFSM communication easily implemented with thread messages.
 Disadvantage
o In some situations, no ready thread support in specific platform.
o Related analysis (progressiveness if semaphores are used, timing
properties, etc) may be difficult.

Spring '10 CIS 541 40

Multiple-threaded Implementation

 Approach II
o Event detectors are implemented in threads.
o Transition actions are implemented in functions.
o Location information is stored with a variable.
o When event detector threads detects, calls corresponding functions
and switching locations.
 Advantage
o Easy adaption to model changes.
 Disadvantage
o In some situations, no ready thread support in specific platform.
o Code may be unstructured/unreadable.

Spring '10 CIS 541 41


Multiple-threaded Implementation: Example
(Approach II)

void *trans3(void *ptr) {


int t;
 A transition logic is written inside a
while(1) { function
sem_wait(&Sense);
o Wait for semaphore for triggering
if(current==WAIT_VRP && TRUE) {
t=getTimer(&v_x); signal.
printf("Sense:%d\n", t); o If succeeded, check state
clearTimer(&v_x);
(WAIT_VRP) and guard (TRUE).
current=ST_IDLE;
sem_post(&ST_IDLE); o Execute updates.
}  Print out timer value (for debugging)
}  Reset timer value
}
 Change state
int main(int argc, char *argv[]) {
pthread_t thread1, thread2,thread3;  All threads initialized and run in main
// ... initilization code ...
pthread_create( &thread1, NULL, trans1, NULL);
pthread_create( &thread2, NULL, trans2, NULL);
pthread_create( &thread3, NULL, trans3, NULL);
pthread_join( thread1, NULL);
return 0;
}

Spring '10 CIS 541 42

Optimal EFSM Implementation

 Does there exist one?


 A trade off based on
o platform (available libraries? languages to use?)
o purpose of coding
 just for implementation or for analysis?
 what type of analysis? etc.
o efficiency requirement
o possibility of model changes

Spring '10 CIS 541 43


THE EFSM TOOLSET

The EFSM Toolset

 Introduction
 The EFSM Language
 Checking for Non-determinism and Totality
 Translations to Other Languages
 Test Generation from EFSMs
 Script Generation
 Code Generation
 Simulation
Introduction to EFSM Toolset

 Targets designers and engineers without specialized


training in formal methods
 Uses easily human-readable languages in description
 Features
o based on communicating EFSMs
o using communication channels as well as shared variables
o with input, output, and local variables

Spring '10 CIS 541 46

The EFSM Language

 Example
SYSTEM LampSystem:
Channel: press, sync, B;
EFSM Lamp {
States: off, low, bright;
InitialState: off;
LocalVars:
bint[0..5] y =0,
boolean x = false;
Transition: From off to low when true==true do press ? x , y =0;
Transition: From low to off when y>=5 do press ? x;
Transition: From low to bright when y<5 do press ? x;
Transition: From bright to off when true==true do press ? x;
}
EFSM User {
States: idle;
InitialState: idle;
LocalVars:
boolean x = false;
Transition: From idle to idle when true==true do press ! x;
}

Spring '10 CIS 541 47


The EFSM Language: Channels

 Specification: Channel: <name>, <type>, <r/w/b>;


o <type> maybe “sync” or “async”
 “sync”: one-to-one, blocking synchronization of two EFSMs
 “async”: one-writer-to-many-readers, non-blocking for writer, non-
consuming from the readers, asynchronous
o <r/w/b> – reader channel, writer channel, or both
 Communication action: <channel name> <action> <arg>
o <action> can be !, ?, !!, ??
 ! means writing, ? means reading
 single mark means synchronous; double marks means asynchronous
o <arg> is a typeless value

Spring '10 CIS 541 48

Non-determinism and Totality

 Definitions
o An EFSM is non-determinism if there exists some state
with two or more outgoing transitions which maybe
enabled at the same time.
o An EFSM is total (or complete) if at any state S, there is at
least one outgoing edge enabled.
 Checking Non-determinism and Totality
o The EFSM Toolset utilizes the satisfiability checker zChaff
 systematically transform logic formula over guards to DIMACS
(zChaff accepted format)
 feed into zChaff and interpret the result

Spring '10 CIS 541 49


Non-determinism and Totality

 Example: A system with a bounded integer x in [1..5] and


(1) From start to discard if x<=4;
(2) From start to use if x>3;
(3) From start to redo if x==5;
 To check for non-determinism for the “start” state, we need to check
(a) (x<=4) ∧ (x>3)
(b) (x<=4) ∧ (x==5)
(c) (x>3) ∧ (x==5)
which are transformed to (xk means x==k is true)
(a) (x1 ∨ x2 ∨ x3 ∨ x4) ∧ (x4 ∨ x5)
(b) (x1 ∨ x2 ∨ x3 ∨ x4) ∧ (x5)
(c) (x4 ∨ x5) ∧ (x5)
 (a), (c) are satisfied, which means there are non-determinisms between
o the first and the second transitions, and
o the second and the third transitions

Spring '10 CIS 541 50

Translations to Other Languages

 Table – CSV format most Spreadsheet programs can open


 Text – Human readable text file
 Dotty – Input format of the “dot” program for drawing
 Promela – The Spin model checker input language
o systems with only synchronous channels are supported now
o setting channel buffer size to 0 in Promela
 Uppaal – The Uppaal model checker XML format
o systems with only synchronous channels are supported now
o value passing must take place through shared variables
 SMV format – the NuSMV model checker
o currently supports systems without communication channels
o shared variables are supported
o can utilize the verification results from NuSMV for test case generation

Spring '10 CIS 541 51


Test Generation from EFSMs

 Test Generation
o create a set of traces through the EFSM
o for testing an implementation of the system
o coverage criteria
 state coverage – go through each state at least once
 transition coverage – ensures that every transition is take once
 definition-use coverage – makes a trace from every definition of a
variable to each of its subsequent uses
 Output of Test Generation
o a sequence of assignments of variable values
o necessary to lead the EFSM to take particular paths

Spring '10 CIS 541 52

Test Generation from EFSMs

 Model Based Approach using NuSMV

 Direct Test Generation Algorithm


o DFS algorithm to discover set of paths covering all states
o It keeps track of constraints and assignments along the path.
o A transition can be added to the path if compatible with other constraints.
o The algorithm starts with initial state and a set of constraints corresponding
to the initial assignments of variables.
o If a transition can be added (compatible), add it and make a recursive call.
o Can keep a snapshot of visited states to guarantee termination.
o Need to use a satisfiability checker.

Spring '10 CIS 541 53


Script Generation

 Script Generation
o takes a set of traces (from test generation)
o makes a set of scripts
o which can be run on an implementation
 Approach

Spring '10 CIS 541 54

Code Generation

 Allows mapping state machine variables to arbitrary input/output


functions
o input function is called each time the variable is read
 condition like x==2 will be translated to readX()==2
o output function is called each time the variable is written
 assignment like x:=y-2 will become writeX(y-2)
 C
o limited to single EFSM model without communication channels
o repeatedly executing a series of if-else statements like
 if (state==X and condition==c) { doSomething(); … }
 Java
o supports multiple communicating machines, utilizing JCSP library
o each EFSM is run inside a thread, and they are all run in parallel
o scheduled round-robin

Spring '10 CIS 541 55


Example: Generated Code Snippet in C

while (transition_taken) {
transition_taken=0;
if ((currentState==1)&&(current < getNumBots())) {
PRE_TRANSITION_HOOK;
current=current+1;
currentState=2;
transition_taken=1;
//printf("rolling:From:incrementTo:check
//Guard:current <=numBotsAction:current=current+1\n");
POST_TRANSITION_HOOK;
}
....
if ((currentState==2)&&(getSwitch()==1)) {
PRE_TRANSITION_HOOK;
setAllAngles(1);
currentState=1;
transition_taken=1;
//printf("rolling:From:checkTo:increment
//Guard:switchValue==trueAction:setAngles=true \n");
POST_TRANSITION_HOOK;
}
}

Spring '10 CIS 541 56

Example: Generated Code Snippet in Java

import jcsp.lang.*;
public class gaitThread implements CSProcess {
private final String name="gaitThread"; ....
public gaitThread() {}
public void run() {
final Skip skip= new Skip(); ....
while ( true ) {
switch (alt.priSelect()) {
case 0:
if ((currentState.equals("footArming")) & (TwoSecondDelay == true )) {
currentState="spineArming";
System.out.println("gait: From: footArming
To:spineArming
Guard:TwoSecondDelay== true
Action:spine=-20");
}
if ((currentState.equals("spineArming")) & (TwoSecondDelay == true)) {
....
} ....
....
}
}
}
Spring
} '10 CIS 541 57
Simulation with the EFSM Toolset

 Simulator generates Java code


which walks through the EFSM
model.
 At each step, it asks the user for
input variable values, if any.
 Example screen on the right.
o Either choose variables to set value and
“Step”, or
o Auto with “Probabilistic”.
 Simulator reports error message if
no transitions available.

Spring '10 CIS 541 58

References

 Miro Samek, Practical Statecharts in C/C++,


CMPBooks, 2002
o Source code available online
o http://www.state-machine.com/psicc/
 David Arney, EFSM Toolbox Manual, University of
Pennsylvania, 2009

Spring '10 CIS 541 60


Thank you!

Spring '10 CIS 541 61

You might also like