[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
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

# 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
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:
• *** 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:

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.

[ 10x.html ]

[ 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.

[ 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 ]

• 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.