ISSN 1392 – 124X INFORMACINËS TECHNOLOGIJOS IR … · kriminalistikos mokslo taktines ir metodines rekomendacijas. Tyrėjai ir teisėjai dalyvauja pažinimo procese, kurio esmę

XII SEKCIJA Informacinių sistemų projektavimo metodai ir

technologijos

ONTOLOGIJOS REIKŠMĖ KURIANT KRIMINALISTINĘ INFORMACINĘ SISTEMĄ

Dalė Dzemydienė, Eglė Kažemikaitienė Lietuvos teisės universitetas, Teisinės informatikos katedra

Matematikos ir informatikos institutas Lietuvos teisės universitetas Kriminalistikos katedra

[email protected], [email protected]

Straipsnyje nagrinėjami pagrindiniai reikalavimai kriminalistinės informacijos struktūrizavimui ir ontologijos kūrimui. Ontologijų pagrindu kuriama kriminalistinė informacinė sistema užtikrina reikiamą informacijos struktūros modelio taikymą, apibrėžia pagrindines taisykles kaip iš išorinių ir vidinių pirminių duomenų apie nusikaltimų tyrimą gauti reikšmingą kriminalistinę informaciją. Ontologija padeda sukurti darbo struktūrą ir tokiu būdu užtikrinti tyrimui reikšmingos informacijos kaupimą, saugojimą, apdorojimą bei perdavimą vartotojams reikiamu pavidalu ir sudarant galimybes priimti optimalius sprendimus.

1. Įvadas

Tiriant nusikaltimus sprendžiama gana daug sudėtingų taktinių, techninių, kriminalistinių uždavinių [1, 10]. Nusikaltimo tyrimo metu kylančius uždavinius galima suskirstyti į dvi pagrindines grupes: uždavinius grynai kriminalistinio pobūdžio ir uždavinius, susijusius su baudžiamąją teise, baudžiamuoju procesu, organizacinius, kriminologinius. Pirma uždavinių grupė gali būti sprendžiama pasitelkus kriminalistinę informaciją, kitai uždavinių grupei spręsti reikalinga informacija iš baudžiamos teisės, baudžiamojo proceso ir pan., kuri konkretaus nusikaltimo tyrimo metu būtų kriminalistiškai reikšminga. Kriminalistinė informacija - tai, visų pirma, nusikalstamą įvykį ir jo tyrimą atspindintys duomenys. Žinoma labai svarbūs yra kriminalistinį tyrimą išaiškinti padedantys duomenys.

Tikslas sukurti patariamojo pobūdžio informacinę sistemą, kad tyrėjas galėtų gauti pagalbinio ir konsultacinio pobūdžio informaciją susijęs su daugeliu kompleksinių informacinių technologinių uždavinių. Kriminalistinei informacinei sistemai, turinčiai pirminę kriminalistinę informaciją, keliami reikalavimai turėti galimybę pateikti užklausimus kitoms reikiamoms informacinėms sistemoms, gauti iš jų atsakymus, ir remiantis jais pateikti jau apdorotą antrinę informaciją, tyrimo vykdymo versijas ir galimus sprendimo būdus. Savo ruožtu tyrėjas, gavęs jau apdorotą informaciją, remiantis ja ir savo loginiu mąstymu priimtų reikiamą sprendimą.

Kriminalistinė registracija yra labai reikšmingas kriminalistikos mokslo bei nusikaltimų tyrimo praktikos raidos etapas, todėl negalima pamiršti to, kas jau yra sukurta, t.y. kriminalistinių registrų, automatizuotų ir dalinai automatizuotų įskaitų, kartotekų, kolekcijų bei duomenų bazių.

Tačiau registracinio pobūdžio sistemų neužtenka atliekant sudėtingą nusikaltimų tyrimo informacinio aprūpinimo darbą [8]. Būtų tikslinga turėti informaciją apie įvairių rūšių nusikaltimų įvykio vietos apžiūros praktiką, t.y. žinias apie įvairių rūšių nusikaltimų vietų apžiūros taktiką ir jos ypatumus, bei įvairių rūšių nusikaltimų vietų apžiūros strategijas – kur ieškoti pėdsakų, kokį apžiūros planą sudaryti, kokius uždavinius spręsti [11]. Dar viena ypatybė, kalbant apie įvykio vietos apžiūros informacinį aprūpinimą, - tai vieta, iš kurios tyrėjas galėtų pasiųsti užklausimą į kriminalistinę informacinę sistemą.

Antros grupės klausimų išsprendimas turi ne mažesnę reikšmę, kuriant kriminalistinę informacinę sistemą. Pavyzdžiui, gavus pranešimą ar pareiškimą apie įvykį, tyrėjas privalo išspręsti ar yra čia nusikaltimo požymių. Jam padėti gali tokia informacinė sistema, kurioje bus įvesta informacija su išryškintais nusikaltimų požymiais [3]. Tokie kaip pavyzdžiui, konkrečios smurtinės žymės ar kiti konkretūs kūno pažeidimai, būdingi įvairiems smurto atvejams. Kiekvienas nusikaltimas turi šiai nusikaltimo rūšiai būdingus požymius, kurie turi būti išryškinti kriminalistinėje informacinėje sistemoje.

Kitas tyrėjo uždavinys būtų tinkamas nusikalstamos veikos kvalifikavimas. Todėl tyrėjas turi turėti priėjimą prie atitinkamos informacijos, t.y. informacijos iš baudžiamosios teisės: baudžiamieji įstatymai, baudžiamųjų įstatymų komentarai ir aiškinimai, teismų praktika.

Ontologijų kūrimo metodai bei technologijos ir jų galimybių panaudojimas įvairioms bendradarbiavimo formoms vystyti padeda tokių sistemų kūrimo procesuose [4, 12]. Svarbu pasirinkti kuo patogesnį atitinkamos tematikos pateikimo būdą, įvesti aktualijų propagavimo ir analizės modulius į kuriamą žinių sistemą, įvertinant informacijos struktūrinimo principus ir atskleidžiant semantiką. Tačiau gan problematiški yra dinamiško šių procesų

– 1 –

mailto:[email protected]

mailto:[email protected]

D. Dzemydienė, E. Kažemikaitienė

valdymo klausimai, kurie ypač aktualūs sprendžiant semantiškai grindžiamos informacijos sklaidos, žinių išsaugojimo ir išgavimo uždavinius.

Ontologijų kūrimas ir taikymas leidžia susisteminti surinktus duomenis, įvertinti skleidžiamų žinių struktūrą ir jų kūrimo procesą [7]. Ontologijų terminas pradėtas naudoti dirbtinio intelekto srityse, kalbant apie žinių bendrą naudojimą, programinių agentų tarpusavio sąveiką, visuotinai pripažįstamų žinių vaizdavimą, natūralios kalbos apdorojimą ir kt. Ontologija - tai tam tikros srities sąvokų visumos specifikavimas išreikštu pavidalu. Ontologijų kūrimas yra iteracinis procesas. Dažniausiai naudojamos ontologijų kūrimo metodikos: M.Uschold’o metodika, M.Grüninger’io ir M.S.Fox’o (TOVE) metodika; METHONTOLOGY karkasas; KACTUS metodika; On-To-Knowledge (OTK) metodika [12, 13]. Šių metodikų taikymas žymai palengvina komponentinių žinių sistemų kūrimo procesus konkrečioje dalykinėje srityje.

Analizuojant intelektualių informacinių sistemų komponentes, svarbu nagrinėti, kaip vaizduoti kriminalistines žinias, kokiais metodais kurti sprendimų rengimo sistemas. Tuo tikslu mėginama nusakyti šių metodų taikymo prasmę, įvardijant sprendimų priėmimo uždavinius, kuriant kriminalistinės informacijos ontologiją.

2. Nusikaltimų tyrimo informacinio aprūpinimo specifika

Kriminalistinės dalykinės srities specifika dažniausiai susijusi su formalizuojamų reiškinių struktūrizavimo ir aprašymo problemomis. Kuriant intelektualizuotas sistemas šioje dalykinėje srityje reikia taikyti papildomus metodus, siekiant aprašyti sudėtingas sprendimo situacijas, neformalius sprendimo priėmimo būdus [4, 6]. Svarbu atsiriboti nuo galimų subjektyvių veiksnių, darančius įtaką vieno ar kito sprendimo priėmimui, netikslios ir melagingos informacijos galimybių ir pan.

Analizuojant intelektualių informacinių sistemų kūrimo etapus svarbios yra žinios, kurios turėtų padėti suprasti, kaip taikyti sprendimų rengimo, patariamųjų sistemų kūrimo metodus, užrašant teisės specialistų sukauptą patirtį kompiuterinei sistemai suprantama kalba.

Tiriamas nusikaltimo įvykis

Fiksuojami materialūs ir nematerialūs nusikaltimo duomenys

Nustatomi būsenos savybių, materialių objektų kokybės pasikeitimai

Nustatoma faktinė šių pasikeitimų informacija

Gaunami įrodymai: duomenys apie faktinės informacijos ryšį su tiriamojo

įvykio aplinkybėmis

1 pav. Nusikaltimą įrodančiosios informacijos tyrimo etapai

Kriminalistinė informacija turi aprašyti nusikaltimo įvykio aplinkybes, jų mechanizmą ir atskirus nusikaltimo padarymo dėsningumus. Duomenys apie asmenis, padariusius nusikaltimą, nusikaltimo pėdsakus, duomenys apie nusikaltimo kriminalistinę charakteristiką ir versijas sudaro pagrindą kriminalistinės informacinės sistemos kūrimui. Nusikaltimų tyrimo procese reikšmingos yra žinios apie nusikaltimų tyrimo metodiką, baudžiamąjį procesą bei kitas kriminalistikos mokslo taktines ir metodines rekomendacijas. Tyrėjai ir teisėjai dalyvauja pažinimo procese, kurio esmę sudaro įvykio atkūrimas pagal aplinkoje paliktus pėdsakus, kurie yra fiksuojami ir atpažystami, kad iš nežinomos priežasties veiksnių taptų nusikaltimo įrodymais. Įrodomosios informacijos kūrimas, perkėlimas ir transformacija vyksta nuosekliai vienu ar kitu aspektu ir atspindi daugiapakopius ir struktūrinius priežastinius ryšius aprašančius nusikalstamą veiką (1pav.).

– 2 –

Ontologijos reikšmė kuriant kriminalistinę informacinę sistemą

Kriminalistinė informacinė sistema turi aprūpinti tyrėją kokybiškai apdorota informacija ir drauge padėti priimti pagrįstus sprendimus svarbiais nusikaltimo tyrimo klausimais: iškelti versijas, parinkti vienokią ar kitokią tyrimo taktiką, nusikaltimo tyrimo strategiją, keisti savo elgesį atliekant tyrimą ir pan. Todėl kriminalistinė informacinė sistema tampa nusikaltimų tyrimo praktinės veiklos instrumentu. Nusikaltimo tyrimo informacinis aprūpinimas yra sudėtinga sistema, kuri nusakoma šiais specifiniais bruožais:

• kriminalistinės informacinės sistemos tikslas yra padėti tyrėjui greitai ir efektyviai ištirti nusikaltimą, atliekant rutininius daug informacijos reikalaujančius darbus ir tuo pačiu sukurti prielaidas tiklingam tyrimui;

• kriminalistinė informacinė sistema kuriama vadovaujantis kriminalistikos bei kitų, nusikaltimų tyrimui reikšmingų, mokslų rekomendacijomis atitikant pagrindinį tikslą – nusikaltimo tyrimą, atskleidimą ir prevenciją;

• sistema turi būti teisiškai reglamentuota; • duomenys turi būti prieinami ribotam vartotojų ratui, užtikrinamas jų saugumas, vadinasi kriminalistinė

informacinė sistema nėra viešo naudojimo informacinė sistema, ji yra riboto naudojimo; • duomenų apdorojimas tokioje sistemoje turi atitikti kriminalistinius tyrimo uždavinius; • informacinių procesų optimizavimas įgyvendinamas per jų automatizavimą ir technologinį realizavimą.

Informacinių procesų automatizavimas vykdomas griežtai vykdant būtinas procedūras, kurias sudaro: • nusikaltimų tyrimo procese naudojamos informacijos objektų, rūšių ir pobūdžio nustatymas; • tyrimo informacijos analizė dėl tyrimo informacinio aprūpinimo trūkumų nustatymo ir įmanomų tyrėjo

darbo automatizavimo krypčių nustatymo; • kriminalistinės informacinės sistemos projektavimas; • sukurtos kriminalistinės informacinės sistemos diegimas į tyrimą; • automatizuotos kriminalistinės informacinės sistemos kontrolė, pakeitimų įvedimas jos tobulinimo tikslais.

3. Ontologijos kūrimas kriminalistinėje dalykinėje srityje

Ontologijos samprata susijusi su konceptualizavimu, intencionalaus modeliavimo sąvoka, kalbos parinkimu [7]. Ontologijos reikšmė susijusi su aibės loginių aksiomų nagrinėjimu, projektuojant ir išreiškiant intencionalinę žodyno reikšmę. Konceptualizavimo supratimas reikalauja atitinkamo formalizavimo. Konceptualizavimas yra apibrėžiamas [14] kaip struktūra <D,R>, kur D yra nagrinėjamos srities erdvė, R yra aibė atitinkamų ryšių srityje D. Loginės kalbos L nagrinėjimą siejame su atitinkamu žodynu V. Galime apibrėžti modelį kalbai L kaip struktūrą <S,I>, kur S =<D,R> yra pasaulio struktūra ir I: V D∪R yra interpretavimo funkcija priskirianti srities D elementams pastovius simbolius iš V, o elementams iš R predikatinius simbolius iš V. Intencionalaus interpretavimo sąvoka apibrėžiama per struktūros <C,J> priemones, kur C =<D,W,R> yra konceptualizavimas, D nagrinėjama sritis, W - aibė situacijų pasireiškimų ir J:V D∪R. Galima išskirti skirtigus ontologinius apibendrinimo lygius: • Aukščiausio lygio ontologijos apibrėžia labai bendras sąvokas (konceptus), tokias kaip erdvė, laikas, materija,

objektai, įvykiai, veiksmai; • Srities ontologijos ir užduočių ontologijos apibrėžia žodyną susijusi su bendrają sritimi (pvz. medicina, teise,

automobilizmu) arba bendras užduotis kaip (diagnozavimas, pardavimas) specializuojant terminus įvestus aukščiausio lygio ontologijoje;

• Taikomosios ontologijos aprašo sąvokas (konceptus) priklausančius konkrečiai sričiai ir užduotims ir yra tam tikra jų specializacija. Sąvokos dažniausiai atitinka rolėms, kurias vaidina srities esybės atlikdamos tam tikrus veiksmus (veikas.) Taikomojo lygmens kriminalistinės dalykinės srities ontologija kuriama pasitelkiant unifikuotą modeliavimo

kalbą UML, taikant objektinę projektavimo metodiką [2] ir yra skiriama informacinės sistemos kūrimui. Šie darbai jau vykdomi keletą metų ir kai kurie jų sprendimo aspektai aprašyti [6].

Kriminalistinė informacinė sistema turėtų užtikrinti komponentų integruotumą ir galėtų dirbti kaip vientisa sistema, vadinasi jai keliami tokioms sistemoms būdingi reikalavimai [14]: • Nepriklausomai nuo atskirų komponentų konkrečios paskirties ir rūšies kriminalistinei informacinei sistemai

yra būdinga kokybė, kuri negali būti suvedama vien į sistemą sudarančių elementų savybes. • Kokybinės kriminalistinės informacinės sistemos savybės priklauso nuo sudarančių elementų kokybinių

savybių.

– 3 –


• Tarp kriminalistinės informacinės sistemos elementų yra glaudus ryšys. Tuo tarpu tie ryšiai tokie glaudūs, kad vieno sistemos komponento pasikeitimas sąlygoja kitų komponentų, o kai kada ir visos sistemos pasikeitimą.

• Kriminalistinę informacinę sistemą kaip vientisą sistemą charakterizuoja į ją įeinančių elementų, o taip pat ryšių tarp jų, taisyklinga tvarka. Labiausiai tai pasireiškia informacinės sistemos struktūroje bei organizacijoje.

• Kaip ir bet kuri vieninga sistema kriminalistinė informacinė sistema negali egzistuoti izoliuotai, be ryšio su išoriniu pasauliu. Kriminalistinė informacinė sistema sąveikauja su realiu pasauliu bei kitomis informacinėmis sistemomis. Ji yra dinamiška ir besivystanti informacinė sistema. Mūsų nagrinėjamos srities problematiką galima būtų apriboti nusikaltimų tyrimo nagrinėjimu kaip išorinio

pasaulio modelio sukūrimu grindžiamu ontologiniu požiūriu. Nagrinėjami pagrindiniai duomenų srautai išskiriant nusikaltimo įvykį kaip procesą, sudaromi duomenų srautų

ir juos transformuojančių procesų modeliai (pavyzdys pateikiamas 2 pav.). Nusikalstamo įvykio tyrimas, remiantis [10, 14], gali būti detalizuojamas: • informacijos apie tiriamąjį įvykį šaltinių suradimas (nustatymas); • informacijos apie tiriamąjį įvykį gavimas iš šaltinių; • atskirų tiriamojo įvykio aplinkybių nustatymas; • bendros informacinės sistemos sudarymas ir tiriamojo įvykio faktinės struktūros nustatymas. Taigi, visa veikla susijusi su nusikaltimų tyrimu, yra skirta vienam bendram galutiniam tikslui pasiekti –

nusikaltimo įvykio struktūros nustatymui.

Nusikaltimo įvykis

Atliekama ekspertizė Ikiteisminis nusikaltimo tyrimas

Operatyvinė paieškos veikla

Kriminalistinės įskaitos ir

registracijos DB

Kriminalistinių ekspertizių

praktikos DB

Nustatomi įrodymai/ įkalčiai

Nusikaltimas klasifi-kuojamas pagal

baudžiamąjį kodeksą

Tyrimo medžiaga perduodama teismui

2 pav. Nusikaltimo ikiteisminio tyrimo pagrindinių duomenų srautų diagrama

Ikiteisminis nusikaltimo tyrimas grindžiamas kriminalistikos mokslo žiniomis apie nusikaltimų tyrimo atlikimą, planavimą, tyrimo situacijas, tipines nusikaltimo versijas ir pan. Čia svarbūs archyvinių baudžiamųjų bylų duomenys bei baudžiamosios statistikos duomenų bazėse sukaupta informacija.

Kriminalistinės informacijos ontologija – tai visų pirmą, nusikalstamo įvykio ir jo tyrimo atspindys; tai informacija, aprašanti nusikaltimo įvykio aplinkybes, jų mechanizmą ir atskirus nusikaltimo padarymo dėsningumus, duomenys apie asmenis, padariusius nusikaltimą, nusikaltimo pėdsakus, duomenys apie nusikaltimo kriminalistinę charakteristiką, versijas, o taip pat žinios apie nusikaltimų tyrimo metodiką, baudžiamąjį procesą bei kitas kriminalistikos mokslo taktines ir metodines rekomendacijas.

Klasių diagramų pavyzdžiai pateikiami 3 ir 4 pav. aprašant nusikaltimo charakteristiką ir nusikaltimų hierar-chiją.

– 4 –

Ontologijos reikšmė kuriant kriminalistinę informacinę sistemą

3 pav. Nusikaltimų charakteristikos aprašymo pavyzdys UML kalboje

Remiantis nusikaltimų klasifikacija pagal galiojančius baudžiamuosius įstatymus, pavyzdžiui, Lietuvoje1 tai būtų: nusikaltimai žmoniškumui ir karo nusikaltimai (genocidas ir t.t.), nusikaltimai žmogaus gyvybei (nužudymas ir t.t.), nusikaltimai ir baudžiamieji nusižengimai nuosavybei, turtinėms teisėms ir turtiniams interesams (vagystės, turtinės žalos padarymas apgaule, turto sunaikinimas ar sugadinimas ir t.t.), nusikaltimai ir baudžiamieji nusižengimai ekonomikai ir verslo tvarkai (kontrabanda ir kt.) ir t.t., - iš viso apie du šimtus įvairių nusikaltimų rūšių. Savo ruožtu atskiros nusikaltimų rūšies informacinio bloko sudarymas turi remtis kriminalistine nusikaltimų charakteristika ir jos elementais [9, 10].

Nusikaltimai

Nusikaltimai žmoniškumui

Nusikalt. žmogaus gyvybei

Baudž. nusižengimai nuosavybei

Baudž. nusižengimai ekonomikai ir verslo tvarkai

Vagystės

Turtinė žala

Turto sunaikinimas

4 pav. Nusikaltimų klasifikacijos pavyzdys UML kalboje

Kriminalistinė informacija turi atitikti tokias savybes: informacijos reliatyvumo (dinamiškumo), informacijos kompleksiškumo (išsamumo), informacijos savalaikiškumo (operatyvumo), informacijos patikimumo (tikrumo), informacijos prieinamumo, informacijos saugumo, informacijos ergonomiškumo ir informacijos moksliškumo.

1 Lietuvos Baudžiamasis kodeksas, patvirtintas 2000 09 26 d. įstatymu Nr. VIII-1968. – Specialioji dalis: 99-329str.

– 5 –


Kriminalistinės informacijos šaltiniais būtų materialūs ir nematerialūs (idealūs) objektai plačiąja prasme, kurie susiję pagal nusikaltimo įvykdymo aplinkybes ir kuriuose slypi informaciją apie tas aplinkybes.

4. Išvados

Nusikaltimų tyrimo efektyvumas priklauso nuo patariamosios kriminalistinės informacinės sistemos kokybės. Taigi, kriminalistinė informacinė sistema suprojektuota, grindžiant ontologinėmis nuostatomis, paverčianti išorinius ir vidinius duomenis kriminalistine informacija, užtikrinanti kriminalistinės informacijos kaupimą, saugojimą, apdorojimą ir perdavimą vartotojams reikiamu pavidalu sudaro galimybes priimti optimalius sprendimus. Pagrindinis tokios informacinės sistemos tikslas būtų nusikaltimų tyrimo informacinis aprūpinimas, ypač ikiteisminio tyrimo, o kriminalistinės informacinės sistemos tikslinė paskirtis – padėti nusikaltimo tyrėjui nepažeidžiant žmogaus ir piliečio teisių bei laisvių, visuomenės ir valstybės interesų, greitai ir išsamiai išaiškinti nusikaltimus ir pagrįsti įtariamų asmenų kaltę.

Literatūra [1] Andersen, M. Bryde. Problems of Description in Computer Tort Law. – Nordic Studies in Information Technology and

Law. Ed.: Blume, P. Kluwer Law and taxation Publishers. Deventer – Boston. 1991, pp. 110-131. [2] Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language User Guide. Addison Wesley.1999. [3] Burda R. Nusikaltimai ekonomikai: sampratos modeliavimas ir šiuolaikinė tyrimo metodikos koncepcija /daktaro

disertacija/. – V., 2000. – p.60. [4] Čaplinskas, A., Poškevičius,V., Misiūnas, J. Kai kurios baudžiamosios teisės ontologijos problemos. Jurisprudencija,

16(8), Mokslo darbai. LTA. Vilnius. 2000, pp.118-131. [5] Dzemydiene D. Conceptual Architecture for Dynamic Domain Representation. Mathematical Modelling and Analysis. R.

Ciegis (ed) Vol, 5. Vilnius, Technika. 2000, pp. 55-66. [6] Dzemydiene D., Kazemikaitiene E., Petrauskas R. Knowledge Representation in Advisory information System of Crime

Investigation Domain. In. Hele-Mai Haav, Ahto Kalja (Eds.) Databases and Information Systems II. Kluwer Academic Publishers. 2002. pp. 135-148.

[7] Guarino N. Formal Ontology and Information Systems. In. N. Guarino (ed. ) Formal Ontology in Information Systems. Proceedings of FOIS’98. Italy. Amsterdam. IOS Press. 1998, pp. 3-15.

[8] Hebenton B., Terry T. Criminal Records. – Brookfield USA. 1993 [9] Kovacich G.L. Boni W. Hig Technology- Crime Investigator’s handbook: Working in the Global Information

Environment. Butterwoth- Heinemann. 2000, pp. 115-136. [10] Kuklianskis S., Matulienė S. Kriminalistinės nusikaltimų charakteristikos samprata. // Jurisprudencija, 29(21) tomas.

Vilnius, 2002. – p.49-65. [11] Malevski H. Įvykio vietos apžiūra ir įvykio vietos tyrimas: naujos kriminalistinės koncepcijos modelis /daktaro disertacija/.

– V., 1997. [12] Maskeliūnas S. Ontological Engineering: Common Approaches and Visualisation Capabilities // Informatica, Vol. 11,

2000, No. 1, pp. 41-48. [13] Maskeliūnas S. Modernių informacinių sistemų ontologijos ir paslaugų reikalavimų formulavimas. Konf. Informacinės

technologijos’ 2003 pranešimų medžiaga. 2003, p. 1-8. [14] Nilson N. Logic and Artificial intelligence. Journal of Artificial Intelligence. 1991, p. 31-35. [15] Полевой Н.С. Криминалистическая кибернетика. – М., 1989.

Ontology Design in The Criminalistic Information System

The research considers the main structural requirements for criminalistic information system and ontology design. The criminalistic information system, based on ontology, ensures the proper application of criminalistic information structural model, determines the main rules, how to receive the important criminalistic information from primary facts about crime. Ontology helps to create the framework and in this way to ensure the collecting, accumulation, storage, treatment and transmission in proper form of important investigation information, which create conditions to make optimal solutions in investigation of crimes.

– 6 –

http://www.vtex.lt/Informatica/htm/INFO195.htm

INFORMACIJOS SRAUTAI IR ORGANIZACIJOS STRUKTŪRA

Vaidotas Petrauskas Kauno technologijos universitetas

Optimali organizacijos struktūra leidžia efektyviai išnaudoti turimus resursus, siekiant kuo didesnio pelno. Intensyviai besivystančios prekių bei paslaugų teikimo technologijos atpalaiduoja darbo jėgą, tuo tarpu informaciniai srautai tarp darbo vietų intensyvėja. Tai negali neatsiliepti organizacijos struktūrai: mažėja gamybiniai plotai, gamybos darbo jėga, didėja kabinetinių darbo vietų skaičius bei informacinių technologijų plėtros tempai. Straipsnyje nagrinėjama informacijos srautų įtaka organicacijos struktūrai, įvertinant šių srautų apdorojimo priemonių (informacinių technologijų) galimybes.

1. Įvadas

Organizacijų struktūros analizei visais laikais skiriamas dėmesys. To priežastis yra optimalus žmonių, įrangos, informacijos ir kitų resursų paskirstymas projektuojant organizacijos veiklą.

Kalbant apie verslo įmones, optimali organizacijos struktūra leidžia efektyviai išnaudoti turimus resursus, siekiant kuo didesnio pelno. Tai ir darbo vietų skaičiaus mažinimas, ir įrangos paskirstymas darbo vietose, ir turtinių resursų paskirstymas veiklos procesams ir kiti panašūs dalykai, leidžiantys verslininkams didinti apyvartą, kelti darbo kokybę, našumą.

Verslo įmonės veiklą galima skirstyti į betarpiškus prekių gaminimo (paslaugų teikimo) veiksmus ir į informacinius ryšius tarp darbuotojų kolektyvo šiems veiksmams koordinuoti. Dabartiniu metu intensyviai besivystančios prekių bei paslaugų teikimo technologijos atpalaiduoja darbo jėgą, tuo tarpu informaciniai srautai tarp darbo vietų intensyvėja. Tai negali neatsiliepti organizacijos struktūrai: mažėja gamybiniai plotai, gamybos darbo jėga, didėja kabinetinių darbo vietų skaičius bei informacinių technologijų plėtros tempai.

Pradinė organizacijos veiklos stadija taip pat įgyja atitinkamą pobūdį: sudaromas verslo planas, strateginis planas keletui metų į priekį, modeliuojama organizacijos veikla, ir tik po to priimamas sprendimas verslui plėtoti. Pirminiuose verslo planuose jau ryškus būsimosios organizacijos (būsimojo verslo) kontūrai, įskaitant ir būsimuosius informacijos srautus.

Kyla klausimas, ar informacijos srautai turi įtakos būsimos organizacijos struktūrai? Straipsnio tikslas yra išnagrinėti informacijos srautų įtaką organizacijos struktūrai įvertinant šių srautų

apdorojimo priemonių (informacinių technologijų) galimybes.

2. Organizacijos struktūrų modeliai

Dauguma organizacijos struktūros projektavimo koncepcijų, metodikų yra aprašomojo pobūdžio. Tai rinkinys heuristikų, kurios netinkamos visomis aplinkybėmis. Nėra organizacijos projektavimo teorijos, kuri paaiškintų, kodėl skirtingos technikos tinka vienoms ir netinka kitoms organizacijoms. Organizacijų struktūrų įvairovę paryškina ir tai, kad sėkmingai rinkoje dirbančios organizacijos smarkiai skiriasi savo struktūra. Dauguma organizacijos struktūros projektavimo koncepcijų remiasi sėkmingai rinkoje dirbančių organizacijų struktūrine analize ir pagal jas formuojamomis išvadomis. Natūralu, kad tokios koncepcijos tinka tik tam tikram organizacijų tipui ir visiškai netinka kitoms organizacijoms.

Dauguma organizacijos struktūros projektavimo koncepcijų nagrinėja išskirtinai gamybinio pobūdžio darbo vietų struktūrą, nieko arba labai mažai pasakydamos apie informaciniu darbu užsiimančių darbuotojų paskirstymą organizacijoje.

Be to, dalis optimalios organizacijos struktūros formavimo koncepcijų nagrinėja klausimus, susijusius su vadovaujantį darbą dirbančių žmonių (priimančių sprendimus ir neatliekančių gamybinių užduočių) darbo vietų paskirstymu tarp organizacijos padalinių ir maksimalaus vadovaujančių asmenų laipsnio (lygio) organizacijoje paieškomis.

Šios koncepcijos yra gana gerai ištobulintos gamybinio pobūdžio darbo vietų skirstymui organizacijoje – jas taikant, galima ne tik kad parinkti tinkamą organizacijos tipą, bet ir beveik optimaliai paskirstyti gamybinio pobūdžio darbus tarp organizacijos padalinių bei konkrečių darbo vietų.

– 7 –

V. Petrauskas

Nagrinėjant organizacijų struktūrų raidą, galima išskirti keletą charakteringų etapų. Iki 20 a. pradžios organizacijos struktūroje dominavo autoritarinis valdymas ir žemos kvalifikacijos darbo jėgos specializavimas pagal atliekamas operacijas. Ryškus šio laikmečio organizacijos tipas – F.W.Teiloro modelis, kuris ryškiai atskyrė organizacijos „smegenų trestą“ nuo vykdančiosios darbo jėgos. Tokia struktūra buvo pateisinama neišsivysčiusių gamybos technologijų sąlygomis. Žvelgiant iš šiandieninės perspektyvos, informacijos srautai F.W.Teiloro modelyje koncentravosi „smegenų treste“ bei tarp „smegenų tresto“ ir vykdančiosios darbo jėgos. Informaciniai ryšiai tarp gamybines operacijas atliekančių darbininkų ir jiems vadovaujančių „smegenų tresto“ darbuotojų turėjo būti ypač tobuli dėl to, kad Tailoro organizacijos modelis buvo pagrįstas kiekvienos darbininko darbo vietos studija, kurios tikslas kaip galint daugiau „išsunkti“ iš joje dirbančio darbininko. Gi ryšiai tarp „smegenų testo“ darbuotojų turėjo priminti analogiškus ryšius šiandieniniame organizacijos vadovų kolektyve.

20 a. pradžios ekonomisto Fajolos departamentinis organizacijos struktūros modelis įvedė papildomus informacijos srautus jau tarp organizacijos departamentų informacinių darbuotojų. Tokie srautai būdingi bendrai organizacijos veiklai (ryšiai tarp personalo, finansų, gamybos ir kitų departamentų yra būtini integruotai informacijai gauti ir pateikti ją vadovybei). Šioje struktūroje išlieka tie patys santykiai tarp gamybines operacijas atliekančių ir informaciją apdorojančių organizacijos dalių. Tačiau šioje paskirstytoje sistemoje ypač aktualus darosi informacijos apdorojimas atskiruose departamentuose bei informacinės sąsajos tarp jų. Šitokia struktūra yra tarsi katalizatorius informacinių technologijų diegimo intensyvinimui. 20 a. pabaigoje praktiškai išliko tas pats Fajolos modelis, o kompiuterių technika leido sukurti departamentus integruojančią informacinę aplinką organizacijos duomenų bazėse.

Be Fajolos departamentinės struktūros egzistuoja ir kiti organizcijų struktūrų modeliai, pavyzdžiui, matricinė struktūra, kurioje informaciniai srautai dar labiau išsišakoja tarp matricos struktūrinių elementų, tuo būdu poreikis šiuos srautus apdorojančios technikos dar didesnis.

Tolimesnė organizacijų struktūrų plėtra neabejotinai sąlygojama šiandieninių informacinių technologijų. Galima pastebėti, kad:

1. Vystantis technologijoms, vis didesnis svoris tenka informaciją apdorojančiai organizacijos daliai. Įvertinant tai, kad informacijos apdorojimas yra intelektualus darbas, o intelektualaus darbo apdorojimo kolektyvuose pavaldumo koeficientas yra kur kas mažesnis (3-5) negu fizinio darbo, reiškia, organizacijos struktūroje įvedami žymiai mažiau žmonių turintys struktūriniai organizacijos vienetai, kurie turi apdoroti didelius informacijos kiekius, o tuo pačiu ir palaikyti informacinius ryšius tarp vidinių struktūrinių padalinių ir išorinių informacinių vienetų. Šios tendencijos pagimdė tokius reiškinius kaip TQM ir BPR.

2. Santykis tarp informacinių srautų ir organizacijos struktūros darosi akivaizdus, jo ne tik kad negalima ignoruot, bet būtina spręsti atvirkštinę problemą – kokią įtaką turi informacijos srautai organizacijų struktūrai ir ar negalima informacijos srautų charakteristikų susieti su organizacijos struktūros parametrais.

Analizuojant organizacijų struktūrų raidą, galima pastebėti, kad tobulinant organizacijos struktūrinius modelius, siekiama sukurti tokią struktūrą, kur organizacijos uždaviniai būtų vykdomi efektyviai, esant minimaliam darbo vietų skaičiui. Tačiau vystantis gamybos ir informacijos technologijoms ir dėl to mažėjant gyvosios darbo jėgos kiekiui tendencija mažinti darbo vietų skaičių toms pačioms funkcijoms atlikti ypač ryški. Labiausiai paplitę organizacijų struktūrų tipai yra šie:

• (grynai) funkcinė: darbuotojai grupuojami padaliniais pagal jų techninius ar specialybinius sugebėjimus, • divizinė – orientuota į projektus, geografiją: darbuotojai grupuojami padaliniais pagal atliekamus projektus

– labai populiari struktūra didelėse organizacijose, gaminančiose daug gaminių tipų (teikiančiuose daug rūšių paslaugų); ši struktūra taip pat naudojama organizacijos padalinius formuojant pagal geografinius regionus (tada ji vadinama geografiškai orientuota struktūra),

• matricinė struktūra: darbuotojai grupuojami padaliniais pagal jų profesinius sugebėjimus ir pagal atliekamą projektą – vienas darbuotojas turi du vadovus – profesinės srities ir atliekamo projekto,

• ar jų derinys. [3, 6] Organizacijos yra skirstomos ir į kitokius tipus (, priklausomai nuo to, kurį organizacijos struktūrą formuojantį

veiksnį išskiria autorius). Pavyzdžiui, Minzbergas (1983) organizacijas skirsto į tipus pagal darbų koordinavimo pobūdį . Skiriami 5 tipai:

• paprasta struktūra (simple structure): iš esmės struktūros nėra – basically no structure, tiesioginis valdymas,

• mašininė biurokratija (machine burocracy): dominuoja techniniai/specialistų prioritetai – dominated by technical/specialist priorities, standartizuojami darbo procesai,

• profesionali biurokratija (professional burocracy): dominuoja centro personalas įgūdžiai – dominated by skills of core staff, standartizuojami įgūdžiai,

– 8 –

Informacijos srautai ir organizacijos struktūra

• divizinė forma (divisionalised form): dominuoja produktai – dominated by products/outputs, standartizuojami pagaminami produktai (outputs),

• adokracija (adhocracy): dominavimas padalinamas tarp centro personalo ir palaikymo tarnybų – shared dominance of core staff and support services, valdymas yra bendras, prisitaikantis. [3]

Be to, organizacijos yra skirstomos ir pagal vertikalių santykių organizacijoje laipsnį – plokščioje (flat) struktūroje yra mažiau, aukštoje (tall) – daugiau vadovų. [3]

Organizacijos struktūros tipui įtaką turinčiais faktoriais paprastai laikomi šie: (išorinės) aplinkos stabilumas, organizacijos tikslai, užduotys (tasks), nacionalinė kultūra, skirtumai tarp

padalinių, organizacijos dydis, vadovavimo stilius, darbuotojų asmeninės savybės (charakteristikos). [3, 6] Optimalią organizacijos struktūrą nagrinėjančių koncepcijų didžiausias trūkumas yra tas, kad jos yra tik

aprašomojo pobūdžio ir neformalizuotos. Jų formalizavimas yra pakankamas nustatant gamybinio pobūdžio darbo vietų struktūrą (nors, be abejo, reikalauja detalaus tyrimo kiekvienu konkrečiu atveju), tačiau beveik nieko nesako apie negamybinio tipo (tame tarpe ir administracinio, ir su informacijos surinkimu, apdorojimu, koordinavimu tarp padalinių bei tarp organizacijos ir išorės) darbų paskirstymą, ypač įvertinant šiuolaikinių informacinių technologijų teikiamas informacijos apdorojimo galimybes.

Norint surasti informacinį darbą atliekančios organizacijos dalies optimalią struktūrą, būtina informacinių srautų organizacijoje analizė.

Be to, atliekant organizacijos reorganizavimo darbus (TQM, BPR) ar kuriant naują įmonę, darbo srautai (workflow) yra analizuojami neatsiejamai nuo informacijos srautų. [1]

3. Informacijos ir informacijos srautų aprašymo modeliai

Informacijos srautu paprastai yra vadinamas informacijos judėjimas ir jos pasikeitimas. Bet kuriam gamybos procesui, ar kokiam nors fiziniam objekto pasikeitimui turi būti atitinkamas apibrėžtas informacinis srautas. Kai kurių autorių dokumentų srauto interpretavimas informacijos srautu yra klaidingas, kadangi net ir tarp išskirtinai gamybinio pobūdžio (nekuriančių dokumentų) darbo vietų egzistuoja informacijos mainai (pvz., pagamintų medžiagų skaičius perduodamas iš vienos darbo vietos į kitą), kuriems perduoti, apdoroti reikia žmogaus arba kompiuterio įsikišimo (tuo pačiu ir darbo laiko gaišimo).

Detali organizacijos informacijos srautų analizė įmonės vadovams suteikia pilną informaciją apie organizacijos procesus – ir gamybinius, ir su jais susijusius ir juos administruojančius informacinius procesus. Remiantis šios analizės metu gautomis išvadomis, galima ieškoti optimalios organizacijos procesų struktūros. [2]

Kuriant organizacijos informacijos valdymo sistemas (portalus), kartais didelėse organizacijose informacijos srautų optimizavimas nėra atliekamas ir visi organizacijoje vykstantys informaciniai procesai yra įtraukiami į sistemą tokie kokie jie yra. Be abejo, tinkamai realizuotoje informacijos valdymo sistemoje informacijos procesai bus atliekami gerokai sparčiau nei anksčiau, tačiau neoptimaliai – bus vykdomi ir besidubliuojantys, ir su organizacijos veikla mažai ką bendro turintys parazitiniai (jei tokių yra) ir panašūs.

Organizacijos procesų ir informacijos srautų analizė leidžia išskirti vertės tiesiogiai nekuriančiai veiklai skiriamus arba surasti neefektyviai naudojamus išteklius ir, tinkamai pritaikius tose vietose informacines technologijas, paspartinti organizacijos procesus taip, kad organizacija efektyviau atitiktų jai keliamus tikslus, su minimaliu darbo vietų skaičiumi gautų maksimalų pelną. [7]

Dažniausiai organizacijoje vykstantys procesai (tame tarpe ir informaciniai) yra atvaizduojami diagramomis. Priklausomai nuo analizei keliamų reikalavimų (ar siekiama detalios, ar bendro pobūdžio informacijos apie organizacijoje vykstančius procesus), procesai gali būti analizuojami neskaidant jų į sudėtinius elementus arba susmulkinant juos iki paprasto veiksmo (action) lygio. Smulki diagrama leidžia matyti visus procesus, vykstančius organizacijoje – tiek gamybinės veiklos, tiek informacinius – ir, juos išanalizavus, reorganizuoti juos.

Dažniausiai pasitaikantys diagramų tipai yra duomenų srautų, ER, IDEF, UML diagramos ir kiti. Duomenų srautų diagramomis sistemą galima atvaizduoti norimame detalizavimo lygyje grafiniu tinklu

simbolių, vaizduojančių duomenų srautus, duomenų procesus ir duomenų šaltinius/tikslus. [5] Aprašius procesus duomenų bazėse naudojama simbolika, spartesnis tampa šių procesų reorganizavimas

organizacijos informacinėje sistemoje. Diagramos yra labai vaizdus būdas pavaizduoti organizacijoje vykstančius procesus, jos nesunkiai suprantamos

ir specialistui, ir vadovui. Tačiau informacijos srautų diagramos yra modelis, kurio negalima analizuoti automatizuotais analizės metodais.

Nors yra metodai ir priemonės, leidžiančios atlikti vieno ar kito proceso, aprašyto diagramomis, analizę, modifikavimą ir optimizavimą, tačiau tai nėra automatizuotas procesas. Visas informacijos modelis dažniausiai yra pernelyg sudėtingas optimizuoti vienam žmogui be specialių analizės priemonių. Neužtenka turimo modelio

– 9 –

V. Petrauskas

analizuoti ekspertui išskiriant kurią nors modelio dalį ir ją analizuojant atskirai nuo kitų procesų bei optimizuojant ją pagal kokius nors parametrus. Reikia visos organizacijos informacijos srautų kokybinės analizės. Tam, kad sumodeliuotoji sistema būtų analizuojama/transformuojama optimizavimo tikslais specialių programų pagalba, yra reikalingi formalūs modelio analizės/optimizavimo metodai.

Diagramomis galima parodyti, kokia yra informacijos srauto informacija arba kas ją kuria/modifikuoja/vartoja, bet norint žinoti daugiau apie taip kaip informacija juda organizacijoje, reikia ją aprašyti formaliais metodais, įvedant papildomus su informacijos kūrimu, apdorojimu ir naudojimu susijusius parametrus. Be to, optimizavimo eigoje dažnai yra labai naudinga simuliuoti informacijos judėjimą organizacijoje – šio etapo eigoje bus matoma, kaip informacijos paketai juda organizacijoje. Vienas tokių modeliavimo būdų, kurį galima simuliuoti, yra modeliavimas Petri tinklais.

Pačią pilniausią informaciją apie informacijos srautus organizacijoje galima gauti, juos aprašius formaliais metodais. Galima modeliuoti tik organizacijoje cirkuliuojančius informacinius srautus, o galima sukurti ir visos organizacijos modelį.

Organizacijos modelis – verslo, vyriausybės ar organizacijos struktūros, veiklų, procesų, informacijos, žmonių, poelgių ir apribojimų skaitmeninis atvaizdavimas. Organizacijos modelio tikslas yra pasiekti modeliu pagrįstą organizacijos projektavimą, analizę ir įvertinimą [4].

Sumodeliavus organizacijos informacijos srautus, sudarytąjį modelį galima analizuoti, ieškant įvairių modelio charakteristikų. Kai modelyje nėra aprašyta pati informacija, o tik informacijos srautų judėjimas (toks metodas yra ir Petri tinklai), tuomet, siekiant pilno informacijos srautų paveikslo, reikia kombinuoti šį metodą su diagraminiu, parodančiu pasikeitimus pačioje informacijoje.

4. Išvados

Iki šiol, projektuojant organizacijos struktūrą, nėra atsižvelgiama į informacijos srautus. Informacijos srautams organizacijoje yra naudojami organizacijos ištekliai ir darbuotojų laikas. Jų apdorojimo našumas priklauso nuo naudojamų technologijų. Todėl informacijos srautų analizė turi būti neatskiriama organizacijos struktūros projektavimo dalis.

Literatūros sąrašas [1] Aalst, W.M.P., The Application of Petri Nets to Workflow Management. 1998. Prieiga per internetą <http://tmitwww.tm.tue.nl/staff/wvdaalst/Publications/p53.pdf> [2] Casson, M., Information and organization: a new perspective on the theory of the firm. Clarendon pres., 1997, p. 314 [3] Cole, G.A., Management: Theory and Practice. Letts Educational, 1999, pp 170-185 [4] Gruninger, M., Atefi, K., and Fox, M.S., Ontologies to Support Process Integration in Enterprise Engineering. Computational & Mathematical Theory, Vol. 6, pp 381-394, 2000. Prieiga per internetą <http://www.eil.utoronto.ca/enterprise-modelling/papers/index.html> [5] Kozar, K.A., The Technique of Data Flow Diagramming., 1997, Prieiga per internetą <http://spot.colorado.edu/~kozar/DFDtechnique.html> [6] Rue, L.W., Byars, L.L., Management: Theory and application. Irwin, 1986, p. 649 [7 ] Wysocki, R.K., DeMichiell, R.L., Managing Information across the enterprise. John Wiley & Sons, 1997, p. 372

Information Flow and Enterprise Structure

Optimal enterprise structure allows effectively use enterprise resources for achieving bigger profit. New technologies release workforce, while information flows between workplaces grows. These changes respond to the enterprise structure: declines workspaces, workforce, grows office and bureaucratic workplaces, grows the rates of development information systems. In this article the influence of information flows in the enterprise structure is analyzed.

– 10 –

RIZIKOS VALDYMAS BANKUOSE INTELEKTUALIŲ SPRENDIMŲ PARAMOS SISTEMŲ PAGRINDU

Gintautas Garšva, Egidijus Merkevičius Vilniaus universiteto Kauno humanitarinis fakultetas, Informatikos katedra

Muitinės g.8, Kaunas

Straipsnyje nagrinėjamas intelektualių sprendimų paramos sistemų panaudojimas bankuose Bazelio naujos kapitalo sutarties kontekste. Išnagrinėjami šios sutarties reikalavimai bankų informacinėms sistemoms, atliekamas sukurtų rizikos valdymo sistemų tyrimas, suprojektuojamas konceptualaus intelektualios sprendimų paramos sistemos lygmens modelis, jo pagrindu atliekama konkretaus banko informacinės sistemos pirminė analizė, numatomi tolimesni intelektualios sprendimų paramos sistemos vystymo etapai.

1. Įžanga

Sprendimų paramos sistemos pastaraisiais metais tampa vis svarbesne ir efektyvesne įvairių sričių (medicinos, statybos, finansinių paslaugų, elektronikos ir kt.) problemų sprendimo priemone. Tai iš dalies lemia įvairių dirbtinio intelekto (toliau – DI) metodų – ekspertinių sistemų (toliau – ES), dirbtinių neuroninių tinklų, evoliucinių algoritmų ir kt. – panaudojimas sprendžiant įvairias problemas. Viena iš aktualesnių intelektualių sprendimų paramos sistemų (toliau – ISPS) sričių yra kreditavimo procese atsirandančių rizikų valdymas. Pasaulyje vystomi bei tobulinami rizikos valdymo modeliai, priimami nauji standartai. Vienas iš tokių pavyzdžių – Bazelio bankų priežiūros komiteto (toliau – Bazelio komiteto) vystoma kapitalo pakankamumo užtikrinimo principus nustatanti sutartis. Naujoji jos versija suteikia bankams žymiai platesnes galimybes valdant kredito, operacinę bei rinkos rizikas. Analitikų manymu (0,0 ir kt.), ji suteikia ne tik didesnes galimybes, bet ir didesnius reikalavimus bankų informacinėms sistemoms (toliau – IS) diegiant sudėtingus rizikos valdymo modelius. Tokiu atveju galėtų pasitarnauti ISPS, identifikuodamos banko IS spragas ir siūlydamos jų šalinimo sprendimus pertvarkymo projektuose.

Šio straipsnio tikslas – pasiūlyti tokios ISPS konceptualaus lygmens modelį. Tuo tikslu straipsnyje atskleidžia-ma rizikos valdymo sistemų diegimo į bankų IS problematika, ištiriami Bazelio komiteto reikalavimai bankų IS, išanalizuojamos charakteringos sukurtos rizikos valdymo sistemos, suprojektuojamas konceptualus banko IS modelis, jo pagrindu atliekama konkretaus banko IS pirminė analizė, nusakoma tolimesnė kuriamos ISPS pers-pektyva. Visa tai atliekama Bazelio komiteto reikalavimų bankų IS kontekste.

2. Problematika

Sprendimų paramos sistemų (toliau - SPS) kūrimas ir vystymas prasidėjo daugiau nei prieš 35 metus, plačiau taikyti pradėtos nuo 1980 metų, kada atsirado finansinio planavimo bei grupinių sprendimų paramos sistemos. Pagrindinis tokių sistemų tikslas – suteikti informaciją vartotojui apie galimus problemos sprendimo būdus ir pasiūlyti optimalius problemų sprendinius. Vartotojo požiūriu SPS skirstomos į pasyvias, aktyvias ir kooperatyvias 0, konceptualiu požiūriu – į komunikacines, duomenų, dokumentų, žinių ir modelių SPS 00, techniniu požiūriu – į kompanijos ir darbo vietos SPS 0. Intelektualios sprendimų paramos sistemos kuriamos panaudojant pažangius dirbtinio intelekto metodus – ekspertines, fuzzy sistemas, dirbtinius neuroninius tinklus, evoliucinius, spiečiaus teorijos algoritmus. Šie metodai taikytini bankų informacinių sistemų pertvarkymo problemų sprendimuose, susijusiuose su naujais Bazelio komiteto priimamais tarptautiniais susitarimais. Jų reglamentuojami rizikos valdymo principai leidžia bankams tobulinti kreditavimo veiklą, optimizuojant su ja susijusią riziką.

Bazelio bankų priežiūros komitetas (ang. Basel Committee on Banking Supervision) – bankų veiklos, priežiūros standartus, metodologijas, rekomendacijas, instrukcijas formuluojantis trylikos valstybių (tarp jų - JAV, Didžioji Britanija, Vokietija, Japonija) centrinių bankų komitetas. Jo 1999-2001 m. publikuota Bazelio nauja kapitalo sutartis (toliau Bazelis II), formuluojanti kapitalo pakankamumo apskaičiavimo principus, leidžia bankams kredito, operacinę bei rinkos rizikų valdyme taikyti iki šiol oficialiai nenaudotus rizikos valdymo metodus. Šių rizikų valdymas tiesiogiai siejamas su kapitalo pakankamumo užtikrinimu vykdant kreditavimo veiklą. Lyginant su 1988 m. publikuota Bazelio kapitalo sutartimi (toliau – Bazelis I), kurios principai šiuo metu įgyvendinti beveik visose rinkos ekonomikos valstybių bankininkystės sektoriuje, pagal Bazelį II bankai įgauna galimybes taikyti tikslesnius ir sudėtingesnius rizikos valdymo modelius. Bazelio kapitalo sutarčių palyginimas pateikiamas 1 lentelėje:

– 11 –

G. Garšva, E. Merkevičius

1 lentelė. Bazelio kapitalo sutarčių palyginimas

Bazelis I Bazelis II

Kapitalo pakankamumo skaičiavimas

Kredito ir rinkos rizikos koeficientai Kredito, rinkos ir operacinės rizikos koeficientai

Kredito rizika (ang. Credit risk)

Tik standartizuotas metodas (ang. Standardised approach).

Pateikiami trys metodai: 1. Standartizuotas metodas (patikslinti svoriai, adekvatūs suteiktiems išoriniams reitingams arba vidinėms skaičiavimo taisyklėms). 2. Bazinis vidinių reitingų metodas (Foundation Internal Rating Basis). 3. Patobulintas vidinių reitingų metodas (Advanced Internal Rating Basis).

Operacinė rizika (ang. Operational risk)

Kapitalo pakankamumo skaičiavime ji neįvertinama.

Įvertinamas operacinės rizikos koeficientas; skaičiuojamas priklausomai nuo pasirinkto kredito rizikos metodo: 1. Bazinių rodiklių metodas (ang. Basic indicator approach). 2. Standartizuotas metodas (ang. Standardised approach). 3. Patobulintų skaičiavimų metodas (ang. Advanced measurement approach).

Vidinis reitingas čia suprantamas kaip banko vidinis indikatorius, prognozė arba nuomonė apie kliento-skolinin-ko gebėjimą vykdyti savo įsipareigojimus, įvertinant galimus nuostolius bei atsižvelgiant į atitinkamus rizikos faktorius. Vidinių reitingų sistema (toliau – VRS) apima procesus, procedūras ir IT sistemas, aprūpinančias vidinio reitingo nustatymą. 0.

Svarbi sąlyga vidinių reitingų sistemos diegimui banke yra Bazelyje II reglamentuojamų reikalavimų įgyven-dinimas. Reikalavimų įvykdymas betarpiškai susijęs su banko IS pertvarkymu, tobulinimu. Kadangi visi bankai turi vienokią ar kitokią IS, atsiranda poreikis ISPS, padedančiai pertvarkyti IS pagal Bazelio II reikalavimus. Tokios ISPS tikslas - diagnozuoti esamą banko IS, identifikuoti neatitikimus ir projektuoti tolimesnius veiksmus diegime.

3. ISPS kūrimas konceptualiame lygmenyje

Finansinio konsultavimo bei paslaugų kompanija Pricewaterhouse Coopers sukūrė panašios paskirties produktą The Pricewaterhouse Coopers Bazel II Diagnostic 0. Jis skirtas bendros banko kreditavimo sistemos įvertinimui Bazelio II aspektu. Ši ISPS jungia esminius SPS komponentus (duomenų bazė, modelių bazė, vartotojo dialogas 0), ir integruotą ES (papildomi komponentai – procesas, duomenys, modelis, ekspertų taisyklės 0). Rezultate pateikiama banko situacija šešiais aspektais: strategijos ir politikos, valdymo ir organizacijos, procesų, matavimų, duomenų, atskaitomybės. Ji nagrinėja banko bendrus strateginius sprendimus ir skirta esminėms spragoms nustatyti.

Šiame straipsnyje nagrinėjamos ISPS objektas – banko IS ir joje vykstantys procesai vidinių reitingų sistemos – kaip kredito rizikos valdymo metodo – aspektu.

ISPS kuriamos ir vystomos remiantis sistemos vystymo gyvavimo ciklu: ISPS modeliavimui naudojamos CASE priemonės. Šiame straipsnyje nagrinėjama ISPS konceptualaus

lygmens modelis gyvavimo ciklo poreikių, planavimo, analizės ir projektavimo fazėse. Tam, kad būtų galima diagnozuoti banko IS, reikia sumodeliuoti tokį VRS modelį, kuris atitiktų Bazelio II reikalavimus VRS.

3.1. Poreikių nustatymas

Poreikių fazėje nustatomi Bazelio II reikalavimai VRS (žr. 2 lentelę). Bazelyje II Vidinių reitingų sistema yra suprantama ne tik kaip metodas, leidžiantis tiksliai įvertinti kliento-skolininko bei jo paskolos būklę, bet kaip paskolų portfelio rizikos valdymo priemonė, leidžianti panaudoti vidinį reitingą paskolų portfelio formavimui.

– 12 –

Rizikos valdymas bankuose intelektualių sprendimų paramos sistemų pagrindu

Projektavimas

Sistema

Planavimas

Poreikiai

Analizė

Realizavimas

1 pav. Tradicinis sistemos vystymo gyvavimo ciklas (krioklys) 0

2 lentelė. Bazelio II reikalavimai banko IS diegiant VRS

Aspektai Apibūdinimas Duomenų saugykla (Data warehousing) Tinkama infrastruktūra duomenų laikymui, valdymui ir analizavimui. Duomenų saugyklos sritys • Klientai-skolininkai (sektoriaus tipas, skolininko tipas, vidinių ir išorinių

reitingų istorija, finansiniai duomenys, rizikos įvykiai ir t. t.); • Paskolos (pozicijos) (paskolos tipas, terminai, valiutinė išraiška, palūkanų

norma ir įmokos, nukrypimai ir t. t.) • Finansiniai užstatai (užstato tipas, nominali vertė, rinkos vertė, valiutinė

išraiška, grynoji vertė, perkainojimo dažnumas, terminai, pagrindiniai duomenys apie poziciją ir t. t.)

• Fiziniai užstatai (nuorodos apie nuosavybę, nuosavybės vertė, perkainojimo dažnumas ir t. t.)

• Garantijų ir išvestinių kreditų detalės (garantijų / kredito tiekėjų duomenys, valiuta, terminai ir pan.)

• Rizikos vertinimo apskaičiavimai pagal pozicijas, portfelį, sektorių, geografinį pasiskirstymą ir pan.

Sistemų integruotumas IS integruotumas, patikimumas ir lankstumas klaidų atveju. Priėjimas prižiūrėtojams (Supervisory access) Sistemoje numatomas priėjimas bankų prižiūrėtojams. Verslo (korporatyvinės) pozicijos Įvertinamos pagal verslo ir finansinius aspektus, tarp kurių nustatoma:

• Istorinės ir projektuojamos pinigų srautų generavimo galimybės; • Kapitalo struktūra; • Pajamų kokybė; • Operacinių svertų lygis ir jų įtaka pelningumui bei pinigų srautams; • Finansinis lankstumas ir iš jo sekantis priėjimas prie kapitalo rinkų

papildomiems resursams gauti; • Valdymo patirtis ir sugebėjimai; • Kompanijos padėtis sektoriuje;

Vartotojiškos pozicijos Sukuriama kredito skoringo (scoring) sistema Reitingų duomenys Saugojamos visos suteiktų reitingų reikšmės. Tikslas – retrospektyvus

testavimas, pozicijos prognozės, vertinimo korektiškumas ir kt. Segmentacija Bankai renka ir saugoja segmento bei skolininko duomenis ir charakteristikas,

panaudotas segmentacijai, nukrypimų būsenos skaičiavimui ir išmatuotos rizikos charakteristikas, jas susiejant su konkrečiu segmentu.

Rizikos komponentai (PD, EAD, LGD), rizikos svorio funkcija ir susiejimas su kapitalo pakankamumo apribojimu.

Sekamos atsiradusių nuostolių dėl nemokumo detalės ir atgavimo dydžiai. Ši informacija stebima kiekvienai pozicijai, pvz., tiesioginiai praradimai, atstatymui reikalingas laikotarpis, administravimo kaštai ir pan.

– 13 –


Planavimo fazėje pasirenkama Zachmano IS architektūros 0 konceptuali perspektyva duomenų, funkcijos, tinklo, žmonių, laiko ir motyvacijos dimensijose.

3.2. Sukurtų rizikos valdymo sistemų tyrimas

Analizės fazėje būtina identifikuoti banko IS komponentus ir ryšius tarp jų. Komponentu čia laikoma tam tikros visumos – banko IS – dalis. Tuo tikslu išnagrinėjamos esamos sukurtos rizikos valdymo sistemos, kurios teigia atitinkančios Bazelį II reikalavimus.

Analitinės kompanijos „Meridien Research“ duomenimis 0, išskiriamos šios dominuojančios rizikos valdymo sistemas kuriančios kompanijos ir jų produktai:

1. IBM Financial Services (IBM’s Banking Data Warehouse); 2. SAS Risk Management (SAS Risk Dimensions); 3. SAP AG (my SAP Banking / SAP IS Risk Analyzer); 4. Algorithmics Inc (AlgoSuite 4.2). Šios sistemos išanalizuojamos pagal Bazelio II reikalavimus VRS bankų IS. Analizės rezultatai pateikiami 3

lentelėje 0.

2 lentelė. Lyginamoji rizikos valdymo sistemų analizė Bazelio II aspektu

Aspektas SAS Risk Dimensions

MySAP AlgoSuite 4.2

IBM BDW

Lietuviškai Angliškai Pirminiai

Duomenų šaltiniai Data sources - - + - Duomenų saugykla (DS) Data warehousing + + + + Duomenų agregavimas Extraction, Conversion,

Cleansing, Transfer - - + +

Rinkos rizika/ Vertės rizikos modeliavimas

Market risk/VaR + - + +

Operacinė rizika Operational risk + + + + Scenarijų analizė Scenario Analysis + + + + Kredito rizika Credit risk + + + + Kredito rizikos komponentų skaičiavimo variklis? (LGD, PD, EAD)

Credit risk parameters engine

+ + + +

Ar numatytas priėjimas prižiūrėtojui Supervisory access - + + + Vartotojiško kredito skoringas Scoring models + - - - Reitingo skaičiavimo variklis/įrankis Rating calculation engine + + + + Ar skiriama pozicijos ir portfelio analizė

Credit Portfolio Mgmt + + + ?

Užstatų valdymas Collateral management - + + + Ataskaitos Reporting + + + +

Papildomi Duomenų modeliavimas/map Modeling/map + + + + Rizikos indikatoriai, monitoringas Risk indicators /

Monitoring + + + +

Multi-dimensinės duomenų bazės MDDB / OLAP + + ? + Integracija web puslapiuose /XML XML/Web services + - - + Sąsaja su tarptautiniais apskaitos standartais

Basel II and IAS - + - +

Limitų valdymas Limit management - + + - Ar sistema modulinė? + - + - Ar yra grįžtamasis ryšys, sistemų kontrolė?

+ - - -

– 14 –


Čia: „+“ - yra; „-“ – neužfiksuota; „?“ – nepakankamai duomenų.

Analizuojant gautus rezultatus, galima teigti, jog: • svarbiausi VRS reikalavimai IS įgyvendinti visuose siūlomuose sprendimuose – rizikos komponentai,

rizikos svorio funkcija, reitingo skaičiuoklė, duomenų saugykla, užstatų valdymas; • kompanijų produktai siūlo papildomus sprendimų komponentus – duomenų modeliavimas/žemėlapiavimas,

multidimensinių duomenų bazių panaudojimas, atskaitomybės bei ataskaitų atitikimas tarptautiniams apskaitos standartams, limitų valdymas ir kiti.

3.3. Banko IS rizikos valdymo modelio projektavimas

Nustačius banko IS komponentus, aukščiau minėtos Zachmano IS architektūros pagrindu projektuojamas banko IS rizikos valdymo modelis VRS aspektu. Suprojektuojami šie modeliai:

• verslo sąveikų diagrama (ang. Bussiness interaction modeler) - bendros banko veiklos formalizavimui IT modelio pagal Bazelį II aspektu;

• tikslų modelis (ang. Goal modeler) - atvaizduoja verslo veiklos tikslus. Šio modelio tikslas – nustatyti kredito rizikos koeficiento – kaip esminio VRS rodiklio – apskaičiavimo tikslų medį;

• komunikacijos modelis (ang. Communication modeler) - analizės sistemų ir duomenų saugyklų (DS) komunikacija, detalizuojant duomenis, kurie patenka į DS;

• veikimo diagrama (ang. Activity diagram) - modelio paskirtis yra atvaizduoti verslo procesus, išreiškiant juos veiklos komponentais ir darbų seka tarp tų veiklų.

Veikimo diagrama aprašo kreditavimo procesą nuo paraiškos gavimo išduoti paskolą iki atskaitomybės bankų priežiūros institucijoms. Joje panaudojami visi duomenys, gauti tyrimų metu – komponentai, ryšiai tarp jų, sąveikos ir pan., todėl ją laikome esmine, pateikdami 2 pav.:

2 pav. Veikimo diagrama

– 15 –


Modelio pagrindiniai elementai:

darbų sekos juosta (ang. workflow lane) – tai juosta, kuri išskiriama linijomis ir žymi organizacijos esybės ar rinkos darbų atlikimo sritį. Joje išdėstoma tos esybės ar rinkos atliekamų darbų seka.

Duomenų saugykla

saugykla (ang. Store, vaizduojamas stačiakampis) - tai elementas naudojamas pažymėti atsargų, produkcijos ar informacijos kaupimui

K ditvertinimas

veikla-darbas (ang. Activity, vaizduojamas suapvalintas keturkampis) – tai konkretus darbų sekos juostos atliekamas darbas. Šioje diagramoje naudojamos trijų rūšių veiklos:

šaltinis/pabaiga (ang. Source/sink) - sukuria darbo sekos šaltinį, kai yra nežinomas šios sekos iniciatorius ir darbo sekos pabaigą, kai nežinomas pabaigos iniciatorius.

darbų seka (ang. Workflow) – tai ryšys, naudojamas dviejų darbų sujungimui į vientisą seką.

Šių konceptualių modelių sukūrimas leido išnagrinėti VRS sistemą pagal visus svarbiausius banko informacinės architektūros aspektus:

• motyvacinis („kodėl?“ – tikslų diagrama); • žmonės („kas?“ – verslo sąveikų diagrama); • funkcinis („kaip?“) ir laiko („kada?“) – veikimo diagrama; • tinklo („kur?“) ir duomenų („kas?“) – komunikacinis modelis. Visi aspektai išnagrinėti pagal Bazelio II reikalavimus bankų IS, taip pat remiantis jau sukurtais rizikos

valdymo sistemų produktais, todėl galima teigti, kad gauta interpretacija – universali priemonė pirminei banko IS analizei, ar kredito rizikos analizei naudojama VRS atitinka Bazelio II reikalavimus.

3.4. Konkretaus banko IS analizė

Atliekama konkretaus banko IS analizė, tiriant pateiktą informaciją, kurią sudaro: 1. Surenkamos, apdorojamos bei panaudojamos informacijos proceso schema; 2. Vidinių reitingų metodologija; 3. Kredito, operacinės ir rinkos rizikų valdymo modeliai; 4. Duomenų saugykloje saugomų duomenų parametrai; 5. Kapitalo pakankamumo skaičiavimo modelis Tomis pačiomis priemonėmis, kaip ir kuriant diagnostinės banko ISPS rizikos valdymo konceptualų modelį,

sumodeliuojama konkretaus banko IS. 3 pav. pateikiama šio banko VRS veikimo diagrama. Lyginant su konceptualiu modeliu matyti, kad esminiai VRS pagal Bazelį II elementai: • rizikos komponentai, rizikos svorio funkcija neskaičiuojami; • reitingai neturi tiesioginio ryšio su kapitalo pakankamumo apskaičiavimu; • nerealizuotas tiesioginis bankų priežiūros institucijų priėjimas prie duomenų, neišlaikomi kiti minimalūs

reikalavimai. Naudojamas standartizuotas kredito rizikos skaičiavimo metodas, kurio paskolų grupavimo metodai neleidžia

optimizuoti specialiųjų atidėjimų kiekvienai paskolai ir nors tikslesniam paskolų įvertinimui taiko vidinių reitingų skaičiuoklę, tačiau tai neturi tiesioginės įtakos kapitalo poreikio optimizavimui.

4. Tolimesnė ISPS kūrimo perspektyva

Remiantis tradiciniu sistemos vystymo gyvavimo ciklu, Zachmano IS architektūra, Bazelio II reikalavimais, numatomi sekantys ISPS vystymo etapai:

1. Loginė perspektyva (sisteminis modelis);

– 16 –


2. Fizinė perspektyva (technologinis modelis); 3. Detalus pristatymas (konkretus pritaikymas).

3 pav. Banko VRS veikimo diagrama

Pagal aukščiau išdėstytus tyrimų bei modeliavimo rezultatus numatoma kurti ekspertinę žinių bazę, o banko IS atitikimo Bazelio II reikalavimams kontrolės mechanizmą kurti fuzzy (neryškios aibės) logikos pagrindu. Sukaupta duomenų bazė apie Bazelio II reikalavimus ir jų įgyvendinimą leis surinkti sistemintą informaciją apie banko IS būklę, o analitinė sistemos dalis leis ją interpretuoti bei pateikti banko IS optimizavimo pagal Bazelį II sprendimų variantus. Tokiu būdu gaunama pilnavertė ISPS, kaupianti, tikrinanti, analizuojanti ir siūlanti įvairius sprendimo kelius bei teikianti alternatyvius IS optimizavimo projekto variantus.

5. Išvados

1. Pirminiai bankų IS pagal Bazelį II VRS tyrimo aspektai yra šie: IS duomenų šaltiniai, duomenų saugyklos, kredito, rinkos ir operacinių rizikų modeliavimas, scenarijų analizė, kredito rizikos komponentai (PD, LGD, EAD), rizikos svorio funkcija, prižiūrėtojo teisės, reitingo/skoringo skaičiavimo variklis, užstatų valdymas, įvairaus sudėtingumo lygio ataskaitų rengimas.

2. Sukurtos rizikos valdymo sistemos siūlo papildomus sprendimų komponentus: duomenų modeliavimas/žemėlapiavimas, multidimensinių duomenų bazių panaudojimas, atskaitomybės bei ataskaitų atitikimas tarptautiniams apskaitos standartams, limitų valdymas ir kiti;

3. ISPS konceptualaus lygmens, analizuojančios banko IS atitikimą Bazelio II reikalavimams VRS aspektu, modelis, apibūdina visus svarbiausius banko IS veiklos aspektus: motyvacinį, žmonių, funkcinį, laiko, tinklo, duomenų, jis gali būti taikomas kaip iliustratyvi grafinė banko IS analizės priemonė.

4. ISPS konceptualaus lygmens modelio perspektyva – programinė įranga, realizuota žinių bazės, fuzzy logika principais, skirta tiksliam bankų IS atitikimo Bazeliui II testavimui bei tolimesnio VRS diegimo projektavimui.

Literatūros sąrašas [1] Algorithmics. Addressing the Challenges of the Basel Capital Accord (BIS II). Algorithmics Incorporated, November

2002. [2] Basel Committee On Banking Supervision. The Internal Ratings-Based Approach. Consultative Document. BIS, Basel

Switzerland, 2001. - 108 p.

– 17 –


[3] Basel Committee On Banking Supervision. The New Basel Capital Accord. Consultative Document. BIS, Basel Switzerland, 2001. - 133 p.

[4] B.O'Connell. Risk Management Software Spells Relief for Bankers. BankingTechnology News. [žiūrėta 2004.01.10]. Prieiga per internetą: http://www.banktechnews.com/btn/articles/btnjun01-6.shtml

[5] Ch.Ilako. The New Basel Accord. Bank`s current state of readiness, a European perspective. Pricewaterhouse Coopers. Presentation Material. 2001.

[6] Ch.Sidler, G.David. Impact of the New Basel Accord. White paper: Basel 2, EDS. 2003. 68 p. [7] D.Ashenden. The impact of Basel II on IT in financial servines. Out-law.com. [žiūrėta 2004.01.10]. Prieiga per internetą:

http://www.out-law.com [8] D. J. Power. Web-Based and Model-Driven Decision Support. Systems: Concepts and Issues. Prepared for AMCIS 2000,

Americas Conference on Information Systems, Long Beach, California, August 10th - 13th, 2000, „Model-Driven and Web- Based Decision Support Systems" Mini Track.

[9] D.J. Power. What is a DSS? The On-Line Executive Journal for Data-Intensive Decision Support, October 21, 1997: Vol. 1, No. 3.

[10] E. Turban, J. E. Aronson. Decision Support Systems and Intelligent Systems. Prentice Hall, Upper Saddle River, NJ , 6th edition, 2001.

[11] G. Garšva, E. Merkevičius. IT modelis Bazelio naujoje kapitalo sutartyje. Informacinės technologijos verslui – 2003. Konferencijos pranešimų medžiaga. Kaunas: Technologija, 2003, ISBN 9955-09-428-1.p.27-33.

[12] G. Mentzas. Intelligent Process Support for Corporate Decision Making, Journal of Decision Systems, Vol. 6, No. 2, pp. 117-138, 1997.

[13] J. Adomaitis. Verslo sprendimų paramos sistemų klasifikacija ir tipai. Vilnius: VU leidykla, 2002. p. [14] J. Wallis, A. Van Ceulebroeck. Addressing the Systems Architecture. Implications of Basel II. IBM Business Consulting

Services. 2001. - 44 p. [15] J. Zachman. A Framework for Information Systems Architecture. IBM Systems Journal, vol. 26, no. 3, 1987. [16] Meridien Research. Top ERM Vendors: Struggling to Find a Market [interaktyvus]. Risk Management, Volume 4, Brief

Number 5. [žiūrėta 2003.11.01]. Prieiga per internetą: http://ww.meridien-research.com [17] P. Hättenschwiler. Neue Konzepte der Entscheidungsunterstützung, Working Paper 99-4, Institute of Informatics,

University of Fribourg, March 1999. [18] P. Kawalek, P. Kueng. The Usefulness of Process Models: A Lifecycle Description of how Process Models are used in

Modern Organisations. Department of Computer Science, University of Manchester, 1997 – 12p. [19] SAP solutions. mySAP-Banking. Basel II – Solution. Presentation. September 2002. – 30 p. [20] SAS Risk management. Comply and Exceed. Credit Risk Management for Basel II and Beyond. A SAS White Paper.

2002. - 20p. [21] A. Порох. Банковские технологии в области управления рисками. Банковские Технологии, №3 (77), 2002.

Risk Management in Banks based on Intelligent Decision Support Systems

In this paper there is analyzed the application of Intelligent Decision Support Systems in banks in the context of New Basel Capital Accord. There are analyzed the requirements for banks information systems, as well there is created conceptual level model for Intelligent Decision Support Systems. Based on it the basic analysis of concrete bank information system is made. The perspective of software realization in intelligent decision support systems is proposed.

– 18 –

http://www.banktechnews.com/btn/articles/btnjun01-6.shtml

http://www.out-law.com/

http://ww.meridien-research.com/

APIE IS KŪRIMĄ KOMPONENTINIU METODU

Edvinas Pakalnickas, Saulius Gudas Kauno technologijos universitetas, Informacijos sistemų katedra

Straipsnyje aptariamas IS komponentinio projektavimo metodas skirtas patikslinti poreikių analizės ir architektūrinio IS projektavimo etapus. Aprašomos komponentinio projektavimo metodo savybės ir jo realizavimo technologija, sudarytos eksperimentinės programinės įrangos struktūros ypatumai.

1. Įvadas

Viena iš perspektyvių informacijos sistemų inžinerijos krypčių yra komponentinis IS kūrimas, kuris siekia “surinkti” IS iš komponentų. Žinomi keli komponentinio projektavimo ir programavimo požiūriai. Vienas iš jų integruoja architektūrinį ir komponentinį IS kūrimo metodus [1],[2]. Jo pagrindu buvo sukurtas komponentinis realios IS sistemos modelis. Straipsnyje aptariama eksperimentinės IS realizacija, sukurta panaudojant komponentinį sistemos modelį. Šis metodas sieja veiklos informacinės architektūros modelį ir darbų sekų modelį. Darbų sekų modelio analizės pagrindu išskiriami IS komponentai ir jų tarpusavio sąsajos, toliau pereinama prie IS projektinių sprendimų ir programavimo.

2. Komponentinis IS projektavimas

Norėdami pasinaudoti komponentinio projektavimo privalumais, mes patobulinome IS gyvavimo ciklą – projektavimo etape panaudami komponentinį sistemos modelį (KSM) 1. pav. KSM tai grafinė notacija, skirta informacijos sistemos komponentų ir jų tarpusavio ryšių identifikavimui.

VFkomponentas i

Sąsaja

S2.x

S5.x

S4.xS1.x

Valdymofunkcijos VF

Taikomiejiuždaviniai TU

Duomenųstruktūros DS

Technologiniaiprocesai

TP

S0.xTUkomponentas j

TUkomponentas j+1

DSkomponentas k

DSkomponentas k+1

TPkomponentasm

Kompiuterizuotosdarbo vietos

DVkomponentas nKDV

S9.x

Išorinė versloaplinka VA

VAkomponentas l

S8.x

1 pav. Komponentinis sistemos modelis (KSM)

Komponentinis sistemos modelis skirstomas į takelius pagal organizacijos veiklos sritis (domenus). Domenuose yra skirtingo tipo IS komponentai, kuriuos reikia specifikuoti. IS komponentų tipai priklauso nuo domeno paskirties,

– 19 –

E. Pakalnickas, S. Gudas

tai apibrėžia veiklos informacinės architektūros modelis [1]. Komponentus žymime stačiakampiais, kurių kampai yra užapvalinti, sąsajas žymime rodyklėmis, šalia nurodydami komponentų sąsajos tipą. Komponentų sąsajos tipą taip pat apibrėžia veiklos informacinės architektūros modelis [1].

Pagrindiniai KSM domenai: • valdymo funkcijų takelis “VF”, atitinka verslo domeną (BD) ir yra skirtas valdymo funkcijų ir

ekonominės veiklos specifikavimui; • taikomųjų uždavinių takelis “TU” atitinka informacinių procesų domeną (IPD) ir skirtas IS taikomųjų

uždavinių logikos realizuojantiems komponentams specifikuoti; • duomenų struktūrų takelis “DS” atitinka informacijos domeną (DD) ir skirtas IS duomenų bazės saugomos

informacijos duomenų komponentams specifikuoti; • technologinių procesų takelis “TP” atitinka technologinių procesų domeną (TPD) ir skirtas

technologiniams procesams specifikuoti; • išorinės aplinkos veiksnių takelis “VA” atitinka išorinės aplinkos domeną ir skirtas šio domeno

komponentams specifikuoti; • - kompiuterizuotų darbo vietų takelis “KDV” atitinka darbo vietų domeną kuris suvokiamas kaip darbo

vietų visuma, aprašant reikalavimus darbo vietose vykdomoms funkcijoms [2]. Pagrindiniai komponentų sąsajų tipai:

S0.x - valdymo eigos sąsajos (control flow – CF), jos sieja vieno domeno komponentus ir nurodo priežastinius domeno komponentų ryšius;

S1.x - duomenų domeno ir verslo domeno sąsajos; S2.x - informacinių procesų domeno ir verslo domeno sąsajos; S3.x - technologinių procesų domeno ir verslo domeno sąsajos; S4.x - informacinių procesų domeno ir informacijos domeno sąsajos; S5.x - technologinių procesų domeno ir informacijos domeno sąsajos; S6.x - informacinių procesų domeno ir technologinių procesų domeno sąsajos; S7.x - technologinių procesų domeno sąsaja technologijų aplinka; S8.x - verslo domeno sąsajos su verslo aplinka;

x-sąsajos komponentės numeris.

3. Eksperimentinės IS projektavimas

Eksperimentinės IS projekto komponentinį sistemos modelį sudarėme CASE sistemos Provision Workbench aplinkoje.

Pirmiausiai buvo sudarytas darbų sekų modelis (DSM), kuris aprašė IS veiklos funkcijas ir procesą. Komponentinis sistemos modelis buvo sudaromas analizuojant darbų sekų modelį 2 pav. pagal tokias taisykles [1]:

1. valdymą atliekantys DSM procesai buvo perkeliami į valdymo funkcijų takelį “VF”; 2. DSM informacijos srautai perkeliami į duomenų struktūrų takelį “DS”; 3. skaičiavimą atliekantys DSM procesai perkeliami į taikomųjų uždavinių takelį “TU”; 4. DSM materialūs srautai į technologinių procesų “TP”takelį. Toliau pereinama prie IS komponentų specifikavimo, naudojame atitinkamus objektinius UML modelius.

Kiekvienam KSM identifikuotam komponentui sudarėme klasių diagramas: • valdymo funkcijų klasių diagramą; • duomenų komponentų klasių diagramą; • taikomųjų uždavinių komponentų klasių diagramą. Kiekvieną KSM komponentą aprašėme išplėsta klase. Išplėsta klasė yra UML klasė, papildyta sąsajų

sluoksniu šalia tradicinių atributų ir metodų sluoksnių. Jei UML klasę aprašome k={A,M}, A –atributai, M- metodai , tai KSM naudojamą modifikuotą klasę aprašome

taip: K={A,M,S}, A –atributai, M- metodai, S-sąsajos. Komponentinio sistemos modelio komponentų specifikavimo pavyzdys yra 3 paveiksle.

– 20 –

Apie is kūrimą komponentiniu metodu

KOMPONENTINIS SISTEMOS MODELIS

DARBŲ SEKŲ DIAGRAMA

SąsajosInformacijos srautai

Valdymo funkcijos

aa

Sąsajos Nr.

2 pav. Komponentinis sistemos modelio sudarymo procesas

Valdymo funkcijų komponentoklasė

Duomenų stuktūrų komponentoklasė

3 pav. KSM komponentų klasės

4. Eksperimentinės IS realizacija naudojant KSM

Norėdami pasinaudoti projektavimo etapo rezultatais, turėjome išplėsti CASE sistemos saugyklą, t.y. papildyti ją žinių struktūra, reikalinga komponentiniam IS realizavimui. Todėl buvo sukurta atskira duomenų bazė, skirta KSM atributų informacijai saugoti.

Projektavimo etape sudarytas KSM klasių diagramas ir jų atributus, iš Provision Workbench eksportuojame į DBVS, kurioje bus saugomos projekto specifikacijos. Pasinaudodami Provision Workbench vartotojo sąsajos generatoriumi, sugeneruojame ekrano formas Visual Basic (VB) aplinkai. Formos yra generuojamos iš komponentinio modelio verslo funkcijų klasių diagramos. Duomenų struktūrų komponentus generuojame programos darbo metu.

Realizuojant IS, buvo sukurtas komponentas, kuris, pagal informaciją esančią KSM saugykloje, formuoja duomenų struktūrų komponentus ir susieja juos su verslo funkcijų komponentais (formomis). Pagrindiniai programos darbo etapai:

1. vartotojas iššaukia tam tikrą valdymo funkcija (pvz. ekrano forma); 2. programa “žinodama” kokią kokios valdymo funkcija turi būti įvykdyta, perduoda valdymo funkcijos

pavadinimą moduliui atsakingam už domenų komponentų tarpusavio sąveiką;

– 21 –

E. Pakalnickas, S. Gudas

3. modulis, pagal valdymo funkciją, atrenka sąsajas ir komponentų atributus; 4. sukuria komponentus ir juos apjungia, toliau programos darbas vyksta kliento-serverio architektūros

principu. 5. duomenų komponentai susijungia su DBVS, duomenys, reikalingi konkrečiai verslo funkcijai atlikti,

perkeliami į duomenų struktūrų komponentus. 6. vartotojui duomenys iš duomenų struktūrų komponentų yra pateikiami į formas, kuriose jis gali dirbti su

duomenimis. Iššaukus kitą valdymo funkciją komponentų formavimo ir apjungimo procedūra kartojama iš naujo.

Sugeneruoti duomenųstruktūrų komponentai

KSM specifikacijųsaugykla

IS DBVS

1

2

Komponentųformavimo ir

apjungimomodulis

3

4

5

6

4 pav. Principinė IS programinės įrangos darbo schema

Eksperimentinės IS programinės įrangos darbo principas atitinka kliento-serverio architektūrą 4 pav. Šios programos struktūros skirtingumas yra tas, kad duomenų struktūrų komponentai yra generuojami programos darbo metu, naudojant KSM specifikacijų saugyklą (2, 3, 4 žingsnis).

Toks IS realizacijos sprendimas leido sumažinti programavimo darbų apimtis, užteko vieno modulio, kuris užtikrino duomenų mainus tarp vartotojo sąsajos (kurią sudarė 15 vartotojo sąsajos formų) ir DBVS, be to iš DBVS buvo atrenkami tik tie duomenys, kurie buvo reikalingi einamajai valdymo funkcijai, tai leido sumažinti perduodamų duomenų kiekį tarp IS ir DBVS.

Migruojant iš MS SQL DBVS į PostgreSQL DBVS, naujoje DBVS buvo sukurta duomenų bazė, pagal IS projekto specifikaciją ir perkelti IS bei komponentinio sistemos modelio specifikacijos duomenys, IS programinėje įrangoje buvo pakeistas tik kelias iki DBVS (ODBC šaltinis), IS programinė įranga veikė ir veikia be sutrikimų.

5. Išvados

Eksperimentinės IS kūrimo procese išryškėjo pagrindiniai komponentinio sistemos modelio privalumai ir trukumai.

Kaip trukumą galime paminėti tai, kad KSM naudojimas reikalauja daugiau IS projektuotojo darbo, bet tai atsveria privalumai, kuriuos mes gauname naudodami KSM:

• KSM suformuoja IS projekto specifikacijas, kurios įgalina generuoti komponentų ir sąsajų specifikacijas; • sąsajų ir komponentų specifikacijos leidžia automatizuoti komponentų sudarymą ir jų integravimą, ko

pasėkoje sumažėja programuotojo darbo apimtis;

– 22 –

Apie is kūrimą komponentiniu metodu

• sumažėja klaidų tikimybė, nes atributai automatiškai surenkami iš projektavimo aplinkos ir perkeliami į programą;

• sumažėja testavimo ir derinimo darbų apimtis. Šis projektavimo metodas turėtų būti vystomas, siekiant apjungti skirtingus IS hierarchijos lygius.

Literatūros sąrašas [1] Pakalnickas E., Gudas S. Informacijos sistemos projektavimas ir realizavimas komponentiniu metodu. Informacijos

mokslai, 2003, t. 24, p. 59-68. [2] Gudas S. The component-based information system requirements modeling. Business operation and its legal

environment: processes, tendencies and results. Riga "Biznesa augstskola Turiba" SIA 2002, p. 98-102. [3] Brown W.A. Large-Scale, Component-Based Development. Prentice Hall PTR, 2000, ISBN 0-13-088720-X. [4] Apperly A., Hofman R., Latchem S., Maybank B., McGibbon B., Piper D., Simons C. Service- and Component-based

Development: Using Select Perspective™ and UML. Addison Wesley, 2003, ISBN 0-321-15985-3.

About Component Based IS Desing

The paper presents the component-based information system design method, which is used for IS requirements specification, the major steps of IS code realization technology based on component design method, designed experimental IS software structural properties.

– 23 –

DOKUMENTŲ KONTEKSTO ANALIZĖ ORGANIZACIJOS DOKUMENTŲ STANDARTIZACIJOS PROJEKTUOSE

Kristina Moroz Lapin Vilniaus universitetas, Matematikos ir informatikos fakultetas, Programų sistemų katedra

Naugarduko 24, Vilnius

Po pirmojo organizacijų kompiuterizavimo etapo daugelis jos dokumentų yra saugoma elektronine forma. Šie do-kumentai yra glaudžiai susieti su konkrečiu dorojimo įrankiu ir turinio pavaizdavimu. Tai sukelia problemas viename dokumente įvestą informaciją pakartotinai naudoti kitame, nes gali skirtis tiek jų pavaizdavimas, tiek naujo dokumento kūrimo įrankis. Be matomo dokumento turinio svarbi yra informacija apie dokumentą, vadinamą dokumento kontekstą. Šios problemos yra gvildenamos dokumentų standartizacijos projektuose. Šiame straipsnyje yra apžvelgiamas vienas iš uždavinių, standartizuojant organizacijos dokumentus, būtent jų konteksto analizė..

1. Įvadas

Daugelis šiuolaikinės organizacijos dokumentų yra saugoma elektronine forma. Pastarųjų dokumentų kūrimas, modifikavimas ir platinimas yra paremtas informacijos technologijomis. Nuolatinė technologijų kaita apsunkina informacijos, esančios dokumentuose, pasiekimą ir naudojimą. Dalis informacijos yra iš viso prarandama. Doku-mentų formatų ir ruošimo sistemų įvairovė bei nuolatinė informacijos technologijų kaita kelia informacijos priėjimo ir naudojimo problemas, atliekant darbo užduotis. Problemos liečia tiek įmones, tiek visuomenines organizacijas.

Pirmame organizacijų kompiuterizavimo etape dokumentų dorojimas yra siejamas su konkrečiais dokumentų dorojimo ir platinimo įrankiais bei su konkrečiu pavaizdavimu. Jei ta pati informacija yra naudojama skirtingų klasių dokumentuose, tuomet kitame dokumente informacijos pavaizdavimas turi būti modifikuotas, atsižvelgiant į kitos dokumentų klasės pavaizdavimo reikalavimus. Vieną kartą įvestą informaciją yra sudėtinga panaudoti keletą kartų.

Antras organizacijų veiklos kompiuterizavimo etapas turi įveikti dokumentų dorojimo įrankių kaitos bei įvestos informacijos daugkartinio naudojimo problemą. Dokumento turinys turi būti atskirtas nuo jo pavaizdavimo aprašo bei konkrečių dokumentų dorojimo įrankių. Šis organizacijos dokumentų kompiuterizavimo etapas yra vadinamas organizacijos dokumentų standartizacija.

Vienas iš būdų pagerinti verslo procesus organizacijoje yra pradėti dokumentų standartizacijos projektus, paremtus nepriklausomais nuo programinės įrangos dokumentų formatais. Standartizacijos projekte yra siekiama sukurti taisykles, apibrėžiančias informacijos pavaizdavimą. Taisyklės reikalingos efektyviam, nuosekliam ir stabiliam informacinių technologijų naudojimui organizacijos veikloje. Technologijų kaitos ir ilgai saugomų elektroninių dokumentų priežiūros problemos skatina ieškoti nepriklausomų nuo sistemų ir pavaizdavimo dokumentų formatų. Šiuo metu dažniausiai yra naudojami du formatai, būtent SGML ir XML.

SGML (angl. Standard Generalised Markup Language, ISO Standard 8879) — tai tarptautinis dokumentų apibrėžties ir pavaizdavimo standartas nepriklausomoje nuo taikymo formoje [6]. Jis aprašo dokumentų klasę ir atitinkamą konkrečią struktūrą. SGML kalba aprašo tik loginę struktūrą arba dokumento turinį. Nieko nesakoma, kaip turinys turėtų būti pavaizduojamas. Pavaizdavimas yra aprašomas DSSSL kalba [6]. XML — tai SGML kalbos poaibis, skirtas aprašyti internetinius dokumentams. Tai antros kartos deklaratyvi žymenų kalba, kurioje dokumento pavaizdavimo apibrėžtys yra atskiriamos nuo loginės struktūros aprašo.

Dokumentų standartizacijos projektuose yra atliekama gili dokumentų analizė. Dokumentų analizė yra dažnai suprantama kaip dokumentų struktūrų analizė [8]. Tačiau taikant dokumentų standartus organizacijose nepakanka nustatyti vien dokumentų struktūrų. Dažnai nusistovėjusiose organizacijos dokumentuose yra informacija, kuri nėra naudojama arba dubliuojasi. Abu atvejai nėra pageidaujami. Organizacijos žinias sudaro ne tik dokumentų turinys, tačiau ir dokumentus supančios aplinkos informacija. Pastaroji informacija – dokumento vaidmens tam tikroje veikloje supratimas, kitaip vadinamas dokumento kontekstas [9]. Tik deklaratyvus dokumento aprašas leidžia saugoti tiek dokumento informaciją, tiek jo kontekstą

2. Dokumentų valdymo aplinka

Dokumentų valdymo aplinkos supratimas yra ypatingai svarbus dokumentų standartizacijoje, ypač jei yra analizuojami kelių dokumentų tipai arba dokumentai yra naudojami informacijos apsikeitimui. Tuomet dokumentų

– 24 –

Dokumentų konteksto analizė organizacijos dokumentų standartizacijos projektuose

analizė apima ne tik dokumentų struktūros, bet ir jų konteksto atitinkamoje veikloje tyrimą. Dokumento kontekstas yra matomas organizacijos veikloje veikiantiems asmenims arba agentams. Dokumentų analizė apima ir agentų bei jų veiklų tyrimą.

Elektroniniai dokumentai organizacijose yra naudojami informacijos valdymui, kaip priemonė grupuoti, organizuoti, saugoti, perkelti ir naudoti informaciją, siekiant organizacijos tikslų. Terminas elektroninių dokumentų valdymas yra suprantamas kaip tikslingas šiuolaikinių informacinių technologijų naudojimas. Dokumentų standartizacijos projekte yra svarbu identifikuoti elektroninių dokumentų valdymo aplinkos, kurioje dokumentai yra kuriami, naudojami ir modifikuojami, esybes.

1 paveikslas pavaizduoja elektroninių dokumentų valdymo aplinkos modelį, atsižvelgiant į veiklų ir resursų aspektus. Ši schema yra sukurta, naudojant ICNs [5] modeliavimo kalbą. Informacija yra sukuriama ir naudojama veiklose. Informacijos resursai yra saugyklos, kuriose informacija galėtų būti saugoma arba iš kurių būtų paimama. Rodyklės paveiksle nurodo, kad informacijos resursų srautus. Elipsės žymi veiklas, stačiakampiai — resursus. Resursai yra trijų tipų: dokumentai, sistemos ir agentai.

Dokumentai Veiklos Agentai

Sistemos

1 pav. Dokumentų valdymo aplinkos komponentai

Dokumentuose yra užrašomi duomenys, skirti suprasti žmonėms. Dokumentas yra identifikuojamas ir

tvarkomas tam tikrose veiklose. Kompiuterizuotoje organizacijoje dokumentų valdymo aplinkose paprastai veikia elektroniniai dokumentai. Informacijos technologijos doroja šiuos dokumentus

Sistemos – techninė ir programinė įranga, taikomosios programos – yra pagrindiniai dokumentų valdymo aplinkos resursai. Tačiau dokumentų informacija turi būti pasiekiama taip pat ir keičiant sistemas. Todėl svarbu yra atskirti dokumentus, kaip resursus, nuo sistemų.

Agentai — tai žmonės ir organizacijos, atliekantys veiksmus ir naudojantys dokumentus bei sistemas savo veikloje. Pilnai automatizuotose veiklose programų sistemos taip pat galėtų atlikti veiksmus, kaip antai, sukurti elektroninį laišką ir nusiųsti jį į saugyklą. Tačiau mes nagrinėjame veiklą, kurioje agentais yra tik žmonės ir organizacijos. Dokumentų ir sistemų kontekste agentai paprastai yra vadinami naudotojais. Agentai yra grupuojami, remiantis jų veikloje atliekamais vaidmenimis. Vaidmuo – tai agentų užduočių, atsakomybė ir teisių visuma, pavyzdžiui, sistemos naudotojas arba dokumentų saugyklos naudotojas.

Informacija kuriama ir naudojama veiklose gali būti saugoma įvairiai, būtent žmonių galvose ir patirtyje, organizacijos kultūroje, techninės ir programinės įrangos sprendimuose, popieriniuose ir elektroniniuose dokumentuose.

Elektroninių dokumentų valdymo aplinka gali būti viena organizacija. Šiuolaikiniame pasaulyje verslo procesai dažnai apima kelias organizacijas, partneriai dalina bendrus resursus. Tuomet elektroninių dokumentų valdymo aplinka, kurioje veikia organizacija arba asmuo, yra pakankamai sudėtinga. O standartizacvijos projektas apima visas bendradarbiaujančias organizacijas.

Šiame straipsnyje yra nagrinėjama dokumentų valdymo aplinkos arba konteksto analizė.

3. Dokumentų valdymo aplinkos analizė

Dokumento kontekstą sudaro [9]:

– 25 –

K. Moroz Lapin

• aplinka, kurioje dokumentai yra kuriami ir naudojami, bei • agentai, kuriantys ir naudojantys dokumentus.

Dokumentų valdymo aplinkos analizei yra keliami šie tikslai: • Suvokti dalykinę sritį ir dokumentų vaidmenį joje. Dokumentų valdymo aplinka yra organizacijų, žmonių,

veiklų ir dokumentų tinklas, todėl dažnai yra labai sudėtinga. Tokios dalykinės srities supratimas gali būti sudėtingas net darbuotojui, ilgą laiką dirbančiam tokioje aplinkoje. Kita vertus, standartizacijos ekspertai ir konsultantai nepažįsta dalykinės aplinkos, ten naudojamos dalykinės terminologijos ir nusistovėjusių darbo metodų.

• Bendravimas. Standartizacijos projektai gali tęstis keletą metų, bendradarbiaujant organizacijos darbuotojams ir konsultantams. Analizė yra priemonė suvienodinti projektuotojų ir naudotojų dalykinės srities supratimą.

• Agentų poreikių nustatymas. Sėkmė standartizacijos projekte gali būti pasiekta tik nuodugniai nagrinėjant agentų (organizacijų ir asmenų) reikalavimus ir atsižvelgiant į juos naujuose technologiniuose sprendimuose.

• Dokumentų apdorojimo perprojektavimas. Dokumentų standartizacija dažnai reiškia senų dokumentų tipų perprojektavimą ir jų apdorojimo pakeitimą [1]. Diegiant naujus ir efektyvius dokumentų dorojimo būdus, būtina suprasti senus dokumentų dorojimo būdus. Šiems tikslams pasiekti, analizės rezultatas turėtų būti ne tik dokumentų aprašai, bet ir veiklų, agentų bei jų

užduočių aprašai. 2 paveikslas pavaizduoja dokumentų analizės proceso modelį. Dokumentų analizės pradžioje apibrėžiama ir aprašoma analizuojama dalykinė sritis.

Dalykinė sritis apibrėžiama lygiagrečiai modeliuojant procesus, dokumentus ir vaidmenis. Modeliavimas atliekamas, analizuojant procesus ir būsenas.

Procesų modeliavimas yra naudojamas kaip priemonė identifikuoti smulkesnes dalykinės srities veiklas, atsakingas organizacijas ir dokumentus, kuriamus ir naudojamus šiose veiklose.

Dokumentų modeliavimas duoda detalesnę informaciją apie pasirinktą dokumentų tipų rinkinį. Darbas su pasirinkto tipo dokumentais yra modeliuojamas būsenų diagramose [2][4], kurios yra dokumentų modelio dalis. Dokumentų modeliavimas yra atliekamas trimis etapais:

• objektų modeliavimas, • gyvavimo ciklų modeliavimas ir • turinio modeliavimas.

Dalykinės srities aprašymas

Procesų modeliavimas Dokumentų modeliavimas Rolių modeliavimas

Naudotojų poreikių analizė

Analizės ataskaitos rengimas

2 pav. Dokumentų standartizacijos modelis

– 26 –

Dokumentų konteksto analizė organizacijos dokumentų standartizacijos projektuose

Objektų diagramoje yra aprašomi dokumentų objektai ir jų santykiai. Gyvavimo ciklo diagrama parodo doku-mento objektų dinamiką laike. Turinio modelyje yra analizuojama dokumento struktūra. Turinio modeliavimas apima preliminaraus SGML arba XML dokumentų klasės aprašo (DTD) projektavimą. Vaidmenų modelyje yra aprašomi pagrindiniai dokumentų naudotojai, jų dokumentų valdymo veiksmai ir jų santykiai. Naudotojų poreikių analizėje poreikiai yra siejami su busimu dokumentų valdymu. Analizės proceso pabaigoje visi minėti aprašai yra surenkami į bendrą ataskaitą.

4. Dokumentų analizės ataskaitos struktūra

Visi 2 paveiksle dokumentų konteksto analizės etapai sukuria tam tikras galutinės ataskaitos skyrius. Pirmo etapo rezultatas – organizacijos, vykdančios dokumentų struktūrizacijos projektą, struktūros aprašas. Tarporganizaciniame projekte yra nagrinėjami organizacijų vaidmuo dalykinėje veikloje, jų struktūra ir informacijos srautai.

Vaidmenų modeliavimo etape yra kuriami vaidmenų aprašai ir struktūra. Išanalizavus dokumentų ir vaidmenų santykį, yra sudaroma dokumentų – vaidmenų santykio lentelė. Remiantis šia lentele bus apibrėžiami dokumentų esybių atributai.

Dokumentų modelio aprašą sudaro sudaro šie aprašai: • dokumentų aprašai, • dokumentų santykių diagrama, • dokumentų būsenų diagrama, • dokumentų komponentų aprašai, • pakartotino naudojimo lentelė, • preliminario dokumentų klasių apibrėžtys Procesų modeliavimo metu, veiklos procesai yra išskaidomi į smulkesnes veiklas, nagrinėjami valdymo srautai.

Programų sistemų kūrimo metu procesų analizė yra atliekama, siekiant automatizuoti veiklas [4]. Standartizacijos projekte šis etapas turi kitą tikslą, būtent identifikuoti veiklas, aktorius ir dokumentus, siekiant pagerinti jų suvokimą ir nustatyti tarpusavio ryšius [3]. Jei standartizacijos projekto tikslas numato dokumentų saugyklos kūrimą, tuomet procesų analizės rezutate yra kuriami įvesties ir išvesties dokumentų modeliai. Dokumentų išvesties modelis parodo, kokios veiklos ir kurie aktoriai kuria tam tikrus dokumentus. Dokumentų ivesties modelis, atvirkščiai, parodo, kokie dokumentai ir kokių agentų veiklose yra naudojami. Apibendrinant, procesų modeliavimo rezutatas – veiklos diagramos ir įvesites bei išvesties dokumentų modeliai.

Naudotojo poreikių analizėje yra remiamasi įvesties dokumentų modeliu. Poreikių analizė nesiskiria nuo tradicinės naudotojo poreikių analizės, kuriant pragramų sistemas[4].

Analizės pabaigoje visi minėti dokumentai yra surenkami į bendrą ataskaitą.

5. Išvados

Elektroninių dokumentų valdymo aplinkos dažnai yra sudėtingas dokumentų saugyklų, sistemų ir organizacijų tinklas. Šių aplinko darbo procesuose dalyvauja asmenys iš skirtingų organizacijų ir su skirtingais vaidmenimis. Dokumentų standartizacija siekia paremti informacijos keitimąsi tarp asmenų ir organizacijų bei pagerinti sistemų keitimo valdymą.

Dokumentų standartizacijoje dokumentai yra nagrinėjami platesniame kontekste. Be įprastos dokumentų struktūros yra nagrinėjamas dokumentų kontekstas, kuris apima veiklas, agentus ir sistemas. Konteksto analizės veikla yra panaši į įprastą programų sistemų dalykinės srities analizės veiklą. Tačiau šių veiklų tikslai struktūrizacijos projekte skiriasi.

Dokumentų standarizacija yra viena iš pagrindinių busimo verslo proceso gerinimo veiklų. Vykdomų standartizacijos projektų patirtis parodė, sudėtingos struktūros organizacijoje tokie projektai gali tęstis net keletą metų. Tai yra sudėtingas projektas, kuriame yra naudojami programų sistemų kūrimo metodai, dalykinės srities analizės metodikos, projektų ir informacijos valdymo priemonės.

Literatūros sąrašas [1] K. Braa, T. Sandahl. Approaches to standartisation of documents. In Wakayama, S. Kannapan, C.M. Khoong,

S. Navanthe, J. Yates. Information and Process Integratgion in enterprises: Rethinking Documents. Norwell (MA): Kluwer Academic Publishers, 1998, pp. 125 – 142.

– 27 –

K. Moroz Lapin

[2] G. Booch, J. Rumbaugh, J. Jakobson. The Unified Modeling Language User Guide. Reading (MA): Addison-Wesle, 1999.

[3] B. Curtis, M.A. Kellner, J. Over. Process Modelling. Communications of the ACM, 35(9), 1992, pp. 75-90. [4] A. Čaplinskas. Programų sistemų inžinerijos pagrindai, I ir II dalis MII leidykla, 1998. [5] C. A. Ellis. Information Control Nets: a mathematical model of office information flow. Proceedings of the Conference

on Simulation, Measurement and Modelling of Computer Science (special issue). ACM SIGMERICS Performance evaluation Review, 8(3), (1979).pp.225-238.

[6] C.F. Goldfarb. The SGML Handbook. Oxford, UK: Oxford University Press , 1990. [7] ISO Standard 10179, Document Style Semantics and Specification Language, 1996. [8] E. Maler, J. El Andaloussi. Developing SGML DTDs. From text to model to markup. Upper Saddle River (NJ):

Prentice Hall., 1996. [9] V. Salminen, V. Lyytikainen, P. Tiitinen, Putting document into their work context in document analysis. In

Information Processing and management, 36 (2000), pp.624-641.

The Analysis of Document Context in Standardisation of the Organisational Documents

Most documents in modern organisations are in electronic form. They are closely bounded to the particular formats and systems. Permanent changes in information technology cause problems accessing and using the information. Document standardisation projects intend to find more effective and consistent ways to use information technology. The main goal is to create the rules which define the declarative and application independent way information is represented in documents. The main activity in document standardisation is extended document analysis that requires analysis of document structures and understanding of the role of documents in work processes. In this paper we discuss the document context analysis as a part of document analysis.

– 28 –

ONTOLOGIJŲ NAUDOJIMAS TEISINIŲ ŽINIŲ BAZĖMS LYGINTI

Laima Paliulionienė Matematikos ir informatikos institutas

Akademijos g. 4, Vilnius

Straipsnyje aptariamas teisinių dokumentų palyginimo uždavinys ir ontologijų panaudojimas teisinių žinių bazių lyginamojoje analizėje. Nagrinėjamas freimų logikos taikymas šiam tikslui bei modelių generavimas.

1. Įvadas

Teisės aktų (įstatymų, nutarimų, nuostatų ir pan.) palyginimas ir jų harmonizavimas yra aktualus klausimas Europos Sąjungos valstybėms, ypač naujoms jos narėms, o reiškia ir Lietuvai. Taip yra dėl intensyvaus prekių ir žmonių srautų judėjimo tarp šių šalių, įmonių bendradarbiavimo bei politinių siekių sudaryti panašias sąlygas ES valstybėse. Dirbtinio intelekto panaudojimo galimybės šioje srityje yra mažai ištirtos. Tai nenuostabu, nes teisininkai lyginamąją analizę supranta kaip teisės sistemų palyginimą, o ne kaip atskirų įstatymų palyginimą. Tokios lyginamosios analizės automatizavimo galimybės yra menkos.

Mes kalbėsime tik apie panašių teisinių dokumentų palyginimo automatizavimą. Galima išskirti dvi tokio palyginimo rūšis: a) skirtingų to paties teisės akto versijų palyginimas (pavyzdžiui, alternatyvių projektų, projekto ir galiojančio dokumento, dokumento iki ir po pakeitimo palyginimas), b) skirtingų valstybių analogiškų teisės aktų palyginimas.

Ontologijos yra semantinis pagrindas kompiuterizuojant įvairius teisės aspektus – ne tik teisės aktų palyginimą, bet ir jų analizę, rengimą, teisinės informacijos paiešką, veiklos optimizavimą remiantis teisės normomis, konkrečių gyvenimo situacijų teisinį kvalifikavimą. Ontologijose išskiriamos, susiejamos ir aksiomatizuojamos dalykinės srities sąvokos.

Šiame straipsnyje nagrinėjamos automatizuotos lyginamosios analizės galimybės, kai teisės aktams formalizuoti ir teisės ontologijoms užrašyti naudojama freimų logika (F-logika). Teisinių žinių bazių skirtumas suprantamas kaip išvadų iš galimų situacijų skirtumas.

Straipsnis turi tokią struktūrą. 2-ajame skyriuje aptariami teisinių dokumentų palyginimo uždaviniai bei apžvelgiami literatūroje siūlomi intelektualizuoti sprendimai. 3-iajame skyriuje nagrinėjamas ontologijų vaidmuo teisinių žinių bazių sistemose. 4-ajame skyriuje apžvelgtas F-logikos formalizmas, kurį siūloma naudoti teisinių žinių bazėms bei ontologijoms užrašyti. 5-ajame skyriuje siūloma žinių bazių modelių generavimo taisyklė, naudojama žinių bazėms palyginti. 6-ajame skyriuje pateiktas teisinių žinių bazių palyginimo pavyzdys. Straipsnio išvados pateiktos 7-ajame skyriuje.

2. Teisės aktų palyginimas

Teisėje lyginamoji analizė paprastai suprantama kaip teisės sistemų, sąvokų, vertybių lyginimas, o ne kaip atskirų įstatymų lyginimas. Galima paminėti tokias teisinės lyginamosios analizės savybes:

- lyginimas apima kelis teisės aktus, susijusius su nagrinėjama sritimi, - lyginamos sąvokos, - lyginama tam tikru aspektu (pvz., negalios sąvokos lyginamos ne medicininiu, o diskriminavimo aspektu, t.y.

adaptacijos visuomenėje ir darbo rinkoje požiūriu), - lyginama pagal tam tikrus parametrus, - analizuojamos skirtumų priežastys (pvz., istoriniai skirtumai, tikslų skirtumai). Taip suprantamos lyginamosios analizės automatizavimo galimybės yra menkos. Mes kalbėsime tik apie

panašių teisinių dokumentų palyginimo automatizavimą. Galima išskirti dvi tokio palyginimo rūšis: a) skirtingų to paties teisės akto versijų palyginimas (pavyzdžiui, alternatyvių projektų, projekto ir galiojančio dokumento, dokumento iki ir po pakeitimo palyginimas), b) skirtingų valstybių analogiškų teisės aktų palyginimas. Tai yra sudėtingas uždavinys, ypač kai teisės aktas yra didelės apimties ir sudėtingos struktūros. Dirbtinio intelekto panaudojimo galimybės šioje srityje yra mažai ištirtos. Yra tik keletas šį klausimą nagrinėjančių darbų. Darbe [4] lyginimo tikslas yra nesuderinamumo nustatymas; jame siūloma taikyti metataisyklių lygį imituojant teisininkų

– 29 –

L. Paliulionienė

mąstymą, kai reikia pasirinkti vieną iš kelių nesuderinamų išvadų. Darbe [2] siūloma palyginti skirtingas teisės akto versijas, atsirandančias dėl teisės akto pakeitimų, naudojant ontologijų, išreikštų deskriptyviosiomis logikomis, integravimą, o po to – klasifikavimą jungtinėje ontologijoje. Palyginimo rezultatas yra sąryšiai tarp teisės aktą sudarančių normų, kurie nusako pakeitimo tipą (normos išplėtimą, susiaurinimą, įtraukimą, panaikinimą ir pan.). Darbe [1] taip pat siūloma palyginimą traktuoti kaip atskirą ontologijų integravimo atvejį, naudojant ontologijų vaizdavimo kalbą OWL. Ir vienu ir kitu atveju rezultatas neparodo konkrečių skirtumų.

3. Ontologijų vaidmuo

Siekis automatizuoti teisės aktų palyginimą neišvengiamai atveda prie teisės ontologijų konstravimo. Ontologijos aprašo bendrines arba dalykinės srities sąvokas, sąryšius tarp šių sąvokų bei aksiomas, kurios riboja apibrėžtų sąvokų ir sąryšių interpretavimą. Formaliai žiūrint, ontologija yra loginė teorija [3]. Žiūrint iš praktinės pusės, ontologija aprašo teiginių ir užklausų žodyną. Be to, atsakymus į užklausas tuomet galima pateikti ne tik pagal užklausoje vartojamas sąvokas, bet ir pagal ontologinius sąryšius tarp jų, pavyzdžiui, išplečiant atsakymo paieškos sritį pagal dalinius arba visiškus sinonimus, pagal taksonominę hierarchiją aukštyn arba žemyn, o daugiareikšmėms sąvokoms naudojant ir daugybinę klasifikaciją. Potenciali praktinė ontologijų nauda yra jų pakartotinio naudojimo galimybė konstruojant kitas sistemas.

Teisės ypatumas kuriant ontologijas yra tas, kad joje yra sunku išskirti dalykinės srities sąvokas. Teisė interpretuoja pasaulį, teisės normos skirtos nustatyti tvarką įvairiose socialinio gyvenimo srityse. Todėl beveik bet koks pasaulio daiktas gali būti priskirtas teisės sričiai. Tai taip pat reiškia, kad mums tenka naudoti ir bendro pobūdžio sąvokas – agentai, veiksmai, procesai, laikas, erdvė ir kt. Teisines ontologijas yra tikslinga jungti su epistemologiniu lygiu, susijusiu su samprotavimais ir argumentavimais.

Yra du pagrindiniai ontologijos konstravimo būdai: nuo viršaus žemyn (nuo bendrų dalykų prie atskirų) ir nuo apačios į viršų. Pirmuoju atveju galimi du variantai: ontologija kuriama ekspertų, kurie tiesiogiai specifikuoja dalykinę sritį, arba ontologija kuriama iš egzistuojančios ontologijos ją apibendrinant, konkretizuojant arba kitaip modifikuojant. Konstruojant ontologiją iš apačios į viršų visi elementai, reikalingi ontologijai sukonstruoti, ištraukiami iš rašytinių dokumentų. Šis metodas leidžia sąvokų išrinkimui ir sąryšių tarp jų nustatymui naudoti kompiuterinius sintaksinius analizatorius, tikimybinius analizatorius ir pan.

Manau, kad tikslinga yra suderinti šiuos būdus, naudojant tiek jau sukurtas teisės ontologijas, tiek išrenkant sąvokas ir sąryšius iš teisinių dokumentų. Teisės ekspertus galima naudoti kaip konsultantus vertinant kuriamą ontologiją, nes jų tiesioginis įtraukimas į ontologijos kūrimą reikalauja daug laiko.

4. F-logika

Ontologijos gali būti užrašytos įvairiomis priemonėmis – tiek specialiai tam pritaikytomis, tiek tradicinėmis žinių vaizdavimo kalbomis. Mūsų tyrime ontologijai užrašyti naudojamas freimų logikos formalizmas F-logika [5]. Šis formalizmas jungia objektinį žinių vaizdavimo būdą su loginio išvedimo mechanizmu, grindžiamu rezoliucija. Pagrindinis F-logikos kaip ontologijos užrašymo kalbos privalumas yra tas, kad taip išreikštą ontologiją galima tiesiogiai sujungti su teisinių dokumentų žinių baze, užrašyta taip pat F-logikos kalba. F-logikos lokalumo principas leidžia aprašyti sąvokas pažingsniui, kas yra svarbu išrenkant sąvokas ir sąryšius iš teisinių dokumentų. Tačiau reikia pažymėti, kad F-logika neturi specialių ontologijų kūrimo priemonių privalumų, pavyzdžiui, darnos tikrinimo galimybės ir indeksavimo galimybės sąvokų paieškai pagreitinti.

F-programą sudaro taisyklės, kurių forma yra antraštė ← kūnas, kur antraštė yra F-molekulė, kūnas yra F-molekulių ir jų neiginių konjunkcija. F-molekulėse naudojami sąvokų vardai, atributų vardai, atributų reikšmės, predikatų simboliai. F-molekulė turi vieną iš šių pavidalų: (a) S1:S, kur S1 žymi sąvokos-klasės S egzempliorių, (b) S1::S, kur S1 žymi sąvokos S specializaciją (poklasį), (c) S[K−>R], kur S žymi konkrečiausią sąvoką (egzempliorių), K − tos sąvokos atributą, R − to atributo reikšmę, (d) S[K=>R], kur S žymi apibendrintą sąvoką (klasę), K − tos sąvokos atributą, R − to atributo reikšmių kitimo sritį, (e) S[K*−>R], kur S žymi apibendrintą sąvoką, K − tos sąvokos atributą, kurio reikšmę galima naudoti sąvokos egzemplioriuose neišreikštiniu būdu, R − to atributo reikšmę, kuri pagal nutylėjimą perduodama sąvokos egzemplioriams, (f) P(S1, ... ,Sn), kur P yra predikato vardas, S1, ... , Sn − sąvokos. Sąvokų ir atributų vardai yra identifikaciniai termai, kurie gali turėti argumentus. Atributai gali būti daugiareikšmiai; tuomet naudojami ženklai −>>, =>> ir *−>>.

Štai F-programos pavyzdys: asmuo [vardas => string, pavardė => string, gimimo_data => data, vaikai=>> asmuo] darbuotojas :: asmuo [sodra_nr=>string] vaikas(asmuo) :: asmuo

– 30 –

Ontologijų naudojimas teisinių žinių bazėms lyginti

Y : vaikas(X) ← X [vaikai −>> Y] jonas : darbuotojas [vardas −> “Jonas”, pavardė −> “Jonaitis”, vaikai −>> {rita, marius}, sodra_nr −>

“SD1010017”] Užklausos pavyzdys: ?- Y : vaikas(jonas) Atsakymas: Y = rita Y = marius F-molekulėse galima išskirti primityvias sudėtines dalis, vadinamas atomais. F-molekulės yra atomų

konjunkcijos. Pavyzdžiui, molekulė darbuotojas :: asmuo [sodra_nr=>string] susideda iš atomų darbuotojas :: asmuo ir darbuotojas [sodra_nr=>string], o molekulę jonas : darbuotojas [vardas −> “Jonas”, pavardė −> “Jonaitis”, vaikai −>> {rita, marius}} sudaro atomai jonas : darbuotojas, jonas [vardas −> “Jonas”], jonas [pavardė −> “Jonaitis”], jonas [vaikai −>> {rita}], jonas [vaikai −>> {marius}].

5. Modelio generavimas

Teisinių žinių bazių skirtumą mes apibrėžiame kaip išvadų iš galimų situacijų skirtumą. F-logikos išvedimo mechanizmas įgalina gauti tik atsakymą į užklausą panašiai kaip Prologe. Kad galėtume gauti visas konkrečios situacijos išvadas ir jas palyginti, F-logiką reikia praplėsti formaliu įrodymu, grindžiamu modelių generavimu [6]. Pagal modelio generavimo taisyklę į modelį pirmiausia įtraukiami faktai, toliau pagal taisyklių grandines gaunamos išvados iš šių faktų.

Modelio generavimo taisyklė. Pradinis modelis yra tuščia aibė. Tai, kad iš žinių bazės KB galima sugeneruoti modelį N, žymėsime KB├M N. Modelis generuojamas taip:

1. Horno disjunktai. Jei žinių bazėje yra taisyklė C ← A, kur A susideda iš atomų, ir egzistuoja keitinys σ toks, kad Aσ yra teisingas iki šiol sukonstruotame modelyje N, o Cσ šiam modeliui nepriklauso, tai N išplečiamas įtraukiant į jį Cσ.

2. Bendrieji disjunktai. Jei žinių bazėje yra taisyklė C ← A, not P1, …, not Pn (n>0), kur A susideda iš atomų ir P1, …, Pn yra atomai, ir egzistuoja keitinys σ toks, kad Aσ yra teisingas iki šiol sukonstruotame modelyje N, o Cσ šiam modeliui nepriklauso, tai N išplečiamas, gaunant du modelius su specialiu modaliniu operatoriumi “k” − modelį N ∪ {Cσ, ~k(P1σ), …, ~k(Pnσ)} ir modelį N ∪ {k(P1σ; …; Pnσ)}. Čia ~k(P) reiškia, kad tikimasi, jog modelis neturės fakto P, o k(P1; …; Pn) reiškia, kad tikimasi, jog modelis turės bent vieną iš faktų P1, …, Pn. Toliau generuojant modelius atmetami tie, kuriuose yra ~k(P) ir P. Jei modelyje yra k(P1; …; Pi; … ; Pn) ir Pi (i=1,…,n), iš jo pašalinamas k(P1; …; Pi; … ; Pn). Iki galo sugeneravus visus modelius atmetami tie, kuriuose yra k(P1; …; Pn), bet nėra nė vieno Pi (i=1,…,n, n>0). Galutiniai modeliai gaunami iš neatmestų modelių pašalinus faktus su operatoriumi “k”.

3. Lygybės predikatas. a) Bet kokiai konstantai p iš žinių bazės KB Herbrand’o universumo U(KB) modelis N išplečiamas įtraukiant į

jį p=p. b) Jei p=q priklauso modeliui N, įtraukti į jį ir q=p. c) Jei p=q ir q=r priklauso modeliui, įtraukti į jį ir p=r. d) Jei p=q priklauso modeliui ir faktas L1, kuriame yra konstantų p, priklauso modeliui, įtraukti į modelį ir L2,

gautą iš L1 keičiant kiekvieną konstantą p į q. e) Vienareikšmiškumas (čia ~> reiškia −> arba *−>): jei p[m ~> s] ir p[m ~> t] priklauso modeliui, įtraukti į jį ir

s=t. Faktai, gauti pagal punktus nuo a) iki d), reikalingi tik modelio generavimo metu. Vartotojui jie nėra įdomūs ir

jam nepateikiami. Faktai, gauti pagal e) punktą, dažnai reiškia klaidą žinių bazėje. 4. Poklasio santykis. a) Bet kokiai konstantai p, priklausančiai žinių bazės KB Herbrand’o universumui U(KB), modelis N

išplečiamas įtraukiant į jį p :: p. b) Jei p :: q ir q :: r priklauso modeliui, įtraukti į jį ir p :: r. c) Jei p :: q ir q :: p priklauso modeliui, įtraukti į jį ir p=q. d) Jei p : q ir q :: r priklauso modeliui, įtraukti į jį ir p : r.

– 31 –

L. Paliulionienė

Faktai, gauti pagal a), b) ir d) punktus, reikalingi tik modelio generavimo metu. Vartotojui jie nėra įdomūs ir jam nepateikiami. Faktai, gauti pagal c) punktą, dažnai reiškia klaidą žinių bazėje.

5. Signatūros reiškinys. Čia pateiktos taisyklės galioja vienareikšmio ir daugiareikšmio atributo signatūrai, todėl trumpumo dėlei naudojame ≈> vietoje => ir =>>.

a) Jei p[m ≈> s] priklauso modeliui ir r :: p priklauso modeliui, įtraukti į jį ir r[m ≈> s]. b) Jei p[m ≈> r] priklauso modeliui ir r :: s priklauso modeliui, įtraukti į jį ir p[m ≈> s]. 6. Reikšmės paveldėjimas. Iki galo sugeneravus modelį pagal ankstesnius punktus, jis išplečiamas faktais su

paveldėtomis atributų reikšmėmis. Tai daroma, jei tenkinamos šios sąlygos: a) q[m *−> s] priklauso modeliui, b) p : q priklauso modeliui, c) modelyje nėra fakto p[m −> t], d) jei p : u ir u :: q priklauso modeliui, ir u[m *−> t] priklauso modeliui, tai u=q (t.y. q yra konkrečiausia klasė,

kurioje apibrėžiama paveldima reikšmė). Tuomet modelis praplečiamas faktu su specialiu modaliniu operatoriumi “inh” – inh(p[m −> s]). Jis žymi

atributo reikšmės paveldėjimą (“inh” – nuo angliško žodžio “inheritance”). Jei modelyje jau buvo inh(p[m −> t]), jis pašalinamas (taip gali atsitikti sugeneravus naujus faktus po 7-o ir 8-o punkto).

7. Modelio generavimas iš paveldėtų reikšmių Horno disjunktų atveju. Iki galo sugeneravus modelį su paveldėtomis reikšmėmis pagal 6-ą punktą, toliau atliekamas generavimas įtraukiant taisykles, kurių kūne galima panaudoti naujus faktus. Jei žinių bazėje yra taisyklė C ← A, kur A susideda iš atomų, ir egzistuoja keitinys σ toks, kad:

a) Aσ yra teisingas iki šiol sukonstruotame modelyje N, b) Aσ turi savyje p[m −> s], c) inh(p[m −> s]) priklauso modeliui, d) Cσ modeliui nepriklauso, tuomet modelis N išplečiamas, gaunant du modelius − modelį N ∪ {Cσ, dinh(p[m −> s])} ir modelį N ∪

{~dinh(p[m −> s])}. Čia dinh(p[m −> s]) reiškia, kad tikimasi, jog paveldėta reikšmė nebus perklota, t.y. modelis neturės fakto p[m −> t], arba turės šį faktą kartu su faktu t=s. ~dinh(p[m −> s]) reiškia, kad tikimasi, jog paveldėta reikšmė bus perklota, t.y. modelis turės faktą p[m −> t], ir neturės fakto s=t. Iki galo sugeneravus modelius atmetami tie, kuriuose yra dinh(p[m −> s]) ir p[m −> t] ir nėra fakto t=s. Taip pat atmetami modeliai, kuriuose yra ~dinh(p[m −> s]) ir nėra p[m −> t]. Po to vėl generuojama pagal 6-ą punktą ir atmetami modeliai, kuriuose yra dinh(p[m −> s]), bet nėra nei inh(p[m −> s]), nei p[m −> t]. Neatmestuose modeliuose pašalinami faktai su operatoriumi “dinh”, o faktai inh(p[m −> s]) pašalinami, jei yra faktai p[m −> t], priešingu atveju inh(p[m −> s]) keičiami į p[m −> s].

8. Modelio generavimas iš paveldėtų reikšmių bendrųjų disjunktų atveju. Modeliai generuojami kombinuojant 2-ą punktą neigiamai taisyklės kūno daliai ir 1-ą arba 7-ą punktą (priklausomai nuo to, ar naudojamos paveldėtos reikšmės) teigiamai daliai. Iki galo sugeneravus, atmetami modeliai, kuriuose yra inh(p[m −> s]) ir ~k(p[m −> s]) ir arba nėra p[m −> t], arba jis yra, bet s=t. Taip pat pašalinami modeliai, kuriuose yra kartu inh(p[m −> s]), k(p[m −> s]) ir inh(p[m −> t]) ir nėra s=t. Neatmestuose modeliuose faktų aibės {inh(p[m −> s]), ~k(p[m −> s]), p[m −> t]} keičiamos į faktus p[m −> t], o faktų aibės {inh(p[m −> s]), k(p[m −> s])} keičiamos į p[m −> s].

Darbe [6] buvo suformuluota teorema, pagal kurią skirtumui tarp žinių bazių nustatyti pakanka sugeneruoti modelius iš elementarių testinių situacijų, neanalizuojant visų įmanomų situacijų. Kiekviena tokia situacija sudaroma iš žinių bazės taisyklių antecedentų, konkretizuojant kintamuosius konstantomis, nenaudojamomis lyginamose žinių bazėse (t.y. nepriklausančiomis tų bazių Herbrand’o universumui). Išplėtus modelio generavimo taisyklę, galioja analogiška teorema. Išimtį sudaro tik paveldėjimo atvejis, kuris reikalauja papildomo tyrimo. Trumpumo dėlei čia nekartosime apibrėžčių ir algoritmų, o pateiksime pavyzdį, demonstruojantį kaip lyginamos F-logikos kalba užrašytos teisinės žinių bazės, naudojant elementarias testines situacijas ir modelių generavimą.

6. Pavyzdys

Pavyzdyje nagrinėsime fragmentą iš Valstybinių pašalpų šeimoms, auginančioms vaikus, įstatymo. Palyginsime galiojantį šio fragmento variantą ir naujo varianto projektą.

Ontologijos fragmentas, aprašantis atitinkamas sąvokas, yra toks: pašalpa [gavėjas =>> asmuo, gavėjų_ryšys => loginis_ryšys, dydis => dydis(real, matas)] kūdikis : asmuo

– 32 –

Ontologijų naudojimas teisinių žinių bazėms lyginti

motina (asmuo) :: asmuo tėvas (asmuo) :: asmuo globėjas (asmuo) :: asmuo ir : loginis_ryšys arba : loginis_ryšys litai : matas mgl : matas Sąvokos pašalpa atributas gavėjas yra daugiareikšmis, todėl galima nurodyti kelis pašalpos gavėjus, o atributas

gavėjų_ryšys nurodo loginį ryšį tarp gavėjų – ryšys ir reiškia, kad pašalpa mokama visiems nurodytiems gavėjams, o ryšys arba reiškia, kad pašalpa mokama tik vienam iš jų.

Toliau pateiktos ištraukos iš galiojančio įstatymo ir pakeitimo projekto bei šių ištraukų formalizavimas. Galiojantis įstatymas. Gimus kūdikiui, motinai (tėvui) ar globėjui mokama 6 minimalių gyvenimo lygių (toliau

– MGL) dydžio vienkartinė pašalpa. Formalizavimas: pašalpa [gavėjas −>> {motina(X), tėvas(X), globėjas(X)}, gavėjų_ryšys −> arba, dydis −> dydis(6,

mgl)] ← gimė(X), X : kūdikis. Įstatymo projektas. Gimus pirmajam kūdikiui, motinai (tėvui) ar globėjui mokama 16 minimalių gyvenimo

lygių (toliau – MGL) dydžio vienkartinė pašalpa. Už antrą ir kiekvieną paskesnį vaiką pašalpa didinama 8 MGL. Formalizavimas: pašalpa [gavėjas −>> {motina(X), tėvas(X), globėjas(X)}, gavėjų_ryšys −> arba, dydis −> dydis(16,

mgl)] ← gimė(X), X : kūdikis[nr −>1]. pašalpa [gavėjas −>> {motina(X), tėvas(X), globėjas(X)}, gavėjų_ryšys −> arba, dydis −> dydis(16+(N–1)*8,

mgl)] ← gimė(X), X : kūdikis[nr −>N], N>=2.

Elementarios testinės situacijos ir skirtumų aibės bus tokios:

Testinė situacija Išvada pagal galiojantį įstatymą Išvada pagal įstatymo projektą

gimė(x),

x : kūdikis pašalpa [gavėjas −>> {motina(x), tėvas(x), globėjas(x)}, gavėjų_ryšys −>arba, dydis −> dydis(6, mgl)]

–

gimė(x), x : kūdikis [nr −> 1]

pašalpa [dydis −> dydis(6, mgl)] pašalpa [dydis −> dydis(16, mgl)]

gimė(x), x : kūdikis [nr −>n], n>=2

pašalpa [dydis −> dydis(6, mgl)] pašalpa [dydis −> dydis(16+(n-1)*8, mgl)]

Išvados

Teisinių žinių bazių palyginimo sėkmei yra svarbus tinkamas formalizavimas, leidžiantis išskirti esminius objektus, atributus ir jų ryšius. Ontologijų dėka išreikštiniu būdu aprašomas pasirinktas dalykinės srities konceptualizavimas.

Šiame darbe siūloma naudoti F-logiką kaip ontologijos užrašymo kalbą. Tai teikia galimybę tiesiogiai sujungti ontologiją su įstatymo žinių baze, užrašyta taip pat F-logikos kalba. F-logikos lokalumo principas leidžia aprašyti sąvokas pažingsniui, kas yra svarbu išrenkant sąvokas ir sąryšius iš teisinių dokumentų.

Pasiūlytas metodas gali būti naudojamas ne tik teisinių žinių bazių palyginime, bet ir kitų žinių bazių, išreikštų loginėmis programomis, lyginamojoje analizėje. Tokia analizė iki šiol buvo mažai tyrinėta.

Nors mes apsiribojome tik panašių teisės aktų palyginimu, verta paminėti kai kurias automatizavimo galimybes ir klasikinėje teisinėje lyginamojoje analizėje. Viena galimybė – tai automatizuotas palyginimo lentelių (kuriose kartais pateikiami palyginimo rezultatai) sudarymas pagal eksperto pateiktus vertinimus. Kita galimybė – semantinė sąvokų paieška daugelyje teisės aktų naudojant ontologinius ryšius.

– 33 –

L. Paliulionienė

Literatūros sąrašas [1] A. Boer, T. M. van Engers, R. Winkels. Using ontologies for comparing and harmonizing legislation. Proceedings of

the 9th ICAIL’2003, Edinburgh, ACM Press, 2003, pp. 60-69. [2] A. Gangemi, D. M. Pisanelli, G. Steve. A formal ontology framework to represent norm dynamics. Proceedings of the

Second International Workshop on Legal Ontologies (LEGONT), University of Amsterdam, 2001. [3] T. R. Gruber. Towards principles for the design of ontologies used for knowledge sharing. International Journal of

Human-Computer Studies, 1995, Vol. 43, pp. 907-928. [4] P. Guidotti, F. Turchi. A frame-work for law comparison. J.S.Svensson, J.G.J.Wassink, B. van Buggenhout (eds.) Legal

Knowledge Based Systems: Jurix'93: Intelligent Tools for Drafting Legislation, Computer-Supported Comparison of Law, Lelystad: Koninklijke Vermande, 1993, pp. 107-114.

[5] M. Kifer, G. Lausen, J. Wu. Logical foundations of object-oriented and frame-based languages. Technical report 93/06, Department of Computer Science, University SUNY at Stone Brook, 1993.

[6] L. Paliulionienė. Kai kurie teisinių žinių bazių lyginamosios analizės aspektai. Lietuvos matematikų draugijos XL konferencijos darbai, Technika, Vilnius, 1999, pp. 230-235.

Using Ontologies for the Comparing of Legal Knowledge Bases

The article deals with the problem of comparing legislation and using ontologies to this aim. The frame logic formalism is proposed to represent legal acts and legal ontologies, and the model generation rule designed for F-logic expressions is presented.

– 34 –

UŽKLAUSŲ SKAIDYMAS IR APDOROJIMAS MULTIDIMENSINĖSE DUOMENŲ BAZIŲ SISTEMOSE

Mindaugas Surdokas KTU Studentų g. 50

Vieninga, globali multidimensinių duomenų bazių užklausų apdorojimo sistema leidžia jos vartotojams pasiekti nesusijusių duomenų bazių duomenis. Bene didžiausia problema dirbant su multidimensinėmis duomenų bazėmis – globalių užklausų apdorojimas. Šiame straipsnyje aptariami globalių užklausų skaidymo į sub-užklausas principai.

1. Įžanga

Šiuo metu skirtingose duomenų bazėse yra saugojama labai daug duomenų. Šie duomenys vartotojui dažnai yra sunkiai prieinami, nes skirtingos sistemos naudoja savitus duomenų modelius ir originalias užklausų apdorojimo kalbas. Vienos sistemos vartotojai dažnai negali pasiekti kitoje sistemoje esančių duomenų. Todėl bėgant laikui ir augant saugojamų duomenų apimtims, atsiranda didesnis poreikis susieti skirtingas sistemas, išgaunant iš skirtingų duomenų bazių vartotojui reikiamą informaciją.

Vienas iš būdų apjungti multidimensines duomenų bazes - suformuoti multiduomenų bazės sistemą, kuri palaikytų paprastą, dažnai pasitaikantį duomenų modelį ir paprastą užklausų apdorojimo kalbą, pritaikytą populiariausioms šiuo metu egzistuojančioms sistemoms. Tokia sistema būtų prieinama produkto vartotojui, kuriam teliktų sistemai užduoti klausimą ir laukti rezultatų.

Vartotojo užduotas klausimas yra apdorojamas trimis etapais. Pirmiausia, globali užklausa yra išskaidoma į aibę mažesnių sub-užklausų. Vėliau kiekviena sub-užklausa analizuojama, ir reikalui esant, dar sykį skaidoma. Skaidymas kartojamas iki tol, kol į sub-užklausą bus galima atsakyti imant duomenis iš vienos lokalios duomenų bazių valdymo sistema.

Po globalios užklausos dekompozicijos atliekama informacijos paieška bei gautų rezultatų apdorojimas.

2. Užklausų skaidymas

Multidimensinių duomenų bazių sistemoje užklausa yra išreikšta užklausų kalba visai globaliai schemai. Dažniausiai globaliai užklausai patenkinti reikia duomenų iš skirtingų lokalių duomenų bazių valdymo sistemų (DBVS). Dėl to globalią užklausą yra neišvengiama suskaidyti į smulkesnes sub-užklausas taip, kad į kiekvieną sub-užklausą būtų galima atsakyti naudojantis tik viena lokalia DBVS.

Po to, kai visos sub-užklausos yra apdorotos, gauti rezultatai turi būti apjungiami į atsakymą panaudojant tokias operacijas, kaip prijungimas, projekcija, išrinkimas, sąjunga ir panašiai.

Sistemai perdavus globalią užklausą, ši pirmiausia yra pasiunčiama užklausų dekompozitoriui, atliekančiam užklausų išskaidymą į smulkesnes sub-užklausas. Globalių užklausų dekompozicijos procesas labai priklauso nuo sistemos sandaros ir atskirų jos modulių sąveikos.

3. Užklausos dekompozicijos pavyzdys

Peržiūrėkite sekančią globalią užklausą, lokalių duomenų bazių schemą (Pav.1) bei klasių sąryšių schemas (Pav.2).

q: select e.name, e.age, d.dept_name from employee e, department d where e.salary > 1500 and e.dept_no = d.dept_no and d.address = ‘Kaunas‘;

– 35 –

M. Surdokas

DB1 emp (emp_id, age, ename, salary, dno) dept (dno, dname) mgr_emp (mgr_id, emp_id)

DB2 employee (ssno, name, salary, dname, status) division (dno, dname, location) student (sno, name, sex, department, gpa, age)

DB3 employee (eno, ename, salary, deptno) department (dno, deptname, address)

1 pav. Lokalios duomenų bazės

Globali schema employee (ssno, name, age, salary, dept_no, manager, status) department (dept_no, dept_name, address) student (stu_id, sname, gpa, sex, dept_name, age) assistants (asst_id, name, gpa, stu_dept, sex, salary, emp_dno)

2 pav. a) Globali schema

mapping employee { origin DB1:emp e1, DB1:mgr_emp m1, DB2:employee e2, DB2:division d2, DB3:employee e3; def_ext emp_ext as select * from e1, e2, e3 where e1.emp_id *= e2,ssno and e2.ssno *= e3.eno and e1.emp_id *= e3.eno; def_att ssno as select e1.emp_id, e2.ssno, e3.eno from e1,e2,e3; def_att name as select e1.ename, e2.name, e3.ename from e1, e2, e3; def_att age as e1.age; def_att salary as select e1.salary, e2.salary, e3.salary from e1, e2, e3; def_att dept_no as select e1.dno, d2.dno, e3,dno from e1, e2, d2, e3 where e2.dname = d2.dname; def_att manager as select m1.mgr_id from e1, m1 where e1.emp_id = m1.emp_id; def_att status as e2.status; }

2 pav. b) Sąryšiai (employee)

mapping department { origin DB1:dept d1, DB2:division d2, DB3:department d3; def_ext dept_ext as select * from d1,d2,d3 where d1.dno*=d2.dno and d2.dno*=d3.dno and d1.dno*=d3.dno; def_att dept_no as select d1.dno, d2.dno, d3.dno from d1,d2,d3; def_att dept_name as select d1.dname, d2.dname, d3.deptname from d1,d2,d3; def_att addrress as select d2.location, d3.address from d2, d3;}

mapping student { origin DB2:student s1; def_ext stu_ext as select * from s1; def_att stu_id as s1.sno; def_att sname as s1.name; def_att gpa as s1.gpa; def_att sex as s1.sex; def_att dept_name as s1.department; def_att age as s1.age; }

2 pav. d) Sąryšiai (student)

2 pav. c) Sąryšiai (department)

– 36 –

Užklausų skaidymas ir apdorojimas multidimensinėse duomenų bazių sistemose

mapping assistants { origin DB2:student s1, DB1:emp e1, DB2:employee e2, DB2:division d2, DB3:employee e3; def_ext asst_ext as select * from s1,e1,e2,e3 where s1.sno=e2.ssno and s1.sno=e2.ssno and s1.sno=e3.eno; def_att asst_id as select s1.sno, e1.emp_id, e3.eno from s1,e1,e3; def_att name as select s1.sname, e1.ename, e3.ename from s1,e1,e3; def_att gpa as s1.gpa; def_att stu_dept as s1.department; def_att sex as s1.sex; def_att salary as select e1.salary, e2.salary,e3.salary from e1,e2,e3; def_att emp_dno as select e1.dno, d2.dno,e3.dno from e1,e2,d2,e3 where e2.dname=d2.dname; }

2 pav. e) Sąryšiai (assistants)

Matome, kad globali schema gauta apjungus tris schemas. Šio pavyzdžio globali užklausa reikalauja duomenų iš visų trijų duomenų bazių. Taigi, turime tris sub-užklausas, kurių kiekviena bus siunčiama atskirai lokaliai DBVS.

Pirmas žingsnis – eilutės from dekomponavimas. Abiejų klasių (employee ir department) duomenys origin srityse išgauti pasinaudojus pastarųjų klasių sąryšių aprašais. Pavyzdžiui, employee klasės duomenų šaltinis:

origin origin origin origin origin

dbl:emp_el dbl:ngr_emp ml db2:employee e2 db3:employee e3 db2:division d.2

Visi aukščiau nurodyti klasės duomenų šaltinių aprašai yra automatiškai įterpiami į naujai formuojamas sub-užklausas. Antrame žingsnyje yra apdorojamas projekcijų sąrašas. Kiekvienam atributui (name, age ir dept_name) atributų aprašai yra gaunami paveldimi iš susietų klasių. Pavyzdžiui, klasės employee atributo name užklausos aprašymas:

q1: select e1.ename, e2.name, e3.ename from e1, e2, e3

Formuojant sub-užklausų projekcijų sąrašą naudojami ne globalūs atributai, bet projekcijų sąrašo q1 atributai. Todėl globalus atributas name yra įterpiamas į pirmos sub-užklausos projekcijų sąrašą vardu ename ir panašiai. Po to, kai visi atributai projekcijų sąraše yra apdoroti ir įterpti į juos atitinkančias sub-užklausas, tuo pačiu būdu yra apdorojami globalios užklausos where predikatas.

Atliekant užklausų skaidymą, dešinė predikato pusė gali būti tiek kintamasis tiek konstanta. Jei predikato dešinė pusė yra išraiška, tada turi būti peržvelgiami visi keturi galimi išraiškos variantai. Kairė predikato pusė gali būti tik viena paprasta išraiška, tuo tarpu dešinė predikato pusė gali susidėti iš užklausos ar panašiai. Abi predikato pusės gali susidėti iš paprastų išraiškų, galiausiai abi gali turėti užklausas atributų aprašuose. Kiekvienas iš šių keturių variantų dekompozicijos algoritme turi būti sprendžiamas skirtingai. Jei atributų aprašuose bet kurioje predikato pusėje pasitaiko užklausa, tuomet pastarosios where predikatas taip pat turi būti išskaidytas, jei jis egzistuoja.

Kad būtų galima apdoroti pirmąjį predikatą pavyzdyje (e.salary > 1500), atributo salary aprašymas gautas iš sąryšių aprašų sekančiai:

q2: select l1.salary, e2.salary, e3.salary from e1, e2, e3;

Sub-užklausų predikatai suformuluoti naudojant atributus, aprašytus q2 projekcijų sąraše. Pirmos sub-užklausos predikatas yra e1.salary > 1500, o predikatas e2.salary > 1500 yra įterptas į antrą sub-užklausą, ir t.t.

– 37 –

M. Surdokas

Antram predikatui gauname abiejų pusių atributų aprašymus. Employee klasės atributui dept_no yra sekantis sąryšių aprašymas:

q3: select e1.dno, d2.dno, e3.deptno from e1, e2, e3, d2 where e2.dname = d2.dname;

Klasės department atributą dept_no aprašome: q4: select d1.dno, d2.dno d3.dno from d1, d2, d3;

Globalus jungties predikatas e.dept_no = d.dept_no yra konvertuojamas į pirmosios sub-užklausos predikatą e1.dno = d1.dno. Aukščiau paminėtu atveju užklausos q3 where predikatas taip pat turi būti suskaidytas. Pavyzdžiui, e2.dname = d2.dname yra įtrauktas į antrą sub-užklausą. Galiausiai, predikatas e3.deptno = d3.dno yra įtrauktas į trečią sub-užklausą.

Užklausos skaidymo proceso metu globalios užklausos where predikato atributai taip pat yra įtraukti į sugeneruotų sub-užklausų projekcijų sąrašus. Sugeneruotos trys sub-užklausos:

select e1.emp_id, el.ename, el.age, e1.salary, d1.dname from emp e1, dept dl where el.salary > 1500 and el.dno = dl.dno; select e2.ssno, e2.name, e2.salary, d2.dname, d2.location from employee e2, division d2 where e2.salary > 1500 and d2.location = ‘Kaunas‘ and e2.dname = d2.dname; select e3.eno, e3.ename, e3.salary, d3.deptname, d3.address from employee e3, department d3 where e3.salary > 1500 and e3.deptno = d3.dno and d3.address = ‘Kaunas‘;

4. Dalinių rezultatų apdorojimas

Dekompozicijos proceso rezultatas – aibė sub-užklausų, kurias reikia optimizuoti ir įvykdyti. Optimizavimo algoritmas stengiasi maksimizuoti vykdomų procesų lygiagretumą kiek tai leidžia globalios užklausos struktūra, seka sub-užklausų apdorojimo eiliškumą.

Po sub-užklausų įvykdymo reikia apdoroti gautus iš lokalių DBVS rezultatus ir suformuluoti galutinį atsakymą. Rezultatų apjungimas vykdomas duomenis apjungiant, sujungiant, filtruojant ir panašiai, atmetant neteisingus duomenis, atsiradusius tarp rezultatų per klaidą. Galiausiai rezultatai yra nukreipiami į globalios užklausos projekcijų sąrašą.

Aukščiau minėto pavyzdžio rezultatų apdorojimas:

((R1 R2) R3)

kur Ri kreipiasi į rezultatą, gautą iš duomenų bazės i, ženklas reiškia bet kokią operaciją, o skliaustai nusako operacijų atlikimo eiliškumą.

– 38 –

Užklausų skaidymas ir apdorojimas multidimensinėse duomenų bazių sistemose

Sub-užklausa 1 Sub-užklausa 2 Sub-užklausa 3

DB1 Lokali DBVS1

DB1 Lokali DBVS1

DB1 Lokali DBVS1

R1 R2 R2R3

R1 Išorinis apjungimas (emp_id*-ssno)

Išorinis apjungimas (ssno*-eno)

R3

Išorinis apjungimas (enp_id*-eno)

3 pav. Sąryšiai

3 paveiksle pateiktoje schemoje matosi pavyzdyje nagrinėta schema. Pirmiausiai reikėtų sujungti R1 ir R2. Šios

sąjungos rezultatus galime pamatyti 4 lentelėje. Atliekant išorinio rezultatų apjungimo veiksmą gali atsitikti taip, kad kai kuriems atributams lokaliose duomenų bazėse nebus duomenų. Tokiu atveju atributui priskiriama reikšmė „N/A“.

1 lentelė. DB1 daliniai rezultatai

emp_id ename age salary dname 00123 02234 12397 23476

Petraitis Jonaitis Bartkus Girinis

25 23 24 40

1600 4000 1800 3000

moksl. komp. vadyb. komp.


ssno name salary dname location 00123 Petraitis 1600 moksl. Kaunas 02234 Jonaitis 4000 komp. Kaunas 45800 Gudas 4100 komp. Kaunas


eno name salary deptanie address

00123 Petraitis 1600 moksl. Kaunas

12397 Bartkus 1800 vadyb. Kaunas

4 lentelė. Tarpiniai rezultatai emp_id ename age salary dname ssno name salary dname location

00123 Petraitis 25 1600 moksl. 00123 Petraitis 1600 moksl. Kaunas

02234 Jonaitis 23 4000 komp. 02234 Jonaitis 4000 komp. Kaunas 12397 Bartkus 24 1800 vadyb. N/A N/A N/A N/A N/A 23476 Girinis 40 3000 komp. N/A N/A N/A N/A N/A N/A N/A N/A N/A komp 45800 Gudas 5000 komp Kaunas

– 39 –

M. Surdokas

5 lentelė. Antri tarpiniai rezultatai

emp_id Ename age salary dname ssno name salary dname location eno name salary deptname address 0123 Petraitis 25 1600 moksl. 00123 Petraitis 1600 moksl. Kaunas 00123 Petraitis 1600 moksl. Kaunas 02234 Jonaitis 23 4000 komp. 02234 Jonaitis 4000 komp. Kaunas N/A N/A N/A N/A N/A 12397 Bartkus 24 1800 vadyb. N/A N/A N/A N/A N/A 12397 Bartkus 1800 vadyb. Kaunas 23476 Girinis 40 3000 komp. N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A 45800 Gudas 4100 komp. Kaunas N/A N/A N/A N/A N/A

Toliau pagal 3 paveikslėlyje pavaizduotą schemą apjungiame R3 su ką tik gautais tarpiniais rezultatais, ir gauname antrus tarpinius rezultatus, atvaizduotus 5 lentelėje. Reikia pastebėti, kad įrašas “Girinis“ yra įtrauktas ir į 5 lentelę, neatsižvelgiant į tai, kad jis neturėtų būti tarp galutinių rezultatų. Taip atsitiko todėl, kad pirmoji DBVS neturėjo adreso atributo, ir negalėjo „Girinio“ pašalinti kaip netenkinančio užklausos. Tačiau yra būtina pasiųsti užklausą į DB1, nes ji vienintelė turi age atributą. Tokiu būdu tarp rezultatų gali pasitaikyti netinkamų įrašų. Kad išvengti tokių netikslumų galutiniai rezultatai turi būti dar kartą peržvelgiami ir pašalinami tie įrašai, kurių bent vienas atributas, esantis where predikate, turi reikšmę „N/A“.

Norint pašalinti tokius įrašus, globalios užklausos where predikate išvardinti atributai turi būti saugojami lokaliose duomenų bazių valdymo sistemose, taip pat sub-užklausų projekcijų sąrašuose. Pavyzdžiui, atributai išvardinti where predikate taip pat yra įterpti į sub-užklausų projekcijų sąrašus. Šiuo atveju įrašo „Girinis“ abiejų atributų location ir address reikšmės yra „N/A“, nepaisant to, kad abu išreiškia tą pačią informaciją kaip ir globalus atributas address. Todėl galiausiai įrašas „Girinis“ yra pašalinamas.

Pabaigoje būtina surašyti rezultatus į globalios užklausos projekcijų sąrašą. Rezultatų surašymo metu atributai – sinonimai, išreiškiantys tą pačią esybę, yra pašalinami iš rezultatų. Pavyzdžiui, ename, name ir ename semantiškai yra tas pats, todėl du iš jų pašalinami.

Galutiniai rezultatai atvaizduojami 6 lentelėje.

6 lentelė. Galutiniai rezultatai

name age dept_name Petraitis 25 moksl. Jonaitis 23 komp. Bartkus 24 vadyb. Gudas komp.

Literatūra [1] T.Topaloglou, A. Illarramandi, L. Sbattella, Query Optimization for KBMSs: Temporal, Syntactic and Semantic

Transformations, http://citeseer.nj.nec.com/topaloglou92query.html [2] J.A. Hylton, Identifying and Merging Related Bibliographic Records http://citeseer.nj.nec.com/37740.html [3] A.Levy, A.Rajaraman, J.Ordille, Querying Heterogeneous Information Sources Using Source Descriptions

http://citeseer.nj.nec.com/levy96querying.html

Query Decompocition and Processing in Multidimesional Database System

A multidatabase system allows its users to simultaneously access heterogeneous, and autonomous databases using an integrated schema and a single global query language. An important problem in multidatabase systems is processing of the global queries. In this paper, we describe a global query processing scheme.

– 40 –

http://citeseer.nj.nec.com/topaloglou92query.html

http://citeseer.nj.nec.com/37740.html

http://citeseer.nj.nec.com/levy96querying.html

VEIKLOS ŽINIŲ KAUPIMO POSISTEMIS

Sandra Budrevičienė, Audrius Lopata, Saulius Gudas Informacijos sistemų katedra, Kauno technologijos universitetas

Studentų 50-309, LT-3031 Kaunas

Straipsnyje aprašyti IS inžinerijai skirto veiklos modelio užpildymo konkrečios srities žiniomis technologijos pagrindiniai etapai. Pateikiami veiklos žinių kaupimo posistemio programinės įrangos vartotojo sąsajos pavyzdžiai, aptariamos šio programinės įrangos prototipo vystymo galimybės.

1. Įvadas

Informacijos sistemų inžinerijos gyvavimo ciklas pradedamas veiklos dalykinės srities analize, vartotojo poreikių analize ir informacinių poreikių specifikacijos sudarymu. Mūsų požiūriu veiklos analizės metu surinkta informacija turi būti sutvarkoma kaip žinių struktūra, leidžianti generuoti IS projektinius modelius (UCM, kaip vartotojo poreikių specifikaciją, klasių modelį ir kt.). Tokią žinių struktūrą vadinsime veiklos modeliu (angl. Enterprise model) [1,3,4,5]. Veiklos modelis detaliai nagrinėjamas [2]. Straipsnio tikslas yra apžvelgti veiklos modelio užpildymo konkrečios srities žiniomis pagrindinius etapus ir pateikti sukurtos programinės realizacijos aprašymą.

2. Veiklos modelio loginė DB schema

Veiklos modelio duomenų bazės loginę schemą sudaro penkiolika tarpusavyje susietų lentelių. Pagrindinės lentelės yra Procesas, Funkcija, PxF (proceso ir funkcijos sankirta), Vykdytojas, Mat_srautas, Inf_srautas.

Lentelėje Procesas saugomos žinios apie materialius dalykinėje veiklos srityje vykstančius procesus, o lentelėje Funkcija – žinios apie dalykinėje veiklos srityje vykstančias funkcijas. PxF saugo procesų ir funkcijų sąsajos informaciją, t.y. kokius procesus valdo konkreti funkcija. Lentelėje Vykdytojas saugoma informacija apie organizacinę struktūrą: procesų ir funkcijų vykdytojus t.y. padalinius, cechus ar asmenis. Lentelėse Mat_srautas ir Inf_srautas saugoma informacija apie materialius ir informacinius kompiuterizuojamos dalykinės srities srautus srautus. Procesai, procesų ir funkcijų sankirta, vykdytojai, materialūs ir informaciniai srautai gali turėti papildomus informacinius atributus. Jie saugomi atitinkamose lentelėse P_Atributai, PxF_Atributai, Vykdytojo_Atributai, Mat_Sraut_Atrib ir Inf_Sraut_Atrib. Materialaus ar informacinio srauto rūšis nurodoma Mat_Sraut_Rusis ir Inf_Sraut_Rusis lentelėse. Funkciją gali sudaryti daug veiklų, sudarančių veiklų hierarchija saugoma lentelėje Veikla, o veiklų tipai lentelėje V_Tipas.

3. Veiklos modelio užpildymo etapai

Dalykinės srities žinių surinkimo etape taikomi šešių tipų modifikuoti darbų sekų modeliai: veiklos procesų darbų sekų modelis (VP_WFM), procesų darbų sekų modelis (P_WFM), funkcijų darbų sekų modelis (F_WFM), procesų darbų sekų modelis be trūkio taškų, funkcijų darbų sekų modelis be trūkio taškų ir funkcijos sudėties darbų sekų modelis (FS_WFM). Šių modelių kūrimui ir žinių transformavimui į veiklos modelį taikomi penkių tipų algoritmai: informacijos perkėlimo algoritmas, procesų ir funkcijų darbų sekų modelių atskyrimo algoritmas, trūkio taškų šalinimo procesų darbų sekų modelyje algoritmas, trūkio taškų šalinimo funkcijų darbų sekų modelyje algoritmas, funkcijos sudėties nustatymo algoritmas ir žinių transformavimo į veiklos modelį algoritmas.

Pirmasis etapas – Informacijos perkėlimo algoritmas

Pirmasis darbo etapas susideda iš penkių žingsnių. Pirmuoju žingsniu paketu „ProVision Workbench v4.0.2 Enterprise Pro“ sudaromas grafinis darbų sekų modelis (G_WFM), specifikuojantis kompiuterizuojamą dalykinę veiklos sritį. VP_WFM skirtas nagrinėjamo veiklos proceso eigai aprašyti. Kai jau darbų sekų modelis - G_WFM -sudarytas, galime atlikti sekantį pirmojo etapo žingsnį tai yra - eksportavimą į „Microsoft Excel 2002“ paketą. Šis paketas naudojamas kaip tarpinis informacijos perkėlimui iš „ProVision Workbenchv 4.0“ į „Microsoft Visual

– 41 –

S. Budrevičienė, A. Lopata, S. Gudas

-P_Kodas : int-P_Pav : char-Vykd_Kodas : int-P_Eil_Nr : int

Procesas

-P_Kodas : int-P_Atrib_Kodas : int-P_Atrib_Pav : char

P_Atributai

1

*

-Mat_Sraut_Kodas : int-Mat_Sraut_Pav : char-P_Kodas : int-Mat_Sraut_Rus_Kodas : int

Mat_srautas 1*

-Mat_Sraut_Rus_Kodas : int-Mat_Sraut_Rus_Pav : char

Mat_Sraut_Rusis

1

*

-Mat_Sraut_Atrib_Kod : int-Mat_Sraut_Atrib_Pav : char-Mat_Sraut_Kodas : int

Mat_Sraut_Atrib

1

*

-Vykd_Kodas : int-Vykd_Pav : char

Vykdytojas

-Vykd_Kodas : int-Vykd_Atrib_Kodas : int-Vykd_Atrib_Pav : char

Vykdytojo_Atributai

1*

1

*

-PxF_Kodas : int-P_Kodas : int-F_Kodas : int-PxF_Pavad : char

PxF

1 *

-F_Kodas : int-F_Pavad : char-Eil_Nr : int-Vykd_Kodas : int

Funkcija

1*

1 *

-PxF_atrib_kodas : int-PxF_atrib_pav : char-PxF_kodas : int

PxF_Atributai

1

*

-F_Kodas : int-V_Kodas : int-V_Pav-V_Tip_Kodas

Veikla

1 *

-V_Tip_Kodas : int-V_Tip_Pav : char

V_Tipas

1

*

-V_Kodas : int-Inf_Sraut_Kodas : int-Inf_Sraut_Pav : char-Inf_Sraut_Rus_Kodas : int

Inf_Srautas

1*

-Inf_Sraut_Rus_Kodas : int-Inf_Sraut_Rus_Pav : char

Inf_Sraut_Rusis1

*

-Inf_Sraut_Kodas : int-Inf_Sraut_Atrib_Kodas : int-Inf_Sraut_Atrib_Pav : char

Inf_Sraut_Atrib

1

*

1 pav. Veiklos Modelio loginė duomenų bazės schema

1. Informacijos perkėlimo algoritmas

G_WFM

2. Procesų ir funkcijų darbų sekų modelių atskyrimoalgoritmas

VP_WFM

F_WFMP_WFM

3.1 Trūkio taškų šalinimo procesų darbųsekų modelyje algoritmas

4. Funkcijos sudėties nustatymo algoritmas

F_WFM be trūkio taškųP_WFM be trūkio taškų

FS_WFM

3.2 Trūkio taškų šalinimo funkcijųdarbų sekų modelyje algoritmas

2 pav. Informacijos tvarkymo algoritmas

FoxPro 7.0“. Šis paketas pasirinktas todėl, kad grafinio modeliavimo būdas leidžia informacijos eksportavimą į šį ir dar į keletą paketų. Apsispręsta pasirinkti „Microsoft Excel 2002“, nes būtent iš šio paketo įmanomas informacijos importavimas į „Microsoft Visual FoxPro 7.0“, kurio pagalba realizuojame VM valdymo informacinę sistemą. Taigi antru žingsniu atliekame - Informacijos eksportavimą iš G_WFM į „Microsoft Excel 2002“ darbo lapus. Atlikus minėtą žingsnį gautus “Microsoft Excel 2002” darbo lapus reikia pasiruošti sekantiems žingsniams t.y. trečiasis

– 42 –

Veiklos žinių kaupimo posistemis

pirmojo etapo žingsnis – „Microsoft Excel 2002“ darbo lapų tvarkymas (panaikiname juose esančius nereikalingus laukus). Šis žingsnis atliekamas todėl, kad dalis laukų minėtuose darbų lapuose yra visiškai tušti. Atlikus trečiąjį žingsnį galime vykdyti ketvirtą - Informacijos importavimą iš „Microsoft Excel 2002“ į „Microsoft Visual FoxPro 7.0“, nes visas darbas bus atliekamas būtent šiuo paketu. Importavus duomenis į „Microsoft Visual FoxPro 7.0“ DB, gauname dvi nepriklausomas DB lenteles, kuriose ir yra patalpinta visa reikiama informacija. Minėtu paketu taip pat vykdomas ir Informacijos perkėlimo algoritmas.

3 pav. Informacijos tvarkymo algoritmo pirmasis etapas - informacijos perkėlimo algoritmas

Antrasis etapas – Procesų ir funkcijų darbų sekų modelių atskyrimo algoritmas

Antruoju etapu VP_WFM esanti informacija yra išskiriama į dvi dalis: tai yra į P_WFM ir F_WFM . Šis etapas realizuojamas analizuojant VP_WFM veiklos procesų įeigos ir išeigos srautus. Jei veiklos proceso įeigos ir (arba) išeigos srautas yra materialus tai procesas, kartu su materialiais įeigos ir išeigos srautais P_WFM atvaizduojamas kaip materialus procesas, o jei įeigos ir (arba) išeigos srautas yra informacinis –veiklos procesas, kartu su juo susijusiais informaciniais srautais, F_WFM atvaizduojamas kaip informacinė veikla. Taip visi veiklos procesai yra suskirstomi į dvi grupes ir šis jų padalinimas realizuojamas „Microsoft Visual Studio 7.0“ pakete P_WFM ir F_WFM atskyrimo algoritmo pagalba.

Trečiasis etapas – Trūkio taškų šalinimo procesų ir funkcijų darbų sekų modelyje algoritmas

Išskyrus atitinkamus VP_WFM komponentus į P_WFM ir F_WFM reikia ištirti ar organizacijos veiklos modeliuose, sudarytuose pagal analizės metu surinktą (vartotojo pateiktą) informaciją, nėra trūkio taškų, t.y. ar pilnai aprašyta specifikuota kompiuterizuojamoji dalykinė sritis. Trūkio taškas- tai nuosekliai vykdomų procesų ar veiklų grandinės neegzistavimas, t.y. informacinių ar materialių srautų tarp procesų ar veiklų, būtinų informacijos ar materialių išteklių aprūpinimui trūkumas. P_WFM trūkio taškams šalinti taikomas procesų darbų sekų modelio trūkio taškų šalinimo algoritmas. F_WFM trūkio taškams šalinti taikomas funkcijų darbų sekų modelio trūkio taškų šalinimo algoritmas. Tai analogiški algoritmai, tik taikomi skirtingų tipų darbų sekų modeliams modeliams. P_WFM ir F_WFM trūkio taškų šalinimo algoritmų rezultatas- P_WFM be trūkio taškų ir F_WFM be trūkio taškų.

– 43 –

S. Budrevičienė, A. Lopata, S. Gudas

Ketvirtas etapas – Funkcijos sudėties nustatymo algoritmas

Šiame etape nustatoma funkcijų sudėtis. Pagal veiklos metamodelyje apibrėžtą funkcijos sudėtį egzistuoja trijų tipų veiklos – Interpretavimas, Informacijos apdorojimas ir sprendimų priėmimas (IP) ir Realizavimas, kurios nustatomos pagal veiklos įeigos ir išeigos srautus. Jeigu veiklos įeiga “Process Output”, o išeiga “IP Input”, pagal veiklos metamodelio struktūrą nustatoma, kad ši veikla yra funkcijos dalis - “Interpretavimas”. Jeigu veiklos įeiga yra “IP Input”, o išeiga “IP Output”, nustatoma, kad ši veikla yra funkcijos sudėtinė dalis “Informacijos apdorojimas ir sprendimų priėmimas” (IP). Jeigu veiklos įeiga yra “IP Output”, o išeiga “Process Input”, nustatoma, kad ši veikla yra funkcijos dalis - “Realizavimas”. Galimas variantas, kad negali būti nustatytas konkrečios veiklos tipas. Ši veikla turi vieno tipo veiklos įeigą ir kito tipo veiklos išeigą. Tokiu atveju, panaudojant egzistuojantį – funkcijos sudėties nustatymo algoritmą, surandama kokių tipų veiklų trūksta ir šios veiklos bei jų trūkstami ryšiai įvedami vartotojo.

3. Išvados

Naudojant “Provision WorkBench v. 4.0.2 Enterprise Pro“, “Microsoft Excel 2002” ir „Microsoft Visual Studio 7.0“ programinius paketus realizuoti informacijos perkėlimo bei procesų ir funkcijų darbų sekų modelių atskyrimo algoritmai. Sukurta veiklos modelio žinių tvarkybos informacinė sistema. Taip intelektualizuojant informacijos sistemos kūrimo procesą veiklos žinių pagrindu, gali būti sutaupomas IS projektavimo darbo laikas, gerinama sprendimų kokybė – veiklos modelio sukauptos jau patikrintos žinios apie probleminę sritį.

Literatūra [1] A. Lopata. Veiklos modelių sudėties analizė. “Informacinės Technologijos 2002”, Kaunas, 2002 psl. 377-381. [2] S.Gudas, T. Skersys, A. Lopata. Domain Knowledge Integration For Information Systems Engineering. “Informacinės

technologijos verslui 2002” Kaunas, Technologija 2002. psl.56-59. [3] A. Lopata, S. Gudas. Informacijos išteklių identifikavimas, veiklos modelio pagrindu. Informacijos mokslai, T19, Vilnius.

Vilniaus universiteto leidykla, 2001, p.43-50 . [4] E. Turban, E. McLean, J. Wetherbe. Information Technology for Management, John Wiley&Sons.Ins., 1999. [5] Kenneth C.Laudon, Jane P. Laudon Management Information Systems, Prentice-Hall, 2000.

– 44 –

VERSLO TAISYKLIŲ MODELIŲ TRANSFORMACIJA META-MODELIŲ PAGRINDU

Sergejus Sosunovas, Olegas Vasilecas Informacinių sistemų mokslo laboratorija, Vilniaus Gedimino Technikos Universitetas

Saulėtekio al. 11, Vilnius, Lietuvas, {sergejus,olegas}@isl.vtu.lt

OMG (angl. Object Management Group) pasiūlyta modeliais grindžiama architektūra (angl. Model Driven Architecture - MDA) šiuo metu yra aktyviai siūloma naudoti informacinių sistemų kūrimui. MDA naudojimas tai pat įgalina verslo sistemos modelių transformaciją į informacinės ir toliau į programų sistemos modelius. Nepaisant didelio šią temą publikacijų skaičiaus, verslo taisyklių (VT) modelių transformacija tarp skirtingo tipo sistemų, pavyzdžiui, tarp verslo ir informacinės sistemos, taip pat ir MDA kontekste beveik nėra nagrinėjama. Šiame darbe analizuojama VT, specifikuotų UML/OCL, kurios meta-modelis atitinka MOF (angl. Meta Object Facility) reikalavimus, transformacija į aktyviųjų duomenų bazių sistemų ECA tipo taisykles. Analizuojami transformacijai reikalingi meta-modeliai ir modelių transformacijos problemos.

1. Įvadas

Informacinių sistemų įgyvendinimo technologijos keičiasi labai greitai, didelėms kompanijoms yra sudėtinga pereiti nuo vienos technologijos prie kitos taip greitai, kaip to reikalauja rinka. Paprastai siekiant įgyvendinti pažangias technologijas būtina kurti naują sistemą. Tačiau greitai keičiantis technologijoms, dažnai, dar nesukurta sistema būna pasenusi. Bet verslo procesai, verslo taisyklės ir verslo aplinka, daugeliu atveju lieka nepasikeitę arba keičiasi nežymiai. Todėl ankščiau sukurti modeliai lieka, galima būtų juos naudoti, tačiau šie modeliai yra susiję su jau pasenusiomis technologijomis. Iš kitos pusės negalima kurti sistemos, nekuriant modelių, kurie būtų susiję su konkrečiomis informacinėmis technologijomis.

Modeliais pagrista architektūra (angl. model driven architecture MDA) [1], viena paskutiniųjų objektų valdymo grupės (angl. Object Management Group OMG) iniciatyvų, siūlo spręsti šią dilema naudojant trijų tipų modelius: nepriklausomą nuo skaičiavimų (angl. computation independent model CIM), nepriklausomą nuo platformos (angl. platform independent model PIM) ir priklausoma nuo platformos (angl. platform specific model PSM). Yra numatomą, kad CIM bus kuriami verslo ekspertų tam, kad aprašyti verslą, jame vykstančius procesus, verslo taisykles. Kuriamų sistemų architektūra aprašo naudojant PIM aprašo programinės įrangos architektai, projektuotojai. PSM savo ruožtu kuriamas programuotojo arba testuotojo, kad įgyvendinti tam tikrą sistemos architektūrą. OMG siūloma architektūra nėra nauja. Tai kitų autorių pasiūlytų teorinių schemų realizacija. Pavyzdžiui [2] siūlomas skirstymas į verslo, informacine ir programų sistemas tiesiogiai atvaizduojamas į CIP, PIM ir PSM (1 Pav.).

Nepriklausomas nuoskaičiavimų modelis

(CIM)

Nepriklausomas nuoplatformos modelis

(PIM)

Priklausomas nuoplatformos modelis

(PSM)

Programų sistemųkodas

CIM >> PIMtranformavimas

PIM >> PSMtransformavimas

PSMtransformavimas

į kodą

VersloSistema

Informacinėsistema

Programųsistema

1 pav. Verslo, informacinių ir programų sistemų sąryšis su MDA

– 45 –

S. Sosunovas, O. Vasilecas

MDA ribose vykstą modelių transformacija. Tam yra naudojami modelių meta-modeliai ir atitinkamos transformacijos kalbos. Tokių būdu pasikeitus verslui CIM yra transformuojami į PIM. Įvykus revoliuciniam technologijos pasikeitimui, paprastai kas dešimt metų, atliekamas atitinkamas PIM keitimas, ir tolimesnis pusiau automatinis transformavimas į PSM. Smulkus technologijų pasikeitimai neįtakoja PIM. Paprastai transformacijų specifikacijos yra pateikiami PSM tiekėjų, o specifiniai pakeitimai atliekami sistemos tvarkytojo. Taip PIM lygis yra apsaugomas nuo dažno technologijų pasikeitimo.

Transformacijos įmanomos tik tuo atveju jei abudu modeliai turi pagal vienodas taisykles specifikuotą meta-modelį, MDA šiuo atveju reikalauja naudoti meta objektų infrastruktūrą (angl. meta object facility MOF) [3]. MOF ir UML naudojimas MDA modeliams kurti yra visuotinai priimtas standartas, tačiau, deja šiuo metų dar nėra standarto reglamentuojančio transformacijos kalbą, leidžiančią transformuoti CIM, PIM, PSM tarpusavyje. OMG yra tik išleidęs pasiūlymų užklausimą (angl. request for proposals RfP)[4] kuriame yra keliami reikalavimai MOF transformavimo kalbai. Šio pasiūlymų pateikimo rezultatas bus transformavimo kalbos standartas specifikuojantis ne tik modelių transformavimą, bet ir modelių rodinių formavimo bei modelių sinchronizavimo taisykles.

Atsižvelgiant į standarto poreikį šiuo metu OMG yra pateikta virš 5 transformavimo kalbos pasiūlymų [5],[6],[7],[8],[9]. Transformavimo kalbos problemos yra vaisingai nagrinėjamos literatūroje ir to rezultatas yra sekančios modelių transformavimo kalbos: UMLX [10], BOTL [11], ATL [12]. Egzistuoja kaip atviro kodo MDA priemonės: Jamda[13], AndroMDA [14], taip ir komerciniai produktai: OptimalJ [15], XDE [16].

Šiame darbe nagrinėjamos verslo taisyklių transformacija tarp lygių. Verslo taisyklės specifikuodamos objektų ribojimų kalba (angl. Object Constraint Language OCL) [17],[18] kaip PIM lygio kalba. Toliau pateikiamas vieno tipo taisyklių transformavimo į PSM įvykis-sąlyga-veiksmas (angl. Event-Condition-Action ECA) taisykles, kurios gali būti realizuotos aktyviuose duomenų bazių valdymo sistemose. Transformacija yra specifikuojama naudojant supaprastintus OCL ir ECA meta-modelius, bei TRL[5] transformacijos kalbą.

2. Verslo taisyklių modeliavimas OCL kalba

Verslo taisyklės skirtos skirtingais būdais riboti verslą. Iš verslo sistemų nuleidžiant reikalavimus žemyn jie atsiranda informacinėse sistemos ir tokiu pat būdu programų sistemose, realizuotos kaip programų sistemų kodas.

Verslo sistemoje verslo taisyklė susideda iš trijų dalių: inkaro (angl. anchor), korespondentų (angl. correspondent), bei sąlygos. Inkaras suteikia jungimosi tašką, nuo kurio reikia pradėti interpretuoti taisyklę. Visos taisyklės savo sąlygose kreipiasi į modelio egzempliorius, jas vadina korespondentais [19]. Pagal [19] verslo sistemoje išskiriamos sekančios verslo taisyklių šeimos: egzempliorių tikrinimo (angl. instance verifiers), rūšies tikrinimo (angl. type verifiers), pozicijos tikrinimo (angl. position verifiers), funkcinio tikrinimo (angl. functional verifiers), palyginimo (angl. comparative evaluators), matematinio įvertinimo (angl. mathematical evaluators), projekcijos kontrolės (angl. projection controllers).

Kiekvienas iš aukščiau paminėtų taisyklių tipų gali būti tiesiogiai atvaizduotas į atitinkanti OCL loginį operatorių, arba jų derinį [20]. OCL kalba tapo UML specifikacijos dalimi nuo 1.1 versijos. Ši kalba buvo sukurta IBM korporacijos laboratorijose ir naudojama uždėti papildomus ribojimus objektiškai orientuotiems modeliams. Jos pagrindas – pirmos eilės predikatų logika. Sakiniai teksto pavidalu gali būti prikabinti prie UML klasės, arba klasės metodo.

OCL kalbos sakiniai negali egzistuoti be UML modelio, jų teisingumas gali būti tikrinamas tik atsižvelgiant į atitinkamą modelio realizacija. OCL sakinio struktūra:

Context <Klasifikatorius> inv: <RibojimoPavadinimas>: Sąlyga

Kiekvienas OCL ribojimas prasideda nurodant kontekstą (angl. Context), kuriame jis galioja. Kaip kontekstas gali būti naudojamas UML modelio klasifikatorius (pvz. klasės pavadinimas, atributas) arba klasifikatoriaus metodas. Priklausomai nuo ribojimo konteksto gali būti naudojama invariantas, raktinis žodis inv:, kai kontekstas klasifikatorius, arba prieš-sąlygos, raktinis žodis pre:, ir po-sąlygos, raktinis žodis post:, kai kontekstas klasifikatoriaus metodas. Ribojimas visada baigiasi sąlyga. Invarianto sąlygą turi tenkinti kiekvienas modelio egzempliorius. Kai ribojimas uždedamas UML klasės metodui prieš-sąlyga turi būti patenkinta prieš metodo vykdymą o po-sąlyga turi būti teisingą po metodo vykdymo pabaigos. Daugiau apie invariantų, prieš-sąlygų ir po-sąlygų semantinę ir sintaksinę prasmę yra [21],[22],[23].

3. Verslo taisyklių išreikštų OCL transformavimas

OCL sakiniai gali būti atvaizduotos aktyvioje duomenų bazėje kelias skirtingais budais: panaudojant tvirtinimo sakinius [24], naudojant rodinius [25]. Siekiant transformuoti OCL sakinius į ECA taisyklės, paprastai realizuojamas kaip trigeriai, būtina išspręsti sekančias problemas [26]:

• Įvykis kuris iššaukia trigerį;

– 46 –

Verslo taisyklių modelių transformacija meta-modelių pagrindu

• Trigerio inicijavimo dažnis (angl. granularity);

• Trigerio sąlyga;

• Trigerio suveikimo laikas;

Iš OCL specifikacijos aišku, kad OCL invarianto sakinis tūri būti tenkinamas bet kokio modelio egzemplioriaus. Siekiant patenkinti būtina šitą reikalavimą būtiną sekti kiekvieno OCL sąlygoje panaudoto atributo būklę. Tai reiškia, kad invarianto atveju trigeris tūri būti iššauktas įterpiant/keičiant/trinant kortežus kurių atributai yra panaudoti OCL sąlygoje.

Trigerio suveikimo laikas numato kada bus patikrinta sąlyga, prieš įvykdant trigerio įvykį ar po jo. Pagal [27] jei trigeris suveikia ir sąlyga yra įvertinama prieš iššaukusį įvykį veiksmą sąlyga neturi prieigos prie keičiamų duomenų. Tikrinti sąlyga ir prieš ir po yra ne efektyvu, todėl sąlyga tūri būti tikrinama po veiksmo atlikimo.

Įterpiant n įrašų iš eilės trigeris gali suveikti n arba 1 kartą, priklausomai nuo trigerio inicijavimo dažnio. Trigeriai gali turėti skirtingą inicijavimo dažnį; teiginio lygio, eilutės lygio. Įvertinant OCL sąlygą reikalingas eilutės lygio inicijavimo dažnis.

Pažeidus OCL sakino ribojimą ECA taisyklė turi atlikti tam tikrą veiksmą. Šiuo atveju sistema gali tiesiog pranešti apie ribojimo pažeidimą arba atšaukti ribojimo pažeidimą, toliau specifikuota transformacija įgyvendins antra variantą – transakcijos nutraukimą. Tai pat būtina atsižvelgti į įmanomus ribojimo pažeidimo atvejus transakcijos vykdymo metu, todėl visi ribojimai tūri būti įvertinami prieš transakcijos pabaiga, turi būti naudojamos taip vadinamos atidedami(angl. deferred) trigeriai.

Toliau paprastumo dėlei bus nagrinėjama verslo taisyklės priklausančios palyginimo šeimai. Šios verslo taisyklės vykdo palyginimą tarp panašių korespondentų tipų. Šitai šeimai priklauso sekantys taisyklių tipai: lygu (equal-to), ne lygu (not-equal-to), daugiau-kaip (greater-than), daugiau-kaip-arba-lygu (greater-than-or-equal-to), mažiau-negu (less-than), mažiau-negu-arba-lygu (less-than-or-equal-to).

Pavyzdžiui teiginys: „negalima parduoti tabako gaminių asmenims jaunesnėms negu 18 metu. Šia taisykle OCL kalba galima išreikšti sekančiai:

Context Klientas Inv AmziausRibojimas: Amzius >= 18

Name : StringCore::ModelElement

OclExpression

PropertyCallExp

ExpressionInOcl

ModelPropertyCallExp

OperationCallExpAttribteCallExpCore::Attribute

Core::Classifier

DataTypes::Expression

+contextualClassifier0..1

+appliedProperty 1

+Source

0..n

+referredAttribute* +parenOperation 1

+arguments

0..n {ordered}

2 pav. Supaprastintas OCL meta-modelis

Kad transformuoti tokio tipo verslo taisyklę pakanka supaprastinto OCL meta-modelio (2. Pav.). Sutinkamai su MDA reikalavimais pateikiamas ECA taisyklių supaprastintas meta-modelis (3. Pav., 4.Pav.). Šių meta-modelių

– 47 –


visos klasės yra tiesioginiu arba netiesioginiu būdų paveldėtos iš UML meta-modelio branduolio(angl Core) paketo klasės ModelElement, atitinkamai yra paveldimas atributas „vardas“ (angl. Name) Supaprastintas OCL meta-modelis yra OCL specifikacijoje pateikto meta-modelio dalis. Supaprastintas ECA meta-modelis iš dalis yra sintezuotas iš OCL meta-modelio, elementai „Table“ ir „Column“ yra klasės iš supaprastinto DBVS meta-modelio pateikto [5].

ECArule

Event

ConditionExp

Action

ErrorAction

Table

OperationCallExpColumnCallExp

Column

1

+Evet

1..n

1+Condition

1

1

+Action1..n

+Table

10..n

1

+AppliedAttribute0..n

0..n+referredColumn*

+parenOperation

1

+arguments0..n{ordered}

3 pav. Supaprastintas ECA taisyklės meta-modelis

-Name : StringCore::ModelElement

Action ColumnECArule Event ConditionExp Table

4 pav. Supaprastinto ECA taisyklės meta-modelio klasės

4. OCL-ECA transformacija 4.1. Transformacijos kalba

Transformacija formaliai specifikuoti yra naudojama viena iš kalbų pateiktų OMG kaip atsakymas į pasiūlymų užklausimą. Būtina pastebėti, kad bendrą visų transformavimo kalbu struktūra yra panaši. Kiekviena kalba turi priemones specifikuoti kokie meta-modeliai bus naudojami transformacijoje. Tai pat egzistuoja priemones specifikuoti transformavimo taisykles. Paprastai kiekviena taisyklė prasideda šablonu specifkuojančiu kokius meta-modelio elementus transformuoja ši taisyklė. Taisyklės kūnas specifikuota koks modelio šaltinio elementas tūri būti surištas su paskirties modelio elementu. Pagrindiniai transformavimo kalbų skirtumai pagal [28]: transformavimo taisyklių tipai (deklaratyvus, imperatyvus), taisyklių galimybės, šaltinio-paskirties modelių sąveika, taisyklių naudojimo strategijos, taisyklių organizavimas, kryptingumas.

TRL – transformavimo taisyklų kalba (angl. Transformation Rule Language)[5], kalba naudojama išreikšti modelių užklausas ir transformacijas sutinkamai su meta-modeliavimo principais apibrėžtais MOF 2.0. Ši kalba yra OCL 2.0 išplėtimas. Todėl dauguma operacijų tame tarpe ir navigacijos tarp modelių elementų yra paimtos iš OCL. Organizaciniu požiūriu TRL yra suskirstyta į modulius, moduliai į paketus. Galima išskirti tris modulių rūšis: užklausų, transformacijos ir rodinių.

QVT specifikacija taikoma modeliams, kurie yra apibrėžti meta-modelių terminais. TRL naudoja specialia sąvoka modelio tipas (angl. model type), kad nurodyti kokio meta-modelio ir kokios meta-klasės, savybės yra reikalingos. Pavyzdžiui: use modeltype UMLCore;. Naudojamas modelio tipas yra specialiai apibrėžiamas prieš transformaciją, naudojant TRL kalbos konstrukcijas.

Transformacijos moduliai naudojami specifikuoti modelis-modelis transformaciją. Šie moduliai gali vienyti būti kaip atitikimo pagristas (angl. compliance-based), deklaratyvias operacijas, taip ir procedūriniais (angl. operational

– 48 –

Verslo taisyklių modelių transformacija meta-modelių pagrindu

based). Paskutiniuoju atveju, transformacija apibrėžiama naudojant užklausos pagalbos operacijas ir atitikimo atvaizdavimo taisykles (angl. compliance mapping rules).

Transformacijos modulio viduje gali būti viena arba keletas aktyvatorių (angl. activator), tai yra specialios operacijos, kurios naudojamos kaip modulio įėjimo taškas. Aktyvatoriaus kūnas gali būti sudarytas iš vienos arba daugiau instrukcijos, kiekviena jų yra transformacijos žingsnis. Paprastai šis žingsnis naudoją modelį šaltinį, kad išrinkti modelio elementus ir paskui iškviesti vieną arba keletą taisyklių.

Kiekviena modelio elemento sukūrimo, atnaujinimo, arba sunaikinimo operacija tūri būti atlikta iššaukiant operacinę taisyklę. Taisyklės operacija yra skelbiama signatūra ir gali papildomai turėti kūną. Signatūra sudaryta iš skirtingų elementų: taisyklės tipo (create, update, delete, createupdate, createreceive), diskriminatoriaus, konteksto parametrų ir rezultato parametrų ir papildomo įvedimo parametrų.

rule <Žymė> taisyklėstipas [rezultato_parametrai][diskriminatorius] from [konteksto_parametrai] (papildomo_įvedimo-parametrai).

Taisyklės tipas apibrėžia kokį veiksmą modelio adresato atžvilgiu atliks taisyklė. Taip pavyzdžiui sukūrimo (angl. create) taisyklė gražiną modelio elementą kuris apibrėžtas kaip rezultato_parametras.

Transformacijos metu yra naudinga kreiptis į jau sukurtus modelio elementus. Operacinė taisyklė netiesiogiai saugo informacija apie tai koks paskirties modelio elementas buvo sukurtas iš modelio šaltinio elemento. Kad pasiekti šią informacija naudojamas operatorius resolve.

4.2. Formali transformacijos specifikacija

Ši formali OCL – ECA kalbų transformacija atliekama naudojant aukščiau aprašyta TRL transformacijų specifikavimo kalbą. Specifikacija išplečia UML-DBMS specifikacija atliktą [5]. Iš UML-DBMS transformacijos specifikacijos naudojami „Column“ ir „Table“ transformuoti elementai.

Transformacijos formali specifikacija remiantis aukščiau pateiktais meta-modeliais ir principais: transformation Ocl2ECA extends transformation Uml2rdbms; use modeltype SimplOCL, SimpleECA purpose create ecamodel:SimpleECA from oclmodel:Simple:OCL activator go() {oclmodel.objects() [ExpressionInOCL].create ECArule();} rule R1 create ECArule from ExpressionInOcl(){ name:=name; event:=ContextualClassifier.create Sequence(Event); condition:=bodyExpression.create Condition(); action:=self.create ErrorAction();} rule R2 create Sequence(Event) from ContextualClassifier(){ result:={self.create Event(“UPDATE”), self.create Event(“INSERT”)};} rule R3 create Event(n:String)from ContextualClassifier(){ name:= name+”_”+n; table:=self.resolve(Table);} rule R4 create ConditionExp() from bodyExpression(){ parentOperation:=parentOperation.create OperationCallExp(); appliedAttribute:=appliedProperty.create AttributeCallExp();} rule R5 create OperationCallExp() from parentOperation() inherits R4 {name:=”not ”+name;} rule R6 create AttribtueCallExp() from appliedProperty() inherits R4 {name:=self.resolve(Column);} rule R7 create ErrorAction() from ExpressionInOcl() {name:=”Violation of: ”+name;}

5. Išvados Šiame darbe sėkmingai atliktas UML/OCL išreikštų verslo taisyklių transformavimo į ECA tipo taisykles.

Pateiktas supaprastinta UML/OCL ir ECA meta-modeliai leidžia formaliai išreikšti transformacijos specifikacija. Palyginus su kitais transformacijos būdais pateiktas straipsnyje pasižymi didesniu abstrakcijos lygiu bei deklaratyvumu.

Pagrindinis tolimesnio darbo tikslas išplėsti meta-modelių specifikacija, taip įgalinant kitų taisyklių tipų transformacija į ECA taisykles. Specifikuoti programų sistemų kodo generavimą, šiuo atveju aktyvių duomenų bazių valdymo sistemų SQL kodo, iš ECA modelio.

– 49 –


– 50 –

Literatūros sąrašas [1] R. Soley, OMG. Model-Driven architecture. Prieinamas: http://www.omg.org. [2] A. Čaplinskas, A. Lupeikienė, O. Vasilecas. Shared Conceptualisation of Business Systems, Information Systems and

Supporting Software. Databases and Information Systems.II, Kluwer Academic Publishers, ISBN 1-4020-1038-9, 2002, psl. 109-120.

[3] OMG. OMG/MOF Meta Object Facility (MOF) Specification. Prieinamas: http://www.omg.org. [4] OMG. OM/RfP/QVT MOF 2.0 Query/Views/Transformations. 2002. Prieinamas: http://www.omg.org. [5] Alcatel, Softeam, Thales, TNI-Valiosys, Codagen Technologies Corp. Response to the MOF 2.0

Query/View/Transformations RFP (ad/2003-08-05). Prieinamas: http://www.omg.org. [6] QVTP-partners. MOF Query/Views/Transformations, Revised Submission. OMG dokumentas: ad/2003-08-08,

Prieinamas: http://www.omg.org. [7] CBOP, DSTC, IBM. MOF Query/Views/Transformations, Revised Submission. OMG dokumentas: ad/2003-08-03,

Prieinamas: http://www.omg.org. [8] Interactive Objects and Project Technologie. MOF Query/Views/Transformations, Revised Submission. OMG

dokumentas: ad/2003-08-11, Prieinamas: http://www.omg.org. [9] Compuware Corporation, Sun Microsystems. MOF Query/Views/Transformations, Revised Submission. OMG

dokumentas: ad/2003-08-07, Prieinamas: http://www.omg.org. [10] E.D. Willink. UMLX: A graphical transformation language for MDA. MDAFA2003 medžiaga, University of Twente,

2003, Prieinamas: http://trese.cs.utwente.nl/mdafa2003, psl. 13-24. [11] P. Brauna, F. Marschall. The Bi-directional Object-oriented Transformation Language. Techninė ataskaita.

Miuncheno techninis universitetas, TUM-I0307, 2003. [12] J. Bezivin, G.Dupe, F.Jouault, J.E. Raugui. First experiments with the ATL model transformation language.

Transforming XSLT into XQuery. OOPSLA’03 Workshop on Generative Techniques in the Context of the MDA medžiaga, 2003, Prieinamas: http://www.softmetaware.com/oopsla2003/mda-wokshop.html

[13] Jamda: The Java Model Driven Architecture 0.2. Projekto tinklapis, 2003, Prieinamas: http://sourceforge.net/projects/jamda.

[14] AdroMDA 2.0.3, Projekto tinklapis, 2003, Prieinamas: http://www.andromda.org. [15] Compuware. OptimalJ 3.0. Varotojo vadovas. Prieinamas: http://www.compuware.com/products/optimalj. [16] IBM. Rational XDE, Produkto tinklapis, Prieinamas: http://www.rational.com/products/xde. [17] J. Warmer ir A. Kleppe. The object constraint language. Precise modeling with UML. Addison Wesley Longman,

1999. [18] OMG. Response to the UML 2.0 OCL RfP (ad/2000-09-03). Revised Submission, Version 1.5 June 3, 2002.

Prieinamas: http://www.omg.org [19] R.G. Ross. The business rules book. Classifying, defining and modelling rules. Second Edition. Business rule

solutions, LLC, 1997. [20] S.Sosunovas, O.Vasilecas. Using UML/OCL for business rules modelling. Šeštosios Lietuvos jaunųjų mokslininkų

konferencijos „Lietuva be mokslo – Lietuva be ateities“ medžiaga, Technika, Vilnius, 2003, psl: 139-148. [21] R. Hennicker, H. Hussmann ir M. Bidoit. On the precise meaning of OCL constraints. LNCS 2263, Springer-Verlag

Berlin Heidelberg, 2002, psl. 69-84,. [22] T. Clark, A. Evans ir S. Kent. A Meta-model facility for a family of UML constraint languages. LNCS 2263,

Springer-Verlag Berlin Heidelberg, 2002, psl. 4-20. [23] M. Richters ir M. Gogolla. OCL: syntax, semantics and tools. LNCS 2263, Springer-Verlag Berlin Heidelberg, 2002,

psl. 42-68. [24] B. Demuth, H. Hussmann. Using OCL constraints for relational Database Design. LNCS 1723, Springer-Verlag

Berlin Heidelberg 1999, psl. 598-613. [25] B. Demuth, H. Hussmann, S. Loecher. OCL as a Specification Language for Business rules in Database Applications

Design. LNCS 2185, Springer-Verlag Berlin Heidelberg, 2001, psl. 104-117. [26] M. Badawy, K. Richta. Deriving triggers from UML/OCL specification. Kluwer Academic/Plenum Publishers,

Hardbound, 2003, psl.305-316. [27] K. Kline SQL in a Nutshell. O'Reilly & Associates, Sebastopol, CA. 2001. [28] K. Czarnecki, S. Helsen. Classification of Model Transformation Approaches. OOPSLA’03 Workshop on Generative

Techniques in the Context of the MDA medžiaga, 2003, Prieinamas: http://www.softmetaware.com/oopsla2003/mda-wokshop.html

The Meta-Model Based Transformation of Business Rules Models Model driven architecture is object management group’s new initiative in the information systems development.

The usage of MDA allows automatic transformation of the business models to the information system models and then in the software system models. Despite of the noticeable scientific attentions to the MDA, the problem of the transformation of business rules (BR) models between different MDA levels is not addressed yet. This paper analyses transformation of BR in UML/OCL, which meta-model conforms to the meta object facility (MOF) requirements, to the ECA rules of active database management systems. In this paper we present necessary transformation specification and meta-models.

http://www.omg.org/

http://www.omg.org/

http://www.omg.org/

http://www.omg.org/

http://trese.cs.utwente.nl/mdafa2003

http://www.compuware.com/products/optimalj

http://www.omg.org/