Przypadki użycia

Kilka postów wcześniej wspomniałem o tym, że nie cierpię diagramów przypadków użycia. Skrytykowałem to narzędzie m.in. za, ukrywanie tego czym przypadki użycia naprawdę są. Nie wspomniałem jednak czym właściwie są te przypadki użycia. Pojęcie jest znane od przynajmniej kilkunastu lat (1994?), czy jednak wszyscy używający tego pomysłu wiedzą o co chodzi? Postaram się w skrócie opowiedzieć jak ja posługuję się przypadkami użycia. Dziś skupię się raczej na tym jak zastosować przypadki użycia, jak je rozumieć. Do tego jak je opisać wrócę, mam nadzieję, w którymś z kolejnych wpisów.

Zacznijmy od ustalenia podstawowej informacji – co to jest przypadek użycia. Sformułowanie niby proste, ale jednak na tyle płynne że konieczne jest ustalenie sensownej definicji. Niestety objaśnienia typu „przypadek użycia to opis wymagania”, albo „przypadek użycia to przykład użycia systemu” nie są ani dobre ani wystarczające. Moja, choć oparta na „Writing effective use cases”, definicja UC brzmi tak:

Przypadek użycia to plan zastosowania systemu do realizacji (osiągnięcia) celu

lub, bardziej ogólnie

Przypadek użycia to plan realizacji (osiągnięcia) celu

Od razu zakładam, że nie jest to jedyna słuszna definicja, że nie istnieje inny sposób interpretacji tego pojęcia. Równie dobrze, można pracować wg innego sformułowania i uzyskać poprawne rezultaty. Jednak ustalenie co rozumiemy przez use case jest kluczowe do poprawnego zanalizowania problemu.

Wracając do tematu – definicja definicją, ale co to znaczy? Mała analiza powinna pomóc, ustalmy więc jak należy rozumieć użyte w definicji słowa. Zacznijmy od określenia pojęcia cel. Zwracam uwagę, że w drugiej wersji definicji, nie pojawia się słowo „system” i to jest kluczowe do zrozumienia co znaczy cel. Cel to rezultat, efekt(a także częściowy rezultat), którego osiągnięcie ma znaczenie dla uczestników1, przynosi im jakąś korzyść, ma znaczenie w kontekście dziedziny/biznesu. Cel „znajduje się” poza systemem – czyli osiągnięcie go ma wpływ na otoczenie samego systemu, a nawet (teoretycznie) do osiągnięcia celu nie jest konieczna aplikacja (ta konkretna i tak w ogóle). Jak już wspomniałem, cel ma znaczenie dla uczestników w otoczeniu systemu, jednak niektórzy z nich są bardziej związani z nim, są aktorami. Związek między aktorem i przypadkiem użycia nie jest tak do końca oczywisty i prosty, może przyjąć różne poziomy. Jednak w moim opisie najważniejsze są dwa poziomy: pierwszy z nich, aktor główny, określa aktora wykonującego wskazany przypadek użycia, czyli tą osobę która siedzi przed ekranem i doprowadza do zrealizowania celu. Drugi z poziomów, interesariusz2, określa dla kogo ma znaczenie osiągnięcie, lub nie osiągnięcie, celu. Chociaż w mojej definicji przypadków użycia, aktorzy nie pojawiają się, są jednak bardzo istotnym ich elementem, pozwalającym odkryć właściwe przypadki użycia i ustalić czy we właściwy sposób zostały opisane.

Kolejny punkt definicji – plan. Zastanawiałem się dłuższą chwilę, jakiego słowa najlepiej tu użyć. Scenariusz – typowe określenie używane w tym miejscu podczas opisywania idei przypadków użycia – nie do końca mi odpowiada, bo sugeruje że jest to liniowy opis „dialogu”, jak w sformułowaniu „scenariusz filmowy”. W potocznym rozumieniu, scenariusz posiada tylko jedną drogę od początku do końca, nie ma alternatywnych ścieżek, różnych zakończeń, warunkowych zdarzeń, nietypowych sytuacji. Plan jest zdecydowanie lepszym określeniem, bo sugeruje że może istnieć wiele ścieżek, dróg, możliwe są różne zakończenia (punkty docelowe) jak w planie działań czy planie drogowym. I tak właśnie należy rozumieć sformułowanie „przypadek użycia to plan” – UC jest opisem ścieżek, dróg, prowadzących od rozpoczęcia przypadku użycia (punkt startu) do osiągnięcia celu, czyli zakończenia.

Zakończenie, czyli osiągnięcie celu. W ten oto sposób dotarliśmy do kolejnego elementu definicji – realizacja. Zakończenie przypadku może być pozytywne, gdy cel został osiągnięty, lub negatywne, gdy cel nie został zrealizowany. Ponieważ przypadki użycia znajdują się bardziej w obszarze dziedziny a nie systemu (patrz co oznacza cel), są formą opisu interfejsu3 między systemem a użytkownikiem, czy też otoczeniem, procesem biznesowym4, więc realizacja musi być opisywana z punktu widzenia aktora a nie systemu. Czyli opis jak aktor może wykorzystać system do osiągnięcia celu a nie jak system będzie w tle przeprowadzał prace. W opisie przypadku użycia nie powinny pojawić się informacje o sposobie zrealizowania przypadku użycia przez system. Mówiąc w skrócie, gdy myślimy o przypadkach użycia to system ma być dla nas czarną skrzynką, której zawartość nas nie interesuje5.

Kiedy już wiemy co znaczy definicja to powiem, że nie należy się jej trzymać. Ściśle. Mówiąc o celu wspomniałem, że powinien być poza systemem, jednak czasem warto poluzować reguły i dopuścić także wersję celu systemowego, którego osiągnięcie daje efekt tylko w kontekście systemu. Sztandarowym, używanym w każdej książce przykładem, jest oczywiście „Użytkownik loguje się”. Ma sens tylko w systemie, tylko tu jego prawidłowa realizacja da sensowny efekt. Należy jednak pamiętać o dwóch rzeczach – wyraźnym zaznaczeniu poziomu przypadku użycia i ścisłym stosowaniu definicji celu przy pierwszym cyklu identyfikacji wymagań do systemu – tu należy myśleć o celach tylko jako „do czego mogę użyć systemu”.

Cały powyższy wywód ma na celu ustalenie CO oznaczają przypadki użycia a nie JAK wyglądają. Ustalenie jednej, spójnej i sensownej definicji przypadków użycia umożliwia ich poprawne zidentyfikowanie. Oczywiście, przypadki użycia stworzone na podstawie omówionej definicji, będą dość proste. Definicja pomija sporo ważnych elementów odróżniających dobre przypadki użycia od złych. W realnych zastosowaniach, opis przypadków może i powinien być uzupełniony o niezbędne szczegóły, jak np. warunki brzegowe (wejścia i wyjścia), wyzwalacze, sformalizowany opis planu działań. Chciałem jednak skupić się na tym czym są przypadki użycia i opisać to maksymalnie prosto. Dlatego też starałem się nie poruszać tematu formy opisu przypadków. Rozpoczęcie od ustalenia jak rozumiemy przypadki użycia, znaczenie ułatwia ich identyfikację, jest niezbędne do stworzenia listy zadań realizowanych przez projektowany system. W kolejnych wpisach chciałbym poruszyć temat formy opisu przypadków użycia a przede wszystkim przedstawić kilka praktycznych przykładów.

  1. użytkowników, osób działających w otoczeniu systemu
  2. dużo bardziej podoba mi się angielskie określenie stakeholder – jest proste, łatwo zrozumiałe, dużo powszechniej używane, zwłaszcza w języku biznesowym; jednak nie ma w j. Polskim ładnego odpowiednika, musimy więc używać takiej nowomowy
  3. W znaczeniu – „punkt styku” a nie GUI
  4. Oczywiście nie zawsze i nie wyłącznie
  5. j.w.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *