Często spo­ty­kam się w audy­to­wa­nych pro­jek­tach z poję­ciem ​„Czas jako aktor”. Wyjaśnijmy sobie kil­ka rze­czy, w tym to, że Czas nie jest akto­rem Systemu. Poniżej kil­ka wybra­nych pytań z dys­ku­sji na ten temat.

Dialog

Pytanie: Jak w takim razie w ogól­no­ści mode­lo­wać cyklicz­ność? Np. ​„pre­nu­me­ra­ta cza­so­pi­sma na okres 12 m‑cy”, ​„codzien­ne gene­ro­wa­nie rapor­tu”, ​„zbie­ra­nie wska­zań licz­ni­ka co N jed­no­stek czasu” ?

Jarek Żeliński: naj­pierw nale­ży zro­zu­mieć co się na praw­dę dzie­je i pamię­tać, że na Diagramach UC (przy­pad­ków uży­cia) nie mode­lu­je­my upły­wu cza­su a inte­rak­cje akto­rów z sys­te­mem. Prenumerata cza­so­pi­sma na 12 m‑cy to obiekt w sys­te­mie repre­zen­tu­ją­cy np. doku­ment zamó­wie­nia tej pre­nu­me­ra­ty (ma zapew­ne atry­but okres pre­nu­me­ra­ty). Codzienne gene­ro­wa­nie rapor­tu, pytam kto ini­cju­je ​„co rano” raport? Bo sam się nie robi, albo jest to aktor, czło­wiek robią­cy to ​„z palu­cha” albo wewnętrz­ny ser­wis (demon), któ­ry reagu­je na zda­rze­nia (sygnał cza­su, np. raz na dobę gene­ro­wa­ny przez dedy­ko­wa­ny do tego pod­sys­tem), taki ser­wis, gene­ro­wa­nie rapor­tu, to kla­sa mają­ca ope­ra­cję GenerujRaport. Jeżeli jed­nak obsłu­ga takich zda­rzeń ma miej­sce wewnątrz Systemu do dia­gram UC nie jest miej­scem na poka­zy­wa­nie tego (przy­po­mi­nam, że na mode­lu UC sys­tem to ​„czar­na skrzynka”).

Pytanie: Aktor ​„czas” pozwo­lił­by na doda­nie tego do mode­lu przy­pad­ków uży­cia, ale czy model przy­pad­ków uży­cia jest wła­ści­wym miej­scem ? Czy ​„lepiej” opi­sy­wać takie zacho­wa­nia w spe­cy­fi­ka­cji dodatkowej?

J.Ż.: Jeżeli pro­jek­tu­je­my bom­bę zega­ro­wą to jedy­nym akto­rem jest czło­wiek usta­wia­ją­cy (raz :))) moment wybu­chu, innych akto­rów ta bom­ba nie ma. Moduł zega­ra to wewnętrz­ny moduł bom­by zega­ro­wej. Przypadek uży­cia to: ​„Ustawienie momen­tu wybu­chu na okre­ślo­ny czas”. Mechanizm, któ­ry dopro­wa­dzi do wybu­chu to wewnętrz­na kon­struk­cja bom­by i zada­niem pro­jek­tan­ta jest opra­co­wa­nie jak to wyma­ga­nie zre­ali­zo­wać, a zada­niem pro­gra­mi­sty jest imple­men­ta­cja tego wyma­ga­nia (reali­za­cja to kawa­łek kodu, budzik z dru­ci­kiem, itp..). Kwestia imple­men­ta­cji ​„upły­wu cza­su” wynik­nie z tre­ści wyma­ga­nia, pamię­ta­my, że UC to wyma­ga­nia, usłu­gi sys­te­mu dla akto­ra i taki UC powi­nien się nazy­wać ​„usta­wie­nie godzi­ny wybu­chu” i już wia­do­mo o co cho­dzi – to tu jest miej­sce na taką informację.

Na zakończenie

Łamanie zasad UML nie jest dobrym pomy­słem. Od lat spraw­dza mi się porze­ka­dło, że ​„jeże­li cze­goś nie potra­fi­my nary­so­wać to zna­czy, że jesz­cze tego nie rozu­mie­my”. Maskowanie bra­ku wie­dzy o tym ​„jak” kolej­ny­mi nowy­mi sym­bo­la­mi to tyl­ko ​„sprze­da­wa­nie” pro­ble­mu dalej, bo jaki pro­blem pro­jek­to­wy roz­wią­zu­je stwo­rze­nie akto­ra Czas?. Analityk to ktoś, kto ana­li­zu­je by ​„zro­zu­mieć”… a nie zapi­su­je jak dyk­ta­fon sło­wa np. zamawiającego.

Co do ste­reo­ty­pów (ste­reo­typ ​„czas” dla akto­ra), nie słu­żą one do łama­nia zasad a do posze­rza­nia tak­so­no­mii pojęć UML i tu war­to np. dla akto­ra użyć np. «czło­wiek» czy «sys­tem» ale sko­ro aktor to z defi­ni­cji ​„coś mają­ce­go inte­rak­cję z Systemem” to czas nie speł­nia tej defi­ni­cji. Czyli nie moż­na w pro­fi­lu dodać akto­ro­wi zna­cze­nia ​„czas” bo poję­cie to nie mie­ści się w defi­ni­cji akto­ra (seman­ty­ka tego poję­cia nie może być łama­na przez profil).

Wiem, że są narzę­dzia, któ­re ​„suge­ru­ją” uży­cie ste­reo­ty­pu czas dla akto­ra ale z pyta­nia­mi ​„dla­cze­go” zapra­szam do ich dostaw­ców… a co mówi spe­cy­fi­ka­cja? [[UML Superstructure]] (OMG):

16.3.1 Actor (from UseCases) An actor spe­ci­fies a role play­ed by a user or any other sys­tem that inte­racts with the subject.

Semantics: Actors model enti­ties exter­nal to the sub­ject. When an exter­nal enti­ty inte­racts with the sub­ject, it plays the role of a spe­ci­fic actor.

Pojęcie Aktor odgry­wa rolę użyt­kow­ni­ka lub inne­go Systemu mają­ce­go inte­rak­cje z mode­lo­wa­nym Systemem. Pojęcie Aktor mode­lu­je byt zewnętrz­ny wobec mode­lo­wa­ne­go sys­te­mu. (przyp. J.Ż.)

Z per­spek­ty­wy imple­men­ta­cji mam akto­ra i dwie moż­li­we sytuacje:

1. gra­ficz­ny inter­fejs dla użyt­kow­ni­ka jakim jest człowiek
2. pro­gra­mo­wy (np. trans­mi­syj­ny) inter­fejs dla inne­go, zewnętrz­ne­go systemu.

Powyżej ilu­stra­cja z Wikipedii i kil­ka słów komentarza:

• Konsultant to kla­sycz­ny aktor (kon­kret­na rola, człowiek),
• Dział sprze­da­ży już nie koniecz­nie, nie wia­do­mo kto, wolał bym jed­nak np. sprze­daw­ca lub dyrek­tor sprzedaży,
• Systemy, nagry­war­ka czy kiosk mul­ti­me­dial­ny, to nic inne­go jak ​„jakiś zewnętrz­ny sys­tem”, imple­men­ta­cja inter­fej­su do nagry­war­ki niczym się nie róż­ni od inter­fej­su do Systemu rezer­wa­cji pokoi (pomi­jam to jakie kon­kret­ne pole­ce­nia są wysyłane) .
• Termin płat­no­ści to już zupeł­ne pogwał­ce­nie seman­ty­ki UML: jaką i jak reali­zo­wa­ną, inte­rak­cję ma Termin z Systemem?

Tak więc radzę ostroż­nie z Wikipedią (sta­je się nie­ste­ty zbio­rem pseu­do­wie­dzy). Wprowadzanie pojęć ukry­wa­ją­cych isto­tę rze­czy to moim zda­niem, ukry­wa­nie nie­wie­dzy na eta­pie ana­li­zy i pro­jek­to­wa­nia. To jed­na z przy­czyn złej jako­ści pro­ce­su two­rze­nia opro­gra­mo­wa­nia. Niezależnie od tego jak ład­nie umo­ty­wu­je­my ist­nie­nie akto­ra Czas, pro­gra­mi­sta i tak musi ten pro­blem roz­wią­zać i nie będzie to na pew­no inter­fejs ​„inte­rak­cji Systemu z Czasem”… A co z cza­sem? No cóż, albo czło­wiek kli­ka co godzi­nę w coś, albo wewnątrz sys­te­mu jest moduł, któ­ry gene­ru­je zda­rze­nie wywo­łu­ją­ce tę samą ope­ra­cję co kli­ka­ją­cy użyt­kow­nik… Moduł wewnętrz­ny sys­te­mu nie jest jego aktorem.

Jak w takim razie w ogól­no­ści mode­lo­wać cyklicz­ność? Np. ​„pre­nu­me­ra­ta cza­so­pi­sma na okres 12 m‑cy”, ​„codzien­ne gene­ro­wa­nie rapor­tu”, ​„zbie­ra­nie wska­zań licz­ni­ka co N jed­no­stek cza­su” ? Po pierw­sze usłu­ga sys­te­mu to odpo­wied­nio: zarzą­dza­nie pre­nu­me­ra­ta­mi, gene­ro­wa­nie rapor­tów, prze­twa­rza­nie pomia­rów. Prenumerata to zapis mówią­cy, że mam otrzy­mać np. każ­de wyda­nie jakie­goś perio­dy­ku w cią­gu dane­go roku. Generowanie rapor­tów to czyn­ność czło­wie­ka (raport na życze­nie) albo auto­ma­tu reagu­ją­ce­go na zda­rze­nie ​„kon­kret­ny czas”, zda­rze­nia takie gene­ru­je np. zegar sys­te­mo­wy. Zbieranie wska­zań licz­ni­ka to cyklicz­ne zda­rze­nie ini­cjo­wa­ne przez System. Implementacja tych wyma­gań to ele­ment pro­jek­to­wa­nia logi­ki biz­ne­so­wej i nie jest to już dia­gram przy­pad­ków uży­cia a model dzie­dzi­ny sys­te­mu bo to tu jest logi­ka biznesowa.

Ciąg dal­szy w arty­ku­le: Czas nie jest akto­rem dla Systemu c.d. czy­li projekt