Sequence Diagrams

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 • 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 • Caller lifts receiver • dial tone begins • caller dials digit (5) • dial tone ends • caller dials digit (5) • caller dials digit (5) • caller dials digit (1) • caller dials digit (2) • caller dials digit (3) • caller dials digit (4)

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 Callee Phone line caller lifts receiver dial tone begins dials (5) dial tone ends dials (5) dials (5) dials (1) dials (2) dials (3) dials (4) phone rings ringing tone 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

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 jo:Employee jo:Customer :CashMachine lourdes:Bank lourdes:Bank ibm:Employer insert card pay req cash payslip req details get cash cash get cash jo:Customer :Card Reader :Dispenser :Keyboard insert card req cash

10. Using Scenarios • Stories illustrated by sequence diagrams Payday jo:Employee lourdes:Bank ibm:Employer IBM transfers money to Jo's account at her Bank pay IBM notifies Jo that she has been paid payslip get cash Jo can now collect cashfrom 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

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'scards identifiesan Account. 123:DAccount jo:Customer 345:CAccount Jo wants moneyfrom her currentaccount. FastBuck welcome She inserts thecard in an ATM.This associates the ATM to her current account. Any further operations at themachine are recorded against her current account. £20: Debit date=17/5/99

16. How UML is used – software specification use-case diagram with system boundary • Showing which activities the software supports • Sometimes also useful to note those it doesn’t support Room Management System check in check out Receptionist Person pay bill  uml-c-p77

17. Scenario with sequence diagram 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 jo : Person chris: Receptionist rms: Room Manager System use-case check in 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 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

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

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

21. Distribution of tasks: issues • Applying for a job 0 thinks: I need a job 10 (later) thinks: I need a widgetgrinder 1 chris.acceptApplication (myApplication) chris: Secretary pat: Manager jo: Person 2 : Application intray: WorkTray

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

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( ) 2.1 nextApplicn( ) 1.2 * acceptApplication (joApplic) jo: Person chris: Secretary pat: Manager boss 1.2.1 put(joApplic) association 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 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