Gonzalo G�nova wrote: > In ordinary language "message" means > basically "passing of information", while in OO languages it means mainly > "passing of execution control", usually by invoking an operation on the > receiver of the message. [snip] a synchronous message, represented as > a one-way arrow, means passing of control in both ways (pass and return), as > well as passing of information also in both ways (parameters and return > values). Asynchronous messages are more like ordinary language messages, in > the sense that there is no implicit return in the message: if you want a > response, you have to send another asynchronous message back to the original > sender.
I think that interaction diagrams are normally drawn with the implicit assumption that the objects are messaging each other simply via operations. I don't think that the UML actually binds you to use that implicit model. Objects in different devices, or invoked by different threads, may be messaging each other in the same diagram as objects in common devices and threads. For better or worse, I have a tendency to model interactions without implicit returns, particularly during inception and elaboration. This approach is more general than assuming a single processor, it nails down my intentions very plainly, it seems simpler to understand than implicit returns, and it forces me to develop semantics for the application that make sense in the context of each object. People who implement my designs are free to turn my explicit returns into return types of the initializing operations. There is a downside to my habit: current tools do not support reverse engineering to interaction diagrams. The interaction model will need to be updated manually. If you are using sequence diagrams deep into the project, objects are more and more likely to be interacting within a single processor and on a single thread. Implicit returns get more appropriate as you get down to deeper levels of detail. A fixed habit of modeling with implicit returns will have its own problems, such as interaction diagrams that do not accurately model potential problems with system timing. Finally, an appeal to authority: The only kind of message arrow that my copy of Rose supports normally means asynchronous messaging according to the UML Spec. OMG Unified Modeling Language Specification Version 1.3 First Edition: March 2000 "3.61.3 Presentation options "The following arrowhead variations may be used to show different kinds of communications: "filled solid arrowhead "Procedure call or other nested flow of control. The entire nested sequence is completed before the outer level sequence resumes. May be used with ordinary procedure calls. May also be used with concurrently active objects when one of them sends a Signal and waits for a nested sequence of behavior to complete. "stick arrowhead "Flat flow of control. Each arrow shows the progression to the next step in sequence. Normally all of the messages are asynchronous. "half stick arrowhead "An asynchronous Stimulus. Used instead of the stick arrowhead to explicitly show an asynchronous communication between two Objects in a procedural sequence. "dashed arrow with stick arrowhead "Return from procedure call." -Eric ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Admin.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 * *************************************************************************
