VILNIAUS UNIVERSITETO KAUNO HUMANITARINIS FAKULTETAS

Transcription

1 VILNIAUS UNIVERSITETO KAUNO HUMANITARINIS FAKULTETAS VEIKLOS MODELIO TAIKYMO INFORMACIJOS SISTEMŲ INŽINERIJOS REIKALAVIMŲ SPECIFIKAVIMO IR PROJEKTAVIMO ETAPUOSE TYRIMAS Ilona Veitaitė VU KHF Informatikos inžinerijos (07T) krypties doktorantė ( ) Ataskaita Darbo vadovas: prof.dr. A.Lopata... Doktorantė: I.Veitaitė... Kaunas 2013

2 SANTRAUKA Techninėje ataskaitoje nagrinėjami informacijos sistemų (IS) inžinerijos ir žiniomis grindžiamos inžinerijos skirtumai. Analizuojamas UML diagramų generavimas IS kūrimo procese, taikant žiniomis grindžiamą posistemę, kurią sudaro veiklos meta-modelis ir veiklos modelis. Siūlomas ir teoriškai grindžiamas žiniomis grindžiamos posistemės, kaip papildomo CASE (angl. Computeraided software engineering) įrankio komponento naudojimas, siekiant išvengti empiriškumo IS kūrimo procese reikalavimų specifikavimo ir projektavimo etapuose. Raktiniai žodžiai: UML, veiklos modeliavimas, CASE įrankis, IS inžinerija, žiniomis grindžiamos sistemos. 2

3 TURINYS SANTRAUKA... 2 TURINYS... 3 ĮVADAS... 4 TRADICINĖ INŽINERIJA... 5 ŽINIOMIS GRINDŽIAMA INŽINERIJA... 6 Veiklos modelis... 7 Tradicinė IS inžinerija ir žiniomis grindžiama inžinerija... 8 UML NAUDOJIMO CHARAKTERISTIKA UML DIAGRAMŲ GENERAVIMAS IŠVADOS STUDIJŲ PLANO VYKDYMAS KITŲ METŲ PLANAS LITERATŪRA PRIEDAI IT BIS

4 ĮVADAS Informacinės sistemos (IS) tampa sudėtingesnės ir verslo procesams aprašyti nepakanka tekstinės informacijos ir elementarių schemų. Kompiuterizuotų IS reikalavimų specifikavimui ir modeliavimui taikomi specifiniai modeliai. Veiklos modeliavimas tapo neatsiejama IS kūrimo proceso dalimi, kuomet kuriamos didelės ir sudėtingos arba sąveikaujančios su kitomis sistemomis IS. Šio proceso metu modeliuojami vartotojo reikalavimai, dalykinės srities žinios, programinės įrangos architektūra ir kiti esminiai komponentai. Pastaruoju metu organizacijos veiklos modeliavimo etapas tapo svarbi projektavimo procesų dalis. Tokiu būdu, specializuoti kompiuteriniai modeliavimo įrankiai tapo neatsiejama sudėtingų IS kūrimo ir projektavimo dalimi [4]. UML yra vienas labiausiai paplitusių programinės įrangos specifikavimo standartų. Tai universali IS modeliavimo kalba taikoma daugelio metodologų ir naudojama populiariausiuose modeliavimo įrankiuose, tokiuose kaip Enterpise Architect, System Architect, MagicDraw ir kt. Ši kalba naudojama programinės įrangos, verslo logikos ir kitų sistemų aprašymui, vizualizavimui ir dokumentavimui. IS kūrimo procese sparčiai auga projektavimo įrankių įtaka. Vienas iš esminių rezultatų yra sugeneruojamas programinis kodas [17, 27]. Organizacijose nuolat vyksta veiklos procesų pokyčiai darantys įtaką veiklos valdymui. Toks veiklos tobulinimas vadinamas reinžinerija, nes veiklos koregavimas yra tiesiogiai susijęs su esamos organizacijos informacinės sistemos tobulinimu. Šiose organizacijose IS privalo atitikti kintančius veiklos poreikius, o toks IS kitimas priklauso nuo pokyčių organizacijos veikloje [2]. Organizacijų veikla informacijos sistemų inžinerijoje yra dalykinė sritis, kurią reikia kompiuterizuoti. Organizacijų veiklos valdymas, palyginus su technologinių sistemų valdymu, turi kokybinių ypatybių, kurios siejamos su žmogiškojo faktoriaus įtaka valdymo sistemos veiklai. IS inžinerijos etapai nuo modeliavimo iki kodo generavimo tradiciškai vykdomi empiriškai. Kompiuterizuojamos dalykinės srities modelis sudaromas pagal analitiko ir vartotojo patirtį, o tradicinės CASE sistemos projektiniai modeliai formuojami remiantis surinkta informacija apie kompiuterizuojamą dalykinę sritį, todėl pagrindinis vaidmuo tenka analitikui ir specifikuotos dalykinės srities žinios visiškai arba nepakankamai tikrinamos formalizuotų kriterijų atžvilgiu. Vienas iš daugelio kompiuterizuotų IS inžinerijos metodų trūkumų yra tai, kad tik dalis IS projekto modelių generuojami, nes IS projektavimo etape projektuotojas formuoja projektinius modelius remdamasis asmenine patirtimi, o ne taikydamas veiklos modelyje saugomų žinių generavimo principus. Šias problemas išsprendžia veiklos modelio, kaip pagrindinės dalykinės srities žinių saugyklos, integravimas į IS inžinerijos procesą [3]. Šiuo metu kompiuterizuota IS inžinerija, siekiant išvengti empiriškumo, plėtojama naujais žiniomis grindžiamais metodais. Žiniomis grindžiamoje kompiuterizuotoje IS inžinerijoje informacinės sistemos projektas kuriamas naudojant veiklos žinių bazėje saugomas dalykinės srities žinias, t.y. veiklos modelį, kurio sudėtis apibrėžta pagal formalius kriterijus. Tokia IS kuriama pagal organizacijos veiklos valdymo modelį. Šis modelis yra teoriškai pagrįstas ir atitinka organizacijoje naudojamų IS veiklos valdymo specifines savybes. Šiuo modeliu grindžiamas kompiuterizuotas IS taikomosios programinės įrangos kūrimas vadinamas žiniomis grindžiama IS inžinerija [3, 25]. Žiniomis grindžiamos IS inžinerijos siūlomi sistemų modeliavimo ir sprendimų priėmimo metodai ir priemonės suteikia galimybę sukurti tikslesnį ir detalesnį dalykinę sritį atitinkantį IS 4

5 projektą. Organizacijos informacinės sistemos projekto kūrėjui programuotojui sudaromos sąlygos naudoti ne tik projektavimui reikalingas žinias, kurios saugomos tradicinėje CASE įrankio saugykloje, bet ir žinių saugyklą, kurioje saugomos formaliais kriterijais patikrintos dalykinės srities žinios. Rinkoje yra nemažai veiklos modeliavimo standartų ir metodikų. Taip pat rinkoje yra įrankių automatiniam programinio kodo generavimui iš UML diagramų. UML diagramų generavimo iš veiklos modelio metodas realizuoja žiniomis grindžiamą projektavimo etapą IS kūrimo cikle [5]. TRADICINĖ INŽINERIJA Informacijos sistemų inžinerija tai informacijos sistemos kūrimo procesas, kurio vykdymo metu įgyvendinami IS kūrimo gyvavimo ciklo etapai. IS inžinerijoje kiekvienas IS kūrimo gyvavimo ciklo etapas buvo vykdomas nepriklausomai nuo kitų, nes neegzistavo kompiuterizuota visus IS kūrimo gyvavimo ciklo etapus apimanti projektinių žinių saugykla. Analitikas ir projektuotojas, taikydami tradicinės arba objektiškai orientuotos IS inžinerijos metodus, IS projektus vykdydavo nekompiuterizuotai arba naudojant specifinės paskirties kompiuterizuotas priemones, taikomas konkrečiam vartotojų poreikių specifikacijos uždaviniui spręsti. Vėliau pradėti realizuoti kompiuterizuoti IS kūrimo metodai. IS kūrimas buvo vykdomas taikant kompiuterizuotus IS kūrimo įrankius CASE sistemas, kurios apėmė dalį IS kūrimo gyvavimo ciklo projektavimo, dokumentavimo ir kodavimo etapus. Analitikas ir projektuotojas IS konceptualaus ir detalaus projektavimo etapų vykdymui naudojo CASE sistemos IS projektavimo paskirties įrankius, o programuotojas praktinės realizacijos etape naudojo įrankius kodui generuoti. Šiuo atveju, kompiuterizuota CASE sistema buvo grindžiama tradicinės IS inžinerijos ir (arba) objektiškai orientuotos IS inžinerijos metodais [4]. Vystantis tradicinei IS inžinerijai CASE sistemos apėmė visą IS kūrimo gyvavimo ciklą nuo veiklos modeliavimo iki taikomųjų uždavinių kodo generavimo. Šiuos gyvavimo ciklo etapus realizuoja CASE įrankio komponentai (Pav. 1). IS inžinerijos priemonėse integruotas veiklos modeliavimas [4]. Pav. 1 Tradicinės IS inžinerijos CASE įrankio komponentai (Sudaryta pagal [9]) CASE sistemos pradėtos taikyti ne tik IS inžinerijai, bet ir organizacijos veiklai modeliuoti, veiklos reinžinerijai. CASE sistemos papildytos veiklos modeliavimo įrankiais, o CASE sistemos saugykla veiklos modelių posisteme. Sistemos analitikas pagrindinis CASE sistemos veiklos modeliavimo įrankių vartotojas. Kompiuterizuotas IS kūrimo procesas grįstas projektinių IS modelių kūrimo seka, kur kiekvienas kito projektavimo etapo modelis kurtas interaktyviai, dalyvaujant analitikui, projektuotojui ar programuotojui. Tokia CASE sistema automatiškai generavo tik duomenų bazės logines schemas, vartotojo sąsajos fragmentus, taip pat IS kodą, kurį vėliau iš esmės turėjo koreguoti programuotojas. Taigi, kompiuterizuotoje tradicinėje IS inžinerijoje, IS kūrimo gyvavimo ciklas pradedant pradiniu ir baigiant paskutiniu jo etapu vyksta 5

6 empiriškai, o daugelis CASE įrankiuose taikomų projektinių modelių yra generuojami tik iš dalies ir juos pilnai realizuoti gali tik analitikas remdamasis empirine patirtimi [4]. ŽINIOMIS GRINDŽIAMA INŽINERIJA Kompiuterizuotos IS inžinerijos konkretūs metodai kuriami remiantis bendrais reikalavimais, kuriuos susistemina pasirinkta metodologija. Yra išskiriami tokie būtini žiniomis grindžiamos IS inžinerijos metodologijos komponentai [8]: Veiklos srities modeliavimo teorinis pagrindas organizacijos veiklos teorinis modelis, kurio paskirtis identifikuoti būtinus ir pakankamus IS inžinerijai veiklos komponentus, kurie realizuoja veiklos srities valdymą. Veiklos teorinio modelio pagrindu sudarytas veiklos modelis aprašo veiklos srities valdymą. Organizacijos veiklos teorinis modelis tai veiklos valdymo formalizuotas modelis, kuris identifikuoja veiklos komponentus, jų sąveikas, veiklos valdymo ir jų sąveikas. Veiklos žinių sudėties teorinis pagrindas veiklos meta-modelis. Remiantis IS kūrimo gyvavimo ciklo etapais veiklos teorinio modelio komponentai ir jų sąveikos aprašomi veiklos meta-modeliu. Veiklos meta-modelis struktūrinis modelis, kuris specifikuoja būtinų ir pakankamų IS inžinerijai veiklos valdymo komponentų savybes ir sąsajas. Žiniomis grindžiamos IS inžinerijos proceso teorinis pagrindas IS inžinerijos proceso modelis (metodologija), kuris pagrindžia veiklos žiniomis grindžiamo IS kūrimo eigą, naudojant veiklos modelį kaip papildomą žinių šaltinį šalia analitiko ir vartotojo. Kompiuterizuotų IS inžinerijos sistemų kūrimo pagrindas yra žiniomis grindžiamos IS inžinerijos priemonės: veiklos modeliavimo metodai, IS projektavimo modeliai, taikomųjų uždavinių kodo formavimo metodai. Žiniomis grindžiamo IS kūrimo gyvavimo ciklo etapams realizuoti reikalingi tinkami įrankiai praktiniai žiniomis grindžiami modeliavimo būdai ar modelių rinkiniai. Žiniomis grindžiami praktiniai modeliavimo metodai skirti tradicinių CASE sistemų funkcionalumo plėtrai, sukuriant žiniomis grindžiamas intelektualias CASE sistemas. Pav. 2 Žiniomis grindžiamos IS inžinerijos CASE įrankio komponentai (Sudaryta pagal [1]) Kompiuterizuotos žiniomis grindžiamos IS inžinerijos projekto valdymo pagrindas CASE sistemos žinių posistemė (Pav. 2). Žiniomis grindžiamos CASE sistemos žinių posistemės bazinis komponentas yra veiklos žinių bazė, kurios būtini komponentai yra veiklos meta-modelio specifikacija ir konkrečios veiklos srities veiklos modelis. Žinių posistemė dar vienas aktyvus IS inžinerijos proceso dalyvis, žinių šaltinis (šalia žmogaus), kurio paskirtis yra verifikuoti IS gyvavimo ciklo etapų rezultatus. Žinių posistemė interaktyvus IS inžinerijos proceso dalyvis. 6

7 Pav. 3 Žiniomis grindžiamos posistemės ryšys su veiklos modeliu ir veiklos meta-modeliu CASE įrankyje Žiniomis grindžiamos CASE sistemos sudėtyje būtini tokie veiklos žinias organizuojantys komponentai: CASE sistemos žinių posistemė, kurios branduolys yra veiklos žinių bazė, talpinanti veiklos meta-modelio specifikaciją ir konkrečios veiklos srities modelį, atitinkantį meta-modelyje saugomus apribojimus [11]. Principinė žiniomis grindžiamos posistemės ryšio su veiklos modeliu ir veiklos meta-modeliu CASE įrankyje schema pateikiama paveikslėlyje (Pav. 3). Veiklos modelis Veiklos meta-modelis tai formaliai apibrėžta veiklos modelio struktūra, sudaryta pagal formalizuotą veiklos modelį, atitinkantį bendruosius valdymo teorijos principus (Pav. 4) [6]. Tai žinių apie kompiuterizuojamą dalykinę sritį šaltinis, skirtas verslo procesų reinžinerijai ir IS inžinerijai. Šis veiklos meta-modelis yra detaliai nagrinėjamas Vilniaus universiteto ir Kauno technologijos universiteto mokslininkų darbuose [6, 7]. Pav. 4 Veiklos meta-modelio klasių modelis [6] Veiklos modelio pagrindu, yra modeliuojami organizacijoje vykstantys procesai, įvertinant organizacijos aplinkos poveikį pačiai organizacijai. Veiklos modeliavimas apima šias sudėtines dalis: 7

8 funkcijas, elgseną, išteklius ir organizaciją. IS inžinerijoje svarbu unifikuoti veiklos modeliavimą, nes kiti funkcionuojantys veiklos modeliai neatitinka veiklos modeliavimo reikalavimų IS inžinerijos srityje [13]. Todėl IS inžinerijoje yra siekiama naudoti formalizuotą žinių apie veiklos valdymą struktūrą veiklos meta-modelį. Veiklos meta-modelyje yra integruoti skirtingi veiklos modeliavimo požiūriai ir metodikos [13]. Yra išskiriami du esminiai veiklos meta-modelio elementai: funkcija ir procesas. Procesas apibūdina materialią, o funkcija informacinę veiklos pusę [14]. Daugelyje modeliavimo įrankių informacinės sistemos projektavimo metu tik iš dalies naudojamos analizės metu sukauptos žinios. Tikslinga tokias žinias surinkti į saugyklą, kurios sudėtį apibrėžia veiklos meta-modelis. Šio veiklos meta-modelio sudėtis grindžiama pagrindinių veiklos modeliavimo metodologijų esminiais elementais [12]. Veiklos žinių posistemė išplečia šiandien egzistuojančių CASE įrankių architektūrą, kadangi atliekamos pagrindinės kompiuterizuojamos dalykinės srities žinių saugyklos funkcijos. IS projektavimo etape veiklos modelis, kaip pagrindinė organizacijos žinių struktūra, kontroliuoja IS projektavimo eigą, sumažindamas IS projektavimo loginių klaidų tikimybę. Tradicinė IS inžinerija ir žiniomis grindžiama inžinerija Tradicinę IS inžineriją ir žiniomis grindžiamą IS inžineriją skiria kokybiniai skirtumai (Pav. 5). Tradicinės IS inžinerijos atveju tai empirinė IS inžinerija, kuomet veiklos visumos neapima nei vienas atskiras vartotojas. Žiniomis grindžiamos IS inžinerijos atveju, veiklos visumą apima veiklos specifikacija (veiklos modelis), kadangi jis specifikuoja organizacijos veiklos esmines savybes. Veiklos modelis pakankamai formalizuotas, grindžiamas organizacijų veiklos valdymo teoriniais principais, siejamais su valdymo procesų teorija automatinio reguliavimo teorija. Pav. 5 Principinė lyginamoji tradicinės IS inžinerijos ir žiniomis grindžiamos inžinerijos schema (Sudaryta pagal [1]) Tradicinėje kompiuterizuotoje IS inžinerijoje informacijos sistema kuriama empiriškai. Žiniomis grindžiamoje kompiuterizuotoje IS inžinerijoje informacijos sistema kuriama naudojant veiklos žinių saugykloje, t.y. veiklos modelyje saugomas kompiuterizuojamos dalykinės srities žinias, kurios yra būtinos ir pakankamos IS projektavimui. Pirmoje lentelėje pateikiami IS inžinerijos išskiriamų tipų skirtumai pagal naudojamus metodus, žinių šaltinius, t.y. dalyvius, kurie dalyvauja IS kūrimo procese bei šiam procesui reikalinga programinė įranga. Lentelėje naudojami sutrumpinimai: 8

9 ISIRE IS inžinerijos raidos etapai TISI tradicinė IS inžinerija (nekompiuterizuota) KPĮI kompiuterizuota programinės įrangos inžinerija KISI su VM kompiuterizuota IS inžinerija su veiklos modeliavimu ŽGISI žiniomis grindžiama IS inžinerija ISIRE TISI KPĮI KISI su VM ŽGISI Metodai Projektavimas pagal IS GC etapus individualiais metodais CASE metodas, apima dalį IS GC: a) IS projektavimą b) IS realizavimą CASE metodas, apima visą IS GC: a) veiklos modeliavimą b) IS projektavimą c) IS realizavimą ŽG CASE metodas, apima: d) veiklos žinių modeliavimą e) veiklos modeliavimą f) IS projektavimą g) IS realizavimą Šaltinis: Sudaryta pagal [1] Lentelė 1 IS inžinerijos raidos etapų skirtumai Žinių šaltiniai PĮ (Dalyviai) DB projektavimo priemonės; Programavimo priemonės Dalyviai: Vartotojas Analitikas Projektuotojas Programuotojas Dalyviai: Vartotojas Analitikas Projektuotojas Programuotojas Dalyviai: Vartotojas Analitikas Projektuotojas Programuotojas Dalyviai: Vartotojas Analitikas Projektuotojas Programuotojas CASE žinių posistemė Vartotojo poreikių specifikavimo priemonės; DB projektavimo priemonės; Vartotojo sąsajos projektavimo priemonės; Taikomųjų uždavinių projektavimo priemonės; Programavimo priemonės Veiklos modeliavimo priemonės Vartotojo poreikių specifikavimo priemonės; DB projektavimo priemonės; Vartotojo sąsajos projektavimo priemonės; Taikomųjų uždavinių projektavimo priemonės; Programavimo priemonės Veiklos modeliavimo priemonės Žinių posistemės administravimo priemonės Vartotojo poreikių specifikavimo priemonės; DB projektavimo priemonės; Vartotojo sąsajos projektavimo priemonės; Taikomųjų uždavinių projektavimo priemonės; Programavimo priemonės Žiniomis grindžiamoje kompiuterizuotoje IS inžinerijoje egzistuoja mažiau projektavimo loginių trūkių negu tradicinėje kompiuterizuojamoje IS inžinerijoje. Loginis projektavimo trūkis kai nutraukiamas nuoseklus automatizuotas IS projektavimo procesas tam, kad analitikas įvestų trūkstamą IS inžinerijos procesui informaciją. Loginiai IS projektavimo trūkiai egzistuoja ne tik teoriniuose IS inžinerijos modeliuose, bet ir daugelyje naudojamų CASE įrankių, pvz.: System Architect, MagicDraw, Enterpise Architect ir kt. Dauguma CASE įrankiuose taikomų projektinių modelių yra generuojami tik iš dalies ir juos pilnai realizuoti gali tik sistemos analitikas turintis empirinės patirties [4]. Žiniomis grindžiamoje kompiuterizuotoje IS inžinerijoje, surinkus IS projektavimui būtinas žinias į veiklos žinių saugyklą, visus projektinius modelius, panaudojant generavimo algoritmus, galima sugeneruoti interaktyviai, t.y. reikalingas minimalus analitiko ir projektuotojo dalyvavimas, užtikrinantis trūkstamų IS projektavimui žinių įvedimą. Žinių rinkimo į veiklos žinių saugyklą etape, 9

10 yra tikrinamas jų pilnumas, jos yra verifikuojamos, tuo užtikrinant automatizuotai generuojamų projektinių modelių ir programinio kodo kokybę [4, 16]. UML NAUDOJIMO CHARAKTERISTIKA UML tai modeliavimo notacija pirmą kartą pristatyta 1997 metais. UML tapo viena iš plačiausiai naudojamų modeliavimo kalbų. Vartotojai verslo sektoriuje naudoja UML modeliavimo savo verslo srityse, taip pat kaip ir procesuose. Paskutini aktuali versija yra UML 2.5 (beta versija), išleista spalis 2012 [20]. UML vaidmuo kuriant programinę įrangą, tapo reikšmingesnis, atsiradus modeliais grindžiamai architektūrai (MDA), kuri lėmė UML svarbą programinės įrangos kūrime. UML kaip modeliavimo kalba yra dažniausiai naudojama programuotojų kaip pagrindas realizacijos procese. Šiame etape darbas grindžiamas empirika. UML naudojimo stilius ir taisyklės naudojant praktikoje labai skiriasi. Šis skirtumas priklauso nuo daugelio veiksnių, tokių kaip analitiko ar projektuotojo patirtis, laiko trūkumas ir vartotojų reikalavimai [26, 27] metais Dobing ir Parsons (CAMC) atliktas tyrimas apie UML naudojimą (182 respondentai). 171 respondentas visiškas UML vartotojas ir 11 iš dalinių UML vartotojų. UML naudojimo rezultatai buvo tokie: klasių diagrama (73%) yra dažniausiai naudojamas techninis aprašas, taikomųjų uždavinių diagrama ir sekų diagrama, veiklos diagrama (77%) geriausia priemonė, atsižvelgiant į vartotojo dalyvavimą; klasių diagrama (93%), sekų diagrama (91%) ir būsenų diagrama (82%) pageidaujama techniniam aprašymui [21] metų Dwayne Anius ir Brian Dobing tyrime apie programuotojų požiūrį į UML diagramų naudingumą pateikė panašius rezultatus kaip ir ankstesni tyrima. Tyrime analizuojami 94 respondentų atsakymai. Dauguma respondentų turintys 15 ir 20 metų UML programavimo patirtį. Apie 21% nurodė turintys 10 ar daugiau metų patirtį [22]. Sudėtinga formuluoti išvadas dėl UML naudojimo naudingumo, apklausus šimtą respondentų, tačiau įvertinus jų turimą patirtį, galima teigti, kad rezultatai pakankamai informatyvūs [23]. Kaip jau buvo minėta, klasių diagrama yra plačiausiai naudojama UML diagrama informacinių sistemų kūrimo procese, tačiau ši diagrama nėra tikslus objektų specifikavimas diagrama suteikia tik dalį klasės aprašymo. Klasių diagrama naudoja duomenis iš kitų UML modelių. Dinaminės diagramos, pavyzdžiui, taikomųjų uždavinių, veiklos ir sekų diagramos, yra pagrindiniai duomenų šaltiniai. Klasių diagrama yra viena plačiausių notacijų, veiklos ar sistemos atvaizdavimui, bet tuo pačiu metu jis yra statinė ir apibūdina tik kaip viskas turėtų būti, o kiti dinaminiai modeliai gali atskleisti, kaip veiksmas iš tikrųjų vyksta [24]. UML DIAGRAMŲ GENERAVIMAS Automatizuoto projektavimo įrankiai palengvina projektuotojo darbą, tačiau vis dėlto nepakankamai jį automatizuoja, kadangi privalomas analitiko dalyvavimas. Didelis dėmesys skiriamas modeliavimui, ir projektuotojas šiai veiklai turi sugaišti nemažai laiko, kai galutinis darbo rezultatas IS, o ne modeliai. Siekiama kiek įmanoma labiau formalizuoti modelių sudarymą, tam yra sukurta įvairių metodikų, tačiau dar egzistuoja ir neišnaudotų galimybių, kurios leistų patobulinti CASE įrankiais valdomus informacinių sistemų projektavimo metodus [17]. 10

11 UML modeliavimo kalba skirta aprašyti projektavimo sprendimus. Tai modeliavimo kalba, kuri apibrėžia grafinę notaciją, skirtą įvairių programinės įrangos architektūros aspektų modeliavimui. UML modeliai vadinami programinės įrangos žemėlapiais, kadangi leidžia greičiau ir lengviau suprasti programinės įrangos struktūrą ir veikimo principus, todėl yra efektyviai taikomi programinės įrangos architektūros dokumentavimui bei projektavimo sprendimų aptarimui. Šiuo metu UML modeliavimo kalba yra visuotinai priimta projektavimo priemonė. IS modeliavime rekomenduojama pasirinkti UML. Naujausia ir aktuali versija pristatyta 2012 spalį UML 2.5 (beta) apibrėžia dviejų tipų: struktūrines ir dinamines diagramas. Šešiolika pagrindinių ir trys pagalbinės diagramos leidžia specifikuoti įvairius architektūros aspektus (Pav. 6). Nėra būtina naudoti visas diagramas [18]. Informacinių sistemų projektavimo metodai nurodo sistemos projektavimo veiksmų seką, t.y. kaip, kokia tvarka ir kokias UML diagramas naudoti projektavimo procese bei kaip tą procesą vykdyti. Daugelis jų remiasi kelių tipų diagramomis, aprašančiomis skirtingų sistemos aspektų savybes. Kiekvienos diagramos prasmę galima nusakyti atskirai, bet svarbiau yra tai, kad kiekviena diagrama yra visos sistemos modelio projekcija [17]. Pav. 6 UML diagramos 2.5 (beta) [18] Toks sistemos aprašymas yra gana painus, nes daugumoje diagramų pateikiama informacija iš dalies sutampa ir aprašo tuos pačius dalykus tik skirtingais aspektais. Nepatyrusio specialisto netinkamai naudojamos UML diagramos gali būti nenuoseklios, nepilnos ir nevienareikšmiškai aprašyti sistemą. Dabartiniai UML CASE įrankiai tokiais atvejais labai nedaug kuo gali padėti projektuotojui. Formalizavimas atveria naujas programinės įrangos ir informacinių sistemų projektavimo, kūrimo galimybes. Pasiekus maksimalų UML modelių suderinamumą, kai modeliai tarpusavyje susiję pagal aiškiai nusakytas taisykles, griežčiau išreikšti ir pilnesni, labai palengvėtų automatizuoto programinės įrangos kūrimo uždavinio sprendimas [15]. Aišku, nebūtinai reikia specializuotų UML įrankių nedideliuose projektuose galima braižyti UML diagramas bendrais diagramų modeliavimo įrankiais. Nuo tada (1997 gruodis), kai OMG (angl. Object Management Group) paskelbė UML kaip standartą, ši vis labiau populiarėjanti kalba daro didžiulį poveikį IS projektavimui. Pirmaisiais šios kalbos naudojimo metais, ji buvo naudojama modeliuoti informacinėms sistemoms, tačiau ši kalba yra tinkama modeliuoti ir verslo procesams, todėl spėjo paplisti ir verslo analitikų tarpe. UML tinkama apibrėžti verslo struktūrinius, elgsenos ir taisyklių aspektus. Taigi, šios kalbos naudojimas 11

12 IS ir verslo modeliavime gali užtikrinti dokumentacijos stabilumą, vienodumą ir padėti lengviau susikalbėti IS projektuotojams su verslo kūrėjais [19]. UML diagramos turi tarpusavio sąsajas. UML diagramų ir veiklos modelio ryšys realizuojamas per transformavimo algoritmus, t.y. veiklos modelyje saugomi elementai gali būti generuojami, vykdant algoritmą, kaip UML diagramų elementai. Veiklos žinių posistemės įdiegimas ir veiklos modelio naudojimas leidžia generuoti žinias jau patikrintas formalių kriterijų atžvilgiu į UML diagramas (Pav. 7). Naudojant veiklos modelį ir automatizuojant IS kūrimo procesą veiklos žinių pagrindu, sutaupomas projektuotojų ir užsakovų darbo laikas. Pav. 7 Žiniomis grindžiamos IS inžinerijos CASE įrankio komponentai ir UML diagramų taikymas Veiklos modelio elementai atvaizduojami kaip UML diagramų elementai (Pav. 8). Veiklos modelis kaip organizacijos žinių saugykla suteikia galimybę, atlikus transformavimo algoritmus, generuoti UML diagramas (Pav. 9) Tokia saugykla gali būti naudojama ne tik žinių apie organizacijos veiklą kaupimui, bet ir kaip priemonė, kuri minimizuoja IS reinžinerijos darbų apimtį, įvykus pokyčiams organizacijos veikloje [10]. Šiuo metu CASE sistemose naudojamų veiklos modelių sudėtis netikrinama formalizuotų kriterijų atžvilgiu. Nors veiklos modeliai sudaromi pagal atitinkamas notacijas (kaip pvz.: duomenų srautų diagramos, darbų sekų modeliai ir pan.), tačiau jų sudėtis netikrinama konkrečios dalykinės srities savybių atžvilgiu. IS inžinerijoje visų projektų modelių kūrimas atliekamas remiantis eksperto empirine patirtimi. Ekspertai, dalyvaujantys IS kūrimo procese, neturi sukaupę pakankamai daug žinių, todėl reikalavimų analizės ir specifikavimo proceso etapai gali būti vykdomi per ne lyg ilgai. Pav. 8 Žiniomis grindžiamos posistemės ir UML diagramų sąsaja CASE įrankyje Veiklos meta-modelio sudėtyje egzistuoja pagrindinių veiklos modeliavimo metodologijų bei būdų esminiai elementai. Iš šios saugyklos generuojami UML projektiniai modeliai. Taip veiklos žinių pagrindu automatizuojant IS kūrimo procesą sutaupomas projektuotojų ir užsakovų darbo laikas, be to, gaunama išsamesnė ir tikslesnė IS projektinė schema, kadangi veiklos modelyje 12

13 saugomos valdymo požiūriu patikrintos žinios. Taip veiklos modelis tampa organizacijos žinių saugykla, kuri yra naudojama ne tik žinioms apie organizacijos veiklą kaupti, bet ir kaip priemonė, mažinanti IS reinžinerijos darbų apimtį, keičiantis organizacijos veiklai. Pav. 9 UML diagramų generavimas naudojant transformavimo algoritmus Lentelė 2 Dalis iš veiklos modelio sugeneruotų UML diagramų elementų Veiklos meta-modelio Sugeneruotas UML UML diagrama elementai diagramos elementas Materialus srautas Veiklos diagrama Kontrolinis mazgas Vykdytojas Taikomųjų uždavinių diagrama Vykdytojas Procesas Veiklos diagrama Veiklos particija Procesas Taikomųjų uždavinių diagrama Taikomasis uždavinys Veiklos taisyklės Veiklos diagrama Objekto mazgas Informacijos srautas Veiklos diagrama Veiklos riba Funkcija Taikomųjų uždavinių diagrama Taikomasis uždavinys Šaltinis: Sudaryta autoriaus pagal [19] Antroje lentelėje pateikiama dalis iš veiklos modelio sugeneruotų UML diagramų elementų, t.y. keletas UML veiklos ir taikomųjų uždavinių diagramų elementų. Tai parodo, kad veiklos modelis kaip organizacijos žinių saugykla suteikia galimybę, atlikus transformavimo algoritmus, generuoti UML diagramas. Tokia saugykla gali būti naudojama ne tik žinių apie organizacijos veiklą kaupimui, bet ir kaip priemonė, kuri minimizuoja IS reinžinerijos darbų apimtį, įvykus pokyčiams organizacijos veikloje. IS inžinerijos projektavimo etapo intelektualizavimas, t.y. UML diagramų generavimas iš veiklos modelio užtikrina sukurtų modelių korektiškumą, formalią notaciją ir savalaikį rezultatą. IŠVADOS Kompiuterizuota IS inžinerija paremta empirika ir IS kūrimo gyvavimo ciklo etapai vykdomi remiantis ekspertų patirtimi. Didelė dalis CASE įrankiuose taikomų projektinių modelių yra generuojami tik iš dalies ir juos pilnai realizuoti galima tik neautomatizuotai, dalyvaujant žmogui. Šiandien IS inžinerija turi būti žiniomis grindžiama. Tokiu atveju, žiniomis grindžiamoje kompiuterizuotoje IS inžinerijoje informacijos sistemos projekto kūrimas vykdomas naudojant veiklos žinių bazėje saugomas dalykinės srities žinias. Žiniomis grindžiamos CASE sistemos sudėtyje būtinas veiklos žinias organizuojantis komponentas CASE sistemos žinių posistemė, kurio pagrindą sudaro veiklos žinių bazė, kurioje talpinama veiklos meta-modelio specifikacija ir konkrečios veiklos srities modelis, kuris atitinka meta-modelyje saugomus apribojimus. Organizacijų veiklos valdymo principais grindžiamas veiklos 13

14 modelis specializuotas veiklos modelis, apimantis veiklos valdymo informacinių procesų esmines savybes. Formalizuoto veiklos modelio pagrindu kuriama veikos žinių bazė, kaip CASE įrankio posistemė, kuri užtikrina kokybiškas ir patikrintas žinias konkrečiam veiklos atvejui. Ataskaitoje nagrinėjama UML diagramų generavimo iš veiklos modelio galimybės. Veiklos modelio elementai atvaizduojami į UML diagramų elementus. Kiekvienos IS kūrimui reikalingos UML diagramos elementai gali būti generuojami iš veiklos modelio. UML diagramų generavimo iš veiklos modelio metodas realizuotų žiniomis grindžiamą IS kūrimo ciklo projektavimo etapą. 14

15 STUDIJŲ PLANO VYKDYMAS Sėkmingai išlaikyti keturi egzaminai: Informacijos poreikių specifikavimas, įvertinimas Informatikos ir informatikos inžinerijos tyrimo metodai ir metodika, įvertinimas Žiniomis grindžiama kompiuterizuota informacijos sistemų inžinerija, įvertinimas Sistemų analizės technologijos, įvertinimas 9. Dalyvavimas konferencijose: XVII tarpuniversitetinė magistrantų ir doktorantų konferencija Informacinės technologijos 2012, Kaunas th Workshop on Applications of Knowledge-Based Technologies in Business (AKTB 2013). Tarptautinė konferencija 15th International Conference on Business Information Systems, BIS2013, Poznanė, Lenkija PhD simpoziumas. Tarptautinė konferencija 15th International Conference on Business Information Systems, BIS2013, Poznanė, Lenkija. Publikacijos: Veitaitė I., Lopata A. (2012) Veiklos modeliu grindžiamas UML diagramų generavimas. XVII tarpuniversitetinė magistrantų ir doktorantų konferencija. Informacinės technologijos VUKHF, Kaunas m. balandžio 20 d. Informacinės technologijos XVII tarpuniversitetinė magistrantų ir doktorantų konferencija. Konferencijos pranešimų medžiaga. Vilniaus universitetas. ISSN X Veitaitė I., Lopata A. (2013) UML Diagrams Generation Process by Using Knowledge- Based Subsystem. 15th International Conference on Business Information Systems, BIS2013 International Workshop, Poznan, Poland, June 19-21, 2013, Series: Lecture Notes in Business Information Processing. Parengti ir pateikti straipsniai: Lopata A, Veitaite I., Gudas S., Butleris R. (2013) CASE Tool Component Knowledgebased Subsystem. UML Diagrams Generation Process. Transformations in Business & Economics. Lopata A., Ambraziunas M., Veitaite I., Butleris R. (2013) SysML and UML models usage in Knowledge Based MDA process. Elektronika ir Elektrotechnika. Rengiama medžiaga disertacijai: Mokslinių tyrimų disertacijos tema apžvalga ir analizė (Lietuvoje ir užsienyje). Tyrimo metodikos sudarymas. 15

16 KITŲ METŲ PLANAS 2014 m. numatytas dalyvavimas konferencijoje ir publikacija. Parengti medžiaga disertacijai: Analitinis tyrimas. Planuojama atlikti detalę veiklos metamodelio ir UML diagramų meta-modelių palyginamąją analizę, siekiant įrodyti, kad pasirinktojo veiklos modelio sudėtis yra pakankama šių diagramų generavimui, išsiaiškinti, ar reikalingas veiklos modelio koregavimas įtraukiant papildomus elementus, generuojant ne tik esminius UML diagramų elementus ir sudaryti detalius UML diagramų generavimo iš veiklos modelio algoritmus. 16

17 LITERATŪRA [1] Gudas S. Žiniomis grindžiamos IS inžinerijos metodų principai. - Konferencijos pranešimų medžiaga Informacinės technologijos 2004, T.2, Kaunas, Technologija, 2005, p ISBN [2] Gudas S. Enterprise knowledge modelling: Domains and aspects. Technological and economic development of Economy. Baltic Journal on Sustainability , 2009 [3] Gudas S., Architecture of Knowledge-Based Enterprise Management Systems: a Control View, Proceedings of the 13th world multiconference on systemics, cybernetics and informatics (WMSCI2009),) July 10 13, 2009, Orlando, Florida, USA, Vol. III, p ISBN -10: (Volume III).ISBN -13: (Volume III) [4] Gudas S., (2012) Informacijos sistemų inžinerijos teorijos pagrindai. Vilniaus universiteto leidykla ISBN [5] Gudas, S., Brundzaite R. Knowledge-Based Enterprise Modelling Framework. Advances in Information Systems. Lecture Notes in Computer Science, 2006, Volume 4243/2006, , DOI: / _35 [6] Gudas S., Lopata A. Vartotojo poreikių modelio generavimas veiklos modelio pagrindu. //Informacijos mokslai 2003, p ISSN [7] Gudas S., Lopata A. Informacijos išteklių identifikavimas veiklos modelio pagrindu. Vilniaus universiteto leidykla, 2001 m. [8] Gudas S., Lopata A. Žiniomis grindžiama informacijos sistemų inžinerija -Informacijos mokslai, Mokslo darbai, T.30, Vilnius, Vilniaus Universiteto leidykla, 2004, p ISSN [9] Gudas S., Lopata A. Žiniomis grindžiama sistemų inžinerija. Mokomoji medžiaga. Vilniaus universiteto Kauni humanitarinis fakultetas [10] Gudas S., Lopata A., Skersys T. Domain Knowledge Integration For Information Systems Engineering Informacinės technologijos verslui 2002: [konferencijos pranešimų medžiaga]. Kaunas: Technologija p [11] Gudas S., Lopata A., Skersys T. Framework for knowledge-based IS engineering. Advances in Information Systems: Third International Conference, ADVIS 2004, Izmir, Turkey, October 20-22, 2004, p. 512 [12] Gudas, S., Lopata, A.; Skersys, T. Approach to Enterprise Modelling for Information Systems Engineering Vilnius: Vilniaus universitetas, [13] Lopata A. Disertacija. Veiklos modeliu grindžiamas kompiuterizuotas funkcinių vartotojo reikalavimų specifikavimo metodas [14] Lopata A.; Gudas S. Meta-Model Based Development of Use Case Model for Business Function // Information Technology and Control, vol. 36, No [15] Skersys T., Gudas S. Klasių modelio generavimas veiklos modelio pagrindu. Informacijos mokslai V.26, Vilniaus Universiteto leidykla, Vilnius, 2003, pp [16] Skersys, T. Business knowledge-based generation of the system class model Kaunas: Information Systems Department, Kaunas University of Technology, [17] UML Diagrams (2012) Elektroninė svetainė 17

18 [18] Unified Modeling Language (UML), version 2.5 Unified Modeling. [19] Veitaitė I., Lopata A. Veiklos modeliu grindžiamas UML diagramų generavimas. XVII tarpuniversitetinė magistrantų ir doktorantų konferencija. Informacinės technologijos VUKHF, Kaunas m. balandžio 20 d. Informacinės technologijos XVII tarpuniversitetinė magistrantų ir doktorantų konferencija. Konferencijos pranešimų medžiaga. Vilniaus universitetas. ISSN X [20] OMG UML (2012) Unified Modeling Language version 2.5. Unified Modeling// [21] Dobing, B., Parsons, J. (2006) How UML is used. Communications of the ACM - Two decades of the language-action perspective. Volume 49 Issue 5, May 2006 Pages ACM New York, NY, USA [22] Dobing, B., Anius, D. (2010) Programmers' views of the usefulness of UML diagrams. [23] Rosen, S. (2010) A glimpse into the current state of UML use. Architexa Working with Large Codebases [24] Thomas A. Pender (2002) UML Weekend Crash Course, p. 94 ISBN: , New York. [25] Freiberg, M., Baumeister, J., Puppe, F. (2010) Interaction Pattern Categories Pragmatic Engineering of Knowledge-Based Systems. 6th Workshop on Knowledge Engineering and Software Engineering (KESE6) at the 33rd German Conference on Artificial Intelligence September 21, Karlsruhe, Germany [26] Perjons, E (2011) Model-Driven Process Design. Aligning Value Networks, Enterprise Goals, Services and IT Systems. Department of Computer and Systems Sciences, Stockholm University. Sweden by US-AB, Stockholm ISBN [27] Sommerville, I., (2011) Software engineering 9th ed. Pearson Education, Inc., publishing as Addison-Wesley. ISBN-13:

19 Įžanga PRIEDAI IT2012 VEIKLOS MODELIU GRINDŽIAMAS UML DIAGRAMŲ GENERAVIMAS Ilona Veitaitė 1, Audrius Lopata 2 Vilniaus Universitetas, Kauno humanitarinis fakultetas, Muitinės g. 8, LT-44280, Kaunas, Lietuva, 1 Ilona.Veitaite@khf.stud.vu.lt 2 Audrius.Lopata@khf.vu.lt Santrauka (abstract). Straipsnyje nagrinėjamos UML diagramų generavimo (veiklos ir taikomųjų uždavinių diagramų pavyzdžiu) iš veiklos meta-modelio galimybės. Analizuojama UML 2.4 versijos (angl. Unified Modelling Language) veiklos ir taikomųjų uždavinių diagramų sudėtis ir taikymas. Straipsnio tikslas apibrėžti veiklos meta-modelio sudėtį, kuriuo remiantis galima generuoti UML diagramas. Raktiniai žodžiai: Unified Modelling Language, veiklos modeliavimas, veiklos meta-modelis. Pastaruoju metu sparčiai vystosi nauja informacinių sistemų (IS) inžinerijos kryptis žiniomis grindžiama IS inžinerija [9]. Tradicinės informacinių sistemų inžinerijos etapai nuo modeliavimo iki generavimo vykdomi empiriškai. Žiniomis grindžiamoje kompiuterizuotoje IS inžinerijoje informacijos sistemos projekto kūrimas vykdomas naudojant veiklos žinių bazėje saugomas dalykinės srities žinias (veiklos modelį, kurio sudėtis apibrėžta pagal formalius kriterijus)[2]. Žiniomis grindžiamos IS inžinerijos siūlomi sistemų modeliavimo ir sprendimų priėmimo metodai ir priemonės suteikia galimybę sukurti tikslesnį ir tinkamiau dalykinę sritį atitinkantį IS projektą. Organizacijos informacinės sistemos projekto kūrėjui programuotojui sudaromos sąlygos naudoti ne tik projektavimui reikalingas žinias, kurios saugomos tradicinėje CASE (angl. computer-aided software engineering) įrankio saugykloje, bet taipogi žinių saugyklą, kurioje saugomos formaliais kriterijais patikrintos dalykinės srities žinios. Veiklos meta-modelis Veiklos meta-modelis tai formaliai apibrėžta veiklos modelio struktūra, kuri sudaryta pagal formalizuotą veiklos modelį, atitinkantį bendruosius valdymo teorijos principus [1]. Tai žinių apie kompiuterizuojamą dalykinę sritį šaltinis, skirtas verslo procesų reinžinerijai ir IS inžinerijai. Šis veiklos meta-modelis yra detaliai nagrinėjamas Vilniaus universiteto ir Kauno technologijos universiteto mokslininkų darbuose [2, 3]. 19

20 1 pav. Veiklos meta-modelio klasių modelis [6] Daugelyje modeliavimo įrankių informacinės sistemos projektavimo metu dalinai naudojamos analizės metu sukauptos žinios. Tikslinga tokias žinias surinkti į saugyklą, kurios sudėtį apibrėžia Veiklos meta-modelis [4, 5, 6, 8]. Šio veiklos meta-modelio sudėtis turėtų būti grindžiama pagrindinių veiklos modeliavimo metodologijų bei būdų esminiais elementais. Tokios saugyklos pagrindu tikslinga realizuoti UML projektinių modelių generavimą. UML raida UML (angl. Unified Modeling Language) modeliavimo ir specifikacijų kūrimo kalba, skirta specifikuoti, atvaizduoti ir projektuoti objektiškai orientuotų IS specifikacijas. UML vartojama visuose technologiniuose procesuose, IS gyvavimo ciklo stadijose ir nėra susieta su konkrečia IS kūrimo metodika ar tų sistemų įgyvendinimo technologija. Šiuo metu UML yra populiariausias programinės įrangos specifikavimo standartas. UML kalboje IS vizualizavimui taikomos veiklos modeliavimo metodologijas atitinkančios diagramos, kurių tikslas įvairiais pjūviais aprašyti kuriamą sistemą sudaryti sistemos modelį [9]. UML Naujausia UML specifikacijos versija išleista 2011 rugpjūčio mėnesį [12]. Šioje UML versijoje diagramos skirstomos į dvi kategorijas: struktūrinės ir dinaminės (elgsenos), į pastarąsias įtraukta sąveikos diagramų grupė. 2 pav. UML diagramos (versija ) [11] 20

21 Struktūrinės diagramos, skirtos grafiškai atvaizduoti IS komponentų struktūros hierarchiją. Duomenų srauto elementų diagramų paskirtis specifikuoti programų dalių hierarchiją. Šios diagramos naudojamos siekiant atvaizduoti statinę projektavimo organizavimo būseną [10, 11, 12]. Struktūrinės diagramos skirstomos į: Klasių diagrama (angl. Class diagram) skirta atvaizduoti sistemos struktūrą, jos klases ir jų atributus, bei ryšius tarp klasių ir operacijas; Objektų diagrama (angl. Object diagram) skirta vaizduoti dalinį arba visą modeliuojamos sistemos vaizdą konkrečiu momentu; Paketų diagrama (angl. Package diagram) skirta vaizduoti sistemos sudėtį suskaidytą į atskiras logines grupes ir jų tarpusavio priklausomybę; Sudėtinė, kompozicinės struktūros diagrama (angl. Composite structure diagram) skirta vaizduoti vidinę klasių struktūrą ir bendradarbiaujant suteiktas galimybes; Komponentų diagrama (angl. Component diagram) skirta vaizduoti sistemos išskaidymą į komponentus ir jų tarpusavio priklausomybes; Diegimo diagrama (angl. Deployment diagram) skirta vaizduoti fizinį sistemos elementų išdėstymą; Profilio diagrama (angl. Profile diagram) skirta vaizduoti sistemos mechanizmą, nurodant esmines vertes, apribojimus, platformas ir domenus; Modelių (angl. Model diagram), paraiškų (angl. Manifestation diagram) ir tinklo architektūros (angl. Network architecture diagram) diagramos versijoje išskiriamos kaip pagalbinės ir yra naudojamos ne visada. Dinaminės (elgsenos) diagramos skirtos atvaizduoti kaip kas turi elgtis modeliuojamoje sistemoje [10, 11, 12]. Dinaminės diagramos yra: Taikomųjų uždavinių diagrama (angl. Use case diagram) skirta atvaizduoti funkcinius sistemos reikalavimus, išorinius aktorius, jų elgseną ir sistemos veiksmus su jais; Veiklos diagrama (angl. Activity diagram) skirta vaizduoti sistemos elgseną ir jos elgseną su tam tikros sistemos srautais ir sistemos komponentų veiklų sekas; Būsenų diagrama (angl. State machine diagram) skirta vaizduoti klasės judėjimą, joje paaiškinami judėjimas ir elgsena; Sąveikos diagramos (angl. Interaction diagram) skirtos atvaizduoti objektų bendradarbiavimą, jų tvarką keičiantis pranešimais [10, 11, 12]. Išskiriami keturi sąveikos diagramų tipai: o Sekų diagrama (angl. Sequence diagram) skirta vaizduoti pranešimų sekas, kurios priklauso objektų bendradarbiavimui. Taip pat nurodoma objektų gyvavimo trukmė; o Komunikacijų diagrama (angl. Communication diagram) skirta pranešimais atvaizduoti objektų arba jų dalių sąveiką; o Laikinio pasiskirstymo diagrama (angl. Timing diagram) skirta vaizduoti laiko apribojimus; o Sąveikos apžvalgos diagrama (angl. Interaction overview diagram) skirta vaizduoti veiklas, kurios atitinka sąveikos diagramas. UML diagramų ir veiklos modelio tarpusavio sąveika UML diagramas sieja tarpusavio ryšiai. Pagal diagramų naudojimą galima išskirti vykdymo diagramų grupę, kurioje pateikiamos diagramos apibrėžiančios fizinę sistemos struktūrą. 21

22 3 pav. UML diagramų tarpusavio ryšiai ir UML projektinių modelių generavimas iš veiklos meta-modelio [10] Paveikslėlio a dalyje pateikiami UML diagramų tarpusavio ryšiai. Paveikslėlio b dalyje pateikiama UML diagramų ir veiklos meta-modelio integravimo schema. Veiklos modelyje saugomi elementai gali būti generuojami, vykdant transformavimo algoritmą, kaip UML diagramų elementai. Veiklos žinių posistemio įdiegimas ir veiklos modelio naudojimas leis generuoti žinias jau patikrintas formalių kriterijų atžvilgiu į UML diagramas. Naudojant veiklos modelį ir automatizuojant IS kūrimo procesą veiklos žinių pagrindu, būtų sutaupomas projektuotojų ir užsakovų darbo laikas. Gaunama IS projektinė schema būtų tikslesnė ir išsamesnė, kadangi veiklos modelyje išsaugomos valdymo požiūriu patikrintos žinios [7]. 4 pav. UML diagramų (veiklos, taikomųjų uždavinių) atvaizdavimas veiklos modelyje Lentelė Nr.1 UML diagramų elementų atvaizdiniai Veiklos modelyje Veiklos meta-modelio elementai Atvaizdys UML diagramų elementai Materialus srautas 1 Kontrolinis mazgas (Veiklos diagrama) Vykdytojas 2 Veiklos mazgas (Veiklos diagrama) 1 Vykdytojas (Taikomųjų uždavinių diagrama) Procesas 3 Veiklos particija (Veiklos diagrama) 2 Taikomasis uždavinys (Taikomųjų uždavinių diagrama) Veiklos taisyklės 4 Objekto mazgas (Veiklos diagrama) Informacijos srautas 5 Veiklos riba (Veiklos diagrama) 22

23 Veiklos meta-modelio elementai Atvaizdys UML diagramų elementai Funkcija 3 Taikomasis uždavinys (Taikomųjų uždavinių diagrama) Veiklos meta-modelio elementai atvaizduojami kaip UML diagramų, veiklos ir taikomųjų uždavinių diagramų, elementai. Tai parodo, kad veiklos modelis kaip organizacijos žinių saugykla suteikia galimybę, atlikus transformavimo algoritmus, generuoti UML diagramas. Tokia saugykla gali būti naudojama ne tik žinių apie organizacijos veiklą kaupimui, bet ir kaip priemonė, kuri minimizuoja IS reinžinerijos darbų apimtį, įvykus pokyčiams organizacijos veikloje. Išvados Šiuo metu CASE sistemose naudojamų veiklos modelių sudėtis netikrinama formalizuotų kriterijų atžvilgiu. Nors veiklos modeliai sudaromi pagal atitinkamas notacijas (duomenų srautų diagramų, darbų sekų modelių ar kt.), deja jų sudėtis netikrinama konkrečios dalykinės srities savybių atžvilgiu. Šie modeliai paremti empirika. Nepakankamos empiriniu būdu sudarytos veiklos modelio savybės ir nepakankamos vartotojo reikalavimų specifikavimo savybės riboja CASE sistemų funkcionalumą, nes projektiniuose modeliuose gali būti nepilnai arba klaidingai specifikuotos dalykinės srities žinios. Šią problemą tikslinga spręsti taikant veiklos modelį IS inžinerijos procese. Veiklos modelyje saugomas žinias, kurios yra patikrintos pagal formalius kriterijus, tikslinga generuoti vartotojų reikalavimų specifikavimo ir projektavimo etapuose naudojamose UML diagramose. Literatūros sąrašas [1] Gudas S., Lopata A. (2001). Informacijos išteklių identifikavimas veiklos modelio pagrindu. Vilniaus universiteto leidykla, 2001 m. spalio 30 d. [interaktyvus][žiūrėta 2012 m. kovo 10 d.]. Prieiga per Internetą: [2] Gudas S. (2005) Žiniomis grindžiamos informacijos sistemų inžinerijos procesų modeliai. Habilitacijos procedūrai teikiamų mokslo darbų apžvalga Kaunas: Kauno technologijos universitetas [interaktyvus][žiūrėta 2012 m. kovo 10 d.]. Prieiga per Internetą: [3] Lopata A. (2000) Veiklos modelių sudėties analizė. Informacinės technologijos ir valdymas. [4] Gudas S., Lopata A., Skersys T. (2002) Domain Knowledge Integration For Information Systems Engineering. Informacinės technologijos verslui 2002 konferencijos pranešimų medžiaga. Kaunas, p [5] Gudas S. (2009) Enterprise knowledge modelling: Domainas and aspects. Technological and economic development of Economy. Baltic Journal on Sustainability [6] Gudas S., Lopata A. (2001). Informacijos išteklių identifikavimas veiklos modelio pagrindu Vilniaus universiteto leidykla, 2001 m. spalio 30 d. [interaktyvus][žiūrėta 2012 m. kovo 10 d.]. Prieiga per Internetą: [7] Gudas S., Lopata A., Skersys T. (2004). Framework for knowledge-based IS engineering. Advances in Information Systems: Third International Conference, ADVIS 2004, Izmir, Turkey, October 20-22, 2004, p. 512 [8] Gudas, S., Brundzaite R. (2006) Knowledge-Based Enterprise Modelling Framework. Advances in Information Systems. Lecture Notes in Computer Science, 2006, Volume 4243/2006, , DOI: / _35 [9] Gudas S., Lopata A. (2011) Žiniomis grindžiama sistemų inžinerija. Mokomoji medžiaga. Vilniaus universiteto Kauni humanitarinis fakultetas [10] Tang, W. (2006). UML 2 Diagrams [interaktyvus][žiūrėta 2012 m. kovo 10 d.]. Prieiga per Internetą: [11] UML Diagrams (2012) Elektroninė svetainė [interaktyvus][žiūrėta 2012 m. kovo 10 d.]. Prieiga per Internetą: 23

24 [12] Unified Modeling Language: Specification, version 2.4. [interaktyvus][žiūrėta 2012 m. kovo 10 d.]. Prieiga per Internetą: Enterprise model based UML diagrams generation process The paper deals with the possibility of Enterprise meta-model based UML 2.4 Activity and Use Case diagrams generation. Analysis of UML 2.4 Activity and Use Case diagrams construction and application reveals that the construction of chosen Enterprise meta-model is sufficient for the UML 2. 4 Activity and Use Case diagram generation. 24

25 BIS2013 UML DIAGRAMS GENERATION PROCESS BY USING KNOWLEDGE-BASED SUBSYSTEM Audrius Lopata, Ilona Veitaite Vilnius University, Kaunas Faculty of Humanities, Muitines St. 8, Kaunas Abstract. The main scope of the paper is to present UML diagrams generation process from enterprise model. The paper analyzes the differences between traditional information systems (IS) engineering and knowledge-based engineering. There is proposed to use knowledge-based subsystem for the purpose of avoiding empirically based IS development process Keywords: UML Diagrams, enterprise modeling, CASE tool, IS engineering, knowledge-based systems 1 Introduction Information systems (IS) are becoming more complicated and textual information with elementary schemes is not sufficient to describe business processes. Specific models are applied for computerized requirements specification and modeling of IS. Enterprise modeling has become an integral part of IS development process. During this process user requirements, business domain knowledge, software architecture, and other essential components are modeled [8]. Recently, the organization's business modeling has become an important phase of modeling design processes [11]. IS engineering phases from modeling to code generation are traditionally implemented empirically. Computerized model of the subject area is formed by experience of the analyst, while traditional CASE system design models are formed on the basis of the information collected on business domain, which is being computerized. The main role is given to the analyst and enhanced knowledge of the subject area is not fully or insufficiently controlled by formalized criteria [6]. Currently, computerized IS engineering, in order to avoid the empiric, is developing based on new knowledge-based methods. Computerized information system in knowledge-based information system engineering, is developed by using stored enterprise knowledge base of the subject area, i.e., enterprise model, the composition of which is defined by formal criteria. Computerized IS software development based on that model is known as knowledge-based IS engineering [6]. A knowledge based IS engineering offered system modeling and decision making methods and tools, which helps to develop more accurate and detailed subject area corresponding to the project [2]. IS project developer and (or) programmer is allowed to use not only the knowledge of the project, which is stored in traditional CASE tool repository, but also the knowledge repository, where formal criteria tested subject area knowledge is stored. There are a number of standards and business modeling methodologies [6]. UML is one of the most common software specification standards. It is a universal IS modeling language applied to a number of methodologists and used in the most popular modeling tools, such as Enterprise Architect, System Architect, MagicDraw and others. The method of UML diagrams generation from enterprise model implements a knowledgebased design phase in the IS development cycle. 25

26 Knowledge-based subsystem as CASE tool component with enterprise meta model and enterprise model inside can solve this question. Enterprise meta model is a formal structure which ensures more qualified project development process and knowledge base data collection [9]. Enterprise model and enterprise meta model make UML project models generation process more effective and qualified and ensure lower number of mistakes in the final IS development phase. 2 Traditional IS Engineering and Knowledge-based IS Engineering Information systems engineering is an information system development process, the execution of which is implemented through the IS development life cycle phases. Each phase of the IS development life cycle was implemented independently of the others, because there was no computerized knowledge repository, in which were included all phases of life cycle. Analysts and designers used conventional or object oriented IS engineering methods. IS projects were implemented non computerized or by using specially created computerized tools intended for the specific user requirements specifications to solve the problem. Later, computerized IS development methods were implemented. Information system development improved computerized IS development tools CASE systems which included a part of the IS development life cycle phases design, documentation and coding. Analysts and designers used CASE system's IS development tools for conceptual and detailed design phases, and in the practical realization phase programmer used the tools designed to generate code. In this case, a computerized system was based on the traditional IS engineering and object oriented IS engineering methods. With the development of the traditional IS engineering CASE system covered the entire IS development life cycle from enterprise modeling to code generation. These life cycle phases are implemented with CASE tool components, such as process modeling tools, detailed analysis tools, transformations tools, database/application design tools, application generation tools. Enterprise modeling process is integrated into IS engineering instruments [1]. CASE system applicable not only in IS engineering, but also in enterprise modeling and reengineering. CASE systems are complemented with enterprise modeling tools and CASE system repository enterprise model subsystem. System analyst is the main user of enterprise modeling CASE tool component. Computerized IS development process is based on the design from the model sequence execution, where every other phase of the design model is created interactively in the presence of the analyst, designer and programmer [7] At that period CASE systems automatically generated only the logical database diagrams, user interface fragments and code, which programmer basically had to adjust. Thus, the traditional computerized IS engineering, IS development life cycle starting from the initial and ending with its last phase takes place empirically and many design models in CASE tools were generated partially. Only analyst could fully implement them on the basis of empirical experience. The computerized IS engineering specific methods are developed based on common requirements, which systematize the selected methodology. There are some necessary components for knowledge-based IS engineering methodology [4, 5]: Core of enterprise modeling theoretical basis is the theoretical enterprise model. Its purpose is to identify the necessary and sufficient business components for IS engineering, which implements enterprise's business management. Theoretical enterprise model is a formalized enterprise management model that identifies business components and their interactions, enterprise management and their interactions. Theoretical enterprise knowledge model is enterprise meta model. Based on the IS development life cycle phases the theoretical model components and their interactions are described as enterprise meta model. Enterprise meta model is a structural model, which specifies the necessary and sufficient components of IS engineering enterprise management features and interactions. 26

27 The theoretical basis of knowledge-based IS engineering process is IS engineering process model (methodology) that bases knowledge-based IS development process by using an enterprise model as an additional knowledge source besides the analyst and the user. Computerized IS engineering systems development is based on knowledge-based IS engineering tools: enterprise modeling approach, design models, use case methods. Right tools are needed for knowledge-based IS development life cycle phase s implementation, such as practical knowledge-based modeling methods or models sets. Practical knowledge-based modeling methods are intended for the development of functionality of traditional CASE systems by creating a knowledge-based CASE intelligent system. Computerized knowledge-based IS engineering project management basis is CASE system knowledge-based subsystem (Fig. 1). CASE system's knowledge-based subsystem's core component is knowledge base, which essential elements are enterprise meta model specification and enterprise model for certain problem domain. Knowledge-based subsystem is one more active participant of IS engineering process beside analyst, whose purpose is to verify results of IS life cycle phases. Figure 1 Knowledge-based CASE Tool Components Figure 2 Knowledge-based subsystem connection to the enterprise model and enterprise meta model inside CASE tool Knowledge-based CASE systems containing essential components, which organize knowledge: knowledge-based subsystem's knowledge base, which essential elements are enterprise meta model specification and enterprise model for certain problem domain. Principal scheme of interaction between CASE tool's knowledge-based subsystem, enterprise model and enterprise meta model is presented in the figure (Fig. 2). Traditional IS engineering and knowledge-based IS engineering have qualitative differences. In case of traditional IS engineering there is an empirical IS engineering, where individual user does not include whole enterprise processes. A knowledge-based IS engineering covers whole enterprise specification (enterprise model), because it specifies the essential enterprise's characteristics. Formalized enterprise model is based on theoretical enterprise's management principles [3]. Information system is developed empirically in traditional computerized IS engineering. In knowledge-based computerized IS engineering information system is developed by using enterprise knowledge repository, where necessary and sufficient computerized knowledge of the subject area is stored [6]. In a knowledge-based computerized IS engineering design there are less logical breaks than in traditional computerized IS engineering. The logical break of a design is, when consistent automated information system design process is terminated to allow the analyst to enter the missing information of IS engineering process. Logical breaks exist not only in theoretical IS engineering models, but also are observable in many CASE tools, such as System Architect, MagicDraw, 27

28 Enterprise Architect and others. The majority of CASE tool's project models are generated partially and fully implementation possible just by using the systems analyst experience. In a knowledge-based computerized IS engineering, all project models can be generated interactively by using generation algorithms, if the necessary knowledge will be collected into knowledge repository. A minimum analyst and designer participation is required for ensuring a missing knowledge entry. Knowledge is tested for completeness; it is verified to ensure automatically generated design models and software code quality in knowledge gathering into knowledge repository phase. The differences in the types of are engineering methods, sources of knowledge, i.e. participants, who are involved in IS development process and necessary software is described below: Traditional IS Engineering (non computerized) Methods: IS life cycle stages based design using individual methods; Sources of knowledge (participants)/people: User, Analyst, Designer, Programmer; Software: Database design tools, Development Tools. Computer aided software engineering Methods: Computer aided software engineering method includes parts from IS life cycle: Design method, Realization method; Sources of knowledge (participants)/people: User, Analyst, Designer, Programmer Software: User specification tools, Database design tools, User interface design tools, Use Case tools, Development tools Computerized IS Engineering (with enterprise modeling) Methods: Computerized IS Engineering (CASE) method includes all IS life cycle: Enterprise modeling, Design method, IS realization method; Sources of knowledge (participants)/people: User, Analyst, Designer, Programmer Software: Enterprise modeling tools, User requirements specification tools, Database design tools, User interface design tools, Use Case tools, Development tools Knowledge based IS engineering Methods: Knowledge based CASE method includes: Enterprise knowledge modeling, Enterprise modeling, Design method, Realization method; Sources of knowledge (participants)/people: 1. User, Analyst, Designer, Programmer 2. CASE knowledge-based subsystem Software: Enterprise modeling tools, Knowledge-based subsystem, User requirements specification tools, Database design tools, User interface design tools, Use Case tools, Development tools 3 Generation process The current version of UML is UML 2.5 (beta), released in October tools will have to support a complete UML specification [13]. Computer aided design tools facilitate the work of the designer, but still does not automate enough, because the analyst inclusion is required. The main purpose is to formalize as much as possible model creation process. A variety of methodologies has been designed, but still there are missed opportunities that would improve the IS design methods that are controlled by CASE tools [10]. Information system design methods specify the sequence of systems engineering actions, i.e. how, in what order and what UML diagrams to use in the design process and how to implement the process. Meaning of each diagram can be defined individually, but more important is the fact that each diagram is the projection of the system model [12]. This kind of system description is quite confusing, because most of the information in the diagrams overlap and describe the same things just in different ways. Formalization brings new software and IS design and development opportunities. When the maximum coherence of UML models is reached, models are linked to each other clearly articulated by the rules, expressed stricter and fuller. This greatly facilitates the task of automated software development. Interaction between UML diagrams and enterprise model is realized through the transformation algorithms. 28

29 Figure 3 Generation process of UML diagrams by using the transformation algorithm Enterprise model as organization's knowledge repository allows to generate UML diagrams after using the transformation algorithms (Fig. 3) Such repository can be used not only for knowledge of the organization accumulation, but also as a tool that minimizes IS reengineering scope of work if changes occur in an organization. In information system engineering all design models are implemented on the basis of the empirical expert experience. Experts, who participate in the IS development process, do not gain enough knowledge, and process implementation in requirements analysis and specification phases can take a too long time. Enterprise meta model contains essential elements of business modeling methodologies and techniques, which insures a suitable UML diagrams generation process. Figure 4 Algorithm of EM based UML diagrams generation process Transformation algorithm (Fig. 4) is top level algorithm for enterprise meta model based UML diagrams generating process. Main steps for generating process are identifying and selecting UML diagram for generating process, identifying starting elements for the selected UML diagram and selecting all related elements, reflecting enterprise model elements to UML diagram elements and generating the selected UML diagram. Table 1 Reflections of some basic EM elements to UML diagram elements Enterprise meta-model Generated UML diagram UML Diagram elements element Material Flow Activity Diagram Control Node Actor Use Case Diagram Actor Process Activity Diagram Activity Partition Process Use Case Diagram Use Case Business Rules Activity Diagram Object Node Information Flow Activity Diagram Activity Edge 29