Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Papyrus for Real Time » Local transition is not code-generarted
Local transition is not code-generarted [message #1778121] Mon, 11 December 2017 02:40 Go to next message
Shingyu Kang is currently offline Shingyu KangFriend
Messages: 5
Registered: December 2017
Junior Member
Hi,

Because internal transitions are not supported yet,
I'm giving a try with local transitions.
But I can't generate code for local transitions.

I want to know how to add local transitions.

I've added local transition as follows:
index.php/fa/31540/0/

But I see the following error from codegen
index.php/fa/31541/0/
Re: Local transition is not code-generarted [message #1778193 is a reply to message #1778121] Mon, 11 December 2017 16:54 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 363
Registered: March 2011
Senior Member
Hi.

The "Description" field in the error message says what the problem is: you have a transition "local_transit" whose source is an exit point (you can identify it as it is a little circle marked with an X). A transition whose source is an exit point is meant to exit the state that owns the exit point (as the name indicates). But your local transition is owned by "TOP", and hence it is not exiting TOP. So your state machine is syntactically invalid.

Also, keep in mind that local transitions do not replace internal transitions and do not have the same semantics. It looks like you are trying to emulate an internal transition as a local transition, but this won't work either. To quote from the OMG UML spec [1]:

Quote:

14.2.3.8.1 Transition kinds relative to source
The semantics of a Transition depend on its relationship to its source Vertex. Three different possibilities are defined, depending on the value of the Transition's kind attribute:
• kind = external means that the Transition exits its source Vertex. If the Vertex is a State, then executing this Transition will result in the execution of any associated exit Behavior of that State.
• kind = local is the opposite of external, meaning that the Transition does not exit its containing State (and, hence, the exit Behavior of the containing State will not be executed). However, for local Transitions the target Vertex must be different from its source Vertex. A local Transition can only exist within a composite State.
• kind = internal is a special case of a local Transition that is a self-transition (i.e., with the same source and target States), such that the State is never exited (and, thus, not re-entered), which means that no exit or entry Behaviors are executed when this Transition is executed. This kind of Transition can only be defined if the


So local transitions go from an entry point to some substate. Your model already has a valid local transition, from the entry point in the top of TOP to the LEFT substate.

But trying to use a local transition from TOP to TOP will not generate code equivalent to that for an internal transition from TOP to TOP.

You might need a different pattern for what you are trying to achieve. What exactly do you want to do? Is the local transition supposed to emulate an internal transition?






[1] http://www.omg.org/spec/UML/About-UML/
Re: Local transition is not code-generarted [message #1778211 is a reply to message #1778193] Tue, 12 December 2017 01:56 Go to previous messageGo to next message
Shingyu Kang is currently offline Shingyu KangFriend
Messages: 5
Registered: December 2017
Junior Member
Hi,

What I want is staying in the child state without exit/entry when a certain event occurs in the parent state. (it's internal transition)

I'm involved in a commercial project which uses PapyrusRT 1.0.
In this project, many states/sub-states have entry/exit behavior. So I want at least exit/entry behavior is not called on its state when a transition occurs while one of its sub-state is active. If it's possible, I can make a workaround to handle entry/exit behaviors in the sub-states.

This workaround works. But I'm not sure it's correct design.
(entry point is removed)
index.php/fa/31554/0/

And if possible, could you give a hint where I can make a workaround for internal transition. Then I can try to build a local version before official release.

If a parent state has a internal transition, every state also calls its corresponding transition function of its parent state.
So internal transition function is duplicated as many as the number of sub-states. I guess the function should be added only when it is on boundary (?).
But I can't find where I can try to fix it.

Thanks in advance.
Re: Local transition is not code-generarted [message #1778300 is a reply to message #1778211] Tue, 12 December 2017 20:49 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 363
Registered: March 2011
Senior Member
When you say that you want to "[stay] in the child state without exit/entry" it's not clear to me if you are talking about the entry/exit actions of the "parent" state or the substates.

If you mean that you do not want to execute the entry/exit actions of neither the parent nor the substates, then an internal transition is required in the parent state, but, as you've found out, the code generator incorrectly generates duplicated functions for this. We have a bug open for this (Bug 528164) but it won't be fixed until the next service release, and unfortunately we do not have a date for that. (Of course, for commercial customers we can do a contract to fix bugs, add features, etc. If this suits you, let me know and we can work out an arrangement).

If, however, you mean that you don't want to execute the exit/entry actions of the parent state, but it's OK to execute the exit/entry actions of the substates, then this can be achieved by a local transition, similar to what you have done. See the attached model.

The idea is essentially to have in the parent state a local transition from the boundary of the parent state to its deep history pseudo-state (or equivalently to the parent state's boundary, but it may be clearer to have an explicit deep history pseudo-state. The local transition plays the role of the internal transition: it is a group transition with a trigger such that, when an event is received, it exits the current substate (recursively) and goes back to the same state (recursively) since the target is the deep-history pseudo-state. Hence the transition's action is executed while remaining in the same substate (chain). The difference with internal transitions is that in an internal transition, the currently active substate is not (recursively) exited and (recursively) entered, and therefore its exit and entry actions are not executed, whereas in the case I describe, these actions *are* executed.

See the diagram below:
index.php/fa/31579/0/

Now, the UI has several bugs that make it difficult to do this, so here's what you need to do:

1) Add a DeepHistory point from the palette (the circle marked with H*).

2) Create a transition (t3 in the example) from the Boundary of the parent state to a substate. We are trying to make it to the DeepHistory point, but due to a bug, we cannot target it directly. Also note that this automatically creates an entry point which needs to be removed.

3) Move the target of the transition (t3 in the example) to the DeepHistory point.

4) Move the source of the transition (t3) from the entry point to the boundary of the parent state.

(Optional) remove the entry pseudo-state.

Check that the source and target of the transition are set appropriately by selecting the transition, and go to the "Advanced" tab in the "Properties" view. The source and target fields should be the parent state and the deep history pseudo-state, as shown here:

index.php/fa/31580/0/

Now, if you really need to remain in the state and not execute *any* exit/entry actions, then you have to do some manual work, since internal transitions don't work yet. A possible hack would be to add a check to every exit and entry action to see if we are executing as a result of the message that we are expecting in the (fake) internal transition. For example, in the model attached, the "internal" transition is triggered by a protocol message called "InProtocolMessage2" from "Protocol1". So every entry/exit action of every substate could do the following:

if (msg->getSignalId() != Protocol1::signal_InProtocolMessage2) {
    // do execute entry or exit action code
}


So the idea is that each action function has an implicit 'msg' parameter which holds the message. We ask for its signal id, and if it is not the message from the "internal" transition, we execute the action, otherwise, we do nothing.

I know it's not ideal, but it's the best that can be done right now.

Fixing the duplicated internal transitions in the code generator is not trivial. I am not certain where exactly is the bug, but it is likely that it is in the following function: org.eclipse.papyrusrt.codegen.statemachines.transformations.StateNestingFlattener.phase1ProcessState(State, Iterable<Transition>) But what this function does (and how the state machines generator works) is a long story, not suitable to describe here in the forum.






[Updated on: Tue, 12 December 2017 20:56]

Report message to a moderator

Re: Local transition is not code-generarted [message #1778393 is a reply to message #1778300] Wed, 13 December 2017 18:33 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 363
Registered: March 2011
Senior Member
I found where the error is in the code generator. Details are in Bug 527165.
Re: Local transition is not code-generarted [message #1778435 is a reply to message #1778393] Thu, 14 December 2017 09:25 Go to previous message
Shingyu Kang is currently offline Shingyu KangFriend
Messages: 5
Registered: December 2017
Junior Member
Thank you for your detailed explanation.
With your help,
I have now enough workarounds for bugs and missing features I have found in our project.
Previous Topic:UML-RT/Papyrus-RT and the "Let it Crash" approach to handling faults
Next Topic:How to override targetStartup
Goto Forum:
  


Current Time: Tue Nov 20 15:53:19 GMT 2018

Powered by FUDForum. Page generated in 0.02973 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top