New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Final state and End state in Umple along with Done and automatic transition. #140

Closed
Nava2 opened this Issue Aug 26, 2015 · 20 comments

Comments

Projects
None yet
4 participants
@Nava2
Member

Nava2 commented Aug 26, 2015

Originally reported on Google Code with ID 240


Umple current status:

Umple currently specifies that a final state is any state in the state machine without
any outgoing transitions. However, if the state is within a composite state machine
(i.e has a parent state or region), then even if the state has no outgoing transitions,
it is not an Final state since a transition out of this state can still take place.
For example, in the attached figure 1, B is not a final state even though there is
no transition out of the state B (but there is a transition out of the parent state
A).

UML 2.4 specifications:

According to UML specifications, when a final state is entered, it implies that the
containing region is completed, as well as all containing regions. If within a state
machine, all regions with a final state enters their final states, then the whole state
machine is completed and the state machine terminates (not clear what happens when
a state machine terminates. Possibly, one can delete the object containing the state
machine?).

Proposed change:

Add support for End state and Final state.

An End state is a state without any outgoing transitions. End states can not have entry
or exit actions, or regions, or substates. There can be more than one end state within
a state machine, or within a region.

A Final state means that the whole state machine terminates. Termination means that
any running do activities are killed, and the object containing the state machine is
deleted. Notice that doing so may kill other do activities in other state machines
that are within the same object.
Final states must not have regions, entry or exit actions, do activities, or substates.
There can be more than one final state within a state machine or within a region. Final
state must have at least one incoming transitions.

Syntax:
No special keywords for an end state.
Use the keyword final before the name of a state.


Reported by @obahy on 2011-10-13 16:46:21

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

I suggest just

event -> final;

where final becomes a keyword for an end state. There would be no behavioural difference
for multiple final states, so no need to define more than one. Final would result in
deletion of the object once all concurrent regions also reach a final state,

However what if a second concurrent region transitions out of the region to an entirely
different state? I suggest the semantics be that the 'finalness' be then abandoned
(although if could be restored if a transition to history occurred, since being final
would be a valid possibility for history.

There will have to be lots of test cases to get this right


Reported by @umple on 2011-10-13 19:24:18

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by @umple on 2011-10-13 19:26:14

  • Labels added: Component-Syntax
@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

We have agreed to resolve this such that any transition to Final causes deletion


Reported by @umple on 2012-01-13 23:05:41

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

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.


Reported by @umple on 2012-02-15 17:58:55

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by @obahy on 2012-04-02 12:30:26

  • Blocked on: #34
@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by @umple on 2012-12-31 18:18:45

  • Status changed: Accepted
  • Blocked on: #191
  • No longer blocked on: #191
@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by @umple on 2014-01-31 18:59:48

@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by @umple on 2014-08-05 19:05:34

  • Owner changed: pedroaugusto3000
@Nava2

This comment has been minimized.

Member

Nava2 commented Aug 26, 2015

Reported by @umple on 2014-09-05 15:09:27

  • Owner removed
  • Labels added: ucosp, Diffic-Med
@vahdat-ab

This comment has been minimized.

Member

vahdat-ab commented Feb 14, 2017

@jblang94 explore the semantic of final. Looks like there is a mixed-up concept for the final state. This might be related to issues #152 and #925

@vahdat-ab

This comment has been minimized.

Member

vahdat-ab commented Feb 14, 2017

what proposed here must be explored and summarized for the final implementation. Looks like may conflicts exist

@jblang94

This comment has been minimized.

Contributor

jblang94 commented Feb 14, 2017

@vahdat-ab Thanks! I will take a deeper dive into this issue after I have finished issues #935 and #778

@jblang94 jblang94 self-assigned this Mar 19, 2017

@jblang94

This comment has been minimized.

Contributor

jblang94 commented Mar 24, 2017

@vahdat-ab Here is my research into the semantics of final states so far:

It was difficult to find exact semantics for final state, but I found the following definitions. The search term combinations I used included "what is a final state in a uml state machine", "uml statemachine final state semantics".

https://www.visual-paradigm.com/VPGallery/diagrams/State.html
"A special kind of state signifying that the enclosing region is completed. If the enclosing region is directly contained in a state machine and all other regions in the state machine also are completed, then it means that the entire state machine is completed."

https://www2.warwick.ac.uk/fac/sci/physics/research/condensedmatt/imr_cdt/students/david_goodwin/teaching/modelling/l2_umlactivity.pdf
"A special kind of state signifying that the enclosing region is completed, leading to the entire state machine being completed."

https://msdn.microsoft.com/en-us/library/ee264171(v=vs.110).aspx
"A state which represents the completion of the state machine."

UML 2.5 Specification
“FinalState is a special kind of State signifying that the enclosing Region has completed. Thus, a Transition to a FinalState represents the completion of the behaviors of the Region containing the FinalState.”

In Umple, when a transition’s next state is the Final keyword, this causes the state machine to enter its final state. As a result, exit actions that can be executed prior to entering the final state are via the generated exit methods. The exit methods also handle stopping do activities.

When a nested state machine has a state that is prefixed with the keyword final, this defines a final state in which entry actions are allowed, as decided in #925. I did not find any definitions that stated that entry actions are not permitted for final states. However, from what I read here , entry actions are meant to serve as initialization functions. It seems weird to initialize a final state, since entering a final state means that a state machine is complete (delete() will be called).

For both Final and final <stateName>, the delete() method is called. What can differ between them is the sequence of exit actions that are executed. For instance, in the example below, final s3 is in s1 so only s2_exit() is executed. With goFinal, s2_exit(), and s1_exit() are executed.

class NonConcurrentFinalStates {
  sm {
    s1 {
      exit/{s1_exit();}
      do {s1_do_activity();}
      goFinal-> Final;
      s2 {
        exit/{s2_exit();}
        do {s2_do_activity();}
        goToS3-> s3;
      }
      final s3{ }
    }
  }
}

QUESTION:

If we decide that entry actions are no longer valid, should we have Umple only provide the -> Final; notation for final states?

Final would result in deletion of the object once all concurrent regions also reach a final state

Currently, when a concurrent state machine enters its final state, it deletes the entire state machine. It does not wait for the other concurrent state machines to enter their final states. Generating Java code for my example below demonstrates this.

class ConcurrentFinalStates {
  sm {
    s1 {
      s2 {
        s3 {
          completeS2-> s4;
        }
        final s4 {}
      }
      ||
      s5 {
        s6 {
          completeS5-> s7;
        }
        final s7 {}
      }
    }
  }
}

So far, it seems that we should update how final states are handled for concurrent state machines. For non-concurrent state machines, I believe that the current implementation is correct, asides from deciding if entry actions are still allowed. However from #152 , I am unsure if only the exit action of the current state that initiates the transition to the final state is executed, or if it the exit actions of parent states should also be executed. With the fix for #935, the exit actions of parent states are executed. I am wondering where to go from here?

@vahdat-ab

This comment has been minimized.

Member

vahdat-ab commented Mar 24, 2017

@jblang94 Thanks. great job.

This is from UML 2.5

A special kind of State, which, when entered, signifies that the enclosing Region has completed. If the enclosing Region is directly contained in a StateMachine and all other Regions in that StateMachine also are completed, then it means that the entire StateMachine behavior is completed

There are two meanings for final states. One used for regions and one for the entire state machine. In Umple, the first one is satisfied through the keyword final followed by the name of the state (e.g. final s3{}. The second on is satisfied through the keyword Final. In fact, the keyword Final reacts like a final state in the top level of the state machine -> "If the enclosing Region is directly contained in a StateMachine".
The current version supports this semantics but we don't have a proper implementation for them in Java. YES, this needs to be fixed.

Regarding having entry actions for final states, we have already discussed that we would like to have it although UML doesn't support it and you implemented it. JUST A NOTE FROM UML 2.5 for final states

no_exit_behavior: A FinalState has no exit Behavior.
no_outgoing_transitions: A FinalState cannot have any outgoing Transitions.
no_regions: A FinalState cannot have Regions.
cannot_reference_submachine: A FinalState cannot reference a submachine.
no_entry_behavior: A FinalState has no entry Behavior.
no_state_behavior: A FinalState has no state (doActivity) Behavior.

However, we cannot have entry actions for Final because we have defined it implicitly.
Therefore, make sure these two concepts are respected in our generated code specifically with orthogonal regions. Furthermore, explore how auto transitions of composite states, when they have orthogonal regions, are dealt in the current implementation.
I hope I have answered your questions.
BTW, check what has been done regarding the keyword End. We don't want to have confusion in the keywords.

@TimLethbridge You may want to comment on this as well

@TimLethbridge

This comment has been minimized.

Member

TimLethbridge commented Mar 24, 2017

I don't mind going slightly against UML and keep entry actions on final states. The very big benefit is that it allows such things as notifying of clients to shut down, or outputting the state change to the UI before termination. These things are supposed to be 'instantaneous', so there is essentially no harm in such entry actions, only benefit.

@vahdat-ab

This comment has been minimized.

Member

vahdat-ab commented Mar 24, 2017

@TimLethbridge I wonder if you are also ok with the semantics and syntax of final states described above? I mean using both Final and final with the state name.

@jblang94

This comment has been minimized.

Contributor

jblang94 commented Mar 25, 2017

@vahdat-ab thanks for the meeting today. Here is my attempt to try to encompass all of the aspects we discussed in an example. If you could confirm that my understanding is correct that would be great. I will then begin working on the implementation. I've created a separate gist .

@vahdat-ab

This comment has been minimized.

Member

vahdat-ab commented Mar 28, 2017

The first scenario is fine, but I'm not sure about the second scenario. According to what we talk it is correct and I'm in favor of it but let's see what @TimLethbridge says.
In fact, the procedure is correct but I'm not sure if we need to delete the SM or no.
BTW, check this link

@TimLethbridge

This comment has been minimized.

Member

TimLethbridge commented Mar 28, 2017

I am content with the semantics as shown in the gist.

Just to be clear that 'delete()' deletes the object (including the sm). As I understand it this would occur on a transition to 'Final'. It would also occur on a transition to a final state in situations where there are no concurrent regions, or if there are concurrent regions then all of them are in the final state.

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.

@jblang94

This comment has been minimized.

Contributor

jblang94 commented Mar 29, 2017

@vahdat-ab @TimLethbridge thanks for your comments

Just to be clear that 'delete()' deletes the object (including the sm). As I understand it this would occur on a transition to 'Final'. It would also occur on a transition to a final state in situations where there are no concurrent regions, or if there are concurrent regions then all of them are in the final state.

Yup! This is what we've agreed on so far. I will go ahead with this implementation.

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