Abstraktā biznes-modelēšana

Kārlis Podnieks

LU 64. konference

2006.gada 17.februārī

(C) K.Podnieks, 2006

Reti sastopamu situāciju modelēšanas "bēda"

Tiem, kuri nodarbojušies ar modelēšanas rīku (tādu kā GRADE) izstrādi, ir labi zināms, ka 90% no rīka funkcionalitātes tiek radīti tikai reti sastopamu situāciju modelēšanai. Jautājums: ja veidojot rīku, mēs liekam uzsvaru uz šo 90% realizāciju, vai tādā gadījumā mēs nesabojājam tos 10%, kas domāti visbiežāk sastopamo situāciju modelēšanai?

T.i., vai mēs neradām lietotājam sarežģījumus tur, kur reālā dzīvē to nav? Ar terminu „abstraktā biznes-modelēšana” es domāju tieši šos rīka funkcionalitātes 10%, kurus vajadzētu realizēt perfekti, nejaucot kopā vienkāršo ar sarežģīto.

Šī referāta tēma: kā varētu izskatīties tāds nedaudz abstrakts modelēšanas rīks, kas perfekti atbalstītu tikai šos vienkāršos un bieži lietojamos 10%? Un kas no šī skaistuma ir gājis zudumā GRADE un citos pilna apjoma modelēšanas rīkos?

Galamērķis: atrast studentu (vai divus), kurš (-a, -i) uzņemtos izstrādāt šī rīka prototipu kā savu (-s) maģistra vai bakalaura darbu (-s).

Biznes-modeļa struktūra

Jebkurā biznes-modelī tādā vai citādā veidā parādās divas paralēlas un saistītas struktūras:

a) Sistēmas fiziskā struktūra: izpildītāju ("performeru") hierarhija. GRADE to attēlo ORG diagrammas vai CO diagrammas. Fiziskie objekti (Jāņa Gobiņa "aktīvie objekti") te ir cilvēki, datori, datubāzes, org-vienumi utt.

b) Sistēmas funkcionālā struktūra: uzdevumu ("tāsku") hierarhija. GRADE to attēlo BP diagrammu koks:

Uzdevumi savā starpā ir saistīti ar ziņojumiem, ko viens uzdevums sūta citiem, savu darbu beidzot. GRADE to attēlo BP diagrammas:

Bet saistību abu hierarhiju starpā uzdod asociācija „x izpilda y”, kur x pieder fiziskajai struktūrai, bet y – funkcionālajai struktūrai.

Tāda (neprecizējot sīkāk) ir biznes-modelēšanas kopējā aina.

Sarežģījumi

Reālajā modelēšanā parādās problēmas, kas situāciju sarežģī, piemēram:

a) Viens izpildītājs var piederēt vairākām hierarhijām, var būt vairāki izpildītāju tipi (darbinieki, resursi, funkcijas utt.) un vairāku veidu pakļautības asociācijas to starpā (is-part-of, "izmanto darbam", amatu subordinācija utml.).

b) Vienu uzdevumu var izpildīt vairāki izpildītāji, kurus savā starpā saista UN, VAI, vai pat vēl sarežģītāka loģiska izteiksme (GRADE - "performer expression").

c) Vienu uzdevumu var izmantot kā vairāku lielāku uzdevumu sastāvdaļu, tāpēc, lai atbalstītu atkal-izmantošanu ("reusability"), rodas vajadzība pēc jēdzieniem task-type un task-occurrence.

Ignorēsim un vienkāršosim...

Kā pirmo tuvinājumu, es ieteiktu visus šos sarežģījumus ignorēt, un pamēģināt izpētīt, ko tad spēj šāda ne-sarežģūta (t.i. abstrakta) biznes-modelēšana? Par sarežģījumiem domāsim pēc tam (ne šodien).

Tātad, mēģināsim uzskatīt, ka (atļaušos nezīmēt piemērus, paļaujoties klausītāju attīstīto fantāziju):

a) Izpildītāji visi ir viena tipa, tie veido vienu hierarhiju (varbūt, ar vairākām saknēm, kuru koki savā starpā nekrustojas). Izpildītāju vienīgā savstarpējā asociācija ir „x ir daļa no y” (katrs x var būt daļa tikai vienam vai nevienam y).

b) Uzdevumi arī veido vienu hierarhiju (varbūt, ar vairākām saknēm, kuru koki savā starpā nekrustojas). Šo hierarhiju uzdod asociācija „x ir daļa no y” (katrs x var būt daļa tikai vienam vai nevienam y).

c) Zemākā līmeņa uzdevumus (tikai zemākā!) saista asociācijas ir „pēc x seko y” (pēc x var sekot neviens, viens vai vairāki y, un tāpat, viens y var sekot aiz neviena, viena vai vairākiem x).

c) Katru zemākā līmeņa uzdevumu izpilda neviens vai viens (un arī - zemākā līmeņa!) izpildītājs (asociācija „x izpilda y”).

Ja rodas vēlēšanās reģistrēt modelī vairākus viena uzdevuma izpildītājus, tad šo uzdevumu vajag detalizēt tālāk, parādot, kuras uzdevuma daļas katrs izpildītājs izpildīs. Bet, protams, viens izpildītājs var izpildīt nevienu, vienu vai vairākus uzdevumus.

Galvenā ideja

Ko mēs pēc šiem vienkāršojumiem tagad redzam?

Funkcionālā struktūra „nodarbojas” ar zemākā līmeņa uzdevumu apvienošanu arvien lielākos uzdevumos utt. līdz pašai augšai.

!!!Fiziskā struktūra „nodarbojas” ar… to pašu – ar zemākā līmeņa uzdevumu apvienošanu org-vienībās utt. līdz pašai augšai!!! Ļoti būtiska ideja!!!

Abas šīs struktūras tātad ir divas dažādas hierarhijas, kas uzliktas vienai plakanai pamatstruktūrai – zemākā līmeņa (t.i. elementāro) uzdevumu tīklam.

Starp zemākā līmeņa uzdevumiem pastāv tikai viena asociācija „pēc x seko y” (tā ir many-to-many, jo gan pirms, gan pēc uzdevuma var būt neviens, viens vai vairāki citi uzdevumi). Tas ir kaut kas līdzīgs GRADE uzdevumu hierarhijas izklājumam vienā apvienotā BP diagrammā (funkcija Build one-level BP). Pagaidām es nejūtu vajadzību kaut kā ierobežot šo uzdevumu sekošanas tīklu. Vēlāk varbūt, varēsim pieprasīt, piemēram, lai šis tīkls sadalās „sakarīgās” komponentēs, kur katrā ir tikai viens START uzdevums (pirms kura nav citu uzdevumu). Vai arī – ja uzdevumu tīkla kaut kāda daļa tiek apvienota vai nu org-vienībā, vai lielākā uzdevumā, tad šīs vienības/uzdevuma robežu nevajadzētu šķērsot pārāk daudzām „sekošanas bultām”.

Esam nonākuši pie tās struktūras vispārīgas definīcijas, ko es gribētu saukt par abstraktajiem biznes-modeļiem. Pamatā ir elementāru uzdevumu kopa un asociācija „aiz x seko y” (t.i. uzdevumu tīkls). Uz šīs struktūras ir uzliktas divas hierarhijas „x ir daļa-1 no y” un „x ir daļa-2 no y”. Katrs x var būt daļa-1 vai daļa-2 tikai vienam vai nevienam y. Abu hierarhiju apakšējā līmenī ir tikai elementārie uzdevumi.

Meta-modelis

Šādas struktūras meta-modelis (par uzdevumiem un org-vienumiem tagad varam aizmirst):

Bet faktiski, pēc visiem mūsu vienkāršojumiem mums pat vairs nav svarīgi, cik šo hierarhiju virs mūsu elementāro uzdevumu tīkla ir – viena, divas vai vairākas. Tātad esam nonākuši pie vēl vispārīgākas struktūras – plakana elementu tīkla (orientēts grafs) ar vienu vai vairākām apvienojošām hierarhijām virs tā.

Skati jeb diagrammas

Kāda veida diagrammās mēs varētu vēlēties šādu modeli apskatīt?

1. Elementu tīkls

To varētu attēlot kā vienu lielu GRADE BP diagrammu, kurā kastītes attēlotu elementus (elementāros uzdevumus), bet bultiņas attēlotu sekošanas asociāciju. Parasti šāda diagramma būs diezgan liela (vai pat pārāk liela...).

GRADE šādu diagrammu prot ģenerēt no BP diagrammu hierarhijas (funkcija Build one-level BP).

2. Hierarhiju koki

Piemēram, fiziskās struktūras hierarhija (zīmēts ar Exigen Business Modeler):

vai funkciju hierarhija (zīmēts ar Exigen Business Modeler):

Vairākās senākās modelēšanas notācijās šādas hierarhijas bija paredzētas, bet UML tās nav iekļautas. GRADE atļauj zīmēt ORG diagrammas (sk. iepriekš), kas būtībā ir fiziskās struktūras attēls, bet funkcionālo hierarhiju GRADE ļauj attēlot tikai kā t.s. modeļ-koka daļu (kas nav sevišķi veikls risinājums, sk. iepriekš).

3. GRADE BP un CO diagrammu analogi

Dotā uzdevuma BP diagrammā kastītes attēlo šī uzdevuma tiešos apakš-uzdevumus, bet bultiņas savieno tos apakš-uzdevumus, kuru sastāvā ir zemākā līmeņa uzdevumi, ko saista sekošanas asociācija.

„Ārējās bultiņas” – novelkamas uz kastīti vai no kastītes, ja attiecīgajam apakš-uzdevumam sastāvā ir zemākā līmeņa uzdevumi, kas saistīti ar šajā diagrammā neattēlotiem uzdevumiem.

Savukārt, dotās org-vienības CO diagrammā kastītes attēlo šīs vienības tiešās apakš-vienības, bet bultiņas savieno tās apakš-vienības, kuru sastāvā ir zemākā līmeņa uzdevumi, ko saista sekošanas asociācija.

„Ārējās bultiņas” – novelkamas uz kastīti vai no kastītes, ja attiecīgajai apakš-vienībai sastāvā ir zemākā līmeņa uzdevumi, kas saistīti ar šajā diagrammā neattēlotām org-vienībām. Sekojot GRADE paraugam, ar katru bultiņu jābūt saistītai tabulai, kurā attēlotas visas sekošanas asociācijas, kas saista bultiņas galos esošās apakš-vienības.

CO diagrammas (kurās tiek parādīts, ar kādām komunikācijām savā starpā ir saistīti org-struktūras elementi) ir GRADE specifiska īpatnība. Citi modelēšanas rīki neko tādu neatbalsta.

4. Vairāk-līmeņu diagrammas

Ar to domāts elementu tīkls, kuram "uzlikta" viena no hierarhijām. Hierarhisko pakļautību attēlo diagrammas kastīšu iekļautība.

Piemēram, funkciju diagramma (zīmēts ar Exigen Business Modeler):

vai fiziskās struktūras diagramma (zīmēts ar Exigen Business Modeler, nav novilktas savienojošās bultas):

Ģenerēt automātiski...

Labam modelēšanas rīkam visus skatus 1, 2, 3, 4 vajadzētu spēt ģenerēt automātiski, balstoties uz vieniem un tiem pašiem abstraktā biznes-modeļa datiem.

Neviens no zināmajiem modelēšanas rīkiem šādus skatus vienlaicīgi neatbalsta. GRADE gan ir paredzētas vairākas funkcijas, kas no vieniem un tiem pašiem datiem ģenerē vairāku skatus.

Piemēram, ja lietotājs ir uzzīmējis ORG diagrammu un BP diagrammu hierarhiju, tad GRADE funkcija Build system model ļauj uzģenerēt CO diagrammu komplektu, kurā var redzēt, kādu informāciju viens org-elements sūta otram. Bet vairāku skatu vienlaicīgu automātisku uzturēšanu (bez pārģenerācijas) pa īstam nenodrošina arī GRADE.

Modeļu būvēšanas atbalsts - RDF?

Līdz šim mēs aplūkojām tikai diagrammas-skatus, kurās lietotājs redz biznes-modeļa datus. Bet no kurienes lai šie dati rastos?

Mazliet nenopietns risinājums būtu datu imports RDF formātā. Tiešām, mums taču ir tikai 3 klases – elementi, agregāti-1 un agregāti-2 un 2 asociāciju veidi: „x seko aiz y” (x un y ir elementi) un „x ir daļa no y” (x ir jebkas, bet y – agregāts, kura tips sakrīt ar x tipu – ja x arī ir agregāts). Tātad savu biznes-modeli mēs varētu izveidot, apstrādājot plūsmu no šāda veida teikumiem:

Alfa ir elements;
Beta ir elements;
Gamma ir agregāts-1;
Delta ir agregāts-2;
Beta seko aiz Alfa;
Alfa ir daļa no Gamma;
Beta ir daļa no Delta;
Utt.

Būtu dabiski izstrādāt šādiem datiem runas ievadu. Šodien tas jau būtu reāls uzdevums.

Modeļu būvēšanas atbalsts - tās pašas diagrammas

Bet ja nopietni, tad pa īstam atbalstīt biznes-modeļu radīšanu un tālāku attīstību, protams, var tikai ar jau minēto diagrammu palīdzību, padarot tās rediģējamas.

Cilvēkam, kurš jau ir strādājis ar modelēšanas rīkiem, būs viegli iedomāties, kā ar minēto hierarhiju diagrammu palīdzību varētu radīt un pārvaldīt, piemēram, org-vienību vai uzdevumu hierarhijas:

Piemēram, lietotājs paņem vajadzīgo simbolu no simbolu paletes un ievieto to diagrammā, tad atveras dialogs, kurā lietotājs ievada objekta vārdu un citus atribūtus, utt.

Te nebūs grūti realizēt arī hierarhijas pārkārtošanas operācijas, kas kādu objektu pārceļ no viena "mātes" objekta pie cita.

Nav grūti iedomāties arī, kā ar elementu tīkla diagrammas palīdzību varētu šo tīklu radīt un pārvaldīt (sajūtai jābūt tādai kā rediģējot GRADE BP diagrammu). Protams, kad tīkls izvērtīsies pārāk liels, tad tieša tā rediģēšana kļūs apgrūtinoša, un to vajadzēs darīt caur mazākiem skatiem (piemēram, rediģējot viena uzdevuma apakšuzdevumus, kā to dara GRADE).

Detalizācijas un agregācija

Viena no raksturīgām situācijām modelēšanā ir detalizācija – kad kāds (līdz šim "nesadalīts") objekts O tiek pasludināts par sastāvošu no vairākām daļām, piemēram, O1, O2, O3. Atkarībā no O vietas modelī, mums vajadzēs "nokārtot" dažādas ne vienmēr tik vienkāršas lietas.

Piemēram, ja O līdz šim bija savas hierarhijas priekšpēdējā līmenī, pakļaujot sev elementus E1, E2, E3, tad iespējams, ka tagad O1 pakļaus tikai U1, O2 - U2, O3 - U3 (vai kā citādi). Modelēšanas rīkam ir jānodrošina lietotājam šīs pārkārtošanas ērta izpilde.

Līdzīga situācija būs, ja O savā hierarhijā ir augstāk par priekšpēdējo līmeni.

Visinteresantāk būs, ja O pats ir elements, kuram jau ir saites ar citiem elementiem. Tad mums vajadzēs: a) visas O ārējās saites pievest klāt attiecīgajām sastāvdaļām O1, O2, O3; b) iezīmēt O1, O2, O3 savstarpējās saites. Modelēšanas rīkam ir jānodrošina lietotājam šīs pārkārtošanas ērta izpilde (apmēram tā, kā GRADE).

Agregācija ir detalizācijai pretēja operācija - mēs ievedam hierarhijā jaunu objektu, kas kas kā daļas saturēs vairākus citus objektus. Skaidrs, ka te sastāvdaļas nedrīkst hierarhijā atrasties viena virs otras. (GRADE šādas operācijas atbalsta ļoti vāji.)

Hierarhijas objekta O izmešana no vidus ir līdzīga agregācijai - līdzšinējās O sastāvdaļas kļūst par O "mātes" objekta sastāvdaļām.

Eksperimentāla pārbaude

Kā nākošo soli es ieteiktu eksperimentāli pārbaudīt, cik parocīga šāda abstrakta biznes-modēlēšana varētu būt praksē, kā tā iespējas varētu vērtēt potenciālie lietotāji. Šim nolūkam būtu jāprogrammē eksperimentāls rīks, kas realizētu gan minēto dažādo skatu automātisku ģenerāciju no modeļa datiem, gan arī efektīvi atbalstītu modeļu būvēšanu ar diagrammu redaktoru palīdzību.

Uzdevums nav tik "nepaceļams" kā varētu likties. Jo modeļu datu struktūras ir ļoti vienkāršas, un mūsu rīcībā ir ļoti laba darbam gatava grafisko funkciju bibliotēka (LU MII piederošā Graphical Diagramming Engine, kura, starp citu, nodrošina arī Exigen Business Modeler diagrammu zīmēšanu).

Kādreiz jau atgriezīsimies
arī pie "sarežģījumiem"....

Manuprāt, ja šim vienkāršotajam biznes-modelim mēs visus minētos algoritmus būtu detalizēti izstrādājuši un eksperimentāli pārbaudījuši, tad visu līdz šim noignorēto „sarežģījumu” atpakaļ-ievešana nekādas nepārvaramas problēmas radīt nevarētu.

Tikai nekādā gadījumā nevajadzētu "upurēt", t.i. izjaukt minēto vienkāršo pamatstruktūru – elementu tīklu ar vairākām hierarhijām virs tā.

Maģistra vai bakalaura darbs

Abstraktās biznes-modelēšanas eksperimentāla rīka programmēšana, manuprāt, būtu ļoti laba tēma maģistra vai pat bakalaura darbam, vienam vai pat diviem studentiem uzreiz.