UoL CS Notes
Menu

Interaction Diagrams - Collaboration, Sequence & Activity Diagrams

COMP201 Lectures

Interaction diagrams record how objects interact to perform a particular use-case.

Collaboration Diagrams

Collaboration diagrams show links, objects and actors.

The labelled arrows show a message sent from one object to another.

actor "aMember:BookBorrower" as member
[theLibraryMember:\nLibraryMember] as librarymember
member -- librarymember:borrow(theCopy) >
librarymember -- librarymember:1: okToBorrow >
[theCopy:Copy] as copy
librarymember -- copy:2: borrow >
[theBook:Book] as book
copy -r- book:2.1: borrowed >

The objects are named as objectName:className.

Sequence Diagrams

This is the same events as before, shown in a sequence diagram:

sequenceDiagram
actor bb as aMember:BookBorrower
participant lm as theLibraryMember:LibraryMember
participant c as theCopy:Copy
participant b as theBook:Book
activate bb
bb ->> lm:borrow(theCopy)
activate lm
lm ->> lm:1: okToBorrow
lm ->> c:2: borrow
activate c
c ->> b:2.1: borrowed
activate b
deactivate b
deactivate c
deactivate lm
deactivate bb
  • Messages are shown as solid lines.
  • Returns are shown as dotted lines.

Timing Constraints

You can show timing constraints like so:

sequenceDiagram
actor bb as aMember:BookBorrower
participant lm as theLibraryMember:LibraryMember
participant c as theCopy:Copy
participant b as theBook:Book
activate bb
note over bb:A
bb ->> lm:borrow(theCopy)
activate lm
lm ->> lm:1: okToBorrow
note over bb:{C-A < 5 secs}
lm ->> c:2: borrow
activate c
note left of b:{borrowed'-borrowed < 1 sec}
c ->> b:2.1: borrowed
activate b
deactivate b
deactivate c
lm -->> bb: 
deactivate lm
note over bb:C
deactivate bb

Creating & Deleting Objects

In collaboration diagrams:

  • You can show if objects are created and destroyed by labelling them with {new} and {destroyed}.
  • If an object is created and destroyed in the same interaction, it can be labelled {transit}.
actor ":UTO" as UTO
component ":Lecturer {destroyed}" as Lecturer
component ":DirectorOfStudies {new}" as DirectorOfStudies
UTO -r- Lecturer:1: n := getName() >
UTO -r- Lecturer:3: destroy() >
UTO -- DirectorOfStudies:2: new DirectorOfStudies(n) >

You can create and delete objects in a sequence diagram like so:

actor ":UTO" as UTO
participant ":Lecturer" as Lecturer
participant ":DirectorOfStudies" as DirectorOfStudies
activate UTO
UTO ->> Lecturer:1: n := getName()
activate Lecturer
deactivate Lecturer
create DirectorOfStudies
UTO ->> DirectorOfStudies:2: new DirectorOfStudies(n)
UTO ->> Lecturer:3: destroy()
destroy Lecturer
deactivate UTO

Messages from an Object to Itself

If an object sends a message to itself you can use the Java keyword this. This will call the method on the existing object.

Omitting messages from an object to itself, for internal computation, can be used as a form of abstraction.

Packages

We can split of a sub-collaboration into a package in order to simplify a collaboration:

  • Collaboration - Collection of objects and links between them.
  • Sub-Collaboration - A subset of the objects together with the links connecting those objects.

Activity Diagrams

The following is an example of an activity diagram:

stateDiagram
state j1 <<join>>
state f2 <<fork>>
state member {
state br <<choice>>
[*] --> br
br --> fb:borrower
br --> wq:returner
fb --> wq
fb: Find Book on Shelf
wq: Wait in Queue
f2 --> [*]
}
wq --> j1
state librarian {
state br2 <<choice>>
j1 --> br2
state f1 <<fork>>
br2 --> f1:returning
br2 --> rb:borrowing
rb:Record Borrowing
f1 --> rr
rr:Record Return
f1 --> pb
pb:Put Book Back on Shelf
state j2 <<join>>
rr --> j2
pb --> j2
rb --> pn
pn:Prepare for Next Member
j2 --> pn

pn --> f2
f2 --> j1
}

It has the following components:

  • Activity - A task to complete.
  • Transition - Moving from one activity to another.
  • Synchronisation Bar - Describes the coordination of activities.
  • Decision Diamond - Can be used to show decisions.
  • Start/Stop Markers - The same as state diagrams.

There are several differences between activity diagrams and state diagrams:

  • Activity diagrams don’t normally include events.
  • Activities are intended to proceed, following the flow described by the diagram. Usually one of the guards of an edge leaving an activity should be satisfied.
  • Concurrent activities can be modelled by using the synchronisation bar notation.