Summary of differences between protocol and behavioural state
diagrams
Any kind of state diagram records the qualitatively different states an
object can be in, and how events (things that happen TO the object) affect
that state.
Purpose:
A protocol state diagram is mostly for the clients of the object. It
tells them what they need to know: the protocol by which they have to
interact with the object, e.g., in what order they can send it messages.
For example, if you must send an object an initialise message before you
send it any other message, that'll be shown by the initial state having
only initialise as event on a transition out of the initial state.
A behavioural state diagram is mostly for the implementors of the object.
It tells them what they need to know to implement the object, including
what the object should do (the actions it should carry out) on each
transition.
Information: Only behavioural state diagrams can contain actions.
Quick questions
Q1 States in a UML state diagram are shown as
rectangles
ellipses
rectangles with left and right
sides curved
rectangles with rounded corners
Q2 The arrows in a state diagram are called
transitions
messages
events
associations
Q3 Two people could each create a behavioural state diagram for the same class,
and their diagrams could both be correct but have different numbers of states:
True
False
Q4 An element that can appear on a behavioural state diagram, but
cannot appear on a protocol state diagram, is:
a nested state
an action
an event
a condition
Answers:
Q1: rectangles with rounded corners
Q2: transitions (not, e.g., messages: perhaps I didn't say this very clearly)
Q3: true (There will usually be one natural answer! But there can be different ways of abstracting the full statespace that are technically correct, and occasionally, different natural ways to do it. Can you think of an example?)