> 
> > 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.
> 
> The latter is true, the former is probably true (but doesn't seem
> to have been nailed down for certain).
>

If the former turns out to be true, then I believe that the latter is 
unnecessary, because the equivalent situation can occur by indicating that all 
transitions occur simultaneously.

(For eg, activity 'A' has steps 1 and 2, occuring in this sequence. I can 
indicate asynchronous transitions by labeling my transitions '1 is complete' 
and '2 is complete' .. or .. I could indicate parallel transitions by labelling 
both exits from the activity with the same name.)

> 
> > 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.
> 
> It woulds appear so.
> 
> > 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?
> 
> We must first question how such a precondition could arise.
> For each instantiation of an Activity Diagram, if the only
> way that we can get activities happening in parallel is via
> a fork, then this precondition can only occur between
> a fork and a join.  
> 
> If I were writing an activity diagram where there could be
> more than one transition into an activity after a fork,
> but without a join, then I would expect this occurrence
> to cause a new instantiation of the activity that may be
> proceeding in parallel with another instantiation of the
> activity from another thread derived from the fork.
> 
> OTOH, what I expect may not be what other folk expect;
> the situation is a bit ambiguous for my purposes and I'd
> want to state clearly and unambiguously what I expect
> to happen.
> 
> I guess UML is like any other language - you can write
> a sentence that is grammatically and syntactically
> correct, but it may still be nonsense.
> 
> So my (tentative) answer is :-
> 
> 5) It starts a separate instantiation of the activity that may run
>   in parallel with other instantiations.
> 
> But don't take my word on this; I admit that I may well be wrong.
> 
I thought of this option on the way home. So the question becomes: "Is it 
feasible to be able to indicate that several instances of an activity may 
execute in parallel, in a single activity diagram?".

Les.

________________________________________________
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
*************************************************************************

Reply via email to