(responding to Eric)
>> (Paul) >> 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. > > (Eric) > You are not paraphrasing me correctly (could be my fault). Activities > can only have control for one tick. States can have control for a > series of ticks. I think that is the crucial difference between > activities and states. As I understand the reference book on Activity States, there is no limit on how long an activity state may be active. It usually but not always terminates on completion of the activity. An Action state is atomic, but an Activity state is not. I find it hard to reconcile this with your assertion that Activities can only have control for one tick. But as I say, I might be getting hold of the wrong end of the stick. > For me, the unfamiliar thing in this is parallelism. The notion of > state is hard for me to square with parallel threads of control. In my > bones, I expect one state per state diagram, unless you embed a > diagram. A state shouldn't make a transition *and* retain control into > the next tick, because that means that there is more than one state of > the FSM waiting for events (which at least *feels* wrong). I'm familiar with parallelism, the Petri Net notation covered it well IMHO. OTOH I agree with you that "A state shouldn't make a transition *and* retain control into the next tick". Petri Net notation did allow this but it had to be explicit - the outgoing transition that consumed the token needed to send a token back to the Place concerned (where Place is roughly equivalent to State). Example - a Clock could be represented by a Place and a timed Transition. The Transition would have an input link and an output link to the place, so when it fired it would consume a token from the Place, but immediately replace it. To be useful, there would also be another output link from the transition to another Place, supplying tokens that represent ticks of the Clock. > Obviously, parallelism is legal in activity diagrams, or there would be > no synchronization bars, but I'm tempted to stick to old habits, and > model each potential thread of control as a separate FSM. What do I > lose by this? To do this on a single diagram, you would AFAICS need to 'manufacture' an artificial state to hold the nested multiple parallel state chains. Apart from the layout problems, it will get cumbersome to represent cases where one of the forked activity chains joins with a chain from a different fork ( e.g. Fig 9-4 UML Distilled p.137, if you have it handy ). Incidentally the UML reference manual strongly hints that only one outgoing transition from an Activity State will fire; "If more than one guard condition evaluates to true, the choice is undefined. It may be nondeterministic, or a rule may be imposed as a semantic variation point". 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 *************************************************************************
