PHP-põhise tarkvaraarenduse abivahendid.

Transcription

1 Tallinna Ülikool Matemaatika-loodusteaduskond Informaatika osakond PHP-põhise tarkvaraarenduse abivahendid. Seminaritöö Ahti Nurme Juhendaja: Jaagup Kippar Autor: a. Juhendaja: a. Osakonnajuhataja: a Tallinn 1

2 Sisukord 1 Sissejuhatus Teema valiku põhjendus Probleemi sõnastus Töö eesmärk Töö tulemus Töö struktuur PHP-põhine tarkvaraarendus ja selle abivahendid Tarkvaraarenduse mõiste Uuritava tarkvara ehk AutomatWebi tutvustus AW Object Request Broker AW Classbase AW Storage Kasutatavad tehnoloogiad Veahalduse, koodihalduse, paketihalduse ja koodi dokumentatsiooni tähtsus tarkvaraarenduses Paketihaldus RPM Dpkg FreeBSD Ports Collection Autopackage Veahaldus Bugzilla Mantis BugTracker Flyspray JIRA Trac AW BugTrack Koodihaldus GNU Arch Bazaar BitKeeper CVS Subversion Koodi dokumentatsioon Javadoc phpdocumentor PHPDoc AW DocGen PHPXref Kokkuvõte Kasutatud infoallikad Lisad Lisa 1: Javadoci levinumad märgendid Lisa 2: AW DocGeni praegune süntaks ja kuvapildistus Lisa 3: AW BugTracki kuvapildistus

3 1 Sissejuhatus 1.1 Teema valiku põhjendus Olles ise kokku puutunud programmeerimisega juba aastast 1999, alguses Perliga ja praeguseni PHP-ga, jäid minu teadmised ja oskused kuni eelmise aasta sügiseni suures osas vaid PHP programmeerimise tasemele, arusaam ja mõistmine tarkvaraarenduse olemusest on alles praegu järkjärgult välja kujunemas. Osalt oli see ka tingitud valitud programmeerimiskeele spetsiifikast, kuid suures osa ka PHP põhise tarkvara uudsusest ja sellest tulenevast reglementeerimatusest. Iseenest on ka PHP võimalused rakenduste valmistamisel oma Easy Deploy metoodika tõttu vägagi huvi pakkuv uurimisteema, otsustasin siiski keskenduda esialgu sellega seotud temaatikale. Praeguseks hetkeks on AutomatWebi temaatikal valminud 3 bakalaureusetööd, millest 2 on käsitlenud süsteemi üldiselt ja üks on käsitlenud kvaliteedi ja protsessijuhtimist AutomatWebi kontekstis, selletõttu tundus minu jaoks ülekohtune, et kõik kirjatükid on keskendunud pigem AutomatWebi funktsionaalsusele ja välimisele küljele, mitte arendamisele. Selletõttu sai antud temaatika käsitluse alla võetud. Kuna AutomatWebi areng tavapärasest veebiskript tegemisest tarkvaraarendusliku lähenemiseni on senimaani olnud vägagi aeglane ja puudulik, vajab tarkvaraarendus antud kontekstis lähemat uurimist ja väljatöötamist, et saada parim võimalik tulemus. Kuna tarkvaraarendus kui selline on oma olemuselt väga keeruline ja mitmekoeline süsteem, käsitleb seda temaatikat mõnes järgnevas töös. Sellepärast sai esialgu keskendutud just tarkvaraarendust toetavatele tegevustele, mille põhjal saab järgmises ringis juba sügavuti minna AutomatWebi enda arendamise juurde. 1.2 Probleemi sõnastus Aastast 1999 tegutsev veebifirma Struktuur Meedia on kogu see aeg arendanud veebipõhist tarkvaraplatvormi AutomatWeb. Alguses puhtalt PHP3-põhise CMS rakendusena alguse saanuna, on põhiarendus liikumas PHP5 peale, muutudes PHP põhisest arendusest suures osas teadmuspõhiseks arenduseks. Seni läheneti arendusele veebifirmade moodusel, viies muudatusi sisse vastavalt vajadusele, kuid seos klientide arvu kasvuga on kasvamas üle pea erinevate versioonide ja veaparanduste omavaheline sobitamine, tekitades tõsine vajadus tarkvaraarenduse juhtimise konkretiseerimiseks, alustades sellega seotud taustprotsessidest, eelkõigega sooviga pakkuda paremaid, lihtsamaid ja töökindlamaid lahendusi. 3

4 1.3 Töö eesmärk Seminaritöö eesmärk konkreetsemalt on teha ülevaade antud ettevõtte konteksti tarkvaraarenduseks sobivate vahendite kohta ja nende rakenduse otstarbekusest ja võimalusest PHP spetsifiikas, üldisemas plaanis on kolm eesmärki: Panna märk maha PHP põhise tarkvaraarenduse problemaatikast; Tekitada mingitmoodi juhis teistele sama temaatikaga kokku puutuvatele organisatsioonidele; Anda teemast huvitatutele programmeerijatele võimalus antud valdkonnaga tutvuda. Eelkõige keskendume siinkohal neljale vahendile: koodihaldus, paketihaldus, veahaldus ja koodi dokumentatsioon. See valik ei ole olnud juhuslik, vaid konkreetselt seotud AutomatWebi arengus ja plaanides viimasel kahel aastal toimunuga: koodihaldus on välja kasvamas CVS-ist, paketihaldus on teemaks olnud juba üle 2 aasta, veahalduse kohapealt sai AW BugTrack alustatud umbes aasta tagasi ning sai arenguhoo sisse nüüd, 2006 alguses ning koodi laiaulatuslikum dokumenteerimine AW DocGen abiga on praegu teoks saamas. 1.4 Töö tulemus Töö tulemusena peaks valmima ülevaade turul saadaolevatest vahenditest ja ka isearendamise võimalustest ja otstarbekusest, seda eelkõige ülevaadete ja soovituste formaadis. Täpsemalt üritame lahata ka antud vahendite sobivust AutomatWebi arenduse konteksti, proovides leida parimat lahendust antud töö raames, mille põhjal saaks rakendamist planeerima asuda. Üldisemalt võib seda käsitleda ka kui juhtnööre PHP-põhise tarkvaraarenduse pakendamise võimalustest lihtsast ja struktureerimata veebiprogrammeerimise kontekstist konkreetsemasse ja jätkusuutlikumasse tarkvaraarenduse konteksti. 1.5 Töö struktuur Ülesehituselt jaguneb töö kolmeks: 1. Sissejuhatus teemasse, kus käsitletakse valitud tarkvara ning PHP-põhise tarkvara arenduse spetsiifikat ning valitud teemade (koodi dokumentatsioon, koodihaldus, paketihaldus ja veahaldus) üldisemat tutvustust ja tähtsust AutomatWebi arenduses. 2. Konkretiseerimist, kus tutvustatakse iga teema kohta olemasolevaid lahendusi, pakutakse 4

5 omapoolseid variante ning antakse hinnang valiku kohta. 3. Kokkuvõte, kus üritatakse leitud lahendusi mõtestada lahti ühtse tervikuna, analüüsida koostoimet ning pakkuda kava edasiseks tegevuseks. 2 PHP-põhine tarkvaraarendus ja selle abivahendid 2.1 Tarkvaraarenduse mõiste Et mõista PHP-põhise tarkvaraarenduse spetsiifikat, peab kõigepealt seletama lahti tarkvaraarenduse kui sellise: lihtsalt seletades on tarkvaraarendus on tarkvara loomeprotsess. Üldjuhul peetakse tarkvaraarenduse all silmas tarkvara loomist inimgrupi poolt, kokkulepitud reeglite alusel. Formaalset tarkvara loomist üksikisiku poolt nimetatakse sageli lihtsalt programmeerimiseks (kuigi ka see võib sisaldada kõiki protsessi samme). Tarkvaraarenduse protsessi täpne kuju sõltub peamiselt arendatava tarkvara otstarbest ning loojate eelistustest ning kogemustest. Klassikaliselt sisaldab tarkvaraarendus järgmisi tegevusi (Pilt 3): Süsteemianalüüs (sageli ka nõuete analüüs, või spetsifitseerimine) - luuakse või määratakse kindlaks see, mida loodav tarkvara tegema peab, sageli ka lahenduse üldkuju. Sageli kasutatakse selleks prototüüpimist, mille käigus luuakse tulevase lahenduse osaline mudel, erinevate lahendusvariantide katsetamise või probleemi parema mõistmise eesmärgil. Disain - luuakse tarkvara sisemine arhitektuur - loogiline ülesehitus ning erinevate omaduste jaotus programmi osade vahel. Sageli luuakse disain väga üksikasjalik - pseudokoodi tasemel. Programmeerimine disainitud lahendus teostatakse programmeerimiskeeles, vajadusel kujundatakse tarkvara kasutajaliides. Sageli on disaini ja programmeerimise vahelise piiri tõmbamine raske. Mõned allikad peavad täpseimaks disainiks testitud programmi lähtekoodi. Testimine kontrollitakse lahenduse töökindlust, jõudlust ja eesmärgipärasust. Juurutamine olenevalt loodava tarkvara tüübist võib see tähendada nii tarkvara paigaldamist konkreetsesse keskkonda, kui ka lihtsalt müüki paiskamist. Sageli hõlmab juurutamine ka kasutajate koolitamist tarkvaraga töötamiseks. Hooldus vigade parandamine, täiendavate omaduste lisamine, kohandamine muutuva keskkonnaga, klienditugi. 5

6 Pilt 3. Tarkvaraarenduse elutsükkel. Nende tegevuste tegemise ulatus, järjekord ja täpne sisu olenevad suuresti arendaja poolt kasutatavast tarkvaraprotsessist. Näiteks viiakse nn. kosemudeli kohaselt eelnimetatud sammud läbi üksteise järel. Iteratiivse mudeli kohaselt seevastu koosneb kogu protsess mitmest järjestikusest tsüklist (iteratsioonist) mis kõik sisaldavad analüüsi, disaini, programmeerimist ja testimist kuid erinevates tsüklites on rõhk erinevatel sammudel. Tarkvara protsessimudeleid on praeguseks hetkeks tekkinud väga palju, igaüks oma spetsiifikaga, ning need arenevad pidevalt edasi. Vaadeldaval juhul ei lõppe tarkvaraarendus hooldusega, vaid on pidevalt kordu protsess. PHP on tarkvara kontekstis vägagi omapärane nähe: oma jõulise tulekuga aastast alates, kui lasti välja 4. versioon, on tekitanud väga huvitava olukorra, nimelt veebi tarkvarastumise. Kuni selle ajani oli veeb vägagi staatiline, vaid suuremad portaalilahendused olid dünaamiliselt genereeritavad, kui viimase kuue aasta jooksul on suurem osa veebist läinud üle dünaamilisele sisule, lõviosa nendest PHP-põhisel platvormil. Kuigi Microsoft ja Sun on oma.net ja Java erinevate versioonidega üritavad olemasolevat vahet tasa teha, on rong praegusel hetkel nende jaoks läinud: PHP on vaieldamatult kõige populaarsem veebirakenduste valmistamise keel 1. See omakorda nõuab teistmoodi lähenemist tarkvaraarendusse, kui tavapäraste programmeerimiskeelt nagu Java, C/C++ ja Visual Basic puhul. Tavapäraselt on tarkvaraarenduse 1 6

7 eesmärgiks saada kohe alguses parim lahendus, kuna ümbertegemine on kallim ja keerukam kui uuesti tegemine, siis PHP puhul on see probleem väiksema skaalaga. Olles oma olemuselt madala taseme skriptikeel, millele ei ole veel tehtud visuaalseid arenduskeskkondi (nagu teistele keeltele), on see siiski väga kiirelt omandatav, kirjutatav ja võimekas. Sellest tulenevalt peab arendamisprotsess olema paindlik, et see arenduskiirust takistama hakkaks, kuid samas piisavalt põhjalik, et kataks vajadusel ka teadmuspõhise arenduse. Sellest tulenevalt on suurem osa PHP arendust, vähemalt Eestis, mingi modifikatsioon XP-st[x]. Senimaani on üle 6 aasta toimunud AutomatWebi arendamine toimunud küll visioonorienteeritult, planeerides tuleviku jaoks, kuid tegevus ise on seni olnud küllaltki piiritlemata, eelkõige töömahtude ja arendusmeeskonna väiksuse tõttu. Kuna AutomatWebi suurus on viimase 2 aasta jooksul kahekordistunud (kui aastal 2004 oli 200,000 koodirida, siis praeguseks on peaaegu 400,000), kuid meeskonna maht jäänud enamvähem samaks, on tekkinud vajadus peale meeskonna jõulise laiendamise ka hallata ja koordineerida paremini AutomatWebi arendamist. Samas on muutunud ka tegevuste spetsiifika: kui 2004 aastal oli põhiline arendustegevus koondunud sisuhalduse ja AW baassüsteemi võimaluste arendamisele ning saadi hakkama tavapärase mudeliga, kus programmeerija arendas võimalusi, kujundaja lõi kujunduse ja sidus HTML-iga ning projektijuht testis/suhtles kliendiga/haldas sisu, siis praeguseks on suurem osa arendustegevusest koondunud eelkõige ärirakendustele, nagu kliendihaldus ja ressursiplaneerimine, kus oleks vaja veidike konkreetsemat rollide jaotamist, kui seni on toimunud, ning see on omakorda seotud antud uurimustöö temaatikaga. 2.2 Uuritava tarkvara ehk AutomatWebi tutvustus Kuna töö olemuse mõistmiseks on tähtis ka uuritava tarkvara tundmine, toon järgnevalt ära AutomaWebi lühikese tutvustuse: AutomatWeb on Struktuur Meedia väljatöötatud üle interneti kasutatav tarkvaraplatvorm veebilahenduste jaoks. AutomatWebi nimetatakse platvormiks, kuna üks ja sama tarkvara baasosa koondab endas kümmekond erinevat tooteperekonda. See on AutomatWebi peamisi eeliseid - ennast tõestanud platvorm koos suure moodulite hulgaga. Praeguseks võib AutomatWebi ühtses tarkvarakeskkonnas kasutada kõiki populaarsemaid interneti teenuseid alates sisuhaldusest kuni aja- ja kliendihalduseni. Uute võimaluste hulk kasvab kiiresti tänu süsteemi paindlikkusele. 7

8 Platvormi ülesehitusest ehk süsteemiarhitektuurist sõltuvad väga paljud omadused: avatus uutele arendustele, paindlikkus ja liidestatavus, turvalisus. AutomatWebi süsteemiarhitektuur põhineb kolmel sambal ehk kolmel olulisemal tehnoloogial (Pilt 9). Pilt 9. AutomatWebi süsteemiarhitektuur. Igal sambal on oma väljundid nii tootearendajatele kui ka praegustele ja tulevastele AutomatWebi klientidele: AW Object Request Broker AW Object Request Broker on närvikeskus, mis vahendab programmisiseseid ja väljast tulevaid päringuid. Veebipõhiste tarkvarade puhul toimub programmile käskude edasiandmine hüperlingi ehk URLi kaudu, mida kontrollib ORB. ORB on moodulite vahelise suhtluse protokoll, mis võimaldab näiteks eri programmeerimisekeeltes loodud ning eri serverites asuvatel moodulitel omavahel suhelda. Teiseks on ORB meetod, millega kirjeldatakse XML formaadis ära mooduli API kasutamise tingimused. See võimaldab kasutajal süsteemi kasutada just niipalju, kui ORBi kihis on deklareeritud ning ei luba mooduli seest suvalisi funktsioone ja parameetreid välja kutsuda. 8

9 ORBi väljundid: täiendav koht, kus kontrollitakse kasutajaõigusi, valideeritakse kasutaja poolt sisestatud infot, sealhulgas URLe. Alles siis, kui andmed on valideeritud, tõmmatakse vastav klass käima. See suurendab tunduvalt süsteemi turvalisust häkkimise vastu, võimaldab päringuid ka teistest süsteemidest vastu võtta, URLides kasutatavate avalike meetodite dünaamiline genereerimine, tagab AWle XML-RPC Web Services toe kogu programmi ulatuses, on lüliks AW API ja teiste süsteemide vahel üle Web Services kihi (XML-RPC, SOAP), klassidele saab luua erinevaid liideseid ORBi tasemel AW Classbase AW Classbase on täiendav abstraheerimise vahend klassipõhiselt kasutajaliidese ehitamiseks ja sellega manipuleerimiseks. Tänu Classbasele käib AutomatWebi uute ühtlase kasutajaliidesega moodulite loomine kiiresti. Kogu funktsionaalsus mida lõppkasutaja ekraanilt näeb, pärineb andmebaasist, kus on ära kirjeldatud kõik kasutajaliidese võimalused. Klassi ehk mooduli vormistamise viimane tegevus on kogu AW omaduste andmebaasi põhjal uue kasutajaliidese kihi kompileerimine. Classbase väljundid: lihtsustab ja kiirendab kasutajaliidese ehitamist, ühtlane visuaalsetel komponentidel põhinev kasutajaliides lõppkasutajale, uute visuaalsete komponentide kasutamine koheselt kogu AW ulatuses, liidese stiilide muutmine ühest kohast, erinevate kujundusmallidega HTML liideste loomine, ühtne andmete salvestamise loogika ja valideerimisvõimalused, klassi omaduste kirjeldamine päises lisab AWle läbipaistvuse, teeb koodi vabalt loetavaks, ühele klassile võib samas süsteemis luua mitu erinevat kasutajaliidest, standardiseerib klassi vormistuse, võimaldab AWle genereerida teisi kasutajaliideseid peale HTMLi (näiteks Applet, GTK, Winforms, XAML, XUL), tagab seostehalduri mugava kasutamise. 9

10 2.2.3 AW Storage AW Storage eesmärk on rakenduste tasemel päringute võimalikult abstraktne kirjeldus ja ühtse päringuloogika tagamine kogu programmi ulatuses. AW Storaget võib kujutleda suure torustikuvõrguna, läbi mille liiguvad kõik AW andmepäringud. Storage suunab andmed vastavalt parameetritele kitsamate torude kaudu näiteks läbi andmeallika filtri My-SQL andmebaasi või läbi integratsioonikihi välistesse rakendustesse. Storage üheks olulisemaks alamkomponendiks on seostehaldur, mis haldab dünaamiliselt objektidevahelisi seoseid. Dünaamiline seos on näiteks kliendibaasis leiduva organisatsiooni alla lisatud sündmuse (kõne, kohtumine, leping jt) automaatne seostamine lisaja personaalse kalendriga. Seostehaldur on abiks ka käsitsi seoste loomisel, näiteks saab kalendrisündmusega siduda faile (koosolekuprotokoll) ja teisi objekte. Seostehaldur muudab objektidevaheliste seoste loomise süsteemile ja lõppkasutajatele ühtlaseks ja võimaldab objekte korduvkasutada. Storage väljundid: kasutajaõiguste kontrollimine, ühtlustatud andmebaasipäringud, minimeerib vigaste päringute arvu, muudab päringute optimeerimise tsentraalseks, garanteerib õiguste kontrolli päringute/andmete tasemel, võimaldab granulaarselt andmepäringuid vahemällu salvestada (cacheda), päringud salvestatakse kompileeritud kujul massiivi, võimaldab hõlpsasti lisada teiste andmebaasiserverite tuge kogu programmi ulatuses, võimaldab saada ülitäpse ülevaate sellest, milliseid päringuid süsteemis tehakse, tagab ühtse loogikaga objektidevahelised seosed Kasutatavad tehnoloogiad AutomatWebi töö ei eelda ühegi tasulise tarkvara olemasolu. AutomatWeb on täielikult programmeeritud PHP4-s ja kasutab sujuvaks töötamiseks ka PHP- või ZEND-Acceleratorit. Praktikas töötab AutomatWeb Linux, Free- ja Open BSD, AIX, Solaris ja muudes UNIXi laadsetes operatsioonisüsteemides. On lahendusi, kus AutomatWeb töötab ka Windows platvormil, kuid problemaatilisena. AutomatWebi objektisüsteemi andmebaasiserverina kasutatatakse My-SQLi. Suhtlemine My-SQL andmebaasiga käib üle vastava draiveri. Käesolevaks hetkeks on AutomatWebile arendatud ka MS- 10

11 SQL draiver, praktilist kasutamist leiab see lisandväärtusega teiste andmebaasiserveritega suhtlemisel [3]. AutomatWebi detailsema kirjelduse võib leida Raul Viigipuu 2005 aastal valminud lõputööst Ülevaade AutomatWebi platvormist. HTML kujunduse ühendamise juhend AutomatWebiga. 11

12 3 Veahalduse, koodihalduse, paketihalduse ja koodi dokumentatsiooni tähtsus tarkvaraarenduses Antud uurimustöö puhul on vägagi tähtis lahti seletada, mis tähtsus on nimetatud vahenditel PHPpõhises tarkvaraarenduses, nii üldiselt kui ka AutomatWebi spetsiifiliselt lähenedes. Kuna tarkvara kui selline ei ole oma olemuselt monoliitne moodustis, mis saaks mingi hetk valmis ja püsiks sellisena 600 aastat, vaid on pidevas ja korduvas arengus, peavad olema kõik selle arendamist toetavad tegevused olema sama paindlikud. Esmatähtis on alati kõige värskema ja asjakohasema informatsiooni saamine, nii tarkvara arendustsüklist üldiselt, kui ka selle konkreetsetest etappidest. Just selle informatsiooni pakkumine ongi antud tööriistade ülesanne. Kuid tähtis ei ole mitte ainult informatsioon ja ülevaatlikus ise, vaid selle asumine üldises kontekstis, mida pakub terve arendusprotsessi talletamine, millega tegeleb iga tööriist ise küljest. Koodihaldus talletab kogu tarkvara elutsükli jooksul arendatud koodi, mille põhjal saab hiljem ennustada edaspidiseid tegevusi ning lähenemisi, veahaldus toetab tarkvaraarendamist selle kõikidel eluetappidel, andes arendajatele otsest tagasisidet koodi kvaliteedi kui ka funktsionaalsuse kohta, koodi dokumentatsioon on sotsiaalne mälu nii testimise kui arendamise juures, võimaldades uut ja olemasolevat funktsionaalsust kiiremini ja lihtsamini rakendada ning paketihaldus, andes kasutajatele võimaluse paindlikuks uuendamiseks ja kasutamiseks, testijale läbi veahalduse ülevaate koodi küpsusest, arendajale tagasiside funktsionaalsuse kasutatavuse ja veaparanduste efektiivuse kohta ning palju-palju muudki (Pilt 4). 12

13 Pilt 4. Koodihalduse, paketihalduse, veahalduse ja koodi dokumentatsiooni seotus tarkara arendustsükli erinevate etappidega. Seda kõike muidugi ideaaljuhul, kui tegevuste haldamine käib läbi mainitud tööriistade, mistõttu peab nende kasutamine, kasutuselevõtmine ja koostoime olema kas võimalikult lihtne, võimalikult efektiivne või mõlemat. Mis toobki meid vajaduse juurde määratleda ära see täpsem vajadus, mille põhjal saaks hakata otsima parimat lahendust. Üks hea printsiip, mida siinjuures silmas pidada, on KISS põhimõte: Keep It Simple, Stupid ehk kõige suurema funktsionaalsusega vahend ei ole tingimata alati parim, kui seda ei saa mugandada konkreetsetele vajadustele vastavaks. Samas tekib ka küsimus, miks arendada ise, kui on võimalus võtta kasutusel juba valmistoode, mis pakub sama funktsionaalsust? Ühest vastust on siinkohal raske anda, kuid vähemalt nendes osas, mille arendamine on realistlik (koodihaldus seda kohe kindlasti ei ole), on seni töötanud kõige paremini just ise valmistatud lahendused, eelkõige just selletõttu, et sidumine olemasoleva funktsionaalsusega on üsnagi valutu. Kui vaadata konkreetsemalt koodihalduse vajadusi, siis on peapõhjus uue otsimiseks CVS-i funktsionaalsuse piiratus AutomatWebi arendamise tarvis. CVS töötab küll ideaalselt, kuid kuna on tekkinud palju kliente, kelle rakenduses on kasutatud nendele spetsiifilist koodi, siis puudub hetkel CVS-i vahenditega võimalus seda hallata. Umbes kaks aastat tagasi üritati arendust viia eri okste peale, et üks oleks arendusversioon ja teine kliendiversioon, kuid kuna kahe erineva oksa kokkusobitamine toimus CVS-i puhul käsitsi, ei tundunud iga nädal 50 erineva faili kokku panemine ja konfliktide puhastamine absoluutselt hea mõttena. Pidades tulevikku silmas, on tähtis, et peale kliendispetsiifika haldamise saaks arenduse ja kliendiversioonid erinevatesse harudesse lahku aetud ning iga suurema arenduse või ümberkorralduse jaoks saaks teha erineva haru, mille hiljem arenduskoodi ja sealt kliendi koodi ühendab. Üks põhilise probleeme praeguse ühe oksa lähenemises ongi asjaolu, et puudub ülevaade, kas antud funktsionaalsus töötab või mitte, enne kui see on lisatud koodibaasi ning kuskil testitud ning kui samal ajal on tekkinud vajadus kliendikoodi uuendada, siis on õnnetud tagajärjed kerged tulema. Selletõttu peaks uus lahendus pakkuma peale töökindluse ja lihtsuse ka korralikku funktsionaalsust. Koodi dokumentatsiooni eesmärk on üle saada vaakumist praeguse puuduliku dokumentatsiooni pakutu ning uute AW õppijate vajaduste vahel. Praegune dokumentatsioon on küll mingis osas eksisteeriv, kuid vägagi hajutatud, olles eri aegadel eri meetoditel koostatud ning kohati vägagi aegunud. Tulev lahendus kas seoks kogu olemasoleva ühtsesse süsteemi või siis laiendaks seda. Koodi automaatse dokumenteerimise keskkond on küll AW DocGeni näol olemas, kuid hetkel veel keeruline kasutada ning vähefunktsionaalne ning dokumenteerimisformaat puudulik, kuid selle teema aktuaalsus sunnib kiiresti leidma optimaalse lahenduse nii funktsionaalsuse kui ka formaadi 13

14 osas. Pikemas perspektiivis on vaja pakkuda mingisugust tuge ka arendajatele, kes kasutavad AW-d nii oma süsteemiga liidestamiseks kui ka litsentseerivad platvormi arendamiseks. Veahaldus on seni olnud üks AW murelapsi, millest on üle saadud vaid tohutu koguse sündmuste abil. Kuna AW on laialdaselt kasutatav süsteem, siis avastavad kasutajad mitmeidki vigu, mida kliendikoodis õnneks väga ohtralt ei esine eelkõige lahenduste lihtsuse tõttu, kuid ärirakenduste suuna keerukuse ja mahukuse tõttu hakkab üha enam esile kerkima. Praegune lahendus AW BugTracki näol on alles arenemas staadiumisse, kus oleks võimalik vigu selle kaudu hallata. Selle valmimisega seotud tegevustest on kindlasti üsnagi prioriteetne eraldi testija ametikoha loomine, sest praeguste mahtude juures on üsnagi utoopiline ilma konkreetse tegevuseta tagada AW veakindlus. Kuna testija töö nõuab pidevat tegelemist ka veahaldusega, saab tänu sellele veel paremini spetsifitseerida ja arendada lõpuni vajadused nii vea- kui arendustegevusehalduses üldisemalt. Paketihaldus kui vajalik vahend arendustegevuse parandamiseks on olnud jututeemaks praeguseks juba üle kahe aasta, kuid senimaani ei ole esialgsetest ideedest kaugemale jõutud. Ühest küljest on see vägagi laialivalguv teema, nõudes enne arendamist ka konkreetsemat spetsifitseerimist just tööprotsessi osas, samas on see tekitanud ka teatava nokk-kinni-saba-lahti efekti, kus paketihalduse arendamiseks vajalikud tegevused seisvad nii mingis osas nii otseselt kui kaudselt paketihalduse puudumise taga. Konkreetse lähenemise kohta on raske ühtset seisukohta võtta, kuid see peaks kindlasti võimaldama AW enda kaudu haldamist ning vajadusel ka mingi muu süsteemi paketina väljastamist (nagu Windows Installer, rpm või dpkg). 14

15 4 Paketihaldus Paketihaldussüsteem on olemuselt kollektsioon tööriistu, mis automatiseerivad tarkvarapakettide arvutile paigaldamise, uuendamise, konfigureerimise ja eemaldamise. Seda lähenemist kasutatakse kõige sagedamine Unixilaadsete süsteemide puhul, eriti Linuxil, mis on väga tugevalt sellega seotud ning kus tüüpiline esmapaigaldamine koosneb tuhandetest väikestest pakettidest. Tarkvaraarenduse kontekstis on paketihalduse mõte hallata tarkvara elutsükli osasid valmimisest kuni hoolduseni (Pilt 5). Pilt 5. Paketihalduse roll tarkvaraarenduse elutsüklis. Tüüpiliselt on tarkvara sellistest süsteemides eraldi ühest failist koosnevate pakettide kujul, mis sisaldavad tihti ka muud vajalikku informatsiooni, nagu täisnime, versiooni, arendajat, kontrollsummat ja seotud pakettide kohta, mida vaja programmi käivitamiseks. Paketihalduse ülesanne on hallata kõiki pakette, mis on süsteemi paigaldatud ning säilitada nende kasutatavus, erinevad paketihaldused kasutavad erinevaid kombinatsioone järgnevatest selle saavutamiseks: Verifitseeritakse faili kontrollsumma, et vältida erinevusi allalaaditud ja ametliku paketi vahel; Lihtne paigaldamine, uuendamine ja eemaldamine; 15

16 Sõltuvuste jälgimine, et tagada töötav tarkvara; Uuenduste kontroll, et saada alati kõige värskem versioon tarkvarast, sealhulgas veaparandusi ja turvapaike; Pakettide grupeerimine funktsionaalsuse järgi, et vähendada kasutajate segadust paigaldamisel ja haldamisel. Tänapäeval on kasutusel palju erinevaid paketihaldussüsteem, millest tuntuimad on: dpkg, algupäraselt kasutatud Debian GNU/Linux-il ja praeguseks ka sellest põlvnevatele distributsioonidel, kasutab.deb failiformaati ja oli esimene, kes võttis laiaulatuslikult kasutusele sõltuvuste haldamise töövahendi, APT-i. FreeBSD Ports Collection, vahel tuntud ka kui ports, kasutab Makefile-isid tarkvara paigaldamiseks binaaridest või lähtekoodist. Fink, kasutatakse Mac OS X-is, pärit osaliselt dpkg/apt-ist ja ports-ist. OS X kasutab samas ka süsteemi nimega Installer. RPM Package Manager, loodud Red Hat-i poolt ja kasutatakse praegu mitmetes Linuxi distributsioonides. Linux Standard Base on üritanud RPM-ist teha Linuximaailma standardit, kuid Debiani toetajate vastuseisu ja liiga väikese kõlapinna tõttu ei ole see teoks saanud. RPM-ile on ka palju lisatööriistu, nagu apt4rpm, Red Hati up2date, Mandriva urpmi, SuSE YaST ja Fedora Core-i YUM. Windows Installer, kasutatakse suurema osa Windows-i tarkvara paigaldamiseks. Autopackage, loodud RPM-i ja dpkg täiendamiseks, lihtsustades pakettide haldamist erinevate distributsioonide vahel. Kuna kõik vaadeldavad paketihaldused on loodud konkreetse vajaduse rahuldamiseks (antud tarkvaraversioonide paigaldamiseks antud süsteemi) ning on olemuselt keerukad ning mahukad, hindame siinkohal neid pigem ideelisest küljest, pidades silmas, mis plusse ühel ja teisel on ning vastavalt sellele koostada optimaalne lahendus konkreetseks otstarbeks. Kuna AutomatWebi puhul on ilmselgelt paketihaldusega seotud koodihaldus (AutomatWebi kasutatakse otse lähtekoodi kujul), üritame hindamisel vaadelda ka nende kahe koostoimimise võimalusi. 4.1 RPM RPM Package Manager (või RPM, algupärase nimetusega Red Hat Package Manager) on kõige laiaulatuslikumalt kasutusel olev paketihaldussüsteem Linuxile. RPM haldab kogu pakettide 16

17 paigaldamist, eemaldamist, uuendamist, verifitseerimist ja päringuid. Algupäraselt arendatud Red Hat Linuxi jaoks, on RPM nüüdseks kasutusel ka paljudes muudes Linuxi distributsioonides. RPM on porditud ka teistele operatsioonisüsteemidele, nagu Novell NetWare ja IMB AIX. RPM paketihalduse baassüsteemiks on RPM andmebaas, mis koosneb kõikide paigaldatud pakettide informatsiooni sisaldavast topeltviidetega nimekirjast. Andmebaas peab arvet kõikide failide üle, mis on paigaldatud või lisatud, tehes nende eemaldamise seeläbi lihtsaks. Kui andmebaas katkeb (mida juhtub tihti, kui RPM-i klient vägisi peatada), siis topeltviited hoolitsevad selle eest, et andmebaas oleks võimalik uuesti üles ehitada. Igal RPM paketil on oma silt, mis sisaldab järgnevat infot: tarkvara nimi tarkvara versioon paketi versioon (mitmes pakett antud tarkvarast tehtud on), tihti kasutatakse seda välja ka märkimaks, millise distributsiooni jaoks antud pakett mõeldud on, näiteks fc4 Fedora Core 4 jaoks, rhl9 Red Hat Linux 9 ja suse93 SuSE Linux 9.3 jne. Arvuti arhitektuur, mille jaoks see pakett sai tehtud (näiteks i386, i686, athlon, ppc jne) ja RPM failil on tavaliselt järgnev formaat: <nimi>-<versioon>-<pakett>.<arhitektuur>.rpm Näiteks: nano i386.rpm Samas, paketi nimi ei pruugi ühtida sildil kirjeldatuga, kuna viimast hoitakse paketi sees eraldi. Paketi võidakse abil jagada ka lähtekoodi, asendades arhitektuuri kirjelduse src märgendiga. Näiteks: libgnomeuimm src.rpm Samamoodi levitatakse teeke pakettides kahe eraldi versioonina, üks eelkompileeritud koodiga ja teine arendussfailidega, viimastel tavaliselt märgend -devel lisatud nime väljale. Kasutajad peavad sellisel juhul väga tähelepanelikult jälgima, et arendusfailid vastavad kompileeritud paketiga, vastasel juhul ei pruugi teek väga hästi töötada. 17

18 RPM võimaldab jagada ka arhitektuurist sõltumatuid pakette, nagu graafikat ja teksti teiste programmide jaoks, märkides seda noarch -iga arhitektuurisildiga. RPM-i nagu dpkg-d, ei kasutata tavaliselt iseseisvalt, vaid läbi automaatse sõltuvushalduste programmi, nagu YUM või APT. YUM (Yellow Dog Updater Modified) loodi algselt Red Hati pakettide haldamiseks Duke-i ülikoolis, kuid üsna pea võeti kasutusele ka mitmetes teistes Linuxi distributsioonides, nagu Fedora Core, CentOS jpt. YUM-ile on tehtud ka mitmeid graafilisi liideseid, nagu Kyum. RPM pakettide plussid on ühtne programmide paigaldamise viis, populaarsus, automaatne paigaldus, paketide verifikatsioon; samas miinuste kohapealt on RPM paketid tagasiühildamatud pakettide formaatide muutumise korral, ebatäiuslik ja aegunud dokumentatsioon, vastuolulised sõltuvusseosed sõltuvalt Linuxi distributsioonist jpm. RPM-ile on ette heidetud järjepidevuse puudumist pakettide nimetamisel, tehes seeläbi automaatse sõltuvusseoste haldamise raskeks, mis ei ole otseselt RPM formaadi, kui just erinevate RPM-i kasutatavate distributsioonide haldajate koostöö puudulikkusest tulenev probleem. Kui kasutada Fedora Core jaoks ainult Fedora Core-i pakette, siis suudavad automaatsed sõltuvustehaldused, nagu apt ja yum, konfliktide lahendamisega hakkama saada, sama toimib ka teiste distributsioonide puhul. RPM paketi saab luua tehes spetsiaalse.spec lõpuga faili, kus on kirjas paketi nimi, versioon, y RPM-i versioon, loomise ja eemaldamiseks vajalikud sammud ja changelog. Samast.spec failist saab vajadusele luua ka mitmeid pakette, pakettide loomine toimub spetsiaalse rpmbuild tööriista abil. RPM-i käsitledes ei saa mööda minna sellisest mõistest nagu dependency hell või siis teisiti ka RPM hell. Depenency hell on olukord, kus üks pakett tahab paigaldamiseks saada mingi teise paketi olemasolu, kuid teine pakett ei ole kas kättesaadav või liiga uus, mille peale nii RPM ja dpkg keelduvad soovitud toimingut sooritamast. Neid saab küll sundida seda tegema, kuid tagajärjeks on tihti veelgi suurem segadus, mis võib viia kergesti süsteemi uuesti paigaldamiseni. Vahel võib ka juhtuda, et üks pakett sõltub teisest, teine kolmandast ja see omakorda neljandast, mis tähendab kokkuvõtteks meeletu pakikoguse paigaldamist, et esialgne tööle saada. Selliste olukordade vältimiseks loodi paketihaldustele automaatsed tööriistad nagu yum ja apt, mis üldjuhul tirivad pakette ühest veebis olevast baasist ning üritavad lihtsamaid segadusi ise parandada, kuid keerukamate süsteemide korral jäävad nemadki hätta. 18

19 Oma kogemuse põhjal RPM-i paketihaldusega Fedora Core-i võin väita, et kuigi tavaseadetes töötab see küllaltki rahuldavalt, lihtsamad uuendamised saab tehtud väiksema ja vahel ka suurema vaevaga, ei saa yum ega apt hakkama kogu süsteemi uuendamisega, sest paketibaas muutub distributsiooni versioonides vägagi palju, ning lõppeb tohutu segadusega, mille kõrvaldamiseks peab kas meeletu koguse pakette käsitsi eemaldama või süsteemi nullist üles ehitama. RPM-i paketihalduse puudus tundub olevat ka automaatsete töövahendite rpmi-i baassüsteemi vähene koostöö, mis väljendub pidevas vajaduses pakette käsitsi paigaldada ning uuendada ja paketibaasi väiksuses, mille tulemusele olen senimaani vältinud vastava paketihaldusega Linuxi distributsioonide kasutamist. Iseenest ei ole dependency hell uus nähtus, vaid eksisteeris juba Unixi hiilgeaegadel, kui tarkvara paigaldati konfiguratsiooniskriptide abil, kus olid kirjas vajalikud sõltuvused teiste pakettidega. Selliste segaduste vältimiseks on välja töötatud mitmeid lahendusi, üks nendest on võrgufailisüsteem, kus kõik failid peale privaatsete on globaalselt unikaalsed. Seni ainus näide selle kohta on Coda failisüsteem, mis on tasapisi jõudmas kasutusküpsuseni. 4.2 Dpkg Dpkg on Debiani ametlik paketihaldussüsteem, mis loodi 1993 Ian Jacksoni poolt. Dpkg on olemuselt sarnane RPM-iga, kuna ta teeb samu operatsioone, kuid on tollest kõvasti vanem, seega võib öelda pigem, et RPM on dpkg-ga sarnane. Dpkg, nagu RPM-gi, on ise madala taseme tööriist, teised vahendid nagu APT, haldavad pakettide allalaadimist paketibaasidest ja lahendavad keerukaid sõltuvusseoseid. Dpkg pakett ise koondab endas põhilise vahendeid pakettide paigaldamiseks ja haldamiseks, dpkg-dev aga pakettide ehitamiseks. Tavalise kasutatatakse dpkg pakettide tegemiseks tööriista nimega dpkg-buildpackage, mis tahab nelja kohutuslikku faili, mille järgi paketi koostada: copyright, kus on kirjas litsentsitingimused; control, mis sisaldab paketi nime, kirjeldust ja sõltuvusi; rules, olles Makefile juhistega paketi koostamiseks; changelog, mis kujutab endast loogiliselt järeldades changelog-i. Pärast paketi ehitamist testitakse seda tüüpiliselt lintian-i nimelise tööriistaga, mis otsib probleeme ja ebakõlasid paketist. 19

20 Dpkg paketi nimi pannakse sarnaselt RPM-ile kokku järgnevalt: <pakett>_<versioon>-<debianiversioon>.deb ning koosneb peale programmi enda veel järgnevatest failidest: Makefile, paketihalduse jaoks jaoks; control, sisaldab informatsiooni ja seadeid, nagu sõltuvusi teiste pakettidega; skriptid, mingid tegevused peale või enne paigaldamist, mis on vaja ära teha (nt konfigureerimine peale paigaldamist). Dpkg puhul hallatakse pakettide paigaldamist tasemete järgi: Required paketid, mis on süsteemi toimimiseks hädavajalikud ning mida dpkg eemaldada ei luba. On vähetõenäoline, et ainult Required pakettidega süsteem töötab, kuid kindlasti piisavalt, et paigaldada uusi pakette. Important lisapaketid, ilma milleta on kasutamine raskendatud. Nende hulgas ei ole ühtegi suuremat süsteemi, kõik on väiksemad lisakomponendid. Standard kõik paketid, mida kasutajal tavaliselt vaja läheb, nagu gcc jms. Optional suurem osa tarkvarapakette, nagu X11 ja Emacs. Extra kõik, mida mingil põhjusel ei sobi Optional alla panna. Sarnaselt eelnevaga, toimub sõltuvuste haldamine ka läbi erinevate juhtude: sõltuvus pakett A sõltub pakett B-st; rangelt soovitamine paketti peaks kasutama ainult koos paketiga B; soovitamine pakett A soovitab ka pakett B paigaldamist; konflikt pakett A ei sobi kokku paketiga B; asendamine pakett A on loodud asendama paketti B (üks konflikti erijuhte); hõlmamine pakett A sisaldab ka kogu paketi B funktsionaalsust. Dpkg-d ainuüksi kasutatakse üldiselt vägagi vähe, peaaegu alati toimub kogu pakettide haldamine läbi tema eesliidese, APT-i. APT (Advanced Packaging Tool) ise ei ole otseselt tööriist, vaid kogu 20

21 C++ programme, mis tegelevad erinevate paketihalduse osadega, neist kasutatavaim on apt-get. APT on porditud ka RPM-i ja Mac OS X jaoks (Fink-i osana), kuid põhiliselt kasutatakse seda siiski Debiani-põhistes süsteemides. Apt kasutab paketihalduses Debiani paketibaasi, kus on kättesaadavad üle 17,000 erineva paketi. Baase võib ka läbi konfiguratsioonifaili ise lisada, samuti saab seal ka määrata paketide allalaadimise eeskirju (nt millisest versioonist kõigepealt paketti otsida, kas stable, testing või unstable). Baasiks saab ka CD plaate või muid võrgus asuvaid andmehoidlaid kasutada. Apt-i kasutamine on vägagi lihtne, erinevalt dpkg või RPM süsteemist, kus pead ette andma olemasoleva faili ja siis see paigaldatakse, saad apt-i abil kõigepealt otsida vajaliku faili ning siis vastavalt selle paketibaasi nimele paigaldada, igasugune arhitektuuri vms haldus toimub automaatselt. Samuti suudab apt vajadusel automaatselt ise kogu süsteemi paketid uuendada, näiteks iga pühapäeva öösel cron-i tööna. Isiklikult olen ni Debiani süsteemi kui apt-i tõsine süsteem, eelkõige just selletõttu, et peale erinevate Linuxi distributsioonide proovist, kus pakettide uuendamine oli kõige valusam teema, kasutasin süsteemi, mille paigaldamine oli kohati problemaatiline, kuid uuendamine ja tööshoidmine väga lihtne ja mõnus. Tavapäraselt üritavad erinevad Linuxi distributsioonid kasutajaid meelitada mingite imeliste lisavidinatega, nagu automaatne WIFI tugi või ilus kasutajaliides, mida Debianil vaikimisi vähemalt aasta tagasi ei olnud. Kuna minu kasutuses oli sülearvuti, mis ei olnud väga üldlevinud riistvaraga (Bluetooth, kolmanda osapoole WIFI jms), tundus esialgu mugava süsteemi paigaldamine väga utoopiline, kasvõi selletõttu, et Debian ei suutnud isegi Pentium M protsessorit ära tunda ning arvuti kippus üle kuumenema, sai Interneti kaasabil lõpuks nii sobilik Linuxi kernel kui ka vajalik WIFI draiver dpkg-buildpackage abil kokku lastud ning paigaldatud, mis veelkord tõestas dpkg võimsust ja lihtsust minu jaoks, nimetamata kahekäsulisi süsteemiuuendamisi. 4.3 FreeBSD Ports Collection FreeBSD Ports Collection pakub lihtsat ja mugavat viisi paigaldada tarkvara FreeBSD-le, kasutades Makefile-e, tehes paigaldamise ja eemaldamise võimalikuks make käsuga. Kui aplikatsiooni paigaldatakse, ei pea kasutaja tavaliselt rohkem tegema, kui algkäskluse andma, ning programm laetakse automaatselt Internetist alla, konfigureeritakse, kompileeritakse, paigaldatakse ja registreeritakse pakettide andmebaasi ning võimaluse korral paigaldatakse ka sõltuvuse tõttu vajatavad paketid ning uuendused. 21

22 Igat paketti haldab vabatahtlik paketihaldur, kelle ülesandeks on olla kursis kõigi selle paketi arenduses toimuvaga ning hoiab seda ka kasutamiskõlblikuna. Igaüks võib saada paketihalduriks, võttes siis kas mõne haldurita paketi oma hallata või pannes üldisse baasi mõne oma loomingu. Kuna Ports Collectionisse lisatakse uusi pakette pidevalt, ei ole kasutajatel tihti tarvis kuskilt väljastpoolt vajalikke programme otsima asudagi, sest 2006 märtsi seisuga on Ports'i paketibaasis üle 14,100 paketi. FreeBSD puhul eristatakse eelkompileeritud pakette lähtekoodiga pakettidest, mida on samuti võimalik vabalt üldisest baasist alla laadida. FreeBSD-l on ka spetsiaalne kompileerimisfarm, mis tegeleb pidevalt pakettide kompileerimisega erinevatele platvormidele ning pakub pidevalt tagasisidet paketihalduritele vigade ning logide kohta, et viimane omaks head ülevaadet platvormide sobivusest ning tarkvara puudustest ja saaks kompileerimisvead võimalikult kiiresti kõrvaldada. Nagu RPM-i ja dpkg puhul, jagatakse kompileeritud paketid erinevatesse kaustadesse. -release kaustas on paketid, mis kompileeriti konkreetse FreeBSD versiooniga koos ning neid ei uuendata peale seda enam, -stable ja -current kaustades on kõige värskemad versioonid, mida uuendatakse keskeltläbi kord nädalas. Peaaegu alati saab vanema FreeBSD versiooni jaoks kompileeritud paketti paigaldada ka uuemale versioonile, sest koguaeg pannakse rõhku ka tagasiühilduvusele. IA32 binaarse ühilduvuse kiht lubab paljusid i386 pakette kasutada ka amd64 arhitektuuril. Isiklik kokkupuude antud süsteemiga on puudunud, kuid tean, et paljud serveriadministraatorid eelistavad FreeBSD-d peale töökindluse ka RPM hell-i puudumise tõttu, kus sa saad vajaliku konfiguratsiooniga süsteemi ise kokku panna, sõltumata meeletust kogusest lisapakettidest. 4.4 Autopackage Autopackage on võrdlemisi uus ja arenev paketihaldussüsteem Linuxile, mõeldud kasutamiseks ükskõik millise distributsiooni all, mis eristabki teda teistest paketihaldustest. Erinevalt RPM ja Deb paketiformaatidest, kontrollib Autopackage pakettide sõltuvusseoseid tegelikul süsteemil, mitte paketiinfo andmebaasil. Kuigi see lähenemine vähendab probleeme, mis tulenevad pakettide erinevast nimesüsteemidest, teeb see Autopackage-i tegelikult aeglasemaks distributsiooni oma paketihaldusest. Autopackage-i paketid on tegelikuses bash-i skriptid, mida saab paigaldada lihtsalt neid käima lastes. Autopackage sai loodud eelkõige eesmärgiga teha pakettide paigaldamine Linuxis kõige lihtsamaks üldse, üritades olla kasutuselt sarnane nii Mac OS X-i programmikaustadega kui ka Windows Installeri lihtsa liidesega. 22

23 Autopackage on mõeldud aplikatsioonide paigaldamiseks, nagu tekstiredaktoris, veebibrauserid ja mängud, mitte baassüsteemi osade, nagu shell-id ja teegid, mille jaoks soovitatakse siiski distributsiooni enda paketihaldust. Aplikatsioonide paigaldamine on omamoodi kahe otsaga probleem, ühest küljest teeb Autopackage nende paigaldamise erinevatele süsteemidele võimalikult lihtsaks, teisalt võivad tekkida sõltuvusprobleemid, kui distributsiooni enda paketihaldus tahab kasutada teeke, mis on paigaldatud Autopackage-i poolt. Autopackage kasutab platvormisõltumatuse saavutamiseks APbuildi, et eemaldada mittevajaminevaid sõltuvusi, ristkompileerimist, et panna C++ programmid tööle erinevate g++ versioonidega ning parandab GLIBC versiooni sümboleid. Programmid, mis kasutavad Autopackage-it peavad olema samuti lihtsasti ümberpaigutatavad, mis tähendab, et neid saab paigaldada ükskõik kuhu failisüsteemis, ilma vajaduseta uuesti kompileerida. See teeb ka võimalikuks paigaldada Autopackage-i ilma administraatori õigusteta kasvõi oma kodukausta. Tasapisi on Autopackage hakanud populaarsust koguma, näiteks Gaim ja Inkscape on selle juba kasutusele võtnud, samamoodi pakub Freshmeat.net infolisajatele võimalust sisestada ka Autopackage-i paketi URL. 23

24 5 Veahaldus Veahaldus on süsteem, mis on spetsiaalselt kujundatud tarkvaraprobleemide haldamiseks. Tüüpiliselt kasutab veahaldussüsteem n-ö ticket tracking meetodit, kus iga veateade 2 salvestatakse süsteemi, määratakse prioriteet ja aeg spetsiaalse pileti kujul ning sellega tegeletakse, kuni see on lõplikult suletud. Seeläbi hoolitsetakse, et viga saaks alati parandatud ning kasutaja saaks vajadusel ka mingi tagasiside selle kohta. Tavaliselt lubab veahaldus kasutajatel kiiresti sisestada veateateid ja neid otsida, mõned lubavad lausa määrata spetsiaalse workflow, mis automatiseerib vea elutsükli. Veahaldus on vaadeldavatest vahenditest ainus, mis on seotud kogu tarkvaarenduse elutsükliga ning mida käsitletakse selletõttu tihti laiendatud kujul (Pilt 6). Pilt 6. Graafikult ilmneb selgelt veahalduse osatähtsus kogu tarkvaraarenduse jooksul. Kuna projektide olemuse tõttu on veahalduse vajadused erinevad, lubavad süsteemid määrata, mida vea kirjeldusse lisada võib. Julgelt võib väita, et veahaldus on infosüsteemi seisukohalt vägagi kriitilise tähtsusega, sest ilma korraliku veahalduselt on oht, et veateated kaovad infomürasse ning jäävad tähelepanuta või mingiks hetkeks koguneb neid nii palju, et puudub igasugune ülevaade parandatutest ja allesolevatest. 2 (märgiks siinkohal ära, et antud käsitluses on veateade seoses eestikeelse homonüümsusega inglisekeelses tähenduses bug report, mitte error) 24

25 Iga veateade tähendab tihti tunde ja võibolla isegi päevi lisatööd, selletõttu on see väga tähtis, et neid ka korralikult hallataks ja kaitstaks. Selletõttu peaks eahaldussüsteemiga töötades silmas pidama mõningaid olulisi punkte: 1. Tööta alati tarkvara kõige viimase versiooniga see võimaldab testijatel olla kindlad, et ei teatata vigadest, mis on juba parandatud ja samas võimaldab see ka uued vead kiiremini ära parandada, sest arendajatel on paremini meeles see, millega alles hiljaaegu tegeleti. 2. Kasuta tarkvara versioonide numereerimist alati kui võimalik, tasuks kirja panna, mis versioonis antud viga esines, mis versioonis see parandati ja mis versioonis tuvastati parandus, sest tihti ei piisa ainult lähtekoodi numeratsioonist, kuna testimine ei oma sellest alati ülevaadet. 3. Pane paika veateadete elutsükkel see võimaldab olla kindlad, et vead ei suletud enne, kui tegelikult oleks pidanud sulgema, näiteks võib see tähendada, et veateate lisaja saab ainult seda sulgeda või on mingi muu tõhusam süsteem kasutusel. Veateate elutsükkel võiks alati koosneda järgnevatest osadest: Uus, Määratud, Lahendatud, Testitud, Suletud. 4. Kasuta vea staatust et hoida veateate elutsükkel võimalikult lihtsalt mõistetavana, kasuta välja, kus on märgitud vea staatus. Võimalik väärtused võiksid olla: Parandatud, Parandamatu, Kordamatu, Kordus, Disainist ja Väline. 5. Ära kasuta koosolekuid veateadete üle arutlemiseks see võib kulutada palju töötunde, mida võiks kasutada veateadete parandamiseks. Kui selline koosolek on plaanis, siis ei tasuks vaielda veateadete sulgemise üle, sest see on testijate kvaliteedikontrollist möödaminemist, vaid kasuta aega veateade reprioritiseerimiseks, parandamise edasilükkamiseks või parandamatuks kuulutamiseks. 6. Halda feature request-e eraldi tüüpiliselt juhtub seda tihti, kuid neid peaks hallatama eraldi ja arutama nendele üle, sest muidu võivad need veateadetega segunedes ajada sassi tarkvara kvaliteedi mõõdetavuse. 7. Kirjelda, kuidas viga uuesti tekitada mida lihtsamini on viga uuesti tekitatav, seda kiiremini saab arendaja seda parandama asuda. 8. Pea arvet selle üle, kuidas vigu avastatakse arvepidamine aitab sul kõige paremini planeerida, kuidas raha testimise peale kulutada. Põhilised testimisviisid on: interaktiivne testimine, testiskripti kasutamine, unit testing, koodi ülevaatus, beetatestimine ja kasutajate teated. 9. Hoia vigade teatamine võimalikult lihtne ei ole mõtet teha veateatesse koguda rohkem infot, kui tegelikult vaja on. Kui vigade teatamine on liiga keeruline, siis hakkavad kasutajad 25

26 neid saatma pigem e-kirjaga või suusõnaliselt, mis halvab tõsiselt veahaldussüsteemi otstarbekuse. Iseenest ei ole need 9 punkti tingimata nõutavad veahalduse juures, kuid teevad selle kindlasti tükkmaad efektiivsemaks. Kui rääkida aga veateadetest, siis on korralikul veateatel alati need 3 omadust: sammud, kuidas see saada see, mida sa pidid nägema, ja see, mida sa tegelikult nägid. Ilma nendeta on vägagi raske viga tuvastada, veel vähem parandada. Kõige tüüpilisemad veahaldussüsteemid on Bugzilla, Flyspray, Mantis, Trac ja JIRA, kaks viimast neid hõlmavad ka ka arendusprojekti juhtimist ja muid tegevusi. Siinkohal on tähtis ära märkida ka fakt, et veahaldussüsteeme vaadeldes on raske esialgu hinnata täpseid nõudmisi, kuna protsessi kirjeldus ei ole veel piisavalt täpselt välja töötatud. Kuid kuna läbi veahaldussüsteemi hakkab esialgse kava kohaselt toimuma kogu AutomatWebi arendamine, peab süsteem eeldatavalt võimaldama peale tavapärase vigade haldamise ka kontrollida tervet arendusprojekti või siis vähemalt mingit osa sellest. 5.1 Bugzilla Bugzilla on üldotstarbeline veahaldustööriist, mis algupäraselt arendatud ja kasutatud Mozilla Foundationi poolt. Kuna Bugzilla on veebipõhine ning avatud lähtekoodiga tasuta tarkvara, kasutatakse seda ka mitmete avatud lähtekoodiga ning äriliste projekti juures, millest kuulsaimad on KDE, Linux kernel, GNOME, Apache, OpenOffice. Bugzilla vajab töötamiseks Apache veebiserverit, kas MySQL või PostgreSQL andmebaasi ja Perli. Tavaliselt võib veateateid sisestada igaüks ning määrata neid kindlale arendajale. Kuna Bugzilla vea märge on väga üldine, kasutab Mozilla seda ka näiteks feature request-ide haldamiseks. Bugzillal on päris palju võimalusi, suuresti tänu sellele, et seda koguaeg aktiivselt arendatakse, ning siinkohal tutvustaks mõnda nendest: Üks vägagi omapärane võimalus on raportite genereerimine: võimalus vigade andmebaasis hetkeseisust genereerida kas graafik või tabeli kujul esitlus. Oma olemuselt see väga palju otsingust ei erine, lisandunud on veel valikud esitluse meetodi kohta, näiteks graafiku genereerimisel saad määrata ära nii X, Y kui Z telgede omadused. Otsingu puhul saad valida nii lihtsa kui keerulise 26

27 otsing vahel, viimasel on terve lehekülg erinevaid omadusi ja valikuid, mille järgi leida. Bugzillal on olemas ka request-ide süsteem, et saad määrata ära teatavad lipud teisele arendajale ning siis tema siis peab nendele vastama, kas lubatud või tagasi lükatud. Selle tähtsus seisab asjaolus, et see võimaldab märkida arenduse elutsükleid, näiteks uue versiooni väljastamist, kus keegi peab kinnitama, et see on piisavalt küps. Samamoodi on seal olemas ka võimalus määrata ära n-ö insider kasutajad, kes saavad teistele omasugustele kommentaare jätta, mida teised kasutajad ei näe. Üks vägagi hea omadus on vigade parandamiseks kulunud aja jälgimine: kogu vea elutsükli ajal saab iga arendaja märkida, palju aega ta selle tegemiseks planeeris ja palju tegelikult kulus ning siis hiljem statistika selle kohta vaadata, mille põhjal saab hilisemaid planeerimisi täpsemalt teha. Vägagi omapärane asi on ka Sanity Check nimeline vahend, mis otsib pidevalt taustal andmebaasist kokkusobimatusi, mille ta siis eraldi koos sellega seotud vigadega välja toob. Samuti otsib ta ka meilide hulgast mingil põhjusel saatmata meile. 5.2 Mantis BugTracker Mantis on nagu Bugzillagi avatud lähtekoodiga veebipõhine veahaldussüsteem, mis erinevalt Bugzillast töötab PHP ja MySQL-iga. Mantis sai alguse ühest videomängu projektist, mille jaoks oli vaja veahaldust, kuid kõik sellel hetkel saadaolevad ei rahuldanud vajadusi ning selletõttu sai see kirjutatud ning hiljem ümber kirjutatud ning avalikustatud. Mantis ei ole nii laialt kasutusel kui Bugzilla, kuid kõige tuntumad kasutajad hetkel on Saab, phpbb ja WordPress. Väga omapärane on Mantises otsingute tegemine: selleks, et otsida, pead sa koostama spetsiaalse otsingufiltri, mis näitab vastavate filtrite järjekorra järgi tulemusi. Vägagi detailne on samas graafikute ja statistika vaade, mis annab vägagi hea ülevaate tegevusest. Iseenest vägagi tore vahend, kuid tundub, et kohati jääb Bugzillale omasest funktsionaalsusest ja kasutusmugavusest puudu. 5.3 Flyspray Flyspray on samamoodi avatud lähtekoodiga veebipõhine veahaldussüsteem. See loodi Psi projekti jaoks, sest ükski olemasolev ei vastanud nende vajadustele. Omades samu baasfunktsioone nagu Bugzilla, erineb see paljuski all olevas koodis: Flyspray kasutab PHP-d ja võib ADOdb abil kasutada paljusid erinevaid andmebaase ning omab Jabber-i tuge kasutajate teavitamisel. Kuigi Flyspray-l ei ole veel nii keerukaid omadusi nagu Bugzillal, on tema üks tugevusi lihtne paigaldamine ja kasutamine. Üks puudus (kui seda üldse puuduseks lugeda) on infomaterjali puudumine (ei ole selgitatud funktsioone ja võimalusi) ja dokumentatsiooni vähesus, kuid samas 27

28 see tundub olevat üks kõikide veahalduste omadusi. Flyspray kasutamine on tõesti lihtne, seal ei ole mingeid keerulisi menüüsid ja valikuid, välimus on lihtne HTML koos JavaScriptiga, mis peidab lisavalikud ning toob need vajadusel nähtavale. Esimese asjana antakse kohe ette tabel lahtiste bugidega, mida saab siis vastavalt sorteerida või otsida nende hulgast. Lihtsus ongi üks peapõhjusi, miks arendajad selle üle nii uhked on. Kahjuks ei õnnestunud mul katsetada töötavat näiteversiooni, selletõttu pidin funktsionaalsuse uurimiseks kasutama limiteeritud näidist. 5.4 JIRA JIRA erineb teistest veahaldustest eelkõige selletõttu, et ta koondab endas peale tavapärase veahalduse ka projektihalduse, keskendudes eelkõige meeskonnatöö tähtsusele. JIRA on ka vaadeldavatest ainus, mis on kommertstoode (standardlitsentsi hind algab 1,200 dollarist) ja ehitatud J2EE platvormile. JIRA-l on ka mitmeid kolmandate osapoolte tehtud lisasid, näiteks integratsioon Eclipse-iga. JIRA üks tugevusi seisnebki selles, et ta suudab peale vigade hallata kogu arendusprotsessi üldiselt. Mõned näited funktsionaalsusest: Ettevõtte äriprotsesside workflow ülekandmise võimalus; Võimalus jälgida muutusi, lisandeid jms; Üleüldine täistekstiotsing koos võimalusega otsing salvestada; Võimalus siduda väliste süsteemidega (nt e-post, RSS, Excel, XML, koodihaldus jpt) Web-Services tugi üle SOAP-i, XML-RPC ja REST-i; Lihtsasti mugandatav töölaud, saad välja tuua kõik, mis sinule vajalik. JIRA-t pakub ka väga laiaulatuslikku õiguste süsteemi, mis laseb määrata erinevad kasutajatasandiõigused ja vaated: juhtidel projekti staatust uuendada, arendajatel tegevusi hallata, analüütikutel äriprojektidel silma peal hoida, kasutajatoel probleemide kulgu jälgida, testijatel kiiresti probleemid kirja saada ilma, et topelt asju tehtaks, projektijuhtidel osade tähtsusi hinnata ja neid määrata. Võrreldes teiste vaatluse all olevate süsteemidega, on JIRA nendest kõvasti parema ning läbimõelduma ülesehitusega, suuresti tänu asjaolule, et tegemist on puhtalt kommertstootega, millel on vägagi nimekad kasutajad. Samas ei pakuta everything but the kitchen sink stiilis funktsionaalsusega üle, vaid jäetakse vaba voli kasutada seda, mida sul on vaja ning natuke enamatki. JIRA-t kasutavad hetkel üle 2600 organisatsiooni, teiste hulgas Adobe, Hewlett-Packard, Oracle, 28

29 Samsung, Siemens jpt. 5.5 Trac Trac on samamoodi nagu JIRA, teistest funktsionaalsem, sisaldades peale veahalduse ka projektihaldust ja -jälgimist, kuid erinevalt JIRA-st on Trac avatud lähtekoodiga ning tasuta saadaval. Trac on inspireeritud CVSTrac-i nimelisest tööriistast ja seda arendab Edgewall Software. Trac ühendab endas veebipõhiselt veahalduse, versioonihalduse ja Wiki ning täidab ka Subversioni veebiväljundi ülesannet ehk kokkuvõtteks peaks Trac täitma nii koodihalduse, koodi dokumentatsiooni ja veahalduse ülesannet. Trac on kirjutatud tervenisti Python-is. Trac on samamoodi nagu Bugzilla ja JIRA üsnagi laialt kasutusel, üks kuulsamaid on NASA Jet Propulsion Laboratory, kes kasutavat seda mitmete süva- ja lähikosmose projektide haldamiseks. Trac-i arendajate lähenemine on, et arendusvahendid peaksid võimalikult vähe segama arendaja tegutsemisvabandust ja toetama seda võimalikult palju. Selletõttu istub kogu süsteem Wiki ja vigade andmebaasi core-i peal, st kõik projektidesse puutuv (veateated, feature request-id, milestone-id, teated, versioonid jne) on omavahel seotud, lastes arendajal keskenduda kõige tähtsamale: tarkvara arendamisele. Trac peaks eeldatavalt ära katma nii projektijuhi, arendaja, testija kui analüütikute vajaduses, andes täieliku ülevaate projektis toimuvast. Trac-i arendajad lubavad ka, et Trac-i saab väga kergesti siduda olemasolevate süsteemidega. Kuna Trac on nagu paljud teisedki käsitluse all olevad süsteemid suuresti alles arenemisjärgus, puuduvad sealt nii mõnedki komponendid, mis selle kasutatavust laiendaksid, nagu e-postiga teavitamine, teiste andmebaaside tugi ja laiendatud otsing. Trac, nagu JIRA-gi, pürgib laiendama veahalduse kasutusvõimalusi ka teistesse sellega seotud tegevustesse, nagu projektihaldus ning uurimustöö raames vaadeldavad koodi ning dokumentatsiooni haldused. Trac-i lähenemine on vaadeldutest kõige lihtsam, tehes vigade lisamise ja haldamise läbi teiste tegevuse kiireks, kuid vaatamata funktsionaalsusele jätab kuidagi pooliku mulje, erinevad osad ei tundu esmapilgul piisavalt seotud olevat, et nende põhjal mingigi workflow saaks tekkida. Süsteemi üldidee ning eesmärk on vägagi innovaatiline ning haldamise kergendav, kuid näin nagu oleks lihtsalt kokku pandud osad, mis võiks kokku sobida, proovimata neid tegelikult koos toimima panna. Kohati häirib ka marginaalse, kuid mingis etapis vägagi tähtsa kasutajatasandite ning e-posti teel teavitamise võimalused. 5.6 AW BugTrack AW BugTrack sai oma alguse 2005 kevadel, kui tekkis vajadus selle järgi seoses AW visuaalse 29

30 arenduskeskkonna väljatöötamisega. AW-l on veahaldus olnud ka varem, kõige esimene versioon sisaldas seda, kuid kuna lähenemine polnud piisavalt hästi läbi mõeldud ja struktureeritud (kasutajad said vigu oma liidesest lisada, kuid haldus nende üle puudus), kogunes neid veateateid lõpuks tuhandeid, kuni otsustati see kinni panna. Uus veahaldus sai küll esimesed koodiread kirja, kuid seoses tööde suure mahuga jäi see kuni käesoleva aasta kevadeni seisma, kui antud kirjatüki autoril oli vaja kuskile süsteemist avastatud vead kirja panna nii, et need ei jää lihtsalt infoks kuskile. Aktiivne arendamine on toimunud 2006 jaanuarist alates, praegu ollakse vägagi lähedal selleni, et kasutuse saaks võtta, kuigi plaanitud funktsionaalsusest on olemas vaevalt 1/5. Üks põhjus, miks ei võetud kasutusele mõnda valmis süsteemi, on see, et omaenda loomine on küll ajamahukas ja keeruline, kuid vastab kõige paremini vajadustele, on sidus ja lihtne kasutada ning kasutatav ka muus otstarbes koos teiste vahenditega, kui ainult AutomatWebi arenduses (nt projektihalduses projektielutsükli täiendamisel). AW BugTracki kuvapildistus on ära toodud Lisas 3. Oma olemuselt AW BugTrack teistest sarnasest süsteemidest väga palju ei erine, samamoodi saab vea elutsüklit jälgida, sulgeda, avada, teateid saata jne., kuid erinevused tulevad sisse eelkõige AW spetsiifikast lähtudes: 1. Esimene neist on kindlasti vigade puu struktuuri kuvamine. Kuna AW failisüsteem on puukujuline, siis oli üks eeldusi ka see, et veateateid saaks kategooriatesse ja alamkategooriatesse jaotada ning üksteise alla panna, et tekiks ka visuaalne pilt järgnevustest. Üks küsimusi, mis tekib on ka see, et kui see puu struktuur väga sügavaks läheb, kuid olen üpriski kindel, et kasutajad ise hoolitsevad selle korrahoidmise eest. 2. Teine oluline lähenemine on AW BugTracki sidumine kirjakastiga, mille ülesanne on täpsem ülevaade liikuva e-posti osas, mis on seotud veahaldusega ning kõik kasutaja meilihaldus käiks ühe süsteemi kaudu. Üks spetsiifilisem vajadus on seotud ka AW arendamisega, kuna AW-l on spetsiaalne vigadelist, kuhu kõik AutomatWebid saadavad tekkivaid vigu ning sealt oleks võimalikult lihtne veateateid lisada süsteemi. 3. Kolmas lähenemine on veahalduse sidumine projekti ja kliendiga, mis annab esiteks võimaluse saada ülevaade konkreetse kliendiga seotud vigadest ning samas ka konkreetse projekti põhistest. Kliendiga sidumine võimaldab hinnata ka temale esitatavaid hooldusarveid ning projektipõhisus luua lisaväärtust seotuna projektielutsükliga projektihalduses. 4. Neljas lähenemine on AW BugTracki sidumine kasutaja kalendriga. Senimaani on kogu AW arendus käinud niimoodi, et tekitatakse arendaja kalendrisse sündmus, kus on kirjas kõik, 30

31 mis on konkreetse ülesande piires vaja teha. Tihti kasvab see nimekiri vägagi pikaks ja ei ole vägagi ülevaatlik, kuna peab ka kommentaare tegevuste kohta kirjutama ning ülesannete pikaajalisuse tõttu kaovad need tegevused kalendrivaatest ära, kuid jäävad tegevuste ribasse alles. Selletõttu on kõikidel arendajatel hästi palju tegemata toimetusi ja tühi kalendrivaade. Eesmärk on tekitada kalendrisse spetsiaalne vaade, kust näed veateateid lisaks tavapärasele, kus on kirjas ainult konkreetsel päeva/nädala/kuu tegevused, mis ei ole otseselt arendusega seotud. 5. Viies lähenemine on veateadete import. Kuna AW BugTrack peaks lõpuks koondama kogu AW-ga seotud arendustegevused, ei tule sinna ainult veateated. Tihti pannakse kogu projekti spetsifikatsioon kirja tavalisse tekstifaili ning sealt ridade kaupa sisestamine on ebaotstarbekas. Mis toob omakorda sisse vajaduse teha veateate piires ka väiksemaid n-ö alamvigu, mida saaks märkida tehtuks lihtsamalt, kui üldist veateadet ennast, et ei peaks iga pisi asja jaoks tegema eraldi teadet, vaid hallata neid grupeeritult. 31

32 6 Koodihaldus Informaatikas ja telekommunikatsioonis ei käsitleta eraldi terminit koodihaldus, vaid konfiguratsioonihaldus, millel on kaks tähendust: 1. Automaatse infosüsteemi turvaline seadete, tarkvara, riistvara, dokumentatsiooni, testide jms majandamine kogu arendamis- ja töötamisaja jooksul ehk SCM. Koodihaldus on üks osa sellest. 2. Keeruliste süsteemide arenemise kontroll ja adaptsioon ehk meetodid, kuidas hoida tarkvara arenemine kontrolli all, tagades piisav kvaliteedi ja kuluva aja suhted, jagunedes omakorda kaheks: vanem osa tegeleb tarkvara arendamise käigus tekkinud seadete eest, uuem hoolitseb nende seadete muutmise ja kasutamise eest. Meie vaatluse alla jääb esialgu vaid esimene lähenemine ning sellest just täpselt koodihalduse osa, teist osa sellest hõlmab eeldatavasti paketihaldus (Pilt 7). Pilt 7. Koodihalduse seotus erinevate elutsükli osadega. Kuna SCM on oma olemuselt vägagi keerukas ja kõikehõlmav lähenemine (kontrollides nii projekti, koodi, seadeid, elutsüklit kui kõike selle juurde kuuluvat), ei ole antud töö raames võimalik seda niivõrd laiaulatuslikult käsitleda, seega piirduma vaid kõige põhilisema ehk koodiga. Kuigi vahe üldise SCM-i ja koodihalduse vahel on pigem lähenemises, kui funktsionaalsuses, võib seda skeemi vaadata niipidi: SCM-i osa on versioonihaldus, mis omakorda spetsifitseerides moodustab koodihalduse. 32

33 Versioonihaldus on vahend ühe informatsioonikoguse erinevate versioonide haldamiseks. Seda kasutatakse tavaliselt inseneriteaduses ja tarkvaraarenduses, kus tihti muutuvad dokumendid, lähtekood vms kiiresti ning on vaja neid muutusi kuidagi hallata. Kõige lihtsam versioonihalduse viis on hallata neid muutusi käsitsi, hoides alles kõiki tehtud versioone, kuid see on vägagi ebaefektiivne, sest vajab palju aega, on infomahukas (kõik versioonid peavad alles olema), nõuab väga tugevat distsipliini arendajatelt ning võib seetõttu väga lihtsalt vigadeni viia. Põhimõtteliselt on võimalik automaatset versioonihaldust kasutada ükskõik millise informatsiooni haldamiseks, kuid praktikas on seni seda vaid tarkvaraarenduses kasutatud. Nüüd hakkavad ka CAD failide puhul üha enam kasutusele tulema automaatne versioonihaldus vana manuaalse asemel. Tarkvaraarenduses on vägagi tavaline, et korraga on kasutuses mitu tarkvara versiooni ning nendega tegelevad eri arendajad. Vead ja muud probleemid eksisteerivad tihti ainult ühes versioonis (sest arenduses asenduvad ühed vead tihti teistega), selletõttu on vaja näiteks debugger-il võrrelda erinevaid versioone, et tuvastada algallikas. Vahel on arenduses ka tarkvara mitu versiooni ning siis peab olema kuidagi võimalik parandada vigu niimoodi, et ei tehtaks topelttööd. Traditsiooniliselt on versioonihaldussüsteemid kasutanud tsentraliseeritud mudelit, kus kõik kontrollifunktsioonid on ühe koduserveri käes. Mõned aastad tagasi hakkasid süsteemid nagu TeamWare, BitKeeper ja GNU Arch kasutama jagatud mudelit, kus igal arendajal on oma kohalik baas ning muutused baasi vahel jagati eraldi sammuna. See lähenemine lubab arendajatel töötada võrguühenduseta ja annab ka täieliku kontrolli baasi üle, ilma et peaks õigusi tsentraliseeritult haldama. Üks juhtivaid jagatud versioonihalduse propageerijaid on Linus Torvalds, Linuxi kernel-i looja. Enamuses tarkvaraprojektides tegelevad mitmed arendajad ühe ja sama programmiosaga korraga. Kui kaks arendajat üritavad muuta ühte ja sama faili samal ajal, siis nad võivad väga kergesti kirjutada üle üksteise tööd. Suurem osa versioonihaldusi lahendavad selle probleemi ühel või teisel moel. Samas on see probleemiks ainult tsentraliseeritud lähenemise puhul, sest jagatud mudeli põhiidee ongi lubada mitme arendaja poolt korraga muutmist. Mõned süsteemid kasutavad probleemi lahendsamiseks failide lukustamist, kus üks pool ei tohi enne muuta, kui teine on enda muudatused üles pannud. Teised, näiteks CVS, lubavad korraga muutmist ning annavad võimaluse pärast muudatused ühendada. Selle üks võimalusi on ka reserveeritud muutmine, kus ei tohi muudatusi üles panna enne, kui teine on üles pannud, isegi kui mõlemad saavad muuta. Selle üks tagasilööke on asjaolu, et kui muudatuste tsükkel ei ole piisavalt kiire, siis võib üks kasutaja oma muudatuse lihtsalt süsteemi eirates käsitsi üles panna, mis võib viia veel suuremate probleemideni. Mõned süsteemid üritavad hallata muutmisõigusi vastavalt sellele, et mitu arendajat tohib muuta ja oma muudatusi lisada korraga, kuid nende järjekord sõltub õigustest 33

34 või on hallatav ühe arendaja poolt. Suurem osa versioonihaldustarkvaradest kasutab delta kompressiooni, mis hoiab alles ja tegeleb ainult kahe versiooni erinevustega, hoides kokku mahtu nii andmesidelt, kui andmehoiult. Mitmed arenenumad versioonihaldused pakuvad ka võimalust liidestamiseks, mida on ära kasutanud mitmed IDE-d, nagu Eclipse, MS Visual Studio, NetBeans IDE ja paljud teised. Versioonihaldustarkvarasid on päris palju, siinkohal toome ära tuntumad, kuid lähemalt käsitleme vaid antud seminaritöö piires olulisi: GNU Arch, üks omapärasemaid versioonihalduseid, erineb CVS-ist ja tema analoogidest selle poolest, et kasutab detsentraliseeritud hoidlat; CVS, RCS-i järglane; RCS, loodi asendama SCCS-i oma efektiivsema lähenemise tõttu; Subversion, loodud CVS-i asendama; SCCS, algupärane UNIXi SCM tööriist; TeamWare, loodud Sun Microsystemsi poolt ning põhiliselt nende enda poolt kasutuses; Perforce, kasutusel üle 3,600 organisatsiooni poolt, BitKeeperi suurimaid konkurente; BitKeeper, kasutati pikalt Linuxi kernel-i lähtekoodi haldamiseks, kuni arendaja ja Linuxi meeskonna vahel litsentsileping läbi sai ja Linuxi meeskond endale ise vahendi ehitas, arendatud sama inimese poolt, kes juhtis TeamWare-i arendamist ning on selletõttu mitmedki lähenemised sealt pärinud; Bazaar-NG, põhineb GNU Arch-il, kuigi praeguseks täiesti from scratch ümber kirjutatud, senimaani siiski veel varajases arengujärgus. Kuna AutomatWebi arendamine on algusest peale toimunud CVS-i kaasabil, on selle vajaduste osas juba mõningane eelteave ja pilt olemas, mis on samas piiratud väheste arendajate arvust tingitud väiksemate nõudmiste tõttu. Uus ja eeldatav vahend peaks peale praegustele nõudmistele parema vastamise olema võimeline ka jätkusuutlikuseks arendajate arvu kasvamisel suureks, ilma, et tekiks vajadus olulisel määral tegevusi omavahelise suhtlemise tasandil muuta. Ühest küljest peale ilmselgete puuduste on CVS-i nõrk külg ka väheste võrguprotokollide toetamine, mis väljendub tihti selles, et kasutaja serverisse paigaldatakse AutomatWeb üle FTP. Teisalt, kuna paketihaldus ja koodihaldus on AutomatWebi kontekstis hetkel vägagi seotud (praeguse seisuga AutomatWebi ei eelkompileerita), siis võib paketihalduse teke ära katta nii mõnegi koodihalduse praeguse puuduse, kuid ainult klientidega, mitte üldisemalt arendusega seotud tegevustes. 34

35 6.1 GNU Arch GNU Arch on versioonihaldusprogramm, mis vaatamata oma analoogiaga CVS-ile ja Subversioniga, kasutab nendest erinevalt jagatud meetodid muudatuste haldamiseks, kus iga muudatus on globaalselt identifitseeritav, tehes süsteemi väga skaleeruvaks ühendamaks ja muutmiseks täiesti erinevatest allikatest. GNU Archi detsentraliseeritud lähenemine tähendab, et read-only koopia algsest koodist tehakse vabalt loetavaks kõikidele kasutajatele, mida siis igaüks saab muuta ja oma muudatused üles laadida, ning projekti juhtarendaja ühendab muudatused käsitsi, mis omakorda jõuavad taas algsesse koopiasse. Tsentraliseeritud lähenemise simuleerimiseks saab peaarendaja lasta üle SSH, FTP või WebDAV-i kasutajad ligi ka peakoodile. GNU Arch kasutab sarnaselt Subversioniga atomaarsete muudatuste põhimõtet, kus muudatused ei jõustu enne, kui kogu muudatuste hulk on edukalt valideeritud. Samamoodi on kasutusel ka mitmed muud Subversioni lähenemisega sarnase võimalused: muudatused on projekti, mitte failipõhised; oksade tegemine on tehtud lihtsaks ja kiireks; ümbernimetamine toimub baasipõhiselt jpm. Lisaks on GNU Archil ka vägagi põhjalik muudatuste ühildaja, mis suudab kolmepoolselt muudatusi kokku panna (algbaas, esimene muutja, teine muutja) ning arvestab sealjuures ka kõikide muudatuse ajalooga. Samuti tehakse igast muudatuste hulgast krüptoräsi, mida on võimalik ka signeerida, et ei oleks võimalik lubamatut baasi muutmist. GNU Arch-i esialge versioon loodi Tom Lordi poolt, millest ka käsurealühend tla (Tom Lord's Arch). Alguses oli see vaid kogumik shelli skripte, mis olid mõeldud CVS-i asendama, kuid 2003 aastal sai see osaks GNU projektist ning augustis 2005 teates Tom Lord, et lahkub projektist (varsti peale 2.0 versiooni avaldamist) ning soovitas Canonical Ltd-i Bazaari projekti Archi asendajaks. Peale Bazaari, on Archist veel mitmeid eri versioone tehtud, nagu Arch ja hiljutine Bazaar-NG. Paljud suhtuvad vägagi kriitiliselt Arch-i, eelkõige selletõttu, et seda on vägagi raske õppida, kasutades suurel hulgal käskusid, mis võivad algajat kohutada. Mõningat kriitikat saab see ka asjaolu tõttu, et kasutab vägagi omapärast failinimede süsteemi (hüüdnimega FunkyFileNames), mis teeb selle portimise teistele operatsioonisüsteemidele vägagi raskeks. Peale raske kasutamise, on Arch-i puhul ka teada, et probleeme tekib ka suurte koodipuude haldamisega. Archi pooldajad samas väidavad, et tarkvara alles areneb ning suuremad probleemid saavad arenduse käigus kindlasti lahendatud, kuid kuna Archi uus 2.0 versioon (mis muideks on from scratch ümber kirjutatud, eemaldab failinimede probleemi ning ei kasuta üle 10 põhikäsu) ei paista veel kuskilt tulemas olevat, eelkõige selle tõttu, et eelmisest arendajast tekkinud seisaku tõttu. 35

36 6.2 Bazaar Esialgne Bazaar sai alguse GNU Arch protokolli implementatsioonina, mis väljastati oktoobris Canonical Ltd toetas selle arendamist kuni 2005 alguseni kui kogu toetus ja arendus läks üle uue ja parema disainiga versioonil väljatöötamiseks. Praegusel hetkel on esialgne Bazaar hüljatud. Veebruaris 2005 teatas Martin Pool, kes oli eelnevalt võrrelnud ja kirjeldanud mitmeid versioonihaldussüsteeme, et ta töötab Canonical Ltd ülesande peal teha hajutatud versioonihaldussüsteem, mida häkkerid armastaks kasutada. Avalik lehekülg ja meilinglist pandi üles aadressile ning projektile anti nimeks Bazaar-NG, kus NG tähistab uut põlvkonda (Next Generation), sest Bazaari nimeline projekti oli siis juba olemas. Augustis 2005 teatas Canonical Ltd, et kogu uue põlvkonna versioonihalduse arendus läheb üle Bazaar-NG toetuseks, mis väljastatakse Bazaar 2.0 nime all 2006 alguses Praegune Bazaar ei oma esimese Bazaariga ühist koodibaasi, neid ühendab peale nime veel mõned lähenemised ja algideed: teha Archilaadne versioonihaldustarkvara, kus ei ole vajadust keskse halduse jaoks ning säilitaks kõik varasemad versioonid ning muutused. 6.3 BitKeeper BitKeeper on versioonihaldustarkvara, mis tänu oma võimalustele, võistleb suurtegijatega nagu Rational ClearCase ja Perforce. BitKeeper on BitMover Inc-i toode ning mille arendamist juhib Larry McVoy, sama inimene, kes disainis Sun-i TeamWare-i, selletõttu jagab BitKeeper mitmeid TeamWare-i lähenemisi. BitKeeperi üks põhilisemaid müügiargumente on võimalus hajutatud arendusmeeskondadel hoida enda lokaalne baas ja keskne baas sünkroonis võimalikult lihtsalt. BitKeeper on kinnise lähtekoodiga tarkvara, mida müüakse või liisitakse osana kasutajatoe paketist korporatsioonidele. Täpne hind sõltub kliendi vajadustest, kuid keskmine kulu ühe arendaja kohta on keskmiselt üle 1000 dollari, tehes selle kättesaadavaks vaid suurimatele. BitMover pakkus tasuta kasutamist mitmetele avatud lähtekoodiga ja tasuta tarkvaradele, millest kõige kuulsam ja samas ka vastuolulisem on Linuxi kerneli lähtekood. Ühiskondliku versiooni leping lubas BitKeeperit kasutada arenduses tasuta vaid juhul, kui kasutajad ei arenda samal ajal konkureerivaid tooteid (nt CVS, GNU Arch, Subversion vms) BitKeeperi kasutamise ajal pluss üks aasta. Sama leping nõudis ka, et mingi osa koodimuutuste metainfost säilitataks ka BitMoveri serverites, mis tegi võimatuks projektide arendamise, millest BitMover ei olnud teadlik. Otsus 2002 aastal võtta Linuxi kerneli arendamisel kasutusel BitKeeper, tekkis vägagi vastakaid arvamusi. GNU projekti algataja Richard Stallman väljendas oma muret ärilise tarkvara kasutamisest vaba tarkvara tegemiseks. Samal ajal kui Linus Torvalds ja teised põhitegijad võtsid 36

37 BitKeeperi kasutusse, keeldusid mõned häälekalt (nagu Linuxi veteran Alan Cox) ning kommenteerid BitKeeperi litsentsitingimusi, millest võis välja lugeda, et projekti juhtimise võib üle võtta mõni ärilise suunitlusega arendaja. Nende probleemide kõrvaldamiseks lisas BitMover gateway-d, mis lubasid kasutada limiteeritult CVS-i ja Subversionit BitKeeperi serveritega. Isegi nende täiendustega tekkisid vahel pikad sõnasõjad Linuxi kerneli meilinglistis, milles võttis tihti osa ka Larry McVoy, kes on ise ka Linuxi arendaja. Aprillis 2005 teatas BitMover, et lõpetab tasuta BitKeeperi versiooni pakkumise, eelkõige vaidluste tõttu Linus Torvaldsi tööandja, ODSL-iga (Open Source Development Labs), mille üks töötaja Andrew Tridgell üritas BitKeeperit lahti muukida, et saaks arendada tasuta tarkvara, mis seda asendaks. Varsti peale seda avaldust teatas Linus git projekti algatamisest, mis pidi asendama BitKeeperit Linuxi kerneli versioonihalduses. Ametlik tugi lõppes 1. juulil 2005 ja kasutajad pidid kas ostma tasuta tarkvara või minema üle mingile muule vahendile. Ka hiljem on BitMover vägagi häälekalt võidelnud igasuguste projektide vastu, mis võivad BitKeeperit ohustada: oktoobris 2005 tegi McVoy ettekirjutuse ühele kliendile, kelle töötaja arendas GPL lähtekoodiga versioonihaldussüsteemi Mercurial, et too lõpetaks sellise tegevuse, mida viimane konfliktide vältimiseks tegigi. 6.4 CVS Concurrent Versions System (ehk rohkem tuntud kui CVS), on üks kuulsamaid versioonihaldussüsteeme, mida kasutatakse väga palju avatud lähtekoodiga projektides. CVS on tüüpiline näide klient-server ehk tsentraliseeritud lähenemisest: server haldab projekti versioone ja nende ajalugu ning klient ühenda serverisse, et tirida endale koopia, muuta enda koopiat ning muutused serverisse tagasi tõsta. Tüüpiliselt toimub üle LAN-i või Interneti, kuid klient ja server võivad asuda ka füüsiliselt samas masinas, kui CVS-ile on niimoodi määratud. CVS server jookseb tüüpiliselt Unixipõhisel süsteemil (kuigi on olemas Windows NT CVS-i versioon olemas), samas kui kliendid on kõigi suuremate operatsioonisüsteemide jaoks olemas. Mitu klienti võib muuta ja täiendada ühte koopiat samaaegselt, hiljem kui nad oma muutused serverisse tagastavad, üritab server need kokku panna, kui see ebaõnnestub, siis peab kasutaja käsitsi vea parandama. Samas kui see õnnestub, jäetakse failisüsteemi kasutajakommentaariga märge muutuste kohta. Kasutajad saavad samuti võrrelda ühe faili erinevaid versioone, küsida tervet muutuste ajalugu või küsida ajaloolist koopiat süsteemist konkreetse kuupäeva või versiooninumbriga. Mitmed avatud lähtekoodiga süsteemid võimaldavad kasutajatele anonüümset ligipääsu, mille pioneeriks on 37

38 OpenBSD. Anonüümne CVS tähendab, et CVS-i koopia tõmbamiseks on üks kasutaja, millel pole vaja parooli sisestada, kuid serverisse lisamiseks peab olema personaalne kasutaja. CVS võimaldab hallata ka mitmeid sama projekti harusid, kus näiteks ühte haru kasutatakse täisversioonide ja veaparanduste jaoks ning teist arenduste jaoks. CVS-il on oma algupärast tulenevalt ka mõningad puudused: faile CVS-i baasis ei saa ümber nimetada, need tuleb eemaldada ja uuesti lisada; CVS ei võimalda käsitleda katalooge projekti osana, kõik ümbernimetamised-kustutamised peab tegema failikaupa; piiratud Unicode-i tugi jpm. Mitmed CVS-i endised arendajad on üle läinud Subversioni arendamisele, mille esimene versioon väljastati 2004, ning pidi parandama mitmed CVS puudused. Samas on väljastatud ka mitmed tööriistad, mis tegelevad CVS-i puudustega, nagu WANdisco for CVS, mis toob mängu atomaarsed muudatused, rollipõhised kasutajaõigused ja mitme baasi toe. CVS arendati algselt paari shelli skriptina RCS-i põhjale ühe Amsterdami tudengi, Dick Grune, poolt 1984, kellel oli vaja ühe oma tarkvaraprojekti jaoks vahendit, kus inimesed saaksid eri aegadel faile muuta ja üldisesse baasi lisada. Kood avalikustati juunis 1986 Usenetis ning asjaolud hakkasid sealtpeale hargnema, kuni 1989 hakati välja töötama CVS-i praegust versiooni, mis üsna pea avaldati GPL litsentsi all. Praegu haldavad CVS grupp vabatahtlikke, projektist on eraldunud Windows NT versioon CVSNT eraldi projektiks, mille arendamine on aktiivsem ning arendajad lausa tõstavad funktsionaalsust tagasi ka Unix platvormile. 6.5 Subversion Subversion on avatud lähtekoodiga versioonihaldussüsteem, vahel tuntud ka kui svn oma käsurealühendi tõttu. Subversion on spetsiaalselt disainitud olemaks moodne CVS-i asendaja ning jagab sellega mõningaid peaarendajaid. Subversionil on päris palju eeliseid CVS-i ees: atomaarsed muudatused: kui muudatus peatatakse, ei lõhuta sellega baasi; ümbernimetamine/kopeerimine/eemaldamine säilitab täieliku ajaloo, st kõike on võimalik alati 38

39 taastada; täielik binaarsete failide tugi; kataloogide versioonimine: tervet kataloogipuud võib ümber tõsta/kopeerida ning sellest säilib terve tegevuste ajalugu; oksade tekitamine on ajast sõltumatu; andmevahetus on vägagi optimiseeritud. Erinevused CVS-iga on just eelkõige kasutusmugavuse ja võimaluste osas. Näiteks võimaldab Subversion kasutada mitmeid erinevaid andmebaase koodibaasi ja sellega seonduva info hoidmiseks, samuti on tal mitmeid erinevaid liideseid, nagu WebDAV tugi ja üle kümne graafilise kliendi (tuntumad nendest TortoiseSVN Windowsi jaoks ja kdesvn Linuxi jaoks). Subversionit kasutatakse ka mitme vabavaraprojekti osana: Trac projektijuhtimisvara, mis ühendab endas Subversioni, sündmustehalduse ja Wiki ühtsesse veebipõhisesse süsteemi. Subclipse projekt, mis ühendab endas Subversioni ja Eclipse-i. JavaSVN, mis on 100% Java-põhine Subversioni klient CVS-i kõige suurem viga oligi just selles, et see ei võimaldanud käsitleda koodi ühtse süsteemina, vaid käsitles iga faili eraldi objektina, seevastu Subversionis on versiooninumbrid muutuste järgi, mitte faili versioonide järgi, st. koodi käsitletakse ühtse puuna, samamoodi ei pea versiooninumbritega uuesti ühest peale hakkama kui fail tõstetakse mujale, nagu CVS-i puhul, vaid säilitatakse olemasolev isegi kustutamise puhul. Subversioni üks põhilisemaid puudusi hetkel võrreldes CVS-iga on asjaolu, et tegemist on alpha tarkvaraga: see on piisavalt kõlblik üldiseks kasutamiseks, aga samas käib pidevalt aktiivne arendamine, funktsionaalsuse lõpetamine ja veaparandus. Selletõttu ei ole see ka veel hakanud väga CVS-i positsiooni kõigutama, aga juba ilmuvad esimesed projektid, mille puhul kasutatakse Subversioni võimsamat funktsionaalsust, seega on CVS-i asendamine vaid aja küsimus. 39

40 7 Koodi dokumentatsioon Enne kui uurime konkreetselt mingit dokumenteerimisvõimalust, määratleme ära, et meile pakuvad huvi vaid automaatse dokumentatsiooni genereerijad, sest kiire ja lihtsa muudetavuse tõttu on PHP puhul muud variandid välistatud: keegi ei suudaks vähegi suurema projekti puhul käsitsi tehtud dokumentatsiooni kaasaegse hoida ja samas ei ole selline detailsusaste ka vägagi otstarbekas. Konkreetsemalt huvitab meid automaatse dokumentatsiooni puhul just API dokumenteerimine, kuna sellega puutuvad programmeerijad mooduleid tehes kõige rohkem kokku, kuid samas vaatame ka core'i ja mooduli sisest dokumenteerimist. API dokumentatsioon seletab lahti API (Application Programming Interface) nii, et teised programmeerijad saaks projekti arendamist jätkata ilma, et peaks ise selle koodi uurima. Tüüpiliselt avaldatakse API dokumentatsioon elektroonilises formaadis, nagu HTML, PostScript või RTF. Paljudel IDE-del on ka API dokumentatsioon osana süsteemist. Dokumentatsiooni genereerimiseks on tehtud palju automaatseid tööriistu, mis kõik kasutavad mingit spetsiaalselt kommentaarikoodi, et see oleks loetav nii dokumentatsiooni sirvides kui ka koodi niisama lugedes. Kui kirjutatakse tarkvara, on kood ainuüksi ebapiisav, peab olema ka mingi tekst, mis seletaks ka selle eeldatava töötamise erinevaid aspekte. Dokumentatsioon võib kõikuda üldisest süsteemiideest, kuni API ja isegi kasutatavate muutujanimede ja algoritmide tasemele (Pilt 8). Pilt 8. Koodi dokumentatsiooni kasutamine erinevate elutsükli osade juures. Programmeerijatele istub eriti just automaatse dokumentatsiooni genereerimine, sest see võetakse 40

41 otse lähtekoodist, mille tõttu saab seda vaadata otse kirjutamise ajal ning samas ka koodiredaktoriga otse dokumenteerida, mis teeb koodi ajakohasena hoidmise palju lihtsamaks. 7.1 Javadoc Javadoc on automaatne dokumentatsiooni generaator Sun Microsystemsi poolt genereerimaks API dokumentatsiooni Java lähtekoodist HTML-i. Javadoc on de facto standard Java dokumenteerimiseks ning paljud IDE-d genereerivad Javadoci HTML-i automaatselt. Javadoc-i formaadis on ka Java Development Kitide API-d. Javadoc oli esimene, kes võttis kasutusele dokumenteerimise formaadi, mida kasutavad praegu pea kõik vastavad vahendid: dokumentatsioon algab /** ja lõppeb */ märgiga ning kõik märgendid märgiga. Lisas 1 on ära toodud Javadoci kõige põhilisemad märgendid ja kasutusnäidis. Javadoc-is sisaldub ka API doclet-ide ja taglet-ide genereerimiseks, mis võimaldavad analüüsida Java aplikatsiooni struktuuri analüüsida. Üks näide sellest on JDiffi nimeline vidin, mis raporteerib muutusi kahe versiooni vahel. JDiff on oma olemuselt Javadoci doclet, mis genereerib HTML raporti kõigist pakettidest, klassidest, konstruktoritest, meetoditest ja väljadest, mis on kustutatud või muudetud mingil moel, kaasa arvatud nende dokumentatsioon. See on vägagi tõhus vahend jälgimaks, mis on konkreetselt muutunud kahe versiooni puhul. Võrreldakse ainult API-t, mitte seda, mida lähtekood teeb, kui see käima pannakse. Javadoci üldine süntaks on toodud ära Lisas phpdocumentor Praegusel hetkel (2006 veebruar) on phpdocumentor de-facto standard dokumendigeneraator PHP jaoks, mille PHP arendajad on lisanud ka PEAR-i koodibaasi. Infot selle kohta, kui laialt see tegelikult kasutusel on, ei ole praegu võimalik kuskilt leida, kuid teades, kui populaarne ja tuntud on PEAR, ei saa see olla kindlasti väike. phpdocumentorist on kirjutamise hetkel väljas versioon 1.3.0RC4, mis on viimane veaparandusväljalase enne 2.x versioone. phpdocumentor võimaldab peale tavalise 11 erineva HTML formaadi teksti väljastada ka CHM, PDF, XML DocBook formaadis ja võimaldab teha ka PHPXref koodi esiletõstu ja linkimist, samuti lugeda JavaDoc formaati ning teeb isegi võimalikuks mitme erineva otstarbega dokumentatsiooni koostamise samast algmaterjalist. PhpDocumentorit võib kasutada nii veebist kui ka käsurealt. Töö põhimõte on sama, mis teistel dokumenteerijatel, et kirjeldused kirjutatakse PHP koodis C++ stiilis kommentaaride vahele, kus iga rea alguses on tärn. phpdocumentor võimaldab kasutada ka malle, st määrata ära mingid eeskirjad, mille järgi dokumentatsiooni tehakse ning panna see elementidele külge. Näide: 41

42 private string */ $_var1 = esimene ; $_var2 = teine ; /**#@-*/ teeb sama, mis: /** private string */ $_var1 = esimene; /** private string */ $_var2 = teine ; Mallide põhieelis ongi just pikkade sarnaste elementide dokumenteerimise lihtsustamine. Hetkel on phpdocumentoril umbes 30 erineva märgendit, millest 20 on aktiivses kasutuses; saab kasutada nii lehe-, paketi- kui klassipõhist dokumenteerimist, paketipõhine on kõige tüüpilisem. Dokumentatsiooni genereerides üritab ta kaasata ka include ja require käskudest tulevad dokumentatsioonid. Üks vägagi huvipakkuv võimalus on ka õpetuste tegemine. Üldidee on see, et tavapärasel moel õpetusi dokumentatsiooni kirjutades muutuvad need tihti väga pikaks (õpetused võivad olla nii rida pikad), tehes koodi lugemise ja muutmise vägagi ebamugavaks. Selletõttu loodi spetsiaalne inline märgendite kogu, mille abil saab väljaspool asuvatest failidest kirjeldusi lisada. Protsess toimub enamvähem samamoodi nagu tavalise dokumenteerimise puhul, jagunedes kolmeks: paketi-, klassi- ja funktsioonipõhiseks. phpdocumentori üks eeliseid on ka asjaolu, et võimaldab käivitamist ja töötlemist nii läbi veebiserveri kui käsurealt (viimane on soovitatav variant). 7.3 PHPDoc PHPDoc on Javadoc-i analoog PHP maailmas, olles ise samamoodi PHP-s kirjutatud. See pakub võimalust genereerida API dokumentatsiooni objektorienteeritud ja protseduursest koodist kindlate märgendite abil dokumentatsiooni. PHPDoc on avatud lähtekoodiga projekt ja igaüks võib seda vabalt laiendada ja kasutada, seni ei ole kuulda, et keegi oleks väga sellest võimalusest kinni haaranud. PHPDoci omapära on see, et ta suudab koostada ka n-ö toorest dokumentatsiooni ehk töötleb 42

43 kõiki kommentaare, olenemata sellest, kas see on dokumentatsioonimärge või mitte. PHPDoci otsest parserit kui sellist ei eksisteerinud ka kõige viimases versioonis, selle eesmärk oli tagasiühilduvus PHP 3. versiooniga. Kõige värskem versioon sellest on 1.0 beeta, mis väljastati aastal. Kuna Javast tulnud lähenemine ei mänginud PHP puhul eriti välja (eelkõige parseri aegluse ja huvipuuduse tõttu), asendati see üsna pea phpdocumentoriga. 7.4 AW DocGen AW DocGen kui selline sai alguse suvel 2004, kui seoses AW programmeerimiskoolitusega tekkis vajadus üldisema dokumentatsiooni jaoks. Antud koolituse jaoks sai valmis põhiliselt kasutusdokumentatsioon, kuid kuna uutele programmeerijatele oli vaja ka midagi konkreetsemat API dokumentatsioonina, siis sai kevadel 2005 ka vastavad juhendid ja eeskirjad välja töötatud. Üldisemas plaanis järgib AW DocGen Javadoci süntaksit, kuid on mugandatud ja lihtsustatud. Täielik süntaks on toodud ära Lisas 2 koos kuvapildistusega. AW DocGeni eripära võrreldes Javadoci ja analoogidega on see, et see kasutab sama ORB kirjeldust, millega hallatakse API kasutusõigusi. Selline lähenemine säästab küll päris korralikult aega dokumenteerimisel, kuid tekitab kohati päris palju segadust, kuna asjad ei ühti alati üks-ühele. 7.5 PHPXref PHPXref on arendustöövahend, mis on mõeldud suurte PHP-põhiste tarkvaraprojektide jaoks, tehes lihtsaks ja kiireks lähtekoodi ja selle dokumentatsiooni sirvimise. Töötab see põhimõtte järgi, et loeb sisse projekti kataloogi ja tõlgib failid ümber ristviidatud HTML-iks, tehes samal ajal koodi kommentaarid dokumentatsiooniks selle kõrvale, mille tulemusel valmib üks kogus tavalise HTML faile, mis ei vaja kasutamiseks midagi peale tavalise veebibrauseri. PHPXref-il on väga väikesed nõudmised keskkonna osas, vajades vaid töötavat Perli koopiat ning paari rea muutmist konfiguratsioonifailis. PHPXref on omapärane just selles mõttes, et ta ei ole otseselt koodidokumentatsiooni generaator, vaid ristviidetega koodibrauser, mis võimaldab luua ka hädapärast dokumentatsiooni sinna kõrvale. PHPXref kasvas välja arendaja vajadusest mingi mooduse järgi, kuidas hallata linux.com kümneid tuhandeid koodiridu, mida muutsid paljud erinevad arendajad ning dokumentatsiooni oli mitmetes erinevates formaatides ning pidi koodis funktsioone taga ajama. Ajapikku osutus see üpriski kasulikuks tööriistaks mitmete teiste projektide juures ka ning selle arendamist jätkati. Viimane versioon PHPXref-ist on 0.6, mis anti välja 2004 oktoobris ning sisaldas ennast PHP5 põhilist tuge ja mõningaid veaparandusi. Minule mitteteadaolevatel põhjustel jäi arendus peale seda 43

44 soiku, suuresti võibolla põhjusel, et seda arendati ühe inimese poolt. 44

45 8 Kokkuvõte Kui lähtuda kokkuvõtte kirjutamisel AutomatWebi praegusel hektel olemasolevast, on puudu ainult paketihaldus, mille arendamine kerkib loodetavasti päevakorda lähima aasta jooksul. Samas ei ole antud uurimustöö eesmärk võrrelda olemasolevat teiste võimalikega, vaid laiendada olemasolevat käsitlust, üritades leida parimat võimalikku nii jätkusuutlikkuse, lihtsuse kui ka vajaduste täitmise osas. AutomatWebi arenduspoliitika ei nõua ilmtingimata kõige isetegemist, kuid kuna tegemist on siiski arendusplatvormiga, siis miks mitte selle potenetsiaali võimalikult laialdaselt ära kasutada, proovides kätt nii nendega vahenditega, mida on vaja AutomatWebi enda arendamiseks? Kui konkreetsemalt lahata vaadeldud tööriistu, siis ilmneb selgelt kolm tendentsi: laiade kasutusvõimalustega, kuid tavapärasest teistesse oludesse kohandamatu (suurem osa paketihaldusi); konkreetse kasutusvaldkonnaga mingi kindla ülesande võimalikult hästi tegemiseks (suurem osa vaadeldud vahendeid); võimalikult laia kasutusvaldkonnaga, olemata sealjuures liiga üldine (näidetena veahaldusest Trac ja JIRA, dokumenteerimisest PHPXref ja phpdocumentor). Võib tekkida ka küsimus, miks on jäänud käsitlusest välja IDE-d, kuigi need pakuvad tihti kõike seda funktsionaalsust koos, siis on põhjuseks asjaolu, et just IDE kasutusvõimaluste suuruse tõttu nõuab nende käsitlemine suuremat mahtu, kui antud töö võimaldab, IDE kasutuselvõtmine on hetkel PHP kontekstis täiesti individuaalne (isiklikult ei ole ma veel kohanud IDE-t, mis teeks PHP arendamise kiiremaks ja efektiivsemaks kui tavaline tekstiredaktor) ning on liiga üldine konkreetsete vajaduste jaoks. Kui konkreetsemalt paketihaldusest rääkida, siis on suurem osa saadaolevaid vahendeid mõeldud konkreetse platvormi jaoks konkreetsete ülesannete jaoks (apt ja RPM Linuxile, ports FreeBSD-le, Windows Installer Windowsile jne). Kindlasti on tingitud see ka asjaolust, et tavaliselt on ainult operatsioonisüsteemid ainsad, mis vajavad sellises mastaabis lahendusi. Kuna isiklikult olen Linuxi osas väga suur Debiani fanaatik, siis istub mulle dpkg robustne kuid väga lihtne lähenemine kõige rohkem, kuid on ilmselge, et tervenisti sellisel kujul paketihalduse tekitamine on mõeldamatu, kuigi pakettide sõltuvussuhete haldamisel on dpkg pakutud lähenemisest kindlasti väga palju kasu. Omapärase lähenemisena on antud kontekstis Autopackage, mis ei oma kahuks veel piisavalt kõlapinda, et mingitpidigi üldkasutatava lahendusena käsitleda, kuid iseenesest idee, et kogu 45

46 paketide haldamine peaks olema võimalikult platvormist sõltumatu, toob lausa rõõmupisara silma. Suure tõenäosusega ei ole ükski paketihaldussüsteem piisavalt silma paistev, et võtta kõige täiega üle, kuid kuna tulevane vahend kirjutatakse nagunii konkreetseid vajadusi arvestades, peaks see olema võimalikult seotud koodihaldusega, ühendades samas paketihalduses nii portsi konfigureeritavust, dpkg sõltuvuste haldamise mudelit ning Autopackage-i lihtsat paigaldatavust. Koodi dokumentatsiooni kohapealt on AW DocGen pikaealisuse ja läbimõelduse tõttu täitnud küllaltki hästi oma eesmärgi. Kõige huvipakkuvam käsitlustest on PHPXrefi lähenemine, kus moodustub teatav võrgustik koodi seostest, mille ülekandmine AW DocGeni vähendaks märgatavalt lisadokumentatsiooni vajadusi. Vähetähtis ei ole siinkohal ka phpdocumentoris oleva välise linkimise võimalus, mida saaks koostöös AutomatWebi support keskkonna või mingi muu välise allika abil kasutada mitmepidiseks dokumenteerimiseks, kus kasutajaliidese dokumenteerija aitab ka koodi dokumenteerida ja vastupidi. Vaadeldavatest vahenditest on Javadoc seni standard, millel põhinevad kõik ülejäänud lahendused, kuid samas selle PHP kloon, PHPDoc, ei jõudnudki esialgsest beetast kaugemale, kuid aitas kaasa phpdocumentori sünnile. Koodihaldus on vaadeldavatest vast kõige laiaulatuslikumalt käsitletud, kuid samas teistest spetsiifilisema kasutusvaldkonnaga. Antud tööd kirjutades suutsin leida üle 40 erineva koodihalduse, millest suurem osa on ühe või teise suurema kloonid, kuid samas ei ole peale CVS-i ja tasuliste vahendite, nagu BitKeeper jms saavutanud ükski arenduseks vajalikku küpsust. BitKeeper oleks vast kõige sobilikum AW arendamiseks, kui silmas pidada jätkusuutlikkust, kuid segane litsentsipoliitika ning kõrge hind teevad selle kättesaadavaks vaid suurtele. Arch oli üks esimesi pioneere, kes üritas seda sama lähenemist tuua ka tasuta tarkvara konteksti, kuid on nüüdseks peaaegu surnud. Selle asendamiseks on küll loodud Bazaar, kuid hetkel on see veel küllaltki kaugel igasugusest tõsise arendustegevuse jaoks sobivusest, võibolla paari aasta pärast on olukord juba teine. Seni on Subversion ainus, mis sobiks AW konteksti võimalikult väheste muudatustega (põlvnedes kasutusel olevast CVS-ist), mille puhul ei tohiks vägagi segavaks saada ka osa pikemas perspektiivis vajaliku funktsionaalsuse puudumine. Veahaldus on käsitluse all olevates teemadest vast kõige laiem, hõlmates tervet tarkvaraarendusprotsessi. Siinkohal oli näha selgelt kahte lähenemist: tehes veahaldamise võimalikult hästi või lihtsalt hallatud tegevuseks või integreerida see põhjalikult muu arendustegevusega. Kuna AW arendamine on veel hetkel siiski väikese mastaabiga, siis sobib kõige paremini see jagatud mudel, kus sa saad nii vigu hallata projekti ühe osana. JIRA tundub 46

47 funktsionaalsust vaadates vast kõige edumeelsem, kuid esialgu tundub, et nii põhjalik süsteem ei ole hetkel veel päevakorras, tuues esialgu endaga kaasa rohkem haldamise probleeme, kui ta lahendab. Kõige rohkem meeldis mulle vaadeldutest Trac-i veidike kaootiline lähenemine, kus seotakse nii Wiki, koodihaldus kui veahaldus. Trac ise vahendina kasutusele võtta oleks vägagi ahvatlev, kuid kuna AW-l on juba arenduses vahend vigade haldamiseks, Wiki on lähima paari kuu arenduskavades ning Subversioni kasutamine on plaanis (mitte ainult lähtudes antud töö järeldustest), siis oleks kõige parem lahendus võtta üle Trac-i lähenemine, sobitades seda AutomatWebi konteksti, miksmitte luues seeläbi peale AW arenduses sobiva võimsa vahendi ka tööriist teistele tarkvaraarendajatele. Kui isiklikust seisukohast lähtuda, siis sai antud töö raames vägagi selge pildi nii antud valdkondade spetsiifikat, nende probleemidest kui ka üldpildina nende tegevuste koosmõjust tarkvarategevusele, mille põhjal väidan, et see täitis oma püstitatud eesmärgi. Kui nüüd korraks veel AutomatWebi juurde tagasi pöörduda, siis AutomatWeb on tarkvara seisukohalt vägagi omapärane nähe nii Eesti kui ka teadolevalt maailma mastaabis, mis ehk seletab ka selle, miks on senimaani AutomatWebist valminud viis uurimustööd kaasaarvatud käesolevaga. Iseenest mängib mingit rolli ka nende isikute tihedam seotus AutomatWebiga kui ka platvormi suurus, mis ei lase teemade puudusel tekkida. Loodetavasti on antud töö tulemus veidigi abiks ka PHP arenduses üldiselt, mitte ainult AutomatWebi seisukohalt. 47

48 9 Kasutatud infoallikad 1. Wikipedia ja Struktuur Meedia ja AutomatWebi tehniline tutvustus, 2006, Ahto Reinaru. 4. Software Testing Fundamentals: Methods and Metrics - Marnie L. Hutchenson, John Wiley & Sons PHPXref 6. PHPDoc 7. JIRA 8. Bugzilla 9. Subversion: a better CVS Subversion Version Control With Subversion phpdocumentor Guide to Creating Fantastic Documentation umentor.pkg.html FreeBSD puhul on lähtekoodipakett port ja kompileeritud pakett package, kuid käsitluse lihtsustamiseks ei ole seda eristust tekstis üle kantud. 48

49 10 Lisad 10.1 Lisa 1: Javadoci levinumad Kirjeldus Arendaja nimi Märgib meetodi vananenuks. Mõned IDE-d väljastavad selliselt märgitud funktsioone kasutades hoiatuse. Dokumenteerib erindi, mille meetod väljastab Defineerib funktsiooni parameetri Dokumenteerib meetod poolt tagastatava sünonüüm Dokumenteerib seose teise klassi või meetodiga Märgib, millal antud meetod klassi sünonüüm Märgib klassi või meetodi versiooni Järgnevalt ka Javadoci kasutuse lühike näide: /** * Valideerib malekäigu Jaan Pill kustfail asukoha fail kustv2li asukoha aste kuhufail sihtvälja fail kuhuv2li sihtvälja aste tagastab true, kui käik lubatud ja false, kui ei ole */ boolean onlubatudk2ik(int kustfail, int kustv2li, int kuhufail, int kuhuv2li) {... } 10.2 Lisa 2: AW DocGeni praegune süntaks ja kuvapildistus Samamoodi nagu teistegi automaatsedokumenteerimise tööriistade juures, nõuab AW DocGen, et kommentaariblokk asuks vahetult enne dokumenteerivat funktsiooni. Kõiki parameetreid võib ümbritseda jutumärkidega, kuid ei pea tingimata, juhul kui need ei sisalda tühikuid. Märgendid võivad olla ükskõik millises järjekorras ning mitmerealiste märgendite lõppu tähistab järgmise märgendi algus. AW DocGeni süntaks: /** ühe realine name=orb_name params=[name pos] default="0" nologin="1" api=1 all_args=1 49

50 caption="foo" foo [optional required] type=[int var oid object string float] acl=[view;edit;add] mitmerealine tekst mitmerealine tekst mitmerealine tekst mitmerealine tekst jätkatud ja ka koodinäited **/ üldine info funktsiooni kohta name meetodi nimi; kui see on defineeritud, siis käsitletakse seda ORB-i meetodina. params võib olla kas name või pos. name - argumendid antakse sisse massiivina ning on seetõttu eristatavad nime järgi, pos - argumendid sisestatakse nimekirja põhjal järjestatuna. default 0 või 1. Kui ORB-i meetodite korral on see 1, siis käsitletakse antud meetodid klassi vaikimisi meetodina, st kui päringus puudub action parameeter, siis kutsutaks välja see funktsioon. nologin 0 või 1, vaikimisi 0. Kui väärtus on 0, siis nõutakse kasutajalt funktsiooni jaoks sisse logimist, kui 1 siis võivad ka sisselogimata kasutajad seda vaadata. api 0 või 1, vaikimisi 0. Kui väärtus on 1, käsitletakse seda meetodit API meetodina ning lisatakse API dokumentatsiooni nimekirja. all_args 0 või 1, vaikimisi 0. Kui väärtus on 1, antakse ORB-i meetodisse kõik päringuargumendid, vastasel korral ainult defineeritud. is_public 0 või 1, vaikimisi 0. Kui väärtus on 1 ja klass on defineeritud xml/interfaces/public.xml failis, käsitletakse meetodit avaliku meetodina ning seda võib menüüvalikuna kasutada. caption tekst, mida kuvatakse avaliku meetodi info ühe meetodi parameetri kohta foo parameetri nimi [optional required] kas parameeter on valikuline või nõutud. 50

51 type parameetri tüüp, võib olla üks nendest (int, string, float, oid, object (objekti instants), var (määramata tüüp)) acl valikuline, kui see määratud ORB-i meetodile, siis eeldatakse, et parameeter sisaldab objekti ID-d ning seda ACL-i kontrollitakse. ACL definitsiooni märgitakse komaga eraldatult, nt acl=view;edit, tähendades et kasutajal on nii vaatamise kui muutmise õigus. ACL väärtus võib olla üks järgnevatest: view, edit, add, delete. default parameetri vaikimisi väärtus Iga parameetri järel võib olla ka 0 või enam rida kommentaari parameetri mitmerealine kirjeldus vigadest, mida see meetod saab väljastada kas error::raise meetodi kaudu või mitmerealine kirjeldus andmetest, mida meetod võib mitmerealine üldine kirjeldus meetodi näidiskoodi ja kommentaarid meetodi kasutamise kohta. Pilt 1. AW DocGeni ühe klassi dokumentatsiooni vaade. 51

52 1.1 Lisa 3: AW BugTracki kuvapildistus Pilt 2. AW BugTracki vaikimise vaade BugTracki enda arendusettepanekute kohta. 52