5 INTERACTION DIAGRAMS  3/11/97

Interaction diagrams

describe the dynamic interactions between objects in the system, i.e. the pattern of message-passing.

Two main uses:

• Showing how the system realises [part of] a use case (Use Case View) – e.g. recording how you wave CRC cards around!

• Showing how an object reacts to some message (Logical View)

Particularly useful where the flow of control is complicated, since this can’t be deduced from the class model, which is static.

UML has two sorts, sequence and collaboration diagrams – the differences are syntactic.

Slide 45

5 Interaction diagrams

The work we’ve just done with CRC cards highlighted an aspect of the design that we don’t yet have a way of recording: the way that objects work dynamically together to achieve the goals of the system, e.g. as expressed in the use case model.

UML allows two major ways of doing this, and both are informally called interaction diagrams. The two ways are sequence diagrams and collaboration diagrams. You won’t usually use both within the same project: it’s more likely that that you’ll pick one you prefer in the context and use that. If you’re using Rose or a similar tool, you may not need to commit yourself: in Rose you can create one kind of interaction diagram, and Rose will create the other kind from it, and will then maintain the two in a consistent state, so that you can consult whichever seems more readable in a given context. As this implies, they record essentially the same information. (NB Rose isn’t very good at laying out the diagram, so you may have to move the elements of a generated diagram around yourself to make it legible.) Most of what I want to say applies to both forms.

As the name suggests, the interaction model describes the interactions between objects. It does not describe the internal computation within an object. So, for example, an interaction diagram may show object aCustomer sending a message to aBankAccount, but it will not record how object aCustomer knows which message to send, or which object to send it to. If we need to record that kind of information, we’ll use state diagrams.

The interaction model is in some sense less fundamental than either the use case model or the class model. Simple projects might well not develop them at all: if the interactions are sufficiently clear, you might go straight to code. Most projects will not develop interaction diagrams for every use case, but rather, will use interaction diagrams as a way of expressing the possible options in difficult cases.

Interaction diagrams can also be useful for documenting what an object should do when it receives a particular message, whether or not this corresponds obviously to some use case.

5 INTERACTION DIAGRAMS  3/11/97 5.1 Developing an interaction diagram

Generic and instance forms Interaction diagrams in UML come in two forms, a generic form and an instance form. (This is not explained well in Fowler: possibly it wasn’t settled when that went to press.) In the generic form, you show all possible interactions between objects of the relevant classes: that is, you describe the whole use case, including all its variants, using special syntax to show things like constraints and iteration. In the instance form, you just describe one possible instance of this behaviour; that is, one scenario, without branch points or unspecified numbers of repetitions. If you use the instance form to describe how the system realises a use case that has several scenarios, you may well have to develop several interaction diagrams for the same use case. For example, in the case of the WithdrawMoney use case, you might have one instance form interaction diagram to show what happens if the customer doesn’t have enough money in the account, and another to show what happens if s/he doesn’t.

We’ll deal with the instance form, since this is simpler, easier to use, and therefore arguably more useful. (And because it’s what Rose supports!)

Developing an interaction diagram

1. Decide exactly what behaviour to model.

2. Check that you know how the system provides the behaviour: are all the necessary classes and relationships in the class model?

3. Name the objects which are involved.

4. Identify the sequence of messages which the objects send to one another.

5. Record this in the syntax of a sequence or collaboration diagram.

(more detail in the notes)

Slide 46

5.1 Developing an interaction diagram

In more detail:

1. That is, which use case, and if there are several scenarios in the use case, which scenario; or else, what message, and what assumptions if any you have to make about the arguments to the message in order to know exactly what messages will pass.

2. So you have to know how the system provides the functionality, maybe from your CRC work, maybe from some other technique. (If it’s obvious, you probably shouldn’t be developing the interaction diagram at all.)

3. By convention, if an interaction involves some object of class Foo, we often call the object aFoo. (Obviously you need another convention if an interaction involves several different objects of the same class.)

5 INTERACTION DIAGRAMS  3/11/97  5.2 Sequence diagrams

4. Remember that the message includes the selector as well as the specific arguments. UML allows you to give particular arguments to the messages that appear in an interaction diagram: for example, you could develop a diagram to show what happens when a bank customer withdraws £20. Rose, however, only allows you to specify the operation: you have to show any constraints using notes.

5. See specific sections below.

A sequence diagram

Slide 47

5.2 Sequence diagrams

A sequence diagram shows the objects at the top of dashed lines. The line represents time as seen by the objectL it is the object’s lifeline.

The order in which you show the objects doesn’t matter, though it will make for a more readable diagram if you put the objects which take part earliest furthest to the left, so that most messages flow left to right.

If object1 sends message selector(arg1,arg2) to object2, you show this by an arrow from object1’s lifeline to object2’s lifeline, labelled with the message selector(arg1,arg2).

(You can show an object sending a message to itself, using an arrow from that object’s timeline back to the same timeline a little further down, but in most cases you will probably decide that that counts as internal computation inside that one object. As mentioned, the main purpose of interaction diagrams is to show different objects interacting. It’s a matter of taste, though: decide which is clearest in each case.)

The vertical position of an arrow represents the time at which the message is sent, so arrows appearing further down the page represent later messages. Messages are also (usually?) numbered in order, though the information is redundant.

UML permits actors, as well as objects, to appear at the top of lifelines. In the example, I show the actor aStudent sending a message to the object theStudent. Of course the actor – the flesh and blood student – can’t do this directly! But at some stage we do have to bridge this human/machine gulf, if we want to have diagrams that show how they relate. Assume that when an interaction diagram shows an actor sending a message, it means that somehow or other the actor causes the message to be sent.

5 INTERACTION DIAGRAMS  3/11/97  5.3 Collaboration diagrams

Here again you have to know that Rose treats actors as a special kind of class: to get an actor into a sequence diagram, you put an object there, and then in the specification of the object you specify an actor as the “Class” of the object. The shape of the object on the diagram will change from rectangular to actor-shaped.

In UML we can also show object creation and deletion, and a host of other features, but we won’t discuss them here. (If you want more detail on this or any other aspect of UML, see the UML notation guide accessible from the course home page.)

A collaboration diagram

Slide 48

5.3 Collaboration diagrams

The main difference between collaboration diagrams and sequence diagrams (at least, the simple forms we’re considering) is the layout of the objects and messages. A collaboration diagram does not have object timelines, and you cannot deduce whether one message occurs later than another by looking at their relative positions on the page. In a collaboration diagram the numbering on messages is essential, not, as in sequence diagrams, a redundant repetition of information shown on the diagram. The advantage of this is that it gives you freedom to use the spatial relationships between objects for other purposes. We use a plain line between objects to represent an association between their classes, which should, of course, correspond to an association (maybe the special kind of association, aggregation) in the class model.

Collaboration diagrams in Rose In the “link specification” that you get by doubleclicking (etc.) on a link between objects in a collaboration diagram, you can set the “association”, and Rose gives you a menu to choose from which, if you’ve specified the objects’ classes, will show the known association between those classes. Warning! Do not select this menu item! Rose will crash if you do. Type the name in instead. It’s also a known bug that long labels on the messages sometimes display truncatedly. If on an interaction diagram you see only part of your message’s name shown, clicking on the name and then on the background will normally fix it. (Any more Rose bugs, to me: I’ll be sending them in at the end of term.))

Trap 4: allowing circular dependencies

going through more than one “sensible reuse unit”.

E.g. (from Webster p228):

graphical rendering subsystem uses calls from text rendering subsystem uses calls from line layout subsystem uses calls from graphical rendering subsystem.

It’s quite easy to get this by accident: one reason why we delay deciding in which direction our associations are navigable.

Problem: if this happens you can say goodbye to reuse. It’s also very hard to understand.

Small-scale case: if possible, avoid making associations navigable both ways. (But not if the only way to do it is to have a huge non-cohesive class including both “real” classes!)

Slide 49

It was correctly pointed out in the lecture that there isn’t anything really special about circular dependencies (though this is languge dependent: in some cases it may be impossible to even compile such a system). The problem is with tightly coupled systems in general, and the thing about circular dependencies (with large circles) is just that they invariably are highly coupled. In particular, you can’t reuse anything on the circle without reusing everything on the circle.

Here’s a genuine example of a horrible dependency structure that doesn’t include any circular dependencies – but it takes a while to satisfy oneself of this! When you add in the fact that PG represents an implementation of graphs which exposes every implementation detail to the outside world, you’ll appreciate how hard it is to change this system, let alone reuse parts of it.

5 INTERACTION DIAGRAMS  3/11/97  5.3 Collaboration diagrams

CWB dependencies (not designed by me!)

Slide 50