Mallien ja järjestelmien oikeellisuuden toteaminen

Transkriptio

1 Mallien ja järjestelmien oikeellisuuden toteaminen Elena Pirinen Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Tietojenkäsittelytieteen laitos Elena Pirinen Työn nimi Arbetets titel Title Mallien ja järjestelmien oikeellisuuden toteaminen Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Seminaari Tiivistelmä Referat Abstract Aika Datum Month and year Sivumäärä Sidoantal Number of pages 21 Perinteisessä mielessä järjestelmän oikeellisuuden toteaminen on tarkoittanut implementoinnin, toteutuksen, oikeellisuuden tarkistamista. Tätä on tehty validoimalla ja verifioimalla järjestelmää. Mallipohjaisessa ohjelmistotuotannossa, jossa mallit tehdään ennen toteutusta, tulisi myös mallien oikeellisuus varmistaa mahdollisimman aikaisessa vaiheessa. On ajateltu, että perinteiset validoinnin ja verifioinnin tekniikat, kuten staattinen analyysi ja dynaaminen testaus sopivat myös mallien oikeellisuuden toteamiseen. Osittain näin voidaankin tehdä, esimerkiksi katselmoinneilla voidaan todeta mallien oikeellisuus. Kuitenkaan malleja ei voida suoraan suorittaa (dynaamisten) testien ajamiseksi. Automaattinen mallien validointi ja verifiointi ei ole tällä hetkellä mahdollista. Implementoinnin validointiin ja verifiointiin on olemassa työkaluja, mutta niiden syötekielenä on ohjelmakoodia, ei abstrakteja malleja. Näistä johtuen mallit tulee ensin transformoida alaspäin tasolle, jota voidaan formaalisti käsitellä. Nykyisin se tarkoittaa alimmalle abstraktiotasolle ja siitä ajettavaksi ohjelmakoodiksi. Kun alemman abstraktiotason semantiikka on aina yhteneväistä ylemmän kanssa, voidaan testejä ajamalla ja validoinnin sekä verifioinnin työkaluilla todeta myös mallien oikeellisuus. Jotta mallien transformoinnit, validoinnit ja verifioinnit voitaisiin suorittaa automaattisesti, tulisi mallien olla formaaleja ja keskenään yhteensopivia. Tällä hetkellä ei kuitenkaan ole riittävää standardia formaalien mallien muodostamiseksi, eivätkä mallinnustyökaluilla tehdyt mallit ole välttämättä keskenään yhteensopivia. Malleja ja implementointeja ei myöskään ole mahdollista tällä hetkellä verrata keskenään, onko lopputulos sellainen, kuin ajateltiin. Ei ole ohjelmistoja, jotka vertaisivat kahdella eri abstraktiotasolla olevaa kuvausta järjestelmästä toisiinsa ja suorittaisivat vertailevaa verifiointia ja validointia. ACM Computing Classification System (CCS): D.2 [Software Engineering] Avainsanat Nyckelord Keywords Model transformation, MDA, MDE, Testing of object-oriented systems Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information

3 Sisältö 1 Johdanto Malliperustainen ohjelmistotuotanto Malliperustaisen ohjelmistotuotannon tavoitteet ja hyödyt Abstraktiotasot ja näkökulmat Mallimuunnokset eri kohteiksi Oikeellisuuden toteaminen Ohjelmiston ominaisuudet Validointi Verifiointi Staattinen analyysi Dynaaminen testaus Testausprosessi ja testausstrategia Testivaatimukset, testaussuunnitelma ja testitapaukset Oikeellisuuden toteaminen mallipohjaisessa ohjelmistotuotannossa Mallien semantiikka Mallien muuntaminen sopivalle abstraktiotasolle Työkalujen valinta Verifiointi mallipohjaisessa ohjelmistotuotannossa Verifiointi Web services -ympäristössä Staattinen analyysi Mallipohjainen (dynaaminen) testaus Yhteenveto... 18

4 1 1 Johdanto Malliperustainen ohjelmistotuotanto (engl. model-driven engineering, MDE) on ohjelmistokehityksen menetelmä, jossa apuvälineinä käytetään malleja. Malli on jonkin järjestelmän kuvaus; järjestelmä voi olla fyysinen, digitaalinen, abstrakti tai esimerkiksi sosiaalinen järjestelmä, tällöin kuvaus on ontologiaa. Mallien perusteella voidaan tuottaa toisia malleja, tekstiä tai ohjelmistoja. Tarkoituksena on nostaa abstraktiotasoa tietokonelähtöisestä lähdekoodin näkökulmasta sovelluslähtöisempään näkökulmaan sekä automatisoida osaa tietojärjestelmäkehityksestä [SeKo03] [Sch06]. Mallien sekä niiden pohjalta tehtyjen toteutusten oikeellisuuden toteaminen tarkoittaa niiden verifioimista ja validoimista. Täyttääkö tuotos tarpeen, johon se on suunniteltu, onko se vaatimusten mukainen, ja toisaalta toimiiko tuotos oikein, virheettä. Perinteisesti ohjelmakoodia voidaan verrata vaatimusmäärittelyyn ja toisaalta suorittaa ajamalla testitapauksia ja siten saada implementointi verifioitua sekä validoitua. Mallien osalta tilanne on toinen. Mallit tulee transformoida alimmalle abstraktiotasolle, jotta niistä saataisiin suoritettavaa koodia, jota voidaan ajaa. Alemman abstraktiotason mallin on oltava semanttisesti yhteneväinen ylemmän mallin kanssa. Näin voidaan ajaa malleja kuin implementointia ja suorittaa verifiointia sekä validointia. Tähän ei kuitenkaan vielä ole työkaluja. Malleja voitaisiin hyödyntää myös testivaatimuksien ja testitapauksien luomisen automatisoimiseksi, mikäli mallit saadaan tietokoneen ymmärtämään muotoon. Tämä seminaarityö on osa Helsingin yliopiston matemaattis-luonnontieteellisen tiedekunnan tietojenkäsittelytieteen laitoksen Malliperustainen ohjelmistotuotanto - seminaaria. Seminaarityössä tarkastellaan ensin lyhyesti mallipohjaista ohjelmistotuotantoa yleensä, oikeellisuuden toteamiseen liittyviä piirteitä. Tämän jälkeen selvitetään, mitä tarkoittaa oikeellisuuden toteaminen perinteisessä mielessä, jolloin tarkastellaan implementoinnin oikeellisuutta. Samat käsitteet viedään sitten mallipohjaisen ohjelmistotuotannon oikeellisuuden toteamiseen, ja tutkitaan mitä eroja on edelliseen verrattuna. Seminaarityössä tarkastellaan mitä ratkaisuja on tällä hetkellä tarjolla mallien verifioimiseksi ja validoimiseksi sekä niiden automatisoimiseksi, ja kuinka malleista voidaan automaattisesti tuottaa testivaatimuksia ja testitapauksia.

5 2 2 Malliperustainen ohjelmistotuotanto Malliperustainen ohjelmistotuotanto (engl. model-driven engineering, MDE) on nostanut ohjelmistokehityksen abstraktiotasoa ohjelmointikieliin verrattuna. Aluksi ohjelmistokehityksessä käytettiin ohjelmointikieliä, toimittiin hyvin tietokonelähtöisesti. Sitten avuksi tulivat CASE-välineet, jotka automaattisesti tekivät esimerkiksi luokkakaavioista tietokannan taulujen luontilauseet. Malliperustaisessa ohjelmistotuotannossa tehdään ensin mallit, sovelluskohtaista sanastoa käyttäen, ja mallien perusteella tuotetaan ohjelmistot. Malli on kuvaus, joka on kuvattavaa kohdetta yksinkertaisempi, mutta joka säilyttää mahdollisimman hyvin mallinnettavan kohteen tarkasteltavat ominaisuudet. Hyvä malli on kompakti, hallittavan kokoinen, ennustava, semanttisesti mielekäs ja riittävän yleinen [PeYo08]. 2.1 Malliperustaisen ohjelmistotuotannon tavoitteet ja hyödyt Malliperustainen ohjelmistotuotanto tehostaa määrittely- ja suunnittelutyötä. Sanastona käytetään kunkin organisaation liiketoimintasanastoa, jolloin tarvittavan henkilöstön saaminen mukaan kehitystyöhön ei vaadi sanastollista erityisosaamista. MDE helpottaa myös toteutusvaihetta. Koodia voidaan generoida automaattisesti ja toistuvat tehtävät voidaan automatisoida. MDE:n avulla ohjelmistokehitystyössä voidaan käyttää uudelleen haluttuja osa-alueita, sillä järjestelmää voidaan tarkastella eri aspekteista eli näkökulmista. Esimerkiksi turvallisuusaspekti tai tehokkuusaspekti voidaan ottaa mukaan myöhemmin toisiin järjestelmiin. Tämä tukee lisäksi siirrettävyyttä, jolla voidaan myös saavuttaa liiketoimintaetua MDE:ssä. Järjestelmistä tulee yleiskäyttöisempiä ja tehokkaampia. Parhaat käytännöt dokumentoidaan, jolloin myös niitä voidaan hyödyntää myöhemmissä järjestelmähankkeissa.

6 3 2.2 Abstraktiotasot ja näkökulmat Malliperustaisessa ohjelmistotuotannossa järjestelmiä käsitellään monesta eri abstraktiosta ja näkökulmasta. Eri abstraktiotasojen mallit kuvaavat kohdetta eri tarkkuuksilla, enemmän tai vähemmän yksityiskohtaisesti, eri näkökulmat kuvaavat kohdetta tietyn abstraktiotason kautta [SeK03]. OMG:n (Object Management Group) MOF (meta object facility) -standardin mukainen nelikerrosarkkitehtuuri [OMG09] sisältää meta-metamallit (MOF), metamallit (UML), mallit (luokkakaaviot) ja datan (konkreettiset objektit). OMG:n MOF -standardin mukaan abstraktiotasoja on kolme [OMG09] CIM (Computation Independent Model) tarkastelee organisaation toimintaa, PIM:ssä (Platform Independent Model) viedään SIM:n käsitteet yhtä tasoa alemmas, puhutaan esimerkiksi orkestroinneista, koreografioista sekä rooleista ja PSM (Platform Spesific Model) vie PIM-tason käsitteet johonkin tiettyyn teknologiaan. 2.3 Mallimuunnokset eri kohteiksi Mallista voidaan muuntaa toinen malli, jolloin käytetään metatason hierarkiaa transformaatioiden tekemiseen. Malli voidaan muuntaa myös tekstiin. Tästä on esimerkkinä kaavaimet, joissa tulostekielen, esimerkiksi HTML, väliin laitetaan proseduraalisia osia, esimerkiksi PHP-ohjelmointikielellä. Mallien kudonnassa määritellään vastaavuuksia kahden eri mallin välille. Tällöin malleja voidaan sulauttaa ja sitoa toisiinsa, ja niiden välille voidaan määritellä yhteistoimintaa.

7 4 Eriasteisia mallitransformaatioita tarvitaan mallien hallitsemiseksi ja käsittelyn automatisoimiseksi, esimerkiksi mikäli kaikki sovellusalueen mallit liittyvät toisiinsa [SeK03]. 3 Oikeellisuuden toteaminen Perinteisesti oikeellisuuden toteaminen on tarkoittanut implementoinnin, toteutuksen, oikeellisuuden arvioimista ja varmistamista. Järjestelmäprojektin tuloksia voidaan tarkastella monesta eri näkökulmasta koko yrityksen toiminnan, yksittäisen projektin ja jopa yksittäisen vaihetuotteen kannalta [HaMä98]. Tuloksen oikeellisuutta tarkastellaan validoimalla ja verifioimalla. 3.1 Ohjelmiston ominaisuudet Ohjelmistolla on joukko kirjattuja ominaisuuksia, joita myös varmennetaan verifioinnilla ja validoinnilla. Ominaisuuksia voivat olla esimerkiksi luotettavuus (engl. dependability), viive (engl. latency), käytettävyys (engl. usability), läpäisykyky (engl. throughput), ylläpidettävyys (engl. maintainability), uudelleenkäytettävyys (engl. reusability), testattavuus (engl. testability) ja seurattavuus (engl. traceability) [PeYo08]. Ominaisuuksille määritellään halutut arvot, joita voidaan myös testausprosessin kuluessa vaihdella. 3.2 Validointi Ohjelmiston validointi vastaa kysymykseen: 'Are we doing the right product?', siinä tarkastellaan täyttääkö tuote asiakkaan sille asettamat todelliset tarpeet, onko ohjelmisto sitä mitä haluttiin. Mietitään mikä on tehtävä, johon ohjelma on valittu ja täyttääkö ohjelma tuon tehtävän [PeYo08]. 3.3 Verifiointi Verifioinnissa puolestaan kysytään: 'Are we doing the product right?', jolloin tarkastetaan vastaako tehtävä ohjelmisto sille tehtyä määrittelyä, toteutuvatko kirjatut vaatimukset ja onko tuote vaatimusten mukainen [PeYo08]. Verifionti vaatii hyvin

8 5 yksityiskohtaista analyysiä spesifikaatiosta ja ohjelmistosta, joten se on usein aikaa vievää ja kallista [So04]. Verifiointiin on kehitetty työkaluja, joilla pyritään automatisoimaan ja helpottamaan manuaalisia tehtäviä. Verifiointiin ja validointiin on olemassa lukuisia tekniikoita, jotka pääosin luokitellaan kahteen ryhmään: staattinen analyysi ja (dynaaminen) testaus. 3.4 Staattinen analyysi Staattinen analyysi on yleisnimi sellaisille verifiointi- ja validointitekniikoille, jotka eivät vaadi ohjelmakoodin suoritusta. Se sopii suoritettavaksi alkuvaiheessa ohjelmistonkehitysprosessia, kun on olemassa jokin malli, mitä voidaan testata. Yksi staattinen analyysitekniikka ovat tarkastukset (engl. inspections). Se on erinomainen, mutta aikaa vievä ja kallis tekniikka [PeYo08]. 3.5 Dynaaminen testaus Dynaaminen testaus tarkoittaa verifiointi- ja validointitekniikoita, jossa ohjelmaa tai sen osaa suoritetaan tietyllä syötteellä ja saadut tulokset analysoidaan. Tällöin löydetään sellaisia virheitä, joita ihminen ei pysty laskemaan. Tekniikkaa käytetään, kun hallittava kokonaisuus on hankala tai kun järjestelmä on deterministinen. Mikäli järjestelmä on epädeterministinen eli riippuu ympäristöstään vahvasti, on staattinen analyysi parempi tekniikka [PeYo08]. Dynaamisella testauksella löydettävät virheet ovat pienempiä, mutta kokonaisuus saattaa olla hankala hahmottaa. Yleisesti ottaen dynaaminen testaus sopii virheiden etsintään, staattinen analyysi puolestaan ominaisuuksien varmentamiseen [PeYo08]. 3.6 Testausprosessi ja testausstrategia Pöri esittää väitöskirjassaan [Pö08, s. 3-5], että ohjelmiston testaus suoritetaan testausprosessin kautta laatusuunnitelman ja siitä johdetun testausstrategian pohjalta. Järjestelmälle laaditaan testausstrategia, jossa kuvataan laatutavoitteet sekä tavat mitata niiden toteutumista. Laatutavoitteet määritellään usein laatuattribuutteina, jossa ominaisuuksille on määrätty vaaditut arvot [PeYo08]. Testausstrategiassa kuvataan myös laadun varmistuksessa tarvittavat dokumentit ja käytettävät työkalut.

9 6 Kuva 1: Laatusuunnitelma, testausstrategia ja testausprosessi [Pö08] 3.7 Testivaatimukset, testaussuunnitelma ja testitapaukset Testausstrategian pohjalta tehdään testivaatimukset, testaussuunnitelma ja siihen liitetään testitapaukset.

10 7 Testauksessa on noudatettava seuraavia vaatimuksia: Vaatimus 2.4.1: Ohjelmistoa tulee voida demonstroida RITA-työkalulla. Vaatimus 2.4.2: Ohjelmisto testaus tulee toteuttaa JUnit-työkalulla. Vaatimus 2.4.3: Arkkitehtuuri toteutetaan niin, että samaa testikoodia on mahdollista käyttää eri sovelluksille. Vaatimus 2.4.4: Yksikkö- ja integraatiotestit erotetaan toisistaan sekä nimetään selkeästi. Vaatimus 2.4.5: Kaikki konfiguraatiot ovat testattavissa; myös eri sovelluksien komponentteja yhdistämällä tehdyt sovellukset tulee voida testata. Vaatimus 2.4.6: Ohjelmistolle toteutetaan testitapauksia, joissa kerrosarkkitehtuuria käydään läpi siten, että kaikki kerrokset tulevat testattua. Vaatimus 2.4.7: Testit ryhmitellään testijoukoiksi (test suite) eri ominaisuuksien mukaan. Kuva 2: Esimerkki testivaatimuksista [AnKi04] Testitapaukset suunnitellaan täyttämään yhden tai useamman testivaatimuksen. Testitapaus sisältää [PeYo08] joukon syötteitä, suoritusehdot (esimerkiksi muuttujien arvot testin alussa) ja hyväksymisehdon (mikä on testitapauksen hyväksyttävä lopputulos, menikö testi läpi). Testaussuunnitelmaan voidaan liittää testioraakkeli, joka kertoo, mikä testin tulos pitäisi olla. Testioraakkeli voi olla esimerkiksi uuden ohjelman edellinen ohjelmaversio, jota ajettaessa saadaan selville, mikä tulos uudella ohjelmalla pitäisi saada. Testioraakkeli voi olla myös käyttäjä, tai kullekin testitapaukselle määritellyt pre- ja postehdot, jotka on oltava voimassa.

11 8 4 Oikeellisuuden toteaminen mallipohjaisessa ohjelmistotuotannossa Mallipohjaisen ohjelmistotuotannon systeemitestauksesta ei ole vielä paljoa tutkimustietoa [BrLa02]. On ajateltu, että olemassa olevat lähestymistavat testaukseen pätevät niin perinteisiin kuin mallipohjaisiin systeemeihin. Kuitenkin, kuten luvussa 3 todettiin, testaustekniikat ovat perinteisesti olleet implementointilähtöisiä systeemitestauksia, kun mallipohjaisessa ohjelmistotuotannossa myös mallit sekä mallien suhde tuotokseen tulee testata [BrLa02]. Malleista pyritään verifiointia ja validointia varten löytämään ominaisuuksia, joita voidaan tarkastella. Usein ohjelmiston tai dokumentaation ominaisuus voi kuitenkin olla niin yleinen, ettei sitä voida varmentaa helposti [PeYo08]. UML (engl. unified modeling language) on standardi graafiselle mallinnuskielelle, joka sisältää 13 erilaista kaaviota, mallia [W09UML]. UML kielellä tuotettujen mallien verifiointi ja validointi on ongelmallista [EnKüHe03]. UML ei ole yleensä verifiointityökalujen syötekieli ja eikä UML-mallia myöskään ei pystytä suoraan suorittamaan (dynaamista) testaamista varten. UML malleja on lähinnä käytetty dokumentointiin ja kommunikoinnin helpottamiseksi, jolloin formaali semantiikka ja mallien käsittelyn työkalut eivät ole olleet tarpeen. Engels, Küster, Heckel ja Lohmann esittävät esseessään [EnKüHe03] kuinka UML malli voidaan muuntaa verifiointi- ja validointityökalujen ymmärtämäksi syötekieleksi. Mallin tulee sisältää riittävästi tietoa sekä mallin tulee olla riittävän formaali, jotta automaattista muuntamista voidaan tehdä [BrLa02]. Kielessä säilytetään alkuperäisen mallin semantiikka, ja sekä verifiointi- että validointityökalut ymmärtävät muunnoskieltä. Kun semantiikka on säilytetty samanlaisena, on tämän implementoinnin validointi ja verifiointi samalla myös sen mallin oikeellisuuden tarkastamista [EnKüHe03]. Mikäli verifioinnissa ja validoinnissa tulee virheitä, ovat ne malleissa olevien virheiden ansiota, ja malleja on korjattava. 4.1 Mallien semantiikka Semanttista käyttäytymistä malleissa voidaan määritellä tutkimalla mitä yksittäinen aktiviteetti tarkoittaa ja miten tuo aktiviteetti yhdistyy muihin. On toimialakohtaista mitä semantiikkaa tarvitaan ja miten tuota semantiikkaa validoidaan ja verifioidaan.

12 9 4.2 Mallien muuntaminen sopivalle abstraktiotasolle UML-mallit voidaan muuntaa implementaatioksi käyttämällä olemassa olevia mallien transformaatiotekniikoita. Mallista generoidaan ohjelmakoodi ja mallia käytetään myös testitapausten määrittelemisessä. Testitapaukset ajamalla saadaan verifioitua implementaatio ja sitä kautta myös malli, kunhan semantiikka on säilytetty samanlaisena [EnKüHe03]. Mikäli mallit ovat korkealla abstraktiotasolla, transformoidaan ne ensin taso kerrallaan alimmalle formaalisti käsiteltävissä olevalle transformaatiotasolle käyttäen mallitransformaatiota. Nykyisin tämä tarkoittaa lähinnä alinta abstraktiotasoa, joka on lähimpänä teknistä alustaa, ja josta voidaan automaattisesti muuntaa mallit ajettavaksi prototyypiksi [EnKüHe03]. UML:llä tehdyistä artifakteista, kuten käyttötapaus-, sekvenssi-, yhteistyö- ja luokkakaavioista voidaan johtaa systeemin toiminnalliset vaatimukset, jotka puolestaan voidaan muuntaa testitapauksiksi verifiointi- ja validointityökalua varten [BrLa02]. Tällöin mallien semantiikan ja syntaksin tulisi olla yhteneväistä ja mallit tehdä kontrolloidusti siten, että mallit ovat keskenään yhtenäisiä ja johdonmukaisia [LeBaJu95]. Tuloksena olevan tuotteen tai mallin on oltava yhteensopiva ylemmän mallin kanssa (konformanssi). Eri näkökulmien on myös annettava yhtenäinen kuva järjestelmästä, jota tutkitaan (konsistenssi). Mallien transformaatio on yksi MDA:n ydinajatuksia [Al07]. Mallien muuntamistyökalussa on oltava API (Applicetion Programming Interface), jokin kirjasto, rajapinta, jonka avulla eri ohjelmointikielillä pääsee käyttämään työkalua. Mallien muuntamista voitaisiin kuitenkin ajatella tehtäväksi suoraan transformaatiokielillä, jolloin muunnoksien spesifikaatiot itsessään olisivat myös malleja [Al07]. 4.3 Työkalujen valinta Olennaista on, että käytettävät työkalut on määritelty [EnKüHe03]. UML mallit tehdään formaaleiksi tiettyjen työkalujen avulla, sillä formaalien mallien määritteleminen ilman työkalujen apua on hankalaa. Samoin tiettyjä työkaluja käytetään testistrategian luomisessa, jonka avulla puolestaan tehdään testien määrittelyt. Työkalupakkiin (engl. tool suite) tarvitaan neljänlaisia komponentteja [EnKüHe03]

13 10 mallinnuksen hallinnan työkalut, verifiointityökalu, validointityökalu ja käyttöliittymäkomponentti. Mallinnuksen hallinnan työkaluihin kuuluvat mallien luomiseen, muokkaamiseen ja säilyttämiseen liittyvät ratkaisut siten, että malleista saadaan formaaleja. Tämä on ikään kuin CASE-työkalu UML-kaavioiden tekemiseen. Verifiointityökalu transformoi ensin mallin riittävän alhaiselle abstraktiotasolle, ja käyttäjä voi lisäksi lisätä malliin ominaisuuksia. Verifioinnin jälkeen tuloksia voidaan tarkastella tietyn käyttöliittymän kautta. Validointityökalu muuntaa alimman abstraktiotason mallin suoritettavaksi ohjelmakoodiksi dynaamista testausta varten. Koodimuunnoksia voidaan muokata editorin kautta, ja testitapaukset voidaan luoda automaattisesti. Työkalujen tulisi olla keskenään yhteensopivia ja pitäisi myös standardoida, onko mallinnuskielenä UML vai joku muu [Al07]. 4.4 Verifiointi mallipohjaisessa ohjelmistotuotannossa Verifiointi on formaali tarkistus, että tuote vastaa sille asetettuja vaatimuksia. Mallitarkastuksella (engl. model checking) voidaan automaattisesti testata täyttääkö ohjelmisto spesifikaatiomääritykset tuottamalla joukko tiloja ja siirtymiä sekä arvioimalla niiden perusteella ohjelmiston toimintaa [EnRo03]. 4.5 Verifiointi Web services -ympäristössä Web service on ohjelmistojärjestelmä, joka mahdollistaa tietokoneiden välisen vuorovaikutuksen tietoverkon yli. Käytännössä termillä tarkoitetaan internetpohjaisia ohjelmointirajapintoja: jokin palvelin tarjoaa muille tietokoneille palvelun tai muun internetpohjaisen protokollan yli [W09WS]. Työnkulku (engl. workflow) kuvaa ihmisten ja laitteiden välisen työn etenemistä organisaatiossa. Työnkulku sisältää aktiviteetteja, kuten tietojen näyttäminen käyttäjälle, tietojen pyytäminen käyttäjältä tai tietokoneelta, laskutoimitukset tai viestien lähettäminen muille järjestelmille. Työnkulusta kuvataan: miten tehtävät tehdään, kuka

14 11 ne tekee, missä järjestyksessä ja kuinka nopeasti. Artikkelissaan [FoUcMa] Foster, Uchitel, Magee ja Kramer kuvaavat kuinka työnkulkuja web services -ympäristössä voidaan verifioida. Nykyisin web-services teknologiaa käytetään lähinnä point-to-point tyyppisesti kahden autonomisen järjestelmän välillä. Päämääränä on kuitenkin dynaaminen kokonaisuus, jossa palvelu voidaan valita tarpeen mukaan, ja työnkulku mukautuu valinnan mukaisesti. Tämä asettaa uudenlaisia haasteita kokonaisuuden verifioinnille. Työnkulku olisi tärkeätä verifioida ennen sen varsinaista implementointia. Artikkelissa [FoUcMa] ehdotetaan työnkulkujen mallintamista teknologiariippumattomilla tavoilla ja mallien käyttämistä verifiointiin. Artikkelissa web services työnkulut kuvataan XMLpohjaisella BPEL4WS (engl. business process execution language for web services) kuvauskielellä ja lisäksi ne mallinnetaan UML:n sekvenssikaavioilla (engl. MSC, message sequence chart). Molemmista luodaan tekstimuotoinen esitys FSP (engl finite state process) -notaatiolla. Näitä kahta vertaamalla löydetään eroja ja vastaavuuksia ja saadaan interaktiivisesti verifioitua molempien ominaisuuksia ottamatta vielä kantaa tekniseen alustaan ja sen asettamiin rajoituksiin. Sekvenssikaaviot, muunnokset FSP:hen sekä vertailut esitysten välillä ehdotetaan tehtäviksi sekä automatisoitaviksi mallinnustyökalulla nimeltä LTSA (engl. Labelled Transition System Analyzer). Jotta vertailua voidaan tehdä, on semantiikan oltava yhteneväinen.

15 12 Kuva 8: Verifiointi Web services ympäristössä [FoUcMa] Artikkeli tarjoaa ehdotuksen kuinka verifiointia voitaisiin tehdä ennen käyttöönottoa. Lisäksi ehdotetaan työnkulkujen mallintamisen integroimista mallinnustyökaluihin verifioinnin helpottamiseksi. Vastaavaa työnkulkujen mallintamista ja verifioimista voidaan tehdä myös muissa kuin Web services -ympäristössä.

16 Staattinen analyysi Staattinen analyysi on mallipohjaisessa ohjelmistotuotannossa validoinnin ja verifioinnin tekniikka, jossa testataan mallin oikeellisuutta. Tekniikalla on tarkoitus löytää puutteita tai virheitä ohjelman malleissa. Mitä strukturoidumpi malli on, sitä paremmin testausta voidaan automatisoida, toisaalta taas formaalin mallin tekemiseen menee enemmän aikaa [PeYo08]. Staattisessa analyysissä löydetään suuriin kokonaisuuksiin liittyviä virheitä. 4.7 Mallipohjainen (dynaaminen) testaus Formaalit mallit sisältävät niin paljon informaatiota, että niiden avulla voidaan tehdä automaattista testausta. Formaaleja malleja ovat esimerkiksi äärelliset automaatit, päätöstaulut ja kieliopit. Puoliformaalit mallit vaativat manuaalista analyysiä, mutta tarjoavat silti paremman lähtökohdan testitapausmäärittelyille kuin vapaamuotoiset kuvaukset. Puoliformaaleja malleja ovat esimerkiksi luokkakaaviot, tietovuokaaviot ja laajennetut käyttötapaukset [PeYo08]. Briand ja Labiche ehdottavat artikkelissaan [BrLa02] TOTEM (Testing Object-orienTed systems with the unified Modeling language) metodologiaa mallipohjaiselle systeemitestaukselle. Tällöin dynaamista testausta voidaan automatisoida puoliformaaleista malleista lähtien. Testivaatimukset tuotetaan automaattisesti seuraavista UML-artifakteista : käyttötapauskaaviot, käyttötapauskaavioiden kuvaukset (engl. use case descriptions), sekvenssi- tai yhteistyökaavio jokaista käyttötapausta kohden, luokkakaaviot ja sanasto (engl. a data dictionary), joka kuvailee jokaisen luokan, metodin ja attribuutin.

17 14 Lisäksi saatetaan tarvita aktiviteettikaavio kuvaamaan missä järjestyksessä käyttötapauksia voi järjestelmään tulla, mikäli järjestyksen on oltava määritelty. Esimerkiksi kirjastosysteemissä käyttäjän tulee rekisteröityä ennen kuin hän voi lainata kirjan. TOTEM-metodologia koostuu seuraavista vaiheista: UML-mallin formalisimin tarkistaminen (A1), Käyttötapausten riippuvuuksien määrittely (aktiviteettikaavio) (A2), Testivaatimukset sekvenssikaavioiden perusteella (A3), Testivaatimukset luokkakaavioiden perusteella (A4), Aktiviteettikaavioiden ja sekvenssikaavioiden yhdistäminen (A5), Systeemitestausvaatimusten kokoaminen edellisistä (A6), Testitapausten luominen systeemitestausvaatimusten perusteella (A7) ja Testausoraakkelien luominen (A8).

18 15 Kuva 3: TOTEM vaiheet [BrLa02] UML-kaavion on oltava automaattisesti testattavissa, eli riittävän formaalisti muodostettu. Tälle ei artikkelissa ole varsinaista toimintamallia, kerrotaan ainoastaan, että formalismi on tarkistettava. Jokaiselle toimijalle on TOTEM:ssa tehty oma aktiviteettikaavio, josta nähdään käyttötapausten väliset riippuvuudet.

19 16 Kuva 4: Esimerkki aktiviteettikaaviosta [BrLa02] Aktiviteettikaaviosta muodostetaan ohjelmallisesti suunnattu verkko, joka kertoo käyttötapaussekvenssien läpikäymisen järjestyksen. Kuva 5: Esimerkki aktiviteettikaaviosta muodostetusta verkosta [BrLa02] Jokainen käyttötapaus kuvataan sekvenssikaaviolla tai yhteistyökaaviolla, joissa kuvauskielenä on käytetty OCL:ää (engl. object constraint language) [W09OCL].

20 17 Kuva 6: Esimerkki sekvenssikaavioista[brla02] Sekvenssikaaviosta muodostetaan ohjelma, jossa otsakkeet (engl. labels) ovat operaatioita, ja algoritmit voivat automaattisesti muodostaa säännölliset lausekkeet tietokoneohjelmaa varten. Kuva 7: Sekvenssikaavion perusteella muodostettu säännöllinen lauseke [BrLa02]

21 18 Kun operaatiot sekä niiden suoritusjärjestys on näin saatu automatisoitua, kootaan systeemitestausvaatimukset sekä testitapaukset; mitä asioita pitää testata, jotta saadaan todettua toimiiko järjestelmä siten kuin se on tarkoitettu toimivaksi. Lopuksi luodaan testioraakkelit. Ne saadaan, mikäli operaatioiden pre- ja post-ehdot ovat määritelty formaalisti ja OCL-kielellä. Oraakkeli kertoo toteutuvatko ehdot halutulla tavalla. TOTEM-metodilla päästään suunnittelemaan testivaatimuksia jo perinteisen ohjelmistotuotantoprojektin aikaisessa vaiheessa, käyttötapauskaavioiden, sekvenssikaavioiden ja luokkakaavioiden valmistuttua. Testivaatimukset luodaan näiden kaavioiden pohjalta. Kaavioiden aikainen analysointi on tärkeää, sillä näin voidaan löytää ja korjata virheitä mahdollisimman aikaisessa ohjelmistoprojektin vaiheessa. Kun yksityiskohtaisempaa tietoa ohjelmistosta on saatavilla projektin edettyä, voidaan jo varhain tehtyjä testivaatimuksia käyttää testitapausten ja testioraakkelien muodostamiseksi. Artikkelissa [BrLa02] annetaan algoritmeja käyttötapausten järjestyksen automatisoimiseksi, kuten edellä esiteltiin, sekä proseduuri käyttötapausskenaarioiden automaattiseksi muodostamiseksi, mutta muutoin automatisointi on jätetty vielä tulevaisuuden tutkimuskohteeksi. Myöskään siihen ei olla otettu kantaa, miten eitoiminnallisten laatuvaatimusten (esimerkiksi luotettavuus, suorituskyky) testaaminen voitaisiin integroida TOTEM-lähestymistapaan. 5 Yhteenveto Mallipohjaisessa ohjelmistotuotannossa mallien oikeellisuuden varmentamiseen ei ole vielä riittäviä työkaluja. Ei myöskään ole välineitä verrata mallien pohjalta tehtyä toteutusta itse malliin: vastaavatko ne toisiaan. Työ on pitkälti aikaa vievää manuaalista käsityötä eikä tehtäviä voida automatisoida. Mikäli testauksessa vaaditaan paljon manuaalista työtä, kuten suurissa järjestelmissä, joissa testitapauksia on paljon, tulee testaamisesta kallista ja aikaa vievää ilman automatisointia. Mallien automaattinen verifiointi ja validointi ei ole mahdollista niin kauan, kuin itse mallien formalismia ei ole määritelty. Riittäviä työkaluja kaavioiden formaalille

22 19 muodostamiselle ei ole; mallien rakenne vaihtelee eivätkä ne välttämättä ole keskenään yhteensopivia. UML on noussut yleisimmäksi standardiksi mallien muodostamisessa, mutta tällä hetkellä ei ole mahdollista varmistaa UML-mallien formalismia automaattisten työkalujen avulla Mallien verifioimisen ja validoimisen automatisoimiseksi tulisi nämä mallit saada tietokoneen ymmärtämään muotoon. UML- tai muista malleista pitäisi saada muodostettua ajettavaa ohjelmakoodia, jossa alkuperäisen mallin semantiikka on säilytetty. Tämän ohjelman oikeellisuuden toteaminen olisi samalla mallin oikeellisuuden varmistamista. Tätä varten mallit tulisi muuntaa alimmalle formaalisti käsiteltävälle abstraktiotasolle. Näin saataisiin luotua ajettavaa ohjelmakoodia, jota verifiointi- ja validointityökalut ymmärtävät. Tässä mallitransformaatio on olennaista, mutta mallien abstraktiotasojen muuntamiseksi ei ole vielä standardoituja työkaluja. Testivaatimusten ja testitapausten automaattiselle muodostamiselle UML-kaavioiden pohjalta on joitakin algoritmeja, mutta suuremmassa määrin testitapausten muodostamisen automatisointi ei ole vielä mahdollista. Työnkulkuja voidaan verifioida kuvaamalla ne UML-sekvenssikaavioilla ja lisäksi BPEL-kielellä, muuntamalla ne tekstimuotoisiksi ja vertaamalla tämän jälkeen automaattisesti toisiinsa eroavaisuuksien löytämiseksi. Joskus ohjelman toiminta voidaan mallintaa äärelliseksi automaatiksi, joukoksi tiloja ja siirtymiä. Äärellisen automaatin kuvaama järjestelmä siirtyy tilasta toiseen saamansa herätteen avulla. Tällaisen formaalisti muodostetun tilakoneen avulla on mahdollista automaattisesti testata ominaisuuksia vaatimusmäärittelyä vasten vertaamalla toinen toisiaan. Työkalut on oltava kunnossa, jotta mallipohjainen analyysi UML- ja muista kaavioista voisi yleistyä. Tarvittavia työkaluja olisivat: mallinnuksen hallinnan työkalut formaalien mallien muodostamiseksi, verifiointityökalut ominaisuuksien hallinnoimiseksi ja niiden oikeellisuuden varmentamiseksi, työkalut mallien abstraktiotasojen muuntamiseksi, validointityökalut mallin muuntamiseksi ajettavaksi ohjelmaksi sekä sen suorittamiseksi, ja käyttöliittymäkomponentit koodin ja mallien editointia varten. Tällaisia työkaluja ei vielä ole olemassa. Mikäli riittäviä työkaluja ei ole, ei mallipohjaista oikeellisuuden toteamista juuri ole mahdollista automatisoida.

23 20 Lähteet AnKi04 Andersson, J., Kielosto, J., Linnamaa, L., Tilles, J., Vettenranta, J., Vaatimusdokumentti, 2004, URL [ ]. Al07 Alanen, M., A Metamodeling Framework for Software Engineering, BrLa02 Briand, L., Labiche, Y., A UML-Based Approach to System Testing, 2002, URL [ ]. EnKüHe03 Engels, G., Küster, J., Heckel, R., Lohmann, M., Model-Based Verification and Validation of Properties, 2003, URL [ ]. EnRo03 FoUcMa HaMä98 Endres, A., Rombach, D., A Handbook of Software and Systems Engineering. Pearson Education Limited, sivut Foster, H., Uchitel, S., Magee, J., Kramer, J., Model-based Verification of Web Service Compositions. Haikala, I., Märijärvi, J., Ohjelmistotuotanto, Suomen Atk-kustannus Oy, sivut LeBaJu95 Lee, M., Barta, B., Juliff, P, Software Quality and Productivity, Chapman&Hall, sivut Obj09 Object Management Group, Meta Object Facility (MOF), URL [ ]. OMG09 OMG s Metaobject Facility, 2009, URL [ ] PeYo08 Pezzè, M., Young, M., Software Testing and Analysis: Processes, Principles, and Techniques, Wiley, sivut Pö08 Pöri, M, Testaus Scrum-prosessimallissa. 2008, URL [ ].

24 Sch06 Schmidt, D. C., Model-driven engineering. IEEE Software, 39,2(2006), sivut SeKo03 So04 Sendell, S., Kozaczynski, W., Model transformation: The heart and soul of model-driven software development. IEEE Software, 20,5(2003), sivut Sommerville, I., Software Engineering, Pearson Education Limited, sivut W09OCL Wikipedia, URL [ ]. W09UML Wikipedia, URL [ ]. W09WS Wikipedia, URL [ ]. WhArTr Whittle, J., Araújo, J., Moreira, A., Composing Aspect Models with Graph Transformations.