BPMN vs UML

W procesie wytwarzania oprogramowania analitycy biznesowi modelują procesy w notacji BPMN, a architekci systemu definiują wymagania funkcjonalne za pomocą przypadków użycia UML. Problem polega na tym, że oba modele operują na różnych poziomach abstrakcji i nie da się ich ze sobą bezpośrednio porównać. Ręczna weryfikacja, czy proces biznesowy faktycznie realizuje to, co opisuje przypadek użycia, jest czasochłonna i podatna na błędy.

Przegląd literatury pokazał, że choć istnieją próby konwersji między tymi notacjami (np. Lubke et al. proponowali wizualizację przypadków użycia jako procesów BPMN, Bouzidi et al. badali odwrotny kierunek), nikt dotąd nie zaproponował narzędzia do weryfikacji zgodności między istniejącymi diagramami obu typów.

Stworzyłem narzędzie, które automatyzuje ten proces — przekształca oba typy diagramów w struktury grafowe, a następnie porównuje je za pomocą autorskiego algorytmu, generując raport zgodności.

Przypadek użycia vs diagram przypadków użycia

Warto rozróżnić dwie rzeczy, bo łatwo je pomylić. Przypadek użycia (use case) to tekstowy opis interakcji aktora z systemem — lista kroków pogrupowana w scenariusz główny i scenariusze alternatywne. Przykładowo dla bankomatu:

  • Scenariusz podstawowy: wypłata gotówki
    1. Klient umieszcza kartę w bankomacie
    2. Bankomat wyświetla menu główne
    3. Klient wybiera opcję wypłaty
    4. Bankomat prosi o wprowadzenie kwoty
    5. ...
  • Scenariusz alternatywny: Brak środków (początek: krok 5, złączenie: krok 8)
    1. Bank odmawia autoryzacji wypłaty

Diagram przypadków użycia to graficzna reprezentacja — owale (przypadki użycia), aktorzy i relacje między nimi (asocjacja, <<include>>, <<extend>>). Jeden diagram może zawierać wiele przypadków użycia, ale sam nie opisuje kroków — jest mapą funkcjonalności systemu, nie instrukcją.

Moje narzędzie pracuje na przypadkach użycia (konkretnych krokach i scenariuszach), nie na diagramach przypadków użycia.

Jak to działa?

Cały pipeline składa się z trzech etapów: konwersja diagramów na grafy, algorytm zgodności i generowanie raportu.

1. Konwersja diagramów na grafy

Pliki źródłowe BPMN (XML) oraz UML/XMI są parsowane i zamieniane na grafy skierowane.

BPMN → Graf: Każde zdarzenie i zadanie staje się wierzchołkiem, przepływy sekwencyjne stają się krawędziami. Poniżej przykład prostego diagramu BPMN i wynikowego grafu:

Przykładowy diagram BPMN przed parsowaniem Graf skierowany utworzony na podstawie diagramu BPMN

Informacje potrzebne do zbudowania grafu znajdują się w pliku XML wewnątrz elementu bpmn:process. Każdy element posiada unikalne id oraz elementy bpmn:incoming i bpmn:outgoing zawierające identyfikatory przepływów — to wystarczy, żeby odtworzyć strukturę grafu.

UML (przypadki użycia) → Graf: Kroki scenariusza podstawowego tworzą ścieżkę główną (kolejne wierzchołki połączone krawędziami). Scenariusze alternatywne są dołączane jako rozgałęzienia — początek i koniec alternatywnej ścieżki łączy się z odpowiednimi krokami w scenariuszu głównym, zgodnie z definicją w pliku XMI (elementy extension z atrybutami guid i join).

Graf utworzony na podstawie przykładowego przypadku użycia

2. Algorytm zgodności

Zgodność jest mierzona dwoma niezależnymi metrykami.

Zgodność kroków — czy każdy krok z przypadku użycia ma swoje odzwierciedlenie jako zadanie w BPMN:

\[C_n(A,B) = \frac{|V_A \cap V_B|}{|V_A|} \cdot 100\%\]

gdzie \(V_A\) to zbiór wierzchołków grafu przypadku użycia, a \(V_B\) grafu BPMN. Krok i zadanie uznaje się za zgodne, jeśli ich nazwy są identyczne. BPMN jako bardziej szczegółowy opis może zawierać nadmiarowe zadania — to jest dopuszczalne, ważne, żeby wszystkie kroki z przypadku użycia były pokryte.

Zgodność ścieżek — czy każda ścieżka (scenariusz) z przypadku użycia występuje również w procesie biznesowym:

\[C_p(A,B) = \frac{|I|}{|A|} \cdot 100\%\]

Algorytm znajduje wszystkie ścieżki w grafie BPMN (od startu do końca), usuwa z nich wierzchołki nadmiarowe (te które nie występują w grafie przypadku użycia), a następnie sprawdza izomorfizm między tak uproszczonymi ścieżkami BPMN a ścieżkami przypadku użycia.

Wynikowy współczynnik to średnia arytmetyczna obu metryk:

\[C(A,B) = \frac{C_p(A,B) + C_n(A,B)}{2}\]

3. Raport

Narzędzie generuje raport w formacie Markdown zawierający metryki zgodności, listę brakujących wierzchołków i listę brakujących ścieżek.

Przykład krok po kroku

Weźmy przypadek użycia z pięcioma krokami w scenariuszu głównym i dwoma scenariuszami alternatywnymi:

  • Scenariusz podstawowy:
    1. A
    2. B
    3. C
    4. E
    5. F
  • Scenariusz alternatywny 1 (początek: krok 3, złączenie: krok 4):
    1. G
  • Scenariusz alternatywny 2 (początek: krok 3, złączenie: krok 4):
    1. D

Oraz odpowiadający mu proces biznesowy:

Przykładowy proces biznesowy BPMN

Po konwersji otrzymujemy dwa grafy:

Przykładowy diagram BPMN przed parsowaniem Graf skierowany utworzony na podstawie diagramu BPMN

Zgodność kroków

Szukamy wierzchołków wspólnych. Na grafie A kolorem czerwonym zaznaczony jest wierzchołek "G", który nie ma pokrycia w grafie B:

Graf A z zaznaczonym brakującym wierzchołkiem

Na grafie B pomarańczowym kolorem zaznaczono wierzchołki wspólne z grafem A:

Graf B z zaznaczonymi wspólnymi wierzchołkami

\[C_n(A,B) = \frac{|V_A \cap V_B|}{|V_A|} = \frac{6}{7}\]

Zgodność ścieżek

Algorytm znajduje wszystkie ścieżki w grafie B i zaznacza na nich wierzchołki wspólne z grafem A:

Przykładowy diagram BPMN przed parsowaniem Graf skierowany utworzony na podstawie diagramu BPMN

Po usunięciu nadmiarowych wierzchołków (niebieskich) porównujemy z trzema ścieżkami grafu A:

Przykładowy diagram BPMN przed parsowaniem Graf skierowany utworzony na podstawie diagramu BPMN Graf skierowany utworzony na podstawie diagramu BPMN

Dla ścieżki nr 3 (A → B → G → E → F) nie istnieje izomorficzna ścieżka w grafie B, bo wierzchołek "G" nie występuje w procesie biznesowym. Zatem:

\[C_p(A,B) = \frac{2}{3}\]

Wynik

\[C(A,B) = \frac{\frac{6}{7} + \frac{2}{3}}{2} \approx 0.76\]

Wygenerowany raport:

Wygenerowany raport zgodności

Narzędzie poprawnie wskazało brakujący wierzchołek "G" oraz ścieżkę, której nie da się odtworzyć.

Studium przypadku: system bankomatu

Aby zweryfikować praktyczną użyteczność narzędzia, zaprojektowałem kompletny system bankomatu z czterema funkcjami: autoryzacja użytkownika, wpłata gotówki, wypłata gotówki i sprawdzenie salda. Dla każdej funkcji stworzyłem przypadki użycia UML i odpowiadające im procesy biznesowe BPMN, a następnie celowo wprowadzałem niespójności, żeby sprawdzić, czy narzędzie je wykryje.

Diagram przypadków użycia bankomatu

Bankomat wymaga autoryzacji przed każdą operacją, dlatego "Sprawdzenie PIN" jest osobnym przypadkiem użycia połączonym z pozostałymi relacją zawierania (<<include>>). Każdy przypadek użycia ma osobną definicję dla klienta i dla banku — wynika to z założenia, że jeden przypadek użycia jest porównywany z jednym procesem BPMN, który nie dzieli się na baseny.

Przeprowadziłem cztery scenariusze testowe.

Pełna zgodność

Przypadek użycia "Sprawdzenie PIN" porównany z procesem biznesowym, który go w pełni realizuje — ale zawiera też nadmiarowe zadania i ścieżki (np. obsługę błędu odczytu karty i błędu nawiązywania połączenia).

  • Scenariusz podstawowy: Sprawdzenie PIN
    1. Karta zostaje umieszczona w bankomacie
    2. Bankomat prosi o podanie PIN
    3. Bankomat wysyła zapytanie do banku, czy PIN poprawny
    4. Bank weryfikuje poprawność PIN
    5. Bank potwierdza poprawność PIN
    6. Bankomat informuje o autoryzacji zakończonej pomyślnie
  • Scenariusz alternatywny: Zły PIN (początek: krok 5, złączenie: koniec)
    1. Bank informuje o błędnym PIN
    2. Bankomat pokazuje komunikat o niepoprawnym PIN
    3. Bankomat oddaje kartę

Proces biznesowy:

Proces biznesowy sprawdzenia PIN

Narzędzie poprawnie rozpoznało 100% zgodność mimo nadmiarowych elementów w BPMN:

Raport zgodności dla sprawdzenia PIN

Metryka Wynik
Zgodność kroków 100%
Zgodność ścieżek 100%
Wynikowy współczynnik 100%
Wierzchołki (use case / BPMN / wspólne) 9 / 17 / 9
Ścieżki (use case / BPMN / wspólne) 2 / 4 / 2

Brak zgodności ścieżek

Przypadek użycia "Obsługa wypłaty" porównany z procesem BPMN, w którym jedno zadanie jest na niewłaściwym miejscu — przez co jedna ze ścieżek nie ma pokrycia.

  • Scenariusz podstawowy: Obsługa wypłaty
    1. Bankomat wyświetla menu główne
    2. Klient wybiera opcję wypłaty gotówki
    3. Bankomat prosi o wprowadzenie kwoty
    4. Bankomat prosi bank o weryfikację dostępności środków
    5. Bank autoryzuje wypłatę
    6. Bank aktualizuje stan konta użytkownika
    7. Bankomat wydaje banknoty
    8. Bankomat drukuje potwierdzenie
    9. Bankomat oddaje kartę
  • Scenariusz alternatywny: Brak środków (początek: krok 5, złączenie: krok 8)
    1. Bank odmawia autoryzacji wypłaty

Proces biznesowy:

Proces biznesowy obsługi wypłaty z błędem w ścieżce

Metryka Wynik
Zgodność kroków 100%
Zgodność ścieżek 50%
Wynikowy współczynnik 75%
Brakujące ścieżki 1

Narzędzie wskazało dokładnie, którą ścieżkę (scenariusz alternatywny "Brak środków") nie da się odtworzyć w procesie biznesowym.

Brak zgodności kroków

Przypadek użycia "Wypłata" porównany z procesem BPMN, w którym celowo pominięto zadanie "Klient odbiera gotówkę i potwierdzenie".

  • Scenariusz podstawowy: Wypłata
    1. Klient wybiera opcję wypłaty
    2. Bankomat prosi o podanie kwoty
    3. Klient wprowadza kwotę
    4. Bankomat wysyła żądanie wypłaty do banku
    5. Bankomat odbiera pozytywną decyzję
    6. Bankomat drukuje potwierdzenie transakcji
    7. Klient odbiera gotówkę i potwierdzenie
    8. Bankomat zwraca kartę
    9. Klient odbiera kartę
  • Scenariusz alternatywny: Brak środków (początek: krok 5, złączenie: krok 8)
    1. Bankomat odbiera negatywną decyzję
    2. Bankomat wyświetla komunikat o braku środków

Proces biznesowy:

Proces biznesowy wypłaty z brakującym krokiem

Metryka Wynik
Zgodność kroków 91%
Zgodność ścieżek 50%
Wynikowy współczynnik 70%
Brakujące wierzchołki 1
Brakujące ścieżki 1

Brak jednego kroku pociągnął za sobą brak jednej ścieżki — scenariusz główny przechodzący przez ten krok nie mógł być odtworzony. Narzędzie poprawnie wskazało zarówno brakujący wierzchołek, jak i ścieżkę.

Całkowity brak zgodności

Przypadek użycia "Sprawdzenie PIN" porównany z procesem BPMN odpowiadającym obsłudze wypłaty — czyli dwa zupełnie różne procesy. Jedynym wspólnym wierzchołkiem okazało się "Bankomat oddaje kartę" (występuje w obu).

Metryka Wynik
Zgodność kroków 11%
Zgodność ścieżek 0%
Wynikowy współczynnik 6%
Brakujące wierzchołki 8
Brakujące ścieżki 2

Wnioski z case study

We wszystkich czterech scenariuszach narzędzie poprawnie zidentyfikowało braki i wskazało konkretne brakujące elementy. Co ważne, radzi sobie zarówno z nadmiarowością w BPMN (pełna zgodność mimo dodatkowych zadań i ścieżek), jak i z wykrywaniem kaskadowych efektów — brak jednego kroku automatycznie powoduje brak ścieżki, która przez niego przechodzi.

Stack technologiczny

  • Python 3 — implementacja algorytmów i parsowanie plików
  • ElementTree — przetwarzanie plików XML (BPMN i XMI)
  • NetworkX — reprezentacja i analiza struktur grafowych (przeszukiwanie ścieżek, izomorfizm)

Ograniczenia

Narzędzie w obecnej wersji ma kilka uproszczeń:
- Obsługuje tylko podstawowe elementy BPMN (zdarzenie startowe/końcowe, bramka XOR, przepływ sekwencyjny)
- Procesy wejściowe nie mogą zawierać podziału na baseny i tory — nie rozróżnia też typów zadań
- Zgodność kroków opiera się na identyczności nazw (bez analizy semantycznej)
- Jeden przypadek użycia jest porównywany z jednym procesem biznesowym

Gdybym miał to rozwijać dalej, skupiłbym się na wsparciu pełnego zestawu symboli BPMN, analizie semantycznej nazw kroków (np. z użyciem embeddingów) oraz możliwości pracy z wieloma przypadkami użycia jednocześnie.

Źródła