1. Introduction to Sequence Diagrams

2. The Vision SSM Models Databases Use Cases Programs Activity Models
Object
Models
Dynamic Models
Computing
Business

3. Beginnings of a Method
Soft Systems Model

4. Systems Activities
The systems functionality is represented as a number of Use Cases
The functionality of each use case will be realised through objects collaborating with each other
Collaboration is achieved through message passing

5. Message Connections The arrow indicates that:
The sender sends a message
The receiver receives the message
The receiver takes some action, returning the result to the sender

6. Message Connections
The message must activate an operation in the receiving object

7. Message Connections
There are two ways of knowing which object to send a
message to:
(1) An association exists between sender and receiver in the object model
(2) The receiver’s object id is passed as part of the message (i.e. as a parameter)

8. Message Connections
Sequence Diagrams allow us to describe object communication associated with a specific use case
Can be used:
during analysis to help define an object's responsibilities
as documentation for the final implemented software

9. Example Object Model

10. Sequence Diagram for Placing an Order

11. Placing an Order
A message is sent to the order class to create a new “order”
Customer No., Stock items and Quantities are passed as parameters
Customer details are retrieved from the appropriate customer object
For each stock item an order line object is created
Details are extracted from the stock item object

12. Another Example - A Library
We have identified three objects: Borrower, Book and Librarian and
the following relationship:
0..1
Borrower
Book n

13. Library Example Issuing a Loan
Triggered by a request from a Borrower for
the loan of a Book.
Before issuing the loan we need to check:

14. Library Example 1) The borrower has no overdue fines
2) The borrower has not already reached the maximum number of loans that they are allowed.
3) None of the borrower’s current loans are overdue

15. Issue Loan - Sequence Diag.

16. Library Example Borrower Book Fines Owing Borrower No.
Our object model must be consistent with the
interaction diagram
Borrower
Book
0..1
Fines Owing
Borrower No.
Max. No. of Loans
Date Due n
Add Book to Loan List
Check if overdue
Check Loan Status
Issue to Borrower
Librarian
Issue Loan

17. Library Example Each of the operations in our model needs to
be documented with pseudocode
e.g.
Borrower::Add Book to Loan List
Receives a book id and then adds this to the collection of books linked to borrower

18. An Example Program

19. Another Student

20. The Underlying Database

21. The Program that uses the Database

22. The Class Diagram

23. Get Group Student Numbers
Get Student Number

24. Get Module Results
Get Student Marks

25. Three Tiers

26. Exercise
Each Instructor has a name, address and telephone number and is qualified to present one or more courses.
We store the date when the instructor became qualified to teach the course
A course has at least one instructor qualified to teach it but it may have many 
Each course has a number, title and a date of next revision
Each course will have several scheduled presentations
Details of the date, duration and location are recorded for each presentation
Each presentation will be given by only one instructor but one instructor may give many presentations

27. The “Reschedule Presentation” use case
Sometimes a presentation needs to be rescheduled when this happens the availability of the existing instructor needs to be checked. If they are available they are assigned to the presentation on the new date. If not we need to release the current instructor, find all other qualified instructors and check their availability to identify a replacement.

28. Use Case – Reschedule Presentation Initial Class Diagram1
0..n 1 1
1..n
1..n 1

29. After much discussion…

31. Developing Sequence Diagrams
Identify the relevant objects involved in the computation
Establish the role of each object
Identify the controller
Identify the collaborators
Decide on the messages between objects

32. Sequence diagram notation
Actors
:Object 1
:Object 2
Objects

33. Sequence diagram notation
:Object 1
:Object 2
Lifelines
Identify the existence of the object over time.

34. Sequence diagram notation
:Object 1
:Object 2
Activations
Indicate when an object is performing an action

35. Sequence diagram notation
:Object 1
:Object 2
message
Messages
Indicate the communications between objects

36. Sequence diagram notation
:Object 1
:Object 2
message
message
Sequence
Vertical position signifies sequence – earlier messages appear nearer the top.

37. Sequence Diagram Tracks a sequence of events in a scenario
Identifies all objects involved
Objects O1 O2 O3 O4 O5
indicates
that the
event
effects the
object
Events E1 E2 E3 E4

38. Sequence modelling
For each event, ask “what objects does this involve?”
Used to identify new classes
Determines how classes interact

39. Use case elaboration
We define use cases as sequences - primary and alternative paths
Now we take sample sequences and build sequence diagrams
This gives us the objects
And it gives us the relationships
And it gives us the operations

40. Invoicing use case (1)

41. Invoicing use case (2)

42. The Primary Path
The following sequence is carried out for every customer on the sales ledger who has not been billed in the last month:
Get sales items from the sales ledger.
Get customer details from the customer file, covering billing address details.
Get any credits that the customer has.
Get discount details for customer.
Print the invoice header
Print the line items on the invoice
Calculate any discounts
Apply any credits
Calculate and print the invoice total
Calculate and print the VAT
Mark items on sales ledger as invoiced

43. Now we can realise the use case
Elaborate the scenario with sequence diagrams
Find objects
Add operations to objects
Add attributes to objects

44. Sequence diagram for Print Invoice use case
In recent years many OO gurus have suggested that we should introduce a control class for each Use Case.
The control class drives the processing.
: Print Invoice
For interactive use cases there is usually a boundary class too.
We can put this object in a class diagram

45. Print Invoice - class diagram
From our sequence diagram, we find our first object!
Print Invoice

46. And then we need a recipient of the message.
: Print Invoice
: Customer
Record
Get Customer Name
Now we implement the first step of the scenario by getting the Print Invoice control class to send a message.
And then we need a recipient of the message.
So we have found another object

47. Print Invoice - class diagram
Customer Record
We can see that as the objects communicate we need a relationship between them.

48. Moving on to the next step of the scenario
: Print Invoice
: Customer
Record
: Invoice
Get Customer Name
Print Customer Name
Moving on to the next step of the scenario
We now have a third object!

49. Print Invoice - class diagram
Customer Record
Now we add in our third object
Invoice
And because the message comes from Print Invoice to Invoice, they need to be related

50. So we continue! : Print Invoice : Customer Record : Sales Items
Get Customer Name
Print Customer Name
Get Customer Address
Print Customer Address
Get Unbilled Invoicable Items
Print Invoice Lines
Print Total
Print Terms and Conditions
So we continue!

51. Print Invoice - class diagram
We need one more object
Print Invoice
Customer Record
Sales Items
Invoice
Which is related to Print Invoice

52. So what have we done? Worked through a Use Case scenario step by step
Introduced a controller object to drive things
Sent messages from one object to another
Found objects to deal with the messages
Put the objects and necessary relationships on a class diagram

53. What have we got left to do?
Find operations on objects to support the messages
Find attributes to support the objects

54. So we work through the messages and apply operations
: Print Invoice
: Customer
Record
: Sales Items
: Invoice
GetName( )
So we work through the messages and apply operations

55. Print Invoice - class diagram
And then we have an operation for our class diagram
Customer Record
Print Invoice
GetName()
Invoice
Sales Items

56. And so we continue : Print Invoice : Customer Record : Sales Items
GetName( )
PrintCustName( )
And so we continue

57. Print Invoice - class diagram
And we add the next operation to the class diagram
Customer Record
Print Invoice
GetName()
Invoice
Sales Items
PrintCustName()

58. And all the way through the sequence diagram
: Print Invoice
: Customer
Record
: Sales Items
: Invoice
GetName( )
PrintCustName( )
GetAddress( )
PrintCustAddress( )
GetUnbilledItems( )
PrintLines( )
PrintTotal( )
PrintTermsConditions( )
And all the way through the sequence diagram

59. Print Invoice - class diagram
We can put an operation on Print Invoice to implement this
And then add the other operations to the class diagram
Customer Record
Print Invoice
GetName()
Print()
GetAddress()
Invoice
Sales Items
PrintCustName()
getItems()
PrintCustAddress()
GetUnbilledItems()
PrintLines()
PrintTotal()
PrintTermsConditions()

60. A Simpler Example - Sending an email

61. interface

62. Working from a scenario
Sending an
1. Press “New ” icon
2. Enter person’s name in “To” section
3. Type subject
4. Type contents
5. Press Send button
6. System looks up address in address book
7. System submits the to the server

63. Starting the diagram
If this is an interactive scenario, we always have an actor driving it, so we put one on the sequence diagram

64. Add objects
The first interaction is with the icon bar, which we can treat as an object

65. The user talks to the icon bar
Add message
The user talks to the icon bar

66. Label the communication
Remember that actors can only communicate with interface objects such as screens, menus and icon bars.

67. The icon bar has some work to do.
It creates an page.
Now the user can see the page and use it.

68. The next three steps are filling in the details on the email page

69. The user then clicks Send

70. Now consider how to do the sending
We can choose to get the page to look up the address from an address book object

71. The arrow allows information to return
So we don’t need to put a return arrow with the address going back to the page

72. We can choose to get the email page to submit the email to the email server

73. And if we think carefully, the email page always closes after the send.

74. Now we go through and change the messages to operations on the object

75. And so on, all the way through

76. And now we have found our objects, and the operations on them
So we drag them onto a class diagram

77. The icon bar needs to communicate with the email page
We could use an arrowed relationship, but we generally don’t

78. Likewise the email page communicates with the address book
and server

79. Then we worry about multiplicity

80. Developing a Sequence Diagram
Work through a scenario step by step
Make actors communicate with screens, icons, menus
Make the screen actions (etc) trigger actions with objects
Convert the actions to operations

81. Class diagrams
Objects from the sequence diagram go on a class diagram.
Operations are added automatically by the CASE tool
(e.g. Together)
Examine the sequence diagram to see where the communication takes place.
Add relationships, and consider multiplicity.

82. Sequence Diagrams – why bother?
Tie use cases and object models together
Use the sequences in use cases
Identify objects
Identify relationships
Identify operations

83. Beginnings of a Method
Soft Systems Model