
Nie każdy współpracujący system to Aktor – czyli jak opisać wymagane interfejsy
Pojęcie aktora, integracji, interfejsów itp. stale się przewija w dokumentach wymagań, niejednokrotnie w sposób błędny co wprowadza zamęt w dokumentacji i zamęt w zrozumieniu problemu do rozwiązania.
Co znajdziemy w dokumentacji UML (UML 2.4.1. Superstructure 2011-08-05, rozdz. 16):
Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems that may interact with the subject are represented as actors. Actors always model entities that are outside the system. The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors.
Ogólnie: Przypadek Użycia oznacza konkretne (w określonym celu) użycie Systemu. Standardowo Przypadków Użycia używa się do opisania wymagań wobec przyszłego Systemu. Kluczowe pojęcia skojarzone z Przypadkami Użycia to Aktor i przedmiot opisu czyli System. Użytkownik lub inny system może wchodzić w interakcje z Systemem jako Aktor. Aktor to zawsze byt zewnętrzny względem Systemu (ale nie każdy nam znany). Wymagane zachowania (reakcje) Systemu są specyfikowane z pomocą jednego lub wielu przypadków użycia reprezentujących potrzeby Aktorów.
Aktorem jest więc zewnętrzny byt, który ma potrzebę użycia Systemu w konkretnym celu. Innymi słowy: Przypadek Użycia opisuje usługą świadczoną przez System dla jego Otoczenia. Użytkownicy tych usług to Aktorzy. Tak więc generalnie Przypadki Użycia to usługi Systemu jakie świadczy i są one inicjowane przez jego Aktorów czyli żądających obsługi. Kluczowe tu jest stwierdzenie: Aktor to ten, który inicjuje dialog z Systemem żądając obsługi.
Aby pokazać gdzie są problemy pokaże to dokładnie od końca. Jak ktoś nie jest analitykiem może od razu przejść na koniec :).
Integracja czyli komponenty i podsystemy
Powyżej mamy dość typową sytuację, w której mamy System projektowany, inny Zewnętrzny System 1, który już u nas funkcjonuje. Z systemu projektowanego będzie korzystał Użytkownik oraz kolejny inny Zewnętrzny System 2. Zewnętrzny oznacza tu „już istniejący” (zewnętrzny względem projektowanego).
Na diagramie (UML, diagram komponentów) użyto symboli komponent i interfejs. Warto wiedzieć, że interfejsy mają „dwa oblicza”. Co do zasady w UML (i metodach obiektowych) występuje pojęcie „użycia” to znaczy, że „coś żąda realizacji usługi od czegoś” albo jak kto woli „coś używa czegoś do realizacji swoich zadań”. Dlatego interfejsy dzielimy na oferowane i wymagane. Użytkownik używa Systemu (jest on dla niego narzędziem pracy) do realizacji swoich celów. Może to także robić (żądać obsługi) inny System.
Dwa typy interfejsów
Interfejs oferowany i wymagany to dwa różne „byty”. Ogólnie, jeżeli jeden system wysyła żądanie wykonania jakiejś usługi do drugiego, to pierwszy ma interfejs wymagany a drugi oferowany (i muszą być zgodne ;)). Zestaw poleceń „rozumianych” przez interfejs oferowany to „język”, który musi znać interfejs wymagany (system wywołujący). W praktyce wygląda to tak, że interfejs oferowany ma dokumentację, którą powinien dostać programista interfejsu wymaganego (wywołującego zdalny System).
Tak więc mamy już świadomość ról używający i używany (w UML pokazuje to związek użycia: strzałka z linii kreskowej z grotem wskazującym na system/obiekt wywoływany, świadczący usługę, patrz pierwszy diagram).
Od środka
Popatrzmy na „stworzony system”. System już po „napisaniu” mógł by wyglądać tak (użyto [[wzorców projektowych, w tym wzorca MVC]]):
Co tu mamy? Użytkownik to osoba korzystająca z Systemu Projektowanego. Każdy przypadek użycia ma swoją dedykowaną klasę, która „wie jak świadczyć daną usługę”. Model dziedziny odwzorowuje przetwarzane dane (Jakaś klasa, agregaty itp.), są klasy świadczące jakieś wewnętrzne usługi. W trakcie analizy i projektowania może się okazać, że jakaś potrzebna wewnątrz Systemu Projektowanego usługa jest już dostępna w sieci Zamawiającego, znamy Zewnętrzny System 1, który ją ma, sprawdzamy czy System ten ma interfejs do tej usługi lub czy można go napisać. (np. mamy już system kadrowo-placowy więc nie musimy po raz drugi implementować listy pracowników, możemy o dane pracownika prosić ten istniejący już zewnętrzny system).
W ramach projektu więc nie implementujemy drugi raz takiej usług (nie dublujemy jej w naszej sieci) tylko tworzymy interfejs, klasę która będzie wywoływała Zewnętrzny System 1, za każdym razem gdy usługa ta będzie wymagana. Nie pozwalamy na bezpośrednie wywołania z wnętrza naszego Systemu Projektowanego, bo to uzależni całe jego wnętrze od szczegółów obcego Systemu. Tworzymy „adapter” czyli „maskujemy” obcy system (Klasa «Interfejs» to ten adapter). Dzięki temu jego, Zewnętrznego Systemu 1, ewentualna wymiana nie zaowocuje przeróbkami naszego Systemu Projektowanego. Gdyby trzeba było zrezygnować z Zewnętrznego Systemu 1, klasę adaptera wypełnimy implementacją potrzebnych funkcji a reszta Systemu Projektowanego nie odczuje zmiany.
Mamy więc już projekt. A teraz wracamy do początku i narysujemy
Diagram przypadków użycia
który obrazuje powyższy projekt:
To jest to co zrozumie Klient, najprostszy diagram do pokazania, zawiera zakres projektu, granice systemu (najważniejsza rzecz) i aktorów (część różowa tylko dla lepszego zrozumienia treści artykułu). Inny System, jeżeli inicjuje akcję czyli żąda usługi także jest aktorem, ale System realizujący na nasze zlecenie jakieś usługi nie jest aktorem, jest tylko wywoływany, sam z siebie nie inicjuje żadnej akcji. On realizuje jakąś potrzebną nam funkcję.
Może się okazać, że Zewnętrzny system ma zarówno interfejs oferowany jak i wymagany, wtedy w projekcie, na diagramie przypadków użycia, warto operować nie nazwą zewnętrznego systemu (np. ERP który może mieć dziesiątki interfejsów oferowanych i wymaganych) a nazwą usługi (interfejs oferowany) lub zdarzenia (interfejs wymagany) będących przedmiotem takich akcji i zakresu projektu.
Diagram przypadków użycia to pierwszy test zrozumienia tego co i po co ma powstać. Jest to bardzo prosty diagram i dlatego każde uproszczenie lub niezrozumienie, prowadzi nie raz do poważnych nieporozumień a bywa, że do krachu projektu. To bardzo ważny diagram. Powie nam do czego Systemy Projektowany będzie używany, to cel sponsora. Na tej podstawie można wybrać gotowe oprogramowanie i testując je ocenić przydatność (nie radze wybierać gotowego oprogramowania na bazie prezentacji!). Ale diagram ten nigdy nie powie jaką logikę należy zaimplementować, dlatego w przypadku tworzenia oprogramowania konieczny jest jego projekt: model dziedziny systemu, jako kolejny etap projektu na oprogramowanie dedykowane. Przypomnę także, że przypadki użycia w wersji minimalnej powinny mieć opis:
- cel jego użycia (co Aktor chce osiągnąć)
- stan początkowy (wejście, dane wejściowe, itp.)
- stan końcowy (wyjście, dane wyjściowe itp.)
Tu zwracam uwagę, że powyższe to zarazem testy akceptacyjne otrzymanego oprogramowania.

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.