Utökning av en träningsapplika
tion
Komplettering av funktionalitet till en webbapplikation med fokus på träning
Expansion of a physical exercise logger
Adding Additional functionality of existing system with the focus of exercise
Arvid Gördén Isabelle Rybank
Fakulteten för hälsa, naturoch teknikvetenskap Datavetenskap
Cuppsats 15hp
Handledare: Johan Eklund Examinator: KarlJohan Grinnemo Datum: 20210601
Förord
Tack till våra föräldrar och vänner som har stöttat oss genom detta arbete. Vi vill också ge tack till Liam Rasim och Magnus Norman på CGI för möjligheten att skriva kandidatarbete hos dem och hjälpen vi har fått. Även tack till vår uppsatshandledare Johan Eklund för hjälpen och den konstruktiv kritik vi har blivit givna för att kunna producera en gedigen uppsats.
i
ii FÖRORD
Sammanfattning
Regelbunden motion kan ha många positiva sidoeffekter som bättre hälsa och ökad produktivitet. På CGI i Karlstad utvecklas det en applikation kallad CGIMoving som används för att motivera och förenkla träningen för deras medarbetare. Målet med detta projekt är att utöka funktionaliteten i CGIMoving genom att ge stöd för att användare ska kunna delas in i grupper. Denna uppsats presenterar bakgrunden till projektet, det vill säga vilket arbete som redan har gjorts samt delar och komponenter av projektet som brukas i senare skede vid implementation. Detta för att utöka funktionaliteten i CGIMoving. Sedan presenteras designen för denna utveckling samt hur denna design implementerades. Till sist presenteras och diskuteras resultatet i relation till målen för projektet.
Slutsatsen är att de mål och delmål som sattes uppfylldes till största del och möjlig- heten att dela upp användare i grupper blev implementerad.
iii
iv SAMMANFATTNING
Abstract
Regular exercise can have many positive benefits such as increased productivity and better health. At the CGI-office in Karlstad a web application called CGIMoving is being developed for their co-workers in order to motivate them and make the process of working out simpler. The goal of this project is to expand on the current functionality of CGIMoving by adding support for users to be separated into groups. This thesis introduces background information about the project, namely what work had already been done as well as the parts and components that will be used later in the development of the extended functionality. The design is presented, along with how the design was implemented. Lastly the results of the project are introduced and it is discussed how the extended functionality was designed and implemented. The thesis conclusion is that the goals were met to a greater extent , which now implies that users could be separated into groups.
v
vi ABSTRACT
Innehåll
Förord i
Sammanfattning iii
Abstract v
Figurer xii
1 Introduktion 1
1.1 Uppdragsgivare . . . 2
1.2 Motivering till arbetet . . . 2
1.3 Problembeskrivning . . . 2
1.4 Syfte och mål . . . 3
1.5 Etik och samhälle . . . 4
1.6 Metod . . . 4
1.7 Fördelning av arbete . . . 5
1.8 Avgränsningar . . . 5
1.9 Disposition . . . 5
2 Bakgrund 7 2.1 CGIMoving introduktion . . . 7
2.2 Model-View-Controller . . . 8 vii
viii INNEHÅLL
2.2.1 Model . . . 9
2.2.2 View . . . 9
2.2.2.1 Inloggningssida . . . 10
2.2.2.2 Homepage . . . 11
2.2.2.3 Inställningar . . . 13
2.2.2.4 Administratör . . . 14
2.2.3 Controller . . . 17
2.2.4 Övriga komponenter . . . 18
2.2.4.1 Repository . . . 18
2.2.4.2 Provider . . . 18
2.2.4.3 Service . . . 18
2.2.4.4 Code-First databas med Entity ramverk . . . 18
3 Design 21 3.1 Utökad funktionalitet för administratörer . . . 21
3.2 Utökad funktionalitet för användare . . . 22
3.3 Komplettering av gränssnitt . . . 23
4 Implementation 27 4.1 Utökning av funktionalitet för administratörer . . . 27
4.2 Utökning av funktionalitet för användare . . . 32
4.3 Implementationen av komplettering för gränssnittet . . . 33
5 Utvärdering 35 5.1 Test av utökad funktionalitet . . . 35
5.1.1 Utökad funktionalitet för administratörer . . . 35
5.1.2 Utökad funktionalitet för användare . . . 37
5.1.3 Utökad funktionalitet för gränssnittet . . . 37
INNEHÅLL ix
5.1.4 Slutresultat . . . 38
6 Slutsats 39 6.1 Diskussion . . . 39
6.1.1 Delmål 1 - Beslut kring utökad funktionalitet för administratörer 39 6.1.2 Delmål 2 - Beslut kring utökad funktionalitet för användare . . 40
6.1.3 Delmål 3 - Beslut kring utökat gränssnitt . . . 40
6.1.4 Reflektioner under projektets gång . . . 41
6.2 Slutsats . . . 42
6.3 Framtida arbete . . . 42
Litteraturförteckning 44 Bilagor 49 A Kravspecifikation 51 A.1 Kravspecifikation . . . 51
B Implementationskod 53 B.1 GroupChoice Enitity / Tabell . . . 53
B.2 GetGroupOptions(CampaignID) i CampaignRepository . . . 53
B.3 GroupChoicesModel . . . 54
B.4 GetGroupOptions(CampaignID) i AdminProvider . . . 55
B.5 UpdateGroupNode i AdminController . . . 55
B.6 UpdateCampaignGroupChoice i CampaignRepository . . . 56
B.7 Profile Enitity / Tabell . . . 56
x INNEHÅLL
Figurer
2.1 Relationer inom MVC . . . 8
2.2 Inloggningssida . . . 10
2.3 En del av huvudsidan . . . 11
2.4 Närmare bild av Registeractivity . . . 11
2.5 Närmare bild av Activity trend . . . 12
2.6 Närmare bild av Sidomenyn för administratörer . . . 12
2.7 Underkategorierna för admin . . . 13
2.8 Konto-inställningar . . . 13
2.9 Lista över användarprofiler . . . 14
2.10 Redigering av användares profil . . . 15
2.11 Lista över vilka administratörer som finns för systemet . . . 16
2.12 Hantering av träningskampanjer . . . 16
2.13 Fördefinierade aktiviteter för aktuell träningskampanj . . . 17
3.1 Design för användargränssnittet för att välja grupp . . . 23
3.2 Design för administratörgränssnittet för vyn ”Campaign” . . . 24
3.3 Design för administratörgränssnittet för att ändra användare . . . 25
4.1 Implementation för det uppdaterade administratörgränsnittet under vyn ”Campaign” . . . 29
4.2 Implementation för administratörgränssnittet för ändra användare . . . . 31 xi
xii FIGURER 4.3 Implementation för användargränssnittet för att välja grupp . . . 32
Kapitel 1
Introduktion
Fysisk aktivitet har bevisats att ha positiv effekt på den mentala såväl som den fysiska hälsan[1]. Genom daglig aktivitet minskas risken för ett flertal sjukdomar som stroke eller cancer[2]. Det har även påvisats att vid mental utmattning och trötthet kan fysisk aktivitet ge ett mer energirikt liv[3].
Under de senaste åren har företaget CGI utvecklat en träningsapplikation som kallas CGIMoving för medarbetare i Karlstad. CGIMoving gör det möjligt att registrera trä- ningspass, delta i de träningsevent som CGI erbjuder och delta i tävlingar för att vinna priser.
Ca 80 medarbetare på Karlstadkontoret använder CGIMoving. Det finns även för- hoppningar hos CGI att expandera användningen av CGIMoving till de andra CGI- kontoren i Sverige.
Syftet med arbetet som beskrivs i denna uppsats är att komplettera CGIMoving med ytterligare funktionalitet.
1
2 KAPITEL 1. INTRODUKTION
1.1 Uppdragsgivare
CGI är ett multinationellt IT-konsultföretag med huvudkontor i Montreal och ca 160 an- ställda i Karlstadområdet. De erbjuder ett flertal olika IT tjänster inom diverse branscher som bank, finans och industri [4].
1.2 Motivering till arbetet
Motiveringen till varför uppdragsgivaren vill att detta arbete utförs är för att utöka funktionaliteten inom CGIMoving så den stöder grupptillhörighet. Denna utökade funk- tionalitet innebär att användare kan välja vilken grupp de vill tillhöra och administratö- rerna kan bestämma grupptillhörigheten för en specifik användare. Den utökade funk- tionaliteten ska göra det möjligt för administratörerna att skapa grupper för en specifik träningskampanj. Motiveringen till varför uppdragsgivaren vill ha grupptillhörighet är för att kunna expandera användingen av CGIMoving till de andra övriga CGI-kontoren i Sverige.
1.3 Problembeskrivning
Huvuduppgiften i detta projekt är att komplettera den existerande applikationen CGI- Moving med stöd för grupptillhörighet. Denna komplettering innebär att administratö- rerna för applikationen ska kunna lägga till och ta bort grupper och att användare ska kunna välja vilken grupp de tillhör.
Grupper ska ordnas hierarkiskt genom att ex. en undergrupp till kontoret i Karlstad kan vara avdelningen marknadsföring. Användare ska kunna ange grupptillhörighet.
Administratörerna ska kunna skapa grupper, ändra grupptillhörighet för användare och bestämma vilka grupper som bör kopplas till eventuella träningskampanjer. Denna funk- tionalitet ska även testas under arbetets gång.
1.4. SYFTE OCH MÅL 3 Syftet med arbetet är att göra det enklare för CGI att expandera användandet av CGIMoving till resten av sin kontor i Sverige genom att använda grupper.
1.4 Syfte och mål
Huvudmålet med detta arbete är att designa och implementera stöd för grupptillhörighet i den befintliga applikationen CGIMoving. Arbetet har tillsammans med uppdragsgiva- ren delats in i följande delmål:
1. Utökad funktionalitet för administratörer:
(a) Administratörerna ska kunna ta bort och lägga till grupper.
(b) Administratörerna ska kunna skapa en hierarki som består av grupper och undergrupper.
(c) Administratörerna ska kunna koppla grupper till en specifik träningskam- panj.
(d) Administratörerna ska kunna redigera vilken grupp en användare tillhör.
2. Utökad funktionalitet för användare:
Användare ska kunna ange vilken grupp de tillhör och aktuell grupptillhörighet ska vara synlig för användaren.
3. Utökning av gränssnitt:
(a) Uppdatering av användargränssnittet så att användaren ser de tillgängliga grupperna och kan välja vilken grupp användaren vill tillhöra samt aktuell grupptillhörighet ska vara synlig för användaren.
4 KAPITEL 1. INTRODUKTION (b) Uppdatering av det administrativa gränssnittet så att administratörer ser de tillgängliga grupperna samt funktionalitet för att kunna ta bort, lägga till och ändra grupperna.
(c) Uppdatering av gränssnittet så att administratörerna kan se de tillgängliga grupperna för en specifik användare och kan välja och ändra grupptillhörig- heten för den specifika användaren.
Dessa mål och delmål är baserade på kravspecifikationen från uppdragsgivaren, se bilaga A.1.
1.5 Etik och samhälle
Att dela upp människor i grupper har sina för och nackdelar, för vad händer när någon inte får eller inte kan vara med i gruppen? Det kan vara på grund av ett handikapp eller ett annat tillstånd som förhindrar att man kan delta i vissa aktiviteter, och om alla andra på kontoret utför aktiviteter man ej kan delta i, kan detta leda till att man känner sig utanför[5]. Det har även dokumenterats att under coronapandemin har det blivit allt fler som känner sig ensamma pågrund av distansarbete [6] och mer stillasittande än vanligt, därför kan det vara av vikt att lämna sitt hem och röra på sig samt träffa andra. Om det finns ett sätt att enkelt träffa och träna med sina medarbetare, kan CGIMoving bli en positiv förändring för de som jobbar på distans och känner sig ensamma.
1.6 Metod
Metoden som användes i detta arbete var att ändra och komplettera ett redan existerande projekt. Detta innebar att en mängd nya metoder och filer behövde skapas för att kunna implementera den funktionalitet som önskades. Efter varje implementationssteg testades även den implementerade funktionaliteten. Genom att ha ett stående möte varje vecka
1.7. FÖRDELNING AV ARBETE 5 med uppdragsgivare är det möjligt att ställa frågor om projektet och få feedback under arbetets gång.
1.7 Fördelning av arbete
Under projektets gång har vi båda arbetat ungefär lika mycket och har parprogrammerat under tiden implementationen gjordes. Det fanns olika delar där till exempel den ena studerade till tentamen och den andra programmerade eller att den andra var sjuk och den ena programmerade. Dock har arbetet sammanfattningsvis delats upp rättvist.
I uppsatsen skrevs introduktionen lika fördelat mellan oss båda. Design och slut- sats skrevs av Isabelle Rybank och Arvid Gördén skrev resultat och implementation.
Däremot hjälptes vi åt vid behov under dessa delar.
1.8 Avgränsningar
Projektet kommer endast bestå av de uppgifter som specificeras i kapitel 1.4. I framtiden har CGI planer på att strukturera om hela CGIMoving med ett nytt gränssnitt. Detta medför att det i detta projekt inte kommer läggas någon tid på att förfina det gränssnitt som implementeras under arbetets gång.
1.9 Disposition
Uppsatsen är strukturerad enligt följande. I kapitel 2 presenteras hur produkten CGIMo- ving såg ut innan detta arbete påbörjades samt vad Model-View-Controller är. Kapitel 3 behandlar designen för hur den utökade funktionaliteten ska uppnås. Kapitel 4 förklarar hur implementationen utfördes med hänsyn till designen. Kapitel 5 presenterar resul- tatet av arbetet och diskuterar huruvida målen och delmålen blev uppfyllda. Kapitel 6
6 KAPITEL 1. INTRODUKTION innehåller diskussion, slutsats och uppslag för framtida arbete för fortsatt utveckling av CGIMoving.
Kapitel 2 Bakgrund
Kapitlet ger en överblick för hur CGIMoving såg ut och fungerade vid starten av det- ta uppdrag, och vad systemet använder för ramverk och komponenter. Model-View- Controller(MVC) konceptet presenteras i Kapitel 2.2, där kapitel 2.2.2 innehåller de olika delarna av CGIMoving. I det sista kapitlet 2.2.4 beskrivs Repository, Providers, Services och Entities[7].
2.1 CGIMoving introduktion
CGIMoving är en webbapplikation för att registrera träningsaktiviter och denna applika- tion har en frontend och backend och bygger på MVC-konceptet. CGIMoving använder en databas för att spara och hantera information, där det finns ett flertal tabeller som bland annat representerar användare (profiltabell), aktiviteter (aktivitetstabell) och roller (AspNetRoles), där varje tabell representeras av en entitet.
7
8 KAPITEL 2. BAKGRUND
2.2 Model-View-Controller
CGIMoving är utvecklat i flera etapper, där en del av det tidigare arbetet finns doku- menterat i form av en kandidatuppsats [8].
CGIMoving är skrivet i ASP.NET core[9]. Applikationen är till största del utvecklad utifrån Model-View-Controller konceptet [10]. Huvudsakligen finns det 3 olika viktiga komponenter i ett MVC ramverk, Model [11],View [12] och Controller [13] som syns i figur 2.1.
Förutom dessa tre huvudkomponenter är CGIMoving uppbyggt av följande delar : View-Model, Entities, Providers, Services och Repositories. Dessa delar beskrivs i senare kapitel 2.2.4.
Figur 2.1: Relationer inom MVC
2.2. MODEL-VIEW-CONTROLLER 9
2.2.1 Model
Model [11] [14] hanterar datarelaterad logik och används för att hålla databasen enkel, detta innebär att det är model som utför säkerhetskontroller och andra mer komplexa metoder gentemot databasen (som beskrivs i kapitel 2.2.4.4 ). I CGIMoving finns en modelklass för varje entitetsklass där varje entitetsklass representerar en tabell i data- basen enligt Code-First [7]. Varje model är en klass skriven i C# [15] och innehåller en eller flera metoder.
2.2.2 View
View [14] är det gränssnitt som visas för användaren/administratörerna. Gränssnittet för CGIMoving byggs med hjälp av HTML [16], CSS [17], Javascript [18], HTTP [19] och C# kod. Den använder även Razor [20] vilket gör det möjligt att skriva C# kod i HTML och på så sätt med hjälp av logik och repetition gör HTML dynamiskt. Tillsammans med HTML används även Javascript vilket gör det möjligt att använda de bibliotek som Javascript erbjuder, till exempel jQuery [21] som innehaver pluginet jsTree [22]. Vyerna (views) struktureras utifrån en standard-layout likt ett arv och layout-sidan laddar in vald vy i en så kallad RenderBody.
View-Model är en struktur som länkar ihop model och vyn. Denna struktur gör det möjligt att reducera och specificera vilken data det är som ska visas i vyn. [12].
Det finns två olika huvudvyer i CGIMoving. En avsedd för användaren och en av- sedd för administratörer. Administratörerna har dock tillgång till båda och detta innebär att användare får begränsade rättigheter jämfört med administratörer. Begränsningen för användare innebär att de ej kan se Admin-menyn som syns i figur 2.7 i senare del av kapitlet, utan kan endast navigera mellan de 4 menyalternativen ”Home”, ”Activities”,
”Events” och ”Settings” som visas i figur 2.6 i senare del av kapitlet.
10 KAPITEL 2. BAKGRUND 2.2.2.1 Inloggningssida
Figur 2.2: Inloggningssida
Den första sidan som användaren och administratören möts av i CGIMoving är Login- sidan. Denna syns i figur 2.2. I bilden syns två textfält där en registrerad användare kan skriva in sin mailaddress och sitt lösenord för att logga in men kan också återställa sitt lösenord. En icke registrerad användare har även möjlighet att registrera sig här.
2.2. MODEL-VIEW-CONTROLLER 11 2.2.2.2 Homepage
Figur 2.3: En del av huvudsidan
Efter att en användare eller administratör har loggat in visas huvudsidan. En del av denna huvudsida syns i figur 2.3.
Figur 2.4: Närmare bild av Registeractivity
På huvudsidan finns det möjlighet att registrera aktiviteter, se dagens aktiviteter (workout of the day) och se de 7 senaste dagarnas träning. En mer detaljerad vy över
12 KAPITEL 2. BAKGRUND dessa fält visas i figur 2.4.
Figur 2.5: Närmare bild av Activity trend
På huvudsidan visas dessutom träningstrenden, kallad ”Activity trend” för de näst- kommande 9 månaderna i figur 2.5. Denna trend baseras på dina registrerade aktiviteter under de senaste 7 dagarna som visas i figur 2.4.
Figur 2.6: Närmare bild av Sidomenyn för administratörer
2.2. MODEL-VIEW-CONTROLLER 13
Figur 2.7: Underkategorierna för admin
Längst till vänster på huvudsidan visas en navigeringsmeny för användare respektive administratörer. I figur 2.6 visas hur administratörens navigeringsmeny ser ut och i figur 2.7 visas det vilka alternativ som finns under rubriken Admin. Dessa alternativ förklaras senare i kapitlet. Skillnaden mellan administratörernas och användarnas meny är att valet Admin inte finns för användare.
2.2.2.3 Inställningar
Figur 2.8: Konto-inställningar
Under menyalternativet ”Settings” i huvudmenyn (figur 2.6) är det möjligt att ändra lösenord, e-post, namn, efternamn, telefon och ta bort sitt konto, dessa val illustreras i figur 2.8.
14 KAPITEL 2. BAKGRUND 2.2.2.4 Administratör
Under administratörvalet finns det 4 menyalternativ som syns i figur 2.7
• Användare (”Users”)
• Kampanj (”Campaign”)
• Lotterihjulet (”Fortune Wheel”)
• Events Användare
Under menyalternativet Användare kan administratören:
Se alla användares namn, efternamn, e-post, ”tickets”, ”points” och ”claim” som refererar till utförda aktiviteter( figur 2.9). Vissa av de figurerna som följer har blivit maskerade för att på så sätt bibehålla användarnas integritet då deras riktiga namn används här.
Figur 2.9: Lista över användarprofiler
2.2. MODEL-VIEW-CONTROLLER 15 Genom att trycka på knappen ”EDIT” längst till höger i figur 2.9 skapas ett pop-up fönster (figur 2.10) där administratörerna kan ändra/ta bort en specifik användare.
Figur 2.10: Redigering av användares profil
I pop-up fönstret i figur 2.10 som visas när ”EDIT” angetts kan administratörer ändra en användares namn, e-post, telefonnummer, hur många ”tickets” eller ”points”
användaren har samt priser (Rewards) från nivå 1 till 3. Här är det även möjligt att göra användaren till en administratör, blockera användaren eller ta bort användaren. Knappen
16 KAPITEL 2. BAKGRUND
”save changes” sparar alla förändringar som har gjorts till databasen.
Figur 2.11: Lista över vilka administratörer som finns för systemet
I figur 2.11 visas en lista av alla administratörer och deras namn, efternamn och e-post, till höger i figuren finns en knapp som tar bort administratörrättigheter. Admi- nistratörerna navigerar sig till denna vy genom menyalternativet ”Users” i figur 2.7.
Figur 2.12: Hantering av träningskampanjer
2.2. MODEL-VIEW-CONTROLLER 17 Under rubriken Kampanj i figur 2.7 kan administratören skapa en ny träningskam- panj, uppdatera eller ta bort nuvarande träningskampanj. Denna möjlighet finns under texten ”Manage campaign” som framgår av figur 2.12. Dessutom går det även att redi- gera vilka aktiviteter som tillhör aktuell träningskampanj genom att antingen uppdatera namnet på en aktivitet, ta bort, eller lägga till en ny aktivitet. Detta syns i figur 2.13 som visas i samma fönster som figur 2.12 på sidan ”Campaign”.
Figur 2.13: Fördefinierade aktiviteter för aktuell träningskampanj
2.2.3 Controller
Controller [14] är den del i CGIMoving som hanterar vilken vy som ska ge vilken information. Controllerns roll är att:
• Hantera förfrågningarna från vyn / gränssnittet
• Hämta data från modellen
• Avgöra vilken vy som ska visas
18 KAPITEL 2. BAKGRUND
2.2.4 Övriga komponenter
Det finns olika sätt att implementera MVC, i den befintliga koden för CGImoving fanns förutom standardkomponenterna i MVC ytterligare komponenter som providers, services, repository och entity-framework.
2.2.4.1 Repository
Repository hanterar databasförfrågningar och använder Fluent API [23], som är ett sätt att skriva databasförfrågningar, och SQL-kommandon[24] för att göra databasanrop.
För varje repository finns det även ett repository interface som definierar vilka metoder det finns inom motsvarande repository. Repository medlar mellan Provider och databas samt Service och databas.
2.2.4.2 Provider
Provider hanterar kommunikationen mellan vyn och repository, när vyn ska läsa ifrån databasen använder den sig av providern. Detta är baserat på designprincipen SOLID [25] som innebär att endast en del av koden ska hantera en del av programmet, så kallad single responsibility [25]. Provider ansvarar för läsning ifrån databasen.
2.2.4.3 Service
Service och provider har liknande funktionalitet då båda kommunicerar mellan repo- sitory och vyn. Skillnaden är att när information ska sparas in i databasen anropas en service. Services har ansvaret att skriva till databasen.
2.2.4.4 Code-First databas med Entity ramverk
CGIMoving använder en databas enligt Code-First, som är en Microsoft SQL-databas [26]. Detta innebär att databasen, tabellerna och kolonnerna i databasen definieras direkt
2.2. MODEL-VIEW-CONTROLLER 19 i koden med hjälp av Code First Entity-framework[7].
Entity Framework med en Code-First databas är ett ramverk som består av entite- ter som representerar databastabeller. Genom att använda Code-First tillsammans med Fluent API skapas en databas med hjälp av koden. De models och entities som används måste även innehålla samma egenskaper som databasen.
Entity Framework är en så kallad Object-relational mapper(O/RM)[27] vilket tillåter utvecklaren att jobba med databasen genom .NET objekt. När entiteten och modellen är komplett görs en migration som konverterar .NET objekten till en tabell i databasen [7].
20 KAPITEL 2. BAKGRUND
Kapitel 3 Design
Detta kapitel beskriver den design som skapats för att implementera den utökade funk- tionalitet som uppdragsgivaren önskar för CGIMoving. I kapitlet beskrivs hur designen ser ut samt hur tanken är att användaren och administratörerna ska använda programmet med dess utökade funktionalitet.
3.1 Utökad funktionalitet för administratörer
För att uppnå delmål 1 a) - c) att administratörer ska kunna ta bort/lägga till grupper, samt skapa en hierarki för dessa grupper och bestämma vilka grupper som tillhör en specifik träningskampanj behöver följande kompletteringar göras:
1. Skapa en ny tabell i databasen för att kunna lagra grupper. I denna tabell repre- senterar varje rad en grupp. Varje grupp ska använda ”Campaign” entitet som ett attribut för tabellen vilket innebär att varje rad som representerar en grupp i tabellen kommer ha ett ”campaignID”.
2. Komplettera programmet för att kunna hämta grupper från databasen genom att använda ytterligare en provider. Denna provider ska returnera alla nuvarande
21
22 KAPITEL 3. DESIGN grupper från tabellen med informationen lagrad i databasen om grupper.
3. Skapa en trädstruktur i databasen för att representera hierarkin bland grupperna.
Denna trädstruktur behövs för att varje rad som representerar en grupp i databasta- bellen ska kunna referera tillbaka till sin förälder, det vill säga, till den grupp som ligger ovanför i hierarkin av grupper.
4. Skapa stöd i programmet för att administratörerna ska kunna lägga till och ta bort grupper genom att använda en service som sparar det som har ändrats i databasen och en controller som anropar denna service.
För att ge stöd för att redigera grupptillhörighet för en specifik användare som administratörer delmål 1 d) behöver följande kompletteringar göras:
1. Komplettera den redan befintliga profiltabellen nämnd i kapitel 2.1, som innehåll- er information om användaren, så att denna även lagrar den valda grupptillhörig- heten i en kolumn.
2. Skapa stöd i programmet för att spara en specifik användares grupptillhörighet i databasen via en så kallad service samt en controller som anropar denna service.
3.2 Utökad funktionalitet för användare
För att uppnå delmål 2 att användare ska kunna ange vilken grupp de tillhör och ak- tuell grupptillhörighet ska vara synlig för användaren behöver följande kompletteringar göras:
1. Skapa en kolumn i profiltabellen för att lagra den valda grupptillhörigheten eller använda den tidigare skapade kolumnen vilken beskrivs i delmål 1 d).
3.3. KOMPLETTERING AV GRÄNSSNITT 23 2. Skapa funktionalitet för att hämta information om tillgängliga grupper
3. Skapa stöd för att spara användarens grupptillhörighet i användarens profil i data- basen. Detta stöd bör skapas via en controller som anropar service.
3.3 Komplettering av gränssnitt
Figur 3.1: Design för användargränssnittet för att välja grupp
För att uppnå delmål 3 a), att uppdatera gränssnittet så att användare ser de till- gängliga grupperna, behöver gränssnittet kompletteras i enlighet med figur 3.1. De tillgängliga grupperna bör hanteras under ”Settings” i menyn i figur 2.6 och det är även här uppdateringen av gränssnittet för detta delmål sker.
För att uppnå delmål 3 b), att uppdatera gränssnittet så att administratörerna ser de tillgängliga grupperna samt med funktionalitet för att ta bort/ lägga till / ändra grupper,
24 KAPITEL 3. DESIGN
Figur 3.2: Design för administratörgränssnittet för vyn ”Campaign”
behöver gränssnittet kompletteras i enlighet med figur 3.2. De tillgängliga grupptill- hörigheterna ska presenteras under ”Campaign”-sidan i administratörmenyn (figur 2.7) och ska presenteras nedanför tillgängliga aktiviteter som syns i figur 2.13.
För att uppnå delmål 3 c) att uppdatera gränssnittet så att administratörerna ser de tillgängliga grupperna för en specifik användare och kan välja grupptillhörigheten för den specifika användaren, behöver administratörsgränssnittet kompletteras i enlighet med figur 3.3. Denna funktionalitet bör ligga under menyvalet ”Users” i administra- törmenyn (figur 2.7).
3.3. KOMPLETTERING AV GRÄNSSNITT 25
Figur 3.3: Design för administratörgränssnittet för att ändra användare
26 KAPITEL 3. DESIGN
Kapitel 4
Implementation
Detta kapitel redogör för hur den utökade funktionaliteten, som beskrevs i kapitel 3, implementerades.
4.1 Utökning av funktionalitet för administratörer
För att utöka funktionaliteten för administratörer delmål 1 a) - d) utfördes följande steg.
Skapa ytterligare en tabell i databasen för att hantera grupper:
För att skapa ytterligare en tabell i databasen för att hantera grupper kompletterades programmet med ytterligare en entitetsklass och en model för att, med hjälp av Entity framework, skapa denna tabell utifrån data i de skapade model-och entitetsklasserna.
Entitetsklassen GroupChoice har följande egenskaper:
• GroupChoiceId. Detta ID ger varje rad i tabellen, som representerar en grupp, ett unikt ID för att senare kunna identifiera respektive grupp.
• Company, en sträng som representerar gruppens namn.
• CampaignId, ett ID som kopplar gruppen till en specifik kampanj.
Fullständig implementationskod för tabellen GroupChoice finns i bilaga B.1.
27
28 KAPITEL 4. IMPLEMENTATION Läsa ifrån databasen:
För att kunna läsa från databasen implementerades metoderna :
• GetGroupOptions(CampaignID) i Repositoryklassen som ansvarar för tränings- kampanjerna (CampaignRepository). Denna metod innehåller funktionalitet för att tillsammans med Fluent API hämta grupptillhörigheter från databasen. (Kod för denna metod finns i bilaga B.2).
• GroupChoice To(GroupChoice option) denna metod innehåller logik som kon- verterar en GroupChoicemodel till en GroupChoice entitet. Kod för denna metod finns i bilaga B.3
• GroupChoice From(GroupChoicesModel model) denna metod innehåller logik som konverterar en GroupChoice entitet till en GroupChoicemodel. Kod för den- na metod finns i bilaga B.3
• GetGroupOptions(CampaignID) i Providerklassen som ansvarar för att läsa ifrån databasen som administratör (AdminProvider). Metoden läser från tabellen i da- tabasen och returnerar en lista med alla rader. Koden finns i bilaga B.4.
Skapa hierarki i databasen för grupperna:
För att skapa en hierarki i tabellen med grupper lades egenskapen ParentId till som kolumn i grupptabellen. Denna egenskap kan vara NULL, vilket gör den till en rotnod, alltså en grupp som är högst i hierarkin, eller vara en referens till en annan grupps ID.
Kod för att skapa kolumnen ParentId i databasen finns i bilaga B.1.
Utökning av funktionalitet för att administratörer ska kunna lägga till och ta bort grupper inklusive uppdatering av administratörernas gränssnitt:
Genom att administratörer markerar en eller flera grupper och trycker på den skapade knappen Delete i figur 4.1 kan dessa tas bort från databasen. Att lägga till eller uppdatera
4.1. UTÖKNING AV FUNKTIONALITET FÖR ADMINISTRATÖRER 29 en grupp sker genom att markera en grupp, skriva det nya namnet i textfältet och sedan trycka på Add eller Update, detta visas i figur 4.1. När detta gjorts skickas en HTTP- POST (se kapitel 2.2.2) med information om vad i tabellen som ska uppdateras. Detta hanteras sedan av den Controllerklass som ansvarar för administratöranrop (AdminCon- troller). Kod för denna funktionalitet finns i bilaga B.5.
Uppdateringen realiserades genom att kalla på de skapade metoderna: UpdateCam- paignGroupChoice() i CampaignRepository som används för att spara ner den informa- tionen om den uppdaterade gruppen. Kod för denna metod finns i bilaga B.6.
Figur 4.1: Implementation för det uppdaterade administratörgränsnittet under vyn
”Campaign”
Utökning av funktionalitet för att administratörerna ska kunna redigera vilken grupp en användare tillhör:
30 KAPITEL 4. IMPLEMENTATION För att möjliggöra att administratörer ska kunna ändra eller ta bort gruppval för en specifik användare krävs det att en användare ska kunna ha en referens till vilken grupp den är med i. Detta implementerades genom att lägga till ytterligare en kolumn i profiltabellen. Denna kolumn fick namnet GroupSelected. Kod för detta finns i bilaga B.7.
För att presentera trädstrukturen över aktuella grupper uppdaterades administratörs- gränssnittet under menyalternativet ”Users”, se figur 2.9 där trädet implementerades på pop-up-sidan under knappen ”Edit” se figur 2.10 . Uppdateringen av en användares grupp sker genom att administratörer markerar gruppen och sedan sparar valet. Det uppdaterade gränssnittet för detta visas i figur 4.2. När markeringen sparas skickas det med hjälp av en HTTP-POST-metod till AdminController. Fullständig kod för denna funktionalitet finns i bilaga B.5.
4.1. UTÖKNING AV FUNKTIONALITET FÖR ADMINISTRATÖRER 31
Figur 4.2: Implementation för administratörgränssnittet för ändra användare
32 KAPITEL 4. IMPLEMENTATION
4.2 Utökning av funktionalitet för användare
För att användaren ska kunna välja grupp genereras ett träd , se kapitel 4.3. När använ- daren har valt sin grupp under ”Settings” i figur 4.3 , skickar webbläsaren en HTTP- POST till servern som är värd för CGImoving med information om gruppvalet. Denna information ska sparas till databasen. Detta gruppval uppdateras sedan i profiltabellen (se sektion 2.1) med hjälp av ett SQL-kommando. Figur 4.3 visar det uppdaterade gränssnittet för användare med information om grupptillhörighet. Koden som visar hur detta implementerats finns i Bilaga B.5.
Figur 4.3: Implementation för användargränssnittet för att välja grupp
4.3. IMPLEMENTATIONEN AV KOMPLETTERING FÖR GRÄNSSNITTET 33
4.3 Implementationen av komplettering för gränssnittet
Administratör-och användargränssnitten kompletterades på liknande sätt. Presentatio- nen av grupptillhörigheter gjordes med ett träd som är uppbyggt hierarkiskt. Detta träd representerar databastabellen med grupptillhörigheter. Detta implementerades genom att använda det tidigare nämnda JavaScripts-biblioteket jQuery och dess plugin jsTree (se sektion 2.2.2) . jsTree kan konvertera JSON-formatterad text till ett träd. Genom att iterera över tabellen för grupptillhörighet kan en sträng i JSON-format genereras.
JSON-strängen består av en lista med element som har värdena: Id, text och ParentId, där text är namnet på gruppen. Strängen tolkas sedan som JSON och skickas som data till jsTree-trädet.
34 KAPITEL 4. IMPLEMENTATION
Kapitel 5 Utvärdering
Under projektets gång implementerades den funktionalitet uppdragsgivaren önskade, vilket innebar att designa och implementera stöd för grupper och grupptillhörighet för användare i CGIMoving. I följande sektioner presenteras de tester som gjordes på den nya funktionaliteten samt resultatet av det uppdaterade gränssnittet.
5.1 Test av utökad funktionalitet
Arbetet innebar att controllers, models, databasen och gränssnittet utökades med nya metoder och funktioner. I kravspecifikationen fanns det inga kriterier angående vilka tester som skulle göras för att arbete skulle anses som klart. Det föreslogs av uppdrags- givaren att bygga och använda automatiserade tester istället för att testa manuellt. På grund av tidsbrist skapades inga automatiserade tester, istället gjordes följande tester manuellt (Analys av resultaten finns i sektion 6.1).
5.1.1 Utökad funktionalitet för administratörer
Delmål 1 a) - b) ”Administratörerna ska kunna ta bort och lägga till grupper” och
”Administratörerna ska kunna skapa en hierarki som består av grupper och undergrup- 35
36 KAPITEL 5. UTVÄRDERING per”. Dessa tester skedde via det uppdaterade gränssnittet i figur 4.1. Nedanstående funktionalitet testades. Den funktionalitet som är implementerad och fungerar enligt specifikationen har markerats med , medan övrig önskad funktionalitet har markerats
med .
• Ta bort en grupp
• Ta bort flera grupper samtidigt
• Lägga till en grupp
• Lägga till flera grupper samtidigt
• Lägga till en grupp som undergrupp till en annan grupp
• Ändra en grupp
• Ändra flera grupper samtidigt
Delmål 1 c) ”Administratörerna ska kunna koppla grupper till en specifik tränings- kampanj”. Inga tester gjordes specifikt på denna del. Anledningen till detta var att det endast fanns en träningskampanj att testa i systemet. Analys av resultaten finns i sektion 6.1.
Delmål 1 d) ”Administratörerna ska kunna redigera vilken grupp en användare till- hör”. Dessa tester skedde via det uppdaterade gränssnittet i figur 4.2
• Välja en grupp åt en specifik användare
• Välja flera grupper åt en specifik användare
• Välja ingen grupp åt en specifik användare
• Välja en undergrupp åt en specifik användare
5.1. TEST AV UTÖKAD FUNKTIONALITET 37
5.1.2 Utökad funktionalitet för användare
Delmål 2 ”Användare ska kunna ange vilken grupp de tillhör och aktuell grupptillhö- righet ska vara synlig för användaren.” Dessa tester skedde via det utökade gränssnittet i figur 4.3
• Välja en grupp som användare
• Välja flera grupper som användare
• Välja ingen grupp som användare
• Välja en undergrupp som användare
5.1.3 Utökad funktionalitet för gränssnittet
Den utökade funktionaliteten i gränssnittet visas nedan i anslutning till respektive del- mål:
• Delmål 2 och 3 a) ”Användare ska kunna ange vilken grupp de tillhör och aktuell grupptillhörighet ska vara synlig för användaren” och ”Uppdatering av användar- gränssnittet så att användaren ser de tillgängliga grupperna och kan välja vilken grupp användaren vill tillhöra samt aktuell grupptillhörighet ska vara synlig för användaren ”. Det uppdaterade gränssnittet syns i figur 4.3.
• Delmål 3 b) ”Uppdatering av det administrativa gränssnittet så att administratörer ser de tillgängliga grupperna samt funktionalitet för att ta bort/ lägga till / ändra grupperna”. Det uppdaterade gränssnittet syns i figur 4.1.
• Delmål 1 d) och 3 c) ”Administratörerna ska kunna redigera vilken grupp en användare tillhör” och ” Uppdatering av gränssnittet så att administratörerna kan
38 KAPITEL 5. UTVÄRDERING se de tillgängliga grupperna för en specifik användare och kan välja grupptillhö- righeten för den specifika användaren”. Det uppdaterade gränssnittet syns i figur 4.2.
5.1.4 Slutresultat
Utfallet från testerna av den utökade versionen av CGIMoving visade att den nya funk- tionaliteten baserat på målen presenterade i kapitel 1.4 fungerade i de flesta fall. Även om alla tester inte avklarades presterade funktionaliteten generellt som önskat enligt målen och delmålen för projektet.
Kapitel 6 Slutsats
6.1 Diskussion
Under arbetet att utöka funktionaliteten för CGIMoving fick vi fria händer att fatta design- och implementationsbeslut, i detta kapitel kommer vi diskutera dessa beslut och hur detta påverkade slutresultatet.
6.1.1 Delmål 1 - Beslut kring utökad funktionalitet för administra- törer
• Delmål 1 a) Administratörerna ska kunna ta bort och lägga till grupper:
Under utvecklingen mot detta delmål bestämde vi att administratörerna endast skulle kunna lägga till en grupp åt gången men att det skulle vara möjligt att ta bort flera grupper samtidigt. Annledningen till att detta beslut togs var på grund av tidsbrist.
• Delmål 1 b) Administratörerna ska kunna skapa en hierarki som består av grupper och undergrupper:
Vi bestämde oss för att använda en ParentId kolumn i GroupChoicetabellen (se 39
40 KAPITEL 6. SLUTSATS sektion 4.1) för att skapa en hierarki, detta fungerade bra och samverkade väl med jsTree-pluginet som användes senare.
• Delmål 1 c) Administratörerna ska kunna bestämma vilka grupper som tillhör en specifik träningskampanj:
I den nuvarande versionen av CGIMoving kan bara en träningskampanj åt gången vara aktiv. Vi bestämde oss därför för att endast skapa funktionalitet för att grup- perna som skapas sparas till den träningskampanj som är aktiv. Denna lösning fungerar för tillfället men skulle CGI bestämma sig för att ha flera kampanjer aktiva samtidigt behöver denna funktionalitet således också ändras.
6.1.2 Delmål 2 - Beslut kring utökad funktionalitet för användare
Användaren kan i den utvecklade versionen av CGIMoving endast välja en grupp att tillhöra, på detta sätt behövdes ingen lista av grupper sparas i profiltabellen. Uppdrags- givaren ansåg dock att detta var en begränsning då de i framtiden skulle vilja införa flera aktiva kampanjer parallellt och då även kunna ha användare kopplade till fler än en grupp.
6.1.3 Delmål 3 - Beslut kring utökat gränssnitt
För delmål 3 a) och 3 c) som rör gränssnittet för administratörer och användare som beskrivs i senare del av denna sektion, identifierades en svaghet med den GroupSelec- ted kolumn som skapades i profiltabellen. Om användaren inte markerade en grupp i hierarkin och försökte spara, kastades ett null-exception fel. Detta hanterades genom att hårdkoda rotnoden ”CGI” som grupptillhörighet för användaren om inget val gjordes.
Denna lösning bör vid nästa uppdatering hanteras genom att meddela användaren eller
6.1. DISKUSSION 41 administratören om att ingen grupp har valts med hjälp av den null-exception som kastas.
• Delmål 3 a) Uppdatering av användargränssnittet så att användaren ser de till- gängliga grupperna och kan välja vilken grupp användaren vill tillhöra:
Under utvecklingen mot detta delmål försökte vi först skapa en egen struktur för att presentera grupperna och deras ordning i hierarkier, men det visade sig att det var smidigast att använda jsTree.
• Delmål 3 b) Uppdatering av det administrativa gränssnittet så att administratörer ser de tillgängliga grupperna samt för att ta bort/ lägga till och att ändra grupperna:
Under utvecklingen mot detta delmål togs ett implementationsbeslut att beskriva hur administratörerna skulle gå tillväga för att lägga till eller uppdatera en grupp under texten ”How to change the tree” eftersom detta inte kändes intuitivt.
• Delmål 3 c) Uppdatering av gränssnittet så att administratörerna kan se de till- gängliga grupperna för en specifik användare och kan välja grupptillhörigheten för den specifika användaren:
Under utvecklingen hittades en svaghet i det tidigare implementerade gränssnittet vilket innebar att det inte gick att scrolla i det pop-up fönstret som skapades i figur 4.2. Detta ledde till att det inte var möjligt för administratörerna att klicka på
”Save Changes” när en ändring hade skett. Det fanns ingen tid att ordna detta och lösningen är för närvarande att administratörerna får ut zooma ut i webbläsaren.
6.1.4 Reflektioner under projektets gång
Uppgiften i detta projekt, att ändra och komplettera funktionalitet i ett redan existerande projekt innebar utmaningar, att sätta sig in i och förstå andra människors kod och att göra detta på distans var några av dessa utmaningar. Eftersom vi inte kunde utföra arbetet på plats i CGIs kontor på grund av coronapandemin blev det svårare att få hjälp vilket
42 KAPITEL 6. SLUTSATS ledde till att vi kunde fastna under längre tid med småproblem som egentligen hade lätta lösningar. Dock var detta ett ypperligt tillfälle att mogna som utvecklare.
Om vi hade kunnat sitta på plats hade det kanske blivit lättare och vi kunde fått mer tid att lösa de små problem som har specificerats i tidigare delar i detta kapitel. Detta gav oss dock en chans att bli bättre problemlösare.
6.2 Slutsats
Slutsatsen är att de huvudmål och delmål som är specificerade i kapitel 1.4 till stor del är uppfyllda.
Efter att implementationen var klar stämde vi av med uppdragsgivaren för att säker- ställa att slutprodukten nådde upp till uppdragsgivaren förväntningar. I samband med detta höll vi i en demonstration för dem över ett digitalt möte. Resultatet av detta var att de var nöjda, men hade även synpunkter på vissa områden som presenteras i kapitel 6.3.
6.3 Framtida arbete
För att fortsätta detta arbete rekommenderas följande åtgärder:
• Göra det möjligt att scrolla i pop-up fönstret som kommer upp då administratö- ren ser de tillgängliga grupperna för en specifik användare, se figur 4.2. Denna möjlighet underlättar användningen av CGIMoving för administratörer.
• Skapa funktionalitet för att administratörer ska kunna lägga till fler än en grupp åt gången. Detta skulle innebära att det blir enklare att lägga till fler antal grupper.
• Skapa funktionalitet för att redigera mer än en grupp åt gången.
• Den aktuella versionen av CGIMoving har begränsningen att en användare endast kan tillhöra en grupp. Genom att skapa funktionalitet så att användare kan tillhöra
6.3. FRAMTIDA ARBETE 43 fler än en grupp blir det enklare att skapa mer omfattande träningskampanjer med fler medlemmar.
44 KAPITEL 6. SLUTSATS
Litteraturförteckning
[1] A Ståhle. FYSS 2017 - a tool for healthcare professionals when prescribing physical activity: Agneta Ståhle. European Journal of Public Health, 27(suppl_3), 10 2017. ckx187.055.
[2] Mohammed Abou Elmagd. Benefits, need and importance of daily exercise. Int.
J. Phys. Educ. Sports Health, 3(5):22–27, 2016.
[3] Timothy Puetz. Physical activity and feelings of energy and fatigue. Sports medicine (Auckland, N.Z.), 36:767–80, 02 2006.
[4] CGI karlstad description. https://www.cgi.com/se/sv/karriar/
cgi-karlstad. Accessed: 2021-03-29.
[5] Anneli Johansson. En studie om aktÖrer med funktionshinders situation i det svenska sociala landskapet, 2005.
[6] F. Bu, A. Steptoe, and D. Fancourt. Who is lonely in lockdown? cross-cohort analyses of predictors of loneliness before and during the covid-19 pandemic.
Public Health, 186:31–34, 2020.
[7] MS Doc codefirst description. https://docs.
microsoft.com/en-us/aspnet/mvc/overview/
getting-started/getting-started-with-ef-using-mvc/
45
46 LITTERATURFÖRTECKNING
creating-an-entity-framework-data-model-for-an-asp-net-mvc-application. Accessed: 2021-03-08.
[8] Arturs Locmelis and Mathias Thoren. Improvement of a physical exercise logger, 2020. Digitalt presentation via Zoom.
[9] Carl-Hugo Marcotte and Abdelhamid Zebdi. An atypical asp . net core 5 design patterns guide, 2020.
[10] MS Doc mvc asp.net description. https://docs.microsoft.com/en-us/
aspnet/core/mvc/overview?view=aspnetcore-5.0. Accessed: 2021-03- 08.
[11] MS Doc model description. https://docs.microsoft.com/en-us/
aspnet/core/tutorials/first-mvc-app/adding-model?view=
aspnetcore-5.0&tabs=visual-studio. Accessed: 2021-03-08.
[12] MS Doc view description. https://docs.microsoft.com/en-us/aspnet/
core/tutorials/first-mvc-app/adding-view?view=aspnetcore-5.
0&tabs=visual-studio. Accessed: 2021-03-08.
[13] MS Doc controller description. https://docs.microsoft.com/en-us/
aspnet/core/tutorials/first-mvc-app/adding-controller?view=
aspnetcore-5.0&tabs=visual-studio. Accessed: 2021-03-04.
[14] Mugilan T. S. Ragupathi. Learning ASP.NET Core MVC Programming. Packt Publishing, 2016.
[15] Skansholm Jan. Skarp programmering med C sharp. Studentlitteratur, 2008.
[16] MS Doc html description. https://docs.microsoft.com/en-us/cpp/
mfc/html-basics?view=msvc-160. Accessed: 2021-04-19.
LITTERATURFÖRTECKNING 47 [17] Css. https://developer.mozilla.org/en-US/docs/Web/CSS. Accessed:
2021-04-19.
[18] Duckett Jon. JavaScript and JQuery: Interactive Front-End Web Development.
John Wiley and Sons Inc, 2014.
[19] Http description. https://developer.mozilla.org/en-US/docs/Web/
HTTP. Accessed: 2021-05-12.
[20] MS Doc razor description. https://docs.microsoft.com/en-us/aspnet/
core/mvc/views/razor?view=aspnetcore-5.0. Accessed: 2021-04-19.
[21] jquery description. https://jquery.com/. Accessed: 2021-05-10.
[22] jstree description. https://www.jstree.com/. Accessed: 2021-05-11.
[23] CodeProject fluent api description. https:
//www.codeproject.com/Articles/1022331/
Add-Fluent-API-Flavour-To-Your-Repositories. Accessed: 2021- 03-11.
[24] Sqlcomand description. https://docs.microsoft.com/en-us/dotnet/
api/system.data.sqlclient.sqlcommand?view=dotnet-plat-ext-5.
0. Accessed: 2021-05-12.
[25] MS Doc soild. https://docs.microsoft.
com/en-us/archive/msdn-magazine/2014/may/
csharp-best-practices-dangers-of-violating-solid-principles-in-csharp. Accessed: 2021-04-12.
[26] Mssqldatabase description. https://docs.microsoft.com/en-us/sql/
sql-server/?view=sql-server-ver15. Accessed: 2021-05-12.
48 LITTERATURFÖRTECKNING [27] Patrick Linskey and Marc Prudhommeaux. An in-depth look at the architecture of
an object / relational mapper. 2007.
Bilagor
49
Bilaga A
Kravspecifikation
A.1 Kravspecifikation
Den kravspecifikation som gavs från CGI var följande :
• En anställd och/eller Admin skall kunna välja organisation/grupp tillhörighet i ett träd som t ex Defence, GTO, Data advantage.
• Organistaionsschema ska administreras och skapas vid skapande av en kampanj.
• En vanlig användare skall under sin profil kunna välja vilken organisationsgrup- pering denne tillhör. Valet skall kunna göras i en trädstuktur där underliggande grupper expanderas och man endast behöver välja en organisations gruppering.
• En administratör skall genom att editera en användare kunna sätta organisations- tillhörigheten.
• En administratör skall kunna under admin sidan skapa upp organisationstrukturen som skall gälla för denna organisation och motionskampanj.
51
52 BILAGA A. KRAVSPECIFIKATION
Bilaga B
Implementationskod
B.1 GroupChoice Enitity / Tabell
namespace CGIMoving.Entities {
public class GroupChoice {
//Unikt Id för varje kolumn
public int GroupChoiceId { get; set; }
//Namnet på företaget
public string Company { get; set; }
//Unikt Id så att varje grupp tillhör en kampanj public Guid CampaignId { get; set; }
//Kopplar varje grupp till en annan rad public int? ParentId { get; set; } }
}
B.2 GetGroupOptions(CampaignID) i CampaignRepo- sitory
namespace CGIMoving.Repository {
public class CampaignRepository : ICampaignRepository {
53
54 BILAGA B. IMPLEMENTATIONSKOD
public List<GroupChoice> GetGroupOptions(Guid campaignId) {
var options = _dbContext.GroupChoices.Where(x => x.
CampaignId == campaignId).ToList();
return options;
//Lista som hämtas ifrån databasen och innehåller alla rader i GroupChoices tabellen
} } }
B.3 GroupChoicesModel
namespace CGIMoving.Models {
public class GroupChoicesModel {
//Samma kolumner som i GroupChoice finns även här //...
public GroupChoicesModel To(GroupChoice option) //Omvandlar en Model till en Entitet
{
if (option == null) return null;
Company = option.Company;
CampaignId = option.CampaignId;
ParentId = option.ParentId;
return this;
}
public GroupChoice From(GroupChoicesModel model) //Omvandlar en Entitet till en Model
{
if (model == null) return null;
var option = new GroupChoice {
GroupChoiceId = model.GroupChoiceId, Company = model.Company,
CampaignId = model.CampaignId, ParentId = option.ParentId, };
return option;
}
B.4. GETGROUPOPTIONS(CAMPAIGNID) I ADMINPROVIDER 55
} }
B.4 GetGroupOptions(CampaignID) i AdminProvider
namespace CGIMoving.Providers {
public class AdminProvider : IAdminProvider {
public List<GroupChoice> GetGroupOptions(Guid campaignId) { //Hämtar ut en lista med alla rader ifån GroupChoice
tabellen använder CampaignRepository var options = _unitOfWork.CampaignRepository.
GetGroupOptions(campaignId).ToList();
return options;
} } }
B.5 UpdateGroupNode i AdminController
namespace CGIMoving.Controllers {
[Authorize(Roles = "Admin")]
public class AdminController : Controller {
[HttpPost]
public IActionResult UpdateGroupNode([FromBody]
GroupChoicesModel groupChoicesModel) {
var result = _adminService.UpdateGroupNode(
groupChoicesModel); //Använder AdminService för att spara det nya namnet på en nod i GroupChoice
tabellen.
return new JsonResult(result);
}
//...
[HttpPost]
56 BILAGA B. IMPLEMENTATIONSKOD
public async <IActionResult> SaveUserChanges([FromBody]
UserModel userModel) {
var groupResult = _profileService.UpdateUserGroup(user , userModel.GroupChoiceId);
//Använder ProfileService för att spara förändringar i profilen tabellen
return new JsonResult(userResult.Succeeded &&
pointsResult && ticketsResult && outfitResult &&
groupResult);
} }
B.6 UpdateCampaignGroupChoice i CampaignReposi- tory
namespace CGIMoving.Repository {
public class CampaignRepository : ICampaignRepository {
public bool UpdateCampaignGroupChoice(GroupChoice group) {
var x = _dbContext.GroupChoices.Update(group);
//Använder Update för att uppdatera databasen och returnera true eller false
return x;
} } }
B.7 Profile Enitity / Tabell
namespace CGIMoving.Entities {
public class Profile {
public Guid ProfileId { get; set; } //....
public virtual GroupChoice GroupSelected { get; set; }
B.7. PROFILE ENITITY / TABELL 57
} }
