1. Sequence Diagrams

2. Sequence Diagrams Related Terms: Interaction Diagrams
Event Trace Diagram
Scenarios
Message Diagram

3. Scenarios
A scenario is a sequence of events that occurs during one particular execution of a system.
A scenario can include all events in the system or can only include these events that are generated by a certain object in that system.
A scenario can be a historical record of executing or simulating the execution of a system or an object.

4. Example: Scenario for a Phone Line
Caller lifts receiver
dial tone begins
caller dials digit (5)
dial tone ends
caller dials digit (1)
caller dials digit (2)
caller dials digit (3)
caller dials digit (4)
called phone begins ringing
ringing tone appears in calling phone
called party answers
called phone stop ringing
ringing tone disappears in calling phone
phones are connected
called party hangs up
phones are disconnected
caller hangs up

5. Event Trace Diagram
Each event transmits information from one object to another.
Example:
dial tone begins event transmits a signal from the phone line to the caller.
In Event Trace:
Identify sender and receiver objects of each event.
Event Trace Diagram (ETD) shows the sequence of events and the object exchanging these events.
ETD shows object as a vertical line and each event as a horizontal line from the sender to the receiver.

6. Event Trace Diagram for a Phone Call
Caller
Phone line
Callee
caller lifts receiver
dial tone begins
dials (5)
dial tone ends
dials (5)
dials (5)
dials (1)
dials (2)
dials (3)
dials (4)
ringing tone
phone rings
answers phone
tone stop
ringing stops
phone connected
phone connected
callee hangs up
connection broken
connection broken

7. Sequence Diagrams Definition:
A sequence shows a series of messages exchanged by
A selected set of objects in temporally limited situation,
With emphasis on the chronological course of events.
Objects are shown by vertical lifelines. This highlights
The chronological sequence of the message.
Time runs from top to bottom.

8. Scenarios Stories about how the business works
Typical sequences that happen, and variations on the basics
Usually structured with numbered steps and calls to sub-sequences
Can be illustrated with sequence charts
Scales --- level of detail of the steps:
Daily scale --- "my pay was credited to my account yesterday, so I went to get some cash today"
Detail scale --- "to get money from your account, you insert your card into a cash machine, select 'cash', …"
Grand scale --- "A good way of making money is to run a bank. Provide accounts with higher rates of interest in exchange for less accessibility. They should be able to get cash from the most accessible accounts at any time of day or night."
Choose the level you're working at
It’s important to keep to a consistent scale within a particular scenario.
Part of the art of the analyst is to stand back from the detail. Programmers are always tempted to dive down into the depths – resist!

9. Sequence charts for scenarios
Helps:
identify the different participants and their interactions
show the sequence of events
Each event can be expanded to more detailed sequences
and each object to more detailed objects
Payday
get cash
ibm:Employer
lourdes:Bank
jo:Employee
jo:Customer
:CashMachine
lourdes:Bank
The sequence diagrams are primarily intended to show function calls between objects in an OO program; but they can also be used to show interactions in business. The main difficulties are that sometimes (a) it can be hard to decide who’s initiating the interaction; (b) there may be more than two equal interactors. In these cases, the direction of the arrow is a bit arbitrary; you can show third and fourth objects as parameters of the action – just like function calls have parameters. So for example, the amount of pay, cash, etc.
(The horizontal bars in these diagrams are instances of use-cases (“actions”); the vertical bars are instances of objects.)
Each interaction (in the real world) can be shown in more detail – every interaction takes some time and consists of smaller interactions; it’s just a question of whether you bother to investigate them.
Each object (in the real world) can be shown in more detail – every object has some constituent parts (unless we’re talking subatomic physics). Again, it’s just a question of whether we like to show them. The interactions you show with the aggregate object are the sum of the interactions with its constituents.
Once you’ve got the idea that you can look at each action in more detail if you want to, you can also stand back from the detail and say “we’ll do that later”.
Corresponding partial type diagram if interested:
insert card
pay
req cash
payslip
req details
get cash
cash
get cash
jo:Customer
:Card Reader
:Dispenser
:Keyboard
insert card
req cash
Employee
Get cash
Bank
Insert card
Req cash
cash
Cash Machine
Keyboard
Card reader

10. Using Scenarios Stories illustrated by sequence diagrams
Payday
ibm:Employer
lourdes:Bank
jo:Employee
IBM transfers money
to Jo's account at her Bank
pay
The proper way to draw sequence diagrams is with a story alongside.
In fact, the story is really the main thing: the sequence diagram just helps show who’s doing what.
Some of the UML tools (eg Rose) permit a story to be written like this with a sequence diagram, and will rearrange the steps of the story and the actions in the sequence diagram at the same time.
IBM notifies Jo that she
has been paid
payslip
get cash
Jo can now collect cash from her Bank.

11. Benefits of scenarios Enable dialogue with non-technical users
Initial exploration of the domain

12. Try it … Write some scenarios for a Library
No software, just the people and things
Write a scenario (or two) to show what happens when Jo wants to borrow “Trainspotting”, but Pat and Chris already have the only copies. How does Jo eventually get to read it?
Notice that a sequence diagram’s vertical bars are objects, not types — you can have more than one object of the same type
This should reveal the need for reservations.
Jo:Member
:Library
Pat:Member
Search for Trainspotting :– no luck
Jo attempts unsuccessfully to find Trainspotting. Jo reserves Trainspotting (Lib confirms it will be available.)
Another Member returns a copy.
The Library keeps this copy for Jo, (rather than returning it to shelf), and notifies Jo.
Jo comes to collect the kept copy, within a standard period.
reserve Trainspotting
Return a copy of Trainspotting
Notify available
Collect held copy of Trainspotting

13. Technique: Spot nouns Nouns –> candidate types
Elephant, Airplane, Meeting, Flight
Questions you could ask at any one moment –> associations and attributes
fred is an Elephant
What colour is fred? What Airplane does fred own? What Meetings is fred chairing this month? What meetings is fred attending this month?
m42 is a Meeting
Who is chairing m42 ? Where will m42 be held? When will m42 take place?
Verbs –> use-cases
But usually prefer to do them on a separate diagram
Fred flies to Athens; m42 is held by fred & the board;
Some of them turn into objects – fred meets jo –> meeting

14. Technique: Scenarios -> snapshots
Snapshots can be used to exercise scenarios
Scenario = a story about a series of occurrences
For each step in the scenario, modify the snapshot
ensure there is a way you can record all the relevant information in the associations and attributes
ensure that all information relevant to enquiries is represented in the associations and attributes
Update the type model to reflect improvements you made while going through the scenario

15. Process: writing scenarios
Ask users for typical stories about tasks in the domain
Envision with snapshots, cartoons, screen shots, play-acting
"rich pictures"
MegaBank
Each of Jo's cards identifies an Account.
123:DAccount
jo:Customer
Jo wants money from her current account.
345:CAccount
FastBuck
Any technique you can use to bring the scenarios to life and ensure they cover the relevant details.
“Rich pictures” are sort of cartoons combined with snapshots.
welcome
She inserts the card in an ATM. This associates the
ATM to her current account.
Any further operations at the machine are recorded against her current account.
£20: Debit
date=17/5/99

16. How UML is used – software specification
Showing which activities the software supports
Sometimes also useful to note those it doesn’t support
use-case diagram with system boundary
Room Management System
check in
We’ve looked at business modelling to some extent. Let’s take a look at some ways in which UML is used to define software.
We’ll introduce a few extra parts of the UML notation as we go through.
This is a small addition to the basic idea of a use-case diagram, in which we introduce a system boundary to say what parts of the problem the system deals with.
Of course, there might be a separate chunk of software to support payment.
check out
Receptionist
Person
pay bill
 uml-c-p77

17. Scenario with sequence diagram
Interactions between actors:This is a form of instance diagram: it just shows one example of what could occur
Used to work out use-case implementation at high level
No internal details of system
Sequence diagram
use-case check in
jo : Person
chris: Receptionist
rms: Room Manager System
Person arrives at desk, gives name.
R gets map of available Rooms, chooses one.
R enters Person’s details on Room Management system against chosen room.
R gives key to Person.
arrive
get room map
choose room
get details
The scenario the the left is part of the notation.
The tools (e.g. Rose) allow you to move the steps around by grabbing and moving the corresponding horizontal arrows.
Notice that the Room Management System is one of the actors.
This is an instance diagram: the vertical bars are instances of objects; the horizontal bars are occurrences of use-cases.
person details
time
confirm room assignment
key

18. Try it ...
Make a system boundary diagram for a system to support a library
Create two scenarios for people checking a book out of a library, and another for returning a book
List the operations the system is required to do
Write the dictionary descriptions for the operations
At this stage, you may be short on time. If so, do it as a class exercise with you leading – you drawing on flipchart, or one of them if there’s a particularly clued-up one. The rest tell you what to draw, and answer your questions.
If you prefer, you can do the first part immediately after the slide on system boundaries: “so what would a system boundary diagram for a library management system look like?” Ask for examples of use-cases that the system might not deal with – or that a different system might deal with: eg stock management, members’ accounts (for any membership fees, fines, etc), reservations, paying staff.
The different scenarios for checking a book out should deal with simple case – check one book out, normal outcome; and a more complex case – check two books out at the same time; other scenarios might include denial because the member owes fines or something. Interesting to see who decides – the librarian or the system.
E.g.:
jo:Member
chris: Librarian
: Loan Management System
hand over member card
system will assume next operations are about jo
scan member card
display member details
(including fines owed etc)
system will assume next operations are about loans
hand over books
set to loan mode
scan book
system records book1 on loan to jo
scan book
hand back books & card ok
system records book2 on loan to jo
Loan Management System
scan member card
set mode (loan | return)
scan book

19. Object oriented or component based design
Designs consist of interacting parts
each containing interacting parts ...
Design is about dividing up the task between the parts
This is not a UML diagram: it’s just to illustrate the general idea that the typical system design consists of a number of different components, each of which do some part of the job. At the largest scale, the parts might operate in different machines: e.g the accounts subsystem, the dispatching subsystem, the sales subsystem. Then within those there can be smaller components: a user interface, business logic, a database. In an object oriented design, each of these will be composed of interacting objects.
Each component or object has its own data and performs a number of operations.
This is rather like the way in which work is divided up between departments and people in a business: the company as a whole has a job to do; the job gets done by the collaboration of several departments, which interact in various ways and each have their own jobs to do. Within each department, there are people with different responsibilities, each with their own tasks to do, and each with their own files to support them doing that.
Good design is about dividing the responsibilities in such a way that the responsibilities are clearly separated. A good design is easy to change.

20. Collaborating objects
Functions of software system are divided between objects
Each object performs those sub-tasks most relevant to it
Objects interact to achieve overall system goals
‘Sending messages’ = invoking functions
Objects have to send each other messages to ask for other parts of the job to be done
A good OO design partitions the tasks cleanly, so that no object does work that should properly be done by another
decoupling ®
flexible, easily changeable software
separable, generic components that can be assembled in many ways to make many end products
Bad design results in poor decoupling ® no OO benefits
Motivation for learning to decouple properly.

21. Distribution of tasks: issues
Applying for a job
thinks: I need a job
10 (later)
thinks: I need a widgetgrinder 1
chris.acceptApplication
(myApplication)
The purpose of this is to discuss one of the main topics in object oriented design: separation of concerns.
Remark that OO is a style of programming developed from simulation (Simula was the first OO prog lang). Writing a good OOP is often like organising a human business: the whole system has some objectives, and these are achieved by dividing up the job between different people - each of whom have their own filing cabinets (data) and jobs they do; and there is a protocol of messages between them whereby they collaborate to achieve the overall goals.
Distributing the responsibitilities well resuls in a good flexible business or program. It's an issue we have to deal with in OOP, that traditional programming doesn't lay so much emphasis on: so in this introductory chapter, it's worth spending some time discussing it.
Introduce the scenario: Jo is looking for a job, creates a job application, and sends it to Chris, a secretary in a company. Chris puts the job-application into a tray. (Q: what's a tray like in software terms? A: a stack or list or queue.)
Q: If this were software, what name might we give to message 2 ? "storeJobApplication"?
A: No! We might want to use the tray for other purposes --- it would be daft to design a tray specifically for holding job applications. More likely, it will hold any A4 sheets of paper, so we should avoid any mention of job applications in the naming of it.
--> Lesson: OOPers never design narrowly for the program they're currently working on.
Q2: Now let's suppose Pat wants to look at some of the recent job-applications. There are at least two places s/he could send a message. What are they, and what are their relative benefits?
A: (a) intray.get( ) --- fast. (b) chris.getApplication( ) --- more flexible.
Suppose we changed the way we store job-applications: e.g. two trays, one for people with nice handwriting. How many other classes would need reprogrammed unders schemes (a) and (b)?
-->Lesson: we should reduce the number of dependencies we allow between objects. Make arrangement of application storage the Secretary's responsibility, not a joint one. OOP lays emphasis on being clear about each object's responsibilities, and a 1-1 map between behavioural features and object classes.
jo: Person
chris: Secretary
pat: Manager 2
: Application
intray: WorkTray

22. Distribution of tasks: issues
Appropriate distribution of responsibilities ®
changes have more restricted impact
objects can be reused elsewhere
benefit of this scheme:
thinks: I need a job
10 (later)
thinks: I need a widgetgrinder 1
chris.acceptApplication
(joApplic)
11 chris.nextApplicn()
jo: Person
chris: Secretary
pat: Manager
12 intray.get()
2 intray.put(joApplic)
11 intray.get()
joApplic: Application
intray: WorkTray
benefit of this scheme:

23. UML collaboration diagrams
Messages shown atop instance diagrams
associations: references stored within one object linking to another
could be: pointers in memory, database keys, URLs, ...
messages: invocations of a function from one object to another
could be: function calls, database queries, http (web page) requests, …
These diagrams don't show the precise nature of the implementation
2 needWidgetgrinder( )
“*” = repeated with other receiver instances
1 needJob( )
1.2 *
acceptApplication
(joApplic)
2.1 nextApplicn( )
jo: Person
chris: Secretary
pat: Manager
boss
association
1.2.1 put(joApplic)
message
2.1.1 get()
1.1 new
1 intray
2.1 intray.get()
instance creation
intray: WorkTray
joApplic: Application

24. UML Sequence diagrams Different view of collaborations
Tools translate directly between the two syntaxes
Good for showing assignment of responsibility
not so good at associations
also weak at control flow variations
jo: Person
chris: Secretary
intray: WorkTray
pat: Manager
1 needJob( )
instance creation
General weaknesses with both sequence and collaboration diagrams:
They are instance diagrams, and therefore it’s difficult to show variations in behaviour.
They give an overall view and therefore discourage decoupling (in which the general objective is that the design of each object should be independent of the designs of the others).
However, they are useful to understand the control flow initially, and often we design using a diagram like this and then apply decoupling patterns as necessary afterwards.
1.1 new
joApplic: Application
repeated
1.2 *
acceptApplication
(joApplic)
1.2.1 put(joApplic)
message
stores joApplic
2 needWidgetgrinder( )
2.1 nextApplicn( )
2.1.1 get()
optional
return joApplic