[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [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 Wed Feb 6 13:34:11 PST 2013

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
    92010-03-16New Exercise on Code and InteractionsRJB
    102011-02-05Expanded notes on Code and InteractionsRJB
    12 2013-01-23Added the darts and dart board analogy DCDRJB

    (Close Table)

    Chapter 15 UML Interaction Diagrams

    1. * A visual aid for thinking about how a set of objects work. Also a way to record the results of thinking.

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

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

    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.

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

    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. * Demonstration [ Minicalc.png ] (design) [ Minicalc.Cards.html ] (descriptions of objects) and [ Minicalc.cpp ] (C++ code).

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

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

    11. *** The activity when a message arrives maps to the body of the member function in the class.

    12. * 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.

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

    14. *** Messages in an SSD have data that is mostly alphanumeric. In a design the data often includes objects. Commonly, an object can pass itself to another object. These are actually pointers!

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

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

    17. + Interactions lead directly to the Design Class Diagram -- -- --(DCD)
      for the software. Many interaction diagrams are summarized by each DCD. You can imagine the relation between the interaction diagrams and the DCD as being like the relation between a set of darts and a dart board. Each dart has to land in a good part of the board... the arrows in aninteraction diagram are the darts... and the object life line that they point at tells you which part of the dart board/DCD they should be sticking in.

    18. + 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.

      Common Error -- Confusing an SSD with an Interaction Design

      An SSD is a very special kind of sequence diagram:
      1. It shows actors (external entities). These do not appear on normal sequence or communication diagrams.
      2. It has a single object that is always called ":System".
      3. We do not show activations.
      4. Messages+data flow from the primary actor into the System.
      5. Data is returned from the System to the primary actor.

      Interaction diagrams can also show what goes on INSIDE a system as it responds to a message. These have MANY OBJECTS.

      An SSD is a sequence diagram with one primary actor and an object called ":System". If the object is called ":System" and it is the only object.... then the diagram is a SSD. Else it is not.

      Semantics: SSDs show the sequence of events between an actor and the whole system. A sequence diagram should show the objects inside the system doing something.

    19. *** 15.1 Two forms of interaction diagram: sequence
    20. diagram and communication (once called collaboration ) diagram.
    21. These diagrams give you 90% of the code. For example Diagram 15.3 and 15.4 both show us that the class Register has an operation called makePayment:
       	void Register::makePayment(Money cashTendered)
       	{
       		sale->makePayment(cashTendered);
       	}
      we might deduce the existence of the attribute sale that refers to a Sale as well.

    22. *** 15.2 Tracing interactions is more important than most novices think.
    23. * 15.3 Notation for objects. name : class, <<metaclass>>

      +++ Messages and operations and functions

      Each incoming message describes the header of a function. Outgoing messages describe the contents of the body of a function.

      Sequence Diagrams

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

    25. 15.4 Basic Sequence Diagram Notations:
      • *** message, reply/return, (Q5) [ 08.html#Messages ]
      • *** reply = message (data) (Q5) Common error -- forgetting data
      • *** reply = message (Q5)
      • ** message to self
      • ** creation, destruction (><) (Q5)
      • ** alt(Q5), loop(Q5), opt(Q5), par, region
      • +++ loops include counting loops and loops that use iterators to send messages to a set of objects one after another.
      • ** [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. Notice the notation!
      • **** Each activation (tall and thin 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

    26. 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. Notice the different notation.
      • **** It is harder to work out the precise code for a function from a communication diagram. It doesn't have explicit activations and the notation for control structures is primitive. The numbers tell you what function is being defined. A message with number a.b....c.d indicates that it's operation is called as a result of the message a.b....c being sent. For example a message numbered 1 will invoke a function whose body sends messages 1.1, 1.2, 1.3, and so on. And 1.2 will call 1.2.1, 1.2.2, 1.2.3. So the sequence of calls will be: 1, 1.1,1.2,1.2.1,1.2.2,1.2.3,1.3,... for example.

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

    28. +++ Sequence and Communication diagrams describe code. If a message m(d) is sent from an object of class A to an object of class B:

      [Message m(d) is passed from A to B]

      then in some method in A there must be a an object b:B and a call

       		b->m(d)
      (C++ code)
       		b.m(d)
      (Java). Also in class B there must be a operation
       		m(d:Data):ReturnedObject
      (UML)

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

    30. +++ Assume that for any design class A we have classes like vector<A> and list<A> without having to draw any special classes. In Design Class Diagrams multiplicities (example "*") indicate the use of vectors, lists, etc. . Also we presume that we have iterators that can move accross the elements in these lists, vectors, etc. . Common notation
       		object_name : vector<Whatever>
      for example. Many would then write things like
       		[ for i=0..object_name.size ] .... object_name[i]...
      but I prefer
       		[ for item in object_name ] .... item...

      We also presume we can write code to insert and delete items in vectors, lists, etc. A message like

       		add(newItem)
      can be sent to a vector or set of similar Items and do the obvious thing.

    . . . . . . . . . ( end of section UML Interaction Diagrams) <<Contents | End>>
    (Q): Tested in quizzes and/or finals.
    (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

[ 10x.html ]

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

  • Artifact::="Anything that is created in the course of a project".
  • artifact::=see above.

  • DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code. [ 02DiceGameClasses.gif ] (example).
  • Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".

  • 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 set of objects and/or classes 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 has no value now, 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 and Engineering School, CSUSB".
  • RUP::Process="Rational UP", a proprietary version of UP.

  • SSD::="System Sequence Diagrams", see chapter 10 and [ 02DiceGameSSD.gif ] (example).

  • 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 also means "It won't be on the final or in quizzes".

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

    ( End of document ) <<Contents | Top