ISSN 1392 – 124X INFORMACINËS TECHNOLOGIJOS IR … · 2003. 1. 26. · Daiktai gali būti nedalomi arba sudėtiniai, t.y. sudaryti iš kitų, paprastesnių daiktų. Paprastesnieji

VI SEKCIJA INFORMACINIŲ SISTEMŲ PROJEKTAVIMO

METODAI IR TECHNOLOGIJOS

.

INFORMACINIŲ SISTEMŲ SPECIFIKAVIMO KALBŲ KOKYBĖS VERTINIMO PROBLEMA

Jelena Gasperovič, Albertas Čaplinskas Matematikos ir informatikos institutas, Akademijos 4, Vilnius

Straipsnyje nagrinėjama informacinių sistemų specifikavimo kalbų kokybės vertinimo problema. Aptariama spe-cifikavimo kalbos kokybės samprata, apžvelgiami skirtingi požiūriai, remiantis kuriais bandoma vertinti specifikavimo kalbų kokybę. Nagrinėjami metodai, grindžiami ontologine specifikavimo kalbos analize, ir metodai, naudojant ku-riuos specifikavimo kalbos kokybė yra vertinama ją išreiškiant atitinkamų kokybės atributų hierarchija. Palyginti nag-rinėjamų metodų trūkumai ir privalumai, parodyta, kad nei vienas iš jų kol kas nėra pakankamai ištobulintas, kad juo būtų galima pasinaudoti praktikoje, parenkant specifikavimo kalbą konkrečiam projektui.

1. Įvadas

Informacinių sistemų inžinieriai šiandien gali naudotis visu informacinėms sistemoms kurti skirtų priemonių arsenalu. Tai ir įvairios specifikavimo bei projektavimo kalbos, ir dalykinės srities analizės bei sistemų projektavimo metodai, ir sistemų įgyvendinimo technologijos, ir įvairios tikslinės paskirties instrumentinės priemonės (paketai reikalavimų bazėms tvarkyti, projektavimo paketai, specializuoti tekstų redagavimo paketai ir pan.). Šis arsenalas nuolat yra plečiamas. Pažymėtina, kad informacinių sistemų kūrimo priemonės dažnai dubliuoja viena kitos funkcionalumą. Vienok, tą patį arba panašų funkcionalumą turinčios priemonės gali būti labai skirtingos kitais po-žiūriais. Todėl informacinių sistemų inžinierius kiekvieną kartą susiduria su konkrečiam projektui geriausiai tinkan-čių priemonių, taip pat ir specifikavimo kalbos parinkimo problema. Parinkti konkrečiai informacinei sistemai specifikuoti geriausiai tinkančią specifikavimo kalbą nėra paprasta. Viena vertus, kalba turi turėti raiškos gebą, pakankamą visiems kuriamosios sistemos aspektams specifikuoti. Kita vertus, ji turi būti kuo paprastesnė, patiki-mesnė ir tenkinti daugelį kitų reikalavimų, išplaukiančių iš konkretaus projekto pobūdžio. Kitaip tariant, pasirenkant informacinės sistemos specifikavimo kalbą, tenka spręsti daugiakriterinio optimizavimo uždavinį. Nepaisant to, kad sistemų kūrimo praktikoje šis uždavinys yra sprendžiamas jau daugelį metų, jis vis dar nėra pakankamai tiksliai suformuluotas. Kol kas nesuformuluoti ir objektyvūs specifikavimo kalbų vertinimo bei lyginimo kriterijai. Šio straipsnio tikslas apžvelgti mokslinėje literatūroje pasiūlytus lyginamosios analizės metodus, tinkamus specifika-vimo kalboms palyginti bei vertinti, ir išanalizuoti jų privalumus bei trūkumus.

2. Specifikavimo kalbos parinkimas konkrečiam projektui

Specifikacija – tai aprašas, nusakantis kokio nors objekto, proceso ar kokio nors kito fenomeno savybes. Spe-cifikacija apibūdina arba patį fenomeną, arba to fenomeno veikimą (elgseną). Inžineriniame kontekste specifikacija priešpastatoma realizacijai, apibūdinančiai fenomeno įgyvendinimo būdą. Informacinės sistemos reikalavimų specifikacija yra dokumentas, aprašantis informacinės sistemos atliekamas funkcijas, jos produktyvumą, interfeisų pobūdį ir kitas pageidautinas kuriamosios informacinės sistemos savybes. Nors reikalavimus galima formuluoti ir natūraliosiomis kalbomis, dėl daugelio priežasčių paprastai yra vartojamos specialiai tam tikslui sukurtos kalbos, vadinamosios specifikavimo kalbos. Specifikavimas natūraliųjų kalbų priemonėmis šiame straipsnyje nenagri-nėjamas.

Paprastai specifikavimo kalbos yra skirstomos į formaliąsias ir formalizuotas. Formaliosiomis vadinamos kal-bos, turinčios formaliai apibrėžtus žodyną, sintaksę ir semantiką. Formalizuotosios specifikavimo kalbos yra mažiau griežtos, joms formaliai yra apibrėžiami tik žodynas ir sintaksė. Svarbiausias formaliųjų kalbų pranašumas – galimybė panaudoti formalius specifikacijų analizės metodus. Kitaip tariant, formaliąja kalba parašytos specifi-kacijos neprieštaringumą, išsamumą ir kai kurias kitas savybes bent jau teoriškai galima patikrinti formaliai. Kita vertus, formaliosios specifikavimo kalbos turi nemaža trūkumų, pavyzdžiui, tokiomis kalbomis parašytos specifika-cijos esti gremėzdiškos ir sunkiai suvokiamos. Bandant suderinti formaliųjų ir formalizuotojų kalbų privalumus, pastaraisiais metais pasiūlyta [10], [11], [12] tarpinė kalbų grupė, iš dalies formaliosios specifikavimo kalbos. Pagrindinė iš dalies formaliųjų specifikavimo kalbų idėja – dalinis specifikavimas. Kitaip tariant, rašant specifika-cijas tokiomis kalbomis formaliai yra aprašomi tik kai kurie specifikuojamosios sistemos aspektai. Kiti aspektai

VI – 1

J.Gasperovič, A.Čaplinskas

aprašomi tik formalizuotai. Taigi, dalinė specifikacija išsamiai aprašo kuriamąją sistemą tik tam tikru požiūriu. Kitais požiūriais sistema aprašoma neišsamiai. Jei tuos požiūrius taip pat norima specifikuoti išsamiai, jiems reikia rašyti atskiras specifikacijas.

Atliekant specifikavimo kalbos parinkimą konkrečiam projektui, visų pirma reikia nuspręsti, kokio tipo spe-cifikavimo kalbą – formalizuotą, iš dalies formalią, ar formalią – tikslinga pasirinkti. Taigi, analizuoti ir vertinti reikia ne tik kalbas, bet ir jų kategorijas. Kiek mums žinoma, išsami formaliųjų, iš dalies formaliųjų ir forma-lizuotojų specifikavimo kalbų lyginamoji analizė atlikta nebuvo. Buvo bandyta tarpusavyje palyginti tik tipinius šių kategorijų egzempliorius [11]. Palyginti tarpusavyje ne tik konkrečias šių kategorijų kalbas, bet ir pačias kategorijas yra labai sudėtinga nes, viena vertus, įvedus iš dalies formaliąsias kalbas, ir kita vertus, formalizuotosioms kalboms pamažu evoliucionuojant formaliųjų kalbų link ir vis formaliau ir formaliau apibrėžiant formalizuotųjų kalbų seman-tiką, ribos tarp tų kategorijų išblanko, šiuo metu jos iš dalies persidengia.

3. Bunge ontologija grindžiami specifikavimo kalbų vertinimo metodai

Pirmosios specifikavimo kalbos buvo sukurtos praeito amžiaus penktojo dešimtmečio pabaigoje. 1979 m. jau buvo vartojama apie 150 skirtingų specifikavimo kalbų [15]. Kiek mums yra žinoma, pirmą kartą, palyginti specifikavimo kalbas bandyta jau 1977 m. [23]. Autoriai suskirstė formalizuotas grafines specifikavimo kalbas į dvi grupes: kalbas, grindžiamas duomenų srautų ideologija, ir kalbas, grindžiamas duomenų struktūrų ideologija. Kitaip tariant, už pagrindą imtos ontologinės prielaidos apie socialinės realybės pobūdį. Pirmuoju atveju socialinė realybė konceptualizuojama, naudojant duomenų saugyklos, duomenų srauto ir duomenų srautą transformuojančio proceso kategorijas, antruoju – duomenų struktūros ir tą struktūrą kuriančio proceso kategorijas arba, tiksliau, vadovaujantis duomenų ir programų dualumo principu. Taigi, jau pačiame pirmajame specifikavimo kalbų lyginamajai analizei skirtame darbe išryškėjo esminė problema: kaip palyginti tarpusavyje specifikavimo kalbas, kurios yra grindžiamos skirtingomis socialinės realybės konceptualizavimo nuostatomis arba, kitaip tariant, visiškai skirtingai suvokia, kas tai yra socialinė realybė, kurią bandoma modeliuoti, specifikuojant informacinę sistemą.

Klausimas, kaip geriau konceptualizuoti socialinę tikrovę yra labai svarbus. Čia galima vadovautis įvairiais kriterijais: konceptualizacijos skaidrumu (kiek intelektualinių pastangų reikia specifikacijai suvokti), kategorijų sis-temos raiškos galia (ar visus socialinės realybės aspektus galima specifikuoti), kategorijų sistemos semantine galia (kokio dydžio specifikaciją gauname), kategorijų sistemos selektyvine geba (kokiu detalumu galima išskirti specifikuojamus objektus) ir kt. Kadangi kai kurie kriterijai yra prieštaringi, viskas priklauso nuo to, kokius priori-tetus teikiame vienam ar kitam kriterijui konkrečiu atveju. Vienok, galima bandyti įvertinti kiek geras ar blogas yra kiekvienas konceptualizavimo būdas kiekvieno kriterijaus požiūriu. Tai bandoma daryti, pavyzdžiui, darbe [11], konstruojant reprezentatyvų socialinės realybės fragmentą, ir konceptualizuojant jį skirtingais būdais. Nors šitoks lyginamosios analizės metodas iš pirmo žvilgsnio ir atrodo pagrįstas (grindžiamas kontroliuojamo eksperimento metodika), jį vis dėl to negalima pripažinti objektyviu, nes socialinės realybės fragmentas yra sukonstruotas vado-vaujantis subjektyviais kriterijais.

Subjektyvumą bandyta pašalinti, įvedant tam tikrą standartą. Dar 1977 metais filosofas Mario Bunge pasiūlė [1] ontologiją, kuri kai kurių autorių nuomone gali būti panaudota kaip “standartinė” (normatyvinė) ontologija. Kitaip tariant, siūloma specifikavimo kalbas vertinti būtent per šios ontologijos prizmę.

Pagrindinė Bunge idėja yra prielaida, kad socialinę tikrovę galima konceptualizuoti, naudojant “daikto” kate-goriją. Kitaip tariant, Bunge ontologijos požiūriu, pasaulis yra sudarytas iš daiktų. Daikto samprata grindžiama Aristotelio substancijos koncepcija. Sutinkamai su šia koncepcija, daiktai yra materialūs, egzistuojantys nepriklau-somai nuo stebėtojo ir išsaugantys savo tapastis vykstant jų pokyčiams. Daiktai gali būti nedalomi arba sudėtiniai, t.y. sudaryti iš kitų, paprastesnių daiktų. Paprastesnieji daiktai vadinami sudėtinio daikto komponentais. Bet kuris daiktas turi tam tikras savybes. Įvykiai, vykstantys arba su daiktu, arba jo viduje, traktuojami kaip to daikto savybės. Taip pat yra traktuojami ir dėsniai, nusakantys leistinus daiktų būsenos pokyčius. Apskritai, daiktų savybės yra skirstomas į keturias grupes: esmines savybes (angl. intrinsic properties), ryšio savybes (angl. mutual properties), iš-ryškėjančias savybes (angl. emergent properties) ir paveldėtąsias savybes (angl. hereditary properties). Esminių savybių grupei priskiriamos individualių daiktų charakteringosios savybės, ryšio savybių grupei – dviems arba daugiau daiktų būdingos savybės (sąryšiai, priklausomybės ir pan.), išryškėjančių savybių grupei – sudėtinių daiktų savybės, kurios nėra būdingos nei vienam komponentui, paveldėtų savybių grupei – sudėtinių daiktų savybės, kurias jie paveldi iš savo komponentų. Daikto savybių visuma duotuoju laiko momentu vadinama jo būsena. Klasė apibrė-žiama kaip vienodas savybes turinčių daiktų rinkinys.

Bunge ontologijoje daiktai yra konkretūs objektai. Svarbiausioji bet kurio daikto savybė yra jo egzistavimas. Egzistuodamas daiktas visuomet yra sąveikoje su kitais jį supančiais daiktais. Taigi, daiktai turi ne tik struktūrą, bet ir aplinką. Aplinką sudaro tie daiktai, su kuriais nagrinėjamasis daiktas yra sąveikoje. Jokių daiktų, taip pat ir sistemų, negalima analizuoti, ignoruojant jų aplinką. Daikto sąryšiai su aplinka sudaro jo išorinę struktūrą. Pri-minsime, kad sąryšiai priskiriami daikto ryšio savybių grupei. Taigi, vidinę daikto struktūrą sudaro jo esminės savybės, išorinę – jo ryšio savybės. Sąryšiai gali būti jungiantieji (angl. bonding relations) arba nejungiantieji (angl.

VI – 2

Informacinių sistemų specifikavimo kalbų kokybės vertinimo problema

non-bonding relations). Jungiantieji sąryšiai (jungtys) daro poveikį susietų daiktų būsenoms, nejungiantieji sąryšiai (nuorodos) – jokio poveikio jų būsenoms neturi. Jie sieja daiktus su atskaitos sistemomis. Pavyzdžiui, erdvės ir laiko sąryšiai yra nesusiejantieji sąryšiai. Erdvės sąryšiai Bunge ontologijoje traktuojami kaip daiktų ryšio savybės. Erdvė suprantama kaip erdvės sąryšiais susietų daiktų visuma. Kitaip tariant, kalbant apie erdvę, daroma nuoroda į ją sudarančius daiktus, erdvė nusako tų daiktų erdvines savybes. Šitokia erdvės samprata yra pakankamai konstruktyvi, bet silpnai suderinama su kasdienine erdvės kaip tam tikromis ribomis apriboto abstraktaus objekto samprata. Kasdieniniame gyvenime erdvės kategorija apibrėžia tai, kame egzistuoja daiktai ir vyksta įvykiai. Pagal Bunge, bet kuris daiktų rinkinys, pavyzdžiui, žvaigždžių konsteliacija arba medžių alėja, gali būti traktuojamas kaip erdvė.

Sistema apibrėžiama kaip “sudėtinis daiktas, kurio sudėtinės dalys yra susietos tarpusavyje vienos ar kelių tipų jungtimis (angl. bonds)”. Jei sudėtinės dalys yra susietos ne jungtimis, o kitokiais sąryšiais, tai turime ne sistemą, bet agregatą. Ontologija apibrėžia dvi su sistemomis siejamų problemų klases – analizę ir sintezę. Analizės problema yra, turint sistemą, t.y. žinant jos kompoziciją, aplinką ir struktūrą, nustatyti jos elgseną. Priminsime, kad sistemos struktūra užduodama visų sistemos ryšių (vidinių ir išorinių) visuma, kompoziciją sudaro daiktai, iš kurių yra sudaryta sistema, aplinką - daiktai, su kuriais nagrinėjamasis daiktas yra sąveikoje Sintezės problema yra atvirkštinė, t.y. žinant sistemos elgseną, reikia nustatyti, kokia sistema gali ją generuoti. Kitaip tariant, sintezė su-prantama kaip sistemos tenkinančios duotąją reikalavimų specifikaciją projektavimas, o analizė – kaip supro-jektuotos sistemos vertinimas. Iš sintezės sampratos seka svarbi išvada, kad daikto savybes ir patį daiktą galima specifikuoti atskirai. Savybės nusakomos reikalavimų specifikacija, pats daiktas – projektine specifikacija. Kadangi Bunge ontologijoje daiktai suvokiami kaip materialūs objektai turintys materialias savybes, tai daiktų ir savybių atskyrimas turi dar ir kitą prasmę: keisdami daiktą, priskirdami jam naujas savybes, mes neprarandame jo tapasties. Pavyzdžiui, reikalavimų specifikacija yra transformuojama į projektinę, pastaroji – į veikiančią sistemą, bet visais trim atvejais mes turime tą patį daiktą (tą pačią sistemą).

Matome, kad Bunge ontologijoje daiktai ir savybės yra fundamentinės kategorijos, o klasės ir sistemos – išvestinės.

Bunge ontologija priklauso vadinamųjų integralinio pliuralizmo (angl. integrated pluralism) ontologijų grupei [13]. Kitaip tariant, ji skelbia socialinės realybės įvairovę ir vienovę tuo pat metu. Sutinkamai su Bunge tezėmis, socialinė realybė yra daugiasluoksnė struktūra, tokia, kad:

• bet kuris socialinės realybės objektas (daiktas) priklauso bent vienam sluoksniui; • evoliucijos eigoje atsiranda nauji sluoksniai, tam tikros naujos savybės (taip pat ir nauji dėsniai) ir tam

tikros savybės yra prarandamos; • visi nauji sluoksniai yra siejami su senaisiais kaip besitęsiančios egzistencijos, taip ir jų atsiradimo

prasme; • kiekvienas sluoksnis yra stabilus ir autonomiškas, jei jį nagrinėti tik jo pačio ribose; • bet kuris įvykis yra nusakomas dėsniais, charakterizuojančiais sluoksnį, kuriam jis priklauso, ir

gretimus sluoksnius. Iš čia seka Bunge epistomologija. Sutinkamai su ja socialinė realybė yra pažini ir žinios apie ją gali būti skirs-

tomos į atitinkamus sluoksnius. Kiekvienas naujas socialinę tikrovę nagrinėjantis mokslas turi savo specifinius tyrimo objektus ir specifinius tyrimo metodus. Tačiau jis išsaugo ir tam tikras mokslo, iš kurio jis kilo, idėjas. Giles-nis bet kurio sluoksnio suvokimas negalimas, nenagrinėjant gretimų sluoksnių. Kiekvienas socialinę tikrovę nagrinė-jantis mokslas, vidiniu požiūriu, yra tam tikru mastu savarankiškas ir stabilus. Bet kuri sistema ir bet kuris įvykis gali būti aprašyti, paaiškinti ir prognozuojami, visų pirma jo ir gretimų sluoksnių terminais, visiškai nebūtinai nagrinėjant visą daugiasluoksnę struktūrą. Ši epistomologija yra labai svarbi konstruojant socialinės realybės anali-zės metodikas, taip pat ir tas, kurios naudojamos kuriant informacines sistemas.

Bunge ontologija ir epistomologija plačiai naudojamos įvairiose mokslo šakose, taip pat ir informatikoje. Pavyzdžiui, UML kalba yra grindžiama Bunge ontologija. Taikant Bunge ontologiją informacinėms sistemoms, daromos prielaidos, kad informacinė sistema traktuotina kaip socialinės realybės modelis, konstruojamasi vadovau-jantis tam tikra metafizine socialinės realybės teorija, šiuo atveju, Bunge ontologija. Darbuose [30], [31], [32], [33], [34], [35], [36], [5] buvo pasiūlyta kaip pritaikyti Bunge ontologiją informacinių sistemų specifikavimo kalboms bei jomis parašytoms specifikacijoms vertinti. Šie pasiūlymai vadinami Bunge, Wand ir Weber (BWW) modelių sistema1. BWW modelių sistema yra sudaryta iš trijų modelių: vaizdavimo (angl. representation), būsenų perėjimų (angl. state-tracking) ir geros dekompozicijos (angl. good decomposition).

Būsenų perėjimo ir geros dekompozicijos modelių paskirtis – apibūdinti informacinių sistemų specifikacijas. Būsenų perėjimo modelis nustato būtinas ir pakankamas sąlygas, kurias turi tenkinti specifikacija tam, kad ji atitiktų modeliuojamąją socialinę tikrovę. Geros dekompozicijos modelis nustato, kaip geriau perteikti organizacijos

1 BWW terminais specifikavimo kalbos vadinamos modeliavimo gramatikomis (angl. modelling grammars), o tomis

kalbomis parašytos specifikacijos – scenarijais (angl. scripts).

VI – 3


socialinės realybės, tiksliau, ten vykstančio verslo, esmę vartotojui. Daroma prielaida, kad tam tikras savybes turinčios specifikacijos verslo esmę vartotojui perteikia geriau.

Vaizdavimo modelis sukonstruotas kaip konceptualizacija, kuria reikia vadovautis, vertinant specifikavimo kalbų ontologinį išsamumą (angl. ontological completeness) ir ontologinę skaidrą (angl. ontological clarity). Ontologinis išsamumas yra apibrėžiamas kaip galimybė specifikavimo kalba ir su ja siejamos samprotavimų sistemos priemonėmis aprašyti visus socialinės realybės fenomenus pakankamu detalumu. Kitaip tariant, ontologinis išsamumas nusako ir specifikavimo kalbos raiškos gebą, ir jos selektyvinę gebą. Sutinkamai su šiuo požiūriu, pavyzdžiui, esybių ryšių diagramų kalba nėra ontologiškai išsami [5], nes vien tik šios kalbos priemonėmis visų socialinės realybės aspektų pakankamu detalumu specifikuoti neįmanoma. Ontologinė skaidra suprantama kaip laipsnis, kuriuo specifikavimo kalbai konceptualizuoti vartojamos kategorijos atitinka vaizdavimo modelio kategorijų sistemai arba, kitaip tariant, Bunge ontologijai. Išsamiau BWW vaizdavimo modelio ontologiniai pagrindai aprašyti darbuose [29], [28], [6].

BWW vaizdavimo modelis buvo panaudotas daugelio specifikavimo kalbų ontologiniam išsamumui ir onto-loginei skaidrai vertinti [6], [7], [8], [24], [25], [37], [14], [31], [36], [28], [22], [29]. Pagrindinis vertinimo kriterijus grindžiamas prielada, kad specifikavimo kalba turi būti galima specifikuoti visus socialinės realybės daiktus, kurie galėtų dominti informacinės sistemos vartotojus. Kitaip specifikavimo kalba pripažįstama ontologiškai neišsamia. Kalbos ontologinis išsamumas vertinamas, lyginant BWW vaizdavimo modelio konstrukcijas su tos kalbos konst-rukcijomis. Reikalaujama, kad kiekvieną BWW vaizdavimo modelio konstrukciją atitiktų bent viena vertinamos kalbos konstrukcija. Jeigu tokio atitikmens rasti nepavyksta, specifikavimo kalba laikoma ontologiškai neišsamia. Kalbos ontologinė skaidra laikoma pažeista, jei yra nustatoma, kad:

• kelias skirtingas BWW vaizdavimo modelio konstrukcijas atitinka ta pati vertinamos specifikavimo kalbos konstrukcija (tai vadinama konstrukcijos perkrova, angl. construct overload),

• vieną BWW vaizdavimo modelio konstrukciją atitinka kelios skirtingos vertinamos specifikavimo kalbos konstrukcijos (tai vadinama kalbos pertekliškumu, angl. construct redundancy),

• vertinamos specifikavimo kalbos konstrukcija BWW vaizdavimo modelyje atitikmenų neturi (tai vadinama kalbos perdėtumu, angl. construct excess).

Metodiniu požiūriu, ontologinė analizė atliekama sugretinant BWW vaizdavimo modelio konstrukcijas su ver-tinamos specifikavimo kalbos konstrukcijomis. Kitaip tariant, naudojamas palyginimo su norma metodas. BWW modelis paskelbiamas norma, visos kitos specifikavimo kalbos vertinamos, lyginant, kiek jos tenkina tą normą. Taigi, vadovaujantis šitokia kalbų vertinimo metodika, reikalaujama pripažinti, kad BWW vaizdavimo modelio ontologija konceptualizuoja visus socialinės realybės aspektus ir kad ši ontologija sukonstruota taip, jog ji yra “natūraliausia” (skaidri) bet kuriam vartotojui, nepriklausomai nuo jo subjektyvaus mąstymo, sąlygoto jo profesijos, interesų ir gimtosios kalbos. Tai fundamentalus reikalavimas. Darbuose [30], [31], [32], [33], [34], [35], [36], [5] pateiktų argumentų šiam reikalavimui pagrįsti nepakanka [2]. Tą pastebėjo ir kiti autoriai [6], [7]. Jų darbuose išreikštos abejonės, ar BWW vaizdavimo modelio ontologija nėra perkrauta kai kuriomis bereikalingomis konstruk-cijomis, nes atitikmenų šioms konstrukcijoms nebuvo rasta nei vienoje iš analizuotų specifikavimo kalbų. Be to, kai kurios specifikavimo kalbos yra specializuotos ir naudojamos tik kai kuriems informacinių sistemų aspektams specifikuoti. Praktikoje jos yra kombinuojamos su kitomis specifikavimo kalbomis ir visa informacinė sistema yra specifikuojama, vartojant kelių kalbų rinkinį. Rinkinys yra sudaromas vadovaujantis principu, kad į jį įeinančios specifikavimo kalbos ontologiniu požiūriu persidengtų kuo mažesniu laipsniu [37]. Reikalauti, kad visos į rinkinį įeinančios kalbos būtų ontologiškai išsamios, yra neprasminga. Kita vertus, kai kurių aiškiai reikalingų konstrukcijų BWW vaizdavimo modelio ontologijoje nėra, pavyzdžiui, ten pasigendama verslo tikslų, verslo strategijos ir kai kurių kitų verslui modeliuoti būtinų konstrukcijų [6].

Kitas esminis siūlomo metodo trūkumas yra tas, kad specifikavimo kalbos kokybė yra vertinama tik dviejų savybių – ontologinio išsamumo ir ontologinės skaidros – požiūriu. Daroma prielaida, kad tik ontologiniai socialinės realybės aspektai (jie vadinami giluminiais, angl. deep structures) yra esminiai, specifikuojant informacines sistemas. Visi kiti aspektai laikomi neesminiais, techniniais (jie vadinami paviršiniais, angl. surface structures) ir daroma prielaida, kad jų specifikuoti nereikia, nes pakankamai ištobulintos intelektualizuotos instrumentinės sistemos pačios gali nuspręsti, kokias technines savybes turėtų turėti kuriamoji informacinė sistema. Deja, ši prielaida yra nereali [2].

Vienas iš pasiūlymų, kaip išplėsti BWW vaizdavimo modelio kategorijų sistemą, pateiktas darbe [21]. Siekta įvesti priemones specifikuoti subjektyvius socialinės realybės vertinimus, nes informacines sistemas skirtingi žmonės vertina subjektyviai, per savo asmeninės patirties ir savo interesų prizmę. Darbe pasiūlyta įvesti dvi naujas kategorijas – perspektyvą ir koncepciją. Perspektyva - tai nuo konteksto ir laiko momento priklausantis vartotojo požiūris į analizuojamą socialinę tikrovę. Kitaip tariant, tai tam tikra socialinės realybės interpretacija. Kadangi pagal Bunge ontologiją socialinę tikrovę sudaro tam tikras savybes turintys daiktai, tai perspektyvą galima sukurti tik arba matant ne visus socialinės realybės daiktus, arba matant ne visas tų daiktų savybes. Kadangi klasė yra apibrėžiama kaip tam tikras savybes turinčių daiktų aibė, o perspektyva apima tik tam tikrą savybių poaibį, tai iš čia

VI – 4


seka, kad tas pats daiktas stebimas iš skirtingų perspektyvų priklauso skirtingoms klasėms. Todėl perspektyva yra nusakoma vadinamųjų koncepcijų rinkiniu. Koncepcija – tai daikto traktuotė tam tikros perspektyvos požiūriu, paveldinti iš tos perspektyvos stebimų tam tikrą to daikto savybių poaibį. Kitaip tariant, stebint daiktą tam tikra perspektyva yra matomas ne pats daiktas, o tik tam tikra jo koncepcija. Kadangi pagal skirtingas koncepcijas tas pats daiktas turi skirtingas savybes, o ryšio savybės nusako daiktų priklausomybes ir sąryšius, tai skirtingos to pačio daikto koncepcijos nusako ir skirtingus to pačio daikto priklausomybes bei sąryšius. Taigi, stebint socialinę tikrovę iš skirtingų perspektyvų, joje galima įžvelgti skirtingus verslo aspektus. Taigi, darbe [21] pateikti pasiūlymai yra grindžiami radikaliojo konstruktyvizmo filosofijos prielaidomis, teigiančiomis, kad vadinamoji socialinė realybė bent jau iš dalies yra mentalinė ją stebinčio stebėtojo konstrukcija. Kitaip tariant, neįmanoma atskirti, kokiu mastu analitiko turima socialinės realybės samprata yra objektyvi. Todėl informacinių sistemų specifikacijas būtina papildyti perspektyvų ir daiktų koncepcijų aprašais.

Vadovaujantis šitaip praplėsta ontologija, siūloma vertinti ne tik specifikavimo kalbas, bet ir dalykinės srities analizės metodus. Kadangi analizuojant socialinę tikrovę yra siekiama ją geriau suprasti ir kadangi ta realybė yra analizuojama daugelio perspektyvų požiūriu, tai specifikavimo kalbas (o taip pat ir analizės metodus) siūloma nagrinėti per socialinei realybei konceptualizuoti naudojamų kategorijų prizmę:

1 lentelė. Kategorijų matrica.

Daiktai Savybės Koncepcijos Perspektyvos Daiktai Savybės Koncepcijos Perspektyvos

Autoriaus nuomone, kalbos kokybę galima vertinti, atsakant į klausimus: • kokias semantines kategorijas galima išreikšti kalbai? • kiek patogiai jas galima išreikšti? Į šiuos klausimus atsakinėjama konceptualizavimo kategorijų terminais. Todėl klausimus patogu formuluoti

aukščiau pateiktos matricos langeliuose. Pavyzdžiui, langelyje <daiktas, daiktas> pateikiamas klausimas “Ar, speci-fikuojant daiktą, kalba leidžia sistemiškai ir išreikštiniu būdu specifikuoti visus kitus su to daikto kontekstu susietus daiktus?”

Toks klausimynas rengiamas kiekvienai specifikavimo kalbos kokybės charakteristikai. Kadangi kokybės charakteristikų rinkinys ir tų charakteristikų svarba priklauso nuo konkretaus projekto, tai ir klausimynų rinkinys, ir tuose klausimynuose pateikiami klausimai priklauso nuo konkretaus projekto. Remdamasis darbe [17] pateiktu teiginiu, kad visas kokybės charakteristikas galima apibendrinti iki dviejų – išsamumo ir atitikimo tikrovei (angl. validity), autorius nagrinėja kalbų ir metodų kokybę tik šitų dviejų charakteristikų požiūriu. Pagrindinis dėmesys skiriamas metodams, specifikavimo kalbų vertinimo klausimus paliekant ateičiai.

Taikant šią metodiką praktikoje, išryškėjo keletas su ja susijusių problemų. Viena iš jų yra vadinamoji tranzytivumo problema, siejama su klausimyne pateiktų klausimų tarpusavio priklausomybėmis. Pavyzdžiui, sudarinėjant klausimynus kalbos išsamumui analizuoti, paaiškėjo, kad kai kurie aukščiau pateikta matrica aprašomi sąryšiai implikuoja kitus sąryšius. Pavyzdžiui, jei galima išreikštiniu būdu specifikuoti sąryšius tarp daikto ir jo koncepcijų ir sąryšius tarp koncepcijų ir jų savybių, tai galima išreikštiniu būdu specifikuoti ir sąryšius tarp daikto ir jo savybių. Kitaip tariant, klausimynas nėra minimalus ir analizės ribos kartais gali būti nepagrįstai išplėstos. Kita problema – skirtinga tų pačių kokybės charakteristikų svarbos traktuotė skirtingais laiko momentais. Pavyzdžiui, nors specifikacijos darna yra neabejotinai pageidautina savybė, dažnai gali būti tikslinga projekto pradžioje dirbti su prieštaringa specifikacija, atidedant prieštaravimų šalinimą vėlesniam laikui. Tačiau svarbiausioji problema, kad ši metodika, kaip ir BWW modelių sistema, yra normatyvinė. Kitaip tariant, čia irgi daroma prielaida, kad egzistuoja pats geriausias socialinės realybės konceptualizavimo būdas ir visi kiti būdai turi būti lyginami su juo. Be to, nors metodika ir atsisako specifikavimo kalbos kokybės vertinimo vien tik per ontologinio išsamumo ir ontologinės skaidros prizmę, ji vis vien siūlo naudoti tik vieną kokybės charakteristikų vertinimo būdą – ontologinę analizę. Be to, lieka neaišku kaip, naudojantis vien klausimynu, duoti kiekybinius kokybės charakteristikų įverčius.

4. Kiti ontologiniai specifikavimo kalbų vertinimo metodai

Darbe [19] pasiūlyta specifikavimo kalbas vertinti ne Bunge, bet Chisholm ontologijos [3], [4] pagrindu. Sutinkamai su Chisholm ontologija, socialinė realybė yra sudaryta iš esybių. Terminą esybė Chisholm vartoja skirtinga prasme negu yra įprasta informatikoje, pavyzdžiui, kalbant apie ER diagramas. Chisholm esybės esti

VI – 5


dviejų rūšių: atsitiktinės (angl. contingent) ir būtinosios (angl. necessary). Atsitiktinės esybės egzistuoja retkarčiais, būtinosios – visuomet. Atsitiktinės esybės turi egzempliorius (angl. individuals). Egzemplioriais gali būti arba ribok-liai (angl. boundaries), arba esminės socialinės realybės substancijos. Ribokliai – tai erdviniai elementai, nusakantys egzempliorių substancijų ribas. Substancijos daug maž atitinka tai, ką informatikoje įprasta vadinti esybėmis. Substancija gali būti daiktas, idėja, fikcija ir pan. Būtinosios esybės egzempliorių neturi, jos taip pat representuoja socialinės realybės substancijas ir turi atributus. Abiejų rūšių esybės turi būsenas, bet tik atsitiktinėms esybėms su jomis yra siejami įvykiai. Jie traktuojami kaip būsenų pakategorijos ir naudojami dinamikai modeliuoti. Būtinųjų esybių atributai ir jų reprezentuojamos substancijos yra patvarūs ta prasme, kad jų negalima nei sukurti, nei sunaikinti. Atributus su esybe susieja stebėtojas (analitikas), vadovaudamasis savo intuicija ir įsitikinimais. Sakoma, kad atributas šitaip yra išryškinamas (angl. exemplify). Intencijos ir įsitikinimai yra esminės Chisholm ontologijos kategorijos. Kitaip tariant, čia yra traktuojama ne tai, kad “esybė turi atributą”, bet tai, kad kažkas “yra įsitikinęs, jog ji turi atributą”. Specifikacijose kai kurie atributai yra išryškinami, kai kurie – ne, o kai kurių apskritai neįmanoma išryškinti. Atributais galima išreikšti ir faktus, ir teiginius. Atributai gali būti ne tik elementarūs, bet ir sudėtiniai. Sudėtiniai atributai yra konstruojami iš elementariųjų konjunkcijos ir dizjunkcijos operacijomis.

Esybių egzemplioriai gali būti siejami ryšiais. Ryšiai yra orientuoti, t.y. visuomet turi tam tikrą kryptį. Ryšiai aprašomi per atributus. Per atributus yra aprašomos ir klasės bei aibės. Jos aprašomos aksiomatiškai. Chisholm ontologijoje yra ir daugiau įvairių ypatumų, kurių čia neaptarsime. Besidominantys skaitytojai išsamiai su šia onto-logija gali susipažinti darbuose [3], [4].

Chisholm ontologija vietoje Bunge ontologijos buvo paimta todėl, kad ji autorių nuomone [18] geriau pritaikyta informacinių sistemų, ypač duomenų modeliavimo specifikai. Vertinant specifikavimo kalbas, jas galima traktuoti kaip socialinės realybės modeliavimo konstrukcijų rinkinius. Du analitikai tos pačios specifikavimo kalbos priemonėmis gali parašyti skirtingas specifikacijas. Vienam iš jų prireiks vienų priemonių, kitam – kitų. Todėl, autorių nuomone, kalbas reikia vertinti ne per jų siūlomų konstrukcijų prizmę, bet nagrinėjant kokiu mastu kalbos konstrukcijomis galima specifikuoti socialinės realybės situacijas. Tam siūloma naudoti suderinamumų (angl. agreement) ir skirtumų nustatymo metodus. Naudojant šiuos metodus, socialiniai precedentai (angl. cases) yra anali-zuojami suderinamumų ir skirtumų požiūriu ir siekiama rasti priežastinius ryšius. Po to tie ryšiai yra apibendrinami. Tam reikia apibrėžti kokybinių bruožų (angl. features) aibę ir charakteristikų aibę. Kokybiniais bruožais vadinami situacijų elementai, kurie analitiko įsitikinimu gali būti svarbūs nustatant precedentų skirtumus. Charakteristikos – tai savybių, kuriomis kokybinis bruožas pasireiškia duotojoje situacijoje, rinkinys. Nustatant suderinamumus, siekiama išryškinti bendras duotosios išeigos charakteristikas ir iš jų nuspręsti, kokie kokybiniai bruožai sąlygojo tą išeigą. Nustatant skirtumus, siekiama patikrinti, kad skirtingose išeigose tam pačiam kokybės bruožui tikrai yra stebimos skirtingos charakteristikos. Taikant šiuos metodus, analizuojama kokie specifikavimo kalbos suderina-mumai ir kokie jos skirtumai yra stebimi, lyginant ją su Chisholm ontologija. Ar koks nors kokybinis bruožas yra būdingas vertinamai specifikavimo kalbai, vertinama naudojant kokybinę darnos/skirtumų penkių lygmenų skalę. Vertinama ne tik atsižvelgiant į tai, ar kalba palaiko kokybinį bruožą, bet ir į tai, kokiu mastu yra palaikomas tas bruožas.

Nors ši metodika, lyginant ją su BWW modelių sistema, geriau atsižvelgia į specifinius informacinių sistemų specifikavimo poreikius, ji vis vien yra normatyvinė, t.y. siekia sukonstruoti “patį geriausią” konceptualizavimo būdą. Todėl jai būdingi beveik visi tie patys trūkumai, kurie yra būdingi BWW modelių sistemai. Šiuos trūkumus bandyta pašalinti darbuose [20], [9], kuriuose atsisakyta požiūrio, kad būtina vadovautis kokia nors normatyvine ontologija. Iš esmės jie siūlo lyginti ontologinius susitarimus, kuriais grindžiamos skirtingos specifikavimo kalbos. Darbe [20] siūloma kalbos ontologinę analizę atlikti vadovaujantis sudėtinga ontologine sistema, sudaryta iš statinės (angl. static), dinaminės (angl. dynamic), intencijų (angl. intentional) ir socialinės (angl. social) ontologijų. Apskri-tai, kalbas siūloma vertinti trim aspektais: ontologiniu, abstrakcijos mechanizmų ir instrumentiniu. Aptarsime šiuos aspektus išsamiau.

Statinė ontologija konceptualizuoja struktūrinius socialinės realybės aspektus. Daugelis šiuolaikinių specifikavimo kalbų yra grindžiamos ontologine prielaida, kad socialinė realybė yra sudaryta iš esybių (tiksliau, jų egzempliorių), turinčių nekintančią tapastį, apibūdinamų atributų rinkiniu, kintančių pagal tam tikro gyvavimo ciklo nusakytus dėsnius ir susietų sąryšiais su kitomis esybėmis. Tačiau toks socialinės realybės konceptualizavimo būdas nėra nei universalus, nei minimalus, nei geriausias kuriuo nors kitu požiūriu. Tiesiog šitaip yra prasminga kon-ceptualizuoti tikrovę, sprendžiant tam tikros klasės uždavinius. Kitiems uždaviniams patogesnė gali būti kitokia socialinės realybės konceptualizacija.

Dinaminė ontologija konceptualizuoja socialinės realybės dinamiką. Paprastai jie yra aprašomi per būsenos, perėjimo iš būsenos į būseną ir proceso kategorijas. Tačiau tai taip pat ne vienintelis pokyčių konceptualizavimo būdas. Pavyzdžiui, socialinės realybės dinamiką galima konceptualizuoti per proceso, proceso žingsnio, tikslo ir agento kategorijas.

Intencijų ontologija konceptualizuoja agentų mentalitetą, t.y. jų įsitikinimus, norus, argumentus ir pan. Tam taip pat gali būti vartojamos įvairios kategorijų sistemos, pavyzdžiui, sistema, sudaryta iš kategorijų agentas, tikslas, potikslis, tema, aprobavimas, neigimas ir pan. Pažymėtina, kad tokio pobūdžio kategorijomis operuoja tiktai

VI – 6


naujausios informacinių sistemų specifikavimo kalbos, nors dirbtinio intelekto teorijoje jomis operuojama jau keletą dešimtmečių.

Socialinė ontologija konceptualizuoja socialinėje realybėje funkcionuojančias organizacines struktūras. Tam gali būti, pavyzdžiui, vartojama kategorijų sistema aktorius, pozicija, vaidmuo, įgaliojimai, įsipareigojimai ir pan. Šios ontologijos skirtos aktorių rolėms, strateginiam priklausomumui tarp aktorių nustatyti. Toks priklausomumas gali atsirasti, pavyzdžiui, tuomet, kai aktorius perduoda užduoties vykdymą kitam aktoriui.

Specifikavimo kalbos skiriasi tuo, kuriuos socialinės realybės aspektus (statinį, dinaminį, intencijų, socialinį) galima jomis specifikuoti.

Jei ontologijos apibūdina specifikuojamąją socialinę tikrovę, tai specifikavimo kalbos abstrakcijos mechanizmai nusako leistinus informacijos organizavimo būdus. Svarbiausieji abstrakcijos mechanizmai yra klasifikavimas (angl. classification), apibendrinimas (angl. generalisation), agregavimas (angl. aggregation), kontekstualizavimas (angl. contextualisation), materializavimas (angl. materialisation), normalizavimas (angl. normalisation) ir parametri-zavimas (angl. parametrisation) [20]. Specifikavimo kalbos skiriasi palaikomais abstrakcijos mechanizmais.

Instrumentinės priemonės skirtos padidinti specifikacijas sudarančio asmens darbo našumą. Jos padeda su-daryti, analizuoti ir vertinti. Specifikavimo kalbos skiriasi tuo, kokius instrumentus galima joms sukurti.

Mylopoulos siūlo specifikavimo kalbas vertinti atsižvelgiant į tai, kokiomis ontologijomis jos yra grindžiamos, kokie abstrakcijos mechanizmai jose yra palaikomi ir kokias instrumentines priemones joms galima sukurti. Naudojant autoriaus siūlomas klasifikavimo schemas, visus tris aspektus galima įvertinti pagal pasirinktą skalę. Siūloma naudotis skale {exellent, good, OK, so-so, none}. Bendras specifikavimo kalbos įvertis gaunamas atitin-kamai kombinuojant jos aspektų įverčius. Kiekvienos dimensijos įvertinimas gaunamas sudėjus jos komponentų įverčius.

Turint specifikavimo kalbų įverčius, konkrečiam projektui labiausiai tinkamą kalbą siūloma parinkti vado-vaujamasi tokiais kriterijais:

• informacinės sistemos tipas (kokių ontologijų reikia), • informacinės sistemos sudėtingumo laipsnis (kokių abstrakcijos mechanizmų reikia), • informacinės sistemos apimtis (be kokių instrumentinių priemonių negalima apsieiti), • sprendžiamų uždavinių pobūdis (abstrakcijos mechanizmų ir instrumentinių priemonių poreikis. Ši specifikavimo kalbų vertinimo metodika taip pat turi rimtų trūkumų. Visų pirma neaišku, ar siūlomas onto-

logijų rinkinys iš tiesų yra pakankamas visiems socialinės realybės aspektams konceptualizuoti. Pavyzdžiui, darbe [9] ontologijų sistemą siūloma konstruoti visiškai kitaip. Antra, visos vienos ontologijos kategorijų sistemos laikomos lygiavertėmis, o taip nėra. Vienos jų geriau yra pritaikytos vieniems tikslams, kitos – kitiems. Trečia, įver-čiai gaunami subjektyviai, neatliekant kokių nors tikslesnių matavimų, o ir pati skalė yra negriežta, kokybinė.

5. LSS karkasas

Mokslinėje literatūroje yra pasiūlyta ir kitokių, ne tik ontologinės analizės principais grindžiamų specifikavimo kalbų vertinimo metodų. Tipiškas tokio metodo pavyzdys yra vadinamasis Lindland, Sindre,. Sølvberg (LSS) karkasas [17]. LSS karkasas yra vienas iš pirmųjų bandymų sukurti IS specifikavimo kalbų kokybės modelį. Jis buvo pasiūlytas darbe [27], vėliau išplėtotas darbe [26] ir išbaigta forma aprašytas darbuose [16] ir [17]. LSS karkasas apibrėžia kalbos kokybės, procesų kokybės ir specifikacijos kokybės modelius. Aptarsime LSS karkaso kalbos kokybės modelį išsamiau.

Kokybė nagrinėjama formaliai apibrėžus specifikavimo kalbos, socialinės realybės ir socialinės realybės modelio sąvokas. Specifikavimo kalba apibrėžiama kaip aibė visų sintaksiškai teisingų sakinių, socialinė realybė - kaip aibė visų jos požiūriu prasmingų sakinių (kalbos poaibis), modelis – kaip aibė socialinės realybės požiūriu prasmingų sakinių, priklausančių duotąjai specifikacijai. Jos samprata grindžiama specifikacijų, kurias galima parašyti ta kalba, kokybės samprata. IS specifikavimo kalba laikoma kokybiška, jei ji įgalina rašyti kokybiškas specifikacijas. Išskiriami šeši specifikacijos kokybės aspektai: fizinė kokybė, empirinė kokybė, sintaksinė kokybė, semantinė kokybė, pragmatinė kokybė ir socialinė kokybė [16].

Fizinė kokybė siejama su specifikacijos pateikties forma (diske, popieriuje ir kt.). Svarbiausios fizinę kokybę apibūdinančios savybė yra galimybė saugoti specifikacijas taip, kad, viena vertus, jos būtų apsaugotos nuo praradimų ir kad, kita vertus, būtų patogiai ir operatyviai prieinamos visiems suinteresuotiems asmenims.

Empyrinė kokybė nusako klaidų specifikacijose tikimybę bei ergonomines specifikacijų ir potencialiai galimų jomis manipuliuoti skirtų instrumentinių priemonių savybes.

Sintaksinė kokybė suprantama kaip socialinės realybės modelio darna su tuo specifikavimo kalbos plėtiniu, kurio priemonėmis rašoma specifikacija. Kalba išplečiama, papildant ją konkretaus socialinės realybės fragmento

VI – 7


žodynu. Siekiama, kad kalba būtų sukonstruota taip, kad sintaksinis analizatorius galėtų atpažinti visus sintaksiškai klaidingus sakinius, taip pat ir tuos, kuriuose vartojamos kalbą išplečiančios konstrukcijos.

Semantinė kokybė suprantama kaip socialinės realybės modelio ir specifikuojamo tos realybės fragmento darna. Modelis turi būti išsamus ir tikroviškas (angl. valid). Kitaip tariant, specifikavimo kalba turi leisti rašyti išsamias ir tikroviškas specifikacijas.

Pragmatinė kokybė suprantama kaip socialinės realybės modelio ir tą modelį nagrinėjančių subjektų mentaliteto darna. Tai reiškia, kad specifikavimo kalba turi leisti konceptualizuoti socialinę tikrovę taip pat, kaip ją konceptua-lizuoja būsimieji informacinės sistemos vartotojai.

Socialinė kokybė suprantama kaip galimybė derinti skirtingų socialinėje realybėje veikiančių subjektų po-žiūrius.

Specifikavimo kalbos kokybės modelį LSS karkase sudaro du lygmenys. Viršutiniame lygmenyje išskiriamos dvi kokybės atributų grupės: koncepciniai atributai, aprašantys kalbos konstrukcijas koncepciniu aspektu, ir pateik-ties atributai, aprašantys kalbos konstrukcijų vaizdavimą, pavyzdžiui, konstrukcijų vizualizavimą ekrane [2].

Antrajame kokybės modelio lygmenyje kiekviena viršutinio lygmens grupė yra suskaidoma į penkis pogrupius: • suvokiamumą (angl. perceptibility), apibūdinantį kalbos konstrukcijų ir jų vaizdavimo suprantamumą

analitikams, projektuotojams ir kitiems veikiantiesiems asmenims, • raiškos gebą (angl. expressive power), apibūdinančią ontologinį kalbos išsamumą, • raiškos ekonomiją (angl. expressive economy), apibūdinančią kalbos konstrukcijų efektyvumą (semantinę

galią), • technologiškumą (angl. method/tool potential), apibūdinančią galimybes sukurti instrumentines kalbos

palaikymo priemones [16]. • supaprastinamumą (angl. reducibility), apibūdinantį galimybes supaprastinti dideles ir sudėtingas

specifikacijas, jas atitinkamai struktūrizuojant [26]. Taigi, antrojo lygmens atributai charakterizuoja kalbą trim požiūriais: dalykinės srities, vartotojų ir techno-

logijos. Naudojant siūlomą kokybės modelį įvertinamas kalbos tinkamumas dalykiniai sričiai aprašyti (raiškos geba), kalbos patogumas vartotojams (suvokiamumas, raiškos ekonomija ir supaprastinamumas), ir technologinio kalbos palaikymo galimybė (technologiškumas).

Raiškos geba LSS karkase artimai susijusi su sąvoka siejasi su BWW vaizdavimo modelyje vartojama ontolo-ginio išsamumo sąvoka. Tačiau šios sąvokos nėra identiškos. Raiškos geba apibūdina ne tik dalykinės srities apra-šymo galimybes, bet ir nusako kokių dalykinės srities aspektų negalima išreikšti specifikavimo kalba. Pažymėsime, jog kartais raiškos geba yra suprantama kaip raiškos adekvatumas. Tačiau tai šiek tiek kita kalbos savybė. Raiškos adekvatumas turi du aspektus. Pirmasis charakterizuoja kalbos galimybes išskirti detales (selektyvinė geba), antrasis aprašo kalbos galimybes paslėpti detales (apibendrinimo geba) [2].

Suprantamumo sąvoka yra artima ontologinės skaidros sąvokai. Specifikacija yra suprantama vartotojui, jei ji tenkina dvi sąlygas: grindžiama socialinės realybės konceptualizacija, atitinkančią vartotojo turimą tos realybės sampratą (atitinka vartotojui įprastą dalykinės srities metaforą) ir užrašyta kalba, kuri yra konceptualizuota vartojant tą pačią kategorijų sistemą, kuri buvo vartota socialinei realybei konceptualizuoti. Taigi, suprantamumo sąvoka yra platesnė už ontologinės skaidros sąvoką [2].

Kalbos technologiškumas siejamas su kalbos instrumentavimo galimybėmis. Kalba yra technologiška, jei jos konstrukcijas yra pakankamai paprasta interpretuoti programiškai [16]. Tai siejama su teorine galimybe atlikti automatinius samprotavimus (kalboje turi būti atitinkamas loginio išvedimo aparatas) ir galimybe tuos samprotavimus efektyviai realizuoti programiškai. Taigi, kalbos technologiškumas yra artimai susijęs su notacijos efektyvumu [38], kuris nusakomas kalbos koncepcine struktūra, jos konkrečia vaizdavimo forma ir iš to kylančiais reikalavimais programinei įrangai, manipuliuojančiai specifikacijos tekstu. Sutinkamai su [38], notacijos efekty-vumas nusakomas skaičiavimo efektyvumu ir koncepciniu efektyvumu. Koncepcinis efektyvumas palaiko žinių ištraukimą, skaičiavimo efektyvumas palaiko samprotavimus ir kitus skaičiuojamuosius algoritmus.

Trumpai reziumuojant, LSS karkasas yra grindžiamas šitokiomis idėjomis: • atskiriamos kalbos konstrukcijos ir konkrečios sintaksinės tų konstrukcijų vaizdavimo formos (pateiktis), • kalbos kokybė vertinama naudojantis atitinkamu kokybės modeliu, • kokybė vertinama socialinės realybės, vartotojo ir technologiniu aspektais, • kokybės atributai apibrėžiami aibių teorijos priemonėmis (kaip tai yra daroma, galima susipažinti iš darbo

[16]) LSS karkasas labiausiai priartėja prie tikslo sukurti objektyvią specifikavimo kalbų vertinimo metodiką. Tačiau

ši metodika taip pat turi rimtų trūkumų. Pasiūlytasis kokybės modelis nėra iki galo išbaigtas, neaišku kaip matuoti ir

VI – 8


vertinti kokybės charakteristikas, ignoruojami vertingi autorių, bandančių kokybę vertinti remiantis atitinkamomis ontologijomis, pasiūlymai. Neaišku kaip, vertinant kalbos kokybę, atsižvelgti į konkretaus projekto poreikius.

6. Išvados

Specifikavimo kalboms vertinti šiuo metu yra pasiūlyti du koncepciniu požiūriu skirtingi būdai. Pirmasis būdas yra grindžiamas ontologinės analizės metodika, t.y. specifikavimo kalbos kokybė yra vertinama per jos ontologinio išsamumo ir ontologinės skaidros prizmę. Tai daroma dviem skirtingais būdais: arba konstruojant “pačią geriausią” socialinės tikrovės ontologiją, arba analizuojant ontologinius susitarimus, kuriais yra grindžiama specifikavimo kalba, pasirinktojoje ontologijų sistemoje. Nei vienas šios pakraipos metodas nėra pakankamas specifikavimo kalbos tinkamumui konkrečiam projektui vertinti, nes niekaip neatsižvelgia į konkrečius to projekto reikalavimus.

Antrasis specifikavimo kalbų vertinimo būdas tas kalbas siūlo vertinti, sukonstruojant kalbos kokybės charak-teristikų hierarchiją (kokybės modelį). Šis būdas taip pat kol kas negali būti panaudotas specifikavimo kalbos tinkamumui konkrečiam projektui vertinti, nes, viena vertus, taip pat neatsižvelgia į kokybės sampratos realia-tyvumą, priklausomybę nuo konkretaus projekto ypatumų ir, kita vertus, nepagrindžia teoriškai siūlomo kokybės charakteristikų rinkinio ir nepateikia konkrečių jų matavimo bei vertinimo procedūrų.

Mūsų nuomone, specifikavimo kalbos vertinimo būdas turėtų būti konstruojamas derinant abiejų aukščiau mi-nėtų būdų privalumus, pašalinant jų trūkumus ir išreikštiniu būdu įvedant konkretaus projekto konteksto sąvoką.

Literatūros sąrašas [1] M. Bunge. Treatise on Basic Philosophy. Reidel, Boston, 1977, Vol. 3: Ontology I: The Furniture of the World. [2] A. Caplinskas, A. Lupeikiene, O. Vasilecas. A Framework to Analyse and Evaluate Information Systems Specification

Languages. Y. Manolopoulos, P. Navrat (eds.). Advances in Databases and Information Systems. 6th East European Conference, ADBIS 2002, Bratislava, Slovakia, September 2002, Proceedings. LNCS 2435, Springer, 2002, pp. 248-262

[3] R.M. Chisholm. The basic ontological categories. K. Muligan (ed.). Language, Truth, and Ontology, Kluwer Academic Publishers, 1992

[4] R.M. Chisholm. A Realistic Theory of Categories – An Essay on Ontology. Cambridge University Press, 1996. [5] R.M. Colomb, R. Weber. Completeness and Quality of Ontology for an Information System. N. Guarino (ed.), Formal

Ontology in Information Systems. Proceedings of FOIS’98, Trento, Italy, 6-8 June 1998. IOS Press, Amsterdam, 1998, pp. 207-217.

[6] P. Green, M. Rosemann. Integrated Process Modeling: An Ontological Evaluation. Information Systems, 2000, 25 (2), pp. 73-87

[7] P. Green, M. Rosemann. An Ontological Analysis of Integrated Process Modeling. M. Jarke, A. Oberweis, (eds.), Advanced Information Systems Engineering. Lecture Notes in Computer Science, Springer-Verlag, Berlin Heidelberg New York, 1999, Vol. 1626, pp. 225–240

[8] P. Green. M. Rosemann. Integrating multi-perspective views into ontological analysis. Proceedings of the International Conference on Information Systems OCIS 2000, Brisbane, Australia, December 11-13, 2000, Online publication, http://www.commerce.uq.edu.au/icis/ICIS2000.html

[9] N. Guarino. Formal Ontology and Information Systems. Guarino, N. (ed.): Formal Ontology in Information Systems. Proceedings of FOIS’98, Trento, Italy, 6-8 June 1998. IOS Press, Amsterdam, 1998, pp. 3-15

[10] D. Jackson. Alloy: A Lightweight Object Modelling Notation. Avai l abl e f r om: http://sdg.lcs.mit.edu/alcoa . [11] D. Jackson. A Comparison of Object Modelling Notations: Alloy, UML and Z. Unpublished manuscript. MIT Lab for

Computer Science, August 1999, accesible at the http://geyer.lcs.mit.edu/~dnj/pubs/alloy~comparison.pdf [12] D. Jackson, J. Wing. Lightweight formal methods. IEEE Computer, April 1996, pp. 21-22, accesible also at the

http://geyer.lcs.mit.edu/~dnj/pubs/ieee96-roundtable.html [13] I. Johansson. Pattern as an ontological category. N. Guarino (ed.). Formal Ontology in Information Systems, IOS Press,

1998, pp.86-94 [14] M. N. Johnstone, D.C. McDermid. Using ontological ideas to facilitate the comparison of reąuirements elicitation

methods. Proceedings of the Twelfth Australasian Conference on Information Systems (CD), Coffs Harbour, NSW, Australia, December 5-7, 2001, http://infotech.scu.edu.au/ACIS2001/Proceedings/

[15] N.D. Jones, D.A. Schmidt. Compiler generation from denotational semantics. LNCS 94, Springer Verlag, 1980. [16] J. Krogstie, A. Sølvberg. A.: Information Systems Engineering: Conceptual Modeling in a Quality Perspective (the draft

of the book). The Norwegian University of Science and Technology, Andersen Consulting , January 2, 2000. [17] O.I. Lindland, G. Sindre, A. Sølvberg. Understanding Quality in Conceptual modelling. IEEE Software, March 1994,

pp. 42-49

VI – 9

http://www.commerce.uq.edu.au/icis/ICIS2000.html

http://sdg.lcs.mit.edu/alcoa

http://geyer.lcs.mit.edu/~dnj/pubs/alloy~comparison.pdf

http://geyer.lcs.mit.edu/~dnj/pubs/ieee96-roundtable.html

http://infotech.scu.edu.au/ACIS2001/Proceedings/


[18] S. Milton, E Kazmierczak. Enriching the Ontological Foundations of Modelling in Information Systems. C. N. G. Dampney et al. (eds.), IS Foundations - Ontology, Semiotics and Practice, Macquarie University, Sydney/Australia, 1999.

[19] S. Milton, E Kazmierczak, C. Keen. Comparing Data Modelling Frameworks Using Chisholm's Ontology, Proceedings of the 4th European Conference on Information Systems, ECIS'98, Aix-en-Provence, June 1998, 1998.

[20] J. Mylopoulos. Characterizing Information Modeling Techniques. P. Bernus, K. Mertins, G. Schmidt (eds.). Handbook on Architectures of Information Systems. Springer, Berlin, 1998, pp. 17-57.

[21] Andreas L. Opdahl. Applying Semantic Quality Criteria to Multi-Perspective Problem Analysis Methods. Eric Dubois, Andreas L. Opdahl and Klaus Pohl (eds.). Proceedings of "The Third International Workshop on Requirements Engineering: Foundations of Software Quality — REFSQ'97", Barcelona/Spain, June 1997, 1997.

[22] J. Parsons, Y. Wand. Using Objects in Systems Analysis, Communications of the ACM (40:12), 1997, pp. 104-110. [23] L.J. Peters, L.L. Trip. Comparing Software Design Metodologies. Datamation, 1977, 23(11), pp. 89-94. [24] M. Rosemann, P. Green. Developing a Meta-Model for the Bunge-Wand-Weber Ontological Constructs. Information

Systems, 2002, 27, pp. 75-91 [25] M. Rosemann, P. Green. Enhancing the process of ontological analysis – the “Who cares” dimension. C. N. G.

Dampney et al. (eds.). Proceedings of the Information Systems Foundations Workshop: Ontology, Semiotics and Practices, Macquarie University, Sydney/Australia, 1999. http://www.comp.mq.edu.au/isf99/Rosemann.html

[26] A.H. Seltveit. Complexity Reduction in Information Systems Modelling (PhD thesis), IDT, NTH, Trondheim, Norway, 1994.

[27] G. Sindre. HICONS: A General Diagrammatic Framework for Hierarchical Modelling (PhD thesis), IDT, NTH, Trondheim, Norway, 1990.

[28] R. Weber. Ontological Foundations of Information Systems, Coopers & Lybrand Accounting Research Methodology, Monograph No. 4, Melbourne, 1997.

[29] Y.Wand, V.C. Storey, R. Weber. An Ontological Analysis of the Relationship Construct in Conceptual Modeling. ACM Transactions on Database Systems, Vol. 24, No. 4, December 1999, pp. 494-528

[30] Y. Wand, R. Weber. A Model of Control and Audit Procedure Change in Evolving Data Processing Systems. The Accounting Review, 1989, LXIV (1), pp. 87–107

[31] Y. Wand, R. Weber. An Ontological Evaluation of Systems Analysis and Design Methods. Falkenberg, E.D., Lindgreen, P. (eds.): Information Systems Concepts: An In-depth Analysis. North-Holland, Amsterdam, 1989, pp. 79-107

[32] Y. Wand, R. Weber. An Ontological Model of an Information System. IEEE Trans. Software Eng., 1990, 16(11), pp. 1281-1291.

[33] Y. Wand, R. Weber. Mario Bunge’s Ontology as a Formal Foundation for Information Systems Concepts. P. Weingartner, G.J.W. Dorn, (eds.): Studies on Mario Bunge’s Treatise. Rodopi, Atlanta, 1990, pp. 123-149.

[34] Y. Wand, R. Weber. A Unified Model of Software and Data Decomposition. J. DeGross, I. Benbast, G. DeSanctis, C.M. Beath (eds.): Proceedings of the Twelfth International Conference on Information Systems, 1991, pp. 101-110.

[35] Y. Wand, R. Weber. On the Ontological Expressiveness of Information Systems Analysis and Design Grammars. Journal of Information Systems, 1993, 3(4), 217-237.

[36] Y. Wand, R. Weber. On the Deep Structure of Information Systems. Information Systems Journal. 1995, 5, pp. 203-223. [37] R. Weber, Y. Zhang. An Analytical Evaluation of NIAM’s Grammar for Conceptual Schema Diagrams. Information

Systems Journal, 6(2), 1996, pp. 147-170.

[38] W.A. Woods. What’s Important About Knowledge Representation? Computer, 1983, pp. 22-27.

Information systems specification languages quality evaluation

This paper discusses the Information Systems specification language evaluation problem. It compares two main approaches: ontology analysis and quality-model based approach. The paper discusses strengths and weaknesses of both approaches and demonstrates that up to date any approach is enough elaborated to use it to select mostly appropriate specification language for the needs of particular project.

VI – 10

http://www.comp.mq.edu.au/isf99/Rosemann.html

SU ISO 10303 SUDERINTO INŽINERINIŲ DUOMENŲ VALDYMO KLAUSIMU

Rimvydas Nogis Vilniaus Gedimino technikos universitetas

Apžvalga. Produkto projektavimo iteratyviniame procese gaminame ir naudojame daug inžinerinių duomenų. Pranešime apžvelgiama inžinerinių duomenų sistemos duomenų modeliai. Aprašomi, su ISO 10303 suderinami, duo-menų modeliai: produkto apibrėžimas, produkto struktūra, produkto geometrinės formos pateiktis. Produkto geomet-rinės formos pateikties vystymosi kryptys apžvelgiamos.

1. Įvadas

Produkto gyvavimo cikle, pradedant principinių sprendimų tyrimu ir baigiant produkto utilizacija efektyvus duomenų apie produktą valdymas nėra naujas uždavinys[8],[9]. Pilnam produkto gyvavimo ciklui duomenų modelio sudarymas yra sprendžiamas tarptautiniu standartu ISO 10303[2]. Standartas planuojamas, ruošiamas ir išleidžiamas atskiromis dalimis. Standarto pirmosios dalys patvirtintos 1994 metais.

Duomenų apie produktą, laikomų integruotoje duomenų bazėje, potencialiais vartotojais laikomos planavimo, projektavimo, gamybos paruošimo, gamybos, finansų, kokybės užtikrinimo ir kitos grandys. Standarto ISO 10303 apibrėžimai rašomi pačiame standarte pateikta EXPRESS kalba, kuri turi grafinį poaibį EXPRESS-G. Šiuo metu standarte yra patvirtinta virš 90 dalių. Dauguma komercinių kompiuterizuoto projektavimo produktų turi duomenų transliatorius išeinantiems ir įeinantiems produktų geometrinės formos duomenims į standarto nustatytus formatus. Produktų duomenų modeliai naudojami komercinėse inžinerinių duomenų valdymo sistemose sudaromi atsižvel-giant į standarto projektų svarstymuose nusistovėjusias kokybes.

2. Produkto apibrėžimas

Produktą pilnai apibrežiant ISO 10303 standartu paremtoj inžinerinių duomenų valdymo sistemoj, naudojame šio standarto esinius. Pagrindinius esinius pateikiame 1 lentelėj, o jų ryšius EXPRESS-G kalbos grafine diagrama 1 paveiksle.

1 lentelė. Produkto apibrėžimo duomenų modelis

Esinys Šaltinis standarte product Produkto apibrėžimo schema ISO 10303-41[3] product_definition_formation Produkto apibrėžimo schema ISO 10303-41 product_definition_formation_relationship Produkto apibrėžimo schema ISO 10303-41 product_definition_formation_with_specified_source Produkto apibrėžimo schema ISO 10303-41 product_definition Produkto apibrėžimo schema ISO 10303-41 product_definition_with_associated_document Produkto apibrėžimo schema ISO 10303-41 document Dokumento schema ISO 10303-41 product_definition_relationship Produkto apibrėžimo schema ISO 10303-41

Produkto apibrėžimo duomenų modelyje aprašoma produkto identifikacija ir apibrėžimas, grupuojama produkto versijos ir aprašomi ryšiai tarp produktų. Esinys product turi keletą požymių, tarp jų: id, name, description ir frame_of_reference. Paskutinis jų priklauso nuo produktų taikomosios srities.

Esinio product_definition_formation tikslas yra atspindėti produkto specialią versiją. Jo požymiai yra tokie: id, description ir of_product. Paskutinis jų nurodo kuriai produkto versijai priklauso specialioji versija. Esinys product_definition_formation_relationship aprašo to pačio produkto dviejų versijų ryšį. Šis esinys gali būti naudojamas istorijos fiksavimui tarp buvusios ir esamos versijos atsiradus inžneriniam pakeitimui. Jo požymiais tarnauja: id, name, description, relating_product_definition_formation ir related_product_definitio_formation.

Esinys product_definitio_formation_with_specified_source nurodo iš kur produkto versija kilo. Jis turi papildo-mą požymį make_or_buy parodantį ar produktas pagamintas organizacijos viduje, ar pirktas.

VI – 11

R.Nogis

Esinys product_definition naudojamas produkto specifiniam aprašymui: produkto geometrijos ar gamybos duomenims. Tarp jo požymių yra tokie: id, description, formation ir frame_of_reference. Produkto apibrėžimo doku-mentams išvardinti yra esinys product_definition_with_associated_documents. Esinys document naudojamas pro-dukto aprašymams. Paprastai dokumentų būna daug ir jų identifikatoriai yra aibė požymyje documents_ids.

product_definition_formation_relationship

product _definition_formation

product_definition_formation product

product_definition_relationship

product_definition

product_definition_with

relating_product_definition_formation

related_product_definition_formation

idnamedescription

iddescription

of_product

frame_of_reference_with_specified_source

make_or_buyrelating_product-definition

related_product-definition

frame_of_reference

iddescription

_associated_documents

document

id name description

id name description kind

1 pav. Produkto apibrėžimo schema EXPRESS-G formatu

Esinys product_definition_relationship nusako santykį tarp product_definition egzempliorių produkte. Jo požymiai yra tokie: id, name, description, relating_product_definition ir related_product_definition.

3. Produkto struktūra

Produkto sudedamosios dalys apibrėžiamos produkto struktūros duomenų modelyje. Modelio pagrindiniai esi-niai pateikiami 2 lentelėje. Ryšiai tarp esinių matomi 2 pav.

2 lentelė. Produkto struktūros duomenų modelis

Esinys Šaltinis standarte product_definition_usage Produkto savybės apibrėžimo schema ISO 10303-44[6] assembly_component_usage Produkto savybės apibrėžimo schema ISO 10303-44 make_from_usage_option Produkto savybės apibrėžimo schema ISO 10303-44 next_assembly_usage_occurrence Produkto savybės apibrėžimo schema ISO 10303-44 promissory_usage_occurrence Produkto savybės apibrėžimo schema ISO 10303-44 quatified_assembly_component_usage Produkto savybės apibrėžimo schema ISO 10303-44

Esinys product_definition_usage yra esinio product_definition_relationship sub-esinys. Esinys make_from_ usage_option nurodo, kad vienas produktas pagamintas iš kito. Esinys assembly_component_usage nusako, kad produktas surinktas iš žemesnio lygmens detalių. Šie abu esiniai negali būti kartu, tik arba vienas arba kitas. Esinys make_from_usage_option gali būti naudojamas aprašyti santykį tarp produkto ir ruošinio medžiagos. Požymiai ranking, ranking_rationale, ir quantity nurodo rūšiavimą, rūšiavimo pagrindimą ir kiekį, bei jo matą.

Esinys assembly_component_usage savyje laiko duomenis apie medžiagų ir detalių specifikacijas. Esinys quantified_assembly_component_usage nurodo komponentų kiekius produkte. Esinys next_assembly_usage_ occurance gali būt naudojamas kelių lygių specifikacijoms suformuoti ir joms sujungti. Esinys promissory_usage_ occurrance skiriasi nuo anksčiau nurodytų komponentų tuom, kad gali būti naudojamas, kol produkto struktūra dar yra nepilnai apibrėžta, nėra pilnai žinoma komponento tinkamumas produktui.

VI – 12

Su ISO 10303 suderinto inžinerinių duomenų valdymo klausimu

product_definition_usage

assembly_component_usage

quantified_assembly_component_usage

make_from_usage_option

next_assembly_usage_occurance

promissory_usage_occurance

rankingmaking_rationale

quantity1

1

2 pav. Produkto struktūros schema EXPRESS-G formatu

4. Formos pateiktis

Be produkto konfiguracijos duomenų yra svarbi produkto geometrijos pateiktis. Pateikties schemos gali būti daugybinės, jei kelių schemų buvimas palengvina geometrijos perdavimo uždavinį[7]. Pagrindiniai esiniai schemoje pateikti 3 lentelėje. Ryšiai tarp esinių matomi 3 pav.

3 lentelė. Formos pateikties duomenų modelis

product_definition_shape representation_of shape_definition_representation

representation

representation_item

geometric_representation_item topological_representation_item

representation_context

shape_representation

pavadinimas

aprasas

geometric_representation_item

representation

representation_item

product_definition_shapeapraðas

pavadinimasrepresentation_of shape_definition_representation

representation_context

topological_representation_item shape_representation

repr

eset

atio

n_m

odel

3 pav. Formos pateikties schema EXPRESS-G formatu

Esinys Šaltinis standarte product_definition_shape Produkto savybės apibrėžimo schema ISO 10303-41[3] shape_definition_representation Produkto savybės apibrėžimo schema ISO 10303-41 shape_representation Produkto savybės apibrėžimo schema ISO 10303-41 representation Pateikties schema ISO 10303-43[5] representation_context Pateikties schema ISO 10303-43 representation_item Pateikties schema ISO 10303-43 geometric_representation_item Geometrijos schema ISO 10303-42[4] topological_representation_item Topologijos schema ISO 10303-42

Produkto formos apibrėžimas arba apibrėžimo santykis talpinamas esinyje product_definition_shape. Forma

gali būti aprašyta tekstu, nenaudojant specifinės geometrijos pateikties. Projektavimo pradinėje stadijoje projek-tuotojas gali nedetalizuoti geometrinės pateikties, aprašyti tik esminias charakteristikas. Naudojant šį esinį, formos charakteristikos gali būti prijungtos prie product_definition arba product_definition_relationship.

VI – 13

R.Nogis

Naudojant esinį shape_definition_representation formos charakteristikos gali būti tiksliau pateikiamos pateik-ties modeliu, pav., tūrio ribine pateiktimi. Kadangi representation_model ir represent_of yra nepriklausomi požy-miai, tai vienas produktas gali turėti kelis besiskiriančius pateikties modelius.

Esinys shape_representation apibrėžia kuri produkto forma yra modeliuojama geometrinėje pateiktyje. Šis esinys yra representation sub-esiniu ir paveldi visus jo požymius. Dabartinėse kompiuterinio projektavimo sistemose su ISO 10303 suderintos geometrinės pateikties schemos daugiausia būna tūrio ribinė pateiktis pagal ISO 10303-203 suderinamumo 4 ir 6 klases.

5. Formos pateikties perspektyvos

Produkto tūrio ribinė pateiktis ISO 10303 standartu apibrėžia bylos formatą, į kurį ir iš kurio transliatoriais aprūpintos visos šiuolaikinės kompiuterinio projektavimo programos. Formos duomenų pernešimas iš vienos sistemos į kitą susideda iš dviejų transliavimo žingsnių. Charakteringa kad pirmojo žingsnio metu transliuojant į ISO 10303 formatą prarandama visi formos parametrizavimo, apribojimų ir bruožų duomenys. Visi duomenys apie produkto geometrija tėra tik topologiniai ir geometriniai esiniai. Ruošiant gaminio technologiją mums labai svarbūs duomenys yra formos bruožai. Projektavimo metu sukurti bruožai yra artimi technologinio paruošimo operacijoms. Tuo pačiu prarandame galimybę redaguoti produkto formą naujoje kompiuterinio projektavimo aplinkoje.

ISO darbo grupėje ISO TC184/SC4 yra parametrikos grupelė[7], kurios pagrindinis tikslas yra ištaisyti esamą padėtį. Panašius tikslus, tik savo organizacijų uždavinių rėmuose, turi ir kitos organizacijos: CAM-I[10], DMAC OLE[1], ENGEN[7] ir kt. Čia išsiskiria dvi kryptys formos modeliavime. Vieną, kai turime tiesiogiai išreikštus šonus, briaunas ir viršūnes, ir antrą procedūrinį arba netiesioginį formos pateikimą. Esamos kompiuterinio projektavimo sistemos savo viduje naudoja abi krypčių elementus bruožų formavime. Pavyzdžiui, tempinyje naudojami tiesiogiai išreikštų profilio ir tempimo kelio duomenys ir tempimo operacija, kuriai reikia skaičiavimo proceso. Abi kryptys grynai darbiniu požiūriu vertinant turi savo privalumus ir trūkumus. Procedūriškai apibrėžto bruožo duomenų apimtis žymiai mažesnė už tiesiogai išreikštos formos bruožą. Tačiau nurodant konkretų paviršių procedūriniame bruože sutinkame vardinimo keblumus. Modelio kūrimo metu be kūrimo operacijų būna grįžimo atgal bei modifikacijų operacijos. Taip proceduriniame metode mes turime turėti ne vien modeliavimo topologinių ir geometrinių esinių kūrimo operacijas, bet ir jų naikinimo, modifikacijos ir užklausų operacijas. Ir visa tai gali būti naudojama aukštesnio lygio – bruožų operacijose, bet ir žemesnio lygio, kreivių, taškų ir paviršių operacijose.

Kaip žinome, pernešant produktų formą iš vienos sistemos į kitą turime geometrinio tikslumo keblumų. Pavyzdžiui, skirtingos sistemos skirtingai apibrėžia dviejų taškų tapatumo sąlygą. Todėl pernešus modelius tenka juos “gydyti”. Parametriniuose modeliuose su procedūriniais elementais reikia spresti vienareikšmiškumo uždavinį sprendžiant apribojimus, nes dauguma apribojimų yra netiesiški.

6. Baigiamosios pastabos

Šis pranešimas apžvelgia esamas ir besiformuojančias metodus ISO 10303 standarte produktų konfiguracijoje ir geometrijos pateiktyje. Galima tiketis, kad CAD duomenų saugojimas ir perdavimas gali žymiai palengvėti išvysčius minėtas besiformuojančias priemones: standartizuotus procedūriniais CAD modelius bei standartizuotą API CAD modeliavimo sistemoms.

Literatūros sąrašas [1] - Design and Modeling Advisory Council. What is OLE for design and modeling? 2000. Svetainė http://www.dmac.org [2] - International Organization for Standartization. ISO 10303:1994 - Industrial automation systems and integration – Product data representation and exchange, Part 1,Overview and fundamental principles. [3] - International Organization for Standartization. ISO 10303:1994 - Industrial automation systems and integration – Product data representation and exchange, Part 41, Integrated generic resources: Fundamentals of product description and support. [4] - International Organization for Standartization. ISO 10303:1994 - Industrial automation systems and integration – Product data representation and exchange, Part 42, Integrated generic resources: Geometric and topological representation. [5] - International Organization for Standartization. ISO 10303:1994 - Industrial automation systems and integration – Product data representation and exchange, Part 43, Integrated generic resources: Representation structures. [6] - International Organization for Standartization. ISO 10303:1994 - Industrial automation systems and integration – Product data representation and exchange, Part 44, Integrated generic resources: Product structure configuration.

VI – 14

http://www.dmac.org/

Su ISO 10303 suderinto inžinerinių duomenų valdymo klausimu

[7] M. J. Pratt, B. D. Anderson. A shape modeling applications programming interface for the STEP standard. Computer- Aided Design, 2001 ,(33), 531-543. [8 ] V. Singh, R. H. Weston. Life cycle support of manufactoring systems based on integration of tools. International Journal of Production Research, 1996, (34), 1, 1-17. [9] Ting-Kuo Peng, A. J. C. Trappey. A step toward STEP-compatible engineering data management: the data models of product structure and engineeing changes. Robotics and Computer-Integrated Manufacturing, 1998, (14), 89-109. [10] P. R. Wilson, I. D. Faux, M. C. Ostrowski, K.G. Pasquill. Interfaces for data transfer between solid modeling systems. IEEE Computer Graphics and Applications, 1985, (5), 1, 41-51.

On product data management compatible with ISO 10303.

During the product life cycle from its conceptualization, design, production, distribution to utilization many product data types and formats are used for various domains of application. Product data models compatible with ISO 10303, as product definition, product structure and shape representation, are looked over. Trends for shape representation future are looked too.

VI – 15

AGENTINIŲ TECHNOLOGIJŲ PANAUDOJIMO REIKALAVIMAI KURIANT KOMPONENTINES VERSLO, INFORMACINES IR

PROGRAMŲ SISTEMAS

Audronė Lupeikienė Matematikos ir informatikos institutas

Akademijos 4, Vilnius

Naujos kartos informacinės taip pat ir programų sistemos kuriamos kaip susietų dinamiškų komponentų, kurie funkcionuoja išskirstytuose tinkluose, visuma. Informacinėse ir programų sistemose agentinės technologijos gali būti taikomos interfeisams sukurti, sistemų aktyvumui užtikrinti, informacinėse sistemose - informacijos paieškai, duomenų analizei ir naujų žinių formavimui vykdyti, verslo ir informacinėse sistemose - problemoms spręsti, įmonių sąveikai įgyvendinti, ir pan. Darbe aptariami agentinių technologijų panaudojimo reikalavimai šiems uždaviniams spręsti.

1. Įvadas

Agentinės technologijos turi būti naudojamos kuriant komponentines verslo, informacines ir programų sistemas dėl daugelio priežasčių. Pirma, pasaulyje labai sparčiai daugėja informacijos kiekis, kuria reikia naudotis tiek įmo-nės veikloje, tiek privačiame gyvenime. Be to, ši informacija nuolat keičiasi, yra nestruktūrizuota. Antra, vis daugiau įmonių, valstybinių institucijų ir organizacijų naudojasi globaliuoju kompiuterių tinklu, todėl gali gauti informaciją skaitmeniniame ir kt. pavidale bei ją pateikti kitiems. Trečia, vis daugėja programų ir informacinių sistemų naudotojų, verslo sistemų klientų, kurie yra taip vadinami nekvalifikuoti naudotojai. Todėl jiems reikia pagalbos ir intelektualizuotų asistentų, kurie padėtų veikti vis sudėtingesnėje aplinkoje. Ketvirta, vis daugiau vykdomos kasdieninės veiklos tampa kompiuterizuota, todėl reikia naudoti technologijas, leidžiančias efektyviai kurti kompiuterizuotas sistemas.

Agentas apibrėžiamas (pvz., darbuose [1], [2], [3], [4]) kaip esybė, kuri veikia savarankiškai, vykdydama sau ir/arba kitoms esybėms reikalingas užduotis. Tačiau su tuo siejami labai įvairūs tyrimai ir jų taikymai. Skirtingose srityse yra naudojami tokie terminai kaip robotas, personalizuotas agentas (angl. personal agent), naudotojo agentas (angl. userbot), agentas-programa (angl. softbot), žiniomis grindžiamas agentas (angl. knowbot), užduotimis grin-džiamas agentas (angl. taskbot) ir kt.

Visi agentai aukščiausiame abstrakcijos lygmenyje paprastai (pvz., [5], [6]) skirstomi į tokias rūšis: agentai-žmonės, agentai-robotai ir agentai-programų sistemos. Nagrinėjant agentų elgseną, tiksliau tariant, agento veiksmus konkrečiose situacijose, galima skirti intelektualius (pvz., žmonės) ir intelektualizuotus agentus. Pagal [5] intelek-tualizuotas agentas yra toks, kuris nagrinėjamoje situacijoje pasirenka geriausią galimą veiksmą. Intelektualizuotu agentu mes vadinsime agentą, kuris yra gyvybingas adaptyvus, reaktyvus, generatyvus, gebantis analizuoti sau-gomus duomenis, siekti savo tikslų, mokytis ir asistuoti vartotojui. Kitaip tariant agentas yra intelektualizuotas, jei jis geba kuo daugiau pagelbėti naudotojui už jį atlikdamas įvairias užduotis.

Kaip buvo paminėta agentinės technologijos tiriamos ir taikomos įvairiose srityse. Pagal [2] agentinės prog-ramų sistemos kilo iš daugelio agentų sistemų, nagrinėtų išskirstytų dirbtinio intelekto sistemų kontekste apie 1970 metus. Nuo to laiko agentinės programų sistemos, jų kūrimas, agento-komponento modelis ir kiti klausimai buvo plačiai išnagrinėti. Mažiau arba iš vis nepakankamai dėmesio buvo skirta agentinių technologijų naudojimui infor-macinėse, o ypač verslo sistemose. Pavyzdžiui, informacinių sistemų enciklopedijoje [7] apie agentines techno-logijas ir jų naudojimą nieko nerašoma.

Šio darbo tikslas - išnagrinėti agentinių technologijų panaudojimo sritis programų, informacinėse ir verslo siste-mose ir nustatyti reikalavimus, kuriuos reikia suformuluoti, norint sukurti komponentines verslo, informacines ir programų sistemas.

2. Agentinių technologijų panaudojimas programų sistemose

Agentinės programų sistemos yra programų sistemos, kurios savarankiškai vykdo užduotis vartotojams. Vienas svarbiausių jų skirtumas nuo tradicinių programų sistemų yra autonomiškumas. Agentinės programų sistemos savo

VI – 16

Agentinių technologijų panaudojimo reikalavimai kuriant komponentines verslo, informacines ir programų sistemas

tikslų siekia be nurodymų ir komandų iš aplinkos. Aišku, vartotojas gali duoti komandas, užuominas ir pan., kurias agentas panaudoja savarankiškai vykdydamas užduotis.

Skiriamos kelios rūšys intelektualizuotų agentinių programų sistemų, priklausomai nuo šių sistemų aprašomųjų savybių reikšmių. Agentinės programų sistemos gali būti klasifikuojamos, atsižvelgiant į šiuos kriterijus:

• intelektualumą, • agentų kiekį, • mobilumą, • tarpusavio sąveiką.

Trumpai aptarsime šias agentinių programų sistemų klases. Intelektualumas. Skirtingos agentinės programų sistemos gali turėti įvairų intelektualumo laipsnį. Vienos sis-

temos gali pasižymėti tik viena ar keliomis intelektualumą demonstruojančiomis savybėmis, kitos - turėti visas intelektualumą nusakančias savybes. Intelektualumo laipsnis lemia agento gebėjimą autonomiškai atlikti užduotis ir naudingai sąveikauti su aplinka.

Agentų kiekis sistemoje: vieno agento sistemos ir daugelio agentų sistemos. Programų sistema gali būti įgy-vendinama sukūrus vieną arba kelis agentus. Vieno agento sistema negali kontaktuoti su kitais agentais, netgi tuo atveju, kai jos aplinkoje tie agentai funkcionuoja. Agentas gali sąveikauti tik su naudotojais arba informacijos šal-tiniais. Daugelio agentų sistemos agentai bendrauja tarpusavyje. Jie taip pat gali bendradarbiauti. Daugelio agentų sistemoje kiekvieno agento elgsena turi būti sąlygojama kokio tai šios sistemos potikslio.

Mobilumas: stacionarūs agentai ir mobilūs agentai. Mobilumas nusako agentinės programų sistemos savybę judėti kompiuterių tinkluose. Stacionarūs agentai visą laiką funkcionuoja vienoje fizinėje vietoje (pvz., kompiu-teryje). Jie nekeičia šios vietos, tačiau gali bendrauti su kitais tinkle esančiais agentais. Mobilūs agentai gali keliauti kompiuterių tinkle iš vieno kompiuterio į kitą. Mobilūs agentai - tai nutolusios programos. Mobilios programos esti dviejų rūšių - mobilūs skriptai ir mobilūs objektai. Mobilūs skriptai nusiunčiami į kitą fizinę vietą, o po to jie pradeda veikti. Mobilūs objektai gali keisti savo vietą bet kuriuo jų veikimo momentu. Tai reiškia, kad į kitą vietą turi būti perkeliama ne tik programa, bet ir jos esama būsena bei aplinka.

Agentų tarpusavio sąveika: bendradarbiaujantys ir konkuruojantys agentai. Agentų tarpusavio bendradarbia-vimas reiškia jų bendravimą arba kooperavimąsi. Siekdami gauti informacijos, agentai bendrauja su aplinka ir/arba kitais agentais. Bendravimas vykdomas pagal atitinkamą protokolą ir gali būti grindžiamas skelbimų lentos arba žinučių/dialogo naudojimu. Skelbimų lenta yra visų bendraujančių agentų bendra darbo sritis, kuria naudodamiesi jie gali keistis duomenimis, žiniomis ir kt. Skelbimų lentose gali būti talpinamos tiek užduotys, tiek gauti rezultatai. Sistemoje gali būti kelios skelbimų lentos, kuriomis naudotis agentai turi teisę tik užsiregistravę. Agentų darbas su skelbimų lenta gali būti valdomas. Tai daroma įvedant specializuotus agentus, vadinamus tarpininkais (angl. moderator) arba dispečeriais. Tarpininkas skelbia lentoje reikiamas spręsti problemas, registruoja agentus, kurie prisideda prie šių problemų sprendimo, skiria užduotis agentams. Dispečerio uždavinys yra informuoti visus skel-bimų lentoje užsiregistravusius agentus informuoti apie padarytus šioje lentoje pakeitimus.

Naudojant žinučių mechanizmą agentai gali skaityti tik jam adresuotą informaciją. Kitaip tariant, agentas, vadinamas siuntėju, perduoda žinutę konkrečiam agentui, vadinamam gavėju. Bendravimo protokolas turi nusakyti ne tik bendravimo procesą, žinučių formatą, bet ir bendravimo kalbą. O bendraujantys agentai turi žinoti šios kalbos semantiką. Žinutės, kuriomis keičiasi agentai, gali būti panaudotos agentų bendravimui ir kooperavimuisi įgyvendinti.

Agentų kooperavimasis leidžia geriau ir greičiau išspręsti sudėtingas problemas. Kita vertus, kooperavimasis naudingas patiems agentams, nes jie greičiau pasiekia savo tikslus, o kartais tie tikslai gali būti pasiekti tik kitų agentų darbo dėka. Agentų kooperavimasis - tai galimybė išskirstyti problemų sprendimą. Sudėtingos problemos skaidomos į elementarias problemas, kurias gali išspręsti atitinkami agentai. Agentai, besikooperuojantys problemai spręsti, gali pagelbėti vienas kitam dviem būdais: dalindamiesi užduotį ir dalindamiesi rezultatais. Kooperavimuisi įgyvendinti reikalingi kooperavimosi protokolas ir strategijos.

3. Agentinių technologijų panaudojimas informacinėse sistemose

Naujos kartos informacinės sistemos kuriamos kaip susietų dinamiškų komponentų, kurie funkcionuoja išskirs-tytuose tinkluose, visuma. Norint pabrėžti šį aspektą, informacinės sistemos vadinamos kooperatyviosiomis infor-macinėmis sistemomis. Informacinėse sistemose agentinės technologijos gali būti taikomos interfeisams sukurti, sistemų aktyvumui užtikrinti, taip pat informacijos paieškai vykdyti, problemoms spręsti ir kt. Trumpai aptarsime agentinių technologijų naudojimą šiems uždaviniams spręsti.

IS interfeisai. Informacinės sistemos skirtingų tipų interfeisams sukurti galima naudoti skirtingus agentus. Kitaip tariant, sukurti agentus, susietus su konkrečiomis informacinės sistemos vartotojų grupėmis. Agentas privalo

VI – 17

A.Lupeikienė

veikti ir kaip informacinės sistemos vartotojo asistentas. Kitaip tariant, jis privalo padėti priimti reikalingus spren-dimus bei atlikti tam tikras užduotis. Vartotojas gali konsultuotis su asistentu ir deleguoti jam tam tikras užduotis. Kita vertus, asistentas gali pats sufleruoti vartotojui vienus ar kitus sprendimus arba perspėti jį apie potencialiai galimas neigiamas priimamų sprendimų pasekmes. Pabrėšime, kad remiamasi prielaida, jog agentas yra mažiau iš-manantis už vartotoją. Galutinis sprendimas visada priklauso žmogui. Tuo siekiama padidinti vartotojų darbo našu-mą, o ne sumažinti jiems keliamus kvalifikacinius reikalavimus.

Naudojant agentinę technologiją informacinių sistemų interfeisams kurti, agentą galima sieti ne tik su vartotojų grupėmis, bet ir su kiekvienu konkrečiu vartotoju. Kitaip tariant, kurti personalizuotus agentus. Personalizuotas agentas privalo kaupti žinias apie vartotojo kvalifikaciją, darbo stilių bei preferencijas ir priimti sprendimus.

IS aktyvumas. Tradiciškai buvo kuriamos pasyvios informacinės sistemos, kitaip tariant, tradicinėse sistemose veiksmus inicijuodavo sistemos vartotojai arba aptarnaujantis IS personalas. Naujos kartos informacinės sistemos yra aktyvios. Tai reiškia, kad pati sistema seka situacijas, valdo įvykius ir inicijuoja reikiamus veiksmus arba infor-muoja vartotojus apie susiklosčiusią situaciją ir galimus veiksmus.

IS aktyvumas gali būti įgyvendinimas taikant agentines technologijas. Kaip buvo paminėta, vienas svarbiausių agentinių sistemų skirtumų nuo tradicinių programų sistemų yra jų autonomiškumas. Agentinės sistemos sprendžia apibrėžtus uždavinius ir siekia savo tikslų be nurodymų ir komandų iš aplinkos. IS vartotojai turi turėti galimybę specifikuoti ar keisti agento savarankiškumą. Gali būti kuriami visiškai autonomiški ir valdomi agentai.

IS aktyvumas įgyvendinamas kuriant reaguojančius, svarstančius (angl. deliberative), samprotaujančius, besi-mokančius agentus ir kitokius agentus. Paprasčiausio agento, kurį galima panaudoti IS aktyvumui užtikrinti, architektūra pateikta 1 pav.

JUTIKLIAI

MUNIPULIATORIAI

Agentas

APLINKA

Situacijosanalizė

Veiksmopasirinkimas

Taisyklės"sąlyga -

veiksmas"

1 pav. Reaguojantis agentas

Kaip parodyta 1 pav., reaguojantis agentas priima sprendimus apie veiksmų inicijavimą remdamasis informacija apie esamą situaciją. Kitokio tipo agentai inicijuoja veiksmą atsižvelgdami į istoriją (kitimo tendencijas), pasirenka veiksmą kaip samprotavimo rezultatą, suplanuoja veiksmų seką, atlieka pasekmių analizę, ir kt.

Informacijos paieška. Intelektualizuoti agentai naudojami įvairioms problemoms spręsti. Pagal probleminę sritį agentai skirstomi į informacijos paieškos, verslo transakcijų vykdymo, elektroninės prekybos tarpininkus ir pan. Greitas informacijos šaltinių kiekio augimas reikalauja kurti efektyvias informacijos paieškos priemones, siekiant padėti vartotojams surasti reikiamą informaciją. Šiandieninės informacijos paieškos mašinos (pvz., AltaVista, MetaCrawler) yra agentinės programų sistemos, kurios pasauliniame tinkle ieško reikiamos informacijos. Paprastos paieškos mašinos architektūra susideda iš keturių pagrindinių komponentų, kaip parodyta 2 pav.

Pagrindinė užklausų serverio funkcija - užtikrinti vartotojams galimybę formuluoti užklausas ir pateikti gautus rezultatus. Paieškos administratorius inicijuoja ir valdo informacijos paiešką, vykdo indeksaciją (sintaksinę išrinktų dokumentų analizę ir pasirengimą juos saugoti duomenų bazėje) ir administruoja duomenų bazę. Duomenų bazėje saugomi nuorodos į rastą informaciją ir jų indeksai. Duomenų bazėje gali būti saugomi ir patys rasti dokumentai. Svarbiausias komponentas yra informacijos paiešką vykdantys agentai. Jie turi aiškų tikslą, gali bendrauti ar kooperuotis vykdydami užduotį. Su paieškos administratoriumi agentai bendrauja tik gaudami užduotį ir pateikdami rezultatus.

Naujos kartos informacinėse sistemose agentinės technologijos turi būti naudojamos ne tik informacijos paieškai išoriniame tinkle, bet ir vidiniame įmonės tinkle. Be to, turi būti kuriamos priemonės ir žinių bei dokumentų paieškai vykdyti.

Tradiciniai (sintaksiniai) paieškos metodai, tokie kaip paieška pagal raktinį žodį ar teksto fragmentą, nėra efektyvūs. Juos taikant negalima vykdyti semantinio informacijos filtravimo, o gautas paieškos rezultatas yra per didelės apimties ir dažnai jo neįmanoma apžvelgti. Neefektyvus filtravimas taip pat sukuria papildomą apkrovimą kompiuterių tinklui. Todėl yra kuriami efektyvesni semantinės paieškos metodai ir juos realizuojančios agentinės sistemos.

VI – 18


Agentas 2

Agentas 1

Agentas n...

Paieškosadministratorius

Užklausųserveris

Užklausa

RezultatasDuomenų

bazė

2 pav. Paprastos paieškos mašinos architektūra

Duomenų analizė ir naujų žinių formavimas. Agentai gali vykdyti ne tik informacijos paiešką, bet ir duome-nų analizę bei generuoti naujas žinias. Priimant sprendimus įmonės mastu būtina naudotis visos įmonės duomenų saugyklose saugomais duomenimis, o taip pat už įmonės ribų esančiais dideliais informacijos kiekiais. Paprastai tai realizuojama kreipiantis į operatyvius analitinio apdorojimo serverius. Tačiau ne visada tokios paslaugos gali būti teikiamos atskiruose pasaulinio tinklo mazguose. Be to, ne visada serverių paslaugos, naudojami duomenų analizės ir žinių generavimo metodai pakankami priimančiajam sprendimus. Todėl įmonės informacinėje sistemoje turi būti sukurti mobilūs agentai, besinaudojantys įmonės žinių baze, savo (gal būt specialiais) žinių generavimo metodais, kt. ir pateikiantys įmonės vadovams papildomą informaciją bei žinias, gautas analizuojant didelius kiekius pasauliniame tinkle saugomų duomenų.

4. Agentinių technologijų panaudojimas verslo sistemose

Agentai yra žmonės, robotai (kitaip tariant aparatūra), programų sistemos arba bet kokios jų kombinacijos. Pa-vyzdžiui, žmogus, turintis mobilų telefoną, gali būti nagrinėjamas kai įmonės arba jos kompiuterizuotos IS agentas. Todėl nagrinėjant agentinių technologijų panaudojimą verslo sistemose, galima kalbėti ir apie tradiciniai suprantamas verslo sistemas. Kita vertus, pačias verslo sistemas galima analizuoti ir kurti kaip sąveikaujančių agen-tų sistemas. Ekonominė agentų teorija [8] įmones nagrinėja kaip savo tikslų siekiančių agentų ir kontraktų tarp jų visumą, o ne kaip unifikuotą pelno siekiantį objektą. Pagal šią teoriją įmonės savininkas samdo agentus (darbuo-tojus), kad jie vykdytų jam reikalingas užduotis, ir deleguoja jiems tam tikrus sprendimų priėmimo įgaliojimus.

Agentinių technologijų naudojimas verslo sistemose gali keisti verslo procesus, o kartu ir įmonės siekius. Pa-vyzdžiui, agentinės technologijos keičia paslaugų tiekėjų paiešką, informacijos kiekį ir kokybę sprendimams priimti, derybų su partneriais vykdymą. Šiame skyriuje nagrinėsime agentinių technologijų panaudojimą verslo sistemose, kuriose informacijos apdorojimo procesai yra kompiuterizuoti.

Įmonių sąveikos įgyvendinimas. Analizuosime dvejopą įmonių sąveiką: elektroninę prekybą ir derybų vykdy-mą bei kontraktų sudarymą. Kitaip tariant, aptarsime paminėtos veiklos įgyvendinimą taikant agentines techno-logijas. Derybos gali būti nagrinėjamos kaip savarankiška įmonių sąveikos sritis arba kaip vienas iš elektroninės prekybos etapų (šio aspekto mes detaliai nenagrinėsime).

Elektroninės prekybos vykdymo tarpininkai turi būti kuriami kaip agentinės programų sistemos. Autonomiškų, nuolat stebinčių situaciją, personalizuotų agentų ypatumai lemia tai, kad agentinė technologija labai tinka elektro-ninei prekybai realizuoti. Tam agentai turi gebėti rasti ir filtruoti informaciją, atlikti vertinimą pirkėjo/pardavėjo požiūriu, sąveikauti, esant laiko ribojimams. Agentai kaip elektroninės prekybos tarpininkai sąveikauja, pavyzdžiui, derybų stadijoje, nustatant kainą ar kitas elektroninės transakcijos savybes, mokėjimo stadijoje, vykdant atsiskaitymus už prekes ar paslaugas. Elektroninę prekybą įgyvendinantys agentai turi gebėti pasirinkti tuos sprendimus, kokių iš jų laukia asmuo, kuriam jis atstovauja, o taip pat paaiškinti savo sprendimus. Vieni iš svarbiausių agentų bendradarbiavimo protokolų yra tie, kurie nusako darbą su vieninga ontologija, finansinių transakcijų vykdymą ir jų saugumo užtikrinimą. Elektroninei prekybai vykdyti gali būti kuriamos labai skirtingos agentinės programų sistemos - nuo paprastų perkančių ar parduodančių agentų iki agentais grindžiamų prekyviečių.

Derybos yra sprendimų priėmimo būdas, kai dvi ar daugiau įmonių, asmenų ir pan. ieško galimų visiems priimtinų sprendimų. Susitarus dėl sprendimo gali būti sudaromas kontraktas. Vykdant derybas pagrindinis tikslas yra užtikrinti nepriklausančiai veikiančių ir turinčių savo tikslus agentų konstruktyvų bendradarbiavimą. Derybos yra reglamentuojamos protokolu, tačiau derybų strategija priklauso nuo kiekvieno jose dalyvaujančio agento realizacijos.

VI – 19

A.Lupeikienė

Problemų sprendimas. Kadangi agentai ne tik reaguoja į pokyčius aplinkoje, bet ir patys gali imtis iniciatyvos, svarbu, kad agentai turėtų išsamiai specifikuotą tikslą arba sudėtingą tikslų sistemą. Todėl gali būti kuriamos daugelio agentų, kartu spendžiančių sudėtingas problemas, sistemos. Toks problemos išsprendimas susideda iš šių uždavinių išsprendimo:

• sudėtingos problemos padalinimas į dalines ir atsakingų už jų išsprendimą agentų paskyrimas, • dalinių sprendinių integravimas, siekiant gauti problemos sprendimą.

5. Agentinių technologijų panaudojimo reikalavimų formulavimas

Šiame skyriuje apžvelgsime reikalavimus, kurie turi būti formuluojami naudojant agentines technologijas. Nag-rinėsime reikalavimus, kurie turi būti formuluojami nepriklausomai nuo to, kokia sistema (programų, informacinė ar verslo) bus kuriama.

Agento reikalavimai. Agento reikalavimai apima jo savybių ir gyvavimo ciklo reikalavimus. Agento savybės charakterizuoja jo autonomiškumą, aktyvumą, gebėjimą mokytis, bendradarbiauti su kitais agentais ir pan.

Agento funkciniai reikalavimai. Šie reikalavimai nusako, kokias funkcijas turi vykdyti agentai, kad būtų už-tikrintos reikiamos kuriamos sistemos funkcijos, kurioms realizuoti pasirinkta agentinė technologija. Pavyzdžiui, kuriant elektroninę prekybą įgyvendinantį IS posistemį, priklausomai nuo jo funkcijų, gali būti reikalingi pirkėjo, prekyvietės, parduodantys, perkantys ir kt. agentai. Formuluojant agento funkcinius reikalavimus, kiekvienai funkcijai turi būti nurodomi jos pradiniai duomenys, pateikiami rezultatai ir funkcijai įgyvendinti atliekami veiksmai. Turi būti specifikuojama veiksmų atlikimo tvarka ir jų vykdymo ribojimai. Ribojimai taip pat turi būti specifikuojami ir pačioms agento funkcijoms, pvz., gali būti nurodoma, kokių funkcijų negalima vykdyti lygiagrečiai.

Agento tikslų reikalavimai. Agento vykdomos funkcijos yra glaudžiai susijusios su agento tikslais. Kitaip ta-riant, iniciatyvos besiimantis agentas gali turėti savo tikslą ar sudėtingą tikslų sistemą, kuriems pasiekti jis turi gebėti vykdyti tam tikras funkcijas. Formuluojant agento tikslų reikalavimus reikia nurodyti:

• pagrindinį tikslą ir jo potikslius, • tikslo pasiekimo nustatymo metriką, • problemas, kurios gali trukdyti siekti tikslo, • problemų eliminavimo būdus.

Agentų tikslai gali būti kiekybiškai pamatuojami arba ne, t.y. kokybiniai. Reikalavimai kokybiniams tikslams neturi priminti užduočių, kitaip tariant, neturi būti formuluojami užduoties, kurią turi vykdyti agentas, reikalavimai. Pavyzdžiui, rinkti informaciją tam tikra tema, nėra pagrindinis agento tikslas, o jo funkcinis reikalavimas.

Nurodant tikslo metriką turi būti operuojama kiekybiniais terminais, tokiais kaip laikas, pelnas, apimtis ir pan., arba kokybiniais terminais, pavyzdžiui, "užtikrinti klientų pasitikėjimą teikiamos informacijos teisingumu".

Tikslai susiję su besikartojančiomis arba vienkartinėmis problemomis, apsunkinančiomis tikslų įgyvendinimą. Turi būti numatyti ne tik problemų sprendimo būdai, bet ir galimi keli jų variantai.

Agento funkcinės architektūros reikalavimai. Funkciniais architektūros reikalavimais nusakomi pagrindiniai struktūriniai elementai ir jų tarpusavio ryšiai, būtini agento tipui ir jo funkcijoms realizuoti. Agento intelektualumo reikalavimai ir agento gebėjimas vykdyti tam tikras užduotis atsispindi jo funkcinėje architektūroje.

Išskirstytos agentų sistemos architektūros reikalavimai. Šių reikalavimų tikslas - nusakyti pagrindinį projektinį sprendimą kaip bus kuriama išskirstyta sistema. Šie reikalavimai nusako būsimos sistemos struktūrinius elementus ir ryšius tarp jų. Kaip parodyta darbe [9] agentų sistemos architektūra gali būti specifikuojama nurodant įvairius abstrakcijos lygmenis.

Agentų sąveikos reikalavimai išskirstytos agentų sistemose. Agentų sąveikos reikalavimai yra šie: • sąveikos proceso reikalavimai, • informacijos, kuria keičiamasi, reikalavimai.

Kadangi agentų sąveikos procesas yra dvejopas, agentų bendravimo ir kooperavimosi reikalavimus apžvelg-sime atskirai.

Agentų bendravimui nustatyti turi būti suformuluoti reikalavimai bendravimo procedūrai, bendravimo kalbai, keitimosi žinutėmis ar dialogo vedimo protokolui. Agentų bendravimo procedūra gali būti realizuojama keliais bū-dais. Jei tai vykdoma naudojant skelbimų lentas, turi būti suformuluoti reikalavimai agentų registravimuisi naudotis skelbimų lenta. Šie reikalavimai turi nusakyti ne tik registravimosi procedūrą, bet ir užsiregistravusio agento teises. Jei agentai bendrauja keisdamiesi žinutėmis, turi būti numatyti žinučių formato ir žinučių perdavimo sistemos reikalavimai. Žinučių perdavimo sistemos reikalavimai apima identifikavimo, sujungimo ir žinučių perdavimo

VI – 20


reikalavimus. Svarbūs yra reikalavimai agentų bendravimo kalbai, kadangi visi bendraujantys agentai turės gebėti suprasti šios kalbos semantiką.

Agentų kooperavimosi reikalavimai apima kooperavimosi strategijos ir kooperavimosi protokolo reikalavimus. Plačiau naudojamų kooperavimosi strategijų pavyzdžiais gali būti derybų ir tarpininkavimo ("supiršimo") strategijos. Reikalavimai šių strategijų protokolams apima strategijų įgyvendinimo taisyklių ir agentų bendravimo reikalavimus. Kooperavimosi protokolo reikalavimai nusako užduočių skirstymo tvarką, rezultatų pateikimą, keiti-mosi informacija tvarką ir besikooperuojančių agentų roles.

Informacijos, kuria keičiamasi, reikalavimai nusako: • ontologinius susitarimus, • kuo tarpusavyje keisis agentai (užduotimis ir/ar rezultatais), • informacijos struktūrą.

Agento patikimumo reikalavimai. Šie reikalavimai nusako trikių poveikį agentų funkcionalumui ir agento gebėjimus atkurti prarastą funkcionalumą. Reikalavimai agento funkcionalumui atstatyti turi numatyti, kaip jis yra atstatomas:

• visais atvejais pats agentas turi gebėti atstatyti savo funkcionalumą, • kokius funkcionalumo pažeidimus atstato pats agentas, o kokius - sistemos kūrėjai ar aptarnaujantis

personalas. Veikiant agentų sistemai vieno agento funkcionalumo praradimas nebūtinai sutrikdo visos agentų sistemos dar-

bą. Agentų sistemos patikimumo reikalavimai formuluojami nurodant, kaip bus sprendžiama funkcionalumą praradusio agento paslaugų įgyvendinimas, keliems agentams vienu metu leidžiama prarasti funkcionalumą, leistiną agento funkcionalumo praradimo laiką ir pan.

Agento saugumo reikalavimai. Agento patikimumas glaudžiai siejasi su jo darbo saugumu. Saugumo reika-lavimai yra vieni svarbesnių naudojant agentines technologijas. Pavyzdžiui, kuriant mobiliuosius agentus, turi būti užtikrintas labai aukštas agentinės sistemos saugumo laipsnis. Agentai gauna užduotis ir konfidencialius duomenis, todėl turi būti užtikrinama, kad niekas kitas negali įtakoti agento darbo ar pasinaudoti jo turimais duomenimis. Saugumo reikalavimai apima agento ir jo naudotojo autorizavimo, duomenų kodavimo ir pan. reikalavimus. Tiek stacionarūs, tiek mobilūs agentai beveik visada naudojasi kompiuterių tinklu, todėl saugumo reikalavimai turi apimti išorinių saugumo modelių (tokių kaip ugnies sienos, duomenų perdavimo protokolo, kt.) integravimo reikalavimus. Saugumo reikalavimai yra ypač svarbūs išskirstytose agentų sistemose.

Agento diegimo reikalavimai. Agento diegimo reikalavimai numato išlaidas, reikalingas parengti agentą darbui ir gal būt apmokyti naudotojus, kuriems reikės agento teikiamų paslaugų. Šie reikalavimai turi numatyti agento instaliavimo, agento vidinių duomenų, žinių bazių užpildymo procedūras.

Agento aptarnavimo ir priežiūros reikalavimai. Agento aptarnavimas ir priežiūra turi užtikrinti, kad jis visada būtų tinkamas naudotis. Šie reikalavimai turi numatyti aptarnavimo ir priežiūros procedūrą, pagalbines užduotis, reikalingas agentų aptarnavimui ir priežiūrai.

Agento modernizavimo reikalavimai. Agento modernizavimo reikalavimai turi nustatyti jo pritaikomumą, perkeliamumą ir praplečiamumą. Agento pritaikomumas suprantamas kaip galimybė agentą pritaikyti techninės ir programinės įrangos pokyčiams, o gal būt ir naujoms funkcijoms vykdyti. Agento perkeliamumas suprantamas kaip galimybė jį perkelti į kitą techninę ir operacinę aplinką. Agento praplečiamumas nusakomas darbo sąnaudomis, rei-kalingomis išplėsti agento teikiamų paslaugų kiekį ir kokybę.

Agento adaptyvumo reikalavimai. Agentai turi gebėti adaptuotis prie besikeičiančios jų aplinkos. Besikeičianti aplinka suprantama kaip agentų komunikavimo kalbos pakeitimas, naujų rūšių agentų atsiradimas, naujų užduočių gavimas, prisitaikymas prie naujų aplinkos ribojimų ir pan. Agento adaptyvumo reikalavimai apima adaptyvaus agento architektūros, jo adaptavimosi scenarijų, adaptavimosi trukmės reikalavimus.

Iš teisinių apribojimų išplaukiantys reikalavimai. Šie reikalavimai susiję su agento funkciniais reikala-vimais. Juos formuluojant būtina atsižvelgti, ar agentai (ypač mobilieji) nepažeis įvairių šalies, kurioje veikia įmonė, ir kitų šalių, į kurių informacines sistemas gali nukeliauti agentas, įstatymų. Įmonės informacinės sistemos agentas negali viršyti tai įmonei suteiktų įgaliojimų. Formuluojant agentų reikalavimus reikia atsižvelgti į duomenų apsaugos reikalavimus, informacijos platinimo ir rinkimo būdų reglamentavimą, kt. reikalavimus, susijusius su teisiniais ribojimais.

6. Išvados

Agentinės technologijos keičia verslo sistemų modeliavimo būdus, informacinių ir programų sistemų kūrimą. Kuriant komponentines verslo, informacines ir programų sistemas agentinės technologijos turi būti taikomos programų ir informacinių sistemų interfeisams sukurti, sistemų aktyvumui užtikrinti, informacinėse sistemose -

VI – 21

A.Lupeikienė

informacijos paieškai, duomenų analizei ir naujų žinių formavimui vykdyti, verslo ir informacinėse sistemose - problemoms spręsti, įmonių sąveikai įgyvendinti. Agentinės technologijos gali turėti poveikį įmonės tikslams ir verslo procesams. Tačiau agentinių technologijų naudojimas kuriant informacines, o ypač verslo sistemas nėra išsa-miai išnagrinėtas. Modeliuojant agentinių verslo, informacinių ir programų sistemų reikalavimus tikslinga pakan-kamą dėmesį skirti agento ir jo tikslų reikalavimams, su kuriais glaudžiai susiję yra kiti šiame darbe pateikti agentų reikalavimai.

Literatūros sąrašas [1] H. S. Nwana. Software agents: an overview. Knowledge Engineering Review, 1996, Vol. 11, No. 3, pp.1-40. [2] M. Wooldridge, N. Jennings. Intelligent Agents: Theory and Practice. The Knowledge Engineering Review, 1995, Vol.

10, No. 2, pp. 115-152. [3] P. Maes. Agents that Reduce Work and Information Overload. Communications of the ACM, 1994, Vol. 37, No. 7, pp. 31-

40. [4] FIPA Abstract Architecture Specification. Foundation for Intelligent Physical Agents, Geneva, Switzerland, 2002,

paskelbta adresu: http://www.fipa.org/specs/fipa00001/SC00001L.html. [5] S. Russel, P. Norvig. Artificial Intelligence: A Modern Approach. Prentice Hall, 1995. [6] W. Brenner, R. Zarnekow, H. Wittig. Intelligent Software Agents. Springer, 1998. [7] H. Bidgoli (ed.). Encyclopedia of Information Systems. Academic Press, Vol. 1, 2, 3, 4, 2003. [8] M. Jensen, W. Meckling. Theory of the firm: managerial behaviour, agency costs, and ownership structure. Journal of

Financial Economics, 1976, Vol. 3, No. 4, pp. 305-360. [9] A. M. Ouksel. A framework for a scalable agent architecture of cooperating heterogeneous knowledge sources. M. Klusch

(ed.) Intelligent Information Agents, Springer, 1999, pp. 100-124.

Requirements for agent-based business, information and software systems

Intelligent agents transform the way we model the enterprise, build information and software systems. Intelligent information, software, etc. agents can be used for interfaces development, data mining and knowledge discovery, information search, problem solving, office work support, etc. This paper considers the requirements for agent-based business, information and software systems.

VI – 22

MOBILIŲ INFORMACINIŲ SISTEMŲ KŪRIMO YPATUMAI

Audronė Lupeikienė Matematikos ir informatikos institutas, Akademijos 4, Vilnius

Olegas Vasilecas Vilniaus Gedimino technikos universitetas, Saulėtekio 11, Vilnius

Apibrėžiant mobilios informacinės sistemos sampratą, dažnai informacinės sistemos mobilumas siejamas tik su geografinę padėtį keičiančiu naudotoju ir jo naudojama technine bei programine įranga. Taip apibrėžiant mobilią informacinę sistemą vienas svarbesnių nagrinėjamų klausimų tampa ryšio su naudotoju ir paslaugų kokybės užtikri-nimas. Kitaip tariant, kalbama apie informacines sistemas, kuriose prieigai naudojamos bevielės technologijos. Todėl taip suprantant mobilias informacines sistemas, turi būti akcentuojami tam tikrų (bevielių) technologijų panaudojimo klausimai, o ne mobilumas. Mobilumo užtikrinimas susijęs su daugelio problemų, tokių kaip mobilios informacinės sistemos architektūra, komunikavimo modelis, duomenų vaizdavimo modelis, transakcijų modelis ir kt., išsprendimu. Šio darbo tikslas - išnagrinėti mobilių informacinių sistemų sampratą ir nustatyti pagrindines jų kūrimo ypatybes.

1. Įvadas

Šiuolaikinė telekomunikacijų infrastruktūra kartu su dideliu nešiojamų kompiuterių, mobilių telefonų ir kitokių mobilių įrenginių kiekiu sudaro galimybę teikti įvairesnes informacines ir komunikavimo paslaugas naudotojams, o technologinė infrastruktūra šiuo metu yra pakankamai išvystyta, kad būtų galima ją naudoti bei vykdyti tolimesnius tyrimus. Naujų infrastruktūrų, teikiančių paslaugas aukštesnių dažnių juostos plotyje ir tokiu būdu užtikrinančių patikimesnio prisijungimo prie tinklo galimybę atsiradimas įgalina iš esmės transformuoti būdus, kuriais žmonės naudojasi informaciniais ištekliais. Ši infrastruktūra ir toliau bus plečiama. Su mobilumu susijusios paslaugos, to-kios kaip, pavyzdžiui, interaktyvioji televizija, bus vis svarbesnės ateities rinkoje, o mobilumą užtikrinančios tech-nologijos įgaus vis didesnę reikšmę.

Tradicinės informacinės sistemos (IS) grindžiamos prielaida, kad jų naudotojai nekeičia savo buvimo vietos ir kad kliento bei paslaugos tiekėjo ryšys yra fiksuotas visą jų bendravimo seansą. Šiuolaikinės informacinės sistemos skiriasi nuo tradicinių tuo, kad jos yra labiau išskirstytos, t.y. savo buvimo vietą keičia ir naudotojai, ir aparatūra, ir kitos IS komponentės. Tačiau komunikavimas su naudotojais kaip taisyklė ribojamas fizinėmis aparatūros ir duomenų perdavimo kanalų charakteristikomis.

Besiplečiančio m-verslo, be abejonės susijusio su moderniomis informacinėmis sistemomis, kurios savo ruoštu yra ir mobilios, esmė yra pasiekti užsakovus, tiekėjus ir darbuotojus, nepriklausomai nuo jų buvimo vietos ir pateikti reikalingą informaciją tinkamiems asmenims reikiamu laiku.

Verslo sistemoje naudojama informacinė sistema palaiko įmonės vykdomą veiklą, t. y. ji kuriama naudotojams jų darbams vykdyti. Modernios informacinės sistemos architektūra yra sudėtinga, ją sudaro daugelis įvairiais ryšiais susietų komponenčių. Tai techninė įranga (kompiuterių tinklai, serveriai, stacionarios darbo stotys, nešiojami asmeniniai kompiuteriai, mobilūs telefonai ir pan.), programinė įranga (operacinės sistemos, duomenų bazių valdymo sistemos, programinės įrangos mobilumui užtikrinti serveriai ir pan.) ir kitos komponentės. Apibrėžiant mobilios informacinės sistemos sampratą, labai dažnai IS mobilumas siejamas tik su geografinę padėtį keičiančiu naudotoju ir, aišku, jo naudojama technine bei programine įranga. Taip apibrėžiant mobilią informacinę sistemą vienas svarbesnių nagrinėjamų klausimų yra komunikavimo su mobiliu naudotoju užtikrinimas. Kitaip tariant, kalbama apie informacines sistemas, kuriose naudojamos bevielės komunikavimo technologijos ir turi būti užtikrinti įvairūs naudotojų interfeisai bei naudotojams reikiamos paslaugos. Tokiu būdu akcentuojamas tik tam tikrų tech-nologijų panaudojimas.

Pirmųjų mobilių informacinių sistemų paslaugos faktiškai apėmė tik apsikeitimą laiškais, pavyzdžiui, elektro-niniu paštu ar mobilių telefonų žinutėmis. Šiuo metu mobiliose informacinėse sistemose naudojamos, kliento-serverio technologijos, šios sistemos yra išskirstytos, o naudotojams užtikrinamos tokios pat paslaugos kaip ir sta-cionarių IS atveju. Tačiau kuriant mobilias informacines sistemas reikia sukurti tinkamas jų architektūras, daugelio vartotojų, naudojančių mobilius ir vis sudėtingesnės struktūros duomenis gebančius apdoroti įrenginius, tarpusavio komunikavimo modelius, duomenų vaizdavimo modelius, leidžiančius gauti skirtingo detalumo informaciją, naujus transakcijų modelius, apsaugos modelius ir pan. Šiuo metu paminėti klausimai dar nėra išsamiai išnagrinėti.

VI – 23

A.Lupeikienė, O.Vasilecas

Šio darbo tikslas - išnagrinėti mobilių informacinių sistemų sampratą, jų specifiką, nustatyti pagrindinius kūri-mo ypatumus.

2. Mobilumas kaip viena iš modernių informacinių sistemų savybių

Modernios verslo informacinės sistemos verslo sistemas palaiko teikdamos kitos kokybės paslaugas, palyginus su pirmos kartos informacinių sistemų paslaugomis. Svarbiausieji modernių verslo informacinių sistemų ypatumai yra šie:

• sistemos yra intelektualizuotos, tai reiškia, kad geba generuoti, kaupti ir pasinaudoti verslo bei kitokiomis žiniomis, sukauptomis įmonėje ir kitose žinių saugyklose, o taip pat geba mokytis;sistemos yra aktyvios, tai reiškia, kad geba reaguoti į susidariusią situaciją, inicijuoti reikiamus veiksmus;

• sistemos yra mobilios, tai reiškia, kad jos naudotojai gali naudotis sistemos paslaugomis būdami įvairiose geografinėse vietose, o taip pat ir kitų informacinės sistemos komponenčių buvimo vieta gali priklausyti nuo laiko;

• sistemos yra išskirstytos, tai reiškia, kad palaiko išskirstytų bei virtualių įmonių veiklą, kuri gali būti vykdoma skirtingose geografinėse vietose arba iš vis neribojant geografinės padėties, kas susiję su globalaus kompiuterių tinklo naudojimu;

• sistemos dirba su sudėtingos struktūros informacija, tai reiškia, kad gali saugoti, apdoroti ne tik skaitme-ninius duomenis, bet ir erdvinius duomenis, garsus, vaizdus ir kt.

Informacinių sistemų mobilumas yra viena iš modernių informacinių sistemų charakteristikų. Kitaip tariant, mobilios informacinės sistemos neturėtų būti nagrinėjamos kaip atskira informacinių sistemų rūšis. Todėl terminą ,,mobili informacinė sistema" naudosime norėdami pasakyti, kad informacinė sistema, pasižymi mobilumo savybe.

Darbe [6] mobilių informacinių sistemų ypatumai suskirstyti į keturias grupes: naudotojai, technologiniai aspektai, kūrimo metodika, saugumas ir kiti kokybės aspektai. Pirmosios grupės ypatumai susiję su mobilių infor-macinių sistemų interfeisais. Kadangi mobilių IS naudotojų ir jų naudojamų techninių priemonių rūšių gali būti daug, dėmesys turi būti kreipiamas į interfeisų sukūrimą ir tų interfeisų adaptavimą konkrečių naudotojų poreikiams. Antrajai grupei priskiriami ypatumai susiję su naudojama įvairių rūšių aparatūra ir komunikavimo su ja užtikrinimu. Mobilūs įrenginiai gali integruoti įprastų atskirų įrenginių funkcijas, turi ribotas atminties, komunikavimo ir pan. galimybes. Todėl jų veikimo reikalavimai yra svarbūs kuriant mobilias sistemas. Trečiojoje grupėje nagrinėjami mobilių IS kūrimo metodikų ypatumai. Tačiau darbe [6] pateikiami tik du pastebėjimai:

• atsižvelgiant į tai, kad mobilios IS vystosi labai greitai, projektuoti reikia taip, kad nebūtų sunku jas radikaliai modernizuoti;

• reikalingos rekomendacijos naudotojų interfeisams kurti ir standartai. Ketvirtoji grupė ypatumų apima mobilių sistemų saugumo užtikrinimą, o taip pat paslaugų prieinamumą, pati-

kimumą ir gautos informacijos darną. Darbas [6] yra apžvalginis, jame analizuojamos mobilių IS savybės ir numatomos tyrimų kryptys, spręstinos

problemos. Tačiau mobilių IS ypatybės nėra išnagrinėtos nei pakankamai išsamiai, nei pakankamai detaliai. Pagal [5] gali būti skiriamos su mobilumu ir su mobiliomis IS susijusios savybės. Darbe [4] nagrinėjami trys su mobilumu susiję aspektai: vieta, laikas ir kontekstas. Nagrinėjant mobilias IS paprastai akcentuojama naudotojo buvimo vieta. Kitų IS komponenčių buvimo vieta dažniausiai (pvz., [6], [3]) nenagrinėjama. Taip pat paprastai nenagrinėjamas IS mobilumas laiko aspektu. Pagal [6], [5], [7] kontekstą sudaro aplinka (daiktai, triukšmas, temperatūra ir pan.), asmeninės naudotojo savybės (psichologinė būsena, analitiniai sugebėjimai ir pan.), naudotojo vykdomos užduotys, socialinės ypatybės (naudotojo statusas, socialinė rolė, tų rolių keitimas ir pan.), informacijos erdvė (globali ir asmeninė informacija, kuria konkrečiu momentu galima naudotis).

Su informacinių sistemų mobilumo savybe susijusius IS ypatumus siūlome skirstyti į tokias grupes: • IS komponenčių mobilumas, • lokalizavimas ir navigavimas, • aparatūra, • komunikavimas, • paslaugos ir patogaus naudotojo darbo užtikrinimas, • apsauga, saugumas, patikimumas ir pan. IS savybės. Trumpai aptarsime šiuos ypatumus. Viena iš svarbiausių mobilių IS ypatybių yra jos komponenčių mobilumas. IS naudotojai turi galimybę dirbti,

gauti ir pateikti reikiamus duomenis nepriklausomai nuo jų buvimo vietos ir tos vietos keitimo pobūdžio.

VI – 24

Mobilių informacinių sistemų kūrimo ypatumai

Šiuolaikinėje informacinėje sistemoje naudojama aparatūra yra ne tik stacionarūs kompiuteriai, jų tinklai, bet ir mobilūs telefonai, delniniai kompiuteriai, kt., kuriuos nesunku perkelti iš vienos vietos į kitą. Bendru atveju mobilūs gali būti ir kiti IS techninės infrastruktūros elementai. Tačiau šiandieninėmis sąlygomis, pavyzdžiui, serveriai laiko-mi nemobiliais, nes jie funkcionuoja fiksuoto ryšio tinkle. Serveriai gali būti nagrinėjami kaip tarpininkai, per kuriuos mobilieji techniniai elementai sąveikauja su fiksuoto ryšio pasauliniu kompiuterių tinklu. Informacinės sis-temos duomenys gali būti saugomi tiek stacionariuose serveriuose, tiek mobiliuosiuose kompiuteriuose. Kitaip tariant, IS duomenų bazės gali būti mobilios ir turėti kitas duomenų bazių savybes (pavyzdžiui, aktyvumą [9]). IS komponenčių mobilumas reiškia, kad savo buvimo vietą gali keisti ne tik IS naudotojai, bet ir aparatūra, duomenų bazės, dalykinės programos, jų aplinkos, siekiant surinkti reikiamą informaciją ar atlikti kitus veiksmus. Apibendrin-dami pažymėsime, kad visus IS elementus galima skirstyti į dvi rūšis: mobiliuosius ir stacionarius, ir tas suskirstymas gali nuolat kisti.

Mobilumas įveda su IS elemento buvimo vieta susijusį neapibrėžtumą. Jei informacinės sistemos elementas pastoviai keičia savo buvimo vietą, svarbu turėti galimybę ją nustatyti, siekiant užtikrinti reikiamas paslaugos ir patogų naudotojo darbą. Tai reiškia, kad mobilūs IS elementai turi būti nuolat sekami ir, jei reikia, naviguojami. Siekiant užtikrinti paslaugas, reikalingas tam tikru laiku tam tikroje geografinėje vietoje esančiam naudotojui, taip pat turi būti sekami ir naviguojami verslo sistemos objektai.

Mobiliose IS dalis naudojamos aparatūros turi turėti tam tikras fizines ypatybes. Visų pirma, mobilioji aparatūra (angl. mobile units) turi galėti komunikuoti su stacionaria aparatūra naudojant bevieles technologijas. Antra, mobi-lioji aparatūra turi ribojimus: yra fiksuotas dažnių juostos plotis, ribota akumuliatorių talpa ir pan. Trečia, siekiant užtikrinti ryšį su mobilia aparatūra, IS techninėje infrastruktūroje turi funkcionuoti taip vadinamos bazinės stotys, aprūpintos specialia įranga. Šie kompiuteriai turi veikti kaip tarpininkai tarp mobilių ir stacionarių IS techninių elementų.

Mobilūs IS naudotojai gali bendrai spręsti įvairias problemas, vykdyti bendras užduotis. Todėl būtina užtikrinti jų tarpusavio komunikavimą. Be to, komunikavimas turi būti užtikrinamas ir tarp visų kitų IS mobilių komponenčių. Mobiliose IS komunikavimui tarp naudotojų naudojamos bevielės technologijos, kurios turi užtikrinti tokį pat patikimą ryšį kaip ir stacionarių naudotojų atveju.

Su naudotojo buvimo vieta ir laiko momentu susijusios paslaugos ir naudotojo navigavimas yra mobilių IS charakteringos ypatybės. Kaip buvo paminėta, turi būti naviguojami ir verslo sistemos objektai, siekiant išplėsti mobilių IS paslaugas. Tokios paslaugos sąlygoja du IS kūrimo aspektus. Pirma, mobilaus IS naudotojo aplinka turi būti nagrinėjama kaip virtuali. Kitaip tariant, kiekvienu laiko momentu gaunamas konkretus aplinkos kaip tipo egzempliorius. Su šiuo egzemplioriumi yra susiję naudotojui pateikiami duomenys. Antra, turi būti užtikrinami labai įvairūs IS interfeisai, nes naudotojai turi skirtingų rūšių mobilią aparatūrą. Be to, interfeisai dažnai turi būti individualizuoti. Tai reiškia ne tik IS interfeiso prisitaikymą prie naudotojo aparatūros, stiliaus, kt. preferencijų, bet ir galimybę interfeisą keisti pačiam naudotojui.

Mobilių sistemų saugumo problema atsirado sukūrus bevielį tinklą, nes mobilaus ryšio (telefonų pokalbių) fak-tiškai gali klausytis bet kas. Be to, patys mobilūs įrenginiai yra lengvai pavagiami, prarandami ir pan. Taip pat bevielis ryšys yra palyginti nepatikimas, ypač jei naudotojai nori būti susijungę su stacionariu serveriu ir tada, kai juda. Dauguma patikimumo aspektų bus netgi dar sudėtingesni mobiliose informacinėse sistemose nei tradicinėse verslo sistemose. Pavyzdžiui, tie patys mobilieji įrenginiai ar kompiuteriai bus dažnai naudojami kaip asmeniniai įrankiai (priklausomai nuo vartotojo) skirtinguose projektuose bei skirtingose įmonėse, ir reikės užtikrinti, kad duomenys nebūtų neleistinai naudojami. Kitas saugumo problemos aspektas - tai vartotojo kontrolė per taip vadinamus pėdsakus, kuriuos jis palieka, kai naudojasi nuo vietos priklausančiomis ar kitomis kontekstinėmis pa-slaugomis.

Apibendrinant pastebėsime, kad mobilios IS gali būti nagrinėjamos kaip viena iš išskirstytų IS rūšių, kuriose dinamiškai keičiasi ryšiai tarp IS sistemos komponenčių ar jų dalių.

Atkreipsime dėmesį, kad kalbant apie mobilias informacines sistemas, nagrinėjamos bevielės komunikavimo technologijos ir su jomis susijusios teikiamos paslaugos. Bendru atveju tai gali išplėsti įmonėse sprendžiamų problemų ir informacijos apdorojimo procesų kiekį. Tačiau, kaip pastebėta darbe [8], mobilios informacinės sistemos neturi būti nauju lozungu ar kitokiu spekuliavimu, kai, pavyzdžiui, vietoje technologijos ypatybių nagrinėjimo skelbiamas naujos verslo sistemų rūšies atsiradimas.

Informacinė sistema yra verslo sistemos posistemis [2]. Todėl, aišku, IS funkcijos susijusios su verslo sistema, informacinės sistemos ypatybės priklauso nuo verslo sistemos ypatybių, o informacinė sistema gali turėti įtaką verslui. Šiandien vis dažniau kuriamos virtualios verslo sistemos. Virtualias verslo sistemas palaikančios informa-cinės sistemos yra išskirstytos ir gal būt mobilios. Mobilumo savybė reikalinga, kai verslo sistemoje sprendžiami šie uždaviniai:

• resursų valdymas ir apskaita, • projektų valdymas virtualioje verslo sistemoje,

VI – 25


• sprendimų priėmimas. Šiandieninės įmonės gali būti nesiejamos su konkrečia fizine vieta. Virtuali įmonė kuria ir pateikia produktus ar

paslaugas neribodama fizinės buvimo vietos ir neturėdama griežtos tradicinės organizacinės struktūros. Pavyzdžiui, įmonės produkcijos pardavimą gali vykdyti mobilūs pardavėjai, jei jie turi galimybę bet kuriuo momentu sužinoti, ar reikiama prekė yra įmonės sandėlyje. Taigi, IS turi turėti mobilumo savybę, jei verslo sistemoje vykdomas pirkimų, pardavimų ir atsargų kaupimo valdymas ir apskaita.

Funkcinės mobilių IS galimybės turi apimti projektų valdymą virtualioje verslo sistemoje. Jei darbuotojai dirba skirtingose vietose, mobilūs inspektoriai, vietiniai vadovai gali padėti projekto vadovui operatyviai sudaryti darbo grafikus, darbų vykdymo suvestines.

Įmonių vadovai pakankamai daug laiko praleidžia ne savo darbo vietose, todėl IS turi užtikrinti paslaugas keliaujantiems vadovams. Pagal [3], vadovui asistuojančios IS turi užtikrinti reikiamos informacijos gavimą ir jos analizę, komunikavimą su bendradarbiais, sprendimų darymą. Kad galėtų priimti sprendimus, mobiliems vadovams turi būti pateikiama detali ir apibendrinta informacija, ir, aišku, reikiamu laiku reikiamoje vietoje.

3. Mobilių informacinių sistemų kūrimas

Su informacinių sistemų mobilumo savybe susiję ir šią savybę realizuoti įgalinančios technologijos sparčiai vystosi. Mobiliųjų IS naudotojų rūšys, jų techninės galimybės nuolat keičiasi, todėl kuriant mobilias IS svarbu į tai atsižvelgti. Kitaip tariant, projektiniai sprendimai neturi ribotis tik tuo metu naudojamomis technologijomis. Jie turi numatyti galimybę tas technologijas pakeisti. Kaip pastebėta darbe [6], mobilios IS turi būti kuriamos taip, kad nereikėtų jų iš naujo projektuoti ir nereikėtų daug sąnaudų joms modernizuoti.

Pasiūlyta keletas skirtingų informacinių sistemų projektavimo metodikų (pvz., [10], [11]). Metodikos grin-džiamos skirtingomis informacinių sistemų ontologijomis, tačiau jos visos informacines sistemas modeliuoja keliais abstrakcijos lygmenimis: reikalavimų (koncepcinis), projektinių sprendimų (projektinis) ir tų sprendimų įgyvendi-nimo būdo (realizacinis). Pats svarbiausias projektinis sprendimas yra kuriamos sistemos architektūros pasirinkimas ([1]), nes nuo to priklauso būsimos sistemos savybės. Todėl kuriant informacinę sistemą, kuri turi turėti mobilumo savybę, svarbu pasirinkti tinkamo stiliaus architektūrą. Šis pasirinkimas lemia, ar visos reikiamos mobilios IS savybės bus užtikrinamos ir ar iš viso bus įmanoma sukurti tokią sistemą.

Vieta_a

Agentas 1

Agentas 2

Agentų sistema _ 2

Agentas 3

Agentas 2

Agentų sistema _ 1

Vieta_bVieta_c

bendravimas

persikėlimas

Vieta_d

1 pav. Agentinio stiliaus architektūros pavyzdys

Agentinio stiliaus architektūra yra vienas iš architektūrų stilių, kuris gali būti naudojamas mobilioms informa-cinėms sistemoms projektuoti. Pagal [1], architektūros stilius aprašomas išvardijant to stiliaus komponentų tipus, jungtis, konstrukcijas ir ribojimus. Agentinio stiliaus architektūroje naudojami primityvai yra įvairių tipų agentai. Sistemoms konstruoti naudojamos jungtys - reikalavimai atlikti operacijas ir įvykių interfeisai. Vienos agentų opera-cijos kviečiamos pareikalavus jas atlikti, kitos kviečiamos įvykus numatytiems įvykiams. Naudojant konstrukcijas galima sukonstruoti daugelio agentų sistemą ar agentų bendruomenę. Daugelio agentų sistemą sudaro autonomiškų arba pusiau autonomiškų agentų grupė, kurie sąveikauja tarpusavyje, kad atliktų tam tikrą užduotį ar pasiektų nustatytus tikslus. Daugelio agentų sistemoje agentai gali bendrauti arba kooperuotis tarpusavyje, jų veikla gali būti koordinuojama. Dažnai daugelio agentų sistema yra konstruojama atsižvelgiant į užduotį, kurią reikia įvykdyti. Daugelio agentų sistema kartais vadinama agentūra (angl. agency). Pagal [13] daugelio agentų sistema gali būti nagrinėjama kaip skaičiavimus vykdanti įmonė. Kitaip tariant galima taikyti įmonės metaforą. Kita daugelio agentų sudėtinga konstrukcija - agentų bendruomenė. Agentų bendruomenė gali būti atvira (agentai laisvai įsijungia ir pasitraukia iš bendruomenės), pusiau atvira (agentai negali pasitraukti) ir uždara (bendruomenės nariai yra fiksuoti). Agentų bendruomenė gali turėti įvairią organizacinę struktūrą. Pavyzdžiui, hierarchinėje agentų bendruomenėje

VI – 26

Mobilių informacinių sistemų kūrimo ypatumai

agentų tarpusavio bendravimas yra ribojamas fiksuotais kanalais. Agentų rūšių skaičius bendruomenėje charak-terizuoja ją kaip homogeninę arba heterogeninę. Agentų bendruomenės struktūra gali būti statinė arba kisti laike. Dinaminėje agentų bendruomenėje jų struktūra ir tarpusavio sąveika gali keistis. Agentinio stiliaus architektūros pavyzdys pateiktas 1 pav.

Agentai gali būti įvairių tipų. Jie klasifikuojami pagal elgseną, sprendžiamas problemas, gebėjimą keistis. Agentinės sistemos gali būti klasifikuojamos, atsižvelgiant į šiuos kriterijus:

• agentų intelektualumą, • agentų mobilumą, • agentų kiekį, • tarpusavio sąveiką. Mobilumas nusako agento savybę keisti savo buvimo vietą. Stacionarūs agentai visą laiką funkcionuoja vienoje

fizinėje vietoje (pvz., kompiuteryje). Jie nekeičia šios vietos, tačiau gali bendrauti su kitais agentais. Mobilūs agentai gali keliauti iš vienos vietos į kitą. Mobilūs agentai - tai nutolusios programos, sistemos, naudotojai ir pan.

Mobilus agentas yra į tam tikrą veiklą įtrauktas subjektas. Jis gali keisti savo buvimo vietą, nors tai gali ir nie-kada neatsitikti per jo gyvavimo ciklą. Kaip buvo pažymėta juo gali būti žmogus, programos, aparatūra arba bet kokia šių elementų kombinacija. Asmuo, turintis mobilų telefoną su jo operacine sistema, gali būti mobilus infor-macinės sistemos agentas. Kuriant mobilias IS turi būti naudojami tiek mobilūs, tiek stacionarūs agentai. Trumpai aptarsime mobilaus agento architektūrą.

Pagal [12], mobilus agentas aprašomas šiais elementais: • agento gyvavimo ciklo modeliu, • skaičiavimo modeliu, • komunikavimo modeliu, • navigavimo modeliu, • apsaugos modeliu. Pastebėsime, kad agentui nusakyti taip pat turi būti sukurtas agento modelis. Agento modelis turi nusakyti jo

savybes: autonomiškumą, aktyvumą, adaptyvumą, gebėjimą mokytis ir pan. Mobilaus agento gyvavimo ciklo modelis apibrėžia agento galimas būsenas ir įvykius, kurie sąlygoja perėjimą iš vienos būsenos į kitą. Specifikuojant mobilų agentą turi būti nusakoma agento veikimo semantika, arba, kitaip tariant, nusakomas skaičiavimo modelis. Skaičiavimai vykdomi tam tikroje aplinkoje, jiems realizuoti reikalingas procesorius. Mobilūs agentai bus mažai naudingi, jei jie nesugebės bendrauti ar kitaip sąveikauti su kitais agentais. Komunikavimo modelis aprašo agentų bendravimo mechanizmą ir bendravimo protokolą. Navigavimo modelis susijęs su agento mobilumo savybe. Agentui keičiant buvimo vietą reikia nustatyti, kur jis yra ir kur gali persikelti kitu žingsniu. Komunikavimo modelis specifikuoja įvardijimo susitarimus, duomenų iš nutolusių vietų gavimą, agento persikėlimą, agento perkėlimą į arba iš nutolusios fizinės vietos. Mobilaus agento apsaugos modelis apima du aspektus: agento ir serverio, į kurį agentas gali persikelti, apsaugojimą nuo piktavališkų veiksmų.

4. Išvados

Šiame darbe parodyta, kad mobilių informacinių sistemų ypatybės yra susiję su IS komponenčių mobilumu, lokalizavimu ir navigavimu, naudojama įranga, komunikavimu, paslaugų ir patogaus naudotojo darbo užtikrinimu, apsauga, patikimumu.

Informacinių sistemų mobilumas yra viena iš modernių IS savybių. Mobili informacinė sistema gali būti nagri-nėjama kaip išskirstytų informacinių sistemų rūšis, kai dinamiškai keičiasi ryšiai tarp IS komponenčių ar jų sudėtinių dalių. IS komponenčių mobilumas bendru atveju taip pat yra dinamiška tų komponenčių savybė.

Mobilios informacinės sistemos turi būti kuriamos taip, kad nebūtų sunku jas radikaliai modernizuoti. Mobi-lioms informacinėms sistemoms kurti gali būti naudojama agentinio stiliaus architektūra.

Literatūros sąrašas [1] A. Čaplinskas. Programų sistemų inžinerijos pagrindai. 1998, 2 dalis, Matematikos ir informatikos institutas. [2] A. Caplinskas, A. Lupeikiene, O. Vasilecas. Unified Enterprise Engineering Environment: Ontological Point of View. In:

H.-M. Haav, A. Kalja (eds.). Databases and Information Systems, Proc. of the Fifth International Baltic Conference BalticDB&IS'2002, Tallinn, June 3-6, 2002, vol. 1, Tallinn, pp. 39-50.

VI – 27


[3] N. O’Donoghue, S. Puuronen, V. Savolainen. Executives’ Mobile Personal Information Systems. Information and Communication View. Studies in Informatics and Control, 1997, Vol. 6, No. 2, pp. 145-161. Paskelbta adresu: http://www.ici.ro/ici/revista/sic97_2/vesa1.html

[4] M. Kakihara, C. Sorensen. Mobility reconsidered: topological aspects of interaction. S. Bjornestad, R. Moe, A. Morch, A. Opdahl (eds.). Prceedings of the 24th Information Systems Research Seminar in Scandinavia, Bergen, Norway, August 11-14, 2001.

[5] J. Krogstie. Requirements engineering for mobile information systems. Proceedings of the Seventh International Workshop on Requirements Engineering: Foundation for Software Quality REFSQ'2001, June 4-5, Interlaken, Switzerland, 2001. Paskelbta adresu: http://www.ifi.uib.no/conf/refsq2001/papers/p6.pdf.

[6] J. Krogstie, K. Lyytinen, A. Opdahl, B. Pernici, K. Siau, K. Smolander. Mobile information systems - research challenges on the conceptual and logical level. Proceedings of the International Workshop on Conceptual Modeling Approaches to Mobile Information Systems Development MobIMod'02, Tampere, Finland, October 7-11, 2002, pp. 1-12.

[7] K. Lyytinen, Y. Yoo. The next wave of nomadic computing: a research agenda for information systems research. Sprouts: Working Papers on Information Environments, Systems and Organisations, 2001, Vol. 1, Summer. Paskelbta adresu: http://weatherhead.cwru.edu/sprouts/2001/010301.pdf.

[8] H. Lehmann, F. Lehner. The Next E will be M - but M-What? Making sense of mobile applications - a critical note. Proceedings of the Sixth Pacific Asia Conference on Information Systems PACIS-2002, September 2-4, Tokyo, Japan, 2002.

[9] Y. Saygin, O. Ulusoy, A. Yazici. Dealing with fuzziness in active mobile database systems. Information Sciences, 1999, Vol 120, No. 1-4, pp. 23-44.

[10] A. -W. Scheer. ARIS - Business Process Frameworks. Springer, 1998. [11] F. Sowa, J. A. Zachman. Extending and formalizing the framework for information systems architecture. IBM System

Journal, 1992, Vol. 31, No. 3, pp. 590-619. [12] S. G. Woods, M. Barbacci. Architectural Evaluation of Collaborative Agent-Based Systems. 1999, Technical Report

CMU/SEI-99-TR-025, Software Engineering Institute. Paskelbta adresu: http://www.sei.cmu.edu/publications/documents/99.reports/99tr025/99tr025abstract.html

[13] F. Zambonelli, N. R. Jennings, M. Wooldridge. Organizational abstractions for the analysis and design of multi-agent systems. P. Ciancarini, M. J. Wooldridge (eds.). Agent - Oriented Software Engineering, 2001, Springer, pp. 235-251.

Mobile information systems development issues

Information system mobility is one of the features of modern information system. This paper examines characteristics that distinguish mobile information system from its traditional counterpart. The paper discusses the possible approaches and agent style architecture for mobile information system development.

VI – 28

MOCURIS PROJEKTO MOKYMO MEDŽIAGOS PATEIKTIES MODELIS, NAUDOJANTIS RELIACINES IR XML TECHNOLOGIJAS

Kristina Lapin, Vilniaus universitetas, Naugarduko 24, LT-2600 Vilnius, [email protected]

Algis Saulis, Olegas Vasilecas Vilniaus Gedimino technikos universitetas, Saulėtekio al. 11, LT-2040 Vilnius,

[email protected], [email protected]

Darbe nagrinėjamos magistrų lygio informacinių sistemų studijų programos (MOCURIS projektas) ruošimo efek-tyvumo didinimo ir pateikties problemos. Aptariami įvairūs programos rengimo ir realizacijos aspektai. Siūlomas pateikties modelis, įgalinantis kurti ir tobulinti studijų modulius. Modelis pasižymi lankstumu, jis atskiria modulio turinį ir vaizdavimą. Jame be įprasto statinio studijų programos pateikimo numatytas ir dokumentų dinaminis gene-ravimas. Nagrinėjami užklausų efektyvumo klausimai. Apžvelgiamas studijų modulių ruošimo procesas ir naudojamos technologijos. Akcentuojama XML technologija, kuri įgalina lanksčiai publikuoti duomenis įvairiais formatais. Apta-riama duomenų transformacija iš reliacinės DB į XML dokumentą, šios transformacijos realizacija ir jos alternatyvos. Aprašyti reikalavimai DB struktūrai ir realizacijos architektūrai. Studijų programos pateikties modelio kūrimas yra remiamas Europos Komisijos Socrates/Erasmus programos2.

1. Įvadas

Informacinės visuomenės plėtra keičia visuomenę, ekonomiką bei formuoja naują požiūrį į mokslą ir studijas. Vystantis distanciniam mokymui, tradicinis modelis, kai studijų programa yra priskiriama konkrečiam fakultetui ar katedrai, nestimuliuoja jos kaitos. Studijų programa turi dinamiškai prisitaikyti prie rinkos poreikių, jos atnaujinimas turi būti atliekamas nuolat be biurokratinių suvaržymų.

Atsižvelgdamos į augantį informacinių technologijų specialistų poreikį, visos aukštosios mokyklos kuria naujas studijų programas. Būsimas studentas, sąmoningai pasirenkantis tam tikrą specialybę, dažnai pritrūksta informacijos apie konkrečių aukštųjų mokyklų studijų programų sandarą ir dalykų turinį. Toliau vieno dalyko sandara ir turinys yra vadinami moduliu.

Aukštosios mokyklos realizuoja vieną arba keletą specializacijų. Pastarųjų struktūra yra nelanksti, o pasirin-kimas yra nepakankamas. Dažnai trūksta informacijos, kokios specializacijos žinias įgys tam tikros specialybės absolventas. Modulių pateikties lankstumas reikalauja nustatyti pagrindines naudotojų grupes [5]. Atsižvelgiant į MOCURIS projekto ir tradicinius universiteto poreikius, yra išskiriami keturi naudotojų tipai:

• besirenkantis studijų programą studentas, • modulio rengėjas, • modulio recenzentas, • studijų programos rengimo koordinatorius (studijų komiteto pirmininkas arba MOCURIS projekto koor-

dinatorius). Kurdamas naują arba atnaujindamas turimą, modulio rengėjas pateikia paruoštą darbinį aprašą recenzentui.

Atsižvelgus į recenzento pastabas, aprašas yra tobulinamas. Kai modulio rengėjas ir recenzentas sutaria, kad turinys yra pakankamai brandus, modulis yra pateikiamas koordinatoriui. Tik tuomet modulio galutinė versija yra talpinama į duomenų bazę.

Aukšta modulių kokybė pasiekiama, kai jų rengime dalyvauja geriausi atitinkamos dalykinės srities žinovai. Rengti ir recenzuoti modulius nebūtinai turi vienos organizacijos darbuotojai, todėl modulių darbinės versijos turėtų būti pateikiamos Internete. Projekte yra kuriamos grupės iš kelių institucijų darbuotojų. Vadinasi, studijų programai parengti, reikalingas nuotolinis darbo organizavimas ir koordinavimas.

2 MOCURIS-modern curriculum in information systems at master level, SOCRATES/ERASMUS project, contract number

69077-IC-1-98-1-LT-ERASMUS-CDA-2

VI – 29

mailto:[email protected]

mailto:[email protected]

K.Lapin, A.Saulis, O.Vasilecas

Modulio aprašas turi nusistovėjusią struktūrą, kuri yra skirtinga įvairiuose universitetuose. MOCURIS projekte taip pat buvo sukurta išsami modulio aprašo struktūra. Tokiems dokumentams tinka struktūrinių dokumentų apdo-rojimo priemonės, skirtos analizuoti struktūrą bei pateikti dokumentą, atsižvelgiant į naudotojo poreikius. Modulių pateikties formato lankstumą užtikrina XSL transformacijos [7].

Studijų programa turi būti analizuojama, nes nuolat atnaujinant modulius, giminingose moduliuose gali atsirasti pasikartojančių temų. Modulių analizei galėtų būti naudojama reliacinių duomenų bazių technologija, nes šiuo metu tai yra labiausiai ištobulintas, efektyvus, greitas ir patogus duomenų saugojimo ir apdorojimo metodas. XML tech-nologijos papildo šį potencialą mechanizmais, reikalingais šiuos duomenis lanksčiai publikuoti įvairiais formatais.

Publikuojant reliacinius duomenis, naudojantis XML technologijomis, atsiranda du reikalavimai [10]. Pirmas, reikalinga kalba, skirta duomenų konversijai iš reliacinės bazės į XML dokumentą. Antras, reikalinga efektyvi šios transformacijos realizacija. Kalbos specifikacijoje turėtų būti aprašoma, kaip struktūrizuoti ir žymėti elementus iš vienos arba kelių reliacinių lentelių į hierarchinį XML dokumentą. Pasirenkant duomenų bazių valdymo sistemą, turi būti atsižvelgta į galimybę patenkinti šiuos reikalavimus.

Trečiame skyriuje yra nagrinėjamos XML technologijos. Ketvirtame skyriuje yra aptariamos realizacijos alter-natyvos. Penktame skyriuje pristatomas konkretus modulių saugojimo variantas ir reliacinės duomenų bazės struk-tūra. Šeštame skyriuje aprašoma realizacijos architektūra. Pabaigoje yra pateikiamos išvados ir trumpai aptariami tolimesni planai.

2. Studijų programų rengimo projektas

Studijų programą galima nagrinėti dviem aspektais - rengimo ir realizacijos. Vieną vertus, studijų programa - tai kursų visuma. Rengiant studijų programą, giminingų sričių dalykai yra ap-

jungiami į kursus, o kursai susideda iš atskirų modulių. 1 pav. vaizduoja programos rengimą administravimo aspektu.

Studijų programa

Kursai

Moduliai

Rengimo grupė

Darbo grupė

Nariai: rengėjai, recenzentai

1 pav. Studijų programos rengimo administravimas

Kiekvieną kursą kuruoja darbo grupė. Pastarosios nariai ruošia ir recenzuoja rengiamus modulius. Informacinių sistemų (IS) studijų programa apima 5 kursus [2], būtent: teorinių pagrindų, sudėtingesnių IS aspektų, IS inžinerijos, IS projektų valdymo ir etikos, mokslinių tyrimų bei filosofijos problemų.

Visų kursų moduliai turi būti pritaikomi specialybių poreikiams. Situacija, kai tas pats modulis yra dėstomas kelių fakultetų studentams, remiantis šia schema yra nepriimtina. Tai yra svarbus nagrinėjamos schemos apri-bojimas.

Kitą vertus, studijų programa - tai specializacijų visuma. Studijų programa yra realizuojama, dėstant svarbius tam tikrai specializacijai mokymo dalykus. Konkretus universitetas realizuoja vieną arba daugiau specializacijų. 2 pav. vaizduoja studijų programos realizavimo aspektą. Specializacija apima po vieną arba kelis modulius iš kiekvieno kurso, atsižvelgiant į konkrečios specialybės poreikius.

S tud ijų p rogram a

S pecia lizacijos

M oduliai

K ursai

2 pav. Studijų programos realizavimas

VI – 30

MOCURIS projekto mokymo medžiagos pateikties modelis, naudojantis reliacines ir XML technologijas

Informacinių sistemų pakraipa apima visą eilę specializacijų [2], kaip antai verslo informacinių sistemų inžinierius (angl. Business IS engineer), techninių informacinių sistemų inžinierius (angl. Technical IS engineer), žinių inžinierius (angl. Knowledge engineer), duomenų valdytojus (angl. Data manager), sistemų integruotojus (angl. Systems integrator), verslo sistemų analitikus (angl. Systems (business) analyst), informacinių sistemų konsultantus (angl. IS consultant), projektų vadovus (angl. Project manager), vyriausius informacijos valdytojus (angl. Chief information officer), elektroninio verslo sistemų specialistus (angl. E-business systems specialist) bei akademinę pakraipą, skirtą būsimiems doktorantūros studentams.

Pateiksime vienos iš specializacijų [3], būtent verslo IS inžinieriaus , kursų ir modulių struktūrą: • teoriniai pagrindai: matematinė logika, algoritmų teorija, operacijų tyrimas, matematinis modeliavimas; • sudėtingesni IS aspektai: šiuolaikinės IS, papildomi duomenų bazių sistemų skyriai, dokumentų valdymo

sistemos, dirbtinis intelektas; • IS inžinerija: sistemų inžinerija, IS inžinerija, duomenų inžinerija, procesų inžinerija, papildomi programų

sistemų inžinerijos skyriai, agentinės technologijos, tinklų inžinerija, IS realizacijos metodai; • mokslinių tyrimų bei filosofijos problemos: mokslinių tyrimų principai ir metodai, save tvarkančių sistemų

filosofijos principai, minties filosofija, IS etika, informacijos ir žinių filosofiniai aspektai. • Pristatomas studijų programos pateikties modelis labiau atspindi rengimo aspektą. Studijų programos

realizavimo aspektas yra numatomas realizuoti ateityje.

3. XML aprašai

Plečiama žymenų kalba XML yra hierarchinis formatas, skirtas keistis informacija Internete. Tai nėra nauja programavimo kalba, o formatas, skirtas informacijos struktūrizavimui. Vienareikšmiškas duomenų struktūros aprašas leidžia tiek vaizdžiai pavaizduoti informaciją naršyklėje, tiek kurti programinius taikymus. XML technologijų šeima - tai augantis modulių skaičius, skirtas teikti paslaugas. XML dokumentą sudaro jo sudedamųjų elementų struktūra. Kiekvieną elementą atitinka žymuo. Elementai gali turėti atributus ir reikšmes arba susideda iš žemesnio lygio elementų. XML aprašas naudojamas tiek griežtos struktūros dokumentams, tiek pusiau struktūrizuotiems dokumentams. Modulio aprašas turi nusistovėjusią struktūrą, todėl galima sudaryti Dokumento tipo apibrėžtį (angl. Document Type Definition, DTD). Toliau taikyme jis bus naudojamas dokumento sintaksiniam ir semantiniam teisingumui tikrinti. Sintaksiškai teisingas (angl. well-formed) dokumentas atitinka XML specifikaciją. Semantiškai teisingas dokumentas (angl. valid) dar turi atitikti DTD. 3 pav. parodytas modulio DTD fragmentas, aprašantis pagrindines modulio sudedamąsias dalis.

Šiame fragmente nurodomi modulio aprašo elementai: kurso, kuriam priklauso modulis, pavadinimas, modulio pavadinimas, raktiniai žodžiai, modulio filosofijos, tikslų, būtinų sąlygų, turinio, dėstymo metodikos, literatūros sąrašai. Taip pat nurodomi moduliai, kuriuos būtina išklausyti prieš aprašomą modulį; Be įprastų modulio sudedamųjų dalių svarbus yra modulio realizavimo kontekstas, kurį nusako reikalingi resursai (patalpų, programinės ir techninės įrangos), parengimo ir atnaujinimo terminai, modulio autorius ir recenzentas. Dokumento aplinkos arba konteksto svarba dokumento struktūros analizei yra nagrinėjama [8].

<!DOCTYPE module[ <!ELEMENT module (course, title, keywords, philosophy, objectives, prerequisites, content, teaching_considerations, bibliography, resources*, deadline*, author, reviewer)> <!ATTLIST module m_id ID #IMPLIED> <!ELEMENT course (#PCDATA)> <!ATTLIST course c_id IDREF #FIXED> <!ELEMENT title (#PCDATA)> <!ELEMENT keywords (keyword)+> (…) ]>

3 pav. Modulio aprašo dokumento tipo apibrėžties fragmentas

Elementas modulyje turi nebūtiną atributą m_id. Reikšmė jam yra priskiriama įvedant dokumentą į duomenų bazę. Atnaujinant modulį, jis yra identifikuojamas, naudojantis jau žinoma atributo reikšme. Elementas course turi nuorodą į kurso unikalų numerį. Kadangi modulis gali priklausyti vienam kursui, tai viename modulio dokumente nuoroda yra viena ir galioja iki dokumento pabaigos. Vadinasi, šio atributo savybė turėtų būti #FIXED. 4 pav. parodytas XML dokumento fragmentas, atitinkantis anksčiau pateiktam modulio DTD.

VI – 31


<?xml version="1.0" ?> <!DOCTYPE module SYSTEM "module.dtd"> <module> <course c_id=”2”> Advanced Concepts of Information Systems </course> <title> Document Management Systems </title> <keywords> <keyword> document </keyword> <keyword> repository </keyword> <keyword> conversion </keyword> <keyword> indexing </keyword> <keyword> searching </keyword> (…) </keywords> (…) </module>

4 pav. Konkretaus modulio XML dokumento fragmentas

4. Realizacijos alternatyvos

Pasirenkant realizacijos sprendimą, yra galimi du variantai: modulius saugoti reliacinėje duomenų bazėje arba XML dokumentų bazėje.

Pirmuoju atveju, modulio elementai yra talpinami reliacinėse lentelėse. Dauguma elementų modulyje pasi-kartoja, todėl jie turi būti saugomi atskirose lentelėse. Šiuo atveju, modulių skaičius gali augti beveik neribotai, apdorojimo efektyvumui tai beveik neatsiliepia. Modulio turinys gali būti analizuojamas įvairiais aspektais. Pavyzdžiui, galima nustatyti, kuriuose moduliuose yra nagrinėjama tam tikra sąvoka, suformuoti literatūros sąrašą, būtiną tam tikram kursui, analizuoti tvarkaraščius. 5 pav. vaizduoja šį rengimo modelį.

Pastarasis būdas turi ir trūkumų. Vyksta daug dokumento formatų transformavimo operacijų keliant jį į duomenų bazę ir traukiant iš jos. Modulių rengimui naudojama griežtai apibrėžta struktūra. Realizuojant studijų programą konkrečiame universitete, modulio struktūra gali keistis, nes turi atitikti universitete galiojančiai tvarkai. Tokiu atveju keisis duomenų bazės struktūra ir dokumentų transformavimo aparatą teks derinti prie naujų sąlygų.

Modulioaprašas

ReliacinėDB

XMLdoku -mentas

Spasdinimovariantas

Tinklalapiui

Trumpa žinutė

5 pav. Studijų programos kūrimo modelis, naudojantis reliacinę duomenų bazę

Publikuojant reliacinius duomenis, naudojantis XML dokumentais, atsiranda du reikalavimai. Pirmas yra kalba, kuria bus aprašoma transformacija iš reliacinių duomenų į XML dokumentą. Naujausių versijų DBVS, kaip antai MS SQL Server 2000, yra įdiegta užklausos rezultatų išvestis XML formatu. Užklausos rezultatas turi plokščią struktūrą, todėl ji yra toliau apdorojama, naudojantis XSL transformacijomis. Rezultatas - hierarchinis XML doku-mentas, kuris vėliau transformuojamas į formatą, atitinkantį naudotojų poreikius. Taigi, antras reikalavimas - tai efektyvi taikomoji programa, realizuojanti užklausos rezultatų pateikimą naudotojui.

Antruoju atveju, tai yra saugant modulius XML dokumentuose, modulių analizė nebus tokia greita ir efektyvi, kaip reliacinėje bazėje, ypač augant modulių skaičiui. Tačiau čia išvengiama transformavimo iš XML į reliacinę bazę ir atgal, iš reliacinių duomenų į XML formatą. 6 pav. vaizduoja tokį saugojimo būdą.

Modulioaprašas

XMLdokumentas

Spausdinimovariantas

Tinklalapiui

Trumpa žinutė

6 pav. Studijų programos kūrimo modelis, naudojantis XML dokumentų bazę

VI – 32


Pastarasis modelis nėra jautrus modulių struktūros pokyčiams. Jame gali būti saugomi ne itin griežtos struktūros dokumentai. Dokumentų analizei, užklausų vykdymui yra kuriamos užklausų kalbos, pavyzdžiui, Xquery. Siūlomi įvairūs užklausų realizacijos metodai [9]. Interaktyvių tinklalapių kūrimas taip pat yra nagrinėjamas [1], [6] darbuose.

Renkantis tinkamą variantą, reiktų įvertinti, kiek svarbi yra modulių analizė, reikalaujamas užklausų vykdymo greitis ir jų kiekis, planuojamas modulių skaičius, modulių struktūros pokyčių galimybės ir keitimo dažnis. Rengiant studijų programą, svarbūs yra darbo koordinavimo ir modulių analizės aspektai. Modulio struktūra projekte yra determinuota, jos keitimas nėra numatomas. Remiantis šiomis prielaidomis, realizacijai buvo pasirinktas pirmas modulių saugojimo būdas, būtent reliacinė duomenų bazė. Lygiagrečiai numatoma realizuoti ir antrąjį variantą bei įvertinti abiejų modelių privalumus ir trūkumus.

5. Duomenų modelis

Duomenų saugojimo modelis atitinka MOCURIS projekto poreikius. Jis skirtas modulių rengimo darbų analizei ir koordinavimui, realizacijos aspektai yra numatomi diegti ateityje. Šalia modulio sudėtinių dalių bazėje yra saugoma informacija apie projekto dalyvius, jų įsipareigotus modulių rengimo ir recenzavimo terminus. Darbas yra nuotolinis, todėl numatoma panaudoti XML technologijas informuoti dalyvius apie artėjančius terminus, siunčiant trumpas žinutes į dalyvių mobilų telefoną.

Analizuojant šią informaciją, yra sekama esama padėtis. 7 pav. pavaizduota duomenų bazės struktūra.

University

-Univer_id : Int-Univer_name : text-Address : text-City : text

Member

-Person_no : int-First_name : text-Last_name : text-phone : int-univer_id : int

Course

-Course_id : int-title : text

Module

-module_id : int-title : text-auth_id : Member-Course_id : Course-carrer_track_id : Career_tracks

Reviewer

-Reviewer_id : int-mem_id : Member-Mod_id : Module

Trained_abilities

-Mod_id : Module-tab_id : int-ability : text

1..n

Glossary

-Gl_id : int-term : text-annotation : text-mod_id : Module

Topic

-T_id : int-mod_id : Module-topic_text : text

schedule

-t_id : Topic-mod_id : Module-week : int-hours : int

Bibliography

-Bib_id : int-book_code : text-book_annot : text-mod_id : Module-intro : Yes/No

1..n

Book

-Book_code : Bibliography-Book_author : text-bool_title : text-company : text-year : int

1..n

Keyword

-Key_id : int-Mod_id : Module-word : text

Prerequisites

-Pre_id : int-pre_course : Course-Pre_mod : Module-mod_id : Module

Exercises

-ex_id : int-exercise : text-module_id : Module

Objective

-ob_id : int-mod_id : Module-objective : text

1..n

1..n

Career_tracks

-Car_id : int-career_name : text

1..n

7 pav. Duomenų bazės struktūra

Modulis yra priskirtas tam tikram kursui. Jo sudėtinės dalys jau buvo aptartos 0 skyriuje, kai buvo nagrinėjamas modulio DTD aprašas. Dauguma modulio struktūros elementų yra pasikartojantys, pavyzdžiui, raktinis žodis, pagrindinės sąvokos, temos ir panašiai. Jų santykio su moduliu tipas yra 1:n. Modulis turi vieną rengėją ir vieną recenzentą, projekto dalyvį. Kadangi moduliai turi būti pateikiami Internete, tai pareikšti pastabas gali bet koks suinteresuotas asmuo.

Ateityje svarbesnis taps studijų programos realizavimo aspektas. Jis yra pakankamai sudėtingas. Turimas modelis turėtų būti papildytas specializacijų sąrašu, kuriame atsispindėtų specializacijų santykis su konkrečiais

VI – 33


moduliais. Be to, reiktų sudaryti modulio techninių ir programinių resursų aprašą, nustatyti modulių eiliškumą kiekvienai specializacijai.

6. Pateikties realizacija

0 skyriuje buvo minėta, kad saugojant duomenis reliacinėje bazėje reikalinga kalba, kuri transformuos lentelių duomenis į XML formatą. Produkte MS SQL Server 2000 yra numatytas sakinys SELECT ... FOR XML, todėl buvo pasirinktas šis produktas. 8 pav. iliustruoja pateikties modulio architektūrą. Be minėtos DBVS panaudotas Web serveris - Microsoft Internet Information Server. Transformavimo scenarijai buvo rašomi, naudojant ASP scenarijus [4]. Transformaciją iš XML į PDF formatą atlieka Apache FOP procesorius. Jis naudoja XML bei XSL aprašus ir generuoja dokumentą PDF formatu. Šis formatas yra nepriklausomas nuo platformos ir todėl tinkamas spaus-dinimui.

W e b n a rš yk lėX M L

p ro c es o riu s

H T M L

K lie n to ko m p iu te r is

W E Bs e rv e r is

A S Pin te rp re ta to r iu s

X M L

X S L

O D B C

S e le c t . . . fo r X M L

D B V SM S S Q L 2 0 0 0

S e rv e r in is k o m p iu te r is

P D F

8 pav. Pateikties modelio architektūra

Pateiksime keletą rodinių, iliustruojančių studijų programos pateikties modelio realizaciją. Pasirinkus kursą, rodomi moduliai. Spragtelėjus spausdinimo mygtuką, modulio turinys bus transformuojamas PDF formatu ir siun-čiamas naudotojui.

Įvedinėti modulius į duomenų bazę gali tik projekto dalyviai, todėl norint įvesti naują modulį naudotojas turi re-gistruotis. Modulių įvestis realizuota, naudojantis HTML formomis ir ASP scenarijais. Ieškoti galima modulius ir knygas. Paieška realizuota taip pat naudojantis ASP scenarijais. Pagal pasirinktą parametrą ir gautą raktinį žodį yra siunčiama užklausa MS SQL serveriui. Užklausos rezultatas yra pateikiamas XML dokumente, prijungiamas XSL pavaizdavimo aprašas ir išsiunčiamas klientui.

7. Išvados

Straipsnyje buvo nagrinėjamos informacinių sistemų studijų programos pateikties problemos. Aptarti rengimo ir realizacijos aspektai. Informacinių sistemų studijų programa realizuojama universitete turint vieną ar keletą specia-lizacijų. Dinamiškai vystantis technologijoms, kursai turi būti nuolat keičiami. Pasiūlytas ir praktiškai realizuotas pateikties modelis leidžia tai daryti lanksčiai ir pakankamai efektyviai. Modelis pateikia kurso žinių branduolį, lei-džia koordinuoti nuotolinį modulių rengimą, keitimą ir recenzavimą. Modulių pateikties lankstumą užtikrina naudojamos XML technologijos - parengtas modulio XML aprašas, paruošti XSL transformacijų aprašai. Moduliai yra saugomi reliacinėje duomenų bazėje. Tai sudaro galimybes efektyviai vykdyti užklausas, analizuoti modulių tu-rinį, sekti modulių rengimo ir recenzavimo terminus.

VI – 34


Numatoma modelį plėsti realizacijos aspektu, siejant modulius su specializacijomis ir naudojamais resursais. Pasiūlyta duomenų bazės struktūra tai leidžia daryti. Be to, planuojama realizuoti modelių saugojimą, naudojant XML dokumentų bazę, kas supaprastintų operacijas, ir palyginti abiejų metodų privalumus bei trūkumus.

Straipsnio autoriai dėkoja Katalonijos technikos universiteto bakalaurui Albert Hervas Pi ir Vilniaus Gedimino technikos universiteto bakalaurui Valdui Sinkevičiui už straipsnyje nagrinėtų įdėjų realizaciją.

Literatūros sąrašas [1] A. Bonifati, S. Ceri, S. Paraboschi. Active Rules for XML: A new paradigm for E-services. The VLDB Journal, 2001, vol.

10, pp. 39 – 47. [2] A. Caplinskas and O. Vasilecas. Modern curriculum in information systems: A case study. Information Technology and

Control, 2002, 1 (22), pp. 22-27. [3] A. Čaplinskas, O. Vasilecas. MOCURIS — modern curriculum in information systems at master level. In Stanislaw Wrycza

(eds.). Proc. of the 10th European Conference on Information Systems (ECIS2002), Gdansk, Poland, 2002, V. 1, pp.184 – 193.

[4] H.M. Deitel, P.J. Deitel, T.R. Nieto, T.M. Lin, P. Sadhu. XML How to program. Prentice Hall, Translated by Binom Publishers, 2001.

[5] Ch. Gnaho. Web-Based Information systems Development - a User Centered Approach. In WebEngineering 2000, S. Murugesan, Y. Deshande (Eds.), LNCS, 2016, pp. 105 – 118.

[6] H. Kiyomitsu, A. Takeuchi, K. Tanaka. ActiveWeb: XML-based Active Rules for Web View Derivations and Access Control. Proc. of the Workshop on Information technology for Virtual Enterprises (ITVE 2001), Australian Computer Science Communications. IEEE Press, 2001, Vol. 23, No. 6, pp.31-39.

[7] D. Martin, M. Birbeck, M. Kay, B. Loesgen et al. Professional XML. Wrox press Ltd., 2001, p. 864. [8] A. Salminen, Lyytikäinen, P. Tiitinen. Putting documents into their work context in document analysis. In Information

Processing and Management, 2000, 36, pp. 623-641. [9] D. Scheffner, J.C. Freytag. The XML Query Execution Engine (XEE). Technical Report HUB-IB-158. Humbold-Universität

zu Berlin, 2002. [10] J. Shanmugasundaram, E. Shekita, R. Barr, M. Carrey, B. Lindsay, H. Piranesh, B. Reinwald. Efficiently Publishing

Relational Data as XML Documents. The VLDB Journal, 2001, 10 (2-3), pp. 133 – 154.

Presentation Model of Project MOCURIS Teaching Materials Using Relational and XML Technologies

The article deals with the problems of increasing efficiency of Information systems curriculum development. A presentation model enabling to develop, correct and renew the modules is suggested. The model is flexible enough; it separates module content and presentation. An XML technology is used to transfer the documents over Internet. The problems of data conversion from relational DB to XML document and such conversion realization are discussed. The structure of DB and presentation architecture are presented.

VI – 35

MODIFIKUOTŲ DARBŲ SEKŲ MODELIŲ TAIKYMAS DALYKINĖS SRITIES ŽINIOMS SPECIFIKUOTI

Audrius Lopata, Saulius Gudas Kauno Technologijos universiteto informacijos sistemų katedra, Studentų g. 50, Kaunas

Vilniaus Universitetas, KHF, Muitinės 8, 3000 Kaunas

Straipsnyje aptariamos modifikuotų darbų sekų modelių taikymo galimybės vartotojų poreikių surinkimo ir ana-lizės etape. Analizuojamas veiklos procesų, materialių procesų ir funkcijų darbų sekų modelių taikymas žinioms apie dalykinę sritį surinkti, bei žinių surinkimo klaidoms mažinti.

1. Vartotojo poreikių surinkimo ir analizės principas naudojant veiklos metamodelį.

IS kūrimo gyvavimo ciklo vartotojo poreikių surinkimo etapą (1 pav.) sudaro trys pagrindiniai poetapiai: • dalykinės srities žinių surinkimas, specifikavimas ir validavimas; • vartotojo poreikių surinkimas; • surinktų vartotojo poreikių atitikimo dalykinės srities žinioms tikrinimas. Probleminės srities žinių surinkimas, specifikavimas ir validavimas atliekamas pagal probleminės srities žinių

surinkimo ir pilnumo tikrinimo algoritmą. Probleminės srities žinios surenkamos taikant modifikuotus darbų sekų modelius, o jų pilnumas tikrinamas veiklos metamodelio pagrindu [1]. Surinktos žinios kaupiamos žinių bazėje, kuri sudaryta veiklos modelio ir veiklos metamodelio pagrindu [2]. Veiklos metamodelis apibrėžia veiklos modelio sudėtį.

Vartotojo poreikių surinkimas atliekamas pagal pasirinktą vartotojo poreikių surinkimo šabloną (pvz.: Volere[3]). Specifikuoti vartotojo poreikiai taikant vartotojo poreikių atitikimo dalykinės srities žinioms tikrinimo algoritmą tikrinami su veiklos modelyje saugomomis veiklos dalykinės srities žiniomis, kas sąlygoja veiklos modelyje esančių žinių pildymo bei vartotojo poreikių koregavimo procesus. Galutinis vartotojo poreikių surinkimo etapo rezultatas- vartotojo poreikių specifikacija, naudojama kituose IS gyvavimo ciklo etapuose.

Realuspasaulis

Probleminėssrities žiniųsurinkimas

Vartotojo poreikiųsurinkimas

(naudojant šabloną)

Pirminiaiduomenys

Pirminiaiduomenys

Probleminėssrities žinių

specifikavimas irvalidavimas

Probleminėssritiesžinios

Veiklos modelisProbleminėssritiesžinios

Vartotojo poreikiųverifikav imas

Veiklos žinios

Pirminė vartotojo poreikiųspecifikacija

Pirminės vartotojo poreikiųspecifikacijos patikslinimas

Veiklosmodelio

papildymasžiniomis

Vartotojo poreikių surinkimoetapas

Kiti IS kūrimogyvavimo

ciklo etapaiVartotojoporeikių

specifikacija

Veiklos žinios(enterprise knowledge)

Vartotojo poreikiai

Veiklos žinios (enterprise knowledge)

VeiklosMeta-modelis

Žinių bazė

1 pav. IS GC vartotojo poreikių surinkimo ir analizės etapas, taikant veiklos metamodelį

Veiklos procesų darbų sekų modelis informacijos apie dalykinę sritį surinkimui naudotinas todėl, kad yra pa-kankamas pirminei dalykinės srities informacijai surinkti, bei yra nesudėtingas ir suprantamas vartotojui. Veiklos procesų darbų sekų modelio pagalba surenkama pirminė dalykinės veiklos srities informacija. Vartotojas pateikia kompiuterizuojamos srities veiklos procesų aprašymą užpildydamas veiklos procesų darbų sekų modelį. Taikant veiklos procesų darbų sekų modelį surenkama informacija ne tik apie dalykinėje srityje vykstančius procesus, bet ir apie informacinius ir materialius srautus bei vykdytojus. Žinios apie kompiuterizuojamą veiklos dalykinę sritį surenkamos naudojant veiklos procesų, procesų ir funkcijų darbų sekų modelius.

VI – 36

Modifikuotų darbų sekų modelių taikymas dalykinės srities žinioms specifikuoti

3. Veiklos procesų darbų sekų modelio sudėtis

Standartiniuose darbų sekų modelių (Provision WB[4] ir kt.) sudėtinės dalys yra vykdytojai, veiklos ir srautai. Veiklos ir vykdytojai, priklausomai nuo darbų sekų modelio notacijos gali būti skirstomi į tipus, o srautai neskirstomi į tipus.

Siekiant detalesnio informacijos apie dalykinę sritį surinkimo grindžiamo veiklos metamodeliu, veiklos darbų sekų modelį tikslinga modifikuoti įvedant dviejų tipų srautus (informacinius ir materialius). Veiklos procesų darbų sekų modelyje dviejų tipų srautai būtini jo skaidymui į procesų ir funkcijų darbų sekų modelius sekančiame probleminės srities žinių surinkimo ir analizės etape. Kiekvienas veiklos procesas, išskyrus pradinį ir paskutinį turi materialią ir (arba) informacinę įeiga ir išeigą.

Veiklos procesas veiklos darbų sekų modelyje apibrėžiamas kaip organizacijoje vykstančių veiksmų, trans-formuojančių įeigas į išeigas seka[5]. Veiklos darbų sekų modelio materialus srautas, tai materiali veiklos proceso įeiga ir (arba) išeiga, užtikrinanti veiklos proceso aprūpinimą materialiais ištekliais, būtinais jo įvykdymui. Veikos procesų darbų sekų modelyje materiali veiklos proceso įeiga (išeiga) nėra būtinas kiekvieno veiklos proceso elementas. Veiklos darbų sekų modelio informacinis srautas- tai informacinė veiklos proceso įeiga ir(arba) išeiga, skirta veiklos procesų valdymui. Veikos procesų darbų sekų modelyje informacinė veiklos proceso įeiga (išeiga) nėra būtinas kiekvieno veiklos proceso elementas. Veiklos darbų sekų modelio vykdytojai (dalyviai)- asmuo, jų grupė ar organizacinis vienetas, vykdantis procesą bei atsakingas už jo sėkmingą įvykdymą.

Veiklos darbų sekų modelio pavyzdys pateikiamas 3 pav.

Veiklos proc.Nr.2

Veiklosproc.Nr.4

Veiklosproc.Nr.3

Veiklos proc.Nr.5

VykdytojasNr.1

VykdytojasNr.2

VykdytojasNr.3

Materialussrautas Nr.2

Veiklos proc.Nr.1


Informacinissrautas Nr.1





3 pav. Bendro (veiklos procesų) darbų sekų modelio pavyzdys

3 paveiksle, vaizduojančiame veiklos darbų sekų modelį, pateikti veiklos procesų, “Veiklos proc. Nr.1”, “Veiklos proc. Nr.2”, “Veiklos proc. Nr.3”, “Veiklos proc. Nr.4” ir “Veiklos proc. Nr.5”, informacinių srautų “Informacinis srautas Nr.1”, “Informacinis srautas Nr.2”, “Informacinis srautas Nr.3” ir materialių srautų “Materialus srautas Nr.1”, “Materialus srautas Nr.2”, “Materialus srautas Nr.3” ir “Materialus srautas Nr.4” pavyzdžiai.

4. Veiklos darbų sekų modelio išskyrimo į procesų ir funkcijų darbų sekų modelius teorinis pagrindimas

Procesų ir funkcijų darbų sekų modelių išskyrimas iš veiklos darbų sekų modelio yra pradinis dalykinės srities žinių pilnumo tikinimo etapas. Iš veiklos darbų sekų modelio būtina išskirti procesų ir funkcijų darbų sekų mode-lius, nes juose saugoma pradinė informacija, kurią naudoja žinių apie dalykinę sritį surinkimo ir pilnumo tikrinimo algoritmas. Šis algoritmas tikrina veiklos darbų sekų modeliu surinktų žinių pilnumą pagal veiklos metamodelio vidinę struktūrą. Veiklos metamodelis apibrėžia materialaus proceso ir jį valdančios funkcijos struktūrą ir jų tarpu-savio sąveiką. Procesų darbų sekų modelyje iš veiklos darbų sekų modelio išskiriami dalykinėje srityje egzis-tuojantys materialūs srautai, materialūs procesai bei jų vykdytojai. Funkcijų darbų sekų modelyje iš veiklos darbų sekų modelio išskiriami informaciniai srautai, veiklos bei vykdytojai.

Taikytinos trys pagrindinės veiklos darbų sekų modelio išskyrimo į procesų ir funkcijų darbų sekų modelius taisyklės.

Pirma taisyklė - jei veiklos proceso įeiga ir (arba) išeiga yra informacinis srautas, šis veiklos procesas, su infor-maciniais įeigos ir (arba) išeigos srautais funkcijų darbų sekų modelyje atvaizduojamas kaip VEIKLA (ACTIVITY).

VI – 37

A.Lopata, S.Gudas

Antra taisyklė - jei veiklos proceso įeiga ir (arba) išeiga yra materialus srautas, šis veiklos procesas su materialiais įeigos ir (arba) išeigos srautais procesų darbų sekų modelyje atvaizduojamas kaip PROCESAS

Trečia taisyklė - veiklos proceso vykdytojas, funkcijų arba procesų darbų sekų modeliuose atvaizduojamas vykdantis tą veiklą ar procesą, kuris buvo išskirtas iš jo vykdomo veiklos proceso veiklos procesų darbų sekų modelyje.

Veiklos procesų darbų sekų modelio sudėtinių dalių atvaizdavimo funkcijų ir procesų darbų sekų modeliuose principas pavaizduotas 4 pav.

Funkcijų darbų sekųmodelis

Veiklos procesų darbųsekų modelis

Procesų darbų sekųmodelis

Veiklos procesas

Materialus srautas

Informacinis srautas

Vykdytojas

Procesas

Materialus srautas

Vykdytojas

Veikla

Informacinis srautas

Vykdytojas

I taisyklė

I taisyklė

II taisyklė

II taisyklė

III taisyklė III taisyklė

4. pav. Veiklos procesų darbų sekų modelio skaidymo į funkcijų ir procesų darbų sekų modelius principas

5 pav. pateiktas veiklos procesų darbų sekų modelio sudėtinių dalių atvaizdavimo procesų ir funkcijų darbų sekų modeliuose pavyzdys. Veiklos procesų darbų sekų modelį sudaro veiklos procesai VP1, VP2 ir VP3, informaciniai srautai I1 ir I2 bei materialus srautas M1. Veiklos procesas VP2, kartu su informacine įeiga I1 taikant pirmą veiklos darbų sekų modelio išskyrimo į procesų ir funkcijų darbų sekų modelius taisyklę, atvaizduojamas funkcijų darbų sekų modelyje kaip veikla F2, turinti informacinę įeigą I1. Veiklos procesas VP3, kartu su materialia įeiga M1, taikant antrą veiklos darbų sekų modelio išskyrimo į procesų ir funkcijų darbų sekų modelius taisyklę atvaizduojamas procesų darbų sekų modelyje kaip materialus procesas P2 turintis materialią įeigą M1. Veiklos procesas VP3 ir jo informacinė įeiga I2, funkcijų darbų sekų modelyje atvaizduojami kaip veikla F3, turinti informacinę įeigą I2. Kadangi veiklos procesas VP1, turi informacines išeigas I1 ir I2, bei materialią išeigą M1, veiklos procesas VP1 taikant pirmą veiklos darbų sekų modelio išskyrimo į procesų ir funkcijų darbų sekų modelius taisyklę funkcijų darbų sekų modelyje atvaizduojamas kaip veikla F1 turinti informacines išeigas I1 ir I2, o taikant antrą taisyklę, procesų darbų sekų modelyje atvaizduojamas kaip materialus procesas P1 turintis materialią išeigą M1.

VP3

VP2

V1

VP1

I1

I2

M1

Veiklos procesųdarbų sekų modelis

V1

F3

F2

V1

F1

I1

I2

Funkcijųdarbų sekų modelis

V1

P2P1M1

V1

Procesųdarbų sekų modelis

5 pav. Veiklos procesų darbų sekų modelio skaidymo į funkcijų ir procesų darbų sekų modelius pavyzdys

5. Procesų darbų sekų modelis

Procesų darbų sekų modelyje pateikiami organizacijoje vykstantys procesai, turintys materialias įeigas ir išeigas.

Procesų darbų sekų modelio sudėtinės dalys yra procesai, materialūs srautai ir vykdytojai.

VI – 38

Modifikuotų darbų sekų modelių taikymas dalykinės srities žinioms specifikuoti

Procesas - tai didžiausias veiklos vienetas, nurodantis organizacijos darbų seką nuo išorinių tiekėjų iki išorinių klientų. Įeigos keitimo į išeigą metu procesas naudoja materialius išteklius. Proceso įeigos ir išeigos – tik materialūs srautai. Procesams gali būti taikomi įvairūs apribojimai. Procesai gali būti skaidomi į mažesnes dalis: subprocesus, užduotis, operacijas (sudaroma procesų hierarchija).

Materialaus srauto ir vykdytojų sąvokos apibrėžiamos analogiškai kaip ir veiklos darbų sekų modelyje. Pirmasis darbų sekų modelio procesas neturi įeigos, o paskutinis išeigos. Jeigu procesas nėra pirmas ar

paskutinis, ir jis neturi įeigos arba išeigos srauto, vadinasi procesų darbų sekų modelyje egzistuoja trūkio taškas, kuris bus šalinamas probleminės srities žinių surinkimo ir pilnumo tikrinimo algoritmu. Procesų darbų sekų modelio trūkio taškas, tai materialaus srauto, nutraukiančio nuoseklią procesų sekos vykdymą nebuvimas. 6 pav. pateiktas procesų darbų sekų modelio pavyzdys. Jame matome, kad įvykdžius veiklos darbų sekų modelio išskyrimo į funkcijų ir procesų darbų sekų modelius algoritmą, procesų darbų sekų modelyje atsirado trūkio taškų, nes procesai “Procesas Nr.3” ir “Procesas Nr.4” neturi išeigos, o procesas “Procesas Nr.5” neturi nei įeigos nei išeigos. Vykdant probleminės srities žinių surinkimo ir pilnumo tikrinimo algoritmą, procesų darbų sekų modelis bus pildomas trūkstamais materialiais įeigos ir (arba) išeigos srautais (išeigos srautu nebus pildomas paskutinis procesų darbų sekų modelio elementas).

ProcesasNr.2

ProcesasNr.4

PrcesasNr.3 Procesas Nr.5

VykdytojasNr.1

VykdytojasNr.2

VykdytojasNr.3


ProcesasNr.1




6 pav. Procesų darbų sekų modelio formalus aprašymas BNF notacijoje

6. Funkcijų darbų sekų modelis

Funkcijų darbų sekų modelio sudėtinės dalys yra veiklos (activity), informaciniai srautai ir vykdytojai Veikla - tai funkcija, arba jos sudėtinė dalis apdorojanti organizacijos informacinius srautus, keisdama jų in-

formacinę įeigą į išeigą. Kiekvieną materialų procesą būtinai valdo bent viena funkcija. Funkcija- pilnai, o veikla, būdama funkcijos sudėtinė dalis dalinai valdo materialų procesą.

Pagal veiklos metamodelyje apibrėžtą funkcijos vidinę struktūrą, veiklos gali būti priskiriamos: Interpretavimui (Interpretation), Informacijos apdorojimui (IP processing) arba Realizavimui (Realization).

Kiekviena funkcijų darbų sekų modelyje egzistuojanti veikla gali atitikti bet kurią iš aukščiau išvardintų funk-cijos sudėtinių dalių. Probleminės srities žinių surinkimo ir pilnumo tikrinimo algoritmu nustatoma, kuriai funkcijos vidinei daliai priklauso ir kurį materialų procesą valdo funkcijų darbų sekų modelyje egzistuojančios veiklos.

Informacinio srauto ir vykdytojų sąvokos apibrėžiamos analogiškai kaip ir veiklos darbų sekų modelyje.

VeiklaNr.2

VeiklaNr.4

VeiklaNr.3

VeiklaNr.5

Vykdytojas Nr.1

Vykdytojas Nr.2

Vykdytojas Nr.3

VeiklaNr.1


Informacinissrautas Nr.2Informacinis

srautas Nr.3

7 pav. Funkcijų darbų sekų modelio pavyzdys

VI – 39

A.Lopata, S.Gudas

Įvykdžius veiklos darbų sekų modelio išskyrimo į procesų ir funkcijų darbų sekų modelius algoritmą, funkcijų darbų sekų modelyje, kaip ir procesų darbų sekų modelyje gali atsirasti trūkio taškų. Funkcijų darbų sekų modelio trūkio taškas, tai informacinio srauto, nutraukiančio nuoseklų veiklų sekos vykdymą nebuvimas. Jeigu veikla neturi informacinės įeigos ir (arba išeigos) vadinasi funkcijų darbų sekų modelyje egzistuoja trūkio taškas (išskyrus tuos atvejus kai veikla pirmoji arba paskutinė). Funkcijų darbų sekų modelyje egzistuojančių trūkio taškų pavyzdys pateikiamas 7 pav. Veikla “Veikla Nr.2” neturi informacinės išeigos, nors ji nėra paskutinė funkcijų darbų sekų modelyje. Veiklos “Veikla Nr.3” ir “Veikla Nr.4” neturi informacinės įeigos nors jos nėra pradinės funkcijų darbų sekų modelio veiklos. Trūkio taškai aptinkami ir šalinami vykdant probleminės srities žinių surinkimo ir pilnumo tikrinimo algoritmą.

7. Išvados

Modifikuoti darbų sekų modeliai taikytini IS gyvavimo ciklo vartotojo poreikių ir surinkimo etape todėl, kad yra pakankami pirminei kompiuterizuojamos dalykinės srities informacijai surinkti ir yra nesudėtingi ir lengvai suprantami vartotojui. Veiklos procesų darbų sekų modeliu surinktas žinios taikant funkcijų ir procesų darbų sekų modelių atskyrimo algoritmą transformuojamos į funkcijų ir procesų darbų sekų modelius, kuriuose pateiktos žinios naudojamos kaip pradinės žinios, reikalingos dalykinės srities žinių surinkimo ir pilnumo tikrinimo algoritmui. Vykdant šį algoritmą, pildomi procesų bei funkcijų darbų sekų modeliai, kas sąlygoja mažesnę klaidų, surenkant dalykinės srities žinias tikimybę.

Literatūros sąrašas [1] A. Lopata, S. Gudas Informacijos išteklių identifikavimas, veiklos modelio pagrindu. Informacijos mokslai, Vilniaus

universiteto leidykla, T19, Vilnius, 2001, p.43-50 [2] S.Gudas, T. Skersys, A. Lopata. Domain Knowledge Integration For Information Systems Engineering. “Informacinės

technologijos verslui 2002”, Kaunas, 2002. [3] J. Robertson, Volere Requirements Specification Template, http://www.systemsguild.com/ GuildSite/Robs/Template.html [4] ProVision Work Bench User Manual Guide www.proformacorp.com [5] ENV 12204: Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling, CEN TC

310/WG1, 1996 http://www.pera.net/Standards/ENV 12204.html

Usage of modified work flow models for specification of problem domain knowledge

The paper presents the principles of modified work flow models usage in user requirements acquisition and analysis stage. Possibilities of business processes, material processes and functions work flow models usage for acquisition and specification of problem domain knowledge are presented.

VI – 40

http://www.systemsguild.com/ GuildSite/Robs/Template.html

http://www.pera.net/Standards/ENV 12204.html

Veiklos taisyklių integravimo kompiuterizuotoje IS inžinerijoje būdas Saulius Gudas, Tomas Skersys

Kauno Technologijos universitetas, Informacijos sistemų katedra Studentų g. 50, Kaunas

Straipsnyje aptariamos veiklos taisyklių (VT) taikymo kompiuterizuotame informacijos sistemų (IS) projektavime galimybės. Pateikiami VT integravimo į žiniomis grindžiamą organizacijos veiklos modelį principai. Aptarti tokio po-žiūrio privalumai ir naujos galimybės kompiuterizuoto IS projektavimo srityje.

1. Įvadas

Informacijos sistemų (IS) projektavimas naudojant vien tik grafinius duomenų atvaizdavimo modelius turi aiškių trūkumų [1]. Duomenų modeliai didžiąja dalimi tik aprašo duomenų struktūras. Čia beveik nieko nepasakoma, kaip tie duomenys gali ar privalo būti panaudoti. Šiuos trūkumus bandoma išspręsti tradicinius IS projektavimo metodus integruojant su veiklos taisyklėmis.

Pirmieji moksliniai straipsniai apie veiklos taisykles (VT) pradėti publikuoti apie 1990-uosius metus. Tuomet buvo pastebėta, kad, siekiant pilnai aprašyti organizaciją, tradicinių į procesus ir duomenis orientuotų analizės metodų nebeužtenka, o programuotojams paliekama per daug laisvės improvizacijai, programiniu kodu užpildant neišanalizuotus organizacijos aspektus.

Veiklos taisyklės dabar naudojamos tik labai nedaugelyje kompiuterizuoto IS projektavimo (CASE) įrankių. Šie įrankiai dažniausiai apsiriboja paprasčiausiomis struktūrinėmis taisyklėmis duomenų modelių struktūroms aprašyti (tokios taisyklės pateikiamos kaip grafinės modelių notacijos dalis). Jei naudojamos ir kitų tipų VT, jos paprastai saugomos tik kaip paprastas tekstas modelio objektų komentaro laukeliuose.

Kompiuterizuotas IS projektavimas organizacijos veiklos modelio žinių bazės pagrindu [2] panaikina atotrūkį tarp į procesus ir duomenis orientuoto projektavimo ir VT.

Straipsnyje bus aptariama veiklos taisyklių sąvoka, jų klasifikavimo, užrašymo būdai ir pateikiami taisyklių integravimo Organizacijos veiklos modelyje principai.

2. Veiklos taisyklių klasifikavimas

Iki šiol nėra vieningos nuomonės įvairiais klausimais, susijusiais su taisyklių identifikavimu, atvaizdavimu, jų integravimu IS kūrimo procese, diegimu taikomosiose programose ir kt. Nėra ir vieningo VT apibrėžimo, notacijos bei jų klasifikacijos.

Organizacija “Business Rule Group” (dar žinoma kaip “GUIDE Business Rule Project”) pasiūlė tokį VT apibrėžimą: “Veiklos taisyklė – tai teiginys, kuris apibrėžia arba sąlygoja tam tikrą veiklos aspektą” [3].

2 lentelė. Veiklos taisyklių klasifikacija

Šaltinis Taisyklių klasifikacija Business Rules Group (Guide Business Rules Project)

Struktūrinės taisyklės (terminai, faktai), veiksmo taisyklės (integralumo apribojimai, sąlygos, autorizacija), išvestys (skaičiavimai, loginės išvados)

Ronald Ross, Database Research Group

Terminai, faktai (ryšių tipai, subtipai, atributai), taisyklės (skaičiavimai, atmetimo taisyklės, projekcijos)

Tom Romeo, IBM

Struktūrinės taisyklės (ryšiai, domenai, kardinalumas), elgesio taisyklės (pre-sąlygos, post-sąlygos, išvestys)

Margaret Thorpe, Tangram

Apibrėžimai, integralumo taisyklės, bendrieji deklaratyvūs apribojimai, procedūriniai apribojimai, išvestys

Barbara von Halle, Knowledge Partners

Apibrėžimai, faktai, apribojimai, išvestys, loginės išvados

Usoft Corporation Apribojimai, išvestys, elgesio taisyklės, atvaizdavimo taisyklės Brightware Veikla, strategija, darbų sekos, sprendimų euristika Vision Software Validavimo taisyklės, išvestys, ryšiai, sąlygos veiksmai

VI – 41

T.Skersys, S.Gudas

Šiuo metu kiekviena VT srityje dirbanti organizacija, nepriklausomi mokslininkai kuria savas veiklos taisyklių klasifikacijas, priklausomai nuo iškeltų darbo tikslų, probleminės srities specifikos. Keletą veiklos taisyklių klasifikacijų matote 1 lentelėje.

Viena dažniausiai naudojamų VT klasifikacijų yra sudaryta organizacijos “Business Rules Group” (BRG). Pagal šią klasifikaciją taisyklė gali: (1) apibrėžti terminą (2) sujungti terminus į faktus (3) pateikti skaičiavimų rezultatus (4) patikrinti sąlygas naujo fakto sukūrimui (5) patikrinti sąlygas veiksmui inicijuoti. Trys paskutiniosios kategorijos apibrėžia tikrąsias veiklos taisykles, o terminai ir faktai turėtų būti interpretuojami kaip struktūrinės taisyklės, kurių didžiąją dalį galima atvaizduoti ir tradicinėmis duomenų modelių grafinėmis notacijomis.

Nepaisant sudėtingų veiklos taisyklių klasifikacijų, nemažą dalį jų galima aprašyti daugeliui suprantamais IF…[AND…]THEN… arba WHENEVER…[AND…]THEN… formatais. Tokiu formatu užrašytomis taisyklėmis gal-ima įvertinti veiklos objektų savybes ir iššaukti atitinkamus veiksmus. Veiksmai gali modifikuoti veiklos objekto savybes, sukurti naujus veiklos objektus, iššaukti metodus arba kitų taisyklių vykdymą [4].

Norint integruoti veiklos taisykles Organizacijos veiklos modelyje, tikslinga pateikti ir savo taisyklių klasifikaciją bei sudėtį. Žemiau pateiktoje klasifikacijoje (1pav.) matome, kad veiklos taisyklės, atsižvelgiant į EVC sudėtį, gali būti skirstomos į Interpretavimo, Informacijos apdorojimo bei Realizavimo taisykles. Terminai ir faktai buvo atskirti nuo VT ir sudaro atskirą struktūrinių taisyklių grupę.

VT apibrėžimas(Business rule statement)

Veiklos taisyklė(Business rule)

Terminas(Term)

Interpretavimo VT(Interpretation BR)

Faktas(Fact)

Apribojimas(Constraint)

Veiksmoįgalinimo VT

(Action enabler)

Išvestis(Deriviation)

Informacijosapdorojimo VT

(Information processing BR)

Realizavimo VT(Realization BR)

Formali VT išraiška(Formal rule expression)

Šablonas(Pattern)

Loginė išvada(Inference)

2 pav. VT klasifikacija ir sudėtis pagal Organizacijos veiklos modelį

Trumpas taisyklių tipų paaiškinimas: • Struktūrinės taisyklės (structural rules) – šios taisyklės apibrėžia duomenų struktūras ir jų tarpusavio ryšius.

Šio tipo taisyklės gali būti pavaizduotos grafine duomenų modelių notacija. o Terminai (terms) – apibrėžia analizuojamoje veikloje esančius objektus (daiktavardžius). Esybių ryšių

diagramose terminai gali būti apibrėžiami kaip esybės. o Faktai (facts) aprašo terminus (esybių atributus) arba asociacijas tarp terminų, kurie yra prasmingi

probleminei sričiai (ryšius tarp esybių). • Veiklos taisyklių (business rules) grupę sudaro:

o Apribojimai (constraints) – tai taisyklės, apibrėžiančios aplinkybes, kurioms esant transakcija, sprendimas ar veiksmas turi būti atmestas, nutrauktas arba yra nepageidautinas.

o Veiksmo įgalinimo taisyklės (action enablers) – aplinkybės, kurios įgalina organizaciją imtis nustatytų veiksmų.

o Išvestys (derivations) yra išraiškos, kuriose naudojamos matematinės ir loginės operacijos su faktais išvestinių atributų reikšmėms paskaičiuoti.

o Loginės išvados (inferences) – taisyklės, kurios nusako, kaip žinios ar informacija yra transformuojama į kitą formą. Šios taisyklės gali operuoti ir neskaitiniais duomenimis.

VI – 42

Veiklos taisyklių integravimo kompiuterizuotoje IS inžinerijoje būdas

3. Veiklos taisyklių formalizavimas

Pasak Barbaros von Halle, visame sistemos kūrimo procese veiklos taisyklės verslo žmonėms yra labiausiai suprantamas dalykas. Tačiau iš verslo srities atstovo “ištraukta” VT dažnai būna neaiški, daugiareikšmė. Iš vartotojo surenkamos taisyklės turi būti aprašomos tokiu formatu, kad vėliau jas būtų galima dokumentuoti ir automatizuoti. Taisyklės turi būti:

• deklaratyvios – taisyklės neturi būti apibrėžtos procedūriškai, naudojant aukšto lygio procedūrines programavimo kalbas. Šiuo atveju nėra svarbu, kaip taisyklė bus įgyvendinta;

• tikslios – taisyklė turi būti interpretuojama vienareikšmiškai. Jei taisyklė gali būti suprasta daugiareikšmiškai, ji turi būti suformuluota kitaip;

• atominės – taisyklė turi išlaikyti vieną ir tik vieną išbaigtą mintį. Bandant suskaldyti atominę taisyklę į keletą dalių bus prarandama informacija;

• neperteklinės – taisyklių rinkinys negali turėti taisyklių, teigiančių tą patį. • VT taip pat gali būti kompozicinės, t.y. būti sudarytos iš kitų taisyklių. Komercinėse veiklos taisyklių valdymo sistemose (BRE – Business Rules Engines), pavyzdžiui, QuickRules

2.0, BRS RuleTrack., šiuos reikalavimus bandoma užtikrinti pseudo-formaliomis kalbomis, kuriose naudojamos natūralios kalbos išraiškos, sudėtos į tam tikros struktūros sakinius (šablonus). Pagrindinis tokias kalbas taikančių firmų argumentas – veiklos taisyklės turi būti užrašytos verslo atstovams suprantama kalba, nes būtent šie žmonės naudosis veiklos taisyklių valdymo sistemomis. Be to:

• šablonais užrašytos veiklos taisyklės yra dalinai formalizuotos, • naudojant šablonus yra išlaikoma vienoda to paties tipo taisyklių struktūra, • taisyklių šablonai laikomi pseudo-kodu – tai svarbu programuotojams. Yra ir kitokia nuomonė: “Mes turime specialistus, kurie kuria ir keičia taisykles; dauguma vartotojų neturi jokio

noro patys tvarkyti didelius sudėtingų taisyklių rinkinius. Net jei ir norėtų patys užrašinėti taisykles, ar jie suprastų, kaip jas ištestuoti?” (Westfield Group) [5].

Šablonų naudojimas yra patogus būdas taisyklėms iš vartotojų surinkti ir validuoti, tačiau gilesnei jų analizei reikėtų naudoti deklaratyvias formalias kalbas, pavyzdžiui, Prolog, Z, Predikatų logiką, OCL, Alloy.

Straipsnyje siūloma taisykles į žiniomis grindžiamo Organizacijos veiklos modelio VT saugyklą surinkti ir validuoti naudojant veiklos taisyklių šablonus (žr. 2 lentelė). Šablonais užrašytos taisyklės transformuojamos į formalias pasirinktos kalbos išraiškas. Formaliam taisyklių užrašymui pasirinkta OCL (Object Constraint Language) [6] dėl tokių priežasčių:

• Informacijos sistemų projektavimo metu naudojami grafiniai UML (Unified Modeling Language) modeliai, o OCL yra UML standarto dalis. Pagrindinė OCL paskirtis yra formaliomis išraiškomis papildyti UML grafinius modelius (pvz., klasių modelį). OCL idealiai tinka struktūrinėms taisyklėms užrašyti, tačiau šia kalba galima užrašyti ir kitų tipų taisykles.

• Yra sukurta keletas OCL sintaksės tikrinimo įrankių bei interpretatorių (pvz., IBM OCL parser [7], Dresden OCL Toolkit [8]). Kai kurie įrankiai yra atviro kodo ir moksliniais tikslais juos galima modifikuoti.

• OCL yra gana lengvai įsisavinama ir suprantama kalba.

2 lentelė. VT šablonų pavyzdžiai

VT tipas Šablonas Terminas <Term> is defined as <textual definition>

Faktas <Term_1> may <verb><Term_2> <Term_1> has a property of <Term_2>

Išvestis <Term> is computed as <formula>

Apribojimas <Term_2> must have <at least, at most, exactly n of> <Term_1> <Term_1> must be in list <list>

Veiksmo įgalinimas IF <rule phrase> [AND <rule phrase> AND <rule phrase>…] THEN <action> Loginė išvada IF <rule phrase> [AND <rule phrase> AND <rule phrase>…] THEN <inferred knowledge>

4. Veiklos taisyklių integravimo sistemoje būdai

Veiklos taisyklės nuolat kinta, t.y. yra dinamiškos. Jos turi būti reguliariai atnaujinamos – tik tuomet valdoma organizacija galės laiku prisitaikyti prie besikeičiančių aplinkos, veiklos sąlygų. Tačiau didžioji dalis šiuo metu

VI – 43

T.Skersys, S.Gudas

naudojamų CASE įrankių veiklos taisykles paprasčiausiai ignoruoja; taisyklių surinkimas ir apdorojimas nėra įtraukiamas į informacijos sistemų analizės, projektavimo etapus. Tradiciškai veiklos taisyklės programuotojų dažniausiai būna “įsiuvamos” tiesiai į programų kodą. Tokie darbo principai yra atgyvenę ir neefektyvūs [9].

Taisyklių išskyrimas iš programinio kodo yra vienas svarbiausių žingsnių, siekiant supaprastinti VT valdymo mechanizmą. Naudojant veiklos taisyklių valdymo sistemas taisykles kurti, klasifikuoti ir palaikyti gali su organizacijos veikla susipažinęs analitikas, o ne programuotojas. Veiklos taisyklių saugyklos ir taikomųjų programų ryšys palaikomas per specialius programų kode įdėtus kreipinius.

Dar viena VT integravimo sistemoje strategija apima du aukščiau aprašytuosius būdus. Taisyklės čia kaip ir pir-muoju atveju yra integruojamos į programos kodą, tačiau pačios taisyklės kodo generatoriaus yra paimamos iš specialios VT saugyklos.

Pastarąjį būdą siūloma taikyti ir organizacijos veiklos modeliu grindžiamame IS kūrimo metode. Organizacijos veiklos modelio VT saugykloje saugomos taisyklės bus tiesiogiai integruojamos į programos kodą, sugeneruotą projektinių modelių pagrindu. Tokiu būdu bus išsaugotas lankstus veiklos taisyklių kūrimo ir modifikavimo mechanizmas ir nepažeistas programos vientisumas.

5. Veiklos taisyklių integravimas organizacijos veiklos modelyje

“Taisyklė yra organizacijos sprendimų priėmimo mechanizmo dalis” (Paul Mallens, “Usoft Corporation”). Galima sakyti, kad organizacija yra suma to, ką ji žino (t.y. informacija) ir kaip ji tas žinias išnaudoja (t.y. taisyklės) savo tikslingoje veikloje [10].

Veiklos procesai organizacijoje yra valdomi per sprendimų priėmimo mechanizmą. Šis mechanizmas orientuoja procesus taip, kad būtų pasiekti organizacijos tikslai su optimaliomis sąnaudomis (materialinių resursų, laiko ir kt.). Tačiau, jei toks valdymo mechanizmas organizacijoje informacijos sistemoje ir yra realizuotas, jis paprastai neturi aiškios struktūros ir būna paslėptas procedūriniame programos kode, išmėtytas daugybėje taikomųjų programų (žr. sk. “Veiklos taisyklių integravimo sistemoje būdai”).

Žiniomis grindžiamame organizacijos veiklos modelyje veiklos taisyklės pilnai integruotos į veiklos procesų valdymo mechanizmą per sąsają VT-Funkcija-Procesas (2pav.) ir turi aiškią architektūrą [2]. Kiekviena taisyklė gali būti pasiekiama per organizacijos veiklos modelio VT saugyklą.

Aktorius(Actor)

Procesas(Process)

Funkcija(Function)

Veiklos taisyklė(Business rule)

a t l ieka

yra a t l i ekamas

valdo

yra va ldomas

at l ieka

yra a t l i ekama

apibrėž ia

yra ap ibrėž iama

Tikslas(Objective)

yra į t ako jama

į t ako ja 2 pav. Organizacijos veiklos modelio fragmentas

6. Išvados

Veiklos taisyklių integravimas kompiuterizuotoje informacijos sistemų inžinerijoje praplečia funkcines IS kūrimo galimybes.

Pasiūlyta veiklos taisyklių klasifikacija žiniomis grindžiamame organizacijos veiklos modelyje. Taisyklių šablonai yra patogi, plačiai naudojama priemonė taisyklėms iš vartotojų surinkti ir validuoti, tačiau

gilesnei taisyklių analizei turi būti naudojamos ir formalios išraiškos. Parinkti šablonai ir formali kalba taisyklių surinkimui į organizacijos veiklos modelio VT saugyklą ir jų formalizavimui.

Apžvelgti veiklos taisyklių integravimo sistemoje būdai. Pasirinktas VT integravimo sistemoje būdas informacijos sistemos kūrimui naudojant organizacijos veiklos modelį.

VI – 44

Veiklos taisyklių integravimo kompiuterizuotoje IS inžinerijoje būdas

Literatūros sąrašas [1] David C. Hay, What Data Models can’t do, http://www.essentialstrategies.com/documents/brules.pdf [2] S. Gudas, A. Lopata, T. Skersys. Domain knowledge integration for information systems engineering. Konferencijos

pranešimų medžiaga “Informacinės technologijos verslui 2002”, Kaunas, Technologija, p. 56-59. [3] The Business Rules Group, Final Report, ver. 1.3, http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf [4] About Blaze Advisor Rule Services, http://www.kpiusa.com/brbook/Blaze.htm [5] Colleen Frye, Business Rules are back, http://www.adtmag.com/print.asp?id=6492 [6] Object Constraint Language Specification, http://www-3.ibm.com/software/ad/library/standards/ocl.html [7] The Object Constraint Language, http://www-3.ibm.com/software/ad/library/standards/ocl.html [8] OCL Compiler, http://dresden-ocl.sourceforge.net/index.html [9] Business Rules – Bizagi, http://www.visionsoftware.biz/resources/BusinessRules.htm

[10] Business Rules Today: A KPI Position Paper, http://www.kpiusa.com/ReadingRoom/BusinessRulesToday.htm

Principles of Business Rules integration in computer aided IS engineering

Possibilities of Business Rules application in computer aided IS engineering are discussed. Principles of Business Rules integration in knowledge-based Enterprise model are suggested. The advantages and new possibilities of this approach are discussed.

VI – 45

http://www.essentialstrategies.com/documents/bruleseco99.pdf

http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf

http://www.kpiusa.com/brbook/Blaze.htm

http://www.adtmag.com/print.asp?id=6492

http://www-3.ibm.com/software/ad/library/standards/ocl.html

http://www-3.ibm.com/software/ad/library/standards/ocl.html

http://dresden-ocl.sourceforge.net/index.html

http://www.visionsoftware.biz/resources/BusinessRules.htm

http://www.kpiusa.com/ReadingRoom/BusinessRulesToday.htm

MIKRO MOKĖJIMŲ APLINKA

Sigita Abramavičiūtė Vytauto Didžiojo Universitetas, Informatikos fakultetas, Vileikos g. 8, Kaunas, Lietuva, [email protected]

Raimundas Matulevičius Dept. of Computer and Information Science, Norwegian Univ. of Science and Technology

Sem Sealands vei 7-9, NO-7491 Trondheim, Norway, [email protected]

M-komercija pradeda žengti pirmuosius žingsnius greta tradicinio verslo ir e-komercijos. Organizacijos, matančios galimybes pritraukti naujus klientus siūlydamos m-komercijos paslaugas ir prekių apmokėjimo galimybes, turi sukurti naują strategiją, galinčią plėstis ir lanksčiai prisitaikyti prie dinaminės rinkos. M-komercijoje mikro mokėjimai yra mažos piniginės vertės mokėjimai, kurie yra svarbūs, naudojant naujas m-komercijos sistemas. Šiame darbe nagrinėjami m-komercijos sistemoms keliami reikalavimai bei apžvelgiamos esamos taikomosios programos ir technologijos, įgalinančios atlikti mikro mokėjimus, naudojant SMS ir mobiliąsias technologijas.

1. Įžanga

Gyvenimas neįsivaizduojamas be pirkimų. Vienais ar kitais būdais už pirkinius reikia atsiskaityti – sumokėti. Įprastą ir seniai naudojamą atsiskaitymą grynaisiais pinigais pamažu keičia pažangesni mokėjimo būdai. Daugelis įprato naudotis kreditinėmis kortelėmis, tačiau šiuo metu populiarėja nauja galimybė – mokėti naudojant SMS.

Mokėjimus būtų galima skirstyti į makro ir mikro mokėjimus. Makro mokėjimuose operuojama sąlyginai didelėmis sumomis, todėl tokių mokėjimų rizika yra gana didelė. Todėl apmokėjimo būdai dažniausiai būna tradiciniai – mokėjimas grynaisiais pinigais, arba mokėjimas pavedimu ar kreditine kortele.

Kas kita yra mikro mokėjimai. Domėjimosi mobiliąja komercija grupė [7] (MCIG - Mobile commerce interest group) mikro mokėjimus apibrėžia kaip: „mažos vertės tranzakcijas, apimančias mokėjimus, kurių vertė nuo kelių centų iki dešimties eurų, už skaitmenines ar fizines prekes, perkamas naudojat mobilųjį įrenginį ar atsisiunčiamas/įrašomas į jį, ir sumokant grynųjų pinigų ekvivalentu (reikiamą sumą nurašant nuo išankstinio apmokėjimo sąskaitos, banko sąskaitos ar įtraukiant ją į sąskaitą už telefoninius pokalbius).” Kadangi mikro mokėjimų rizika yra nedidelė, tai leidžia juos atlikti naudojant įvairius būdus - atsiskaityti grynaisiais pinigais, kredito kortele, sumokėti reikiamą sumą internetu arba atlikti mokėjimą naudojant SMS. Pastaroji galimybė sąlygoja naujos verslo rūšies, m-komercijos, atsiradimą. M-komercija nepakeis egzistuojančių mikro mokėjimo būdų, tačiau dėl savo paprastumo ir mobiliųjų įrenginių paplitimo tai gali išplėsti mikro mokėjimų galimybes ir pritraukti daugelį vartotojų.

Šiame darbe nagrinėjama mikro mokėjimų naudojant SMS aplinka. Tai ateities technologija, potencialiai turinti plačias panaudojimo galimybes. Darbe nagrinėjamos m-komercijos ir mikro mokėjimų sąvokos, aptariami m-komercijai keliami reikalavimai bei apžvelgiamos esamos taikomosios programos ir technologijos, suteikiančios galimybę atlikti mikro mokėjimus naudojant SMS. Išvados ir galimi ateities darbai yra nagrinėjami straipsnio pabaigoje.

2. M-komercija ir mikro mokėjimai

M-komercijos paslaugų sėkmė priklauso nuo vartotojų pasitikėjimo tokių mokėjimų saugumu, paslaugų patrauklumo ir jų naudojimo paprastumo bei finansinių tranzakcijų integravimo. Nors diegiant mikro mokėjimus reikia priimti techninius, komercinius ir teisinius iššūkius bei atlaikyti kitų mokėjimo galimybių konkurenciją, ši sritis yra perspektyvi mobiliojo ryšio operatoriams, turintiems patirties valdant didelius informacijos srautus ir jau įgijusiems vartotojų pasitikėjimą.

Mikro mokėjimai naudojant SMS yra patrauklūs vartotojams, nes nereikia investuoti į naują technologiją ir dalintis kredito informacija su trečiąja šalimi. Kaip ir bet kuri technologija, mokėjimai naudojant SMS turi tiek privalumų, tiek trūkumų, lyginant su kitais mokėjimo būdais. Pagrindiniai privalumai būtų šie:

• Mobiliųjų telefonų naudojimo paprastumas ir paplitimas; • Nereikia naujos programinės įrangos;

VI – 46

Mikro mokėjimų aplinka

• Paslauga yra lengvai pritaikoma interneto puslapiuose; • Mobiliojo ryšio operatoriai yra trečioji šalis kuria vartotojas pasitiki. Dar vienas žymus mobiliųjų telefonų kaip platformos mikro mokėjimams panaudojimo privalumas yra

sąlyginai nedidelis operatorių skaičius, kuris dalinasi rinką. Todėl reikia reliatyviai mažai susitarimų tam, kad padengti visą rinką. Tokie tarptinkliniai susitarimai garantuoja, kad pajamos yra pasidalinamos tarp skirtingų operatorių.

Pagrindiniai trūkumai [2], ribojantys mokėjimų naudojant SMS paplitimą, yra: • Labai mažų mikro mokėjimų (mažesnių nei vienas euras) operacijų palaikymo kaštai; • Neapibrėžti rinkos vartotojų poreikiai ir jų įgyvendinimo ribojimai; • Didelis paslaugas ir produktus siūlančių organizacijų skaičius; • Skirtingų tipų m-komercijos operacijos; • Skirtingi matavimo vienetai ir palaikymo reikalavimai produktams ir paslaugoms (standartų trūkumas); • Sudėtingas saugumo užtikrinimas; • Įrenginių ribojimai. Nors mobilios bevielės taikomosios programos jau seniai naudojamos nišinėms aplikacijoms, naujosios mo-

bilios bevielės taikomosios programos orientuojasi į individualius vartotojus. Todėl yra siekiama integruoti duomenų ir balso funkcionalumą viename personaliniame įrenginyje. Ar įrenginys būtų mobilusis telefonas, turintis interneto naudojimo funkcionalumą, ar kišeninis duomenų apdorojimo įrenginys, turintis telefono funkciją, tikslas yra suteikti individualiam vartotojui mobilų bevielį ryšį su duomenų apdorojimo taikomosiomis programomis.

Bankai, kelionių agentūros ir mažmenininkai atranda, kad bevielės taikomosios programos suteikia jų klientams alternatyvius informacijos pasiekimo būdus. Točiau m-komercija nepakeičia realiai vykstančių ar kompiuteriu vyk-domų operacijų. Todėl m-komercija turėtų būti laikoma papildoma verslo galimybe, bet ne pakaitalu tradiciniam verslui ar e-komercijai. Yra svarbu charakterizuoti produktus ir paslaugas, už kuriuos būtų perspektyvu atsiskaityti naudojant SMS kaip alternatyvą įprastiems apmokėjimo būdams. Tokių produktų ir paslaugų pavyzdžiai: bilietai į renginius (koncertus, teatrus, filmus, varžybas), greito maisto produktai (mineralinis vanduo pardavimo automate), sąskaitos (restorane, mokesčiai). Jie pasižymi tokiomis savybėmis [7]:

• Ribotas, bet tikslus pasirinkimas; • Nuspėjamas pasiekiamumas; • Impulsyvus pirkimas; • Naudojimosi patogumas. IDC organizacija pateikia tris rekomendacijas [1], diegiant mobilias bevieles taikomąsias programas: • Nustatyti vartotojų poreikius. Vartotojų poreikių supratimas ir tiesioginės naudos, kurią suteiks bevielė

taikomoji programa, radimas yra svarbiausias tokių technologijų diegimo uždavinys. • Sukurti taikomąsias programas. Mobilūs įrenginiai nepakeis asmeninių kompiuterių. PDA ir WAP telefonai

nėra kompiuterių pakaitalai, todėl taikomosios programos jiems yra skirtingos. • Nustatyti m-komercijos strategiją. Mobiliųjų bevielių įrenginių naudojimo strategija ir tradicinio verslo ar

e- komercijos strategija yra skirtingos. Todėl m-komerciją rekomenduojama naudoti kaip tradicinio verslo ar e-komercijos papildymą, bet ne alternatyvą.

M-komercija suteikia vartotojams papildomą pasirinkimą. Tačiau didžioji dalis operacijų vis dėlto yra vykdoma ne mobiliaisiais įrenginiais. Todėl investicijų į bevieles aplikacijas atsipirkimas ir pelnas yra sunkiai identifikuojami bendrosiose organizacijos pajamose.

3. Taikomosios programos

Yra sukurta nemažai susitarimų ir produktų, palaikančių mikro mokėjimus [5]. Reikėtų paminėti Palm ir Visa partnerystę,Visa International mokėjimo operacijų sistemą, City Group ir AOL sandėrį ir daugelį kitų.

Nexage, Inc. [6] - e-komercijos programinės įrangos ir paslaugų kompanija, išleido mCASH 2.0, pritaikytą Java platformai, ir pritaikė juos marketinginiuose susitarimuose su Japonija ir Brazilija. Bevieliai pirkėjai ir pardavėjai gali diegti Nexage mCASH 2.0 mikro mokėjimuose ir virtualios kortelės sprendimuose naudodami Java platformą. Tai suteikia vartotojams galimybę, turint mobilųjį telefoną, naudotis m-komercijos paslaugomis.

MasterCard International [5] pagamino globalią apmokėjimų apdorojimo platformą su bevielėmis aplikaci-jomis, kuri leidžia finansinėms institucijoms naudoti naujausias technologijas ir efektyviai reaguoti į dinaminius verslo aplinkos pokyčius.

VI – 47

S.Abramavičiūtė, R.Matulevičius

Turint Aria Visa kreditine kortele, kuri tinka mobiliajam telefonui ar asmeniniu kišeniniam kompiuteriui, galima mobiliai naudoti sąskaitos informaciją. Providian Financial [9] pristatė programą Aria Visa kortelių turėtojams, kuri leidžia pasiekti sąskaitas realiu laiku. Dubliuota AriaAnywhere yra nemokama paslauga ir veikia su suderintais su WAP telefonais, interneto telefonais ir sujungtais su tinklu kišeniniais kompiuteriais.

4. M-komercijos pavyzdys

Šiame skyriuje panagrinėkime galimą m-komercijos vartotojo dienos scenarijų [7]. Jis pateikiamas 1 lentelėje.

1 lentelė. Galimas m-komercijos vartotojo dienos scenarijus

Laikas Veiksmai 8:00 Išėjęs iš namų vartotojas pastebi, kad pamiršo pasiimti piniginę, tačiau dėl to visiškai nesijaudina, kadangi turi su

savimi mobilųjį telefoną su aktyvuota mikro mokėjimų funkcija. 8:05 Už autobusą iki geležinkelio stoties ir traukinio bilietą jis sumoka naudodamasis mobiliuoju telefonu. 8:20 Nusiperka mineralinio vandens, sumuštinių ir rytinį laikraštį iš skirtingų pardavimo automatų, įtraukiančių šias

tranzakcijas į mobilaus telefono sąskaitą. 10:00 Darbe iš priimančio mikro mokėjimus automato nuperka gaiviųjų gėrimų savo kolegei. Kiek vėliau ji reikiamą sumą

persiunčia kaip kreditą į jo sąskaitą. 12:00 Valgykloje vartotojas susimoka už pietus naudodamasis mobiliojo telefono mikro mokėjimų sąskaita. 16:00 Darbo laiko pabaigoje atsisiunčia savo mėgstamos muzikos ir užsisako bilietus į kiną, kaip paskatinimą gaudamas

nemokamą leidimą parkuoti automobilį ir kredito taškų, kurie iš karto yra įtraukiami į jo telefono sąskaitą. 19:30 Kine, naudodamasis pardavimo automatais, nusiperka popkorno, pasinaudodamas jų akcija “Vieną perki, vieną gauni

nemokamai” bei priedo gauna 10% premiją. 22:00 Namo grįžta savo automobiliu, kelių mokesčius sumokėdamas mobiliuoju telefonu. 23:00 Atsiverčia kelionių agentūrų interneto puslapius, norėdamas suplanuoti atostoginę kelionę po Europą, kurios metu

mobilusis telefonas su aktyvuota mikro mokėjimų funkcija labai pravers. Jam nereikia rūpintis valiutos keitimu, kadangi visu tuo pasirūpins jo mobiliojo telefono operatorius.

Kaip matome iš pateikto scenarijaus, kuriame mikro mokėjimai yra tiek už skaitmenines, tiek už fizines prekes, šio vartotojo atliekamus veiksmus įtakoja daug potencialių pardavėjų. Naudojama visa eilė sudėtingų apmokėjimo atvejų, įskaitant kreditus, kredito kliento klientui persiuntimą, nemokamus pasiūlymus bei lojalumo premijas. Prie to reiktų pridėti potencialią pardavėjų-kliento aptarnavimo atsakomybę, skirtingų rinkos veikėjų paslaugų integravimą ir pajamų pasidalijimą, tiek vietinės tiek ir tarptautinės rinkos lygiu. Padauginę šį vieną vartotoją iš tūkstančių ir juos padauginę iš galimo siūlomų paslaugų skaičiaus, galime matyti kokie iššūkiai ir galimybės laukia mobiliojo ryšio operatoriaus mikro mokėjimų srityje.

5. Išvados

Šiame darbe nagrinėjama, kas yra m-komercija ir mikro mokėjimai, aptariami jiems keliami reikalavimai bei pristatomos kelios taikomosios programos ir technologijos, įgalinančios atlikti mikro mokėjimus naudojant SMS ir mobiliąsias technologijas. M-komercija yra sudėtinga taikomųjų programų integravimo sritis tarp mokėjimų apdorojimo centrų, pardavėjų ir pirkėjų. Bevielės technologijos turi būti laikomos priedu prie esančios taikomųjų programų infrastruktūros. Tačiau tai perspektyvi ir vis didesnę paklausą įgyjanti verslo sritis.

Tolesniuose darbuose bus naginėjama galimybė vietoj mobilaus ryšio operatorių naudotis bankinių sistemų paslaugomis, atliekant mikro mokėjimus naudojant SMS. Tam reikalingas mokėjimų naudojant SMS mobiliąsias technologijas paklausos tyrimas.

Literatūros sąrašas [1] IDC, mCommerce: A Competitive Necessity, Not a Commerce Strategy, 2001,

URL: http://www.idc.com/getdoc.jhtml?containerId=ebt20010329. [2] MobileInfo, M – Commerce: Limiting Factors,

URL: http://www.mobileinfo.com/Mcommerce/limiting_factors.htm. [3] MobileInfo, M-Commerce: Payment Systems and Issues,

URL: http://www.mobileinfo.com/Mcommerce/payment_Systems.htm. [4] MobileInfo, M – Commerce: Products, Services & Applications Suited for M-Commerce

URL: http://www.mobileinfo.com/Mcommerce/prod_serv_appl.htm.

VI – 48

http://www.mobileinfo.com/Mcommerce/limiting_factors.htm

Mikro mokėjimų aplinka

VI – 49

[5] MobileInfo, MasterCard Unveils New Payment-Processing Platform URL: http://www.mobileinfo.com/News_2001/Issue18/Mastercard_payment.htm.

[6] Nexage mCash 2.0. URL: http://industry.java.sun.com/javanews/stories/story2/0,1072,44388,00.html. [7] Radicchio, White Paper on Micro – Payments, MCIG, URL: http://www.radicchio.org/downloads/mcig016_02r5.pdf [8] Strand Consult, Mobile Operators and SMS Will Revolutionize Payments on the Internet,

URL: http://flashcommerce.com/articles/01/05/02/082211.html. [9] Wirelessly link to your credit card info, 2001,

URL: http://www.cnn.com/2001/TECH/computing/02/02/wireless.credit.card.idg/index.html.

Micro Payment Environment

M-commerce is a new business opportunity to traditional business and e-commerce. Organizations, which feel that could offer a possibility to pay for their goods via SMS, should develop a new strategy, which would be able to grow and to adapt to a dynamically changing market. Micro payments are payments of small amount. They are important in m-commerce systems. In this paper the requirements for micro payment systems are analyzed and existing applications and technologies, which enable micro payments via SMS, are surveyed.