Mechanically supported design of self-stabilizing algorithms

Abstract

Het schrijven van een programma is vaak veel gemakkelijker dan te bewijzen dat een programma doet wat het moet doen. Daarbij wordt onze samenleving steeds afhankelijker van computers; men denke daarbij aan complexe programmatuur die de verkeersleiding van treinen of vliegtuigen regelt, die de administratie van de eectenhandel bijhoudt of die besluit of de stormvloedkering al dan niet neergelaten moet worden. Om de kwaliteit van programmatuur te kunnen garanderen, wordt ze uitgebreid getest. Dit wordt meestal gedaan met de probeer-en-faal methode, waarbij een pro- gramma op testinvoer wordt losgelaten en er vervolgens wordt gekeken of het aan de verwachtingen van de programmeur en klant voldoet. Deze manier van testen elimi- neert helaas niet alle fouten. We horen dan ook vaak mensen over bugs in programma's praten. Softwarefabrikanten komen regelmatig met nieuwe versies van hun produkten die de bugs van de vorige versie niet meer bevatten. Dat klopt vaak wel, maar helaas is het eerder regel dan uitzondering dat de nieuwere versie nieuwe bugs bevat. Kortom, bugs lijken als een soort onvermijdbare erfenis in programma's voor te komen. Voor een programma zoals een tekstverwerking kunnen we best wel met een bug of twee leven, maar van een studenten-administratiesyteem verwachten we toch dat het pro- gramma niet onbedoeld met de cijfers van de studenten omgaat. We verwachten ook, om een paar andere voorbeelden te noemen, dat onze prive brieven die elektronisch via het Internet worden verzonden niet per ongeluk aan het verkeerde adres worden afgeleverd, of dat een elektronisch besturingsysteem van een vliegtuig niet plotseling weigert. Met de genoemde probeer-en-faal testmethode kunnen wij slechts constateren dat tijdens een test alles goed ging. Helaas is het veelal onmogelijk alle toestanden waarin een computersysteem zich kan bevinden na gaan met een test. Dat zou veel te veel tijd kosten of is soms zelfs theoretisch nietuitvoerbaar, nog daargelaten of het commercieel acceptabel zou zijn. Een andere methode die tot een betere softwarekwaliteit kan leiden is de volledig formele aanpak; hierbij is een programmeur verplicht om een wiskundig bewijs van de correctheid van zijn programma te leveren. Meestal wordt een programma hierbij ontworpen tegelijkertijd met het construeren van een bewijs dat het programma aan de specicatie voldoet. Er wordt gebruik gemaakt van een speciaal soort wiskunde (vaak programma-logica genoemd) voor het redeneren over eigenschappen van een pro- gramma. Met deze methode kan men bewijzen dat een programma qua ontwerp fout- loos is, zonder dat men het programma zelf hoeft te testen. Dit betekent nog niet dat in de praktijk het geproduceerde programma echt foutloos zal zijn, want het ontwerp is maar een van de vele stadia |alhoewel een van de belangrijkste| in het produceren van software. Wel kunnen wij zeggen dat het resultaat betrouwbaarder zal zijn. Net zoals dat wij fouten kunnen maken bij het schrijven van een programma, kun- nen wij helaas ook fouten maken bij het geven van een bewijs. Een gecompliceerd?Page 236 programma vraagt meestaal ook een gecompliceerd bewijs. De kans om fouten te maken zal toenemen, en het is niet onwaarschijnlijk dat een denkfout die gemaakt wordt bij het ontwerpen van een programma ook gemaakt wordt bij het construeren van een correctheidsbewijs voor dat programma. Parallel met het ontwikkelen van formele methoden, is ook de technologie om bewi- jzen te kunnen veri?eren met de computer ge?evolueerd. Deze technologie noemen we mechanisch vericatie en het computerprogramma die dat doet noemen we (niet echt passend) een stellingbewijzer. Een stellingbewijzer wordt gebaseerd op een handvol axiomas en bewijsregels. De consistentie en zinvolheid van deze axiomas en bewijs- regels zijn veelal al uitgebreid bestudeerd en er bestaat consensus over hun consis- tentie. Het bewijs van een nieuwe stelling kan alleen worden geconstrueerd door het herhaaldelijk toepassing van de bewijsregels, uitgaande van de axiomas. De juistheid van deze nieuwe stellingen wordt dus afgedwongen door de manier waarop ze wor- den gebouwd. In veel stellingbewijzers kan men ook nieuwe bewijsregels denieren in termen van reeds bestaande (primitieve) bewijsregels. Deze nieuwe stellingen en bewi- jstactieken zijn vaak krachtiger dan de ingebouwde en kunnen dus leiden tot kortere en meer inzichtelijke bewijzen. In dit proefschrift wordt speciaal aandacht besteed aan zogenaamde gedistribueerde programma's. Een gedistribueerd programma is een programma dat bestaat uit samen- werkende componenten |elke component heeft meestal een eigen processor. Zulke pro- gramma's worden heel veel gebruikt, bijvoorbeeld in het Internet waarbij computers uit de hele wereld in een groot elektronisch netwerk worden verbonden. Boodschappen van de ene computer moeten, via tussen-computers, worden verstuurd naar de bestem- mingscomputer. Op elk van deze tussen-computers draait een component van een routeringsprogramma. Deze routeringsprogramma's hebben kennis van (een gedeelte) van de structuur van het netwerk. Omdat het netwerk voortdurend van vorm veran- dert (er kunnen verbindingen bijkomen of wegvallen, en er kunnen tussen-computers aangezet en uitgezet worden) moeten deze computers het netwerk zelf gebruiken om samen uit te vinden hoe de globale structuur is. Zo'n routeringsprogramma is een voorbeeld van een gedistribueerd programma. Omdat het vaak om veel componenten gaat die over, tussen, met en door elkaar werken, is het redeneren over een gedistribueerd programma moeilijk. In dit proefschrift bestuderen we de programma-logica UNITY die speciaal ontworpen is omte redeneren over eigenschappen van gedistribueerde programma's [CM88]. UNITY is klein en sim- pel, en daarom aantrekkelijk. Toch is programma's ontwerpen met UNITY, in onze ervaring, vaak erg lastig. Er ontbreekt een systematische ontwerpmethodologie, en sommige ontwerptechnieken bleken niet ondersteund te (kunnen) worden. We hebben dus UNITY uitgebreid, vooral om technieken rond het opsplitsen van programma in parallel werkende componenten beter te ondersteunen. Er worden voorbeelden gegeven om te laten zien hoe we de specicatie van een probleem kunnen vereenvoudigen door een geschikte opsplitsing te kiezen. We besteden daarbij vooral aandacht aan zogenaamde zelf-stabiliserende, gedis- tribueerde programma's. Een zelf-stabiliserend programma is een programma dat het systeem weer in een gewenste toestand kan brengen als het daar, door een externe?Page 237 verstoring, uit geraakt is. Ook als er tijdens dit herstellen weer nieuwe verstoringen optreden is dat geen probleem voor dergelijke systemen. We hebben UNITY uitge- breid met een reeks van stellingen om over zulke programma's te kunen redeneren. We behandelen een groot voorbeeld, het zogenaamde Eerlijk en Herhaaldelijk Toepassing (EHT) programma. Het EHT programma is een gedistribueerd programma dat een bepaalde klasse van problemen zelf-stabiliserend kan oplossen (uitrekenen). Dit boek is uniek omdat het niet alleen over formele methoden of over het bewi- jzen van een of ander moeilijk programma gaat, maar omdat vrijwel alle resultaten mechanisch geverieerd zijn met een stellingbewijzer! Onze ervaring met mechanisch vericatie wordt ook in dit boek beschreven. Mensen die ook met mechanisch veri- catie van gedistribueerde programma's willen beginnen zullen veel onderwerpen in dit boek interessant vinden. Tot slot willen we benadrukken dat het beoefenen van formele methoden vereist dat programmeurs een goed ontwikkelde wiskundige handvaardigheid hebben. Het eectief opereren met een stellingbewijzer is tot nu toe, helaas, slechts voorbehouden aan een handjevol specialisten. Het is begrijpelijk dat de industrie twijfelt aan de economisch waarde van formele methoden. Toch zullen mensen vroeg of laat, naar mate wij steeds afhankelijker worden van computers, ontdekken hoe kwetsbaar ze zijn als er fouten in computers optreden. In de toekomst zullen mensen dus gedwongen zijn om naar stellingbewijzers te kijken. Investeren in de technologie van mechanisch vericatie en in het opleiden van 'formele' programmeurs, is daarom, naar onze mening, geen weg gegooide moeite.?