It og informationssøgning Forelæsning december 2006 Nils Andersen. Indkøring, afprøvning og dokumentation af programmer

Transkript

1 It og informationssøgning Forelæsning december 2006 Nils Andersen Indkøring, afprøvning og dokumentation af programmer Indkøring Syntaksfejl Køretidsfejl Semantiske fejl Dokumentation Sammenfatning Problemorienteret analyse Programmeringsovervejelser Programbeskrivelse Afprøvning Brugervejledning Downey, Elkner & Meyers: Appendix A Andersen & Simonsen: kap. 13 1

2 Syntaksfejl Python-systemet fortolker programlinjerne, efterhånden som de præsenteres; fejl meldes omgående. Der, hvor fejlen opdages! Opbyg gradvis og modulært. Eller dan en kopi af programmet, og fjern programdele, til fejlen forsvinder. Hyppige fejl: Brug af reserveret navn som variabelnavn Manglende kolon Forkert indrykning Ubalanceret parentes- eller tekstkonstruktion Dynamisk lighedstegn (=) i stedet for sammenlignende lighedstegn (==) 2

3 Køretidsfejl Der sker ingenting: Kun erklæringer? Uendelig løkke? Ubegrænset rekursion? Sørg for basistilfælde! Indkreds problemet ved indsættelse af print-sætninger (før test, først og/eller sidst i funktioner)! Få overblik over programmets logik. Programafbrydelse: undtagelser. (Systemets fejlmelding viser stakken af suspenderede funktionskald.) Find simpleste tilfælde, der fejler. Ryd op / bryd ned / omskriv programmet. 3

4 Semantisk fejl Systemet udfører det programmerede forløb men ikke det ønskede forløb! Måske forkert mental model af sprogelement. Sørg for, det er den rigtige programtekst. Modulær opbygning: Nedefra-og-op : danne større helheder af allerede fungerende mindre byggesten, eller oppefra-og-ned : Trinvis forfining, hvor tilnærmende pladsholdere erstattes af uddybende detaljer. Problemløsning: Ansku fra forskellige synsvinkler Hold en pause Dan en ny løsning efter den første Beskriv problemet for en anden 4

5 Programdokumentation Et program er ikke kun instrukser, der skal få en maskine til at virke, men skal også støtte fejlfinding muliggøre udbygning fastholde beslutninger i en gruppe eller over tid muliggøre genbrug formidle indsigter Forslag til rapportstruktur: Sammenfatning Problemorienteret analyse Programmeringsovervejelser Programbeskrivelse Afprøvning Brugervejledning Bilag: Program Testudskrifter 5

6 Problemorienteret analyse Et program kan opfattes som en model af en isoleret del af virkeligheden. Analyser problemet, afgræns opgaven. Gør rede for uklarheder, selvmodsigelser, ufuldstændigheder og andre mangler, og præciser den opgave, som det vælges at løse. Afdæk genstandsområdets egenskaber og lovmæssigheder. Indfør gerne speciel terminologi til lejligheden! Afklar, hvad programmet skal gøre, uden nogen forpligtelse til hvordan (og uden henvisning til elementer i noget bestemt programmeringssprog). 6

7 Programmeringsovervejelser = systemorienteret syntese = programkonstruktion = software design Redegørelse for repræsentation og overordnet struktur. Gerne tegninger og diagrammer! Udfordringen ligger i at finde et niveau, der er højere end programmeringssprogets, uden at det dog bliver så højt, at forklaringen bliver indholdsløs. 7

8 Programbeskrivelse (Selve pro- Læsevejledning til programmet. grammet medgives som bilag.) Beskriv programmets statiske struktur (indholdsfortegnelse) og dynamiske struktur (hvilke dele aktiverer hvilke andre dele?) Forklar klasser og datastrukturer. Husk systematisk navngivning. Gør opmærksom på smarte tricks. 8

9 Afprøvning Empirisk: Man laver en fejl pr. ca. 20 programlinjer Der bør testes for hver ca. 40 programlinjer Man begår en ikke-triviel fejl for hver ca. 150 programlinjer Dobbelt formål: fejlfinding og dokumentation. Fejlfinding: Det betaler sig at afprøve løbende, mens man har den aktuelle programdels virkemåde præsent. Prøv omkring grænser (lige før, på, lige efter). Formålet er: at finde fejl; lad eventuelt en udenforstående konstruere data. Gør programmet afprøv-bart. 9

10 Forklar afprøvningssystema- Dokumentation: tikken. Opfat prøvekørsler analogt til et fysisk-kemisk eksperiment. Sammenlign en forudsigelse af udfaldet med det faktisk udfald. Vælg testdata, så der findes flest mulige fejl med færrest mulige prøvekørsler. Selve testkørslerne vedlægges som bilag, men refereres loyalt. 10

11 Brugervejledning Henvender sig til en anden type læser end de foregående rapportafsnit. Bør derfor ikke henvise til andre dele af rapporten (og slet ikke til programmet!) Færdiggøres sidst (men en skitse på et tidligt stadium kan være et nyttigt styringsredskab). Typisk struktur: Programmets overordnede funktion (nytte) Inddataformat Uddatas form og betydning: såvel egentlige resultater som fejlmeldinger Beskriv kun, hvad det konstruerede program selv har at gøre med (ikke maskinens knapper eller operativsystemet eller lignende). 11