1
APPENDIX 4: A Guide to Role Activity Diagrams
Role Activity Diagrams (RADs) are a useful way of describing processes. They are
valuable in documenting processes as they are now, and as they might be in the future.
The main part of the Salford BPR Framework describes the ways in which Role Activity
Diagrams can be used within a broader change project. This guide tells you how to draw
Role Activity Diagrams.
The guide will show you that Role Activity Diagrams are a reasonably simple
diagramming technique. It is not difficult to learn how to draw them and it is not difficult
for most people to interpret them.
The guide progresses by introducing each of the main constructs of the Role Activity
Diagram. It describes these in turn, giving advice about the drawing conventions. This is
syntactic guidance. In addition to these syntactic skills, the creation of Role Activity
Diagrams relies upon an ability to scope a study, to decide on the level of interest and to
determine the boundaries of each role in a diagram. This is where the real skill of using
Role Activity Diagrams comes in but such issues are addressed only partially in this
report. In reality the reader will rely upon experience gained through using Role Activity
Diagrams in projects. This experience will teach how Role Activity Diagrams can best be
used, and what they are most useful for.
The Main Constructs of the Role Activity Diagram
A Role Activity Diagram is a flowchart-type notation. They are normally drawn with the
main thread on the left and with choice conditions and part-refinements to the right.
Roles
 Role - a set of activities which when taken together achieve some particular goal.
Note that roles may or may not be equivalent to organisational job titles. For example,
‘Manager’ might be a role. So too might ‘Financial Performance Review’ – it all depends
on the scope and focus of the model being created.
It is sometimes useful to use gerunds to denote roles. This is because it helps some people
to emphasise the activities taking place rather than just the person or job-title involved.
Hence, ‘Manager’ might become ‘Managing,’ whilst ‘Financial Performance Review’
could be ‘Financial Performance Reviewing.’ This convention is not adopted in this
guide.
2
Roles are drawn as sets of boxes:
Chairman
Officer
Figure 1. Role bodies
In Figure 1, we start to construct a Role Activity Diagram by focusing on two roles
‘Officer’ and ‘Chair.’
Activities
 Activities - the items of work that people do.
Activities are represented as boxes within a role.
Chairman
Officer
Prepare item
for committee
Figure 2. An Activity
In Figure 2 we see that an activity has been added to one of the role bodies. This is
‘Prepare item for committee’ and is performed within the role ‘Officer.’
Ordering
 Ordering - activities are ordered by state.
Note that Role Activity Diagrams are state diagrams. The vertical lines linking activities
denote the different states of the role. Formally then it can be understood that completion
3
of the activity ‘Prepare item for committee’ represents a transition to a further state in
which ‘Make Item Available’ is undertaken.
Chairman
Officer
Prepare item
for committee
Make item
available
Figure 3. Ordering
Note that in fact it is highly unlikely that the ordering of activities is as precise in the real
world as it is in a Role Activity Diagram. People work in a complex manner often
tackling more than one task at a time. This is always a difficulty with formalised models
of work practice. The modeller will be wise to pay heed to these restrictions.
Interactions.
 Interactions – the point at which a role interacts with another role in order to fulfil an
objective.
Interactions are shown by a horizontal line linking two boxes. They designate
synchronous behaviour between the roles. They are easiest to understand when two
people are involved. For example, we can imagine that when the Officer carries out
‘Make item available,’ there is an interaction with another role that is carried out by
someone acting as a Chair.
In other cases we can understand them as points of synchronisation between roles. This is
not as obvious: we might think of two functions undertaken by the same person but
between which there is a logical interaction. For example, the roles ‘Agreeing Purchase
Price of House’ and ‘Legal Administration of House Purchase’ could be undertaken by
the same person, but there will definitely be a logical interaction between them.
4
Chairman
Officer
Prepare item
for committee
Make item available
Figure 4. Interaction
Choices.
 Choices - the conditions under which different activities take place.
These are shown as linked circles. In the diagram below it can be seen how the ‘Chair’
reviews the item for inclusion. If it is ok, no action is taken. If it is not ok, the Chair
reports the fact to the officer.
Chairman
Officer
Prepare item
for committee
Make item available
Review
item
Item ok for
inclusion?
No
Yes
Report to
officer
Figure 5. Choice
Part refinement.
 Part refinement - shows activities in sub-threads to the main thread. This means that
the ordering of these sub-threads is not significant.
5
Linked triangles indicate that activities below them can be undertaken in any order.
Therefore, ‘Prepare notes for meeting’ can be undertaken before, at the same time as, or
after ‘Read other materials.’
In the terminology of Role Activity Diagrams this is a ‘Part Refinement.’ What it really
says is that the vertical is a state that can be refined into further parts. It then is valid for
the actions in the separate threads to trigger in any sequence but they must all complete
before the main action thread is re-joined. Note - you will not have to look far to find
cases that deviate from this proper interpretation of part refinement.
Chairman
Officer
Prepare item
for committee
Make item available
Review
item
Item ok for
inclusion?
No
Yes
Report to
officer
Read
other
materials
Prepare
notes for
meeting
Figure 6. Part Refinement
Cardinality
 Cardinality – the numerical relationship between role types.
Cardinality is difficult in Role Activity Diagrams. Interpreting the semantics of the
previous diagram in a precise way reveals how this can be manifest. It can be seen that
two roles interact. The ‘Chair’ role receives an item for the committee from the ‘Officer’
role. The Chair reviews it and may reject it. The Chair will then read other materials for
the meeting and prepare notes. So, what happened to all the other items for the
6
committee? The diagram shows an interaction between two roles. The implication is that
the committee considers only one item.
It is therefore helpful to show the cardinality occurring across the interaction. This is
done simply by denoting a relationship of the following sorts:
 One to one (default)
 One to many (1:m)
 Many to one (m:1)
Of course, there are many officers who submit items to the chair of any given committee.
Therefore, there is a many to one relationship between role types. This is denoted by
marking the role titles appropriately.
Chair (1)
Officer (m)
Prepare item
for committee
Make item available
Review
item
Item ok for
inclusion?
No
Yes
Report to
officer
Read
other
materials
Prepare
notes for
meeting
Figure 7. Cardinality Shown at Role Titles
Explicit State Marker.
 State - It is sometimes useful to identify and label particular states in a Role Activity
Diagram.
7
A state is marked explicitly by concentric circles. This is done to promote clarity and to
show iteration (see Iteration, below). In Figure 8** we simply denote the state at which
the Chair’s preparation for the meeting is complete.
Chair (1)
Officer (m)
Prepare item
for committee
Make item available
Review
item
No
Item ok for
inclusion?
Yes
Report to
officer
Read
other
materials
Prepare
notes for
meeting
Preparation for
meeting is
complete
Figure 8. Explicit State Marker
Iteration.
 Iteration – a return to a previous state of the role.
Iteration can be shown in two ways.
 State markers can show iteration.
 An arrow which linking two states in a role.
The example below shows the use of state markers for iteration. Note that a state marker,
‘Item Awaiting Review,’ is shown in the ‘Chair’ role. A new condition is also inserted
into this role (‘All Items Reviewed?’). If this condition is not satisfied then the role
returns to its earlier state. This is shown by the state marker on the ‘No’ thread.
8
Officer (m)
Chair (1)
Prepare item
for committee
Make item available
Item
awaiting
review
Review
item
Item ok for
inclusion?
No
Yes
Report to
officer
All items
reviewed?
No
Yes
(Item
awaiting
review)
Read
other
materials
Prepare
notes for
meeting
Preparation for
meeting is
complete
Figure 9. Iteration shown by State Markers
The diagram below uses an arrow to denote the same iteration. Note also the introduction
of an iteration in the ‘Officer’ role (as officers may submit more than one item.) Notice
also how the interaction received by the Officer role (‘Report to Officer’), is now shown
on its own thread. This is done where an interaction may or may not be received in a role
– hence it is logically separable from other activities.
9
Chair (1)
Officer (m)
Prepare item
for committee
Make item available
Other
items?
Yes
No
All
items
prepared
Review
item
Item ok for
inclusion?
No
Yes
Report to
officer
All items
reviewed?
No
Read
other
materials
Yes
Prepare
notes for
meeting
Preparation for
meeting is
complete
Figure 10. Iteration using arrow notation
Waiting.
 Waiting - external events or inputs are sometimes needed before work can continue.
These are shown in Role Activity Diagrams by a circle with an arrow entering from the
left.
10
Order
taxi
Taxi
arrives
Depart for
destination
Figure 11. Waiting
Starting Another Role.
 Starting Another Role - one role can start off another role.
A five sided figure is used to indicate the point at which another role is started. This is an
important feature through which Role Activity Diagrams can be used to represent
dynamic behaviour.
Process
Application
Security
Assessment
Create
Membership Card
Figure 12. Starting off another role
Starting off a Role that is not Modelled.
 Staring off a role that is not modelled.
When the five sided figure also has an arrow heading to the right, this indicates that the
role being started is not modelled in the collection of diagrams. There may be a number
of reasons for this but typically it will be a result of the scope of the study.
Process
Application
Security
Assessment
Create
Membership Card
Figure 13. Starting off a role that is not modelled
11
Identifying Role Deliverables
 Role Deliverables – identifying the concrete outputs of a role.
Sometimes it is useful to provide a highlighted description of the outputs of roles. This
enables the reader to quickly peruse the diagram, focusing upon how each role works on
the deliverables described.
This kind of highlighted description can be provided below each role body. The text
should be phrased in a way that helps the reader to quickly assimilate the dynamics of the
process being described. An example of a RAD containing description deliverables is
contained below.
Committee Services Officer.
Approximately 10 days
before meeting
Directorates
Give agenda
items & reports
Receive items &
reports
Prepare
agenda &
reports
Printing
Each committee will
primarily service
one committee but
there are many
directorates that
may submit items to
a committee.
Deadline 12.00
Wednesday
Send to printing
Print &
collate
Note that preparation of
agendas and minutes will
be done through
interaction with a typing
pool (not shown).
Thursday AM
Give to despatch
Despatch
Thursday
Distribute to
members
Members
Receive
papers
Prepare
Minutes
Prepare for
meeting
Members will receive
papers relating to a
number of different
committees.
Attend
committee
meeting
Week following receipt
of minutes
Present
items
Record
decisions/
comments
Attend party
meeting
Attend
committee
meeting
Make
decision/
comments
Deliverables of roles
Agenda Items & Reports
(i) Given to Committee Services
Officer (ii) Presented to Committee
Agenda Items & Reports
(i) Passed on to Printing
Minutes
(i) Recorded as official record
Agenda Items & Reports
(i) Passed on to despatch
Agenda Items & Reports
(i) Passed on Members
Decision
(i) Decision made
Comments
(ii) for inclusion in minutes
12