Sequence Diagrams

Think you know all about sequence diagrams? Well, while you were sleeping, the UML guys quietly went about adding some significant capabilities which make the sequence diagrams much more effective than you ever thought they can be.

The primary trick they introduced was a thing called the interaction fragment. This is nothing but a smaller piece of a bigger sequence diagram. A natural notation for this is a bounded rectangle.

Now take the interaction fragment one step further to create a combined fragment, which combines multiple interaction fragments into a bigger, macro interaction fragment.

Consider the following example.

Combined Fragment – alt

The box titled alt Payer is a combined fragment and is made up of three interaction fragments (with dashed lines acting as separators).

What does the alt stand for? It stands for alternate. And pray, what is that supposed to mean?

Well, the alt is really an operator and the three interaction fragments are its operands. Ergo, in this example, alt stands for three possible alternate flows. Think of it as modeling a switch – case, with alt being synonymous with switch and each of the three interaction fragments being a case. Each case needs to have a condition associated with it, right? You see the condition represented at the top left corner of each of the three interaction fragments.

Now, read the diagram. What does it say? Very little really, but very meaningful.

• If the payer concerned is Anthem, then the MemberEligibility component instantiates the Anthem version of the MemberEligibilityService and invokes the getPatientEligibilitySummary method on it.
• If the payer concerned is Blue Cross Blue Shield of Georgia, then the MemberEligibility component instantiates the BCBS Georgia version of the MemberEligibilityService and invokes the getPatientEligibilitySummary method on it.
• Finally, if the payer concerned is Blue Cross California, then the MemberEligibility component instantiates the Blue Cross California version of the MemberEligibilityService and invokes the getPatientEligibilitySummary method on it.

With this basic idea of combined fragments in hand, it is easy to see how different semantics can be packaged into it – simply provide different operators to represent different semantics. UML 2.0 provides the following operators:

• Alt
• Opt
• Par
• Loop
• Critical
• Neg
• Assert
• Strict
• Seq
• Ignore
• Consider

To be honest, I haven’t figured out the semantics of most of these operators but alt, par, opt and loop look pretty useful to me. I have already given an example of alt above.

Here is an example of par.

Combined Fragment – par, ref

Par stands for parallel (that’s right – parallelism inside a sequence diagram; counter-intuitive, but very useful).

This example depicts two interaction fragments that execute in parallel. The first one obtains eligibility summary and primary care physician information (one after the other), while at the same time the second one obtains year-to-date deductibles. By executing these in parallel the intention is to save precious cycle time. Why not get eligibility summary and PCP info too in parallel? Cannot be done because the eligibility summary contains information about who the primary care physician is! Only after you know that, you can proceed to get more details about that physician, right?

What are those boxed labeled ref? Park it aside for the time being; I’ll come to that in a moment.

Let us look at opt now. Opt stands for optional. It takes a single interaction fragment as its operand. If a specified condition is satisfied, then the operand interaction fragment is executed. Else nothing need be done. Simple.

Here is an example of opt:

Combined Fragment: opt

This example illustrates a step in a typical health insurance claim adjudication process.

In the absence of a well-accepted standard for claim submissions (while HIPPA 837 is a standard claim submission format, there are other non-standard formats still in use), many claims processing systems choose to use a canonical form of their own making within their claims processing systems.

With this background, now look at the opt box. When a Real Time Processing requests arrives at an enterprise service bus, the bus checks to see if it is a HIPPA 837 request. If so, it forward it to a HIPPA component for translation into the canonical form. If not, it assumes the message is already in canonical form and skips this step.

Like I said, simple.

Loop is the next one. (Unfortunately I do not have examples for opt and loop yet but I hope you got the drift of how these combined fragments work by now). Anywhere you need your sequence diagram to loop through a collection, you know what to use.

Let me now move on to the final sequence diagram refinement that I want to cover – reference. I will continue to use the same example I used for par.

We noted earlier that two interaction fragments execute in parallel. What goes on inside the interaction fragments? The boxes labeled ref indicate that these are references to other use case diagrams!

Instead of specifying complex sequences in this diagram, we separate out those sequences into separate diagrams. This sequence diagram only shows a reference to those diagram, at the right point in this sequence. If you are viewing this diagram inside a UML tool, clicking on the ref box will navigate you to a new sequence diagram.

This is a much needed improvement to sequence diagrams, which otherwise tend to become too unwieldy, extending on and on and on towards the right as the number of lifelines increase and end up becoming quite unreadable very soon. Now with the ref construct in place, it is up to the modeler to create multiple sequence diagrams and embed references appropriately, thus keeping each sequence diagram simple and clear.

Clearly, much has happened while you were sleeping and the tortoise has crept way ahead of you. Get going or you will be left behind!

Previous Next