Forum / Nettverkssamfunn Team 2

Software Requirements & Design Document Forum / Nettverkssamfunn Team 2 1

Innholdsfortegnelse 1 Introduksjon... 4 1.1 Hva består dokumentet av?... 4 1.2 Maskinvarekonfigurasjon... 4 2 Nomenklaturliste... 6 3 Design... 8 3.1 Oversikt... 8 3.2 Skisser... 8 4 Kravspesifikasjoner... 12 4.1 Ikke-funksjonelle krav... 12 4.1.1 Kostnadsestimering... 12 4.1.2 Data og sikkerhet... 12 4.2 Funksjonelle krav for brukere... 12 4.2.1 Krav 1 - Logg inn... 12 4.2.2 Krav 2 - Registrering... 13 4.2.3 Krav 3 - Kategorier... 13 4.2.4 Krav 4 - Subkategorier... 13 4.2.5 Krav 5 - Emner... 13 4.2.6 Krav 6 - Kommentarer... 14 4.2.7 Krav 7 - Profil... 14 4.2.8 Krav 8 - Redigering av profil... 14 4.2.9 Krav 9 - Søkefunksjon... 14 4.2.10 Krav 10 - Medlemsliste... 14 4.2.11 Krav 11 Nye emner... 14 4.2.12 Krav 12 Trender... 15 4.3 Funksjonelle krav for administratorer... 15 4.3.1 Krav 1 - Redigering av brukere... 15 4.3.2 Krav 2 Redigering av kategorier og subkategorier... 15 4.3.3 Krav 3 - Sletting av tråder/emner og kommentarer... 15 5 Systemarkitektur... 16 6 Systemmodeller... 17 6.1 E/R Diagram av databasestruktur... 17 6.2 UML - Use Case Diagram... 19 6.3 UML Sekvensdiagrammer... 20 6.3.1 Registrering... 20 2

6.3.2 Logg inn... 21 6.3.3 Lag kommentar... 21 6.3.4 Opprett emne... 22 6.4 UML Klassediagram... 22 7 Systemets evolusjon... 24 7.1 Fundamentet... 24 7.2 Antatte endringer... 24 7.2.1 Brukerendringer... 24 7.2.2 Kommentarer i tråder/emner... 24 8 Referanser... Feil! Bokmerke er ikke definert. 3

1 Introduksjon I dette kapittelet introduseres kravene til prosjektet og kort om hvordan systemet skal fungere. 1.1 Hva består dokumentet av? Målet med dette dokumentet er å spesifisere krav til programvaren som skal bli lagd, både funksjonelle og ikke-funksjonelle krav. Funksjonelle krav vil f.eks. være krav som beskriver funksjonaliteten til de forskjellige funksjonene, mens de ikke-funksjonelle kravene vil være krav som hvordan data behandles og operasjonskostnader [1]. Dette dokumentet er primært lagd for kunden, som vil måtte foreslå og godkjenne de forskjellige funksjonalitetene i programvaren, men også for utviklerne som trenger en forståelse for hvordan systemet henger sammen i form av en maskinvarekonfigurasjon. I dokumentet vil det bli referert til en ordliste, hvor man kan slå opp terminologien som er tatt i bruk. 1.2 Maskinvarekonfigurasjon Kommunikasjon mellom maskinvaren vil være det viktigste ved skapelsen av et forum. I dette prosjektet vil Azure DevOps tas i bruk for hosting av database og webserver slik at informasjonen når websiden og blir plukket opp av klienten. Dette fungerer med et forhold mellom database og webserver som henter ut og skriver inn ny informasjon, videre vil webserveren sende ut informasjonen til internett som dermed klienten kan plukke opp. Problemer som kan oppstå er f.eks. om ikke databasen og webserveren kommuniserer vil det ikke være mulig å hente ut eller implementere ny informasjon i databasen, dette vil da føre til at websiden som serveren verter ikke vil vises og dermed vil heller ikke klienten ha noen tilgang til websiden. Figur 1-2 viser funksjonalitet og virkemåte mellom maskinvaren som blir brukt i skapelsen av et forum. 4

Figur 1-2: Bildet viser maskinvarekonfigurasjon. 5

2 Nomenklaturliste Tabell 1-1 nedenfor beskriver betydningen av begreper tatt i bruk utover i dokumentet. Tabell 1-1: Nomenklaturliste Begrep Administrator Azure DevOps Bruker Cloud Database Forum Funksjonelle Krav GUI Hosting Ikke-Funksjonelle Krav Klient Moderator Responstid Tråder/Emner View Hva er det? En bruker som overvåker forumet, har muligheten til å sette brukere til moderator status. En tjeneste fra Microsoft for lettere lagring av data på Cloud. Spesifisert for bruk innenfor dataprogrammering. En bruker er en opprettet profil på forumet. En Cloud er en virtuell lagringsplass for data på internett. En Database er et lagringsmedia for informasjon. En kommunikasjonsplattform for ulike interesser og meninger, også kalt et nettsamfunn. En spesifisering av hva systemet burde gjøre En grafisk representasjon av et kodet system, brukt for navigasjon i systemet/programmet. Forkortning for Graphical User Interface. En server lagrer data fra Database og Webserver og gjør det mulig at en klient får tilgang til websiden lagret serveren. Dermed hoster serveren websiden. En beskrivelse av hvordan systemet virker En klient er utstyr som kan få tilgang til tjenester muliggjort av en server. Eksempel på dette er en Computer. En bruker som kan moderer forumet. Eksempel på dette er ved muligheten til å slette tråder opprettet av brukere. En måling av tid det tar for systemet å reagere/respondere. En tråd/emne er opprettelsen av et brukerspesifikt emne i forumet. Som regel er dette i form av et spørsmål man søker svar på. En opprettelse av virtuelle tabeller i en database, basert på en spørring etter informasjon i databasen. 6

Webserver En webserver lagrer, prosesserer og leverer en webside til klienter. 7

3 Design I dette kapittelet vil det ses på skisser av websiden, med noe forklaring av funksjonalitet og forumets virkemåte. 3.1 Oversikt Flytskjema i Figur 3-1 under forklarer virkemåten til forumet. Når man kobler seg til nettsiden vil man få muligheten til å logge seg inn, ut ifra dette kan man lage ny bruker om man ikke har det allerede. Det er også mulighet for å surfe nettsiden uten bruker og navigere Kategorier og subkategorier for mulighet til å lese tråder/emner og kommentarene som er lagt inn. Det er derimot ikke mulighet for oppretting av emner og kommentarer om ikke man har registrert seg som bruker på nettsiden. 3.2 GUI skisser Figur 3-1: Overordnet flytskjema av forumets virkemåte Figurene (3.2-3.6) viser enkle utkast av hvordan det ferdige forumet kan sees ut. Figur 3-2 viser hvordan nettsidens hjemmeside vil være, på PC. Øverst på nettsiden ser man en 8

toppordnet navigeringsbar, denne vil sitte fast på toppen av siden og skaleres automatisk uansett om man blar eller skalerer ned/opp sidestørrelsen (Auto-scaling). Navigeringsbaren skal inneholde enkle, primære funksjoner for brukeren, som ekspemelvis logg inn, registrer bruker. Under navigeringsbaren finner man først en oversikt over aktuelle kategorier, utseendemessig vil dette avvikle fra figuren, men prinsipielt er baktanken at det skal være oversiktlig og enkelt å navigere seg til ønsket kategori. Under kategoriene finner man populære og nye tråder, slik at brukerne enkelt kan se hvilke tråder som er aktive. Figur 3-2: Utkast av GUI, hjemmeside, til bruk i forumets dannelse. Figur 3-3 er et eksempel på hvordan nettsiden for en kategori kan se ut. Man finner den samme navigeringsbaren her som på forumets hjemmeside. Her skal det være enkelt å se hvilke tråder som er aktive innen kategorien, hvor det listes ned nye og populære tråder, med mulighet til å fremme tråder man finner passende ved å gi posten en tommel opp/ned. Til høyre i figuren finner man regler og generell informasjon innenfor subkategorien. 9

Figur 3-3: Utkast av GUI, subkategori med tråder. Figur 3-4 til 3-6 viser enkelt utkast av hvordan forumet vil vises på mobilplattform. Figur 3-4, på lik linje som på PC, har man den samme toppordnede navigeringsbaren, med klikkbar Dropdown-meny for å finne funksjonene, ellers viser navigeringsbaren sidetittel på nåværende side. Under navigeringen finner man en enkel oversikt over kategoriene. Figur 3-5 viser nettsiden for ønsket kategori, med liste over aktive tråder. Figur 3-6 viser informasjon og regler innenfor kategorien og er ment å kunne sveipes inn fra høyre til venstre når man er inne på kategorien (figur 3-5). 10

Figur 3-4: Sidetittel og Logo Figur 3-5: Forumnavn Figur 3-6: Utkast av GUI for mobil 11

4 Kravspesifikasjoner I dette kapittelet vil de funksjonelle kravene og ikke-funksjonelle kravene være listet. Det vil skilles mellom funksjonelle krav for bruker og administrator. En administrator vil kunne gjøre det alle brukere gjør samt litt til, men en bruker vil ikke kunne gjøre det en administrator gjør. 4.1 Ikke-funksjonelle krav Det vil her ses litt på kostnadsestimering, hvem som har tilgang til hva slags data og hvordan data vil bli håndtert. 4.1.1Kostnadsestimering Tidsrammen til prosjektet er 18 uker, og det skal jobbes i 15 timer i uken. Det er tre medlemmer i teamet, og med en timelønn på 200kr i timen så vil kostnaden bli på 54 000kr på hvert teammedlem, og totalkostnad når prosjektet er ferdig vil bli på 162 000kr. Siden hvert teammedlem har nødvendig software, så vil det ikke bli noen softwarekostnader, ei heller hardwarekostnader. Kunden vil måtte betale for webhosting og domene selv etter endt prosjekt. 4.1.2Data og sikkerhet Personvernopplysninger vil behandles iht. personvernforordningen. Brukere vil måtte samtykke at vi prosesser data de etterlater seg for å få tilgang til forumet og de vil også ha tilgang til å se hva slags data som blir samlet inn om dem. Det vil ikke samles inn unødvendig mye informasjon om brukeren [2]. All data prosessert vil være på grunnlag av samtykke fra brukeren, hvor bruker får vite om hvilke vilkår for bruk programmet vil ha og aksepterer om vilkårene er tilfredsstillende. Om datalagringen er utsatt for et databrudd vil alle personer utsatt bli notifisert innen 72 timer etter data innbruddet. Det vil av den grunn bli implementert mekanismer for beskyttelse av brukerens data slik at den personlige dataen ikke ligger åpent. Dette for å beskytte brukerens personvern. En bruker kan også bestemme og slette brukeren sin, og da vil all informasjon om denne brukeren bli slettet fra systemet. Systemet vil måtte beskyttes mot ulike angrep som f.eks. SQL injection. 4.2 Funksjonelle krav for brukere Her vil de funksjonelle kravene for brukere bli listet opp. 4.2.1 Krav 1 - Logg inn Et medlem av forumet skal kunne logge inn på forumet med et brukernavn og et passord. Logg inn knapp finnes i header for å være lett tilgjengelig. 12

Avhengig av: Krav 2, krever at man har allerede opprettet en bruker via registrering. Test: Kan testes når krav 2 fungerer. 4.2.2 Krav 2 - Registrering For å bli et medlem av forumet er man avhengig av å registrere seg, for å registrere seg må man skrive inn brukernavn, passord, email og hva man studerer. Man må måtte skrive inn både passord og email to ganger for å se om de stemmer overens, slik at brukeren ikke skriver feil email og/eller passord. Den som registrerer seg på forumet vil motta en verifiseringsemail med en kode som man skriver inn første gang man logger inn. Avhengig av: Ingenting. Test: Kan testes så fort en registreringsside er laget og en registrer knapp eksisterer. 4.2.3 Krav 3 - Kategorier Man skal kunne se kategoriene på forsiden av websiden. Man skal kunne trykke på kategorinavnet og bli ført inn på subkategoriene til den spesifikke kategorien man trykker på. Hver kategori skal også ha et assosiativt bilde som ikke kan være større enn en viss størrelse. Avhengig av: Avhenger av kommunikasjon med database og opprettede kategori elementer på nettside. Test: Kan testes når database kommuniserer med kategori elementer på nettside. 4.2.4 Krav 4 - Subkategorier På samme måte som i krav 3 ovenfor så vil man kunne trykke på en subkategori, som fører til at man åpner alle emnene til den spesifikke subkategorien. Avhengig av: Krav 3, da man må kunne klikke på en kategori for å se subkategoriene til denne kategorien. Test: Kan testes når krav 3 fungerer. 4.2.5 Krav 5 - Emner Man vil kunne komme inn på emner ved å trykke på en subkategori. Da vil en tabell bli vist av alle emnene til en subkategori. Hvert emne skal kunne stemmes opp eller stemmes ned, for å kunne stemme opp eller stemme ned må man være en bruker av forumet. Avhengig av: Krav 4, da man må kunne klikke på subkategori for å se trådene til denne subkategorien. Test: Kan testes når krav 4 fungerer. 13

4.2.6 Krav 6 - Kommentarer Ved å trykke på et emne så vil man ha muligheten til å se kommentarene til dette emnet. Kommentarene vil fortsette nedover i all evighet, siden det ikke vil bli lagd en sidefunksjon. Avhengig av: Krav 5, her må en tråd være opprettet for at kommentering skal være mulig. Test: Kan testes når krav 5 fungerer. 4.2.7 Krav 7 - Profil Ved å trykke på brukernavnet til en på medlemslisten, eller sitt eget brukernavn vil man komme inn på profilen sin. Her vil mye av informasjonen til brukeren bli vist. Avhengig av: Krav 2, du må være registrert og krav 1, du må være logget inn. Test: Kan testes når krav 1 og 2 fungerer. 4.2.8 Krav 8 - Redigering av profil Det vil være mulighet for redigering av profilen man har opprettet. For å redigere profilen sin skal man måtte trykke på brukernavnet sitt. Avhengig av: Krav 1 og 2. Du må være registrert og logget inn for å redigere en profil. Test: Kan testes når krav 7 fungerer. 4.2.9 Krav 9 - Søkefunksjon Søkefunksjon skal være lett tilgjengelig på forsiden av websiden, her skal brukere kunne søke etter emner. Om en bruker ikke husker hele emnenavnet, så skulle systemet kunne finne emner med lignende navn. Avhengig av: Krav 5, at det eksisterer emner. Test: Kan testes når emner eksisterer. 4.2.10Krav 10 - Medlemsliste Det skal være mulighet for å kunne se en medlemsliste for å se andre som er registrert på forumet. Denne medlemslisten skal være sortert etter dato man ble registrert. Avhengig av: Krav 1 og 2. Kun innloggede brukere kan se medlemslisten. Test: Kan testen når en bruker er innlogget. 4.2.11 Krav 11 Nye emner På forsiden skal man kunne se nye emner som er opprettet. Slik kan man enkelt oppdatere seg på hva som er nytt på siden. Avhengig av: Krav 1 og 2. 14

Test: Kan testes når det er satt opp nye emner. 4.2.12 Krav 12 Trender Slik som i krav 11, vil det være mulig å se populære emner som er opprettet. Dermed kan man enkelt oppdatere seg på hva medlemmer av forumet ofte er innom. Avhengig av: Krav 1 og 2. Test: Kan testes når et system for upvoting er implementert 4.3 Funksjonelle krav for administratorer Her vil krav spesifisert for bruk av administratorer i forumet bli forklart. 4.3.1 Krav 1 - Redigering av brukere Administratorer skal kunne redigere brukere ved å søke opp et brukernavn. Der har de muligheten til å endre informasjon om denne brukeren. Avhengig av: Krav 1 og 2. Test: Kan testes når administratorpanel er opprettet. 4.3.2 Krav 2 Redigering av kategorier og subkategorier Administratorer kan legge til, slette, oppdatere og redigere kategorier og subkategorier ved hjelp av eget kontrollpanel. Avhengig av: Kravet er avhengig av eksisterende kontrollpanel for administratorer. Test: Kan testes når administratorpanel er opprettet. 4.3.3 Krav 3 - Sletting av tråder/emner og kommentarer Administrator kan slette tråder/emner og kommentarer som bryter forumets reglement. Avhengig av: Ett oppsatt forum reglement for brukere. Test: Kan testes når administratorpanel er opprettet. 15

5 Systemarkitektur For systemet tenkes det at en arbeidsstasjon har kontakt med en Cloud Plattform, denne cloud plattformen har kontakt med webserveren hvor websiden ligger lagret. Websiden henter ut informasjon fra databasen og skriver inn informasjon til databasen. Det er tenkt at komponenter som er leddvis koblet sammen kontinuerlig har kontakt med hverandre for å kunne oppdateres så effektivt som mulig. Arbeidsstasjonen som har kontakt med Cloud Plattformen vil her ha en Request & Reply protokoll, plattformen vil måtte hente informasjon som f.eks. layout i form av HTML og CSS og arbeidsstasjonen må få tilgang til plattformen ved bruk av sikkerhetsprotokoller. Se figur 5-1 for en skjematisk tegning av systemets tenkte arkitektur. Figur 5-1: Bildet viser systemets tenkte arkitektur. 16

6 Systemmodeller I kapittelet systemmodeller vil det finnes modeller av systemet som f.eks. flytskjema og E/R Diagram. Disse modellene skal kunne gi en oversiktlig forståelse av systemets virkemåte. 6.1 E/R Diagram av databasestruktur Figur 6-1 viser det fysiske E/R diagrammet. I brukertabellen så skal all informasjon om brukerne lagres, det vil være brukernavn, passord, kjønn, studieretning, beskrivelse av seg selv, hva slags rolle man har på forumet og en link til et bilde. Certification_id i brukertabellen vil være en tilfeldig generert kode som man skriver inn etter man registrer seg for å aktivere brukeren. Etter man har aktivert brukeren sin vil det ikke være noe informasjon lagret i Certerification_id. Kategoritabellen lagrer id og navn på kategorier, det samme gjør SubCategory tabellen for subkategori id og navn. Topictabellen inneholder en topicid, en userid, et topicname, en topictext og tidspunktet det ble postet. Dette for å vise hvem bruker som har lagd hva slags emne på forumet, og når dette har blitt tekst og hva slags tekst emnet inneholder. Tabellen kommentarer inneholder en commentsid, usersid, kommentartekst og tidspunkt som kommentaren ble postet. Tabellen Category_SubCategory lagrer alle subkategoriene en kategori kan ha. Det vil altså si hvis det er en kategori som heter Realfag, så kan denne kategorien ha mange subkategorier som f.eks. Matte, Fysikk og Kjemi. Disse vil bli lagret i tabellen Category_SubCategory. SubCategory_Topic vil lagre alle emnene en subkategori kan ha, og Topic_Comment tabellen vil lagre alle kommentarene et emne vil ha. Figur 6-2 viser det det logiske E/R diagrammet. 17

Figur 6-1: Bildet viser fysisk E/R diagram. Figur 6-2: Bildet viser logisk E/R diagram. 18

6.2 UML - Use Case Diagram I use case diagrammet i Figur 6-3 under vil man kunne se forholdet mellom aktører, klasser og metoder i det tenkte systemet. De to viktigste aktørene for at systemet skal fungere er her User og New User, disse vil stå for muligheten til å opprette bruker og alle funksjonene en bruker har i forumet. Alle aktører må ha en mulighet til å kunne logge inn som vist ved avhengighet mellom aktører og objektet Login i Use Case Diagrammet. Alle aktører som går via Login må også innom aktøren System Authenticator som vil stå for å verifisere at brukeren eksisterer, hvilken rolle brukeren har og om brukeren er blitt utestengt fra forumet eller ikke. Administratorer skal ha muligheten til å kunne gjøre brukere til moderatorer, det skal også være mulighet for å komme seg inn på et kontrollpanel for enklere redigering av forumet. Dette som følge kravspesifikasjoner gjort i kapittel 4. Figur 6-3: Bildet viser et overordnet Use Case Diagram for forumet. 19

Figur 6-4: Bildet viser et forenklet Use Case Diagram for forumet. 6.3 UML Sekvensdiagrammer 6.3.1Registrering Her må en ny bruker først skrive inn informasjon om seg selv, denne informasjonen vil deretter bli sendt til Authenticator klassen ved trykk på en knapp registrer som vha. metoden Register() vil sette informasjonen inn i databasen. Brukeren vil sendes til en ny side hvor man må sette inn verifikasjonskode som man får da systemet sender en verifikasjonsemail tilbake til bruker om registreringsinformasjon er fullført implementert i databasen. Dersom et obligatorisk innfyllingsfelt mangler i opprettelsen av ny bruker vil det sendes en melding om at Obligatorisk felt mangler til brukeren. Alt dette som vist i Figur 6-4 under. 20

Figur 6-5: Bildet viser sekvensdiagram av registrering i forumet. 6.3.2Logg inn Her må brukeren skrive inn brukernavn og passord og trykke på knappen logg inn, deretter vil Authenticator-klassen behandle informasjonen og kjøre metoden LogIn() som vil sjekke opp imot databasen om det er en eksisterende bruker. Dersom brukeren eksisterer så vil det startes en session. Det vil returneres melding om feil brukernavn/passord eller ikke eksisterende bruker om brukeren ikke eksisterer i databasen. Alt dette som vist i Figur 6-5 under. Figur 6-6: Bildet viser sekvensdiagram av logg inn i forumet. 6.3.3Lag kommentar For å lage kommentar må det først sjekkes om brukeren er i en session slik at systemet vet at det er en bruker som har rettighet til å skrive kommentar på forumet. For å kunne skrive kommentaren må informasjon skrives inn i et kommentarfelt og deretter en kommenter knapp trykkes på. Denne informasjonen sendes inn til database via metoden CreateComment(). Når informasjonen er lagt inn i databasen vil siden lastes inn på nytt, 21

slik at kommentaren blir vist, alt dette som vist i figur 6-7 under. Figur 6-7: Bildet viser sekvensdiagram av medlemsliste i forumet. 6.3.4Opprett emne Her må det sjekkes om en bruker er i en session. Deretter vil brukeren kunne se en knapp for oppretting av et emne, her vil man kunne legge inn informasjon som via metoden CreateTopic() legger inn informasjonen i databasen. Så vil nettsiden lastes inn på nytt slik at man kan se emnet som er opprettet. Alt dette som vist i Figur 6-8 under. Figur 6-8: Bildet viser sekvensdiagram av emneopprettelse i forumet. 6.4 UML Klassediagram Figur 6-9 viser klassediagrammet og metodene som skal være i klassene. Klassen Member vil være en overordnet klasse for oppretting av metoder og funksjoner som registrerte brukere av forumet vil ta i bruk via GUI et. Her vil metoder som f.eks. CreateTopic slik som vist i sekvens diagram i Figur 6-8 ovenfor, ligge. Det vil være to andre klasser som vil arve fra klassen Member, disse klassene er Administrator og Moderator. Disse klassene tilsvarer funksjoner og metoder som Moderatorer og Administratorer skal ha tilgang til på forumet. Klassen Authenticator vil være en klasse for bruk av autorisering av nye brukere og allerede eksisterende brukere. Alt dette som vist i Figur 6-9 nedenfor. 22

SKRIVES MER OG LEGGE INN FORHOLD MELLOM KLASSER OG LEGGE INN NYE KLASSER Figur 6-9: Bildet viser et klassediagram. 23

7 Systemets evolusjon Her vil alle antakelser gjort om systemet og antakelser om endringer av systemet bli oppgitt. 7.1 Fundamentet Forumet skal kunne ha en enkel navigerbar hjemmeside. På hjemmesiden skal man kunne se de største kategoriene og det skal også være mulighet for å kunne se nye tråder som blir opprettet og populære tråder som er mye brukt i forumet. Det skal også kunne være mulighet for å logge inn og opprette konto ved bruk av knapper på hjemmesiden. En dropdown meny vurderes for implementering, for enkel navigering gjennom kategorier. 7.2 Antatte endringer Antatte endringer i funksjonaliteten av forumet kan være følgende: 7.2.1Brukerendringer Det er her antatt at endringer i form av hvilke innstillinger og profilmuligheter en bruker har kan endres under prosessen. Det er nå antatt at en bruker skal kunne ha muligheten til å redigere Utdanning, årgang, bilde og en kort beskrivelse av seg selv på profilsiden. Dette er ikke nødvendigheter for brukeren og er dermed vurdert som endringer i prosjektet. 7.2.2Kommentarer i tråder/emner Det er antatt at man skal kunne legge kommentarer fra seg under valgte tråder/emner. Foreløpig skal det bare være mulig å kommentere på tråden/emnet, men ikke mulighet for å kommentere på andres kommentarer. Dette legges under vurdering for endring. 24

8 Referanser [1] H.P Halvorsen, Software Development A practical approach, 2017 [2] https://expresswriters.com/tldr-what-is-gdpr/, Lastet ned 17.02.2019 25