A ToolGuide for Eclipse: En fördjupning i några av verktygen i Eclipse och hur de underlättar XP s practices Mattias Jarheden och Thomas Forsström Sammanfattning Denna djupstudie försöker ge en inblick i två olika verktyg som finns tillgängliga i Eclipse. Skälet till att vi väljer att fördjupa oss i de verktygen är för vi tror att de kan vara till hjälp för team som använder Eclipse. Först ges en bakgrund till varför utvecklingsverktyg kan ha en avgörande roll i utvecklingsprocessen av programvara. Vi tar upp exempel på verktyg som stödjer practices i XP. Därefter behandlas verktygen debug, Ant och deras grundläggande funktioner. Slutligen redovisas huruvida Eclipse och dess verktyg underlättade för vårt team. 1 Inledning Att utveckla program från grunden kan vara en tidsödande process i Java. Detta beror bland annat på att logiken inuti en metod, interface eller en klass är unik, däremot behöver man göra importsatser och syntax för klasser och paket om och om igen. Detta resulterar i att samma typ av kod måste skrivas upprepade gånger, vilket ofta leder till förlorad tid och irriterande felstavningar som upptäcks först vid kompilering. Detta problem har man insett och Eclipse är ett verktyg som tagits fram för att underlätta och spara tid för utvecklaren. Eclipse är en open-source, utbyggbar plattform med en generell design och är för närvarande mest populär som en javaintegrerad utvecklingsmiljö. Eclipse innehåller funktioner för att skriva och debugga 1 javakod som standard men det ges även möjlighet att installera externa plugins för mer avancerade funktioner. Eftersom Eclipse tillhandahåller en stor mängd hjälpmedel och funktioner har vi i denna djupstudie beslutat oss för att titta närmare på två centrala funktioner i programvaruutveckling, nämligen debug och Ant. 2 Varför utvecklingsverktyg? Det råder ingen tvekan om att olika former av utvecklingsverktyg sparar tid för användaren. Det kan vara allt från påbyggda texteditorer såsom Emacs, jedit med flera till ett komplett system med CVS-hantering som Eclipse. För att tydliggöra vilka fördelar och effektiviseringar som kan göras med olika verktyg tar vi upp vilka XP-practices som underlättas med respektive verktyg. Refactor Mercilessly I Eclipse finns det hjälpmedel för att göra vanliga refaktoriseringar såsom byta namn på metod, klasser, variabler etc. Det finns även stöd för att bryta ut metoder och klasser, ändra inparametrar, då dessa operationer kan vara väldigt tidsödande när antalet samverkande klasser börjar bli många. 1 Felsöka i koden genom att t.ex. kontrollera variabelvärden.
Adopt Test-Driven Development Eftersom testverktyget junit är integrerat i Eclipse underlättas arbetet med att genomföra testdriven programvaruutveckling. XP förespråkar regelbunden testning och detta kan vara tidsödande om man istället har ett separat testverktyg. Adopt Collective Code Ownership Denna practice kräver CVS-hantering vilket för förstagångsanvändaren inte är helt trivialt. Med promptbaserad CVS måste man kunna flera långa kommandon vilket kan leda till att man undviker att använda verktyget effektivt. I Eclipse är detta inbyggt och istället för att behöva skriva långa kommandon, representeras detta med ett lättanvänt grafiskt gränssnitt. Integrate Continually Då det i Eclipse är enkelt att använda CVS-operationerna, enligt ovanstående practice, underlättas processen att integrera ny kod med repositoryt. Release Regularly Med hjälp av funktionen Ant i Eclipse kan releaseprocessen automatiseras och avsevärt underlättas. Vi kommer att titta närmare på denna funktion i den här djupstudien. Eclipse stora fördel märker man framförallt av då man är tvungen att köra flera verktyg parallellt. Generellt kan man säga att Eclipse samlar flera i verktyg i ett användargränssnitt och därmed slipper användaren ha flera separata program öppna. Det grafiska miljön i Eclipse förenklar användningen av de olika verktygen och textbaserade kommandon undviks. 3 Fördjupning av verktygen 3.1 Ant En väldefinierad releaseprocess är en av de viktigaste delarna i mjukvaruutveckling men det är sällan man använder verktyg för det. En välutvecklad paketeringsprocess försäkrar att programvaran i projektet byggs på exakt samma sätt varje gång en release ska göras. När byggnadsprocessen blir mer komplex kommer behovet av standardisering öka. Därför bör man sätta upp, dokumentera och automatisera tillvägagångssättet så mycket som möjligt. För att minska avståndet mellan utveckling, integrering, testning och produktionsmiljöerna så behövs en väldefinierad byggnadsprocess. Bara processen i sig kommer effektivisera övergången från ett steg till nästa i utvecklingen. Man minskar även problem rörande kompilering, classpath, eller egenskaper som kostar många projekt tid och pengar. Ant står för Another Neat Tool och är ett scriptverktyg för att skapa och köra filer som till exempel kan kompilera, kopiera och andra operationer som är nödvändiga vid en releaseprocess. Till skillnad från andra makefiler 2, så är Ant plattformsoberoende och är annorlunda från andra makeverktyg då javaklasser används istället för operativsystemets 2 Textfil som innehåller kommandon som kan skapa backupar, sätta ihop filer till ett komplett program eller köra program. Traditionellt så används makefiler till att specificera beroenden mellan målfiler och källfiler.
kommandon. XML-filer används för konfiguration där flera moment exekveras, varje moment körs av ett objekt som implementerar ett interface. Ant tar källkoden och bygger en applikation men kan också göra mycket mer, t ex manipulera filer och kataloger samt köra applikationer så som javac. Eftersom Ant också kan interagera med CVS så täcks det mesta som behöver göras till en release i verktygets repertoar. I Eclipse kan man enkelt konfigurera XML-filer då det finns en texteditor som stödjer färgkodning till syntaxen. För att skapa en ny Ant-fil i Eclipse gör man på följande vis: 1. File > New > File. 2. Skriv in valfritt namn på filen, men se till att den har.xml som filändelse. 3. Klicka på Finish. Precis som i den vanliga kodeditorn så hjälper Eclipse till med förslag på det man ska skriva in. Man kan exempelvis skriva <tar och sen trycka ctrl+space, då får man upp en lista med möjliga ifyllanden, i detta fall <target>. Då man väljer den så sätts både början och slut på taggen in. Bild 1 visar ett exempel på en liten XML-fil. Bild 1: En XML-fil där texten Hello skrivs ut. Det finns även en Outline-vy i Eclipse där man i detta fall enkelt ser vad filen innehåller för olika arbetsuppgifter och vad respektive target gör. Alla XML-filer kan köras som Ant-filer i Eclipse även om inte alla är det. Vi använder även här vårt HelloWorld-exempel. 1. Välj HelloWorld.xml i Navigator-vyn and och välj Run Ant... från innehållsmenyn. 2. Run Ant dialogrutan kommer fram. Se bild 2.
Bild 2: Dialogruta för Ant. 3. Den här dialogrutan gör det möjligt att ställa in de sätt som Ant buildfiler kan köras men vi koncentrerar oss på Targets fliken. Där kan de Ant targets man vill köra väljas och i vilken ordning. 4. Klicka på Run. 5. Filen körs och resultatet skickas till Console-vyn. Det går också att spara en sådan konfiguration så man kan ha flera uppsättningar. Man slipper då ställa in den enligt ovanstående varje gång. Möjligheten finns också att skapa flera olika konfigurationer på samma fil. T ex kan man ändra exekveringsordningen så att World körs före Hello. För att underlätta ännu mer så finns i Eclipse en Ant-vy där man kan visa de XML-filer man vill. Från vyn kan man välja olika targets i filerna och exekverar dem enbart. Vyn ger en överblick över alla filer och innehåll samt ett lätt sätt att komma åt filerna för att modifiera dem på olika sätt. 3.2 Debug Att debugga eller inte debugga, det är frågan. Hur mycket man än försöker att koda perfekt och använda omfattande testning så kommer det ändå uppstå buggar som är svåra att hitta. Det finns många sätt att debugga eller fixa buggar och det första måste göra är att hitta raden med kod som orsakar felet. När raden i fråga har hittats underlättar det att veta lite om omgivningen runt buggen, t ex variabelvärden, metoder och dylikt. Att försöka leta buggar kan vara en tidsödande och frustrerande process speciellt om man gör det med det traditionella println() där möjligheterna är begränsade. Koden blir full med extra rader som efteråt måste hittas och plockas bort igen.
Med en debugger är det tämligen enkelt att ta reda på denna information. Eclipse har en inbyggd debugmiljö vilken erbjuder verktyg som behövs för att hitta och åtgärda de buggar som kan uppstå. Dock begränsas debug-möjligheten till vad vanliga javaobjekt kan hantera. Här följer ett enkelt exempel på hur man använder debuggern i Eclipse. 1. Till att börja med måste koden vara kompilerad och vara exekverbar. 2. Verktyget erbjuder många möjligheter men det vanligaste är att sätta ut breakpoints. Detta gör man för att få reda på värden på variabler, villkor och loopar. För att sätta en breakpoint dubbelklickar man på listen till vänster om raden med kod man vill undersöka. 3. Därefter behöver man göra inställningar för hur debuggern ska användas. I Run>Debug ställer man in de eventuella argument som behövs samt den main-klass som debuggern ska köra. 4. När ovanstående inställningar har gjorts, klickar man på knappen Debug och ett nytt perspektiv öppnas i Eclipse. Bild 3: Debuggerns Perspektiv. 5. Nu är vi redo att köra debuggern. Detta gör man enklast genom att klicka på play-knappen i övre vänstra hörnet i debugperspektivet. 6. Koden körs och debuggern stannar upp vid de breakpoints man angivit. Se bild 4.
Bild 4: Debuggern visar vilken rad med kod som körs. När man har hittat var felet uppstår vill man oftast se vad programmet gör precis innan det kraschar. Ett sätt att göra detta är att gå igenom programmet stegvis med hjälp av den stepfunktion som finns tillgänglig. Denna funktion gör det möjligt att se hur enskilda klasser körs rad för rad, hoppa över rader samt se hur hela programmet exekveras rad för rad. I den högra delen av debugperspektivet kan man få reda på vilka värden variabler och uttryck har genom att klicka på respektive flik, se bild 3. En användbar funktion som finns i de senare versionerna av JVM och Eclipse är Hotswap Bug Fixing. Denna innebär helt enkelt att man kan ändra och rätta till fel i koden samtidigt som man debuggar. Detta gör att man slipper stänga applikationen, ändra koden, kompilera och starta igen. Det är användbart när det tar lång tid att starta programmet eller att komma till den punkt där programmet kraschar. Eclipse erbjuder även en intressant funktion som kallas Remote debugging. Då körs en debuggserver samt applikationen på servern och så kopplar man upp en debuggklient mot den. Detta kan vara användbart då man vill debugga virus, trojaner etcetera då den drabbade datorn kan isoleras väl. Ett annat tillfälle kan vara när det uppstår fel som förekommer på en specifik dator och inte på några andra datorer. I framtiden vill man även öka möjligheten att debugga på flera operativsystem och arkitekturer. Debugging bör inte användas som ett substitut för tester. Försök istället tänka på det som ett utvecklingsverktyg för att hålla testerna fungerande och inte som ett verktyg för att hålla koden fungerande. 4 Utvärdering av hjälpmedlen i vårt team Under projektets gång blev teamet mer vana vid att använda Eclipse och dess funktioner. Debug-funktionen är fortfarande något som är svårt att få folk att prova och använda regelbundet. Den praxis som man ofta använder är att köra programmet och se om det fungerar. De fallen då programmet kraschar och man börjar leta efter fel så känns debugverktyget ofta omständigt och man tar till standardförfarandet med att lägga till koden System.out.println(). Detta kan bero på att omfattningen av kod i detta projekt ändå är relativt liten och man klarar sig väl med att göra enkla systemutskrifter. Teamet fick i uppgift att testa och utvärdera debug-verktyget. Slutsatsen, som vi coacher också delar, är att det kan vara användbart vid större projekt då det kan bli rörigt med osammanhängande systemutskrifter och då man måste vara mer strukturerad i sitt felsökande. Det råder ingen tvekan om att debug är ett kraftfullt och effektivt verktyg, dock får man i detta projekt inte användning för dess fulla potential. Ant användes desto mer effektivt under projektet. Vi lät teammedlemmar tidigt i projektet lära sig hur man skriver script som genererar en komplett release från repositoryt. Detta har visat sig spara mycket tid till exempel då det uppträder fel strax innan release. Med ett Ant-script så får man, efter att ha korrigerat felet, en komplett release igen på några sekunder. Införandet av Ant i releaseprocessen gick väldigt smärtfritt och det blev redan
efter första iterationen en naturlig del i projektet. Slutsatsen från teamet är att Ant är något som underlättat och sparat mycket tid i releaseprocessen och det är ett verktyg som man definitivt kommer använda igen om man skulle genomföra liknande projekt. 5 Slutsats Programvaruutveckling är en komplicerad process eftersom det innehåller många olika moment som ska fungera tillsammans. Utvecklingsverktyg har tagits fram för att underlätta denna process genom att spara värdefull tid och därmed pengar. Verktygen kan göra skillnaden mellan att sitta och leta kompileringsfel och andra irriterande problem till att låta programmerarna koncentrera sig på att lösa de väsentliga problem som för programvaran framåt. 6 Acknowledgements Vi vill tacka team07, Love Johansson, Marcus Eliasson, Martin Malek och Görel Hedin.
7 Referenser 1. chromatic. Extreme Programming, Pocket Guide. O Reilly & Associates 2003 2. Eclipse help contents 2003. http://www.eclipse.org 3. Länkar: Debugging Carlos Valcarcel, Using the Eclipse Debugger, Oct 8, 2004. http://www.quepublishing.com/articles/article.asp?p=336709 Paul Leszek, Debugging with Eclipse, (Nov. 7, 2003). http://linuxdevices.com/articles/at6046208714.html Ant Michael Cymerman, Automate your build process using Java and Ant. http://www.javaworld.com/javaworld/jw-10-2000/jw-1020-ant.html Bryan Dollery, The Best Java Open-Source Tools, Nov 8, 2002. http://www.informit.com/articles/article.asp?p=29962&seqnum=5 http://ant.apache.org/