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)