6. Suunnittelu. Suunnitteluprosessi

Transkriptio

1 6. Suunnittelu Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja. Tavoitteena on kuvata tehtävä ohjelmisto sellaisella tarkkuudella, että sen toteutus on suoraviivaista. Suunnittelun tuloksena saadaan kuvaukset toteutettavasta ohjelmistosta, sen tarvitsemista ja tuottamista tiedoista, ulkomaailman rajapinnoista ja mahdollisesti käytetyistä algoritmeista. Sivu Suunnitteluprosessi Requirements specification Design activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Design products Kuvalla (C) I. Sommerville 2000 Sivu

2 Suunnitteluprosessin työvaiheet 1. Arkkitehtuurisuunnittelu (Architectural design) Osajärjestelmät tunnistetaan ja kuvataan niiden välinen yhteistyö. 2. Abstrakti määrittely (Abstract specification) Kuvataan osajärjestelmien tehtävät ja rajoitukset. 3. Rajapintasuunnittelu (Interface design) Suunnitellaan osajärjestelmien rajapinnat ja yhteistyö. 4. Komponenttisuunnittelu (Component design) Suunnitellaan osajärjestelmien rakenne. 5. Tietorakennesuunnittelu (Data structure design) Suunnitellaan osajärjestelmien vaatimat tietorakenteet. 6. Algoritmisuunnittelu (Algorithm design) Suunnitellaan mahdolliset tarvittavat algoritmit. Sivu Arkkitehtuurisuunnittelu Käytännössä jokainen ei-triviaali ohjelma rakentuu useasta osajärjestelmästä. Yksi osajärjestelmä sisältää samaan asiaan liittyviä piirteitä ja tarjoaa samankaltaisaia palveluita. Osajärjestelmiä käytetään erottamaan metsä (koko järjestelmä) puilta (yksittäiset komponentit). Ilman osajärjestelmiä saatava arkkitehtuuri luokkineen olisi niin laaja, että sitä ei voisi hahmottaa kunnolla. Arkkitehtuurisuunnittelussa eristetään osajärjestelmät ja kuvataan niiden välinen yhteistyö. Sivu

3 Osajärjestelmä ja moduuli Sommerville määrittelee osajärjestelmät ja moduulit: Osajärjestelmä on kokonainen järjestelmä, joka toimii itsenäisesti riippumatta muiden järjestelmien tarjamista palveluista. Osajärjestelmä rakentuu moduuleista ja sisältää yhden tai useamman rajapinnan muille osajärjestelmille. Osajärjestelmä saattaa rakentua useasta aliosajärjestelmästä. Moduuli on järjestelmän komponentti, joka tarjoaa palveluita muille moduuleille. Se ei ole itsenäinen samalla tavalla kuin osajärjestelmä, vaan toimii vahvemmassa yhteistyössä muiden moduuleiden kanssa osajärjestelmän sisällä. Moduulit saattavat rakentua alimoduuleista. Sommerville ei tee selkeää jäsentelyä osajärjestelmälle, moduulille ja komponentille. Jatkossa pidämme moduulia ja komponenttia synonyymeina. Sivu Osajärjestelmien jaottelu Osajärjestelmien valinta ja tunnistus ovat suunnittelupäätöksiä. Sommervillen vaihtoehdot ovat: Tietovarastomalli (Repository model) Osajärjestelmät erotellaan tehtävien mukaan. Kaikki osajärjestelmät käyttävät yhtä tietokantaosajärjestelmää, johon talletetaan kaikki yhteiskäytössä oleva tieto. Jokaisella osajärjestelmällä on oma tietokanta paikallisille tiedoille. Asiakas-palvelin -arkkitehtuuri (Client-server architecture) Osa osajärjestelmistä on palvelimia, jotka tarjoavat palveluja. Loput ovat asiakkaita, jotka käyttävät palvelimien tarjoamia palveluita. Abstraktin koneen malli (Abstract machine model) Osajärjestelmät ovat sisäkkäisiä. Jokainen tarjoaa abstraktiotason palveluihin. Mitä alemmalla abstraktiotasolla ollaan, sitä lähempänä ollaan laitteistotasoa. Sivu

4 Lisää osajärjestelmistä Osajärjestelmien jaottelun täytyy olla sellainen, että sen tehtävällä ja tarjoamilla palveluilla on selvät rajat. Sitä mukaa kun osajärjestelmät tunnistetaan ja suunnitellaan, niiden täytyy toteuttaa seuraavat ehdot: Jokaisella osajärjestelmällä on hyvin määritelty rajapinta, jonka kautta se on yhteistyössä muiden osajärjestelmien kanssa. Osajärjestelmien lukumäärän pitäisi olla kohtuullisen pieni. Osajärjestelmä voidaan osittaa sisäisesti aliosajärjestelmiksi, jos tällainen jaottelu on luonnollinen ja jos muussa tapauksessa osajärjestelmästä tulisi laaja ja vaikeaselkoinen. Osajärjestelmä rakentuu rajapinnan toteuttavista ulkoisista moduuleista ja palvelut toteuttavista sisäisistä moduuleista. Sivu Arkkitehtuurisuunnitelma Arkkitehtuurisuunnittelun tuloksena saadaan arkkitehtuurisuunnitelma. Se kuvaa löydetyt osajärjestelmät, niiden tehtävät, jaottelun moduuleiksi ja osajärjestelmien välisen yhteistyön. Arkkitehtuurisuunnitelma sisältää yleensä joukon kaaviokuvia ja yksityiskohdista kertovat kuvaustekstit Yksinkertaisin arkkitehtuurin kaaviokuva sisältää osajärjestelmät laatikkoina ja osajärjestelmien välisen yhteistyön nuolina. Tällainen malli riittää hyvin korkeimmaksi abstraktioksi, kunhan arkkitehtuurikuvaukset on tehty huolella. Sivu

5 Esimerkkiarkkitehtuuri (kalvo 15) Radar system Transponder system Data comms. system Aircraft comms. Telephone system Position processor Backup position processor Comms. processor Backup comms. processor Aircraft simulation system Flight plan database Air Traffic Control system architecture Weather map system Accounting system Controller info. system Controller consoles Kuvalla (C) I. Sommerville 2000 Activity logging system Sivu Abstrakti määrittely Tämä työvaihe tehdään rinnakkain arkkitehtuurisuunnitelun kanssa. Siinä löydetyille osajärjestelmille tehdään kirjallinen kuvaus, joka sisältää seuraavat kohdat: osajärjestelmän tehtävä, osajärjestelmän tarjoamat palvelut, osajärjestelmään liittyvät säännöt ja rajoitukset, osajärjestelmän mahdollinen rinnakkaisuus muiden osajärjestelmien kanssa ja mahdolliset aliosajärjestelmät, joista jokaiselle tehdään vastaava abstrakti määrittely. Kuvaukset liitetään arkkitehtuurisuunnitelmaan. Sivu

6 6.3. Rajapintasuunnittelu Rajapintasuunnittelu on ehkä suunnittelun tärkein työvaihe. Siinä jokaisen osajärjestelmän rajapinta muihin osajärjestelmiin suunnitellaan ja dokumentoidaan yksityiskohtaisesti. Osajärjestelmien rajapintojen pitää olla sellaiset, että osajärjestelmän tarjoamia palveluja voidaan käyttää tietämättä niiden toteutuksesta mitään. Näin erotetaan osajärjestelmän tarjoamat palvelut (rajapinta) niiden toteutuksesta (osajärjestelmän komponentit). Rajapintojen kuvaus tulee arkkitehtuurisuunnitelmaan Sivu Osajärjestelmien rajapintojen määrittelyn tulee olla yksiselitteiset ja ristiriidattomat. Tämän johdosta luonnollinen kieli ei riitä rajapintojen määrittelyyn. Toisaalta ohjelmointikielikään ei välttämättä ole paras tapa määritellä rajapintoja, sillä ohjelmointikieli menee helposti turhan matalalle abstraktiotasolle. Rajapinnan määrittelyyn voidaan käyttää jotain formalismia, kuten Sommervillen luvussa 9.2. Toisaalta formalismia tärkeämpää on valittu abstraktiotaso. Kuvauksesta täytyy selvitä tarvittavat tiedot ilman turhia toteutusriippuvia yksityiskohtia. Sivu

7 Rajapinnan kuvaus Itse suosittelen rajapinnan kuvaukselle seuraavaa: Rajapinnan nimi: Nimi voi kuvata myös yhtä rajapinnan palvelua tai palvelujoukkoa. Yleinen kuvaus: Yleinen kuvaus on vapaamuotoinen selostus rajapinnan tarjoamista palveluista. Rajapinnan tarjoamat palvelut. Jokaisesta palvelusta nimi, yleinen kuvaus, sisään otettavat parametrit arvojoukkoineen, ulos annettavat tulokset arvojoukkoineen, poikkeustilanteet, alkuehdot ja loppuehdot. Sivu Rajapinnan kuvaus (jatkuu) Sisään otettavat parametrit arvojoukkoineen vastaavat metodin parametreja. Ulos annettavat tulokset arvojoukkoineen vastaavat metodin tulosta. Poikkeustilanteet kertovat, mihin erikoistapauksiin palvelussa varaudutaan. Alkuehto on jokin ehto, jonka on oltava voimassa ennen kuin palvelua voidaan käyttää. Loppuehto on jokin ehto, joka on voimassa, kun palvelu on suoritettu. Alku- ja loppuehdot eivät ole pakollisia. Sivu

8 Arvojoukoista Arvojoukot ovat tärkeitä, eikä niitä useinkaan määritellä ohjelmointikielissä. Esimerkiksi jos meillä on sisään otettava parametri ikä, niin parametrilla on varmaankin arvojoukko , mutta ohjelmointikielellä INTEGER. Oikein määritellyt yksityiskohtaiset arvojoukot helpottavat osajärjestelmien suunnittelua, sillä arvojoukkoon kuulumisen testaus voidaan tehdä heti palveluun savuttaessa. Samoin arvojoukot helpottavat testausta, sillä niitä voidaan käyttää hyväksi testitapausten generoinnissa. Sivu Rajapintaesimerkki Nimi: Juuri Kuvaus: Palauttaa toisen asteen yhtälön ax 2 +bx+c=0 reaalijuuret Palvelu Juuri Kuvaus: Toteuttaa rajapinnan Juuri Parametrit sisään: a,b,c : R (reaalilukuja) Parametrit ulos: r 1,r 2 : R (reaalilukuja) Huom. Toinen tai molemmat lähtevistä parametreista voi puuttua. Poikkeustilanteet: a = 0 (ei toisen asteen yhtälö) Alkuehdot: Ei alkuehtoja Loppuehdot: Ei loppuehtoja Sivu

9 Rajapintaesimerkki javalla public interface Juuri { }; class result { }; double r1; double r2; // juuret int roots; // juurten määrä public result Juuri(double a, double b, double c) throws aiszeroexception; Kuvaukset, alku- ja loppuehdot pitää laittaa kommentteina. Sivu Komponenttisuunnittelu Kun osajärjestelmien rajapinnat on suunniteltu huolellisesti, rajapintojen tarjoamien palveluiden toteutus ei vaikuta rajapintoihin. Näin samalle rajapinnalle voi olla monta toteutusta, ja toisaalta yksi toteutus voi toteuttaa monta rajapintaa. Komponenttisuunnittelu on osajärjestelmien rajapinnan toteutusta. Siinä osajärjestelmä jaetaan komponentteihin ja selvitetään komponenttien välinen yhteistyö. Komponenttisuunnittelun tuloksena saadaan kunkin osajärjestelmän komponenttirakenne. Sivu

10 Komponentit Komponentti ei ole itsenäinen. Se toimii yhteistyössä muiden osajärjestelmän komponenttien kanssa. Jokaisella komponentilla on rajapinta, jonka kautta päästään käsiksi komponentin tarjoamiin palveluihin. Osajärjestelmä rakentuu ulkoisista komponenteista, jotka toteuttavat osajärjestelmän rajapinnan, ja sisäisistä komponenteista, jotka tarjoavat rajapinnan toteutuskomponenteille palveluja. Oliopohjaisessa suunnittelussa komponentti on yleensä pakkaus (package), joka sisältää useita olioluokkia (object classes). Sivu Oliot Lopuksi jokainen komponentti rakentuu joukosta yhteistyötä tekeviä olioita, jotka komponenttien tapaan ovat joko sisäisiä tai ulkoisia olioita. Ulkoiset oliot toteuttavat komponentin määrittelemän rajapinnan. Sisäiset oliot tarjoavat palvelut, joita ulkoiset oliot tarvitsevat rajapinnan toteutukseen. Suunnittelutasolla jaottelu järjestelmä-osajärjestelmäkomponentti-olio toimii hyvin. Toteutuksessa osajärjestelmistä alaspäin oliot ovat kaikkien rajapintojen toteuttajina. Järjestelmässä on vain olioita ja osajärjestelmiä. Sivu

11 6.5. Tietorakennesuunnittelu Kun järjestelmä on saatu jaettua osajärjestelmiin, komponentteihin ja olioluokkiin (ryhmiin samanlaisia olioita), voidaan miettiä kunkin osajärjestelmän käyttämiä tietorakenteita. Tietorakenteet voivat olla ulkoisia, jolloin niitä käytetään osajärjestelmän sisällä useista komponenteista tai olioluokista, tai ne voivat olla sisäisiä, jolloin ne näkyvät vain tietylle olioluokalle. Tietorakenteiden suunnittelussa löydetään uusia tietorakenteiden toteutukselle välttämättömiä olioluokkia ja jopa komponentteja. Sivu Algoritmisuunnittelu Algoritmisuunnittelu on suunnitteluprosessin viimeinen vaihe. Siinä valituista ei-triviaaleista palveluista tehdään pseudokieliset kuvaukset. Kaikista palveluista ei kannata tehdä kuvauksia, sillä varsinkin sisäisiä palveluita on paljon ja useimmat niistä ovat kohtullisen suoraviivaisia toteutettavia. Joskus varsinkin monimutkaisista algoritmeista tulee sellaisia, että ne kannattaa jakaa useaksi palveluksi. Tällöin yksi palvelu toimii algoritmin toteutuksen hallinnoijana, joka kutsuu toteuttavia palveluita. Sivu

12 6.7. Olioiden tunnistus Teoriassa ohjelmiston jako osajärjestelmiin, komponentteihin ja olioihin on hyvä idea. Mutta mistä nämä hienot elementit löydetään? Osajärjestelmät löydetään yleensä vaatimusanalyysissa ja viimeistään arkkitehtuurisuunnittelussa. Osajärjestelmiä ei ole paljon ja yleensä samat arkkitehtuurit toimivat samantyyppisissä ohjelmistoissa. Joskus myös osa komponenteista tai olioluokista selviää suoraan vaatimusanalyysista ilman sen kummempaa tunnistamista. Sivu Olioiden tunnistus (jatkuu) Seuraavat menetelmät sopivat osajärjestelmien, komponenttien ja olioiden tunnistamiseen: Sanalistat (grammatical analysis). Järjestelmän kuvauksista etsitään substantiiveja ja verbejä. Substantiivit ovat luokka-, komponentti- ja osajärjestelmäehdokkaita. Verbit ovat palveluehdokkaita. Konkreettiset ehdokkaat. Järjestelmästä tunnistetaan konkreettisia kohteita (esim. koneita), toimijoita (esim. asiakkaita), tapahtumia (esim. palvelupyyntöjä), yhteistyötä (esim. tapaamisia), paikkoja (esim. toimistoja), organisaatiota (esim. yrityksiä) jne. Näitä käytetään analyysin pohjana. Analyysia täydennetään tietorakenteilla ja algoritmeilla. Sivu

13 Olioiden tunnistus (jatkuu) Toiminnan ymmärrys. Ensin kootaan joukko näkemyksiä tehtävästä ohjelmistosta. Jokainen näkemys sisältää joukon palveluita, jotka tunnistetaan ja sijoitellaan osajärjestelmiin. Lisäksi tunnistetaan järjestelmän toimijat ja toiminnan tulokset. Skenaariolähtöinen analyysi. Jokainen löydetty skenaario analysoidaan. Skenaarion perusteella mietitään tarvittavat osajärjestelmät, komponentit ja luokat, joiden avulla skenaario on toteutettavissa. Skenaarioista eristetyt elementit yhdistetään yhteen koko järjestelmän kuvaukseksi. Ylläolevat menetelmät antavat raakaelementtejä, jotka on jalostettava lopullisiksi osajärjestelmiksi, komponenteiksi ja luokiksi. Kaikkia menetelmiä käytetään usein samaan aikaan. Sivu Uudelleenkäyttö Oliopohjaisten menetelmien aikakaudella ohjelmiston osien uudelleenkäyttö on lisääntynyt huomattavasti. Koko suunnitteluprosessi tehdään sellaiseksi, että toteutuksessa voidaan käyttää jo aiemmin suunniteltuja, toteutettuja ja dokumentoituja ohjelman osia; suunnittelussa voidaan eristää osia, jotka voidaan dokumentoida ja tallettaa käytettäväksi muissa projekteissa. Uudelleenkäyttö säästää suunnittelu- ja toteutuskustannuksia, mutta voi lisätä ylläpitokustannuksia. Uudelleenkäytetyistä osista tiedetään yleensä rajapinta ja kuvaus. Rajapinta ei välttämättä kelpaa enää muuttuneisiin vaatimuksiin. Sivu

14 Komponenttipohjainen suunnittelu Komponenttipohjaisessa suunnittelussa pyritään yhtäältä käyttämään jo olemassaolevia komponentteja ja toisaalta eristämään uusia komponentteja yleiseen käyttöön. Pelkät olioluokat todettiin nopeasti huonoiksi eristettäviksi. Luokat olivat vahvasti erikoistuneita ja niiden oliot olivat liian vahvasti kytkeytyneitä muihin olioihin. Komponentti on abstraktimpi käsite kuin olio(luokka). Komponentti kapseloi yhden tai useamman yhteistyössä olevan olioluokan yhdeksi. Sivu Komponentit Komponentit tarjoavat palveluja rajapintansa kautta. Palveluiden toteutus, käytetty ohjelmointikieli ja jopa suoritusalusta eivät näy palvelupyynnön esittäjälle. Komponenttien koko ja kompleksisuus voivat vaihdella yksinkertaisista funktioista täydellisiin järjestelmiin, kuten tietokannan hallintajärjestelmä. Sommervillen mukaan komponentin lähdekoodi ei ole saatavilla. Yleensä lähdekoodi on saatavilla, mutta siihen ei viitata suoraan. Vain kaupasta ostetuista komponenteista saattaaa puuttua lähdekoodi. Sivu

15 Komponentin rajapinnat Komponentilla on kaksi rajapintaa, sisään ja ulos: Komponentti tarjoaa rajapinnan, joka määrittelee komponentin tarjoamat palvelut. Komponentti tarvitsee rajapinnan, joka kuvaa järjestelmältä vaadittavat palvelut. Requires interface Component Provides interface Kuvalla (C) I. Sommerville 2000 Sivu Suunnittelumallit Valmiiden komponenttien käyttö suunnittelussa onnistuu silloin, kun sopivia komponentteja on saatavilla. Vaikka komponentit olisi suunniteltava ja toteutettava itse, suunnittelussa voidaan käyttää hyväksi hyväksi havaittuja periaatteita. Näitä hyväksi havaittuja suunnitteluperiaatteita kutsutaan suunnittelumalleiksi (design patterns). Suunnittelumallit lähtevät ajatuksesta, että samat perusrakenteet toistuvat oliopohjaisessa suunnittelussa jatkuvasti. Sivu

16 Suunnittelumallit (jatkuu) Malli tarjoaa nimensä mukaisesti hyväksi havaitun menetelmän ratkaista tunnettu suunnitteluongelma. Ratkaisu on yleensä esitetty sellaisella abstraktiotasolla, että sen perusteella voidaan tehdä sopivia toteutuksia erilaisiin sovelluksiin ja ympäristöihin. Vaikeinta suunnittelumalleissa on tunnistaa oikea malli oikeaan tehtävään. Yleisimmät mallit tulevat kuitenkin hyvin nopeasti tutuiksi ja käyttökelpoisiksi. Mallien hallinta ja käyttö helpottaa huomattavasti hyvien oliopohjaisten ratkaisujen suunnittelua. Sivu Suunnittelumallin rakenne Suunnittelumallin kuvaus sisältää seuraavat osat: Mallin nimi Nimi on mallia kuvaava tunniste suunnittelumallille. Kuvaus Kuvaus selittää, miten malli toimii. Ongelmakuvaus Ongelmakuvaus selittää ongelmakentän, mihin malli tuo ratkaisun. Ratkaisukuvaus Ratkaisukuvaus selittää ratkaisussa tarvittavat osat, niiden tehtävät ja osien väliset suhteet. Seuraukset Seurauksissa kuvataan mallin käytön seuraukset ja mahdolliset sivuvaikutukset. Sivu

17 Suunnittelumalliesimerkki Esimerkkinä suunnittelumalleista esitän Observersuunnittelumallin (tarkkailija? no miten vaan). Observer-mallia käytetään, kun olion tilasta tarvitaan useita erilaisia esityksiä. Malli erottaa esitettävän olion esityksen toteuttavista olioista. Obsever-mallin avulla voidaan esimerkiksi kuvata samaa dataa taulukkona, piirakkana tai käyränä. Kun data muuttuu, muutokset näkyvät automaattisesti kaikissa Observer-mallilla toteutetuissa näkymissä. Sivu Suunnittelumalliesimerkki (jatkuu) C D B A A B C D Subject Observer 1 A: 40 B: 25 C: 15 D: 20 Observer 2 Kuvalla (C) I. Sommerville 2000 Sivu

18 Suunnittelumalli Observer Nimi Observer Kuvaus Eristää olion tilan esityksen itse oliosta Ongelmakuvaus Observer ratkaisee tilanteen, missä samasta oliosta tarvitaan automaattisesti muuttuvia erilaisia näkymiä. Ratkaisukuvaus Seuraavalla kalvolla UML:lla. Seuraukset Tilan esitysten optimointi on epäkäytännöllistä. Sivu Ratkaisukuvaus Observer Subject Observer Attach (Observer) Detach (Observer) Notify () for all o in observers o -> Update () Update () ConcreteSubject ConcreteObserver GetState () subjectstate return subjectstate Update () observerstate observerstate = subject -> GetState () Kuvalla (C) I. Sommerville 2000 Sivu

19 7. Verifiointi ja validointi Verifiointi ja validointi on työvaihe, missä tarkastetaan, että suunnittelussa ja toteutuksessa saatu tuote toimii sekä syntaktisesti että semanttisesti oikein. Syntaktisesti oikein: ohjelma on riittävän virheetön, toimii kaikilla syötteillä ja toteuttaa implisiittiset vaatimukset. Semanttisesti oikein: ohjelma toteuttaa vaatimusanalyysissa määritellyt toiminnalliset ja ei-toiminnalliset vaatimukset. Verifiointi on syntaktista tarkistusta: Teemmekö tuotteen oikein?. Validointi on semanttista tarkistusta: Teemmekö oikeaa tuotetta? Sivu Verifiointi- ja validointitekniikat Sekä verifioinnissa että validoinnissa käytetään kahta perustapaa: tarkastuksia (inspections) ja testausta. Tarkastuksissa osa ohjelmistoa tai ohjelmiston dokumentaatiota tarkastetaan ohjelmaa suorittamatta. Tarkastukset ovat staattinen tekniikka. Testauksessa suorituskelpoista ohjelmaa tai sen osaa ajetaan joillain syötteillä ja kirjataan suorituksen tulos. Testaus on dynaaminen tekniikka. Lisäksi validoinnissa käytetään toisinaan hyväksi simulointia, formaaleja menetelmiä ja mallinnusta. Sen sijaan verifioinnissa tarkastukset ja testaus ovat käytännössä ainoat tavat. Sivu

20 7.1. Tarkastukset Tarkastus (inspection) on kokous, jossa tarkastetaan jonkin työvaiheen tuotos, tai osa siitä, ja yritetään löytää siitä puutteita ja virheitä. Puute = vajaa määritys tai puuttuva toiminta Virhe = väärin tehty määritys tai ei-toivottu toiminta Tarkastuksia tehdään kaikissa projektin työvaiheissa. Aina kun projektissa on saatu jokin tuotos valmiiksi, se kannattaa käydä läpi muodollisesti tarkastuksissa. Tarkastukset parantavat tuotteen laatua, sillä aikaisessa vaiheessa löydetty puute tai virhe on helpompi korjata kuin myöhemmin löydettynä. Sivu Tarkastusten luonne Tarkastus on muodollinen tilaisuus, johon osallistuu kolmesta kuuteen henkilöä. Tilaisuudella on tarkka ohjelma ja aikataulu. Henkilöt edustavat eri sidosryhmiä asiakkaasta projektiryhmän jäseniin. Valmistautuessaan tarkastukseen osallistujat analysoivat systemaattisesti tarkastettavaa tuotosta. Tarkastuksessa kootaan löydetyt puutteet ja virheet. Tarkastukseen valmistaudutaan etukäteen. Valmistautumisen helpottamiseksi jokaiselle osallistujalle on jaettu mahdollisia puutekohtia sisältävä tarkistuslista. Sivu

21 Tarkastukseen osallistujat Jokaisella tarkastukseen osallistujalla on rooli, joka kuvaa osallistujan tehtävän tarkastuksessa: Kirjoittaja (Author/owner): Tuotoksesta vastuussa oleva henkilö tai ryhmän edustaja. Omistaja on vastuussa löydettyjen puutteiden ja virheiden korjaamisesta. Tarkastaja (Inspector): Etsii virheitä ja puutteita tuotoksesta. Saattaa myös tunnistaa laajempia asioita, jotka sisältävät tarkastettavan tuotoksen puutteineen. Lukija (Reader): Esittelee tarkastettavan tuotoksen. Sihteeri (Scribe): Kirjaa löydetyt virheet ja puutteet ylös Puheenjohtaja (Moderator): Kutsuu tarkastusryhmän kokoon ja vastaa tarkastustilaisuudessa, että ohjelmaa ja aikataulua seurataan. Sivu Tarkastustapahtuma Itse tarkastustapahtuma ei saa kestää enempää kuin kaksi tuntia. Siinä keskitytään yksinomaan löytämään puutteita ja virheitä. Tarkastukseen osallistujat eivät keskustele löydetyistä puutteista. Kun puute on havaittu, sihteeri kirjaa sen ylös ja siirrytään eteenpäin. Puheenjohtaja on vastuussa siitä, että tarkastus etenee aikataulun mukaan. Puheenjohtaja jakaa puheenvuorot ja keskeyttää mahdolliset analyysi- ja korjauskeskustelut. Sivu

22 Tarkastuksen päätös Kun tarkastus on päättynyt, sihteeri luettelee löydetyt puutteet ja virheet. Tämän jälkeen ryhmä äänestää tuotoksen hyväksymisestä. Vaihtoehdot ovat: Hyväksytään sellaisenaan: mitään muutoksia ei tarvitse tehdä. Hyväksytään muutoksin: löydetyt puutteet ja virheet on korjattava, mutta tuotoksesta ei tarvita enää uutta tarkastusta. Hylätään: löydetyt puutteet ja virheet on korjattava. Korjauksen jälkeen tuotoksesta käydään läpi uusi tarkastus. Tarkastuksen tuloksena sihteeri kirjoittaa tarkastusdokumentin, missä listataan löydetyt puutteet ja virheet ja niiden vakavuudet. Sivu Tarkastusten kultaiset säännöt Seuraavista periaatteista on hyötyä tarkastuksissa: 1. Arvioidaan tuotetta, ei tekijää. 2. Suunnitellaan aikataulu ja pidetään siitä kiinni. 3. Rajoitetaan väittelyä. 4. Ei yritetä ratkoa löydettyjä ongelmia. 5. Rajoitetaan osallistujien määrä 3-6 henkeen. 6. Vaaditaan, että osallistujat ovat valmistautuneet huolellisesti tarkastukseen. 7. Käytetään tarkistuslistoja sekä valmistautuessa että tarkastuksessa. 8. Varataan riittävästi aikaa ja resursseja. 9. Koulutetaan osallistujat. 10. Arvioidaan myös tarkastusprosessia. Sivu

23 7.2. Testaus Toisin kuin yleensä luullaan, testausprosessi alkaa samaan aikaan kun koko ohjelmistotuotantoprosessi. Testausprosessissa seurataan niin sanottua V-mallia. Se selittää testausvaiheet ja niiden suhteen muihin prosessin työvaiheisiin. V-malli yhdistää testauksen ja tuotteen rakentamisen kätevästi toisiinsa. V-mallin vasemmassa sakarassa suunnitellaan testitapaukset, jotka suoritetaan V- mallin oikeassa sakarassa. Jokaisella yrityksellä on oma variaationsa V-mallista. Sivu V-malli Requirements elicitation Requirements analysis System testing Acceptance testing Architecture design Module design Module testing Integration testing Coding Kuvalla (C) J. Paakki 2000 Sivu

24 Testausvaiheet V-mallin mukaisen testausprosessin vaiheet ovat: Yksikkötestaus (module/unit testing): pienimmät jakamattomat yksiköt testataan sitä mukaa kun ne valmistuvat. Oliopohjaisessa suunnittelussa pienin yksikkö on joko olio(luokka) tai metodi. Yksikkötestauksessa keskitytään toteutukseen. Integrointitestaus (integration testing): Ohjelmiston olioluokat kootaan komponenteiksi. Komponentit kootaan osajärjestelmiksi. Osajärjestelmät kootaan koko järjestelmäksi. Integrointitestauksessa keskitytään rajapintoihin. Järjestelmätestaus (system testing): Ohjelmistoa testataan kokonaisena. Testauksessa keskitytään ohjelmiston verifiointiin. Hyväksymistestaus (acceptance testing): Ohjelmistoa testataan osana koko järjestelmää laboratorio-olosuhteissa ja todellisessa ympäristössä. Testauksessa keskitytään ohjelmiston validointiin. Sivu Yksikkötestaus Yksikkötestausta pidetään yleensä toteutuksen osana, mutta siitä huolimatta se on testausta. Yksikkötestauksessa testataan ohjelmiston pienimmät jakamattomat osat ilman muista ohjelmiston osia. Jotta testaus onnistuu, tarvitaan ajureita ja tynkiä Ajuri on koodi, joka ottaa vastaan testiaineiston, muokkaa sen testattavalle elementille sopivaan muotoon, kutsuu testattavaa elementtiä testiaineiston mukaisilla parametreilla ja ottaa vastaan elementin palauttaman tuloksen. Tynkä tekee minimitoteutukset sellaisille testattavan elementin kutsuille, jotka menisivät elementin ulkopuolelle. Esim. metodia testattaessa tyngät korvaavat kutsut muihin metodeihin ja olioihin. Sivu

25 Oliopohjainen yksikkötestaus Oliopohjaisessa yksikkötestauksessa pienin testattava yksikkö on yleensä olio. Myös metodi voi olla pienin testattava yksikkö. Olioa testattaessa testataan kaikki metodit, kaikki tilat, olion paikalliset tietorakenteet ja rajapintojen toteutukset. Jos oliosta on palvelupyyntöjä muihin olioihin, palvelut korvataan tyngillä. Tyngistä tehdään sellaiset, että testattava olio on täysin eristetty muista. Sivu Metodien testaus Jokainen metodi testataan erikseen. Testaukseen kuuluu koodin testaus: kaikki kirjoitettu koodi täytyy käydä läpi, silmukkatestaus: kaikki koodin silmukat käydään läpi, virhetilanteiden testaus: kaikki mahdolliset virhetilanteet generoidaan ja tarkistetaan metodin selviäminen niistä, metodin sisäisten tietorakenteiden testaus: jos metodilla on sisäisiä tietorakenteita, näiden oikea toiminta testataan, Sivu

26 Metodien testaus (jatkuu) Metodin testauslista jatkuu. metodin rajapinnan testaus: testataan parametrien tarpeellisuus, niiden tyyppi, arvojoukot, mahdolliset metodin kutsun alkuehdot ja mahdolliset metodin kutsun loppuehdot; ja metodin reunaehtojen testaus: testataan metodia sellaisilla syötteillä, jotka liittyvät metodin syötteiden arvojoukkojen reunaehtoihin. Esimerkiksi jos metodi ottaa vastaan lukuja , niin testataan arvoilla -1, 0, 1, n<99, 99, 100, 101. Sivu Tilojen testaus Olion tilojen testauksessa on kaksi mahdollisuutta: voidaan testata tiloja erikseen tai tiloja yhdessä. Molemmissa tapauksissa tilat saadaan eristettyä tilasiirtymäkaavioista. Erikseen testattaessa ei testata siirtymiä. Yhdessä testattaessa testataan siirtymien mukaan. Erikseen testattaessa testataan tilaan tulo: tilalla voi olla tehtäviä, jotka tehdään aina tultaessa tilaan. kaikki tulon aktivoivat tapahtumat ja laukaisimet testataan tilasta poistuminen: tilalla voi olla lopetustehtäviä, jotka tehdään poistuttaessa tilasta. Sivu

27 Tilojen testaus (jatkuu) Tilojen testaus jatkuu. tilassa olo: tilaan liittyvät tapahtumat testataan. Jos tiloja testataan yhdessä, testataan tila-siirtymä-tila -ryhmiä kokonaisina. Jokainen ryhmä alkaa alkutilasta ja päättyy lopputilaan. Siinä välissä käydään läpi kaikki välitilat. Tällaisesta alkutilasta lopputilaan menevästä polusta tehdään yksi testitapaus, mikä testataan kokonaisuutena. Sivu Tilatestausten erot Jos tilat testataan yksittäin, testaus on suoraviivaisempaa. Toisaalta tilojen yhteistyö ei selviä. Jos tilat testataan ryhmänä, testauksen suunnittelu vaatii enemmän, sillä on selvitettävä, miten siirtymät tapahtuvat metoditasolla. Toisaalta tulos on yksittäistä testausta kattavampi, sillä myös siirtymät tulevat testattua. Mitä enemmän luokalla on tilaluonnetta, sitä enemmän kannattaa mielestäni testata tiloja ryhminä. Sivu

28 Paikallisten tietorakenteiden testaus Olion paikallisten tietorakenteiden tulee olla käytössä ja toimia odotetulla tavalla. Tarkistuslistaan kuuluvat: tietorakenteiden tyyppien tarkistus, tietorakenteiden alustusoperaatioiden tarkistus, muuttujanimien tarkistus, reunaehtojen tarkistus ja tietorakenteiden käytön rajapintojen testaus. Oliopuolella tietorakenteet voidaan kätevästi eristää muusta ohjelmistosta. Tällöin niiden testaus käy helpommin kuin perinteisellä puolella. Sivu Rajapintojen toteutuksen testaus Rajapintojen toteutuksen testaus on viimeinen yksikkötestauksen vaihe. Siinä testataan, että olion metodit ja attribuutit toimivat yhteistyössä ja toteuttavat olion rajapinnan tarjoamat palvelut. Rajapintojen toteutuksen testauksessa koodilla ei ole merkitystä. Testaus on semanttista. Jos olion tarjoamilla palveluilla on tunnettuja reunaehtoja, arvojoukkoja, alustus- ja lopetusehtoja, niin nämä otetaan huomioon. Muuten toteutuksen rakenne ei vaikuta testaukseen. Sivu

29 Integrointitestaus Integrointitestauksessa testatut pienimmät yksiköt integroidaan suuremmiksi kokonaisuuksiksi. Integrointia voidaan tehdä kahdesta suunnasta: ylhäältä alaspäin tai alhaalta ylöspäin. Ylhäältä alaspäin aloitetaan ohjaavista kokonaisuuksista ja mennään alaspäin kohti toteuttavia kokonaisuuksia. Etuna tässä on, että testattava ohjelmisto on heti valmis suoritettavaksi. Haittana on kasvava tynkien tarve. Alhaalta ylöspäin aloitetaan toteuttavista kokonaisuuksista ja mennään ylöspäin kohti ohjaavia kokonaisuuksia. Etuna tässä on, että tynkiä ei tarvita. Haittana on, että ohjelmisto on valmis suoritettavaksi vasta integroinnin päätyttyä. Sivu Oliopohjainen integrointi Oliopohjainen integrointi on yleensä luonnollista tehdä alhaalta ylöspäin. Ensin oliot integroidaan komponenteiksi. Sitten komponentit integroidaan osajärjestelmiksi. Lopuksi osajärjestelmät integroidaan koko järjestelmäksi. Näin integrointitestaus on kolmivaiheista (tai nelivaiheista, jos vielä integroidaan metodit olioiksi). Jokainen vaihe on erillinen kokonaisuus. Kaikilla integrointitestausten tasoilla testataan rajapintoja. Rajapintojen toteutus on jo testattu yksikkötestauksessa. Sivu

30 Rajapintojen testaus Rajapintojen testauksessa testataan: Parametrien lukumäärää Kaikilla tarvittavilla parametreilla täytyy olla merkitystä kutsujalle. Kaikilla palautetuilla arvoilla täytyy olla merkitystä kutsujalle. Parametrien tyyppiä Tyyppien ja arvojoukkojen täytyy olla samat kutsujalle ja palvelun tarjoajalle. Palvelua Palvelun semantiikka testataan kutsujan kannalta. Palvelun tarjoajan kannalta semantiikka on tarkistettu yksikkötestauksessa. Alku- ja loppuehtoja Jos palvelulla on alku- ja/tai loppuehdot, nämä testataan. Sivu Järjestelmätestaus Integrointitestauksesta seuraava työvaihe on järjestelmätestaus. Siinä järjestelmä testataan kokonaisuutena. Kokonaisuuteen kuuluvat ohjelmisto, laitteisto ja muut ohjelmiston kanssa yhteistyössä toimivat ohjelmistot. Järjestelmätestauksessa oletetaan, että ohjelmisto on testattu syntaktisesti. Ohjelmakoodi ei ole enää näkyvissä, vaan testauksessa keskitytään toiminnallisten ja ei-toiminnallisten vaatimusten validointiin. Sivu

31 Hyväksymistestaus Hyväksymistestaus on viimeinen testausvaihe. Siinä loppukäyttäjät testaavat ohjelmistoa ensin valvotusti laboratorio-olosuhteissa (alfa-testaus) ja sitten valvomatta lopullisessa käytössä (beta-testaus). Sekä alfa- että beta-testauksessa testaavat loppukäyttäjät kirjaavat ylös kaikki löytämänsä puutteet. Hyvässä ohjelmistossa löydetyt puutteet liittyvät toiminnallisuuteen. Perinteisiä virheitä (ohjelman kaatumista, vääriä tulosteita jne.) ei pitäisi löytyä. Sivu Testausmenetelmät Testausmenetelmät voidaan jakaa kahteen luokkaan: lasilaatikkotestaukseen (white-box testing) ja mustalaatikkotestaukseen (black-box testing). Lasilaatikkotestaus testaa enemmän syntaksia kuin semantiikkaa. Mustalaatikkotestaus testaa enemmän semantiikkaa kuin syntaksia. Lasilaatikkotestausta käytetään yksikkö- ja integrointitestauksessa. Mustalaatikkotestausta käytetään kaikilla testaustasoilla, mutta erityisesti järjestelmä- ja hyväksymistestauksessa. Sivu

32 Lasilaatikkotestaus Lasilaatikkotestauksessa testattavan yksikön koodi on näkyvissä. Koodia käytetään hyväksi testitapauksia suunniteltaessa. Testauksessa testataan ohjelman rakennetta. Testattaviin osiin kuuluvat esimerkiksi polut, ehdot, silmukat, parametrit ja muuttujat. Koska lasilaatikkotestauksessa koodi on näkyvissä, testausta voidaan systematisoida ja automatisoida kätevästi. Lasilaatikkotestauksen teoria onkin hyvin hallittua ja matemaattiseen formalismiin perustuvaa teoriaa. Sivu Polkutestaus Polkutestauksessa testataan yleensä yhtä metodia, mutta samaa menetelmää voidaan käyttää laajemmassakin mittakaavassa. Yksinkertaisuuden vuoksi puhun jatkossa vain metoditason polkutestauksesta. Jokainen metodi voidaan kuvata suunnattuna verkkona, jossa on yksi lähtösolmu ja yksi maalisolmu. Lähtösolmu kuvaa metodin alkupistettä, eli metodin parametrien alustusta. Maalisolmu kuvaa pistettä, jossa metodista poistutaan ja palautetaan metodin laskema tulos, siis metodin loppupistettä. Sivu

33 Suunnattu verkko Suunnatun verkon jokainen solmu kuvaa yhtä metodin lausetta, ja jokainen särmä kuvaa siirtymää lauseesta toiseen. Jos lause on ehtolause, siitä lähtee kaksi särmää (trueja false-vaihtoehdot). Jos lause on case-lause, siitä lähtee yhtä monta särmää kuin on case-vaihtoehtoja (ja yksi särmä vaihtoehdolle, että yksikään case-vaihtoehto ei sovi). Jos lause on return-lause, siitä lähtee särmä lopputilaan. Sivu Polut Kun suunnattu verkko on valmis, siitä voidaan johtaa polkuja. Jokainen polku alkaa lähtösolmusta ja päättyy maalisolmuun. Kukin polku kuvaa yhtä tapaa käydä metodi läpi. Kun kehitämme metodille testiaineiston, joka vastaa polun läpikäyntiä, saamme kyseisen polun testattua. Jo aika yksinkertaisissa metodeissa kaikkien polkujen määrä kasvaa niin suureksi, että maailmankaikkeuden jäljellä oleva ikä ei riitä niiden testaamiseen. Siksi on kehitetty yksinkertaistuksia, joissa kaikkien polkujen joukosta valitaan muutama mielenkiintoinen. Sivu

34 Kattavuudet Valittavat polut määrittelevät kattavuuskriteerin. Se kertoo, millä perusteella polut valitaan. Kattavuus puolestaan kertoo, miten hyvin suoritetut testit täyttävät kattavuuskriteerin. Esim. jos kattavuuskriteerinä ovat kaikki polut, ja polkuja on 100, Niin yhden testin suoritus antaa kattavuudeksi 1/100 eli 1%. Yksinkertaisin kattavuus on lausekattavuus. Siinä kriteerinä ovat kaikki verkon solmut (eli lauseet). Toinen usein käytetty kattavuus on haaraumakattavuus. Siinä kriteerinä ovat kaikki verkon särmät (eli siirtymät lauseesta toiseen). Sivu Silmukkatestaus Silmukkatestauksessa testataan nimensä mukaisesti silmukoita. Testit vaihtelevat silmukan tyypin mukaan: Yksinkertaiset silmukat. Silmukka suoritetaan 0 - n kertaa, missä m voi vaihdella väliltä 0..N ja N on jokin tunnettu maksimiarvo (tai ääretön, jos arvoa ei tunneta). Oleellista on, että n voi vaihdella. Silmukalle tehdään seuraavat testit: 1. 0 iteraatiokierrosta iteraatiokierros iteraatiokierrosta. 4. m iteraatiokierrosta 2 < m < N N-1, N ja N+1 iteraatiokierrosta. Sivu

35 Silmukkatestaus (jatkuu) Sisäkkäiset silmukat. Näille silmukoille ei voida tehdä yhtä kattavaa testausta kuin yksinkertaisille silmukoille, koska testien määrä kasvaa silmukoiden lukumäärän suhteen eksponentiaalisesti. Seuraavalla testillä päästään kattavaan tulokseen vähemmillä testeillä: 1. Aloitetaan sisimmästä silmukasta. Asetetaan muut silmukat minimiarvoihin 2. Suoritetaan sisimmälle silmukalle yksinkertaisen silmukan testit. Pidetän muut silmukat vakioina. Testataan mahdolliset yli- ja alivuodot. 3. Siirrytään silmukka kerrallaan ulospäin. Jo testatuille silmukoille asetetaan järkevät arvot. Testaamattomat silmukat pidetään vakioarvoissa. 4. Jatketaan kunnes kaikki silmukat on testattu. Sivu Silmukkatestaus (jatkuu) Peräkkäiset silmukat. Toisistaan riippumattomille peräkkäisille silmukoille voidaan soveltaa erikseen yksittäisten silmukoiden testausperiaatetta. Toisistaan riippuvien silmukoiden testauksessa käytetään sisäkkäisten silmukoiden testaustapaa. Kiinteät silmukat. Jos silmukan alku- ja loppuarvot ovat vakioita eli silmukka suoritetaan aina yhtä monta kertaa, niin silmukkaa voidaan pitää lyhennettynä muotona koodista, missä silmukassa suoritettavat lauseet ovat peräkkäin. Tällaisille silmukoille riittää silmukkatestauksessa yksi testitapaus. Rakenteettomat silmukat. Nämä silmukat eivät seuraa rakenteista ohjelmointia. Jotta ne voidaan testata systemaattisesti, ne täytyy ensin kirjoittaa uudelleen yksinkertaisiksi, sisäkkäisiksi, kiinteiksi tai peräkkäisiksi silmukoiksi. Onneksi tällaisia silmukoita ei enää tule juurikaan vastaan. Sivu

36 Mustalaatikkotestaus Mustalaatikkotestauksessa ohjelman koodi ei ole näkyvissä. Ohjelmasta tiedetään vain, mitä se ottaa syötteenä, antaa tuloksena, ja mitä se tekee. Mustalaatikkotestauksessa pyritään löytämään virheellisiä tai puuttuvia toimintoja, sisäisiin, ulkoisiin tai käyttöliittymään liittyviä virheitä, virheitä yleisissä tietorakenteissa, suorituskykypuutteita ja alustus- ja lopetustoimintojen virheitä. Toiminnallisen testauksen aineisto voidaan johtaa järjestelmän kuvauksista. Sivu Ekvivalenssiluokat Mustalaatiikotestauksessa syöteavaruus ositetaan ekvivalenssiluokiksi. Yksi luokka kuvaa toiminnallisuuden osajoukkoa, jolle voidaan tehdä yhteisiä testejä. Ekvivalenssiluokat voidaan johtaa esimerkiksi ohjelmiston kuvauksista, arkkitehtuurista, käyttäjän vaatimuksista tai järjestelmävaatimuksista. Yhdestä ekvivalenssiluokasta valitaan muutama testitapaus. Yhdessä kaikki testitapaukset muodostavat optimitapauksessa kattavan testiaineiston. Sivu

37 8. Yhteenveto Ohjelmistotuotanto jakaantuu selkeästi seuraaviin osa-alueisiin: projektin perustamiseen, ongelman määrittelyyn, ohjelmistosuunnitteluun, toteutukseen, testaukseen ja ylläpitoon. Nämä osa-alueet muodostavat myös ohjelmistotuotantoprosessin päätehtävät. Tehtäviä ei välttämättä suoriteta tässä järjestyksessä eikä edes peräkkäin. Ohjelmistotuotannossa on tilaa erilaisille prosesseille ja prosessimalleille. Kuitenkin nämä osaalueet ovat aina läsnä kaikissa malleissa. Sivu Projektin suunnittelu - älä aliarvioi Vaikka jokainen osa-alue on tärkeä, niistä kaikkein tärkeimmäksi nostaisin projektin sunnittelun (sattumoisin se vei myös eniten luentoaikaa). Suunnittelu ei ala tuotteesta, vaan prosessista. Ilman tarkkaa suunnitelmaa ei synny laadukasta tuotetta. Tämä osa-alue on varsinkin oppilasprojekteissa pahiten retuperällä. Ennen ensimmäistäkään vaatimusanalyysin osavaihetta pyrkikää siihen, että teillä on selvä ja realistinen aikataulusuunnitelma, jota seurataan. Sivu

38 Aikataulun realistisuus Realistisuus on avainsana aikataulussa. On tuhat kertaa parempi saada aikaan pieni laadukas ohjelmisto, kuin tehdä iso ohjelmisto, joka on vain vähän sinne päin. Kun aikataulu on realistinen, työskentely on miellyttävämpää, tulokset ovat parempia ja työ valmistuu ajallaan. Siitä se alkaa ja siihen se päättyy: hyvästä projektin suunnittelusta. Se pitää omaksua selkäytimeen. Loput asiat voi kerrata vaikkapa tästä luentomonisteesta ja oppikirjasta. Sivu Loppu Kiitokset yhteistyöstä! Sivu