Warunki początkowe i końcowe przypadku użycia

W ostatnim czasie w biurze miała miejsce krótka dyskusja dotycząca warunków początkowych (pre-condition) i końcowych (post-condition) przypadku użycia. W wielu projektach w ciągu ostatnich lat opisywaliśmy przypadki użycia i w każdym przypadku wszyscy wiedzieli w jaki sposób formułować warunki początkowe i końcowe. Niespodziewanie dyskusja została wywołana przez analityków z jednej z firm z którą współpracujemy. Dyskusja ta świadczy o tym, że warto dokładnie opisać wszelkie zasady, które na pierwszy rzut oka wydają się oczywiste.

Zasady ogólne 

Warunki początkowe i końcowe mają zastosowanie zarówno do przebiegu głównego jak i do przebiegów alternatywnych. Jeśli nie można tego spełnić, wówczas należy zastanowić się nad rozdzieleniem takiego przypadku użycia na kilka oddzielnych przypadków.
Warunki początkowe i końcowe nie są opcjonalne, muszą być spełnione wszystkie łącznie.
Warto dodać, że reguły te zostały zdefiniowane w specyfikacji UML w następujący sposób:

"An optional set of Constraints specifying what must be fulfilled when the behavior is invoked."

 Jeśli warunki początkowe i końcowe to Constraint, zatem przyjrzyjmy się jeszcze opisowi Contraint w specyfikacji UML:

„Constraint is a condition (a Boolean expression) that restricts the extension of the associated element beyond what is imposed by the other language constructs applied to that element.”
„The value specification for a constraint must evaluate to a Boolean value.”

Wynika z tego, że warunek początkowy lub końcowy to ograniczenie, które może być formułowane przy użyciu dowolnego języka (również naturalnego), dla którego można wyliczyć wartość wartość logiczną: prawda lub fałsz. Opis ten odnosi się do pojedynczego warunku. Jeśli wyspecyfikowano kilka warunków, wówczas powyższe reguły odnoszą się do każdego z nich z osobna.

Warunki początkowe (pre-conditions)

Warunki początkowe wyrażają to, co system jest w stanie zidentyfikować i określić zanim przypadek użycia może zostać wykonany.
Warunki początkowe muszą zostać spełnione poprzez wykonanie innych przypadków użycia w systemie (oznacza to, że przed wykonaniem danego przypadku użycia, inna funkcja systemu powinna zostać wykorzystana, np. wyszukanie obiektów).
Ważne jest, aby warunki początkowe mogły być sprawdzone w systemie, czyli można było logicznie określić, czy warunek jest spełniony (true), czy nie (false).
Warunki początkowe służą do przekazania warunków, które muszą zaistnieć, aby zainicjować przypadek użycia.
Częstym błędem przy definiowaniu warunków początkowych jest ich definiowanie zbyt wielu. Nie należy określać warunków, które powinny być sprawdzane dopiero w przebiegu przypadku w celu wykrycia sytuacji wyjątkowej.
Podczas definiowania warunków początkowych należy próbować odpowiedzieć na następujące pytania:

• Co musi być spełnione przed przystąpieniem do wykonania danej funkcji?
• Czy system ma możliwość wykrycia tego?
• Czy istnieje potrzeba, aby to wykrywać?

Warunki końcowe (post-conditions)

Warunki końcowe wyrażają to, co system jest w stanie zidentyfikować i określić po wykonaniu danego przypadku użycia.
Warunki końcowe zostają spełnione po wykonaniu przypadku użycia (za wyjatkiem wystąpienia sytuacji wyjątkowej).
Ważne jest, aby określać tylko te warunki, które powinny być zapamiętane w systemie.
Podczas definiowania warunków końcowych należy próbować odpowiedzieć na następujące pytania:

• Co musi być spełnione po wykonaniu danej funkcji?
• Czy system musi zachować tę informację?

Przykład warunków początkowych i końcowych

Poniżej zamieszczam szkic (tworzenie kompletnego opisu nie jest przedmiotem tego artykułu) przykładowego przypadku użycia.
Nazwa: Wypłata z bankomatu
Aktorzy:

• Klient banku - klient banku, który posiada kartę bankomatową wydaną przez bank.
• Bank partnerski - bank wydający karty bankomatowe posiadający umowę z partnerem, jakim jest operator bankomatów.

Warunki początkowe:

• Karta bankomatowa została włożona do bankomatu

Przebiegi:

• Przebieg główny
• Przebieg alternatywny 1: Brak wystarczających środków na koncie (Klient ma w tym przypadku możliwość zmiany żądanej kwoty, gdy nie poda prawidłowej kwoty, wówczas zachodzi Sytuacja wyjątkowa 3)
• Sytuacja wyjątkowa 1: Karta bankomatowa jest nieprawidłowa
• Sytuacja wyjątkowa 2: Podany PIN jest nieprawidłowy
• Sytuacja wyjątkowa 3: Brak wystarczających środków

Warunki końcowe:

• Transakcja wypłaty została poprawnie zakończona
• Potwierdzenie wypłaty zostało wydrukowane dla Klienta banku

Został zdefiniowany tylko jeden warunek początkowy informujący o tym, że karta została włożona do bankomatu. System jest w stanie to zweryfikować. Brak jest natomiast warunku początkowego mówiącego na przykład o tym, że Klient banku stoi przed bankomatem, gdyż system nie może zweryfikować, czy warunek ten został spełniony. Brak również warunku dotyczącego podania PIN, gdyż podanie PINu jest realizowane dopiero w trakcie przebiegu. Możliwe jest jednak rozbicie tego przypadku użycia na dwa:

• Weryfikacja tożsamości Klienta
• Realizacja wypłaty (wraz z relacją include do powyższego przypadku)

W takim przypadku, warunkiem końcowym "Weryfikacji tożsamości Klienta" byłyby dwa warunki końcowe: Karta bankomatowa jest prawidłowa, Kod PIN jest prawidłowy. Zaś warunkiem początkowym przypadku użycia "Realizacja wypłaty" mogłyby być "Tożsamość klienta została zweryfikowana".

Zalogowanie użytkownika jako warunek

Często wśród warunków początkowych wymienia się "Użytkownik jest zalogowany do systemu". W rzeczywistości, o ile system wymaga logowania - należałoby zamieścić taki warunek w odniesieniu do każdego przypadku użycia (oprócz przypadku dot. logowania). Decyzja o tym, czy umieszczać taką informację należy do zespołu projektowego. Ja jednak uważam, że taki warunek początkowy nie wnosi wartości merytorycznej do opisu.
Podobnie nie widzę również powodu do umieszczania informacji o tym, czy użytkownik posiada uprawnienia do wykonania danej funkcji. Uprawnienia do określonych funkcji można na podstawowym poziomie opisać poprzez hierarchię aktorów (Użytkownik zwykły, Użytkownik kluczowy, Kierownik, SuperUser itd.). A szczegółowy opis uprawnień warto opracować w postaci macierzy uprawnień w oderwaniu od opisów przypadków użycia.

A jeśli brak jakichkolwiek warunków?

Jeśli dla uruchomienia danego przypadku użycia nie udało się sformułować żadnych warunków początkowych (warunki końcowe zazwyczaj łatwiej znaleźć), nie należy wymyślać takich warunków na siłę. Zalecam jednak, aby w opisie przypadku użycia zawsze umieszczać sekcję Warunki początkowe, a w tej sekcji napisać tylko: Brak. Oznacza to, że opis jest kompletny i autor dokonał analizy w tym zakresie.