Udvikling af IT-system for Swarco Technology

Transkript

1 Udvikling af IT-system for Swarco Technology Udvikling af software til overvågning af netværksforbindelser mellem trafikreguleringsenheder Projektvejleder fra Syddansk Universitet Palle Hermansen Teknisk vejleder fra Swarco Technology Peter Tobias Gønge Nielsen - tn@swtech.dk Projektperiode 1. februar 1. juni Udarbejdet af projektgruppen Alexey Bessonov alexey@bessonov.dk Frantz Furrer frantz@furrer.dk Jakob Witte Larsen jakobwitte@gmail.com Synopsis Denne rapport beskriver udviklingen af et system for Swarco Technology til overvågning af netværksforbindelsers status i et trafikreguleringsnetværk. Det er vist gennem anvendelsen af teknologier inden for datakommunikation og softwarekonstruktion, at det er muligt at detektere hvorvidt netværksforbindelser er tilsluttede eller afbrudte i et trafikreguleringsnetværk, samt fremvise denne status for en operatør som derved kan sikre at den opståede fejl bliver udbedret hurtigst muligt. Derved kan det samtidig afgøres hvem der har erstatningsvaret for det ødelagte netværkskabel. Under udviklingsperioden er der blevet anvendt Unified Process og SCRUM til strukturering og styring af projektet. Implementeringen af systemet er blevet foretaget i henholdsvis C++, Java og JavaScript.

2

3 Forord Da projektgruppen ønskede at samarbejde med en virksomhed under bachelorprojektet kontaktede vi Swarco Technology, da vi havde erfaret at de beskæftiger sig med komplekse datateknologiske problemstillinger indenfor elektronik- og softwareudvikling i en samfundsmæssig sammenhæng. Det så gruppen som en unik mulighed for at udvikle sine kompetencer indenfor det datateknologiske område både på det teoretiske og praktiske plan, og på samme tid få prøvet sine kompetencer opnået under bacheloruddannelsen af i en virksomhed. Der er under projektperioden blevet lagt meget tid i projektet fra projektgruppens side, for at kunne opnå et tilfredsstillende resultat. Det har været kilde til stor motivation og inspiration af få muligheden for at samarbejde med en virksomhed om at udvikle en softwareløsning som skal tages i brug i den virkelige verden Dette har ligeledes haft betydning for at det var været muligt at udvikle et system af den opnåede kompleksitet. Der skal derfor lyde en stor tak til teknisk vejleder Peter Tobias Gønge Nielsen og til Swarco Technology, for det gode samarbejde under projektperioden. Målgruppen for bachelorrapporten og de dertilhørende projektjournaler og projektmateriale er ud over projektvejleder og censor derfor også Swarco Technology, som skal anvende den udarbejde dokumentation når systemet skal videreudvikles og tages i drift. Derudover er målgruppen personer med interesse indenfor det datateknologiske område. Bachelorprojekt udarbejdet for Swarco Technology forår Alexey Bessonov Frantz Furrer Jakob Witte Larsen Om Swarco Technology Swarco er en international koncern som har specialiseret sig i udvikling af smarte løsninger indenfor trafik og infrastruktur og er en af de ledende aktører i markedet for intelligente transportsystemer. Løsningerne benyttes i dag indenfor vej, jernbane og og parkeringsanlæg over hele verden, og er baseret på et bredt spektrum af produkter, systemer og tjenester. Som en del af Swarco-koncernen befinder Swarco Technology sig i Odense. De står for udviklingen og markedsføringen af trafik- og kommunikationsudstyr til trafikstyringssystemer. Tusindvis af Swarco Technology's systemer og produkter er blevet installeret og er nu i brug i mange lande i hele verden. Swarco Technology har en lille udviklingsafdeling bestående af ca. 5 softwareudviklere, som primært udvikler på systemer til trafikregulering. Side 3

4 Læsevejledning Rapporten forudsætter grundlæggende kendskab indenfor datakommunikation, softwareudvikling, softwarekonstruktion samt operativsystemer, hvis læseren ønsker at få det fulde udbytte af rapporten. Der vil dog gennem rapporten være henvisninger til uddybende litteratur hvor gruppen har vurderet det er nødvendigt. Hvert område af systemet behandles i en særskilt sektion og det er i en vis udstrækning muligt, at læse sektionerne uafhængigt af hinanden, men det anbefales af læse rapporten fra start til slut. Rapporten er derfor delt op i fem sektioner henholdsvis en prolog som danner grundlag for projektet, en sektion for hver af de tre hovedområder systemet er inddelt i, samt en epilog der konkluderer og perspektiverer på det opnåede resultat. De tre hovedområder er opbygget så de starter med en indledning som beskriver indholdet og fokus i sektionen samt den metode der er blevet anvendt, så læseren altid har overblik over hvad formålet med den enkelte sektioner er. De fleste sektioner har herefter et analyseafsnit der introducerer problemstillingerne og mulige løsningsforslag. Herefter et design-, implementerings og et testafsnit som beskriver hvordan den valgte løsningen er designet, implementeret og testet. Afslutningsvis i hver sektion forefindes en konklusion der beskriver det opnåede resultat, samt mulige tilføjelser til den enkelte del. Der medfølger en Cd til rapporten som indeholder følgende: - Dokumentation for gruppens arbejdsproces - Projektjournaler - Projektgrundlag - Rapporten - Referater fra vejledermøder - Kildekode - UML-diagrammer - Anvendte programmer - Anvendte datablade - Tidsplaner og backlogs Cd'en starter automatisk i et browservindue, hvor det er muligt at navigere rundt på en overskuelig side. Følgende projektjournaler og dokumenter forefindes på Cd en. Dokumentnavn Dokumentet indeholder Antal sider Projektgrundlag v1.4 Indeholder projektbeskrivelse, procesmodel, støttediscipliner og overordnet plan for projektet. 10 Inceptionsdokument v1.3 Indeholder en oversigt over systemet, en kravmodel, en indledende risikoanalyse, en testspecifikation samt mockups for brugergrænsefladen. 17 Inspektionsreview v1.0 Indeholder analysemateriale som er blevet review i samarbejde med Swarco Teknology. 7 Krav- og Den udarbejdede kravmodel, brugsmønstermodel og brugsmønsterdokument v1.3 brugsmønsterbeskrivelser for hele systemet. 20 Udvidet risikoanalyse v1.2 Risikoanalyse for hele systemet. 1 Analyseklassediagram og -sekvensdiagrammer v1.0 Indeholder analyseklassediagram og analysesekvensdiagrammer samt mockups. 13 Designklassediagram og -sekvensdiagrammer v1.0 Indeholder designklassediagram og designsekvensdiagrammer. Test af TNSSR v1.0 Indeholder testbeskrivelse og testresultater for test på TNSSR TNSS-Server API dokumentation v1.1 Dokumentationen for TNSSS API'et. Accepttestdokument v1.1 Godkendt test af hele systemet. I dokumentet beskrives det hvordan enkelte krav skal testes Tabel 0.1: Oversigt over projektjournaler og deres indhold Kildekoden som ses herunder forefindes på den medfølgende Cd. Kildekode Sprog TNSSR C++ 32 TNSSS Java 60 TNSSW serverdel Java 27 TNSSW klientdel JavaScript 36 Tabel 0.2: Oversigt over kildekoden og deres udviklings sprog. Side 4 Antal sider

5 Indholdsfortegnelse 1 Indledning Projektbeskrivelse Problemanalyse Problemformulering Mål og forventede resultater Procesmodel Tidsplan Kvalitetskontrol af software Milepælsplan Indledende analyse af systemet Oversigt over system Brugsmønstermodel Kravmodel Risikoanalyse...18 TNSSR Indledning til TNSSR Opdeling af TNSSR Analyse af overvågning af forbindelser Indledende analyse Overblik over rutning, OSPF og Quagga's ospfd Analyse af indrapportering af ændringer Indrapportering fra begge routere Identificering af dobbeltmeddelelser Den udviklede løsning Design og implementering af TNSSR Valg af programmeringssprog Kildekode inddeling Trådning Køer Registrering af ændringer Indmelding af meddelelser Sockets Deployering af TNSSR Webinterface og opstart af TNSSR Deployeringsscripts Test af TNSSR Ekstern påvirkning Intern påvirkning Udvidelser af TNSSR Konklusion for TNSSR...38 TNSSS Indledning til TNSSS Analyse af TNSSS Design af TNSSS Implementering af TNSSS Indlæsning af data fra routere...44 Side 5

6 18.2 Tilgang til databaser TNSSS API Dynamisk kvalitetskontrol af TNSSS Konklusion for TNSSS...52 TNSSW Indledning til TNSSW Opbygning af TNSSW Analyse af TNSSW Design af TNSSW Implementering og deployering af TNSSW Kommunikation mellem klient og server i TNSSW Implementering af præsentation i Google Maps Udvidelser af TNSSW Konklusion for TNSSW Oversigt over samlet system...74 EPILOG Accepttest Konklusion Perspektivering Referenceliste Anvendt litteratur Anvendte internetsider Programliste...80 Appendix 1 - SCRUM...81 Side 6

7 1 Indledning Denne rapport omhandler udviklingen af et IT-system for Swarco Technology til overvågning af netværksforbindelsers status i et trafikreguleringsnetværk. Rapporten beskriver de overvejelser og valg der har været i forbindelse med analyse, design og implementering af systemet samt de teknologier indenfor datakommunikation og softwarekonstruktion der er blevet anvendt. I det efterfølgende kapitel gennemgås projektbeskrivelsen, hvor problemstillingen analyseres og målene for projektet defineres. 2 Projektbeskrivelse Projektbeskrivelsen danner grundlag for projektet, og indeholder derfor en problemanalyse, problemformulering, samt mål og forventede resultater. Derudover indeholder projektbeskrivelsen også en kort beskrivelse af den procesmodel som er blevet anvendt under projektet samt en tids- og milepælsplan. 2.1 Problemanalyse Til styring og regulering af bytrafik anvendes detektorer og reguleringsenheder, som sikrer at trafikken forløber flydende. Disse reguleringsenheder er forbundet i et selvstændigt kablet netværk, via routere1, som tilses af en operatøren på en central. I centralen foregår en overordnet koordinering og overvågning af trafikken i byen, således at det eksempelvis er muligt at optimere vejene ind mod byen om morgenen og ligeledes ud af byen om eftermiddagen i myldretiden, så der ikke opstår store køer. Et eksempel på et netværk i en by kan ses på figuren herunder: Figur 2.1: Eksempel på trafikreguleringsnetværk. Der forefindes på nuværende tidspunkt software som gør det muligt manuelt at detektere hvorvidt de enkelte routere er online i netværket, men det er ikke muligt at overvåge hvorvidt de enkelte forbindelser mellem routerne er tilsluttede eller afbrudte. Da der eksisterer redundans i netværket vil 1 Swarcos SHDSL routere. Mere information om routerne kan findes på: som desuden er vedlagt på Cd'en Prolog Side 7

8 de routningsalgoritmer som dirigerer kommunikationen kunne sikre forbindelse mellem routerne, selvom et netværkskabel eksempelvis er gravet over ved f.eks. vejarbejde. Det er dermed kun muligt på nuværende tidspunkt at detekterer når samtlige forbindelser til en router er afbrudt og et netværkskabel kan således have været gravet over i lang tid før det opdages af centralen. Dermed er det ikke muligt at rette fejlene imens udgravningen står åben, samt at afgøre hvem der har erstatningsansvaret for det ødelagte netværkskabel. Swarco Technology ønsker derfor at få udvidet deres software med et system som skal tilbyde følgende services: Systemet skal overvåge de enkeltstående forbindelser mellem routerne. Systemet skal gøre det muligt for en server at opsamle informationer om forbindelser mellem routere. Systemet skal foretage logning af tid, fejltyper og sted i en database når en forbindelse bliver afbrudt. Systemet skal tilbyde en grafisk og tekstbaseret præsentation af forbindelser, samt alarmerer overvågningscentralen i det øjeblik en forbindelse afbrydes. Google Maps API2 ønskes benyttet til den grafiske præsentation. Systemet skal bestå af løst koblede komponenter, der nemt kan udskiftes, og grænsefladerne mellem disse skal være tydeligt defineret. Derudover forefindes der nogle tekniske krav som skal opfyldes for at software kan integreres i Swarco Technology's nuværende softwareløsninger: Eventuel software på routerne skal afvikles på en Linux-platform. Systemet skal kunne samarbejde med en nuværende database som bl.a. indeholder koordinater for de enkelte routere. Det nuværende netværk er opbygget af forskellige netværksteknologier, såsom Ethernet og DSL. For at udvikle et system der er kompatibel med det nuværende, skal alle netværkets aspekter analyseres. I løbet af inceptionen blev der på baggrund af de nævnte overordnede krav udarbejdet en kravmodel for projektet, som er forefindes i afsnit Problemformulering Swarco Technology ønsker udviklet et system til detektion af forbindelser status i et netværk som anvendes ved trafikregulering. Gennem projektperioden vil gruppen derfor bestræbe sig på at afklare følgende problemstilling: Er det muligt gennem analyse af det nuværende trafikreguleringsnetværk at udarbejde en systemprototype, som i en testopstilling der simulerer netværket, viser at det er muligt at detektere fejlsituationer3, som kan opstå ved de enkelte forbindelser? Det påpeges at der under projektperioden udelukkende arbejdes med forbindelser, og at nedbrud af routerne ikke detekteres på nuværende tidspunkt, da det primære krav fra Swarco Technology er at være i stand til at kunne detektere afbrudte forbindelser. Systemet designes dog så der er mulighed for at udvide det på et senere tidspunkt så det også kan håndtere oplysninger omkring routerne. 2 API: Application Programming Interface 3 Tilsluttede og afbrudte forbindelser. Side 8 Prolog

9 3 Mål og forventede resultater Følgende punkter oplister de mål og resultater som projektgruppen forventer at opfylde i løbet af projektperioden: Gennemføre en inception i tæt samarbejde med Swarco Technology for at fastlægge de specifikke krav og brugsmønstre til systemet. Undersøge og behandle risici i forbindelsen med konstruktionen af systemet, ved at behandle centrale brugsmønstre. Foretage analyse af nuværende system, og på baggrund af denne analyse udvælge mulige løsninger for konstruktionen af et system som opfylder Swarco Technology's krav. Analysere de udvalgte løsningers indflydelse på det nuværende systems drift, og derefter redegøre for fordele og ulemper ved disse. Herefter på baggrund af denne analyse udvælge den bedst egnede løsning. Foretage en testopstilling af netværket, som simulerer det nuværende system, og som muliggør udførsel af test af det udviklede software. Gennemføre testpræget udvikling, hvor det konstruerede software testes og evalueres løbende gennem hele projektperioden. Foretage review i samarbejde med Swarco Technology i løbet af projektperioden. Analysere og fastlægge strategier for distribution og lagdeling af softwaresystemet. Herunder udvikle et løst koblet system, som muliggør udskiftning af de enkelte moduler. Udvælge løsning til persistensgørelse af data som passer ind i virksomhedens nuværende system. Udarbejde en grafisk præsentation af netværkets status, herunder status for de enkelte forbindelser. Foretage en konstruktion og implementering af det udviklede system, som demonstrerer detektionen af forbindelserne i trafikreguleringsnetværket og håndteringen af fejlsituationer i forbindelse med disse. Løbende dokumentere udviklingsforløbet i form af projektjournaler, som muliggør løbende review af det udviklede software og overvejelser foretaget i forløbet. Ved projektperiodens afslutning levere et system som Swarco Technology kan implementere i det på nuværende tidspunkt anvendte system. Prolog Side 9

10 4 Procesmodel Som beskrevet i forrige afsnit har projektgruppen opstillet en række mål og resultater som projektgruppen ønsker at opfylde indenfor projektperioden. Det er derfor nødvendigt at vælge en procesmodel som kan hjælpe projektgruppen igennem projektperioden. Den procesmodel der anvendes i projektet er Unified Process (UP). Det betyder at det samlede projekt inddeles i fire faser: Inception, elaboration, konstruktion og transition, hvor inceptionen og elaborationen samt størstedelen af konstruktionen gennemføres i projektperioden. Forløbet i UP er angivet i figuren herunder. Figur 4.1: Forløbet i Unified Process. Gruppen har desuden valgt at anvende et agilt projektplanlægningsværktøj, SCRUM, i kombination med UP for at gøre det lettere at håndtere udviklingsforløbet. I projektet anvendes SCRUM i kombination med Unified Process, på den måde at elaborations- og konstruktionsfasens iterationer afvikles som enkeltstående sprints. Den sidste periode til afrapportering forløber ligeledes som et sprint. Under inceptionsfasen hvor krav og brugsmønstre skal udforskes har gruppen bestemt sig for ikke at benytte SCRUM, da det er vigtigt at tilstødende problemer behandles løbende. En nærmere beskrivelse af SCRUM forefindes i appendiks 1. Side 10 Prolog

11 4.1 Tidsplan Det faktiske forløb for projektperioden er illustreret i tabellen herunder. SCRUM-masteren og den testansvarlige er desuden angivet. Uge Fase Aktivitet 5-7 Inception ProjektIteration 0 grundlag SCRUM master Testansvarlig Frantz Elaboration / Konstruktion Iteration 1 Iteration 2 Iteration 3 Iteration 4 Alexey Jakob Alexey Jakob Afrapportering Rapportretning og korrektur Frantz Frantz Tabel 4.1: Overordnet tidsplan for projektet. Den detaljerede tidsplan forefindes på Cd'en. 4.2 Kvalitetskontrol af software I Unified Process indgår test som en naturlig del af alle faser og det vil derfor være naturligt at udføre en løbende kvalitetskontrol. Der er naturligvis ikke muligt at undgå fejl i den software der udvikles og der vil derfor under projektforløbet blive udført statisk- og dynamisk kvalitetskontrol af det udviklede software. I projektet anvendes testcases til kvalitetskontrol af kritiske områder af softwaren, for at sikre at disse er af høj kvalitet. De kvalitetskontrolaktiviteter, som gruppen har planlagt at gennemføre, fremgår af den overordnede milepælsplan i afsnittet herefter. 4.3 Milepælsplan En oversigt over projektets milepæle og kvalitetskontrolaktiviteter der blev udført under projektperioden er angivet i tabellen, herunder: Dato 02/ / / / / / / / / / / / / / / / Milepæl Første udkast til projektgrundlag til vejleder og Swarco Technology Godkendelse af projektgrundlag af vejleder og Swarco Technology Opsætning af testmiljø i samarbejde med Swarco Technology Godkendende review af inceptionsdokument med Swarco Technology Afslutning af inception og opstart af interation 1 Afslutning af interation 1 og opstart af interation 2 Inspektionsreview af dokumentation fra iteration 1 med Swarco Technology Komponenttest Afslutning af iteration 2 og opstart af iteration 3 Afslutning af iteration 3 Test af systemprototype Afslutning af Systemprototype test opstart interation 4 Accepttest (Endelig test) Afslutning af iteration 4 Rapport færdig til korrekturlæsning Rapportaflevering Tabel 4.2: Milepælsplan. Prolog Side 11

12 5 Indledende analyse af systemet Den indledende analyse af systemet indeholder en beskrivelse af hvordan gruppen har valgt at opdele systemet. Derefter følger en oversigt over de væsentligste artefakter udarbejdet under inceptionsfasen for projektet. Det være sig henholdsvis brugsmønstermodellen der indbefatter brugsmønsterdiagram og et overblik over aktørernes tilgang til systemet, kravmodellen som sikrer at alle de ønskede funktionaliteter bliver en del af det udviklede system, samt den risikoanalyse der er foretaget for at sikre kvaliteten af systemet. Der vil blive anvendt UML4 notation af UP's artefakter. Det skal understreges at for at opnå en dybere forståelse af systemets funktionaliteter anbefales det læseren at gennemlæse projektjournalerne Inceptionsdokument og Krav- og brugsmønsterdokument, som forefindes på Cd'en. Disse dokumenter indeholder den fulde dokumentation for inceptionsfasen, herunder blandt andet detaljerede brugsmønsterbeskrivelser. 5.1 Oversigt over system Da der udvikles et system til overvågning af netværksforbindelser i et trafikreguleringsnetværk, har projektgruppen valgt at navngive det udviklede system: Traffic Network Surveillance System Der vil gennem rapporten derfor bliver anvendt forkortelsen TNSS, som en henvisning til det samlede IT-system. Af praktiske grunde foretages en modulopdeling af IT-systemets softwarearkitektur. Ved inddeling af softwaren i mindre moduler, sikres stor fleksibilitet i den videre udvikling af systemet, da moduler kan ændres og udskiftes så længe snitfladerne mellem disse opretholdes. Modulopdelingen af systemet er samtidig et krav fra Swarco Technology's side, da det ved denne fremgangsmåde vil være muligt at integrere det udviklede system, i det eksisterende software som anvendes. Swarco Technology afvikler deres nuværende system på en central server i den pågældende by hvor trafiknetværket befinder sig, som tilgås eksternt af flere forskellige operatører på hver deres enhed. Denne opdeling i en klient-server-struktur, hvor en central server står for den overordnede administration og tilgås af mindre klient-applikationer, vil derfor blive benyttet til opbygningen af TNSS, da systemet skal kunne afvikles sammen med den eksisterende software. Overordnet set skal systemet kunne håndtere tre grundlæggende arbejdsopgaver, for at opfylde de overordnede krav: Detektering af fejlsituationer på forbindelser Administration og persistensgørelse af fejlmeddelelser Præsentation af netværkets nuværende status Det leder frem til en naturlig opdeling af systemet i tre moduler som hver især håndterer en af ovenstående opgaver. Hermed kommer en modulopdeling af systemet til at se ud som illustreret på næste side: 4 Unified Modeling Language Side 12 Prolog

13 Figur 5.1: Oversigt over opdeling af det samlede system. På figuren er for overblikkets skyld angivet specifikke informationer omkring den tekniske opbygning af systemet. Dette vil blive beskrevet nærmere under dokumentationen af de enkelte moduler, hvor der samtidig argumenteres for de valgte løsninger. Herunder følger ligeledes en begrundelse for opdelingen af TNSSW-delen. Figur 5.1, anvender følgende forkortelser for de enkelte moduler, som samtidig vil blive anvendt gennem den resterende del af rapporten. Anvendt forkortelse: Modul: Overordnet funktionalitet: Ansvarlig: TNSSR Detektering af afbrudte forbindelse, samt TNSS-Router indmelding af disse fejlmeddelelser til serveren. Alexey TNSSS Håndtering og dekodning af TNSS-Server fejlmeddelelser, samt persistensgørelse og opdatering af netværkets nuværende status. Frantz TNSSW TNSS-Web Præsentation af netværkets status, samt håndtering af forespørgsler fra operatøren. Jakob Tabel 5.1: Oversigt over forkortelser anvendt til beskrivelse af IT-systemet. Som angivet i tabellen har der under projektperiodens forløb været tildelt en ansvarlig på hvert modul. Den ansvarlige har haft det overordnede ansvar for konstruktion og implementeringen af modulet, men det understreges at selve analyse og designet er udført i fællesskab i projektgruppen. Opdelingen af systemet ligger samtidig til grund for opbygningen af rapporten, som indeholder en sektion der beskriver hver af de definerede moduler. Prolog Side 13

14 5.2 Brugsmønstermodel Brugsmønstermodellen indbefatter brugsmønsterdiagram, som viser de enkelte brugsmønstre som systemet indeholder og aktørernes tilgang hertil samt en aktørbeskrivelse, som beskriver de enkelte brugere af systemet. Brugsmønsterdiagram Brugsmønsterdiagrammet herunder illustrerer brugsmønstrene i systemet, samt operatørens interaktion med disse, det er valgt kun at vise operatørens tilgang til systemet da han er den vigtigste aktør. Figur 5.2: Diagram over systemets brugsmønstre. Som det ses i diagrammet er enkelte af brugsmønstrene beskyttet af en udvidet adgangskontrol. Det skyldes at disse funktionaliteter i TNSS skal være beskyttet, så det kun er operatører med udvidede rettigheder der kan anvende dem. Af diagrammet fremgår desuden anvendelsen af de eksisterende databaser over f.eks. routere. Side 14 Prolog

15 Aktørbeskrivelse Herunder er en beskrivelse af systemets primære og sekundære aktører. Der er tilføjet en tekniker og administrator til aktørbeskrivelsen, som står for opsætning og konfiguration af selve netværket og routerne. Routerne er desuden tilføjet som sekundær aktør, da de har en central rolle i selve detekteringen af de afbrudte forbindelser. Dette beskrives nærmere i den efterfølgende sektion. Primære aktører Beskrivelse Operatør Operatøren er en person som tilgår systemet via en sikker forbindelse via internettet. Han bruger systemet til at overvåge de enkelte forbindelser mellem routerne. - Logge ind i system - Kontroller om en forbindelse er aktiv - Se alle forbindelser i netværket - Se informationer om routerne. - Se en alarm såfremt en forbindelse afbrydes - Se informationer om forbindelserne - Fjerne en forbindelse fra systemet - Se alle tidligere fejl og ændringer som systemet har været underlagt Teknikker Teknikkers opgave er at konfigurere routerne og genoprette forbindelse mellem dem i tilfælde af fejlsituationer. - At installere software på routerne. - At konfigurere indstillinger for routerne. - At konfigurere routerne via et webinterface. - At genoprette forbindelser. Administrator Administrator står for konfiguration af serverapplikationerne og databasen på centralen. - At installere software på serveren. - At indstille og redigere generelle systemindstillinger - At tilføje/fjerne bruger fra systemet Sekundære aktører Database Router Mål Beskrivelse Mål Databasen benyttes til at logge informationer om netværkets status og ændringer af disse. - At opbevare data - At være online 24/7 Routeren står for håndtere netværkstrafikken samt for at indsende oplysninger om dens forbindelser til serverapplikationen. - At sende information til serveren, hvis en forbindelse til dens naborouter afbrydes - At logge ændringer lokalt i tilfælde af manglende forbindelse til serveren. - At tilbyde et webinterface - At være online 24/7 og i tilfælde af nedbrud fremsende en meddelelse til serveren. Tabel 5.2: Beskrivelse af aktører til systemet. Prolog Side 15

16 5.3 Kravmodel Kravmodellen for systemet er angivet i tabellerne herunder. Hvert krav er tildelt et ID med et præfiks, som angiver hvorvidt det er et funktionelt krav (F) eller et ikke-funktionelt krav (K). Kravene er inddelt i henhold til opdelingen af systemet, som beskrevet i afsnit 5.1, Oversigt over system. Desuden er der for hvert krav angivet prioritet efter MoSCoW metoden (Must, Should, Could og Want), i henhold til kravets vigtighed i forhold til det endelige system. Funktionelle krav TNSSS og TNSSW ID Type Detaljer TNSS skal sikre at det kun er operatøren FA01 Adgangskontrol der har mulighed for at benytte systemet. Særlige forhold MoSCoW Systemets login skal bestå af et brugernavn med en tilhørende kode. Adgangskoden skal være pluggable. Could FA02 Kontroller forbindelser TNSS skal give operatøren mulighed for at kontrollere om en forbindelse er aktiv. Must FA03 Kontroller forbindelser TNSS skal give operatøren mulighed for at Herunder hvorvidt disse er aktive se alle forbindelser i netværket. eller afbrudte. Could TNSS skal automatisk opdatere FA04 Status for router brugergrænsefladen når en router tilføjes til systemet. FA05 Status for router Sammenholdes med krav FB03. Could TNSS skal give operatøren mulighed for at Der skal udskrives ID, forbindelser, se informationer om en router. type og koordinater. Want FA06 Status for forbindelser TNSS skal automatisk opdatere brugergrænsefladen når en forbindelse tilføjes til netværket. Sammenholdes med krav FB04. Could FA07 Status for forbindelser TNSS skal rejse en alarm til brugeren såfremt en forbindelse i netværket bliver afbrudt. Der skal udskrives tidspunkt, fejltype og sted. Sammenholdes med krav FB05. Must FA08 Status for forbindelser Der skal udskrives forbindelses ID, TNSS skal give operatøren mulighed for at status, router der er forbundet, antal se informationer om forbindelserne. fejl og kommentarer. Should FA09 Status for forbindelser TNSS skal kunne håndtere falske fejlsituationer som kan opstå i forbindelse med montering af nye forbindelser. Could FA10 Håndtering af fejlsituationer TNSS skal gøre det muligt for operatøren at tilføje en kommentar til forbindelser med fejl. Det skal være muligt for operatøren at angive hvorvidt der er sendt en teknikker afsted, samt status for reparationen. Could FA11 Håndtering af fejlsituationer TNSS skal gøre det muligt at fjerne en forbindelse fra systemet. Såfremt en forbindelse fjernes permanent fra netværket skal den ikke længere fremgå af den grafiske brugergrænseflade. Could FA12 Håndtering af fejlsituationer TNSS skal gøre det muligt at fjerne en router fra systemet. Såfremt en router fjernes fra netværket skal den ikke længere fremgå af den grafiske brugergrænseflade. Want FA13 Logning Side 16 TNSS skal gøre det muligt for operatøren at se alle tidligere fejl og ændringer som systemet har været underlagt. Should Prolog

17 TNSS skal give administratoren mulighed FA14 Administration for at ændre indstillinger for serverapplikationen. FA15 Informationer TNSS skal gøre det muligt for operatøren om forbindelse at ændre forløbet af en forbindelse. Tilføj/fjern bruger Portindstillinger Databaseadresse / databaseindstillinger osv. Could Det er muligt at optegne en forbindelse på korte så den følger de rigtige veje. Could Tabel 5.3: Funktionelle krav for TNSSS og TNSSW. Ikke-funktionelle krav TNSSS og TNSSW ID KA01 Type Detaljer Særlige forhold MoSCoW Brugergrænsefladen på TNSS skal Brugergrænsefl anvende Google Maps API til visning af ade routere og forbindelsen mellem disse. Must KA02 Sikkerhed TNSS på centralen skal kunne tilgås via en Kommunikationen foregår på port sikker forbindelse via internettet. 443 (TLS). KA03 Persistens TNSS skal anvende en SQL-baseret database til logning af ændringer i netværket osv. Should Must Tabel 5.4: Ikke-funktionelle krav for TNSSS og TNSSW. Funktionelle krav TNSSS og TNSSR ID Type Detaljer Særlige forhold MoSCoW Der skal være muligt at indstille ID, placering samt deaktivere og aktivere softwaren. Could FB01 Konfiguration TNSS skal gøre det muligt for teknikeren af routere at konfigurere indstillinger for routerne. FB02 Der skal anvendes samme TNSS skal gøre det muligt for teknikeren Konfiguration webinterface som benyttes til at at konfigurere indstillinger for routerne via af routere indstille Swarcos andre services på et webinterface. routerne. Could FB03 Status for routere TNSS skal automatisk registrere når en router tilføjes til systemet. Sammenholdes med krav FA04. Want FB04 Status for forbindelser TNSS skal automatisk registrere når en forbindelse tilføjes til netværket. Sammenholdes med krav FA06. Should FB05 Status for forbindelser Systemet skal garantere at TNSS skal registrere og rejse en alarm når fejlmeddelelsen når frem til serveren en forbindelse bliver afbrudt. Sammenholdes med krav FA07. Must FB06 Logning TNSS skal kunne logge ændringer i netværket. Must FB07 Logning TNSS skal føre log over ændringer i netværket på de enkelte router. Der skal registreres tidspunkt, fejltype og sted. Should Tabel 5.5: Funktionelle krav for TNSSS og TNSSR. Ikke-funktionelle krav TNSSS og TNSSR ID Type Detaljer KB01 Drift Systemet på router skal køre hele tiden, og i tilfælde af systemnedbrud, melde dette tilbage til serveren inden de lukkes. Særlige forhold MoSCow Want Tabel 5.6: Ikke-funktionelle krav for TNSSS og TNSSR. Prolog Side 17

18 5.4 Risikoanalyse Der er blevet fortaget en risikoanalyse efter FURPS+5, for at finde kritiske punkter ved systemet. Analyse er foretaget på baggrund af de ikke funktionelle krav fra kravmodellen. Risikoanalysen giver et overblik over de testbare kriterier som systemet skal opfylde: Kvalitetsscenarium Påvirkning Succesprioritet Risiko Mellem Mellem Høj Mellem Hvis detektionen tager for langt tid, vil de ansvarlige for afbrydelsen forsvinde inden overvågningspersonalet møder op på stedet. Mellem Lav Faktor Funktionalitetskriterier: Sikkerhed Kommunikation mellem TNSSW og TNSSS skal være sikker. Hvis kommunikationen ikke er sikker, kan uvelkomne personer får adgang til systemet. Yderevne kriterier: Belastning af netværket. Mængden af netværkstrafik der benyttes Andre services bliver forsinket, hvis mængden af til overvågning af forbindelser skal ikke netværkstrafik stiger så meget at det påvirker dem. påvirke andre services der benytter netværket. Tid før detektion. En alarm skal vises i TNSSW senester 5 minutter efter en forbindelse er afbrudt. Driftsikkerhedskriterier: Genstart. I tilfælde af påkrævet genstart skal alle services på TNSSR starte automatisk. Hvis services ikke starter når routeren genstarter, vil afbrudte forbindelser ikke kunne rapporteres til centralen (TNSSServer). Høj Lav Delvis systemnedbrud. Når en af TNSS moduler går ned eller på Hvis delvis systemnedbrud ikke rapportes, vil operatøren anden måde mister sin funktion, skal ikke opdage at systemet ikke virker. dette rapporteres til operatøren. Høj Mellem Vedligeholdelseskriterier: Snitflader mellem TNSS moduler. Systemet skal have klart definerede snitflader mellem software moduler. Det vil blive svært at udvikle på systemet sener og dermed også at tilpasse det ind i andre systemer som Swarco ønsker Høj Høj Modificering af systemet. TNSS moduler skal være løst koblet til hinanden således at de nemt kan udskiftes med andre. Hvis modulerne ikke kan udskiftes med andre, vil systemet ikke være brugbar til videreudvikling. Høj Høj Dokumentation. Der skal udarbejdes dokumentation af de Uden dokumentation vil det være svært at videreudvikle enkelte moduler. systemet. Mellem Mellem Høj Mellem Brugerkriterier: Brugervenlighed. Det skal være enkelt for operatøren at benytte systemet. Hvis operatøren ikke kan anvende systemet, bliver afbrudte forbindelser ikke håndteret. Tabel 5.7: Risikoanalyse for systemet. Artefakterne beskrevet i dette og de forgående afsnit danner grundlag for udarbejdelsen af systemet. De enkelte moduler for systemet vil blive beskrevet i de tre efterfølgende sektioner, hvor der vil blive gået i dybden med de tekniske overvejelser der har været i forbindelse med konstruktionen af det samlede system. 5 FURPS+ står for: Functionality, Usability, Reliability, Performance, Supportability. Se evt. Kilde 11 kapitel 6. Side 18 Prolog

19 TNSSR Dokumentation for TNSS-Router

20 6 Indledning til TNSSR Softwareløsningens overordne funktion er at registerere når en forbindelse bliver tilsluttet eller afbrudt, og sørge for at ændringen bliver indrapporteret til en server. I sektionen fokuseres der primært på de overvejelser og valgmuligheder der lå til grund for de valgte løsninger. Det skal understreges at det udviklede software ikke skal ses som en proof-ofconcept, men derimod som en færdig softwareløsning, hvilket afspejles i den analyse der vil blive gennemgået, samt beskrivelsen af de tests der er blev foretaget for at sikre en softwareløsning af høj kvalitet. Projektgruppen har til at kunne teste systemet fået udleveret 5 routere fra Swarco Technology. Routerne benyttes til overførsel af data mellem trafikreguleringsenhederne og centrallen. Nogle af forbindelserne er af en ældre dato, og kan derfor være ret langsomme hvad angår dataoverførsel. Der er derfor blevet stillet følgende krav: Faktor Kvalitetsscenarium Påvirkning Succesprioritet Risiko Mængden af netværkstrafik der benyttes til overvågning af forbindelser skal begrænses mest muligt så det ikke påvirker andre services der benytter netværket. Andre services bliver forsinket, hvis mængden af netværkstrafik stiger så meget at det påvirker dem. Høj Mellem Yderevne kriterier: Belastning af netværket. Tabel 6.1: Uddrag af risikoanalyse. Da dette ikke er et kvantitativ krav, vil dette blive løst analytisk, og det løsningsforslag der forbruger færrest netværksressourcer vil blive udvalgt. Formålet med TNSS systemet er at alarmere operatøren når en forbindelse bliver afbrudt. Et andet krav er derfor: Funktionelle krav TNSSS og TNSSR ID Type FB05 Status for forbindelser Detaljer Særlige forhold MoSCoW Systemet skal garantere at TNSS skal registrere og rejse en alarm når fejlmeddelelsen når frem til serveren en forbindelse bliver afbrudt. Sammenholdes med krav FA07. Must Tabel 6.2: Uddrag af kravmodel for TNSSR. Det vil senere i analysen vise sig, at det ikke er nok at oprette en forbindelse med en sikker overførsel mellem en router og serveren for at opfylde dette krav. Side 20 TNSSR

21 7 Opdeling af TNSSR På baggrund af den ønskede funktionalitet som TNSSR skal opfylde, er softwaren blevet opdelt i to lag, som vist på Figur 7.1. Figur 7.1: Opdeling af TNSSR Det første lag tager sig af kommunikation med andre programmer og enheder, ved brug af socket forbindelser. Det andet lag består af to dele: den første del tager sig af at overvåge forbindelser og skal opfylde det førstnævnte krav, mens den anden del afvikler en algoritme der sørger for at forbindelserne bliver korrekt indmeldt til serveren. I de næste to afsnit analyseres hvordan de to dele af lag 2 kan designes for at opfylde de to mest betydende krav for TNSSR. 8 Analyse af overvågning af forbindelser I dette afsnit analyseres de forskellige valgmuligheder der er for at detektere når en forbindelse bliver tilsluttet eller afbrudt, således at den bedste løsning kan udvælges. Det bliver hurtigt klart at den ene løsning benytter lagt færre netværksressourcer end de andre. En stor del af analysen vil derfor omhandle den løsning der benytter færrest netværksressourcer, og om denne overhovedet kan lade sig gøre. 8.1 Indledende analyse Der er to metoder en afbrudt forbindelse kan detekteres på. Nogle netværkskort kan registrere en afbrudt forbindelse hardwaremæssigt, og informere operativsystemet derom. Dette kan lade sig gøre med mange Ethernet over twisted pair interfaces. Selvom de udleverede routere fra Swarco Technology benytter disse, har det ved analyse af routerne vist sig at dette ikke er tilfældet6. Derudover kan denne løsning hellere ikke benyttes i tilfælde af at netværkskablet er af en anden type, f.eks. optisk, eller hvis forbindelserne linkes sammen med switche og hubs. Det er derfor nødvendigt at konstruere software som registrerer forbindelsesændringer på en anden måde, da denne infomation er ikke tilgængelig fra operativsystemet. En netværksafbrydelse kan kun registreres af software når en router ikke modtager noget data fra sin naborouter7. En overvågning af en forbindelse kræver derfor at der sendes data med jævne mellemrum over forbindelsen. Herfra er der to muligheder: enten at udvikle software der sender data over forbindelser og tilføjer dermed yderlige belastning til netværket, eller at finde et 6 Selvom routere har 5 netværksinterfaces, er der kun 1 netværkscontroller til at styre dem. Normalt er der en for hver. 7 Med naboen forstås en router der er direkte forbundet til den pågældende router. Altså en router på samme IPnetværk. TNSSR Side 21

22 eksisterende program på routere der med jævne mellemrum kommunikerer med andre routere. Figur 8.1: Ping- og hello-meddelelser(1-vejs). Hvis der skal sendes data over forbindelser, kan dette gøres på to måder: ved ping- eller ved hellomeddelelser. Ved ping forespørger en router sin nabo om den findes, og hvis alt fungerer som det skal, får routeren et positivt svar. Denne løsning kræver at data sendes to gange over en forbindelse. Ved hallo meddelelser skal en router få en hello-meddelelse fra sin nabo inden for et bestemt tidsinterval. Denne løsning kræver at begge routere skal have deres tidsfrister synkroniseret, men bruger til gengældt kun halvt så meget trafik som ved ping. Hello-meddelelser må derfor betragtes som en bedre løsning i forholdt til netværksressourcer. De routere som Swarco Technology stillede til rådighed til test, havde det mest basale software installeret på deres Linux system. Der er to programmer som kommunikerer med andre enheder: ARP-protokollen der er en del af Linux-kernen, og programmet Quagga der håndterer rutningsprotokollen. ARP oversætter IP-adresser for de direkte koblede enheder til MAC-adresser. Disse opsamles ved en broadcast forespørgsel, hvor naboen returner dens MAC-adresse. Dette sker kun en gang, for når en routere lærer naboens MAC-adresse, bliver denne gemt i ARP-cache (ARP-tabel). ARP kan derfor ikke benyttes til overvågning af forbindelser. I det næste afsnit analyseres hvilke informationer der kan hentes fra Quagga. Der gives en kort introduktion til formålet med rutning, for at forklare hvorfor Quagga indsamler de nødvendige informationer. Desuden skal afsnittet overbevise læseren om at Quagga softwaren ikke kan undlades fra routere, og i tilfælde af Quagga udskiftes med lignende routningsprogrammer, vil de nødvendige informationer stadig kunne forefindes. 8.2 Overblik over rutning, OSPF og Quagga's ospfd Rutning En router er en computer, der er dedikeret til at overføre data mellem forskellige netværk. Som alle computere har routeren et operativ system, og i mange tilfælde er det Unix afledte styresystemer såsom Linux og FreeBSD, eller Cisco's IOS. Til Linux findes der et udvalg af open source rutninsprogrammer, hvor Quagga er et af de mest udbredte. Cisco's IOS er ikke et OS i den forstand Side 22 TNSSR

23 som Linux og Unix, da der ikke er anden software end IOS på Cisco routere, og IOS står selv for rutningen. IOS er værd at nævne, da Cisco har en stor markedsandel på routere, hvilket måske har ført til at Quagga benytter en syntaks der er stærkt inspireret af IOS. For at overføre data mellem forskellige netværk, skal en router have nogle netværksinterfaces, ét for hvert netværk. Et routerinterface opsættes med en IP-adresse og en subnetmask, som regel manuelt af netværksadministratoren, hvilket også er tilfældet med router fra Swarco. Ud fra disse kan en router bestemme hvilke netværk den er forbundet til.8 Når interfaces er indstillet, kan en router kun kommunikere med andre netværksenheder hvis interfaces er indstillet til samme netværk, da routeren ikke kender andre netværk. Ser man bort fra switches og hubs som blot videresender data, kan en router kun kommunikere med dens nabo routere. Figur 8.2: Router R1 kender kun de direkte koblede netværk. De andre netværk skal læres ved statisk/dynamisk rutning. En router kan lære om andre netværk på to måder. Enten ved at netværksadministratoren manuelt angiver en rute til et andet netværk (statisk rutning), eller ved at lade en rutningsprotokol håndtere det (dynamisk rutning). Routere der afvikler samme rutningsprotokol og som er indstillet til samme rutningsdomæne udveksler informationer med hinanden. Routere fra Swarco opererer på et intranet der er opbygget med redudans, og her er en rutningsprotokol en nødvendighed, for ellers kan routeren ikke lære om ændringer på fremmede netværk. OSPF Der er to typer af rutningsprotokoller9: distance vector og link state. Til større intranet er linkstate protokoller bedre egnet, da de konvergerer hurtigere ved netværksændringer, og benytter færre netværksressourcer. Ulempe ved dem er at de benytter mere CPU når routerens rutningstabel skal opdateres, hvilket er et problem for gamle routere med svage CPU'er. Da routere fra Swarco opererer på større intranet, er link-state protokoller et lysende klar valg. Af link-state protokoller er OSPF og IS-IS de mest udbredte af de frit tilgængelige protokoller. OSPF er normalt den foretrukne, selvom det kan ikke siges at den ene er klart bedre end den anden. Begge protokoller understøttes af Quagga. Swarco Techonology har valgt at benytte OSPF, dette kan bl.a. ses i 8 IP netværk bestemmes ved logisk AND af IP adresse og subnetmask. 9 Af Interior Gateway Protokoller (hånderer rutning indenfor en rutningsdomæne) TNSSR Side 23

24 implementation af routernes webinterface, se afsnit 11.1, Webinterface og opstart af TNSSR. OSPFs stærke side er, at protokollen opbygger en fuld topologi af rutningsdomænet, hvilket giver den mulighed for hurtigt at udregne en ny korteste rute. En router ved altså status af alle andre forbindelser på samme rutningsdomæne. Hvis alle routere befandt sig på samme rutningsdomæne, ville det være nok med at kun forespørge informationer om ændringer fra én router på intranetet. Dette er naturligvis ikke gældende alle steder, da der kan være flere rutningsdomæner, som vist på Figur 8.3. Derfor hvis informationer skal hentes fra Quagga, skal det være fra hver enkel router. Figur 8.3: OSPF internetværk opdelt i forskellige rutningsdomæner. På nuværende tidspunkt er det med rette at præcisere at Quagga ikke er et program, men derimod flere selvstændige daemons10 der samarbejder om at sammensætte rutningstabellen. Daemonen zebra står for kommuination med operativsystemet. De andre daemons er opdelt efter rutningsprotokollen. Daemonen ospfd håndterer OSPF protokollen, og er altså den der skal hentes informationer fra. Quagga's ospfd Opsamling af rutningsinformationer fra ospfd beskrives i det følgende. Det skal nævnes at det samme gælder for isisd. Hver router sender med jævne mellemrum en hallo-meddelelse ud gennem sine netværksinterfaces. Alle enheder der er direkte koblet til denne router modtager pakken på deres netværksinterfaces, hvilket registreres af deres ospfd. Hermed bliver forbindelsen til denne router registreret som tilsluttet på disse enheder. Til hver router allokeres en timer, som decrementeres indtil den næste hallo-meddelelse modtages. Hvis timeren løber ud, bliver forbindelsen betragtet som afbrudt. For at implementere denne protokol, skal ospfd altså indeholde en oversigt med disse informationer, og den kan hentes med terminalkommandoen: show ip ospf neighbor På Figur 8.4 ses en udskrift fra Quagga s ospfd der viser en routers naboinformationer. Det ses at denne router har 3 naboer, den ene af dem har ID , den er forbundet til routerens interface eth0.1 og dens timer vil udløber om 31,552s. 10 En service der afvikles i baggrunden. Side 24 TNSSR

25 RouterX> show ip ospf neighbor Neighbor ID Pri State Full/DR Full/DR Full/DR Dead Time s s s Address Interface eth0.1: eth0.2: eth0.3: RXmtL RqstL DBsmL RouterX> Figur 8.4: Udskrift fra ospfd der viser hvilke naboer en router har forbindelse til. Som vist på Figur 8.4, kender ospfd alle tilsluttede forbindelser til dens naboer. Når en forbindelse afbrydes, bliver dette registreret af ospfd. Ved at hente informationer fra ospfd, kan der altså registrere når en forbindelse afbrydes. Udhenting af informationer fra ospfd Der er to måder hvorpå informationer kan hentes fra ospfd. Et OSPF API udarbejdet af Ralph Keller kan benyttes, ellers kan informationer hentes fra ospfd terminal interface, hvis standard port er Selvom andvendelse af API virker som en pænere løsning, har den to problemer. Det første er at ospfd skal indstilles til at det skal være muligt for API'et at kommunikere med ospfd. Dette skal gøres gennem routerens webinterface, og der er reel risiko for at bruger af systemet kan glemme dette, derudover kan det give problemer ved deployering da der så skal ændres i de nuværende opsætninger af ospfd. Det andet problemer er at dokumentation til API'et ikke længere er tilgængelig, på Ralph Keller's hjemmeside. På baggrund af de to problemer vælges kommunikation gennem terminal interface i stedet for. Det kan hermed konkluderes at det er muligt at hente informationer om status for hvert direkte koblede forbindelse fra Quagga's ospfd. Der benyttes ingen yderligere netværksressourcer ved denne løsning, og da det vigtigste krav er at bruge så få netværksressourcer som muligt, vælges denne løsning. 9 Analyse af indrapportering af ændringer Når en forbindelse bliver tilsluttet eller afbrudt, skal ændringen rapporteres til en server. Kravet til systemet er, at der skal garanteres at en afbrudt forbindelse altid bliver meldt ind. En tilsluttet forbindelse skal også meldes ind, men dette har ikke lige så høj prioritet som en afbrudt forbindelse. Operatøren skal have mulighed for at tilkalde en teknikker når en forbindelse afbrydes, men når den tilsluttes igen skal der ikke foretages noget. For at være sikker på at serveren har modtaget en meddelelse fra en router, benyttes en protokol der garanter en sikker overførsel, TCP. I tilfælde af en succesfuld overførsel, returner TCP på serveren en bekræftelse på at data er modtaget, og ellers får systemet at vide at data ikke er overført. Hvis en router ikke kan overføre data, f.eks. hvis serveren er nede, skal routeren prøve igen senere. Derfor kræves det at meddelelser bliver gemt lokalt på routerne, indtil de er overført. Da der er risiko for at en router kan gå ned imens den har nogle meddelelser der mangler at blive overført, skal de persistensgøres, således at de kan hentes op når programmet starter igen. 9.1 Indrapportering fra begge routere At lade routere beholde meddelelser indtil de er sendt til serveren, kan give et problem, idet flere meddelelser kan blive sendt til server indenfor en kort tidsperiode. Dette kan også ske med en TNSSR Side 25

26 ustabil forbindelse, der registreres skiftevis som tilsluttet og afbrudt. Hver ændring bliver som udgangspunkt rapporteret af begge routere, derfor skal dobbeltmeddelelsen, altså den meddelelsestvilling der ankommer sidst, ignoreres. Dette er ikke et problem så længe meddelelser ankommer parvis, som vist på Figur 9.1 øverst til venstre. Reelt ser det dog sandsynligvis ud som vist på Figur 9.1 øverst til højre. Når en router får kontakt med serveren vil den kunne nå at overføre alle meddelelser, da deres datastørrelse er meget lille. Dette betyder at dobbeltmeddelelsen bliver svær at identificere. Figur 9.1: Indrapportering af meddelelser. A betyder afbrudt, T betyder tilsluttet og ign. er forkortelse for ignoreret. Under routere vises hvilke meddelelser hver enkelt router sender. Til venstre for server vises den mest optimale rækkefølge som serveren kan modtage meddelelser på. Til højre for server vises den mest sandsynlige. At identificere og ignorere den anden meddelelse er kritisk for systemet og det vil nu blive beskrevet hvordan dette problem løses. Hvis meddelelser ankommer som vist på Figur 9.1 øverst til højre, vil en log over ændringer indeholde de ekstra beskeder, og det kan forvirre operatøren. De ekstra beskeder vil også gøre at databaseloggen kommer til af fylde mere, op til det dobbelte. Det største problem er hvis den ene router går ned imens den er i gang med at indrapportere meddelelser. Dette er illustreret på Figur 9.2 og her kan det ses at den sidste meddelelse har indrapporteret at forbindelsen er tilsluttet, hvilket ikke er tilfældet. Det stillede krav om at en afbrudt forbindelse skal blive rapporteret til serveren, er hermed ikke opfyldt. Hvis dobbeltmeddelelser kunne blive identificeret og sorteret fra, ville dette problem ikke opstå. Side 26 TNSSR

27 Figur 9.2: Router 2 er gået ned under overførsel af meddelelser. Den sidste meddelelse er ikke indrapporteret, derfor kender serveren den forkerte aktuelle status. Sandsynligheden for at en router går ned imens den er i gang med at overføre meddelelser til en server er meget lille. Det er ret sjældent at en forbindelse går ned, og meddelelserne bliver leveret ret hurtigt til serveren, så tidsvinduet er meget kort. Omvendt kan man se at dette system kan blive afviklet på mange intranets. Hvert intranet består af mange forbindelser og routere, og programmet afvikles uafbrudt på hver router døgnet rundt. Sandsynligheden for at denne fejl sker engang er derfor reel, og eftersom gruppens mål er at udvikle software som skal være færdigt, skal der findes en løsning. 9.2 Identificering af dobbeltmeddelelser Hvis en dobbeltmeddelelse skal identificeres, skal den dele noget unikt sammen med den første meddelelse der allerede er indmeldt til serveren. Tiden er den oplagte valgmulighed, men det kræver at den er synkroniseret på begge routere. I OSPF tager det mellem 30 og 40 sekunder at registrere en afbrydelse og mellem 0 og 10 sekunder at registrere en tilsluttet forbindelse. I værste tilfælde vil der blive genereret meddelelser med samme information inden for 30 sekunder. Dette er standardindstillinger og timer-værdierne kan indstilles til registrere ændringer endnu hurtigere. Da det ikke er sikkert at alle routere har deres tid synkroniseret inden for det korte tidsinterval, kan tiden ikke betragtes med sikkerhed som at være den unikke del af en besked. Der findes ikke anden reel information om en ændring, der kan være med til at gøre den unik. Hvis en dobbeltmeddelelse skal identificeres, må den derfor tildeles et unikt ID, og samme ID skal genereres af begge routere inden deres meddelelser bliver sendt af sted til server. Dette ID skal være et tal der inkrementeres for hver ny ændring og skal persistensgøres, for routere skal have mulighed for at blive genstartet. Denne løsning har desværre nogle synkroniseringsproblemer. Hvis en router udskiftes, hvis dens software geninstalleres eller hvis router på en anden måde mister det ID, som den var nået frem til, hvilket ID skal den så sende? Routeren kan godt forespørge serveren, der kender det sidste registrerede ID, men serveren kan godt være offline. ID kan også hentes fra naboen medmindre den også er geninstalleret eller hvis forbindelsen til den er afbrudt. Ikke mindst er der også det problem at en router kan registrere en afbrydelse uden at den anden kan nå at gøre det, dette kan lade sig gøre med en afbrydelse der varer mellem 30 og 40 sekunder med standardindstillinger. Den ene router vil inkrementere ID'et, mens den anden ikke vil gøre det, og hermed kommer de to ud af takt. Fordi man ikke kan være fuldstændig sikker på at begge routere TNSSR Side 27

28 kan generere samme ID når en ændring finder sted, fravælges denne løsning. 9.3 Den udviklede løsning Eftersom en dobbeltmeddelelse ikke kan identificeres med sikkerhed, må der findes en anden løsning og undersøges om der er metoder hvormed der kan undgås at der genereres en dobbeltmeddelelse. Når en router mister en forbindelse til sin nabo kan den ikke vide om det er fordi forbindelsen er afbrudt eller om det er fordi naborouteren er gået ned. Derfor må hver router selv rapportere afbrydelsen hver gang til serveren. For en tilsluttet forbindelse er det til gengæld nok at kun én router rapporterer ændringen. Hver router har et router-id, der er unikt i OSPF rutningen, og der kan dermed bestemmes at routeren med den laveste router-id vil sende meddelelse om en tilsluttet forbindelse. Hermed er problemet med dobbeltmeddelelser dog ikke løst. I udviklingsperioden har gruppen diskuteret mange forskellige løsningsforslag, og gjort sig nogle erfaringer. Det har til sidst ført frem til den løsning som kan ses på Figur 9.3. Dens grundlæggende ide er at kun en router må kommunikere med serveren når forbindelsen er tilsluttet. Problemet skyldtes at routere indrapporter beskeder usynkroniseret, derfor medfører det orden når meddelelser indrapporteres igennem én router. Når en router med en lavt router-id skal indrapportere en tilsluttet meddelelse (T-meddelelse), bliver meddelelsen først sendt til dens nabo, som placer meddelelsen bagest i køen. De gamle meddelelser på naboen bliver sendt til serveren før den nye T-meddelelse. Figur 9.3: Det endelige løsningsforslag. Alle dobbeltmeddelelser kan identificeres og ignoreres. Risikoen for at en router kan gå ned imens den overfører nogle meddelelser, hvilket medfører til en forkert status på server, er også så godt som udryddet med denne løsning. Hvis T-meddelelsen er sendt til server fra router med den høje router-id, og den router derefter går ned, så vil dette registreres af router med den lave router-id. Hvor man i den oprindelige scenarie sendte tilsluttet beskeder selvom forbindelsen til nabo var afbrudt, kræves det nu at forbindelsen skal være tilsluttet. Når router med den høje router-id går ned, registreres dette på router med den lave router-id, som derefter sender en A-meddelelse til serveren. Serveren kender hermed den korrekte status. I tilfælde af at opsfd når at registrere en tilsluttet forbindelse, men en T-meddelelse ikke kan sendes til nabo fordi forbindelsen er gået ned, bliver T-meddelelsen placeret bagest i køen, således at en A-meddelelse kan sendes til server. Dette er vist på Figur 9.4. Det ses også, at den korte oprettelse og afbrydelse derpå ikke bliver registreret, da disse meddelelser ender med at blive Side 28 TNSSR

29 ignoreret. Figur 9.4: En T-meddelelse placeres bagest i køen hvis den ikke kan sendes til nabo. Hermed kan en afbrydelse indrapporteres til server. Med den valgte løsning introduceres en ny forsinkelse for T-meddelelser, da de nu skal sendes gennem en naborouter. Denne forsinkelse afhænger af hvor tit naboen sender meddelelser til server. Der er blevet valgt en standard værdi på 10 sekunder, hvilket giver en gennemsnitlig forøgelse på 5 sekunder. I det samlede billede hvor kravet er 5 minutter betyder denne forsinkelse ikke ret meget. Den valgte løsning opsummeres i den følgende pseudokode: gentag { find ændringer for (alle ændringer) { hvis (dette router-id er lavest og forbindelse er tilsluttet) { send meddelelse til nabo hvis (meddelelse er nået frem til nabo) fjern meddelelse; ellers placer bagest i køen; } hvis (forbindelse er afbrudt) { send meddelelse til server hvis (meddelelse er nået frem til server) fjern meddelelse; } } } Pseudokode 9.1: Pseudokode for TNSSR. Ud fra analyse af de forskellige valgmuligheder der er til at detektere en forbindelsesændring, og gennem grundige overvejelser over hvordan meddelelser skal indrapporteres til server, udarbejdet en pseudokode til hvordan software skal fungere. I det næste afsnit beskrives hvordan de forskellige dele af software er designet og implementeret. TNSSR Side 29

30 10 Design og implementering af TNSSR I analysen blev der beskrevet de to hovedfunktionaliteter som TNSSR skal foretage. Det er hermed naturligt at TNSSR består af to dele som er uafhængige af hinanden, men kommunikerer internt i programmet. Dette afsnit omhandler design og implementering af de to dele af softwaren Valg af programmeringssprog Den del af TNSS software der afvikles på serveren ønskes at være platformuafhængig da Swarco Techonology afvikler deres software både på Windows og Linux server, derfor er softwaren skrevet i Java. Samme valgmulighed har gruppen ikke til routerene, da Swarco Techonology ikke ønsker at Java programmer skal afvikles på dem. På routerne afvikles Swarco Linux11, og den software der udvikles til routere af Swarco Techonology bliver derfor normalt skrevet i C og C++, så derfor står valgmuligheden mellem de to programmeringssprog. Da der ikke skal skrives direkte til hardware i TNSSR, er det oplagt af benytte et sprog der giver et højere abstraktionsniveau, derfor vælges C++ frem for C Kildekode inddeling Den ene af TNSSR's to dele står for indrapportering af meddelelser til serveren. I analysen kom gruppen frem til at routere også skal kommunikere indbyrdes når en tilsluttet forbindelse skal indrapporteres. For overskueligheds skyld inddeles denne del derfor i to source-filer, en der indeholder kildekode til at sende meddelelser, og en til at modtage meddelelser. Den anden del af softwaren som står for overvågning af forbindelser er også inddelt i to source-filer, hvor den ene indeholder kildekode til at hente data fra opsfd og finde ændringer, og den anden til at sammensætte meddelelser. En samlet oversigt over alle source-filer er vist i Tabel Navn Funktionalitet tnssr_main.cc Opstart af TNSSR. Sammesætter en meddelelse til serveren, når en ændring er registreret. tnssr_ospfd.cc Henter en liste over de nuværende naboer fra ospfd. Analyser denne liste og finder ændringer. tnssr_out.cc Sender meddelelser. tnssr_in.cc Modtager meddelelser og behandler dem. tnssr_sock.cc Håndterer kommunikation på socket-niveau med andre enheder. (Lag 1 på Figur 7.1) tnssr_file.cc Læser og skriver data i en fil. tnssr_shared.cc Indeholder de globale variabler. Henter data fra konfigurationsfilen. Tabel 10.1: Oversigt over source-filer i TNSSR Trådning Det er ikke ønskeligt at kommunikation med andre routere og serveren skal forstyrre programmets centralle funktion, som er overvågning af forbindelser. Derfor afvikles programmet af 3 tråde: tråd 1 overvåger forbindelser, tråd 2 sender meddelelser, og tråd 3 modtager meddelelser og behandler dem. Trådene kommunikerer indbyrdes ved brug af en meddelelseskø. Når en ændring registreres i tråd 1, opbygger tråden en meddelelse der skal indmeldes med de nødvendige informationer, og placerer den derefter i køen. Tråd 2 kontrollerer regelmæssigt om der er meddelelser i køen, og hvis der findes en, finder tråden ud af hvilken host meddelelsen skal sendes til, og forsøger derefter at 11 Modificeret Linux 2.6 kerne. Side 30 TNSSR

31 sende meddelelsen. Tråd 3 modtager en meddelelse fra en nabo router, modificer den så serveren bliver dens næste destination og til sidst placer den i køen. Et flowdiagram der giver et generelt overblik over programmets funktionalitet er illustreret på Figur Figur 10.1: Flowdiagram over TNSSR 10.4 Køer Meddelelser skal persistensgøres således at de ikke forsvinder hvis routeren går ned. Derfor implementeres en kø-struktur, hvor meddelelser bliver gemt i en fil i routerens non-volatile hukommelse. Filen placeres i samme mappe som programmet bliver afviklet fra. Da alle tre tråde gerne vil tilgå filkøen, skal den beskyttes med en semafor. Til dette formål benyttes semaforer fra POSIX, et API som er specificeret af IEEE standarder12, og som bl.a. kan afvikles af Linux TNSSR Side 31

32 Det har også været et ønske fra Swarco Techonogy at meddelelser skal gemmes i POSIX message queue, således at andre programmer også kan modtage informationer om forbindelser der ændrer deres status. POSIX message queue er en kø der håndteres af operativsystemet. Andre programmer kan tilgå den ved blot at angive køens navn. Message queue skal have en maksimal størrelse, og denne er valgt til være 100. Eftersom der ikke kan placeres nye meddelelser når den er fuldt op, fjernes halvdelen af meddelelserne for at give plads til de nye. Der er til gengæld ikke lavet nogen begrænsninger på hvor stor en filkø får lov til at blive. Til forskel fra POSIX message queue, ved gruppen med sikkerhed at der bliver læst fra filkøen, og derfor får den ikke lov til at vokse uafbrudt Registrering af ændringer Den algoritme der finder ændringer i forbindelsesstatus vil nu blive præsenteret. Som input får den en gammel liste over routere og en ny liste over routere. Ved at sammenligne de to lister, skal den finde nye og manglende routere, og gemme dette i en liste over ændringer. Disse lister implementeres som objekter af structs, da de bl.a. skal indeholde felter som router-id og interface IP. Eftersom de ikke skal tilbyde nogen funktioner, vælges struct frem for klasse strukturen. To løkker skal programmet løbe igennem for at finde ændringer. I den første af dem skal der findes hvilke routere der er tilføjet, og i den anden hvilke routere der mangler. Dette kan ikke gøres samtidigt, for i virkeligheden søges der først efter hvilke routere der mangler i den gamle liste, og derefter hvilke routere der mangler i den nye liste. Begge løkker består faktisk af en ydre og en indre løkke. Hver router, der skal findes (ydre løkke), skal sammenlignes med hver tilgængelig router (indre løkke). Hvis routeren ikke findes, er der sket en ændring. Eftersom ændringer skal gemmes i de eksisterende objekter, benyttes funktioner strcat fra string.h, så det er teksten fra inputlister der flyttes, og ikke referencen. Objektet bliver først nulstillet ved at sætte den første bit til '\0' Dette er nødvendigt, da strcat tilføjer tekst til objektet, derfor skal den cleares før informationer kan gemmes. int find_changes(neigh *neigh_c, neigh * neigh_u, int neigh_c_count, int neigh_u_count, r_status* change){ int length = 0; bool match; //search for new connections for (int i = 0;i < neigh_u_count; i++) { //connection from new set match = false; for (int j = 0;j <neigh_c_count; j++) { //can i find it in old? if(memcmp(neigh_c[j].router_ip,neigh_u[i].router_ip,ip_size)==0) { match = true; break; } } if(!match) { // = no = save it in change[] change[length].router_id[0] = '\0'; strcat(change[length].router_id,neigh_u[i].router_id); change[length].router_ip[0] = '\0'; strcat(change[length].router_ip,neigh_u[i].router_ip); change[length].home_ip[0] = '\0'; strcat(change[length].home_ip,neigh_u[i].home_ip); change[length].status = true; save_router(change[length].router_ip, change[length].router_id,change[length].home_ip); length++; } } //search for missing connections for (int i = 0;i < neigh_c_count; i++) { //connection from old set match = false; Side 32 TNSSR

33 for (int j = 0;j <neigh_u_count; j++) { //can i find it in new? if(memcmp(neigh_u[j].router_ip,neigh_c[i].router_ip,ip_size)==0) { match = true; break; } } if(!match) { // = no = save it in change[] } } return length; } Kildekode 10.1: Algoritme der finder ændringer i forbindelsesstatus Der skal angives en sti til konfigurations filen, som en parameter til programmet. Ved analyse af software på Swarco Linux er der blevet erfaret at konfigurationsfiler og eksekverbare filer ikke befinder sig i samme mappe, så for at følge dette, er stien ikke hard-coded. Derudover kan man angive at programmet skal afvikles i daemon-mode, med en parameter -d. Hermed bliver programmet afviklet i baggrunden, ligesom de andre programmer der afvikles på routere. Dette beskrives yderlige i det efterfølgende afsnit Indmelding af meddelelser For at hente data fra ospfd, oprettes der først en socket forbindelse til localhost på port Dette gøres internt på routeren for ikke at skabe ekstra netværkstraffik. Et andet portnummer kan angives i konfigurationsfilen, hvis standardporten for ospfd ikke benyttes. Der sendes en loginkode og hvis den er korrekt, er forbindelsen oprettet. Først hentes routers router-id, dette sker kun under opstart da router-id er statisk. Som beskrevet tidligere, bliver router-id benyttet til at beslutte hvilken router der skal sende en tilsluttet meddelelse. Derefter kan naboer hentes med show ip ospf neighbor, hvor der udrages naboens router-id, dens interface IP, og den lokale interface IP til naboen. Når der sker en ændring bliver disse informationer brugt til at opbygge en meddelelse, der kan se ud som: 1M :29:18 I tabellen herunder følger en forklaring af opbygningen af meddelelsen: 1 M :29 0 hvis denne router har et højere router-id. 1 hvis denne router har et lavere router-id. N hvis meddelelsen skal sendes til nabo. M hvis meddelelsen er modtaget fra nabo og er modificeret til at sendes til server. S hvis meddelelsen skal sendes direkte til server. Interface IP på den vedrørende forbindelse på denne router. Denne routers router-id. Interface IP på den vedrørende forbindelse på nabo router. Nabo router-id. 0 hvis forbindelse er afbrudt. 1 hvis forbindelse er tilsluttet. Dato og tidspunkt. Tabel 10.2: Indhold af en meddelelse 10.7 Sockets Der bliver oprettet tre socketforbindelser: en kilentsocket til at sende forespørgsler og hente data fra ospfd, en klientsocket til at sende meddelelser, og en serversocket til at modtage meddelelser. For at den centrale server kan modtage alle meddelelser er dens socketforbindelse sat op som en TNSSR Side 33

34 serversocket. Når meddelelser skal modtages på routeren, er det routeren der er server i datakommunikationenen, da den accepter tilslutninger fra dens naboer. Server sockets er indstillet til at kunne acceptere tilslutninger fra flere klienter, for selvom meddelelser bliver overført rigtigt hurtigt, er der risiko for at flere routere sender deres meddelelser til den ene nabo samtidigt. Figur 10.2: Oversigt over socketforbindelser. 11 Deployering af TNSSR I dette afsnit beskrives hvordan TNSSR kan deployeres på Swarco Technology's rutere. Det er ikke den endelige fremgangsmåde, da deployeringen sandsynligvis skal integreres med deployering af den eksisterende software. Formålet med dette afsnit er at vise at udviklingsarbejde ikke kun har handlet om at udvikle den kildekode der skal afvikles af programmet, men at der også blevet foretaget analyse, og lavet bash programmering i forbindelse med deployering af TNSSR Webinterface og opstart af TNSSR Swarco Technology har udviklet et webinterface, hvorfra konfigurationer af de forskellige services kan indstilles. Webinterfacet er lavet for at øge brugervenligheden, således at brugeren bliver fri for den konsolbaserede interaktion med routere. For at finde ud af hvordan TNSSR skal integreres med webinterfacet, har gruppen foretaget en analyse af hvordan ospfd afvikles på routerne, og hvordan den er integreret med webinterfacet. På baggrund af den analyse har gruppen valgt at TNSSR skal deployeres på samme måde som ospfd. Billede 11.1: TNSSR integreret i webinterface Side 34 TNSSR

35 På baggrund af den bash-fil hvorfra zebra og ospdf kan startes, stoppes og genstartes er der udarbejdet en bash-fil til TNSSR, som tilbyder de samme services13. TNSSR startes med følgende bash-kommando, som er inspireret af bash-kommandoen til at starte ospfd: /usr/sbin/tnssr -d -f /etc/tnssr.conf Parameter -d gør at tnssr starter i dameon mode, -f indikerer at stien til konfigurationen følger som den næste parameter. For at kunne ændre konfigurationsfilen i webinterface, skal der tilføjes en fil i /etc/packages, der indeholder navnet på bash filen i den første linje, og stien til konfigurationsfilen i den næste. Den tilføjede fil hedder tnssrp. Således er TNSSR integreret i webinterface Deployeringsscripts Der er udarbejdet to bash scripts der tilsammen deployerer TNSSR på routere. Det ene hedder remove og afvikles først. Som navnet måske hentyder, står den for at afslutte en aktiv TNSSR process på routere, og sletter alle de filer der har noget med TNSSR at gøre. Det andet script hedder deploy, og står for at overføre data gennem en Secure Copy protokol (SCP). Et uddrag af scriptet er vist i Kildekode IP adresser på de routere, hvor TNSSR skal deployeres, angives i en array på første linje. routers=(' ' ' ' ' ' ' ' ' ') # get number of elements in the array ELEMENTS=${#routers[@]} for (( i=0;i<$elements;i++)); do sudo scp ~/workspace/tnssr/tnssr root@${routers[${i}]}:/usr/sbin done Kildekode 11.1: Uddrag af bash-script til deployering af TNSSR Eftersom det er vigtigt at systemet kan deployeres på routere uden at der kan opstå fejl, bliver alle de forskellige deployerings scenarier gennemtestet, og beskrives i næste afsnit. 13 Programmet ospfd bliver afviklet fra /usr/sbin/, og dens konfigurationsfil ospfd.conf ligger i /etc/ mappen. Det samme bliver derfor gældende for filerne tnssr og tnssr.conf. I /etc/init.d/user-appl-available.d/ ligger en fil 25_router, som er en bash fil, hvorfra zebra og ospfd kan startes, stoppes og genstartes. Startsekvensen bliver eksekveret under opstart af routerne. Stærkt inspireret af denne bash fil, er der blevet udarbejdet 44_tnssr, der tilbyder de samme services. TNSSR Side 35

36 12 Test af TNSSR For at sikre at den udviklede løsning er af en høj kvalitet, hvilket vil sige at programmet ikke bare tjener sit formål men også opfører sig stabilt under stresssituationer, er der i løbet af projektperioden blevet lagt stor vægt på at teste TNSSR, for at udrydde alle de fejl der kunne findes Ekstern påvirkning Hvis det overvejes hvilke typer af fejl der kan opstå, kan disse inddeles i to områder. I det første område findes alle de fejl der opstå som følge af noget eksternt input som programmet kan blive påvirket af. Som følge af disse input, genererer programmet noget output, der kan sammenlignes med de forventede resultater. Hvis de ikke stemmer overens, har programmet udført en funktionsfejl. Disse fejl fanges ved en funktionstest som foretages på baggrund af en testcase der udarbejdes før testen. Denne testcase indeholder alle de forskellige scenarier for input som er værd at teste, samt det forventede output. Under testen registreres det reele output, og hvis der er forskel, foretages der analyse af hvad der kunne medvirke til et forkert output. Efter alle fejl er rettet, udføres testen en gang til for at sikre at rettelser ikke har medført til nogle nye fejl. Der er tre forskellige former for input til TNSSR: Forbindelsesændringer (afbrydelse og tilslutninger). Strømafbrydelse, hvor en router går ned. Deployering af systemet. Ved forbindelsesændringer bliver følgende testet: De simple afbrydelser og tilslutninger. Dette skal vise at den overordnede funktionalitet er korrekt. Afbrydelser og oprettelse af flere forbindelser samtidigt. Dette er en stressende situation for både ospfd og TNSSR. Herunder hvad der sker hvis alle forbindelser mistes til serveren. Korte og lange forbindelsesafbrydelser. For at simulere en strømafbrydelse slukkes der for en eller flere routere. Naborouterne skal selvfølgeligt indrapportere en afbrudt forbindelse. Derudover bliver der testet: Efter opstart skal routere med en lavere router-id indrapportere en tilsluttet forbindelse. Om persistensgørelse af meddelelser virker på de routere der slukkes. Routere tændes/slukkes en efter en. Korte og lange strømafbrydelser. Til sidste men ikke mindst er det også vigtigt at sikre at systemet starter korrekt efter deployering, og at deployeringen ikke medfører at routerne går ned. Det følgende blev testet: De udviklede scripts til deployering. Routere melder korrekt meddelelser ind når alle routere genstartes, eller når routere genstartes en ad gangen efter deployering. Delvis deployering. Deployering mens nogle forbindelser er afbrudt. Genstart af programmet uden genstart af selve router. I den første funktionstest blev der fundet nogle enkelte fejl. Efter at de blev rettet, blev funktionstesten gennemført en gang til, denne gang uden nogen fejl. Side 36 TNSSR

37 Den udviklede testcase med de endelige resultater er dokumenteret i projektjournalen Test af TNSSR som er vedlagt på Cd'en. Testopstillingen er vist på Figur 12.1, og det skal bemærkes at den indeholder redundans for at simulere en autentisk router intranet. Figur 12.1: Den anvendte testopstilling der indeholder redundans. Billedet er fra Cisco's Packet Tracer, hvor testopstillingen blev anvendt til analyse af routernes opførsel på diverse ændringer Intern påvirkning Det andet område af fejl består af dem der opstår uden en ekstern påvirkning. Blandt dem hører: Programmet har udført en ulovlig handling, det kan f.eks. være hvis programmet forsøger at skrive i en utilgængelig hukommelse. En memory leak, fordi programmet allokerer nye ressourcer uden at disse bliver frigivet efter brug. Programmet går i deadlock. Fejl fra dette område er svære at opspore, da de ikke kan fremprovokeres ved noget input. Der kræves nogle avancerede værktøjer der kan opspore en abnorm ressourcerforbrug, hvilke gruppen ikke har kendskab til. En anden måde at finde disse fejl på, er ved at lade programmet afvikles over en længere tidsperiode, til programmer fryser eller går ned. En såkaldt 24-timers test, hvor programmet afvikles over et døgn er blevet foretaget. Denne test var succesfuld, idet at der blev fundet en fejl. Det viste sig at socket forbindelsen ikke blev lukket ordenligt, og da der er en begrænsning på hvor mange sockets et program kan få allokeret af styresystemet, resulterede dette at programmet frøs. Efter denne fejl blev rettet, kom der ikke flere fejl i en ny 24-timers test. Faktisk har gruppen ladet routere afvikle TNSSR i 3 uger i slutningen af projektperioden, uden at der blev fundet nye fejl. De tests hvor programmet afvikles på routere, hører under dynamisk kvalitetskontrol. En anden måde at teste software på er at foretage en statisk kvalitetskontrol. I praksis gik det ud på at gruppen foretog et review af det kode der blev udviklet til TNSSR, hvor nogle forskellige områder blev diskuteret og rettet, således at koden blev optimeret. I slutningen af projektperioden foretog gruppen en accepttest med Swarco Technology, hvor hele systemet blev vist frem. I den forbindelse har Swarco Technology's udviklere foreslået en tilføjelse til TNSSR, der beskrives i næste afsnit. TNSSR Side 37

38 13 Udvidelser af TNSSR En udvidelse af TNSSR som Swarco Technology har foreslået er en overvågning af selve programmet på routere. Dette kan ske ved at programmet periodisk sender en meddelelse til serveren at det er kørende, eller at serveren selv forespørger programmet om dette. Hvis der også er andre programmer der skal overvåges på routere, kan det samlet set generere en del netværkstrafik, hvilket kan blive ret problematisk. En løsning til overvågning af TNSSR skal derfor nøje overvejes. Hvis andre programmer også skal overvåges, er det måske bedst at lave et ny program der overvåger andre programmer på routeren og indrapporter hvis der sker en fejl. For at gøre TNSSR fleksibelt, er det ikke programmet selv der skal indrapportere, den skal forespørges. Således kan forespørgsler komme både fra serveren, eller internt på routeren fra et andet program. 14 Konklusion for TNSSR Denne sektion omhandlede programmet TNSSR, som skal afvikles på de enkelte routere. Modulets overordnede krav er at detektere en forbindelsesafbrydelse ved brug af så få netværksressourcer som muligt, og indrapportere afbrydelsen til en server. Ved at analysere de forskellige valgmuligheder der er til rådighed for at detektere en afbrudt forbindelse, og ved at analysere de måder hvorpå en meddelelse kan indrapporteres til serveren, er det lykkedes at udvælge de metoder der tilsammen løser problemet bedst muligt, set fra gruppens synspunkt. Den valgte løsning blev designet og implementeret i C++, og for at sikre at det udviklede program af en høj kvalitet, har test af software spillet en væsentlig rolle i udviklingsperioden, hvor programmet har været igennem en black-box-test af eksterne påvirkninger, en langvarig afviklingstest, accepttest og der blev foretaget en review af den udviklede kildekode. Det kan hermed konkluderes at TNSSR er i stand til at indmelde forbindelsesændringer til serveren. Disse ændringer behandles af TNSSS modulet, som beskrives i næste sektion. Side 38 TNSSR

39 TNSSS Dokumentation for TNSS-Server

40 15 Indledning til TNSSS Denne sektion omhandler udviklingen af den midterste del af TNSS, TNSSS. Denne del af systemet er central, da den skal tage sig af modtagelsen af meddelerne fra TNSSR samt persistensgørelse af disse infomationer. Ydermere skal TNSSS stille et API til rådighed for TNSSW, og andre applikationer som i fremtiden ønsker at anvende data om netværket. TNSSW skal blandt andet udhente infomationer fra API'et, som skal benyttes til den grafiske præsentation af trafikreguleringsnetværket. Swarco Technology ønsker at TNSSS skal være fleksibel i forhold til at kunne anvende forskellige databasetyper14. Samtidig skal modulet kunne udvides til på et senere tidspunkt at kunne understøtte flere databasetyper ad gangen. Der vil derfor i udviklingen af TNSSS blive lagt særligt vægt på at lave databasetilgangen så fleksibelt som muligt. Overordnet havde Swarco Technology følgende krav, som har væsentlig indvirkning på udformningen af TNSSS. Den første tabel er uddrag fra kravmodellen og den sidste er et uddrag fra risikoanalysen: Funktionelle krav TNSSS ID Type FA13 Logning Detaljer Særlige forhold MoSCoW - Should Særlige forhold MoSCoW - Must TNSS skal gøre det muligt for operatøren at se alle tidligere fejl og ændringer som systemet har været underlagt. Ikke-funktionelle krav TNSSS ID Type KA03 Persistens Detaljer TNSS skal anvende en SQL-baseret database til logning af ændringer i netværket osv. Tabel 15.1: Uddrag af de vigtigste fra kravmodellen. Kvalitetsscenarium Påvirkning Faktor Succes- Risiko prioritet Vedligeholdelseskriterier: Snitflader mellem TNSS moduler. Systemet skal have klart definerede Det vil blive svært at udvikle på systemet snitflader mellem software sener og dermed også at tilpasse det ind i moduler. andre systemer som Swarco ønsker Modificering TNSS moduler skal være løst af systemet. koblet til hinanden således at de nemt kan udskiftes med andre. Hvis modulerne ikke kan udskiftes med andre, vil systemet ikke være brugbar til videreudvikling. Høj Høj Høj Høj Tabel 15.2:Uddrag fra risikoanalysen. På baggrund af de beskrivende krav vil der i næste afsnit være en analyse der beskriver hvordan det er muligt at opbygge TNSSS. 14 Herunder har Swarco Technology bland andet nævnt MySQL Server 5.1 og MS SQL Server Express 2008 R2. Side 40 TNSSS

41 16 Analyse af TNSSS I dette afsnit gennemgås overordnet analysen af TNSSS. Der vil i afsnittet blive redegjort for de funktionaliteter TNSSS skal udføre. TNSSS skal grundlæggende stå for administrationen af informationen i systemet. Delen har til opgave at indlæse de fejlbeskeder der genereres af TNSSR og derefter behandle disse. Behandlingen af fejlbeskederne indebærer en persistensgørelse af informationen, samt funktioner til at stille denne information til rådighed for andre softwaremoduler. Da hele TNSS skal bestå af løst koblede monduler er det oplagt at udvikle et API til det midterste modul, hvor der dermed er muligt at tilgå information omkring trafiknetværkets status. Det har samtidig været et ønske fra Swarco Technology at projektgruppen udvikler et API til systemet, hvormed informationen som TNSS indsamler vil kunne anvendes i Swarco Technology's egne softwaremoduler. Ovenstående analyse leder frem til følgende figur som illustrerer funktionaliteterne i TNSSS: Figur 16.1: Opbygning af TNSSS. Som det fremgå af figuren er muligt at tilkoble eksterne softwaremoduler til TNSSS, idet der defineres et API til modulet. TNSSW benytter det definerede API til en grafisk præsentation af trafikreguleringsnetværket, men man kan forestille sig at det kunne være relevant at overveje at udvikle moduler til for eksempel at administrere brugere eller til at tilføje og fjerne routere i systemet. Udviklingen af TNSSW beskrives i næste sektion. Der medtages desuden fra analysen, at TNSSS skal tilgå en eksisterende database med brugeroplysninger, herunder brugernavn og adgangskode, samt en database med informationer om routere. Dette får indflydelse på hvordan databasemondulet skal designes og implementeres. TNSSS Side 41

42 17 Design af TNSSS Herunder gennemgås designet af TNSSS foretaget på baggrund af den indledende analyse. Der vil i afsnittet blive lagt vægt på opdelingen af softwarearkitekturen samt givet et overblik over designklassediagrammet for TNSSS. Som beskrevet i analysen udvikles et API til TNSSS der giver mulighed for at data fra databasen kan tilgås af eksterne softwaremoduler. Hermed er det muligt at udvikle en applikation med en specifik funktionalitet og koble denne på TNSSS, hvormed alle informationer omkring netværkets forbindelser bliver tilgængelige. Tilføjelsen af et modul til TNSSS fungerer dermed som en udvidelse af applikationskernen af TNSSS. På figuren herunder er angivet de anvendte distributionsmønstre for TNSSS. Som det ses at figuren anvendes samtidig mønsteret remote database, idet TNSSS skal fungere sammen med de eksisterende databaser: Figur 17.1: Illustration af distributionsmønstre anvendt ved TNSSW.15 Ved anvendelsen af distributed application kernel opnås stor fleksibilitet i TNSS, da det er muligt for Swarco Technology på et senere tidspunkt at konstruere separate softwaremoduler til specifikke opgaver og tilkoble disse til TNSSS, uden at skulle foretage ændringer i TNSSS. På baggrund af Figur 17.1 samt den anvendte distribution af TNSSS udarbejdedes et designklassediagram over opbygningen af TNSSS. Projektgruppen har valgt at anvende PCMEF16 arkitekturframeworket til strukturering af softwaren. Ved anvendelsen af PCMEF opnås en hierarkisk lagdeling af softwaren som gør det nemt af foretage vandrette snit igennem strukturen. Dette er en fordel i forbindelse med definitionen af API'et, idet der kan tilføjes moduler til den samlede software uden af det går ud over softwarestrukturen. En forenklet udgave af designklassediagrammet for TNSSS kan ses på figuren herunder: 15 Figur udarbejdet på baggrund af kilde 10 side PCMEF står for Presentation, Control, Entity, Mediator og Foundation og er en fremgangsmåde til at inddele softwaren i pakker som håndterer forskellige funktionaliteter fra henholdsvis brugerinteraktion (presentation) til kontakt med eksterne enheder (foundation). For mere information om PCMEF se evt. Kilde 3, side 415. Side 42 TNSSS

43 Figur 17.2:Desingklassediagram for TNSSS. Som det ses af figuren indeholder TNSSS Foundation- og noget af Mediator-laget. Det er dermed muligt med et eksternt modul at tilføje de øvre lag af PCMEF-strukturen. Dette vil blive demonstreret i udviklingen af TNSSW. På designklassediagrammet er der ud over de klasser som håndterer de overordnede funktionaliteter i TNSSS, tilføjet to klasser til kommunikation med filer. Dette skyldes at der i TNSSS indbygges en automatisk backup-funktion, som sørger for at gemme beskeder fra TNSSR lokalt i tilfælde af at databasen ikke skulle være tilgængelig. Hermed kan systemet stadig fungerer selvom databasen er offline. Derudover er der tilføjet filer til at indeholde log over eventuelle fejl som skulle opstå i systemet, samt til at indeholde systemindstillinger for TNSSS. Systemindstillinger dækker blandt andet over stien til databasen samt indstillinger for API'et. TNSSS Side 43

44 18 Implementering af TNSSS I dette afsnit beskrives implementering af TNSSS. Afsnittet er på baggrund af analysen inddelt i tre underafsnit omhandlende hver af de tre overordnede funktionaliteter som TNSSS skal udføre Indlæsning af data fra routere, tilgang til databaser og tilbydelse af API. Der vil i afsnittet blive gået i detaljer med de anvendte tekniske løsninger samt blive begrundet hvorfor de givne løsningerne er valgt Indlæsning af data fra routere Herunder beskrives hvordan fejlmeddelelser sendt fra routerne indlæses i TNSSS. Fejlmeddelelserne afkodes i TNSSS, hvorefter informationen kan persistensgøres og udsendes på API'et. Som beskrevet i forgående sektion forsøger TNSSR at oprette en socketforbindelse ind til serveren, for at kunne sende fejlmeddelelsen. Klassen FSocketCommunication skal derfor være i stand til at håndtere disse forespørgsler og indlæse meddelelserne fra routerne. For hele tiden at være i stand til at indlæse beskeder fra routerne er FSocketCommunication implementeret i sin egen tråd, som ikke laver andet end at acceptere udefrakommende forespørgsler. Klassens run-metode er gengivet herunder: public void run() { try { ServerSocket srvr = new ServerSocket(inPort); System.out.println("Socket listener running"); while(true){ Socket skt = srvr.accept(); BufferedReader in = new BufferedReader(new InputStreamReader(skt.getInputStream())); try { handlemessage(in.readline()); while (in.ready()) { handlemessage(in.readline()); } } catch (SocketException e) { errorlog.addlinewithtime( "Socket exception on " + skt.getremotesocketaddress()); } in.close(); skt.close(); } } catch (IOException e) { errorlog.addlinewithtime( "TERMINATED: IO exception in socket listener"); System.exit(1); } } Kildekode 18.1: run-metode i FSocketCommunication som håndterer indkomne forespørgsler fra routerne. Side 44 TNSSS

45 Som det ses af ovenstående kildekode venter TNSSS på at kunne acceptere indgående forespørgsler idet linjen: Socket skt = srvr.accept(); blokerer indtil en klient forsøger at oprette forbindelse til serveren. Når en router har opnået forbindelse til serveren indlæses og håndteres de linjer TNSSR sender til serveren. Normalt sendes kun en linje af gangen, men der er i implementeringen af TNSSS taget højde for at routerne skulle sende flere linjer i tilfælde af at TNSSR bliver udvidet. De modtagede beskeder håndteres med metoden handlemessage. I kildekode 18.1 fremgår desuden anvendelsen af errorlog, som er af typen FFileCommunication. Med dette objekt er det muligt at tilføje beskeder til loggen over fejl, i tilfælde af at der skulle opstå problemer med indlæsningen fra den pågældende socket. De beskeder der indlæses fra TNSSR, har i henhold til afsnit 10.5, Indmelding af meddelelser, følgende syntaks: ## interfaceip1 routerid1 interfaceip2 routerid2 status tid Hvor et eksempel på en besked er angivet herunder: 1M :37:0 Det er derfor nødvendigt at afkode disse beskeder for at udtrække de relevante data, henholdsvis de to interfaces, de to routere, status for forbindelsen samt tiden da ændringen blev registreret. Til afkodning af denne teststreng anvendes regular expressions, som er en simpel og fleksibel måde til at afkode tekststrenge på. Regular expressions kan desuden anvendes i Java, ligesom mange andre programmeringssprog understøtter metoden. Ved anvendelsen af regular expressions defineres en mønster for opbygningen af tekststrengen. Matcher den pågældende tekst det definerede mønster er det derefter muligt at udtrække dele af teksten. Et mønster som beskriver en IP-adresse ser ud som følger: \\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3} Som oversat giver tre grupper af tal på 1 til 3 cifre adskilt af punktummer. I kildekoden herunder er angivet hvorledes der i Java defineres et mønster for meddelelserne sendt fra TNSSR, hvorefter mønsteret anvendes til at kontrollere om beskederne har den definerede opbygning: private String ipp = "\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}"; private String ts = "\\d{4}-\\d{1,2}-\\d{1,2} \\d{1,2}:\\d{1,2}:\\d{1,2}"; private Pattern pattern = Pattern.compile("[0-1][A-Z]+ +(" + ipp +") +" + "(" + ipp +") +(" + ipp +") +" + "(" + ipp +") +([0-1]) +(" + ts + ")"); private void handlemessage(string message) { if (message!= null) { Matcher matcher = pattern.matcher(message); if (matcher.matches()) { Kildekode 18.2: Eksempel på anvendelsen af regular expressions til afkodning af beskeder. Ved herefter at kalde funktionen matcher.group(#) er det muligt at udtrække de grupper der i mønsteret er angivet i parentes. Kaldet matcher.group(1) returnerer dermed det første interface. Det er hermed muligt at udtrække det ønskede data fra beskederne sendt fra TNSSR således at beskeden kan behandles videre i systemet. Behandlingen af beskeden beskrives i de efterfølgende underafsnit. TNSSS Side 45

46 18.2 Tilgang til databaser I dette afsnit gives et kort overblik over de konstruerede databaser som TNSSS benytter, og der redegøres for implementering af databasetilgangen. Eftersom databasetypen kan variere på de enkelte servere, skal tilgangen være fleksibel for at der ikke skal foretages ændringer i softwaren ved deployering. Meddelelser som TNSSS modtager fra TNSSR skal gemmes i en database. Til dette formål har gruppen designet databasen TNSS, som vist på Figur TNSS er en relationel database, der består af tre tabeller: connection indeholder informationer om hver enkel forbindelse, comment indeholder kommentarer der kan tilføjes til en forbindelse, og log indeholder informationer om alle forbindelsesændringer. TNSS indeholder ikke informationer om de enkelte routere, da projektet er afgrænset kun til at overvåge forbindelser. Men da forbindelsesændringer skal præsenteres i den grafiske brugergrænseflade, er det nødvendigt at hente nogle routerinformationer, primært deres koordinater. Swarco Techonology har oplyst at der eksisterer en database over routere, men at den ikke er færdigudviklet endnu. Derfor har gruppen i første omgang udviklet en database over routere, ROUTERS, der indeholde de informationer som skal benyttes til den grafiske visning. Derudover er der også blevet udviklet en database USERS der indeholder informationer over de enkelte brugere der anvender systemet. Figuren herunder giver et overblik over opbygningen af databaserne: Figur 18.1: Oversigt over de tre databaser som TNSSS tilgår. Side 46 TNSSS

47 Fleksibiliteten af databasetilgangen testes med to databaser: MySQL Server 5.1 og Microsoft SQL Server Express R SQL er et programmeringssprog til relationelle databaser og giver mulighed for at: Oprette, ændre og nedlægge en tabel. Udvælge, indsætte, rette og slette data i en tabel. Kontrollere brugernes adgang til database. Desværre er syntaksen lidt forskellig i de databaseprogrammer der anvender SQL, men for de mest anvendte funktioner stemmer syntaksen overens. Praktisk har gruppen erfaret at syntaksen er den samme for INSERT, UPDATE og DELETE og med disse kan databasen udføre sin arbejdsopgave. Dermed kan SQL sætninger hard-codes ind i TNSSS. Der er en lille variation i tabelnavne: f.eks. hedder det TNSS.connection i MySQL og TNSS.dbo.connection i Microsoft SQL Server. Hvis disse navne skal anvendes, skal SQL sætninger tilpasser til hver database, hvilket er upraktisk. Måden dette problem er løses på, er ved at oprette en forbindelse direkte til en bestemt database. Hermed kan tabelnavnet angives uden databasenavnet. Dette betyder at der skal oprettes en forbindelse til den ønskede database hver gang en SQL forespørgsel skal udføres. Det er desuden god skik ikke at have en forbindelse til en database hele tiden. Når TNSSS skal kommunikere med databasen, skal dette ske igennem en connector, der er en Java driver til databasen. Figur 18.2: Databaseforbindelse. Denne connector er unik for hver databasetype og skal inkluderes i Java projektet. Connectorens navn skal derfor omdefineres i classpath filen17. Derefter skal TNSSS have at vide hvilken klassefil (class forname) der skal anvendes fra connectoren. Dette skal angives direkte i kildekoden, men for at gøre dette fleksibelt, bliver den hentet fra en konfigurationsfil. For at lette forståelsen ses herunder et udklip af konfigurationsfilen som gruppen har udviklet til TNSSS: database database database database address jdbc:mysql:// :3306/ class forname com.mysql.jdbc.driver user TNSS password TNSS Tabel 18.1: Udklip af settings.conf. TNSSS er i udklippet indstillet til at forbinde til en MySQL server. 17 For at indstille denne, skal jar-filen åbnes med et pakke program, f.eks. WinRar, og navnet på connectoren skal ændres i filen MANIFEST.MF. Dermed tilføjes connectoren til projektet. TNSSS Side 47

48 18.3 TNSSS API Formålet med dette underafsnit er at give et overblik over det udviklede API til kommunikation med TNSSS applikationen. Der vil i afsnittet blive givet en generel oversigt over de tilgængelige kommandoer i API'et samt et eksempel på deres anvendelse. Herefter gives en teknisk gennemgang af implementeringen af API'et. API'et tilbyder på nuværende tidspunkt mulighed for at udlæse data omkring trafiknetværkets status i henhold til de i inceptionen definerede krav. Der er som tillæg til disse funktionaliteter samtidig tilføjet kommandoer til at håndtere tilføjelsen og fjernelsen af routere i systemet, selvom det på nuværende tidspunkt ikke anvendes i TNSSW. Dette skyldes at der allerede er taget højde for at teknikeren skal kunne oprette routere manuelt. Derudover forefindes en muligheden for at abonnere på beskeder om de ændringer som netværket udsættes for, samt funktioner til administration af brugeradgang til systemet. API'et er implementeret således at en klient kan oprette en socketforbindelse ind til TNSSS. Hermed er det muligt for klienten at angive kommandoer bestående af tekststrenge afsluttet af et linjeskift18, og serveren returnerer herefter et svar, som ligeledes består af en række tekststrenge indeholdende den ønskede data. En oversigt over implementerede funktioner i API'et er angivet i tabellen herunder: Funktion: Kommando: API oversigt help Kontroller login checklogin -u username -p password Tilføj bruger adduser -nu newusername -np userpassword -pr privileges -u username -p password Slet bruger deleteuser -du usertodelete -u username -p password Oplist brugere listusers -u username -p password Modtag ændringer recievemessages Tilføj router addrouter -id routerid -lat latitude -lng longitude -u username -p password Slet router deleterouter -id routerid -u username -p password Oplist routere listrouters Tilføj interface addinterface -id routerid -i interface -u username -p password Slet interface deleteinterface -id routerid -i interface -u username -p password Oplist interfaces listinterfaces Slet forbindelse removeconnection -id connectionid -u username -p password Oplist forbindelser listconnections Ændr forbindelseskoordinater changecoordinates -id connectionid -c coordinatestring -u username -p password Hent forbindelsesinformation getconninfo -id connectionid Hent log getlog [-p sortparameter] Tilføj kommentar addcomment -id connectionid -c comment Slet kommentar deletecomment -id commentid -u username -p password Hent kommentarer getcomments -id connectionid Tabel 18.2: Oversigt over API defineret for TNSSS. 18 Med linjeskift menes et Line Feed: 0x0A (ASCII). Side 48 TNSSS

49 API'et er på nuværende tidspunkt sat til at anvende port 4444, og kan tilgås ved at anvende telnet ind til serveren: telnet serverip 4444 Når forbindelsen er oprettet kan kommandoer som nævnt angives som enkeltstående tekststrenge. Til test af API'et er der desuden konstrueret en konsolbaseret testklient.. Klienten blev anvendt under den løbende test af API'et samt under den mere omfattende kvalitetskontrol der er foretaget til sidst i forløbet, som beskrevet i afsnit 29. Testklienten er vedlagt på Cd'en under kildekode. Et eksempel på anvendelsen af API'et til tilføjelse af en kommentar til en forbindelse, er angivet herunder. Kommando: addcomment -id C0A80704C0A c Forbindelsen er ofte offline Svar: Ved korrekt tilføjelse af kommentar: Comment added Denne specifikke funktion tænkes anvendt til den indbyrdes koordination mellem operatørerne, idet det f.eks. er muligt at angive status for udbedringen af en afbrudt forbindelse. Serveren er implementeret flertrådet for at kunne håndtere flere klienter på samme tid, og opretter således en ny tråd hver gang en klient opretter forbindelse til serveren. Dette sker i klassen SocketFactory, som ligeledes afvikles i sin egen tråd. Klassen er gengivet herunder: private class SocketFactory implements Runnable { private Socket clientsocket; private ServerSocket serversocket; public SocketFactory(ServerSocket serversocket) { this.serversocket = serversocket; } public void run() { try { while (true) { clientsocket = serversocket.accept(); new Thread(new ServerThread(clientSocket)).start(); } } catch (IOException e) { errorlog.addlinewithtime("client accept on port " + apiport + " failed."); } } } Kildekode 18.3: Klassen SocketFactory som står for at oprette tråde til klienterne. Som det ses af kildekoden venter tråden på indkomne forespørgsler fra en klient, og når der oprettes forbindelse oprettes en ny ServerThread som tildeles sin egen tråd. TNSSS Side 49

50 Klassen ServerThread minder meget i opbygning om FSocketCommunication, som er beskrevet i afsnit Kommandoer fra den pågældende klient indlæses og behandles med metoden decodecommandline, som genererer et svar som returneres. Indlæsningen af kommandoer er vist herunder: String commandline = input.readline(); if (commandline!= null) { String answer = decodecommandline(commandline); output.println(answer); Kildekode 18.4: Indlæsning og behandling af kommando fra klient. Metoden decodecommandline afkoder den angivne kommando ved hjælp af regular expressions, i stil med den måde beskeder fra TNSSR afkodes. Afkodningen og behandlingen af en addcomment kommando er gengivet herunder: private String decodecommandline(string commandline) { commandline = commandline.trim(); commandline = commandline.replace("'", "''"); String command = commandline.split(" ")[0]; Pattern pattern; Matcher matcher; String output = ""; switch (Commands.toCommand(command)) { case addcomment: pattern = Pattern.compile("[a-zA-Z]* +-id +(.*) +-c \"(.*)\""); matcher = pattern.matcher(commandline); if(matcher.matches()) { if (fdatabasecommunication.addcomment(matcher.group(2), matcher.group(1))) { output = "Comment added"; } else { output = "Command error: Could not add comment\n"; } } else { output = "Command error: Syntax\n"; output += "Use: addcomment -id connectionid" + " -c \"comment\""; } break; } return output.trim(); } Kildekode 18.5: Behandling af addcomment i decodecommandline Ud over de generelle funktioner til udlæsning af data omkring netværkets status, er der desuden som det ses af tabel 18.2, implementeret en funktion til at abonnere på beskeder fra routerne, recievemessages. Når denne besked modtages hos serveren tilføjes klienten til en liste internt på serveren. Når en besked modtages fra TNSSR broadcastes den til alle klienter i denne liste. Ved anvendelsen af denne funktion er det dermed muligt hele tiden at overvåge ændringer i netværket uden at skulle udlæse hele netværkets status. Side 50 TNSSS

51 19 Dynamisk kvalitetskontrol af TNSSS Under udviklingsforløbet er der blevet foretaget en white-box test af hver komponent der blev implementeret i TNSSS. Denne testmetode blev udført af den ansvarlige for implementeringen for at opfange de fleste fejl mens en komponent var under udvikling. For at teste den samlede funktionalitet, er der blevet foretaget en black-box test, der tester TNSSS' øverste snitflade, som er API'et. På nuværende tidspunkt tilbyder API'et 20 services, hvilket betyder at der er rigtig mange forskellige inputscenarier. Ingen af dem må medføre fejl på TNSSS og derfor skal API'et testes for mange inputscenarier, for at sikre at alle umiddelbare fejl bliver fundet og rettet. Programmets nederste snitflade modtager meddelelser fra TNSSR og da det vides, at de overholder den korrekte syntaks, er det derfor ikke nødvendigt at foretage en black-box test af den nederste snitflade. Samtidig er implementation meget lige API'et. For at automatisere testen defineres en testcaseindeholdende de scenarier der skal testes. Ud fra analyseviden om hvilket input der er korrekt, og hvilket der er forkert, er der blevet genereret testdata til testcasen. Rækkefølgen af input i testcasen er logisk opbygget for at opfange flest mulige inputscenarier. Eftersom det er rigtigt mange inputscenarier der skal testes, er det ønskeværdigt at automatisere testen. Til dette formål benyttes JUnit, som er et testframework til Java. JUnit består af nogle klasser der integreres i Java projektet. Testcasen placeres i en klasse, der arver fra TestCase. Klassen TestSuite benyttes til at organisere testcasens metoder, og invokere dem sekventielt efter hinanden. Opbygning af JUnit ses i Figur Figur 19.1: JUnit testframework med testcase til test af API'et. Anvendelse af JUnit giver mulighed for at teste stort set alle metoder i TNSSS rigtigt hurtigt. Dette har været nyttigt ved kompatibilitetstest af forskellige databaser, eftersom data forespørges fra databasen ved de fleste API kald. Der kunne hurtigt konkluderes at systemet er kompatibel med både MySQL og MS SQL Server 2008 R2 Express. Der blev fundet nogle enkelte fejl i API'et, som blev rettet og kontrolleret derefter ved at afvikle testen endnu en gang. TNSSS er dermed grundigt gennemtestet. I softwareudvikling er programmet fejlfrit indtil den næste fejl bliver fundet. Der er rigtig mange inputscenarier, og derfor er der en risiko for nogle fejl blev overset. Denne risiko vurderes dog til at være meget lille. Det skal afslutningsvis påpeges at den udviklede testcase kan anvendes til test af om andre databasetyper fungerer med TNSSS. TNSSS Side 51

52 20 Konklusion for TNSSS TNSSS kan på længere sigt udvides så der kan tilgås flere databasetyper, hvilket vil være nemt af udvide systemet med og teste med den udviklede testcase. TNSSS opfylder de stillede krav og tilbyder dermed adgang til flere SQL-baserede databaser samt garanterer at forbindelsesændringer sendes videre selvom databasen er nede. TNSSS tilbyder desuden et API som kan anvendes af andre moduler heriblandt TNSSW til en grafisk præsentation af trafiknetværket som beskrives i næste sektion. Modulet er sammen med TNSSR blevet udførligt gennemtestet, og de to dele kan derfor betragtes som et fuldstændigt og færdigt system. Det vil sige at disse dele af systemet kan derfor anses som værende klar til deployering hos Swarco Technology. Det vil på nuværende tidspunkt være meningsløst at teste TNSSS og TNSSR mere på nuværende tidspunkt, da eventuelle fejl som skulle være til stede kun vil kunne afdækkes ved at sætte systemet i drift over en længere periode. Side 52 TNSSS

53 TNSSW Dokumentation for TNSS-Web

54 21 Indledning til TNSSW I denne sektion beskrives den øverste del af TNSS, som er TNSSW. TNSSW står for den grafiske præsentation af trafikreguleringsnetværket, og skal benyttes af operatøren til at overvåge netværkets status. TNSSW skal samtidig stille information til rådighed om de enkelte forbindelser samt en log over hvilke ændringer netværket har været underlagt. Til at udlæse data om netværkets status anvendes det definerede API19 for TNSSS. TNSSW adskiller sig fra den resterende del af systemet ved at den ikke udgør en vital del af selve registreringen af netværksforbindelsernes status, og de underliggende dele af systemet er derfor ikke afhængige af denne dels funktionalitet. TNSSW er stadigvæk en væsentlig del af systemet, da det er den del der har til opgave at fremvise fejlmeddelelser til operatøren, som derefter har mulighed for at reagere på disse. Det er tanken at TNSSW på længere sigt skal blive en integreret del af det system Swarco Technology anvender til overvågning af trafikreguleringsnetværket, hvilket også betyder at det ikke er muligt på nuværende tidspunkt i processen at levere et så færdigt stykke software, som de underliggende dele af systemet ellers er. Derimod skal TNSSW demonstrere hvordan en præsentation af netværket kan foretages ved anvendelsen af det udviklede API til TNSSS. På grund af dette, er det samtidig også vigtigt at designe TNSSW således at det er muligt på en senere tidspunkt at kunne tilpasse delen specifikt til Swarco Technologys system, hvis dette er ønskeligt. Overordnet havde Swarco Technology to ikke-funktionelle krav som har væsentlig indvirkning på udformningen af TNSSW: Ikke-funktionelle krav TNSSW ID Type Detaljer KA01 Brugergrænseflade Brugergrænsefladen på TNSS skal anvende Google Maps API til visning af routere og forbindelsen mellem disse. KA02 TNSS på centralen skal kunne tilgås via en sikker forbindelse via internettet. Sikkerhed Særlige forhold Kommunikationen foregår på port 443 (TLS). Tabel 21.1:Uddrag af kravmodellen for TNSSW. Der ønskes altså en grafisk præsentation af trafikreguleringsnetværk ved anvendelse af Google Maps, som derfor skal være en integreret del af præsentationslaget af TNSSW. Derudover er det vigtigt for Swarco Technology at tilgangen til TNSSW foregår via en sikker forbindelse via internettet, hvilket har betydning for hvordan kommunikationen fra operatørens brugerinterface og ind til serveren foregår, og dermed også betydning for hvordan TNSSW kommunikerer med TNSSS. På baggrund af kravet omkring anvendelsen af Google Maps, samt de resterende krav om hvilke informationer som brugergrænsefladen skal stille til rådighed, blev der i samarbejde med Swarco Technology udviklet mockups over hvorledes TNSSW skal præsentere netværket. Mockup over visningen af trafikreguleringsnetværket og dets afbrudte forbindelser kan ses på billedet herunder. Resterende mockups over brugergrænsefladen er vedlagt i projektjournalen Design af brugergrænseflade, som forefindes på Cd'en. 19 Se afsnit 18.3 for en nærmere beskrivelse af TNSS API. Side 54 TNSSW

55 Billede 21.1: Mockup over brugergrænseflade. Der vil i denne sektion først blive foretaget en overordnet analyse af opbygningen af TNSSW, med henblik på at sikre at kravene fra Swarco Technology bliver opfyldt og samtidig fastlægge de teknologier som skal anvendes. Da dette har stor betydning for udvikling af TNSSW, bearbejdes denne del først. Herefter foretages analyse, design og implementering af delen, hvorefter der afsluttes med et afsnit der beskriver hvilke udvidelser der kan tilføjes til TNSSW. I afsnittene vil der blive lagt vægt på de teknologier der benyttes, da mange af de anvendte teknologier har været nye for projektgruppen, og da det derfor har været nødvendigt for gruppen at tillære sig disse. Det vil samtidig blive beskrevet hvilke valg der har haft indflydelse på udformningen af TNSSW. Der anvendes i denne sektion UML-notation til dokumentation af de udarbejdede artefakter under analyse og design. TNSSW Side 55

56 22 Opbygning af TNSSW I dette afsnit vil den overordnede opbygning af TNSSW blive beskrevet. Der vil blive skabt et overblik over og givet en generel introduktion til de teknologier som anvendes til den grafiske præsentation af trafikreguleringsnetværket i Google Maps. Selve implementeringen og deployeringen af denne del af systemet beskrives i afsnit 25 Implementering og deployering af TNSSW, hvor der vil blive gået mere i detaljer med den praktiske anvendelse af de beskrevne teknologier. Det nuværende system Swarco Technology tilbyder til overvågning af trafikreguleringsnetværket, anvender et dynamisk webinterface, fremvist i en webbrowser, til navigation rundt i til systemets funktionaliteter. Det er derfor et krav at TNSSW på samme måde skal kunne tilgås gennem et interface som kan afvikles i en webbrowser. Dette begrænser allerede mulighederne væsentligt for udformningen af klientsiden. Valget står her imellem en applikation afviklet i browseren såsom en Java applet eller Flash applikation, eller en dynamisk webside. Google Maps anvender et JavaScript-baseret API, og det vil derfor være nemmest at integrere TNSSW i sidstnævnte løsninger, som samtidig også vil være lettere at tilpasse til det nuværende system Swarco Technology anvender, sammenlignet med de lidt tungere løsninger. En anden fordel ved at anvende en dynamisk webside er at det ikke kræves at der installeres yderligere software på klient-enheden som ved Java eller Flash, samt at det bliver nemmere at vedligeholde denne løsning, da den kan opdateres centralt på serveren uden at skulle udskifte hele applikation. En dynamisk webside giver selvfølgelig ikke helt de samme grafiske muligheder, som for eksempel en flash applikation, men i dette tilfælde vil det grafiske brugerinterface kunne implementeres i almindelig HTML, da det primære omdrejningspunkt vil være Google Maps. Selve udformningen af brugergrændefladen vil blive behandles senere i denne sektion. En almindelig HTML-side er en statisk repræsentation af en række elementer. Elementerne i en side er repræsenteret ved den såkaldte Document Object Model (DOM), som er en platformsuafhængig konvention for repræsentationen af disse elementer, som anvendes af alle større browsere20. Denne repræsentation gør det muligt at tilgå de enkelte elementer på siden, og dermed foretage en dynamisk manipulation af disse. Denne metode kaldes Dynamisk HTML (DHTML). DHTML er et bredt begreb som dækker over en kombination af teknologier, herunder HTML, klient-side scripting (oftest JavaScript), CSS21 og DOM, som muliggør udformningen af dynamiske websider. En anden mulighed for at skabe en dynamisk webside ville have været at Figur 22.1:Document Object anvende server-side-scripting, såsom PHP, ASP eller JSP, hvor det er Model (DOM) serveren der dynamisk generer siden og sender denne til brugeren. Dette er dog langt mindre fleksibelt sammenlignet med DHTML, idet det kræver at den enkelte side genindlæses før indholdet opdateres. Ved anvendelsen af DHTML er det muligt at skabe et dynamisk brugerinterface i webbrowseren, men for at have noget at præsentere, kræves en metode til at overføre data fra TNSSS. Til overførsel af data kan der igen anvendes ASP, PHP eller JSP, som muliggør en oprettelse af en direkte socketforbindelse til TNSSS. Det betyder dog igen at siden ikke kan være dynamisk, men at den skal genindlæses for hver forespørgsel, så derfor er denne løsning ikke at foretrække. Da JavaScript 20 Heriblandt Microsoft Internet Explorer, Safari, Opera, Google Chrome og Mozilla Firefox som tilsammen deler en markedsandel på over 99 %. 21 CSS: Cascading Style Sheets Side 56 TNSSW

57 i forvejen benyttes til DHTML anvendes derimod AJAX-teknologien. AJAX står for Asynchronous JavaScript And XML, men kræver i princippet ikke anvendelsen af XML, og kommunikationen behøver for den sags skyld heller ikke at foregå asynkron. Ved anvendelsen af AJAX er det muligt via JavaScript at foretage dynamiske HTTP-forespørgsler til en server via et XMLHttpRequestobjekt og opdatere browser-indholdet på baggrund af det data der returneres uden siden genindlæses. Teknologien kræver en klient-server-løsning, hvor en server applikation behandler de HTTP-forespørgsler som klienterne udfører. Som illustreret tidligere betyder dette derfor at TNSSW deles i to dele: Figur 22.2: Oversigt over opdeling af TNSSW Selvom dette er mere omfattende end en socket-forbindelse fra eksempelvis PHP direkte til TNSSS API, er det nødvendigt for at opnå den ønskede funktionalitet, med dynamisk opdatering. Samtidig giver løsningen også mulighed for at lægge væsentligt mindre belastning på API'et, da der kun skal oprettes én forbindelse til API'et for samtlige webklienter, og da informationer omkring netværkets status kan lagres i server-applikationen. Det betyder at det ikke er nødvendigt at kontakte TNSSS og databasen hver gang en klient logger på systemet. En anden fordel ved denne løsning er, som illustreret på Figur 22.2, at det er muligt at indlægge den sikre forbindelse mellem klient- og server-delen i TNSSW, hvormed der ikke skal foretages nogle tilpasninger af TNSSS. Dette vil blive behandlet i afsnit 25, Implementering og deployering af TNSSW. Serverdelen af AJAX kan implementeres på flere forskellige måder, blandt andet i C# og Java, men på grund af platformsuafhængigheden vælges igen Java som ved TNSSS-applikationen. Serversiden skal derfor implementeres som en Java Servlet, som kan håndtere HTTP-forespørgsler og samtidig kommunikere med TNSSS via det definerede API. En teknisk beskrivelse af selve implementeringen af servletten forefindes i afsnit 25. For at opsummere på det ovenstående består TNSSW af henholdsvis en tynd klient-del og en server-del. Klient-delen er en DHTML-side som anvender AJAX til kommunikation med serverdelen, som består af en Java Servlet. En oversigt over opbygningen og kommunikationsvejen i TNSSW kan ses på figuren herunder: TNSSW Side 57

58 Figur 22.3: Opbygning af TNSSW. Efter denne overordnede analyse af opbygningen af TNSSW vil det efterfølgende afsnit omhandle en mere dybdegående teknisk analyse af systemet, hvorefter design og implementering vil blive behandlet. 23 Analyse af TNSSW I dette afsnit vil TNSSW blive analyseret og der vil blive udarbejdet et analyseklassediagram som ligger til grund for det videre design. Det primære fokus i analysen vil være udformningen af servletten da den er hovedvægten i denne del af systemet. I afsnittet medtages kun udtræk fra den samlede analyse og analysesekvensdiagrammer vil derfor ikke blive medtaget i rapporten. For en dybdegående gennemgang af analysen af TNSSW henvises læseren til projektjournalen Analyseklassediagram og -sekvensdiagrammer, som er vedlagt på den medfølgende Cd. Der er flere muligheder for kompleksiteten af servletten. Servletten kan blot fungere som en tunnel, som videresender forespørgsler foretaget af brugeren til TNSSS API. En anden mulighed er at udformes servletten, så den indeholder en repræsentation af netværkets nuværende status, og ved at abonnere på ændringer i netværket gennem API'et22, kan denne repræsentation hele tiden holdes opdateret. De to muligheder er illustreret på figuren herunder: 22 For en dybere beskrivelse af API'et henvises til afsnit 18.3 og projektjournalen TNSS API på Cd'en. Side 58 TNSSW

59 Figur 23.1: Analyse over opbygning af servletten. Fordelen ved den første løsning er at servletten vil være simpel at konstruere, da den blot skal kunne håndtere forespørgsler og videresende disse i systemet. Løsningen betyder dog at der vil blive foretaget et kald på API'et hver gang netværkets status skal opdateres på en klient. Alle routeres og forbindelsers status skal udlæses løbende fra databasen og sammenlignes med sidste gang de blev udlæst for at kunne detektere at der er sket en ændring. Dette skal ske minimum en gang hvert 5. minut23 for hver klient der er forbundet til systemet, og da TNSSS er designet så der oprettes en ny forbindelse til databasen hver gang der foretages en forespørgsel, vil dette lægge et stort pres på databasen. Sammenligningen af data skal samtidig foregå på klienten hvilket medfører at den bliver mere kompliceret. Dette er ikke ønskeligt, da en mere kompliceret klient er sværere at tilpasse til Swarco Technology's eksisterende system. Den anden løsning på Figur 23.1 er mere kompliceret end den den første, men tager derimod højde for nogle af de førnævnte problemer. Ved at have en repræsentation af hele netværket i servletten er det muligt at anvende funktionen i API'et til at abonnere på ændringer i netværket. Hermed belastes API'et mindst muligt og det er kun nødvendigt at udlæse fra databasen når der skal hentes specifikke informationer såsom hændelseslog over ændringer i netværket. En anden fordel ved den sidstnævnte løsning er at systemet vil være i stand til at blive ved med at vise ændringer i netværket selvom databasen ikke er tilgængelig. TNSSS tager allerede højde for dette scenarie, ved at gemme ændringsbeskeder lokalt i en fil, samtidig med at de stadigvæk broadcastes via API'et og ved at lade TNSSW reagere på disse beskeder, gøres delen delvist uafhængig af databasen. Det er dermed kun funktionaliteter som indebærer visning af specifikke informationer som ikke vil være tilgængelige når databasen er offline. Dermed kan systemet opfylde sin vigtigste funktion selvom databasen er offline, nemlig at alarmere operatøren om afbrudte forbindelser. På baggrund af den mindre belastning af API'et, det sikkerhedsmæssige perspektiv, samt det faktum at systemet stadig vil kunne meddele fejl selvom databasen ikke er tilgængelig, vælges den sidste løsning, hvor hele netværkets nuværende status repræsenteres i servletten. Det leder frem til analyseklassediagrammet som er vist på figuren på næste side: 23 De 5 minutter er specificeret i risikoanalysen som er angivet i afsnit 5.4, og er den maksimale forsinkelse der må gå fra et kabel afbrydes i netværket til det bliver præsenteret for operatøren. TNSSW Side 59

60 Diagram 23.1: Analyseklassediagram for TNSSW Diagrammet er udarbejdet på baggrund af de analyserede krav. I analyseklassediagrammet er netværkets elementer repræsenteret ved hver deres klasse, og derudover er der tilføjet en klasse til at repræsentere ændringer. Som nævnt tidligere håndteres kun ændringer på forbindelser hvilket fremgår af diagrammet idet ændrings-klassen, forbindelsesændring, kun er forbundet til forbindelserne. Skal systemet på et senere tidspunkt ændres til at kunne håndtere ændringer på routerne kræves enten en udvidelse af ændrings-klassen eller en tilføjelse af en klasse til at håndtere router-ændringer. Informationer om routernes status er allerede medtaget i diagrammet selvom de ikke benyttes i det senere design af systemet. Side 60 TNSSW

61 De enkelte analyseklasser er beskrevet nærmere i tabellen herunder: Klasse: Central Router Forbindelse Forbindelsesændring Beskrivelse: Centralen repræsenterer den centrale server. Til centalen er der tilknyttet en række routere via en række forbindelser. Centralen styres af en operatør som står for overvågningen af de enkelte forbindelser og routere. Centralen har også en log der indeholder informationer om forbindelsesændringer. Ydermere administrerer centralen adgangskontrol og skriverettigheder for operatøren. En router har en type der fortæller hvilken type router den er (eks. SHDSL). En router har et RouterID som er et unikt ID på netværket og en status som fortæller om routeren er online eller offline. Desuden har routeren et sæt koordinater der fortæller dens geografiske placering. En router er forbundet til dens naborouter via en forbindelse. En forbindelse har et forbindelseid som er et unikt ID på netværket. Derudover er der en status der angiver om forbindelsen er online eller offline. Desuden kan en forbindelse være underlagt et vis antal fejl over en periode som bliver registeret. Det er muligt at tilføje og fjerne en kommentar fra en forbindelse og at optegne forbindelsen så den følger vejens forløb hvor forbindelsen er gravet ned. Desuden er det muligt at slette en forbindelse der er offline. En forbindelsesændring har et tidspunkt for ændringen og hvilken type ændring der er der er tale om (eks. at en forbindelse er blevet afbrudt). Der kan opstå mange forbindelsesændringer på en enkelt forbindelse og disse forbindelsesændringer vil blive modtaget af centralen. Tabel 23.1:Beskrivelse af analyseklassediagram. Ud fra analysen kan det konkluderes at servletten kan konstrueres så den indeholder en repræsentation af netværkets nuværende status, som opdateres på baggrund af de beskeder der broadcastes gennem API'et. Denne opbygning vælges da det reducerer belastningen af API'et og databasen, og samtidig garanterer at fejlmeddelelser kan nå frem selvom databasen ikke er tilgængelig. TNSSW Side 61

62 24 Design af TNSSW I dette afsnit følger en gennemgang af designet og distribueringen af TNSSW. Fokus vil i dette afsnit primært være på server-delen (servletten) af TNSSW, da designet bygger oven på analysen fra forrige afsnit. I starten af afsnittet vil overvejelser angående valg af distributionsmønstre for TNSSW, i forlængelse af analysen af den overordnede opbygning af TNSSW, blive beskrevet. Herefter gives et overblik over designet af TNSSW, samt et overblik over opbygningen af det samlede system bestående af TNSSR, TNSSS og TNSSW. Der vil som i foregående afsnit ikke blive gået i detaljer med sekvensdiagrammer for softwaren, men derimod blive lagt vægt på de tekniske overvejelser. For et dybdegående teknisk overblik over designet henvises til projektjournalen Designklassediagram og -sekvensdiagrammer, som forefindes på Cd'en. Som beskrevet i forrige afsnit opbygges TNSSW som en klient-server-løsning med en tynd klient der udelukkende står for præsentation af trafikreguleringsnetværket. Server-delen benytter TNSSS API til udlæsning af data omkring netværkets status og stiller dette til rådighed for klienterne ved at indeholde en repræsentation af netværket, som hermed kan tilgås. Dermed fungerer TNSSW som en udvidelse af applikationslaget i TNSSS, og tilfører samtidig et præsentationslag bestående af klientdelen. På figuren herunder ses en oversigt over de mest anvendte distributionsmønstre, hvor placeringen af de to dele af TNSSW samtidig er angivet: Figur 24.1: Illustration af distributionsmønstre anvendt ved TNSSW.24 Definitionen af API'et i TNSSS giver mulighed for at anvende distributionsmønsteret Distributed Application Kernel. Mønsteret giver i dette tilfælde mulighed for stor fleksibilitet, idet det er muligt at konstruere et modul som tilbyder en specifik funktionalitet for TNSS, som det er tilfældet med TNSSW, der har til opgave at præsentere netværket og opståede fejl. På samme måde ville det være muligt at tilføje andre moduler, som for eksempel kunne håndtere tilføjelsen og fjernelsen af routere fra systemet ved anvendelsen af det samme API. Ved at anvende Distributed Presentation mellem server- og klient-siden af TNSSW opnås samtidig at det er muligt at redigere og tilføje funktionaliteter til TNSSW uden at skulle opdatere applikationen på samtlige klienter. Dette er en stor fordel idet TNSSW skal integreres med et nuværende system, som hele tiden udbygges. 24 Figur udarbejdet på baggrund af kilde 10 side 4. Side 62 TNSSW

63 I designet af TNSSW anvendes som i den resterende del af systemet, PCMEF25 arkitekturframeworket, til lagdeling af de enkelte klasser. Dette er et oplagt valg, da det er samme arkitekturframework som anvendes til TNSSS, og TNSSW som beskrevet kan betragtes som en udbygning af førstnævnte. Ud fra analysediagrammet på side 60, udarbejdedes designklassediagram over servletten i TNSSW, som i simplificeret form er illustreret herunder: Figur 24.2: Designklassediagram over TNSSW. Et designklassediagram som indeholder attributter og metoder forefindes på Cd'en i projektjournalen Designklassediagram og -sekvensdiagrammer. Som det ses af figuren er domænemodellen fra analyseklassediagrammet repræsenteret i systemets Entity-pakke. I stedet for klassen centralen, er der tilføjet en facade-klasse, EEntity, som står for uddelegeringen af kald der foretages på Entity-pakken. Dette mindsker koblingen mellem de enkelte pakker i systemet, og gør det dermed mere fleksibelt over for ændringer som tilføres på et senere tidspunkt. I systemets mediator-pakke er placeret to klasser som står for kommunikationen med TNSSS API, henholdsvis MReciever og MDatabaseCommunication. Som illustreret på figuren anvender de to klasser API'et på forskellige måder. MReciever anvender API'ets recievemessages-funktion, og modtager dermed samtlige ændringer netværket udsættes for. På baggrund af disse ændringer opdateres objekterne i Entity-pakken hvormed repræsentationen af systemet hele tiden holdes opdateret. Samtidig gemmes et message-objekt for hver ændring. MDatabaseCommunication står for at håndtere specifikke forespørgsler i databasen, såsom tilføjelse af kommentarer og udlæsning af hændelsesloggen. Ved at uddelegere disse opgaver i to forskellige klasser kan de foregå parallelt, hvilket mindsker forsinkelsen på forespørgsler fra brugeren. I Control-laget står CActioner-klassen for håndtering af alle forespørgsler fra klienterne. Klassen 25 PCMEF står for Presentation, Control, Mediator, Entity and Foundation og er beskrevet nærmere i forgående sektion under afsnit 17. TNSSW Side 63

64 nedarver fra klassen HTTPServlet som er en generel Java-klasse som benyttes til servletter. CActioner inderholder blandt andet to funktioner til at håndtere henholdsvis POST- og GETforespørgsler, som er de to mest anvendte måder at foretage HTTP-forespørgsler på. En dybere teknisk beskrivelse af hvordan forespørgsler på servletten håndteres, forefindes i det efterfølgende afsnit. Når en klient opretter forbindelse til serverapplikationen udlæses hele netværket, hvormed dette kan indtegnes i Google Maps. Herefter er det kun nødvendigt for klienten løbende at udlæse nye beskeder, EMessage, som er blevet tilføjet, hvormed oversigten over netværket vil kunne holdes opdateret. Dette minimerer mængden af data der overføres mellem de to dele, da det kun er ændringer i netværket der skal udlæses. Efter tilføjelsen af TNSSW, kommer det samlede system til overvågning at netværksforbindelser dermed til at se ud som illustreret herunder: Figur 24.3: Oversigt over samlet system, TNSS. Det ses igen at TNSSW fungerer som en udvidelse af applikationskernen i systemet. Side 64 TNSSW

65 25 Implementering og deployering af TNSSW Herunder behandles implementeringen og deployeringen af TNSSW. De to områder beskrives samlet, da de på grund af den valgte opbygning af TNSSW er tæt koblede. I starten af afsnittet følger en beskrivelse af opsætningen af servletten, herunder hvordan den sikre forbindelse ind til denne implementeres. Herefter beskrives kommunikationen mellem klient- og server-delen, og hvordan data omkring trafikreguleringsnetværkets status udlæses til præsentationslaget. Til sidst i afsnittet forefindes en beskrivelse af implementeringen af præsentationslaget i DHTML, og hvordan Google Maps anvendes til præsentation af netværket. Da TNSSW er inddelt i to dele, henholdsvis en klient-del implementeret med DHTML og en serverdel implementeret som en Java Servlet, skal der til deployering anvendes både en HTTP-server til førstnævnte samt en web container til sidstnævnte. Gruppen har valgt at anvende Apache HTTP-server26 sammenkoblet med Apache Tomcat27 til deployering af TNSSW, da denne løsning indeholder alle de ønskede funktionaliteter som skal anvendes, herunder muligheden for at beskytte systemet med en sikker forbindelse via Transport Layer Security (TLS). Løsningen er samtidig platformsuafhængig, hvilket sikrer mulighed for anvendelse af løsningen ved forskellige serveropsætninger. Andre løsninger er blevet overvejet såsom Sun Java System Web Server28, men valget er faldet på Apache og Apache Tomcat, da Apache HTTP-server er den mest anvendte HTTP-server29 og anvendes blandt andet allerede i forvejen af Swarco Technology. Deployeringen af TNSSW skal samtidig højest sandsynligt foregå forskelligt fra by til by, idet der på nuværende tidspunkt anvendes forskellige løsninger på de enkelte centraler, og der er derfor ikke gjort yderligere overvejelser angående valg af løsning i dette tilfælde. Det skal her nævnes at projektgruppen ikke havde nogen tidligere erfaringer med opsætning og afvikling af AJAX og servletter, og der er derfor i projektperioden blevet benyttet en del tid på at kunne demonstrere hvorledes systemet skal deployeres. Dette er gjort for at kunne vise anvendelsen af de valgte teknologier og for at kunne demonstrere systemet over for Swarco Technology. Ved den valgte løsning foregår samtlige forespørgsler på TNSSW via en sikker forbindelse gennem Apache HTTP-server. Apache HTTP-server står derfor både for at hoste selve klienten bestående af et DHTML-modul som hentes som en almindelig hjemmeside i en browser, men samtidig også for at videreføre forespørgsler til servletten til Apache Tomcat. En forespørgsel på servletten er illustreret på figuren herunder: Figur 25.1: Eksempel på kommunikation med servlet gennem Apache HTTP-server. Punkt 3 på figurer sker kun i tilfælde hvor der forespørges direkte på informationer fra databasen Hyperlink til Apache HTTP Server: Hyperlink til Apache Tomcat Hyperlink til Sun Java System Web Server Hyperlink til undersøgelse omkring brug af HTTP-server TNSSW Side 65

66 Som det ses af Figur 25.1 anvendes et plugin kaldet mod_jk30 til at sammenkoble Apache HTTPserver med Apache Tomcat. Apache HTTP-server er samtidig sat op til at anvende TLS i form af HTTPS31, hvormed klientsiden beskyttes med brugernavn og kodeord. Dermed krypteres samtlige data som overføres mellem klienten og serveren. Selve opsætningen af Apache og Apache Tomcat er ikke medtaget i rapporten, da det ikke har direkte relevans for TNSS. På Cd'en forefindes en guide til opsætning af de to programmer samt alle opsætningsfiler som er blevet anvendt til deployering. I underafsnittet herunder forefindes derimod en gennemgang af implementeringer af kommunikationen mellem klient- og server-delen i TNSSW Kommunikation mellem klient og server i TNSSW I dette underafsnit gennemgås den tekniske implementation af kommunikationen mellem klienten og servletten. Der lægges i afsnittet vægt på hvordan data overføres mellem de to dele af TNSSW ved anvendelse af AJAX-teknologien, samt hvordan det er muligt hele tiden at udlæse de nyeste informationer omkring netværkets status til operatøren. Som beskrevet i afsnit 22 Opbygning af TNSSW er det ved anvendelsen af JavaScript muligt at foretage HTTP-forespørgsler inde fra en statisk side der er indlæst i browseren og dermed på baggrund af det data der returneres på denne forespørgsel manipulere med den viste side. Ved anvendelsen af mod_jk er det muligt af videreføre forespørgsler på en bestem URL32 på serveren til Apache Tomcat og dermed til servlet-delen af TNSSW. Der findes forskellige former for HTTP-forespørgsler, hvor de fire mest anvendte er angivet i tabellen herunder: HTTP-forespørgsel Beskrivelse HEAD Benyttes til at modtage udelukkende headerinformationer i responsen. Kan blandt andet benyttes til at modtage status for forespørgslen. PUT Benyttes til at aflevere information til serveren. GET Benyttes til at modtage den information URL'en angiver. POST Benyttes til at tilføje information til serveren. POST-kommandoen anvendes blandt andet når forms i HTML submittes. Tabel 25.1:Oversigt over mest anvendte HTTP-forespørgsler. I det udviklede system anvendes GET og POST kommandoerne til at kommunikere med servletten. POST anvendes ved udvidet adgangskontrol, hvor operatøren er nødt til at indtaste et kodeord for at anvende de beskyttede funktionaliteter, mens GET anvendes til at udhente informationer omkring netværket. Et eksempel på opbygningen af en GET-forespørgsel på servletten er angivet herunder: Som det ses af ovenstående kan der i forespørgslen angives diverse parametre, og på baggrund af 30 Hyperlink til opsætning af Apache og Tomcat 31 HTTPS: HyperText Transport Protocol Secure. 32 URL: Uniform Resource Locator Side 66 TNSSW

67 disse parametre kan server-applikationen generere et svar til klienten. Som berørt i forrige afsnit, udlæser klienten hele netværket ved initialisering. Dette foregår via en HTTP-forespørgsel foretaget fra JavaScript. I JavaScript anvendes XMLHttpRequest-objektet som er et API, som kan anvendes til HTTP-forespørgsler. Herunder er angivet den JavaScript-funktion som benyttes til at udlæse netværket under initialisering: function materialize() { var url = "TNSSA/TNSSA?networkRequest"; if (typeof XMLHttpRequest!= "undefined") { netreq = new XMLHttpRequest(); } else if (window.activexobject) { netreq = new ActiveXObject("Microsoft.XMLHTTP"); } netreq.open("get", url, true); netreq.onreadystatechange = createnetwork; netreq.send(null); } Kildekode 25.1: Funktion til foretagelse af initialisering af netværk i JavaScript. I funktionen defineres først servlettens URL hvorefter der oprettes et XMLHttpRequest-objekt. Da implementeringen af XMLHttpRequest-objektet er forskellig i Microsoft Internet Explorer sammenlignet med andre browsere er det nødvendigt med den viste kontrol, for at oprette det korrekte objekt. Når XMLHttpRequest-objektet er oprettet kan en GET-forespørgsel oprettes på objektet med den definerede URL. Inden forespørgslen sendes til serveren, defineres desuden den callback funktion som kaldes hver gang forespørgslens readystate ændres. XMLHttpRequest-objektets readystate kan antage fire værdier som beskriver forespørgslens status: readystate Status 1 open metoden er udført med succes på objektet. 2 send metoden er blevet udført og header information er modtaget. 3 HTTP-svarets indhold er begyndt at blive indlæst. 4 HTTP-svarets indhold er nu fuldt indlæst. Tabel 25.2:Oversigt over værdier readystate kan antage. Ved kontrol af readystate er det dermed muligt at kontrollere hvorvidt et svar er modtaget fra serveren. TNSSW Side 67

68 Som beskrevet i afsnit 22 Opbygning af TNSSW indeholder servletten metoder til at håndtere HTTP-forespørgsler, og ved foretagelsen af GET-kommandoen på servletten udføres dennes doget-funktion: public void doget(httpservletrequest request, HttpServletResponse response) throws IOException, ServletException { String getnetwork = request.getparameter("networkrequest");... String reply = "<?xml version=\"1.0\" encoding=\"iso \"?>";... else if ((getnetwork!= null)) { reply += getnetwork(); }... response.setcontenttype("text/xml"); response.setheader("cache-control", "no-cache"); response.getwriter().write(reply); } Kildekode 25.2: Uddrag af servlettens doget-funktion der illustrerer håndteringen af en networkrequest. Funktionen dekoder de angivne parametre, og genererer på baggrund af disse et HTTP-respons til klienten. Som det ses af kildekode 25.2 genereres et svar i XML33, som indeholder netværkets data. Metoden getnetwork returnerer følgende XML-data over netværket: <network> <router> <id>...</id> <lat>...</lat> <lng>...</lng> </router>... <connection> <id>...</id> <status>...</status> <coordinates>...</coordinates> </connection>... </network> Kildekode 25.3: Oversigt over XML som returneres ved forespørgsel på netværket.. Data lagres i XML, da det gør det nemt at udtrække de enkelte informationer på klient-siden, idet XMLHttpRequest-objektet er designet til at håndtere denne form for data. På trods af navnet kan XMLHttpRequest-objektet dog sagtens modtage data i form af almindelig tekst, men ved at anvende XML kan informationen i de enkelte tags tilgås, uden at det er nødvendigt at sortere i svaret. 33 XML: Extensible Markup Language Side 68 TNSSW

69 HTTP-responsen fra servletten håndteres i materialize funktionen af funktionen createnetwork som er delvist gengivet herunder. function createnetwork() { if (netreq.readystate == 4) { if (netreq.status == 200) { var networkxml = netreq.responsexml; var routers = networkxml.getelementsbytagname("router"); var conns = networkxml.getelementsbytagname("connection"); for (i = 0; i < routers.length; i++) { Kildekode 25.4: Callback-funktion som håndterer respons fra servletten. Som det ses af kildekoden kontrolleres der først for at svaret er blevet fuldt indlæst hos klienten. Herefter foretages et tjek for at statuskoden for responsen er i orden. 200 indikerer at responsen er modtaget med success. Er disse to forhold opfyldt kan det med sikkerhed vides at det ønskede data er modtaget hos klienten, og det er herefter muligt at udtrække de enkelte informationer om henholdsvis routere og forbindelser. Hermed kan netværket indtegnes ved hjælp af Google Maps API, hvilket beskrives i det efterfølgende underafsnit. Efter at have modtaget hele netværket ved initialisering begynder klienten herefter at forespørge på nye ændringer i netværket. Dette foregår hvert 15. sekund hvor der foretages en forespørgsel på servletten, som returnerer indholdet af de message-objekter som er blevet tilføjet siden sidste forespørgsel: Figur 25.2: Illustration af den løbende udlæsning af ændringer i netværket. Hermed er det muligt hele tiden at opretholde præsentationen af netværkets status hos klienten. For god ordens skyld skal det desuden nævnes at der på servlet-siden er implementeret en garbagecollection funktion, som sørger for at slette gamle Message-objekter så hukommelsen på serveren ikke fyldes op. Dette kan gøres da repræsentationen af netværket hele tiden holdes opdateret og da de klienter som er aktive hele tiden sørger for at få udlæst de nyeste ændringer i netværket. TNSSW Side 69