Linköpings Universitet Medietekniskt kandidatprojekt TNM094 MMDG Massive Multiplayer Dome Game Rapport Gruppmedlemmar: Anton Albèrt Karlström Erik Broberg Philip Burridge Rasmus Haapaoja Martin Kierkegaard Ludvig Mangs Michael Nilsson Johan Sylvan Examinator: Karl Johan Palmerius 3 juni 2014
Sammanfattning Som en del av ett kandidatarbete för utbildningen Civilingenjör i Medieteknik är denna rapport skriven för att återge arbetsprocessen kring utvecklingen av ett system. Systemet i fråga gör det möjligt för andra utvecklare att enkelt skapa applikationer som ett flertal användare kan interagera med samtidigt på samma skärm. Systemet är utformat för att fungera med en applikation skriven i OpenGL med ett externt bibliotek som är anpassat till domteatrar och dess datorkluster. Målet med rapporten är att ge förståelse i de val och prioriteringar som gjorts i utvecklingen av systemet med fokus på att det ska vara möjligt att kunna utveckla en tillhörande applikation. I denna rapport förutsetts det att läsaren har viss kunskap inom systemutvecklingsmetodiker och kan koppla de begrepp som tas upp i denna rapport till teorin, istället fokuserar rapporten på att beskriva arbetsgången i projektet. Under projektets gång har ett flertal slutsatser dragits om hur arbetsprocessen har kunnat förbättras. Bland annat kom systemutvecklarna till insikt om att det är viktigt att inte fastna i analysfasen för länge. Det har även visat sig vara till fördel med en precis tidsuppfattning. Vidare är det viktigt att designa systemet med en bra uppdelning mellan moduler och komponenter. De ska vara isolerade med lågt beroende av varandra och ha ett specifikt syfte. Användbarhet måste tas hänsyn till utifrån två perspektiv, applikationsutvecklare och applikationsanvändare. Det grafiska användargränsnittet ska vara lätt att konfigurera. För att påvisa de ställda kraven för systemet har prestandatester utförts och proof of concepts skapats. Dessa slutsatser har hjälpt oss förstå hur ett system bör utvecklas för att göra det möjligt för andra utvecklare att enkelt skapa applikationer till systemet som klienter kan interagera med samtidigt.
Innehåll 1 Inledning 1 1.1 Bakgrund............................. 1 1.1.1 Mål............................ 1 1.2 Syfte och frågeställning...................... 2 1.3 Avgränsningar........................... 2 1.4 Typografiska konventioner.................... 3 1.5 Definition av ämnesspecifika begrepp.............. 3 2 Redogörelse för arbetet 6 2.1 Projektuppstart.......................... 6 2.1.1 Förstudier......................... 6 2.2 Modellering............................ 8 2.2.1 Programmeringsstil.................... 8 2.3 Projekthantering......................... 9 2.3.1 Versionhantering..................... 9 2.3.2 Dokumentstruktur.................... 10 2.3.3 Tidsplan.......................... 10 2.4 Tillämpningen av Scrum..................... 11 2.4.1 Sprintplanering...................... 12 2.4.2 Sprints........................... 12 2.4.3 Verktyg för hantering av scrum............. 13 2.5 Systemarkitektur......................... 13 2.5.1 Klientsidan........................ 14 2.5.2 Server........................... 15 2.5.3 Applikation........................ 17 2.6 Programdesign.......................... 19 2.6.1 Klienter.......................... 20 2.7 Gränssnitt mellan klasser..................... 22 2.8 Testning.............................. 23 2.8.1 Statisk testning...................... 23 2.8.2 Enhetstester........................ 23
2.8.3 Integrationstester..................... 23 2.8.4 Prestandatester...................... 24 3 Resultat 25 3.1 Utvecklingsprocessen....................... 25 3.2 MMDG-systemet......................... 26 3.3 Testresultat............................ 27 3.3.1 Prestandatest 1 (lokalt test)............... 27 3.3.2 Prestandatest 2...................... 27 3.3.3 Prestandatest 3...................... 27 4 Diskussion och framtida arbete 29 4.1 Resultat från prestandatest................... 29 4.2 Analysis paralysis......................... 29 4.3 Burndown chart.......................... 30 4.4 Utvecklingslaget.......................... 31 4.5 Retrospekt............................. 31 4.6 Hur klienter ansluter till MMDG-server............. 32 4.7 Kundkontakt........................... 33 5 Slutsatser 34 Appendices 37 A Use case diagram 38 B Kommunikationsdiagram 39 C Aktivitetsdiagram 40 D Ostandardiserade ritningar 43 E Kravspecifikation 44 F Exempelklass Java 46 G Medarbetare 49
Figurer 2.1 Exempel på Java......................... 9 2.2 Tidslinje över projektets sprints................. 10 2.3 Trellobacklog........................... 12 2.4 Överblick över ett fullständigt MMDG-system.......... 14 2.5 Överblick över klientens komponenter.............. 15 2.6 Överblick över serverns komponenter............... 15 2.7 Serverkod............................. 16 2.8 Enkel testapplikation som använder SGCT........... 17 2.9 Bomb Game testas........................ 18 2.10 RobberCop är ett multiplayerspel som använder SGCT.... 18 2.11 MMDG GUI............................ 21 2.12 Klassdiagram........................... 22 3.1 Sprint 1 till 3, från vänster till höger.............. 25 3.2 Överblick över det framtagna MMDG-systemet........ 26 3.3 Testapplikationen RobberCop.................. 26 3.4 Prestandatest 1.......................... 27 3.5 Prestandatest 2.......................... 28 3.6 Prestandatest 3.......................... 28 A.1 Use case diagram......................... 38 B.1 Kommunikationsdiagram..................... 39 C.1 Aktivitetsdiagram 1........................ 41 C.2 Aktivitetsdiagram 2........................ 42 D.1 Diagram på tavla......................... 43 D.2 Diagram på tavla......................... 43 G.1 Statistik från Github. Observera att arbetsbördan inte är direktrelaterad med uppladdningar, på grund av parprogrammering............................... 50
Tabeller 1.1 Typografiska konventioner.................... 3 3.1 Värdena avser de anpassade andragradspolynomen...... 28
Kapitel 1 Inledning 1.1 Bakgrund Visualiseringscenter C visar ett flertal föreställningar varje dag i sin domteater där det kan vara uppåt hundra besökare vid varje tillfälle. Centret ser potential i att låta publiken interagera med vad som händer på skärmen, till exempel genom att de kan rösta på vilka föreställningar som ska köpas in eller att de kan spela ett spel mot varandra innan en föreställning. I rapporten kommer publiken refereras till som klienter, alltså användare av systemet. För att denna interaktion ska kunna ske behöver centret ett system som sköter kommunikationen av den input som kommer från klienter till den önskade applikationen. Systemet behöver vara anpassningsbart för att möjliggöra uppdatering och implementering av nya applikationer som passar de olika målgrupperna som gästar domen. Detta system kallas MMDGsystem och de som utvecklar applikationer som använder sig av systemet nämns som MMDG applikationsutvecklare. 1.1.1 Mål Världsrekordet för flest antal spelare på samma skärm är 113 personer. Det har varit ett mål att slå detta rekord. För att kunna uppfylla detta mål måste systemet vara utformat på ett sådant sätt att det är tidseffektivt då fördröjningen som uppstår när klienter ska kommunicera med applikationen ökar när fler klienter kopplar upp sig. 1
1.2 Syfte och frågeställning Syftet med rapporten är att beskriva systemutvecklingen av ett system som gör det möjligt för andra utvecklare att enkelt skapa applikationer som flera klienter kan interagera med samtidigt. De grundläggande frågeställningarna för rapporten lyder enligt: Hur kan en agil metod som scrum[2] tillämpas för systemutveckling av projekt som innefattar flertalet delsystem, där utvecklarna är relativt oerfarna inom både programmering och systemutveckling? Är det möjligt att producera ett system som kan hantera över 100 användare inom den givna tiden och med den kompetens som finns till befogande? Hur kan en Medieteknisk bakgrund vara en fördel för ett systemutvecklingsprojekt som kräver en bred teknisk kompetens? Hur kan ett system som möjliggör interaktion mellan flera användare och en extern applikation designas och utvecklas? 1.3 Avgränsningar I denna rapport förutsätts det att läsaren har viss kunskap inom systemutvecklingsmetodiker och kan koppla de begrepp som tas upp till teorin, istället fokuserar rapporten på att beskriva arbetsgången i projektet. Projektledningsmodellen, dess livscykel och faser är lika i de flesta olika typer av systemutvecklingsmetodiker. Emellertid är planeringen, uppföljningen och styrningen specifika för det här projektet vilket innebär att även resultatet blir specifikt. Såleds kommer den här rapporten inte ha generella slutsatser och diskussioner. 2
1.4 Typografiska konventioner Teckensnitt eller symbol AaBbCc123 AaBbCc123 Innebörd Ordet finns definierat i ordlistan på sidan 3 Text i bold är namn på klasser Exempel Utvecklingsmetoden scrum tillämpas. Klassen MMDG Server sköter all kommunikation. Tabell 1.1: Typografiska konventioner 1.5 Definition av ämnesspecifika begrepp MMDG: Massive Multiplayer Dome Game: Produkten MMDG-Server: Den server som sköter kommunikationen mellan klienterna och applikatione n Scrum: Utvecklingsmetodiken som använts under projektets gång [4]. Scrum master, scrummästare: Den som ansvarar för att arbetet går framåt inom utvecklings laget. Product owner, produktägare: Den som håller kontakt med kund och håller koll på backlogen. Scrum meeting, scrummöte: Dagligt möte då gruppen går igenom vad de gjort, vad de ska göra och om det är något som hindrar för att utföra uppgiften. Sprint: En tidsbestämd iteration inom scrum där arbetet är uppdelat till mindre uppgifter och slutförs. User Story: Produktägaren tar kundens önskemål för slutprodukten och bildar en kort beskrivande text. Task, uppgift: User stories delas upp i mindre uppgifter, detta är en task. Planning poker, planeringspoker: En metod inom systemutveckling för att uppskatta tidsåtgång av tasks. Det går tillväga genom att anonyma uppskattningar av en task ges av alla medlemmar i gruppen. Den uppskattning som flest gissat på sätts som arbetstid för tasken. 3
Product backlog: Här dokumenteras alla user stories prioriterade efter vad som ger mest mervärde till slutprodukten. Sprint backlog: För varje sprint skapas tasks av user stories som läggs in i sprintkatalogen. Utvecklarna kan då välja en att implementera. För varje task estimeras tidsåtgången. Burndown Chart: En graf för varje sprint som visar sprintens framåtskridande mot det beräknade slutdatumet. Code review, kodgranskning: En granskning av kod som skapats av en annan utvecklare för att hitta fel och buggar. Trello: Verktyg för product backlog och sprint backlog Card: Symboliserar en task som en utvecklare kan ta på sig att implementera. To do-lista: Består av cards och varje lista kan till exempel användas för olika stadier av att slutföra en task. Board: Består av to do-listor och cards. UML (Unified Modelling Language): Ett sätt att modellera programstruktur [7](Sida 347-348). Use Case Diagram: Övergripligt beskriver vilka krav som ställs på systemet, vad som ska kunna göras och av vem. Activity Diagram: Förtydligar i vilken ordning som de olika funktionaliteterna genomförs och hos vilken modul. Communication Diagram: Visar hur olika komponenter kommunicerar med varandra. Class Diagram: Illustrerar vilka klasser som ska finnas och deras respektive funktioner och variabler. Nätverk. Transmission Control Protocol (TCP): Ett protokoll för nätverkskommunikation. User Datagram Protocol (UDP): Ett protokoll för nätverkskommuniktation. Simple Graphics Cluster Toolkit (SGCT): Ett bibliotek utvecklat för att enklare kunna skapa applikationer anpassade till domteatrar och dess datorkluster. Git: Versionshanteringsverktyg. 4
Branch: Ett eget arbetsutrymme för till exempel en egen uppgift som jobbas med separat ifrån de andra brancherna. Merge: Lägger ihop två olika brancher till en. Genom Git kommer all kod med från båda brancherna om det inte finns någon konflikt. Repository: Det som ligger lokalt på datorn innan man skickar iväg det till resten av deltagarna. Agil utveckling: Egenorganiserat flexibelt arbetssätt som använts under arbetet. Består av flera iterationer. Trådning (multithreading)- En metod som möjliggör parallell exekvering av programkod Websockets: Verktyget som används på klientsidan för att kommunicera med servern. 5
Kapitel 2 Redogörelse för arbetet 2.1 Projektuppstart Det första steget som utfördes inom projektet var att bestämma att gruppen skulle följa den agila utvecklingsmetoden scrum och att dela ut de roller som behövdes. Andra beslut som togs var hur versionshantering skulle utföras samt vilka medier som skulle användas för hantering av övriga dokument. För att kunna fastställa vad kunden förväntar sig av systemet bokades ett möte där kundens krav och förhoppningar diskuterades. Det var viktigt med god förståelse om hur systemet skulle fungera innan arbetet inleddes. Detta ledde till att kundmöten bokades in regelbundet under projektets gång. En kravspecifikation bestämdes utifrån diskussioner kring de önskemål som kunden hade på systemet, se bilaga E. En projektplan skapades där projektets mål, utvecklingsmetodik och tekniska lösningar var huvudämnen. Till denna skapades även en tidsplan med alla sprintar inplanerade för att lätt få en överblick om hur arbetet förhåller sig till slutdatum. 2.1.1 Förstudier Kravet på att systemet ska kunna användas av åtminstone 100 användare innebar att förstudier behövde inledas innan arbetet påbörjades. Detta för att förhindra en eventuell fördröjning om många personer kopplar upp sig samtidigt. Eftersom systemet behövde vara stabilt för flera användare var ett snabbt programmeringsspråk att föredra. De förstudier om vikten av ett snabbt språk bestod av sökningar på internet. Dessa visade inga tydliga tecken på att något av de aktuella språken skulle vara betydligt sämre än något annat för det ändamål som MMDG-applikationsutvecklarna ville utföra. 6
Den kommunikation inom systemet som påverkar fördröjningen mest är TCP-kommunikationen som inte påverkas av programmeringsspråket. Det som skulle komma att ha störst inverkan på hastigheten hos systemet var dock internetuppkopplingen. Således influerades inte valet av programmeringsspråket av denna risk att systemet skulle kunna bli fördröjt för fler användare. De programmeringsspråk som diskuterades var C++, C#, JavaScript och Java. En av fördelarna med C# var att det finns många inbyggda funktioner i.net som kan användas för att få servern att fungera. Dock var en stor nackdel att det inte är plattformsoberoende vilket var ett mål från gruppens sida. JavaScript diskuterades med plattformen Node.js i åtanke då detta var ett tips från studenter som använt sig av detta tidigare. Att ha en person som redan är insatt i problematiken, samt fungerande exempelkod till hands skulle underlätta för att snabbt få en fungerande server. En nackdel med Node.js var att det är nytt och relativt oprövat samt att det är skrivet i JavaScript vilket är ett programmeringsspråk som i grunden inte är objektorienterat. De två språk som återstod efter att ovanstående valts bort var C++ och Java vilka båda är språk som är objektorienterade samt som alla gruppmedlemmar har tidigare erfarenhet av. Språket som valdes för webservern var Java då det till skillnad från C++ är plattformsberoende efter kompilering. Två andra fördelar med Java är att det finns inbyggda funktioner för att hantera websockets samt att trådning är simplare att implementera i det språket än i C++. Nätverkskommunikation Kommunikationen mellan systemets olika moduler måste ske via någon form av protokoll för nätverk. De två mest kända är UDP samt TCP, vilka ofta definieras som ett snabbt respektive säkert protokoll. Då SGCT -biblioteket använder sig av TCP-kommunikation för externa anslutningar som standard, i detta fall till MMDG-servern, behöver endast valet av protokoll ske mellan MMDG-server och klienter. Valet föll på TCP, främst då en inbyggd säkerhetskoll redan finns i protokollet, vilken ser till att alla meddelanden som skickas kommer fram i samma ordning som de skickades. UDP-protokollet å andra sidan erbjuder inte en sådan funktion, främst för att kunna göra överföringen av data snabbare. Då säkerhet var prioriterat hade en egen kontroll behövts göras av meddelandena som skickas om UDP hade använts. Detta skulle göra kommunikationen långsammare och då ta bort den fördelaktiga snabbhetsaspekten som UDP normalt innehar. Det var då mer naturligt att använda TCP, då det redan har inbyggd säkerhet, samt för att prestandan i slutändan skulle bli försumbar mellan de två alternativen eftersom allting 7
kommer att ske på lokalt nätverk. Websockets Eftersom TCP-protokollet används för kommunikation mellan klienter och server behöver dessa kunna hålla kontakten och kunna skicka meddelanden mellan varandra samtidigt. En uppgradering av TCP-kommunikationen kan då utföras, till någonting som kallas för websockets. Denna uppgradering tillhandahåller tvåvägskommunikation, det vill säga båda ändarna av uppkopplingen kan skicka meddelanden till varandra samtidigt. Det tillåter även att uppkopplingen alltid upprätthålls via ett så kallat handshake. Vilket medför att en server alltid kan skicka meddelanden till en klient utan att klienten själv ber om att få information skickad till sig. Detta lämpar sig väl till systemets ändamål, främst då information behöver skickas till och från alla klienter på ett smidigt sätt. 2.2 Modellering Den modellering som gruppen valt att använda varierade beroende på behov för den specifika modulen. För att få en övergripande bild av systemet skapades ett Use Case Diagram (Bilaga A) och ett Communication Diagram (Bilaga B), med hela systemets funktionalitet hos alla delar. Det skapades två Activity Diagrams (Bilaga C), ett för initialiseringen av uppkopplingen mot servern och ett för kommunikationen mellan klient, webserver och applikation. Att använda en White-Board för att skapa illustrationer av hur systemet skulle fungera gjordes kontinuerligt för att hålla gruppen insatt i hur systemet fungerade. Då testapplikationen hade ett flertal delar var det rimligt att ha ett eget Class Diagram för dess komponenter. Modellering används för att koordinera alla utvecklare så risken av missförstånd minskar och alla får ökad förståelse för systemet. 2.2.1 Programmeringsstil För att koden skall vara enhetlig och enkel att förstå är det viktigt med en programmeringsstil som alla utvecklare håller sig till. Detta bidrar även till känslan av det gemensamma ägandet av koden, vilket är viktigt i ett projekt där kod ska granskas och förbättras i iterationer. Programmeringsstilen som valts för C++ är en förenkling av Google Style Guide[1] och vid Java implementation användes en stil utformad av gruppen. Googles programmeringsstil är mer omfattande än vad projektgruppen behöver och det 8
skulle krävas en större kraftansträngning för att lära sig en sådan programmeringsstil än vad som är nödvändigt. Nedan är ett exempel på en funktion i Java som innehåller en for-loop som visar hur koden dokumenteras och hur måsvingar ska placeras (figur 2.1). Se bilaga F för exempelkod för en fullständig Javaklass. Figur 2.1: Exempel på Java 2.3 Projekthantering Med ett stort utvecklingslag som arbetar på en produkt är det viktigt med struktur och kommunikation. Inte minst när arbetet handlar om utveckling av mjukvara då det det ofta innebär programmering i samma fil av flera utvecklare. Det behövs kraftfulla och smarta verktyg för att hantera allt inom projektet, annars är det svårt att vara samordnad som grupp. 2.3.1 Versionhantering Eftersom scrum tillämpades som utvecklingmetodik, betydde detta att varje gruppmedlem behövde någonstans att spara koden för sin uppgift och enkelt kunna dela med sig av denna till övriga gruppmedlemmar. För att uppnå detta användes Git med ett stängt repository på GitHub:s hemsida. Varje task utvecklades då separat på en specifik branch med samma namn som uppgiften i fråga. Namngivningen gör det även enkelt för kodgranskaren att veta vilken branch som skall granskas. Kodgranskaren utför sedan en merge med master branch i ett repository, förutsatt att koden inte innehåller några fel. Det vill säga varje slutförd task förs hela tiden in i master branch, där endast den senaste fungerande versionen av koden skall finnas. 9
2.3.2 Dokumentstruktur Vid hantering av övriga filer som inte innehåller kod användes plattformarna Google Drive samt Dropbox. Dokument som till exempel textfiler lagrades på Google Drive, då flera personer enkelt kan redigera samma dokument samtidigt. Detta visade sig fördelaktigt under möten samt under sammanställningar av dessa eftersom medlemmarna kunde föra anteckningar tillsammans vid kundmöten och sprintplaneringar etc. En struktur av hur dessa dokument är uppdelade såg ut enligt följande: Projektplan Projektrapport Förstudier Sekreterare Övrigt Mötesprotokoll Dropbox utnyttjades för att snabbt komma åt bilder samt skisser på t.ex. arkitekturen över systemet. 2.3.3 Tidsplan När projektet startade fanns det redan ett antal utsatta deadlines samt uppehåll, för t.ex. disposition av individuell uppsats, halvtidsseminarium och medieteknikdagarna. Utifrån dessa tillverkades en tidsplan(fig 2.2) som visade vilka interna deadlines som skulle behöva följas under projektet. Till exempel inledning och avslutning av sprints samt syfte med dessa och även vad som skall fungera i programvaran efter utförd sprint. Då arbetet sker agilt kan tidsplanen ändras om justeringar skulle behövas. Figur 2.2: Tidslinje över projektets sprints 10
Mål med sprint 0 Den första sprinten utfördes som ett test, främst för att göra förstudier samt testa på agil utveckling. Serverspråk samt protokoll mellan systemets olika moduler var de områden som främst utforskades. Mål med sprint 1 Målet med den första skarpa sprinten var att utveckla ett enkelt proof of concept. Vilket skulle visa hur en klient, via en server, kunde styra en SGCTapplikation på något sätt. Mål med sprint 2 Då endast en klient efter sprint 1 kunde styra en enkel testapplikation, var det naturliga steget att implementera stöd för flera användare samtidigt. Ett andra mål var att utveckla ett GUI för klienter, vilket skulle genereras via en konfigurerbar XML-fil. Mål med sprint 3 Sprintens huvudsakliga mål sattes till att utveckla ett mindre spel för flera spelare. Eftersom gruppen under de första två sprintsen i princip färdigställt server samt GUI delarna kändes det då rimligt att utveckla ett mer avancerat proof of concept. Mål med sprint 4 Målet för den sista sprint:en var att finslipa slutprodukten samt att addera små mervärdesfunktioner för till exempel spelet. Det vill säga inga stora och nya delar utvecklades under denna sprint. 2.4 Tillämpningen av Scrum För att projektarbetet skulle fungera på ett effektivt sätt var det viktigt att tilldela de ansvarsområden som behövdes. Två roller som bestämdes tillhör inte den typiska scrummodellen men tillsattes ändå för att de ansågs vara viktiga. Dessa roller var: sekreterare som har ansvaret för att föra protokoll på möten samt rapportansvarig som skulle se till att rapporten blir skriven i tid. De roller inom scrum som valdes var scrummästare, produktägare och utvecklare. 11
2.4.1 Sprintplanering För att strukturera arbetet inom nästkommande sprint användes sprintplanering. Produktägaren började med att välja ut relevanta user stories från product backlog som skulle utgöra en bra iteration i arbetet. Det tilldelades sedan en dags arbete till att bryta ner user stories till tasks samt uppskattades tiden varje task skulle ta att utföra, se figur 2.3. Figur 2.3: Trellobacklog Alla tasks har delats upp i delmål för att förtydliga arbetsgången och öka förståelsen. Varje gruppmedlem har uppskattat hur lång tid en task kräver och sedan utfördes en röstning där majoriteten av rösterna avgjorde arbetstiden. Inför sprintplaneringen till sprint 3 genomfördes en planning poker. Detta gjordes för att undvika grupptryck och få en rättvisare röstning. 2.4.2 Sprints En sprint inleds med att de tasks som är mest prioriterade delas ut till samtliga utvecklare efter intresse och kompetens. En del av dessa tasks handlade om undersökning inför implementation medan andra handladeom implementation av kod. De olika tasksen utfördes stundtals av flera personer parallellt och ibland med parprogrammering vid svårare moment. Varje arbetsdag inleddes med ett stående möte, som var begränsat till 15 minuter, där gruppmedlemmarna berättade om gårdagens samt framtidens arbete. Dessa möten strukturerade den kommande dagens arbetsgång eftersom uppgifterna koordineras mot varandra för att undvika missförstånd. När en task sedan blivit färdigställd utfördes även code review och testning på varje färdig task. I slutet av varje sprint framställdes ett retrospektiv som analyserade hur sprinten har fungerat, exempelvis diskuterades hur alla verktyg och all kommunikation mellan utvecklarna fungerat under sprinten. Detta görs främst för 12
all lära sig av tidigare misstag och tillämpa dessa lärdomar till nästkommande sprints. 2.4.3 Verktyg för hantering av scrum Eftersom scrum är uppbyggt av flera moment där struktur och ordning är viktigt användes Trello.com, en hemsida där gruppedlemmarna tillsammans kan strukturera alla viktiga delar inom scrum. Trello är inte bara ett effektivt verktyg för utvecklare av en produkt, utan också för andra parter inom företaget när det behövs en enkel översyn över utvecklingen av produkten. Genom att skapa flikar som kallas boards för både en product backlog och sprints är det enkelt att strukturera alla user stories och tasks inom varje sprint. Vilket gör det enkelt att se vad som är påbörjat och vad som behöver implementeras. Väl inne i en board läggs det till cardss som representerar en task, vilken kategoriseras med olika rubriker och även en tillhörande kravspecifikation där det bockas av när delmoment har genomförts. Användandet av fyra rubriker utgjorde en logisk grund för varje sprint; to do, implementing, code review och done. I början av varje sprint bröts relevanta user stories ner till tasks som lades i to do-listan. därefter gjordes kvalificerade gissningar på hur många timmar dessa tasks skulle ta att utföra för att få ett preliminärt slutdatum då sprinten skulle vara färdig. De olika kompetenserna inom gruppen valde sedan tasks utifrån kunskap och intresse, vilket enkelt markerades med en profilbild på den tasken. När ett moment i sprinten var färdigställt drogs denna task till nästa rubrik Code review, för att granskas och testas. Detta för att motverka buggar och svårbegriplig kod. För att få en överblick så att sprinten kommer bli klar i tid användes en burndown chart[4] där alla arbetade timmar ställs emot de tasks som skall färdigställas. När en sprint slutfördes gjordes hela processen om för den nästkommande sprinten. Hela tanken med trello har varit att strukturera arbetet och göra arbetstiden så effektiv som möjligt genom att meddela alla inblandade hur projektet fortlöper. 2.5 Systemarkitektur För att uppnå ett system som är skalbart och lätt att underhålla, krävs det att systemet utvecklas modulbaserat. Om designprincipen tillämpas väl, resulterar det i att varje modul får ett entydigt ändamål och är relativt oberoende av resten av systemet. Utgångspunkten har varit att implementera modulerna med minimalt beroende av övriga komponenter (loose coupling) för att strukturen ska bli mindre komplex[3](sida 323). 13
De olika delarna av det fullständiga MMDG-systemet kategoriserades som MMDG-applikation, MMDG-server samt MMDG-serverns klientsida. Denna uppdelning illustreras i figur 2.4 nedan, där gråa pilar representerar informationsflöde. Figur 2.4: Överblick över ett fullständigt MMDG-system. 2.5.1 Klientsidan Klientsidan är skriven i HTML, CSS, XML och Javascript. Ett krav var att det grafiska användargränsnittet ska vara anpassningbart efter en specifik applikation. Det beslutades tidigt i projektet att låta detta göras genom en XML fil. För att uppnå ett konfiguerbart användargränsnitt har vi använt oss av objektorienterad Javascript. Utgångspunkten var att ha en klass per element som ska kunna visas på skärmen, där element innebär komponenter som knappar, displayer och utfyllnader. Dessa element hanteras av Gui-klassen som har en lista av varje element. Gui-klassens användargränssnitt består av tre funktioner: dess konstruktor, loadelements() och drawgui(). Dessa funktioner har i uppgift att ladda in de specifierade elementen från XMLfilen, se till att alla rutor i rutnätet är fyllda och sedan generera HTML för användargränsnittet. Utöver detta finns en oberoende script-fil som tar emot och skickar meddelanden till servern via WebSocketprotokollet för att notifiera om knapptryckningar och dylikt. I figur 2.5 nedan är denna fil är markerad i rött. 14
Figur 2.5: Överblick över klientens komponenter. Figur 2.5 illustrerar hur klientsidans komponenter är beroende av varandra. XML-filen är applikationutvecklarens gränssnitt och config.xml definierar användargränsnittet för MMDG-applikationen. 2.5.2 Server En större del av utvecklingsarbetet bestod av framtagandet av MMDG- Servern. I framtagandet av MMDG-servern har modulariseringen baserats på de olika uppgifter som servern ansvarar för att hantera. MMDG-serverns fyra huvudsakliga uppgifter definierades till att: 1. Förse nya klienter med ett grafiskt användargränssnitt samt all nödvändig funktionalitet för att kunna interagera med en MMDG-applikation. 2. Lyssna på- och skicka meddelanden till anslutna klienter. 3. Validera och sammanställa klienternas meddelanden. 4. Lyssna på- och skicka meddelanden till och från MMDG-applikation. Figur 2.6 nedan illustrerar MMDG-serverns interna delar och dess interna beroenden med de svarta heldragna pilarna. Figur 2.6: Överblick över serverns komponenter. 15
Som figur 2.6 visar definieras MMDG-servern genom fyra huvudkomponenter, en för varje ansvarsområde. Det framgår även genom riktningen på pilarna att den komponent som heter MMDG Server är högst upp hierarkinivån; alla andra komponenter är beroende av den. MMDG-Server Klassen MMDG Server definierades i syftet att fungera som ett kontrollcenter över de andra komponenterna. Då en instans av denna klass skapas, skapas hela serversystemet och denna klass definierar då även det gränssnitt eller fasad genom vilket alla övergripande inställningar görs. Java-koden (figur 2.7) nedan exemplifierar hur man kan starta upp en MMDG-server. Figur 2.7: Serverkod Applikationshanterare Applikationshanteraren (ApplicationHandler) togs fram för att lyssna på applikationens inkommande meddelanden och spara dessa till dess att den blir tillkallad. I det här fallet genom ett anrop från MMDG Server. Den skulle även fylla funktionen att skicka ett angivet meddelanden till applikationen. HTTP-hanterare En HTTPhanterare (HTTP Handler) definierades i syfte att sköta hantera överföringen alla nödvändiga filer som behövs på klientsidan. Dessa filer definierar den websida som kommer utgöra användargränssnittet hos kienten. WebSocket-hanterare WebSocket-hanteraren (WS Handler) togs fram för att hantera kommunikationen med de anslutna klienterna. När en ny klient ansluter till servern skapas en klienthanterare som omhändertar den klienten i en separat tråd. För den här modulen övervägdes att implementera ett designmönster för 16
asynkron dataöverföring och därefter fördefiniera ett total antal trådar som har hand om samtliga klienter. På grund av tidsbrist valdes detta att inte genomföras. 2.5.3 Applikation En MMDG-applikation definierades som ett program som använder en MMDGserver och tillåter att flera klienter interagerar med applikationen samtidigt. Att utveckla en fullständig applikation var utanför projektets omfattning, men trots det har testapplikationer utvecklats under projektets gång i syfte att fungera som proof of concepts. Dessa applikationer använde sig av SGCTs inbyggda funktionalitet för fönsterhantering och TCP-kommunikation. Snurrande triangel Den första och enklaste testapplikation bestod endast av en fil: main.cpp. Denna applikation verifierade att kommunikationen från klienterna nådde fram till applikationen genom att en triangels rotationsriktning ändrades. I figur 2.8 nedan visas en bild på applikationen samt en översiktlig skiss över dess enkla struktur. (a) Bild av triangel. (b) Struktur av applikation Figur 2.8: Enkel testapplikation som använder SGCT Bomb Game Den andra testapplikation, kallad Bomb Game, skapades inte som en extern applikation, utan som en applikation implementerad direkt på servern. Detta gjordes genom att skapa en underklass till MMDG Server, som överskuggar den metod som processerar klienternas meddelanden. Spelet som går ut på att uppkopplade kienter skickar en virtuell bomb mellan varandra, som efter en viss tid exploderar hos någon av klienterna. Syftet med Bomb Game var att testa kommunikationen mellan servern och flera klienterna, och 17
samtidigt fa mo jlighet att ho ra vad testanva ndarna tyckte anga ende responstider med mer. Figur 2.9 nedan visar en bild pa na r Bomb Game demonstrerades pa en mindre tillsta llning som inkluderade fo rta rande av fo rfriskande drycker. Figur 2.9: Bomb Game testas Multiplayerspel: RobberCop Den andra testapplikationen i SGCT gjordes na got mer omfattande och verifierade att flera klienter kan interagera samtidigt. Varje uppkopplad klient tilldelas en avatar som kan ga omkring i spelets 2-dimensionella spelplan. Antingen blir man tjuv eller polis, och spelet ga r ut pa att poliserna ska fa nga tjuvarna. I figur 3.3 nedan visas en bild pa applikationen samt en o verblick av dess struktur. (b) Struktur av spel (a) Bild av spel. Figur 2.10: RobberCop a r ett multiplayerspel som anva nder SGCT En klass kallad MMDG Core utvecklades med funktionaliteten att kunna utfo ra benchmarking (tidtagning av klienters responstid) samt avkodning av inkommande meddelanden. Syftet med detta var att andra utvecklare pa 18
ett enkelt sätt ska kunna återanvända denna grundläggande funktionalitet i utvecklandet av egna MMDG-applikationer. 2.6 Programdesign För att bryta ner vad för typ av kopplingar som behövs, har modelleringen skett händelse-orienterat [3](sida 259). Detta har gjorts genom att följa informationsflödet genom systemet i olika scenarion. Modelleringen har dels utförts med hjälp av UML[5] kommunikationsdiagram (figur B.1 på s. 39) och aktivitetsdiagram(figur C.1 på s. 41), men även med hjälp av ostandardiserade ritningar (figur D.1 och D.2 på s. 43). Kommunikationen mellan modulerna sker i form av textsträngar via dataöverföringsprotokoll och gränssnittet ligger således i vad som skrivs i dessa strängar. Textsträngarna som skickas kallas kommandon och innehåller argument(/flaggor) med tillhörande värden som är separerade med avgränsningstecken. De kommandon som skickas mellan klient och MMDG-server innehåller två argument: Variabel (var=), används till knappens namn. Värde (val=) Om knappen trycks eller släpps. Dessa värden definieras av applikationsutvecklaren konfigurations-filen tillsammans med det grafiska användargränssnittet. Kommandot verifieras sedan i MMDG-servern och skickas därefter vidare till applikationen med ett extra argument ID (id=). Detta argument används till att identifiera vilken klient som skickat kommandot. Nedan demonstreras ett kommando som applikationen skulle kunna få in: id=3 var=btn3 val =1; Ett krav från kunden var att varje klient ska associeras med ett unikt id och att det inte ska vara möjligt att skicka kommandon som någon annan klient. En lösning som övervägdes vid projektets början var att spara ett IDnummer som krypterats med en hash funktion[6](ref. 212 i datastrukturboken) hos klienten och låta den skickas med i dess kommandon. Vid händelsen att en klient blir ifrånkopplad på grund av en oförutsedd anledning och sedan återfår kopplingen skulle detta förenkla hanteringen. En klient skulle då kunna fortsätta kontrollera samma ID-nummer som tidigare. Istället beslutades att utföra identifikationshanteringen på MMDG-servern. Säkerhetsaspekten blev således inbyggd eftersom klienterna inte kan kontrollera vad för ID som 19
skickas till applikationen. Att återuppkoppla en förlorad anslutning var varken ett krav eller en önskvärd funktion. På applikationssidan kan MMDG-core klassen användas som superklass till applikationen för att läsa av och dela upp meddelandet. Funktionen process från Core klassen måste sedan överskridas (override) i applikationen för att definiera vad som ska göras med argumenten i ett kommando. Kommandon kan även skickas från applikationen till enskilda eller alla klienter med argumentet ID tillsammans med ett meddelande som skrivs ut på klientens displayruta. 2.6.1 Klienter Besökare i domen kommer använda sina egna mobiltelefoner för att interagera med applikationen. Nedan beskrivs den tekniska bakgrunden och redogörelse för besluten som tagits. Användargränssnitt En besökare bemöts av ett gränssnitt som fungerar på alla mobiltelefoner och Web-läsare. Hemsidan är storleksanpassad efter varje mobiltelefons storlek och upplösning. Gränssnittet består av en tre-gånger-tre-matris där varje plats på skärmen skall definieras som en knapp eller tom ruta. Matrisen är uppbyggd av div-taggar som är designade av en CSS-fil. GUI design Vid designen av användargränssnittet för MMDG:s proof of concept fanns ett antal aspekter att ta hänsyn till. Först och främst hur placeringen av alla objekt sker, där kunskaper från en medieteknisk bakgrund kan utnyttjas. Då spelet robbercop kräver att en spelare kan förflytta sig i åtta olika riktningar kändes det rimligt att placera respektive knappar utefter kanterna av skärmen, enligt figur 3.3b. Detta för att till exempel en förflyttning åt höger känns mest naturlig om den sker med ett tryck längst ut i höger kant av skärmen. Spelet kräver inte bara förflyttningar, utan även att viss information kan visas på en spelares enhet, via text i detta fall. Detta flöde av information placerades centralt på grund av två saker. Först och främst för att informationen blir mest synlig i mitten av en skärm, samt för att endast en plats fanns kvar att fylla i det fördefinierade 3x3 rutnätet för GUI:t. En annan aspekt att ha i åtanke är det visuella utseendet. Eftersom kunden vill använda systemet i Visualiseringscenter C:s dome-teater, där stark belysning kraftfullt påverkar upplevelsen till det negativa, användes en mörk 20
och nedtonad färgpalett. Projektorerna i dome-teatern har redan utan andra ljuskällor i lokalen problem med färgåtergivningen och konstrasten. Just därför är vikten av att hålla GUI:t så mörkt som möjligt väldigt stor. Då en fullsatt dome med ungefär 100st ljusa displayer skulle göra kontrasten samt färgåtergivningen ännu sämre. Figur 2.11: MMDG GUI Konfigurering Det utvecklarna av applikationen skall definiera är den tre-gånger-tre-matris som finns på hemsidan. Detta görs med en XML-fil som enkelt begrips utan stor tenkisk kunskap. Antingen skall det vara möjligt att trycka på en knapp eller en tom ruta och båda av dessa representeras av en bild. Eftersom dessa knappar skall styra applikationen måste utvecklarna veta vilken knapp som trycks ner, därför definieras också knapparna med ett ID som även används i applikationen för att identifiera ett knapptryck. Kommunikation En slags kommunikation behöver etableras mellan klienten och servern för att applikationen skall kunna interageras med. När en knapp trycks ner skickas ett meddelande med Websockets som både berättar ID:t på knappen, om knappen trycks ner eller släpps och vilken klient det är som trycker. 21
2.7 Gränssnitt mellan klasser Gränssnitt definierar vilka funktioner en mjukvaruenhet tillhandahåller resten av systemet och hur andra enheter kommer åt dessa funktioner [3](sida 328). Det hjälper en utvecklare att kapsla in en mjukvaruenhets designoch implementationsdetaljer från andra utvecklare, vilket också gör systemet lättare att underhålla [3](sida 330). MMDG-Servern har en huvudklass MMDGServer. Denna klass samordnar de olika serverns komponenter. I dess konstruktor initieras därför en instans av TCPHandler, WebSocketHandler och HTTPHandler. När den publika funktionen run() används i MMDGServer, startas HTTPhanteraren och det påbörjas en oändlig loop som hämtar och skickar vidare kommandon från både klienterna och applikationen. Komponenterna i MMDGServer har ingen inbördes kommunikation, alla funktionsanrop sker via huvudklassen. WebSocketServer-klassen har en nästlad klass (inner class) ClientHandler. Denna design valdes för att förenkla och förtydliga beroendet mellan WebSocketServer och ClientHandler. I Klassdiagrammet nedan (figur 2.12) har alla privata funktioner och variabler dolts för att illustrera vilka funktioner som bygger upp klassens gränssnitt. Figur 2.12: Klassdiagram 22
2.8 Testning I projektet har testning använts för att identifiera fel i koden och på så sätt uppnå hög funktionalitet och stabilitet. Testningsfasen i ett projekt kan generellt sätt aldrig riktigt nå ett slut eftersom det nästan alltid finns fler gömda buggar i koden. Det har alltså varit viktigt att kunna avgöra när sökandet av fel skulle avslutas för att kunna hålla deadlines och gå vidare i projektet. I agil systemutveckling har testning förekommit i varje task och story. Testningen har därför tillfogats kontinuerligt för att kunna försäkra att koden ständigt har hög kvalitet. När testning har förekommit har en utvecklare som inte har skrivit koden hanterat testningen. Detta har lett till bättre felsökning och optimering av kod eftersom utvecklaren som inte har skrivit koden i regel inte fastnar i samma fällor när denne analyserar kod som utvecklaren som skrev koden. Testning som använts i detta projekt kan delas upp i fyra delar. Statisk testning, enhetstester, integrationstester och prestandatester. 2.8.1 Statisk testning Statisk testning har främst använts vid programmering i Eclipse. Den inbyggda testningen i programmet har ständigt levererat återkoppling om hur kod ska skrivas vilket har lett till att slarvfel minskat. 2.8.2 Enhetstester Enhetstester har i viss mån genomförts efter att varje modul utvecklats. Ett exempel på hur enhetstest har gått tillväga är testningen av kommunikationen mellan server och klinter. Eftersom klientsidan av MMDG-systemet inte var klar vid den tiden som kommunikationen behövde testas, skapades en virtuell klient som alltså inte var implementerad på klientsidan. Dessa virtuella klienter gjorde det möjligt att testa kommunikationen genom att skicka och ta emot meddelanden [3](sida 438). 2.8.3 Integrationstester Integrationstester har utförts för att testa hela systemet. Genom att skapa testapplikationerna snurrande triangel och robbercop, nämda ovan, har hela MMDG-systemet granskats. Dessa integrationstester har tagit lång tid att göra. Emellertid har de varit viktiga eftersom de testat att integrationen mellan komponenterna fungerar. 23
2.8.4 Prestandatester I prestandatester säger applikationen till servern att pinga alla klienter. Vidare mäter testen hur lång tid det tar för varje klient att svara på ett ping-meddelande skickat från applikationen. För varje mätning beräknas medelvärdet av alla responstider, och baserat på dessa värden anpassas ett polynom av grad två. Prestandatester har tillåtit utvecklarna att se hur snabb kommunikationen i MMDG-systemet är. Detta har i sin tur gjort det möjligt att följa kundens krav om hur snabbt systemet behöver vara. 24
Kapitel 3 Resultat 3.1 Utvecklingsprocessen Graferna i figur 3.1 visar burndown charts för sprint ett till tre där den önskade tidsåtgången (gul) visas mot den faktiska (blå) och de hittils arbetade timmarna (röd). Det kan utläsas att sprint ett och två var nära önskad medan i sprint tre fanns det brister i tidsuppdateringen på uppgifter i trello. Figur 3.1: Sprint 1 till 3, från vänster till höger 25
3.2 MMDG-systemet Den resulterande produkten är ett system med flera komponenter som tillsammans behandlar de givna kraven utifrån en strukturerad grund. En översikt över fullständiga MMDG-systemet med testapplikationen RobberCop visas i figur 3.2 nedan. Figur 3.2: Överblick över det framtagna MMDG-systemet En bild på testapplikationen RobbeCop och dess tillhörande användargränssnitt redovisas i Figur 3.3 nedan. (a) Gemensam vy (b) Användargränssnitt Figur 3.3: Testapplikationen RobberCop Det system som har skapats är nu en fungerande kommunikation från klient till applikation via en server. När klienten ansluter sig till servern på sin mobila enhet möts hen av ett användargränssnitt som frågar efter ett spelarnamn. Som besökare är det sedan fritt fram att spela (fig 3.3b) spelet tillsammans med alla andra anslutna besökare. Kommunikationen från klient till applikation är snabb och enkel för att de som utvecklare av andra applikationer till systemet inte skall behöva förstå all serverkod. Testapplikationen robbercop är nu färdigställd, det går att röra sig runt i hela Domen och samla poäng som både polis och tjuv (fig 3.3a). 26
3.3 Testresultat Nedan redovisas resultaten från prestandatesten av systemet. I testerna har klienterna anslutits genom olika flikar i webläsare på en datorn. 3.3.1 Prestandatest 1 (lokalt test) Under det lokala prestandatestet kördes applikationen, servern samt klienterna från samma dator. Testresultaten visas i Figur 3.4 nedan. Figur 3.4: Prestandatest 1 3.3.2 Prestandatest 2 Under prestandatest 2 kördes applikationen och klienterna från samma dator, och servern på en separat dator. Testresultaten visas i Figur 3.5 nedan. 3.3.3 Prestandatest 3 Under prestandatest 3 kördes applikationen, servern och klienterna från tre separata datorer. Testresultaten visas i Figur 3.6 nedan. För de anpassade andragradspolynomet i graferna ovan gäller tabell 3.1 nedan. 27
Figur 3.5: Prestandatest 2 Figur 3.6: Prestandatest 3 Test R 2 skärning med 100 ms 1 0.9010 367 klienter 2 0.9625 469 klienter 3 0.7686 394 klienter Tabell 3.1: Värdena avser de anpassade andragradspolynomen 28
Kapitel 4 Diskussion och framtida arbete 4.1 Resultat från prestandatest Testen har visat att MMDG-servern, som körs på en vanlig persondator, klarar av över 300 användare samtidigt, med förutsättningen att samtidigt uppfylla kundens krav på en responstid på maximalt 100 millisekunder. Kundens krav avser dessutom den tid det tar meddelanden från klient till servern. Tiderna som mätts i testerna avser den tid det tar för ett meddelande att skickas från applikationen till server, till klienterna, tillbaka till servern och slutligen tillbaka till applikationen. Med följande resonemang kan man alltså hävda att prestandakravet är uppnått med god marginal. Vad testerna dock inte tar hänsyn till är att alla klienternas meddelande skickas från olika fysiska enheter och därmed från olika IP-adresser. I testerna har samtliga klienter simulerats från samma dator och meddelandena har skickats från samma IP-adress, vilket eventuellt skulle kunna göra routerns jobb enklare och snabbare än i praktiken. Detta är visserligen inte något vi kan påverka, men samtidigt kan det innebära att testresultaten som presenteras i denna rapport kan vara missvisande. För att få mer precisa och rättvisa testresultat skulle motsvarande tester behöva göras med samtliga klienter uppkopplade från olika fysiska enheter. Dessutom skulle det vara värdefullt att höra användarnas kommentarer på responstiden. Det kan hända att användarna i praktiken är mer kräsna än det krav som kunden ställde på detta system. 4.2 Analysis paralysis I början av ett projekt finns det risk att fastna i en så kallad analysis paralysis, ett stadie av planering och efterforskning utan beslut. Under första sprinten 29
undersökte gruppen vilket programspråk som skulle användas till serverdelen av MMDG-systemet, denna period blev projektets utveckling fördröjd. Det berodde i första hand på att kunden hade ställt krav på att olika språk skulle testas på servern och att valet av språk skulle baseras på de som ger bäst prestanda. Detta tillvägagångssätt var inte hållbart för arbetet eftersom det skulle ta för lång tid med den kunskap gruppen hade. Prestanda kan alltid förbättras och optimeras vilket betyder att det enklaste prestandatestet av ett visst språk inte skulle ge en rättvis bedömning av hur systemet skulle prestera i slutändan. Valet av språk baserades därför på andra kriterier. Kunder kan komma med orealistiska krav och då gäller det att man förhandlar fram en kompromiss och ber dem att prioritera kraven efter absolut essentiella, önskvärda och valfria krav[3][s. 178]. Eftersom prestandaundersökningen sågs som ett önskvärt krav som var väldigt omfattande bortprioriterades det. Nästan en månad efter den första kundkontakten togs ett beslut för att påbörja utvecklandet av systemet. Det här problemet skulle antagligen kunna undvikas genom att våga misslyckas eller om mer erfarenhet inom agil utveckling hade införskaffats. 4.3 Burndown chart För att planera framtida utveckling är det mycket bra om det sker tidsestimeringar och dokumentering av hur lång tid uppgifterna har tagit. På detta sätt erhålls direkt återkoppling på gruppens tidsuppskattningsförmåga vilket ger en bättre möjlighet till planering framöver. I ett projekt där efterforskning ingår i uppgifterna har detta varit svårare än förväntat och har därför inte gett oss särskilt mycket underlag för planering. Ofta pratas det om manstimmar när tidsuppskattningar diskuteras, och i en projektgrupp med nybörjare inom systemutveckling hinner alla uträtta väldigt olika mängd arbete på en manstimme. Parprogrammering har i vissa fall använts i förhoppningen att arbetstiden på en task ska halveras, men det är ett antagande som visat sig brista vilket har lett till ännu svårare tidsuppskattningar. Därutöver bör tilläggas att gruppmedlemmarna har haft andra åtaganden vid sidan om detta projekt, vilket har lett till att vissa tasks stått stilla i burndown chart under dessa tillfällen. Trots detta kan vi dra lärdomar från tidsdokumentationen. Med hjälp av burndown charts har det förtydligats exempelvis när arbetet har varit ineffektivt samt att kodgranskning borde fått högre prioritet för att produkten snabbare skulle få sitt värde. Om inte koden granskas kontinuerligt kommer 30