Funkcinių uždavinių informacinių modelių tyrimas

Įvadas Darbe nagrinėjama esamos (angį. legacy) informacinės si­stemos sąvoka. Nustatytos būdingos teigiamos ir neigiamos savybės bei funkcinių uždavinių išgavimo prasmė. Aptarti galimi funkcinių uždavinių realizavimo programų sistemoje būdai ir aprašytas algoritmas kaip atpažinti ir ištraukti esamas funkcinių uždavinių realizacijas. Verslo taisyklė - tai nesudėtingas sakinys, tikrinantis duomenų teisingumą, atliekantis būtinus paskaičiavimus ar valdantis duomenų pavaizdavimą. Programuotojas sukuria šių taisyklių rinkinį aprašantį įstaigos veiklą. Toks principas yra labai priimtinas, kai veiklos sąly­gos greitai keičiasi - tada užtenka pakeisti tik taisykles ir nereikia liesti ir keisti pačios DB sistemos (skirtingai nuo procedūrinio pro­gramavimo). Viena didžiausių problemų funkcinių uždavinių panaudojimui yra jų kiekis ir sunkiai nuspėjama tarpusavio sąveika. Taisyklėms veikiant kartu atsiranda įvairūs konfliktai, kai viena iš dviejų vykdomų taisyk­lių priima užduotį, o kita atmeta ir t.t. Darbe nagrinėjamos problemos, susijusios su funkcinių uždavinių rinkinio damos užtikrinimu. Trumpai apžvelgta funkcinių uždavinių samprata, daug dėmesio skirta lo­gika pagąstiems išvedimo būdams, kurie panaudoti funkcinių uždavinių rinkinių konfliktų pašalinimui. Suformuluotas metodas, leidžiantis XML atvaizduotas funkciniai uždaviniai transformuoti į predikatus bei komponuoti į išsamius ir neprieštaraujančius funkcinių uždavinių rinkinius. Kad funkciniai uždaviniai būtų lengva keisti, reikia, kad jos būtų lo­giškai atskirtos nuo duomenų bei programos struktūros. Dažniausiai jos įsimenamos taisyklių interpretatoriuje, kuris yra priemonė, lei­džianti peržiūrėti, pakeisti ar tvarkyti tas taisykles. Esamą sistemą galima apibrėžti kaip visą verslo sistemą su ją palaikančia informacine sistema ir realizacija konkrečioje programų sistemoje. Svarbu pastebėti, kad kai šnekame apie funkciniai uždaviniai , tai žinome, kad jos egzistuoja tik verslo sistemoje, o informacinėje sistemoje dalis funkcinių uždavinių yra konvertuojama į informacinių si­stemų taisykles ir tik dalis jų realizuojama programų sistemoje pro­gramų sistemų taisyklių pavidalu. Funkcinių uždavinių išgavimo svarba George Bakehouse ir Tony Wakefield f J] išskyrė esamų sistemų privalumus: • Darbuotojai pripratę prie darbo su esama sistema, • Patikima, • Verslui kritinė, • Saugo visą verslo informaciją, ir trūkumus: • Lėta • Brangus palaikymas • Nėra dokumentacijos • Sunku atrasti praktines žinias (įgūdžius). • Gali stabdyti vystymą Taigi matome, kad nors darbuotojai ir yra pripratę prie darbo su esama sistema bei ji yra pakankamai patikima, verslui kritinė, bet dėl lėtumo, brangaus palaikymo ir vystymosi galimybių stabdymo dažnai būna priimamas sprendimas atnaujinti, pakeisti programinę įran­gą, palaikančią verslo informacinę sistemą. Tokiu atveju labai svarbus lieka vienintelis esamos sistemos privalumas -joje yra išsaugota visa verslo informacija, o taip pat ir funkciniai uždaviniai . M. Chisholm [2] dar 2004 m. pastebėjo, kad programuotojai 40 % laiko skiria aplikacijos atgalinės inžinerijos atlikimui, tam, kad ją suprastų, galėtų padaryti pakeitimus, taisyti klaidas ar integmoti su kitomis aplikacijomis. Viso šio užtrukimo priežastimi dažnai yra ta, kad dokumentacija yra beveik visada nepilna, pasenusi ir nepatikima. Efektyvus funkcinių uždavinių perpanaudojimas sistemų gyvavimo cikle leidžia paspartinti patį informacinių sistemų reorganizavimo procesą. 1.Funkcinių uždavinių informacinio modelio tyrimo teoriniai aspektai 1.1.Funkcinių uždavinių realizavimo programos Prieš pradedant nagrinėti kaip reikia ištraukti funkciniai uždaviniai iš esamo kodo, pirmiausiai reikia aptarti tai, kokiais būdais jos gali būti realizuotos. Pagal Taveter K. [3] galimi realizacijos variantai patei­kiami 1-oje lentelėje. 1 lentelė. Funkcinių uždavinių realizacijos programų sistemoje būdai Funkcinių uždavinių konceptas Realizacija programų sistemoje Apribojimai Programavimo kalbų If-then sakiniuose, DOMAIN, CHECK ir CONSTRAINT parametrai SQL lentelių apibrėžtyse, CREATE ASSERTION sąlygos SQL duomenų schemos apibrėžtyse. Išvedimo taisyklės Deduktyvių duomenų bazių (arba Prolog) taisyklės; SQL CREATE VIEW sąlygos. Reaktyvios taisyklės Programavimo kalbų If-then sakiniuose; CREATE TRIGGER sąlygos SQL; generavimo (production) taisyklės ekspertinėse sistemose. Leidimų taisyklės Rolėmis pagrįstos prieigos teisės (access rights). Dažniausiai atgalinė inžinerija pradedama nuo išeities kodo ir iš jo išgaunama informacija apie produkto struktūrą. Bet kai kurios priemonės ir technikos pirma ištraukia iš išeities kodo funkciniai uždaviniai ir duomenis. Seniai pripažinta, kad organizacijos programų siste­ma yra vertinga todėl, kad savy turi žinias apie organizaciją, jos kli­entus, tikslus, strategiją, taikomus apribojimus. Funkcinių uždavinių išgavimas apima • Analizę • Nereikšmingų taisyklių eliminavimą • Žymėjimą, jungimą ir pertvarkymą į naują formą. Tik 20-30 % esamos sistemos kodo gali būti susieta su kokia nors funkcija [5]. Likusioji dalis kodo tiesiog yra skirta aprašy­ti programų sistemos realizavimui ir nesvarbios verslo vykdymui (2 lentelė). Loginis segmentas, kuris nebuvo niekada vykdytas, nepaisant duomenų reikšmių. Aptinkamas loginis segmentas, kuris nevykdomas dėl nustatytų duomenų reikšmių (dėl verslo pasikeitimų tam tikri duomenys nebeįgyja senųjų reikšmių). Aptinkamas loginis segmentas, kuris pradžioje nustato kintamojo ar įrašo reikšmę į nulį ar nuli. Kodo dalys, susijusios su tiesioginiu duomenų skaitymu, rašymu, iškvietimu. Randamos vietos, kuriose duomenys išvedami į ekraną ar ataskaitų formas. Sąlygos, tikrinančios duomenų išvedimo, išvedimo klaidas. 2 lentelė. Programų sistemos realizavimo logika 1 2 Klaidų apdorojimo logika Randamos privalomai apdorojamos klaidos, iššaukiančios išimčių pranešimus ar darbo nutraukimą. Darbas su duomenų struktūromis Atskiriamos darbo su duomenų bazėmis dalys, kurios susijusios su kodo vietomis, nedirbančiomis verslo logikai. Aplinkos logika Aplinkos nustatymus keičiančios dalys Šalutinė ir bereikalinga logika Randamos besikartojančios(perteklinės) sąlygos ar nesuderinami patikrinimai. Eliminavus netinkamas programų sistemos dalis, reikia nustatyti taisyklių rūšis, kurias norima ištraukti iš kodo, išsaugoti ar pakartoti­nai panaudoti, nes kiekviena jų turi savo aprašymo ir realizavimo ga­limybes (1 lentelė). Kiekviena sąlyga ir su ja susiję sakiniai gali atstovauti verslo tai­syklę ar jos dalį. Čia kyla kelios problemos. Ne kiekviena atpažinta taisyklė nors ir susijusi su verslo taisykle visiškai padengia ją, taigi tenka sugebėti nagrinėti ne tik kodą, bet ir jo aplinką. Kita problema yra susieti kelias programos kodo ištrauktas taisykles į vieną verslo taisyklę. Ištrauktas ir sutvarkytas funkciniai uždaviniai reikia dokumentuoti iš­saugoti tinkamu formatu, kad ateityje būtų pakankamai lengvas mo­difikavimas ar pakartotinis panaudojimas. Tam tinka taisyklių repozitonius. Apibendrintai galima teigti, kad organizacijos programų sistema yra vertinga todėl, kad savyje turi žinias apie organizaciją, jos klientus, tikslus, strategiją, taikomus apribojimus, esančias funkciniai uždaviniai . Kad funkciniai uždaviniai būtų lengva keisti, reikia, kad jos būtų logiškai atskirtos nuo duomenų bei programos struktūros. Efektyvus funkcinių uždavinių pakartotinis panaudojimas sistemų gyvavimo cikle leidžia paspartinti patį informacinių sistemų reorga­nizavimo procesą. Taisyklių paiešką ir ištraukimą iš programų sistemų palengvi­na pirmiau atliekamas netinkamų kodo dalių eliminavimas. 2.Funkcinių uždavinių informacinių modelių keitimas Siekiant prisitaikyti prie nuolat besikeičiančios verslo aplinkos, būtina siekti, kad bendrovės informacinė sistema atitiktų verslo po­reikius bet kuriuo laiko momentu. Informacinės sistemos modifika­vimo laikas ir sąnaudos turi būti minimalios. Vienas iš būdų užtikrin­ti, kad sistema būtų lengvai pritaikoma prie besikeičiančių verslo sąlygų yra verslo taisyklėmis grindžiamos metodikos taikymas si­stemos kūrimo procese [1]. Taikant šią metodiką taisyklės yra atski­riamos nuo programos kodo. Tokiu būdų informacinė sistema tampa greitai modifikuojama, kadangi nereikia keisti programos kodo kiek­vieną kartą, kai keičiasi situacija versle. Taisyklių pakeitimus gali at­likti verslo atstovas. Dažnai dalis funkcinių uždavinių nėra realizuojamos programų si­stemų lygmenyje, kadangi jos kinta ypač dažnai. Siame straipsnyje nagrinėjama galimybė išplėtoti verslo taisyk­lėmis pagrįstos programų sistemos kūrimo metodiką papildant funkciniai uždaviniai privalomumo lygmeniu siekiant padidinti kuriamos pro­gramų sistemos skaidrumą ir lankstumą. 2.1.Funkciniai uždaviniai su privalomumo lygmeniu Suteikti taisyklėms privalomumo lygį nėra nauja idėja versle, ta­čiau programų sistemų lygmenyje iki šiol tai nebuvo realizuojama. Siūlomas toks funkcinių uždavinių privalomumo lygmens apibrėžimas: „privalomumo lygmuo nusako taisyklės rangą gradacijos skalė­je ir aprašo, kokių veiksmų reikia imtis, kad taisyklės būtų lai­komasi. " „something that represents a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule inforce " Verslo motyvacijos modelyje [2] siūlomi šie privalomumo lyg­menys: • privalomumo lygmuo: griežtas (angį. strict) apibrėžimas: griežtai privalomas (jei taisyklė bus pažeista, pasekmės yra neišvengiamos); • privalomumo lygmuo: atidėtas (angį. deferred) apibrėžimas: atidėtas privalomumas (griežtai privalomas, bet privalomumą užtikrinantys veiksmai gali būti atidėti- pvz. laukiama resurso su reikiamais įgūdžiais); • privalomumo lygmuo: su patvirtinimu (angį. pre-authorized) apibrėžimas: galimas nepaisymas po patvirtinimo (privaloma, bet galimos išimtys, kurias gali leisti sistemos aktoriai turintys šia teisę); • privalomumo lygmuo: atidėto įvertinimo (angį. post-authorized) apibrėžimas: taisyklę pažeisti galima, tačiau pažeidimo atvejis vėliau gali būti nagrinėjamas ir gali būti imtasi sankcijų pažeidėjo atžvilgiu; • privalomumo lygmuo: galima nepaisyti (angį. override) apibrėžimas: galimas taisyklės pažeidimas, be tolesnių sankcijų; • privalomumo lygmuo: gairės (angį. guidelines) apibrėžimas: gairės rekomenduoja, kaip derėtų elgtis tam tikroje situacijoje Reikėtų pastebėti, kad tai tik siūlomi privalomumo lygmenys. Priklausomai nuo verslo modelio, privalomumo lygiai gali skirtis. Versle egzistuoja prievartos mechanizmas, kuris verčia laikytis tai­syklių. Jei jo nebūtų, tada taisyklių naudojimas netektų prasmės. Nuo taisyklės privalomumo lygmens priklauso, kokių veiksmų bus imtasi jei taisyklės nebus laikomasi. Privalomumo lygmuo gali kisti pri­klausomai nuo situacijos versle. Pavyzdžiui taisyklei - „Pardavimo kaina turi būti didesnė už savikainą" gali būti suteiktas privalomumo lygmuo - „griežtai privaloma", kadangi priešingu atveju šios taisyk­lės nepaisymas prieštarautų vienam pagrindinių verslo tikslų- už­dirbti akcininkams pelną. Tačiau versle dažnai pasitaiko tokios situa­cijos, kada taisyklės nepaisymas gali atnešti daugiau naudos nei taisyklės paisymas. Prekės pardavimas už kainą kuri yra mažesnė už savikainą yra nenaudingas verslui, tačiau jei tai sezoninė prekė ir vit­rinoje liko tik keli vienetai šios prekės, vertėtų pasvarstyti, gal geriau šia prekę parduoti pigiau tuo atlaisvinant vietą naujai prekei. Šiuo at­vejų būtu atliekamas veiksmas prieštaraujantis taisyklei kuri riboja pardavimo kainą. Šiai taisyklei vertėtų priskirti privalomumo lygme­nį- „su patvirtinimu" kuris leistų parduoti prekę už kainą, kuri yra mažesnė už savikainą, bet tik tuo atveju jei šį pažeidimą patvirtina si­stemos aktorius turintis šią teisę. Suteikti šiai taisyklei privalomumo lygmenį- „galima nepaisyti" būtų netikslinga, kadangi šiuo atveju pardavėjas gautu teisę priimti sprendimą dėl prekių kainos, tokiu bū­du jis galėtu piktnaudžiauti šia teise. Tačiau yra taisyklių, kurių jokiu būdų negalima būtų pažeisti esant, bet kokioms aplinkybėms. Pavyzdžiui negalima sąskaitoje nurodyti parduodamos prekės kiekį didesnį nei yra sandėlyje. Ši taisyklė negalėtų būti iš principo pažeista, ka­dangi ji prieštarautų apskaitos standartams ir logikai. Šiai taisyklei turi būti suteiktas lygmuo „griežtas". Neaprašius tokių situacijų iškil­tu kita problema - sistemos aktoriai nežinotų kaip jiems elgtis, todėl jų sprendimai nebūtų pagrįsti [4]. Tokiu atveju, jei sistema nenuma­tytu galimybės pažeisti taisyklę, jos pažeidimas tikriausiai vis tiek vyktų, bet jau už sistemos ribų, o tai mažintų visos verslo sistemos skaidrumą. Jei nagrinėti tik verslo sistemą, galima pastebėti kontrolės vėla­vimo problemą, kadangi sistemos aktorius gali laisvai pažeisti taisyk­lę, o kontroliuojantis aktorius apie šį pažeidimą sužinoti, kai pasek­mių išvengti jau nebegalima. 2.2.Funkcinių uždavinių su privalomumu realizacijos programų sistemų lygmenyje problematika Reikėtų pastebėti, kad suteikiant verslo taisyklėms privalomumo lygmenis arba prioritetus [5] sprendžiamos skirtingos problemos. Su­teikiant VT privalomumo lygmenį galima, priklausomai nuo verslo modelio ir privalomumo lygmens, leisti arba neleisti ignoruoti tai­syklę, o ignoravimo atveju atlikti nustatytus veiksmus. Priskiriant VT prioritetą yra valdomas taisyklių vykdymo eiliškumas tuo atveju, kai įvykus konkrečiam įvykiui, ADBVS turi vykdyti keliuose trigeriuose numatytus veiksmus. Anksčiau esančiame skyrelyje buvo minėta, kad kyla problemos siekiant vykdyti taisyklių laikymosi kontrolę, kadangi verslo siste­moje aktorius atsakingas už šią kontrolę apie pažeidimą gali sužinoti pavėluotai. Ši problema turėtų būti sprendžiama IS ir PS lygmenyse realizuojant prevencinę taisyklių kontrolę, kurios metu nepageidau­jami sistemos aktoriaus veiksmai būtų draudžiami. Šią kontrolę ga­lima būtų realizuoti vartotojo sąsajos [6] ir ADBVS pagalba [7]. Var­totojo sąsajoje gelėtų būti atliekama pirminė verslo taisyklės kontrolė. Pavyzdžiui, kiekvieną kartą įvedus prekes kieki, būtų vyk­doma užklausa, kuri tikrina ar šis kiekis nėra mažesnis už esamą sandėlyje. Kitas pavyzdys, kada vartotojas atlieka įrašo apie atostogas - įvedimą. Šiuo atvejų reikėtų apriboti galimybę įvesti atostogų pra­džios datą, kuri yra ankstesnė, nei šios dienos data. Tokiu atveju var­totojo sąsaja turėtų būti generuojama dinamiškai. Atlikti taisyklių tikrinimą vien tik vartotojo sąsajos lygmenyje nepakanka. Siekiant užtikrinti duomenų saugumą ir vientisumą (angį. consistency) būtina atlikti tikrinimą ir ADBVS priemonėmis. 3.Funkcinių uždavinių rinkinio darnos užtikrinimas Šiandienos įmonės susiduria su greitai besikeičiančia verslo ap­linka ir negali laikytis pastovaus ilgalaikio veiklos modelio, Įmonės veikla ir jos veiklos modelis turi būti dinamiški. Viena didžiausių problemų funkcinių uždavinių panaudojimui yra jų kiekis ir sunkiai val­domos tarpusavio sąveikos. Taisyklėms veikiant kartu galimi įvairūs jų sąveikos konfliktai. Taisyklių potencialių konfliktų aptikimui ir logiškumui bei nuoseklumui patikrinti siūloma naudoti logika pagrįs­tus mechanizmus, tokius kaip išvedimas. 3.1.Susijusių darbų apžvalga Funkcinių uždavinių požiūris iš informacinių sistemų perspektyvos teigia, kad funkciniai uždaviniai suprantamos kaip nesudėtingas teiginys, tikrinantis duomenų teisingumą, atliekantis būtinus paskaičiavimus ar valdantis duomenų pavaizdavimą [2]. Verslo įmonės apima tūkstančius funkcinių uždavinių kombinacijų, kurios veikia operaciniame lygmenyje. Kai kalbama apie verslo tai­syklę (angį. business nde) dažniausia turime omenyje taisyklių rin­kinį (angį.: ruleset) su tam tikra jų hierarchija ir prioritetais. Viena didžiausių problemų funkcinių uždavinių panaudojimui yra jų kiekis ir sunkiai nuspėjamos tarpusavio sąveikos. Vienas iš galimų sprendimo būdų, tai perdavimo algoritmas (angį. propagation algo-rithm), skirtas statinių ECA taisyklių analizei. Analizės technika yra paremta bendro pritaikymo algoritmu, kuris yra naudojamas nuspręs­ti, kada vienos taisyklės veiksmas gali paveikti kitos taisyklės būseną ir nuspręsti, kada taisyklių veiksmai persijungia [3]. Kitas problemos sprendimo būdas galėtų būti paremtas funkcinių uždavinių prioritetų ir jų vykdymo strategijos nustatymu. Tokiu atve­ju, atsiradus konfliktams, žemesnį rangą turinti taisyklė galėtų būti tiesiog pašalinama. Dažnai minima sprendimo galimybė yra taisyklių ir su jomis susijusių procesų hierarchizacija, kai žemesnio lygmens procesai naudojantys taisykles esančias aukštesniame lygmenyje tampa tų procesų subprocesais. Kadangi verslo procesai gali būti specifikuojami verslo taisyklėmis, o funkciniai uždaviniai gali būti detali­zuojamos procesais, įvedus subprocesus taisyklės tuo pačiu gali įgyti tam tikrą hierarchinę struktūrą [4]. Dažniausiai taisyklių validavimui yra naudojama speciali simuliacija, kai tiesiog stebima ar esant tam tikroms sąlygoms sistema reaguoja adekvačiai. Taisyklių konfliktų aptikimui ir logiškumui bei nuoseklumui pa­tikrinti galima naudoti logika pagrįstus mechanizmus, tokius kaip re­zoliucija arba išvedimas, panaudojant modus ponens, atbulinį išvedi mą (angį. backward chaining), tiesioginį išvedimą (angį. fonvard chaining). Šie metodai dažniausia realizuojami išvedimo mašinose (angį. inference engine), dirbančiose pagal Rete algoritmą arba specia­liose ekspeitinėse sistemose. Algoritmai, naudojami įvertinti taisyklės elgseną duotoje situacijoje vadinami išvados darymo (angį. inference) arba funkcinių uždavinių mašina (angį. business nde engine) [5]. Išvados gavimas — tai procesas, naudojamas žynių sistemose, kad gauti naują informaciją iš jau žinomos informacijos. Išva­doms gauti reikalingos žinios, faktai ir problemos sprendimo stra­tegijos. Išvedimo mašinose dažniausia naudojami du išvadų gavimo būdai: Tiesioginis išvedimas (angį. fonvard chaining). Tai duomenų valdymo procesas; išrinkti galimas išvadas ir bandyti patvirtinti jų pagrįstumą patvirtinančiais įrodymais (tikslo valdymas arba atbulinis išvedimas). Egzistuoja ir kiti metodai, tokie kaip Rete tinklas, modus ponens, išvadų tinklas, šablonų tikrinimo metodas ir kita [6]. 3.2.Rinkinio darnos užtikrinimo metodo formulavimas Funkcinių uždavinių rinkinio darnos užtikrinimo problemos spren­dimas galėtų būti realizuotas žemiau suformuluotu metodu, naudo­jant funkcinių uždavinių transformaciją ir išvedimo logiką (1 pav.). Funkcinių uždavinių rinkinio damos užtikrinimas susideda iš dviejų procesų: išvedimo ir preliminaraus sprendimo išrinkimo. Kad funkciniai uždaviniai būtų lengva keisti, reikia, kad jos būtų lo­giškai atskirtos nuo duomenų bei programos struktūros. Dažniausiai jos įsimenamos taisyklių repozitoriuje, kuris yra priemonė, leidžianti peržiūrėti, pakeisti ar tvarkyti tas taisykles. Pasiūlytame metode funkciniai uždaviniai vaizduojame XML forma, sujungtas į specialius taisyklių rinkinius kartu su faktais, gautais iš esamų verslo duomenų (žinių bazė). Faktai saugojami atskirame XML formato faile. Duotasis funkcinių uždavinių rinkinys transformuojama į predikatus ir užkraunamas į išvedimo mašiną. Taip patikrintas rinkinio funkcionalumas, ko pasė­koje būtų gaunamos naujos išvestinės taisyklės bei patikrinamas atskirų taisyklių vientisumas, t. y. ar nėra tarp jų prieštaravimų. Taisyklių atskirimas nuo išvedimo mašinos, kuri ieško išvadų, kurios 1 pav. Funkcinių uždavinių rinkinio darnos užtikrinimo loginio išvedimo mašina metodo schema patenkina tikslą, įgalina sistemos efektyvumą saugoti ir atlikti taisyk­lių paiešką. Keičiant tikslą, gaunami skirtingi rezultatai. Metodo eksperimento uždavinys yra funkciniai uždaviniai pavaizduo­tas XML formatu transformuoti į predikatų logikos sakinius ir patik­rinti išvedimo mašinoje. Pirmiausia pagal tam tikrą sugeneruotą SRML DTD dokumentą ir XML pavaizduotas taisykles sukuriama XSLT schema, reikalinga taisyklių transformacijai į predikatų logi­kos sakinius. Pagal XSLT schemą sugeneruojami predikatų logikos sakiniai, kurie užkraunami į išvedimo mašiną. Išvedimo mašina pradžioje suriša nesusijusias taisykles į loginį tinklą. Rete tiesioginio paieškos algoritmo esmė ta, kad iŠ faktų ir jų derinių yra sukuriamas grafas - medis. Jame faktai išdėstomi ir su­jungiami taip, kad pagal taisyklių prielaidų šablonus, būtų vykdoma kuo efektyvesnė peržiūra/paieška, t. y. medis atsimena surastus faktų derinius ir taip sutaupo paieškos laiko (kai tų derinių dažnai ieško­ma). Atsiradus naujam faktui, medis minimaliai reorganizuojamas. Daugelį atvejų atlikus loginius išvedimus, turime išbaigtus sprendimus bei funkcinių uždavinių rinkinį, išreikštą predikatais. Išvedi­mo mašina gautus išsamius rinkinius būtų galima panaudoti duo­menų analizėje. Toliau šis taisyklių rinkinys gali būti konvertuoja­mas atgal į XML formatą. Taip pat išvedimo mašiną galima naudoti ir taisyklių sistemos darnos testavimui. Tam reiktų sukurti tam tikrus faktus, užrašyti juos predikatais ir fiksuoti rezultatus, kurie turi gautis. Įvedus naują taisyklę į taisyklių rinkinį reiktų užkrauti visas taisyklių rinkinio taisykles kartu su naująja ir patikrinti ar gaunamas rezultatas atitinka testuojamąjį. Toks būdas bent jau iš dalies padėtų išvengti akivaizdžių klaidų. 4.Funkcinių modelių tyrimas 4.1.Funkcinių modelių taikymas logistikoje Logistika - tai procesas, kuriame į visumą sujungiamas sinchroniškas prekių, paslaugų ir informacijos judė­jimas bei tokios funkcijos kaip transportavimas, prekių paskirstymas, atsargų valdymas, sandėliavimas, vartotojų aptarnavimas ir prekyba, kai procesai vyksta optimaliai, prekės, paslaugos ir informacija juda pagal tikslų grafiką [1]. Varančioji logistikos plėtros jėga yra būtinybė firmoms sumažinti pinigines ir laiko sąnaudas, susijusias su prekių judėjimu. Logistikos tikslą trumpai galima apibūdinti taip: įmonės sugebėjimas reikiamą prekę pristatyti į reikiamą vietą, reikiamu kiekiu ir reikiamu laiku. Kuo mažesnėmis sąnaudomis įmonė įgyvendina šiuos principus, tuo efektyvesnė jos veikla. Optimali logistika suteikia įmonei didžiulį strateginį pranašumą: trumpų ir patikimų tiekimo terminų sąskaita vienu metu yra sumažinamos išlaidos ir pagerinamas klientų aptarnavimas. Greta žemos kainos ir aukštos kokybės vartotoj ui-pirkėjui logistikos principų realizavimas tampa vis svarbesnis kriterijus, todėl efektyvi logistikos sistema ženkliai padidina įmonės konkurentabilumą. [51 straipsnyje yra pateikiamos logistikos sistemos agregatinis modelis. Siame straipsnyje yra pateikiami modeliavimo rezultatai, kurie buvo gauti sukūrus logistikos sistemos imitacinį modelį, panaudojant modeliavimo sistemą "PRANAS" [3], Sistemos konceptualusis modelis pav. Logistikos sistemos schema Logistikos sistemos sandara yra pateikta 1 pav. Sistema sudaryta iš N prekybos centrų, centrinio sandėlio ir tiekėjo. Kiekvieną iŠ prekybos centrų charakterizuoja tokie pagrindiniai parametrai: pradinis prekių kiekis, paklausa, prekių kiekio riba, kurią peržengus siunčiamas užsakymas sandeliui, siunčiamo užsakymo dydis. Prekybos cent­ruose visą laiką vyksta prekių pardavimas, kuris priklauso nuo paklausos. Periodiškai tikrinamas prekių likutis, kai jis peržengia prekių kiekio ribą, siunčiamas užsakymas į centrinį sandelį. Centrinį sandelį charakterizuojantys parametrai yra pradinis prekių kiekis, prekių kiekio riba ir tiekėjui siunčiamo užsakymo dydis. Gavus užsakymą iš prekybos centro tikrinama, ar jis gali būti išpildytas, t.y. ar yra prekių sandelyje. Atidavus prekes prekybos centrui, tikrinama, ar likęs prekių kiekis neperžengia prekių kiekio ribos. Jeigu šią ribą peržengia, siunčiamas užsakymas tie­kėjui. Jei prekių sandelyje nėra, atėję užsakymai yra statomi į užsakymų eilę. Gavus prekes iš tiekėjo, aptarnaujami eilėje esantys prekybos centrų užsakymai. Priimama prielaida, kad tiekėjas visada turi prekių. Vienas svarbiausių logistikos elementų yra prekių atsargų valdymas, t.y. balanso tarp "įplaukiančių" ir "išplau­kiančių" prekių palaikymas greitam prekių judėjimui užtikrinti. Tobulas balansas užtikrina pakankamą prekių kiekį paklausai patenkinti laikant minimalias atsargas. Tiek per didelės, tiek per mažos prekių atsargos sąlygoja tam tikrus nuostolius ir be abejonės labai įtakoja visos logistikos sistemos darbo efektyvumą. Siekiant padidinti logistikos sis­temos funkcionavimo efektyvumą, pravartu panagrinėti plačiau, kokios dedamosios sudaro prekių atsargų valdymo nuostolius ir kaip juos galima minimizuoti. Atsargų valdyme galima išskirti dviejų rūšių nuostolius: nuostoliai dėl prekės trūkumo (pažymėkime juos S) ir nuostoliai dėl prekės pertekliaus (pažymėkime juos W). Nuostoliai dėl prekės trūkumo S susidaro tuomet, kai dėl vienokių ar kitokių priežasčių prekės kiekis yra nepakankamas ir prarandami pinigai, kurie potencialiai galėtų būti uždirbami arba sutaupomi jeigu tos prekės kiekis sugebėtų patenkinti paklausą. Kitą nuostolių dalį sudaro praradimai, kurie atsiranda dėl prarastų klientų bei sumažėjusio prekės konkurencingumo. į prekės trūkumo nuostolius S taip pat įeina ir pinigai, kurie išleidžiami tam, kad atnaujinti trūkstamos prekės padėtį rinkoje (papildomos darbuotojų pastangos, reklaminės kampanijos ir pan.). Iš čia seka, kad prekės trūkumo nuostolius S galima skaičiuoti įvertinant dvi dedamąsias: S = PP + PI, kur PP - prarastas pelnas, kuris galėtų būti uždirbamas nuo trūkstamos prekės; PI ~ papildomos išlaidos prekės likučių bei padėties rinkoje atstatymui. Siekiant minimizuoti nuostolius, susidarančius dėl prekės trūkumo, reikia didinti prekės atsargas. Kuo didesnis prekių likutis palaikomas, tuo mažesnė tikimybė, kad tos prekės paklausa jį viršys ir tuo mažesnius nuostolius patirs įmonė. Tačiau didėjant atsargoms, didėja ir nuostoliai dėl prekės pertekliaus. Nuostoliai dėl prekės pertekliaus W susidaro tuomet, kada turimos prekės kiekis viršija paklausą ir dėl to atsi­randa papildomos sandėliavimo išlaidos, prekes nusidėvėjimo bei pasiemimo nuostoliai, bei prarandami pinigų dėl jų įšaldymo dideliame prekės kiekyje: W = SI + AN + PN, kur SI - sandėliavimo išlaidos; AN - amortizaciniai nuostoliai; PN - pinigų įšaldymo nuostoliai. Taigi, nuostoliai dėl prekės trūkumo S ir nuostoliai dėl prekės pertekliaus W yra glaudžiai susiję tarpusavyje, todėl siekiant minimizuoti logistikos sistemos nuostolius ir padidinti jos veiklos efektyvumą, tikslinga nagrinėti bendrą nuostolių funkciją, kurią sudaro Šių dviejų dedamųjų suma: /V = 5+ W, kur N~ bendri logistikos sistemos nuostoliai. Tam, kad optimizuoti logistikos sistemos darbą, reikia surasti tokius parametrus, kuriems esant nuostolių funk­cijos jV reikšmė yra mažiausia, t.y. reikia rasti tokį prekės užsakymo dydį, kad prekės, turinčios tam tikrą paklausą, atsargų valdymo nuostoliai būtų mažiausi. Analitiškai paskaičiuoti nuostolių funkcijos reikšmes prie skirtingų užsa­kymo kiekių sudėtinga, nes reikia stebėti prekės sandėliavimo bei trūkumo nuostolių kitimą laike. Be to, palyginti kelias nuostolių funkcijos reikšmes galima tik tada, kai tie nuostoliai patiriami realiai. Todėl čia tikslinga panaudoti sistemos modeliavimą. Modeliuojant logistikos sistemos darbą per tam tikrą pasirinktą laikotarpį T, galima įvertinti, kiek prekės trūksta (trūkstamą prekės kiekį pažymėkime QS) ir kiek sandėliuojama per daug (perteklinį prekės kiekį pažymėkime QW). Tuomet sistemos trūkumo nuostolius, patirtus per visą modeliavimo laikotarpį, galima išreikšti taip: T $^k^QS, ,kur k - koeficientas, įvertinantis vieno kiekio vieneto trūkumo nuostolį litais, ir k = PP + PI vienam kiekio vienetui. Atitinkamai pertekliaus nuostoliai gali būti išreikšti taip: = /!j3^,kur / - koeficientas, įvertinantis vieno kiekio vieneto pertekliaus nuostolį litais, ir / = SI + AN + PN vienam kiekio vienetui. Taigi, bendri logistikos sistemos patirti nuostoliai per modeliavimo laikotarpį skaičiuojami taip: N = kYdQSi + lY4QW} Sistemos modeliavimo rezultatai Modeliavimo rezultatams gauti buvo pasirinktos kelios prekės, skirtingos pagal savo kainą, užimamą vietą sandelyje bei pelningumą, t.y. gaunamą pelną pardavus tą prekę, Modeliuojamas laiko tarpas - 1000 darbo dienų. Kiekio vienetas - paletė. Pirma pasirinkta prekė - miltai. Tai nebrangi (2.00Lt už vienetą), turinti didelę paklausą ir užimanti nemažai vietos sandėlyje (252 vienetai užima vieną paletinę vietą) prekė. Uždirbama 2% nuo vieneto kainos. Trūkumo nuostolius įvertinantis koeficientas fc=5; pertekliaus nuostolius įvertinantis koeficientas 1=7. Nuostolių funkcija šiam konkrečiam atvejui: 11)00 1000 N^5J^QSi + 71£iQWi. Sistemai buvo užduoti tokie parametrai: Prekybos centro kiekio riba 1 Sandėlyje esamų prekių kiekio riba 40 Pradinis prekybos centre esančių prekių kiekis 10 Pradinis sandėlyje esančių prekių kiekis 100 Prekybos centro pardavimas per dieną 3 Sandėlio užsakymo dydis 80 2 pav. Logistikos procesą charakterizuojanti nuostolių priklausomybė (prekė: miltai). Gautoje nuostolių funkcijoje matyti, kaip nuostoliai dėl trūkumo ir nuostoliai dėl pertekliaus įtakoja bendros nuostolių funkcijos reikšmes. Esant nedideliam užsakymo kiekiui, sistemoje susidaro trūkumai, kadangi nedidelis, nors ir dažnas, prekių pristatymas nesugeba patenkinti paklausos. Taigi, dideles pirmąsias nuostolių funkcijos reikšmes nulemia nuostoliai dėl prekės trūkumo. Didėjant užsakymo kiekiui trukumai mažėja ir nuostoliai dėl trūkumo turi vis mažesnę įtaką bendrai nuostolių funkcijai - matyti kad kreivė gana sparčiai leidžiasi iki tam tikros ribos, šiuo atveju ši riba - apie 421t. Tai minimalūs nuostoliai šiai prekei šioje sistemoje su anksčiau minėtais parametrais. Jie pasiekiami, kai užsakymo dydis yra 5-8 paletės. Toliau didinant prekių užsakymo dydį, nuostolių funkcija pradeda augti. Šį augimą sąlygoja nuostoliai dėl papildomo prekės sandėliavimo, kadangi didesni užsakymo kiekiai viršija paklausą, prekės vis ilgiau sandėliuojamos ir vis didesnę įtaką bendrai nuostolių funkcijai įgyja nuostoliai dėl sandėliavimo. Taigi, matyti, kad optimaliausias prekybos centro užsakymo kiekis šiuo atveju yra intervale [5, 8] palečių. Sekanti modeliavimui parinkta prekė - vaikiškos sauskeinės. Tai brangi (50Lt už vienetą), turinti didelę pa­klausą, užimanti daug vietos sandėlyje (98 vienetai užima 1 paletinę vietą) prekė. Uždirbamas pelnas - 3% nuo vieneto kainos. Trūkumo nuostolius įvertinantis koeficientas 4=147; pertekliaus nuostolius įvertinantis koeficientas"' /=53. Nuostolių funkcija atrodo taip: ;V = i47£gS; + 53]TQWI. Modeliuojant naudojami tie patys parametrai, kaip aukščiau pateiktam pavyzdyje. Nuostoliai. Lt Vaikiškų sauskelnių nuostolių funkcijos forma panaši į miltų nuostolių funkciją, tik bendras nuostolių lygis yra žymiai didesnis, kadangi ši prekė yra žymiai brangesnė ir pelningesnė. Didesnė kaina sąlygoja didesnius sandėliavimo nuostolius, o didesnis pelningumas - didesnius trukumų nuostolius. Minimalūs nuostoliai per visą modeliavimo laiką- apie 18000Lt ir jie pasiekiami, kai prekybos centrai užsako po 7-9 paleles. Didėjant užsakymo kiekiui ši funkcija auga greičiau negu miltų nuostolių funkcija, kadangi vaikiškos sauskelnės užima daugiau vietos sandėlyje (į vieną paletinę vietą telpa 252vnt. miltų ir tik 98vnt. vaikiškų sauskelnių). Trečia pasirinkta prekė - plaukų lakas. Tai ilgesnio vartojimo prekė, negu prieš tai buvusios, todėl jos paklausa žymiai mažesnė. Prekė maža - 1368vnt. lelpa į vieną paletinę vietą sandėlyje, jos kaina - 9Lt už vienetą. Uždirbamas pelnas - 15% nuo vieneto kainos. Trūkumo nuostolius įvertinantis koeficientas 4=1846; pertekliaus nuostolius įvertinantis koeficientas 1=116. Nuostolių funkcija: /V = 1846^. 4. Object Management Group, Semantics of Business Vocabulary and Bu­ siness Rules Specification [interaktyvus], Mareli 2006 [Žiūrėta 2007- 03-01]. Prieiga per internetą:

Daugiau informacijos...

★ Klientai rekomenduoja

Šį rašto darbą rekomenduoja mūsų klientai. Ką tai reiškia?

Mūsų svetainėje pateikiama dešimtys tūkstančių skirtingų rašto darbų, kuriuos įkėlė daugybė moksleivių ir studentų su skirtingais gabumais. Būtent šis rašto darbas yra patikrintas specialistų ir rekomenduojamas kitų klientų, kurie po atsisiuntimo įvertino šį mokslo darbą teigiamai. Todėl galite būti tikri, kad šis pasirinkimas geriausias!