Modelling with Role Activity Diagrams (RADs)
Role Activity Diagrams are a notation originally developed for software process modelling. In the UK they have been used and promoted by both Praxis and Co-Ordination Systems, and their merits have been discussed at a number of tutorials and meetings on process modelling. The process modelling CASE tool, RADitor marketed by Co-Ordination systems uses Role Activity Diagrams as its diagramming method. RADs can be considered to be a state of the art single paradigm process modelling approach, and are well known among the process modelling community.
Any business process consists of a number of distinct, concurrent activities corresponding to the many contributing ‘roles’. It is this notion of roles and the interactions between them that form the basis for RAD descriptions. Such a description of a world of roles is intended to exploit the notion of concurrently executing agents all co-ordinating to achieve a common goal.
The process model is recorded in the form of a Role Activity Diagram (RAD). A RAD shows the roles, their component activities, and their interactions together with external events and the logic that determines what activities are carried out when. We will use a subset of the original RAD notation in our learning activities. The aim is for you to understand the basics of role based modelling.
1 Basic Notation used in Role Activity Diagrams
A role involves a set of activities which, taken together, carry out a particular responsibility or set of responsibilities. For example, take the business process of a publisher. We can identify roles such as, Authoring, Copy Editing, Designing, Editing, Planning, Producing, Marketing, and so on. In a retail store we might find roles such as Buyer, Shop Floor Assistant, Customer, Store Manager, Checkout Assistant, Security, Supervisor, etc. (Ould, 1995).
Although we tend to identify roles using job titles, we should take care not to get confused between the role name and the title. In most cases the activities that are coined under a job title run across a number of processes. Take the post of a 'Store Manger'. We can treat this as a role. But clearly this is a post, which has a part to play in many processes in the store: staff management, stocking, planning market strategies, in some cases granting credit, etc. A post in many cases combines a number of areas of responsibility in the organisation.
We may also tend to identify parts of the organisation as roles, such as, departments, divisions, and sections. Again their activities range over a number of processes. Take the Reception of Hendon campus, for example. They perform a variety of tasks. Let's try to enumerate them. Reception is the greet people, provide them with various information, they sign for goods delivered, incoming and outgoing mail through the box van go via them, they answer phone calls, again providing information, they hold keys to rooms, assigning/request of labour done through them. So, certain marketing activities are done, providing promotional information for people either via phone or in person, goods in activities, mail room activities, security, resource management are some of the processes they participate in.
Roles are types. Role instances are process participants. They carry out activities in order to achieve some goal or objective. They are the actual objects in the real world. Take as an example the business process of a retail store. Two roles we can identify in this business process are; Customer and Cashier. Say Peter, Tom, and Garry enters the shop to do their weekly shopping. Each of them now represents an instance of the role Customer. A role instance can be acted by a person, a machine, or a group of people.
In a RAD model, a role is represented by the contents of a curvy edged rectangle. Each role has a vertical thread of activity that starts at the top of the rectangle. The notation used to represent a role is shown below.
Each role has a start and an end state. The role may start in an 'initial' state or it may start at a specific state, e.g. a role cashier may start at a state 'ready to serve Customers'. The ending of a role is represented by using a terminator, denoting that, logically no further activity could take place.
A role has a state. In carrying out an activity it moves from one state to another. The line vertically above the activity represents the role's previous state, and the line below the activity, its new state (after the action). In labelling these states the state-based semantics of the role becomes clearer, and the labels can help to make explicit the pre-conditions and consequences of each activity or action.
However, the notation does not require the modeller to explicitly label the state of a role. The advantage of showing the state explicitly is that it makes the model easier to understand. The disadvantage is that the diagram becomes larger and this may sometimes hamper understanding.
For example, take the Customer role in a small retail shop. The action 'enter shop' changes the state of the role from 'not being able to select goods' to 'able to select goods'. The first state is implicitly stated, while the latter is explicitly stated. The action 'select goods' changes the state of the Customer role from 'able to select goods' to 'ready to pay'.
The representation of the state becomes useful when there is a need to show iterative or repetitive action (more simply known as looping. The use of state labels allows us to avoid using loops to represent iterative actions. Using state labels we can show easily the way a role returns to a previous state (see Figure below).
In the above figure both constructs represents the same logical sequence of actions. The construct to the rights shows looping back or returning to a previous state by joining the 2 state by a line. Although this construct may be easier to understand, it becomes very cumbersome when the model is large and/or complex. The same logic can be presented very elegantly using explicit states.
The adoption of state labels can assist or hinder the understanding of the model depending on the complexity of the process being studied. It is up to the modeller to decide how best to present the model. One basic objective of modelling is to understand the underlying business process. The model produced should be able to achieve this objective.
An action is a process step, which changes the state of the system. An action changes the state of its own role, from some before state to some after state. An action is represented in a RAD using a square.
What we need to understand is that the granularity of actions may change according to what level of detail you are representing in your model. For example, an activity in one model can be expanded to a separate RAD showing further details.
Activities relate to each other in 3 different ways:
A choice indicates different sequences of activities. Only one path given will be pursued.
Note that unlike in a choice, all paths in the parallel construct will be pursued. Only the sequence in which they are acted upon is not relevant.
In a process model we want to show where activities are sequential, alternative, or parallel. This is one way of representing business rules (Ould, 1995).
Interactions are one of the most important things that happen in a process, e.g., a manager delegating tasks to a subordinate, handing over a report, a discussion between 2 people (exchange of ideas, decisions), an agreement among a group of people.
An interaction is a process step that takes place simultaneously in more than one role. In other words an interaction can involve any number (more than one) of roles and signifies that the roles involved must pass through it together - they synchronise.
Sometimes it is useful to show which role participating in an interaction takes the lead or is responsible for making it happen. Such a leading role is known as 'driving role'. We indicate the driving role by shading the activity square in that role. In the above diagram, Role 1 is the driving role.
The synchronisation aspects of an interaction is important: that is, for the interaction to happen all participating roles should be in their before states. As a result of the interaction all roles involved in the interaction move from their before states to their after states.
More formally, with respect to the diagram above, when the driving role (Role1) is in the state before1, and its associated role (Role2) is in the state before2, then the interaction may take place. The interaction is named at the driving role end. The driving role (or rather the activity) is further emphasised by shading the activity square associated with the interaction.
As a result of the interaction, the driving role will move to the state after1, and the associated role will move to the state after2.
Note that the interaction does not carry arrows to indicate a 'flow' or a direction. A direction is implicitly indicated by the driving role. (See web notes for further clarification).
One role can instantiate another role, i.e., start a new instance of another role. We call this 'creation'. The creating role has the simple state change from its before1 state to its after1 state. The new role is usually created in an initial state.
More formally when the role is in the state before1, it performs the creation and moves to the state after1, creating a new instance of type R.
2 Example: case study 1
In order to understand the notation used in RADs lets consider a simple process of ‘shopping’, how retailers process their customers. This is to allow our initial choice of application domain to be something familiar to all of us (hopefully). In our scenario a customer having entered the shop should be able to select goods and then pay for what s/he has selected, or leave the shop. During the time the customer is in the shop, s/he should be able to select and/or pay for the goods any number of times s/he desires, until the customer decides to leave the shop. The shop should be able to display goods for the customer to select and manage the transaction of receiving money for those goods. This scenario is shown in Figure 3.
As you all know by now, the central concept of Role Activity Diagrams is that of a role. A role describes a sequence of steps or activities, which can be acted out by a person or perhaps by a group or department, or even a machine. Roles are acted out in parallel and communicate through interactions. It is important to realise that a role is merely a type. For example, it may describe the behaviour of a class of people. So, in the above example a role may describe the responsibilities and interactions of a customer, or a cashier. A single instance of a role can be acted by many people, and similarly a single person may act many role instances. For example, taking the shopping example, one person may act as a supervisor role and also a cashier role at two different time points.
A role is represented by a curved edged rectangle. It has a thread of activities within it, and is read from top to bottom. The line connecting the activities (represented by square boxes) is called a state-line, and represents the state of the role at a given time.
There are two kinds of activities within a role, actions and interactions. In Role Activity diagrams an action is a process step that the actor of the role carries out in isolation. Thus actions do not involve any joint behaviour with another role. Actions are represented by an unfilled square.
In the above case study (Case Study 1) we can identify the following actions in the role, Customer: enter shop, select goods, and leave.
An interaction between two roles implies that they have some shared or joint behaviour and is represented by joining activities within different roles by a horizontal. An interaction is usually initiated by one of the roles involved, in which case the action in the initiating role is shown by a filled square.
In the above case study 'paying for goods' is an interaction since it involves both the Customer and a Cashier in the store.
The scenario described in the case study can be represented in a RAD model as shown in the figure below.
This diagram shows two roles: customer and cashier for a retail outlet, e.g. a supermarket. Having entered the customer may choose to select goods or leave. Once goods have been selected the customer must make a payment before leaving. However, a number of selections can be made before paying. On payment there is an interaction with the cashier. This is only possible if there is an instance of a signed-on cashier for the customer to interact with.
Figure 1: Case study 1: Shopping
An action changes the state of the role in which it occurs. For example, in Figure 1, the activity of entering the shop changes the state of the Customer from ‘not being able to select goods’ (not shown in the model but implicitly understood), to ‘ready to select goods’.
Alternative paths are where there is a choice of activity and the choice is dependent on some condition. The notation used to denote choice is an inverted triangle. In the above figure, after the customer enters the shop s/he is faced with the choice of leaving the shop without taking any further action or selecting goods. This is represented by the two inverted triangles named ‘choose leave’ and ‘choose select’ respectively.
Once the customer has done a selection (action ‘select goods’) s/he is in the state where more goods can be selected, or pay for the goods, indicated by the state, ‘able to select/ pay’. At this point the customer can continue down any one of the alternative paths shown by the choice construct which follows the state.
In Figure 1, after each activity of ‘select’, the customer has a choice of paying what s/he has selected or selecting more. Only after ‘payment’ is the customer has the choice of leaving or selecting again. This sequence of activities forces the customer to pay before leaving. Note the use of state labels to show iterative action.
An interaction in Role Activity Diagrams changes the state of all roles that participates in that interaction. For example, in the figure representing case study 1, the interaction ‘payment’ changes the states of both roles, Customer and Cashier. Before the payment the customer may either select more goods or pay for goods, but may not leave. After payment the customer may select again or leave. The payment activity changes the state of the cashier so that s/he can process the next customer. The shared (interaction) activities must take place synchronously. This synchronisation may take place over time, and may be quite complex. We are not concerned about the nature of the interaction at this level of abstraction, only the fact that an interaction takes place is taken into account.
RADs display two kinds of parallelism; the role instances acting in parallel, and the threads of parallel activities within a role. In the ‘shopping’ example (see Figure 1), we can identify two parallel roles, Cashier and Customer. Role Activity Diagrams assume no ordering on the way instances of roles proceed. In other words, the RAD describes the behaviour of the role, and its relations to other roles, but it does not describe the allocation of resources to roles, or the number of roles active at any one time and so on. For example, the same person who previously acted as a supervisor may later act out an instance of a cashier role, but this may happen in parallel with another instance of the supervisor role. Similarly there will be a number of cashier roles acting in parallel at any one time. Roles are not descriptions of instances of behaviour rather they describe a type of behaviour to be acted by the role.
We can also have parallel (or concurrent) threads of activities within a role. These parallel vertical threads are denoted by the ordinary triangle symbol, . There is no choice here, and thus no forcing down one thread. Indeed, it is assumed that all paths are taken. In order to examine parallel threads lets consider the example given in Case Study 2.
4 Example: Case Study 2
The example describes the interactions between three roles; a Divisional Director, a Project Manager and a Designer, involved in ‘carrying out a design project’.
This small example is useful because it contains all of the constructs mentioned in Section 1.
The Role Activity Diagram below (Figure 2) shows three roles ‘Divisional Director’, ‘Project Manager’, and ‘Designer’. This diagram has no explicit labelling of states. However, the description below will implicitly mention states which, are represented by the lines between the activity squares.
Starting at the top of the Divisional Director role there is some external event (shown as a horizontal arrow) which signifies the approval for a new project. As a result of this event the ‘Divisional Director’ role is able to start a new project.
This is followed by the creation of a new Project Manager role, represented by ‘start new project manager’. Creation is represented by having an action square in the creating role, with a horizontal line with a double arrowhead pointing to the role it creates. In this way it is clearer which role type is created by the creating role.
As a result of the creation an instance of a Project Manager role will be created in an ‘initial’ state. Now the Project Manager and Divisional Director roles are able to agree a Terms Of Reference (TOR) for the project. Thus, the Divisional Director takes part in an interaction with a Project Manager role. Interactions are shown as squares joined by a horizontal line. In the driving role the activity square (associated with the interaction) is filled whereas in all other roles involved in the interaction the corresponding activity square is left unfilled. Hence, the Divisional Director side of the interaction has a filled square showing that this role drives the interaction. The completion of the interaction ‘Agree TOR for project’, moves the two roles to their next state.
The Project Manager role (as a result of the previous interaction) is able to take part in the action ‘start new designer’. As with the creation of the Project Manager role, the ‘start new designer’ creation, will create an instance of a Designer. In this case the Project Manager must write a TOR (the action ‘write TOR for designer’) before being able to initiate (drive) an interaction with the Designer to agree the TOR. Once this interaction has taken place the Project Manager is in a waiting state, waiting to receive an estimate from the Designer.
The Designer, having agreed the TOR, follows two parallel or concurrent paths. The paths are each denoted by an upward pointing triangle. The left-hand path involves a single action, ‘choose a method’. The right-hand path is more complex. The Designer must first ‘prepare an estimate’ (an action), and then take part in an interaction with the Project Manager, the result of which is that both roles have the estimate agreed. Since the interaction takes place only after the Designer has prepared the estimate the Designer drives the interaction. Only when this interaction ‘obtain estimate’ has taken place, can the Project Manager go ahead and ‘prepare a plan’. Similarly on completion of the action ‘prepare a plan’ the Project Manager drives an interaction which gives the plan to the Designer.
When both, the interaction ‘give plan to designer’ and the action ‘choose a method’ have been completed is the Designer in a state of being ready to design. All concurrent paths must rejoin in a Role Activity Diagram. At this point the Designer may take part in the action ‘produce design’. Having produced a design, the Designer must then ‘carry out design quality check’. Once again the role now has two paths. However, the downward pointing triangle symbol shows that there is a choice between these paths (only one may be taken). The choice depends on the post-condition of the previous action. If the design is not OK, then the role moves back to a state of being ready to design, shown on the RAD as a loop back; from the bottom of the inverted (no) triangle back to the activity ‘produce design’. There may be any number of iterations of this loop, produce design and then carry out a design check, before the design is acceptable. Once the design is acceptable, then an interaction is initiated by the Designer to ‘deliver design’ to the Project Manager. Finally for this depiction of the process the Project Manger takes part in an action to ‘produce project debrief report’.
5 Correct Assignment of Responsibilities for Driving the Process
It is very easy in constructing the RAD to give little credence to the importance of deciding which role drives the interaction. The interaction can easily be seen merely as a point of synchronisation for the roles, and a mechanism for communication. However, in the real world being modelled driving the interaction may be extremely important for the process as a whole to progress. It is necessary to assign the responsibility for driving the interaction to the correct role, since in the instantiation of the process it is necessary to assign the responsibility for initiating the interaction to an appropriate agent. Furthermore, since roles synchronise on an interaction it may be important that it is clear which role initiates this interaction in order to minimise slack time in the process.
As an example consider the ‘obtain estimate’ interaction between the Designer and the Project Manager (See Figure 2 for case study 2). The diagram implies that the interaction is driven by the Designer, who prepares an estimate and then sends the estimate to a (presumably waiting) Project Manager, who uses this estimate in some planning activity. However, it may be more sensible for the interaction to be initiated by the Project Manager. For example, it may be that estimate production is relatively trivial and that a number of estimates are produced and waiting, such that at the instant that they are needed they are requested by the Project Manager, sent and then used.
Case Study 2 may appear complex to you in your first reading. But it contains all the constructs which we discussed in the lecture and which you might use in answering your coursework. As you model a few simple example cases and get familiar to the notation you will gain more insight to the model.
6 Further Reading
Handy, C.B. (1976) On Roles and Interactions, in Understanding Organisations, Handy, C.B., Penguin Modern Management Texts, Penguin Books, 1976.
Curtis, B., M.I. Kellner, and J. Over (1992), Process Modelling Communications of the ACM, vol. 35, num. 9.
Shams-Aliee Fereidoon and Brian C. Warboys, (1995), Roles Represent Patterns, presented at the Workshop on Pattern Languages of Object-Oriented programs, ECOOP’95, Denmark, August 1995, available at http://www.cs.man.ac.uk/ipg/publications.html.
Information and Software Technology: Special Issue on Process Modelling in Practice, vol. 35, num. 6/7.
Yourdon, E (1989), Modern Structured Analysis, Prentice Hall.
The Informatics Process Group at Manchester University - active modelling of organization processes at http://www.cs.man.ac.uk/ipg/index.html.