Programos kūrimo proceso produktyvumas

Paskutinio dešimtmečio informacinių technologijų (IT) vystimasis pasižymėjo didžiuliais pasikeitimais. Mūro dėsnis (Moore's Law) vis dar tinka aparatinės įrangos pramonei ir nuolat pasireiškė eksponentiniu procesorių, atmintinių ir duomenų saugyklų našumo didėjimu. Taip pat ir programinės įrangos vystimasis pasižymi didžiule kaita. Buvo pastebėta, kad skirtingi programinės įrangos abstraktumo lygiai pasižymi nevienoda kaitos sparta. Kaip taisyklė: kuo didesnis abstraktumo lygis - tuo mažesnis pasikeitimų tempas. Programavimo lygyje, atsiranda naujos programavimo kalbos, o jau egzistuojančios (pvz. Java arba C#) vystomos toliau. Jau daugelį metų programos skaidomos į skirtingo dydžio komponentes ir tų komponenčių realizavimo metodai ženkliai keitėsi bėgant laikui, EJB (Enterprise Java Beans) standartas taip pat ir Microsoft kompanijos .NET platforma gali būti paminėti kaip pavyzdžiai. Kitaip negu realizavimo metodai, programinės įrangos struktūrizavimas ir modeliavimas tapo pastovesnis, ypač kai atsirado standartizuotos modeliavimo kalbos tokios kaip OMG (Object Management Group) konsorciumo vieninga modeliavimo kalba UML (Unified Modeling Language).

OMG pasiūlė UML kalbą programinės įrangos (ir ypač objektiškai orientuotos) elementų ir sistemų aprašymui. Vidinė UML architektūra ir taikymų ribos dar nėra visai nusistovėję, nes paskutinė UML 2.0 kalbos versija ženkliai skiriasi nuo ankstesnių. Norėdama standartizuoti UML ir kitų į UML panašių modeliavimo kalbų kūrimo procesą, OMG sukūrė MOF (Meta Object Facility) modeliavimo kalbą. UML ir MOF yra esminės keturių lygių MDA modeliavimo aplinkos dalys [1, 2-2p.].

Faktai, kad IT kaita yra nuolatinė ir, kad kaitos sparta mažėja - didėjant abstraktumo lygiui, tapo OMG pagrindu naujai modeliavimo strategijai. Jeigu skirtingi abstraktumo lygiai gali būti tiksliai nustatyti, tai technologinių pasikeitimų įtaka galima apriboti modelio poaibiu. Vietoj to, kad perdaryti visą sistemos modelį, galima pakeisti tik technologijos pasikeitimo paveiktas dalis.

Modeliais Pagrįsta Architektūra (MDA) (Model Driven Architecture) - tai OMG iniciatyva, kuri pateikia efektyvaus programinės įrangos modelių kūrimo ir panaudojimo strategijas. MDA apibrėžia tokį IT sistemų specifikavimo būdą, kuris atskiria sistemos funkcionalumo specifikaciją nuo sistemos realizavimo specifikacijos tam tikrai technologinei platformai [2, 3p.]. MDA nėra nauja architektūra - tai nauja programinės įrangos modelių kūrimo strategija. Šitos strategijos vienas iš siekių - skirtingų realizavimo technologijų ir standartų sambūvio galimybė. MDA tikslas - ne vieno uniforminio standarto įdiegimas, o aiškus skirtingų abstrakcijos lygių atskyrimas. MDA architektūros taikymas turėtų iš esmės pakeisti šiuolaikinę programų kūrimo praktiką. Toliau detaliau panagrinėsime programų kūrimo proceso problemas, kurias turėtų išspręsti programų kūrimo pagal MDA metodikos.

Pirmoji problema - tai programos kūrimo proceso produktyvumas. Programos kūrimo procesas, kokį mes jį žinome iš šiuolaikinės praktikos, didžiąja dalimi remiasi detaliu projektavimu ir programos kodo rašymu [3, 2p.]. Tipinis programos kūrimo procesas pereina tokias stadijas:

1.      Reikalavimų surinkimas;

2.      Analizė ir funkcinis aprašymas;

3.      Projektavimas;

4.      Kodo rašymas;

5.      Testavimas;

6.      Diegimas.

Šio proceso metu, nuo 1 iki 3 fazės, sukuriami reikalavimų tekstai, diagramos, programos funkcinės specifikacijos dokumentai ir daugybe UML diagramų. Gaunamas dokumentų kiekis būna gana didelis ir jų kūrimui panaudojama daug nemažai ir laiko, tačiau - tai tik dokumentai. Kai tik pradedama programos kodo rašymo stadija - dokumentų vertė pradeda sparčiai nykti. Tęsiantis programos kodo rašymui, dokumentų ir realizacijos neatitikimas vis didėja. Keičiantis jau sukurtai sistemai, pakeitimai dėl laiko ir išteklių stokos dažnai daromi tik kodo lygyje. Iškyla klausimas: Kam gaišti tiek brangaus laiko aukšto lygmens specifikacijoms, jeigu be tinkamo atnaujinimo jos greitu laiku praranda vertę?

Ekstremalaus programavimo XP (Extreme Programming) metodika pasidarė gana populiari praktikoje, nes pasižymi didele programos kūrimo proceso sparta. XP remiasi tuo, kad programos kodas yra lemiantis programos kūrimo elementas, todėl realiai tik programavimas ir testavimas yra produktyvios šio proceso stadijos (žr. 1 pav.). Tačiau ši metodika išsprendžia tik dalį problemos [3, 2p.]. Kol projekte dirba ta pati komanda - aukšto lygio žynių apie sistemą yra pakankamai, kad užtikrinti projekto eigą. Tačiau po pirmos programos versijos išleidimo projekto komanda yra išskaidoma ir kiti žmonės perima programos palaikymą ir klaidų taisymą. Programos palaikymas yra praktiškai neįmanomas turint tik kodą ir testus.

Kita problema su kuria susiduria programinės įrangos pramonė - tai sparti technologijų kaita. Įmonės investuoja didžiules lėšas programų kūrimui šiuolaikinėmis technologijos, tačiau dar net dalinai neatsipirkus sukurtam produktui atsiranda naujos technologijos arba pasikeičia esamos. Dauguma bibliotekų ir programavimo priemonių tiekėjų palaiko tik paskutines tris versija, todėl neatnaujinus sistemos - galima likti be palaikymo iš tiekėjų pusės. Įmonės konkurencijos sąlygomis negali sau leisti atsilikti ir tenka adaptuosis prie naujų technologijų.

Galima jau egzistuojančią ir veikiančią sistemą naudoti ir toliau, tačiau čia iškyla sąveikavimo ir integravimo problemos (interoperability problem) - juk senoji sistema turi veikti su naujai sukurtąja. Programinės sistemos retai būna izoliuotos. Daugumai programinių produktų tenka sąveikauti su jau egzistuojančiomis programomis. Taip pat paminėtina, kad net jeigu programa rašoma iš naujo, ji dažniausiai naudoja keletą technologijų, bibliotekų ir programavimo aplinkų (frameworks), ir naujai sukurtų ir jau seniai naudojamų. Atskiriems programų komponentėms rašyti naudojamos tam labiausiai tinkamos technologijos, tačiau komponentės turi sąveikauti norint, kad sistema veiktų [3, 5p.].

MDA - tai aplinka (framework) programų kūrimui, pasiūlyta OMG konsorciumo, kuri turėtu išspręsti bent dalį anksčiau paminėtas programavimo proceso problemas ir suteikti naujas programinių sistemų atnaujinimo ir integravimo galimybes. Programų kūrimo proceso fazės pagal MDA labai panašios į klasikinio, tačiau stadijų produktai yra skirtingi (žr. 2 pav.).

Tekstai

HM

PSM

Kodas

Kodas

Stadijos                                   Produktai

Antros ir trečios fazės produktai - tai formalūs programinės sistemos modeliai, t.y. - šie modeliai ne tik suprantami žmonėms, bet gali būti apdoroti kompiuteriu. MDA programų kūrimas yra pagrįstas modeliais (model-driven), nes modeliai nukreipia sistemos kūrimą, modifikavimą ir diegimą [4, 2-2p.].

Nuo platformos nepriklausomas modelis PIM (Platform Independent Model) - tai sistemos atvaizdas (view) nuo platformos nepriklausomu požiūriu [4, 2-6p.]. PIM aprašo sistemą abstrakčiai ir tam tikru laipsniu nepriklauso nuo realizacijos detalių tam tikrai platformai. PIM kuriama taip, kad kuo tiksliau aprašytų probleminę sritį (business domain).

Kitas modelis kurį aprašo MDA - tai platformai specifinis sistemos modelis PSM (Platform Specific Model). PSM aprašo sistemą terminais specifiniais tam tikrai platformai

11

kurioje bus realizuota programinė sistema [4, 2-6p.]. Kuriant programą MDA aplinkoje - analizės fazės metu sukurtas PIM modelis transformuojamas į vieną ar kelis PSM. Kadangi platformai specifinis modelis aprašo tam tikrai technologinei platformai būdingas detales, jis gali būti lengvai transformuotas į programos kodą [3, 6p.].

Paminėsime dar viena modelių tipą - tai nuo skaičiavimų nepriklausomas modelis CIM (Computationally Independent Model). CIM yra bazė PIM modeliui, tačiau jis visiškai skirtas tik probleminės srities esybėms aprašyti ir visai neturi informacijos apie pačią skaičiavimo sistemą ir jos skaičiavimų aplinką (computational environment), dėl šitos priežasties jis nebuvo paminėtas MDA programos kūrimo procese.

Tradicinio programavimo proceso metu, perėjimas nuo vieno modelio prie kito ar perėjimas nuo modelio prie programinio kodo atliekamas rankiniu būdu. Naudojant kodo generavimo įrankius galima dalį programinio kodo sugeneruoti, tačiau generacijos rezultatas - tai tik šablonas, ir vis tiek didžiąją dali jo tenka užpildyti rankomis (žr. 1 lent.). Tačiau MDA transformacijos visada vykdomos automatiškai naudojant programinius įrankius. Dauguma klasikinių automatinio kodo generavimo įrankių moka sugeneruoti programinį kodą iš PSM, nes šio modelio elementai ir sąryšiai tiesiogiai atitinka konkrečią platformą. Tai ką MDA apibrėžia naujo - tai PIM aukšto abstraktumo modelio automatinis transformavimas į tam tikrai platformai specifinį PSM modelį [3, 8p.].

1 lent. -- Programos kodo generacijos efektyvumas (ištrauka iš [5, 9p.])

	Neautomatizuota	Paprastas    UML	MDA
	s kodo rašymas	modeliavimas
Rankiniu būdu parašytų kodo eilučių	126	71	20
skaičius
Sugeneruotų eilučių skaičius	0	55	106
Visa kodo apimtis eilutėmis	126	126	126
Rankomis parašytų eilučių kiekis [%]	100	56	16

Matome, kad modelių transformavimas yra esminis programų kūrimo pagal MDA procesas, todėl nustatyti tokie šio tiriamojo darbo tikslai:

1.      Susipažinti su transformacijų MDA aplinkoje ypatumais ir sąsaja su OMG standartais;

2.      Sukurti eksperimentinius išeities ir tikslo metamodelius;

3.      Išanalizuoti   eksperimentinių   modelių   transformacijų   procesą   ir   suprojektuoti transformacijos algoritmą;

4.      Sukurti eksperimentinės transformacijos algoritmo realizaciją;

5.      Įvykdyti eksperimentines modelių transformacijas.

Sekančiame skyriuje pagrindžiamas tolesnis eksperimentinių metamodelių konstravimas, bei parenkamos transformacijų realizavimo priemonės.