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 SPRINT BPR Methodology 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.
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. Please select a specific construct below to read more about it or scroll down to see all.
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.
Roles are drawn as sets of boxes:
Figure 1. Role bodies
In Figure 1, we start to construct a Role Activity Diagram by focusing on two roles 'Officer' and 'Chair.'
Activities are represented as boxes within a role.
Figure 2. Activity
Here, 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.'
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 of the activity 'Prepare item for committee' represents a transition to a further state in which 'Make Item Available' is undertaken.
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 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.
Note that the striped box denotes the interaction driver (i.e. initiator). The white box is the interaction receiver (and, where applicable, responder).
Figure 4. Interaction
These are shown as inverted triangles. 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.
Figure 5. Choice
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.
Figure 6. Part Refinement
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 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:
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.
Figure 7. Cardinality Shown at Role Titles
A state is marked explicitly by a freeform loop. 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.
Figure 8. Explicit State Marker
Iteration can be shown in two ways.
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.
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.
Figure 10. Iteration using arrow notation
These are shown in Role Activity Diagrams by an arrow entering from the left.
Figure 11. Waiting
A crossed box 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.
Figure 12. Starting off another 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.
Figure 13. Identifying role deliverables