Tempus Custode. En GPS-tidrapporteringsapplikation. Tempus Custode An application for GPS time reporting. Peter Fryxelius Oscar Ternström

Transkript

1 Tempus Custode En GPS-tidrapporteringsapplikation Tempus Custode An application for GPS time reporting Peter Fryxelius Oscar Ternström Fakulteten för Hälsa, Natur- och Teknikvetenskap Datavetenskap C-nivå, 15 HP Katarina Asplund Donald Ross

2

3 Tempus Custode - en GPStidrapporteringsapplikation Peter Fryxelius & Oscar Ternström 2014 Författaren/författarna och Karlstads universitet

4

5 Denna rapport är skriven som en del av det arbete som krävs för att erhålla en kandidatexamen i datavetenskap. Allt material i denna rapport, vilket inte är vårt eget, har blivit tydligt identifierat och inget material är inkluderat som tidigare använts för erhållande av annan examen. Peter Fryxelius Oscar Ternström Godkänd, 3 juni 2014 Handledare: Katarina Asplund Examinator: Donald Ross iii

6

7 Sammanfattning Denna uppsats beskriver Tempus Custode, en smarttelefonapplikation med vilken användaren kan registrera arbetstid och restid under arbetsdagen. Applikationen kommunicerar via en server med en databas. Datan som sparas i databasen kan manipuleras med ett administratörsverktyg, främst för att skapa färdiga tidrapporter. På så sätt kan användarens arbete med att tidrapportera sin dag avsevärt förenklas. Applikationen diskriminerar själv mellan arbetstid och restid, genom att applikationen löpande hämtar GPS-data från smarttelefonens GPS-mottagare. Det finns ett integritetsproblem i och med detta förfarande, eftersom arbetsgivaren kan följa den anställdes position under arbetsdagen. Applikationen kan ändå, under vissa förutsättningar, sägas följa personuppgiftslagen. Projektet Tempus Custode består av en mer eller mindre färdigutvecklad applikation som fungerar på alla moderna smarttelefoner. En enkel server har implementerats, tillsammans med en databas. Däremot finns inget utvecklat administratörsverktyg, utan data i databasen beskådas och manipuleras på annat sätt. Resultaten från tester av systemet har varit tillfredsställande och leder författarna att hävda, att målet för projektet har uppnåtts: Tempus Custode kan väsentligt förenkla användarens arbetsdag, genom att erbjuda enkel, semiautomatisk GPS-tidrapportering. v

8 Tempus Custode an application for GPS time reporting Abstract This paper describes Tempus Custode, a smartphone application with which the user may register working hours and travel time during the work day. The application communicates with a database via a server. The data stored in the database may be manipulated using an administrator tool, mainly for the composition of time reports. In this way, the user s task of time reporting his day is greatly simplified. The application is able to automatically discriminate between work time and travel time, as it continuously fetches positioning data from the smartphone GPS receiver. There is a personal integrity issue inherent in this operation, because an employer may supervise an employee s position during the work day. The application may still, with some qualifications, be in accordance with the Swedish Personal Data Act. The Tempus Custode project comprises one tentatively complete application that runs on all modern smartphones. A simple server has been implemented, together with a database. The administrator tool has not been developed. Data in the database are otherwise viewed and manipulated. The results of testing the system have been satisfactory, leading the authors to claim that the project s objective has been fulfilled: Tempus Custode can significantly simplify the work day of the user, by offering simple, semi-automatic, GPS time reporting. vi

9 Innehållsförteckning 1 Inledning Uppdragsgivaren och förutsättningar för uppdraget Bevekelsegrunder Mål Resultat Uppsatsens disposition Bakgrund Verktyg och tekniker GPS-satelliter Kommunikation mellan GPS-satellit och smarttelefon HTTP HTTPS C# NET-plattformen Sencha Architect Sencha Touch JavaScript MVC HTML5 2.2 Jämförelse med liknande applikationer Samtankes interna timer TimeLogger 2.3 Antaganden Smarttelefonens funktionalitet GPS och precision 2.4 Hänsyn Användarens integritet Personuppgiftslagen Säkerhet vid dataöverföring Lagring av data i databasen 2.5 Kapitelsammanfattning Design och implementation Tempus Custode tidväktaren Komponenter i Tempus Custode Smarttelefon med Tempus Custode tidrapporteringsapplikationen Server vii

10 3.2.3 Databas Administratörsverktyg Kommunikation mellan smarttelefon och server Kommunikation mellan server och databas Kommunikation mellan server och administrationsverktyg 3.3 Designval Användargränssnittet Relationsdatabasen Administratörsverktyget Stoppursmodellen Bakgrundskontroll av GPS-position Att välja användar-id Att välja arbets-id Avgöra skillnad mellan resa och arbete 3.4 Slutlig design GUI för Tempus Custode Logiken bakom GUI för applikationen Servern Databasen Administratörsverktyget 3.5 Implementationsdetaljer Hantering av GPS-data Trådsäkring Relationsdatabasen Administratörsverktyget 3.6 Kapitelsammanfattning Resultat och utvärdering Resultaten i korthet Kommentarer till resultaten Utvärdering av projektarbetet Utvärdering av resultatet gentemot förväntningar Utvärdering av arbetsmodellen Problem och efterklokhet Problem som tillstött Vad göra annorlunda? 4.7 Kapitelsammanfattning Sammanfattning Sammanfattning av projektet Tempus Custode Framtida utveckling av Tempus Custode A Navigationsekvationer och GPS B Beräkningar med GPS-data B.1 Avstånd mellan två positioner B.2 Avstånd med hänsyn till precision viii

11 Figurförteckning Figur 1.1: Projektet Tempus Custode och dess komponenter... 2 Figur 2.1: MVC-modellen... 9 Figur 3.1 Komponenter i Tempus Custode Figur 3.2 Osäkerheter i position jämfört med gränsvärde (limit) Figur 3.3 GUI Huvudvyn före start Figur 3.4 GUI Huvudvyn under tidsintervall Figur 3.5 GUI Konfigureringsvyn Figur 3.6 GUI Nyarbetsvyn Figur 3.7 Vy av databasen SQL Express Figur 5.1: Omvandling mellan kartesiska och polär koordinater Vissa figurer har komponerats med hjälp av clipart hämtat från Clker.com royaltyfria bilder: ix

12 1 Inledning Uppgiften var konstruktion av en mobilapplikation, med vilken en användare enkelt kan rapportera tidsåtgång, såväl för arbete som för resa till och/eller från kunden. Med denna applikation kan manuell tidrapportering avskaffas helt, under förutsättning att ett bakomliggande system - som också behöver konstrueras - producerar begripliga tidrapporter utifrån de data som skapas av applikationen. Målgruppen för applikationen är resande servicetekniker i allmänhet, även om uppdragsgivarens, Samtanke AB, kunder reparerar och underhåller i huvudsak storköksutrustning. Serviceteknikerna är oftast män, så för enkelhets skull används pronominet han om serviceteknikern i denna rapport. Förutsättningar: Applikationsanvändaren har en smarttelefon 1 (essentiellt är anslutning till internet och fungerande GPS 2 ) med sig under arbetspasset. Genom enkel interaktion med applikationen ska användaren, vid arbetspassets slut, med minsta möjliga ansträngning ha rapporterat arbets- och restider för passet. (Se Figur 1.1: Projektet Tempus Custode och dess komponenter) 1.1 Uppdragsgivaren och förutsättningar för uppdraget Uppdragsgivaren är Samtanke AB, som stödjer olika verksamheter med webbaserade och mobila lösningar. Samtanke AB består av tre medarbetare med kontor i Karlstad. Företagets kunder är serviceföretag inom storköksbranschen; kunderna reparerar och underhåller maskiner i snabbmatsindustrin. Samtanke AB har levererat ett flertal andra mobila lösningar till olika företag. Det har från Samtanke ABs kunder uttryckts önskemål om enklare sätt att hantera tidrapporteringen, men ingen beställning på ett sådant system har ännu skett. Systemet utvecklas alltså in spe; förhoppningen är att systemet (en senare raffinering av förevarande prototyp) ska vara av intresse för den typ av företag Samtanke AB redan nu assisterar. 1 Smarttelefon: en mobiltelefon med bland annat GPS-navigation, förmågan att exekvera tredjepartsapplikationer, internetåtkomst, Wi-Fi, etc.[28] 2 GPS: Global Positioning System, ett satellitsystem som levererar positions- och tidsdata till mottagare som har fri siktlinje till minst fyra GPS-satelliter.[20] 1

13 Ett resultat av detta är att författarna haft mycket fria tyglar när det gäller prototypens karaktär och parametrarna för det system som tagits fram. I denna rapport kommer flera designbeslut redovisas tillsammans med de faktorer som påverkat desamma. Figur 1.1: Projektet Tempus Custode och dess komponenter 1.2 Bevekelsegrunder Varför är då utvecklingen av en applikation av detta slag intressant? Att manuellt räkna ut och rapportera arbetstid, restid och eventuellt även ressträckor är en uppgift som kan ta avsevärd tid i anspråk för den resande serviceteknikern. En applikation av det slag som här undersöks torde vara mycket intressant för företag där tidrapportering är 2

14 såväl viktig som icke-trivial (motsatsen är personer som alltid arbetar klockan till 17.00, för vilka tidrapporteringen betraktas som trivial). Den teknik som används existerar redan och är mycket vidspridd i samhället. Applikationen utnyttjar alltså befintliga resurser, snarare än banar ny väg inom tekniken. Grundtanken är att förenkla användarens arbetsdag, samtidigt som denne ska behöva investera minimal tid och energi i att lära sig applikationen. Enkelhet är den viktigaste egenskapen för den slutliga produkten. Arbetet med detta system är intressant för författarna, eftersom de erbjuds möjligheten att bekanta sig med vad de förmodar är viktiga aspekter av det moderna IT-samhället: smarttelefoner, GPS, servrar, samt utvecklingsverktyg för dessa. Enkelhet har en inneboende elegans. Flera föreläsare på Karlstad Universitet författarnas lärosäte har betonat hur viktigt det är med enkelhet vid utvecklingen av programvara, inte minst för att programmet kan förmodas ha färre dolda brister om det är enkelt (här avses alltså enkelhet för utvecklaren, inte nödvändigtvis enkel användning eller enkelt underhåll av koden). Applikationen är alltså intressant för företag med resande anställda, eftersom den effektiviserar arbetet. Den är även intressant för den anställde, eftersom den erbjuder ett sätt att förenkla arbetsdagen. Arbetet är även högst intressant för författarna, då de får kontakt med näringslivet och kan bekanta sig med nya verktyg och programspråk, vilket breddar deras kompetens. Om författarna lyckats hålla sig till enkelhetens ledstjärna kan applikationen även vara av akademiskt intresse. 1.3 Mål Det mål som gavs för projektet var att utveckla en mobilapplikation för GPS-tidrapportering som ett proof of concept. Det betyder att målet var att visa genomförbarheten av en GPStidrapporteringsapplikation och skissera en lösning. Applikationen och vidhängande komponenter behövde alltså inte vara fullt utvecklade. Fokus skulle i stället ligga på designval och metoder för att lösa problem omkring GPS-tidrapportering. Den löst formulerade projektspecifikationen har låtit författarna själva sätta upp mål för utvecklingen. Några av dessa mål var: Att undersöka problematiken kring arbetsgivarens önskan att med GPSpositionering förenkla tidrapporteringen gentemot arbetstagarens rätt till privatliv. Utgångspunkten för denna undersökning var personuppgiftslagen.[15] 3

15 Att undersöka om en ny produkt av typen GPS-tidrapportering är befogad. Finns det redan liknande, eller rent av bättre produkter? En jämförelse med någon sådan produkt är på sin plats. Att utveckla en design för en smarttelefonapplikation och fundera över vilka designprinciper som är viktiga. Att implementera denna design i ett enkelt proof of concept; en liten applikation med de absolut mest nödvändiga komponenterna. Applikationen behöver inte ha full funktionalitet och kringliggande komponenter kan simuleras på enklast möjliga sätt. 1.4 Resultat Resultatet av projektet är en enkel GPS-tidrapporteringsapplikation, kallad Tempus Custode. Problematiken kring personuppgiftslagen och lagring av data gällande den anställdes GPSposition kan lösas om vissa grundläggande riktlinjer följs, se avsnitt (Personuppgiftslagen). Tempus Custode har vissa drag som gör applikationen relevant på marknaden, även om det redan finns liknande applikationer, se avsnitt 2.2 (Jämförelse med liknande applikationer). Användarvänligheten och det specifika fokuset mot tidrapportering talar för Tempus Custodes relevans. Applikationens design är semiautomatisk: Användaren avgör när ett tidsintervall ska inledas och avslutas genom att använda smarttelefonapplikationen. Under klockning av ett intervall arbetar applikationen självständigt och försöker löpande avgöra huruvida användaren arbetar eller reser, beroende på lagrad data om användarens GPS-koordinater. Smarttelefonapplikationen samlar alltså data och skickar dessa (ibland automatiskt, utan att användaren involveras) som tupler (rader) till en relationsdatabas. Från datan i databasen ska ett administratörsverktyg kunna sammanställa tidrapporter. I prototypen finns inget administratörsverktyg. Verktyget simuleras i stället av ett program med vilket man kan bese och manipulera databasen, dock utan begränsningar eller med för Tempus Custode avsedd funktionalitet (till exempel förmågan att sammanräkna tupler till en färdig tidrapport). 4

16 1.5 Uppsatsens disposition Uppsatsens disposition är som följer: Kapitel 2 (Bakgrund) beskriver de verktyg och tekniker som använts under projektet. Tempus Custode jämförs sedan med liknande applikationer, främst TimeLogger. Vissa antaganden om smarttelefonens funktionalitet och hanteringen av GPS-data görs, och hänsyn vad gäller användarens integritet undersöks med utgångspunkt i personuppgiftslagen. Kapitel 3 (Design och implementation) presenterar Tempus Custode och dess komponenter. Designmöjligheter undersöks och val mellan dessa görs. Den slutliga designen av framför allt smarttelefonapplikationen presenteras, varpå några implementationsdetaljer redovisas. Kapitel 4 (Resultat och utvärdering) presenterar resultaten av projektet Tempus Custode. Projektarbetet utvärderas, varpå några problem beskrivs tillsammans med idéer om hur arbetet kunnat utföras annorlunda. Kapitel 5 (Sammanfattning) sammanfattar rapporten av projektet Tempus Custode. Här skisseras också hur en framtida utveckling av Tempus Custode skulle kunna se ut och vilken funktionalitet som utelämnats ur projektet. 5

17 2 Bakgrund I detta kapitel presenteras bakgrunden till projektet. Avsnitt 2.1 (Verktyg och tekniker) redogör för de rådande tekniska förhållanden som påverkar projektet, till exempel positioneringsteknik, transportprotokoll, utvecklingsspråk och modeller. Avsnitt 2.2 (Jämförelse med liknande applikationer) gör en kort jämförelse mellan Tempus Custode och en lösning som hittills använts av Samtanke AB. Sedan görs en mer detaljerad jämförelse med TimeLogger. Avsnitt 2.3 (Antaganden) beskriver vilka förutsättningar som antas gälla under projektet, inklusive hur GPS-data hanteras. Avsnitt 2.4 (Hänsyn) beskriver hur användarens integritet kan hotas när Tempus Custode används och hur personuppgiftslagen är relevant i dessa fall. Dessutom poängteras vikten av säkerhet vid dataöverföring och rutiner för lagring av data i databas. Kapitlet sammanfattas i avsnitt Verktyg och tekniker I detta avsnitt beskrivs positioneringssystemet GPS och kommunikationen mellan satelliter och smarttelefoner. De grundläggande applikationsprotokollen HTTP och HTTPS presenteras och programspråket C# introduceras som en del av.net-plattformen. Utvecklingen av mobilapplikationen har skett med Sencha Architect, vilket använder Sencha Touch, ett JavaScript-ramverk. Dessa tekniker beskrivs kortfattat. Programmeringsmodellen MVC presenteras, liksom webbmärkspråket HTML GPS-satelliter Runt jorden cirklar idag 32 satelliter som utgör rymdsegmentet av det så kallade Global Positioning System. Med anor i USAs hemliga forskningsprojekt under 1960-talet var GPS (då med ett rymdsegment av 24 satelliter, kallade Space Vehicles, eller SVs) ett nationellt militärt projekt. Under president Reagan gjordes degraderad data 3 från satelliterna tillgänglig för den globala allmänheten och under president Clinton avskaffades degradering av publik data helt och hållet.[20] 3 Degraderad data innebär, att signalen medvetet förvanskas för att ge en osäkerhet i GPS-positionen på 100 meter. Skälet till degraderingen var en önskan att hindra civila applikationer från att kunna användas för militära syften: t.ex. målsökningssystem för vapen. 6

18 Det finns flera globala positionssystem. Såväl Ryssland och Kina som Indien och EU har i någon mån utvecklade globala positioneringssystem. Trots detta används idag GPS mest av gemene man, just på grund av den allmänna tillgängligheten, får man förmoda. En mottagare på jordytan kan i allmänhet få kontakt med omkring nio GPS-satelliter. Det räcker med fyra för att särskilda navigationsekvationer 4 ska kunna lösas, vilka ger användarens position med god noggrannhet Kommunikation mellan GPS-satellit och smarttelefon Varje GPS-satellit sänder kontinuerligt signaler, vilka kan uppfattas av smarttelefonen. Meddelandet innehåller information om den tidpunkt vid vilken signalen skickades ut, samt satellitens position då signalen utsändes. Med dessa data från minst fyra satelliter kan positionen bestämmas (se bilaga A). Dessutom kan signalerna fastställa tiden; GPS erbjuder alltså en tillförlitlig klocka. En GPS-mottagare har en antenn, med vilken mottagaren kan övervaka signaler på GPSsatelliternas frekvens. Det antal kanaler som används motsvarar hur många olika satelliter som kan övervakas samtidigt. Moderna enheter kan ha uppåt 20 kanaler HTTP HTTP står för HyperText Transfer Protocol, och är det idag grundläggande applikationsprotokollet för kommunikation över webben. Protokollet definierar strukturen hos två typer av meddelanden: begäran och svar. Idag används versionen HTTP/1.1.[10] HTTPS HTTPS (HTTP Secure) är ett kommunikationsprotokoll för säker dataöverförning över webben. Tekniskt sett så är det egentligen inte ett eget protokoll utan en hybrid mellan protokollen HTTP och TLS (Transport Layer Security), det vill säga en inbyggd kryptering av datan i HTTP. Säkerheten uppnås genom långlivade publika och privata nycklar, med vilka man upprättar sessionsnycklar för varje ny session.[22][11] C# Det programspråk som har använts för utvecklandet av serversidan av applikationen är C# (uttalas C sharp ). Detta språk stöds av Visual Studio[26] och kan köras på.net-plattformar (se avsnitt nedan). C# är typsäkrat och objektorienterat. 5 4 Se bilaga A. 5 Se t.ex. Microsofts hemsida för C#.[8] 7

19 C# ger alltså möjligheten att på hög nivå och med objektorientering skapa applikationer och kod i rask takt. Många programmeringshänsyn som till exempel garbage collection kan ignoreras, eftersom det hanteras transparent för programmeraren NET-plattformen.NET (uttalas dot-net ) är ett ramverk för mjukvara, designat av Microsoft. Den grundläggande tanken är att kod, skriven med olika språk, fortfarande ska kunna interoperera. För att kunna skapa denna bas för mjukvaruutveckling består.net av följande två komponenter[17]: Common Language Runtime (CLR), en virtuell maskin på applikationsnivå. Med denna komponent kan kod, skriven på olika språk, kompileras och köras tillsammans. Här finns stöd för till exempel minneshantering och säkerhet. CLR är.netplattformens implementering av CLI (Common Language Infrastructure), en så kallad språkneutral plattform 6. Ett gemensamt klassbibliotek (Base Class Library) för.net-lösningar ger grundläggande funktionalitet inom områden som användargränssnitt, dataåtkomst, nätverkskommunikation, et cetera Sencha Architect Sencha Architect 3 är ett verktyg, där man använder ramverket Sencha Touch 2.3.x (se nedan) för att utveckla HTML5-applikationer för såväl mobiltelefoner som för läsplattor och persondatorer. Genom en relativt intuitiv miljö kan till exempel mobil-applikationer konstrueras, varvid avsevärd mängd kod (JavaScript) genereras automatiskt, vilket förenklar utvecklingsarbetet Sencha Touch Sencha Touch är ett JavaScript-ramverk med ett användargränssnitt. Inriktningen är mot mobila applikationer och baseras på bland annat HTML5. Gränssnittet ger tillgång till allmängiltiga menyer, knappar och textfält. Dessa kan enkelt kombineras och kopplas till händelser (events, exempelvis skärmberöring, så kallad tap), där funktionalitet kan kodas. Sencha Touch använder MVC-mönstret (se avsnitt ).[14] 6 CLI beskrivs i [18]. Språk som stöder CLI återfinns i [25]. 8

20 2.1.9 JavaScript JavaScript är ett programspråk med lös typning, vilket ofta används i webbsidor för att göra dessa interaktiva. Syntaxen liknar den för C, men språket är ett multiparadigmspråk som stöder objektorienterad, imperativ och funktionell programmering. Likheterna med Java är trots namnlikheten mycket små och begränsar sig till namngivningskonventioner.[24] MVC MVC är akronym för Model-View-Controller, ett programmeringsmönster som är användbart vid programmering av användargränssnitt. Mönstret innehåller tre delar: modell, vy och controller. Modellen innehåller data, logik och regler, vyn är det för användaren synliga användargränssnittet och controllern manipulerar vy och modell utifrån användarens indata. Figur 2.1 beskriver både avgränsning och interaktion mellan dessa tre delar (se Figur 2.1: MVC-modellen):[27] Figur 2.1: MVC-modellen HTML5 HTML5 är ett relativt nytt märkspråk (markup language) för webben 7. Det inkluderar strategier för införlivandet av audio och video, samt även mer avancerad grafikhantering, vilket saknats i tidigare versioner av HTML. I dessa tidigare versioner har man istället behövt använda så kallade plug-ins (som till exempel Flash) för att införliva audio och video. Med HTML5 kan man även avse kombinationen av märkspråket själv, CSS3 (Cascading Style Sheets, vilket hjälper till att beskriva färg, font och layout i märkspråkstexter) och JavaScript[21] 8. 7 Från 2012, enligt [5]. 8 Mer information om HTML5 och arbetsgruppen som konstruerar detta språk kan hittas t.ex. på [30]. 9

21 2.2 Jämförelse med liknande applikationer Många företag erbjuder idag mobil tidrapportering. Två exempel på sådana tidrapporteringssystem är Samtanke ABs egen tidrapporteringsmekanism, inbäddad i ett teknikerverktyg, samt TimeLogger till iphone, vilka beskrivs nedan Samtankes interna timer Samtanke AB har i sina teknikerverktyg redan implementerat en enkel timer, vilken kan ge tid till en tidrapport. Den är enkel och erbjuder endast möjlighet att starta och stoppa timern, utan möjlighet att differentiera mellan resa och arbete. Enligt Samtanke AB används denna funktion inte i nämnvärd utsträckning TimeLogger TimeLogger är en applikation till iphone och ipod Touch, tillgänglig på iphone App Store.[1] 9 Applikationen kan även användas på smartklockan 10 Pebble, vilket gör den mycket portabel, förutsatt att användaren använder denna armbandsklocka. Pebbles användargränssnitt består av en skärm och fyra tryckknappar, vilket allvarligt begränsar hur en applikation kan se ut. I en recension av en ny version av TimeLogger står följande (egen översättning): TimeLogger är en rätt djup applikation (det finns många finesser) med ett gränssnitt som inkluderar en liten skärm och bara 4 knappar, och det ursprungliga målet var att kunna sköta TimeLogger från en Pebble-klocka med så få klick som möjligt. Vi nådde målet, men på vägen fick vi ett användargränssnitt som inte var så otroligt intuitivt. Efter att ha gått igenom appen med Pebbles UX ledning stod det klart att vi behövde göra upplevelsen mer intuitiv, även om det medföljde att vi lade till några extra klick. Resultatet är en riktigt bra och än mer finessrik smartklockeapplikation för att kontrollera TimeLogger från din Pebble. [12] Av särskilt intresse är likheterna i målsättningen med den för Tempus Custode: Applikationen ska kunna hanteras med så få klick som möjligt (se avsnitt nedan). Dessutom strävar båda applikationerna mot så få knappar som möjligt. I denna strävan styrs TimeLogger av hårdvaran för Pebble; den har bara fyra knappar. 9 En mer detaljerad beskrivning av gränssnitt och funktionalitet hittas på [12]. Smartklockan Pebble kan beses på: ( ), eller [29]. 10 Med en smartklocka avses ett armbandsur med funktionalitet liknande den på en smarttelefon. De för projektet relevanta finesserna inkluderar möjligheten att köra mobila applikationer, GPS-navigation, samt att kommunicera genom till exempel Bluetooth eller Wi-Fi.[29] 10

22 Den insamlade datan i TimeLogger ska lätt kunna exporteras till Excel eller ett likvärdigt kalkylblad. Det är ganska likt det mål som föreligger Tempus Custodes administratörsverktyg, där datan från databasen ska kunna exporteras till just ett kalkylblad (se nedan). En TimeLogger-timer kräver en hel del knapptryck för att initieras. Tempus Custode, å sin sida, kräver endast inmatning av ett så kallat arbets-id. Information av denna typ kan hämtas av administratörsverktyget (och finns i en annan relation i databasen, se avsnitt nedan). TimeLogger kan ha flera timers igång samtidigt. Det kan inte Tempus Custode, men å andra sidan är det inte meningen att en och samma förflutna tid ska kunna debiteras flera gånger (till exempel för olika jobb), så denna arbetsuppgift (liksom en del annan funktionalitet hos TimeLogger) faller utanför ramarna för Tempus Custode. En pågående timer kan avbrytas (slängas). Detta kan Tempus Custode inte göra. Tanken är i stället att felaktiga tupler i databasen ska kunna korrigeras med administratörsverktyget. Trots likheterna är det svårt att jämföra TimeLogger med Tempus Custode med avseende på enkelhet och få knapptryckningar. Detta beror på att TimeLogger har mer funktionalitet, vilket ju kan ses som positivt, men detta resulterar i fler knapptryckningar per tidtagning, vilket är negativt. Tempus Custode utför bara ett arbete åt gången, och är inte en lika allmängiltig applikation som TimeLogger, men å andra sidan är Tempus Custode jämförelsevis enklare och kräver mycket få knapptryck per arbete. Tempus Custode kan automatiskt byta från arbetstid till restid (och vice versa) utan att användaren behöver tillfrågas. Denna funktionalitet verkar saknas i TimeLogger. Slutligen är TimeLogger en applikation enbart för iphone och ipod Touch, medan Tempus Custode fungerar på alla populära smarttelefoner. Ovanstående ger vid handen, att TimeLogger och Tempus Custode har många likheter, men fyller olika behov. TimeLogger har en inneboende allmängiltighet, medan Tempus Custode löser sin specifika uppgift med färre knapptryckningar och kräver mindre specifik hårdvara. Detta kan vara avgörande för ett företag, som kanske är ovilliga att köpa just iphones till sina anställda servicetekniker. Sammanfattningsvis verkar projektet Tempus Custode trots likheterna kunna tillföra någonting nytt och därför vara relevant. 11

23 2.3 Antaganden De förutsättningar som givits för uppdraget har varit löst preciserade. Eftersom ingen kund ännu finns, är projektet en strävan att skissera en produkt vilken tilltalar resande servicetekniker och deras arbetsgivare. Det grundläggande antagandet har varit detta: Om inte applikationen är enkel att förstå och enkel att använda, kommer den inte heller användas. Enkelhet har alltså varit den främsta ledstjärnan vid utvecklingen av Tempus Custode (se även avsnitt nedan). Andra antaganden för projektet är som följer: En servicetekniker (användaren) har tillgång till en smarttelefon under en arbetsdag som innebär resor till och från uppdragsgivare samt arbetspass hos dessa uppdragsgivare. Arbetstid och restid ska debiteras uppdragsgivarna, men inte enligt samma taxa, varför de behöver separeras som skilda typer av debiterbar tid. Användaren har möjlighet att själv tidrapportera sin dag med hjälp av papper och penna. Att använda sig av GPS-tidrapporteringsapplikationen Tempus Custode ska väsentligt förenkla arbetsdagen, genom att erbjuda ett alternativ till manuell tidrapportering. Applikationen ska alltså: Uppmäta och lagra förfluten tid, som ett stoppur. Typsätta lagrad tid som antingen arbetstid eller restid. Skicka lagrad data till en central databas, varifrån datan kan behandlas till en färdig tidrapport för aktuellt uppdrag. Denna behandling bör vara automatisk, eller åtminstone lättvindig att genomföra. I inget fall ska användaren själv behöva befatta sig med behandling av datan. Arbetsinsatsen för tidrapporteringen ska begränsas till att specificera arbete (ange ett arbets-id), starta och stoppa klockan. Nedan beskrivs andra viktiga antaganden om smarttelefonens funktionalitet och om behandling av GPS-data Smarttelefonens funktionalitet För att Tempus Custode ska fungera krävs det att användarens smarttelefon har tillgång till internet och att den kan ta emot GPS-signaler från GPS-satellitnätet. Kontakten med internet måste vara pålitlig. Transportprotokollet som används för dataöverföring är TCP, vilket hanterar grundläggande aspekter i överföringssäkerhet, som förhindrande av korruption och förlust av datapaket. Däremot måste TCP-förbindelsen kunna upprättas för att så ska vara fallet. Sålunda måste både sändare (smarttelefonen) och mottagare (server) ha en stabil uppkoppling mot internet. Det bör noteras, att HTTP använder TCP implicit, författarna behövde inte själva arbeta på transportlagernivå. 12

24 Den ovan beskrivna stabiliteten antas föreligga under projektet Tempus Custode. I dagsläget finns inga implementerade metoder för att köa meddelanden eller återetablera en bruten kontakt mellan sändare och mottagare ifall nätförbindelsen skulle haverera. En färdig produkt måste naturligtvis innehålla metoder för att upptäcka och hantera brott i kommunikationen mellan smarttelefon och server GPS och precision På samma sätt som internet antas GPS vara tillgänglig och tillförlitlig när Tempus Custode körs. Här tillstöter att annat problem: det tar tid att hämta GPS-data, varför implementationen måste anpassas för detta (se avsnitt 3.5.2). Om GPS-positioner inte kan hämtas finns inga förutsättningar för att kunna skilja mellan arbetstid och restid (se avsnitt 3.3.8). I dessa fall förutsätts all data vara av typen arbete. Önskar användaren i efterhand ändå specificera viss tid som restid måste han via administratörsverktyg ändra bland databasens tupler. Användarens GPS-data används för att räkna ut var användaren befinner sig. Denna position kan jämföras med föregående position för att avgöra om användaren rört på sig sedan senaste mätning. Denna jämförelse ger sträcka över tid, det vill säga medelhastighet, vilket i vissa fall kan användas för att inferera resa, snarare än arbete. Dessutom förutsätts arbete föreligga på en enda plats och förändringar i position från denna plats under arbetets gång förväntas vara små. Därför används ett konstant gränsvärde för att jämföra med: Om den absoluta förflyttningen från arbetets startposition överskrider gränsvärdet, måste man anta att arbetet avslutats, och att en resa påbörjats. GPS-datan innehåller longitud och latitud för mottagaren, men även precisionen (eller osäkerheten) för beräkningen av föregående värden. Precisionen påverkar hur GPSkoordinaterna kan användas (se avsnitt 3.5.1). 2.4 Hänsyn I detta avsnitt beskrivs särskilda hänsyn som har behövt beaktas vid konstruktionen av Tempus Custode. I synnerhet spelar användarens integritet, personuppgiftslagen, säkerhet vid dataöverföring samt lagring av data i databas stor roll Användarens integritet Med användarens integritet avses här användarens personliga integritet när denne använder Tempus Custode. Personlig integritet behandlar den rätt till privatliv och egen sfär som en 13

25 människa garanteras (eller inte, beroende av det land människan bor i) genom lag och FNs deklarationer om de mänskliga rättigheterna. Det är viktigt att inse att dessa rättigheter inte är absoluta, utan ställs i relation till bland annat andra människors rätt till personlig integritet, statens intressen (till exempel säkerhetspolitiska) och i staten gällande lagar. Användaren av Tempus Custode förutsätts vara en resande servicetekniker 11. Han har alltså en arbetsgivare, vilken samlar data om hans arbetsdag genom applikationen Tempus Custode. Dessa data innefattar arbetstider, vilka användaren själv anger genom att använda applikationen, men även GPS-koordinater, vilka han själv inte har någon kontroll över. Genom GPS-koordinater och data om tidpunkter kan arbetsgivaren i detalj studera var användaren befinner sig under arbetsdagen. Om den sparade datan överförs på ett osäkert sätt (se avsnitt 2.4.3) kan den läcka ut till andra än arbetsgivaren. Datan sparas i en databas, varför ett intrång i databasen skulle avslöja i hög grad personliga uppgifter om användaren (se avsnitt 2.4.4). I de ovan nämnda fallen kan främmande parter utröna personliga uppgifter om användaren, som de inte har rätt att utröna. Dessa fall utgör alltså hot mot användarens integritet Personuppgiftslagen Det dokument som styr svenskt förhållande till användarens integritet är personuppgiftslagen (förkortas PUL eller PuL).[15] Kan arbetsgivaren lagligen via GPS kontrollera sina anställdas positioner under arbetsdagen? På Datainspektionens hemsida besvaras denna fråga med ett kvalificerat ja.[2] Förutsättningen för en sådan kontroll är en intresseavvägning mellan den anställdes integritet och arbetsgivarens behov av att kontrollen utförs. Kontrollen ska vara befogad och inte utföras slentrianmässig. Syftet med kontrollen ska också vara klart uttalat. Insamlad data får sedan inte användas i ett annat syfte än det uttalade. En hemsida med hänsyn som arbetsgivaren måste ta ges också av Datainspektionen.[3] Denna sida är högintressant för utvecklingen av Tempus Custode, varför huvuddragen i sidan parafraseras nedan (rubrikerna citeras i sin helhet), tillsammans med korta kommentarer om hur Tempus Custode påverkas: Utgå från att personuppgiftslagen gäller Det är lätt att koppla data till enskilda personer. Datan är sällan så anonym som den först ser ut att vara. Därför gäller personuppgiftslagen för Tempus Custode. 11 Enligt avsnitt

26 Klargör personuppgiftsansvaret Personuppgiftsansvarig är normalt den juridiska person som hanterar personuppgifter i en verksamhet. Vem som har personuppgiftsansvaret när en tjänst köps är inte lika självklart. Innan ett system används måste ansvaret tydligt bestämmas genom avtal. Om en tredje part samlar in uppgifter om de anställda, kan denna tredje parts ansvar beskrivas i ett så kallat biträdesavtal. Vid framtida användning av Tempus Custode kan det vara viktigt att upprätta sådana biträdesavtal, i de fall applikationen används av tredje part på uppdrag av en arbetsgivare. Tänk på att arbetstagare normalt inte kan samtycka Samtycke från en arbetstagare ses inte som frivilligt, eftersom arbetstagaren är i beroendeställning gentemot arbetsgivaren. Det räcker alltså inte att få sina anställda att godkänna användandet av GPS-övervakningen. Samtidigt finns det ett för Tempus Custode så viktigt undantag att det citeras i sin helhet: Om de anställda erbjuds rimliga alternativ och inte utsätts för någon direkt eller indirekt påtryckning att välja ett system baserat på positioneringsteknik, kan det vara tillåtet för arbetsgivaren att behandla personuppgifter med stöd av samtycken från de anställda. Ett sådant exempel är körjournalshantering, där de anställda kan välja mellan manuellt ifylld körjournal och ett system som bygger på positioneringsteknik. [3] Eftersom målet med Tempus Custode är att förenkla tidrapporteringen för den anställde, syns det klart att applikationen kan användas av ett företag om samtycke från arbetstagaren ges och det finns alternativ till applikationen (till exempel manuell tidrapportering). Precisera ändamålen med behandlingen Syftet med datainsamling ska vara uttalat och tydligt formulerat. Dessutom får uppgifter som samlats in med ett syfte sedan inte användas för ett annat syfte. De data som insamlas ska vara relevanta för syftet. Syftet ska vara förenligt med god sed på arbetsmarknaden, något som avgörs i diskussion mellan arbetsmarknadens parter. Syftet med Tempus Custode är förenklad tidrapportering. Detta syfte måste klart uttalas och datan från applikationen ska sedan endast användas till detta syfte. Spara inte uppgifter längre än nödvändigt Ska uppgifterna används i statistiska syften måste de avidentifieras. Då gäller inte längre personuppgiftslagen. För Tempus Custode är det tänkt att datan lagras i databas. Därifrån sammanställs datan till färdiga tidrapporter. När väl detta skett bör datan i databasen ses som föråldrad och raderas. Detta sker dock inte automatiskt i skrivande stund, utan bör implementeras i det framtida administratörsverktyget. Ge tydlig information till de anställda De anställda ska i förväg informeras om databehandlingen, såväl vilken data som insamlas som syftet med insamlingen och hur länge 15

27 data sparas. En arbetsgivare som ämnar använda Tempus Custode måste alltså införa rutiner för att meddela sina anställda denna information. Skydda personuppgifterna Överföring av uppgifter via öppna nät (som internet) ska ske via kryptering. Åtkomst av sparad data ska vara kontrollerad (till exempel med behörighetsstyrning). Dessutom ska manipulering av data (läsning, skrivning och ändring) loggas. Det ännu inte utvecklade administrationsverktyget till Tempus Custode behöver alltså använda inloggningsuppgifter och dessutom logga transaktioner i systemet. Slutligen poängterar Datainspektionen att en arbetsgivare inte får använda positionsbestämningsdata för att rutinmässigt kontrollera sina anställdas arbetstider. Det är endast tillåtet undantagsvis vid konkret misstanke om allvarligt missbruk av arbetsgivarens förtroende [3] Säkerhet vid dataöverföring De data som skickas måste vara tillräckligt krypterade för att hindra obehöriga från att ta del av densamma. Protokollet HTTPS anses vara tillräckligt starkt för att tillgodose säkerhetskraven i kommunikation mellan smarttelefonapplikationen, servern, databasen och administrationsverktyget. Denna säkerhet är nödvändig för att Tempus Custode inte ska stå i strid med personuppgiftslagen, enligt avsnittet ovan. Hur säkra är GPS-signalerna? Ett problem är svårigheten att avgöra om inkommande data är data från satelliterna själva, eller så kallad spoofad data[13]. Detta problem verkar inte lösbart i dagsläget, men utgör inget hot att användardata komprometteras. Däremot kan data som härleds från falska GPS-signaler naturligtvis leda till orimliga positioner. Detta skulle kunna leda till tupler i databasen med tidstypen restid, som egentligen hade varit av tidstypen arbete, om inte spoofad GPS-data förvirrat applikationen Lagring av data i databasen Avsnitt ovan (rubriken Spara inte uppgifter längre än nödvändigt) indikerar att det är viktigt att datan i databasen inte lagras på obestämd tid. Efter nyttjande av datan för att sammanställa en tidrapport borde datan raderas från databasen. Man skulle kunna tänka det så, att datan migrerat från databasen till det medium administrationsverktyget använder för att spara data. Därmed är loggning och lagring en uppgift för administrationsverktyget. Om datan i databasen är intressant ur statistiskt perspektiv, bör den avidentifieras innan den används. Även i detta fall bör datan migreras från databasen till en annan databas, så att inte gammal, avidentifierad data ligger blandad med ny (och fortfarande anländande) data. 16

28 Dessutom kommer tuplernas utseende att ändras vid en avidentifiering: Till exempel borde GPS-positionerna själva vara ointressanta. Kanske ersätts de med ett attribut som helt enkelt anger skillnad (i meter) mellan start- och slutposition. 2.5 Kapitelsammanfattning I detta kapitel har förutsättningar för GPS-tidrapporteringsapplikationen Tempus Custode översiktligt beskrivits. Först beskrevs de verktyg och tekniker som använts under projektet. GPSpositioneringssystemet har förklarats, liksom webbprotokollen HTTP och HTTPS. Programspråket C# har använts som en del av ramverket.net, när servern utvecklades. Mobilapplikationen utvecklades med Sencha Architect, vilken använder Sencha Touch (ett JavaScript-ramverk). Programmeringsmönstret MVC beskrevs, liksom webbmärkspråket HTML5. Sedan jämfördes projektet Tempus Custode med en funktion i Samtanke ABs existerande affärslösningar (vilken inte används i större utsträckning) och med TimeLogger. Likheterna mellan Tempus Custode och TimeLogger var många, men de skilde sig också på några viktiga punkter: TimeLogger är mycket mer generell i sin design, men också mindre enkel än Tempus Custode, vars inriktning är förenklad tidrapportering. Förutsättningarna för projektet har skissats och vissa grundläggande antaganden har gjorts, gällande smarttelefonens funktionalitet och hur GPS-data ska hanteras. Slutligen har viktiga hänsyn gällande användarens personliga integritet, säkerhet vid dataöverföring och lagring av data i databas diskuterats, med utgångspunkt i personuppgiftslagen. 17

29 3 Design och implementation Detta kapitel börjar med att i avsnitt 3.1 (Tempus Custode tidväktaren) presentera Tempus Custode och i avsnitt 3.2 (Komponenter i Tempus Custode) beskriva delarna i projektet och kommunikationen dem emellan. Avsnitt 3.3 (Designval) diskuterar några av de designval författarna gjort under projektet, medan avsnitt 3.4 (Slutlig design) skisserar utseendet av den färdiga produkten (särskilt smarttelefonapplikationen). Avsnitt 3.5 (Implementationsdetaljer) tar upp några detaljer i Tempus Custodes implementation. Kapitlet sammanfattas i avsnitt Tempus Custode tidväktaren Namnet som getts åt den prototyp som framtagits är Tempus Custode. Namnet är latin: tempus betyder tid, custode betyder väktare. Med väktare avses innebörden handhavare eller intendent snarare än övervakare (en roll som för all del är möjlig, men som undvikits under utvecklandet 12 ). Engelskans låneord custodian beskriver syftet med applikationen: att handha tiden åt användaren, för att denne inte överdrivet ska behöva bekymra sig om tidrapporteringen. Tempus Custode är en applikation, där man i en smarttelefon ska kunna mäta arbetstid och restid samt koppla dessa till sitt användar-id och ett lämpligt valt arbets-id, vilka unikt definierar arbetet. Den totala tiden ska automatiskt rapporteras till en databas, från vilken en administratör ska kunna (mer eller mindre automatiskt) generera en tidrapport för arbetet, där total restid och arbetstid kan debiteras kunden. Komponenterna i Tempus Custode beskrivs av Figur 3.1. (Den uppmärksamme läsaren kan notera att det är samma figur som i kapitel 1, flyttad hit för ökad tillgänglighet.) 12 Se avsnittet där användarens integritet diskuteras. 18

30 Figur 3.1 Komponenter i Tempus Custode Applikationen i smarttelefonen är semiautomatisk: Användaren startar och stoppar applikationen själv, men under tiden applikationen körs kan den själv utföra ett begränsat antal uppgifter. I synnerhet kan applikationen urskilja mellan arbete och resa med hjälp av användarens GPS-position. På så vis kan applikationen reparera eventuella misstag från användarens sida. Ett exempel: Användaren startar Tempus Custode vid början av en resa till ett uppdrag. När han kommer fram glömmer han att stänga av klockan och sedan starta den på nytt (detta är ju ett sätt att skilja mellan restid och arbetstid, vilka debiteras kunden enligt olika taxor). Tempus Custode kommer med jämna mellanrum kontrollera användarens GPS-position och avgör vilken typ av tidrapport som är lämplig utifrån denna position. I detta exempel kommer applikationen upptäcka att restid har avslutats och arbetstid påbörjats och rapportera tiden enligt detta. 19

31 3.2 Komponenter i Tempus Custode Figur 3.1 beskriver överskådligt applikationen Tempus Custode med dess komponenter. De element som krävs är: en smarttelefon med applikationen, en server, en databas och ett administrationsverktyg på en persondator. Dessutom utnyttjas GPS-systemet av smarttelefonen. Följande avsnitt beskriver nämnda element, tillsammans med kommunikationskanalerna dem emellan: Smarttelefon med Tempus Custode tidrapporteringsapplikationen Med en smarttelefon avses en telefon med avancerade funktioner, som internetanslutning med hjälp av Wi-Fi, digitalkamera, GPS-navigationsenhet, mediaspelare, tryckkänslig skärm, med mera. Av dessa är GPS-navigationen och internetuppkopplingen av central betydelse för Tempus Custode. Utvecklingen av applikationen Tempus Custode har skett med verktyget Sencha Architect 13, som försäkrar att den färdiga applikationen skall kunna exekveras på följande mobila operativsystem: ios 4+ (Apples produkter); BB OS 10 och BB Tablet OS 1 (Blackberry-produkter); Windows Phone 8 (Nokia-produkter); samt Kindle OS och Android 2.2+ (produkter av Samsung, Motorola, et cetera).[14] Server Servern utgör mellanhand för kommunikation mellan smarttelefonen med applikationen Tempus Custode och den databas som lagrar data från applikationen. Servern skall vara åtkomlig via internet under den tid applikationen ska användas, och tar emot data från applikationen och transformerar den till tupler i en relationsdatabas. Vidare kan den på uppmaning från ett administrationsverktyg även hämta tupler från databasen för presentation till administrationsverktyget. I detta projekt användes servern IIS (Internet Information Services)[7][23], eftersom uppdragsgivaren redan använder IIS i andra projekt. Vana vid redskapet och förenklad kombination av färdiga projekt är alltså skälet till att välja just IIS. 13 Se även avsnitt 2.1.7, där Sencha Architect beskrivs vidare. 20

32 IIS är Microsofts webbserver, vilken stöder bland andra protokollen HTTP och HTTPS 14. Det finns en nedbantad freeware-version, kallad IIS Express, vilken också skulle ha varit tillräcklig för projektets syfte, men enligt argumentet i stycket ovan användes inte denna version. I detta projekt har Microsoft Visual Studio använts för att skapa serverkoden. Microsoft Visual Studio är ett så kallat IDE (integrated development environment) för skapandet av bland annat grafiska användargränssnitt (GUI) och webbsidor.[26] Databas Den databas som används i projektet är Microsoft SQL Server Express. Detta program är gratis att ladda ned och använda. Servern kan hantera relationsdatabaser med upp till 10 GB data, vilket är mer än tillräckligt för Tempus Custode. Lättvindigheten i användandet har gjort att uppdragsgivaren redan använder SQL Express i flera egna uppdrag. Samma argument som presenterades i avsnitt ovan gäller alltså för att arbeta med just SQL Express Administratörsverktyg Administratörsverktyget är någon applikation, menad att köras på en persondator, med vilken en administratör, exempelvis företagets ekonomiassistent, enkelt kan sammanställa datan i en databas för att få ut tidrapporter för företagets anställda. Administratörsverktyget kan implementeras till exempel med en webbläsare gentemot servern. Verktyget är inte implementerat, mer än att data i databasen kan beses och enkla sökningar kan ske Kommunikation mellan smarttelefon och server Kommunikationen mellan smarttelefon och server skedde under utvecklingsstadiet med protokollet HTTPS. HTTPS kräver certifikat, vilket Samtanke AB tillhandahöll 15. För en fungerande prototyp kunde ju det icke krypterade kommunikationsprotokollet HTTP vara tillräckligt, men en färdig produkt måste skicka krypterad data. 14 Se [23] samt [7]. Sägs vara den tredje vanligaste webbservern, efter Apache och Nginx, enligt [16]. En något mer optimistisk rapport på Netcraft.com[9] menade att IIS var den andra vanligaste webbservern, med en marknadsandel av 32.8%. 15 För utveckling kan man teckna egna SSL-certifikat när man använder HTTPS. 21

33 3.2.6 Kommunikation mellan server och databas Servern bygger på ASP.NET webb-api som är till viss del en automatiskt genererad server backend. APIet definierar hur servern tar emot mobil-applikationens Ajax-frågor samt besvarar dessa. Frågorna är av datatypen JSON. Servern skickar sedan in all korrekt inkommande data till databasen där datan sparas. Ajax (Asynchronous JavaScript And XML) är ett samlingsnamn för flera olika tekniker som används vid konstruktionen av applikationer för webben, med ökad interaktivitet gentemot tidigare webbapplikationer. Ajax innehåller bland annat APIet XMLHttpRequest, som tillåter JavaScript på en webbsida att anropa webbservern utan att sidan behöver laddas om. JSON (JavaScript Object Notation) är ett språkoberoende textbaserat format som bygger på attribut-värde-par. JSON används ofta i Ajax-tekniker.[4] Kommunikation mellan server och administrationsverktyg På samma sätt som i avsnitt ovan skedde kommunikationen mellan server och administrationsverktyg med protokollet HTTPS. Av samma anledning som i avsnitt bör HTTPS användas i en färdig produkt, så att datan krypteras. 3.3 Designval I detta avsnitt beskrivs några av de skiljevägar författarna stått vid, samt de val som avgjort Tempus Custodes design. Databasens utformning, användargränssnittet för smarttelefonapplikationen samt utnyttjandet av GPS-positioner diskuteras Användargränssnittet Enkelhet har varit ledstjärnan under designen av det grafiska användargränssnittet till Tempus Custode. Vid alla de val som gjorts har enkelhet vägt tungt: Av två lösningar som i övrigt är likvärdiga har alltid den som är enklare valts 16. Enkelhet i detta projekt handlar om två saker: Få knappar för användaren att välja mellan på applikationen Tempus Custode, samt krav på ett minimalt antal knapptryckningar för att tidrapportera användarens dag. Få knappar Att ha få knappar på applikationen medför flera fördelar: Främst innebär få knappar, att varje knapp kan tilldelas en större del av fönsterytan. Det gör knapparna enklare att trycka, och minskar därmed risken för att trycka på fel knapp av 16 Alla likheter med Ockhams Rakkniv är högst medvetna. Det som är gott nog för filosofer duger absolut åt författarna. 22

34 misstag. Etiketterna på knapparna kan också göras läsligare, antingen genom större bokstäver, och/eller genom utrymme för mer förklarande text. Därutöver innebär få knappar att applikationen blir enklare att förstå. Inlärningskurvan blir inte så brant. Detta förutsätter naturligtvis att en och samma knapp inte betyder olika saker vid olika tillfällen 17. Få knapptryck Ju färre knappar användaren behöver trycka för att hantera sin tidrapportering, desto mer attraktiv kommer Tempus Custode att vara som arbetsbesparande verktyg. Mot detta intresse ligger behovet av kontroll och läsbarhet. Tempus Custode kunde ju vara aktivt hela tiden, utan att någon knapp trycks alls, men hur ska den ansamlade datan då sållas och användas? Det finns alltså en gräns för hur få knapptryckningar som är rimligt Relationsdatabasen De data som samlas och skickas till en databas innehåller allting som är väsentligt för att sammanställa en tidrapport (se avsnitt nedan). Flera relationer kan behövas i en färdig version av Tempus Custode, men för att uppvisa full funktionalitet som prototyp räcker det med en enda relation, där användar-id, arbets-id, tidstyp, start- och stopptid, samt eventuella GPS-koordinater för start- och stoppositioner finns redovisade. En serie tupler med samma användar-id och arbets-id kan sammanställas till en tidrapport Administratörsverktyget Ett administratörsverktyg ska ha tillgång till databasens tupler. Dessa tupler ska kunna: Sammanställas till slutlig tidrapport. I en sådan rapport kan den mesta datan i tuplerna döljas. Kvar blir en summering av de tider under vilka användaren arbetat och rest, respektive. Ändras av administratören. Detta är viktigt, eftersom fullständig felfrihet inte kan förutsättas om vare sig systemet eller dess användare. Felaktiga knapptryckningar från användaren kan tas bort och tveksamma tupler kan komma att redigeras av administratören, efter kommunikation med användaren. Ett exempel: Användaren avreser till ett arbete klockan U, och startar Tempus Custode för att kunna debitera sin restid. Användaren fastnar i en bilkö på vägen till ett arbete. Han 17 Detta verkar vara ett problem för utvecklarna till TimeLogger, som ju tar hänsyn till att smartklockan Pebble, med sina fyra knappar, ska kunna hantera en rad komplexa uppgifter (se avsnitt 2.2.2). 23

35 tvingas stå still under en betydande tid (mellan klockan V och W), varför Tempus Custodes bakgrundkontroll beslutar att han arbetar (eftersom han står still). När kön sedan rör sig, kommer arbetspasset skickas som en tupel till databasen, och en ny tupel av typen resa påbörjas. Användaren anländer till arbetsplatsen klockan X. Hans restid borde teoretiskt kunna summerats till tiden mellan klockan U och X. I stället ligger nu i databasen tre tupler: 1. Resa mellan klockan U och V. 2. Arbete mellan klockan V och W 3. Resa mellan klockan W och X. I exemplet ovan framgår det hur viktigt det är att administratörsverktyget i efterhand kan gå in och ändra tupler. Genom att ändra tidstypen på tupel 2 till resa blir debiteringen korrekt. Sammanställningen av en tidrapport är alltså inte löst i och med utvecklandet av Tempus Custode (eftersom administratörsverktyget inte är färdigutvecklat), men de nödvändiga förutsättningarna för tidrapportering finns, i form av databasens tupler Stoppursmodellen Tempus Custode är medvetet designat att likna ett vanligt stoppur. Det finns en central knapp, med vilken man både startar och stoppar tidsintervall som ska mätas. Det finns flera skäl till denna naiva design: Intuitivitet Användaren förväntas förstå hur en stoppklocka hanteras. Text på knapparna kunde i förlängningen ersättas med symboler, vilket förenklar designen ytterligare och ökar den internationella anpassningsbarheten av applikationen. Interaktivitet Användaren har själv kontrollen över vilka tidsintervall som klockas. Detta adresserar i viss mån invändningar användaren kan ha över att bli spårad genom applikationens GPS-mottagare (se avsnitt Användarens integritet). Enkelhet En stoppklocka är ett gott exempel på hur en bestämd funktion uppnås med minimalt antal knappar Bakgrundskontroll av GPS-position Ett tidigt designval var detta: Ska applikationen Tempus Custode ha knappar för att användaren ska kunna specificera huruvida uppmätt tid är av typen arbete eller resa? Eller ska applikationen själv avgöra tidstypen automatiskt? Manuell design Att låta användaren specificera tidstyp medför vissa fördelar: Det ger större interaktivitet och möjlighet att mer exakt föra in de data man önskar via applikationen. 24

36 Dessutom kan anropet av GPS-positioner begränsas till knapptryckningstillfällena, varför eventuella integritetsproblem för användaren är mycket väl avgränsade (användaren är väl medveten och i själva verket delaktig i denna loggning av hans position). Nackdelen är dock att applikationen blir mer komplex. Varje extra knapp och/eller knapptryck under användande minskar applikationens attraktivitet för användaren. Dessutom finns följande scenario: Anta att användaren startar Tempus Custode för att resa till uppdragsgivaren. Väl framme glömmer han stoppa tiduret, som just då räknar restid. Han kastar sig in i arbetet och när det är dags att klocka ut, efter avslutat arbete, kommer Tempus Custode uppfatta det hela som ett långt pass av tidstypen resa! Därmed uppkommer problemet hur denna tid sedan ska kunna delas upp i resa och arbete, och debiteras enligt de olika tidstyperna. Denna situation uppfattas av författarna som vanligt förekommande och var ett centralt problemscenario under designfasen av projektet. Semiautomatisk design Ett alternativ till manuell design är en semiautomatisk process, som efter användarens initiala tryck på klockans startknapp exekverar i bakgrunden fram till dess att stoppknappen trycks ned. Denna bakgrundsexekvering innebär att GPS-data hämtas med jämna mellanrum. Den innebär också att tidstypen löpande avgörs av applikationen. Om tidstypen övergår från arbete till resa (och vice versa) kan applikationen själv avsluta pågående tupel som är av en viss tidstyp sända denna och sedan påbörja en ny tupel av den andra tidstypen. Inget av föregående kräver användarens deltagande; processen är transparent för användaren. Fördelarna med denna design är i första hand enkelhet. En eller flera knappar för att själv specificera tidstyp (arbete/resa) kan elimineras från designen, varför applikationen Tempus Custode blir enklare och snabbare att använda. Problematiken som scenariot ovan beskriver är också löst med denna design, som faktiskt är specifikt utformad för att lösa detta problem. Resultatet blir en applikation där användaren kan starta Tempus Custode vid resans start och sedan stanna Tempus Custode vid ankomst, varpå Tempus Custode startas igen när arbetet inleds (förmodligen tätt inpå resans slut), och så vidare. Men med den i bakgrunden löpande processen kunde användaren förenkla för sig så till den grad, att han startar Tempus Custode när jobb eller resa börjar och stoppar Tempus Custode när uppdraget är slutfört trots att tidsintervallet innehåller olika tidstyper. Nackdelarna med denna design är den minskade interaktiviteten: Mindre interaktivitet är ju eftersträvansvärt för att öka enkelheten. Samtidigt minskar den personliga kontrollen av när användarens GPS-data hämtas och lagras. 25

37 Dessutom kan det tänkas, att batterinivån sjunker signifikant mycket mer vid denna typ av design. Internetanslutning och GPS-tjänster drar kraft ur smarttelefonens batteri, så ju mer sällan tjänsterna används, desto mer sparas batteriet 18. Den manuella designen kräver bara GPS-data vid start och slut av en tupel, och internetanslutning endast när stoppknappen trycks (för att sända tupeln till databas). Den semiautomatiska designen, däremot, kommer med jämna intervall kalla på GPS-data, och varje gång tidstypen verkar ändras kommer en internetanslutning användas. Författarna förutser dock inte, att applikationen Tempus Custode kommer dra ur batteriet på en smarttelefon med sådan takt, att prestandasänkningen kommer att märkas för användaren. Fälttest för att specifikt utröna batteriåtgång planerades dock inte för projektet Tempus Custode Att välja användar-id Att välja användar-id (UID) ska bara behöva göras under två förutsättningar: Första gången applikationen används, eller När applikationen används av en ny användare. Detta implicerar överlämnande av den fysiska smarttelefonen. Därför anses detta fall vara mycket sällan föreliggande. Följaktligen ska en knapp för att sätta UID vara diskret eller inkorporeras med andra, även de sällan använda, val Att välja arbets-id Till skillnad från valet av användar-id, förmodas arbets-id (JID) ofta ställas in, nämligen i början av varje nytt arbete som ska klockas. Det kan därför vara lämpligt att underlätta detta val, till exempel genom att skapa en egen meny för detta. En möjlig framtida funktionalitet för Tempus Custode vore att utnyttja användarens nuvarande position för att ta reda på vilket tillgängligt arbete som ligger närmast användaren, och föreslå detta som nästa arbete. För att detta ska fungera måste databasen innehålla en relation med tillgängliga arbeten, tillsammans med dessa arbetens GPS-koordinater Avgöra skillnad mellan resa och arbete I en semiautomatisk design av Tempus Custode (beskriven i avsnitt ovan), med en i bakgrunden exekverande process som granskar den tidstyp som för tillfället uppmäts av 18 Att GPS och även internetuppkoppling via t.ex. Wi-Fi märkbart påverkar batteriet i en smarttelefon kan man till exempel läsa i en hjälpsam artikel[6] om hur man håller sin smarttelefon laddad så länge som möjligt. Att andra telefoner än Android skulle fungera annorlunda vad gäller batteriförbrukning verkar otroligt, varför påståenden från denna länk extrapoleras till att gälla alla smarttelefoner. 26

38 stoppklockan, hur ska applikationen själv diskriminera mellan tidstyperna? Hur ska Tempus Custode avgöra huruvida ett tidsintervall är av tidstypen resa eller arbete? Svaret ligger i GPS-funktionaliteten. Genom att jämföra nuvarande position med föregående kan applikationen avgöra både användarens position, förflyttning och medelhastighet under föregående tidsintervall. Grundinställning För enkelhets skull antas alla tidsintervall vara av typen arbete om inget annat gäller. Detta val är helt godtyckligt, men kan vara av hjälp i de fall då det råder osäkerhet om tidstypen. Alltså: kan inte tidstypen fastställas på annat sätt, förutsätts den vara av typen arbete. Resa Användaren kan ses som resande under någon av följande förutsättningar: Användaren befinner sig på minst ett visst avstånd från en känd position (arbetsplats) 19. Eftersom han inte befinner sig på platsen för uppdraget, måste han vara på resa antingen till eller från sagda plats. Användaren överskrider en viss medelhastighet under det senaste tidsintervallet. Antagandet här är att arbetsplatserna inte är så stora att de erbjuder interna transportmedel. Om de ändå gör det, är det ju inte orimligt att kalla denna tid för restid. Hur långt användaren förflyttat sig under ett tidsintervall kan beräknas ur GPS-datan för föregående och nuvarande position (se bilaga A). Här ger GPS-datans precision också ett mått av osäkerhet. Sträckan som användaren förflyttat sig ligger omkring ett värde, med avvikelser (lika stora) uppåt och nedåt från detta värde. Figur 3.2 åskådliggör tre olika fall: I det översta fallet (A) ligger både minsta och största värde (Amin och Amax, respektive) under gränsvärdet (limit). Det är därför entydigt så, att användaren förflyttat sig mindre än gränsvärdet. Han ska alltså anses som arbetande. I det understa fallet (C) ligger både minsta och största värde över gränsvärdet, varför användaren entydigt kan sägas vara resande. 19 Om arbetsplatsen har kända GPS-koordinater blir urskillningen mellan resa och arbete så mycket enklare, se avsnitt 5.2, andra punkten. I annat fall används i allmänhet tupelns startposition för jämförelser: Har användaren överskridit gränsvärdet i sin förflyttning från startpositionen, anses resa förekomma, snarare än arbete. 27

39 Figur 3.2 Osäkerheter i position jämfört med gränsvärde (limit) I mittenfallet (B) ligger minsta värdet under gränsvärdet, medan största värdet ligger över gränsvärdet. Kan man avgöra huruvida användaren i detta fall reser eller arbetar? Flera lösningar är möjliga. Författarna har valt att låta minsta värdet avgöra; om det minsta värdet ligger under gränsvärdet anses användaren arbeta, annars reser användaren. Detta val harmonierar med idén om att grundinställningen ska vara arbete (avsnitt ovan): Råder någon tvekan om tidstyp, ska tidstypen sättas till värdet arbete. 3.4 Slutlig design I detta avsnitt beskrivs användargränssnittet (GUI) för smarttelefonapplikationen, därefter logiken bakom densamma. Sedan beskrivs server, databas och administratörsverktyg i korthet GUI för Tempus Custode Applikationen Tempus Custode består av tre vyer (fönster): huvudvyn, konfigureringsvyn och nyarbetsvyn, vilka beskrivs nedan. Huvudvyn Huvudvyn är det fönster som i allmänhet visas i applikationen. Fönstret innehåller följande komponenter när applikationen körs för första gången (se Figur 3.3): 28

40 Figur 3.3 GUI Huvudvyn före start 1. Stoppklocka, tillsammans med ackumulerad arbetstid (W) och restid (T). 2. Startknapp. Denna knapp kan inte tryckas ned förrän arbets-id och användar-id är ifyllda av användaren, eftersom dessa värden är nödvändiga för funktionaliteten. 3. Ändra arbets-id. Man kan förmoda att användaren startar nya arbeten relativt ofta. Därför får denna aktivitet en egen meny och en egen knapp i huvudmenyn för applikationen Tempus Custode. Knappen är placerad för att vara lätt åtkomlig. Tryck denna knapp för att gå till nyarbetsvyn. 4. Konfigurering. Tryck på denna knapp för att gå till konfigureringsvyn och ändra bl.a. användar-id. Denna knapp har diskret placerats längst ned, eftersom den inte förväntas användas ofta När en timer startas (det vill säga när startknappen tryckts) förändras huvudvyn enligt Figur 3.4: 29

41 Figur 3.4 GUI Huvudvyn under tidsintervall 1. Stoppklockan ackumulerar nu tid. När stoppknappen trycks ned, eller om logiken i bakgrunden dikterar att en tupel ska skickas, kommer ackumulerad tid adderas till tiderna inom parentes beroende av tidstyp (W står för arbete, T för resa), varpå klockan nollställs för nästa intervall. 2. Trycks stoppknappen ned skickas lagrad data som en tupel och huvudvyn återgår till läget beskrivet i Figur 3.3 (förutom att klockorna W och/eller T inkrementerats). 3. Under pågående tidsintervall kan varken arbets-id eller konfigurationsinställningar ändras, varför knapparna inte går att trycka. Konfigureringsvyn I projektet Tempus Custode har val av användar-id (UID) grupperats i en meny tillsammans med inställningar för gränsvärden för positionsförändring (se avsnitt Avgöra skillnad mellan resa och arbete), tidsintervall för bakgrundsprocessen 30

42 och vissa andra värden, som för användaren kan tänkas vara intressant att ställa in manuellt 20. Vyns knappar beskrivs i Figur 3.5 nedan: Figur 3.5 GUI Konfigureringsvyn 1. Tidsintervallet (i millisekunder) mellan de automatiska bakgrundsuppdateringarna. I exemplet givet av figuren kommer uppdatering ske var trettionde sekund. 2. Avståndsgränsvärde (i meter). Om användaren förflyttar sig längre än denna sträcka (medräknat osäkerhet enligt avsnitt ovan) räknas han som resande, i annat fall räknas han som arbetande. 3. Användar-ID, vilket bör vara unikt för varje användare. Denna post måste fyllas i för att applikationen ska kunna användas. 4. Server-URL. Här kan adressen till servern skrivas in manuellt. Om inget värde skrivits in används ett förutbestämt värde. 20 I en framtida version kommer konfigurationsvalen vara annorlunda: vissa värden kan sättas i konfigureringsvyn av användaren, medan andra inte ska kunna ändras av användaren, utan i stället placeras i en konfigurationsfil, som endast arbetsgivaren kan manipulera, se avsnitt 5.2, femte punkten. 31

43 5. Konfirmation av val i vyn. Vid tryck på denna knapp återgår användaren till huvudvyn, så länge ett användar-id finns. Annars händer ingenting, i väntan på ett användar-id ska ifyllas. Nyarbetsvyn Varje gång ett nytt arbete ska påbörjas, måste ett ID för detta arbete fyllas i av användaren. Nyarbetsvyn visas i Figur 3.6 och innehåller följande komponenter: Figur 3.6 GUI Nyarbetsvyn 1. Fält för att skriva in arbets-id. Detta fält kan i en framtida applikation ersättas av en rullist valbara arbeten, varpå arbetet att fylla i ett ID förenklas (se avsnitt 5.2). 2. Konfirmation av val i vyn. Vid tryck på denna knapp återgår användaren till huvudvyn, så länge ett arbets-id finns. Annars händer ingenting, i väntan på ett arbets-id ska ifyllas Logiken bakom GUI för applikationen När användaren fyllt i all information som behövs för att starta applikationen (specifikt användar-id och arbets-id) och trycker på startknappen, så kommer applikationen hämta en 32