Issue 5324: example on page 6-11 (uml-scheduling-ftf)
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity: 
Summary: Second, in the example on page 6-11


"there is a notational difference that I don't get. <<CRAsync>> is put on
the receiving instance (on TelemDataDisplay) but for the synch.  invocations
<<CRSynch>> is put on the client side (TelemetryDisplayer).


'jaol@enea.se

Resolution: see above
Revised Text: Attach "CRasynch" stereotype to TGClock lifeline in figure 6-3.
Actions taken:
May 23, 2002: received issue
June 30, 2003: closed issue
Discussion: 
Resolution:
(BS) Well, the stereotype is attached to the action execution (not 
 the instance), which is mainfested as a focus of control block in the  diagram. So, the first block, labeled <<CRAsynch>> is invoked asynchronously  of the main thread of the TelemetryDisplayer (implying some kind of forking of a supplementary thread), while the subsequent blocks are invoked synchronously, indicating that the main thread will be  blocked until the synchronous actions are completed.
 (AM) I think that the <<CRasynch>> tag is attached to the wrong control block - it should be attached to the TGClock lifeline.

End of Annotations:=====
2)
Second, in the example on page 6-11


"there is a notational difference that I don't get. <<CRAsync>> is put
on
the receiving instance (on TelemDataDisplay) but for the synch.
invocations
<<CRSynch>> is put on the client side (TelemetryDisplayer).


'jaol@enea.se


Thanks again for all your help.


Alan