582101 - Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta 1
Toteutuksesta ja testauksesta Suunnitteluprosessista Tarkan tason luokkasuunnittelu Siirtyminen UML-kaavioista Java-toteutukseen Yksikkötestaus ja testausohjattu kehitys (TDD) Hyväksymis- ja regressiotestaus 2
Yleistä suunnitteluprosessista Liiketoimintatason malli järjestelmän määrittelynä Karkean tason käyttötapaukset Liiketoimintaoliot Käyttöliittymäsuunnitelma Arkkitehtuurimalli Kohdealuetason käsitteellinen malli Tarkat Analyysitason käyttötapaukset luokkamalli Suunnittelutason malli Vuorovaikutuskaaviot Tarkan suunnittelutason luokat Tietokantamalli 3
Erilaisia suunnittelutason olioiden lähtökohtia Käyttöliittymäsuunnitelma Arkkitehtuurimalli Tarkat Analyysitason käyttötapaukset luokkamalli Tarkan suunnittelutason luokkamalli Käyttöliittymä- oliot (View) Kontrollioliot (Controller) Sisältöoliot (Model) 4
Käyttöliittymästä sisältöön Suunnittele käyttöliittymä ja valitse sovellettava arkkitehtuurimalli, esim. MVC Sisällytä suunnitelmaasi tarvittavat käyttöliittymäoliot ja luokat Sisällytä suunnitelmaasi kustakin käyttötapauksesta vastaava kontrolliolio (sama voi vastata useasta) Määrittele kontrollioliolle käyttötapauksen hoitamiseen tarvittavat operaatiot ja attribuutit Sisällytä suunnitelmaasi käyttötapauksessa tarvittavat sisältöoliot (vrt. analyysitason luokkamalli) Määrittele sisältöolioille käyttötapauksen hoitoon tarvittavat operaatiot (lisää tarvittaessa luokkia) 5
Tarkan tason luokkasuunnittelu Tarkentaa alkuperäistä luokkamallia Syötteet (analyysitason luokkamallin lisäksi) käyttötapausmalli määrittelee toiminnallisuuden, joka on toteutettava valittu arkkitehtuurimalli (architectural framework) asettaa tiettyjä rajoitteita Tuottaa suunnittelutason luokat ja rajapinnat yksityiskohtineen (erityisesti operaatiot) Etenee yleensä rinnakkain vuorovaikutussuunnittelun kanssa ja liittyy siihen kiinteästi 6
Palvelujen jakaminen luokkien operaatioiksi Lähtökohtana tietojärjestelmälle määritellyt palvelut (käyttötapaukset) Palvelut toteutetaan olioiden yhteistyönä (olioiden verkkona) Tavoitteena haluttujen palveluiden toteuttaminen selkeän ja ylläpidettävän olioverkon avulla Oliolle (tai luokalle) voidaan antaa vastuu jostakin palvelukokonaisuudesta ja operaatiot määräytyvät tämän vastuun puitteissa 7
Palvelujen jakaminen luokkien operaatioiksi Palvelua määriteltäessä, on selvitettävä pystyykö luokan olio hoitamaan sen itsenäisesti oman tietosisältönsä avulla; ja ellei pysty millaista yhteistyötä muiden olioiden kanssa tarvitaan Kumpikin selvityksistä voi tuottaa uusia attribuutteja tai operaatioita 8
UML-kaaviosta toteutukseen UML-luokista puuttuu tyypillisesti yksityiskohtia, jotka on kiinnitettävä luokan toteuttamiseksi kooditasolla Olennaisinta on päättää yhteyksien toteuttamisesta 1-1-yhteydet toteutetaan tyypillisesti kohteen tyypin mukaisina tietokenttinä (data member, data field) 1-N- ja N-M-yhteydet toteutetaan usein kokoelmaluokkien avulla UML tarjoaa mahdollisuuden esittää luokat niin tarkalla tasolla, että niistä voidaan generoida luokkarungot metodien toteutuskoodia ei kuitenkaan yleensä anneta myöskään standardikirjastoihin kuuluvia kokoelma- ja vastaavia luokkia ei yleensä merkitä näkyviin 9
Esimerkki: analyysitason käsitteellisestä kaaviosta 10
Esimerkki:.. suunnittelutason kaavioon 11
Esimerkki: suunnittelutason luokasta.. 12
Esimerkki:.. vastaavaan Java-luokkaan Movie.java 7: public class Movie { 8: private String movietitle; 9: 10: private double moviecode; 11: 12: private String director; 13: 14: private Collection listedas; 15: 16: public Movie(double moviecode,string title,string director){ 17: this.moviecode = moviecode; 18: this.director = director; 19: this.movietitle = title; 20: listedas = new ArrayList(); 21: }... 13
Testaus ohjelmistoprosessin eri vaiheissa Käsitteellinen luokkamalli Luokkasuunnittelu ja koodaus Vikaraportit Käyttötapaukset Testausohjattu ohjelmistokehitys Hyväksymistestaus Ylläpito ja regressiotestaus Muut spesifikaatiot ja vaatimukset Arkkitehtuurimalli Päivityspyynnöt 14
Testaus ohjelmistoprosessin eri vaiheissa (vaihtoehtoinen jaoittelu) 15
Testausohjattu ohjelmistokehitys (Test-driven development, TDD) Ohjelmoija kirjoittaa testimäärittelyt ja testikoodin Testit laaditaan ennen koodattavan moduulin, luokan, tms. toteutusta (usein jo ennen lopullista suunnittelua) Sovelluskoodi kirjoitetaan täyttämään testien sisältämät vaatimukset (testit ovat moduulin spesifikaatio) Testaus ohjaa kehitystyötä (ei ole erillinen laadunvarmistusvaihe toteutuksen jälkeen) testien on aluksi (ennen toteutuksen valmistumista) epäonnistuttava (pyritään varmistamaan, että testit todella testaavat haluttua asiaa) toiminnallisuus katsotaan toteutetuksi, kun testit menevät läpi 16
Yksikkötestaus (unit testing) Testausohjattu kehitys alkaa yksikkötestauksella Yksikkötestin yksikkö on yleensä luokka testattava luokka eli testin kohde (voi olla myös luokan osa tai muutaman toisiinsa kiinteästi liittyvän luokan joukko) testiluokka eli testin suorituksen ja resurssit määrittelevä luokka (tai luokkajoukko) Pienin itsenäisesti suoritettava testin osa (yleensä testiluokan metodi) on testitapaus (test case) Testitapauksia kootaan tyypillisesti suuremmiksi kerralla suoritettaviksi testikokoelmiksi (test suite) 17
Mihin testikoodi sijoitetaan? Jokaisen testattavan yksikön (luokan) sisään esim. Javassa main-metodiin tai staattiseen sisäiseen luokkaan Erillisiin testiluokkiin yleensä käytetään geneeristä testauskehystä JUnit on (erityisesti XP:n muiden ketterien ohjelmisto-prosessien yhteydessä) suosittu testauskehys 18
JUnit Test run(testresult) * TestCase run(testresult) runtest() setup() teardown() TestSuite run(testresult) addtest(test) Account deposit(double) AccountTest setup() testdeposit() 19
Yksikkötestausesimerkki (black-box) 20
Yksikkötestaus oliojärjestelmässä Oliojärjestelmässä toiminnallisuus tyypillisesti toteutetaan olioverkon yhteistyönä Edellisen kalvon yksikkötestausesimerkki testaa olioverkkoa mustana laatikkona, joka joko toimii tai ei toimi Sana yksikkötestaus kuitenkin viittaa ajatukseen, jonka mukaan jokainen testattava yksikkö olisi itsenäisesti testattavissa Eräs ratkaisu on kehittää kullekin luokalle testausluokkien ympäristö (mock objects), jossa testattavat oliot voivat toimia yhteistyössä 21
Black-box ja white-box -testaus Black-box testauksella voidaan tarkistaa, että tulos vastaa odotettua White-box testauksessa voidaan tehdä mock-olioita näyttelemään aitoa kontekstia 22
Hyväksymistestaus (acceptance testing) Testataan toteutettu koodi erikseen toteutuksen jälkeen Kattaa usein laajempia toiminnallisuuskokonaisuuksia kuin yhden luokan (jopa koko järjestelmän) Tarkistetaan verifiointipisteissä (verification point), että käyttötapauksissa kuvatut vaatimukset toteutuvat Yleensä mustalaatikkotestausta (black-box testing) ei huomioida järjestelmän sisäistä toteutusta tai toimintaa, vaan verrataan ainoastaan syötteitä saatuihin tulosteisiin annetaan usein automaattisesti tuotettuina testiskripteinä testaaja suorittaa manuaalisesti käyttöliittymän kautta ne testit, joita ei voida automatisoida 23
Regressiotestaus Järjestelmän muutoksen jälkeen uudelleensuoritettavat relevantit hyväksymistestit koskevat muuttuneita osia ja niistä riippuvia osia Tarkoituksena varmistaa, että muutokset ja korjaukset on toteutettu oikein muutokset eivät ole aiheuttaneet ei-toivottuja sivuvaikutuksia Olennaista testien automatisointi mahdollisimman pitkälle turhan testauksen välttäminen, jos mahdollista Regressiotestiin (kuten hyväksymistestiinkin) liittyy testiskripti ja sen toteutus (tai testin suoritusjärjestelmä) syötteiden ja odotettujen tulosten spesifikaatiot testidokumentti, jossa raportoidaan testin tulokset 24