Sequence Diagrams Mr B S Tarle Interaction diagrams

Sequence Diagrams Mr. B. S. Tarle

Interaction diagrams • There are 3 types of Interaction diagrams; – Sequence diagrams, – communication diagrams, and – timing diagrams. • These diagrams are used to illustrate interactions between parts within a system. • Among the three, sequence diagrams are preferred by both developers and readers alike for their simplicity. Sequence Diagrams 2

Interaction Diagrams • A series of diagrams describing the dynamic behavior of an object-oriented system. – A set of messages exchanged among a set of objects within a context to accomplish a purpose. • Often used to model the way a use case is realized through a sequence of messages between objects. Sequence Diagrams 3

Interaction Diagrams (Cont. ) • The purpose of Interaction diagrams is to: – Model interactions between objects – Assist in understanding how a system (a use case) actually works – Verify that a use case description can be supported by the existing classes – Identify responsibilities/operations and assign them to classes Sequence Diagrams 4

What is a Sequence Diagram? • Sequence diagrams, commonly used by developers, model the interactions between objects in a single use case. • They illustrate how the different parts of a system interact with each other to carry out a function, and the order in which the interactions occur when a particular use case is executed. • In simpler words, a sequence diagram shows different parts of a system work in a ‘sequence’ to get something done. Sequence Diagrams 5

Sequence Diagrams • Demonstrates how objects interacts with each other. • Give emphasis to time ordering of messages. • Can model simple sequential flow, branching, iteration, recursion and concurrency. Sequence Diagrams 6

A Sequence Diagram member: Library. Member book: Book Copy borrow(book) ok = may. Borrow() [ok] borrow(member) set. Taken(member) Sequence Diagrams 7

A Sequence Diagram X-Axis (objects) member: Library. Member : Book Copy book: Book Object borrow(book) Y-Axis (time) Life Line ok = may. Borrow() message [ok] borrow(member) set. Taken(member) Activation box/focus of control condition Sequence Diagrams 8

Object • Object naming: – syntax: [instance. Name][: class. Name] – Name classes consistently with your class diagram (same classes). – Include instance names when objects are referred to in messages or when several objects of the same type exist in the diagram. my. Birthdy : Date • The Life-Line represents the object’s life during the interaction Sequence Diagrams 9

Messages • An interaction between two objects is performed as a message sent from one object to another (simple operation call, Signaling, RPC) • If object obj 1 sends a message to another object obj 2 some link must exist between those two objects (dependency, same objects) Sequence Diagrams 10

Messages (Cont. ) • A message is represented by an arrow between the life lines of two objects. – Self calls are also allowed – The time required by the receiver object to process the message is denoted by an activation-box. • A message is labeled at minimum with the message name. – Arguments and control information (conditions, iteration) may be included. Sequence Diagrams 11

Return Values • Optionally indicated using a dashed arrow with a label indicating the return value. – Don’t model a return value when it is obvious what is being returned, e. g. get. Total() – Model a return value only when you need to refer to it elsewhere, e. g. as a parameter passed in another message. – Prefer modeling return values as part of a method invocation, e. g. ok = is. Valid() Sequence Diagrams 12

Synchronous Messages • Nested flow of control, typically implemented as an operation call. – The routine that handles the message is completed before the caller resumes execution. : A : B do. You. Understand() Caller Blocked yes Sequence Diagrams return (optional) 13

Object Creation • An object may create another object via a <<create>> message. Preferred : A : B : A <<create>> : B Constructor Sequence Diagrams 14

Object Destruction • An object may destroy another object via a <<destroy>> message. – An object may destroy itself. – Avoid modeling object destruction unless memory management is critical. : A : B <<destroy>> Sequence Diagrams 15

Control information • Condition – syntax: ‘[‘ expression ’]’ message-label – The message is sent only if the condition is true – example: [ok] borrow(member) • Iteration – syntax: * [ ‘[‘ expression ‘]’ ] message-label – The message is sent many times to possibly multiple receiver objects. Sequence Diagrams 16

Control Information (Cont. ) • Iteration examples: : Compound. Shape draw() *draw() : Shape : Driver : Bus *[until full] insert() The syntax of expressions is not a standard Sequence Diagrams 17

Control Information (Cont. ) • The control mechanisms of sequence diagrams suffice only for modeling simple alternatives. – Consider drawing several diagrams for modeling complex scenarios. – Don’t use sequence diagrams for detailed modeling of algorithms (this is better done using activity diagrams, pseudo-code or state-charts). Sequence Diagrams 18

Example 1 : Violations Dialog : Violations Controller : Violations DBProxy Clerk lookup view. Button() Lookup Traffic Violation id=get. ID() get. Violation(id) May be a pseudomethod display(v) v Sequence Diagrams <<create>> v: Traffic Violation DB is queried and the result is returned as an object 19

Example 2 Active object : Print. Server Printing A Document : Queue : Printer Proxy Client print(doc, client) Repeated forever with 1 min interludes [job] done(status) enqueue(job) job=dequeue() [job]print(job. doc) status Sequence Diagrams 20

Sequence Diagrams 21

Sequence Diagram Common Mistakes • When drawing sequence diagrams, designers tend to make these common mistakes. By avoiding these mistakes you can ensure the quality of your diagram. • Adding too much detail. This clutters up the diagram and makes it difficult to read. • Obsolete and out of date sequence diagrams that are irrelevant when compared to the interfaces, actual architectures etc. of the system. Don’t forget to replace them or modify them. • Leaving no blank space between the use case text and the message arrow; this makes it difficult for anyone to read the diagram. • Not considering the origins of message arrows carefully Sequence Diagrams 22

Sequence Diagram of an Online Exam System Sequence Diagrams 23

Sequence Diagram Example of a School Management System Sequence Diagrams 24

Example of an Option Combination Fragment Sequence Diagrams 25

Example of a Loop Sequence Diagrams 26