firing of transition with guard only ?

[jdeantoni]

Dear Yakindu experts,

I have an issue with simple statecharts like this one:

In Yakindu @EventDriven mode, even if test is initialized to true then the state charts stays in stateA. When initialized at false and changed to true then it still rests in stateA.

I'm wondering what is the expected behavior. In the SCXML specifications transitions with guard only are enabled if the condition is becoming true: https://www.w3.org/TR/2015/REC-scxml-20150901/#SelectingTransitions ; and is fired during any macro step.

In Rhapsody the semantics seems to be the one of SCXML also and is resumed as: "A transition can consist of only a guard. The low-to-high transition of the condition (or Boolean value) is considered to be the triggering event" (https://www.ibm.com/support/knowledgecenter/SSB2MU_8.3.0/com.ibm.rhp.uml.diagrams.doc/topics/rhp_t_dm_spfing_guard.html). All my students are actually expecting this behavior and myself too.

In the generated java code, it is always possible to as explicitly for a run cycle after each variable set but my intuitive understanding is that it should be done in the setter.

Could you please clarify the semantics followed by Yakindu and its rational ? thanks in advance

[tkutz]

From my understanding, Yakindu does not behave differently from SCXML nor Rhapsody in that regard.

Setting a variable is not triggering a run-to-completion step (or what is called macrostep in the SCXML doc). I think the Rhapsody documentation is just not clear in their wording. They also say "...all guards without triggers are tested every time an event happens". And further down, "Each time this event occurs, the state machine evaluates the two guards...". Omitting the event on the transition just means that it is checked for every event that occurs, but it still needs some event to occur. For me, this indicates the same behavior as in the @EventDriven mode of Yakindu.

If you don't want to have events triggering a run-to-completion step, you can use the @CycleBased mode to have it triggered periodically.

[jdeantoni]

Dear Thomas,

thanks for the answer. I'm still not sure since in the SCXML spec, at the link I provided, you can read (excerpt)

To simplify the following definitions, we introduce the event NULL. NULL has no name and is used only in these definitions. It never occurs in the event queues of an SCXML Processor. All other events have names and are distinct from NULL. (In effect, NULL is a pseudo-event that is used in these definitions as a trigger for eventless transitions.)

A transition is enabled by NULL in atomic state S if a) T lacks an 'event' attribute, and b) T's source state is S or an ancestor of S and c) T lacks an 'cond' attribute or its 'cond' attribute evaluates to "true". (Note that such a transition can never be enabled by any named event.)]

[Definition: A microstep consists of the execution of the transitions in an optimal enabled transition set.]

From this I understood that it should be fired. Also in Rhapsody since "The low-to-high transition of the condition (or Boolean value) is considered to be the triggering event" then the bold part of your comment should also encompass the low-to-high transition of the condition.

I know I can use CycleBased but it introduces delays due to sampling time.

Finally, the very same model in the SCXML Qt editor (https://doc.qt.io/qt-5/qtscxml-index.html) provides a different result (it ends in stateB

[tkutz]

Okay, I read the SCXML docs again and my understanding now is that event-less (NULL) transitions are taken at the end of a macrostep when all other events are consumed. Consider this example:

When myEvent is invoked, StateB gets active, and then all event-less transitions are checked, making the state machine go to StateC. Same holds for your example, as the event-less transitions are also checked after the initial state is activated. What I do not read out in the specification is that merely changing the value is also considered to trigger a macrostep.

In Rhapsody, things might be different. I don't know enough about Rhapsody, but it is possible that changing a property value is considered being an event that triggers a step.

So yes, Yakindu behaves differently. In @EventDriven mode, the state machine does only react to events (or time triggers). Having an event-less transition is the same as putting the always trigger on the event, which makes it react to every event that is processed. But just changing a property value is not considered to be an event.

That said, you can do the following to get closer to the desired behavior: If you want to have SCXML code and behavior in the end, you can use the SCXML domain. The simulation will then invoke an SCXML interpreter. If you want to generate Java code, you can consider enabling super steps semantics with @SuperSteps(yes). The behavior will be still different than what is specified by SCXML or Rhapsody, but your and my example models would end up in the desired states.

[jdeantoni]

Dear Thomas,

thanks for the clear explanations. I'll read about superstep semantics.

A last minor question to see if it is a workaround. Considering changing a value in an event-less guard from the code (the setter from the SCInterface). Is it safe to explicitly invoke the runcycle() method after the value setter ? In this case it somehow acts as a trigger from the value change; and the behavior is the expected one.

thanks again

[tkutz]

Yes, that sounds like a valid workaround for me. However, in the recent version of Yakindu, we changed the APIs, so that runCycle() is no more visible from the outside for event-driven statecharts (only for cycle-based ones). So probably you will be able to do it only with 3.x. versions, and not with the 4.x version.

[terfloth]

Providing triggers derived from variable changes makes sense. Here is an excerpt of an internal task (which is not scheduled yet):

In addition to events statecharts define a set of state variables in their interface. Changes to these variables should be considered as events wich are processed according to the existing event execution semantics.

To be backwards compatible and provide a consistent definition inion of semantics the following issues are considered:

• changing or 'overloading' existing guard only transition semantics is not desired
• change triggers must be specified explicitly
• the extension must be consistent with existing language concepts

Two approaches are possible:

1. specify trigger property on declaration: @trigger var x : integer
2. specify change trigger on transition: x@changed [x > 100] / doSomething()

As an extension to the second alternative also change events on expression could be implemented:

• (x > 100)@changed
• (x > 100)@becomes(true)

[jdeantoni]

thanks for the complementary answer. This is quite interesting.

just a personal feeling: At a first glance it seems to me that specifying the annotation in the interface is more intuitive and make the state chart simpler (and more classical) to read. Consequently, it means that every usage of the variable is subject to "guard only" transition and of course that every expression where it is used is also concerned.

I'm not sure if there are situations where this is not the case and where we want to choose transition by transition the semantics to be applied. It is also worth noticing that in this case it seems that we can always specify explicitly the trigger (e.g., every Xms [x > 0])

my two cents