SRD. Software Requirements and Design GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

Transkript

1 SRD Software Requirements and Design GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

2 Innholdsfortegnelse 1. Systemoversikt Tekniske krav Funksjonskrav og brukergrensesnitt spesifikasjon Begrensninger Systemkrav Teknisk arkitektur API Systemarkitektur Database ERwin database diagram UML Use Case diagram Sekvensdiagram Opprette quiz: Delta i spill: Registrer bruker: Logg inn: Klassediagram

3 1. Systemoversikt I sin enkleste form er GLIS et quiz-spill som skal kunne brukes under opplæring i alt fra grunnskole til universitet. Det er en webapplikasjon der eneste krav til bruker er en pc med nettleser. Alle brukere kan opprette quizer med egne svar og alternativer. Glis står for «Glis Liker Ikke Slagord», men er også et ord vi assossierer med noe positivt. 2

4 2. Tekniske krav Ved utvikling av en programvare stilles det en rekke krav avhengig av hva programvaren 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 vet hva som kreves for å tilfredsstille kravene. Funksjonskravene under er spesifikasjoner rettet mot hva programvaren skal utføre av oppgaver. Hvor effektivt dette skal gjøres spesifiseres ikke i dette kapittelet 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 aktivt spill (med kode) eller å logge inn til sin personlige side (Figur 2.1). Må: Det skal være valgfritt om en bruker vil opprette en bruker med passord eller spille som gjest. Figur 2.1 Enkel skisse av forsiden. Må: Hver bruker kan opprette sin egen konto. 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. Brukeren skal kunne aktivere en allerede laget quiz. Da skal enten ny spillkode bli sendt til administrator, eller en oversikt over spillkoden (som aldri endres) vises. Ønsket: Den personlige siden inneholder en oversikt over hvor mange som har spilt quizene og hvor mange ganger quizen er tatt i bruk. Må: Fra denne siden skal det også være mulig å opprette ny quiz (Figur 2.2). 3

5 2.2. Enkel skisse av en registrert brukers personlige side. Figur Må: Administrator har en mer utfyllende personlig side med en oversikt over registrerte brukere, registrerte quizer i tillegg til sine egne quizer (Figur 2.3). Figure 2.3 Skisse av Administratorenes personlige side. Må: Når et nytt spill lages skal bruker formulere et spørsmål med 4 svaralternativer ved å fylle inn tekst i tekstboksene under. I tillegg må verdien av hvert svaralternativ bestemmes som et heltall mellom -100 og 100. Ønsket: Quiz-eier kan ha mulighet til å legge inn flere svaralternativer. 4

6 Ønsket: Mulighet for quiz-eier å legge inn bilder eller figurer til spørsmålene og/eller i svaralternativboksene. Må: Det skal være mulig å angi poengsum til hvert av svaralternativene (eller om svaret er rett eller galt). Må: Quiz-eier skal ha mulighet til å lage et ønsket antall spørsmål ved å trykke på knappen «Next Question» og deretter opprette quizen med trykk på knappen «Finish Quiz» (Figur 2.4). Figur 2.4. Enkel skisse for siden til opprettelse av spørsmål og svaralternativer. Spørsmål skrives inn i øverste firkant, deretter må man legge inn minimum 2 svar og maks 4. Må: Quiz-eier skal få tilsendt spillkoden til sitt spill. Må: Flere brukere skal kunne logge inn i programmet samtidig med gitt kode fra quizeier. Må: Deltagere skal kunne velge eget brukernavn. Ø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.5. Enkel skisse av spørsmålsidene. Et svar kan inneholde maks 150 karakterer. Ønsket: Når en deltager har avgitt svar sendes han/hun til en midlertidig/vente-side til alle deltagere har avgitt svar eller eier av spillet har avsluttet muligheten for å svare. 5

7 Ønsket: Mens deltakerene svarer på spørsmålene settes eier av spillet til en vente-side der han/hun kan se hvem og hvor mange av deltagerne som har avgitt svar. Må: For hvert spørsmål skal administrator få tilgang til en liste over deltagerens svar. Ønsket: For hvert spørsmål skal eier få tilgang til en liste over deltagerens svar som oppdateres hver gang en bruker avgir svar. Quiz-eier skal på en oversiktlig måte ha kontroll på når alle deltagerne har avgitt svar (Figur 2.6). Må: Quiz-eier avgjør når neste spørsmål kommer manuelt ved trykk på knapp. Figur 2.6. Enkel skisse av siden administrator ser mens spillerne svarer på spørsmål. Ønsket: Quiz-eier, men også deltakerne hvis ønskelig, skal ha mulighet for å se en resultatliste som viser resultatet til deltagerne med størst total sum for hvert nye spørsmål (Top 5 liste). Ønsket: Scrollbar liste så eier, men også deltakerne hvis ønskelig, kan se alle deltakeres totale sum (Figur 2.7). Må: Kun eier av en quiz sin resultatside har en «Next question»-knapp, ellers er resultatsiden like for deltakere og eier. Figur 2.7. Enkel skisse av resultatsiden.oppdater bilde Må: Spillet avsluttes når eier trykker «Finish Quiz» på siste spørsmål. Ønsket: Administrator kan avslutte quiz når som helst, og fortsatt se avsluttende resultater. 6

8 2.2. Begrensninger Server kan ha nedetid for vedlikehold mellom 10:00 og 14:00 tirsdager og fredager, men er ellers på hele uken. Øvre grense for antall aktive brukere og spørsmål settes etter behov. Pc som skal brukes av spiller eller quiz-eier trenger kun internettilgang og nettleser. I videre utvikling kan spillet være tilgjengelig på mobil. Foreløpig: Deltakere av et spill må få koden personlig fra eier. Senere: Mulighet for å opprette «offentlige» spill. Tiden vil være en begrensning for hvor utfyllende programmet blir og hvor mange funksjoner som blir tilgjengelig 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 rammeverket for utvikling i Visual Studio. IIS fra Microsoft blir brukt som programmets webserver. ISS gir programmet tilgang til internett og kan brukes ved hjelp av nettleser og PC. Spillet skal være tilgjengelig på internett. Deltakernes brukernavn, svar og resultat lagres i MS 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. Kun valgt brukernavn og epost adresse, dersom det ønskes å registrere en bruker. 7

9 3. Teknisk arkitektur Den tekniske arkitekturen skal gi brukeren et overordnet bilde over hvordan programmet skal fungere. Dette kan ofte vises ved et flytdiagram Flytdiagram Flytdiagrammet (Figur 8) viser en enkel oversikt over hvordan programmet kan benyttes av brukere. Først må bruker gå til Glis sin nettside. Her vil han/henne få valget mellom å logge inn, registrere ny bruker eller å spille som gjest ved å angi spillkode (Gamecode) og midlertidig brukernavn. Dersom brukeren velger å spille som gjest vil han/henne bli sendt direkte til det spillet som samsvarer med oppgitt spillkode. Registrerte brukere kan logge inn med brukernavn og passord og bli sendt til sin egen personlige side. For å registrere en bruker velges det på forsiden. Brukeren blir deretter sendt til en registeringsside før han/henne får opprettet en bruker og blir sendt til sin nye personlige side. Fra den personlige siden kan brukeren se informasjon om sine egne quizer, lage nye/aktivere/slette quizer. For å spille quizer trenger brukeren kun å angi quizens spillkode. Dersom brukeren ønsker å lage en ny quiz velges dette med et tastetrykk og brukeren sendes til en ny side. På denne siden trenger brukeren kun å fylle ut tekstboksene for spørsmål, svar og poengsum. Brukeren kan lage så mange spørsmål han/henne ønsker og opprette quizen etter ønsket antall spørsmål. Deretter sendes brukeren tilbake til sin personlige side. 8

10 Figur 3.1. Hendelsesforløpet til opprettelse og bruk av spillet 3.2. API API Application Programming Interface. En spesifikasjon som forteller hvordan programvare komponenter snakker med hverandre. Det fungerer som et bibliotek med funksjoner, metoder og klasser som brukes i kodingen av programvaren. Bruk av API i et prosjekt vil gjøre det lettere for andre utviklere da de kan: Ha fokus på prosjektet Spare tid på utvikling Reduserer feil og feilsøkingstid Tilrettelegge for et modulært design Få en konsekvent utviklingsplattform. En API vil gi en mye finere arkitektur, gjøre det lettere å legge til og endre metoder og lettere å fikse bugs under utviklingen av prosjektet. «GLIS» krever mye kommunikasjon med database. Det vil derfor være svært gunstig å sette opp en database kommunikasjons API. Der views og stored procedures kan være. 9

11 Figur Tegning av hvordan en Database API skal fungere. Bildet er hentet fra ware%20arc hitecture.pdf 3.3. Systemarkitektur Systemarkitekturen er viktig for å kunne forstå hvordan programmet skal fungere. Det skal vise hvordan database, webservere og koden skal henge sammen. Den beskriver hvilke servere som skal brukes og hvilke andre hjelpemidler som kreves for at programmet skal fungere. Arkitekturen skal også vise hvilke behov en bruker må oppfylle for å kunne ta i bruk programmet. 10

12 Figur 3.3 Systemskisse av GLIS sitt program. Figur 3.3 viser hvordan programmet til GLIS skal fungere. Programmet med database vil ligge på Windows Server Dette skal igjen ligge på IIS, en webserver fra Microsoft, som gir programmet tilgang til internett og kan brukes ved hjelp av nettleser fra en PC. Programmet blir laget i ASP.NET sitt rammeverk for webapplikasjoner. GLIS har en trelags arkitektur bestående av presentasjonslag, businesslag og et datalag. Presentasjonalaget er igjen fordelt i brukergrensesnitt og serviselag. Brukergrensesnittet består av flere Web Forms. Noen eksempler på hvilke Web Forms programmet har er vist i Figur 3.3. Businesslaget består hovedsakelig av programmets C# kode som utvikles i Visual Studio. Datalaget kalt «Common Database API C#» i figuren er koblingen mellom Visual Studio koden og SQL databasen. 11

13 4. Database En god databasestruktur er nødvendig for å få et effektivt program. I «GLIS» er det mye som skal lagres i database. Bland annet informasjon om brukere, quizer med spørsmål, svar og resultater 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 4.1). 12

14 5. UML UML står for Unified Modeling Language. Det er et utviklings-, og modeleringsspråk innenfor utvikling av programvare. UML er en rekke diagrammer som beskriver programvarens funksjon og design. UML diagrammene som benyttes her er Use Case Diagram, Sekvensdiagram og Klassediagram. Utfra disse diagrammene skal det være mulig å få en helhetlig oversikt over hvordan programmet skal fungere Use Case diagram Use Case diagrammet viser forholdet mellom bruker (actors) og systemets Use Cases (Figur 10). Diagrammet gir en enkel beskrivelse av hvordan ulike brukere av spillet kan utnytte spillets funksjoner og hvilke andre systemer handlingene påvirker. Figur 10 viser at en registrert bruker og adminbruker kan delta i quiz, lage quiz og logge inn. En qjest (ikke registrert bruker) kan kun delta i quiz og registrere bruker. En kodegenerator er koblet til opprettelsen av quizer. Det blir sendt melding/tilbakemelding ved opprettelse av quiz, innlogging av bruker og registrering av ny bruker. Ved deltagelse i quiz vil en resultatliste bli vist når quizen avsluttes. Figur 5.1 Use Case-diagram 13

15 5.2. Sekvensdiagram Sekvensdiagram beskriver hvordan og i hvilken rekkefølge objektene i klassene skal operere med hverandre i programmet. Sekvensdiagrammene under tar utgangspunkt i hver sin Use Case (Figur 10) Opprette quiz: Ved opprettelse av quiz vil brukeren først bli sjekket om han/henne er en registrert bruker. Det er kun registrerte brukere som kan lage quizer. For å lage spørsmålene og tilhørende svaralternativer skriver brukeren dette inn i tekstbokser. Når brukeren har fylt ut tekstboksene kan han/henne velge å lage flere spørsmål. Denne sekvensen går i en løkke (loop) inntil brukeren velger å lagre quizen ved å trykke på knappen «Opprett quiz». Da blir quizen lagret i databasen og skal være klar til bruk. Figur Sekvensdiagram for å lage quiz Delta i spill: For å delta i spill kreves en bestemt spillkode(gamecode). Denne koden vil bestå av 6 siffer eller bokstaver og er ulik for hver quiz. Når en bruker ønsker å delta i en quiz skriver han/henne inn koden som hører til den bestemte quizen. Denne koden må sjekkes og godkjennes. Dersom man spiller med et midlertidig brukernavn velges dette før quizen starter. Når quizen er i gang, er det en løkke(loop) som kjøres og viser oppdaterte resultater etter hvert spørsmål. 14

16 FrontPage/UserPage (WebForms) Participant GameCode JoinGame(userId, gamecode) joinquizpassed Redirect() GetActiveQuiz(gameCode) quizid WaitingRoomQuiz Figur Sekvensdiagram for å delta i quiz Registrer bruker: For å registrere en bruker, taster man inn den informasjonen som kreves i tilhørende tekstbokser. Deretter vil det bli kjørt to metoder. Først en metode for å kryptere ønsket passord, deretter en metode som registrerer alt inn i databasen. Etter registreringen blir brukeren sendt til sin personlige «GLIS» brukerside. RegisterUser (WebForm) User Create(userName, password, ) ans = usercreated Login( , password) ans = loginsuccess Redirect() UserPage (WebForm) Figur Sekvensdiagram for å registrere bruker 15

17 Logg inn: For å kunne logge inn må man taste inn brukernavn og passord. Det blir da kjørt en metode for å hente ut passord og dekryptere. Hvis dette godkjennes blir man sendt til personlige «GLIS» brukerside. FrontPage (WebForm) User Login( , password) ans = loginsuccess Redirect() UserPage (WebForm) Figur Sekvensdiagram for å logge inn 5.3. Klassediagram Klassediagram viser strukturen til de forskjellige klassene i programmet. Det viser forholdet mellom klassene, og de allerede kjente metodene og egenskapene hver klasse inneholder. Diagrammene er utarbeidet utfra sekvens-diagrammene. Klassediagrammet for dette prosjektet er laget som to klassediagram, dette er kun for å gi bedre og mer ryddig oversikt over klassene. Klassediagrammene er fordelt utfra arkitekturens bussineslag og serviselag. Til sammen utgjør de to klassediagrammene oversikten over alle klassene i programmet. Klassediagram for bussineslag (Figur 5.6): 16

18 Figur 5.6 Klassediagram for Businesslag. Klassediagram for serviselag (Figur 5.7): Figure 5.7- Klassediagram for serviselag. 17