Ooad sequence diagram lecture


Published on

Object Oriented programming and advanced software engineering.
For more docs visit

Published in: Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Ooad sequence diagram lecture

  1. 1. OOADSequence Diagrams
  2. 2. Interaction Diagrams Interaction diagrams describe exemplary how groups of objects collaborate in some behavior. An interaction diagram typically captures the behavior of a single use case. Interaction diagrams do not capture the complete behavior, only typical scenarios.
  3. 3. Types of Interaction Diagrams There are two types of interaction diagrams: Sequence diagrams emphasize the order or concurrency of the interactions. Collaboration diagrams emphasize the interacting objects.
  4. 4. Role of Interaction Diagrams in UML
  5. 5. Interaction Diagrams and Use Cases Behavior of the “order” use case: A customer orders several products. The (sub-)orders (“order lines”) for each product are prepared separately. For each product check the stock. • If the product is in stock, remove requested amount from stock. • If the product stock falls below a predefined level, reorder it.
  6. 6. Object Object naming: myBirthdy  syntax: [instanceName][:className] :Date  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. The Life-Line represents the object’s life during the interaction
  7. 7. 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 sends a message to another 1 object obj2 some link must exist between those two objects (dependency, same objects)
  8. 8. 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.
  9. 9. 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()  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 = isValid()
  10. 10. Synchronous Messages Nestedflow of control, typically implemented as an operation call.  The routine that handles the message is completed before the caller resumes execution. :A :B doYouUnderstand() return Caller yes (optional) Blocked
  11. 11. Object Creation An object may create another object via a <<create>> message. Preferred :A :B :A <<create>> <<create>> :B Constructor
  12. 12. 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>>
  13. 13. Sequence Model (1)
  14. 14. Sequence Model (2)
  15. 15. Sequence Model (3)
  16. 16. Sequence Model (4)
  17. 17. Why not just code it? Sequence diagrams can be somewhat close to the code level. So why not just code up that algorithm rather than drawing it as a sequence diagram? a good sequence diagram is still a bit above the level of the real code (not EVERY line of code is drawn on diagram) sequence diagrams are language-agnostic (can be implemented in many different languages non-coders can do sequence diagrams easier to do sequence diagrams as a team can see many objects/classes at a time on same page (visual bandwidth)17
  18. 18. Lifetime of objects creation: arrow with new written above it  notice that an object created after the start of the scenario appears lower than the others deletion: an X at bottom of objects lifeline  Java doesnt explicitly delete objects; they fall out of scope and are garbage-collected 18
  19. 19. Indicating selection and loops frame: box around part of a sequence diagram to indicate selection or loop  if -> (opt) [condition]  if/else -> (alt) [condition], separated by horiz. dashed line  loop -> (loop) [condition or opt [balance 0] items to loop over] [balance 100.00] <> alt < [balance 100 ] >= .00 loop [balance 0] <19
  20. 20. Concurrent Processes and Activations
  21. 21. Concurrency in Sequence Diagrams (1)
  22. 22. Concurrency in Sequence Diagrams (2)
  23. 23. Concurrency in Sequence Diagrams (3)
  24. 24. A Successful Bank Transaction Reference: Object-Oriented Analysis and Design J.W. Schmidt, F. Matthes, TU Hamburg-Harburg
  25. 25. A Failing Bank Transaction Reference: Object-Oriented Analysis and Design J.W. Schmidt, F. Matthes, TU Hamburg-Harburg
  26. 26. Sequence diag. from use case26