PRODUKTDOKUMENTASJON

Transkript

1

2 PROSJEKT NR.: Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: Telefaks: PRODUKTDOKUMENTASJON HOVEDPROSJEKTETS TITTEL: Dekklåven DATO: 31. mai 2008 ANTALL SIDER / BILAG: PROSJEKTDELTAKERE: Chau Quoc Do, Einar Drivdal, Nikolai Godager og Kevin Holmvik INTERN VEILEDER: Steinar Johannessen OPPDRAGSGIVER: Dekklåven KONTAKTPERSONER: Dag Terje Bjørlo tlf: SAMMENDRAG Denne rapporten inneholder dokumentasjon som har blitt produsert i forbindelse med hovedprosjektet våren 2010 ved Høgskolen i Oslo, avdeling for dataingeniør. Den tar for seg et nettbasert system for Dekklåven og skal kunne bestille dekk og felger, reservere servicetimer og dekkhotell. Dekkhotell er en selvstendig applikasjon som tar for seg av lagring av dekk. STIKKORD: Nettbutikk, Reservasjon av servicetimer, Dekkhotell

3 1 FORORD Dette produktet er en beskrivelse av systemet vi har laget i forbindelse med hovedprosjekt ved Høgskolen i Oslo, avdeling for dataingeniør. Hensikten med et produktdokument er for å beskrive oppbygging og virkemåte for systemet. Dette dokumentet er ment for de som skal videre utvikler, vedlikehold og lære bort. I produktdokumentet har vi prøvd å skrive så detaljert som mulig, for å kunne vise hva vi ha utviklet gjennom hele prosjekt perioden. Dokumentet vil blant annet inneholde om programmets virkemåter, et detaljert gjennomgang av programmet og databasen. Dette dokumentet er optimert for papirutskrift.

4 Innholdsfortegnelse 1 Forord Innledning Om bedriften Dagens situasjon Våre infrastrukturelle ønsker om endring Mål for prosjektet Samsvar mellom kravspesifikasjon og produktet Teknologi Beskrivelse av teknologi Dekkhotell Datastruktur Om dataflyten: Om databasen: Oppbygging og virkemåte for Dekkhotell Nettverkskalender Datastruktur OM DATAFLYTEN OM DATABASEN Oppbygging og virkemåte for Nettverkskalender To innledende paradokser Beskrivelse av klasser Beta testing Oppbygning og virkemåte for online reservasjon av timer Nettbutikk Planlegging Analyse av Visma Dataflyt Konklusjon

5 2 INNLEDNING I dette dokumentet vil du finne forklaring om produktet vårt for hovedprosjekt. Her vil du nærmere forklaring om hvordan vi ha klart å utvikle produktet. 3 OM BEDRIFTEN Dekklåven AS norskdrivende bedrift som leverer tjenester innenfor salg av dekk og felger, utfører dekkskift og lagring av dekk. Dekklåven AS ble etablert i Brummundal i 2002, og har i dag flere verksteder omkring Oslo området. I dag selger bedriften dekk og felger med importert fra Asia, og utgjør bare dekkskift for kundene. 3.1 DAGENS SITUASJON Dekklåven AS har i dag bare kjøp av dekk og felger ved lageret sitt, og dette krever ganske stor kapasitet av ansatte og mye manuelt arbeid. Ved lagring av dekk, har de i dag oppbevart informasjonen i et Excel-dokument og noe som gjør det lite fleksibelt. Håndtering av servicetimer, har de i dag måtte la kundene møte opp og la dem vente til det er ledig time. 3.2 VÅRE INFRASTRUKTURELLE ØNSKER OM ENDRING Forslag: Oppgrader internettabonnementet til en raskere linje Grunnlag: En lokal IIS server krever en rask og stabil linje for at nettbutikkbrukere skal kunne bestille varer. Resultat: Bedriftens lokasjon er mer enn 4km unna nærmeste DSLAM. Vi ser det som mest logisk å sette opp et replikasjonssystem mellom bedriftens database og webhotellets databaseserver. Forslag: Endre webhotell til UniWeb.no Grunnlag 1: Visma sin database er av type Microsoft SQL. Dersom vi skal replikere den er det av ytelsesmessige forhold en fordel å replikere den til en identisk database. Grunnlag 2: Vi ønsket å utvikle en online timebestillingsapplet i C# (.NET). Appleten må dermed kjøres på en Microsost IIS Resultat: Abonnementet hos uniweb ble opprettet. Forslag: Kjøp en lisens av Microsoft SQL Server Standard Edition Grunnlag1: Trigger/Prosedyre replikasjon er en treg og usikker måte å kopiere databaser på. Grunnlag2: SQL Server replikasjon fungerer ikke på SQLEXPRESS (krever minimum Standard Edition) Resultat: Lisens kjøpt. 2

6 4 MÅL FOR PROSJEKTET Målet for dette prosjektet har vært å utvikle et nettbasert system med wehshop, dekkhotell, servicebestilling, nettverkskalender og en ny hjemmeside. Med disse applikasjonene vil det kunne gjøre hverdagen til både de ansatte og kundene lettere for å nå bedriftens tjenester. Vi lagde noen hovedpunkter over hva vi hadde da til følgende mål for hver av oppgavene: Webshop o Skal kunne kjøpe fra hjemmeside. o Lager beholdning skal oppdateres når en kunde har handlet. o Det skal være mulig å betale med visa. o Bare autoriserte personer har tilgang til å hente ut ordrer. Dekkhotell o Skal la brukere kunne få muligheten til å registrere nye lagringsplass. o Et søkbart system for å finne lagringsplass. Reservasjon av servicetimer o Kunder skal ha muligheten til å reservere time hos Dekklåven. Nettverkskalender o Ansatte skal ha mulighet til å opprette/endre/slette reservasjoner o Skal kunne presentere data om hva som skjer nå og hva som skjer snart på en storskjerm i værkstedet. Hjemmeside o Skal være en oversiktlig side. o Siden skal være mest mulig brukevennlig. 3

7 4.1 SAMSVAR MELLOM KRAVSPESIFIKASJON OG PRODUKTET Etter flere måneder med programmering og planlegging har vi nå kommet frem til et sluttprodukt, vi selv er ganske fornøyd med resultatet. I produktet vil nå inneholde en ny hjemmeside, reservasjon for servicetimer, dekkhotell og nettverkskalender for håndtering av den administrerte delen. Om vi har klart å følge kravspesifikasjon, vil vi selv si at vi har klart det noen lunde. Vi har ikke klart å opprette en webshop for bedriften, siden det var litt problemer fra arbeidsgiveren vår fylle kravene for at en webshop skulle til. Siden en webshop var blitt skrevet i kravspesifikasjonen, er det bare de punktene som hører til webshop som ikke har blitt oppfylt. Dette har vi da tatt med vår oppdragsgiver, og vi selv har lovet bedriften å fullføre hele prosjektet når oppdragsgiveren har fått på plass kravene for å lage en nettbutikk. 4.2 TEKNOLOGI Siden oppdragsgiveren lot oss stå ganske fritt til å velge type teknologi vi skulle bruke, valget falt ganske fort at vi skulle bruke MS Visual Studio 2008 og Qt Creator. Grunnen til at vi har falt for valget av disse to, er for at vi bestemte å velge den plattformen vi følte oss mest trygg på og samtidlig fornye kunnskapene, 4.3 BESKRIVELSE AV TEKNOLOGI MS Visual Studio 2008 MS Visual Studio 2008 har vært til bruk for det meste i vårt hovedprosjekt, siden det er raskere og enklere å lage en nettbasert applikasjon. Dette er fordi MS Visual Studio inneholder mange ferdige kontroller og komponenter for funksjoner som ofte er brukt på en webside. I Figur XX vil det vise hvordan MS Visual Studio 2008 blitt tatt i bruk. FigurXX Skjermbilde av MS Visual Studio

8 MS SQL Server Management Studio Express Dette programmet, med det noe lange navnet, gir et grensesnitt mot databasene på serveren. Dette gjør det enkelt å sette opp en database med tabeller uten å måtte skrive koden i SQL. Qt Framework Qt er et brukergrensesnitt - rammeverk opprinnelig laget for C++. Det ble først utviklet av norske Trolltech før det ble overtatt av Nokia i Det inneholder en rekke biblioteker som gjør bl.a. UI - oppsett og databasebehandling enkelt. Qt Creator Qt Creator er programmet applikasjonen er laget med. Programmet er egentlig ment for å enkelt sette opp brukergrensesnitt. Det gjør man ved å dra de forskjellige enhetene ut på et brett og så genererer programmet kode for dette oppsettet. For denne applikasjonen er all kode skrevet selv, men programmet er brukt da det gir et fint grensesnitt som gir muligheten for å bruke en del snarveier og har en fin "gjettefunksjon" som gjør at det går raskere å kode. Figur 1 viser Qt Creator i bruk: 5

9 C++ C++ er et multiparadigme - programmeringsspråk videreutviklet fra C av dansken Bjarne Stroustrup. Det har bl.a. støtte for objekt - orientert programmering, noe som passer fint, da applikasjonen gjerne skal være mulig å videreutvikle. C# (C Sharp) C# er et programmeringsspråk for objektorientert programmering, er utviklet bla. for programmering i.net.(asp). C# er basert på programmeringsspråkene C++ og Java. SQL SQL, som de fleste mener står for Structured Query Language, er et databasebehandlingsspråk. Det har vært viktig å ha kjennskap til da applikasjonen benytter seg av databaser. 6

10 5 DEKKHOTELL 5.1 DATASTRUKTUR OM DATAFLYTEN: Fig OM DATABASEN: Fig 2 viser hvordan applikasjonen skriver og henter data fra/til databasen via en server via ODBC- grensesnittet. Databasens oppsett var viktig for hvordan applikasjonen skulle fungere. Den var derfor noe av det første som ble laget. Den har gjennomgått små endringer, men er i hovedtrekk lik føsteutkastet. Den ble først designet i Database Designer 4, et program det er enkelt å sette en E/R-modell opp i, vist i figur 3.1: 7

11 Fig 3.1 Databasen består altså av de fire tabellene Kunde, KundePlass, Plass og Lager. Til å sette opp databasen, definere tabellene og legge inn data brukte jeg MS SQL Server Studio Express. Skjermdumpene som kommer i neste segment er tatt derifra og viser tabellen med data fra testeprosessen som illustrerer hvordan det vil se ut når applikasjonen er i bruk. Jeg vil kort gå gjennom bakgrunnen for hver av tabellene: Kunde Fig 3.2 8

12 Tabellen vis i figur 3.2 er til for lagring av informasjon om kundene, som her mer konkret er personer som benytter seg av Dekklåvens tilbud om å lagre dekk for dem avhengig av sesong. Primærnøkkelen er Id, som gis automatisk av systemet (auto increment). Dette er for å ha en unik identifisering for hver kunde. Ellers lagres navn og nummer, som folk husker bedre enn en Id og som gjør at man kan komme i kontakt med kunden. Tabellen har en n:m-relasjon med tabellen Plass da en kunde kan ha flere lagringsplasser og en plass kan i tidens løp benyttes av forskjellige kunder. Plass Fig 3.3 I tabellen, som vises i figur 3.3, lagres informasjon man trenger å vite om en plass hvor et sett med dekk ligger. Et lager (Lager_Id) har et sett med plasser (Plass), som igjen har et undersett med plasser (UnderPlass). Kolonnen "Ledig" er av typen bit og kan inneholde verdiene 1 eller 0. Dette vises som True og False i Studio Express der de henholdsvis representerer 1 og 0, logisk nok. Disse to tabeller er koblet sammen ved hjelp av en database kalt KundePlass: KundePlass Fig 3.4 I tabellen som vises i figur 3.4, er plassen hvor kunden har fått lagret sine dekk beskrevet. Det kan se litt rått/grovt ut så i programmet vises navnet på kunden i stedet for Kunde_Id. Lager Tabellen Lager er enkel. Den har en kolonne, Id, som er primærnøkkel og settes automatisk. I tillegg har den en kolonne som heter "Kommentar", hvor man kan skrive en kommentar som gir mening for de som jobber der. For eksempel hvor lageret ligger/hvilket lager det er. 9

13 5.2 OPPBYGGING OG VIRKEMÅTE FOR DEKKHOTELL Programmet består av 4 hovedklasser som henger sammen som vist nedenfor: Fig 4 Pilene i figur 4 indikerer at klassene det pekes på ligger i klassene det pekes fra. Oppbygging og virkemåte Dialogen Dette er klassen hvor hovedbrukergrensesnittet ligger, vist i figur 5.1: Fig

14 Den består av en rekke layouts som er lagt i forholt til hverandre. Et eksempel: linjelayouten.addwidget(etternavn); linjelayouten.addstretch(); linjelayouten.addwidget(etternavnle); Her legges labelen "Etternavn" og LineEditen "etternavnle" etter hverandre horisontalt. Det samme skjer med "Fornavn" og "Tlf", som man kan se under "Søk:" i midten til høyre. Disse tre layoutene legges så i en layout for hele høyre segment: hoyrelayout.addwidget(knappeboks); hoyrelayout.addspacing(100); hoyrelayout.addwidget(soeklabel); hoyrelayout.addlayout(&linjelayouten); hoyrelayout.addlayout(&linjelayoutto); hoyrelayout.addlayout(&linjelayouttre); hoyrelayout.addstretch(); hoyrelayout.addlayout(&knapplayout); Knappene nedenfor den store tabellen som tar opp mesteparten av plassen skiftes ut etter hva som er naturlig i henhold til innholdet i tabellen. Dette endres ved at brukeren kan skifte mellom hva han vil se oppe i høyre hjørne. Radioknappene der er bundet sammen med metoder som endrer på oppsettet for Uiet: connect(kunde,signal(clicked()),dbv,slot(kundeview())); connect(kunde,signal(clicked()),dbv,slot(oppdater())); connect(kunde,signal(clicked()),this,slot(kundelayout())); Når kunde, som er navnet på radioknappen med tilhørende label "Kunde" blir trykket på, sender den ut signalet clicked(). Som jeg her binder sammen med metoden kundeview() og oppdater() fra DBView, som kort fortalt setter tabellen til å vise informasjon om alle kunder. Tilslutt binder jeg signalet til en metode i Dialogen som setter opp Layoutet slik at knappene passer overens med at det er info om kunder i tabellen. Tabellen er klassen DBView. DBView DBViews har Qt-klassen QTableView, som er en tabellklasse som kan inneholde og presentere forskjellige typer informasjon, som hovedwidget. Klassen inneholder fire forskjellige modeller som innehar informasjonen til hver av tabellene i databasen. En av dem er en QsqlRelationalTableModel, kalt model: model = new QSqlRelationalTableModel(this); model->settable("kundeplass"); model->setrelation(0,qsqlrelation("kunde","id","enavn")); model->setsort(0,qt::ascendingorder); model->setheaderdata(0, Qt::Horizontal, "Navn"); model->setheaderdata(1, Qt::Horizontal, "Plass"); model->setheaderdata(2, Qt::Horizontal, "UnderPlass"); model->setheaderdata(3, Qt::Horizontal, "Lager"); model->select(); 11

15 SetTable() angir hvilken tabell fra databasen den skal bruke. SetRelation setter en relasjon mellom tabellen og en annen tabell som har relasjon i databasen, slik at man kan representere informasjon fra begge tabeller på likt. Her blir det f.eks. Ssatt en relajson til "Kunde" og "Id" fra "Kunde" vises i stedet som "Enavn" fra samme tabell. Dette fører til at "Kunde_Id" i "KundePlass" blir vist som "Enavn" fra "Kunde". Informasjonen i modellen vises i QtableViewet kalt "view". Det skiftes enkelt mellom modellene ved å knytte modellen til viewet med metoden setmodel(). Klassen DBView inneholder også noen viktige metoder, bl.a. for å fjerne kunder fra databasen. Dette skjer i metioden fjernkunde(qmodelindex index). Hovedtrekkene i den er: QSqlRecord rec = kundemodel->record(index.row()); QsqlRecord trekker ut en rekke fra en av modellene, så de blir en kopi av en rekke i en av tabellene i databasen. Hvilken rekke dette er er avhengig av hvilken index som blir sent til metoden. Indexen som er indexen til den rekken som er uthevet i tabellen i det modellen blir kalt. FjernKunde blir kalt av at knappen "Fjern Kunde" trykkes på. Da blir indexen til den kunden som er valgt sent til metoden og informasjon om denne kunden havner i QsqlRecord rec. Brukeren blir først spurt om han virkelig vil slette brukeren, hvis ja går metoden videre for å sjekke om kunden som skal slettes har noen dekk på lageret: QString str = "Kunde_Id = "; str.append(rec.value(0).tostring()); model->setfilter(str); model->select(); Qstringen "Kunde_Id = " får lagt til seg første verdi i rec, som er Id til kunden som er valgt. Str er nå f.eks. "Kunde_Id = 11". setfilter(str) fungerer som en WHERE str i modellen og modellen vil etterpå inneholde info om kunden som har Id lik 11. Brukeren blir informert og bedt om å ordne opp i det dersom kunden han prøver å fjerne er registrert med dekk på lageret. Hvis ikke: str.remove(0,6); editmodel->settable("kunde"); editmodel->setfilter(str); editmodel->select(); editmodel->removerows(0, 1); editmodel->submitall(); "Kunde_" fjernes fra str og det blir satt som filter i modellen som nå inneholder tabellen "Kunde". Der blir den slettet med removerows(0,1) som sletter alle rader fra indeks null helt til én i tilfelle en feil skulle ha gjort at flere rader ble med. DBView inneholder en egen klasse som fungerer som et skjema for å legge til Kunder i databasen: 12

16 LeggTilKunde Fig 5.2 Klassen, hvis brukergrensesnitt er vist i figur 5.2, sitt mål er hovedsaklig å legge en kunde til i tabellen "Kunde" if(linediten->text().length()>0 && lineditto->text().length()>0 && linedittre->text().length()>0) { } modell->insertrow(0); modell->setdata(modell->index(0,1), linedittre->text()); modell->setdata(modell->index(0,2), linediten->text()); modell->setdata(modell->index(0,3), modell->submitall(); lineditto->text()); emit closing(); this->close(); Dersom alle feltene er fylt ut settes en tom rad inn i modellen som inneholder tabellen "Kunde". Den blir fylt med data fra feltene og det blir lagret til databasen med submitall(). 13

17 LEGGTILLAGERPLASS Fig 5..3 Denne klassen, vist i figur 5.3, gjør mye av det samme som LeggTilKunde. Man velger en ledig plass og trykker på en knapp "Registrér lagerplass" slik at vinduet kommer opp og man velger en person som skal ha lagerplassen med "Velg Kunde". Dersom det er en ny kunde benytter man seg av "Legg til ny kunde" som åpner opp et LeggTilKunde-vindu. Dersom vinduet blir lukket uten at man har valgt en kunde blir ingenting endret i databasen. Main Main er klassen hvor Dialogen blir instansiert og hvor applikasjonen blir koblet til databasen. Det skjer slik: QSqlDatabase db = QSqlDatabase::addDatabase("QODBC"); db.sethostname("localhost"); db.setdatabasename("dekklaaven"); db.setusername("admin"); db.setpassword("administrator"); Dette er koden jeg har brukt til å koble meg på den lokale databasen på maskinen min. Databasenavnet blir her navnet på ODBC-linken mellom applikasjonen og databaseserveren. 14

18 6 NETTVERKSKALENDER 6.1 DATASTRUKTUR OM DATAFLYTEN For å unngå å bruke unødvendige ressurser til oppdatering av C# sine datagridview (for presentasjon av inndelingsdata) valgte vi å mellomlagre all data som er presentert på skjermen via en timerfunksjon som kontinuerlig gjør nye spørringer mot databasen. Hvor rask oppdateringsfrekvensen mellom bufferen og databasen er valgte vi å legge som et radioknappalternativ ved pålogging hvor en kan velge mellom tilhørende valg: Puls Hastighet Notat Lav 5000ms Tilpasset for VPN Medium 500ms Rask 100ms Krever rask klient Vi fant det mest naturlig å presentere de ulike formene ved tabcontrols. For å gjøre utviklingen av designet mer fleksibelt lagde vi separate UserControls til hver tabpage som vi knyttet sammen I designerfilen som tabcontrolen lå I (HovedVindu.Designer). Generelt ønsket vi å bruke et nøytralt fargevalg på layotet. Vi ønsket å gjøre alle farge, font og størrelsesmessige innstillinger brukerspesifikke. Dette løste vi ved å opprette profilvariabler i program.resources som skriver til xml uten at en trenger å håndtere dette selv. Når brukeren avslutter applikasjonen lagres også vinduspossisjoneringen lokalt slik at den blir identisk ved neste oppstart. Applikasjonen er tilpasset 800x600 oppløsning som minimum, og skalerer seg dynamisk dersom skjermen er større i form av at de mest essensielle enhetene skaleres oppover. tabpage Navn Beskrivelse 1 Kalender Her lagres, endres og vises data i alle inndelingene. 2 Intradag Denne siden er konstruert for å vise historie/fremtidige poster på storskjerm 3 Inndelinger Her kan administratorbrukere opprette nye eller slette inndelinger. 4 Status For presentasjon av statistikk 15

19 Modellering og Design Selve kalenderen (til høyre på bildet) viser kun de dagene som er blitt generert under Inndelinger Funksjonalitet og Sikkerhet Applikasjonen skal være enkel å bruke samt logisk annlagt. Vi fikk relavtivt frie tøyler når det gjaldt utformingen så vi ønsket å begrense funksjonene til det minimale etter hva hver enkelt bruker har behov for. tabpage4 (Inndelinger, bilde under) Viser vår schedueler som genererer fremtidige inndelinger. Integritetsmessig er det viktig at det ikke skal være mulig å opprette 2 individuelle inndelinger som kolliderer. Vi har derfor lagt vekt på utfyllende feilbeskrivelser dersom tilfellet skulle oppstå. Under Instillinger er det flere spesifikke detaljer som kan endres, deriblant når en varsling skal intreffe for at ny generering må foretas. 16

20 6.1.2 OM DATABASEN Databasen ble designet med MS SQL Server Management Studio og inneholder 4 tabeller i relasjon, samt en spesifikk tabell [dbo].konfigurasjon som inneholder 40 kolonner med spesifikk informasjon over fremtidige inndelinger Databasen består av følgende tabeller: UserPrivelege, UserRole, Bestillinger og LanBrukere. 17

21 Bestillinger I Figuren XX vil du se hvilke attributter som har blitt opprettet, og hvordan de har blitt definert. Figur XX Definering av tabellen Bestillinger Tabellen bestillinger inneholder alle reservasjoner i kalenderen. For å opprette en reservasjon, har kunden muligheten til å opprette. Men det er ikke bare kunden som har muligheten til det, de ansatte har selv fri tillatelse for å opprette en reservasjon, enten det er via administratorverktøyet eller brukergrensesnittet på hjemmesiden. LanBrukere I Figuren XX vil du se hvilke attributter som har blitt opprettet, og hvordan de har blitt definert. Figur XX Definering av tabellen LanBrukere Tabellen LanBrukere 18

22 håndtere brukerinformasjonen til de som kan logge på administrasjonsapplikasjonen. 19

23 UserPrivelege I Figuren XX vil du se hvilke attributter som har blitt opprettet, og hvordan de har blitt definert. Figur XX Definering av tabellen UserPrivelege Tabellen UserPrivelege definerer de ulike privelegiumene en rolle kan ha. Tabellen UserRole binder en rolle til et sett med privelegier. I Figuren XX vil du se hvilke attributter som har blitt opprettet, og hvordan de har blitt definert. Figur XX Definering av tabellen UserRole. UserRole er en enkel tabell hvor det viser hvilke type roller det er i systemet, og hvilket tillatelse hver rolle har. Nettverkskalender 20

24 6.2 OPPBYGGING OG VIRKEMÅTE FOR NETTVERKSKALENDER TO INNLEDENDE PARADOKSER Det første paradokset vi møtte var at det er to ulike fremgangsmåter for å lage en nettverkskalender på, hru: Metode1: Generere SQL data on-the-fly Beskrivelse: Når en bruker velger en kalenderinndeling vil applikasjonen først se om dagen eksisterer, deretter vise dagen ved eksistens eller generere inndeling ved non eksistens. Styrke: 1. SQL databasen vil kun inneholde tabeller med relevant data. 2. Data I uendelig fremtid kan genereres (pr. definisjon også en svakhet) Svakhet: 1. Applikasjonen vil bli tregere siden det må kontrolleres om inndelingen eksisterer hver gang en ny dag skal vises. 2. Større databasetrafikk Metode2: Forhåndsgenererte inndelinger Styrke: 1. Switching mellom dager vil gå raskt. 2. Klientene trenger kun å ha tilgang til å oppdatere eksisterende poster. 3. Lettere å håndtere spesielle virkedager (i.e. bevegelige helligdager) Svakhet: 1. Store inndelinger vil kreve mye maskinkraft å generere. I.E: En bedrift åpner 0800 og stenger 1800, de ønsker 5min intervaller som skal utspennes over 2 forskjellige porter/betjeninger. Det gir oss følgende regnestykke: (10timer x (60/5) inndelinger pr.time) x 2 porter x 365dager x 3år = unike rader 2. Mye tomrom vil eksistere i databasen. Ved å konstruere begge strukturene fra begynnelsen av kunne vi konkludere med at metode2 var ytelsesmessig overlegen. I vårt testeksempel ble en dag med 20 inndelinger gjennomsnittlig lastet på 200ms ved metode 1 mot 25ms ved metode2. Se mer om hvordan forhåndsgenereringen blir gjennomført I punkt blabl # #QR#! R# FAS# # 21

25 6.2.2 BESKRIVELSE AV KLASSER Programmet består av en HovedVindu klasse inneholder en tabcontrol som initialiserer alle andre klassene ved en suksesfull pålogging. HovedVindu.Cs inneholder også funksjonaliteten som sprer seg over alle tabpagene, hru. print/søk/meny/avslutt samt filskriving for å lagre profildata (farge/font instillinger) lokalt til XML. Login.Cs Dette er en egen applikasjonsform som kalles fra HovedVindu.Cs før komponentene I HovedVindu.Cs blir initialisert. Dersom påloggingen er vellykket lagres det brukerrelatert data tilbake til ressursfilen Program.Resources som benyttes videre for presentasjon av riktig layout ihht. innloggedes rettigheter. UserControlKalender.Cs Dette er den første kontrollen som lastes etter en vellykket pålogging. Den inneholder litt over 2000 linjer med spesifikk data UserControlIntradag.Cs Denne klassen inneholder nødvendige metoder for presentasjon av intradagen til Storskjerm. Den ligger under tabpage UserControlInndelinger.Cs Her ligger alle metodene bak generering av inndelingsdata. UserControlStatus.Cs Inneholder en oversikt over bl.a. antall innloggede brukere, antall lagrede poster, dager igjenn før kalenderen utløper (før ny generering må foretas). SQLMetoder.Cs Her ligger det spesifikke sqlmetoder som er tilbruk i mer enn 1 klasse. Deriblant metoden sikkertekst(string s) som returnerer en bool som representerer om teksten som skal settes inn I databasen er injectionsikker. UserControllInnstillinger.Cs Denne UserControlen lastes via applikasjonsformen Instillinger.cs. Kontrollen inneholder innstillinger som berører alle de andre tabsidene. Properties.Resources Visual Studio sitt XML lager for brukerprofiler. 22

26 6.2.3 BETA TESTING Første betaversjonen vi installerte hos Dekklåven la vi inn med en oppdateringspeker mot vårt hjemmeområde på HiO. Under hele betaperioden publiserte vi nye versjoner hvor beta applikasjonen benyttet PULL prinsipp for å søke etter nye oppdateringer mot HiO ved oppstart. Vi anbefalte bedriften å fortsette den ordinære bokføringen av timebestillinger i exceldokumenter de første 2 ukene av testperioden Etter den første måneden begynte det å bli færre oppdateringer og vi fjærnet dermed linken mot HiO for at applikasjonen skal fremtre raskere ved oppstart. Vi brukte deretter Advanced Installer som installasjonsprogram og tilføyde en enkel EULA. 23

27 6.2.4 OPPBYGNING OG VIRKEMÅTE FOR ONLINE RESERVASJON AV TIMER Navigeringsmodell Figuren XX viser flyten i reservasjonssystemet. For å starte reservasjonen må kunden ha valgt en bestemt dato for å se når det er ledige reservasjoner. Kunden har hele tiden muligheten til å velge en annen dato til seinere tid. For videre reservasjon, må kunden da velge det tidspunktet som passer og den ledige plassen som er ledig på det tidspunktet. Når en bruker har valgt dato, tid og plass, vil det sende brukeren til neste steg hvor det blir å skrive kommentarer til verkstedet. For å foreta en reservasjon, må brukeren gjennomføre fire skjermbilder. Figuren XX viser hvordan navigering for reservasjon. Steg 1: Forside Når man har fått valgt Timebooking fra hovedmenyen, vil man komme til forside for reservasjon. Steg 2: Logg inn/registrere ny bruker Før en bruker kan velge dato for reservasjon, må bruke ha autorisert tilgang for å kunne reservere. Dette vil si at brukeren må enten være logget som kunde eller administrator. Hvis brukeren ikke har innlogging, kan brukeren eventuelt opprette en konto. Steg 3: Velge dato Her må brukeren velge en dato for å kunne navigere seg videre i prosessen. For at det skal bli reservert på samme dato som brukeren har valgt har det blitt bruke med følgende metode for å kontrollere at brukeren valgt riktig dato. Deretter vil den videre hente timeplanen for det valgte dagen. private void LoadData() { 24

28 if (! (calbestillingdato.selecteddate == DateTime.MinValue)) { // En validert dato har blitt valgt i kalenderen. Henter TimePlanen og binder den til TimePlan control. TimePlan1.DataSource = BestillingManager.GetValgAvTime(calBestillingDato.SelectedDate); TimePlan1.ValgtDato = calbestillingdato.selecteddate; TimePlan1.DataBind(); } } Steg 3: Velge tid og plass Etter å ha valgt en validert dato, vil brukeren bli sendt videre til timeplan hvor brukeren vil få en oversikkt over når det er ledige servicetimer på verkstedet.i Figuren XX er det et eksempel på hvordan en timeplan med en plan over ledige timer. 25

29 7 NETTBUTIKK 7.1 PLANLEGGING Vi begynte å planlegge nettbuttikken tidlig i prosjektet, og fikk tidlig øye på Visma sin egne netthandelløsning med navn Visma Zpider. Etter dialog med en av norges ledende Vismaforhandlere fikk vi en hyggelig pris på produktet og godkjent det av Dekklåven. Fordelene ved å ta ibruk Zpider var mange, deriblant at vi kan bruke Visma Global som de ansatte allerede kjenner til for å administrere store deler av nettbutikken. Noen dager etter dette kom fakturaen I posten med en pris som var på ett 6 siffret beløp og endte på 12ganger mer enn hva vi I utgangspunktet ble tilbudt. Lettere sjokkert tok vi kontakt med forhandleren og fikk høre at det var en prisøkning som Visma Norge hadde lagt på sin ehandelløsning og som de dermed ikke kunne gjøre noe med. Dette resulterte i at vi måtte begynne å se oss over gjerdet etter andre løsninger. Etter et kort møte med vår bedrift kom vi til enighet om at løsningen ble for dyr og at vi skulle forsøke å lage en egen løsning som leser ut nettbutikk relatert aktivitet fra visma. 7.2 ANALYSE AV VISMA Visma benytter Microsoft Sql Server til å holde kustus på dataene. Ved å logge seg på databasen via Management Studio kunne vi se følgende: 1. Databasen består av 389 forkjellige Tabeller og 51 ulike prosedyrer. 2. Relasjonene mellom tabellene er applikasjonshåndtert, de fremgår dermed ikke I databasen. Koneskvensen av dette er at vi må selv finne hvilken relasjoner som er skapt mellom de forskjellige tabellene som er nødvendige for å bruke en nettbutikk interaktivt mot Visma Global. For å finne hvor de nødvendige postene som er relatert til eshop legger seg begynte vi med å skape 1 ny artikkel med artikkelnr Når vi opprettet denne artikkelen la vi inn et bilde ved navn Image1.jpg som vedlegg til artikkelen. Deretter sjekket vi av for publiser på nett og tok en ny backup av Visma sin SQL database for å finne relasjonene. Ved å bruke en egen prosedyre for å gjennomføre et søk igjennom alle tabeller og tilhørende kolonner I databasen etter artikkel 3100 og bildenavn mini.jpg (se vedlegg 1 for prosedyre) fant vi følgende data: Funn etter Artikkel 3100: [dbo].dekklven.article.showonwebyesno (tinyint) ble endret til fra 0 til 1 Funn etter Bilde mini.jpg [dbo].dekklven.savedpictures.picturename (image) ble endret til mini.jpg Relasjonen til de 2 overnevnte fant vi I [dbo]. Dekklven.Event der Keyvalue (Artikkelnr) var linket med DocumentPointer (PictureId fra SavedPictures). Ved å fortsette søk etter bla. Enheter I lagerbeholdning, artikler I bestilling, kampanjepriser, enhetsvekt etc kunne vi tegne oss ett bilde av hvilken tabeller vi trenger å manipulere for å få Visma til å administrere hvilken artikler som skal publiseres på nett. 26

30 7.3 DATAFLYT De aller fleste som oppretter en egen nettbutikk mot en lokal database setter opp en egen server mot internet (heretter forkortet IIS). I dekklåven s tilfelle hvor de er begrenset til en 1024/256kbit linje vil dette være en dårlig løsning som videre fører til missfornøyde kunder. Alternativ A) Egen webserver Siden Dekklåven ikke har egen IIS og deres internettlinje er alt for liten til at det er aktuelt å sette opp en, fant vi kun èn fornuftig måte å opprette nettbutikken på. Via databasereplikasjon. Alternativ B) Replikert database 7.4 KONKLUSJON Under analysen av de andre tabellene vi trengte for å skape en komplett replikasjon fant vi ut at bedriften må foreta en ny fysisk lageropptelling av alle artikler i lagerbeholdningen, da artikler med beholdning i form av bokstaver eller negative tall er vanskelige å håndtere I en nettbutikk. Dette samt at alle artiklene må taes bilde av under samme lysforhold (fotoboks) var det ønskelig fra Dekklåven sin side å engasjere oss til å fullføre nettbutikken som en sommerjobb i tråd med at de skal oppgradere/bytte alle sine maskiner samt flytte kontorlokalene sine i nevnte periode. 27