[Skip Navigation] [ CSUSB ] / [CNS] / [Comp Sci & Engineering] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Question] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 10.html Mon Sep 28 15:44:28 PDT 2009

Contents

    CSci 375/10 Interaction Diagrams
    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous9Packages197-219Q4(173-219)-
    Today10Interactions221-247-W4(transition to design)
    Next11Class Diagrams248-270Q5(221-270)-

    (Close Table)

    Revision History
    Table
    Version#DateDescriptionAuthor
    02005-01-03Used boiler plate to make templateRJB
    12005-02-04Added Book Section HeadersRJB
    22005-02-10Adding notes and questionsRJB
    32006-02-02UpdatesRJB
    42007-01-10Add link to projectRJB
    52007-02-07Added reference on messagesRJB
    62008-02-05Made some small improvementsRJB
    72009-03-04Found messages in the SSDRJB
    82009-03-23New Exercise on Code and InteractionsRJB

    (Close Table)

    Chapter 15 UML Interaction Diagrams

    1. * A visual aid for thinking about how a set of objects work.

    2. ** Two formats, say samething in different ways. Both have advantages and disadvantages. Learn Both.

    3. *** Learn to translate between sequence diagrams and communication diagrams.

    4. * You can use them to explore what should happen when ANY operation is applied to any object.

    5. * Think in terms of a basket-ball game: messages are passes. The players are objects. The ball is with the object that is active. etc.

    6. * Review the formats for messages and returned objects. [ 08.html#Messages ]

    7. * Think in terms of an atomic cloud chamber: a particle comes in and collides with another particle.... and a spray of particles and interactions are triggered off.

    8. **** Each incoming message in an interaction diagram maps to a header for a member function of a class.

    9. **** Each outgoing arrow maps to a call of a member function of a class.

    10. * Interaction diagrams are used to design the internal classes of a system. One message on the SSD triggers off a lot of activity between the objects inside the System. These diagrams help you work these out. The interactions drive the design of the classes inside the system.

    11. *** Each message in an SSD has no more than one set of interactions.

    12. * Treat this chapter as a reference manual of notations.

    13. + Looking ahead: we take each step in the SSD and work out a set of interactions that do what is needed. [ UC2Code.png ]

    14. + Design is easier if you know what is true before the operation and what must be made true before it it complete. So, Operation Contracts make designing objects easier.

    15. *** 15.1 Two forms of interaction diagram: sequence
    16. and communication (once called collaboration )
    17. * 15.2 Tracing interactions is more important than first thought. This by experts and novices.
    18. * 15.3 Notation for objects. name : class, <<metaclass>>

      Sequence Diagrams

    19. * Examples [ search?cat=img&cs=iso88591&q=sequence+diagram&rys=0&itag=crv ]

    20. 15.4 Basic Sequence Diagram Notations:
      • *** message, reply/return, (Q5) [ 08.html#Messages ]
      • *** reply = message (Q5)
      • ** message to self
      • ** creation, destruction (><) (Q5)
      • ** alt(Q5), loop(Q5), opt(Q5), par, region
      • ** [condition], [else]
      • * action boxes (action)
      • * nesting, ref, sd
      • *** <<metaclass>>
      • * polymorphism (more later)
      • * asynchronous vs synchronous calls, active objects,...
      • *** Found messages -- the trigger for a set of interactions. A function header.
      • **** Each activation box maps to the body of a member function in the code.
        ++ Common technique: an object p will send a message to object q that includes p as data 
         		doSomethingForMe(p)
        and q will respond by sending requests and data back to p by using ps own functions. An example of the Hollywood Principle -- "Don't call us, we will call you!"

      Communication/Collaboration Diagrams
    21. 15.5 Basic Communication Notation:
      • **** Links + Messages(Q5)
      • *** One link -- MANY messages.
      • ** create, (Q5)
      • **** sequence numbers: complex 1, 2, 2.1, 2.2, 3...(Q5)
      • ** conditions, iteration(Q5)
      • * <<metaclass>>
      • * synchronous and asynchronous
      • ** Found messages -- the trigger for a set of interactions.
      • **** Each box maps to the bodies of member functions in the code. The numbers tell you what function is being defined.

    22. +++ Sequence and Communication diagrams are equivalent. Learn to map between them (Q5)!

    23. +++ It is best to analyse one single "found" message at a time.

    . . . . . . . . . ( end of section UML Interaction Diagrams) <<Contents | End>>
    (Q5): Tested in Quiz 5.

. . . . . . . . . ( end of section Chapter 15 UML Interaction Diagrams) <<Contents | End>>

Example: List unfulfilled orders at a depot

[ 10ExGetUnfilledInteract.html ]

This interaction leads to thee fragments of code: [ 10ExGetUnfilled.cpp ] to be added to Depot, Customer, and SalesOrder.

Exercises if Time

  1. What interaction diagrams might be drawn for this SSD? [ 09SSD060208.jpg ] (Don't draw the diagrams ... just decide how many and what each would do).

    Here is the declaration of a member function in C++ & Java translate it into a (1) sequence diagram, and (2) a communication diagram: 

     		void A::f ( B* b) { b->g(this); C* c = new C; c->h(b); }
     		public void f ( B b) { b.g(this); C c = new C; c.h(b); }

    Answers: [ 10ExAf.png ]

    Here is some more C++ code.... fit it into both your interaction diagrams 

     		void B::g ( A *a) { a->k(); }
     		public void g ( A a) { a.k(); }

    [ 10ExAfBk.png ]

  2. Translate a given sequence diagram to a communication diagram.

  3. Translate a given communication diagram to a sequence diagram. Handout.

  4. Given an incomplete pair of diagrams of the same set of events/messages -- one communication and one sequence -- use the given information to fill in the blanks.

  5. Act out a given interaction diagram.

  6. Read a given diagram aloud -- read out what steps does it does.

  7. Given a dictation of a set of steps.... draw the diagram.

. . . . . . . . . ( end of section Exercises) <<Contents | End>>

Questions and Answers

[ 10q.html ]

Next: Class Diagrams

 Each object in an interaction diagram has a class in a design class diagram, and the messages in the diagram are operations in the clases!

  • *** A small to medium size project will only have ONE design class diagrams, but many interaction diagrams.

    [ 11.html ]

    Project 4 -- SSDs and Packages

    [ w4.html ] due next class.

    Review Questions

     [ 10r.html ]

    Standard Definitions
  • CS202::= See http://cse.csusb.edu/dick/cs202/.
  • CS372::= See http://cse.csusb.edu/dick/cs372/.

  • DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  • DRY::XP="Don't Repeat Yourself".

  • ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

  • Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  • GoF::="Gang of Four", [ patterns.html#GoF ]
  • GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  • Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  • KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

  • OO::shorthand="Object-Oriented".

  • OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  • patterns::="Documented families of problems and matching solutions", see Patterns.
  • Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  • Process::="How to develop software".

  • RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
  • RUP::Process="Rational UP", a proprietary version of UP.

  • SSD::="System Sequence Diagrams", see chapter 10.

  • TBA::="To Be Announced".

  • UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  • UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  • YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need it now. In this class it means "It won't be on the final or in quizzes".

  • XP::="Extreme Programming", the ultimate iterative code-centric, user-involved process.

    End