Community
Participate
Working Groups
The Textual notation TUML-RT should support internal transitions. An example would be: state A { /* entry action, exit action, etc. */ internal transition StateA_internal_transition triggers on portA:messageA action '// do something'; }
I guess this could be compared to the corresponding functionality in the tooling for creating internal transitions, see Bug 494287.
Now that I think of it: How do you define an external self transition vs. a local self transition in the textual notation? This is about a notation of local transitions, and I guess that the difference between external self transition and local self transition is where it is being placed, i.e. "outside" the state or "inside" the state itself.
(In reply to Peter Cigehn from comment #2) > Now that I think of it: How do you define an external self transition vs. a > local self transition in the textual notation? This is about a notation of > local transitions, and I guess that the difference between external self > transition and local self transition is where it is being placed, i.e. > "outside" the state or "inside" the state itself. You are right on both points, currently there is no explicit syntax to distinguish between these, and the distinction is made by the textual scope. If we have composite state S1 { composite state S2 { transition t2 from S2 to S2; } transition t1 from S2 to S2; } Then t1 would be an external self transition and t2 a local transition. t1 is owned by S1 and t2 is owned by S2. Do you think there is a need for a new keyword to make the distinction? Perhaps an optional keyword?
(In reply to Ernesto Posse from comment #3) > Do you think there is a need for a new keyword to make the distinction? > Perhaps an optional keyword? Maybe an optional keyword, but that might just add complexity. Without knowing it might good enough that it is implicit based on the position. When looking a bit closer, I realize that I myself specified the one of variants of transitions incorrectly in Bug 494284, i.e. case 8). This one should actually be an external transition. Since case 7) though is also a local transition, I am not sure that you want/need to specify that explicitly in the textual notation. So to keep things simple, it feels like you simply should avoid any keywords for external and local transitions, and only as this Bugzilla proposes, have a keyword for the internal case since that case should not require and source/target states since that always implicitly both are the same as the owning state. Whereas for both external and local transitions you both have self-transitions where source and target are the same state, but also "normal" transitions where source and target differs.
(In reply to Peter Cigehn from comment #4) > (In reply to Ernesto Posse from comment #3) > > Do you think there is a need for a new keyword to make the distinction? > > Perhaps an optional keyword? > > Maybe an optional keyword, but that might just add complexity. Without > knowing it might good enough that it is implicit based on the position. > > When looking a bit closer, I realize that I myself specified the one of > variants of transitions incorrectly in Bug 494284, i.e. case 8). This one > should actually be an external transition. > > Since case 7) though is also a local transition, I am not sure that you > want/need to specify that explicitly in the textual notation. > Right. But reading the cases, I think that case 6) might conflict with the UML spec, which I quote here (2.5.1, p. 328): "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." So the source and the target vertices must be different. Hence the only way in which there could be a *local* self-transition is if there were explicit exit and entry pseudostates: composite state S1 { composite state S2 { entry points { p1 } exit points { q1 } transition t2 from p1 to q1; } } But even then, it looks like it goes against the spirit of the definition of local transitions, doesn't it? > So to keep things simple, it feels like you simply should avoid any keywords > for external and local transitions, and only as this Bugzilla proposes, have > a keyword for the internal case since that case should not require and > source/target states since that always implicitly both are the same as the > owning state. Whereas for both external and local transitions you both have > self-transitions where source and target are the same state, but also > "normal" transitions where source and target differs. Agreed. Better not to introduce additional syntax if it can be avoided.
(In reply to Ernesto Posse from comment #5) > (In reply to Peter Cigehn from comment #4) > > (In reply to Ernesto Posse from comment #3) > > > Do you think there is a need for a new keyword to make the distinction? > > > Perhaps an optional keyword? > > > > Maybe an optional keyword, but that might just add complexity. Without > > knowing it might good enough that it is implicit based on the position. > > > > When looking a bit closer, I realize that I myself specified the one of > > variants of transitions incorrectly in Bug 494284, i.e. case 8). This one > > should actually be an external transition. > > > > Since case 7) though is also a local transition, I am not sure that you > > want/need to specify that explicitly in the textual notation. > > > > Right. But reading the cases, I think that case 6) might conflict with the > UML spec, which I quote here (2.5.1, p. 328): > > "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." > > So the source and the target vertices must be different. Hence the only way > in which there could be a *local* self-transition is if there were explicit > exit and entry pseudostates: Yes, but that is also what case 6 is all about. The user draws and edge from the state to itself, but the tooling automatically creates the entry and exit points (as the tooling always should do, the user shall never have to create the entry and exit points manually before hand), and the final result is that the transitions has as its source the entry point and the target is the exit point (with implicit deep history semantics according to UML-RT). I've based these cases by checking how the legacy tooling behaves and what kind of transitions it creates. And case 6) results in a local transition being created. > > composite state S1 > { > composite state S2 > { > entry points { p1 } > exit points { q1 } > transition t2 from p1 to q1; > } > } > > But even then, it looks like it goes against the spirit of the definition of > local transitions, doesn't it? But the definition of local (self) transition vs external (self) transition is mainly about if the entry/exit behavior of the composite state itself shall be executed or not. Actually the entry/exit behavior of any substates do get executed, which not happens for internal transitions, and hence it makes sense to have the entry and exit points, with implicit deep history semantics, since the entry/exit code for all substates is executed. So I really don't see that this goes against this spirit.
(In reply to Peter Cigehn from comment #6) > (In reply to Ernesto Posse from comment #5) > > So the source and the target vertices must be different. Hence the only way > > in which there could be a *local* self-transition is if there were explicit > > exit and entry pseudostates: > > Yes, but that is also what case 6 is all about. The user draws and edge from > the state to itself, but the tooling automatically creates the entry and > exit points (as the tooling always should do, the user shall never have to > create the entry and exit points manually before hand), and the final result > is that the transitions has as its source the entry point and the target is > the exit point (with implicit deep history semantics according to UML-RT). > > I've based these cases by checking how the legacy tooling behaves and what > kind of transitions it creates. And case 6) results in a local transition > being created. That's fine, but the question here is whether in the context of the textual syntax we shall require such exit and entry points. To me they seem superfluous, and would impose an additional effort on the user. I think it is much easier to type composite state S1 { composite state S2 { transition t2 from S2 to S2; } } than having to type composite state S1 { composite state S2 { entry points { p1 } exit points { q1 } transition t2 from p1 to q1; } } > > But even then, it looks like it goes against the spirit of the definition of > > local transitions, doesn't it? > > But the definition of local (self) transition vs external (self) transition > is mainly about if the entry/exit behavior of the composite state itself > shall be executed or not. Actually the entry/exit behavior of any substates > do get executed, which not happens for internal transitions, and hence it > makes sense to have the entry and exit points, with implicit deep history > semantics, since the entry/exit code for all substates is executed. So I > really don't see that this goes against this spirit. Right. I didn't express myself clearly. What I find to be "against the spirit of the definition of local transitions" is the fact that you can achieve the same effect (having a local self-transition) by adding entry/exit pseudo-states. I think that my question is that I don't see why the UML spec imposes the constraint that the source and target vertices should be different is you can achieve a local self-transition anyway. It feels like a bit of an artificial constraint. Perhaps I'm missing something.
(In reply to Ernesto Posse from comment #7) > (In reply to Peter Cigehn from comment #6) > > (In reply to Ernesto Posse from comment #5) > > > So the source and the target vertices must be different. Hence the only way > > > in which there could be a *local* self-transition is if there were explicit > > > exit and entry pseudostates: > > > > Yes, but that is also what case 6 is all about. The user draws and edge from > > the state to itself, but the tooling automatically creates the entry and > > exit points (as the tooling always should do, the user shall never have to > > create the entry and exit points manually before hand), and the final result > > is that the transitions has as its source the entry point and the target is > > the exit point (with implicit deep history semantics according to UML-RT). > > > > I've based these cases by checking how the legacy tooling behaves and what > > kind of transitions it creates. And case 6) results in a local transition > > being created. > > That's fine, but the question here is whether in the context of the textual > syntax we shall require such exit and entry points. To me they seem > superfluous, and would impose an additional effort on the user. I think it > is much easier to type > > composite state S1 > { > composite state S2 > { > transition t2 from S2 to S2; > } > } > > than having to type > > composite state S1 > { > composite state S2 > { > entry points { p1 } > exit points { q1 } > transition t2 from p1 to q1; > } > } > Right, I did misunderstood. But you bring up a very good point. How do we handle those cases in the textual notation, where the graphical tooling automatically adds additional model elements and automatically establishes needed relations to those additional model element, e.g. the entry and exit points being automatically created when the user draws a transition to/from a composite state. Should this be implicitly handled by the textual notation as you propose? I guess that in this specific it should be fine. If you compare with figure 15 in the UML-RT profile document, you have examples of the implicit deep history convention, where a transition terminates on the boundary of a composite state, but with no continuing transition from the point of contact, which could either be a simple termination, an entry point, or an exit point. Since the two cases are identical, i.e. with or without the entry/exit point, it behaves the same, the textual notation could/should probably handle the entry/exit point implicitly (including the case for a local self transition). Only in the case when the entry/exit point is explicitly needed, i.e. when you have a continuing transition "on the other side" of the composite state, you need the explicitly identified entry/exit point to be able to refer to it both from the transition on the "inside" and on the "outside". > > > > But even then, it looks like it goes against the spirit of the definition of > > > local transitions, doesn't it? > > > > But the definition of local (self) transition vs external (self) transition > > is mainly about if the entry/exit behavior of the composite state itself > > shall be executed or not. Actually the entry/exit behavior of any substates > > do get executed, which not happens for internal transitions, and hence it > > makes sense to have the entry and exit points, with implicit deep history > > semantics, since the entry/exit code for all substates is executed. So I > > really don't see that this goes against this spirit. > > Right. I didn't express myself clearly. What I find to be "against the > spirit of the definition of local transitions" is the fact that you can > achieve the same effect (having a local self-transition) by adding > entry/exit pseudo-states. I think that my question is that I don't see why > the UML spec imposes the constraint that the source and target vertices > should be different is you can achieve a local self-transition anyway. It > feels like a bit of an artificial constraint. Perhaps I'm missing something. I'm an not fully sure that I follow along here. I guess you probably should direct this question to Bran. I guess he probably can give an explanation. Not sure either if this is related to the fact that UML-RT have the implicit deep history convention, whereas UML don't (where you instead are forced to have explicity deep history pseudostates). I add Bran to Cc.
Unless I am overlooking something, I think that the statement about the source and target of a local transition being different is a mistake. (I believe that this was introduced when the state machine section was "owned" by Birger Moeller-Pederson, who was working for Ericsson at the time, and keen on ensuring that SDL 2000 was supported by UML 2. Unfortunately, Birger was really rushed to complete the section as we were busy closing up UML 2.0, so this error seems to have slipped through.) Note, that the actual constraint in the spec does not disallow the source and target to be different; it only talks about the two possible types of sources for a local transition: (kind = TransitionKind::local) implies ((source.oclIsKindOf (State) and source.oclAsType(State).isComposite) or (source.oclIsKindOf (Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint)) In other words, the source can be either the state itself or an entry point; that is, a local transition must emanate from the boundary of its containing state. It says nothing about the target. So, if there is a local self-transition, there is no need to create an entry point and, even less so, an exit point for its source and target respectively. Perhaps the RSA implementation team was mislead by the mistaken wording. Actually, it appears that this whole thing needs to be reconsidered; for one, there is no constraint, as there should be, to ensure that the target of a local transition has to be inside the composite state that is its source. Note that even the name of the constraint ("state_is_local") is misleading.
(In reply to Bran Selic from comment #9) > So, if there is a local self-transition, there is no need to create an entry > point and, even less so, an exit point for its source and target > respectively. Perhaps the RSA implementation team was mislead by the > mistaken wording. But now I guess we need to consider the legacy? Should we continue to follow this pattern that local self transitions also have explicit entry/exit points created, as defined in case 6) in Bug 494284? Or should we change this? I guess we still need to support this since importing any legacy model will follow this pattern. I checked a bit in the legacy tooling, and you can re-orient the local self transition so that it has the composite state as source and target directly, i.e. the same kind of re-orientation you have to do to create transitions T4 and T2 in figure 15 in the UML-RT profile document. And this models validates correctly in the legacy tooling. When generating code, both variants produces the same code, i.e. you can have a local self transition without the entry/exit points. But since the tooling is consistent in always creating an entry/exit point for transitions with a composite state as source/target, in the way I indicate should be done in Bug 494284. Bran, could you check what I have written in Bug 494284, and comment if you have anything to add/correct regarding this? > Actually, it appears that this whole thing needs to be reconsidered; for > one, there is no constraint, as there should be, to ensure that the target > of a local transition has to be inside the composite state that is its > source. Note that even the name of the constraint ("state_is_local") is > misleading. I do know that the legacy tooling have added an additional live constraint for this. If you try to change the kind of transition to local for the case when the target is not inside the composite state, then a dialog pops stating this fact.
(In reply to Peter Cigehn from comment #10) > (In reply to Bran Selic from comment #9) > > So, if there is a local self-transition, there is no need to create an entry > > point and, even less so, an exit point for its source and target > > respectively. Perhaps the RSA implementation team was mislead by the > > mistaken wording. > > But now I guess we need to consider the legacy? Should we continue to follow > this pattern that local self transitions also have explicit entry/exit > points created, as defined in case 6) in Bug 494284? Or should we change > this? I guess we still need to support this since importing any legacy model > will follow this pattern. > > I checked a bit in the legacy tooling, and you can re-orient the local self > transition so that it has the composite state as source and target directly, > i.e. the same kind of re-orientation you have to do to create transitions T4 > and T2 in figure 15 in the UML-RT profile document. And this models > validates correctly in the legacy tooling. When generating code, both > variants produces the same code, i.e. you can have a local self transition > without the entry/exit points. But since the tooling is consistent in always > creating an entry/exit point for transitions with a composite state as > source/target, in the way I indicate should be done in Bug 494284. > > Bran, could you check what I have written in Bug 494284, and comment if you > have anything to add/correct regarding this? > > > Actually, it appears that this whole thing needs to be reconsidered; for > > one, there is no constraint, as there should be, to ensure that the target > > of a local transition has to be inside the composite state that is its > > source. Note that even the name of the constraint ("state_is_local") is > > misleading. > > I do know that the legacy tooling have added an additional live constraint > for this. If you try to change the kind of transition to local for the case > when the target is not inside the composite state, then a dialog pops > stating this fact. Legacy is certainly something that we must account for. While I said that there is no need to include the entry and exit points, there is also no harm in doing so (as stated in Peter's note for Bug 494284). In fact, for the exit point, there is an important advantage, since it allows a subclass to extend the transition by adding an external transition that emanates from that exit point - something that often makes sense. We could also do the same for the source entry point of the local transition, but this becomes complicated if the local transition has a trigger. (I recall that ObjecTime handled this case, but that's ancient history.)
Besides the advantages in inheritance situations, I also believe it makes it easier to change transitions if the entry/exit states exists. This advantage is however more a convenience during graphical modelling and I don't think the use-case is the same for a textual syntax. I would therefor advocate that the textual syntax can be specified with or without the source/entry pseudo states. Unlike for the graphical tooling there is no "automatic creation" of anything and the textual definition should follow the principal, "what you see is what you get". In other words there shouldn't be any implicit entry/exit pseudo states associated with the self transition. Therefor both definitions below are valid, while the top one also supports the use-cases for inheritance and ease of change. The first case will also be able to support change of history semantics from the RT default deep history. composite state S1 { composite state S2 { entry points { p1 } exit points { q1 } transition t2 from p1 to q1; } } composite state S1 { composite state S2 { transition t2 from S2 to S2; } transition t1 from S2 to S2; } On a sidenote, what value does the "composite" part of the "composite state" syntax? Isn't it a derived attribute in the UML spec? "isComposite = (region > 1)".
As Peter pointed out, it should be "isComposite = (region > 0)", in the SM spec it is stated that the composite state should contain at least one region and that this constraint is satisfied "isComposite = region.notEmpty()". None the less, it is a derived and not an explicit specification of the state.
