Programmering, abstraktion och modellering PROJEKTFÖRELÄSNING ANDERS MÄRAK LEFFLER IDA/HCS

Transkript

1 Programmering, abstraktion och modellering PROJEKTFÖRELÄSNING ANDERS MÄRAK LEFFLER IDA/HCS

2 Idag Idag: Övrig information Vad är projektet? Hur går det till? Strukturerande (I-III) Allmänna tips LaTeX-föreläsning 2

3 Ortogonalt mot projektet ÖVRIG INFORMATION 3

4 Övrig info Direkt kursrelaterat Labb 5. Dugga 2 anmäl er! Inga oanmälda får komma in! Dagens föreläsning. Mycket material (att återvända till). Principer och riktlinjer, ej givet hugget i sten. 4

5 Översikt VAD ÄR PROJEKTET? 5

6 Vad är projektet? Ungefärlig arbetsgång: 3hp ~ 2 veckor, räkna ~80h/pers. Görs i par. Liknande nivå (jämnt arbete, diskussion). Liknande ambitioner. Betygssättning U/3/4/5 (K) 6

7 Betyg Huvuddrag Ren kodmängd premieras inte! Dö inte. Kodkvalitet. Stil, abstraktioner med mera. Koncept, utbyggbarhet. Ex: Utbyggbart litet RPG med grafiskt gränssnitt slår stor spelvärld med rätt hårdkodad värld. Gör något roligt*. 7

8 HUR GÅR DET TILL? 8

9 Hur går det till? Resursgenomgång Översikt. Plan. Resurser, specificerande. Grafik. Tommy Karlssons miniföreläsningar. 9

10 Marginellt större projekt STRUKTURERANDE I 10

11 Strukturerande Tentativa frågor Vad behöver vi beskriva? Data, datatyper. Vad för delar på hög nivå har programmet? Hur talar de med varandra? ~Hur hänger allt ihop? 11

12 Mellanspel Labb 5 och look. Ett kommandos väg. 12

13 OOP STRUKTURERANDE II 13

14 Berör många, men inte alla projekt Helt eller delvis. 14

15 OOP-repetition Objekt...har tillstånd Ex: Spelkaraktär vet sin plats, uppdateras....är isolerade. Begränsat vad de vet och påvekar. Ex: en character% vet bara vilken plats den är på. En place% vet bara vilka som är där...har gränssnitt. Hur man interagerar med dem, och vad de gör då. Ex: move-to (med flera) hos character%....bär sitt beteende. Ex: character% har sin egen move-to (inte något externt, som (settriple-left! ) 15

16 OOP Modellering bygga projekt Vad finns det för saker i världen eller i programmet? Ex: spelkaraktärer, platser, Kanske en spelomgång Ex: ett användargränssnitt (tänk adventure-ui%). Ex: Super Mario-spel: kanske poängräknaren? En?-låda? (OBS, exempel!) Vad har de för ansvar? Ex: Har character% ansvar för att informera tidigare plats om var den är? Har platsen det? 16

17 Vilka uppgifter ska lösas av olika delar? Ansvar. Se OOP-föreläsning, kompendium 17

18 Programstruktur övergripande STRUKTURERANDE III 18

19 Vilka delar har programmet? Bygga projekt på strukturnivå Vad är data och vad är logik? När och hur möts de? Ex: nuvarande schackbräde respektive regelmotor. Ex: Pacman är på (r,c) respektive det som flyttar Pacman framåt. Hur kommer presentation/visning in i det hela? Ex: Har en character% ansvar för att skriva ut saker? Något annat? Försök att inte blanda ihop detta! 19

20 (Till kodande) Filstruktur säger något om programstruktur Ha inte allt i en fil. 20

21 Filstruktur Ha en logisk filstruktur för olika delar av projektet. Ex: item.rkt för klassdefinition item%. Inget mer. character.rkt för character%. Inget mer. Ex: datatyper i graph_representation.rkt, logik i andra require/provide-paret. Säger något om beroenden. 21

22 Filstruktur Filstruktur Tumregel: det ska gå att rita ett logiskt schema över require-beroenden, utan cykler. Ex: item inte beroende av något. world_init behöver item-definitioner (med mera). Rita pil world_init till item. Fortsätt. Ser ut som ren filstruktur, men säger också något (litet) om separation! Gör detta kontinuerligt inte vi fixar det på slutet (kanske upptäcker man konstiga beroenden) 22

23 Specifikation SPECIFIKATION (INLÄMNING!) 23

24 Projektspecifikation Projektspec Vad gör vi? Ambitioner? Krav Nedbrytning av arbetet i mindre delar. Ungefär när (ordning)? Ex: Labb 5. Först grundläggande objekt i världen, sedan koppla ihop världen, lägga till kommandon, UI (Se exempelspec!) Översiktlig bild av struktur, datatyper 24

25 Projektspec Huvudsakliga mål Specifikation - kravlista. Hör ihop med projektval och betygsambitioner. Ändras inte när den är godkänd (utan handledare) Handledaren ser struktur på projekt, eller brist på struktur (och kan kommentera!) 25

26 Tumregler ALLMÄNNA RÅD 26

27 Versionshantera (även av tekniska skäl dålig rutin, men talande bild) 27

28 Versionshantera Rekommendation: git + Gitlab Helt frivilligt! Dela kod. Håll koll på framsteg. Kunna rulla tillbaka. Föreläsning 17/

29 Läsbarhet Din kod ska inte bara vara läsbar för kompilatorn*. Du skriver för andra programmerare. 29

30 Läsbarhet Ett par tumregler Namngivning. Är det meningsfullt i applikationen? Ex: set-neighbour-visited! vs change-flag1-cadrtrue! Hur ser det ut i funktioner som anropar? Ex: (let ([next (nearest-neighbour cur-node graph)])..) OBS! Gör lätt att felsöka logiken (troligen trasig här ovan!). Gör funktionerna vad de ska, och inget mer? 30

31 Läsbarhet+ansvar Ett par tumregler Struktur och läsbarhet: gör funktionerna vad de ska, och inget mer? Ex: nearest-neighbour ska inte ändra i grafen. Ex: update-gui ska inte flytta på Pacman, den ska uppdatera GUI. Viktig följd: funktioner som anropar ska inte räkna med sådant! nearest-neighbour tar fram närmsta, men vi vet ju att den också ändrar i variabel X, så vi använder det... Viktig följd: ni ska inte behöva ta hänsyn till det! Ändring i nearest-neighbour ska inte göra att annat plötsligt slutar fungera. Finstilt: Funktioner kan göra flera saker*, men det ska vara tydligt. Det blir det sällan här. 31

32 men vi vet ju att -test Antyder att man vill tänka efter noga innan man går vidare. 32

33 Rubber duck debugging 33

34 Testning och struktur Testa era procedurer! Tänk på ordning! Vad bygger på vad? Ordning, testbarhet. Gå att lita hyfsat på saker längre ned. Klick på ruta (r,c) gör inte vad det ska. Är det GUI:t som skickar fel data? Spelmotorn som gör fel beräkning? Brädet som inte utför uppdatering? Refaktorering (code refactoring). En funktion (eller dylikt) gör samma sak, men på annat vis. Ex: Optimera flights-from-to utan att ändra inargument eller utdata. (Eller ev sidoeffekter.)...men bli inte för låsta! Våga experimentera. 34

35 Till projektlektionen 1. Välj projekt (nu!) 2. Läs igenom exempel-specifikationen. 3. Fundera på struktur bitar av programmet på översiktlig nivå. Inget inlämningskrav där (förbered för lektionen!) 35

36 DON'T PANIC 36

37 Frågor? Attribution: - Hello Ruby by Hello Ruby is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. - git fire-bild, angiven upphovsman Ladsgroup ( ) 37

38