Skip to content
Software Architecture Guide

Process Notations Comparison (EPC, BPMN, UML Activity Diagram)

Explanation

Section titled “Explanation”

A process notation is a set of symbols and rules for drawing how work flows. Three are common: the Event-driven Process Chain (EPC), the UML activity diagram, and BPMN. See the articles “BPMN 2.0 Notation” and “Unified Modeling Language (UML)” for background.

EPC. Researchers at Saarland University developed it in 1992, with SAP, as part of ARIS. It has functions, which are active elements, and events, which are passive and drawn as hexagons. Connectors (XOR, AND, and OR) split and join branches. Events and functions strictly alternate: an event triggers one function, and a function leads to one event. A chain starts and ends with an event. EPC has only five control-flow elements, while BPMN has over a hundred modeling constructs.

BPMN. Its basic building blocks are tasks, which are small units of work. Gateways route the flow. An exclusive gateway picks one path based on data. A parallel gateway forks paths that run side by side. BPMN is also an XML document with a visual form, and workflow engines can interpret it. That supports execution.

UML activity diagram. It uses actions and decisions. Bars mark where concurrent activities fork and join. Object nodes carry data between actions along object flows.

Mapping.

Idea EPC UML activity BPMN
Unit of work Function Action Task
Something that happens Event not covered here Event
Choice or parallel split Connector Decision, fork and join bars Gateway

Responsibilities need a separate decision: keep them as roles or turn them into lanes.

Converting EPC to BPMN.

  • Functions become tasks, events stay events, and connectors become gateways.
  • A data-based EPC XOR decision matches the exclusive gateway, which also chooses by data.
  • Scheer’s tool converts by predefined rules. The result may need manual correction.
  • Practitioners who converted about 120 EPCs found many unnecessary intermediate events. EPC events are often meaningless when translated directly.

Example

Section titled “Example”

A team has an EPC for handling an order. It reads: event “Order received”, function “Check order”, event “Order checked”, function “Ship order”. Converting it directly gives a BPMN start event, a task, an intermediate event, and another task. The middle event “Order checked” only restates that the task finished. The team removes it and connects the two tasks directly. They also decide whether the EPC roles become lanes.

Trade-offs

Section titled “Trade-offs”

EPC is simple, with few control-flow elements, but that is also its limit. BPMN offers far more constructs, so it costs more to learn. In return, it can be interpreted by workflow engines. Automatic conversion saves effort but does not remove the need for manual review. Direct translation of EPC events tends to clutter the BPMN model.

An EPC order chain converted to BPMN: the redundant middle event is dropped.

Diagram source 
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" targetNamespace="http://example.com/bpmn">
  <process id="order" isExecutable="false">
    <startEvent id="start" name="Order received">
      <outgoing>f1</outgoing>
    </startEvent>
    <task id="check" name="Check order">
      <incoming>f1</incoming>
      <outgoing>f2</outgoing>
    </task>
    <task id="ship" name="Ship order">
      <incoming>f2</incoming>
      <outgoing>f3</outgoing>
    </task>
    <endEvent id="end" name="Order shipped">
      <incoming>f3</incoming>
    </endEvent>
    <sequenceFlow id="f1" sourceRef="start" targetRef="check" />
    <sequenceFlow id="f2" sourceRef="check" targetRef="ship" />
    <sequenceFlow id="f3" sourceRef="ship" targetRef="end" />
  </process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_order">
    <bpmndi:BPMNPlane id="BPMNPlane_order" bpmnElement="order">
      <bpmndi:BPMNShape id="BPMNShape_start" bpmnElement="start">
        <dc:Bounds x="80" y="102" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="68" y="143" width="60" height="28" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="BPMNShape_check" bpmnElement="check">
        <dc:Bounds x="216" y="80" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="BPMNShape_ship" bpmnElement="ship">
        <dc:Bounds x="416" y="80" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="BPMNShape_end" bpmnElement="end">
        <dc:Bounds x="616" y="102" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="608" y="143" width="53" height="28" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="BPMNEdge_f1" bpmnElement="f1">
        <di:waypoint x="116" y="120" />
        <di:waypoint x="216" y="120" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="BPMNEdge_f2" bpmnElement="f2">
        <di:waypoint x="316" y="120" />
        <di:waypoint x="416" y="120" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="BPMNEdge_f3" bpmnElement="f3">
        <di:waypoint x="516" y="120" />
        <di:waypoint x="616" y="120" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</definitions>

Checks

Section titled “Checks”
  • When EPC models are converted to BPMN, the result is reviewed for unnecessary intermediate events.
  • The conversion mapping is stated: functions to tasks, events to events, connectors to gateways.
  • The document states whether EPC roles become BPMN lanes or remain roles.
Section titled “Related”

Sources

Section titled “Sources”