TIE303 Formaalit menetelmät, kevät 2005 Johdanto II Antti-Juhani Kaijanaho antkaij@mit.jyu.fi Jyväskylän yliopisto Tietotekniikan laitos TIE303 Formaalit mentetelmät, 2005-01-20 p. 1/21
Luento2Luentomoniste Hoaren tripla: s. 12 Luku 3.7 ss. 32 33 Luku 3.8 ss. 33 35 Luku 4.1 ss. 37 39 Luku 7 ss. 69 72 (osittain) TIE303 Formaalit mentetelmät, 2005-01-20 p. 2/21
Formaaliuden tasot Tasolla 0 ohjelmankehityksessä ei käytetä lainkaan formaaleja menetelmiä eikä muuta matematiikkaa kuin sovellusalan omaa. Tasolla 1 ohjelmankehityksessä käytetään epämuodollista matematiikkaa lähinnä dokumentaation tai ideoinnin apuvälineen. Käytetyn matematiikan syntaksi ja semantiikka horjuu eikä siten sovellu automaattisesti käsiteltäväksi. Tasolla 2 käytetty matemaattinen notaatio on kiinnitetty sekä syntaksinsa että semantiikkansa osalta. Työskentelyä tukemassa käytetään joitakin automaattisia työkaluja, jotka prosessoivat käytettyä notaatiota lähinnä syntaksin tasolla. Tasolla 3 menetelmän syntaksi ja semantiikka on täysin määritelty ja täysin automatisoitu. Tuotosten sisäinen konsistenttius ja tuotosten keskinäinen oikeellisuus voidaan mekaanisesti todentaa. TIE303 Formaalit mentetelmät, 2005-01-20 p. 3/21
Seitsemän myyttiä 1. Formaalit menetelmät kykenevät takaamaan, että ohjelmisto on täydellinen. 2. Formaaleissa menetelmissä on kyse pelkästään ohjelmien oikeellisuustodistuksista. 3. Formaalit menetelmät auttavat vain kriittisissä (safety-critical) projekteissa. 4. Formaalit menetelmät vaativat korkeasti koulutettuja matemaatikkoja. 5. Formaalit menetelmät kasvattavat kehityskustannuksia. 6. Formaalit menetelmät eivät kelpaa käyttäjille. 7. Formaaleja menetelmiä ei käytetä todellisten, laajojen ohjelmistojen kehityksessä. Anthony Hall: Seven Myths of Formal Methods, IEEE Software, vol 7, no 5, September 1990. TIE303 Formaalit mentetelmät, 2005-01-20 p. 4/21
Seitsemän muuta myyttiä 8. Formaalit menetelmät hidastavat kehitysprosessia. 9. Formaaleilla menetelmillä ei ole työkalutukea. 10. Formaalit menetelmät korvaavat perinteisen ohjelmistotuotantoprosessin. 11. Formaalit menetelmät sopivat vain softan kehitykseen. 12. Formaalit menetelmät ovat tarpeettomia. 13. Formaaleja menetelmiä ei tueta. 14. Formaalien menetelmien ihmiset käyttävät aina formaaleja menetelmiä. Jonathan P. Bowen, Michael G. Hinchey: Seven More Myths of Formal Methods, IEEE Software, vol 12, no 4, July 1995. TIE303 Formaalit mentetelmät, 2005-01-20 p. 5/21
Kymmenen käskyä 1. Valitse tilanteeseen sopiva notaatio. 2. Formalisoi mutta älä yliformalisoi. 3. Arvioi kulut. 4. Hanki formaalien menetelmien guru saapuville. 5. Älä hylkää perinteisiä menetelmiäsi. 6. Dokumentoi tarpeeksi. 7. Älä luovu laatuvaatimuksistasi. 8. Älä ole dogmaattinen. 9. Testaa, testaa ja vielä kerran testaa. 10. Käytä uudelleen. Jonathan P. Bowen, Michael G. Hinchey: Ten Commandments of Formal Methods, Computer, vol 28, no 4, April 1995. TIE303 Formaalit mentetelmät, 2005-01-20 p. 6/21
While-ohjelmat 1 Unohdetaan (toistaiseksi) luokat, oliot, aliohjelmat jne While-ohjelmassa voi olla: sijoituslauseita: x 4 if-lauseita: if x > 4 then else fi while-lauseita: while x > 4 do od väitelauseita: { x > 0 } On vain yksi tyyppi: kokonaisluvut (ei ylivuotoa) Lausekkeissa saa käyttää normaaleja yhteen-, vähennys- ja kertolaskutoimituksia Jakolasku on a/b (pyöristetään ylöspäin lähimpään kokonaislukuun) ja a/b (pyöristetään alaspäin lähimpään kokonaislukuun) Jakojäännös a mod b TIE303 Formaalit mentetelmät, 2005-01-20 p. 7/21
While-ohjelmat 2 Perusehtolausekkeet: a = b, a < b jne Ja-ehtolauseke: p q Tai-ehtolauseke: p q Ei-ehtolauseke: p Ehtolausekkeet eivät ole lausekkeita eikä niillä ole siten tyyppiä. Ehtolauseketta voidaan käyttää vain if-lauseen ja while-lauseen ehtona sekä väitelauseessa. Väitelauseen ehtolausekkeen tulee olla tosi aina suorituksen osuessa väitelauseen kohdalle. Jos näin ei ole, ohjelman suoritus ei ole sallittu. TIE303 Formaalit mentetelmät, 2005-01-20 p. 8/21
Eukleideen algoritmi { a > 0 b 0} a a b b while b 0 do t b b a mod b a t od { a mod a = 0 b mod a = 0} TIE303 Formaalit mentetelmät, 2005-01-20 p. 9/21
Hoaren tripla { esiehto } koodi { jälkiehto } Esiehto on väite, joka sijaitsee koodin alussa. Esiehto ilmaisee, millaisin alkuarvoin ohjelman saa käynnistää. Jälkiehto on väite, joka sijaitsee koodin lopussa. Jälkiehto kertoo jotain ohjelman loppuarvoista olettaen, että esiehto pätee. Entä oikeassa ohjelmoinnissa? TIE303 Formaalit mentetelmät, 2005-01-20 p. 10/21
Formaaleja vihjeitä ohjelmoijille: Väittämät 1 Väittämä (assertion) on suoritettava ohjelmalause, joka tarkistaa, että ohjelman tila on ainakin osittain kunnossa. Käytännössä väittämään liittyy oleellisesti testilauseke, jonka tulee aina väittämän tullessa suoritetuksi saada arvokseen tosi. Väittämien perusasiat: Väittämän laukeaminen (ehto saa väitettä suoritettaessa arvon false) on aina bugin merkki. Käytä väittämiä vain ohjelman sisäisen toiminnan varmistamiseen: syötteen oikeellisuuden tarkistaminen väitteillä on niiden väärinkäyttöä. Yleisemmin: käytä väittämiä vain varmistamaan, että luottamusta ei rikota (esimerkiksi, jos metodi luottaa, että sitä kutsutaan vain tietynlaisilla argumenteilla), älä koskaan luottamuksen luomiseen. a a Tämä periaate on tärkeä turvallisuuskriittistä koodia kirjoitettaessa. TIE303 Formaalit mentetelmät, 2005-01-20 p. 11/21
Väittämät 2: Esimerkki Oikean Elämän koodista public class ErrorHandler { protected void err(string s) { throw new RuntimeException(s); } private static final Stack handlerstack = new Stack(); private static ErrorHandler currenthandler = new ErrorHandler(); public static void error(string s) { assert currenthandler!= null; currenthandler.err(s); } protected final void register() { assert currenthandler!= null; handlerstack.push(currenthandler); currenthandler = this; } protected final void deregister() { assert currenthandler == this; assert!handlerstack.empty(); currenthandler = (ErrorHandler)handlerStack.pop(); } } TIE303 Formaalit mentetelmät, 2005-01-20 p. 12/21
Formaaleja vihjeitä ohjelmoijille: Väittämät 3 Tavallisesti väittämät käännetään tehokkuussyistä pois päältä, kun ohjelmasta tehdään tuotantokäyttöön tarkoitettu koonti. Hoare 1970-luvulla: väittämien kääntäminen pois päältä tuotantokäytössä muistuttaa pelastusliivien jättämistä maihin merille mentäessä. Hoare 2000-luvulla: väittämät ovat testioraakkeleita, jotka määrittelevät, milloin ohjelma (ainakin) toimii väärin. Väittämät ovat ensisijaisesti suoritettavaa dokumentaatiota, toissijaisesti testivälineitä ja pieneltä osaltaan ohjelmien analyysin välineitä. Käytännössä kannattaa luokitella väittämät useaan kategoriaan ja ilmaista tämä luokitus ohjelmakoodissa käyttämällä kategorian mukaisesti nimettyä makroa tai metodia paljaan assert-lauseen asemesta. TIE303 Formaalit mentetelmät, 2005-01-20 p. 13/21
Formaaleja vihjeitä ohjelmoijille: Väittämät 4 Jotkin ohjelmointikielet tarjoavat alkeellisen väittämätuen, esim. C:n assert-funktio ja Javan assert-lause. Nämä ovat yleensä riittämättömiä väittämien tehokäyttäjälle. Harva ohjelmointikieli tarjoaa kunnollisen väittämätuen. Sellainen pitää siis rakentaa itse kirjastoina. Microsoftilla eri projektit käyttävät mm. seuraavia väittämäkategorioita: a SIMPLIFYING_ASSUMPTION (strlen(input) < MAX_PATH, not yet checking for overflow ) COMPILE_TIME_CHECK (sizeof(x)==sizeof(y), addition is undefined for arrays of different sizes ) switch (condition) { case 0:... case 1:... default: UNREACHABLE( condition is really a boolean ); } a Tony Hoare: Towards the Verifying Compiler. O. Owe ym: From Object- Orientation to Formal Methods, Springer 2004, LNCS 2635. TIE303 Formaalit mentetelmät, 2005-01-20 p. 14/21
Formaaleja vihjeitä ohjelmoijille: Väittämät 5 Esimerkiksi C:ssä voi määritellä makroja eri väittämäkategorioille: #define SIMPLIFYING_ASSUMPTION(test) \ do { \ if (!test) { \ fprintf(stderr, "%s:%d(%s): Simplifying assertion %s failed.",\ FILE, LINE, func, #test);\ exit(exit_failure);\ }\ } while(0) Nyt sitten voidaan kehitystyön aikana sanoa SIMPLIFYING_ASSUMPTION(n < 50), kun halutaan toteuttaa vain osa toiminnallisuudesta. Kehitystyön lopuksi kannattaa varmistaa koneellisella etsinnällä, että tuota makroa ei enää missään käytetä. TIE303 Formaalit mentetelmät, 2005-01-20 p. 15/21
Formaaleja vihjeitä ohjelmoijille: Sopimusohjelmointi 1 Eräs väittämien sovellus on sopimusohjelmointi: Ohjelma koostuu luokista, joiden ajonaikaisia ilmentymiä sanotaan olioiksi. Kunkin luokan kullakin metodilla on kaksi väittämää: esiehto (precondition) ja jälkiehto (postcondition) Lisäksi kullakin luokalla on yksi luokkakohtainen väittämä, luokkainvariantti (class invariant) Ajatus on, että esi- ja jälkiehdot muodostavat luokan ja sen olioiden käyttäjien (metodien kutsujat) välille sopimuksen. Sopimus antaa kummallekin osapuolelle oikeuksia ja velvollisuuksia toista osapuolta kohtaan. Sopimus luo luottamussuhteen luokan ja sen käyttäjien välille. TIE303 Formaalit mentetelmät, 2005-01-20 p. 16/21
Formaaleja vihjeitä ohjelmoijille: Sopimusohjelmointi 2 Esiehto on metodin kutsujalle velvollisuus ja metodille itselleen oikeus. Kutsujan on huolehdittava, että esiehto pätee aina kun se kutsuu metodia. Metodi voi luottaa siihen, että metodiin tultaessa esiehto pätee. Sen ei tarvitse (eikä tule!) iffitellä esiehdon toteutumista. Jos esiehto ei päde metodiin tultaesssa, se on kutsujan bugi. Se ilmenee esiehtoväittämän laukeamisena, jos väittämät ovat päällä. Jos esiehto ei päde, metodilla ei ole mitään velvollisuuksia. Jos metodia voi kutsua epäluotettava taho (esimerkiksi RMI:n tms. avulla), esiehdon tulee olla triviaali (aina tosi) ja lähtötilan oikeellisuus tulee tarkistaa iffittelemällä. TIE303 Formaalit mentetelmät, 2005-01-20 p. 17/21
Formaaleja vihjeitä ohjelmoijille: Sopimusohjelmointi 3 Jälkiehto on metodin (ehdollinen) velvollisuus ja kutsujan (ehdollinen) oikeus. Ehto on kummassakin tapauksessa se, että esiehto päti metodiin tultaessa. Metodin on huolehdittava siitä, että jälkiehto on voimassa, kun metodin suoritus päättyy. Metodi vapautuu tästä vastuusta, jos esiehto ei päde metodiin tultaessa. Kutsuja voi luottaa siihen, että metodin palatessa jälkiehto pätee, jos esiehto päti metodiin tultaessa. Jos jälkiehto ei päde metodista poistuttaessa, vaikka esiehto päti siihen tultaessa, se on metodin bugi. Se ilmenee jälkiehtoväittämän laukeamisena, jos väittämät ovat päällä. TIE303 Formaalit mentetelmät, 2005-01-20 p. 18/21
Formaaleja vihjeitä ohjelmoijille: Sopimusohjelmointi 4 Luokkainvariantti on ehto, joka karakterisoi luokan olioiden sallitut tilat. Luokan muodostimen tehtävänä on saattaa luokkainvariantti voimaan. Kukin metodi voi olettaa, että suorituksen alkaessa luokkainvariantti on voimassa. Vastaavasti sen tulee huolehtia, että se on voimassa suorituksen päättyessä. Luokkainvariantti on siis oikeastaan osa metodin esi- ja jälkiehtoa. Yleensä sitä ei kuitenkaan kirjoiteta näkyviin esija jälkiehdon yhteyteen vaan luokan itsenäiseksi osaksi. Jos luokassa on riittävä tiedon piilotus (attribuutteja pääsevät muuttamaan vain luokan metodit), invariantin rikkoutuminen on luokan sisäinen bugi. TIE303 Formaalit mentetelmät, 2005-01-20 p. 19/21
Esimerkki Se kuuluisa pino? TIE303 Formaalit mentetelmät, 2005-01-20 p. 20/21
Seuraava luento: maanantaina klo 10 samassa salissa (Ag Beeta). TIE303 Formaalit mentetelmät, 2005-01-20 p. 21/21