This website or its third-party tools use cookies which are necessary to its functioning and required to improve your experience. By clicking the consent button, you agree to allow the site to use, collect and/or store cookies.
Please click the consent button to view this website.
I accept
Deny cookies Go Back

Business analysis training courses, e-training and consulting

Business analysis training and consultancy: Bespoke and ready made online e-training and classroom courses for business analysts.

  • Home
  • BA Training
    • Learning business analysis
    • Essential skills
    • E-learning examples
    • Free training for business analysts
  • Courses
    • Shop for courses
    • My courses
    • Free training for business analysts
    • FAQs
  • Blog
  • About
    • Clients
    • Contact

Preview – UML Activity Diagrams Notation

Video – Overview of lesson

Video - Overview of lesson

https://capiro.co.uk/mp-files/video-mbp-m3l2-activity-diagrams-notation-v0-1.mp4/?stream=true&file=video-mbp-m3l2-activity-diagrams-notation-v0-1.mp4

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

Swimlanes and actors
Swimlanes and actors

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

Swimlanes - Start and end points
Swimlanes – 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 in swim lanes
Tasks in swim lanes

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

Process flows on the main path
Process flows on the main path

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:

  1. Has booked in advance.
  2. Checks in normally (however the airline defines ‘normally’).
  3. Is allocated a seat.
  4. 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’.

Decision symbol is a diamond

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.,

  1. Quality check required.
  2. Quality check not required.

We write these outcomes (of the decision) inside square brackets, i.e.

  1. [Quality check required]
  2. [Quality check not required]

Decision Outcomes written inside square brackets are known as ‘guards’ or ‘guard conditions’.

Decision and guards
Decision and guards

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’
Quality check not required
Quality check not required
  • If a quality check is required, the process goes to the task, ‘Check quality’‘
Activity diagram showing decisions and guards
Quality check required

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’.

Incorrect way of merging
Incorrect way of merging

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.

Merging into the main path

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.

Using the ‘merge’ symbol

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
Error paths

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’.

Activity diagram showing how to model a task that includes 2 decisions
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.

Use of keyword ELSE
Use of keyword ELSE

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.

Multiple decision outcomes
Multiple decision outcomes

In the diagram, ‘multiple decision outcomes’, there are three outcomes from the decision diamond.

  1. Immediate operation needed.
  2. Scan needed.
  3. 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:

  1. 3
  2. 2
  3. 4
  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.

Concurrent (parallel) tasks

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.

  1. Accounts obtain payment
  2. 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.

Synchronising parallel tasks

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.

Parallel flows initiated with a fork symbol
Parallel flows initiated with 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.

Synchronising parallel flows with a join symbol
Synchronising parallel flows with 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.

Download case study and exercise
Case study – Process Model Part 2


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.

BCS MBP Quiz 15 M3L2 Activity Diagrams

Question 1 of 5 (20%)

When will Task D be instantiated?

Question 2 of 5 (40%)

When does Task F get instantiated:

Question 3 of 5 (60%)

When does Task E start:

Question 4 of 5 (80%)

Which of the following is correct?

Question 5 of 5 (100%)

In the diagram below, when do items stop being unloaded:

Print Friendly, PDF & Email

Guide to Success training – Features and Benefits

Be among the first to hear about a new course.

Grab it at the early bird price.

Keep informed about special launch prices

Recent Posts

  • What is a non-functional requirement?
  • Online business analysis training courses
  • Is e-learning the future until the pandemic is over?

Search Form

© 2021 Capiro Ltd - Members: Log in

Privacy Policy