Sequence Diagrams

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

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.

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

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.

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

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.

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!

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

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.

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

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

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

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

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

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

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

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

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.

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.

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

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:

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

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