Sammanfattning 1 (56)

Transkript

1 Sammanfattning GoldPen Computing AB utvecklar bl a programvara för inventering och projektering. Ett program som heter Sting 2000 har utvecklats för inventering av bl a telestolpar. Sting 2000 drivs med data som hämtas från en systemdatabas. Systemdatabasen innehåller uppgifter om inventeringsobjekten och hur de ska presenteras i det grafiska användargränssnittet. Datorerna som Sting 2000 körs på är ruggade handhållna PC-datorer med Windows 98 eller Windows 2000 som operativsystem. Eftersom dessa är dyra undersöks billigare alternativ, t ex handdatorer med Pocket PC eller Windows CE som operativsystem. Detta exemansarbete syftar till att undersöka möjligheterna att implementera en inventeringsapplikation på handdatorer med Pocket PC. Inventeringsapplikationen skall vara datadriven. Systemdatabasen lagrar information om inventeringsobjekt och hur de presenteras ska vara så generell som möjligt. Rapporten beskriver arbetet med att ta fram en generell systemdatabas till handdatorer och hur den ska driva användargränssnittet. Rapporten beskriver också den studie av användargränssnitt till små skärmar, och framförallt handdatorer, som genomförts. Rapporten presenterar också arbetet med att ta fram en prototyp för användargränssnittet till en inventeringsapplikation. Rapporten avslutas med att redovisa det som kan utvecklas vidare och förbättras. För att testa den systemdatabas som designades gjordes ett antal testimplementationer av systemdatabasen. Vid testerna undersöktes prestanda och lagringsstorlek på systemdatabasen. Den användargränssnittsstudie som genomfördes resulterade i en HIFIprototyp för en Pocket PC-version av Sting Slutsatsen av examensarbetet är att det går bra att implementera en inventeringsapplikation som använder en förhållandevis stor systemdatabas. Prototypen visar att ett användbart grafiskt användargränssnittet går att utveckla till en inventeringsapplikation för Pocket PC. 1 (56)

2 Innehållsförteckning 1. Inledning Bakgrund och syfte Metod Avgränsningar Kapitelbeskrivningar Ordförklaringar Problemformulering Uppgiften Sting Systemdatabasen Tabellen FÖREMÅLSMALL Tabellen VARIABEL Övriga tabeller Begränsningar Önskemål Tolkningsmodellen Begränsningar Användargränssnittet Begränsningar och brister Systemdatabasen Dataabstraktion Fysisk Logisk Vy Datamodell Object-Based Logical Models Record-Based Logical Models Vald datamodell Entity-Relationship-diagram Objektmodellering Exempel på objektmodellering Egenskapsmodellering Exempel på egenskapsmodellering Användargränssnittsmodellering Exempel på användargränssnittsmodellering Specialisering av systemdatabasen Översättning till relationsmodell Normalformer Översättning från ER-diagram till relationsmodell Prestandatester av systemdatabasimplementationer SQL Server 2000 Windows CE Tabeller i minnet Slutsats Systemmodell och tolkning av systemdatabasen Möjlig systemmodell Tolkning av systemdatabas Användargränssnitt för handdatorer (56)

3 4.1. Teorisammanfattning Skärm och inmatning Gruppering och placering Ikoner Text Övrigt Användaren och miljön LOFI-prototyp för användargränssnitt Scenario Scenario HIFI-prototyp för användargränssnitt Resultat Systemdatabasen Användargränssnittet Rapporten Möjliga framtida förbättringar Systemdatabasen Användargränssnittet Övrigt Referenser Böcker Rapporter Internet (56)

4 1. Inledning Denna rapport är resultatet av ett examensarbete utfört på GoldPen Computing AB hösten Handledare på GoldPen Computing AB är Ulf Bergqvist. På IDA är Daniel Karlsson handledare och examinator är Petru Eles. Ulf Bergqvist arbetar på GoldPen Computing AB och är en erfaren utvecklare av programvara för handdatorer. Detta första kapitel syftar till att ge en kort introduktion till examensarbetet. En kortare beskrivning av bakgrunden och syftet med examensarbetet, den metod som kommer tillämpas samt de avgränsningar som finns. Sist i kapitlet finns en beskrivning av upplägget på dokumentet ordförklaringar Bakgrund och syfte GoldPen Computing AB utvecklar bl a programvara för inventering och projektering. Ett program som heter Sting 2000 har utvecklats för inventering av telestolpar m m ute i fält. Inventeringen utförs på stationsområden där de olika inventeringsobjekten kallas mätpunkter och oftast består av telestolpar. En telestolpsinventering är egentligen en besiktning av telestolpar. Inventeringen tillser att röta och andra fel som kan förekomma på en telestolpe eller de ledningar som den håller uppe inte ska orsaka driftstörningar eller utgöra en fara för inventeraren. Dessa inventeringar utförs med jämna mellanrum på stationsområden. Ett stationsområde är det nät som är kopplat till en speciell telestation. Ett stationsområde kan innehålla uppemot 2000 telestolpar. Datorerna som Sting 2000 körs på är ruggade handhållna PC-datorer med Windows 98 eller Windows 2000 som operativsystem. Eftersom dessa är dyra undersöks nu billigare alternativ, t ex handdatorer med Pocket PC eller Windows CE som operativsystem. Vid utveckling av programvara till handdatorer kan ett flertal olika språk användas. GoldPen Computing AB utryckte ett intresse för att undersöka.net plattformen. Därför har all implementation i examensarbetet har utförts i C# och.net Compact Framework. Den här rapporten syftar till att: 4 (56)

5 Ge en bakgrund till problemställningen. Visa hur uppgiften som beskrivs i kapitel 2 Problemformulering är löst. Ge läsaren som inte är insatt i området möjlighet att förstå hur och varför jag valt de specifika lösningarna Metod Den metod som har valts för att ta fram en prototyp till det grafiska användargränssnittet i detta projekt är prototyping [3]. Det är en form av utveckling som lämpar sig väl då man vill utveckla snabbt och kunna få synpunkter från användarna. Prototyping lämpar sig väl då man snabbt vill implementera testprogram där koden sedan återanvänds vid ett senare steg i utvecklingen. Prototyping lämpar sig också väldigt bra då man använder ett högnivåspråk. Den metod som använts till de databasrelaterade implementationerna är en inkrementell metod [3]. Det innebär att ett utvecklingsschema har gjorts upp i förväg och sedan har olika steg implementerats och mellan dessa steg så har en dokumentering av det tidigare gjorda steget utförts. De senare delarna har sedan fått anpassa sig efter de tidigare tagna besluten. Databasmodellen har tagits fram enligt ER-modellen och relationsmodellen [1]. ER-modellering valdes då problemet enkelt kan formuleras i termer av objekt och relationer Avgränsningar Rapporten syftar till att redogöra för de metoder som använts och de resultat som uppnåtts under examensarbetet. Rapporten är inte tänkt att vara en lärobok i något av de ämnen som behandlas utan endast belysa de problem och lösningar som uppstått. Läsaren av rapporten bör ha allmänna kunskaper om programmering och databaser Kapitelbeskrivningar Nedan följer en kort beskrivning av innehållet i varje kapitel. 1. Innehåller en beskrivning av bakgrund och syfte med examensarbetet samt ger en kortare beskrivning av den metod som använts för att lösa examensarbetet. 2. Innehåller en formulering av de problem som skall lösas inom examensarbetet. 3. Innehåller arbetet med systemdatabasen. Teoribakgrund och arbete tillsammans med lösningar. 5 (56)

6 4. Innehåller arbetet kring användargränssnittet; teori, arbete och lösning. 5. Innehåller slutsatser dragna under examensarbetet. 6. Innehåller de tänkbara förbättringar som man kan göra på examensarbetet Ordförklaringar Ord ActiveX b B COM Determinant DOM ER GUI IDA Handdator HTML K Kandidatnyckel Förklaring En vagt definierad mängd teknologier framtagen av Microsoft. ActiveX härstammar från OLE- och COM-objekt. Förkortning för bit. Förkortning för byte. Component Object Model, ett ramverk för binära mjukvarukomponenter. A determinerar B, d v s A bestämmer B. A är i detta fall determinanten. Om A är postnumret du tillhör. Då vet man också vilken stad, B, du bor i. Med andra ord determinerar postnumret A staden B. Document Object Model, specifikation för hur objekt, t ex text, bilder och länkar, i HTML eller XML ska representeras. Entity-Relationship, en datamodell för databaser. Modellen beskriver objekt och deras samband. Graphical User Interface, en engelsk förkortning som betyder grafiskt användargränssnitt. Institutionen för datavetenskap, en del av Linköpings tekniska högskola. Även kallad PDA, Personal Digital Assistant. En dator stor som en hand. Inmatning sker ofta via en tryckkänslig skärm med ett pennliknande föremål. Hypertext Markup Language, det språk som används för att beskriva innehåll och utseende på hemsidor på Internet. Förkortning för binärt kilo, IEEE förslag för att beskriva 2 10 med K till skillnad från k som betyder Ett attribut, eller en kombination av attribut, 6 (56)

7 OLE Pocket PC Punkter Ruggad SVGA Windows CE.NET XML som alltid har ett unikt värde för varje rad i en relationstabell i en databas. Inga redundanta attribut får ingå i kandidatnyckeln. Object Linking and Embedding, en standard för sammansatta dokument. Ett operativsystem för handdatorer och mobiltelefoner. Ett mått för textstorleken i ett dokument. Storleken som den fysiska texten erhåller beror på den upplösning som skärmen eller utskriften på papper använder. Extra tålig för att klara av yttre påverkan i form av exempelvis regn, vind, starkt solljus och annan fysisk påverkan. Super Video Graphics Array, en videostandard för persondatorer. Maximal upplösning är 800 horisontella och 600 vertikala pixlar. Operativsystem från Microsoft för mobila smarta enheter. extensible Markup Language, en specifikation utvecklad av W3C. XML tillåter utvecklare att designa specialiserade taggar för att definiera data som sedan kan tolkas av olika applikationer och organisationer. 7 (56)

8 2. Problemformulering I detta kapitel presenteras först de frågeställningar som examensarbetet syftar till att besvara. Sedan ges en överblick av det program,och dess ingående delar, som idag finns till stationära datorer. De olika ingående delarna beskrivs för att ge den bakgrundsinformation som behövs för att lösa de frågeställningar som presenteras Uppgiften Examensarbetet syftar till att undersöka möjligherna att utveckla en inventeringsapplikation för Pocket PC-plattformen samt att utföra någon slags testimplementation. Mera specifierat syftar examensarbetet till att studera följande frågeställningar: Ge ett förslag på hur databasmodellen kan generalisera för att på ett kraftfullare sätt kunna styra det grafiska användargränssnittet. Samt anpassa databasen för en handdator. Testimplementationer skall även uföras för att undersöka förslagets rimlighet och användbarhet. Studera hur en systemmodell för inventeringsapplikationen skulle kunna utformas. Producera en prototyp för ett grafiskt användargränssnitt för en telestolpsinventeringsapplikation till en handdator Sting 2000 Det befintliga systemet för inventering av telestolpar, Sting 2000, byggs upp av tre delar; ett användargränssnitt, en tolkningsmodell och en systemdatabas. Systemdatabasen innehåller egenskaperna för de olika inventeringsobjekten och styrinformation för hur dessa egenskaper ska presenteras och matas in via användargränssnittet. Tolkningsmodellen styr sedan hur informationen ska tolkas och vad som är giltigt m m. Designvalet med en systemdatabas, istället för att hårdkoda all information om inventeringsobjekten i tolkningsmodellen, medför flera fördelar. Det innebär bl a att nya inventeringsobjekt kan läggas till i systemet utan att applikationen behöver kompileras om. Det innebär också att med en väl genomtänkt systemdatabas och en tillräckligt generell datamodell så kan nya inventeringsapplikationer byggas enbart genom att ny information lagras i systemdatabasen. En nackdel som en systemdatabas medför är att prestanda förloras då data måste hämtas och tolkas av 8 (56)

9 tolkningsmodellen. I Figur 1 visas en schematisk bild över Sting 2000 och hur de olika delarna interagerar med varandra. GUI Tolkningsmodell Systemdatabas Figur 1. Schematisk bild av systemmodellen för Sting Systemdatabasen I detta avsnitt kommer systemdatabasen som används i Sting 2000 och dess begränsningar att beskrivas. Begränsningarna hos systemdatabasen tillsammans med de önskemål som finns ligger sedan till grund för den nya systemdatabasen. Systemdatabasen lagrar metadata för inventeringsobjekt. Den används således inte för att lagra insamlad data. Systemdatabasen är idag uppbyggd kring två centrala tabeller; FÖREMÅLSMALL och VARIABEL. Nedan görs ett försök att förklara innehållet i dessa och hur de används i den befintliga systemdatabasen. Alla kolumner i tabellerna i systemdatabasen kommer inte att förklaras utan endast designen i större drag. I nedanstående text är föremål detsamma som ett inventeringsobjekt, ett föremål kan också representera ett fel eller en åtgärd Tabellen FÖREMÅLSMALL Tabellen innehåller information om alla typer av inventeringsföremål, såsom namn vid utskrift, ikon och hjälptexter m m. Tabellen kan till 9 (56)

10 viss del styra hur föremålet ska presenteras i användargränssnittet genom att välja mellan ett par fördefinerade grafiska mallar Tabellen VARIABEL Tabellen innehåller de variabler som förekommer bland föremålen. Det finns därför lagrat information om vilket föremål som äger variabeln, dess typ samt information om hur variabeln ska presenteras i användargränssnittet. I tabellen lagras även uttryck i ett interpreterande språk som kallas Fido. Fido kan t ex användas för att styra validering av inmatning eller för att styra andra variabler inom föremålet eller andra föremål. Andra saker som lagras i tabellen är variabelns förställda värde, om något existerar. Beroenden mellan variabler lagras även i tabellen men i en ganska begränsad form Övriga tabeller Tabellen TEXTER innehåller de flesta av de textsträngar som skrivs ut i användargränssnittet. Flera olika alternativa texter lagras i tabellen för samma textreferens, t ex kan en förkortning lagras. Vilken textreferens som skall användas bestäms av tolkningsmodellen. Båda tabellen VARIABLER och FÖREMÅLSMALL refererar till TEXTER. Tabellen LISTOR används för att lagra de alternativ som ska visas i t ex en drop down -meny. Tabellen refereras till av tabellen VARIABEL. Diverse andra tabeller finns i systemdatabasen som av historiska skäl mer eller mindre har direkta samband med varandra. Deras samverkan mellan varandra, eller avsaknad av densamma, kommer inte att tas upp i denna rapport Begränsningar Möjlighet att styra det grafiska gränssnittet finns, men styrningen är förhållandevis rudimentär och behöver utökas och generaliseras för att framtida tillägg och förändringar skall gå att införa. En del av den funktionalitet som systemdatabasen erbjuder används inte i Sting 2000 utan är till viss del flyttad till tolkningsmodellen och användargränssnittet. Detta beror till viss del på historiska skäl och att viss funktionalitet inte går att modellera i den nuvarande systemdatabasen Önskemål Många av begränsningarna som finns i den nuvarande systemdatabasen vill man finna lösningar till men man önskar också en mera generell databas så att utvecklandet av andra program för 10 (56)

11 inventering och besiktning blir enklare. Större möjlighet till styrning av det grafiska gränsnittet önskas Tolkningsmodellen I detta avsnitt kommer tolkningsmodellen som används i Sting 2000 att beskrivas kortfattat. De begränsningar som en handdator har ställer vissa krav på tolkningsmodellen i form av minnesförbrukning och beräkningskraft. Tolkningsmodellen är den största delen av Sting I denna del ingår själva datamodellen som består av stationer, mätpunkter, inventeringsobjekt, åtgärder o s v. Tolkningsmodellen tar även hand om systemdatabashanteringen. Tolkningsmodellen innehåller även en interpretator för Fido. Fido används för att utföra automatiska beräkningar på värden i systemdatabasen och inmatade inventeringsvärden. Fido kan också används för att kontrollera inmatade inventerinsgsvärden. Detta språk är ganska krångligt att förstå och framförallt är det väldigt omfattande. Insamlade inventeringsvärden sparas i en s k stationsfil. I stationsfilen sparas information om stationsområdet tillsammans med inventeringsvärden från mätpunkterna, inventeringsobjekten och åtgärder m m. Stationsfilerna är XML-filer som läses in via en DOMparser. Skrivning till XML-fil sker dock genom enkel uppbyggnad av strängar som sedan skrivs till fil Begränsningar Att implementera en interpretator för Fido på en handdator är fullt möjligt, men en interpretering av ett uttryck kommer troligtsvis att kräva en del beräkningskraft. Det kan ställa till problem då Fidouttrycken ofta utförs då användaren använder det grafiska gränssnittet och det kan leda till att viss fördröjning uppstår då vissa operationer utförs. En fördröjning kan ofta anses som irriterande och fel kan uppstå genom att användaren trycker på andra knappar medan systemet är upptaget. Precis som Fido kräver XML en interpretator. Denna interpretering är inte lika känslig för en beräkningssvag plattform eftersom interpretering av XML utförs vid sparande och hämtande av stationsdata. Vid sparande och hämtande blir inte en användare lika förvånad om det skulle ta en liten stund utan har antagligen en större 11 (56)

12 förståelse för ett eventuellt dröjsmål. Det som dock kan vara ett problem är att en XML-fil med tusentals mätpunkter är ganska stor Användargränssnittet I detta avsnitt kommer användargränssnittet som används i Sting 2000 och dess begränsningar att beskrivas. Begränsningarna och bristerna hos användargränssnittet tillsammans med önskemålet om att applikationen skall gå att använda på en handdator ligger sedan till grund för det nya användargränssnittet. Figur 2. Användargränssnittet för Sting 2000 Sting 2000 delar upp skärmytan i 3 områden som man kallar vyer, dessa används för att interagera med användaren. De olika vyerna innehåller; karta, mätpunkter och egenskaper för inventeringsobjekten eller åtgärderna. 12 (56)

13 Figur 3. Kartvyn i Sting 2000 Kartan är implementerad som en ActiveX-komponent och styrs med hjälp av snabbknappar i övre delen av kartvyn, knapparna är dock inte en del av ActiveX-komponenten. Kartan visar det aktuella stationsområdet och de mätpunkter som är under inventering. Mätpunkter läggs till genom att man väljer ett verktyg för att sätta ut mätpunkter från knappraden och sedan klickar på den geografiska punkt på kartan där mätpunkten ligger. Kartkomponenten har fördelen att den förhållandevis enkelt kan modifieras för att användas i en handdator. 13 (56)

14 Figur 4. Mätpunktsvyn i Sting 2000 Den andra vyn innehåller de mätpunkter som är markerade på kartan. De, på kartan, markerade mätpunkterna visas i en lista. Mätpunkterna har sedan olika inventeringsobjekt eller åtgärder kopplade till sig. Man kan markera en mätpunkt och lägga till ett nytt inventeringsobjekt eller åtgärd för mätpunkten. Figur 5. Egenskapsvyn i Sting 2000 Egenskaperna för ett inventeringsobjekt visas i en separat vy där man kan se statisk data och fylla i de uppgifter som behövs för det aktuella inventeringsobjektet. Denna vy byter innehåll beroende på vilket inventeringsobjekt eller vilken åtgärd som är markerad. Då ett inventeringsobjekt är i så dåligt skick att någon viktig åtgärd måste utföras varningsmarkeras ett objekt i användargränssnittet med en liten ikon. Denna ikon används dels i kartbilden bredvid mätpunkten och i mätpunktslistan. Förutom att det markeras att objektet har ett fel så låser programmet upp viss funktionalitet i programmet tills användaren matat in en åtgärd för felet. Detta kan vara lite svårt att upptäcka ibland och en tydligare markering över att en åtgärd måste läggas till vore önskvärt Begränsningar och brister Den största begränsningen med det nuvarande gränssnittet är att det är anpassat efter en skärm med SVGA-upplösning eller högre. Eftersom det tänkta systemet är en handdator, som i dagsläget har upplösningen 240 gånger 320 pixlar, så måste användargränssnittet designas om. En mindre informell utvärdering av det nuvarande användargränssnittet har genomförts. Denna utvärdering syftade till att gå igenom användargränssnittet för att se vilka typer av gränssnittkomponenter och metaforer som använts. Vid utvärderingen framkom följande brister eller funderingar: 14 (56)

15 Placeringen av en del menyalternativ behöver undersökas. De avgränsare som skiljer mätpunkerna och inventeringsobjekten från varandra i mätpunktsvyn är något otydliga. Då en penndator används skymmer en högerhänt person de inmatningsfält som fylls i. 15 (56)

16 3. Systemdatabasen I detta kapitel ges en kortfattad beskrivning av de olika typer av datamodeller som beaktades vid designen av datamodell till systemdatabasen. Innan designen av systemdatabasen presenteras ges en kortfattad introduktion till ER-diagram. Därefter beskrivs vilken funktionalitet som infördes i systemdatabasen och hur det till slut ledde fram till designens slutgiltiga utseende. Testimplemetationerna beskrivs på slutet tillsammans med resultat och slutsatsen Dataabstraktion Det finns tre grundläggande nivåer av dataabstraktion som kommer att användas i beskrivningen av de olika datamodellerna. I de följande styckena kommer de olika modellerna att presenteras Fysisk Den fysiska nivån beskriver hur data faktiskt lagras på hårddisken. Komplexa datastrukturer beskriver i detalj hur detta sker Logisk Den logiska nivån beskriver vilken typ av data som lagras i databasen och vilka relationer som finns. Hela databasen beskrivs som ett litet antal enkla strukturer. Man bryr sig på denna nivå inte om hur det fysiskt lagras utan man koncentrerar sig på den information som ska lagras i databasen Vy Den högsta abstraktionsnivån beskriver endast delar av databasen. Trots den enkla struktureren i den logiska nivån finns det kvar lite komplexa saker p g a databasens storlek. Många användare har inget behov av att komma åt hela databasen utan behöver endast tillgång till en mindre del. Därför abstraheras databasen ytterliggare en nivå för att ge tillgång till en mindre del av databasen. Flera olika vyer kan erhållas för samma databas Datamodell Datamodellen kan ses som en samling konceptuella verktyg för att beskriva; data, relationer mellan data, datasemantik och konsistenskrav. Datamodellen kan ses som en avbildning av den miniatyrvärld som man försöker modellera. De olika datamodeller som finns föreslagna kan kategoriseras i två olika grupper. Object-Based Logical Models 16 (56)

17 Record-Based Logical Models I avsnitten nedan kommer de olika kategorierna presenteras kortfattat Object-Based Logical Models Den objektbaserade modellen används för att beskriva data på logisk och vynivå. Modellen karaktäriseras av att den är flexibel och tillåter att restriktioner explicit specifieras. De mest kända och använda är: Entity-Relationship Object-Oriented Entity-Relationship-modellen, eller ER-modellen, kan beskrivas som en avbildning av den riktiga världen som består av objekt och relationer, benämns som entiteter och relationer. En entitet är ett ting eller sak och kan t ex vara en kund eller ett bankkonto. En relation mellan två ting kan vara t ex en insättning av pengar på ett bankkonto av en kund. Liksom ER-modellen är den objektorienterade modellen baserad på objekt. Ett objekt lagrar data i instansierade variabler inuti objektet. Ett objekt kan även innehålla programkod, för opertationer som skall kunna utföras på objekten. Dessa operationer kallas i objektorienterade sammanhang för metoder. Objekt som innehåller samma typ av data och metoder grupperas ihop i något som kallas klasser. Dessa klasser kan jämföras med vanliga programmeringsspråkens abstrakta datatyper. Det enda sättet man kan få tillgång till data i objekten är genom att anropa en metod i objektet Record-Based Logical Models Denna form av datamodell är strukturerad i poster av fast längd av olika typ. Varje post definierar ett fast antal fält eller attribut, och varje fält är oftast av fast längd. Detta medför en fysiskt enkel implementation av databasen. De vanligaste formerna av recordbased logical model är relationsmodellen. Relationsmodellen använder tabeller för att representera både data och relationer mellan data. Varje tabell har ett flertal kolumner och varje kolumn har ett unikt namn. Det som relaterar en tabell till en annan är det värde som en post innehåller. 17 (56)

18 Vald datamodell De datamodeller som kommer att avändas i detta examensarbete är ER-modellen och relationsmodellen. Modellerna erbjuder de verktyg som behövs för att beskriva miniatyrvärlden. Erfarenhet från ERmodellering och relationsmodellering finns sedan tidigare så ingen ny kunskap behövs. Systemdatabasen kommer först modelleras i ERmodellen och sedan översättas till relationsmodellen för att på ett enkelt och smidigt sätt kunna implementeras Entity-Relationship-diagram Den logiska nivån eller strukturen hos en databas kan beskrivas med ett ER-diagram [1]. Enkelheten och tydligheten i diagrammet har gjort det till ett mycket använt verktyg vid databasmodellering. ER-diagram består av ett antal grundstenar: Rektanglar, representerar entiteter. Elipser, representerar attribut. Diamanter, representerar relationer. Linjer, binder samman entiteter med relationer. Dubbla elipser, representerar flervärda attribut. Streckade elipser, representerar härledda attribut Dubbla linjer, indikerar beroende för en entitet till en relation. Attribut med understruket namn visar att det är en primärnyckel för entiteten. För att visa vilken typ av relation det är mellan de olika entiteterna skrivs en siffra, N eller M ut bredvid linjen till relationen. Relationen en-till-många skrivs 1 N, många-till-en skrivs N 1, och många-till-många skrivs N - M. Andra relationer kan skrivas genom att siffran 1 byts ut mot godtycklig siffra. För exempel på ER-diagram och dess symboler se Figur 6 i avsnitt Objektmodellering Systemdatabasen är tänkt att beskriva den del av världen som man vill inventera. Det är då viktigt att erbjuda en systemdatabasmodell som tillåter att objekt modelleras och att relationer dem emellan tillåts. I detta avsnitt kommer objektmodellering, egenskapsmodellering samt användargränssnittsmodellering beskrivas samt vad i den nya och den gamla systemdatabasen som skiljer dem åt. Avsnittet kommer att avslutas med ett exempel för att visa hur det praktiskt är tänkt att modelleras i systemdatabasen. 18 (56)

19 En generalisering av systemdatabasen för att i framtiden kunna utveckla andra inventeringsapplikationer med samma komponenter önskades. Detta ledde till att en mindre studie i form av brainstorming utfördes där ett antal tänkbara inventeringsapplikationer sammanställdes och kraven de kunde tänkas ställa på en systemdatabas. Nedan presenteras de viktiga punkter som ledde fram till en mer generell databas. I den ursprungliga systemdatabasen kan objekt inte bestå av andra objekt. För att i framtiden kunna beskriva komplexare strukturer av objekt skapades en faderskapsrelation eller en hierarkisk relation. Relationen är en en-till-många-relation vilket betyder att ett objekt kan ha en förälder och en förälder kan ha flera eller inga barn. Denna relation kan även användas för att införa grupper av objekt, något som i den ursprungliga databasen löstes genom speciella tabeller. Förutom att kunna gruppera ihop saker genom en hierarkisk struktur behövdes något för att beskriva samband mellan olika typer av objekt. Man vill t ex kunna definiera vilka fel ett visst objekt kan ha eller vilka objekt som ett visst fel kan förekomma på. Den relation som behöver läggas till är således en många-till-många-relation. Förutom att visa på olika relationer mellan olika objekt så kan man vilja namnge objektet och därför behövs en relation till en textsträng. Textsträngar separeras från objektet för att det ska vara enkelt att hålla reda på all text ifall man t ex vill byta språk i programmet eller om man behöver döpa om saker. Ett par olika textsträngar kan vara bra att kunna lagra ifall man t ex vill ha en längre förklaring eller om en förkortning behövs p g a utrymmesbrist i det grafiska användargränssnittet. En annan skillnad jämfört med den gamla systemdatabasen är att en kontrollstruktur lagts till, objectcontrol. Denna kontrollstruktur är tänkt att kunna användas då man t ex vill kontrollera att en viss relation upprätthålls. Till exempel kanske man vill kunna kontrollera i vilken ordning objekt skapas. Det kan exempelvis vara att ett felobjekt endast får konstrueras om ett visst åtgärdsobjekt redan har skapats. Förutom att endast ha fördefinierade funktioner som kan anropas av objectcontrol så lämnas utrymme för att lagra ett Fido-uttryck. I den gamla systemdatabasen lagrades vilken typ av mall som skulle användas för att presentera objektet. Systemet med mallar har i den nya systemdatabasdesignen flyttats ut från objektet och generaliserats. 19 (56)

20 Presentation och inmatning av objektets egenskaper presenteras i avsnitt 3.5 Egenskapsmodellering. Nedan visas den ER-modell som är resultatet av detta avsnitt. Figur 6. ER-diagram efter objektmodelleringssteget Exempel på objektmodellering Vi föreställer oss en väldigt enkel inventeringsapplikation där man vill samla in information om vilken typ av hjul som folk har på sina bilar. Ett hjul består av en fälg och ett däck. Däcken kan vara av typen sommardäck eller vinterdäck. Det kan också finnas ett antal olika fälgar, fälg1 respektive fälg2. En hierarkisk struktur kan lätt identifieras med hjul som består av fälg och däck. Ett däck kan i sin tur finnas i en massa olika modeller. På motsvarande sätt kan det resoneras kring fälgar. Denna struktur använder sig endast av faderskapsrelationen. Ovanstående resonemang skulle kunna resultera i en struktur som ser ut på föjande sätt: 20 (56)

21 Figur 7. Objekthierarki över ett hjul och dess beståndsdelar. Högst upp i Figur 7 ligger objektet hjul som sedan har två grupper av objekt under sig. Den ena gruppen består av alla olika fälgar som finns. Den andra gruppen består i sin tur av två nya grupper av objekt, nämligen sommardäck och vinterdäck. Grupperna sommardäck respektive vinterdäck är i sin tur fyllda med objekt som representerar de däck som finns. Det som kan tyckas saknas i denna bild är relationerna mellan vilka däck som passar på vilka fälgar. I detta fall skulle man t ex kunna beskriva det med ett relationsförhållande mellan SDäck1 och Fälg1, och mellan VDäck1 och Fälg Egenskapsmodellering I detta avsnitt följer den del som beskriver hur egenskaper för de olika objekten modelleras. De resultat som följer införs sedan ER-diagramet över systemdatabasen. Avsnittet kommer avslutas med ett exempel för att klargöra och visa hur det praktiskt kan fungera. Egenskapsentiteten talar om vilken typ av egenskap det är, t ex om det är ett heltal, flyttal eller en textsträng. En egenskap kan också lagra ett fördefinierat värde, om något existerar. Om typen för egenskapen inte är ett heltal pekar det fördefinierade värdet tillsammans med typen på egenskapen ut det objekt eller sträng som utgör det fördefinierade värdet. Egenskapen är kopplad till ett objekt och kan således bara tillhöra ett objekt. En relation finns också till entiteten text där textsträngar lagras som kan användas för att presentera egenskapen. Den stora skillnaden mellan den gamla systemdatabasen och den nya är att Fido-uttryck inte lagras tillsammans med en egenskap. Istället 21 (56)

22 kopplas något som kallas propertycontrol till egenskaperna. Propertycontrol fungerar på samma sätt som objectcontrol. Propertycontrol är dock mera inriktat på att hantera kontroll av inmatning och samband mellan egenskaper. Precis som i objectcontrol finns det även i propertycontrol plats för att lagra ett Fido-uttryck. En egenskap kan ha en definierad värdemängd kopplad till sig. Värdemängden lagras i ett listobjekt. Listobjektet kan förutom att lagra vanliga heltal även skapa en värdemängd av textsträngar eller objekt. Precis som i fallet med det fördefinierade värdet så är det typen, av medlemmen i värdemängden, som avgör om det är ett heltal, objekt eller textsträng som pekas ut. I Figur 8 visas den ER-modell som är resultatet av ovanstående avsnitt tillsammans med de tidigare resultaten. Figur 8. ER-diagram efter egenskapsmodelleringssteget Exempel på egenskapsmodellering Det exempel som togs upp i förra avsnittet, objektmodelleringsavsnittet, byggs nu vidare. I detta avsnitt läggs hjulets egenskaper till i designen. Hjulet har i detta fall två 22 (56)

23 egenskaper. Det finns en egenskap som talar om vilken fälg som används och det finns en egenskap för vilket däck som används. Till dessa två egenskaper finns var sin värdemängd kopplad. Värdemängderna består av listor uppbyggda av de olika däck respektive fälgar som finns. Det skulle kunna resultera i något med följande utseende: Figur 9. En schematisk bild över objektet hjul och dess egenskaper. I Figur 9 är värdemängden i listobjekten inte redovisade utan enbart att det är ett listobjekt. Listobjekten, d v s det som utgör värdemängden, är i detta fall av en speciell typ. Typen som vi skulle kunna kalla objectchildren, betyder att det finns en relation från listobjektet till ett annat objekt vars barn är tänkt att utgöra värdemängden. I vårt fall med hjulet innebär det att medlemmen i värdemängden utgörs av alla de fälgar som finns som barn till objektet fälg, som egentligen utgör en grupp av fälgar. På samma sätt finns två listobjekt lagrade som pekar på barnen till gruppobjektet sommardäck respektive vinterdäck Användargränssnittsmodellering Detta avsnitt beskriver den del av systemdatabasen som är tänkt att bygga upp användargränssnittet. I slutet byggs exemplet från de tidigare två avsnitten vidare med ett grafiskt användargränssnitt. I den gamla systemdatabasen fanns ett system för att presentera egenskaperna till ett objekt där man använde sig av ett antal olika mallar, kallade dialoger. Detta system vill man generalisera. Man vill dessutom kunna styra presentationen av enskilda egenskaper och presentera samma objekt på flera olika sätt. 23 (56)

24 De datastyrda användargränssnitt som tidigare skapats för att användas under körning av programmet är få och oftast handlar det om något slags språk som tolkas i realtid. Givetvis skulle ett sådant språk kunna lagras som textsträngar som sedan kopplas till de olika objekten och som tolkas under körning då ett objekt ska presenteras. Dessa språk är dock oftast ganska omfattande och medför att en avancerad tolk behövs. Detta är något som inte bara stjäl en massa beräkningskraft utan också lagringsutrymme. Istället har ett eget system för att styra det grafiska användargränssnittet utvecklats som inte är fullt så avancerat men som ändå tillåter att ganska avancerade användargränssnitt kan byggas. Istället för att använda färdiga mallar så införs ett hierarkiskt system av noder som kan liknas vid de layout managers som finns i exempelvis Java. Layout managern styr t ex var inmatningsfält placeras på skärmen eller hur stor yta de får uppta. Layout managers kan nästlas i varandra m h a en hierarkisk struktur, inte helt olikt hur HTML-sidor byggs upp, för att få ett mera avancerat användargränssnitt. Beroende på hur strukturen hos de underliggande noderna och de argument de har så bestämmer layout managern hur det grafiska användargränssnittet ska se ut och fungera. En layout manager kan förutom att bestämma utseendet också användas för att styra i vilken ordning information ska matas in. Den funktionalitet som man väljer att implemetera i layout managern är således inte hårt specifierad till att endast placera ut föremål på skärmen utan kan användas på flera olika sätt. I Figur 10 visas tre exempel på hur användargränssnittet kan se ut om man implementerar två olika layout managers. 24 (56)

25 Figur 10. Figurerna företäller grafiska gränssnitt hanterade av layout managers. Figuren till vänster visar en enkel layout manager som delar upp skärmen i två kolumner. Figuren i mitten visar en layout manager som skapar ett fliksystem med två sidor. Figuren till höger visar hur det kan se ut om layout managern i figuren till vänster nästlas med layout managern i mitten figuren. För att layout managern ska ha något att placera ut på skärmen så införs widgets. En widget är de grafiska föremål som man bygger upp sina program med, det kan vara ett inmatningsfält för text eller en avbrytknapp. En widget är med andra ord det man interagerar med. Eftersom man vill skapa en slags nästlad struktur som påminner om den som används i HTML och Java så behövs en faderskapsrelation. Därför, precis som för objekten, införs en faderskapsrelation mellan layout managers. Förutom att man vill kunna nästla layout managers så vill man även kunna koppla widgets till de olika layout managerna. Det kan göras på flera olika sätt, bl a genom att skapa två olika entiteter och en relation mellan de båda entiterna, widgets och layout managers, eller så kan man sammanföra dem i en och samma entitet. Jag valde att sammanföra dem i en och samma entitet för att effektivisera sökningarna efter poster då man slipper söka i flera olika tabeller. Jag skapade därför en entitet som kallas widget som kan anta formen av en layout manager eller agera widget. Widgetarna har en relation till den egenskap som de representerar grafiskt. Det finns även en relation till objektet som på så sätt får en grafisk representation över sina egenskaper. Så det som läggs till i ER-diagrammet är således en entitet för något som vi kallar widget som innehåller funktionaliteten för både widget och layout managern. Den entiteten har även argument för att man skall kunna tala om hur bred eller hög en widget ska vara eller om t ex hur många kolumner en layout manager ska skapa. Detta resulterar i ER-diagrammet i Figur (56)

26 Figur 11. ER-diagram över den fullständiga systemdatabasen. Vissa entiteter har attribut som heter arg1, arg2 o s v. Dessa är tänkta att fungera som ännu icke namngivna argument. Ett par exempel nämndes i stycket ovan, men de allra flesta är ännu inte uttänkta. Det kan handla om alltifrån att kunna bestämma höjden på ett textinmatningsfält eller ordna egenskapernas placering i ett formulär Exempel på användargränssnittsmodellering Exemplet i föregående avsnittet byggs nu vidare med ett grafiskt användargränsnitt för att kunna inventera hjul. Det man behöver är först en Layout manager som talar om på vilket sätt den ska placera ut de egenskaper som objektet har. Sedan behövs det en widget för varje egenskap som talar om hur de olika egenskaperna ska visas på skärmen. Dessa kopplas sedan ihop med varandra för att bilda den struktur man vill uppnå. 26 (56)

27 Figur 12. Användargränssnittmodellering över objektet hjul. I Figur 12 markerar de heldragna linjerna relationerna mellan objektet och dess egenskaper. De streckade linjerna representerar användargränssnittet. I detta exempel ligger det först en widgetnod som är en layout manager som talar om att egenskaperna ska placeras ut i kolumner, ett argument till layout managern talar om att den endast ska skapa en kolumn. Layout manager-noden har i sin tur två barn. Det ena barnet till layout managern är en widget som talar om att egenskapen däck ska presenteras med en drop-down lista. Det andra barnet är en likadan nod som istället har en relation till egenskapen fälg. Det användargränssnittet skulle kunna se ut som i Figur 13 på en handdator. Figur 13. Användargränssnitt skapat med användargränssnittsmodellering. 27 (56)

28 Eventuellt kan flera olika varianter av grafiskt utseende behövas till samma objekt, t ex kanske man vill ha ett utseende för ett objekt om det ska skrivas ut som ett protokoll på en skrivare efter att objektet har inventerats. Av den anledningen kan flera olika widget-noder kopplas till samma objekt. Hur man sedan håller skillnad på vilket utseendeträd som är för skrivare eller inventering kan styras av den första noden i trädet. Den noden kan helt enkelt bestå av en widgetnod som har en speciell sorts layout manager som talar om att det rör sig om ett protokoll som lämpar sig för att skriva ut till skrivare Specialisering av systemdatabasen Med hjälp av Fido kan avancerade operationer och beräkningar utföras och det innebär stor flexibilitet för den som vill utveckla en ny inventeringsapplikation, men för att applikationen skall bli tillräckligt snabb på en handdator kan det vara klokt att inte använda sig av Fidouttryck. Det är inte otroligt att en tolkning av ett uttryck skulle ta så lång tid att man skulle uppleva en fördröjning. Dock har inga tester har utförts med Fido-tolkning på handdator och därför kan ingen slutsats dras ur resonemanget. Ett alternativ till ett interpreterande språk skulle kunna vara fördefinierade funktioner som kan anropas med argument tagna ur systemdatabasen. Ett exempel på en sådan funktion skulle kunna vara största eller minsta tillåtna värde. Även om det inte ingår att undersöka Fido i detta examensarbete så kan man anta, eftersom utvecklingen av handdatorer gått fort den senaste tiden, att beräkningskraften för att utföra interpretering av Fido-uttryck snart finns tillgänglig. Det gör att man på sikt kanske vill implementera en tolk för Fido-uttryck. Tills vidare kan man klara sig med fördefinierade funktioner som tar hand om de allra vanligaste kontrollerna och beräkningarna som måste ske Översättning till relationsmodell Översättningsproceduren från ER-diagram till relationdsmodell kräver att databasmodellen är normaliserad. En kort genomgång av vad detta innebär följer i nedanstående avsnitt tillsammans med resultatet av översättningen av databasmodellen Normalformer Vid en direkt översättning från ER-diagram till relationsmodell kan problem med normalisering uppstå. De problem som kan uppstå om man inte normaliserar är t ex att information dubbellagras eller att information inte går att lagra. Normalformerna kan användas vid analysering av en given design för att se vilka problem som finns eller 28 (56)

29 som kan uppstå. Problem som kan uppstå genom normalisering kan ofta undvikas genom att följa två enkla grundregler: En typ av objekt per tabell. En instans av ett objekt per rad i tabellen. Innan definitioner av normalformer kan ges är det nödvändigt att först definiera vad som menas med funktionellt beroende. Funktionellt beroende, fb, om en kolumn är beroende av en eller flera kolumnner, determinanten, i samma tabell är den funktionellt beroende. Fullständigt funktionellt beroende, ffb, funktionellt beroende där man inte kan ta bort kolumner ur determinanten, d v s determinanten är minimal. Nedan presenteras de olika normalformerna: Första normalformen, 1NF, betyder att endast atomära värden får lagras. Det är i princip alltid uppfyllt då de flesta databashanterare endast kan lagra ett värde per fält. Andra normalformen, 2NF, är 1NF och att varje icke-nyckelattribut ska vara ffb av varje kandidatnyckel. Det vill säga att inga funktionella beroenden får finnas från delar av primärnyckeln utan endast funktionella beroenden från hela primärnyckeln. Tredje normalformen, 3NF, är 2NF och att inget ickenyckelattribut får vara ffb av något annat icke-nyckelattribut. Boyce-Codds normalform, BCNF, är 1NF och att varje determinant skall vara en kandidatnyckel. Boyce-Codds normalform är en något strängare normalform än 3NF men de flesta tabeller i 3NF är redan i BCNF. Om tabellerna är i BCNF slipper man att redundant information lagras i databasen. Det enklaste sättet att kontrollera om en tabell är i BCNF är att visa alla fullständiga funktionella beroenden som pilar. Då ska alla pilar gå från kandidatnycklar. Om en pil går från något annat än en kandidatnyckel, så är tabellen inte i BCNF. Nackdelen med BCNF är att sammanslagningar av tabeller kan behövas vid sökning då all information ligger i separata tabeller, en s k join operation. Det innebär en prestandaförsämring gentemot att tabeller lagrar flera sorters information. En annan nackdel med att 29 (56)

30 normalisera är att få en enklare och klarare design med ett färre antal tabeller. Eftersom de sökningar som behöver göras i databasen inte är av den natur att flera tabeller behöver slås samman så är det mycket lämpligt att de tabeller som skapas är i BCNF Översättning från ER-diagram till relationsmodell Tillvägagångssättet vid översättning från ER-diagram till en relationsmodell består av 10 steg. I detta avsnitt följer vi översättningen av ER-diagrammet i Figur 11 till relationsmodellens tabeller steg för steg. 1. Varje vanlig entitetstyp blir en tabell. Vanliga attribut blir kolumner i tabellen. Detta steg resulterar i tabellerna: list, object, objectcontrol, property, propertycontrol, text och widget. Figur 14. Tabeller skapade i steg Varje 1 N-relation blir ett referensattribut i "många"- entitetstypens tabell. Det medför att kolumner läggs till i följande tabeller: object, property och widget. Figur 15. Tabeller förändrade av steg Varje 1-1-relation blir ett referensattribut i den ena entitetstypens tabell. Inga sådana relationer finns i ERdiagrammet och hoppas därför över. 30 (56)

31 4. Varje N - M-relation blir en egen tabell. Följande tabeller skapas genom detta steg: objectcontrolrelation, objectrelation och propertycontrolrelation. Figur 16. Tabeller skapade av steg Varje flervägsrelation blir en egen tabell. Inga flervägsrelationer finns i ER-diagrammet och steget hoppas därför över. 6. Attribut på relationer blir kolumner. För 1-1- och 1 - N- relationer i samma tabell som den med referensattributet, och för N - M-relationer i den särskilda relationstabellen. En kolumn läggs till i tabellen objectrelation. Figur 17. Tabeller förändrade av steg Varje svag entitetstyp blir en tabell. Primärnyckeln består av den svaga entitetstypens partiella nyckel, kombinerad med den identifierande entitetstypens primärnyckel. Inga svaga entitetstyper finns i ER-diagrammet och hoppas därför över. 8. Sammansatta attribut behandlas som om de bara bestod av delarna. Inga sammansatta attribut finns i ER-diagrammet och steget hoppas därför över. 9. Varje flervärt attribut blir en egen tabell. Primärnyckeln består av entitetstypens primärnyckel, kombinerad med det flervärda attributet. Inga flervärda attribut finns i ER-diagrammet och steget hoppas därför över. 10. Härledda attribut ignoreras. När hela ER-diagrammet är översatt till en relationsmodell kontrollerades alla tabeller så att de var i BCNF. Figuren nedan visar hela relationsmodellen med dess relationer markerade med hjälp av linjer mellan tabellerna. 31 (56)

32 Figur 18. Den fullständiga relationsmodellen Prestandatester av systemdatabasimplementationer I nedanstående avsnitt presenteras vad som testades och de praktiska resultaten. Testerna utfördes både i en emulator och på en riktig handdator. Det som var av vikt att undersöka var dels hur mycket lagringsutrymme en systemdatabas skulle använda och dels hur lång tid det skulle ta att hämta ut ett formulär för inventering. Tiden det tar att hämta ett formulär är av stor vikt då användaren inte skall behöva vänta då en knapp har tryckts ner utan allt ska tyckas ske direkt. För att undersöka hur mycket lagringsutrymme systemdatabasen för Sting 2000 skulle ta upp gjordes en applikation som skapade en relationsdatabas och fyllde den med data. Data som användes för att fylla databasen genererades av testprogrammet. Antalet poster som skapades i relationsdatabasen motsvarar ungefär det antal som finns i den nuvarande systemdatabasen i Sting Antalet poster i de olika tabellerna redovisas i tabellen nedan. 32 (56)

33 Tabellnamn Antal poster objectcontrol 100 propertycontrol 100 object 200 property 2500 widget 2500 list 4000 text 5000 Figur 19. Antal poster som användes vid prestandatestet. För att undersöka hur lång tid det skulle ta att hämta ett formulär för inventering undersöktes Sting 2000 och en approximation gjordes över hur många olika poster i de olika tabellerna som behövde hämtas för ett formulär. Det antal poster som hämtades ur de olika tabellerna redovisas i tabellen nedan. Tabellnamn Antalet poster property 10 list 20 widget 10 text 15 Figur 20. Antal poster som hämtades ur varje tabell vid prestandatestet. Sökningarna utfördes på samma sätt som om en algoritm tolkade databasen skulle ha gjort, d v s sökningar utfördes på den kolumn som faktiskt används i de olika relationerna och inte på de index som de olika tabellerna har. Information hämtades inte ur alla tabeller utan testet gjorde endast för att få ett tillräckligt underlag till beslut om implementationsrekommendation SQL Server 2000 Windows CE 2.0 Efter en mindre undersökning över vilka databaser som finns till Pocket PC-plattformen utsågs SQL Server som kandidat. De andra databaserna som finns på marknaden kostar alla pengar eller verkade inte tillräckligt mogna för att konkurrera med SQL Server. SQL Server fanns desseutom att tillgå via GoldPen Computing AB för utvärdering utan att något behövde köpas in. Ett testprogram konstruerades där data lagrades i tabeller i SQL Server och storleken 33 (56)

34 på filen uppmättes till 948 KB vilket får anses som en liten fil i sammanhanget. Ytterliggare funktionalitet lades till i testprogramet där olika poster i databasen hämtades, motsvararande ett normalstort formulär. Hämtningstiden för formuläret var förvånansvärt hög och trots att en del optimeringar utfördes på databasen, t ex indexering, så sjönk hämtningstiden ytterst lite. Det visade sig att mycket tid gick förlorad i kontakten med SQL-databasen och det tog drygt 3 sekunder att hämta de poster som behövdes för ett tänkt formulär. Slutsatsen av testet är att SQL Server inte går att använda för hämtning av poster under körning av programmet. Dock skapar SQL Server en lämplig plattform för lagring av systemdatabasen genom att den tar lite utrymme och det är enkelt att synkronisera innehållet i den handdatorbaserade SQL Server-databasen med den vanliga versionen för stationära datorer. En lägre normaliseringsnivå av systemdatabasen hade inte snabbat upp datahämtningen för att göra SQL Server till ett gångbart alternativ eftersom inga sammanslagningar av tabeller behöver göras i sökningarna Tabeller i minnet För att lösa problemet med de långsamma hämtningstiderna ur databasen gjordes ett testprogram som hämtade in all data ur SQL Server-databasen och lagrade tabellerna internt i ett antal olika hashtabeller. Ur dessa hashtabeller hämtades sedan de poster som bygger upp formuläret. Trots stora datamängder visade sig denna metod vara snabb och inte speciellt minneskrävande. Att hämta posterna till formuläret tog ca 4-5 ms och lagring av systemdatabasen i de olika hashtabellerna tog upp ca 4 MB minne. Det som dock är värt att notera är att inläsningen av systemdatabasen från SQL Server till hashtabellerna tar runt 20 sekunder. Hashtabellernas utseende är hårdkodade i exempelprogrammet vilket medför att om man ändrar systemdatabasens utformning genom att exempelvis införa en ny kolumn så resulterar det i att programmet måste ändras och kompileras om. Detta skulle kunna lösas med att någon form av metadata läses ur databasen där information om tabellernas kolumner sedan används för att bestämma utseendet på hashtabellerna. Dock lider man av samma problem även om man använder sig av en riktig databas då modellen som hämtar informationen ur databasben fortfarande inte vet om att en ny kolumn dykt upp. Detta problem torde dock vara tämligen litet eftersom att 34 (56)

35 systemdatabasen, då en applikation är färdigutvecklad, inte är tänkt att ändras speciellt ofta Slutsats Dessa praktiska test har visat är att det inte är några problem att lagra en förhållandevis omfångsrik systemdatabas på en handdator. Tiden det tar att hämta de poster som efterfrågas i hastabeller är kort och det bör inte heller vara något problem att hantera stora formulär. Dock bör ett alternativt lagringsformat till SQL Server användas för att förkorta inläsningstiden. Något som inte undersökts i detta examensarbete men som använts i tidigare projekt på GoldPen Computing AB är det inbyggda stöd som finns i Windows CE för enklare databaser. Dessa databaser har använts i tidigare projekt där de visat sig ge bra prestanda Systemmodell och tolkning av systemdatabasen I nedanstående avsnitt presenteras en tänkbar systemmodell och ett testprogram som implementerar en mindre del av systemmodellen Möjlig systemmodell Detta avsnitt beskriver en tänkbar systemmodell för en inventeringsapplikation. GUI Inventeringsdata Systemdatabas Figur 21. Tänkt systemmodell för Pocket Sting De tre modulerna i systemet motsvarar det grafiska användargränssnittet (GUI), inventeringsdata, och systemdatabasen. De 35 (56)

36 träd som finns i de olika modulerna motsvarar de interna representationerna av data som förekommer. I systemdatabasen förekommer två olika typer. Det ena trädet, prickat i Figur 21, representerar den logiska uppbyggnaden av objekt, relationer dem emellan, och deras egenskaper. Det andra trädet, streckat i Figur 21, motsvarar objektens grafiska presentation. Avsnitt 3.4 och 3.5 beskriver hur det prickade trädet är uppbyggt och avsnitt 3.6 beskriver hur det streckade trädet är uppbyggt. I inventeringsdatamodulen finns ett träd som innehåller de objekt som har skapats under inventering. De objekt som återfinns i detta träd är instansierade objekt ur systemdatabasens prickade träd. I användargränssnittsmodulen finns ett streckat träd som är en instansiering av det streckade trädet i systemdatabasmodulen. Då ett objekt skall inventeras skapas en grafisk representation i form av ett formulär i användargränssnittet, från formulärträdet i systemdatabasen, och ett objekt instansieras i inventeringsdatamodulen, från det logiska trädet i systemdatabasen. I en tänkt systemmodell måste det finnas en koppling mellan ett instansierat objekts egenskaper och det instansierade formulärets widgets. Denna koppling måste finnas då ett formulär ska kunna uppdatera det instansierade objektets egenskaper och på motsvarande sätt om man användaren vill se eller ändra sparade data för ett instansierat objekt. Då ett instansierat formulär försöker uppdatera ett instansierat objekt så kontrolleras det instansierade objektet mot systemdatabasens logiska träd för att se om det ska utföras någon kontroll på det inmatade värdet, eller om det inmatade värdet påverkar någon annan egenskap hos det instansierade objektet Tolkning av systemdatabas Att implementera en fullständig tolk för all funktionalitet har inte varit möjligt, och ingår inte riktigt i uppgiften, inom de uppsatta tidsramarna. Istället för att implementera en fullständig tolk har en koncentration på det grafiska gränssnittet gjorts. För att testa om teorin med layout managers och widgets fungerar i praktiken skapades ett testprogram som visar formulär för objekt. Testprogrammet täcker delar av användargränssnittsmodulen och delar av systemdatabasmodulen. Testprogrammet letar igenom systemdatabasens logiska träd efter objekt som har ett formulärträd. 36 (56)

37 De olika formulärträden kopplas sedan ihop med ett menyalternativ. Då man väljer ett formulär i menyerna skapas ett formulärträd i användargränssnittet m h a det formulärträd som finns i systemdatabasen. I testprogrammet skapas inget objekt i inventeringsdatamodulen och alltså sparas inget av det man matar in. Testprogrammet tar därmed inte hänsyn till hur de instansierade objekteten ska lagras eller hur de olika delarna ska samarbeta med inventeringsdatamodulen. En miniminivå för tolken lades vid att två olika layout managers skulle implementeras och att minst två olika användargränssnittskomponenter skulle finnas tillgängliga. Ett fåtal datatyper ska tolken förstå, t ex heltal, strängar och objekt. Tolken ska även kunna hantera listor tillhörande egenskaper för att fylla exempelvis en lista eller en combobox. För att visa egenskaper skapades två olika komponenter, s k widgetar; en textbox och en combobox. Textboxen låses för inmatning genom att ett av argumenten sätts till ett. Tre layout managers implementerades. Den första fungerar väldigt enkelt genom att bara lägga upp widgetarna radvis. Den andra layout managern skapar ett antal flikar. Den tredje layout managern skapar flikar där rubriken på fliken sätts genom ett argument och sedan radas widgetarna upp på samma sätt som den enkla managern. För att få testdata så skapar testprogrammet en systemdatabas och fyller den med egenskaper för ett sängobjekt. En säng har tre egenskaper; längd, bredd och bäddmadrass. Längd och bredd är båda av typen heltal medan bäddmadrass är en form av objekt. Längden på sängen är specifierad till 200 cm och ska inte kunna ändras. Bredden på sängen kan bara anta ett antal fördefinierade värden som lagras i en lista. Egenskapen bäddmadrass är också fördefinierad via en lista. Denna lista innehåller referenser till de objekt som är bäddmadrasser. Till objektet skapas två formulär. Det ena formuläret är tänkt att bara rada upp de olika egenskaperna under varandra. Det andra formuläret skapar ett fliksystem med två flikar där den första fliken innehåller den fördefinierade egenskapen längd och den andra fliken innehåller egenskaperna bredd och bäddmadrass. Systemdatabasen implementerades med hashtabeller som läser upp informationen ur en SQL Server-databas. Systemdatabasmodulen har 37 (56)

38 ett enkelt gränssnitt där de olika tabellerna ligger publika för de andra modulerna. Användargränssnittsmodulen ber systemdatabasen läsa upp informationen ur SQL Server-databasen och hämtar sedan information ur systemdatabasen om vilka objekt som har formulär. Då modulen får ett anrop om att visa ett formulär för ett objekt, traverserar den igenom det formulärträd som finns i systemdatabasen och skapar ett motsvarande träd av noder i användargränssnittet. Detta träd traverseras sedan igenom för generera det formulär som sedan visas i användargränssnittet. De användargränssnittskomponenter som skapas har en koppling till en lista som tillhör det skapade objektet. Via denna lista skulle en eventuell inventeringsdatamodul komma åt de användargränssnittskomponenter som motsvarar det objektets egenskaper. Figur 22 till Figur 24 visar hur det ser ut då testprogrammet körs. Figur 22. De formulär som finns till object1 visas i menyn. 38 (56)

39 Figur 23. Det första formuläret med en enkel layout manager. Figur 24. Det andra formuläret med en flikbaserad layout manager. 39 (56)

40 4. Användargränssnitt för handdatorer I detta kapitel kommer den grundläggande teorin presenteras. Den ligger sedan till grund för utformningen av det grafiska användargränssnittet. Teorin till detta kapitel är hämtat ur [6] och [2], där [6] har sammanfattat teorin kring små skärmar på ett kompakt och bra sätt. Arbetsgången vid design av ett grafiskt användargränssnitt är hämtat ur [2], där även allmänna MDI-regler beskrivs Teorisammanfattning Skärmstorleken spelar en avgörande roll vid design av ett användargränssnitt för handdatorer. En litteraturstudie av användargränssnittsdesign för små skärmar har därför gjorts. Den mesta informationen riktar sig till ännu mindre skärmar än dem hos handdatorer, sådana som används i mobiltelefoner och liknande. Mycket av det som de studierna kommer fram till går trots det att tillämpa på en skärm som är något större. Samtidigt gäller alla de studier, angående tydliga typsnitt, gruppering av användargränssnittkomponenter, ikoner och dylikt, som är framtagna för vanliga skärmar även den mindre skärmen Skärm och inmatning Den främsta begränsningen vid design av användargränssnittet på en handdator är skärmens storlek och upplösning samt inmatningsmöjligheterna. Handdatorer har ofta inmatning via pekverktyg och endast ett fåtal erbjuder tangentbord. Detta medför att man i så stor utsträckning som möjligt skall undvika textinmatning. Eftersom textinmatning stör arbetsflödet bör man söka efter alternativa inmatningsmetoder, t ex kan man visa alla gatunamn i en lista istället för användaren ska behöva skriva in gatunamnet. Små skärmar kan liknas vid Post-It-lappar, båda är effektiva för kort fokuserad information men olämpliga för långa eller komplexa meddelanden. Detta betyder att den totala informationsmängden som visas på skärmen bör minimeras vid varje tillfälle till det absolut nödvändigaste. Om man trots allt måste visa en större mängd information på skärmen samtidigt så har det visat sig i forskning, enligt [6], att man bör dela upp informationen på flera sidor istället för att låta användaren scrolla. Det är bättre ur prestationssynpunkt och användarna föredrar det alternativet, men på små skärmar föredrog användarna scrollning framför uppdelning i sidor. Det bör påpekas att 40 (56)

41 med små skärmar menar man i detta fall de skärmar som används i mobiltelefoner som har väsentligt lägre upplösning än en handdator. Det kan vara svårt att indikera varningar och tillhandahålla upplysningar då man inte har en stor skärm, då kan små ikoner i nedre delen av skärmen vara en bra lösning. Då applikationen är tänkt att användas på flera olika plattformar med olika stora skärmar är det viktigt att designen på användargränssnittet är gjort för den minsta skärmen. Det tenderar ofta till att bli ett svårnavigerat gränssnitt då scrollning måste tillämpas i alltför stor utsträckning Gruppering och placering Objekt som hör ihop med varandra kan grupperas ihop. För att göra dessa grupper tydliga bör tillhörighet mellan objekten visas genom spatial närhet, färgkodning och eller med grafiska gränslinjer. Grupperingar leder till att användaren lättare får en överblick av objekten. Placering av objekt och grupper bör hållas konsekvent genom hela programmet. Generella element bör placeras före specifika objekt och så vidare Ikoner En ikon är en grafisk representation av en applikation, funktion eller ett koncept som betyder något för användaren. Studier har visat att ikoner och text är mindre förvirrande än att endast använda ikoner. Endast text är mindre förvirrande än att endast använda ikoner. En kombination av ikoner och text är således att föredra. För att förtydliga skeenden kan dessa representeras med animerade ikoner. Text är ibland bättre än att använda endast symboler, men bra grafiska symboler är mer underhållande och tilltalande än att endast använda text. Detta kan vara mycket viktigt ur marknadsföringssynpunkt då det ger ett mer användarvänligt gränssnitt. Om ikoner och text används samtidigt bör användargränssnittet stödja någon slags valmöjlighet för den avancerade användaren att slå av och på text och ikoner för att en anpassning skall kunna göras för den mera avancerade användaren. Om skärmen är liten så att ikonerna är svåra att tyda p g a deras storlek bör man överväga att använda text istället. Vid formgivning av ikoner är det mycket viktigt med visuell konsekvens. Detta gäller egenskaper som att ikonerna är svängda på 41 (56)

42 ett visst sätt, linjernas tjocklek, färgsättning, 3D-effekt och liknande. De kulturella skillnaderna skall beaktas vid val av symboler då betydelsen av bilder och färger kan variera. Forskning har visat att användaren uppfattar fyllda figurer mycket bättre än icke fyllda figurer, och att cirkelfigurer är svårare att uppfatta än fyrkantiga. Man bör eftersträva att komma på enkla figurer med få element. För att en ikon ska vara lätt att uppfatta bör man följa nedanstående punkter: Figuren skall vara fylld. Figuren avbildar hela objektet och inte bara en mindre del. Figuren är enkel, men ändå konsekvent. Figuren föreställer bäst konkreta objekt och är mest effektiv som en miniatyrepresentation av det fysiska objektet. Effektiviteten hos en ikon avgörs om ikonen direkt kan representera det man avser eller om en omkodning måste göras. Det är också viktigt att de olika symbolerna är lätta att lära sig. Det man bör tänka på är att ju mer abstrakt koncept desto svårare är det att hitta en fungerande ikon Text Då längre stycken text ska presenteras för användaren finns det många studier som ger grundläggande råd om vad man ska tänka på för att maximera läsbarheten. En sammanfattning av vad man bör tänka på då man använder en liten skärm ges i denna text. Gränsen för läsbarhet ligger vid 9-12 pixlar för handdatorer vilket motsvarar en texthöjd på 2,1 2,9 mm. Texten skall ha hög kontrast jämfört med bakgrunden och det ska vara lika myket utrymme mellan raderna som raderna är höga. Ett antal studier har undersökt hur läshastigheten påverkas av antalet synliga tecken på skärmen. Det har visat sig att mindre än 26 tecken per rad skall undvikas då text skall presenteras för att inte läshastigheten skall sjunka för mycket. Dock har det visat sig att antalet rader som texten presenteras på spelar mindre roll. Förkortningar bör endast användas där det behövs på grund av utrymmesskäl och då användaren kan antas vara bekant med dem. Markeringar skall användas sparsamt oavsett vilka metoder som används, eftersom överanvändning motverkar deras syfte. Exempel på markeringar kan vara färgning, invertering, fetstil mm. Det som verkar fungera bäst är dock färgkodning. Markeringar får endast användas då 42 (56)

43 validiteten är hög, d v s rätt sak är markerad. Blinkande text bör i de flesta sammanhang undvikas som markeringsmetod Övrigt Det är viktigt att användargränsnittet använder metaforer och begrepp som användaren är van vid. Om ovana begrepp och metaforer används kan det vara svårt för användaren att få grepp på hur systemet fungerar. Studier som gjorts på små skärmar visar att de resultat som erhållits vid studier av vanliga skärmstorlekar även gäller för små. Eftersom de moderna handdatorerna använder samma metaforer, skrivbord, fönster m m, som de vanliga stationära datorerna så förväntar sig den normala användaren att den ska ha samma kapacitet och snabbhet som en stationär dator. Det ställer krav på att utvecklaren designar ett användargränssnitt som känns lika snabbt som på en stationär dator. Det innebär att om något kommer ta en stund att utföra bör användargränssnittet tydligt meddela användaren detta. När man designar menyer bör man tänka på att menystrukturen bör vara bred och grund istället för smal och djup. Konkava menystrukturer är det bästa ur effektivitetssynpunkt, dvs många val på start- och slutnivån och få val på mitten. Menyalternativ som förväntas användas ofta bör placeras nära toppen. Om detta inte går att följa bör en kronologisk eller alfabetisk ordning följas. Eftersom Pocket PC -operativsystemet är utformat så att menyerna ligger i nedre delen av skärmen och öppnas uppåt, för att inte handen ska skymma menyerna när man klickat fram dem, skall givetvis de menyalternativ som förväntas användas oftast placeras i botten Användaren och miljön Ett studiebesök på Swedia Networks, de som utför inventering av telestolpar, har genomförts under en dag. Vid detta tillfälle gavs en möjlighet att se hur de befintliga datorerna används och hur de praktiskt genomför en inspektion av telestolpar. De saker som noterades under dagen presenteras i detta avsnitt. De krav som den fysiska omvärlden ställer på datorn är att den bör tåla värme, solljus och regn. Inget av dessa krav går egentligen att överföra som krav på applikationen. Inventeringen utförs sommartid och därmed skulle en hög kontrast i användargränssnittet vara önskvärd för att maximera läsbarheten vid starkt solljus. 43 (56)

44 Det som kan vara av större intresse att ta upp är användarnas förkunskaper. Användarna, i detta fall inventerarna, har förhållandevis lite kunskaper om datorer och dess interna funktion. De har dock jobbat elektroniskt med Sting 2000 och handhållna PC-datorer under ett antal säsonger, men den terminologi som normalt används i datasammanhang med fönster och skrivbord är inte etablerade. Användarna är mycket kunniga inom inventering av telestolpar och använder särskilda begrepp och ord som bör användas även i ett datorprogram LOFI-prototyp för användargränssnitt Sting 2000 är ett stort program som innehåller formulär för inventering av många objekt. Att tillverka en prototyp för alla formulär är ett arbete som inte går att genomföra inom ramen för detta examensarbete. Istället kommer en konceptuell prototyp att presenteras. Prototypen kan beskrivas som ett antal mallar som är designade efter den teori som presenterades tidigare i detta kapitel. Det användargränssnitt som används i Sting 2000 har utvärderats och omarbetats. Eftersom användarna är vana vid utseendet och den terminologi som används i Sting 2000 har mycket av det gamla användargränssnittet behållits för att skapa ett användargränssnitt som användaren är van vid. Användargränssnittet är dock modifierat för att erhålla maximal användbarhet och produktivitet på en handdator. I rapporten presenteras LoFi-prototypen med hjälp av ett antal scenarier. De olika scenarierna är sedan beskrivna en och en tillsammans med de designbeslut som tagits. LoFi-prototypen visades för två personer på GoldPen Computing AB, en som har lite erfarenhet av stolpinventering och en som har mycket erfarenhet av Sting 2000 och stolpinventering. Ingen riktig testning med de tänkta användarna ufördes då möjligheten att träffa en inventerare inte fanns. Testningen utfördes under informella former och bestod av en dialog med den tänkta användaren. Scenariot beskrevs och användaren kunde fritt delge sina tankar och funderingar Scenario 1 Det första scenariot beskriver hur det ser ut då man startar programmet för första gången eller då man ska inventera ett nytt stationsområde. 44 (56)

45 Figur 25. Bilden visar de olika flikarna vid skapandet av en station. Figur 26. Bilden visar en standarddialog för öppnandet av kartfil. Det formulär som används i Sting 2000 för skapandet av en station ryms normalt sett på en skärmsida på en vanlig PC, detta är dock inte fallet på en handdator. De olika fälten som ska matas in grupperades ihop och sattes på olika fliksidor. Flikarna namngavs och ett par extra navigationsknappar skapades för att en användare som inte är van vid fliksystemet ska erbjudas flera navigationssätt. En standarddialog för öppnandet av kartfil avbildades. En av testpersonerna tyckte att knapparna för navigering mellan de olika fliksidorna vid skapandet av stationen borde ligga nedanför sidornas flikar. Detta ändrades också till Hifi-prototypen. Då scenariot inte omfattar speciellt mycket framkom heller inte så många åsikter Scenario 2 Det andra scenariot går ut på att visa hur programmet ser ut och fungerar då man kommit igång med stationen och ska inventera de olika objekten, i detta fallet lägga till en telestolpe. 45 (56)

46 Figur 27. Menyerna som används i kartvyn och mätpunktsvyn. På grund av den begränsade skärmytan rymdes inte mer än fem menyalternativ på den första nivån, huvudmenyn. Det betydde att utav de ursprungliga sju huvudmenyalternativen, Arkiv, Redigera, Visa, Karta, Verktyg, Inställningar och Hjälp, skapades fem stycken. De som togs bort som huvudmenyer var Karta och Inställningar. De saker som förändras via menyalternativet Karta i Sting 2000 är nästintill enbart sådana saker som skulle kunna inledas med ordet visa och flyttades därför helt sonika in under menyalternativet Visa. De övriga menyalternativen, öppna och stäng karta, som fanns under Karta flyttades till Arkiv -menyn. För att följa gängse standard för Windows-program så flyttades Inställningar till Verktyg. De inventerare som inte är vana vid datorer kanske inte är familjära med Windows standardupplägg på menyer och kanske kan tycka att det är förvirrande. Menyalternativet Visa har en annat utseende då man befinner sig i mätpunktsvyn då de för kartan specifika menyalternativen plockats bort. 46 (56)

47 Figur 28. Kartvy De ikoner som används i kartvyn på Sting 2000 har inte någon medföljande text utan har enbart en svävande text som kommer fram då man håller musen ovanför ikonen. Då svävande text inte går att använda på en handdator är det väldigt svårt att veta vad ikonerna betyder om man inte har använt programmet tidigare eller provar sig fram. Därför har vissa knappar kompletterats med menyalternativ för att öka möjligheterna för användaren. En ikon har lagts till i den högra delen av ikonraden för att kunna byta mellan kartvy och mätpunktsvy. Denna knapp har en bild föreställande ett träd med mätpunkter, ikonen visar alltså hur skärmen ser ut efter man tryckt på knappen. Motsvarande knapp finns på samma ställe i mätpunktsvyn men föreställer där en karta. Motsvarande funktionalitet finns också i Visa -menyn. Figur 29. Mätpunkstvy Mätpunktsvyn är i stort sett likadan som mätpunksvyn i Sting Den stora skillnaden är att mätpunkterna läggs in i ett träd som liknar 47 (56)

48 det som används i filhanteringsfunktionen i windows för att visa var man befinner sig i katalogstrukturen. De tre knappar som finns i den nedre delen av vyn är samma som i Sting 2000 förutom knappen Ta bort som i knapptexten saknar det ord som indikerar vilket objekt som är markerat, ex Ta bort telestolpe. Figur 30. Inventering av en telestolpe Det formulär som fylls i då man ska lägga till en telefonstolpe, eller ändra informationen i densamma, är i stort sett av samma utseende som i Sting Inga speciella kommentarer har givits kring detta scenario. Det som dock framkom är att menyerna har designats om till en uppdaterad version av Sting 2000 som ska släppas snart. Framförallt har saker flyttats om i menysystemet. Efter en genomgång av det nya menysystemet till Sting 2000 valdes det som förebild inför HiFiprototypen. De nya menyerna är logiskt bättre organiserat jämfört med de gamla menyerna och en del menyalternativ bytt namn HIFI-prototyp för användargränssnitt Tanken med hifi-prototypen är att implementera en mjukvaruversion av den pappersprototyp som togs fram som LoFi-prototyp. HiFiprototypen är tänkt att fungera så att man kan klicka sig fram mellan de scenarier som användes i LoFi-prototypen. En del knappar har implementerad funktionalitet för att man ska få en känsla av hur det kan vara att använda användargränssnittet. Den betaversion som användes av.net Compact Framework hade tyvärr inte all funktionalitet implementerad och det innebar att en del saker som skulle användas i HiFi-prototypen fick visas som en bild istället. Den användargränssnittskomponent som inte fanns implementerad i betaversionen var trädkomponenten som skall användas till att visa mätpunkterna och inventeringsobjekten. En annan komponent som inte kan visas annat än som en bild är kartkomponenten. 48 (56)

49 Kartkomponenten är dock inte en del av.net utan har utvecklats av GoldPen Computing AB. Figur 31. De olika flikarna vid skapandet av en station. Figur 32. Standarddialog för att öppna en kartfil. Knapparna för navigation mellan flikarna och skapandet av station flyttades ner utanför flikarna till HiFi-prototypen. I övrigt ändrades inte mycket utan utseendet från LoFi-prototypen behölls. Figur 33. Kartvyn Kartvyn består av en kartkomponent som visar den geografiska placeringen av mätpunkterna. Under kartan finns ett antal knappar med ikoner som används för att styra kartan och placera ut nya mätpunkter. De ikoner som används är 16 gånger 16 pixlar och bör vara tillräckligt tydliga för att de ska fylla sin funktion. Ett alternativ 49 (56)

50 om fler knappar behövs är att placera de knappar som inte används så ofta i en alternativ knapprad som kommer fram då man trycker på en speciell knapp. Det skulle innebära 2 knapptryckningar för att använda en funktion som inte används så ofta, d v s lika många eller färre knapptryckningar som om alternativet hade funnits i en meny. Det som finns i den nuvarande kartkomponenten som kanske bör tas bort, eller förminskas kraftigt, är visningen av skalan då den skulle ta upp ganska mycket utrymme på den begränsade skärmen, se figur 3 på sidan 13. Någon möjlighet att slå av eller på skalan kanske ska finnas för att maximera den användbara ytan för kartan. Figur 34. Mätpunktsvyn Mätpunktsvyn är i identisk med LoFi-prototypen. 50 (56)

51 Figur 35. Formulär för inventering av telestolpe. Formuläret som användes i LoFi-prototypen fick förändras lite på grund av utrymmesskäl. Navigationsknappar för att navigera fram och tillbaka mellan flikarna lades också till, för att vara konsekvent med hur fliksystemet var utformat vid skapandet av en station. Figur 36. Menyerna som används i kartvyn och mätpunktsvyn. De menyer som tagits fram till den nya versionen av Sting 2000 har modifierats för att passa en handdator. En del menyalternativ har tagits bort och ett antal menyalternativ har lagts till, för att öka tillgängligheten av vissa funktioner. Exempel på vad som lagts till är funktioner som normalt sett aktiveras genom knappar i kartvyn. En av de saker som tagits bort är möjligheten att ordna de olika fönstrens storlek, eftersom en handdatorversion aldrig visar de olika vyerna eller 51 (56)

52 fönstren bredvid varandra samtidigt. Menyalternativen i menyn Karta inaktiveras då man befinner sig i mätpunktsvyn. Samma personer som tittade på LoFi-prototypen testade även HiFiprototypen. Det genomgående intrycket var att det verkade väldigt användbart och att det inte skulle vara några problem för de inventerare som använt de handhållna PC-datorerna att gå över till en handdatorversion. Inga förslag på förändringar framkom egentligen av testerna. Om man vill få fram mera utförliga testresultat bör man nog utveckla prototypen ytterliggare lite och testa med riktiga inventerare. 52 (56)

53 5. Resultat I detta kapitel ges en sammanfattning av de resultat och i viss mån de slutsatser som dragits under examensarbetet. Resultatet från de två viktigaste delarna av examensarbetet gås igenom Systemdatabasen Systemdatabasen modellerades efter ER-modellen. Det gav ett enkelt utseende som gjorde det enkelt att översätta modellen till relationsmodellen. Relationsmodellena kan sedan direkt omvandlas till tabeller. Den nya systemdatabasen är mer generell än den gamla genom ett antal punkter. En viktig punkt är hur objekt kan relateras till varandra genom en objekthierarki. Objekthierarkin kan exempelvis användas för att gruppera ihop objekt. En annan viktig punkt är de relationer som kan skapas mellan objekt. Dessa relationer kan användas för att t ex styra vilka åtgärder som kan appliceras på en telestolpe vid inventering. Systemdatabasen tillåter att egenskaperna till ett objekt kan ha värdemängder kopplade till sig och fördefinierade värden. Systemdatabasen innehåller även ett system med kontrollobjekt som kan användas för att ex kontrollera inmatning eller att en relation är giltig. Användargränssnittets datadrivning har lösts genom att en hierarkisk struktur av widgets och Layout managers skapas. Den hierarkiska strukturen liknar den som används i HTML, eller i Java. Komponenterna som används för att bygga upp det grafiska gränssnittet är dels de widgets som används för att presentera ett objekts egenskaper och dels de Layout managers som styr hur widgetarna ska placeras ut på skärmen. De testimplementationer, med reducerad funktionalitet, som gjorts för att se om lösningen är realiserbar har visat att en stor systemdatabas kan lagras på en handdator. Det går även att tolka systemdatabasen tillräckligt snabbt för att konstruera användargränssnitt under körning Användargränssnittet För att få en bra överblick över hur mycket kunskaper användarna av det tänkta programmet har så utfördes ett studiebesök hos Swedia Networks där en inventerare visade hur de arbetar. Det besöket gav värdefulla insikter och djupare förståelse för hur inventeringen går till. 53 (56)

54 Eftersom de användare som är tänkta att använda en handdatorbaserad inventeringsapplikation redan idag använder datorer för att inventera telestolpar så har de en grundläggande kunskap om hur man interagerar med en dator. Den långa erfarenhet som de flesta inventerare har medför att en speciell terminologi används och att man bör använda den i ett användargränssnitt. De arbetar utomhus sommartid vilket innebär att hög kontrast bör användas för att öka läsbarheten i användargränssnittet. Den HIFI-prototyp som arbetet med användargränssnittet resulterade i är en bra bit på vägen. Den ger användaren en bra bild av hur systemet kan tänkas se ut och hur det känns att interagera med systemet. En något mer utvecklad prototyp och en större användarstudie med riktiga inventerarna skulle kunna ge värdefulla synpunkter innan man fortsätter utvecklingen av en fullskalig inventeringsapplikation Rapporten Den obligatoriska delen i examensarbetet är rapporten. Det är meningen att den ska ge läsaren en överblick över hur problem av denna typ kan lösas. Rapporten syftar också till att visa att studenten är förmögen att förmedla sina kunskaper inte bara i tal utan också i skriftlig form. Rapporten är inte skriven enligt någon speciell mall utan influenserna till upplägget på denna rapport är delvis hämtade från PUM grupp nummer 4 år 2002 från kursen TDDB61 Programvaruprojekt i ett helhetsperspektiv som ges av IDA på LiTH. 54 (56)

55 6. Möjliga framtida förbättringar I detta kapitel beskrivs de saker som kan förbättras eller utvecklas i examensarbetet Systemdatabasen Då en inventeringsapplikation skall utvecklas måste en modellering av inventeringsobjekten ske. Den modelleringen måste idag ske för hand i databasen, vilket man vill undvika då man lätt kan göra fel. Ett redigeringsverktyg behöver utvecklas som underlättar skapande och underhåll av systemdatabaser. Skapande och underhåll av en systemdatabas sker företrädelsevis på en vanlig stationär dator. Implementering av en tolk för Fido kan vara intressant att utföra för att undersöka om det är ett användbart språk på en handdator. De kontrollobjekt som finns i systemdatabasen är inte testade rent praktiskt och en undersökning hur de praktiskt kan utformas behöver genomföras. I avsnitt 3.9 nämndes att det finns en sorts enklare databaser i Windows CE. Om man vill fortsätta utveckla i C# och.net Compact Framework kan det vara värt att undersöka hur man kommer åt Windows CE-databaserna för att lagra systemdatabasen i dessa Användargränssnittet För att utveckla användargränssnittet krävs att en större användarstudie genomförs med en eller flera mer utvecklade prototyper. En prototyp bör tas fram där man inte baserar sina idéer på det gamla användargränssnittet i Sting Prototypen bör använda ett nytt upplägg på användargränssnittet för att se om det kan ge högre användbarhet Övrigt En fullständig tolk för systemdatabasen saknas där användargränssnittet byggs upp från systemdatabasen. Utveckla och implementera systemmodellen. Kartkomponenten som används behöver skrivas om för Pocket PC så den kan användas på en handdator. 55 (56)

56 7. Referenser 7.1. Böcker [1] Silbershatz Abraham, Korth F. Henry, Sudarshan S., Database system concepts, ISBN , [2] Preece Jennifer, Rogers Yvonne, Sharp Helen, Interaction design: beyond human- computer interaction, ISBN , [3] Ian Sommerville, Software Engineering, ISBN , Rapporter [4] Nilsson, Peter, ODMBROWSER Ett självanpassande grafiskt användargränssnitt för stora databaser som vidareutvecklas kontinuerligt, LiTH-IDA-Ex-9322, [5] Falkenroth Esa, Risch Tore, Törne Anders, Using an Embedded Active Database in a Control System Architecture, LiTH-IDA-R-95-39, [6] Siljedahl Niclas, Design av små displayer i system med begränsade inputmöjligheter, LiTH-KOGVET-D-0062-SE, [7] Blixt Hagholm K. Fredrik, Sting 2000 för handdatorer, GoldPen Computing AB intern rapport, [8] Bergqvist Ulf, ParkRight databaser och synkronisering, GoldPen Computing AB intern rapport, Internet [9] MSDN.NET Framework SDK, Microsoft, msdn.microsoft.com Dokumentation för.net. [10] Thomas Padron McCarthy, Linköpings Universitet, - Ordlista med utförliga förklaringar till termer som används inom databasområdet. 56 (56)