This link has been bookmarked by 155 people . It was first bookmarked on 16 Dec 2007, by mikeem em.
-
05 Jan 17
-
an object (i.e., lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead
-
Note: When reading this sequence diagram, assume that the analyst has already logged into the system.
-
guard
-
The option combination fragment is used to model a sequence that, given a certain condition, will occur; otherwise, the sequence does not occur.
-
-
29 Sep 16
-
22 Sep 16
-
16 Sep 16
-
24 Aug 16
-
23 Jun 16
Roman Motyka"eiving object represents an operation/method that the receiving object's class implem"
-
12 Nov 15
-
11 Jul 15
-
In addition to providing a visual border, the frame element also has an important functional use in diagrams depicting interactions, such as the sequence diagram. On sequence diagrams incoming and outgoing messages (a.k.a. interactions) for a sequence can be modeled by connecting the messages to the border of the frame element (as seen in Figure 2). This will be covered in more detail in the "Beyond the basics" section below.
-
Notice that in Figure 2 the diagram's label begins with the letters "sd," for Sequence Diagram. When using a frame element to enclose a diagram, the diagram's label needs to follow the format of:
Diagram Type Diagram Name
The UML specification provides specific text values for diagram types (e.g., sd = Sequence Diagram, activity = Activity Diagram, and use case = Use Case Diagram).
-
Messages
The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.
-
Again, the return messages are an optional part of a sequence diagram. The use of return messages depends on the level of detail/abstraction that is being modeled. Return messages are useful if finer detail is required; otherwise, the invocation message is sufficient. I personally like to include return messages whenever a value will be returned, because I find the extra details make a sequence diagram easier to read.
-
The example messages in Figure 5 show synchronous messages; however, in sequence diagrams you can model asynchronous messages, too. An asynchronous message is drawn similar to a synchronous one, but the message's line is drawn with a stick arrowhead, as shown in Figure 6.
-
Guards
When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow. Here, I will discuss guards in both UML 1.x as well as UML 2.0. In UML 1.x, a guard could only be assigned to a single message. To draw a guard on a sequence diagram in UML 1.x, you placed the guard element above the message line being guarded and in front of the message name. Figure 7 shows a fragment of a sequence diagram with a guard on the message addStudent method.
-
As you will notice in Figure 8, an alternative combination fragment element is drawn using a frame. The word "alt" is placed inside the frame's namebox. The larger rectangle is then divided into what UML 2 calls operands. [Note: Although operands look a lot like lanes on a highway, I specifically did not call them lanes. Swim lanes are a UML notation used on activity diagrams. Please refer to The Rational Edge's earlier article about Activity Diagrams.] Operands are separated by a dashed line. Each operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline. [Note: Usually, the lifeline to which the guard is attached is the lifeline that owns the variable that is included in the guard expression.] If an operand's guard equates to "true," then that operand is the operand to follow.
-
Loops
Occasionally you will need to model a repetitive sequence. In UML 2, modeling a repeating sequence has been improved with the addition of the loop combination fragment.
The loop combination fragment is very similar in appearance to the option combination fragment. You draw a frame, and in the frame's namebox the text "loop" is placed. Inside the frame's content area the loop's guard is placed towards the top left corner, on top of a lifeline. [Note: As with the option combination fragment, the loop combination fragment does not require that a guard condition be placed on it.] Then the loop's sequence of messages is placed in the remainder of the frame's content area. In a loop, a guard can have two special conditions tested against in addition to the standard Boolean test. The special guard conditions are minimum iterations written as "minint = [the number]" (e.g., "minint = 1") and maximum iterations written as "maxint = [the number]" (e.g., "maxint = 5"). With a minimum iterations guard, the loop must execute at least the number of times indicated, whereas with a maximum iterations guard the number of loop executions cannot exceed the number.
-
Referencing another sequence diagram
When doing sequence diagrams, developers love to reuse existing sequence diagrams in their diagram's sequences. [Note: It is possible to reuse a sequence diagram of any type (e.g., programming or business). I just find that developers like to functionally break down their diagrams more.] Starting in UML 2, the "Interaction Occurrence" element was introduced. The addition of interaction occurrences is arguably the most important innovation in UML 2 interactions modeling. Interaction occurrences add the ability to compose primitive sequence diagrams into complex sequence diagrams. With these you can combine (reuse) the simpler sequences to produce more complex sequences. This means that you can abstract out a complete, and possibly complex, sequence as a single conceptual unit.
An interaction occurrence element is drawn using a frame. The text "ref" is placed inside the frame's namebox, and the name of the sequence diagram being referenced is placed inside the frame's content area along with any parameters to the sequence diagram. The notation of the referenced sequence diagram's name follows the pattern of:
sequence diagram name[(arguments)] [: return value]
-
Gates
The previous section showed how to reference another sequence diagram by passing information through parameters and return values. However, there is another way to pass information between sequence diagrams. Gates can be an easy way to model the passing of information between a sequence diagram and its context. A gate is merely a message that is illustrated with one end connected to the sequence diagram's frame's edge and the other end connected to a lifeline. A reworking of Figures 11 and 12 using gates can be seen in Figures 14 and 15. The example diagram in Figure 15 has an entry gate called getBalance that takes the parameter of accountNumber. The getBalance message is an entry gate, because it is the arrowed line that is connected to the diagram's frame with the arrowhead connected to a lifeline. The sequence diagram also has an exit gate that returns the balance variable. The exit gate is known, because it's a return message that is connected from a lifeline to the diagram's frame with the arrowhead connected to the frame.
Figure 14: A reworking of Figure 11, using gates this time
-
-
27 Feb 15
-
19 Jan 15
-
The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur.
-
a business-level sequence diagram can be used as a requirements document to communicate requirements for a future system implementation. During the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level of refinement. When that occurs, use cases are often refined into one or more sequence diagrams.
-
One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement. Use cases are often refined into one or more sequence diagrams.
-
In addition to their use in designing new systems, sequence diagrams can be used to document how objects in an existing (call it "legacy") system currently interact. This documentation is very useful when transitioning a system to another person or organization.
-
The frame element is used as a basis for many other diagram elements in UML 2, but the first place most people will encounter a frame element is as the graphical boundary of a diagram. A frame element provides a consistent place for a diagram's label, while providing a graphical boundary for the diagram.
-
the frame element also has an important functional use in diagrams depicting interactions, such as the sequence diagram. On sequence diagrams incoming and outgoing messages (a.k.a. interactions) for a sequence can be modeled by connecting the messages to the border of the frame element
-
Notice that in Figure 2 the diagram's label begins with the letters "sd," for Sequence Diagram. When using a frame element to enclose a diagram, the diagram's label needs to follow the format of:
Diagram Type Diagram Name
The UML specification provides specific text values for diagram types (e.g., sd = Sequence Diagram, activity = Activity Diagram, and use case = Use Case Diagram).
-
The main purpose of a sequence diagram is to define event sequences that result in some desired outcome. The focus is less on messages themselves and more on the order in which messages occur; nevertheless, most sequence diagrams will communicate what messages are sent between a system's objects as well as the order in which they occur.
-
The diagram conveys this information along the horizontal and vertical dimensions: the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to.
-
When drawing a sequence diagram, lifeline notation elements are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled.
-
Lifelines are drawn as a box with a dashed line descending from the center of the bottom edge (Figure 3). The lifeline's name is placed inside the box.
-
The UML standard for naming a lifeline follows the format of:
Instance Name : Class Name
-
Note that, here, the lifeline name is underlined. When an underline is used, it means that the lifeline represents a specific instance of a class in a sequence diagram, and not a particular kind of instance (i.e., a role). In a future article we'll look at structure modeling. For now, just observe that sequence diagrams may include roles (such as buyer and seller) without specifying who plays those roles (such as Bill and Fred). This allows diagram reuse in different contexts. Simply put, instance names in sequence diagrams are underlined; roles names are not.
-
Our example lifeline in Figure 3 is a named object, but not all lifelines represent named objects. Instead a lifeline can be used to represent an anonymous or unnamed instance. When modeling an unnamed instance on a sequence diagram, the lifeline's name follows the same pattern as a named instance; but instead of providing an instance name, that portion of the lifeline's name is left blank.
-
Also, because sequence diagrams are used during the design phase of projects, it is completely legitimate to have an object whose type is unspecified: for example, "freshman."
-
The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.
-
To show an object (i.e., lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal). The message/method name is placed above the arrowed line.
-
Besides just showing message calls on the sequence diagram, the Figure 4 diagram includes return messages. These return messages are optional; a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline, and above this dotted line you place the return value from the operation.
-
The use of return messages depends on the level of detail/abstraction that is being modeled. Return messages are useful if finer detail is required; otherwise, the invocation message is sufficient. I personally like to include return messages whenever a value will be returned, because I find the extra details make a sequence diagram easier to read.
-
When modeling a sequence diagram, there will be times that an object will need to send a message to itself. When does an object call itself? A purist would argue that an object should never send a message to itself. However, modeling an object sending a message to itself can be useful in some cases.
-
The example messages in Figure 5 show synchronous messages; however, in sequence diagrams you can model asynchronous messages, too. An asynchronous message is drawn similar to a synchronous one, but the message's line is drawn with a stick arrowhead
-
When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow.
-
To draw a guard on a sequence diagram in UML 1.x, you placed the guard element above the message line being guarded and in front of the message name.
-
The notation of a guard is very simple; the format is:
[Boolean Test]
For example,
[pastDueBalance = 0]
-
In most sequence diagrams, however, the UML 1.x "in-line" guard is not sufficient to handle the logic required for a sequence being modeled. This lack of functionality was a problem in UML 1.x. UML 2 has addressed this problem by removing the "in-line" guard and adding a notation element called a Combined Fragment. A combined fragment is used to group sets of messages together to show conditional flow in a sequence diagram. The UML 2 specification identifies 11 interaction types for combined fragments.
-
-
11 Dec 14
-
show the interactions between objects in the sequential order that those interactions occur
-
frame element
-
diagram's label
-
the order in which messages occur
-
horizontal dimension
-
vertical dimension
-
time sequence
-
object instances that the messages are sent to
-
lifeline notation elements
-
a box with a dashed line descending from the center of the bottom edge
-
a specific instance of a class in a sequence diagram, and not a particular kind of instance (i.e., a role).
-
underline
-
unnamed instance on a sequence diagram,
-
lifeline's name is left blank
-
a line to the receiving object with a solid arrowhead
-
stick arrowhead
-
an operation/method that the receiving object's class implements.
-
message
-
return messages
-
a dotted line with an open arrowhead back to the originating lifeline,
-
depends on the level of detail/abstraction that is being modeled.
-
return messages are an optional
-
model asynchronous messages
-
Combined fragments (alternatives, options, and loops)
-
An option is used to model a simple "if then" statement
-
Combined fragments (break and parallel)
-
exception handling.
-
-
03 Nov 14
-
26 Aug 14
-
18 Dec 13
-
20 Nov 13
-
12 Nov 13
-
06 Nov 13
-
07 Oct 13
-
The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur.
-
One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement.
-
The notation
-
frame element is as the graphical boundary of a diagram
-
rame element is optional in UML
-
the frame element also has an important functional use in diagrams depicting interactions, such as the sequence diagram. On sequence diagrams incoming and outgoing messages (a.k.a. interactions) for a sequence can be modeled by connecting the messages to the border of the frame element
-
diagram's label begins with the letters "sd," for Sequence Diagram.
-
Diagram Type Diagram Name
-
The basics
-
The focus is less on messages themselves and more on the order in which messages occur
-
The main purpose of a sequence diagram is to define event sequences that result in some desired outcome
-
the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to
-
Lifelines
-
Lifelines represent either roles or object instances that participate in the sequence being modeled
-
Simply put, instance names in sequence diagrams are underlined; roles names are not.
-
if the lifeline is representing an anonymous instance of the Student class, the lifeline would be: " Student." Also, because sequence diagrams are used during the design phase of projects, it is completely legitimate to have an object whose type is unspecified: for example, "freshman."
-
Messages
-
a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline, and above this dotted line you place the return value from the operation.
-
the return messages are an optional part of a sequence diagram
-
are useful if finer detail is required
-
To draw an object calling itself, you draw a message as you would normally, but instead of connecting it to another object, you connect the message back to the object itself
-
Guards
-
condition must be met for a message to be sent to the object.
-
ou placed the guard element above the message line being guarded and in front of the message name
-
Alternatives
-
Alternatives are used to designate a mutually exclusive choice between two or more message sequences.
-
Option
-
n option is used to model a simple "if then" statement
-
Loops
-
modeling a repeating sequence has been improved with the addition of the loop combination fragment.
-
-
18 Sep 13
-
When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow.
-
Alternatives
Alternatives are used to designate a mutually exclusive choice between two or more message sequences. [Note: It is indeed possible for two or more guard conditions attached to different alternative operands to be true at the same time, but at most only one operand will actually occur at run time (which alternative "wins" in such cases is not defined by the UML standard).] Alternatives allow the modeling of the classic "if then else" logic (e.g., if I buy three items, then I get 20% off my purchase; else I get 10% off my purchase).
-
-
18 Aug 13
-
05 Jul 13
jeewantha samaraweerahttp://staruml.sourceforge.net/docs/user-guide%28en%29/ch04.html
-
05 Jun 13
-
09 Mar 13
-
le of reasons that the OMG improved UML. The main reason was that they wanted UML models to be capable of delivering Model Driven Architecture (MDA), which meant that the UML had to function as a more model driven notation. Also, the UML 1.x notation set was at times difficult to apply to larger applications. Furthermore, the notation elements needed to be improved in order to make diagrams more readable. (For example, modeling logical flow in UML 1.x was complicated and at times impossible. Changes to the sequence diagram's notation set in UML 2 have made vast improvements in modeling logic in sequences.)
-
However, an organization's business staff can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. Be
-
-
31 Jan 13
-
09 Jan 13
-
21 Nov 12
-
it uses an option combination fragment because more messages need to be sent if the student's past due balance is equal to zero
-
-
16 Nov 12
-
01 Oct 12
-
o show the interactions between objects in the sequential order that those interactions occur.
-
but the first place most people will encounter a frame element is as the graphical boundary of a diagram.
-
interactions, such as the sequence diagram
-
e letters "sd," for Sequence Diagram
-
(e.g., sd = Sequence Diagram, activity = Activity Diagram, and use case = Use Case Diagram).
-
gram is to define event sequences that result in some desired outcome
-
the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the
-
ifeline notation elements are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled.
-
Instance Name : Class Name
-
the lifeline name is underlined. When an underline is used, it means that the lifeline represents a specific instance of a class in a sequence diagram
-
To show an object (i.e., lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal)
-
The message/method name
-
placed above the arrowed line
-
ceiving object represents an operation/method that the receiving object's class implements.
-
The analyst object is calling the system object's getAvailableReports method
-
a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline,
-
dotted line you place the return value from the operation.
-
there will be times that an object will need to send a message to itself
-
y showing the system sending itself the message "determineAvailableReports," the model draws attention to the fact that this processing takes place in the system object.
-
draw a message as you would normally, but instead of connecting it to another object, you connect the message back to the object itself.
-
-
09 Jun 12
-
Guards
-
The previous section showed how to reference another sequence diagram by passing information through parameters and return values. However, there is another way to pass information between sequence diagrams. Gates can be an easy way to model the passing of information between a sequence diagram and its context. A gate is merely a message that is illustrated with one end connected to the sequence diagram's frame's edge and the other end connected to a lifeline. A reworking of Figures 11 and 12 using gates can be seen in Figures 14 and 15. The example diagram in Figure 15 has an entry gate called getBalance that takes the parameter of accountNumber. The getBalance message is an entry gate, because it is the arrowed line that is connected to the diagram's frame with the arrowhead connected to a lifeline. The sequence diagram also has an exit gate that returns the balance variable. The exit gate is known, because it's a return message that is connected from a lifeline to the diagram's frame with the arrowhead connected to the frame.
-
Figure 14: A reworking of Figure 11, using gates this time
-
Figure 15: A reworking of Figure 12, using gates this time
-
-
23 May 12
-
18 May 12
-
22 Mar 12
-
12 Mar 12
-
31 Jan 12
-
19 Dec 11
-
13 Dec 11
-
06 Dec 11
-
02 Dec 11
-
28 Nov 11
-
28 Oct 11
-
06 Oct 11
-
02 Jul 11
-
16 Jun 11
-
The diagram's purpose
-
The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur
-
However, an organization's business staff can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. Besides documenting an organization's current affairs, a business-level sequence diagram can be used as a requirements document to communicate requirements for a future system implementation.
-
use cases are often refined into one or more sequence diagrams
-
One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement.
-
sequence diagrams can be used to document how objects in an existing (call it "legacy") system currently interact
-
The notation
-
. On sequence diagrams incoming and outgoing messages (a.k.a. interactions) for a sequence can be modeled by connecting the messages to the border of the frame element (as seen in Figure 2). This will be covered in more detail in the "Beyond the basics" section below.
-
diagram's label begins with the letters "sd," for Sequence Diagram
-
The basics
-
The main purpose of a sequence diagram is to define event sequences that result in some desired outcome
-
The focus is less on messages themselves and more on the order in which messages occur; nevertheless, most sequence diagrams will communicate what messages are sent between a system's objects as well as the order in which they occur
-
Lifelines
-
Lifelines represent
-
When drawing a sequence diagram, lifeline notation elements are placed across the top of the diagram
-
either roles or object instances that participate in the sequence being modeled
-
Lifelines are drawn as a box with a dashed line descending from the center of the bottom edge (Figure 3). The lifeline's name is placed inside the box.
-
instance name is freshman
-
class Student
-
here, the lifeline name is underlined. When an underline is used, it means that the lifeline represents a specific instance of a class in a sequence diagram, and not a particular kind of instance (i.e., a role)
-
not all lifelines represent named objects. Instead a lifeline can be used to represent an anonymous or unnamed instance. When modeling an unnamed instance on a sequence diagram, the lifeline's name follows the same pattern as a named instance; but instead of providing an instance name, that portion of the lifeline's name is left blank
-
sequence diagrams are used during the design phase of project
-
Messages
-
The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.
-
To show an object (i.e., lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal)
-
The message/method name is placed above the arrowed line
-
Figure 4, the analyst object makes a call to the system object which is an instance of the ReportingSystem class. The analyst object is calling the system object's getAvailableReports method. The system object then calls the getSecurityClearance method with the argument of userId on the secSystem object, which is of the class type SecuritySystem
-
Figure 4 diagram includes return messages. These return messages are optional; a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline, and above this dotted line you place the return value from the operation
-
In Figure 4 the secSystem object returns userClearance to the system object when the getSecurityClearance method is called. The system object returns availableReports when the getAvailableReports method is called.
-
the return messages are an optional part of a sequence diagram
-
. Return messages are useful if finer detail is required; otherwise, the invocation message is sufficient.
-
When modeling a sequence diagram, there will be times that an object will need to send a message to itself
-
"determineAvailableReports,"
-
To draw an object calling itself, you draw a message as you would normally, but instead of connecting it to another object, you connect the message back to the object itself.
-
Guards
-
When modeling object interactions, there will be times when a condition must be met for a message to be sent to the object.
-
In Figure 7, the guard is the text "[pastDueBalance = 0]." By having the guard on this message, the addStudent message will only be sent if the accounts receivable system returns a past due balance of zero
-
Alternatives
-
Alternatives are used to designate a mutually exclusive choice between two or more message sequences.
-
Alternatives allow the modeling of the classic "if then else" logic (e.g., if I buy three items, then I get 20% off my purchase; else I get 10% off my purchase).
-
The word "alt" is placed inside the frame's namebox
-
Operands are separated by a dashed line.
-
operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline.
-
If an operand's guard equates to "true," then that operand is the operand to follow.
-
Alternative combination fragments are not limited to simple "if then else" tests. There can be as many alternative paths as are needed. If more alternatives are needed, all you must do is add an operand to the rectangle with that sequence's guard and messages.
-
The option combination fragment is used to model a sequence that, given a certain condition, will occur; otherwise, the sequence does not occu
-
The option combination fragment notation is similar to the alternation combination fragment, except that it only has one operand and there never can be an "else" guard (it just does not make sense here).
-
Occasionally you will need to model a repetitive sequence. In UML 2, modeling a repeating sequence has been improved with the addition of the loop combination fragment.
-
The loop combination fragment is very similar in appearance to the option combination fragment. You draw a frame, and in the frame's namebox the text "loop" is placed. Inside the frame's content area the loop's guard is placed towards the top left corner, on top of a lifeline
-
The special guard conditions are minimum iterations written as "minint = [the number]" (e.g., "minint = 1") and maximum iterations written as "maxint = [the number]" (e.g., "maxint = 5").
-
-
28 May 11
-
03 Apr 11
-
28 Mar 11
-
09 Feb 11
-
03 Feb 11
-
26 Jan 11
-
14 Jan 11
-
16 Dec 10
-
01 Nov 10
-
28 Oct 10
-
08 Oct 10
-
UML basics: The sequence diagram
-
UML basics: Th
-
-
15 Aug 10
Vladimir ShulyakWhen modeling a sequence diagram, there will be times that an object will need to send a message to itself. When does an object call itself? A purist would argue that an object should never send a message to itself. However, modeling an object sending a m
uml sequence diagram modeling development sequence-diagram reference tutorial
-
27 May 10
-
30 Apr 10
-
29 Mar 10
-
23 Mar 10
-
22 Mar 10
-
08 Mar 10
-
25 Feb 10
-
22 Jan 10
-
10 Dec 09
-
30 Sep 09
-
19 Aug 09
-
24 Jun 09
-
23 Jun 09
-
14 May 09
-
06 Feb 09
-
12 Dec 08
-
08 Dec 08
-
When drawing a sequence diagram, lifeline notation elements are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled. 1 Lifelines are drawn as a box with a dashed line descending from the center of the bottom edge (Figure 3). The lifeline's name is placed inside the box.
-
The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.
To show an object (i.e., lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal). The message/method name is placed above the arrowed line. The message that is being sent to the receiving object represents an operation/method that the receiving object's class implements. In the example in Figure 4, the analyst object makes a call to the system object which is an instance of the ReportingSystem class. The analyst object is calling the system object's getAvailableReports method. The system object then calls the getSecurityClearance method with the argument of userId on the secSystem object, which is of the class type SecuritySystem. 2
-
Alternatives are used to designate a mutually exclusive choice between two or more message sequences. 3 Alternatives allow the modeling of the classic "if then else" logic (e.g., if I buy three items, then I get 20% off my purchase; else I get 10% off my purchase).
As you will notice in Figure 8, an alternative combination fragment element is drawn using a frame. The word "alt" is placed inside the frame's namebox. The larger rectangle is then divided into what UML 2 calls operands. 4 Operands are separated by a dashed line. Each operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline. 5 If an operand's guard equates to "true," then that operand is the operand to follow.
-
The option combination fragment is used to model a sequence that, given a certain condition, will occur; otherwise, the sequence does not occur. An option is used to model a simple "if then" statement (i.e., if there are fewer than five donuts on the shelf, then make two dozen more donuts).
The option combination fragment notation is similar to the alternation combination fragment, except that it only has one operand and there never can be an "else" guard (it just does not make sense here). To draw an option combination you draw a frame. The text "opt" is placed inside the frame's namebox, and in the frame's content area the option's guard is placed towards the top left corner on top of a lifeline. Then the option's sequence of messages is placed in the remainder of the frame's content area. These elements are illustrated in Figure 9.
-
Occasionally you will need to model a repetitive sequence. In UML 2, modeling a repeating sequence has been improved with the addition of the loop combination fragment.
The loop combination fragment is very similar in appearance to the option combination fragment. You draw a frame, and in the frame's namebox the text "loop" is placed. Inside the frame's content area the loop's guard 6 is placed towards the top left corner, on top of a lifeline. Then the loop's sequence of messages is placed in the remainder of the frame's content area. In a loop, a guard can have two special conditions tested against in addition to the standard Boolean test. The special guard conditions are minimum iterations written as "minint = [the number]" (e.g., "minint = 1") and maximum iterations written as "maxint = [the number]" (e.g., "maxint = 5"). With a minimum iterations guard, the loop must execute at least the number of times indicated, whereas with a maximum iterations guard the number of loop executions cannot exceed the number.
-
Referencing another sequence diagram
When doing sequence diagrams, developers love to reuse existing sequence diagrams in their diagram's sequences. 7 Starting in UML 2, the "Interaction Occurrence" element was introduced. The addition of interaction occurrences is arguably the most important innovation in UML 2 interactions modeling. Interaction occurrences add the ability to compose primitive sequence diagrams into complex sequence diagrams. With these you can combine (reuse) the simpler sequences to produce more complex sequences. This means that you can abstract out a complete, and possibly complex, sequence as a single conceptual unit.
An interaction occurrence element is drawn using a frame. The text "ref" is placed inside the frame's namebox, and the name of the sequence diagram being referenced is placed inside the frame's content area along with any parameters to the sequence diagram. The notation of the referenced sequence diagram's name follows the pattern of:
sequence diagram name[(arguments)] [: return value]
Two examples:
1.
Retrieve Borrower Credit Report(ssn) : borrowerCreditReportor
2.
Process Credit Card(name, number, expirationDate, amount : 100)In example 1, the syntax calls the sequence diagram called Retrieve Borrower Credit Report and passes it the parameter ssn. The Retreive Borrower Credit Report sequence returns the variable borrowerCreditReport.
In example 2, the syntax calls the sequence diagram called Process Credit Card and passes it the parameters of name, number, expiration date, and amount. However, in example 2 the amount parameter will be a value of 100. And since example 2 does not have a return value labeled, the sequence does not return a value (presumably, the sequence being modeled does not need the return value).
-
-
17 Nov 08
-
01 Oct 08
-
27 Sep 08
-
23 Jun 08
-
22 Jun 08
-
03 Jun 08
-
07 May 08
-
10 Feb 08
-
28 Jan 08
-
24 Jan 08
-
03 Dec 07
-
08 Nov 07
-
15 Oct 07
-
17 Jun 07
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.