Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Utvärdering av inläsning av XML-kontra
flatfiler
av
Mathias Pettersson
LIU-IDA/LITH-EX-G--12/028--SE
Utvärdering av inläsning av
XML-‐kontra flatfiler
Av: Mathias Pettersson
2012-‐11-‐23
Handledare: Björn Eklund Skatteverket Visby Examinator: Patrick Lambrix
Linköpings Universitet
Innovativ Programmering
Sammanfattning
Examensarbetet har utförts på Skatteverkets kontor i Visby. Eftersom Skatteverket arbetar med ett befintligt projekt som medför en kommande förändring på
filformatet från flatfil till XML-‐fil så fanns en oro över att det nya formatet skulle medföra prestandaproblem. Därför ville Skatteverket göra en utvärdering på
inläsningen från filformaten till en databas med fokus på prestanda men även andra kvalitetskriterier.
Målet med examensarbetet var att jämföra inläsningen av de olika filformaten där systemet skulle klara av hundratals till hundratusentals kontrolluppgifter för att sedan sammanställa resultatet av jämförelsen i en rapport.
För att arbetet skulle kunna utföras så behövdes en lokal utvecklings-‐ och testmiljö installeras. Testdata behövde även tas fram för att kunna utföra utvärderingen. Slutsatsen blev inte helt oväntat att flatfilsformatet är snabbare att läsa av än XML-‐ formatet. Detta grundar sig i att XML-‐formatet innehåller betydligt fler tecken än flatfilsformatet. Flatfilsparsern var i genomsnitt 29% snabbare än XML-‐parsern i de fallen då ett hundratal kontrolluppgifter till flera hundratusentals parsades.
Resultatet var dock mer oväntat då skillnaden i filstorlek mellan formaten förhöll sig konstant runt 80% för samma antal kontrolluppgifter. I min mening tycker jag att skillnaden i berarbetningstid och filstorlek borde ha varit mer jämna procentuellt. En graf med bearbetningstiderna finns att se i rapporten.
Resultatet blev fyra stycken Eclipse-‐projekt på totalt 2988 rader kod. XML-‐parsern som valdes för utvärderingen var SAX-‐parsern, vilket var den mest lämpade parsern då den strömmar inläsningen av XML-‐dokument och håller därför en låg
minnesanvändning. Flatfilsparsern var lite knepigare, då det inte fanns en färdig parser att tillgå som var anpassat efter formatet, därför var jag tvungen att skriva en egen parser för Skatteverkets format. Detta går att läsa mer om i rapporten.
Innehållsförteckning
1 Inledning ... 1
1.1 Bakgrund till examensarbetet ... 1
1.1.1 Krav ... 1 1.2 Motivering ... 1 1.3 Syfte ... 1 1.4 Frågeställning ... 2 1.5 Avgränsningar ... 2 1.6 Målgrupp ... 2 1.7 Språkbruk ... 3 1.8 Rapportens struktur ... 3 2 Bakgrund ... 4 2.1 XML ... 4 2.2 Flatfiler ... 4 3 Teori ... 6
3.1 Programspråk & tekniker ... 6
3.1.1 Java ... 6
3.1.2 XML parser ... 6
3.1.2.1 SAX (Simple API for XML) ... 6
3.1.2.2 DOM (Document Object Model) ... 6
3.1.2.3 StAX (Streaming API for XML) ... 7
3.1.3 Flatfilsparser ... 7
3.1.4 JPA (Java Persistence API) ... 7
3.1.5 JAXB (Java Architecture for XML Binding) ... 7
3.2 Databasdesign ... 7
3.3 Testning ... 7
3.3.1 Beteendetestning (Black box testing) ... 8
3.3.2 Glasboxstest (White box testing) ... 8
3.3.3 Enhetstest (Unit testing) ... 8
3.3.4 Lasttest (Load testing) ... 8
3.3.5 Acceptanstest (Acceptance testing) ... 8
3.4 Användbarhet ... 8
Innovativ Programmering 3.6 Utvecklingsmiljö ... 8 3.6.1 IDE-‐program ... 8 3.6.2 Databas ... 9 4 Metod ... 10 4.1 Utvecklingsmetod ... 10 4.1.1 Milstolpar ... 10 4.1.2 Agil utveckling ... 10 4.1.3 Mitt arbete ... 10 4.2 Testning ... 11 4.3 Utvecklingsmiljö ... 11 4.3.1 Rational Rose ... 11 4.3.2 Apache Ant ... 11 4.3.3 Eclipse IDE-‐mjukvaruutvecklings-‐verktyg ... 12 4.3.4 Databas ... 12 4.3.5 Oracle WLS ... 12 4.4 Tekniker ... 12 4.4.1 JAXB ... 12 4.4.2 SAX-‐XML parser ... 13 4.4.3 Flatfils-‐parser ... 13 4.4.4 JPA ... 13 5 Resultat ... 15 5.1 Arbetsförlopp ... 15
5.1.1 Generering av testdata ... 15
5.1.1.1 XML-‐dokument ... 15
5.1.1.2 Flatfil ... 15
5.1.2 Parsning av filformat ... 15
5.1.2.1 Parsning av XML fil ... 15
5.1.2.2 Parsning av flatfil ... 15
5.1.3 Prestandajämförelse ... 16
5.1.3.1 Sammanställning av prestandajämförelse ... 16
5.2 Användargränssnitt ... 16
5.3 Databasstruktur ... 17
5.5 Prestandamätning ... 18
6 Slutsats och diskussion ... 19
6.1 Egen reflektion och diskussion ... 19
6.1.1 Fortsatt arbete ... 20 6.2 Slutsats ... 20 7 Referenser ... 22 8 Bilagor ... 23 8.1 Kontrolluppgifter ... 23 8.1.1 XML-‐format ... 23 8.1.2 Flatfilsformat ... 25
1 Inledning
1.1 Bakgrund till examensarbetet
Skatteverkets IT-‐avdelning jobbar med utveckling,drift, förvaltning och underhåll av Skatteverkets och Kronofogdens IT-‐system. Uppdragen kommer från Skatteverkets huvudkontor.
Större delen av verksamheten finns i Solna, samt på orterna Göteborg, Umeå, Visby, Västerås och Östersund.
Kontoret i Visby är uppdelat i två sektioner och har ca 50 medarbetare. Arbetsuppgifterna är
uppdelade i domäner, en datawarehousedomän samt en javadomän. I javadomänen utvecklas allt från infrastrukturella komponenter till
handläggningsstöd och applikationer avsedda för Skatteverkets externa webbplats. Examensarbetet blev därför placerat i javadomänen.
På uppdrag av Skatteverkets kontor i Visby så behövdes en utvärdering på
inläsningen av filformaten XML kontra flatfil innehållandes kontrolluppgifter till en databas.
Källan till arbetet var att den danska motsvarigheten till Skatteverket hade pekat på att de tvingats gå från XML-‐format till förmån för flatfiler p.g.a. prestandaproblem med XML-‐filer. Då Skatteverket ska införa liknande funktionalitet så ville de säkerställa att XML-‐formatet i sig inte skulle vara något problem.
1.1.1 Krav
• Installation av lokal test/utvecklingsmiljö. • Testdata skulle tas fram.
• Stöd för kontrolluppgiftsfiler innehållandes hundratals till hundratusentals kontrolluppgifter.
• En rapport där IT-‐miljön beskrivs samt de utvärderade teknikerna. • En testbilaga med bearbetningstider och diagram under olika laster.
1.2 Motivering
På grund av en kommande formatändring från flatfil till XML fil i ett befintligt projekt hos Skattekontoret i Visby så fanns det oro för eventuella prestandaförsämringar, då den danska motsvarigheten till Skatteverket pekade på detta.
Därför var det viktigt för dem att göra en utvärdering som påvisar olikheter i en prestandajämförelse mellan de två olika filformaten.
1.3 Syfte
Syftet med examensarbetet var att göra en utvärdering på inläsning av de olika Figur 1: Skatteverket är en statlig myndighet i Sverige
(KU10) från arbetsgivare m.fl. Detta skulle göras för att påvisa olikheter och
eventuella fördelar och nackdelar mellan de olika filformaten, så som prestanda och andra kvalitetskriterier.
Testdata skulle tas fram för att kunna göra flera mätningar på olika laster om hundratals till hundratusentals kontrolluppgifter.
Resultaten från testkörningarna skulle sammanställas i en testbilaga med grafer och diagram som visar skillnaden i bearbetningstid för olika antal kontrolluppgifter, om hundratals till hundratusentals.
1.4 Frågeställning
• Finns det någon teknik att generera XML dokument i Java eller hur gör man
det enklast?
För att förenkla och abstrahera arbetet så är det en viktig fråga. • Vilka olika parsningstekniker finns det för att traversera de olika
filformaten och vilken metod lämpar sig bäst för arbetet?
Eftersom fokus främst låg på prestanda var det viktigt att hitta den tekniken som var snabbast. Eftersom antalet kontrolluppgifter kunde vara
hundratusentals som mest så var det även viktigt att hitta den teknik som klarade av att hantera stora mängder för att hålla prestandan uppe. • Finns det något bra sätt att hantera databasanslutningen på?
Då inläsningen av kontrolluppgifter skulle ske till en databas så ansåg jag det viktigt att hitta ett bra sätt att hantera anslutningen och innehållet i
databasen på.
• Hur stor är storleksskillnaden mellan filformaten och hur mycket påverkar
det bearbetningstiden?
Eftersom XML filen innehåller betydligt fler tecken än flatfilen så borde storleken vara markant. Det kan även vara av intresse att se om storleken ökar linjärt med antalet kontrolluppgifter.
• Kommer bearbetningstiden öka sekventiellt med antalet kontrolluppgifter? Då storleken ökar med antalet kontrolluppgifter så ökar även
bearbetningstiden. Det kan därför vara av intresse att veta om bearbetningstiden ökar linjärt.
1.5 Avgränsningar
Utvärderingen använder programspråket Java med en SQL databas från Oracle. Allt ska köras på en dator vilket Skatteverket tillhandahåller.
Arbetet ska integreras med Skatteverkets säkerhetsbibliotek för att det ska kunna köras säkert på en WLS från Oracle.
Resultat sammanställs i ett Excelldokument med grafer som påvisar skillnader, om för och nackdelar mellan de två filformaten.
1.6 Målgrupp
Den här rapporten är riktad till studenter med datautbildning inom programmering på kandidatnivå eller personer med förståelse och intresse för programmering.
1.7 Språkbruk
KU -‐ Kontrolluppgift 10, kontrolluppgift från arbetsgivare m.fl.
JPA -‐ Java Percistence API, ett ramverk för att hantera relationsdata mellan objekt. JAXB -‐ Java Architecture for XML Binding, "mappar" Java-‐klasser till XML
representationer.
SQL -‐ Ett standardiserat språk för att hämta och modifiera data i en relationsdatabas. WLS -‐ Web Logic Server, en Java web applikationsserver från Oracle.
Entitet -‐ Ett objekt/tabell i en databas.
Parser (tolk) -‐ tolkar strängar av symboler (indata) enligt regler i en formell
grammatik.
Kommandorad -‐ När jag skriver kommandorad så syftar jag på raden i ett
terminalfönster där olika kommandon kan skrivas in för att kommunicera med olika program.
GUI -‐ Graphical User Interface, eller på svenska: grafiska användargränssnitt. XML -‐ Extensible Markup Language, ett märkspråk (engelska: markup language).
XML dokument används för att strukturera data.
Element -‐ Ett XML-‐dokument är i grunden uppbyggt av element. Ett element består
vanligtvis av en start-‐ och en sluttagg och kan ha olika attribut och innehåll.
Flatfil -‐ Har samma funktion som ett XML-‐dokument. Syntaxen/strukturen däremot
bestäms självt.
JAR -‐ Java Archive, Är ett arkivformat för att hålla samman många Java-‐klassfiler,
metadata och andra resurser i en och samma fil.
Tråd -‐ (programtråd) Används för att utföra saker samtidigt. kB -‐ kilobyte, måttenhet. 1 kB motsvarar 1024 bytes (2^10). ms -‐ millisekunder, på en sekund går det 1000 millisekunder.
1.8 Rapportens struktur
Den här rapporten sammanfattar examensarbetet för Mathias Pettersson på Skatteverkets kontor i Visby under våren 2012.
Rapporten är uppdelad i åtta kapitel. Rapportens första kapitel är inledningen med bakgrunden, syftet och avgränsningar till examensarbetet. Andra kapitlet är lite bakgrundsfakta om filformaten då exjobbet behandlar detta. Tredje kapitlet
innehåller teorier som ligger bakom examensarbetet som kan vara bra att känna till. Det fjärde kapitlet handlar om metoder som jag använt under arbetet. Femte kapitlet innehåller resultaten för arbetet och kapitel sex en slutsats och diskussion kring arbetet. Det sjunde kapitlet innehåller de referenser som jag har använt för rapporten och examensarbetet. Åttonde och sista kapitlet innehåller bilagor till
2 Bakgrund
För att reda ut några begrepp och tekniker som jag har använt eller kommit i kontakt med i examensarbetet så har jag valt att beskriva det här för att förståelsen för rapporten ska ökas och läsaren ska ha lättare att hänga med.
2.1 XML
Extensible Markup Language (XML) är ett så kallat märkspråk vars syfte är att kunna utväxla data mellan olika informationssystem. XML dokument innehåller data som beskrivs direkt i dokumentet till skillnad från flatfiler som endast brukar innehålla data.
Ett XML-‐dokument är i grunden uppbyggt av element. Ett element består vanligtvis av en start-‐ och en sluttagg och kan ha olika attribut och innehåll.
Genom att kombinera ett flertal element med valfria attribut kan olika information beskrivas. Följande exempel är en beskrivning på en kontrolluppgift med lite persondata: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <?xml version="1.0" encoding="iso-‐8859-‐1"
standalone="yes"?> <!-‐-‐ Deklarerar att det är en XML-‐fil med teckenkodning iso-‐8859-‐1 -‐-‐>
...
<Kontrolluppgift> <!-‐-‐ Kontrolluppgift är ett element i rotelementet Manadsuppgift -‐-‐>
<Inkomsttagare> <!-‐-‐ En inkomsttagare/persondata-‐-‐> <!-‐-‐ ns2: är ett "namespace", vilket används för att lösa namnkonflikter -‐-‐>
<ns2:Adress> <ns2:Gatuadress>Skatteverket 1</ns2:Gatuadress> <ns2:Postnr>62123</ns2:Postnr> <ns2:Postort>Visby</ns2:Postort> </ns2:Adress> <Fornamn>John1</Fornamn> <Efternamn>Doe</Efternamn> <Personnr>500101-‐0015</Personnr> <Orgnr></Orgnr>
</Inkomsttagare> <!-‐-‐ Slut på elementet persondata -‐-‐>
...
2.2 Flatfiler
Flatfiler innehåller ren text vars syfte är samma som XML-‐dokument. Strukturen på dessa skiljer sig dock då flatfiler oftast innehåller en post per rad. Det finns ingen förutbestämd struktur på hur en flatfil ska se ut, utan detta bestäms av skaparen. Inom en post så kan flera fält finnas, vilka kan vara separerade med något sorts tecken (vanligtvis kommatecken), men inte i detta fall då det handlar om nyckelord som t.ex. "#NAMN".
Följande är en del ur en flatfil där en kontrolluppgift beskrivs precis som i exemplet för XML: 1 2 3 4 5 6 7 8 9 10 11 12 ... #POST_START KU10 #PERSONNR 195001010015 #NAMN Doe John1
#ADRESS Skatteverket 1 #POSTORT Visby #POSTNR 62123 ... ... ... #POST_SLUT KU10 ...
3 Teori
Inom examensarbetet så har jag behövt använda en del tekniker och program för att kunna utföra arbetet. Därför har jag varit tvungen att göra vissa jämförelser mellan dem för att välja det som jag anser lämpar sig bäst för uppgiften. Jag tänkte därför ge lite bakgrund till allt i detta kapitel och där jag även beskriver hur jag har tänkt.
3.1 Programspråk & tekniker
Programmeringsspråket ska väljas efter uppgiften. Vilket språk eller vilken teknik som bäst lämpar sig för arbetet kan vara det som har bredast urval av funktioner som kan användas under arbetets gång, eller det som är enklast att använda men kanske inte är så optimerat.
Jag kommer här gå igenom några programspråk och tekniker som jag har tittat på och ge lite bakgrund om dem.
3.1.1 Java
Java är ett objektorienterat programspråk som presenterades för världen år 1995. Java är ett plattformsoberoende språk som har många användningsområden, som t.ex. programapplikationer i detta fall. Nedan presenterar jag olika fördelar och inbyggda funktioner som Java tillhandahåller vilket jag använt mig av i mitt arbete.
3.1.2 XML parser
Eftersom XML filer innehåller betydligt fler tecken än en flatfil så behövdes en snabb XML parser som inte höll så mycket data i minnet då systemet kunde bli segt om flera hundratusentals kontrolluppgifter skulle hanteras. Jag kom fram till att följande XML parsers fanns att tillgå i Java: SAX, DOM och StAX.
3.1.2.1 SAX (Simple API for XML)
En SAX-‐parser skapar inte någon intern struktur av XML dokumentet utan istället tar den påträffandet av olika komponenter som event och talar om för klienten vad den läser under tiden den läser. Eftersom SAX-‐parsern inte skapar någon intern struktur så är den mycket minneseffektiv vid stora XML dokument. Parsern är också generellt snabbare och lättare att lära sig än DOM-‐parsern, dock så blir det mer för
programmeraren att hålla reda på då denne måste ta hand om all data som kommer och skapa sin egen struktur.
3.1.2.2 DOM (Document Object Model)
DOM-‐parsern bygger s.k. DOM-‐träd från XML dokument och sparar det i minnet. Fördelen med DOM-‐träd är att det är enklare för programmeraren att ta ut och förändra de delar som behövs. DOM-‐parsern läser alltid in hela XML dokumentet oavsett hur mycket data som behövs. DOM-‐parsern är väldigt ineffektiv om XML dokumenten är stora eftersom hela trädet hålls i minnet.
Eftersom det var som mest 500 000 kontrolluppgifter som fanns i ett XML dokument så fanns risken att systemets minne skulle ta slut. Därför ansåg jag att denna parser inte lämpade sig för arbetet.
3.1.2.3 StAX (Streaming API for XML)
StAX parsern är en blandning mellan DOM och SAX parser där det går att välja
antingen eller. Huvudingången för StAX är en filpekare som representerar positionen inom XML dokumentet. Applikationen flyttar sedan pekaren framåt och tar
informationen som den behöver från parsern.
3.1.3 Flatfilsparser
Eftersom flatfiler kan se lite olika ut så fanns det ingen direkt funktion som passade för att parsa de flatfiler jag hade till handa. Därför är alternativet att delvis läsa in filen (i s.k. "chunks") som programmeraren sedan får sålla ut data ur. Detta ansåg jag vara det mest effektiva sättet för att hålla prestandan uppe vid större flatfiler om hundratusentals kontrolluppgifter.
3.1.4 JPA (Java Persistence API)
JPA är ett ramverk som används för att mappa s.k. entiteter i form av klasser i Java till en relationsdatabas. JPA förenklar därmed anslutningen och hanteringen av databasen då utvecklaren inte behöver bry sig speciellt om hur databasen ser ut då detta specificeras i JPA.
3.1.5 JAXB (Java Architecture for XML Binding)
JAXB används för att mappa Java klasser till XML representationer. Detta förenklar uppbyggnaden av XML filer som skulle genereras som testdata då jag slapp bygga en egen funktion som skulle utföra samma sak.
JAXB tar ett XML-‐schema och genererar objekt utifrån elementen i det. XML-‐
schemat används senare för att validera att alla obligatoriska objekt finns med för att generera ett XML-‐dokument.
3.2 Databasdesign
Databasen ska ha tydliga och strukturerade relationer så den är lätt att följa, med så tydliga entiteter med så hög normalform som möjligt på databasstrukturen.
Med databasnormalisering menas att systematiskt för varje normalform (1NF och uppåt) stegvis minska redundans och beroenden i databasen.
Databasdesignen är enkel i detta fall, då detta specificeras och sköts av tidigare nämnt JPA, se 3.1.4. Endast en entitet kommer att existera i detta fall, vilket är "Kontrolluppgift" för båda filformaten, se utdraget av entiteten kontrolluppgift i kapitel 4.4.4.
3.3 Testning
Testningen ska vara likvärdig mellan filformaten då samma antal kontrolluppgifter ska testas för varje filformat. Det är viktigt att testa ofta och så mycket som möjligt då det kommer att förenkla arbetet och undvika eventuellt onödiga fel. Det är bra att använda olika testmetoder för att få olika synvinklar på programmet så det blir lättare att komma fram till ett bra resultat från början.
Nedan följer olika testmetoder som jag kommit fram till att jag tycker är bra och passar in på arbetsuppgiften.
3.3.1 Beteendetestning (Black box testing)
Den som testar känner endast till vad mjukvaran förväntas göra och inte hur
programmet fungerar. Det viktiga här är att programmet ger rätt utdata i förhållande till vad som kommer in. Denna metod är bra eftersom bl.a. saknade funktioner, fel i gränssnittet eller beteendefel uppdagas.
3.3.2 Glasboxstest (White box testing)
Testaren har tillgång till programkoden. Denna testmetod är bra för den garanterar att alla oberoende vägar/möjligheter har exekverats minst en gång. En risk med denna metod är att testerna kan anpassas för att matcha kodens funktion.
3.3.3 Enhetstest (Unit testing)
Utförs generellt av programmeraren. Denna metod brukar ske fortlöpande i takt med att arbetet fortlöper.
3.3.4 Lasttest (Load testing)
En metod för att testa hur systemet beter sig under större/tyngre laster.
3.3.5 Acceptanstest (Acceptance testing)
Används normalt för att verifiera om systemet möter kundens krav. Detta sköts normalt av kunden.
3.4 Användbarhet
Användbarheten är av stort fokus. Projektet ska kunna användas och vidareutvecklas efter min tid på Skatteverket. Klasser och projekt ska vara tydligt uppdelade med lämpliga namn som beskriver dess innebörd.
Att uppnå en hög abstraktionsnivå är bra, då programmeraren kan dölja mer komplicerade lösningar i konkreta modeller eller användargränssnitt.
3.5 Prestanda
Prestanda var något som var väldigt viktigt för examensarbetet, därför gick mycket av tiden åt till att forska i hur stor mängd data som kan läsas in i taget för att hålla en så bra prestanda som möjligt, då antalet kontrolluppgifter kunde variera från
hundratals till hundratusentals.
Prestanda är något som är viktigt i dagens läge. Därför var det viktigt att hitta de teknikerna och Java-‐biblioteken som fungerade bäst och gav bäst resultat vid inläsning av filformaten till databasen. Därför jämförde jag bland annat några olika tekniker för att läsa XML-‐dokument, men även olika sätt att läsa in flatfiler, se tidigare kapitel 3.1.2 samt 3.1.3.
3.6 Utvecklingsmiljö
Utvecklingsmiljön är väl kanske något av de viktigaste områden för att ett
programmeringsarbete ska kunna utföras. För att arbetet skulle kunna utföras så behövdes vissa program och verktyg vara installerat i utvecklingsmiljön.
3.6.1 IDE-‐program
Ett IDE-‐program (integrerad utvecklingsmiljö) innehåller textredigerare, kompilator och debugger. Bra exempel på dessa är Eclipse och NetBeans som båda har stöd för programspråket Java.
3.6.2 Databas
Då kontrolluppgifterna ska skrivas till en databas så finns det lite olika valmöjligheter som t.ex. Oracles gratisalternativ Oracle Database Express eller MySQL som är helt gratis. Båda alternativen är databaser som använder frågespråket SQL, så det är
4 Metod
4.1 Utvecklingsmetod
Under arbetet har jag valt att utveckla agilt med tio grovplanerade sprints/milstolpar som definierades i tidsplaneringen vilket reflekterade de veckor som
examensarbetet var inplanerat på.
4.1.1 Milstolpar
• Vecka 1
Planeringsrapport skrivs. Installation av test-‐ och utvecklingsmiljö påbörjas. • Vecka 2
Studie av filformat som ska behandlas. Ett testskript för att generera (unika) poster för de olika filformaten som ska testas tas fram.
• Vecka 3
Forska i och testa vilka tekniker som lämpar sig för arbetet. Detta ska göras innan själva arbetet.
• Vecka 4-‐6(7)
Implementation av de olika utvärderade teknikerna görs. • Vecka (7-‐)8
Prestandamätning görs. Arbetet färdigställs och en rapport innehållande en beskrivning av systemet lämnas in till arbetsplatsen där olika fördelar påvisas för de tekniker som använts. En bilaga med olika tester under olika laster lämnas även in till Skatteverket.
• Vecka 9
Reflektionsdokument och rapport påbörjas. • Vecka 10
Reflektionsdokument och rapport.
4.1.2 Agil utveckling
Syftet med agil utveckling är att kunden hela tiden är nöjd med vad som utvecklas. Detta sker genom ett mycket nära samarbete och öppenhet under hela
utvecklingstiden med täta regelbundna möten mellan utvecklare och kund.
Utvecklingen sker iterativt vilket medför att många små delleveranser sker. Detta ger hela tiden en chans till utvärdering av systemet och kan därför lättare ändras för att möta nya krav och önskemål.
4.1.3 Mitt arbete
Då jag arbetade ganska tätt intill mina två handledare Björn Eklund och Gert Lundin så hade jag en naturligt daglig kommunikation med dem om mitt arbete. Därför talade jag ofta om hur jag låg till och vad jag höll på med för stunden och där av fick jag en naturlig feedback (daily communication).
Då jag hela tiden utvecklade fortlöpande så höll jag arbetet enkelt utan alltför komplicerade lösningar. Jag lämnade även många små delleveranser utav systemet. Detta för att ge rum för eventuellt plötsliga förändringar eller önskemål som skulle kunna uppstå.
Mot arbetets slut så förfinade jag och snyggade till koden samt dokumenterade systemet så det blev mer lätthanterligt att använda och vidareutveckla i framtiden.
4.2 Testning
Testning av systemet har hela tiden skett fortlöpande i takt med alla små
delleveranser som jag levererade. Jag testade hela tiden att systemet fungerade som förväntat innan jag gick vidare till nästa del.
Inga testfall skrevs för systemet då bland annat JAXB som genererar XML-‐dokument utifrån ett XML-‐schema som jag tillhandahöll från Skatteverket validerar att XML-‐ dokumentet är korrekt utifrån schemat innan filen skapas. Sedan var det även svårt att validera tidsåtgången för bearbetning av KU-‐filerna som var en av de
intressantaste aspekterna när det gällde prestandan för systemet, då det var det som skulle utvärderas. Det jag gjorde här var att notera tiden och föra in det i ett Exceldokument för de olika filformaten. Jag noterade även att rätt antal
kontrolluppgifter hade skrivits till databasen för varje filformat efter varje mätning. De egentliga testerna som utfördes var generellt de som är beskrivna i kapitel 3.3 (bortsett från enhetstestet). Främst så kontrollerade jag hela tiden att systemet klarade av tyngre laster (lasttest, se kapitel 3.3.4), då det förekom vissa problem när många kontrolluppgifter skulle genereras eller parsas när antingen minnet tog slut eller att en "anslutnings-‐time-‐out" förekom till WLSen. Orsaken till time-‐outen var när många antal KU bearbetades och WLSen inte gav något svar inom en viss tidsram vilket var satt till 30 sekunder från början. Det jag gjorde för att lösa problemet var att sätta connection-‐time-‐out till 1800 sekunder (en halvtimme) så förekom inte problemet något mer.
4.3 Utvecklingsmiljö
Nedan går jag igenom de program och verktyg som jag har använt mig utav i mitt arbete.
4.3.1 Rational Rose
Rational Rose är ett objektorienterat UML designverktyg som är avsett för visuell modellering. Rose används för att skapa ramen för ett program genom att definiera klasser med attribut och metoder. Rose ger en bra överblick och grund på de klasser som ingår i projektet.
Rose användes för att generera tomma Java-‐klasser som sedan implementerades med själva koden för parsningen för att tillslut publiceras på WLSen.
4.3.2 Apache Ant
Ant är ett kommandoradsverktyg som används som byggstöd för
mjukvaruutveckling. Ant använder s.k. byggfiler vilket är XML dokument som beskriver byggprocessen och beroenden. Byggstödet är speciellt framtaget för att användas till Javaprojekt.
Ant är väldigt bekvämt att använda i större projekt som innefattar många källkodsfiler.
4.3.3 Eclipse IDE-‐mjukvaruutvecklings-‐verktyg
Eclipse är ett IDE mjukvaruutvecklings-‐verktyg med stöd för många olika programmeringsspråk och plugins. Skatteverket använder Eclipse som
utvecklingsmiljö i sina projekt och jag var mest bekant med programmet sedan tidigare så därför föll valet på att använda Eclipse.
4.3.4 Databas
Då uppgiften var att utvärdera inläsningen av filformaten till en databas så behövdes en bra och stabil databas som klarar av ett högt tryck och att många frågor (queries) ställs till den samtidigt.
Då Skatteverket använder programvara från Oracle så föll även valet där på att använda Oracles databas "Oracle Database Express" som har stöd för SQL och är gratis. Gränssnittet för att hantera databasen var inte något som jag satte mig in i så mycket då JPA (se 3.1.4) skötte det mesta. Men vid de tillfällen då jag behövde kontrollera något så använde jag kommandoraden för eventuella
databasförfrågningar.
4.3.5 Oracle WLS
En WLS, eller Web Logic Server används för att agera bl.a. Java EE applikationsserver som i detta fall. På WLSen så publicerade jag min huvudapplikation som parsade filformaten. Applikationen kommunicerade med en Oracle databas där
informationen från filformaten hamnade.
För att ansluta till applikationen på WLSen så byggs en klient som kan kommunicera med den.
4.4 Tekniker
4.4.1 JAXB
När jag upptäckte JAXB (se, 3.1.5) så förenklade det en stor del av mitt arbete då jag besparades att skriva en egen funktion som gjorde precis samma sak.
En fördel med JAXB är att den validerar XML-‐objekten mot XML-‐schemat innan den skapar XML-‐dokumentet.
Nackdelen är att hela XML strukturen hålls i minnet tills dess att den skrivs till fil, vilket kan medföra att arbetsminnet som programmet är tilldelat kan ta slut ifall strukturen blir stor. Detta kan dock lösas enkelt på så vis att programmet tilldelas
Figur 2: Eclipse™ är ett populärt IDE mjukvaruutvecklingsverktyg
mer minne, antingen via Eclipse eller genom kommandoraden när JAR-‐filen exekveras.
4.4.2 SAX-‐XML parser
Med förmån till SAX-‐parserns låga minnesanvändning så valde jag att implementera SAX-‐parsern för systemet eftersom t.ex. DOM-‐parsern inte hade varit optimal då flera hundratusentals kontrolluppgifter skulle behandlas i värsta fall.
En lösning med StAX parser gjordes också. Det var dock inget som fanns med i den slutgiltiga produkten då jag såg att SAX-‐parsen var snabbare än StAX-‐parsern vid en enklare jämförelse mellan dessa.
4.4.3 Flatfils-‐parser
I och med att det inte fanns en inbyggd parser för flatfiler så valde jag att skriva en egen som läser in Skatteverkets flatfiler bitvis (i chunks). Dessa bitar delas upp med hjälp av separator-‐tecknet "#" och med nyckelord som beskriver vilket fält värdet tillhör.
4.4.4 JPA
Jag valde att använda JPA för att hantera databasanslutningen till Oracle-‐databasen. Det var väldig smidigt på så sätt att jag inte behövde skriva några direkta
databasförfrågningar utan JPA skötte allt åt mig.
Ett utdrag på entiteten "Kontrolluppgift" som användes i arbetet är enligt följande: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 @Entity
public class Kontrolluppgift implements Serializable {
@Id
@GeneratedValue private long id;
@Column(unique = true) private String personnr; private String namn; private String adress; private String postort; private String postnr; private String ug; ... public Kontrolluppgift() { super(); }
public long getID() { return id;
}
public void setID(long id) { this.id = id;
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 return personnr; }
public void setPERSONNR(String personnr) { this.personnr = personnr;
}
public String getNAMN() { return namn;
}
public void setNAMN(String namn) { this.namn = namn;
}
public String getADRESS() { return adress;
}
public void setADRESS(String adress) { this.adress = adress;
}
public String getPOSTORT() { return postort;
}
public void setPOSTORT(String postort) { this.postort = postort;
}
public String getPOSTNR() { return postnr;
}
public void setPOSTNR(String postnr) { this.postnr = postnr;
}
public String getUG() { return ug;
}
public void setUG(String ug) { this.ug = ug; } ... }
5 Resultat
5.1 Arbetsförlopp
Nedan beskriver jag hur upplägget av arbetsförloppet såg ut för examensarbetet.
5.1.1 Generering av testdata
Första uppgiften för examensarbetet var att ta fram testdata i XML format samt flatfilsformat. Skatteverket tillhandahöll mallar för hur strukturen skulle se ut för båda dessa format.
Testdatan som användes i utvärderingen genererades i de två filformaten och utgick från samma basklass för att vara så likvärdiga som möjligt så en rättvis
prestandajämförelse kunde göras. Basklassen genererade unika personnummer och namn som hade en variabel som ökades med ett för varje ny kontrolluppgift.
5.1.1.1 XML-‐dokument
För att generera XML dokumenten valde jag att använda mig av JAXB. Då jag hade fått ett färdigt XML-‐schema från Skatteverket så var denna process ganska snabbt avklarad.
Nackdelen med JAXB var att hela strukturen hölls i minnet innan den skrevs ned till fil, vilket kunde resultera i att minnet tog slut om XML strukturen blev stor vid många KU. Detta löstes genom att tilldela Eclipse mer arbetsminne.
Ett exempel på en kontrolluppgift i XML-‐format finns att se i kapitel 8.1.1.
5.1.1.2 Flatfil
Flatfilen genererades rakt upp och ned enligt formatet som var förutbestämt från Skatteverket.
Ett exempel på en kontrolluppgift i flatfilsformat finns att se i kapitel 8.1.2.
5.1.2 Parsning av filformat
Efter att ha studerat olika tekniker för att parsa XML-‐ och flatfiler så kom jag fram till följande.
5.1.2.1 Parsning av XML fil
Som tidigare nämnts var jag tvungen att välja bort DOM-‐parsern på grund utav dess dåliga prestanda när stora XML-‐dokument ska behandlas (se 3.1.2.2). Jag valde därför att främst använda mig utav SAX-‐parsern, vilket var mycket mer
minneseffektiv då den sekventiellt läser in XML-‐dokument. StAX parsern använde jag även till en annan lösning för XML formatet bara för att jämföra de olika teknikerna och för att se om det var någon större skillnad. Resultatet var att StAX parsern var något långsammare än SAX parsern.
5.1.2.2 Parsning av flatfil
Det finns väl ett obenämnt antal lösningar för att parsa en flatfil. Mitt val föll på att läsa in ett X antal bitar/tecken i taget, där jag sedan tog ut de olika delarna utav inläsningen för varje KU i filen. Skulle en inläsning vara ofullständig, d.v.s. att den bröts mitt i en "uppgift" så sparade programmet den ofullständiga delen till nästa
5.1.3 Prestandajämförelse
Prestandajämförelsen som jag har utfört gick till så att jag skapade 9 st. KU-‐filer för båda filformaten med olika antal KU i varje fil om 100, 500, 1 000, 10 000, 50 000, 100 000, 200 000, 300 000 och 500 000 st.
Jag gjorde ett flertal prestandajämförelser för varje antal KU så jag såg att resultaten blev någorlunda lika varandra.
5.1.3.1 Sammanställning av prestandajämförelse
Skatteverket efterfrågade en testbilaga med bearbetningstider och diagram och för det så valde jag att använda Microsofts verktyg Excel.
Resultatet av prestandajämförelsen blev enligt följande graf. X-‐axeln motsvarar antal KU och Y-‐axeln tiden i millisekunder.
5.2 Användargränssnitt
I planeringen av examensarbetet så ingick inget grafiskt användargränssnitt (GUI). Men då tid fanns över efter att prestandatesterna hade slutförts så bestämdes det att ett GUI skulle tas fram.
Resultatet blev att jag använde mig av Java swing. Målet var att skapa ett enkelt gränssnitt där användaren kan välja antalet KU som ska parsas utifrån en
fördefinierad lista med testfiler. Applikationen skriver ut vilken parser som är snabbast och med hur många procent mer den är snabbare jämfört med den andra. Figur 3: Resultat för bearbetningstid av XML & Flatfil om 100 -‐ 500 000 KU
Gränssnittet visar även andra intressanta parametrar så som hur många KU som parsats när som mest arbetsminne användes av datorn samt hur många KU som parsades totalt från varje fil, vilket gör det enklare att se ifall någon parser eller KU-‐fil skulle misslyckas eller vara trasig förutsatt att användaren vet hur många KU som filen borde ha innehållit.
5.3 Databasstruktur
Eftersom examensarbetet endast innefattade en entitet "Kontrolluppgift" för databasen så blev det inte ett så stort ER-‐diagram.
Som tidigare nämnts så använde jag JPA för att sätta upp databasentiteterna i Java vilket underlättade för mig då jag inte behövde bry mig så mycket om databasen mer än att anslutningen fungerade mellan Java-‐projektet och databasen, samt att rätt antal kontrolluppgifter skrevs till databasen och även att databasen tömdes efter varje fil som parsades. Ett utdrag av databasentiteten kontrolluppgift går att se i kapitel 4.4.4.
5.4 Programkod
För exjobbet så skapade jag totalt fyra projekt, varav det första används för att generera testfilerna och de tre andra bygger på varandra för att parsa
kontrolluppgiftsfilerna. Jag kommer därför ta upp dem i följande ordning som jag utvecklade dem.
5.4.1 Statistik
Projekt ett; Detta är projektet som genererar test-‐KU-‐filerna. Projektet är
ensamstående och innefattar totalt 4 filer som jag skrivit själv, 18 stycken som genererades av JAXB samt ytterligare 3 filer som är XML-‐schemat som jag fick från Skatteverket. Totalt antal rader som jag skrev för detta projekt var 821.
Projekt två; Projektet är själva basen för parsningen och är en del utav applikationen
som ligger på WLSen. Projektet parsar båda filformaten och skriver
kontrolluppgifterna till SQL-‐databasen. Projektet består av 8 filer som jag skrivit själv, samt 1 fil som lånades från en tidigare kurs TDP024 där jag även använde JPA. Det totala antalet rader som jag skrev för projektet var 1847.
Projekt tre; En del av projektet genererades av Rational Rose, vilket är den delen
som ska implementeras för WLSen. Men då jag gjorde projektet som parsar filformaten innan detta projekt så fick det bli så att det importeras som en JAR-‐fil i projektet. Totalt så genererade jag en klass i Rose som jag implementerade och blev på totalt 55 rader.
Projektet innehöll ett X antal andra filer som jag varken hade skapat eller hade möjlighet att räkna. Dessa filer fick jag av Skatteverket och var beroende av byggstödet Ant för att få upp applikationen på WLSen.
Projekt fyra; Projektet innehåller bland annat det grafiska användargränssnittet som
jag skapade för att förenkla prestandamätningen. Projektet innehåller även kommunikationen till applikationen på WLSen och implementerar vissa
Skatteverksspecifika funktioner i deras säkerhetsbibliotek. Projektet består av 3 filer som jag skrivit och innehåller totalt 265 rader kod.
5.5 Prestandamätning
Som tidigare nämnt så valde jag att implementera SAX parsern för att parsa XML-‐ dokument av förut förklarliga skäl. Jag försökte även att så gott som möjligt
optimera koden jag skrev för att parsa flatfiler. Resultatet av prestandajämförelsen kan ses i grafen i figur 3 som visar bearbetningstiden för båda filformaten om 100 till 500 000 KU.
Prestandamätningarna som jag utfört för filformaten var vid vissa tillfällen lite oviss då bearbetningstiderna varierade för samma antal KU om dessa parsades ett par gånger efter varandra.
Jag kan dock ha kommit på en potentiell lösning vilket är att ändra "last modified" eller senast ändrad-‐stämpeln som finns för alla filer i operativsystemet till den aktuella tiden när skriptet körs. Enligt min mening borde det vara en av
parametrarna som operativsystemet kontrollerar innan den lämnar ut filer från sin cache. Resultatet av bearbetningstiden blev aningen mer jämna efter att jag implementerade lösningen.
Jag kom även fram till att min flatfilsparser trots skillnaden i filstorlek mellan kontrolluppgiftsfilerna för flat och XML fil är 29% snabbare i genomsnitt än XML
6 Slutsats och diskussion
6.1 Egen reflektion och diskussion
Arbetet flöt på bra från början till slut. Det enda som jag fastnade på och som jag fick support av min handledare var när projektet skullen integreras med Skatteverkets säkerhetssystem och publiceras på den lokala WLSen.
Det var intressant att arbeta med stora mängder data då jag fick erfara hur det kan vara att inte ha all information tillgänglig hela tiden, med risk för att arbetsminnet skulle ta slut. Jag var därför tvungen att ta vara på det som var viktigt och göra något med det för att hålla minnesanvändningen så låg som möjligt. Att arbetsminnet tog slut var ett problem som återkom ett par gånger.
Resultatet av prestandajämförelsen med snittet på 29% (se tabell 1) skillnad i bearbetningstiden är rätt oväntat då den procentuella skillnaden i filstorlek är
konstant runt 80% (se tabell 2) mellan samma antal KU för filformaten. Jag tycker att flatfilsparsern presterade dåligt och att den procentuella skillnaden mellan
filstorleken och bearbetningstiden borde ha varit mer lika. Detta kan bero på att det ännu finns vissa delar kvar att optimera för flatfilsparsern, t.ex. antal tecken som läses in i taget vid varje bearbetning av data eller att en annan algoritm kan vara mer passande, t.ex. reguljära uttryck istället för att leta efter skiljetecken som min parser gjorde.
ANTAL KU XML FIL (ms) FLATFIL (ms) Procentuell skillnad
100 141 94 33,33 500 391 328 16,11 1 000 1 593 1 125 29,38 10 000 10 969 7 313 33,33 50 000 64 466 47 092 26,95 100 000 111 531 73 964 33,68 200 000 277 928 181 260 34,78 300 000 332 059 232 696 29,92 500 000 613 133 447 108 27,09 MEDEL 29,40 Tabell 1: Procentuell skillnad för bearbetningstid. Enligt formeln: 100 -‐ (minstTid/ mestTid) * 100. Där minstTid är filen som tog kortast tid att parsa (ms), mestTid är filen som tog längst tid att parsa (ms) och 100 som det hela (100%)
ANTAL KU XML FIL (kB) FLATFIL (kB) Procentuell skillnad 100 249 51 79,52 500 1 243 252 79,73 1 000 2 485 503 79,76 10 000 24 862 5 047 79,70 50 000 124 395 25 321 79,64 100 000 248 808 50 662 79,63 200 000 497 831 101 541 79,60 300 000 746 855 152 420 79,59 500 000 1 244 901 254 178 79,58 MEDEL: 79,64 Tabell 2: Procentuell skillnad för filstorlek. Enligt formeln: 100 -‐
