[IGSTK-Developers] State Machine requirements

[Kevin Gary]

At the 1-year review meeting with came away with some decisions w.r.t.
state machines that I do not see documented in the requirements. Specifically,
moving all appropriate component state machines to the "AttemptTo" pattern,
and ensuring all state machine transition tables are fully populated. I do
not see this in the requirements list - may I add them? Luis, should it be
you?

I'm asking because we are working through our requirements for a validation
tool that includes static structural analysis of IGSTK state machines,
and these would be two things we check for.

The fully populated state transition table is a particularly interesting one,
as to do exhaustive testing, here are some of the numbers for some of our SMs:

Class		#States		#Inputs		Node	Edge	Path
View		2		15		1	15	225
Tracker		10		9		9	90	9^10
PulseGenerator	4		7		3	28	7^4 (2401)
Spatial Object	4		10		3	40	10^4 (10k)
Landmark3DReg.	9		7		8	63	7^9 (> 40M)
SerialCommun.	11		11		10	121	11^11 (>285M)

The numbers for node, edge, and path indicate number of test cases required,
with some assumptions (no loops, path length = #nodes). In practice path
tests could be much higher. Then if we do scenarios across multiple component
SMs...

Thanks,
Kevin G.


-- 
===
Kevin A. Gary, Ph.D.
Assistant Professor
DCST, ASU East
(480)727-1373
http://kgary2.east.asu.edu
kgary at asu.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kgary.vcf
Type: text/x-vcard
Size: 369 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20051213/bf3270e8/attachment.vcf>