Simon Perry MBCS CITP, a systems consultant at Brass Bullet makes a framework-based comparison of UML and BPMN.


Process modelling is arguably one of the most important aspects of any organisation in terms of the management and control of all of the organisational activities. But how should such processes be modelled?

This article discusses the need for modelling in the context of a process modelling framework, and goes on to compare two widely used modelling notations, the unified modelling language (UML) and the business process modelling notation (BPMN).

The need for a framework

In order to fully specify any process, a number of different concepts must be realised. It is not sufficient just to model the flow of a process; various structural aspects (such as the stakeholders involved, the artefacts produced and consumed, the nomenclature used and the basic contents of each process), and behavioural aspects (such as the flow of the process and the requirements for the process) have to be captured.

The simplest way to model a process and ensure that all the required information is captured is to use a process modelling framework to guide the modelling. Such a framework defines a number of structural and behavioural views of the information that comprises the process.

One such approach is a 7-view framework that has been adopted by the BSi - the national standards body for the UK. (Full details of the framework be found in Jon Holt's A Pragmatic Guide to Business Process Modelling.)

The seven views defined by this framework are:

  1. Requirements view - captures the requirements of the process and the stakeholders involved
  2. Information view - captures the artefacts (deliverables) that are produced and consumed by the process, and also shows the relationships between the artefacts
  3. Stakeholder view - captures the stakeholders involved in the process
  4. Process structure view - captures the structure and terminology of the process; forms the basis for any kind of mapping between different processes and standards, which is important when performing audits and assessments
  5. Process content view - defines the content of a process in terms of the artefacts and activities that make up that process
  6. Process behavioural view - defines the behaviour of the process: how the activities are sequenced, the artefacts entering and leaving the activities and the stakeholders involved in the process
  7. Process instance view - captures a sequence of processes and defines a scenario that can be used to verify the requirements of the process.

Only when all seven views have been realised can it be assumed that the process has been completely specified.

Realising framework views

Having defined a framework to use when process modelling, it makes sense to use a modelling notation that is sufficiently rich and expressive to allow all views to be realised within that notation.

It is possible to mix notations, but this can lead to increased cost and effort in modelling (and maintaining) a process: different notations have to be learned and understood, multiple tools may be required, the notations may be sufficiently different that performing consistency checks between views becomes difficult.

Two common notations used for process modelling are the UML and the BPMN. The UML is a rich and powerful general-purpose modelling notation that was originally developed for designing and specifying software-intensive systems, but which is being increasingly used in other areas such as systems engineering (see Holt's UML for Systems Engineering: watching the wheels).

The BPMN is a modelling notation aimed specifically at business process modelling.

So how do the two notations compare? The table below compares the suitability of the two notations in realising each of the views in the 7-view framework.

BPMN 7 View Framework

Process modelling with UML

As can be seen in the table above, it is possible to realise all of the seven views using a subset of UML and, hence, to fully model a process.

Process modelling with BPMN

The BPMN defines a single diagram (the business process diagram) but has no concept of structural modelling or requirements and therefore these aspects of a process can not be realised using BPMN. Thus the BPMN realises two of the views very well, but five of the views not at all, resulting in an incomplete picture of a process.


Process modelling should be undertaken in the context of a process framework that defines a number of views that are used to realise different structural and behavioural aspects of the process. One possible approach is the 7-view framework described above.

When using a process framework to describe a process it makes sense to use a notation that is sufficiently rich and expressive to represent all views of the framework. This avoids the need for different notations for different views.

UML and BPMN can be compared for effectiveness in realising the process framework. UML can represent all of the seven views considered.

However BPMN has no direct support for structural views and no concept of modelling requirements. As a result BPMN can only fully represent two views and therefore is not sufficiently rich and expressive to capture all the defined views. BPMN alone is therefore not suitable for the complete modelling of a process.

Of particular concern with BPMN is its inability to model the requirements view. Not only does this view supply the aims for the process but it is also essential for validating the process. That is, for ensuring that the process actually achieves what it is supposed to. If the requirements for the process are not known, then how can it be validated? It can't.

In addition requirements change over time. If these changes are not captured then the process is no longer valid. Only by capturing, maintaining, and periodically re-validating can the process remain current and useful. For this, having the requirements of the process captured as part of the process model is vital.

Further reading

A Pragmatic Guide to Business Process Modelling, Jon Holt
UML for Systems Engineering: watching the wheels, Jon Holt