Czym jest aktor#
Aktor (actor) w UML reprezentuje rolę, z której perspektywy zewnętrzny podmiot wchodzi w interakcję z modelowanym systemem. Aktorem może być człowiek, organizacja, urządzenie albo inny system. Aktor nie jest częścią wnętrza modelowanego systemu w danym diagramie przypadków użycia — znajduje się po jego zewnętrznej stronie i uczestniczy w realizacji celu.
Aktor oznacza rolę, a nie konkretną osobę ani konto. Jedna osoba może występować w różnych rolach, a wiele osób może pełnić tę samą rolę. Na przykład ta sama pracownica może być „Klientem” w systemie zakupowym i „Administratorem” w narzędziu do zarządzania kontami. Modeluj te role osobno, jeśli mają inne cele lub uprawnienia.
Klient jest zewnętrznym uczestnikiem, który inicjuje albo wspiera przypadek użycia „Złóż zamówienie”. Diagram nie twierdzi, że klient wykonuje wszystkie kroki samodzielnie ani że zna wewnętrzną implementację sklepu. Pokazuje granicę systemu, aktora i istotny cel interakcji.
Aktor podstawowy i pomocniczy#
W opisie scenariusza często wyróżnia się aktora podstawowego, który inicjuje przypadek użycia, aby osiągnąć cel, oraz aktorów pomocniczych, którzy dostarczają usług lub uczestniczą w realizacji. To użyteczne rozróżnienie analityczne, ale nie zawsze musi być osobną właściwością graficzną aktora w diagramie. Opisz role w tekście przypadku użycia, jeśli sam rysunek tego nie wyjaśnia.
Przykładowo klient może rozpocząć zakup, a zewnętrzny operator płatności uczestniczyć w autoryzacji. Operator jest aktorem względem sklepu, mimo że jest systemem, a nie osobą. W kontekście diagramu systemu płatniczego relacja może wyglądać inaczej — to, co jest aktorem, zależy od wybranej granicy systemu.
Granica systemu decyduje o aktorach#
To, czy dany element jest aktorem, zależy od zakresu diagramu. Jeśli modelujesz sklep, bramka płatnicza jest zewnętrznym aktorem. Jeśli modelujesz samą bramkę, sklep może być aktorem korzystającym z jej usług. Granica systemu nie jest granicą organizacji ani sieci; to decyzja o tym, co obejmuje konkretny model.
W diagramie przypadków użycia aktorzy znajdują się poza prostokątem systemu, a przypadki użycia — wewnątrz. Sama pozycja graficzna nie wystarczy, jeśli granica i nazwa systemu są niejasne. Podpisz zakres tak, by czytelnik wiedział, czyje zachowanie modelujesz.
Nazewnictwo i poziom szczegółowości#
Nazywaj aktora nazwą roli lub zewnętrznego systemu, na przykład Klient, Operator płatności, Administrator. Unikaj nazw konkretnych osób i niepotrzebnych nazw zespołów, które opisują strukturę organizacyjną zamiast interakcji z systemem.
Nie rozbijaj roli na wiele aktorów, jeśli prowadzi to do identycznego zachowania i nie wyjaśnia różnic. Jeśli istnieją wyspecjalizowane role, możesz modelować generalizację aktorów, ale tylko gdy rzeczywiście dzielą wspólne zachowanie. Podobieństwo stanowisk w firmie samo nie wystarcza.
Aktor a użytkownik i uprawnienia#
Aktor nie musi być użytkownikiem logującym się do aplikacji. Zewnętrzny system, automatyczny proces lub urządzenie również może wchodzić w interakcję z systemem. Z drugiej strony konkretna osoba może korzystać z systemu bez występowania jako odrębny aktor, jeśli diagram opisuje inną abstrakcję.
Aktor oznacza rolę uczestniczącą w interakcji, nie kompletny model autoryzacji. Diagram przypadków użycia nie określa sam z siebie, jak uwierzytelnia się aktora, jakie ma dokładne uprawnienia ani jakie dane może odczytywać. Te reguły można opisać osobno w wymaganiach, modelu bezpieczeństwa lub szczegółowym scenariuszu.
Typowe błędy#
- Aktor utożsamiony z osobą. Modeluj role, które mogą być pełnione przez wiele osób.
- System zewnętrzny pominięty. Aktorem może być usługa lub urządzenie, jeśli wchodzi w interakcję z modelowanym systemem.
- Granica systemu nieuwzględniona. Rola zewnętrzna zależy od zakresu konkretnego diagramu.
- Aktor umieszczony wewnątrz systemu. W typowym diagramie przypadków użycia aktor jest poza granicą, przypadek użycia — w środku.
- Aktor potraktowany jak uprawnienie. Sama rola nie definiuje zasad dostępu.
- Nadmierna liczba aktorów. Rozdzielaj role, gdy ich cele lub interakcje rzeczywiście się różnią.
- Nazwa osoby zamiast roli. Używaj nazw funkcji pełnionej wobec systemu.
Podsumowanie#
Aktor UML reprezentuje zewnętrzną rolę lub system uczestniczący w interakcji z modelowanym systemem. Jego znaczenie zależy od granicy systemu. Aktor nie jest konkretną osobą, kontem ani kompletnym opisem uprawnień; pokazuje perspektywę, z której realizowane są cele systemu.