Video – Overview of lesson
Video - Overview of lesson
Introduction
The UML Activity diagrams are the way of modelling business processes and other activities with the Unified Modelling Language, (UML).
The UML is a graphic notation for the construction of various forms of system model.
The UML notation supports the entire system development process, from the business process modelling through technical design and implementation. It therefore contains far more icons (artefacts) than are needed for business process modelling.
The business process models use the minimum detail necessary to do the job of business process modelling: rectangles, diamonds, lines and a few circles. This course uses a relevant, and minimal, subset of the available icons.
Detail can be added, if necessary, as a development project gets into the more technical stages. We will keep things business focused and as simple as possible.
In UML activity diagrams, all artefacts such as tasks, decisions, merges, start and end points are referred to as ‘nodes’. We shall occasionally use this term in the following text but we will emphasise terms used in the BCS syllabus.
In this lesson we go over many of the points raised in the previous lesson, adding more detail where useful and applying the standard notation for UML activity diagrams.
Representing actors on the process model – Swim lanes
Swim lanes are drawn as sets of parallel lines, either horizontally or vertically, exactly as demonstrated in the previous lesson.
We recommend that you always include swimlanes for ‘external’ actors, e.g. customers and suppliers. A common convention is to place the externals at either the top or the bottom when using horizontal swim lanes.
In the modelling notation for BPMN (Business Process Modelling Language), the swimlanes of external actors are drawn physically separate from the swimlanes representing internal actors. This convention is not used in activity diagrams.
The accompanying diagram shows horizontal swimlanes. Note the two parallel vertical lines forming a column that contains the names of the actors.
Start and end points
It is normal practice to indicate the start and end point(s) (nodes) of the process; in standard activity diagrams, they are just that, the start and end points of a set of actions.
When using activity diagrams for business process modelling, it is good practice to consider the start and end nodes as the triggering event and outcome(s) respectively.
Start point
The start point is represented by a small, solid, circle.
Label the start point with the name of the triggering event.
Typically there is only one start point for a workflow.
UML activity diagrams support multiple start points which can be used to represent a situation where multiple actors have different roles in a process, all of which start independently of each other and either at the same time or at no particular time.
Alternatively, multiple start points can be used to indicate that various tasks have to be done at the start of the process, by a single actor, but the order in which they are started does not matter.
You are most unlikely to need multiple start points for the BCS examination but you may occasionally find them useful when modelling for real.
End Point(s)
The end points of a process are represented with a small ‘solid’ circle surrounded by a larger clear circle.
Most process models will have multiple end points (outcomes) representing the different possible outcomes of an instantiation of the process.
Each of the possible end points for a process must be shown on the diagram. It is good practice to annotate the end point, e.g. ‘Successful’ or ‘Unsuccessful – Credit check failed’.
Modelling tasks
Tasks are depicted with a round cornered rectangle.
The name of the task is written in verb-noun format inside the rectangle, e.g. ‘Dispatch order’.
Tasks are drawn inside the swimlane of the actor that executes it.
Process Flows
The flow of control between tasks is denoted by a line ending in an arrowhead. The arrow can point in one direction only.
As we have already mentioned, the BCS syllabus refers to these arrows as process flows.
The accompanying diagram, ‘Process flows on the main path’, shows an example of tasks connected by process flows with no decisions. There is only one route through this process, from the event, ‘Order ready’, to the outcome, ‘Success -Delivery received’.
Typically this route is referred to as the ‘main path’. It is the most commonly used route through the process.
Another example of a main path is the airline passenger who:
- Has booked in advance.
- Checks in normally (however the airline defines ‘normally’).
- Is allocated a seat.
- Boards.
And all without incident.
The main path is sometimes referred to as the happy path.
We assume that nothing goes wrong on the main path; that’s presumably why it is also referred to as the ‘happy path’. By the end of the flow, the outcome of the overall process will have been realised and everyone will be happy.
Alternative paths and Decisions
Sometimes it is necessary to leave the main path. For example, after receiving a delivery we may optionally want to perform a quality check on the delivered items.
Such points in the flow, where there are branches to alternative paths, are referred to as ‘decisions’.
The symbol for a decision in an activity diagram is a diamond; this is the same notation as for standard flowcharts. Unlike a flowchart, however, there is nothing written inside the diamond. So, how do we know which process flow to follow?
In our example, the decision we need to resolve is:
- ‘Do we need to do a quality check, or can we go straight through to recording the delivery without doing a quality check?’
There are two possible ‘outcomes’ for this decision, i.e.,
- Quality check required.
- Quality check not required.
We write these outcomes (of the decision) inside square brackets, i.e.
- [Quality check required]
- [Quality check not required]
Decision Outcomes written inside square brackets are known as ‘guards’ or ‘guard conditions’.
We draw the guards on the relevant process flows coming out of the decision diamonds. See the diagram, ‘Decision and guards’.
A decision will always have:
- One process flow entering it.
- Two or more process flows leaving it; these ‘exiting’ process flows will be labelled with guards.
Each decision outcome is typically selected based on one or more of the following:
- The result of a previous task.
- The value of an item of data.
- A business rule.
Note that in the above diagram, these decision outcomes are mutually exclusive, i.e. only one of them can be true in any one instance. The process will flow one way OR the other; it cannot go both ways at the same time, i.e.
- If a quality check is not required, the process continues on the happy path to the task, ‘Record Delivery’
- If a quality check is required, the process goes to the task, ‘Check quality’‘
After the task ‘Check quality’, we want the process flow to go to the task, ‘Record delivery’. The diagram below tries to indicate this with the (dotted) arrowed line going from, ‘Check quality’ straight into ‘Record delivery’.
Although many modellers do this, it is not good activity diagramming.
If you are familiar with BPMN, you will know that it would be ok to bring the (sequence) flow into the activity; BPMN works the other way round to UML in this respect.
Important note: Although we have correctly said that this is not good activity diagramming, the BCS publication, Business Analysis, does exactly this. We may therefore assume that you could see this form in your examination.
Remember that in this situation, the flow either goes straight from the decision diamond to, ‘Record delivery’, or it goes via the task, ‘Check quality’; it is one way or the other.
In such, ‘either/or’ situations, it is not correct in activity diagramming to show a process flow going straight from ‘Check quality’ to ‘Record delivery’; you will understand the logic for this rule after reading the section on ‘Concurrent tasks’.
To correctly model the above (‘either/or’) situation, some modelling approaches would merge the process flow from ‘Check Quality’ straight into the process flow between ‘Check quality’ and ‘Record delivery’, as shown in the accompanying diagram.
UML activity diagramming does something very similar to the above approach, but it insists on using an explicit symbol called a merge; this is shown in the diagram below.
You will notice that the merge symbol looks identical to the symbol for a decision. The only difference is that a merge has two or more process flows entering it, and only one process flow leaving it.
Note how the process flow from ‘Check Quality’ rejoins the main flow between ‘Validate Delivery’ and ‘Record Delivery’ via the merge symbol.
This notation indicates that ‘Record Delivery’ will happen whether or not a quality check is required.
Error (Exception) paths
Error paths are a form of alternative path; they indicate where something has gone wrong. For example, suppose an airline passenger has a valid ticket but the airline has overbooked so that no seats are available. For that passenger, something has gone wrong.
Graphically, alternative paths and error paths look identical.
UML does not use the term error path. However, I in real life process modelling, I have always found it useful to distinguish between:
- Alternative paths that are not errors
- For example, different processing for people who have booked tickets in advance and those who haven’t
- Alternative paths that handle situations where something has gone wrong
- For example, where too many many tickets have been sold so that a ticket holder is unable to get what they paid for
What I refer to as, ‘error paths’ are those situations that could prevent a process from achieving its objective(s).
Unless it is possible to correct things during the process, the error flows will lead to what we have already noted as ‘unsuccessful’ or ‘failed’ outcomes.
In the above diagram, labelled ‘Error paths’, if the validation of the delivery fails for some reason, the process is brought to an end; it has failed to reach a successful outcome.
When modelling in real life it is valuable to note the details of the failure on your models.
Modelling multiple decisions in one task.
Remember that the decision diamond simply determines which process flow should be followed next. The information to make that decision is processed inside the task even though the decision diamond is placed outside.
Suppose we have a task that involves more than one decision. For example, a task to process applications for membership to some group. The task may:
- Do a credit check on the applicant.
- Offer applicants who pass the credit check an opportunity to purchase a superior level of membership.
We now need two decision diamonds, both of which are placed outside the task on our process model. This is shown in the diagram, ‘Modelling task with 2 decisions’.
To repeat, the credit checking and upgrade offers happen inside the task but the diamonds are shown outside the task.
In the next module, we look at tasks in more detail. Activity diagrams can be used to model the inside of a task, i.e. the steps of a task. The inside view of the task steps (the task level model) will also show the 2 diamonds.
When we show the same task at the process level, i.e. on a process model, we have to move the diamonds so that they are outside the rectangle representing the task.
Remember that the diamonds don’t do any processing; they just route the work along the process flows.
Use of the keyword, ‘else’.
Instead of using guards on every exit from a decision, it is possible to use the keyword, ‘Else’.
Use of ‘else’ is an option.
Decision outcomes
A decision diamond can have only one process flow going into it. It can have any number of process flows coming out of it.
Each exiting process flow will be labelled with a guard (condition) or with an else statement.
We can refer to the process flows exiting from a decision diamond as ‘decision outcomes’. The term, decision outcome, is not used in the BCS syllabus for Modelling Business Processes but is in common use and is very convenient. It is used in the BCS, Foundation Testing, course.
In the diagram, ‘multiple decision outcomes’, there are three outcomes from the decision diamond.
- Immediate operation needed.
- Scan needed.
- Else.
These outcomes are labelled with the appropriate guard (condition).
Important note for exam
The above hospital scenario has 3 outcomes.
Beware of exam questions that ask, for such a scenario, how many decision diamonds are used to model this.
A multi-choice may as ask you to select the correct number from the following options:
- 3
- 2
- 4
- 1
As you can see from the above example, the correct answer is option, 4, i.e. only 1 decision diamond is required. Such a question is probing your ability to distinguish between distinct, independent decisions, and ‘decision outcomes’ coming from a single decision.
Summary of alternative and error paths
To summarise, we find it useful to distinguish between:
- Alternative paths that represent valid and anticipated variants on the main path such as catering for people with special needs during flight check-in, departures and arrivals. We do not consider these as errors or exceptions.
- Alternative paths that represent error situations such as hotels or flights that are over booked so that there are no rooms or seats left for people with valid bookings. We refer to these as ‘Error’ or ‘Exception’ paths.
This distinction between alternative and error paths is entirely optional; use it only if you or your stakeholders find it useful. The BCS syllabus does not make this distinction. It is not mentioned in the UML Activity Diagram specification.
It is worth noting that in typically complex business processes, it is unlikely that the business analyst will be able to identify all of the alternative or error paths in the time available for analysis; and life has a way of always throwing up another unanticipated exception.
Concurrent (Parallel) tasks
Concurrent tasks are tasks that can take place at the same time as each other. They are sometimes referred to as parallel tasks. More generally, we refer to this sort of situation as concurrent or parallel processing. It is the way in which real business processes operate.
For example, when an order for a new product is received from a customer, the order details are recorded.
Following that, the order may be sent simultaneously to the accounts department and to manufacturing.
Two things should then happen.
- Accounts obtain payment
- Manufacturing builds the product
Because these two tasks are performed by different organisation units, they can be performed independently of each other. We consider this to be ‘concurrent’ or ‘parallel’ processing. We are assuming for this example that the business does not have a rule that says that one of these tasks has to be done before the other.
Note in the diagram the two process flows from the task, ‘Record order’. In this situation, both process flows are followed simultaneously.
There are no guards on either of these process flows. This is because there are no decisions to make. The process flow from Record Order to Build Product and the process flow from Record Order to Obtain Payment always occur; they are not conditional on anything.
Also note that the above diagram is incomplete, i.e. we have not shown the end point(s). We will complete the diagram in the next section, ‘Synchronising concurrent tasks’.
Although concurrent tasks normally imply that more than one actor is involved, i.e. one actor per task, the process modeller can also show two or more tasks as parallel if a single actor performs all of them but strict linear sequence between them is not mandatory, i.e. if the actor can do the tasks in any order.
Proposing that tasks can run in parallel is a common approach to improving the throughput of a process.
Synchronising concurrent tasks
Let us suppose that there is a business rule stating that an item cannot be delivered until it has both been built AND paid for.
In the accompanying diagram, ‘Synchronising parallel tasks’, the task, ‘Deliver ordered product’ cannot start until both ‘Build Item’ AND ‘Obtain Payment’ have completed.
The modeller has indicated this by bringing the flows from ‘Build product’ and ‘Obtain payment’ into ‘Deliver ordered product’. To synchronise parallel tasks, it is necessary to bring the two process flows into the task, Deliver ordered product.
Compare this ‘concurrent processing’ situation with the ‘linear processing’ situation’ depicted in the earlier section, ‘Alternative paths and decisions’.
Linear processing means that only one task at a time can be active, i.e. only one task at a time can be worked on. Following a decision, the process flow goes one way OR the other.
In concurrent (parallel) processing, more than one task can be active at the same time, i.e. it is possible that more than one task can be worked on at the same time. No decisions are involved. All process flows coming out of a single task will be followed simultaneously. This is an AND situation, i.e. ‘task A’ AND ‘task B’ AND possibly other tasks can be worked on at the same time.
Note that the merge symbol is only relevant to linear processing situations, i.e. the OR situation. Remember also that bringing two (or more) process flows into a single task was incorrect in the linear processing situation.
Bringing two (or more) process flows into a single task is the correct way of synchronising flows and tasks in concurrent processing, i.e. in the AND situation.
Read the section on alternative paths again to make sure that you understand the difference between that situation, without concurrent tasks and process flows, and the situation here with concurrent tasks and process flows.
Representing parallel paths with forks and joins.
Fork
So far, I have indicated parallel (concurrent) tasks by having two process flows coming from a single task; see the two process flows coming out of the task, ‘Record order’ in the above diagram. It is possible to have more than two flows from a single task; however many there are, they will all be running in parallel, i.e. at the same time.
An alternative way of showing the start of parallel processing in UML activity diagrams is to use a ‘fork’ symbol.
The fork is the thick line with 2 process flows coming out of it. A fork can have any number of process flows coming out of it.
In this diagram the fork line is horizontal; it can be vertical.
You can easily recognise a fork. It has:
- One process flow going into it.
- Two or more process flows coming out of it.
Any flow coming out of a fork can itself be input to a fork; parallel flows within parallel flows.
Join
Parallel flows can be synchronised, i.e. brought back into a single flow, by simply showing the flows all going into a single task. This is how I have showed synchronisation so far; see the process flows entering the task, ‘Deliver ordered product’ in the above diagram.
An alternative form in UML activity diagrams is to use a ‘join’ symbol.
You easily recognise a join as having two or more process flows entering it and only one flow exiting.
As with a fork, the line representing a join can be drawn vertically.
Fork or not to fork?
You have seen two ways of representing starting and synchronising parallel flows. Choose the one you and your team prefer. Having chosen your preferred style, keep to it to avoid confusion.
Case study.
The course has a case study exercise at this point.
The exercise involves creating an activity diagram based on a comprehensive scenario.
The exercise is not included in this preview.
Quick Quiz
This quick quiz is to check your understanding of the lesson.
Up to 4 possible answers appear in text boxes below the question.
Click the answer that you believe to be correct.
You will not get an immediate answer. Click the button labelled, ‘Next question’ that is situated below the answers.
Important: If you click ‘Next question’ before you click an answer, the quiz will move on to the next question. You will not be advised that you have not clicked an answer. The quiz will give a score based on the number of questions you actually answered.
If the quiz does not move on to the next question, refresh the page and try again.
You cannot return to a previous question.
After you have answered the 5th and final question, the button label will read, “See my score”. Click this to see your score. Your score will appear on this page.
You will also be able to download a PDF version of the quiz and the annotated answers.
After completing the quiz, you may refresh the page and have another go.
