Produktrapport WillWest Smøredatabase GRUPPE 21 FORFATTERE: BREKKLUND, PÅL E. LARSEN, MARTIN WESTGAARD, CHRISTIAN S. 1
Innholdsliste Produktrapport... 1 Innholdsliste... 2 1 Forord... 4 2 Beskrivelse av programmet... 5 3 Programmets oppbygging og virkemåte... 6 3.1 MVC (Model-view-controller)... 6 3.1.1 Controlleren... 9 3.1.2 Modelldata... 9 3.1.3 Viewdata... 9 3.2 Databasen - Model... 10 3.2.1 Innlegg... 10 3.2.2 Brukertabellen... 10 3.2.3 Omstendigheter/Værdata... 11 3.2.4 Skiinfo... 11 3.2.5 Skipar... 11 3.2.6 StrukturType... 12 3.2.7 Glid... 12 3.2.8 Feste... 12 3.2.9 Oppsummering... 13 3.2.10 Oppsummering av databasen... 13 3.3 Nettsiden - View... 14 3.3.1 Ferdig kode... 14 3.3.2 Rammeverk... 16 3.3.3 Sidene... 17 3.3.4 CSS... 17 3.3.5 Bilder - figurer og ikoner... 18 3.3.6 JavaScript... 18 2
3.4 Nettsiden - Controller... 19 3.4.1 Behandling av inndata og funksjonskall... 19 3.4.2 Klasser... 19 3.4.3 Oppsummering av nettsiden:... 20 3.5 Offline versjon... 21 3.5.1 Hjelpeverktøy... 21 3.5.2 Modifikasjoner fra online versjon... 21 4 Samsvar mellom kravspesifikasjon og produkt... 22 4.1 Samsvar med kravspesifikasjonen... 22 3
1 Forord Dette er produktrapporten som er utarbeidet i forbindelse med hovedprosjekt våren 2014 ved Høgskolen i Oslo og Akershus av gruppe 21. Rapporten vil beskrive gangen i utviklingsarbeidet av siden laget for vår oppdragsgiver WillWest Sport. Prosessrapporten er først og fremst rettet mot sensor og veileder. Det forutsettes da at leseren har noe datateknisk innsikt. Prosessrapporten er inndelt i disse hovedkapitlene: Beskrivelse av programmet En beskrivelse av hvordan løsningen vår henger sammen. Programmets oppbygging og virkemåte En komplett gjennomgang av alle komponentene som løsningen vår inneholder, og hvordan disse er bygd opp og virker. Samsvar mellom kravspesifikasjon og produkt For dette kapittelet vil vi gå gjennom hvert punkt i kravspesifikasjonen og se hvordan produktet samsvarer/avviker fra kravspesifikasjonen. 4
2 Beskrivelse av programmet Nettsiden vi har laget er en WEB-basert smøredatabase. All nettbasert kode er skrevet med TextMate som plattform og kodingen skjer i PHP, JavaScript, jquery, HTML og CSS. SQL koden er skrevet både i Mac Terminal og i databaseoppsettprogrammet HeidiSQL. Dette kapittelet beskriver hva koden gjør, hvordan nettsiden oppfører seg og hvordan den ser ut. Hensikten med nettsiden er at brukeren skal kunne lagre alle sine data, for deretter i ettertid å kunne hente det frem igjen. Det skal være mulig å søke iblant den lagrede informasjonen. 5
3 Programmets oppbygging og virkemåte Dette kapittelet vil i detalj vise de ulike delene som nettsiden er bygget opp av, hvilke komponenter den har, og hvordan virkemåten til nettsiden er. For å se hva hver enkelt side gjør, se Brukermanualen, eller 4.4.1 "Betraktninger brukergrensesnitt" (GUI) i prosessrapporten. For å få forklaring på hva mye av hver spesifikke kodesekvens gjør, se kommenteringen i koden på vedlagt minnepenn. 3.1 MVC (Model-view-controller) Model-view-controller konseptet (heretter kalt MVC) er en arkitektur som brukes i grafiske editorer. Den ble for første ble først beskrevet av Trygve Reenskaug i 1979 da han arbeidet med Smalltalk hos Xerox PARC. Vi har brukt MVC som designmønster under programutviklingen av Smøredatabasen. MVC deler applikasjonen i tre deler: Model Applikasjonens data og funksjonalitet View Presentasjonen av data til brukeren (brukergrensesnitt, GUI) Controller Kontrollerer strøm av input fra bruker (tastatur, mus etc.) Controller er et mellomliggende komponent som muliggjør kommunikasjon mellom model og view. Med en slik inndeling kan man endre på brukergrensesnittet uten at dette har noen innvirkning på hvordan dataene blir håndtert. Endringer av hvordan dataene håndteres påvirker heller ikke brukergrensesnittet. 6
Figur 3.0 MVC konseptet I smøredatabasen er all lagret data knyttet til en innleggs ID. Modellen av klassen innlegg representeres av en rekke egenskaper og funksjoner gjennom en instans av gitt klasse. Denne instansen lagrer de data som er knyttet til innlegget som bruker, sted, dato, værforhold, informasjon om ski som er brukt, informasjon om produkter som er benyttet, rangering og kommentar. Når informasjon om innleggene skal vises eller manipuleres gjøres dette gjennom grensesnittet, i MVC kalt view. Controller forbereder informasjonen og sender aktuell data til view. Oppsummert kan man si at Model holder på data, view viser frem data og controller flytter på data. Et annet positivt aspekt ved å benytte dette mønsteret er forenklet kode ved å unngå replikasjon og gjenbrukbare objekter som kan brukes i andre grensesnitt for mobiltelefoner og nettbrett. Slike skiller seg fra grensesnittet for nettlesere på datamaskiner. Figur 3.1: MVC konseptet 7
"The model manages data and logic, the view creates the interface, and the controller processes user input." [Moock 2004] Figur 3.1 viser forholdet Model View - Controller og hvordan de kommuniserer seg imellom. Model kan gi utvalgt informasjon til view, eksempelvis at det har vært en forandring i model, oppdater view uten at det blir gått i detalj på hva forandringene innebærer. I view vil model da studeres og deretter oppdateres. View ber altså om å få beskjed fra controller dersom en bestemt hendelse skjer. Denne prosessen kalles Notify/Subscribe mekanismen. Linjen View - Model viser til at view kan kalle direkte på modellens funksjoner. Linjen View Controller kommer av at view kan kalle på et begrenset utvalg av funksjoner i kontrolleren. Denne ansvarsfordelingen gjør at modellen (data og logikk) ikke trenger å ta hensyn til brukergrensesnitt og viewet trenger ikke ta hensyn til logikk eller prosessering av input. Vi kan si mer direkte at modellen ikke skal vite noe om viewet, noe som også innebærer at den ikke inneholder noen referanser til view. Fordeler med MVC: - Én modell kan representeres til brukeren på flere måter (flere views) - Views kan lages, forandres eller fjernes uten å påvirke dataene (modellen) - Håndtering av brukerinput kan enkelt forandres - Et view kan brukes for flere modeller - Hjelper utvikleren med å fokusere på et område av applikasjonen av gangen - Man kan fordele arbeidet på gruppen. I vårt tilfelle så passet det bra, siden vi var tre stykk. Alle fikk en hoveddel å arbeide med - Man kan arbeide uavhengig på de tre områdene som er en fordel når man er flere utviklere med forskjellige arbeidsområder. 8
3.1.1 Controlleren All input fra brukerne skal gå gjennom kontrolleren. En forandring skjer blant annet i view når en bruker f.eks. trykker på en knapp, Controller vil da kalle på metoder som sørger for en eventuell forandring i modellen. Dersom modellen er aktiv vil forandringen i modellen reflekteres i view, dersom den er i passiv modus kan kontrolleren bestemme når view skal oppdateres. En handling i vår applikasjon er for eksempel å filtrere et view. Controller vil da håndtere alt som trigger de ulike handlingene som må skje for at filtrering kan utføres. For å benytte seg av skille mellom modell og view må det defineres hvilke data som tilhører hva. 3.1.2 Modelldata - Klassene - De identifiserende attributtene - Binære assosiasjoner med deres attributter (multiplisitet, roller, identifisering) 3.1.3 Viewdata - Visning av klasse om en klasse skal være synlig eller ikke i view - Gruppert/ikke gruppert klasse skal klasser grupperes eller ikke? - Visning av assosiasjonsklasser hvordan skal assosiasjonsklasser vises? - Fremmednøkler På et generelt grunnlag vil elementer som har egenskaper som kan være forskjellige i view tilhøre viewdata og data som er felles i alle view tilhøre modelldata. 9
3.2 Databasen - Model Databasen er bygget opp med MySQL kode med programmet HeidiSQL og direkte via terminal fra MacOS til skolens servere. Vi går nå igjennom i detalj hvordan databasen er bygget opp og hva funksjonen til hver av delene er. 3.2.1 Innlegg All data blir lagret som ett innlegg, det vil si at innlegg har relasjoner til flere entiteter, som igjen inneholder attributter. Vi kaller denne samlende entiteten for "innlegg". For bedre å forstå sammenhengen, se ER-diagram og forenklede modeller i vedlegg (figur 2.3 og 2.5). Den inneholder attributtene: Innlegg_ID INT(11) Primærnøkkel Sted Varchar (50) Dato Date SkiInfo INT(11) Fremmednøkkel Bruker INT(11) Fremmednøkkel Omstendigheter INT(11) Fremmednøkkel Glid INT(11) Fremmednøkkel Feste INT(11) Fremmednøkkel 3.2.2 Brukertabellen Hver bruker har sin unike ID og er utstyrt med brukernavn. Det skilles imellom smører og utvøver (bruker_detaljer). Brukerne kan lage seg ett passord som blir hashet. Passordet er hashet med en innebygd SQL hash i MySQL. Bruker_ID INT(11) Primærnøkkel BrukerNavn Passord BrukerDetaljer Varchar(100) Varchar(100) Varchar(100) 10
3.2.3 Omstendigheter/Værdata Værdata heter Omstendigheter i databasen. Værdata inneholder data som skal si noe om forholdene på stedet der dataene ble samlet inn. Omstendigheter_ID INT(11) Primærnøkkel Temperatur Luftfuktighet Vind Vaerforhold Snotemperatur Snofuktighe Snotype 3.2.4 Skiinfo INT(11) INT(11) INT(11) Varchar(100) INT(11) INT(11) Varchar(150) Skiinfo tabellen samler ID'ene fra tabellene Skipar og Struktur, og samler det i en egen Skiinfo_ID som blir brukt i Innlegg tabellen. Så det blir lettere å hente ut alle skiinfo dataen til innlegget. Skiinfo_ID INT(11) Primærnøkkel SkiNummer Struktur 3.2.5 Skipar INT(11) Varchar(50) Skinummer representerer et skipar. Alle ski har et unikt serienummer, slik at man kan skille mellom skiene. Skiene blir valgt ut ifra kvalitetene sine, om det er stabile, gode å gå med i 11
motbakker eller slipen. Et skipar kan enten komme med en fabrikkslip, eller det kan bli slipt (Slip). Et skipar kan slipes om flere ganger. Skipar_ID INT(11) Primærnøkkel Skinummer Slip 3.2.6 StrukturType Varchar(50) Varchar(50) Et skioppsett kan ha ingen eller flere forskjellige strukturtyper (manuelt skistruktur verktøy). Struktur lagres i form av "på hele, bak eller foran" på skien. StrukturType_ID INT(11) Primærnøkkel Foran Bak Hele 3.2.7 Glid Varchar(30) Varchar(30) Varchar(30) I tabellen glid lagres alle de forskjellige produkttypene som blir brukt under skien. Produktene deles opp i tre forskjellige kategorier, og lagres deretter. JernTemp er for å lagre hvilken temperatur smørejernet hadde ved pålegging av pulver. Glid_ID INT(11) Primærnøkkel Glider Pulver Topping JernTemp 3.2.8 Feste Varchar(150) Varchar(150) Varchar(150) Varchar(150) 12
I tabellen feste lagres alle de forskjellige produkttypene som blir brukt under skien. Produktene deles opp i tre forskjellige kategorier, og lagres deretter. Feste_ID INT(11) Primærnøkkel Base Klister Voks 3.2.9 Oppsummering Varchar(150) Varchar(150) Varchar(150) Oppsummering er en tabell som lagrer eventuelle kommentarer og en karakter for hvor bra smøringen og oppsettet fungerte. Oppsummering_ID INT(11) Primærnøkkel Karakter Kommentar INT(11) Varchar(150) 3.2.10 Oppsummering av databasen Det tok litt tid å få databasen slik vi og oppdragsgiver var fornøyde med. Men den oppfører seg slik vi ønsker. I oppgaveteksten så skriver oppdragsgiver at han ønsker å kunne bruke den "offline" også, dette er fullt mulig på det nåværende tidspunktet, men krever at man kjører f.eks. programmet XAMPP med phpmyadmin og Apache Web Server. Foreløpig ligger selve databasen på skolens webserver. 13
3.3 Nettsiden - View Dette kapittelet vil ta for seg hvordan view delen av nettsiden er bygget opp. Figur 3.2 viser mappestrukturen gruppen har. Under mappen HP, ligger "gui" og "php", disse mappene inneholder view og kontroller delen. Figuren viser alle de forskjellige undermappene i view. Figur 3.2 View bibliotek 3.3.1 Ferdig kode Den røde tråden igjennom hele siden er en bakgrunn med bilde av en skiløype i et hvit landskap. Bildet er nedtonet og behagelig for å holde fokuset på det interaktive som er midt på siden. For å få bildet til å holde seg sentrert i alle nettlesere på PC/Mac valgte vi å bruke jquery (spesielt IE krevde dette). Koden er tilpasset vår side, men jquery aktiveringen er hentet fra nettet. (CSS-Tricks, 20.11.2010). Figur 3.3 viser variablene og funksjonen som må til for å omskalere bildet. Det er i tillegg kode i CSS filen. 14
Figur 3.3 jquery bildekode Den andre koden gruppen har hentet fra nettet er den som gir brukeren mulighet til å velge dato fra en datoboks (figur 3.4). Figur 3.4 dato velger 15
Koden er hentet ifra siden (jquery user interface, udatert). Alle tilpasninger rundt datovelgeren er gjort av gruppen. Den siste koden gruppen har hentet fra en ekstern side er tilhører innloggingsboksen. Denne er også blitt modifisert og tilpasset til siden vår, men grunnmuren er den samme. Koden er hentet fra nettet (Developer drive, 14.03.2013). Figur 3.5 innlogging. Figur 3.5 viser et utdrag fra CSS koden til innloggingsboksen. Her legger vi blant annet inn farger, font og størrelse. 3.3.2 Rammeverk Siden er satt opp med et rammeverk i bunn som det resterende bygger på. Dette er HTML kode med tilpasset CSS. Rammeverket består av en footer, header og en header med snarveier. Alle sidene inneholder også den samme wrapper diven og samme content diven. Dette gjør at alle sidene ser like ut i grunnformen. Det eneste som endrer seg fra side til side er da innholdet i selve content diven. 16
3.3.3 Sidene Filene i mappen sidene representerer hver sin webside. Disse inneholder javascript for forskjellige handlinger og valideringer som foregår på de forskjellige sidene. De inneholder også det meste av HTML koden som blir presentert. På de dynamiske sidene inneholder filene PHP kode, denne koden kaller forskjellige funksjoner fra controller delen. 3.3.4 CSS Gruppen bruker HTML tagen "Div id" og "Div class" for å manipulere de forskjellige elementene på siden etter gruppen preferanser. "Div id" brukes for å skille ut elementer for seg selv, dette gjør elementet unikt. "Div class" brukes for elementer som blir brukt flere ganger, eksempel på det ser man i innleggsiden. Den består av mange like bokselementer som er like i utseende. Figur 3.6 viser et utklipp på hvordan gruppen har delt inn CSS koden. Vi har prøvd å holde oss til så få stilark som mulig, og heller dele inn i sider i forskjellige seksjoner i CSS-arket. Figur 3.6 css liste 17
3.3.5 Bilder - figurer og ikoner Bildene er lagd i Adobe-Illustrator og eksportert som PNG-filer for å muliggjøre transparent bakgrunn. Det sikrer i tillegg at det blir bedre oppløsning på bildene. Photoshop er brukt for å redigere bilder, lagre dem i jpg format og den iterative prosessen med GUI-delen. 3.3.6 JavaScript Gruppen bruker JavaScript til blant annet regex (Regular-Expressions.info, 2013). Dette for å tvinge bruker til å bruke kun bokstaver, eller tvinger bruker til at passord må være til en satt standard. Figur 3.7 viser et utdrag fra siden innleggregistrert.php. Den viser regex i en ifsetning for å registrere brukernavn. Figur 3.7 regex 18
3.4 Nettsiden - Controller Kontrollerdelen av nettsiden er den delen som inneholder de forskjellige klassene, samt PHP som tar imot inndata og kaller på funksjoner i klassene som behandler dataen. Filene ligger i php mappen og klassefilene ligger i egen mappe kalt klasser, som vist i figur 3.8. Figur 3.8 Controller bibliotek 3.4.1 Behandling av inndata og funksjonskall Filene som ligger direkte i php mappen, ikke i php/klasser mappen, inneholder filer som tar seg av controller delen. De behandler alt av inndata fra skjemaer og sender det til de forskjellige klassene og deres constructor. Det er også her alle funksjoner blir kalt fra klasse filene. 3.4.2 Klasser Gruppen har valgt å bruke objektorientertprogrammering i oppgaven, og tar dermed i bruk klasser og constructorer til å behandle all inndataen. Klassene inneholder også mange ulike funksjoner som gjør forskjellige ting. Det kan for eksempel være å koble til databasen og legge inn data, koble til databasen og hente data eller sjekker om data finnes i databasen. 19
Figur 3.9 Class og constructor Figur 3.9 viser et utdrag ifra php filen klassen Regbruker. Der kan vi se klassen bruker, som inneholder variablene brukernavn, passord og detaljer. Disse blir sendt til funksjonen, function construct og lagret i variabler. Funksjonen sjekkbrukernavn, sjekker om brukernavnet finnes fra før. Dersom brukeren ikke finnes fra før, kjøres funksjonen regbruker som da registrerer den nye brukeren. 3.4.3 Oppsummering av nettsiden: Nettsiden er bygget opp uten automatisk generert rammeverk eller hjelpeprogrammer og har dermed krevd litt tid for å se bra ut. Gruppen er allikevel fornøyd med resultatet og syns det ser innbydende ut, samtidig som det er lett å forstå hvilke valg man har på sidene og hva de gjør. Gruppen har latt oppdragsgiver prøve siden ved flere anledninger og han synes å være fornøyd med resultatet selv. 20
3.5 Offline versjon Det var et ønske fra oppdragsgiver å lage en versjon som kunne fungere offline også. Gruppen har gjort det slik at den versjonen som er online er blitt kjørbar offline også. Vi skal her gå igjennom hvordan det er blitt gjort og hvordan den kan brukes. 3.5.1 Hjelpeverktøy For at bruker skal kunne bruke smøredatabasen offline, så er han nødt til å ha XAMPP, Apache Web Server og MySQL database installert og riktig konfigurert på sin maskin. Riktig konfigurasjon betyr at PHP og HTML filene er lagt inn i localhost mappen, og at databasen er blitt importert inn i phpmyadmin. 3.5.2 Modifikasjoner fra online versjon Muligheten til å legge til nye brukere er tatt bort. Vi har laget en offline databasetilkobling, som gir mulighet til å kommunisere med nettside og databasen igjennom phpmyadmin og Apache Web Server. Gruppen har sett på hvordan vi skal få synkronisert offline databasen med online databasen på en automatisk måte. Det står en fyldig gjennomgang på nettet (MySQL Developer Zone, udatert). Men siden vi jobber på skoleservere og oppdragsgiver ikke har en egen server satt opp enda, så mangler vi rettigheter til å få synkronisert dette av seg selv. Det må derfor bli i fremtiden. Det finnes allikevel en måte å få det synkronisert på per dags dato. Man må da passe på at man hele tiden oppdaterer phpmyadmin databasen og serverdatabasen etter brukt. Hvis man vet at man i helgen må bruke offline versjonene, må brukeren importere den siste versjonen fra serverdatabasen, inn i phpmyadmin. Man kan da søke i siste data, samt legge inn nye innlegg. Det viktige er da at man eksporterer offline databasen når man er ferdig, og legger den inn i serverdatabasen før man gjør noe online igjen. Selv om dette fungerer, ser vi at dette er en tungvint metode, og man kan fort ende opp med å miste innlegg. 21
4 Samsvar mellom kravspesifikasjon og produkt Kravspesifikasjonen er beskrevet i en egen rapport. 4.1 Samsvar med kravspesifikasjonen Oppgaven stemmer rimelig godt overens med kravspesifikasjonen. Den har noen avvik på terminologi og bestemmelser. For eksempel kan vi se at det står "Administrator skal kunne opprette, endre og slette brukere". En administrator kan gjøre alle de nevnte oppgavene, men det kan også en vanlig bruker, så det gjelder mer enn bare en administrator. Men hvis databasen skulle være tom (uten brukere), så ville kun en som har tilgang til koden kunne legge til brukere. Det står også at man skal kunne søke etter sted og rangering. Dette oppfyller vi, men vi har lagt til at brukeren også kan søke på temperatur og snøtype. Gruppen har ikke målt om det er mer eller mindre tidkrevende å bruke nettsiden enn penn og papir. Men vi har fått gode tilbakemeldinger fra oppdragsgiver om at databasen vil bli tatt i bruk. Offline/online funksjonen fungerer, men krever at bruker har installert og kjører programmet XAMPP, med Apache Web Server og phpmyadmin for bruk offline, som nevnt i avsnitt 3.5.1 Hjelpeverktøy. Systemet kan benyttes på de nevnte nettleserne i kravspesifikasjonen. Den fungerer på PC og Mac. Den fungerer på ipad. Gruppen har hatt problemer med at bakgrunnsbildet ikke er skalert på mobil, og informasjonsboksen som kommer opp når man trykker på spørsmåltegnet på registrer innlegg siden oppfører seg ikke helt som på web, men uten at det skaper noen store problemer. Alle funksjonene virker ellers som de skal på mobil. Testet på AsusTablet (Android), også der er bakgrunnsbildet litt i ubalanse. 22
Nettsiden krever brukernavn og passord, disse blir tildelt av en administrator eller en annen bruker. Dette sikrer mot at alle kan få innsyn i tabellene. Men sikrer IKKE mot at smørerne ukritisk kan låne bort brukernavn og passord, og det på den måten kan spre seg. Hvis man skulle klart å få innsyn til der dataene ligger lagret, er passordet hashet slik at det ikke kan stjeles. Gruppen har også lagd en SQL-kode som sletter alle data på siden hvis en administrator skulle ha behov for å kjøre den. 23