Software Engineering – (System) Sequence Diagrams

Now it times to learn all about how to create a (System) Sequence Diagram (SSD).

Note: not to be confused with State Diagrams, hehe ;)

Their Purpose

A SSD’s main purpose is to represent the interactions among objects within a system via the usage of messages. (below)

 

The components

System Sequence Diagrams only have 2 objects, that is:

1. An actor on the system (such as a user, driver or the controller)

2. The system itself.

Lost in translation

One System Sequence Diagram translates to one use case. Because of this, the one actor that is contained within an SSD is from the related use case scenario. The actor must be the system operator, and the system is the system under analysis or development.

Furthermore, SSD’s come straight, or mainly, from the use cases description. Such as ‘participating actors’ and ‘primary flow of events’.

Let’s take an example use case:

 

 

Here we have 3 use cases: Process Sale, Handle Returns and Cash In.

With these, we must now create the use case descriptions – but i’m not going to go into all that much detail here. Let us say for now that we only have the use case process sale. Here is the use case description for that use case:

1. Customer arrives at a checkout

2. Cashier starts a new sale ( makeNewSale() )

3. Cashier enters item ID ( enterItem(itemID, quantity) )

4. System presents total amount with taxes calculated ( Description, total and totalWIthTaxes() )

5. Cashier tells customer the total and asks for payment (acknowledgements)
   ( endSale() )

6. Customer pays up and the system handles payment ( makePayment() and  Change / Receipt )

The main actor here is the cahier, mainly also because they are the only ones that can use the “handle payment” use case. So the SSD would be as follows;

 

 

Note: the text labelling each arrow is the message that was mentioned above ;)

 

So, what exactly is the relationship between a use case and an SSD?

Well, returning to old, but hopefully well known facts – a use case may show one or more (more commonly more…) use case scenarios.

An SSD shows external system events for one use case scenario. These external system events commonly come from the use case descriptions primary flow of events for that use case scenario that the SSD is based on.