Drakborgen. - Tips och rekommendationer. III. Tillvägagångssätt. Abstract. I. Inledning. II. Beskrivning av spelet

Transkript

1 Drakborgen - Tips och rekommendationer Av Per Hamrin, IT05 Abstract Utbildningen inom programmering är under förändring på Uppsala Universitet. Ett av kursmomenten består av att designa och implementera brädspelet Drakborgen. Rapportens avsikt är att ge information, rekommendationer och åsikter utifrån min roll som utvecklare, handledare och student på det gamla programmet. I. Inledning Tidigare har studenterna på Uppsala Universitet både fått bekanta sig med java och objektorientering inom samma kurs. I den nya kursen så kommer studenterna redan ha läst en kurs där de använder java och har gått igenom grunderna inom programmering, och betraktas vara tillräckligt vana vid java för att designa och genomföra en implementation av Drakborgen. Under sommaren 2008 jobbade jag med att ta fram en implementation av Drakborgen med grundläggande funktionalitet. Under följande hösttermin var jag handledare i den gamla kursen för objektorienterad design & programmering. Under den tiden var min uppgift att skriva en uppgiftsspecifikation samt att assistera 4 studenter med att designa och implementera Drakborgen istället för den vanliga uppgiften som ges under kursen. II. Beskrivning av spelet Brädspelet Drakborgen släpptes av ALGA 1985 och expanderades senare med extramateriel. Spelet är för 1-4 spelare. Spelbrädet har ett rutnät där brickor läggs ut. Brickorna representerar en labyrint och läggs ut allt eftersom spelare rör sig på spelplanen. I början av varje drag väljer spelaren om han vill flytta sig, söka i det rum han står i efter skatter eller använda en förmåga. Resten av draget kommer vara en reaktion på hur labyrinten ser ut och vad spelaren drar för kort. Spelet går förenklat ut på att samla på sig så mycket skatter som möjligt i labyrinten och ta sig ut innan speltiden tar slut med livet och skatterna i behåll. III. Tillvägagångssätt Under HT08 gjordes en utvecklings- och provomgång där jag agerade handledare åt fyra studenter som var intresserade av att prova att göra spelet istället för den vanliga inlämningsuppgiften. Jag utformade uppgiften löpande under terminen och såg till att studenterna hade ett mål att jobba mot. Arbetet delades upp i två faser och begränsningar sattes för hur stor del av olika fällor, monster och andra spelegenskaper som skulle innefattas av uppgiften. Design: Under designfasen hade vi möten 1-2 ggr i veckan, då vi diskuterade spelet, koncept runt objektorienterad design, så som designpatterns och design by contract och hur det kommer påverka studenternas jobb. Studenterna fick som uppgift att ta fram ett heltäckande klassdiagram över hela programmet och under ett av mötena hade vi som huvuddiskussion att rita upp ett interaktionsdiagram över hur de olika klasserna interagerar med varandra och på så sätt hitta luckor i interfacen. Stor vikt lades vid att hålla rena interface mellan klasserna och se till att inga överflödiga kontaktpunkter fanns. Ungefär halva kurstiden gick åt denna fas och studenterna fick inte skriva någon kod under denna fas. Implementering: Under programmeringsfasen skulle drakborgen implementeras efter studenternas design. Detta gick mycket bra och mycket få möten hölls under denna fas. Under mötena hade studenterna lätt att dela upp arbetet mellan sig. Studenterna skrev sina delar av programmet utan att konflikter uppstod när de sedan sammanförde de olika delarna. En stor anledning till att implementeringsfasen gick bra berodde på att studenterna var mycket väl insatta och engagerade i uppgiften, vilket jag tyder

2 som en konsekvens av att de själva varit så insatta i designarbetet. Även användandet av versionshantering har spelat roll i att arbetet gått bra. Resultat: Efter deadline finns ett körbart spel som följer studenternas design väl, har väldigt få buggar och koden är i bra skick vad gäller dokumentation och struktur. Innehållet är relativt begränsat till en eller ett fåtal typer av monster, fällor, skatter etc. Detta var enligt planen. tänka när jag ska lägga ut brickorna på planen etc. 3. Uppgiftsbeskrivningen är viktig Ge studenterna en komplett uppgiftsbeskrivning så tidigt som möjligt. Motivering: Eftersom uppgiften framarbetades parallellt med att studenterna utförde uppgifterna så fanns ej en fullständig uppgiftsplan att tillgå. Eftersom drakborgen är spel med många regler och specialfall, se till att verkligen specificera vad som ska och vad som inte ska implementeras. De saker som ej hann bli klara i tid finns med i designen men hann ej bli implementerade. Brister: Den slutliga inlämnade koden blev inte helt färdigställd p.g.a. vaga krav från mig som handledare samt andra faktorer så som tidsbrist och tentaperiod mm. Det som ej blev implementerat var: Genomsökning av rum En fullständigt fungerande skattkammare med skatter och en drake. IV. Slutsatser och Rekommendationer Nedan följen en lista med tips och rekommendationer från min sida: 1. Spela spelet Låt studenter spela spelet så snart som möjligt, helst första dagen och tillsammans med någon/ några som spelat det förut. Motivering: Drakborgens regelbok är stor och förvirrande och allt verkar väldigt skrämmande i början av en sådan uppgift. Att spela tillsammans med någon mer erfaren spelare rekommenderas starkt eftersom de då kan få information löpande tillsammans med tips på hur man kan jobba med de olika elementen. 2. Tillgång till spelet samt regler Låt studenterna ha tillgång till spelet om möjligt. Motivering: Det finns många olika brickor, regler och specialfall som underlättas om man kan se det framför sig, t.ex. Hur blir det om man står X och vill gå Y men det är en vägg där?, Hur ska jag 4. Versionshantering Se till att studenterna får tillgång till SVN/CVS samt att de har kunskap om hur den används i god tid innan kodningsarbetet startar. En inledande laboration där grundläggande versionshantering introduceras. Bra punkter att ta upp är hur man använder sig av diff, för att se vad som ändrats och skillnader mellan checkout och update är värt att ta upp. Motivering: Kunskapen om versionshantering varierar ofta och problem kan enkelt avvärjas om studenter fått bekanta sig med det innan. Bra gratis alternativ för studenter är t.ex. googlecode ( eller BeansTalkApp ( Det underlättar att använda versionshantering om studenterna växelvis jobbar hemifrån eller från laptops eftersom de då inte behöver ha manuell koll på vilken fil som innehåller de senaste ändringarna och kan utnyttja verktyget för att få hjälp med integration mellan revisioner. 5. Verktyg Tipsa tidigt om vilka program de kan använda i olika syften: Motivering: Det underlättar ifall studenterna har något program att modullera UML i, istället för att skissa för hand. Detta gäller även program för kodning.

3 Programtips: UML: Visual Paradigm har en bra programsuit där man ladda hem och använda en community edition där bl.a. en bra UML editor ingår. Denna användes under höstterminens kurs och studenterna var mycket nöjda med funktionaliteten. Kodning: Beroende på vilken plattform studenterna använder så finns olika verktyg att använda. Självklart finns även emacs till alla plattformar. Windows: Personligen skulle jag rekommendera notepad++ (gratis) över eclipse/netbeans ifall studenterna inte har tidigare erfarenheter av IDE'er, vilka ibland kan vara svåranvända om användaren inte är bekant med miljön. OS X: TextMate (ej free-ware) har många bra egenskaper för en editor. Smultron är en bra editor med syntaxhighlighting etc. även här rekommenderar jag editor över IDE'er. *NIX: En trevlig editor till linux är Geany, som utöver editor med syntax hightlighting ger möjlighet till terminal i editorn samt har ett antal bra plugins. Övrigt Jag har läst om ett program vid namn BlueJ i en rad artiklar som behandlar utlärning av objektorienterad programmering som antagligen är ett bra verktyg, då jag vet att det används i andra kurser på institutionen. Jag saknar egen erfarenhet av programmet men klassdiagrammet kommer gratis när man skapar klasser, det går att köra metoder utan att skapa en main metod etc. SVN klienter: OSX+*NIX: Terminalen är det jag föredrar då den är enkel att använda. Win: TortoiseSVN är lättskött och fungerar bra. Rekommenderas. Om eclipse används så finns även en SVNplugin. 6. Gruppstorlek Genomför ej projektet i helklass. Motivering: Ju fler kockar desto sämre soppa, eftersom uppgiften i huvudsak ett designproblem så kommer diskussioner och möten vara nyckelfaktorer i att få projektet att fungera. Detta fungerade mycket bra med en grupp på 4 personer + mig som handledare. Då jag pratat med studenterna från HT08 tror de inte att det skulle fungera att hålla uppgiften som helklass eller ens halvklass uppgift. Rekommenderad gruppstorlek är 4-8 personer. Ett förslag på hur det skulle kunna fungera i helklass är att ha mindre grupper (2-4 personer) under designfasen som sedan slås ihop 2 och 2 till implementationsfasen så att en större grupp kan implementera en gemensam lösning. Med en större grupp under implementationsfasen kan man sätta färre begränsningar på spelet. Problem med små grupper: Att få tag på ett antal spel för alla grupper samt att kunna handleda dem. 7. Kunskap om objektorientering Diskutera OOP principer och hur de tillämpas i detta fall redan under designfasen eftersom det är då studenterna planerar och har lättare att anpassa sin plan innan den skrivs i kod. Motivering: Nu har studenterna äntligen chans att se en poäng med mycket av den teori de har läst. Försök gärna hitta exempel på när olika patterns t.ex. factory och singleton kan användas i designen. 8. Interaktionsschema Använd en deluppgift eller ett möte till att reda ut hur alla deras klasser interagerar med varandra. Motivering: Det är enklare att upptäcka luckor i klasslogiken genom att reda ut vad som egentligen sker när man går runt i labyrinten, slåss och drar kort. Vilka av metoder som specificerats i klassdiagrammen anropas och vilka argument skulle användas. Dessa fel är svåra och jobbiga att rätta till när spelet lämnat designstadiet och om man endast designar alla klasser utan att testa funktionaliteten.

4 9. Specificera begränsningar Ge studenterna gärna begränsningar i vad som ska utföras. Motivering: Det finns många specialfall i drakborgen. Begränsa gärna mängden sådan som ska implementeras så att t.ex. inte 8 olika sorters fällor som i princip gör samma sak(ofta skadar eller dödar spelaren) implementeras innan en spelare kan gå, slåss och dra kort. Jag bifogar två versioner av manualen. En ren version och en kryssad version där jag tagit bort många delar. 10. Uppmuntra testkod och testning av kod. Motivering: Uppmuntra studenter att skriva dumma testfall för att testa små kod-snippets som de inte är säkra på hur den fungerar. Ex. Hur fungerar det egentligen med listor, jag skriver en klass ListTest.java där jag testar bl.a. om man kan ta bort huvudet på en lista. Även om mycket går att läsa i API och liknande så blir man sällan så säker på något som när man testar själv. innebär att man inte kan generera någon javadoc. En javadoc är till god hjälp när en handledare ska förstå koden samt bra för studenterna själva. 14. Tänk efter hur mycket kod studenterna ska få från början. Eftersom studenternas design kan skilja sig rätt mycket i namngivning och funktion från den kod jag skickar med som bilaga så riskerar en allt för strukturerad ifyllnadsövning att minska studenternas engagemang och göra det svårare för dem. Målet med designfasen bör vara en komplett design med hög detaljnivå som bör vara så tydlig att studenterna inte har svårt att implementera den till körbar kod. Enligt mina erfarenheter så gick implementationen mycket bättre för mina studenter än för mig i någon tidigare kurs som jag läst. Studenterna verkade mycket nöjda med sin insats och har blivit mer motiverade att implementera sina idéer och lära sig mer om OOD principer 11. Använd paket Motivering: Drakborgen innehåller många saker som blir egna klasser. Det blir omöjligt att ha allt detta i defaultpaketet vilket innebär en mapp på som alla filer ligger i. Hänvisa även till god OOD sed. Detta sammanfattar i mångt och mycket de tips jag kan konkretisera utifrån mina erfarenheter både som implementatör utan handledning (sommarjobb -08) och som labbhandledare. 12. Kompilera inte till samma mapp som källfilerna Motivering: Av samma anledning som ovan kan det vara bra att hålla.class skilda från.java filer. görs mha javac -d målmap t.ex:../build målfil t.ex: Drakborgen.java Detta kompilerar Drakborgen.java och allt som den anropar till en systermapp. Kan vara bra om man t.ex. har filhierarki med en mapp build och en mapp source brevid varandra. 13. Javadoc Upplys om hur javadoc kommentarer skrivs samt hur en javadoc genereras utifrån.java filerna. Motivering: Mina studenter har skrivit kommentarer om hur alla funktioner fungerar men de har använt felaktig syntax för javadoc vilket

5 V. Bilagor 1. Min kod, designad av mig som för grund för test HT08. Tanken var initialt att studenter skulle få bitar av koden, men i slutändan så hade begränsat mer än hjälpt dem. Många klasser kan göras om till fylla i övningar av varierande svårighetsgrad. Just nu är min kod inte körbar p.g.a. pågående förändringar för att integrera min implementation med HT08 studenternas design för att kunna ge dem bitar av koden. Detta projekt avstyrdes efter ett tag med motivationen att det helt enkelt inte hade varit så givande och jag lät dem börja utan någon kod alls. 2. Den kod som producerats av Studenterna. Körbar men med brister som listas i översiktskapitlet. 3. Studenternas UML diagram 4. Inscannade manualer både med och utan överkryssade rekommendationer 5. Spreadsheet med data om monster och deras hp, skada mm. 6. Den enkät jag designade och bad HT08 studentera besvara som en egen utvärdering av uppgiften. 7. Liten guide hur man använder och installerar SVN i windows. 8. Möteslogg med kommentarer. 9. Inluppsförslag.