6. Suunnittelu. Suunnitteluprosessi

Samankaltaiset tiedostot
Ohjelmistotuotanto, suunnittelu Syksy Suunnittelu. Suunnittelun tulos. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi.

6. Suunnittelu. Suunnittelun tulos

Suunnittelun tulos. 6. Suunnittelu. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi. 6.1 Arkkitehtuurisuunnittelu.

Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II

7. Verifiointi ja validointi

Ohjelmistotuotanto, verifiointi ja validointi Syksy Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi

Ohjelmistojen suunnittelu

Harjoitustyön testaus. Juha Taina

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:

Kontrollipolkujen määrä

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Testausraportti. Oppimistavoitteiden hallintajärjestelmä harri

2. Ohjelmistotuotantoprosessi

Suunnitteluvaihe prosessissa

Ohjelmistotuotantoprojekti

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

5. Järjestelmämallit. Mallinnus

Testaussuunnitelma Labra

Prosessimalli. 2. Ohjelmistotuotantoprosessi. Prosessimallin vaihejako. Prosessimallien perustehtävät. Ohjelmiston suunnittelu. Vaatimusmäärittely

Ohjelmiston testaus ja laatu. Testaustasot

Testaaminen ohjelmiston kehitysprosessin aikana

Mallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005

Ohjelmistotuotanto s

Convergence of messaging

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

58160 Ohjelmoinnin harjoitustyö

Ohjelmistotuotanto, prosessit Syksy Ohjelmistotuotantoprosessi. Prosessimalli. Prosessimallien perustehtävät. Prosessimallin vaihejako

Laadunvarmistustekniikat

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }

Testaussuunnitelma. Oppimistavoitteiden hallintajärjestelmä harri

Ohjelmiston testaus ja laatu. Testausmenetelmiä

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

10. Tarkastukset. Tarkastusten rakenne

Tarkastusten rakenne. 10. Tarkastukset. Tuotoksen tekijän rooli. Tarkastustiimi. Tarkastusprosessin vaiheet. Tarkastusprosessi

Testaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Tietojärjestelmän osat

1. Johdanto. Ohjelmistotuotannon ongelmia

Testaustyökalut. Luento 11 Antti-Pekka Tuovinen. Faculty of Science Department of Computer Science

ELM GROUP 04. Teemu Laakso Henrik Talarmo

Verifiointi ja validointi

Testaussuunnitelma. Asdf. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Juha Taina, Marko Salmenkivi ja Kjell Lemström,

Testaussuunnitelma. Karstula. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testausprosessin vaatimukset. 2. Testausprosessi (Artikkelit) Vesiputousmallin ongelmia. V-mallin neljä osavaihetta. Testausprosessimalli V-malli

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

1. Johdanto. Ohjelmistotuotannon piirteitä. Ohjelmisto ja järjestelmä. Osajärjestelmät ja käyttäjät. Järjestelmän ja ohjelmiston laadinta

UCOT-Sovellusprojekti. Testausraportti

Dynaaminen analyysi IV

Ohjelmistojen mallintaminen, mallintaminen ja UML

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä

ITKP102 Ohjelmointi 1 (6 op)

Ohjelmiston testaussuunnitelma

Ohjelmiston toteutussuunnitelma

Dynaaminen analyysi III

Testaussuunnitelma. Ohjelmistotuotantoprojekti Nero. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Dynaaminen analyysi IV Luento 6 Antti-Pekka Tuovinen

1. Johdanto. Ohjelmistotuotannon piirteitä

12. Javan toistorakenteet 12.1

Test-Driven Development

Dynaaminen analyysi III Luento 5 Antti-Pekka Tuovinen

12. Javan toistorakenteet 12.1

11. Javan toistorakenteet 11.1

1. Johdanto. Ohjelmistotuotannon piirteitä

812341A Olio-ohjelmointi Peruskäsitteet jatkoa

Dynaaminen analyysi I

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0

Lohtu-projekti. Testaussuunnitelma

SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1

Rajapinnasta ei voida muodostaa olioita. Voidaan käyttää tunnuksen tyyppinä. Rajapinta on kuitenkin abstraktia luokkaa selvästi abstraktimpi tyyppi.

UML -mallinnus TILAKAAVIO

13/20: Kierrätys kannattaa koodaamisessakin

Test-Driven Development

Onnistunut Vaatimuspohjainen Testaus

1. Johdanto. Ohjelmistotuotannon piirteitä. Ohjelmisto ja järjestelmä. Osajärjestelmät ja käyttäjät. Järjestelmän ja ohjelmiston laadinta

Ohjelmistotekniikan menetelmät, toteutuksesta ja testauksesta

Dynaaminen analyysi II

Algoritmit 1. Luento 3 Ti Timo Männikkö

TIE Tietorakenteet ja algoritmit 1. TIE Tietorakenteet ja algoritmit

11/20: Konepelti auki

Testaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza

Uudelleenkäytön jako kahteen

Sisällys. JAVA-OHJELMOINTI Osa 7: Abstrakti luokka ja rajapinta. Abstraktin luokan idea. Abstrakti luokka ja metodi. Esimerkki

1. Johdanto. Ohjelmistotuotannon piirteitä

Määrittelydokumentti NJC2. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

UML- mallinnus: Tilakaavio

JReleaser Yksikkötestaus ja JUnit. Mikko Mäkelä

Sisällys. 12. Javan toistorakenteet. Yleistä. Laskurimuuttujat

Projektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

3. Testaus osana ohjelmistoprosessia

Menetelmäraportti Ohjelmakoodin tarkastaminen

Katselmoinnit. review) Katselmoinnit (review( Mitä ovat katselmoinnit? Katselmoinnin määritelmä (IEEE 1988)

Transkriptio:

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 - 127 - 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 - 128-1

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 - 129-6.1 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 - 130-2

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 - 131 - 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 - 132-3

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 - 133 - 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 - 134-4

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 - 135-6.2 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 - 136-5

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 - 137 - 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 - 138-6

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 - 139 - 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 - 140-7

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 0..200, 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 - 141 - 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 - 142-8

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 - 143-6.4. 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 - 144-9

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 - 145 - 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 - 146-10

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 - 147-6.6. 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 - 148-11

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 - 149 - 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 - 150-12

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 - 151-6.8. 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 - 152-13

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 - 153 - 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 - 154-14

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 - 155 - 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 - 156-15

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 - 157 - 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 - 158-16

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 - 159 - Suunnittelumalliesimerkki (jatkuu) C D B A 50 25 0 A B C D Subject Observer 1 A: 40 B: 25 C: 15 D: 20 Observer 2 Kuvalla (C) I. Sommerville 2000 Sivu - 160-17

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 - 161 - 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 - 162-18

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 - 163 - 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 - 164-19

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 - 165 - 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 - 166-20

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 - 167 - 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 - 168-21

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 - 169 - 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 - 170-22

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 - 171 - 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 - 172-23

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 - 173 - 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 - 174-24

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 - 175 - 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 - 176-25

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 0..100, niin testataan arvoilla -1, 0, 1, n<99, 99, 100, 101. Sivu - 177 - 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 - 178-26

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 - 179 - 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 - 180-27

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 - 181 - 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 - 182-28

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 - 183 - 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 - 184-29

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 - 185 - 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 - 186-30

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 - 187-7.3. 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 - 188-31

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 - 189 - 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 - 190-32

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 - 191 - 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 - 192-33

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 - 193 - 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. 2. 1 iteraatiokierros. 3. 2 iteraatiokierrosta. 4. m iteraatiokierrosta 2 < m < N-1. 5. N-1, N ja N+1 iteraatiokierrosta. Sivu - 194-34

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 - 195 - 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 - 196-35

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 - 197 - 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 - 198-36

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 - 199 - 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 - 200-37

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 - 201 - Loppu Kiitokset yhteistyöstä! Sivu - 202-38