Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

Esitys aiheesta: "Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta"— Esityksen transkriptio:

1 582101 - Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

2 Toteutuksesta ja testauksesta
Suunnitteluprosessista Tarkan tason luokkasuunnittelu Siirtyminen UML-kaavioista Java-toteutukseen Yksikkötestaus ja testausohjattu kehitys (TDD) Hyväksymis- ja regressiotestaus

3 Yleistä suunnitteluprosessista
Liiketoimintatason malli järjestelmän määrittelynä Karkean tason käyttötapaukset Liiketoiminta- oliot Kohdealuetason käsitteellinen malli Tarkat käyttötapaukset Analyysitason luokkamalli Käyttöliittymä- suunnitelma Arkkitehtuuri- malli Suunnittelutason malli Vuorovaikutus- kaaviot Tarkan suunnit- telutason luokat Tietokantamalli

4 Erilaisia suunnittelutason olioiden lähtökohtia
Käyttöliittymä- suunnitelma Arkkitehtuuri- malli Tarkat käyttötapaukset Analyysitason luokkamalli Käyttöliittymä- oliot (View) Kontrollioliot (Controller) Sisältöoliot (Model) Tarkan suunnittelutason luokkamalli

5 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)

6 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 vuorovaikutus-suunnittelun kanssa ja liittyy siihen kiinteästi

7 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

8 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

9 Esimerkki: Luokan KingKX125 operaatio checkFrequency(double)
boolean checkFrequency(double frequency) { // imaginary transmission test if(Math.random() < ) { return true; } return false; Itsenäinen, mutta ei kovinkaan älykäs Parempi toteutus voisi käyttää taajuuksia esittävää oliota taajuuden testaamiseen

10 Esimerkki: Luokan KingKX125 operaatio checkFrequency(double)
boolean checkFrequency(double freq) { Frequency f; f = FrequencyFactory.getFrequency(freq); return f.transmissionTest(); } Toteuttaa palvelun toista oliota käyttäen Näin esiteltiin riippuvuus luokkaan Frequency; tuon luokan toiminnan muuttuessa vaihtuu myös tämän luokan toiminta

11 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

12 Esimerkki: analyysitason käsitteellisestä kaaviosta

13 Esimerkki: .. suunnittelutason kaavioon

14 Esimerkki: suunnittelutason luokasta ..

15 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: } ...

16 Testaus ohjelmistoprosessin eri vaiheissa
Käsitteellinen luokkamalli Luokkasuunnittelu ja koodaus Arkkitehtuurimalli Päivityspyynnöt Vikaraportit Käyttötapaukset Testausohjattu ohjelmistokehitys Hyväksymis- testaus Ylläpito ja regressiotestaus Muut spesifikaatiot ja vaatimukset

17 Testaus ohjelmistoprosessin eri vaiheissa (vaihtoehtoinen jaoittelu)

18 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

19 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)

20 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

21 JUnit * TestSuite run(TestResult) addTest(Test) Test run(TestResult)
TestCase runTest() setUp() tearDown() AccountTest setUp() testDeposit() … Account deposit(double) …

22 Yksikkötestausesimerkki (black-box)

23 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ä

24 MockFrequency Radioesimerkissä vaihdettiin radio kommunikoimaan radiotaajuutta simuloivan Frequency-luokan olioiden kanssa Radiotaajuus-olion tehtävänä saattaisi olla välittää oliolle lähetetyt viestit kaikille järjestelmän radioille, jotka ovat virittäytyneet kuuntelemaan ko. taajuutta Vrt. Observer-pattern Radiotaajuus-oliota testattaessa testataan siis viestinvälityksen toimivuutta; Radion check-metodia testattaessa tarkistaan, että radio testissään todellakin käy kaikilla kanavilla

25 MockFrequency Radion metodin check() yksikkötestiä varten tehdään uusi luokka, MockFrequency, jota käytetään yhdessä yksikkötestaavan luokan kanssa Radion metodin check() yksikkötesti onnistuu, mikäli radio metodissaan läpikäy jokaisen kanavan MockFrequency-luokkaan kirjoitetaan yksikkötestitapauksen kannalta olennainen toiminnallisuus Kaikkia Frequency-luokan toiminnallisuuksia / vastuita ei tarvitse (eikä edes pidä!) toteuttaa

26 MockFrequency.java public class MockFrequency implements Frequency { private boolean checked = false; public MockFrequency(double d) { } public boolean transmissionTest() { return checked = true; } public boolean isChecked() { return checked; public void transmit(String str) { /* NOOP */ }

27 Hyväksymistestaus (acceptance testing)
Testataan toteutettu koodi erikseen toteutuksen jälkeen Kattaa usein laajempia toiminnallisuus-kokonaisuuksia 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

28 Regressiotestaus Järjestelmän muutoksen jälkeen uudelleen-suoritettavat 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