2.1. Czym są scenariusze przypadków użycia?

Na poziomie wymagań oprogramowania konieczne jest bardzo szczegółowe zdefiniowanie sposobu działania systemu, gdyż na tej podstawie zespół deweloperski musi zaprojektować i zaimplementować system. Konieczne jest zatem sformułowanie szczegółowych scenariuszy działania systemu, które pokazują perspektywę użytkowników (ogólnie: aktorów) oraz ich interakcji (dialogu) z systemem.

Scenariusze określają w sposób precyzyjny interakcję użytkownika z systemem prowadzącą do osiągnięcia określonego celu biznesowego. Scenariusze na poziomie wymagań oprogramowania powinny określać wszystkie zidentyfikowane alternatywne ścieżki wykonania przypadku użycia oraz obsługę sytuacji wyjątkowych. Scenariusz przypadku użycia powinien spełniać trzy cechy:

• opisywać sekwencję interakcji między aktorem i systemem,
• zaczynać się od interakcji aktora (w większości przypadków)
• kończyć się, kiedy zostanie osiągnięty cel przypadku użycia, lub kiedy na drodze do tego celu nastąpiła porażka.

Przypadek użycia jest zbiorem scenariuszy prowadzących do tego samego celu, w tym tych zakończonych porażką. Scenariusze przypadku użycia powinny definiować wszystkie alternatywne przebiegi obsługujące sytuacje wyjątkowe, z wyjątkiem tych najbardziej oczywistych.

Pierwsze zdanie scenariusza jest w większości przypadków akcją inicjującą sekwencję współpracy pomiędzy użytkownikiem a systemem. Sekwencja taka jest zawsze inicjowana przez aktora dla głównych przypadków użycia. Dla przypadków użycia połączonych relacjami z innymi przypadkami użycia możliwa jest sytuacja, kiedy pierwszą akcją jest akcja wykonywana przez system.

Przykłady scenariuszy przypadku użycia spełniające powyższe zasady widzimy na rysunku 2.1. Zdania scenariuszy w tym przykładzie pisane są w prostej kontrolowanej gramatyce, która z jednej strony jest wystarczająca do kompletnego opisania interakcji aktor-system, a z drugiej na tyle prosta, aby scenariusze były przejrzyste i jednoznaczne.

Rysunek 2.1: Przykładowe scenariusze przypadku użycia

2.2. Notacja dla scenariuszy

Podstawowym typem zdania scenariusza w gramatyce kontrolowanej jest zdanie typu POD(D) (Podmiot, Orzeczenie, Dopełnienie bliższe, opcjonalne Dopełnienie dalsze).  Przykłady takich zdań widzimy na rysunku 2.2. Zdanie POD(D) składa się z podmiotu określającego wykonawcę akcji, orzeczenia określającego wykonaną akcję oraz dopełnień określających pojęcia, których ta akcja dotyczy

Rysunek 2.2: Gramatyka dla zdań POD(D)

Zwróćmy uwagę na to, że podmiotem zdań POD(D) jest zawsze system bądź aktor (z reguły aktor główny, lecz może to być również aktor poboczny biorący udział w interakcji). Biorąc to pod uwagę, zdania typu POD(D) możemy podzielić na trzy kategorie ze względu na nadawcę i odbiorcę komunikatu:

• zdania aktor-system; są to komunikaty od aktora do systemu (z reguły wprowadzenie danych bądź naciśnięcie przycisku),
• zdania system-aktor; są to komunikaty od systemu do aktora, np. wyświetlenie formularza bądź okienka komunikatu,
• zdania system-system; opisują wewnętrzne operacje systemu jak np. walidację danych wprowadzonych przez użytkownika lub wykonanie przetwarzania danych.

Oprócz zdań w gramatyce kontrolowanej, opisujących sekwencje wymiany komunikatów pomiędzy systemem a użytkownikiem, w scenariuszu mogą występować również zdania sterujące.

Zdania sterujące warunkowe pozwalają na kontrolowanie przebiegu scenariuszy przypadków użycia. Użycie zdania warunkowego pozwala na rozgałęzienie sterowania w zależności od spełnienia bądź niespełnienia danego warunku. Warto zwrócić uwagę na to, że wszystkie zdania występujące przed zdaniem warunkowym są identyczne dla scenariusza pierwotnego  i alternatywnego. Aby jednak nie dokonywać niepotrzebnych powtórzeń zdań, w scenariuszu alternatywnym można się odwołać do zdań w scenariuszu pierwotnym.

Zdania powrotu pozwalają na ponowne połączenie rozgałęzionych scenariuszy bądź zdefiniowanie powtarzanych interakcji (pętli). Definiując powrót trzeba określić scenariusz i numer zdania, które nastąpi po wykonaniu wszystkich zdań danego scenariusza. Jeśli na końcu scenariusza nie ma zdania powrotu, to sterowanie po ostatnim zdaniu wraca do wywołującego przypadku użycia lub następuje powrót do ekranu głównego.

Zdania warunków rozpoczęcia i zakończenia określają dopuszczalny stan system przed i po zakończeniu wykonania scenariuszy. Odpowiedni przykład takich zdań ilustruje rysunek 2.3. Widzimy tutaj zdanie oznaczone frazą „Pre”, które stanowi warunek rozpoczęcia. Takie zdanie jest jedno dla całego przypadku użycia i zawiera wyrażenie, pod rygorem którego możliwe jest jego wykonanie.

Rysunek 2.3: Scenariusze ze zdaniami warunków rozpoczęcia i zakończenia

O ile warunek rozpoczęcia może być najwyżej jeden, to warunków zakończenia może być wiele. Warunki zakończenia możemy umieścić na końcach scenariuszy, które nie posiadają zdań powrotu (patrz wyżej). Każdy warunek zakończenia stanowi określenie stanu systemu, który jest wymagany po zakończeniu działania przypadku użycia zgodnie z danym scenariuszem. W naszym przykładzie mamy tylko dwa warunki zakończenia (oznaczone frazą „Post”). Ich znaczenie jest dosyć oczywiste – określają możliwe stany bazy modeli w przypadku zakończonego sukcesem usunięcia modelu oraz, gdy operacja zostanie anulowana.

Zdania wywołania (ang. invoke) określają krok scenariusza, w którym uruchamiany jest inny przypadek użycia. Mogą one mieć charakter zarówno warunkowy, jak i bezwarunkowy. Zdania tego typu możemy na przykład oznaczyć stereotypem «invoke», opcjonalnym warunkiem (w nawiasach kwadratowych) i nazwą przypadku użycia. Po wykonaniu wywołanego przypadku użycia sterowanie powraca do bieżącego przypadku i wykonanie przypadku jest kontynuowane od miejsca wywołania. Przykład scenariusza przypadku użycia zawierającego takie zdania został przedstawiony na rysunku 2.4.

Rysunek 2.4: Przykładowy scenariusz przypadku użycia ze zdaniami wywołań

2.3. Graficzna reprezentacja scenariuszy

Alternatywnym sposobem przedstawiania scenariuszy przypadków użycia jest prezentacja graficzna za pomocą diagramów czynności. Pozwala to na przedstawienie wielu scenariuszy na jednym diagramie, co w wielu przypadkach pomaga lepiej zrozumieć logikę działania danej aplikacji. Przykład takiej reprezentacji logiki przypadku użycia został przedstawiony na rysunku 2.5. Wykorzystana została standardowa notacja diagramów czynności języka UML.

Rysunek 2.5: Przykład reprezentacji scenariusza przypadku użycia na diagramie czynności