[IGSTK-Developers] State Machine requirements

[Hui Zhang]

Hi, Luis and Kevin (G),

I am thinking of a way to make the state machine transition tables to be 
fully populated in the class test. Do you think it is possible?

The states and inputs of each class is enumated for state-machine driven 
class, so that the edges in the transitions table can be full tested by 
setting the each state and input. I read some source code of test programs, 
and it seems like not all the edges are fully passed. For exmaple, a class 
may have states: A, B, C, D, and inputs: I1:A->B, I2:B->C, I3:C->D.... In 
general, the test code for this class will go by A->B->C->D, and not test 
what will happen when A->C, A->D, and so on. A brute-force test can make 
sure all the path of the table will be passed. But if we add this manually 
to each class test, that would dramatically increase the coding work for 
each class. So I think a way to add some functions in the core 
igstkStateMachine class and be called by all igstk classes.

The pseudo code can be like those:

igstkStateMachine::BruteForceStateMachineTest()
{
    SetGeneralInputParameters();
    for each state
        for each input
            SetInitialState( state);
            SetInputParameters();
            PushInput( input);
            ValidateResult(); // I am not sure whether this line of function 
is needed or not to verify the result for each state.
        end for
    end for
}

igstkStateMachine::SetInputParameters and 
igstkStateMachine::SetGeneralInputParameters functions are declared as 
virtual functions, and can be implemented in each derived igstkclass if the 
class wants to set the specific ones. If the igstkclass wants to test random 
input paramters, it can be easily implemented too. The work for 
igstkStateMachine is to add one function - 
igstkStateMachine::BruteForceStateMachineTest, and declare two virtual 
functions.

For each existed igstkclass, it can set those temporary member variables in 
the SetInputParameters function like those:
igstkClass::SetInputParameters()
{
    switch each state
    state 1:
        m_XXXToBeSent = ....;
        .....;
        break;
    state 2:
         ....
} or generally
igstkClass::SetGeneralInputParameters()
{
    m_XXXXToBeSent = ....;
    .....
}
If the igstkClass doesn't want to set those specific parameters, nothing 
need to do for existed class.

For the class test progam, it only requies to add one line:
igstkClass->BruteForceStateMachineTest();

Regards,
James


----- Original Message ----- 
From: "Luis Ibanez" <luis.ibanez at kitware.com>
To: "Kevin Gary" <kgary at asu.edu>
Cc: "shylaja kokoori" <Shylaja.Kokoori at asu.edu>; "IGSTK" 
<igstk-developers at public.kitware.com>
Sent: Wednesday, December 14, 2005 5:21 PM
Subject: Re: [IGSTK-Developers] State Machine requirements


>
> Hi Kevin,
>
> Thanks for pointing this out.
>
> You are right, we have not started to enforce these
> requirements for the State Machine.
>
> I just added the requirements to the Wiki page for
> Iteration7:
>
> http://public.kitware.com/IGSTKWIKI/index.php/R2_I7_REQ#State_Machine
>
>
> What we can do immediately is to add a check to the
> SetReadyToRun() method in the State Machine, in order
> to verify the completeness of the transition table.
>
> If the table is not full, then the SM will report a
> fatal error to the logger and refuse to run.
>
> The new macros for observing events, and translating
> them into inputs should make easier the implementation
> of the AttemptTo pattern.
>
>      igstkEventTransductionMacro()
>      igstkLoadedEventTransductionMacro()
>
>
> We will have to code-review every class in order to identify
> where this pattern is missing and should be introduced.
>
>
>    Luis
>
>
> -----------------
> Kevin Gary wrote:
>> 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.
>>
>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>