Synkronisering af datastrukturer i et opgavestyrings system

Transkript

1 Synkronisering af datastrukturer i et opgavestyrings system I samarbejde med Terma A/S af Kasper Friis Kjærhus, s Danmarks Tekniske Universitet Institut for Informatik og Matematisk Modelering Eksamensprojekt Vejleder : Paul Pop IMM-B.Eng oktober 2008

2 i Resumé Udarbejdelse af en offline udgave at et planlægnings system, der virker i en udgave på et netværk. Systemet anvendes af flere brugere og hoved problematikken i problemstillingen går på at definere passende synkroniserings algoritmer. Disse algoritmer skal tage hånd om mange brugeres opdateringer, og tilføjelser af data, der kan være oparbejdet over en tidsperiode ind i et system der i samme periode er anvendt dynamisk. Synkroniseringen skal såvidt det er muligt foregå uden brugerens indblanding. Og der skal derfor være mulighed for gå tilbage til tilstande før synkroniseringer, både helt og delvist. Projektet kommer derfor til at bestå af disse hoved punkter Konstruktion af en optimeret data struktur til anvendelse i et task management system med tilhørende værktøjer til operationer på data strukturen. Konstruktion af en transportabel(offline) udgave af systemet. Eksport af data fra data strukturen til et meta-format, der kan anvendes til både eksport og backup. Synkronisering mellem forskellige datastrukturer, ved import af eksporterede data.

3 Indhold 1 Datastruktur Planlægningsobjekter Afhængigheder Træstrukturer Orienteret graf Løkker og hårdknuder Repræsentation af den orienterede graf Sortering Grupper af knuder Funktionaliteter i datastrukturen Konklusion på datastruktur Transportabel udgave af PlanTool 12 3 Eksport af datastrukturer Format Forudsætninger Java og XML Hvilke data skal eksporteres Database til xml konklusion Synkronisering og indlæsning af data Indlæsning af data Overordnet synkronisering Indlæsning af datasæt Synkronisering af datasæt Konklusion Konklusion 23 Litteratur 24 A DTD definition for eksport format 25 ii

4 INDHOLD iii B PlanTool 27 B.1 styring i PlanTool B.2 Status C Appendiks 30

5 Forord I forbindelse min praktik hos Terma A/S udviklede jeg et værktøj, kaldet PlanTool, til styring af arbejdsopgaver. Det er dette system der er grundlaget for mit eksamensprojekt. PlanTool tilhører Terma A/S og bliver derfor ikke vedlagt dette projekt. Selve systemet er ikke relevant for projektet, da det kun er del funktioner der anvendes. I forbindelse med min fremlægning af projektet vil jeg kort demonstrere systemet, og vise de funktionaliteter der behandles i dette projekt. Projektet omhandler synkronisering mellem datastrukturer anvendt i Plan- Tool systemet. Systemet indeholder mange funktioner, der ikke er relevante for dette projekt, og som derfor ikke vil blive behandlet. Systemet eksisterer i øjeblikket i en alpha-version, der testes af kommende brugere. I appendiks B introduceres PlanTool med de forskellige funktionaliteter som systemet byder på. Systemet er ikke færdig udviklet og derfor er der flere funktioner der ikke fungerer optimalt. Der er endnu ikke udført fyldestgørende test af systemet, så der kan forekomme uregelmæssigheder i eksekveringen. Dette har imidlertid ingen indflydelse på projektet da det alene omhandler eksport og synkronisering af data. I afsnit 1 analyseres en datastruktur til anvendelse ved eksport og synkronisering af data. Endvidere beskrives en række værktøjer til anvendelse på datastrukturen. I afsnit 2 fastlægger jeg platformen til eksekvering af PlanTool som en transportabel udgave. I afsnit 3 defineres et meta-format til eksport af data strukturer. Samtidig redegøres for de funktionaliteter der skal implementeres i systemet for at kunne foretage eksporten. Endelig vil jeg i afsnit 4 omtale funktioner til import og synkronisering, af data. Målet med dette projekt er at få klarlagt de aspekter og problemer der er forbundet med eksport, import og synkronisering i forbindelse med PlanTool. 1

6 1 Datastruktur I PlanTool 1 er der visse vanskeligheder med organisering af data. Disse problemer opstår ved relationer mellem objekter der ikke kan beskrives ved almindelige datastrukturer. Målet er derfor at udvikle en generisk data struktur der kan beskrive relationer mellem objekter uden at der opstår problemer. Først vises hvorfor den almindelige opbygning af projekter, med underopgaver i en træstruktur ikke fungerer i dette tilfælde. Dernæst anvendes en datastruktur baseret på orienterede grafer der løser problemerne. 1.1 Planlægningsobjekter I PlanTool eksisterer der tre slags planlægnings objekter; projekter, opgaver og milepæle. Hver type af objekter har en række særegne-, men også en del fælles egenskaber. I afsnit B.1 på side 27 er en nærmere beskrivelse af de forskellige typer planlægningsobjekter. Overordnet kan de tre typer dog betragtes som objekter af samme type, nemlig planlægnings objekter. Dette gør det væsentligt mere simpelt at anvende en generisk datastruktur. 1.2 Afhængigheder Der eksisterer fire forskellige slags afhængigheder mellem objekter; FF-, FS-, SF- og SS-afhængigheder, disse afhængigheder er nærmere beskrevet i B.1 på side 28. FF-afhængigheden er den afhængighed der benyttes til at hægte de forskellige objekter sammen, og de andre er sekundære afhængigheder. FFafhængigheder betyder at et forældre objekt ikke kan afsluttes før børne objektet er afsluttet. Dette betyder derfor at for ethvert objekt der er afsluttet, gælder at alle børn, børnebørn osv. også er afsluttede. Afhængighederne vil blive illustreret med pile, hvor pilens hoved peger på det objekt der er afhængigt af det objekt pilen udgår fra, se figur 1.1 på næste side 1 I appendiks B på side 27 findes der en nærmere beskrivelse af værktøjet PlanTool. 2

7 KAPITEL 1. DATASTRUKTUR 3 B A C Figur 1.1: A afhænger af B og C 1.3 Træstrukturer Simpelt træ Den umiddelbare struktur der kan anvendes til at beskrive et projekt er en træstruktur 2. Roden af træet er selve projektet og opgaverne i projektet er knuder i træet som vist på figur 1.2 Projekt Figur 1.2: Simpel træstruktur for et enkelt projekt. Indlejrede projekter Et projekt kan afhænge af et andet projekt der afvikles selvstændigt. Denne situation kan også repræsenteres ved et simpelt træ som det ses på figur 1.3 på næste side. Hvis et projekt indeholder en opgave der også er indeholdt i et andet projekt opstår der lidt komplikationer. Da afhængigheden går på tværs i træet, er træstrukturen ikke længere overholdt og de særlige egenskaber ved træet ikke længere gældende. Hvis træstrukturen skal overholdes skal der derfor laves en kopi af opgaven, samt alle dens underliggende objekter. Det er vigtigt at alle de underliggende objekter kopieres korrekt for at bevare alle egenskaber for den pågældende opgave. For at simplificere situationen med kopiering af underobjekter, kan enhver knude i træet udgøre roden i sit eget undertræ, således at en knude indeholder børne -træer i stedet for knuder. Man kopierer nu et helt træ i stedet for en enkelt knude, og man er således sikker på at alle under objekter er kopieret. 2 [Cormen et al., 2001]

8 KAPITEL 1. DATASTRUKTUR 4 Projekt 1 Projekt Figur 1.3: Simpel træstruktur for et projekt med et indlejret projekt. Projekt 1 Projekt KOPI Figur 1.4: Simpel træstruktur for et projekt med et indlejret projekt, og en opgave der findes i begge projekter. Problemer At det samme objekt findes mere end ét sted i datastrukturen er på ingen måder optimalt. Denne redundans giver anledning til flere problemer, i forbindelse med pladsforbrug, søgning og opdateringer. Pladsforbrug En af konsekvenserne er den åbenlyse forøgede data mængde, hvilket i den faktiske situation med PlanTool ikke er et alvorligt problem. Under andre betingelser vil dette dog kunne medføre praktiske problemer i forbindelse med

9 KAPITEL 1. DATASTRUKTUR 5 Projekt 1 Projekt Figur 1.5: Træstruktur for et projekt med under-træer. pladsforbrug. I det værst tænkelige tilfælde kan redundansen udgøre langt den største del af datastrukturen. Dette kan forekomme ved en data struktur der forekommer ved rekursion. Søgning og opdatering I forbindelse med søgning i datastrukturen vil redundante objekter udgøre et problem. For at kunne foretage en reel søgning er man nødt til at kunne skelne de redundante objekter fra hinanden. Eller vil det ikke være muligt at vide om man er i den rigtige gren af træstrukturen. Det må dog antages at man ved en søgning finder de korrekte data, stien til dataene kan dog være en anden end den forventede, og i sagens natur vil den samlede mængde information, sti og data, ikke nødvendigvis være korrekt. Da et objekt kan forekomme i flere udgaver i datastrukturen vil det betyde at en entydig identifikation ikke er mulig og der kan derfor opstå vanskeligheder ved opdateringer af objekterne. Ved en opdatering skal alle kopier af objektet have samme opdatering, og det er derfor vigtigt at alle forekomster findes ved søgning. Konklusion på træstrukturer Træstrukturer er meget effektive i de tilfælde hvor et planlægningsobjekt kun kan tilhøre et enkelt projekt eller opgave. I disse tilfælde er træstrukturen umiddelbart at foretrække idet den er simpel og hurtig. I de tilfælde hvor et planlægningsobjekt kan tilhøre to eller flere projekter er træstrukturen derimod utilstrækkelig. Den har et uhensigtsmæssigt pladsforbrug, mangler effektivitet og sikkerhed i søgefunktioner såvel som ved opdatering af objekter. Endvidere er der en risiko for at data integriteten i datastrukturen ikke opretholdes.

10 KAPITEL 1. DATASTRUKTUR Orienteret graf Et alternativ til træstrukturer er at bruge orienterede grafer 3. En orienteret graf er en samling af knuder og orienterede kanter. Flere af problemerne ved træstrukturen bliver umiddelbart løst ved istedet at bruge orienterede grafer. Hvis man laver datastrukturen i figur 1.4 på side 4 om til en orienteret graf får man strukturen som vist på figur 1.6. Projekt 1 Projekt 2 Projekt Projekt Figur 1.6: Eksempler på orienterede grafer, de to grafer repræsenterer de samme data men den ene er skrevet op som et træ, og den anden er skrevet som en generisk orienteret graf. Alle objekter er nu entydigt defineret i strukturen hvilket naturligvis fjerner problematikken ved søgninger og opdateringer. Til gengæld er stier til de enkelte objekter ikke længere entydige, da der kan være mange måder at komme frem til det samme objekt. Samtidig er der en risiko for at der kan opstå løkker 4 og dermed hårdknuder 5 Datastrukturens pladsforbrug nu er reduceret til et minimum da alle objekter forekommer netop én gang. Datastrukturen er på mange måder mere simpel end i træstrukturen, men måske ikke så intuitiv, da der ikke findes en decideret rod. Endvidere er strukturen af de orienterede grafer ikke så let overskuelig som i træstrukturer, hvilket fremgår af figur Løkker og hårdknuder Man kan havne i en situation hvor forskellige objekter låser hinanden på en sådan måde at det ikke er muligt at komme videre, denne situation kaldes en hårdknude, eller på engelsk en deadlock. Det mest simple tilfælde er når et objekt er afhængig af sig selv. Mellem objekter er det mest simple tilfælde når to objekter er gensidigt afhængige af hinanden som det ses på figur [Cormen et al., 2001] 4 Eng.: Loops 5 Eng.: Deadlocks

11 KAPITEL 1. DATASTRUKTUR 7 A A A B B C Mindste løkke Simple løkke Figur 1.7: Løkker Større løkke For at undgå hårdknuder må det altså være et krav at der ikke findes løkker i datastrukturen. Der tages derfor udgangspunkt i orienterede grafer uden løkker, også kaldet acykliske orienterede grafer 6, i designet af datastrukturen. 1.6 Repræsentation af den orienterede graf For at overskueliggøre arbejdet med graferne må der være en fornuftig måde at repræsentere strukturen på. I det følgende repræsenteres grafer ved symbolet G af det engelske Graph. Mængden af knuder repræsenteres ved symbolet V af det engelske Vertex, og mængden af kanter ved E af Edge. Vi har dermed denne repræsentation for en graf 7 : Repræsentation af knuder G = (V, E) Hvis alle knuderne opstilles på listeform, sorteret efter deres id, kan arbejdet tage udgangspunkt i id erne fra denne liste fremfor knuderne i sig selv, se tabel 1.1. Hvis vi igen betragter strukturen fra figur 1.6, så ser den ud som på figur 1.8, ved en nummerering af knuderne. Denne nummerering er valgt tilfældigt og kunne være foretaget på mange andre måder. Nummereringen er derfor ikke entydig, men kan i visse tilfælde påvirke effektiviteten af søgninger i datastrukturen. Denne problem stilling er imidlertid rent teoretisk, da man i praksis vil bruge kendte id er fremfor tilfældig nummerering. Mængden af knuder i figuren er derfor: V = 1, 2, 3, 4, 5, 6 Repræsentation af kanter Alle kanter i en orienteret graf udgår fra netop én knude og ender ligeledes i netop én knude. En kant er derfor entydigt bestemt ved et par af knuder, 6 På engelsk kaldet Directed Acyclic Graphs forkortet DAG 7 [Bryant, 1992]

12 KAPITEL 1. DATASTRUKTUR 8 Liste indeks Knude Projekt Projekt 1 Tabel 1.1: Liste af knuder, hvor listens indeks anvendes videre. 2 e 0 e 3 e 2 5 e 5 e Figur 1.8: Grafen fra figur 1.6 med knuder repræsenteret som indeks i en liste. e 1 notationen for en enkelt knude er: e = (u, v) hvor, e er den enkelte kant, u er den knude kanten udgår fra og v er knuden som kanten går til. Hvis vi betragter figur 1.8 får vi følgende kantsæt: E = e 0, e 1, e 2, e 3, e 4, e 5 = (0, 2), (1, 3), (2, 5), (3, 2), (3, 4), (4, 5) Kanterne kan også repræsenteres ved en såkaldt kantmatrix 8. En kantmatrix er en (n n)-matrix, hvor n er antallet af knuder i grafen. Tallet 1 i matricens felt (u, v), viser at der går en kant fra knuden u til knuden v, og et 0 viser at der ikke er nogen kant. På figur 1.9 ses et eksempel på en kantmatrix. I forbindelse med en kantmatrix er en del spild i repræsentationen i form af alle de kanter der beskrives som ikke eksisterende. Hvis man i stedet anvender en lænket liste af kanter der udgår fra hver enkelt knude, så viser man nøjagtigt det samme som i kantmatricen, men hvor al den overflødigt er væk. På figur 1.9 ses et eksempel på en kantliste. 8 Eng.: Adjacencymatrix [Cormen et al., 2001]

13 KAPITEL 1. DATASTRUKTUR (a) (b) Figur 1.9: (a) Grafen fra figur 1.6 repræsenteret som en kantmatrix. (b) Samme graf repræsenteret som en liste. 1.7 Sortering For at kunne forhindre løkker skal det være muligt på en eller anden måde at afgøre i hvilken rækkefølge forskellige knuder ligger. I forbindelse med PlanTool betyder dette rækkefølgen hvormed opgaver kan løses. For acyklisk orienterede grafer findes der netop sådan en sortering kaldet topologisk sortering 9. Kort sagt er en topologisk sortering en placering af alle knuderne i grafen på en linie således at alle kanter har samme retning, eksempelvis fra venstre mod højre. En topologisk sortering er ikke entydig da der for den samme graf kan eksistere adskillige topologiske sorteringer. I figur 1.10 er der to forskellige topologiske sorteringer af strukturen fra figur 1.6 på side Projekt Projekt Projekt 2 Projekt 1 Figur 1.10: Topologiske sorteringer af strukturen fra figur [Cormen et al., 2001]

14 KAPITEL 1. DATASTRUKTUR 10 I [Cormen et al., 2001] er der beskrevet en effektiv algoritme til at udføre topologisk sortering. 1.8 Grupper af knuder Det er nødvendigt at kunne identificere og beskrive enkelte såvel som grupper af knuder i grafen. Dette gøres ved en simpel underopdeling i form af familie, øvre gruppe og nedre gruppe. Denne opdeling af grupper kan afhjælpe den førnævnte problemstilling omkring løkker. Definition af grupper Øvre gruppe Den øvre gruppe, UG, til en bestemt knude, v i G, er mængden af knuder der i alle topologiske sorteringer T S(G) ligger før knuden selv. UG(G, v) = u UG(G, v) v G u v T S(G) Nedre gruppe Den nedre gruppe, LG, til en bestemt knude, v i G, er mængden af knuder der i alle topologiske sorteringer T S(G) ligger efter knuden selv. LG(G, v) = u LG(G, v) v G u v T S(G) Familie Famlien, F, til en bestemt knude, v, er mængden af knuder der er forbundet med v, således at hvis u F, så er det enten muligt at komme fra v til u eller fra u til v, ved at følge kanter i G. Sagt på en anden måde, at der eksisterer en vej mellem u og v i den ene eller anden retning. F (G, v) = u F (G, v) v G (En vej fra u til v ellr v til u) For at forhindre løkker kræves det at der til enhver tid kan gennemføres en topologisk sortering. Det er forholdsvis simpelt at garantere at dette overholdes i forbindelse med oprettelsen af nye kanter, ved at kræve at nye kanter ikke oprettes fra en knude til en i dens øvre gruppe. Nogle af grupperingerne anvendes ikke direkte i dette projekt, men skal være til stede i forbindelse med andre funktioner der skal anvende strukturen.

15 KAPITEL 1. DATASTRUKTUR Funktionaliteter i datastrukturen For at data strukturen skal være funktionel skal den have en række forskellige funktioner, således at data kan vedligeholdes og tilgåes. Det skal naturligvis være muligt at indsætte både knuder og kanter, ligeledes skal det være muligt og fjerne disse igen. En naturlig funktionalitet er også muligheden for at hente data fra en eller flere knuder. Der vil endvidere være brug for at kunne hente de forskellige grupperinger som tidligere er beskrevet, og endelig skal det være muligt at ændre nummereringen af de forskellige knuder. Oversigt over funktionaliteter i datastrukturen Indsæt/slet knuder. Indsæt/slet kanter. Undersøg knuder og kanter. Hente en knude. Hente en liste af knuder. Finde forskellige grupper, som beskrevet i afsnit1.8. Ændre nummereringen af knuder, skal bruges ved synkronisering Konklusion på datastruktur Der er ved analysen fremkommet en datastruktur der kan indeholde planlægningsobjekterne i værktøjet PlanTool. Den fundne datastruktur kan på en fornuftig måde håndtere alle de afhængigheder der kan oprettes i systemet, samt garantere lovligheden af disse. Vedlagt i appendiks C ses implementationen af datastrukturen, sammen med et testprogam.

16 2 Transportabel udgave af PlanTool For at optimere brugen af PlanTool er det nødvendigt at systemet også eksisterer i en transportabel udgave, der kan fungere offline. PlanTool er skrevet udelukkende i Java som et web-baseret program, og derfor kan hele programmet gemmes i en WAR-fil 1. Det er derfor nemt at flytte hele applikationen, da alle ressourcer er pakket i samme fil. PlanTool har en indbygget database, der er baseret på Java, og brugeren behøver ikke at installere eller opsætte en sådan. PlanTool er således kun afhængig af tilstedeværelsen af en webserver der indeholder en servlet container 2, og et Java miljø 3. Der findes adskillige af sådanne webservere, fx. Jetty 4 eller Winstone 5. Det forventes at brugerne har et Java miljø installeret, og Jetty eller Winstone kan således startes med en enkelt kommando fra en prompt eller ved hjælp af en batch-fil. Jetty eller Winstone vil fx. kunne startes med nedenstående kommando fra et bibliotek indeholdende de to filer der anvendes. Jetty java -jar jetty-runner.jar PlanTool.war Winstone java -jar winstone jar --warfile=<plantool.war> Minimum Java Runtime Environment

17 3 Eksport af datastrukturer For at gøre anvendelses mulighederne for systemet så store som mulige er det et ønske at systemet skal kunne eksportere til et meta format, altså et filformat der udelukkende beskriver systemets data uafhængigt af systemet selv. 3.1 Format XML Et åbenlyst valg til dette format er XML 1. Ved at eksportere data til dette format er der mulighed for eventuelt at anvende informationerne i andre systemer. Det er også muligt manuelt at søge i informationerne, hvilket ikke direkte er muligt i et binært format. Endelig er der muligheden for kun at anvende dele af informationerne. En anden klar fordel ved XML, er muligheden for at anvende validering af data formatet ved hjælp af enten DTD 2 eller SCHEMA 3 filer. Endelig er der det faktum at XML er blevet en de facto standard for eksport og import af strukturerede oplysninger, og mange forskellige udviklingsmiljøer understøtter derfor direkte ind og udlæsning af XML data. Database dump (SQL) I systemet er alle data gemt i en database baseret på HSQLDB 4. Og man kunne derfor også direkte eksportere et dump af databasen. Dette er dog ikke optimalt da et andet system ikke direkte vil kunne læse data fra dumpet. Da databaser ikke eksporterer til et standardiseret format, men oftest til en variant af SQL, der er tilpasset den aktuelle data, kan der også opstå problemer ved læsning af formatet. Der er dog fordele ved at eksportere direkte fra databasen, hvis man for eksempel ønsker at erstatte den eksisterende information i databasen med den information der indlæses, så kan man umiddelbart indlæse det eksporterede dump. 1 "Extensible Markup Language"se også 2 "Document Type Definition" Definition "Document Type Definition" Definition 4 Nærmere om denne database kan ses her [HSQLDB project page] 13

18 KAPITEL 3. EKSPORT AF DATASTRUKTURER 14 Tekst format Der vil ikke være nogen ide i at eksportere til et tekstformat, da XML i sig selv er et tekst format, der tilbyder en masse ekstra funktionalitet. Eneste fordel ved at anvende rene tekstfiler, er muligheden for at få mindre filer, da en meget stor del af en XML-fil anvendes til at beskrive strukturen. Men da hverken lager plads eller båndbredde er begrænset for PlanTool er der ingen ide i at anvende et rent tekstformat. Andre formater Der er en del andre formater der kunne anvendes, men nogle af disse er properitære, og derfor ikke interessante da systemet skal holdes i åbne formater. Andre er i pricippet afarter af de ovenstående som fx. SGML, CSV og ODF. 3.2 Forudsætninger For at det er muligt at eksportere data, og senere genindlæse, så skal det være muligt at identificere alle objekter der ikke genereres dynamisk. Dvs. at det skal være muligt at identificere alle planlægningsobjekter og brugere, da alle andre data kan identificeres ved deres relationer til de før nævnte. Brugere er nødvendigvis unikke, og identificeret ved deres navn og initialer, der skal være unikke. Der er således ikke nogle vanskeligheder omkring brugere da der eksisterer globale attributter der identificerer dem, såfremt at disse er aftalt fra en central instans, i dette tilfælde virksomheden. Anderledes er det med planlægningsobjekterne, her eksisterer der ikke globale attributter der entydigt kan identificere alle objekter. Projekter har som oftest et nummer eller anden form for identifikation, til anvendelse i forbindelse med fakturering. r er straks mere vanskelige da de ikke har en selvstændig fakturering. Da opgaver også kan høre under flere projekter kan det ikke lade sig gøre at anvende en eventuel sti til at placere opgaven. Hvis den samme opgave oprettes på forskellige systemer så kan man ikke entydigt identificere opgaven. Man kan kigge på relationerne til andre objekter og sandsynliggøre at det er den samme opgave, men det er ikke entydigt. Denne problematik hører dog under synkronisering, og bliver derfor behandlet i et senere afsnit. r bliver identificeret ved deres navn, men har en global unik identifikation 5, der kan anvendes til entydigt at bekræfte at to objekter er kongruente. Omkring milepæle gælder samme problematik som for opgaver, og samme løsnings model benyttes. 5 Med global unik menes en streng der med meget stor sandsynlighed er unik, da den består af en brugers initialer og tiden i millisekunder siden 1. januar 1970 kl 00:00: GMT og det er meget usandsynligt at den samme bruger har oprettet to objekter på nøjagtig samme tid.

19 KAPITEL 3. EKSPORT AF DATASTRUKTURER Java og XML Java har i forvejen klasser til at arbejde med XML-filer, der ligger i pakken javax.xml. Der findes værktøjer til både at generere, læse og validere XML data. Jeg vil derfor ikke beskrive nærmere hvordan der genereres XML-filer da det fremgår af dokumentationen for klasserne. Der konstrueres en DTD-fil for hver eneste version af XML-filer således at alle XML filer kan valideres for at sikre at eksport filerne er genereret korrekt. 3.4 Hvilke data skal eksporteres Umiddelbart kunne man vælge at eksportere samtlige data fra databasen, men en del af indholdet i databasen er genereret udfra relationer til andre data. Disse data er derfor irrelevante ved indlæsning i et andet datasæt da de under alle omstændigheder skal regenereres for at sikre integriteten. Den information der er relevant at gemme omkring data er således alle de de informationer der specifikt er angivet, og ikke informationer der er nedarvet. Den information der ligger i systemet kan deles op i fire dele. Information omkring system og versioner. Information omkring brugere. Information omkring planlægnings objekter. Log information I appendiks A på side 25, ses schema-filen for eksportformatet. I det følgende nævnes kun de informationer der har relevans for strukturen, andre attributter har ingen indflydelse på opbygningen af datastrukturen. Det skal også besluttes om man vil eksportere arkiverede data, eller om der kun skal eksporteres aktivt data. Dette besluttes alt afhængig af hvad de eksporterede data skal bruges til. System, version og fil information Udover de faktiske data der ligger i systemet er det også nødvendigt at gemme nogle informationer omkring systemet der eksporterer data. Herunder tænkes på versions-numre på både datamodellen og på systemet, det er også nødvendigt at gemme eksport tidspunktet, da system datoer ikke nødvendigvis er pålidelige, fordi de kan være ændret undervejs i forbindelse med overførsler mellem systemer. Endelig skal det også noteres hvilke data der er eksporteret, om det er aktive-, arkiverede eller alle data.

20 KAPITEL 3. EKSPORT AF DATASTRUKTURER 16 Brugere - <users> Med hensyn til data omkring brugerne er det rimelig ligetil at eksportere disse. Alle data omkring brugere skal eksporteres da intet afhænger af andre informationer. I tabel 3.1 er vist de vigtigste attributter for brugere. De resterende attributter kan ses i DTD-filen i appendiks A. Tag <id> <name> <initials> <password> Beskrivelse Id Navn Initialer Password Tabel 3.1: Vigtige attributter omkring brugere, Omsluttende tag <user> Planlægnings objekter - <objects> Planlægningsobjekter er en anelse mere komplekse at eksportere. Ud over de attributter der direkte tilhører objektet findes der også indlejrede sæt af attributter der beskriver tidsfrister, relationer til andre objekter. Disse indlejrede sæt repræsenteres i deres egne XML-elementer, som vist på figur 3.1. Figur 3.1: Planlægningsobjekter - <objects> Estimater - <estimates> Disse estimater på tidsforbrug kunne gemmes som almindelige attributter i objekter, men de lægges i deres eget element for overskuelighedens skyld.

21 KAPITEL 3. EKSPORT AF DATASTRUKTURER 17 Tidsfrister - <deadlines> Det er ikke nødvendigvis alle tidsfrister der skal eksporteres. Tidsfrister nedarves i stort omfang, og det er derfor kun de tidsfrister der specifikt er angivet for de enkelte objekter der skal eksporteres. Et enkelt objekt kan have flere tidsfrister, da der er flere forskellige slags. Samtidig kan der være både arkiverede og aktive tidsfrister. Eftersom ingen af tidsfristerne der gemmes er nedarvede, så er det ikke nødvendigt at gemme tidsfristers informationer om hvilke relationer de er dannet ud fra. Afhængigheder - <dependencies> Et planlægnings objekt kan have mange afhængigheder, af forskellige typer, og med referencer til mange andre objekter. Igen gælder det at der kan være både aktive og arkiverede afhængigheder. Log - <log> Loggen dækker alle handlinger i systemet, og det vil sige at alle nedarvninger er inkluderet. Der skal derfor kun eksporteres de log-meddelelser der indeholder tilføjelser og ændringer, og dermed datoer for disse handlinger, samt hvilke brugere der har foretaget handlingerne. Hvis disse informationer ikke er nødvendige, kan man nøjes med at gemme de log-beskeder som brugere af systemet har angivet. 3.5 Database til xml For at eksportere informationerne til en XML-fil skal foretages operationer i to skridt, se figur 3.2. Første skridt går på at eksportere de relevante data fra databasen til forskellige datastrukturer, bl.a. en som beskrevet i afsnit 1 på side 2. Andet skridt udlæser datastrukturen til en XML-fil. 1 2 Database Datastruktur XML-fil Figur 3.2: To skridts proces fra database over datastruktur til XML-fil Skridt 1 - Database til datastrukturer Data fra databasen kan inddeles i en række forskellige kategorier, som igen matcher XML-formatet der skal eksporteres til. Der foretages derfor flere skridt for at udlæse relevant data fra databasen til forskellige datastrukturer.

22 KAPITEL 3. EKSPORT AF DATASTRUKTURER 18 For at organisere denne process kan der laves en exportpakke der indeholder de forskellige datastrukturer. Eksport pakken skal således indeholde en liste af system informationerne, en liste over brugere, en datastruktur til at indeholde objekterne og til sidst en liste over log indlæg, se figur 3.3. Funktionerne der indlæser disse data skal således vide hvilken database der skal udlæses fra, hvilken fil der skal gemmes i, om det er arkiverede, aktive eller alle data der skal eksporteres, og endelig i hvilket omfang log data skal eksporteres. Figur 3.3: eksport pakken i diagram Hvis der således er en funktion til enhver type af data, så vil det være muligt at eksportere nøjagtig hvad der er tiltænkt. Skridt 2 - Datastruktur til XML-fil Da alle data der skal eksporteres ligger i passende datastrukturer er processen med at skrive data ud til en XML-fil lige til. For hver type af data skal der laves en funktion der skriver det pågældende data-objekt til XML. Hele genereringen af XML-filen forløber så ved at gennemgå samtlige data-objekter, og løbende skrive til filen. 3.6 konklusion Der er hermed konstrueret et meta-format til eksport af data fra PlanTool. Formatet dækker alle de informationer systemets brugere har lagt ind i systemet. Informationerne i meta-formatet er uafhængige af systemet og kan derfor anvendes i andre systemer.

23 4 Synkronisering og indlæsning af data Med synkronisering af data forstås der indlæsning af data i systemet fra enten en fil eller fra et andet system, på en sådan måde at data efter en synkronisering indeholde alle data, fra begge datasæt, fra før synkroniseringen, hvoraf de senest opdaterede data er gældende ved sammenfald. Problemerne med synkronisering mellem forskellige instanser af PlanTool består af primært tre dele. Første del af problematikken består i at IDentificere sammenhørende data i forskellige instanser. Anden del består i at bestemme hvilke data der skal være gældende, og dermed tage højde for data der ændret og eventuelt slettet. Endelig kommer dialogen med brugeren for at afklare eventuelle konflikter. Naturligvis kan der også være problemer ved synkronisering mellem forskellige versioner af PlanTool. 4.1 Indlæsning af data Data kan indlæses i et system på tre forskellige måder. Enten som indlæsning i et tomt system, som erstatning af data i et system med eksisterende data eller som synkronisering med eksisterende data. Den første situation hvor der er tale om indlæsning i et tomt system, kan faktisk betragtes som en synkronisering mellem et tomt data sæt, og et fyldt data sæt. Der er derfor ikke nogen grund til at lave specielle funktioner til denne situation. Den anden situation hvor det indlæste datasæt skal erstatte et eksisterende datasæt, svarer til den første situation, hvor det eksisterende datasæt slettes før indlæsningen. Endelig er der synkroniseringen, som behandles i resten af dette afsnit. 4.2 Overordnet synkronisering Basalt set kan synkroniseringen mellem to systemer ses som en fire trins proces som illustreret på figur 4.1. Første skridt er overførsel af data ved hjælp af en datafil fra det ene system til det andet. Dernæst indlæses data i modtager 19

24 KAPITEL 4. SYNKRONISERING OG INDLÆSNING AF DATA 20 systemet, og data bliver her synkroniseret. Det synkroniserede datasæt sendes så tilbage til afsender systemet, der udskifter sit eget datasæt med det nye. Synkronisering ved indlæsning fra en fil er identisk med synkronisering mellem to systemer set udfra det funktionsmæssige synspunkt. Det er nøjagtig de samme funktioner der udfører synkroniseringen. De resterende operationer der foretages ved synkroniseringen mellem systemer, er irrelevante i forbindelse med selve synkroniseringen. Disse operationer med eksport, transport, og overskrivning behandles derfor ikke her. Det følgende omhandler indlæsning af et XML-datasæt eller -fil, og den efterfølgende synkronisering af datasæt. Start A B Synkronisering af datasæt A XML(A) A+B XML(AB) Udskiftning A AB AB Slut AB AB Figur 4.1: Synkronisering mellem to systemer, hvor A og B repræsenterer de enkelte systemers datasæt og AB det synkroniserede datasæt. 4.3 Indlæsning af datasæt Idet et datasæt skal importeres fra en datafil, er der et par indledende problemer der skal håndteres. Som tidligere nævnt kan XML-data importeres i systemet på to måder, enten ved synkronisering eller ved overskrivning. I begge situationer skal det dog undersøges om versionerne stemmer overens, ellers skal der kompenseres for dette. Ved indlæsning af en XML-data er det nødvendigt at undersøge hvilken version datasættet har. I forbindelse med alle opgraderinger af PlanTool skal der derfor laves et modul til indlæsning af datafiler fra tidligere versioner. Hvis der ved hver opgradering laves et modul der kan opgradere fra foregående til nuværende version, vil en sådan stak af konverterings moduler kunne konvertere en hvilken som helst version til den nuværende. Der vil dog straks opstå problemer ved indlæsning af et nyere format i en ældre version af systemet. Denne situation vil dog ikke blive håndteret af systemet, men systemet vil give brugeren besked om at udføre en opdatering. Efter indlæsningen af XML-data, er datasættet klar til synkronisering.

25 KAPITEL 4. SYNKRONISERING OG INDLÆSNING AF DATA Synkronisering af datasæt Synkroniseringen af datasæt, består i sig selv af flere delprocesser. Inddata til processen er to datasæt, et eksisterende og et der skal indlæses. I første omgang skal inddata identificeres i forhold til de eksisterende data. Således at det er muligt at se hvilke elementer der skal opdateres eller slettes og hvilke der skal tilføjes. Dernæst skal nye brugere og planlægningsobjekter tilføjes, og til sidst skal sammenfaldende planlægningsobjekter opdateres, hvis det er nødvendigt. Identifikation af brugere og planlægningsobjekter En af forudsætningerne for at kunne identificere er muligheden for at ændre id er på de forskellige objekter. Når der ændres id for en bruger eller et planlægningsobjekt, skal det samme id ændres alle de steder hvor der er referencer til ændringen. Dernæst skal det være muligt at se hvilke id er der er identificeret. Da alle id er er positive værdier, kan man sætte et minus foran alle id er i inddata. På denne måde er det nemt at se hvilke der er identificeret uden at tilføje ekstra information eller unødige funktioner. Identifikation af brugere Alle brugere har en unik identifikation i deres initialer, og ved at sammenligne disse kan man se hvilke brugere der findes i forvejen. Findes der sammenfald opdateres brugerid erne i inddata så de er identiske med de eksisterende brugeres. Identifikation af planlægningsobjekter I forbindelse med indsættelse af planlægningsobjekter oprettes der en unik identifikationsstreng der kan anvendes til at sammenligne objekter med. Findes der et sammenfald mellem disse identifikations strenge er man sikker på at der er tale om de samme objekter. Er det samme objekt oprettet på to forskellige systemer, så vil denne identifikationsstreng ikke være sammenfaldende og den automatiske identifikation fejler. Projekter har i dette tilfælde faktureringsnumrer som kan bruges til at lave unikke identifikationer på, men opgaver og milepæle har ingen globale identifikationer. Hvis der således ikke findes en match blandt de eksisterende planlægningsobjekter, så skal brugeren manuelt kunne matche objekter i inddata med objekter i det eksisterende datasæt. Eventuelt vil man kunne sammenligne et inddata objekts afhængigheder, med afhængigheder blandt de eksisterende objekter og derved kunne reducere antallet af sandsynlige match.

26 KAPITEL 4. SYNKRONISERING OG INDLÆSNING AF DATA 22 Tilføjelse og opdatering af data Ved tilføjelse af nye data er det vigtigt at alle objekter indsættes før afhængigheder og tidsfrister ændres eller tilføjes. Det er netop derfor at nye data skal tilføjes før eksisterende data opdateres. For hvert objekt der tilføjes skal alle objekter i inddata have informationer om id for det netop indsatte objekt, så alle referencer kan opdateres. Alle de nye brugere tilføjes til systemet ved hjælp af de samme funktioner der normalt anvendes til at tilføje nye brugere. Dernæst tilføjes alle de planlægningsobjekter der ikke blev fundet i forvejen, igen ved anvendelse af de eksisterende funktioner. Efter at objekterne er tilføjet gennemgåes alle objekterne igen for at tilføje afhængigheder og tidsfrister. Til dette anvendes også allerede eksisterende funktioner. Alle brugere og objekter der er identificeret i inddata gennemgås for at se om der er ændringer i forhold til de eksisterende brugere eller objekter. Hvis der er forskelle i data opdateres de eksisterende data, hvis inddata er nyere. Hvis der er tale om et system med kritiske data kan det være nødvendigt at inddrage brugeren i beslutninger omkring opdateringer, for at sikre datasættets gyldighed. Til sidst tilføjes alle log-informationerne, der umiddelbart kan indsættes direkte i systemet, da alle referencer er opdateret. 4.5 Konklusion Det kan konkluderes at synkronisering ikke umiddelbart kan foretages autonomt, samtidig med at entydigheden i datasættet skal garanteres. Dette imødekommes ved at involvere brugeren, i hvert tilfælde.

27 5 Konklusion Jeg kan konkludere at det er lykkedes at konstruere en datastruktur der opfylder de krav blev opstillet fra starten. Datastrukturen fungerer i forbindelse med eksport af data fra systemet PlanTool. Ligeledes kan den samme datastruktur rekonstrueres udfra det eksporterede meta-format. Datastrukturen opfylder også sin opgave i forbindelse med synkronisering af data ind i et eksisterende datasæt. Jeg har ikke konstrueret en direkte transportabel, eller offline, udgave af PlanTool, idet det viste sig at være unødvendigt. Den model PlanTool er bygget over gør at systemet er fuldt transportabelt, og det kan derfor afvikles direkte på andre systemer, hvis der bare er en java platform til stede. Da de data der eksporteres til meta-formatet, kan gendanne den samme datastruktur, må det konkluderes at meta-formatet både kan anvendes til eksport og backup. Meta-formatet er samtidig fuldstændig uafhængigt af PlanTool, med hensyn til repræsentation af data. Da alle data samtidig gemmes på en måde så hele strukturen, og dermed informationen omkring data, er bevaret, kan jeg til fulde kalde det et meta-format. Endelig kan det konkluderes at det er muligt, dog ikke autonomt, at udføre en synkronisering mellem datastrukturer. Planen er nu at systemet i den nuværende udgave skal revideres på baggrund af brugernes evalueringer. Dernæst foretages den næste iteration af udvikling og test af systemet, hvorefter en beta udgave skal afprøves. På langt sigt er det planen at systemet skal fungere som et arbejdsredskab hos Terma A/S. Med PlanTool løser jeg en opgave hos Terma A/S som de konventionelle projektstyrringsværktøjer ikke har kunne løse på en tilfredsstillende måde. Med dette projekt udvider jeg funktionaliteten i PlanTool, og imødekommer hermed yderligere behov i forbindelse med opgave styring 23

28 Litteratur Victor Bryant. Aspects of Combinatorics, A wide-range introduction. Cambridge University Press, ISBN Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. Introduction to Algorithms. The MIT Press, 2 edition, ISBN HSQLDB project page. Hsqldb - 100% java database. org/, year =

29 A DTD definition for eksport format DTD-fil <?xml version=" 1. 0 " encoding="utf 8"?> <!ELEMENT w o r s t c a s e (#PCDATA)> <!ELEMENT version (#PCDATA)> <!ELEMENT u s e r s ( ( u s e r +))> 5 <!ELEMENT u s e r (#PCDATA i d name i n i t i a l s password r o l e c o n f i d e n c e a c t i v e ) > <!ELEMENT type (#PCDATA)> <!ELEMENT t i t l e (#PCDATA)> <!ELEMENT t e x t (#PCDATA)> <!ELEMENT s l a v e (#PCDATA)> 10 <!ELEMENT r o l e (#PCDATA)> <!ELEMENT p r o g r e s s (#PCDATA)> <!ELEMENT password (#PCDATA)> <!ELEMENT parenttype (#PCDATA)> <!ELEMENT p a r e n t i d (#PCDATA)> 15 <!ELEMENT o b j e c t s ( ( o b j e c t +))> <!ELEMENT o b j e c t (#PCDATA i d name i d e n t i f i e r type p r o g r e s s c r e a t e d modified d e s c r i p t i o n i n t e r n a l p r o g r e s s u s e r e s t i m a t e s d e p e n d encies d e a d l i n e s ) > <!ELEMENT name (#PCDATA)> <!ELEMENT moduser (#PCDATA)> <!ELEMENT modified (#PCDATA)> 20 <!ELEMENT master (#PCDATA)> <!ELEMENT l o g s ( ( l o g ) )> <!ELEMENT l o g ( ( user, text, created, parenttype, parentid, t i t l e, o b j e c t ) )> <!ELEMENT l o c k (#PCDATA)> <!ELEMENT l i k e l y c a s e (#PCDATA)> 25 <!ELEMENT i n t e r n a l p r o g r e s s (#PCDATA)> <!ELEMENT i n t e r n a l c o r r e c t i o n (#PCDATA)> <!ELEMENT i n i t i a l s (#PCDATA)> <!ELEMENT i d e n t i f i e r (#PCDATA)> <!ELEMENT i d (#PCDATA)> 30 <!ELEMENT exportpackage ( ( version, u s ers, o b j e c t s, l o g s ) )> <!ELEMENT e s t i m a t e s ( ( user, moduser, b e s t c a s e, l i k e l y c a s e, worstcase, c e r t a i n t y, i n t e r n a l c o r r e c t i o n ) )> <!ELEMENT d e s c r i p t i o n (#PCDATA)> <!ELEMENT dependency (#PCDATA i d u s e r s l a v e master c r e a t e d type l o c k a c t i v e ) > <!ELEMENT dependencies ( ( dependency ) )> 35 <!ELEMENT d e a d l i n e s ( ( d e a d l i n e?) )> <!ELEMENT d e a d l i n e (#PCDATA dependency u s e r moduser d e a d l i n e type c r e a t e d modified a c t i v e ) > 25

30 BILAG A. DTD DEFINITION FOR EKSPORT FORMAT 26 <!ELEMENT c r e a t e d (#PCDATA)> <!ELEMENT c o n f i d e n c e (#PCDATA)> <!ELEMENT c e r t a i n t y (#PCDATA)> 40 <!ELEMENT b e s t c a s e (#PCDATA)> <!ELEMENT a c t i v e (#PCDATA)>

31 B PlanTool PlanTool er et værktøj der løser opgave styring for en arbejds gruppe hos Terma A/S. Arbejds gruppen har forsøgt at anvende forskellige projektstyrings værktøjer på markedet, men ingen af dem har fungeret tilfredsstillende. En af årsagerne er at gruppen arbejder på tværs af mange projekter, samt at visse af opgaverne også ligger under flere projekter. PlanTool er et web-baseret system skrevet i java, systemet afvikles på en web-server med understøttelse af java og servletter 1. Systemet leverer en brugerflade i xhtml-formatet der kan tilgås med en browser. På figur B.1 ses platformen som PlanTool kører på. Figur B.1: Platform for PlanTool B.1 styring i PlanTool I systemet er det muligt at definere planlægnings objekter som projekter, opgave og milepæle. Derudover er det muligt at definere hvorledes disse objekter afhænger af hinanden, ud fra en række regler som systemet sørger for at overholde. Endelig kan en række forskellige egenskaber defineres for de forskellige objekter. 1 fx. Apache Tomcat eller Jetty 27

32 BILAG B. PLANTOOL 28 Projekter Projekter står som en form for forretningsmæssigt objekt, og er således ansvarlige for at holde styr på de informationer der anvendes til fakturering. Det er ligeledes altid et projekt der står i roden for en hver kæde af planlægnings objekter. Et projekt kan både indeholde opgaver, milepæle og andre projekter. r Det egentlige arbejde der skal udføres kaldes for en opgave. Og det er derfor en opgaves ansvar at holde styr på den enkelte opgave med hensyn til hvem der arbejder med denne og hvor meget arbejde der udføres. Milepæle Milepæle er simple grupperinger af planlægnings objekter, eventuelt med en fælles tidsfrist. Milepæle kan ikke indeholde andre planlægnings objekter, og fungerer kun som en liste. Afhængigheder Planlægnings objekter kan afhænge af andre objekter på flere forskellige måder. Objekter kan være afhængige af at andre objekter enten er aktive eller afsluttede, før de selv kan enten aktiveres eller afsluttes. Dette giver altså fire forskellige afhængigheder. Afhængighed A FF B A FS B A SF B A SS B Beskrivelse B kan ikke slutte før A er afsluttet B kan ikke starte før A er afsluttet B kan ikke slutte før A er startet B kan ikke starte før A er startet Tabel B.1: Typer af afhængigheder FF-afhængigheder er klart den vigtigste type af afhængigheder da disse definerer tilhørsforhold mellem de forskellige planlægnings objekter. Dvs. at hvis en opgave indeholder underopgaver, så er det med FF-afhængigheder de er forbundet. Tidsfrister En naturlig egenskab i forbindelse med opgave styring er angivelse af tidsfrister, hvilket naturligvis også er indbygget i systemet. Tidsfristerne nedarves automatisk til andre objekter hvis deres afhængighed dikterer det.

33 BILAG B. PLANTOOL 29 B.2 Status Planen er nu at systemet i den nuværende udgave skal revideres på baggrund af brugernes evalueringer. Dernæst foretages den næste iteration af udvikling og test af systemet, hvorefter en beta udgave skal afprøves. På langt sigt er det planen at systemet skal fungere som et arbejdsredskab hos Terma A/S.

34 C Appendiks DAG.java package s r c. pt. s e r v e r. u t i l s ; import java. u t i l. ArrayList ; import java. u t i l. HashMap ; 5 import java. u t i l. I t e r a t o r ; import java. u t i l. L i n k e d L i s t ; import java. u t i l. Map ; import java. u t i l. Set ; import java. u t i l. Stack ; 10 public class DAG private Map<I n t e g e r, DAGNode> nodes ; private HashMap<I n t e g e r, ArrayList <I n t e g e r >> edgesout ; 15 private Map<I n t e g e r, ArrayList <I n t e g e r >> e d g e s I n ; private int nodeidx ; private int edgecount ; private int edgeidx ; 20 public DAG( ) this. nodes = new HashMap<I n t e g e r, DAGNode>() ; this. edgesout = new HashMap<I n t e g e r, ArrayList <I n t e g e r >>() ; this. e d g e s I n = new HashMap<I n t e g e r, ArrayList <I n t e g e r >>() ; 25 this. nodeidx = 0 ; this. edgecount = 0 ; this. edgeidx = 0 ; 30 public int addnode (DAGNode node ) // Returns the index o f the new node int idx = nodeidx++; nodes. put ( idx, node ) ; 35 // Create e d g e l i s t f o r node edgesout. put ( idx,new ArrayList <I n t e g e r >() ) ; e d g e s I n. put ( idx,new ArrayList <I n t e g e r >() ) ; return idx ; 40 public int addnode ( int key, DAGNode node ) // Returns the index o f the new node nodes. put ( key, node ) ; 45 // Create e d g e l i s t f o r node edgesout. put ( key,new ArrayList <I n t e g e r >() ) ; 30

35 BILAG C. APPENDIKS 31 e d g e s I n. put ( key,new ArrayList <I n t e g e r >() ) ; return key ; 50 public void removenode ( int v ) for ( int i = 0 ; i <edgesout. get ( v ). s i z e ( ) ; i ++) 55 removeedge ( v, edgesout. get ( v ). get ( i ) ) ; edgesout. remove ( v ) ; nodes. remove ( v ) ; 60 public int addedge ( int u, int v ) // I f edge i s i l l e g a l r e t u r n 2 i f ( uppergroup ( u ). c o n t a i n s ( v ) ) return 2; 65 // I f edge e x i s t s r e t u r n 1 i f ( edgesout. get ( u ). c o n t a i n s ( v ) ) return 1; edgesout. get ( u ). add ( v ) ; e d g e s I n. get ( v ). add ( u ) ; edgecount++; 70 return edgeidx++; public boolean removeedge ( int u, int v ) 75 System. out. p r i n t l n ( " Checking f o r Edge : " + u + " to " + v ) ; i f ( edgesout. get ( u ). c o n t a i n s ( v ) ) System. out. p r i n t l n ( " Edge : " + u + " to " + v + " E x i s t s.. " ) ; ArrayList <I n t e g e r > a l = e d g e s I n. get ( v ) ; 80 for ( int i =0; i <a l. s i z e ( ) ; i ++) i f ( a l. get ( i )==u ) a l. remove ( i ) ; 85 System. out. p r i n t l n ( " Removed edgein : " + u + " to " + v ) ; break ; a l = edgesout. get ( u ) ; 90 for ( int i =0; i <a l. s i z e ( ) ; i ++) i f ( a l. get ( i )==v ) a l. remove ( i ) ; 95 System. out. p r i n t l n ( " Removed edgeout : " + u + " to " + v ) ; break ; edgecount ; 100 return true ; return f a l s e ; 105 public ArrayList <I n t e g e r > uppergroup ( int v ) ArrayList <I n t e g e r > ug = new ArrayList <I n t e g e r >() ; Stack<I n t e g e r > s t a c k = new Stack<I n t e g e r >() ;

36 BILAG C. APPENDIKS s t a c k. push ( v ) ; while (! s t a c k. empty ( ) ) int n = s t a c k. pop ( ) ; ug. add ( n ) ; ArrayList <I n t e g e r > e I = e d g e s I n. get ( n ) ; i f ( e I. s i z e ( ) >0) 120 for ( int i = 0 ; i <e I. s i z e ( ) ; i ++) i f (! ug. c o n t a i n s ( e I. get ( i ) ) ) s t a c k. push ( e I. get ( i ) ) ; 125 return ug ; public ArrayList <I n t e g e r > lowergroup ( int v ) 130 ArrayList <I n t e g e r > l g = new ArrayList <I n t e g e r >() ; Stack<I n t e g e r > s t a c k = new Stack<I n t e g e r >() ; boolean f i r s t = true ; int n ; 135 while (! s t a c k. empty ( ) f i r s t ) i f ( f i r s t ) 140 n = v ; f i r s t = f a l s e ; else 145 n = s t a c k. pop ( ) ; l g. add ( n ) ; 150 ArrayList <I n t e g e r > eo = edgesout. get ( n ) ; i f (eo. s i z e ( ) >0) for ( int i = 0 ; i <eo. s i z e ( ) ; i ++) 155 i f (! l g. c o n t a i n s (eo. get ( i ) ) ) s t a c k. push (eo. get ( i ) ) ; 160 return l g ; public ArrayList <I n t e g e r > f a m i l y ( int v ) 165 ArrayList <I n t e g e r > f a m i l y = new ArrayList <I n t e g e r >() ; Stack<I n t e g e r > s t a c k = new Stack<I n t e g e r >() ; s t a c k. push ( v ) ; ArrayList <I n t e g e r > ei, eo ; 170 while (! s t a c k. empty ( ) )

37 BILAG C. APPENDIKS 33 int n = s t a c k. pop ( ) ; f a m i l y. add ( n ) ; 175 e I = e d g e s I n. get ( n ) ; i f ( e I. s i z e ( ) >0) for ( int i = 0 ; i <e I. s i z e ( ) ; i ++) 180 i f (! f a m i l y. c o n t a i n s ( e I. get ( i ) ) &&! s t a c k. c o n t a i n s ( e I. get ( i ) ) ) s t a c k. push ( e I. get ( i ) ) ; eo = edgesout. get ( n ) ; 185 i f (eo. s i z e ( ) >0) for ( int i = 0 ; i <eo. s i z e ( ) ; i ++) i f (! f a m i l y. c o n t a i n s (eo. get ( i ) ) &&! s t a c k. c o n t a i n s (eo. get ( i ) ) ) s t a c k. push (eo. get ( i ) ) ; 190 return f a m i l y ; 195 public int nodecount ( ) return nodes. s i z e ( ) ; 200 public Object getnode ( int n ) i f ( nodes. containskey ( n ) ) return nodes. get ( n ) ; 205 return null ; public void printnodes ( ) 210 System. out. p r i n t l n ( nodes ) ; public void p r i n t A d j L i s t ( ) 215 int nodecount = nodecount ( ) ; int [ ] keys = keyarray ( ) ; S t r i n g tmp ; ArrayList <I n t e g e r > edg ; for ( int i = 0 ; i <nodecount ; i ++) 220 // System. out. p r i n t l n ( edgesout. t o S t r i n g ( ) ) ; edg = edgesout. get ( keys [ i ] ) ; tmp = keys [ i ] + " : > " ; for ( int j = 0 ; j<edg. s i z e ( ) ; j++) 225 tmp += " [ " + edg. get ( j ) +" ] " ; System. out. p r i n t l n (tmp) ; 230

38 BILAG C. APPENDIKS 34 public void printadjmatrix ( ) int nodecount = nodecount ( ) ; 235 int [ ] keys = keyarray ( ) ; int [ ] [ ] AdjMatrix = new int [ nodecount ] [ nodecount ] ; S t r i n g tmp ; ArrayList <I n t e g e r > edg ; for ( int i = 0 ; i <nodecount ; i ++) 240 edg = edgesout. get ( keys [ i ] ) ; for ( int j = 0 ; j<edg. s i z e ( ) ; j++) AdjMatrix [ i ] [ edg. get ( j ) ]=1; 245 for ( int i = 0 ; i <nodecount ; i ++) 250 tmp = " " ; for ( int j = 0 ; j<nodecount ; j++) tmp += " [ " + AdjMatrix [ i ] [ j ] +" ] " ; 255 System. out. p r i n t l n (tmp) ; private Map<I n t e g e r, I n t e g e r > c o l o r ; 260 private LinkedList <I n t e g e r > s o r t i n g ; 265 public ArrayList <I n t e g e r > t o p o l o g i c a l S o r t i n g ( ) s o r t i n g = new LinkedList <I n t e g e r >() ; // Node c o l o r i n g s 0 : White, 1 : Gray and 2 : Black c o l o r = new HashMap<I n t e g e r, I n t e g e r >() ; Set<I n t e g e r > e n t r i e s = nodes. keyset ( ) ; 270 I t e r a t o r <I n t e g e r > i t e r = e n t r i e s. i t e r a t o r ( ) ; // S e t t i n g a l l nodes to white while ( i t e r. hasnext ( ) ) 275 int entry = i t e r. next ( ) ; c o l o r. put ( entry, 0) ; int counter = 0 ; 280 int next = 0 ; while ( c o l o r. c o n t a i n s V a l u e ( 0 ) ) // System. out. p r i n t l n ( " There are s t i l l white nodes " ) ; // System. out. p r i n t l n ( c o l o r ) ; 285 i t e r = e n t r i e s. i t e r a t o r ( ) ; while ( i t e r. hasnext ( ) ) // System. out. p r i n t l n ( " Looking f o r next white node " ) ; int entry = i t e r. next ( ) ; 290 // System. out. p r i n t l n ( " Entry : " + entry + " has c o l o r : " + c o l o r. get ( entry ) ) ; i f ( c o l o r. get ( entry )==0)

39 BILAG C. APPENDIKS 35 // System. out. p r i n t l n ( " Found a white node node : " +entry ) ; next = entry ; 295 break ; // counter++; // i f ( counter >5) break ; 300 dosort ( next ) ; return new ArrayList ( s o r t i n g ) ; 305 private void dosort ( int n ) // System. out. p r i n t l n ( " Examining node : " + n ) ; c o l o r. put ( n, 1 ) ; // s e t node gray ArrayList <I n t e g e r > e = this. edgesout. get ( n ) ; 310 i f ( e. s i z e ( ) >0) for ( int i = 0 ; i <e. s i z e ( ) ; i ++) // System. out. p r i n t l n ( " Edge from " + n + " to " + e. get ( i ) + ". Node "+e. get ( i ) +" has c o l o r : " + c o l o r. get ( e. get ( i ) ) ) ; 315 i f ( c o l o r. get ( e. get ( i ) )==0) // white dosort ( e. get ( i ) ) ; 320 this. c o l o r. put ( n, 2) ; // s e t n black this. s o r t i n g. a d d F i r s t ( n ) ; 325 public int [ ] keyarray ( ) Set<I n t e g e r > e n t r i e s = nodes. keyset ( ) ; int [ ] keys = new int [ e n t r i e s. s i z e ( ) ] ; int counter = 0 ; 330 I t e r a t o r <I n t e g e r > i t e r = e n t r i e s. i t e r a t o r ( ) ; while ( i t e r. hasnext ( ) ) keys [ counter ] = i t e r. next ( ) ; counter++; 335 return keys ; public int renumbernode ( int oldid, int newid ) 340 i f (! nodes. containskey ( o l d I d ) ) return 1; // old node does not e x i s t i f ( nodes. containskey ( newid ) ) return 2; // New node a l r e a d y e x i s t DAGNode dn = nodes. get ( o l d I d ) ; dn. renumbernode ( newid ) ; 345 addnode ( newid, dn ) ; while ( edgesout. get ( o l d I d ). s i z e ( ) >0) int v = edgesout. get ( o l d I d ). get ( 0 ) ;

40 BILAG C. APPENDIKS 36 removeedge ( oldid, v ) ; 350 System. out. p r i n t l n ( " Removed edge : " + o l d I d + " to " + v ) ; addedge ( newid, v ) ; System. out. p r i n t l n ( " Added edge : " + newid + " to " + v ) ; while ( e d g e s I n. get ( o l d I d ). s i z e ( ) >0) 355 int v = e d g e s I n. get ( o l d I d ). get ( 0 ) ; removeedge ( v, o l d I d ) ; System. out. p r i n t l n ( " Removed edge : " + v + " to " + o l d I d ) ; addedge ( v, newid ) ; 360 System. out. p r i n t l n ( " Added edge : " + v + " to " + newid ) ; edgesout. remove ( o l d I d ) ; e d g e s I n. remove ( o l d I d ) ; nodes. remove ( o l d I d ) ; 365 return 1 ; public Map<I n t e g e r, DAGNode> getnodes ( ) 370 return nodes ; DAGNode.java 5 package s r c. pt. s e r v e r. u t i l s ; public interface DAGNode public int renumbernode ( int oldid, int newid ) ; DAGTest.java package s r c. pt. s e r v e r. u t i l s ; import java. u t i l. ArrayList ; 5 public class DAGTest a r g s / 10 public s t a t i c void main ( S t r i n g [ ] a r g s ) DAG s t r u k t u r e = new DAG( ) ; int tmp ; 15 System. out. p r i n t l n ( " " ) ; System. out. p r i n t l n ( " ADDING NODES" ) ; System. out. p r i n t l n ( " " ) ; S t r i n g [ ] nodes = " 2. 1 ", " ", 20 " P r o j e c t 2 ", " 1. 1 ",

41 BILAG C. APPENDIKS 37 " 1. 2 ", " P r o j e c t 1 ", " Disconected node 1 ", " Disconected node 2 " ; for ( int i = 0 ; i <nodes. l e n g t h ; i ++) 25 System. out. p r i n t l n ( " Adding node \" " + nodes [ i ] +" \" " ) ; tmp = s t r u k t u r e. addnode ( i, new testnode ( nodes [ i ] ) ) ; System. out. p r i n t l n ( " Node added with index : " + tmp) ; 30 System. out. p r i n t l n ( " " ) ; System. out. p r i n t l n ( " ADDING EDGES" ) ; System. out. p r i n t l n ( " " ) ; 35 int [ ] [ ] edges = 0, 2, 1, 3, 2, 5, 3, 2, 4, 5, 3, 5 ; for ( int i = 0 ; i <edges. l e n g t h ; i ++) System. out. p r i n t l n ( " Adding edge from node " +edges [ i ] [ 0 ] + " to node " +edges [ i ] [ 1 ] ) ; 40 tmp = s t r u k t u r e. addedge ( edges [ i ] [ 0 ], edges [ i ] [ 1 ] ) ; System. out. p r i n t l n ( " Edge added with index : " + tmp) ; System. out. p r i n t l n ( " " ) ; 45 System. out. p r i n t l n ( " ADJACENCY LIST " ) ; System. out. p r i n t l n ( " " ) ; s t r u k t u r e. p r i n t A d j L i s t ( ) ; 50 System. out. p r i n t l n ( " " ) ; System. out. p r i n t l n ( " ADJACENCY MATRIX" ) ; System. out. p r i n t l n ( " " ) ; 55 s t r u k t u r e. printadjmatrix ( ) ; System. out. p r i n t l n ( " " ) ; System. out. p r i n t l n ( " UPPER GROUPS" ) ; System. out. p r i n t l n ( " " ) ; 60 ArrayList <I n t e g e r > tmpal ; S t r i n g tmps ; for ( int i = 0 ; i <s t r u k t u r e. nodecount ( ) ; i ++) System. out. p r i n t l n ( " Upper group f o r node : " + i + " \" " + s t r u k t u r e. getnode ( i )+" \" " ) ;

42 BILAG C. APPENDIKS tmpal = s t r u k t u r e. uppergroup ( i ) ; tmps = " " ; for ( int j = 0 ; j<tmpal. s i z e ( ) ; j++) tmps += " " + tmpal. get ( j ) ; 70 i f ( j < tmpal. s i z e ( ) 1) tmps += ", " ; tmps += " " ; System. out. p r i n t l n ( tmps ) ; 75 System. out. p r i n t l n ( " " ) ; System. out. p r i n t l n ( " LOWER GROUPS" ) ; System. out. p r i n t l n ( " " ) ; 80 for ( int i = 0 ; i <s t r u k t u r e. nodecount ( ) ; i ++) System. out. p r i n t l n ( " Lower group f o r node : " + i + " \" " + s t r u k t u r e. getnode ( i ) +" \" " ) ; tmpal = s t r u k t u r e. lowergroup ( i ) ; tmps = " " ; 85 for ( int j = 0 ; j<tmpal. s i z e ( ) ; j++) tmps += " " + tmpal. get ( j ) ; i f ( j < tmpal. s i z e ( ) 1) tmps += ", " ; 90 tmps += " " ; System. out. p r i n t l n ( tmps ) ; System. out. p r i n t l n ( " " ) ; 95 System. out. p r i n t l n ( " FAMILIES" ) ; System. out. p r i n t l n ( " " ) ; for ( int i = 0 ; i <s t r u k t u r e. nodecount ( ) ; i ++) 100 System. out. p r i n t l n ( " Family f o r node : " + i + " \" " + s t r u k t u r e. getnode ( i ) +" \" " ) ; tmpal = s t r u k t u r e. f a m i l y ( i ) ; tmps = " " ; for ( int j = 0 ; j<tmpal. s i z e ( ) ; j++) 105 tmps += " " + tmpal. get ( j ) ; i f ( j < tmpal. s i z e ( ) 1) tmps += ", " ; tmps += " " ; System. out. p r i n t l n ( tmps ) ; 110 System. out. p r i n t l n ( " " ) ; System. out. p r i n t l n ( " TOPOLOGICAL SORTING" ) ;

43 BILAG C. APPENDIKS System. out. p r i n t l n ( " " ) ; System. out. p r i n t l n ( " T o p o l o g i c a l s o r t i n g... " ) ; tmpal = s t r u k t u r e. t o p o l o g i c a l S o r t i n g ( ) ; tmps = " " ; 120 for ( int j = 0 ; j<tmpal. s i z e ( ) ; j++) tmps += " " + tmpal. get ( j ) ; i f ( j < tmpal. s i z e ( ) 1) tmps += ", " ; 125 tmps += " " ; System. out. p r i n t l n ( tmps ) ; System. out. p r i n t l n ( " " ) ; 130 System. out. p r i n t l n ( " RENAME NODE" ) ; System. out. p r i n t l n ( " " ) ; s t r u k t u r e. renumbernode ( 3, 245) ; 135 s t r u k t u r e. printnodes ( ) ; s t r u k t u r e. p r i n t A d j L i s t ( ) ; 140 class testnode implements DAGNode S t r i n g name ; public testnode ( S t r i n g name ) 145 this. name = name ; public S t r i n g t o S t r i n g ( ) 150 return name ; public int renumbernode ( int n ) 155 // TODO Auto g e n e r a t e d method stub return 0 ; 160