Diagram przypadków użycia

Czym jest diagram przypadków użycia#

Diagram przypadków użycia (use case diagram) przedstawia, jakie cele i usługi system oferuje podmiotom zewnętrznym oraz jak te podmioty wchodzą z nim w interakcję. Pokazuje zakres systemu, jego aktorów i najważniejsze jednostki użytecznego zachowania. Najlepiej odpowiada na pytanie: „Kto korzysta z systemu i w jakim celu?”.

Diagram daje zwięzły, wysokopoziomowy widok funkcji, nie pełny opis sposobu ich wykonania. Zwykle towarzyszą mu tekstowe specyfikacje przypadków użycia, scenariusze, warunki wstępne, wyniki, reguły i wyjątki. Elipsa z nazwą „Złóż zamówienie” nie wyjaśnia sama, jakie kroki wykonuje klient ani co system robi w przypadku braku płatności.

Diagram może pomagać w rozmowie o zakresie i wymaganiach, ale nie jest kompletną metodą zbierania wymagań. Pokazuje wybrane zachowania z perspektywy aktorów; jakość wymagań zależy również od scenariuszy, kryteriów akceptacji, danych i uzgodnień ze interesariuszami.

System i jego granica#

Przypadki użycia zwykle umieszcza się wewnątrz prostokąta reprezentującego modelowany system (subject), a aktorów na zewnątrz. Nazwa granicy powinna jasno określać zakres, np. Sklep internetowy, Panel administracyjny albo Usługa rezerwacji.

Granica mówi, co w tym modelu uznajemy za system. Ten sam element może znaleźć się wewnątrz albo na zewnątrz w zależności od zakresu. Jeśli modelowany jest sklep jako produkt, operator płatności będzie zwykle aktorem zewnętrznym. Jeśli modelowany jest cały ekosystem płatniczy, operator może być wewnątrz szerszej granicy.

Nie przedstawiaj granicy jako granicy sieci lub procesu bez dodatkowego kontekstu. Diagram przypadków użycia opisuje zakres odpowiedzialności z perspektywy funkcji, a nie rozmieszczenie serwerów.

Aktorzy#

Aktor (actor) jest rolą odgrywaną przez osobę, organizację, urządzenie albo inny system w relacji z modelowanym systemem. Aktorem może być Klient, Administrator, Operator płatności lub Czytnik kodów. Aktor nie jest konkretną osobą ani kontem użytkownika; tę samą rolę może odgrywać wiele osób, a jedna osoba może odgrywać różne role.

Aktor znajduje się poza granicą systemu i uczestniczy w jego przypadkach użycia. Aktor może inicjować zachowanie lub współdziałać z systemem w trakcie jego realizacji. Nie każdy interesariusz jest aktorem: osoba, która finansuje projekt lub akceptuje wymagania, ale nie wchodzi w interakcję z systemem, może być interesariuszem, lecz nie musi być aktorem na diagramie.

Nazwy aktorów zapisuj jako role, a nie nazwy ekranów, zespołów programistycznych czy baz danych, chyba że dany element rzeczywiście uczestniczy zewnętrznie w zachowaniu. System zewnętrzny, np. bramka płatności, może być aktorem w modelu sklepu.

Uogólnienie aktorów#

Aktorzy mogą uczestniczyć w uogólnieniu. Trójkątny grot skierowany ku aktorowi bardziej ogólnemu oznacza, że aktor szczegółowy dziedziczy jego relacje i może być używany w miejscach, gdzie dopuszczony jest typ ogólny. Stosuj to, gdy role rzeczywiście współdzielą zachowanie, a nie tylko dlatego, że ich nazwy są podobne.

Przypadki użycia#

Przypadek użycia (use case) opisuje zachowanie systemu, które przynosi obserwowalną wartość aktorowi lub innemu interesariuszowi. Jego nazwa najczęściej jest krótką frazą czasownikową, np. Złóż zamówienie, Sprawdź dostępność, Zmień adres dostawy.

Przypadek użycia powinien mieć sens jako cel lub spójna usługa z punktu widzenia aktora. Nie musi odpowiadać pojedynczemu ekranowi, przyciskowi, funkcji w kodzie ani wywołaniu API. „Kliknij przycisk Zapisz” opisuje krok interfejsu, niekoniecznie cel użytkownika. Z kolei „Zarządzaj wszystkim” może być zbyt ogólne, aby wspierać analizę.

Przypadek użycia może mieć opis obejmujący:

• cel i zakres;
• aktora głównego oraz pozostałych uczestników;
• warunki wstępne;
• wyzwalacz;
• podstawowy przebieg zdarzeń;
• alternatywne i wyjątkowe przebiegi;
• warunki końcowe i gwarancje;
• reguły biznesowe, dane wejściowe oraz wymagania specjalne.

Zakres tych sekcji jest wyborem metodyki i zespołu; UML nie narzuca jednego obowiązkowego szablonu tekstowej specyfikacji.

Asocjacja aktora z przypadkiem użycia#

Aktor jest łączony z przypadkiem użycia linią asocjacji. Linia wskazuje udział aktora, lecz sama nie określa kolejności kroków, kierunku komunikatu, protokołu ani tego, kto inicjuje każde zdarzenie. Grot na takiej linii bywa stosowany przez narzędzia jako dodatkowa konwencja, ale w prostym diagramie nie jest potrzebny do pokazania współuczestnictwa.

Jeden aktor może uczestniczyć w wielu przypadkach użycia, a w jednym przypadku może uczestniczyć kilku aktorów. Dodawaj asocjację wtedy, gdy aktor rzeczywiście wchodzi w interakcję z tym zachowaniem. Nie łącz każdego aktora z każdym przypadkiem tylko po to, by diagram był symetryczny.

Relacja «include»#

Relacja «include» oznacza, że przebieg przypadku bazowego włącza zachowanie wskazanego przypadku użycia. Jest przydatna, gdy wydzielony fragment jest obowiązkowo wykonywany przez jeden lub więcej przypadków i warto opisać go osobno. Strzałka zależności biegnie od przypadku włączającego do przypadku włączanego.

Na przykład Złóż zamówienie może zawsze włączać Sprawdź poprawność koszyka, jeśli ta walidacja jest elementem każdego przebiegu składania zamówienia. Przypadek włączany można współdzielić, aby uniknąć powielania wspólnego zachowania w specyfikacjach. Nie oznacza to jednak, że każda linia wspólnego kodu powinna stać się osobnym przypadkiem użycia.

«include» nie jest odpowiednikiem wywołania funkcji w konkretnym języku ani diagramem kolejności. Szczegółowe zachowanie nadal warto opisać w tekstowej specyfikacji.

Relacja «extend»#

Relacja «extend» opisuje dodatkowe zachowanie, które w określonych warunkach może rozszerzyć przypadek bazowy. Przypadek rozszerzający jest opcjonalny względem kompletnego przebiegu przypadku bazowego. Strzałka biegnie od rozszerzającego przypadku użycia do przypadku rozszerzanego.

Przykładem może być Zastosuj kupon, które rozszerza Złóż zamówienie, gdy klient poda kod i spełnione są warunki promocji. Przypadek bazowy można zrozumieć bez rozszerzenia. Warunek i miejsce włączenia zachowania powinny być opisane, jeśli są istotne. UML pozwala wskazać punkt rozszerzenia w specyfikacji przypadku bazowego.

«extend» nie oznacza po prostu „ten przypadek jest rzadszy” ani „ten przypadek pojawia się później”. Używaj go, gdy model rzeczywiście rozdziela kompletne zachowanie bazowe i warunkowo dołączane zachowanie dodatkowe.

Uogólnienie przypadków użycia#

Uogólnienie między przypadkami użycia wskazuje wyspecjalizowany wariant zachowania, który dziedziczy i może doprecyzowywać zachowanie przypadku ogólniejszego. Podobnie jak przy dziedziczeniu klas, szczegółowy przypadek powinien zachować sens relacji „jest odmianą”.

Jeżeli zachowanie jest zawsze wykonywane jako część innego przypadku, rozważ «include». Jeśli jest opcjonalne i zależne od warunku, rozważ «extend». Uogólnienie nie jest uniwersalnym sposobem na pokazanie dowolnej relacji „podtyp” między nazwami funkcji.

Przykład: sklep internetowy#

Diagram przedstawia klienta, zewnętrznego operatora płatności oraz cele widoczne na granicy sklepu. Złożenie zamówienia zawsze obejmuje kontrolę poprawności koszyka. Wprowadzenie kuponu jest dodatkowym, warunkowym zachowaniem. Operator płatności uczestniczy w autoryzacji, która jest częścią realizacji zamówienia.

Klient może przeglądać katalog i składać zamówienie, a operator płatności współpracuje z systemem przy autoryzacji. Strzałki «include» prowadzą od Złóż zamówienie do zachowań włączanych. Strzałka «extend» prowadzi od Zastosuj kupon do przypadku bazowego. Nawiasowa etykieta przedstawia uproszczony warunek rozszerzenia.

Diagram nie opisuje całego procesu zakupu, takich kroków jak wybór dostawy i potwierdzenie adresu, ani nie określa, kiedy dokładnie operator otrzymuje żądanie. Dalsze kroki, odpowiedzi i wyjątki powinny znaleźć się w scenariuszu tekstowym lub diagramie zachowania.

Jak tworzyć diagram przypadków użycia#

1. Ustal zakres systemu. Nazwij modelowany produkt, usługę lub podsystem.
2. Wskaż aktorów zewnętrznych. Zapisz role ludzi, organizacji, urządzeń i systemów współpracujących z zakresem.
3. Odkryj cele aktorów. Zapytaj, po co aktor wchodzi w interakcję i jaki obserwowalny wynik jest dla niego wartościowy.
4. Nazwij przypadki jako cele. Używaj zwięzłych fraz czasownikowych; nie koduj w nazwie szczegółowego przebiegu.
5. Połącz uczestników z przypadkami. Dodaj tylko rzeczywiste relacje interakcji.
6. Wydziel powtarzalne zachowanie przez «include». Upewnij się, że jest włączane w kontekście przypadku bazowego.
7. Dodaj «extend» dla zachowań warunkowych. Wskaż warunek i punkt rozszerzenia w opisie, jeśli są potrzebne.
8. Dodaj uogólnienia tylko dla prawdziwych specjalizacji. Sprawdź, czy przypadek szczegółowy jest odmianą ogólnego.
9. Dopisz specyfikacje tekstowe. Opisz przebiegi, warunki, wyjątki i wyniki.
10. Sprawdź diagram z interesariuszami. Zapytaj, czy cele i granica odpowiadają temu, co system ma zapewnić.

Proces może być iteracyjny: rozmowa o scenariuszu ujawnia nowego aktora, a rozmowa o aktorze może odkryć pominięty cel.

Diagram a tekstowy przypadek użycia#

Diagram jest mapą zakresu i relacji między rolami a celami. Tekstowa specyfikacja wyjaśnia warunki, kroki, alternatywy, błędy oraz wynik. Dla złożonej funkcji jedno nie zastępuje drugiego.

Nie istnieje jeden obowiązkowy format tekstu przypadków użycia. Zespół może wybrać styl opisujący cel użytkownika, przebieg główny i rozszerzenia, albo szczegółowe wymagania systemowe. Ważne, aby opisy były jednoznaczne i pomagały zweryfikować, kiedy przypadek jest spełniony.

Diagram sekwencji może rozwinąć wybrany scenariusz przez pokazanie uczestników i komunikatów w czasie. Diagram aktywności może przedstawić przepływ kroków i decyzje. Nie zamieniaj diagramu przypadków użycia w schemat procesu, próbując narysować wszystkie kroki w elipsach.

Typowe błędy#

• Aktor jako konkretna osoba. Modeluj rolę, np. Klient, a nie nazwisko lub pojedyncze konto.
• Aktor wewnątrz granicy. Aktor jest zewnętrznym uczestnikiem względem modelowanego zakresu.
• Przypadek użycia jako ekran lub przycisk. Nazwij cel i użyteczny wynik, nie techniczny krok interfejsu.
• Elipsa bez wartości dla aktora. Upewnij się, że przypadek opisuje spójne zachowanie o znaczeniu dla użytkownika lub innego interesariusza.
• Diagram traktowany jako kompletna specyfikacja. Dopisz przebiegi, warunki, wyjątki i wyniki w tekście.
• Nadużywanie «include». Nie wydzielaj każdej wspólnej instrukcji; używaj relacji dla istotnego współdzielonego zachowania.
• Odwrócony kierunek relacji. «include» prowadzi do przypadku włączanego; «extend» prowadzi do przypadku bazowego.
• Używanie «extend» dla każdego wyjątku. Warunkowe rozszerzenie powinno mieć sens jako osobne zachowanie względem kompletnego przypadku bazowego.
• Mylenie aktora z interesariuszem. Interesariusz może mieć wymagania, ale nie musi bezpośrednio współdziałać z systemem.
• Za dużo przypadków na jednym rysunku. Podziel zakres na widoki, gdy gęstość utrudnia rozmowę.
• Używanie strzałek aktor–przypadek jako kolejności. Asocjacja oznacza uczestnictwo, nie następstwo kroków.

Co diagram przypadków użycia pokazuje, a czego nie#

Diagram pokazuje modelowany system, aktorów zewnętrznych, cele lub usługi w postaci przypadków użycia oraz wybrane relacje między nimi. Jest przydatny na początku analizy do wspólnego ustalenia zakresu i rozmowy o tym, kto czego oczekuje.

Nie pokazuje szczegółowej logiki, kolejności kroków, struktury klas, ekranów, protokołów ani kompletnej treści wymagań. Uzupełnij go tekstowymi scenariuszami i innymi diagramami dobranymi do pytania, które pozostaje bez odpowiedzi.