Czym jest przypadek użycia#
Przypadek użycia (use case) opisuje zachowanie systemu, które przynosi obserwowalny rezultat aktorowi lub innemu podmiotowi zewnętrznemu. Nazwa powinna wyrażać cel, na przykład „Złóż zamówienie”, „Wypłać gotówkę” albo „Zarejestruj konto”. Przypadek użycia obejmuje scenariusze prowadzące do osiągnięcia celu, w tym istotne warianty i wyjątki.
Elipsa na diagramie oznacza przypadek użycia, ale diagram nie jest pełną specyfikacją wymagań. Pokazuje zakres funkcji, aktorów i wybrane relacje. Szczegóły scenariuszy, warunki wstępne, gwarancje, reguły biznesowe i błędy należy opisać tekstowo lub innym odpowiednim modelem.
Klient dąży do złożenia zamówienia. Obliczenie podsumowania jest w tym przykładzie wydzielonym, obowiązkowym zachowaniem. Zastosowanie kuponu rozszerza przypadek główny tylko wtedy, gdy spełniony jest warunek, na przykład klient podał ważny kod. Przykład nie pokazuje kolejności kroków ani wszystkich możliwych rezultatów — te należą do opisu scenariusza.
Granica systemu i aktorzy#
Granica wyznacza system lub podsystem, którego zachowanie opisujemy. Przypadki użycia znajdują się wewnątrz niej, aktorzy — poza nią. Granica odpowiada na pytanie „co jest przedmiotem modelu?”, a niekoniecznie „co należy do firmy” lub „co działa na tym samym serwerze?”.
Aktor reprezentuje rolę zewnętrzną wobec tej granicy: człowieka, organizację, urządzenie lub inny system. Ten sam element może być aktorem w jednym diagramie i częścią systemu w innym, jeśli zmieni się zakres. Połączenie aktora z przypadkiem użycia oznacza udział w interakcji; samo nie określa dokładnej kolejności, inicjatora każdej wiadomości ani przepływu danych.
Scenariusze, cel i zakres#
Przypadek użycia zwykle opisuje pełny, sensowny cel, a nie pojedynczą operację techniczną. „Złóż zamówienie” może obejmować wybór dostawy, potwierdzenie danych, autoryzację płatności i informację o wyniku, o ile tworzą spójną usługę widzianą przez aktora. „Zapisz wiersz w tabeli” zwykle jest krokiem wewnętrznym, a nie celem użytkownika.
Jeden przypadek użycia może mieć scenariusz główny, alternatywne przebiegi i wyjątki. Scenariusz opisuje konkretną ścieżkę zdarzeń; przypadek użycia obejmuje rodzinę takich przebiegów realizujących powiązany cel. Wymagania powinny określać warunki początkowe, wynik sukcesu, zachowanie przy niepowodzeniu i interesariuszy, gdy te informacje są istotne.
Relacja «include»#
«include» wskazuje, że zachowanie przypadku dołączanego jest włączane do zachowania przypadku bazowego w określonym przebiegu. Strzałka przerywana biegnie od przypadku bazowego do dołączanego. Można jej użyć, by wydzielić wspólny fragment zachowania używany przez kilka przypadków albo uczynić obowiązkową część przebiegu czytelną osobno.
Nie wyodrębniaj mechanicznie każdej wspólnej linijki tekstu. Jeśli wydzielony przypadek nie ma samodzielnego znaczenia, utrudnia czytanie albo zmienia się razem z jednym przebiegiem, lepiej opisać go jako krok scenariusza. Użycie «include» nie oznacza koniecznie, że wydzielona funkcja jest osobnym modułem lub usługą w kodzie.
Relacja «extend»#
«extend» dodaje zachowanie rozszerzające do bazowego przypadku w określonym punkcie i pod warunkiem. Strzałka prowadzi od przypadku rozszerzającego do bazowego. Przypadek bazowy powinien pozostawać zrozumiały bez rozszerzenia; rozszerzenie stosuje się wtedy, gdy wariant, opcjonalna funkcja lub warunek wyjątkowy uzupełnia jego przebieg.
Punkty rozszerzenia mogą nazwać miejsce w przebiegu bazowym, w którym dodatkowe zachowanie może się włączyć. Warunek i znaczenie rozszerzenia trzeba opisać, jeśli nie wynikają jasno z modelu. «Extend» nie oznacza po prostu „wywołaj drugi przypadek na końcu” ani nie jest synonimem opcjonalnego kroku bez kontekstu.
Generalizacja przypadków użycia#
Generalizacja może wiązać przypadki użycia, gdy szczegółowy przypadek jest odmianą bardziej ogólnego i dzieli jego cel lub zachowanie. Pusty trójkąt jest skierowany do przypadku ogólnego. Używaj tego mechanizmu oszczędnie: podobne nazwy lub kilka wspólnych kroków nie dowodzą, że przypadki tworzą hierarchię typów.
Podobnie można specjalizować aktorów, jeśli role szczegółowe dziedziczą relacje aktora ogólnego. Nie myl tej relacji z «include» ani «extend» — każda odpowiada na inne pytanie o strukturę zachowania.
Diagram a tekstowy opis#
Diagram przypadków użycia sprawdza się jako przegląd zakresu funkcjonalnego i rozmowy z interesariuszami. W większym systemie podziel go na czytelne widoki. Nie dodawaj dziesiątek elips i strzałek tylko po to, by odtworzyć pełny przebieg. Szczegółowy zapis tekstowy może zawierać: nazwę i cel, aktorów, warunki wstępne, gwarancję sukcesu, scenariusz główny, warianty, wyjątki i wymagania specjalne.
Przypadki użycia nie są automatycznie wymaganiami weryfikowalnymi. Nazwa i elipsa są skrótem komunikacyjnym; zespół nadal musi uzgodnić kryteria akceptacji i zachowanie w sytuacjach granicznych. Do kolejności komunikatów użyj diagramu sekwencji, a do przepływu procesu — diagramu aktywności, jeśli to lepiej odpowiada pytaniu.
Częste błędy#
- Przypadek nazwany rzeczownikiem technicznym. Formułuj nazwę jako cel, który system realizuje dla aktora.
- Jeden przypadek na każdy ekran lub endpoint. Granice przypadków wyznaczają cele i wartość, nie elementy UI ani API.
- «include» i «extend» odwrócone. Include prowadzi od bazowego do dołączanego; extend od rozszerzającego do bazowego.
- «extend» użyte jako zwykły krok obowiązkowy. Warunkowe rozszerzenie powinno mieć warunek lub jasno wskazany wariant.
- Elipsa uznana za kompletny opis. Diagram wymaga scenariuszy i reguł tam, gdzie szczegóły są istotne.
- Aktor utożsamiony z komponentem wewnętrznym. Pozycję określa granica modelowanego systemu.
- Nadmierna dekompozycja. Nie rozbijaj celów na drobne kroki bez poprawy zrozumiałości.
Podsumowanie#
Przypadek użycia opisuje zachowanie systemu, które prowadzi do wartościowego rezultatu dla aktora. Diagram pokazuje zakres systemu, role zewnętrzne i cele, a scenariusze wyjaśniają przebieg. «Include» wydziela włączane zachowanie, «extend» dodaje warunkowe rozszerzenie; kierunki tych relacji są różne i powinny wynikać z semantyki modelu.