[EMAIL PROTECTED] wrote: > 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? 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. 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. The notation looks sufficient to me, given this reasoning. Is there some flaw in my premises or reasoning here? 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]. 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. 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. -Eric [EMAIL PROTECTED] wrote: > > (responding to Eric Tarkington) > > > I haven't done enough with activity diagrams, but here's > > how it looks to me: > > > > The initial activity executes in 1 "tick" so the multiple transitions > > out of it are simulaneous. A synchronization bar in the diagram > > is harmless but redundant. > > > > If you have an initial state, instead of an activity, the state can > > use an indeterminate number of ticks (including 0) between the > > transitions, so the parallel threads may be *launched* > > asynchronously, and a synchronization bar is very significant. > > Well I don't agree, but OTOH, I can't say you're wrong. > And therein lies the problem - the notation can be > ambiguous; different interpretations are possible, and there > seems to be no guidance on which is correct. (I have > heard that UML 2.0 will clear up this ambiguity; I'm > still wading through the documentation of 1.4 and hope > to be finished by Christmas! ) > > 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. > > If one doesn't want to say at this stage which of the options > are desired (I can't conceive of an example, but maybe > others have better imaginations), then it _may_ be a valid > approach to have multiple outgoing transitions without > mutually exclusive guards. However, if anyone is about > to take this approach, I recommend that they thoroughly > document what it is that they are trying to say, because it > is clear that different people will read the diagram in different > ways. > > 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 *************************************************************************
