One of the biggest missing features in the state process implementation is support for nested state processes. In the implementation, we need to know whether a trigger is for an internal state or the external state that contains the nested process. We could perhaps handle this with explicit transition attributes, but it would be nice if there were a better way. How do you unambiguously indicate the target for a trigger in a UML diagram? I have only seen examples with a top level state process with no nested states. Guess I need to know that before thinking about implementation details. Please post an example if you have one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A agree that nested state processes need to be supported--as well as transitions into arbitrary states in that nested process. This is a key feature for limiting complexity and is essential to good modeling.
A trigger is always for the "current" state. We need to be thoughtful about what we're modeling, and how that's reflected by execution. It should be possible, for example, for a trigger "t" to be received by an outer model and each nested inner state process (as many levels down as you like) and be handled correctly. I think the keys to doing that are:
1. we need a clear heirarchy of execution. Right now, I'm thinking "lowest-level-first" is the most logical from the process modeling point of view.
2. we need to warn the developer when the same trigger name applies to more than one level in a nest, to ensure that's the desired behavior. We need an annotation to turn that warning off, too.
Internal transitions are a special case of nested state processes; I think they should probably be modeled the same way nested processes are modeled (whatever that turns out to be).
I haven't thought about how to represent this yet. Thus: I'm happy for suggestions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with those requirements, but I'm still looking for a clue on how the same issue (what is the "current" state that a trigger applies to in a hierarchy of active nested states) is resolved in a UML diagram, since that will constrain our solution. Is it just left ambiguous? Is it a constraint to not repeat a trigger in the hierarchy (another possible, but less flexible solution)? If not, then you cannot validate triggers for a state without knowing how it is nested, if we go with the convention that a trigger applies to the first state that implements that trigger, searching from the bottom of the hierarchy through each parent container state (a reasonable convention). I agree warnings about trigger hiding (if allowed) would be nice to have, but lower priority than the representation and functionality.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re-reading your post, it seems you are actually suggesting that a trigger applies to every state in the hierarchy that implements it. That implies complex control mechanisms to include or exclude a state. I would prefer the simplifying assumption that only one state will get the trigger. I think you can invoke triggers unique to higher level states from your state process classes if you need to affect multiple states in a hierarchy at once. However, I recognize that moves the complexity out of the diagram and into the process-specific code. Also, I don't know if that assumption limits the valid UML diagrams that can be executed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the biggest missing features in the state process implementation is support for nested state processes. In the implementation, we need to know whether a trigger is for an internal state or the external state that contains the nested process. We could perhaps handle this with explicit transition attributes, but it would be nice if there were a better way. How do you unambiguously indicate the target for a trigger in a UML diagram? I have only seen examples with a top level state process with no nested states. Guess I need to know that before thinking about implementation details. Please post an example if you have one.
A agree that nested state processes need to be supported--as well as transitions into arbitrary states in that nested process. This is a key feature for limiting complexity and is essential to good modeling.
A trigger is always for the "current" state. We need to be thoughtful about what we're modeling, and how that's reflected by execution. It should be possible, for example, for a trigger "t" to be received by an outer model and each nested inner state process (as many levels down as you like) and be handled correctly. I think the keys to doing that are:
1. we need a clear heirarchy of execution. Right now, I'm thinking "lowest-level-first" is the most logical from the process modeling point of view.
2. we need to warn the developer when the same trigger name applies to more than one level in a nest, to ensure that's the desired behavior. We need an annotation to turn that warning off, too.
Internal transitions are a special case of nested state processes; I think they should probably be modeled the same way nested processes are modeled (whatever that turns out to be).
I haven't thought about how to represent this yet. Thus: I'm happy for suggestions.
I agree with those requirements, but I'm still looking for a clue on how the same issue (what is the "current" state that a trigger applies to in a hierarchy of active nested states) is resolved in a UML diagram, since that will constrain our solution. Is it just left ambiguous? Is it a constraint to not repeat a trigger in the hierarchy (another possible, but less flexible solution)? If not, then you cannot validate triggers for a state without knowing how it is nested, if we go with the convention that a trigger applies to the first state that implements that trigger, searching from the bottom of the hierarchy through each parent container state (a reasonable convention). I agree warnings about trigger hiding (if allowed) would be nice to have, but lower priority than the representation and functionality.
Re-reading your post, it seems you are actually suggesting that a trigger applies to every state in the hierarchy that implements it. That implies complex control mechanisms to include or exclude a state. I would prefer the simplifying assumption that only one state will get the trigger. I think you can invoke triggers unique to higher level states from your state process classes if you need to affect multiple states in a hierarchy at once. However, I recognize that moves the complexity out of the diagram and into the process-specific code. Also, I don't know if that assumption limits the valid UML diagrams that can be executed.