Diagramy przypadków użycia: Praktyczny przewodnik

A diagram przypadku użycia to diagram UML zachowania, który pokazuje, jak zewnętrzni użytkownicy lub systemy oddziałują z systemem. Skupia się na czym system robi z perspektywy aktora, a nie na szczegółach wewnętrznej realizacji.

Diagramy przypadków użycia są szczególnie przydatne podczas analizy wymagań, ponieważ zapewniają widok najwyższego poziomu funkcjonalności i zakresu systemu.

1. Co pokazuje diagram przypadku użycia

Diagram przypadku użycia zwykle zawiera:

• Granica systemu — definiuje, co znajduje się wewnątrz modelowanego systemu.

• Aktory — zewnętrzni użytkownicy, organizacje, urządzenia lub systemy, które z nim oddziałują.

• Przypadki użycia — cele lub usługi, które system oferuje.

• Połączenia — łącza komunikacyjne między aktorami a przypadkami użycia.

• Związki między przypadkami użycia — takie jak <<include>> i <<extend>>.

• Generalizacja — dziedziczenie między aktorami lub przypadkami użycia.

Diagram przypadków użycia zwykle nie pokazuje:

• Kroki algorytmu

• Tabele bazy danych

• Klasy programu

• Wewnętrzne przepływy pracy

• Szczegółowe układy interfejsu użytkownika

• Sequencje komunikatów w czasie

Te szczegóły lepiej przedstawić za pomocą diagramów działania, klas, sekwencji lub stanów.

2. Kluczowe pojęcia

Granica systemu

Granica systemu to prostokąt otaczający przypadki użycia należące do systemu.

Na przykład w systemie internetowego zakupów:

+--------------------------------------+
|        System zakupów internetowych        |
|                                      |
|  (Przeglądaj produkty)                   |
|  (Złóż zamówienie)                       |
|  (Zapłać)                      |
+--------------------------------------+

Aktorzy pozostają poza granicą, ponieważ są zewnętrzne dla systemu.

Granica pomaga wyjaśnić zakres systemu. Jeśli funkcjonalność znajduje się poza granicą, nie jest realizowana przez modelowany system.

Uczestnicy

Pojedynczy uczestnik to wszystko zewnętrzne, co oddziałuje na system w celu osiągnięcia celu.

Uczestnicy mogą obejmować:

• Użytkownicy ludzi

• Zewnętrzne aplikacje

• Urządzenia sprzętowe

• Inne organizacje

• Czas lub zaplanowane zdarzenia, gdy są modelowane jako zewnętrzne wyzwalacze

Przykłady:

• Klient

• Bibliotekarz

• Brama płatności

• Administrator

• Usługa e-mail

Uczestnik reprezentuje rolę, niekoniecznie konkretnej osoby. Na przykład „Klient” zwykle brzmi lepiej niż „Alex”.

Aktorzy mogą być:

• Główni aktorzy — inicjują interakcje w celu osiągnięcia celu.

• Wsparciowe aktory — zapewniają usługi systemowi.

Na przykład klient może rozpocząć „Zamówienie”, podczas gdy brama płatności wspiera „Przetwarzanie płatności”.

Przypadki użycia

A przypadek użycia reprezentuje znaczący cel lub usługę oferowaną przez system.

Dobre nazwy przypadków użycia zwykle mają tę postać:

Czasownik + rzeczownik

Przykłady:

• Zarejestruj konto

• Wyszukaj katalog

• Zgłoś wniosek

• Wygeneruj raport

• Anuluj rezerwację

• Przetwórz płatność

Przypadek użycia powinien opisywać widoczny wynik, a nie krok implementacji wewnętrznej.

Preferuj:

Złóż zamówienie

zamiast:

Weryfikuj obiekt zamówienia

Drugi opisuje operację wewnętrzną, a nie cel użytkownika.

Połączenia

Połączenie to łącze komunikacyjne między aktorem a przypadkiem użycia.

Wskazuje, że aktor uczestniczy w przypadku użycia lub inicjuje go.

Klient ---- (Złóż zamówienie)

Połączenia zazwyczaj nie wskazują kolejności, przepływu sterowania ani kierunku. Jeśli kolejność interakcji ma znaczenie, użyj diagramu sekwencji lub diagramu działania.

3. Relacje między przypadkami użycia

<<include>>

Użyj <<include>> gdy jeden przypadek użycia zawsze używainnego przypadku użycia.

Na przykład, składanie zamówienia może zawsze wymagać uwierzytelnienia:

(Złóż zamówienie) ..> (Uwierzytelnij klienta) : <<include>>

Podstawowy przypadek użycia zależy od uwzględnionego przypadku użycia.

Użyj include gdy:

• Zachowanie jest obowiązkowe.

• Zachowanie jest ponownie używane przez wiele przypadków użycia.

• Wydzielenie zachowania poprawia jasność.

Przykład:

(Wypłać gotówkę) ..> (Zautoryzuj kartę) : <<include>>
(Sprawdź saldo) ..> (Zautoryzuj kartę) : <<include>>

Oba przypadki użycia zawsze wymagają uwierzytelnienia karty.

<<extend>>

Użyj <<extend>> gdy dodatkowe zachowanie jest opcjonalne lub warunkowo wstawiane do podstawowego przypadku użycia.

(Zastosuj zniżkę) ..> (Złóż zamówienie) : <<extend>>

Zachowanie zniżki występuje tylko wtedy, gdy spełnione są warunki uprawnienia.

Użyj extend gdy:

• Zachowanie jest opcjonalne.

• Występuje wyłącznie w określonym warunku.

• Podstawowy przypadek użycia jest kompletny bez niego.

Przykłady:

• „Dodaj opakowanie podarunkowe” rozszerza „Zamówienie.”

• „Zażądaj zwrotu pieniędzy” rozszerza „Anuluj subskrypcję.”

• „Wyślij e-mail promocyjny” rozszerza „Zakończ rejestrację.”

Strzałka wskazuje od rozszerzanego przypadku użycia do podstawowego przypadku użycia.

Generalizacja

Generalizacja reprezentuje relację „jest rodzajem” między aktorami lub przypadkami użycia.

Na przykład:

Klient premium --|> Klient

Klient premium jest rodzajem klienta i dziedziczy interakcje klienta.

Generalizacja aktora może być przydatna, gdy kilku aktorów dzieli wspólne zachowanie:

Administrator --|> Pracownik
Bibliotekarz --|> Pracownik

Używaj generalizacji oszczędnie. Jeśli relacja polega jedynie na „używa” lub „uczestniczy w”, to związek jest zwykle bardziej odpowiedni.

4. Aktor główny i wspierający

Rozważ scenariusz płatności online:

• The Klientjest głównym aktorem, ponieważ inicjuje zakup.

• Pierwszy Środkowisko płatności jest aktorem wspierającym, ponieważ przetwarza płatność na żądanie systemu.

Prosty model może wyglądać następująco:

Klient ---- (Złóż zamówienie)
(Złóż zamówienie) ---- Środkowisko płatności

Rozróżnienie jest przydatne, ponieważ wyjaśnia, kto korzysta z przypadku użycia i jakie systemy zewnętrzne są zaangażowane.

5. Jak identyfikować przypadki użycia

Prawdopodobnie najlepszym sposobem na odkrycie przypadków użycia jest zadanie pytań:

1. Kto korzysta z systemu?

2. Jakiego celu chce osiągnąć każdy aktor?

3. Jakie usługi oferuje system?

4. Jakie zdarzenia wywołują zachowanie systemu?

5. Z jakimi systemami zewnętrzny musi się system komunikować?

6. Jakie zachowanie jest zawsze wymagane?

7. Jakie zachowanie jest opcjonalne lub warunkowe?

Dla każdego aktora wymień ich cele:

Cel powinien mieć sens dla aktora. Unikaj przekształcania każdej małej operacji systemowej w przypadki użycia.

6. Zasady nadawania nazw

Używaj jasnych, skierowanych na cel nazw.

Dobre przykłady:

• Utwórz konto

• Zaktualizuj profil

• Zgłoś roszczenie

• Śledź przesyłkę

• Zatwierdź prośbę

• Wygeneruj fakturę

Unikaj nieprecyzyjnych nazw:

• Przetwarzanie systemu

• Obsługuj dane

• Funkcja użytkownika

• Uruchom operację

Unikaj nadmiernych szczegółów technicznych:

• Wykonaj zapytanie SQL

• Wywołaj punkt końcowy REST

• Zainicjuj PaymentService

Mogą to być poprawne kroki implementacyjne, ale zazwyczaj nie są użyteczne jako przypadki użycia najwyższego poziomu.

7. Przykład: System zarządzania biblioteką

Załóżmy, że system biblioteczny obsługuje:

• Członkowie poszukujący książek

• Członkowie wypożyczające książki

• Członkowie zwracające książki

• Bibliotekarze zarządzający katalogiem

• Powiadomienia o przeterminowanych zadaniach

• Przetwarzanie płatności za grzywny

Możliwi aktorzy:

• Członek

• Bibliotekarz

• Usługa powiadomień

• Usługa płatności

Możliwe przypadki użycia:

• Wyszukiwanie katalogu

• Wypożyczenie książki

• Zwrócenie książki

• Oblicz grzywnę

• Zapłać grzywnę

• Zarządzanie katalogiem

• Wyślij powiadomienie o przeterminowaniu

Związki:

• Wypożyczenie książki zawiera sprawdzenie członkostwa.

• Wypożyczenie książki zawiera sprawdzenie dostępności książki.

• Zwrócenie książki zawiera obliczanie grzywny.

• Zapłata grzywny współdziała z usługą płatności.

• Wysyłanie powiadomienia o przeterminowaniu współdziała z usługą powiadomień.

8. Przykład PlantUML

Poniższy kod PlantUML tworzy diagram przypadków użycia dla systemu bibliotecznego:

@startuml
kierunek od lewej do prawej

tytuł System zarządzania biblioteką – diagram przypadków użycia

aktor Członek
aktor Bibliotekarz
aktor "Usługa powiadomień" jako Powiadomienie
aktor "Usługa płatności" jako Płatność

prostokąt "System zarządzania biblioteką" {

  przypadki użycia "Wyszukaj katalog" jako UC_Wyszukaj
  przypadki użycia "Wypożycz książkę" jako UC_Wypożycz
  przypadki użycia "Zwróć książkę" jako UC_Zwróć
  przypadki użycia "Sprawdź członkostwo" jako UC_SprawdźCzłonkostwo
  przypadki użycia "Sprawdź dostępność książki" jako UC_SprawdźDostępność
  przypadki użycia "Oblicz grzywnę" jako UC_ObliczGrzywnę
  przypadki użycia "Zapłać grzywnę" jako UC_ZapłaćGrzywnę
  przypadki użycia "Zarządzaj katalogiem" jako UC_ZarządzajKatalogiem
  przypadki użycia "Wyślij powiadomienie o przeterminowaniu" jako UC_WyślijPowiadomienie
}

Członek --> UC_Wyszukaj
Członek --> UC_Wypożycz
Członek --> UC_Zwróć
Członek --> UC_ZapłaćGrzywnę

Bibliotekarz --> UC_ZarządzajKatalogiem
Bibliotekarz --> UC_Wypożycz
Bibliotekarz --> UC_Zwróć

Płatność --> UC_ZapłaćGrzywnę
Powiadomienie --> UC_WyślijPowiadomienie

UC_Wypożycz ..> UC_SprawdźCzłonkostwo : <<include>>
UC_Wypożycz ..> UC_SprawdźDostępność : <<include>>
UC_Zwróć ..> UC_ObliczGrzywnę : <<include>>

UC_WyślijPowiadomienie ..> UC_Zwróć : <<extend>>

@enduml

9. Wyjaśnienie przykładu

Aktory

aktor Członek
aktor Bibliotekarz
aktor "Usługa powiadomień" jako Powiadomienie
aktor "Usługa płatności" jako Płatność

Diagram modeluje dwóch ludzkich aktorów oraz dwie zewnętrzne usługi.

Aliasy takie jak jako Powiadomienie ułatwiają późniejsze odwoływanie się do długich nazw.

Granica systemu

rectangle "System zarządzania biblioteką" {
    ...
}

Prostokąt określa zakres systemu. Przypadki użycia znajdujące się wewnątrz prostokąta są dostarczane przez system biblioteki.

Powiązania aktora

Członek --> UC_Wyszukaj
Członek --> UC_Wypożycz

Te powiązania pokazują, że członek może wyszukiwać katalog i wypożyczać książki.

Kierunek strzałki zwykle nie ma znaczenia semantycznego w diagramie przypadków użycia. Służy głównie do ułatwienia czytania diagramu.

Powiązania Include

UC_Wypożycz ..> UC_SprawdźCzłonkostwo : <<include>>
UC_Wypożycz ..> UC_SprawdźDostępność : <<include>>

Wypożyczenie książki zawsze wymaga sprawdzenia członkostwa i dostępności, dlatego są one modelowane jako dołączone przypadki użycia.

Powiązanie rozszerzające

UC_Powiadomienie ..> UC_Zwróć : <<extend>>

Oznacza to, że zachowanie powiadomienia o przekroczeniu terminu jest dodatkowym zachowaniem powiązanym z zwracaniem książki.

Jednak w rzeczywistym modelu wymagań bardziej naturalnym rozwiązaniem może być przypisanie „Wysyłanie powiadomienia o przeterminowaniu” do zaplanowanego procesu lub aktora takiego jak „Harmonogram biblioteki”. Najlepsza relacja zależy od rzeczywistych zasad biznesowych.

10. Szczegółowsza specyfikacja przypadku użycia

Diagram daje przegląd, ale każdy ważny przypadek użycia powinien zwykle mieć specyfikację tekstową.

Przypadek użycia: Wypożycz książkę

Diagram przypadków użycia nie powinien próbować zawierać wszystkich tych szczegółów. Diagram dostarcza mapy; specyfikacja dostarcza zachowania.

11. Odwołanie do składni PlantUML

Deklarowanie aktorów

aktor Klient
aktor "Brama płatności" jako Bramka

Deklarowanie przypadków użycia

użycie "Zamówienie" jako PlaceOrder
użycie "Przetwarzanie płatności" jako ProcessPayment

Tworzenie granicy systemu

prostokąt "Sklep internetowy" {
    użycie "Przeglądanie produktów" jako Browse
    użycie "Zamówienie" jako Order
}

Łączenie aktorów i przypadków użycia

Klient --> Browse
Klient --> Order

Zawieranie

Zamówienie ..> PrzetwarzaniePłatności : <<zawieranie>>

Rozszerzanie

ZastosujKupon ..> Zamówienie : <<rozszerzanie>>

Uogólnienie aktora

PremiumCustomer --|> Klient

Grupowanie pakietów

Pakiety mogą wizualnie grupować powiązane przypadki użycia:

rectangle "System bankowy" {
  package "Zarządzanie kontami" {
    usecase "Otwórz konto" jako OpenAccount
    usecase "Zamknij konto" jako CloseAccount
  }

  package "Płatności" {
    usecase "Przelej środki" jako TransferFunds
    usecase "Zapłać rachunek" jako PayBill
  }
}

Notatki

note right of PlaceOrder
  Klient musi być zautoryzowany
  przed złożeniem zamówienia.
end note

12. Ulepszanie układu diagramu

PlantUML automatycznie układają diagramy, ale kilka technik poprawia czytelność.

Kontrola kierunku

kierunek od lewej do prawej

Czasem jest to przydatne, gdy aktorzy powinni pojawiać się po bokach, a przypadki użycia w środku.

Inne powszechne kierunki to:

kierunek od góry do dołu

Użyj aliasów

Zamiast powtarzania długich nazw:

usecase "Weryfikacja tożsamości klienta" jako VerifyIdentity

Następnie odwołaj się:

RegisterAccount ..> VerifyIdentity : <<include>>

Zgrupuj powiązane przypadki użycia

Użyj pakietów lub zagnieżdżonych prostokątów do oddzielenia obszarów funkcjonalnych:

package "Zarządzanie zamówieniami" {
    usecase "Utwórz zamówienie" jako CreateOrder
    usecase "Anuluj zamówienie" jako CancelOrder
}

Unikaj nadmiernych przecięć

Diagram staje się trudny do odczytania, gdy zbyt wiele linii się przecina. Możesz go ulepszyć przez:

• Umieszczanie powiązanych aktorów blisko ich przypadków użycia

• Grupowanie przypadków użycia w pakietach

• Dzielenie jednego dużego diagramu na kilka mniejszych diagramów

• Używanie aliasów do jasnych odwołań

• Unikanie niepotrzebnych relacji

13. Powszechne błędy

Modelowanie funkcji wewnętrznych jako przypadków użycia

To zwykle jest zbyt techniczne:

Weryfikuj połączenie z bazą danych
Serializuj żądanie
Wywołaj interfejs API płatności

Preferuj cele o znaczeniu zewnętrznym:

Zapłać
Zgłoś wniosek
Wygeneruj raport

Traktowanie każdego aktora jako osoby

Zewnętrzne systemy i urządzenia mogą również być aktorami:

• Brama płatności

• Dostawca tożsamości

• System magazynowy

• Skanner kodów kreskowych

• Usługa powiadomień

Używając include dla opcjonalnego zachowania

Jeśli zachowanie jest opcjonalne, użyjextend zamiast include.

Niepoprawnie:

Zamówienie ..> Zastosuj kupon : <<include>>

Jeśli zastosowanie kuponu jest opcjonalne, użyj:

Zastosuj kupon ..> Zamówienie : <<extend>>

Używając extend dla zachowania wymuszonego

Jeśli zachowanie zawsze występuje, powinno być zazwyczaj modelowane za pomocądołącz.

Zamówienie ..> Uwierzytelnij klienta : <<dołącz>>

Łączenie przypadków użycia bezpośrednio bez sensu

Linia między dwoma przypadkami użycia powinna reprezentować ważną relację UML. Unikaj dowolnych połączeń, które jedynie sugerują, że przypadki użycia są jakimś sposobem powiązane.

Tworzenie jednego ogromnego diagramu

Diagram przypadków użycia powinien jasno przekazywać informacje na wysokim poziomie. Jeśli zawiera dziesiątki aktorów i przypadków użycia, stwórz kilka diagramów uporządkowanych według podsystemu lub obszaru działalności.

Pokazywanie kolejności

Diagram przypadków użycia nie pokazuje, że jeden przypadek użycia następuje przed drugim. Do pokazania kolejności użyj diagramu sekwencji lub diagramu działania.

14. Kiedy używać innych diagramów UML

Diagramy przypadków użycia są najlepsze do przedstawienia zakresu systemu i celów użytkownika. Połącz je z innymi diagramami, gdy potrzebne są szczegółowe informacje:

15. Zalecany proces modelowania

1. Zdefiniuj granice systemu.

2. Zidentyfikuj wszystkich zewnętrznych aktorów.

3. Zidentyfikuj cele każdego aktora.

4. Przekształć te cele w przypadki użycia.

5. Połącz aktorów z przypadkami użycia, w których uczestniczą.

6. Zidentyfikuj wymagane zachowanie ponownie używalne i zamodeluj je za pomocą <<include>>.

7. Zidentyfikuj opcjonalne lub warunkowe zachowanie i zamodeluj je za pomocą <<extend>>.

8. Dodawaj generalizację tylko tam, gdzie istnieje rzeczywista relacja „jest rodzajem”.

9. Przejrzyj diagram razem z zaangażowanymi stronami.

10. Dodaj specyfikacje tekstowe dla ważnych przypadków użycia.

11. Podziel diagram, jeśli stanie się zbyt zatłoczony.

16. Skompaktowany szablon PlantUML

Możesz użyć tego jako punktu wyjścia:

@startuml
kierunek od lewej do prawej

tytuł Diagram przypadków użycia systemu

aktor Użytkownik
aktor "System zewnętrzny" jako ExternalSystem

prostokąt "Nazwa systemu" {
  przypadki użycia "Główny cel użytkownika" jako MainGoal
  przypadki użycia "Wymagana wspólne zachowanie" jako RequiredBehavior
  przypadki użycia "Opcjonalne zachowanie" jako OptionalBehavior
}

Użytkownik --> MainGoal
ExternalSystem --> MainGoal

MainGoal ..> RequiredBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

@enduml

Głównym założeniem jest modelowanie widocznych z zewnątrz celów, a nie szczegółów implementacji wewnętrznej. Dobry diagram przypadków użycia umożliwia natychmiastowe zrozumienie granic systemu, aktorów, możliwości oraz ważnych zależności.

Odwołanie

Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文