How to draw sequence diagram for multiple-stages use case?

Question

In current system, some functionalities/ use cases may need multiple stages to complete their whole procedure. Examples are like user registration which may contain two stages: inserting user record on database and email activation. Or for money transfer on netbank, it requires the stage of filling transfer information and of SMS verification before the actual transaction happens. I want to know how to draw sequence diagram for such kind of functionalities/ use cases.

To be more specific, I have drawn a sequence diagram for the user registration example using MVC pattern, which is shown on the bottom. On this diagram, the two stages is divided by the red line. Also I skip the logic that handles failures or exceptions like invalid input or username already existing in the database to make it simpler. It seems that there are so many objects involved in this diagram, should I draw a sequence diagram this way? Or using 2 sequence diagram for each stage is better?

Answer 1

Generally speaking the smaller diagram, the better. If you are doing it for documentation / informing purpose then clarity should be your priority.

a) breaking it up

In your particular example, breaking it into (at least) two sequence diagrams would be a good option, as both those activities are usually performed at different times.

The way you could look at this is:

• first diagram takes as an input unregistered user and produces a unverified user
• second diagram takes as an input unverified user and produces a verified user

That way you wouldn't need to worry about connecting the two diagrams as they are really not that dependent.

b) using interaction overview

That being said, UML has interaction overview diagrams (http://www.uml-diagrams.org/interaction-overview-diagrams.html), that allow you sow together various diagrams, so you could split it into two, and then just connect them differently. Or you could use state machine diagram to track the mutation of the user — the UML vocabularly is rather large, so no need to limit yourself just to one type.