Home » Eclipse Projects » Papyrus for Real Time » Local transition is not code-generarted
|
| Re: Local transition is not code-generarted [message #1778193 is a reply to message #1778121] |
Mon, 11 December 2017 16:54   |
 Ernesto Posse
Messages: 438
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 #1778300 is a reply to message #1778211] |
Tue, 12 December 2017 20:49 |
Ernesto Posse
Messages: 438
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:
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:
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 |
|
| | |
Goto Forum:
Current Time: Fri Apr 26 13:41:50 GMT 2024
Powered by FUDForum. Page generated in 0.03642 seconds |
] 
Search
Help
Register
Login
Home
