Often, some kind of iterator object is ultimately used, such as an implementation of or a C++ standard library iterator, although in the sequence diagram that low-level 'mechanism' need not be shown in theĪt the time of this writing, the UML specification did not (and may never) have an official idiom for this case. Iteration Over a CollectionĪ common algorithm is to iterate over all members of a collection (such as a list or map), sending the same message to each. See Figure 15.15.įigure 15.15 Mutually exclusive conditional messages. Use UML 1 style only for simple single messages when sketching.Īn ALT frame is placed around the mutually exclusive alternatives. See Figure 15.14.įigure 15.14 A conditional message in UML 1.x notationa simple style. The older UML 1.x notation for single conditional messages in sequence diagrams is not legal in UML 2, but so simple that especially when sketching it will probably be popular for years to come. The UML 2.x notation to show a single conditional message is heavyweight, requiring an entire OPT frame box around one message (seeįigure 15.13). Conditional Messages in UML 1.x StyleStill Useful? See Figure 15.13.įigure 15.13 A conditional message. Notice that the guard is placed over the related lifeline. The LOOP frame notation to show looping is shown in Figure 15.12.Īn OPT frame is placed around one or more messages. Parallel fragments that execute in parallel.Ĭritical region within which only one thread can run. Optional fragment that executes if guard is true. There is discussion that the specification will be enhanced to define a FOR loop, such as loop(i, 1, 10) Can also write loop(n) to indicate looping n times. The following table summarizes some common frame operators:Īlternative fragment for mutual exclusion conditional logic expressed in the guards. To support conditional and looping constructs (among many other things), the UML uses frames.įrames are regions or fragments of the diagrams they have an operator or label (such as loop) and a guard The UML lifeline notation provides a way to express this destruction (see Figure 15.11).įigure 15.11 Object destruction.

Have automatic garbage collection, or when you want to especially indicate an object is no longer usable (such as a closedĭatabase connection). For example, when using C++ which does not In some circumstances it is desirable to show explicit destruction of an object. The typical interpretation (in languages such as Java or C#) of a create message on a dashed line with a filled arrow is 'invoke the new operator and call the constructor'. The message name create is not requiredanything is legalbut it's a UML idiom.įigure 15.10 Instance creation and object lifelines. The arrow is filled if it's a regular synchronous message (such as implying invoking a Java constructor), or open (stickĪrrow) if an asynchronous call. Object creation notation is shown in Figure 15.10. You can show a message being sent from an object to itself by using a nested activation bar (see Figure 15.9).įigure 15.9 Messages to 'this.' Creation of Instances See Figure 15.8.įigure 15.8 Two ways to show a return result from a message. Line is normally labelled with an arbitrary description of the returning value. I prefer the first approach when sketching, as it's less effort.

Using a reply (or return) message line at the end of an activation bar.īoth are common in practice. Using the message syntax returnVar = message(parameter). There are two ways to show the return result from a message: The bar is optional.ĭrawing the bar is more common (and often automatic) when using a UML CASE tool, and less common when wall sketching. Stack) using an execution specification bar (previously called an activation bar or simply an activation in UML 1). Without the ball, intending by convention it is a found message.įocus of Control and Execution Specification BarsĪs illustrated in Figure 15.7, sequence diagrams may also show the focus of control (informally, in a regular blocking call, the operation is on the call However, by convention a team or tool may ignore showing this, and instead use a regular message line In the example of Figure 15.7 the starting message is called a found message in the UML, shown with an opening solid ball it implies the sender will not be specified, is not known, or that the message is comingįrom a random source. The time ordering is organized from top to bottom of lifelines.įigure 15.7 Messages and focus of control with execution specification bar. Solid line between the vertical lifelines (see Figure 15.7). Each (typical synchronous) message between objects is represented with a message expression on a filled-arrowed

Sequence diagram ifelse