przypadek użycia aktor czas

Czas nie jest aktorem Systemu

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” ?

przypadek użycia aktor czas

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

Inne artykuły na podobny temat

Komentarze

  1. Jacek Rybicki 28 listopada 2011 at 11:45

    To co zosta­ło zamo­de­lo­wa­ne w UC jest testo­wa­ne przez klien­ta w ramach testów akcep­ta­cyj­nych. Jeżeli mój klient prze­pro­wa­dza testy dzia­łań ini­cjo­wa­nych osią­gnię­ciem okre­ślo­ne­go punk­tu w cza­sie, to nie widzę powo­du, żeby aku­rat ten aspekt sys­te­mu mode­lo­wać ina­czej niż za pomo­cą UC.

    To, jak nazwie­my akto­ra, to inna spra­wa. Zgadzam się, że trze­ba się­gać do przy­czyn, naj­głę­biej jak się da.
    Ale tutaj też widzę pew­ną nie­kon­se­kwen­cję w się­ga­niu w histo­rię. Działania akto­rów mogą być spo­wo­do­wa­ne wcze­śniej­szy­mi dzia­ła­nia­mi innych ludzi, może rów­nież akto­rów w sys­te­mie. Wtedy pyta­nie akto­ra dla­cze­go wyko­nu­je akcję też zosta­nie prze­kie­ro­wa­ne do oso­by rze­czy­wi­ście ini­cju­ją­cej pro­ces. Czy w takim razie wska­zy­wać tę oso­bę jako akto­ra dla dane­go UC? Jak dla mnie, war­to wymie­nić te dzia­ła­nia w przy­czy­nach wyko­na­nia UC, warun­kach początkowych.

    • Jarek Żeliński 28 listopada 2011 at 11:56

      Na czym pole­ga testo­wa­nie popraw­no­ści nasta­wy bom­by zega­ro­wej? Na nasta­wie­niu jej i obser­wa­cji wybu­chu i momen­tu jego zaist­nie­nia. Wybuch ma nastą­pić o okre­ślo­nej godzi­nie. Testy akcep­ta­cyj­ne: aktor wpro­wa­dza dane do ini­cja­cji wybu­chu. Efekt dzia­ła­nia sys­te­mu: wybuch o nasta­wia­nej godzi­nie. Czym się róż­ni UC Raport na naci­śnię­cie kla­wi­sza” od Raport z opóź­nie­niem o godzi­nie XX:XX”. Niczym. To jeden i ten sam UC Raport” (usłu­ga sys­te­mu) mają­cy moż­li­wość wpro­wa­dze­nia para­me­tru (dane) o ewen­tu­al­nym opóź­nie­niu wykonania. 

      Wyobraźmy sobie dia­gram UC dla elek­tro­nicz­ne­go budzi­ka (albo jego wer­sji kom­pu­te­ro­wej wyświe­tla­nej na pul­pi­cie windows) …

  2. Jacek Rybicki 28 listopada 2011 at 12:24

    UC uwzględ­nia­ją­cy prze­rwę w wyko­ny­wa­niu dzia­łań jest bar­dziej skom­pli­ko­wa­ny. Trzeba wyko­rzy­stać jakieś medium zacho­wy­wa­nia sta­nu po zakoń­cze­niu pierw­szej inte­rak­cji. Sam powrót do zamro­żo­nej inte­rak­cji może wyma­gać pod­ję­cia dodat­ko­wych akcji przez aktora.

    Rozumiem zamo­de­lo­wa­nie całe­go pro­ce­su usta­wia­nia budzi­ka, od począt­ku do koń­ca, z uwzględ­nie­niem wszyst­kich akcji i atrak­cji. Jednak UC pozio­mu użyt­kow­ni­ka zamo­de­lo­wał­bym osob­no, gdyż w UC tego pozio­mu mode­lu­ję poje­dyn­czą inte­rak­cję z systemem.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.