Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 16hp | Datateknik
202019 | LIU-IDA/LITH-EX-G--2019/XXX--SE
Utvecklingen av ett verktyg för
att automatisera konfiguration av
plattformar i taktiska
simulering-ar
The development of a tool for automating configuration of
plat-forms in tactical simulations
Hampus Olsson, Pontus Nilsson
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Sammanfattning
Idag är det vanligt att automatisera mer och mer av människors arbete för att spara in tid på repetitiva och tidskrävande arbetsuppgifter. Ett sätt att göra detta på är att utveckla ett användargränssnitt för att samla flera handlingar i t.ex. en knapp. I detta arbetet skapas ett verktyg i form av ett användargränssnitt för att automatisera och effektivisera konfi-gureringen av plattformar i taktiska simuleringar för arbetarna på FOI. Egenskaper och funktionalitet i verktyget specificeras i en kravspecifikation skriven av FOI. Detta verktyg strävar efter en hög användbarhet och bra möjligheter till utbyggbarhet för att möjliggöra framtida tillägg till verktyget av arbetarna på FOI. Arbetet resulterade i ett verktyg som bå-de är användarvänligt och utbyggbart som visabå-de sig vara en förbättring av FOI:s tidigare arbetssätt.
Författarens tack
Vi skulle vilja tacka våra kamrater Liam Vilhelmsson och Tobias Mellberg som gjort sitt exa-mensarbete parallellt med oss på FOI för trevligt umgänge. Även stort tack till vår handleda-re på FOI, Dennis Granåsen som alltid ställt upp och givit bra råd under hela arbetets gång. Slutligen vill vi tacka vår examinator Petru Eles för hjälp och handledning.
Innehåll
Sammanfattning iii Författarens tack iv Innehåll v Figurer vii Tabeller viii 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Mål . . . 2 1.4 Kravspecifikation . . . 2 1.5 Avgränsningar . . . 3 2 Bakgrund 4 2.1 Totalförsvarets forskningsinstitut . . . 4 2.2 Konfigurationsverktyg . . . 4 2.3 Kommunikationsplattform . . . 4 2.4 Förbandsstruktur . . . 5 2.5 Integrering av verktyg . . . 52.6 FOI:s nuvarande tillvägagångssätt . . . 6
3 Teori 7 3.1 Relaterat arbete . . . 7 3.2 Grafiska användargränssnitt . . . 7 3.3 C# . . . 8 3.4 .Net Framework . . . 8 3.4.1 WinForms . . . 8
3.4.1.1 Model View Controller (MVC) pattern . . . 8
3.4.1.2 Model View Presenter (MVP) pattern . . . 8
3.4.2 WPF . . . 9 3.4.2.1 Mvvm . . . 9 3.5 Python . . . 9 3.5.1 PyQt . . . 9 3.6 Användbarhet . . . 10 3.7 Utbyggbarhet . . . 10 4 Metod 11 4.1 Val av ramverk . . . 11 4.2 Implementation . . . 12
4.3 Utvärdering av verktyget . . . 12
5 Resultat 13 5.1 Val av ramverk . . . 13
5.2 Implementation . . . 13
5.2.1 Skapa mallar . . . 14
5.2.2 Designa militära förband . . . 16
5.2.3 Instansiering av förband . . . 17
5.2.4 Funktioner för att öka användbarhet . . . 19
5.2.4.1 Multiselect . . . 19
5.2.4.2 Visuell återkoppling . . . 19
5.2.4.3 Drag and Drop . . . 20
5.3 Utvärdering av verktyget . . . 21
6 Diskussion 23 6.1 Resultat . . . 23
6.2 Metod . . . 23
6.2.1 Replikerbarhet . . . 23
6.3 Arbetet i ett bredare kontext . . . 24
7 Slutsats 25
Figurer
2.1 Ett exempel på hur strukturen av enheter kan se ut i en mall. . . 5
2.2 Ett exempel på hur en militärt förband skulle kunna se ut. . . 5
2.3 Hur ett militärt förband ser ut definierat i excel. . . 6
3.1 Hur MVVM är designat och hur det kommunicerar . . . 9
5.1 En helhetsbild på första fönstret i verktyget. . . 14
5.2 Listor med de mallar som redan finns skapade. . . 14
5.3 I denna del av fönstret skapas olika typer av varje komponent som kommer finnas i en platform. En uppsättning av dessa komponenter sätts ihop för att sedan skapa en komplett mall. . . 15
5.4 1. Fönster för skapandet av mallar till vågformer. 2. Fönster för skapandet av oli-ka valbara typer av servers. 3. Fönster för soli-kapandet av olioli-ka valbara typer av klienter. 4. Fönster för skapandet av olika valbara typer av radios. . . 15
5.5 En helhetsbild på fönstret för att designa militära förband. . . 16
5.6 Detta är en liten meny med tre olika valmöjligheter användaren får upp om an-vändaren högerklickar på en enhet i trädet. . . 16
5.7 File innehåller tre vanliga funktioner som de flesta GUI också innehåller. . . 17
5.8 Detta är fönstret får upp när användaren försöker lägga till nya enheter i trädet. . . 17
5.9 Detta är fönstret för att instansiera förbandet. . . 17
5.10 En bild på vilka mallar som existerar och där användaren instansierar vågformer. . 18
5.11 Fönstret som dyker upp när användaren vill lägga till en mall på en/flera enheter. 18 5.12 Hur det ser ut när man makerar flera enheter. . . 19
5.13 Visuell återkoppling när användare sparar mall med ett namn som redan existerar i verktyget. . . 19
5.14 Visuell återkoppling med var filer kan finnas när användare genererar en konfi-gurationsfil. . . 20
5.15 Dra från ”Existing plattforms” in på en/flera enheter för att lägga till. . . 20
5.16 Släpp plattformen för att lägga till och då läggs vågformer tillhörande tillagd mall till i ”Current waveforms” listan. . . 21
Tabeller
1
Inledning
1.1
Motivering
Försvaret är en viktig del av landets säkerhet. Försvarets uppgift är att försvara landet och dess befolkning ifrån utomstående. Hoten mot landets säkerhet kan komma i många former, det kan vara andra länders trupper som invaderar landet eller så kan det vara virtuella hot. Strategi, träning och kommunikation är tre viktiga delar för att försvaret skall fungera. För att försvarets trupper ska kunna skydda landet så effektivt som möjligt måste de ha möjligthet att träna. Träningen är det som kommer lära trupperna att göra manövrar och ha ett bra sam-arbete. För att kunna ha ett bra samarbete så är kommunikationen viktig. Kommunikationen är viktigt för att lätt kunna få en översikt, struktur och minska skaderisken under övningen. Detta ökar kraven på verktygen som har hand om kommunikationen, krav som att de skall vara användarvänliga och flexibla till förändring.
FOI, företaget arbetet utförs på, har idag ett kluster vid namn CRATE som består av ett par hundra virtuella maskiner där simuleringar körs för olika militära scenarion. I dagens läge måste de konfigurera alla virtuella maskiner manuellt vilket är en tidskrävande uppgift och kan ta ännu längre tid ifall fel uppstår vid konfigureringen. För att underlätta denna pro-cessen vill FOI ha ett verktyg som är lätt att förstå och använda, som möjliggör att vilken person som helst skall kunna konfigurera klustret. Verktyget skall inte utföra någon konfi-gurering utan skall skapa konfigurationsfiler som sedan skall användas av ett annat verktyg som konfigurerar de virtuella maskinerna. Detta verktyg utvecklas parallellt av en utvecklare på FOI.
1.2
Syfte
I detta arbete föreslås en lösning på ett användbart och utbyggbart verktyg för att skapa kon-figurationsmallar och omstrukturera kommunikationsplattformar, samt att designa militära förbandsstrukturer. Det är önskvärt att verktyget skall vara användbart då det möjliggör för ett effektivare arbete och att det underlättar för nya personer att lära sig verktyget. Då För-svarsmakten är en organisation i ständig utveckling och förändring så är det önskvärt att verktyget skall vara utbyggbart för att lättare kunna hantera förändringar i förbandsstruktu-ren. Det är även önskvärt att verktyget ska vara utbyggbart för att lättare kunna lägga till nya funktioner eller göra ändringar till verktyget.
1.3. Mål
I verktyget som FOI vill utveckla skall det kunna skapas militära förbandsstrukturer som sedan skall visualiseras i en trädstruktur. Dessa förbandsstrukturer skall kunna sparas i JSON-format, samt kunna läsas in från JSON-format och generera trädstrukturen. Det skall också gå att skapa mallar som representerar en kommunikationsplattform som t.ex. konfi-gurationer för en viss modell av en stridsvagn. En kommunikationsplattform består typiskt av en komnod, en eller flera klienter, en eller två servrar, m.m. som alla är representerade av virtuella maskiner i klustret. I skapandet av mallar kommer också IP-adresser, nätmask och multicast-adress genereras. Alla mallens variabler skall kunna sparas ner till JSON-filer. I verktyget skall enheter kunna initieras i trädstrukturen med dessa mallar och generera en JSON-fil utifrån trädstrukturen. Genererade filen skall också verktyget kunna läsa in för att göra det så enkelt som möjligt att redigera.
1.3
Mål
Målet med detta arbete är att utveckla ett grafiskt användargränssnitt för att automatisera skapandet av typkonfigurationer i form av filer till CRATE. Det som är viktigt egenskaper för verktyget har FOI skrivit i form av en kravspecifikation, och detta arbete kommer att utgå från just den kravspecifikation, vid utvecklingen av verktyget.
1.4
Kravspecifikation
Utifrån FOI:s nuvarande tillvägagångssätt till deras arbete, med andra ord konfigurering-en av kommunikationsplattformar i deras kluster, så har arbetarna idkonfigurering-entifierat några nyckel funktionaliteter och egenskaper som behövs samt brister som avses att lösas med detta verk-tyget. Krav på funktionalitet listas här nedan:
1. Designa militära förbandsstrukturer
2. Designa mallar för konfiguration av datornät där varje plattformstyp/fordonstyp har en typkonfiguration
3. Realisera plattformar genom att koppla mall mot förband
4. Nätverksparametrar ska kunna konfigureras automatiskt då denna koppling görs 5. Mjukvara ska kunna konfigureras automatiskt då denna koppling görs
6. Spara alla mallar och konfigurationer till fil 7. Läsa alla mallar och konfigurationer från fil
8. Integrera med klustrets konfigurationsverktyg för att driftsätta simuleringsmiljön Utöver funktionaliteten så finns de även egenskaper som är önskvärda att verktyget besit-ter för att det skall vara till så stor användning som möjligt inom FOI:s arbete. Handledaren på FOI kommer att lägga särskilt fokus vid följande områden:
9. Användbarhet 10. Utbyggbarhet
Dessa egenskaper kommer att ligga som grund för designbesluten som tas under utveckling-en av verktyget.
1.5. Avgränsningar
1.5
Avgränsningar
• Verktyget skall i första hand köras på en windowsmiljö då detta är vad företaget an-vänder sig av i deras verksamhet.
• Verktyget skall i första hand koppla typkonfigurationer av kommunikationsplattformar mot ett eller flera militärförband och för att kunna automatisera de manuella stegen vid konfigurationen av virtuella maskinerna.
• Automatisering kommer att göras i samarbete med en utvecklare på FOI så en konfigu-rationsfil ska genereras av verktyget som skall tolkas av utvecklarens verktyg.
2
Bakgrund
2.1
Totalförsvarets forskningsinstitut
FOI, Totalförsvarets forskningsinstitut, är ledande inom säkerhet och försvar i Europa. FOI är statligt ägt och arbetar under Försvarsdepartementet. På FOI forskas det kring säkerhet på al-la nivåer inom samhället. FOI jobbar främst för Försvarsmakten och Försvarets materielverk men jobbar även med kommuner och företag.
2.2
Konfigurationsverktyg
FOI har utvecklat en plattform vid namn CRATE för att kunna köra stora simulationer i en virtuell miljö. Cyber Range And Training Environment, förkortat CRATE, är en miljö för att simulera och träna inför framtida IT-intrång eller IT-incidenter. CRATE består idag av ca 800 servrar i ett kluster med både intern och extern kommunikation där klustret används för att bygga upp ett simulerat internet med tusentals virtuella datorer. I denna virtuella miljö kan man välja vilken sorts hårdvara- och kommunikationsinfrastruktur som skall simuleras. Till CRATE har FOI utvecklat ett konfigurationsverktyg som används för att välja vad för sorts hård- och mjukvara som ska simuleras och antalet datorer som skall avsättas för varje simulation. FOI har identifierat ett behov av att förenkla skapandet av konfigurationerna för den hård- och mjukvara som ska simuleras.
2.3
Kommunikationsplattform
En kommunikationsplattform består av en uppsättning virtuella maskiner som kommunice-rar med varandra via CRATE. Det finns olika typer av kommunikationsplattformer där en sådan kan vara en fordonstyp som t.ex. en stridsvagn eller andra sorters stridsfordon. Varje kommunikationsplattform skall kopplas till en mall som skall vara specifik för just den typen av kommunikationsplattform där en typ kan variera t.ex. med antalet virtuella maskiner den kräver. En kommunikationsplattform innehåller typiskt två eller flera radioenheter, en kom-nod, en krypteringsenhet, en eller två servrar och ett flertal klienter som skall ta emot och skicka data. Ett exempel på hur en mall för kommunikationsplattformar går att se i Figur 2.1.
2.4. Förbandsstruktur
Figur 2.1: Ett exempel på hur strukturen av enheter kan se ut i en mall.
2.4
Förbandsstruktur
En förbandsstruktur är en visualisering av hierarkin och relationerna mellan de olika förban-den som sammanfaller under det översta förbandet i trädstrukturen. Förbandet kommer att representeras med hjälp av trädstrukturen och kommer kunna bestå av fem olika militära förband. Det som användaren kommer få välja mellan är Brigad, Bataljon, Kompani, Pluton och Grupp. Ett exempel på detta går att se i Figur 2.2 .
Figur 2.2: Ett exempel på hur en militärt förband skulle kunna se ut.
2.5
Integrering av verktyg
Det nya verktyget som utvecklas i detta arbete skall kunna konfigurera IP-adresser, namn, typer, antalet radioenheter/servrar i klustret såväl som mjukvara som körs på virtuella mil-jön. All denna information skall sparas i form av mallar och hela denna process skall va-ra automatiseva-rad. I detta arbetet kommer konfiguva-rationspava-rametva-rar skapas i form av fält i ett JSON-objekt och där varje sådant JSON-objekt representerar en mall för en viss typ av
2.6. FOI:s nuvarande tillvägagångssätt
konfiguration. För att integrera FOI:s verktyg och verktyget som utvecklas i detta arbete be-höver detta JSON-objekt tolkas och översättas till kommandon i Virtualbox VboxManage-gränssnitt. Detta gränssnitt används av FOI:s verktyg för den slutgiltiga konfigureringen av virtuella maskinerna. Denna tolkning och översättning kommer att utvecklas parallellt med detta arbete av en utvecklare på FOI och kommer inte att ingå i detta arbetet.
2.6
FOI:s nuvarande tillvägagångssätt
För att kunna köra simulationer i CRATE behöver klustret det består av att konfigureras. För att lättast göra det genererar arbetarna på FOI just nu JSON-filer dels från Excel, men skriver även för hand. De börjar med att definiera vilka enheter som ska finnas. Detta skriver de sedan in i en Excel-fil, se Figur 2.3. I Figur 2.3 ses det hur en liten del av den militära strukturen är definierad i Excel. På tredje raden går det att se hur Stabs- Understödkomp är förälder till Lednplut, som i sin tur är förälder till 1. Ledgrp, som i sin tur innehåller fem fordon av typen Stripbv 90 Avancerad. Excel-filen fortsätter på liknande vis och är 170 rader lång. Det tar väldigt lång tid att definiera upp ett militärt förband på detta viss. Efter att Excel-filen är skapad används ett script som omvandlar det till en JSON-fil på det format som önskas. Men i denna fil finns det ingen information om fordonen, om nätverksparametrar, eller någon information om vågformer. Detta måste också skapas och det görs för hand. Detta arbete tar uppskattningsvis en hel arbetsdag att genomföra enligt arbetarna på FOI.
3
Teori
3.1
Relaterat arbete
I en funnen studie av Logen et al. [1] utvecklas ett GUI för att underlätta att arbete med Volati-lity framework. Valda ramverket var ganska svårt att använda och användare var tvungna att lära sig en massa kommandon för att använda det. Till frameworket tillkom en kommando-rads interface där kommandon skrevs in som interfacet exekverade. Författarna tyckte detta var jobbigt och ville därför underlätta arbetet. Därför valde de att utveckla ett GUI för att öka användbarheten av Volatility framework. Ett problem som är likt det som detta arbetet anses lösa. Arbetssättet de har är komplicerat och kräver mycket tid och vill underlätta detta genom att skapa ett användbart GUI.
Att kunna ändra på krav och detaljer under arbetets gång och att kunna anpassa verktyget för framtida utveckling är viktigt för detta arbete. En tidigare studie av Li et al. [2] studerade utvecklingen av ett GUI med hjälp av designmönstret MVVM för att se om verktyget skulle bli lättare att modifiera då verktyget behöver skräddarsys för varje kund. Eftersom MVVM som designmönster bidrar med separering av designen och logiken så ökade utbyggbarheten i och med komponenter lättare kunde återanvändas och ersättas utan större modifiering av verktyget.
3.2
Grafiska användargränssnitt
Grafiska användargränssnitt (GUI) är en sorts användargränssnitt som låter användaren in-teragera med datorn genom ikoner, bilder och andra notationer med hjälp av en mus men även tangentbord. Dessa gränssnitt kan ses som en uppgradering av CLI (Command Line Interface) som enbart är textbaserade och styrda med ett tangentbord [3]. Grafiska användar-gränssnitt gör hanteringen av datorer mer intuitiv och därav lättare att lära sig att använda. Att flytta filer eller skapa nya dokument kan då göras antingen genom ett knapptryck eller dra ikoner istället för en mängd kommandon skrivna i text. Detta tillåter användaren att ta full nytta av att kunna multitaska genom att köra flera instanser av gränssnittet och därav effektivisera sin spenderade tid. Visuell återkoppling är en annan fördel med grafiska använ-dargränssnitt där användaren direkt kan få en bekräftelse på vad den gjort och effekterna av handlingen. Lärande och användandet av gränssnittet för uppgifter blir då lättare och snab-bare att slutföra för användaren.
3.3. C#
3.3
C#
C# är ett objektorienterat programspråk skapat av Microsoft som från början utvecklades för att Windows ville ha ett Java liknande språk som var specialiserat mot operativsystemet Windows. Meningen med att utveckla ett eget språk var för att användas till Windows egna utvecklingsverktyg. Även om dessa utvecklingsverktyg enbart finns för Windows så har C# blivit plattformsoberoende genom fristående kompilatorer inom Mono och DotGNU projek-ten.
3.4
.Net Framework
Till operativsystemet Windows utvecklade Microsoft en systemkomponent kallad .NET Framework. Det består av en uppsättning komponenter som sköter exekveringen av pro-gram skrivna för detta ramverket. Ramverket inkluderar ett stort klassbibliotek för lösningar inom databashantering, webbtjänster, nätverksanslutning, användargränssnitt m.m.
3.4.1
WinForms
Klassbiblioteket Windows Forms är ett användargränssnitt som används för utveckling av skrivbordsapplikationer [4]. Windows Forms bidrar med en wrapper som består av en upp-sättning av C++-klasser för utveckling av Windows-applikationer. Den bidrar med diverse kontroller som textrutor, knappar och fönster samt möjligheten att utveckla egenanpassade kontroller. Windows Forms är i grund och botten en slät sida som en utvecklare kan fylla med kontroller för att skapa ett användargränssnitt. Windows Forms plattform bistår utvecklaren med en stor uppsättning av utvecklingsverktyg, allt från resurshantering, användarindata, visualisering av data, bindande av data och att skapa applikationer snabbt och säkert i en Windowsmiljö.
3.4.1.1 Model View Controller (MVC) pattern
MVC skapades 1979 av Trygve Reenskaug [5]. MVC består av tre delar Model, View och Controller. Trygve Reenskaug har även gjort en beskrivning av MVC pattern och förklarar vad varje del har för uppgift:
• Model kan bestå av en eller flera olika objekt och innehåller all dess information. • View är en visuell representation av Model. Den framhäver vissa element och gömmer
andra. Det är inte alltid att allt i Model skall visualiseras. View har även som uppgift att uppdatera Model när ändringar görs. För att kunna göra detta måste View veta hur semantiken ser ut för elementen in i Model.
• Controller är en länk mellan Model och View. Controller är delen som säger till View när element i Model ändras. Den ger även användaren möjlighet att interagera med View och ändra på element eller ta del av information i objekt. [6]
3.4.1.2 Model View Presenter (MVP) pattern
Mode View Presenter (MVP) utvecklades under 90-talet av mjukvaruföretaget Taligent soft-ware company [7]. MVP utvecklades först och främst till C++ och Java. Det var inte förrän 2000-talet som det började utvecklas i C# .Net. MVP är på många vis likt MVC där det som skiljer dem åt är data bindings. Dessa data bindings gör att om ett element som har bundits ändrar sig kommer ett event att ske och på den vägen avgörs vilket element som ska upp-dateras. Model och View har samma funktion i MVP som i MVC. Det som skiljer dem åt är Presenter, Presenter använder sig av data bindings för att få reda på vilket/vilka element som
3.5. Python
sitt element. Model kommer sedan att notifiera View om denna ändringen och då kommer View att hämta det uppdaterade värdet och visa det uppdaterade värdet för användaren.
3.4.2
WPF
För framtida utveckling av Windows-applikationer har Microsoft utvecklat en efterträdare till Windows Forms vid namn Windows Presentation Foundation, förkortat WPF. Till skillnad från Windows Forms bidrar WPF inte bara med en wrapper för C++-klasser utan är en del av ett .NET framework. WPF använder sig av XAML, ett XML-baserat programspråk för att definiera och länka de olika elementen i gränssnittet [9]. Med hjälp av XAML separeras designen och definitionen av användargränssnittet i XAML-filen, från runtime-logiken till applikationen som skrivs i filer som kallas ”codebehind”-filer. Denna typ av design möjliggör ett mer flexibelt och modulärt arbetsflöde där separata arbetslag parallellt kan jobba på både användargränssnittet och logik bakom applikationen. Återanvändning och utbyggbarhet av gränssnitt förenklas i WPF där ”codebehind”-filer lätt kan återanvändas med olika XAML-filer eller som utbyggnad av andra ”codebehind”-XAML-filer.
3.4.2.1 Mvvm
MVVM består precis som de andra designmönsterna också av tre delar, Model, View och View Model. MVVM utvecklades hos Microsoft av John Gossman [10] och målet var att göra en variation av MVP pattern för att bättre passa WPF. Eftersom MVVM är en modifikation av MVP är de lika. Den största skillnad utvecklingsmässigt är att MVVM använder man sig av WPF som i sin tur använder sig av XAML. Utöver det så fungerar alla olika delar likadant i teorin. Huvudskillnaden mellan MVP och MVVM är att i MVVM kan View Model bindas till många Views medan i MVP kan Presenter enbart bindas till en View. Detta gör att om man använder MVVM får man mindre kod och det går att återanvända mer kod [11].
Figur 3.1: Hur MVVM är designat och hur det kommunicerar
3.5
Python
TIOBE gör mätningar varje månad på vilka programmeringsspråk som är mest populära. Enligt den mätning TIOBE [12] gjorde för mars 2019 var Python det 3:e mest använda pro-grammeringsspråk och var det språk som växt mest sedan deras tidigare mätning för februari 2019. Enligt GitHub [13] egna mätningar för populära programmeringsspråk ligger Python på första plats med 27.35% av alla språk. Mätningen är baserat på hur många som googlar efter genomgångar av grundläggande Python.
3.5.1
PyQt
Qt är från början utvecklat för C++ men på senare dagar har det gjorts en version som fun-gerar på Python som heter PyQt. Qt är ett verktyg som utvecklats för att göra det lättare att utveckla GUI. Med Qt är det relativt enkelt att öppna fönster och skapa knappar med funktio-nalitet. PyQt har även klassbibliotek för databashantering och mycket mer. PyQt innehåller över 400 klasser och har över 6000 funktioner och metoder [14]. Med PyQt kommer också ett grafiskt verktyg som heter Qt Designer. Detta verktyg används för snabbt skapa upp GUI komponenter som t.ex. knappar och fönster vilket underlättar designen av ett GUI.
3.6. Användbarhet
3.6
Användbarhet
Användbarhet är en bredare term för användarerfarenhet och menar på hur lätt det är för en användare att använda produkten i fråga. Användbarhet är något som används för att mäta hur bra ett verktyg är. Det optimala verktyget är ett verktyg som är enkelt att lära sig använ-da, snabbt går att utföra det jobb som verktyget är tänkt för, att användaren kan ta en längre paus från att använda verktyget och sen snabbt komma in i det igen, att användaren gör få fel med verktyget och att det är en behaglig upplevelse att använda verktyget. Det finns även fler saker att mäta på när användbarheten av ett verktyg mäts. Dessa komponenter är de viktigaste för att uppnå en hög grad av användbarhet. Det finns också två olika tillvä-gagångssätt för att mätta användbarhet, “bottom-up” och “top-down” [15]. “bottom-up” är rak på sak och går ut på att hur lätt det är att använda verktyget. Medans “top-down” är ett bredare tillvägagångssätt som går ut på hur bra verktyget är för det ändamål det var skapt för.
Det finns många olika tolkningar för hur användbarheten för ett verktyg ska mätas. Det finns en organisation som heter “The International Standard Organization”, som har defi-nierat många olika ISO-standarder som kan användas för att mäta användbarheten av ett verktyg. Men det finns ett problem med alla dessa ISO-standarder: de är svåra att använda [15]. De riktlinjer som är framtagna för utvärderingen är oklara och svåra att tolka, de är inte universella utan måste anpassas till det arbete som utförs, m m. Allt detta har resulterat i att användbarhet har blivit svårt att mäta.
“The International Standard Organization” definierar användbarhet som “the extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use” [16]. Steve Krug är en expert på användarvänlighet och definierar användbarhet som “making sure that so-mething works well: that a person of average (or even below average) ability and experience can use the thing—whether it’s a Web site, a fighter jet, or a revolving door—for its intended purpose without getting hopelessly frustrated.” i sin bok Don’t make me think [17].
Användbarhet är ett kvalitetsattribut som bedömer hur enkelt ett användargränssnitt är att använda enligt Jakob Nielsen [18]. Jakob Nielsen är co-founder till Nielsen Norman Group som är ledande i forskning kring användarerfarenhet och definierar användbarhet med 5 komponenter:
• Lärbarhet (Learnability) - Hur enkelt är det för en användare att utföra grundläggande uppgifter första gången de möter designen?
• Effektivitet (Efficiency) - När användarna lärt sig designen, hur snabbt kan de utföra uppgifter?
• Minnesvärdhet (Memorability) - När användarna återvänder till designen efter en pe-riod då de inte använt det, hur lätt kan användarna återställa kompetensen?
• Fel (Errors) - Hur många fel gör användarna, hur svåra är dessa fel, och hur lätt kan de återhämta sig från felen?
• Nöjdhet (Satisfaction) - Hur trivsamt är det att använda designen? [18]
3.7
Utbyggbarhet
Vid utveckling av mjukvara finns det många egenskaper som anses förhöja kvaliteten av mjukvara, en av dessa egenskaperna är utbyggbarhet. För att underlätta för framtida utveck-lare eller arbetskamrater är det önskvärt att mjukvara skall vara anpassningsbar för föränd-ringar av krav eller vid integrering mellan två olika system. Utbyggbarhet är samlingstermen för hur väl mjukvara är benägen att anpassa sig för förändring av design eller komponenter
4
Metod
4.1
Val av ramverk
En efterforskning gjordes av olika ramverk för utveckling av applikationer som skulle kunna vara lämpliga för att utveckla ett verktyg utefter de krav och behov som satts upp av företa-get vilka går att se i 1.4. Sökningar på tidigare studier, rapporter och artiklar som handlar om utveckling av användargränssnitt genomfördes med nyckelord som användbarhet, utbygg-barhet och effektivitet. Första ramverket som undersöktes var QT och då i första hand dess Pythonversion. Det andra och tredje ramverken var Windows egna WinForms och WPF. För att avgöra vilket ramverk som skulle användas i arbetet summerades för- och nackdelar med varje ramverk i en tabell och matchades emot kravspecifikationen.
Summering av ramverk
Ramverk Fördelar Nackdelar PyQt
• Crossplatform-stöd. • Lätt att lära sig. • Bra stöd för design.
• Dålig dokumentation för PyQt. • Svårt att använda utan QT
Crea-tor. WinForms
• En del Crossplatform-stöd. • Äldre, mer beprövat.
• Data bindings, effektivare upp-datering.
• Lätt att lära sig.
• Mindre stöd för design och an-vändbarhet. • Mindre stöd för återanvändning av komponenter. WPF • Bra stöd för design. • Bra stöd för återanvändning av komponenter och utbyggbarhet. • Data bindings, effektivare
upp-datering
• Svårare att lära sig. • Inget Crossplatform-stöd.
4.2. Implementation
Utifrån för- och nackdelar summerade i Tabell 4.1 jämfördes resultatet med det som var viktiga egenskaper och krav för detta arbetet, de som specificerats tidigare i kapitel 1.4.
4.2
Implementation
Innan implementationen skulle påbörjas behövdes några designval göras. De frågor som fanns var hur allt skulle delas upp för att det skulle vara mer användbart. De val som be-hövde göras innan implementationen var hur verktyget skulle se ut. Det första som gjordes var att identifiera nyckelfunktionerna som skulle finnas i verktyget. De som identifierades var att skapa mallar, skapa militärförbandet och instansiera förbandet. Valet gjordes att de-la upp verktyget i tre fönster, en för varje nyckelfunktion. Detta var för att användaren inte skulle bli överrumplad av information när verktyget öppnades. Därefter var det lätt att veta vilka funktioner som skulle ligga under vilket fönster. Allt som rörde skapandet av mallar låg under fönstret för som hanterade mallar, design av förband under sitt fönster och sedan ett fönster för som instansierade förbandsstrukturen med mallar.
Vid skapandet av den slutgiltiga konfigurationsfilen för CRATE togs ett beslut att samla all information i en enda stor JSON-fil istället för att ha de olika mallarna uppdelade i flera små filer. Detta valet gjorde det svårare att förstå strukturen av JSON-filen dock underlättade det inläsningen för de som i slutändan skall bearbeta denna konfigurationsfil genom att ha all information i en fil. Detta valet bidrar till effektivare arbete för de anställda på FOI.
För att ge bra återkoppling till användaren så togs beslutet att implementera dialogrutor, som ifall användaren gör fel, kommer med återkoppling som beskriver vad som gick snett och förslag på hur användaren kan undvika att göra samma misstag. Detta för att öka an-vändbarheten i enlighet med Jakob Nielsens [18] definition då dialogrutor bidrar med bättre återhämtning från fel och ökning av lärbarheten med förslag ifall de är första gången använ-daren använder verktyget.
För att effektivisera arbetet och undvika repetitiva uppgifter vid bland annat skapandet av förbandsstrukturer identifierades ett behov av att kunna markera flera förband ifall de skulle tilldelas samma undergrupper och på så vis tilldela flera förband samtidigt. När användaren väl lärt sig designen kan de då effektivisera sitt arbete [18].
4.3
Utvärdering av verktyget
För att utvärdera verktyget gjordes en jämföras med kravspecifikationen i kapitel 1.4. Det kommer att kolla att varje funktionalitet finns i verktyget och fungerar på det sätt som det var ämnat åt. Det kommer även göra ett test där handledaren får testa skapa de filer som krävs för att köra en simulation på CRATE. På så sätt kan man säkerställa att all funktionalitet finns i verktyget för att kunna genomföra det arbete verktyget var skapt för. Ifall verktyget uppfyller alla krav i kravspecifikationen och att handledaren enkelt kan skapa en konfigurationsfil med all information som behövs med så lite repetitivt arbete som möjligt, anses verktyget vara en förbättring av FOI:s tidigare tillvägagångssätt.
5
Resultat
5.1
Val av ramverk
PyQt är lätt att lära sig och Python är ett effektivt programspråk att utveckla i. Ramverket har bra stöd för design men under testningen av ramverket märktes en viss avsaknad av doku-mentation. Vid utvecklingen av nya verktyg på FOI så använder sig majoritet av utvecklarna antingen WinForms eller WPF. De flesta datorer på FOI använder sig av en Windowsmiljö så därav var crossplatform-stöd inte av någon relevans för detta arbetet. För att underlätta för framtida arbetare att utveckla vidare på arbetets verktyg valdes därför PyQt bort.
Möjligheten att lätt kunna bygga vidare på verktyget och även återanvända delar av verk-tyget vid framtida utveckling ansågs viktigt i enlighet med kravspecifikationen. Detta är något som Li et al. [2] påpekar i sin studie som en fördel vid användning av WPF jämfört med WinForms, att WPF ökade nivån av utbyggbarhet. Med detta i åtanke valdes WPF som med XAML filer möjliggör separering av design från bakgrundslogiken. Detta resulterar i att båda delar kan återanvändas oberoende av varandra vilket är något WinForms saknar. De-signmönstret MVVM i WPF tillför även att varje dataobjekt har en tillhörande View Model som besitter visualiseringslogiken för just det objektet. Ett objekt kan då lätt läggas till eller återanvändas i andra verktyg genom att endast kopiera objektet och tillhörande View Model.
5.2
Implementation
Resultaten av de designvalen som gjordes i Sektionen 4.2 presenteras i detta kapitel i form av bilder och beskrivningar av de olika funktionerna i verktyget.
5.2. Implementation
5.2.1
Skapa mallar
Figur 5.1: En helhetsbild på första fönstret i verktyget.
Fönstret med namnet ”Create template” är den del av verktyget som ansvarar för ska-pandet av mallar, i första hand mallar för kommunikationsplattformar som kan ses i Figur 5.1.
Figur 5.2: Listor med de mallar som redan finns skapade.
I Figur 5.2 syns de listor av mallar som redan har skapats i verktyget. Listan ”Platform Templates” håller på namnet av plattformen och vilken typ av den specifika plattformen. Ifall en mall markeras med ett vänsterklick så kommer den valda mallen att laddas in i ”Create Platform Template” fönstret som går att se i Figur 5.3. Därifrån inspekteras, redigeras eller återanvändas i skapandet av en ny mall. Den andra listan ”VF Templates” håller de mallarna som varje vågform kan instansieras med. I högra hörnet finns knappen ”File” som används för att ladda in en befintlig mall utifrån in i verktyget.
5.2. Implementation
Figur 5.3: I denna del av fönstret skapas olika typer av varje komponent som kommer finnas i en platform. En uppsättning av dessa komponenter sätts ihop för att sedan skapa en komplett mall.
Fönstret i Figur 5.3 sköter själva ihopsättningen av en mall. ”Radio type”, ”Client type” och ”Server type” är dropdown-menyer där användaren väljer av de existerande typerna för varje komponenter som skapats i de fönsterna som går att se i Figur 5.4. En radio är unik i varje mall medans klienter och servrar kan ha flera av samma eller olika typer i en och samma mall, vilket representeras av ett ”xN” efter namnet där n är antalet av den komponenten. I listan till höger i Figur 5.3 syns de för tillfället tillagda komponenter i mallen som kommer läggas till ifall användaren väljer att spara mallen.
Figur 5.4: 1. Fönster för skapandet av mallar till vågformer. 2. Fönster för skapandet av olika valbara typer av servers. 3. Fönster för skapandet av olika valbara typer av klienter. 4. Fönster för skapandet av olika valbara typer av radios.
5.2. Implementation
5.2.2
Designa militära förband
Figur 5.5: En helhetsbild på fönstret för att designa militära förband.
I Figur 5.5 ses det hur fönstret för att designa militära förband ser ut. Detta fönster inne-håller all funktionalitet som har med skapandet av militära förband att göra. För att skapa ett militärt förband kan användaren dra in en typ av enhet från det högra fältet från något av de fem valen som finns fördefinierade i rutan.
Figur 5.6: Detta är en liten meny med tre olika valmöjligheter användaren får upp om använ-daren högerklickar på en enhet i trädet.
När användaren högerklickar på en enhet så kommer användaren få upp tre olika val (se Figur 5.6). Användaren kan välja mellan ”Remove Node and Templates”, ”View as seperate tree”, eller ”Change image”. ”View as seperate tree” uppgift är att visa de valda enheterna i ett eget träd. Om användaren väljer ”View as seperate tree” kommer knappen som ligger bredvid File i Figur 5.5 att bli aktiv och användaren kommer då att kunna gå tillbaka till trädet som fanns innan en mindre del visades. File innehåller också tre olika valmöjligheter (se Figur 5.7). Dessa val är ‘’New’, ‘’Open”, och ‘’Save”. ‘’New” tar bort befintligt träd, ‘’Open” laddar in ett sparat träd, och ‘’Save” sparar det befintliga trädet.
När användaren drar in en ny enhet i trädet kommer det öppna ett nytt litet fönster (se Figur 5.8). I fönstret kommer man få fylla i vad enhetens namn ska vara och hur många enheter som skall skapas, där en enhet är förinställd. Om användaren väljer att lägga till flera med samma namn kommer en siffra stegas upp för att kunna urskilja enheterna.
5.2. Implementation
Figur 5.7: File innehåller tre vanliga funktioner som de flesta GUI också innehåller.
Figur 5.8: Detta är fönstret får upp när användaren försöker lägga till nya enheter i trädet.
5.2.3
Instansiering av förband
Figur 5.9: Detta är fönstret för att instansiera förbandet.
I Figur 5.9 ses det hur fönstret för att instansiera förbanden ser ut. Den är ganska likt fönstret för att skapa förband, skillnaden är att detta fönster innehåller lite mer funktionalitet. Precis som i fönstret för att skapa förband har även detta fönstret en ‘’File” och ‘’previous tree” knapp. De fungerar precis likadant som i fönstret för att skapa förband. Det som skiljer de åt går att se i Figur 5.10.
5.2. Implementation
Figur 5.10: En bild på vilka mallar som existerar och där användaren instansierar vågformer.
I det vänstra fönstret i Figur 5.10 ses alla existerande mallar. Den innehåller namnen på mallarna och vilken typ av plattform. Dessa kan användaren dra in på trädet för att lägga till dem på en eller flera enheter. När användaren drar in en mall på en enhet kommer fönstret i Figur 5.11 dyka upp. Där får användaren specificera hur många mallar som användaren vill lägga till av den mall som drogs in på enheten. I det högra fönstret i Figur 5.10 ses vilka våg-former som finns i förbandet, vilken bandbredd de har och användaren kommer också kunna se vilken IP-adress vågformen kommunicerar på. Dessa kommer i början att vara tomma och användaren får dra in vågformer från ‘’Waveform Templates” för att instansiera vågformer-na. Det finns även två knappar i fönstret, ‘’Select folder” som kommer att öppna en standard dialogruta i Windows där användaren får välja en mapp som konfigurationsfilerna ska spa-ras i, och den andra knappen ‘’Generate config files” kommer att generera filerna och spara dem i den mapp som användaren valt.
5.2. Implementation
5.2.4
Funktioner för att öka användbarhet
Här kommer några funktioner som ökar användbarheten av verktyget att presenteras.
5.2.4.1 Multiselect
Figur 5.12: Hur det ser ut när man makerar flera enheter.
I fönsterna för att designa och instansiera förband finns möjligheten att markera flera en-heter, detta kan ses i Figur 5.12. De enheter som väljs kommer att markeras som vanligt med ett blått fält. Om användaren har markerat flera enheter och utför någon operation kommer samma operation att utföras på samtliga markerade enheter. För att markera flera enheter håller användaren in LCtrl samtidigt som användaren trycker på de enheterna som använda-ren vill markera.
5.2.4.2 Visuell återkoppling
Figur 5.13: Visuell återkoppling när användare sparar mall med ett namn som redan existerar i verktyget.
I verktyget finns det flera olika popup-fönster som säger till när användaren gjort något som inte ska göras eller när användaren måste fatta något sorts beslut. Ett exempel är när an-vändaren försöker skapa en ny mall med samma namn som en som redan finns. Då kommer popup-fönstret i Figur 5.13 och användaren får då göra ett val. Det finns även flera popup fönster som inte har några val i som t.ex. Figur 5.14, som istället förklarar vad användaren
5.2. Implementation
gjort som inte borde göras eller ger återkoppling över resultatet av handlingen som använ-daren utförde.
Figur 5.14: Visuell återkoppling med var filer kan finnas när användare genererar en konfi-gurationsfil.
5.2.4.3 Drag and Drop
Figur 5.15: Dra från ”Existing plattforms” in på en/flera enheter för att lägga till.
Denna funktionalitet ligger i att designa och instansiera förbandfönstren. I Figur 5.15 ses det hur användaren drar en mall från fönstret i högra hörnet in till trädet för att lägga till den i en enhet. I Figur 5.16 har mallen lagts till på den enhet användaren släppte den på. Detta kan också kombineras med att markera flera enheter för att lägga mallen till flera enheter samtidigt. Samma sak gäller för fönstret med att designa förband, där går det också att dra in förband för att lägga till i trädet (se Figur 5.5).
5.3. Utvärdering av verktyget
Figur 5.16: Släpp plattformen för att lägga till och då läggs vågformer tillhörande tillagd mall till i ”Current waveforms” listan.
5.3
Utvärdering av verktyget
Denna del kommer att innehålla en utvärdering kring hur väl verktyget uppfyller kravspeci-fikationen, samt handledarens åsikter kring hur användbart verktyget är att arbeta med.
• Kravspecifikation 1: Detta krav uppfylldes genom att implementera det fönster som ses i Figur 5.5.
• Kravspecifikation 2: Detta krav uppfylldes genom att implementera det fönster som ses i Figur 5.2.
• Kravspecifikation 3: Detta krav uppfylldes genom att implementera det fönster som ses i Figur 5.9.
• Kravspecifikation 4: Detta löstes med att associera ett unikt id till varje tillagd plattform i förbandsstrukturen vid instansiering (koppling).
• Kravspecifikation 5: Detta löstes med att användaren fick instansiera varje tillagd våg-form med de parametrarna som användaren ville ha. Sedan kommer alla tillagda platt-formar att konfigureras med de valda parametrarna. Detta kan ses i det högra fönstret i Figur 5.10.
• Kravspecifikation 6: Designa och instansiera förband har både en flik som heter ‘’File” där användaren kan spara ner filerna. Dock sparas det bara minimalt med filer. För att spara allt så får användaren välja mapp och sen generera konfigurationsfilerna genom att trycka på ‘’Generate” i Figur 5.9.
• Kravspecifikation 7: Alla fönster kan läsa in filer, i fönstret för att skapa mallar kan an-vändaren läsa in mallar från filer. I både fönstret för att designa och instansiera förband kan användaren läsa in strukturen för förbandet och dess mallar som ligger i förbandet från en fil.
• Kravspecifikation 8: Denna punkt är lite speciell, anledningen till det är för att arbetaren på FOI inte är klar med det verktyget än. Men konfigurationsfilerna är skickade och det kommer fungera att driftsätta simuleringsmiljön från de filerna.
5.3. Utvärdering av verktyget
• Kravspecifikation 9: Detta löstes med att implementera funktionalitet som beskrevs i Funktioner för att öka användbarhet.
• Kravspecifikation 10: Detta löstes genom valet av ramverk. Att använda ramverket WPF och med designmönstret MVVM.
När verktyget var färdigt fick även handledaren utvärdera verktyget. Han ansåg att verk-tyget var en förbättring av FOI:s nuvarande arbetssätt, och att verkverk-tyget skulle underlätta vid framtida arbete med CRATE.
6
Diskussion
6.1
Resultat
Målet med detta arbete var att skapa ett verktyg som uppfyllde alla de kraven listade i krav-specifikationen. Verktyget uppfyller dessa krav, dock visade sig vissa delar av verktygets funktioner vara svårare att implementera än förväntat. WPF, det ramverk som valdes för im-plementationen av verktyget, har som ramverk inte inbyggda funktioner för vare sig ”Drag and Drop” eller ”Multiselect” vilket var något som på förhand inte togs i åtanke. Detta re-sulterade i att dessa funktioner behövde implementeras på egen hand i form av utbyggnads-klasser av ramverkets utbyggnads-klasser. Mycket tid och felsökning lades ner på att implementera den-na funktioden-nalitet som redan finns i de andra ramverken som presenterades i Tabell 4.1 vilket kunde haft en påverkan i beslutet vid val av ramverk.
6.2
Metod
Detaljerna kring vad som skulle finnas i verktyget var från början inte tydligt specificerade utan var något som till viss del fick identifieras under arbetets gång. Detta gjorde det svårt att upprätta en systematisk metod för utvecklingen och resulterade i att arbetet tog lite längre tid än nödvändigt. Mer fokus hade kunnat läggas på design och placering av de olika fönsterna och även eventuell ytterligare uppdelning av funktionerna i flera fönster. Mer efterforskning hade kunnat göras i detta område för att få en högre användbarhet men detta hanns tyvärr inte med på grund av tidsbrist.
6.2.1
Replikerbarhet
Ifall någon skulle skapa ett verktyg utifrån detta arbetets metod så skulle de resultera i ett likvärdigt verktyg. Däremot är metoden baserad på de krav som specificerats i kravspecifi-kationen, väldigt specifikt för just de verktyg som FOI vill ha och därför inte är så generell arbetsmetod för utveckling utav användargränssnitt. Utöver det skiljer sig designen av ett verktyg åt från person till person vilket kan resultera att t.ex. användbarheten av verktygen inte blir sig likvärdig. Även de designbesluten som tas i utvecklingen av ett verktyg blir väl-digt knutna till verktygets ändamål vilket även gäller i detta fallet.
6.3. Arbetet i ett bredare kontext
6.3
Arbetet i ett bredare kontext
När vi designade verktyget fick vi förfrågan ifall vi hade några problem med att arbeta med något som kan användas i ett militärt syfte vilket är något som är värt att ha i åtanke som utvecklare. Vi är även medvetna att rapporten är en publik handling och resultatet skulle kunna användas i ett omoraliskt syfte. Verktyget skulle kunna användas för att realisera kris-scenarion och i fel händer kan det användas för att simulera något omoraliskt. Vi anser att verktygets ändamål eller innehållet i det inte är omoraliskt eller oetiskt utan är något som effektiviserar arbetet för de anställda på FOI och deras verksamhet.
7
Slutsats
Syftet med detta arbete var att utveckla ett verktyg som skulle effektivisera arbetet för anställ-da på FOI vid konfigureringen av CRATE. Verktyget uppfyller alla de kraven specificerade i Kravspecifikation och har implementerats med funktionalitet som visuell feedback, ”Multise-lect” och ”Drag and Drop” för att förhöja användbarheten. Valet av ramverket WPF resultera i ett mer utbyggbart verktyg.
Litteratur
[1] S. Logen, H. Höfken och M. Schuba. ”Simplifying RAM Forensics: A GUI and Exten-sions for the Volatility Framework”. I: 2012 Seventh International Conference on Availabi-lity, Reliability and Security. Aug. 2012, s. 620–624.
[2] X. Li, D. Chang, H. Pen, X. Zhang, Y. Liu och Y. Yao. ”Application of MVVM design pattern in MES”. I: 2015 IEEE International Conference on Cyber Technology in Automation, Control, and Intelligent Systems (CYBER). Juni 2015, s. 1374–1378.
[3] GUI Definition. http://www.linfo.org/gui.html. Accessed: 2019-04-03.
[4] Windows Forms overview. https : / / docs . microsoft . com / en - us / dotnet / framework/winforms/windows-forms-overview. Accessed: 2019-05-29.
[5] Trygve M. H. Reenskaug. MVC XEROX PARC 1978-79. http://heim.ifi.uio.no/ ~trygver/themes/mvc/mvc-index.html. Accessed: 2019-05-29.
[6] Trygve M. H. Reenskaug. MODELS-VIEWS-CONTROLLERS. http : / / heim . ifi . uio.no/~trygver/1979/mvc- 2/1979- 12- MVC.pdf. Accessed: 2019-05-29. Dec. 1979.
[7] M. Potel. MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java. http://www.wildcrest.com/Potel/Portfolio/mvp.pdf. Accessed: 2019-05-31. 1996.
[8] F. Jarnjak. ”Notice of Retraction Flexible GUI in robotics applications using Windows Presentation Foundation framework and Model View ViewModel pattern”. I: 4th In-ternational Conference on New Trends in Information Science and Service Science. Maj 2010, s. 176–179.
[9] XAML overview. https://docs.microsoft.com/en-us/dotnet/framework/ wpf/advanced/xaml-overview-wpf. Accessed: 2019-05-29.
[10] A. Feldman. ”WPF in Action with Visual Studio 2008”. I: Manning Publications Co (2009), s. 283–285.
[11] J. Smith. ”WPF Apps With The Model-View-ViewModel Design Pattern”. I: MSDN Ma-gazine (febr. 2009).
[12] TIOBE Index for March 2019. https://www.tiobe.com/tiobe- index. Accessed: 2019-04-03.
Litteratur
[13] PYPL PopularitY of Programming Language. http://pypl.github.io/PYPL.html. Accessed: 2019-04-12.
[14] PyQt. https://wiki.python.org/moin/PyQt. Accessed: 2019-04-12.
[15] N. Bevan. ”Measuring usability as quality of use”. I: Software Quality Journal 4 (2 1995), s. 115–130.ISSN: 1573-1367.
[16] ISO 9241-11:1998. ”Ergonomic requirements for office work with visual display ter-minals (VDTs)–Part 11: Guidance on usability”. I: Standard. Geneva, CH: International Organization for Standardization (mars 1998).
[17] S. Krug. Don’t make me think: A common sense approach to web usability. Pearson Education India, 2005.
[18] J. Nielsen. ”Usability 101: introduction to usability”. I: All Usability 9 (jan. 2003), s. 1–10. [19] J. Bansiya och C. G. Davis. ”A hierarchical model for object-oriented design quality assessment”. I: IEEE Transactions on Software Engineering 28.1 (jan. 2002), s. 4–17.ISSN: 0098-5589.
