7. Daži vārdi par uzdevumu TD diagrammām
Iepriekšējās nodaļās uzsvērām, ka modeļa uzdevumu aprakstam būtiskākās ir BP diagrammas.Tomēr, katram uzdevumam modeļa kokā ir piesaistīta arī TD diagramma, kurā ietverts uzdevuma saturīgs apraksts un citi uzdevuma raksturojumi. Sīkāk par TD diagrammām runāsim 16. nodaļā. Šeit aplūkosim vienīgi TD diagrammas iepriekšējās nodaļas modeļa primārajam uzdevumam un pirmā līmeņa trim apakšuzdevumiem (Zīm. 7.1 - Zīm. 7.4) un uz to pamata paskaidrosim vienu TD funkciju - uzdevumu interfeisu aprakstu. Ar uzdevumu interfeisu mēs saprotam precīzas norādes, jeb references uz kaimiņuzdevumiem.
No Zīm. 7.2 - Zīm. 7.4 redzam, ka references tiek attēlotas tieši tāpat, kā biznesa procesā, kurš veic dotā uzdevuma detalizāciju. Iepriekšējā nodaļā references uz kaimiņu uzdevumiem mēs skaidrojām tieši biznesa procesos, nerunājot par uzdevuma TD. Īstenībā rīks nodrošina sekojošu interfeisu informācijas pārneses ķēdīti.
Augšējā līmeņa uzdevumam, tāpat kā jebkuram citam, arī atbilst TD diagramma (Zīm. 7.1), tikai šī TD nekādus interfeisus nesatur (izņemot gadījumu, kas aprakstīts 8. nodaļā). Zīmējot biznesa procesu (BP diagrammu) augšējā līmeņa uzdevumam mēs iezīmējam attiecīgos apakšuzdevumus un notikumus, kas saista šos apakšuzdevumus. Tiklīdz kāds apakšuzdevums tiek iezīmēts BP diagrammā, rīks uzreiz šī uzdevuma TD aizmetni automātiski ieliek modeļa kokā. Tiklīdz mēs iezīmējam kādu notikumu, kas ieiet/iziet no dotā apakšuzdevuma, rīks uzreiz šo notikumu kopā ar referenci uz attiecīgo kaimiņuzdevumu automātiski iezīmē dotā uzdevuma TD diagrammā. Tādā veidā uzdevuma TD diagrammas interfeisa daļa aizpildās automātiski, izmantojot BP diagrammu.
Pieņemsim, ka mēs gribam apakšuzdevumu tālāk detalizēt, zīmējot tā biznesa procesu (BP diagrammu). Šajā gadījumā, izmantojot iepriekš radīto dotā apakšuzdevuma TD, rīks pasaka priekšā, kādam jābūt šī biznesa procesa interfeisam. Tādā veidā turpinot, mēs nonākam līdz elementāriem uzdevumiem, kuriem rīka uzzīmētā TD vairs tālāk netiek izmantota.
No izklāstītā redzam, ka vienkāršos gadījumos un ja diagrammas tiek veidotas no augšas uz leju, lietotājam nav vajadzības pētīt un pašam papildināt TD diagrammu saturu. Nākošajā, 8. nodaļā (vairāki primārie uzdevumi) aplūkots gadījums, kad lietotājam jāaizpilda pašam uzdevuma interfeiss. Vēlāk, 16. nodaļā, redzēsim, ka dažus uzdevuma raksturojumus var ierakstīt vienīgi TD diagrammā.
Tagad atgriežamies pie mūsu piemēra. Diagrammu dabiskais konstruēšanas ceļš ir sekojošs:
Protams, jebkurā brīdī ir iespējams pārkāpt šo dabisko diagrammu konstruēšanas secību, tādā gadījumā rīka palīdzība būs mazāka.
Zīm. 7.1. TD diagramma primāram uzdevumam Query_Processing
Zīm. 7.2. TD diagramma uzdevumam Register_and_Forward_Query
Zīm. 7.3. TD diagramma uzdevumam Prepare_Answer
Zīm. 7.4. TD diagramma uzdevumam Send_Answer
Parasti sistēmas biznesa modelis sastāv nevis no viena primārā uzdevuma, kā tas bija iepriekšējā piemērā, bet no vairākiem primārajiem uzdevumiem, kuriem katram par sevi ir saturīga jēga.
Vairumā gadījumu šie primārie uzdevumi ir neatkarīgi (vai arī atkarību parāda tikai kopīga Datu Noliktava). Tomēr ir gadījumi, kad starp šiem primāriem uzdevumiem notiek arī kāda neliela ziņojumu apmaiņa. Lai mēs varētu aprakstīt šo gadījumu, izmantojot vienīgi līdz šim aplūkotos līdzekļus, mums vajadzētu mākslīgi ieviest vienu "superprimāru" uzdevumu, kas sastāvētu no šiem īstajiem primārajiem uzdevumiem, un konstruēt šim "superprimārajam" uzdevumam BP diagrammu, kurā norādīt notikumu plūsmu starp īstajiem primārajiem uzdevumiem.
Lai izvairītos no šāda mākslīga "superprimāra" uzdevuma ieviešanas, ir paredzēta tieša ziņojumu apmaiņa starp primārajiem uzdevumiem.
Aplūkosim jau zināmo piemēru Office un uzskatīsim, ka tur minētie 3 apakšuzdevumi Register_and_Forward_Query, Prepare_Answer un Send_Answer ir primāri (skat. Zīm. 8.1 attēloto modeļa koku).
Taču mēs zinām, ka starp šiem primārajiem uzdevumiem notiek ziņojumu apmaiņa, proti, tāda, kāda tā ir parādīta Zīm. 6.4. Bet mūsu jaunajā modeļa kokā šī Zīm. 6.4 nav! Tādēļ šo uzdevumu TD diagrammās "ar roku" ir jāiezīmē paredzamās ziņojumu apmaiņas attiecīgo referenču formā, kā tas parādīts Zīm. 7.2 - Zīm. 7.4. Interfeisa daļai šajās "ar roku" radītajās TD diagrammās ir precīzi jāsakrīt ar tām, ko, automātiski nodrošināja rīks no Zīm. 6.4 attēlotās BP diagrammas.
Tālāk šo primāro uzdevumu detalizācija notiek tieši tāpat, kā tas aprakstīts iepriekšējā nodaļā.
Zīm. 8.1. Kantora modeļa variants ar trim primāriem uzdevumiem
Noslēgumā atzīmēsim, ka dotajā piemērā sadarbība starp primārajiem uzdevumiem ir samērā intensīva. Tāpēc šajā gadījumā pareizais risinājums būtu tāds, kāds tika minēts 6. nodaļā, kur mēs uzskatījām šos uzdevumus par apakšuzdevumiem kādā vēl lielākā primārā uzdevumā, kas saucās Query_Processing.
9. Uzdevumu daudzkārtēja izmantošana
Uzdevuma izvērsumā caur BP diagrammu piedalās - jeb ir sastopami,- citi, elementārāki uzdevumi. Katru šādu uzdevuma parādīšanās reizi BP diagrammā angliski sauc par occurrence. Latviski šī jēdziena apzīmēšanai lietosim jaunvārdu sastape.
Aprakstot reālas sistēmas ir iespējama situācija, ka viens un tas pats uzdevums tiek izmantots vairākos biznesa procesos (vai arī vienā un tajā pašā biznesa procesā viens un tas pats uzdevums sastopams vairākas reizes). Šāda situācija ir attēlota Zīm. 9.1 - Zīm. 9.4
Zīm. 9.1. Augšējā līmeņa BP
Zīm. 9.2. Task_A izvērsums
Zīm. 9.3. Task_B izvērsums
Zīm. 9.4. Koks modelim ar daudzkārt izmantojamu uzdevumu
Šeit gan uzdevuma Task_A detalizācijā, gan uzdevuma Task_B detalizācijā tiek izmantots viens un tas pats apakšuzdevums Task_D.
Rodas jautājums, kāda tagad būs uzdevuma Task_D specifikācija, t.i. TD diagramma, kā šajā diagrammā tiksaprakstīts Task_D interfeiss. Turklāt rodas problēma, kur šo uzdevumu Task_D novietot biznesa modeļa kokā.
Normālā gadījumā mēs zinām, ka uzdevumi Task_A1 un Task_A2 ir novietojami zem uzdevuma Task_A, un Task_B1 un Task_B2 zem uzdevuma Task_B. Uzdevums Task_D ir kopīgs abiem uzdevumiem Task_A un Task_B, tāpēc to vairs nevar novietot tikai zem viena no tiem. Nekas cits neatliek, kā modeļa kokā pacelt uzdevumu Task_D vienu līmeni augstāk - kopā ar Task_A un Task_B, kā tas parādīts zīm 9.4. Šādi to ir iespējams iekļaut gan Task_A, gan Task_B detalizācijā. Principā bija iespējams novietot uzdevumu Task_D vēl vienu līmeni augstāk, un uzskatīt to par primāru - arī tad to varētu lietot uzdevumu Task_A un Task_B detalizācijās. Tomēr, ievērojot metodiskus apsvērumus, bez vajadzības "mākslīgus" primāros uzdevumus nevajadzētu ieviest.
Zīm. 9.5. TD uzdevumam Task_D
Zīm. 9.6. BP uzdevumam Task_D
Izvirzās jautājums: kāds tagad būs uzdevuma Task_D interfeiss (TD diagramma). Šajā gadījumā tiek izmantots princips: ja uzdevums ieiet vairākās BP diagrammās, tad būvējot tā interfeisu TD diagrammā visas references no dažādām BP diagrammām tiek summētas, kā tas tiek parādīts Zīm. 9.5. Savukārt Zīm. 9.6 ir parādīts viens iespējamais šāda kopēja uzdevuma Task_D BP diagrammas variants.
Tagad aplūkosim sarežģītāku gadījumu (Zīm. 9.7 un 9.8). Šo gadījumu raksturo tas, ka kopējam uzdevumam Task_D dažādās tā sastapēs (skat. Zīm. 9.7 un 9.8) tiek izmantotas dažādas ieejas un izejas notikumu kopas.
Izvirzās jautājums: kāds šajā gadījumā būs uzdevuma Task_D interfeiss. Mēs redzam, ka vienā uzdevuma Task_D sastapē (Zīm. 9.7) ienāk notikumi e un f un iziet notikums g, otrajā (Zīm. 9.8.) ienāk notikums e, bet iziet g un h. Šāda situācija ir pilnīgi likumīga. Uzdevuma Task_D TD diagrammā visas šīs references tiek summētas, kā tas parādīts Zīm. 9.9. Imitācijas gadījumā gan tiks izdots brīdinājums pie dotā uzdevuma konkrētās sastapes, jo daži notikumi paliks "gaisā pakārti". Nekas slikts gan tāpēc nenotiks, taču šādu situāciju uzskatīsim par sliktu projektēšanas stilu.
Ja mēs paskatāmies, kāds savukārt izskatās uzdevumam Task_D atbilstošais biznesa process (skat. Zīm. 9.10), tad redzam, ka šajā biznesa procesā viss pilnais interfeiss parādās tieši tādā pašā izskatā, kāds tas ir uzdevuma Task_D specifikācijā (tas ir pamatprincips, ka visas references no uzdevuma TD diagrammas tiek automātiski pārnestas uz šī uzdevuma BP diagrammu, to jau nodrošina pats rīks).
Zīm. 9.7 Izvērsums uzdevumam Task_A |
Zīm. 9.8 Izvērsums uzdevumam Task_B |
Zīm. 9.9 TD uzdevumam Task_D |
Zīm. 9.10 BP uzdevumam Task_D |
Mēs iepriekš teicām, ka nekas slikts nenotiks, ja vienā uzdevuma Task_D sastapē tas izmantos vienus ieejas notikumus, citā - citus. Tas, ka OR gadījumā nekas slikts nenotiks, ir acīmredzami. Problēmas varētu rasties, ja trigerēšanas nosacījumā tiek izmantota saite AND un uzdevuma sastapē dotajā BP ne visi AND-otie ieejas notikumi parādās. Lai dabīgā veidā tiktu galā ar šo gadījumu, tiek izmantota sekojoša noruna: AND-oti tiek tikai tie notikumi (ieskaitot arī vadības plūsmas notikumus), kuri parādās konkretajā uzdevuma sastapē dotajā BP.
Sevišķi būtiska šī noruna ir vadības plūsmas notikumu gadījumā. Var būt situācija, kas attēlota Zīm. 9.11, kad dažādās uzdevuma U sastapēs BP diagrammā, šim uzdevumam atbilst dažāds ieejošo vadības plūsmas notikumu skaits.
Zīm. 9.11 Piemērs norunai par vadības
plūsmām
Noslēgumā vēl uzsvērsim, ka uzdevums no sastapju viedokļa ir jāsaprot kā makrodefinīcija - pārejot uz plakanu modeli katra sastape tiek aizstāta ar savu uzdevuma kopiju, pie tam references uz kaimiņuzdevumiem tiek izmantotas, lai veiktu pareizu ievietošanu.
10. Biznesa procesa precīza izpratne, transakcijas jēdziens
Transakcija ir viens no biznesa modelēšanas pamatjēdzieniem. Ar transakciju saturīgi saprot darbību virkni, kas jāveic, lai vienu sistēmā no ārpasaules ienākušu notikumu (vai notikumu kopu) līdz galam apstrādātu.
Ja aplūkojam Piemēru 3.1 un viņam atbilstošo Zīm. 3.2, tad vienas vēstules ienākšanu līdz tās galīgai apstrādei būtu dabiski uzskatīt par vienu transakciju.
Biznesa procesa semantikas precīza izpratne lielā mērā ir saistīta ar transakcijas jēdziena izpratni.
Transakcijas jēdziens būs svarīgs arī vēlāk, vācot imitācijas statistiku, jo parasti mūs interesēs, cik ilgi vidēji notiek vienas transakcijas apstrāde u tml. jautājumi.
Jebkurā gadījumā transakcija ir pieskaitāma fundamentāliem biznesa modelēšanas jēdzieniem.
Transakcijas precīza definīcija ir samērā sarežģīta, taču vienkāršākos gadījumos, kas sastāda vairākumu, transakcijas jēdziens ir pietiekoši vienkāršs un dabisks.
Šajā nodaļā mēs transakciju skaidrosim tikai plakanā biznesa procesa ietvaros, proti, biznesa procesa, kas uzreiz tiek sadalīts elementāros uzdevumos, kuri tālāk vairs netiek detalizēti.
Aplūkosim Zīm. 10.1 attēloto piemēru.
Zīm. 10.1. Vienas vēstules apstrāde - transakcijas piemērs
Šajā piemērā klients nosūta vēstuli, sekretāre to saņem un iereģistrē, pēc tam tiek sagatavota atbilde un nosūtīta klientam. Kā jau tas iepriekš bija minēts, šādu vienas vēstules apstrādi ir dabiski uzskatīt par vienu transakciju.
Tagad aplūkosim nedaudz sarežģītāku Zīm. 10.2 attēlotu piemēru. Šajā piemērā klients atkal nosūta vēstuli, sekretāre to saņem un iereģistrē, bet tagad sekretāre kopā ar priekšnieku nevis uzreiz gatavo atbildi, bet vispirms nosūta vēstules kopiju recenzentam uz atsauksmi.
Zīm. 10.2. Vēstuļu apstrādes transakcija ar recenziju
Arī šajā gadījumā mēs vienas vēstules apstrādi gribētu uztvert kā vienu transakciju. Taču šeit ir jautājums, kā formāli atšķirt "īsto" transakcijas sākumu (resp., vēstules ienākšanu no ārējā klienta) no recenzijas, kas tiek saņemta vēstules apstrādes vidū, un kas arī ienāk no ārējā izpildītāja (recenzenta). Pēdējo mēs intuitīvi negribētu uzskatīt par transakcijas sākumu.
Acīmredzot, mēs negrēkosim pret mūsu intuīciju, ja vienosimies par šādu transakcijas sākuma pazīmi: uzskatīsim, ka transakciju vienmēr sāk notikumi, kuri ienāk no ārpasaules avotiem, kur šie ārpasaules avoti (uzdevumi), savukārt, ir neatkarīgi, t.i. neizmanto nekādus notikumus, kas nāk no apskatāmā biznesa procesa iekšienes.
No šī viedokļa ziņojuma Query (Vēstule) avots principiāli atšķiras no cita ārēja avota - ziņojuma Review (Recenzija) avota. Pirmo no šiem avotiem - uzdevumu Send_Query (Nosūta) neietekmē nekas no aplūkojamā procesa iekšienes, bet otro ārējo avotu - uzdevumu Review (Recenzē) ietekmē ziņojums Copy_of_Query (Vēstules_Kopija), kas nāk no transakcijas iekšienes.
Runājot par laika notikumiem, tie vienmēr būs īsti ārējie notikumi, kurus nekas neietekmē no iekšienes.
Vadoties pēc minētā kritērija, ir redzams, ka Vēstule, kas ienāk no uzdevuma Nosūta ir transakcijas sākums, kamēr Recenzija, kas ienāk no ārējā uzdevuma Recenzē, vairs nav transakcijas sākums.
Tagad šo pašu biznesa procesu vēl mazliet sarežģīsim un aplūkosim Zīm. 10.3 attēloto piemēru
Zīm. 10.3. Transakcija, kuru iesāk taimeris
Paskatīsimies, vai šeit mēs pēc iepriekšējā kritērija varēsim atšķirt šķietamo transakcijas sākumu no īstā. Acīmredzot, ka varēsim, jo arī šeit ir iekšējais notikums, kuru saņem eksternālais uzdevums Recenzē, proti, Vēstules_kopija, un līdz ar to tas nevar kalpot par transakcijas sākumu. Īstais transakcijas sākums šajā gadījumā būs laika notikums Daily (Ikdienas), kurš trigerē uzdevumu Send_Query (Nosūta).
Uzreiz atzīmēsim, ka lai biznesa procesu varētu imitēt (t.i. izpildīt), laika notikumiem ir jābūt līdz galam definētiem Notikumu Tabulā.
Ja transakcijas sākums ir vienkārši eksternāls uzdevums, kā pirmajos divos tikko aplūkotajos gadījumos, tad biznesa procesu imitēt nevar, jo mēs, piemēram, nezinām, cik bieži klients vēstules nosūta.
Aplūkojam nākamo piemēru, kas attēlots Zīm. 10.4.
Zīm. 10.4 Nevēlamas transakcijas apturēšana ar NOSTART
Šajā gadījumā klients sūta vēstules, bet, pilnīgi neatkarīgi, arī recenzents sūta recenzijas. Tātad, šajā situācijā ārpus mūsu aplūkotā modeļa klients kaut kādā veidā nogādā vēstules recenzentam. Taču pie atbildes sagatavošanas, abiem šiem ziņojumiem būtu jāsanāk kopā.
Rodas neskaidrība. No mūsu formālā kritērija viedokļa gan vēstules saņemšana, gan recenzijas saņemšana var būt transakcijas sākumi, jo tie abi nāk no ārējiem avotiem. Kurš transakcijas sākums ir "īstāks", tas formāli nav saprotams. Tajā pat laikā, cilvēkam parasti ir skaidrs, ko uzskatīt par "īsto" transakcijas sākumu - šeit, dabiski, par tādu būtu jāuzskata vēstules saņemšana, kamēr recenzijas saņemšanu nebūtu jāuzskata par transakcijas sākumu.
Šādiem gadījumiem ir paredzēta iespēja "maldinošos" transakcijas sākumus izslēgt, pierakstot pie attiecīgā uzdevuma NOSTART - tas nozīmēs, ka šis uzdevums nerada jaunu transakciju. Tomēr rodas vēl cita problēma - kā pie atbildes sagatavošanas mēs varam saprast, kura no iesūtītajām recenzijām attiecas uz doto vēstuli. Šim nolūkam trigerēšanas nosacījumā ir paredzēts WHERE nosacījums (sīkāk par to skat. 19. nodaļā). Lai WHERE nosacījumu varētu korekti uzrakstīt, mums vēstulei un recenzijai ir jāpiekārto datu tips, kas satur lauku, kurš identificē vēstulei atbilstošo recenziju. Datu tipu piekārtošanu notikumiem, kā tas jau iepriekš minēts, veic ar Notikumu Tabulas (skat. 16. nodaļu) palīdzību.
Šajā gadījumā ziņojumam Query varētu piekārtot rakstu ar lauku No un tāda paša tipa rakstu piekārtot arī ziņojumam Review. Tādā gadījumā nepieciešamais trigerēšanas nosacījums varētu būt:
Query & Review WHERE Query.No = Review.No.
Tagad atgriezīsimies pie Zīm. 10.2 un 10.3.
Mēs redzam, ka arī šeit uzdevums Prepare_Answer saņem gan Query, gan Review, taču ?eit WHERE nosacījums intuitīvi šķiet nevajadzīgs. Jautājums - kāpēc?
Te arī atklājas transakcijas galvenā jēga. Tiek uzskatīts, ka trigerēšanas nosacījumos, ja tas nav speciāli atrunāts, drīkst piedalīties notikumi tikai no vienas un tās pašas transakcijas. Tas nozīmē, ka Zīm. 10.2 un 10.3 patiesībā tiek izmantots noklusētais WHERE nosacījums, kuru mēs nerakstām, proti, ka gan Query, gan Review ir jābūt no tās pašas transakcijas.
Precīza transakcijas definīcija ir saistīta ar transakcijas identifikatora (TID) jēdzienu. Mēs šeit īsumā paskaidrosim TID ideju.
Sākoties transakcijai, notikumam, kurš rada šo transakciju, tiek piekārtots t.s. transakcijas identifikators (TID). Diagrammās šis TID tiešā veidā neparādās, arī modelētājam tas nav jāraksta, tikai jāiedomājas, ka tāds ir. Katrai transakcijai šis TID ir unikāls (resp., dažādām transakcijām šie TID atšķiras). Tālāk tiek pieņemts, ka visiem notikumiem, kuri iziet no kāda uzdevuma, ir tāds pats TID kā notikumiem, kas šo uzdevumu ir trigerējuši. AND tipa trigerēšanas nosacījums ir patiess tikai tad, kad visi tajā ieejošie notikumi ir ar vienu un to pašu TID. Citiem vārdiem sakot, trigerēšanas nosacījums e & f ņem no ziņojumu rindas tikai tos e un f pārus, kuriem ir vienādi TID.
Gadījumā, ja trigerēšanas nosacījums satur ALL opciju: e AND ALL f, pastāv īpaša noruna: tiek paņemti visi notikumi ar vārdu f, neskatoties uz to TID_iem.
Ņemot vērā iepriekš teikto, Zīm. 10.4 uzdevumu Prepare_Answer varētu modificēt vienā no sekojošiem veidiem, pie tam nerakstot NOSTART pie uzdevuma Review, t.i. atļaujot uzdevumam Review arī radīt savu transakciju:
Pirmajā gadījumā uzdevums Prepare_Answer savāc visas recenzijas, kas uz doto brīdi ir pienākušas, neskatoties, vai tās atbilst dotajai vēstulei, vai nē. Otrajā gadījumā uzdevums savāc tikai tās recenzijas, kas attiecas uz doto vēstuli. Abos gadījumos izejas notikumam Draft_Answer ir tāds pats TIDs, kā ieejas notikumam Query. Taču, ja uzdevuma izejā parādās notikums ar to pašu vārdu, kas aiz ALL:
tad šis notikums aiziet tālāk ar savu oriģinālo TIDu (nevis ar to TIDu, kas ir Query, un līdz ar to Draft_Answer).
Ir paredzēta vēl viena iespēja - pierakstīt NOTID pie izejas notikuma:
Ar to tiek nodzēsts attiecīgā notikuma TIDs.
Līdz ar to šis notikums var brīvi ANDoties ar notikumiem, kuriem ir patvaļīgi TIDi. Šī iespēja ir jāizmanto gadījumos, kad mēs gribam modelēt sadarbību starp dažādām transakcijām.
Tagad par transakcijas beigām. Tātad, normālā gadījumā transakcija beidzas, kad visi tās izraisītie notikumi ir izlietoti.
Mūsu pirmajā piemērā, kas attēlots Zīm. 10.1, ir pilnīgi skaidrs, kad transakcija beidzas, proti tad, kad vairs biznesa procesa iekšienē nepaliek neviens notikums, ko ir radījusi ienākusī vēstule,- tie vai nu visi ir izlietoti, vai izsūtīti uz ārpasauli. Resp., transakcija beidzas, kad nav vairs notikumu ar ienākušajai vēstulei atbilstošo TID.
Līdz ar to normālos gadījumos transakcijas beigas ir ļoti skaidras, - tās ir tad, kad biznesa procesa iekšienē nav palicis neviens notikums ar transakcijai atbilstošo TID.
Taču ir sastopami gadījumi, kur transakcijas beigas nav tik skaidri nosakāmas. Aplūkosim Zīm. 10.5 attēloto piemēru.
Zīm. 10.5. Nenoteiktas transakcija beigas
Šis ir pietiekoši tipisks piemērs - ir attēlots gadījums, kad klients nosūta vēstuli, sekretāre to iereģistrē, nosūta recenzentam uz atsauksmi, bet papildus uzliek vēl taimeru, t.i. inicializē "tehnisku" uzdevumu Timer1, kurš neko citu nedara (arī izpildītāja viņam nav), kā tikai pēc 25 dienām izdod ziņojumu Timeout. Šādi "tehniski", jeb "palīguzdevumi" dažreiz ir jāizmanto, lai adekvāti aprakstītu modelējamo situāciju.
Ja ir pagājušas 25 dienas, t.i. ir pienācis ziņojums Timeout, tad, neatkarīgi no tā, vai recenzija ir saņemta, sekretāre kopā ar priekšnieku gatavo atbildi. Šis fakts tiek pierakstīts ar atbilstošo trigerēšanas nosacījumu uzdevumā Prepare_Answer:
Query & Timeout | Query & Review
Pieņemsim, ka 25 dienas ir pagājušas, Timeout ziņojums ir saņemts, un sekretāre ir nosūtījusi atbildi. Tas nozīmē, ka šī transakcija saturīgi ir beigusies, jo dotā vēstule ir apstrādāta.
Tagad pieņemsim, ka pēc kaut kāda laika no recenzenta tomēr pienāk Review. Uzdevums Prepare_Answer tomēr nekad netrigerēsies ar šo Review, jo tai būs apstrādātās vēstules TID, bet cita vēstule ar šādu TID nekad neparādīsies. Līdz ar to šī Review ar savu TID paliks pie uzdevuma Prepare_Answer rindā uz mūžīgiem laikiem. Šī iemesla dēļ dotajā gadījumā nedarbojas iepriekš minētais noklusētais transakcijas beigu kritērijs.
Lai izvairītos no šādu bezgalīgu rindu veidošanās, ir paredzēta iespēja pierakstīt atsevišķam uzdevumam atslēgas vārdu END. Tad līdz ar dotā uzdevuma izpildi transakcija beidzas, un visi notikumi, kas vēl pastāv ar šīs transakcijas TID, tiek izmesti no rindām. Tas nozīmē, ka iepriekšējā piemērā būtu bijis pareizāk, ja pie uzdevuma Send_Answer mēs būtu pierakstījuši atslēgas vārdu END:
Vispārīgā gadījumā END var pierakstīt ne tikai pie paša uzdevuma, bet arī pie uzdevuma konkrēta zara:
Iespējama arī cita situācija: sekretāre var gatavot Draft_Answer tikai uz recenzijas Review pamata neizmantojot oriģinālo pieprasījumu Query. Tas nozīmē, ka uzdevumam Prepare_Answer nav nepieciešams ieejas notikums Query. Taču ja mēs Zīm. 10.5 uzdevumam Prepare_Answer vienkārši nodzēsīsim ieejas notikumu Query un līdz ar to iegūsim trigerēšanas nosacījumu: Timeout|Review, tad mēs panāksim nevēlamu situāciju: uzdevums Prepare_Answer trigerēsies divas reizes - vienreiz ar Timeout, otrreiz ar Review.
Zīm. 10.6 Liekas Prepare_Answer izpildes novēršana ar vadības plūsmas notikumu
Lai izvairītos no šīs situācijas, ir jāzīmē vadības plūsmas notikums no Ask_Review uz Prepare_Answer kā tas parādīts Zīm. 10.6.
Pēc noklusēšanas vadības plūsmas notikumi vienmēr pieANDojas pie esošā trigerēšanas nosacījuma (dotajā gadījumā Timeout|Review). Vienīgais gadījums, kad vadības plūsmas notikumi neANDojas, ir tīrais trigerēšanas nosacījums OR.
Nodaļas noslēgumā nedaudz pakavēsimies pie cita jautājuma, un proti, īsumā aprakstīsim "biznesa mašīnu", kura izpilda biznesa procesus.
Šādu biznesa mašīnu var iedomāties sekojoši. Katram uzdevumam no modelējamā biznesa procesa tiek veidots savs "darbagalds". Zīm. 10.5 attēlotajam biznesa procesam parādīsies 6 darbagaldi. Pie katra darbagalda notikumi stājas rindā.
Tātad, ja vēstules nāk bieži, tad pie darbagalda Register_Query tās var sastāties garā rindā.
Ja izpildītājs apkalpo daudzus darbagaldus (šajā gadījumā tā ir sekretāre), tad mēs varam iedomāties, ka izpildītājs "skraida" no viena darbagalda pie otra, lai veiktu viņam paredzētos uzdevumus (skat. Zīm. 10.7). Tas nozīmē, ka reālas izpildes gadījumā transakcijas var būt stipri "sajauktas", resp., viens no darbagaldiem var jau izpildīt kādu simto transakciju, kamēr kāds cits varbūt nav vēl ticis galā ar pirmo.
Zīm. 10.7. Biznesa mašīna
