locked
Accepting States and Model Parameterization RRS feed

  • Question

  • Dear All,

    on my model I apply the sequential composition operator (;).
    Only to accepting states sequences can be added, so I simply start with all model states accepting:

            public static bool Switch = true;
    
            [AcceptingStateCondition]
            public static bool Accept
            {
                get
                {
                    return (Switch == true);
                }
            }
    

    But I also need accepting states for having the test always end in a save state.
    So my idea was to finally switch off the unwanted accepting states (except the save states - not shown here) with a parameterization:

    machine AccumulatorModelProgram() : Main 
    {
        {. Switch = false; .} :
        (construct model program from ParameterCombination)
    }

    This nearly works: Only the initial state is now accepting.
    The problem is that an action with no state change at all (state checker) paradoxically causes a state change: it will "make" the initial state non-accepting.
    This creates unwanted states.

    Is this correct, or shouldn't also the initial state be non-accepting now?

    Is it possible to make all states non-accepting with parameterization?

    Thank you for any help

    Monday, October 31, 2011 1:11 PM

Answers

  • Hello, Bubuda,

    This issue is actually by-design now in Spec Explorer. The root cause is that embedded C# code in cord will be invoked after initial states are initialized. A work-around would be having some code to exclude the initial state from accepting states: you can either add some code in your model, or design another machine invoking at least one action.

    Thanks,

    Xiang

    • Proposed as answer by Xiang LiModerator Tuesday, November 1, 2011 1:41 AM
    • Marked as answer by bububa Tuesday, November 1, 2011 12:01 PM
    Tuesday, November 1, 2011 1:41 AM
    Moderator

All replies

  • Hello, Bubuda,

    This issue is actually by-design now in Spec Explorer. The root cause is that embedded C# code in cord will be invoked after initial states are initialized. A work-around would be having some code to exclude the initial state from accepting states: you can either add some code in your model, or design another machine invoking at least one action.

    Thanks,

    Xiang

    • Proposed as answer by Xiang LiModerator Tuesday, November 1, 2011 1:41 AM
    • Marked as answer by bububa Tuesday, November 1, 2011 12:01 PM
    Tuesday, November 1, 2011 1:41 AM
    Moderator
  • Hello Xiang,

    thank you very much. Though your second hint perfectly worked and looked simpler (I just added a dummy-action in front), I added/changed my code for another problem with this approach.

    Thank you again for the explanation!

    Tuesday, November 1, 2011 12:05 PM