SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie
Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger... 6 2.3. Systemkrav... 7 3. Tekninsk arkitektur... 8 3.1. Flyt-diagram... 8 4. Database... 9 4.1. ERwin database diagram... 9 5. UML... 10 5.1. Use Case Diagram... 10 5.2. Sequence Diagram... 11 5.2.1. Opprette quiz:... 11 5.2.2. Endre data:... Feil! Bokmerke er ikke definert. 5.2.3. Delta i spill:... 12 5.2.4. Registrer bruker:... 13 5.2.5. Logg inn:... 14 5.3. Klassediagram... 15 1
1. Systemoversikt I sin enkleste form er GLIS et quiz-spill som skal kunne brukes i opplæring på grunneskole og videre utdanning og til sosiale sammenkomster. Det er en webapplikasjon og eneste krav til bruker er en pc med nettleser. Mulighet for både å kunne delta og lage quizer. Når man lager en quiz kan man oppgi flere svaralternativer hvor minst ett må være riktig. Spørsmålene vil komme opp på pc-skjermen og bruker må trykke på et av svaralternativene. Den/de med høyest poengsum vinner. Navnet «GLIS» kom frem etter tankeprosess på navn hvor målet var å ha et morsomt og fengende navn som skulle få frem positivitet og glede. 2
2. Tekniske krav Når man skal utvikle en programvare stilles det en rekke krav avhengig av hva det skal brukes til, hvem som skal bruke det og hvordan det skal brukes. Det er derfor viktig å kartlegge dette før man setter i gang med utviklingen, slik at man veit hva som kreves for å tilfredsstille de kravene som stilles. 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon Dette underkapittelet inneholder funksjonskravene(«må») til programmets brukergrensesnitt, samt ønsker til videre utvikling av brukergrensesnittet. Må: Programmet/spillet skal være tilgjengelig fra internett. Må: På første skjerm skal det være mulig å delta i et allerede laget spill (med kode), å lage en ny quiz, eller å logge inn til sin personlige side (Figur 2.1). Ønsket: Ved å velge «Lag quiz» vil bruker få valget mellom å logge inn eller å registrere ny bruker. Figur 2.1 - Enkel skisse av forsiden, hvor det øverste rektangelet er en tekstblokk og de to andre firkantene er knapper. Må: Hver bruker/administrator kan opprette sin egen bruker. Når bruker logger inn med valgt brukernavn og passord vil han/henne komme til sin egen personlige side. Må: Denne siden skal inneholde brukerens allerede lagde spill. Ved å dobbeltrykke på en av quizene vil spillet bli aktivert og en ny spillkode bli sendt til administrator/ en oversikt over spillenes kode som aldri endres. Ønsket: Den personlige siden inneholder en oversikt over hvor mange som har tatt quizene. Må: Fra denne siden skal det også være mulig å opprette ny quiz (Figur 2.2) 3
Figur 2.2. Enkel skisse av en registrert brukers personlige side. Må: Når et nytt spill lages skal administrator lage spørsmål med 2-4 svaralternativer ved å fylle inn tekst i skrivefeltene. Ønsket: Administrator kan ha mulighet til å legge inn flere svaralternativer. Ønsket: Mulighet for administrator å legge inn bilder eller figurer til spørsmålene og/eller i svaralternativboksene. Må: Svaralternativ skal ha avkryssingsboks med mulighet til å huke av «riktig» for å avgjøre hvilke alternativ som gir poeng. Må: Administrator skal ha mulighet til å lage et ønsket antall spørsmål ved å trykke på knappen «Neste spørsmål» og deretter opprette quizen med trykk på knappen «Opprett quiz» (Figur 2.3). Figur 2.3. Enkel skisse for siden til opprettelse av spørsmål og svaralternativer. Spørsmål skrives inn i øverste firkant, også må man legge inn minimum 2 svar og maks 4. Må: Administrator skal få tilsendt spillkoden til sitt spill. Må: Flere brukere skal kunne logge inn i programmet samtidig med gitt kode fra administrator. Må: Deltagere skal kunne skrive inn sitt eget brukernavn. Må: Deltagere skal angi et alternativ deretter «Svar avgitt» (Figur 2.4). 4
Ønsket: Deltakere skal kunne avgi flere riktige alternativ. Ønsket: Når et av svaralternativene velges har deltagerne mulighet til å endre svar. Først når brukeren har trykket «Svar avgitt» låses muligheten for å endre svar. Ønsket: Tilbakemelding til hver enkelt bruker om deres svar stemte eller ikke på neste skjerm. Ønsket: Deltagere får mer poeng jo raskere de svarer på spørsmålene. Figur 2.4. Enkel skisse av spørsmålsidene. Et svar kan inneholde maks 200 karakterer. Må: For hvert spørsmål skal administrator få tilgang til en liste over deltagerens svar som oppdateres hver gang en bruker avgir svar. Administrator skal på en oversiktlig måte ha kontroll på når alle deltagerne har avgitt svar (Figur 2.5). Må: Administrator avgjør når neste spørsmål kommer manuelt ved trykk på knapp. Figur 2.5. Enkel skisse av siden administrator ser mens spillerne svarer på spørsmål. Må: Administrator, men også deltakerne hvis ønskelig, skal ha mulighet for å se en resultatliste som viser resultatet til deltagerne med størst total sum for hvert spørsmål (Top 5 liste). 5
Ønsket: Scrollbar liste så administrator, men også deltakerne hvis ønskelig, kan se alle deltagerens totale sum (Figur 2.6). Figur 2.6. Enkel skisse av resultatsiden. Må: Spillet avsluttes når administrator trykker «Neste» på siste spørsmål. Ønsket: Administrator kan avslutte quiz når som helst, og fortsatt se avsluttende resultater. 2.2. Begrensninger Server kan ha nedetid for vedlikehold mellom 10:00 og 14:00 tirsdager og fredager, men er ellers på hele uken. Quizer som lages har resultater tilgjengelig en uke etter opprettelse. De slettes automatisk fra databasen etter 1 uke. Øvre grense for antall aktive brukere og spørsmål settes etter behov. Pc som skal brukes av spiller eller administrator trenger kun internettilgang og nettleser. I videre utvikling kan spillet være tilgjengelig på mobil. Foreløpig: Deltagere av et spill må få koden personlig fra administrator. Senere: Mulighet for å opprette «offentlige» spill. Tiden vil være en begrensning for hvor utfyllende programmet blir og hvor mange funksjoner som blir tilgjengelig. 6
2.3. Systemkrav Hvilke systemkrav som kreves for å kunne lage en god webapplikasjon er viktig å kartlegge for å få en oversikt over hvilke ferdigheter som kreves for å utvikle applikasjonen. Programkode og brukergrensesnitt lages i Visual Studio. Utviklere trenger ASP.NET og.net sitt rammeverk i Visual Studio. Spillet skal være tilgjengelig på internett. Deltagernes brukernavn, svar og resultat lagres i SQL database. For hver ny spørsmålsrunde vil poengsummen til deltagerne oppdateres i databasen. Det skal ikke være nødvendig for brukere å oppgi personlig informasjon. 7
3. Tekninsk arkitektur Teknisk arkitektur skal gi brukeren en et overordnet bildet over hvordan programmet skal fungere og dere funksjoner. Dette kan ofte vises ved et flytdiagram. 3.1. Flyt-diagram Flyt-diagrammet i (Figur 8) viser en enkel oversikt over hvordan programmet kan benyttes av brukere. Figur 3.1. Hendelsesforløpet til opprettelse og bruk av spillet 8
4. Database En god databasestruktur er nødvendig for å kunne få et effektivt program. I «GLIS» er det mye som skal lagres som brukere, quizer med spørsmål og svar og resultater. 4.1. ERwin database diagram ERwin database diagrammet viser en oversikt over hvordan databasen er satt sammen og hvilke tabeller den består av. ERwin kobles sammen med Microsoft SQL Server (Figur Figur 4.1 - ERwin-diagram av databasestruktur 9
5. UML Unified Modeling Language. Det er et utviklings- og modelerings språk innenfor utvkling av programvare. Det viser en rekke diagrammer som skal beskrive programvarens funksjon og design. Ut ifra disse diagrammene skal det være mulig å få en oversikt over hvordan programmet skal fungere. 5.1. Use Case Diagram Use Case diagrammet viser forholdet mellom bruker/actores og systemets Use Caser (figur 10). Det gir en enkel beskrivelse av hvordan ulike brukere av spillet kan utnytte spillets funksjoner, og hvilke andre systemer de handlingene påvirker. Figur 5.1 - Usecase-diagram 10
5.2. Sequence Diagram Sequence diagram beskriver hvordan og i hvilken rekkefølge objektene i klassene skal operere med hverandre i programmet. Sequence diagrammene under tar utgangspunkt i hver sin Use Case (Figur 10). 5.2.1. Opprette quiz: Når man skal opprette quiz, må det først godkjennes at du er registrert bruker som er et krav for å kunne lage egne quizer. Det skal også velges en mal for hvordan du ønsker at quizen skal se ut. Når det skrives inn spørsmål og svar vil dette gå i en løkke, så hver gang bruker har trykket på en knapp «Legg til spørsmål» vil samme metode gjenta seg helt bruker velger å trykke på knappen «Opprett quiz». Da blir quizen lagret i databasen og skal være klar til bruk. Figur 5.2 - Sekvens-diagram for å lage quiz 11
5.2.2. Delta i spill: Det skal tastes inn en spillkode for hver bruker som ønsker å delta i quiz. Dette må godkjennes. Man får også en forespørsel om man ønsker å registrere seg, er ikke dette ønskelig fortsetter man som gjest med å taste inn spillkode og et brukernavn. Når quizen er i gang, er det en loop som kjøres og viser oppdaterte resultater etter hvert spørsmål. Figur 5.3 - Sekvens-diagram for å delta i quiz 12
5.2.3. Registrer bruker: Når det skal registreres en bruker, taster man inn den infoen som står i tekstbokser. Deretter vil det bli kjørt to metoder. Først en metode for å kryptere ønsket passord, og så en metode som registrerer alt inn i databasen. Etter registreringen kommer man til et nytt form som er din personlige «GLIS» brukerside. Figur 5.4 - Sekvens-diagram for å registrere bruker 13
5.2.4. Logg inn: For å kunne logge inn må man taste inn brukernavn og passord. Det blir kjørt en metode for å hente ut passord og dekryptere. Hvis dette godkjennes blir man sendt inn til sin egen «GLIS» brukerside hvor man kan opprette quizer og se på statistikk. Figur 5.5 - Sekvens-diagram for å logge inn 14
5.3. Klassediagram Klassediagrammet viser strukturen av de forskjellige klassene i programmet. Det viser forholdet mellom klassene, og de allerede kjente metodene og egenskapene hver klasse inneholder. Den er utarbeidet fra sekvens-diagrammene. Figur 5.6 - Klassediagram 15