(responding to Eric)
>> (Paul) >> What I _can_ say is that if one wants to say that the outgoing >> transitions are alternatives, it is possible to say this without >> ambiguity by putting a set of mutually exclusive guard >> conditions on the outgoing transitions. If OTOH one wants to >> say that the outgoing transitions are all to happen, possibly >> in parallel, then it is also possible to say this without >> ambiguity by using fork (and join) synchronisation bars. > What you describe is exactly the unambiguous practice that > I consider best. We agree on the solution, but I'm left with a > troubling question: absent a set of MUTUALLY EXCLUSIVE > guard conditions on all of the transitions from an activity, must > we not assume that all of the transitions happen in one tick? I'm glad we agree that everyone should go for the unabbiguous approach; discussing the meaning of the ambiguous cases is then merely an academic exercise - but let's not let that stop us, it could be instructive. I assert that there is a good argument for _either_ meaning, which is why it remains ambiguous in the extreme. You put up a good argument here in favour of the 'ANDing' of outflow transitions - the subsequent activities would all happen, possibly at the same time. OTOH, there is also a good argument (and precedent) for the outflow transitions to be 'ORed'; only one of them would happen... > Repeating: this is a state diagram. A state acts only in indivisible > ticks, and retains control until it receives an event that causes it to > make a transition to another state or activity in the diagram. An > activity is a kind of degenerate state (no state variable) that does not > retain control for more than one tick. First point agreed. Second point (though not relevant) is that the 'Activity' is something that goes on until the state machine makes a transition out of the state, so the state machine holds the state for more than one tick. I might be getting the wrong end of the stick here, but I don't think the point is relevant. > Since the activity MUST pass control after handling the incoming event > (to conclude the tick), it must make at least one transition. A true > guard condition asserts that the transition is made. A lack of guard > conditions on the transitions asserts that they are all true, so the > activity must make them all. Again, first point agreed. The second point is a good arguiment, but there is an equally good argument (and precedent) saying only one of the outgoing transitions will fire. (given later). > The notation looks sufficient to me, given this reasoning. Is there > some flaw in my premises or reasoning here? Your reasoning is sound, but it isn't the only possible line of reasoning. > If you want to keep the usage ambiguous for transitions from an > activity, you should use the guard condition [we're not sure], or > something similar. OK, seriously, [unknown]. Well, that would give us some way of checking that we really do mean to be ambiguous - a good recommendation. > Where does that leave us with transitions out of states? Does > the fact that a state can retain control through more than one tick > make a difference? I think it does, because it makes collections > of guardless exits ambiguous, since each could be made on a > different tick. Ah, not with my line of reasoning. > This is all based on the assumption that the term "state" means > what it meant to me in the 20-odd years that I used FSMs prior to > the UML. It would be very interesting to discover that my > assumption is false. There are various earlier forms of state machine notation. AFAIK, and I don't claim to have knowledge of them all, they tend to admit only one state at a time except where there is an explicit mechanism to say two states are permitted at a time. I think those on which UML was based are those that only allow one state at a time except where there are substates (i.e. the state machine can be nested, and in an inner state at teh same time as being in the enclosing state). There are various mechanisms allowing parallel states. The one I am most familiar with is the Petri Net. Here, a Place (equivalent of a state, or near enough) has a number of 'tokens' it can pass to outgoing transitions. A transition is enabled when all its inflows have access to a token, and when it fires, the incoming tokens are removed from the Place. Thus if there are more outgoing transitions that could fire than there are tokens, some of these transitions will not fire because the tokens will be used up elsewhere. In Petri Net notation, _all_ transitions have a 'synchronization bar', even those with only a single inflow and outflow. UML seems to have adopted this notation only for transtitions with either (or both?) multiple inflows or outflows. It hasn't adopted the concept of tokens. OTOH, it makes sense to assume there will be only one token. The alternative is to say there will be an indeterminate number of tokens (which might make sense). To put it simply, though, the state machine approach is more likely IMHO to say that there is only a single state active at a time unless explicitly stated - any ambiguity means that we don't know _which_ state will be active. There is your equally plausible alternative that suggests any ambiguity means we don't know _how many_ states will be active. I find your sugestion that a transition from a state can fire yet the state remain active to allow other outgoing transitions to fire later a bit worrying, and I'm sure if we allow multiple outgoing transitiona to fire, we ought to make sure they all fire at the same time. Paul Oldfield ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ www.aptprocess.com any opinions expressed herein are not necessarily those of Mentors of Cally or the Appropriate Process Movement ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
