Section 7.8. Managing Complex Interactions with Sequence Fragments

7.8. Managing Complex Interactions with Sequence Fragments

Most of what you've seen in this chapter will have been pretty familiar to anyone who has used sequence diagrams in UML 1.x. But now it's time for something completely different.

In the bad old days of pre-UML 2.0, sequence diagrams quickly became huge and messy, and contained far too much detail to be easily understood or maintained. There were no built-in, standard ways to show loops and alternative flows, so you had to "grow your own" solutions. This tended to contribute to the size and complexity of the sequence diagrams rather than helping to manage it.

Something new was needed to help the modeler work with the detail that a sequence diagram needed to capture, allowing her to create organized and structured sequence diagrams that showed complex interactions such as loops and alternate flows. The answer from the UML 2.0 designers was the sequence fragment.

A sequence fragment is represented as a box that encloses a portion of the interactions within a sequence diagram, as shown in Figure 7-19.

A sequence fragment's box overlaps the region of the sequence diagram where the fragment's interactions take place. A fragment box can contain any number of interactions and, for large complex interactions, further nested fragments as well. The top left corner of the fragment box contains an operator. The fragment operator indicates which type of fragment this is.

Figure 7-19. A sequence fragment located as part of a larger sequence diagram, with notes to indicate the fragment box, any parameters, and its operator

In Figure 7-19, the operator is opt, which means that this is an optional fragment. All the interactions contained within the fragment box will be executed according to the result of the fragments guard condition parameter.

Some fragment types do not need additional parameters as part of their specification, such as the ref fragment type discussed in the next section, but the guard condition parameter is needed by the opt fragment type to make a decision as to whether it should execute its interactions or not. In the case of the opt fragment type, the interactions that the fragment contains will be executed only if the associated guard condition logic evaluates to true.

7.8.1. Using a Sequence Fragment: The ref Fragment

The ref type of sequence fragment finally alleviates some of the maintenance nightmare presented by the huge sequence diagrams that are often created for complex systems. In Figure 7-20, the ref fragment represents a piece of a larger sequence diagram.

The interactions by which the Administrator actor selects a blog account type for creation are now contained within the referenced sequence fragment. Figure 7-21 shows how the referenced fragment can be expressed on a separate sequence diagram.

Figure 7-20. Capturing the interactions used to select an account type within a ref sequence fragment

Figure 7-21. A referenced sequence diagram that contains the new account selection interactions

Along with managing the sheer size of large sequence diagrams, the ref fragment also presents an opportunity to reuse a set of common interactions. Several ref fragment boxes can reference the same set of interactions, thereby reusing the interactions in multiple places.

The ref fragment type works in a very similar manner to the <<include>> use case relationship. See Chapter 2 for more about the <<include>> use case relationship.

7.8.2. A Brief Overview of UML 2.0's Fragment Types

UML 2.0 contains a broad set of different fragment types that you can apply to your sequence diagrams to make them more expressive, as shown in Table 7-4.

Table 7-4. The fragment family and explanations why each type might be useful when creating sequence diagrams
Type	Parameters	Why is it useful?
ref	None	Represents an interaction that is defined elsewhere in the model. Helps you manage a large diagram by splitting, and potentially reusing, a collection of interactions. Similar to the reuse modeled when the `<<include>>` use case relationship is applied.
assert	None	Specifies that the interactions contained within the fragment box must occur exactly as they are indicated; otherwise the fragment is declared invalid and an exception should be raised. Works in a similar fashion to the `assert` statement in Java. Useful when specifying that every step in an interaction must occur successfully, i.e., when modeling a transaction.
loop	min times, max times, [guard_condition]	Loops through the interactions contained within the fragment a specified number of times until the guard condition is evaluated to false. Very similar to the Java and C# `for(..)` loop. Useful when you are trying execute a set of interactions a specific number of times.
break	None	If the interactions contained within the break fragment occur, then any enclosing interaction, most commonly a loop fragment , should be exited. Similar to the `break` statement in Java and C#.
alt	[guard_condition1] ... [guard_condition2] ... [else]	Depending on which guard condition evaluates to true first, the corresponding sub-collection of interactions will be executed. Helps you specify that a set of interactions will be executed only under certain conditions. Similar to an `if(..) else` statement in code.
opt	[guard_condition]	The interactions contained within this fragment will execute only if the guard condition evaluates to true. Similar to a simple `if(..)` statement in code with no corresponding `else`. Especially useful when showing steps that have been reused from another use case's sequence diagrams, where `<<extend>>` is the use case relationship.
neg	None	Declares that the interactions inside this fragment are not to be executed, ever. Helpful if you are just trying to mark a collection of interactions as not executed until you're sure that those interactions can be removed. Most useful if you happen to be lucky enough to be using an Executable UML tool where your sequence diagrams are actually being run. Also can be helpful to show that something cannot be done, e.g., when you want to show that a participant cannot call `read( )` on a socket after `close( )`.Works in a similar fashion to commenting out some method calls in code.
par	None	Specifies that interactions within this fragment can happily execute in parallel. This is similar to saying that there is no need for any thread-safe locking required within a set of interactions.
region	None	Interactions within this type of fragment are said to be part of a critical region. A critical region is typically an area where a shared participant is updated. Combined with parallel interactions, specified using the par fragment type, you can model where interactions are not required to be thread- or process-safe (par fragment) and where locks are required to prevent parallel interactions interleaving (region fragment ). Has similarities synchronized blocks and object locks in Java.

Sequence fragments make it easier to create and maintain accurate sequence diagrams. However, it's worth remembering that no fragment is an island; you can mix and match any number of fragments to accurately model the interactions on a sequence diagram. Be wary if your diagrams become huge and unwieldy even when you are using fragments, since you might simply be trying to model too much in one sequence.

We've given you a brief overview of sequence diagram fragments here. All the different sequence diagram fragment types are a big subject in their own right and are a little beyond the scope of this book. For a more in-depth look at the different types of sequence diagram fragments, see UML 2.0 in a Nutshell (O'Reilly).