Często spotykam się w audytowanych projektach z pojęciem “Czas jako aktor”. Wyjaśnijmy sobie kilka rzeczy, w tym to, że Czas nie jest aktorem Systemu. Poniżej kilka wybranych pytań z dyskusji na ten temat.

Dialog

Pytanie: Jak w takim razie w ogólności modelować cykliczność? Np. “prenumerata czasopisma na okres 12 m-cy”, “codzienne generowanie raportu”, “zbieranie wskazań licznika co N jednostek czasu” ?

Jarek Żeliński: najpierw należy zrozumieć co się na prawdę dzieje i pamiętać, że na Diagramach UC (przypadków użycia) nie modelujemy upływu czasu a interakcje aktorów z systemem. Prenumerata czasopisma na 12 m-cy to obiekt w systemie reprezentujący np. dokument zamówienia tej prenumeraty (ma zapewne atrybut okres prenumeraty). Codzienne generowanie raportu, pytam kto inicjuje “co rano” raport? Bo sam się nie robi, albo jest to aktor, człowiek robiący to “z palucha” albo wewnętrzny serwis (demon), który reaguje na zdarzenia (sygnał czasu, np. raz na dobę generowany przez dedykowany do tego podsystem), taki serwis, generowanie raportu, to klasa mająca operację GenerujRaport. Jeżeli jednak obsługa takich zdarzeń ma miejsce wewnątrz Systemu do diagram UC nie jest miejscem na pokazywanie tego (przypominam, że na modelu UC system to “czarna skrzynka”).

Pytanie: Aktor “czas” pozwoliłby na dodanie tego do modelu przypadków użycia, ale czy model przypadków użycia jest właściwym miejscem ? Czy “lepiej” opisywać takie zachowania w specyfikacji dodatkowej?

J.Ż.: Jeżeli projektujemy bombę zegarową to jedynym aktorem jest człowiek ustawiający (raz :))) moment wybuchu, innych aktorów ta bomba nie ma. Moduł zegara to wewnętrzny moduł bomby zegarowej. Przypadek użycia to: “Ustawienie momentu wybuchu na określony czas”. Mechanizm, który doprowadzi do wybuchu to wewnętrzna konstrukcja bomby i zadaniem projektanta jest opracowanie jak to wymaganie zrealizować, a zadaniem programisty jest  implementacja tego wymagania (realizacja to kawałek kodu, budzik z drucikiem, itp..). Kwestia implementacji “upływu czasu” wyniknie z treści wymagania, pamiętamy, że UC to wymagania, usługi systemu dla aktora i taki UC powinien się nazywać “ustawienie godziny wybuchu” i już wiadomo o co chodzi – to tu jest miejsce na taką informację.

Na zakończenie

Łamanie zasad UML nie jest dobrym pomysłem. Od lat sprawdza mi się porzekadło, że “jeżeli czegoś nie potrafimy narysować to znaczy, że jeszcze tego nie rozumiemy”. Maskowanie braku wiedzy o tym “jak” kolejnymi nowymi symbolami to tylko “sprzedawanie” problemu dalej, bo jaki problem projektowy rozwiązuje stworzenie aktora Czas?.  Analityk to ktoś, kto analizuje by “zrozumieć”… a nie zapisuje jak dyktafon słowa np. zamawiającego.

Co do stereotypów (stereotyp “czas” dla aktora), nie służą one do łamania zasad a do poszerzania taksonomii pojęć UML i tu warto np. dla aktora użyć np. <<człowiek>> czy <<system>> ale skoro aktor to z definicji “coś mającego interakcję z Systemem” to czas nie spełnia tej definicji. Czyli nie można w profilu dodać aktorowi znaczenia “czas” bo pojęcie to nie mieści się w definicji aktora (semantyka tego pojęcia nie może być łamana przez profil).

Wiem, że są narzędzia, które “sugerują” użycie stereotypu czas dla aktora ale z pytaniami “dlaczego” zapraszam do ich dostawców… a co mówi specyfikacja? [[UML Superstructure]]  (OMG):

 16.3.1 Actor (from UseCases) An actor specifies a role played by a user or any other system that interacts with the subject.

Semantics: Actors model entities external to the subject. When an external entity interacts with the subject, it plays the role of a specific actor.

Pojęcie Aktor odgrywa rolę użytkownika lub innego Systemu mającego interakcje z modelowanym Systemem. Pojęcie Aktor modeluje byt zewnętrzny wobec modelowanego systemu. (przyp. J.Ż.)

Z perspektywy implementacji mam aktora i dwie możliwe sytuacje:

1. graficzny interfejs dla użytkownika jakim jest człowiek
2. programowy (np. transmisyjny) interfejs dla innego, zewnętrznego systemu.

Powyżej ilustracja z Wikipedii i kilka słów komentarza:

• Konsultant to klasyczny aktor (konkretna rola, człowiek),
• Dział sprzedaży już nie koniecznie, nie wiadomo kto, wolał bym jednak np. sprzedawca lub dyrektor sprzedaży,
• Systemy, nagrywarka czy kiosk multimedialny, to nic innego jak “jakiś zewnętrzny system”, implementacja interfejsu do nagrywarki niczym się nie różni od interfejsu do Systemu rezerwacji pokoi (pomijam to jakie konkretne polecenia są wysyłane) .
• Termin płatności to już zupełne pogwałcenie semantyki UML: jaką i jak realizowaną, interakcję ma Termin z Systemem?

Tak więc radzę ostrożnie z Wikipedią (staje się niestety zbiorem pseudowiedzy). Wprowadzanie pojęć ukrywających istotę rzeczy to moim zdaniem, ukrywanie niewiedzy na etapie analizy i projektowania. To jedna z przyczyn złej jakości procesu tworzenia oprogramowania. Niezależnie od tego jak ładnie umotywujemy istnienie aktora Czas, programista i tak musi ten problem rozwiązać i nie będzie to na pewno interfejs “interakcji Systemu z Czasem”…  A co z czasem? No cóż, albo człowiek klika co godzinę w coś, albo wewnątrz systemu jest moduł, który generuje zdarzenie wywołujące tę samą operację co klikający użytkownik… Moduł wewnętrzny systemu nie jest jego aktorem.

Jak w takim razie w ogólności modelować cykliczność? Np. “prenumerata czasopisma na okres 12 m-cy”, “codzienne generowanie raportu”, “zbieranie wskazań licznika co N jednostek czasu” ? Po pierwsze usługa systemu to odpowiednio: zarządzanie prenumeratami, generowanie raportów, przetwarzanie pomiarów. Prenumerata to zapis mówiący, że mam otrzymać np. każde wydanie jakiegoś periodyku w ciągu danego roku. Generowanie raportów to czynność człowieka (raport na życzenie) albo automatu reagującego na zdarzenie “konkretny czas”, zdarzenia takie generuje np. zegar systemowy. Zbieranie wskazań licznika to cykliczne zdarzenie inicjowane przez System. Implementacja tych wymagań to element projektowania logiki biznesowej i nie jest to już diagram przypadków użycia a model dziedziny systemu bo to tu jest logika biznesowa.

Ciąg dalszy w artykule:  Czas nie jest aktorem dla Systemu c.d. czyli projekt