Enigma. Gruppe: E4-105

Transkript

1 Enigma Gruppe: E4-105

2

3 Department of Computer Science Fredrik Bajers Vej 7 Telefon Fax Titel: Enigma Tema: Et større program Synopsis: Projektperiode: SW3, efterårssemesteret 2004 Projektgruppe: E4-105 Deltagere: Henrik Kragh-Hansen Jeppe Vestergaard Boelsmand Rasmus Dichmann Carlsen Rasmus Thorslund Jensen Adam Masoudn Tharaniharan Somasegaran Vejleder: Keld Pedersen Oplagstal: 8 Denne rapport omhandler Enigma maskinen, som blev brugt af tyskerne under anden verdenskrig. Der vil blive fokuseret på, hvordan en Enigma virker rent teknisk. Efter vi har beskrevet, hvordan en Enigma maskine virker, vil vi gennemgå det program, vi har udviklet, som kan simulere den Enigma, der blev brugt under anden verdenskrig. Vi vil desuden implementere en række ekstra features, så vores Enigma bliver mere dynamisk, og gør det nemmere, at sende chifrerede beskeder mellem to brugere, der begge har en udgave af vores Enigma program. Der vil blive udviklet et Command Line Interface (CLI), så vores program kan anvendes med kommandoer, og der vil blive udviklet et Graphic User Interface (GUI), hvor brugeren vil have adgang til avancerede features gennem en grafisk brugerflade. Sidetal: 96 Bilagsantal og art: 7 sider og 1 cd Afsluttet den 17. December 2004

4 Forord Denne rapport er udarbejdet ved Aalborg Universitet under studieretningen Softwareingeniør. Projektet er udarbejdet i projektperioden 2. september til 21. december Denne rapport omhandler den tyske Enigma cipher maskine, der blev anvendt af tyskerne under anden verdenskrig. Det forventes ikke, at man allerede kender til hvordan en Enigma maskine virker, da dette bliver forklaret i rapporten. Rapporten henvender sig til personer, der har interesse i, hvordan den tyske Enigma virker. Vi vil gerne takke Peter Axel Nielsen for lån af hans Enigma maskine, og Keld Pedersen for hans gode vejledning. Kildehenvisninger skrives med kantede parenteser [nummer på kilden], som refererer til en litteraturliste, der kan findes bagerst i rapporten. Når vi i rapporten skriver han eller hun, så mener vi han/hun. Kildekode forklaret i teksten vil være linieombrudt, og vil til tider ikke ligne det originale. Dette skyldes diverse kommentarer, som måtte være skrevet i kodefilerne og problemer med kodeopsætninger, som ikke vil være hensigtsmæssige at have med i rapporten. For at forstå koden, skal man kunne forstå objektorienteret programmering (OOP) og Java. Jeppe Vestergaard Boelsmand Rasmus Thorslund Jensen Tharaniharan Somasegaran Adam Masoudn Rasmus Dichmann Carlsen Henrik Kragh-Hansen i

5 Indhold 1 Indledning Enigma historie Beskrivelse af Enigma Stecker Rotor Indikator Ringopsætning Reflektor Eksempel på chifrering med Enigma Kravspecifikation kvalitetsmålskema Udviklingsmodeller Vandfaldsmodellen Evolutionær model Fjerde Generations Teknikker Spiral Model Valg af udviklingsmodel Design Enigma Components Stecker Reflector Rotor Enigma Dataminer WriteXML Config Alphabet Util XML standard ii

6 INDHOLD 5.2 Designet af den Grafiske Brugerflade Program layout Enigma vinduet Simpel Opsætning Vinduet Avanceret Vinduet Alfabet Kommando Brugerflade Argumenter Anvendelse af Brugerfladen Ekstra features i vores Enigma Kodebeskrivelse Kode standard Enigma kodebeskrivelse GUI kodebeskrivelse CLI kodebeskrivelse Testning Enigma test Unit tests Integrations tests GUI test Første fase Anden fase Tredje fase CLI test Konklusion på testning Evaluering af anvendte værktøjer Planlægning Versionsstyring Programmering Test metoder Konklusion Litteratur 81 A Kilde Kritik 82 B Værktøjs evaluering 84 C Planlægning 85 iii

7 Figurer 2.1 Abstrakt figur af Enigma Et eksempel på en stecker Oversigt over de originale rotorer Rotor 2 detaljeret Rotor 2 efter en rotation Forklaring af reflektor B Eksempel på chifrering af HELLO ENIGMA Vandfaldsmodellen Evolutionær model Overordnet model for fjerde generations udviklingsmodeller Spiral model Overordent design af vores program UML diagram af vores Enigma design Diagram over inputet til vores WriteXML Overordnet sturktur af vinduer, og deres sammenhæng Hovedvinduet Simpel Avanceret Alfabet vinduet UML diagram af vores Command Line Interface design Eksempel på chifrering af input Kontrol Flow Diagram Eksempel på chifrering af HELLO ENIGMA med GUI iv

8 Tabeller 2.1 Placeringen af notches på rotorerne Hvilke par der er på de tyske reflektorer Kvalitetsmål Variabler i alfabet klassen Alfabet konstruktøren Undersøger alfabetet for duplikerede bogstaver Finder pladsen af et bogstav Finder bogstavet på den givne plads cipher metoden i Enigma.java subcipher metoden i Enigma.java cipher metoden i Components.java cipher metoden i Rotor.java Tilføje en label til BorderLayout Tilføje en label til GridBagLayout Action i GUI Kommunikation med brugeren i CLI Testcases Kontrolstruktur v

9 Kapitel 1 Indledning Under første verdenskrig anvendtes morsekode til transmission af beskeder. En svaghed ved denne metode var, at alle som opfangede beskeden, og som kendte til morsekoden, kunne forstå beskeden. Derfor var det ikke så praktisk anvendeligt, for virksomheder som gerne ville beskytte sig imod industrispionage. Værre var det dog for militæret, hvor slagets succes afhang af beskedernes sikkerhed. Der blev derfor efterlyst en metode til at gøre kommunikation sikker på, og en løsning kom i form af Enigma maskinen. Denne rapport vil beskrive Enigma maskinen og dens funktionalitet, og chifrerings metoden gennemgås og analyseres. Derudover implementeres denne maskine i det objektorienteret programmeringssprog Java. Hovedvægten af rapporten vil ligge i programmet, beskrivelse af programmet og selve udviklings forløbet. 1.1 Enigma historie Enigma maskinen var oprindeligt udviklet til anvendelse indenfor industrien, for virksomheder, der havde brug for sikker kommunikationslinie, som samtidigt var let anvendeligt. Den blev opfundet og produceret af Arthur Scherbius, en tysk ingeniør. Enigma maskinen var så effektiv, at den hurtigt tiltrak det tyske militærs opmærksomhed. Det er som chiffer maskine i det tyske militær under anden verdenskrig, at Enigma er bedst kendt. Inden det tyske militær tog den kommercielle Enigma i brug, modificerede de den for at opnå endnu højere sikkerhed, men i det store hele fungerede maskinen på samme måde. En anden feature, som tiltrak det tyske militær, var størrelsen på Enigma maskinen. Den var transportabel, hvilket gjorde den ideel til blitzkreig strategien, hvor det var livsnødvendig med en perfekt koordinering imellem luft og jord styrkerne. Det tyske søværn gjorde også megen brug af Enigma maskinen. Især i ubåde var den et vigtigt værktøj, til at angive positioner på fjendtlige skibe og konvojer. På denne måde kunne ubådene koordinere 1

10 KAPITEL 1. INDLEDNING deres angreb, og derved forvolde størst skade. Tyskerne overvurderede dog graden af Enigmaens chifreringsevne. De var overbeviste om at koden var ubrydelig. De første som tog kampen op mod Enigma maskinen var Polen. Det polske dechifrerings bureau, BS4, opsnappede en af det tyske militærs Enigma maskiner, som var sendt til den tyske ambassade i Polen. De sendte pakken videre til den tyske ambassade, så de ikke ville fatte mistanke, men BS4 nåede at få undersøgt Enigma maskinen så omhyggeligt, at de var i stand til at duplikere den, samt dechifrer nogle tyske beskeder. I 1938 foretog tyskerne nogle ændringer i Enigma maskinen, bl.a. udvidede de systemet med to rotorer, så at der nu var fem i alt. Enigma maskinen kan indeholde tre rotorer, men når der var fem rotorer at vælge mellem, gjorde det koden endnu mere kompliceret, og polakkerne havde på det tidspunkt ikke ressourcer til, at fortsætte med dechifreringen af Enigma maskinen. Tyskerne chifrere de beskederne efter en forudbestemt dagsopsætning for rotorerne, reflektoren og steckeren. Derudover valgte operatøren, tre bogstaver som fungerede som tekstindstillingen for den pågældende kodningssession. Disse tre bogstaver blev skrevet to gange i starten af teksten med dagsopsætningen, og resten af koden blev chifreret med henhold til de tre bogstaver. Til sidst blev de tre bogstaver igen skrevet to gange med dagsindstillingen. Hvis man ikke er i besiddelse af dagsopsætningen, krævede det, at tusinder af forskellige opsætninger af Enigma maskinen skulle afprøves, for at gætte opsætningen. Til dette formål opfandt de allierede The Bomb. The Bomb bestod af 36 rotorer. Disse repræsenterer 12 Enigma maskiner hver med tre rotorer. Disse rotorer havde den samme tilslutning, som rigtige Enigma rotorer, og kunne på samme vis udskiftes. Så testede The Bomb alle muligheder for en korrekt enigma opsætning, og når maskinen landede på en sandsynlig opsætning, stoppede den, og den mulige dagsopsætning for beskeden kunne så verificere manuelt på en Enigma maskine. Afsnittet er skrevet ud fra hjemmesiderne About the bomb [2] og Enigma Applet [1]. 2

11 Kapitel 2 Beskrivelse af Enigma Dette kapitel vil først beskrive, hvordan Enigma maskinen teoretisk fungerer, derefter tilgå problemet mere direkte, og gennemgå et eksempel. Figur 2.1: Abstrakt figur af Enigma Figur 2.1 er en overordnet illustration af, hvordan chifreringen initialiseres. Enigmaen får et bogstav som input, som sendes igennem steckeren, som beskrives i afsnit 2.1, hvor bogstavet bliver ændret. Derefter igennem de tre rotorer, som beskrives i afsnit 2.2, hvor hver rotor ændrer bogstavet. Herefter ændrer reflektoren bogstavet, som beskrives i afsnit 2.5, og sender det retur gennem de tre rotorer, hvor det igen bliver ændret til et nyt bogstav efter hver passage. Sidst, men ikke mindst, går bogstavet gennem steckeren og returnerer det chifrerede bogstav. Sammenlagt skifter bogstavet tilstand ni gange inden det returneres til brugeren. Det næste afsnit vil redegøre for, hvad der sker i de enkelte bestanddele af Enigmaen, dvs. steckeren, rotorerne og reflektoren. 3

12 KAPITEL 2. BESKRIVELSE AF ENIGMA 2.1 Stecker En stecker virker som et omstillingsbord for tastaturet, brugeren kan opsætte steckeren, før Enigmaen tages i brug. Steckeren bytter om på bogstaverne i par. Brugeren sætter to bogstaver sammen, f.eks. kan H sættes sammen med G. Dvs. når brugeren taster H ændrer steckeren det til G, og omvendt når der tastes G ændres det til H. Det er muligt at sætte steckeren op for dele af, eller for hele alfabetet, men det er ikke nødvendigt for at anvende Enigmaen. Der eksisterer ikke nogen standard stecker opsætning, da dette var noget, der blev sat op ud fra dagsopsætningen, som blev beskrevet i Enigma historie. Figur 2.2: Et eksempel på en stecker På figur 2.2 illustreres en opsætning af steckeren. I Enigma maskinen er der to normale alfabeter under hinanden, og parrene forbindes med ledninger, men for at gøre det mere overskuelig, er det bogstav som inputtet skal chifreres til placeret under det normale alfabet. Det danner følgende par: (BI), (CS), (EJ), (FX), (GH), (KZ), (MV), (NT), (OR), (PU), (QW) Følgende bogstaver chifreres ikke: A, D, L, Y. Herefter følger en beskrivelse rotorerne. 2.2 Rotor Rotorer chifreres ikke par, men ikke desto mindre ændrer den ligesom steckeren bogstavet til et nyt bogstav, men hermed ophører alle lighederne. Når et input er chifreret, roterer rotoren, således at hvis den modtog to ens input, vil outputtet ikke være ens. På figur 2.3 ses de originale rotorer, der blev anvendt af tyskerne under anden verdenskrig. Rotor 1-5 er dem, som kan benyttes i en standard Enigma, og rotor 6-8 blev kun anvendt i den Enigma, som den tyske flåde benyttede sig af. Flåden havde også en version af Enigma maskinen 1, der kunne indeholde 4 rotorer, og den sidste rotor bestod af enten Beta eller Gamma rotoren. På figur 2.4 ses rotor 2, hvor det ses, hvordan de forskellige bogstaver bliver forbundet. Figuren har samme forbindelser, som rotor 2 har på figur 2.3, hvis G er input og stregen følges, så vil der returneres et R, hvilket er det samme som på den forrige figur. Problemet med figur 2.3 er, at det er svært at overskue, hvad der sker når rotoren roterer. 1 Der blev kaldt Shark 4

13 KAPITEL 2. BESKRIVELSE AF ENIGMA Figur 2.3: Oversigt over de originale rotorer Figur 2.4: Rotor 2 detaljeret Figur 2.5: Rotor 2 efter en rotation Figur 2.5 illustrerer et eksempel på, hvordan rotoren ser ud efter en rotation. Hvis inputtet igen er G, så ses det, at G linker til H, og hvis strengen følges, så hænger H sammen med U og U linker til T, hvilket resulterer i at G 5

14 KAPITEL 2. BESKRIVELSE AF ENIGMA returnerer et T, når rotor 2 er roteret en position. Tilsvarende sker i de andre rotorer. Den første rotor i Enigmaen roterer hver gang, den modtager et bogstav, hvorimod de andre rotorer kun roterer, hvis den forrige rotor står i notch eller de selv står i notch. Som tidligere illustreret på figur 2.1, kan rotorerne også chifrere bagfra. Når et bogstav passerer baglæns gennem en rotor, så svarer det til at chifrere nedefra og op på figur 2.5. Her vises, hvordan O chifreres på vej tilbage gennem rotor 2. O rammer op på P, og hvis stregen følges, så hænger P sammen med U, da der læses nedefra og op. U trykker derefter op på T, hvilket vil sige, at O returnerer et T, når rotor 2 er roteret en position, og bogstavet chifreres på vej tilbage gennem rotoren. På tabel 2.1 ses det, hvor der er notches på de forskellige rotorer. På Beta og Gamma rotorerne er der ikke notches, da disse rotorer altid skal være placeret længst til venstre, som sidste rotor, og de kan derfor ikke påvirke andre rotorer. Beta og Gamma rotorerne kan heller ikke roteres af andre rotorer. Rotor 1 Rotor 2 Rotor 3 Rotor 4 Rotor 5 Rotor 6,7 og 8 på R på F på W på K på A på A og N Tabel 2.1: Placeringen af notches på rotorerne 2.3 Indikator Det er vigtigt, at hver rotor står på samme måde, når der chifreres og dechifreres. Dette sikres ved hjælp af indikatoren. Indikatoren viser, i hvilken position hver rotor står, ved at vise et bogstav. Den har 26 mulige positioner den kan stå på, nemlig bogstaverne fra A til Z. Disse bogstaver er skrevet på ringen, se afsnit 2.4. Hver gang en rotor roterer skifter bogstavet i indikatoren. 2.4 Ringopsætning Ringen sidder omkring selve kernen af hver rotor, hvor kernen indeholder de krydsende ledninger, der bytter om på bogstaverne. Den kan ved hjælp af en tap og en bladfjeder låses fast på rotoren i en bestemt position, inden chifreringen begynder. Fordi de notches, der tvinger rotoren ved siden af til at rotere, sidder på ringen, er det ringen der bestemmer, hvornår rotoren skal rotere. Samtidigt sidder indikatorbogstaverne også på ringen. Derfor vil en given rotor altid rotere ved samme bogstav, uanset hvordan ringen er forskudt. Af samme grund kan brugeren derfor ikke umiddelbart se, hvordan 6

15 KAPITEL 2. BESKRIVELSE AF ENIGMA ringen er sat. Det eneste den gør, er at forskyde indikatoren i forhold til kernen. Derved gøres rotoren på en nem måde mere kompliceret. I næste afsnit vil der blive gennemgået, hvordan reflektoren fungerer. 2.5 Reflektor En reflektor chifrerer i form af par i stil med steckeren, forskellen ligger hovedsagligt i, at en stecker sender bogstavet igennem, hvor en reflektor sender bogstavet tilbage, så der bliver tale om et kredsløb. Tabel 2.2 viser en oversigt over de reflektorer, som tyskerne brugte i anden verdenskrig. Navn B C B Dünn C Dünn De par reflektoren har (AY)(BR)(CU)(DH)(EQ)(FS)(GL)(IP)(JX)(KN)(MO)(TZ)(VW) (AF)(BV)(CP)(DJ)(EI)(GO)(HY)(KR)(LZ)(MX)(NW)(TQ)(SU) (AE)(BN)(CK)(DQ)(FU)(GY)(HW)(IJ)(LO)(MP)(RX)(SZ)(TV) (AR)(BD)(CO)(EJ)(FN)(GT)(HK)(IV)(LM)(PW)(QZ)(SX)(UY) Tabel 2.2: Hvilke par der er på de tyske reflektorer Figur 2.6: Forklaring af reflektor B På figur 2.6 ses det, hvordan reflektor B linker de forskellige par sammen. Hvis bogstavet E rammer reflektoren, så chifreres det over til Q. Da reflektoren kobler bogstaverne sammen i stil med en stecker, så gælder det modsatte også, så Q chifreres til E. Der vil nu blive beskrevet et eksempel på, hvordan en sætning chifreres ved hjælp af Enigma maskinen. 2.6 Eksempel på chifrering med Enigma Dette afsnit vil tydeliggøre hvorledes Enigma maskinen chifrerer ved at gennemgå et eksempel skridt for skridt, men først skal Enigmaen sættes op. Først gennemgås opsætningen. Vores ring og indikator opsætning er sat til 111 og AAA, hvilket vil sige, at der ikke er nogen forskydning af hverken notches eller rotorer, når Enigmaen først begynder at blive anvendt. Der bruges rotor 1, 2 og 3. Rotorerne er sat op så bogstavet først chifreres af rotor 2, så 1 og til sidst 3. Den reflektor, der er valgt, er reflektor B, og som 7

16 KAPITEL 2. BESKRIVELSE AF ENIGMA stecker er der valgt den, som er blevet gennemgået i afsnittet vedrørende steckeren, og som kan ses på figur 2.2. Ring: 111 Indikator: AAA Rotor Reflektor B Stecker: (BI), (CS), (EJ), (FX), (GH), (KZ), (MV), (NT), (OR), (PU), (QW) Følgende bogstaver chifreres ikke af steckeren: A, D, L, Y. Enigma maskinen er nu sat op, og er klar til at chifrere en besked. Det der skal chifreres er: HELLO ENIGMA, der resulterer i følgende output NCGDNPHKYVL, med den valgte opsætning. Den originale Enigma maskine kunne ikke håndtere mellemrum, hvilket er grunden til, at outputtet står som ét ord. Herunder illustreres hvorledes H bliver chifreret til N. H skifter bogstav på følgende måde inden et N bliver returneret: H->G GHUT TTPP PPEE E->Q QQYY YYOO OPUT T->N Først går H gennem steckeren og bliver til G, som vist på side 4, som ses ved H->G. GHUT viser, hvordan G skifter til T ved at gå gennem rotor 2, som blev gennemgået på side 6. TTPP viser, hvordan T bliver chifreret gennem rotor 1, da rotoren ikke er roteret rammer T direkte ned på T, som viste ved eksempel på side 4. Tilsvarende sker i rotor 3, og derefter chifreres E til Q, gennem reflektoren, som vises med E->Q, som vist ved eksempel på side 7. Bogstavet chifreres nu tilbage gennem rotor 3 og 1, hvorefter den går igennem rotor 2, som illustreres med OPUT, som blev gennemgået på side 6. Til sidst chifreres bogstavet tilbage gennem steckeren, som returnerer et N. På figur 2.7 ses det, hvordan alle bogstaverne er blevet chifreret gennem steckeren, de tre rotorer, reflektoren, tilbage gennem de tre rotorer og til sidst igennem steckeren, hvorefter bogstaverne returneres. De tre bogstaver i parenteser efter denne række, beskriver hvad indikatoren viser, efter der er blevet sendt et bogstav gennem Enigmaen. Hjemmesiderne The Enigma cipher machine [4] og Enigma Applet [1] er blevet brugt som kilder til dette afsnit. 2 der gøres opmærksomt på at bogstavet chifreres fra højre mod venstre, så det er rotor 2 der først bliver aktiveret. 8

17 KAPITEL 2. BESKRIVELSE AF ENIGMA Figur 2.7: Eksempel på chifrering af HELLO ENIGMA 9

18 Kapitel 3 Kravspecifikation Kravspecifikationen er en essentiel del af enhver udviklingsproces. I dette afsnit vil kravene, sat af projektgruppen, blive redegjort for. Kravene vil først blive opsummeret og skrevet i en liste, dernæst uddybes disse. Overordnet krav Ikke-funktionelle krav 1. Skal implementeres i Java. 2. Skal følge Javadoc standarder. 3. Skal være testbart. 4. Konsistent. 5. Genbrugbart. 6. Modulært design. 7. Integrerbart. 8. Ensartet kodedesign. Funktionelle krav 1. Skal have en grafisk brugerflade. 2. Skal have en kommando brugerflade. 3. Skal kunne simulere den virkelige Enigma. 4. De fysiske bestanddele af Enigmaen skal implementeres enkeltvis. 5. Konfigurerbart gennem XML. 10

19 KAPITEL 3. KRAVSPECIFIKATION 6. Importer og eksporter TXT dokumenter. 7. Mulighed for implementation af alfabetet efter brugerens valg. 8. Skal selv kunne lave en tilfældig Enigma opsætning. 9. Skal kunne chifrere en hel streng. 10. Skal kunne indeholde et variabelt antal rotorer. 11. Skal kunne anvende brugerdefinerede rotorer. Uddybning af overordnet krav Ikke-funktionelle krav 1. Enigma programmet skal implementeres i programmeringssproget Java. Argumentationen for valget af Java er, at det er et af projektkravene, at programmeringssproget skal være objektorienteret. Derudover følger gruppen et kursus i objektorienteret programmering, hvor Java er det primære sprog, og derfor har gruppen den samme vidensbasis inden for dette. 2. Koden skal overholde Javadoc-standarder, således kommentarer kan kompileres separat, således de danner en kodedokumentation. 3. Det skal være muligt at foretage Black box og White box testning af programmet. Hvilket kræver at koden skal være veldokumenteret og forståeligt. Testen vil benytte sig af JUnit test. 4. Hvis steckeren, rotoren og reflektoren står ens, på to forskellige maskiner, og den sammen bogstavkombination indtastes på dem begge, skal de give et identisk chifreret output. 5. Det skal ikke være muligt at tilgå kildekoden, men det skal være muligt for andre programmører, at bruge pakkerne i andre programmer. Ved at læse programmets Javadoc kan andre programmører se hvilke funktioner de kan tilgå, og hvordan de fungere. 6. De enkelte moduler skal fungere uafhængigt af hinanden, f.eks. skal stecker og rotor modulerne fungere som individuelle objekter. Gruppen har derfor sat et kriterium at for så vidt muligt undgår at hardcode noget. 7. Kildekoden skal kunne, uden megen redigering, implementeres sammen med andre programmer, f.eks. et chatprogram, klient og lignende, hvor chifrering kan være nødvendigt. 11

20 KAPITEL 3. KRAVSPECIFIKATION 8. Det er vigtig at vores kode design overholder nogle faste regler, for hvad angår ensartethed. Dette vil i sidste ende gøre det mere belejligt for os, og andre at læse og forstå koden. Funktionelle krav 1. Den grafiske brugerflade skal skrives på dansk, selvom koden skrives på engelsk, da programmet hovedsagligt henvender sig til brugere i Danmark, hvorimod koden helst skal forstås af så mange som muligt. Den engelske oversættelse af grafisk brugerflade er graphical user interface, forkortet er det GUI. Gruppen har vedtaget at anvende GUI til at referere til den grafiske brugerflade i den resterende del af rapporten. Der vil være en uddybning af GUI krav på side Kommando brugerflade, er en tekstbaseret brugerflade, der på engelsk hedder commandline interface, der forkortes til CLI. Gruppen har vedtaget at anvende CLI til at referere til kommando brugerflade i den resterende del af rapporten. Der vil være en uddybning af CLI krav på side 13. CLI vil dog kun indeholde de features, der er i en standard Enigma. 3. Programmet skal kunne chifrere på samme vis, som Enigma maskinen anvendt i anden verdenskrig. 4. De fysiske bestanddele af Enigmaen skal implementeres i kildekoden som klasser, der simulerer de fysiske bestanddele. 5. Programmet skal kunne sættes op ud fra et XML dokument. Dette XML dokument skal indeholde informationer om hvordan stecker, rotor og reflektor skal sættes op. Standarden for dette XML dokument vil blive fastsat af vores gruppe. Dette dokument skal kunne eksporteres og importeres. 6. Programmet skal kunne importere et TXT dokument, for chifrering og dechifrering, for derefter at kunne eksportere dokumentet igen. 7. Brugeren skal have mulighed for at anvende et alfabet udviklet efter vedkommendes valg. 8. Programmet skal kunne lave en tilfældig Enigma opsætning, så brugeren ikke behøver bruge tid på at sætte Enigmaen op. 9. Det skal være muligt for brugeren, at vælge om vedkommende vil chifrere enkelte karakterer eller hele strenge. 10. Brugeren skal kunne vælge hvor mange rotorer, der skal være i Enigmaen. 11. Brugeren skal have mulighed for anvendelse af rotorer udviklet efter vedkommendes valg. 12

21 KAPITEL 3. KRAVSPECIFIKATION Uddybning af grafisk brugerflade 1. Overskueligt design - Knapper, menuer, etc. skal placeres efter en ordnet og logisk plan, så GUI fremstår overskuelig for brugeren. 2. Bruger venlig - Det er logisk at bevæge sig rundt i programmet, og benytte alle feature og metoder. 3. Ensartethed - Vinduer og knapper skal være ensartet størrelse. Uddybning af kommando brugerflade 1. CLI skal kunne konfigurer og lave forespørgelser til enigma modulet, så som at chifrere. 2. Ved programkaldet skal man kunne bruge argumenter til at indstille og få hjælp til at bruge programmet. 3. Skulle brugeren ved hjælp af argumenter ved programmet kaldet ikke give nok input, skal CLI spørge om dette. 4. CLI skal kunne skrive en XML konfigurations fil. Dog kun til en standard tysk M3 Enigma maskine. 3.1 kvalitetsmålskema Her er en vurdering af, hvor vigtige følgende kvalitetsmål er i vores projekt: Kvalitetsmål Meget vigtigt Vigtigt Mindre vigtigt Ikke vigtigt Brugbarhed X Integritet/sikkert X Effektivitet X Korrekthed X Troværdighed X Vedligeholdelsesvenlighed X Testbarhed X Fleksibilitet X Genbrugbarhed X Flytbarhed X Interopererbarhed X Tabel 3.1: Kvalitetsmål Vi vil nu begrunde, hvorfor vi har valgt vores prioritering, som vi har. Brugbarhed - Vi fokuserer ikke så kraftigt på brugbarhed, da det er ligetil at bruge en Enigma maskine. Det besværlige er at forstå, hvordan den virker, og dette er ikke nødvendigt for brugeren. 13

22 KAPITEL 3. KRAVSPECIFIKATION Integritet/sikkert - Vi har valgt, at datasikkerheden er uvigtig her, fordi enigma chifferet er helt åbent for alle. Det vigtigste ved et hvert chiffer er, at nøglen er skjult og den er lagret i XML filen, som vi går ud fra bliver transmitteret på en sikker måde. Effektivitet - Vi vil altid prioritere processorkraft frem for ram. Vi forsøger at opnå konstant søgetid i de dele af koden, der tillader det. Dette gøres på bekostning af at bruge mere ram. Dette er både for at gøre programmet mere brugervenligt med lavere svartider, og fordi en personlig computer nu om stunder, har relativt store hukommelseslagre. Korrekthed - For at kunne bruge en chifrerings algoritme, er det vigtigt, at resultaterne er til at stole på. Der sørger for, at implementationen er korrekt ved at teste den så grundigt som muligt. Troværdighed - At den same opstilling altid returnerer det samme output ved samme input. Vedligeholdelsesvenlighed - Vores kravspecifikation er statiske, så når disse er opfyldt, er det ikke nødvendigt at ændre i koden. Testbarhed - At der kan køres automatiske tests. Fleksibilitet - Er ikke så vigtigt, da vi som tidligere nævnt ikke skal ændre i vores system, når det først opfylder vores krav. Genbrugbarhed - At alle klasser skal kunne virke uafhængigt. Flytbarhed - Vi behøver ikke at være opmærksomme på, at vores kode skal være flytbart til andre platforme, da vi koder i Java er dette automatisk muligt. Interopererbarhed - Eksplicit defineret hvilke inputs programmet skal have, og hvilke outputs det returnerer. Skal kunne implementeres I andre programmer. 14

23 Kapitel 4 Udviklingsmodeller I følgende kapitel beskrives, hvordan de enkelte udviklingsmodeller anvendes, og hvilke fordele og ulemper der er ved disse modeller. I slutningen af dette kapitel, vil den udviklingsmodel vi finder bedst passende til projektet, blive udvalgt. Bogen Software Engineering [3] er brugt til alle udviklingsmodellerne. 4.1 Vandfaldsmodellen Vandfaldsmodellen blev introduceret for første gang i 1970erne. I hovedtræk opdeler metoden softwareudviklingen i faser. I den oprindelige model skal hver fase færdiggøres og dokumenteres, inden næste fase kan påbegyndes. På den måde overskueliggøres softwareprocessen, og det bliver dermed lettere at forudsige, hvor lang tid det resterende projekt vil tage. En af de største fordele ved anvendelsen af vandfaldsmodellen er, muligheden for en stram projektstyring, idet hver eneste fase skal grundigt dokumenteres. Ud fra dokumentationen af faserne, er det muligt, at vurdere om projektet halter eller overholder den planlagte tidsplan. Dokumentationen er med til at forbedre strukturen af projektet. Samtidig giver det et godt afkast til en rapport over projektforløbet. Her følger en kort beskrivelse af de forskellige faser. Krav specifikation: Fasen hvor projektets formål fastlægges dvs. hvilket problem der skal løses og hvilke mål der er gældende for projektet. Her igennem udvikles nogle specifikke krav, som alle dele af slutproduktet skal leve op til. System og software design: Fasen hvor systemarkitekturen bliver designet. Designet involverer identifikation og beskrivelse af de fundamentale abstraktioner og deres sammenhæng. Implementation og test: Fasen hvor designet bliver implementeret som 15

24 KAPITEL 4. UDVIKLINGSMODELLER Figur 4.1: Vandfaldsmodellen programkode, og hvorefter de enkelte enheder bliver testet og sammenholdt med kravspecifikationen. Integration og systemtest: Fasen hvor de enkelte enheder bliver testet som et samlet system, for at sikre optimal funktionalitet. Derefter bliver produktet leveret til slutbrugeren. Drift og vedligeholdelse: Fasen hvor systemet bliver installeret og anvendt i praksis. Uforudsete fejl og mangler bliver noteret og rettet. Dette er ofte den længste fase af vandfaldsmodellen. Fordele: Megen dokumentation Fast struktur Let at planlægge og overskue Ulemper: Fast struktur Ingen indbygget kunderinteraktion efter kravspecifikation Der er blevet redegjort for fordele ved denne model, men for overhovedet at kunne anvende modellen, skal kravene fra brugeren være præcist og utvetydigt defineret. Er dette ikke opfyldt, vil det ikke være muligt at udvikle et program, som tilfredsstiller alle involverede parter. 16

25 KAPITEL 4. UDVIKLINGSMODELLER 4.2 Evolutionær model Den evolutionære model eller prototyping, som det også kaldes, er en konstant udvikling og forbedring af prototyper indtil en endelig acceptabel version nås. Den evolutionære model er udviklet ud fra erfaringer hentet fra vandfaldsmodellen. Modellen fungerer dynamisk, dvs. det med lethed er muligt at modificere programkravene, uafhængig af hvilken udviklingsfase programmet undergår. Programmøren følger overordnet denne model 4.2. Figur 4.2: Evolutionær model I begyndelsen formuleres et sæt krav for programmet, herudfra udvikles en initial version, også kaldet en prototype. Denne testes, og uforudsete problemer noteres, og herefter introduceres prototypen for slutbrugeren. Derefter kommer slutbrugeren med feedback, i form af kravændringer og muligvis nogle yderligere krav. Med udgangspunkt i de nye krav udvikles en ny version. Denne version er dels baseret på noget af den gamle kode og dels noget nyt, dette er en intermediet version. Herefter gentages processen. Dette forløb stopper først, når en version nås, som både kunden og udvikleren er tilfredse med. En af de største fordele ved evolutionær programmering er uden tvivl muligheden for at opsnappe uforudsete problemer og herunder den sideløbende udvikling af kravspecifikation, i tæt samarbejde med slutbrugeren. Fordele: Dynamisk Let for slutbrugeren at komme med input Det er muligt at påbegynde programmeringen uden at kende til alle kravene Dette kan dog også betragtes som en af de største svagheder. Brugeren kan konstant komme med ideer til forandring og forbedring af programmet, hvilket kan medvirke til at presse deadlinen, og gøre projektet uoverskueligt for 17

26 KAPITEL 4. UDVIKLINGSMODELLER udviklerne. Der er nogle elementære svagheder i den evolutionære programudviklingsmodel. Ulemper: Manglende gennemskuelighed under projektudviklingen Kun lidt dokumentation imellem faserne Det færdige program er ofte dårligt struktureret Den evolutionære programudviklingsmodel anvendes først og fremmest til udviklingen af små, mellemstore programmer og grafiske brugerflader. Hvis programmet bliver for stort, vil problemerne blive for voldsomme, og det bliver umuligt at holde styr på alle faser af programmeringen. 4.3 Fjerde Generations Teknikker Vandfaldsmodellen og den evolutionære model har begge deres fordele, men som redegjort for tidligere i afsnit 4.1 og 4.2, har de også nogle svagheder. Ud fra nogle af de erfaringer udviklere har gjort sig med henhold til programmeringsfasen i disse udviklingsmodeller, udviklede de fjerde generations sprog. I dette afsnit redegøres for mulighederne ved anvendelse af disse. Figur 4.3: Overordnet model for fjerde generations udviklingsmodeller Udviklingsmodeller ved anvendelse af fjerde generations sprog består hovedsagligt af tre faser: En kravsspecifikationsfase, en programmeringsfase og en testfase. På figur 4.3 ses de tre faser. Kravene specificeres grundigt, og derefter udvikles koden. Til forskel fra de typiske sprog, udvikles koden ikke 18

27 KAPITEL 4. UDVIKLINGSMODELLER af programmører, men derimod genereres den automatisk ud fra kravspecifikationen. Dette sker normalt gennem en grafisk brugerflade, som derefter oversætter kravspecifikationen til kode. Fordelene ved anvendelse af fjerde generations udviklingsmodeller er at ændringer i kravspecifikationen automatisk medføre ændringer i koden. I andre udviklingsmodeller kan uforudsete hindringer, give store problemer for videreudviklingen af programmet. I værste fald kan disse betyde, at det er nødvendigt at begynde helt forfra. Fjerde generations udviklingsmodeller giver udviklerne mulighed for lige meget, hvor langt de er i forløbet at gå tilbage og ændre i kravspecifikationen, som det ses på figur 4.3. Denne frihed kan ikke opnås i nogen af de andre beskrevne udviklingsmodeller. Fordele: Uddybende kravspecifikation. Modellen giver en god forståelse af projekt udkastet i første omgang. Transformationen fra kravspecifikationer til koden er automatiseret. Kravspecifikationen kan optimeres for at få en bedre udførelse af selve programmet. Der forekommer dog nogle problemer, som begrænser mulighederne for denne model. Et af de største problemer er, at hvis muligheden for konstant at vende tilbage og redigere i kravspecifikationen udnyttes, kan strukturen i både kravspecifikationen og koden blive svag. En anden ulempe er, at den automatiske generede kode ikke altid er forståelig. Derfor kan optimering og vedligeholdelse af programmerne blive et stort problem. Derfor er denne model ikke anvendelig i udviklingen af store programmer. Ulemper: Den gentagende revidering af kravspecifikationen kan gøre strukturen meget svag. Koden som bliver genereret er ikke altid let læselig. Det kan være problematisk at optimere og vedligeholde. Modellen er meget anvendeligt til udvikling små applikationer og er ikke nær så praktisk til større programmer, som f.eks. det der skal udvikles i dette semester. 4.4 Spiral Model Spiral modellen er skabt ud fra erfaringer, og er et kompromis af andre udviklingsmodeller, der udnytter fordelene fra de andre modeller. I spiralmodellen 19

28 KAPITEL 4. UDVIKLINGSMODELLER udvikles prototyper, meget lig den evolutionære model, men spiralmodellen har også faser indbygget. Dette gør at den til dels også er dokumentbaseret som vandfaldsmodellen. En anden feature er, at denne udviklingsmodel tillader anvendelse af forskellige modeller til udvikling af koden. Figur 4.4: Spiral model Figur 4.4 illustrerer udviklingsfaserne ved anvendelse af spiralmodellen. Hver omgang i spiralmodellen indeholder fire faser: Kravspecifikation, design, kodning og evaluering. Efter hver omgang undersøges nødvendigheden af endnu en omgang i spiralmodellen. Hvis konklusion af evalueringen er, at endnu en runde er nødvendig, foretages en risikoanalyse. Derefter vælges en udviklingsmodel, der bedst lever op til kravspecifikationen, og denne anvendes under kodningsfasen. Spiralmodellen bygger på andre modellers fordele. Den arver f.eks. fra vandfaldsmodellen, med generering af dokumentation, men undgår en af vandfaldsmodellens største ulemper, nemlig den meget faste fase struktur. Derudover har udvikleren den fordel, at der laves periodiske reviews af kravene til projektet. Dette er med til at gøre spiralmodellen mere fleksibel. Ved anvendelse af spiralmodellen, er det ikke muligt at overskue hele udviklingsforløbet fra start til slut. Derfor er evalueringen sidst i forløbet essentiel. B Bliver denne ikke udført tilfredsstillinde, kan projektet blive forsinket. Fordele: Meget fleksibel Bedre feedback end f.eks. vandfalds modellen Mere dokumentbaseret end f.eks. den evolutionær model 20

29 KAPITEL 4. UDVIKLINGSMODELLER Ulemper: Manglende overblik over hele udviklingsperioden Spiral modellen findes i mange udformninger, med alt fra tre til seks inddelinger eller underfaser. Men fælles er hvorledes cyklusen indledes, og hvordan den afsluttes. Spiralmodellen mangler overblik over hele projektforløbet, og det kan skabe tidsproblemer i slutningen af dette. 4.5 Valg af udviklingsmodel Der er blevet redegjort for flere forskellige udviklingsmodeller, hver med deres fordele og ulemper. Et af kravene til dette semester er, at programmet implementeres i et objektorienteret sprog. Derfor er fjerde generations teknikker ikke anvendelige her. Evolutionær- og spiralmodeller kræver begge en stram projektstyring, og de udvikler begge prototyper. Dette er en fordel, hvis kravene ikke er specifikke. Vores kravspecifikation er fastsat fra anden side ved projektets begyndelse, da Enigma maskinen er fuldt defineret. Derfor vil en udviklingsmodel, som generer megen dokumentation, og hvor der ikke behøves at være så stram en projektstyring, være praktisk. Med dette i tankerne er valget faldet på Vandfaldsmodellen. 21

30 Kapitel 5 Design Dette afsnit vil beskrive designet af vores program, og de forskellige moduler, som vil blive programmeret til vores samlede produkt. Først beskrives selve opdelingen af programmet i moduler. Dette gøres for at opfylder kravet om at vores program skal være modulært, se afsnit 3. Figur 5.1 viser hvordan programmet er delt op. De tre dele er: Enigma modulet Graphical User Interface (GUI) Command Line Interface (CLI) Figur 5.1: Overordent design af vores program Denne opdeling gør det muligt at bruge hvilken som helst brugerflade til Enigma. Fordi det er muligt at udskifte en eller flere af brugerfladerne, uden at skulle ændre i de andre moduler. Til hvert modul er der et tilhørende UML diagram. Klasserne er repræsenteret ved firkantede kasser, som indeholder klassens navn, variabler og metoder. Hvis klassens navn er kursivt, så er der tale om en abstrakt klasse. Efter variabelnavnet er der angivet, hvilken type den repræsenterer. Efter 22

31 KAPITEL 5. DESIGN metodenavnet er der angivet, hvilken type metoden returnerer. Foran variabelnavne og metoderne er der angivet -, + eller #. Et - betyder at, det er en private variabel eller metode, hvorimod et + betyder at, det er public. Et # betyder, at det er en friendly variabel eller metode. 5.1 Enigma Dette modul skal fungere på samme måde som en Enigma maskine Som input skal den have en opsætning af maskinen dvs. hvilken stecker, reflektor og hvilke rotorer, der bliver brugt. Enigma modulet skal også have det input, som skal chifreres med den valgte opsætning. Modulet skal så returnere den chifrerede streng. Enigma modulets ansvar er, at simulere selve Enigma maskinens interne dele, dermed opfylder den vores krav om at skal kunne simulere Enigma maskinen, se afsnit 3. Modulet har tre slags klasser: De centrale klasser der er ansvarlig for at simulere enigma maskinen, config klasserne hvis ansvar er at hente og skrive konfigurationen fra/til en XML fil. De øvrige klasser er af mere til generelt brug af samtlige moduler. Opdeling i modulets centrale klasser er meget lig den fysiske konstruktion af en Enigma maskine, den er delt op i fem klasser: en styre klasse, kaldet Enigma, der styrer alle de andre komponenter. tre klasser der hver repræsenterer en fysik ting i enigma maskinen rotor, reflektor og stecker, en sidste klasse, der indeholder fælles træk for de fysiske ting i maskinen, denne klasse hedder Components. På figur 5.2 ses et UML diagram af vores Enigma design. Der vil nu redegøres for de enkelte klasser Components Components er en abstrakt klasse, der fungerer som overklasse for Stecker, Reflector og Rotor, Components ansvar er at levere nogle variabler og metoder til sine underklasser. Components indeholder: En friendly variabel cryptoalphabet som er af typen Alphabet, som vil blive gennemgået i afsnit 5.1.9, der indeholder det alfabet som metoden cipher bruger til at chifrere den givne karakter med. En friendly variabel clearalphabet som er af typen Alphabet. Der indeholder alfabetet i den korrekte rækkefølge. En public metode cipher. Metoden tager en karakter som input, og ud fra variablen cryptoalphabet og clearalphabet returnerer den en chifreret karakter. 23

32 KAPITEL 5. DESIGN Figur 5.2: UML diagram af vores Enigma design Stecker Stecker er en klasse, der arver fra den abstrakte klasse Components. Den udbygger ikke klassen med ekstra variabler eller metoder. Dens funktion er, at repræsentere den fysiske stecker i enigma maskinen. 24

33 KAPITEL 5. DESIGN Reflector Reflector er en klasse, der arver fra den abstrakte klasse Components, men den udbygger ikke klassen med ekstra variabler eller metoder. Ud fra et design- og programmeringsmæssigt synspunkt, er der ikke forskel på en stecker og en reflektor Rotor Rotor er en klasse, der arver fra den abstrakte klasse Components og udbygger den med seks variable, seks metoder og overskriver cipher metoden. Dens funktion er at repræsentere den fysiske rotor i Enigma maskinen. De sejs variable og seks metoder er: En private variabel rotationpointer, som er et heltal, fortæller hvor langt vi er henne i alfabetet En private variabel notches, som er et karakter array, indeholder de bogstaver, hvor der befinder sig et notch på rotoren En private variabel reversecryptoalphabet, som er af typen Alphabet, se afsnit 5.1.9, indeholder cryptoalphabetet, som det skal se ud, når rotoren chifrer baglæns En private variabel cipheringforward, som er af typen boolean, indeholder sandt, hvis vi går frem igennem rotoren, og indeholder falsk, går vi baglæns gennem rotoren En private variabel isrotatable, som er af typen boolean, indeholder sandt, hvis rotoren kan roteres, og indeholder falsk, hvis rotoren er i stand til at rotorer En private variabel nring, som er af typen heltal, fortæller hvor langt rotorens kerne er rykket i forhold til rotorringen, se evt. afsnit 2.4 En public metode cipher. Metoden tager en karakter som input, og ud fra cipheringforward vælger den, hvilket cryptoalphabet eller cryptoalphabet der skal bruges til at chifrere. Derefter chifrer og returnerer den en chifreret karakter En public metode atnotch. Metoden tager ingen input, men bruger variablen rotationpointer. Den returnerer sandt, hvis vi befinder os på et notch ellers returnerer den falsk En public metode rotate. Hvis metoden atnotch returnerer sandt, så skal rotoren roteres, hvilket sker ved at variablen rotationpointer tælles en op 25

34 KAPITEL 5. DESIGN En public metode rotateback der roterer rotoren bagud, ved at rotationpointer tælles en ned En private metode rearrangealphabet. Metoden bruges i konstruktøren til at lave reverse cryptoalfabet ud fra cryptoalfabet En public metode isrotatable, der returner værdien i isrotatable En public metode indicator der returner en karakter fra klartekst alfabetet beregnet ud fra rotationpointer og nring Enigma Enigma er selve klassen, der binder de forskellige klasser sammen, så modulet fungerer på samme måde som en Enigma maskine. Konstruktøren til klassen får en streng ind, der indeholder stien til en opsætningsfil. Klassen sender strengen videre til Config, se afsnit 5.1.8, hvor klassen henter sin opsætning fra. Klassen består af fire variabler, to metode og en procedure: En public variabel mode som er af typen heltal, der bliver sat til hvilken type alfabet der er tale om, se afsnit En private variable stecker af typen stecker indeholder steckeren En public variable rotorlist af typen rotorlist indeholder rotoren En private variable reflector af typen reflector indeholder reflektoren En public metode cipher der tager en streng som input, og returnerer den chifrerede streng. Metoden deler strengen op i karakterer og kalder metoden subcipher med enkelte karakter som input En private metode subcipher der tager en karakter som input, og returner den chifreret karakter. Metoden chifrerer ved hjælp af stecker, rotorlist og reflector En public procedure machinerotateback, der rotere hele maskinen bagud Dataminer Dataminer klassen læser opsætningsfilen. Den får filens placering i sit input, der er en streng. Klassen henter alle variabler til Enigma maskinen. Den har ni private statiske variabler, ni public statiske metoder og en procedure. En variabel strplainalpha, der er en streng og indeholder alfabetet. En variabel nplainalphabettype, der er et heltal og indeholder alfabettypen, se evt. afsnit omkring vores XML standard. 26

35 KAPITEL 5. DESIGN En variabel strstecker, der er en streng, og indeholder stecker parrene. En variabel strreflector, der er en streng, og indeholder reflektoren. En variabel strrotors, der er et array af strenge, og indeholder rotorenes chifrerings alfabeter. En variabel strnotch, der er et array af strenge, og indeholder rotorens notches. En variabel nring, der er et array af heltal, og indeholder ring indstillingerne for rotorerne. En variabel npos, der er et array af heltal, og indeholder positionen af rotorerne. En variabel nrotors, der er et heltal, og indeholder antallet af rotorer. En procedure minedata, læser XML konfigurations filen og gemmer dataet i overstående variable En metode getrotors, der returnerer et array af strenge, der indeholder strrotors. En metode getnotches, der returnerer et array af strenge, der indeholder strnotch. En metode getrings, der returnerer et array af heltal, der indeholder nring. En metode getposition, der returnerer et array af heltal, der indeholder npos. En metode getplainalphabet, der returnerer en streng, der indeholder strplainalpha. En metode getplainalphabettype, der returnerer et heltal, der indeholder nplainalphabettype. En metode getreflector, der returnerer en streng, der indeholder strreflector. En metode getstecker, der returnerer en streng, der indeholder str- Stecker. En metode getnumberofrotors, der returnerer et heltal, der indeholder nrotors. 27

36 KAPITEL 5. DESIGN WriteXML WriteXML er en abstrakt klasse, der har ansvaret for at skrive en enigma konfiguration til en XML fil. En public procedure writesetuptoxml tager en ArrayList som input. Den laver en XML fil ud fra listen. Inputtet skal være på formatet som vist på figur 5.3. Alt i ArrayListen er strenge, da det man ikke er muligt at tilføje basale datatype til en ArrayList. Figur 5.3: Diagram over inputet til vores WriteXML Config Config er en klasse, der får input fra et XML dokument ved hjælp af DataMiner klassen, se afsnit I dette XML dokument findes opsætningen til Enigmaen, dvs. hvilken reflektor og stecker, der skal anvendes, samt antallet af rotorer, og hvilke rotorer der skal anvendes. Derved opfyldes vores 28

37 KAPITEL 5. DESIGN tredje funktionelle krav: Konfigurerbart gennem XML. Efter at have læst konfigurationen bygger configklassen alle objekterne til maskinen. Klassen består af fem variabler og to metoder: En friendly variabel stecker indeholder et objekt lavet ud fra klassen Stecker, se afsnit En friendly variabel rotorlist indeholder en række af objekter lavet ud fra klassen Rotor, se afsnit i en ArrayList. En friendly variabel reflector indeholder et objekt lavet ud fra klassen Reflector se afsnit En friendly variabel plainalphabet som er af typen Alphabet, se afsnit 5.1.9, indeholder det alfabet der bruges. Den friendly variabel nplainalphabettype, som er af typen heltal, indeholder typen af alfabetet, se afsnit En private metode cyclicconvert. Metoden kaldes fra konstruktøren og modtager et alfabet som er cyklisk noteret 1. cyclicconvert omarangerer bogstaverne så de i stedet danner et kryptoalfabet Alphabet Alphabet er en abstrakt datatype, der lagre et alfabet. Dette er lavet for at gøre det lettere at chifrer, endvidere opnås der konstant søgetid i alfabetet. Dette er et af vores kvalitetsmål effektivitet, som beskrives i afsnit 3.1. Alphabet er kun i stand til at lave gyldige alfabeter med lige antal karaktere. Alphabet indeholder: Tre private variable, 2 private metoder og 5 public metoder. en private variabel arrayindexes et array af heltal, der starter ved den mindste karakters ASCII værdi, og går op til den største. Dette vil sige, at den første plads 3 er index af den karakter med mindste ASCII værdi, og den fortsætter op til den største ASCII værdi, array lænden er dermed største ASCII værdi minus mindste ASCII værdi. En private variabel arrayalphabet er et array af karakterer, der indeholder selve bogstaverne i alfabetet. 1 Cyklisk notation betyder at en karakter chifrerer til det til venstre for og det sidste i hver tuppel krypterer til det første. Det betyder at (AB) denoterer at A chifrerer til B og B chifrerer til A. I en stecker eller reflector er der kun to bogstaver i hver tuppel 2 Kryptoalfabetet ZBCDEFGHIJKLMNOPQRSTUVWXYA denoterer at A chifrerer til Z og visa versa. Det svarer i cyklisk notation til (AZ) eller (ZA) 3 index nr. 0 29

38 KAPITEL 5. DESIGN En private variable smallestcharinalphabet er et heltal, der fortæller værdien i ASCII af det mindste bogstav i alfabetet. En private metode containsduplicates der modtager et array af karakter og returnerer en boolsk værdi, der er sandt, hvis der skulle være to enes karakterer i arrayet. En private metode bettertochararray der modtager en streng som input og returnerer et karakter array ud fra strengen. Metoden bruger en try blok til at sikre sig imod NullpointerException En public metode indexof der modtager en karakter. Karakteren bliver brugt til at hente et heltal ud fra arrayindexes, denne værdi returneres. En public metode charat modtager et heltal som input, og returnerer ud fra arrayalphabet en karakter. En public metode tochararray returnerer et karakter array, hvilket er en kopi af arrayalphabet. En public metode tostring returnerer en streng dannet ud fra arrayalphabet. En public metode length returnerer længden af arrayalphabet, hvilket er et heltal Util Util er en abstrakt klasse, der indeholder data, der svarer til de rigtige 4 rotorer og reflektorer. Udover data, indeholder klassen også 5 metoder, der har forskellige anvendelses muligheder. Klassen indeholder fire variabler, som alle er static og final, to metoder, begge er statiske: En public variabel rotortype af typen array af strenge, der indeholder de 10 tyske rotor chiffer alfabeter. En public variabel notch af typen array af strenge, der indeholder de tyske rotors notches. Passer med pladserne til rotortype. En public variabel reflector af typen array af strenge, der indeholder de tyske reflektorer. En public variabel alphabet af typen streng, der indeholder alfabetet fra A til Z. 4 de fysiske dele fra den rigtige Enigma 30

39 KAPITEL 5. DESIGN En public metode getascii der ikke tager noget input og returnerer en streng, der indeholder et udvidet alfabet. Dette alfabet indeholder blandt andet æ, ø, å, tallene og en del symboler. En public metode randomizestring der tager en streng og et heltal som input, og returnerer den ændret streng. Metoden bruger heltallet til seed af en random generator, der tager et tilfældigt bogstav fra strengen, og putter det sidst i den streng, der skal returneres. En offentlig metode containssameletter tager to Alphabet er som input. Checker om det andet alfabet er indeholdt i det første alfabet. Den returnerer et heltal, nul hvis en eller flere bogstaver fra det anden alfabet ikke findes i det første. Et hvis der er de samme bogstaver og samme antal i begge alfabeter, og to hvis det andet alfabets bogstaver er indeholdt i det første alfabet. En public metode getextension der tager en fil som input og finder frem til hvilken fil type, der er tale om, ved at finde det sidste punktum og læse resten af strengen derfra. Metoden returnerer strengen den finder frem til. En public metode makeextension der tager en fil og en streng som input, den tager filen og tilføjer eller ændrer dens type til hvad strengen indeholder. Metoden returnerer så den nye fil. Herunder vil der følge en gennemgang af vores XML standarder. Programmet bruger XML filer til at gemme Enigma opsætningen. På den måde bliver det let for andre brugere af programmet at importere og eksportere opsætninger XML standard Vi har udviklet en XML standard i samarbejde med gruppe E Grunden til dette er, at for det skal være muligt at chifrere en beskeder på den ene maskine, og så sende denne chifrerede besked og XML filen. Det vil nu være muligt at dechifrerer beskeden, så man kan få den rigtige tekst frem igen, selvom man bruger en anden Enigma maskine til at dechifrere med. XML bliver brugt af alle moduler til at importere og eksportere Enigma opsætningen. De to klasser der styrer henholdsvis importere og eksporter metoderne er: WriteXML for eksport, som vi har designet i afsnit 5.1.7, og Dataminer for import, som vi har designet i afsnit I det følgende vil det blive beskrevet, hvordan XML filen skal udfyldes for at overholde standarden. Inde i tagget stecker, er der et text felt. Her er der en streng, som beskriver steckeren. Hvis A skal chifreres til J og Z chifreres til H, så skrives AJZH. Dette betyder, at man skal skrive det i par to og to, som bogstaverne kobles sammen. 31

40 KAPITEL 5. DESIGN <?xml version="1.0"?> <enigma> <stecker> <text></text> </stecker> <reflector> <text></text> </reflector> <rotor> <text></text> <notch></notch> <ring></ring> <pos></pos> </rotor> <alphabet> <text></text> <int></int> </alphabet> </enigma> Inde i tagget reflector, er der et text felt, her er der en streng, som beskriver reflektoren. Noteringen af reflektoren fungerer på samme måde som med steckeren, den eneste forskel er, at en reflektor skal indeholde alle bogstaver i alfabetet præcist en gang. Inde i tagget rotor, er der et text, notch, ring og pos felt, som bruges til at beskrive rotoren. Text feltet er selv kryptoalfabetet, som rotoren chifrerer klartekstalfabetet til. I notch feltet skal der stå de bogstaver i alfabetet, hvor der er notch. Ring feltet indeholder et heltal, der fortæller, hvor mange positioner ringen er forskudt. Tallet et svarer til, at ringen ikke er forskudt. Pos feltet indeholder et heltal, der fortæller hvilket nummer bogstav i alfabetet, der vises i indikator vinduet. Tallet et svarer til, at bogstavet A vises i indikatorvinduet forudsat, at det er et standard alfabet, der anvendes. Inde i tagget alphabet, er der et text og et int felt, som bruges til at beskrive alfabetet. Text feltet indeholder selve alfabetet. Int feltet indeholder en int, som viser hvilket type alfabet, der er tale om. Hvis det er tallet nul, er det et udvidet alfabet, ved tallet et er det et standard alfabet, og ved tallet to er det et brugerdefineret alfabet. Kun hvis int feltet indeholder to, er det nødvendigt at udfylde text feltet, da dette indeholder det brugerdefineret alfabet. 5.2 Designet af den Grafiske Brugerflade En GUI kan være med til at gøre selv de mest komplicerede programmer brugervenlig, og gør det samtidigt mere overskueligt at se på. I dette afsnit 32

41 KAPITEL 5. DESIGN redegøres for udviklingen af GUI, hvor der tilstræbes at opfylde kravene stillet til GUI under kravspecifikationen, se afsnit 3. Figur 5.4: Overordnet sturktur af vinduer, og deres sammenhæng GUI-designet, figur 5.4, er opbygget af to geometriske mønstre, firkanter og rhomber. En firkant betegner vinduer, der vil blive redegjort nærmer i dette afsnit. En rhombe illustrerer funktioner, da denne ikke indgår i GUI vil de ikke blive beskrevet. Enigma vinduet er det første vindue brugeren ser, når programmet initialiseres, gennem denne kan der navigeres til alle andre vinduer. Enigma vinduet giver adgang til funktionerne import og eksport, og vinduet simpel opsætning. Gennem simpel opsætning kan brugeren navigere videre til avanceret opsætning, herfra har brugeren mulighed for at implementere et alfabet efter smag og behag. Pilene mellem vinduerne illustrerer, muligheden for at gå fra det nuværende til det forrige vindue, f.eks. kan brugeren fra avanceret opsætning både gå tilbage til simpel opsætning, eller tilbage til Enigma vinduet. 33

42 KAPITEL 5. DESIGN Program layout Projektgruppen har valgt, at den grafiske brugerflade skal ligne noget, brugeren er vant til at bruge. Da Enigma programmet er skrevet i programmeringssproget Java, er programmet platformsuafhængigt, og den grafiske brugerflade vil automatisk tilpasse sig efter det operativsystem brugeren har. Generelt om hvert vindue kan der siges, at projektgruppen har valgt at give hvert vindue en overskrift. Fælles for dem alle er, at der findes en menubar, med forskellige menupunkter, og nederst i hvert vindue findes der knapper, der gør det lettere for brugeren at tilgå de forskellige metoder. Dette opfylder kravene vedrørende ensartethed og overskuelig vindue design, beskrevet i afsnit 3. I det næste afsnit vil alle vinduerne blive gennemgået: Denne Enigma brugerflade indeholder fire vinduer. De er: 1. Enigma Vinduet 2. Simpel Opsætning Vinduet 3. Avanceret Opsætning Vinduet 4. Alfabet Vinduet Det første vindue, Enigma vinduet er hovedvinduet. Det andet vindue er Simpel opsætning. Simpel opsætning anvendes til at opsætte rotorer, stecker og reflektor af Enigma maskinen. Simpel opsætnings vinduet giver mulighed for at sætte Enigma maskinen op, som det var muligt med den rigtige tyske Enigma. I det tredje vindue, Avanceret opsætning, er det muligt at opbygge sin egen unikke Enigma. Brugeren kan her frit vælge antallet af rotorer, og her er der mulighed for at anvende en af de eksisterende rotorer, eller designe sine egne rotorer, samt reflektor og stecker. Som standard bruger Enigma maskinen et alfabet der går fra A til Z. Men det er også muligt at udvikle sit eget alfabet, dette gøres i Alfabet vinduet, og det anvendes herefter i Avanceret Opsætnings vinduet. Designet er udviklet med programmet Microsoft Visio, denne laver billeder af vinduerne, der er magen til dem fra Windows XP. Vinduer udviklet i Java, vil rent grafisk afvige en smule, men der vil være tydelige ligheder fra det ene styresystem til det andet. Nedenunder bliver de fire vinduer uddybet enkeltvis Enigma vinduet I Enigma vinduet er det muligt at skrive klartekstbeskeden ind i klartekstfeltet, og den chifrerede besked bliver vist i det nederste tekstfelt, når der trykkes på chifrer knappen. Når brugeren vil chifrere sætningen HELLO ENIGMA, så skal brugeren skrive den ind i klartekstfeltet, så bliver hele 34

43 KAPITEL 5. DESIGN strengen chifreret samtidig til NCGDNPHKYVL og det bliver vist i det nederste tekstfelt 5. Enigma programmet giver også brugeren mulighed for at chifrere i realtime. Dvs. når et bogstav tastes ind i klartekstfeltet bliver det chifreret med det samme, dette kræver at enkelt tastetryk er slået til. På figur 5.5 ses design billedet af Enigma vinduet: Figur 5.5: Hovedvinduet Forklaring for hver enkelt metode i Enigma vinduet vil følge herefter. Først gennemgås Menubaren og dens menupunkter, derefter værktøjslinien, herefter bliver klartekst og chifrerings vinduet gennemgået, og til sidst vil de nederste knapper blive forklaret. Menubaren i Enigma vinduet indeholder tre menuer: Filer, Opsætning og Hjælp. 5 Denne tekst vil forekomme hvis man bruger samme opsætning som i vores eksempel, beskrevet i afsnittet om Enigma beskrivelsen

44 KAPITEL 5. DESIGN Menuen Filer indeholder fire menupunkter, Tilfældig Enigma, Importer tekst, Eksporter chifreret tekst og Luk. Tilfældig Enigma - konfigurerer en tilfældig Enigma maskine, ud fra den tyske standard Enigma, dvs. med tre rotorer, stecker, indikator, reflektor og ring opsætning. Når den tilfældige Enigma maskine er konfigureret, er programmet klar til at chifrere. Importer tekst - denne funktion muliggøre importering af tekst dokumenter af typen TXT, således det er muligt at chifrere den importerede tekst. Det er også denne funktion, der kan importere chifrerede tekster og dechifrere dem. Importer tekst funktionen opfylder vores funktionelle krav, vedrørende importering af tekst dokumenter, beskrevet i afsnit 3. Eksporter chifreret tekst - gør det muligt at eksportere den chifrerede tekst. Den eksporteret tekst bliver af typen TXT, således er det muligt at importere teksten tilbage i programmet igen. Eksporter tekst funktionen opfylder vores funktionelle krav vedrørende eksportering af tekst dokumenter, beskrevet i afsnit 3. Luk - dette lukker programmet. Menuen Opsætning indeholder fire menupunkter: Simpel opsætning, Importer opsætning, Eksporter opsætning og Enkelt tastetryk. Simpel opsætning - åbner et nyt vindue, hvor det er muligt manuelt selv at konfigurere en enigma. Hvordan opsætningen konfigureres bliver nærmere forklaret i afsnittet omhandlende simpel opsætning. Importer opsætning - denne feature gør det muligt at importere en anden Enigma opsætning. Denne funktion indlæser en anden opsætning, således kan en tekst chifreret af en trejdepart nemt dechifreres, uden at brugeren manuelt skal indtaste opsætningen. Ekspoter opsætning - denne feature gør det muligt at eksportere sin opsætning, dette gør det nemmere for andre brugere at dechifrere beskeder skrevet af brugeren, de behøver kun at importere opsætningen vha. deres Enigma. Enkelt tastetryk - dette er en feature, der gør det muligt at chifrere hvert enkelte anslag i realtime. For et nærgående eksempel se afsnit Det sidste menupunkt er Hjælp. Hjælp indeholder to menupunkter Guide og Om 36

45 KAPITEL 5. DESIGN Guide - dette er en hjælpefil, der forklarer alle funktioner i Enigma maskinen, og hvor der er et eksempel på hvordan Enigma programmet virker. Om - dette punkt fortæller brugeren, hvilken version af programmet brugeren har. Værktøjslinjen indeholder fire ikoner, disse er sat til at udføre de samme funktioner som under menuen Opsætning. Holder brugeren sin muse markør over ikonerne, vil funktionsnavnet fremkomme. Det næste i Enigma vinduet er de fire små vinduer: Dit alfabet, Indikatorer, klartekst og chifrer tekst. Dit alfabet - viser alfabetet som brugeren anvender. Det er som standard ikke muligt, at bruge æ, ø, å og specialtegn, da dette heller ikke var muligt i den oprindelige tyske Enigma. Indikatorer - viser brugeren, hvilken bogstav Enigmaens rotorer står på. Klartekst vinduet - her skal teksten, som skal chifreres indtastes. Det er vigtigt at klar teksten gennemgås for bogstaver som ikke er medtaget i alfabetet illustreret i Dit alfabet vinduet. Medtages bogstaver der ikke er med i Dit alfabet vil programmet skrive en advarsel til brugeren, når chifreringen initialiseres. Linie skift er heller ikke understøttet af programmet. For et eksempel på chifrering se afsnit chifreret tekst vinduet - i dette vindue vises den chifrerede tekst. Igen er det vigtigt, at huske på at mellemrum ikke bliver chifreret, den chifrerede tekst vises som et langt ord. De sidste to knapper der er nederst i vinduet er: Chifrer og Nulstil. Chifrer knappen initialiserer chifrering. Nulstil knappen sletter den indtastede tekst, og beholder de valgte indstillinger, men nulstiller dem Simpel Opsætning Vinduet I dette vindue er det muligt for brugeren at opsætte sin egen Enigma. Brugeren kan vælge mellem to standard indstillinger kaldet M3 og M4, disse bestemmer om, der er tre eller fire rotorer. Brugeren kan så selv definere rotor opsætningen, ringopsætningen og indikator opsætningen. Fælles for begge standard indstillinger er, at brugeren har mulighed for at indstille både stecker par og reflektor. På figur 5.6 ses designet for simple opsætnings vinduet. 37

46 KAPITEL 5. DESIGN Figur 5.6: Simpel Simpel opsætnings menubarer har to menupunkter, Filer og Hjælp. Menupunktet Filer har tre menupunkter: Avanceret, Nulstil, Tilfældig. Avanceret - Åbner Avanceret vinduet, se afsnit Nulstil - nulstiller alle indstillinger, og sætter Enigma programmet til en standard opsætning uden stecker par. Tilfældig genererer en tilfældig Enigma opsætning. Menu punktet Hjælp har to menupunkter: Guide og Om. Guide - dette er en hjælpefil, der forklarer alle funktioner i Enigma maskinen, og hvor der er et eksempel på hvordan Enigma programmet virker. Om - dette fortæller brugeren hvilken version og hvem har forfattet programmet. Herunder vil selve opsætnings vinduet blive beskrevet. Enigma type - her defineres hvilken model af Enigma maskinen skal anvendes. M3 er standard Enigma maskinen, ligesom den som blev anvendt at det tyske militær. M4 er den Enigma model, der blev anvendt af det tyske søværn. Den har en ekstra rotor, ring opsætning og indikator opsætning. 38

47 KAPITEL 5. DESIGN Rotor rækkefølge - denne funktion giver mulighed for at bestemme, hvilken rækkefølge rotorerne skal placeres i, her kan der vælges imellem tallene 1-8. Den ekstra rotor i M4 Enigmaen kan have en af to rotorer, kaldet Beta eller Gamma. Ring opsætning - ring opsætning giver mulighed for at sætte hvilken position, ringen skal starte på. Der er mulighederne Der er samme muligheder med begge Enigma maskiner M3 og M4. Indikator rækkefølge - her kan brugeren opsætte sin indikator. Indikatoren angiver hvilken position(bogstav) rotoren skal starte i. Det er muligt at sætte indikatoren i 26 positioner A-Z. Indikatoren viser brugeren, hvilken position rotoren står på. Der er samme muligheder med begge Enigma maskiner M3 og M4. Stecker par - stecker par giver mulighed for at sætte bogstav par op. Der kan max være 13 par, og det samme bogstav må ikke bruges to gange. Der er samme muligheder for begge Enigma modeller. Reflektor - her er mulighed for at sætte reflektoren. Der er fire valg muligheder. Der er samme muligheder med begge Enigma modeller M3 og M4. De fire knapper i bunden af vinduet, er genvejs taster til de mest anvendte funktioner. Ok knappen - laver en Enigma med det angivne opsætning. Programmet giver en fejlmeddelelse, hvis der er nogle værdier som ikke er valide. Ellers sendes brugeren tilbage til selve Enigma vinduet, og brugeren kan chifrere meddelelser med den valgte opsætning. Annuller knappen - sletter den valgte opsætning og vender tilbage til Enigma vinduet. Nulstil knappen - nulstiller alle indstillinger, og sætter Enigma programmet til en standard opsætning uden stecker par. Tilfældig knappen - konfigurerer en tilfældig Enigma opsætning. Avanceret knappen - åbner avanceret vinduet, se afsnit Fra simpel kan brugeren åben Avanceret opsætnings vinduet, der bliver beskrevet i næste sektion. 39

48 KAPITEL 5. DESIGN Avanceret Vinduet Som nævnt ovenover, giver Avanceret opsætning mulighed for brugeren at opbygge sin egen unikke Enigma, med henhold til bl.a. antal af rotorer, og indstillingen af disse. De tre vigtigste features i avanceret, er at antallet af rotorerne kan defineres, brugeren kan selv sætte notch punkter og vælge hvilket alfabet vedkommende vil anvende. På figur 5.7 ses designet til avanceret opsætnings vinduet. Figur 5.7: Avanceret Alle metoderne i selve Avanceret vinduet vil blive beskrevet herunder: Menubaren har tre menuer. Filer, Alfabet og Hjælp. Menupunktet Filer indeholder tre underpunkter: Simpel, Tilfældig og Nulstil. Disse funktioner, er tilsvarende de funktioner, der er i simpel Enigma opsætning. Simpel - sletter alle konfigurationer, brugeren har lavet i den avancerede Enigma, og sender brugeren tilbage til simpel opsætnings vinduet. Tilfældig - på samme vis som i simpel opsætning, konfigurer programmet selv en Enigma opsætning. Med antallet af rotorer, ringopsætning og indikator, rotor type, som er sat af brugeren. Nulstil - nulstiller opsætningen ved at sætte rotor typen til 1, ring opsætningen til 1, indikatoren til A, stecker par til ingenting og reflektor til B. Så er det muligt, for brugeren at starte forfra med at konfigurere en avanceret Enigma. Menupunktet Alfabet giver brugeren mulighed for, at ændre standard alfabetet A-Z til at inkludere æ, ø, å og specialtegn. Det er også muligt at 40

49 KAPITEL 5. DESIGN lave sit eget alfabet, med egne tegn. Alfabet indeholder følgende undermenupunkter. ABC...Z - denne indstilling sætter alfabetet til A-Z, og giver ikke mulighed for specialtegn, æ, ø og å. ABC...Z er valgt som standard, for det var det alfabet tyskerne anvendte. Dansk (med Specialtegn) - denne feature er en udvidelse af den oprindelige Enigma. Den åbner et nyt vindue, hvor brugeren skal vælge et antal af rotorer, og dernæst vil programmet automatisk opsætte resten af opsætningen. Herfra er der ingen mulighed for yderligere at konfiguration af Enigma maskinen. I det nye vindue findes der 3 funktions taster. Ok, Annuler og Simpel. Ok accepterer brugeren valget af rotorer, og sender den tilbage til Enigma vinduet. Annuller sletter alle konfigurationer og vender tilbage til Enigma vinduet. Simpel knappen sender brugeren tilbage til den simple opsætning vindue. Brugerdefineret - bliver nærmere forklaret i afsnittet Alfabet Vinduet består af en række funktioner, der gør det muligt for brugeren at opsætte den udvidede Enigma. Her er det muligt selv at definere antallet af rotorer, angive de enkelte dele af rotoren: Rotor typer, ring opsætning, indikator og selv konfigurere en rotor tekst. Som i simpel opsætning, er det muligt at sætte nogle stecker par og en reflektor. Antal rotorer - defineres af brugeren til det antal af rotorer vedkommende ønsker, dog maksimalt 500, og minimalt 1. Rotor nummer - alt efter hvor mange rotorer brugeren vælger, laver programmet selv en rotor opsætning for hver eneste rotor brugeren har valgt. Opsætningen ligner til forveksling den under til simpel opsætning, og i store træk er dette også tilfældet. De eneste tilfælde, hvor dette ændres er, når rotor typen står på brugerdefineret. Her er mulighed for at sætte, det ellers predefineret notch punkt, og rotor tekst.rotor tekst er hvordan den enkelte rotor sammenkæder et bogstav til et andet bogstav. Det er muligt at konfigurere en eller flere rotorer som standard rotorer. Ringopsætning, indikator og stecker par fungerer på samme vis som i simpel. Det er også muligt at sætte reflektoren som beskrevet i simpel opsætning, men det er også muligt selv at definere sin egen, ved at vælge brugerdefineret. Ok knappen - laver en Enigma med det angivne opsætning. Programmet giver en fejlmeddelelse, hvis der er nogle værdier som ikke er valide. Ellers sendes brugeren tilbage til selve Enigma vinduet, og brugeren kan chifrere meddelelser med den valgte opsætning. 41

50 KAPITEL 5. DESIGN Annuller knappen - sletter den valgte opsætning og vender tilbage til Enigma vinduet Nulstil knappen - nulstiller alle indtastninger, og sætter alle rotorer op til sammen standard indstilling. Simpel knappen - sender brugeren tilbage til simpel opsætnings vinduet Alfabet På figur 5.8 ses designet af alfabet vinduet, dernæst vil der følge en beskrivelse af det. Figur 5.8: Alfabet vinduet Alfabet vinduet gør det muligt for brugeren, at definere sit eget alfabet, dvs. selv bestemme hvilken bogstaver, tal og specialtegn Enigma maskinen skal anvende. Brugerdefineret åbner et nyt vindue, hvor brugeren selv skal indtaste det ønskede alfabet. Der er 2 knapper i bunden af skærmen, Ok og Annuller. Ok accepterer indtastninger og vender tilbage til avanceret vinduet, og Annuller sletter indtastningerne og vender tilbage til avanceret vinduet. 5.3 Kommando Brugerflade I dette afsnit vil designet af CLI 6 blive beskrevet. CLI er en ren tekst baseret brugerflade, der kan bruges i en konsol. CLI er bindeleddet mellem Enigma modulet og brugeren. Figur 5.9 illustrerer et UML-diagram af vores CLI. Ved udviklingen af UMLdiagrammet er det tilstræbt at opfylde kravene vedrørende interaktivitet og argument baseret anvendelse, som er redegjort i afsnit 3. Når CLI anvendes er det nødvendigt for programmet at afgøre om argumenterne givet af brugeren, har den rigtige syntaks. Derfor var det praktisk at dele modulet i to klasser, EnigmaCli og Input. Input modtager argumenter fra brugeren, og verificerer om det har den rigtige syntaks. EnigmaCli står for metode kaldene. Begge klasser vil blive nærmere redegjort for i afsnittene herunder. 6 Command Line Interface - Kommando Brugerflade 42

51 KAPITEL 5. DESIGN Figur 5.9: UML diagram af vores Command Line Interface design Argumenter Argumenter er det der skrives efter en kommandoen i en konsol. F.eks. giver dir /p i Windows kommando prompt en liste over hvilke filer, der er i mappen. Argumentet /p gør at man får vist en side af gangen, frem for at man får vist en lang liste, der er over en side lang. CLI kan acceptere seks forskellige argumenter. Tre af argumenterne producerer samme effekt. De er h,?, help. Disse argumenter kalder alle hjælpfunktionen. Disse argumenter og v virker kun som første argument, og tillader ikke andre argumenter at komme efter dem. Det første argument, der ikke indeholder et, bliver tolket som det afsluttende metode argument og som det første input, CLI læser hele kommando kaldet. De seks argumenter er: f <file> 7, hvor filen er konfigurations filen til Enigma modulet. h,?, help viser hjælpen til CLI, som inkludere en liste over acceptable argumenter, og hvem der er programmørerne. i giver den CLI besked om, at den ikke skal bruge input, og derfor kun skal teste om konfigurationsfilen kan bruges til at lave en Enigma maskine. v viser versions information omkring den CLI man bruger Anvendelse af Brugerfladen Brugeren har to måder, at anvende Enigmaen på gennem CLI, interaktivt eller med argumenter. 7 < > betyder krævet input 43

52 KAPITEL 5. DESIGN Interaktivt Interaktivt startes som standard, hvis programmet initialiseres uden argumenter. Programmet vil som det første bede brugeren om et bibliotek, h- vor vedkommende har/vil have sin konfigurationsfil. Derefter bedes der om navnet på konfigurationsfilen brugeren vil anvende. Programmet tester om filen eksisterer. Hvis filen ikke eksisterer, bliver brugeren guided igennem opsætningsprocessen. Hvis filen eksisterer, så anvender programmet denne opsætning. Alt det indtastede bliver checket om det har den korrekte syntaks. Når konfigurationsfilen er lavet, bruger programmet filen til at lave en Enigma maskine. Programmet beder dernæst om teksten, som den skal chifreres, og viser så outputtet på skærmen. Herefter afsluttes programmet. Med Argumenter For at kunne chifrere, skal man have en konfigurations fil, som man indlæser med argumentet -f efterfulgt at stien til filen. Efterfulgt af teksten man vil have chifreret, f.eks. HELLO ENIGMA. Hele kommandoen vil se sådan ud. EnigmaCli -f C:\testXml.xml HELLO ENIGMA Det giver en direkte og hurtig chifrering af ens tekst. 5.4 Ekstra features i vores Enigma Da projektgruppens Enigma maskine ikke er bundet af at skulle være mekanisk, giver det gruppen muligheder for at lave en del flere features til den oprindelige tyske krigs Enigma. Det har gruppen så gjort, således at programmet er så brugervenligt så muligt. Nedenfor vil der derfor følge en liste over de ekstra features, projektgruppens Enigma implementationen har. Den implementeret Enigma kan selv konfigurere en tilfældig Enigma opsætning, således at maskinen er lige til at bruge Den implementeret Enigma kan chifrere hele tekst strenge, og ikke blot enkelte bogstaver som den oprindelige Enigma, men det er muligt at vælge enkelt tastetryk i Enigma implementationen. Den implementeret Enigma gør det let at importere en anden opsætning, samt at eksportere sin egen. Den implementeret Enigma gør det muligt, at importere en hel tekst og så chifrere den. Den implementeret Enigma gør det muligt, at definere antallet af rotorer og konfigurer indstillinger på disse. 44

53 KAPITEL 5. DESIGN Den implementeret Enigma gør det muligt at definere det alfabet programmet skal kunne chifrere og dechifrere. Disse features gør det lettere for en brugeren at bruge implementationen til at chifrere med. Selve metoden hvorved Enigma maskinen chifrerer, er stadig den samme som den oprindelige tyske Enigma maskine fra anden verdenskrig. Disse features er tilføjet for at opfylde nogle af de funktionelle krav, som vi fremsatte i vores kravspecifikation i afsnit 3. 45

54 Kapitel 6 Kodebeskrivelse Vi har udviklet vores program ud fra vores design i afsnit 5, og vores program består derfor af tre moduler. Vi har Enigma modulet, som indeholder koden, der skal bruges for at chifrere strenge, som den virkelige Enigma maskine gjorde. Vores GUI modul er en grafisk brugerflade til vores Enigma modul. Vores CLI modul er en konsolbaseret brugerflade til vores Enigma modul. Vi har valgt at illustrere kodeeksempler fra Enigma, GUI og CLI modulerne. Hele kildekoden kan findes på den vedlagte CD, vi vil kun beskrive udvalgte dele af koden, og redegøre for disse. Vi har selv udviklet disse tre moduler, og alle klasserne i modulerne. Her er en liste over hvor mange klasser, der er i de enkelte moduler: Enigma modulet indeholder 10 klasser og 7 test klasser. Modulet består af ca linier kode. GUI modulet indeholder 11 klasser. Modulet består af ca linier kode. CLI modulet indeholder 2 klasser. Modulet består af ca. 600 linier kode. Der vil først redegøre for vores kodestandard, herefter følger en beskrivelse af koden. 6.1 Kode standard Som vi beskrev i vores kravspecifikation, se afsnit 3, så vil vi overholde kodestandarderne for Java og JavaDoc. Vi vil overholde Java standarden, fordi det gør det nemmere at læse vores program. Det er specielt følgende regler, der skal overholdes. Koden skal skrives på engelsk. Klassenavne skal starte med et stort bogstav. 46

55 KAPITEL 6. KODEBESKRIVELSE Variabel og metodenavne starter med et lille bogstav. Variabler, metoder og klasser skal have sigende navne. Komplicerede kodelinjer skal kommenteres. Vi har valgt at skrive vores kode på engelsk, fordi syntaksen er på engelsk, og derfor giver det god synergi i koden, hvis det hele konsekvent står på engelsk. Vi har dog valgt at alt output til brugeren i vores GUI og vores CLI står på dansk, da programmet henvender sig til danske brugere. Vi vil overholde JavaDoc standarden, fordi det muliggør kompileringen af en html side, der redegøres for dokumentationen af vores kode. Vi bliver nødt til at overholde standarden for, at dette html dokument bliver lavet korrekt. Dokumentationen til vores kode kan findes på den vedlagte cd. 6.2 Enigma kodebeskrivelse Dette afsnit vil redegøre for, hvorledes vores enigma modul er udviklet. Det vil blive trivielt, hvis vi gennemgår hele koden, så i stedet har vi valgt at fremhæve enkelte metoder fra vores kildekode. Hele kildekoden kan som tidligere nævnt findes på den vedlagte cd. Vi vil indlede med en redegørelse af alfabet klassen, da denne er af stor betydning for vores program. Det er derfor vigtigt for læseren, at han forstår, hvordan denne klasse virker. Herefter vil vi redegøre for de metoder, som anvendes, når Enigmaen skal chifrere en besked. Alfabet klassen Alfabet klassen er lavet for at gøre det lettere at arbejde med alfabeter. Designet af alfabet klassen kan læses i afsnit Når der skal laves udskiftninger og fortolkninger af bogstaver i Enigmaen, sker der en masse casting af heltal og karakterer 1. Dette kan undgås ved at holde hele alfabetet i en streng, og udnytte indexeringen til at finde den valgte karakterer. Det kan være særdeles tidskrævende at søge i strenge, hvis der er tale om et stort alfabet. Det alfabetklassen gør, er at holde alle karaktererne i et array og alle karakterernes pladser i et andet array. Derved kan man i konstant tid slå op for at finde en karakters plads. Vi har valgt at kalde metoderne til at slå op i alfabetet, det samme som, hvis det var en streng, nemlig charat og indexof. Alle kodeeksemplerne i dette afsnit om Alfabet klassen er taget fra filen Alphabet.java, som ligger i pakken enigma. I starten af klassen, bliver der erklæret tre variabler, som kan ses på tabel Casting er en konvertering fra en simpel type til en anden 47

56 KAPITEL 6. KODEBESKRIVELSE 01 private int[] arrayindexes; 02 private char[] arrayalphabet; 02 private int smallestcharinalphabet; Tabel 6.1: Variabler i alfabet klassen Linie 01 Erklærer det array af heltal, som skal holde pladserne af karaktererne i arrayalphabet. Linie 02 Erklærer det array af karakterer, som udgør alfabetet. linie 03 Erklærer den mindste ASCII værdi i alfabetet. Den skal bruges af andre metoder, og derfor er den en instansvariabel i stedet for lokalt i konstruktøren. Konstruktøren til alfabet klassen kan ses på tabel 6.2. Linie Konstruktøren undersøger, om alfabetet indeholder det samme bogstav flere gange, ved at kalde metoden containsduplicates, som er vist på tabel 6.3. Hvis alfabetet inde holder duplikater kastes en exception. Linie 06 Hvis exceptionen ikke er blevet kastet, kører programmet stadigt og instansvariablen arrayalphabet sættes lig med argumentet. Linie 07 SmallestCharInAlphabet bliver sat lig med karakterværdien af et stort tal for at være sikker på, at det tal som ender med at være det mindste ikke er, det vi initialiserer med. Linie 08 Det største tal initialiseres til karakterværdien af nul af samme årsag. Linie ArrayAlphabet scannes og de største og mindste asciiværdier findes. Linie 17 ArrayIndexes initialiseres og den største og mindste asciiværdi bruges til at finde længden af arrayet. Alternativet er at erklære et array fra nul til den største asciiværdi, men derved bruger man unødvendig plads i hukommelsen. Linie Værdierne i arrayindexes initialiseres til -1. Derved er vi sikre på, at indexof metoden returnerer -1, hvis karakteren ikke eksisterer i arrayet. Linie Hver karakters plads i arrayalphabet bliver sat ind i arrayindexes på sin asciiværdi minus den mindste asciiværdi i arrayalphabet. 48

57 KAPITEL 6. KODEBESKRIVELSE 01 public Alphabet(char[] alpha) throws AlphabetException { 02 if (containsduplicates(alpha)) { 03 throw new AlphabetException( 04 "Your alphabet-string contains at least one duplicate letter"); 05 } 06 arrayalphabet = alpha; 07 smallestcharinalphabet = (char) 65537; 08 int largestcharinalphabet = (char) 0; for (int i = 0; i < arrayalphabet.length; i++) { 11 if (largestcharinalphabet < arrayalphabet[i]) 12 largestcharinalphabet = arrayalphabet[i]; 13 if (smallestcharinalphabet > arrayalphabet[i]) 14 smallestcharinalphabet = arrayalphabet[i]; 15 } arrayindexes = new int[largestcharinalphabet - smallestcharinalphabet + 1]; for (int i = 0; i < arrayindexes.length; i++) { 20 arrayindexes[i] = -1; 21 } for (int i = 0; i < arrayalphabet.length; i++) { 24 arrayindexes[(int) arrayalphabet[i] - smallestcharinalphabet] = i; 25 } 26 } Tabel 6.2: Alfabet konstruktøren Metoden containsduplicates sikrer, at et alfabet ikke indeholder det samme bogstav to gange. Metoden kan ses på tabel private boolean containsduplicates(char[] alpha) { 02 for (int i = 0; i < alpha.length; i++) { 03 for (int j = i + 1; j < alpha.length; j++) { 04 if (alpha[i] == alpha[j]) { 05 return true; 06 } 07 } 08 } 09 return false; 10 } Tabel 6.3: Undersøger alfabetet for duplikerede bogstaver 49

58 KAPITEL 6. KODEBESKRIVELSE Linie 02 Alle bogstaver i alfabetet gennemløbes. Linie Det valgte bogstav sammenlignes med hvert bogstav efter det. Hvis et bogstav optræder begge steder returneres sandt. Linie 08 Der returneres falsk, hvis det samme bogstav ikke optræder flere gange. Metoden indexof returnerer, som tidligere nævnt, pladsen af et bogstav. Metoden kan ses på tabel public int indexof(char inputchar) { 02 try { 03 return arrayindexes[(int) inputchar - smallestcharinalphabet]; 04 } catch (ArrayIndexOutOfBoundsException e) { 05 return -1; 06 } 07 } Tabel 6.4: Finder pladsen af et bogstav Hvis bogstavet ikke optræder skal -1 returneres. Da værdierne i arrayet blev initialiseret til -1 inden de rigtige karakterer blev sat ind, vil alle de pladser, som ikke er blevet skrevet over stadig indeholde -1. For at sikre at -1 bliver returneret, hvis et opslag er uden for arrayet, har vi valgt at bruge exception handling. Hvis man prøver at bruge en indexværdi, som er for høj eller lav med et array, bliver en ArrayIndexOutOfBoundsException automatisk kastet. Derfor behøver vi blot gribe den og returnere public char charat(int inputint) throws AlphabetException { 02 try { 03 return arrayalphabet[inputint]; 04 } catch (ArrayIndexOutOfBoundsException e) { 05 throw new AlphabetException("" + inputint 06 + " does not translate to a letter between " 07 + arrayalphabet[0] + "(" + indexof(arrayalphabet[0]) 08 + ") and " + arrayalphabet[arrayalphabet.length - 1] + "(" 09 + indexof(arrayalphabet[arrayalphabet.length - 1]) + ")"); 10 } 11 } Tabel 6.5: Finder bogstavet på den givne plads Metoden charat returnerer karakteren på den plads, som inputtet angiver. Hvis den ikke findes i arrayet, bliver en AlphabetException kastet. Metoden kan ses på tabel

59 KAPITEL 6. KODEBESKRIVELSE Det næste afsnit vil redegøre for, hvordan selve chifreringen af teksten fungerer. Chifrering af input I afsnittet Beskrivelse af Enigma forklarede vi, hvordan en Enigma maskine chifrerer input. Dette har vi selvfølgelig implementeret i vores enigma program. På figur 6.1 vises, hvordan vores program chifrerer et input, det ses at opbygningen minder meget om den, vi beskrev i afsnittet Beskrivelse af Enigma 2. Figur 6.1: Eksempel på chifrering af input Metoden cipher tager som input en streng, man er interesseret i at få chifreret. Metoden cipher er vist på tabel 6.6. Cipher kalder så subcipher, som kan chifrere karakteren. Metoden subcipher er vist på tabel 6.7. For at subcipher kan chifrere karakteren, kalder den først cipher metoden i stecker objektet. Steckerens cipher metode er vist på tabel 6.8. Karakteren bliver nu chifreret ved at kalde cipher metoden i alle rotor objekterne. Rotorens cipher metode er vist på tabel 6.9. Cipher metoden bliver kaldt på reflektor objektet, og chifreres nu tilbage gennem rotorerne og steckeren. Reflektorens cipher metoden er vist på tabel 6.8. Cipher returnerer så den chifrerede streng. Vi vil starte med at forklare, hvordan cipher metoden virker. Metoden cipher findes i filen Enigma.java, som befinder sig i pakken enigma. Metoden kan ses på tabel 6.6. Designet af Enigma klassen kan læses i afsnit

60 KAPITEL 6. KODEBESKRIVELSE 01 public String cipher(string subject) throws AlphabetException { 02 char[] letters = subject.tochararray(); 03 for (int i = 0; i < letters.length; i++) { 04 letters[i] = subcipher(letters[i]); 05 } 06 return new String(letters); 07 } Tabel 6.6: cipher metoden i Enigma.java linie 02 Cipher erklærer først et array af karaktererletters til resultatstrengen. linie Hvert enkelt bogstav i arrayet af karakterere chifreres ved hjælp af subcipher og placeres på samme plads i arrayet af karakterere igen. Metoden subcipher kan ses på tabel 6.7. linie 06 Den chifrerede streng returneres. Subciphermetoden er den, der laver selve chifreringen af teksten. Metoden subcipher tager som input en karakter, som bliver chifreret. Opbygningen af subcipher metoden svarer til den, der er vist på figur 6.1. Metoden subcipher returnerer så den chifrerede karakter. Metoden subcipher findes i filen Enigma.java, som befinder sig i pakken enigma. Metoden kan ses på tabel 6.7. Designet af Enigma klassen kan læses i afsnit linie 02 En midlertidig rotor erklæres. linie 04 Inputkarakteren chifreres med steckeren. Steckerens cipher funktion er vist på tabel 6.8. linie 06 Laver en iterator til at passere gennem arraylisten af rotorer. linie 08 Den boolske værdi istoturn viser, om den rotor programet er ved, skal rotere på baggrund af om den foregående rotor stod i notch. Værdien istoturn initialiseres til sand, fordi den første rotor altid skal rotere. linie 09 Den boolske værdi atnotch initialiseres til falsk for at være sikker på, at man ikke får en nullpointerexception, hvis der bliver ændret i koden, så den ikke bliver initialiseret før, den bliver kaldt. linie Inden chifreringen af karakteren kan starte, skal alle rotorerne stå rigtigt, så vi gennemløber rotorerne for at kontrollere, om de skal rotere, og hvis dette er tilfældet, bliver de roteret. Så itereres der igennem rotorerne. 52

61 KAPITEL 6. KODEBESKRIVELSE 01 private char subcipher(char subject) throws AlphabetException { 02 Rotor tmprotor; subject = stecker.cipher(subject); ListIterator rotoriterator = rotorlist.listiterator(); boolean istoturn = true; 09 boolean atnotch = false; 10 while (rotoriterator.hasnext()) { 11 tmprotor = (Rotor) rotoriterator.next(); 12 atnotch = tmprotor.atnotch(); 13 if ((istoturn atnotch) && tmprotor.isrotatable()){ 14 tmprotor.rotate(); 15 } 16 istoturn = atnotch; 17 } rotoriterator = rotorlist.listiterator(); while (rotoriterator.hasnext()) { 22 tmprotor = (Rotor) rotoriterator.next(); 23 subject = tmprotor.cipher(subject); 24 } subject = reflector.cipher(subject); while (rotoriterator.hasprevious()) { 29 tmprotor = (Rotor) rotoriterator.previous(); 30 subject = tmprotor.cipher(subject); 31 } subject = stecker.cipher(subject); return subject; 36 } Tabel 6.7: subcipher metoden i Enigma.java linie 11 For hver element i rotorlisten sættes den midlertidige rotor til at pege på det element. linie 12 atnotch bliver sat til falsk eller sandt, alt efter om rotoren står ved notch linie Rotoren roteres, hvis den rotor før var ved notch, eller hvis den selv er ved notch, dog kun hvis den er i stand til at rotere. 53

62 KAPITEL 6. KODEBESKRIVELSE linie 16 istoturn bliver sat til det samme som atnotch, da den næste rotor skal rotere, hvis den foregående står i notch. Rotorerne står nu korrekt, og chifreringen kan gå i gang. linie Rotor-iteratoreren nulstilles, og der foretages en chifrering af karakteren for hver rotor. Alle rotorer har et flag, der bestemmer om, der skal chifreres forlæns eller baglæns. Hver gang en karakter bliver chifreret med en rotor skifter den retning, så rotoren chifrerer den modsatte vej næste gang. Det er fordi, hver karakter skal igennem rotorerne to gange. Rotorens cipher funktion er vist på tabel 6.9. linie 26 Efter karakteren er blevet chifreret af alle rotorerne en gang, sendes karakteren gennem reflektoren. Reflektorens cipher funktion er vist på tabel 6.8. linie Derefter chifreres karakteren med rotorerne igen. Denne gang starter vi ved den sidste og itererer baglæns. linie Der chifreres med steckeren igen og den karakter, der er tilbage returneres. Vi har valgt, at splitte rotationen af rotorerne og den første chifrering op, selv om det er mere effektivt at gøre det samtidigt. Det er lettere at se, hvad der sker når rotorerne roteres inden karakteren chifreres, og det er også på den måde, det sker i den mekaniske Enigma. Hvilket opfylder kravet vedrørende Skal kunne simulere den virkelige Enigma, se afsnit 3. Fælles for alle elementer i Enigmaen er, at de arver fra klassen Components. Både stecker og reflektor bruger den cipher metode, som er implementeret i denne klasse, rotor klassen overskriver cipher metoden. Det er centralt for forståelsen af Enigmaen, at man forstår, hvordan substitutionen af bogstaver sker i hvert komponent. Følgende kode er cipher metoden, som ligger i filen Components.java, som befinder sig i pakken enigma. Metoden kan ses på tabel 6.8. Designet af Components klassen kan læses i afsnit public char cipher(char subject) throws AlphabetException { 02 int worknumber = 0; 03 worknumber = clearalphabet.indexof(subject); 04 return cryptoalphabet.charat(worknumber); 05 } Tabel 6.8: cipher metoden i Components.java linie Variablen worknumber bliver sat til pladsen, på det bogstav, som skal chifreres i klartekstalfabetet og returnerer det bogstav, som står på den plads i kryptoalfabetet. 54

63 KAPITEL 6. KODEBESKRIVELSE Som tidligere nævnt arver steckeren og reflektoren denne metode uden at ændre den, men rotoren overskriver metoden, da denne cipher metode er lidt anderledes, bl.a. fordi den skal kunne chifrere både forlæns og baglæns. Følgende kode er cipher metoden, som ligger i filen Rotor.java, som befinder sig i pakken enigma. Metoden kan ses på tabel 6.9. Designet af Rotor klassen kan læses i afsnit En rotor har to kryptoafabeter, et der chifrerer 01 public char cipher (char currentchar) throws AlphabetException { int worknumber = 0; 04 int length = cryptoalphabet.length(); char tempchar; 07 worknumber = clearalphabet.indexof(currentchar); worknumber = (worknumber + rotationpointer + length) % length; if (cipherforward) { 12 tempchar = cryptoalphabet.charat(worknumber); 13 cipherforward = false; 14 } else { 15 tempchar = reversecryptoalphabet.charat(worknumber); 16 cipherforward = true; 17 } 18 worknumber = clearalphabet.indexof(tempchar); 19 worknumber = worknumber - rotationpointer; 20 worknumber = (worknumber + length) % length; return clearalphabet.charat(worknumber); 23 } Tabel 6.9: cipher metoden i Rotor.java forlæns, og et der chifrerer baglæns. Desuden skal man tage højde for, at alfabeterne hele tiden ændrer sig på grund af rotationen. linie Der erklæres en række variabler. Længden af alfabetet gemmes i length og heltallet worknumber sættes til index nummeret af den karakter, der arbejdes med i klartekstalfabetet. linie 09 Antallet af gange rotoren er roteret, opdateres og gemmes i worknumber. Længden af alfabetet lægges til og moduleres for at være sikker på, at værdien stadig er inden for alfabet arrayet. linie Hvis den boolske værdi cipherforward, som indikerer om, der skal chifreres forlæns eller baglæns, er sand sættes arbejdskarakteren, tempchar, til karakteren på den plads worknumber svarer til i 55

64 KAPITEL 6. KODEBESKRIVELSE det fremad rettede kryptoalfabet, hvorefter cipherforward sættes til falsk. Ellers sker det samme, blot med det bagud rettede kryptoalfabet, hvorefter cipherforward sættes til sand. linie Så findes tempchars plads i klartekstalfabetet og rotationen trækkes fra. linie 20 Igen lægges længden til, og der moduleres med længden for at sikre, at tallet befinder sig inden for alfabet arrayet. linie 22 Til sidst returneres den karakter, worknumber nu svarer til i klartekstalfabetet. I det kommende afsnit, vil der være eksempler på, hvordan GUI er programmeret. 6.3 GUI kodebeskrivelse Koden i GUI adskiller sig fra vores Enigma modul ved, at størstedelen af koden bruges til at specificere, hvor de forskellige objekter vises på brugerfladen. Designet af GUI kan læses i afsnit 5.2. Der findes forskellige layout metoder til at bestemme, hvordan objekterne placeres. Vi har valgt, at bruge to forskellige former for layout. På vores Enigma og Alfabet vindue bruger vi BorderLayout, og på de resterende vinduer bruger vi GridBag- Layout. I det følgende afsnit vil der blive gennemgået, hvordan disse layout metoder adskiller sig fra hinanden, og hvordan de anvendes. BorderLayout Når man anvender BorderLayout, skal man skrive koordinaterne og størrelsen på alle objekter, der skal vises i vinduet. Man har derfor en del frihed, da man selv kan bestemme den eksakte placering af objekterne. Problemet er dog, at det er besværligt, hvis man vil ændre på udseendet af GUI, så skal alle koordinaterne ændres, for at GUI stadig ser struktureret ud. Det følgende kodeeksempel viser, hvordan man tilføjer en label til vinduet, når man bruger BorderLayout. Eksemplet er taget fra filen GUIEnigma.java, som befinder sig i pakken gui, og kan ses på tabel label = new JLabel("Indikators:"); 02 label.setsize(60, 25); 03 label.setlocation(340, 0); 04 layeredpane.add(label); Tabel 6.10: Tilføje en label til BorderLayout 56

65 KAPITEL 6. KODEBESKRIVELSE linie 01 Lablen initialiseres med en tekst. linie 02 Størrelsen af denne label sættes. Størrelsen angives som (Brede, højde). linie 03 Placeringen af øverste venstre hjørne af denne label angives som et koordinatsæt. linie 04 Lablen tilføjes til vinduet. GridBagLayout Når man anvender GridBagLayout dannes der et grid, er ækvivalent med en tabel, hvor række og kolonne til objektets placering skal angives. Dette giver et udsende, der er meget firkantet. Fordelen er, at det er nemt, at tilføje nye objekter og samtidig bevare et struktureret udseende. Det følgende kodeeksempel viser, hvordan man tilføjer en label til vinduet, når man bruger GridBagLayout. Eksemplet er taget fra filen SimpleSettings.java, som befinder sig i pakken gui, og kan ses på tabel label = new JLabel("Enigma type: "); c.gridy = 0; c.gridx = 0; pane.add(label, c); Tabel 6.11: Tilføje en label til GridBagLayout linie 01 Lablen initialiseres med en tekst. linie X og Y koordinaterne til denne label angives, her er X værdien kolonnen og Y værdien er rækken, som lablen skal indsættes i. linie 04 Lablen tilføjes til vinduet. Vi har valgt at anvende GridBagLayout til simpel- og avanceretopsætning, fordi der passer det godt med et firkantet opbygning, hvor hoved og alfabet vinduet skal være lidt mere dynamisk i størrelsen af bl.a. tekstfelterne. Designet til simpel- og avanceretopsætning er gennemgået i afsnit Når man klikker på noget i GUI, så skal der ske en action. Det følgende stykke kode vil vise, hvordan man behandler en action i GUI. Koden er taget fra filen AvanceretSettings.java, som befinder sig i pakken gui, og kan ses på tabel 6.12 linie 01 Klassen implementerer ActionListener, og derfor skal metoden actionperformed være der. Denne funktion opfanger actions foretaget af brugeren. Denne action gemmes i variablen e. 57

66 KAPITEL 6. KODEBESKRIVELSE 01 public void actionperformed(actionevent e) { 02 if ("comboboxchanged".equals(e.getactioncommand())) { 03 JComboBox cb = (JComboBox) e.getsource(); 04 if ("reflector".equals(cb.getname())) { 05 if ("Brugerdefineret".equals(cb.getSelectedItem())) { 06 textreflector.enable(); 07 textreflector.setbackground(color.white); 08 textreflector.settext(""); 09 } else { 10 textreflector.settext(util.reflector[cb.getselectedindex()]); 11 textreflector.disable(); 12 textreflector.setbackground(disabled); 13 } 14 } snip... Tabel 6.12: Action i GUI linie 02 Undersøger om det er en combobox, der er blevet klikket på. Tilsvarende kan man se, om det er en anden type knap, der er trykket på. linie 04 Kontrollerer om det er comboboxen reflector, der er blevet trykket på af brugeren. linie Hvis der er valgt Brugerdefineret, nulstilles text feltet, og giver brugeren tilladelse til at skrive i feltet. linie Hvis der ikke er valgt Brugerdefineret, opdateres text feltet med den tilsvarende reflektor, valgt af brugeren i GUI. Text feltet bliver sat til disabled, så brugeren ikke har tilladelse til at skrive i feltet. I det kommende afsnit, vil der redegøres for et eksempel på, hvordan CLI er programmeret. 6.4 CLI kodebeskrivelse I dette afsnit vil med et kodeeksempel, redegøre for hvordan vi håndterer inputs fra brugeren, når det foregår gennem en konsol. Designet af CLI kan læses i afsnit 5.3. Følgende er taget fra filen EnigmaCli.java, som befinder sig i pakken cli. Koden er inde i main metoden, og args er det input programmet får fra computeren, koden kan ses på tabel Når CLI kommunikerer med brugeren, så er proceduren, at brugeren bliver stillet et spørgsmål, som skal 58

67 KAPITEL 6. KODEBESKRIVELSE 01 if (args.length == 0) { 02 System.out.println("Enigma Maskine lavet af E4-105"); 03 System.out.println("use -? for help"); 04 } else if (args[0].equals("-h") args[0].equals("--help") args[0].equals("-?")) { 05 helpoutput(); 06 } else if (args[0].equals("-v")) { 07 versioninfo(); 08 } else { 09 for(int i = 0;i < args.length;i++) { 10 if (args[i].equals("-f")) { 11 if (i+1 < args.length && args[i+1].charat(0)!= - ) { 12 i++; 13 if (!fileflag) { 14 strpath = args[i]; 15 fileflag = true; 16 } 17 } else { 18 System.out.println("Unexpected Argument, please use -f <file>"); 19 return; 20 } 21 } else if (args[i].equals("-i")) { 22 noinput = true; 23 } else if (args[i].charat(0) == - ) { 24 System.out.println("Unknown Argument" + args[i]); 25 } else { 26 if (i < args.length) { 27 strinput = strinput + args[i]; 28 } 29 } 30 } 31 } Tabel 6.13: Kommunikation med brugeren i CLI besvares. Inputtet bliver evalueret i forskellige if sætninger, hvorefter den korrekte handling udføres. linie Hvis brugeren ikke har indtastet noget, så skrives en velkomst til brugeren, samt hvordan man kan få hjælp til at anvende programmet. Denne if sætning vil blive initialiseret når programmet bliver eksekveret, hvis programmet ikke startes med et argument. linie Undersøger om brugeren har skrevet h, help eller? så køres hjælpe metoden, som viser vejledning til brugeren. linie Hvis brugeren har skrevet v så vises programmets ver- 59

68 KAPITEL 6. KODEBESKRIVELSE sion, ved at kalde versions metoden. linie De første if sætninger er ikke opfyldt, og programmet går nu igennem alle inputs en af gangen ved hjælp af en for-løkke. linie 10 Undersøger om brugeren anvender et f argument. linie Kontrollerer om argumentet efter f argumentet, er en sti til en XML fil og ikke endnu en kommando. Stien gemmes, og fileflag sættes til true, så der ikke kan importeres endnu en XML fil. linie Hvis brugeren har indtastet et ugyldigt argument, skrives den korrekte syntaks til brugeren. linie Undersøger om brugeren har valgt et tom argument. Den boolske værdi noinput sættes til sandt. linie Undersøger om der er invalide argumenter, og oplyser brugeren om dette. linie Hvis inputtet ikke er et argument, gemmes det i strengen strinput. 60

69 Kapitel 7 Testning I dette afsnit redegøres der for hvordan vi har testet Enigma modulet, den grafiske brugerflade og kommando brugerfladen. 7.1 Enigma test I dette afsnit vil der kort blive redegjort for hvorledes JUnit 1 er blevet brugt til. I gruppen blev der indbyrdes aftalt, at før der blev committet 2 kode, skulle denne kode bestå de tests, der var skrevet til den. På denne måde sikres det i nogen grad, at koden overholder de samme krav hele tiden. Før integrationstesten og systemtesten, blev programmet sat op således, at alle rotorerne ville roterer, efter nogle få chifreringer. Derved undgås lange tekststrenge, til validering af kodens korrekthed. Testning af systemniveauet foregik ved sammenligning af output med en fysisk Enigma maskine. Med systemniveau, menes det færdige program kørende på den designerede hardware. Udviklingen af testcases er sket efter principperne for fejl- og scenariobaseret testning, som er forklaret nærmere i afsnit 8.4. Herefter følger en beskrivelse af hvordan JUnit er blevet anvendt til test. Afsnittet er skrevet ud fra kilden [5]. Udvikleren medtager assertions 3 i koden, hvis disse assertions ikke returnerer sandt, kastes der en exceptions, som opfanges af Java. I så fald vil JUnit gøre udvikleren opmærksom på denne exception. Herefter er det op til udvikleren at tage sig af dette problem. 1 JUnit er forklaret nærmere i afsnit kommando i Cuncurrent Version System 3 metoder i Java, som kan sættes til at sammenholde et forventet svar givet af udvikleren, med outputtet af programmet 61

70 KAPITEL 7. TESTNING testconfigcase1 testconfigcase0 testconfigcase2 testcipher(component) testcontainssameletters testrandomizestring testgetextension testmakeextension testcipher(rotor) testatnotchandrotate testenigma testwritesetuptoxml testindexof testcharat testconstructor1 testlength testtostring testtochararray Tester om programmet er i stand til at indlæse opsætningen lavet af et type et alfabet og bygge Enigmaen korrekt og om nogle exceptions bliver kastet. Tester om programmet er i stand til at indlæse opsætningen lavet af et type nul alfabet og bygge Enigmaen korrekt og om nogle exceptions bliver kastet. Tester om programmet er i stand til at indlæse opsætningen lavet af et type to alfabet og bygge Enigmaen korrekt og om nogle exceptions bliver kastet. Tester Componentklassens cipher metode. Den undersøger om omponentklassen ciphrerer korrekt og at den rigtige exception bliver kastet under de rigtige omstændigheder. Tester om de tre mulige outputs produceres i de tre respektive tilfælde. Vi er ikke i stand til at teste om noget faktisk er tilfældigt. I stedet testes der for om der er de samme og lige mange bogstaver i inputstrengen og outputstrengen. Tester om det er muligt at få fat i ekstensionen på en XMLfil, på en fil med. i filnavnet og på en fil uden ekstension. Tester om det er muligt at ændre ekstensionen på en fil. Tester om rotoren ligesom Component klassens ciphermetode chifrerer korrekt. Tester om rotoren er i stand til at rotere korrekt og at detektere om den er ved notch eller ej. Tester om selve enigmaen er i stand til at konstruere sig selv, og chifrere to strenge korrekt. Tester om en opsætning kan indlæses fra en fil og skrives til en fil igen. Korrektheden af denne skal evalueres mauelt ved at sammenligne de to filer. Tester om indexof metoden virker som beskrevet på side 50. Tester om charat metoden virker som beskrevet på side 50. Tester om de rigtige exceptions bliver kastet hvis en karakter optræder mere end en gang i inputtet, eller hvis der er et ulige antal karakterer i inputtet. Tester om lengthmetoden returnerer længden af alfabetet. Tester at tostringmetoden laver en streng korrekt, og at der produceres nye strenge, som ikke er reference lig med hinanden, hver gang metoden kaldes. Tester at tochararraymetoden laver et array af karakterer korrekt, og at der produceres nye arrays, som ikke er reference lig med hinanden, hver gang metoden kaldes. Tabel 7.1: Testcases Tabel 7.1 indeholder alle vores testcases og en kort beskrivelse af deres funktioner. Alle fejl som blev fanget vha. JUnit, blev rettet. For at sikre, at alle 62

71 KAPITEL 7. TESTNING statements i Enigma modulet bliver testet, har vi udviklet kontrol flow diagrammer (se figur 7.1 og tabel 7.2), hvor kontrol flowet ikke er trivielt. Dette konstituerer i realiteten whitebox tests, se side 76. Figur 7.1: Kontrol Flow Diagram if (nplainalphabettype < 2) { if (nplainalphabettype == 1) { plainalphabet = new Alphabet(Data.alfabet); } else { plainalphabet = new Alphabet(Data.getAscii()); } } else { plainalphabet = new Alphabet(DataMiner.getPlainAlphabet()); } Tabel 7.2: Kontrolstruktur Det fremgår af tabel 7.2 og figur 7.1, at kontrolstrukturen danner tre forskellige stier gennem denne programdel. Derfor skal der også bruges tre tests til validering af denne. Derudover skal der bruges en test til at sikre, at den rigtige exception bliver kastet under de valide omstændigheder. Denne teknik har vi brugt til at sørge for at testen, af et program, er så komplet som mulig. Dette er gældende for både test, der bliver foretaget på unit- og integrationsniveau Unit tests Alle ikke private metoder, bliver testet. I hver testmetode sikres det, at outputtet er valid for grænseværdierne af inputsættet inden for grænserne, og invalid uden for inputsættet.derudover testes det, at de rigtige exceptions bliver kastet under de rigtige omstændigheder. For at undersøge om programmet behandler exceptions korrekt, sættes testen op så det er sikkert, at exceptionen bliver kastet. Derefter køres testen og det kontrolleres at outputtetn er valid. 63

72 KAPITEL 7. TESTNING Integrations tests En klasse kan godt fungere alene, men være ubrugelig for andre klasser. Den måde, vi har testet klasserne på er ved, at teste alle de metoder, som bruger andre klasser. Derved sikrer vi, at metoderne fungerer samme. 7.2 GUI test I afsnittet JUnit 8.4, blev der beskrevet, hvordan der kan laves automatiske tests af objekterne i koden. Det er ikke praktisk muligt at anvende JUnit til at teste grafiske brugerflade. Derfor er det nødvendigt manuelt at teste, om GUI stemmer overens med design, og manuelt at finde eventuelle fejl. GUI test kan deles op i tre faser. I de følgende afsnit vil disse tre faser blive forklaret yderligere, men først vises en kort introduktion til, hvad der blev testet for i de forskellige faser. Når knapper nævnes i dette afsnit, så dækker det også over menupunkter, comboboxe og værktøjslinie knapper. Første fase er under selve udviklingen af GUI. Vi tester for, om GUI kan skifte mellem de forskellige vinduer, og om alle knapperne i GUI kan anvendes. I anden fase bliver GUI implementeret med Enigma modulet. Der bliver testet om, de korrekte metoder bliver kaldt, og om det resulterer i det korrekte output. I tredje fase laves en fejltest, hvor man prøver at skrive forkerte inputs til programmet, for at undersøge hvordan det håndterer de forkerte inputs Første fase I denne fase undersøges der om programmet kan registrere hver gang, der bliver trykket på en knap i GUI. Måden vi har gjort det på, er ved at få programmet til at skrive navnet på den knap, der er trykket på, ud til konsollen. Dette vil sige, at hvis brugeren klikker på chifrer knappen, så bliver der skrevet Chifrer ud til konsollen. Vi har valgt at benytte denne metode, det er muligt systematisk at undersøge om programmet rent faktisk opfatter, at der bliver klikket på en knap. Vi har bestået første fase af testen, når alle knapper i GUI skriver knappens navn ud til konsollen Anden fase I anden fase, skal knapperne udføre de funktionaliteter, som er beskrevet i vores design af GUI på side 32. Vi udnytter, at det er muligt at tilgå alle knapperne, da fase et er bestået. I stedet for at skrive navnet på knappen ud til konsollen, så skrives den stump kode, som udfører den ønskede funktionalitet. Hver gang en funktionalitet er tilføjet, sikres det at den udfører den ønskede handling, ved test. Derefter laves et par Scenarie-baserede tests. 64

73 KAPITEL 7. TESTNING Scenarie-baseret test vil sige, at man laver forskellige scenarier som svarer til, de forløb brugeren gennemgår, når han bruger programmet. Vi vil nu beskrive et eksempel på et scenario: Først startes programmet op, og Enigma vinduet vises. Enigmaen skal sættes op, og en simpel opsætning skal anvendes. vi klikker på simpel opsætning i menubaren, eller knappen i værktøjslinien. Rotorerne sættes til 312, ringopsætningen sættes til 111, og indikatorne sættes til AAA. Steckerparene sættes som i eksemplet på side 7 og reflektor B vælges. Herefter klikkes på OK, og Enigma maskinen er nu klar til at chifrere. Vi vælger Enkelt tastetryk i menuen, for at indikatorne opdaterer hver gang, vi skriver et bogstav ind. Det er nu muligt både at kontrollere om outputtet er korekt, og om indikatoren står, som da eksemplet fra tideligere blev beskrevet. På figur 7.2 ses resultatet fra vores scenario test af chifreringen af HELLO E- NIGMA, og som det ses på figuren, får vi samme resultat, som det eksempel vi gennemgik på side 7. Figur 7.2: Eksempel på chifrering af HELLO ENIGMA med GUI Vi har tilsvarende lavet andre og mere avancerede scenarier, og når alle disse 65

74 KAPITEL 7. TESTNING scenarier giver det rigtige resultat, kan vi gå videre til tredje fase af testen Tredje fase Programmet er nu testet og det opfylder kravene om at den kan chifrere, som den rigtige Enigma gør det. Se evt. afsnit 3. I anden fase blev det undersøgt, om Enigma programmet opfører sig, som forventet, om den returnerer det rigtige output ved det givne input. Tredje fase i testen undersøger, hvordan vores program reagerer, hvis brugeren giver et forkert input. Når brugeren anvender programmet, så findes der to typer af fejl brugeren kan lave. Den ene type fejl kan ske, når brugeren skal indlæse eller gemme filer. Den anden type fejl kan ske, når brugeren indtaster en streng, i form af f.eks. en brugerdefineret rotor, reflektor, stecker eller alfabet. Indlæse og gemme filer Når brugeren indlæser eller gemmer en fil, kan der forekomme en række fejl: Der er angivet en forkert filtype. Der er ikke angivet nogen filtype. Hvis det er en XML fil, er det ikke sikkert at den opfylder vores XML standard som redegjort for i afsnit Vi har systematisk afprøvet de steder, brugeren kan indlæse eller gemme en fil, og testet for ovenstående fejlmuligheder. Formålet er at undersøge, om programmet går ned, returnerer en fejlmeddelelse til brugeren, og/eller retter fejlen selv. Indtastning af streng De steder brugeren kan indtaste en streng, kan han lave følgende indtastningsfejl: Tegn der ikke er repræsenteret i alfabetet. Alle tegn i alfabetet er ikke repræsenteret i en brugerdefineret reflektor eller rotor. Der er et ulige antal tegn i alfabetet eller steckeren. Dette samme tegn optræder flere gange i steckeren, reflektoren, notch, alfabetet eller en af rotorerne. Et tomt alfabet. 66

75 KAPITEL 7. TESTNING Vi har systematisk afprøvet de steder, brugeren kan indtaste strenge, og testet for ovenstående fejlmuligheder. Formålet er, at undersøge om programmet går ned, returnerer en fejlmeddelelse til brugeren og/eller retter fejlen selv. En ting vi har testet for, som ikke går ind under nogle af disse to typer af fejl, er når brugeren har skiftet over til enkelt tastetryk. Hvis enkelt tastetryk er slået til, og brugeren skriver hurtigere, end programmet kan nå at chifrere tegnet, vises en besked op til brugeren, om at programmet ikke kan følge med, og programmet anbefaler brugeren at slå enkelt tastetryk fra. Vi har fået programmet til at lave en fejl, hvis man taster så hurtigt, at man når at taste et bogstav mere, inden denne besked vises. Dette kan resultere i en arrayindexoutofboundsexception. Vi har vurderet, at vi ikke vil rette denne fejl, da det kun vil ske, hvis brugeren bevist prøver at få programmet til at gå ned. Det vil tage for lang tid at rette denne fejl, i forhold til hvad vi får ud af det. Når vi har testet alle opsætningsfejl og alle indtastningsfejl, og programmet ikke er gået ned, så er denne test fase bestået. Det er tilfredstillende når programmet ikke går ned, men i stedet skriver en besked til brugeren om, at han har lavet en fejl, og derfor skal rette den, før han kan gå videre med programmet. 7.3 CLI test Command Line Interface er en brugerflade, der som GUI skal bruge input fra brugeren, hvilket gør det svært at bruge automatiske tests. Se evt. afsnittet omkring JUnit 8.4. Derfor testes CLI på samme måde som GUI. Testen er delt op i tre faser. Første fase involver at teste om CLI fanger de sendte argumenter. Anden fase tester om den brugerinteraktive del virker. Tredje fase tester om, programmet har integreret Enigma modulet korrekt. Første fase - Argumenterne Denne fases formål er, at teste om programmet modtager og behandler argumenter korrekt. Metoden til at teste dette, var systematisk at kalde CLI med forskellige argumenter. Det indebar at undersøge, om der var taget højde for de fejl de forskellige kombinationer af argumenter producerede. Ukendte argumenter så som -g giver besked om, at det er et ukendt argument. Når alle testene er bestået kan næste fase påbegyndes. Anden fase - Interaktive metoder Næste fases formål er, at teste den brugerinteraktive del af programmet. Det betyder, at det primært er Input klassen der testes. Testen involverer to ting. Der testes for om det er muligt at indtaste invalid input og der testes for om valid input kan producere invalid output. Ved at indtaste 67

76 KAPITEL 7. TESTNING værdier ind i programmet, skal den brugerinteraktive del, lave en XML fil, som giver en korrekt XML konfigurationsfil som output.andre ting der også skal testes, er om programmet tager højde for at XML konfigurationsfilen, ikke nødvendigvis eksisterer eller er læsbar. For at teste om programmet accepterer forkert input, fodrers programmet systematisk med karakterer. Imens observeres programmet. Hvis det giver en fejlmeddelelse, må denne være på grund af en inputfejl, som herefter kan identificeres og behandles. Når testene er bestået, kan man gå videre til næste fase. Tredje fase - Enigma Modulet I tredje fase testes der om Enigma modulet kan bruges af CLI. Dette indebærer at teste om der opnås et korrekt output ved et korrekt input. Vi bruger eksemplet HELLOENIGMA, som vi gennemgår i afsnit 2.6, til at teste på to underfaser. I første underfase startes programmet uden argumenter, og derved startes den brugerinteraktive guide til konstruktion af en XML konfigurationsfil. En XMLfil med opsætningen fra eksemplet laves. Derefter skriver vi inputtet HELLOENIGMA og undersøger derefter, om outputtet er korrekt ifølge vores eksempel. I anden underfase startes programmet med argumenterne -f filen.xml HELLOENIGMA. Dette bør give samme output som første underfase. Når denne test giver et korrekt output, er vores test serie til CLI færdig. 7.4 Konklusion på testning Alle dele af koden har gennemgået en test, og de fejl der blev fundet, er blevet korrigeret. Ingen af fejlene var så store, at det krævede en omstrukturering af projektet, hvilket indikerer at designet og kommunikationen mellem udviklerne af programmet 4, har været god. Selvom programmet har bestået alle vores testcases, er dette dog ikke ensbetydende med, at koden er fejlfri. A test can show that there is an error in a program. However, it can never show that a program is error free! - Kristian Torp[6, p 2] Som det fremgår af citatet er vores program ikke nødvendigvis fejlfrit, men gennem testen har vi valideret at programmet lever op til kravspecifikationen. 4 udviklerne i dette tilfælde er projektgruppen 68

77 Kapitel 8 Evaluering af anvendte værktøjer Til udarbejdelsen af dette projekt har projektgruppen brugt nogle hjælpeværktøjer og modeller. Værktøjerne er udvalgt således, de har relevans i forhold til semestertemaet 1. Herunder vil der følge en liste over de brugte værktøjer og modeller, og en nærmere beskrivelse og evaluering af dem. De udvalgte værktøjer har alle en central rolle i vores projekt. Til evaluering af vores værktøjer har vi brugt en fremgangsmetode, der er nærmere beskrevet på bilag B, som er en metode, vi har udviklet ud fra kurset Basale softwareprocesser. Værktøjer og Modeller Planlægning Microsoft Project Vandfaldsmodellen Versionsstyring VS(Concurrent Version System) Programmering Eclipse Test metoder JUnit 1 Et større program 69

78 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER 8.1 Planlægning Når der laves et større projekt, så er planlægning essentiel for et struktureret projektforløb. Der er flere former for planlægning, det kan være en plan over hele projektforløbet, men samtidig kan der også være planer for dele af projektet, som f.eks. programmeringsfasen. Vi vil først evaluere det værktøj, vi har anvendt til planlægning af projektforløbet og derefter evaluere vores programmeringsmodel. Værktøjets navn Microsoft Project Værktøjsbeskrivelse MS Project 2 er en udvidelse til Microsoft Office pakken, men virker som et selvstændigt program. MS Project er et omfattende projekt værktøj, hvor det er muligt at administrere projekt planlægning og -styring. Der er mange funktioner i MS Project, men gruppen har ikke anvendt alle funktionaliteter. Det gruppen har brugt i MS Project er følgende: Opgave menu, Gantt kort og ressource inddeling. Det er baseret på disse erfarringer at værktøjet vil blive evalueret. Evaluering af værktøjet MS Project indeholder gode hjælpefeatures, der gør det let anvendeligt. MS Project dækker fuldt ud vores behov som et planlægningsværktøj. En af de features vi har gode erfaringer med, er det visuelle Gantt kort, der giver et overblik over hele projektforløbet. Til gengæld kræver MS Project, at det bliver revideret ofte, for at tilpasse evt. ændringer i projektforløbet. Det er kompliceret at ændre rækkefølgen af opgaverne, samt at linke Gantt kort bokse sammen, således at det passer med arbejdstidspunkter og datoer. MS Project giver en god repræsentation af projektet, deadlines og skaber derudover et godt overblik over hvor langt gruppen er i projektforløbet. Gruppen reviderede MS Project mindst en gang om ugen, det var nødvendigt for at sikre, at planen hele tiden var opdateret, også med hensyn til fravær, som f.eks. sygdom. Planen hjalp os til at indse, at det ikke var muligt at nå, at udvikle en tiltænkt udvidelse til Enigma implementeringen. Da gruppen opdagede dette problem i tide, kunne gruppen planlægge sig ud af problemet, og her var MS Project en stor hjælp. Grunden til at gruppen har valgt, at bruge MS Project er, at gruppen alligevel brugte programmet i forbindelse med et kursus. 2 Microsoft Project 70

79 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER Fordele Gantt kort Let anvendeligt Ulemper Uoverskuelige funktioner Svært at revidere i planlægningen Konklusion MS Project er en hjælp til projektstyring og -planlægning. De basale funktioner er lette at tilgå, men skal der laves mere avanceret projektstyring, bliver det uoverskueligt. En fordel ved MS Project er, at man har en overskuelig milepælsplan for hele projektperioden. Som et alternativt til MS Project, kunne gruppen have brugt en almindelig kalender. Fordelen ved at have sin planlægning i digital form er, at den er nemmere at revidere. Det kan dog være en fordel, at udskrive planen og hænge den op i grupperummet, så gruppen dagligt kan følge med i udviklingen. Vores plan kan ses på bilag C. Værktøjets navn Vandfaldsmodellen Værktøjsbeskrivelse Vandfaldsmodellen er en software udviklingsmodel, der bruges til at styre programmeringsforløbet. Vandfaldsmodellen er delt op i 5 faser, se en nærmere beskrivelse i afsnit 4.1. Evaluering af værktøjet Vandfaldsmodellen er beregnet til brug i projekter, hvor flere mennesker er sammen om at udvikle et større software projekt. For at kunne bruge vandfaldsmodellen kræver det, at gruppen forsøger at planlægge deres projekt ud fra vandfaldsmodellen. Vandfaldsmodellen dækker vores behov for en software udviklingsmodel. I princippet kan vandfaldsmodellen bruges til alle former for software udvikling, det er dog en tidskrævende model. Fordelene vi fik ved at anvende denne model var at vi nøje kunne følge med i projektforløbet. Til gengæld er det lidt problematisk i begyndelsen, at skulle tilpasse projektet til vandfaldsmodellen. Udbyttet af dette værktøj er, at det overskueliggør software udviklingsprocessen. Vandfaldsmodellen passede godt til vores projekt, fordi Enigmaens krav er fuldt ud definerede. Gruppen 71

80 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER har ikke helt holdt sig til vandfaldsmodellen da, gruppen udover de formelle krav har lavet nogle ekstra features til Enigma implementeringen. Gruppen implementerede de ekstra features under programudviklingsfasen, uden at programplanlægningen blev ændret. Det kunne ikke betale sig rent tidsmæssigt at starte vandfaldsmodellen helt forfra, for at tilføje de nye features. Der blev fulgt op på manglerne efter programmeringsfasen var overstået. fordele Overskueliggører software udviklingsprocessen God model hvis kravene er faste ulemper Projektet skal tilpasse vandfaldsmodellen for at få fuldt udbytte af den Det er tidskrævende at tilføje nye features, som ikke allerede er tiltænkt i designet Konklusion Vandfaldsmodellen har hjulpet gruppen til bedre at kunne overskue software udviklingsprocessen, samt tvunget gruppen til at tage diskussioner af forskellige aspekter om programmet op. Alternative modeller kunne have været anvendt, men i kraft af den fuldt ud definerede kravspecifikation valgte vi Vandfaldsmodellen. 8.2 Versionsstyring I et projektudviklings forløb er distribution af projektets materiale af essentiel betydning for kvalitet af det endelige produkt. Har gruppens medlemmer ikke alt materialet, eller er materialet ikke up-to-date, giver dette komplikationer. Komplikationer som i sidste ende kan medføre at deadlinen ikke kan overholdes. For at imødekomme dette problem har gruppen valgt at anvende CVS. Værktøjs navn: CVS(Concurrent Version System) Værktøjsbeskrivelse: CVS giver brugerne mulighed for at holde styr på og distribuerer filer, der hører til projektet, således alle medlemmer af gruppen kan hente den nyeste udgave. CVS oprettes på et hjemmebibliotek, som alle medlemmer af 72

81 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER projektgruppen har adgang til. Herfra kan brugerne individuelt hente filerne ned på deres private computer, redigere i disse, for derefter at uploade dem til hjemmebiblioteket igen. Den gamle version af filen bliver erstattet med den nye, på denne måde har alle medlemmer af gruppen adgang til den nye fil. Herudover har CVS også nogle andre features, programmet gemmer alle versioner af filerne, så det er muligt at hente en tidligere version af filen frem. Derudover laves en log, hvorfra det er muligt at se, hvem der har ændret hvad mellem de forskellige versioner af filerne. CVS giver herudover, mulighed for at se hvilke brugere der arbejder med hvilke filer. Evaluering af værktøjet: Det er nemt at anvende CVS, da der kun er nogle få kommandoer, man skal kunne for at anvende programmet. Ved anvendelse af CVS har gruppen sparet megen tid, dels i kraft af man kan se hvilke filer, de enkelte gruppemedlemmer arbejder med, således vi kunne redigere i rapporten uden at have aftalt forud. Vi har brugt CVS til både tekst dokumenter og kildekode, dog er de placeret i forskellige biblioteker for at holde dem adskilt. Gruppen fandt dog et problem, som har skabt nogen problemer. Når en bruger redigerer i et dokument er det ikke muligt at låse denne, således andre ikke kan redigere i den 3. Det er kun muligt vise at filen redigeres, hvis et andet medlem ikke undersøger for dette, før vedkommende begynder at ændre i filen, kan der opstå problemer når filen skal uploades. Vi har anvendt CVS til distribution af alle filer, der havde med rapporten at gøre. Når filerne var hentet ned på det private medie, kunne vi benytte den editor, vi følte os bedst tilpas med til redigering, for derefter at oploade filen til hjemme biblioteket. Fordele: Alle har nyeste version af filerne. Mulighed for at se hvem, der arbejder med hvilke filer. Mulighed for at hente gamle versioner af filerne. Mulighed for at læse en log over ændringerne af filerne. Ulemper: Ingen mulighed for at låse filer som bliver redigeret. 3 Vi har ikke kunne finde sådan en feature i CVS manualen 73

82 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER Konklusion: CVS har været til stor hjælp i vores projekt, som fildistribution. Det er nemt og hurtigt at anvende, og giver et godt overblik over hvem, der arbejder med hvad. Der er som sagt problemet med, at flere personer kan redigere i den samme fil på samme tid, men dette problem ville have været større, hvis vi ikke havde anvendt CVS. Det er altid en fordel at have backup af gamle filer således, hvis nogen ved et uheld sletter et dokument, kan dette problem hurtigt og nemt imødegås. 8.3 Programmering I vores kravspecifikation skrev vi, at vores program skal være skrevet i Java. En Enigma maskine er velegnet til at blive programmeret i et objektorienteret sprog, da de enkelte objekter kan simulere de fysiske bestanddele i den virkelige Enigma. Som vi tidligere har nævnt, så var det et krav til projektet, at vi programmerede i et objektorienteret sprog. Til at skrive vores kildekode har vi valgt at bruge udviklingsværktøjet Eclipse, som nu vil blive evalueret. Værktøjets navn: Eclipse Værktøjsbeskrivelse: Eclipse er et udviklingsværktøj til at skrive Java i. Eclipse er en avanceret editor, der er optimeret til Java. Den kender Java syntaksen og opdager de fejl brugeren måtte lave, og foreslår hvordan fejlen kan rettes. Eclipse har indbygget auto completion, hvilket hjælper mod tastefejl, og hvis der f.eks. er nogle metodenavne, man ikke kan huske eksakt. Man kan kompilere koden direkte i Eclipse, og Eclipse kan lave jar 4 filer. Det er også muligt at kompilere ens JavaDoc med Eclipse. Evaluering af værktøjet: Vi har anvendt Eclipse til udviklingen af hele vores kode. Eclipse er forholdsvist nemt at gå til, da de mest grundlæggende funktionaliteter, som at oprette et projekt, tilføje pakker, tilføje filer osv., er let tilgængelige. De mere avancerede funktionaliteter i Eclipse går der lidt tid, inden man kan anvende, men indlæringskurven er jævn. Det tager dog lang tid at starte Eclipse op. Hvis man ændrer i nogle filer der er tilføjet til Eclipse, med anvendelse af en anden editor, kan Eclipse godt finde på at skrive fejlmeddelser. Dette 4 En jar fil er en eksekverbar javafil. 74

83 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER er specielt et problem, hvis det er billeder, tekst filer, XML filer osv. man redigerer med en anden editor. Efter vi har skrevet koden i Eclipse, er koden blevet uploaded til CVS, så de andre gruppe medlemmer kan tilgå koden. Eclipse har hjulpet os en del, med specielt Auto completion, da det så ikke er nødvendigt at slå op i dokumentationen for at finde en metode, man ikke lige kan huske navnet på. Det er nemt at kompilere med, hvilket gør, at det er nemt og hurtigt at teste programmet for fejl. Fordele: Auto completion Syntaks fremhævning Nem at kompilere med Nemt at omdøbe pakker og klasser Fejlkorrektur Ulemper: Lange indlæsningstider Har problemer ved anvendelse af andre redigerings værktøjer Konklusion: Det har været nemt at anvende Eclipse, og det har været en fordel, at vi alle har brugt Eclipse, da f.eks. Emacs laver en lidt anderledes formatering af koden. Vi er vant til at anvende Emacs til at udvikling af kode i, men Eclipse har været bedre, da det er specialiseret til java. Emacs er en mere generel editor. 8.4 Test metoder Vores program er blevet testet med testcases, som er udviklet ved hjælp af JUnit frameworket. Testcasene blev udviklet med metodikken, bag fejlbaseret testning og scenario-baseret testning, for øje, hvor reglerne for Blackog Whitebox testning i højerere grad optræder som krav. Dette kapitel indledes med en redegørelse af generelle testmetoder, og til sidst evalueres JUnit som værktøj til udførelse af tests. 75

84 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER Black- og White Box Black- og White Box testning er blandt de mest anvendte test metoder indenfor programmering. Disse tests skal ikke betragtes som to konkurrerende test metoder, men derimod som to metoder som fuldender hinanden. Black Box Formålet med Black Box er at undersøge om programmet lever op til designet, og kravspecifikationen. Dette gøres ved at kalde metoder med forskellige input, outputtet sammenholdes herefter med det forventede output, som blev beskrevet i designet og i kravspecifikationen. Formålet med denne form for testning er at undersøge for 5 : Forkerte eller manglende metoder. Interface fejl. Fejl i datastrukturer. Initialisering og terminerings problemer. Black Box anvendes både under og efter kode udviklingen, idet programmøren har mulighed for, at teste en metode lige efter den er blevet udviklet. Denne test kan udføres på alle niveauer af kode udviklingsstadiet, desværre er denne test ikke fuldkommen, der testes f.eks. ikke for om alle dele af programmet bliver eksekveret. White Box White Box testen fokuserer på korrektheden ved koden, til forskel fra Black Box, kan denne test ikke udføres uden kildekoden. I denne test undersøges alle metoderne for om alle linier, bliver eksekveret, derudover evalueres alle stier under logiske udtryk, får både true og false siden. Derudover undersøges loops i og omkring deres grænser. Opsummeret er formålene for denne test at undersøge 6 : Om alle linier i koden kan blive eksekveret. Alle logiske udtryk. Loops i og omkring deres grænser. Kodens validitet. Til forskel fra Black Box testen er denne test kun mulig på unit-niveau, idet det er her man arbejder med de enkelte metoder, uden bekymring vedrørende deres afhængighed af andre metoder. 5 Følgende punkter er citeret fra [3, p. 486] 6 Følgende punkter er citeret fra [3, p. 471] 76

85 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER Fejl-baseret testning Formålet med fejl-baseret testning er udviklingen af testcases, hvor der lægges vægt på scenarier, hvor der er sandsynlighed for, at programmet bryder sammen. Sandsynligheden for et nedbrud er størst i grænserne, derfor vil testcasene undersøge hvorledes programmet reagerer, når det får input, der ligger udenfor, på og lige indenfor grænserne. En svaghed ved denne testning er, at det er op til testcase udvikleren at bedømme, hvad der er et sandsynligt fejl-scenario, dvs. hvis udvikleren undervurderer et scenario, kan dette give problemer efter software udgivelsen. Scenario-baseret testning Scenario-baseret testning tager i modsætning til Fejl-baseret testning udgangspunkt i de opstillede krav, og tester om disse er overholdt. Dette kan f.eks. ske ved at tage udgangspunkt i eksempler fra kunden, således at systemet testes gennem testcases, der simulerer en normal brugers anvendelse af systemet. Scenario-baseret testning gør det nemmere at validere programmet. Da mangler, fejl eller systemet ikke lever op til kundernes forventning, vil fremstå tydeligt i testen. Værktøjets navn: JUnit Værktøjsbeskrivelse: JUnit testning frameworket er et simpelt, men effektivt test værktøj, der følger med de fleste Java udviklings værktøjer. I sin enkelthed er JUnit en lille testcase, som eksekverer metoder i kildekoden, og sammenholder outputtet, med det forventede output, givet af programmøren. En af de største fordele ved anvendelse af JUnit er, at testcasen er uafhængig af kildekoden. Derfor kan den samme testcase anvendes til validering af samme dele af koden gentagne gange. I længden vil udvikleren spare tid, og små fejl i programmet, som ellers nemt vil kunne overses, kan med JUnit nemt opdages. Vores brug af værktøjet: Vi har brugt JUnit til at teste vores objekter og metoder i vores Enigma modul. Vi er blevet introdusseret til JUnit ved en forelæsning i OOP, det har derfor været nemt at gå til. Det er nemt at designe og programmere ens testcases, men det tager dog lidt tid at udvikle dem. Genbrugbarheden ved testcases har været til stor fordel, da vi har ændret i koden for at optimere koden og hurtigt har kunne validere den. Det har været en stor fordel for os, at JUnit er integreret i Eclipse, så vi ikke behøver at skifte 77

86 KAPITEL 8. EVALUERING AF ANVENDTE VÆRKTØJER udviklingsværktøj, når vi skal teste vores program. Det er desværre ikke muligt, at anvende JUnit til GUI test, så det har været nødvendigt at teste GUI manuelt. Fordele: Automatisk test. Ændring af koden påvirker ikke testcases. Ulemper: Tager tid at skrive testcases. Konklusion: JUnit hjælper os til at kontrollere validiteten af koden. Det tager dog tid at udvikle testcases, men dette opvejes, ved den tid man sparer på at teste. 78

87 Kapitel 9 Konklusion Formålet med denne projektperiode er at udvikle et større program. Vi fik til opgave at udvikle et Enigma simulatorprogram, med samme funktionalitet som den fysiske Enigma maskine. For at løse denne opgave var det nødvendig at forstå Enigma maskinen. Enigma maskinen er beskrevet i afsnit 2, og beskrivelse er blevet brugt som udgangspunkt for den kravspecifikation, der er beskrevet i afsnit 3. I stedet for blot at reproducere en fysisk Enigma, har vi tilføjet en række features, som er beskrevet i afsnit 5.4. En af de mere betydningsfulde udvidelser er baseret på XML teknologien. Med denne udvidelse tilføjer vi persistens til Enigmaen. Implementeringen af kode til at læse XML filer er en kompliceret proces, men at lære andre at anvende denne kan være en endnu kompliceret proces. Derfor udviklede vi en grafisk brugerflade og en kommando brugerflade, som gør at brugeren ikke behøver forstå XML. Kommando brugerfladen giver dog ikke adgang til at benytte de udvidede features, vi har tilføjet til den oprindelige Enigma maskine. Implementeringen af GUI blev nøje sammenholdt med kravene, da det er GUI, som fungerer som programmets ansigt udadtil, og derfor er den af essentiel betydning. Både den grafiske brugerflade og kommando brugerfladen er beskrevet i afsnit 5.2 og 5.3. Koden er testet ved hjælp af JUnit testcases, der kan udføres automatisk. Chifreringen er valideret gennem en sammenligning af output mellem det uviklede program og en ægte Enigma maskine. Den grafiske brugerflade og kommando brugerfladen er blevet testet manuelt gennem anvendelse. Vi kan ikke være sikre på, at koden er fejlfri, men i kraft af at den har bestået testene, er den klar til udgivelse. Testmetoderne er beskrevet i afsnit 7. Vores Enigma program kan anvendes af alle, der ønsker at chifrere beskeder. Hvis der er andre udviklere, der ønsker at udvikle programmer, som skal 79

88 KAPITEL 9. KONKLUSION indeholde Enigma moduler, kan vores kode anvendes. Vores Enigma kan bl.a. anvendes i en klient eller et chatprogram, hvor man ønsker at chifrere den tekst, der sendes mellem brugerne. Koden og rapporten er på den vedlagte cd, sammen med to eksekverbare jar filer. Det har været svært på forhånd at overskue hele projektforløbet og følge de oprindelige planer, men vi har formået at følge op på vores planer, revidere planerne og komme tilbage på sporet. Resultatet af dette projekt er et stabilt og sikkert program, som er nemt at gå til. Desuden har vi formået at anvende mange af de basale softwareprocesser og programmeringsprincipper, som vi er blevet undervist i på semestret. Programmet lever op til samtlige krav stillet til det, samtidig giver det brugeren mulighed for anvendelse af udvidede features. Det kan dog ikke anbefales at benytte Enigma programmet til chifrering af følsomme oplysninger, idet chifreringen nemt kan brydes af nutidens computere. 80

89 Litteratur [1] Andy Carlson. Enigma Applet. enigma.html, Online: 10/ [2] Martin Oberzalek. About the bomb Online: 23/ [3] Rogers S. Pressman. Software Engineering: A practitioner s approach. McGraw-Hill, [4] Tony Sale. The Enigma cipher machine Online: 20/ [5] Kristian Torp. Object-Oriented Programming forlæsning vedrørende Software Test Online: 26/ [6] Kristian Torp. Object-Oriented Programming: Software Test. torp/teaching/e04/oop/handouts/software test.pdf, Online: 26/

90 Bilag A Kilde Kritik I dette kapitel beskrives de anvendte kilder, hvor vi vil reflektere over deres validitet. Enigma Applet Denne side anvender kilder, som er højest anset i Enigma sammenhæng. Skaberen har samlet nyttige informationer fra disse kilder, og gjort dem nemt tilgængelig og forståelig. Vi ser ingen grund til at have mistro til denne kilde. Kilden var desuden angivet på projektforslaget. About the bomb Kildens rettighedsindehaver er begge fra respektive universiteter. Derfor ser vi ingen grund til at have mistro til denne kilde. Software Engineering: A practitioners approach Denne bog blev anbefalet af vores vejleder, derudover bliver denne bog også anvendt af dataloger på Aalborg universitet. Derfor kan validiteten af denne kilde ikke bestrides. The Enigma cipher machine Denne side er skabt af en konservator fra Bletchley Park Museum. Bletchley Park var hovedkvarter for kodebryderne under anden verdenskrig. Derfor betragter vi denne kilde som troværdig. 82

91 BILAG A. KILDE KRITIK Object-Oriented Programming: Software Test Denne kilde er slides skrevet af Kristian Torp, som er er fastansat af Aalborg universitet som fordragsholder af kurset objekt-orienteret programmering. Vi betragter denne kilde som troværdig. Object-Oriented Programming forelæsning vedr. software Test Denne kilde er en videooptagelse af et foredrag i kurset objekt-orienteret programmering. Foredraget bliver holdt af Kristian Torp, der er fast ansat af Aalborg universitet. Vi betragter denne kilde som troværdig. 83

92 Bilag B Værktøjs evaluering Alle de værktøjer vi har brugt gennem hele projektforløbet skal evalueres. Nedenfor er der lavet en lille guide til hvad sådan en evaluering skal indeholde. Værktøjsnavn: Værktøjsbeskrivelse: Kort beskrivelse af værktøjets egenskaber. Skal også omfatte hvilke dele af værktøjet der er under evaluering. (kort sagt hvad er det for et værktøj) Evaluering af værktøjet: I hvilke situationer er det smart at bruge værktøjet? Hvor let er det at tage værktøjet i brug? Dækker funktionalitet jeres behov? Er der oplagte begrænsninger i værktøjet? Hvad virkede godt/skidt i jeres situation? Hvilket udbytte har der været ved at anvende værktøjet? Er værktøjet integreret med de andre værktøjer? Fordele: Ulemper: Konklusion: Var værktøjet så en hjælp eller tidsspilde, og findes der evt. et bedre alternativt til værktøjet 84

93 ID Task Name 1 Baggrundsviden om enigma 2 Vidensdeling og udarbejdelse af dagsorden til møde 3 møde med vejleder og genplanlægning 4 bearbejdelse af viden 5 Udarbejdelse af indholdsfortegnelse og send til vejleder 6 Valg af udviklingsmodel og argumenter for denne 7 Lave projekt og kode retningslinjer 8 Genplanlægning ud fra valg af udviklingsmodel 9 udveksling af løsningsforslag 10 diskusion og valg af løsning 11 Design 12 Ferie 13 afslutning af design og genplanlægning 14 Kode til Review 15 kode review 16 Opsamling af kode review 17 Kode Enigma 18 Informations indsamlig om test 19 Design af GUI 20 Genplanlægning 21 Teste Enigma 22 Kode GUI 23 Test GUI 24 Genplanlægning og evt opsamling på kode 25 Command line interface design 26 Command line interface kodning 27 Command line interface guide 28 GUI design beskrivelse 29 kodebeskrivelse 30 Rapport opsamling 31 Evaluering og konklusion 32 konklusion og rettelser ep '04 13 Sep '04 20 Sep '04 T W T F S S M T W T F S S M T W T Henrik,Jeppe,Tharani,RasmusTJ,Rasmus Henrik,Jeppe,Tharani,RasmusTJ,R Henrik,Jeppe,Tharani,Rasmus Henrik,Jeppe,Tharani, Henrik,Je Task Project Summary Project: projektplanlægning Date: Fri 17/12/04 Split Progress Milestone Summary External Tasks External Milestone Deadline Page 1

94 27 Sep '04 04 Oct '04 11 Oct '04 18 Oct '04 25 F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M DC,Adam asmusdc,adam TJ,RasmusDC,Adam RasmusTJ,RasmusDC,Adam ppe,tharani,rasmustj,rasmusdc,adam Henrik,Jeppe Tharani,RasmusTJ,RasmusDC,Adam Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Henrik,Jeppe,Tharani,RasmusTJ,Rasm Henrik,Jeppe,Tharani,Ras Henrik,Je Project: projektplanlægning Date: Fri 17/12/04 Task Split Progress Milestone Summary Project Summary External Tasks External Milestone Deadline Page 2

95 ct '04 01 Nov '04 08 Nov '04 15 Nov '04 22 Nov '04 T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F usdc,adam ustj,rasmusdc,adam pe,tharani,rasmustj,rasmusdc,adam Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Jeppe,RasmusDC Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Henrik,RasmusTJ,Adam,Tharani Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Jeppe,RasmusDC Henrik,Tharani,RasmusTJ,Adam RasmusTJ,Adam Henrik,Jepp Ras Project: projektplanlægning Date: Fri 17/12/04 Task Split Progress Milestone Summary Project Summary External Tasks External Milestone Deadline Page 3

96 29 Nov '04 06 Dec '04 13 Dec '04 20 Dec '04 27 Dec ' S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T e,tharani,rasmustj,rasmusdc,adam musdc RasmusDC RasmusDC RasmusTJ,Adam Henrik,Jeppe Henrik,Jeppe,Tharani,RasmusTJ,RasmusDC,Adam Henrik,Jeppe,Tharani,RasmusTJ,RasmusD Project: projektplanlægning Date: Fri 17/12/04 Task Split Progress Milestone Summary Project Summary External Tasks External Milestone Deadline Page 4