Team2 Requirements & Design Document Værsystem

Transkript

1 Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 22/01/2018 Systemutvikling og dokumentasjon/ia4412

2 Innholdsfortegnelse 1 Systemoversikt Beskrivelse av systemet Problembeskrivelse Skisser av systemet Tekniske krav Funksjonelle krav Ikke-funksjonelle krav Spesifikasjoner for brukergrensesnitt User Task Flow... Feil! Bokmerke er ikke definert. 2.5 I/O og andre dataspesifikasjoner Spesifikasjoner for Interface til andre systemer Arkitektur Den tekniske arkitekturen til systemet Systemskisser Database UML

3 1 Systemoversikt Systemet som blir utviklet skal være en webapplikasjon som viser brukeren værdata fra forskjellige værstasjoner. Værdata som skal vises er temperatur, luftfuktighet, vindhastighet, lufttrykk og nedbørsmengde. 1.1 Beskrivelse av systemet Systemet skal bestå av ulike typer sensorer som plasseres på forskjellige værstasjoner. Den første skal plasseres på Høgskolen i Sørøst-Norge Campus Porsgrunn. Det skal være mulig å opprette flere værstasjoner. Sensorene skal måle temperatur, lufttrykk, luftfuktighet, vindhastighet og nedbørsmengde. Dermed blir alle disse 5 verdiene lagret og logget i en database og dermed overført til en oversikt på webapplikasjonen. Visual studio programmet som blir programmert i C# skal kommunisere med sensorene, webapplikasjonen og databaseserveren. Programmet skal spørre om data fra sensorene ved et tidsintervall gitt av bruker og dermed bruke det samme tidsintervallet til å logge verdiene til databasen og applikasjonen. Nettsiden hvor webapplikasjonen befinner seg i blir skrevet i HTML. 1.2 Problembeskrivelse Vær-tjenester som YR og Storm måler værforhold over generelt større områder hvor skolen er lokalisert, noe som kan medføre i avvik i målinger for skolens spesifikke område. Om man f. eks vil ha informasjon om værforhold over HSN Porsgrunn er det naturlig at man ser på værvarsel for kjølnes, hvor skolen befinner seg. Dette skal løses med et system som måler værforhold direkte ved Høgskolen i Sørøst-Norge campus Porsgrunn. 3

4 1.3 Skisser av systemet Figur 1-1 viser en enkel skisse av hovedsiden der det skal være mulig å navigere seg rundt i applikasjonen. Figur 1-1: Skisse av hovedside. Etter å ha trykket på Logg inn/registrer vil et skjermbilde som vist i Figur 1-2 vises. 4

5 Figur 1-2: Skisse av innloggingsside. 5

6 2 Tekniske krav Hva systemet skal gjøre og hvilke krav som må til for å kunne gjøre dette mulig kommer frem i dette kapitlet. 2.1 Funksjonelle krav Det er et krav at nettsiden skal gi brukeren mulighet til å registrere seg som en ny bruker og logge inn via hovedsiden. Om brukeren glemmer passordet skal dette kunne bli tilbakestilt ved at systemet må kunne identifisere brukeren ved å sende en epost. Det kreves av webapplikasjonen at værdata skal kunne fremstilles både grafisk og ved tall. Brukeren skal kunne klikke seg inn på en spesifikk vær-egenskap for mer utfyllende informasjon, og brukeren skal også kunne velge en spesifikk dato hvis det er ønskelig å se tidligere værdata. Denne dataen henter systemet opp fra databasen. 2.2 Ikke-funksjonelle krav Noen generelle krav innebærer stabil server med nok kapasitet for lagring av data, beskyttelse av personlig data, og sikkerhet fra skadelig programvare. Systemet krever at brukeren har en datamaskin med internett tilkobling for å kunne bruke webapplikasjonen. Det kreves at sensorene kommuniserer med databasen kjapt nok til at målingene som vises i webapplikasjonen kan kalles direkte. På samme måte kreves det at de andre komponentene i systemet kommuniserer kjapt nok. Hvis en av sensorene feiler må systemet kunne varsle om dette og opprettholde seg som normalt. Dette skal løses med en feilmelding til administrator og at bruker 6

7 vil se en status; «ute av drift» på denne målingen. Det vil også være mulighet for å legge til flere sensorer på et enkelt sted som fører til at bruker ikke vil se at en sensor er ute av drift. Hvis en sensor blir fjernet med vilje skal også databasen kunne håndtere dette ved å legge inn en ny status; «fjernet». 2.3 Spesifikasjoner for brukergrensesnitt Nettsiden sin forside/hovedside skal bestå av webapplikasjonen samt en meny som ligger på toppen som vist i Figur 1-1. Denne menyen inneholder klikkbare ikoner/tekst som vil dirigere brukeren til sider som innlogging (se Figur 1-2), registrering og hovedsiden. Bunnen av nettsiden vil inneholde klikkbar tekst som dirigerer brukeren til sider som hjelp, om og kontakt. Webapplikasjonen skal kunne fremvise værdata ved bruk av tall og grafiske fremstillinger som en historisk graf og grafisk fremstilling av værforhold. Hovedsiden av applikasjonen skal gi et overblikk over alle værdata fra den relevante dagen, men det skal også være mulig å klikke seg inn på en spesifikk værmåling for mer utfyllende informasjon. 2.4 Flytskjema Flytskjemaet viser hvordan en bruker skal operere systemet. Figur 2-1 viser at brukeren fra hovedsiden kan enten velge å logge inn/registrere seg eller tilbakestille passord på en eksisterende bruker, eller så kan webapplikasjonen brukes uten å registrere seg. Etter fullført innlogging blir brukeren dirigert tilbake til hovedsiden. Figur 2-1 viser også at webapplikasjonen fremviser som standard en generell oversikt over værdata som blir målt direkte, men også at det er mulig å velge dypere hva man vil se. 7

8 Figur 2-1: Flytskjema. 2.5 I/O og andre dataspesifikasjoner Input i systemet vil bestå av de forskjellige sensorenes verdier. Output blir i form av tall og grafisk fremstilling. Input signaler som blir brukt skal gå gjennom forskjellige IO enheter. Den første som blir tatt i bruk er NI DAQ som er en signalbehandlingsenhet levert av National Instruments, som leser og omformer analoge og digitale signaler. Der det blir satt grenseverdier til de gjeldene sensorene. Signaltyper som skal brukes skal defineres når det blir spesifisert hvilke sensorer som skal brukes og hvilke måleomfang disse har. 8

9 2.6 Spesifikasjoner for Interface til andre systemer Systemet kommer til å inneholde et interface for kobling mellom I/O enheten og programmet og interface for tilkobling til databasen. Siden det kommer til å være flere metoder med veldig lik atferd ved kobling opp mot I/O enheten og databasen er dette et godt sted for bruk av interface for bedre struktur. 9

10 3 Arkitektur 3.1 Den tekniske arkitekturen til systemet Den tekniske arkitekturen til systemet består av et lokalt nettverk med en eller flere servere med noen datamaskiner koblet til den for feilsøking og oppdatering av systemet. Brukere kobler seg til webapplikasjonen og dataen blir sendt gjennom internett til databasen(serveren) for lagring av data. 10

11 3.2 Systemskisser Figur 3-1: Systemskisse 3.3 Database Figur 3-2 viser databasestrukturen i en ERmodell. USER tabellen er har ikke noe forhold med resten av tabellene. Denne tabellen tar seg kun av brukerinformasjon som brukes til å logge inn med. Password skal krypteres. MEASUREMENT LOG er tabellen hvor all data fra sensorer blir lagret. Denne tabellen er koblet til SENSOR tabellen med et forhold som sier at en sensor kan ha flere målinger. INTERVAL tabellen spesifiserer hvor ofte det skal hentes data fra en type sensor. Denne tabellen er da koblet opp med SENSORTYPE ved at et interval kan ha flere sensortyper, og en sensortype kan ha flere sensorer. STATION inneholder informasjon om forskjellige værstasjoner og hvor de befinner seg, og en værstasjon kan ha flere DEVICE. Det skal være mulig og 11

12 legge til flere værstasjoner etterhvert som disse blir opprettet. DEVICE inneholder informasjon om enheter slik at brukeren av applikasjonen kan se dette hvis det ønskes. En enhet kan ha flere sensorer. Figur 3-2: ERmodell av databasen 3.4 UML (Gjøres senere) 12

13 Figur 3-3: Use case diagram 13