Łączne użycie UML i BPMN w projekcie informatycznym zapewnia komplementarne podejście do modelowania zarówno aspektów technicznych, jak i biznesowych systemu. UML skupia się na strukturze i działaniu systemu informatycznego, podczas gdy BPMN koncentruje się na procesach biznesowych i ich przepływie. Dzięki temu, możliwe jest kompleksowe ujęcie przedsięwzięcia, uwzględniając zarówno wymagania biznesowe, jak i techniczne. Wykorzystanie obu notacji wspiera precyzyjne zrozumienie i komunikację potrzeb biznesowych, co powinno się przełożyć na skuteczniejsze projektowanie i implementację systemów informatycznych. Tyle mówi teoria a praktyka nie do końca podąża za teorią. Dlaczego? Otóż po pierwsze stosowanie notacji wymusza zachowania standardów pracy, precyzji wyrażanych myśli. Pomaga walczyć z byle jakością. Z drugiej strony, przykładowo UML pojawił się w grudniu 1997 i do dziś nie przeszedł reformy, a przecież złożoność projektów zmieniała się radykalnie. W tym artykule postaram się, podobnie jak to było w tekście ArchiMate w praktyce zaprezentować konkretne przykłady wspólnego użycia UML i BPMN.
Przedstawione w artykule, modele te mają przykładowy charakter. W każdej organizacji w zależności od: potrzeb, jej sytuacji oraz sposobu wytwarzania oprogramowania, modele mogą wyglądać trochę inaczej. W razie pytań zapraszam do kontaktu.
W artykule posłużę się przykładem sklepu internetowego, w którym można nabyć szkolenie internetowe. Przykład jest nie jest skomplikowany merytorycznie, jednocześnie jest niemal rzeczywistym przedsięwzięciem. Zacznijmy od celu przedsięwzięcia.
Cel przedsięwzięcia
Cel przedsięwzięcia to stan lub warunki jakie musi spełnić organizacja by osiągnąć plan zdefiniowany w wizji. W naszym przypadku celem przedsięwzięcia jest stworzenie sklepu internetowego, który umożliwi użytkownikom zakup i dostęp do szkoleń online. Sklep będzie oparty na platformie WooCommerce, co zapewni elastyczność i skalowalność rozwiązania. Integracja z bramką płatności Przelewy24 zapewni bezpieczne i różnorodne metody płatności, natomiast współpraca z MailerLite i MailerSend umożliwi efektywną komunikację z klientami oraz automatyzację procesów związanych z wysyłką newsletterów i wiadomości transakcyjnych. Ostateczny cel to stworzenie środowiska do nauki online, które będzie atrakcyjne zarówno dla indywidualnych klientów, jak i dla firm szukających szkoleń dla swoich pracowników.
Tak zdefiniowane cele wymagają uszczegółowienia. Tym uszczegółowieniem są zarówna wymagania biznesowe jak i systemowe. Natomiast realizacja wymagania biznesowych może być przedstawiona za pomocą diagramów procesów biznesowych (BPMN) oraz diagramów ze świata UML czyli diagramów przypadków użycia, aktywności, sekwencji i komponentów. Opis podstawowych diagramów UML można znaleźć na stronie: Diagramy UML.
Wymagania biznesowe
Pierwszym krokiem jest określenie czym jest wymaganie biznesowe. Uproszczona definicja: Wymaganie biznesowe określa obiekt, czynność lub usługę, która wspiera realizację potrzeby biznesowej i pośrednio celu biznesowego projektu lub organizacji. Wymaganie biznesowe jest niezbędna do obsługi procesu biznesowego lub świadczenia usługi biznesowej.
W naszym przykładzie zdefiniowanych zostało kilka wymagań biznesowych.
Jak widać wymagania biznesowe pozwalają na określenie co musi się wydarzyć, by osiągnąć postawiony cel. Kolejne kroki to przygotowanie procesu biznesowego oraz wstępnej architektury rozwiązania.
Proces biznesowy w notacji BPMN
Wstępna analiza pozwoliła wstępnie zidentyfikować kilka procesów biznesowych, które na poniższym rysunku zostały zmapowane na wymagania biznesowe.
Do mapowania została użyta relacja realizacji, ale równie dobrze można zastosować relację trace skierowaną od wymagania do procesu biznesowego. Kolejny krok to przygotowanie procesu biznesowego. Poziom jego szczegółowości powinien pozwolić na identyfikację przypadków użycia.
Na powyższym diagramie zidentyfikowano 5 kroków. Proces ten jest sekwencją działań, które klient oraz system wykonują w celu zrealizowania zakupu online. Oto opis poszczególnych kroków na podstawie diagramu:
- Inicjacja transakcji – Klient wyświetla koszyk by następnie po jego weryfikacji, podać szczegóły zamówienia.
- Rejestracja zamówienia – Zamówienie jest rejestrowane w systemie sklepu ze statusem do zapłaty
- Obsługa płatności – Czynność odpowiedzialna za komunikację z bramką płatniczą.
- Aktywacja zakupionych produktów – Klient otrzymuje dostęp do zakupionych produktów
- Rejestracja zamówienia opłaconego przelewem tradycyjnym: – Zamówienie jest rejestrowane w systemie ze statusem oczekiwane na płatność przelewem.
Czy ten proces można by było przedstawić bardziej szczegółowo? Tak. W takiej sytuacji proces biznesowy może z powodzeniem zastąpić przypadki użycia. W omawianym przykładzie będą wykorzystane przypadki użycia. Za nim to nastąpi powstanie architektura, która jest pomocna w specyfikacji wymagań na system i definiowaniu przypadków użycia.
Diagram komponentów – Architektura rozwiązania
Diagram komponentów służy do ilustracji organizacji i zależności pomiędzy komponentami. Komponentem może być aplikacja lub moduł aplikacji. W tym przedsięwzięciu aplikacje zidentyfikowane w czasie analizy biznesowej staną się komponentami.
Na powyższym diagramie widać, że nasz Sklep korzysta z interfejsów wystawionych przez aplikacje wykorzystywane do wysyłki maili oraz obsługi płatności. Po zdefiniowaniu architektury i procesu biznesowego czas na identyfikację przypadków użycia.
Diagram przypadków użycia – Funkcje aplikacji
Diagramy przypadków użycia pozwalają na graficzne zaprezentowanie własności systemu tak, jak są one widziane po stronie użytkownika. Diagramy przypadków użycia służą do zobrazowania usług, które są widoczne z zewnątrz systemu. Z mojego punktu widzenia przypadek użycia reprezentuje funkcje aplikacji. W naszym przykładzie mamy następujące przypadki użycia
Zakładam, że jedna na jedną aktywność w procesie biznesowym zmapowany jest jeden lub więcej przypadków użycia. W ten oto sposób relacją trace łącze świat procesów biznesowych z funkcjami aplikacji.
W klasycznym podejściu można opisać kroki procesu, podobnie jak to zrobiłem w tekście o dokumentacji wymagań w opraciu o przypadki użycia. Moim zdaniem, do opisu scenariusza, lepiej jest przygotować diagram aktywności.
Diagram aktywności – scenariusz przypadków użycia
Diagram aktywności jako scenariusz to bardzo wydajne i pojemne rozwiązanie. W każdym z kroków mogę dość szczegółowo opisać zasadę działania danej funkcji. Co więcej dość często opisy tych kroków mogą zastąpić specyfikację wymagań. W moim przedsięwzięciu przygotowano następujący diagram aktywności opisujący scenariusz dla PU Wstępna obsługa transakcji.
Jak pisałem wcześniej w każdym z kroków jest opis tego co się w nim dzieje. Przykładowy opis dla aktywności: Wypełnienie formularza
Klient wypełnia następujące pola
Imię
Nazwisko
Kraj -> na stałe przypisane Polska
Adres
Miasto
Kod pocztowy
Adres e-mail
Konto użytkownika
Utwórz hasło do konta
Usługi do zamówienia
Dwa pola do wyboru (radio button):
Przelewy24
Przelew bankowy (opcja dla firm płacących tradycyjnym przelewem)
Dodatkowe:
Gdy zostanie zaznaczony checkbox: Chcę otrzymać fakturę VAT na firmę (opcjonalne)
pojawiają się pola:
Nazwa firmy
NIP firmy
Jest też checkbox: Przeczytałem/am i akceptuję regulamin *
Przycisk Kupuję i płacę ma być aktywny, gdy na stronie nie ma błędów walidacji i wszystkie wymagane pola są aktywne.
Przykładowy formularz jaki powstał na bazie powyższego opisu może wyglądać następująco:
W opisie aktywności nie zawsze będzie formularz. Czasem będzie dość dokładna informacja dla programisty o tym, jakie czynności ma wykonać aplikacja albo gdzie mają być składowane dane. Przykładowy opis dla aktywności utworzenie konta użytkownika:
Konto tworzone jest w tabelach:
wp_users – ogólne informacje o użytkowniku, takie jak adres e-mail i data rejestracji
wp_usermeta – preferowane informacje rozliczeniowe/wysyłkowe
Wysyłany jest mail z powiadomieniem (API MailerSend):
POST https://api.mailersend.com/v1/emailPodsumowane
Powyższy przykład pokazuje jak w praktyce można połączyć elementy notacji UML z BPMN. Przedstawiony przykład, choć nie jest skomplikowany merytorycznie, to pozwolił na przejście od celu przedsięwzięcia, poprzez scenariusz przypadków użycia do specyfikacji poszczególnych kroków danej funkcji. Tak przygotowana dokumentacja jest użyteczna dla różnych jej odbiorców bo mamy tutaj diagram BPMN, który proces opisujący cały proces oraz w opisach aktywności wytyczne dla programistów albo specjalistów od UX. Jednocześnie nie przeciążono tej specyfikacji nadmiarowo diagramami.
I na koniec. Wiem, że w projektach niezbyt często (czytaj prawie nigdy) realizuje się wszystko od zera. Zazwyczaj działamy już na czymś co istnieje. Ten projekt posłuży do tego by właśnie pokazać zmianę. Będę o tym pisał w kolejnym tekście.
Bardzo dobry materiał pod względem kompleksowego podejścia do tematu . W sensie, że cały problem jest rozłożony na wiele diagramów. Popełniłem kiedyś w podobnej koncepcji artykuł o sensie budowaniu modeli. https://productcorelab.com/blog/write-product-specifications-using-models-part-1-2/ . Chodzi zawsze o przedstawienie modelu rozwiązania w jak największej ilości perspektyw . Dzięki temu mamy coraz dokładniejszy obraz rzeczywistości. Modele, których użyłeś są moim zdaniem trafnym minimum, w których Analityk powinien zawsze przedstawiać owoce swoich prac analitycznych. To z kolei ułatwia komunikację a to z kolei sukcesy projektów 🙂 . No a na końcu właściwie pracą analityczną mamy gotową dokumentację i projektu i rozwiązania. Tu kłania się „stara poczciwa” filozofia model based engenering, którą zawsze będę ewangelizował :).
Kolejno , podoba mi się traceowanie wymagań biznesowych na krok procesu. Sam kiedyś odkryłem przez przypadek tą technikę 🙂 No a tu proszę ktoś jeszcze jej stosuje. Nie wiem @Miachał , czy ona ma jaką nazwę ? Dodam jeszcze że ja głównie pracuje w istniejących systemach gdzie proces juz istnieje i właściwie wymagania biznesowe są zmianą tych procesów. Wtedy strzałka idzie w drugą stronę ale raczej jako zwykła associacja. W sumie można by było napisać o tym oddzielny artykuł i dyskusję 🙂 Pozdrawiam , super się czyta taki konkret. pozdrawiam
Świetna rzecz, dzięki 🙂 Czy diagram przypadków użycia nie powinien mieć obrysowanej granicy systemu?
Co rozumiemy przez granice systemu ?
Granice systemu, to sformułowanie które oznacza, zakres funkcji realizowanych przez system. Innymi słowy jak coś jest w wewnątz granic to realizuje to system a jak na zewnątrz to nie są to funkcje realizowane przez dany system.