Dość często spotykam sie z tezami, że użycie przypadków użycia nie wymaga modelowania procesów i odwrotnie, albo że są to „narzędzia” oferujące podobne lub takie same korzyści, np. tak jak tu:

So, as you can see we used different techniques and basically the result is the same. It was not really important what techniques were used unless solution design is complete. It?s just a matter of a habit so if you?re more comfortable with use cases then stick to them or if you?re more familiar with process maps then draw a map. But note that in some cases you may be requested to use a specific technique that is a corporate standard or because there is an agreement that all BAs on the project will use one template (technique) for consistency. (Źródło: Use cases or business process maps, what technique to use?)

Sugeruję najpierw zapoznać się z cytowanym powyżej tekstem a po zapoznaniu się z nim zapraszam do dalszej lektury. Jak się komuś nie chce powyższego czytać, może potraktować mój tekst jak zwykły post a nie jak polemikę ;). 

Zacznę od modelu procesów w BPMN jaki prezentuje jego autor;

Pierwsza rzecz: co do zasady Klient i Podmiot go obsługujący to dwa odrębne podmioty więc diagram ten powinien zawierać dwie pule, a nie jedną wspólną pulę (albo jak kto woli baseny). Dalej. BPMN w specyfikacji traktuje tory wyłącznie jak uniwersalne elementy grupujące (nie są one jednak eksportowane do plików wymiany XPBL czy BPEL4WS), nie ma zakazu stosowanie torów do reprezentowania „systemów”, model biznesowy CIM (definicja MDA) zakazuje. Od siebie dodam, że to czym będą tory należy zdefiniować na początku analizy (i powinna to być jedna spójna definicja).

Autor powyższego diagramu na jednym diagramie pokazał wszystko co wie, łamiąc notacyjne zasady stosowani puli (basenu) oraz dobre praktyki nie mieszania różnych kontekstów na jednym modelu.

Model procesu powinien mieć zawsze konkretny kontekst i być osadzony w jakiejś metodyce, bez tego trudno podjąć decyzję, które informacje są istotne i jakie detale pokazywać (bo notacje są nadmiarowe i nie są metodyką). Bez tego także trudno innej osobie taki diagram jednoznacznie zinterpretować. Najgorsze wyjście to „nie wiem, więc pokaże wszystko co wiem” z czym tu mamy moim zdaniem do czynienia.

Jak to robić? Przyjmuję postępowanie zgodne MDA/MDE (pisałem tu o tym nie raz), więc najpierw tworzymy model CIM (Computation Independent Model), którego celem jest zrozumienie i udokumentowanie mechanizmu – tu – rejestracji konta, typowy mechanizm opt-in:

Co do zasady aktywność w procesie to coś co stanowi kompletnie wykonaną pracę (bo proces to aktywność przekształcająca wejście w wyjście), więc dzielenie jej na kawałki nie ma żadnego uzasadnienia. Detale aktywności pokazujemy na odrębnym diagramie, a częściej jako zapisaną tekstem procedurę (jest niepodzielna bo aktywność jest jedna). Np. aktywność Rejestracja po stronie (w puli) Klienta to:

1. inicjacja rejestracji konta
2. SYSTEM wyświetla formularz Dane użytkownika
3. wypełnienie pól formularza i potwierdzenie
4. jeżeli 
   1. dane są poprawne – SYSTEM potwierdza przyjęcie danych
   2. dane są niepoprawne – SYSTEM prezentuje formularz Dane użytkownika i wyświetla komunikat (lub idź do punkt 2.) 
5. (koniec)

(czasami dodaję pseudo krok procedury koniec aby czytelnik miał pewność, że to ukończona praca).

Po stronie (w puli) Organizacji zainicjowane żądanie rejestracji spowoduje obsługę pierwszego dialogu z Klientem, tu ostatnim krokiem procedury jest wysłanie monitu mailem. Następnie Organizacja czeka, jeżeli dostanie potwierdzenie to aktywuje konto Klienta, zaś po trzech dniach bezczynności, Dane użytkownika zostaną usunięte, i proces rejestracji zostanie uznany za zakończony (tu niepowodzeniem).

Na tym etapie prac wiemy co i jak Organizacja robi w przypadku rejestracji Klienta. Cały ten ambaras jednak do czegoś służy, służy do udostępniania Klientowi możliwości składania zamówień i danych o stanie jego rozrachunków. W przykładzie mamy diagram przypadków użycia, więc i ja pójdę tym tropem (zakres projektowania).

Mamy tu cztery przypadki użycia. Skąd? O tym dalej. Pisałem już wcześniej o transformacji z modelu BPMN na model Przypadków użycia. Tu pokaże efekt końcowy. 

Dlaczego tak?

Przede wszystkim logowanie (wbrew wielu przykładom w sieci) nie jest przypadkiem użycia, czyli nie jest usługą aplikacji, jest cechą środowiska, jednym z wielu sposobów autoryzowania użytkownika do pracy (inne to LDAP, Activedirectory, odcisk palca, itp., jest to metoda realizacji wymagania pozafunkcjonalnego o niedopuszczaniu do korzystania z usług aplikacji nieautoryzowanych osób). Nie jest dobrym pomysłem uznawanie takich czynności jako usług aplikacji (kto kupi coś co służy wyłącznie do logowani się?) 

Mamy tu przypadek użycia Zarządzanie kontem. Jest to usługa polegająca na tworzeniu, aktualizacji, podglądzie lub usunięciu danych użytkownika (standardowo oznacza sie takie usługi CRUD, ang. Create, Retrieve, Update, Delete, są to rejestry pozbawione dziedzinowej logiki biznesowej, kontrolujemy wyłącznie poprawność samych pól). Korzysta z niej Klient, pierwsze użycie (kontekst Create) to nic innego jak rejestracja w systemie, każde kolejne użycie to będzie kolejna aktualizacja danych (kontekst Update) lub ostatecznie polecenie ich usunięcia (kontekst Delete).

Scenariusz rejestracji, opisany wcześniej, wyglądał by tak:

To tu są pokazane (udokumentowane) kolejne kroki realizowane przez projektowany System. W tym przypadku cały proces samoobsługi Klienta (zarządzanie danymi o sobie) został zautomatyzowany (czyli nie robią tego już pracownicy Organizacji a aplikacja). W efekcie model procesu biznesowego przybierze ostateczny kształt „to-be”:

Jedynie Klient używa aplikacji, to kto jest właścicielem oprogramowania nie ma żadnego znaczenia i nie modelujemy tego. Wskazane na wcześniejszym diagramie reguły biznesowe (np. oczekiwanie na powiedzenie rejestracji wygasa po trzech dniach) można zebrać w postaci zestawienia i dołączyć do dokumentacji przypadków użycia, albo po prostu przekazać developerowi całą dokumentację (osobiście powielam zestawienia reguł biznesowych przy przypadkach użycia, co polecam, zaś nadmiarowa dokumentacja jest łatwiejsza w użyciu dla developera).

Autor cytowanego artykułu umieścił w nim także taki diagram:

Mogę to teraz skomentować tak:

1. jest to jakieś nieformalne zestawienie „funkcjonalności”
2. funkcjonalności oznaczone 1, 2 oraz 3 to nic innego jak użycie, w różnym kontekście, przypadku użycia (CRUD) Zarządzanie kontem. 

Nie modelowałem już procesu składania zamówienia (mam nadzieję że nie trzeba :)). Kalendarz to pewna forma zobrazowania terminów (np. zamówień, jeżeli było takie wymaganie), być może na stronie  „panel Klienta” (robota dla UX designera). Monitowanie (6. Notification) to nic innego jak kolejne pozafunkcjonalne wymaganie (monitowanie o czymś jako takie to nie jest przypadek użycia), realizowane w sposób udokumentowany na diagramie sekwencji (scenariusz realizacji przypadku użycia). Diagram sekwencji jak wyżej, po drobnych korektach, będzie pasował do każdej operacji z danymi Klienta, także do aktywności Zapoznanie się z treścią danych w toku potwierdzania rejestracji (tu kontekst prostego potwierdzenia operacji Retrive).

Przedstawiłem wersję, która nie wymaga używania żadnych nieformalnych diagramów (UML i BPMN w zupełności wystarczą). Wersję, która  jest zgodna z MDA, więc wpisuje się dobrze w proces analizy biznesowej (model CIM), oddzielonej od projektowania (model PIM) i implementacji (model PSM, tu pominięty i realnie rzadko wykonywany u developera). Wersję, która w 100% pozwala na śladowanie wymagań. To co opisałem jest także zgodne z zaleceniami BABoK, tworzenia jako wymagania modeli „białej skrzynki” czyli projektu rozwiązania (produktu).

Jak widać, możliwe jest, że jeden przypadek przypadek użycia (dotyczy to szczególnie tych oznaczanych CRUD) jako usługa aplikacji, będzie wykorzystywany w wielu kontekstach (podobnie jak młotek i jego usługa „uderz w to”, może być użyty zarówno do wbijania gwoździa jak i do wybijania szyby).  

Chciałem także kolejny raz pokazać, że zamiast dokumentowania wymagań metodą monstrualnych opisów prozą i zestawień w tabelach, z którymi to opisami autorzy mają nie raz ogromne problemy z utrzymaniem ich kompletności, spójności i niesprzeczności zaś developerzy ogromne problemy z interpretacją, warto wymagania przekazywać w postaci spójnego i przetestowanego i logicznego projektu. Warto także zadbać by schematy blokowe (modele) były tworzone zgodne z określonymi zasadami (notacje, dobre praktyki) bez czego będą trudne w jednoznacznej interpretacji. 

Moi zdaniem podejście MDA zaprezentowane powyżej jest znacznie skuteczniejsze i daje lepsze zrozumienie, niż wersja pokazana przez autora artykułu Use cases or business process maps, what technique to use?, ale ocenę pozostawiam czytelnikom (zachęcam do zadawania pytań i dyskusji).

Co z tytułowym pytaniem: Przypadki użycia czy model procesu, czego używać?

Używać obu diagramów zgodnie z ich przeznaczeniem…