UML Use Case and BPMN Business Process Consistency Verification Tool

BPMN vs UML

In software development, business analysts model processes in BPMN while system architects define functional requirements through UML use cases. The catch is that these two models operate at different levels of abstraction — they can't be directly compared. Verifying by hand whether a business process actually delivers what a use case describes is tedious and error-prone.

A literature review revealed that while there have been attempts to convert between the two notations (Lubke et al. proposed visualizing use cases as BPMN processes; Bouzidi et al. explored the reverse direction), nobody has offered a tool for consistency verification between existing diagrams of both types.

I built a tool that automates this process: it transforms both diagram types into graph structures and compares them using a custom algorithm, producing a consistency report.

Use Case vs. Use Case Diagram

These two things are easy to confuse, so it's worth clarifying. A use case is a textual description of an actor's interaction with a system — a sequence of steps organized into a main scenario and alternative scenarios. For an ATM, for example:

• Main scenario: cash withdrawal
  1. Customer inserts card into the ATM
  2. ATM displays the main menu
  3. Customer selects withdrawal
  4. ATM prompts for the amount
  5. ...
• Alternative scenario: Insufficient funds (starts at step 5, rejoins at step 8)
  1. Bank refuses authorization

A use case diagram is the graphical counterpart — ovals (use cases), actors, and relationships between them (association, <<include>>, <<extend>>). A single diagram may contain many use cases, but it doesn't describe steps — it's a map of system functionality, not a procedure.

This tool works with use cases (concrete steps and scenarios), not with use case diagrams.

How It Works

The pipeline has three stages: converting diagrams to graphs, running the consistency algorithm, and generating the report.

1. Converting Diagrams to Graphs

Source BPMN (XML) and UML/XMI files are parsed and converted into directed graphs.

BPMN → Graph: Every event and task becomes a node; sequence flows become edges. Below is an example BPMN diagram and the resulting graph:

The information needed to reconstruct the graph lives inside the bpmn:process element in the XML. Each element has a unique id and bpmn:incoming/bpmn:outgoing children that hold flow identifiers — enough to rebuild the full structure.

UML (use cases) → Graph: Steps in the main scenario form the main path (nodes connected in sequence). Alternative scenarios are attached as branches — their start and end points connect back to the appropriate steps in the main scenario, as specified by extension elements with guid and join attributes in the XMI file.

2. Consistency Algorithm

Consistency is measured by two independent metrics.

Step consistency — does every step in the use case have a corresponding task in BPMN?

where \(V_A\) is the set of nodes in the use case graph and \(V_B\) in the BPMN graph. A step and a task are considered matching if their names are identical. BPMN, being a more detailed description, may contain extra tasks — that's fine, as long as every use case step is covered.

Path consistency — does every path (scenario) in the use case also appear in the business process?

The algorithm finds all paths in the BPMN graph (from start to end), removes nodes not present in the use case graph, and checks for isomorphism between the simplified BPMN paths and the use case paths.

The final score is the arithmetic mean of both metrics:

3. Report

The tool generates a Markdown report containing the consistency metrics, a list of missing nodes, and a list of missing paths.

Step-by-Step Example

Consider a use case with five steps in the main scenario and two alternative scenarios:

• Main scenario:
  1. A
  2. B
  3. C
  4. E
  5. F
• Alternative scenario 1 (starts at step 3, rejoins at step 4):
  1. G
• Alternative scenario 2 (starts at step 3, rejoins at step 4):
  1. D

And the corresponding business process:

After conversion we get two graphs:

Step Consistency

We look for shared nodes. In graph A, node "G" is highlighted in red — it has no counterpart in graph B:

In graph B, nodes shared with graph A are highlighted in orange:

Path Consistency

The algorithm finds all paths in graph B and marks the nodes they share with graph A:

After removing the extra nodes (shown in blue), we compare with the three paths in graph A:

Path 3 (A → B → G → E → F) has no isomorphic counterpart in graph B, because node "G" doesn't exist in the business process. Therefore:

Final Score

Generated report:

The tool correctly identified the missing node "G" and the path that cannot be reproduced.

Case Study: ATM System

To validate the tool's practical usefulness, I designed a complete ATM system with four functions: user authorization, cash deposit, cash withdrawal, and balance inquiry. For each function I created UML use cases and corresponding BPMN processes, then deliberately introduced inconsistencies to see whether the tool would catch them.

The ATM requires authorization before every operation, so "PIN Verification" is a separate use case linked to the others via an <<include>> relationship. Each use case has a separate definition for the customer and for the bank — this follows from the assumption that one use case is compared against one BPMN process, which doesn't split into pools.

I ran four test scenarios.

Full Consistency

The "PIN Verification" use case compared against a business process that fully implements it — but also contains extra tasks and paths (e.g. handling a card read error and a connection failure).

• Main scenario: PIN Verification
  1. Card is inserted into the ATM
  2. ATM prompts for PIN
  3. ATM sends a PIN verification request to the bank
  4. Bank verifies the PIN
  5. Bank confirms the PIN is correct
  6. ATM notifies the customer of successful authorization
• Alternative scenario: Wrong PIN (starts at step 5, rejoins at end)
  1. Bank reports incorrect PIN
  2. ATM displays an incorrect PIN message
  3. ATM returns the card

Business process:

The tool correctly recognized 100% consistency despite the extra elements in the BPMN:

Missing Path Consistency

The "Withdrawal Handling" use case compared against a BPMN process where one task is in the wrong place — causing one of the paths to have no coverage.

• Main scenario: Withdrawal Handling
  1. ATM displays the main menu
  2. Customer selects cash withdrawal
  3. ATM prompts for the amount
  4. ATM asks the bank to verify fund availability
  5. Bank authorizes the withdrawal
  6. Bank updates the customer's account balance
  7. ATM dispenses banknotes
  8. ATM prints a receipt
  9. ATM returns the card
• Alternative scenario: Insufficient funds (starts at step 5, rejoins at step 8)
  1. Bank refuses authorization

Business process:

The tool pinpointed exactly which path (the "Insufficient funds" alternative scenario) cannot be reproduced in the business process.

Missing Step Consistency

The "Withdrawal" use case compared against a BPMN process where the task "Customer collects cash and receipt" was deliberately omitted.

• Main scenario: Withdrawal
  1. Customer selects withdrawal
  2. ATM prompts for the amount
  3. Customer enters the amount
  4. ATM sends a withdrawal request to the bank
  5. ATM receives a positive decision
  6. ATM prints a transaction receipt
  7. Customer collects cash and receipt
  8. ATM returns the card
  9. Customer collects the card
• Alternative scenario: Insufficient funds (starts at step 5, rejoins at step 8)
  1. ATM receives a negative decision
  2. ATM displays an insufficient funds message

Business process:

The absence of one step cascaded into a missing path — the main scenario passing through that step couldn't be reproduced. The tool correctly flagged both the missing node and the missing path.

No Consistency

The "PIN Verification" use case compared against the BPMN process for withdrawal handling — two entirely different processes. The only shared node turned out to be "ATM returns the card" (which appears in both).

Case Study Conclusions

In all four scenarios the tool correctly identified gaps and pointed to the specific missing elements. Notably, it handles BPMN redundancy gracefully (full consistency despite extra tasks and paths) and detects cascade effects — a missing step automatically causes the path running through it to be flagged as missing too.

Tech Stack

• Python 3 — algorithm implementation and file parsing
• ElementTree — XML processing (BPMN and XMI)
• NetworkX — graph representation and analysis (path traversal, isomorphism)

Limitations

The current version has a few simplifications: it only supports basic BPMN elements (start/end events, XOR gateways, sequence flows); input processes cannot use pools or swimlanes, and task types are not distinguished; step consistency relies on exact name matching with no semantic analysis; and one use case is compared against one business process at a time.

If I were to develop this further, I'd focus on full BPMN symbol support, semantic name matching (e.g. using embeddings), and the ability to handle multiple use cases simultaneously.

References

• Project repository
• BPMN Specification
• UML Specification
• NetworkX — Python graph library