Oletukset virhetilanteista

Luotettava järjestelmä koostuu korkealaatuisesta ohjelmistosta, toipumismekanismeista ja korkeatasoisesta ylläpidettävyydestä. Jos kaikki ohjelmiston virheet ja virhetilanteet

kyetään hallitsemaan mm. toipumisaktiviteeteilla, kyse on korkean luotettavuuden oh-jelmistosta ja järjestelmästä. Virheitä hallitaan monella eri tavalla, yksi hallitsemistapa on sisäisten tarkistusten sijoittaminen ohjelmaan. Assertioiden (so. tarkistusten) oikeas-sa sijoittamisesoikeas-sa tulisi tuntea ohjelman virhemekanismit, mikä käytännössä tapahtuu olettamalla tiettyjä virhetilanteita. Samoja virhetilanneoletuksia voidaan erään ehdotuk-sen (Powell 1995) mukaan hyödyntää määrättäessä sellaiehdotuk-sen järjestelmän luotettavuutta, jonka oikeellisuus riippuu näiden oletusten kelpoisuudesta. Tässä kohdassa käsitellään lyhyesti Powellin esittämää lähestymistapaa analysoida formaalisti virhetilanteita, mutta valitettavasti Powellin esittämät virhetilanteisiini perustuvat luotettavuusarvioinnit eivät mahdu tämän julkaisun raameihin.

4.5.1 Virhetilannekattavuus

Virhetilannekattavuus (engl. error coverage) on ehdollinen todennäköisyys sille, että järjestelmä toipuu virhetilanteen ilmaannuttua (Bouricius et al. 1969). Virhetilannekat-tavuuden luotettavuusvaikutuksen ovat esittäneet monet tahot (mm. Bouricius et al.

1969, Kaufman & Johnson 1999). Virhetilannekattavuus on vaikeasti estimoitavissa, ja siksi anlyyttiset menetelmätkin ovat vähissä. Kehitetyt menetelmät valtaosin vaativat hyvin spesifisiä parametreja, joiden hankkiminen on vaikeaa. Koska riittävä testaaminen on usein taloudellisista syistä perusteetonta, virhetilannekattavuutta on estimoitu tilas-tollisilla malleilla.

Tilastollisessa lähestymistavassa aluksi valitaan virhe(tilanne)joukosta satunnaisesti virhe, joka syötetään joko järjestelmän prototyyppiin tai malliin ja tarkastellaan sen jäl-keen virheen vaikutusta. Suoritettavien syöttöjen lukumäärä on verrannollinen vaaditta-vaan tietyn järjestelmän virhetilannekattavuuteen. Virheen syöttömenetelmää tarkastel-laan lähemmin tämän luvun seuraavassa kohdassa, mutta tässä yhteydessä mainittakoon, että tämä menetelmä vaatii yleensä hyvin suuren määrän syöttöjä, mikä osaltaan vai-kuttaa menetelmän käyttökelpoisuuteen. Tulisikin suunnittelussa jo ottaa huomioon, miten merkittävää on selvittää virhekäyttäytymistä ja suunnitella virheensyöttöä annet-tujen resurssien suomissa mahdollisuuksissa. Mahdollisesti resurssit eivät riitä vaaditta-van virheensyöttökattavuuden täyttämiseksi, mikä merkitsee järjestelmän uudelleen-suunnittelua siten, että vaadittava luotettavuustaso voidaan saatavilla olevilla menetel-millä ja resursseilla saavuttaa. Tarvitaankin estimointimenetelmiä, joilla suunnittelija kykenee arvioimaan järjestelmän kattavuustekijät.

Mahdollisten ohjelmistovirheiden järjestelmätason vaikutukset on tunnettava. Muutoin ei voi olla kyse riittävästä luotettavuudesta. Tunnistaminen voi alkaa käyttö-kokemuksista ja virhetilanteiden kvantitatiivisesta tai kvalitatiivisesta mallinnuksesta.

Tunnistamista edesauttaa geneerinen tietämys virhemekanismeista, mitä ilman

päätök-senteko ja ohjelmistotuotannon menettelyt jäävät karkealle tasolle, eikä silloin sovellus-kohtainen tietämys ehkä enää ole riittävää. Uudet järjestelmät kyetään myös tehokkaasti validoimaan, kun virhetilannemallit ovat saatavilla.

Käytön aikana havaitaan lisää ohjelmiston virhetilanteita, lähinnä koska käyttötilanteet eroavat kehityksen aikaisista testitilanteista. Testauksissa on vaikeata tai joskus jopa mahdotonta ottaa huomioon kaikkia ympäristötekijöitä ja niiden muutoksia. Ohjelmis-ton virhetilanteiden ymmärtämiseksi tarvitaan huolellista virhetoimintojen ympäristö-tarkastelua ja ohjelmistoon korjausten jälkeen tehtyjen muutosten ympäristö-tarkastelua.

Virhemekanismin selvittämisessä oleellisinta on sekä virhetyyppien, komponenttien vikautumistiheyden että vikautumistavan tunteminen. Tietoa virhemekanismeista voi-daan hyödyntää sekä suunniteltaessa että arvioitaessa järjestelmän luotettavuutta. Suun-nittelussa vikasietoisuuden täsmällinen rakentaminen on merkittävää, arvioitaessa kes-keiseksi tulee myös, millä kattavuudella vikoja/virheitä, virhetilanteita ja vikautumi-sia/virhetoimintoja on tarkasteltu. Tarkastelun kattavuudella on selkeitä viitekohtia myös valittaessa vioittumistapoja riskilähtöisessä analyysimenettelyssä, jollaisesta esi-merkkinä Tiira, joka on kuvattu julkaisussa (Harju 2000). Kelpoisuuteen vaikuttavat sekä standardinomainen analysoimisen lähestymistapa, jota kuitenkin juuri ohjelmisto-jen tarkasteluun on vaikea määrittää, vioittumistapoohjelmisto-jen systemaattinen tarkastelutapa sekä prosessien ja artefaktien ottaminen huomioon juuri oikealla tarkkuustasolla.

4.5.2 Datavirhetilanteet

Virhesietoiset varmistukset epäonnistuvat, jos suunnitteluperusteet eli -oletukset osoit-tautuvat vääriksi tai ne ovat muuttuneet jostakin syystä järjestelmää käytettäessä. Jos suunnitteluolettamukset laaditaan ääritapausten mukaan, pelko olettamusten rikkomi-sesta on tosin vähäinen. Kuitenkin on tapauksia, joissa virhesietoisuus on rakennettava hyvin monille virhe- tai virhetilannetyypeille, joiden vikautumiset ja vioittumistavat ovat hyvin vapaasti määriteltyjä. Silloin myös virhesietoisuutta on vastaavasti kasvatet-tava, mikä merkitsee kustannusten kasvamista. Kustannusten kurissa pitämiseksi tulisi Powellin (1995) mukaan löytää juuri oikea virhesietoisuusaste ja täsmälliset olettamuk-set vioittumistavoista, sillä korkea virhesietoisuusaste merkitsee myös suurta vioittu-mistapojen määrää.

Kuvan 16 esittämässä kaaviossa virhetilannetyyppejä on kaksi: arvo- ja ajastusvirheti-lanteet. Kutsuttakoon niitä tässä datavirhetilanteiksi. Powellin mukaan oletetukset vi-kautumistapojen kattavuudelle ovat merkittävässä asemassa virhetilanteen syöttömene-telmien toteuttamisessa. Tällä käsitteellä hän tarkoittaa todennäköisyyttä sille, että väit-teet, joiden perusteella vikautumistapa muodostetaan, ovat paikkansapitäviä.

Yksi datavirhetilanne voi edetä moduulissa tai siirtyä muihin moduuleihin aiheuttamalla uusia datavirhetilanteita. Datavirhetilanne voi myös häipyä, tai virhe voi korjaantua kesken kaiken ennen virhetilanteen etenemistä tai korruptoitunutta dataa kyetään käyt-tämään tavalla, mikä ei vaikuta ohjelman käyttäytymiseen.

V_none ∧ T_E

V_none ∧ T_none

V_none ∧ T_arb

V_none ∧ T_L

V_none ∧ T_O

V_none ∧ T_Bk

V_none ∧ T_P

V_N ∧ T_E

V_N ∧ T_none

V_N ∧ T_arb

V_N ∧ T_L

V_N ∧ T_O

V_N ∧ T_Bk

V_N ∧ T_P

V_arb ∧ T_E

V_arb ∧ T_none

V_arb ∧ T_arb

V_arb ∧ T_L

V_arb ∧ T_O

V_arb ∧ T_Bk

V_arb ∧ T_P

Kuva 16. Vioittumistapojen seurauskaavio kuvattuna kolmidimensioisella karteesin tu-lolla. Vx ja Tx ovat vastaavasti datan arvovirhetilanteita ja datan ajastusvirhetilanteita tietyille siirtymille x (Powell 1995).

Kuvan matemaattinen merkintä V ∧ T esittää karteesista tuloa datan arvovirhetilanne-joukon V ja datan ajastusvirhetilannejoukon T välillä. Kahden joukon V ja T karteesi tulo määritellään kaikiksi pistejoukoiksi (v, t), missä v ∈ V ja t ∈ T. Tässä tapauksessa kyse on kolmidimensioisesta karteesisesta tulosta, jossa on määritelty kuvan mukaisesti kaikkiaan 21 yhdistävää siirtymää datavirhetilanteiden välillä. Mielekkäitä siirtymiä on mahdollista määrittää muitakin kuin kuvassa esitetyt. Kuvan virhetilannesiirtymät mää-ritellään seuraavasti:

– Vnone tarkoittaa sitä, että arvovirhetilanteet ovat oikeita ja tuotteen palvelut tuottavat arvoltaan oikeita tuloksia.

– VN tarkoittaa tilannetta, jossa ainoat arvovirhetilanteet ovat koodaamatto-mat¹³ arvovirhetilanteet. Tämän tilanteen seurauksena ei välttämättä ole vir-hetoimintaa.

– Varb tarkoittaa mielivaltaista arvovirhetilannetta, missä arvovirhetilanteen määrittelyä ei ole rajoitettu kvalitatiivisesti tai kvantitatiivisesti.

– Tnone tarkoittaa sitä, että ajastusarvovirhetilanteita ei ole. Tuotteen palvelut toteutetaan oikea-aikaisina.

– TO tarkoittaa sitä, että ajastusarvovirhetilanteet johtuvat tekemättä jättämi-sestä (haluttua tilaa ei saavuteta, ohjelma kaatuu).

– TL tarkoittaa sitä, että ajastusarvovirhetilanteet ovat myöhässä syntyviä.

Palvelu toteutuu joko ajallaan tai myöhässä.

– TE tarkoittaa sitä, että ajastusarvovirhetilanteet ovat liian aikaisin syntyviä.

Palvelu toteutuu ajallaan tai liian aikaisin.

– Tarb tarkoittaa mielivaltaista ajastusvirhetilannetta, jossa ajastusvirhe-tilanteen määrittelyä ei ole rajoitettu kvalitatiivisesti tai kvantitatiivisesti.

Edellä kuvatut datan virhetilanteiden siirtymät ovat tilapäisiä, siis joko hetkittäisiä tai epäsäännöllisiä. Kaksi jäljelle jäänyttä kuvassa esitettyä siirtymää ovat TP, pysyvä ajas-tusvirhetilanne ja TBk, rajattu tekemättäjättö (engl. bounded omission degree). Edellinen kuvaa tapausta, jossa komponentti palvelee tai toimii ajallisesti moitteetta johonkin tiettyyn palveluerään¹⁴ asti, minkä jälkeen palvelu lakkaa. Jälkimmäinen siirtymä, TBk, rajoittaa pysyvää ajastusvirhetilannetta siten, että komponentti voi laiminlyödä joitakin palvelueriä, mutta k-palveluerän laiminlyönnin jälkeen komponentti jättää toimittamatta kaikki loput palveluerät tai yhteydenotot.

Mielivaltaiset arvovirhetilanteet, joita ei ole kvantitatiivisesti tai kvalitatiivisesti rajoi-tettu mihinkään virhetilannejoukkoon, ovat vaikeasti käsiteltävissä. Käsittely- ja ar-viointikustannukset kasvavat mm. monimutkaisten ja suorituskyvykkyydeltään alhaisten

13 Mitä hyvänsä n-bitin koodia voidaan pitää kaikkien n-bitin merkkijonojen osajoukkona. Ne merkkijo-not, jotka kuuluvat tähän tiettyyn osajoukkoon ovat koodattuja sanoja, kun taas tähän osajoukkoon kuu-lumattomat merkkijonot ovat koodaamattomia sanoja. Yksinkertainen sääntö virhetilanteiden ilmaisemis-sa : jos merkkijono on koodiilmaisemis-sana, merkkijono on oikein, muusilmaisemis-sa tapauksesilmaisemis-sa virheellinen.

14 Palvelu on palveluerien jono s₁ , s₂ , s₃ , …

virhetilanteiden paljastusmenettelyiden takia. Mielivaltaisia arvovirhetilanteita tulisi välttää kohdistamalla suunnittelua virheettömämpään suuntaan.