Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>The "lifeline1" represents an object execute during a period of time.</p> </blockquote> <p>The dotted vertical line represents the object's life time. An 'execution specification' box is drawn on the line when the object is active / executing / has control. </p> <blockquote> <p>During lifelin1 execution and exactly at The red circle "lifeline1" needs something from "lifeline2" to be able to complete its execution</p> </blockquote> <p>If it needed something to begin execution, it would not be shown with an execution specification to start with and would instead be shown as becoming active after it received a message. </p> <p>Instead, the block shows lifeline1 is shown as active, and sending a synchronous message.</p> <blockquote> <p>1)the "lifeline1" pause its execution and then</p> </blockquote> <p>No pause (or other timing) is implied by this sequence diagram.</p> <blockquote> <p>2) call synchronous message .(please clarify it a bit in your answer)</p> </blockquote> <p>It is similar to calling a method on an object - the flow of control in a synchronous message passes immediately from the sender to receiver, and on receipt of a synchronous message the receiver is shown as the active object. </p> <blockquote> <p>The pink line represent the duration of time that the "lifeline1" needs to reach the "lifeline2" to execute</p> </blockquote> <p>No timing is implied by this sequence diagram - it shows the sequence of operations only. Duration timings are shown using the Duration Constraint and Duration Observation notation shown in table 14.1 of the OMG&dagger; <a href="http://www.omg.org/spec/UML/2.4.1/" rel="nofollow">UML2 Superstructure</a>. </p> <blockquote> <p>3)The blue rectangle represent the duration of message execution</p> </blockquote> <p>At the stage in the process represented by the blue rectangle, the 'lifeline2' object is executing in response to the message. Saying 'message execution' is a bit vague - the object is executing, not the message.</p> <blockquote> <p>4)And the dotted line represents the duration of time that the "lifeline2" needs to reach the "lifeline2" to resume its execution.</p> </blockquote> <p>The dotted line is a return message. Because the message sent from "lifeline1" is synchronous, it does not continue execution until the return message is received.</p> <blockquote> <p>5)the black rectangle represent the period when a lifeline1 was idle</p> </blockquote> <p>Execution specification blocks on UML sequence diagrams represent when the object is actively executing. A object which is idle waiting for a synchronous message to return should be represented without the execution specification block on its lifeline. (the colours have no significance in UML - they are there in this diagram to let you talk about a particular block, they do not to show whether the object is active or not)</p> <p>I would take a slightly more formal approach and say that the execution should not be shown where it is, but should start after the return message is received to represent that lifeline1 continues - just like the a method which calls a method in another object does not receive flow of control back until the call returns. </p> <p>However, it very common to show an object which is waiting for a return message with an execution specification as it is sort of still controlling the sequence of operations. </p> <p>(Unfortunately the UML is so big and fluffy, almost any example anyone comes up with can be read in a different manner. As I have used UML to generate executable models for checking processes for deadlocks using pi-calculus, I tend to have a more rigid interpretation than someone who is, say, writing one on a white board to explain something to a co-developer)</p> <p>&dagger; the Object Management Group who maintain the UML standards, not as in 'OMG it's huge', though that also applies.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload