Community
Participate
Working Groups
Entry and exit points are explicit in the current implementation. + can serve as start and end points for transitions + can have multiple transitions attached - in base classes the entry/exit points for future derived classes have to be defined in advance. So they might be defined when we don't need them and vice versa A possible alternative would be the use of implicit entry and exit points. This would mean that e.g. an outer transition could be the starting or end point for a transition. The graphical viewer could insert entry and exit point figures with anchors automatically. Notation could be e.g. Transition tr0: state0 -> state1 Transition tr1: state2 -> state1 Transition tr2: state1 -> state0 Transition tr3: state1 -> state2 State state0 State state2 State state1 { subgraph { Transition (tr0) -> a // connects outer transition t0 with local state a Transition (tr0,tr1) -> a // connects outer transitions t0 and t1 with local state a Transition a -> (tr2) // connects local state a with outer transition tr2 Transition b -> (tr2) // connects local state b with outer transition tr2 State a State b } } + user doesn't have to care about entry and exit point creation + above described problem with base and derived class is easily solved Other opinions?
The implicit alternative is much more handy from my point of view. Some remarks: - a non connected incoming transition should be treated as transition to history - a non connected outgoing transition should be treated as grouptransition - both should be visible inside the state - a entry/exit point should automatically appear on the boarder of a state when a transition is connected to a state. How can the user force: Transition (tr0) -> a Transition (tr1) -> a or Transition (tr0,tr1) -> a on the grafical interface ?? I think it would be nice to force this decission on the higher level by drawing two transitions to the same entry point. For this it would be necessary to make the entry/exit point visible on the boarder of the state as mentioned above. Combining two transitions automatically leads to the data cast issue. We should keep this in mind when we decide how to tread the data cast issue. TJ (In reply to comment #0) > Entry and exit points are explicit in the current implementation. > + can serve as start and end points for transitions > + can have multiple transitions attached > - in base classes the entry/exit points for future derived classes have to be > defined in advance. So they might be defined when we don't need them and vice > versa > > A possible alternative would be the use of implicit entry and exit points. > This would mean that e.g. an outer transition could be the starting or end > point for a transition. > The graphical viewer could insert entry and exit point figures with anchors > automatically. > Notation could be e.g. > Transition tr0: state0 -> state1 > Transition tr1: state2 -> state1 > Transition tr2: state1 -> state0 > Transition tr3: state1 -> state2 > State state0 > State state2 > State state1 { > subgraph { > Transition (tr0) -> a // connects outer transition t0 > with local state a > Transition (tr0,tr1) -> a // connects outer transitions > t0 and t1 with local state a > Transition a -> (tr2) // connects local state a with > outer transition tr2 > Transition b -> (tr2) // connects local state b with > outer transition tr2 > State a > State b > } > } > > + user doesn't have to care about entry and exit point creation > + above described problem with base and derived class is easily solved > > Other opinions?
decision of the discussion today (ts, tj, hrr): - for the first release we stick with the solution we already have in place - improve usability later by - show an entry/exit point for _all_ outer transitions in the state graph of the outer transitions. This means that the small TrPoints can exist without inner counterpart and in this case have to be linked with their transition. - if the state has no sub-graph The small TrPoint shapes are created automatically when a Transition is about to attach to the state anchor and the anchor has to be exchanged (Graphiti: possible? Use Reconnect inside Connect?) - if the state already has a sub-graph The TrPoints together with inner and outer shapes will be created on the fly. - also treat deletion of a sub-graph - a RefinedState may add TrPoints and link them to base state outer transitions Introduce a new syntax like EntryPoint <name> of <ref to outer transition> Use Validation! - make validation during generator model creation less restrictive Unconnected EntryPoints go to history. Unconnected ExitPoints are treated as group transitions Hope I didn't forget anything ;-)
outdated bug - re-open if still relevant
