Kapitlet har gennemgået designet af det samlede system. Overordnet er syste-met designet eksibelt vha. moduler med hver deres ansvarsområde og udbud af services. Disse ansvarsområder og services er gennemgået i kapitlet.
Til designet af frameworket er valgt en trelagsopdeling, hvor præsentation, domæne og datakilde skilles ad. Hvert af disse lag indeholder moduler til at udføre lagets opgave.
Specielle dele af designet er beskrevet mere detaljeret. Pakkernes vej gennem systemet fra de kommer ind fra netværket som rå bytes til de ender på skærmen er gennemgået og det er blevet præsenteret, hvordan pakken struktur kan benyttes i en pakkedatabasestruktur, der gør ltrering eektiv. Denne databasestruktur giver mulighed for ltrering med køretiden O(k) hvor k er dybden af ltret deneret ved antallet af felter, der ltreres på.
Integrationen af Ruby i frameworket kan lade sig gøre ved dels at give brugeren hjælp i form af et Ruby hjælpebibliotek dels at dedikere en kommunikationskanal til interaktion mellem framework og Ruby script. Den protokol, der benyttes til kommunikationen, er præsenteret.
I kapitlet er et interface til protokolanalysator hhv. plug-ins designet, og det er beskrevet, hvilke aspekter, der er vigtige i implementeringen af disse, så frame-worket holder sin interne robusthed.
Undervejs i kapitlet er relevante design patterns introduceret i de sammenhæn-ge, hvor de kan gøre nytte og eektivisere designet.
Dermed er der skabt et overordnet design med en struktur for applikationen.
Der er tale om en fast men ikke komplet struktur for applikationen, da der skal være mulighed for ændringer af designet senere. Men strukturen kan benyttes i næste kapitel, hvor designet implementeres.
Kapitel 4
Implementering og teknisk test
Dette kapitel beskriver implementeringen af designet i C# til .NET platformen.
Kapitlet indledes med en beskrivelse af den benyttede implementeringsmetode.
Dette hænger sammen med, hvordan den tekniske test gennemføres, der derfor også bekrives her.
En beskrivelse af den egentlige implementering tager udgangspunkt i en beskri-velse af den generelle opbygning af frameworket. Herefter beskrives de ikke-trivielle dele af frameworket. Dernæst beskrives, hvordan frameworket bruges, dvs. det in-terface, der er mellem framework og protokolanalysator. I det efterfølgende afsnit beskrives, hvordan eksibiliteten i frameworket er opbygget, så det giver mulighed for tilføjelse af plug-ins.
Kapitlet vil koncentrere sig om den overordnede opbygning, dvs. klassernes individuelle ansvar samt forholdet mellem forskellige klasser. Desuden beskrives det, hvordan designet er implementeret. Der gives ikke en detaljeret beskrivelse af koden, da det ikke synes relevant for rapporten i stedet henvises til koden og kommentarer deri. Dog vil der blive redegjort for mere interessante specikke problemstillinger i implementeringen.
Indholdsfortegnelse
4.1 Implementeringsmetode og strategi for teknisk test . . . 56 4.2 Generel opbygning af framework . . . 57 4.3 Protokoldatabase . . . 59 4.4 Pakkehåndtering og pakkedatabase . . . 63 4.5 Integration af Ruby . . . 65 4.6 Brug af frameworket . . . 67 4.7 Plug-ins . . . 68 4.8 Konklusion på implementering og teknisk test . . . 69
55
4.1 Implementeringsmetode og strategi for teknisk test
I dette afsnit beskrives strategien for at vericere, at applikationen virker korrekt.
Denne strategi indeholder nemlig metoden, der benyttes til implementering.
Som beskrevet i afsnit 1.3.3 og 3.2 er Test-Driven Development (TDD) en oplagt metode at benytte i implementeringen. Generelt er losoen bag TDD at skrive tests til applikationen, før man implementer den. Implementeringen udføres iterativt ved at gentage tre faser [1] [4]:
Red fase Der skrives test, der afspejler kravspecikationen for applikationen. Te-stene gør, at applikationen ikke kan kompilere, idet der ikke er skrevet kode til applikationen endnu.
Green fase Applikationen implementeres med det ene formål, at de skrevne tests skal køre succesfyldt.
Refaktoreringsfase Koden refaktoreres så fx duplikeret kode elimineres.
De tests, der skrives, kan med fordel skrives vha. et xUnit framework og da .NET benyttes i implementeringen, er NUnit1et godt værktøj at benytte. xUnit er en familie af værktøjer til forskellige programmeringssprog, der letter realiseringen af automatiserede tests.
Fordelen ved at benytte TDD er, at man ved, at man, når ens tests forlø-ber fejlfrit, har opfyldt kravspecikationen. Derudover kan man efter ændringer i koden tjekke, at man ikke med sine ændringer har ødelagt andre dele af koden, idet man blot eksekverer alle sine tests igen. Metoden er velegnet i implemente-ringen af frameworket, idet der skrives tests for hvert modul, der tester modulet teknisk. Desuden skrives der en gruppe tests, der tester kommunikationen mellem modulerne.
Metoden er god, men kvaliteten af applikationen afhænger selvfølgelig af kva-liteten af ens tests. Det er vigtigt, at testene tester alle de muligheder, hvorpå en bruger kunne nde på at bruge applikationen. Dette indebærer bl.a., at testene skal være en god afspejling af kravspecikationen.
Men metoden kan ikke bruges i alle tilfælde. Fx er det svært at skrive auto-matiserede tests til brugergrænseaden, idet fx et klik på knap kan være svært at simulere realistisk. Dette aspekt af projektet testes derfor manuelt. Det samme gælder for multitrådede dele af applikationen, da en automatiseret test kan give forskellige resultater fra eksekvering til eksekvering. Denne del må i stedet testes manuelt, men da resultater her også vil variere, er det vigtigt, at designet af disse dele analyseres nøje inden implementering. Kapitel 3 har behandlet de vigtigste elementer indenfor dette område.
Det ligger udenfor dette projekt at beskrive TDD metoden i ere detaljer samt at beskrive de tests, der er benyttet i implementeringen formålet her er blot at dokumentere implementeringsstrategien og teststrategien. Da projektets mål lige-ledes er en prototype af et framework, der i sagens natur ikke er et færdigt produkt, ligger det derfor også uden for opgaven at teste applikationen fuldstændigt. Til gengæld er det en vigtig del af projektet at undersøge, hvorvidt frameworket over-holder brugerkravene dette vil der derfor blive set nærmere på i kapitel 6, hvor en konkret protokolanalysator præsenteres, der derfor kan benyttes som grundlag
1Værktøjet kan ndes på http://nunit.com tilgængelig 6/6-2007.
4.2. GENEREL OPBYGNING AF FRAMEWORK 57