[Leslie Munday] On the receiving end, a transtion into an activity causes that activity to fire. If you wish for muliple activities to complete before exercising a subsequent activity then you must use a synchronization bar in order to wait for completion. So, one more brief simple question, if a transition activates an activity, and while that activity is exercising it receives a subsequent transition, 1) does the activity reset and start again, 2) does it complete before addressing the new stimulus, 3) does it ignore the subsequent stimulus or 4) is the behaviour customisable based upon the specification of the activity?
[wmj] Are you trying to revisit (re-invent?) Concurrent and/or Co-operating Processes using RUP taxonomy and UML notation? Have a nice "W/E" ! WMJ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Leslie Munday Sent: Friday, July 12, 2002 4:56 PM Cc: Rose Forum; RUP Forum Subject: Re: Re: (RUP)(ROSE) Multiple Activity instances > > Excuse me for jumping in and redirecting this thread, but > > thought this might be an opportune moment to bring up a > > question asked elsewhere for which I could get no real > > consenus. > > > > When I have an activity that forks into many activities and > > eventually all these activity threads rejoin a single, > > terminating activity, similar to the original example in this > > thread: > > 1) What is the difference between showing, all transitions > > coming from the initial activity and flowing into each of the > > subsequent parallel activities, and > > showing a single transition from the initial activity as entering > > a synchronization bar and then several transitions exiting the > > synchonization bar and entering my parallel activities? > > This information may go out of date with UML 2.0, but... > > As Activity diagrams are modified state diagrams, if > there are multiple transitions coming out of one Activity > state, then these are, AFAICS, alternatives. Thus only > one of the activities would happen next, rather than all > in parallel. OTOH, I agree that there is a good deal of > ambiguity, and it would be safer explicitly to say what > you mean. > > > 2) What is the difference between showing, all transition > > from parallel activities entering my single terminal activity, > > and all transitions from parallel activities entering a > > synchronization bar and a single transition from the > > synchronization bar entering my terminal activity? > > If my first answer is correct, then only one activity at a > time (per instantiation of the activity diagram) could > be happening, and once that is complete, the transition > to the terminal activity would occur. > > If you want the activities to occur in parallel, use the > synchronization bars. That way, there is no ambiguity > in what you say is to happen. > Thankyou to Paul, David, James and Martin (Fowler that is) for helping to supply the answer to my poser. I gather the consensus in my own simplistic terms, is that transitions from an activity occur asynchronously, whereas transitions from a fork occur in parallel. On the receiving end, a transtion into an activity causes that activity to fire. If you wish for muliple activities to complete before exercising a subsequent activity then you must use a synchronization bar in order to wait for completion. So, one more brief simple question, if a transition activates an activity, and while that activity is exercising it receives a subsequent transition, 1) does the activity reset and start again, 2) does it complete before addressing the new stimulus, 3) does it ignore the subsequent stimulus or 4) is the behaviour customisable based upon the specification of the activity? Les. (Please don't lose any sleep over the W/E, answer can wait until Monday.) ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag **************************************************************************** ***** * 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 *************************************************************************
