Thankyou for your help Eric,
For perhaps the first time, I prefer your argument above other replies on this subject ;-) I think I'm right in suggesting that no-one else had considered the effect of states in an activity diagram, and yet they are allowed. I really don't know of the difference between a state and an activity in this type of diagram, therefore I (and I suspect many others) have been ignoring states and treating an activity as a state, but with additional functionality. As you so rightly pointed out, several transitions from a state indicates that one and only one of many transitions may occur upon exit. Traditional FSMs (state machines) do not carry the idea of parallel processing, IME (although Mr. Harel came along and tried to change all that). Considering that UML state diagrams are based on Harel notation, can we also assume that activity diagrams allow for parallel states? Parallel states are indicated in Harel notation by having states nested within states. I.e. draw a state, split it in 2 and the system may be in state in both sides of the split at the same time. I believe that this notation is also supported by UML. So now I am really confused, because the question becomes, "What is the difference beween 1) several transitions from a state to a fork bar which then enter several other states, 2) several transitions from a state entering into several states and 3) a single transition from a state entering another state that has been split into several states?". [Please bear with me while I take a brief lie-down.] Not to drag this thread out too much let me take a side-track for us Rose users. If you have attempted to use the state/activity diagram editor in Rational, you like me, will have discovered that there are several features that you should not combine. For example, don't use swimlanes, if you ever intend to edit your diagram again. Another combination of features to avoid is synchronizatin bars and diagram automatic resizing. They do not go together. (Did anyone at Rational ever actually attempt to use this feature on a diagram with synchronization bars before realeasing Rose?) So bearing this in mind, and the ulterior motive to most of my emails, I am really looking for a way of showing parallelism in Rose activity diagrams WITHOUT having to use synchronization bars. (Please don't ever suggest using nested states with Rose. I tried it once and my PC never forgave me.) Thankyou again Eric, I believe that is the second time in 13 years that you have helped me solve a problem with my work. Les. > > [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. > > ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ************************************************************************ * 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 *************************************************************************
