Linköpings universitet SE–581 83 Linköping 013-28 10 00 , www.liu.se
Examensarbete på grundnivå, 15hp | Datateknik
2018 | LIU-IDA/LITH-EX-G--18/016--SE
DQ - Digitalt biljettsystem
DQ - Digital ticket system
Samuel Blomqvist
Fredrik Malmfors
Christopher Peters
William Sjöblom
Daniel Thorén
Ludvig Westerdahl
André Willquist
Handledare : Simon Mehari Examinator : Kristian Sandahl
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admi-nistrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstan-ces. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchang-ed for non-commercial research and unchang-educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c Samuel Blomqvist Fredrik Malmfors Christopher Peters William Sjöblom Daniel Thorén Ludvig Westerdahl André Willquist
Syftet med denna rapport är att redovisa utvecklingen av ett digitalt biljettsystem som skulla användas av studentföreningar vid Linköpings universitet. Systemet utvecklas av studenter vid Linköpings universitet på uppdrag av individer representerande LinTek och StuFF, två kårer vid universitetet. Målet med projektet är att utveckla ett digitalt kösystem som studenter vid Linköpings universitet kan använda för att köpa biljetter till fester el-ler liknande. Resultatet av projektet är ett i många aspekter fungerande system som dock saknar vissa grundläggande aspekter. Utöver det utvecklade systemet har även denna rap-port skrivits inklusive en individuell del per gruppmedlem som går in på djupet i olika områden relaterade till projektet.
Författarnas tack
Projektgruppens handledare Simon Mehari tackas varmt för hjälp och stöd under projektets gång och för hjälpen att styra projektet åt rätt håll när detta behövdes. Utöver detta tackas kursledningen för en mycket lärorik kurs.
Sammanfattning iii Författarens tack iv Innehåll v Figurer viii Tabeller x 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställning . . . 2 1.4 Avgränsningar . . . 2 1.5 Begränsningar . . . 2 2 Bakgrund 3 2.1 Uppgift . . . 3 2.2 Tidigare erfarenheter . . . 3 3 Teori 5 3.1 Agil utveckling . . . 5 3.2 Scrum . . . 5
3.3 Model View Controller . . . 6
3.4 Docker . . . 6 3.5 Git . . . 6 3.6 AWS . . . 7 3.7 JavaScript . . . 7 3.8 HTML och CSS . . . 7 3.9 Bootstrap . . . 7 3.10 Vue.js . . . 8 3.11 Axios . . . 8 3.12 Node.js . . . 8 3.13 Express.js . . . 8 3.14 Mocha . . . 9 3.15 PostgreSQL . . . 9 4 Metod 10 4.1 Uvecklingsprocess . . . 10 4.2 Dokumentskrivning . . . 12 4.3 Utbildning . . . 13
4.4 Utvärdering och process för att fånga erfarenheter . . . 14
4.5 Kommunikation . . . 14 5 Resultat 16 5.1 Systembeskrivning . . . 16 5.2 Gränssnittsdesign . . . 22 5.3 Gemensamma erfarenheter . . . 24 5.4 Värde för kund . . . 25 5.5 Testning . . . 26
5.6 Översikt över individuella bidrag . . . 26
6 Diskussion 28 6.1 Metod . . . 28
6.2 Resultat . . . 30
6.3 Projektet i ett vidare sammanhang . . . 32
7 Slutsats 34 7.1 Hur kan det digitala biljettsystemet implementeras så att man skapar värde för kunden? . . . 34
7.2 Vilka erfarenheter kan dokumenteras från utvecklingen av det digitala biljett-systemet som kan vara intressant för framtida projekt? . . . 34
7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 35
7.4 Vilka för- och nackdelar har ett digitalt- jämfört med ett fysiskt biljettsystem? . 35 A En jämförelse av användningsområden och analys av framtiden för SQL jämfört med NoSQL av André Willquist 37 A.1 Inledning . . . 37 A.2 Bakgrund . . . 38 A.3 Teori . . . 39 A.4 Metod . . . 43 A.5 Resultat . . . 43 A.6 Diskussion . . . 45 A.7 Slutsatser . . . 46
B Användning av MVC för en Webbapplikation i ett Team av Ludvig Westerdahl 48 B.1 Inledning . . . 48 B.2 Teori . . . 49 B.3 Metod . . . 51 B.4 Resultat . . . 52 B.5 Diskussion . . . 54 B.6 Slutsatser . . . 56
C Digitalisering och social hållbarhet av Samuel Blomqvist 57 C.1 Inledning . . . 57 C.2 Bakgrund . . . 58 C.3 Teori . . . 58 C.4 Metod . . . 59 C.5 Resultat . . . 60 C.6 Diskussion . . . 63 C.7 Slutsatser . . . 64
D Responsivitet i en webbapplikation av Fredrik Malmfors 65 D.1 Inledning . . . 65
D.2 Bakgrund . . . 66
D.6 Diskussion . . . 70
D.7 Slutsatser . . . 71
E Eventdriven concurrency i JavaScript och Node.js av William Sjöblom 72 E.1 Inledning . . . 72
E.2 Bakgrund . . . 73
E.3 Teori . . . 74
E.4 Metod . . . 74
E.5 Resultat . . . 75
F Högre abstraktioner med ramverk av Christopher Peters 80 F.1 Inledning . . . 80 F.2 Bakgrund . . . 81 F.3 Teori . . . 81 F.4 Metod . . . 83 F.5 Konstruerat problem . . . 83 F.6 Resultat . . . 84 F.7 Diskussion . . . 86 F.8 Slutsatser . . . 88
G Jämförelse mellan websockets och AJAX av Daniel Thoren 90 G.1 Inledning . . . 90 G.2 Bakgrund . . . 91 G.3 Teori . . . 91 G.4 Metod . . . 94 G.5 Resultat . . . 94 G.6 Diskussion . . . 97 G.7 Slutsatser . . . 98 Litteratur 99 vii
Figurer
4.1 Skärmdump från Slack som visar de kanaler som gruppen använde sig av för
intern kommunikation. . . 15
5.1 Systemanatomi översikt. . . 17
5.2 Vue-komponentträd på klientsidan . . . 19
5.3 Backend JSON API svarstruktur . . . 20
5.4 Alfavy . . . 22
5.5 Betavy . . . 23
5.6 Slutgiltig vy . . . 24
A.1 Exempel på SQL tabell . . . 39
A.2 Exempel på nyckel värde-lagring . . . 41
B.1 MVC för en webbapplikation . . . 50
C.1 Hur många fester på LiU annordnade av festerier eller andra studentbaserade utskott går du på per år i genomsnitt? . . . 61
C.2 Färger och svar. . . 61
C.3 Jag blir stressad inför biljettsläpp. . . 61
C.4 En vidare analys av de som både har deltagit på minst en studentanordnad fest-lighet samt känner stress inför biljettsläpp. . . 62
C.5 Jag anser att stor press inför biljettsläpp gör att de som lyckas få tag i biljetter faktiskt är de som är mest sugna på festen. . . 62
C.6 Skulle du vilja slippa pressen inför biljettsläpp? . . . 63
C.7 Social applikations-användning för de som ej svarat Stämmer mycket dåligt angå-ende stress inför biljettsläpp. . . 63
D.1 Skärmdump: Definition av viewport. . . 67
D.2 Skärmdump: Bredd på ett responsivt respektive statiskt element. . . 67
D.3 Skärmdump: Media-taggar i CSS. . . 68
D.4 Skärmdump: Användning av fönsterbredd i JavaScript. . . 69
D.5 Skärmdump: Exempel på komponent för responsivitet i Vue (definition av bryt-punkter). . . 69
D.6 Skärmdump: Exempel på komponent för responsivitet i Vue (användning i HTML). 69 D.7 Skärmdump: Grid-struktur med hjälp av Bootstrap. . . 70
E.1 Övergripande vy över event-loop och event-kö i Node.js . . . 76
F.1 Vyn som representerar datan. . . 83
F.2 Vyn av funktionspanelen. . . 84
F.3 Katalogstruktur av implementation i JavaScript. . . 85
F.4 Katalogstruktur av implementation i JavaScript. . . 85
Tabeller
A.1 Jämförelse av SQL och NoSQL . . . 44 F.1 Jämförelse av LOC . . . 85 F.2 Jämförelse av LCOM . . . 86
Ord Betydelse
Frontend Delen av en webbsida användaren kan se och
inte-ragera med.
Backend Delen av en webbsida som lever på servern och
ex-empelvis tillhandahåller affärslogik och databas. JavaScript Ett interpreterat programmeringsspråk som
möjlig-gör interaktiva webbsidor.
HTML HTML (HyperText Markup Language) är ett
märk-språk som används i webbsidor för beskriva dess visuella struktur.
CSS CSS (Cascading Style Sheets) är ett märkspråk som
beskriver hur en webbsidas visuella struktur ska presenteras.
Node.js Exekveringsmiljö för JavaScript med tillhörande
bibliotek för asynkron I/O.
NPM (Node Package Manager) är ett verktyg till Node.js
för att installera tredjepartspaket.
Express.js Ett webbapplikations-ramverk för Node.js.
DBMS DBMS (Database Management System) är ett
sy-stem som förenklar användningen av databaser.
PSQL PSQL (PostgreSQL) är en sorts DBMS.
SQL SQL (Structured Query Language) är ett
standar-diserat programspråk för kommunicera med ett DBMS.
Vue.js Ett frontend-ramverk för JavaScript.
Axios Ett JavaScript-bibliotek för hantering av
HTTP-anrop.
HTTP Kommunikationsprotokoll för överföring av data
över internet.
Open-source Icke proprietär programkod som är öppen för all-mänheten att använda, läsa och distribuera.
DOM DOM (Document Object Model) är ett
plattforms-och språkoberoende gränssnitt som ger program-språk möjlighet att dynamiskt ändra dokumentets innehåll.
jQuery Ett JavaScript-bibliotek som förenklar operationer
på DOM-trädet.
LiU-ID Identifikation för anställda och studerande vid Lin-köpings universitet.
Overhead Överflödiga prestanda-omkostnader.
Repository Ett förvar för programkod, ofta förknippat med ver-sionshanteringssystem.
AWS AWS (Amazon Web Services) En molnplattform för
driftsättning av bland annat webbapplikationer. Deadlock Ett tillstånd där olika medlemmar cirkulärt väntar
på att en resurs ska frigöras.
Route En webbadress till en viss resurs.
Driftsättning Process för att göra en applikation tillgänglig för den stora massan.
Ramverk Generell beskrivning av verktyg och bibliotek som
används vid mjukvaruutveckling.
Designmönster Återanvändningsbar lösning för vanligt återkom-mande problem.
Arkitekturmönster Ett designmönster för ett mjukvarusystems arkitek-tur.
MVC MVC (Model View Controller) är ett
arkitektur-mönster som främjar kodseparation.
Databas En manipulerbar behållare av digital data.
Sprint Ett tidsintervall, i kontexten agil utveckling, där ut-veckling sker som i slutet utvärderas.
Denna rapport är skriven i samband med utvecklingen av ett webbaserat biljettsystem för fester vid Linköpings universitet. Systemet syftar till att underlätta biljettförsäljningen som i dagsläget sköts genom att studenter köar fysiskt. Projektgruppen som utvecklat systemet och skrivit denna rapport består av sju studenter som studerar civilingenjörsutbildningarna data- och mjukvaruteknik på Linköpings universitet.
1.1
Motivering
En väsentlig del av studenternas tid spenderas i köer till olika evenemang och fester vilket stjäl värdefull tid från studierna. Följaktligen är det av intresse att minska den bortkastade tiden vid biljettköp. Förhoppningsvis med extra tid tillhands möjliggör detta studenterna att bättre prioritera studierna i kombination med att närvara på diverse evenemang.
1.2
Syfte
Rapportens syfte är primärt att besvara frågeställningarna genom att beskriva utvecklings-processen och projektets resultat. För detta ändamål ger rapporten dessutom en inblick i pro-jektgruppens arbetssätt och projekterfarenheter.
Projektets syfte är att skapa ett digitalt biljettsystem för användning av studenter vid Linkö-pings universitet åt en extern kund. Följaktligen är projektet essentiellt för att besvara fråge-ställningarna och utgör den största delen av rapporten.
1.3. Frågeställning
1.3
Frågeställning
Rapporten försöker besvara följande frågeställningar vilka syftar till att både avgränsa porten samt definiera rapportens översiktliga mål. Eftersom projektet är en central del i rap-porten används resultaten därifrån för att svara på frågeställningarna.
1. Hur kan det digitala biljettsystemet implementeras för att skapa värde för kunden? 2. Vilka erfarenheter kan dokumenteras från utvecklingen av det digitala biljettsystemet
som kan vara intressanta för framtida projekt?
3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Vilka för- och nackdelar har ett digitalt jämfört med ett fysiskt biljettsystem?
1.4
Avgränsningar
För att så många som möjligt ska kunna använda sig av den utvecklade produkten krävs det att den stödjer olika sorters enheter. Detta leder till att projektet kräver mer resurser. Av denna anledning är detta projektets målplattform webbläsaren, som stöds av majoriteten av enheter i dagsläget och kräver endast minimalt arbete för att fungera som önskat över alla enheter i fråga. Utöver detta antas att alla användare som vill köpa biljetter har eller känner någon med ett LiU-ID då det används för inloggning i systemet samt identifikation vid evenemang.
1.5
Begränsningar
Projektet har en tidsbudget på 2800 timmar utdelat jämt över projektgruppen, detta inklude-rar både utveckling av systemet samt framställning av rapporten. Rapportskrivningen består dels av en gemensam del, dels av individuella bidrag som skrivs enskilt av varje gruppmed-lem. Utöver detta begränsas projektet av ekonomiska faktorer hos kunden och leder till att verktyg behöver väljas sparsamt.
Projektet beställdes av representanter från studentkårerna Stuff och LinTek. Projektets mål är främst att ge studenterna mer tid över till studier och på så sätt bidra till att minska stress och ohälsa ofta relaterat till tidsbrist i samband med evenemang av olika slag.
2.1
Uppgift
Problemet grundar sig i att efterfrågan på fester, sittningar och kravaller är hög då det finns betydligt fler studenter än antal biljetter. Traditionellt sett har man använt sig av en fysisk kö. För närvarande har detta resulterat i att studenter ofta förväntas börja köa redan kvällen innan biljetterna släpps för att försäkra sig om att få tag i dem. Dessutom förväntas man hålla sig vaken då man blir nekad biljett om man sover i kön. Flertalet köer hålls även utomhus vilket gör att kö upplevelsen ofta blir obehaglig på grund av väder och annat oförutsägbart. Att spendera långa tidsperioder och till exempel bli utsatt för kyla kan även ha negativa hälsoeffekter i form av större risk att bli sjuk [1].
Mot denna bakgrund har kunden efterfrågat ett digitalt biljettsystem som ska minska den tid som studenterna spenderar på ett oproduktivt sätt. Köandet kommer istället att ske via webben vilket betyder att studenterna kan sitta på valfri plats. Således kommer köandet att minska den bortkastade tiden och förhoppningsvis även den stress som studenterna upple-ver i samband med köande.
2.2
Tidigare erfarenheter
Gruppmedlemmarna har tidigare erfarenheter av att arbeta i projektgrupp som kan använ-das på ett konstruktivt sätt i framtida projekt för att de ska lyckas bättre. Nedan finns en gemensam sammanställning av vad som är bra att tänka på och vara förberedd på.
• Uppgifter och arbeten inom ett projekt tar längre tid än förväntat.
2.2. Tidigare erfarenheter
• Man bör inte bli avskräckt för att man har lägre grundkompetens än andra i gruppen. Våga ta utmaningar.
• Sträva efter att fördela arbetet jämt och hjälp varandra så mycket som möjligt.
• Försök att kommunicera effektivt sådant att samtligas individuella arbeten kan integre-ras vid senare stadie.
• Sträva efter goda kodkonventioner och snygg struktur i koden så att det blir enklare att läsa varandras arbeten.
• Inspektera varandras kod regelbundet.
I följande kapitel ges en teoretisk bakgrund för ramverk, designmönster och diverse system som användes i metoden för utvecklingen av systemet. Syftet är att ge läsaren översiktliga grundkunskaper för att lättare förstå innehållet i denna rapport.
3.1
Agil utveckling
Agil utvecklingsmetodik är ett samlingsnamn för olika metoder som används vid mjukva-ruutveckling. Detta tillvägagångssätt innebär att krav och lösningar utvecklas allt eftersom utvecklingsprocessen fortskrider genom nära samarbete mellan utvecklare och kund. Med andra ord, en iterativ utvecklingsmetodik. Agil utveckling lägger även stor vikt vid funge-rande arbetslag av storleksordning tre till nio personer. Utöver detta läggs också stor vikt vid att inte bryta upp ett välfungerande arbetslag när uppgiften arbetslaget skapades för är utförd. I enlighet med agil utvecklingsmetodik bör den gruppen istället arbeta på en ny upp-gift [2]. Den agila utvecklingsmetodiken kan enkelt sammanfattas via dess värderingar som presenteras i följande lista.
• Individer och interaktioner över processer och verktyg • Fungerande mjukvara över omfattande dokumentation • Samarbete med kund över kontraktsförhandlingar • Flexibilitet gentemot förändringar över strikt planföljande
3.2
Scrum
Scrum är ett processramverk för mjukvaruutveckling som presenterar en metodik anpassad till det agila utvecklingsperspektivet. Utöver det tillför scrum ett antal värden och artefakter till utvecklingsprocessen. Scrum är primärt teorin gällande hur varje individuellt arbetslag,
3.3. Model View Controller
presenterat i den agila utvecklingen, ska bete sig. Scrum lägger till exempel stor vikt vid sprinter av längd kortare än 30 dagar där arbetslag jobbar tillsammans för att utföra den maximala mängd arbete som går från en prioriterad lista av uppgifter som ofta kallas sprint backlog eller endast backlog. I slutet av varje sprint genomförs en utvärdering angående hur många av uppgifterna som har slutförts samt vad som är kvar att göra. Inom scrum har man dessutom ett så kallat stå-upp möte dagligen, ofta på morgonen, där alla utvecklare presen-terar vad som har utförts föregående dag och vad som ska göras under dagen. Detta leder till bättre kommunikation mellan medlemmarna och bidrar till öppenhet kring svårigheter som uppstår inom mjukvaruprojekt [3].
3.3
Model View Controller
Arkitekturmönster är återanvändningsbara lösningar på vanliga problem inom systemut-veckling. Ett vanligt mönster är MVC viket står för Model View Controller (sv. Modell Vy Styr-ning). Denna lämpar sig väl för webbapplikationer [4, 5]. MVC passar väl eftersom mönstret går ut på att separera systemet i tre primära delar som kallas modell, vy och styrning. Model-len ansvarar för data i systemet i form av lagring och hämtning från en källa såsom en data-bas eller dylikt. En vy presenterar data som fås från modellen för en användare. Styrningen hanterar interaktionen mellan användaren och systemet, med andra ord är styrningen in-gångsporten in till systemet för användaren. Dessutom ansvarar styrningen för att rätt data hämtas från modellen och skickas till vyn. Följaktligen är målet med MVC att separera upp-gifterna inom ett system på ett sådant sätt att komponenterna är oberoende av varandra och kommunicerar på ett standardiserat sätt, via ett gränssnitt eller API [6]. Därtill ska modellen inte veta om att styrning eller vy existerar. Samma sak gäller för en vy, den bör inte veta om att modell eller styrning existerar. I praktiken kan det vara svårt att till fullo implementera dessa strikta krav. Målet är dock att implementera systemet och dela upp det i modeller, styr-ningar och vyer i enlighet med MVC. Ofta implementeras ett API mellan de olika delarna för att separera dem samt minska kopplingar och beroenden.
3.4
Docker
Docker är ett verktyg för att bygga, driftsätta och exekvera en applikation i en, så kallad, behållare. En behållare är en enhet som isolerar en applikation och som kan exekveras utan att direkt bero på den fysiska hårdvaran. Behållare och virtuella maskiner (Virtual Machine) är till största delen lika i dess mål men har vissa skillnader såsom att en behållare består utav bibliotek och applikationer medan en virtuell maskin även består utav ett, så kallat, gäst-OS. Ett gäst-OS är ett operativsystem som körs under tillsyn av operativsystemet på den fysiska maskinen. Utöver detta, om all utveckling sker mot en behållare, betyder detta att miljön programmet körs i är identiskt på alla datorer vilket innebär att det inte finns några datorspecifika beroenden så som externa ramverk, operativsystem eller bibliotek. Detta leder till att driftsättning av applikationen förenklas eftersom en behållare är en självinnehållande enhet [7].
3.5
Git
Git är en typ av versionshanteringssystem som utvecklades samtidigt som Linux efter ut-vecklarna gav upp på att använda BitKeeper [8]. Gits primära funktionalitet är förmågan att skapa så kallade utvecklingsgrenar. Utvecklingsgrenar är förgreningar av koden som kan
utvecklas parallellt. Detta gör det möjligt för olika utvecklare att bygga olika funktioner sam-tidigt utan att arbeta i samma kopia av koden. Därför kan de låta bli att ändra och förstöra funktionalitet som någon annan använder sig av eller förlitar sig på innan det är dags att sammanfoga koden.
Utöver förmågan att skapa utvecklingsgrenar tillhandahåller även Git flera andra funktioner så som att skapa kontinuerliga återställningspunkter, kunna spara koden på en egen server samt låta flera personer ladda ned samma kod. En annan sak som skiljer Git från andra ver-sionshanteringssystem, till exempel SVN (Apache Subversion), är att Git tillåter användaren att göra många lokala sparningspunkter innan de väljer att även uppdatera koden på servern. SVN låter endast användaren uppdatera koden på servern vilket betyder att man antingen riskerar ha mycket föränderlig kod på servern eller att användaren inte skapar återställnings-punkter ofta nog och förlorar jobb om något går fel.
3.6
AWS
AWS är en förkortning för Amazon Web Services och är en molntjänst som erbjuder beräknings-kraft, databaslagring, webhotell etc. Kunder betalar för hur mycket prestanda de använder där prestanda kan mätas på flera olika sätt, exempelvis antal CPU cykler som används eller mängden data som skickas över nätverket från applikationen. Användare får tillgång till en virtuell maskin, ofta utspridd över flera fysiska servrar, på vilken de kan ladda upp och köra sina applikationer. I fallet med webbapplikationer görs dessa oftast tillgänglig för allmänhe-ten via internet [9]. AWS har funktionalitet för att fungera med program som körs i en docker behållare, vilket gör det enkelt att driftsätta en applikation som är byggd med docker.
3.7
JavaScript
JavaScript är ett imperativt skriptspråk som kan interpreteras av alla moderna webbläsare. JavaScript används i huvudsak för att implementera logik på klientsidan för att skapa dyna-miska webbsidor. JavaScript har på senare tid även börjat användas för backend utveckling [10].
3.8
HTML och CSS
Samtliga webbsidor som syns i webbläsaren består av HTML (HyperText Markup Language) och CSS (Cascading Style Sheets) [11]. Dessa två språk beskriver webbsidans komponentstruk-tur samt hur dessa komponenter ska se ut och placeras [12]. Däremot är inte webbutvecklare tvungna att skriva sina hemsidor direkt i dessa två utan kan istället använda generatorer, JavaScript och ramverk. Alla dessa metoder kommer som slutprodukt producera HTML och CSS som webbläsaren sedan renderar.
3.9
Bootstrap
Bootstrap är ett frontend-bibliotek som förser användaren med färdig HTML och CSS de-sign. Till detta hör också att Bootstrap underlättar utvecklingen av dynamiska hemsidor då biblioteket har som mål att fungera på enheter med olika skärmupplösningar [13].
3.10. Vue.js
3.10
Vue.js
Vue är ett ramverk som underlättar utvecklingen av frontend med JavaScript, det har många unika funktioner som utmärker det jämfört med de andra ramverken. Templates i Vue an-vänds för att binda det renderade DOM trädet till Vue instansens data och skrivs helt i HTML. Dessa templates kompileras till virtuella DOM funktioner för att tillåta enkel manipulation av DOM trädet. Då det är relativt dyrt att ändra i DOM trädet används ett virtuellt DOM träd för att minimera antalet sådana operationer. Vues främsta och kraftfullaste funktionalitet är Components. Dessa används för att dela upp en Vue.js applikation viket gör den mer modu-lär och hanterbar. En komponent är ett avgränsat segment med HTML- och JavaScript kod som går att återanvända i applikationen. Dessutom är det möjligt att bädda in komponenter i varandra och på så sätt skapa en hierarki av dessa byggblock där det också är enkelt att kommunicera mellan komponenterna.
Ramverket Vue tillåter också att man delar upp strukturen i single file components, vilket innebär att varje Vue-komponent ligger i en egen fil med filändelsen “.vue”. Dessa filer packas sedan ihop till en enda JavaScript fil med hjälp av det externa verktyget Webpack [14]. Varje sådan fil innehåller den HTML, JavaScript och CSS-kod som används av den komponenten som filen representerar. Denna isolering av resurser kan göra koden mer strukturerad och lättare att förstå [15].
3.11
Axios
Axios är ett HTTP-bibliotek för JavaScript som hanterar HTTP-förfrågningar mellan klient och server. Vue.js, till skillnad från andra frontend-ramverk, har inte ett eget bibliotek som hanterar HTTP-förfrågningar vilket innebär att ett externt bibliotek behövs. Som tidigare nämnt strävar Vue.js till att komprimera kod till så få rader som möjligt. Detta är en strä-van även hos Axios vilket leder till att dessa två fungerar väldigt bra tillsammans [16].
3.12
Node.js
Node.js är en plattformsoberoende miljö för att exekvera JavaScript-kod och är designad för att bygga skalbara nätverksapplikationer. Hur denna skalbarhet uppnås går att läsa mer om under appendix E.
3.13
Express.js
Express.js, ofta förkortat Express, är ett ramverk för att bygga webbapplikationer och APIs för Node. Express förenklar utvecklingen av webbapplikationer genom att förse användaren med funktioner som i grunden använder sig utav Node. Ramverket är minimalt i storlek och funktionalitet vilket innebär att det blir flexibelt att använda där den största delen av funktionaliteten finns som plugin-programvara [17]. Eftersom det är minimalt och endast tillför ett tunt lager ovanpå Node förlorar man inte Node:s prestanda och robusthet.
3.14
Mocha
Mocha är ett testningsramverk för Node och JavaScript som effektiviserar testning av asyn-krona applikationer. Testerna körs seriellt vilket tillför mer flexibilitet och bättre testresultat. Det är ett minimalt testramverk med mycket funktionalitet som är enkelt att använda. I kon-trast till detta är flexibilitet inte alltid önskvärt då det leder till mycket konfiguration innan testningen kan påbörjas [18].
3.15
PostgreSQL
PostgreSQL är ett av de mest använda databassystemen [19]. Ett databassystem, också kallat DBMS (Database Management System), är ett mjukvarusystem som tillhandahåller funktionali-tet för att interagera med en databas. För detta ändamål används vanligen språket Structured Query Language, ofta kallat SQL. SQL är ett deklarativt språk vilket betyder att man speci-ficerar vad som ska göras och inte hur. Till detta hör också att SQL blev en ISO-standard (International Organization for Standardization) redan 1992 och det finns uppdaterade standar-der från så tidigt som 2003 [20]. Att SQL är det dominerade språket för kommunikation med databaser har lett till att många databassystem, inklusive PostgreSQL håller sig övergripande till dessa standarder. PostgreSQL arbetar speciellt hårt med detta och marknadsför sig med hur väl de följer standarden [21].
Dessutom upprätthåller även PostgreSQL alla de fyra ACID egenskaperna, Atomicity (sv. Atomicitet ), Consistent (sv. Konsekvens), Isolation (sv. Isolering), Durability (sv.Hållbarhet) [22, 23]. ACID är viktigt för multitrådning då det definierar regler gällande hur olika trådar ska hanteras för att undvika konflikter och felaktigheter i databassystemet när flera processer modifierar databasen samtidigt. PostgreSQL stödjer även alla de olika standardiserade data-typerna definierade av SQL standarden. Utöver detta så stödjer den flera andra egenskaper som även de definieras i standarden.
4
Metod
Detta kapitel redogör en mängd varierande metoder som har nyttjats under projektet för utvecklingen och det övergripande administrationsarbetet. Metodiken relaterad till utveck-lingen av projektet definierades i form av en projektplan i början av projektet.
4.1
Uvecklingsprocess
En väldefinierad utvecklingsmetod användes för att underlätta för projektgruppen att kunna arbeta gemensamt. Det som sammanfattningsvis nyttjades var en anpassad version av en agil utvecklingsmetod, dokumentskrivning för att konkretisera planeringen och verktyg för intern kommunikation och administration. Varje gruppmedlem blev också tilldelad en roll som motsvarade ett visst ansvarsområde i utvecklingsprocessen.
4.1.1
Scrum
Projektgruppen använde sig av en agil utvecklingsmetod som inspirerats av scrum. Projekt-gruppen valde att primärt tillämpa sig av sprints, sprint backlog och scrum board. Efter varje sprint hölls ett möte där gruppen utvärderade den föregående sprinten och planerade pro-jektets nästkommande sprint. Vid planeringen flyttades de högst prioriterade aktiviteterna in i den sprint backlog som skulle gälla för nästa sprint. Dessa illustrerades i ett scrum board med hjälp av Trello. Trello är ett webbaserat verktyg som på ett distinkt sätt illustrerar arbets-flödet i varje sprint, vilket fyller funktionen av ett scrum board. En sprint hade ett tidsspann på två veckor då det ansågs vara ett rimligt tidsspann för utvärdering och prioritering av aktiviteter.
4.1.2
Systemanatomi
En systemanatomi togs fram för att ge en överskådlig bild av projektets helhet och relevanta delar. Denna används bland annat som hjälp för att specificera punkter för kommunikation
mellan frontend och backend. Den hjälper även till att visualisera hur de olika delarna av systemet kan brytas upp samt specificerar vilka andra funktioner varje del beror på. Detta kan till exempel användas för att identifiera potentiella flaskhalsar i systemet. En systemanatomi kan utöver detta också användas för att bestämma vilken ordning de olika komponenterna bör utvecklas i. Ett exempel skulle kunna vara att utveckla botten-upp vilket säkerställer att alla funktioner som någon del av systemet beror på är på plats innan man börjar arbeta med den delen.
4.1.3
Utvecklingsmiljö och verktyg
De utvecklingsverktyg som gruppens medlemmar använde sig utav varierade. Dessutom utvecklade medlemmarna på olika operativsystem och plattformar såsom Linux, OSX och Windows. Emellertid fungerade det bra tack vare Docker (se rubrik 3.4). Vissa i gruppen an-vände PhpStorm som utvecklats av JetBrains [24]. PhpStorm lämpar sig väl vid utveckling av webbapplikationer där JavaScript används, då det har flera olika verktyg som kan underlätta utvecklingen. Två exempel på verktyg som tillhandahålls av PhpStorm är Syntax Highlight-ning som gör koden mer lättläslig samt JavaScript Lint som markerar små fel i koden. Andra använde sig av Emacs eller Vim vilka är minimalistiska texteditorer med fördelen att dessa tillåter användaren att modifiera verktygen fritt. Detta tillåter en mer personlig och anpassad miljö vilket kan vara att föredra i vissa sammanhang. Vissa använde sig utav Atom vilket är en relativt minimalistisk texteditor, denna kommer dock med mycket inbyggd funktionalitet jämfört med Emacs och Vim vilket kan vara en fördel då användaren inte behöver lägga lika mycket tid på att konfigurera miljön. Ytterligare ett verktyg som användes var Wireshark som tillåter en att se datorns nätverkstrafik såsom data som skickades med HTTP. Detta användes för att felsöka kommunikationen mellan frontend och backend.
4.1.4
Kodstandard
Kodstandarden som användes i systemet var de vedertagna standarder för de olika språken och ramverken som nyttjades. Utöver detta hade gruppen definierat hur olika route:s (in-gångsportar till det API som fanns på backend) skulle namnges. Detta gjordes för att undvi-ka förvirring om hur systemet fungerade eller vad de oliundvi-ka delarna gjorde. Resultatet blev ett mer konsekvent system som även blev enklare att modifiera och vidareutveckla i framtiden.
4.1.5
Testning
Syftet med testningen av systemet var att säkerställa en kvalitativ produkt som uppfyllde de krav som har hade kommunicerats till kunden i kravspecifikationen. Detta verifierades genom att hitta och förhindra defekter och andra oförutsägbara beteenden som annars even-tuellt skulle kunna förekomma. Till projektet skapades en testplan som bestämde hur utveck-lingsgruppen skulle gå tillväga för att testa produkten.
4.1.6
Arbetsroller
På grund av projektets storlek tilldelades varje gruppmedlem en viss roll för att organisera arbetet. Rollen bestämde vilken del av projektet som individen hade ansvar för.
• Teamledaren ansvarade för måluppfyllnad inom projektet. Individen ansvarade även för att representera utvecklingsgruppen utåt.
4.2. Dokumentskrivning
• Analysansvarig ansvarade för kundkontakten samt att ta reda på vilka krav kunden hade på systemet.
• Arkitekten tog fram en arkitektur över systemet samt identifiera vilka komponenter och gränssnitt som skulle användas.
• Utvecklingsledaren fördelade utvecklingsarbete vid behov.
• Testledaren underhöll och utfärdade tester på systemet. Hade tillsammans ansvar med analysansvarig att kvalitetskraven uppfylldes.
• Dokumentansvarig ansvarade för att sköta dokumentmallar. • Kvalitetssamordnaren såg till att det finns en kvalitetsplan.
• Konfigurationsansvarig bestämde vad som ska versionshanterades samt vad som ingick i leveransen till kund.
4.2
Dokumentskrivning
De dokument som användes för projektet skrevs i LaTeX. Dokumentansvarige ansvarade för att en relevant mall användes för respektive dokument. Dokumentansvarige ansvarade även för att dela in respektive dokument i ett antal filer för att enklare kunna versionshantera dessa via Git. Innan varje inlämning granskades dokumenten av minst en gruppmedlem och inspekterades av en icke-granskande gruppmedlem. Dessa dokument beskrivs under respektive underrubrik.
4.2.1
Statusrapport
Statusrapporter producerades veckovis för att uppdatera handledare och kund om hur pro-jektet fortlöpte. Dessa inkluderade framsteg, motgångar, nya risker och tidrapport för indivi-duella medlemmar.
4.2.2
Mötesprotokoll
Mötesprotokoll fördes för handledar- och kundmöten där information om vad som disku-terats antecknades. På kundmöten fokuserade dessa anteckningar främst på kundens åter-koppling gällande systemet medan anteckningarna som fördes under handledarmöten foku-serade på återkoppling gällande dokumenten. Analysansvarig ansvarade för sammanställ-ningen av dessa.
4.2.3
Kravspecifikation
Kravspecifikationen togs fram av utvecklingsgruppen i samarbete med kunden. Detta do-kument representerade de funktionella och icke-funktionella krav som kunden hade på pro-jektet. All typ av planering och planeringsdokument genomfördes med hänsyn till kraven. Analysansvarige ansvarade för slutförandet och underhåll av detta dokument.
4.2.4
Projektplan
Projektplanen producerades i början av projektet. Meningen med detta dokument var att utvecklingsgruppen skulle ha en konkret plan som de kunde hänvisa till under systemets utveckling. Teamledaren ansvarade för slutförandet och underhåll av detta dokument.
4.2.5
Kvalitetsplan
Kvalitetsplanen bestod av en lista med aspekter i projektutvecklingssyfte som utvecklings-gruppen kunde sträva efter för att försäkra en hög kvalité på systemet. Dokumentansvarige och kvalitetssamordnaren ansvarade för slutförandet och underhållet av detta dokument.
4.2.6
Arkitekturdokument
Arkitekturdokumentet innehöll en översiktlig vy av hur systemets komponenter hängde ihop och fungerade. Detta dokument användes för att synkronisera gruppmedlemmarnas arbete på separata komponenter vilket underlättade vid sammanfogningen av dessa. Arkitekten ansvarade för slutförandet och underhåll av detta dokument.
4.2.7
Testplan
Testplanen beskrev hur systemet skulle testas för att verifiera att man uppfyllde kraven lista-de i kravspecifikationen och kvalitetsaspekterna listalista-de i kvalitetsplanen. Testansvarige an-svarade för slutförandet och underhåll av detta dokument.
4.2.8
Testrapport
Testrapporten sammanställde testerna av systemet, om de lyckades eller misslyckades. Detta dokument producerades och underhölls av testledaren och analysansvarige.
4.3
Utbildning
Projektgruppens medlemmar var i behov av utbildning inom ett antal områden eftersom flertalet inte hade jobbat inom webbutveckling tidigare. Även de som hade erfarenhet av webbutveckling tog nytta av ytterligare kunskap gällande de ramverk och språk som an-vändes i projektet. Utbildning inom respektive områden använde primärt dokumentation på internet men gruppen utförde även interna föreläsningar för att effektivare sprida informa-tionen bland medlemmarna. Enligt projektplanen var utvecklingsgruppen inställda på att ha en grundläggande kunskap inom JavaScript, HTML, CSS, Node.js, Express, PostgreSQL och Vue. En 60-timmars fördjupande utbildning inom Vue, Axiom och Bootstrap var planerat för frontend-utvecklarna. För backend-utvecklarna så var en 18-timmars fördjupande utbildning i Node.js och Express inplanerat. De gruppmedlemmar som arbetade med databasen behöv-de ingen fördjupanbehöv-de utbildning då behöv-de habehöv-de redan haft en kurs i databasutveckling. Allt som krävdes var ett referensdokument för att veta hur kunskaperna applicerades till specifikt PostgreSQL.
4.4. Utvärdering och process för att fånga erfarenheter
4.4
Utvärdering och process för att fånga erfarenheter
Den främsta utvärderingen och uppfångandet av erfarenheter som gjordes var i form av teckningar under handledarmöten samt kundmöten. Kommunikationsverktyget Slack an-vändes utöver kommunikation också till att dela med sig av lärdomar som plockades upp under utvecklingens gång (se rubrik 4.5). Detta nyttjades effektivt i början av projektets ut-veckling då gruppmedlemmarna satt ned och diskuterade gemensamma erfarenheter från tidigare projekt för att kunna undvika att upprepa dem. Utöver dessa aktiviteter var det ett antal mer specifika metoder som gruppen hade i samband med utvecklingsprocess (se rubrik 4.1).
Sprintutvärdering var en utvärderingsmetod som gruppen använde sig av för att göra stör-re stör-reflektioner om grupparbetet. Denna metod är specifik för den utvecklingsprocess som gruppen följde (se rubrik 4.1). Metoden innebär att man efter varje sprint utvärderar det ar-bete som har gjorts under sprinten. Syftet är att gruppen ska få en bättre uppfattning om hur mycket som rimligen kan utföras under en sprint och på så sätt effektivisera planeringen av följande sprints. För projektgruppen hjälpte det också till att kvalitetssäkra alla delar av ut-vecklingen eftersom hela gruppen fick vara med och inspektera utut-vecklingen och då lättare kunde upptäcka potentiella fel. Gruppen tog sedan med sig de lärdomar man sammanfattat under utvärderingen in i nästa sprint vilket succesivt förbättrade både kvalitén och effektivi-teten under projektets gång.
4.5
Kommunikation
Den interna kommunikationen mellan gruppmedlemmarna skedde främst via verktyget Slack där all diskussion var uppdelad i olika kanaler för olika samtalskategorier (se figur 4.1). Då projektgruppen till stor del arbetade samtidigt på samma plats kunde stora delar av kommunikationen skötas verbalt utan tekniska hjälpmedel. Kommunikation med kund skedde främst under planerade kundmöten. Initialt vid första kundmötet bestämdes infor-mellt att det skulle planeras ett kundmöte per sprint. Övrig kommunikation skedde i första hand mellan analysansvarig och kund via e-post eller besök hos kund på kontoret i Kårallen på Linköpings universitet. De som deltog på kundmötena var främst teamledare och analys-ansvarig.
Figur 4.1: Skärmdump från Slack som visar de kanaler som gruppen använde sig av för intern kommunikation.
5
Resultat
I följande kapitel presenteras de resultat som funnits under projektets gång. De resultat som presenteras ämnar primärt att besvara de frågeställningar som ställdes i början av projektet (se rubrik 1.3). Ett av de resultat som beskrivs är en översikt över systemet som utvecklades under projektets gång.
5.1
Systembeskrivning
Här redogörs för hur det utvecklade mjukvarusystemet är uppbyggt, dess övergripande be-ståndsdelar samt hur det fungerar.
5.1.1
Systemanatomi
I projektet fungerade systemanatomin främst som ett verktyg för att i grova drag separera systemet i moduler samt visa de funktionalitetsberoenden som finns mellan dessa. Med en överblick över dessa beroenden kunde sedan funktionalitet prioriteras (se figur 5.1. Systema-natomin var under projektets gång ett väl fungerande verktyg för att till kund kommunicera systemets tekniska aspekter, även vid avsaknad av tekniskt kunnande hos denne.
5.1.2
Frontend
Här beskrivs systemets uppbyggnad på klientsidan.
Övergripande beskrivning
Systemet som beskrivs i denna rapport använder sig av single file components för att göra fil-trädet i projektet så simpelt som möjligt (se rubrik 5.1.2). Webppplikationen har också många Vue-komponenter som återanvänds vid flera tillfällen på olika sätt i applikationen, i syfte att
Sell tickets
Browse events
Manage users
Event list Event view
Sale view Queue Payment Confirmation Manage bought tickets See tickets T ransfer tickets Add event User view Change privilegies Database Change event Remove event Manage events and tickets LiU-id Login Login Consume tickets
Upload images Upload logic
Klarna logic
Klarna
Shop ticket logic
Queue logic Kobra Event logic Image storage Purchased tickets logic Privileges logic Login logic
LiU CAS login Authentication and session
store
Disk
storage
Simplify ticket
sales
5.1. Systembeskrivning
minska förekomsten av liknande kod flera gånger. Flera av komponenterna består av tredje-partspaket som installerats via node package manager. Ett exempel på detta är en komponent vid namn datepicker, som erbjuder en grafisk panel för att välja datum och tid.
För design och stil används till stor del det bibliotek som bootstrap erbjuder, samt komplet-terande CSS-kod, däribland media-taggar för att skapa bra responsivitet till olika webbläsare och enheter. För vidare läsning kring responsivitet i en webapplikation, se appendix D.
Axios
Kommunikationen med backend sker via ramverket Axios vilket bygger på XMLHttp-förfrågningar. Ramverket skapar ett abstraktionslager ovanpå XMLHttp-förfrågningarna som underlättar för utvecklaren [16]. De fyra följande HTTP-förfrågningarna används i pro-jektet, PUT, POST, DELETE och GET. GET används för att hämta data från servern, POST och PUT används för att skapa och modifiera data på servern och DELETE används för att ta bort data från servern [25].
Komponentstruktur
I applikationen har komponenter barn-förälder-relationer. Data kan överföras från en förälder-komponent till en barn-komponent genom en attribut som i Vue kallas “props”. För dataöverföring åt motsatt håll använder applikationen en Vue-funktionalitet kallad “emit” [26].
För att på ett enkelt sätt få en överblick över komponenterna på klientsidan gjordes en kom-ponentstruktur (se figur 5.2). Varje ruta motsvarar en Vue-komponent. Pilarna visar relatio-nen mellan komporelatio-nenterna, där pilens riktning motsvarar förälder till barn-komporelatio-nent. Grö-na rutor motsvarar enstaka komponenter, och de orangea rutorGrö-na motsvarar fall där antalet av dessa kan variera, beroende på applikationens tillstånd. Till exempel kan antalet biljetter variera som en student äger, därav varierar antalet SingleTicket-komponenter som under-komponenter till TicketPage. Komponenterna som ingår i den svarta rektangeln är kompo-nenter som motsvarar hela sidor i gränssnittet, där endast en av dessa kan visas för använ-daren åt gången. Figuren ger endast en övergripande bild av systemet och visar ej mindre underkomponenter.
Figur 5.2: Vue-komponentträd på klientsidan
5.1.3
Backend
Denna del av systemet hanterar anrop från frontend och utför beräkningar eller ger den ef-terfrågande resursen. Då backend är den centrala delen av applikationen är det essentiellt att denna är stabil och fungerar korrekt. Logiken i systemet är implementerad i backend och beskrivs nedan. Dessutom beskrivs hur MVC har implementerats i applikationen.
Kö
Ett datum och en tid för intresseanmälan för en viss biljett ges vid dess skapande eller modi-fierande i applikationen. Efter att en biljett har skapats kommer en kö för intresseanmälan att öppnas vid det givna datumet. En kvart efter öppningen av intresseanmälan tas användare med en viss sannolikhet, som beror på antal biljetter användare i fråga har intresseanmält sig för, från intresseanmälans kö och placeras i en betalningskö. Att just en kvart valdes är godtyckligt men syftar till att ge alla en rättvis chans att placeras i betalningskön och hindrar eventuella datorprogram från att snabbt gå in och betala för en biljett om det istället var först till kvarn. Betalningskön i sin tur kan mer ses som en lista av användare som är i stadiet av att betala för sina biljett(er). Om betalningen för en biljett inte slutförs inom en given tidsram på 30 minuter tas användaren ur betalningskön och en ny användare från intresseanmälans kö får chansen att betala för biljetten. Notera att betalningskön har ett tak på antal användare som kan finnas i den vid en given tidpunkt och bestäms utav antal tillgängliga biljetter för evenemanget i fråga.
Modeller
Inom system representerar en modell en entitet från databasen. Syftet med modellerna är att brygga databasen och ge styrningarna ett simpelt API att använda sig utav för att kommu-nicera med databasen. Detta skapar ett modulärt system där styrningarna är helt oberoende av databasens implementationen då modellernas roll är att hämta och analysera denna data. Alltså kan styrningarna byggas på ett sådant sätt att data kan antas alltid vara på ett visst format eftersom modellerna ser till att följa det specificerade API:t.
5.1. Systembeskrivning
Styrning
De styrningar som existerar i systemet agerar som ingångsport till webbapplikationen. Sy-stemet har flera styrningar vars syfte är att ta emot HTTP anrop från frontend. Detta kan exempelvis innebära att hämta, förändra eller skapa en resurs via dess JSON API. Vid varje anrop får frontend ett svar från backend som följer en viss struktur (se figur 5.3). Det som kan förändras i varje anrop är markerat med ’<’ och ’>’. För närvarande finns endast en version av API:t, men möjlighet finns till fler versioner. Om API:t förändras ska möjligheten finnas att fortsätta använda en äldre version. Detta API specificerar alltså formatet på in- och utda-ta som frontend utgår ifrån och byggs därefter, figuren visar endast på strukturen på utdautda-ta vilket är konstant för alla svar, men indata kan skiljas från olika styrningar. Styrningarna ansvarar också för att modellerna används på korrekt sätt, alltså agerar mellanhand mellan frontend och modellerna. I systemet finns det en styrning som innehåller funktionalitet och logik för de särskilda delarna och resurserna. En resurs menas en biljett, ett evenemang el-ler en användare. Dessutom finns en styrning för login funktionalitet (se figur 5.1). Detta för att separera funktionaliteten för dessa olika delar i systemet och tillhandahålla ingångar för frontend att skicka HTTP anrop och begära en resurs eller att backend utför en eller flera godtycklig funktion(er).
Figur 5.3: Backend JSON API svarstruktur
Databas
Databasen modellerar primärt användare, biljetter och evenemang. Utöver detta finns det flera stödmodeller som hanterar saker så som vilken typ av användare det är eller vilka an-vändargrupper som är inbjudna till vilket evenemang. Alla användare förväntas identifieras i form av ett LiU-ID som är 8 tecken långt. Användare kan vara vanliga studenter, orga-nisatörer, driftchefer och ordföranden. Skillnaderna gäller endast vilka rättigheter de olika användarna har gällande evenemang, biljetter och användargrupper. Organisatörer kan ska-pa evenemang och biljetter till dessa, driftchefer kan publicera evenemang så att allmänheten kan se dem och köpa biljetter samt modifiera användargrupper. Ordföranden kan lägga till och ta bort alla roller, förutom att de inte kan ta bort andra ordföranden, de kan endast ta bort sig själva. Databasen är uppsatt så att all funktionalitet som ska finnas tillgänglig i databasen finns i form av funktioner vilket betyder att modellerna inte behöver kommunicera med da-tabasen själva. Detta är gjort primärt som extra skydd för att undvika SQL injektion samt för att förenkla utvecklingen för utvecklare som behöver arbeta med modellerna men som inte kan SQL syntax.
Biljetter i databasen består av två olika typer, dels finns det affärsbiljetter och det finns köpta biljetter. Affärsbiljetter är kopplade till ett evenemang och innehåller all relevant information om saker som när biljetten kan börja köas till, när de kan börja köpas vad de kostar och så vidare. En köpt biljett är kopplad till en användare när en affärsbiljett, är köpt. Den innehåller information om när biljetten köptes, vem som äger den och vilken affärsbiljett som biljetten
motsvarar. Evenemang används primärt för att gruppera affärsbiljetter som är tänkta att re-latera till varandra, till exempel för att biljetter för olika dagar eller för att biljetter som ska kunna släppas tidigt ska kunna höra ihop med resten. Användare hanteras primärt i form av grupper, de bjuds in, ges rabatter, och håller i evenemang baserat på grupptillhörigheter. Användare kan läggas till i en grupp och grupper bjuds i sin tur sen in till evenemang.
5.1.4
Systemets funktionalitet
Utvecklingsgruppen lyckades uppnå nivå ett kraven i den kravspecifikation man förhandlat fram med kunden. Detta innebär dock ej att systemet blev färdigt, här beskrivs därför vad som blev klart och vad som inte blev klart.
Avsaknad funktionalitet
Två stora komponenter som inte blev klara är betalning via klarna och säker autentisering mot servern. Inloggning via universitetets system “Lisam” implementerades delvis. När en användare loggar in via tjänsten får frontend ett token som bevis på att användaren loggat in. Det som inte implementerats var att autentisera detta token mot backend.
Betalning via klarna visade sig också vara svårare än projektgruppen väntat sig och i brist av tid valde man att prioritera ner denna del.
Ytterligare en del som inte fungerar är hanteringen av användargrupper. Detta är fullt im-plementerat i databasen men fungerar tyvärr ej i backend eller frontend. Detta medför att det inte går att bjuda in specifika användare till evenemang samt att det inte går att ge vissa grupper av användare rabatt på biljetter. Eftersom sättet som förköp försöktes implementeras var genom att skapa en specifik förköpsbiljett för gruppen som skulle ha förköp uteblev även denna funktionalitet.
Tanken var även att implementera ännu en slags användare som skulle kallas “chairman”. Denna skulle ha den högsta behörigheten i applikationen och därmed kunna tillsätta samt ta bort alla andra ansvarsroller. En chairman skulle även kunna utse en ny chairman när denna slutade. Detta fungerar dock tyvärr inte då gruppen var tvungen att lägga resurserna på mer prioriterade uppgifter.
Man kan intresseanmäla sig till en kö rent grafiskt i frontend men själva funktionaliteten för kön är inte implementerad på backend eller databas.
Implementerad funktionalitet
En användare kan se alla tillgängliga evenemang och vilka biljetter som hör till varje evene-mang. De kan även se hur lång tid som är kvar tills en biljett släpps, och en inloggad student kan intresseanmäla sig på biljettsläpp. En användare kan även se sina egna biljetter och över-låta dessa till andra studenter genom att ange ett LiU-ID. Användare kan även byta språk på applikationen. Tillgängliga språk är engelska och svenska.
En administratör kan skapa, redigera samt ta bort evenemang. Dessutom kan de skapa och redigera biljetter för evenemanget i fråga. De kan även lista alla biljetter som hör till ett visst LiU-ID samt riva biljetter. De kan även klistra ihop en biljett om den rivits för att kunna ändra vid misstag.
5.2. Gränssnittsdesign
En driftchef kan publicera och avpublicera evenemang. När ett evenemang publiceras blir det tillgängligt för alla studenter.
5.2
Gränssnittsdesign
Gränssnittsdesignen utvecklades under flera iterationer. I början så designade gruppen gränssnittet med hjälp av en prototyp. Prototypen skapades digitalt och skrevs sedan ut till papperssidor. Denna prototyp fick kunden sedan “trycka på” för att simulera navigation, och beroende på vad kunden klickade på fick denna se olika papperssidor.
Figur 5.4: Alfavy
5.2.1
Alfavy
Den initiala vyn var den som designades för gränssnittsprototypen (se figur 5.4). Prototypen skapades i det molnbaserade prototypverktyget Balsamic Mockups och var främst anpassad för mobilanvändare [27]. Vyn var vid detta stadie inriktad på att ha separata sidor för kom-ponenter, det vill säga att man till exempel skulle gå till en ny sida när man klickar på ett evenemang i listan.
Figur 5.5: Betavy
Gränssnittets utseende under mitten av applikationens utveckling.
5.2.2
Betavy
Betavyn etablerades under den andra iterationen av utvecklingen (se figur 5.5). Efter att tea-met hade fått erfarenhet inom ramverket uppkom nya möjligheter och idéer på förbättringar som kunde göras för gränssnittet. Vid detta stadie hade även en vy för bärbara och stationära datorer etablerats. Vyn hade utvecklats vidare från att ha separata sidor för evenemang till att istället ha en sida som användaren stannade på hela tiden. När användaren tryckte på ett evenemang expanderade det elementet för att visa ytterligare information om evenemanget.
5.3. Gemensamma erfarenheter
Figur 5.6: Slutgiltig vy
Den slutgiltiga vyn i projektets slutskede.
5.2.3
Slutgiltig vy
Den slutgiltiga vyn slutfördes under den fjärde iterationen av utvecklingen (se figur 5.6). Rent visuellt så hade evenemangsvyn uppdaterats till en mer kompakt variant i syfte att kunna visa fler evenemang samtidigt. Biljettvy-komponenten hade fått en mer elegant design. Utöver det så hade utvecklingen här även tagit ett steg tillbaka mot alfavyn på så sätt att applikationen nu återigen hade separata sidor för evenemang. Detta efter förfrågan från kund då de ville att man skulle i framtiden kunna dela länkar till separata evenemang.
5.3
Gemensamma erfarenheter
Mycket ny kunskap och många nya erfarenheter införskaffades under projektets gång av projektets medlemmar. De mest självklara erfarenheterna var de sakliga inom programme-ringsspråket JavaScript och ramverken som användes i projektet såsom Vue.js, Express.js och Node. De mindre självklara erfarenheterna var de som fångades upp med utvärderingsme-todiken som användes under projektets utveckling.
5.3.1
Resursfördelning
Eftersom antalet medlemmar i gruppen var större än vad de flesta tidigare hade jobbat med innebar det att det blev en viss omställning. Detta innefattade att varje projektmedlem inte kunde vara insatt i hela projektet, projektet delades istället upp i komponenter med ett fåtal gruppmedlemmar per komponent. Det som ofta inträffade för gruppen var att endast en person var insatt i en komponent, till exempel LiU-inloggningen, Klarna eller databas. Detta kunde skapa stor press på enstaka gruppmedlemmar när resten av utvecklingsgruppen var beroende av implementationen av någon viss komponent. Denna individuella kunskap blev också en risk för projektets utveckling då om den ansvarige skulle försvinna under en längre period eller helt enkelt inte skulle implementera komponenten skulle systemet riskera att inte uppfylla kravspecifikationen.
5.3.2
Tekniska krav från kund
Innan gruppen hade haft det första kundmötet hade många ramverk och språk redan disku-terats och etablerats. Flertalet av gruppens medlemmar hade börjat utbilda sig inom de ram-verk och språk som valts. Under det första mötet med kund uppdagades dock att kunden hade mycket specifika tekniska önskemål gällande implementationsdetaljerna för systemet. Detta innefattade även val av ramverk och språk vilket resulterade i att gruppen lagt onödi-ga resurser på utbildning inom ramverk och språk som inte kom att användas. Detta hade kunnat undvikas om gruppen hade haft insikt i att kunden kan ha krav och önskemål på implementationsnivå.
5.3.3
Utveckling och planering
Det visade sig att mer tid behövde ägnas åt dokumentation och planering än vad gruppen initialt hade förväntat. Detta resulterade i att gruppen påbörjade projektet med en minimal planering för att sedan inse att en mer utförlig planering behövdes för att kunna fördela arbetet på ett effektivt sätt. Gruppen fick därmed avbryta utvecklingen och planera vilket försämrade effektiviteten. Detta hade kunnat undvikas om projektets medlemmar haft mer insikt i hur mycket nytta man har av en välplanerad systemarkitektur när man delar upp arbetet. Gruppen anser även att fler möten och avstämningar med handledare hade gynnat både planering och utvecklingsprocess.
5.4
Värde för kund
Kunden lade stor vikt vid att välfungerande och väldokumenterad kod hade högre priori-tet än mycket funktionalipriori-tet. Kunden ville hellre ha ett inkomplett system där det som var implementerat fungerade bra än ett komplett system med buggar utan dokumentation. Kun-den hade nämligen planer på att vidareutveckla systemet efter projektets slut om systemet verkade ha en bra grund. Gruppen har därför lagt stort fokus på att skriva läsbar kod med kompletterande kommentarer för att på så sätt skapa värde för kunden. Gruppen har även tagit hänsyn till kundens begränsade ekonomiska resurser vid val av miljöer och ramverk.
5.5. Testning
5.5
Testning
Systemet testades enbart på systemnivå i form av pilottestning. Under pilottesterna som ut-fördes enligt testplanen, påträffades endast ett mindre tekniskt fel. Detta fel analyserades, åtgärdades och testades senare på nytt. Ett nytt testresultat kunde sedan presenteras med alla testfall godkända. Gruppen är överlag nöjda med testningen då systemets huvudsakli-ga funktioner har implementerats korrekt, även om mer detaljerade enhetstester uteblev till fördel för mer övergripande pilottestning av systemet med fokus på användbarhet.
5.6
Översikt över individuella bidrag
Detta avsnitt ger en översikt av de individuella delar som skrivits av alla gruppens medlem-mar. Till dessa ges korta övergripande beskrivningar. Dessa individuella delar finns tillgäng-liga i slutet av detta dokument.
5.6.1
En jämförelse av användningsområden och analys av framtiden för SQL
jämfört med NoSQL av André Willquist
I denna del jämförs SQL och NoSQL för att undersöka vilka aspekter hos ett projekt som talar för att använda den ena tekniken eller den andra. Efter detta undersöks även hur de två teknologierna kan tänkas utvecklas i framtiden. Denna utredning används även för att avgöra vilken av de två teknologierna som är lämpligast att använda för projektet.
5.6.2
Användning av MVC för en Webbapplikation i ett Team av Ludvig
Westerdahl
Utredning om för- och nackdelar med MVC samt hur MVC passar in i ett utvecklingsteam. Systemet som utvecklades av projektgruppen använde sig utav MVC så en grund för hur MVC kan appliceras i ett projekt gav värde för gruppen. Dessutom behandlas förslag på implementationsdetaljer för att effektivisera testningen. Utredningen visar delvis på att det är viktigt att använda arkitekturen till sin fördel men att man ibland kan behöva skräddarsy implementationen av arkitekturen för att passa det utvecklade systemet.
5.6.3
Digitalisering och social hållbarhet av Samuel Blomqvist
Det digitala biljettsystemet kommer med vissa omställningar jämfört det fysiska. Denna in-dividuella del undersöker hur det potentiellt skulle påverka målgruppen socialt genom att titta på dagens stora sociala applikationer, tvångsbeteende och genom att distribuera ut ett frågeformulär angående dagens kösystem till målanvändarna.
5.6.4
Responsivitet i en webbapplikation av Fredrik Malmfors
Utredning om vilka metoder som kan användas för att skapa en webbapplikation vars inne-håll anpassar sig till olika enheter. Dessutom presenteras vilka för- och nackdelar som erinne-hålls i och med dessa metoder som också redovisas både grafiskt och i text format.
5.6.5
Eventdriven concurrency i JavaScript och Node.js av William Sjöblom
Denna del utreder hur JavaScripts eventdrivna concurrency-paradigm fungerar genom att undersöka dess implementation i JavaScript-motorn V8 och Node.js. Hur detta angreppssätt för att skapa asynkrona applikationer skiljer sig från den mer konventionella metoden att använda en operativsystemstråd för varje asynkron uppgift. Vetskap om den inre processen i JavaScripts concurrency-modell applicerades även av projektgruppen under utvecklingen av biljettsystemet för att bygga ett robust och skalbart system.
5.6.6
Högre abstraktioner med ramverk av Christopher Peters
Denna individuella del undersöker hur ett ramverk ändrar abstraktionsnivån. JavaScript är ett flexibelt men klumpigt språk och vid större system visar det sig inte vara skalbart och även svårt att underhålla. Med tiden har ramverk skapats för att underlätta detta. AngularJS har varit ett utav de mest populära ramverk som bland annat används utav Googles utvecklare. En utav dessa utvecklare, Evan You kände att AngularJS kunde förbättras och skapade senare ramverket Vue.js. Genom att jämföra egenskaperna LOC och LCOM av implementation i dessa ramverk kan komplexitet, flexibilitet, skalbarhet och storlek undersökas.
Denna individuella del motiverades av gruppens förundersökning över vilket ramverk som skulle användas för att utveckla produkten.
5.6.7
Jämförelse mellan websockets och AJAX av Daniel Thorén
Moderna webbsidor laddar inte in nya HTML-sidor varje gång nytt innehåll ska laddas, utan har istället övergått till att dynamiskt ladda innehåll vart eftersom denna behövs. Idag finns primärt två tekniker för att göra detta, nämligen AJAX via HTTP-protokollet och Websockets. Denna individuella del jämför dessa två teknikers för och nackdelar samt drar en slutsats gällande vilken teknik som lämpar sig bäst för detta projekt.
6
Diskussion
Det här området täcker in reflektioner från utvecklingsgruppen angående de arbetsmetoder som användes för att nå resultaten, samt analys av de resultat som insamlats.
6.1
Metod
Sammanfattningsvis anser utvecklingsgruppen att den utsatta metoden inte användes som planerat. Den naturliga arbetsfördelningen uppfattades istället att förbruka mindre resurser. Att undvika avbrott under arbetets gång var fördelaktigt, då det tillät en mer produktiv ar-betsmiljö.
6.1.1
Utbildning
Metodiken som användes för att utbilda gruppmedlemmarna var relevant och fungerade bra. Däremot nischades gruppmedlemmarnas ansvarsområden efter intresse där de fick utbilda sig själva under implementeringsfasen. Detta var fördelaktigt då resurser kunde fördelas på sådant vis att den totala kompetensen i gruppen maximerades. Däremot var det svårt att hålla dialoger vid problemlösning då ibland enbart en person var kunnig inom ett visst ämne. Då gruppmedlemmarna tvingades förlita sig på varandras kompetens ökade även beroendet av deras arbete vilket kunde skapa större avbrott.
6.1.2
Scrum
Eftersom projektet sträckte sig över en relativt lång tidsperiod blev det viktigt att reflektera samt kontrollera det arbete som gjorts med jämna mellanrum. Att arbeta enligt en agil ut-vecklingsmetodik blev därmed det naturliga valet för gruppen. Det tar däremot en märkbar tid att regelbundet utvärdera varje iteration. Det en också svårt att planera tidsåtgången för ett projekt när en agil utvecklingsmetod som Scrum används. Gruppen anser dock att den tid
som lades på att granska kod som redan skrivits gav mycket värde både för gruppens med-lemmar och för projektet som helhet. Flertalet potentiella fel kunde förhindras och individen kunde ta del av feedback och lära sig mer.
Att använda Trello var till en början bra för att konkretisera alla de aktiviteter som formule-rats. Gruppen märkte under arbetets gång att verktyget resulterade i overhead kring admi-nistrationsarbetet. Eftersom gruppen oftast arbetade tillsammans blev det naturligt att sköta den administrativa biten verbalt och med hjälp av Slack.
6.1.3
Utvärdering
Utvärderingen och uppfångandet av erfarenheter har gått bra. Utvecklingsgruppen ansåg att det har fungerat bra att dokumentera erfarenheter och tankar i Slack just för att verktyget varit lättillgängligt för alla gruppmedlemmar. När som helst under projektets gång kunde en gruppmedlem navigera till sin ofta konstant öppnade Slack-flik och kommentera en erfa-renhet i den angivna kanalen. Sprintutvärderingarna tillförde inte lika mycket som gruppen först hade hoppats. Detta berodde förmodligen på dålig planering då de uppgifter som pla-nerades in under en sprint sällan blev klara. Gruppen hade svårt att estimera tidsåtgången för uppgifterna, till stor del på grund av bristande erfarenhet inom gruppen.
6.1.4
Kommunikation
Kommunikationen inom gruppen fungerade bra under projektets gång. Gruppens medlem-mar arbetade större delen av sin tid i samma rum vilket möjliggjorde en väl fungerande ver-bal kommunikation. Detta underlättade mycket då det lätt sker misstolkningar av varandra om man kommunicerar via text.
I övrigt användes verktyget Slack för att kommunicera med text. Detta fungerade väldigt bra då skapandet av diverse kanaler möjliggjorde en bra struktur och uppdelning av diskussioner utifrån samtalsämne. Om ett par gruppmedlemmar behövde hålla en diskussion kunde den antingen hållas via privata meddelanden eller i en separat avsedd kanal.
6.1.5
Testning
Enligt kravspecifikationen kan en godkänd produkt se ut på olika sätt. Det är därför be-tryggande för både kunden och gruppen om produkten fungerar som den ska funktionellt. Testning bidrar till en påvisad kvalité. Med hjälp av testning av mjukvaran kan kraven som ställts på denna uppfyllas. Om testerna är godkända underlättar det även för att systemet ska anses vara godkänt. Det är däremot viktigt att testerna som utförts inte är missvisande eller formulerade på sådant vis som gör dem ej fullständiga. Det är upp till testutvecklarna att detta inte händer. I detta projekts fall utfördes primärt systemtester för att säkerställa en kvalitativ användning för tänkbara användare. Viktig testning av betalning och inloggning utfördes inte då dessa delsystem inte blev implementerade inom tidsramen.
6.1.6
Dokumentskrivning
Utvecklingsgruppen anser att dokumentskrivningen periodvis har fungerat bra. Gruppmed-lemmar behövde ibland avbryta utvecklingen av systemet under implementeringsfasen då
