Hur man konstruerar felfria program

1. Hur man konstruerar felfria program Ralph-Johan Back Åbo Akademi TUCS

2. Datorsystem:Programvara och hårdvara Användargränssnitt Användargränssnitt Programvara Programvara Programmeringsspråk Programmeringsspråk Kommunikation Operativsystem Operativsystem Dator Dator Datanät

3. Programvarans centrala roll • Största delen av datorsystemen består av programvara • Samhället ytterst beroende av programvaran • Inbyggda system, administration, pc tillämpningar, telecom, sjukhusväsendet, ... • Ofta kritiska funktioner: • Flygtrafik, medicinska instrument, industriella processes, bankväsendet, ... • Programvarans kvalitet har stark inverkan på samhällets verksamhet • Trygghet, pålitlighet, service, effektivitet, kvalitet

4. Ett bra datorprogram • Funktionellt, gör det som man väntar sig • Mångsidigt, kan användas för olika behov • Lättanvänt, enkel användargränssnitt • Effektivt, fungerar snabbt och med små resurser • Kooperativt, fungerar bra tillsammans med andra program • Pålitligt, innehåller inte fel • Portabelt, fungerar på olika dator och olika operativsystem • Osv, osv

5. Programvarans kvalitet • Utvecklingen har gått emot bättre och bättre programsystem • Lättare att använda, mera effektiva, mångsidigare, .... • Men: programmens pålitlighet har inte förbättrats, snarare tvärtom.

6. Vad beror felen i programen på • Grundorsaken är den ständigt växande komplexiteten • Programmens storlek växer hela tiden. • Dagens programsystem är enorma(100 000 – 10 000 000 rader kod) • Programmen är mycket komplicerade, och delarnas samverkan är svår att hantera • Andra behov (mångsidighet, lättanvändbarhet, ...) har ytterligare ökat programmens storlek • Marknadskrafterna favoriserar inte hög kvalitet i programvara • Det viktigaste är att programsystemen blir färdiga så snabbt som möjligt (time to market) • Konsumenterna kräver inte pålitliga program • Man ger inga garantier för programvara

7. Programvaruteknikens nuvarande nivå • Programvarutekniken är outvecklad jämfört med andra teknologiska områden • Grundforskningen utnyttjas inte i större utsträkning i programvaruindustrin • Programmering kräver en annorlunda teoretisk bas, jämfört med mera traditionella teknologier • Modellerna är oftast diskreta, inte kontinuerliga • De viktigaste arbetsredskapen är logik och algebra • Största delen av den matematik som behövs har utvecklats under de senaste 50 åren

8. Programmeringsprocessen i dag Definiera problemet Planera programmet Skriv programkod Underhåll Testa programmet

9. Testning som kvalitetskontroll • Utför programmet med exempeldata, och kolla att resultaten är riktiga • Man är tvungen att utföra programmet för en mycket stor mängd olika testdata, för att hitta möjligast många fel • Man kan inte hitta alla fel med testning, endast de fel kan repareras som som exempeldata avslöjar

10. Avlägsna fel med testning • De fel som introducerats i början av programmeringsprocessen försöker man ta bort i slutet av processes med testning • Testningen blir allt mera arbetsdryg, ju större programmen är • Testningen bildar en allt större del av kostnaderna för programutveckling • Trots det kan man inte uppnå önskad kvalitet med enbart testning

11. Formella metoder i programmering • Matematisk-logisk analys av progamsystemens egenskaper innan de byggts • Matematisk analys av programmets uppbyggnad och konstruktion • Matematisk modellering av programmets funktionalitet, beteende, resursanvändning, pålitlighet, mm

12. Forskning i formella metoder för programmering vid ÅA • Institutionen för informationsbehandling vid Åbo Akademi 1984-- • Fokus på forskning kring formella metoder i programutveckling • Spetsforskningsenhet vid Finlands Akademi1995 -99 (som en del av TUCS) ja 2002 – 2007 (som egen enhet) • Seniorforskare • Ralph-Johan Back (ledare) • Johan Lilius • Kaisa Sere • Joakim von Wright • Cirka 50 forskare totalt, hälften utlänningar

13. Exempel på formell metod: bevisa riktigheten av program • Uppgift: skriva ett program som räknar summan av de första n talet, 1 + 2 + 3 + ... + n sum n 1+2+3+...+ n

14. Programmet Sum i:=1 s:=0 i <=n s:=s+i i:=i+1

15. Programkod (Python) def sum(n):summera 1+2+3+...+n i := 1 i räknar antalet iterationer s := 0s är delsumma while i <= n:iterera när i <= n s := s+i lägg i till summan s i := i+1öka i return snär i = n+1, så slutar vi, returnera summas s print sum(10)skriv ut 1+2+3+...+10

16. Utför programmet n = 3 i:=1 s:=0 s i 1 0 i <=n s:=s+i i:=i+1

17. Utför programmet n = 3 i:=1 s:=0 s i 1 0 2 1 i <=n s:=s+i i:=i+1

18. Utför programmet n = 3 i:=1 s:=0 s i 1 0 2 1 i <=n 3 3 s:=s+i i:=i+1

19. Utför programmet n = 3 i:=1 s:=0 s i 1 0 2 1 i <=n 3 3 4 6 s:=s+i i:=i+1

20. Avsluta programmet n = 3 i:=1 s:=0 s i 1 0 S=6 2 1 i <=n 3 3 4 6 s:=s+i i:=i+1

21. Induktionshypotes n = 3 i:=1 s:=0 s i 1 0 2 1 i <=n 3 3 4 6 s:=s+i i:=i+1 s =1+...+(i-1) 1<=i <= n+1

22. Påståenden förvillkor: 0 <= n i:=1 s:=0 invariant: s =1+...+(i-1) 1<=i <= n+1 slutvillkor: s = 1+...+n i <=n s:=s+i i:=i+1

23. Påståenden i programtexten def sum2(n): # 0 <= n i := 1 s := 0 while i <= n: # s =1+...+(i-1) & 1<=i <= n+1 s := s+i i := i+1 return s # s = 1+...+n print sum2(10)

24. Sum programmets riktighet • Invarianten gäller i början av slingan • Invarianten förblir i kraft när vi går ett varv runt slingan • Slutvillkoret följer av invarianten när slingan terminerar • Slingan terminerar förr eller senare Sum programmet är korrekt förvillkor i:=1 s:=0 invariant i <=n slutvillkor s:=s+i i:=i+1

25. Formella metoder i programvaruteknik • Det primära problemet är att förbättra programmens tillförlitlighet. • Formella metoder erbjuder delvis ett alternativ till testning, delvis kompletterar de testning • Programmens egenskaper kan analyseras både • logiskt och matematiskt (formella metoder) • statistiskt, med stickprov (testning)

26. Problem med matematisk bevis av progamriktighet • Bevisning kräver ett matematiskt tänkesätt • Bevisningen av stora program mycket svårt • Beviset kan själv innehålla fel • Svårt att beskriva för – och slutvillkoret abstrakt och matematiskt exakt • Kan vara svårt att komma på invarianten (motsvarar problement med att hitta en bra induktionshypotes) • Bevisen är rutinmässiga, inte speciellt intressanta ur matematisk synpunkt

27. Bevisa felaktiga program • I praktiken innehåller programmen fel, så det går inte att bevisa att de fungerar riktigt • Alla fel måste lokaliseras och rättas innan man kan bevisa programriktigheten • Å andra sidan så visar bevisförsöket ofta var felet är • Bevis och testning ger två olika sätt att hitta fel i program • Slutsats: svårt att bevisa riktigheten av färdiga program.

28. Att bygga felfria program Riktigheten bevaras • Slutsats: Programriktigheten måste byggas in från början • Programsystemet skall byggas bit för bit, så att man aldrig förlorar programriktigheten • Det centrala problemställningen i vår forskningsgrupp: Hur konstruerar man stora program inkrementalt, bit för bit, så att programriktigheten hela tiden bevaras

29. Inkrementell programmering • Vi bygger första biten A0 • Vi visar att den fungerar riktigt A0

30. Inkrementell programmering • Vi bygger nästa bit B0 • Vi visar att den fungerar riktigt A0 B0

31. Inkrementell programmering • Vi förbättrar A0 genoma att lägga till nya egenskaper A1 • Vi visar riktigheten av den nya biten A1 • Vi visar dessutom att A1 bevarar egenskaperna i A0 A1 A0 B0

32. Inkrementell programmering • Vi förbättrar B0 genom att lägga till ny funktionalitet B1 • Vi visar att B1 fungerar riktigt • Vi visar att B1 bevara B0s egenskaper A1 B1 A0 B0

33. Inkrementell programmering • Vi förbättrar igen A A2 A1 B1 A0 B0

34. Inkrementell programmering • Osv, tills all funktionalitet som vi behöver har blivit byggd A5 A4 C4 A3 B3 C3 A2 B2 C2 A1 B1 A0 B0

35. Inkrementell programmering • Kräver ett nytt sätt att närma sig programmeringsuppgiften • Programriktigheten måste kollas hela tiden, medan man bygger programmet • Programmets arkitektur måste stöda inkrementell konstruktion • Programmeringsprocessen måste även stöda angreppssättet • Testning är fortfarande viktigt, man testar varje utvidgning

36. Onstrukturering • När man bygger stora helheter bit för bit, så kan man lätt hamna i återvändsgränder: • Den valda arkitekturen passar inte för de nya planerade utvidgningarna • Programmet måste då omstruktureras • Arkitekturen måste ändras • Funktionaliteten ändras inte

37. Programmeringsprocessen • Programutvidgning och omstrukturering alternerar vid inkrementell programmering Utvidga programmet Omstrukturera programmet

38. Fördelarna med inkrementell programmering • Stora program kan byggas som en serie små utvidgningar • Programriktigheten kan kontrolleras kontinuerligt • Man har hela tiden ett fullt funktionerande program (funktionaliteten är inte fullständig, men det som finns fungerar som det skall) • Programmet kan hela tiden jämföras med kraven, och både programmet och kraven kan ändras under processen • Det finns inte ett separat underhållsskede, underhåll sker på samma sätt som programkonstruktion. • Omstrukturering möjliggörs av att programmet är hela tiden korrekt

39. Begränsningar med inkrementell programmering • Det är svårt att bygga stora program på det här sättet • Stora program måste delas upp i mindre moduler, med väldefinierade gränssnitt • De olika modulerna kan byggas av olika programmeringsteam • Inkrementell programmering och modulär programmering kompletterar varandra • Tillsammans gör de det möjligt att bygga stora och ytterst pålitliga program • För att uppnå felfrihet, måste även bevis kontrolleras (eller genereras) med hjälp av datorer

40. Forskning kring inkrementell programmering vid ÅA • Teorin för inkrementell programmering (refinementkalkyl) • Omgivningar för inkrementell programmering (UML-baserad) • Programmeringsprocesser för inkrementell programmering (XP-baserad) • Pilotprojekt för att bygga program inkrementellt • Inkrementell programmering för olika tillämpningsområden (vlsi-planering, objekt orienterad programmering, distribuerade system, parallel programmering, osv)