Tekniskt lyft av PaperLine

Uppgradering av klient till Single Page Application i ett Manufacturing

Execution System.

Technical lift of PaperLine

Upgrading of client to Single page Application in a Manufacturing Execution

System.

Filip Skogum

Alexander Bennetoft

Fakulteten för Hälsa, Natur och Teknikvetenskap

Datavetenskap

C-Uppsats 15hp

Handledare, Katarina Asplund

Examinator, Thijs J. Holleboom

18 jan -17

Abstract

This dissertation summarizes a project mission done at the requestor and company ÅF,

Karlstad. The project was to investigate the possibilities of upgrading parts of the system

named PaperLines which has outdated software. The system is used today at a paper mill for

tracking production and ease administrative work.

AMP, a SPA-platform for MES developed by ÅF, was used in the project to create a proof-of-

concept client with modernized user interface, support for odd screen resolutions and

smarter communication logics. Additionally, it was supposed to be able to run in the old

system, communicating with the server that was initially designed to work with the old client

that used outdated software.

During the development problems concerning the interlinking of the old client and the new

on a single computer and also cooperative communication between them on the same

server got revealed.

The project is seen as successful. A new client with modern user interface has been

produced including support for mobile usage. The client could in a near future even get to be

used in a live environment after evaluation made by ÅF.

Sammanfattning

Denna uppsats beskriver ett examensarbete utfört hos uppdragsgivaren och företaget ÅF i

Karlstad. Arbetet gick ut på att undersöka i möjligheterna att uppgradera delar av systemet

PaperLines utdaterade tekniker. Systemet används idag på pappersbruk för att spåra

produktionen och underlätta administrativt arbete.

AMP, en SPA-plattform utvecklad av ÅF, användes i projektet för att utveckla ett proof-of-

concept till det gamla systemet. Tekniker, ramverk och verktyg som ingår i plattformen är

bland annat HTML5, TypeScript, Aurelia och Kendo UI.

Under utvecklingen uppdagades problem som att samköra en gammal och en ny klient på en

och samma dator samt att få båda att kunna kommunicera med samma server. Dessa

utmaningar har trots allt uppnåtts.

Projektet ses som lyckat då en ny klient med modernt användargränssnitt tagits fram där

bland annat stöd för mobil användning finns. Klienten kan även komma att användas i skarp

miljö efter en validering gjorts av ÅF.

Förord

Vi vill tacka alla medarbetare på ÅF för sitt engagemang i projektet. Hjälpen vi fått av dem

har varit ovärderlig. Speciellt stort tack till eldsjälen Mikael Arvidsson för det han gjort för

oss. Mikael jobbar på samma avdelning vi suttit på denna termin och har ett betydande

deltagande i utvecklingen av AMP som ÅF tagit fram. Vi vill även tacka Katarina Asplund, vår

handledare på Universitetet, för hjälpen hon gett oss i att strukturera denna uppsats. Tack

går även ut till Katarina Friberg och Richard Hellberg på ÅF handledare på ÅF för möjligheten

vi fått att göra examensarbetet på ÅF samt er hjälp och stöd vi fått under tiden projektet

gått.

Innehåll

Abstract ....................................................................................................................................... 3

Sammanfattning ........................................................................................................................... 4

Förord .......................................................................................................................................... 5

Figurförteckning ........................................................................................................................... 9

1 Introduktion .............................................................................................................................. 1

1.1 Uppdragsgivare - ÅF ...................................................................................................................... 1

1.2 Syfte och mål ................................................................................................................................. 1

1.3 Sammanfattning av projektet ........................................................................................................ 2

1.4 Rapportens översikt ...................................................................................................................... 2

1.4.1 Bakgrund................................................................................................................................. 2

1.4.2 Design ..................................................................................................................................... 2

1.4.3 Implementation ...................................................................................................................... 2

1.4.4 Resultat ................................................................................................................................... 3

1.4.5 Slutsats ................................................................................................................................... 3

2 Bakgrund ................................................................................................................................... 4

2.1 Översikt av projektet ..................................................................................................................... 4

2.1.1 Kravspecifikation .................................................................................................................... 4

2.2 PaperLine ....................................................................................................................................... 5

2.2.1 Arkpack ................................................................................................................................... 6

2.3 Gamla klienten – ASP.NET ............................................................................................................. 7

2.3.1 Fördelar med Web Forms ....................................................................................................... 8

2.3.2 Nackdelar med Web Forms .................................................................................................... 8

2.4 Nya klienten – AMP ....................................................................................................................... 9

2.4.1 Utvecklingsmiljö – Visual Studio ........................................................................................... 10

2.4.2 Programmeringsspråk .......................................................................................................... 11

2.4.3 TFS (Team Foundation Server) ............................................................................................. 12

2.4.4 Bootstrap .............................................................................................................................. 12

2.4.5 Kendo UI ............................................................................................................................... 13

2.4.6 Aurelia.io .............................................................................................................................. 13

2.4.7 Gulp.js ................................................................................................................................... 13

2.5 Sammanfattning .......................................................................................................................... 14

3 Design ..................................................................................................................................... 15

3.1 Översikt ....................................................................................................................................... 15

3.1.1 Översikt över systemet ......................................................................................................... 15

3.2 Uppgradering av Front End ......................................................................................................... 17

3.2.1 Uppgradering av användargränssnitt ................................................................................... 17

3.2.2 Uppgradering av komponenter ............................................................................................ 18

3.3 Uppgradering av Back End........................................................................................................... 21

3.3.1 Före uppgraderingen ............................................................................................................ 21

3.3.2 Efter uppgraderingen ........................................................................................................... 24

3.4 Spegling av databas ..................................................................................................................... 27

3.5 Asynkron kommunikation ........................................................................................................... 28

3.6 Sammanfattning .......................................................................................................................... 29

4 Implementation ....................................................................................................................... 30

4.1 Inledning ...................................................................................................................................... 30

4.2 Implementation av grafiska komponenter .................................................................................. 30

4.3 Dataflöde ..................................................................................................................................... 32

4.4 NHibernate och databaskommunikation .................................................................................... 36

4.5 Problem och val av lösningar....................................................................................................... 38

4.6 Automatiskt genererade filer. ..................................................................................................... 43

4.7 Sammanfattning .......................................................................................................................... 44

5 Resultat ................................................................................................................................... 45

5.1 Resultat av krav ........................................................................................................................... 45

5.1.1 Går projektet att genomföra? .............................................................................................. 46

5.1.2 Samkörning av gammal och ny klient ................................................................................... 46

5.1.3 Sammanfogning av AMP och serverlagret ........................................................................... 47

5.1.4 Användargränssnitt .............................................................................................................. 47

5.1.5 Serverkommunikation .......................................................................................................... 47

5.2 Prestandajämförelse av gamla och nya tekniken ........................................................................ 48

5.2.1 Front end .............................................................................................................................. 48

5.2.2 Back end ............................................................................................................................... 48

5.3 Utvärdering av AMP teknikstack ................................................................................................. 49

5.4 Problem ....................................................................................................................................... 50

5.5 Sammanfattning .......................................................................................................................... 51

6 Slutsats ................................................................................................................................... 52

6.1 Utvärdering av projektet ............................................................................................................. 52

6.2 Vidareutveckling .......................................................................................................................... 52

6.3 Kundkontakt ................................................................................................................................ 53

6.4 Tidsåtgång ................................................................................................................................... 53

6.5 Slutord ......................................................................................................................................... 54

Referenser ................................................................................................................................. 55

Figurförteckning

Figur 1: MES PaperLine. .............................................................................................................. 6

Figur 2: Massa till Papper ........................................................................................................... 6

Figur 3: Ett exempel på MVC-modellen. .................................................................................... 7

Figur 4: Teknikstacken som användas i projektet AMP(Aurelia MES Platform) ........................ 9

Figur 5: MVVM-arkitekturen ramverket Aurelia följer ............................................................ 10

Figur 6: Kodexempel: Implementation av javascript ............................................................... 11

Figur 7: Kodexempel: Ett enkelt rutnät från biblioteket i Kendo UI. ....................................... 13

Figur 8: Klassdiagram över systemet PaperLine....................................................................... 16

Figur 9: Den gamla vyn i sin helhet .......................................................................................... 17

Figur 10: Den nya vyn i sin helhet ............................................................................................ 18

Figur 11: Rutnät från gamla vyn. .............................................................................................. 18

Figur 12: Rutnät uppritat av Kendo UI. .................................................................................... 19

Figur 13: Hantering av gränssnitt utan Bootstrap. ................................................................... 20

Figur 14: Hantering av gränssnitt med Bootstrap. ................................................................... 20

Figur 15: .aspx klass .aspx.designer.cs klass och .aspx.cs klass ................................................ 21

Figur 16: Dataflöde i det gamla systemet ................................................................................ 23

Figur 17: Klassdiagram över gamla systemets fyra stora komponenter .................................. 24

Figur 18: Dataflöde i nya implementationen. .......................................................................... 26

Figur 19: Klassdiagram över nya implementations fyra stora komponenter .......................... 27

Figur 20: Representation av Transferobjekt och Transferaggregat ......................................... 28

Figur 21: Asynkron kommunikation i Typescript ..................................................................... 29

Figur 22: Kodexempel: Implementation av Rutnät i både Web Form och Kendo UI .............. 30

Figur 23: Kodexempel: Kendo Contextmenu ........................................................................... 31

Figur 24: Kendo Contextmenu med ett menyobjekt ............................................................... 31

Figur 25: Kodexempel: Implementation av funktion i TypeScript-fil ....................................... 33

Figur 26: Kodexempel: Implementation av function i proxyobjektet ...................................... 33

Figur 27: Kodexempel: Implementation av Web-API ............................................................... 34

Figur 28: Kodexempel: Implementation av Response-objekt .................................................. 34

Figur 29: Kodexempel: Implementation av Request-objekt .................................................... 34

Figur 30: Kodexempel: Implementation av function i Serviceklass ......................................... 35

Figur 31: Kodexempel: Anrop från klient till server ................................................................. 36

Figur 32: Kodexempel: Proxyfactor med uppsättning av TCP-förbindelser ............................. 37

Figur 33: Representation av Interface mellan klient och server .............................................. 37

Figur 34: Kodexempel: Databasanrop från server ................................................................... 38

Figur 35: Kodexempel: Konfiguration av Mousetrap. .............................................................. 39

Figur 36: Kodexempel: Implementation av Mousetrap. .......................................................... 39

Figur 37: Web Forms representation av meddelanderuta. ..................................................... 39

Figur 38: Aurelias representation av meddelanderuta. ........................................................... 40

Figur 39: Utskriftsfunktion från Web Forms. ........................................................................... 42

Figur 40: Utskriftsfunktion från Aurelia.IO och Kendo UI ........................................................ 43

1

1 Introduktion

Detta projekt går ut på att skaffa kunskap kring och påbörja utvecklingen av den nya

webbaserade klienten till PaperLine, ett MES [1] (Manufacturing Execution System) som

utvecklas och säljs av uppdragsgivaren; ÅF, till kunden som är ägare till ett pappersbruk i

Sverige. Produkten används av kunden för att spåra produktionen i ett pappersbruk. Den

gamla klienten är idag baserad på .NET Web Forms [2], se avsnitt 2.3, för att efter kundens

önskemål efterlikna en skrivbordsklient. Dagens lösning har visat sig ha ineffektiv prestanda

med ofta långa väntetider mellan anrop och operationer. Klienten är dessutom inte

anpassad för mobila enheter eller enheter med annorlunda bildförhållande. Därför har ÅF

beslutat att pröva utvecklingen av en ny klient, baserad på dess egenutvecklade plattform.

Genom att utveckla klienten på den nya plattformen förenklas användandet på flera plan, till

exempel kan truckföraren ha PaperLine på en surfplatta i hytten. Klienten kommer att bli

mer responsiv och mobilanpassad samt bli mer prestandavänlig.

1.1 Uppdragsgivare - ÅF

ÅF [3] grundades 1895, då kallat Ångpanneföreningen. Föreningen gjorde initialt

besiktningsuppdrag på ångpannor och har genom historien varit betydande inom

utvecklingen av ångkraft, elektricitet, kärnkraft och digitalisering. Idag är ÅF med cirka 8500

medarbetare i mer än 30 länder ett konsult- och ingenjörsföretag som skapar lösningar inom

energi, industri och infrastruktur. Företaget har en nettoomsättning på ca 10 miljarder SEK

per år och driver projekt i länder över hela världen. På Karlstadskontoret vid stadsparken

jobbar ca 200 personer.

1.2 Syfte och mål

Målet med projektet är att analysera den gamla klienten, ta till vara på de bra delarna och

vidareutveckla delar i behov av förbättring enligt kravspecifikationen se avsnitt 2.1.1.

Därefter ska en början till ny klient skapas med några fåtal färdigställda vyer. Vyerna ska

sedan användas i en guide som görs till uppdragsgivaren. Guiden ska i sin tur beskriva

vidareutvecklingen av den nya klienten. Syftet är att säkerställa prestanda och öka

2

användareffektiviteten, det vill säga minimera den uppmärksamhet operatörer behöver

spendera på klienten.

Kunden är i denna en rapport referens till ett pappersbruk som drivs i Sverige.

Pappersbruket är ett integrerat bruk där hela produktionen av papper sker, ända från

pappersmassan till färdiga produkter i form av kartong och skrivarpapper.

1.3 Sammanfattning av projektet

Uppgiften var att ta reda på hur mycket nytta en ny klient kan göra och om den kan implementeras

utan stora konsekvenser. Därpå ska ett en prototyp byggas och presenteras.

Uppgiften anses vara slutförd.

1.4 Rapportens översikt

Rapporten innehåller 5 kapitel, exklusive detta kapitel, som beskrivs kort nedan:

1.4.1 Bakgrund

Kapitlet Bakgrund ger en övergripande bild av projektets syfte och mål. Kapitlet beskriver

även kravspecifikationen och uppdragsgivaren. Därefter introduceras systemet PaperLine

och en beskrivning av den gamla klienten samt den nya klienten och alla tillhörande tekniker

som klienterna nyttjar.

1.4.2 Design

Detta kapitel ger en systemöversikt över PaperLine, beskriver fördelarna med den nya

klienten samt diskuterar skillnaden på den gamla och den nya klienten. Här nämns även vilka

förbättringar den nya klienten för med sig. Sist beskrivs hantering av data från databasen

och hur kommunikationen till den fungerar.

1.4.3 Implementation

Implementationskapitlet beskriver genomförandet på en detaljerad nivå. Det täcker

implementationen av såväl grafiska komponenter och vy-komponentens kommunikation

som dataflödet genom hela systemet. Vidare finns även diskussion kring problem och val av

lösningar. Här motiveras lösningsvalen och det ges även en djupare förståelse för tekniken.

3

1.4.4 Resultat

Detta kapitel reflekterar över alla fördelar med den nya klienten samt diskuterar resultatet

utifrån kravspecifikationen. Därefter kommer ett avsnitt som jämför gamla och nya klienten

prestandamässigt och ett avsnitt som utvärderar tekniken i den nya klienten. Sist diskuteras

problem som uppstod under projektets gång.

1.4.5 Slutsats

Slutsatsen utvärderar uppdraget och summerar erfarenheten det givit. Kommentarer kring

vidareutveckling och kortfattat om kontakten med kunden. Kapitlet beskriver även

tidfördelningen på projektet och avslutar med slutord.

4

2 Bakgrund

I detta kapitel presenteras tekniken i den nya klienten. Kravspecifikationen beskrivs och

tolkas. Ett avsnitt går igenom vad PaperLine är och vad det används till. Den gamla klienten i

PaperLine beskrivs här tillsammans med sin systemarkitektur MVC(Model, View, Controller)

[4]. Även verktyg, tekniker och ramverk som använts i projektets nya klient samt dess

systemarkitektur MVVM(Model, View, ViewModel) [5] förklaras här för att vidare kunna

förstå diskussioner kring designen i kapitel 3.

2.1 Översikt av projektet

Projektet beskriver det initiala steget i bytet av klient för systemet PaperLine och innehåller

dess planering samt implementering av teknikstacken AMP(Aurelia MES Platform, där MES

står för ’Manufacturing Execution System’), vilken är baserad på en rad verktyg och ramverk,

se avsnitt 2.4.

Utvecklingsmiljön har under projektets gång varit Visual studio [6], se avsnitt 2.4.1 och

arbetet har, som tidigare nämnts i introduktionen, framförallt utgått från att uppgradera en

vy i klienten, samt att i mån av tid uppgradera fler vyer med det slutliga målet att alla gamla

vyer i systemet blivit uppgraderade med den nya tekniken(AMP).

2.1.1 Kravspecifikation

Projektet innebar från start en uppgradering av det existerande systemet PaperLines klient

från dåvarande Web Forms till en mer modernare och snabbare klient i form av bland annat

HTML5 [7](se avsnitt 2.4.2). Eftersom PaperLine i dagens läge omfattar stora delar av

kundens produktionssystem innebär det att en uppgradering av hela systemet skulle

medföra tusentals timmars arbete. Därför valdes att en eller två vyer skulle uppgraderas.

Projektet skulle även innehålla en utredning av vilka problem som kan uppstå vid denna

uppgradering.

Efter små ändringar hos kunden, ändrades projektet och kravspecifikationen till att

demonstrera en vy som ett proof-of-concept, för att senare demonstrera och visa den

uppgraderade vyn och bevisa fördelar med tekniken AMP.

Sammanfattningsvis ingår följande punkter i projektets specifikation:

5

Kan gammalt system och ny teknik samverka?

Uppgradera den gamla klienten med en uppgraderad vy som proof-of-concept.

Kraven som sattes upp var generella vilket gjorde att delkrav under implementationen sattes

upp. Delkraven var inget som var i diskussionen med kunden utan bestämdes i samråd med

de involverade i projektet på ÅF.

Ett av de krav kunden hade, men som lågprioriterades då planering av projektet gjordes, var

att den grafiska designen skulle behållas till största möjliga mån. Detta då kunden till så stor

del som möjligt skall kunna känna igen sig i systemet och snabbt kunna återfå högt

produktionstempo. Fokus lades istället på uppgradering av visuella delar utan på

prestandan.

2.2 PaperLine

PaperLine är sedan 2008 utvecklat av ÅF som ett MES. PaperLine är byggt för att övervaka

och spåra produktionen i pappersindustrin. PaperLine ligger mellan lagren automation och

affärssystem vilket innebär att PaperLine tar in basdata från affärssystemen och returnerar

produktionsdata, vilket man ser i figur 1. Från lagret automation får PaperLine

planeringsdata för att sedan vidarebefordra information om det producerade materialet till

affärssystemet.

Högst upp finns systemet som tillhandahåller information om vad som skall produceras,

framtida produktion av order, planering och lagerstatus.

Lagret i mitten tillhandahåller information om utvärderingar kring producerade order samt

utvärderingar om vad som skall produceras.

Till sist det undre lagret, som består av många olika system, maskiner och data. Lagret har till

uppgift att tillhandahålla system till var och en av maskinerna i produktionen. Där ingår allt

från sensorer till teststationer för order som produceras.

6

Figur 1: MES PaperLine.

2.2.1 Arkpack

Under projektets gång valde ÅF, till en början, att en vy skulle uppgraderas och efter

diskussioner med medarbetare på ÅF ledde det till att projektet initialt lyfter vyn

Arkpackning, vilket är en av de vyer i kategorin pack som är inringat i figur 2 . Arkpack är en

av de nuvarande omkring 5 vyer som existerar i kategorin pack men har i PaperLine klassats

som efterbehandling.

Figur 2: Massa till Papper

7

Arkpackning är en senare del av produktionslinjen i fabriken. Figur 2 visar att packningen

ligger efter utskott och efterbehandlingen vilket mynnar ut i lagret. Till arkpack kommer

specifika ark in till avdelningen för att packas till ”Reams”, vilket är ett mått på ett visst antal

pappersark. Antalet ark i ett ream kan variera.

Packningen sker till stor del automatiskt med hjälp av robotar vilket innebär att

arkpacksbilden i PaperLine-vyn kan operera utan konstant uppsikt från användare.

2.3 Gamla klienten – ASP.NET

Systemet PaperLines klient som existerar idag hos kunden är byggt med Web Forms, en del

av Microsofts ramverk ASP.NET [8]. Ramverket är byggt med öppen källkod för att bland

annat producera webbapplikationer. Web Form, som är en av ramverkets grundblock när

det kommer till webbapplikationer, är designat enligt arkitekturen MVC, se figur 3.

Figur 3: Ett exempel på MVC-modellen.

I modellens tre delar är det vyn(View) användaren kommer se, modellen(Model) skickar

information från databasen vid uppdateringar som användaren skapat via

kontrollen(controller) i form av inmatningar i vyn.

8

2.3.1 Fördelar med Web Forms

User Controls

User Controls [9] är grafiska komponenter som utvecklare själva kan skapa och återanvända.

Dessa komponenter byggs upp av redan existerande komponenter ASP.NET och Visual

Studio erbjuder, vilket gör att de mycket liknar Web Forms-sidor. Komponenter måste sedan

bäddas in i redan existerande Web Forms-sidor då de inte fungerar utan att implementeras i

andra Web Forms. User Controls kan göra stora och repetitiva arbeten enklare.

2.3.2 Nackdelar med Web Forms

View State

En av nackdelarna med Web Forms är hur ramverket behandlar webbapplikationen vid

uppdateringar och hämtning av data. Web form måste vid dessa fall slänga all data sparad på

sidan för att sedan hämta hem allt på nytt. Detta medför att mycket onödig data kommer

skickas mellan klient och server. Web Forms lösning på problemet blev att skapa

lagringsutrymmen kallade View- och Sessionstates [10] [11] som till stor del fungerar som en

cookie fungerar i en webbläsare. I lagringsutrymmena kan data tillfälligt sparas som kommer

användas då sidan laddat om eller data kommit tillbaka från servern. Trots att dessa

lagringsutrymmen existerar kan inte all data sparas undan i utrymmena, detta för att vid

med stora mängder sparad data tillkommer prestandaproblem då view och sessionstates

måste följa med ner till servern och tillbaka upp igen. Men så länge kommunikationen

behålls enkel kan dessa problem undvikas.

9

2.4 Nya klienten – AMP

Figur 4: Teknikstacken som användas i projektet AMP(Aurelia MES Platform)

Den nya klienten som ersätter Web Forms innehåller komponenter bestående av bland

annat HTML-filer och Typescript-filer(se avsnitt 2.4.2). Utöver det används en rad

komponenter och verktyg som beskrivs nedan. Den nya klienten jobbar på en helt ny

plattform kallad AMP där Aurelia (se avsnitt 2.4.6) [12] är det ramverk som används för

struktur och kodning. Aurelia och är baserat på systemarkitekturen MVVM(Model, View,

ViewModel).

MVVM-arkitekturen, se figur 5, är ett alternativ till MVC och går ut på att skilja

användargränssnittet från dess logik. Delen ’View’ innehåller grafisk struktur, layout och kod

för kommunikation till ’View-Model’, det vill säga kod som inte innehåller logik. Model är

precis som i MVC den enhet som innehåller all logik.

10

Figur 5: MVVM-arkitekturen ramverket Aurelia följer

2.4.1 Utvecklingsmiljö – Visual Studio

Microsoft har sedan 1997 släppt nya versioner av sin utvecklingsmiljö Visual Studio som

innehåller en handfull kompilatorer för programmeringsspråk. Beroende på

programmeringsspråk kan användaren få automatisk komplettering och automatisk

generering av sin kod. Utvecklingsmiljön omhändertar projektets filsystem, bygger och kan

exportera projektet som en produkt färdig att installera.

11

2.4.2 Programmeringsspråk

Nedan beskrivs de programmeringsspråk som används i projektet.

C#

”C-Sharp” [13] är vad många kallar Microsofts version av Java [14]. C# är ett objektorienterat

och hårt typat1 programmeringsspråk. Det är en del i Microsofts .NET-plattform och är

officiellt baserat på C++ [15]. Likt Java kompileras C# först till bytekod2 och körs sedan i en

virtuell maskin. Detta tillvägagångssätt är självklart prestandakrävande men gör språket

plattformsoberoende vilket ger det fler applicerbara områden.

HTML5

År 2014 fastställdes version 5 av standarden som HTML använder sig av i uppbyggnad av

World Wide Web. HTML som är ett märkspråk använder sig av så kallade taggar för att skapa

allt från indelade sektioner till att importera bilder. Taggarna definierar typerna av en

komponent på webbsidan.

Språket går att expandera utanför sina egna ramar med hjälp av script i form av JavaScript

[16](se avsnittet nedan) och andra tillägg. Exemplet i figur 6Figur 6: beskriver en inkludering

av JavaScript till en HTML-sida. Verktygen och ramverken som beskrivs senare i bland annat

avsnitt 2.4.4 och 2.4.5 är exempel på sådana tillägg.

Figur 6: Kodexempel: Implementation av JavaScript

JavaScript

JavaScript är som tidigare nämnts en påbyggnad till HTML där fokus ligger på att manipulera

komponenter i webbsidor på framförallt klientsidan av webbläsaren. Språket kan på

klientens sida utvärdera, beräkna och presentera användarens inmatning utan anropa till

servern eller att behöva ladda om sidan. Med tiden har JavaScript utvecklats och gått från att

bara vara ett klientbaserat språk till att även kunna implementeras och användas bland

annat på webbservrar.

1 Hård typning, även statisk typning, är när variabler tilldelas en specifik datatyp vid kompilering och behåller den under resten av programmets livslängd. 2 Bytekod är en slags kompilerad programkod. Till skillnad från maskinkod, som är knuten till en specifik plattform, är bytekod abstrakt eller virtuell eftersom den inte är bunden till en maskinarkitektur

12

TypeScript

TypeScript [17] är ett scriptspråk som transpilerar3 till JavaScript. TypeScript, som är byggt i

öppen källkod av Microsoft, ger användaren möjlighet att koda hårdtypat och

objektorienterat. TypeScript som språk är influerat av JavaScript, Java och C# vilket gör att

utveckling med Typescript blir klassbaserad. Transpilatorn som ingår i TypeScript översätter

TypeScript till JavaScript-kod samt skapar upp en mappnings fil som knyter samman den

traspilerade JavaScript-filen och TypeScript-filen. Denna sammanfogning görs för att enkelt

felsöka koden under exekvering. Skulle fel inträffa kommer mappningen att hänvisa vart

felet inträffat i TypeScript-koden trots att felet inträffade i JavaScript-koden.

CSS

CSS [18] står för ’Cascading Style Sheets’ och är kod som beskriver hur grafiska komponenter

bland annat ska bete sig, positionera sig, förhålla sig med hänsyn till skärmupplösning samt

storlekar på text och tillgängliga fonter ingår i CSS. Varje enskild HTML-sida kan inkludera sin

egen CSS-kod men i detta projekt kommer mycket av CSS-hantering ske automatiskt med

hjälp av Bootstrap [19] och Kendo UI [20].

2.4.3 TFS (Team Foundation Server)

TFS [21] är ett nätverksbaserat versionshanteringsverktyg som låter programmerare enkelt

kunna jobba på samma projekt och bidra med varsin del kod till lösningen. TFS migrerar ihop

filerna och behåller all historik så man alltid kan stega bakåt till föregående ändringar i

projektet.

2.4.4 Bootstrap

Bootstrap är ett HTML-och CSS-ramverk där hemsidor dynamiskt kan redigera sin grafik

beroende på plattformen och enhetens skärmstorlek. Användning av Bootstrap sker

framförallt då utvecklare vill skapa webbapplikationer och webbsidor för såväl

datoranvändning som mobilanvändning.

I Bootstrap manipuleras så kallade “stylesheets” automatiskt när användaren delger grafiska

komponenter olika klasser och kan på så sätt bestämma hur webbsidan skall se ut.

3 En transpilator är en typ av kompilator som använder kod från ett programmeringsspråk och genererar ekvivalent kod i ett

annat programmeringsspråk.

13

Stylesheeten är även modulära vilket innebär att vissa delar till viss del går att ändra på för

att skapa ett mer personligare gränssnitt.

2.4.5 Kendo UI

Kendo UI är ett utvecklingsverktyg för webbsidor. Biblioteket innehåller grafiska

komponenter i form av bland annat grafer, menyer och kartor som kan inkluderas till

webbsidan för en mer användarvänlig upplevelse. Kendo UIs grafiska komponenter gör att

den visuella utvecklingen av webbsidor blir enklare och snabbare för utvecklare. I figur 7Figur

7: Kodexempel: Ett enkelt rutnät från biblioteket i Kendo UI. nedan visas hur Kendo UI i en

inbyggd HTML-scriptfunktion kan bygga upp ett simpelt men stilrent rutnät.

Figur 7: Kodexempel: Ett enkelt rutnät från biblioteket i Kendo UI.

2.4.6 Aurelia.io

Aurelia.io är ett SPA-ramverk byggt enligt MVVM-arkitekturen för att enkelt kunna skapa och

strukturera användargränssnitt. SPA [22] står för Single Page Application, vilket innebär att

sidan aldrig ska behöva laddas om utan användaren skall känna som om sidan hela tiden

dynamiskt laddar in ny data. Aurelia.io utgår från ett skelett där fördefinierade funktioner

finns för att med hjälp av verktyg som TypeScript och JavaScript enkelt kunna utveckla

webbsidor och webbapplikationer. Verktygets stora fördel kan framförallt ses då storleken

på programmets kod går från i vanliga fall vara överskådligt till oöverskådlig. I fallet då

aurelia används kommer utvecklarens kod att förbli överskådlig även vid stora projekt.

2.4.7 Gulp.js

Gulp [23] är ett kompileringsverktyg med bland annat enhetstestning och minimering av

kod. Stegen för funktioner i Gulp sker automatiskt via flöden genom processer där varje

process lägger på en ny funktion, t.ex. kan en process minimera koden genom att ta bort

onödiga delar utan att förändra grundfunktionaliteten. Efter den processen kan programmet

14

skicka utdata till en debug-komponent för felhantering och slutligen skicka ut resultatet av

alla processer till en specifik mapp.

2.5 Sammanfattning

Detta kapitel har presenterat projektets bakgrund där en kravspecifikation för projektet och

det gamla system kunden använder sig av idag har beskrivits. Kapitlet har även beskrivit de

tekniker och de verktyg som använts i projektet.

15

3 Design

I detta kapitel beskrivs programmets nya klient i detalj samt förbättringar sett mot den

gamla versionen som bygger på ASP.NET. Det förs även diskussioner kring de problem som

fanns i den gamla klienten och hur dessa problem tacklas i den nya plattformen. I design-

kapitlet beskrivs även hanteringen av databasanrop och den metod som används för att

spegla datamängder till klienten. Sist diskuteras den asynkrona kommunikationen i den nya

klienten.

3.1 Översikt

Den nya klienten som kommer implementeras i projektet bygger i dagsläge på en klient från

ett annat projekt ÅF jobbat med. Klienten är en webbaserad applikation för surfplattor hos

ett företag som driver en stor återvinningsstation och används vid uppgraderingen som mall

för att försöka hålla en standard för hur projekt skall se ut producerade av ÅF med

teknikstacken AMP.

Mallen innehåller bland annat komponenter för utveckling av webbapplikationer. En av

komponenterna är vyer, vilket i AMP är en SPA(Single Page Application). SPA innebär att

sidan aldrig behöver laddas om utan hämtar endast nödvändig data på begäran och

uppdaterar sidan bitvis.

3.1.1 Översikt över systemet

Klassdiagrammet representerat i figur 8 beskriver systemet i sin helhet, där klient, server,

common och windows service ingår. Figuren beskriver även hur kommunikationen mellan

delarna i systemet fungerar. Lagret common tillhandahåller all kommunikation mellan klient,

server och windows service vilket även beskrivs vidare i avsnitt 3.3.1.

I figuren syns klienten där vyerna, bland annat gamla och nya Arkpack, ligger. Servern som

tillhandahåller kommunikationen med databasen samt windows services som tillhandahåller

bland annat meddelandetjänster syns också här.

16

Figur 8: Klassdiagram över systemet PaperLine.

Client Windows service

Common

Server

Returnerar:

Data

Förbindelser

Skickar:

Andvändar-

förfrågningar

Returnerar:

Data

Skickar:

Andvändar-

förfrågningar

17

3.2 Uppgradering av Front End

Nedan beskrivs skillnaderna i det grafiska utseendet mellan Web form i den gamla klienten

och AMP i den nya klienten.

3.2.1 Uppgradering av användargränssnitt

Gamla vyns användargränssnitt.

Figur 9 representerar den gamla vyns användargränssnitt, uppritad med komponenter från

.NET Web Forms. Upplägget är ganska simpelt med få inmatningsfält och fler textfält där

information om order kommer fram. Inmatningsfälten kommer ofta från skannad order och

mätinstrument som därefter packas då inga fel uppstått. I gränssnittet ingår även ett antal

rutnät där bland annat meddelanden gällande order från tidigare steg i produktionen finns

samt information om order som redan packats. Vyns syfte är simpelt; ta in mätdata,

kontrollera att allt stämmer, uppdatera databasen om att ordern blivit packad samt visa

användaren relevant data för ordern och andra order.

Figur 9: Den gamla vyn i sin helhet

18

Nya vyns användargränssnitt

I figur 10 demonstreras den nya vyns användargränssnitt med komponenter uppritade med

bland annat Kendo UI.

Gränssnittet har här ett mer modernt utseende men med samma komponenter där de

liggandes på i princip samma plats som i den gamla vyn.

Figur 10: Den nya vyn i sin helhet

3.2.2 Uppgradering av komponenter

Kendo UI

Vid uppgradering av front end för systemet valdes, som tidigare nämnt, att använda sig av

det grafiska utvecklingsverktyget Kendo UI istället för Web Forms utdaterade och gamla

design av grafiska komponenter. I figur 11 och figur 12 kan dessa förändringar ses.

Figur 11: Rutnät från gamla vyn.

19

Figur 12: Rutnät uppritat av Kendo UI.

Komponenter som ritas upp av verktyget Kendo UI kommer till stor del att likna de gamla

komponenterna uppritade av Web Forms. En av anledningarna till att utseendet behålls är

att till största del göra övergången mellan gammalt och nytt system så enkelt som möjligt för

kunden.

Bootstrap

Som tidigare nämnt är Bootstrap ett responsivt ramverk för användargränssnitt. Där en av

funktionaliteterna som inkluderats är att bygga upp användargränssnitt utefter plattform.

Detta innebär att då storleken ändras på plattformen kommer Bootstrap att arrangera

layouten olika för att till bästa möjlighet illustrera vyns ursprungliga utseende.

Som illustreras i figur 13 och 14 kan skillnader ses mellan vanlig hantering av webbsidor, som

inte tar storlek på plattform i hänsyn och Bootstraps hantering av layout.

Vid hantering av layout utan Bootstrap kommer, som demonstrerat i figur 14, komponenter

inte alltid synas på den plattform man använder. För full användning av sidan på bland annat

mobil tvingas därför användaren zooma ut vyn, vilket medför att vyn blir liten och oläsbar.

Bootstrap hanterar alla delar av hemsidan individuellt och kan strukturera om dem, som att

trycka ihop dem och sträcka ut dem. Även placera dem, till exempel, under varandra eller vid

sidan av varandra.

Figur 13 visar hur Bootstrap löser de situationer då användning av mobil sker. Genom att

stapla om komponenter på höjden istället skapar Bootstrap ett mer mobilvänligt

användargränssnitt.

20

Figur 14: Hantering av gränssnitt utan Bootstrap.

Figur 13: Hantering av gränssnitt med Bootstrap.

21

3.3 Uppgradering av Back End

3.3.1 Före uppgraderingen

Vyns uppbyggnad

Skapandet av en vy i ASP.net görs till stor del genom tre komponenterna aspx, aspx.deginer

och aspx.cs och denna visualiseras i figuren Figur 15 där komponenterna aspx och

aspx.designer.cs utgör lagret där det grafiska användargränssnittet utvecklas.

Figur 15: .aspx klass .aspx.designer.cs klass och .aspx.cs klass

Aspx klassen tillhandahåller grafiska html-komponenter samt ASP.NETs egenbyggda

komponenter vilket innebär att klassen försöker att till så stor del som möjligt frångå logiskt

uttryck.

Inmatning från användare Data från server till användare

22

Aspx.designer-klassen är en brygga som genereras automatiskt av Visual Studio och skapad

för att enklare kunna utveckla och hantera koden i aspx.cs klassen för de komponenter

skapade i det grafiska användargränssnittet.

Till sist är det aspx.cs klassen vars uppgift är att hantera alla logiska operationer. Här sker allt

från visuella ändringar i de grafiska komponenterna till serveranrop och beräkningar av data.

Data som kommer hit kan vara från användaren där utvärdering av inmatning behöver göras

eller serverdata som skall sållas och visas på vyn.

Dataflöde

Dataflödet för ett Web Form är i ett “fågelperspektiv” enkelt att begripa och kan ses som ett

bra val för en webbapplikation som använder sig av mycket serverkommunikation då en av

fördelarna med Web Form är kontrollen man har över servern.

Användningen av webform sker i tre steg med serverns sida inräknat. Dessa tre steg visas i

figur 16 och beskrivs som följer.

1. Klassen aspx tillhandahåller information kring vyns element och dess identifierare.

Därifrån kommer information från användaren skickas vidare till aspx.cs klassen

2. Klassen aspx.cs är code-behind till Web Forms. Här sker alla logiska funktioner, anrop

till servern, vyhantering samt valideringar. Det kan, som tidigare diskuterats, vid stora

projekt skapa komplex och icke hanterbar kod. Trots detta är server-anropen relativt

simpla utifrån klientens perspektiv.

3. Detta sista steg i kommunikationen med servern sker med fördefinierade

“endpoints” [24] klienten kan koppla upp sig mot. Därifrån hämtas önskad data som

sedan skickas tillbaka till aspx.cs klassen och sedan upp till användaren.

23

Figur 16: Dataflöde i det gamla systemet

Klassdiagram

I figur 17 visas ett mer ingående klassdiagram samt hur en vy hämtar data från databasen

och servern.

Då vyn skall hämta data från databasen krävs, som beskrivs avsnitt 4.4, först förbindelser till

servern från klassen ProxyFactory som är lokaliserad i delprojektet common. Det sker genom

funktionen Get. Förbindelserna(som Microsoft döpt till kanaler) innehåller den endpoint till

servern där TCP(Transmission Control Protocol)-förbindelse [25] sätts upp.

För att sedan knyta samman klient och server skapas ett mellanlager kallat IService. IService

är ett interface för asynkron kommunikation(se avsnitt 3.5) där bland annat det så kallade

24

transferobjektet(se avsnitt 3.4) [26] skickas från databasen till klient och vy via .NET-

ramverket WCF(Windows Communication Foundation) [27].

Figur 17: Klassdiagram över gamla systemets fyra stora komponenter

3.3.2 Efter uppgraderingen

Vyns uppbyggnad

Uppbyggnaden av de nya vyerna med hjälp av AMP uppdelas till skillnad från de gamla

vyerna i flera delar. Likheterna i sin helhet kan dock fortfarande ses då tre delar fortfarande

bygger upp grunden, SPA, Web-API [28] och Service och Server. Kommunikationen har dock

förflyttats och delats upp mellan fler lager. Den logiska koden existerar inte längre i en klass,

utan har här blivit uppdelad i fler delar där var och en tillhandahåller egna funktionaliteter.

Högst upp och närmast användaren ligger HTML och TypeScript filer som tillsammans kallas

vy-komponenter. Vyns grafiska gränssnitt samt presentationslogiken definieras av dessa två

filer. Att frigöra och dela upp logik till specifika filer och klasser medför att utveckling av

webbapplikationer blir enklare och lättare att underhålla.

Till varje vykomponent finns ett objekt som abstraherar bort hanteringen av

kommunikationen, det vill säga Servicelagret och Web-API(även kallat Controller, ska inte

förväxlas med Controller i gamla klientens struktur). Objektet är döpt till proxy då

kommunikationen går via dessa objektet som en mellanhand för att låta vyn tro att den har

Client

Aspx.cs

LoadData();

Server

Service

GetData();

Databas

Common

IService

GetData();

Proxy

Get();

Create();

WCF –

Skickar

Transferdata

WCF –

Skickar

Transferdata

TCP-

förbindelser

25

direktåtkomst till metoder liggande i Web API(beskrivs nedan). HTML-filen, TypeScript-filen

och proxyklassen utgör strukturen för SPA.

Mellanlagret Web API och Service utgör kommunikationen mellan klient och server. Web-

APIs uppgift är att exponera serverns metoder för klienten. Till varje Web-API skall en

serviceklass finnas, den tar rollen serverkommunikation i nya tekniken.

Serverkommunikationen som tidigare beskrevs existerade i aspx.cs klassen i webform.

Servicen tillhandahåller kommunikationen med servern och skapar response på de

förfrågningar som klienten och användaren utfört och som TypeScript-filen sedan kan

presentera i vyn.

Dataflöde

Dataflödet i den nya implementation, illustrerat i figur 18, visar hur data via objekt

bestående av olika TypeScript-filer, HTML-filer och C#-klasser bygger upp den nya

implementationen av PaperLine. De tre delarna klient, mellanlagret och server mellan

användare och server kan beskrivas som följer.

1. Användare gör en förfrågan i en av vy-komponenterna i webbapplikationen.

2. TypeScript-filen behandlar förfrågan med den funktion som är länkad samman med

inmatningen, för att sedan skickas vidare via den uppsatta Proxyklassen.

3. I denna specifika proxy-klassen, som varje HTML och TypeScript-fil har, finns

fördefinierade ‘response’-funktioner som tar in förfrågan och skapar ett ‘request’-

meddelande. ‘Response’-funktionerna har även som krav att ge ett så kallat ‘promise’

[29].

4. När proxy-objektet skapat ett Request skickas detta vidare till Controllern.

5. Via controller skickas information direkt vidare till services där kommunikationen till

databasen sätts upp.

6. Via kommunikationen sätts direkta förbindelser upp till fördefinierade endpoints i

servern.

7. Information hämtas ut från servern och databasen och returneras tillbaka till Proxy

som ett response.

8. När meddelandet kommer tillbaka till proxyn skickas meddelandet vidare till vyns

TypeScript-fil som tar hand om responseobjektet sorterar ut rätt data och placerar

det på rätt plats. Typescript-filen kan även utföra simpel logik på data servern skickat

26

tillbaka då datamängderna ofta kommer som transfersobjekt där mycket data

samlats, för lättare överföring från databasen.

Figur 18: Dataflöde i nya implementationen.

HTML

.ts

Proxy

Controller

Server

Aurelia(klient)

Request Response

Web-Api & Service

Services

Request Response

27

Klassdiagram

Dataflödet som beskrivs i avsnitt 3.3.2 kan beskrivas med hjälp av klassdiagrammet i figur 19.

Figur 19: Klassdiagram över nya implementations fyra stora komponenter

Likt diagrammet i avsnitt 3.3.1 sätts förbindelserna till servern från klienten upp via

ProxyFactor och sedan via interfacet IService. Skillnaden mellan gammalt och nytt är att

istället för en klass som tillhandahåller både logik för vy och serverkommunikation görs det i

separata klasser i den nya klienten. Detta innebär att serverkommunikationen och

uthämtning av endpoints från ProxyFactor i den nya klienten görs av serviceklassen.

3.4 Spegling av databas

Databasen som existerar i projektet är en kopia av den verkliga produktionsdatabasen över

PaperLines all produktionshistorik ute hos kunden, vilket innebär att stora mängder av data

måste hanteras vid databasanrop.

För att på ett enkelt sätt samla all relevant data från databasen till klient har man valt att

skapa så kallade transfer-objekt. Dessa objekt fungerar som en spegling av databasens

tabeller, vilket gör hanteringen av data mycket mer överkomlig vid utveckling av klientens

och serverns kommunikation.

Server

Service

GetData();

Databas

Common

IService

GetData();

Proxy

Get();

Create();

Client

.ts

LoadData();

Service

LoadData();

WCF –

Skickar

Transferdata

WCF –

Skickar

Transferdata

TCP-

förbindelser

28

Dessvärre existerar relevant data för order ofta i många olika tabeller vilket gör anrop till

databasen där produktinformation skall returneras ibland stora och komplexa. Lösningen till

detta problem är då att samla alla relevanta transfer-objekt i ett så kallat transferaggregat.

Transferaggreganten fungerar och liknar till stor del ett transferobjekt med skillnaden att

transferaggregat kan grupperar såväl transferobjekt som andra transferaggregat i sig själv,

vilket innebär stora fördelar för utvecklaren vid anrop av databasen men har även sina

nackdelar. Problemet i vissa fall med transferaggregantens transferobjekten är att de i

många fall kommer fyllas med all information som existerar i databasens tabell. Detta

innebär att mycket onödig information kommer upp till vy komponenterna.

Denna nackdel skapar inga stora problem vid små mängder data då det som visas i figur 20

kan vara enklare att skapa aggregat-objekt med redundans för att enkelt komma åt mer

information med mindre kod. Men kan vid större mängder data skapa problem i

kommunikationen mellan databas och klient.

Figur 20: Representation av Transferobjekt och Transferaggregat

Figur 20 beskriver en del i ett transferaggregat där fler transferaggregat kan inkludeas med

fler transferobjekt för att få ut mer information från databasen.

3.5 Asynkron kommunikation

En viktig del av nya klientens kommunikation i projektet är hur information skickas

asynkront. Asynkron kommunikation innebär att klientsidan inte stannar andra operationer

och bara väntar på informationen som hämtas från servern. Klienten fortsätter istället med

andra uppgifter och när svar kommer från servern behandlas det som en ny uppgift. Den

asynkrona kommunikationen utförs i TypeScript med funktioner som illustreras i figur 21 .

29

Figur 21: Asynkron kommunikation i Typescript

I exemplet visas hur ett resultat genom funktionen searchOrder i Proxyobjektet kommer, då

korrekt returnering skett, att hamna i den temporära variabeln searchResult som sedan

lägger resultatet i objektet this.orders. Detta utförs bara när ett resultat har kommit tillbaka

från databasen, därav funktionen .then(). Det hindrar inte andra funktioner från att utföra

sina uppgifter.

3.6 Sammanfattning

Detta kapitel har täckt designen i den nya klienten AMP som för tillfället används parallellt

med den gamla klienten. Kapitlet beskriver även ingående skillnaden mellan dataflödet i den

gamla klienten och den nya. Detta följdes av en beskrivning av data som färdas i dataflödet

mellan klient och server samt hur skillnaderna visar sig mellan de grafiska komponenterna i

vyn.

30

4 Implementation

4.1 Inledning

I detta kapitel beskrivs ingående mycket av projektet implementationer. Kapitlet omfattar

även några av de redan existerande lösningarna i den gamla klienten samt kommunikationen

mellan server och databas. De gamla implementation inkluderades i kapitlet då det ger en

bättre förklaring av fullständig kommunikation mellan klient och databas.

4.2 Implementation av grafiska komponenter

Aurelia-Kendo UI Bridge

Aurelia-Kendo UI Bridge [30] är ett hjälpmedel för att slippa så kallad wrapper code, det vill

säga importering av hjälpfunktioner. Aurelia-Kendo UI Bridge ger programmeraren möjlighet

att använda Kendo UI-komponenter i Aureliaapplikationer, som huvudsakligen är gjorda för

vanliga HTML-sidor. Därmed använder man taggar som börjar med ak(Aurelia Kendo), till

exempel <ak-grid> är Kendo Grid.

Kendo Grid

Som tidigare beskrivet i avsnitt 3.3.2 visas den grafiska skillnaden mellan rutnät uppritat i

den gamla(Web Forms) och den nya tekniken(AMP). Skillnaden är ytterst liten och samma

gäller för implementation för att rita upp rutnäten. Web forms använder sig av objektet

GridView för att åskådliggöra ett rutnät medan AMP utnyttjar Kendo UI:s inbyggda

funktioner för rutnät. I figur 22 demonstreras skillnaderna mellan gammalt och nytt. Båda

bär på inställningar som kan manipuleras för att få fram den önskvärda grafiska

komponenten. Den markanta skillnaden ligger i vad Kendo UI erbjuder i form av tillägg till

sina komponenter, vilket vidare beskrivs i avsnitt 4.5. Figuren beskriver den gamla klienten

till vänster och den nya till höger.

Figur 22: Kodexempel: Implementation av Rutnät i både Web Form och Kendo UI

31

Att sedan föra in data in i rutnätet sker på liknande sätt, båda objekten tar in listor i form av

transferobjekt in till en datasource. Denna datasource i GridView [31] kan bland annat

behandla objekt som Datatable [32](en tabell i C#), Dataset [33](en kollektion av Datatable),

och IList [34](en kollektion av objekt), dock kan inte Kendo UI behandla alla objekt som

GridView kan, men i det fall blir det inte några förhinder då gamla vyns rutnät använder sig

av IList vilket datasource i ’Kendo UI’ kan behandla.

Kendo Contextmenu

Kendo Contextmenu [35] är en högerklicksmeny i Kendos grafiska bibliotek. Funktionen går

endast att binda till andra Kendo UI-komponenter.

Implementation av komponenten Kendo Contextmenu utförs likt implementationen av

Kendo Grid. Figur 23 visar hur, likt Kendo Grid, även Kendo Contextmenu kräver vissa

inställningar för att få fram de önskvärda design på komponenterna, bland annat

inställningar om vart Contextmenu skall visa sig.

Figur 23: Kodexempel: Kendo Contextmenu

Den komponent som sedan visas vid högerklick är en simpel meny med endast ett valbart

objekt, att skriva ut och visas i Figur 24Figur 24. Väljer användaren att skriva ut renderas en

ny specialgjord komponent beskriven utförligare i avsnitt 4.5.

Figur 24: Kendo Contextmenu med ett menyobjekt

32

Språkhantering

Alla texter och etiketter i HTML-filerna är språkhanterade och gör det möjligt att ändra all

text i en vy. Varje textelement är bundet till en strängvariabel i en specifik språkfil, en .cs-

klass(C#), som hör till vykomponenten. För varje vykomponent finns respektive språkfil fylld

med variabler för alla texter i vyn. Dessa variabler har en get-metod för att hämta texten och

en set-metod för att ändra texten. Figur 23Figur 23 på föregående sida innehåller två

scripttaggar som hämtar text från språkfilerna. Taggarna börjar med language. i texten och

pekar på varsin variabel.

4.3 Dataflöde

Som beskrivet i avsnitt 3.3.2 skapades under projektets gång kommunikation mellan klient

och server med hjälp av response- och request-objekt som skickas fram och tillbaka.

Kommunikationen har till största mån försökt efterlikna den gamla kommunikationen men

med den nya tekniken AMP.

I avsnittet nedan beskrivs ingående vilka komponenter som utvecklats och implementerats i

projektet från klient till server.

HTML-fil

I HTML-filen skrivs koden för all grafisk struktur. Med hjälp av ramverket Aurelia skapas en

dynamisk HTML-struktur som behandlar alla verktyg på ett simpelt och användarvänligt sätt

för programmeraren. Verktyg som Kendo UI och Bootstrap fungerar bra ihop i Aurelia.

HTML-filen har för övrigt en TypeScript-fil kopplad till sig med kommunikationslogik, se

avsnittet nedan. Dessa två filer utgör en vykomponent.

TypeScript-fil

Den översta och närmast användaren, tillsammans med html-filen, liggande filen är en

TypeScript-fil. Filen har som uppgift att skicka ner data bland annat från användaren ner till

proxyobjektet. Här tillhandahålls även data som kommer från servern för att sedan visas på

vyn. Minimalt med logiska operationer existerar här då enbart grafisk manipulering sker här.

Figur 25 visar på hur en lista läggs in i ett listobjekt uppritat i html-filen.

33

Figur 25: Kodexempel: Implementation av funktion i TypeScript-fil

Proxy

I figur 26 sätter Proxyobjektet upp ett nytt requestobjekt med användarens inmatade

inparametrar till förfrågan. Objektet skickas sedan in i funktionen där den asynkrona

kommunikationen sätts upp, skulle fel inträffa i kommunikationen kan detta fångas upp av

programmet genom att definiera en så kallad catch-funktion [36] där det genererade felet

kan behandlas.

Då inga fel genererats returnerar proxyn resultatet från databasen upp till klienten. Skulle

retur-meddelandet bestå av ett objekt måste ett nytt objekt sättas upp med en egen

konstruktor [37]. Detta utförs för att den asynkrona kommunikationen ska fungera med det

objekt som returneras. I figur 26 ser man att ett Promise skapas med objektet i sig.

Figur 26: Kodexempel: Implementation av function i proxyobjektet

Web API

Web API som beskrivs i figur 27 visar på hur simpel bindningen mellan Proxyobjektet och

serviceklassen är. Det måste inkluderas då en ny vykomponent skapas och tillhandahåller ett

request-objekt och ett response-objekt. Även om request- och response-objektet inte

kommer returnera något eller inga inparametrar krävs måste Web API använda sig av

request och response. Detta görs för att skapa en standard för all transport mellan servern

och klienten.

34

Figur 27: Kodexempel: Implementation av Web-API

Response

Ett response-objekt kan, som visat i figur 28, innehålla varierande data. Allt från nummer och

textsträngar till objekt och andra klasser.

Varje gång klienten skickar en förfrågan om data från servern kommer ett nytt tomt

response objekt att skapas som sedan fylls på med information i serviceklassen(se nedan).

Sedan skickas det upp till Proxyobjektet.

Figur 28: Kodexempel: Implementation av Response-objekt

Request

Likt response-objektet tar request-objektet in varierande data som ska till servern. Dessa

objekt kan, som tidigare beskrivet, vara tomma, detta inträffar då servern inte kräver någon

användardata för att utföra sin förfrågan.

I figur 29 beskrivs ett request-objekt där klassen inte innehåller någon förfrågan till servern.

Figur 29: Kodexempel: Implementation av Request-objekt

Service

Service klassen har uppgiften att kommunicera med servern. Med hjälp av förfrågan från

request-objektet som användaren skrivit in, kan klassen via serverns egna serviceklasser

hämta ut transferobjekten. I figur 30 kan ses hur funktionen Fetch tar emot ett request samt

returnerar ett response. Response fylls med data via förbindelserna beskrivet vidare i avsnitt

4.4. Efter all data har fyllts i kommer ett nytt objekt sättas upp, detta responseobjektet

public class FetchBatchDetailsRequest { }

35

kommer returneras till controllern, för att sedan evalueras av proxyn som sedan skickar ut

data till vykomponenterna.

Figur 30: Kodexempel: Implementation av function i Serviceklass

36

4.4 NHibernate och databaskommunikation

Figurerna beskrivna i detta avsnitt är en förenkling av hur kommunikationen mellan klient

och server är uppsatt i det gamla systemet. Implementation finns redan och var inget detta

projekt inkluderade för utveckling, men togs med för att förstå funktionalitet som använts.

För att kommunikationen mellan server och databas skall fungera används

kartläggningsverktyget NHibernate [38]. Verktyget är inte enbart byggt för att få

kommunikationen fungerande utan förenklar även anropen utvecklaren vill utföra från

webbservern till databasen. Figur 31 visar hur klienten sätter upp en kommunikation,

beskrivet nedan, till servern där funktionen GetId() finns. För att sedan hämta ut returvärdet

från GetId() måste klienten gå via, beskrivet nedan, ett interface [39] för uppsättning av

asynkron kommunikation.

Figur 31: Kodexempel: Anrop från klient till server

Klientens uppsättning av kommunikationen börjar med en TCP-förbindelse mellan klient och

server vilket visas i figur 32 . Förbindelsen skapas via klassen Proxyfactor där Endpoints för

varje serverklass sparas undan via funktionen “register” i så kallade dictionaries (kataloger)

[40], vilket visas i figur 32. Förbindelserna som sätts upp görs via den inbyggda klassen

ChannelFactory [41] som kan ses i figur 32. ChannelFactory sätter upp det Microsoft kallar

för kanaler via en adress till en server samt en fördefinierad TCP-förbindelse. Sedan sparas

kanalerna i katalogen som klienten sedan kan hämta ut när serverkommunikation skall

sättas upp.

37

Figur 32: Kodexempel: Proxyfactor med uppsättning av TCP-förbindelser

När förbindelserna skapats till servern, krävs ett interface mellan server och klient där WCF-

ramverket kan skicka data asynkront mellan server och klient. Interfacet innehåller enbart de

funktioner som klienten vill erhålla från databasen.

För att interfacet sedan skall bli definierat som ett interface som skall tillhandahålla WCF-

kommunikation mellan klient och server, måste implementationen av ServiceContract [42]

göras, samt OperationContract [43] vilket definierar att en metod är en operation i WCF

kommunikationen. Detta demonstreras i figur 33.

Figur 33: Representation av Interface mellan klient och server

När sedan klienten vill koppla upp sig mot servern via WCF och kanalerna som blivit sparade

i ProxyFactors katalog ChannelFactories görs detta via funktionen ’get’ som skapar en

tillfällig förbindelse via nyckeln som också är interfacet mellan server och klient till den

specifika platsen i servern. Via funktionerna kan klienten sedan få de transferobjekt som

servern skapar och skickar tillbaka till klienten, se figur 34.

public class ProxyFactor{ public static ProxyFactor Create() { return new ProxyFactor(); } static ProxyFactor() { Register<IPersonService>(“PersonService”,tcpBinding); } public static void Register<T>(string address, ClientBindingBase tcpBinding){ string endAddress = ”net.tcp//:localhost/Server”; address = endAdress + address; ChannelFactory<T> channel = ChannelFactory<T>(tcpBinding, address); ChannelFactories.Add(typeof(T), channel); } public T get<T>() { ChannelFactory<T> factory = (ChannelFactory<T>)ChannelFactories[typeof(T)] T proxy = factory.CreateChannel(); return proxy; }

}

[ServiceContract()] public interface IPersonService { [OperationContract] PersonTransferAggregate GetId(int id); }

38

Figur 34: Kodexempel: Databasanrop från server

Slutligen kräver server att få vetskap om databasen, där används en liknande uppsättning

som klienten gör för kommunikation med server. Skillnaden i servern är att där,

demonstrerat i figur 34 , öppnas en session upp med NHibernate via ett repository1 [44] där

bland annat SQL-kommandon kan skickas in till fördefinierade kommandon representerade i

figur 34, repo.GetAll().

4.5 Problem och val av lösningar

Nedan beskrivs några av de problem som uppstått under projektets gång. Problemen

diskuteras och lösningarna till dem reflekteras med motiveringar till besluten.

Mousetrap

I vyn existerar funktionalitet där knapptryck är bundna till funktioner . Detta är skapat för att

snabbt kunna arbeta med vyn och snabbt kunna navigera sig till andra vyer samt utföra

kommandon utan behov av en mus. Dessa snabbkommandon skapades med ramverket

JQuery [45], ett JavaScript-bibliotek som används för enklare hantering av händelser,

animationer och navigering i dokument. Biblioteket sätter upp händelser i Web Form för att

hantera knapptryck från användare och vidarebefordra dessa snabbkommandon till rätt

funktion.

Att använda sig av biblioteket JQuery hade varit en alternativ lösning till uppgraderingen då

både TypeScript och JQuery bygger på JavaScript. Men denna lösning ansågs inte vara

användbar då Aurelia kan utöka sitt ramverk med tredjepartsbibliotek och biblioteket

Mousetrap [46] löste alla problem JQuery tidgare löst.

Att sätta upp en konfiguration för Mousetrap sker enligt figur 35 på följande sätt. En

mappning för vilka tangenter man vill använda sig av sätts upp med ett namn.

39

Figur 35: Kodexempel: Konfiguration av Mousetrap.

Sedan, representerat i figur 36 , binds detta event till ett objekt i html filen. När sedan

användare trycker på knappen som implementerat i mousetrap skapar mousetrap en

händelse som simulerar ett knapptryck till från användaren och kallar på rätt funktion.

Figur 36: Kodexempel: Implementation av Mousetrap.

Felmeddelanden

En av den stora funktionaliteterna med webbapplikationen var hur felmeddelande

genererades. I den gamla klienten skapades dessa rutor via en så kallad

ModalPopupExtender [47] som visas i figur 37 .Meddelanderutan är en komponent skapad

för att låsa bakomvarande komponenter från interaktion från användare samt lägga sig

ovanpå det redan existerande fönstret.

Figur 37: Web Forms representation av meddelanderuta.

40

För att skapa en mer manipulativ komponent kan felmeddelandet i figur 37 ta in en rubrik,

ett meddelande, en ikon samt en knappgrupp som parametrar och visa upp det i

ModalPopupExtender. Inparametrarna tas in då meddelandet användaren ser kan variera.

Knapparna kan även variera beroende på vad användaren skall göra då felmeddelandet

kommer upp.

ModalPopupExtender existerar inte till Aurelia vilket innebar att ett plugin Aurelia-Dialog

[48] valdes att användas till uppgraderingen. Aurelia-Dialog fungerar på liknande sätt som

ModalPopupExtender där meddelande, rubrik och typ av knapp kan implementeras till

dialogrutan, vilket visas i figur 38.

Figur 38: Aurelias representation av meddelanderuta.

View- och Session State

Som tidigare nämnt är Web Forms lösning på problemet, med data som inte sparas vid

serveranrop och uppdateringar, att skicka med data i anropet till servern för att sedan

skickas tillbaka till klienten.

View- och session state fungerar på samma sätt men har olika långa livscykler där livscykeln

för View states bara existerar då sidan utför ett så kallat postback, vilket innebär att då sidan

skickar en förfrågan för att spara data i servern, kommer användare tillbaka till samma sida

som tidigare. Data servern inte sparar åt användaren kommer då att försvinna om den inte

sparats undan i View state.

Session states livscykel varar så länge en cookie existerar för sidan. Fördelen med session

state framför View state är att session state kan behålla sina värden över anrop av andra

sidor, vilket ger en stor fördel då systemet PaperLine bygger på att användare skall kunna

förflytta sig mellan vyer med samma användarinställningar för var och en av vyerna.

41

Användningen av View state och session state är dock begränsad till ASP.NET vilket innebär

en stor förändring vid uppgradering till AMP. Lösningen till View states problem, att spara

undan data då postback sker, blev simpel. Som tidigare nämnt hämtar AMP enbart data om

det behövs vilket innebär att data tillfälligt kan sparas undan i klienten under serveranropet.

Problem med session state blev dock svårare att lösa och beskrivs vidare in avsnitt 6.2.

Skriv ut och exportera

Likt felmeddelande existerar det specialbyggda meddelanderutor för utskrifter till Excel-

dokument samt utskrifter till skrivare. Dessa meddelanderutor har egenskapen att skriva ut

specificerade rutnät med order. Funktionaliteten sträcker sig även till att användaren skall

kunna plocka bort kolumner från diagrammet samt ändra textstorlek och orienteringen av

sidan.

Problemet uppstår då metoderna för implementationen enbart stöds av webbläsaren

Internet Explorer. Att låsa sig till en webbläsare är inte är att föredra då användare i

framtiden kan komma att byta plattform eller webbläsare.

Lösningen var att likt “felmeddelanden” bygga upp egna komponenter via Aurelias plugin

‘Aurelia-dialog’ och där utföra samma operationer den gamla meddelanderutan utförde.

Figurerna 39 och 40 ger en tydligare bild över skillnaden mellan den uppgraderade versionen

och den gamla versionen. Figur 39 skildrar hur funktionaliteten byggdes upp med hjälp

metoden enbart Internet explorer stödjer showModelessDialog [49]. Metoden tar in och

visar ett HTML-dokument med specifika attribut, vanliga webbapplikationsfönster inte har

som standard. Till exempel inaktivt statusfält och möjlighet att inte skala fönstret.

Figur 39 visar det gamla fönstret för utskriftsfunktion samt export till Excel.

42

Figur 39: Utskriftsfunktion från Web Forms.

I den nya dialogrutan som användare kan bestämma utseendet för rutnätet har förändringar

skett i form av Kendo UIs funktionalitet att sortera bland kolumner och rader. Även

funktionen för export till Excel sköts nu av Kendo UI. Figur 40 ger exempel på hur det kan se

ut när man använder funktionerna i den nya klienten.

43

Figur 40: Utskriftsfunktion från Aurelia.IO och Kendo UI

4.6 Automatiskt genererade filer.

Som beskrivet i avsnitt 3.3.2 ligger en controller mellan proxyobjektet och service-klassen.

Controller, även kallad Web-API, har i uppgift att vidarebefordra meddelanden från en SPA

till serviceklassen. Eftersom klassens enda uppgift är att vidarebefordra meddelanden mellan

två klasser existerar inte mycket kod i klassen. Kontrollerklassen tillhandahåller bara ett

objekt för varje funktion som skapas för anrop till servern.

För att sedan föra samman Web-API och proxyobjektet så kräver SPA-klienten att alla C#-

klasser som används genereras automatiskt till ts-filer. Detta för att skapa en mer effektiv

och typsäker kod. Den automatiska genereringen sker genom ett projekt med öppen källkod

vid namn TypeWriter [50], skapat för att generera TypeScript-kod från C#-kod.

Tyvärr innebär genereringen att filer separeras från varandra, och har därför ingen

kännedom om varandras värden då TypeScripts filer enbart känner till data inom sitt eget

scope [51]. För att använda variabler i en utanför filens scope tvingas utvecklaren exportera

klassen. Denna lösning fungerar enbart åt ena hållet då andra filer nu kan se variabler och

funktioner men kan inte använda sig av dem. Detta på grund av att när en funktion vill

använda en variabel från en annan fil krävs ett import-“statement” för varje användning av

de exporterade funktioner och variabler. Arbetet ansågs då bli för stort för att implementera

alla dessa “statements” vilket innebär att lösningen istället blev att samla alla dessa

automatiskt genererade filer till en enda DTO(Data Transfer Object) fil. Nackdelen med

denna lösning är att filen som genereras innehåller kod för stora delar av projektet vilket kan

44

medföra prestandaproblem då fler filer till största sannolikhet måste genereras vid vidare

arbete av uppgradering och måste då läggas i filen DTO.

4.7 Sammanfattning

Detta kapitel har inkluderat en noga genomgång av vilka komponenter som använts vid

kommunikationen mellan användare och databas. Kapitlet har även beskrivit delar av

kommunikationen mellan server och databas som redan existerat och inte uppgraderades

under projektet gång.

45

5 Resultat

I detta kapitel diskuteras resultat och utvärderingar kring projektet. Här behandlas även

resultatet kring den kravspecifikation som beskrivits i avsnitt 2.1.1. Kapitlet inkluderar även

en utvärdering av den teknikstack som använts i projektet.

5.1 Resultat av krav

Kravspecifikationen som ingick i detta projekt har under tiden som gått ändrat sin form.

Ett av kraven ÅF la fram innan projektet startat innehöll en utvärderingen om AMP var en

genomförbar lösning till problemen användare och utvecklare stött på i PaperLine.

Som tidigare beskrivet, efter diskussion med kunden blev det tydligt att uppgradering av

PaperLine krävdes och ÅF bestämde sig att AMP var den lösning på problemen man ville

satsa på. Detta medförde att kraven i kravspecifikationen fick ändras till ett så kallat proof-

of-concept med demonstration för kunden av uppgraderingarna på en vy, där AMPs fördelar

framför Web forms påvisades.

Dessa förändringar av kravspecifikationen har även inneburit förändringar av vår prioritering

i arbetet och implementationen.

Trots att ändringar gjorts i kravspecifikationen bestämdes att alla kraven som ställts under

projektets gång inkluderas i kapitlet resultat. De högprioriterade kraven identifierades därför

till de tre som beskrivs i avsnittet nedan.

Går projektet att utföra?

Kan gamla systemet och nya tekniken samköras?

Sammanfoga gamla systemet med den nya tekniken

Kraven som beskrivits kan ses som en kedja där nästkommande krav bygger på föregående,

vilket inneburit att hade de första kraven inte varit genomförbart hade de nästkommande

kraven ändrat form eller inte alls existerat.

46

5.1.1 Går projektet att genomföra?

Detta krav existerade enbart i uppstarten av projektet, där kravet lades fram vid det första

mötet med ÅF. I kravet ingick att undersöka ifall en deluppgradering av systemet var möjligt

eller om kod efter år av utveckling av systemet blivit så sammanlänkat, också kallat

spaghettikod [52], att skulle en del uppgraderas tvingas den resterande av systemet också

uppgraderas. Detta krav ansågs ganska snabbt vara genomförbart då de involverade i

utvecklingen av den gamla klienten på ÅF tillsammans med oss diskuterade fram lösningar

på problemet.

I uppstarten var även AMP en relativt otestad plattform som inte noggrant diskuterats med

kunden om den kunde tänkas användas som uppgradering av PaperLine.

Punkten som beskrivits var fråga där resultatet kunde ha slutat i ett genomförbart projekt

eller ogenomförbart projekt. En möjlig utgång av projektet i ett tidigt stadie kunde varit att

kund inte känt sig säker på AMP som plattform och nya tekniker hade behövts

implementeras, testas och utvärderas. Efter diskussion med kunden kunde plattformen AMP

användas som teknik för PaperLine.

5.1.2 Samkörning av gammal och ny klient

Efter beslutet om att projektet var genomförbart, startades en undersökning kring

möjligheten att två klienter kunde samköras. En av lösningarna var att inkludera den klient

och mall ÅF tidigare arbetat med för enklare och snabbare uppstart av projektet, beskrivet i

avsnitt 3.1. Klienten skulle läggas vid sidan av den gamla klienten och sedan låta dem

samköra på en server. De första testerna gick ut på att undersöka ifall några problem kunde

uppstå då två klienter skilda från varandra startade upp på samma dator.

Små komplikationer uppstod men löste sig relativt snabbt och klienterna kunde samköras.

Trots framgångsrika tester fanns fortfarande ovissheten om dessa två klienter samtidigt

kunde kommunicera med servern och även länka mellan varandra.

Enkla tester sattes upp genom att låta den gamla klientens vy inkludera en fast länk till den

nya och genom detta kunde man navigera sig fram och tillbaka mellan den gamla och den

nya klienten. Testerna var framgångsrika och klienterna kunde samtidigt fungera samt länka

mellan varandra och till sista kommunicera samtidigt med samma server.

47

De första kraven hade då blivit genomförda. Det var nu tekniskt bevisat att uppgraderingen

var genomförbar och att den gamla klienten stegvis kunde uppgraderas med hjälp av den

nya tekniken.

5.1.3 Sammanfogning av AMP och serverlagret

Kravet att sammanfoga det gamla systemet med den nya tekniken sågs som den största

utmaningen under projektet. Arbetet med AMP-klientens kommunikation till servern har

krävt absolut mest tid och är källan till många av de problem som uppstått på vägen.

Då större delen av projektets innehåll var en sammanfogning av AMP och server, delades

detta krav upp i mindre delar. De framförallt två stora delarna, front end och back end,

kunde urskiljas.

5.1.4 Användargränssnitt

Vyns användargränssnitt har under projektet gång inte prioriterats. Som beskrivet i avsnittet

2.1.1 har användargränssnitt till största delen efterliknats den redan existerande vyn i den

gamla klienten. Små ändringar har dock lagts till för att kompensera för vissa krav för hur

gränssnittets passform skall se ut. Ett av de delkrav med lägre prioritet har varit att till

största mån utveckla ett användargränssnitt där användning för såväl dator som mobil ska

kunna användas utan problem. Uppgraderingen av de grafiska komponenterna gjordes till

stor del genom att visuellt studera den gamla vyns gränssnitt. Majoriteten av dem var enkla

att uppgradera och någorlunda tydligt angivna hur och varför de visade sig för användaren.

Ett mindre antal av komponenterna var dock mer komplexa och visades enbart under

speciella omständigheter. Dessa komponenter blev lägre prioriterade eftersom de

upptäcktes senare i projektet, vilket medförde att de påbörjades men inte till fullo

slutfördes. Några av dess komponenter som påbörjades var hur vyn hanterar utskrifter och

exporteringar av rutnät samt hur felmeddelanden hanteras. Anledningar till varför

funktionalitet inte till fullo implementerades beskrivs i avsnitt 5.4.

5.1.5 Serverkommunikation

Stor del av prioriteringen i projektet har gått till kravet kommunikation mellan klient och

server. Kravet har inneburit att i största mån undersöka den gamla kommunikationen och

efterlikna denna med den nya tekniken. Där bland annat ny kommunikation satts upp

beskrivet i avsnitt 3.3.2. Trots att större delen av den gamla kommunikationen framgångsrikt

48

blivit uppsatt kommer denna, liksom uppgradering av användargränssnittet, sakna full

funktionalitet då enbart de visuellt synliga uppgraderingarna gjordes(beskrivs vidare i avsnitt

5.4). Några av de funktionaliteter som valdes att inte implementeras var

användarinställningar och grundvyer. Även valideringar av dessa användarinställningar för

att bestämma vilka behörigheter användaren har i systemet.

5.2 Prestandajämförelse av gamla och nya tekniken

I detta delavsnitt påvisas de stora vinster som gjorts tack vare uppgraderingen.

5.2.1 Front end

Resultatet av uppgraderingen gällande prestanda kan vara svår att observera som användare

i vyn Arkpack. Detta på grund av den minimala mängd data som färdas mellan server och

klient i vyn Arkpack. För att till fullo se prestandaförändringen krävs vyer där mycket data

uppdateras ofta, trots att få förändringar skett. I dessa vyer kommer användaren se de stora

fördelarna med den nya tekniken. I vyerna kan onödig datakommunikation markant minskas

med den nya tekniken, då tidigare Web Forms tvingat webbapplikationen att ladda all data

igen så fort någon form av submit eller sparande av data matats in av användaren.

Med den nya tekniken krävs enbart att komponenter som behöver nya data uppdateras.

Detta medför att i ideala fall kan den nya klienten vinna över den gamla klienten med ett

flertal sekunder. Under en provkörning då en test-vy, med data skulle anropas från server,

tog den nya klienten ca 4 sekunder på sig att ladda och rendera färdigt medan den gamla

klienten behövde hela 11 sekunder för att utföra samma operation.

5.2.2 Back end

Förändringar på prestanda i kommunikationen mellan klient och databas kommer inte vara

lika markant som uppgraderingen av klientens visuella delar. Detta framförallt då

kommunikationen till stor del behandlas på liknande sätt i den nya klienten som i den gamla.

Valet att inte förändra mycket i kommunikationen gjordes för att arbetet ansågs vara för

stort då klienten ändå ska bytas ut.

49

5.3 Utvärdering av AMP teknikstack

I detta delkapitel utvärderas de tekniker som använts under projektets gång samt de

alternativa tekniker som inte valdes att användas. Diskussionen görs ur utvecklarnas

synvinkel och inkluderades då teknikstacken är relativt ny, samt är tekniker och verktyg ÅF i

framtiden kommer ha användning för samt kommer vara relevanta för utvecklingen av

applikationer till deras kunder.

Aurelia.io

Utvecklingsverktyget Aurelia.io har varit en av de större faktorerna till att detta projekt har

varit genomförbart. Med dess strukturella utvecklingsmiljö för webbapplikationer har

utvecklingen gått framförallt snabbare och smidigare än vad man som webbutvecklare är

van vid. En av de största fördelarna med Aurelia som verktyg är de många plugins som

konstant läggs till, uppdateras och moduleras av såväl privatpersoner som Aurelias

utvecklingsteam. Dessa medför att webbapplikationen enkelt kan få en modern miljö med

komponenter och metoder byggda för dagens webb.

En alternativ lösning till Aurelia skulle vara att använda sig av det Open-source ramverket

AngularJs [53] utvecklat av Google, vilket skulle kunna utföra de uppgifter problemet med

uppgraderingen krävde. Nackdelen med AngularJS gentemot Aurelia är enkelheten i Aurelia.

Aurelia är även mer effektivt samt mer flexibelt när det kommer till utveckling av

webbapplikationer.

Kendo UI

Kendo UI är ett bibliotek för grafiska komponenter och har gjort webbutvecklingen mycket

enklare. De grafiska komponenterna är fullständiga, något anpassningsbara och går att

konfigurera och testa på en sida inom en minut. Detta ger programmeraren möjlighet att

vara kreativ utan att det slösar onödigt mycket tid på själva kodningen. De grafiska

komponenterna hanterar data väldigt smidigt och har ett enkelt API. Däremot tenderar

Kendo UI grafiska komponenter att ta upp mycket plats i koden, det vill säga många rader

kod med konfigureringar och dylikt. Det är även krångligt att jobba med komponenternas

CSS. Detta slipper man dock i AMP eftersom Bootstrap tar hand om det.

50

Bootstrap

Fördelarna med utvecklingen i Bootstrap märks framförallt genom den enkelheten

ramverket medför då man vill utveckla en responsiv webbapplikation. De redan inbyggda

funktionerna för responsiv visning av webbapplikationer kan vara lite begränsande när det

kommer till hur komponenter strukturerar sig, men då alternativet till att utveckla en

responsiv webbapplikation är att som utvecklare själv ändra utseendet för alla komponenter

och storlekar är Bootstrap som alternativet bättre. Bootstrap kan ses som ett hjälpmedel till

den annars så komplexa och många gånger nästan omöjliga utvecklingen av responsivt

gränssnitt.

Fördelarna med Bootstrap är även att biblioteket enkelt går att förändra så utseende och

komponenter beter sig som utvecklaren vill.

TypeScript

TypeScript som utvecklingsspråk har under projektets gång förenklat en stor del av

utvecklingen av webbapplikationen. Anledningarna till att språket förenklat och skyndat på

utvecklingen är att det jämfört med JavaScript inte är lika mycket kod som

behövs för att utföra samma saker. Detta tack vare att TypeScripts felhanteringen då

utveckling sker är mer responsiv och direkt till skillnad från traditionell JavaScript samt att då

språket skapades fanns det efterfrågan att skapa ett programspråk som förenklade

utvecklingen av JavaScript i webbapplikationer.

5.4 Problem

Generellt har projektet flutit på bra och de problem som uppstått är till större del relaterade

till Visual Studio och TFS där stor tid spenderades under projektets början. Anledningen till

problemen var hur Visual Studio och TFS deklarerat hur filer får och inte får skapas och

skrivas över.

Dessa ovan beskrivna problem har varit lösbara problem som förhindrat vidare arbete men

med tid och hjälp gått att lösa. Men det har även existerat problem som inte gått att åtgärda

helt och hållet. Dessa problem låg mestadels i uppgiften kring uppgraderingen och beskrivs

kortfattat nedan.

51

Testning

Uppgraderingen som implementerades utfördes till stor del genom vad som var visuellt

möjligt att urskilja ur den gamla vyn. Detta innebar att det som inte visades i vyn, specialfall

och liknande, kan ha blivit översedda. En lösning till detta hade varit att sätta upp en

testmiljö där vyn hade kunnat bearbeta alla scenarion och validera det som saknas.

Bristfällig data.

Data som existerat i projektet kom direkt från produktionen, vilket innebar att mycket data

existerade men många gånger inte relevant för de komponenter som uppgraderats. Detta

märktes framförallt då en av de stora delarna av Arkpack skulle uppgraderas,

funktionaliteten att packa en order. Eftersom order konstant produceras inne på

pappersbruket hos kunden existerar order sällan längre perioder mellan vissa maskiner och

delar av systemet. Arkpacken som en del av systemet har sällan order liggande mellan

föregående maskin och sig själv. Detta innebär att databasen innehåller få objekt för

testning av funktionen packning.

5.5 Sammanfattning

I kapitlet resultat har mål och krav angående projektet diskuterats. Tester av prestandan i

den nya tekniken gentemot det gamla systemet har också diskuterats. Även en ingående

diskussion angående den teknikstack som ÅF valt att implementera i deras nuvarande och

framtida projekt, ingår i detta kapitel.

52

6 Slutsats

I detta kapitel ingår en utvärdering av projektets arbete. I kapitlet diskuteras även den

vidareutveckling som behöver utföras av projektet för att driftsättning av den nya tekniken

skall vara möjlig. Även tidsåtgången för projektet samt den kundkontakt vi under projektet

har haft är inkluderat i detta kapitel.

6.1 Utvärdering av projektet

Detta projekt har under de timmar tillbringade på ÅF varit lärorika och roliga. Framförallt för

att projektet blev en start på framtida arbeten för ÅF, samt att kunden fick se fördelar med

vad projektet kunde utföra och behovet av uppgradering av ett gammalt system.

Att få utveckla en “produkt” direkt mot kunden med kundkrav och demo för kunden har givit

oss lärdomar skolans kurser ofta inte lär ut.

6.2 Vidareutveckling

Några av de funktionaliteter som behövts uppgraderats har valts att inte inkluderas som en

del av projektet då dessa till en stor del skulle kräva för stor tidsåtgång för att vara

genomförbara. De största delar som observerats är som beskrivet i kapitel 2.3.2 hur det

beslutats att Web Forms hanteras och hur data sparas undan då webbapplikationen tvingas

ladda om. Problemet som uppstod när implementationen diskuterades var magnituden av

data som sparades, inte bara när vyn initialiseras utan även data som sparats undan från

bakomvarande vyer. Inställningarna för användaren måste i detta fall antingen manuellt

extraheras av utvecklaren då åtkomsten för dessa värden inte kan extraheras via funktioner

och statiskt läggas in i en fil. En annan lösning skulle vara att skapa en ny bakomvarande vy

där alla värden för användarinställningar sätts. Problemet lades dock på ett vidare arbete för

ÅF då prioriteringar på kravet inte var stora och tiden inte räckte till.

Det grafiska gränssnittet som blivit implementerat bygger på ett gränssnitt som till stor del

liknar det gamla. Detta innebär att många komponenter inte ligger på en optimal plats för

bland annat en mobil-lösning. Skulle arbetet fortskrida skulle en omstrukturering krävas för

att optimalt passa in komponenter efter skärmens storlek. För att genomföra denna

53

vidareutveckling skulle en kontinuerlig kundkontakt behövas då den optimala lösningen för

både användare och system måste diskuteras fram.

Som tidigare nämnt har funktionaliteten för att skriva ut och exportera rutnät påbörjats men

aldrig blivit avklarad. Denna funktionalitet kan bli en viktig del att vidareutveckla om mobila

lösningar för PaperLine skulle vara i ett krav i framtiden. Detta eftersom den dåvarande

metoden, som tidigare beskrivs, enbart stöds av webbläsaren Internet Explorer. Detta

medför att begränsningar sätts för de plattformar kunden tvingas använda för att få ett

fungerande system. Med de nya implementeringarna blir begränsningarna färre, då fler

plattformar stödjer de plugin Aurelia erhåller.

6.3 Kundkontakt

Eftersom detta projekt var riktat till en specifik kund som ett proof-of-concept var

kundrelationen förhållandevis distanserad. En av anledningarna till beslutet var att den

faktiska användarintegrationen på vyn inte skulle förändras, utan fokus skulle ligga på att

visa för kunden att AMP är en fungerande teknikstack för deras behov. De tillfällen då vi kom

i kontakt med kunden var det initiala mötet med dem då projektet godkändes samt vid

demo.

6.4 Tidsåtgång

Den initiala tidsåtgången för projektet var 20 timmars per vecka, men märktes snabbt att

skulle vi fortsätta med samma takt skulle varken uppsatsen eller projekt hinna bli klart i tid,

därför ökades arbetstimmar på och landade till slut på en veckotid mellan 24-28 timmar.

Tidsåtgången ökade framförallt och markant i anslutning till projektets utveckling, medan tid

för vad uppsatsen tagit fortsatt på en jämn nivå fram till slutet då arbetsvikten ändrades till

att nästan enbart riktats mot uppsatsen. Orsaken till den obalanserade planeringen var att

efter överenskommelse med ÅF sattes slutdatumet för projektet till mitten av December

vilket innebar att tiden mellan December och Januari kunde helt och fullt ägnas åt

uppsatsen.

54

6.5 Slutord

Under arbetets gång har teknikstacken AMP utvärderats och implementerats som en lösning

och proof-of-concept till PaperLines klient, där gamla klienten var i behov av uppgradering

på grund av ineffektivitet och tekniker som blivit utdaterade.

Efter att stor del av implementering blivit genomförd kunde klienten demonstreras för

kunden som ansåg att det var något de ville se ute i skarp miljö.

Vyn Arkpack kommer under närmaste tiden bli validerad av ÅF. ÅF ska vidareutveckla det

som under projektet inte blivit implementerat. Därefter kan klienten komma bli testad i en

testmiljö för att sedan förhoppningsvis bli använd i skarp miljö. Operatörer kommer då ha

möjligheten att jämföra mellan gamla och nya klienten.

55

Referenser

[1] Wikipedia, ”MES,” [Online]. Available:

https://en.wikipedia.org/wiki/Manufacturing_execution_system. [Använd Sep 2016 2016].

[2] Microsoft, ”ASP.NET Web Form,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/ms973868.aspx#introwebforms_topic1. [Använd 22 Sep 2016].

[3] ÅF, ”ÅF,” [Online]. Available: http://www.afconsult.com/sv/om-af/i-korthet/. [Använd 21 Sep

2016].

[4] Wikipedia, ”MVC,” [Online]. Available:

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller. [Använd 21 Sep

2016].

[5] Mircosoft, ”MVVM,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/hh848246.aspx [Accessed: dd-mmm-2016].

[6] Wikipedia, ”Visual studio,” [Online]. Available:

https://en.wikipedia.org/wiki/Microsoft_Visual_Studio. [Använd 22 Sep 2016].

[7] W3schools, ”HTML5,” [Online]. Available: http://www.w3schools.com/html/html5_intro.asp.

[Använd 01 Sep 2016].

[8] Microsoft, ”ASP.NET,” [Online]. Available: https://docs.microsoft.com/sv-se/aspnet/index.

[Använd 22 Sep 2016].

[9] Microsoft, ”User Control,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/y6wb1a0e.aspx. [Använd 18 Dec 2016].

[10] Mirosoft, ”View state,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/ms972976.aspx. [Använd 14 Okt 2016].

[11] Mirosoft, ”Session state,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/ms178581.aspx [Accessed: 14-Okt-2016].

[12] R. Eisenberg, ”Aurelia.io,” [Online]. Available:

http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/what-is-aurelia/1. [Använd 01

Sep 2016].

[13] Wikipedia, ”C#,” [Online]. Available:

https://en.wikipedia.org/wiki/C_Sharp_(programming_language). [Använd 21 Dec 2016].

[14] Wikipedia, ”Java,” [Online]. Available:

https://en.wikipedia.org/wiki/Java_(programming_language). [Använd 21 Dec 2016].

[15] Wikipedia, ”C++,” [Online]. Available: https://en.wikipedia.org/wiki/C%2B%2B. [Använd 21 Dec

2016].

56

[16] Javascript, ”JavaScript,” [Online]. Available: https://www.javascript.com/about /. [Använd 22

Sep 2016].

[17] TypeScript, ”TypeScript,” [Online]. Available: TypeScript. [Använd 01 Sep 2016].

[18] Wikipedia, ”CSS,” [Online]. Available: https://sv.wikipedia.org/wiki/Cascading_Style_Sheets.

[Använd 29 Sep 2016].

[19] Bootstrap, ”Bootstrap,” [Online]. Available: http://getbootstrap.com/. [Använd 01 Sep 2016].

[20] Telerik, ”Kendo UI,” [Online]. Available: http://www.telerik.com/kendo-ui. [Använd 01 Sep

2016].

[21] Wikipedia, ”TFS (Team Foundation Server),” [Online]. Available:

https://en.wikipedia.org/wiki/Team_Foundation_Server /. [Använd 22 Sep 2016].

[22] Wikipedia, ”SPA,” [Online]. Available: https://en.wikipedia.org/wiki/Single-page_application .

[Använd 16 Sep 2016].

[23] C. Buckler, ”Gulp,” [Online]. Available: https://www.sitepoint.com/introduction-gulp-js/.

[Använd 24 Nov 2016].

[24] Microsoft, ”Endpoints,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/ms733107(v=vs.110).aspx. [Använd 13 Dec 2016].

[25] Wikipedia, ”TCP(Transmission control protocol),” [Online]. Available:

https://en.wikipedia.org/wiki/Transmission_Control_Protocol. [Använd 14 Dec 2016].

[26] Wikipedia, ”DTO(Data transfer object),” [Online]. Available:

https://en.wikipedia.org/wiki/Data_transfer_object . [Använd 19 Okt 2016].

[27] Microsoft, ”WCF(Windows Communication Foundation),” [Online]. Available:

https://msdn.microsoft.com/en-us/library/ms731082(v=vs.110).aspx . [Använd 14 Dec 2016].

[28] Wikipedia, ”Web-Api,” [Online]. Available: https://en.wikipedia.org/wiki/Web_API. [Använd 24

Nov 2016].

[29] ”Promise,” [Online]. Available:

https://basarat.gitbooks.io/typescript/content/docs/promise.html. [Använd 14 Okt 2016].

[30] ”Aurelia-Kendo UI Bridge,” [Online]. Available: https://aurelia-ui-toolkits.gitbooks.io/kendoui-

bridge-docs/content/about_this_application.html. [Använd 04 Jan 2017].

[31] Microsoft, ”GridView,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/system.web.ui.webcontrols.gridview(v=vs.110).aspx. [Använd 09 Nov 2016].

[32] Microsoft, ”Datatable,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/system.data.datatable(v=vs.110).aspx. [Använd 09 Nov 2016].

[33] Microsoft, ”Dataset,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/system.data.dataset(v=vs.110).aspx. [Använd 09 Nov 2016].

57

[34] Microsoft, ”IList,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/system.collections.ilist(v=vs.110).aspx. [Använd 09 Nov 2016].

[35] Telerik, ”Kendo Contextmenu,” [Online]. Available: http://docs.telerik.com/kendo-

ui/controls/navigation/menu/contextmenu . [Använd 01 Jan 2017].

[36] Microsoft, ”Catch,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/0yd65esw.aspx. [Använd 28 Dec 2016].

[37] Wikipedia, ”Konstruktor,” [Online]. Available:

https://en.wikipedia.org/wiki/Constructor_(object-oriented_programming). [Använd 28 Dec

2016].

[38] Wikipedia, ”NHibernate,” [Online]. Available: https://en.wikipedia.org/wiki/NHibernate.

[Använd 19 Okt 2016].

[39] Microsoft, ”Interface,” [Online]. Available: https://msdn.microsoft.com/sv-

SE/library/87d83y5b.aspx. [Använd 13 Dec 2016].

[40] Microsoft, ”Dictionary,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/xfhwa508(v=vs.110).aspx. [Använd 14 Dec 2016].

[41] Microsoft, ”ChannelFactory,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/ms576132(v=vs.110).aspx. [Använd 14 Dec 2016].

[42] Microsoft, ”ServiceContract,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/system.servicemodel.servicecontractattribute(v=vs.110).aspx. [Använd 30 Dec 2016].

[43] Microsoft, ”OperationContract,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/system.servicemodel.operationcontractattribute(v=vs.110).aspx. [Använd 30 Dec

2016].

[44] Microsoft, ”Repository,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/ff649690.aspx. [Använd 04 Jan 2017].

[45] T. j. Foundation, ”JQuery,” [Online]. Available: http://api.jquery.com/. [Använd 23 Nov 2016].

[46] Npm, ”Mousetrap,” [Online]. Available: https://www.npmjs.com/package/aurelia-mousetrap.

[Använd 23 Nov 2016].

[47] R. Masudur, ”ModalPopupExtender,” [Online]. Available:

https://www.codeproject.com/Articles/34996/ASP-NET-AJAX-Control-Toolkit-

ModalPopupExtender-Co. [Använd 24 Nov 2016].

[48] ”Aurelia-Dialog,” [Online]. Available: https://gooy.github.io/aurelia-dialog/#/ . [Använd 24 Nov

2016].

[49] Microsoft, ”ShowModelessDialog,” [Online]. Available: https://msdn.microsoft.com/en-

us/library/ms536761(v=vs.85).aspx. [Använd 14 Dec 2016].

[50] TypeWriter, ”TypeWriter,” [Online]. Available: https://frhagn.github.io/Typewriter/. [Använd 23

58

Nov 2016].

[51] Wikipedia, ”Scope,” [Online]. Available:

http://https://en.wikipedia.org/wiki/Scope_(computer_science). [Använd 09 Jan 2017].

[52] Wikipedia, ”Spaghettikod,” [Online]. Available: https://sv.wikipedia.org/wiki/Spaghettikod.

[Använd 08 Jan 2017].

[53] AngularJs, ”AngularJs,” [Online]. Available: https://angularjs.org/. [Använd 28 Jan 2016].