better clarification for semantics of orthogonal regions and the final states for each regions #1033

Open
vahdat-ab opened this Issue Apr 2, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@vahdat-ab
Member

vahdat-ab commented Apr 2, 2017

Please consider the following example:

class X{
  sm{
    s1{
      -> s2;
     r1{
       e1-> w1;
     } 
     w1{
       e2-> w2;
     }
     final w2{}
     
     ||
     
     r2{
       e3-> m1;
     }
     m1{
      e4-> m2; 
     }
     final m2{}   
    }
    s2{
      h2-> fState;
    }
    final fState{}
  }
}

Region r and region r2 have their own final states and there is an auto-transition for the super state s1. Currently, Umple considers this as an unguarded event and removes all internal transition for state s1.
if I'm not wrong, the auto transition must be activated once both regions are in their final states. It means we should not remove those internal transitions.
This needs more clarification. I might miss sth.

@vahdat-ab

This comment has been minimized.

Show comment
Hide comment
@vahdat-ab

vahdat-ab Apr 2, 2017

Member

Could you please comment on this issue. I might be wrong
@TimLethbridge
@opeyemiAdesina

Member

vahdat-ab commented Apr 2, 2017

Could you please comment on this issue. I might be wrong
@TimLethbridge
@opeyemiAdesina

@jblang94

This comment has been minimized.

Show comment
Hide comment
@jblang94

jblang94 Apr 4, 2017

Contributor

@vahdat-ab after reading through UML 2.5, and browsing through other resources, I believe that this behaviour is formally referred to as Completion Transitions and Completion Events.

Here are some of the search terms I used:
"orthogonal regions final states"
"completion transitions state machines"
"completion events state machines"

UML 2.5 Definition

14.2.3.8.3 Completion Transitions and completion events
A special kind of Transition is a completion Transition, which has an implicit trigger. The event that enables this trigger is called a completion event and it signifies that all Behaviors associated with the source State of the completion Transition have completed execution. In case of simple States, a completion event is generated when the associated entry and doActivity Behaviors have completed executing. If no such Behaviors are defined, the completion event is generated upon entry into the State. For composite or submachine States, a completion event is generated under the following circumstances:

  • All internal activities (e.g., entry and doActivity Behaviors) have completed execution, and
  • if the State is a composite State, all its orthogonal Regions have reached a FinalState, or
  • if the State is a submachine State, the submachine StateMachine execution has reached a FinalState.

In the example you've provided, I believe the completion event is when r1 reaches its final state w2, and r2 reaches its final state m2. The completion transition is -> s2.

Here are more resources I found that provide information regarding "Completion transitions and completion events":

Orthogonal Region Example
Non-Concurrent "ATM" Example --> Note the eventless transition from ServingCustomer to Idle

I also found this Orthogonal Region "CourseAttempt" Example from a website
that I believe is @TimLethbridge's.
It is also contained in the UML 2.5 documentation Figure 14.9 Composite State with Regions
From this page on the same website:

A transition to a final state represents the completion of behavior in the enclosing region. Completion of behavior in all orthogonal regions represents completion of behavior by the enclosing state and triggers a completion event on the enclosing state. Completion of the topmost regions of an object corresponds to its termination.

Here is a StackOverflow page in which Join and Completion Event and Transition are compared.

I think we've partially implemented the Join behaviour from the solution for #140, since delete()is only called when all of the state machines within an orthogonal region are in their final states. If we implement the completion transition, I think it would require replacing the delete() call with a call to the completion transition. In your example, the call would be __autotransition1__()

Contributor

jblang94 commented Apr 4, 2017

@vahdat-ab after reading through UML 2.5, and browsing through other resources, I believe that this behaviour is formally referred to as Completion Transitions and Completion Events.

Here are some of the search terms I used:
"orthogonal regions final states"
"completion transitions state machines"
"completion events state machines"

UML 2.5 Definition

14.2.3.8.3 Completion Transitions and completion events
A special kind of Transition is a completion Transition, which has an implicit trigger. The event that enables this trigger is called a completion event and it signifies that all Behaviors associated with the source State of the completion Transition have completed execution. In case of simple States, a completion event is generated when the associated entry and doActivity Behaviors have completed executing. If no such Behaviors are defined, the completion event is generated upon entry into the State. For composite or submachine States, a completion event is generated under the following circumstances:

  • All internal activities (e.g., entry and doActivity Behaviors) have completed execution, and
  • if the State is a composite State, all its orthogonal Regions have reached a FinalState, or
  • if the State is a submachine State, the submachine StateMachine execution has reached a FinalState.

In the example you've provided, I believe the completion event is when r1 reaches its final state w2, and r2 reaches its final state m2. The completion transition is -> s2.

Here are more resources I found that provide information regarding "Completion transitions and completion events":

Orthogonal Region Example
Non-Concurrent "ATM" Example --> Note the eventless transition from ServingCustomer to Idle

I also found this Orthogonal Region "CourseAttempt" Example from a website
that I believe is @TimLethbridge's.
It is also contained in the UML 2.5 documentation Figure 14.9 Composite State with Regions
From this page on the same website:

A transition to a final state represents the completion of behavior in the enclosing region. Completion of behavior in all orthogonal regions represents completion of behavior by the enclosing state and triggers a completion event on the enclosing state. Completion of the topmost regions of an object corresponds to its termination.

Here is a StackOverflow page in which Join and Completion Event and Transition are compared.

I think we've partially implemented the Join behaviour from the solution for #140, since delete()is only called when all of the state machines within an orthogonal region are in their final states. If we implement the completion transition, I think it would require replacing the delete() call with a call to the completion transition. In your example, the call would be __autotransition1__()

@TimLethbridge

This comment has been minimized.

Show comment
Hide comment
@TimLethbridge

TimLethbridge Apr 5, 2017

Member

This will require me to study what we said recently about another issue where we discussed auto-transitions. Could you please find me that to save me time. Then I can look at all the semantics together.

Member

TimLethbridge commented Apr 5, 2017

This will require me to study what we said recently about another issue where we discussed auto-transitions. Could you please find me that to save me time. Then I can look at all the semantics together.

@jblang94

This comment has been minimized.

Show comment
Hide comment
@jblang94

jblang94 Apr 5, 2017

Contributor

@TimLethbridge from #140 here is the link that @vahdat-ab referenced regarding his concern of how auto-transitions are supposed to be handled in orthogonal regions in Umple.
You followed up to his comment with:

I acnknowledge @vahdat-ab 's concern. He pointed to a link showing UML semantics that includes regions that can independently reach final states, but not terminate the enclosing state, with a 'completion' transition occurring when all regions do reach their final state. Presumably, the same logic in UML would apply in any nested state (i.e. just one region in a state). The example Vahdat pointed to also shows joins. We have not implemented this sort of thing in Umple currently and it would be a considerable piece of work to do so.

In the same issue, one of the earliest comments suggested that a Done keyword should be added to Umple. I did not find any further discussion on it but I've put it here for your reference:

We have also agreed to add another keyword done that is actually a real state that can
exist in any state machine.

Done will work as follows:

We will add automatic outgoing transitions ( transitions without any event on it)

If there is an automatic transition then a transition to Done will cause this to be
taken (subject to guards, and of course there can be more than one such transition
with different guards, however to prevent getting 'stuck' in a state at Done, there
would need to always be one unguarded automatic transition, even if it is just a loop
back to the same state).

In the case of a state with concurrent regions. then the automatic transition will
take place when all of the regions reach done.

There will be a warning if there is a transition to Done without the presence of any
automatic transition.

Done is not syntactically shown as a state, so there can be no entry actions, exit
actions or do activities while in done state.

Contributor

jblang94 commented Apr 5, 2017

@TimLethbridge from #140 here is the link that @vahdat-ab referenced regarding his concern of how auto-transitions are supposed to be handled in orthogonal regions in Umple.
You followed up to his comment with:

I acnknowledge @vahdat-ab 's concern. He pointed to a link showing UML semantics that includes regions that can independently reach final states, but not terminate the enclosing state, with a 'completion' transition occurring when all regions do reach their final state. Presumably, the same logic in UML would apply in any nested state (i.e. just one region in a state). The example Vahdat pointed to also shows joins. We have not implemented this sort of thing in Umple currently and it would be a considerable piece of work to do so.

In the same issue, one of the earliest comments suggested that a Done keyword should be added to Umple. I did not find any further discussion on it but I've put it here for your reference:

We have also agreed to add another keyword done that is actually a real state that can
exist in any state machine.

Done will work as follows:

We will add automatic outgoing transitions ( transitions without any event on it)

If there is an automatic transition then a transition to Done will cause this to be
taken (subject to guards, and of course there can be more than one such transition
with different guards, however to prevent getting 'stuck' in a state at Done, there
would need to always be one unguarded automatic transition, even if it is just a loop
back to the same state).

In the case of a state with concurrent regions. then the automatic transition will
take place when all of the regions reach done.

There will be a warning if there is a transition to Done without the presence of any
automatic transition.

Done is not syntactically shown as a state, so there can be no entry actions, exit
actions or do activities while in done state.

@TimLethbridge

This comment has been minimized.

Show comment
Hide comment
@TimLethbridge

TimLethbridge Apr 6, 2017

Member

OK. I see the long-ago discussion about having 'done' as a transition indicating 'final within a nested state', and retaining 'final' to mean 'delete the object'. However it seems we have deviated from that. I am willing now to accept the logic that says 'auto transition must be activated once both regions are in their final states. It means we should not remove those internal transitions.

Member

TimLethbridge commented Apr 6, 2017

OK. I see the long-ago discussion about having 'done' as a transition indicating 'final within a nested state', and retaining 'final' to mean 'delete the object'. However it seems we have deviated from that. I am willing now to accept the logic that says 'auto transition must be activated once both regions are in their final states. It means we should not remove those internal transitions.

@jblang94

This comment has been minimized.

Show comment
Hide comment
@jblang94

jblang94 Apr 23, 2017

Contributor

To give whomever is assigned this issue a head start, here are the main steps that are required for this change:

  1. Update the checkStateForDuplicateEvents method in UmpleInternalParser_CodeStateMachine.ump so that W054 is not thrown for auto-transitions when there are user-defined final states. If you compile Vahdat's example, you'll see this warning is currently generated.

  2. For nested-state machines, update the prepareFinalStatesFor method in Generator_CodeJava.ump so that auto-transitions are called when the state machine transitions into a user-defined final state.

  3. For concurrent state machines (orthogonal regions), update prepareConcurrentFinalStatesFor in Generator_CodeJava.ump so that auto-transitions are called when all orthogonal regions are in their user-defined final states.

Contributor

jblang94 commented Apr 23, 2017

To give whomever is assigned this issue a head start, here are the main steps that are required for this change:

  1. Update the checkStateForDuplicateEvents method in UmpleInternalParser_CodeStateMachine.ump so that W054 is not thrown for auto-transitions when there are user-defined final states. If you compile Vahdat's example, you'll see this warning is currently generated.

  2. For nested-state machines, update the prepareFinalStatesFor method in Generator_CodeJava.ump so that auto-transitions are called when the state machine transitions into a user-defined final state.

  3. For concurrent state machines (orthogonal regions), update prepareConcurrentFinalStatesFor in Generator_CodeJava.ump so that auto-transitions are called when all orthogonal regions are in their user-defined final states.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment