1 / 40

Hur man konstruerar felfria program

Hur man konstruerar felfria program. Ralph-Johan Back Åbo Akademi TUCS. Datorsystem: Programvara och hårdvara. Användargränssnitt. Användargränssnitt. Programvara. Programvara. Programmeringsspråk. Programmeringsspråk. Kommunikation. Operativsystem. Operativsystem. Dator.

Download Presentation

Hur man konstruerar felfria program

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related