Utvecklingsmetodik kursupplägg
Version 2.3 - 2012-10-24.
Lektionsinnehåll:
Förbered:
Lektionsinnehåll:
Förbered:
Lektionsinnehåll:
Förbered:
Lektionsinnehåll:
Förbered:
Lektionsinnehåll:
Förbered:
Lektionsinnehåll:
Lektionsinnehåll:
Förbered:
Lektionsinnehåll:
Lektionsinnehåll:
http://windwards.net/~quest/TIJ-3rd-edition-html.zip
http://windwards.net/~quest/TIJ-3rd-edition-code.zip
Boken gör många jämförelser med andra språk. Detta är sällan relevant för oss och kan betraktas som överkurs.
Boken har många övningar. De är ofta summariskt beskrivna. Undvik att fastna på en uppgift vare eller gräva ned dig för mycket. Exempelvis 7.6 säger "In the base class, provide methods that are common to all Rodents" vilket är lätt att tolka för ambitiöst. Gå istället vidare.
Extensivt. Motsvarar grovt kapitel 7 (Better Living in Objectville) och är tämligen pratigt. Innehållet är viktigt, men många har svårt att ta till sig den här typen av teoretisk text. Lägg inte för mycket tid här.
Intensivt. Delar överlappar tidigare kurser, men mycket är nog nytt, så hoppa inte för långt fram om du tycker att du redan behärskar det du läser.
Viktiga övningar: 2, 5, 7, 8, 10.
Extensivt. Det mesta av detta kapitel har täckts av tidigare kurs och det är mitt intryck att ni behärskar de grundläggande operatorerna, villkors- och iterationssatserna. Läs efter individuell behållning.
Intensivt. Långt men viktigt kapitel. Stycket "Cleanup: finalization and garbage collection" är överkurs i den här kursen och kan läsas extensivt eller hoppas över. Stycket om flerdimensionella arrayer kan läsas extensivt. Viktigt att göra övningar i kapitel 4.
Viktiga övningar: 1-5, 8-10, 14-18.
Viktigt, men pratigt kapitel. Stycket “Creating unique package names kan hoppas över.”
Viktiga övningar: 5-8, 10.
Intensivt. Dessa kapitel beskriver grunderna i objektorientering a la Java. Viktigt att göra åtminstone några av övningarna.
Intensivt, utom stycket "Abstract classes and methods" som kan läsas extensivt.
Viktiga övningar: 1-5, 8-9, 11-13 (strunta i gnagarna)
Intensivt till "Initializing fields in interfaces." Skumma delen om inre klasser; medan de är praktiska, finns det nästan inget tillfälle där man måste använda inre klasser. Viktigt att göra övningarna (om interface) här.
Viktiga övnignar: många övningar, men viktiga, gör så många du orkar.
Den första och viktigaste metoden för ett disciplinerat förhållningssätt till programmering är testdriven programmering.
Kapitel 1 ur boken The Art of Unit Testing sammanfattar mycket bra vad ett enhetstest är:
http://manning.com/osherove2/AUT2e_meap_ch01.pdf
En kort tutorial som hjälper dig att komma igång med enhetstestning under Eclipse:
http://www.vogella.com/articles/JUnit/article.html
Följ introduktionen till och med 3.4. Resten är överkurs. Tutorialen är för förra versionen av Eclipse, så skärmbilderna kommer inte att stämma exakt.
Nedan finner du en testsvit till en miniräknare. Implementera de tomma klasserna så att alla enhetstest passerar.
https://bitbucket.org/quest/calculator-tests
Dosan som läser ditt kort på spårvagnen kallas en validator. Nedan finner du en testsvit för en enkel validator. Implementera de tomma klasserna så att alla enhetstest passerar.
https://bitbucket.org/quest/pt-validator-tests
Tips: låt dig inte förvirras av att Storage.store() tar en parameter “credit”; denna behövs inte förrän i T4.
Ett problem med biljettsystem som kräver “utcheckning” är att folk glömmer att checka ut. Förbättra validatorn från T3 så att den kommer ihåg innestående fordringar och i stället debiterar kortet nästa gång resenären stiger ombord (första meddelandet i displayen ska informera om detta).
Validator.endStation() anropas när föraren loggar ut från fordonet när turen avslutats. Då har alla passagerare lämnat fordonet.
Försök så långt som möjligt att skriva testen före implementationen.
Nedan finner du en serie enkla klasser. Skriv enhetstester för relevanta delar av dessa klasser. Notera att klasserna innehåller detaljerade instruktioner och tips.
https://bitbucket.org/quest/unittesting-exercises
Nedan finner du en enkel addressbok som fungerar med inmatning på kommandoraden. Skriv en testsvit för denna. I sitt nuvarande skick kan den vara svår att skriva enhetstester för. Det ingår därför i övningen att modifiera produktionskoden så att den går att testa ordentligt. Var försiktig, så att du inte ändrar dess beteende.
https://bitbucket.org/quest/addressbork-src
Om du hellre vill, kan du istället välja att skriva en testsvit för din egen eller någon medstudents addressbok för examinationen i föregående kurs.
Först, några artiklar som introducerar konceptet versionshantering:
http://guides.beanstalkapp.com/version-control/intro-to-version-control.html
http://betterexplained.com/articles/a-visual-guide-to-version-control/
Kursen kommer att använda versionshanteringsverktyget Mercurial. Mercurial är modernt och låter oss öva på alla versionshanteringens arbetsmoment.
Det går att få Mercurial-integration i Eclipse.
TortoiseHg rekommenderas. Försäkra dig om att du kryssar i Shell Extensions under installationen. TortoiseHg kan även användas som kommandoradsklient. Se tutorial i V1.
Installationspaket för kommandoradsklienten för MacOSX. För grafiskt gränssnitt kan man använda MacHg.
På en Ubuntu eller Fedora-installation bör både kommandoradsklienten Mercurial och TortoiseHg gå att installera via den vanliga pakethanteraren.
Vår huvudkälla till visdom om Mercurial är boken “Mercurial: The Definitive Guide.” Den återfinns i sin helhet här:
http://hgbook.red-bean.com/read/
Boken är omfattande och delar av den täcker ämnen mer avancerade än vi behöver för denna kurs. Följ anvisningarna nedan när du läser boken.
Läs extensivt och insup terminologin. Jämförelser med andra verktyg är i första hand för den intresserade.
Centralt kapitel. Försök göra övningarna själv. Läraren kommer att hålla en introduktion.
Centralt kapitel, men svårt koncept. Att “merga” är ganska vanligt, men det kan vara svårt att relatera till. Experimentera gärna. Läraren kommer hålla en introduktion.
Frivilligt: ingen behöver veta hur en bensinmotor fungerar för att kunna köra bil. Den främsta behållningen av kapitlet är som beskrivning av designen av välgjord mjukvara.
Centralt kapitel. Försök följa med övningarna. Referera till detta kapitel när du versionshanterar dina uppgifter under kursen.
Avancerad funktionalitet som vi kommer att återkomma till i senare kurser när våra mjukvaruprojekt blir större.
Läs extensivt. När du utvecklar och inser att du vill ångra något du gjort i ditt arkiv, återkom till detta kapitel och läs om hur du backar ur ändringar du gjort.
Studenten gör en tutorial för att bekanta sig med TortoiseHg och kommandoradsverktyget. För grafiska klienter, följande tutorial:
http://tortoisehg.bitbucket.org/manual/2.4/quick.html
Om du väljer denna tutorial, se till att göra den både med det grafiska gränssnittet och med “thg.” De flesta exemplen i Mercurial-boken använder kommandoradsgränssnitt, så det hjälper om du är bekant med det.
För den som föredrar att göra tutorial med kommandoradsklient, se:
http://mercurial.aragost.com/kick-start/en/
I denna tutorial, fokusera på kapitlen Basic Mercurial, Task Based Development och Remote Repositories.
Läraren tillhandahåller ett arkiv med successiva ändringar i en HTML-fil, men helt utan loggmeddelanden och studenterna skriver loggmeddelanden utifrån de ändringar som gjorts. Övningen går framför allt ut på att förstå diff.
https://bitbucket.org/quest/mercurial-diff-exercise
Beskriv i stora drag vad som sker vid varje version på ett sätt som gör det lätt att hitta rätt senare.
Källan till Mercurial-boken är tillgänglig som ett Mercurial-arkiv på:
https://bitbucket.org/bos/hgbook
Boken är skriven i docbook-format. Se dig om i de olika filerna för att se hur man formulerar sig i DocBook XML.
Den programmering vi kommer att träffa på under kursen täcks åtminstone delvis av kursboken för föregående kurs. Här kommer några tips om vilka delar som är relevanta att läsa (eller repetera).
Kapitlet beskriver begrepp som ligger till grund för mycket av den kod vi ska producera. Om du känner dig osäker på något av begreppen häri, bör kapitlet repeteras.
Medan kursen inte kommer att beröra abstrakta klasser eller polymorfism nämnvärt, kommer vi att arbeta mycket med interface. Denna del av kapitel 8 bör studeras ingående.
Studera gärna kapitlet i anslutning till kalkylator-övningen. Beroende på vald implementation, kan till exempel styckena om autoboxing och decimaltal kan komma väl till pass.
Både tester och implementation kommer att innehålla felhantering. Kapitlet bör studeras ingående.
Set, mappar och listor är våra viktigaste datatyper. Flera av uppgifterna i denna kurs kräver grundläggande förståelse för dessa, så kapitel 16 bör studeras ingående.
Den senare delen av T2 kräver att vi hanterar decimaler. Det finns två fundamentalt olika sätt att göra detta. En kort introduktion.
Med @Test träffar vi vår första annotering. Annoteringar blir allt mer populära, särskilt i de stora bean-ramverken. För att förstå annoteringar måste vi också förstå begreppet introspektion.
Programmerare kan förefalla timida varelser. Då har man inte sett dem när sommartidsomställning kommer på tal. Härmed en introduktion till en av de största felkällorna i ett typiskt komplext informationssystem.
När for-looparna snurrar lika mycket i skallen som i datorn tar vi paus med en översiktsföreläsning.
Var står vi efter två introduktionskurser? Vart går vi härnäst?
http://prezi.com/lb0lzxgssrjk/utvecklingsmetodik/
En introduktion till begrepp som behövs för att kunna tala om mjukvara.
Begreppet krav är mycket centralt i all systemutveckling. Mediespelarprojektet innehåller en lista med krav. Dessa blir en utgångspunkt i denna introduktion till kravställning.
http://blog.thingsdesigner.com/uploads/id/tree_swing_development_requirements.jpg
Hur lite krävs för att lösa ett problem och varför är det så viktigt att undvika overkill?
Den mesta systemutveckling sker i grupp. Vad betyder det i praktiken?
Källkod är naturligt språk med vilket vi kommunicerar med andra utvecklare, både samtida och framtida. Vad betyder detta för oss som utvecklare?
Grupper om 4-5 studenter ska implementera en enkel mediaspelare. Projektet ska träna arbete i team, enhetstestning och versionshantering.
Teamet ska leverera ett Mercurial-arkiv med en enkel mediaspelare. Det går bra med en zip-fil som bilaga, en Bitbucket-URL eller motsvarande. Denna mejlas senast torsdag 1/11 12:00 till javautvecklare@quest.windwards.net.
Fokus i denna övning är att producera bakändan till en mediaspelare som möter kraven nedan. Jag rekommenderar starkt att teamet också implementerar ett gränssnitt av något slag (till exempel konsoll eller Swing); det blir annars svårt för teamet att vara säkert på att mjukvaran verkligen fungerar enligt förväntan. Gränssnittet ingår inte i bedömningen.
Här gives ett enkelt ramverk som hjälper teamet att komma igång. Det finns inget krav att använda detta ramverk. Det går också bra att ändra på det efter behov.
https://bitbucket.org/quest/mediaplayer-framework
Ramverket innehåller hjälpklasser som gör det lite enklare att skriva enhetstester för spelarlogiken.
Projektets inlämnade arkiv kommer att bedömas på, i fallande prioritetsordning:
Godkänt: 15 p, Väl godkänt 20 p.
Några praktiska tips som hjälper er få poäng:
Om teamet blir inspirerat och vill lägga till mer funktionalitet än den som motsvarar kraven nedan, gör det i ett parallellt arkiv, så att du har ett slimmat arkiv ni kan skicka till läraren.
Efter avslutat projekt kommer ett kort seminarium där vi tittar på de olika implementationerna. Syftet är att öva på att beskriva, läsa och förstå källkod.
Varje krav motsvarar grovt sett en metod som kan användas av ett gränssnitt. Om frågor uppstår om kraven, be om komplettering av läraren per mejl eller vid handledningstillfälle.
Ger gränssnittet en lista tillbaka i den ordning låtarna har/kommer att spelas.
Används av ett gränssnitt för att efterfråga aktiv låt.
Gränssnittet ska kunna ge mediaspelaren en referens till ett objekt som implementerar en lämplig metod som mediaspelaren anropar med låten varje gång en ny låt blir aktiv.
Metoder med vilka gränssnittet kan starta respektive avbryta spelning av låt som tidigare satts som aktiv. Multipla anrop har ingen vidare effekt. Det krävs inte att spelning automatiskt fortsätter till nästa låt (se MP-9).
Användaren går till en specifik låt, till exempel genom att klicka i ett grafiskt gränssnitt.
Så fort en låt har spelat färdigt, ska nästa låt sättas aktiv och påbörjas så länge det finns låtar i listan.
javafx ingår i J2SE från och med 1.7.0-07. För tidigare version måste javafx installeras separat. Ramverksprojektet innehåller därför en andra version av API:et som heter net.windwards.mediaplayer.appletimpl som bygger på java.applet.AudioClip, som kan användas om du måste utveckla på en dator där det är svårt att få javafx att fungera. Kom bara ihåg att AudioClip inte kan användas för att lösa MP-9.
För att ladda ned separat JavaFX:
http://www.oracle.com/technetwork/java/javafx/downloads/index.html
