[Eric D. Tarkington] You are not paraphrasing me correctly (could be my fault).
[wmj] Petri Nets notation will eliminate mis-communication in the situation in question. Respectfully WMJ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Eric D. Tarkington Sent: Monday, July 15, 2002 3:25 PM To: [EMAIL PROTECTED] Cc: RUP Forum; Rose Forum Subject: Re: (RUP) Re: (ROSE) Multiple Activity instances [EMAIL PROTECTED] wrote: > > 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. 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. 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). 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? -Eric **************************************************************************** ***** * RUP Forum is a public venue for discussions about the * Rational Unified Process (RUP). * * For RUP support materials, process Plug-Ins, tutorials, whitepapers, * a biweekly column, Rational University training courses, and more, * please visit the Rational Developer Network (available to Rational * customers) at: http://www.rational.net. * * For technical support of RUP, RPW, Rose or any other Rational * product, please visit: http://www.rational.com/support * * For other discussion groups, such as Rose and UML, please * sign up at: http://www.rational.com/support/usergroups/index.jsp * * To reply to a posting, please "Reply to all" or send * To: [EMAIL PROTECTED] * * Admin.Subscription Requests: [EMAIL PROTECTED] * * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send an email: * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rup_forum * **************************************************************************** ************************************************************************ * 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 *************************************************************************
