Najpierw wyznacz granicę systemu#

Aktorów i przypadki użycia rozpoznaje się względem konkretnego systemu, który jest przedmiotem modelowania. Zanim zapiszesz nazwę aktora, odpowiedz, co dokładnie znajduje się w granicy: aplikacja, usługa, urządzenie, proces czy większa organizacja. Ten sam uczestnik może być aktorem w modelu aplikacji, a elementem wewnętrznym w modelu całego przedsiębiorstwa.

Na diagramie przypadków użycia aktorzy znajdują się poza modelowanym podmiotem, a jego przypadki użycia — wewnątrz lub w obrębie granicy. Granica pomaga określić, które zachowanie system ma zapewniać i z jakimi zewnętrznymi rolami wchodzi w interakcję.

Zapisz granicę prostym zdaniem: „Modelowany system to portal sklepu internetowego; płatności realizuje zewnętrzna bramka”. Dzięki temu zespół nie pomyli funkcji portalu z funkcjami operatora płatności.

Aktor to rola zewnętrzna#

Aktor (actor) reprezentuje rolę odgrywaną przez osobę, organizację, urządzenie, usługę lub inny system, który pozostaje zewnętrzny wobec modelowanego podmiotu i wchodzi z nim w interakcję. Aktor nie jest konkretną osobą ani egzemplarzem programu. Jedna osoba może pełnić kilka ról, a tę samą rolę może pełnić wiele osób.

Przykłady aktorów w systemie sklepu to Klient, Operator sklepu i Bramka płatności. Nazwij ich rolą, a nie imieniem, stanowiskiem konkretnego pracownika ani technologią używaną do realizacji funkcji. „Klient” wskazuje odpowiedzialność w interakcji; „Anna Kowalska” jest osobą; „Chrome” zazwyczaj jest detalem klienta aplikacji, a nie aktorem biznesowym.

Aktor może inicjować przypadek użycia albo uczestniczyć w nim, dostarczając dane lub odbierając rezultat. Nie każdy aktor rozpoczyna przebieg. Usługa wysyłająca zdarzenie do systemu może być aktorem inicjującym; operator otrzymujący powiadomienie może być aktorem wspierającym.

Pytania pomocne przy znajdowaniu aktorów#

Przejrzyj wymagania i zapytaj:

  • Kto lub co uruchamia funkcję modelowanego systemu?
  • Kto dostarcza dane wejściowe albo odbiera wynik?
  • Jakie organizacje lub systemy zewnętrzne wymieniają z nim informacje?
  • Kto administruje systemem, konfiguruje go lub utrzymuje?
  • Jakie zewnętrzne urządzenia, czujniki, harmonogramy lub usługi przekazują zdarzenia?
  • Kto otrzymuje wartość z zachowania systemu, nawet jeśli sam nie klika przycisku?

Potem sprawdź każdy kandydat: czy naprawdę znajduje się poza ustaloną granicą? Czy wymienia informacje lub sygnały z systemem? Czy nazwa wskazuje rolę, a nie osobę, interfejs albo wewnętrzny moduł? Jeśli element jest wewnątrz modelu, zwykle nie jest aktorem wobec tego modelu; może nim zostać po zmianie poziomu abstrakcji.

Przypadek użycia opisuje cel i wartość#

Przypadek użycia (use case) opisuje zachowanie systemu prowadzące do obserwowalnego rezultatu istotnego dla aktora lub innego interesariusza. Nazwa powinna wyrażać cel, najczęściej czasownikiem i dopełnieniem: Złożyć zamówienie, Zweryfikować płatność, Wypłacić gotówkę.

Nie zapisuj każdego kliknięcia, ekranu ani wewnętrznej operacji jako osobnego przypadku użycia. Nacisnąć przycisk Zapisz opisuje działanie interfejsu, a niekoniecznie cel użytkownika. Przetworzyć rekord może być zadaniem wewnętrznym bez zewnętrznego celu. Takie kroki mogą należeć do scenariusza przypadku użycia, procedury albo modelu projektu.

Przypadek użycia to nie tylko elipsa na diagramie. Pełny opis często zawiera cel, warunki wstępne, wyzwalacz, główny scenariusz, alternatywy, wyjątki, warunki końcowe i wymagania specjalne. Diagram daje przegląd granicy, aktorów i nazwanych zachowań; scenariusz objaśnia przebieg szczegółowo.

Od opisu do aktorów i celów#

Załóżmy, że wymaganie brzmi: „Klient wybiera produkty i składa zamówienie. Sklep sprawdza dostępność, pobiera płatność i wysyła potwierdzenie. Operator może uzupełnić ofertę. Bramka płatnicza zwraca wynik autoryzacji”.

  1. Ustal podmiot. Jeśli modelujesz system sklepu, wewnątrz są jego funkcje; klient, operator i zewnętrzna bramka leżą poza granicą.
  2. Rozpoznaj role. Klient składa zamówienie, Operator zarządza ofertą, a Bramka płatnicza współpracuje przy autoryzacji.
  3. Sformułuj cele. Złożyć zamówienie i Uzupełnić ofertę są kandydatami na przypadki użycia. Otrzymać autoryzację może być celem systemu względem zewnętrznej usługi albo fragmentem przypadku użycia sklepu — zależnie od zakresu i celu modelu.
  4. Sprawdź rezultat. Dla każdego przypadku wskaż rezultat widoczny z zewnątrz, np. zarejestrowane zamówienie albo zaktualizowaną ofertę.
  5. Zapisz warianty w scenariuszu. Brak produktu lub odmowa płatności są zwykle alternatywnymi przebiegami realizacji celu, a nie automatycznie osobnymi przypadkami użycia.
  6. Zweryfikuj z interesariuszami. Zapytaj, czy rozpoznają role i czy nazwy opisują ich rzeczywiste cele.

To jest sposób analizy, a nie mechaniczny algorytm. Jedno wymaganie może obejmować kilka celów, a jeden przypadek użycia może wynikać z wielu zdań w dokumentacji.

Poziomy celu i zakres przypadków użycia#

Cele można opisywać na różnych poziomach. Zarządzać sklepem jest bardzo szerokie i może składać się z wielu celów. Kliknąć ikonę koszyka jest zbyt szczegółowe i opisuje mechanizm interfejsu. Dobierz poziom do zakresu systemu, odbiorcy modelu i tego, jak przypadek będzie później analizowany lub testowany.

Przydatne pytanie kontrolne brzmi: czy po wykonaniu przypadku użycia aktor może uznać, że osiągnął konkretny rezultat? Jeśli nie, nazwa może opisywać podkrok albo szeroką kategorię zamiast samodzielnego celu.

Granica celu zależy od kontekstu. Autoryzować płatność może być pełnym celem w systemie bramki, ale tylko podprzebiegiem w sklepie. Nazewnictwo i struktura muszą wynikać z modelowanego podmiotu, a nie z uniwersalnej listy poprawnych przypadków użycia.

Relacje między aktorami i przypadkami użycia#

Zwykłe powiązanie aktora z przypadkiem użycia wskazuje jego udział w interakcji. Nie określa dokładnej kolejności kroków ani kanału komunikacji. Nie używaj go jako ogólnej strzałki zależności.

Relacja include oznacza włączenie zachowania innego przypadku użycia. Powinna być uzasadniona powtarzalnym lub wydzielonym fragmentem, którego wykonanie jest częścią przebiegu bazowego. Relacja extend wskazuje zachowanie dołączane warunkowo do przypadku bazowego w określonym punkcie rozszerzenia. Kierunek strzałek ma znaczenie: include prowadzi do przypadku włączanego, a extend od rozszerzającego do bazowego.

Uogólnienie aktorów lub przypadków użycia może wyrażać wspólną rolę albo zachowanie. Wprowadzaj je tylko wtedy, gdy relacja dziedziczenia wyjaśnia model; nie dodawaj jej jedynie po to, by diagram miał więcej połączeń. Rozbudowane warunki i przebiegi zwykle czytelniej zapisać w opisie scenariusza niż za pomocą wielu relacji include i extend.

Waliduj model z użytkownikami i scenariuszami#

Przeczytaj nazwy przypadków użycia z punktu widzenia aktora: „Jako klient chcę złożyć zamówienie”. Sprawdź, czy aktor rzeczywiście uczestniczy w tym celu, czy granica systemu jest jasna i czy rezultat jest obserwowalny. Odtwórz główny scenariusz oraz istotne alternatywy, takie jak odmowa płatności.

Przeglądaj role z różnymi interesariuszami. Użytkownik może znać codzienny przebieg, administrator — konfigurację, a właściciel procesu — reguły i wyjątki. Zgodność jednego diagramu z perspektywą pojedynczej osoby nie gwarantuje, że model uwzględnia wszystkie istotne role.

Typowe błędy#

  • Aktor nazwany konkretną osobą. Zastąp osobę rolą pełnioną wobec systemu.
  • Uznanie każdej osoby w organizacji za aktora. Aktorem jest rola uczestnicząca w interakcji z modelowanym podmiotem.
  • Umieszczenie wewnętrznego modułu poza granicą. Najpierw ustal zakres systemu.
  • Nazwy przypadków jako kroki interfejsu. Formułuj cel, a szczegóły UI pozostaw scenariuszowi lub projektowi.
  • Zbyt szeroki przypadek użycia. Rozbij go, jeśli obejmuje wiele niezależnych celów i różnych rezultatów.
  • Zbyt drobne przypadki użycia. Łączenie kliknięć i wewnętrznych operacji tworzy diagram bez wartości dla interesariuszy.
  • Każdy wyjątek jako oddzielny cel. Odmowa, walidacja i timeout często są alternatywnymi przebiegami podstawowego celu.
  • Traktowanie aktora jako użytkownika człowieka. Aktorem może być inny system, organizacja, urządzenie lub usługa.
  • Mylenie powiązania z kolejnością. Diagram przypadków użycia nie opisuje sekwencji kroków.
  • Nadużywanie include i extend. Relacje wymagają właściwej semantyki i kierunku.
  • Niejasna granica podmiotu. Bez niej nie da się rozstrzygnąć, co jest aktorem, a co częścią modelu.

Lista kontrolna#

  • Czy podmiot i jego granica są nazwane?
  • Czy każdy aktor jest rolą zewnętrzną wobec tego podmiotu?
  • Czy nazwy przypadków użycia wyrażają cele, a nie kliknięcia lub kroki implementacji?
  • Czy każdy przypadek ma zrozumiały, obserwowalny rezultat?
  • Czy warianty i wyjątki są oddzielone od głównego celu, ale nie rozbijają diagramu bez potrzeby?
  • Czy powiązania i kierunki include, extend oraz uogólnienia mają uzasadnienie?
  • Czy interesariusze potrafią rozpoznać swoje role i cele?

Rozpoznawanie aktorów i przypadków użycia jest analizą granicy, ról i celów. Poprawny model nie wynika z samego wyszukiwania rzeczowników w wymaganiach — wymaga ustalenia, kto wchodzi w interakcję z systemem, po co to robi i jaki rezultat ma otrzymać.