Having trouble understanding sequence diagrams

Question

I've been looking the past few days at several UML tutorials, but I'm having a hard time understanding UML sequence diagrams. From a quick glance and run through the guides it all appears to be fairly straightforward, but when I view the provided examples it kind of gets confusing real quick.

I'm currently trying to prepare the sequence diagram for my PHP website system which has functions such as login, register and private messaging. Each of these are essentially use cases which means each one requires its own sequence diagram, correct? Or are sequence diagrams supposed to show the entire system in one diagram? A lot of the examples I find appear to cover the whole system in one shot, though with so many functions I don't know how that can be done in one diagram.

I've prepared 2 simple ones so far of the login and registration:

Use case 1

Use case 2

Answer 1

Each UML diagram puts an emphasis on a system aspect (in content and form) and abstract other aspects away. You should learn this, in order to decide which diagram to use in which situation, how many of them and how. A great, creative part of system modelling.

In case of sequence diagram, it is a behavior diagram, that shows concrete, straightforward scenarios putting emphasis on the collaborating objects and messages they exchange during the implementation of a scenario.

Although a sequence can show the conditional flow and decision (like in your example, user and pass check) it is not its strength, since is breaking its natural straight time line of events.

So, each use case would theoretically have several sequence diagrams, one for each scenario. However, you should think well if it makes sense do make each sequence, because most of them are trivial. You should concentrate on meaningful scenarios, somehow interesting, that bring value to somebody.

At the end, I would suggest you to also see activity diagram, as it is nicely complementary to sequences. Also behavior, but focused on the sequence of tasks, decisions (a weak point of sequence), paralel tasks, responsabilities and data flows.

One activity can cover several sequences, from another point of view. These are much more clear to non-technical people (customers, users), while sequence is of more use to developers, architects, etc.

Mostly, the combination of several diagrams gives the best results. Sequences naturally need a structural "companion" to define the objects that participate in the scenario: components, domain classes, or similar.

Answer 2

Sequence diagrams are meant to communicate how something works to other people, so the priority should be making them easy to understand. In systems with user interaction you can have a sequence diagram to explain a complex use case. A diagram for the whole system doesn't make much sense because the flow depends completely on what the user does. For brevity you can describe two related use cases together if it's clear where one ends and the other one starts, for example register, login, and logout. If a system doesn't have user interaction it's possible to describe how it works in general with a single sequence diagram.