Wstęp
W niedawno napisanym artykule na temat przypadków użycia i ich definicji zgodnej z UML, wskazywałem między innymi, że:
Przypadki użycia są sposobem na uchwycenie [wskazanie] wymagań stawianych systemom, tzn. tego, co systemy mają robić [powody, dla których one powstaną, co będą realizowały] na rzecz i na żądanie Aktora.
źr.: Diagram Przypadków Użycia UML – Jarosław Żeliński IT-Consulting
Sama specyfikacja UML o aktorze, jako elemencie wokół systemu, mówi bardzo niewiele, poza rozdziałem dotyczącym przypadków użycia:
Przypadki użycia są sposobem na uchwycenie wymagań systemów, czyli tego, co systemy mają robić. Kluczowymi pojęciami określone w tym rozdziale to Aktorzy, Przypadek Użycia i Przedmiot Modelowania. Każdy Przedmiot Modelowania reprezentuje analizowany system, do którego dany Przypadek Użycia ma zastosowanie. Użytkownicy i wszelkie inne systemy, które mogą wchodzić w interakcję z tematem są reprezentowane jako Aktorzy.
(rozdz. 18)
aktor jest wymieniany w rozdziale Pakiet zawierającym definicję pojęcia Model:
Model jest opisem systemu, gdzie “system” rozumiany jest w najszerszym znaczeniu i może obejmować nie tylko oprogramowanie i sprzęt, ale także organizacje i procesy. Opisuje on system z pewnej perspektywy (punktu widzenia), w Unified Modeling Language 2.5.1 także pewnej kategorii interesariuszy (np. projektantów, użytkowników lub klientów systemu) i na pewnym poziomie abstrakcji. Model jest kompletny w tym sensie, że obejmuje cały system, choć tylko te aspekty, które są istotne z punktu widzenia jego celu. (tj. w ramach danego poziomu abstrakcji i punktu widzenia) są reprezentowane w Modelu.
(rozdz. 12)
i dalej czytamy:
Model może również zawierać elementy opisujące odpowiednie części środowiska systemu. Środowisko jest zwykle modelowane przez aktorów i ich interfejsy.
(rozdz. 12)
i dlatego warto mu – aktorowi – się lepiej przyjrzeć.
Aktor systemu
W specyfikacji UML czytamy:
Aktor modeluje rodzaj roli odgrywanej przez zewnętrzny podmiot, który wchodzi w interakcję z Przedmiotem Modelowania [systemem] poprzez powiązane z nim Przypadki Użycia […]. Aktorzy mogą reprezentować role odgrywane przez ludzkich użytkowników, zewnętrzny sprzęt lub inne systemy.
(rozdz. 18)
Podsumowując powyższe, przykładowy diagram przypadków użycia można przedstawić tak:
Model powyższy przedstawia System (przedmiot naszego zainteresowania), dwie usługi jakie ten system świadczy użytkownikowi, którym człowiek (‘human’). Na diagramie pokazano także, że istnieje interesariusz (tu członek zarządu). Nasz system korzysta (wymagany jest interfejs, API) z usług zewnętrznej aplikacji i urządzenia.
Aktor jako ludzki użytkownik
Skupimy sie na aktorze będącym człowiekiem i na pojęciu “persona”:
W obszarze zarządzania produktami, typową, najczęściej spotykaną, definicją pojęcia persona jest:
…profil typowego klienta produktu. Persony są wykorzystywane, aby pomóc menedżerowi produktu (i innym osobom w organizacji zaangażowanym w rozwój produktu) zrozumieć kluczowe cechy, zachowania, cele, obowiązki i potrzeby określonego typu użytkownika.
(źr.: What is a Persona? | Definition and Overview (productplan.com)
Rzeczom wokół nas nadajemy nazwy. Definiowane są one na co dzień z pomocą definicji opisowych (definicja sprawozdawcza to typowa definicja słownikowa), oraz definicji realnych (to rzadziej używane definicje atrybutowe) . Związki między nazwą, rzeczą oznaczoną tą nazwą, oraz definicją tego co ta nazwa oznacza, opisuje tak zwany trójkąt semiotyczny (nazwany także trójkątem Ullmanna):
Naszym celem jest tu precyzyjne zdefiniowanie aktora, kim on jest w kontekście projektowania oprogramowania. W związku z powyższym możemy definicje zbudować opisowo i taka opisowa definicja w większości przypadków będzie zrozumiała dla człowieka i wystarczająca na początkowym etapie analizy i projektowania. Jednak komputer nie jest w stanie przetwarzać takiej definicji inaczej, niż ciągu znaków będącym treścią zrozumiałą tylko dla człowieka.
Dlatego potrzebna jest także definicja realna czyli atrybutowa. Definicja taka to określone atrybuty definiowanej (określanej) rzeczy i ich wartości. Ma ona kluczowe zalety: jest jednoznaczna, jest możliwa do wyrażenia w postaci klasyfikatora, można ją wykorzystać do maszynowego przetwarzania (komputer).
Popatrzmy na poniższy przykład:
Zdefiniowano zakres systemu: Zarządzanie produktami, Wysyłki, Przeglądanie oferty, Składanie zamówień. Tym razem skupimy się na “ludzkich” aktorach:
- Aktor: Pracownik firmy sprzedającej (osoba)
- Aktor: Klient (osoba)
Pierwszy atap analizy: opisanie “prozą” (definicje opisowe) aktorów w celu: 1. zrozumienia kim są, 2. określenia czym się różnią między sobą. Opisując “standardowego” pracownika firmy prowadzącej sklep internetowy możemy powiedzieć, że jest to osoba która:
jest formalnie zatrudniony w firmie, dla której pracuje, ma kwalifikacje do samodzielnej pracy z formularzami ekranowymi zawierającymi informacje o produktach, jako pracownik posiada wiedzę na temat branży pozwalającą samodzielnie opisać cechy oferowanego produktu w sposób wzbudzający zainteresowanie klientów
Opisując “typowego” klienta możemy powiedzieć, że:
posiada uznawane za standardowe umiejętności i doświadczenie w dokonywaniu zakupów przez internet, posiada konto w banku, sprawnie posługuje się przeglądarką internetową
Powyższe opisy są dość proste, bo ich celem było zwrócenie uwagi na istotę i cel ich tworzenia: są to “sprawozdawcze” definicje typów tych ludzi, i zapewne w realnie prowadzonym projekcie były by bardziej wyczerpujące. Celem ich tworzenia jest zrozumienie, dla kogo projektowany jest system. Mając tę wiedzę można z większym zrozumieniem zaprojektować graficzny interfejs użytkownika, lepiej opracować opis użytkownika (dane czyli jego atrybuty) w systemie (np. formularz profilu) i lepiej opracować scenariusz dialogu aktor – system.
Definicje realne (atrybutowe) są konieczne dla realizowania logiki dziedzinowej (tak zwane reguły biznesowe). Logika opisująca np. uprawnienia, śledzenie wykonawców itp. wymaga ustalenia atrybutów tych osób, te muszą być przechowywane przez system:
Tak więc realizacja reguły ustalającej np. uprawnienia pracownika do wykonania korekty zamówienia wymaga ustalenia wartości atrybutu stanowisko, o ile na tym atrybucie będzie zbudowana te reguła.
Z perspektywy modelowania z użyciem metod obiektowych i notacji UML mówimy o aktorach. Z perspektywy analizy biznesowej, w tym także modelowania procesów biznesowych z użyciem notacji BPMN, mówimy o rolach. Zawsze na początkowym etapie pracy operujemy pojęciami odnoszącymi się do osób i ich ogólnej charakterystyki. Musimy odróżniać klienta od pracownika, są to różne typy użytkowników naszych aplikacji. A jak odróżniamy szefa od podwładnego? Właśnie po to budujemy definicje atrybutowe: to wartość atrybutu stanowisko! Nie tworzymy żadnego “diagramu aktorów”!. Na diagramie przypadków użycia aktorem jest klasa (w UML wszystko jest klasą). Ta ma atrybuty i to one służą do identyfikowania konkretnych osób lub ich typów, reprezentowanych na diagramie jako klasa użytkowników. Diagram przypadków użycia nie służy np. do modelowania uprawnień, od tego są reguły biznesowe, jednak by możliwe było ich budowanie, np. systemu uprawnień, musimy dysponować zestawem cech aktorów – to ich atrybuty – i przyporządkować im wartości.
Jak widać, pokazane powyżej profile, pozwalają takie reguły budować. Są to dwa odrębne profile, bo innymi atrybutami opisujemy pracownika a innymi klienta. Ale więcej “ludzkich” aktorów już tu nie ma. W systemie będącym sklepem potrzebujemy minimalnego zestawu atrybutów, wystarczającego do realizacji logiki biznesowej (reguły biznesowe). Aktorów mamy dwóch bo mamy tylko dwa typy użytkowników. Profil pracownika jest ubogi, bo są to dane pobierane z systemu HR, zakładamy, że tam są pełne dane pracownika, tu potrzebujemy małej części z nich.
Podsumowanie
Pojęcie persony ma rodowód w nauce o psychologii. Jest bardzo wygodne jako model, personifikacja (archetyp) typu ludzkiego aktora aplikacji .
Szczegółowy opis typów użytkowników powinien być jednym z pierwszych etapów definiowania zakresu projektu, gdyż to użytkownik będzie pracował z aplikacją jako narzędziem.
Nie znaczy to jednak, że przyszły faktyczny użytkownik ma koniecznie brać udział określaniu tej roli. Persona to idealizacja, jej celem jest zbudowanie modelu użytkownika jako aktora, nie jest tu celem odwzorowywanie realnych i nie raz “ułomnych” osób (np. nielubiących przestrzegać prawa).
Zrozumienie kim są i jakimi cechami wyróżniają się ludzcy aktorzy systemu, pozwala znacznie lepiej zaprojektować ich profile w systemie. To zaś w dużym stopniu decyduje o jego jakości.
Dodatek
Kilka słów o typowych błędach. Błędem nazywam tu stosowanie niezdefiniowanych w UML konstrukcji lub nieprawidłowe stosowanie istniejących.
- ‘business use case’ i ‘business actor’, są to pojęcia z popularnej w drugiej połowie lat 90-tych metodyki RUP (Philippe Kruchten, Rational Unified Process), graficznie obrazowanej jako standardowe symbole aktora i przypadku użycia UML z przekreśleniem, pojęć tych nigdy nie było w formalnej specyfikacji UML.
- “diagram aktorów”, jako drzewiasta struktura dziedziczenia zbudowana z aktorów (spotykana chyba tylko na stronach SPARX) nie oparcia w UML (dziedziczenia nie ma w UML od 2015 roku), po drugie modelowanie uprawnień z użyciem dziedziczenie jest ontologicznie nie do obrony, gdyż związek między np. przełożonym a podwładnym nie przenosi ich uprawnień: nie jest prawdą ani to, że przełożony może zastąpić podwładnego ani to, że podwładny może zastąpić w czymkolwiek przełożonego.
- dziedziczenie między przypadkami użycia jest konstrukcją całkowicie pozbawioną logiki: usługi aplikacyjne niczego nie współdzielą (są to hermetyzowane, niezależne komponenty i scenariusze),
- aktor jest klasyfikatorem a nie specyfikacją instancji, więc wyróżnianie na diagramie UC nazw stanowisk w tej samej organizacji jest pozbawione logiki,
- co do zasady przypadki użycia nie służą do modelowania architektury systemu czy kodu (“UseCases define the offered Behaviors of the subject without reference to its internal structure”, UML, Rozdz. 18.1.3.1), dlatego stosowanie związków ‘include’ oraz extend’ nie ma uzasadnienia, są nadal w specyfikacji UML z komentarzem, że diagramu tego można używać także w metodach strukturalnych, gdzie te konstrukcje mają zastosowanie np. jako modelowanie podprogramów,
- nie ma w UML czegoś takiego jak “skierowana asocjacja między aktorem a przypadkiem użycia”, co do zasady to aktor inicjuje interakcje z systemem a nie system z aktorem i nie trzeba tego pokazywać żadną “strzałką”.
Więcej na ten temat w cytowanym na początku artykule Diagram Przypadków Użycia UML.
