| Prev | Next |
Lifelines, Messages and Activations
In a Sequence diagram, the Blocks that participate in the interaction have a lifetime that is represented by a dashed line, emanating from the base of the element and continuing vertically for the life of the element. Elements can be created or destroyed at any time during the period represented by the Sequence diagram, and the lifeline therefore represents their existence. Elements that are present at the top of the diagram are created at the beginning of the interaction. A message exchange between a sender and a receiver will originate in one lifeline (the sender) and end in another (the receiver).
The sender is effectively calling or activating some behavior provided by the receiving lifeline. Enterprise Architect provides useful mechanisms to utilize behaviors already defined in the form of operations. This illustration shows the properties of an existing message, which the modeler is able to select from a drop down list of previously defined operations. Alternatively, the modeler can define a new operation by selecting the .
Formally, when a message targets a lifeline an execution occurs, meaning that a behavior is initiated or augmented. This execution is represented visually by an activation, which is drawn on the diagram as a thin rectangular overlay on the lifeline, the length of which represents the relative duration of the behavior. The extent of the rectangle activation is ended when a reply message is sent back to the caller.
A Block (Instance) can be both the sender and the receiver of a message, which can be referred to as a reflexive message because it starts and ends on the same lifeline. In this case a second and shorter activation rectangle is overlaid on the first activation but offset to the right.
Messages that Create and Destroy Blocks
Any number of Block Instances can form part of an interaction, and often a set of these instances will be present for the duration of the time represented by the Sequence diagram. These Blocks will be positioned in a row across the top of the diagram. It is, however, possible for Blocks to be created and destroyed during the sequence of the diagram. For example, a particular Block might only be needed for a short time and so could be instantiated, perform its function and then be destroyed. Enterprise Architect allows an Engineer to specify that a message is a Create message, which means that the receiving Block will be instantiated at that point in the diagram's time sequence. This is achieved by setting the Life Cycle message action to 'New' as indicated in this illustration.
Setting this property has the effect of moving the targeted Block to a position lower in the diagram, signifying that the Block Instance would not be created until this point in the overall time sequence of the diagram. The message line style is also altered to a dashed line with an open arrow-head to reflect that it is a Create message. Other aspects of the semantics and effect of this message are unchanged.
In an analogous way the lifetime of an Instance can be ended by sending a Destroy message. Practically, this means that the Instance has served its purpose and is no longer required. This can be achieved easily by once again setting a message property but this time we set the Life Cycle message action to 'Delete'.
Setting this property has the effect of immediately terminating the lifetime of the Instance; this is represented visually by the dashed lifeline being arrested by a small cross on the lifeline at the point in time that the message arrives.
When a Sequence diagram is representing a software system that has bounded memory available, the destruction of the targeted instance will result in allocated memory being returned to the memory pool. In systems engineering there can be a variety of other pay-offs from managing the lifetime of electro-mechanical objects, such as power consumption, over-heating, availability, or even risks such as security.
Synchonous and Asynchronous Messages
Messages essentially represent sending some type of request from a sender to a receiver. There are two fundamental ways the sender of a message can interact with the recipient. The first type of message is called a Synchronous message because the messages occur at approximately the same point in time. With this type of message the sender waits until the recipient replies before sending additional messages. The second type of message is called Asynchronous because the sender does not wait for a reply from the recipient before continuing on with the execution, including sending additional messages to this or other recipients.
Enterprise Architect by default creates Synchronous messages, but the message type can be altered by setting the 'Synch type' property on the 'Properties' dialog. When the message type is set to Synchronous (default) this sets the line style to solid with a closed arrow head pointing to the recipient Instance. The line can be annotated with the name and parameters of the message.
Asynchronous messages represent calls to operations, or signals that are sent to recipients; in either case the sender does not expect a reply nor pause its execution in wait of one. In the case of the call to an operation, the operation itself would be defined as asynchronous and the system or machine represented by the diagram would know not to wait for a message return (reply). Enterprise Architect allows this message type to be set through the 'Synch' property as explained previously. When the message type is set to Asynchronous this sets the line style to dashed with an open arrow head pointing to the recipient Instance. The line can be annotated with the name and parameters of the message.
There is a third type of message that can optionally be used with a Synchronous message, this being the Reply Message. This message signifies an operation that has been invoked on the recipient returning a receipt that the behavior has been executed and is complete. The inclusion of Reply messages in a diagram is a stylistic decision. Some engineers and modelers prefer to leave them off diagrams to reduce the visual clutter. If a return type and value have been set, this will be returned as part of the Reply message.
Blocks can have both Operations and Receptions specified as part of their definition; this paradigm describes the relationship of Operations and Receptions to messages and signals.
- Synchronous Invocation of Operation - Synchronous Message
- Asynchronous Invocation of Operation - Asynchronous Message
- Reception Receipt of Signal - Asynchronous Message