Wymagania na oprogramowanie są często dokumentowane z pomocą Przypadków Użycia (PU), zwanych w „oryginale” Use Case (UC). Wygodą stosowanie tej konwencji jest traktowanie Systemu jako tak zwanej czarnej skrzynki, czyli czegoś, czego wewnętrznej budowy nie znamy, ale znamy reakcje na bodźce. W przypadku oprogramowania, nie wiemy jak jest ono zbudowane (w momencie zamawiania go, może ono jeszcze nie istnieć), ale wiemy jak reaguje na „polecenia”. Jest to uznanie zasady, że zamawiający definiuje CO oprogramowanie ma robić a nie to JAK ono to robi. W przypadku gotowego oprogramowania, lub na etapie poprzedzającym projektowanie, ma to sens, jednak należy pamiętać, że przypadki użycia nie determinują tego co tak na prawdę dostaniemy, co opisałem w artykule o tym co na prawdę opisują przypadki użycia.
Przypadki użycia budzą jednak wiele kontrowersji, gdyż konwencja ta jest sformalizowana (jest to część notacji UML), używanie jej „po swojemu” prowadzi najczęściej do bezużyteczności modeli przypadków użycia.
Jeden z czytelników sprowokował ciekawą dyskusję:
…jakiej notacji używa Pan, aby pokazać wpływ jednego procesu na drugi? Konkretnie chodzi mi o przypadek, że problem występuje w procesie rozliczania płatności, ale żeby go naprawić trzeba wprowadzić zmiany w procesie zakupów. Nie wiem czy samo rozrysowanie procesów w BPMN jest wystarczające czy można to jakoś lepiej zamodelować.
Niektóre analizy wymagają czegoś „ponad” procesami”. Mamy dwa wyjścia: tworzenie nadrzędnych map procesów i na nich „szukanie” związków albo zastosowanie innej notacji na „wyższym poziomie abstrakcji”. Notacja np. BPMN wystarczy, rzecz w tym by opisać proces na odpowiednio wysokim poziomie abstrakcji. Tego typu problemy wymagają uogólnienia i spojrzenia z „wyższej” perspektywy. Pomagają przypadki użycia.
Jeśli chodzi o modele PU, to przyznam, że rzadko je stosuję. W przypadku 1 czynność – 1 PU, to jeśli mamy proces w BPMN, to wg mnie model PU, to po prostu wrzucenie do jednego worka wszystkich czynności. Czyli jest to inna graficznie (wg mnie słabsza, bo brak kolejności) prezentacja tego samego co w BPMN. Chyba że mamy czynności, które nie są wspierane systemem albo wiele procesów, które wykorzystują tą samą czynność (różni aktorzy dla tego samego PU).
Troszkę o tym (przypadki użycia w skrócie PU) tu: https://it-consulting.pl//?s=przypadki+u%C5%BCycia
Ogólnie PU to usługa systemu, czynność w procesie to element pewnego łańcucha takich czynności (proces ma swój cel, pewne czynności mogą się powtarzać w różnych procesach, np. archiwizacja dokumentu). System (oprogramowanie) rzadko wspomaga wszystkie czynności w procesach. Model procesu służy do zrozumienia (i przetestowania) tego co i po co się dzieje w organizacji, część czynności (zakres projektu) jest (ma być) wspierana oprogramowaniem (usługa systemu).
Po drugie model PU to tak na prawdę korzeń struktury opisu oprogramowania. Rolą modelu PU nie jest opis procesów a specyfikacja „usług systemu” z perspektywy „zewnętrznego użytkownika”, jest to opis funkcji narzędzia a nie proces.
Rzecz zasadza się w tym, jak zostaną zdefiniowane pojęcia „przypadek użycia” i „czynność” (w procesie). Ciekawe jest to, że obie te definicje są (PU w UML i czynność w BPMN) permanentnie zaniedbywane (łamane) w dokumentacjach projektowych. W moich oczach jest to niezrozumienie celowości modelowania, które ma być lekarstwem na niejednoznaczność prozy a nie jej inną firmą.
Dziękuję, za takie precyzyjne (łopatologiczne) wyjaśnienie. Mimo, że czytałam wcześniej Pana artykuły (oczywiście nie wszystkie) to dopiero teraz to do mnie wyraźnie dotarło. Nadal nie wiem jak sensownie za pomocą modelu PU przedstawić pełny zakres systemu np. ERP/CRM. Na takim diagramie powinno być chyba kilkadziesiąt elementów i taki diagram nie będzie wg mnie przejrzysty. Czy może dla jednego systemu należy zrobić kilka modeli PU, ale z podziałem na aktorów…
A czy ma Pan może jakiś przykład PU gdzie aktorami są 2 systemy tzn. nie ma udziału osoby fizycznej?
Duże systemy warto podzielić na tak zwane bloki funkcjonalne ograniczone dziedzinowo (tak zwane [[bounded context]]) i „pracować nad nimi” niezależnie (każdy ma swój interfejs). Duży system może mieć setki UC, dzieli się je na pakiety ale nie „per aktor” a raczej „per kontekst” (np. księgowanie dowodów księgowych w jednym podsystemie, niezależnie od tego ilu jest aktorów). Nie ma sensu upychanie na jednym diagramie wszystkich UC…
Co do zasady, model PU zawiera pojęcie System (abstrakcja modelowanego oprogramowania), w nim przypadki użycia (PU) oraz poza nim aktorów tego Systemu. Co jest ważne: model PU to model „Jednego systemu i jego otoczenia”, jeden model PU nie może zawierać wielu równorzędnych Systemów.
Co do zasady model PU to: System modelowany, przypadki jego użycia (jego usługi świadczone na zewnątrz) oraz aktorzy, aktorem jest każdy zewnętrzny byt żądający obsługi. Możliwe jest więc, że system nie ma żadnego „ludzkiego” aktora. Nie przesadzał bym z tym, że PU to „głównie rozmowy systemów” choć projektując „głównie” systemy middleware i elementy integracji można mieć „takie wrażenie” 🙂
O narzędziach
Agilian ogólnie wspiera każde „śladowanie”. Każda operacja utworzenia PU z czynności BPMN, po drodze ma etap wskazania jaki diagram UC oraz jaki Model jest docelowy (a może ich być wiele). Tu trzeba bardzo uważać, bo jeżeli mam proces (np. w BPMN) obsługi reklamacji, to pojawią się czynności z obszaru FK (sprawdzenia czy sprzedano taki towar), z obszaru logistyki (sprawdzenia kiedy wydano lub dostarczono) oraz CRM (czynności „biurowe” obsługi klienta, tu obsługa reklamacji). W zasadzie jeden proces „użył” co najmniej trzy narzędzia (systemy) z różnych obszarów dziedzinowych.
Co do adresatów diagramów, ja także skłaniam się ku tezie, że dla biznesu jest BPMN a PU to już diagram „systemowy”, jednak wiele metodyk (w tym RUP) traktuje diagram PU jako pierwszy powstający (?!) i jako adresowany do zamawiającego… cóż…
Generalnie diagram PU jest bardzo dobrym „korzeniem” do analizy i tworzenia pozostałych modeli, ale bez powstającego „natychmiast” modelu dziedziny nie jest możliwe zaprojektowanie granic (bounded context) dla komponentów.
Spotykam się w literaturze z tezami, które uważam za słuszne, że jeden system (podsystem) nie powinien przekraczać 50 klas biznesowych w dziedzinie (liczba bliska 100 to ogromny system). Praca nad oprogramowaniem powinna zacząć się od analizy i rozbicia problemu na „strawne” kawałki. Najpierw podział na podsystemy, potem na komponenty, a na końcu konkretne klasy i ich realizacje.
Nie ma tu mowy o podziale z perspektywy aktora, bo jeżeli wiemy jaka jest konstrukcja zaprojektowanego młotka albo kalkulatora, to nie możemy ograniczyć (bo nie mamy podstaw) liczby ich użytkowników, bo każdy ma swoje uzasadnione powody by wziąć do ręki np. młotek….
