13.Vēlreiz par biznesa modelēšanas mērķiem
Pirms pārejam pie valodas GRAPES-BM sīkāka izklāsta, raksturosim mērķi, uz kuru tiecamies. Vispirms ir jāsaprot, ka biznesa modelēšanas mērķis nav līdz galam formalizēt tos uzdevumus, kurus sistēma veic. Piemēram, ja sistēma veic tādus uzdevumus, kā izgatavot automašīnas motoru vai samontēt mikroshēmu, tad ir skaidrs, ka, lai arī cik attīstīta būtu biznesa modelēšanas valoda, līdz galam formalizēt šāda veida uzdevumus dotajā valodā mēs nevarēsim, tam ir nepieciešamas specializētas valodas. Tāpat šķiet bezcerīgi tik tālu attīstīt biznesa modelēšanas līdzekļus, lai ar tiem līdz galam precīzi varētu aprakstīt netriviālus datu apstrādes uzdevumus - priekš tā ir attiecīgas programmēšanas valodas.
Bet kāds tad ir mērķis, uz kuru jātiecas biznesa modelēšanas valodai? Atbilde ir sekojoša: biznesa modelēšanas valodai ir jādod līdzekļi, ar kuru palīdzību var aprakstīt sistēmas veicamo uzdevumu svarīgākos raksturojumus. Piemēram, pie kādiem nosacījumiem dotais uzdevums ir jāsak izpildīt (triggering condition), kas ir šī nosacījuma izpildītājs (performer), cik ilgā laikā dotais uzdevums ir jāizpilda (duration) un tml. Citiem vārdiem sakot, galvenais, kas biznesa modelēšanas valodai ir jānodrošina, tā ir prasību specifikācija (requirement specification). Kas attiecas uz sistēmas implementāciju, tad tas jau ir citu valodu un līdzekļu uzdevums.
Iepriekšējās nodaļās aprakstītos biznesa modelēšanas līdzekļus var uzskatīt par pašiem nepieciešamākajiem prasību specifikācijai. Šie līdzekļi ir vairāk vai mazāk pietiekoši, lai būvētu rupjus sistēmu biznesa modeļus. Taču tālākos sistēmas projektēšanas etapos parasti ir nepieciešami detalizētāki biznesa modeļi, kurus var imitēt, lai atklātu projekta iespējamās šaurās vietas vai kļūdas. Šim nolūkam gan uzdevumi, gan notikumi ir jāapraksta daudz detalizētāk. Nākamās nodaļas tad arī ir veltītas nepieciešamajiem valodas papildlīdzekļiem:
14. nodaļa - sistēmas orgstruktūras aprakstīšanas līdzekļiem;
15. nodaļa - valodā GRAPES-BM pieņemto datu tipu definēšanas līdzekļiem (īss izklāsts). To izmantos nākamajās nodaļās;
16. nodaļa - notikumu detalizētas aprakstīšanas līdzekļiem;
17. - 23. nodaļa - veselai virknei papildiespēju uzdevumu sīkākam raksturojumam;
24. nodaļa - elementāriem līdzekļiem, ar kuru palīdzību var sīkāk detalizēt izejas notikumus.
Uz šiem līdzekļiem var skatīties arī no cita viedokļa. Biznesa modelis (skat. 5. nodaļu), patiesībā ietver sevī 3 savstarpēji saistītus modeļus:
1. Orgstruktūras modeli;
2. Datu modeli;
3. Dinamisko modeli, kura galvenā sastāvdaļa ir sistēmas biznesa procesi.
Šajos terminos runājot, varam teikt arī, ka 14. nodaļa ir veltīta sistēmas orgstruktūras modelēšanai, 15. nodaļa - sistēmas datu modelēšanai, bet 16. - 25. nodaļas - pamatā to līdzekļu izklāstam, kas attiecas uz dināmisko modelēšanu.
Var arī uz nākamajām nodaļām raudzīties kā uz īsu valodas GRAPES-BM kopsavilkumu, kas domāts tiem lasītājiem, kuri biznesa modelēšanas pamatidejas jau ir apguvuši.
Vairumā gadījumu sistēmas izpratne sākas ar tās orgstruktūras izpratni. Acīmredzot, tā nebija nejaušība, ka aplūkojot pat tik vienkāršu piemēru kā Kantoris 3. nodaļā, mēs sākām ar kantora organizatoriskās struktūras aprakstu.
Valoda GRAPES-BM satur attīstītus līdzekļus sistēmas orgstruktūras modelēšanai (aprakstīšanai). Šim nolūkam kalpo jau 4. nodaļā pieminētā ORG diagramma. Šajā nodaļā mēs dosim pilnīgāku ORG diagrammas aprakstu, vienlaicīgi aplūkojot arī kompetences jēdzienu un tā lietošanu.
ORG diagramma tiek būvēta izmantojot speciālus grafiskus simbolus orgvienību (unit), resursu (resource) un štata vietu (position) apzīmēšanai. Pie tam tiek šķiroti atsevišķie (single) un daudzkārtīgie (multiple) elementi.
Paskaidrosim ar piemēru palīdzību:
|
atsevišķa orgvienība (Comp_Sci_Department); | |
|
daudzkārtīga orgvienība (Department), skaitlis 5 šeit nozīmē attiecīgo orgvienību (dotajā gadījumā departamentu) skaitu - drīkst arī šo skaitli nenorādīt; | |
|
atsevišķa štata vieta (Head); | |
|
daudzkārtīga štata vieta (Programmer), skaitlis 15 šeit nozīmē attiecīgo štata vietu skaitu, drīkst arī nenorādīt; | |
|
atsevišķs resurss (Computer_No_007); | |
|
daudzkārtīgs resurss (Computer); skaitlis 25 šeit nozīmē attiecīgo resursu (dotajā gadījumā datoru) skaitu, drīkst arī nenorādīt. |
ORG diagramma no šiem elementiem tiek būvēta kā hierarhiska struktūra, izmantojot attiecības
kur owns attiecas uz resursiem, bet consists of attiecas uz pārējiem elementiem.
Precīzāk,
aiz 1, 2 var sekot consists of 1, 2, 3, 4
aiz 1, 2, 3, 4 var sekot owns 5, 6
aiz 5, 6 var sekot consists of 5, 6
Zīm. 14.1, 14.2 un 14.3 ir doti ORG diagrammu piemēri.
Zīm.14.1. Departaments ar divām laboratorijām
Zīm.14.2. Departaments ar divām atsevišķām laboratorijām
Zīm. 14.3 ir parādīts, kā attēlo tos ORG diagrammas elementus, kuri attiecībā pret aplūkojamo sistēmu ir ārējie (external). Šie elementi tiek iezīmēti ar pārtrauktu kontūru.
Zīm.14.3. ORG diagramma ar ārējiem elementiem un izdalītiem fragmentiem
Viens biznesa modelis var saturēt vairākas ORG diagrammas, šīm diagrammām modeļa kokā var piešķirt vārdus (skat. Zīm. 5.3). Tas dod iespēju ORG diagrammas zināmā nozīmē strukturēt - pirmajā ORG diagrammā mēs varam attēlot rupju iestādes orgstruktūru, nākamajās ORG diagrammās mēs varam sīkāk detalizēt katru rupjās ORG diagrammas sastāvdaļu. Piemēram, Zīm. 14.3 attēloto ORG diagrammu mēs dabiski varam sadalīt divās ORG diagrammās, kur pirmā attēlo Institūta sadalījumu pa Departamentiem, bet otra - Departamenta A struktūru, pie tam katrai no šim diagrammām modeļa kokā mēs varam piešķirt pietiekoši izteiksmīgu vārdu.
Vēl viena svarīga piezīme tiem, kas lieto GRAPES-BM tikai modelēšanas vajadzībām un nerūpējas par iegūtā biznesa modeļa imitāciju. Šādi tīrie modelētāji drīkst atkāpties no precīzas GRAPES-BM semantikas. Viena šāda atkāpe ir dabiska tieši ORG diagrammām. Proti, bieži gribas attēlot ne tikai iestādes orgstruktūru, bet arī iestādes administratīvo struktūru, norādot, kuram kurš ir pakļauts. To var izdarīt, pieļaujot ORG diagrammās pakļautības izskatā:
GRAPES-BM redaktors neaizliedz zīmēt šādas pakļautības. Šīs pakļautības jālasa sekojoši:
Person manages Unit_x
Person manages Person_x
Formāli pakļautības ORG diagrammas ir izmantojamas arī imitācijai domātajos modeļos. Imitators nepieļauj vienīgi vienlaicīgu gan organizatoriskās, gan administratīvās struktūras attēlojumu vienā modelī. Sintakses analīze to atzīs par kļūdu. Tīrajam modelētajam par to nav jāuztraucas.
ORG diagrammas elementiem var būt sekojoši atribūti:
Pirmajiem trim atribūtiem ir jābūt skaidriem no iepriekšējā izklāsta. Sīkāk pakavēsimies pie pārējiem atribūtiem.
Kompetence (competency) tiek uzdota, uzskaitot dotajam elementam piemītošās kompetences (atdalītas ar komatu):
identif1, identif2, ...
Štata vietai Programmer, piemēram, atbilstošais kompetenču saraksts varētu būt :
Pascal, Ada, Cplus
Resursam Computer, piemēram, atbilstošais kompetenču saraksts varētu būt:
PC, More_than_80MHz, ...
Patiesībā kompetences lietojums ir daudz plašāks, nekā vienkārši uzdot attiecīgas štata vietas (un tai piekārtotās personas) kompetenci šī vārda tradicionālā nozīmē.
Plašākā nozīmē ar kompetenci ir jāsaprot jebkurš elementa īpašības apzīmējums (identifikatora formā). Piemēram, tas var būt darbinieka kategorija, darbinieka vecums, darbinieka dzimums (vīrietis, sieviete) u.t.t.
Šāda plašāka kompetences izpratne dod iespēju izmantot kompetences jēdzienu, lai ORG diagrammas elementus varētu sadalīt pa klasēm. Aplūkosim piemēru Klubs. Pieņemsim, ka Klubs sastāv no Prezidenta, Sekretāra, Junioriem un Senioriem. Pieņemsim, ka Kluba locekļi skaitās tikai Prezidents un Seniori. Kā to formāli pateikt? To var izdarīt ar kompetences palīdzību, kā tas parādīts Zīm. 14.4
Zīm.14.4. ORG diagramma ar kompetencēm
Tagad aplūkojam pārējos atribūtus.
Darba laiks (availability). Ar to saprot laika intervālu, kad dotais darbinieks (vai visa orgvienība) ir pieejams, t.i. var piedalīties uzdevumu izpildē. Tālāk seko laika intervālu piemēri, pierakstīti atbilstoši GRAPES-BM prasībām:
(08:00-17:30) - katru dienu no plkst. 8.00 līdz 17.30
*.*.* (08:00-17:30) - arī katru dienu no plkst. 8.00 līdz 17.30
(08:00-13:00,14:00-17:30) - katru dienu no plkst. 8.00 līdz 13.00 un no 14.00 līdz 17.30
*.*.01 - katra mēneša 1. datumā (no plkst 00.00 līdz 24.00)
*.*.01 (00:00-23:59) - katra mēneša 1. datumā no plkst 00.00 līdz 24.00
*.06.(01-05,15-20) - no 1. līdz 5. jūnijam un no 15. līdz 20. jūnijam
*.*.(MON-FRI) - katru darbdienu (no pirmdienas līdz piektdienai)
*.*.01 (08:00-17:30) - katra mēneša 1. datumā no plkst 8.00 līdz 17.30
*.*.(MON-FRI) (08:00-17:30) - katru darbdienu (no plkst. 8.00 līdz 17.30)
*.*.(MON,WED) (08:00-09:00,13:30-14:00)- katru pirmdienu un trešdienu no plkst. 8.00 līdz 9.00 un no 13.30 līdz 14.00
Kā redzams no šiem piemēriem, laika intervāls ir jāuzrāda vai nu ar precizitāti līdz dienai, vai arī līdz minūtei.
Stundas cena (cost per hour) - INTEGER vai FLOAT tipa konstante (piemēram, 2.50), kas norāda, cik izmaksā viena darba stunda attiecīgajai orgvienībai, štata vietai vai resursam (atkarībā no tā, kam šis atribūts ir piekārtots). Šis atribūts tiek izmantots rēķinot uzdevuma predefinēto atribūtu COST (skat. 18. nodaļu).
Efektivitātes līmenis (efficiency level) - FLOAT tipa konstante lielāka par 0, piemēram, 0.5. Šajā gadījumā tas nozīmē, ka dotais izpildītājs (orgvienība, štata vieta vai resurss) veic savu darbu ar efektivitāti 50% (attiecībā pret standartefektivitāti 100%, kas atbilst noklusētajam efektivitātes līmenim). Uzdevumiem pierakstāmais izpildes laiks (duration) atbilst izpildītāju standartefektivitātei (t.i. 100%). Piemēram, ja uzdevumam A ir pierakstīts izpildes laiks 2h, bet viņam atbilstošais izpildītāja efektivitātes līmenis ir 0.5, tad patiesais šī uzdevuma izpildes laiks būs 4h. Ja uzdevumam ir iespējami vairāki izpildītāji, tad nejauši tiek izvēlēts viens no brīvajiem izpildītājiem, vienalga kāda ir viņa efektivitāte.
Vēl ir palicis viens atribūts - darbinieka vārds (employee name), kas var tikt pierakstīts tikai atsevišķai štata vietai, viņam ir jābūt likumīga identifikātora formā, piem., Jsmith vai J_Smith.
Līdz ar to visi iespējamie ORG diagrammas elementu atribūti ir aplūkoti.
Noslēgumā vēl daži vārdi par Kompetenču Tabulu (Competencies Table). Kompetenču Tabula (CMP), tāpat kā ORG diagramma (ORG), ir redzama modeļa kokā (skat. Error! Reference source not found.). Kompetenču tabulai ir jāsatur visi tie kompetenču identifikātori, kas parādās ORG diagrammas elementos. Rīks nodrošina iespēju CMP tabulu aizpildīt reizē ar jaunas kompetences ierakstu ORG diagrammas elementā. No otras puses, ja kompetenču tabula ir izveidota iepriekš (tā tam būtu jābūt!), tad aizpildot ORG diagrammas elementus, rīks ļauj izvēlēties jau esošos kompetenču identifikatorus no CMP. Kompetenču Tabulas piemērs parādīts Zīm. 14.5.
Zīm.14.3. CMP tabulas piemērs
15. Datu modelēšana
Valodā GRAPES-BM ir paredzēti sekojoši elementārie datu tipi:
INTEGER
FLOAT
STRING
TIME
DURATION
Ar INTEGER tipa datiem var izpildīt visas tradicionālās aritmētiskās operācijas:
+, -, *, DIV, MOD
Līdzīgi ar FLOAT tipa datiem var izpildīt operācijas:
+, -, *, /
Arī INTEGER un FLOAT tipa konstantes attēlo tradicionālā formā: 25, -25, 25.05, -25.05 u.t.t.
Ar STRING tipa datiem nekādas operācijas nav paredzētas, aplūkojamā GRAPES-BM versijā tiem ir tikai ilustratīva nozīme.
Ar TIME un DURATION tipa datiem var izpildīt sekojošas aritmētiskas operācijas:
DURATION + DURATION 
DURATION
DURATION - DURATION DURATION
DURATION DIV DURATION INTEGER
DURATION / DURATION FLOAT
DURATION * INTEGER DURATION
DURATION * FLOAT DURATION
TIME + DURATION TIME
TIME - DURATION TIME
TIME - TIME DURATION
TIME tipa konstantes attēlo sekojoši:
tukšums
|
1995.06.15 09:30
/ | \ \ \
gads mēnesis diena stunda minūte
Likumīgas ir arī saīsinātās konstantes - datumi:
1995.06.15
DURATION tipa konstanšu attēlojumu raksturo sekojoši piemēri:
2h - 2 stundas
15m - 15 minūtes
2.5h - 2 stundas un 30 minūtes
2h:30m - 2 stundas un 30 minūtes
150m - 150 minūtes
Vispār DURATION tipa konstantēs var izmantot:
d - dienas aprakstīšanai,
h - stundu aprakstīšanai,
m - minūšu aprakstīšanai,
s - sekunžu aprakstīšanai,
piemēram, 3d:12h:20m:10s.
Kā redzams no iepriekšējiem piemēriem, kā TIME tā arī DURATION tipa konstantes tiek ieslēgtas pēdiņās:
Izteiksmes tiek būvētas tradicionālā veidā izmantojot iepriekšminētās operācijas, kā arī varbūtiskās (random) funkcijas:
UNIFORM (min, max)
NORMAL (mean, deviation)
EXPONENTIAL (mean),
kuru argumenti ir attiecīgi INTEGER, FLOAT vai DURATION tipa, piemēram EXPONENTIAL (2), EXPONENTIAL (2.5), EXPONENTIAL (2m).
TIME tipa gadījumā ir paredzētas vēl divas iebūvētas funkcijas:
NOW un START_TIME,
bet viņu lietojums ir ierobežots - piemēram, tās nedrīkst lietot trigerēšanas nosacījuma WHERE daļā.
Būvējot loģiskas izteiksmes, INTEGER, FLOAT, TIME un DURATION tipa datiem ir paredzētas tradicionālās salīdzināšanas operācijas:
=, < >, >, <, >=, <=
Pašās loģiskajās izteiksmēs ir atļauts lietot tikai operātorus AND un OR (un to alternatīvos apzīmējumus & un | ).
No saliktajiem datu tipiem valodā GRAPES-BM ir paredzēti tikai raksti (record). Tie tiek definēti grafiski, kā tas parādīts Zīm. 15.1.
Zīm.15.1. Datu tips Address
Zīm.15.2. Divu līmeņu definīcija
Abas šīs definīcijas var apvienot arī vienā kokā, kā tas parādīts Zīm.15.2.
Lauka un tipa vārds drīkst arī sakrist. Piemēram, iepriekšējos zīmējumos Name_type vietā varēja rakstīt arī vienkārši Name.
Raksti var būt kā dziļumā 1 (t.i., visi to pirmā līmeņa lauki jau ir elementāri), tā arī lielākā dziļumā.
Datu tipu definīcijas tiek attēlotas t.s. DD diagrammā ar apakštipu DATATYPE. Ja vienā diagrammā visas tipu definīcijas nenovietojas, var lietot vairākas diagrammas. Diagrammas vārdu var izvēlēties patvaļīgi, bet parasti par tās vārdu izvēlās galvenā datu tipa vārdu, kas dotajā diagrammā tiek definēts (iepriekšējā piemērā tas ir Address (Adrese)).
Modeļa kokā DD diagrammas ir novietotas pirmajā līmenī, kā tas parādīts Zīm. 5.3.
ER modeli (Entity-relationship model) definē ar ER diagrammas palīdzību, kā tas parādīts Zīm. 15.3.
Zīm.15.3. DD ER diagrammas piemērs
Entīšu tipiem ir jābūt rakstiem, definētiem DATATYPE DD diagrammās.
Tipa vārdu, ja tas atšķiras no entītes vārda, norāda atklāti (Zīm. 15.3 entītei Person). Ja tipa vārds sakrīt ar entītes vārdu, tad to drīkst nerakstīt (Zīm. 15.3 entītēm Address un Employer).
Atgādināsim, ka ER modelis biznesa modelēšanā tiek izmantots, lai aprakstītu Datu noliktavas struktūru.
Parasti tas tiek darīts detalizētās projektēšanas stadijās. Tad būtisku lomu spēlē precīzas norādes par to, kādas entītes un kādā veidā attiecīgais uzdevums izmanto. Šim nolūkam kalpo Pieeju Tabulas.
Pieeju tabula (AT table) tiek piekārtota atsevišķam uzdevumam (skat. Zīm. 5.3) un tā satur norādes par to, kādas entītes un no kādām datu noliktavām dotais uzdevums izmanto. Zīm.15.4 ir dots pieeju tabulas piemērs. Šī pieeju tabula atbilst vienam konkrētam uzdevumam, tā satur datu noliktavas vārdu (aiz Database:), kolonnas: Entity name (entītes vārds), Access rights (pieejas tiesības: R - tikai lasa, A - pievieno jaunas entītes, U - izmaina esošo entīšu laukus, D - izmet entītes, G - jebkuras pieejas tiesības) un Description (komentārs).
Zīm.15.4. Pieejas tabulas piemērs
Patiesībā ER modelis, kas šeit ir pieminēts ļoti īsi, ir svarīga GRAPES-BM sastāvdaļa. Tas dod iespēju detalizētās projektēšanas stadijās veikt to, ko sauc par datu modelēšanu, - t.i. izstrādāt projektējamās sistēmas datu modeli. Atgādināsim, ka iepriekšējās paaudzes rīki tieši bija balstīti uz datu bāzēm, un datu modelis faktiski bija vienīgais modelis, ko atbalstīja šie rīki. Tālāk jau sekoja programmēšana attiecīgajā 4-tās paaudzes valodā. Nelielu sistēmu gadījumā tāda pieeja sevi pilnīgi attaisnoja. Taču sarežģītu sistēmu gadījumā ar to vien nepietiek; pirms mēs nokļūstam pie datu modeļa, vēl jānoiet krietni garš ceļš veicot kā sistēmas orgstruktūras, tā arī (pats galvenais!) tās darbības modelēšanu.
Tātad, no biznesa modelēšanas viedokļa raugoties datu modelis ir zināmā nozīmē projektēšanas noslēdzošais etaps. Tālāk jau seko programmēšana attiecīgajā programmēšanas valodā, kur biznesa modelēšanas rezultātā uzkonstruētie biznesa procesi kalpo par specifikāciju, rakstot programmas.
Šajā grāmatā sīkāk neiztirzāsim mainīgo tabulu VT, kura domāta imitācijas vajadzībām. Vienīgi 26. (programmēšanas) nodaļā aplūkosim nelielu piemēru ar mainīgo izmantošanu.
Notikumi tiek definēti, tiklīdz attiecīgā bultiņa parādās BP vai TD diagrammā. Citiem vārdiem sakot, tiklīdz notikums ar vārdu tiek iezīmēts kādā no minētajām diagrammām, tā uzreiz tas automatiski parādās Notikumu Tabulā (to nodrošina rīks). Var arī sākt ar Notikumu Tabulu un pēc tam izmantot definētos notikumus BP un TD diagrammās.
Zīm.16.1 ir attēlots Notikumu Tabulas piemērs. Modeļa kokā , kā tas redzams Zīm. 5.3, Notikumu Tabula (ET) ir novietota pašā augšējā rindiņā un tā ir kopīga (globāla) visam modelim.
Zīm.16.1. Notikumu tabula (Event Table)
Notikumu Tabulas kolonnas rāda, kādu informāciju par notikumiem mēs varam uzdot.
Blakus vārdam (Event name) svarīga ir notikuma kategorija (Category) un notikuma tips (Data type).
Kā jau atzīmējām 2. nodaļā, notikumu kategoriju lietotājs var definēt brīvi. Tomēr, valodā GRAPES-BM eksistē 5 predefinētas notikumu kategorijas:
Ziņojumiem (MESSAGE, MATERIAL un lietotāja definētas kategorijas notikumiem) šajā kolonnā var norādīt datu tipu. Datu tips var būt:
Ja notikumam tips nav norādīts, tad imitācijā uzskata, ka šāds notikums datus sev līdzi nenes, t.i. no svara ir tikai fakts, vai notikums ir noticis vai nē.
Laika notikumiem (taimeriem) tipa kolonnā tiek dota definīcija, kā tas parādīts zīmējumā 16.1.. Daļēji par to jau runājām 2. nodaļā, šeit minēsim vēl dažus laika notikumu definīciju piemērus:
TIME(*.*.*) - katru dienu
TIME(*.*.* 09:00) - katru dienu plkst. 9.00
TIME(*.*.* *:*) - katru minūti
TIME(*.*.MON 09:00) - katru pirmdienu plkst. 9.00
Jebkuras zvaigznītes vietā var rakstīt arī intervālu un konstanšu sarakstu:
TIME(*.(01-03,06,12).(01,15)) - janvāra, februāra, marta, jūnija un decembra 1. un 15. datumā
TIME(*.(01,07).(MON-FRI) (9:00,17:00)) - janvārī un jūlijā katru darbadienu plkst. 9.00 un plkst 17.00.
Kā rāda iepriekšējie piemēri, datuma vietā var rakstīt arī nedēļas dienas:
Vēl daži taimera definīciju piemēri, izmantojot REPETITION jēdzienu:
REPETITION (EXPONENTIAL(2m)) - vidēji ik pēc 2 minūtēm (pēc eksponenciālā sadalījuma)
REPETITION(UNIFORM(1m,10m)) - vienmērīgi sadalīts intervālā no 1 līdz 10 minūtēm
Noslēgumā pieminēsim vēl vienu laika notikuma definīciju:
Tas nozīmē, ka šis taimeris vienmēr nostrādās sistēmas starta brīdī (imitācijas gadījumā tiek uzskatīts, ka tas notiek, startējot imitācijas seansam).
Kolonnā Persistence interval norāda, cik ilgi notikums stāv rindā pie uzdevuma; ja šajā laikā dotais notikums netiek patērēts, tas pazūd no rindas pats automātiski. Intervāla norādīšanai lieto DURATION tipa konstantes. Vienīgā atšķirība starp laika notikumiem un ziņojumu notikumiem ir persistences intervāla noklusētajā vērtībā: laika notikumu gadījumā tā ir 0, ziņojumu notikumu gadījumā - bezgalība.
Kolonna Transfer time ir domāta tikai ziņojumu notikumiem. Šajā kolonnā norāda notikuma ceļošanas ilgumu no tā rašanās brīža līdz tā nokļūšanai līdz attiecīgā uzdevuma ieejas notikumu rindai. Transfer time noklusētā vērtība ir 0, t.i. - tiek uzskatīts, ka notikums pārvietojas momentāli. Atzīmēsim, ka transfer time var arī pārdefinēt (vai nodefinēt no jauna) BP diagrammā, kur attiecīgais notikums parādās (pie tam katrai šī notikuma sastapei var nodefinēt savu transfer time).
Vēl ir viena kolonna - Description. Šajā kolonnā var dot attiecīgā notikuma neformālu aprakstu (vai jebkuru citu komentāru).
Ja mūs neapmierina notikuma transfer time, kas dots Notikumu Tabulā, tad BP diagrammā katrai notikuma sastapei (occurrence) mēs varam norādīt savu transfer time, kā tas parādīts Zīm. 16.2.
Zīm.16.2. Lokāla transfer time pārdefinēšana
Vēl BP diagrammā jebkuram izejas notikumam varam norādīt, ka tas nav obligāts, ieliekot to kvadrātiekavās, kā tas parādīts Zīm. 16.3. Atzīmēsim, ka standartsemantika attiecībā uz uzdevuma izejas notikumiem ir tāda, ka visiem izejas notikumiem, kas dotajam uzdevumam ir attēloti BP diagrammā, ir arī jānotiek uzdevuma izpildes rezultātā.
Zīm.16.3. Neobligāts notikums
Vēl uz konkrētā notikuma sastapi BP diagrammā attiecas iespēja noņemt notikumam viņa TIDu, kā tas parādīts Zīm. 16.4 (par to jau runājām 10. nodaļā):
Zīm.16.4. Notikuma TIDa dzēšana
Ko par notikumiem papildus var pateikt TD diagrammā (un līdz ar to tas attieksies uz jebkuru šī uzdevuma sastapi BP diagrammā) - par to runāsim 24. nodaļā.
17. Uzdevuma specifikācija (TD diagramma)
Ar uzdevuma specifikāciju mēs saprotam to informācijas kopumu, ko valodā GRAPES-BM var uzdot (pierakstīt) par doto uzdevumu. Pilnā apjomā šī informācija ir redzama uzdevuma TD diagrammā. Vienkāršas TD diagrammas jau aplūkojām 7. nodaļā. Zīm. 17.1 ir dots pietiekoši vispārīgs TD diagrammas piemērs.
Daļa no šīs informācijas ir redzama arī BP diagrammā, kur dotais uzdevums sastopams (skat. Zīm. 17.2), proti:
Parasti, saskaņā ar ieteicamo modeļa veidošanas secību, lietotājs šos laukus aizpilda tieši BP diagrammā. Kad uzdevuma sastape parādās pirmo reizi, rīks izveido šim uzdevumam TD diagrammu biznesa modeļa kokā un turpmāk rūpējas par informācijas pārnešanu no BP uz TD. Ja pirmā ir izveidota TD, tad rīks palīdz pārnest informāciju no TD uz uzdevuma sastapēm BP diagrammās. Rīkā iebūvētie līdzekļi palīdz nodrošināt vispārēju atbilstību starp uzdevuma TD un šī uzdevuma sastapēm BP diagrammās.
Vēlreiz uzsvērsim, ka gadījumos (un tādu ir vairums), kad pietiek ar minētajiem atribūtiem, lietotājs par TD diagrammu var nemaz neinteresēties, vajadzīgos atribūtus ierakstot tieši uzdevumu sastapēs BP diagrammā.
Uzdevuma sastapē ir iespējams arī komentārs. Tas ir lokāls atribūts, attiecas tikai uz konkrēto sastapi BP diagrammā un netiek pārnests uz TD. Komentārs ir novietots tūlīt zem uzdevuma vārda, parasti mazākā fontā (skat. Zīm. 17.2). Tas dod iespēju lietot īsākus uzdevumu vārdus, saturīgo nosaukumu atstājot uz komentāru.
Tālākās nodaļās tiks dots TD galveno sastāvdaļu - ķermeņa, zarojumu un izejas notikumu sīkāks apraksts. Bet pirms mēs ķeramies pie šiem aprakstiem, mums jāizskaidro vēl viena papildiespēja, un proti, iespēja norādīt uzdevumam viņa tipu un atribūtus (tos var redzēt arī Zīm. 17.1).
Zīm.17.1. TD diagramma
Zīm.17.2. Uzdevuma sastape BP diagrammā
18. Uzdevumu tipi un uzdevumu atribūti. Atribūtu tabulas
Kā redzam Zīm. 17.1, uzdevumam var būt atribūti (attributes). Ar atribūtu palīdzību var precīzāk raksturot aplūkojamo uzdevumu.
Aplūkosim tagad jaunu uzdevumu Produce_Part_A, kur A - kaut kāda detaļa (Zīm. 18.1). Pieņemsim, ka dotajam uzdevumam ir viens ieejas notikums Ev1 ar tipu INTEGER, kurš norāda, cik detaļas A eksemplāru ir jāizgatavo. Pieņemsim, ka detaļas A izgatavošanā tiek tērēti materiāli X un Y. Tādā gadījumā dotā uzdevuma atribūti varētu būt sekojoši:
Material_X_Costs - materiāla X izmaksas viena detaļas eksemplāra izgatavošanai,
Material_Y_Costs - materiāla Y izmaksas viena detaļas eksemplāra izgatavošanai,
Material_X_T_Costs - materiāla X summārās izmaksas visu detaļas eksemplāru izgatavošanai,
Material_Y_T_Costs - materiāla Y summārās izmaksas visu detaļas eksemplāru izgatavošanai,
Material_Total_Costs - materiālu X un Y summārās izmaksas visu detaļu eksemplāru izgatavošanai pareizinātas ar 1.2, lai segtu papildizmaksas.
Vēl pieņemsim, ka Material_X_Costs viena detaļas eksemplāra izgatavošanai ir 10 USD, bet Material_Y_Costs - 25 USD.
Tādā gadījumā uzdevuma atribūti būtu jāattēlo atbilstoši Zīm. 18.1.
Zīm.18.1. Uzdevuma Produce_part_A atribūti
Kāda loma šeit ir uzdevuma tipam (dotajā gadījumā Part_Production)? Uzdevuma tips ir tas, kas nosaka, kādi atribūti ir šī tipa uzdevumiem.
Uzdevuma tipam atbilstošie atribūti (un to rēķināšanas formulas) tiek definēti Atribūtu tabulā (ATR table).
Atribūtu tabulas vārds reizē kalpo arī par uzdevuma tipa vārdu, modeļa kokā (skat. Zīm. 5.3) atribūtu tabulai atbilst elements
ATR TYPE Name_of_Task_Type
Atribūtu tabula ar vārdu Part_Production varētu izskatīties tāda, kāda tā ir parādīta Zīm. 18.2.
Zīm.18.2. Atribūtu tabula Part_Production
Atribūtu tabula tiek izmantota tādā veidā, ka tiklīdz mēs kādam uzdevumam piešķiram tipu, piemēram, Part_Production, tā tūdaļ tiek uzskatīts, ka dotajam uzdevumam visi šie atribūti piemīt. TD diagrammā mēs varam šo atribūtu vērtības pārdefinēt (vai tieši šeit nodefinēt pirmo reizi). TD diagrammas ķermenī atklāti ir redzami tikai tie atribūti, kam vērtības ir piešķirtas tieši šeit. Pārdefinēt var gan atribūtu konstantās (default) vērtības, tā arī to rēķināšanas formulas. Zīm. 18.1 attēlotajā TD piemērā tiek uzskatīts, ka visu atribūtu vērtības (salīdzinot ar Zīm. 18.2) tiek pārdefinētas, tādēļ tās visas ir redzamas TD diagrammas ķermenī.
Atribūtu rēķināšanas formulas var saturēt visus no dotā uzdevuma redzamos lielumus: citus šī uzdevuma atribūtus, uzdevuma izpildes laiku (atribūtu ar vārdu DURATION), ieejas notikumu laukus, arī predefinētu atribūtu ar vārdu COST. Atribūts COST uzdevumā atklāti nav redzams, tā vērtību definē un automātiski rēķina kā
DURATION * Cost per hour,
kur Cost per hour ir uzdevuma izpildītāju vienas stundas cena (šī cena ir redzama ORG diagrammā).
Kā redzams no iepriekš teiktā, atribūtu rēķināšanas formulas ir uzdevumu TD īpašība, t.i. šīs formulas ir kopīgas visām dotā uzdevuma sastapēm BP diagrammā. Taču atribūtu vērtības, kas izrēķinātas ar šo formulu palīdzību, ir dotā uzdevuma sastapes (occurrence) īpašība.
Uzdevuma atribūtiem, tai skaitā arī predefinētajiem atribūtiem DURATION un COST, ir svarīga nozīme, kad mēs imitācijas procesā vācam statistiku par doto modeli. Šajā gadījumā mums ļoti nozīmīgas var būt tādas ziņas, kā summārie izdevumi, summārais materiālu patēriņš un tml. Šādas ziņas var iegūt summējot attiecīgos atribūtus imitācijas seansā.
19. Uzdevumu trigerēšanas nosacījumi
Daļēji tie tika skaidroti jau 2. nodaļā. Šajā nodaļā sniegsim zināmu pārskatu.
Sāksim ar trigerēšanas nosacījumu piemēriem (šajos piemēros e, f, g, h apzīmē notikumus):
AND (vai &)
nozīmē, ka visi uzdevuma dotajā sastapē BP diagrammā redzamie ieejošie notikumi tiek ANDoti
OR (vai |)
nozīmē, ka visi uzdevuma dotajā sastapē BP diagrammā redzamie ieejošie notikumi tiek ORoti
e AND f OR e AND g
nozīmē to pašu ko
(e AND f) OR (e AND g)
un to pašu ko
e AND (f OR g)
e AND f WHERE e.A=f.A
(šeit un turpmāk tiek uzskatīts, ka notikumiem e, f, g ir pierakstīti record datu tipi ar laukiem A un B)
f AND g AND h WHERE f.A=0 AND f.B=g.B
e OR (f WHERE f.A=0) OR (g WHERE g.A=1)
(e AND f WHERE e.A=f.A) OR (f AND g AND h WHERE f.A=0 AND f.B=g.B)
(šajos gadījumos WHERE grupu aptverošas iekavas ir obligātas)
e AND ALL f
izpildās, ja rindā ir vismaz viens notikuma f eksemplārs
e AND g AND ALL f
katrā AND grupā var būt tikai viens ALL, pie tam tikai pār vienu notikumu
e AND ALL f WHERE f.A=e.A
e AND f AND ALL g WHERE e.A=f.A AND g.A=0
(e AND ALL f) OR (g AND ALL f)
(arī ALL grupu aptverošas iekavas ir obligātas, ja šī grupa ieiet sarežģītākā loģiskā izteiksmē)
(e AND ALL f WHERE e.A=f.A) OR (g AND ALL f WHERE g.A=f.A)
(AND/ALL un AND/ALL/WHERE grupas savā starpā arī var būt savienotas ar OR)
e AND <25> f
e AND g AND <10> f
ALL vietā var stāvēt arī konkrēts skaitlis, ielikts iekavās < >, tikai šajā gadījumā nedrīkst sekot WHERE nosacījums; šis skaitlis norāda, cik attiecīgā notikuma eksemplāri ir jāpaņem no notikumu rindas; ja dotajā momentā rindā nav pietiekošā daudzumā attiecīgā notikuma eksemplāru, trigerēšanas nosacījums neizpildās
(e AND <25> f) OR (e AND <10> g)
(e AND g) OR (e WHERE e.A=0) OR (e AND ALL f WHERE f.A=0) OR (g AND <25>h)
vispārīgā gadījumā jebkuras AND grupas var būt savā starpā savienotas ar OR. AND un OR vietā var rakstīt arī & un |, piemēram:
(e & g) | (e WHERE e.A=0) | (e & ALL f WHERE f.A=0) | (g & <25>h)
Mēs uzskatīsim, ka iepriekš minēto trigerēšanas nosacījumu semantika ir pietiekoši skaidra un tādēļ pie tās sīkāk nekavēsimies.
Vienīgi atzīmēsim vienu svarīgu norunu par OR tipa trigerēšanas nosacījumiem: ja vairākas no OR -otām AND grupām vienlaicīgi ir patiesas, tad par reālo trigerēšanas nosacījumu tiek ņemta pirmā no kreisās puses. Piemēram, ja trigerēšanas nosacījums ir
e OR f OR g
un dotajā momentā rindā ir kā e, tā g, tad par īsto trigerēšanas nosacījumu tiks ņemts e (un arī e eksemplārs tiks izņemts no rindas). Šī noruna samērā bieži tiek izmantota sekojoša tipa trigerēšanas nosacījumiem:
e AND f OR e
Atbilstoši šai norunai, ja rindā ir e un f, tad viņi abi tiek patērēti; ja rindā ir tikai e, tad tikai e tiek patērēts.
Ir paredzēts arī otrs (nedaudz ekonomiskāks) veids, kā šo gadījumu aprakstīt, un proti, vienu ANDoto notikumu var ieslēgt kvadrātiekavās, piemēram,
e [AND f].
Tas nozīmē, ka dotā trigerēšanas nosacījuma izpildei f nav obligāts, bet ja tas ir rindā, tad uzdevumam startējot, tas tiks izņemts no rindas.
Noslēgumā vēl īsumā atgādināsim par vadības plūsmas (control flow) notikumiem, kuriem nav vārda. Attiecībā uz viņiem ir sekojoša noruna: ja trigerēšanas nosacījums ir tīrs OR (tikai atslēgas vārds OR un nekas vairāk), tad visi vadības plūsmas notikumi tiek OR -oti; pārējos gadījumos, ja trigerēšanas nosacījums ir AND vai jebkura loģiska izteiksme atšķirīga no tīrā OR , visi dotajā uzdevumā ienākošie vadības plūsmas notikumi tiek AND-oti.
Runājot par trigerēšanas nosacījumu semantiku vēl nedrīkst aizmirst, ka AND tipa trigerēšanas nosacījums, piemēram,
e AND f
būs patiess tikai tad, ja rindā būs notikumi e un f ar vieniem un tiem pašiem transakciju TID-iem (jeb bez TID-iem, jo jebkurš bezTID-u notikums AND -ojas ar jebkuru TID-otu notikumu). Izņēmums ir vienīgi attiecībā uz ALL un <n>: nosacījumos e AND ALL f un e AND <25>f tiek ignorēti notikuma f TID-i.
Otrs svarīgākais (pēc trigerēšanas nosacījuma) uzdevuma raksturojums ir uzdevuma izpildītāji. Tos uzdod ar izpildītāju nosacījuma palīdzību. Zīm. 17.1 (un Zīm. 17.2) šis nosacījums ir izskatā
Perf_1 AND Res_1
Vispārīgā gadījumā izpildītāju izteiksme ir loģiska izteiksme, uzbūvēta no elementāriem izpildītājiem, lietojot AND, OR (vai & un |) un vajadzības gadījumā arī iekavas.
Par elementāriem izpildītājiem var kalpot ORG diagrammas elementi.
Zīm.20.1. Institūta ORG diagramma
Piemēram, ja ORG ir Zīm. 20.1 attēlotā diagramma, tad par elementāriem izpildītājiem var kalpot:
Department_A
Department_B
Car
<2>Car (jebkuras 2 Institūta automašīnas)
Department_A.Head
Department_B. Head
Head (jebkurš no iepriekšējiem 2 vadītājiem)
Department_A.Programmer
Department_A.Programmer.DHigman (Departamenta A programmētājs vārdā DHigman)
<3>Department_A.Programmer (jebkuri 3 Departamenta A programmētāji)
<3>Programmer (jebkuri 3 programmētāji, vienalga, vai no Departamenta A,
vai no Departamenta B)
<2>DepartmentA.Computer (jebkuri 2 Departamenta A datori)
<2>Department_A.Programmer WITH COMPETENCY=Pascal, Cplus (jebkuri 2 Departamenta A programmētāji, kuri zina Pascal un Cplus)
<2>Department_A.Programmer WITH COMPETENCY= Cplus FOR 50% (jebkuri 2 Departamenta A programmētāji, kuri prot Pascal un Cplus, pie tam viņi tiks nodarbināti tikai par 50%
Departament_A.ANY (jebkura Departamenta A persona)
<2>Department_A.ANY WITH COMPETENCY=Pascal, Cplus (jebkuras 2 Departamenta A personas, kuras prot Pascal un Cplus)
<5>ANY WITH COMPETENCY= Cplus (jebkuras 5 Institūta personas, kuras prot Cplus)
Tālāk seko daži izpildītāju izteiksmju piemēri:
Department_A.Programmer OR Department_B.Programmer
Department_A.Programmer AND Department_A.Computer OR
Department_B.Programmer AND Department_B.Computer
<2>Department_A.Programmer WITH COMPETENCY=Pascal, Cplus
AND <3>Department_B.Programmer WITH COMPETENCY=Pascal, Cplus
Tātad, lai uzdevums sāktu izpildīties, ir nepieciešams, lai izpildītos kā trigerēšanas nosacījums, tā arī izpildītāju nosacījums. Izpildītāju nosacījums aplūkojamā laika momentā izpildās, ja šajā laika momentā ir brīvi elementārie izpildītāji, kuri tiek pieprasīti izpildītāju nosacījumā. Ar uzdevuma izpildes sākuma brīdi šie izpildītāji kļūst aizņemti uz uzdevuma izpildes laiku, ko nosaka dotā uzdevuma DURATION izteiksme.
21. Uzdevuma izpildes laiks (duration)
Vienkāršākā gadījumā uzdevuma izpildes laiks (duration) tiek attēlots kā DURATION tipa konstante, piemēram,
2d, 5h, 90m, 2d:5h, 2h:30m.
Uzdevuma izpildes laiks var būt arī DURATION tipa gadījuma funkcija, piemēram,
EXPONENTIAL(2m), UNIFORM (2.5m, 5m)
Vispārīgā gadījumā uzdevuma izpildes laiks var būt DURATION tipa izteiksme, kura kā argumentu var saturēt arī uzdevuma atribūtus un ieejas notikumu laukus. Piemēram, ja uzdevuma ieejas notikums ir Ev1, kura lauks x norāda, cik detaļas A eksemplāru ir jāizgatavo, tad dotā uzdevuma izpildes laiks būs
C*Ev1.x,
kur C - viena detaļas A eksemplāra izgatavošanas laiks, piemēram, 2m. Tātad likumīgs ir, piemēram, šāda izskata izpildes laiks:
2m * Ev1.x
22. Ko vēl var saturēt TD diagrammas ķermenis
TD diagrammas sekcijā Priority var attēlot uzdevuma prioritāti - INTEGER tipa konstanti, piemēram, PRIORITY:2.
Noklusētā prioritāte ir 0, un tā ir visaugstākā prioritāte.
Prioritātes jēga parādās gadījumā, kad izpildītāju resursi ir ierobežoti. Piemēram, ja dotajā biznesa procesā vienai un tai pašai Sekretārei ir jāpilda vairāki uzdevumi, piemēram, Jāreģistrē_ienākušās_vēstules un Jāatbild_uz_telefona_zvaniem, tad otrajam uzdevumam, salīdzinot ar pirmo, droši vien ir jāpiešķir augstāka prioritāte. Vienkāršības labad tiek norunāts, ka jebkurš izpildītājs iesākto uzdevumu vienmēr izpilda līdz galam,kaut arī pa šo laiku ir parādījies uzdevums ar augstāku prioritāti. Citiem vārdiem sakot, prioritāte tiek ņemta vērā brīdī, kad izpildītājam jāsāk jauns uzdevums.
Sekcijā Max instances tiek attēlots maksimālais vienlaicīgi aktivo eksemplāru skaits jebkurai vienai šī uzdevuma sastapei. Šo skaitu, protams, regulē arī pieejamo izpildītāju skaits.
Tālāk seko dažas svarīgas neformālas sekcijas.
Sekcijā Description (tā jau iepriekšējā nodaļā vairākkārt tika pieminēta kā svarīga TD sastāvdaļa) brīva teksta formā tiek dots uzdevuma neformāls apraksts. Šāds apraksts ir obligāts, ja ir šaubas, ka ar uzdevuma nosaukumu vien var būt par maz, lai doto uzdevumu saturīgi saprastu.
Sekcijās Objectives un Constraints brīva teksta formā raksta tās uzdevuma neformālā apraksta sastāvdaļas, kas attiecās uz uzdevuma mērķi un ierobežojumiem.
Sekciju Execution mode var atstāt tukšu vai arī ierakstīt vienu no trim atslēgas vārdiem:
| MANUAL | - ja uzdevumu veic cilvēks, |
| AUTOMATED | - ja uzdevumu veic kāda iekārta (dators, robots un tml.) |
| INTERACTIVE | - ja uzdevumu veic cilvēks kopā ar attiecīgo iekārtu. |
Ir paredzēta vēl viena samērā reti lietojama sekcija - Alternatives. Proti, vispārīgā gadījumā ir atļauts vienu un to pašu uzdevumu detalizēt ar vairāku biznesa procesu palīdzību, kur katrs no šādiem biznesa procesiem apraksta savu dotā uzdevuma izpildes scenāriju. Piemēram, ja uzdevums ir Iznomāt_automašīnu, tad viens no scenārijiem varētu būt gadījumam, kad klients ir zināms, un otrs - gadījumam, kad klients nav zināms. Protams, abus šos scenārijus var apvienot arī vienā biznesa procesā, bet tad tas varētu nebūt pietiekoši pārskatāmi. Tādēļ arī ir paredzētas minētās alternatīvas. Katrai alternatīvai tiek dots savs vārds, un biznesa process ar attiecīgo vārdu parādās modeļa kokā. Sekcija Alternatives kalpo tam, lai katrai alternatīvai norādītu tās varbūtību (to ņem vērā imitācijas laikā).
Līdz ar to visas uzdevuma ķermeņa sastāvdaļas ir aplūkotas.