Witam ponownie w cyklu #TechLead! W poprzednim artykule omówiliśmy podstawy Event Storming - Big Picture. Dziś kontynuujemy naszą podróż przez świat przypadków użycia, skupiając się na praktycznym zastosowaniu i przykładach.
Przypadki użycia – krótka powtórka
Przypadki użycia są niezwykle przydatnym narzędziem w analizie i projektowaniu systemów. Pozwalają nam zebrać w jednym miejscu informacje biznesowo-techniczne potrzebne do realizacji konkretnej funkcjonalności.
Przypadki użycia opisują listę działań do wykonania w celu osiągnięcia zamierzonego rezultatu, dzieląc informacje według kategorii takich jak cele, kroki, wyjątki i błędy. Można powiedzieć, że służą za punkt styku pomiędzy aspektami biznesowymi, a technicznymi. Zarysowują technologiczne aspekty zagadnienia na tyle, by można było je łatwo przedstawić, oszczędzają jednak zbędnych na tym etapie szczegółów.
Przypadki użycia w praktycznym scenariuszu
Aby lepiej zrozumieć, jak wygląda praktyczne zastosowanie narzędzia, przeanalizujmy dosyć powszechny w branży przypadek. Wyobraźmy sobie, że pracujemy nad systemem e-commerce, który musi zsynchronizować produkty z zewnętrznym systemem PIM co dwie godziny.
Nasz model wygląda następująco:
Tytuł: Synchronizowanie produktów z systemu PIM
Wyzwalacz: Minęły 2 godziny od poprzedniego uruchomienia
Główny scenariusz:
- Odpytano system klienta o produkty dodane w ostatnich 2 godzinach
- System zewnętrzny zwrócił nowe produkty
- Sprawdzono duplikaty zwrócone przez PIM
- Produkty zapisano w systemie e-commerce
- Uruchomiono proces publikacji na stronie
Wyjątki:
1a. System zewnętrzny zwraca błąd 429.
- Zakolejkowano odpytanie na minutę później.
1b. System zewnętrzny zwraca błąd 500.
- Zapisano informację o błędzie komunikacji do loga zdarzeń.
- W przypadku braku możliwości synchronizacji przez 1 godzinę powiadomiono administratorów.
Atrybuty jakościowe:
- Skalowalność : system poradzi sobie z obsługą do 200 produktów podczas jednej sesji synchronizacji.
- Wydajność : synchronizacja zakończy się poniżej 10 sekund.
Wygląda prosto? Oczywiście, ale jednocześnie upraszcza problem i pokazuje najważniejsze aspekty całego przypadku.
Uproszczone przypadki użycia według Martina Fowlera
O ile przypadki użycia to potężne narzędzie, nie jest ono niestety pozbawione wad. Wśród praktyków panowała niegdyś tendencja do rozbudowywania scenariuszy w nieskończoność. Często prowadziło to do tego, że przypadki użycia były nieczytelne. Z inicjatywą znalezienia rozwiązania po raz pierwszy wyszedł Martin Fowler w swojej, opublikowanej po raz pierwszy w 1997 roku, książce “UML Distilled”.
W odróżnieniu od tradycyjnego podejścia, przypadki użycia według Fowlera skupiają się na funkcjonalnościach systemu, a nie na aktorach. Diagramy przypadków użycia według Fowlera pokazują typową interakcję między użytkownikiem a systemem komputerowym, która przechwytuje pewną widoczną dla użytkownika funkcję i osiąga dyskretny cel użytkownika.
Podejście Given When Then
Jeszcze jednym podejściem do tego samego tematu jest Given When Then, bardzo konkretna i sformalizowana perspektywa, która wyśmienicie się sprawdzi w kejsach, gdzie użytkownik końcowy nie jest jedynym odbiorcą scenariusza. W tej wersji, przypadki użycia są opisane z użyciem trzech sekcji:
- Given (Dane wejściowe)
- When (Akcje użytkownika)
- Then (Oczekiwane rezultaty)
Dobrze pokazał to Jakub Nabrdalik w swojej prezentacji o interesującym tytule Things that work for me so well I cannot believe you are not using it:
Taka struktura niesie ze sobą liczne wiele korzyści, szczególnie ułatwiając automatyzację testów. Dzięki precyzyjnemu opisaniu danych wejściowych, działań użytkownika oraz oczekiwanych rezultatów, przypadek użycia bez trudu można przekształcić bezpośrednio w scenariusz testowy. Given When Then pomaga też w nawiązaniu lepszego porozumienia między zespołem projektowym, a testerami i programistami. Świetnie sprawdzi się więc w systemach, które oprócz interakcji użytkowników, uwzględniają także zarządzanie testami.
Wykorzystanie przypadków użycia
Przypadki użycia stanowią cenną praktykę, umożliwiającą szybkie podsumowanie zakresu prac nad konkretnym zadaniem. Ich struktura zapewnia spójność i czytelność w analizie poszczególnych funkcjonalności.
Przykładowo, w technice Upstream Kanbana:
Programista może wziąć tu na siebie zadanie i przeprowadzić analizę jego realizacji. Następnie tworzy opis scenariusza działania w postaci przypadków użycia. Dzięki temu, podczas spotkania mającego na celu dalsze doprecyzowanie, zespół ma już wstępnie przemyślaną funkcjonalność. W efekcie komunikacja jest bardziej efektywna i produktywna.
Polecam
Przypadki użycia to prawdziwie wielofunkcyjne narzędzie – sprawdzą się nie tylko jako podstawa dokumentacji, ale także, odpowiednio przygotowane, pomogą w skutecznym planowaniu, analizie i realizacji zadań.
Jeśli interesuje Ciebie ten temat to zachęcam do zapoznania się z dodatkowymi materiałami:
- “UML Distilled” - Martin Fowler - rozdział o przypadkach użycia
- Things that work for me so well I cannot believe you are not using it - Jakub Nabrdalik – wykorzystanie przypadków użycia
