How to handle an exception thrown by an actor i.e. cancelOperation() in sequence diagram?

Question

I'm making a sequence diagram for some use cases of an interaction model for an online Book Store. In the use case sequence diagram, there's always the possibility of a user canceling the process that is occurring like on a normal site by logging out, by pressing cancel on an operation, or simply closing the browser or app. How do I model this in the sequence diagram? This is what I currently have:

I've tried putting in an alt fragment, but it would have to encompass the lifelines and I don't think its right because it depends on where the user executes cancel. I've thought of using break, but that assumes where the person is going to cancel. Since this applies to all use-cases I'm not sure how to model cancellation during execution of a process or use-case.

Answer 1

A SD focuses on a certain scenario in detail. That means it's not so meaningful for general cases. So your choice is to either have a note in a "general" SD or to create individual SDs to show behavior (e.g. for time-out, for cancel, for erroneous entry etc.)

Answer 2

The good: Non-exceptional outcomes

If there's a "cancel" button, it's legitimate to press it, and it's one of the expected outcomes, not an exception. And if you perform a check operation, there are two expected outcomes: successful and unsuccessful. Nothing to do with exceptions at first sight.

In this context, your current approach is very clear: a message is received, some actions are performed and then there are two possible outcomes, each with its own sequence of interactions.

Another approach is when a lot of things need to be performed and you perform a number of checks on the way, each may impede on the rest of the sequence. In this case the alt would end to be nested and repetitive and very difficult to read. In such a case, you can use, as you found out, a break. Break stop what's happening after the break bloc in an enclosing block. Use this technique if most of the time the flow continues but at some occasions, the journey ends there because of a polite decline by the user, or a negative outcome in a check. This avoids nesting a lot of alt boxes.

The bad: Exceptional outcomes

Excceptions are meant for truly exceptional circumstances that interrupt the flow of control. As strange as it may sound, exceptions can be modelled in UML as a *signal*. But in a sequence diagram, signals are represented exactly as operation calls. So despite exceptions, the SD would look closely to what you have. Including the need to use an alt or an opt fragment.

The ugly: visual programming

Now beyond the technical alternatives described above, you should question if this is the way to go. Indeed, sequence diagrams belong to the scenario-based modelling: the diagrams are well thought and intuitive to read for a specific case. If you start to misuse sequence diagram as a visual programming tool, modelling not a single scenario, but an algorithm as close as possible to the implementation, you'll quickly have an unreadable diagram that nobody will use. Programming is best done in programming languages.