XIV SEKCIJA VEIKLOS PROCESŲ IR INFORMACINIŲ POREIKIŲ ANALIZĖ

Transcription

1 XIV SEKCIJA VEIKLOS PROCESŲ IR INFORMACINIŲ POREIKIŲ ANALIZĖ.

2

3 SISTEMŲ FORMALUS SPECIFIKAVIMAS, MODELIAVIMAS IR VALIDAVIMAS Mudis Šalkauskas Mokslininkų rūmų Sistemų teorijos sekcija Žaliųjų ežerų g. 49 Pavadinime tarptautiniais žodžiais pateiktos svarbios informatikos sąvokos reikalauja interpretavimo, nes kiekvienas vartotojas supranta jas pagal savo poreikius ir savo įvaizdžius. Pranešime nagrinėjamos šių sąvokų prasmių aibės ir bandoma parodyti, kad informacinės technologijos turi pateiktį dokumente ar duomenų bazėje naudojamų sąvokų specifikacijas, nurodydamos jų prasmines koordinates ar galimų interpretacijų ribas.. Žodinė informacija Informaciją gauname ir perduodame įvairiais ženklais. Universaliausia ir geriausiai suprantama informacijos perdavimo priemone laikoma kalba. Kai kurie mokslininkai net teigia, kad mes mąstoma tik dėka kalbos, nors galima manyti, jog kalbėti išmokome skaitydami savo piešinius. Kalbėdami mes naudojame žodžius, tačiau žodžių prasmė yra gana neapibrėžta ir todėl sinonimai atspindi skirtingas prasmės pakraipas []. Tiksli kalba reikalauja griežtos žodžių atrankos. Diplomatijos ir teisės praktiką rodo kokia svarbi yra terminų interpretacija. Iš kitos pusės, dar Michailas Saltykovas-Ščedrinas yra pastebėjęs [2], kad visuomenės darnai sutrikus jos kalba darosi padrika, iškreipta ir beprasmiška. Netikslus terminų vartojimas rodo supratimo apie kalbamąjį dalyką neaiškumą. Mūsų jaunoje nepriklausomybę atgavusioje šalyje valdžios vyrai, politikai ir žurnalistai vis dar painioja valstybę su vyriausybe, šalį su tėvyne, o tėvynę su tėviške, pajamas su pelnu, galvojimą su mastymu, pakankamumą su ganėtinumu ir dar daug ką. Kadangi kalbininkai netaiso žodžių prasminių klaidų, tai šios, visur ir visų kartojamos, įsitvirtina ir tampa visuotinai priimta norma. Šie kalbos vartojimo dalykai yra socialiniai ir lingvistiniai, tačiau ir informaciniai, kurie dažnai veikia betarpiškai kalbos panaudojimo sužadintus veiksmus, lemdami jų tinkamumą ar netinkamumą. Šio pranešimo tikslas atkreipti informatikos specialistų dėmesį į žodžių ir terminų daugiaprasmiškumą, kuri ne visada ištaiso kontekstas. Toks terminų daugiaprasmiškumo nepaisymas yra pavojingas, nes gali sukelti nepageidautinus veiksmus arba sudaryti dviprasmiškas situacijas. 2. Tautiniai ir tarptautiniai žodžiai Perimdami pažangesnius, naudingesnius dalykus iš svetimų šalių mes kartu perimame su tuo dalyku susijusius žodžius. Šie žodžiai paplinta kalboje ir tampa tarptautiniais žodžiais. Tarptautiniai žodžiai yra žymiai imlesni įvairioms prasmėms, nes jų nevaržo tautinės kalbos žodžio lizdo apribojimai ir todėl patogūs tiek tiksliam technologijų aprašymui, tiek ir neaiškiai suvoktų įvaizdžių dėstymui. Tačiau, toks tautinės kalbos sąsajomis neapribotas daugiaprasmiškumas, pavojingas, nes leidžia rasti daugybę įvairiausių ir dažnai neįtikėtinų interpretacijų. Techninių disciplinų specialistai stengiasi rasti tautinės kalbos terminus, kurie tiksliau atitiktų svetimųjų kalbų terminų dažniausiai naudojamą prasmę ir taip susiaurintų tarptautinio žodžio daugiaprasmiškumą [3]. Informatiką yra viena iš tų greitai plintančių ir plačiai naudojamų veiklos sričių, kurioje ypač apstų tarptautinių žodžių. Kai jie naudojami savo siaurąją dalykine šios srities prasme, jie yra nekenksmingi ir techniškai tinkami, tačiau kai jie pereina į kitas sritis jų prasmė kinta ir jie įgauna nevaldomo ženklo pavojingą neapibrėžtumą. Lietuvių kalba, skirtingai nuo plačiai ir greitai plintančios analitinės ir paprastos anglų kalbos, iš kurios gauname daugumą naujų tarptautinių žodžių, turi tokias galimybes, kuriomis galime tiksliau išreikšti tam tikrus aspektus, pvz. suvokdami keturių daiktų kiekį kaip vieningą visumą sakome ketvertas, o jeigu jie veikia kartu, - sakome keturiese. Išskirdami paskutinįjį narį vadiname jį ketvirtuoju.daug kur mūsų kalbos sudėtingumas gali būti mums parankus ir naudingas. Tačiau lietuvių kalboje pasitaiko spragų, kurias galima užpildyti tik tarptautiniais žodžiais, pvz. rezultatas, situacija, valentingumas ir pan. arba neįprasta žodžių daryba: dadėti, dapilti, dadaryti, dabaigti. XIV

4 3. Sistemos ir sisteminimas M.Šalkauskas Sistemos sąvoka kito nuo pradinės sandaros, junginio ir tvarkos prasmės iki dabartinio sisteminio požiūrio arba sisteminės nuostatos, kuri teigia kad viskas kas yra yra sistemos. Jas sudaro posistemės, o bet kuri sistema įeina į supersistemą. Taigi, šiandien sistema vadiname ir atskirą gamtos organą, ir mūsų pasaulėžiūroje atskirą sutvarkytą įvaizdį. Apibūdinimas sistemiškas, sistematingas, susistemintas prilygsta paliudijimui, kad tai moksliškas, išsamus, pagrįsta ir patikimas dalykas. Pastangos tvarkyti, sisteminti užima svarbia informacijos apdorojimo dalį ir yra viena iš pagrindinių pasaulio suvokimo priemonių, kuri plačiai naudojama ir jo pertvarkymui, valdymui. Pirmosios pastangos sukurti tvarką didelės įvairovės aibėje, buvo bene leksikos semantinės sistemos paieškos, kad papildytų abecelinius žodynus, kurie operuoja žodžiais, o ne jų prasmėmis. Sisteminiai sąvokų žodynai daugelyje didžiųjų civilizacijų (kinų, indų, graikųromėnų) atsirado mūsų eros pradžioje. Dabar žinomiausi yra klasikinis Rodžeto tesauras, Longmano mokslo žodynas ir lietuviški J.Paulausko parengti žodynai [4-7]. Sekmingiausius sisteminimo pastangų vaisius galima rasti tiksliuose moksluose: Linejaus augalų sistematika, Mendelejevo periodinė cheminių elementų sistema, elementariųjų dalelių sistemą ir kt. Nežiūrint to, kad atsirado technikos šaka sistemotechnika, greta kurios yra ir sistemų analizė, ir sistemų sintezė, o galų gale ir bendroji sistemų teorija, nagrinėjanti bendriausius sistemodaros ir sistemų sąrangos dėsningumus, sistematizacija lieka atskira ir savarankiška disciplina, kuri gali būti panaudota tiek sistemų vidaus sąrangai nagrinėti, tiek ir atskirų dar nesisteminių, bet tam tikrą bendrumą turinčių dalykų tvarkymui ir informaciniam pateikimui [8-0]. Bendriausias sistemos žodinis modelis ją nusako kaip santykinai uždarą ir savarankišką, savitą vidinę tvarką turinčią vieningą atskirybę. Sistemos sąvoka apima ir gamtos objektus ir jų matomus/jaučiamus vaizdus bei teorinius įvaizdžius - modelius. Abstrakčiausias sistemos modelis ir abstrakčiausias modelio įvaizdis yra juodoji dėžė, kuri nagrinėjama stengiantis rasti tik įeičių ir išeičių sąsajas, funkcijines priklausomybes bei vyksmų trukmės ypatumus, nesigilinant į vidinį sandarą ir sąrangą. 4. Formavimas ir formalizavimas Forma, formatas, formavimas, formalizacija, formalizavimas, formalistas, formalumas, formalistas, formulė, formuliaras, formuluotė, formuotė yra būdingi pavojingų tarptautinių žodžių atstovai. Forma mes vadiname ir pavidalą, ir sutvarkymą, ir įtaisą pavidalui suteikti, ir sportininko pajėgumą, ir regimybę. Viso priskaičiuojama daugiau nei dešimt lietuviškų atitikmenų, kurie yra labai skirtingi. Panašiai yra ir su kitais šios šaknies žodžių dariniais. Visi jie turi gan gerus lietuviškus atitikmenis ir, atrodo, galima būtų išsiversti be šių tarptautinių žodžių, kurie gali sukelti daug dviprasmybių. Pvz. Formalus ko nors darymas gali būti suprastas, kaip tvarkingas veiksmas pagal tam tikras taisykles siekiant nustatyto pavidalo arba kaip darbas padarytas nesiskaitant su dalyko esmę, kad tik turėtų tam tikrą pripažintą pavidalą. 5.Specifikavimas Specifikavimas gan naujas tarptautinis naujadaras atsiradęs iš to paties lotiniško žodžio specialis ypatingas, atskiras, kurio seniai priimtų tarptautinių žodžių darinių turime gana daug (žurnalistas ar kitas neatsargus kalbėtojas pasakytų pakankamai daug, nenurodydamas nei kam, nei kodėl pakanka?): specializacija, specialistas, specas (žargonas), specialybė, specifika, specifinis, specifikacija, specialus, spec-dalykai. Specifikavimas, kurio vis dar nėra tarptautinių žodžių žodynuose, randamas internete ir suprantamas kaip įvardinimas, apibūdinimas, išskaičiavimas/išvardinimas. Todėl specifikavimas reikalauja tam tikrų nagrinėjimo, aptikimo ir atpažinimo veiksmų []. 6. Modeliai ir modeliavimas Tarptautinis žodis modelis, kilęs ir iš lotyniško modus matas, polinkis, ir itališko modello, ir prancūziško - modèle, reiškia pavyzdį (gaminio etaloninis gaminys, žmogaus kūno pozuotojas) arba abstraktų įvaizdį, esmės žymėjimo ženklą. Pastaroji prasmė tampa vis daugiau dalykišką ir dabar jau modelis suprantamas kaip sistemos (daiktybės, reiškinio, proceso) žodinis, grafinis ar matematinis aprašymas, arba fizinis darinys, kuris leidžia pavaizduoti ir nagrinėti modeliuojamojo dalyko (objekto) tam tikrus ypatumus. Principe, vienus dalykus galima modeliuoti kitais, labiau ištirtais, patogesniais tyrimams arba lengviau suprantamais. Tuo būdu modeliavimas suvedamas į analogijų ir analogų paieškas. Toks modelis-įrankis yra patogus tuo, kad išreiškia tik tam tikras savybes, atsiribodamas nuo visų kitų. Modelis, kuris išreikštų visus modeliuojamojo dalyko požymius ir savybes būtų tolygus modeliuojamajam dalykui, o tai reikštų jog jis yra toks pat sudėtingas ir nesuprantamas kaip ir modeliuojamasis, t.y. daiktas savyje. Šiandien nėra nė vienos veiklos ar tyrimų šakos, kuri nesinaudotu modeliavimu ir visų specialybių studentai mokomi šio meno [2]. XIV 2

5 Sistemų formalus specifikavimas, modeliavimas ir validavimas 7. Validavimas Termino validavimas dar nėra nė viename lietuvių kalbos žodyne. Naujausiame tarptautinių žodžių žodyne [3] yra validus patikimas (iš lotiniško stiprus!). Anglišką žodį validation žodynai verčia kaip patikra, patvirtinimas, aprobavimas. Tačiau internete jau galima rasti ir validavimą, kur jo prasmė aiškinama kaip įvertinimas, patikrinimas, patvirtinimas, pripažinimas. Panašia prasme internete vartojamas ir terminas verifikavimas. Apibendrinant, galima paskyti, kad abu šie tarptautinių žodžių naujadarai validavimas ir verifikavimas dar neprigijo. Jie dar nėra pripažinti kalbininkų, o savo daugiaprasmiškumu yra pavojingi. Kaip rodo lietuviškų atitikmenų įvairovė, jų prasmės techniškai yra skirtingos ir todėl vietoje daugiaprasmio tarptautinio žodžio naujadaro tikslinga vartoti tinkamus lietuviškus atitikmenis. 8. Ką daryti? Matyt, visais atvejais, bet kuriam tekstiniam dokumentui, reikia įvesti skyrių, kuriame paaiškinama, kokios sąvokos ir kokiomis prasmėmis šiame dokumente bus naudojamos. Taip yra daroma įstatymuose ir standartuose žodžiams-terminams, o moksliniuose straipsniuose įvairiems ženklams bei santrupoms. Būtų labai naudinga, jeigu pradėtume visuotinai naudoti ir sąvokų indeksavimą, kuris nurodytų apie kurią daiktybę kalbama,- daiktą savyje (D) denotatas, daikto vaizdą (V) ar daikto įvaizdį (Į) designatas, pav. Tai skirtingi dalykai ir tas jų skirtingumas, dažnai būna nesusikalbėjimo, nesupratimo ir nesusipratimo priežastimi. D V Į pav. Pasaulio suvokimo modelis: D daiktas savyje, V jo vaizdas, projekcija, Į jo įvaizdis mūsų pasaulėvaizdyje Pavyzdžiui kalbėdami apie Saulę, mes galime svarstyti kur yra ir kaip rasti Saulę D, arba kaip mes matome ir stebime Saulę V, arba kaip astronomai ir astrofizikai aprašo ir nagrinėja Saulę Į. Tai trys skirtingos termino Saulė sąvokos, kurios visos, kaip sąvokos yra mūsų pasaulėvaizdžio dalykai, tačiau, kaip sinonimai jie atstovauja skirtingiems denotato aspektams. Kaip išvada to, kas aukščiau buvo nagrinėta, galima pasakyti, jog šis konferencijos tematikos tarptautiniais žodžiais išsakytas skyrius yra imlus įvairioms prasmėms. Literatūros sąrašas [] V.V. Nalimov. Verojatnostnaja model jazyka. Moskva, Nauka, 974. [2] M. Saltykov-Ščedrin. Pisma tetuške. St. Peterburg, Efron, 88. [3] S. Zajankauskas. Visada pirmiausiai susitarkime, kaip ką vadinsime. Kompiuterininkų dienos 99, 999, II dalis, [4] P.M. Roget. Thesaurus of English Words and Phrases. London [5] A. Godman and E.M.F. Payne. Longman Dictionary of Scientific Usage. Longman Group Ltd., Harlow, 979. [6] J. Paulauskas. Sisteminis lietuvių kalbos žodynas. Vilnius, Mokslas, 967. [7] J. Paulauskas. Sisteminis lietuvių kalbos frazeologijos žodynas. Kaunas, Šviesa, 995. [8] B.W. Leong-Hong and B.K. Plagman. Data Dictionary/Directory Systems. Wiley-Interscience Publ., New Yourk, 982. [9] Ju. Ja. Liubarskij. Intelektualnyje informacionyje sistemy. Moskva, Nauka, 990. [0].L.V. Aleksandrov, N.N. Karpova. Rabočaja knyga po sistematizacii informacii. Moskva, Poisk, 993. [] R. Butleris, J.Jasinevičiutė. Vartotojo poreikių specifikavimo schema. Kompiuterininkų dienos 99, 999, II dalis, [2] R. Makuška, S. Budrinė. Cheminės technologijos procesų modeliavimas. Vilnius, VU leidykla, [3] A. Mackevičienė. Tarptautinių žodžių žodynas. Vilnius, UAB Gimtinė, 999 XIV 3

6 Formal specification, modelling and validation of systems M.Šalkauskas Title wordage needs some explanation and interpretation. Each user do this in his own way according it s needs and understanding.in the presentation author analyses and try to determine fields of meaning of titel words, which are essential terms of informatics. Author suggests that specification of meanings is essential in all information technologies and data presentation. XIV 4

7 INFORMACINIŲ VALDYMO SISTEMŲ INTELEKTUALIZAVIMO METODAI Dalė Dzemydienė Matematikos ir informatikos institutas, Programų sistemų inžinerijos skyrius Akademijos 4, 202 Vilniu, Straipsnyje nagrinėjami sprendimų paramos sistemų intelektualizavimo klausimai. Skirtingose taikomosiose srityse sprendžiamos problemos reikalauja skirtingų strategijų ir samprotavimo metodų užtikrinimo kompiuterinėje sistemoje. Šių problemų sprendimo strategijos ir samprotavimo metodų charakteristikos tampa dalimi atvaizduojamų modelių skaitmeninėje erdvėje. Nustatant sprendimų aplinkos darbinę infrastruktūrą ir formuluojant reikalavimus informacinės sistemos architektūrai, analizuojami keliamų problemų tipologijos, taksonomijos formavimo klausimai. Tuo pačiu sudaromi valdymo problemų ontologiniai modeliai. Sprendžiant šiuos mokslinio tyrimo klausimus, įvertinami valdymo lygmenys, kuriems bus orientuojamos sprendimų paramos sistemos ir analizuojami informacinio bei intelektualaus aprūpinimo poreikiai.. Įvadas Keliami mokslinio tiriamojo darbo tikslai - įvertinti skirtumus tarp organizacijos valdymo lygmenų ir aprašyti bendrąsias problemų struktūrizavimo galimybes, bei įvardinti technologinio sprendimų paramos sistemų aprūpinimo reikalavimus. Skirtingų dalykinių sričių problemos paprastai reikalauja skirtingų strategijų ir samprotavimo metodų užtikrinimo sistemoje. Šių problemų sprendimo strategijos ir samprotavimo metodų charakteristikos tampa dalimi atvaizduojamų modelių [5]. Žmogaus žinojimo faktoriai, kurie padeda atlikti vykdomos veiklos įvertinimą ir kontrolę bei priimti sprendimus apima duomenis, informaciją iš daugelio skirtingų veiklos sričių. Šiame procese svarbu nustatyti kokie žinojimo aspektai ir kokiu būdu įtraukiami į samprotavimo metodus ir problemos sprendimo strategijas [3], [6] bei integruotai su duomenų valdymo technologijomis realizuoti šiuos procesus kompiuterinėse sistemose. Problemos sprendimo žinios priskiriamos kontrolei (įvertinimui, ekspertizei) apima: fundamentines žinias, kurios aprašo probleminę sritį; problemos sprendimo strategijos valdymo lygio modelius (pvz. kontrolės, rizikos prevencijos valdymo modelius); užduočių ir uždavinių struktūras; samprotavimo modelius, apimančius aibę samprotavimo metodų ir samprotavimų struktūrą (kurie aprašo užduočių eigą bei jų sprendimo metodus); Sprendimų priėmimo sistemoje, kuri įgalintų valdyti procesus ir atlikti kontrolę, išskiriami keturi žinių vaizdavimo lygiai, kurie jungia pagrindines informacinės infrastruktūros formavimo komponentes. Strateginiame lygmenyje aprašomi planai, nustatomos taisyklės, įvertinama teisinė reglamentavimo sistema. Šių komponentų pagrindu nustatoma valdomų procesų struktūra, turinti tiesioginės įtakos užduočių lygyje apibrėžtiems tikslams ir vykdomoms užduotims. Norint apjungti objektiškai orientuotą požiūrį į probleminę sritį ir veiklai orientuotų IS metodų galimybes, įvedami kai kurie patikslinimai ir papildymai koncepcinės schemos projektavimo dedamosioms. Be statinius aspektus aprašančios dedamosios, išreiškiančios informacijos struktūrines savybes įvedami: objektų gyvavimo ciklų; objektų ryšių; objektų bendravimo aprašymai, scenarijų modeliai ir pan.. Integruojant šių dedamųjų analizę, kaip objektų veiklos situacijų tyrimą, specifikuojamas objekto veiklos įvertinimo ir funkcionavimo analizės modelis sprendimo priėmimo sistemoje. Šiame procese pasitelkiamos šiuolaikinės duomenų saugyklų organizavimo technologijos ir duomenų išgavimo metodai. Be to nagrinėjamos duomenų, agregavimo, įtakos ir variacijų sritys (edvės), kurių analizės rezultatai formuoja sprendimų pagrindimą. Darbas atliktas Matematikos ir informatikos institute, vykdant planinę mokslinių tyrimų temą Ontologijomis grindžiamų komponentinių programų, informacinių ir verslo sistemų inžinerijos problemos. XIV 5

8 2. Sprendimų priėmimo aplinkos įvertinimas D.Dzemydienė Formuluojant reikalavimus sprendimų priėmimo sistemų architektūrai pirmiausiai analizuojama keliamų problemų tipologija įmonėje, organizacijoje, t.y. nustatomi problemų tipai, kuriems spręsti bus orientuojamos kompiuterinės sprendimų paramos sistemos. Tuo pačiu nustatoma valdymo problemų taksonomija, t.y. įvertinami valdymo lygmenys, kuriems bus orientuojamos sprendimų priėmimo sistemos. Nustatant reikalavimus technologiniam tokių problemų sprendimo aprūpinimui, įvertinamos kiekvieno iš lygmenų problemų struktūrizavimo galimybės, t.y. nustatomos problemų struktūrizavimo galimybės ir ribos atitinkamuose valdymo lygmenyse. Lygmenys charakterizuojami orientuojantis į Anthony ir Simon o klasikinę taksonomiją: operacijų valdymas, taktinis/vadovavimo valdymas ir strateginis planavimas bei valdymas, [Anthony, Simon, Blozneshek ir kt.]. Išskiriami problemų sprendimo uždaviniai šiuose lygmenyse. Įvertinus įmonėje, organizacijoje sprendžiamų problemų ir vykdomų sprendimų tipologija ir taksonomiją, konstruojamas sprendimų priėmimo sistemos darbo aplinkos karkasas (framework), įvertinantis valdymo sprendimų ir technologinių palaikymų poreikius ( lentelė). lentelė. Sprendimų priėmimo sistemų darbo aplinka. Operacinis valdymas Valdymo tipai Vadovavimo valdymas Strateginis planavimas Technologijų palaikymo poreikiai SPRENDIMŲ TIPAI Struktūrizuoti sprendimai Apskaičiavimai, sutvakyti įėjimai, operatyvus užduočių valdymas Biudžeto analizė, trumpalaikiai perspektyviniai planavimai, personalo ataskaitos, atlikimas - ar -pirkimas Finansų valdymas (investicijos), saugyklų dislokacija, sistemų paskirstymas Valdymo informacinės sistemos, operacijų tyrimo modeliai, tranzakcijų apdorojimas Dalinai struktūrizuoti sprendimai Produkcijos planavimas ir tvarkymas, inventoriaus kontrolė Kreditų įvertinimas, biudžeto parengimas, projektų valdymas, gamybos planavimas, atlyginimų sistemos projektavimas Naujų įmonių statyba, susijungimas, stambinimas, technologijų įgijimas, naujos produkcijos planavimas, kompensacijų planavimas, kokybiškas garantijų ir draudimo planavimas Sprendimų paramos sistemos, žinių valdymo sistemos Nestruktūrizuoti sprendimai Išrinkti padengimo išlaidas, pirkti programinę įrangą, patvirtinti paskolas Derybų vedimas, naujų narių priėmimas, technikos planavimas ir įsigijimas, lobizmas Naujų tyrimų ir mokslo sričių pasirinkimas planavimas ir vystymas, socialinių įsipareigojimų planavimas Intelektualizuotos SPS, ekspertinės sistemos (ES), ŽVS Technologijų palaikymo poreikiai Informacinės valdymo sistemos, vadybos mokslas Vadybos mokslas, SPS, ES, Vykdomosios IS, Grupinio darbo palaikymo sistemos, SVS Vykdomosios IS, ES, neuroniniai tinklai, ŽVS Struktūrizuotos problemos, kurios gali būti įvardijamos kaip programuojamos apima struktūrizuojamus, tipiškai nusistovėjusius procesus, kurie tampa rutininiais, atliekamais dažnai pagal nusistovėjusį algoritmą. Šios problemos sprendžiamos vykdant veiksmus, atliekamus jau pagal tvirtai nusistovėjusias taisykles, tapusęs ar tampančias standartais, kitaip sakant, struktūrizuotų problemų sprendimui egzistuoja standartizuoti metodai. Nestuktūrizuoti procesai yra pakankamai migloti (fuzzy), šių procesų problemoms spręsti nėra aiškiai išskirti sprendimo metodai. Aiškiai apibrėžiamos problemos su kuriomis susidūriama pakankamai dažnai, turi aukščiausią stuktūrizavimo lygį. Tokias problemas galima apibendrinti bei analizuoti kaip prototipines. Tokių problemų sprendimui yra aprašyti metodai ir išvystomos kiekybinių skaičiavimų formulės, metodai bei kokybinių įvertinimų modeliai. Struktūrizuoti ir kai kurie dalinai stuktūrizuoti sprendimai, ypač operacijų ir taktinio valdymo lygmenyse buvo vystomi ir palaikomi kompiuterizuotais metodais, jau pradedant praeito šimtmečio šešiasdešimtuosius metus. Tokie XIV 6

9 Informacinių valdymo sistemų intelektualizavimo metodai sprendimai vystomi daugelį funkcinių sričių, ypač finansinių ir gamybinių operacijų valdyme. Vystomi imitacinio modeliavimo, netiesinio programavimo, optimizavimo metodai. 3. Sprendimo priėmimo ir modeliavimo proceso etapai Formuluojant reikalavimus sprendimų priėmimo sistemai, analizuojamas sprendimų palaikymo procesas, kuriame nusakomi pagrindiniai šio proceso vykdymo etapai ir reikalavimais, apibrėžiami atliekami veikmai ir jų tarpusavio ryšiai, įvertinant kiekvieno šio proceso etapų atlikimo rezultatus ( pav.). Realybė Supaprastinimas Prielaidos Intelektualus etapas Organizaciniai tikslai Paieškos ir peržiūros procedūros Duomenų surinkimas Problemos identifikavimas Problemos teisinis reglamentavimas ir priskirimas Problemos klasifikavimas Problemos konstatavimas Modelių validavimas Problemos konstatavimas Projektavimo etapas Formuluojami modeliai Nustatomi pasirinkimo kriterijai Ieškomos ir formuojamos alternatyvos Numatomi ir įvertinami galimų alternatyvų rezultatai pasisekimas Pateikiamų sprendinių verifikavimas, testavimas, vertinimas Diegimas Alternatyvos Pasirinkimo etapas Sprendimai modeliuojant Sensityvi analizė Parinkimas geriausios (geros) alternatyvos Įdiegimų planas Sprendinys/planas nepasisekimas pav. Reikalavimai sprendimų atlikimo /modeliavimo procesams Intelekto etape (angl. intelligence) apibrėžiamos problemos ir nustomos sąlygos, kurioms spręsti bus taikomi sprendimų priėmimo metodai. Projektavimo etape (angl. design) atrandami, išvystomi ir analizuojami galimi skirtingų sprendimų variantai ir įvertinamos su jais susijusių veiksmų modeliavimo/vykdymo eigos. Pasirinkimo etape (angl. choise) atrenkami veiksmų eigų vertinimo kriterijai, nustatomi vertinimo kriterijų matai (įvertinant atitikimą tikslo siekimo funkcijai) ir kiti vertinimo būdai, kurie leistų įvertinti galimas veiksmų eigas ir vienos ar kitos alternatyvos pasirinkimą. XIV 7

10 D.Dzemydienė Diegimo etape (angl. implementation) vykdoma vieną iš pasirenkamų alternatyvų ir ją vertinant nustomas įdiegimų planas. Pasirinkimo etapo metu atliekamas geriausio plano (objekto) išrinkimas iš galimų alternatyvų aibės, aprašomos sprendimo priėmimo proceso fazės. Į ši procesą įtraukiami modeliavimo rezultatų vertinimo, optimizavimo metodai ir daugelis žinių bazių elementų. Tad visi šie komponentai ir pagrindinių sprendimų priėmimo procese dalyvaujančių komponenčių derinimas integruojamas bedraja SPS architektūra. 3. Duomenų ir informacijos analizės dimensijos bei technologijos taikomos sprendimų pagrindimui Organizacijos veiklos analizei ir tyrimui yra svarbios sistemos, kurios leidžia atlikti daugiamatę veiklos analizę, planavimą ir modeliavimą. Kartu su poreikiais išsaugoti didelius duomenų kiekius ir juos tinkamai organizuoti, plėtojami duomenų saugyklų (angl. data warehousing) kūrimo metodai ir technologijos, įtakojančios informacijos apdorojimo bei analizės procesus. Duomenų saugyklų kūrimas ir jų analizė, išsaugant ir manipuliuojant dideliais istorinės informacijos ir duomenų kiekiais, dažniausiai grindžiami daugiasluoksnio sumuštinio paradigma, kuri nusako daugelio lygių duomenų saugyklų projektavimo metodiką. Šios metodikos pagrindu integruotai atliekami duomenų saugyklų organizavimo duomenų analizės bei duomenų išgavimo (angl. data mining) darbai. Šiuolaikinių duomenų saugyklų tikslas - apjungti didelius istorinės informacijos kiekius iš daugelio šaltinių ir naudoti šią informaciją sprendimų pagrindimui. Bendras tokio tipo sprendimų pagrindimo lygmuo nusako tam tikslui integruojamas komponentes, kurių sąveikos schema pateikiama 2 pav. Sprendimų palaikymo įrankiai Duomenys Duomenys 2. Duomenys n Duomenų susijungimo sistema Sprendimų pagrindimo repozitorijus Duomenų kokybės sistema 2 pav. Sprendimų pagrindimo komponečių sąveikos schema Sprendimų pagrindimo repozitorijus gali turėti skirtingas komponentes. Užduotys atleikamos dideliame korporuojamų duomenų repozitorijuje dažniausiai skiriasi. Repozitorijuje gali būti atliekamos užklausų ir ataskaitų formavimo, daugiamatės (daugiadimencinės) analizės, duomenų gavybos ir panašios užduotys. Dažniausiai skirtingos užduotys atliekamos, skirtingų vartotojų grupių, komponuojamos į skirtingus kompiuterinius procesus. Nagrinėjant sprendimų priėmimo procesus, turi būti nagrinėjamos duomenų, agregavimo, įtakos ir variacijų sritys (edvės), kurių analizės rezultatai formuoja sprendimų pagrindimą (3 pav.). Duomenų erdvė Agregavimo erdvė Sprendimų pagrindimas Įtakos erdvė Variacijų erdvė 3 pav. Pagrindinės erdvės formuojančios sprendimų pagrindimą XIV 8

11 Informacinių valdymo sistemų intelektualizavimo metodai Norint įsivaizduoti šių sričių įtaką sprendimų atlikimo pagrindimui, galime pateikti nesudėtingus pavyzdžius iliustruojančius galimų klausimų šioms sritims formavimą. Duomenų erdvė įgalina užklausų formavimą apie faktinius nagrinėjamo objekto duomenis (pvz., Kokia produkto Nr. 25 kaina?) Agregavimo erdvė leidžia atsakyti į klausimus pagal apibendrinančius parametrus, kaip pvz.: Koks produkto pardavimas iš parduotuvės Nr. 8 per mėnesį? Dažniausiai agregavimo erdvė taiko OLAP (On-Line Analytical Processing), ROLAP (Relational On-Line Analytical Processing), MOLAP (Multiple On-Line Analytical Processing, HOLAP (Hybrid On-Line Analytical Processing) programinės įrangos technologijas. Šios technologijos leidžia greitai ir įvairiais įmanomais pjūviais peržiūrėti ir analizuoti didelius informacijos kiekius, atlikti prognozavimą, naudojant tam pritaikytą duomenų modelį, kuris atspindi realų daugiamatį organizacijos veiklos vaizdą. Daugiamačiam duomenų modelio atvaizdavimui, OLAP sistemose naudojami daugiamačiai duomenų kūbai. Daugiamatės sistemos koordinačių ašimis yra pagrindiniai analizuojamo proceso atributai. Nustatant reikalavimus realizuojamai daugiamatei duomenų saugyklai (4 pav.), nagrinėjamos pagrindinių dimencijų aibės. Šios dimensijos dažniausiai nurodo reliacinės duomenų bazės laukų pavadinimus. Sprendimus palaikantys objektai Analizės serveris Sukinių analizės (PivotTable) paslauga Daugiamačiai sprendimų priėmimo mechanizmai Meta duomenų saugykla Daugiamačiai kubai Duomenų šaltiniai 4 pav. Daugiamatės duomenų saugyklos analizės komponentai Nagrinėjami matai, jų skaičius, surandamos matų agreguojamosios dedamosios atitinkančios dimencijų hierarchijoms (pvz., nustatomi visų pardavimų vidurkiai pagal miestus, rajonus) ir šie duomenys išsaugomi velesniems panaudojimams. Agreguojamoji erdvė įjungia pasirinktų matavimų apibendrinamuosius skaičiavimus atliekamus duomenų erdvėje. Šie skaičiavimai yra saugomi ir turi būti nagrinėjami dimencijų ir koordinačių terminais. Intuityviai kiekviena ašis šioje erdvėje atitinka lauko/stulpelio matavimą reliacinėje bazėje ir agregavimas yra vykdomas projekcijomis į daugiadimencines laiko eilučių erdves. Analizės serverio funkcijos yra daugiamačių kubų kūrimas ir valdymas, kubo duomenų saugojimas daugiamatėse struktūrose arba reliacinėse DB. Sukinių analizės paslauga (PivotTable) naudojama kaip sąsaja tarp kliento programų ir analizės paslaugų. Paslaugos gali būti teikiamos įvairiose programinėse aplinkose. Kliento programos gali naudoti Microsoft ActiveX duomenų objektus (pvz., ADO 2.0) arba OLE DB for OLAP 2.5 interfeisus, kurių pagalba galima jungtis prie serverio ir išgauti daugiamačio kubo duomenis, bei kurti daugiamates struktūras. Pastebėjus kai kuriuos didelių duomenų saugyklų organizavimo trukūmus, išgaunant tikslesnius duomenis ir atliekant sudėtingus sprendimus, pradėtos kurti šablonų saugyklos (patterns warehouses) ir jų analizės metodai. XIV 9

12 D.Dzemydienė Įtakos sritis formuoja galimybes nagrinėti įvairių procesų, reiškinių bei priemonių įtakos sferų ir pasekmių analizę, kurios pagrindu formuojami tokio pobūdžio klausimai kaip, pvz.: Kokie faktoriai įtakoja pardavimą Vilniuje? Variacijų sritis analizuoja galimų pokyčių įtaką siekiamo tikslo pasiekiamumui ir duoda galimybę atsakyti į tam tikro tipo analizės klausimus, pvz.: Kaip pardavimo patobulinimai keitėsi per paskutinius tris mėnesius? Analizės procese duomenų sritis dažniausiai praturtinama papildoma semantika įvedant informaciją apie hierarchijas ir periodinę veiklą. Kad darbinė SPS aplinka galėtų būti panaudota aprašyti ir analizuoti egzistuojantiems metodams, ji turi tenkinti reikalavimus ir būti pakankama išreikšti: Keletui atvaizdavimo formalizmų, Problemos sprendimo valdymo metodams, Daugelio paradigmų samprotavimui (reasoning), Daugelio paradigmų mokymui, Integravimo aspektams ir pan. 4. Išvados Formuluojant reikalavimus informacinių valdymo sistemų architektūrai turėtų būti išanalizuoti valdymo lygmenys, įvertinama problemų tipologija, taksonomija. Informacinė sistema projektuojama atsižvelgiant į ontologines nuostatas. Skirtingų dalykinių sričių problemos paprastai reikalauja skirtingų strategijų ir samprotavimo metodų užtikrinimo sistemoje. Žmogaus žinojimo faktoriai, kurie padeda atlikti vykdomos veiklos įvertinimą ir kontrolę bei priimti sprendimus apima duomenis, informaciją iš daugelio skirtingų veiklos sričių. Šiame procese svarbu nustatyti kokie žinojimo aspektai ir kokiu būdu įtraukiami į samprotavimo metodus ir problemos sprendimo strategijas bei integruotai su duomenų valdymo technologijomis realizuoti šiuos procesus kompiuterinėse sistemose. Literatūros sąrašas [] Aamodt A. A Knowledge-Intensive, Integrated Approach to Problem Solving and Sustained Learning. Knowledge Engineering and Image Processing Group. University of Trondheim. 99, pp [2] Čaplinskas A. General Introduction to Artificial Intelligence. In K.Wang, H.Pranevicius (Eds.) Lecturer Notes of the Nordic-Baltic Summer School on Applications of AI to Production Engineering. KTU Press. Technologija. Kaunas. 997, p.-38. [3] Chaturvedi A.R. Acquiring Implicit Knowledge in a Complex Domain. Expert Systems with Applications Vol. 6. No., pp [4] Dzemydienė D. An Approach to Modelling Expertise in the Environment Pollution Evaluation System. In (Eds.) Janis Barzdins, Albertas Caplinskas Databases and Information Systems. Kluwer Academic Publishers. Dordrecht/ Boston/ London. 200, pp [5] Dzemydienė D. Informacinių sistemų projektavimo alternatyvų formavimas sprendimų priėmimo sistemoje. Konf. Informacinės technologijos pranešimų medžiaga. Kaunas. Technologija. 2002, p XIV 0

13 LIETUVOS IR ES ŠALIŲ INFORMACINIŲ TECHNOLOGIJŲ PLĖTROS RODIKLIŲ DAUGIAMATĖ ANALIZĖ IR PROGNOZĖ Dalė Dzemydienė, Vitalija Rudzkienė Lietuvos teisės universitetas, Teisinės informatikos katedra Matematikos ir informatikos institutas Straipsnyje nagrinėjami Europos Sąjungos (ES) šalių ir Lietuvos informacinių technologijų vystymosi rodikliai ir jų įtaka nuotolinio darbo plėtros tendencijoms. Įvertinamos ES šalių ir šalių kandidačių personalinių kompiuterių ir interneto vartotojų, korinio (mobiliojo) telefonų skaičiaus priklausomybės ir jų kitimo tendencijų poveikis nuotolinio darbo vystymuisi. Įvertinami informacinių ir komunikacinių technologijų išsivystymo rodiklių priklausomybė nuo socialinių ekonominių rodiklių ir jų skirtumai Europos Sąjungos šalyse ir šalyse kandidatese.. Įvadas Nuotolinio darbo privalumai (lankstumas, mobilumas, stresų mažinimas ir kt.) grindžiami informacinių ir komunikacinių technologijų šiuolaikinėmis galimybėmis pastebimi įvairiuose darbo organizavimo srityse. Nauji darbo organizavimo metodai padeda spręsti neefektyvaus darbo problemas: mažina nedarbą, padeda globalizuoti darbo atlikimo procesą. Informacinių technologijų priemonėmis vystomi elektroninio bendradarbiavimo, komunikavimo, administravimo būdai ne tik naudoja informacines technologijas, bet ir keičia darbo pobūdį. Biurokratinėje organizacijoje dirbančių žmonių griežta priežiūros kontrolė ir hierarchinė valdymo struktūra stiprina įtampą, stabdo iniciatyvumą. Nelankstumas tokiose organizacijose tampa neefektyvia vyraujančia charakteristika, stabdančia naujų darbo metodų efektyvesnį diegimą. Viešųjų institucijų restruktūrizavimas įtakojamas veiksnių, kurie formuoja naujus darbo metodus, pasitelkiant informacinių technologijų taikymo galimybes. Viešojo administravimo darbo pasidalijimo sistemų alternatyva yra grindžiama naujų informacinių technologijų galimybėmis, kurios įgalina naujas darbo organizavimo formas, leidžia darbuotojams prisiimti naujus vaidmenis ir individualiai prisidėti prie efektyviau pasiekiamų galutinių rezultatų. Europos Sąjunga, nusakydama ekonomikos vystymo tikslus ir siekdama tapti dinamiškiausia ir konkurencingiausia visuomene, remdamasi nuotolinio darbo praktika pasaulyje ir JAV, įvardija strategines kryptis nuotolinio darbo plėtrai. Elektroninės Europos veiksmų planuose iki 2002 m. ir iki 2005 m. numatytos priemonės, teisinės sistemos pagrindai, egzistuojančių finansinės paramos programų perorientavimo strateginės kryptys, bendros šių priemonių įgyvendinimo gairės nuotolinio darbo technologijų įgyvendinimui. Užimtumo ir socialinių reikalų generalinis direktoratas įsteigė Europos pokyčių monitoringo centrą - EMCC 2, kuris vertina Europos šalių pastangas gyvenimo ir darbo kokybei pagerinti 3. Europos Sąjungos socialinių partnerių nutarimas dėl teledarbo reguliavimo [4] apibrėžė pagrindines nuotolinio darbo organizavimo formas, nusakė būdus kaip darbuotojai (tiek privačiame, tiek viešajame sektoriuje) gali modernizuoti darbo organizavimą bei pagerinti savo darbo ir asmeninio gyvenimo balansą ir pasiekti didesnės autonomijos darbe. Nuotolinio darbo vystymo priemonėmis siekiama ne tik padidinti darbo vietų skaičių, bet taip pat sukurti ir geresnės kokybės darbo vietas, t. y. tinkamai aprūpintą darbo aplinką, darbą suderintą su asmeniniu gyvenimu, užtikrinti sveikatos apsaugos ir saugumo priemones darbo vietose, darbo įvairovę. Žinių visuomenė darbo kokybei atveria naujas perspektyvas: jau esamose darbo vietose kuriamos sąlygos pokyčiams naujiems lankstiems darbo metodams ir būdams darbui organizuoti. Tyrimuose naudojami statistinės analizės metodai, leidžiantys atlikti daugelio parametrų tarpusavio įtakos įvertinimą laike pagal pagrindinius kriterijus, nustatant pagrindinius faktorius ir jų įtaką nuotolinio darbo vystymui ir nedarbo mažinimui Europos Sąjungoje ir šalyse kandidatėse. 2 3 EMCC European Monitoring Centre on Change. Knowledge Society. e-working// XIV

14 2. Darbo kaitos indikatoriai susiję su nuotoloniu darbu D. Dzemydienė, V.Rudzkienė Europos užimtumo strategija 4 ypatingą dėmesį skiria darbo perspektyvai žinių visuomenėje bei informacinių ir komunikacinių technologijų potencialui plėtoti. Ji numato šalių narių užimtumo politika bei veiksmų planus, kad būtų sudarytos sąlygos pilnam gyventojų užimtumui žinių visuomenėje, kaip pvz. elektroninis mokymasis visiems, darbuotojų skaitmeninis raštingumas, viešųjų paslaugų modernizacija. Šiuolaikinių informacinių ir komunikacinių technologijų vystymasis kuria palankias sąlygas interneto ir kitų mobiliojo ryšio priemonių naudojimui. Atsiranda visa eilė paslaugų rūšių teikiamų per internetą: elektroninė komercija, diskusijų svetainės, mokesčių mokėjimas, virtualios įstaigos ir pan., dirbančios tiesioginio ryšio režime []. Informacinių ir komunikacinių technologijų efektyvus taikymas padeda atsirasti naujoms darbo organizavimo formoms. Šie veiksniai pozityviai įtakoja darbo kokybę: didina atsakomybę, darbo produktyvumą, padeda geriau valdyti informacijos srautus. Visa tai leidžia mėgautis darbu ir padaryti jį efektyvesniu bei pertvarkyti darbą jų vidinėje struktūroje ir už jos ribų. Tokie pokyčiai vyksta daugelyje taikomųjų sričių: medicininės diagnostikos, automatinio projektavimo laboratorijose, nuotolinio valdymo centruose. Pagal Eurobarometro 5 naujų darbo metodų tyrimus visose šalyse narėse pastebimas nuotolinio darbo augimas. Elektroninio (nuotolinio) darbo sąvoka atsirado kartu su EMERGENCE projektu 6, kur sakoma, kad bet koks darbas vykdomas ne įkurtoje vietoje, bet valdomas iš įkūrimo vietos ir naudoja informacines technologijas (IT) bei telekomunikacijas darbui gauti ar pristatyti, vadinamas elektroninių (nuotoliniu) darbu. Daugiausia nuotolinio darbo metodai diegiami programinės įrangos, kūrybinio darbo, dizaino, redagavimo srityse. Nuotolinis darbas gali būti suprantamas kaip darbo organizavimo ir/ar vykdymo metodas, kur žymi dalis darbuotojų darbo laiko praleidžia ne biuro patalpose. Darbas yra atliekamas naudojant IK technologijas duomenų perdavimui, ypač Internetą. Tai apima nuotolinį darbą namuose, pakaitinį darbą biure ir namuose, mobilų nuotolinį darbą ir darbą vietiniuose nuotolinio darbo centruose. 3. Interneto vartotojų skaičiaus ir socialinių rodiklių tarpusavio priklausomybės tyrimai Norint atlikti daugelio parametrų tarpusavio įtakos įvertinimą laike, nustatant pagrindinius faktorius ir jų įtaką nuotolinio darbo vystymui ir nedarbo mažinimui Europos Sąjungoje ir šalyse kandidatėse, pirmiausia reikia ištirti kurie iš ES šalių nagrinėjamų rodiklių turi didžiausią įtaką Interneto vartotojų skaičiui [2,3]. Tam tikslui apskaičiuojamas šių rodiklių porinio (Pirsono) koreliacijos koeficiento dydis tarp Interneto vartotojų skaičiaus 00 gyventojų ES šalyse narėse bei šalyse kandidatėse ir: bendrojo vidaus produkto (BVP) vienam gyventojui pagal perkamosios galios paritetą (PPS), kai vidutinis ES šalių BVP=00; procentinės BVP dalies, skiriamos IT; PK skaičiaus, tenkančio 00-ui gyventojų; korinio (mobiliojo) ryšio abonentų skaičiaus 00-ui gyventojų; nedarbo lygio, procentais. Apskaičiavus šio koeficiento reikšmes 998, 999 ir 2000 metais tarp ES šalių Interneto vartotojų skaičiaus ir kitų rodiklių, gauname, kad visais nagrinėjamais metais šio rodiklio reikšmė priklausė tik nuo personalinių kompiuterių (PK) skaičiaus, tenkančio 00-ui gyventojų, t.y.: corr m (ivs m ; pks m )= 0,72, m=998 (žr. pav); corr m (ivs m ; pks m )= 0,8, m=999 (žr. 2 pav); corr m (ivs m ; pks m )= 0,85, m=2000 (žr. 3 pav). Analizuojant svarbu žinoti ne tik absoliutų PK skaičių, bet ir šio skaičiaus kitimo tendencijas, t.y. kaip sparčiai šie procesai vystosi ir kokios jų tolesnės vystymosi perspektyvos. Šiam tikslui reikia apskaičiuoti rodiklio kitimo indeksą arba, kitiap tariant, PK skaičiaus, tenkančio 00-ui gyventojų didėjimo greitį. Lygindami šiuos duomenis matome, kad priklausomybė tarp PK skaičiaus ir Interneto vartotojų skaičiaus kasmet stiprėjo: jei 998 metais apytikriai pusė asmenų, turinčių PK, buvo prisijungę prie Interneto (determinacijos koeficientas R 2 =0,52), tai 999 metais jau virš 60 procentų asmenų, turinčių PK, buvo prisijungę prie Interneto (determinacijos koeficientas R 2 =0,66), o 2000 metais jau virš 70 procentų (determinacijos koeficientas R 2 =0,72) European Employment Strategy// Johnston P. The New Policy Agenda for e-work in Europe. Helsinki, 200// EMERGENCE. The project// XIV 2

15 Lietuvos ir Europos Sąjungos šalių informacinių technologijų plėtros daugiamatės Tokią pat išvadą galime padaryti ir iš tiesinės regresijos lygčių. Pavyzdžiui, 2000 metais kiekvienas papildomas kompiuteris Interneto vartotojų skaičių padidindavo 0,92. Interneto vartotojų skaičius y = 0.547x R 2 = PK skaičius, 998 m. pav. ES šalių PK skaičiaus ir Interneto vartotojų skaičiaus tarpusavio priklausomybė ir jos aproksimacija tiesine regresija (998 metai) Interneto vartotojų skaičius y = x R 2 = PK skaičius, 999 m. 2 pav. ES šalių PK skaičiaus ir Interneto vartotojų skaičiaus tarpusavio priklausomybė ir jos aproksimacija tiesine regresija (999 metai) Interneto vartotojų skaičius y = x R 2 = PK skaičius, 2000 m. 3 pav. ES šalių PK skaičiaus ir Interneto vartotojų skaičiaus tarpusavio priklausomybė ir jos aproksimacija tiesine regresija (2000 metai) Vidutinis PK skaičiaus ir Interneto vartotojų skaičiaus ES šalyse kitimas 998, 999 ir 2000 metais pavaizduotas 4 pav. XIV 3

16 D. Dzemydienė, V.Rudzkienė PK skaičius 00 gyv. Interneto vartotojų skaičius 00 gyv pav. Vidutinis PK ir Interneto vartotojų skaičiaus 00 gyventojų ES šalyse kitimas 998, 999 ir 2000 metais PK skaičius siejasi ne tik su Interneto vartotojų skaičiumi, bet ir su nedarbo lygiu. Tik šiuo atveju priklausomybė yra silpnesnė ir atvirkštinė, t.y. kuo šalyje didesnis PK skaičius, tuo mažesnis nedarbo lygis. Ši priklausomybė kasmet po truputį stiprėja: 995 apskaičiuota porinio koreliacijos koeficiento tarp PK skaičiaus 00-ui gyventojų ES valstybėse ir nedarbo lygio reikšmė buvo 0,45, 999 metais - -0,5, o 2000 metais - -0,52 (žr. 5 pav.). Nedarbo lygis, proc y = -0.24x R 2 = PK skaičius 00-ui gyv. 5 pav. ES šalių PK skaičiaus 00 gyventojų ir nedarbo lygio procentais tarpusavio priklausomybė ir jos aproksimacija tiesine regresija (2000 metai). Lyginant su ES šalimis, Lietuvos rodikliai atrodo labai kukliai. Grafinis pavidalas dėl skaičių mažumo nėra vaizdingas, todėl šie duomenys pateikti Lentelėje. Lentelė. Vidutinis PK ir Interneto vartotojų skaičius 00 gyventojų Lietuvoje Metai PK skaičius 00 gyv Interneto vartotojų sk. 00 gyv * * pažymėtas Lietuvos SD pateiktas skaičius, kitų duomenų šaltinis Eurostat. 4. Lietuvos Interneto vartotojų skaičiaus ir kitų rodiklių analizė Šiuo metu Lietuvoje yra ženkliai pagerėjusios darbo rinkos funkcionavimo sąlygos, skatinančios gyventojų užimtumą. Tai liudija darbo rinką apibūdinantys rodikliai: išaugo darbo jėgos paklausa, sumažėjo bedarbių skaičius, sumažėjo nedarbo lygis bei jo teritorinė diferenciacija. Juntamai pagerėjus verslo sąlygoms ir bendrai ekonominei padėčiai, per šiuos metus darbdaviai teritorinėse darbo biržose užregistravo 45 tūkst. laisvų darbo vietų. Į jas, taip pat ir ankščiau užregistruotas darbo vietas, tarpininkaujant teritorinėms darbo biržoms buvo įdarbinta 48 tūkst. asmenų arba vidutiniškai,4 tūkst. kas mėnesį. Aktyviose darbo rinkos politikos priemonėse dalyvavo 23,7 tūkst. XIV 4

17 Lietuvos ir Europos Sąjungos šalių informacinių technologijų plėtros daugiamatės bedarbių. Tai įgalino juos lanksčiau prisitaikyti prie kintančios darbo rinkos sąlygų, padidino jų įsidarbinimo galimybes m. pirmojo pusmečio darbo rinkos kitimo duomenys rodo, kad pasiekta teigiamų pokyčių subalansuojant darbo rinką ir mažinant nedarbą. Visose apskrityse ir savivaldybių teritorijose pastebima nedarbo lygio mažėjimo tendencija. Vietinės užimtumo iniciatyvos paremia naujų darbo vietų kūrimo projektus, padedančius sutelkti vietos bendruomenės socialinių ekonominių partnerių pastangas, atskirų savivaldybių gyventojų užimtumo bei vietos socialinės ekonominės infrastruktūros vystymui. Lietuvos IT vystymosi rodiklių palyginamąją analizę pradėsime lygindami šalių kandidačių pagrindinius informacinių ir komunikacinių technologijų plėtros rodiklius. Lyginant su ES šalimis, pagrindiniai informaciniai rodikliai, charakterizuojantys Lietuvos IT išsivystymą (personialinių kompiuterių skaičius ir interneto vartotojų skaičius tenkantis 00 gyventojų) yra kuklesni (6 pav.) PK skaičius 00 gyv. Interneto vartotojų sk. 00 gyv. 6 pav. Lietuvos PK ir Interneto vartotojų skaičius 00 gyventojų metais. Lietuvos IT rodiklių palyginamąją analizę pradėsime nuo 200 metų šalių kandidačių rodiklių palyginimo. Pirmiausia galima pastebėti, kad iš nagrinėjamų valstybių tarpo savo savybėmis išskiria dvi valstybes tai Malta ir Kipras. Šios dvi valstybės pasižymi labai mažu gyventojų skaičiumi (67 ir 390 tūkst.gyventojų) ir jų vystymasis kelias skiriasi nuo kitų valstybių, kurios priklausė buvusiam sovietiniam blokui. Todėl Lietuvos rodiklius lyginsime su aštuonių valstybių kandidačių grupėje. Nagrinėdami tuos pačius rodiklius, kaip ir ES šalių grupėje, pastebime keletą esminių skirtumų: () Pagrindinė priklausomybė šių valstybių grupėje yra ne tarp PK ir Interneto vartotojų skaičiaus, o tarp BVP vienam gyventojui pagal perkamąją galią, kai ES šalių BVP prilyginams 00 ir korinio (mobiliojo) ryšio abonentų skaičiaus 00-ui gyventojų (7 pav.): Pirsono koreliacijos koeficiento dydis 200 m.: corr(bvp vienam gyventojui pagal perkamąją galią; korinio (mobiliojo) ryšio abonentų skaičius 00-ui gyv.)= 0,95; (2) Antroji priklausomybė yra tarp korinio (mobiliojo) ryšio abonentų skaičiaus 00-ui gyventojų ir nedarbo lygio (8 pav.). Pirsono koreliacijos koeficiento dydis 200 m.: corr(korinio (mobiliojo) ryšio abonentų skaičius 00-ui gyv.; nedarbo lygis)= 0,77; Nors seka trumpa (N=8) abu šie koeficientai reikšmingi esant 5 procentų reikšmingumo lygmeniui. Tuo tarpu ES šalių grupėje šios priklausomybės nėra reikšmingos. Paskutinėje analizės dalyje ištiriame, kurių rodiklių reikšmės ES šalių ir šalių kandidačių grupėse labiausiai skiriasi, t.y. nustatome kurie rodikliai diskriminuoja šias grupes. Tam tikslui panaudosime daugiamatį diskriminantinės analizės metodą (tiksliau, Fišerio tiesinės diskriminantinės analizės metodą). Diskriminantinėje analizėje pagal kintamųjų reikšmes nustatomi požymiai, leidžiantys atskirti tiriamas grupes ir įvertinama diskriminavimo kokybė. Tam tikslui panaudosime programą STATISTICA 5.5 Apskaičiavus Vilkso 7 Užimtumas ir darbo rinka/lr socialinės apsaugos ir darbo ministerija// XIV 5

18 D. Dzemydienė, V.Rudzkienė lambda statistiką, gauname reikšmę 0,045. Reikšmė, artima nuliui, rodo, kad kintamieji gerai diskriminuoja grupes. Vilkso lambda statistiką transformavus į F statistiką, gauname reikšmę F=56,67, kuri taip pat rodo egzistuojančius esminius grupių skirtumus. Toliau nustatysime, kurie rodikliai turi didžiausią diskriminavimo galią (2 lentelė). Mobiliojo ryšio abonentų skaičius y =.4887x R 2 = BVP vienam gyventojui 7 pav. ES šalių kandidačių BVP vienam gyventojui pagal perkamąją galią, kai ES=00 ir korinio (mobiliojo) ryšio abonentų skaičius 00-ui gyventojų tarpusavio priklausomybė ir jos aproksimacija tiesine regresija (200 m.) y = x R 2 = Nedarbo lygis Mobiliojo ryšio abonentų skaičius 8 pav. Šalių-kandidačių korinio (mobiliojo) ryšio abonentų skaičius 00-ui gyventojų ir nedarbo lygio tarpusavio priklausomybė ir jos aproksimacija tiesine regresija (200 metai). 2 lentelė. Diskriminantinės analizės rezultatai Wilks' Lambda: approx. F (6,6)=56.67, p< Wilks' Lambda Partial Lambda F-remove (,6) p-level Procentinė BVP dalis, skiriamos IT BVP vienam gyventojui pagal perkamosios galios paritetą PK skaičius, tenkantis 00-ui gyventojų Interneto vartotojų skaičius 00 gyventojų Mobiliojo ryšio abonentų skaičius 00- ui gyventojų Nedarbo lygis Kaip matyti iš 3 lentelės šios grupės labiausiai skiriasi pagal BVP vienam gyventojui apskaičiuotam įvertinant perkamąją galią. Taip pat grupes reikšmingai atskiria dar du kintamieji: mobilųjų telefonų skaičius (reikšmingumo lygmuo p=0,062) ir procentinė BVP dalis, skiriamas IT vystymui (p=0,068). XIV 6

19 Lietuvos ir Europos Sąjungos šalių informacinių technologijų plėtros daugiamatės Naudojant šį metodą naudosime valstybių klasifikavimui, turėtume gauti aukštą klasifikavimo kokybę, kadangi pagal apskaičiuotas klasifikavimo funkcijas turimiems duomenims gautas 00 procentų klasifikavimo tikslumas. 3 lentelė. Kanoninių klasifikuojančių funkcijų koeficientai Klasifikacinės funkcijos; grupė 2 grupė p= BVP vienam gyventojui Mobiliojo ryšio abonentų skaičius p= ui gyventojų Procentinė BVP dalis, skiriamos IT Constant Išvados ES šalių nedarbo lygio mažėjimą sąlygoja didejantis PK skaičius. ES šalių kandidačių nedarbo lygio mažėjimas susijęs su mobiliojo ryšio abonentų skaičiaus didėjimu. Didžiausi informacinių ir komunikacinių technologijų išsivystymo skirtumai tarp ES šalių narių ir kandidačių pastebimi šiuose rodikliuose: bendrojo vidaus produkto tenkančio vienam gyventojui dydį, įvertintą pagal perkamosios galios paritetą (PPS), procentinės BVP dalies, skiriamos IT dydį ir mobiliojo ( korinio) ryšio abonentų skaičiaus 00-ui gyventojų kitimą. Literatūros sąrašas [] Dzemydienė D., Naujikienė R. Patariamosios sistemos teisėtvarkoje. // Mokslo darbai. Informacijos mokslai. T. 8, Vilniaus universitetas. 200, p [2] Rudzkienė V. Statistical Packages in Teaching Process. Informacijos mokslai, ISSN , T , p , [3] Rudzkienė V. The Analysis of Non-parametric Modules of Statistical Systems // Informacinės technologijos. Kaunas: Technologija. 200, p [4] Social Partners Sign Teleworking Accord /European industrial relations observatory on-line// XIV 7

20 INFORMACINIŲ SISTEMŲ MODELIAVIMAS DALYKINĖS SRITIES ŽINIŲ POŽIŪRIU Irma Valatkaitė Vilniaus Gedimino Technikos Universitetas, Saulėtekio al., Vilnius Olegas Vasilecas Vilniaus Gedimino Technikos Universitetas, Saulėtekio al., Vilnius Pastarąjį dešimtmetį žinios tapo aktualia sąvoka tiek mokslininkams, tiek verslo atstovams. Žinių ekonomika, žinių visuomenė, žinių sistema, žinių valdymas tai tik keletas sąvokų, žyminčių bendrą mokslo bei verslo vystymosi tendenciją. Pastaruoju metu itin daug dėmesio susilaukė verslo informacinių sistemų modeliavimas žinių požiūriu sparčiai tobulėjančios verslui skirtų programų bei informacinių sistemų technologijos bei vis galingesnė kompiuterinė technika įgalina valdyti žinias kaip bet kurį kitą turtą ir sėkmingai jas naudoti naujos vertės kūrimui. Šiame straipsnyje siūloma tokias verslo informacines sistemas modeliuoti naudojant koncepcinius grafus, nes koncepciniai grafai atitinka pagrindinius žinių vaizdavimo kalbai keliamus reikalavimus (lengvai skaitoma, suprantama dalykinės srities ekspertams ir formali). Turimo žinių modelio realizacija automatiniu generavimo būdu stipriai sumažintų informacinių sistemų kūrimo sąnaudas. Be to, nagrinėjant dalykinės srities žinias verslo taisyklių požiūriu, gali būti palaikomas reikalavimas verslo taisykles modeliuoti, realizuoti bei saugoti atskirai nuo informacinės sistemos duomenų bei funkcijų, tai yra palaikyti verslo taisyklių repozitorijaus koncepciją.yra apibrėžiama verslo informacinių sistemų kūrimo technologija, kurioje ir panaudojami paminėtieji elementai.. Įvadas Pastarąjį dešimtmetį žinios tapo aktualia sąvoka tiek mokslininkams, tiek verslo atstovams. Žinių ekonomika, žinių visuomenė, žinių sistema, žinių valdymas tai tik keletas sąvokų, žyminčių bendrą mokslo bei verslo vystymosi tendenciją. Šiuolaikinė visuomenė tiesiog ir vadinama žinių arba kompetencijos visuomene. Toks įvardijimas rodo, kad dabartinėje visuomenėje profesionalumo klausimas, t. y., kaip formuojamas pats žinojimas, žinojimo struktūros ir žinojimo panaudojimo galimybės, yra pagrindinis šios visuomenės praktinis klausimas [3]. Orientacija į žinias bei aktyvus jų naudojimas skatina kurti ir diegti intelektualias informacines sistemas, kurių svarbiausia savybė yra ne tik duomenų, bet būtinai ir verslo procesuose naudojamų žinių bei informacijos apdorojimas. Šio tikslo siekiant, informacinių sistemų moksle atsirado ar buvo pritaikytos tokios sąvokos kaip žinių vaizdavimas (knowledge representation), žinių modeliavimas (knowledge modeling), žinių apdorojimas (knowledge processing), ontologija (ontology), žinių radimas (data or knowledge mining), intelektualios sistemos (intelligent systems), agentai bei intelektualūs agentai (agents, intelligent agents) ir pan. Dauguma šių sąvokų, tokios kaip žinių vaizdavimas bei modeliavimas ar ontologija, nėra naujos sąvokos, tačiau pastaruoju metu jos nagrinėjamos bei taikomos ne tik teoriniuose moksliniuose tyrinėjimuose ar moksliniuose eksperimentiniuose taikymuose, bet ir kuriant realias verslo informacines sistemas. Tokiame kontekste ypatingai aktualus tampa uždavinys, kurį trumpai galima suformuluoti taip: analizuoti realų pasaulį aprašančias žinias ir atvaizduoti jas tokia forma, kuri leidžia tas žinias panaudoti verslo informacinėse sistemose. 2. Naujausios žinių naudojimo tendencijos versle bei verslo informacinėse sistemose Pastaruoju metu itin daug dėmesio susilaukė verslo informacinių sistemų modeliavimas žinių požiūriu. Tai lėmė keletas faktorių. Pirma, visuomenės požiūris į žinių vaidmenį įvairiuose visuomeniniuose, o taip pat ir verslo procesuose. Aiškiai įvardijamos žinios yra suvokiamas kaip turtas, kuris gali būti kaupiamas, saugojamas, panaudojamas, parduodamas ir pan., žinios suvokiamos kaip intelektualinė jų turėtojų nuosavybė. Antra, kokybiškai pakitęs verslui vykdyti reikalingų išteklių rinkinys brangiausia jo dalis yra žinios, kaip sėkmingai vykdyti verslą, o ne tiesioginiai fiziniai ištekliai. Trečia, sparčiai tobulėjančios verslui skirtų programų bei informacinių sistemų XIV 8

21 Informacinių sistemų modeliavimas dalykinės srities žinių požiūriu technologijos bei vis galingesnė kompiuterinė technika įgalina valdyti žinias kaip bet kurį kitą turtą ir sėkmingai jas naudoti naujos vertės kūrimui. Šie faktoriai, kartu paėmus, sąlygoja ne tik žinių svarbos didėjimą, bet taip pat kelia mokslininkams naujus reikalavimus realiai kurti pažangias verslą remiančias informacines sistemas, kurios įgalintų verslo organizaciją konkuruoti rinkoje bei įgyvendintų žinių visuomenės sampratą apie pažangius verslo vykdymo metodus. Svarbus reikalavimas pažangioms technologijoms bei informacinėms sistemoms yra tiesioginis pritaikomumas verslo organizacijose. Žinios yra pakankamai abstrakti sąvoka, turinti daug interpretacijų. Pastaruoju metu išryškėjo tendencija suvokti bei modeliuoti verslo turimas ar kuriamas žinias verslo taisyklėmis. Tai galima paaiškinti keliais įtakojančiais faktoriais:. Verslo taisyklės nėra naujas terminas, juo operuoja verslo dalyviai aprašydami verslo procesus. Paprastai verslo organizacijos turi procesų aprašus, tvarkas ir pan. Tai rodo, kad verslo dalyviai be sistemų analitikų pagalbos geba identifikuoti, kokios taisyklės naudojamos jų verslo procesuose bei procedūrose. 2. Verslo taisyklės yra būdas struktūrizuoti verslo žinias. Kadangi naudoti verslo taisykles geba ir verslo dalyviai, ir sistemų analitikai, šis būdas yra patogus ir kaip bendravimo tarp probleminės srities ekspertų ir sistemų analitikų kalba. Tai yra svarbus veiksnys, nes būtent vieninga probleminės srities samprata įgalina sistemų analitikus formuluoti korektiškus tikslus kuriamai informacinei sistemai. 3. Verslo taisyklės savo sandara artimos produkcinėms taisyklėms, todėl jas galima formalizuoti naudojant kurią nors formalią žinių vaizdavimo kalbą. 4. Turint formalų žinių modelį, galima naudoti įvairius dirbtinio intelekto, žinių vaizdavimo, žinių apdorojimo, žinių išgavimo (mining), aktyvių ir intelektualių duomenų bazių, intelektualių agentų technologijas bei metodus (plačiau apie juos galima pasiskaityti [], [2]). Tokiu būdu galima teigti, kad versle naudojamas žinias suprasti, naudoti ir modeliuoti verslo taisyklėmis yra patogu, praktiška bei korektiška. 3. Verslo taisyklės Skirtinguose šaltiniuose pateikiami sąvokos verslo taisyklė apibrėžimai yra labai panašūs. Ir GUIDE [6] projekto autoriai, ir OMG [20] verslo taisyklę apibrėžia dviem aspektais:. Verslo požiūriu verslo taisyklė yra direktyva, skirta įtakoti ar valdyti verslo elgseną, tuo būdu realizuojant verslo politiką, kurią sąlygoja galimybės vystytis bei išorinės ar vidinės grėsmės. Tai yra bet kokie apribojimai ar nurodymai, taikomi verslo dalyviams tiek nurodymai, kur leistina rūkyti, tiek pirkimo-pardavimo dokumentų registravimo tvarka. 2. Informacinių sistemų požiūriu verslo taisyklė yra teiginys, kuris nusako ar apriboja kurį nors verslo aspektą, deklaruoja verslo struktūrą, kontroliuoja arba kitaip įtakoja verslo procesus. Informacinėse sistemose tai realizuojama kaip faktų registravimas naudojant duomenų struktūras bei šių faktų reikšmių keitimo ribojimai. Verslo taisyklės esmė nepriklauso nuo jos išraiškos būdo (vartojamų terminų ar sintaksės). Paprastai verslo taisyklės yra išreiškiamos tais terminais, kuriais operuoja verslo dalyviai, naudojant sintaksę, kuri patogi verslo dalyviams, nes verslo taisyklių savininkai yra būtent verslo dalyviai. Modeliuojant verslo informacinę sistemą, būtina atkreipti dėmesį į tai, kad verslo taisyklės paprastai keičiasi greičiau nei probleminės srities duomenų struktūros ar objektų elgsena. Verslo informacinės sistemos analizės, projektavimo bei programavimo etapuose dažnai prireikia verslo taisyklių rinkinį patikslinti, papildyti bei kitaip atnaujinti; tai sąlygoja verslo vykdymo tvarkos pokyčiai. Be to, verslo taisyklės yra nuolat tobulinamos tai natūralus procesas, nes verslo organizacijos laikui bėgant taip pat nuolat keičiasi adaptuojasi prie besikeičiančios verslo aplinkos. Tačiau bet kokie pakeitimai neturėtų sugriauti pradinio verslo taisyklių rinkinio suderinamumo bei nuoseklumo. Nuoseklumo reikalavimas reiškia, kad taisyklių bei sąlygų rinkinio modifikavimas nesugriauna pradinės sistemos ir neįneša nepageidaujamų šalutinių efektų. Be to, verslo taisyklių galiojimas gali būti apribotas verslo taisyklės gali būti taikomos tik tam tikrą laiko tarpą. Pavyzdžiui, tam tikra paslauga gali būti taikoma tik atitinkamos reklaminės kampanijos metu. Tokios probleminės sritys turi labai greitai augantį ir besikaičiantį verslo taisyklių rinkinį. Verslo taisyklių rinkinio keitimas tradicinėje informacinėje sistemoje yra brangus procesas, nes reikalauja išsamaus testavimo ir gali turėti nepageidaujamų pasekmių [2]. Siekiant išvengti problemų dėl greitos verslo taisyklių kaitos, yra siūloma verslo taisykles ne tik modeliuoti, bet ir realizuoti atskirai nuo kitų informacinės sistemos komponentų. 3.. Verslo taisyklių klasifikacija Verslo taisyklės gali būti klasifikuojamos įvairiais būdais. Verslo taisyklių realizacijos požiūriu patogiausia yra klasifikacijos schema, pasiūlyta [3]. Pagal šią schemą verslo taisyklės gali būti dviejų kategorijų: darnos ir veikos. XIV 9

22 I.Valatkaitė, O.Vasilecas Darnos taisyklės nurodo duomenų darnos reikalavimus, kurie gali būti užtikrinti pasyviais ir aktyviais darnos ribojimais. Pasyvūs ir aktyvūs darnos ribojimai skiriasi veikimo strategija: aktyvūs ribojimai užtikrina duomenų darną vykdant duomenų keitimo operacijas, o pasyvūs ribojimai uždraudžia vykdyti operacijas, kurios pažeistų duomenų darną. Veikos taisyklės savo ruožtu nusako veiksmus ar operacijas, kurios turi būti įvykdytos. Klasifikavimo schema yra parodyta paveiksle. Verslo taisyklės Darnos Veikos Aktyvios Pasyvios 3.2. Verslo taisyklių modeliavimas pav. Verslo taisyklių klasifikacija Kadangi verslo taisyklės apibrėžia bet kurio ir kiekvieno verslo proceso ar struktūros veikimo principus, galima sakyti, kad verslo taisyklės iš tikrųjų yra informacinės sistemos funkcinių reikalavimų pagrindas. Modeliuojant verslo informacines sistemas verslo taisyklės turi būti nagrinėjamos kaip viena svarbiausių modelio dalių, nes būtent verslo taisyklės aprašo probleminę sritį. Esminis skirtumas yra modeliavimo koncepcija kokiu požiūriu vadovaujantis yra kuriamas informacinės sistemos modelis. Informacinių sistemų modeliavimas verslo taisyklių požiūriu yra vienas naujausių informacinių sistemų projektavimo būdų, kuris remiasi verslo taisyklių koncepcija. Šis modeliavimo požiūris įgalina išvengti verslo taisyklių kaitos keliamų problemų. Tai yra, tradiciniais metodais sukurtos informacinės sistemos pakeitimo ar pritaikymo prie pasikeitusios situacijos išlaidos yra pernelyg didelės. Verslo taisyklėmis pagrįstoje sistemoje taisyklių rinkinio keitimas yra lokalizuotas, neįtakojantis kitų sistemos komponentų. Be to, egzistuojantys informacinių sistemų specifikavimo ir projektavimo modeliai blogai išreiškia dalykinėje srityje galiojančias taisykles, jos yra padrikai paskirstytos po visą sistemą. Taikant verslo taisyklių koncepciją, galima išspręsti šią problemą, nes taisyklių identifikavimas ir automatizavimas yra išreiškiamas formaliais metodais, o pačios taisyklės saugomos atskirai nuo kitų sistemos komponentų [7]. 998 metais ECOOP (European Conference on Object-Oriented Programming) konferencijos metu verslo taisyklėms buvo skirtas itin didelis dėmesys ir vykusio seminaro metu buvo suformuluoti reikalavimai, kuriuos turi tenkinti darbui su verslo taisyklėmis skirtos priemonės bei sistemos. Šie reikalavimai išreiškia ne vieno autoriaus, bet visų seminaro dalyvių nuomonę. Seminaro medžiaga paskelbta [7], o reikalavimai priemonėms bei sistemoms yra tokie:. Centralizuotas repozitorijus. Verslo taisyklės turi būti realizuotos viename centralizuotame repozitorijuje. Repozitorijus gali būti necentralizuotas fiziniame lygmenyje, bet loginiame būtinai. Jei šis reikalavimas tenkinamas, viename repozitorijuje yra saugomas pilnas taisyklių rinkinys. 2. Adaptyvumas. Esamas taisyklių rinkinys turi būti lengvai keičiamas taisyklės modifikuojamos, trinamos ar įrašomos naujos. 3. Konfliktų aptikimas. Galimybė aptikti konfliktuojančias taisykles. 4. Kodo derinimo vykdymo metu (debugging) palaikymas. Galimybė surasti vykdymo metu atsirandančias klaidas. 5. Deklaratyvi kalba. Verslo taisyklės turi būti išreiškiamos deklaratyviąja kalba. 6. Specialūs verslo taisyklių peržiūros įrankiai. Tai verslo taisyklių peržiūrai skirti įrankiai, kurie taip pat gali riboti priėjimą prie verslo taisyklių priklausomai nuo jų tipo bei prisijungusio vartotojo tipo. 7. Efektyvumas. Efektyvumas yra sunkiai pamatuojamas rodiklis, bet seminaro dalyviai sutarė, kad efektyvumas turėtų būti sveiko proto ribose. 8. Verslo taisyklės išreiškiamos aiškiai. Šis reikalavimas reiškia, kad verslo taisykles palaikanti sistema ar priemonė verslo taisykles modeliuotų, saugotų, vykdytų ir įvardintų aiškiai kaip verslo taisykles, o ne funkcinius ar duomenų reikalavimus. 9. Formalus pagrindas. Verslo taisyklės turi būti vaizduojamos formaliai. Šis reikalavimas gali būti taikomas ir dviem etapais: pirminiame verslo taisyklių modeliavimo etape gali būti naudojamas ir neformalus būdas, bet XIV 20

23 Informacinių sistemų modeliavimas dalykinės srities žinių požiūriu vėliau verslo taisyklės turi būti išreikštos aiškia, formalia kalba. Taip pat pastebėta, kad geriau yra rinktis kurią nors standartinę kalbą KIF (Knowledge Interchange Format), OCL (Object Constraint Language), UML (Unified Modeling Language) ir pan. 0. Verslo taisyklių identifikavimas ir ištraukimas iš realaus pasaulio atvaizdavimų. Žinių ištraukimas (elicitation) yra sudėtingas procesas, kurio metu neaiškiai išreikštos žinios, sukauptos kaip žmonių patirtis, bei saugomos įvairiais pavidalais (dokumentais, duomenyse ir pan.) yra identifikuojamos, įvardijamos ir vaizduojamos kaip aiškiai išreikštos žinios. Tačiau pilnas šio proceso automatizavimas yra labai gražus, bet kol kas nepasiekiamas tikslas.. Vientisumo ir nuoseklumo palaikymas. Norint išsaugoti verslo taisyklių rinkinio vientisumą ir nuoseklumą, būtina užtikrinti, kad tik tam skirtomis priemonėmis būtų galima rinkinį peržiūrėti ir modifikuoti. Taip pat reikia užtikrinti, kad verslo taisyklių rinkinį pasiektų tik tokias teises turintys vartotojai. 2. Vaizdavimas. Verslo taisyklės gali būti įvairiai vaizduojamos, pageidautina, kad vaizdavimo būdas priklausytų nuo vartotojo tipo, lygio ar pasirinkimo. Vaizdavimas nebūtinai turi būti formalus. Pavyzdžiui, galima taisykles vaizduoti lentelėmis, grafais ar medžio tipo struktūromis. 3. Atvirumas. Galimybė įrašyti naujas taisykles bei modifikuoti esamas. 4. Samprotavimo mechanizmas. Galimybė gauti naujus faktus ar taisykles, o ne tik saugoti taisykles. 5. Skirtingų lygių taisyklių palaikymas. Verslo taisyklės gali būti kelių lygių priklausomos nuo dalykinės srities, priklausomos nuo konkrečios informacinės ar programų sistemos ir pan. Tokiam reikalavimui tenkinti turi būti palaikoma verslo taisyklių klasifikavimo ar grupavimo galimybė. 6. Integracija su jau egzistuojančiomis sistemomis. Svarbu integruoti verslo taisyklėms skirtą priemonę su jau egzistuojančiomis sistemomis, jų kūrimo metodais, technologijomis ir notacijomis. 4. Verslo taisyklių modeliavimui naudojamos kalbos, sistemos, metodai 4.. UML bei OCL Šiuo metu bene populiariausia informacinių sistemų modeliavimo kalba yra UML (Unified Modeling Language), atsiradusi mokslininkų bei komercinių kompanijų jungtinių pastangų dėka ir vienijanti kelių ankstesnių modeliavimo kalbų geriausias idėjas [6]. UML be jokios abejonės šiuo metu yra standartinė informacinių bei programų sistemų modeliavimo kalba, plačiai naudojama ne tik informacinių ar programų sistemų, bet ir verslo procesų, organizacijų modeliavimui. Natūralu, kad UML bandoma pritaikyti ir verslo taisyklių modeliavimui. Tam yra naudojamas papildoma UML kalbos komponentė OCL (Object Constraint Language) [2]. OCL yra kalba, skirta išreikšti tokius objektų elgsenos apribojimus, kuriuos neįmanoma išreikšti naudojant tik UML konstrukcijas. OCL yra formali logikos pagrindu sukurta kalba, neturinti grafinės notacijos. SQL rodinių bei trigerių šablonų (templates) generavimas iš OCL kalba išreikštų apribojimų yra aprašytas [0]. Pagrindinis pasiūlyto būdo elementas yra SQL rodinių generavimas pagal OCL kalba parašytą sąlygą. Jeigu objektas, kurio apribojimas nagrinėjamas, netenkina taisyklės, jo duomenys bus SQL rodinyje. Tikrinant rodinio reikšmes, galima realizuoti tolimesnius reikalingus veiksmus. Yra siūlomi trys būdai realizuoti rodinio tikrinimą bei tolimesnius veiksmus:. Rodinio tikrinimas iš taikomosios programos. Rodinio reikšmių tikrinimas nesiejamas su duomenų bazės vientisumo ir nuoseklumo tikrinimo mechanizmais, tokiais kaip, pavyzdžiui, trigeriai. Priešingai, taikomosios programos kode turi būti įrašyta rodinio tikrinimo sąlyga. Tai yra kombinuotas požiūris naudojami tiek duomenų bazės tikrinimo mechanizmai (rodiniai), tiek taikomosios programos metodai. Tačiau tokiu būdu netenkinama sąlyga atskirti verslo taisyklių rinkinio realizaciją nuo kitų informacinės sistemos komponentų. 2. Tvirtinimų (assertion) pakeitimas. Trigeriai, kurie naudojami įvertinti duomenų neprieštaringumą bei korektiškumą, gali būti naudojami kaip mechanizmas, stabdantis programos vykdymą ir paskelbiantis apie klaidą. Toks trigeris yra aktyvuojamas po kurios nors duomenų atnaujinimo operacijos. Vienintelis veiksmas, kuris yra atliekamas, jei rodinyje yra randama duomenų, yra klaidos pranešimas. Toks trigerio naudojimo būdas iš tikrųjų nepilnai realizuoja verslo taisykles visų verslo taisyklių veiksmas būtinai yra klaidos pranešimas, o tai nėra teisybė. Galima teigti, kad tik labai maža verslo taisyklių dalis gali būti suformuluota ir realizuota tokiu būdu. 3. ECA trigerio šablonas. Verslo taisyklės savo sandara yra panašios į ECA taisykles [9]. ECA taisyklės yra tokios formos: įvykus įvykiui, jei tenkinama sąlyga, vykdomas veiksmas. Įvykis nurodo, kada verslo taisyklė turi būti aktyvuojama; sąlyga apibrėžia, kas turi būti patikrinta prieš aktyvuojant verslo taisyklę; veiksmas specifikuoja, kas turi būti atlikta, jei sąlyga yra tenkinama. ECA struktūra leidžia apibrėžti ir paprastus darnos ribojimus, ir sudėtingą verslo procesą. Autorių siūlomas būdas leidžia gauti tik trigerio šabloną, tai yra, sugeneruojamas tik trigerio įvykis bei sąlygos tikrinimas (kuris yra rodinio reikšmių skaičiaus tikrinimas), o veiksmo pačios sudėtingiausios verslo taisyklės dalies realizacija paliekama programuotojams. XIV 2

24 I.Valatkaitė, O.Vasilecas Kitas siūlymas specifikuoti verslo taisykles OCL kalba ir realizuoti jas aktyvių duomenų bazių trigeriais, yra pristatytas darbe [4]. Pasiūlytas algoritmas, generuojantis reliacinės duomenų bazės trigerius iš UML/OCL specifikacijos. Tačiau algoritmo veikimo sritis yra labai ribota: palaikomos tik darnos taisyklės. Apibendrinant galima pasakyti, kad siūlomi būdai modeliuoti verslo taisykles UML ir OCL bei vėliau jas realizuoti duomenų bazių technologijomis (rodiniais bei aktyvių duomenų bazių trigeriais) yra vienas būdų dirbti su verslo taisyklėmis. UML naudojimas lengvai integruoja siūlomus būdus į jau egzistuojančias modeliavimo bei realizacijos priemones, nes UML kalba yra viena plačiausiai naudojamų modeliavimo kalbų. Tačiau naudojant UML neišvengiamai tenka spręsti kitas problemas: modeliuoti verslo taisykles UML konstrukcijų neužtenka, todėl naudojama OCL kalba. OCL kalba yra formali kalba, todėl yra tinkama probleminės srities verslo taisyklėms modeliuoti; tačiau OCL, formali kalba, neturi jokios grafinės notacijos, todėl yra netenkinamas reikalavimas, kad verslo taisyklių modelis būtų suprantamas ir probleminės srities ekspertams; siūlomi būdai apsiriboja darnos taisyklių modeliavimu bei realizacija, o veikos taisyklės (tai yra tokios taisyklės, kurios specifikuoja verslo algoritmus, procedūras ar tvarką) nėra nagrinėjamos; o jeigu nagrinėjamos, tai automatinė realizacija nėra galima CDM RuleFrame Oracle Corp. taip pat siūlo metodą, kalbą ir priemones verslo logikai modeliuoti ir realizuoti taikant verslo taisyklių požiūrį [5]. CDM RuleFrame yra aplinka (framework), kartu ir architektūra, skirta verslo taisyklėms analizuoti, modeliuoti ir realizuoti. Naudojant Oracle Designer priemones verslo logikos meta-duomenims saugoti, daug užduočių yra atliekamos automatiškai. Pagal CDM RuleFrame verslo taisyklės yra modeliuojamos atskirai nuo duomenų, verslo funkcijų ir įvykių aprašymų, tuo būdu yra palaikoma verslo taisyklių repozitorijaus idėja ir tenkinamas esminis verslo taisyklių sistemų reikalavimas. Verslo taisyklės yra klasifikuojamos tokiu būdu:. Autorizacijos taisyklės ar besikreipiantis vartotojas turi teisę pasiekti šiuos duomenis ar operacijas. 2. Ribojimai ar vykdoma duomenų apdorojimo operacija ir jos rezultatai yra korektiški. statiniai dinaminiai 3. Keitimo įvykių taisyklės kokios papildomos operacijos turi būti atliekamos po kurios nors duomenų apdorojimo operacijos. kartu su duomenų apdorojimo operacija be duomenų apdorojimo operacijos Ši taisyklių klasifikavimo schema labai primena pateiktąją 3. skyriuje (žr. paveikslą), tik CDM RuleFrame atskirai išskiria autorizacijos taisykles. Ribojimai yra darnos taisyklės jų paskirtis yra leisti arba neleisti įvykti duomenų keitimo operacijai, o keitimo įvykių taisyklės yra tas pats, kaip veikos taisyklės, nes jos nurodo, kokie veiksmai ir kada turi būti atlikti. CDM RuleFrame aplinkoje verslo taisyklių modeliavimo kalba yra RuleSLang, kuri yra OCL poaibis, pritaikytas informacijos inžinerijai, Oracle Designer naudojimui ir CDM RuleFrame architektūrai. Ši kalba bus palaikoma Oracle priemonių. Deja, ji, kaip ir OCL, neturi grafinės notacijos. Apibrėžus taisykles RuleSLang kalba, galima automatiškai gauti taisyklių formuluotes natūraliąja kalba anglų ar kuria nors kita, kuria yra nurodyti vertimai visiems RuleSLang standartiniams elementams. Toks vertimas yra naudingas pavyzdžiui, analitikas gali patikrinti, ar teisingai panaudojo RuleSLang elementus ir sintaksę; o vartotojas gali perskaityti taisykles kalba, kuri yra mažiau formali nei pati RuleSLang. Svarbiausias tikslas automatinis taisyklių realizacijos kodo generavimas yra atliekamas panaudojant kitas Oracle priemones [5] Verslo taisyklių repozitorijus Darbuose [8], [7] KTU mokslininkai pateikia verslo taisyklių repozitorijaus architektūros bei tokio repozitorijaus realizacijos galimybių tyrimų rezultatus. Verslo taisyklių repozitorijaus architektūra yra kuriama remiantis Rosso verslo taisyklių klasifikavimo schema. Verslo taisyklių repozitorijus yra kuriamas kaip atskiras architektūrinis elementas. Pagrindiniai repozitorijaus kūrimo tikslai yra struktūrizuotas taisyklių bei jų aprašų saugojimas, priemonės taisyklėms redaguoti bei priemonės, leidžiančios taikomosioms programoms pasinaudoti taisyklių baze. XIV 22

25 Informacinių sistemų modeliavimas dalykinės srities žinių požiūriu Vienas svarbiausių šios technologijos privalumų aiškiai suformuluotas ir išskirtas verslo taisyklių repozitorijus kaip architektūrinis elementas, tokiu būdu pilnai atskiriant verslo taisykles nuo duomenų bei funkcijų (taikomųjų programų) elementų Apibendrinimas Pagal šiame skyriuje pateiktą trumpą verslo taisyklių modeliavimo bei realizacijos technologijų apžvalgą matyti, kad yra siūlomi įvairūs būdai panaudoti verslo taisyklių koncepciją, be to, šiame darbe aktyviai dalyvauja tiek mokslininkai, tiek komercinės kompanijos. Pastarųjų siūlomi sprendimai yra labai glaudžiai susieti su jų kuriamais programiniais produktais, todėl yra tinkami tik tais atvejais, kai yra tikslinga naudotis būtent tos kompanijos paslaugomis. Nepriklausomo verslo taisyklių repozitorijaus idėja yra architektūrinis sprendimas, geriausiai tenkinantis verslo taisyklių sistemoms keliamus reikalavimus žinoma, kai kurių reikalavimų tenkinimas žymia dalimi priklauso tik nuo repozitorijaus realizacijos, bet ne nuo architektūros. Tačiau dabartinės IS kūrimo technologijos bei priemonės yra sunkiai siejamos su nepriklausomo verslo taisyklių repozitorijaus realizacija fiziniame lygmenyje. Todėl šiame darbe yra siūloma technologija, kuri palaiko verslo taisyklių repozitorijaus idėją loginiame lygmenyje naudojant dabartines IS kūrimo priemones. 5. Siūloma verslo informacinių sistemų kūrimo technologija panaudojant verslo taisyklių požiūrį Apibendrinant atliktą mokslo bei verslo tendencijų, metodų, technologijų apžvalgą, galima apibrėžti reikalavimus, į kuriuos būtina atsižvelgti kuriant technologiją pažangioms verslo informacinėms sistemoms kurti:. Pažangi verslo informacinė sistema turi palaikyti žinių naudojimo versle tendencijas (žr. 2 skyrių). 2. Turi būti kuriamas ir palaikomas koncepcinis žinių modelis. 3. Tenkinami žinių vaizdavimo kalbų reikalavimai (išanalizuoti ir suformuluoti [25]). 4. Žinios struktūrizuojamos bei modeliuojamos verslo taisyklių požiūriu (žr. 2 skyrių). 5. Optimaliai tenkinami verslo taisyklių sistemų reikalavimai (žr. 3.2 skyrių). Remiantis aukščiau išvardintais reikalavimais, yra siūloma verslo informacinių sistemų kūrimo technologija, pavaizduota 2 paveiksle. Kaip kiekvienas šių komponentų yra naudojamas, derinamas su kitais bei tokio pasirinkimo motyvai pateikiami žemiau. 5.. Aktyvios duomenų bazės Aktyvių duomenų bazių valdymo sistema tai tradicinė pasyvi duomenų bazių valdymo sistema, papildyta galimybe reaguoti į įvykius [], [26]. Reakcija į įvykius yra apibrėžiama ECA (Event, Condition, Action įvykis, sąlyga, veiksmas) taisyklėmis. ECA taisyklės yra tokios formos: įvykus įvykiui, jei tenkinama sąlyga, vykdomas veiksmas. Taisyklės komponentų semantika: įvykis: kada verslo taisyklė turi būti aktyvuojama, sąlyga: kas turi būti patikrinta prieš aktyvuojant verslo taisyklę, veiksmas: kas turi būti atlikta, jei sąlyga yra tenkinama. Aktyvios duomenų bazės yra tinkamas verslo taisyklių realizacijos būdas dėl keleto priežasčių. Pirma, pagrindinė aktyvių duomenų bazių savybė yra reagavimas į įvykius. Aktyvių duomenų bazių valdymo sistema (toliau ADBVS) pagal jos apibrėžimą turi ECA taisyklių specifikavimo priemones ir ECA taisyklių vykdymo priemones. Šie du mechanizmai ir užtikrina funkcionalumą, reikalingą verslo taisyklių repozitorijui sukurti, valdyti bei vykdyti. Antra, verslo taisyklės savo semantika yra labai panašios į ECA taisykles: verslo taisyklės, kaip ir ECA taisyklės, apibrėžia, kokiomis sąlygomis turi būti vykdomi atitinkami veiksmai, kokie veiksmai kokiomis sąlygomis yra negalimi ir kokie įvykiai aktyvuoja atitinkamas taisykles. Todėl verslo taisyklių realizacija ECA taisyklėmis nėra nauja idėja. Tačiau ankstesniuose darbuose nebuvo tenkinama didžiuma verslo taisyklių sistemoms keliamų reikalavimų. Pavyzdžiui, Herbst ir kiti [4] pavaizdavo, kaip pagal ECA schemą struktūrizuota verslo taisyklė atrodo organizacijos bei informacinės sistemos kontekste (3 pav.):. Verslo taisyklė. Verslo taisyklė yra centrinis šios schemos komponentas, jungiantis visus kitus. 2. Įvykis. Verslo taisyklė turi įvykį, kuris ją aktyvuoja. 3. Sąlyga. Verslo taisyklė gali turėti vieną sąlygą. XIV 23

26 I.Valatkaitė, O.Vasilecas 4. Veiksmas. Verslo taisyklė gali turėti aprašytą vieną ar du veiksmus (jei naudojamas ECAA požiūris: veiksmai yra du pirmas vykdomas, jeigu sąlyga tenkinama, antrasis jeigu sąlyga nėra tenkinama). 5. Informacinės sistemos komponentas. Verslo taisyklės komponentai realizuojami kuriame nors informacinės sistemos komponente. 6. Organizacinis vienetas. Verslo taisyklės gali būti priskirtos kuriam nors organizaciniam vienetui remiantis tuo, kad kuris nors organizacinis vienetas atsakingas už verslo taisyklės apibrėžimą arba vykdymą. 7. Verslo procesas. Verslo taisyklės, struktūrizuotos pagal ECA schemą, gali būti panaudotos aprašyti verslo procesui.tai yra, procesą sudarys tam tikras verslo taisyklių rinkinys. Be to, procesas yra susietas su organizaciniais vienetais. 8. Verslo taisyklės pagrindas. Kiekviena verslo taisyklė turi savo pagrindą kuo remiantis organizacijos padaliniai vadovaujasi būtent tokiomis taisyklėmis. Tai gali būti organizacijos nustatyta darbo tvarka, procesų aprašymai ir pan. 9. Modeliavimo konstrukcija. Tai bet kurios modeliavimo kalbos, kuri gali būti naudojama verslo taisyklėms modeliuoti, konstrukcija. Bendrieji reikalavimai Žinių naudojimo versle tendencijos Koncepcinio žinių modelio reikalingumas Žinių vaizdavimo kalbų reikalavimai Žinių struktūrizavimas verslo taisyklėmis Verslo taisyklių sistemų reikalavimai Patikslinti reikalavimai IS turi turėti priemonių žinių apdorojimui Turi būti kuriamas ir palaikomas žinių koncepcinis modelis Žinių koncepcinis modelio kalba turi būti formali, bet vaizdi IS palaikomos žinios gali būti strujtūrizuojamos verslo taisyklėmis IS turi maksimaliai tenkinti tokioms sistemoms keliamus reikalavimus Reikalavimų tenkinimo būdas Aktyvios duomenų bazės Verslo taisyklių repozitorijus Automatinis trigerių generavimas Verrslo taisyklių modelis koncepciniais grafais Koncepciniai grafai Mineau procesai Verslo informacinių sistemų kūrimo technologija 2 pav. Verslo informacinių sistemų kūrimo technologijos reikalavimai bei komponentai Sukurtas verslo taisyklių repozitorijus turintis grafinę taisyklių peržiūros priemonę, naudojant keletą taisyklių vaizdavimo kalbų Petri tinklus bei ER 2. Didžiausias šio repozitorijaus trūkumas grafiniame peržiūros pakete pakeitus taisyklių modelį, nepalaikomas automatinis pakeitimų perdavimas į fizinį verslo taisyklių modelį. Tai yra, verslo taisyklių realizacija nėra automatinė. Tačiau svarbus šio darbo rezultatas yra sėkmingas verslo taisyklių repozitorijaus sukūrimas naudojant ADBVS priemones. Vadovaujantis šia schema, galima apibrėžti verslo taisyklių repozitorijaus realizaciją aktyvių duomenų bazių trigeriais. Detaliau specifikuotas verslo taisyklės metamodelis pateiktas 4 pav., nesikeičiantys elementai aiškumo tikslais yra nepavaizduoti:. Verslo taisyklė. Tas pats. 2. Įvykis. Tas pats. 3. Sąlyga. Tas pats. 4. Veiksmas. Tas pats. 5. Informacinės sistemos komponentas. Šis komponentas yra verslo taisyklių repozitorijus, kuris realizuojamas ADBVS priemonėmis. XIV 24

27 Informacinių sistemų modeliavimas dalykinės srities žinių požiūriu 6. Organizacinis vienetas. Tas pats, nepavaizduotas. 7. Verslo procesas. Tas pats, nepavaizduotas. 8. Verslo taisyklės pagrindas. Tas pats, nepavaizduotas. 9. Modeliavimo konstrukcija. Tas pats. yra realizuotas 0, N yra realizuota 0, N Informacinės sistemos komponentas 0, N yra realizuotas įvyksta, N, N įvertinama Organizacinis vienetas 0, N susideda iš 0, N, N, N susijęs su vykdomas Verslo procesas, N 0, N apibrėžia, N Verslo taisyklė 0, N yra pagrįsta 0, N, N 0, N susideda iš, N Verslo taisyklės pagrindas 0, N 0, N 0, N Įvykis, 0,, 2 0, N 0, N Sąlyga 0, N 0, N Veiksmas 0, N 0, N susideda iš 0, N 0, N 0, N 0, N susideda iš 0, N 0, N vaizduoja 0, N 0, N 0, N Modeliavimo konstrukcija yra sąlygojamas 3 pav. Verslo taisyklės metamodelis organizacijos kontekste Aktyvios duomenų bazės yra naudojamos kaip verslo taisyklių repozitorijaus realizacijos priemonė Verslo taisyklių repozitorijus Antrasis technologijos elementas yra verslo taisyklių repozitorijus, kuriamas kaip verslo taisykles realizuojančių trigerių rinkinys. Repozitorijus kuriamas prisilaikant komponentinės architektūros principų tikslas yra sukurti tokį repozitorijų, kuris palaikytų aiškiai apibrėžtą taisyklių įrašymo / redagavimo interfeisą ir pagal saugomus taisyklių duomenis, naudojant trigerių generavimo komponentą, gebėtų palaikyti darną tarp taisyklių modelio ir jų realizacijos ADBVS. Tokiu būdu būtų realizuotas verslo informacinių sistemų komponentas, kuris galėtų būti naudojamas nepriklausomai nuo kitų aprašomos technologijos komponentų (modeliavimo kalbos, taisyklių modelio). XIV 25

28 I.Valatkaitė, O.Vasilecas 0, N Duomenų schema Duomenų bazė Duomenų modelis ECA taisyklių apibrėžimo priemonės ECA taisyklių vykdymo priemonės, N, N, N, N, N, yra dalis Aktyvių duomenų bazių valdymo sistema yra realizuotas 0, N, yra realizuotas, N užtikrina vykdymą yra realizuota 0, N Repozitoriumas 0, N yra realizuotas generuojama Verslo taisyklė, N 0, N 0, N susideda iš 0, N 0, N Įvykis, 0,, 2 0, N Sąlyga 0, N 0, N Veiksmas 0, N 0, N 0, N 0, N 0, N susideda iš susideda iš 0, N 0, N vaizduoja 0, N 0, N 0, N Modeliavimo konstrukcija 0, N yra sąlygojamas 5.3. Verslo taisyklių modelis koncepciniais grafais 4 pav. Verslo taisyklės realizuotos ADBVS Verslo taisyklių modelis turi būti kuriamas naudojant koncepcinius grafus kaip žinių vaizdavimo kalbą. Koncepciniai grafai kaip žinių modeliavimo kalba yra aprašyti [24]. Toks modelis gali būti naudojamas keliems tikslams: bendrauti su probleminės srities ekspertu, nes koncepciniai grafai turi grafinę notaciją; tikrinti verslo taisyklių modelį naudojant koncepcinių grafų operacijas (projekcijas, jungimą), detektuoti ciklišką verslo taisyklių kvietimą; automatiškai generuoti trigerius, naudojant koncepcinių grafų CGIF arba KIF formas kaip įeities duomenis generavimo mechanizmui. Bet koks modelio keitimas siūlomoje technologijoje turėtų vykti tik viena kryptimi pirmiausia keičiamas modelis, kurio pakeitimai automatiškai perduodami į realizacijos lygmenį. Tačiau ši problema pakeitimų perdavimas dar nėra išsamiai nagrinėta siūlomos technologijos kontekste ir yra viena tolimesnių tyrinėjimų krypčių. XIV 26

29 Informacinių sistemų modeliavimas dalykinės srities žinių požiūriu 5.4. Automatinis trigerių generavimas Vienas svarbiausių technologijos elementų yra automatinis trigerių generavimo mechanizmas naudojant verslo taisyklių koncepcinį modelį. Tai vienas verslo taisyklių sistemoms keliamų reikalavimų, kurio tenkinimas yra tikriausiai sunkiausiai pasiekiamas. Siūlomoje technologijoje esminis reikalavimas yra naudoti koncepcinius grafus kaip žinių vaizdavimo kalbą verslo taisyklių modeliui užrašyti. Pirmieji šio darbo rezultatai yra pateikti [22] ir [23] darbuose. Pasiūlytas algoritmas generuoti ADBVS trigerius naudojant verslo taisyklių specifikaciją CGIF kalba. CGIF kalba yra vienas koncepcinių grafų formatų, kuris yra ekvivalentiškas KIF bei pirmos eilės predikatų logikai. Tolimesniuose tyrimuose planuojama atsisakyti reikalavimo naudoti kurią nors konkrečią koncepcinio modeliavimo kalbą, nes toks reikalavimas susiaurina taikymo galimybes. Konkrečios modeliavimo kalbos konstrukcijų atvaizdavimas į bendrą repozitorijaus duomenų struktūrą būtų atskiras uždavinys, vykdomas specialių preprocesorių Koncepciniai grafai Koncepciniai grafai pasirinkti kaip žinių vaizdavimo kalba dėl to, kad jie atitinka visus reikalavimus, keliamus žinių vaizdavimo kalboms [25], [24]: formali kalba; turi grafinę notaciją ir suprantama probleminės srities ekspertams; šalia grafinės notacijos turi keletą ekvivalentiškų vaizdavimo formatų CGIF, KIF, LF, kurie yra tekstiniai ir gali būti naudojami žinių apsikeitimui, pavyzdžiui, kaip įeities duomenys kuriam nors transformavimo, generavimo ar išvedimo mechanizmui; palaiko ontologijos naudojimo tendenciją galima specifikuoti probleminės srities konceptus, konceptų hierarchiją, taip pat ryšius tarp konceptų Mineau procesai Mineau [9], [8] pristatė procesus kaip originalios koncepcinių grafų teorijos išplėtimą. Procesais gali būti modeliuojamos veikos taisyklės, kaip parodyta [23]. Procesai apibrėžiami kaip perėjimas iš vienos būsenos į kitą. Pradinė ir naujoji būsenos charakterizuojamos prieš ir po sąlygomis ( pre and post conditions ). Perėjimas iš pradinės būsenos į naująją aktyvuojamas, kai galioja prieš sąlygos (yra įvertinamos kaip teisybė ). Perėjimas (būsenos keitimas) yra suprantamas kaip koncepcinių grafų atmetimas arba patvirtinimas. Proceso apibrėžimas reiškia, kad algoritmas gali būti automatiškai verčiamas į prieš ir po sąlygų porų rinkinį. Procesas formaliai apibrėžiamas taip: procesas p(in g, out g2, ) yra {r I = <pre I, post I >, I [, n] } Tai yra, procesas tai taisyklių r rinkinys, kur kiekvienai taisyklei yra priskirtos prieš ir po sąlygos. Kiekvienas procesas turi n perėjimo taisyklių (kur i n). Įeities parametrai yra koncepciniai grafai, kurie įtraukiami į pirmos perėjimo taisyklės prieš sąlygą kai procesas yra aktyvuojamas. Išeities parametrai yra įtraukiami į paskutinės taisyklės po sąlygą. 6. Išvados ir tolimesnio darbo kryptys Atlikus verslo informacinių sistemų kūrimo technologijų bei požiūrių apžvalgą buvo nustatyta, kad naujų technologijų kūrimą sąlygoja žinių, žinių visuomenės, žinių naudojimo versle tendencijos. Informacinės sistemos yra kuriamos ne tik duomenų bei verslo transakcijų fiksavimui, bet būtinai ir žinių kaupimo bei panaudojimo uždaviniams. Todėl svarbus uždavinys yra sukurti tinkamą verslo informacinių sistemų kūrimo technologiją. Darbe pasiūlyta technologija bei jos pagrindiniai komponentai:. Verslo taisyklių repozitorijus žinios yra modeliuojamos bei struktūrizuojamos verslo taisyklėmis, palaikoma atskiro centralizuoto verslo taisyklių repozitorijaus idėja. 2. Kuriamas ir palaikomas koncepcinis verslo taisyklių modelis. 3. Koncepciniai grafai naudojami kaip žinių modeliavimo kalba. 4. Verslo taisyklėms modeliuoti yra naudojami koncepcinių grafų procesai kaip patogus būdas specifikuoti taisyklių vykdymo sąlygas bei taisyklių veiksmus. 5. Aktyvių duomenų bazių trigeriai yra verslo taisyklių realizavimo būdas. 6. Automatinis trigerių generavimo procesas iš verslo taisyklių modelio koncepciniais grafais, panaudojant koncepcinių grafų CGIF formatą. XIV 27

30 I.Valatkaitė, O.Vasilecas Tolimesnio darbo uždaviniai yra tikslinti bei realizuoti pasiūlytos technologijos komponentus. Pirma, turi būti išnagrinėta, kokiu laipsniu yra tenkinami verslo taisyklių sistemoms keliami reikalavimai bei nustatyta, kokius reikalavimus būtina tenkinti, o kokius ne. Antra, turi būti pabaigta pasiūlyto trigerių generavimo iš CGIF specifikacijos algoritmo realizacija bei realizuotas taisyklių modelio redagavimo komponentas. Trečia, turi būti nustatytas bei realizuotas sąsajos su duomenų modeliu būdas, nes verslo taisyklės apraše yra naudojami duomenų modelio elementai. Ketvirta, reikia atsisakyti reikalavimo naudoti kurią nors konkrečią koncepcinio modeliavimo kalbą, nes toks reikalavimas susiaurina taikymo galimybes; konkrečios modeliavimo kalbos konstrukcijų atvaizdavimas į bendrą repozitorijaus duomenų struktūrą būtų atskiras uždavinys, vykdomas specialių preprocesorių. Literatūros sąrašas [] ACT-NET Konsorciumas. The Active Database System Manifesto: A Rulebase of ADBMS Features. ACM Sigmod Record. 996, 25(30), [2] A. Arsanjani. Rule Object: A Pattern Language for Pluggable and Adaptive Business Rule Construction. Pattern Languages of Programming , ~plop/ plop2k/ proceedings/ Arsanjani/ Arsanjani.pdf, taip pat KoalaPLoP [3] A. Augustinaitis. Informacijos visuomenės profesionalumo kriterijai. Seminaro "Informacijos vadyba Lietuvoje 2000" pranešimas, 2000 gegužės 9 d., URL: padal/ kitk/ arunas/ infovi_kriterijai.htm. [4] M. Badawy, K. Richta. Deriving triggers from UML/OCL specification. Proceedings of Information Systems Development 2002, 2002 rugsėjo 2-4 d.d., Ryga, Latvija, spaudoje (Kluwer Academic Press). [5] L. Boyd. CDM RuleFrame The Business Rule Implementation Framework That Saves You Work. ODTUG 200 konferencijos pranešimų medžiaga.200, [6] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide. 2000, Addison-Wesley. [7] R. Butleris, K. Kapocius. The Business Rules Repository for Information Systems Development. Yannis Manololoulos, Pavol Navrat (eds.): ADBIS 2002, Vol. 2: Research Communications. 2002, Slovakijos Technikos Universitetas, Bratislava, [8] R. Butleris, K. Kapočius. Struktūrizuotų veiklos taisyklių saugyklos architektūra, Informacijos mokslai 200, T. 7, [9] U. Dayal, A.P. Buchmann, D.R. McCarthy. Rules are objects too: a knowledge model for active, object-oriented database management system. Advances in Object-Oriented Database Management Systems. 998, Springer-Verlag, Berlynas, [0] B. Demuth, H. Hussmann, S. Loecher. OCL as a Specification Language for Business Rules in Database Applications. M. Gogolla ir C. Kobryn, red.: UML , LNCS 285, Springer-Verlag, Berlin Heidelberg, [] V. Devedzic. A survey of modern knowledge modeling techniques. Expert Systems with Applications, 999, vol.7, No.4, [2] V. Devedzic. Knowledge Modeling - State of the Art. Integrated Computer-Aided Engineering. 200, vol.8, No.3, [3] H. Herbst, G. Knolmayer, T. Myrach, M. Schlesinger. The specification of business rules: a comparison of selected methodologies. Methods and Associated Tools for the Information System Life Cycle. 994, Verijn-Stuart, A.A., Olle T.-W., Elsevier, Amsterdamas, [4] H. Herbst, T. Myrach. A Repository System for Business Rules. R. Meersman, L. Mark (red..), Proceedings of the Sixth IFIP TC-2 Working Conference on Data Semantics, 996, Londonas, Chapman & Hall. [5] L. Jelema. CDM RuleFrame: Speaking CDM RuleSLang. ODTUG 2000 konferencijos pranešimų medžiaga. 2000, [6] A. Kolber, D. Hay, K. A. Healy, J. Hall ir kiti. GUIDE Business Rules Project, Final Report r..2. GUIDE International Corporation, 997 October, URL: [7] K. Mens, R. Wuyts, D. Bontridder, A. Grijseels. ECOOP'98 Workshop Report: Tools and Environments for Business Rules. ECOOP'98 Workshop Reader. 998, Springer-Verlag, Berlin Heidelberg. [8] G.W. Mineau, R. Missaoui, R. Godin. Conceptual modeling using conceptual graphs. Proceedings of the 7th International Workshop on Knowledge Representation meets Databases (KRDB 2000) rugpjūčio 2 d., Berlynas, Vokietija, [9] G.W. Mineau. From actors to processes: the representation of dynamic knowledge using conceptual graphs. Conceptual Structures: Theory, Tools and Applications, 6th International Conference on Conceptual Structures, ICCS ' rugpjūčio 0-2 d.d., Montpeljė, Prancūzija, Springer, Berlynas, [20] Object Management Group. Business Rules in Models, Request For Information. 2002, September, URL: [2] Rational Software Corp. media/ uml/ resources/ media/ ad970808_uml_ocl.pdf, XIV 28

31 Informacinių sistemų modeliavimas dalykinės srities žinių požiūriu [22] I. Valatkaite, O. Vasilecas. Application Domain Knowledge Modelling Using Conceptual Graphs. In Marite Kirikova (eds.) Information Systems Development Advances in Methodologies, Components and Management, Kluwer Academic/Plenum Publishers, Hardbound, December, 2002, 460 pp [23] I. Valatkaitė, O. Vasilecas. Verslo taisyklių modeliavimas koncepciniais grafais ir jų realizavimas naudojant aktyvių duomenų bazių trigerius. Lietuvos matematikos rinkinys. 2002, T.42, spec. nr., [24] I. Valatkaitė, O. Vasilecas. Žinių transformacija naudojant koncepcinius grafus. Konferencijos Informacinės technologijos 2002 pranešimų medžiaga, 2002, KTU, Technologija, [25] I. Valatkaitė. Žinių naudojimas organizacijos veikloje. Trečiosios Lietuvos jaunųjų mokslininkų konferencijos "Lietuva be mokslo - Lietuva be ateities, įvykusios Vilniuje 2000 m. balandžio 26d. spalio 6d., medžiaga. Vilnius: Technika p [26] O. Vasilecas. ECA taisyklių realizacija aktyviose duomenų bazių valdymo sistemose. Lietuvos mokslas ir pramonė. Konferencijos "Informacinės technologijos'2002" pranešimų medžiaga, Kaunas, Technologija, 2002, p Information systems modelling from domain knowledge perspective Lately the concept of knowledge became widely used in IT field not only by scientists, but also business representatives. Knowledge economy, knowledge society, knowledge management those are examples of trends in IT technologies and business development. To support knowledge usage in business information systems domain knowledge is considered to be an inherent part of information systems. But being an inherent part of information systems does not mean knowledge being modelled implicitly. On the contrary the necessity of explicit and separate domain knowledge model is widely understood and accepted. One of the most popular approaches to knowledge modelling is business rules approach. In this paper a technology of business information systems development is presented which has several components. Knowledge is modelled as business rules using conceptual graphs as modelling language. Those business rules are implemented in active database management systems as triggers thus supporting business rules repository idea. An automatic generation of triggers from business rules model in conceptual graphs is one of the most important elements of technology that significantly reduces efforts required for implementing business rules. XIV 29

32 VERSLO TAISYKLIŲ MODELIAVIMAS UML IR REALIZACIJA RELIACINĖJE DBVS Vladimir Avdejenkov Vilniaus Gedimino Technikos Universitetas, Saulėtekio al., Vilnius Irma Valatkaitė Vilniaus Gedimino Technikos Universitetas, Saulėtekio al., Vilnius Olegas Vasilecas Vilniaus Gedimino Technikos Universitetas, Saulėtekio al., Vilnius Pastaruoju metu informacinių sistemų tyrinėtojai ir praktikai daug dėmesio skiria verslo modeliavimui įvairiais požiūriais, siekdami sukurti informacinę sistemą, kuri visais reikalaujamais aspektais tinkamai remtų verslą. Šiuo požiūriu svarbu sukurti versle naudojamų taisyklių modelį ir tokių taisyklių atitinkamą projekciją informacinėje ir programų sistemoje. Darbe nagrinėjama verslo taisyklių, sumodeliuotų UML, realizacija reliacinėje aktyvioje DBVS. Analizuojamos galimybės naudoti UML verslo ir informacinių sistemų modeliavimui ir po to tokį modelį panaudoti SQL trigerių modeliavimui bei jų realizacijai. UML šiuo metu yra viena populiariausių kalbų projektuoti verslo, informacinėms bei programų sistemoms, bet jos taikymas minėtų sistemų modeliavimui vis dar nagrinėjamas. Nėra pakankamai išnagrinėtas ir UML (be OCL dalies) taikymas ECA tipo taisyklių modeliavimui. Galimybė UML modeliuoti verslo taisykles ir šį modelį realizuoti DBVS suteiktų UML dar didesnę vertę informacinių sistemų kūrimo procese. Darbe analizuojama, kokias UML diagramas tikslinga naudoti modeliuojant ir realizuojant reliacinės DB schemas ir ECA tipo taisykles. Be to, nagrinėjama, kokiais būdais informacija apie tai saugoma UML specifikacijoje. Darbe siūlomas metodas, kaip iš UML specifikacijoje esamų duomenų apie verslo taisykles galima sukurti trigerių specifikacijas ir kaip tokia specifikacija susiejama su naudojamos DB schema.. Įvadas Atsiradus aktyvių duomenų bazių valdymo sistemoms (ADBVS), programų sistemų kūrėjai įgijo priemonę, leidžiančią efektyviai valdyti ir realizuoti dalykinėje srityje naudojamas žinias bei užtikrinti duomenų bazės darną. Tai galima pasiekti naudojant trigerius arba aktyvias taisykles, kurias galima traktuoti kaip produkcinių taisyklių realizaciją DBVS. Trigeriai yra aktyvūs DBVS komponentai, kurie yra aktyvuojami susidarius tam tikroms sąlygoms ir užtikrina platų funkcionalumo spektrą, kuris apjungia darnos ribojimų realizaciją, išvestinių duomenų tvarkymą bei duomenų saugumą. Bet iki šiol trigeriai nėra plačiai naudojami kuriant programų sistemas. Viena priežasčių yra taikomųjų programų, skirtų trigerių kūrimui, trūkumas. Jeigu trigeriai yra išskirstyti duomenų bazėje ir jų yra daug, tai administruoti ir vystyti tokią trigerių sistemą yra sudėtinga ir toks procesas reikalauja didelių darbo sąnaudų. Šiuo metu trūksta priemonių, kurios leistų modeliuoti trigerius vieningu būdu, užtikrintų aktyvių taisyklių vertinimą, konfliktų nustatymą, rekursijos fiksavimą [23]. Dėl to trigerių funkcionalumas dažnai perkeliamas į dalykines programas. Pastaruoju metu atlikta daug tyrimų, kuriuose siūlomi įvairūs aktyvių taisyklių modeliavimo metodai. Tai ir koncepciniai grafai, UML ir OCL [2], [2], [22]. Be abejonės, UML [2] šiuo metu yra viena populiariausių sistemų modeliavimo priemonė. Dėl to praktiškai visos šiuolaikinės CASE priemonės palaiko UML. Priemonės, skirtos automatizuoti programinės įrangos kūrimą, irgi turi UML modelį. Tačiau UML yra sunkiai pritaikoma reliacinių duomenų modeliavimui ir projektavimui. Kai kurie CASE priemonių gamintojai iš dalies bando palaikyti reliacinių duomenų bazių modeliavimą naudojant UML. Pvz. Rational 8 sukūrė papildomą Rational Rose priemonę Data Modeler [6], kuris klasių diagramą (object model) gali transformuoti į reliacinį duomenų modelį (data model), o 8 Rational, Ratiomal software development company prekės ženklas. Rational programinė įranga Vilniaus Gedimino Technikos universitete naudojama sutinkamai su SEED sutartimi, kuri 2003 m. sausio mėnesio d. sudaryta su Rational Software Corparation. XIV 30

33 Verslo taisyklių modeliavimas UML ir jų realizavimas reliacinėje DBVS duomenų modelį gali transformuoti į DDL (Data Definition Language) kalbą, kurią jau galima naudoti fiziniam duomenų modeliui sukurti. Bet nė viena iš dabartinių CASE priemonių nesiūlo naudojant UML suprojektuoti ECA taisykles ir transliuoti jos į aktyvios DB trigerius. Šiame darbe būtent ši problema ir yra nagrinėjama, siūlomas metodas UML modelio transformacijai i ECA tipo taisyklių modelį bei tokio modelio realizacija ADBVS, bei aprašomas atliktas eksperimentas. 2. Susietų darbų apžvalga Pastaruoju metu dirbančių šioje srityje mokslininkų dėmesys skiriamas versle naudojamų žinių ir susijusių taisyklių analizei bei modeliavimui. Darbe [22] nagrinėjama galimybė koncepcinius grafus naudoti vieningam dalykinės srities duomenų struktūrų, dalykinės srities ribojimų bei dalykinės srities objektų elgsenos modeliavimui. Darbe siūlomas būdas susieti tradicinį ER modeliavimą su koncepcinių grafų modeliu naudojantis transformavimo taisyklėmis. Darbe pristatomas koncepcinių grafų formalizmas ir parodoma, kad visų tipų dalykinės srities žinias galima modeliuoti koncepciniais grafais. Taip pat pristatomas metodas transformuoti žinias iš ER modelio į modelį koncepciniais grafais. Šiuo metu plačiai tiriami būdai modeliuoti ECA taisykles naudojant įvairias koncepcinio modeliavimo kalbas, tai pat ir UML taikymo duomenų modeliavimui problemos. Šioje srityje atlikta nemažai tyrimų ir įvairiuose darbuose nagrinėjama galimybė gauti duomenų bazių modelį naudojant UML specifikaciją [5], generuoti reliacinės DBVS trigerius, naudojant UML/OCL specifikacijas [2]. Darbe [5] aprašytas UML modelio transformavimų eksperimentas. Transformacijai naudojama XMI (XML Metadata Interchange) specifikacija [4], kurią OMG (Object Management Group) apibrėžė kaip skirtą lengvai apsikeisti duomenimis ir metaduomenimis tarp skirtingų UML naudojimo priemonių ir metaduomenų saugyklų, naudojančių OMG UML specifikaciją. Darbe [5] nagrinėjamas reliacinės duomenų bazės modelio gavimas iš UML diagramų (klasių diagrama), naudojant XMI specifikaciją. Pirmiausiai CASE modeliavimo priemonės pagalba gaunama UML modelio XMI specifikacija. Transformacijos aprašomos XSLT (Extensible Stylesheet Language Transformations) [25] taisyklių rinkinio pagalba. Programa (transliatorius) analizuoja XMI specifikaciją, XSLT taisyklių rinkinį ir generuoja SQL DDL (Data Definition Language) kodą. Šio proceso eiga yra parodyta paveiksle. pav. XMI specifikacijos transformavimas [3]. Straipsnio [2] autoriai nagrinėja galimybę pagal tą pačią schemą, ir papildomai naudojant OCL (Object Constraint Language) [6], [20], aprašyti ir transliuoti taip pat ir duomenų bazės darnos palaikymo taisykles, tačiau nepasiūlo konkretaus realizavimo metodo. OCL naudojimas duomenų bazės darnos palaikymui yra aprašomas ir darbe [2]. Siūlomas SQL trigerių gavimo metodas iš UML/OCL specifikacijos. Darbe apsiribojama tik darnos palaikymo trigeriais. Autoriai teigia, kad kitų trigerių tipų gavimas šiuo metodu yra neįmanomas. Pagal aprašytą metodą yra analizuojama OCL užrašyti tam tikro tipo ribojimai, kurie vėliau gali būti transliuojami į SQL trigerio specifikaciją. Paminėtuose darbuose nagrinėjamas arba tik duomenų modelio gavimas arba DBVS trigerių, skirtų tik darnos duomenų bazėje užtikrinimui, gavimas. Pirmasis atvejis (duomenų modelio gavimas) yra pakankamai gerai ištirtas ir egzistuoja gerai žinomos šio metodo realizacijos. Pavyzdžiui, Data Modeler (speciali Rational Rose modeliavimo priemonės komponentė), leidžiantis UML diagramų pagalba aprašyti duomenų modelį (forward engineering), arba atvirkščiai duomenų modelį paversti UML diagrama (reverse engineering). Antruoju atveju (darnos užtikrinimo trigeriai) autoriai apsiriboja tik vienu trigerių tipu duomenų bazės ribojimų tikrinimui ir nenagrinėja kitų trigerių, kurie realizuoja ECA tipo taisykles. Tokio tipo taisyklės modelį DB aplinkoje bandoma realizuoti ir darbe [7]. Paprastai verslo taisyklė yra suprantama kaip teiginys, kuris apibrėžia ar riboja kurį nors verslo aspektą; jos paskirtis yra nusakyti verslo struktūrą, taip pat kontroliuoti ar įtakoti verslo elgseną [7]. Būtent verslo taisyklės yra XIV 3

34 V.Avdejenkov, I.Valatkaitė, O.Vasilecas sudėtingiausios modeliavimo bei realizavimo požiūriais, nes jos apibrėžia visus versle naudojamus veiklos bei skaičiavimų algoritmus. Šiame darbe, siekiant supaprastinti uždavinį, bus apsiribuota tokia verslo taisyklė, kuri programų sistemoje gali būti pavaizduota kaip ECA tipo taisyklė. Šiame darbe yra siūlomas metodas, kuri naudojant UML užrašytą dalykinės srities tam tikro tipo verslo taisyklių modelis transformuojamas į reliacinės DB struktūrą ir ADBVS trigerius. ADBVS trigeris, šiuo atveju, realizuos versle naudojama taisyklę. Tokiu būdu bus išplėstos UML pritaikymo galimybės - ne tik duomenų modeliavimui, bet ir verslo taisyklių modeliavimui bei realizacijai. 3. UML specifikacijos kūrimo ir transformavimo analizė 3.. UML specifikacijos analizė Bet kuri kalba yra informacijos saugojimui ir perdavimui skirta ženklų sistema. Kalbos būna formalios, kurių naudojimo taisyklės yra griežtai apibrėžtos, ir neformalios, kurių naudojimo taisyklės susikūrė savaime, natūraliai. Kalbas taip pat galima skirstyti į dirbtines (specialiai sukurtas) ir natūralias (kurios susikūrė pačios). Pavyzdžiui, kalba, kuria parašytas šis straipsnis (lietuvių kalba) yra neformali ir natūrali. Bet praktiškai visos programavimo kalbos yra formalios ir dirbtinės. UML galima charakterizuoti kaip formalią ir dirbtinę (nors ji nėra tiek formali kaip programavimo kalbos). UML dirbtinė kalba, ir jos autoriai G. Booch, I. Jacobson, ir J. Rumbaugh plačiai žinomi [3]. UML yra formali, bet yra ir neformalių dalykų. Manoma, kad formali dirbtinė kalba yra gerai aprašyta, jei joje apibrėžtos trys dalys: Sintaksė, t.y. kalbos konstravimo taisyklių apibrėžimas; Semantika, t.y. apibrėžimas, kaip kalbos frazėms yra priskiriama prasmė; Pragmatika, t.y. apibrėžimas, kaip kalbos frazės naudojamos pasiekti tikslą. UML formali ir dirbtinė turi semantiką, sintaksę ir pragmatiką, nors šios dalys kai kuriais atvejais pavadintos ir aprašytos kitaip, negu priimta programavimo kalbose. Taigi, UML apibrėžia: Elementus, kurie sudaro semantikos modelį (semantika); Notaciją, skirtą vizualiam modelio elementų pateikimui (sintaksė); Naudojimo taisykles (pragmatika). UML apibrėžti kalbos koncepcijos išplėtimo ir specializavimo mechanizmai. UML neapibrėžia ir nenurodo: Programavimo kalbos UML yra semantinis modelis, kuris lengvai pernešamas į bet kokį objektiškai orientuotą modelį, bet nepriklauso nuo konkrečios realizavimo kalbos. Instrumentus UML nekelia reikalavimų CASE priemonėms, padarytoms UML pagrindu ir neapibrėžia jų naudojimo. Bet instrumentas, palaikantis UML, turi tiksliai atitikti kalbos semantiką. Kūrimo procesas kūrimo proceso apibrėžimas nebuvo autorių tikslas, UML specialiai buvo padaryta nepriklausoma nuo kūrimo proceso. Visos pagrindinės UML modeliavimo koncepcijos apibrėžtos UML specifikacijoje kaip modelio elementai (ModelElement), pradedant nuo tokiomis konkrečiomis kalbos konstrukcijomis kaip klasė, ir baigiant tokiais modelio elementais kaip panaudojimo variantai (Use Case). Taigi, UML modeliavimo kalbos pagalba galima modeliuoti įvairias sistemas. Mūsų uždavinys yra UML sumodeliuoti ECA taisyklę ir transformuoti ją į aktyvią RDBVS taisyklę. Klasių diagrama naudojama modelio statinės struktūros aprašymui. Ji puikiai tinka duomenų bazės loginio modelio užrašymui. Lentelėje parodyta, kaip loginis modelis atitinka fizinį: lentelė. Loginio duomenų modelio atvaizdavimas į fizinį reliacinės DB modelį Loginis modelis Class (Klasė) Operation (Operacija) Attribute (Atributas) Package (Paketas) Component (Komponentas) Association (Asociacija) Nėra Nėra Fizinis modelis Table (Lentelė) Constraint (Apribojimas) Column (Stulpelis) Scheme (Schema) Database (Duomenų bazė) Relationship (ryšis) Trigger (Trigeris) Index (Indeksas) XIV 32

35 Verslo taisyklių modeliavimas UML ir jų realizavimas reliacinėje DBVS Kaip matome, trigerio atitikties loginiame UML modelyje nėra. Trigeris yra aktyvus DBVS elementas, kuris bendru atveju aprašo sistemos elgseną. Tokį elementą galima aprašyti tokių UML diagramų pagalba, kurios aprašo sistemos elgseną. UML sistemos elgsenai aprašyti naudojamos procesų (activity) ir būsenų (statechart) diagramos. Tokiu atveju ECA taisyklei modeliuoti mes galėsime naudoti būtent šias diagramas. Taigi, galima padaryti išvadą, kad duomenų bazės modeliui aprašyti užtenka klasių diagramos, o ECA taisyklės aprašomos procesų ir būsenų diagramų pagalba. Tokio diagramų rinkinio užtenka ECA taisyklių modeliavimui SQL trigerio analizė Reliacinės ADBVS trigeriai yra aktyvūs DBVS elementai, kurie aktyvuojami susidarius tam tikroms sąlygoms ir užtikrina platų funkcionalumo spektrą nuo darnos palaikymo iki sudėtingų versle naudojamų taisyklių realizavimo [23]. ECA taisyklės (trigeriai) ADBVS sistemose gali būti skirti kelių tipų užduotims:. Užtikrinti duomenų bazės darną (integrity); 2. Užtikrinti taisyklių realizaciją; 3. Nustatyti sudėtingas reikšmes pagal nutylėjimą; 4. Apdoroti dublikatus. Trigerį galima nagrinėti kaip ECA taisyklės realizaciją, kurios pagrindinės dalys yra: įvykis (Event), sąlyga (Condition) ir veiksmas (Action). Tai yra, trigeris reaguoja į kurį nors nustatytą įvykį (Event), patikrinama sąlyga (Condition) ir priklausomai nuo sąlygos tikrinimo rezultato atliekamas veiksmas (Action). Galimi trys įvykio variantai: eilutės įterpimas (INSERT), eilutės trynimas (DELETE) arba eilutės atnaujinimas (UPDATE). Jeigu įvyko nustatytas įvykis, yra tikrinama sąlygą: tai gali būti įrašytų ar ištrintų duomenų patikrinimas, duomenų iš kitų lentelių patikrinimas ir t.t. Priklausomai nuo sąlygos patikrinimo rezultato atliekamas veiksmas: tai gali būti bet kokia SQL kalbos komanda: transakcijos atšaukimas, duomenų pakeitimas tiek bazinėje lentelėje, tiek bet kurioje kitoje lentelėje, pranešimų siuntimas. MS SQL 2000 trigerio sintaksė [9] apibrėžiama taip: CREATE TRIGGER trigger_name ON { table view } [ WITH ENCRYPTION ] { { { FOR AFTER INSTEAD OF } { [ INSERT ] [, ] [ UPDATE ] [,] [DELETE] } [ WITH APPEND ] [ NOT FOR REPLICATION ] AS [ { IF UPDATE ( column ) [ { AND OR } UPDATE ( column ) ] [...n ] IF ( COLUMNS_UPDATED ( ) { bitwise_operator } updated_bitmask ) { comparison_operator } column_bitmask [...n ] } ] sql_statement [...n ] } } Šioje specifikacijoje: trigger_name nurodo trigerio vardą, kuriuo jis identifikuojamas duomenų bazėje; table view nurodo lentelės ar rodinio pavadinimą, kuriai veikia trigeris; [ INSERT ] [, ] [ UPDATE ] [, ] [DELETE] įvykiai, kuriems įvykus aktyvuojamas trigeris. Galima nurodyti nuo vieno iki trijų įvykių; IF UPDATE ( column ) tikrinama sąlyga, ar pakeistas nurodytas stulpelis; sql_statement [...n ] veiksmas (SQL kalbos komandos), vykdomas patikrinus sąlygą Transformacijos analizė Modelių transformacijos problema yra aktuali ir plačiai nagrinėjama, pavyzdžiui, [0]. UML tai pat galima panaudoti modelių transformacijai, nors jos pagrindinė paskirtis yra sistemų modeliavimas. Dėl to dauguma dabartinių CASE priemonių palaiko UML. Priemonės, skirtos programinės įrangos kūrimo proceso automatizavimui, savyje turi kuriamos sistemos UML modelio atvaizdavimą, kuris skiriasi nuo apibendrinto schemų atvaizdavimo. XIV 33

36 V.Avdejenkov, I.Valatkaitė, O.Vasilecas Bet koks produktas, palaikantis modeliavimą UML, turi savo modelio atvaizdavimą. Populiariausi tokie produktai yra Rational Rose [6], Together Control Center [9], MS Visio Enterprise [8], ArgoUML []. Išanalizavus šiuos produktus, galima padaryti išvadą, kad jų kūrėjai daugiausiai dėmesio skirdavo diagramų braižymo proceso tobulinimui, o ne UML semantikai. Rolf W. Rasmussen savo darbe [5] charakterizavo tokias priemones kaip bandymą gaminti maistą žiūrint į knygos nuotraukas, o ne gaminti tiksliai pagal receptus. Svarbu suprasti, kad UML diagramos yra tik modelio projekcijos ir tarp diagramų ir modelio nėra vienareikšmiško ryšio. Be abejo, diagramos irgi yra labai svarbios, bet svarbesnis yra visas modelis, kuris ir yra pagrindinis sistemos modeliavimo artefaktas. Naudojant išsamu sistemos modelį galima daryti papildomus veiksmus, pavyzdžiui, generuoti programinį kodą, analizuoti sistemos modelio sudėtingumą. Šis procesas pavaizduotas 2 paveiksle. Java VB DB schema Verslo sistema Verslo taisykles UML modelis Taisykliu modelis DB trigeris XMI specifikacija 2 pav. UML modelio panaudojimas Nuo UML versijos.3 standartas apibrėžia modelio pateikimą teksto formatu [3]. XML metaduomenų apsikeitimo formatas (XMI) yra pasiūlytas Object Management Group (OMG). Pagrindine XMI paskirtys leisti lengvai keisti duomenimis ir metaduomenimis tarp UML modeliavimo įrankių ir metaduomenų saugyklų. XMI sukurtas remiantis trimis standartais:. XML extensible Markup Language W3C standartas [24] apibrėžia universalų formatą struktūrizuotems dokumentams ir duomenims Internete; 2. UML Unified Modeling Language, OMG modeliavimo standartas [3], skirtas objektinių sistemų modeliavimui; 3. MOF Meta Object Facility, su COBRA standartu suderinta architektūra, skirta dalintis semantiniais metaduomenimis išskirstytose heterogeninėse aplinkose naudojant OMG modeliavimo ir metaduomenų saugyklos standartus []. Savo eksperimentui mes pasirinkom Rational Rose UML modeliavimo priemonę. Tai padaryta dėl įvairių priežasčių, bet pagrindinės yra dvi: Rational Rose paketo tinkamumas ir legalios versijos buvimas VGTU informacinių sistemų mokslo laboratorijoje bei XMI specifikacijos palaikymas. Taip pat reikia paminėti priemonę, esančią Rose paketo sudėtyje, Data Modeler, kuri skirta gauti reliacinį duomenų modelį iš UML diagramų. Naudojant šią priemonę mes palengviname sau užduotį reliacinis duomenų modelį gaunamas tiesiai iš UML specifikacijos. Tuo būdu lieka uždavinys iš veiklos (activity) diagramų specifikacijos XMI formatu sugeneruoti ADBVS trigerį. XIV 34

37 Start [ ='0' ] Operacijos irasymas entry/ ^Operacijos.INSERT exit/ ^INSERTED.OperacijosTipas exit/ ^INSERTED.PrekesKodas exit/ ^INSERTED.SandelioNmeris exit/ ^INSERTED.SandelioKiekis SND Gavimas entry/ ^Prekes.UPDATE(PrekesKodas=PrekesKodas) exit/ ^Prekes.UPDATE(PrekesLikutis=PrekesLikutis+OperacijosKiekis) SND Isdavimas entry/ ^Prekes.UPDATE(PrekesKodas=PrekesKodas) exit/ ^Prekes.UPDATE(PrekesLikutis=PrekesLikutis-OperacijosKiekis) END Verslo taisyklių modeliavimas UML ir jų realizavimas reliacinėje DBVS 4. SQL trigerio specifikacijos generavimo iš UML specifikacijos metodas 4.. Metodo aprašymas Išanalizavus UML specifikaciją, trigerio specifikaciją, o taip pat atsižvelgus į atliktos analizės rezultatus galime pasiūlyti SQL trigerio iš UML specifikacijos gavimo metodą. Šį procesas bendru atveju pavaizduotas 3 paveiksle. UML diagramos OperacijosTipas [ ='00' ] Veiklos diagrama Prekes PrekesKodas PrekesPavadinimas PrekesLikutis PrekesKaina Klasių diagrama Data Modeler n Sandeliai PrekesKodas SandelioNr SandelioLikutis n n Operacijos OperacijosTipas SandelioNr OperacijosData PrekesKodas OperacijosNumeris OperacijosKaina OperacijosKiekis XMI eksportas XMI specifikacija MSSQL 2000 Trigeris <UML:Diagram xmi.id = 'S.22' name = 'Trigger_Name' diagram CREATE TRIGGER Trigger_Name Type = 'ActivityDiagram' style = '' > ON { table view } <UML:Action.target> <UML:ObjectSetExpression language = '' body = 'Table view' /> { { FOR AFTER INSTEAD OF } { [ </UML:Action.target> INSERT ] [, ] [ UPDATE ] } <UML:SendAction xmi.id = 'XX.8' name = 'INSERT' <UML:SendAction xmi.id = 'XX.4' name = 'UPDATE' visibility = 'public' isspecification = 'false' isasynchronous = 'false' > <UML:Action.recurrence> <UML:IterationExpression language = '' body = '' /> </UML:Action.recurrence> <UML:Action.target> <UML:ObjectSetExpression language = '' body = 'Statment' /> </UML:Action.target> <UML:Action.script> <UML:ActionExpression language = '' body = '' /> </UML:Action.script> <UML:SendAction.signal> <Behavioral_Elements. Common_Behavior.Signal xmi.idref = 'G.20'/> Transformacijos [ { IF UPDATE ( column ) [ { AND OR } UPDATE ( column ) ] [...n ] { sql_statement [...n ] } Taisyklė Įvykis Sąlyga Veiksmas RDB shema 3 pav. SQL trigerio iš UML gavimo metodas Procese dalyvauja dvejų tipų diagramos: klasių ir veiklos. Klasių diagrama naudojama modeliuoti duomenų struktūrą, o veiklos diagrama naudojama modeliuoti verslo taisyklę. Klasių diagrama Data Modeler priemonės pagalba transformuojama į reliacinės duomenų bazės schemą, o veiklos diagramą išsaugojama XMI formatu. Gautas XMI tekstas yra analizuojamas ir atliekant transformacijas gaunamas SQL trigeris Eksperimentas Eksperimentui sukursime pasirinktos dalykinės srities atsargų valdymo duomenų struktūrą ir apibrėšime objektų elgseną. Atsargų valdymas skirtas buhalterinei prekių apskaitai. Kadangi eksperimento tikslas yra parodyti, kaip veikai pasiūlytasis metodas, dalykinę sritį supaprastinome. Duomenų struktūra apibrėžiama trimis lentelėmis: prekės, sandėliai ir operacijos. Pirmojoje lentelėje laikoma informacija apie prekes (kodas, pavadinimas, kaina ir t.t.), antrojoje sandėlių informacija (sandėlio numeris, prekės kodas ir informaciją apie prekės likutį sandėlyje), trečiojoje lentelėje saugoma informacija apie įvykusias operacijas (operacijos numeris, prekės kodas, sandėlio numeris, operacijos tipas ir t.t.). Verslo taisyklė apibrėžiama taip: kai sandėlyje įvyksta operacija, pvz., prekių gavimas (00 tipo operacija) arba prekių išdavimas (0 tipo operacija), prekių kiekis atitinkamam sandėlyje turi mažėti arba didėti. Galutinis prekių likutis lentelėje prekės turi taip pat mažėti arba didėti. Rational Rose UML modeliavimo priemonės pagalba modeliuojame klasių (class) ir procesų (activity) diagramas. Klasių diagrama (žr. 4 paveikslą) skirta duomenų modeliui sukurti. Sukurta klasių diagrama naudojant Data Modeler yra transformuojama į objektų modelį (object model) ir į duomenų modelį (data model), kurio pagalba sukuriamas DDL (Data Definition Language) skriptas. Sistemos elgsenai vaizduoti naudojama veiklos (activity) diagrama. Aukščiau aprašytos, nagrinėjamame versle naudojamos, ECA tipo taisyklės modelis naudojant veiklos diagrama pavaizduotac 5 paveiksle. XIV 35

38 V.Avdejenkov, I.Valatkaitė, O.Vasilecas Prekes PrekesKodas PrekesPavadinimas PrekesLikutis PrekesKaina n Sandeliai PrekesKodas SandelioNr SandelioLikutis n n Operacijos 4 pav. Klasių diagrama. Operacijos Tipas SandelioNr O Operacijos irasymas entry/ ^Operacijos.INSERT exit/ ^INSERTED.OperacijosTipas exit/ ^INSERTED.PrekesKodas exit/ ^INSERTED.SandelioNr exit/ ^INSERTED.OperacijosKiekis OperacijosTipas [ ='00' ] [ ='0' ] SND Gavimas entry/ ^Prekes.UPDATE(PrekesKodas=PrekesKodas) exit/ ^Prekes.UPDATE(PrekesLikutis=PrekesLikutis+OperacijosKiek... SND Isdavimas entry/ ^Prekes.UPDATE(PrekesKodas=PrekesKodas) exit/ ^Prekes.UPDATE(PrekesLikutis=PrekesLikutis-OperacijosKiekis) 5 pav. Veiklos diagrama Ši diagrama išsaugoma XMI formatu. Kad lengviau būtų dirbti su duomenimis, analizuodami diagramą XMI formatu, mums reikalingus duomenis talpiname į tarpinių duomenų saugyklą, kuria sudaro tokios lenteles: Analizuojant duomenų saugykloje esamą informaciją apie ECA taisyklę, ji yra transformuojama į SQL trigerio specifikaciją. Šis procesas schematiškai pavaizduotas 6 paveiksle. XIV 36

39 Verslo taisyklių modeliavimas UML ir jų realizavimas reliacinėje DBVS Lentelė. Diagrama Pavadinimas DiagramXMIID DiagramName DiagramType Kontekstas Diagramos identifikatorius pagal XMI Diagramos pavadinimas Diagramos tipas Lentelė 2. Diagramos elementas Pavadinimas DiagramXMIID DiagramElementXmiID DiagramElementXmiIDRef DiagramElementName DiagramElementType Lentelė 3. Ryšių lentelė Pavadinimas DiagramElementXmiIDRef Outgoing Incoming Kontekstas Diagramos identifikatorius, kuriai priklauso diagramos elementas Diagramos elemento identifikatorius pagal XMI Diagramos elemento identifikatorius pagal XMI nuorodas Diagramos elemento pavadinimas Diagramos elemento tipas Kontekstas Diagramos elemento identifikatorius pagal XMI nuorodas Išeinančio perėjimo identifikatorius Įeinančio perėjimo identifikatorius Lentelė 4. ActionState būsenų lentelė Pavadinimas DiagramElementXmiID SendActionXmiID SendActionName SendActionTarget StateType Kontekstas Diagramos elemento identifikatorius pagal XMI Diagramos elemento veiksmo identifikatorius pagal XMI Diagramos elemento veiksmo pavadinimas Diagramos elemento veiksmo objektas Diagramos elemento veiksmo būsenos tipas n Sandeliai Prekes PrekesKodas PrekesKodas SandelioNr PrekesPavadinimas SandelioLikutis PrekesLikutis PrekesKaina n n Operacijos OperacijosTipas SandelioNr OperacijosData PrekesKodas OperacijosNumeris OperacijosKaina OperacijosKiekis UML klasių diagrama Operacijos irasymas Start entry/ ^Operacijos.INSERT exit/ ^INSERTED.OperacijosTipas exit/ ^INSERTED.PrekesKodas exit/ ^INSERTED.SandelioNmeris exit/ ^INSERTED.SandelioKiekis SND Isdavi mas OperacijosTipas [ ='00' ] entry/ ^Prekes.UPDATE(PrekesKodas=PrekesKodas) exit/ ^Prekes.UPDATE(PrekesLikutis=PrekesLikutis-OperacijosKiekis) [ ='0' ] SND Gavimas entry/ ^Prekes.UPDATE(PrekesKodas=PrekesKodas) exit/ ^Prekes.UPDATE(PrekesLikutis=PrekesLikutis+OperacijosKiekis) END UML veiklos diagrama Rational Rose Specifikacija quidu "3D98DBB005" compartment (object Compartment location (830, 62) font (object Font size 0 face "Arial" charset 86 color 0 default_color TRUE) icon_style "Icon" fill_color anchor 2 nlines 2 max_width 28 compartmentitems (list Compartment "entry/ ^Prekes.UPDATE(PrekesKodas=PrekesKodas)" "exit/ ^Prekes.UPDATE(PrekesLikutis=PrekesLikutis-Op eracijoskiekis)")) XMI Specifikacija <UML:SendAction xmi.id = 'XX.9' name = 'OperacijosTipas' visibility = 'public' isspecification = 'false' isasynchronous = 'false' > <UML:Action.recurrence> <UML:IterationExpression language = '' body = '' /> </UML:Action.recurrence> <UML:Action.target> <UML:ObjectSetExpression language = '' body = 'INSERTED' /> </UML:Action.target> <UML:Action.script> <UML:ActionExpression language = '' body = '' /> </UML:Action.script> <UML:SendAction.signal> <Behavioral_Elements.Common_Behavior.Signal xmi.idref = 'G.6'/> </UML:SendAction.signal> </UML:SendAction> MSSQL 2000 Trigerio specifikacija CREATE TRIGGER NaujaOperacija ON dbo.operacijos FOR INSERT AS varchar decimal = =SandelioNr,@PrekesKodas = OperacijosKiekis FROM INSERTED = '00' BEGIN UPDATE Prekes SET prekeslikutis = prekeslikutis WHERE PrekesKodas=@Prekeskodas; UPDATE Sandeliai SET SandelioLikutis = SandelioLikutis WHERE PrekesKodas=@Prekeskodas and SandelioNr=@sandelioNr; End = '0' BEGIN UPDATE Prekes SET prekeslikutis=prekeslikutis-@operacijoskiekis WHERE PrekesKodas=@Prekeskodas; UPDATE Sandeliai SET SandelioLikutis = SandelioLikutis WHERE PrekesKodas=@Prekeskodas and SandelioNr=@sandelioNr; End Return MSSQL 2000 DDL instrukcijos CREATE TABLE Sandeliai ( SandelioNr CHAR ( 2 ), PrekesKodas VARCHAR ( 0 ), SandelioLikutis DECIMAL ( 8 ) ) ON [PRIMARY] GO CREATE TABLE Prekes ( PrekesKodas VARCHAR ( 0 ) NOT NULL, PrekesPavadinimas VARCHAR ( 50 ), PrekesLikutis DECIMAL ( 8 ), PrekesKaina MONEY, CONSTRAINT PK_Prekes PRIMARY KEY CLUSTERED (PrekesKodas) ) GO CREATE TABLE Operacijos ( OperacijosTipas CHAR ( 2 ), SandelioNr CHAR ( 2 ), OperacijosData DATETIME, PrekesKodas VARCHAR ( 0 ), OperacijosNumeris VARCHAR ( 0 ) NOT NULL, OperacijosKaina MONEY, OperacijosKiekis DECIMAL ( 8 ), CONSTRAINT PK_Operacijos PRIMARY KEY CLUSTERED (OperacijosNumeris) ) GO 6 pav. SQL trigerio iš UML gavimo procesas XIV 37

40 V.Avdejenkov, I.Valatkaitė, O.Vasilecas 4.3. Gauti rezultatai Atlikus visus aprašytus veiksmus gauname SQL specifikaciją, kuri būvo panaudota generuojat ADBVS MS SQL Server fizinį duomenų modelį: CREATE TABLE Sandeliai ( GO SandelioNr CHAR ( 2 ), PrekesKodas VARCHAR ( 0 ), SandelioLikutis DECIMAL ( 8 ) ) ON [PRIMARY] CREATE TABLE Prekes ( GO PrekesKodas VARCHAR ( 0 ) NOT NULL, PrekesPavadinimas VARCHAR ( 50 ), PrekesLikutis DECIMAL ( 8 ), PrekesKaina MONEY, CONSTRAINT PK_Prekes PRIMARY KEY CLUSTERED (PrekesKodas) ) CREATE TABLE Operacijos ( GO OperacijosTipas CHAR ( 2 ), SandelioNr CHAR ( 2 ), OperacijosData DATETIME, PrekesKodas VARCHAR ( 0 ), OperacijosNumeris VARCHAR ( 0 ) NOT NULL, OperacijosKaina MONEY, OperacijosKiekis DECIMAL ( 8 ), CONSTRAINT PK_Operacijos PRIMARY KEY CLUSTERED (OperacijosNumeris) ) Gauta trigerio, realizuojančio nagrinėjamą taisyklę, SQL specifikacija yra tokia: CREATE TRIGGER NaujaOperacija ON dbo.operacijos FOR INSERT AS varchar decimal = =SandelioNr,@PrekesKodas = OperacijosKiekis FROM INSERTED = '00' BEGIN UPDATE Prekes SET prekeslikutis = prekeslikutis WHERE PrekesKodas=@Prekeskodas; UPDATE Sandeliai SET SandelioLikutis = SandelioLikutis WHERE PrekesKodas=@Prekeskodas and SandelioNr=@sandelioNr; End = '0' BEGIN UPDATE Prekes SET prekeslikutis=prekeslikutis-@operacijoskiekis WHERE PrekesKodas=@Prekeskodas; XIV 38

41 Verslo taisyklių modeliavimas UML ir jų realizavimas reliacinėje DBVS UPDATE Sandeliai SET SandelioLikutis = SandelioLikutis WHERE PrekesKodas=@Prekeskodas and SandelioNr=@sandelioNr; End Return 5. Išvados ir tolimesni tyrimai Šiame darbe išnagrinėta galimybė naudoti UML verslo taisyklių modeliavimui bei jų realizacijai ADBVS. Atlikta analizė parodė, kad UML galima modeliuoti versle naudojamas ECA tipo taisykles ir gautą modelį naudoti SQL ir trigerių specifikacijų generavimui. Tokiu būdu galima vieningu būdu modeliuoti ne tik duomenų struktūrą, bet ir ADBVS trigerius. Tolimesnio darbo užduotys būtų ištirti galimybę naudojant UML modeliuoti bei realizuoti ne tik atskiras ir tam tikro tipo verslo taisykles, o įvairių taisyklių sistemas. Tokiose taisyklių sistemose iškylą ir papildomos problemos, kurias galima spręsti analizuojant UML modelį. Tai tame skaičiuje taisyklių sudėtingumo vertinimas, konfliktų ir tarpusavio priklausomybių problemų sprendimas, taisyklių galutinio užbaigimo problema. Literatūros sąrašas [] ArgoUML. Open Source Software Engineering [2] M. Badawy, K. Richta. Deriving triggers from UML/OCL specification, In Marite Kirikova (eds.) Information Systems Development Advances in Methodologies, Components and Management, Kluwer Academic/Plenum Publishers, Hardbound, December, 460 pp [3] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 999. [4] M. Dahm, Grammar and API for Rational Rose petal files. July 9, [5] B. Demuth, H. Hussmann, Sven Obermaier. Experiments With XMI Based Transformations of Software Models, WTUML: Workshop on Transformations in UML, ETAPS 200 Satellite Event, Genova, Italy, April 7th, 200 [6] D. Didier, V. Jean-Marc, J ez equel. OCL as a Core UML Transformation Language WITUML 2002 Position Paper 8th April [7] E. Gottesdiener. Business rules show power and promise, Application Programming Trends, 4(3) (997). [8] Home Page for Microsoft Visio [9] E. Mamaev. Microsoft SQL Server CPb.: BXB-Peterburg, 200 [0] P. McBrien, A. Poulovassilis. A Uniform Approach to Inter-Model Transformations; Dept of Computer Science, King s College London, Strand, London WC2R 2LS [] OMG. Meta Object Facility (MOF.3) Specification ( ) [2] OMG. Unified Modeling Language (UML). [3] OMG. Unified Modeling Language Revision Task Force. Unified Modeling Language Specification. Version.3, June 999. [4] OMG. XML Metadata Interchange (XMI) Specification. Version.2, [5] R. Rasmussen. A framework for the UML meta model. University of Bergen, [6] Rational. The UML and Data Modeling Rational software Whitepaper. [7] J. Reinert, N. Ritter. Applying ECA Rules in DB-based Design Environments Tagungsband CAD 98 "Tele-CAD - Produktentwicklung in Netzen", März 998, Informatik Xpress 9, pp [8] S. Sendall, A. Strohmeier. Using OCL and UML to Specify System Behavior. Object Modeling with the OCL 2002: pp [9] Together Control Center [20] UML Object Constraint Language (OCL) ANTLR Grammar [2] I. Valatkaite, O. Vasilecas. Application Domain Knowledge Modelling Using Conceptual Graphs. In Marite Kirikova (eds.) Information Systems Development Advances in Methodologies, Components and Management, Kluwer Academic/Plenum Publishers, Hardbound, December, 460 pp [22] I. Valatkaitė, O. Vasilecas. Verslo taisyklių modeliavimas koncepciniais grafais ir jų realizavimas naudojant aktyvių duomenų bazių trigerius, Lietuvos matematikos rinkinys, T.42, spec. nr., p [23] O. Vasilecas. ECA taisyklių realizacija aktyviose duomenų bazių valdymo sistemose. Lietuvos mokslas ir pramonė. Konferencijos "Informacinės technologijos'2002" pranešimų medžiaga, Kaunas, Technologija, 2002, p XIV 39

42 V.Avdejenkov, I.Valatkaitė, O.Vasilecas [24] W3C. Exstensible Markup Language (XML) [25] W3C. XSL Transformations (XSLT). Recommendation 6 November Business rules modeling Using uml and rules enforsing in relational databases In information systems research field a lot of efforts are directed towards business modeling pursuing the goal to develop such information systems that supported real business in the most coherent way. To achieve this goal it is vitally important to have business rules model and its implementation in information system. In this paper a method is proposed how to enforce business rules in information systems in automatic way thus reducing efforts required to develop such information system. The modeling language used is UML because of its expressive power and CASE tools support. The research of UML and OCL usage for business modeling is a hot topic currently. In this paper it is shown that UML alone (without OCL) can be successfully applied for domain modeling if business rules approach is used for information system development. Business rules can be modeled as ECA rules and it is possible to implement those as triggers in active relational DBMS. The proposed method utilizes textual UML format XMI that is translated to active DBMS trigger specification. This way UML gains even more power as a conceptual modeling language for various business domains with abilities to exploit business rules modeling approach. XIV 40

43 INFORMACIJOS SRAUTŲ SPECIFIKACIJOS GYVAVIMO CIKLAS IS PROJEKTAVIMO PROCESE Rimantas Butleris, Tomas Danikauskas Kauno technologijos universitetas, Informacijos sistemų katedra Studentų , LT-303, Kaunas Informacijos srautų specifikacija sudaroma į sistemą įeinančių ir iš jos išeinančių informacinių srautų analizės pagrindu. Tam, kad pasinaudoti šia specifikacija, ji saugoma specializuotoje saugykloje. Informacijos srautų specifikacijos parengimas iteratyvus daugiaetapis procesas, kuomet kiekvienos iteracijos metu saugykloje išsaugoma nauja arba patikslinama esanti informacija. Atskirus specifikacijos sudarymo etapus galima susieti su atskirais informacijos sistemos (IS) projektavimo proceso etapais. Išbaigtos specifikacijos panaudojimas priimant IS projektinius sprendimus turi užtikrinti sklandesnį ir spartesnį IS realizavimo procesą.. Įvadas Didėjant IT rinkos konkurencingumui pagrindiniai faktoriai, nulemiantys rinkos lyderius, yra našumas, kokybė bei sukurto produkto kaina. Norint išlaikyti šiuos faktorius ties rinkos užduota kartele nepakanka turėti geriausius programuotojus, išmanančius naujausias technologijas. Vienas esminių dalykų yra pasiruošimas IS programiniam realizavimui, t.y. reikalavimų specifikavimas ir projektavimas. Abu šiuos darbus galima atlikti rankiniu būdu. Bet tai neužtikrins galimybės aukščiau paminėtus faktorius išlaikyti ties norima riba. Tam reikia pasitelkti automatizuotas sistemų kūrimo priemones (CASE). Kiekvienas CASE įrankis yra realizuotas tam tikro metodo pagrindu. Vienas jų yra informacijos sistemai keliamų funkcinių reikalavimų specifikavimo metodas [], pasižymintis šiomis savybėmis: reikalavimų informacijos sistemai išgavimo ir specifikavimo eiga yra artima natūraliai, t.y. atitinka tradicinę šio proceso veiksmų seką; metodas minimizuoja atotrūkį tarp vartotojo ir analitiko jų bendravimo metu rengiamos reikalavimų specifikacijos struktūros abipusio supratimo bei specifikavimo proceso natūralumo aspektais; modeliavimo procesas užtikrina organizacijos veiklos ar jos išskirto konteksto modelio pilnumą. Tam, kad metodą būtų galima naudoti IS projektavimo procese, jo pagrindu sudaromai specifikacijai saugoti turi būti sukurta saugykla. Saugyklos užpildymo procesas turi užtikrinti IS projektavimo proceso sklandumą, kad, iškilus klaidoms ar nepilnumo faktams, galima būtų grįžti prie reikalavimų specifikacijos papildymo, atliekant papildomą iteraciją IS kūrimo procese. 2. Informacijos srautų specifikacijos sudarymo procesas Kiekviena IS galima nagrinėti, kaip informacinių srautų sistemą, kurioje galima išskirti tris pagrindinius srautų tipus: Įeinantys srautai; Išeinantys srautai; Vidiniai srautai. Būtent operuojant šiais trimis srautų tipais ir yra sudaroma informacijos srautų specifikacija. Kaip vienas svarbiausių ir pirmiausiai išsiaiškintinų reikalavimų būsimai kompiuterizuotai informacijos sistemai yra reikalavimai išvedamai informacijai [2]. Todėl reikalavimai būsimai sistemai pradedami analizuoti nuo išeinančių informacijos srautų. Žinant jų struktūrą, galima identifikuoti reikiamus įeinančius srautus ir jų sudėtį. Be to, galimas informacijos srautų judėjimas pačios kompiuterizuotos IS viduje. Žinant, kad kompiuterizuotą IS galima įvardinti, kaip informacijos srautų apdorojimo sistemą, šiuos srautus galima specifikuoti sudarant informacijos srautų specifikaciją. Šios specifikacijos sudarymo procesas pagrįstas informacijos sistemai keliamų funkcinių reikalavimų specifikavimo metodu [2]. Juo remiantis naudojami informacijos srautų tipai įvardijami taip: XIV 4

44 T.Danikauskas, R.Butleris Įeinantis srautas Duomenų šaltinis organizacijos objektas, saugantis duomenis, reikalingus kompiuterizuojamoms veiklos funkcijoms atlikti. Tai gali būti organizacijoje cirkuliuojantys dokumentai, žodiniai pranešimai ir kiti informacijos nešėjai; Išeinantis srautas Rezultatas kompiuterizuotos IS funkcionalumo metu formuojamas rezultatas (ekraninė forma, ataskaita, duomenų srautas elektroniniu formatu), kuris iš dalies pakeičia iki kompiuterizuotos IS įdiegimo organizacijoje cirkuliavusius popierinius dokumentus (ataskaitas, suvestines), žodžiu ar kitomis komunikavimo priemonėmis perduodamus informacijos srautus; Vidinis srautas Duomenų srautas srautas, perduodamas iš vieno duomenų šaltinio kitam duomenų šaltiniui arba rezultatui. Srauto struktūrą sudarantys elementai parodo, kokio duomenų šaltinio atributo reikšmės bus perduodamos ir koks rezultato arba kito duomenų šaltinio atributas jas gaus. Šios reikšmės suformuoja atitinkamų duomenų šaltinio arba rezultato, kuriam perduodamos srautas, atributų reikšmes. Pirmajame paveikslėlyje pateikiama principinė informacijos srautų specifikacijos sudarymo proceso schema. Kadangi šiuo atveju orientuojamasi į specifikacijos panaudojimą IS projektavimo procese, todėl ši schema atspindi pagrindinius reikalavimų specifikavimo proceso etapus [3], parengiančius reikalingą informaciją atitinkamiems IS projektavimo etapams. Funkcijų hierarchijos specifikavimas X. DŠ apdorojimo etapų specifikavimas Etapas 4. DŠ būsenų kaitos specifikavimas 5. Veiksmas 2 Rezultatų ir duomenų šaltinių struktūros specifikavimas Duomenų šaltinis DŠ. 2. Veiksmas Etapas 3 Etapas 2 Veiksmas Busena Būsena 2 Būsena 3 Veiksmas 3 Veiksmas2 Originalus dokumentas Struktūros specifikacija DŠ ER modelis Ryšių tarp DŠ ir jų sudėties specifikavimas Ryšių tarp DŠ ir duomenų šaltinių būsenų specifikavimas I I Būsena Būsena 4 O Būsena 2 Būsena 3 Būsena 5 Būsena 6 pav. Funkcinių reikalavimų specifikavimo proceso konceptuali schema Pirmasis etapas pažymėtas X atitinka įžanginę specifikavimo proceso veiksmų seką. Specifikavimo procesas prasideda nuo rezultatų struktūros specifikavimo. Specifikavimo metu kiekvienam rezultatui sudaromas struktūros modelis ir rezultato esybių-ryšių (ER) modelis. Šis specifikavimo procesas yra trijų lygių: Formos šablono lygis, kuriame užfiksuojamas formos šablonas; Rezultatų/duomenų šaltinių struktūros modelis, kuris sudaromas pagal tam tikras taisykles; ER eskizas, tai yra ER modelis, apimantis tik vieno rezultato arba duomenų šaltinio kontekstą. Projektavimo aspektu sudėtingiausias trečiasis lygis, kuomet gaunamas rezultatas ER modelio eskizas. Kadangi duomenų šaltinio struktūra yra analogiška kompiuterizuotos IS funkcionalumo rezultato struktūrai (sudaro tokio paties tipo elementai) [], tai analogiškas specifikavimo procesas atliekamas duomenų šaltiniams. Todėl pirmajame paveikslėlyje struktūros specifikavimas apima pirmąjį ir antrąjį etapus. XIV 42

45 Informacijos srautų specifikacijos gyvavimo ciklas IS projektavimo procese Sekančio etapo metu specifikuojami duomenų srautai ir jų sudėtis. Duomenų srautus galima įvardinti kaip informacinius ryšius tarp duomenų šaltinių bei duomenų šaltinių ir rezultatų. Viena pagrindinių taisyklių šiems ryšiams specifikuoti yra tai, kad kiekvienam rezultatui formuoti reikalingas bent vienas duomenų šaltinis. Ketvirtojo etapo metu specifikuojama duomenų šaltinio apdorojimo technologija. Šio etapo rezultatas yra šaltinio apdorojimo etapų ir perėjimų tarp apdorojimo etapų specifikacija. Šis etapas turi betarpišką sąsają su IS projektavimo procesu. Dažnai pasitaiko, kad duomenų šaltinis užpildomas informacija laipsniškai, tam tikrais atributų rinkiniais. Be to, šalinio apdorojimas gali vykti lygiagrečiai su kito šaltiniu apdorojimu arba šaltinį apdoroja keletas aktorių. Visi šie ypatumai, vėliau projektuojant kompiuterizuotą IS tiesiogiai ar netiesiogiai atsispindės galutiniame produkte ir ypač vartotojo sąsajos elementuose. Penktasis etapas yra ankstesniojo detalizavimas. Duomenų šaltinio apdorojimas detalizuojamas iki duomenų šaltinio būsenų lygmens. Būsenų specifikavimas suteikia galimybę apibrėžti visus įmanomus duomenų šaltinio apdorojimo variantus. Visų variantų įvertinimas yra prielaida, kad sukurta kompiuterizuota IS pilnai palaikys visus organizacijoje vykstančius veiklos procesus. Paskutinis pav. pristatomo proceso etapas yra ryšių, identifikuotų ir aprašytų trečiojo etapo metu perkėlimas į duomenų šaltinių būsenų modelį. Šis etapas leidžia patikslinti jau esančius ryšius tarp duomenų šaltinių ir rezultatų. Atlikus visus aukščiau išvardintus etapus sistemos analitikas/projektuotojas turi informacijos srautų specifikaciją, kurios pagrindu gali būti projektuojama kompiuterizuota IS. 3. Specifikacijos paruošimas IS projektavimui Sudarytą specifikaciją reikia panaudoti kompiuterizuotos IS projektavimui. Kol kas ji yra tik modelių, naudojančių iš anksto apibrėžtą grafinę notaciją, rinkinys. Galima teigti, kad jau ir to pakanka, kad sistemos projektuotojas galėtų pradėti savo darbą, tačiau šiuo atveju nemažą dalį darbo tektų atlikti rankiniu būdu. Žymiai efektyviau būtų turimos specifikacijos rezultatą panaudoti automatizuotoje IS projektavimo priemonėje, kuri leistų atlikti sistemos projektavimą ar net sukurti jos prototipą. Kiekvienos CASE priemonės neatsiejama dalis yra saugykla (metaduomenų bazė), t.y. duomenų bazė, kurioje saugoma informacija, reikalinga projektuojant kompiuterizuotą IS. Aukščiau aptartai informacijos srautų specifikacijai taip pat reikalinga saugykla, kurios loginė schema pateikta 2 pav. Šis modelis skirtas specifikacijos informacijai išsaugoti, kad būtų galima atkurti išsaugotus specifikacijų modelius arba turimą informaciją panaudoti sistemos projektavimui. Šioje saugykloje nėra pilnai įvertinta sistemos projektinių sprendimų informacijos išsaugojimo galimybė, tačiau dalį saugyklos struktūros bus galima naudoti ir projektavimo etapo metu gaunamos informacijos kaupimui. Turima specifikacijos saugykla turi būti užpildyta duomenimis. Saugyklos užpildymo eiga atitinka specifikacijos sudarymo eigą. Antrajame paveikslėlyje loginės schemos lentelės suskirstytos į grupes, kurios sunumeruotos. Kiekvienos grupės lentelių informacija įvedama būtent tokiu eiliškumu, kaip vyksta ankščiau aprašytas specifikacijos sudarymo procesas. Kiekvienas sekančio žingsnio informacijos įvedimas vyksta pasinaudojant ankstesnių žingsnių išsaugota informacija saugykloje. Ši taisyklė galioja ir pirmajam žingsniui, nes išsaugant duomenų šaltinio ar rezultato struktūros specifikacijos duomenis, jie turi būti sinchronizuojami su jau esamais duomenimis. Taisyklė negalios tik pirmojo rezultato struktūros specifikacijai, nes saugykla bus tuščia. Pirmoji lentelių grupė, pildoma pirmojo ir antrojo žingsnio metu, suskirstyta į dar mažesnius pogrupius. Kairioji grupė skirta rezultatų struktūros specifikacijai saugoti, dešinioji - duomenų šaltinių struktūros specifikacijai saugoti. Centrinė dalis yra jungiamasis sluoksnis tarp kairiosios ir dešiniosios dalių. Į šią dalį informacija įvedama abiem atvejais. Kiekvieną kartą įvedinėjant tiek rezultatų, tiek duomenų šaltinių informaciją, vyksta informacijos sinchronizavimas su centinės dalies informacija, t.y. sekama ar tokie ryšiai, esybės ir jų atributai jau buvo išsaugoti. Taip realizuojamas specifikacijos pilnumo ir nepertekliškumo užtikrinimo mechanizmas [4]. 4. Informacijos srautų specifikacijos saugykla IS projektavimo procese Projektuojant kompiuterizuotą IS galima išskirti tris pagrindines šio proceso dalis: Kompiuterizuotos IS duomenų bazės loginės schemos projektavimas; Kompiuterizuotos IS vartotojo sąsajos elementų projektavimas; Kompiuterizuotos IS veiklos vidinių procesų projektavimas. Turimą specifikaciją ir jos saugyklą galima susieti su visomis trimis dalimis (žr. 3 pav.). Paveikslėlyje pateikiama bendra koncepcinė schema, kaip susieti informacijos srautų specifikacijos sudarymo procesą su kompiuterizuotos IS projektavimo procesu. Kaip jungiamoji grandis tarp šių dviejų procesų yra specifikacijos saugykla. Siūloma specifikacijos sudarymo procesą ir kompiuterizuotos IS projektavimo procesą realizuoti kaip atskirus CASE įrankio komponentus, dirbančius su ta pačia saugykla. XIV 43

46 T.Danikauskas, R.Butleris Salygos_elem_R. 2. Salygos_elem_DS id r_id r_a_id r_a_id2 rb_id id Rysys kard kard2 e_id e_id2 rys_ds_id id ds_id ds_a_id ds_a_id2 rb_id id Aktorius kodas pavadinimas paaiskinimas Perejimas_DS_B id ds_b_is_id ds_b_i_id et_id Rib_reiksme_R id kodas vard_org n_vardas paaiskinimas r_id id id Rezultatas kodas pavadinimas paaiskinimas salyga R_atributas id R_esybe kodas vard_org rodomumas tipas r_id e_id kodas vard_org egz_sk rodomumas butinumas formule r_id a_id id id Esybe kodas n_vardas paaiskinimas Atributas kodas n_vardas unikalumas paaiskinimas tipas ilgis e_id Rib_reiksme_DS id kodas vard_org n_vardas paaiskinimas ds_id id DS_esybe kodas vard_org rodomumas tipas ds_id e_id id Duom_salt kodas pavadinimas paaiskinimas salyga h_lygis DS_atributas id kodas vard_org egz_sk rodomumas butinumas formule ds_id a_id Veiksmas_DS id kodas pavadinimas paaiskinimas ak_id ak_id2 Perejimas_Et id v_id et_is_id et_i_id id Et_atributas id Etapas kodas pavadinimas paaiskinimas ds_id ds_a_id et_id DS_B_atributas id Rysys_tarp_DS id kard kard2 vardas vardas2 l_ds_r_id l_ds_r_id2 ds_id ds_id2 Lankas_DS_R id DS_Busena id kodas pavadinimas paaiskinimas et_id ds_b_id et_a_id ds_b_id 6. Rysys_tarp_DS_B kodas tipas id Srautas_R kodas pavadinimas paaiskinimas ds_id_is r_id_i Sr_R_elem id sr_id ds_a_id_is r_a_id_i 3. Sr_DS_elem id ds_a_id_is ds_a_id_i Srautas_DS id kodas pavadinimas paaiskinimas ds_id_is ds_id_i id kard kard2 vardas vardas2 rys_ds_id l_ds_b_id l_ds_b_id2 ds_b_id ds_b_id2 Lankas_DS_B id kodas tipas l_ds_r_id 2 pav. Informacijos srautų specifikacijos metabazės schema ir jos užpildymo proceso eiga Duomenų bazės loginės schemos projektavimui kaip pagrindą reiktų naudoti pirmos/antros lentelių grupės centrinėje dalyje saugomą informaciją, kurios pagrindu galima sudaryti eskizinį kompiuterizuotos IS duomenų bazės modelį. Šiam modeliui gali stigti dalies ryšių arba prireikti detalizuoti esamus. Tai galima atlikti pasitelkiant saugyklos lentelių trečiosios ir šeštosios grupės duomenis. Detalizavus šį modelį gautas eskizinis duomenų bazės modelis gali būti naudojamas kompiuterizuotos IS arba jos prototipo realizavime. XIV 44

47 Informacijos srautų specifikacijos gyvavimo ciklas IS projektavimo procese Vartotojo sąsajos elementų projektavimas ir pateikimas kaip prototipinių ekrano formų ar ataskaitų, gali būti atliktas pasinaudojant pirmos/antros ir ketvirtos saugyklos lentelių grupių informacija. Šiuo atveju projektavimas atliekamas remiantis atskirai kiekvieno duomenų šaltinio apdorojimo etapų ir struktūros informacija saugykloje. Tai leidžia dar neturint pilno kompiuterizuotos IS loginės schemos modelio turėti vartotojo sąsajos elementų prototipą. Informacijos sistemai keliamų funkcinių reikalavimų specifikavimo metodas CASE priemonė specifikacijos sudarymui... DŠ/R struktūros specifikavimas Ryšių tarp DŠ specifikavimas DŠ apdorojimo etapų specifikavimas DŠ būsenų kaitos specifikavimas... KIS specifikacija Specifikacijos saugykla... Modulis KIS DB loginės schemos projektavimo modulis KIS vartotojo sąsajos elementų projektavimo modulis KIS veiklos procesų projektavimo modulis CASE priemonė kompiuterizuotai IS (KIS) projektuoti... Modulis KIS projektas, prototipas 3 pav. Informacijos srautų specifikacijos panaudojimas IS projektavimo procese Pasinaudojant 3-6 grupių lentelėmis galima atlikti kompiuterizuotos IS veiklos vidinių procesų projektavimą. Galima suprojektuoti kompiuterizuotos IS sistemos atskirų modulių ir jų vartotojo sąsajos elementų elgseną, kaip tai atrodys organizacijos veiklos kontekste [5]. Šis etapas dar turi būti papildomai išplėtotas. Koncepcinėje schemoje tiek projektavimo proceso, tiek specifikavimo proceso eigoje palikti neįvardinti moduliai identifikuoja projektavimo ir specifikavimo plėtros poreikį, numatant papildomas kompiuterizuoto sistemos projektavimo galimybes, reikalaujančias praplėsti ir informacijos srautų specifikacijos sudarymo procesą. 5. Išvados Atlikta informacijos srautų specifikacijos proceso analizė, pateikiant pagrindinius specifikacijos sudarymo žingsnius. Pristatytas funkcinių reikalavimų informacijos sistemai specifikacijos saugyklos modelis. Specifikacijos sudarymo žingsniai susieti su specifikacijos modelių išsaugojimu atskirose specifikacijos saugyklos poschemėse. Pateiktas koncepcinis informacijos srautų specifikacijos panaudojimo IS projektavimo procese modelis, kuriame numatoma naudoti du atskirus CASE priemonės komponentus, skirtus funkciniams reikalavimams specifikuoti bei IS kūrimo projektiniams sprendimams fiksuoti. Šie komponentai naudosis bendra specifikacijos saugykla. Toliau numatomas informacijos srautų specifikavimo ir IS projektavimo proceso detalizavimas bei plėtra, išvystant informacijos srautų specifikavimo bei IS projektinių sprendimų rengimo procesus ir siekiant užtikrinti realizuojamo IS projekto pilnumą. Literatūros sąrašas [] Butkienė R., Butleris R. The Approach for the User Requirements Specification. 5 th East-European conference ADBIS 200. Research Communications, Ed. by A.Čaplinskas, J.Eder, Vilnius, 200, pp [2] Butkienė R., Butleris R. Verification Rules of Computerized Information System Model with Respect to Data Resource Processing. Informatica, Vilnius: Mokslo aidai, 200, Vol.2, No.3., pp [3] Butleris R.,Danikauskas T. Veiklos modeliavimo metodų analizė reikalavimų specifikavimo aspektu. Informacinės technologijos 2002, Konferencijos pranešimų medžiaga. Kaunas: Technologija, 2002, p [4] Butkienė R., Butleris R, Danikauskas T. The approach to consistency checking of functional requirements specification. The 6th Worl Multiconference on Systematics, Cybernetics and informatics, Proceedings of International Conference, Orlando, USA. 2002, Vol.8, p XIV 45

48 T.Danikauskas, R.Butleris [5] Butleris R., Butkienė R., Danikauskas T. Business modeling for elicitation of information requirements. Business operation and its legal environment: processes, tendencies and results, Proceedings of International Conference, Riga: Turiba, 2002, p Life Cycle of Information Flows Specification During Information System Design Data flows specification is composed on basis of input and output date flows of system or separate its parts. In case to use this specification during IS design process specification is saved in repository. Preparation of date flows specification is iterative and multilevel process. Every iteration saves new information or corrects old in repository. Separate stages of functional requirements specification will be related with separate stages of IS design. XIV 46

49 ŠIUOLAIKINĖS ŽMOGIŠKŲJŲ IŠTEKLIŲ VALDYMO SISTEMŲ KŪRIMO TENDENCIJOS Milda Balandytė, Jūratė Jašinskaitė, Lina Nemuraitė, Giedrius Tamulis Informacijos sistemų katedra, Informatikos fakultetas, KTU Studentų g. 50, LT-3028 Kaunas Straipsnyje suformuluoti organizacijos žmogiškųjų išteklių valdymo sistemų kūrimo principai ir tendencijos, apžvelgtos pagrindinės funkcijos bei duomenų struktūros. Pagal žmogiškųjų išteklių valdymo sistemoms keliamus reikalavimus buvo sudarytas universalus sistemos modelis, tinkantis bet kokio dydžio ir struktūros organizacijoms. Atsižvelgiant į vartotojų poreikius palaikyti grupinio darbo sąsają, užtikrinti dokumentų saugumą, valdyti darbų sekas, sistemos realizacijai buvo pasirinkta Lotus Notes/Domino aplinka. Realizuotas produktas bandomajam laikotarpiui įdiegtas UAB PTI Technologijos.. Įvadas Atsižvelgiant į nuolat augantį poreikį valdyti organizacijose žmogiškuosius išteklius bei išnagrinėjus jau egzistuojančius tokių sistemų sprendimus Lietuvoje ir pasaulyje, buvo suformuotas tikslas sudaryti organizacijos žmogiškųjų išteklių valdymo sistemos universalų modelį, tinkantį mažoms ir didelėms gamybinėms bei negamybinėms įmonėms ir valstybinėms institucijoms, apimantį visas funkcijas, susijusias su žmogiškųjų išteklių valdymu, ir pasirinkus Lietuvos įmonę pagal jos poreikius realizuoti būtiniausią sistemos dalį. 2. Egzistuojančių sistemų žmogiškųjų išteklių valdymo funkcijų analizė Šiuo metu Lietuvoje daugelyje paplitusių apskaitos sistemų žmogiškųjų išteklių valdymas suprantamas kaip darbuotojų kortelių tvarkymas, kartais prie jo prijungiant darbo užmokesčio skaičiavimo funkcijas, kurios labiau sietinos su buhalterine apskaita. Sudarant organizacijos žmogiškųjų išteklių valdymo sistemos universalų modelį, buvo nagrinėjami tiek Lietuvoje, tiek užsienyje sukurti paketai. 2.. Problemos sprendimas pasaulyje Pasaulyje egzistuoja daug ir įvairių sprendimų, susijusių su žmogiškųjų išteklių valdymu. Tiriant tokių sistemų rinką užsienyje, buvo analizuojami šie programiniai paketai: Navision Financials, Hansa Financials, Best Abra HR, Best Imperative HRMS, Ulti Pro HR, Dynamics, Sage Enterprise Suite, eenterprise, Navision Axapta, Oracle Small Business Suite, Mysap HR, Peoplesoft HR, Oracle HR. Išnagrinėjus šias egzistuojančias sistemas galima teigti, kad: Didelės sistemos, tokios kaip Oracle HR, PeopleSoft HR, mysap, pasižymi išvystytomis žmogiškųjų išteklių valdymo funkcijomis, tačiau yra labai brangios; Dauguma užsieninių sistemų nepritaikytos Lietuvos specifikai; Dauguma sistemų netenkina funkcinių reikalavimų Situacijos Lietuvoje įvertinimas Kadangi Lietuvoje žmogiškųjų išteklių valdymas siejamas su darbuotojų kortelių tvarkymu, sukurtuose programiniuose paketuose visai neatsižvelgiama į kitų reikalingų funkcijų bei darbų sekų (tarp vadovų bei darbuotojų) automatizavimą tai įrodo išnagrinėtų Lietuvos rinkoje egzistuojančių sistemų pavyzdžiai: Scala, Balansas 2000, Konto, Apskaita, Akf apskaita, Personalas, Cs asmuo, Ci avs 200, Debetas, Alga 2000, Du000, Ontime, Personalas, Alga iv, Pragma, Skaita 2000, Atlygis, Stekas-apskaita. Daugelis nagrinėtų sistemų netenkina funkcinių reikalavimų, keliamų personalo valdymui išskirti galima tik DU000 ir ALGA2000 sistemas. Dauguma jų pritaikytos tik vienai darbo vietai nepalaiko grupinio darbo sąsajos: intraneto (paslaugų darbuotojams organizacijos viduje teikimas), darbo sekų valdymo (dokumentų tvirtinimo - teisiškai pagrįstų procedūrų užtikrinimas). XIV 47

50 M.Balandytė, J.Jašinskaitė, L.Nemuraitė, G.Tamulis Išnagrinėjus egzistuojančių žmogiškųjų išteklių valdymo sistemų rinką Lietuvoje ir užsienyje, išryškėjo reikiamų funkcijų spektras. Pirmiausia turi būti realizuotas platus darbuotojų asmeninių duomenų valdymas. Asmens kortelėse registruojami ne tik asmeniniai darbuotojų duomenys, bet ir gauti skatinimai bei pasiekti laimėjimai. Darbuotojams suteikiama galimybė įvesti ir koreguoti tam tikrus leistinus duomenis bei gauti reikiamas ataskaitas ir pažymas. Kiekvienoje kortelėje fiksuojama konkretaus asmens darbo istorija (iki įsidarbinimo įmonėje ir pačioje įmonėje). Kita svarbi funkcija organizacinis valdymas. Pirmiausia sistemoje apibrėžiama organizacijos padalinių hierarchija. Vėliau sudaromas pareigybių tarpusavio priklausomybių medis. Kiekvienai pareigybei nustatomos jos teisės, pareigos, atsakomybė, reikalaujama kompetencija bei priskiriamas asmuo, eisiantis tas pareigas. Taip pat nurodoma pavaduojanti pareigybė. Esant poreikiui, sistemoje gali būti kuriamos struktūrinės grupės tam tikri įmonės organizaciniai vienetai. Įmonių vystymui labai svarbu gerai organizuoti naujų darbuotojų paiešką ir atranką. Sistemoje sudaromas rezervas darbuotojų, tinkamų konkrečiai pareigybei užimti, ranguotas sąrašas. Asmenims užpildžius pateiktą kandidato anketą, gauti duomenys registruojami ir analizuojami. Taip gaunamas ranguotas kandidatų sąrašas pagal jį organizacijos vadovybė atsirenka tinkamą žmogų konkrečiai pareigybei užimti. Su nauju darbuotoju sudaroma darbo sutartis. Organizacijose daug dėmesio turi būti skiriama personalo ugdymui ir mokymui. Kiekvienam asmeniui sudaromas individualus karjeros planas, kuriame registruojami pageidavimai žinioms, mokymo programoms bei norimai karjerai pasiekti. Pateikti pageidavimai derinami su įmonės poreikiais bei pareigybėms keliamais reikalavimais. Sistemoje taip pat turi būti registruojami kvalifikacijos tobulinimo renginiai (mokymo kursai, komandiruotės, stažuotės), skaičiuojamos išlaidos ir palyginamos su jų teikiama nauda. Sistemos pagalba organizuojami ir planuojami susirinkimai bei konferencijos. Svarbi funkcija darbuotojų motyvacijos kėlimui bei darbų sekimui darbuotojų vertinimas. Tokiu būdu kontroliuojama įmonės darbuotojų darbų kokybė bei vertinamos asmeninės savybės. Vertinimo sistema pasirenkama pagal konkrečios organizacijos poreikius. Periodiškai sudaromos ataskaitos bei pateikiami statistiniai duomenys. Žmogiškųjų išteklių valdyme svarbu sekti darbo laiko apskaitą. Todėl sistemoje turi būti realizuotas atostogų valdymas. Pirmiausia nustatomas kiekvienam darbuotojui priklausomų atostogų dienų skaičius. Užregistravus darbuotojų prašymus dėl atostogų trukmės ir laiko, sudaromas atostogų planas. Taip pat vykdomas sveikatos monitoringas - registruojami nedarbingumo lapeliai, profesiniai susirgimai ir apsinuodijimai, vykdomas darbo vietų higieninio įvertinimo rezultatų ir darbuotojų sveikatos parametrų palyginimas su reikiama norma. Sistemoje formuojami statistiniai duomenys ir įvairaus pobūdžio ataskaitos. Sudarius reikiamų funkcijų sąrašą, sudarytas universalus organizacijos žmogiškųjų išteklių valdymo modelis. 3. Siūlomas organizacijos žmogiškųjų išteklių valdymo modelis Kuriant organizacijos žmogiškųjų išteklių valdymo sistemos modelį, buvo siekiama: sukurti lengvai naudojamą sistemą, paremtą internetine sąsaja; realizuoti platesnį nei šiuo metu egzistuojančių sistemų funkcijų spektrą; užtikrinti su personalu susijusių dokumentų tvarkymą; suteikti kiekvienam darbuotojui komunikavimo galimybes; padidinti kiekvieno personalo nario informuotumą, suteikiant duomenis apie jį patį ir organizacijos informacinius išteklius pagal darbuotojo teises; siekti ekonominio efektyvumo, automatizuojant organizacijos valdymo, įdarbinimo, mokymo funkcijas, tokiu būdu sutaupant nemažai laiko bei pinigų sąnaudų; užtikrinti tinkamų darbuotojų priskyrimą pareigybėms ir atskiroms užduotims, remiantis kompetencijų modeliais; užtikrinti darbuotojų kompetencijos didinimą, mokymą, darbo išteklių planavimą; kaupti istoriją apie kiekvieną darbuotoją; stebėti ir vertinti pareigybes, darbuotojus bei jų darbo sąlygas; sistemą pritaikyti Lietuvos sąlygoms, kad būtų galima panaudoti daugelyje įmonių. XIV 48

51 Šiuolaikinės žmogiškųjų išteklių valdymo sistemų kūrimo tendencijos pav. panaudojimo atvejų diagramos pagalba pavaizduotos sistemos ribos ir sąveika su vartotojais. Kiekvienas panaudojimo atvejis atskiras susijusių funkcijų poaibis. Sistemoje atskiri vartotojai ar vartotojų grupės turi tam tikras teises, t.y. gali atlikti tik konkrečias funkcijas. 2. Darbo laiko apskaita Buhalterinė apskaita. Darbuotojų asmeninių duomenų valdymas 5. Personalo ugdymas, mokymas Administratoriai 9. Saugos darbe monitoringas 7. Atostogų valdymas Darbuotojai 8. Sveikatos monitoringas Personalo skyrius 0. Statistinių duomenų ir ataskaitų formavimas 6. Darbuotojų vertinimas Padalinių vadovai 4. Naujų darbuotojų paieška ir atranka Kandidatai 3. Organizacinis valdymas Normatyvinių aktų DB Organizacijos vadovybė 2 pav. Sistemos ribos 2 pav. pateiktas sistemos dalykinės srities duomenų modelis, kuriame abstrakčiai pateikiami sistemoje cirkuliuojantys duomenų vienetai. Remiantis sudarytu organizacijos žmogiškųjų išteklių valdymo modeliu, pagal UAB PTI Technologijos poreikius suprojektuota, realizuota ir įdiegta sistemos dalis. Šiuo metu sukurta Organizacijos žmogiškųjų išteklių valdymo sistemos dalis, užtikrinanti patogų informacijos apie personalą valdymą bei duomenų perdavimo sąsają tarp sistemos ir buhalterinės apskaitos programos, nustatanti darbuotojų darbo užmokestį, naudojant specializuotą vertinimo sistemą bei formuojanti statistinius ir suminius rezultatus. XIV 49

52 M.Balandytė, J.Jašinskaitė, L.Nemuraitė, G.Tamulis Pamainumo/pavadavimo planas Kvalifikacinis reikalavimas Anketa Reikalavimas Kolegų vertinimas..n Pareigybė Etatas Rezervas Laisva darbo vieta Karjeros planas..n Kandidatas..n Struktūrinė gru pė Ranguotas sąrašas Darbo vertinimas Kolegų atsiliepimų vertin imas Laimėjimas Skatinimas Istorija Darbo sutartis Asmens savybių vertinimas 0.. n..n.. n..n..n 0.. n Darbo ataskaita Vertinimas Darbuotojas (asmens kortelė) 0.. n Vadovas..n..n..n 0.. n..n Prašymas 0.. n..n Pravaikšta Kv alif ikacijos tobu li nimo renginys Darbo laikas Susirgimas 0.. Nedarb in gu mo lap elis Atostogų planas Komandiruotė Atostogos Padalinys 0.. n Statistiniai duomenys ir ataskaitos Orga nizacija Personalo skyrius..n Darbo vietos/pareigybės vertinimas Saugos normatyvas Higienos normatyvas Teisinė norma Susirinkimas Seminaras Konferencija Mokymo ku rsai 3 pav. Dalykinės srities duomenų modelisorganizacijos žmogiškųjų išteklių valdymo sistemos sukūrimas Lietuvos vartotojui Sukurtas produktas apima šiuos modulius: DB Biblioteka ( DBLibary ) - registruoja informaciją apie sistemą sudarančias posistemes; Klasifikatoriai ( Classficators ) - registruoja bendrą klasifikuotą sistemoje naudojamą informaciją; Organizacinė struktūra ( OrgStructure ) - aprašo organizacijos padalinių struktūrą bei pareigybių pavaldumo medį; Personalas ( Personnel ) - registruoja ir saugo duomenis apie organizacijos darbuotojus; Atlyginimų skaičiavimo modulis ( Salary ) - pagal gautus vertinimo rezultatus nustato kintamą darbo užmokesčio dalį (KDU), suskaičiuoja NETO atlyginimus ir pateikia ataskaitas, Vertinimų modulis ( Evaluation ) - pateikia darbuotojams vertinimo anketas, formuoja vertinimo rezultatus bei ataskaitas. Sistemos realizacijai pasirinktas Lotus Notes/Domino paketas. Tai IBM firmos produktas, paremtas kliento/serverio architektūra. Jo informacinis vienetas yra dokumentas. Galima išskirti tokius Lotus Notes/Domino paketo privalumus: grupinio darbo sąsaja - sistemos vartotojai gali komunikuoti organizacijos viduje ir už jos ribų; užtikrinami keli slaptumo lygiai kiekvienam sistemos dokumentui nustatoma tam tikra prieiga (galimybė dokumentą skaityti ir redaguoti); internetinė sąsaja suteikiama galimybė vartotojui naudotis sistema per Interneto naršyklę; Integravimas su reliacinėmis DB; Pašto standartų palaikymas; Veiklos koordinavimas (resursų valdymas), darbų sekų valdymas. 4 pav. pateiktas bendras realizuotos sistemos modulių vaizdas Lotus Notes aplinkoje. XIV 50

53 Šiuolaikinės žmogiškųjų išteklių valdymo sistemų kūrimo tendencijos 4 pav. Komponentų diagrama 5 pav. Sistemą sudarantys moduliai Lotus Notes aplinkoje Išvados Išanalizavus žmogiškųjų išteklių valdymo sistemų rinką Lietuvoje ir pasaulyje bei surinkus tokių sistemų būsimų vartotojų reikalavimus, buvo sudarytas universalus modelis, tinkantis įvairaus dydžio ir struktūros įmonėms. Buvo sudarytas reikalingų žmogiškųjų išteklių valdymo funkcijų rinkinys. Remiantis sudarytu modeliu, suprojektuota, realizuota ir bandomajam laikotarpiui įdiegta konkrečiai įmonei būtiniausia žmogiškųjų išteklių valdymo sistemos dalis. Literatūros sąrašas [] A.Sakalas. Personalo valdymas. Kaunas: Technologija, p. [2] Philippe Kruchten. The Rational Unified Process. Addison-Wesley, 998. XIV 5

54 M.Balandytė, J.Jašinskaitė, L.Nemuraitė, G.Tamulis [3] M. Cotterell, B. Hughes. Software Project Management. GB, Oxford, Alden Press Limited, 995. p [4] Įmonių katalogas. Prieiga per Internetą: [5] Human Resource Management. Prieiga per Internetą: [6] Human Resource Management. Prieiga per Internetą: [7] Human Resource Management. Prieiga per Internetą: [8] Human Resource Management. Prieiga per Internetą: [9] Human Resource Management. Prieiga per Internetą: Contemporary development trends of human resource management systems This article represents development trends and fundamentals, gives the overview of key functions and data structures of human resource management systems in organizations. Introduced general-purpose model meets the requirements of human resource management systems and fits for the organizations of any size and structure. The system, mentioned above, was implemented by Lotus Notes/Domino SDK (software development kit). In accordance with user requirements Lotus Notes/Domino environment maintains groupware interface, provides document security and workflow management. For trial period created software was installed in joint-stock company 'PTI Technologijos'. XIV 52

55 UML IŠPLĖTIMAS VERSLO MODELIAVIMO KALBOS SAVYBĖMIS Lina Nemuraitė, Paulė Žakšauskienė KTU, Informacijos sistemų katedra, Šiame darbe išanalizuota verslo modeliavimo kalbos BML semantika ir panaudojant UML išplėtimo mechanizmus sudaryti BML elementų atitikmenys UML kalba. Sudaryta verslo procesų modeliavimo metodika padeda patikslinti UML veiklos diagramų semantiką verslo procesų modeliavimui ir gauti korektiškesnį verslo procesų modelį, naudojant standartinius UML CASE įrankius.. Verslo procesų projektavimo tendencijos Šiais laikais organizacijos turi susidoroti su greitai kintančiais vartotojų reikalavimais, griežtėjančia konkurencija ir atsiradusiomis naujovėmis tiek gamybos, tiek informacinių technologijų srityse. Dinaminėje aplinkoje greitai reaguojančios organizacijos turės didelių privalumų prieš savo konkurentus. Tradiciškai pagal atliekamas funkcijas organizacijos yra skirstomos į padalinius (marketingo, produkcijos, paslaugų). Tačiau tokia struktūra turi trūkumų. Ji reikalauja daug administravimo išlaidų, sukuria bendrų problemų pasiskirstymą tarp funkcinių organizacijos vienetų, didelis kiekis resursų yra paskiriamas tokioms užduotims, kurios nepateikia naudingo rezultato. Tam, kad išvengti šių problemų, įmonės koncentruojasi į verslo procesus, t.y. į tam tikrą skaičių veiklų, kurios sukuria vertingą rezultatą įmonės klientams. Šie procesai dažnai kerta organizacijos ribas ir apima keletą organizacijų. Analizuojant verslo procesą klientas tampa atskaitos centru, ir tuomet esant kliento poreikiui gauti ankstesnės kokybės produktą ar paslaugą, organizacija turi atitinkamai pritaikyti savo verslo procesus. Norint greitai ir optimaliai adaptuotis reikalingos lanksčios bei integruotos programos. Tačiau daugelis organizacijų turi programas, sukurtas dirbti tik tam tikram funkciniam vienetui ar skyriui. Pavyzdžiui, marketingui buvo sukurta tam skirta speciali informacinė sistema su specialiai suprojektuotomis marketingo programomis. Taigi, organizacijos funkciniams vienetams skirtos programos nesąveikauja tarpusavyje, arba jų bendradarbiavimas yra labai komplikuotas. Tam yra naudojamos programos, galinčios pasiūlyti integruotą informacinę aplinką realizuoti verslo procesus, vykdomus skirtingų funkcinių padalinių ar net organizacijų, sujungiančią skirtingas programas bei paketus. Šioms programoms kurti naudoti reikalinga adekvati modeliavimo technologija su lengvai suprantamais projektuojamais modeliais. Tokiais atvejais gerai tinkanti verslo procesų atvaizdavimui yra BML kalba, kuri gali būti naudojama vaizduoti, projektuoti ir verifikuoti verslo procesų eigos modelius, leidžiančius susieti organizacijos dalyvių veiklą su joje vykdomais verslo procesais. 2. Procesų modeliavimo kalbos Kadangi verslo įmonių informacinių sistemų teorijoje ir praktikoje pastaraisiais metais procesais grindžiamos sistemos tapo viena svarbiausių krypčių [3,0], procesų specifikavimui ir projektavimui buvo sukurta daug kalbų bei metodologijų. Gali būti išskirtos dvi pagrindinės procesų modeliavimo kalbų kryptys: grindžiamos užduotimis ir grindžiamos komunikaciniais veiksmais. Užduotimis grindžiamos yra UML (Unified Modelling Language) veiklos (Activity) diagramos [5,6] bei įvykių valdomos procesų grandinės EPC (Event-driven Process Chains) [9]. Šioms kalboms pritaikytos metodikos dažnai apima ir fizinių, ir informacinių procesų modeliavimą. Komunikaciniais veiksmais grindžiamos kalbos leidžia sutelkti dėmesį į procesus, aprašančius sąveikas tarp žmonių ar sistemų pranešimų siuntimo ir gavimo terminais. Tai suteikia galimybę parodyti veikėjų ir procesų bendradarbiavimą informacinių technologijų sistemose. Vienas labiausiai paplitusių metodų yra Language Action metodas, sukurtas kalbos veiksmų (Speech Act) teorijos pagrindu. Naudojantis Language Action metodu, yra sukurta eilė komunikaciniais veiksmais pagrįstų metodų [2,4,9]: DEMO, Action Workflow, BAT, daugiasluoksniai transakcijų šablonai (Layered Transactional Patterns) bei Language Action metodui labai gimininga verslo proceso kūrimo metodologija P 3 [,2]. P 3 (Process Pattern Perspective) verslo procesų modeliavimo metodika yra skirta kurti verslo procesų modeliui, pradedant nuo statinio verslo modelio. Ji yra pagrįsta primityviais procesų šablonais ir palengvina proceso kūrimą, pateikdama automatizavimo priemones. P 3 metodika paremta teoriniu pagrindu: vertės teorija (Value Theory), XIV 53

56 L.Nemuraitė, P.Zakšauskienė Speech Act teorija, komunikuojančiais būsenų mechanizmais (Communicating State Machines) bei organizacijų modeliavimo ontologija (Enterprise Modeling Ontology). Labai nauja P 3 verslo procesų projektavimo metodika leidžia pritaikyti parankias ir lengvai suprantamas verslo procesų verifikavimo taisykles, kuriomis remiantis nesunku sukurti identišką įmonės verslo procesų eigos modelį. Tačiau gaunamas modelis aprašomas verslo modeliavimo kalba BML (Business Modeling Language) [,3], kuri dar nėra plačiai paplitusi, o tuo pačiu ir nesuprantama projektų užsakovams. Dėl šių priežasčių reikia ieškoti būdo, kuris leistų populiarinti šią metodiką ir palengvinti jos naudojimą. UML (Unified Modeling Language) yra tapusi standartine modeliavimo kalba programinės įrangos kūrimui. Kaip universalioji modeliavimo kalba, UML neduoda tikslių rekomendacijų, ji skirta tenkinti daugeliui tikslų. Tačiau šios kalbos taikymas verslo modeliavimui vadovaujasi panašiomis idėjomis kaip ir kitose verslo procesams modeliuoti skirtose metodikose. Šia kalba užrašomas verslo modelis yra supaprastintas požiūris į verslo eigą bei procesus. Iki šiol UML yra sėkmingai taikoma modeliuojant programinę įrangą. Kadangi verslo modelis naudojamas apibrėžiant reikalavimus kuriamai informacinei sistemai, tos pačios kalbos taikymas palengvina verslo modelio perkėlimą į informacinės sistemos veikimo struktūrą. UML gali būti naudojama verslo procesų analizėje, projektavime ir kaip kitų modelių integravimo pagrindas (pvz., skirtingų informacinių sistemų įjungimui į tą patį verslo modelį). Ši kalba dėl plataus pritaikymo ir išplėtimo galimybių gali būti naudojama atvaizduoti kitų modeliavimo kalbų elementams. Jai yra sukurta daugelis modeliavimo įrankių. BML kalba, lyginant su UML, yra labai nauja, todėl jos modelių sudarymui bei verifikavimui nėra sukurta patogios programinės įrangos. Išsami šių dviejų kalbų semantikos analizė ir palyginimas padėjo sudaryti modelį, kuriuo naudodamasis projektuotojas gali taikyti P 3 metodiką ir sudaryti BML atitinkančias diagramas UML bei naudoti UML CASE įrankius. Tokiu būdu P 3 metodas taptų žymiai lengviau panaudojamas ir pritaikomas praktikoje. 3. Verslo procesų modeliavimo metodo P 3 analizė P 3 metodologija yra skirta sukurti veikiantį proceso modelį, realizuojantį verslo reikalavimus techninėje aplinkoje. P 3 metodikoje procesų modeliai užrašomi BML kalba. Kaip jau minėta, priklausomai nuo tekstinio ir grafinio pateikimo yra susiformavusios dvi procesų projektavimo kryptys: pagrįstos veiksmais ir pagrįstos komunikacijomis. Veiksmais pagrįstų kalbų diagramos paprastai atvaizduoja automatinių bei fizinių funkcijų junginį. Komunikacijomis pagrįsti metodai koncentruojasi į komunikavimo procesą, aprašantį sąveiką tarp žmonių ir sistemų pranešimų siuntimo ir gavimo terminais. P 3 metodika nagrinėja komunikavimu pagrįstus veiksmus, užrašomus BML kalba. Metodikos kūrėjai praplėtė BML notaciją, įvesdami laukimo būsenos simbolį, vaizduojantį pranešimų laukimą. Iš laukimo būsenos galima išeiti, gavus sėkmingą pranešimą. 3.. Verslo procesų šablonai Verslo proceso modeliavimas yra labai komplikuotas ir užimantis daug laiko, ypač tada, kai naujame projekte reikia pradėti nuo eskizo. Gera projektuotojo praktika apeiti šiuos sunkumus yra naudoti gerai dokumentuotus projektavimo šablonus. P 3 metodikos šablonai remiasi komunikacinių veiksmų kilpos fazėmis (užklausa, derinimas, vykdymas, patvirtinimas, [] ) ir atvaizduojami BML procesų diagramomis, atitinkančiomis ekonominius atvejus:. Ekonominių resursų užklausos diagrama (ERUD) Ši diagrama yra veiksmų eigos ciklas, vaizduojamas užklausą pateikusio aktoriaus požiūriu, kai klausiantysis yra pagrindinis veikėjas. Pavyzdžiui, pagrindinio aktoriaus prekės užsakymas atitinka vieną ERUD atvejį, kuriuo siekiama gauti prekės pristatymą iš tiekėjo. Ekonominiu resursu gali būti bet koks ekonominę vertę turintis objektas, ekonominis atvejis dar kitaip vadinamas vertės perdavimu (Value Transfer). 2. Ekonominį resursą siūlanti diagrama (ERSD) Ši diagrama yra veiksmų eigos ciklas, atvaizduojamas paslaugą ar produktą teikiančio aktoriaus požiūriu, kai teikiantis aktorius yra pagrindinis veikėjas. Pavyzdžiui, kliento užsakymas iššaukia ERSD atvejį kliento užsakymo patenkinimui. 3. Aprūpinimo kontrolės diagrama (AKD) Ši diagrama modeliuoja resursų, reikalingų atlikti ekonominiam atvejui, rezervavimą ir užsakymą. 4. Priešingų atvejų diagrama (PAD) Ši diagrama atvaizduoja tuos procesus, kurie vykdomi esant įvairioms alternatyvoms, jeigu užklausa neišpildoma. Galutinis vykdomas procesas yra aprašytų diagramų rinkinys. Iš verslo modelio galima gauti pirminį proceso modelį, kiekvienam ekonominiam atvejui sukuriant ekonominių resursų užklausos diagramą ir ekonominį resursą siūlančią diagramą. Tačiau šios diagramos dar neleidžia pilnai pereiti nuo verslo modelio prie procesų modelio, tam yra skirta P 3 verslo proceso modeliavimo metodika. XIV 54

57 UML išplėtimas verslo modeliavimo kalbos savybėmis Dažnai projektuotojai toliau neplėtoja BML kalba užrašyto sistemos verslo modelio, kurio negalima efektyviai panaudoti, nes jis tik nurodo statinę sistemos būseną arba tam tikrus verslo eigos etapus. Šį BML modelį galima transformuoti į procesų modelį, sistemiškai taikant P 3 metodus. Jei verslo modelis vaizduoja aktorių apsikeitimą verte, tai procesų modelis atspindi nuoseklią aktorių veiksmų tvarką komunikacinių veiksmų metu. Šis perėjimas nuo vieno modelio prie kito projektavimo procese reikalauja daug ir sudėtingų sprendimų Verslo proceso modelio sudarymas P 3 verslo proceso kūrimo eiga apima keturias atskiras fazes, per kurias projektuotojas sukuria veikiantį verslo proceso modelį: Verslo modelio projektavimas Ekonominių atvejų tvarkos sukūrimas Procesų tvarkos sukūrimas Procesų modelio generavimas pav. Verslo procesų modelio kūrimo fazės ( K-A laikas reiškia klausimų ir atsakymų laiką ) Bendrai paėmus, šios fazės gali būti laikomos sisteminiu verslo modelio transformacijos procesu, kurio rezultate gaunamas vykdomas procesų modelis, kurį galima automatiškai realizuoti tinkamoje programinėje aplinkoje. Pirmosios trys fazės yra klausimų ir atsakymų sesijos, kur projektuotojas atsako į klausimus, vedančius prie skirtingų projekto sprendimų. Galutinėje P 3 metodo fazėje sudaromas proceso modelis BML kalba. Verslo proceso modelio sudarymo procesą galima formalizuoti. Verslo modelį sudaro trys dalys: M = (A, VO, VP) A aktorių aibė; VO vertės objektų tipų aibė; VP vertės perdavimo tipų aibė. Verslo tvarkos (VT) sukūrimo metu apibrėžiamas vertės perdavimo procesų eiliškumas (dalinis VP elementų sutvarkymas), nedetalizuojant perdavimo elementų: VP i < VP j, VPi, VPj VP, kur A < B reiškia, kad A turi būti įvykdyta anksčiau, negu B. Procesų tvarkos (PT) sukūrimo metu verslo tvarka papildoma komunikacinių veiksmų (KV) tvarka (daliniu sutvarkymu): PT = VT KV, KV= {KV i <KV j, KV i, KV j KV}. Tai yra, specifikuojamos priklausomybės tarp komunikacinių veiksmų. Kiekvienam VPi VP sudaroma viena komunikacinių veiksmų kilpa, atvaizduojama BML įėjimo arba išėjimo diagrama (įėjimo diagramoje pagrindinis aktorius gauna vertę iš kito aktoriaus, išėjimo diagramoje pagrindinis aktorius perduoda vertę kitam aktoriui). Komunikacinių veiksmų kilpos susideda iš kelių veiksmų tipų. Įėjimo diagramos šablonas apibrėžia tokius veiksmus: - pranešimo siuntimas (direktyva) dirvp kai pagrindinis aktorius siunčia pranešimą, prašydamas perduoti vertės objektą; 2 - pranešimo siuntimas - (atmetimas) atvp, kai aktoriui-iniciatoriui siunčiamas atsisakymas įvykdyti užklausą atvp, arba sutikimas sutvp; 3 - pranešimo siuntimas (direktyva) dirvp, kai vykdytojas praneša apie įvykdytą perdavimą; 4 - pranešimo siuntimas (tvirtinimas) tvvp kai pagrindinis aktorius siunčia pranešimą, patvirtindamas vertės gavimą. XIV 55

58 L.Nemuraitė, P.Zakšauskienė Išėjimo diagramos šablonas apibrėžia tokius veiksmus: - pranešimo gavimas dirvp kai pagrindinis aktorius gauna pranešimą su užklausa perduoti vertę; 2 derinimas susideda iš kelių pranešimų - užklausų pranešimų siuntimo uzk ir atsakančių pranešimų siuntimo ats, kurie lydi kiekvieną užklausą; 3 atsakymų įvertinimas pagrindinis aktorius sutinka vykdyti direktyvą (siunčia pranešimą tvirt) arba atmeta direktyvą (siunčia pranešimą atm); 4 pagrindinis aktorius įvykdo direktyvą ir deklaruoja apie tai - siunčia pranešimą deklvp; 5 gavėjas patvirtina, kad jo direktyva įvykdyta siunčia pranešimą tvirtvp. Procesų modelis sudaromas iš PT, taikant tokias taisykles: taisyklė apibrėžia vertės perdavimo elemento atidėjimą iki kito elemento įvykdymo pabaigos: VP i < VP j VT : Add(D j, {stop, D i }); Add(D i, {laukti dekl, D j }), kur operacija Add(<šaltinio/tikslo diagrama>, {<portas>, <porto diagrama>}) reiškia, kad porto diagramoje turi būti sukurta būsena, kuri turi ryšį su <šaltinio/tikslo diagrama>. Įėjimo portu suprantama būsena, į kurią yra perėjimas iš kitos diagramos, išėjimo portu suprantama būsena, iš kurios yra perėjimas į kitą diagramą. Portų pagalba skirtingos diagramos susiejamos tarpusavyje į bendrą procesą, stop, laukti dekl pabaigos ir deklaravimo laukimo būsenos. 2 taisyklė apibrėžia, kad prieš tvirtinant sutikimą perduoti vertę reikia gauti atsakymą dėl ankstesnės užklausos: sut(vp i ) < sut(vp j ) PT : Add(D j, { sut(v i ), D i }); Add(D i, {ats, D j }). 3 taisyklė apibrėžia, kad prieš tvirtinant sutikimą perduoti vertę būtų perduota vertė: dekl(vp i ) < sut(vp j ) PT : Add(D j, {Stop, D i }); Add(D i, {ats, D j }). 4 taisyklė reikalauja perduoti vertę prieš prašant kito vertės perdavimo (t.y., prieš atitinkamos diagramos pradžios (start) būseną): dekl(vp i ) < dir(vp j ) PT : Add(D j, {Stop, D i }); Add(D i, {start, D j }). 5 ir 6 taisyklės užtikrina modelio pilnumą: D j : if (D i, {ats, D j }) [ (D i, {uzk, D j })] then Add (D i, {uzk, D j }), D j : if (D i, {uzk, D j }) [ (D i, {ats, D j })] then Add (D i, {ats, D j }). 7 taisyklė pašalina visus perteklines diagramų tarpusavio sąveikas: D j : if (D j, {<išėjimo portas>, D i }) (D j, {<įėjimo portas>, D i }) [ (D i, {<įėjimo portas>, D j })] if (D j, { (<bet kuri būsena>, {start, D i }) then Add (D i, {start, D j }) Else Remove(D j, {Uzk, D i }) Pradinis proceso modelis sudaromas, įvedant po vieną diagramą kiekvienam 2 fazėje identifikuotam vertės perdavimo elementui. Taikant aprašytas taisykles visoms procesų tvarkos nelygybėms, įvedami diagramų tarpusavio ryšiai, atspindintys aktorių perduodamus ir gaunamus pranešimus. 4. Verslo procesų modeliavimas UML aplinkoje Kaip jau minėta, BML kalbos notacija neatsiejamai surišta su P 3 metodika. Sudarytas BML ir UML atitikimo modelis leidžia palyginti dvi modeliavimo kalbas bei naudoti UML kalbos notaciją kuriant verslo procesų aprašus pagal P 3 metodiką. BML gali būti naudojama aprašyti sistemos struktūrai ir veikimui, taikant dviejų tipų diagramas. Statinėje diagramoje vaizduojami procesai statinėje būsenoje, pranešimai tarp procesų bei procesų ir aplinkos (išorinių programų ar žmonių). Dinaminis sistemos veikimas aprašomas, naudojant procesų diagramas, kurios vaizduoja procesų valdymo sekas, t.y. tvarką, pagal kurią siunčiami ir gaunami pranešimai. Šiame darbe sudarytas modelis, kurio pagalba galima UML kalboje atvaizduoti abu diagramų tipus. Statinių diagramų atvaizdavimui naudojamas UML veiklos diagramos elementų poaibis. 2 paveiksle pateiktas statinės BML diagramos pavyzdys. XIV 56

59 UML išplėtimas verslo modeliavimo kalbos savybėmis Atvaizduojant procesus statine diagrama, galima sugrupuoti juos į stambesnius procesus, tokiu būdu išsamiau parodant bendrą sistemos architektūrą. Kiekvienas procesas identifikuojamas vardu ir gali turėti daug egzempliorių, kiekvienas egzempliorius turi savus duomenų modelio egzempliorius, kuriuose nurodomi proceso egzemplioriaus naudojami pranešimai ir jų reikšmės. Kiekvienas procesas turi galimybę siųsti kitiems procesams ir sistemos veikėjams pranešimus bei gauti pranešimus iš jų. Pranešimų eilė yra nurodoma kiekviename ryšyje, tarp dviejų diagramos elementų užrašant pranešimo numerius laužtiniuose skliaustuose. Tokį procesų modelį galima atvaizduoti UML veiklos diagrama, kuri pateikta 3 paveiksle. 2 pav. BML statinė diagrama, vaizduojanti sistemos procesų struktūrą (čia m i siunčiami ir gaunami pranešimai) 3 pav. UML veiklos diagrama, atvaizduojanti statinės BML diagramos elementus Proceso sąvokai realizuoti UML kalba galima naudoti sudėtinės veiklos elementą (Subactivity State) [3, skyrius ]. Sudėtinės veiklos elementas nurodo sudėtinį veiksmą, susidedantį iš eilės žingsnių, trunkančių tam tikrą laiko tarpą. Pranešimo arba signalo siuntimo ir gavimo elementai UML notacijoje atvaizduojami kaip išgaubtas ir įgaubtas penkiakampis [3, 3.9.]. Signalo gavimo simbolio viduryje rašomas iš jo išeinančio perėjimo trigerio vardas. Signalo siuntimo simbolio viduryje įrašomas į jį įeinančio perėjimo poveikis (Effect Action). Kadangi BML notacijoje prie pranešimo siuntimo ir gavimo elementų galima nurodyti veikėją (arba procesą), gaunantį arba siunčiantį pranešimą, UML notacijoje objekto simbolis punktyrine linija su rodyklėmis sujungtas su signalo siuntimo ir signalo gavimo elementais rodo signalo siuntėją bei gavėją. BML dinaminių diagramų atvaizdavimui UML kalba taip pat pakanka veiklos bei būsenų diagramoms priklausančio elementų poaibio. Dinaminės BML procesų diagramos realizuoja veiksmų eiliškumą konkretaus proceso vykdymo metu. Kiekviena diagrama turi pradžios ir pabaigos būsenas bei pranešimų siuntimo ir gavimo elementus. P 3 metodikoje įvesti išplėtimai leidžia nurodyti jungtis tarp diagramų, kurios gali būti susijusios su bet kuria iš būsenų. Pranešimų siuntimo ir gavimo elementams nurodomi su šiuo veiksmu susiję aktoriai arba kiti sistemos procesai. Procesų diagrama taip pat gali būti atvaizduota naudojant UML veiklos diagramos notaciją (5 pav.). XIV 57

60 L.Nemuraitė, P.Zakšauskienė Pradžios būsenos atvaizdavimas UML kalboje galimas panaudojant kilpos būseną (stubstate) [3, skyrius 2.2.2]. Kilpos būsena tarnauja kaip perėjimo (Transition) tikslas arba šaltinis, kuris sujungiamas su pagrindine būsena, esančia šioje diagramoje, ir eina į kitą būseną tame būsenų mechanizme, kuris yra nurodytas diagramų tarpusavio jungtyje. UML kalboje nėra išskirta atskiro elemento laukimo būsenai. Ji gali būti atvaizduojama bendru būsenos elementu su tam tikromis specifikacijos detalėmis, bet galima laukimo būseną vaizduoti ir veiksmo būsenos elementu, kuri vaizduoja atominį veiksmą, paprastai tam tikros operacijos iškvietimą ir vykdymą. Laukimo būsenos įvedimas leidžia tiksliau atvaizduoti proceso semantiką, kadangi pagal UML veiklos diagramų semantiką perėjimas iš vieno veiksmo į kitą įvyksta, iš karto pasibaigus veiksmui, tuo tarpu veiklos procesuose yra daug situacijų, kai pasibaigus vienam veiksmui, kitas veiksmas pradedamas tik įvykus tam tikram įvykiui (gavus pranešimą). Pranešimo gavimas Pranešimo siuntimas Perėjimas iš kitos diagramos 4 pav. BML dinaminė procesų diagrama Perėjimas į kitą diagramą Pranešimo gavimas Pranešimo siuntimas Perėjimas iš kitos diagramos 5 pav. UML Veiklos diagrama, atvaizduojanti dinaminės BML diagramos elementus 5. Programinės įrangos prekybos verslo modelis, taikant UML BML išplėtimus Sudaryta verslo procesų modeliavimo metodika buvo ištirta eksperimentiniu būdu, sudarant programine įranga prekiaujančios organizacijos verslo modelį (6 pav.) Pirmiausia sudaroma verslo tvarka (VT) pilnai aprašomi ekonominiai įvykiai, pvz.: <K, PS, Apmokėjimas> - ApmokėjimasIšKliento (K klientas, PS prekybos sistema); <K, PS, Klausimas> - KlientoKlausimasPS; ir jų eilės tvarkos apribojimai: ApmokėjimasIšKliento < KomercinėVersijaKlientui, KomercinėVersijaKlientui < ApmokėjimasUžTAptarnavimą, ir t.t. Aprašant procesų tvarką, proceso projektuotojas turi pateikti verslo ekspertui eilę klausimų: Ar reikia vykdyti ApmokėjimasIšKliento prieš patvirtinant KomercinėVersijaKlientui vykdymą? XIV 58