Sluttdokumentet er delt inn i fire kategorier, og disse kan leses som selvstendige dokumenter:

Transkript

1 1

2 2

3 3

4 Forord Dette sluttdokumentet inneholder all dokumentasjon som er gjort i forbindelse med hovedprosjektoppgaven for utdanningen bachelor i ingeniørfag, data ved Høgskolen i Oslo Denne rapporten skal være tilgjengelig på vårt hovedprosjekts hjemmeside. Rapporten er optimalisert for papir. Sluttdokumentet er delt inn i fire kategorier, og disse kan leses som selvstendige dokumenter: Prosessdokumentasjonen beskriver arbeidsgangen i prosjektet, med fokus på arbeidsmetoder og teknologien som er benyttet. Produktdokumentasjonen beskriver de tekniske aspektene ved utviklingen av produktet. Testdokumentasjonen dokumenterer testingen av systemet, og er en bekreftelse på at vi leverer et fungerende produkt. Brukermanualen er skrevet for å gi en enkel innføring i produktet, slik at brukerne av systemet kan forstå hvordan det fungerer uten å måtte lese hele sluttdokumentasjonen. Vi ønsker å takke: Vår interne veileder, Emine Göcmenoglu, for godt samarbeid, tips og rådgiving gjennom hele prosjektet. Vår kontaktperson ved HiO, Tor Hasle, for positiv holdning, godt samarbeid og en helhjertet tro på prosjektet. Tor Krattebøl, ansvarlig hovedprosjekt, og foreleser med faglig kompetanse i.netteknologien, for teknisk innsikt, rådgivning og for uforpliktet å ha stilt seg tilgjengelig under hele prosjektet. Tore Øfsdahl, senioringeniør, for hyggelig innstilling og hjelp relatert til hardware. Høgskolen i Oslo, for å ha gitt oss muligheten til å utvikle dette systemet. Nam H. Lac Øzden Tasdelen Sami Sarinc Erlend Steen 4

5 Generell innholdsfortegnelse Forord... 4 Generell innholdsfortegnelse... 5 Prosessdokumentasjon... 7 Detaljert innholdsfortegnelse for prosessdokumentasjonen... 9 Produktdokumentasjon Detaljert innholdsfortegnelse for produktdokumentasjonen Testdokumentasjon Detaljert innholdsfortegnelse for testdokumentasjonen Brukermanual Detaljert innholdsfortegnelse for brukermanualen Vedlegg Use case modell Arbeidsplan Fremdriftsplan Brukerundersøkelse

6 6

7 Prosessdokumentasjon 7

8 Forord Denne rapporten inneholder dokumentasjon av prosessen og gruppens arbeid fra prosjektets start til slutt. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte finne det interessant. Det forventes at leseren av prosessdokumentasjonen har grunnleggende kunnskaper om datateknikk. Det vil si at leseren har kjennskap til programmering og systemutvikling. Hensikten med prosjektet har vært å utvikle et system som i hovedsak skal vise studentene hvor de forskjellige forelesningene foregår og i hvilke tidspunkt. Dette systemet har fått navnet RomSys fra dens utviklere. RomSys skal brukes på skjermer satt opp forskjellige steder på skolen, og vise reservasjonene for de gitte etasjene. For teknisk informasjon om RomSys henviser vi til produktrapporten. 8

9 Innholdsfortegnelse 1 Innledning Presentasjon Om bedriften Bakgrunn for oppgaven Hva er TimeEdit? Situasjonen ved prosjektstart Mål Rammebetingelser, hentet fra kravspesifikasjonen Utviklingsmetode Generelt om prosjektutvikling Om utviklingsprosesser Om utviklingsmetoder Om vårt prosjekt utviklingen av RomSys Forberedelser, planlegging og prosjektstyring Valg av hovedprosjekt (prosjektstart) Tilrettelegging fra oppdragsgiver Valg av løsning og teknologi Organisering Hjemmeside Prosjektstyring Anvendt programvare Microsoft Visual Studio Microsoft Expression Blend Microsoft SQL Server Anvendte rammeverk og programmeringsspråk ASP.NET, C# og Silverlight XML LINQ Regular Expression Windows PowerShell IIS Fremdriftsplan og arbeidsplan Kravspesifikasjon

10 4.1 Om bakgrunnen Hensikten med kravspesifikasjoner Kort systembeskrivelse Timeplan Nyheter Annet Eventuelle krav til systemkonstruksjon (tekniske krav) Utvikling Drift Utstyr Eventuelle krav til dokumentasjon Utviklingsprosess og gjennomføring Kravspesifikasjonens rolle i utviklingsprosessen Use Case-modellens rolle under utviklingsprosessen Veiledning og samarbeid Presentasjonsmøte med veileder, oppdragsgiver og faglærer i.net TimeEdit i vårt prosjekt Hovedutfordringer Innsamling av data Knytte Silverlight til database Iterasjonsbeskrivelse Iterasjon Iterasjon Iterasjon 1-ii Iterasjon Iterasjon Iterasjon Iterasjon Oppsummering Produkt Prosess Kilder

11 1 Innledning 1.1 Presentasjon Tittel: Visning av romfordeling Oppgave: Utvikle et program som henter data fra TimeEdit, og viser dette på skjermer fordelt rundt på skolen. Periode: 30. okt mai 2010 Gruppemedlemmer: Nam H. Lac, s (3AB) Sami Sarinc, s (3AB) Erlend Steen, s (3AB) Øzden Tasdelen, s (3AB) Prosjektgruppe: Intern veileder: Oppdragsgiver: Kontaktperson: Emine Göcmenoglu Høgskolen i Oslo Pb 4 St. Olavs plass, 0130 Oslo Tlf: E-post: postmottak@hio.no Thor E. Hasle E-post: Thor.Hasle@iu.hio.no Tlf: Om bedriften Høgskolen i Oslo (HiO) ble opprettet 1. august 1994 og er landets største statlige høgskole. HiO har over studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelorstudier og 18 masterstudier. I tillegg tilbyr skolen et doktorgradsprogram i profesjonsstudier. Flere av høgskolens utdanningstilbud er HiO alene om å tilby i Norge. HiO satser på internasjonal utveksling. Forskning er vektlagt, og mye av fag- og forskningssamarbeidet skjer på internasjonalt nivå. 1.3 Bakgrunn for oppgaven Hva er TimeEdit? TimeEdit er en frittstående kommersiell aktør som leier ut bookings- og planleggingssystem til Høgskolen i Oslo. 11

12 Dette systemet består av: En database som kjører på TimeEdit-klienter som er installert hos enkelte brukere slik at de kan koble seg til databasen. WebTimeTables som viser timeplaner og reservasjoner på en web-side. WebReservations som benyttes til å reservere utvalgte rom både for studenter og tilsatte. Avdelingens timeplanleggere/kursplanleggere må ha tilgang til TimeEdit ved et program / en klient, TimEdit-klienten. Brukerne opprettes manuelt av teknisk ansvarlig for TimeEdit. Nærmeste leder kontakter it-tjenesten for dette. Når en ny bruker opprettes får brukeren det vanlige HiObrukernavnet og -passordet også i TimeEdit. WebTimeTables er tilgjengelig for alle, og kan benyttes til å søke opp timeplaner for enkelte klasser, forelesere eller fag. Det kan også benyttes for å sjekke om rom er ledige. Hver avdeling har sin egen søkeprofil som gir tilgang til å søke i avdelingens rom og klasser. De fleste avdelinger har linker på sin hovedside til "ferdige" timeplaner for sine klasser WebReservations benyttes til å reservere utvalgte auditorier, klasserom, møterom og grupperom. Hvilke rom som er tilgjengelig for reservasjon avgjøres av avdelingen. Noen rom er tilgjengelig for alle, noen for en enkelt avdeling, noen for tilsatte og noen for studenter. Web reservasjoner skal ikke benyttes for timeplanlegging, men for reservasjon av rom for en kort periode. Situasjonen ved prosjektstart Høgskolen har mange elever og tilbyr undervisning i en rekke forskjellige fag. Derfor er det behov for en oversikt over hva som til enhver tid foregår i de ulike undervisningslokalene, slik at studenter på skolen når som helst kan finne denne informasjonen. Per dags dato finnes det ingen løsning av den typen som er gitt oss i oppdrag. De studentene som i dag vil søke opp undervisningsinfo, må benytte en webside som gir enkelte visningsalternativer. Studenter mener at denne løsningen er mangelfull og vanskelig å bruke, og mange lar derfor være å benytte seg av den. Alle romreservasjoner gjøres på TimeEdits side. For å gjennomføre en reservasjon må du først finne et ledig grupperom i ønsket tidsintervall. Det som gjør denne siden vanskelig for mange studenter er nettopp det; Det finnes ingen søkefunksjoner for ledige grupperom. Studentene må gå inn og se på hvert enkelt rom i systemet for å se om det er ledig for reservasjon. Den eksisterende romreservasjonssiden er vist i figur 1. Vår applikasjon skal forenkle situasjonen for studenter som trenger å sette seg på et grupperom. De skal enkelt kunne se hvilke rom som har blitt reservert og hvilke som er ledige ved å bruke vårt system. Systemet er selvfølgelig ikke bare basert på problemet med å finne et ledig grupperom, men vil også være en hjelp til å finne ut hva som til enhver tid skjer i undervisningslokalene. 12

13 Figur 1: Viser alle reservasjonene til det valgte grupperommet. 1.4 Mål Hovedoppgaven til applikasjonen er å vise studentene hvor de forskjellige forelesningene foregår og i hvilke tidspunkt. Ettersom det oppstår store problemer med å finne ledige grupperom på skolen, ønsker vi å bruke et avgrenset felt i applikasjonen til å vise studentene reservasjonsstatusen for grupperommene i området. I tillegg ønsker vi å ha en nyhetsoversikt på siden, for eksempel ved hjelp av en RSS feed. Hovedmål som vi vil oppnå som en gruppe i løpet av prosjektet: Få erfaring med å gjennomføre et stort prosjekt. Få erfaring med å dokumentere et omfattende system. Få erfaring i å samarbeide med en reell oppdragsgiver. Lære å sette opp server. Få erfaring gjennom løsing av de problemene som vil oppstå under utviklingen av systemet. 1.5 Rammebetingelser, hentet fra kravspesifikasjonen Som utviklingsspråk har vi valgt C# kombinert med ASP.NET og Silverlight. Utviklingsplattformen vi har valgt er.net, siden vi nylig har gjennomført et kurs i web-applikasjoner hvor vi brukte dette verktøyet. Vi føler at det er i dette verktøyet gruppen har størst forråd av kunnskaper, og valget falt på.net med denne begrunnelsen. Løsningen vår vil være web-basert, og bestå av én sentral Windows-server som mater en eller flere klienter, heretter kalt stasjon. Stasjonene vil bli den synlige delen av applikasjonen, og skal bestå av en liten maskin med skjerm. Det kreves ikke noe annet av stasjonene enn internettilkobling og en 13

14 nettleser som støtter Silverlight. All prosessering skjer i serveren, og informasjonen sendes ut til stasjonene via internett eller gjennom skolens eksisterende nettverk. Serveren er en maskin satt opp med Windows XP Professional SP3, konfigurert med IIS og med Microsoft SQL Server C# har mange forhåndsdefinerte ressurser, og det er derfor et allsidig språk som er enkelt å bruke i web-baserte løsninger. Det er også et objektorientert programmeringsspråk som er relativt likt Java, som vi har jobbet med i undervisningssammenheng gjennom 3 semestre. Gjennom utviklingen benytter vi programmer som er kommersielle, og ville normalt være nødt til å løse ut lisenser fra Microsoft for å skrive applikasjonen. Imidlertid er Høgskolen i Oslo medlem av et samarbeid, MSDNA (Microsoft Developer Network Academy), som gir studentene tilgang til en rekke Microsoft-produkter for bruk i undervisningssammenheng. Det var derfor mulig for oss å skrive applikasjonen i Visual Studio 2008, et program som vi alle er fortrolige med. Problemstillingen til denne oppgaven går ut på at vi skal hente ut informasjon fra TimeEdit, som er skolens eksterne leverandør av timeplanløsninger. TimeEdit er en kommersiell bedrift, og av forståelige grunner får vi ikke full tilgang til deres systemer. De har heller ikke en eksisterende løsning for å gi oss begrenset tilgang til systemet, og har ingen planer om å lage en slik løsning innenfor den tidsrammen vi har for prosjektet. Det har derfor vært en utfordring å få hentet ut den informasjonen vi trenger i henhold til oppgavens problemstilling, og vi var nødt til å finne en alternativ løsning på dette. 2 Utviklingsmetode Prosjektgruppen består av 4 studenter som har jobbet mye sammen gjennom hele studiet. Vi kjenner hverandre godt, og vet om egne og hverandres sterke og svake sider. På grunnlag av erfaringer fra tidligere prosjektarbeid sammen, har vi utarbeidet vår egen måte å jobbe på. Vi har plukket elementer fra ulike utviklingsmetoder, og kommet fram til en modell som vi mener fungerer veldig bra for vår prosjektgruppe. Her vil vi først forklare litt om utviklingsmetoder og -prosesser som har vært til inspirasjon for oss, og deretter forklare hvordan vi har brukt ulike metoder i utviklingen av vårt prosjekt. 2.1 Generelt om prosjektutvikling En utviklingsprosess baserer seg vanligvis på en utviklingsmetode. Grovt sett kan forskjellige utviklingsmetoder deles inn i lettvektsmetoder og tungvektsmetoder. Lettvektsmetoder passer best for mindre prosjekter med relativt liten bemanning og relativt kort varighet. XP (extreme Programming) trekkes ofte fram som eksempel på en lettvektsmetode. Tungvektsmetoder er motsetningen, og passer best for større prosjekter med relativt stor bemanning (eventuelt delt opp i flere team) og lengre varighet. RUP (Rational Unified Process) er mye brukt som eksempel på en tungvektsmetode. 2.2 Om utviklingsprosesser En sekvensiell utviklingsprosess bygger på at man gjør seg helt ferdig med hvert steg i utviklingen før man går videre til neste steg. Hele prosessen består av én sekvens delt opp i flere steg som gjøres 14

15 ferdig hver for seg. Et av de enkleste eksempler er en prosess som først tar for seg analyse, deretter design, så koding, og til slutt ferdigstilling/utplassering. En iterativ utviklingsprosess kjennetegnes av gjentakende metodikk man gjentar en tidligere sekvens med metodesteg. Prosjektets første fase kan være bygget opp som en sekvensiell utviklingsprosess, men skal resultere i en tidlig prototype. Deretter går denne prototypen gjennom en eller flere gjentakende faser hvor produktet evalueres, testes og forbedres. En inkrementell utviklingsprosess er delt opp i iterasjoner, og bygger seg derfor større gjennom gradvis utvikling. I hver iterasjon baserer utviklingen seg på det arbeidet som ble gjort i forrige iterasjon. Gangen i produktutviklingen blir da som følger: Analysere noe, designe noe, kode noe, analysere mer, designe mer, kode mer, analysere enda mer, designe enda mer, etc. Inkrementell integrasjon (eller iterativ og inkrementell utvikling) er en utviklingsprosess hvor kode blir skrevet og testet i små enheter (ofte kalt units), og deretter satt sammen til et fullstendig produkt ved å legge til ett element om gangen. 2.3 Om utviklingsmetoder (Den forenklede) fossefallsmodellen er strengt sekvensiell. Den er normalt beskrevet som én sekvens bestående av de fire stegene analyse, design, koding og ferdigstilling. Fossefallsmetoden slik den vanligvis blir framstilt tar utgangspunkt i at man ikke går tilbake til et tidligere steg etter at det er ferdigstilt, og den blir derfor kritisert for å ikke ha noen vei tilbake, altså at man ikke kan endre på ting som er gjort i et tidligere steg. Figur 2: Forenklet fossefallsmodell 15

16 Den opprinnelige fossefallsmodellen var mer kompleks og hadde flere steg enn den forenklede framstillingen. Den åpnet også for å gå tilbake til et tidligere steg dersom man så et behov for å gjøre endringer, selv om også den i utgangspunktet var sekvensielt konstruert. Figur 3: Opprinnelig fossefallsmodell RUP (Rational Unified Process) er en sterkt definert sekvensiell utviklingsmetode, men den skiller seg fra fossefallsmodellen hva gjelder innholdet i hvert steg. RUP har fire definerte faser (steg), hvor hver fase skal resultere i en ny versjon eller prototype av programmet, og prosessutviklingen skal foregå som en iterativ prosess. Framdriften styres av milepæler, hvorav de viktigste er overgangen fra en fase til en annen. XP (extreme Programming) prøver å redusere kompleksiteten med å følge en spesiell utviklingsprosess. Det er et mål å gjøre minst mulig unødvendig dokumentasjon, og på dette punktet er XP et motstykke til den omfattende dokumenteringen RUP skal resultere i. XP bygger på inkrementell utvikling, og det er stor åpning for å gå tilbake og endre på tidligere implementerte funksjoner. Det er stort fokus på personlig motivering og at alle programmererne skal ha en eierskapsfølelse til produktet som utvikles. Spiralmodellen kombinerer sekvensiell og iterativ utvikling ved at den består av en rekke iterasjoner, hvor hver enkelt har et sekvensielt forløp. En av fordelene som oppnås med dette, er redusert risiko gjennom at man tidlig får et fungerende produkt med få funksjoner, og prosjektet kan dermed avsluttes på kort tid og uten for store tap. Ulempen med spiralmodellen kan være at det blir vanskeligere å si nøyaktig hvor lang tid det vil ta før produktet er ferdig utviklet, og det kan derfor være en økonomisk risiko knyttet til denne løsningen; Tid er som kjent penger. 16

17 Figur 4: Spiralmodell Timeboxing, eller tidsstyring, er en måte å begrense den økonomiske usikkerheten ved utvikling etter spiralmodellen. Denne metoden bygger på at utviklerne får en definert tidsperiode til rådighet, og kunden angir et ønske om hvor mye funksjonalitet produktet skal inneholde. Rekker utviklerne ikke å implementere all funksjonaliteten innenfor den gitte tidsrammen, leveres produktet imidlertid med den grad av funksjonalitet som den tilgjengelige tiden strakk til for. Bruk av timeboxing gjør det mulig, allerede før prosjektet starter, å komme til enighet om en fast pris for det ferdige produktet, så lenge kunden er tilfreds med å motta det produktet som leveres etter endt tid. For noen oppdragsgivere er det enda viktigere at timeboxing gjør det mulig å bestemme et absolutt tidspunkt for lansering av produktet. Man kunne tenke seg at et flertall av alle prosjekt burde sorteres under kategorien timeboxing, siden de fleste opererer med en tidsfrist. Noen av prosjektene tillater imidlertid forskyving av denne tidsfristen, selv om det sannsynligvis vil være uheldig for prosjektets økonomi. Ekte timeboxing har derimot en absolutt frist, og det gjelder å skape et best mulig produkt før fristen går ut. De fleste skoleprosjekt (herunder dette hovedprosjektet) er av typen ekte timeboxing, og resultatet blir vurdert ut fra hva som er levert innen tidsfristen. 2.4 Om vårt prosjekt utviklingen av RomSys Vi har hatt som utgangspunkt at prosjektet skal utvikles med inkrementell integrasjon. Prosessen ble planlagt som 6 iterasjoner (noe som senere ble endret til 7, da vi fant ut at prosessen ble mer oversiktlig av å dele opp iterasjon 1 og heller behandle den som to enkeltstående iterasjoner.) Hver iterasjon er en egen enhet når man snakker om inkrementell integrasjon, og følgelig ble de enkeltvis testet og implementert i applikasjonen. Av praktiske årsaker fant vi det i enkelte tilfeller hensiktsmessig å arbeide med flere applikasjoner parallelt, men de ble likevel implementert enkeltvis og etter numerologisk rekkefølge. Ved prosjektstart hadde gruppen en overordnet planleggingsfase før det vi regner som utviklingsfasen. Denne overordnede planleggingen var nødvendig med tanke på at vår oppdragsgiver 17

18 hadde et ønske og en idé, men ingen definerte krav til funksjon. Det var derfor viktig å få en større oversikt og grovmasket definisjon av selve oppgaven før vi kunne tenke på utvikling av en applikasjon. I denne fasen hadde vi tidvis hyppige møter med HiO som oppdragsgiver, og her fikk vi blant annet greie på at høgskolen mente vi som prosjektgruppe stod veldig fritt til å ta avgjørelser angående applikasjonen. HiO mente at vi, som selv var studenter, visste best hva som ville være til nytte i en applikasjon som først og fremst skulle bli et hjelpemiddel for studentene ved høgskolen. Likevel har det vært viktig for oss å ha en dialog med oppdragsgiveren gjennom hele prosjektet, og de større avgjørelsene ble gjort ved at prosjektgruppen forklarte situasjonen til oppdragsgiver og la fram et forslag til løsning, mens oppdragsgiver på bakgrunn av dette har tatt selve avgjørelsen. Etter den overordnede planleggingsfasen, kom det vi har valgt å kalle utviklingsfase. Denne startet igjen med en planlegging, definisjon av kravspesifikasjoner og skissering av funksjonalitet. Imidlertid hadde vi fokus på tidlig programmering framfor tidlig dokumentasjon en idé som blant annet er uttrykt i utviklingsmetoden AUP (Agile Unified Process) og det var derfor bare de nødvendige styringsdokumenter som hadde hovedprioritet før programmeringen kunne starte. Det som kan kalles programmeringsfasen, har på mange måter også inneholdt planlegging og evaluering; Vi har tatt utgangspunkt i spiralprinsippet innenfor hver iterasjon planlegging, koding og evaluering, og eventuelt gjentagelse av disse tre punktene dersom iterasjonen ikke er klar til å implementeres. Iterasjonene har blitt lagt til applikasjonen i numerologisk rekkefølge, men samtidig har vi vært åpne for å gå tilbake og forbedre en tidligere iterasjon i de tilfellene et slikt behov har meldt seg. Etter implementering av hver iterasjon har vi testet hele systemet med de nye funksjonene. I tillegg ble hver funksjon i den grad det lot seg gjøre testet før implementering. Parallelt med programutviklingen, har vi arbeidet med den tilhørende dokumentasjon. Det har for oss vært et mål å unngå dokumentasjon som ikke tjener noe formål, i tråd med tankegangen man finner i utviklingsmetoden XP. Samtidig er prosjektet utført som bacheloroppgave / hovedoppgave i et studium ved HiO, og dette legger noen føringer for hva slags dokumentasjon som må medfølge. Vi har fått en dokumentasjonsstandard som skal følges, og selv om denne er åpen for individuelle tilpasninger, inneholder den retningslinjer man må ta hensyn til. Den første iterasjonen (iterasjon 0) inneholdt nødvendigvis en betydelig andel planlegging og dokumentasjon; vi hadde behov for å skape en overordnet skisse av applikasjonen før den kunne utvikles. Samtidig kom vi tidlig i gang med utvikling av de funksjonene vi allerede her innså var nødvendige for et fungerende sluttprodukt. I de følgende applikasjoner kunne vi i større grad fokusere på programmering, selv om også disse startet med planlegging. Iterasjon 5, som var den siste iterasjonen, ble i stor grad satt av til testing av applikasjonen, til tross for at testing har hatt fokus gjennom hele utviklingsprosessen. Her ønsket vi å bruke tid til sluttesting av det ferdige systemet, for å forsikre oss om at det fungerte etter planen. I tillegg skulle iterasjonen brukes til ferdigstilling, det vil si alt avsluttende arbeid, eventuelle feilrettinger og visuell tilpasning. 18

19 3 Forberedelser, planlegging og prosjektstyring 3.1 Valg av hovedprosjekt (prosjektstart) Vi i prosjektgruppen har arbeidet sammen i forbindelse med gruppeprosjekter siden 1.klasse og visste at vi ville få et godt samarbeid. Vi hadde derfor lyst å danne hovedprosjektgruppen sammen, og gjøre et mest mulig effektivt arbeid ut av det. I første omgang hadde vi ingen planer om hvem vi skulle arbeide for, men utvikling av et WEB-system med kombinasjon av flere språk kunne være et relevant oppdrag for oss. Det gikk ikke så langt tid før vi ble enige om oppgaven. Kort tid etter at prosjektforslagene var lagt ut på hovedprosjektsiden, hadde vi møte som prosjektgruppe. Her diskuterte vi ulike oppgaver vi kunne tenke oss, både internt gitte (fra HiO) og eksternt gitte (fra andre bedrifter). Oppdraget visning av romfordeling stod blant de prosjektforslagene som er gitt fra Høgskolen i Oslo, og dette syntes vi virket interessant. Dette var et reelt prosjekt som man kunne ha fått i arbeidslivet. Gruppen ønsket å utvikle et WEB-system med kombinasjon av flere språk, og oppdraget tilsvarte våre ønsker. Med åpent krav om funksjonalitet kunne vi utvikle og designe produktet etter vårt eget ønske. Vi kontaktet først vår oppdragsgiver HiO v/kontaktperson Thor Hasle for å vite mer om oppdraget og om dets funksjonalitet og krav, og underveis i møtet bestemte vi oss for at vi ønsket dette oppdraget Kort tid etter samtalen med Thor Hasle, fikk vi beskjed fra HiO om at oppgaven var vår. Dette gikk i orden tidsnok til å levere en prosjektskisse innen den gitte fristen, 5.desember Oppdragsgiver hadde ikke formulert noen kravspesifikasjon, og derfor begynte vi å jobbe med dette rett etter nyttår. Allerede første uken av januar hadde gruppen et møte om planlegging av prosjektet, hvor vi blant annet diskuterte hvordan systemet skulle se ut og hvilken funksjonalitet det kunne inneholde. Uken deretter hadde vi vårt første møte med intern veileder, Emine Göcmenoglu. 3.2 Tilrettelegging fra oppdragsgiver I følge oppdraget vi har fått fra oppdragsgiveren, var oppgaven å etablere skjermer i hver etasje som viste hvilke rom som skulle brukes av hvem og når. Det skulle da utvikles en applikasjon som leste data fra TimeEdit og viste disse på hensiktmessig måte på en eller flere skjermer per etasje. Men akkurat hvordan systemet skulle se ut var opp til oss Vi sto ganske fritt til å utforme annen funksjonalitet og bestemme utseende på det ferdige produktet. Oppdragsgiveren ba oss komme med egne løsninger og forslag til funksjonalitet, valg av teknologi og plassering av skjerm. Vi avgjorde i stor grad selv hvilke funksjonaliteter som ville være hensiktmessig for vår applikasjon. Applikasjonen skulle etter ønske fra skolen være åpen for videreutvikling på et senere tidspunkt. 3.3 Valg av løsning og teknologi På den måten oppgaven vår var definert la oppdragsgiver ingen føringer for valg av teknologi, og det var i stor grad opp til oss hvordan det ferdige produktet skulle se ut. Oppgaveteksten var som følger: Ingeniørutdanningens ledelse har ytret ønske om å etablere skjermer i hver etasje som viser hvilke rom som brukers av hvem når. Det må da utvikles en applikasjon som leser data fra TimeEdit og som viser disse på en hensiktsmessig måte på en eller flere skjerm per etasje. Etter å ha spurt oppdragsgiver om dette, fikk vi vite at de ikke hadde noen krav eller ønsker om hvilken plattform applikasjonen skulle leveres i, så vi som prosjektgruppe sto helt fritt til å velge 19

20 teknologier og programmeringsspråk. Oppgaveteksten gir også stor grad av frihet til programutviklerne, men det kommer fram at løsningen må være tilknyttet internett. TimeEdit er skolens eksterne leverandør av timeplanløsninger, og de har en nettside hvor man kan få listet opp nødvendig informasjon for den nærmeste tiden. Med dette grunnlaget var det naturlig å bruke en web-basert løsning, og vi valgte da å bruke.net som plattform..net er en samling av teknologier rundt programvareutvikling fra Microsoft, og er i dag en av de mest brukte utviklingsplattformene i verden. Dette passet bra med vårt læringsmål, som var å få større kunnskaper om en mye brukt og ettertraktet teknologi. En positiv bieffekt av dette er at produktet er enkelt å videreutvikle ved en senere anledning, med tanke på at det finnes et stort antall programmerere med.net-kompetanse. I tillegg hadde vi i prosjektgruppen nylig gjennomført et kurs som omhandlet.net-teknologien, og følte derfor at vi hadde grunnleggende kunnskaper om denne utviklingsplattformen. Det betyr på ingen måte at vi manglet utfordringer i arbeidet med prosjektet; Vi måtte lære nye måter å bruke teknologien på, og måtte også tilegne oss kunnskaper ut over det grunnleggende for å utvikle applikasjonen vår. Som programmeringsspråk var det naturlig å velge C# når vi skulle jobbe i.net-plattformen. Dette er et foretrukket språk når man arbeider med.net-teknologien, og prosjektgruppen hadde derfor vært borti språket i det nevnte kurset. C# er et allsidig programmeringsspråk som er objektorientert og har likheter med Java. Programmering i Java hadde vi jobbet med i flere fag fordelt over 2 år, og med kunnskaper om dette språket var det lettere å tilegne seg ferdigheter i C#. ASP.NET er Microsoft sitt rammeverk for utvikling av dynamiske web-applikasjoner, og dette programmeringsspråket var en naturlig valg for presentasjonslaget i applikasjonen vår. Silverlight er et rammeverk som muliggjør integrering av multimedia, grafikk, animasjoner og interaktivitet i web-applikasjoner. Programmering i Silverlight gir produktutviklerne større muligheter til tilpasning av visuell fremstilling enn det som oppnås med vanlig HTML-koding. Med andre ord gir det oss mulighet til å tilpasse applikasjonens utseende på en måte som er uavhengig av ytre påvirkninger, som for eksempel hvilken nettleser brukeren velger å kjøre applikasjonen i. Løsningen vår består av én web-server og en eller flere klienter, heretter kalt stasjon. Stasjonene vil bli den synlige delen av applikasjonen, og skal bestå av en liten maskin med skjerm. Det kreves ikke noe annet av stasjonene enn internettilkobling og en nettleser som støtter Silverlight. All prosessering skjer i serveren, og informasjonen sendes ut til stasjonene via internett. Systemet er åpent, og det er i prinsippet mulig å vise applikasjonen på private hjemmemaskiner koblet opp mot internett, forutsatt at man kjenner URL-adressen applikasjonen ligger på. Det er derfor mulig for studenter å kjøre applikasjonen vår hjemmefra hvis skolen åpner for dette ved å frigjøre URL-en. Studentene kan da velge hvilken stasjon de vil se informasjon fra, og får se informasjon som finnes for den valgte stasjonen. Dette utgjør ingen risiko for systemet, i og med at studentene bare kan velge å vise forhåndsdefinert informasjon. All endring av systemet krever innlogging og kan bare gjøres av administrator. 3.4 Organisering Fasene i prosjektet med programmering og prosjektering, krevde en større og mer formalisert organisering av prosjektet i gruppen med tilhørende beslutnings- og ansvarsfordelinger. For å 20

21 arbeide i tråd med dette, utarbeidet vi en fremdriftsplan. Det skulle være lov å ligge foran i fremdriftsplanen, men det var ikke ønskelig å ligge bak denne. Alle på gruppen skulle holde seg orientert om prosjektets fremdrift og innhold. Hver tirsdag, onsdag og eventuelt torsdag, har vi hatt fast møtetid på HiO, hvor vi har arbeidet sammen i flere timer. For gjennomføring og kvalitetssikring av prosjektets innhold, har denne faste møtetiden vært svært viktig for hele gruppen. Vi førte ikke opp antall timer vi brukte til dokumentasjonen og til selve applikasjonen per dag, men dette prosjektet har hatt hovedfokus gjennom et helt semester. Andre fag vi hadde i tillegg til hovedprosjektet, måtte i noen tilfeller påvirke hvor mye tid vi brukte på dette prosjektet, men de har i liten grad hindret den generelle progresjonen. Enkelte dager har vi møttes på skolen for arbeidsøkter på opp til 10 timer, hvor vi kun har jobbet med hovedprosjektet. Det kan ha gått noe roligere enkelte uker, da andre fag periodevis har stilt store krav til økt arbeidsinnsats, men vi har hele tiden klart å holde oss innenfor fremdriftsplanen. 3.5 Hjemmeside Det var et krav fra skolen at vi skulle opprette en prosjekthjemmeside. Denne har vi etterstrebet å bruke til å holde oss selv og vår veileder oppdatert med informasjon. Vi opprettet en enkel og oversiktlig side, hvor ulike dokumenter ble vist etter kategori i en tabellform. 3.6 Prosjektstyring Prosjektdagboka har helt fra starten vært et ledende dokument. Den er kanskje ikke så veldig langt og detaljert, men tilskrekkelig nok til å gi oss informasjon om hva som til enhver tid har blitt gjort av gruppen gjennom hele prosjektperioden og eventuelt hvilke problemer som har oppstått For hvert møte registrerte vi dag, tid og sted, og det som var verdt å huske. På denne måten kunne veilederen følge utviklingen dag for dag med tenking, utvikling og resultater. Under dokumenteringen av denne prosessrapporten har vi hatt stor nytte av dagboka; Den har vært hovedkilden til resten av prosessdokumentasjonen siden alt var samlet og notert der. Kommunikasjonen har stort sett foregått over internett og SMS. Dokumenter har blitt sendt fram og tilbake på e-post, og beskjeder ble gitt på SMS. Vi så dette som en god løsning for å ta vare på dokumenter, og samtidig en måte å sikre at alle mottok de enkelte dokumenter. Siden vi er 4 i gruppen, fikk vi med andre ord 4 backup-er av det aktuelle dokumentet og sannsynligheten for at ting går tapt blir dermed mindre. 3.7 Anvendt programvare I tillegg til hovedmålet med prosjektet å lage en fungerende applikasjon for oppdragsgiver har det vært et mål at prosjektgruppen skulle få større kunnskap om bruken av relevant teknologi. For å utvikle vårt produkt RomSys har vi brukt den programvaren som er beskrevet her. Selv om vi kjente til all programvaren fra før, har vi gjennom prosjektarbeidet fått mye ny kunnskap om hvordan den kan brukes. All programvare vi bruker er proprietær (lisensiert) programvare fra Microsoft. Lisensene til disse programmene har vi fått fra MSDNA (Microsoft Developer Network Academy), et samarbeid som HiO er medlem av og som gir studentene tilgang til en rekke Microsoft-produkter for bruk i undervisningssammenheng. 21

22 Microsoft Visual Studio 2008 Dette er en IDE (Integrated Development Environment) for.net-rammeverket. Visual Studio inkluderer blant annet en code editor (skriveprogram for datakode) som støtter IntelliSense (Microsofts autofullfør-funksjon for skriving av datakode), en debugger (feilsøkingsfunksjon) og en kompilator, og denne programvaren har vært vårt viktigste verktøy under utviklingen av RomSys. SILVERLIGHT 3 TOOLKIT FOR VISUAL STUDIO 2008 SP1 Dette er en plug-in til Visual Studio som muliggjør bruken av Silverlight-kontroller og -verktøy i applikasjoner som utvikles med denne programvaren. Microsoft Expression Blend 3 Dette er en programvare for utvikling av grafisk brukergrensesnitt for web-applikasjoner. Det er et interaktivt WYSIWYG-verktøy for utforming av XAML-basert grensesnitt. (WYSIWYG står for What You See Is What You Get, og henspiller på at innholdet som vises under redigering er svært likt det endelige resultatet.) Microsoft SQL Server 2005 Dette er en databaseserver for relasjonsmodellerte databaser. Denne programvaren fulgte med installasjonen av Microsoft Visual Studio 2008, og derfor valgte vi å benytte dette databaseverktøyet. 3.8 Anvendte rammeverk og programmeringsspråk ASP.NET, C# og Silverlight ASP.NET er et rammeverk som er utviklet av Microsoft for å la programmerere bygge dynamiske web-applikasjoner. Dette rammeverket muliggjør utvikling med alle språkene i.net-teknologien. C# er et objektorientert programmeringsspråk som er foretrukket for.net-rammeverket. Silverlight er et rammeverk for web-applikasjoner, og integrerer multimedia, grafikk, animasjoner og interaktivitet i et enkelt kjøringsmiljø. XML Extensible Markup Language er et universelt og utvidbart markeringsspråk. XML muliggjør deling av strukturerte data mellom flere informasjonssystemer. Det brukes også til koding av dokumenter og for kommunikasjon mellom ulike dataformater. Formatet er vanlig tekstformat, og dette bidrar til at innholdet er leselig også for mennesker. LINQ Language Integrated Query er en komponent i.net-rammeverket som forenkler bruken av spørresetninger i.net-språkene. Ved å bruke LINQ, kan man unngå SQL-spørresetninger, og i stedet skrive spørringene i C#. Spørresetningene kan brukes til å søke opp, filtrere og hente ut data i databaser eller XML-filer. Ved å skrive spørresetningene i C# fremfor SQL, oppnår vi to fordeler: For det første eliminerer vi risikoen for SQL-injections; I tillegg oppnår vi bedre struktur ved å holde oss til kun å bruke C# i programkoden. Regular Expression Regular Expressions (regelmessig framstilling), refereres også til som regex eller regexp, tilfører i databehandling en kortfattet og fleksibel måte for matching av tekst. Regex kan identifisere spesielle bokstaver, ord eller et mønster av bokstaver. En regular expression er skrevet i et språk som kan 22

23 tolkes av en regular expression processor, et program som enten fungerer som en parser generator eller undersøker tekst og identifiserer deler som samsvarer med en gitt spesifikasjon. Regular expression brukes i mange tekstbehandlingsprogrammer, hjelpesystemer og programmeringsspråk til å identifisere og behandle tekst basert på mønstre. Skriptspråk som Perl, Ruby og Tcl har en regex-motor innebygd i sin syntax. Windows PowerShell Windows PowerShell er et oppgavebasert kommandolinjeskall og skriptspråk, som særlig er tiltenkt systemadministratorer. PowerShell inkluderer interaktiv prompting og et skriptmiljø som kan benyttes uavhengig. I lang tid har Windows fokusert på det grafiske grensesnittet, mens kommandolinjen og automatiseringsmulighetene med script ikke har hatt den høyeste prioriteringen. Løsningen som Windows tidligere hadde var svært avansert, og inkluderte mange uavhengige grensesnitt som ikke nødvendigvis fungerte på tvers av hverandre. Windows PowerShell er et mye mer komplett system, og er derfor en stor forbedring på dette punktet. PowerShell miljøet er like interaktivt som BASH, like programmerbart som Perl og produksjonsorientert. Dette er det beste av det beste. PowerShell er også bygd på.net, vi får dermed objekter til miljøet. Vi får referanser til prosessene, og med disse referansene kan vi jobbe med utdataene på en helt ny måte, hvor vi aktivt kan utføre handlinger på utdataene vi får. IIS Internet Information Services, tidligere kalt Internet Information Server, er en webserver-applikasjon og sett av funksjonsmoduler som er skapt av Microsoft for bruk med Microsoft Windows. Den er en av de mest populære webservere i verden. I mars 2010 betjente IIS 24 % av alle websider. Protokollene som støttes av IIS 7 inkluderer: FTP, FTPS, SMTP, NNTP og HTTP/HTTPS. 3.9 Fremdriftsplan og arbeidsplan Fremdriftsplanen ble satt opp tidlig i prosjektet. Sammen med denne ble det også utarbeidet en god, strukturert arbeidsplan som iterasjon for iterasjon viste arbeidet som skulle gjøres fra start til prosjektavslutning. Begge dokumentene er vedlagt. 4 Kravspesifikasjon Her gjengis kravspesifikasjonen i sin helhet, slik den har blitt nedtegnet tidligere i prosjektarbeidet. Talemåten her vil derfor kunne avvike noe fra den øvrige dokumentasjonen, og noe informasjon kan virke overflødig. 4.1 Om bakgrunnen Høgskolen i Oslo (HiO) er landets største statlige høgskole med studenter. HiO tilbyr både bachelor- og masterstudier, og ett doktorgradsprogram. Høgskolen har mange elever og tilbyr undervisning i en rekke forskjellige fag. Derfor er det behov for en oversikt over hva som til enhver tid foregår i de ulike undervisningslokalene. 23

24 Prosjektet skal resultere i et program som enkelt viser hva som til en hver tid skjer i et gitt område av skolen. Vi ønsker i tillegg å implementere en nyhetsoversikt i programmet. Programmet skal gjøre det mulig å sette opp skjermer som viser timeplanen for et område, for eksempel en gitt etasje. 4.2 Hensikten med kravspesifikasjoner Hovedhensikten med kravspesifikasjonen er å sette krav til funksjonaliteten for vårt produkt, RomSys. Kravene setter rammer og begrensninger, og vi får en oversikt over hvilke funksjonaliteter som skal implementeres. Tanken bak dette dokumentet er å gjøre det enklere for sensor og veileder å evaluere prosjektet. I tillegg vil det være et styringsdokument for oss gjennom hele prosjektarbeidet. Formulering av kravene har blitt satt underveis i prosjektet, både av oss og arbeidsgiver. 4.3 Kort systembeskrivelse Timeplan Sluttproduktet skal vise en timeplan, sortert på hvilket rom den aktuelle hendelsen foregår i. For forelesningssaler skal systemet vise informasjon om den nåværende forelesningen (fag, starttid, sluttid og hvor forelesningen foregår), samt en liste over de neste forelesningene som skal foregå i samme rom (med fag og start- og sluttid). For lab-rom (eksempelvis data-lab) skal det være en tilsvarende visning. I tillegg skal programmet inneholde en liste over grupperom, samt vise om disse er reserverte eller ledige. Nyheter Sluttproduktet skal ha en form for nyhetsvisning med nyheter som er aktuelle for HiO. Dette kan gjøres ved hjelp av en eller flere av HiOs egne RSS-feed. Annet Sluttproduktet skal inneholde en logo, klokke og dato/kalender. 4.4 Eventuelle krav til systemkonstruksjon (tekniske krav) Utvikling Som server har vi valgt å bruke en maskin med operativsystem Windows XP Professional SP3. Maskinen som brukes som server skal være satt opp med IIS for at den skal kunne brukes som webserver, og Microsoft SQL Server 2005 (medfølgende i installasjonen av Visual Studio 2008) som vi bruker i arbeidet med database. Som plattform bruker vi.net, med hovedvekt på ASP.NET kombinert med C# som programmeringsspråk. For det visuelle bruker vi Silverlight 3. Som utviklingsplattform for applikasjonen har vi valgt Visual Studio 2008, og for å utvikle databasen må vi bruke en extension til Microsoft SQL Server Drift Programmet skal være mest mulig selvgående. Det skal være en innloggingsside med mulighet for enkel administrasjon av programmet. 24

25 Når programmet er i drift, skal det være mulig å definere et nytt område, og velge hvilke rom som skal inngå i dette området. Hver stasjon skal settes opp for å vise et område, applikasjonen skal kjøre automatisk når dette først er gjort. Planen er at konfigurasjonen skal settes opp én gang, og ikke kreve øvrig vedlikehold uten hvis det er ønskelig å opprette nye eller slette gamle rom/områder. Utstyr For hver stasjon som skal driftes, trenger man en widescreen skjerm, en PC med internettilkobling og nettleser som støtter Silverlight 3. I tillegg trenger systemet én maskin satt opp med Windows XP Professional SP3 og IIS. 4.5 Eventuelle krav til dokumentasjon Alle gruppene er pålagt å følge en dokumentasjonsstandard: Torvatn, A. M. (2007) "Hovedprosjekter i data/it - Dokumetasjonsstandard". Dokumentasjonsstandarden er utarbeidet av førstelektor Ann-Mari Torvatn. Hun har i mange år undervist faget "Menneske-maskin-interaksjon" og har samtidig utarbeidet et kompendium for faget. Denne dokumentasjonsstandarden er et bearbeidet utdrag fra kompendiet. Ann-Mari Torvatn gikk av med pensjon per 1. januar Hvis det skulle være spørsmål i tilknyting til dette kan hun nås via epostadressen annmari.torvatn@senior.hio.no 5 Utviklingsprosess og gjennomføring 5.1 Kravspesifikasjonens rolle i utviklingsprosessen Hovedhensikten med kravspesifikasjonen er å sette krav til funksjonaliteten for vårt produkt. Oppdragsgiver hadde ingen formulerte krav da vi startet, med hadde et ønske om noen funksjoner som skulle dekkes av applikasjonen. Det ble derfor viktig for oss å utarbeide en kravspesifikasjon før vi kunne gå i gang med programmeringen, ellers ville vi risikert å skrive ubrukelig kode fordi vi ikke visste hva som var målet med applikasjonen. Kravspesifikasjonen måtte utarbeides så tidlig som mulig, sånn at programmeringen kunne starte uten for store forsinkelser. Den ble derfor et viktig dokument allerede fra starten av prosjektet. Vår kravspesifikasjon ble først satt opp punktvis og i stikkordsmessig form, og deretter utarbeidet for å tilfredsstille forventningene til et slikt dokument. Den har blitt et av våre viktigste verktøy for å vite hva vi skulle tilføye av funksjoner i applikasjonen, og har blitt nøye fulgt opp og tilpasset for til enhver tid å representere oppdragsgivers ønsker om den ferdige applikasjonen. Vi mener at vi har klart å følge kravspesifikasjonen hele veien, og at applikasjonen vi presenterer er i tråd med dette dokumentet. 5.2 Use Case-modellens rolle under utviklingsprosessen Det har blitt laget use case modeller og beskrivelser for praktisering av krav der vi følte dette har vært hensiktsmessig. Oppdragsgiveren har ikke hatt noe ønske om eller krav om at UML skulle brukes i det hele tatt, men vi fikk en anbefaling fra intern veileder om å lage use case modeller. Use Case modellen har vært nyttig under opprettelsen av administrasjonssidene. Modellen gjorde at vi enkelt fikk oversikt over hvilke funksjoner som skulle legges til og hvordan 25

26 funksjonene måtte kodes, hvilke typer administrator som skulle ha tilgang til de ulike funksjonene, samt likheter og ulikheter mellom de to ulike administrator-typene. Det var use case modellen som inspirerte oss til å lage to forskjellige innloggingssider det er typen administrator-bruker som avgjør hvilken side innlogget bruker kommer til. Til use case modellering har vi brukt programmet Violet UML Editor. For mer informasjon om diagrammer og beskrivelser vennligst se vedlegg om Usecase Modeller. 5.3 Veiledning og samarbeid Samarbeidet vårt med veilederen, Emine Gøcmenoglu, har vært veldig godt gjennom hele perioden. Hun har alltid vært villig til å møte oss og stilt opp når vi har hatt behov for det. Til å starte med, etter et forslag fra Emine Gøcmenoglu, bestemte vi oss for å ha en fast møtetid med henne hver onsdag. Denne avtalen varierte litt etter hvert som vi kom i gang med prosjektet, når det gjelder dag og tid, og i noen perioder har vi henvendt oss til henne bare ved behov. Dersom det var noe vi sto fast på eller ønsket mer informasjon om, har hun vært flink til å komme med gode og raske tilbakemeldinger. Med andre ord kan vi kort og godt si at Emine har vært en god veileder for oss. 5.4 Presentasjonsmøte med veileder, oppdragsgiver og faglærer i.net Med veilederens hjelp arrangerte vi et møte til den 09/03-10 for å presentere vår applikasjon til oppdragsgiver og Tor Krattebøl. Tor Krattebøl underviser i.net, derfor har vi valgt å invitere ham til presentasjonen. Vi tenkte det kunne være nyttig å ha en faglærer som kunne gi oss innspill og forslag til forbedring av applikasjonen. Under dette møtet fikk vi mange nyttige tilbakemeldinger, hvorav det var en del forbedringsforslag. Alle forslagene ble notert ned, og etter møtet hadde prosjektgruppen et vurderingsmøte hvor vi tok opp hver tilbakemelding for seg. For hvert punkt vurderte vi da nytteverdien av den foreslåtte funksjonen, hvor mye arbeid som måtte til for å implementere den og hvordan det ville påvirke applikasjonen visuelt. Selv om vi fant mulighet til å implementere de fleste foreslåtte funksjoner, var det enkelte av funksjonene vi ikke fant det hensiktsmessig å ta med. Som eksempel kan her nevnes et ønske om at innlogget administrator kunne velge hvor mange undervisningslokaler som skal vises i applikasjonens hovedvindu; det var da tenkt at administrator kunne velge mellom å vise 1, 2, 4, 6 eller 8 undervisningslokaler. (Det er selvfølgelig mulig å vise flere eller færre enn 6 undervisningslokaler med applikasjonen som den er nå også, men da vil det kunne oppfattes som at applikasjonen har et tomrom der det er satt av plass til flere rom; den foreslåtte ideen var derfor at hvert rom skulle vises over et større område hvis administrator valgte å vise kun 2 stykker.) Vi hadde tidligere tenkt på hvor mange undervisningslokaler som var hensiktsmessig å vise, men nå tok vi det opp til ny vurdering. En slik endring ville kreve at vi måtte skrive om store deler av applikasjonen, og derfor valgte vi å tegne opp skjermbildet slik det ville se ut med denne funksjonen før vi begynte å programmere den. Vi klarte imidlertid ikke å finne en måte å vise et annet antall rom uten at vi syntes det påvirket negativt den visuelle oppfatningen av applikasjonen. Dette resultatet, kombinert med den arbeidsmengden det ville kreve, samt at vi ikke kunne komme på noe tilfelle der funksjonen ville ha stor nytteverdi, gjorde at vi valgte å ikke programmere denne funksjonen. Møtet med veileder, oppdragsgiver og den nevnte foreleser resulterte imidlertid også i at vi gjorde noen endringer i henhold til deres forslag. Den første var ganske enkelt et ønske om å vise HiOlogoen på administrasjonssidene. Logoen hadde vi allerede lagt inn i visningsdelen av applikasjonen, men nå ble den lagt til også på innloggings-/administrasjonssidene. Det var også et ønske om at 26

27 administrator skulle kunne velge hvor mange sekunder det skal gå mellom visningen av hvert skjermbilde hvis det er lagt inn mer enn 6 undervisningslokaler. Dette la vi inn som et valg med rullegardin-liste eller drop down list i administrasjonssiden. På møtet ble det også ytret et ønske om at applikasjonen skulle ha en funksjon for å ikke vise grupperom-kontrollen i de tilfeller der stasjonen kun er tilknyttet undervisningsrom. Dette løste vi ved å programmere at applikasjonen automatisk lar være å vise denne kontrollen for en stasjon hvor ingen av de tilknyttede rommene er grupperom. I tillegg har vi gjort noen redaksjonelle endringer av feilmeldinger i applikasjonen som en følge av tilbakemeldingene vi fikk på dette møtet. Videre ble det foreslått at administrator skulle kunne velge om RSS-en skal vises på skjerm eller ikke, og dette tok vi da opp til vurdering. Imidlertid vurderte vi det dit hen at RSS kan være ønskelig for enkelte brukere, og vi kunne ikke komme på noen situasjon hvor det ville være direkte hensiktsmessig å ikke ha denne visningen. I tillegg viste en brukerundersøkelse gjort mot studenter ved datalinjen at flertallet var positive til å få se RSS. I tillegg kom det under møtet et forslag om å fjerne Tilbake til ny stasjonsregistrering -linken fra administrasjonssiden når det har blitt opprettet en ny stasjon. Her er vi uenige, idet vi mener at denne linkens synlighet kan forenkle prosessen med å legge inn flere stasjoner i samme økt. Med tanke på at linken ikke medfører noen som helst ulempe, valgte vi derfor å la denne bli stående. Figur 5: Et skjermbilde av "Ny stasjon" siden 5.5 TimeEdit i vårt prosjekt TimeEdit er skolens eksterne leverandør av timeplanløsninger. Dette er en kommersiell bedrift som tilbyr sin tjeneste til HiO, men har for øvrig ingen tilknytning til skolen. Vår kilde til informasjon om romreservasjoner i dette prosjektet var TimeEdit. Av forståelige grunner kunne vi ikke få full tilgang til deres systemer, og de hadde ingen eksisterende løsning for å gi oss begrenset tilgang til systemene. Det har derfor vært en utfordring å få hentet ut den informasjonen 27

28 vi trenger i henhold til oppgavens problemstilling, og vi var nødt til å finne en alternativ løsning på dette. HiO har heller ingen tilgang til TimeEdit sine systemer, men har en nettside hvor all undervisning kan listes ut. Denne nettsiden har noen få forhåndsprogrammerte valg for sortering, og selv om disse funksjonene normalt er utilstrekkelig for både studenter og skolens ansatte, ga de likevel en mulighet for å hente ut nødvendig informasjon, om enn på en uryddig måte. Figur 6: TimeEdit sin nettside med søkefunksjon 5.6 Hovedutfordringer Her vil vi beskrive de største utfordringene vi møtte på under arbeidet med prosjektet vårt. I tillegg til disse utfordringene, kan det nevnes at vi hadde litt problemer med bruken av IIS i starten. Dette skyldtes imidlertid ikke problemer rundt IIS, men det faktum at vi aldri før hadde arbeidet med denne teknologien. For utfyllende informasjon om hvordan vi løste problemene, henviser vi til iterasjonsbeskrivelsene og produktdokumentasjonen. Innsamling av data Utgangspunktet for vårt prosjekt var annerledes enn det man vanligvis finner for tilsvarende hovedprosjekt. Oppgaven bygger på å vise informasjon fra en database, og normalt finnes det to hovedkategorier av en slik oppgave. Den første kategorien er i de tilfeller databasen er ikkeeksisterende, og den må da bygges som en del av prosjektoppgaven og prosjektgruppen sitter på alle rettigheter; I motsatt fall eksisterer det en database, gjerne administrert av oppdragsgiver, og det finnes måter å gi prosjektgruppen fulle eller begrensede rettigheter. I vårt tilfelle var situasjonen annerledes: Det eksisterte en database, men verken vi eller oppdragsgiver hadde de nødvendige rettigheter for tilgang disse rettighetene eies av TimeEdit, en ekstern bedrift som tilbyr en tjeneste til HiO. Den første utfordringen vår ble derfor innsamling av relevante data. Dette er noe man anser som uproblematisk i de fleste prosjekter, og det regnes derfor ikke for å være en stor oppgave. For oss var dette derimot et problem som måtte løses før vi kunne ta fatt på det man normalt ser på som selve prosjektoppgaven å behandle de innsamlede data og benytte dem i arbeidet med applikasjonen. 28

29 Knytte Silverlight til database En annen utfordring oppstod fordi vi ønsket å utvikle applikasjonen i Silverlight for å få et pent tilpasset brukergrensesnitt. Av sikkerhetsmessige årsaker har Silverlight ingen funksjon for å lese direkte fra en fil eller fra databasen, og dermed hadde vi ingen direkte mulighet til å la Silverlightapplikasjonen benytte de data vi hadde samlet inn, og vi måtte finne alternative måter å gjøre dette på. 6 Iterasjonsbeskrivelse For å kunne gi en lettfattelig beskrivelse av arbeidsprosessen, har vi her valgt å beskrive prosjektets iterasjoner enkeltvis. Vi mener at dette bidrar til en kronologisk og oversiktlig forståelse av arbeidet vi har gjort. Vi planla prosjektet som en prosess bestående av 6 iterasjoner. Underveis i arbeidet innså vi at det ville være mer oversiktlig å dele opp den ene iterasjonen i to enkeltstående deler, og den endelige prosessen ble derfor inneholdende 7 iterasjoner. Flere ganger gjennom prosjektet har gruppen jobbet parallelt med 2 eller flere iterasjoner. Dette har vi gjort av praktiske hensyn, enten fordi det har vært nødvendig å vite hvordan neste iterasjon skulle se ut for å fullføre den iterasjonen vi i utgangspunktet jobbet med, eller fordi det med tanke på tilgjengelig arbeidskraft har vært mest hensiktsmessig at noen startet på neste iterasjon samtidig som andre sluttførte den vi jobbet med. 6.1 Iterasjon 0 Dette er på mange måter den største iterasjonen i prosjektet; Ikke nødvendigvis fordi hver oppgave er spesielt stor eller krevende, men fordi iterasjonen består av mange punkter og omhandler ulike deler av prosjektet. Vi ønsket at den første iterasjonen skulle sette oss inn i alle deler av prosjektet, og den måtte derfor resultere i flere overordnede valg og skisser. Oppgaver: Skissere applikasjonen og funksjonaliteter. Valg av teknologier. Sette opp server og installere programmer. o Operativsystem: Windows XP Pro (SP3) o Remote desktop o IIS o Microsoft Visual Studio 2008 (SP1) o Expression Blend 3 o Silverlight 3 toolkit for Visual Studio 2008 (SP1) o Database: Microsoft SQL Server 2005 Skissere overordnet kravspesifikasjon. Skrape webside til XML: Skrive en applikasjon som kan hente ut data fra TimeEdit sin nettside og lagre de hentede data til en XML-fil. Vurdere ulike utviklingsmodeller. 29

30 Det første prosjektgruppen måtte gjøre, var å skissere hvilken løsning vi skulle lage. Denne skisseringen omfattet blant annet use case-diagrammer, som vi har brukt flere ganger underveis i implementeringsfasen. Oppdragsgiver hadde ikke noen krav eller ønsker til hvilken plattform applikasjonen skulle leveres i, så vi som prosjektgruppe sto helt fritt til å velge teknologier og programmeringsspråk. Ut fra oppgaven vi hadde fått med å hente informasjonen fra TimeEdit sine nettsider, var det naturlig å bruke en web-basert løsning. Vi valgte å bruke Visual Studio som programmeringsverktøy og.net som plattform. Som programmeringsspråk valgte vi å bruke ASP.NET, C# og Silverlight. Når vi hadde valgt å bruke en web-basert løsning, var det klart at vi trengte vi en web-server. Ettersom vi også hadde valgt å bruke.net, måtte vi bruke IIS (Internet Information Services). Det var naturlig å bruke Microsoft Windows som operativsystem når vi valgte Microsofts.NET-løsning som utgangspunkt for programmering. For detaljert beskrivelse av oppsettet for server og programmer, henviser vi til produktdokumentet. Kravspesifikasjonen var for oss et viktig dokument å få på plass tidlig i prosjektet; Ikke som et ferdig dokument, men som en overordnet mal. HiO som vår oppdragsgiver hadde ikke noen formulert kravspesifikasjon, og det var derfor nødvendig å definere deres ønsker og behov. I møter med vår kontaktperson i HiO fikk vi et inntrykk av hvilken funksjonalitet oppdragsgiveren ønsket fra applikasjonen, og deretter måtte formulere det som et skriftlig dokument. På den måten var det vi som forfattet kravspesifikasjonen, mens HiO godkjente at det vi hadde skrevet samsvarte med ønskene de hadde. Oppdraget vårt krever at vi henter ut informasjon fra TimeEdit, som er skolens eksterne leverandør av timeplanløsninger. TimeEdit er en kommersiell bedrift, og av forståelige grunner får vi ikke full tilgang til deres systemer. De har heller ikke en eksisterende løsning for å gi oss begrenset tilgang til systemet, og har ingen planer om å lage en slik løsning innenfor den tidsrammen vi har for prosjektet. Det har derfor vært en utfordring å få hentet ut den informasjonen vi trenger i henhold til oppgavens problemstilling, og vi var nødt til å finne en alternativ løsning på dette. Skolen har ingen tilgang til TimeEdit sine systemer, men har en nettside hvor all undervisning kan listes ut. Denne nettsiden har noen få forhåndsprogrammerte valg for sortering, men denne er vanligvis utilstrekkelig for både studenter og skolens ansatte. De har imidlertid en løsning som lister ut alle reservasjoner og forelesninger i en gitt bygning, med et valgfritt tidsintervall fra 30 minutter til 24 timer framover i tid. Se figur 7 og 8. 30

31 Figur 7: Søkefunksjoner i TimeEdit Figur 8: Opplisting av alle data i TimeEdit Som figurene viser, lister TimeEdit ut alle data i en tabellform. Denne tabellen er i HTML, og dataene er ikke sortert på noen annen måte enn at alt listes kronologisk etter starttidspunkt. For å kunne nyttiggjøre oss denne informasjonen, måtte vi derfor få det over på en form vi kunne jobbe videre med. Vi benytter oss av en teknikk som kalles Web-skraping (engelsk: Web Scraping). Ved hjelp av Regular-Expressions kunne vi filtrere den nødvendige informasjonen fra TimeEdit sin løsning, og skrive denne ned til en XML-fil. Denne XML-filen er vår applikasjons datakilde. Se figur 9. 31

32 Figur 9: Utsnitt av XML-fil 6.2 Iterasjon 1 Oppgaver: Opprette en database. Skrive algoritmer for filtrering av data. Web-skrapingen fra iterasjon 0 gav oss data om registrerte forelesninger og reservasjoner, og den ble lagret i et format som gjorde det mulig å behandle dataene. For å kunne nyttiggjøre oss av dette, måtte vi imidlertid ha et system for sortering av data, og da ble det nødvendig å opprette en database. Oppdraget vårt går ut på å vise relevante forelesninger og reservasjoner for et gitt område, heretter kalt stasjon. Databasen inneholder informasjon om hvilke stasjoner som er opprettet, og hvilke rom hver stasjon omfatter. Visual Studio 2008 kommer med et innebygget databaseverktøy kalt Microsoft SQL Server Av hensyn til effektivitet og enkelhet, valgte vi å bruke dette verktøyet i stedet for mer avanserte programmer. Microsoft SQL Server dekker alle behov vi har i forhold til oppretting og håndtering av databaser. For mer detaljert informasjon om dette, henviser vi til produktdokumentet. 6.3 Iterasjon 1-ii Oppgaver: Opprette en side for administrering av applikasjonen. Da vi var ferdige med algoritmer for filtrering av data, trengte vi en side hvor vi kunne bestemme hva som skulle vises. Dette var nødvendig for å teste algoritmene i praksis; Vi kunne bruke administrasjonssiden til å knytte gitte data til en stasjon, for deretter å kontrollere at de utsendte data samsvarte med forventningene. Administrasjonssiden er bygget opp på en måte som gjør at man må logge på for å få tilgang til funksjonene. Dette er et valg vi har gjort for å gjøre det mulig å ha siden liggende offentlig ute på internett. En innlogget administrator («Standard»-bruker) kan opprette/endre/slette stasjoner, 32

33 opprette/endre/slette rom og velge hvilke rom som skal være knyttet til hver stasjon. En innlogget superadministrator («Admin»-bruker) kan i tillegg opprette nye brukere, slette eksisterende brukere eller endre informasjonen til en bruker. På funksjonene i administrasjonssiden er det lagt inn hensiktsmessige valideringer på data som blir skrevet inn av brukeren. (For detaljert informasjon om dette, henviser vi til produktdokumentet.) Vi fikk imidlertid et problem med å lage validering på feltet «romtittel», som er den unike koden hvert rom har i reservasjonssystemet til TimeEdit. Grunnen til dette, er at rommene har blitt tildelt veldig ulike romtitler noen er tildelt koder som P35-PH322 eller P52-A357a, andre har koder som pp35-u1011 eller p44-v-2u31, andre igjen har koder som -Eksamrom, og atter andre har koder som fg18-k105. (Alle de oppramsede romkodene er reelle eksempler hentet fra TimeEdit sin reservasjonsside.) Som man kan se av dette, er romkodene skrevet på mange ulike former, og vi vet ikke om vi har oppdaget alle de ulike variantene som er brukt. Vi har ikke tilgang til TimeEdit sin database, og kan derfor ikke forhåndsregistrere alle rommene som finnes. På grunn av dette problemet, har det vært umulig for oss å legge inn validering på hva administrator skriver i feltet «romtittel», og alt ansvar ligger derfor på den innloggede brukeren når det gjelder å skrive inn riktige opplysninger i dette feltet. (Hvis et rom blir feilregistrert, må det slettes for deretter å legge inn et nytt rom med riktige opplysninger.) 6.4 Iterasjon 2 Oppgaver: Lage et visuelt rammeverk for applikasjonen. Lage algoritmer for lesing og visning av RSS-feeder. For å se hvilke opplysninger (rom og reservasjoner) som ble knyttet til de ulike stasjonene, trengte vi en side som kunne vise stasjonene. Det er denne delen av programmet som studentene vil se når applikasjonen settes i drift. Det viktigste elementet i denne delen av applikasjonen, er det visuelle, og derfor valgte vi å bruke Silverlight når vi skrev denne siden. Silverlight gjør det mulig å gi nettsiden et pent brukergrensesnitt utover det som er tilgjengelig med vanlig HTML. En ulempe vi oppdaget med Silverlight, var at den ikke kunne lese direkte fra en fil eller fra databasen. Derfor måtte vi opprette en web-service som stod for kommunikasjonen mellom databasen og Silverlight-applikasjonen, og mellom XML-filer og Silverlight-applikasjonen. Parallelt med det visuelle rammeverket, begynte vi å programmere kontroller for å lese inn og skrive ut RSS-elementer. RSS var noe ingen i gruppen hadde arbeidet med tidligere, så vi måtte lære oss dette på egen hånd. Imidlertid var det god hjelp å finne i den kunnskapen vi hadde opparbeidet oss i arbeidet med XML-filer. Grunnen til dette, er at RSS-filer er skrevet i XML-format, og lesing av RSS skjer derfor på samme måte som lesing av en hvilken som helst annen XML-fil. 6.5 Iterasjon 3 Oppgaver: Lage kontroller for visning av forelesningssaler og klasserom. Lage kontroller for visning av grupperom. 33

34 Da rammeverket var ferdig, kunne vi begynne å legge til innhold i visningsdelen av applikasjonen. I Silverlight er det mulig å lage egne kontroller for visning av ulike data. En kontroll er i denne sammenheng et visuelt brukergrenseelement. Det første som måtte på plass, var presentasjon av undervisningen som foregår på skolen. Dette ble den første egendefinerte kontrollen vi laget i Silverlight. Det var viktig for oss å skille mellom ulike undervisningslokaler (klasserom, auditorier og laboratorier), i og med at undervisningen vil foregå i ulik form avhengig av hvilken type lokale den foregår i. Derfor vises all undervisning i samme kontroller, men vi har lagt inn et tekstfelt som beskriver hva slags type lokale det er snakk om. Se figur 10. Figur 10: Presentasjon av undervisningslokaler I tillegg til undervisningslokaler, har det vært viktig for oss å vise grupperom i applikasjonen. Det er ofte vanskelig å finne ledige grupperom, og vi anså det derfor for å være et nyttig tillegg for studentene, selv om skolen i utgangspunktet ikke hadde definert det som et ønske. Det var imidlertid ikke hensiktsmessig å vise grupperom på samme måte som undervisningslokaler, og vi måtte derfor lage en egen visningsmetode for disse. Dette ble den andre kontrollen vi laget i Silverlight-applikasjonen. Grupperom som er reservert markeres med rødt, mens grupperom som er ledige for reservasjon markeres med grønt. Se figur 11. Figur 11: Grupperom 6.6 Iterasjon 4 Lage en kontroll for RSS-visning Lage kontroller for logo, klokke og dato Etter å ha lagt inn undervisninger og grupperom, laget vi en kontroll for å vise nyheter fra HiO sin RSS-feed. I tillegg laget vi en kontroll for å vise HiOlogoen i applikasjonen. For å bedre brukervennligheten, la vi til kontroller for klokke og dato i applikasjonen. Visuelt oppdaget vi at det så fint ut med en analog urskive øverst i websiden, i tillegg til at vi la inn digital klokke og dato nederst på siden. Det er imidlertid mye arbeid å kode en analog klokke, og det krever Figur 12: RSS-visning 34

35 omfattende matematiske beregninger for å posisjonere ulike grafiske elementer i forhold til hverandre. Derfor valgte vi å ta utgangspunkt i allerede eksisterende kode fra og tilpasset denne for å få et utseende som passet til resten av applikasjonen vår. Klokken vi valgte, lå ute med åpen kildekode, og det er derfor fritt fram for alle å bruke den i egne prosjekter. Ettersom dette ikke var en viktig del av prosjektet, men likevel gav et visuelt bidrag, valgte vi å benytte oss av dette eksemplet. Figur 13: Analog urskive 6.7 Iterasjon 5 Testing av funksjonalitet Avsluttende arbeid og visuell tilpasning Da alle nødvendige funksjoner var lagt til, startet arbeidet med å prøve ut applikasjonen i praksis. Vi opprettet midlertidige stasjoner som vi deretter startet visning av og observerte over tid. Det dukket opp enkelte uforutsette situasjoner som en følge av at TimeEdit i enkelte tilfeller oppgav verdier vi ikke hadde tatt hensyn til. Et eksempel på dette, var en reservasjon som hadde oppgitt starttid kl 00:00 og sluttid kl 24:00; Denne reservasjonen fikk programmet til å henge. (Teknisk kan dette forklares med at vi sorterer forelesningene etter DateTime-objekter, og DateTime godtar ikke at timeverdien settes til 24.) For mer detaljert informasjon om testingen, henviser vi til testdokumentasjonen. Vi har laget kode for valideringer av de data vi behandler i applikasjonen, både det som kommer fra TimeEdit og det som kommer fra brukere. For øvrig informasjon om validering av innsamlede data, henviser vi til produktdokumentasjonen. Som et ledd i testing av funksjonaliteten, har vi vist fram applikasjonen til andre studenter på datalinjen ved HiO. Ved et tilfelle laget vi også en anonym spørreundersøkelse der vi ba om forbedringsforslag og spurte hvor enkel applikasjonen var å bruke. På grunnlag av tilbakemeldingene vi fikk der, valgte vi å gjøre et par mindre endringer av redaksjonell art, i tillegg til en større visuell endring. Den store endringen vi gjorde etter et ønske fra flere av studentene, gikk på å lage et visningsalternativ for et tenkt tilfelle der stasjonen bare er knyttet til grupperom og ikke noen forelesningsrom. I et slikt tilfelle vil grupperomreservasjoner vises i den kontrollen som normalt brukes for undervisninger, og dermed vil hvert grupperom listes med flere av de kommende reservasjoner, sortert kronologisk etter starttid. Vi arrangerte også et møte med intern veileder, oppdragsgiver og en foreleser som underviser i.netteknologien. Dette møtet resulterte i mange nyttige tilbakemeldinger og noen forslag til endringer/tillegg. Selve møtet og følgene av dette er allerede oppsummert i prosessdokumentasjonen, i kapitlet om utviklingsprosess og gjennomføring. Her nøyer vi oss derfor med å si at alle forslag ble nøye vurdert, og at vi implementerte flere av de foreslåtte funksjonene. 35

36 7 Oppsummering 7.1 Produkt Produktet vi har laget samsvarer i stor grad med de kravene vi satte fra begynnelsen av prosjektet. Hovedoppgaven til systemet var opprinnelig å vise studenter foregående forelesninger i de ulike undervisningsrommene i hver etasje med ett gitt tidsintervall. I tillegg klarte vi å gjennomføre de kravene vi satte opp selv. Når du ser i skjermen skal du kunne lett få informasjon om når og hvor forelesningen er, eventuelt hvilken grupperom som er ledig og er reservert. HiO-nytt, dato og klokke er andre aktuelle informasjoner i systemet som vi tenkte det kunne være interessant å vite. Figur 14: Et skjermbilde av det endelige produktet. Denne applikasjonen skal brukes på skjermer satt opp forskjellige steder på skolen, og vise reservasjonene for det gitte området. For eksempel en skjerm i 3. etasje vil bare vise reservasjoner som foregår i den etasjen. For å administrere systemet har vi laget en administrasjonsside der brukeren har mulighet til å bestemme utseendet på skjermen. Brukeren oppretter da i første omgang en ny stasjon og legger til rom for den valgte stasjonen. Med utseende mener vi hvilke rom som er lagt inn for visning og hvor lang tid det skal gå før et nytt skjermbilde kommer på skjerm. Ellers skal programmet være mest mulig selvgående. Hver stasjon skal settes opp for å vise et område, og applikasjonen skal kjøre 36

37 automatisk når dette først er gjort. Konfigurasjonen skal settes opp én gang, og skal ikke kreve øvrig vedlikehold uten hvis det er ønskelig å opprette nye eller slette gamle rom eller områder. Som utviklingsspråk har vi valgt C# kombinert med ASP.NET og Silverlight. Utviklingsplattformen som er blitt valgt er.net. Systemet vi har utviklet kan ses på som et fullt funksjonelt og et ferdig produkt. De ulike utfordringer vi har møtt underveis har blitt løst på en fornuftig måte, og både oppdragsgiver og prosjektgruppen er i sin helhet svært godt fornøyd med det endelige produktet. Systemet skal ha all den funksjonaliteten som tilrettelegges hovedsakelig for studenter og gi et fungerende system for per dags dato. Brukerundersøkelsen gjort mot studenter ved datalinjen bekrefter også dette. Undersøkelsen viste at mesteparten av studentene hadde behov for et tilsvarende system. 7.2 Prosess Det har vært en utfordrende og lærerik prosess å arbeide med problemstillingene i dette prosjektet. Vi har møtt opp en del problemer under utviklingen av applikasjonen og serveren, som vi har fått en del god erfaring av. Svært mye av tiden har gått med til å løse disse problemene. I tillegg har vi fått god innsikt i hvordan arbeidsprosessen utføres i et stort prosjekt, og hvordan det er å arbeide sammen i en gruppe på tvers med oppdragsgiver. Mye av den kunnskapen vi har lært i løpet av de 3 studieårene, har vi fått brukt under prosjekt perioden og fikk stor nytte av det. Både når det gjelder programmering, datasikkerhet og systemutvikling. I dette prosjektet fikk vi muligheten til å fordype og praktisere våre kunnskaper. Som tidligere nevnt avgjorde vi selv hvilken funksjonalitet som ville være hensiktmessig for vår applikasjon. Oppdragsgiveren hadde ikke formulert noen kravspesifikasjon, derfor stod vi ganske fri til å utforme annen funksjonalitet. Hovedoppgaven til applikasjonen var egentlig å vise studentene hvor de forskjellige forelesningene foregår og i hvilke tidspunkt. Men i tillegg har vi bestemt oss for å vise studentene alle ledige og reserverte grupperommene i de forskjellige områdene. Vi har selv sett og opplevd hvor vanskelig det er å finne ledige grupperom her på skolen i de 3 årene vi har vært her. Og derfor ville vi implementere en løsning på dette problemet, som en selvfølge, når vi først hadde mulighet til det. Brukerundersøkelsen viste også at dette var godt tenkt. En slik løsning hadde studentene savnet på lenge. Kort sagt er vi ganske fornøyd med innsatsen vi la ned i arbeidet vårt. Programmet skal etter ønske være åpen for videreutvikling på et senere tidspunkt også. Vi føler egentlig ikke at vi ville gjort så mye annerledes dersom det var prosjektstart i dag. Fremdriftsplanen er blitt fulgt som planlagt, og vi klarte å lage et produkt som er i henhold til de mål og krav som har blitt satt. 37

38 38

39 Kilder Torvatn, A.M. (2007) "Hovedprosjekter i data/it - Dokumetasjonsstandard", Oslo: Seksjon for data og allmenfag, IU, Høgskolen i Oslo, Hansen, T.B. (2006) "Om prosesser", Sør-Trøndelag: Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag, Holmstedt, V. (2004) "Objektorientert systemutvikling og UML", Bergen: Fagbokforlaget Vigmostad & Bjørke AS Lano, K. (2005) "Advanced Systems Design with Java, UML and MDA", Storbritannia: Elsevier Butterworth-Heinemann Larman, C. (2005) "Applying UML and Patterns" third edition, USA: Prentice Hall PTR All informasjon fra nettsider er samlet inn i perioden mars 2010 mai

40 40

41 Produktdokumentasjon 41

42 Forord Denne rapporten omhandler produktets funksjonalitet, oppbygging, virkemåte og delvis testing. Dokumentet vil også være til hjelp ved videreutvikling av RomSys på et senere tidspunkt. Leseren av produktdokumentasjonen bør kunne grunnleggende om PC bruk for å ha forståelse av språk og begreper. I tillegg vil det være en fordel om leseren har basiskunnskaper om programmering og utvikling. For utfyllende informasjon om prosessen, testingen og bruk av produktet henviser vi til henholdsvis prosess-, test- og brukerdokumentasjonen som er selvstendige dokumenter. 42

43 Innholdsfortegnelse 1 Presentasjon av RomSys Kort beskrivelse Systemkrav Klient Server ASP.NET og Silverlight Generelt ASP.NET Server Controls Silverlight XAML Controls Silverlight usercontrols Konfigurasjonsfiler i ASP.NET WCF-service C# Applikasjonsstruktur Overordnet struktur Modellene Generelt Prosjektreferanser Datalaget Generelt Web-scraping LINQ - Language Integrated Query Prosjektreferanser Virksomhetslogikken Generelt Serverside validering Prosjektreferanser Presentasjonslaget Administrasjonssidene Generelt Master Pages ASP.NET Panel Meldingsbokser Presentasjonslaget visningsdelen

44 Generelt WCF-Service Animasjoner Databasen Relasjonsdiagrammet Tabellbeskrivelser brukere stasjon rom stasjonrom Oppkobling til database Sikkerhet Brukerinnlogging og passordhashing Beskyttelse mot skadelige inndata Brukergrensesnittet Implementering på server Generelt Applikasjonspakken Konfigurering av IIS Implementering på klient Generelt Automatisk oppstart av applikasjonen Manuell oppstart av applikasjonen Videreutvikling Utviklingsplattform Datakilde for reservasjoner Forslag til videreutvikling Historikk Meldingsbokser med ikoner Manuell styring av kontrollere i visningsdelen Kilder

45 1 Presentasjon av RomSys 1.1 Kort beskrivelse Vår oppdragsgiver, Høgskolen i Oslo (HiO), er landets største statlige høgskole med studenter, og tilbyr både bachelor- og masterstudier, samt ett doktorgradsprogram. Med så mange elever og undervisningstilbud i en rekke forskjellige fag, er det nødvendig å kunne gi en rask og enkel oversikt over hva som til enhver tid foregår i de ulike undervisningslokalene. Oppdragsgiver hadde ingen konkret kravspesifikasjon for denne oppgaven, men hadde et ønske om at en del funksjoner skulle implementeres. Høgskolens avdeling for ingeniørfag mente at det med dagens teknologi burde finnes en enkel måte å se hva som foregår i HiOs lokaler, både for studenter og for ansatte. Videre var det ønskelig å vite hva som skal foregå i de samme lokalene senere på dagen. Det har ikke vært noen enkel måte å finne slike opplysninger med de systemene studenter har hatt tilgang til. Derfor var det ønskelig å vise denne typen informasjon på et antall skjermer, plassert på strategiske steder i høgskolens lokaler. Applikasjonen som vi har utviklet har fått navnet RomSys og består av to hoveddeler: Visningsside for romfordeling: Det er denne delen av applikasjonen brukerne skal se. Under utviklingen av applikasjonen har vi kalt denne delen for Show. Det vil vi også fortsette med videre i dette dokumentet. Show er en Silverlight-applikasjon som har som hovedoppgave å vise timeplanen for et antall rom i et gitt område av skolen. For hvert rom listes opp samtlige reservasjoner for aktuell dag. Reservasjonene er sortert etter tid. Romtyper som vises er forelesningssaler, laboratorier, og klasserom. Det finnes også en oversiktsdel for grupperom. Grupperomsoversikten lister opp alle grupperom for et gitt område og gir en indikasjon på om det er opptatt eller ledig i form av tekst og farger. Det er også implementert en nyhetsoversikt hvor det vises nyheter fra HiOs egen RSS kilde. Hver informasjonsskjerm representerer et område i det aktuelle bygget. Informasjonsskjerm er herved kalt for stasjon i resten av dokumentet. Administrasjonssidene: Denne delen av applikasjonen er kun for administratorer. Fra disse sidene kan stasjonene opprettes og konfigureres før bruk. Eventuelle endringer underveis kan også stilles inn fra disse sidene. Fra administrasjonssidene kan en: Opprette/slette/endre en stasjon. Opprette/slette/endre en bruker. For hver stasjon kan en administrator: Endre tittel og beskrivelse for stasjonen. Legge til/fjerne rom/grupperom som skal vises i stasjonen. Justere rulleringstidsintervallet for romoversikten. 45

46 1.2 Systemkrav Klient Administrasjonssidene for RomSys er nettbaserte og krever derfor en PC med kontinuerlig nettilgang og nettleser. Testede nettlesere er: Internet Explorer: versjon 8 eller nyere. Mozilla Firefox: versjon 3.6 eller nyere. Opera Browser: versjon 10.0 eller nyere. Google Chrome: versjon 4.0 eller nyere. Safari: versjon 4.0 eller nyere. For å kjøre visningsdelen av applikasjonen må nettleseren ha et Silverlight-tillegg med versjon 3 eller høyere. For å kunne se hele applikasjonen, må oppløsningen på skjermen være 1280x1024, eller så må brukeren zoome ut i nettleseren. Server Serversiden av RomSys er bygget på Microsofts.NET-rammeverk versjon 3.5. Applikasjonen trenger en server med Windows XP/Vista/7 installert, i tillegg til IIS 5.0 eller høyere. 46

47 2 ASP.NET og Silverlight 2.1 Generelt RomSys er bygget opp som en ASP.NET-webapplikasjon med Silverlight. ASP (Active Server Pages) er en Microsoft-teknologi for å bygge dynamiske serverbaserte webapplikasjoner for.netrammeverket. Som alle andre serverbaserte webapplikasjoner foregår det en kommunikasjon mellom ASP-serveren (serversiden) og brukerens maskin (klientsiden). Denne kommunikasjonen skjer via utvekslingsprotokollene HTTP eller HTTPS. Når en klient etterspør en ASP.NET-side fra en webserver, sender serveren forespørselen videre til ASP.NET Runtime som er et program ansvarlig for å kjøre serverkode og kompilere filene til en.netklasse. Denne klassen brukes så til å produsere HTML-kode som sendes videre til klientmaskinen. Ved senere forespørsler om samme ASP.NET-side er denne siden allerede kompilert. HTML kan derfor produseres og sendes tilbake til klienten raskere enn for eksempel HTML generert av en PHPserver. Denne prosessen er vist i figur 1 nedenfor. Figur 1: Kommunikasjon mellom klient og server. En ASP.NET-side består vanligvis av to filer, en fil for websidens innhold (.aspx) og en fil for programlogikken, også kjent som code-behind fil. Code-behind filen har filendingen.cs hvis man programmerer i språket C#, ellers har den endingen.vb (Visual Basic). For å øke funksjonaliteten til applikasjonen og samtidig gjøre utseendet mer attraktivt har vi måttet bruke Microsofts web-applikasjons rammeverk Silverlight. Dette er Microsofts svar på Adobe Flash og gir samme type funksjonalitet. Silverlight tilbyr et grafikksystem som ligner på Windows Presentation Foundation (WPF), og integrerer multimedia, grafikk, animasjoner og interaktivitet i enkelt runtime-miljø. I Silverlight- 47

48 applikasjoner er brukergrensesnittet skrevet i Extensible Application Markup Language (XAML) og programmeres ved hjelp av en undergruppe av.net Framework. XAML kan også brukes for merking opp av vektorgrafikk og animasjoner. Programlogikken skrives i C# eller Visual Basic, akkurat som i ASP.NET. 2.2 ASP.NET Server Controls ASP.NET stiller til disposisjon en rekke ferdiglagde dynamiske elementer for visning og behandling av data. Disse kalles for kontroller. Kontrollerne har innebygde metoder og hendelseshåndteringsmekanismer (event handlers) som forenkler prosessen med å lage interaktive web-skjemaer og samtidig reduserer feil som oppstår ved bruk. Innholdet og egenskapene til kontrollerne kan aksesseres underveis fra programkoden i.cs filen. ASP.NET kontrollerne kan tilby alt HTML-kontroller tilbyr og mye mer. Som vanlig prosesseres kontrollerne i serveren og det som kommer tilbake til klienten er ren HTML. Derfor er ASP.NET-kontroller kompatible med samtlige nettlesere ute i markedet. Et eksempel er kontrolleren DropDownList som er mye Figur 2: ASP.NET DropDownList brukt i RomSys. Denne kontrolleren gir lik funksjonalitet som HTML-kontrolleren select. ASP kontrolleren gir i tillegg også muligheter for hendelseshåndtering. En av hendelsene DropDownList tilbyr er SelectedIndexChanged. Denne hendelsen oppstår når det velges noe fra DropDownListen. I serveren utføres kode som tilhører denne hendelsen og oppdatert innhold sendes tilbake til klienten. Figur 3 viser hvordan opprette en DropDownList i ASP.NET. Merk at AutoPostBack må være satt til true. Figur 3: DropDownList i ASP.NET. 2.3 Silverlight XAML Controls I RomSys har vi brukt Silverlight for å utvide nettleserbasert UI (User Interface) utover det som er tilgjengelig med HTML. Silverlight inkluderer store deler av Windows Presentation Foundation(WPF) teknologien, som i stor grad utvider mulighetene for å utvikle fremragende brukergrensesnitt. Extensible Application Markup Language (XAML) er språket som brukes for å opprette elementer i Silverlight. XAML er en deklarativ markeringssyntaks. Silverlight tilbyr et omfattende bibliotek av kontroller som støtter brukergrensesnitt (UI) utvikling. Noen av disse kontrollene har en visuell representasjon, andre fungerer som beholder for andre kontroller eller innhold, som bilder og media. Disse kontrollerne har mye til felles med ASP.NETkontrollerne. Siden begge to kontroller-bibliotekene opprinnelig stammer fra WPF ser kontrollerne visuelt likt ut i begge bibliotekene. Den visuelle representasjonen av de fleste XAML-kontrollerne kan også tilpasses etter behov. 48

49 I Silverlight deklareres brukergrensesnittet blant annet i XAMLfilen. Det er i denne filen kontrollerne legges etter ønske. Programlogikken skrives i C# i.cs filen, akkurat som ASP.NET. I tillegg til et stort bibliotek av kontroller gir Silverlight også muligheten for å tilpasse disse kontrollerne. I RomSys har vi brukt en tilpasset versjon av ComboBoxkontrolleren. Ved klikk dukker det opp en popup-meny hvor en kan velge hvilke stasjon som skal vises. Denne menyen er tilpasset slik at for hver stasjon vises det stasjonsnummer og beskrivelse i tillegg til stasjonstittelen. Figur 4: Tilpasset Silverlight ComboBox Det er flere måter å tilpasse eksisterende kontroller på i Silverlight. Vi har valgt å bruke app.xamlfilen for å deklarere tilpassningene. App.xaml er en fil som brukes av Silverlight-applikasjoner til å deklarere delte ressurser som ulike layout og elementer. I denne filen kan vi opprette ulike templates (norsk: Mal) for hvordan data skal presenteres i de ulike kontrollerne. Figur 5: Deklarering av ComboBox-kontrolleren i Silverlight I figur 5 er det vist hvordan en combobox defineres i Silverlight. Merk attributtet ItemTemplate. Her henvises kontroller-koden til app.xaml filen i form av StaticResource, for utseende og presentasjon av data. Koden i app.xaml-filen ser slik ut: Figur 6: Template for presentasjon av data i ComboBox Merk koden Binding i Text-attributtet på TextBlock-kontrolleren. Bindingsnavnet brukes som et referansenavn for koden i.cs-filen. I programlogikken kan vi senere kalle opp dette navnet for å programmere innhold for denne kontrolleren. 2.4 Silverlight usercontrols En av de viktigste fordelene med Silverlight er at utviklerne enkelt kan innkapsle UI-funksjonalitet inn i gjenbrukbare kontroller. Det er mulighet for å komponere egne kontrollere og bruke dem om og om igjen etter behov. Disse egendefinerte brukerkontrollerne kalles for usercontrol i Silverlight. En usercontrol er ikke en fullt tilpasset kontroll, men heller en kontroller som igjen grupperer eller viser eksisterende kontroller i en gjenbrukbar samling. Figur 7:Liste over brukerkontroller i RomSys 49

50 Visningsdelen i RomSys består i hovedsak av slike usercontrols. Disse kontrollerne komponeres i egne XAML-filer. Brukerkontrollerne deklareres og brukes på samme måte som andre innebygde kontrollere i Silverlight. Figur 8: Nyhetskontroll Figur 10: Romkontroll Figur 9: Grupperomskontroll Figurene over viser tre av brukerkontrollerne i RomSys. 2.5 Konfigurasjonsfiler i ASP.NET Det finnes flere forskjellige konfigurasjonsfiler i en ASP.NET-webapplikasjon. Disse holdes skjult i serveren og det er derfor trygt å lagre konfigurasjonsinformasjon både for brukere av webapplikasjonen og tilkoblingsinnstillinger til databaser. Web.config-filen er hovedkonfigurasjonsfilen i en ASP.NET-webapplikasjon. Denne filen er en XML-fil som inneholder konfigurasjonsinformasjonen til en webapplikasjon. Web.config-filen inneholder informasjon om controll module loading, sikkerhetskonfigurasjonen, sesjonsstatus-konfigurasjon, applikasjonsspråk og kompileringsinnstillinger. Det er også muligheter for å lagre applikasjonsspesifikke elementer som connectionstring for databaser i web.config-filen. En connectionstring (norsk: tilkoblingsstreng) er en kode som angir tilkoblingsinformasjon for en datakilde. Web.config-filen lagrer også informasjon om webservicer som brukes i applikasjonen. Web.config-filen ligger på rot i prosjektet RomSys. 2.6 WCF-service Av sikkerhetsmessige årsaker er det i Silverlight ikke mulig å arbeide direkte mot datakilder. For å jobbe mot databasen med utgangspunkt i Silverlight måtte vi derfor ta i bruk en form for web- 50

51 service. Visual Studio 2008 tilbyr en service kalt Silverlight Enabled WCF-service. WCF står får Windows Communication Foundation. Gjennom WCF-servicen fikk vi tilgang til databasen fra Silverlight-applikasjonen. Vi vil se nærmere på dette i kapittel 3.6 som handler om visningsdelen i RomSys. 2.7 C# ASP.NET-rammeverket støtter i hovedsak Visual Basic og C# som programmeringsspråk for programlogikken. Programlogikken til RomSys er programmert i C#. 3 Applikasjonsstruktur 3.1 Overordnet struktur RomSys er utviklet som en lagdelt applikasjon med egne prosjekter for modeller, dataaksesslag (DAL: Data Access Layer) og virksomhetslogikk (BLL: Business Logic Layer). I tillegg til dette inneholder applikasjonen et prosjekt for Silverlight-produktet. Silverlight-prosjektet inneholder utviklingsfilene for Silverlight-delen av applikasjonen og er uavhengig av resten av applikasjonen. Denne måten for utvikling gir applikasjonen en mer oversiktlig design og forenkler vedlikehold. Lagdelt utvikling gir også enklere videreutviklingsmuligheter. Endringer i implementasjonen i ett lag behøver ikke å påvirke de andre lagene. Dataaksesslaget tar seg av arbeidet med å hente og skrive data fra forskjellige lokasjoner, som for eksempel en database. Modellene utgjør en innkaspsling av dataene for transport mellom de forskjellige lagene. Virksomhetslogikken er mellomleddet mellom presentasjonslaget (applikasjonens UI) og datalaget. I virksomhetslogikken valideres inn- og utdata, og andre nødvendige operasjoner utføres før dataene returneres eller videresendes fra presentasjonslaget. Figur 11: Applikasjonsstruktur i RomSys 51

52 Figur 12 viser hvordan all kode tilhørende de ulike lagene har blitt gruppert under egne prosjekter i RomSys. Figur 12: Inndeling av kode under de tilhørende prosjekter Videre i dokumentet vil det bli gitt en overordnet beskrivelse av laginndelingene/prosjektene, med unntak av prosjektet Test. Dette prosjektet inneholder kode for enhetstestene og vil bli beskrevet i testdokumentasjonen, som er et selvstendig dokument. 3.2 Modellene Generelt Dette prosjektet inneholder objekter som brukes under transport av data mellom de forskjellige lagene. Disse objektene kalles for modeller. Modellene består av en samling av egenskaper (attributter) som kan ses på som informasjonskapsler som bærer på data relatert til modellen. Alle modeller har fått passende navn og attributtene er lett forståelig. RomSys består av to hoveddeler: administrasjonssidene og visningsdelen. Disse to hoveddelene jobber stort sett med like data, men bruksområdet er forskjellig. Derfor har vi for ordens skyld opprettet nye modeller og kategorisert dem under tilhørende hoveddel. Figur 13: Liste av modeller i RomSys Visningsdelen har fått navnet show under utviklingsprosessen, og de tilhørende modellene ligger under mappen show. Figur 14 og 15 viser en visuell representasjon av modellene i sine tilhørende kategorier. Attributtene for hver modell vises også. 52

53 Figur 14: Modeller for administrasjonssidene Figur 15: Modeller for visningsdelen Attributtene for modellene er opprettet som properties. En property er en public attributt med egne get og set metoder (se figur 16). Figur 16: Eksempel på en modell fra RomSys, merk bruken av property attributtet. Det er viktig å forstå at disse modellene, selv om de til dels inneholder samme attributter som tilsvarende entiteter i databasen, ikke er avhengig av å ha en database med samme innhold. Prosjektreferanser Model-prosjektet er et uavhengig prosjekt og krever ingen referanser til andre prosjekter. 3.3 Datalaget Generelt Datalaget i RomSys består av filene gruppert under DAL-prosjektet (Data Access Layer). I datalaget er det implementert metoder for behandling av data inn og ut av database samt XML-filer. Filene i DAL- 53

54 prosjektet er på samme måte som Model-prosjektet kategorisert under tilhørende deler av applikasjonen. Figur 17: DAL Datalaget i RomSys har som oppgave å håndtere data fra forskjellige kilder. Under mappen show finner man filene som jobber med datahåndtering for visningsdelen av applikasjonen, mens i admin mappen finner man dataaksess-filene for administrasjonsidene. Web-scraping Under show mappen finnes det en fil som heter XmlTimeEdit.cs. Denne filen har som hovedoppgave å hente ut data fra en HTML-side som ligger på nettet. Denne HTML-siden inneholder skolens romreservasjonsliste i form av en HTML-tabell. Dataene skrapes fra HTML-siden og sorteres før de skrives ned til en XML-fil. XML-filen befinner seg på webserveren og er åpen for alle som trenger en oversiktlig og sortert liste av romreservasjoner i skolen. For å hente ut data fra HTML-siden har vi brukt et prinsipp som kalles for web-scraping. Prinsippet baserer seg på å filtrere en nettsides HTML-kode og plukke ut de dataene som er av interesse. I XmlTimeEdit.cs filen gjøres dette hovedsakelig i tre trinn: 1. Aksessere nettsiden og lese av innholdet. Vi har brukt en kombinasjon av objektene WebRequest og StreamReader for å laste ned HTML-koden og lese dens innhold. WebRequest klassen kan finnes under System.Net-biblioteket, mens StreamReader befinner seg under System.IO-biblioteket. WebRequest er abstrakt baseklasse, og tjener som.net-rammeverkets request/response-modell for tilgang til data fra Internett. Vi bruker WebRequest for å få tilgang til nettstedet. Med StreamReader leses nettsidens HTML-kode linje for linje helt til koden er slutt. All kode som er lest legges i en string og kan brukes senere. 54

55 Figur 18: Utdrag av kode fra metoden lastnedfratimeedit i XmlTimeEdit.cs-filen. Her vises deler av den metoden som laster ned HTML-kode fra TimeEdit og legger den i en string. 2. Filtrere ut nødvendig data fra HTML-koden og sette det inn i en liste. For å plukke ut nyttig data fra HTML-koden har vi brukt Regular Expressions (norsk: Regulære uttrykk). Som de fleste programmeringsspråkene støtter også C# regular exspressions. Det tilbys en god del verktøy for å jobbe med dette under biblioteket System.Text.RegularExpressions. Øverst i metoden lagliste i XmlTimeEdit.cs-filen er det definert fire regulære uttrykk: Figur 19: Regulære uttrykk i metoden lagliste som er medlem av XmlTimeEdit.cs-filen. Det første uttrykket ser etter en tabell i koden og plukker ut alt mellom <table> taggene i HTML-koden. Neste uttrykk henter ut alt som er mellom <tr> taggene. Et tabellrad i HTML defineres med taggen <tr>. Neste uttrykk ser etter innholdet i kolonnene, altså alt som er mellom <td> taggene. Siste uttrykk plukker ut det som er mellom <font> taggene. For å få de ønskede data ut i en struktur som gir mening, måtte vi bruke disse regulære utrykkene i en nøye uttenkt rekkefølge. Først plukkes HTML-tabellens innhold ut, altså alt mellom <table> taggene. Deretter plukkes informasjonen ut i fra hver kolonne i hver rad og settes inn i et List-objekt fra C#. Vi bruker List<> objektet fra biblioteket System.Collections.Generic. Listen er utgangspunktet for generering av XML-filen i neste trinn. Figur 20: Illustrasjon av HTML-kode som skrapes. OBS! Dette er ikke virkelige data fra TimeEdit, kun en illustrasjon. 55

56 3. Generere XML-fil ut fra dataene i listen fra trinn 2. For å gi applikasjonen en universell plattform har vi valgt å jobbe med XML. Alle reservasjoner som befinner seg i listen fra trinn 2 sorteres og skrives i XML-format. Denne XML-filen brukes som datakilde for reserversjoner. Vi lar RomSys selv opprette denne XML-filen. Hvis TimeEdit ved et seinere tidspunkt bestemmer seg for å servere en liknende XML-fil selv, kan denne benyttes i stedet. Figur 21: Utdrag av XML-filen som er reservasjonsdatakilden for applikasjonen. For å skrive dataene til en XML-fil har vi benyttet oss av klasser som tilbys av biblioteket System.Xml.Linq. Vi oppretter et objekt av instansen XDocument, og oppretter i dette objektet nye elementer i form av XDeclaration, XComment og XElement. Figur 22 viser et utsnitt av koden for skriving av XML fra metoden lagtimeeditxml i XmlTimeEdit.cs filen. Figur 22: Utsnitt av kode for skriving av XML. Dette er en utrag fra LagTimeEditXml metoden i XmlTimeEdit.cs-filen. I XmlTimeEdit.cs-filen finnes også metoder for å lese XML-filen. I metoden genererreservasjonlistefraxml er det kode for å lese fra XML-filen og generere en liste av dataene. Listen inneholder da Reservasjons-objekter (modell). Metoden genererromliste bruker denne listen for å opprette enda en liste, men denne gangen en sortert liste med Rom-objekter (modell). Hver Rom-objekt inneholder en liste av tilhørende Reservasjons-objekter. LINQ - Language Integrated Query I RomSys har vi benyttet av oss LINQ for håndtering av databasen. LINQ er basert på ORM-prinsippet (Object Relational Mapping) hvor det tillates konvertering mellom datatyper fra en database til objekter som er mulig å bruke i objektorientert programmering. LINQ er et av flere rammeverk for ORM. Ved bruk av LINQ genereres det automatisk en rekke objekter som tar utgangspunkt i de opprinnelige tabellene og deres rader. Dette gir muligheten for å håndtere databaseinformasjonen i RomSys direkte som objekter. LINQ-syntaksen brukes for å utføre spørringer som uthenting, sortering, filtrering og manipulering av data. LINQ-syntaksen benytter C# kode i stedet for SQL- 56

57 syntaks. Fordelen med ORM er at vi ikke har noen SQL-setninger i vår programkode, og dette er selvfølgelig ett stort pluss med tanke på SQL-injections. I Visual Studio 2008 tilbyr LINQ i form av LINQ to SQL Classes. For å opprette ORM-koblingen mellom vår database og datalaget benyttet vi oss av dette valget, og deretter la vi til alle relevante tabeller inn i en integrert visuell designer. Denne designeren oppretter ORM-objekter av alle tabellene som er lagt til i designeren, og relasjonene mellom objektene bevares tilsvarende som for de gjeldende tabellene. Som følge av disse relasjonene kan man gjennom ORM-objektet også få tak i attributter som tilhører tabellrader i andre tabeller enn det ORM-objektet man behandler. Figur 23: Tabellene og relasjonene fra databasen vises i den visuelle designeren. Når programmereren er ferdig med å bruke den visuelle designeren, oppretter LINQ et objekt av typen SqlDataContext. Dette objektet tas i bruk der vi ønsker en oppkobling mot databasen. ORMobjektene som opprettes er alltid à jour med databasens siste tilstand. Da tenker vi på databasens innhold hvis derimot databasens struktur endres, må det opprettes et nytt SqlDataContext-objekt. ORM-objektene må ikke forveksles med modellene fra modellprosjektet. ORM-objektene eksisterer kun i datalaget og er ikke nødvendig for resten av applikasjonen. Det er kun modeller fra modellaget som sendes ut eller inn i datalaget. Figur 24 viser et eksempel på dette. Figur 24: Eksempel på bruk av LINQ. Metoden befinner seg i StasjonRep.cs-filen under mappen admin i datalaget. 57

58 Eksempelet i figur 24 er hentet ut fra StasjonRep.cs-filen under mappen admin i DAL-prosjektet. Metoden i eksemplet demonstrerer bruken av SqlDataContext-objektet og LINQ-syntaksen. Objekttypen var er generisk og korrigeres til korrekt objekt ved kompilering. I dette tilfellet returneres et objekt av typen StasjonModell som er et objekt fra modell-prosjektet. Lambdauttrykket (s => (s.stasjonsnr == stid)) tilsvarer i vanlig SQL-syntaks: SELECT * FROM stasjon AS s WHERE s.stasjonsnr = stid I eksemplet i figur 25 vises en alternativ spørringsmåte, som fungerer på samme måte som lambdauttrykk. Denne måten for spørringer i LINQ er av utseende mer lik vanlig SQL-syntaks enn lambdauttrykket er. Dette er to likeverdige måter å formulere spørringen på, og vi har brukt begge spørringsmåtene i programkoden vår. Figur 25: Eksempel på bruk av annen spørringsmetode enn lambdauttrykk. Metoden befinner seg i RomRep.cs filen i DALprosjektet. Prosjektreferanser DAL-prosjektet har referanse til Model-prosjektet for å kunne bruke objektene som mottas og returneres. 3.4 Virksomhetslogikken Generelt Virksomhetslogikken består av filene under prosjektet BLL (Business Logic Layer). Dette laget er mellomleddet mellom datalaget og presentasjonslaget, og det er gjennom dette laget modellene passerer videre til presentasjonslaget eller før de returneres fra presentasjonslaget og til datalaget. 58

59 Serverside validering Hovedoppgaven i virksomhetslogikken er validering. Modellene som passerer gjennom, valideres før de sendes til målet. Alle data som skal til datalaget, valideres før de sendes dit. I RomSys har vi lagt inn validering av all inndata på serversiden. Valideringen gjennomføres av en rekke if-tester på attributtene til modellene. Figur 26 demonstrerer et eksempel på serverside validering som foregår i virksomhetslogikken. Figur 26: Eksempel på serversidevalidering i RomSys. Metoden befinner seg i StasjonKontroll.cs-filen under mappen admin i BLL-prosjektet. I eksemplet over tas et stasjonmodell-objekt inn som en parameter. Innholdet i modellens attributter sjekkes med if-tester. Hvis en eller flere av testene feiler, vil boolean-variabelen feil settes til verdien true og meldinger for hver feil vil legges inn i et ArrayList-objekt. Første element i listen vil 59

60 deretter settes til boolean-verdien true for å markere at valideringen har slått feil. Deretter returneres listen videre til presentasjonslaget. Hvis alle if-testene godkjennes vil metoden prøve å sende modellen videre til datalaget. Hvis det oppstår en feil under registreringen i datalaget, får boolean-variabelen lagringok verdien false. Da vil metoden igjen legge inn true i listens første posisjon, og samtidig legges passende feilmelding(er) inn i listens etterfølgende posisjoner. Listen returneres så til presentasjonslaget. Dersom if-testene godkjennes og datalaget returnerer positivt, vil første posisjon i ArrayList-objektet settes til false. Deretter vil metoden legge inn passende melding i listen, som så returneres tilbake til presentasjonslaget. Prosjektreferanser BLL-prosjektet har referanser til DAL-prosjektet og Model-prosjektet. 3.5 Presentasjonslaget Administrasjonssidene Generelt Presentasjonslaget i RomSys befinner seg i prosjektet romsys. Den består av to hovedapplikasjoner; Administrasjonssidene og visningsdelen av applikasjonen. Administrasjonssidene er bygget opp av ASP.NET-sider, mens visningsdelen er utviklet i Silverlight. Presentasjonslaget er utviklet som en webbasert applikasjon og er i likhet med de andre lagene utbyttbar. Applikasjonsstrukturen i RomSys gir grunnlaget for at det opprettes nye presentasjonslag for andre type plattformer som for eksempel skrivebordsapplikasjoner med Windows Forms og WPF (Windows Presentation Foundation). I dette kapittelet vil vi først se nærmere på administrasjonssidene. Deretter vil vi se på visningsdelen av applikasjonen i neste kapittel. Figur 27: Liste av utviklingsfiler for administrasjonssidene. Administrasjonssidene består av filene som er vist i figur 27. Hver.aspx-fil er knyttet til en.cs-fil. I Aspx-filene defineres brukergrensesnittet og kontrollerne, mens i.cs-filen finner man programlogikken som styrer disse. 60

61 Master Pages I administrasjonssidene har vi brukt ASP.NET Master Pages for å kontrollere layouten. Master Pages er en teknikk som brukes for å få en enstemmig og konsekvent layout i ASP.NET-applikasjoner. Teknikken baserer seg på at en enkelt hovedside definerer utseende og standard oppførsel for alle sidene (eller en gruppe sider) i applikasjonen. Fordelen med dette er at den som utvikler kan vende fokuset mer på innholdet og funksjonalitet enn på utseende. MasterPage-filen i RomSys heter HovedMaster.master og ligger under admin-mappen i presentasjonslaget. I denne filen er applikasjonens hovedutseende deklarert. For hver ASP.NET-side (innholdsside) i applikasjonen er denne.master-filen valgt som Master Page. Med dette fikk vi et felles hovedutseende i applikasjonen. Layouten kan defineres med statisk tekst, HTML-elementer (i kombinasjon med CSS) og serverkontrollere i MasterPage-filer. I tillegg til statisk tekst og kontrollere som vises på alle sider kan en Master Page også inneholde en eller flere ContentPlaceHolder-kontrollere. Denne kontrolleren fungerer som en plassholder, den definerer områder hvor utskiftbar innhold kan plasseres. Figur 28 viser et eksempel på bruk av ContentPlaceHolder-kontrollere fra MasterPage-filen i RomSys. Figur 28: Eksempel på bruk av ContentPlaceHolder i Master Page-en. Figur 29 viser et eksempel på ContentPlaceHolder i en innholdsside. Figur 29: Eksempel på bruk av ContetPlaceHolder i en innholdsside. 61

62 Ved forespørsel mot innholdsside fra klient, kombineres innholdssidens kode med masterpagens kode og det produseres en output hvor layouten er en kombinasjon av innholdssiden og masterpagen. ASP.NET Panel ASP.NET Panel-kontrolleren kan ses på som en beholder. Det er mulig å legge til andre serverkontrollere på denne beholderen. Panel-kontrolleren er spesielt nyttig i websider med former (engelsk: forms). Formene kan kategoriseres og vises etter tur i en brukervennlig måte. Siden disse panelene også er kontrollere selv, har de på samme måte som andre ASP.NET-kontrollere egne egenskaper som kan endres etter behov. Visible-egenskapen er viktig egenskap. Ved visibleverdien false vil panelen skjules og ved visible-verdien true vil den vises. Disse egenskapene kan settes både på forhånd ved deklarering og underveis i programlogikken. I administrasjonssidene har vi brukt ASP.NET-Paneler for å samle de forskjellige kontrollerne som hører sammen. I Figur 30 vises et eksempel på ASP.NET-Panel. Figur 30: Panel for registrering av ny stasjon. I hver administrasjonsside finnes det en eller flere paneler. Disse vises sjelden samtidig. For eksempel ved trykk på Registrer stasjon knappen i figur 30 blir det opprinnelige panelet skjult, mens det dukker opp to nye paneler for registrering av rom på gitt stasjon. (Se figur 31). Figur 31: Registrering av rom på stasjon. 62

63 I aspx-filen defineres alle paneler og deres innhold. For de panelene som ikke skal være synlige fra start, settes visible-egenskapen til false. (Se figur 32). Organiseringen av hvilke paneler som skal vises på siden skjer i programlogikken. Figur 32: Panelens visible-egenskap. Ved trykk på knappen i figur 32 utføres koden i programlogikken som hører til denne knappen. I denne koden programmerer vi hvilke paneler som vises for neste steg i form-et. (Se figur 33). Figur 33: Utdrag av btnregistrerstasjon_click metoden i NyStasjon.cs-filen. Meldingsbokser For hver operasjon som utføres i administrasjonssidene vises det en meldingsboks (Se figur 34). Meldingene forteller brukeren om operasjonen ble vellykket. Teksten i beskjedene er det innholdet som returneres fra virksomhetslogikken. Virksomhetslogikken validerer operasjonen og det returneres en ArrayList som inneholder passende beskjeder om hvordan det gikk. Figur 34: Meldingsboks Figur 35 viser metoden som mottar ArrayListen med beskjeder og viser de i meldingsboksen. Samtlige administrasjonssider i RomSys bruker denne metoden. Figur 35: Metode som viser returnert valideringsdata fra virksomhetslogikken. 63

64 3.6 Presentasjonslaget visningsdelen Generelt Visningsdelen i RomSys er utviklet i Silverlight. Utviklingsfilene befinner seg i prosjektet Show. Denne delen har under utviklingsprosessen fått navnet Show. Figur 36: Utviklingsfilene for Silverlight-applikasjonen. I Silverlight-prosjekter genereres det et kompilert xap-fil av hele applikasjonen. Denne filen fungerer som en zip-fil og inneholder nødvendige filer som trengs for å vise applikasjonen i en ASP.NET- eller HTML-side. Denne filen er det eneste som kreves for å vise Silverlight-applikasjonen i vår ASP.NETside. I RomSys ligger denne filen i prosjektet romsys under mappen ClientBin. Figur 37 illustrerer kodesnuttet som er nødvendig for å vise Silverlight-applikasjonen i en ASP.NET-side. Figur 37: Silverlight-applikasjon i ASP.NET-side. Silverlight-applikasjonen er bygget opp av en rekke egenutviklede brukerkontrollere. Disse kontrollerne er beskrevet i kapittel 2. WCF-Service Siden Silverlight av sikkerhetsmessige årsaker følger sandboks-prinsippet, måtte vi ta i bruk en WCFservice for å kommunisere med database og andre datakilder. Utviklingsfilen for servicen ligger i prosjektet romsys under mappen App_Code. Denne filen består såkalte OperationContract-er som definerer metodene som skal brukes. (Se figur 38.) 64

65 Figur 38: WCF-Service Med denne filen genereres det også en svc-fil. Det er denne filen som skal brukes som servicereferanse i de forskjellige applikasjonene som skal jobbe med servicen. For å referere Silverlightapplikasjonen til WCF-servicen har vi i Visual Studio 2008 høyreklikket på Service References - mappen og valgt Add Service Reference. Da dukker det opp et nytt vindu hvor du enten kan gi URLen til servicen eller klikke på en knapp kalt Discover. Denne knappen lister opp alle tilgjengelige servicer som kjører lokalt på maskinen. (Se figur 40). Figur 40: Referering mot WCF-Service. I figur 41 vises et eksempel på bruk av WCF-service i Silverlight for å hente informasjon fra databasen. Figur 41: Bruk av WCF-service i Silverlight. 65

66 RomsysServiceClient-objektet genereres automatisk etter at WCF-servicen blir referert. Objektet inneholder alle metodene som tilbys av servicen. Animasjoner Vi har brukt animasjoner i applikasjonen. Animasjonene vi har benyttet av oss er av typen DoubleAnimation. Denne typen animasjoner fungerer på en sånn måte at en gitt egenskap hos animasjonselementet forandrer seg i løpet av en gitt periode. I figur 42 viser vi et eksempel på kode for en DoubleAnimation i RomSys. Figur 42: Eksempel på animasjonskode. Denne metoden fader inn et element. Metoden i figur 42 fader inn et gitt element. Øverst i metoden ser vi at double-verdiene From og To blir henholdsvis satt 0 og 1. Dette vil si at elementet skal i begynnelsen være skjult og gradvis bli synligere. Double-verdien 1 tilsvarer maks synlighet mens 0 tilsvarer usynlig. Deretter settes Duration til 500 millisekunder, dette betyr at animasjonen vil vare i et halvt sekund. Nederste avsnitt i koden handler om hvilke egenskap i hvilke element som skal animeres. Her ser vi at det er OpacityProperty som blir satt for endring. Til slutt startes animasjonen med kommandoen Begin. Figur 43 viser et eksempel på bevegelsesanimasjon. Denne typen animasjon er blitt brukt for å scrolle nyhetene nederst i visningsdelen. Figur 43: Eksempel på kode for bevegelsesanimasjon. 66

67 Metoden i eksempel 43 virker på samme måte som metoden i figur 42. Begge to bruker DoubleAnimation teknikken. Forskjellen i bevegelsesanimasjonen er at From og To blir satt til posisjonene hvor elementet skal animeres fra og til. Legg også merke til at det er elementets LeftProperty-egenskap som forandres. 4 Databasen 4.1 Relasjonsdiagrammet I figur 44 vises relasjonsdiagrammet for databasen. Figur 44: Relasjonene mellom tabellene i databasen. Tabellen brukere er ikke i relasjon med noen andre tabeller. 4.2 Tabellbeskrivelser brukere Denne tabellen blir brukt til å lagre brukerdata og rettighetsnivå. Den blir brukt av administrasjonssidene for å verifisere innlogging. Datatypene for de forskjellige attributtene er vist i figur 45. Figur 45: Tabellen bruker. Brukernavnet er primærnøkkelen. Det vil si at tabellen ikke kan inneholde to brukere med samme brukernavn. 67

68 stasjon Denne tabellen inneholder data om stasjonene. Datatypene for de forskjellige attributtene er vist i figur 46. Figur 46: Tabellen stasjon. Vi har valgt å tildele hver stasjon et unikt nummer i tillegg til tittelen. Det er dette nummeret som er primærnøkkelen i stasjon-tabellen. rom Denne tabellen inneholder data om de forskjellige rom i systemet. Datatypene for de forskjellige attributtene er vist i figur 47. Figur 47: Tabellen rom. Siden oppdragsgiver har oppgitt at alle rom i deres lokaler har en unik romkode har vi brukt dette attributtet som primærnøkkel. stasjonrom Tabellen stasjonrom brukes for lagre data rom som hører til stasjoner. Datatypene for de forskjellige attributtene er vist i figur 48. Figur 48: Tabellen stasjonrom. Denne tabellen er i relasjon med både rom-tabellen og stasjon-tabellen. Den inneholder fremmednøkler fra disse tabellene. Fremmednøklene har vi satt som primærnøkler for å hindre dobbeltlagringer av rom som hører til stasjon. 4.3 Oppkobling til database Oppkoblingsdata (ConnectionString) til databasen er definert i datalaget. Datalaget kobler opp til databasen med oppkoblingsdataene vist i figur 49. Disse er definert i konfigurasjonsfilen app.config for DAL-prosjektet. 68

69 Figur 49: Oppkoblingsdata for databasen lagret i app.config-filen i DAL-prosjektet. 5 Sikkerhet 5.1 Brukerinnlogging og passordhashing For å få tilgang til administrasjonssidene må man være en bruker av systemet. Ved opprettelse av en bruker blir en passordidentitet lagret i databasen i form av en SHA1-hash. Ved innlogging blir det laget et SHA1-hash av det passordet brukeren taster inn og denne sammenlignes med brukerens SHA1-passordhash fra databasen. Hvis de to SHA1-hashene er like, er innloggingen vellykket. Se figur 50 for metoden som gjør om passordet til SHA1-hash. Figur 50: Kode for å generere SHA1-hash i datalaget. Metoden i figur 50 tar inn passord som parameter og returnerer SHA1-hash av den. Hash-en returneres som et byte-array. Figur 51: Metoden som brukes for å verifisere innlogging av brukere. 69

70 I figur 51 har vi vist koden som verifiserer innlogging av brukere. Et BrukerModell-objekt med brukerdata tas inn som parameter. Det lages et SHA1-hash av passordet. Deretter sjekkes det i databasen om kombinasjonen av brukernavnet og passordet finnes. Siden passordet er lagret som SHA1-hash sammenlignes hashene og ikke selve passordet. Hvis det finnes en kombinasjon av brukernavnet og passordet i databasen returneres true. Brukerne i RomSys kan kun opprettes av brukere med admin-rettigheter. Ved levering av produkt til oppdragsgiver vil det ligge inne en forhåndsdefinert admin-bruker. 5.2 Beskyttelse mot skadelige inndata RomSys benytter ASP.NET Request Validation for å stanse kjøring av ondsinnet kode gjennom inndatafelter. I tillegg til dette setter bruken av LINQ en effektiv stopper mot SQL- og scriptinjections. Figur 52 viser resultatet av å skrive inn et script i ett av inndatafeltene. Figur 52: Request Validation som stopper et script. 6 Brukergrensesnittet Visningsdelen av applikasjonen vår (skjermbildet som skal vises fram på stasjonene, og som dermed er den delen studentene vil se) er kodet i Silverlight. Dette er et valg vi har gjort fordi Silverlight gir muligheter ut over det man får med vanlig HTML-koding når det gjelder visuell framstilling. Det vi ser på som en fordel programmeringsmessig, kan imidlertid oppfattes som en ulempe i visningen av systemet; Silverlight må nemlig programmeres som et element med bestemt høyde og bredde målt i antall pixler. Dette gir oss den fordelen at vi kan bestemme nøyaktig utseende og størrelsesforhold på alle elementer som skal vises. Vi har valgt å skrive vårt system med en størrelse på 1280x

71 pixler (SXGA-oppløsning), og for å få optimal visning må applikasjonen derfor vises på en skjerm med dette SXGA-oppløsning. Denne oppløsningen finnes på nesten alle nyere skjermer, og det er i dag den mest brukte standardoppløsningen på 17" og 19" LCD-skjermer. Vi mener derfor at det ikke er noen stor ulempe å være bundet til denne fastlåste størrelsen, mens fordelene av å kunne bestemme utseendet så nøyaktig er svært nyttige både fra en programutviklers synspunkt og for å sikre en best mulig visning for brukerne av applikasjonen. Figur 53: Visuell utforming og bruk av farger All bruk av farger og den visuelle utformingen av applikasjonen er valgt med tanke på at skjermen skal være behagelig å se på. Vi har valgt farger som de fleste oppfatter som rolige det vil si at skjermen ikke føles kaotisk eller forstyrrende. Samtidig har vi sørget for god kontrast der man skal finne informasjon. Vi har spurt øvrige studenter ved datalinjen, og de oppfattet applikasjonen som behagelig. På administrasjonssiden har vi lagt inn beskrivende feilmeldinger for å gjøre administrator oppmerksom på hvorfor en funksjon ikke kunne utføres. Figur 54: Feilmelding på administrasjonssiden. 71

72 7 Implementering på server 7.1 Generelt Krav til serveren er spesifisert i kapittel 1.2. Det er forutsatt at disse kravene er oppfylt før implementering av applikasjonen på server. 7.2 Applikasjonspakken RomSys leveres som et.zip-arkiv med forhåndskompilerte.net-klasser. Databasen følger også med i pakken. Filene fra.zip-arkivet må pakkes ut til en mappe tilgjengelig for webtilgang. IIS versjon 5.0 sin mappe for filer som er tillatt webtilgang er som standard satt til C:\inetpub\wwwroot. Figur 55: Applikasjonspakken pakkes ut i C:\inetpub\wwwroot. 7.3 Konfigurering av IIS Etter at filene i applikasjonspakken er pakket ut til wwwroot mappen, vil IIS gjenkjenne disse filene og gjøre nødvendige konfigurasjoner automatisk. Det er viktig at versjonen på ASP.NET er satt til på feltet som vises i figur 56. Figur 56: ASP.NET versjon. 72

73 8 Implementering på klient 8.1 Generelt Systemkrav for klientsiden er beskrevet i kapittel 1.2. Her er det viktigste å ha en nettleser med Silverlight-støtte. 8.2 Automatisk oppstart av applikasjonen Vi har programmert en script som fungerer på den måten at når brukeren kjører scriptet, så åpnes Internet Explorer i fullskjermmodus, Status Bar-en skjules og nettsiden hvor applikasjonen kjører blir lastet inn. Alt dette skjer automatisk når scriptet startes. Før kjøringen av scriptet bør oppløsningen stilles til 1280x1024 pixler, som er størrelsen til applikasjonen. Scriptet kjøres deretter ved å dobbeltklikke på filen som heter RunApplication.ps1. For å kunne kjøre scriptet må brukeren på forhånd ha installert PowerShell. Figur 57: Scriptfilen 8.3 Manuell oppstart av applikasjonen Hvis du ønsker å starte applikasjonen manuelt gjøres det på følgende måte. Still oppløsningen til 1280x1028 pixler. Åpne nettleseren og fjern Status bar-en. Sett nettleseren på fullskjermmodus. Skriv inn URL-en til applikasjonen. Trykk på Stasjonsframvisning knappen i menyen til høyre. (Se figur 58). Figur 58: Stasjonsframvisningsknappen i menyen. 73

74 9 Videreutvikling 9.1 Utviklingsplattform Applikasjonen er utviklet i Visual Studio 2008 og delvis i Microsoft Expression Blend 3 og krever derfor en PC med Windows operativsystem installert. Databasen er bygget opp med Visual Studio 2008 og trenger ikke andre programmer for endringer. Visual Studio Service Pack 1 og Silverlight 3 toolkit må installeres for å jobbe med Silverlight-prosjektet..NET 3.5-rammeverket må også installeres for å kjøre applikasjonen slik som den er i dag. Det er imidlertid ikke nødvendig at denne blir brukt ved videreutvikling. 9.2 Datakilde for reservasjoner Vi fikk problemer da vi skulle finne en kilde for skolens reservasjoner. Løsningen på problemet ble å bruke web-scraping på en av TimeEdits-sider (Se kapittel 3.3). Dataene vi fikk ut med skrapingen lagret vi i en XML-fil. Denne XML-filen ble vår reservasjons-datakilde. Hele applikasjonen er bygget opp på en robust måte, og den vil kjøre så lenge det finnes en XML-fil med reservasjonsdata. Denne XML-filen genererer vi selv i applikasjonen. Fremtidige utviklere får kanskje muligheten til å bruke en XML-fil levert direkte fra TimeEdit. 9.3 Forslag til videreutvikling Historikk I applikasjonen eksisterer det ikke mulighet for historikk. Det hadde vært nyttig å ha en historikk funksjonalitet som gir admin-brukerne muligheten til å spore opp hvilke operasjoner som er utført av hvilke brukere og når. Meldingsbokser med ikoner I administrasjonssidene gis det meldinger for hver operasjon som utføres. Ikoner ved siden av meldingene hadde gitt klarere beskjeder til brukerne om hvorvidt operasjon var vellykket eller ikke. Manuell styring av kontrollere i visningsdelen I visningsdelen finnes det en rekke brukerkontrollere som presenterer forskjellige data, eksempelvis reservasjonsstatus for forelesningssaler og grupperom, samt nyheter, klokker og dato. Det er implementert funksjonalitet for automatisk organisering av disse kontrollene. Hvis valgt stasjon ikke inneholder grupperom, vises ikke grupperomskontrolleren; Hvis valgt stasjon kun inneholder grupperom, vises grupperommene i hovedrammen og ikke på hjørnet. I begge tilfellene endres også utseendet hos andre kontrollere på skjermen. Det hadde vært nyttig med funksjonalitet for manuell organisering av elementene i visningsdelen. Dette kunne for eksempel styres fra administrasjonssidene. 74

75 Kilder Liberty, J.; Maharry, D.; Hurwitz, D. (2008) Programming ASP.NET 4. Edition, USA: O'Reilly Media l_1.0_scripts All informasjon fra nettsider er samlet inn i perioden mars 2010 mai

76 76

77 Testdokumentasjon 77

78 Forord Denne rapporten omhandler testingen av systemet. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte finne det interessant. Ønsker du ytterligere informasjon om prosessen, teknisk informasjon om produktet, eller bruk av produktet henviser vi til henholdsvis prosess-, test- og brukerdokumentasjonen som er selvstendige dokumenter. 78

79 Innholdsfortegnelse 1 Innledning Enhetstester Utfyllende testing Case 1: Innlogging Prosess Resultat Kommentarer Case 2: Utlogging Prosess Resultat Case 3: Opprette en bruker Prosess Resultat Case 4: Endre en bruker Prosess Resultat Case 5: Avbryte endringer Prosess Resultat Case 6: Slette en bruker Prosess Resultat Kommentarer Case 7: Opprette en stasjon Prosess Resultat Case 8: Legge til et nytt rom Prosess Resultat Case 9: Fjerne et rom Prosess Resultat Case 10: Administrere en stasjon

80 Prosess Resultat Case 11: Relasjon mellom rom og stasjon Prosess Resultat Case 12: Administrere rom Prosess Resultat Case 13: Gå til Stasjonsframvisning Resultat Case 14: Tilkoblingsfeil Prosess Resultat Kommentarer Case 15: Stasjonsframvisning Prosess Resultat Konklusjon

81 1 Innledning Testdokumentet er skrevet for å gi en beskrivelse for de ulike testene som er utført mot applikasjonen. Dokumentet vil også fungere som en kvalitetssikring for de ulike kravene som er satt for systemet det sjekkes her om kravene som er satt tilfredsstilles. Applikasjonen RomSys er bygget som en testbasert løsning. Det er utført enhetstester mot systemet. I neste kapittel i dokumentet vil vi se på oppbygningen av disse enhetstestene. Deretter vil vi beskrive tester vi har utført mot systemet for å fange opp situasjoner og uregelmessigheter som kan oppstå, men som ikke dekkes av enhetstester. 2 Enhetstester Enhetstesting er en vanlig måte for å teste at kodeblokkene i systemet gjør det de er tiltenkt at de skal gjøre. I etterkant av utviklingsprosessen forteller disse testene at alle deler av systemet gjør det som er forventet. Testene fungerer i grunn som en kjørbar dokumentasjon. Testfilene er skrevet i Visual Studio og ligger under Test -prosjektet. Figur 1: Liste av testklassene i prosjektet "Test". Figur 2 viser et eksempel på en enhetstest fra en av testklassene i prosjektet Test. 81

82 Figur 2: Eksempel på et enhetstest. Enhetstestene er avhengig av Stubklasser som befinner seg i DAL-prosjektet (Se figur 3). Figur 3: Stubklasse fra DAL-prosjektet. Den generelle gangen i enhetstesting er som følger: Det opprettes en Stubklasse som inneholder informasjon om slags verdier man forventer å hente ut når en bestemt test kjøres. En slik Stubklasse skal etterligne databasen som programmet normalt ville benyttet seg av. Enhetstestingen går da ut på at man sender inn en forespørsel, og en testmetode behandler forespørselen og sender tilbake data avhengig av hva forespørselen gjaldt. Deretter blir de returnerte data sammenlignet med den 82

83 verdien som Stubklassen har lagret som forventet verdi for nettopp denne enhetstesten. Hvis disse to dataene er identiske, betyr det at enhetstesten har passert uten feil. Hvis derimot dataene er forskjellige, genererer enhetstesten en feil. Hvis alle enhetstestene passerer uten feil, betyr det i utgangspunktet at programmet fungerer etter hensikten. Figur 4 viser at vårt program har kjørt alle enhetstester uten noen feil. Figur 4: Resultatet av enhestestene i RomSys. 83

84 3 Utfyllende testing Selv om enhetstesting er et kraftig verktøy for testing av deler i applikasjonen, vil den ikke av seg selv fastslå at systemet fungerer som helhet eller at funksjonaliteten og brukeropplevelsen er som ønsket. For å dokumentere også dette, har vi gjennomført manuelle tester der vi gjennom systemets brukergrensesnitt har testet ut systemets funksjonalitet. Testene er utført med tanke på å fange opp situasjoner og uregelmessigheter som kan oppstå under vanlig bruk av systemet. Noen av disse testene er også relatert til Use-case modellene vi har tegnet for systemet. 3.1 Case 1: Innlogging Prosess Skriv inn URL, skriv inn brukernavn og passord logg inn/enter. Resultat - Det logges inn, brukeren får se sitt innloggingsnavn på hjørnet i den nye sikrede siden som vises. Kommentarer Hvis du har valgt å logge inn med en bruker som kun har standardrettigheter vil du kun få innloggingstilgang på typen Standard, mens brukeren med administrator rettigheter kan du logge inn på begge typene (Admin og Standard). 3.2 Case 2: Utlogging Prosess Logg inn med brukernavn og passord logg deretter ut. Resultat - Blir ført tilbake til innloggingssiden. 3.3 Case 3: Opprette en bruker Prosess Velg type Admin, logg inn med administratorbruker Velg NY BRUKER Skriv inn nødvendig informasjon velg brukerrettighet Admin eller Standard Trykk på Registrer Resultat - Fungerer som forventet. 3.4 Case 4: Endre en bruker Prosess Velg type Admin, logg inn med administratorbruker Velg en bruker Endre opplysninger eller passord på brukeren Trykk på Registrer Resultat - Fungerer som forventet. 84

85 3.5 Case 5: Avbryte endringer Prosess Velg type Admin, logg inn med administratorbruker Velg en bruker Endre opplysninger eller passord på brukeren Trykk på Avbryte for å avbryte endringer Resultat - Fungerer som forventet. 3.6 Case 6: Slette en bruker Prosess Velg type Admin, logg inn med administratorbruker Velg en bruker Trykk på slett Resultat - Fungerer som forventet. Kommentarer For at systemet alltid skal ha minst én admin-bruker har vi satt en sperre på at man ikke kan slette seg selv som bruker. Denne funksjonen er også testet og fungerer som det skal. 3.7 Case 7: Opprette en stasjon Prosess Velger type Standard, logger inn med enten standardbruker eller administratorbruker Skriver inn nødvendig informasjon Velger visningslengde Velg sett inn rom nå JA eller Nei Trykk til slutt på Registrer Resultat - Fungerer som forventet. 3.8 Case 8: Legge til et nytt rom Prosess Har du valgt Ja til å sette inn rom nå, blir du ført til en ny side for å gjøre dette. Vi går ut fra at du har gjort dette. I motsatt tilfelle, kan nytt rom kan også settes inn ved en senere anledning, og også et slikt tilfelle har blitt testet med vellykket resultat. Velg et eksisterende rom eller skriv inn et nytt Skriv inn riktig romkode Velg romtype Trykk på Legg til rom. Resultat - Fungerer som forventet. 3.9 Case 9: Fjerne et rom Prosess Velg et eksisterende rom Trykk på Fjern rom 85

86 Resultat - Fungerer som forventet Case 10: Administrere en stasjon Prosess Trykk på Stasjonsadministrasjon i menyboksen Endre opplysninger, slette en stasjon eller endre visningslengde Trykk på Lagre endringer Resultat - Fungerer som forventet Case 11: Relasjon mellom rom og stasjon Prosess Velg Rom og Stasjon på menyboksen Velg stasjon Om ønskelig kan vi også sette inn et nytt rom, trykk da på Nytt Rom Gjør som i Case 8. Resultat - Fungerer som forventet Case 12: Administrere rom Prosess Velg Romadministrasjon i menyboksen Velg et rom på listen Trykk på Fjern rom for å fjerne fra listen om ønskelig Sett inn et nytt rom med romkode om ønskelig. Resultat - Fungerer som forventet Case 13: Gå til Stasjonsframvisning Trykk på Stasjonsframvisning fra en av administrasjonssidene, eller fra innloggingssiden Siden for stasjonsframvisning startes. Resultat - Fungerer som forventet Case 14: Tilkoblingsfeil Prosess Slå av nettilgangen på maskinen Trykk på Stasjonsframvisning på innloggingssiden Velg stasjon Trykk på Velg. Resultat - Fungerer som forventet. En feilmelding dukker opp: Kunne ikke koble til, prøver igjen om 30 sekunder

87 Kommentarer Nettilgang er nødvendig for lasting av oppdaterte data i applikasjonen. Det hentes oppdatert informasjon fra en tredjepart to ganger hver dag. Når dette skjer, vil systemet forandre visning og det vil dukke opp en liten boks som viser framgangen. Hvis det er problemer med tredjeparten eller nettilgangen vil det dukke opp en feilmelding, og programmet vil etter 30 sekunder forsøke på nytt Case 15: Stasjonsframvisning Prosess Trykk på Stasjonsframvisning på innloggingssiden Velg stasjon Trykk på Velg Resultat - Fungerer som forventet. Framvisning er i gang. Vi ser at informasjonene er riktig plassert og sideoppdatering virker som det skal. 4 Konklusjon Både enhetstestene og de utfyllende testene har vist at systemet stemmer i henhold til forventningene. Alle enhetstestene har passert med positivt resultat, og det har ikke dukket opp uventede situasjoner under de utfyllende testene. Enhetstestene i kombinasjon med utfyllende tester vil sannsynligvis medføre at oppstart og bruk av systemet vil by på minimale problemer for oppdragsgiveren. 87

88 88

89 Brukermanual 89

90 Forord Denne rapporten omhandler bruken av systemet. Brukermanualen er skrevet for de personer som skal ta i bruk applikasjonen, RomSys. Dokumentet beskriver hvordan man bruker RomSys, med bilder og beskrivende tekst. Manualen kan også være interessant for sensorer og intern veileder ved Høgskolen i Oslo, og kan gjerne leses av andre som måtte finne det interessant. Ønsker du ytterligere informasjon om prosessen, produktet, og testingen henviser vi til henholdsvis prosess-, produkt- og testdokumentasjonen som er selvstendige dokumenter. 90

91 Innholdsfortegnelse 1 Innledning Forhåndsdefinerte brukere Logg inn Opprette en bruker Endre en bruker Slette en bruker Opprette en stasjon Legge til et nytt rom Administrere en stasjon Relasjon mellom rom og stasjon Administrere rom Stasjonsframvisning Beskrivelse av visningsdelen

92 92

93 1 Innledning Romsys består av to deler; Den første delen er administrasjonssidene og den andre delen er visningsdelen for de dataene som administreres. På administrasjonssidene har vi lagt inn beskrivende (feil)meldinger for å gjøre administrator oppmerksom på den til enhver tid gjeldende status. I brukermanualen er ikke alle feilmeldinger gjengitt, men meldingene er særdeles selvforklarende og skal ikke behøve ytterligere belysning. Vi anbefaler å lese manualen fra start til slutt for bedre forståelse og sammenheng av applikasjonen. 1.1 Forhåndsdefinerte brukere Merk! Applikasjonen leveres med 2 opprettede brukere; én med admin-rettigheter og én med standard-rettigheter. Vi anbefaler på det sterkeste at du sletter disse brukerne, eller i det minste endrer passord på dem. Følgende brukere leveres med applikasjonen: Type: Brukernavn: Passord: Type: Brukernavn: Passord: Admin-rettighet admin abc123 Standard-rettighet standard abc123 93

94 2 Logg inn Før visningsdelen kan startes for første gang, må du logge inn på administrasjonssiden. Applikasjonen er optimalisert for nettleseren Internet Explorer. Hvis du har tastet inn riktig URLadresse, får du opp dette bildet: Brukernavn og passord er nødvendig for innlogging. 1. Skriv inn brukernavn. 2. Skriv inn passord. 3. Velg type: Standard (administrere rom og stasjoner) eller Admin (administrere brukere). 4. Trykk på Logg inn knappen. 5. Trykker du på Stasjonsframvisning, vil du bli ført til visningssiden. 94

95 3 Opprette en bruker Ved oppretting av ny bruker, må du velge om den nye brukeren skal ha tilgang til å administrere andre brukere, eller om brukeren kun skal ha tilgang til å administrere rom/stasjoner. For å kunne administrere brukere, må det settes brukertype Admin, mens brukertype Standard kan kun administrere rom og stasjoner. 1. Skriv inn brukernavn med administratorrettighet. 2. Skriv inn passord. 3. Velg Admin. 4. Trykk på Logg inn. Du har nå logget deg inn på brukeradministrasjonssiden. Der kan du opprette en ny bruker på følgende måte: 1. Velg NY BRUKER. 2. Slett knappen er til for å slette en eksisterende bruker (les mer om dette i kapittel 5). 3. Skriv inn nødvendig informasjon om brukeren: fornavn, etternavn, e-post, brukernavn og passord. 4. Velg rettighet brukeren skal ha, Admin eller Standard. 5. Registrer bruker ved å trykke på Registrer. 6. Husk å logge ut. Trykk på Logg ut. 95

96 4 Endre en bruker Ved å velge en eksisterende bruker, kan du endre informasjonen om denne brukeren. Du kan også endre brukerens passord. 1. Trykk på rullegardinen til Bruker. 2. Velg en bruker (her olanor). 3. Endre Etternavn og/eller Epost etter behov. 4. Velg om du skal endre passord (Ja eller Nei). 5. Trykk Registrer for å registrere endringene, eller Avbryt for å annullere endringer du har gjort. 96

97 5 Slette en bruker Etter å ha valgt en eksisterende bruker, kan du velge å slette denne brukeren. Det er ikke mulig å slette seg selv. 1. Velg en bruker (her olanor). 2. Trykk på Slett for å slette. Det vil komme opp en melding som bekrefter at brukeren er slettet: 97

98 6 Opprette en stasjon For å opprette en stasjon, må du velge å logge inn som brukertype Standard. Dette er et valg du kan gjøre også hvis du er bruker med Admin-rettighet; Å velge type innlogging til å være Standard betyr bare at du kommer til siden for standardoppgavene en administrator kan utføre. 1. Skriv inn brukernavn. 2. Skriv inn passord. 3. Velg Standard. 4. Trykk på Logg inn. Etter å ha logget inn, kan du legge til en stasjon fra den første siden som vises: 1. Dette er menyen for rom- og stasjonsadministrasjonssiden. (Les mer om denne i de følgende kapitlene.) 2. Skriv inn en tittel til stasjonen. 3. Skriv inn en passende beskrivelse. 4. RSS 1 er adressen til rss-feeden. (Nyhetene fra denne feeden vil vises i visningsdelen.) 5. Velg visningslengden på rulleringen i visningsdelen. (Les mer om dette i kapittel 12.) 6. Velg om du vil sette inn rom nå eller ikke. 7. Trykk på Registrer stasjon-knappen for å registrere stasjonen. 98

99 7 Legge til et nytt rom Hvis du under opprettingen av en stasjon har valgt Ja til å sette inn rom med det samme, vil du få opp følgende skjermbilde. (Ikke fortvil hvis du valgte Nei, du kan legge inn rom senere også.) 1. Bekreftelse på at registreringen av ny stasjon er OK. 2. Identifikasjonsnummer for den opprettede stasjonen. 3. Velg et eksisterende rom fra databasen, eller velg NYTT ROM for å opprette et rom som ikke er registrert tidligere. 4. Hvis du skal opprette et rom som ikke tidligere er lagt inn i systemet, skriv da inn riktig romkode for det du skal legge inn. (Viktig at romkoden er lik med den fra TimeEdit.) 5. Velg hva slags type rom du skal registrere. 6. Trykk på Legg til rom. 7. Her vises en liste over de rommene som skal vises på stasjonen. 8. Hvis du har lagt inn et rom som ikke skal vises i denne stasjonen, merk da det aktuelle rommet fra listen og trykk på Fjern rom. 9. Følg denne linken hvis du skal opprette enda en ny stasjon. Om du ønsker å legge til et rom som allerede finnes i systemet, gjør du som vist under: 1. Velg et rom fra rullegardinen. 2. Trykk på Legg til rom. 3. Rommet er lagt inn i den aktuelle stasjonen. 99

100 8 Administrere en stasjon Du kan administrere opprettede stasjoner som vist under. Opplysningene om en stasjon kan endres, eller du kan velge å slette en stasjon fra databasen. 1. Trykk på Stasjonsadministrasjon i menyboksen øverst til høyre. 2. Velg en stasjon som skal endres. 3. Endre om ønskelig stasjonens tittel. 4. Endre om ønskelig stasjonens beskrivelse. 5. Rss-feed kan ikke endres. 6. Endre om ønskelig visningslengde. 7. Trykk på Lagre endringer, eller velg Avbryt for å forkaste endringene du har gjort. 8. Hvis du i stedet ønsker å slette den valgte stasjonen, trykk da på Slett. 100

101 9 Relasjon mellom rom og stasjon På denne menyen kan du se hvilke rom som er listet opp på de ulike stasjonene. Et rom kan høre til en eller flere stasjoner. Du kan også slette rom fra stasjonen eller legge til et nytt rom på stasjonen om ønskelig: 1. Velg Rom og Stasjon i menyboksen. 2. Velg en stasjon fra rullegardin-menyen. 3. Dette er en liste over de rommene som er registrert på valgt stasjon. 4. Hvis du vil legge inn et nytt rom på stasjonen, trykk på Nytt rom. Hvis du vil fjerne et av rommene som er knyttet til stasjonen, velg Fjern rom. 5. Hvis du valgte å legge til et nytt rom, får du opp ID og navn for den aktuelle stasjonen. 6. Velg et nytt rom som skal registreres på stasjonen. 7. Skriv inn romtittel (romkode) om det ønskede rommet ikke er i listen på nr. 6. (Viktig at romkoden er lik med den fra TimeEdit.) 8. Velg hva slags type rom du skal registrere. 9. Trykk på Sett inn rom, eller trykk Avbryt for å avbryte. 101

102 10 Administrere rom Det er lagt inn en funksjon for å liste opp absolutt alle rommene som finnes i systemet. Det er også mulig å legge inn et rom uten å knytte det opp mot en stasjon. Denne siden anbefales ved registrering av et større antall rom som skal benyttes for flere stasjoner. 1. Velg Romadministrasjon i menyboksen. 2. Liste over alle rommene som er lagt inn i systemet. 3. Merk av et rom og trykk på Fjern rom om det er ønskelig. 4. Legg et nytt rom til i systemet ved å skrive inn en romtittel (romkode). (Viktig at romkoden er lik med den fra TimeEdit.) 5. Velg hva slags type rom du skal registrere. 6. Trykk på Sett inn rom for å sette inn det nye rommet (rommet bli synlig i romlisten). Husk å logge ut. Du har sikkert observert at knappen for Stasjonsframvisning er synlig i alle administrasjonssidene. Denne knappen fører deg til visningsdelen. 102

103 11 Stasjonsframvisning Når rom og stasjon er satt opp på administrasjonssiden kan du vise stasjonene fram på visningsdelen: 1. Velg en stasjon. 2. Trykk på Velg. 3. Link til administrasjonssiden. Bruk denne hvis du vil tilbake for å gjøre endringer. 103

104 Når du trykker på Velg knappen vil applikasjonen hente nødvendige oppdateringer. Hvis det oppstår problemer under innhenting av data, vil systemet prøve på nytt hvert 30. sekund. 104

105 12 Beskrivelse av visningsdelen 1. RSS Nyhet Forelesningsinformasjon. 3. Analog klokke. 4. Grupperominformasjon. 5. RSS Nyhet 2 (rulletekst). 6. Dato og tid. 1. I denne delen av skjermen vil det vises fram nyheter fra et gitt RSS-kilde. Hvis det er mer enn to nyheter som skal vises, vil alle nyhetene vises etter tur i disse boksene. Tidsintervallet for hvor lenge nyhetene vises settes i siden som vises i kapittel Denne delen viser forelesninger i rom som hører til den aktuelle stasjonen. Her er det plass for seks rom per visning. Hvis det er flere enn 6 rom på stasjonen vil denne visningen på samme måte som nyhetsvisningen oppdateres etter gitt tidsintervall. 3. Dette er en analog klokke med time, minutt og sekundviser. 4. I denne delen av siden vises statusen på alle grupperom som er tilknyttet stasjonen. Hvis et grupperom er opptatt, vises det med både tekst og farger. I så fall vil det også vises for hvilke klokkeslett rommet er opptatt. Det er plass til 8 grupperom i denne delen; Hvis stasjonen har fått tilknyttet mer enn 8 grupperom, vil det skje en oppdatering etter gitt tidsintervall. 5. Her rullerer det nyhetsingresser fra samme RSS-kilde som i punkt Her vises dato og tid. 105

106 106

107 Vedlegg 107

108 108

109 Use Case Modeller Administrator og standardbruker 109

110 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Logge inn Bruker Bruker ønsker å logge inn Bruker har valgt å logge inn Bruker er logget inn 1. Systemet ber om brukernavn 2. Systemet ber om passord 3. Systemet ber brukeren velge type innlogging 4. Administratoren fyller ut feltene for brukernavn og passord 5. Brukeren velger enten å logge inn som administrator eller standardtype. Brukeren velger riktig type fra rullegardinmeny 6. Brukeren velger å logge inn 7. Systemet sjekker om bruker er gyldig 8. Bruker er innlogget 1-I Feil innlogging 1-a Systemet gir feilmelding og går ikke videre før brukernavn og passord er godkjent Brukeren er enten en standardbruker eller en administrator. Administrator kan logge seg inn som standardbruker. 110

111 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Legge til stasjon Administrator Administrator ønsker å legge til ny stasjon Administratoren har valgt å legge til en ny stasjon i databasen Stasjonen er blitt lagt til 1. Systemet ber om tittelen til den nye stasjonen, og en beskrivelse av hvor denne skjermen ligger 2. Administratoren fyller inn feltene for tittel og beskrivelse 3. Administratoren velger visningslengde fra rullegardinmeny 4. Administratoren kan sette inn rom nå eller seinere 5. Administratoren velger å registrere stasjon 6. Systemet lagrer informasjonen og oppretter database for denne stasjonen 7. Systemet gir melding til administratoren at ny stasjon er lagret 1-I Stasjonstittel er et obligatoriskfelt 1-II Stasjonsbeskrivelse er et obligatoriskfelt Systemet informerer administratoren og går ikke videre før tittelen og beskrivelsen av stasjonen er fylt ut 5-I Administratoren velger å ikke registrere denne stasjonen 5-a Systemet avbryter endringene og oppdaterer eksisterende side 10 sek er standard visningslengde per side, hvis det ikke velges en ny vislingslengde fra rullegardinmeny. Administratoren kan velge om et nytt rom skal settes inn nå eller ikke. Administratoren kan ikke endre adressen på RSS-kilden. 111

112 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Fjerne stasjon Administrator Administrator ønsker å fjerne en stasjon Administratoren har valgt hvilken stasjon som skal slettes fra databasen Stasjonen fjernes 1. Systemet ber om stasjonsnavn 2. Administratoren velger stasjon. 3. Systemet sjekker om stasjonen er gyldig 4. Administratoren velger å slette stasjon 5. Systemet sletter stasjonen 6. Systemet gir melding til administratoren om at stasjonen er slettet 3-I Ingen stasjon er valgt for fjerning 3-a Systemet informerer administratoren og går ikke videre før stasjon er valgt. 4-I Administratoren velger ikke å fjerne rommet 4-a Systemet avbryter endringene og oppdaterer eksisterende side Administratoren velger en eksisterende stasjon fra liste, rullegardinmeny eller lignende. 112

113 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Endre stasjon Administrator Administrator ønsker å endre eksisterende stasjon Administratoren velger å endre stasjon som allerede er lagret Systemet utfører endringen 1. Systemet ber om stasjonsnavn 2. Administratoren velger stasjon. 3. Systemet sjekker om stasjonen er gyldig 4. Administratoren endrer data 5. Administratoren velger å lagre endringene 6. Systemet lagrer endringene 7. Systemet gir melding til administratoren om at endringene er utført 3-I Stasjon må velges 3-II Stasjonstittel er et obligatorisk felt 3-III Stasjonstittel er et obligatorisk felt 3-a Systemet informerer administratoren og lagrer ikke endringene før stasjon er valgt. 5-I Administratoren ønsker ikke å lagre endringene 5-a Systemet avbryter endringene og oppdaterer eksisterende side Administratoren velger en eksisterende stasjon fra liste, rullegardinmeny eller lignende. Alle eksisterende infoer som er lagret for den stasjonen fra før kommer opp. 113

114 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Legge til rom Administrator Administrator ønsker å legge til rom til valgt stasjon Administratoren velger å legge til rom til valgt stasjon Systemet legger til rom 1. Administratoren velger stasjonen som et rom skal legges til. 2. Systemet ber om tittel til det nye rommet, og hvilken type rom det er. 3. Administratoren fyller inn feltet for romtittel, og velger romtype. 4. Systemet sjekker om rom er gyldig 5. Administratoren velger å registrere rom 6. Systemet lagrer informasjonen og oppretter database for dette rommet 7. Systemet gir melding til administratoren om at et nytt rom er lagret 4-I Romtittel er et obligatoriskfelt 4-a Systemet informerer administratoren og går ikke videre før romtittelen er fylt ut, og romtype er valgt. 5-I Administratoren ønsker ikke å registrere rommet 5-a Systemet avbryter endringene og oppdaterer eksisterende side Administratoren kan velge å legge til et eksisterende rom til valgt stasjon. All eksisterende info som er lagret for dette rommet fra før kommer opp. Administratoren kan også registrere rom i databasen uavhengig av stasjon. Den kan da senere legges til stasjon. Administratoren kan velge å legge til rom under innlegging av stasjon. 114

115 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Fjerne rom Administrator Administrator ønsker å fjerne rom Administratoren har valgt hvilket rom som skal slettes fra databasen Rommet fjernes 1. Systemet ber om romtittel 2. Administratoren velger romtittelen fra en liste. 3. Administratoren velger å slette rommet 4. Systemet sletter rommet 5. Systemet gir melding til administratoren om at rommet er slettet 1-I Ingen rom er valgt for fjerning 1-a Systemet informerer administratoren og går ikke videre før rom er valgt. Administratoren velger en eksisterende bruker fra liste, rullegardinmeny eller lignende. Alle eksisterende infoer som er lagret for dette rommet fra før kommer opp. Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Legge til bruker Administrator Administrator ønsker å legge til en bruker Administratoren velger å legge til en bruker Systemet legger inn brukeren i databasen 1. Systemet ber om fornavn, etternavn, epost, brukernavn, passord og brukertype. 2. Administratoren fyller ut alle felt 3. Administratoren velger å registrere bruker 4. Systemet sjekker om alle obligatoriske felt er fylt ut 5. Systemet legger inn bruker 6. Systemet gir melding til administratoren om at brukeren er registrert 1-I Manglende felt listes opp 1-a Systemet informerer administratoren og registrerer ikke brukeren før alle feltene er godkjent 3-I Administratoren ønsker ikke å registrere brukeren 3-a Systemet avbryter endringene og oppdaterer eksisterende side Administratoren kan velge en eksisterende bruker og foreta endringer. All eksisterende info som er lagret for den brukeren fra før kommer opp. 115

116 Use case Aktør Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Fjerne bruker Administrator Administrator ønsker å fjerne bruker Administratoren velger å fjerne bruker Systemet fjerner brukeren fra databasen 1. Systemet ber administratoren velge en bruker 2. Administratoren velger brukeren fra rullegardinmeny. 3. Administratoren velger å fjerne bruker 4. Systemet sjekker om bruker er valgt 5. Systemet sletter brukeren 6. Systemet gir melding til administratoren om at brukeren er slettet 1-I Ingen bruker er valgt for fjerning 1-a Systemet informerer administratoren og fjerner ikke brukeren før den er valgt 3-I Administratoren ønsker ikke å fjerne brukeren 3-a Systemet avbryter endringene og oppdaterer eksisterende side Administratoren velger en eksisterende bruker fra liste, rullegardinmeny eller lignende. Alle eksisterende infoer som er lagret for denne brukeren fra før kommer opp. Administrator kan ikke slette seg selv. Relatert informasjon om modellen Administrator og standardbruker : I disse beskrivelsene har vi valgt å sette administrator som aktør, men både standardbruker og administrator skal ha tilgang til samme system. Bortsett fra beskrivelsene legge til bruker og fjerne bruker, skal alle funksjoner være tilgjengelig for standardbruker også. Det er bare administrator som skal kunne legge til og fjerne bruker, og i tillegg skal administrator ha alle rettigheter til en standardbruker. 116

117 Arbeids- og iterasjonsplan Denne arbeidsplanen gjelder fra og med det tidspunkt oppgaven ble bekreftet fra oppdragsgiver og godkjent av skolen, det vil si 20. oktober Vi har delt arbeidet inn i iterasjoner fordi det gir en god oversikt underveis i prosjektet. Iterasjoner gjør at man raskere kan se framgang underveis, i og med at man kan se hvilke deler som er ferdige og hvilke som gjenstår. Planlegging/Forprosjekt OPPGAVE Tidsfrist Opprette hjemmeside for prosjektet 01/12-09 Prosjektskisse Kort presentasjon av oppdragsgiver og gruppe Beskrivelse av selve prosjektet Forprosjekt Definere problemområde Mål Bestemme tids- og arbeidsmessige rammer Bestemme teknologiske rammer ut i fra gitte kriterier Arbeidsplan og fremdriftsplan Iterasjon 0 Valg av teknologier Vurdere aktuelle teknologier opp mot hverandre, og velge det vi mener egner seg best for å løse oppgaven. Lage en skisse av applikasjonen Sette opp server & installere programmer o Operativsystem: Windows XP Pro (SP3) o Virtual desktop o IIS o Visual Studio 2008 o Expression Blend 3 o Database: Microsoft SQL Server 2008 Kravspesifikasjon, første utkast Identifisere krav og mulig funksjonalitet Gjøre ferdig modul 1 av programmet o Skraping av internettsiden o Skrive til XML-dokument Vurdere ulike utviklingsmodeller 05/ /01-10 Avsluttes uke 4 29/

118 Implementering og testing modul 2 OPPGAVE Iterasjon 1 Applikasjonen skal ha en database Applikasjonen skal kunne filtrere data En algoritme som filtrerer ut alle data med gitte kriterier Iterasjon 1-ii Tidsfrist Avsluttes uke 6 10/02-10 Avsluttes uke 6 Applikasjonen skal ha en admin-side Innloggingsside for systemadministrator Iterasjon 2 Applikasjonen skal ha et visuelt rammeverk Avsluttes uke 7 26/02-10 For å se resultatet av filtreringsalgoritmen i iterasjon 1 Applikasjonen skal ha algoritmer for lesing og visning av RSS feeder Iterasjon 3 Applikasjonen skal ha et oppsett for visning av forelesningssaler og klasserom Applikasjonen skal ha et oppsett for visning av grupperom Iterasjon 4 Applikasjonen skal ha et oppsett for RSS visning Applikasjonen skal ha en logo, klokke og dato Iterasjon 5 Testing av funksjonalitet Avsluttende arbeid og visuell tilpasning Avsluttes uke 9 12/03-10 Avsluttes uke 10 31/03-10 Avsluttes uke 16 23/

119 Dokumentasjon/prosjektstyring OPPGAVE Prosjektdagbok Dokumentering av hva som har blitt gjort Møtereferat Referat fra møter med intern og ekstern veileder/oppdragsgiver Referat fra gruppemøter Prosessrapport Dokumentasjon av hele prosessen Se dokumentasjonsstandard Produktrapport Frist Føres kontinuerlig gjennom hele perioden. Føres kontinuerlig gjennom hele perioden. 14. mai mai Se dokumentasjonsstandard Installasjons- og brukerveiledning 14. mai Testdokumentasjon 7. mai Avsluttende arbeid OPPGAVE Frist Forberedelse av presentasjon juni Presentasjon juni

120 Fremdriftsplan 120