TK2023 Object-Oriented Software Engineering

CHAPTER 6

SYSTEM SEQUENCE DIAGRAMS

INTRODUCTION

Before proceeding to a logical design of how a software application will work, it is useful to investigate and define its behaviour as a "black box".

System behaviour describes WHAT a system does without explaining how it does it.

Artifacts concerned with system behaviour: (Black-box) Use cases System sequence diagram System contracts

SYSTEM SEQUENCE DIAGRAMS An important part of understanding system

behaviour is the operations that an external actor requests of a system.

When an actor interacts with the system, it generates a system event. This initiates a system operation upon the system.

Consider the "Process Sale" use case.

ACTOR (CASHIER) SYSTEM

Enters item identifier Records sale line item and presents item description, price and running total

A system event is generated

System executes the corresponding system operation

A system sequence diagram (SSD) shows, for a particular scenario of a use case, the events that external actors generate, their order, and inter-system events.

In this diagram, all systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems.

EXAMPLE OF AN SSD

* [more items]

: System : Cashier

makeNewSale( )

enterItem(itemID, quantity)

endSale( )

makePayment(amount)

description, total

total with taxes

change due, receipt

This example is for the main success scenario of the "Process Sale" use case.

GUIDELINES ON SSDs

An SSD should be done for the main success scenario of the use case, and frequent or complex alternative scenarios.

SSDs can also be used to illustrate collaborations between systems. For example, between POS system and the external Payment Authorization Service System.

SSDs are derived from use cases. An SSD can be generated from inspection of a use case.

Actor Action (or Intention) System Responsibility

1. Customer arrives at a POS checkout with goods

2. Cashier starts a new sale

3. Cashier enters item identifier

Cashier repeats 3-4 until indicates done

6. Cashier tells Customer the total, and asks for payment.

7. Customer pays

8. Cashier enters payment

4. Records each sale line item and presents item description and running total.

5. System presents total with taxes calculated

9. Handles payment

Start the name of a system event with a verb such as add…, enter…, end…, make…, etc.

When naming a system event, choose a name that reflects the intent rather than in terms of the physical input medium or interface widget involved.For example,

enterItemis better than

scanItemfillItemIDTextField

It is sometimes desirable to show at least fragments of use case text for the scenario, to clarify or enhance the two views. The text provides details and context; the diagram visually summarizes the interaction.

1. Customer arrives at POS checkout with goods and/or services to purchase.

2, Cashier starts a new sale.

3. Cashier enters item identifier.4. System records sale line item and

presents item description, price, and running total. Price calculated from a set of price rules.

Cashier repeats steps 3 – 4 until indicates done.

5. System presents total with taxes calculated.

6. Cashier tells Customer the total, and asks for payment.

7. Customer pays and Cashier enters payment.

8. System handles payment.…

: System : Cashier

makeNewSale( )

enterItem(itemID, quantity)

endSale( )

makePayment(amount)

description, total

total with taxes

change due, receipt

send message

return data

SSDs WITHIN THE UP

SSDs are part of the Use-Case model. Most SSDs are created during the

Elaboration phase. It is not necessary to create SSDs for all

scenarios of all use cases. Create them only for some chosen scenarios of the current iteration.