23. Zarošanās nosacījumi

Kā jau tas vairākkārt atzīmēts, var būt parastie uzdevumi (transformation tasks) un zarotie uzdevumi (decision tasks). Zīm. 17.1 un 17.2 ir attēlots zarotais uzdevums. Ar zarotiem uzdevumiem ir saistīti zarošanās nosacījumi, kuri tiek attēloti zarošanās (decision) simbolā:

 

Decision name ir obligāta, Decision expression ir neobligāta.

Decision expression var būt viena no diviem:

Varbūtība tiek uzdota izskatā

skaitlis %

un nozīmē dotā zara varbūtību (tā tiek ņemta vērā pie biznesa procesa imitācijas).

Vispārīgā gadījumā vairāki zarošanās nosacījumi var izpildīties arī vienlaicīgi, tas nav aizliegts. Ja zarošanās nosacījumi tiek uzdoti ar formulu, tad to savstarpējo izpildi nosaka pašas formulas. Taču gadījumā, kad zarošanās nosacījumi tiek uzdoti ar varbūtību, pastāv divas iespējas, kā to saprast:

1. varbūtība norāda dotā zara ekskluzīvo izvēli,

2. varbūtība norāda dotā zara izvēli neatkarīgi no pārējo zaru izvēles.

Pirmajā gadījumā ir jālieto atslēgas vārds EXCLUSIVE (un EXCLUSIVE varbūtību kopsumma nedrīkst būt lielāka par 100%):

 

 

Otrajā gadījumā ir jāraksta bez atslēgas vārda EXCLUSIVE:

 

 

Formula, ar kuru uzdod zarošanās nosacījumu, ir izskatā

loģiska izteiksme | ELSE |ALWAYS,

kur loģiskā izteiksme var saturēt uzdevuma atribūtus, ieejas notikumu laukus un, gadījumā ja trigerēšanas nosacījums ir OR tipa, arī speciālu Bula tipa iebūvētu funkciju

IS_TRIGGERED_BY (event_name)

Šīs funkcijas vērtība ir true, ja notikums ar doto event_name ir starp tiem notikumiem, kas dotajā gadījumā patiešām ir trigerējuši doto uzdevumu Piemēram, ja aplūkojam uzdevumu:

 

 

 

 

 

tad E_case izpildīsies gadījumā, kad doto uzdevumu būs trigerējis notikums e, kuram lauka X vērtība ir 0, bet F_case - kad doto uzdevumu būs trigerējis notikums f, kuram lauka Y vērtība ir 0.

Vēl par ELSE un ALWAYS. ALWAYS ir semantiski ekvivalents vienmēr patiesai formulai, ELSE nozīmē “parējos gadījumos”.

 

24. Izejas notikumu vērtības

Rakstot precīzāku specifikāciju, var rasties nepieciešamība uzdevuma izejas notikumu laukiem piešķirt noteiktas vērtības. Tāda iespēja ir paredzēta valodā GRAPES-BM. Šim nolūkam kalpo operātors SET:

SET field1=expr1; field2=expr2; ...

kuru var pierakstīt pie izejas notikuma - tūlīt aiz notikuma vārda (skat. Zīm. 17.1 un Zīm. 17.2). Protams, to var darīt tikai tajā gadījumā, kad notikumam ir piekārtots noteikts datu tips.

Lai būtu skaidrāks, aplūkosim vēl vienu piemēru. Pieņemsim, ka notikumiem e un f ir pierakstīti record datu tipi ar laukiem x un y. Tad var rakstīt:

 

 

 

 

Rezultātā izejas notikuma f laukiem x un y tiek piešķirtas attiecīgi vērtības e.x un e.x*e.y, bet izejas notikumam e, kura vārds sakrīt ar attiecīgo ieejas notikumu, mainīts tiks tikai lauks x, piešķirot tam vērtību e.x+1, bet lauks y paliks tāds pats, kāds tas nāk no ieejas.

Ja, piemēram, notikumam e piekārtots iekļauts record tips, kur lauks x ir savukārt record ar laukiem a un b, tad lauka vārds x ir jālieto kā kvalifikātors:

SET x.a = e.x.a +1

“Piešķiršana” ar operātoru SET ir atļauta tikai elementāro lauku līmenī.

Var arī būt situācija, kad, piemēram, notikumam m ir piekārtots elementārs datu tips, kuram nav lauku. Tādā gadījumā tiek lietots atslēgas vārds VALUE:

SET VALUE = m +1

Noslēgumā vēl par to, ko var saturēt izteiksme, kuras vērtību piešķir izejas notikuma laukam. Kā redzams no iepriekšējiem piemēriem, tā var saturēt ieejas notikumu laukus (OR tipa trigerēšanas nosacījuma gadījumā pašam lietotājam ar zarošanās nosacījumu un IS_TRIGGERED_BY palīdzību ir jārūpējas, lai attiecīgais ieejas notikums būtu nolasīts). Bez ieejas notikumu laukiem izteiksme var saturēt arī uzdevuma atribūtus.

Vēl jebkuram izejas notikumam var pierakstīt

REPEAT integer_expression.

Piemēram:

 

 

 

 

Rezultātā attiecīgais izejas notikums (pēc SET izpildīšanas, ja SET ir paredzēts) ar vienu un to pašu lauku saturu tiks atkārtoti nosūtīts norādīto skaitu reižu.

Noslēgumā atgādināsim, ka, ja kāds ieejas notikums, piemēram f, trigerēšanas nosacījumā parādās “grupā”:

 

 

 

 

un šis pats f parādās arī kā izejas notikums, tad visi nolasītie f eksemplāri bez izmaiņām (ja nav SET opcijas) tiek nodoti tālāk.

Grupveida trigerēšanas gadījumā ir paredzēta vēl viena līdz šim nepieminēta iespēja, un proti, vertikālas operācijas SUM, MAX, MIN, AVG pār grupveidā trigerētā notikuma laukiem. Tās var lietot izejas notikumu SET operatoros:

 

 

 

 

 

 

25. Vēl viens piemērs

Aplūkosim piemēru no ražošanas sfēras, un proti, vienu fragmentu no mikroshēmu ražotnes. Ienāk pasūtījums (Customer_Order) saražot tik un tik mikroshēmas (ziņojuma Customer_Order lauks No_of_Boards). Dispečers, saņēmis pasūtījumu, dod ziņojumu operātoram izgatavot attiecīgo skaitu shēmas. Operators katras shēmas eksemplāra izgatavošanai ņem no noliktavas Boards vienu plati, attiecīgi sagatavo to un nodod tālāk robotam. Robota uzdevums ir piemontēt 100 elementus A, kurus viņš pa vienam ņem no noliktavas Parts. Pēc tam samontētā shēma iet uz testēšanu, kuru veic testētājs. Ja atklājas defekts, shēma tiek labota. Vienkāršības labad pieņemsim, ka labošanu veic operators.

Aprakstītais mikroshēmu izgatavošanas cikls ir attēlots kā biznesa process Zīm. 25.5. Ievērosim, ka šeit parādās viens “tehnisks” uzdevums Vai_turpināt (Continue_Assembling), kuram nav izpildītāja. Šādi “tehniski” uzdevumi bieži ir nepieciešami, lai reālos uzdevumus (dotajā gadījumā attiecīgo ražošanas procesu) iekļautu valodas GRAPES-BM rāmjos. Zīm. 25.1 - 25.4 parādīts modeļa koks un nepieciešamās diagrammas.

Zīm. 25.1. Modeļa Simplified_Production diagrammu koks

Zīm. 25.2. ORG diagramma

Zīm. 25.3. Modeļa Simplified_Production ziņojumu datu tipi

Zīm. 25.4. Modeļa Simplified_Production notikumi

Zīm. 25.5. BP diagramma uzdevumam Simplified_Production

Tagad aplūkosim sarežģītāku situāciju. Pieņemsim, ka mums ir zināmas varbūtības, ar kādām var rasties defekti attiecīgajos ražošanas posmos. Proti, pieņemsim, ka jebkurš detaļas A eksemplārs var būt brāķis ar varbūtību 1%. Tālāk, pieņemsim, ka pašā montāžas procesā “laba” shēma var tikt sabojāta ar varbūtību 2%. Vēl pieņemsim, ka testējot sliktu shēmu tās defektivitāte tiek atklāta ar varbūtību 90%, bet defektivitāte tiek izlabota ar varbūtību 75%. Un pēdējais, pieņemsim, ka testējot labu shēmu, ar varbūtību 4% tiek kļūdaini atzīts, ka shēma ir slikta.

Tagad mūsu mērķis ir uzkonstruēt biznesa procesu, kurš adekvāti attēlo iepriekš aprakstīto situāciju. Lai to izdarītu, mums ir jāieved virkne “tehnisku” uzdevumu, kurus varētu saukt par kļūdu “demoniem” - viņi rada shēmu defektus (kļūdas) ar iepriekšminētajām varbūtībām. Tādā veidā mēs iegūstam Zīm. 25.7 attēloto biznesa procesu, kas adekvāti apraksta iepriekšminēto situāciju.

Imitējot šo biznesa procesu, mēs varam iegūt nepieciešamo statistiku par aplūkojamo ražošanas procesu.

Zīm. 25.6. Modeļa Production_with_defects notikumu datu tipi

Zīm. 25.7. BP diagramma uzdevumam Production_with defects

 

26. Dažas pamācības, kā “programmēt” valodā GRAPES-BM

26.1 Vispārīgas piezīmes

Valodu konstruktori vienmēr nokļūst dilemmas priekšā - vai valodu apaudzēt kā Ziemassvētku eglīti ar bezgala daudzām dāvanām cerībā, ka tādā veidā mēs pietiekoši adekvāti varēsim jebkuru gadījumu ar šo valodu aprakstīt, vai arī izvēlēties otru ceļu - valodu pārmērīgi nesarežģīt, bet toties mācīt, kā šo valodu izmantot dažādos sarežģītākos gadījumos, cerībā, ka pēc tam valodas lietotāji jau pratīs noprogrammēt to, kas viņiem vajadzīgs.

Valoda GRAPES-BM ir orientēta uz to, lai mēs pietiekoši adekvāti varētu aprakstīt reālas sistēmas - reālus ražošanas procesus, reālus kantorus, reālus datu apstrādes uzdevumus u.t.t. Taču, ja mēs gribam attiecīgo biznesa modeli padarīt pietiekoši precīzu - tik precīzu, lai to jau varētu imitēt (bet arī ne tikai šī iemesla dēļ), mums sarežģītākos gadījumos, diemžēl, nākas ieviest dažādus tehniskus uzdevumus, kuri “dabā” tiešā veidā nemaz nepastāv.

Lai to labāk paskaidrotu, atgriezīsimies pie tā paša piemēra, ar kuru mēs beidzām iepriekšējo nodaļu, proti, pie mikroshēmu plašu montāžas (skat. Zīm. 25.5 un 25.7).

Mēs šeit redzam, ka tad, kad mēs aprakstām tikai pašu ražošanas procesu (Zīm. 25.5), viss izskatās ļoti labi - katrs uzdevums šajā modelī atbilst noteiktam uzdevumam “dabā” (ar konkrētu izpildītāju). Tomēr jau šeit parādās pirmais tehniskais uzdevums (bez konkrētā izpildītāja), lai aprakstītu situāciju, vai turpināt shēmu ražošanu, vai nē. Ja mēs nolaižamies līdz precīzākam aprakstam un gribam attēlot arī kļūdas, kas var rasties ražošanas procesā, tad mums gribot vai negribot ir jāievieš vairāki tehniskie uzdevumi, un proti, kļūdu “dēmoni”, kas šīs kļūdas rada (Zīm. 25.7 uzdevumi Defective_Part_Added, Defect_During_Assembling).

Pirmā pamācība, kas no šejienes izriet, ir sekojoša: lai adekvāti aprakstītu (it sevišķi imitācijas vajadzībām) kādu sistēmu, nevajag baidīties ieviest tehniska rakstura palīguzdevumus, kuriem “dabā” tieša analoga nav.

Šīs nodaļas virsrakstā mēs lietojām vārdu “programmēt” (kaut arī pēdiņās). Ar to mēs gribam pasvītrot, ka arī biznesa modelēšanā, aprakstot sistēmas, patiesībā ir jāveic zināms programmēšanas darbs.

Tajā pašā laikā ir jāsaprot, ka biznesa modelēšanas valoda tomēr nav programmēšanas valoda, tās mērķis ir aprakstīt sistēmas specifikāciju tikai ar tādu precizitātes līmeni, lai tas būtu pietiekošs programmētājam, kurš doto sistēmu implementēs, reizē nezaudējot arī apraksta saprotamību menedžerim, kas doto sistēmu izmantos. Vienīgi biznesa modeļa imitācijas nepieciešamība mums bieži “uzspiež” nepieciešamību pēc modeļa lielākas precizitātes un detalizācijas.

26.2. Kā modelēt atmiņu

Valodā GRAPES-BM 4.0 imitācijas vajadzībām ir ieviesti kopīgie mainīgie (datu objektiem dotajā valodas versijā nav paredzētas nekādas formālas darbības). Mainīgos definē VT tabulā, norādot mainīgā vārdu un datu tipu. Tālāk tos var izmantot uzdevumu simbolu piešķiršanas (assign) sekcijā un GRAPES-BM izteiksmēs. Šeit parādīsim mazu piemēriņu, kā var izmantot mainīgos kopīgas atmiņas modelēšanai.

Aplūkosim šādu uzdevumu (skat. Zīm. 26.1 kreiso pusi). No klienta ienāk pasūtījumi izgatavot detaļas. Dispečers pieņem šos pasūtījumus un nodod tālāk izpildīšanai. Katras detaļas izgatavošana sastāv no diviem darbiem, kurus vienkāršības labad sauksim par Darbība_1 (Activity_1) un Darbība_2 (Activity_2). Dienas beigās saražotās detaļas dispečers nosūta klientam.

Pieņemsim tagad, ka ir vēl šāda papildprasība: ir zināmas izmaksas katram no šiem diviem darbiem - attiecīgi 10 un 15 vienības un tiek prasīts, lai dienas beigās kopīgās izmaksas tiktu paziņotas dispečeram. Pieņemsim, ka ar izmaksu summēšanu nodarbojas grāmatvedis.

Zīm. 26.1. Atmiņas modelis

 

 

 

 

 

 

Zīm. 26.2. Notikumu un mainīgo tabula atmiņas modelim

Zīm. 26.1 ir parādīts, kā šo situāciju modelēt ar GRAPES-BM 4.0 līdzekļiem. Zīm. 26.2 ir dotas attiecīgo notikumu un mainīgā Total definīcijas. Galvenā ideja šeit ir - kopīgo atmiņu modelēt ar mainīgā palīdzību. Dotajā piemērā tas ir mainīgais Total. No rīta (Nine_am) Total vērtība tiek uzstādīta vienāda ar 0. Tālāk, kad no attiecīgā uzdevuma ienāk ziņojums Expense par to, cik šis darbs ir izmaksājis, mēs ar

Total :=Total + Expense

palīdzību uzstādām jaunu Total vērtību. Viegli saprast, ka tādā veidā mainīgajā Total tiks uzkrāta kopīgā izmaksu summa par doto darba dienu. Darba dienas beigās (Five_pm) Total vērtība tiek ierakstīta dienas atskaites atbilstošajā ailē un nosūtīta dispečeram.

Viegli saprast, ka šādā veidā mēs varam modelēt arī sarežģītākas darbības ar kopīgās atmiņas elementiem. Piemēram, pietiekoši adekvāti var attēlot situāciju, kad kādu detaļu ražošanai ir nepieciešami noteikti materiāli un mēs gribam kontrolēt šo materiālu izlietojumu. Šajā gadījumā iepriekšminētais grāmatvedis pārvērtīsies par materiālu noliktavas pārzini, bet patiesais materiālu daudzums noliktavā tiks attēlots, piemēram, ar mainīgo X, kuru tāpat izmantos kāda uzdevuma piešķiršanas sekcijā. Izmantojot šo mainīgo zarošanās nosacījumā, var arī “noprogrammēt”, lai noliktavas pārzinis sekotu līdzi patiesajam materiālu daudzumam un gadījumā, kad šis daudzums kļūst mazāks par kritisko robežu, pasūtītu jaunu materiālu porciju (nosūtot attiecīgu ziņojumu).