Sequence Diagrams

Sequence Diagrams

Agenda Interaction Diagrams A First Look at Sequence Diagrams Objects Messages Control Information Examples 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

Interaction Diagrams (Cont.) UML – Collaboration Diagrams Emphasizes structural relations between objects – Sequence Diagram The subject of this tutorial Sequence Diagrams 5

A First Look at Sequence Diagrams Illustrates how objects interacts with each other. Emphasizes time ordering of messages. Can model simple sequential flow, branching, iteration, recursion and concurrency. Sequence Diagrams 6

A Sequence Diagram member: LibraryMember book:Book :Book Copy borrow(book) ok mayBorrow() [ok] borrow(member) setTaken(member) Sequence Diagrams 7

A Sequence Diagram X-Axis (objects) member: LibraryMember :Book Copy book:Book borrow(book) Y-Axis (time) Life Line ok mayBorrow() message [ok] borrow(member) setTaken(member) Object Activation box condition Sequence Diagrams 8

Object Object naming: – syntax: [instanceName][:className] – 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. myBirthdy :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 obj1 sends a message to another object obj2 some link must exist between those two 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. getTotal() – Prefer modeling return values as part of a method invocation, e.g. ok isValid() – Model a return value when you need to refer to it elsewhere, e.g. as a parameter passed in another message. 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 doYouUnderstand() 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 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 [ok] borrow(member) – example: Iteration – syntax: * [ ‘[‘ expression ‘]’ ] message-label – The message is sent many times to possibly multiple receiver objects. Sequence Diagrams 16

Control Information (Cont.) Iteration examples: :CompoundShape 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 statecharts). Sequence Diagrams 18

Example 1 :Violations Dialog :Violations Controller :Violations DBProxy Clerk lookup viewButton() Lookup Traffic Violation id getID() getViolation(id) display(v) v Sequence Diagrams create v:Traffic Violation DB is queried and the result is returned as an object 19

Example 2 - Observer Pattern ? : ConcreteSubject ob1 : ConcreterObserver ob2 : ConcreterObserver notify( ) update( ) getState( ) for each observer update( ) getState( ) Sequence Diagrams 20

Printing A Document Example 3 Active object :PrintServer :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 21