Elektroniskt Skyttesystem
Databearbetning & Presentation
Electronic Scoring System
Data Processing & Presentation
Andreas Bergman
Fakulteten för hälsa, natur- och teknikvetenskap Datavetenskap
Sammanfattning
Denna rapport beskriver ett projekt med målet att utveckla ett elektroniskt skyttesystem utifrån mindre kostsamma standardkomponenter. Det utvecklade systemet avses inneha funktionalitet som är jämförbar med befintliga sådana system. En utredning av det utvecklade systemets precision ämnas utföras, och om precisionen visar sig vara undermålig behöver en utredning ge förslag på ytterligare hårdvara som krävs för att nå en högre sådan.
Projektet resulterade i ett delvis sammankopplat, fungerande system. Systemet består av fysiska komponenter, en databas och en visningsklientsapplikation som bearbetar och presenterar data. Systemets fysiska komponenter innefattar fyra mikrofoner och en Raspberry Pi 2-enhet. Mikrofonerna registrerar ljudankomster och signalerar dessa till Raspberry-enheten, som sparar data i databasen. Denna data hämtas, bearbetas och visualiseras av visningsklienten.
Systemet saknar i nuläget en fysisk träffyta, och precisionsbrister hos dess fysiska komponenter resulterar i opålitliga resultat, då mätvärden är okonsekventa utifrån upprepade träffar på en specifik position.
Abstract
This report describes a project with the goal of developing an electronic scoring system from less costly standard components. The developed system means to have comparable functionality to existing such systems. An analysis of the developed system’s precision is intended to be performed, and if the precision is found to be substandard an investigation needs suggest further hardware necessary for reaching a higher one.
The project resulted in a partially connected, functioning system. The system consists of physical components, a database and a visual client application that processes and presents data. The system’s physical components comprise four microphones and a Raspberry Pi 2 unit. The microphones register sound arrivals and signal these to the Raspberry unit, which saves data in the database. This data is retrieved, processed and presented by the visual client. The system currently lacks a physical target surface, and precision flaws in the system’s physical components result in unreliable results, since readings are inconsistent from repeated hits at a specific position.
Innehållsförteckning
1 Inledning ... 1 1.1 Projektmål ... 1 1.2 Projektets uppdelning ... 2 1.3 Rapportstruktur ... 3 2 Bakgrund... 4 2.1 Sogeti Sverige AB ... 4 2.2 Elektroniska skyttesystem... 4 2.3 Problemformulering ... 6 2.4 Systemkomponenter... 6 2.4.1 Mikrofoner 2.4.2 Raspberry Pi 2 2.4.3 Databas 2.4.4 Visningsklient 2.5 Utvecklingsmiljö ... 12 2.6 Kapitelsammanfattning ... 12 3 Design ... 143.1 Systemets övergripande design ... 14
3.2 Mikrofoner ... 15
3.3 Raspberry-enhet ... 15
3.4 Application Programming Interface ... 16
3.5 Databas... 16
3.5.1 Molnlösning kontra SQLite 3.5.2 Databaskommunikation genom ramverket Entity Framework 3.6 Data ... 18 3.6.1 Mätdata 3.6.2 Databasdata 3.7 Visningsklient ... 19 3.7.1 Användargränssnitt 3.7.2 Övergripande bakgrundsfunktionalitet 3.7.3 Hämtning av data från databasen 3.8 Träffsimulering ... 29
3.8.1 Testapplikationens vyklass
3.9 Kapitelsammanfattning ... 32
4 Implementation... 33
4.1 Azure SQL-server & databas ... 33
4.2 Utvecklingsmiljöns databasdesigner... 35 4.3 Visningsklient ... 37 4.3.1 Ramverksimplementation 4.3.2 Användargränssnitt 4.3.3 Vyklass 4.3.4 Datahanteringsklass 4.4 Testapplikation... 51 4.4.1 Vyklass 4.4.2 Datahanteringsklass 4.5 Kapitelsammanfattning ... 56 5 Resultat ... 57 5.1 Resultatsammanfattning... 57 5.2 Fysiska komponenter ... 58 5.2.1 Träffyta 5.2.2 Raspberry-enhet 5.2.3 Systemets precision 5.3 Molnet ... 60 5.3.1 API 5.3.2 Databas 5.4 Visningsklient ... 61
5.5 Hela systemet sammankopplat... 62
5.6 Kapitelsammanfattning ... 63 6 Slutsats... 64 6.1 Projektutvärdering ... 64 6.1.1 Utvecklingen 6.1.2 Prototypen 6.1.3 Uppdragsgivaren 6.2 Framtida arbete ... 66
6.2.1 Systemfunktionalitet för flera enheter 6.2.2 Datahämtning och användargränssnittsuppdatering 6.2.3 Enhetlig API-implementation 6.2.4 Systemets databassäkerhet 6.3 Slutord ... 68
Referenser ... 70
A.2.2 Visningsklienten A.2.3 Utredning A.2.4 Optioner A.3. Genomförande/arbetssätt ... 75 A.3.1 Rutiner A.3.2 Hårdvara A.3.3 Genomförande A.4. Stöd/kvalitetssäkring ... 75 A.4.1 Granskningar A.4.2 Testarbete A.4.3 Stöd A.5. Leveranser ... 76 A.5.1 Dokumentation A.6. Konfigurationsstyrning ... 76 A.7. Miljö ... 76 A.8. Uppföljning och Rapportering... 76
A.8.1 Rapportering internt/externt
Figurförteckning
1.1: Design av ett önskat elektroniskt skyttesystem...1
1.2: Illustrerad systemdesign och dess uppdelning...2
2.1: Existerande system på en skyttebana [5], samt måltavlor [6]...5
2.2: Tvådimensionell trilateration...5
2.3: SparkFun Sound Detector [8]...7
2.4: Illustration av förfrågandeprocessen mellan användare och databas...9
2.5: Överblick av Entity Frameworks tre användningsområden [17]...10
2.6: Microsoft Azure Webbportal...11
3.1: Illustrerad design av det elektroniska skyttesystemet...14
3.2: Mikrofon med markerade portar...15
3.3: DbContext illustrerad [29]...18
3.4: Övergripande bild av data till databas genom en Raspberry-enhet...19
3.5: Illustration av visningsklientens användargränssnittsdesign...20
3.6: Illustrerad WPF-designer i utvecklingsmiljön [32]...20
3.7: Illustration av visningsklientens klasser i dess bakgrundsfunktionalitet...22
3.8: Visningsklientens illustrerade vyklassmetoder och ramverksbaserade datahanteringsklassmetoder...23
3.9: Den listbaserade visningsklientens illustrerade datahanteringsklassmetoder...26
3.10: Illustration av visningsklient, testapplikation och databas...30
4.1: Brandväggsregler för SQL-servern i Azureportalen...35
4.2: Utvecklingsmiljöns databasdesigner för databastabellen shots, samt databastabellen shots i utvecklingsmiljöns utforskare...37
4.3: Visningsklientens användargränssnitt i utvecklingsmiljöns WPF-designer...42
5.2: Utökad design av det elektroniska skyttesystemet ...61 5.3: Illustrerad visningsklient...63
1 Inledning
Detta kapitel ämnar introducera projektets mål, samt beskriva den projektuppdelning som projektutvecklarna gjort. Detta följs av en övergripande och kortfattad beskrivning av rapportens struktur och innehåll.
1.1 Projektmål
Målet med projektet var att utveckla ett elektroniskt skyttesystem utifrån mindre kostsamma komponenter jämförbart med befintliga system som i nuläget finns på marknaden (se bilaga A.1.1). Ett prototypsystem avsågs implementeras (se bilaga A.2), bestående av fysiska komponenter och en visningsklient. Ett sådant system, utifrån uppdragsgivarens önskade design, illustreras i Figur 1.1. När systemet sammankopplats skulle det reagera när mikrofonkomponenter tog emot ljud och läsa in mätvärden utifrån dem. Dessa mätvärden skulle sparas in i en databas tillsammans med en enhetsidentitet tillhörande den Raspberry Pi 2-enhet som mikrofonerna kopplats till. Ur denna databas skulle sedan visningsklienten hämta datan, beräkna en träffposition och visualisera denna överskådligt för en användare. Det utvecklade systemets möjliga precision skulle sedan undersökas; om precisionen visade sig undermålig skulle projektutvecklarna utreda vilken typ av hårdvara som behövdes för att nå en högre sådan.
I kravspecifikationen fanns även förslag på vidareutveckling (se bilaga A.2.4.1), vilket innefattade beräkning och presentation av träffresultat, systemhantering av flera Raspberry-enheter och träffytor, samt en administrationsdel. Genom denna administrationsdel skulle man kunna se vilka träffytor som finns tillgängliga, sätta upp en tävling mellan användare samt presentera en vinnare efter en träffserie.
1.2 Projektets uppdelning
Detta projekt valdes att delas upp i två delar, illustrerade i Figur 1.2. Den första delen rör systemets fysiska komponenter, den beräkning som sker kring dessa, samt den data som lagras i systemets databas. Den första delen beskrivs endast övergripligt i denna rapport; den får istället större fokus i rapporten författad av Niklas Ivarsson [1].
Den andra delen rör systemets databas, visningsklient och träffsimuleringsapplikation som togs fram i testsyfte. Denna rapport beskriver hur en databas sätts upp och struktureras, hur kommunikation mellan denna databas och en visningsklient sker, hur data används för att beräkna och visualisera relevant information i visningsklienten, samt hur en testapplikation kan simulera värden och skicka dessa till databasen i syfte att testa visningsklienten.
1.3 Rapportstruktur
Detta avsnitt beskriver övergripande och kortfattat rapportens struktur och innehåll.
Kapitel 1 introducerar projektets mål, samt beskriver den projektuppdelning som projektutvecklarna gjort.
Kapitel 2 beskriver projektets bakgrund. Detta innefattar beskrivningar av uppdragsgivaren, hur befintliga system fungerar, samt den problemformulering som ställts i uppdragsgivarens kravspecifikation. Därefter följer beskrivningar av systemets komponenter, samt den utvecklingsmiljö som används för att utveckla systemets visningsklient.
Kapitel 3 beskriver designen för systemets olika komponenter, först övergripande och sedan för dess individuella komponenter. I kapitlet beskrivs även vissa designbeslut som tagits för systemet och dess komponenter, till exempel rörande systemets databas och visningsklient. En beskrivning av en fristående testapplikation återfinns även här, vars syfte är att simulera träffar för testning av systemets visningsklient. Designen för de komponenter som befinner sig i uppdelningens första del beskrivs endast kortfattat i detta kapitel; större fokus ligger kring de komponenter som befinner sig i den andra delen (se avsnitt 1.2).
Kapitel 4 beskriver systemets implementation, rörande dess databas och visningsklient, samt den fristående testapplikationen som tidigare nämnts. Detta kapitel beskriver endast implementationen av de komponenter som befinner sig i uppdelningens andra del.
Kapitel 5 redovisar projektets gemensamma resultat, utifrån systemets individuella komponenter samt det slutgiltiga, sammankopplade systemet.
Kapitel 6 redovisar rapportförfattarens slutsatser kring projektet. Detta innefattar en utvärdering av projektutvecklingen, den slutgiltiga prototypen samt uppdragsgivaren. Ett avsnitt tar sedan upp de möjligheter som finns till framtida utveckling och optimering av systemet. Kapitlet avslutas med ett avsnitt innehållande rapportförfattarens slutord.
2 Bakgrund
Det här kapitlet ämnar ge bakgrundsinformation kring uppdragsgivaren, den problemformulering som ställts, och det system som under projektets gång avsågs utvecklas. Detta innefattar systemets komponenter, den teknik som användes för att utveckla systemets visningsklient, samt den utvecklingsmiljö som användes för att utveckla systemapplikationerna.
2.1 Sogeti Sverige AB
Sogeti Sverige AB (Sogeti) är ett IT-konsultbolag med en bred verksamhet och ett stort fokus på kompetens och modern teknik (se bilaga A.1.1). Bolaget bildades 1 januari 2003 [2] och är en del av den franska Capgemini-koncernen, ett av världens största konsult- och teknologiföretag med över 180 000 anställda i över 40 länder [3].
Ett projektuppdrag togs fram utifrån ett personligt intresse som fanns på det Karlstadbaserade kontoret rörande elektroniska skyttesystem.
2.2 Elektroniska skyttesystem
Automatiserade elektroniska skyttesystem används inom sportskytte för att visualisera träffplacering och räkna ut resultat. Detta möjliggör en omedelbar och precis återkoppling till skytten, samtidigt som det underlättar för tävlingsorganisatörer och publik [4].
Existerande system består av måltavlor med monterade sensorer, samt monitorer som visualiserar träffytan, träffar och resultat (se Figur 2.1 (a)). Dessa måltavlor kan vara så kallade mjuka eller hårda (se Figur 2.1 (b respektive c)). Mjuka måltavlor har sensorer som är isolerade från träffytan och är stora men relativt lätta, medan hårda måltavlor har sensorer monterade direkt på träffytan och en vikt som beror på byggmaterialet [6].
Olika systemtekniker existerar, där den vanligaste utnyttjar akustik; tre eller flera mikrofoner känner med hjälp av trilateration [7] av var en kula träffat en yta (se bilaga A.1.1). Trilateration går ut på att en position uppskattas utifrån olika punktavstånd (där punkterna i detta fall är de mikrofoner som används), med hjälp av cirkel- eller triangelgeometri. Den eftersökta positionen återfinns i det område där två eller flera sådana former skär varandra. Figur 2.2 illustrerar hur en punkt P återfinns inom det område där tre cirklar med mittpunkter p1, p2 och p3 skär varandra. Denna teknik har praktiska applikationer inom till exempel fältmätning och positioneringssystem.
Figur 2.1: Existerande system på en skyttebana [5], samt måltavlor [6]
2.3 Problemformulering
Elektroniska skyttesystem är i dagsläget förhållandevis dyra (se bilaga A.1.1). Därför vill Sogeti utforska om liknande system kan utvecklas utifrån mindre kostsamma standardkomponenter för att uppnå den precision som krävs. Alternativt vill Sogeti ha svar på följande frågeställningar (se bilaga A.2.3):
Hur hög precision kan man komma upp i med den utrustning som tillhandahålls? (del av mm, mm, cm, dm?)
Vilken typ av hårdvara skulle man behöva för att komma upp i högre precision? Hur mycket skiljer det i precision med den tillgängliga utrustningen jämfört med de
kommersiella systemen som finns?
Figur 1.1 illustrerar den design som Sogeti har bidragit med av ett önskat skyttesystem med flera komponenter: en träffyta med mikrofoner där en träff ska registreras, en Raspberry Pi 2 som skickar värden och enhetsnamn till en databas, vars innehåll visualiseras i en visningsklient.
2.4 Systemkomponenter
I detta avsnitt kommer de fyra systemkomponenter illustrerade i Figur 1.1 att beskrivas. Dessa innefattar systemets mikrofoner som registrerar träffljud, den Raspberry Pi 2-enhet som tar emot och skickar vidare värden till en databas, samt den visningsklient som visualiserar träffar och resultat för en användare.
2.4.1 Mikrofoner
Systemet har för avsikt att med hjälp av mikrofoner reagera på när dessa tar emot ljud av en viss ljudnivå, och sedan uppskatta var en träff har skett (se bilaga A.2).
Härnäst följer en beskrivning av de mikrofoner som tillhandahållits, samt den beräkningsmetod som utförs utifrån de ljudankomster som mikrofonerna registrerar.
2.4.1.1 SparkFun Sound Detector
De mikrofoner som Sogeti tillhandahöll var SparkFun Sound Detector (SEN-12642), illustrerad i Figur 2.3. Dessa mikrofoner är små och användarvänliga, med tre möjliga outputsignaler. Den första av dessa är ljudoutput, den andra en binär indikation av ljudnärvaro, och den tredje är en analog representation av ljudamplituden. Dessa tre outputsignaler är simultana och självständiga, vilket möjliggör utnyttjande av så få eller så många signaler som krävs [8]. När en mikrofon lyckas ta emot ljud har den möjlighet att indikera detta genom att en röd lampa på enheten tänds.
Figur 2.3: SparkFun Sound Detector [8]
2.4.1.2 Multilateration
För att uppskatta var på en yta en träff har skett används en teknik som kallas för
multilateration, där tidsskillnaden för ljudankomster till tre eller flera punkter mäts [9], och
där punkterna i detta fall är systemets mikrofonkomponenter. Denna teknik skiljer sig från trilaterationstekniken, där uppskattningen gjordes utifrån punkternas olika absoluta avstånd till varandra. Multilaterationstekniken går istället ut på att mäta tidskillnader mellan två ankomstpunkter i taget. Den tidsskillnad som uppmäts resulterar i en hyperbel mellan de båda ankomstpunkterna, med ett oändligt antal ursprungspositioner. Genom att utnyttja ytterligare par av ankomstpunkter så kan en ursprungspunkt approximeras utifrån de skärningspunkter som uppstår för de olika utmätta hyperblarna.
2.4.2 Raspberry Pi 2
I systemet kopplas mikrofonerna till en Raspberry Pi 2, som avser samla in mätvärden från mikrofonerna och spara dessa samt en enhetensidentitet i en databas (se bilaga A.2).
Raspberry Pi 2 Model B är den andra generationen Raspberry Pi, som ersatte sin föregångare Raspberry Pi 1 Model B+ i februari 2015. Denna nya version har byggt vidare på originalet
och kan erbjuda en fyrkärnig 900MHz processor samt 1GB RAM-minne, utöver den funktionalitet som funnits tidigare, som till exempel portar för USB, Ethernet och HDMI, samt kortingång för micro-SD [10]. Jämförelsevis kunde de föregående modellerna endast erbjuda en enkärnig 700MHz processor och antingen 256MB eller 512MB RAM-minne [11].
Detta avsnitt följs av en beskrivning av Raspberry-enhetens operativsystem. Därefter följer ett avsnitt som beskriver den ytterligare hårdvara som Sogeti befarar krävs för tidsregistreringen, eftersom Raspberry-enhetens I/O-ingångar kan vara för långsamma för de korta tider det rör sig om (se bilaga A.2.1).
2.4.2.1 Windows 10 IoT Core
Det operativsystem som Sogeti önskar att enheten använder är Windows 10 (se bilaga A.2.1). Den version som kommer användas är Windows 10 IoT Core [13], som är specifikt designad för små enheter och möjliggör ytterligare integrationsmöjligheter med enheter som delar samma operativsystem [14]. Förkortningen IoT står för Internet of Things [15] (på svenska
sakernas Internet), och syftar på fysiska objekts förmåga att samla in och dela med sig av
information över olika nätverk.
2.4.2.2 Time-to-Digital Converter
Sogeti har föreslagit att den ytterligare hårdvara som kan komma att krävas skulle kunna vara en så kallad Time-to-Digital-omvandlare (Time-to-Digital Converter, TDC) (se bilaga A.1.1). En TDC [12] representerar digitalt tiden för en skedd händelse. Sådana händelser skulle till exempel kunna vara ankomsttiden för flera start- och stoppsignaler; TDC används vanligast för att mäta ett tidsintervall mellan sådana signaler. Denna mätning startas när en signalpuls korsar ett visst bestämt tröskelvärde.
Det intervall som önskas mätas är intervallet mellan ljudankomsterna hos de olika mikrofonerna på träffytan. Startsignalen representerar ljudankomsten hos den närmaste
mikrofonen, och följande signaler kommer ifrån de övriga mikrofonerna. Intervallen mellan dessa signaler är relevanta för att uppskatta var på ytan träffen har skett.
2.4.3 Databas
En databas används för att organiserat samla viss data. Den data som avses samlas är enhetsidentiteten och antingen de uppmätta mätvärdena eller de slutgiltiga koordinaterna, beroende på var i systemet beräkningen sker (mer om detta i avsnitt 3.6.1). I de avsnitt som följer beskrivs det programspråk som används för att kommunicera med databasen, det ramverk som underlättar databashanteringen, samt den plattform som möjliggör databasplacering i molnet.
2.4.3.1 Structured Query Language
Structured Query Language (SQL) är ett programspråk designat för att hantera data som finns
i databassystem. Den datahantering som förfrågor med SQL möjliggör är infogning, hämtning, uppdatering samt radering [16]. Figur 2.4 illustrerar den förfrågandeprocess som sker mellan en användare och en databas. Det förfråganderesultat som returneras, precis som de tabeller där data placeras i och hämtas ifrån, är listor av rader.
2.4.3.2 Entity Framework
Entity Framwork är ett ramverk utvecklat av Microsoft som sammankopplar data med domänbaserade objekt och egenskaper. Ramverket kan översätta operationer för dataåtkomst mot objekten och deras egenskaper till ekvivalenta databasåtgärder. Detta möjliggör att databashanteringen kan abstraheras ut ur programkoden, så att en utvecklare ej behöver bekymra sig om de databastabeller där den lagrade datan finns; utvecklaren agerar då istället främst mot en konceptuell modell av den aktuella databasen [17].
Entity Framwork kan användas på tre olika sätt, vilket illustreras i Figur 2.5: för att skapa dataåtkomstklasser för interagering med en redan existerande databas, för att skapa en databas utifrån domänklasser, och för att skapa en databas och relevanta klasser utifrån en designad databasmodell.
2.4.3.3 Microsoft Azure
Tanken är att hantera SQL-databasen genom Microsoft Azure [18] som erbjuder en samling integrerade molntjänster. Azure möjliggör att skapa och hantera sådana databaser i molnet över en webbportal (se Figur 2.6) eller direkt genom en utvecklingsmiljö. Andra exempel på populära Azure-tjänster är applikationsutveckling för mobila och webbaserade lösningar, samt molndistribuering av avbildningar för virtuella maskiner [19].
Figur 2.6: Microsoft Azure Webbportal
2.4.4 Visningsklient
Visningsklienten ämnar hämta den data som finns samlad i databasen, och uppskatta var på ytan träffen skett utifrån denna (se bilaga A.2.2). Denna information ska presenteras överskådligt och korrekt för användaren. Utöver träffvisualisering ska visningsklienten även beräkna och överskådligt visualisera resultat utifrån dessa träffar.
har i syfte att erbjuda en konsekvent programmeringsmodell för applikationsskapande, och separerar användargränssnittet från den logik [21] som styr hur data skapas, visas upp, lagras och ändras. Genom att skilja en kontrolls logik från dess utseende kan dess gränsnitt ändras radikalt utan att dess uppförande påverkas.
2.5 Utvecklingsmiljö
Sogeti har begärt att projektets utvecklingsmiljö, om möjligt, ska vara Visual Studio 2015 [22], som är en utvecklingsmiljö framtagen av Microsoft. Denna miljö erbjuder verktyg för att designa bland annat applikationsgränssnitt, webbmiljöer samt databasdiagram, och stödjer olika typer av programmeringsspråk, som till exempel C# [23]. Visual Studio underlättar för programmerare på olika sätt, till exempel genom så kallad syntaxmarkering, som möjliggör att olika delar av källkoden skrivs ut i olika färger, och kodkomplettering, som ger förslag på möjliga variabler och metoder som kan användas. Genom att tillämpa bakgrundskompilering kan miljön ge en programmerare omedelbar återkoppling huruvida dennes kod genererar fel eller varningar redan när den skrivs, vilket visualiseras genom röda respektive gröna markeringslinjer under koden i fråga.
Den utgåva av Visual Studio som kommer att användas kallas Community, en gratisupplaga speciellt riktad mot enskilda utvecklare eller små arbetslag, med funktionalitet som liknar den professionellautgåvan Visual Studio Professional.
2.6 Kapitelsammanfattning
Det här kapitlet har beskrivit uppdragsgivaren Sogeti, det projektuppdrag kring elektroniska skyttesystem som denne tagit fram, samt den problemformulering som återfinns i projektets kravspecifikation (se bilaga A). I problemformuleringen vill uppdragsgivaren undersöka om det är möjligt att utveckla ett mindre kostsamt system; i brist på detta vill uppdragsgivaren veta hur hög precision som kan uppnås och vilken utrustning som behövs för att optimera systemet.
Därefter beskrevs systemets komponenter. Detta innefattade systemets mikrofonkomponenter, av märket SparkFun Sound Detector. Mikrofonerna har i uppgift att registrera träffar, vars ljudankomster används för att mäta deras tidsintervall. Med en så kallad multilaterationsberäkning approximeras träffens position med hjälp av de uppmätta
tidsintervallerna. En Raspberry-enhet, som på inrådan av uppdragsgivaren använder en IoT-version av operativsystemet Windows 10, avser samla in mätvärden från mikrofonerna. Dess precision befaras av uppdragsgivaren vara undermålig, och således befaras en så kallad
Time-to-Digital-omvandlare vara nödvändig för ökad systemprecision.
Raspberry-enheten avser skicka vidare relevant data till en databas. Databasen använder sig av SQL för att hantera data däri genom relevanta förfrågor. Kommunikation till denna databas hanteras genom ramverket Entity Framework, som möjliggör att en utvecklare agerar mot en konceptuell modell av databasen istället för hårdkodade SQL-förfrågor. Denna databas är tänkt att hanteras som en molntjänst genom Microsofts Azureportal. Därefter följde en beskrivning av systemets visningsklient, som utvecklas som en WPF-applikation. Visningsklienten avser hantera datan i databasen och presentera den överskådligt för en användare. Även utvecklingsmiljön Visual Studio 2015 Community beskrivs, som används för att utveckla systemets applikationer.
3 Design
Detta kapitel avser beskriva systemets övergripande design. Kortfattade beskrivningar av systemets fysiska komponenter följer; dessa beskrivs mer utförligt i rapporten författad av Niklas Ivarsson [1]. Därefter beskrivs systemets databas, den data som den ämnar innehålla, systemets visningsklient, samt den testapplikation som utvecklats för att simulera träffvärden i syfte att testa visningsklienten.
3.1 Systemets övergripande design
Den övergripande designen för det elektroniska skyttesystemet ser ut som illustrerat i Figur 3.1. Flera mikrofoner monteras på en träffyta med uppgiften att registrera träffljud. Ankomsttider för dessa träffljud ska tas emot av en Raspberry Pi 2-enhet, som även måste veta i vilken ordning de olika mikrofonerna tog emot ljudankomsten. Denna Raspberry-enhet ska i sin tur räkna ut en träffposition utifrån denna mätdata, och sedan skicka relevant information till en databas i molnet. En visningsklient ska sedan hämta denna data, utifrån vilken resultat beräknas och visualiseras i ett användargränssnitt. Även själva träffarna bör visas upp i en träffyta i användargränssnittet, liknande den en användare skjuter mot.
3.2 Mikrofoner
De mikrofoner som används i systemet är fyra stycken SparkFun Sound Detectors. Dessa komponenter valdes av Sogeti utifrån deras mindre kostnad (de kostar runt $11 styck [7]). Figur 3.2 illustrerar en sådan mikrofon. De röd- och gulmarkerade portarna hanterar komponentens strömförsörjning respektive dess grundnivå (även kallad jord). På mikrofonens grönmarkerade port finns möjligheten att få ut en binär signal då en ljudankomst registrerats. De binära signalerna från samtliga fyra mikrofoner avses tas emot av Raspberry-enheten tillsammans med den identitet tillhörande den mikrofon som skickade respektive signal.
Figur 3.2: Mikrofon med markerade portar
3.3 Raspberry-enhet
En Raspberry-enhet ska med hjälp av en Universal Windows Platform-applikation (UWP) [24] ta emot binära signaler från mikrofonkomponenterna. Dessa signaler används för att bestämma de olika tidsintervallen för mikrofonernas ljudankomster. Genom multilaterationsberäkning omvandlas dessa tidsintervall till approximerade x- och y-koordinater för en träff i träffytan. Raspberry-enheten skickar slutligen relevant data till databasen genom ett Application Programming Interface (API) [25].
3.4 Application Programming Interface
API:t hanterar kommunikationen mellan Raspberry-enheten och databasen. Detta krävs på grund av att UWP inte kan ställa SQL-förfrågor, utan måste istället kommunicera genom
Hypertext Transfer Protocol (HTTP) [26]. API:t översätter därför denna
HTTP-kommunikation till SQL-förfrågor mot databasen.
3.5 Databas
Systemets databas har i uppgift att lagra viss data från Raspberry-enheten, som sedan ska hämtas ut av visningsklienten. Några förslag på hur denna databas skulle kunna hanteras gavs av Sogeti. Den skulle antingen kunna utnyttjas som en molntjänst genom Microsoft Azure, eller som en lokal lösning med hjälp av SQLite. I följande avsnitt jämförs för- och nackdelar mellan de olika lösningarna, vilket följs av ett avsnitt som beskriver kommunikationen med databasen genom ramverket Entity Framework.
3.5.1 Molnlösning kontra SQLite
SQLite är en serverlös open source-lösning som erbjuder databashantering direkt mot vanliga diskfiler. Dessa diskfiler innehåller databasens tabeller, som läs- och skrivoperationer kan utföras mot direkt i en applikation utan att behöva förlita sig på en separat serverprocess [27]. Fördelen med molntjänstlösningen är att den är skalbar och att jämlöpande skrivoperationer utförda av flera klienter är möjligt. Detta är önskvärt då funktionalitet för flera enheter önskas (se bilaga A.2.4.3). En nackdel med denna lösning är svårigheten att skapa den i Azureportalen, eftersom en Azure-prenumeration behövs för att komma åt portalen och brandväggsregler behöver sättas upp för de IP-adresser som behöver åtkomst till databasen. En annan nackdel är att en Internetuppkoppling krävs för att kunna skicka in och hämta data i databasen. Några fördelar med den lokala SQLite-lösningen är att databasen är lätt att sätta upp, samt att den passar IoT-enheter då den ej behöver administreras. Nackdelar med denna lösning är storleken på disken som den lokala filen kräver (och som även kan hämmas om den har en viss bestämd storleksgräns), de instanser som behöver kommunicera med databasen är fastlåsta till enheten den är lagrad på, samt att jämlöpande skrivoperationer av flera användare ej är möjliga [28].
I slutändan valdes molnlösningen för detta projekt. Att jämlöpande skrivoperationer är möjliga ansågs vara nödvändigt om flera enheter implementeras. Att en molntjänst är en
kommersiell lösning som kan anses strida mot systemets lågkostnadsmål så är en sådan lösning i slutändan skalbar; man betalar således endast för vad som behöver användas. Det kan även vara värt att notera att uppdragsgivaren Sogeti vanligtvis använder sig av sådana lösningar.
3.5.2 Databaskommunikation genom ramverket Entity Framework
Kommunikationen med databasen utförs genom SQL-förfrågor från Raspberry-enheten och visningsklienten. Med hjälp av ramverket Entity Framework är det möjligt att abstrahera bort hårdkodade sådana förfrågor direkt i applikationskoden och ersätta dessa med objektorienterade metodanrop.
Till att börja med så skapas en så kallad Entity Data Model, som är en slags beskrivning av en datastruktur, utifrån den existerande databasen. En kontextklass skapas, härledd utifrån en så kallad DbContext [29], illustrerad i Figur 3.3. DbContext är bryggan mellan applikationens entitetsklasser och databaser; den innehåller den mängd databasentiteter som en utvecklare väljer att hantera i applikationen, den översätter Linq-to-Entities-förfrågor [30] (den metod som används för att utföra förfrågor mot Entity Framework) till SQL-förfrågor, och möjliggör att operationer kan utföra och spara ändringar i databasen. Även entitetsklasser skapas, utifrån de databastabeller som avses hanteras i applikationen, med tillhörande get- och set-metoder till deras egenskaper.
Genom att i applikationen skapa en ny instans av kontextklassen så sätts en uppkoppling till databasen upp. Ett sätt att utföra detta är att använda using-satser där de behövs, istället för att sätta upp en global uppkoppling till databasen och sedan behålla denna under hela applikationens exekvering. Detta leder till att uppkopplingsobjekten får ett mindre omfång, och vid vars ände objekten automatiskt släpps utan att en Dispose-metod behöver kallas. I samband med att modellen skapas måste en utvecklare välja datauppkoppling till server och databas. Inloggningsuppgifter måste därför anges, och utvecklaren får möjlighet att välja om dessa uppgifter ska skickas med i uppkopplingssträngen som används för att koppla upp sig mot databasen, eller i själva applikationen. Utvecklaren förvarnas att medskick av sådan känslig information i uppkopplingssträngen är en säkerhetsrisk. I detta projekt valdes att skicka med inloggningsuppgifterna i uppkopplingssträngen; en användare behöver således
Figur 3.3: DbContext illustrerad [29]
3.6 Data
Detta avsnitt avser beskriva den data som från träffytan hanteras i Raspberry-enheten, och därefter den data som sparas i databasen.
3.6.1 Mätdata
Den mätdata som kommer från träffytan och dess mikrofoner är träffljudets ankomsttider till de olika mikrofonerna, samt deras mikrofonidentitet. Denna data kan ge en uppskattad träffposition, i och med att den mikrofon som befinner sig närmast träffen får en ankomsttid noll, följt av de ankomsttider till de mikrofoner som befinner sig på ett ökande avstånd från träffen. Mätdatan ska i något skede av processen användas för att räkna ut träffens x- och y-koordinater på träffytan.
Denna beräkning kan antingen ske i Raspberry-enheten eller i visningsklienten. Fördelarna med att sköta beräkningen i Raspberry-enheten är att redan beräknad data kan placeras i databasen, vars innehåll då blir mer lätthanterlig än om både ankomsttider och mikrofonidentiteter placeras däri. Systemet skulle då lättare kunna hantera flera träffytor med tillhörande Raspberry-enheter som önskat (se bilaga A.2.4.3), eftersom varje enhet sköter sin egen beräkning och underlättar därigenom för visningsklienten. En nackdel är att varje Raspberry-enhet då utför ytterligare arbete än om de endast behöver spara inhämtad mätdata i databasen. En fördel med att sköta beräkningen i visningsklienten är att Raspberry-enheten kan agera effektivare, eftersom den endast behöver skicka den mätdata som tas fram direkt till
databasen. Nackdelarna med denna lösning är att databasen behöver hantera mer data, samt att visningsklienten behöver utföra samma beräkning för flera enheter.
I detta projekt valdes lösningen där beräkningen sker i Raspberry-enheten; visningsklienten behöver således endast hantera färdig data från en eller flera implementerade enheter.
3.6.2 Databasdata
Figur 3.4 illustrerar den data som, genom Raspberry-enheten, hamnar i databasen. Utifrån mätdatan bestående av mikrofonernas ljudankomsttider samt identiteter ska data tas fram som ska skickas vidare till systemets databas. Denna data ska bestå av träffens x- och y-koordinater på träffytan, Raspberry-enhetens identitet samt vilket nummer träffen får i träffserien. Databasens primärnyckel måste bestå av både träffnummer och enhetsidentiteten, på grund av att flera enheter ska ha möjlighet att kunna registrera värden från sina skjutserier; de olika enheterna kan komma att dela träffnummervärden, vilket medföljer att identiteten även måste vara kopplad till primärnyckeln för att denna ska vara unik. En tabellrad bestående av dessa värden skickas sedan in i molndatabasen.
Figur 3.4: Övergripande bild av data till databas genom en Raspberry-enhet
3.7 Visningsklient
Detta avsnitt ämnar beskriva visningsklientens användargränssnitt, bakgrundsfunktionalitet, och hur hämntningen av databasdata sker.
3.7.1 Användargränssnitt
används för att lista de beräknade träffresultaten. En mindre Text Box används för att skriva ut det medelvärdesresultat användaren fått från sina träffar. Denna Text Box ska användaren själv ej ha möjlighet att skriva i, så att innehållet endast ändras när medelvärdesresultatet uppdateras utifrån ytterligare träffar.
Visningsklientens användargränssnitt är grafiskt designad i utvecklingsmiljön Visual Studio med hjälp av den designer som subsystemet WPF erbjuder (se Figur 3.6). I denna lösning har man möjlighet att utveckla visningsklientens användargränssnitt genom att skapa och placera komponenter så som knappar, etiketter och boxar av olika slag i designvyn (på engelska
design view) ur en verktygslåda (toolbox). Funktionalitet och egenskaper för dessa
komponenter kan sedan påverkas i ett egenskapsfönster (properties window). Man har även möjlighet att i WPF-lösningar utnyttja något som kallas Extensible Application Markup
Language (XAML) [31], vilket är en XML-baserad språklösning för att initialisera och
definiera objekt i användargränssnittet från en egen ruta (XAML view). En utvecklare kan således skriva kod i XAML-vyn för att påverka en WPF-applikationens visuella utseende utöver det som erbjuds från verktygslådekomponenter och deras egenskaper.
Figur 3.5: Illustration av visningsklientens användargränssnittsdesign
3.7.2 Övergripande bakgrundsfunktionalitet
Visningsklientens bakgrundsfunktionalitet består i huvudsak av fyra klasser (se Figur 3.7): En kontextklass sätter upp och hanterar kommunikationen med databasen och datan
däri. Denna klass genereras utifrån databasen genom implementation av Entity Framework.
En träffklass innehåller get- och set-metoder till variablerna enhetsID, träffnummer, samt x- och y-position från de respektive kolumner som databasen innehåller. Även denna klass genereras utifrån databasen genom implementation av Entity Framework. En datahanteringsklass använder instanser av kontextklassen för att koppla
applikationens logik med databasen och dess innehåll. Klassen innehåller metoder för att beräkna träff- och medelvärdesresultat utifrån data i databasen, samt metoder för att hämta ut och skicka vidare denna data.
En vyklass innehåller de metoder som skapar och visualiserar träffcirklar på användargränssnittets träffyta, samt de metoder som skriver ut de olika resultaten i användargränssnittets designerade rutor.
Visningsklientens bakgrundsfunktionalitet utvecklades under projektets gång från en version som förlitade sig mer på kommunikation med databasen genom ramverket Entity Framework för att hantera dess data, till en version som allt mindre förlitade sig på denna kommunikation genom att spara ner all data i databasen och hantera denna mer lokalt. Båda dessa lösningar har fördelar och nackdelar. Den tidigare lösningen funger utmärkt om visningsklienten avser uppdateras för varje individuell träff; det finns då mindre anledning att hämta ner och lägga in allt databasinnehåll i en lista för varje sådan träff. Med denna tidigare lösning så tar datahämtning och beräkning lite längre tid då databasen måste kontaktas flera gånger per träff, men denna fördröjning mellan träff och visualiserat resultat är försumbar för bearbetning av endast en träff åt gången. Om istället flera träffar i följd ska beräknas och visualiseras mellan uppdateringstillfällena så är däremot den senare lösningen mer effektiv, både tidsmässigt och ur kodperspektiv. Flera metoder som krävs i den tidigare lösningen kan refaktoriseras bort ur den senare lösningen eftersom deras funktionalitet kan utföras direkt
Figur 3.7: Illustration av visningsklientens klasser i dess bakgrundsfunktionalitet
3.7.2.1 Ramverksbaserad bakgrundsfunktionalitet
Denna tidigare lösning för visningsklientens bakgrundsfunktionalitet baserade kommunikationen med databasen och dess data utifrån flera metoder innehållande implementation av ramverket Entity Framework. Flera aspekter av denna ramverksbaserade bakgrundsfunktionalitet användes i den fristående testapplikationen (se avsnitt 3.8), som kan simulera träffar för att testa visningsklienten.
En metod i datahanteringsklassen behövde anropas i samband med att applikationen initialiserades med uppgiften att tömma databasen. All data däri behövde tas bort, som försäkring att inga tidigare existerande värden befann sig där som kunde påverka resultatberäkning och träffvisualisering negativt. När så applikationen startas så gör den det med en tom databas och träffyta, och är precis som ett riktigt system redo för en ny träffserie från en användare.
En metod för beräkning av resultat för varje träff krävdes i datahanteringsklassen, som anropades i vyklassen när en uppdatering av användargränssnittet skedde. Detta träffresultat behövdes för de enskilda, beräknade resultaten som skrevs ut i användargränssnittet. I denna metod adderades även det beräknade träffresultatet in i en klassegenskapsvariabel som representerade det totala resultatet för alla träffar i träffserien. Detta totala resultat behövdes sedan när medelresultatet för samtliga träffar beräknades.
För varje enskild träff behövdes dess x- och y-koordinater hämtas ut ur databasen, vilket krävde en metod vardera i datahanteringsklassen för att utföra denna uppgift och returnera koordinaterna de hittade.
När ett träffresultat beräknats i datahanteringsklassen returnerades det ut till vyklassen, som skickade resultatet som en parameter till en metod med uppgiften att skriva ut det i den List Box som befann sig i användargränssnittet. Det totala resultatet skickades som en parameter till en metod som räknade ut det medelresultat som träffserien genererat. Även detta resultat returnerades till vyklassen, för att i en metod skrivas ut i den Text Box som befann sig i användargränssnittet.
En metod i vyklassen skapade en träffellips i användargränssnittets träffyta utifrån en träffs x- och y-koordinater. För att placera träffellipsen rätt på användargränssnittets träffyta behövde dessa koordinater på nytt hämtas ut från databasen genom att anropa de metoder som skötte detta. När träffellipsen fått rätt värden bestämdes dess storlek och färg, och lades sedan till i användargränssnittets träffyta.
Allt detta behövde ske för varje individuell träff i databasen då den anlänt däri. Applikationen måste således kunna uppfatta att en ändring skett i databasen och reagera på detta. Implementation utav sådan funktionalitet visade sig dock vara för tidskrävande; mer om detta i avsnitt 3.7.3.
Härnäst följer en mer ingående beskrivning av först den ramverksbaserade bakgrundsfunktionalitetens vyklassmetoder följt av dess datahanteringsklassmetoder, illustrerade i Figur 3.8 (a respektive b).
(a) (b)
Figur 3.8: Visningsklientens illustrerade vyklassmetoder och ramverksbaserade datahanteringsklassmetoder
visualizeScoreInListBox
Denna metod i vyklassen lade in det beräknade träffresultatet överst i användargränssnittets List Box. Därigenom befann sig alltid det senaste träffresultatet överst i den visualiserade träffserien.
visualizeAverageScoreInTextBox
Denna metod i vyklassen skrev ut det beräknade medelresultatet för alla träffar som en sträng i användargränssnittets Text Box.
visualizeShot
Denna metod i vyklassen skapade träffellipser utifrån de värden som fanns att hämta i databasen. Träffens x- och y-koordinater returnerades till denna metod genom anrop till ett par metoder i datahanteringsklassen med uppgift att hämta ut denna data ur databasen, som därefter tilldelades träffellipsen. När sedan träffellipsens höjd, bredd och färg hade tilldelats antagna värden så kunde träffellipsen till slut läggas till i användargränssnittets träffyta. visualizeAverageShot
Denna metod i vyklassen skapade en träffellips utifrån de övriga träffarna. Träffens x- och y-koordinater returnerades efter att ett par metoder i datahanteringsklassen anropats, vars uppgifter var att beräkna medelvärdet av alla träffars x- respektive y-koordinater. Dessa värden tilldelades sedan träffellipsen, tillsammans med antagna värden för höjd, bredd och färg (denna färg skilde sig från övriga träffar). När detta hade bestämts så kunde träffen till slut läggas till i användargränssnittets träffyta.
clearDB
Denna metod i datahanteringsklassen tog bort alla gamla träffar i databasen, och sparade denna ändring i databasen. Denna metod anropades i samband med att applikationen startades; detta var nödvändigt för att starta visningsklienten tom från gamla skräpvärden som kunde påverka beräkning av träffantal negativt, och gjorde den redo att ta emot nya träffserier från användare.
calculateScore
Denna metod i datahanteringsklassen räknade ut det resultat som den senaste träffen givit. Mittkoordinater för användargränssnittets träffyta i x- och y-led, samt två variabler för deltavärden för x och y definierades. Metoden beräknade det avstånd mellan träffytans mittpunkt i x-led och träffens x-koordinat, samt det avstånd mellan mittpunkten i y-led och
träffens y-koordinat, och tilldelade deltavärdena dessa beräknade avstånd. Avståndet mellan träffen och träffytans mittpunkt kunde beräknas med hjälp av Pythagoras sats utifrån de beräknade deltavärdena:
√
Avståndet subtraherades sedan från maxresultatet i träffytan (som i detta projekt var tio), vilket gav ett lägre resultat desto längre ifrån träffytans mittpunkt som träffen befann sig. Klassegenskapsvariabeln innehållande totalresultatet för alla träffar adderades med träffens resultat, innan träffresultatet returnerades.
calculateAverageScore
Denna metod i datahanteringsklassen hade i uppgift att beräkna det medelvärde som alla träffar givit. Detta utfördes genom att dividera det totala resultatet för alla träffar med antalet träffar i serien. Det totala resultatet fanns sparat i den klassegenskapsvariabel avsedd för denna uppgift, och antalet träffar hämtades ut ur databasen utifrån den senaste träffens träffnummervärde.
calculateAverageXPosition & calculateAverageYPosition
Dessa metoder i datahanteringsklassen hade i uppgift att beräkna medelvärdet av x- och koordinater hos alla träffar i databasen. För varje träff däri hämtades dess x- respektive y-koordinat ut med hjälp av den get-metod som befann sig i träffklassen, och y-koordinaterna adderades ihop. Metoden returnerade dessa adderade värden dividerat med antalet träffar i databasen, utifrån den klassegenskapsvariabel som höll reda på detta.
getLastShotXPosition & getLastShotYPosition
Dessa metoder i testapplikationens datahanteringsklass hade i uppgift att hämta ut den senaste träffens x- respektive y-koordinat och returnera dem. Eftersom Last-metoden, som har i uppgift att returnera den sista entiteten i en sekvens, inte stöds av Linq-to-Entities-förfrågor så behövde man ordna databasen i nedåtgående ordning och sedan välja ut den första entiteten i denna ordnade sekvens med en First-metod.
funktionalitet för att uppdatera visningsklienten vid databasändringar var för tidskrävande (se avsnitt 3.7.3) behövde ett alternativ tas fram.
En ny lösning togs fram, som hämtar ner alla träffar i databasen och lägger in dessa i en lista varje gång en användarstyrd uppdatering sker. Detta medföljer att värdeshanteringen istället för att vara fullt kopplad med databasen nu sker på lokalt hämtade värden. Träffarna kan direkt skickas utifrån listan som argument till metoder, vilket leder till att deras värden kan hämtas och sättas med hjälp av de definierade get- och set-metoder som finns i träffklassen. Detta ledde till att några metoder kunde refaktoriseras bort då deras funktionalitet effektivare kunde utnyttjas direkt på medskickade objekt och värden. De metoder som visningsklienten består av beskrivs i följande avsnitt, där dess metoder i vyklassen illustrerade i Figur 3.8 (a) följs av de som befinner sig i dess datahanteringsklass (se Figur 3.9).
Figur 3.9: Den listbaserade visningsklientens illustrerade datahanteringsklassmetoder
visualizeScoreInListBox, visualizeAverageInTextBox & visualizeAverageShot
Dessa metoder återfinns i visningsklientens vyklass, och de behåller den funktionalitet som tidigare beskrivits (se avsnitt 3.5.2.1).
visualizeShot
Denna metod i vyklassen behåller sin tidigare funktionalitet (se avsnitt 3.5.2.1), med några förändringar. En träffparameter tas emot av funktionen, och det är utifrån denna medskickade träff som den visualiserade träffens x- och y-koordinater hämtas och tilldelas.
clearDB
Denna metod i datahanteringsklassen behåller den funktionalitet som tidigare beskrivits (se avsnitt 3.5.2.1).
loadDBShotsIntoList
Denna metod i datahanteringsklassen skapar en ny instans av listan som träffarna läggs in i. Metoden tilldelar även en träffräknare värdet noll, samt nollställer totalresultatet för träffserien. För varje träff i databasen läggs sedan träffen in i listan, dess värden sätts med hjälp av set-metoderna i träffklassen till de värden som återfinns i databasen, och räknaren inkrementeras. Denna räknare kan sedan användas för att utreda hur många träffar som finns i listan.
calculateScore
Denna metod i datahanteringsklassen behåller den funktionalitet som tidigare beskrivits (se avsnitt 3.5.2.1), med några förändringar. Som parameter tar den här metoden emot en träff, utifrån vilken de x- och y-koordinater som används vid beräkning hämtas ut ifrån. Denna metod behöver då inte längre uppsöka den senaste träffen i databasen och hämta ut dess x - och y-koordinater, vilket behövdes i den tidigare ramverksbaserade lösningen.
calculateAverageScore
Denna metod i datahanteringsklassen behåller den funktionalitet som tidigare beskrivits (se avsnitt 3.5.2.1); metoden får dock träffantalet genom den klassegenskapsvariabel med uppgift att hålla reda på detta antal, istället för att som i den tidigare lösningen hämta ut den senaste träffens nummer i träffordningen.
calculateAverageXPosition & calculateAverageYPosition
Dessa metoder i datahanteringsklassen behåller den funktionalitet som tidigare beskrivits (se avsnitt 3.5.2.1), med några förändringar. Istället för att hämta x- respektive y-koordinater från alla träffar i databasen utförs detta mot alla träffar i listan med hjälp av de get-metoder som befinner sig i träffklassen. Dessa koordinatvärden adderas ihop, och metoderna returnerar dessa värden dividerat med antal träffar i listan, som går att återfinna i den klassegenskapsvariabel med uppgift att hålla reda på detta.
3.7.3 Hämtning av data från databasen
Hämtning av databasdata vore idealisk om denna kunde ske i samband med att varje träff anländer i databasen. För att detta ska vara möjligt så måste databasändringar registreras och
Tekniken SignalR sätter upp ett bakplan (på engelska backplane), som tar emot och vidarebefordrar meddelanden från och till varje applikationsinstans. Varje sådant meddelande skickas genom en meddelandebuss med en publish/subscribe-mekanism designad för bakplanet; serverinstanser kopplas sedan till bakplanet genom denna buss. När meddelanden sedan avses skickas till servern hamnar det istället först i bakplanet, som har möjlighet att skicka vidare meddelandet till alla eventuella serverinstanser. När en server således tar emot ett meddelande från bakplanet placeras det i serverns lokala cache-minne, varifrån meddelanden sedan levereras till klienter [33].
Ett relevant användningsområde med SignalR-implementation att jämföra önskad funktionalitet med är chattapplikationer; en sådan applikation kan utnyttja publish/subscribe-kommunikation mellan två eller flera klientapplikationer genom en serverinstans. Ett meddelande från en klient når och lagras således i databasen, som har möjlighet att publicera att en ändring i dess innehåll har skett. Övriga klienter som prenumererar på relevanta händelser i databasen har då möjlighet att ta emot meddelanden från servern och uppdatera sina användargränssnitt därefter. En snarlik lösning för applikationen i Raspberry-enheten, databasen och visningsklienten hade varit önskvärd, men på grund av projekttidsbrist hann en sådan implementation inte tas fram. Således fick visningsklienten fungera utifrån en alternativ lösning.
I nuläget uppdaterar visningsklienten istället sitt användargränssnitt med hämtad databasdata utifrån manuell uppdatering. Genom att en användare trycker på en knapp i användargränssnittet så hämtas all databasdata till visningsklienten och läggs in i en lista. De funktioner som sedan behöver denna data för beräkning och visualisering kommunicerar följaktligen med denna lokala lista.
Detta möjliggör beräkning och visualisering av flera träffar i följd. Med den ramverksbaserade lösningen var sådan följduppdatering möjlig, men den krävde upprepad kommunikation med molndatabasen för att hämta x- och y-koordinater för varje träff, samt för att returnera den sista träffens nummer i träffordningen; detta var nödvändigt för att veta hur många träffar som behövde beräknas och visualiseras. Eftersom åtkomst till databasen är skild från vyklassen måste således flera metoder i datahanteringsklassen med möjlighet att hämta databasdata anropas därifrån så att relevanta värden kan returneras.
3.8 Träffsimulering
För att kunna visualisera träffar och beräknade värden i visningsklienten behöver data som ska hämtas ur databasen faktiskt finnas där. En fristående testapplikation togs därför fram för att simulera träffar så att funktionaliteten kring dem kan testas i visningsklienten. Testapplikationens syfte är därmed att skapa de databasentiteter som visningsklienten sedan kan hämta genom manuell användaruppdatering.
Testapplikationen liknar visningsklienten, både i användargränssnitt och bakgrundsfunktionalitet (se Figur 3.10). Den skiljer sig dock i att en användare med hjälp av muspekaren kan skapa träffar i användargränssnittets träffyta; för att tydliggöra detta skiftar muspekarikonen till ett kors när denna befinner sig inom träffytan. För varje träff som skapas skickas dess värden in i databasen, där de sedan hämtas tillbaka för att beräknas och visualiseras. Denna händelsekedja visar att inlägg och uthämtning av data i och ur databasen är möjlig och fungerar korrekt.
Testapplikationen motsvarar den tidigare ramverksbaserade visningsklientlösningen. Eftersom uppdateringen i testapplikationen sker för varje träff så ansågs det inte finnas någon anledning att hämta ner alla databasvärden i en lista varje gång uppdateringen sker; testapplikationen arbetar således direkt mot databasen. Testapplikationen blir då lite långsammare, särskilt om en serie träffar simuleras i snabb följd, men eftersom applikationen är fristående från visningsklienten och endast avsedd för träffsimulering i brist på riktiga värden ansågs detta försumbart.
Den ytterligare funktionalitet som skiljer testapplikationen åt från visningsklienten är att varje uppdatering sker när en användare trycker ner vänster musknapp då muspekaren befinner sig inom användargränssnittets träffyta. När en träff skapas däri sätts träffens x- och y-koordinater till de y-koordinater som muspekaren har vid träfftillfället; varje träff som simuleras skickas in i databasen med dessa värden samt enhetsidentitet och ett träffnummer enligt en räknare av antalet simulerade träffar. Eftersom testapplikationen precis som den ramverksbaserade visningsklienten räknar ut träffresultat för varje träff när den simuleras så behöver den möjlighet att hämta ut x- och y-koordinater för den senaste träffen, och därför återfinns två sådana metoder.
Figur 3.10: Illustration av visningsklient, testapplikation och databas
3.8.1 Testapplikationens vyklass
Testapplikationens vyklass har, precis som visningsklientens sådan, i uppgift att visualisera träffar och beräknade resultat. Skillnaden här är att användaren själv väljer var i användargränssnittets träffyta som träffarna placeras, genom att med muspekaren klicka inom träffytan. Dessa användarplacerade träffar ämnas sedan skickas in i databasen, med de koordinater och träffnummer som träffsimuleringen genererar.
Härnäst beskrivs testapplikationens vyklassmetoder.
3.8.1.1 visualizeScoreInListBox & visualizeAverageInTextBox
Dessa metoder i testapplikationens vyklass behåller den funktionalitet som tidigare beskrivits (se avsnitt 3.5.2.1).
3.8.1.2 createAndVisualizeShot
Denna metod i testapplikationens vyklass skapar och visualiserar de simulerade träffarna i sitt gränssnitt. Träffarnas x- och y-koordinater sätts till de värden som muspekarens position har
vid träfftillfället. En räknare i datahanteringsklassen inkrementeras varje gång en träff läggs till i användargränssnittet, för att hålla reda på det antal träffar som simuleras. Efter detta så skickas träffens x- och y-koordinater som argument i ett anrop till en metod i datahanteringsklassen som lägger till träffen i databasen.
3.8.2 Testapplikationens datahanteringsklass
Testapplikationens datahanteringsklass, liknande den datahanteringsklass som finns i visningsklienten, har i uppgift att tömma databasen, lägga till träffar i den, hämta ut nödvändiga värden utifrån den data däri och beräkna träffresultat.
Härnäst beskrivs datahanteringsklassens metoder.
3.8.2.1 clearDB
Denna metod i testapplikationens datahanteringsklass behåller den funktionalitet som tidigare beskrivits (se avsnitt 3.5.2.1).
3.8.2.2 insertShotIntoDB
Denna metod i testapplikationens datahanteringsklass har i uppgift att lägga till en träffentitet i databasen. Den tar emot träffens x- och y-koordinater som parametrar, och lägger till en träff med dessa värden samt en antagen enhetsidentitet med värdet ett och träffnummer enligt den räknare som inkrementeras när träffar simuleras i användargränssnittets träffyta. När en träff således har lagts in i databasen så sparas denna ändring.
3.8.2.3 getLastShotXPosition & getLastShotYPosition
Dessa metoder i testapplikationens datahanteringsklass behåller den funktionalitet som tidigare beskrivits (se respektive metoder i avsnitt 3.7.2.1).
3.8.2.4 calculateScore
3.8.2.5 calculateAverageScore
Denna metod i testapplikationens datahanteringsklass behåller den funktionalitet som tidigare beskrivits (se avsnitt 3.5.2.1); de värden som divideras är totalresultatet för alla träffar samt antal träffar i databasen. Båda dessa värden återfinns i klassegenskapsvariabler i datahanteringsklassen.
3.9 Kapitelsammanfattning
I detta kapitel har systemets övergripande design beskrivits och illustrerats, där dess systemkomponenter introducerats och deras respektive uppgifter angivits. Därefter följde en kort beskrivning av systemets fysiska komponenter, samt det API som hanterar kommunikationen mellan Raspberry-enheten och systemets databas. Ett avsnitt rörande denna databas följde, som beskrev hur en jämförelse mellan en molnlösning kontra en lokal sådan ledde till att databasen i detta projekt placerades i molnet, samt hur kommunikationen till och från den sker med hjälp av ramverket Entity Framework. Därefter beskrevs systemets olika data: först mätdatan från mikrofonkomponenterna och var den beräkning som utförs utifrån denna data utförs, samt den data som sparas i databasen. Ett avsnitt som beskrev systemets visningsklient följde, där dess användargränssnittsdesign illustrerades och den designer som används för att grafiskt designa användargränssnittet beskrevs. En beskrivning av visningsklientens övergripande bakgrundsfunktionalitet följde, vilket innefattade dess klasser och metoder. Avsnittet beskrev även hur en ramverksbaserad bakgrundsfunktionalitet som var en mer optimal lösning för automatisk datahämtning och användargränssnittsuppdatering ersattes av en listbaserad bakgrundsfunktionalitetslösning då visningsklienten fick sköta hämtning och uppdatering utifrån manuell användarinput när implementering av tekniken SignalR ansågs alltför tidskrävande. Avsnittet följdes av ett avsnitt beskrivande den utvecklade testapplikation, med funktionalitet motsvarande den ramverksbaserade sådan för visningsklienten, som avser simulera träffar som sparas i systemets databas. Således kan visningsklienten testas genom att hämta, beräkna och visualisera träffar och resultat utifrån denna sparade data.
4 Implementation
Det här kapitlet ämnar beskriva genom bilder och text hur en SQL-server och databas sätts upp i Azureportalen, hur visningsklientens alla beståndsdelar skapas och implementeras, samt kodutseende och funktionalitet för visningsklientens och testapplikationens olika klasser.
4.1 Azure SQL-server & databas
För att få tillgång till Azureportalen och därefter sätta upp en SQL-server och databas krävs en Azure-prenumeration kopplad till ett Microsoftkonto. I detta projekt var det möjligt att skapa en sådan med hjälp av Microsoft DreamSpark Premium [34], som erbjuds studenter inom STEM-institutioner (Science, Technology, Engineering och Math) vid Karlstads Universitet.
I samband med att man skapar en databas kan man välja att skapa en ny Azure SQL-server eller använda en redan befintlig sådan. Om man väljer att skapa en ny server så får skaparen möjlighet att välja de inloggningsuppgifter som senare kommer användas för att komma åt servern och databasen i utvecklingsmiljön.
Det sista som behöver utföras i Azureportalen när väl SQL-servern är skapad är att lägga till den aktuella IP-adressen i serverns brandväggsregler. Om inte detta utförs kommer applikationen att nekas åtkomst till servern och dess databaser. Figur 4.1 illustrerar var man kan hitta denna inställning; i den skapade databasens flik klickar man först på servernamnet, och väljer i dess flik sedan antingen Visa brandväggsinställningar, eller Alla inställningar och sedan Brandvägg. Man har där möjlighet att lägga till nya klient-IP-adresser, vilket måste utföras för varje ny adress som behöver åtkomst till databas och server.
4.2 Utvecklingsmiljöns databasdesigner
För att påverka databasen inuti utvecklingsmiljön måste först SQL-servern kopplas samman med denna. Servern behöver läggas till i utvecklingsmiljöns utforskare SQL Server Object
Explorer; för att göra detta behövs dess servernamn och inloggningsuppgifter.
När servern har lagts till och databasen kan hittas i utforskaren kan en utvecklare skapa en ny databastabell i denna genom att högerklicka på undermappen Tables och välja alternativet
Lägg Till Ny Tabell. Detta laddar då en databasdesigner, där utvecklaren lätt kan skapa namn
och typ för den data som tabellen ska innehålla. Figur 4.2 (a) illustrerar databastabellen shots för de träffar som läggs in i och hämtas ut ur databasen. Id är den enhetsidentitet som en Raspberry-enhet blivit tilldelad. ShotNum är en träffs ordning i träffserien. Dessa två värden sätts som primärnycklar genom att klicka i rutan till vänster om namnen, och tilldelas datatypen integer i rutan till höger om namnen. xPos och yPos är de x- och y-koordinater en träff får på träffytan, och de tilldelas datatypen float. För att spara tabellen i databasen måste utvecklaren trycka på Update-knappen som befinner sig i övre vänstra hörnet av designern, ovanför namnkolumnen. Figur 4.2 (b) illustrerar resultatet i utforskaren, där databastabellen shots med dess tillhörande kolumner ligger tillagd i databasen ElectronicMarking.
(a) (b)
Figur 4.2: Utvecklingsmiljöns databasdesigner för databastabellen shots, samt databastabellen shots i utvecklingsmiljöns utforskare
4.3 Visningsklient
Visningsklienten skapas i utvecklingsmiljön som ett WPF-projekt. Visningsklienten består av ett användargränssnitt och fyra klasser i bakgrundsfunktionaliteten. Detta avsnitt avser beskriva dessa komponenter och hur de implementeras.
4.3.1 Ramverksimplementation
Två av visningsklientens klasser, träffklassen Shot och kontextklassen Context, skapas utifrån databasen då ramverket Entity Framework implementeras. För att implementera ramverket i projektet så behövs en ny programdel ADO.NET Data Entity Model (se avsnitt 3.3.2) läggas till. Modellen sätts upp som en Code First-lösning, vilket ser till att klasser i modellen skapas utifrån den redan existerande databasen. En utvecklare får då möjlighet att välja databasuppkoppling, modellinställningar och vilka databasobjekt som inkluderas i modellen. I samband med att uppkopplingen till databasen sätts upp behöver utvecklaren förse de inloggningsuppgifter som angetts när servern skapades i Azureportalen. Dessa inloggningsuppgifter krävs för att koppla visningsklienten till databasen, och utvecklaren kan sedan välja att skicka med dessa i den uppkopplingsträng som skapas i slutet av ramverksimplementationen, eller om de ska förses på annat sätt i själva applikationen. I detta projekt gjordes antagandet att skicka med uppgifterna i uppkopplingssträngen, då fokus under utvecklingsprocessen låg på att utveckla en fungerande visningsklient, inte på dess säkerhet. Uppkopplingsinställningarna sparas som en given sträng, i detta fall den antagna strängen
Context, i applikationens konfigureringsfil App.config. Denna fil innehåller ramverkets
uppkopplingskonfiguration mellan applikationen och databasen. Denna konfiguration innefattar den skapade uppkopplingsträngen. Uppkopplingsträngens relevanta innehåll är följande:
Name: den givna strängen som uppkopplingsinställningarna sparades under Data Source: den server som agerar datakälla
Initial Catalog: den databas som uppkopplingen upprättats mot
User id & password: de inloggningsuppgifter som är kopplade till servern, och som i detta fall valts att medskickas i uppkopplingssträngen
