Examensarbete i datalogi vid Stockholms universitet 2006

Nätundersökningar Utveckling av en prototyp för nätbaserade enkätundersökningar

Jonas Bergsten

Nätundersökningar Utveckling av en prototyp för nätbaserade enkätundersökningar

Jonas Bergsten

Examensarbete i datalogi om 20 poäng vid Matematisk-datalogiska linjens datalogiinriktning Stockholms universitet år 2006 Handledare vid Nada var Kjell Lindqvist Examinator var Yngve Sundblad TRITA-CSC-E 2006:084 ISRN-KTH/CSC/E--06/084--SE ISSN-1653-5715 Institutionen för numerisk analys och datalogi KTH 100 44 Stockholm

Sammanfattning

NätundersökningarUtveckling av en prototyp för nätbaserade

enkätundersökningar

Enkätundersökningar som genomförs på nätet kan ha stor betydelse förmedieföretag för att undersöka tittares reaktioner på det material somTV-sänds. För att en undersökning skall fungera och ge en korrekt bildav respondenters syn och åsikter måste ett flertal aspekter beaktas. Det-ta gäller så väl planeringen av undersökningen och dess genomförandesom analysen av inhämtade svar. Genomförande av nätbaserade un-dersökningar istället för pappersbaserade ger nya möjligheter men harockså sina begränsningar, vilket medför nya aspekter att beakta.

Målet med detta arbete är att designa och utveckla en prototyp förett generellt verktyg som ger möjlighet att genomföra nätbaserade en-kätundersökningar. Rapporten fokuserar speciellt på områden som an-vändbarhet för både respondenter och administratörer, interaktiva un-dersökningar med möjlighet att förmedla multimedia till respondentersamt regler för att automatiskt göra val om nästa steg i undersökningarbaserat på tidigare svar.

Abstract

Online PollsPrototype Development for Net based Polls

Online polls can play an important role for television networks in ex-amining viewer reactions regarding programming contents, trailers andcommercials. In order for a poll to be successful and give a correct in-dication of the respondent’s views several things have to be considered.This applies to both the planning, execution and analysis phase of thepoll. Conducting a poll online as opposed to a poll on paper brings upeven more things to consider. An online poll provides new abilities butalso new limitations.

The focus of this thesis is to design and develop a prototype for atool providing general purpose mechanisms for conducting polls online.Areas especially considered here include usability for both the respond-ent and the administrator, interactive polls with possibilities of relayingmultimedia to the respondent as well as rules to automatically branchin polls based on previous answers.

Innehåll

1 Introduktion 11.1 Viasat Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Egna mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Bakgrund 32.1 Datornätverk och Internet . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Klient-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 HTTP – Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . 42.4 CGI – Common Gateway Interface . . . . . . . . . . . . . . . . . . . 52.5 Formatmallspråk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.6 Reguljära uttryck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.7 HTTPS – Secured Hypertext Transfer Protocol . . . . . . . . . . . . 6

3 Val av arkitektur 73.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Operativsystem . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.2 Webbserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.3 Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.4 Programmeringsspråk . . . . . . . . . . . . . . . . . . . . . . 113.1.5 Formatmallspråk . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.1 Layoutspråk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.2 Olika sätt att visa media . . . . . . . . . . . . . . . . . . . . 143.2.3 Aktiv kod på klienten . . . . . . . . . . . . . . . . . . . . . . 15

4 Beskrivning av systemet 174.1 Grundläggande uppbyggnad . . . . . . . . . . . . . . . . . . . . . . . 174.2 Inloggning och säkerhet . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Resurser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4 Efterfrågan av en resurs . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 Metoder för ett generellt grafiskt gränssnitt . . . . . . . . . . . . . . 23

4.5.1 Språk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5.2 Inställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.5.3 Egna objekt i Smarty . . . . . . . . . . . . . . . . . . . . . . 264.5.4 Felmeddelanden . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Systemets funktionalitet 315.1 Resurser för alla användare . . . . . . . . . . . . . . . . . . . . . . . 31

5.1.1 Inloggning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.2 Nekad åtkomst . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.3 Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Resurser för slutanvändare . . . . . . . . . . . . . . . . . . . . . . . . 325.2.1 Navigering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.2 Enkätfråga . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 Administratörsdel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3.1 Hantering av användare och grupper . . . . . . . . . . . . . . 325.3.2 Persondata för användare . . . . . . . . . . . . . . . . . . . . 325.3.3 Administration av media . . . . . . . . . . . . . . . . . . . . 325.3.4 Administration av enkäter . . . . . . . . . . . . . . . . . . . . 335.3.5 Skapa och redigera enkät . . . . . . . . . . . . . . . . . . . . 335.3.6 Skapa och redigera fråga . . . . . . . . . . . . . . . . . . . . . 345.3.7 Hantering av lagrade svar och andra data . . . . . . . . . . . 35

6 Rekommendationer 376.1 FastCGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Undersökning av hur systemet används . . . . . . . . . . . . . . . . . 376.3 Utökad funktionalitet . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Litteraturförteckning 39

Kapitel 1

Introduktion

Detta kapitel beskriver bakgrunden till, förutsättningar för och målsättningar medarbetet som ligger till grund för denna rapport.

1.1 Viasat Broadcasting

Viasat Broadcasting är ett företag vars verksamhet innefattar TV-sändningar i egnasvenska TV-kanaler.

När Viasat köper in nya TV-program marknadsförs de på olika sätt för att fåså många tittare som möjligt. Ett sätt som denna marknadsföring genomförs på ärgenom att sända så kallade trailers i de egna TV-kanalerna. En trailer kan enklastbeskrivas som en reklamfilm för en film eller ett TV-program. Den består av enkortare sekvens med bild och ljud, oftast delvis taget från det program den görreklam för. Trailerns syfte är att fånga tittarnas uppmärksamhet och försöka göraden som ser trailern mer benägen att vid ett senare tillfälle se motsvarande filmeller TV-program.

1.2 Mål

Viasat efterfrågar ett datorbaserat system med vars hjälp man kan undersöka huren trailer eller ett program påverkar tittarna. Detta skall ske genom att först visaett antal personer den trailer eller det program som skall undersökas, och därefterställa en serie frågor.

De personer som deltar i undersökningarna skall ha tillgång till de TV-kanalersom programmen sänds i. För att kunna nå en så stor del av denna grupp sommöjligt på ett billigt sätt är målet att låta deltagarna genomföra undersökningarnavia Internet. Deltagarna skall gå in på en hemsida och därifrån kunna se den trailersom skall undersökas och sedan svara på de frågor som ingår i undersökningen. Desvar som lämnas skall sedan sparas på ett sådant sätt att de vid ett senare tillfällekan analyseras på olika sätt.

1

Utifrån en sådan undersökning skall sedan beslut kunna tas om vilka trailerssom ska sändas och vilka som behöver ändras eller tas bort. Önskvärt är också attkunna utvärdera nya programidéer så att osäkerheten inför en lansering minskar.

Dessa undersökningar ska inte bara mäta uppmärksamhet hos tittarna, utanockså preferens och köpintention. Det är därför viktigt att kunna förstå vad det äri en trailer eller i ett program som är intressant för tittaren. Vad är det som gör attuppmärksamheten väcks, vad är det man uppmärksammar och vad är det som göratt preferensen blir högre eller lägre.

Ett viktigt steg i varje undersökning är att sätta samman den panel som skallbesvara frågor. Hur denna panel skall sättas samman ligger utom ramen för dettaarbete, som förutsätter att en befintlig panel finns tillgänglig. För en diskussion avhur en panel bör sättas samman och alternativ till en sådan se [1].

1.3 Egna mål

Utöver de mål som ställts upp för detta arbete av uppdragsgivaren Viasat Broad-casting, har ytterligare några mål med arbetet satts upp som syftar till att ökavärdet av arbetet för författaren. Dessa mål består i att inhämta kunskaper samtatt göra systemet användbart och tillgängligt.

Hur tillgängligt ett system blir och möjligheten att använda det i olika samman-hang beror på flera olika saker. Två viktiga faktorer är:

• Att systemet släpps under en öppen licens.

• Att systemet inte är bundet till andra program eller system som inte också ärsläppta under en öppen licens.

Med öppen licens avses här de licenser som räknas till det engelska begreppet”Open source” (t.ex. GNU General Public License). Detta innebär inte bara att enanvändare slipper betala pengar till upphovsrättsmannen, det innebär också att enanvändare har rätt att ändra på produkten. Möjligheten att själv kunna ändra påen produkt kan många gånger vara en förutsättning för att kunna använda den.

Angående de kunskaper som inhämtas under arbetet är det författarens åsiktatt de är mer värdefulla om de inte baseras på information om system eller teknikervars användande i stor utsträckning begränsas av upphovsrättslagar eller patent.

Ett mål med arbetet har därför varit att, i den mån det inte står i konfliktmed uppdragsgivarens mål, i arbetet endast skapa beroenden till system som ärtillgängliga under en öppen licens.

2

Kapitel 2

Bakgrund

Detta kapitel beskriver olika tekniker som används i detta arbete. Inget områdesom tas upp här beskrivs på ett uttömmande sätt, utan endast i den utsträckningsom bidrar till den förståelse för området som förutsätts senare i rapporten, ellersom på annat sätt förväntas förenkla läsandet av rapporten.

2.1 Datornätverk och Internet

Datornätverk används för att föra information mellan olika datorer. Det som deflesta tänker på när de hör ordet datornätverk är kanske Internet, som är det störstabefintliga datornätverket. Det finns emellertid många andra datornätverk. Många avdessa, men inte alla, har samma struktur och fungerar på samma sätt som Internet.För att olika datorer skall kunna kommunicera med varandra måste det finnas enstandard för hur det skall gå till, på samma sätt som två personer måste kunna ettgemensamt språk för att kunna kommunicera. Den standard som används i Internetoch i många andra datornätverk är ett protokoll som benämns TCP/IP. Det finnsäven många andra protokoll för kommunikation. Eftersom detta examensarbetebaseras på Internet kommer, om inte annat anges, alla fortsatta resonemang omdatornätverk att förutsätta att det är Internet och TCP/IP som används. För enutförligare beskrivning av Internets struktur och protokollet TCP/IP se [7].

En viktig egenskap hos Internet är att det är öppet. Det finns i princip ingenbegränsning utan om en resurs är tillgänglig så är den tillgänglig för alla som har till-gång till Internet. Det finns inget inbyggt sätt att dela ut eller begränsa rättigheter.Detta kan ses både som Internets stora styrka och som ett hot mot datoranvändaressäkerhet. Denna frihet innebär att om man vill begränsa tillgången till en resurs,så måste det finnas ett separat system på den dator som tillhandahåller resursensom tar hand om den saken. Det utan tvekan vanligaste sättet att hantera dettaär att låta den användare som vill komma åt en resurs först ange ett förutbestämtlösenord.

En annan egenskap hos Internet som kan inverka negativt på säkerheten hosett system, är att det i princip aldrig går att vara säker på att en kommunikation

3

mellan två parter inte avlyssnas av en tredje part. Detta har flera olika orsaker, enviktig orsak är att Internet är decentraliserat. När information går från en dator tillen annan, passerar den ett okänt antal andra datorer på vägen. Varje person somadministrerar en sådan dator kan se all information som överförs mellan avsända-ren och mottagaren. Därför bör information som man vill begränsa tillgången tillkrypteras innan den förs över Internet, så att det som går att avlyssna inte längregår att tyda. Lösenord hör förstås alltid till den kategori av information som börkrypteras.

2.2 Klient-server

Klient-server är en arkitektur för datorkommunikation. I den betraktas varje datorantingen som en server eller som en klient. En server gör inte något innan den blirkontaktad av en klient med en begäran om att utföra något. När en server får enbegäran utför den det jobb som efterfrågas och skickar vanligen tillbaka ett svar. Ettexempel på detta är när en webbläsare skickar en begäran om en webbsida till enwebbserver. I detta fall är själva svaret från servern det som efterfrågas av klienten.I andra fall kan det arbete som servern utför vara det som klienten efterfrågar. Ettexempel på detta är när man skickar e-post. Då tar en klient kontakt med en serveroch ber den att skicka brevet. Servern skickar brevet och svarar troligen att det gickbra och att inga fel uppstod. I detta fall är det inte svaret som är den huvudsakligauppgiften för servern.

En server kan ha flera klienter kopplade till sig samtidigt, som fallet var i de tvåexemplen ovan. Det finns heller inget hinder mot att en klient ansluter sig till merän en server samtidigt.

Eftersom man sällan vet när en klient kommer att försöka ansluta till en server,måste servern hela tiden stå beredd och vänta, vilket ofta innebär att en serveralltid måste vara påslagen. För att en klient skall kunna ansluta måste det ocksåköras ett program på servern som förstår meningen med den begäran som klientenskickar. Inget av dessa krav gäller för klienten, som bara behöver vara aktiv justnär en kommunikation med servern skall ske.

2.3 HTTP – Hypertext Transfer Protocol

Som nämnts tidigare följer kommunikationen mellan en webbläsare och en webb-server klient-server-modellen. Det protokoll som de två delarna använder för attkommunicera benämns ”Hypertext Transfer Protocol” och förkortas HTTP. Nam-net är något missvisande då protokollet inte är begränsat till att överföra hypertext,utan till och med har ett inbyggt stöd för att beskriva vilken typ av data som över-förs. HTTP är byggt för att överföra filer från servern till klienten. Lite förenklatsett skickar klienten namnet på den fil den vill få överförd och servern svarar medatt skicka tillbaka filens innehåll.

4

2.4 CGI – Common Gateway Interface

I vissa situationer vill man kanske skicka mer information än vilken fil man önskarfå överförd. Detta är t.ex. fallet när man söker information på Internet. Man kandå använda en sökmotor. Svaret från en sökmotor är en vanlig webbsida, men denfanns inte lagrad i en fil eftersom resultatet berodde på vad som eftersöktes.

Protokollet ”Common Gateway Interface” (CGI) är en teknik som används föratt överföra utökad information av ovan nämnda typ. När CGI används anges istäl-let för namnet på en fil som skall överföras namnet på ett program som skall köras.Allt som programmet sedan skriver ut innan det avslutas skickas tillbaka till webb-läsaren. Indata till detta program kan överföras på två olika sätt. Antingen kaninformation kodas in i adressen till webbsidan eller skickas separat. Vilket alterna-tiv som passar bäst beror på tillämpningen. Om man kodar in information i adressenså kan användaren köra samma program med samma indata en gång till genom attbara spara adressen. Det innebär till exempel att en användare kan skapa ett bok-märke till en utsökning i en sökmotor och inte bara till sökmotorns startsida. Ommycket information skickas till det program som skall köras, kan det vara olämpligtatt koda in det i adressen eftersom den kan se konstig ut och bli svår att tyda föranvändaren. Om känslig information som lösenord överförs är det inte heller lämp-ligt att koda in den i adressen, dels för att den kan synas utskriven i en webbläsareoch dels för att en användare kanske inte väntar sig att en adress skall innehållahemlig information.

2.5 Formatmallspråk

Eftersom resultatet från ett CGI-program skickas till en webbläsare innebär det attresultatet måste vara på ett format som förstås av webbläsaren. Detta innebär of-tast ett layoutspråk som t.ex. HTML. Ett CGI-program är alltså ofta kod som i sintur skapar ny kod i ett annat språk. Att skriva kod som skapar ny kod är en uppgiftsom skiljer sig mycket från uppgiften att beräkna och ta fram den information somlayoutkoden skall innehålla. Det är därför önskvärt att separera de två delarna avett CGI-program. En vanlig situation är att endast delar av layoutkoden är dyna-misk och ändras mellan olika körningar av CGI-programmet. För att åstadkommaönskvärd separation och underlätta framtagandet av CGI-program i den situationsom beskrevs ovan används ofta formatmallspråk (en. template engines). Vid an-vändande av ett formatmallspråk delas ett CGI-program in i två delar, dels ettprogram som bestämmer det dynamiska innehållet och dels en mall som beskriverformatering av innehållet och som också innehåller den information som är statisk,dvs. inte ändras. I mallen används olika former av kodord för att markera var ochhur dynamiskt innehåll skall inkluderas i mallen.

En tendens bland formatmallspråk är att tillåta att beräkningar inte bara utförsi huvudprogrammet utan även med hjälp av formatmallen. Motivationen för dettaär ofta att vissa former av beräkningar som avrundning av tal och andra mindre

5

uppgifter är naturligare att utföra i den kod som styr layout, d.v.s. formatmallen.För en diskussion om formatmallspråk och hur inkludering av för mycket kod iformatmallar kan undvikas se [9].

2.6 Reguljära uttryck

Reguljära uttryck utgör ett språk vars syfte är att beskriva andra språk. I mervardagliga termer kan reguljära uttryck beskrivas som ett verktyg för att känna igenmönster i och extrahera delar ur en text. En stor styrka hos denna konstruktionär att den fokuserar på vad som skall göras och inte hur. Det innebär att kodenför att lösa en uppgift ofta blir kortare och tydligare om reguljära uttryck används.Det bör påpekas att verktyget måste användas på rätt sätt för att uppnå nämndaegenskaper, det kan som många andra verktyg missbrukas för att konstruera kodsom är mycket svårförståelig. För mer information om begreppet se [6].

2.7 HTTPS – Secured Hypertext Transfer Protocol

HTTPS är ett nyare protokoll än HTTP och möjliggör att data skickas krypteradmellan webbserver och webbläsare. Detta sker med hjälp av protokollet Secure Soc-kets Layer (SSL) eller dess efterföljare Transport Layer Security (TLS). Både SSLoch TLS använder sig av tekniken asymmetrisk kryptering, som bland annat möj-liggör att två parter kan kommunicera via en krypterad informationskanal, utan attförst ha träffats (eller kommunicerat på annat sätt) för att komma överens om ettgemensamt lösenord.

6

Kapitel 3

Val av arkitektur

Detta kapitel beskriver vilka val som gjorts beträffande de komponenter och teknikermed vilkas hjälp systemet är uppbyggt. En faktor som spelar in i dessa val ärvem som använder systemet. Dessa personer kan delas in i två grupper. Den förstagruppen är de som med systemets hjälp vill utföra en undersökning, som vi från ochmed nu kallar administratörer. Den andra gruppen består av de personer som skalldelta i undersökningarna, dessa kallar vi slutanvändare. Termen användare kommeratt beteckna såväl administratörer som slutanavändare.

En sak som är viktig i alla typer av enkätundersökningar är att få ett så litetbortfall som möjligt. Med bortfall avses när en person som blivit delgiven enkäteninte ger något svar eller ger ofullständiga svar genom att t.ex. inte besvara allafrågor. En av orsakerna till bortfall kan vara tekniska hinder. Detta är en viktig sakatt beakta vid valet av de komponenter som slutanvändaren kommer i kontakt med.Ett dåligt val i detta sammanhang skulle kunna leda till att en person som är villigatt delta i en undersökning inte kan det på grund av t.ex. det operativsystem hananvänder. Till tekniska hinder bör man också räkna saker som inte är oöverkomligahinder. Orsaker i denna kategori kan vara att en slutanvändare tröttnar för attnågot känns krångligt, för mer information se [2] och [3]. Bortfall kan även hamånga andra orsaker, för en diskussion av detta se [5]. Det bör alltså vara ett målatt i alla sammanhang förenkla för slutanvändaren för att göra denne mer benägenatt delta i undersökningar.

Ett tidigt val som uppkommer är att bestämma hur kommunikationen över In-ternet skall ske för att förmedla frågeställningar till slutanvändare och sedan fåderas svar insamlade. En grundförutsättning för att detta skall kunna ske är att detpå datorerna i båda ändar finns programvara som kan sköta denna kommunikation.Eftersom ett viktigt mål är att förenkla för slutanvändaren, så är det rimligt attbörja med att titta på vilken programvara som skall användas hos denne. Här finnsdet två val. Det ena är att låta slutanvändaren installera programvara på sin dator.Det andra är att använda programvara som man tror finns installerad på slutanvän-darens dator. En fördel med att låta slutanvändaren installera programvara på sindator är att det går att bestämma helt hur den skall se ut. En fördel med att använ-

7

da programvara som man tror finns tillgänglig på slutanvändarens dator är att detom det fungerar rimligen är enklare för slutanvändaren att inte behöva installerany programvara. Det kan även vara så att slutanvändaren inte har möjlighet attinstallera programvara på sin dator. Det är ett säkerhetsproblem för användare attinstallera programvara. Det är idag på de flesta plattformar inte vanligt med systemsom kan begränsa rättigheter till vad program kan göra. Detta är ofta skälet till attanvändare saknar rättighet till att installera program. Det är också möjligt att enslutanvändare med dessa rättigheter väljer att inte göra det eftersom han inte litarpå den som utför undersökningen. På grund av dessa orsaker är det en klar fördelom man uteslutande kan använda sådan programvara som redan finns tillgängligpå slutanvändarens dator.

Olika användare har olika operativsystem och väljer även i övrigt att användaolika programvaror. För systemets slutanvändare är tillgång till Internet en förut-sättning. En programvara som finns på praktiskt taget alla datorer med anslutningtill Internet är en webbläsare. Alla större operativsystem avsedda att användas påpersondatorer levereras med en webbläsare installerad redan från start. Med dettasom bakgrund blev valet att använda webbläsare och webbserver för den kommuni-kation som skall ske.

Resten av de val som skall göras kan delas in i två grupper. Den ena innefattar desom har med servern att göra, dvs. den dator som webbservern körs på. Den andrainnefattar de val som har att göra med klienten, dvs. den dator som webbläsarenkörs på.

3.1 Server

De komponenter som servern är uppbyggd av kommer bara administratörer attkomma i kontakt med. Här finns alltså inte samma önskemål som beträffande slu-tanvändarens dator, om att inte installera någon programvara.

Det enda krav vi hittills ställt på servern är att kontakten med klienten skall skemed hjälp av en webbserver. Förutom en webbserver kommer servern att behövaanvända sig av andra system, nedan följer en diskussion av dessa.

3.1.1 Operativsystem

Precis som andra datorer kommer servern att behöva ett operativsystem. Vilka kravsom ställs på operativsystemet i detta fall beror i första hand på vilken annan mjuk-vara som kommer att användas av servern. Ett program som skall användas måstevara skrivet för att fungera tillsammans med det aktuella operativsystemet. Detfinns också några grundläggande krav som måste uppfyllas av operativsystemet.Dessa innefattar bland annat möjligheten att använda Internet och möjlighetenatt köra flera program samtidigt (multitasking). Dessa krav är dock uppfyllda av iprincip alla moderna operativsystem och blir därför inte så styrande då de endastexkluderar gamla operativsystem eller sådana som är ovanliga och mycket special-inriktade.

8

Målsättningen att göra systemet så tillgängligt som möjligt har gjort det önsk-värt att systemet inte är beroende av ett speciellt operativsystem utan kan fungeramed flera olika. Många program skrivs avsiktligt för att fungera tillsammans medmånga olika operativsystem. För att uppnå målet ovan kommer därför system skriv-na på detta sätt att användas. Detta gäller både de färdiga systemen och den kodsom skrivits under arbetets gång.

3.1.2 Webbserver

Det första krav som bör ställas på en webbserver förutom att uppfylla protokolletHTTP är möjligheten att köra andra program för att skapa de sidor som skallskickas till klienter. Det bästa alternativet är om detta sker med stöd av protokolletCGI eftersom detta protokoll stöds direkt i webbläsare och därför ställer mindrekrav på den miljö som skall finnas på en klientdator.

Vidare är det en fördel om webbservern har stöd för protokollet HTTPS. Omså är fallet kan webbservern kommunicera krypterat med webbläsare som stödjerprotokollet, utan att någon ny kod behöver skrivas. Detta är inte endast en fördelgenom att det underlättar utvecklandet av systemet, användandet av ett eget systemför krypterad kommunikation skulle också leda till ökade krav på klienten i form avinstallerade program eller annan närvaro av körbar kod.

Det finns ett flertal webbservrar tillgängliga under en fri licens som uppfylleralla dessa krav. Tre exempel är:

• Apache – http://httpd.apache.org/

• Cherokee – http://www.0x50.org/

• Jetty – http://jetty.mortbay.org/

Den webbserver som valts i detta arbete är Apache. Ett mål har emellertid varitatt skriva koden så att den i princip går att använda med varje webbserver somuppfyller ovan ställda krav.

3.1.3 Databas

Systemet behöver lagra data av olika slag, mest uppenbart är nog behovet av attlagra svar på enkätfrågor. Det skulle i princip gå att använda en vanlig textfil avsamma typ som används i en vanlig editor för att lagra data. Ett i många fall vanli-gare alternativ är att istället använda en färdig databashanterare. Detta alternativhar flera fördelar över att systemet själv lagrar data direkt i en fil. Den mest uppen-bara fördelen är att den kod som finns i en databashanterare inte behöver skrivasom i ett eget system. Vidare gäller att om två eller fler delar av ett system skalllagra data i en fil samtidigt måste det hanteras på ett speciellt sätt för att det inteskall uppstå problem. Detta är aktuellt i vårt system eftersom flera användare skallkunna använda systemet samtidigt. Detta är ett exempel på ett problem som helt

9

kan lösas med färdig kod, och inte behöver hanteras i den egna koden om en data-bashanterare används. En annan viktig funktionalitet som finns i databashanterareär möjligheten att extrahera och söka efter data med hjälp av ett frågespråk. Ettfrågespråk är ett eget språk som är anpassat just för ändamålet att hantera ochmanipulera en databas. Eftersom språket är speciellt anpassat för databaser gårdet oftast att beskriva vad som skall utföras på ett enklare sätt än med ett vanligtprogrammeringsspråk.

Databashanterare kan delas in i två grupper beroende på hur de fungerar. Detena alternativet är en databasserver, som är ett eget program. Det andra alternativetär att databashanteraren består av en uppsättning funktioner som kan användasi det egna programmet, i detta fall fungerar inte databashanteraren som ett egetprogram utan som en del av det egna programmet.

En fördel med det senare tillvägagångssättet är att det i de flesta fall är enklareatt skriva program som inte förlitar sig på kommunikation med andra program.Eftersom en databasserver är ett eget program måste dessutom det programmetstartas innan det kan användas. Detta medför att det normala är att en databasser-ver alltid är igång, vilket i vissa fall kanske inte är möjligt eller önskvärt. I sådanafall innebär det senare alternativet en klar fördel. Vidare är en databasserver just enserver, det vill säga ett program som kontaktas av andra program, eventuellt frånandra datorer. Varje program som fungerar och används som en server utgör ensäkerhetsrisk eftersom serverns syfte är att användas av utomstående. Ett fel i ser-vern kan medföra att en användare får allt för stora möjligheter och i värsta fall fulltillgång till den dator som servern körs på. I vårt fall behöver emellertid databasser-vern bara kunna kommunicera med program på samma dator, all kommunikationmed andra datorer kan därför förbjudas antingen med hjälp av databasservern själveller med externa verktyg.

En effekt av att använda en webbserver och protokollet CGI är att varje gång enklient skickar en förfrågan till servern måste programmet som bestämmer vad somskall utföras och vad som skall skickas tillbaka startas på nytt. Det går alltså inteatt låta det programmet fortsätta sin exekvering mellan olika anrop från klienter.Detta innebär att data som behöver bevaras mellan olika anrop till servern intekan lagras i programmets minne utan måste lagras utanför programmet, t.ex. i endatabas. Om den databashanterare som används är en del av det egna programmetkommer också den att avslutas efter varje anrop. Detta innebär att alla data somskall lagras i databasen måste skrivas till sekundärminne efter varje förfrågan frånen klient. Om databashanteraren är ett eget program som inte avslutas mellan olikaanrop från klienter kan programmet lagra data mellan anrop i sitt minne. Det inne-bär att data inte behöver skrivas till sekundärminne efter varje anrop utan bara närdatabashanteraren anser det lämpligt. En ännu större fördel är att databashante-raren i detta fall inte heller behöver läsa data från sekundärminne vid varje anrop.Om en viss del av databasen under en tid används mycket kan den delen lagras idatabashanterarens primärminne istället för på sekundärminne. Denna minskningav både läsningar från och skrivningar till sekundärminnet ökar hastigheten medvilken databasen kan användas.

10

I detta arbete finns inga tekniska hinder mot att använda en databashanteraresom fungerar som en databasserver. Ökad hastighet är naturligtvis positivt och valetblir därför att använda en databasserver. Det finns flera olika fria databasservrarsom har den funktionalitet som beskrivs ovan. I detta arbete används MySQL.

3.1.4 Programmeringsspråk

Webbservern kan använda sig av alla program som fungerar på den dator där webb-servern körs. De enda krav som protokollet CGI ställer på det program som skallanvändas är att det klarar av att hantera systemresurserna ”Standard input” och”Standard output” samt att programmet kan ta emot argument från kommandora-den när det startas. Detta innebär att i princip alla programmeringsspråk kan an-vändas. Färdigt stöd för att använda språket tillsammans med databasen MySQL ärinte ett teoretiskt nödvändigt krav då det går att implementera själv. Att göra detinnebär dock så pass mycket arbete att det i praktiken i så fall skulle vara enklareatt använda ett annat språk som hade stöd för MySQL för att utföra kommuni-kationen med databasen. Eftersom kommunikation med databasen är nödvändig ide flesta delarna av det aktuella systemet och eftersom stöd för databasen finns förmånga språk bedömdes det enklast att använda ett av dem.

Förutom ett färdigt stöd för MySQL finns det flera andra egenskaper hos ettspråk som är önskvärda. Dessa egenskaper innefattar att språket är lätt att använda,en API (Application programming interface) som är anpassad för de problem somskall lösas och att språket är säkert. Att språket är snabbt är alltid önskvärt meni detta fall inte den viktigaste egenskapen hos språket. Ökad säkerhet har i dettaarbete betraktats som ett viktigare mål än ökad hastighet.

Att ett språk är lätt att använda är delvis en subjektiv bedömning då olikatankesätt och sätt att göra saker inte nödvändigtvis upplevs på samma sätt av olikapersoner. Ett sådant exempel är möjligheten att programmera efter ett objektori-enterat paradigm. Detta innebär förmodligen att språket blir svårare att lära sig,men också att det är lättare att dela upp programmet i olika delar som inte är be-roende av varandra. Det finns dock egenskaper hos ett språk som i princip inte kanuppfattas som annat än underlättande. Att språket har en skräpsamlare innebäratt det minne som allokeras i ett program inte behöver avallokeras av programme-raren utan automatiskt frigörs när det inte längre används. Detta har en negativinverkan på programmets hastighet men tar samtidigt bort en hel kategori av felsom programmeraren kan införa i programmet.

Det system som skall skrivas i språket kommer att ta emot data från webbläsare.De data som skickas från en webbläsare kodas om på olika sätt innan de skickas,detta beror delvis på att man skall kunna överföra data i en URL (Unified ResourceLocator) och måste komma runt begränsningar på hur en URL får se ut. Att ha envälanpassad API innebär därför i detta fall att den skall innefatta funktionalitet föratt koda av de data som kommer in till servern. Eftersom alla data som kommerfrån en webbläsare är textsträngar är det önskvärt att det också finns funktionalitetför att hantera text på ett bra sätt, t.ex. genom att använda reguljära uttryck.

11

Att ett språk är säkert kan tolkas som att implementationen av språket inteskall innehålla fel. Detta är normalt inte vad som avses. Det är ovanligt att bris-tande säkerhet i program beror på att det finns ett fel där programmet inte gör vadprogrammeraren specificerat, det är däremot vanligt att fel beror på att program-meraren specificerat fel beteende eller i vissa situationer missat att överhuvudtagetspecificera vad som skall ske. Med säkerhet i ett språk brukar därför avses språ-kets möjlighet att stödja programmeraren i att skapa en korrekt och fullständigspecifikation av programmets beteende.

Nedan följer en jämförelse mellan två kandidater som har ovan nämnda egen-skaper. Kandidaterna är Perl (se [10]) och PHP. Båda dessa språk används flitigtför att skapa dynamiska webbsidor kopplade till databaser. Språket PHP skapadesmed syftet att just kunna användas för att skapa dynamiska webbsidor. Målet medPerl var enligt dess skapare att se till att enkla saker som texthantering var mycketenkla att utföra och att svårare uppgifter fortfarande inte blev svårare än i andraspråk. Båda språken har också datatypen associativ array (hashtabell) som en pri-mitiv datatyp inbyggd i språket. Detta är en fördel då data som hämtas från endatabas ofta har den formen.

De två språken skiljer sig på många olika punkter. En grundläggande idé i Perlär att datastrukturer skall vara så plana som möjligt. Språket PHP är mer anpassatför att på ett enkelt sätt skapa djupa strukturer. Ett exempel på detta är vad somhänder när man skapar en lista med hjälp av två andra listor. I PHP kan det göraspå följande sätt.

$a = array (1, 2);$b = array (3, 4);

$c = array ($a, $b);

$length = count ($c);

Här skapas en ny lista som innehåller två andra listor som i sin tur innehållerheltal. Variabeln $length får värdet 2. I Perl ser motsvarande kod ut på följandesätt.

@a = (1, 2);@b = (3, 4);

@c = (@a, @b);

$length = @c;

I detta fall skapas också en lista men den innehåller inte två andra listor utanbara de fyra heltal som fanns i de två listorna @a och @b. Värdet på variabeln$length blir i detta fall 4. Det går förstås att i båda språken åstadkomma de tvåolika resultaten, men exemplet visar hur språken gör den ena uppgiften mer naturlig

12

än den andra. Efter att information extraherats ur databasen eller när informationanländer till systemet från en klient kommer denna information att behöva passeragenom flera olika delar av systemet. Det är då bra om denna information på ettenkelt sätt kan grupperas på ett strukturerat sätt som medför att olika typer avdata kan särskiljas. Om listor som kombineras sammanfogas till en lista så blir detsvårare att senare se vilken information som hör hemma var. Detta innebär att detbeteende som återfinns i PHP är mer naturligt i detta sammanhang.

En annan punkt där de två språken skiljer sig åt är i hur åtkomstnivån för va-riabler bestäms. Båda språken är dynamiskt typade och måste bara deklareras föratt ändra dess åtkomstnivå. I Perl är alla variabler globala om ej annat anges, iPHP är det tvärtom så att alla variabler är lokala om ej annat anges. Eftersomglobala variabler är tillgängliga i hela programmet är det svårare att överskåda hurde interagerar med programmets olika delar. Det innebär därför en minskad riskför fel att använda lokala variabler där det är möjligt. Om man i Perl glömmer attdeklarera en lokal variabel så blir den global. Om den har samma namn som enannan variabel så kan det leda till fel som är svåra att hitta eftersom variabeln dåockså påverkas av andra delar av programmet än de som programmeraren avsåg.I PHP behöver endast globala variabler deklareras. Om en sådan deklaration ute-lämnas blir variabeln lokal. Detta är ett fel som oftast är lättare att hitta då feletär lokalt och inte påverkas av hur andra delar av programmet fungerar.

Även om författarens åsikt är att det är roligare att programmera i Perl på grundav dess fria syntax så blir valet för detta projekt att använda PHP på grund av deegenskaper som beskrivits ovan.

3.1.5 Formatmallspråk

En fördel vid valet av formatmallspråk är om dess intepretator eller kompilatorär skriven i samma språk som resten av systemet. Detta innebär att formatmall-språket kan stödja samma primitiva datatyper som används i resten av systemet.Det innebär också att det inte är nödvändigt att starta en separat process när enmall skall användas, vilket möjliggör ökad hastighet. Det finns ett formatmallspråkskrivet i PHP som heter Smarty och som är skapat för att användas tillsammansmed program skrivna i PHP. Smarty blev därför valet av formatmallspråk i dettaprojekt.

3.2 Klient

I detta avsnitt diskuteras de delar som kommer att utgöra klienten. Som nämntstidigare är det önskvärt att en slutanvändare inte skall behöva installera mjukvarapå sin dator för att kunna använda klienten. Därför fattades beslutet att klientenskall vara en webbläsare.

13

3.2.1 Layoutspråk

Ett layoutspråk används för att beskriva innehåll och utseende för en resurs somskall presenteras grafiskt. Det finns många olika språk för detta ändamål men ettsom används av alla webbläsare är HTML (HyperText Markup Language). Vissawebbläsare kan hantera även andra layoutspråk, antingen genom inbyggt stöd ellermed ett hjälpprogram (plugin) som måste installeras. Dessa andra språk har und-vikits då de skulle innebära att systemet endast fungerade med en viss webbläsareeller krävde att användaren installerade hjälpprogram.

Som layoutspråk valdes därför HTML. Ett viktigt syfte med att använda endastHTML är att möjliggöra att flera olika webbläsare skall kunna användas som klient.Det är därför viktigt att tänka på några saker i samband med användandet avHTML. Specifikationen för HTML är väldefinierad och bestäms av organisationenWorld Wide Web Consortium. Trots detta är det relativt få sidor på Internet somföljer denna standard. Detta har förmodligen flera olika orsaker, men en viktigorsak är troligen att olika webbläsare expanderar språket så att det innehåller nyefterfrågad funktionalitet. Användande av den nya funktionaliteten prioriteras sedanöver möjligheten att visa resultatet i flera olika webbläsare. Ett mål med dettaprojekt är att följa den officiella standarden för HTML.

Det bör också påpekas att webbläsare kan välja att visa sidor på lite olika sättoch fortfarande följa standarden. För att säkerställa funktionalitet i olika webbläsareär det alltså en god idé att testa koden i ett flertal olika webbläsare.

3.2.2 Olika sätt att visa media

En del av klientens uppgift i det aktuella systemet kommer att vara att visa bildoch ljud för slutanvändaren. I HTML finns det stöd för att inkludera stillbildersom en del av den sida som koden beskriver. HTML saknar dock specifikt stöd föratt visa rörliga bilder eller ljud. De flesta webbläsare saknar också inbyggt stöd fördessa uppgifter, utan förlitar sig på externa program. Om det är acceptabelt attden fil som inte kan hanteras öppnas i ett eget program och inte som en del avden sida som visas är detta inte ett problem. Slutanvändaren kan då själv välja detprogram som skall användas för att öppna filen. Moderna webbläsare har ofta stödför att lösa denna uppgift så att användaren inte ens behöver vara medveten omdet. Om det å andra sidan är önskvärt att inkludera t.ex. en videofil som en del aven webbsida så uppstår ett problem. Detta problem har väsentligen två lösningar.Antingen installeras hjälpprogram tillsammans med klienten eller så används lokalautökningar i HTML av en viss webbläsare. Ingen av dessa två lösningar uppfyl-ler de tidigare uppsatta målen om att flera olika webbläsare skall kunna användasutan att installation av hjälpprogram krävs. Samtidigt är det ett önskemål frånuppdragsgivaren att videosekvenser skall kunna visas som en del av den sida därfrågorna i undersökningen ställs. Dessa tre önskemål kan alltså inte uppfyllas sam-tidigt och ett val måste göras. Men valet måste inte göras i systemet själv. Om fleraav de tillvägagångssätt som förklarats ovan implementeras i systemet kan valet gö-

14

ras av systemets användare – i första hand administratörer men även i andra handslutanvändare.

3.2.3 Aktiv kod på klienten

HTML beskriver utseendet hos en statisk webbsida samt vilken information somkan skickas tillbaka till en server, men kan inte beskriva beteendet hos en interaktivsida. En rimlig invändning kan nu vara att ifrågasätta behovet av att ta hand ominteraktion på klienten istället för på servern. Det finns både fördelar och nackdelarmed att sköta delar av interaktionen på klienten istället för på servern.

En nackdel är att man inte längre bara använder HTML utan även måste använ-da någon form av scriptspråk. Det kan vara svårare att skriva kod i ett scriptspråkoch försäkra sig om att den verkligen gör vad den ska i olika webbläsare på olikaplattformar. Om man skriver kod som skall köras på servern vet man att den alltidkörs i samma miljö (en miljö som man dessutom kan välja och anpassa efter behov),vilket förenklar testning och felsökning mycket. Det är dessutom i de flesta fall all-varligare att ett scriptspråk är felaktigt implementerat i en webbläsare än att ettlayoutspråk är det. Om något går fel vid hanteringen av ett scriptspråk leder dettroligen till att koden som skulle köras inte fungerar alls eller ännu värre att detutgör en säkerhetsbrist. Vid ett fel i hanteringen av HTML ser oftast sidan baralite annorlunda ut än tänkt, även om värre fel också kan förekomma.

Som nämnts kan det dock finnas vissa fördelar med att sköta delar av inter-aktionen på klienten. En vanlig situation är att den som använder en interaktivwebbsida förväntas mata in värden i ett formulär. När denna information anländertill servern kan det vara nödvändigt att kontrollera att informationen som skic-kats inte är ofullständig eller ogiltig. Exempel på ofullständig information skullekunna vara att en användare anger sitt användarnamn men glömmer att skriva insitt lösenord. Exempel på ogiltig information skulle kunna vara att en användareanger ett negativ tal då en ålder förväntas. Om servern upptäcker att informationenär felaktig kan den skapa en ny sida som anger detta och skicka tillbaka den tillklienten. Många befintliga sidor av denna typ lider av en stor brist, nämligen attnär servern upptäcker ett fel så skickar den tillbaka ett icke-ifyll formulär med ettmeddelande högst upp om att ifyllda data var felaktiga. Användaren tvingas nuatt fylla i alla fält igen inte bara det som var fel utan även alla som var korrektifyllda. I värsta fall får användaren inte ens veta vilket fält som var felaktigt ifyllt.Detta problem är lätt att lösa. Innan servern skickar tillbaka formuläret med ettfelmeddelande så inkluderas den information som var korrekt i formuläret. Det krä-ver lite mer arbete av programmeraren, men det är författarens åsikt att det ärrespektlöst att förvänta sig att någon skall använda ett system som inte inkluderardenna funktionalitet. Om man tillåter att interaktionen delvis sköts på klienten kanman förenkla ytterligare för användaren. Den typ av felkontroll som beskrivs ovankan då göras redan innan användaren skickar iväg data till servern. Detta kan ledatill en snabbare återkoppling för användaren och också till tydligare felindikationer.Vissa interaktiva sidor på nätet använder idén att ändra bakgrundsfärgen på ett

15

textfält eller markera det med en grön ram så fort det fått ett godkänt värde. Dettaär rimligen enklare för användaren då han kan fylla i ett fält och sedan gå vidare tillnästa utan att eventuellt senare behöva återvända för att rätta till felaktiga värden.

I samband med detta bör det påpekas att om den felkontroll som utförs är kritiskför säkerheten så kan den inte bara ske på klienten. Detta kan ibland leda till att manväljer att utföra samma felkontroll två gånger, först på klienten innan data skickastill servern och sedan ytterligare en gång när data anländer till servern. Skälettill detta är att en (illasinnad) slutanvändare kan konstruera en egen klient ellermanipulera den scriptkod som körs på klienten för att sedan skicka tillbaka falskadata till servern. Dessa data skulle inte ha gått igenom en normal säkerhetskontrollpå serven. Ett exempel på detta är att man inte kan nöja sig med att kontrolleraom angivet lösenord är korrekt på klienten, denna kontroll måste ske på servern.

Det finns även andra faktorer som kan motivera kod på klienten. Interaktionskodsom är tidsrelaterad måste ofta finnas på klienten. Om servern levererar en sida medett flertal textfält, och man är intresserad av i vilken ordning dessa fält fylls i kräverdet att det finns scriptkod på sidan som kan observera vad som händer mellanden tidpunkt då servern levererar sidan till den tidpunkt då svaret från klientenskickas tillbaka till servern. Samma sak gäller om man vill mäta tidsintervall mellanhändelser på en sida. Om denna typ av kod endast skulle finnas på servern skulledet innebära att sidan behövde laddas om så fort en interaktionshändelse uppstodpå sidan. Om den enda möjligheten att interagera med sidan är tryckbara knapparså är det möjligen acceptabelt. Om möjligheterna till interaktion även innefattartangentbord eller ännu värre pekdon som en mus, så är det inte acceptabelt dådet skulle innebära att det gick långsamt att interagera med sidan samt en enormtmycket större belastning på servern.

I detta projekt används språket JavaScript då aktiv kod på systemets sidor ansesnödvändig.

16

Kapitel 4

Beskrivning av systemet

Systemets syfte är, som beskrivits tidigare, att utgöra en plattform för Internetba-serade undersökningar. Detta kapitel beskriver hur systemet är uppbyggt.

4.1 Grundläggande uppbyggnad

Systemet använder sig av en arkitektur med en server och ett flertal klienter. Servernär ansvarig för att förse klienterna med enkäter från en databas med undersökningar.Klientens uppgift är att låta olika slutanvändare besvara enkäterna och sedan skickatillbaka svaren till servern.

Klienten består huvudsakligen av en webbläsare. Enkäter som skickas till klien-ten formateras därför av servern i språket HTML. Servern består huvudsakligen avtre komponenter, en webbserver, en databas och ett huvudprogram skrivet i PHP.Webbservern och databasen är färdiga generella verktyg medan huvudprogrammetär det som bestämmer systemets beteende och är specifikt skrivet för systemet.

Klienten är den del av systemet som på den mest grundläggande nivån kan sägasstyra systemet, eftersom klienten är ansvarig för att initiera all kontakt med servern.Klienten bestämmer alltså när olika saker skall hända. För förståelsen av systemetoch speciellt dess uppbyggnad är det bättre att se på huvudprogrammet som denstyrande enheten. Huvudprogrammet utgör systemets nav i avseendet att den sköterkontakten med alla andra delar. Även om inte huvudprogrammet bestämmer närnågot skall ske, är det huvudprogrammet som bestämmer vad som skall ske. För attförstå händelseflödet i systemet är det viktigare i vilken ordning olika saker inträffarän exakt vid vilka tidpunkter de inträffar.

Varje uppgift som kan lösas av systemet löses genom att klienten skickar enförfrågan till servern som servern sedan genererar ett svar till. Huvudprogrammetär uppdelat i ett flertal olika resurser som används för olika uppgifter. Det finnstill exempel en resurs för att presentera enkäter och en annan för att bestämmavilka användare som har tillgång till systemet. Varje gång en klient tar kontakt medservern måste den efterfråga en specifik resurs. På detta sätt kan huvudprogrammetdelas upp i flera olika delar som blir oberoende av varandra.

17

4.2 Inloggning och säkerhet

För att säkerställa att systemet endast används av de personer det är avsett för till-delas varje användare ett användarnamn och ett lösenord. Detta ger också möjlig-het att tillåta olika saker för olika användare. Eftersom varje användare identifierasunikt med ett eget användarnamn kan användarna både delas in i kategorier ochbetraktas som enskilda användare. Att dela in användare i kategorier är användbartför att skilja administratörer från slutanvändare. Detta kan sedan användas för attse till att en administratör kan ändra på en enkät som lagrats i systemet, medan enslutanvändare inte kan det. I vissa situationer är det även nödvändigt att betraktavarje användare för sig, till exempel för att säkerställa att en slutanvändare inte kanutge sig för att vara en annan slutanvändare.

Innan servern tillåter en klient att använda systemet måste en inloggning ske.Inloggningen sker i flera olika steg. Det första steget är att klienten skickar en tomförfrågan till servern. Med en tom förfrågan avses att klienten endast efterfrågarkontakt med servern utan att ange någon specifik resurs. Detta är enda gångendå klienten kan låta bli att ange en resurs i sin förfrågan. När servern får en tomförfrågan skickar den tillbaka en sida som uppmanar användaren att fylla i använ-darnamn och lösenord. När detta är utfört skickas användarnamnet och lösenordeti form av en förfrågan om resursen för inloggning tillbaka till servern.

När servern får denna förfrågan måste den avgöra om användarnamnet ochlösenordet stämmer överens. Servern har i sin databas en lista över systemets allaanvändare. I denna lista finns inte användarnas lösenord sparade, istället finns resul-tatet av en enkelriktad funktion applicerad på lösenordet lagrat. En enkelriktadfunktion är en funktion som kan beräknas utan problem, men vars invers är mycketsvår att beräkna. För att kontrollera om det lösenord som skickats till servernstämmer överens med vad som finns lagrat i systemet appliceras den enkelriktadefunktionen på lösenordet. Resultatet av denna beräkning jämförs sedan med detvärde som finns lagrat i databasen för den användare som angivits vid inloggningen.Om det beräknade värdet är samma som det som redan finns lagrat i systemetsdatabas godkänner servern inloggningsförsöket.

Efter detta steg skulle i många fall en inloggning vara klar. I detta fall är detäven nödvändigt med ytterligare åtgärder för att slutföra inloggningen. Varje gången klient gör en ny förfrågan om en resurs till servern skapas en ny kontakt mellanklienten och servern. Mellan den tidpunkt då en förfrågan avslutas och den tidpunktdå nästa förfrågan görs finns ingen kontakt mellan server och klient. Hur långtdetta tidsintervall är beror på användaren. Även om intervallet innan användarenskapar en ny förbindelse är kort måste det säkerställas att det verkligen är sammaanvändare som tar kontakt med servern igen. När inloggningsförsöket är godkäntslumpar servern därför ett nytt lösenord som dels lagras på servern och dels skickastillbaka till klienten så att klienten i sin tur kan skicka tillbaka detta lösenord nästagång en kontakt skall tas med servern. Efter att inloggningen är klar kan servernalltså vid varje kontakt med klienten använda det nya lösenordet för att verifiera attdet fortfarande är samma användare som ansluter. Till skillnad från inloggningen

18

kan denna senare verifikation ske helt utan att användaren behöver vara medvetenom den.

Två saker i denna beskrivning kan verka onödigt omständliga, och kan mycketväl göras enklare. Trots detta leder i båda fallen de extra stegen till en ökad säkerhet.

Det första fallet är att använda en enkelriktad funktion på lösenordet innan detlagras i serverns databas. Att lagra själva lösenordet i databasen skulle underlättakontrollen av lösenordet då man i så fall endast jämför det lagrade värdet med detsom användaren angivit. Skälet till att använda en enkelriktad funktion är att mandå inte behöver lagra lösenordet i klartext på sekundärminne. Det finns flera skältill att detta bör undvikas. Om någon på grund av säkerhetsfel eller missbrukatansvar får tillgång till lagrad information så kan vederbörande fortfarande inte sevad systemets användare har för lösenord. Nu kan man ifrågasätta nyttan med atthemlighålla lösenord även efter att någon fått öppen tillgång till hela systemet. Fördet första är det inte säkert att någon fått fulla rättigheter till systemet bara för attpersonen kommit åt delar av den information som lagrats i systemet. Om någon fårotillåten tillgång till en backup av systemets databas genom stöld eller bristandeansvar, kan det medföra en möjlighet att kunna läsa allt som finns lagrat i syste-met. Däremot kan vederbörande inte göra ändringar i den aktiva databasen utantillgång till databasen. Det finns även ett annat skäl till att inte lagra lösenord påsekundärminne. Om en användare använder samma lösenord i flera olika system såinnebär en bristande säkerhet i det ena systemet eventuellt även bristande säkerheti det andra. Att välja samma lösenord i flera olika system innebär minskad säker-het och bör därför undvikas redan av användaren själv. Att skydda sig mot dennasäkerhetsbrist innebär i första hand inte en ökad säkerhet för det egna systemetutan snarare för andra system. Man har alltså ett visst ansvar då man hanteraranvändares lösenord även om man inte värdesätter säkerheten i sitt eget system.

Det andra extra steget i inloggningen är att låta servern slumpa ett nytt lösenordför att användas vid senare verifikationer under samma session, istället för att an-vända användarens eget lösenord. Att skapa ett nytt lösenord innebär samma fördelsom med den enkelriktade funktionen; användarens lösenord behöver inte sparas påsekundärminne. Ett vanligt beteende hos webbläsare är att spara de sidor som tasemot på sekundärminne så att inte servern från vilken sidan kom behöver kontaktaspå nytt om samma sida efterfrågas igen. Detta beteende är sällan värdefullt eller ensönskvärt för dynamiska sidor, då informationen på sidan ofta ändras. Trots dettalagrar ofta webbläsare dessa sidor i sekundärminnet. Nu kommer i så fall det nyalösenordet att lagras på sekundärminne. Detta lösenord inaktiveras så fort använda-ren loggar ut från systemet. Eftersom lösenordet endast är giltigt under en kortaretidsperiod, måste alltså åtkomst till sekundärminnet ske samtidigt som systemetanvänds av användaren för att samma typ av säkerhetsbrist skall kunna uppstå.Detta är normalt en mycket mindre risk. En användare kan också själv välja attgenast logga ut om han märker eller misstänker att bristande säkerhet råder. Dettillfälliga lösenordet begränsas även i tiden på ytterligare ett sätt. När lösenordetskapas sätts en giltighetstid för det. I detta system är tiden satt till två timmar, menkan ändras av den som administrerar systemet. Detta innebär att om en användare

19

går från systemet och glömmer att logga ut så är systemet bara känsligt under enbegränsad tid. Varje gång klienten tar kontakt med servern förlängs giltighetstidenför det tillfälliga lösenordet genom att den räknas från rådande tidpunkt. Det till-fälliga lösenordet skall inte betraktas som tillräcklig verifikation av identitet för atttillåta att en användare byter sitt lösenord. Användaren bör vara tvungen att angesitt eget valda lösenord för att kunna byta ut det mot ett nytt. Detta hindrar enperson med tillgång till det tillfälliga lösenordet från att kunna ta över kontot fråndess riktiga ägare.

4.3 Resurser

Efter att inloggningen är klar kan klienten kontakta servern för att få den att utfö-ra olika uppgifter eller för att skicka tillbaka information. Systemets funktioner äruppdelade i olika resurser, och vid varje kontakt måste klienten ange den specifikaresurs som den vill använda. Det finns flera skäl till denna uppdelning av systemetsfunktioner i resurser. Som tidigare nämnts blir härigenom systemets olika delar inteberoende av varandra, förutom i de fall då detta är önskvärt. Idén att separeraolika delar av ett program från varandra har länge varit drivkraften bakom nyakonstruktioner i programmeringsspråk. Ett skäl till detta är att det förenklar skri-vandet av kod då flera programmerare lättare kan arbeta samtidigt på olika delarav ett program. Det kan också vara mycket lättare att förstå och därmed även attfelsöka ett program som är uppdelat på detta sätt. Desto fler saker som inverkar påvarandra desto svårare är det att förstå vilken av de olika delarna det är som harett fel i sig. Ett annat skäl till att dela upp systemets funktionalitet i olika resurserär att vissa delar av funktionaliteten bara skall vara tillgängliga i vissa fall, ellerbara till en viss grupp användare. De olika resurserna innehåller därför inte baraolika funktionalitet, utan är även ansvariga för att bestämma vilka villkor som skallvara uppfyllda för att respektive resurs skall vara tillgänglig.

Språket PHP som huvudprogrammet är skrivet i är ett objektorienterat språk,och det är med hjälp av detta begrepp som de olika resurserna skiljs från varandra.Varje resurs representeras av ett objekt från en egen klass. För att en klass skallrepresentera en resurs måste den ärva från en superklass kallad Resource, super-klassen är gemensam för alla resurser. Varje klass har en speciell metod som avgörnär resursen får användas. I den gemensamma superklassen Resource förbjuderdenna metod all användning av resursen. Eftersom alla andra klasser som repre-senterar resurser ärver från den gemensamma klassen så kommer ingen resurs attkunna användas om inte metoden som avgör åtkomst definieras om i den subklasssom resursen representeras av. Att förbjuda all användning kan verka meningslöst,men har den stora fördelen att ingen resurs blir tillgänglig av misstag. Det finns ävenen klass som heter AdminResource som ärver från Resource. Metoden för åtkomsti denna klass kontrollerar om den användare som ansluter är en administratör ochger behörighet endast om så är fallet. Denna klass är avsedd att användas som enabstrakt klass som andra klasser kan ärva från för att ansluta sig till den behörig-

20

Figur 4.1. Klassdiagram över resurser.

hetsnivå som definieras av den abstrakta klassen. Tanken var att olika abstraktaklasser skulle kunna skapas för att definiera nya behörighetsnivåer som olika resur-ser sedan kunde ansluta sig till. Det har i arbetet endast uppstått en behörighetsnivåsom är tillräckligt generell för att motivera en gruppering av beskriven typ, det ärden nivå som definieras av klassen AdminResource. I en utvidgning av systemet kanfler behörighetsnivåer definieras på detta sätt om behov uppstår. Figur 4.1 beskriverstrukturen för klasshierarkin för resurser.

4.4 Efterfrågan av en resurs

När en klient efterfrågar en resurs söker systemet efter en resurs med det namn somangivits. Om ingen resurs med motsvarande namn hittas avvisar servern förfråganmed ett felmeddelande. Om en resurs med rätt namn finns i systemet används dessmetod för behörighet för att avgöra om användaren som anslutit i den situationenhar behörighet till resursen. Om så inte är fallet avvisas förfrågan även i dettafall med ett felmeddelande. De två fallen ovan som leder till att servern avvisarförfrågan skall aldrig inträffa vid normal användning av systemet, utan endast dåen användare försöker missbruka systemet. Man måste dock alltid räkna med atthändelser kan inträffa som en effekt av ett fel i systemet. När systemet genererar ensida som ger användaren möjlighet att välja en åtgärd eller på annat sätt interageramed systemet, skall den bara erbjuda interaktionsmöjligheter som är tillåtna i detaktuella läget. Detta innebär att en kontroll av vilka åtgärder som är tillåtna måsteske minst två gånger, dels när den sida som skickas till användaren skapas och delsnär användaren igen ansluter med en förfrågan baserad på den skapade sidan. Detta

21

kan ibland innebära mer arbete med att skriva kod för systemet, men både den förstaoch den andra kontrollen är nödvändig. Om kontrollen vid skapandet av sidor inteutförs leder det till minskad användbarhet då användare i vissa situationer kommeratt erbjudas alternativ som de egentligen inte har. De kommer då att informerasom detta först när de försöker utföra ett otillåtet alternativ. I de flesta fall voredet då betydligt bättre om deras gränssnitt var utformat så att de inte fick dettaalternativ. Om man å andra sidan nöjer sig med kontrollen då sidor skapas, och inteutför någon kontroll då klienten ansluter till servern som en effekt av interaktionpå en sida, så innebär detta en säkerhetsbrist. När en användare ansluter är detinte säkert att den förfrågan som då görs baserar sig på sidor som är skapade avsystemet, det kan lika gärna vara resultatet av att en användare manipulerat sidorfrån servern eller på annat sätt ändrat miljön på sin klient.

När kontrollen av användare och tillgänglighet för resursen i fråga är klar så tararbetet vid med att utföra den uppgift som efterfrågas av klienten. Varje resurs haren egen metod som tar hand om den uppgiften, den benämns handle_request. Vaddenna metod utför beror på vilken typ av uppgifter resursen är avsedd att hantera.Gemensamt för alla uppgifter är att de innefattar minst en av tre grundläggandeoperationer:

• lagra uppgifter i systemets databas

• extrahera information från systemets databas

• bearbeta data eller utföra beräkningar

De flesta uppgifter som systemet löser är en kombination av flera av dessa ope-rationer. När dessa operationer är utförda händer en av två saker. Om det finns ettresultat som skall presenteras för användaren inkluderas resultatet i en formatmallskriven i språket Smarty. Med hjälp av denna mall konstrueras en HTML-sida somsedan skickas tillbaka till användaren. Om uppgiften som utfördes av systemet intehar ett resultat som är intressant att presentera för användaren kan istället en nyförfrågan genereras. I detta fall genereras förfrågan av servern i stället för klienten,men servern kommer efter att den genererat förfrågan att betrakta den som omdet varit klienten som genererat den. Detta är en värdefull konstruktion då den germöjlighet för systemets olika resurser att använda varandra. Detta kan låta motsä-gelsefullt då det lagts så mycket vikt vid att de olika resurserna skall vara åtskildafrån varandra. Följande exempel gör förhoppningsvis idén klarare. I systemet finnsolika enkäter lagrade, ett krav på systemet bör vara att en administratör kan ta borten enkät från systemet då den inte längre är önskvärd. Ett sätt att utföra detta äratt presentera en lista med aktuella enkäter för administratören, där vederbörandekan markera vilka enkäter som skall tas bort. Innan denna information skickas ivägkan det vara värdefullt att ställa en fråga1 till administratören som säkerställer att

1Denna fråga är ett exempel på när det kan vara användbart att ha aktiv kod på klienten ävenom det inte är fullt tekniskt nödvändigt.

22

vederbörande inte gjort ett misstag utan verkligen vill ta bort enkäterna i fråga.När informationen sedan når servern kan rätt resurs genom ett enkelt anrop till da-tabasen ta bort dessa enkäter. Så långt fungerar allt som det skulle ha gjort när vitar bort en fil i en vanlig grafisk filhanterare. Men frågan är vad servern skall göranu. Till slut måste en sida med information skickas tillbaka till administratören.Ett val som faktiskt förekommer i vissa system är att skicka tillbaka en sida därdet står att allt gick bra och där det finns en länk för att återvända till systemetshuvudsida. Det kan vara svårt att veta vad avsändaren vill göra efter att ha tagitbort enkäten, men förmodligen är det inte att få se ett meddelande där systemetpåstår sig fungera korrekt. En tänkbar nästa åtgärd för administratören skulle kun-na vara att försäkra sig om att det verkligen var rätt enkät som försvann. En annanåtgärd skulle kunna vara att ta bort en enkät till, trots att möjlighet gavs att tabort flera samtidigt. I båda dessa fall vill administratören förmodligen få tillbakaen uppdaterad version av den lista med aktiva enkäter som presenterats tidigare.Detta är vad som normalt skulle hända i en grafisk filhanterare.

Det finns flera sätt att åstadkomma den önskade återkopplingen. Det enklastesättet är förmodligen att anropa den del av koden som skapar listan över enkäter,vilket dock bryter mot idén om uppdelning av koden och skapar onödiga internaberoenden. Ett annat sätt är att kopiera den kod som presenterar listan. Dennakod kommer då att finnas på två ställen i programmet och utför samma sak. Dettaär en fruktansvärd lösning som är betydligt sämre än det första alternativet. Omsamma kod finns på flera ställen blir programmet onödigt stort och därför mersvåröverskådligt. Om en ändring görs på ett ställe i koden måste den också utförasi alla kopior. Det är då lätt att glömma att uppdatera någon och därmed förain fel i systemet. Ett tredje alternativ är att skapa en sida med en länk som geradministratören möjlighet att återvända till listan. Detta alternativ har ingen av denegativa aspekterna från de första två alternativen. Inga interna beroenden skapaseftersom varje resurs endast användas via det gränssnitt som är tillgängligt viaklienten. Ur ett användbarhetsperspektiv är detta alternativ dock sämre, eftersomdet presenterar ett sätt att komma tillbaka till listan istället för att visa listandirekt. Lösningen blir därför att låta servern göra förfrågan åt användaren, mensamtidigt behandla förfrågan på samma sätt som om den kom från klienten.

4.5 Metoder för ett generellt grafiskt gränssnitt

För varje funktion som finns i systemet måste det också finnas ett sätt för använ-daren att få tillgång till den. Detta sker genom ett grafiskt gränssnitt som beskrivsi språket HTML och presenteras för användaren med hjälp av en webbläsare. Ettflertal funktioner är relativt enkla och kräver ofta bara en okomplicerad kontaktmed databasen där information extraheras eller lagras. Men även i de fall då enenkel funktion skall användas kan gränssnittet som krävs för att göra funktionentillgänglig vara komplicerat. En stor del av systemets kod är således relaterad tilldet grafiska gränssnittet. Ett viktigt mål i projektet har därför blivit att skriva ge-

23

nerell kod, som kan användas till problem som återkommer i koden för det grafiskagränssnittet.

4.5.1 Språk

Alla meddelanden från systemet som visas i det grafiska gränssnittet bestäms utan-för koden för gränssnittet. För varje ord eller fras som används i gränssnittet finnsett unikt id. Detta id används för att ur en ordlista hämta den text som ordet ellerfrasen består av. Detta tillvägagångssätt har flera fördelar. Det är rimligt att dentext som förekommer i ett gränssnitt kan behöva ändras, det är då enklare att göraändringen i en ordlista än att behöva ändra i koden. Den största fördelen med dettaförfarande är emellertid att flera olika ordlistor kan användas samtidigt. Detta tillå-ter oss att ge systemets användare möjlighet att själv välja vilket språk systemetskall använda.

De ordlistor som används är textfiler. I dessa textfiler anges id för en fras följt avett likhetstecken och sist själva frasen skriven i det språk som ordlistan beskriver.Som exempel följer nedan utdrag ur ordlistorna för svenska och engelska.

language =språklanguage__en =engelskalanguage__sv =svenska

language =languagelanguage__en =englishlanguage__sv =swedish

4.5.2 Inställningar

För flera objekt i systemet kan olika inställningar göras. Det kan till exempel varavilken bakgrundsfärg en sida skall ha, vilken typ av svarsalternativ som skall visaseller som nämndes i föregående avsnitt, vilket språk en användare vill använda. Attlåta en användare ändra på denna typ av inställningar är en återkommande uppgift,som kräver en hel del kod för att utföras på ett bra sätt. Det är därför önskvärt attförsöka generalisera denna kod så att den kan återanvändas.

Att generalisera koden för att ändra på inställningar så att den kan användaspå olika ställen är inte svårt, men att göra det på ett bra sätt kräver lite eftertanke.En trivial idé vore att skriva en komponent som kan ändra alla inställningar för allaobjekt till vad som helst. Denna komponent skulle sedan kunna användas på olikaställen för att lösa den uppgift vi efterfrågar. Denna generalisering gör emellertidatt vi förlorar något, som följande exempel illustrerar. Om vi skrivit en komponentspecifikt för att ändra inställningar för objekt som representerar personer, hade viförmodligen sett till att det inte gick att tilldela personen en bakgrundsfärg, då dettabara varit förvirrande. På samma sätt hade vi troligen för inställningen språkvalbara accepterat meningsfulla svar som svenska eller engelska men inte röd. I dentriviala lösningen saknas information om vilka inställningar som är meningsfulla för

24

ett visst objekt, samt vilka alternativ som är meningsfulla för en viss inställning.Det första problemet löses enkelt genom att skicka med en lista över meningsfullainställningar varje gång komponenten används. Information om giltiga alternativ förvarje inställning skulle också kunna skickas med varje gång komponenten används,men eftersom samma inställning kan vara relevant i flera olika sammanhang skulledet innebära att vi var tvungna att upprepa denna information. Av detta skäl harett separat språk för att beskriva denna information skapats. I språket specificerasen regel om giltiga alternativ för varje inställning. En regel kan även innehållainformation om vilket alternativ som skall väljas om ingen tidigare inställning gjorts.Regeln för inställningen textstorlek ser ut på följande sätt.

text_size = (8|10|12|14|16|18|20|25|30|40|50) (14)

Varje regel börjar med ett namn för den inställning som skall göras (i detta falltext_size). Sedan följer en lista med giltiga alternativ som skall presenteras föranvändaren. I detta fall anges även att textstorlek 14 skall användas om ingen tidi-gare inställning gjorts. I exemplet ovan är alla alternativ numeriska. Detta betyderatt alternativen inte behöver översättas till olika språk2. I de fall då alternativenbestår av ett ord eller en fras måste dess namn istället anges, så att text kan hämtasur en ordlista. I förra avsnittet såg vi att namnen för orden ’engelska’ och ’svenska’var language_en respektive language_sv. En regel för giltiga språkval skulle kunnaskrivas på följande sätt.

language = (language__en|language__sv) (language__en)

Eftersom alla alternativ i detta fall delar ett gemensamt prefix kan regeln ävenskrivas på ett mer kompakt format. Detta skrivsätt kan vara krångligare att förståmen gör regler med många alternativ mer överskådliga.

language::language__ = (en|sv) (en)

Figur 4.2 visar hur regeln för språkval realiseras i komponenten som används avdet grafiska gränssnittet för att göra inställningar.

Nedan beskrivs syntaxen för beskrivningsspråket i EBNF.

2Om något språk skulle kräva översättning av numeriska alternativ måste ordlistan för detspråket inkludera dessa översättningar med det numeriska värdet som namn för översättningen.

25

Figur 4.2. Val av språk i den grafiska komponenten för inställningar.

<rule> ::= <name> [ ’::’ <prefix> ] ’=’ ’(’ <opt-list> ’)’ [ ’(’ <option> ’)’ ]

<opt-list> ::= <option> | <option> ’|’ <opt-list>

<option> ::= <name>

<name> ::= <char>+

<prefix> ::= <char>+

<char> ::= <letter> | <digit> | ’_’

<digit> ::= ’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ | ’8’ | ’9’

<letter> ::= # any alphanumeric character

4.5.3 Egna objekt i Smarty

HTML var från början inte avsett att användas för att beskriva grafiska gränssnittutan för att beskriva dokument. Med tiden har ett flertal objekt relaterade till

26

grafiska gränssnitt inkluderats i språket. Fortfarande saknas dock en del av de objektsom normalt används för att beskriva grafiska gränssnitt.

Smarty ger möjlighet att till viss del utvidga det språk som det används i kom-bination med. I detta fall innebär det att vi kan skapa nya objekt i HTML genomatt kombinera de objekt som redan är tillgängliga. Eftersom varje nytt objekt vipå detta sätt skapar baseras på redan befintliga objekt i HTML kommer de nyaobjekten endast att kunna beskriva sådant som redan var möjligt i HTML. De nyaobjekten kommer dock att ha en högre abstraktionsnivå, vilket gör dem enklare attanvända.

En konstruktion som ofta är önskvärd är att gruppera olika komponenter somhör ihop. Denna teknik kan användas för att se till att en textruta och en knapphamnar bredvid varandra eller att ett flertal kryssrutor får en ram runt sig. Ett sättatt konstruera en sådan gruppering i HTML är med hjälp av en tabell med endasten rad och en kolumn. Koden för detta följer nedan.

<table cellpadding=’10’ cellspacing=’0’ border=’2’ width=’100%’><tr>

<td><font face=’Verdana, Arial, Helvetica’ size=’3’>

<b>Settings:

</b></font><p>

the frame content

</td></tr>

</table>

Om koden ovan används som grund för att skapa ett nytt objekt, kan sedan detnya objektet användas för att skapa denna typ av grupperingar. Den nya koden görsamma sak men är enklare och tydligare:

{group title=’Settings’ width=’100%’}the frame content

{/group}

Detta objekt användes för att skapa komponenten i figur 4.2.

4.5.4 Felmeddelanden

Fel som uppstår i systemet beror antingen på felaktiga indata från en användareeller på interna fel i systemet. Oavsett orsak är det i de flesta fall önskvärt att

27

meddela användaren att det uppstått ett fel. Ett vanligt sätt att hantera detta iett grafiskt gränssnitt är att då felet uppstår direkt visa en dialog som förklararvad som gått fel. Att direkt visa en dialog är inte möjligt i detta system, eftersomingen ny information når användaren innan en ny sida skickas till honom. Det finnsdärför två huvudsakliga sätt att förmedla felmeddelandet. Ett alternativ är att skapaen ny sida som innehåller information om det fel som uppstått och skicka den tillanvändaren. Ett andra alternativ är att försöka modifiera en av de sidor som normaltskulle skickats till användaren så att felmeddelandet inkluderas i den. Det kan varaden sida som skulle visats om felet inte uppstått eller den sida som senast skickatstill användaren. Första alternativet att skapa en helt ny sida är enklast eftersomall information som krävs för att skapa den nya sidan finns tillgänglig i den delav programmet där felet uppstod. Det andra alternativet kräver att informationfrån den del av systemet där felet uppstod sammanfogas med information frånden del av systemet som skapar den sida som normalt skulle skickats tillbaka tillanvändaren. Då måste också ytterligare kod till som bestämmer hur de två delarnaskall sammanfogas. På grund av systemets uppbyggnad kan de två olika delarnainte heller direkt anropa varandra. Ur användarens perspektiv är det rimligen bättreatt få felmeddelandet som en del av den sida som normalt skulle ha visats. Detvanligaste felet som uppstår är att felaktig information matas in av en avsändare.Det är då ett bra stöd för användaren att få se vilken information som var fel ochvarför den var fel, i samband med möjligheten att mata in ny korrekt information.Det sista innebär oftast att inkludera ett meddelande på den sida som användarenjust kom från.

För att kunna infoga dialogmeddelanden på det sätt som beskrivs ovan hållersystemet reda på en lista med fel som uppstått under arbetet med att utföra en för-frågan. Detta sker genom att själva förfrågan förändras så att den själv inkluderardenna lista. Listan är inte begränsad till att innehålla felmeddelanden, ett medde-lande i listan kan även vara en varning eller ett positivt meddelande om att någotfungerat som det ska. Den sista typen används sparsamt, men kan vara av nyttanär en användare förmodas vilja ha en positiv bekräftelse exempelvis vid lösenords-byte och då systemet skickar iväg e-post. När en förfrågan anländer kan systemetsolika resurser se om den hittills orsakat några fel och baserat på den informationenbestämma om den skall hanteras på ett speciellt sätt. När förfrågan sedan når dendel av koden som hanterar det grafiska gränssnittet, används en komponent somdefinierats i språket Smarty för att visa de meddelanden som bifogats förfrågan.Om förfrågan saknar bifogade meddelanden ser komponenten till att dölja sig själv,vilket innebär att komponenten alltid kan inkluderas överst på alla sidor och ba-ra påverka en sida då det är relevant. Varje meddelande som bifogas en förfråganmärks också med en typ, så att den grafiska komponenten kan välja att visa olikatyper av meddelanden på olika sätt. Exempelvis visas positiva meddelanden på engrön bakgrund och felmeddelanden på en röd bakgrund. Felmeddelanden visas alltidöverst. Att spara meddelanden på detta sätt har flera fördelar. Först och främst ärdet då möjligt att behålla systemets inbördes oberoende struktur och delvis förut-bestämda programflöde. Det bidrar även till att separera systemets logik från dess

28

presentation. Att kunna visa meddelanden i den mest relevanta ordningen är ocksåen effekt av detta val.

Det finns en kategori av felmeddelanden som inte hanteras enligt beskrivningenovan, nämligen meddelanden som är en effekt av att en användare nekats åtkomsttill en resurs. Dessa varken kan eller ska hanteras på samma sätt som andra felmed-delanden. Ett meddelande kan fortfarande bifogas förfrågan, men vid nekad åtkomstskapas direkt en ny förfrågan till en egen resurs var enda syfte är att förmedla bud-skapet om nekad åtkomst. För vidare diskussion av felhantering i liknande systemse [4] och [8].

29

Kapitel 5

Systemets funktionalitet

Detta kapitel beskriver systemets funktionalitet, och är avsett att fungera som enreferens för vad som går att göra. Då detta inte är avsett att fungera som en manualbehandlas inte hur olika uppgifter i systemet utförs.

Systemets funktionalitet är som tidigare beskrivits uppdelad i olika delar kalladeresurser. De följande avsnitten kommer att behandla de viktigaste resurserna. Vissaresurser är mycket små och andra bidrar med funktionalitet som inte är direkttillgänglig utifrån. Dessa båda typer av resurser kommer inte att behandlas här.

5.1 Resurser för alla användare

Detta avsnitt beskriver de grundläggande resurser som är avsedda för alla använ-dare.

5.1.1 Inloggning

Resursen inloggning används för att låta en användare ange ett användarnamn ochett lösenord, samt för att kontrollera att de två inmatade värdena är giltiga.

5.1.2 Nekad åtkomst

En användare kan nekas tillgång till systemet på grund av en misslyckad inloggningeller av andra skäl. Denna resurs enda syfte är att säkerställa att nekade användareinte får tillgång till systemet och att de informeras om detta.

5.1.3 Media

Denna resurs bestämmer hur bild och video skall visas. Detta görs med hjälp avett eget beskrivningsspråk. Med hjälp av språket kan egenskaper som bildtext ochstorlek bestämmas.

31

5.2 Resurser för slutanvändare

Den del av systemet som endast är avsedd för systemets slutanvändare är i huvudsakbegränsad till två olika resurser. Utöver dessa resurser finns några små som endastvisar förklarande text.

5.2.1 Navigering

Denna resurs hanterar den första sidan som en slutanvändare ser efter en lyckadinloggning. Den visar en lista med tillgängliga enkäter och ger slutanvändaren möj-lighet att välja en av dem.

5.2.2 Enkätfråga

Resursen enkätfråga används för att visa frågor från enkäter och ge slutanvändaremöjlighet att besvara dem.

5.3 Administratörsdel

Den största delen av systemets funktionalitet är endast tillgängligt för administra-törer. Detta avsnitt beskriver denna funktionalitet.

5.3.1 Hantering av användare och grupper

I vissa fall kan det vara önskvärt att endast låta en delmängd av slutanvändarnadelta i en viss undersökning. Exempelvis kan en enkät rikta sig till en viss målgruppsom inte innefattar alla slutanvändare i systemet. Denna resurs erbjuder möjlighetatt på olika sätt hantera grupper av användare. En grupp kan skapas antingen somen kombination av andra grupper eller via resultatet av en utsökning bland allasystemets användare. Resursen möjliggör även att nya konton för användare kanskapas. Figur 5.1 visar hur resursen representeras grafiskt.

5.3.2 Persondata för användare

Denna resurs utgör ett formulär för att inspektera och ändra data som är specifikaför enskilda användare. Det finns även möjlighet att bjuda in enskilda slutanvändaretill nya enkäter, ta bort användare från systemet samt för att ändra inställningarsom t.ex. språkval. Figur 5.2 visar hur resursen representeras grafiskt.

5.3.3 Administration av media

Denna resurs används för att söka bland tillgängliga mediaobjekt i systemet samtför att ladda upp nya mediafiler. Det är också möjligt att inspektera och ändranamn på befintliga objekt.

32

Figur 5.1. Hantering av användare och grupper.

5.3.4 Administration av enkäter

Denna resurs erbjuder funktionalitet för att skapa, ändra, ta bort och kopiera en-käter. Den kan även användas för att bestämma vilka enkäter som skall vara aktiva(tillgängliga för slutanvändare). Här visas också sammanfattande information omaktiva enkäter.

5.3.5 Skapa och redigera enkät

Denna resurs används för att skapa och redigera en enkät. I detta ingår följandesteg:

• Ange text som förekommer på en inledande sida. Denna text kan innehållainledande instruktioner och förklaringar för den aktuella enkäten.

• Ange text som förekommer på en avslutande sida. Denna text kan tacka fördeltagande eller på annat sätt markera att enkäten nått sitt slut.

33

Figur 5.2. Persondata för användare.

• Göra inställningar som gäller för alla frågor i enkäten där ett annat värde inteangivits.

• Gruppera enkätens frågor för att bestämma vilka frågor som skall placeras påsamma sida.

5.3.6 Skapa och redigera fråga

Denna resurs innehåller den funktionalitet som krävs för att skapa och ändra enenskild fråga. Detta innefattar ett flertal olika saker:

• Möjlighet att bestämma namn och titel för frågan.

• Möjlighet att redigera själv frågeställningen samt att infoga mediaobjekt.

• Möjlighet att göra inställningar för layout samt för hur frågan skall besvaras.

• Möjlighet att bestämma svarsalternativ om frågan är av flervalstyp.

34

Figur 5.3. Sidan för redigering av frågor.

• Möjlighet att ange regler för vilken fråga som skall följa efter nuvarande,baserat på svaret från nuvarande fråga.

Figur 5.3 visar hur resursen representeras grafiskt (själva webbläsaren visas ejpå grund av figurens storlek).

5.3.7 Hantering av lagrade svar och andra data

Denna resurs möjliggör analys av de svar som inkommit till en enkät. Innan en ana-lys utförs kan svaren filtreras så att bara svar från en specifik grupp slutanvändaretas med eller så att bara svar från slutanvändare som angivit ett visst svar på enutvald fråga tas med.

35

Sammanställning

Den enklaste analysen som kan göras är att presentera stapeldiagram som visar hurstor andel av svaren som varje alternativ motsvarar. Om de olika svarsalternativenförsetts med numeriska koder vid konstruktionen av enkäten presenteras medelvär-det för dessa tal. Om frågan inte är av flervalstyp presenteras endast en lista medde svar som angivits.

Statistiska tester

Det finns även möjlighet att utföra statistiska tester på insamlade data. För närva-rande finns Spearmans rankkorrelationstest implementerat. Detta test förutsätterinte någon känd bakomliggande fördelning för de data som skall användas. Eftersomen känd fördelning för svaren i en undersökning oftast saknas är detta ett lämpligttest för detta ändamål. Resultatet av testet presenteras genom att systemet talarom att ingen signifikans kunde hittas eller att resultatet är signifikant på en-, två-eller tre-*nivå. Om det inte finns tillräckligt många svar för att ett test skall kunnautföras anges detta.

Backup

Denna resurs ger också möjlighet att ta backup på hela databasen, genom att sparaden på en fil som laddas ner till klienten. Detta kan även användas för att exporteradata till andra system.

36

Kapitel 6

Rekommendationer

Detta arbete har resulterat i en fungerande prototyp, men det finns ett flertal om-råden som skulle vara värdefulla att utforska i en fortsättning av projektet. I dettakapitel sammanfattas några av dessa områden.

6.1 FastCGI

I den nuvarande prototypen av systemet används CGI. Det innebär som tidigarebeskrivits att en ny process startas på servern varje gång en klient skickar en för-frågan. FastCGI är ett alternativ till protokollet CGI. FastCGI skiljer sig från CGIgenom att endast en process startas, denna process används varje gång en klientansluter. Eftersom denna förändring endast påverkar hur servern beter sig så kanden införas utan att klienten behöver vara medveten om skillnaden. Det sista ärviktigt eftersom klienten är en godtycklig webbläsare som vi inte kan förändra. Var-je gång systemet startas görs ett flertal initieringar. Till exempel läses ordlistan fördet språk som skall användas från en fil vid denna initiering. Om endast en processstartades skulle det innebära att det arbetet bara behövde utföras en gång. Omsystemet får många aktiva användare kan den besparingen innebära en betydandevinst.

6.2 Undersökning av hur systemet används

Vid utvecklandet av prototypen har kontakt med systemets avsedda användare en-dast varit möjlig i mycket liten skala. En hel del eftertanke har ägnats åt att görasystemet användbart. Det är dock inte säkert att användare utnyttjar systemet pådet sätt som är avsett. Det är troligt att större kontakt med användare skulle ha re-sulterat i en annorlunda prototyp. Det skulle därför vara av intresse att undersökahur både slutanvändare och administratörer faktiskt använder systemet. Slutsat-ser från en sådan undersökning skulle troligen kunna användas för att förbättrasystemets användargränssnitt.

37

En gissning är att en sådan undersökning skulle visa att en del funktioner isystemet inte används för att de upplevs som för krångliga, medan det för vissaandra funktioner skulle finnas önskemål om mer avancerad funktionalitet. Dessainsikter skulle då kunna tas till vara genom att lägga till, ta bort eller förändra delarav systemets funktionalitet. Det är också möjligt att det i vissa fall skulle räcka medatt presentera befintlig funktionalitet på ett annorlunda sätt, då författaren (ävenom ambitionen varit en annan) kan ha ett matematiskt synsätt som inte tilltalaralla.

Eftersom systemets grafiska gränssnitt är separerat från dess logik skulle detockså vara möjligt att ha flera olika gränssnitt i bruk samtidigt. Detta skulle kun-na vara värdefullt då användare med olika bakgrund och olika vana av systemetrimligen har olika önskemål.

6.3 Utökad funktionalitet

Eftersom detta projekt utgör ett examensarbete och är begränsat i tiden har fokussatts på den mest centrala funktionaliteten i systemet. Det finns av detta skälmånga områden beträffande funktionalitet som aldrig varit aktuella att ha med iprototypen, men som i en vidare utveckling skulle kunna vara av stort intresse.Några exempel på sådan funktionalitet är:

• Större möjlighet för slutanvändare att ändra data och anpassa systemet efteregna önskemål.

• Funktionalitet för att kunna samarbeta mer med andra system. I prototypenbegränsas den typen av samarbete till en export av data.

• Fler sätt att analysera data i systemet.

• Mallar som beskriver den grundläggande layouten i en enkät. Detta skulleförenkla att ge olika enkäter en gemensam stil.

• Mer interaktion i enkäter. I prototypen används endast formulär för interak-tion i enkäter. Det vore även möjligt att ha annan typ av interaktion, tillexempel att låta slutanvändaren peka med musen i en bild.

38

Litteraturförteckning

[1] R. M. Alvarez., C. VanBeselaere. Web-Based Surveys.http://survey.caltech.edu/encyclopedia.pdf (URL nådd 2006-06-01).(2003)

[2] S. Andrews., S. Feinberg. Developing and implementing effective Web-basedsurveys. STC’s 46th annual conference proceedings. Cincinnati, Ohio: SawtoothTechnologies. http://www.stc.org/confproceed/1999/PDFs/046.PDF (URLnådd 2006-06-01). (1999)

[3] D. Bowker., D. A. Dillman.An experimental evaluation of left and right orientedscreens for Web questionnaires. The 55th annual conference of American Asso-ciation for Public Opinion Research. Portland, Oregon. http://www.amstat.org/sections/srms/Proceedings/papers/2000_167.pdf (URL nådd 2006-06-01). (2000)

[4] M. Brambilla., S. Ceri., S. Comai., C. Tziviskou.Exception Handling in Workflow-Driven Web Applications.http://citeseer.ist.psu.edu/736028.html (URL nådd 2006-06-01).(2005)

[5] K. Dahmström. Från datainsamling till rapport (ISBN 91-44-00111-8). Stu-dentlitteratur (1996)

[6] J. Friedl. Mastering Regular Expressions (ISBN 0-596-00289-0). O’Reilly &Associates, Inc. (2002)

[7] C. Hunt. TCP/IP Network Administration (ISBN 1-56592-322-7). O’Reilly &Associates, Inc. (1998)

[8] J. Miller., A. Sheth., K. Kochut., Z. Luo. Recovery Issues in Web-BasedWorkflow. Proceedings of the 12th International Conference on ComputerApplications in Industry and Engineering (CAINE-99), Atlanta, Georgia.http://chief.cs.uga.edu/~jam/papers/webwork_rec2.ps (URL nådd2006-06-01). (1999)

[9] T. Parr. Enforcing Strict Model-View Separation in Template Engines. http://www.www2004.org/proceedings/docs/1p224.pdf (URL nådd 2006-06-01).(2004)

39

[10] L. Wall, T. Christiansen, R. L. Schwartz. Programming Perl (ISBN 1-56592-149-6). O’Reilly & Associates, Inc. (1996)

40

TRITA-CSC-E 2006:084 ISRN-KTH/CSC/E--06/084--SE

ISSN-1653-5715

www.csc.kth.se