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.