1DV411 Webbprojekt 1 Slutrapport Visualisering och lagring av tracerouteresultat Andreas Ahlborg Fredrik Forsmo Jacob Ottosson Therese Andersson 2012-03-29 Kurskod: 1DV411
Abstrakt Thomas Ivarsson, universitetsadjunkt vid Linnéuniversitetet, efterfrågade ett system för att lagra och presentera tracerouteresultat på ett effektivt sätt. Målet med systemet var att det skulle fungera både som ett lärande och ett examinerande verktyg, och ska tillåta användare att mata in tracerouteresultat och presentera grafer baserade på detta. Systemet ska dessutom vara rollbaserat och göra det möjligt för en administratör att hantera användare, skapa grupper samt biljetter. För att kontrollera inmatningar av data är målet att implementera ett biljettbaserat system. Denna rapport innehåller arbetsförloppet vid utveckling av denna applikation, och resultatet av detta projekt innefattar svar på om det är möjligt att på ett överskådligt och effektivt sätt presentera tracerouteresultat. Rapporten avslutas med de slutsatser som projektgruppen kommit fram till vid utvärdering av arbetet.
Förord Denna rapport är resultatet i kursen Webbprojekt 1, som läses på halvfart under tio veckors tid vid Linnéuniversitetet, och beskriver arbetsförloppet och slutresultatet av projektet Visualisering och lagring av tracerouteresultat. På uppdrag av Thomas Ivarsson, universitetsadjunkt vid Linnéuniversitet i Kalmar, utvecklades ett system för att lagra tracerouteresultat och presentera detta resultat på ett effektivt sätt via en webbaserad applikation. Projektet har varit lärorikt, och har gett oss erfarenhet av att arbeta i grupp över en längre tid samt planera och verkställa en större applikation. Vi vill tacka vår kund Thomas Ivarsson för ett intressant och lärorikt projekt samt ett gott samarbete. Vi vill även passa på att tacka Martin Fredriksson för hans handledning och stöd under projektets gång.
Innehållsförteckning Abstrakt... I Förord...II 1. Bakgrund... 1 1.1 Inledning... 1 1.2 Syfte... 1 1.3 Mål... 1 1.4 Projektorganisation... 2 2. Genomförande... 3 2.1 Metod... 3 2.2 Teknik... 3 2.3 Testning... 4 3. Resultat... 5 3.1 Databasmodell... 5 3.2 Användargränssnitt... 5 3.3 Administrationsgränssnitt... 6 3.3.1 Navigation... 6 3.3.2 Skapa biljetter... 6 3.3.3 Skapa användare... 7 3.3.4 Visa användares grafer... 7 3.4 Skapa graf... 8 3.5 Presentation av graf... 9 3.5.1 Valmöjligheter vid presentation... 9 3.5.2 Individuell graf... 9 3.5.3 Grafer för grupper och grupperingar... 9 3.5.4 Hantering av request timed out... 9 3.6 Användardokumentation... 10 4. Avvikelser...11 5. Slutsats... 12 6. Förslag på vidareutveckling... 13
6.1 Ytterligare utveckling av parsningsfunktionalitet... 13 6.2 Anonyma användare... 13 7. Övertagande organisation... 14 8. Dokumentationshänvisning... 15 8.1 Kravspecifikation... 15 8.2 Testspecifikation... 15 8.3 Mjukvaruarkitektur... 15 9. Diskussion... 16 10. Bilagor... 17 10.1 Bilaga 1: Presentation av individuell graf... 17 10.2 Bilaga 2: Presentation av stor grupperad graf... 17 10.3 Bilaga 3: Skapa flera användare... 17 10.4 Bilaga 4: Användarhantering... 17 10.5 Bilaga 5: Valmöjligheter vid presentation... 17
1. Bakgrund 1.1 Inledning Studenter som studerar nätverksteknik vid Linnéuniversitet kommer tidigt i utbildningen i kontakt med traceroutes 1 och hur dessa fungerar. I dagsläget finns inget verktyg som kan underlätta vid inlärning och examinering inom detta område. Thomas Ivarsson (hädanefter kund), universitetsadjunkt vid Linnéuniversitetet i Kalmar, kände att det fanns ett behov för någon typ av verktyg som kunde användas i undervisningen för att både underlätta studenternas inlärning samt användas i examinerande moment. Att ge studenter en möjlighet att få tracerouteresultat presenterat för sig visuellt istället för enbart textbaserat, kan göra att inlärning effektiviseras och studenternas förmåga att analysera data ökas. 1.2 Syfte Syftet med projektet är att skapa en modern webbaserad undervisningsapplikation som hanterar funktionalitet för att både lagra tracerouteresultat och ge möjlighet att presentera dessa resultat på ett effektivt och visuellt sätt. Systemet ska även implementera någon typ av administrationsgränssnitt med möjlighet att hantera användare, grupper och biljetter. 1.3 Mål Det huvudsakliga målet med projektet är att skapa och leverera ett funktionsdugligt system som kan lagra tracerouteresultat och presentera detta i form av en graf. Systemet ska även vara enkelt och användarvänligt samt kunna användas i flera olika miljöer. Ett administrationsgränssnitt ska finnas implementerat för att sköta hantering av användare, biljetter och grupper på ett effektivt sätt. Systemet ska vara baserat på biljetter för att kunna kontrollera hur många inmatningar en användare får göra och inom vilken tidsram. Utöver målen för själva systemet är även målet att projektgruppen ska lära sig planera och arbeta i större projekt och mot en riktig kund. 1 http://sv.wikipedia.org/wiki/traceroute 1
1.4 Projektorganisation Figur 1.1 Projektorganisation med styrande och ledande delar Figur 1.1 visar hur projektet har varit organiserat samt vilka som medverkat under arbetets gång. Projektledaren har utsetts av projektledningen inför varje iteration, och varje medlem har varit projektledare minst en gång under projekttiden. Varje område har representerats av en ansvarig projektmedlem, och till dessa har en även biträdande ansvarig funnits. Modellen enligt figur 1.1 har använts för att strukturera upp organisationen på bästa sätt, samt funnits som underlag till handledning. 2
2. Genomförande 2.1 Metod Övergripande metodik över projektet har varit att tillämpa iterativt arbetssätt genom att planera uppgifter, göra kontrollerade tester och kontinuerliga leveranser. Arbetet har skett enligt Unified Process 2 vilket innebär att utvecklingen varit uppdelad i faser, som i sin tur varit uppdelade i iterationer vilka tidsmässigt representerat en vecka i projektet. Utvecklingen har baserats på att projektgruppen programmerat till viss del tillsammans för att kunna diskutera krav under arbetets gång. Uppgifter och områden har även tilldelats och varje gruppmedlem har haft ansvaret för att dessa uppgifter ska hålla tidsplaneringen. Genomgående över projektet har gruppen diskuterat dagligen om vad som ska hanteras och vad som är i prioritet. För att ha kontroll över uppgifter och tider skapades en plan inför varje iteration. Denna plan innehöll analys av föregående iteration, genomgång av arbetad tid och mål inför kommande iteration. Under den kritiska startperioden har projektgruppen haft kontinuerlig kontakt med handledare för att få hjälp och stöd angående dokumentation och projektupplägg. Kontakt med kunden, via möten och mail, har skett under nästan varje iteration för att få återkoppling till produkten och föra en diskussion angående specifikation av krav. 2.2 Teknik Projektet innehöll inte många begränsningar utan enda önskemålet från kunden var att arbeta mot en databas av typen MySQL 3. Valet föll då på att använda PHP 4 för att utveckla applikationen. För att få en bra grundstruktur redan från början, och för att förenkla utvecklingen, valde gruppen att använda Slim 5 som är ett ramverk för PHP. 2 http://en.wikipedia.org/wiki/unified_process 3 http://www.mysql.com/ 4 http://www.php.net/ 5 http://www.slimframework.com/ 3
För att hantera vyer användes ramverket Twig 6, även detta för att förenkla och skapa en mer dynamisk applikation. Applikationens huvudsyfte var att presentera någon typ av graf. Till detta testades flera olika verktyg, men gruppen valde slutligen att använda Graphviz 7 till detta. Graphviz är en öppen programvara som bygger på scriptspråket dot. Ett projektkrav var att versionshantera allt material, och till detta har TortoiseSVN 8 använts. Denna del har varit viktig för att ha kontroll över alla filer och göra det möjligt för alla i gruppen att ha tillgång till alla filer i projektet. 2.3 Testning Tidigt i projektet diskuterades testning och hur detta skulle läggas upp. En testspecifikation (se 8.2 Testspecifikation) skapades utefter de specificerade krav som satts upp för projektet. Testspecifikationens uppgift var att samla alla testfall som bör köras i systemet för att säkerhetsställa att kraven uppfylls. När implementeringen av ett krav påbörjades, skapades ett manuellt testfall för detta krav. Utöver de systemtester som kördes tänkte alla i projektgruppen på att kontinuerligt testa just den del som implementerades för att tidigt upptäcka felaktigheter. 6 http://twig.sensiolabs.org/ 7 http://graphviz.org/ 8 http://tortoisesvn.net/ 4
3. Resultat 3.1 Databasmodell Figur 3.1 Fysisk databasmodell I ett tidigt skede av projektet diskuterades databasmodellen för att undersöka huruvida projektet var genomförbart efter de baskrav som satts upp. Efter det skapades en konceptuell databasmodell, vilken modifierades under de första faserna, och denna låg som grund för den implementerade databasen som presenteras enligt figur 3.1. 3.2 Användargränssnitt Figur 3.2 Vy för inloggad användare Figur 3.2 visar hur användargränssnittet ser ut för en inloggad användare. Användaren har tillgång till att skapa grafer om denne blivit tilldelad en biljett, samt presentera de grafer användaren på något sätt är inblandad i. 5
3.3 Administrationsgränssnitt 3.3.1 Navigation Figur 3.3 Navigationsalternativ för administratör Figur 3.3 visar navigeringsmöjligheterna för inloggad administratör. Administratören har tillgång till att skapa biljetter samt hantera användare. 3.3.2 Skapa biljetter Figur 3.3 Vy som presenteras vid skapande av biljetter Figur 3.3 presenterar hur administratören i systemet kan skapa biljetter samt tilldela dessa till användare. En biljett har ett startdatum, ett slutdatum och är giltig för så många inmatningar som administratören bestämmer. När en biljett har skapats presenteras den på den valda användarens startsida. Biljetter som passerat slutdatum eller inte har några tillgängliga inmatningar kvar, finns fortfarande kvar på användarens startsida men biljetten är avaktiverad. 6
3.3.3 Skapa användare Figur 3.4 Hantering för att skapa användare Figur 3.4 visar hur systemet hanterar möjlighet att skapa användare. Förutom användarnamn och lösenord kan administratören välja om användaren ska vara av typen student eller administratör. Användaren kan även ingå i en grupp med studenter, men denna del är frivillig. Övrig användarhantering (se Bilaga 4: Användarhantering) gör det möjligt för administratören att uppdatera användare, ta bort användare samt skapa flera användare åt gången med genom att använda studenternas mailadresser (se Bilaga 3: Skapa flera användare). 3.3.4 Visa användares grafer Figur 3.5 Presentationsvy för att visa användares grafer 7
Figur 3.5 visar hur systemet gör det möjligt för administratören att visa andra användares grafer. Systemet gör så administratören blir presenterad den användarens startsida, och har därför full tillgång till användarens grafer. 3.4 Skapa graf Figur 3.6 Inmatning av traceroutedata för att rendera graf Figur 3.6 presenterar huvudfunktionaliteten i systemet som kan användas för att rendera grafer baserat på traceroutedresultat. Möjligheten att använda denna funktion finns enbart om användaren har tillgängliga biljetter, och detta märks även upp i antal överst på sidan. Applikationen kan hantera olika typer av data som exempelvis traces med request timed out (se figur 3.7) eller lastbalanserade resultat. 8
3.5 Presentation av graf 3.5.1 Valmöjligheter vid presentation Systemet get användaren valmöjligheter vid rendering av graf. Användaren kan välja att skapa en graf i PDF, PNG eller SVG format. Beroende på om grafen är baserad på en individuell traceroute eller grupperad data finns ytterligare möjligheter (se Bilaga 5: Valmöjligheter vid presentation). Användaren kan till exempel välja att visa medeltider för ping, visa destination eller slå ihop duplicerade vägar i sin renderade graf. 3.5.2 Individuell graf Systemet mest grundläggande funktionalitet gör det möjligt att presentera grafer för individuella tracerouteresultat (Bilaga 1: Presentation av individuell graf). 3.5.3 Grafer för grupper och grupperingar Om en användare är medlem i en grupp eller har gjort någon typ av gruppering av data kan dessa presenteras i en enda graf (Bilaga 2: Presentation av stor grupperad graf). För att hantera dessa stora grafer är möjligheten till filformatet PDF eller SVG viktig eftersom det tillåter användaren att förstora grafen för att se all viktig information. 3.5.4 Hantering av request timed out Figur 3.7 Utmärkning i grafen av noder med request timed out 9
3.6 Användardokumentation Systemet har en användardokumentation implementerad i form av en FAQ 9 -sida. Denna kan hjälpa användaren förstå den grundläggande funktionaliteten i systemet, och hur denna fungerar. Eftersom applikationen kräver att inmatad data ser ut på ett visst sätt finns denna del med i dokumentationen tillsammans med felhantering och valmöjligheter. Inloggad administratör ser samma generella dokumentation men med tillägg för hur användar- biljett och grupphantering fungerar. 9 FAQ (Frequently Asked Question) 10
4. Avvikelser Ett önskemål från kunden var att implementera någon typ av hantering av anonyma användare. Projektgruppen ansåg dock att denna uppgift var svår att realisera på grund av hur databasmodellen ser ut. För att möjliggöra den typ av funktionalitet som finns i slutsystemet bör en biljett vara kopplad till en användare som finns registrerad i systemet. På initiativ av gruppen implementerades funktionalitet för att registrera flera användare åt gången genom att mata in mailadresser till de tilltänkta användarna. Detta gjordes för att skapa en mer effektiv användarregistrering vid exempelvis tillfällen då en administratör vill registrera många kursdeltagare. Funktionaliteten är dock inte testad fullt ut på grund av att det från kundens sida inte är bestämt på vilken server systemet ska finnas. Enligt kravspecifikationen (se 8.1 Kravspecifikation) så ska systemet kunna hantera möjlighet att ta bort traceroutedata. Funktionaliteten för detta finns implementerad men är inte fullgjord med vyer i administrationsgränssnittet. 11
5. Slutsats Eftersom vi redan från början fick en bra grund och beskrivning över kundens önskemål, kunde vi nästan direkt börja specificera projektets krav. Det system som utvecklats inom tidsramen för projektet känner vi stämmer överens med den vision som fanns från början. Vid planerad slutleverans fick vi tyvärr mindre problem med hantering av data i vissa format, men vi fick trots allt intrycket av att kunden var nöjd med det utvecklade systemet. Vi känner att projektet har varit en rolig utmaning där vi fått ganska fria händer, men med en bra bas att arbeta från. Kunden har varit delaktig genom hela projektet och på så sätt har vi fått hjälp och återkoppling till funktionaliteten. Systemet implementerar en effektiv lösning för att lagra utvalda delar av traceroutedata, och dessa data kan sedan visualiseras i form av en graf där användaren tillåts välja vad som ska presenteras. Vissa implementerade funktioner, som exempelvis filformat för grafer, är på initiativ av projektgruppen. Dessa funktioner känner vi ger en mer dynamisk applikation som tillåter fler valmöjligheter för användaren. Denna del kan även tillåtas växa i framtiden för att vidareutveckla systemet. Basen för systemet är rollbaserat, och genom ett administrationsgränssnitt tillåts administratörer att sköta hantering av användare, grupper och biljetter. Det biljettsystem som är implementerat kan användas för att på ett effektivt sätt kontrollera de inmatningar en student får göra, och kan exempelvis användas i en laborationsmiljö. Den användardokumentation som skapades till systemet tror vi kan hjälpa användare med den grundläggande funktionaliteten. Denna är dock något bristfällig och bör utökas med fler exempel för att ge ett större omfång i hjälpavsnittet. De verktyg vi använt känner vi har effektiviserat arbetet trots att det fanns risker tidsmässigt med att använda exempelvis ramverk. Vi valde att testa flera olika verktyg som kunde hantera grafrenderingen, och fokuserade först på att satsa på en dynamisk presentation. Eftersom applikationen dock skulle kunna hantera större grafer, insåg vi att detta skulle bli svårt att realisera med JavaScript-baserade verktyg. Graphviz, som vi slutligen använde, har kunnat användas effektivt för att uppfylla alla krav och har varit lätt att modifiera. På kort sikt hoppas vi att systemet kan testas vidare och kanske ytterligare utvecklas, och på lång sikt är målet någon typ av undervisningsplattform som kan användas vid exempelvis examinering. 12
6. Förslag på vidareutveckling 6.1 Ytterligare utveckling av parsningsfunktionalitet I dagsläget kan systemet hantera inmatning traceroutedata i flera olika format. För att detta ska fungera krävs det dock att tracerouteresultatet är skrivet i korrekt format utan exempelvis radbrytningar. Ett förslag på vidareutveckling kan därför vara att utveckla funktionaliteten så att användaren inte behöver bry sig om hur tracerouteresultatet ska se ut. 6.2 Anonyma användare Ett önskemål från kunden under detta projekt var att möjliggöra hantering av anonyma användare och att dessa ska kunna skapa grafer och visa dessa. Detta kan ligga som grund för eventuell vidareutveckling, och förändring av databasmodellen. 13
7. Övertagande organisation Thomas Ivarsson Linnéuniversitetet Institutionen för datavetenskap, fysik och matematik (DFM) 391 82 Kalmar thomas.ivarsson@lnu.se 14
8. Dokumentationshänvisning 8.1 Kravspecifikation Dokumentet kravspecifikation.pdf presenterar de krav som fastställts för systemet. Specifikationen innehåller främst funktionella krav och dessa är till stor del specificerade med användningsfall. 8.2 Testspecifikation Dokumentet testspecifikation.pdf, med tillhörande testrapporter, innehåller de dokumenterade systemtester som användes för att testa applikationen. De tillhörande testrapporterna innehåller dessutom eventuella kommentarer på det testade systemet. 8.3 Mjukvaruarkitektur Dokumentet mjukvaruarkitektur.pdf innehåller den arkitektur som satts upp för systemet och är bestämd av projektgruppen. Arkitekturen användes för att strukturera upp applikationens kod på ett sätt som alla i gruppen kunde förstå och implementera krav efter. 15
9. Diskussion Vi känner att projektet har varit en lärorik och rolig utmaning, där varje projektmedlem tar med sig olika saker beroende på tidigare erfarenheter. Att arbeta med en riktig kund i ett större projekt tycker vi har varit väldigt nyttigt, och vi har fått lära oss vikten av planering och ansvar. Kontakten med kunden har fungerat väldigt bra enligt oss, och förutom möten har vi kunnat ha kontakta kunden med frågor och fått väldigt användbara svar tillbaka. De riktlinjer vi fick från kunden har varit en väldigt bra bas att utveckla vidare från, och de riktlinjerna tror vi var en stor fördel att få redan från början. Till nästa projekt tar vi med oss att sätta sig in i de bestämda verktygen och ramverken tidigare för att undvika de risker det medför. Planeringen fungerade både bra och mindre bra under iterationerna, och detta är även något som vi väljer att ta med oss till nästkommande projekt eftersom planering är så pass viktig både för tid, för krav och för risker. Även uppdelning av arbete och uppgifter kunde ha fungerat mer effektivt i början av projektet, och vi märkte hur betydelsefullt det kan vara när man arbetar i grupp på distans. Vi hade en något optimistisk tidsplanering från början, vilken visade sig vara svår att hålla och som dessutom tog vissa krav i fel ordning. Vi känner dock att detta löstes smidigt genom en bra kommunikation mellan oss i gruppen. Samarbetet mellan oss i gruppen har fungerat mycket bra och vi har haft daglig kontakt på ett eller annat sätt. De projektmöten vi haft oss emellan har använts för att diskutera krav och uppgifter, och vi känner de var tillräckligt långa. Vi kunde ha använt möjligheten till att ha en projektledare annat sätt och därför ha en större struktur på dessa möten. Nu i efterhand ser vi även att det kan finnas värde i att ha strukturerade möten i början på varje arbetsdag. Detta har dock fått anpassas efter arbetstider och liknande utanför projektet. För att hantera och kontrollera planering har vi använt oss av iterationsplanerna. De har kunnat ge en bra indikation om vad som bör prioriteras och hur vi legat till i tidsplaneringen. Större avsteg i exempelvis sprint backlog har diskuterats och sedan har vi tagit med oss det i planeringen inför nästa iteration. Vi känner oss väldigt nöjda med slutresultatet och vad vi har utvecklat inom tidsramen för kursen. Vi har även fått intrycket att kunden är nöjd och att applikationen motsvarar förväntningarna. 16
10. Bilagor 10.1 Bilaga 1: Presentation av individuell graf 10.2 Bilaga 2: Presentation av stor grupperad graf 10.3 Bilaga 3: Skapa flera användare 10.4 Bilaga 4: Användarhantering 10.5 Bilaga 5: Valmöjligheter vid presentation 17
Bilaga 1 Presentation av individuell graf 10.1 Exempel på graf renderad på individuell traceroute. 18
Bilaga 2 Presentation av stor grupperad graf 10.2 Exempel på en graf baserad på en stor mängd data.
Bilaga 3 Skapa flera användare 10.3 Administratör har möjlighet att skapa flera användare åt gången.
Bilaga 4 Användarhantering 10.4 Administratör har möjlighet att sköta användarhantering i gränssnittet.
Bilaga 5 Valmöjligheter vid presentation 10.5.1 Valmöjligheter vid presentation av grupperad graf. 10.5.2 Vid val av show average ping och show path labels vid rendering av graf.
10.5.3 När användaren inte valt att sammanslå duplicerade vägar vid rendering. 10.5.4 Samma som figur 10.5.3 men med duplicerade vägar sammanslagna.