Invariantteihin perustuva ohjelmointi Ralph-Johan Back Abo Akademi ja TUCS www.abo.fi/~backrj 5. kesäkuuta 2006
Oikein toimivien ohjelmien konstruointi: vaihtoehdot Oikeellisuuden todistaminen jälkikäteen (Floyd, Naur, Hoare,...). Kirjoitetaan ensin ohjelma, testataan, ja todistetaan oikeaksi Konstruktiivinen todistus (Dijkstra,...). Konstruoidaan ohjelma ja sen todistus samaan aikaan, siten että annetut alku- ja loppuehdot toteutuvat. Invariantteihin perustuva ohjelmointi (Dijkstra?, Reynolds, van Emden, Back,...). Formuloidaan ohjelman invariantit ensiksi, tämän jälkeen konstruoidaan koodi siten että se säilyttää nämä invariantit. (Hehnerillä samanlaisia ideoita, mutta hän käyttää relaatioita eikä predikaatteja).
Missä vaiheessa kirjoitetaan kooodi Program code Pre/postconditions Pre/postconditions Pre/postconditions Program code Loop invariants Loop invariants Loop invariants Program code Verification Verification Verification A posteriori proof Dijkstra s approach Invariant based programming
Invariantteihin perustuva ohjelmointi: kysymyksiä Mikä on hyvä notaatio invariantteihin perustuvalle ohjelmoinnille (käytämme lyhennettä invarianttiohjelmointi) Mikä on työjärjestys kun rakennetaan invariantteihin perustuva ohjelma. Miten identifioidaan ja formuloidaan ohjelman invariantit ennenkuin koodi on kirjoitettu Minkälaisia eroja on tavallisten ohjelmien ja invarianttiohjelmien välillä. Minkälaista työkalutukea voidaan antaa invarianttiohjelmoinnille. Voidaanko invarianttiohjelmointia hyödyntää opetuksessa.
Notaatio: Sisäkkäiset invariantit (nested invariants diagrams)
Koodiin vai invariantteihin perustuva rakenne? Ohjelman rakenne on traditionaalisesti perustunut koodin kontrollirakenteisiin rakenteinen ohjelmointi, single entry- single exit kontrollirakenteet ohjelmamodulit, kuten proseduurit ja luokat invarianttien on sopeuduttava koodin rakenteeseen Invarianttiohjelmoinnissa ohjelman rakenne tulee määräytyä invarianteista eikä kontrollirakenteista koodin on sopeuduttava invarianttien rakenteeseen single-enty single exit rakenteet eivät välttämättä sovellu tähän
Summan laskeminen, vuokaavio k,sum:=0,0 k:=k+1; sum:=sum+k F k=n T
Laskennan eri tilanteet n, sum : integer n>=0 alkutilanne k,sum:=0,0 k: integer n>=0 0 <= k <= n sum=0+1+2+...+k silmukan invariantti k:=k+1; sum:=sum+k F k=n T sum=0+1+2+...+n lopputilanne
Koodi kuvataan siirtyminä n, sum : integer n>=0 k,sum:=0,0 k:=k+1:sum:=sum+k [k=/=n] k: integer n>=0 sum=0+1+2+...+k 0 <= k <= n [k=n] sum=0+1+2+...+n
Invariantteihin perustuva rakenne Tilanne (situation) kuvaa tilojen joukkoa (niiden tilojen joukko jotka toteuttavat tilanteen ehdot) Tilannetta voidaan vahvistaa (tarkentaa) lisäämällä uusia ehtoja Uusi tilanne on alkuperäisen tilanteen alijoukko. Voimme käyttää Venn-kaavioita tilanteiden kuvaamiseen.
Sisäkkäiset invariantit n,sum: integer n >=0 k: integer 0 <= k <= n sum=0+1+2+...+k k = n Olemme tässä poistaneet ehdot jotka ovat voimassa sisäkkäisyyden ansiosta. Esimerkki: ehto n 0 merkitään vain uloimpaan tilanteeseen, jolloin se on voimassa myös kaikissa sisemmissä tilanteissa.
Sisäkkäisten invarianttien käyttö kaaviossa n,sum: integer n >= 0 k,sum:=0,0 k:=k+1; sum:= sum+k [k=/= n] k: integer 0 <= k <= n sum=0+1+2+...+k [k=n] k = n Siirstymänuolet ovat samoja kuin aimmassa kaaviossa Tämä kaavio on ekvivalentti aiemman kanssa, vain esitystapa on muuttunut
Terminointi n,sum: integer n >= 0 k,sum:=0,0 k:=k+1; sum:= sum+k [k=/= n] k: integer n k>=0 0 <= k <= n sum=0+1+2+...+k [k=n] k = n Terminointifunktio kirjoitetaan invariantit oikeaan yläkulman. Ehto osoittaa että n k 0 on voimassa tässä tilanteessa, ja samalla että funktion n k arvo vähenee ennenkuin palataan tähän tilanteeseen.
Tilannekaaviot ja tilakaaviot Tilannekaaviot ovat samanlaisia kuin tilakaaviot (state charts). Molemmat ovat tilasiirtymäkaavioiden laajennuksia. Niiden tulkinta ja käyttötarkoitus on kuitenkin erilainen. Tilakaaviot kuvaavat ohjelman kontrollia vuorovaikuitteisissa ohjelmissa. Tilannekaaviot ovat taas lähinnä oikeellisuustodistuksia. Tilakaavio on tavallisesti abstraktio suuremmasta ohjelmasta, tilannekaavio kuvaa koko ohjelmaa.
Invarianttiohjelman rakentaminen
Esimerkki: lajitteluohjelma Ongelma: Lajittele kokonaislukutaulukko nousevaan järjestykseen
Algoritminen ratkaisu Valitsemme yksinkertaisen lajittelualgoritmin, insertion sort Kursori käy läpi taulukon elementit vasemmalta oikealle Haemme joka kerta pienimmän alkion kursorin oikealta puolelta, ja vaihdamme tämän ja kursorin osoittaman alkion paikkaa. Tämän jälkeen siirrämme kursoria askeleen oikealle, kunnes lopulta olemme käyneet läpi kaikki taulukon alkiot.
Välitilanteen (invariantin) identifiointi Piirrämme kuvan joka hahmottaa perustitetorakenteet joilla työskennellään, ja miten ne muuttuvat laskennan aikana Voimme tarvittaessa simuloida algoritmia käsin, konkreettisen datan avulla. Kuvista ja simuloinnista yritämme identifioida toistuvat tilanteet, ja kuvata ne yleisessä muodossa. Tilanteiden määrittelyä joudutaan yleensä sovittamaan kun rakennetaan tilanteiden väliset siirtymät.
Sovellutuksen teoriaa Sorted(A, i, j): taulukon alkiot ovat nousevassa järjestyksessä suljetussa välissä [i, j], Partitioned(A, i): jokainen taulukon A alkio ennen indeksiä i on pienempi tai yhtä suuri kuin jokainen An alkio indeksin i kohdalla tai sen jälkeen. Permutation(A, A0): taulukon A alkiot muodostavat taulukon A0 permutaation.
Alkutilanne ja lopputilanne Kuvaamme oletetun alkutilanteen ja toivotun lopputilanteen. 1 n A Permutation(A,A0) sort the array changing A 1 n A Sorted(A,1,n) Permutation(A,A0)
Looginen kuvaus Alkutilanne n : integer A : array1 : n o f integer Permutation(A,A 0 ) Lopputilanne Sorted(A, 1, n) Permutation(A,A 0 )
Välitilanne 1 n Permutation(A,A0) i:=1 1 i n Sorted Permutation(A,A0) Partitioned(A,i) [i<n] [i=n] swap smallest remaining element with A[i]; i:=i+1 1 n Sorted Permutation(A,A0)
Looginen kuvaus Välitilanne lisää seuraavat ehdot alkutilanteen kuvaukseen i : integer 1 i n Sorted(A,1,i 1) Partitioned(A,i) Sijoitus i := 1 aikaansaa välitilanteen Ehto i = n implikoi lopputilanteen Vielä selvitettävä miten ylläpitää välitilanne samalla kun edetään kohti lopputilannetta.
Tilannekaavio A. array 1..n of integer Permutation(A,A0) & 1<=n i:=1 [i=/=n] i: integer 1<=i<=n & Sorted(A,1,i 1) &Partitioned(A,i) n i [i=n] Sorted(A,1,n)
Pienimmän jäljellä olevan alkion löytäminen Pienimmän alkion löytäminen vaatii että selaamme kaikki jäljelläolevat alkiot Tarvitsemme silmukan tässä Lisäämme neljännen tilanteen, jossa osa lajittelemettomasta taulukon osasta on tarkistettu pienintä alkiota haettaessa.
1 n Permutation(A,A0) i:=1 1 i n Sorted Permutation(A,A0) Partitioned(i) [i=/=n] A[i],A[k]:=A[k],A[i]; i:=i+1 [A[j]>=A[k]] [A[j]<A[k]] [i=n ] k:= j j,k:=i,i 1 i k [j=n] j n Sorted Permutation(A,A0) Partitioned(i) min(a,i,j) j:= j+1 [j=/=n ] 1 Tietojenkäsittelytieteen n päivät, 5-6.6, Helsinki Sorted Permutation(A,A0)
Looginen kuvaus Uudessa tilanteessa on lisäehdot k, j : integer i k j n A[k] = min{a[h] i h j} Tarkistamme että tämä tilanne saadaan aikaan sijoituksella j,k := i,i kun i n. Tarkistamme myös että kun j = n, niin A[i],A[k] := A[k],A[i]; i := i + 1 aikaansaa ensimmäisen välitilanteen, kuten kaaviossa on kuvattu.
Välitilanteen säilyttäminen Lopuksi meidän on tarkistettava että välitilanne säilyy samalla kun laskenta etenee. Meidän on näytettävä ett kun j n, niin siirtymä j := j + 1;if A[ j] < A[k] then k := j fi säilyttää välitilanteen Sisempti silmukka pysähtyy, koska n j vähenee mutta on samalla rajoitettu alhaalta Ulompi silmukka pysähtyy koska n i vähenee ja on samalla rajoitettu alhaalta
Lopullinen tilannekaavio Uloin tilanne näyttää algoritmin taustaoletukset. Ensimmäinen sisäkkäinen tilanne kuvaa sitä, että olemme lajitelleet taulukon indeksiin i 1, mutta emme ole vielä aloittaneet seuraavan alkion haun. Sisin tilanne on voimassa kun haemme seuraavaa alkiota Toinen sisäkkäinen tilanne on lopputilanne
A. array 1..n of integer Permutation(A,A0) & 1<=n i:=1 i: integer 1<=i<=n & Sorted(A,1,i 1) &Partitioned(A,i) [i=/=n] [j=/=n] j,k:= i,i j,k: integer A[k]=min(A,i,j) i<n & i<=k<=j<=n n i n j j:=j+1; [A[j]>=A[k]] [A[j]<A[k]]; k:=j [i=n] [j=n] i:=i+1 A[i],A[k]:=A[k],A[i]; Sorted(A,1,n)
Huomioita Olisimme myös voineet sijoittaa lopputilanteen ensimmäisen välitilanteen sisälle. Tämä olisi kuitenkin näyttänyt että meillä olisi lopputilanteessa myös tieto muuttujan i arvosta. Koska tämä ei kuulu tehtäväasetteluun, niin asetamme lopputilanteen ulommalle tasolle.
Vastaava vuokaavio i:=1 i=n i=/=n j,k:=i,i j=/=n j=n A[i],A[k]:=A[k],A[i]; i:=i+1 j:=j+1; if A[j]<A[k] then k:=j
Keskustelu Kuvia käytetään huomattavan paljon johdettaessa invarianttipohjelmia Kuvien avulla voimme melko helposti kirjoittaa tilanteiden loogisen kuvauksen. Tätä tarvitaan kun tarkastelemme siirtymien oikeellisuutta. Kuvat auttavat myös algoritmin kehittämisessä. Tilannekaaviot ovat parempia silloin kun tarkistamme että tilanteet säilyvät siirtymissä. Ne antavat myös sisäkkäisten tilanteiden kautta tiiviimmän loogisen kuvauksen tilanteista. Yllä olevassa algoritmissa olisi luultavasti parempi kuvata pienimmän alkion haku proseduurilla, sen sijaan että meillä on sisäkkäinen silmukka ohjelmassa.
Invarianttiohjelmat vs. tavalliset ohjelmat
Oikeellisuus Invarianttiohjelma on konsistentti (consistent), jos kaikki siirtymät säilyttävät tilanteet pysähtyvä, (terminating) jos ohjelmassa ei ole päättymätöntä silmukaa elävä (live), jos ohjelma pysähtyy vain lopputilanteissa Invarianttiohjelma on totaalisesti oikea (totally correct), jos se on konsistentti, pysähtyvä ja elävä.
Oikeellisuuden aikaansaaminen sivutuotteena Standardi lähestymistapa ohjelmointiin tuottaa koodia, joka on vielä testattava ja korjattava. Tämä ei takaa tarpeeksi suuren luotettavuuden. Oikeellisuus voitaisiin periaatteessa todistaa jälkikäteen, mutta tätä ei tehdä, koska onglema on (tavallaan) jo ratkaistu, meillä on jo jotain joka toimii ja joka voidaan toimittaa lisätyö on liian suuri ja myös liian vaativa puute hyvistä työkaluista Invarianttiohjelmointi antaa invariantit ilmaiseksi, osana ohjelmointiprosessia. Vaatii suuremman ponnistuken ohjelmoinnissa, mutta antaa samalla suuremman luotettavuuden ja paremman ymmäryksen ohjelman toiminnasta.
Kuvien merkitys Ohjelmoija joka ratkaisee yllä esitetyn tapaisen ongelman piirtää yleensä kuvia jotka auttavat ymmärtämän ongelmatilanteen, ja auttaa algoritmisen ratkaisun löytämisessä. Invarianttiohjelmoinnissa nämä kuvat koodataan invarianttien muotoon. Tavallisessa ohjelmoinnissa ne hukkuvat ohjelmoinnin edetessä. Kun annamme enemmän arvoa kuville, on niiden säilyminen ja ylläpitäminen ehkä todennäköisempää. Tämä kuvien rooli ohjelmoinnissa on samanlainen kun kuvien rooli fysikkassa ja insinööritieteissä.
Oikeellisuuden käsite Oikeellisuuden käsite on vahvempi invarianttiohjelmoinnissa kuin mitä se on tavallisessa ohjelmoinnissa. Tavallinen ohjelmointi: jos ohjelma käynnistetään tilassa joka toteutta alkutilanteen ehdot, niin se pysähtyy tilassa joka totetuttaa lopputilanteen ehdot. Invarianttiohjelmoinnissa jokainen tilanne voi olla alkutilanne. Oikeellisuus on siten oltava voimassa myös sellaisten tilojen kohdalla, joita ei edes voida saavutta alkutilanteesta. Oikeellisuusvaatimus on myös vahvempi siinä mielessä, että kaikkien välitilanteiden on aina oltava voimassa kun suoritus saavuttaa ne. Ei riitä että vain lopputilanne on voimassa pysähdyttäessä.
Onko oikeellisuusvaatimus liian vahva Voidaan ajatella että oikeellisuusvaatimus on liian vahva invarianttiohjelmien kohdalla. Toisaalta, jos ohjelmassa on ainakin yksi silmukka, niin tavallisen ohjelman oikeellisuustodistuksessa tarvitaan invariantti, jonka säilyminen on todistettava. Tällöin itse asiassa todistetaan vahvempi oikeellisuusominaisuus. Toisin sanoen, tavanmukaiset oikeellisuuden todistusmenetelmät todistavat itse asiassa vahvemman tuloksen kuin mitä tavallisten ohjelmien oikeellisuus vaatii (vertaa induktiotodistus)
Lokaalisuus ja alhaisen tason modulaarisuus Voimme tarkastella invarianttiohjelmien oikeellisuutta lokaalisti. Tarkastelemme jokaista tilannetta kerrallaan, sekä jokaista tilannetta johon voidaan siirtyä tästä tilanteesta. Muut tilanteet voidaan sivuttaa. Invarianttiohjelmointi tarjoaa proseduuria hienojakoisemman modulaarisuuden asteen imperatiivisessa ohjelmoinnissa (moduli = siirtymä). Voimme siten rakentaa invarianttiohjelmaa modulaarisella tavalla, samalla tavoin kuin voimme rakentaa funktionaalisia ohjelmia ja logiikkaohjelmia modulaarisesti. Invarianttiohjelmaa voidaan muuttaa ja korjata lokaalisti.
Vain terminointi vaatii gloobaalin tarkastelun: jokainen mahdollinen sykli on tarkistettava.
Ohjelmointitekniikka Invarianttiohjelmien semantiikka on hyvin yleinen. Se sallii epäonnistumisen (failure), onnistumisen (miraculous success), äärettömät suoritukset sekä normaalin pysähtymisen. Lisäksi single-entry multiple-exit rakenteet ovat luonnollisia tässä lähestymistavassa, mikä taas tukee poikkeusten käsittelyä. Minimivaatimus on että invarianttiohjelma on konsistentti. Ohjelman ei välttämättä tarvitse olla pysähtyvä tai elävä. Elävyys ei esim. ole silloin voimassa kun olemme rakentamassa ohjelmaa, emmekä vielä ole huomioineet kaikki mahdolliset vaihtoehdot. Ohjelma voi myös olla pysähtymättä, joko sen takia että emme ole vielä huomioineet pysähtymisen, tai sitten tarkoituksena on rakentaa ohjelma joka ei koskaan pysähdy (reaktiivinen ohjelma).
Asteittainen ohjelman rakentaminen Invarianttiohjelma rakennetaan asteittain, sarjana peräkkäisiä päätöksiä, joissa jokainen päätös ja sen toteutus säilyttää ohjelman konsistenttisuuden. Tällainen päätösaskel voi olla jokin seuraavista Lisää uusi tilanne (alkutilanne, lopputilanne, välitilanne) tai uusi siirtymä. Muuta tai poista tilanne tai siirtymä Tarkista konsistenttisuus (ja muunna ohjelmaa tarvittaessa tämän perusteella) Tarkista pysähtyminen tai elävyys (ja muunna ohjelmaa tarvittaessa tämän perusteella)
Konsistenttisuuden tarkistaminen Invarianttiohjelmointi vaatii että jokaisen siirtymän konsistenttisuus tarkistetaan (ts todistetaan siirtymän oikeellisuus) Jos näitä tarkistuksia jätetään liian myöhäiseen vaiheeseen, niin virheet kasaantuvat ja ohjelman korjaaminen konsistenttisuuden aikaansaamiseksi tule vaikeaksi. Virheet pitäisi korjata sitä mukaan kun niitä tehdään. Tarkistusten siirtäminen myöhempään vähentää myös motivaatiota niiden tekemiseen ylipäänsä, koska liian monta keskenään riippuvaa asia joudutaan muuttamaan. Konsistenssitarkistukset voidaan tehdä toivotulla tarkkuustasolla (käsin todistaminen, mekaaninen todistaminen, tms)
Työkaluja invarianttiohjelmien rakentamiseen
Socos ympäristö Rakennamme ympäristöä invarianttiohjelmien rakentamiselle Ympäristössä on sekä graafinen ja tekstuaalinen esitys invarianttiohjelmalle. Ympäristö käyttää hyväkseen teoreeman todistajia joiden avulla pyritään automaattisesti tai interaktiivisesti todistamaan verifointiehdot. Tällä hetkellä käytämme PVS ja Simplify järjestelmiä. Käyttäjälle näytetään ainoastaan ne verifiointehdot joita ei pystytä todistamaan automaattisesti. Invarianttiohjelma käännetään suoraan Python kielelle. Ohjelmat voidaan suoritta debuggin- moodissa. Alku-ja loppuehdot sekä invariantit evaluoidaan suorituksen aikana, ja näytettän varoituksina.
Työn alla Invarianttiohjelmien yksinkertainen + tarkka semantiikka Lähestymistavan laajentaminen (rekursiivisiin) proseduureihin, data moduleihin, luokkiin (mukaanlukien periytyminen ja implementointi), rinnakkaisohjelmiin sekä interaktiivisiin ohjelmiin. Automaattisen verifioinnin kehittäminen Socos ympäristössä Kokeillaan menetelmän käyttökelpoisuutta suurempien ohjelmien rakentamisessa.
Formaalit menetelmät ensimäisenä ohjelmointikurssina
Kokeiluja invarianttiohjelmoinnilla Olemme kokeilleet menetelmää useissa pienissä koetilanteissa, pienryhmillä (1-20 henkilöä). Ryhmä (yleensä 2 henkilöä) ratkaisee jonkin ohjelmointitehtävän yhdessä. Yhtensä noin 10 koetta, 2-3 tuntia per sessio Toimii käytännössä hyvin, sekä erittäin kokeneilta verifiointimenetelmien ammattilaisilta (IFIP WG2.3 jäseniltä) että vasta-alkajilta (takanaan vain muutama ohjelmointikurssi) Invarianttien löytäminen melko helppoa, kun lähdetään kuvioista. Suurin ongelma vasta-alkajille on invariantin ilmaiseminen loogisella kaavalla Invariantteja parannellaan sitä mukaan kun lisätään siirtymiä Tarkistus löytää usein melko subtiileja virheitä Työkalutuki verifointiehtojen tarkistusta varten tärkeää, mutta ilman niitä pärjätään hyvin pienissä ohjelmissa.
Invarianttiohjelmoinnin opetus Olen itse luennoinut yhden kurssin invarianttiohjelmoinnista, tutikimuskeskuksemme jatko-opiskelijoille Lähestymistapaa on myös kokeiltu ammatti-instituutti tasolla hyvin tuloksin Suunnittelemme ohjelmointikurssia tällä memetelmäll ensimmäisen vuoden tietojenkäsittelytieteen opiskelijoille (ensi kevät) Tarkoituksena olisi suunnitella lukion kurssi invarianttiohjelmoinnista
Tarvitaan kaksi peruskurssia: Miten ohjelmointia tulisi opettaa Käytännön logiikkaa (esim Back & von Wright: Matematik med litet logik). Tukee invarianttien formulointia ja verifiointiehtojen todistamista Invarianttiohjelmointi Miten rakennetaan oikein toimivia ohjelmia Tämä antaa ohjelmoinnille yksinkertaisen matemaattisen perustuksen, jota voi käyttää käytännön ohjelmoinnissa. Tämän lisäksi tarvitaan tavanmukaisia test/debug/fixtyyppisiä ohjelmointikursseja.
Missä ohjelmointia tulisi opettaa Ohjelmoinnin opetusta voidaan antaa eri tasoilla Lukiossa Ym kurssit lisätään matematiikan kurssitarjontaan (suositeltavin taso, tulee osaksi yleisivistystä) Ammattikorkeakoulu Tietotekiikan ensimmäisen vuoden kursseja (ohjelmoinnin matemaattienen perusta) Yliopisto Tietotekniikan ensimmäisen vuoden kursseja (ohjelmoinnin matemaattienen perusta)
Hyöty Lukion logiikan ja ohjelmoinnin kurssit olisivat melko samanlainen kuin matematiikan ja fysiikan kurssit (mutta ehkä näitä yksinkertaisempia) Opettaisimme perusmenetelmän jolla rakennetaan ohjelmia joista tiedämme että ne toimivat oikein Logiikan kurssi opettaa argumentoimaan ohjelmien oikeasta toiminnasta. Kurssi tukee myös matematiikan opetusta yleensä Opiskelijat voivat itse vakuuttua rakentamansa ohjelman oikeellisuudesta, ja korjata virheet sitä mukaan kuin ne syntyvät.
Kiitos Kotisivuiltani löytyy lisää materiaalia: www.abo.fi/~backrj