Föreläsning 9: Projektintroduktion, programmeringsmetod, samt att skapa körbara program och dokumentation

Föreläsning 9: Projektintroduktion, programmeringsmetod, samt att skapa körbara program och dokumentation Eva Blomqvist eva.blomqvist@liu.se Linköpings universitet Sweden December 4, 2013 1

Innehåll Information om projektet OO-analys och design Dokumentera kod Javadoc Skapa körbara filer December 4, 2013 2

Projekt December 4, 2013 3

Varför projekt? Ett mellanting mellan ett "verkligt" utvecklingsprojekt och en labb Ni är inte riktigt mogna för att skapa ett helt eget program efter en egen idé - det blir lätt för svårt...samtidigt ska den här kursen ge er en första inblick i hela processen, från krav till färdigt program (även fast vi hoppar över många viktiga steg, t ex systematisk testning) Projektet i kursen Lite större uppgift Ni jobbar med samma problem i ca 8 veckor Ni designar systemet och skriver koden - men kraven finns färdiga och handledarna styr er i rätt riktning December 4, 2013 4

Hur går det till? Ni väljer en uppgift Banken Biblioteket Gymmet Ni får en kravspecifikation för systemet + datafiler och ett kodskelett för att komma igång med inläsning från fil Ni analyserar kraven och designar systemet (på papper) Ni implementerar (och testar) systemet Ni dokumenterar systemet Ni demonstrerar den färdiga lösningen för handledaren Ni lämnar in kod + dokumentation + rapport December 4, 2013 5 Analys och design: 17/1 Inläsning från fil: 31/1 Demo + inlämning: 21/2

Projektet - examination Tre obligatoriska handledarmöten Diskutera er design (= systemet på papper, lista på klasser med variabler och metoder osv) - senast 17/1 (rekommenderat: innan jul!) Diskussion inte "examen" - handledaren kommer hjälpa er komma på rätt spår Diskutera er lösning för inläsning från fil och hur ni skapar och hanterar de nya objekten (= alla klasser skapade, vissa kommer inte ha något "innehåll", inläsning och instansiering fungerar) - senast 31/1 (rekommenderat: v. 3-4) Diskussion inte "examen" - handledaren kommer hjälpa er komma på rätt spår Demonstrera färdig lösning - senast 21/2 Examination - allt ska fungera, testa i förväg OBS! Båda i gruppen måste närvara och båda i gruppen måste kunna svara på frågor och beskriva vad ni har gjort! December 4, 2013 6

Projektet - examination (forts.) Betyget på projektet avgör slutbetyget i kursen OBS! Ni måste dessutom ha uppfyllt alla deadlines i både labbkursen och projektet och klarat duggorna, för att kunna få VG Ni väljer själva ambitionsnivå i projektet - G resp. VG-krav Godkänt Systemet uppfyller alla grundläggande krav (G-krav) i kravspecen Ni demonstrerar ert projekt och lämnar in innan sista kompletteringsdeadline 28/3 - handledaren godkänner Väl godkänt Systemet uppfyller alla G-krav + ett av VG-alternativen GUI eller databaskoppling eller 4 extra krav Ni har haft alla möten innan deadline och lämnat in er lösning innan 21/2 Komplettering fortfarande ok fram till 28/3 December 4, 2013 7

Projekt - att tänka på Börja i tid! Ni hinner inte om ni fokuserar först på labbarna och sedan projektet - ni måste jobba parallellt Sikta på de rekommenderade tiderna för handledarmöten snarare än deadlines ER handledare är där för att hjälpa er komma vidare! Handledarna prioriterar frågor om labbarna fram till 31/1 Boka tid för möten utanför labbtid med ER handledare Tänk på att ni även ska lämna in rapporten 21/2 - börja skriv den i god tid Det är ok att dela upp uppgiften mellan er, men......båda måste kunna förklara hela lösningen för handledaren Kommentera koden noga! Är "alla" lösningar godkända? Nej, ni måste tillämpa det vi lärt oss i kursen: OO-principer, tex inkapsling mm, dela upp kod i metoder, felhantering och test, dokumentation både i koden och som Javadoc + rapport Även om ni tänker satsa på VG - börja med att lösa alla grundläggande krav, så att ni vet att ni är klara med nivån för G innan ni lägger för mycket tid på VG-kraven December 4, 2013 8

Projektet - hur kommer vi igång? Analysera kraven och designa ert system Skriv ner några scenarion som ert system ska kunna hantera i form av små "berättelser" Vilka klasser ska vi ha? Vilka variabler och metoder har varje klass? Hur använder klasserna varandra? Så snart ni är klara (senast 17/1) visa upp för handledaren och diskutera... Era scenariobeskrivningar Ert detaljerade klassdiagram Om ni siktar på VG: vilket alternativ ni har valt och varför Börja inte programmera förrän handledaren tittat på er design om ni är osäkra på om er lösning är rimlig! December 4, 2013 9

Objektorienterad analys och design December 4, 2013 10

Objektorienterade system (rep.) Ett system där varje komponent representerar ett väldefinierat begrepp I första hand begrepp som har en motsvarighet i verkligheten, såsom personer, varor, bankkonton osv. I andra hand implementationsbegrepp, såsom databaser, fönster, mängder osv. Exempel: en flygplats Komponenter (objekt)? Flygplan Terminaler Start- och landningsbanor Objekten har värden på vissa attribut och beskrivna beteenden Flygplanet har värden såsom hastighet, antal säten osv. Flygplanet har beteenden, t ex om ett plan ska starta måste det få veta vilken start/landningsbana som ska användas, och när starten är genomförd kommer planet vara på en viss höjd och ha en viss hastighet December 4, 2013 11

Objektorienterad analys (rep.) Analys? - kravanalys Görs tidigt när man börjar planera ett system Bör utgå från en given kravspecifikation Krav = vad systemet ska klara av (men inte hur det ska göra det) Studera objekten i verksamheten som vi vill bygga ett system för Vilka objekt (objekttyper) finns? Vilka är relevanta för kraven på vårt system? Vad har de för egenskaper? Vilka beteenden uppvisar objekten och som måste återspeglas i systemet? I vilka scenarion kommer de olika objekten användas? Mål Förståelse för vad systemet ska utföra och områdets terminologi Skapa en "analysmodell" som underlag för designfasen December 4, 2013 12

Objektorienterad design (rep.) Design? Baserat på analysmodellen behöver vi nu anpassa den till något vi faktiska kan implementera som ett system Anpassning till en målmiljö - var ska systemet köras? Vilka resurser finns? Vilka existerande program måste vi ta hänsyn till? Operativsystem? Programmeringsspråk? Systemarkitektur Detaljerad beskrivning av objekten och deras relationer Studera objekten i analysmodellen och deras relationer i olika scenarion Vilka (data) värden ska representera objektens attribut? Hur ska beteenden fördelas över olika metoder? Hur ser varje objekts gränssnitt ut gentemot andra objekt? Kan vi specialisera eller generalisera vissa objekt? Hur ska objekten interagera med varandra i olika scenarion? Mål Förståelse för vilka anpassningar som måste göras för den specifika miljön Skapa en systemarkitektur och detaljerad design av systemets alla objekt December 4, 2013 13

Objektorienterad programmering (rep.) Implementation Baserat på den detaljerade designen behöver vi nu skriva koden för alla objekt vi behöver Mål Huvudprogrammet Alla klasser, deras datavärden och deras metoder Skapa ett körbart system som motsvarar vår detaljerade design och uppfyller alla de kvar vi hade i vår kravspecifikation OBS! Det är inte nödvändigtvis så att dessa "steg" görs ett och ett efter varandra för ett helt system (det kallas för en "vattenfallsmodell"), mer vanligt nuförtiden är agila metoder - men stegen i sig finns kvar! December 4, 2013 14

Exempel - Antispinnsystem Ett system för att upptäcka och åtgärda en potentiellt farlig situation Upptäcks genom att jämföra julens hastighet med varandra Liten skillnad: vi svänger Stor skillnad: hjul spinner Åtgärder Reglerar hjulens hastighet individuellt December 4, 2013 15

Exempel - Antispinnsystem (forts) Objektorienterad analys Vilka objekt finns? - Hjul, motor, bromsar, styrsystemet Vilka egenskaper har de? Hjulen - hastighet Motorn - drivkraft/hjul Bromsar - bromskraft Styrsystemet - hjul/broms-par, status (normal/spinner) för hjulen Vilka beteenden (metoder) kan objekten behöva ha? Hjulen - fråga efter hastigheten Motorn - fråga efter aktuell drivkraft/hjul, ändra drivkraft för ett hjul Bromsar - fråga efter bromskraft för en broms, ändra bromskraft Styrsystemet - fråga efter vilken broms som hör till vilket hjul, fråga efter status för ett visst hjul, rätta till status för ett visst hjul December 4, 2013 16

Exempel - Antispinnsystem (forts) Motor Hjul 1 Styrsystem Broms 1 December 4, 2013 17

Exempel - Antispinnsystem (forts) Scenarion - exempel på hur objekten arbetar tillsammans Scenario - ett hjul börjar spinna Ett hjul börjar spinna Styrsystemet beräknar med jämna mellanrum status för varje hjul och frågar då efter farten för respektive hjul Styrsystemet upptäcker att ett hjul spinner och instruerar motorn att sänka drivkraften på det hjulet och bromsen att bromsa det hjulet När status är ok igen instrueras motorn att gå tillbaka till samma drivkraft och bromsen till samma bromskraft som tidigare Vad innebär det för interaktioner mellan objekten? 1. Styrsystemet frågar efter hjulens fart 2. Hjulen svarar med sin aktuella fart 3. Styrsystemet meddelar motorn en viss drivkraft för ett visst hjul 4. Styrsystemet meddelar en viss broms en viss bromskraft 5. Styrsystemet frågar efter hjulets fart igen 6. Hjulet svarar med sin aktuella fart 7. Styrsystemet meddelar motorn att återgå till tidigare drivkraft för hjulet 8. Styrsystemet meddelar bromsen att återgå till tidigare bromskraft December 4, 2013 18

Exempel - Antispinnsystem (forts) Motor 1. (x4) 2. (x4) Hjul 1 3. 7. 5. Styrsystem 6. 8. 4. Broms 1 December 4, 2013 19

Exempel - Antispinnsystem (forts) Tidsdiagram Styrsystemet Hjul 1 Hjul 2 Hjul 3 Hjul 4 Motor Broms 1 Tid 1. 2. 3. 4. 5. 6. 7. 8. December 4, 2013 20

Exempel - Antispinnsystem (forts) Klassdiagram namn Motor drivkraft/hjul sätt ny aktuell drivkraft på ett hjul tillstånd beteende Hjul hastighet ge aktuell hastighet Styrsystem status för hjul broms-hjul par Broms bromskraft sätt ny aktuell bromskraft December 4, 2013 21 "använder"

Exempel - Antispinnsystem (forts) Beskrivning av varje klass Hjul Broms Ett hjul ansvarar för att hålla reda på sin egen hastighet och kunna rapportera denna hastighet till andra objekt som frågar En broms ansvarar för att hålla reda på den bromskraft som just nu appliceras på ett visst hjul och rapportera den bromskraften till andra objekt som frågar, samt ändra bromskraften till ett nytt värde om något annat objekt begär det Motor Motorn ansvarar för att hålla reda på hur mycket motorkraft som går till vardera hjulet och kunna rapportera den drivkraften till andra objekt som frågar, samt ändra drivkraften för ett visst hjul till ett nytt värde om något annat objekt begär det Styrsystem Styrsystemet ansvarar för att periodiskt kontrollera statusen på alla hjulen och om något hjul börjat spinna (har mycket större hastighet än de andra) åtgärda detta genom att ge motorn instruktion att minska drivkraften på hjulet och bromsen instruktion att bromsa hjulet. När hjulets fart är lika med de andra hjulens ska motorn och bromsen instrueras att återgå till tidigare värden. December 4, 2013 22

Objektorienterad design - forts. på exemplet klassnamn Motor double kraft set(int hjulid, double nykraft) variabler metoder Hjul double hastighet gethastighet() Styrsystem boolean[] status HashMap hjulpar Broms double kraft set(double) December 4, 2013 23 "använder"

Objektorienterad design - annat att tänka på Arv och användning av klassbibliotek Kan vi specialisera/generalisera våra klasser för att effektivisera implementationen? Finns des klasser i Javas standardbibliotek jag kan återanvända direkt eller specialisera? Hjälpklasser Grafiskt gränssnitt? In- och utmatning? Ex: en lampa ska blinka när styrsystemet har upptäckt att ett hjul spinner - vi kan lägga till en klass för att hantera detta gränssnitt Huvudprogrammet "Startar" programmet "hönan och ägget" - någon måste skapa klasserna och ge dem inititala värden innan de kan användas! Designbeslut: skapar huvudprogrammet alla klasser och håller reda på dem? Eller skapar huvudprogrammet bara en klass som sedan skapar och styr resten? December 4, 2013 24

Programmeringsmetod (rep.) Vi har tidigare sett ett par sätt att jobba med sjävla koden... När vi har bestämt oss för vilka klasser vi ska ha, deras variabler och metoder, så kan vi börja skriva pseudokod för metoderna Kom ihåg (Fö 6 - avsnittet om "programmeringsmetod" ): pseudokod = beskriv först i "text" algoritmen för programmet utan att bry dig om Java-syntax När ni ska skriva en "stor" main-metod, eller annat stort kodblock, strunta först i detaljerna - dölj dem bakom metoder Kom ihåg (Fö 5 - avsnittet "att jobba med metoder"): börja planera strukturen på programmet genom att skapa "tomma metoder" som du sedan fyller på med kod efter hand December 4, 2013 25

Dokumentation - Javadoc December 4, 2013 26

Vad är Javadoc och hur funkar det? Javadoc är ett speciellt verktyg för att generera dokumentation i form av HTML-sidor baserat på speciella kommentarer i koden Ni har läst HTML-sidorna för standardbiblioteket som genererats genom Javadoc! Används för API-dokumentation Kom ihåg: API = application programming interface Någon annan vill återanvända dina klasser - internt i ett projekt eller externt (finns många återanvändbara API:er på webben) Ni kommer stöta på ett API i labb 7 Beskriver främst det publika gränssnittet till din kod - dvs de klasser och metoder som andra kan använda/anropa utifrån Vi kommer generera dokumentation från källkodsfiler, finns även andra filtyper, t ex paketdokumentation December 4, 2013 27

Vad är Javadoc och hur funkar det? Hur funkar det? Vi skriver kommentarer i källkodsfilerna enligt en speciell syntax (ett speciellt format) Vi kör verktyget (programmet) Javadoc med våra filer (projektet som innehåller källkodsfilerna) som indata Ni kan köra det direkt inifrån Eclipse Markera ditt projekt, och välj "Generate Javadoc" från Project-menyn. I dialogrutan kan du välja vilka delar av koden som ska inkluderas (endast publika klasser/variabler/metoder eller alla osv) samt var resultatet ska sparas. Klicka på "Finish". Ni hittar sidorna i en ny katalog "doc" - index.html är startsidan Kan även köras från ett terminalfönster med kommandot "javadoc" Resultatet blir ett antal HTML-filer som vi kan titta på i en webbrowser December 4, 2013 28

I källkodsfilerna Inkludera en Javadoc-formaterad kommentar åtminstone för varje publik (public) klass, instans- och klassvariabel, samt metod Kommentarerna ska innehålla HTML-kod (eller vanligt text) och vara formaterade enligt vissa regler (syntax) Exempel: /** * Method to get a character from a character string. * The method check that the given index is within the string * if the index is outside the string the null-character is returned, * else the character at the given index is returned. * <p> Uses the method charat(int index) from the class java.lang.string * * @param s the string that contains the character we want to get * @param i index of the character * @return the character at the given index (or the null-character) */ public static char charat (String s, int i){ char nullchar = 0; if (i >= s.length() i < 0) return nullchar; else return s.charat(i); } 29

Syntax Kommentaren läggs alltid precis före respektive klass/ variabel/metod-deklaration Börja kommentaren med /** på en egen rad (OBS! 2x*) Börja varje rad därefter med * (för att visa att det är en kommentar - gör det mer lättläst) Skriv en beskrivning av klassen/variabeln/metoden som en HTML-text Första meningen kommer att användas för sammanfattningar, t ex i tabellen som visar alla metoder, så var noga med att första meningen kan läsas ensam och att den berättar vad klassen/variabeln/metoden är till för Inga tomma rader - använd <p> för nytt stycke Avsluta beskrivningen med en blank rad (bara * i början) Lista de "taggar" du vill använda och deras text Avsluta med */ på en egen rad (OBS! 1x*) December 4, 2013 30

Syntax (forts.) Taggar - börjar alltid med @ Vem som har skrivit koden - @author (inkluderas oftast inte i HTML-sidan, syns bara i koden) Beskrivning av parameter för metod - @param Skriv först namnet på parametern, sen beskrivningen Inkludera en för varje parameter som metoden har Beskrivning av returvärde - @return Inkludera för alla metoder som inte är konstruktorer eller har returtyp void Beskriv vilka undantag som kan kastas - @throws Inkludera om metoden deklarerats kasta undantag (...throws i metodhuvudet) Med @see kan man inkludera länkar till andra sidor i dokumentationen eller till externa webbsidor Kommentarer på svenska kan få fel teckenkodning när HTML-sidorna genereras, använd kommentarer på engelska December 4, 2013 31

package mittpaket.strang; /** * The class Teckenstrang is used to handle strings of characters. * The class has one public method that uses methods from * java.lang.string to implement certain functionality * * @author Eva Blomqvist */ public class Teckenstrang { /** * Method to get a character from a character string. * The method check that the given index is within the string * if the index is outside the string the null-character is returned, * else the character at the given index is returned. * <p> Uses the method charat(int index) from the class java.lang.string * * @param s the string that contains the character we want to get * @param i index of the character * @return the character at the given index (or the null-character) */ public static char charat (String s, int i){ char nullchar = 0; /* * */ if (i >= s.length() i < 0) return nullchar; else return s.charat(i); } } 32

Körbara filer December 4, 2013 34

Att kompilera och "förpacka" sin kod En användare vill inte köra ett program inifrån Eclipse! En användare vill dubbelklicka på en fil, eller möjligen skriva ett kommando i terminalfönstret Vi har flera olika valmöjligheter Köra vårt program genom att skriva "java MittProgram" i ett terminalfönster - kom ihåg en av de allra första föreläsningarna Vi har i förväg kompilerat programmet och det som körs är.class-filen Hur ska användaren veta vad som ska köras om det finns många.class-filer - dvs många klasser i vårt program? Vi kan "samla ihop och förpacka" våra kompilerade klassfiler i en JAR-fil (JAR = Java Archive) - t ex filen MittProgram.jar Vi skriver istället "java -jar MittProgram.jar" i terminalfönstret December 4, 2013 35

Att kompilera och "förpacka" sin kod (forts.) Men om vi vill att användaren bara ska kunna dubbelklicka på filen? Skapa en "runnable JAR" (fungerar om operativsystemet har den funktionen - ok för Windows, Mac mfl), inkluderar information till operativsystemet om vilken.class-fil som innehåller main-metoden Kompilera och förpacka programmet specifikt för ett visst operativsystem December 4, 2013 36

Hur skapar vi en JAR-fil eller en "runnable JAR" i Eclipse? Markera ditt projekt, högerklicka och välj "Export" Under "Java" finns tre alternativ JAR file Javadoc Runnable JAR file Välj "Runnable JAR file" och "Next" Under "launch configuration" måste du markera den klass som innehåller din main-metod, dvs där programmet ska starta när man dubbelklickar på JARfilen (eller skriver java -jar... i terminalfönstret) Under "Export destination" måste du ange var filen ska sparas och vad den ska heta (ändelse:.jar) Avsluta med "Finish" December 4, 2013 37

Sammanfattning Information om projektet Välj projektuppgift: Banken, Biblioteket eller Gymmet Sätt igång direkt med analys och design - Helst möte med handeldaren redan före jul! OO-analys och design - innan du börjar skriva kod! Skriv scenarion Lista klasser och vilka egenskaper och beteenden de ska ha Hur löser klasserna gemensamt ett scenario? - rita! Gör detaljerade beskrivningar av varje klass: namn, variabler (inkl. typ) och metoder (inkl. parametrar och returtyp) Javadoc - ett sätt att dokumentera sina klasser Runnable JAR - ett sätt att "förpacka" ett körbart program December 4, 2013 38

December 4, 2013 39