Czy czas może być aktorem czy też nie oto jest pytanie? Jak zamodelować w konkretnym czasie aplikacji działanie? I inne tego typu pytania często są bolączką osób modelujących.
Otóż jest opinia, że, można traktować czas jako aktora. Wówczas aktor reprezentujący czas może przykładowo rozpoczynać przypadek użycia odpowiadający za przygotowanie informacji o zarobkach, raportu lub rozesłanie katalogu raz na kwartał.
Inne podejście polega na traktowaniu czasu jako części systemu. Gdy korzysta się z tej metody, wówczas przypadek użycia sam się uruchamia w określonym czasie. Aktor, który komunikuje się z tym przypadkiem użycia, to ten, który otrzyma wyniki prac systemu.
Moim skromnym zdaniem czas nie jest aktorem. Aktor to ktoś lub coś co otrzymuje z systemu. Co otrzymuje czas? Nic. Po drugie czas ma wiele postaci. Czas oczekiwania, czas pracy lub czas konserwacji. Jaki czas byłby aktorem? Dlatego też proponuję aby informacje dotyczące czasu rozpoczęcia działania danego scenariusza były zapisane w następujących miejscach w zależności od występowania:
wymagania: w postaci opisu tekstowego np.: System zaczyna backup codziennie o godzinie 17.
przypadek użycia: jeden z warunków początkowych
diagramy aktywności: jako jeden z elementów wymaganych do synchronizacji np.:
Jak widać na powyższym rysunku przygotowanie przelewów może nastąpić tylko w tedy gdy są obliczone kwoty wypłat i nastąpił dzień wypłaty.
W sumie tylko nasza inwencja twórcza i techniki notacji ograniczają nas w sposobach prezentacji czasu.
Podsumowując. Nawet notka z opisem jest lepsza niż używanie aktora do prezentowania czasu na diagramach UML
Bardzo ciekawy wywód :), na swój użytek mam taką definicję: aktor systemu to zewnętrzny byt, nie mający swojej reprezentacji w systemie, który prowadzi z systemem dialog. Tak wiec czas nie jest tu aktorem ale inny system jak najbardziej tak.
Problem Czasu leży moim zdaniem gdzie indziej: czas (ale nie upływ czasu) jest elementem modelu dziedziny systemu (w DDD modelowany jako tak zwany Value Object), i jest możliwe, że pewne operacje reagują na zdarzenie będące konkretnym momentem czasu, musi być jednak zaprojektowany obiekt publikujący takie komunikaty.
UML Infrastructure 2.4 BETA, strona 604, dział 16, podpunkt 16.3.1 czytamy:
„An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject). Actors may represent roles played by human users, external hardware, or other subjects. Note that UML Superstructure Specification, v2.4 605 an actor does not necessarily represent a specific physical entity”
czytając dalej w sekcji ograniczeń – Constraints:
„Actors model entities external to the subject.”
Sprawdźmy więc, czy powyższe kryteria spełnia teoretyczny Aktor czas:
– „exchanging signals”
TAK – AcceptTimeEvent z pakietu CompleteActions na Activity Diagram modeluje odebranie zdarzenia czasowego (notacja – strona 242, figure 11.21). Co oznacza, ze sygnały / zdarzenia, które inicjalizuje czas występują bezpośrednio na diagramie aktywności.
– „but which is external to the subject”
– „not necessarily a specific physical entity”
– „does not necessarily imply the technical definition”
TAK – czas nie ma odzwierciedlenia w postaci konkretnego bytu, czy implementacji. Jest traktowany jako zewnętrzny element systemu.
– „Actors may represent roles played by human users, external hardware, or other subjects”
TAK – mamy możliwości poszerzenia UML’a o własne stereotypy, profile etc. w tym również definiowanie nowych typów aktorów (tak jak w każdym wzorcu projektowym – podstawowe pryncypia: Open/Closed Principle)
W moim skromny zdaniu – Czas to Aktor co potwierdzają liczne projekty z jego udziałem oraz implementacja w postaci EJB timers, CronTab etc.
————————————–
Odnośnie wywodu to miałbym kilka uwag:
————————————–
– „Nawet notka z opisem jest lepsza niż używanie aktora do prezentowania czasu na diagramach UML”
Notka nie jest elementem namierzanym pod względem asocjacji, a w EA mamy przecież widok Hierarchy, który pod względem powiązań pokazuje nam zależności między pojedynczym klasyfikatorem a jego otoczeniem. Osobiście uważam, ze czas (kiedy) powinienem być podawany nie na nazwie UC a na nazwie asocjacji między UC a aktorem Czas, ponieważ:
– mamy tylko jednego aktora/rolę o nazwie Time. A aktor reprezentuje rolę, upewnienia a czas nie ma podziału i ziarnistości uprawnień.
– jeden aktor z którego wyszukujemy wszystkie funkcjonalności, związane z czasem. Problemy na wczesnym etapie analizy typu: „Wieczorem”, „Pod koniec dnia”, „Po południu” są łatwiejsze do namierzenia.
– poprzez asocjacje między Time a UC w widoku Hierarchy odnajdujemy wszystkie funkcjonalności inicjalizowane w ramach czasu. Visual Paradigm, RAD, Embarcadero, Poseidon for UML, również maja podobne widoki.
– również na diagramie wymogów, wszystkie wymogi związane z czasem wiążemy poprzez zależność Realize tylko z jednym Aktorem i tutaj podobnie jak w poprzednim przypadku – widok Hierarchy i wszystko widzimy w jednym miejscu.
————————————–
Odnośnie diagramu:
————————————–
Jest niepoprawny. Wygląda na to, że wysyłamy sygnał o nazwie „Dzień wypłaty” a nie czekamy na jego odebranie. Zalecam spojrzeć tam gdzie mało osób zagląda:
Specyfikacja UML Infrastructure 2.4 BETA (aktualnie najnowsza), strona 241 i to co nas interesuje to AcceptEventAction.
„AcceptEventAction is an action that waits for the occurrence of an event meeting specified condition.”
Natomiast na diagramie został użyty – SendSignalAction z pakietu BasicActions. A przecież nie wysyłamy tylko odbieramy sygnał. Należy poprawić diagram zamieniając wysłanie sygnału na odebranie, czyli konkretnie – AcceptEventAction z notacją klepsydry – strona 242.
Aż dziw, że nikt nie namierzył tego…
Dziękuję za bardzo ciekawy wywód. Nie zgodzę się z UMLowo, że czas może być reprezentowany aktorem, gdyż:
Czas nie wchodzi w interakcję z systemem a jedynie wyznacza moment, w którym usługa musi zadziałać, lub w którym działa, lub do którego momentu w czasie musi skończyć działać.
Tu także się nie zgodzę. Otóż notka ma wskazać kiedy zachodzi interakcja pomiędzy przypadkiem użycia a aktorem. Innymi słowy notka uszczegóławia relację poprzez wskazanie konkretnego miejsce w czasie i nie pełni roli aktora ani go nie zastępuje.
I tu po raz kolejny się nie zgodzę z tak kategorycznym zdaniem, że diagram jest niepoprawny. Już wyjaśniam mój punkt widzenia. Na diagramie aktywności element fork join ma za zadanie zsynchronizować sygnał z aktywnością.
W specyfikacji UML (UML Superstructure Specification, v2.1.1, p. 285) czytamy :
„SendObjectAction is an action that transmits an object to the target object, where it may invoke behavior such as the firing of state machine transitions or the execution of an activity. The value of the object is available to the execution of invoked behaviors. The requestor continues execution immediately. Any reply message is ignored and is not transmitted to the requestor.”
W moim rozumieniu muszę wysłać sygnał „Dzień wypłaty” i muszę mieć obliczone kwoty wypłat by móc wykonać przelewy. Gdybyśmy zaprezentowany diagram rozbudowali i sygnał umieścili w torze z nazwą np.: „Dyrektor” wtedy jednoznacznie widać by było, że ten sygnał musi być wysłany a nie odebrany.
Na koniec pragnę zauważyć, że AcceptEventAction nie ma notacji klepsydry. Klepsydra odnosi się do accept time event action ( UML Superstructure Specification, v2.4 BETA str. 242).
i już naprawdę na koniec: Osobiście accept time event action używam tylko do jednoznacznie zdefiniowanych momentów w czasie np.: ostatni dzień miesiąca, 14 sierpnia itd. Byty nie umiejscowione jednoznacznie w czasie wolę modelować za pomocą accept event action.
To się chyba nie dogadamy, ale z przyjemnością wymienię się spostrzeżeniami i opinią 🙂
Generalnie idea czy czas to Aktor ciągnie się już od dawna. Dla przykładu artykuł od Anthony Crain’a z IBM’a, dokładnie na temat tego czy czas może być Aktorem:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jun02/DrUseCaseJun02.pdf
według personalnej oceny Craiga czas NIE jest aktorem, jednak jak dobrze podkreślił zależy to od kontekstu.
Postawmy więc przykład z którym miałem przyjemność zmierzyć się w praktyce:
Postawmy dla przykładu modelowanie systemu raportującego, coś na wzór BMC Patrol czy systemu akcyjnego (nie mylić z aukcyjnymi). Jeśli w modelowanym systemie 95% funkcjonalności opiera się o czas, automatycznie uruchamianych w różnych momentach czasu funkcjonalności, nie posiadających żadnych aktorów pośrednich. Rzędu kilkaset różnych komunikatów podczas pracy systemu, to reprezentowanie tego w postaci notatki – najbardziej nieformalnego zapisu jaki istnieje w UML’u byłoby dosyć bolesne, bo mielibyśmy masę nieformalnych notatek, a już nie wspominam o łatwości zarządzania tego.
Powstaje pytanie – Jak na diagramie UC miałbym reprezentować UC, który jest powiązany JEDYNIE z czasem, a nie uruchamia go żadna osoba ? Innymi słowy dana funkcjonalność nie ma żadnych aktorów pośrednich oraz jest uruchamiana automatycznie w danych momentach czasu lub okresach czasu. W takim przypadku, stosując podejście notatkowe mielibyśmy wiszący UC nie połączony z żadnym aktorem a jedynie z notatką -> to nie jest zgodne ze specyfikacją UML’a, każdy UC musi mieć aktora. Powstaje drugie pytanie -> jak w sytuacji powyżej na scenariuszach UC zapisać aktora ? Kto jest aktorem ? Notatka ? 🙂
Jeśli stosujemy podejście:
„Czas nie wchodzi w interakcję z systemem a jedynie wyznacza moment, w którym usługa musi zadziałać, lub w którym działa, lub do którego momentu w czasie musi skończyć działać.”
to automatycznie na przypadku, który opisałem, w przypadku który posiada TYLKO JEDNEGO aktora, nie możemy wypełnić w pełni scenariusza a dokładnie pozycji Aktor oraz Trigger -> Ponieważ aktor to notatka. I tutaj w tej sytuacji, jak najbardziej specyficznej dla kontekstu aplikacji zdecydowanie widzę czas jako Aktor.
—————————-
Wracając do diagramu to jeśli miałaby być synchronizacja to ciężko jest ocenić poprawność. Zakładam, że powyżej diagramu w jego niewidocznej części jest wcześniej Fork. UML wymaga, że jeśli przeprowadzamy Join to musimy mieć również Fork. Jeśli wcześniej został użyty Fork (jestem przekonany, ze tak) to jak najbardziej diagram jest poprawny.
—————————-
Co do AcceptTimeEvent to jak najbardziej sam dokładnie tak samo wykorzystują popularną „klopsydrę” dla konkretnie zdefiniowanych, namierzanych punktów w czasie, typu „Sobota 22:00 – Full Backup”, czy „Każdego dnia tygodnia 24:00 – Incremental backup”.
Ja też cieszę się z możliwości wymiany poglądów.
Oczywiście wszystko zależy od kontekstu. Cieszę się, że i Craig uważa tak jak ja.
Niestety z opisu wynika, że przypadki użycia były źle zdefiniowane, ale mogę się mylić bo nie widziałem dokumentacji.
Co do diagramu to widzę, że zaczynamy mieć wspólne stanowisko
Aktor jest bytem więc nie jest „czasem”. Ot tyle 😉 … Pomijam, że zawsze chciałbym zobaczyć testy z udziałem tego „aktora” 😉