Nie każdy użytkownik musi być aktorem na każdym diagramie#

Użytkownik jest aktorem w diagramie przypadków użycia wtedy, gdy jego rola uczestniczy w interakcji z systemem objętym granicą diagramu. Sam fakt, że ktoś korzysta z produktu w szerszym znaczeniu, nie wystarcza. Diagram może opisywać inny system, podsystem lub perspektywę, w której ta osoba nie wchodzi w bezpośrednią relację z modelowanym zakresem.

Aktor reprezentuje rolę, nie konkretną osobę. Ta sama osoba może używać systemu w kilku rolach, a wiele osób może pełnić jedną rolę. Dlatego nazwa aktora opisuje odpowiedzialność wobec systemu, na przykład Klient, Operator lub Administrator, a nie imię i nazwisko.

Kiedy użytkownik jest aktorem#

Użytkownik jest aktorem, jeśli w wybranym zakresie inicjuje przypadek użycia, uczestniczy w nim lub otrzymuje jego obserwowalny rezultat. Przykładowo pracownik działu obsługi może być aktorem w systemie reklamacyjnym, jeśli wyszukuje sprawy i podejmuje decyzje. Osoba przeglądająca publiczną stronę może być aktorem wobec systemu sprzedaży, jeśli model opisuje takie interakcje.

Aktor nie musi klikać interfejsu. Może korzystać z systemu przez API, terminal, urządzenie specjalistyczne lub kanał obsługiwany przez inny system. Z kolei użytkownik biznesowy może korzystać z wyniku raportu przygotowanego automatycznie, ale nie uczestniczyć w procesie modelowanym przez dany diagram.

Rola a osoba, konto i organizacja#

Osoba jest bytem rzeczywistym; konto to mechanizm uwierzytelnienia lub identyfikacji; rola to perspektywa zachowania wobec systemu. W diagramie przypadków użycia zwykle modeluje się rolę. Jedna osoba może używać różnych kont, konto może mieć wiele ról, a działania może inicjować automat lub zewnętrzna integracja.

Nie traktuj nazwy użytkownika w logach jako nazwy aktora modelu. Dla wymagań bezpieczeństwa może być ważne, kto fizycznie wykonał czynność, jakie konto użyto i jakie uprawnienia przydzielono — są to kwestie powiązane, ale odrębne od podstawowej notacji aktora.

Granica systemu rozstrzyga#

Aktor znajduje się poza systemem modelowanym na diagramie. Jeśli granica zmienia się z całej platformy na konkretną usługę, część użytkowników lub systemów zewnętrznych może przestać być aktorami albo stać się aktorami. Na przykład administrator może być aktorem dla panelu administracyjnego, a wewnętrzna usługa tożsamości — aktorem dla aplikacji, jeśli jest modelowana jako zewnętrzny dostawca.

Podpisz granicę i zakres, aby uniknąć niejasności. Nie określaj roli wyłącznie według tego, czy ktoś jest „wewnątrz firmy”, „pracownikiem” lub „ma konto”. Ważne jest, czy znajduje się poza modelowanym systemem i uczestniczy w jego przypadku użycia.

Aktor nie jest listą uprawnień#

Aktor pomaga uporządkować cele i relacje z systemem, ale nie definiuje samodzielnie polityki autoryzacji. Dwie role mogą korzystać z tego samego przypadku użycia, lecz mieć inne uprawnienia do konkretnych danych. Diagram może wskazać różnicę ról, ale dokładne zasady należy dopisać w wymaganiach, modelu bezpieczeństwa lub opisie przypadku użycia.

Nie twórz osobnego aktora dla każdego poziomu uprawnień, jeśli diagram nie wyjaśnia interakcji. Użyj generalizacji aktorów, gdy role szczegółowe dzielą wspólne zachowania i ten podział pomaga czytelnikowi. Jeśli różnica dotyczy wyłącznie ograniczenia widoczności danych, osobne reguły autoryzacji mogą być czytelniejsze.

Użytkownik pośredni i system zewnętrzny#

Użytkownik może korzystać z systemu poprzez inny system, na przykład klient wysyła formularz, a integracja przekazuje dane do usługi. W zależności od celu modelu aktorem może być bezpośredni użytkownik, pośredniczący system albo oba podmioty. Dodaj tylko tych uczestników, których udział jest istotny dla wymagań i zakresu.

Jeśli użytkownik nie widzi bezpośrednio modelowanego systemu, ale otrzymuje rezultat jego działania, może nadal być interesariuszem procesu, lecz niekoniecznie aktorem w tym konkretnym diagramie. Interesariusz, aktor i użytkownik to pojęcia, które mogą się pokrywać, ale nie są tożsame.

Pytania kontrolne#

  • Czy diagram ma jasno określoną granicę systemu?
  • Czy rola wchodzi z systemem w interakcję istotną dla celu diagramu?
  • Czy nazwa opisuje rolę, a nie konkretną osobę, konto lub stanowisko bez związku z zachowaniem?
  • Czy ten sam przypadek użycia może być osiągany przez innych aktorów?
  • Czy różnica między rolami dotyczy celu, czy tylko uprawnień?
  • Czy uczestnictwo jest bezpośrednie, pośrednie czy wyłącznie interesariuszowe?

Typowe błędy#

  • Każda osoba z kontem dodana jako aktor. Uwzględniaj role ważne dla zakresu modelu.
  • Aktor utożsamiony z kontem. Konto identyfikuje, rola opisuje udział wobec systemu.
  • Użytkownik wewnętrzny uznany za element systemu. Pozycję określa granica diagramu, nie organizacja.
  • Każdy użytkownik traktowany jako jeden aktor. Rozdziel role, gdy różnią się celami lub zachowaniem.
  • Aktor uznany za kompletną politykę dostępu. Szczegółowe uprawnienia wymagają osobnego opisu.
  • Interesariusz bez interakcji uznany automatycznie za aktora. Może być ważny dla projektu, lecz nie uczestniczyć w przypadku użycia.

Podsumowanie#

Użytkownik jest aktorem wtedy, gdy reprezentowana przez niego rola uczestniczy w interakcji z systemem określonym przez granicę diagramu. Nie modeluj automatycznie każdej osoby, konta czy interesariusza. Nazwij role zgodnie z celami, a zasady uprawnień opisz osobno, gdy są istotne.