T SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B

Transkriptio

1 T SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B

2 T SEPA - Pariohjelmointi 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus Tuomas Tolvanen Ensimmäinen versio Timo Töyry Selitystä työkaluista lisätty Tuomas Tolvanen Koostettiin palautettava dokumentti

3 T SEPA - Pariohjelmointi 3 (7) SISÄLLYS 1. JOHDANTO Staattisten analyysityökalujen käyttö Katselmointi Referenssit MENETELMÄN KÄYTTÖÖNOTTO Katselmointi Työkalut KOKEMUKSET JA MUUTOKSET Project planning Implementation Implementation Yhteenveto...7

4 T SEPA - Pariohjelmointi 4 (7) 1. JOHDANTO Käytämme projektissa staattisia menetelmiä ohjelmakoodin laadunvarmistukseen. Menetelmät jakautuvat ohjelmakoodin automatisoituun analysointiin ja koodikatselmointikäytäntöihin. Sepa-aihe on valittu, koska näistä menetelmistä ei ole aikaisempaa käytännön kokemusta ja on nähty, että menetelmien käyttö olisi eduksi projektin laadunvarmistuskäytäntöjen osana Staattisten analyysityökalujen käyttö Automaattisessa analysoinnissa käytetään Javalle suunniteltuja analysointityökaluja, jotka analysoivat ohjelmakoodissa olevia ohjelmointivirheitä ja ohjelman kompleksisuutta. Työkalujen avulla saatujen tulosten perusteella tehdään koodiin tarvittaessa muutoksia. Analysointi pyritään integroimaan CruiseControl -järjestelmään, jolloin se voidaan suorittaa yksikkötestien yhteydessä säännöllisesti automatisoituna Katselmointi 1.3. Referenssit Katselmointikäytäntöihin kuuluu koodikatselmus, joka järjestetään ohjelman logiikan kannalta tärkeimmille komponenteille, kuten sovellusadapterin ja tietoliikenneadapterin keskeisimmille osille. Katselmointien tavoitteena on löytää komponenttien toteutuksesta mahdollisia ongelmia, jotka eivät ole tulleet ilmi muilla laadunvarmistusmenetelmillä. Katselmointi toteutetaan formaalina koodikatselmointina, jossa katselmointiin osallistuvat henkilöt tutustuvat katselmuksen kohteena olevaan koodiin ennen katselmointia. Katselmointitilaisuudessa katselmoinnin tulokset käydään läpi luokka ja metodi kerrallaan ja päätetään vaativatko löytyneet ongelmat jatkotoimenpiteitä. Katselmoinnin tulokset kirjataan ylös ja niiden perusteella tutkitaan SEPA:ssa katselmointikäytännön tehokkuutta. Referenssinä koodikatselmoinnin osalta on käytetty kirjaa: I.Burnstein: Practical Software Testing, Springer Professional Computing Lisäksi materiaalina on käytetty luentomateriaalia kurssilta: T Ohjelmistojen testaus ja laadunvarmistus

5 T SEPA - Pariohjelmointi 5 (7) 2. MENETELMÄN KÄYTTÖÖNOTTO 2.1. Katselmointi 2.2. Työkalut Ennen Iteraatio I:n päätöstä suoritetaan koodikatselmointi Tietoliikenneadapterin tietoliikenne-toiminnallisuudelle sekä Sovellusadapterin viestinkäsittely-toiminnoille. Iteraatio I:n lopussa syntyneelle koodille suoritetaan myös ohjelmallinen staattinen analysointi. Katselmoitavalle lähdekoodille tehdään tag versionhallintaan ja katselmointi kohdistuu tässä tagissa olevaan versioon lähdekoodista. Ryhmän jäsenet suorittavan katselmoinnin omatoimisesti ja kirjaavat havaintonsa kirjauslomakkeelle. Tulokset tarkastetaan katselmointitilaisuudessa, jossa lähdekoodi käydään läpi järjestyksessä ja päätetään vaatiko kukin kirjattu havainto jatkotoimenpiteitä. Koodikatselmoinnissa huomio keskittyy toiminnallisten virheiden lisäksi koodin kommentointiin ja luettavuuteen. Katselmointikäytännöistä järjestetään ryhmälle koulutus ennen ensimmäisen katselmoinnin suorittamista Ohjeet katselmointiin löytyvät ryhmän wikistä osoitteesta: Iteraatio I:n aikana on tarkoitus testata seuraavia staattisen analyysintyökaluja: CCCC FindBugs Javancss Jlint. Näistä on tavoitteena löytää ainakin yksi työkalu, jonka voisi integroida osaksi CruiseControl-järjestelmää. Toimiviksi havaitut työkalut otetaan käyttöön koodin staattiseen analyysiin toisessa iteraatiossa. CCCC tuottaa koodista html-muotoisen raportin, josta ilmenee monia koodin tasoa kuvaavia lukuja. FindBugs sisältää oman suhteellisen selkeän käyttöliittymän, jolla koodia voi analysoida. FindBugs:sta on lisäksi olemassa plugini Eclipseen. Javancss pitäisi tuottaa samat osittain samoja lukuja kuin CCCC:n sillä erolla, että CCCC:n raportti on selkeämpi ja tarkempi. Jlint on kaiketi CCCC:n ja Javancss:n tapainen työkalu. Tarkempaa tietoa ei toistaiseksi ole, koska emme ole toistaiseksi onnistuneet saamaan Jlint:iä toimimaan. Iteraatio I:n jälkeen soveltuvimmat työkalut integroidaan osaksi CruiseControl-järjestelmää.

6 T SEPA - Pariohjelmointi 6 (7) 3. KOKEMUKSET JA MUUTOKSET 3.1. Project planning Suunniteltiin katselmointikäytäntöjä ja tutustuttiin alustavasti staattisiin työkaluihin. Staattisten analyysityökalujen testaus päätettiin suorittaa iteraatio 1:n aikana, sitten kun on tuotettu saatu aikaiseksi jonkin verran koodia, johon työkaluja voisi testata. Päätettiin toteuttaa koodikatselmointi Iteraatio 1. loppupuolella Implementation 1 Toteutettiin koodikatselmointi Koodikatselmointi toteutettiin Tällöin katselmointiin svn:ään tagattusta haarasta Source/Dentego/tags/0.1.2-inspection/ oleellisimmat luokat sovellusja tiedonsiirtoadaptereista. Tiedonsiirtoadapterista katselmoitiin tiedostot FinvoiceServise.java ja OpenCDAService.java. Sovellusadapterista katselmointiin tiedostot MessageService.java, MessageController.java, RFDISMessageHandler.java ja QueryMessageHandler.java. Katselmoiduista tiedostoista löytyi odotetusti huomautettavaa, joita ei oltu havaittu normaalissa yksikkötestauksessa. Havainnot liittyivät toiminnallisiin yksityiskohtiin ja koodin kommentointiin ja luettavuuteen. Katselmoinnin havainnot kirjattiin ylös ja katselmoinnin jälkeen jaettiin tehtävät ongelmien korjaukseksi. Osa havatuista ongelmista oli jo korjattu ennen katselmointia, koska kehitystyötä jatkettiin normaalisti katselmointi version taggaamisen jälkeen. Loput havaitut ongelmat päätettiin korjata suurimaksi osaksi vielä ennen iteraation päättymistä. Testattiin staattisia analyysityökaluja Testattiin muutamia staattisia analyysityökaluja. Näistä lupaavilta vaikuttivat CCCC ja findbugs. Näistä ainakin CCCC pitäisi pystyä integroimaan CruiseControl:liin suhteellisen helposti. Findbug:sia ei välttämättä voida integroida CruiseControl:liin vaan se jäänee erilliseksi työkaluksi koodissa mahdollisesti olevien bugien metsästykseen. FindBugs vaikutti varsin kivalta työkalulta koodin laadun nopeaan tarkistukseen. FindBugs:n käyttöliittymässä ilmeni mystinen ongelma, käyttöliittymä ei jostain syystä suostunut näyttämään lähdekoodia sille varatussa paikassa. FindBugs:n Eclipse plugin vaikuttaa kätevältä, kun bugien metsästyksen voi liittää suoraan kehitys ympäristöön eikä tarvita erillistä ohjelmaa. Pluginin ongelmana on kuitenkin, että se lisää löytämänsä ongelmat Eclipse:n Problems-välilehdelle, josta ne saattaa olla vaikea havaita jos koodi tuottaa jo muutenkin paljon varoituksia (esim. javadoc:n puuteesta). FindBugs:n Eclipse plugin:n käyttöä tullaan varmasti jatkamaan Iteraatio II:ssa. Javancss:sää ei saatu toimimaan kunnolla, jonka takia sillä ei saatu luotua muuta kuin tyhjä raportti. Tyhjästäkin raportista selviää Javancss:n tuottamat

7 T SEPA - Pariohjelmointi 7 (7) 3.3. Implementation 2 arvot, jotka eivät näytä poikkeavan kovin paljoa CCCC:stä muuten kuin että Javancss:n tulokset vaikuttaisivat olevan huomattavasti suppeamia. Jlint:n kanssa oli pahoja ongelmia emmekä onnistuneet kääntämään sitä windows:lle. Eikä netistä saatavassa paketissa näemmä ollut binaareita valmiina vaikka niin ohjelma kotisivulla väitettiin. Tutkitaan vielä jatkossa saataisiinko ohjelma käännettyä tai löytyisikö valmiit binaarit jostain Yhteenveto A summary of the experiences. Evaluation of the suitability of the practice to your project, and ideas of the reasons if the practice was not suitable in this project.