„Stanęłam przed wyzwaniem analizy wstecznej systemu, w którym wszystkie procesy są wywoływane przez system, nie ma żadnych użytkowników biznesowych. System sam pobiera dane z zewnętrznego źródła, przetwarza je i wysyła (lub odbiera) informację do innego systemu. Kto w takim przypadku powinien być aktorem na diagramie przypadków użycia? Modelowany system? Czy może konkretny komponent tego systemu? Większość przykładów w literaturze i Internecie bazuje na przykładach, w których mamy interakcję człowiek – system.”
Skoro mówimy o aktorze na diagramie przypadków użycia UML, to zajrzyjmy do specyfikacji UML. Cóż takiego mamy tam o aktorze?
„An Actor specifies a role played by a user or any other system that interacts with the subject.”
Aktor nie musi być człowiekiem. Może być również systemem współpracującym z przedmiotem, analizowanym przez nas zakresem – systemem, komponentem czy klasą.
Ważne jest słowo „innym”, co oznacza, że nie można wrzucać analizowanego systemu lub jego części (tożsamej z analizowanym obszarem) jako aktora.
Ważne jest też to, że nie znajdujemy tu „or time”. Aktor typu „czas” nie występuje w definicji aktora diagramu UML.
Aktor może być też sprzętem.
„Actors may represent roles played by human users, external hardware, or other systems.”
„NOTE. An Actor does not necessarily represent a specific physical entity but instead a particular role of some entity that is relevant to the specification of its associated UseCases. Thus, a single physical instance may play the role of several different Actors and, conversely, a given Actor may be played by multiple different instances.”
Czyli Jan Kowalski, będąc managerem, nie musi jedynie w takiej roli występować na diagramie. Jeśli będzie potrzebował wykonać akcję jako pracownik firmy (którym również jest), wejdzie w rolę „pracownik”. Analogicznie – rola zewnętrznego systemu, komponentu, czy klasy nie musi mieć nazwy tożsamej z nazwą instancji. Można nazwać rolę w jaką wchodzi, wykonując określone działanie.
„Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors”
Czy z jednym przypadkiem użycia można powiązać więcej niż jednego aktora? Patrząc na ten opis – można. Czy można nie tylko tego, który wywołuje przypadek użycia, czy korzysta z jego rezultatów, ale także tego, który po prostu bierze w nim udział?
I tu mam problem. Teraz będzie moja opinia i moja praktyka, nie wyciąg ze specyfikacji UML. Wrzucam na diagram przypadków użycia aktorów, którzy korzystają z rezultatów przypadków użycia, wywołują je, na zasadzie usługi. Aktor potrzebuje usługi, analizowany system mu ją świadczy. Nie wiążę z przypadkiem użycia aktorów, którzy biorą udział w realizacji na którymś z etapów jako komponenty techniczne. Dlaczego? W mojej opinii zmniejsza to przejrzystość. Jeśli diagram przypadków użycia ma pokazywać wymagania co do systemu (co to ma robić), to chcę widzieć dla kogo jaka usługa jest oferowana, a nie szczegóły – w jaki sposób to wymaganie zrealizuję, np. przy pomocy jakich komponentów, systemów zewnętrznych. Na decyzje projektowe (jak to ma robić) przychodzi czas na kolejnych diagramach UML (np. komponentów, sekwencji), w kolejnych fazach analizy.
„UseCases define the offered Behaviors of the subject without reference to its internal structure.”
Zatem bez sensu są aktorzy typu „Algorytm liczący”, które stanowią część analizowanego zakresu.
Bez sensu są przypadki użycia typu „zapisuję X do bazy danych”. Interesuje nas to, co się dzieje na powierzchni – w interakcji system – aktor, nie poniżej. Do tego, co się dzieje wewnątrz analizowanego zakresu służą inne diagramy UML.
Jak już jesteśmy przy tym, to warto wspomnieć:
„When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject.”
Przypadek użycia musi dawać wartość aktorowi. Nie mają sensu przypadki użycia typu „wybranie metody płatności”. Wszedłeś, wybrałeś metodę płatności i wyszedłeś. I co z tego? Samo w sobie jest to bezwartościowe. Dopiero w kontekście dobrego kandydata na przypadek użycia np. „Opłacenie zamówienia” nabiera to sensu.
„It is deemed complete if, after its execution, the subject will be in a state in which no further inputs or actions are expected and the UseCase can be initiated again, or in an error state.”
Wszelkie przypadki użycia, które nie kończą się pełnym sukcesem – tak, że po ostatnim kroku nie ma już potrzeby przechodzenia do kolejnego kroku, bo wartość dla aktora została dostarczona (lub błędem), nie są przypadkami użycia.
Przykładowo: wybranie formy płatności (i co z tego?), wybranie godziny zajęć, przekazanie danej, która nie stanowi potrzebnego kompletu.
A wracając do pytania…
Na diagramie przypadku użycia aktorem będzie inny system lub komponent (będący poza zakresem analizowanego obszaru), który korzysta ze świadczonej usługi, efektów dostarczanego zachowania analizowanego obszaru. Nie może być nim analizowany obszar.
Na przykładzie danych pogodowych…
