MARE NOSTRUM. Del 3 Produktrapport

Transkript

1 MARE NOSTRUM Del 3

2 Forord Denne delen av rapporten tar for seg alt som har direkte med produktet å gjøre. Med andre ord hovedsakelig hva produktet er, hvordan det virker og hva slags muligheter for utvidelse man har. For å lese produktdokumentasjonen bør man ha en del bakgrunnskunnskap innen IT. Dette er fordi vi går ut ifra at leseren har grunnkunnskaper innenfor flere av temaene innenfor IT, som for eksempel datastrukturer. Man bør for eksempel også ha litt forkunnskaper om parallellisering og effektivitet. Vi har imidlertid hatt som mål at man kan lese rapporten med så lite forkunnskaper som mulig. Det brukes også en god del begreper som har med shipping å gjøre, disse begrepene ligger forklart i ordliste i vedlegg 1. 2

3 Innholdsfortegnelse 1 Innledning Gruppen Om bedriften Bakgrunn for oppgaven Prosjektmål Beskrivelse av programmet MongoDB MQ, -server og ScheduleImporter AIS-parser og AIS-receiver DepartureArrivalUpdater (Rederistatistikkoppdaterer) HTTP og WEB Kildekodestruktur Samsvar mellom kravspesifikasjon og produkt Kobling mellom rederi og skip Avgjøre hvor i verden en bestemt havn ligger Teknologier og designprinsipper Programmetsoppbygning og virkemåte AIS-parser Beskrivelse av filer Beskrivelse av programflyt for Aisparser Beskrivelse av de andre klassene Schedule-parser Beskrivelse av programflyten Redereristatistikkoppdaterer Beskrivelse av programflyten Visning av punktlighetsstatistikk på web-siden Rederipunktlighet for alle transitter Forsinkelsesprosent over tid Avviksprosent over tid Resten av modulene

4 6.5.1 port ship shipowner Databaseorganisering countries locations schedules.historic schedules.current voyages.traveling voyages.arrivals ship.static ship.voyagedata suppliers shipowners Funksjonelt grensesnitt Anbefalt spesifikasjoner for hardware Driftssikkerhet Avhengighet av eksisterende systemer Schedule-parser Mailserver Utvidelsesmuligheter Aisparser Parallellisering Mer avansert filtrering av data Fjerne bruk av array Aisreceiver Parallellisering Schedule-parser Rederistatistikkoppdatereren Web-applikasjonen Kjente feil Endringer av opprinnelig kode Problemer med Celery

5 Problemer med logging Referanser

6 1 Innledning Prosjektet er et hovedprosjekt ved HIOA. Vi fikk som oppgave om å lage et program som rangerer skipsrederier i forhold til hvor punktlige rederienes skip er. Oppdragsgiveren er Xeneta. Produktet vi har utviklet er et datasystem som skal lagre data om reiseplan for skip(schedules). Det skal også samtidig lagre data om alle skips posisjoner. Produktet skal også finne de mest punktlige rederiene og vise en rangert list over disse over en viss tid. 1.1 Gruppen Gruppen består av Altin Qeriqi, Eirik Lund Flogard og Haimanot Ftsumbrha Tekie. Alle er avgangsstudenter i studiet bachelorstudium i ingeniørfag data. Vi har tidligere jobbet i andre prosjekter sammen og kjenner hverandres sterke og svake sider godt nok til å kunne fordele arbeidsmengden på en hensiktsmessig vis. 1.2 Om bedriften Xeneta er et lite, relativt nytt selskap med kun 6 ansatte. Firmaet er basert på en forretningsidé og et ønske om å gjøre den lukkede shipping markedet mer åpent. Et stort problem som mange av kundene innen shipping har opplevd er at rederiene forlanger priser som ikke er konkurransedyktige. På grunn av dette fungerer markedet i dag nesten som et oligopol. Xeneta sin mål er derfor å gjøre objektiv informasjon lett tilgjengelig for sine kunder, slik at de er i stand til å ta en fornuftig beslutning når det kommer til valg av rederi. 1.3 Bakgrunn for oppgaven I dag tilbyr Xeneta tre abonnementer til sine kunder. Gratisproduktet gir selskapene priser for handelsrutene og tilgang til markedsdata (priser) for de handelsrutene de deler. Det er et Professional -abonnement som tilbyr en månedlig rapport med dypere analyser av hvordan selskapet ligger an i markedet i tillegg til gratisabonnementet. Enterprise -abonnementet tilbyr mulighet til å kjøpe seg tilgang til markedsdata i forskjellige pakker i tillegg til de tilbudene de to overnevnt abonnementer tilbyr. Xeneta ønsker å tilby kundene sine enda en annen pakke. Pakken skal rangere rederier etter hvor punktlige skipene til rederiene er i forhold til tidspunktet rederiene har planlagt at skipene deres skal ankomme havna. 6

7 1.4 Prosjektmål Det er som overordnet mål å bli ferdig med en god løsning som er tilfredsstillende både for oppdragsgivere og for deres kunder. Målene som er beskrevet er kun midlertidige og kan endres eller ytterligere presiseres i løpet av prosjektet. Følgende mål er satt til å nås innen prosjektets slutt: Løsningen skal være et seriøst tilbud fra Xeneta ved å bidra til å redusere kostnader (knyttet til forsinket eller tidlig ankomst av et skip) for deres kunder i størst mulig grad. Løsningen skal være nyttig, og vise mer informasjon om de forskjellige rederiene enn det deres kunder vet eller har tilgang til per i dag. Løsningen bør være veldig nøyaktig, men samtidig være effektiv med hensyn på datakraft. 7

8 2 Beskrivelse av programmet Denne delen av rapporten er ment å gi leseren en rask innføring i hva programmet er og hvordan de forskjellige delene henger sammen. For informasjon om hva de forskjellige delene faktisk gjør, se kapittel 6 i denne rapporten. Figur Et tilpasset diagram som viser dataflyten til systemet for løsningen vi har utviklet. Diagrammet er opprinnelig basert på et diagram vi i samarbeid med oppdragsgiver tegnet i begynnelsen av prosjektet (se forprosjektrapport for det opprinnelige diagrammet). Den eneste betydelige forskjellen mellom dette og det opprinnelige diagrammet, er at vi her har delt opp de forskjellige komponentene i mindre deler slik at de bedre skal beskrive systemet. Diagrammet over viser en forenklet oversikt over hele systemet til Xeneta med sluttproduktet fra prosjektet inkludert. Nedenunder følger en presentasjon av hva de forskjellige komponentene gjør med vekt på hvordan de henger sammen. 2.2 MongoDB MongoDB er et databasehåndteringssystem som er designet for håndtering av dokumentdatabaser. I produktet brukes MongoDB til å lagre alle de ferdigprosesserte dataene som kommer ut fra de forskjellige komponentene. Dette er funksjonalitet som er spesifisert som krav av oppdragsgiver. For noe nærmere informasjon om hva MongoDB er, se kapittel i prosessdokumentasjonen. 2.3 MQ, -server og ScheduleImporter Systemet vi har utviklet i dette prosjektet består av forskjellige uavhengige komponenter. Celery og Message queue-en (MQ) har som ansvar å styre systemet, og delegere oppgaver for de forskjellige 8

9 nodene. MQ lagrer meldinger midlertidig og bestemmer også om data skal mottas og behandles, eller om de skal ignoreres. Celery sørger også for en slags form for høynivåparallellisering der den delegerer disse oppgavene til de forskjellige nodene som brukes i Xeneta sine systemer. E-postmeldinger blir sendt fra -server til meldingskøen(mq i diagrammet) som oppretter en Celery-task. Dersom meldingen inneholder en rutetabellfil (schedule-fil) fra ShipmentLink, sendes filen til (ScheduleImporter) for at den skal parses(tolkes). I ScheduleImporter schedule-filene parses og derretter lagres dataene i MongoDB-databasen. De lagrede dataene brukes senere i DepartureArrivalUpdater. 2.4 AIS-parser og AIS-receiver AIS-parseren består hovedsakelig av to elementer: en dekoder som skal dekode AIS-data, samt en UDP-server som er integrert i selve programmet. Når AIS-parseren mottar AIS-data, vil den prøve å pare og dekode denne. Når dataene er ferdig parset, blir de sendt til modulen AIS-receiver som sørger for å lagre dataene i MongoDB på en hensiktsmessig måte. De lagrede dataene brukes senere i DepartureArrivalUpdater. 2.5 DepartureArrivalUpdater (Rederistatistikkoppdaterer) DepartureArrivalUpdater er klassenavnet på det som i rapporten kalles Rederistatistikkoppdaterer. Den aksesserer MongoDB og bruker data som allerede er ferdigberegnet av AIS-parser og Schedule-parser, til å finne ut når et skip har forlatt og ankommet en havn. Når den har beregnet dette, sammenlignes den ferdigberegnede, virkelige ankomsttiden med den estimerte ankomsttiden i skipets reiseplan(schedule). Av dette vil DepartureArrivalUpdater regne ut avviket mellom de nevnte ankomsttidene og lagre resultatet i MongoDB. 2.6 HTTP og WEB For prosjektet har HTTP og WEB delen ansvaret for å vise statistikk for webside. HTTP refererer til et http-grensesnitt som sørger for å vise webinnhold for verden. For å vise innholdet hentes punktlighetsdataene for rederiene fra MongoDB. Dataene blir så tilpasset og håndtert slik at de vises på websiden som tabeller og diagrammer. 9

10 3 Kildekodestruktur Under vises det en oversikt over mappestrukturen på kildekoden, slik den er ved prosjektets ferdigstillelse. De røde strekene på figuren lengst til venstre viser hvilke mapper og moduler vi har jobbet med under prosjektet. Alt som ligger under mappen dk er basert på noen andres kode. Vi har imidlertid gjort endringer i veldig mange av filene under denne mappen, og tre av filene er opprettet og skrevet av oss. Av plasshensyn har vi valgt å ikke utvide mappene under aismessages. Se kapittel 6.1 for nærmere detaljer rundt dette. Lengst til høyre ligger en oversikt over kode for alle testmodulene som vi har brukt i prosjektet (for å teste Python-kode). Figur Figuren viser en oversikt over mapper og filer i git-repositoriet. 10

11 4 Samsvar mellom kravspesifikasjon og produkt Under utviklingen av prosjektet har vi lagt stor vekt på at produktet og de virkelige, faktiske kravene skal samsvare. Det skal derfor være fint mulig å utlede alle de funksjonelle kravene fra kravspesifikasjonen ut ifra denne rapporten i sin helhet. Mesteparten av de ikke-funksjonelle kravene er der for å sikre kvaliteten på de funksjonelle kravene og selve produktet, så de hører naturlig med til de funksjonelle kravene. Alle delkapitlene under punkt 6 i denne rapporten tar også for seg hvilke krav hver av komponentene er med på å oppfylle. Vi vil imidlertid gjøre oppmerksom på at vi foreløpig ikke kan vite om vi har oppnådd en del av de ikke-funksjonelle kravene som er beskrevet i kravspesifikasjonen. Grunnen til dette er at vi som nevnt i prosessrapporten(4.2.4 ), ikke har mottatt data fra Xenetas leverandører slik at vi ikke har fått mulighet til å utføre noen alpha-testing av systemet. Vi vet imidlertid at systemet virker etter de funksjonelle kravene etter grundig testing av systemet. Det bør nevnes at det iallfall er to av de funksjonelle kravene som kan kreve en del oppfølging når systemet taes i bruk. Dette er presentert i overskriftene under. 4.1 Kobling mellom rederi og skip Krav nummer 5 i avsnitt i Kravspesifikasjonen er som følger Systemet skal kunne holde rede på hvilke skip hvert registrert rederi eier.. For å kunne beregne punktlighet for rederier, må det finnes en måte å vite hvilke rederier som eier hvilke skip. Dette er vanskelig fordi det finnes egentlig ikke noe komplett offentlig register for dette. Foreløpig har vi lagd en database for dette der vi har lagt inn noen få rederier og alle skipene som de eier manuelt. Dette gir imidlertid et veldig begrenset antall rederier som kan vises i statistikken i web-siden. Løsningen på dette ble derfor at Xeneta enten ansetter folk som kan finne ut hva de forskjellige rederiene, eller muligens lage en webløsning som automatisk søker på nettet etter slik informasjon. Å holde databasen oppdatert er ganske essensielt for å holde kravet som nevnt ovenfor, oppfylt på en hensiktsmessig måte. 11

12 4.2 Avgjøre hvor i verden en bestemt havn ligger Krav nummer 6 i kapittel er som følger Systemet må kunne avgjøre i hvilket land eller verdensdel destinasjonen ligger.. Det kan finnes mange steder i verden som har samme navn. Systemet må derfor kunne avgjøre hvilke av disse stedene skipet er på vei til, for å kunne sammenligne posisjonen til skipet og posisjonen for stedet. Vår løsning på dette er å lete etter det landet skipet er på vei til gjennom skipets reiseplan. Sånn sett er kravet ovenfor oppfylt. Men dersom det ikke finnes noe land i skipets reiseplan vil det kastes en exception. Dette kravet bør altså følges opp mer ved å finne flere alternative måter å avgjøre dette problemet på. 12

13 5 Teknologier og designprinsipper For alle teknologier og designprinsipper som er brukt i prosjektet se punkt 4.3 Teknologi i prosessrapporten. Der finnes det en presentasjon og beskrivelse av de mest nevneverdige teknologiene som vi har brukt under prosjektet. For å raskt slå opp begreper knyttet til teknologiene som er nevnt i denne delen av rapporten, se ordliste i vedlegg 1. 13

14 6 Programmetsoppbygning og virkemåte Denne delen av rapporten tar for seg oppbygning og struktur av produktet. Som tidligere nevnt i kapittel 2, er produktet designet slik at den er delt inn i flere forskjellige komponenter. Komponentene i programmet er delt inn etter overskriftene nedenfor. Under overskriftene er det en grundig beskrivelse av programkomponentene og nøyaktig hva hver enkelt komponent gjør, samt referanser til hvilke krav komponenten har til hensikt å realisere. 6.1 AIS-parser Figur Figuren viser et forenklet klassediagram av hele AIS-parseren. Det er viktig å påpeke at når det refereres til Aisparseren i rapporten, så ligger det også mange andre klasser bak som aldri nevnes. Klassediagrammet viser bare enkelte av metodene som brukes, og enkelte av klassene er forenklet (inkluderer ikke klasser som arver). Dette er også bare en liten del av alle klassene som brukes i programmet, men disse klassene som er vist her er de viktigste klassene for å oppfylle en standard brukstilfelle. Det bør også gjøres klart at det brukes ingen nettverksprotokoller i noen av relasjonene mellom klassene i dette diagrammet. Dette programmet består av en UDP-serverapplikasjon som mottar data. Det er tenkt at programmet skal ligge på en bestemt server, slik at den også skal ha tilgang til resten av nettverket som vist på sekvens-diagrammet lengere ned. Denne komponenten tar sikte på å oppfylle krav 1,2 og 3 i kapittel i kravspesifikasjonen. Det er viktig å påpeke at gruppen ikke har laget denne AIS-parseren fra bunnen av, men gjort modifikasjoner på en allerede eksisterende applikasjon. Applikasjonen er frigitt som Open-source 14

15 slik at vi ikke bryter noen kopirettigheter når vi har brukt koden. Opphavsretten har vi latt bli stående i programkoden Beskrivelse av filer Aisparseren består av følgende filer og mapper: Filer: Aisparser.java AisSender.java ThreadedAisparser.java Aisreceiver.py NMEAMessageReceiver.java Mapper: nmea messages exceptions decoder Klassen Aisparser.java kan ses på som grensesnittet inn mot aisparseren. Det er delen av programmet som hovedsakelig sørger for håndtering av arrayer, nettverkshåndtering og håndtering av utskrift. Flere av klassene som er beskrevet i figur 6.1 ovenfor, ligger i mappene nmea, messages og decoder. Modifikasjoner av opprinnelig programstruktur Som tidligere nevnt var dette programmet opprinnelig laget av en annen utvikler. Vi har imidlertid gjort en god del endringer i klasser under mappen nmea, messages og dekoder. Aisparser.java, AisSender.java og ThreadedAisparser.java er alle klasser som vi selv har opprettet. Endringer som er gjort i programmet er hovedsakelig at vi har lagt til funksjonalitet for dekoding av data som manglet (blant annet for mmsi-nummer), i tillegg til at utskriftsformatene er blitt endret slik at de lettere kan behandles med regular expressions senere. Det var også en del unødig utskrift ved feilhåndteringer som vi fjernet fordi det senket prosesseringshastigheten for innkommende data. 15

16 6.1.3 Beskrivelse av programflyt for Aisparser Det første som skjer når programmet mottar AIS-data, er at dataene legges inn i et array. Når arrayen blir fullt, sjekker den om siste entry i arrayen inneholder en ufullstendig melding. Dersom den gjør det, vil arrayen dynamisk utvides til å inneholde meldingen(e) som mangler*. AIS-Parseren er koblet mot en mottaker ( nmeamessagereceiver ) som tar imot, sjekker at formatet er riktig og sender meldingene videre for dekoding. Dette kan man også se på figur under. Selve dekodingene av meldingene skjer enkeltvis melding for melding. For enkelhets skyld kalles denne delen av programmet bare for dekoder i sekvensdiagrammet. Dekoder refererer ikke til noen klasse, men til alle klassene som ligger bak aisparseren og som har ansvar for å dekode dataene. Alle klassene unntatt aisparser i figur 6.1 hører dermed under Dekoder i sekvensdiagrammet under. Figur Det er gjort et bevisst valg å ikke bruke funksjonskall i dette sekvensdiagrammet. Grunnen til dette er at koden er veldig sammensatt, og det er derfor enklere å bruke tekst for å beskrive hvordan de forskjellige delene virker. Det bør også nevnes at aisparser, aisreceiver og aissender på figuren er javafiler som en administrator må starte opp manuelt. Hendelsesforløpet ovenfor vil derfor altså finne sted etter at alle disse tre modulene er startet opp. Diagrammet bruker også noen ekstra piler (som egentlig ikke skal være i sekvensdiagram) for å vise programflyten. 16

17 Etter dataene er dekodet om til bokstaveformat, tester programmet etter hvilken meldingstype meldingen tilhører. Deretter opprettes det en instans av meldingstypen. Dataene blir så sendt som input til denne instansen. Her blir hver enkelt del av inputen lagt inn i sitt riktige datafelt i instansen, ved å ta ut og konvertere bitstrengen som datafeltene ligger på til char s (nøyaktig hvordan datafeltene er organisert avhenger av de første fem bitene som beskriver meldingstype). Når dataene er dekodet blir de returnert til Aisparser.java og sendt til aisreceiver.py gjennom en TCP-tilkobling. *Det bør nevnes at selv om vi utvider arrayen så er det veldig usikkert at meldingen som mangler, blir mottatt allikevel på grunn av at den sendes gjennom UDP-tilkobling Dekoding av AIS-data Dekodingen av AIS-data foregår på følgende måte: Tabellen under viser funksjoner mellom hva hvert tegn i en kodet tekststreng, og hvilke tall/bit de dekodes til. Når data dekodes, vil den gå igjennom alle tegnene fra venstre til høyre og dekode dem om til bits etter denne tabellen. Tabell Dekodingstabell fra char-format til bit-format Char ASCII Decimal Bits "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" ":" ";" "<" "=" ">" "?" "@" "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S" "T"

18 "U" "V" "W" "`" "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" Bit-feltene kan representeres på forskjellige måter. Nøyaktig hvordan de er representert, er spesifisert i en bestemt standard etter hvilken meldingstype meldingen tilhører. For eksempel så er følgende representasjoner mulig: integers (signed/unsigned) float booleans charactes/string reserved og spare bits (brukes kun for å påtvinge 8 bit alignment for adressering av datafelter, så de blir ikke tolket) Det bør nevnes at det er mange flere tabeller og spesialtilfeller for hvordan AIS-data dekodes. For nærmere detaljer om hvordan dataene dekodes, se AIS-dekoding under referanser Beskrivelse av de andre klassene Aisparser med multithreading I tillegg til den normale versjonen av AIS-parseren, har vi lagt til en AIS-parser med støtte for multithreading. Dette skal kunne øke hastigheten på prosesseringen av AIS-data betraktelig i forhold til single-thread-versjonen av programmet, men først og fremst sørge for å forminske mengden med data som går tapt underveis fordi UDP-protokollen ertilstandsløs. Rent funksjonelt fungerer denne imidlertid akkurat som den vanlige versjonen av AIS-parseren. Vi har ikke hatt mulighet til å teste 18

19 denne noe særlig ennå, men vi vet at den er i stand til å legge inn ganske mye mer data enn singlethread versjonen. Vi anbefaler derfor å bruke den vanlige versjonen av AIS-parser når programmet taes i bruk. Programflyt Programflyten til denne er nøyaktig den samme som for originalversjonen, bortsett fra at dekodingen av data, samt sending av data gjennom socket er gjort i trådene mens forelderprosessen lytter på tilkoblingen og legger de innkommende dataene i array. Oppgaven med å dekode data gjøres altså her av tråder. Nedenfor vises det en beskrivelse av versjonen av programmet med multithreading. Som i figur 6.1 brukes det ikke funksjoner for enkelhets skyld og at programflyten skal være lettere å følge med på. Klassen Dekoder representerer ikke en klasse, men alle de indre klassene i AIS-parseren som har ansvar for å dekode data. Figur Som i figur 6.1 har vi her heller ikke valgt å bruke funksjonskall i sekvensdiagrammet fordi det er så mange av dem i koden. Selvfølgelig må man også her starte opp aisparser, aisreceiver og aissender på 19

20 figuren manuelt. thread pool er en klasse i java som egentlig initialiseres i samme øyeblikk som aisparseren starter opp. Diagrammet bruker også noen ekstra piler (som egentlig ikke skal være i sekvensdiagram) for å vise programflyten. Her har vi benyttes oss av cached thread-pool som tar vare på trådene etter at de er opprettet. Når tråden er ferdig med å kjøre, holdes den i live isteden for å stenges av slik at neste gang en tråd opprettes så tar det mye kortere tid. Dette gjør også kjøringen mye mer effektiv i og med at programmet veldig ofte tar i bruk en ny tråd Ais-receiver Denne modulen inneholder en serverapplikasjon som er ment til å brukes til intern overføring av data fra AIS-parseren. Data som er ferdig dekodet fra aisparser.java vil altså bli sendt hit. Her vil dataene så sorteres og legges inn i MongoDB. Når dataene blir mottatt i AIS-receiver vil det bli gjort regextester for å få delt opp dataene slik at det er mulig å legge det inn på serveren. Siste del av figur 6.2 og figur 6.3 viser hvordan denne delen av programmet virker og samhandler med resten av AIS-parseren. Det er veldig viktig å legge merke til at AIS-receiver tar utgangspunkt i at inputen den får, faktisk kommer fra AIS-Parseren. Dersom man prøver å legge sende tilfeldig, ugyldig input til AIS-receiveren så kan programmet krasje. Kontroll av dataintegritet foregår av effektivitetsmessige grunner i selve AIS-parseren. AIS-receiveren vil også sjekke AIS-dataene for å avgjøre hva slags type de er. Dette må gjøres for å avgjøre i hvilken collection de skal inn i. Positionreports vil for eksempel havne inn i ship.static collection-en (noen av dataene vil også legges inn i ship.voyagedata ), mens voyagedata vil havne inn i ship.voyagedata. I forhold til plassering i systemet er ais-receiver i sin nåværende tilstand, ment å plasseres på en server som har installert pymongo-biblioteket AIS-sender Denne klassen/modulen kan benyttes ved endringer eller for å teste input av data lokalt. Den vil lese en fil nmea.dump fra maskinen og sende innholdet av den til AIS-parseren gjennom UDP-protokoll via nettverket. Denne klassen kan brukes dersom man ønsker å teste spesielle data. Dette må gjøres fordi AIS-parseren tar i mot dataene sine fra UDP-tilkobling. Plasseringen for AIS-senderen kan være hvor som helst, men den bør ligge på samme nettverk for enkelhets skyld. 20

21 6.2 Schedule-parser En av de funksjonelle kravene (avsnitt i Kravspesifkasjonen) i dette prosjektet var å kunne få opp en rangert liste over punktligheten til rederier. For å beregne punktlighetsstatistikker trenger man å sammenligne estimert ankomsttid og faktisk ankomsttid. Informasjon om når et skip skal dra fra en havn og når den er forventet å ankomme bestemmelsesstedet fikk vi tak i ved å abonnere på rutetabeller på ShipmenLink ( Disse rutetabellene sendes som tekstfiler og kommer i et bestemt format. Den delen av programkoden som går på å parse (tolke) disse filene og lagre reiseplanene i databasen er beskrevet i avsnittene under. Schedule-parser har til hensikt å oppfylle krav nummer 4, 5 og 6 i avsnitt i Kravspesifikasjonen. I modulen schedule_importer.py (i mappen xeneta/marenostrum/schedule) ligger det en klasse som heter ScheduleImporter. Denne klassen er ansvarlig for å parse (tolke) rutetabellene (schedules) som sendes fra ShipmentLink en gang i uken og lagrer informasjon om reisene i databasen Beskrivelse av programflyten Figur 6.4 viser sekvensdiagram for hovedscenarioet til den delen av programmet som har med parsing av rutetabellfiler fra ShipmentLink å gjøre. Alle metodekallene i ScheduleImporter er ikke vist. Det ble tatt med nok informasjon i sekvensdiagrammet for å få med seg at reisene fra/til en region er gruppert sammen og det for hver gruppe parses flere linjer med reiseplaner. Les mer om dette i avsnittet Parsing av schedule-filer ( ). 21

22 Figur Sekvensdiagram for schedule-parseren. Bare de viktigste metodekallene er vist, nok til å vise tydelig hvordan parsing av schedule-filer skjer E-post fra ShipmentLink Shipmentlink.com sender en gang i uken en e-postmelding til alle som abonnerer på schedule-filer. Denne e-postmeldingen kommer med en tekstfil som inneholder en liste over skipsreiser flere måneder i fremtiden for flere containerskip. E-postadressen "shipmentlink@marenostrum.xeneta.com ble abonnert på ShipmentLInk. Når en e-postmelding sendes til shipmentlink@marenostrum.xeneta.com, lagres den i e-postserveren og det opprettes en Celery-task som igjen oppretter et objekt av typen Handler. En stor del av denne klassen er implementert av Xeneta; bare den delen av klassen som videresender e-postmeldinger til DataHandler er 22

23 implementert av oss. Når en instans av klassen Handler opprettes, analyseres til-adressen og det avgjøres hvor den skal sendes videre. E-postmeldinger som sendes til ender og sendes videre til klassen DataHandler. Denne klassen har vi implementert selv. I klassen DataHandler sjekkes det om det er en gyldig e-postmelding som inneholder en gyldig schedule-fil fra shipmentlink.com. E-postmeldingen må inneholde bare ett filvedlegg og filvedlegget må være en txtfil og ha et filnavn på formatet "Schedules_YYYYMMDD.txt" der YYYY er året, MM er måneden og DD er dagen i datoen på schedule-filen. Når alt dette er verifisert kan parsing av schedule-filen startes Parsing av rutetabellfiler Skipsrutetabellfilene (schedule-filer) fra ShipmentLink kommer heldigvis i samme format hver gang, men det hender noen ganger at formatet varierer litt. Som beskrevet i prosessrapporten i avsnitt ble det brukt en del tid på å lage en robust parser som har en toleranse for små variasjoner i filene. Schedule-filene er delt opp i flere grupper og undergrupper. Det finnes grupper for reiser fra en bestemt region/kontinent til en annen region/kontinent og i hver av disse regionsgruppene finnes det handelsrutegrupper som forteller deg litt om hvilke del av regionene eller hvilket land reisene gjelder for. Nedenfor er det vist et eksempel på en av disse handelsrutegruppene. Det finnes to linjer som starter med navnet på skipet og en voyage-id (reisenummer). En reise (voyage) for et skip kan altså bety at den besøker flere havner. For hver havn kan man se datoen på estimert ankomsttid (ETA) og estimert avgangstid (ETD) for reisen til skipet. Eksempelet under viser at skipet Ever Ethic skal reise fra Ashdod den 1. mars til Dekheila Alexan (Alexandria) med estimert ankomsttid den 2. mars. ================================================== ShipmentLink Sailing Schedules U.S. West Coast-Asia-Mediterranean Service(UAM) ================================================== DEKHEILA ALEXAN ASHDOD DEKHEILA ALEXAN =========== =========== =========== ETA ETD ETA ETD ETA ETD EVER ETHIC E 02/26 02/27 02/28 03/01 03/02 03/04 EVER UNISON E /07 03/08 03/09 03/10 Som nevnt i forrige avsnitt finnes det flere handelsrutegrupper og som man kan se i sekvensdiagrammet (figur 6.4), parses det i hver handelsrutegruppe flere linjer med reiseplaner. Alle reiseplanene lagres i en liste som er knyttet til et skipsnavn. Etter at alle rutetabellene er parset, vil det lagres en dictionary med navnet på skipet som nøkkel og en liste over dens reiser. Reiser for et skip kan stå på ulike grupper og det finnes flere repetisjoner. Det ble derfor laget en metode i klassen ScheduleImporter (ikke vist i sekvensdiagrammet), kalt create_from_to_schedule(), som fjerner repetisjoner, fletter reiser og lager en liste over alle reiser et skip skal ta. 23

24 Etter at alle reiser for alle skipene er funnet, kan de lagres i databasen. Det finnes to collections i databasen som reiseplanene skal lagres i: schedules.historic og schedules.current. I den første lagres et dokument for hvert skip. I hvert av dokumentene finnes det en array av reiseplandokumenter. Hvert av disse reiseplandokumentene inneholder havnekoder for havnen skipet skal reise fra og havnekoden til havnen skipet skal reise til. Det skal også legges til estimert avgangstid (ETD) og estimert ankomsttid (ETA). Den statiske metoden get_port_code() i klassen ScheduleImporter brukes til å få tak i havnekoden til en havn. I den andre collection-en lagres den samme informasjonen, men bare reiser for neste uke tas med. For å finne reisene for uken etter må man først finne ut hvilke skip som skal reise. Dette gjøres ved å trekke ut en dato fra schedule-filnavnet. Hvis denne datoen er i samme uke som den uken tidspunktet schedule-filen blir parset i, lagres alle reisene i denne collectionen. Disse skal brukes av den delen av programmet som skal sjekke om et skip har begynt å bevege seg fra havnen (avsnitt ). 6.3 Redereristatistikkoppdaterer Som nevnt i kravspesifikasjonen er en av de funksjonelle kravene å kunne få opp en rangert liste over punktligheten til rederier. Schedule-parseren (beskrevet i kapittel 6.2) lagrer informasjon om reiser med estimert avgangs- og ankomsttid, både for flere uker i fremtiden og det som er relevant: Skipsreiser i den førstkommende uken. Vi trenger altså å hente listen over planlagte reiser for den uken vi er i og avgjøre om et skip har forlatt havnen og å finne ut når et skip har ankommet en havn. Når et skip har ankommet til bestemmelsesstedet oppdateres punktlighetsstatistikken for det rederiet skipet tilhører. I dette kapitlet blir den delen av koden som gjør alt dette beskrevet. I beskrivelsen av programflyten er det referert til feltnavn i dokumenter og navn på collection-er. En nærmere beskrivelse av hvordan dokumentene i disse collection-ene er bygget opp finnes i kapittel 7. Det bør nevnes at rederistatistikkoppdatereren har til hensikt å oppfylle krav 1-6 i avsnitt i Kravspesifikasjonen Beskrivelse av programflyten Den delen av programmet som skal sjekke om et skip har forlatt eller ankommet en havn er klassen DepartureArrivalUpdater (i modulen lanes.py). Den skal kjøres flere ganger i løpet av dagen og må derfor kjøres av Celery beat, som er en del av Celery og som kan kjøre periodiske oppgaver i bestemte tidspunkter. Foreløpig er programmet innstilt på å kjøre en gang i timen. Og på grunn av dette, må forsinkelser rundes ned til nærmeste time. Sekvendiagrammet under (figur 6.5) viser programflyten til denne delen av programmet. En detaljert beskrivelse av programflyten står i avsnittene under diagrammet. 24

25 Figur Sekvensdiagram for programdelen som oppdaterer rederipunktlighetsstatistikk Registrering av skip som har ankommet bestemmelsesstedet Etter at en instans av DepartureArrivalUpdater-klassen er opprettet, kan avgangs- og ankomstsjekken startes med metoden check_departures_and_arrivals(). Det startes med å sjekke alle dokumenter i 25

26 collection-en som heter voyages.traveling. I denne collection-en finnes det dokumenter som inneholder skipsinformasjon, estimert avgangs- og ankomsttid og virkelig avgangstid. Skipet må registreres på at den har forlatt den havnen den skulle først. Les mer om nøyaktig hva som er lagret i databasen i kapittel 7. Flydiagrammet i figur 6.6 viser programflyten i metoden som returnerer ankomsttiden til et skip, altså metoden get_arrival_time(). For hvert skip som er på vei til en havn hentes siste posisjonsdata fra databasen via modulen ship.py som ligger i mappen xeneta/marenostrum. Hvis tidsstempelet til posisjonsdataene er eldre enn intervallet mellom hver gang dette programmet kjøres (en gang i timen), ignoreres de og skipet antas å ikke ha ankommet havnen. Dersom den siste posisjonsinformasjonen er ny, sjekkes det om skipet har sluttet å bevege seg. Hvis det siste er tilfelle sjekkes det om skipet er nær destinasjonshavnen (metoden is_near_port() i modulen port brukes). Tidsstempelet til siste posisjonsrapport returneres hvis skipet er mindre enn én radian (en lengdegrad eller breddegrad) fra posisjonen til havnen, ellers antas det at skipet ikke har ankommet haven. Dokumentet merkes for sletting ved å legge inn feltet nøkkelen toa (time of arrival). Figur Flytdiagram for metoden get_arrival_time() i klassen DepartureArrivalUpdater. 26

27 Dokumentene i collection-en voyages.traveling for de skipene som har ankommet en havn, blir fjernet og kopiert over til i arrayen voyages i MongoDB-dokumentet for skipet som ligger i collection-en voyages.arrivals. Men før den kopieres over, legges det til to tall i dokumentet: Antall estimerte reisedager og antall timers avvik fra ETA-datoen. Disse tallene kan blant annet brukes til å beregne avvik fra den planlagte reisetiden i prosent for akkurat denne transitten (reisen) Oppdatere punktlighetsstatistikker for rederier Når transittinformasjonen er lagret i dokumentet for skipet reisen gjelder for, oppdateres punktlighetsstatistikken for rederiet som eier skipet. På web-siden som skal vise en liste over rederier rangert etter punktlighet (se kapittel 6.4), trenger vi å beregne prosentdelen av transittene som ble forsinket og avvik fra den planlagte reisetiden i prosent. Vi trenger derfor å lagre en del tall i dokumentet for rederiet som ligger i collection-en shipowner. Siden vi skal ha aggregerte data for alle reisene som er registrert på hvert rederi, trenger vi å bare inkrementere de tallene som allerede er der. Disse tallene er totalt antall transitter, totalt antall transitter med forsinkelser, totalt antall estimterte reisedager og totalt antall timers avvik fra ETA-datoene til reisene (trukket ut fra schedule-filene fra ShipmentLink). I modulen shipowner.py (xeneta/marenostrum/shipowner.py) finnes det funksjoner som beregner prosenttallene som brukes i web-siden. Les mer om dette i avsnittet om modulen shipowner (avsnitt 6.5.3). Etter at alle dokumentene er sjekket slettes alle dokumenter i collection-en voyages.traveling som inneholder nøkkelen toa, altså alle skipsreisene som har en ankomsttid. Dette blir gjort fordi det kan oppstå problemer med å slette dokumenter i en collection mens man itererer dem Registrering av skip som har forlatt havnen Reiseplanene (schedules) som lagres som dokumentene i databasen og som ligger i collection-en schedules.current itereres. For hvert dokument sjekkes det først om MMSI-nummeret til skipet er kjent ved å kalle metoden get_mmsi() i modulen ship.py (xeneta/marenostrum/ship.py). Hvis ikke MMSI-nummeret finnes, hoppes det over til neste dokument, skipet ignoreres altså. For hver eneste reiseplan-dokument i arrayen schedules sjekkes det om den er for gammel (eldre enn 1 uke), hvis den er det blir den slettet. Etterpå hentes avgangstiden til skipet ved å kalle metoden get_departure_time(). Virkemåten til denne er nesten det samme som i metoden get_arrival_time(), bare at her returneres avgangstiden hvis skipet er i bevegelse og at skipet er i nærheten av havnen som den hadde planlagt å reise fra. 27

28 Hvis avgangstiden returneres fjernes reiseplandokumentet fra schedules.current og metoden register_departure() i samme klasse kalles. I den sistnevnte metoden lages et nytt dokument i collection-en voyages.traveling. Dette dokumentet inneholder de samme nøkkel-verdiparene som i reiseplandokumentet som ble slettet og i tillegg blir MMSI-nummeret til skipet, virkelig avgangstid (toa, time of arrival), navnet og ID-en til rederiet lagt til i dokumentet. 6.4 Visning av punktlighetsstatistikk på web-siden Som nevnt i kravspesifikasjonen og flere ganger i denne rapporten, er en av de viktige funksjonelle kravene å vise hvilke rederier som er de mest punktlige. For å vise dette har vi lagd en webapplikasjon (modulen rendereling_templates.py i mappen xeneta/marenostrum/web) som viser på en web-side punktlighetsstatistikker for rederier som det er registrert transitter på. Det finnes tre seksjoner på web-siden. Nedenfor er det beskrevet hva slags statistikk som finnes i de forskjellige seksjonene på web-siden. Alle verdiene hentes fra funksjoner som finnes i modulen shipowner.py (6.5.3). Verdiene kan virke urimelige fordi de aggregerte tallene i databasen er bare testdata som vi var nødt til å lage selv(se på avsnittet i prosessrapporten). Informasjonen på web-siden er skrevet på engelsk. Det kan nevnes at web-siden og tilhørende moduler kan ses på som en realisering av krav 7, 8 og 9 i kapittel i Kravspesifikasjonen. Web-applikasjonen kjører på testserveren og adressen til websiden er hioa-project.xeneta.com. Vi har brukt Flask som rammeverk og Jinja som template engine. Python-pakken Flask ble installert og ble lagt til i utviklingsverktøy vi brukte (Eclipse). Flask-pakken inneholdt Jinja2 template engine. Vi har kun én modul, rendering_templates.py, som tar seg av websiden. Vi importerte Flask klassen til modulen og opprettet en instans av klassen slik: app = Flask( name ) app er vår WSGI-applikasjon og det første argumentet den tar er navnet på applikasjonens modul. Dette gjør at flask vet hvor den skal lete etter mal (template), statiske filer og liknende filer som tilhører web-siden. Modulen har kun en funksjon, index(). Funksjonen er annotert med flask / ). Dette gjør at funksjonen blir trigget av rot URL-en. index()-funksjonen returnerer en flask-funksjon som kalles render_template. Den tar to parametere. Den første parameteren er template-navnet som vi skal bruke. Den andre parameteren er variablene som skal være tilgjengelige i templatens kontekst. Disse variablene er tilgjengelige i templatene (html filer) og deres innehold kan trekkes ut og brukes i templatene ved bruk av template-motoren jinja2. 28

29 Filene som ligger under static mappen (css, js, img) er hentet fra Twitter Bootstrap og resten er andre static filer som vi trengte for web-siden. Under mappen templates ligger html filene som vi har brukt for websiden. Noen av HTML-filene inneholder også javascript-kode som genererer grafer på websiden Rederipunktlighet for alle transitter I den øverste seksjonen på web-siden finnes det en tabell som viser en liste over alle rederier som det er registrert transitter på. Tabellen viser også antall transitter registrert på rederiet, prosentdelen av transittene som har ankomsttid som avviker fra ETA-datoen og total avvik fra ETA-datoene i prosent. Alle prosenttallene er rundet av til to desimaler etter desimalskilletegnet. Tabellen er sortert i stigende rekkefølge etter prosenttallet for transitter som ikke ankom i tide, men brukeren kan endre sorteringen på tabellen ved å klikke på tabellheaderen. Over tabellen står det beskrevet hvordan punktlighetsstatistikkene er beregnet. Figur 6.7 viser den øverste seksjonen på web-siden. Prosentdelen av transittene som ble forsinket eller kom for tidlig finnes i andre kolonne i tabellen. Tallet beregnes ved å dele totalt antall transitter som er forsinket eller kom for tidlig på totalt antall transitter og multiplisere dette tallet med 100. Avviksprosenten ( Deviation percentage ) viser avvik i prosent mellom transittenes virkelige ankomsttider og de estimerte ankomsttidene (ETA, Estimated time of arrival) i forhold til totalt antall estimerte timer. Med avvik fra estimert ankomsttid menes det antall timer skipene har ankommet bestemmelsesstedene for tidlig eller for sent i forhold til ETA-datoen. Dette tallet viser en bedre oversikt over hvor punktlig et rederi er fordi den tar hensyn til lengden på transittiden, en fire timers forsinkelse på en 12-dagers transitt skal ha mindre påvirkning på punktligheten enn en to timers forsinkelse på en 2-dagers transitt. Avviksprosenten beregnes ved å bruke formelen: 100 * (1 - (((TETD * 24) - TDH) / (TETD * 24))) hvor TETD er totalt antall forventede reisedager og TDH er totalt antall timer som avviker fra ETAdatoene. Eksempel på avviksprosent: Hvis et skip ankommer en havn en time tidligere eller senere enn ETAdatoen for en transitt som var estimert til å ta 4 dager, så vil transitten ha en avviksprosent på 100 * (1 - (((4 * 24) - 1) / (4 * 24))) =

30 Verdiene i tabellen hentes ved å kalle metoden get_shipowners_with_percentage_stats() som ligger i modulen shipowner.py. En beskrivelse av denne metoden står i avsnitt i Som nevnt tidligere, blir prosenttallene rundet av til to desimaler. Figur Den øverste seksjonen på web-siden viser en tabell over punktlighetsstatistikker til rederier Forsinkelsesprosent over tid I denne seksjon på web-siden finnes det to grafer. Hver av grafene viser forsinkelsesprosenten over tid de siste 18 månedene. I den første grafen vises forsinkelsesprosenten for alle transitter hver måned for et rederi. Det vil derfor variere veldig mye fra måned til måned for de fleste av rederiene. Verdiene hentes fra funksjonen get_shipowners_pct_statistics_over_time() i modulen shipowner.py. I den andre grafen vises den kumulative forsinkelsesprosenten for alle transitter hver måned for et rederi. Den kumulative forsinkelsesprosenten for en spesifikk måned beregnes ved å summere antall transitter for denne måneden med antall transitter i alle tidligere måneder og dele dette tallet med antall forsinkede transitter i den spesifikke måneden og tidligere. Kumulativ betyr ikke at prosenttallet 30

31 for en spesifikk måned summeres med prosenttallene for tidligere måneder, men tallene som brukes som grunnlag for å beregne prosenttallene summeres sammen. Grafen har interpolerte verdier mellom månedene. Verdiene hentes fra funksjonen get_shipowners_cumulative_pct_statistics_over_time() i modulen shipowner.py. Figur Seksjonen av web-siden som viser prosentdelen av transittene som avviker fra ETA-datoen. 31

32 6.4.3 Avviksprosent over tid I den nederste seksjonen på web-siden vises avviksprosenten over tid de siste 18 månedene. Se i avsnittet Rederipunktlighet for alle transitter (avsnitt 6.4.1) for en nærmere forklaring av hva avviksprosent betyr. I den første grafen vises avviksprosenten for alle transitter hver måned for et rederi. Det vil derfor variere veldig mye fra måned til måned for de fleste av rederiene. Verdiene hentes fra funksjonen get_shipowners_pct_statistics_over_time i modulen shipowner.py. Akkurat som i forsinkelsesprosentdelen av websiden finnes det også en graf som viser det kumulative prosenttallet over tid. Grafen viser den kumulative avviksprosenten fra ETA-datoen for alle transitter hver måned for et rederi. Den kumulative forsinkelsesprosenten for en spesifikk måned beregnes ved å summere både antall forventede transittdager og det totale antallet timer som avviker fra ETA-datoen for den spesifikke måneden og tidligere måneder. Dermed brukes disse to tallene i den formelen som er vist i avsnittet Rederipunktlighet for alle transitter (avsnitt 6.4.1). Grafen har interpolerte verdier mellom månedene. Verdiene hentes fra funksjonen get_shipowners_cumulative_pct_statistics_over_time() i modulen shipowner.py. 32

33 Figur Avviksprosentdelen av web-siden. 6.5 Resten av modulene I pakken xeneta.marenostrum finnes det tre andre moduler som ikke er beskrevet grundig tidligere. Disse modulene inneholder bare funksjoner som skal brukes av andre moduler til å hente fra databasen informasjon om havner, skip og rederier. 33

34 6.5.1 port Modulen port (xeneta/marenostrum/port.py) inneholder foreløpig bare én funksjon: is_near_port(). Denne metoden returnerer sannhetsverdien på om en koordinat er nær koordinaten til en havn. Havnekoden og koordinatene sendes som argument til metoden. Metoden bruker collection-en locations og metoden fungerer bare hvis geografisk 2D-indeks er satt inn i denne collection-en ship Modulen ship (xeneta/marenostrum/ship.py) inneholder to funksjoner: get_mmsi() og get_last_position_data(). Den første funksjonen returnerer MMSI-nummeret til det skipet med samme skipsnavn som sendes som argument. Funksjonen get_last_position_data() returnerer det siste posisjonsdokumentet for det skipet som har samme MMSI-nummer som det som sendes som argument. Posisjonsdokumenter finnes i arrayen positions i collection-en ship.voyagedata (se kapittel 7) shipowner Denne modulen (filsti: xeneta/marenostrum/shipowner.py) inneholder flere funksjoner som returnerer punktlighetsstatistikker og informasjon om rederier. Den er ment for å brukes til å hente statistikkdata for å vise dem på websiden med punktlighetsstatistikker. Det finnes bare funksjoner og ingen klasser i denne modulen. I hver funksjon finnes det en docstring som forklarer hva funksjonen returnerer og hvilke argumenter som skal sendes til funksjonene. Det er derfor ikke nødvendig å forklare her hva funksjonene gjør i detalj. En nærmere beskrivelse av de forskjellige punktlighetsstatistikkene står i avsnittet Visning av punktlighetsstatistikk på websiden (kapittel 6.4). Funksjonen get_ship_owner_info() returnerer en dictionary med navnet på rederiet og ID-en til rederiet (finnes i collection-ene suppliers og shipowners ) som eier skipet som har det MMSInummeret som sendes som argument. Funksjonen get_shipowners_with_percentage_stats() returnerer en liste av rederier sammen med punktlighetsstatistikker for alle reisene som er foretatt under rederiets navn. Rederiets navn, antall transitter registrert på rederiet, prosent av transitter med ankomsttid som avviker fra ETA-en og total avvik fra ETA-en i prosent returneres. Denne metoden beregner alle prosenttallene før de returneres. Det er anbefalt å lagre så mye data som mulig i en MongoDB-database og det hadde derfor vært aktuelt å lagre selve prosenttallene i databasen, da slipper man å bruke unødvendig med CPU-ressurser hver gang metoden skal returnere punktlighetsstatistikker til brukere som åpnet web-siden. 34

35 Funksjonen get_shipowners_with_percentage_stats_month_year() returnerer en liste av rederier sammen med punktlighetsstatistikk for alle reisene i et bestemt år eller for et bestemt måned, avhengig av hvilke argumenter som sendes til metoden. Man kan velge å returnere enten forsinkelsesprosenten eller avvik fra ETA-en i prosent. get_shipowners_pct_statistics_over_time() -funksjonen returnerer en liste av rederier sammen med punktlighetsstatistikker for alle reisene i et bestemt tidsintervall. Man kan sende inn det startåret og startmåneden og/eller sluttåret og sluttmåneden. Funksjonen get_shipowners_cumulative_pct_statistics_over_time() gjør det samme som funksjonen get_shipowners_pct_statistics_over_time(), men for hver måned akkumuleres alle tall for tidligere transitter. Denne funksjonen bruker hjelpefunksjonen calculate_supplier_cumulative_percentage_stats(). 35

36 7 Databaseorganisering MongoDB er som nevnt i prosessrapporten i avsnitt et dokumentorientert databasehåndteringssystem. MongoDB inneholder dokumenter som har et eller flere nøkkel-verdipar. Flere dokumenter kan grupperes i noe som kalles collection. Dette avsnittet inneholder en detaljert beskrivelse av alle de collection-ene som er relevante for dette prosjektet. Strukturen i MongoDBdatabaser kan ikke visualiseres i ER-diagrammer fordi det sjelden finnes relasjoner mellom collectioner og verdiene i dokumenter kan også være dokumenter, arrayer og andre datatyper. Derfor er de visualisert på den måten MongoDB skriver dem ut på terminalen, men istedenfor å ta med verdieksempler, er forventet datatype til verdiene tatt med. I dette prosjektet ble databasen på testserveren med databasenavnet marenostrum brukt. Siden vi ikke har tilgang til AIS-data som sendes i sanntid til testserveren for prosjektet, vil det ikke gi noen mening å kjøre Rederistatistikkoppdatereren (klassen DepartureArrivalUpdater, se kapittel 6.3). Dette betyr at flere av collection-ene ikke finnes i databasen, men de opprettes under kjøring av enhetstesten for DepartureArrivalUpdater og slettes etter at enhetstesten er fullført. AIS-parseren, som også tar i mot AIS-data, er det heller ikke noen mening å kjøre hele tiden, med mindre man skal teste den. De dokumentene som finnes i collection-ene som ikke burde ha vært med i databasen inneholder bare testdata. Celery har sluttet å fungere fordi det ble gjort endringer i koden som hadde med konfigurasjonen av Celery å gjøre. Les mer om dette i kapitlet om driftssikkerhet (kapittel 9). Dette betyr at Scheduleparseren (klassen ScheduleImporter) ikke kan motta rutetabellfiler fra ShipmentLink og dette betyr igjen at det ikke finnes dokumenter i collection-en schedules.current. Dette forklarer også hvorfor det ikke finnes dokumenter som ligger schedules.historic som er nye. 7.1 countries Denne collection-en brukes ikke direkte av noen moduler som vi har laget selv. I ScheduleImporterklassen brukes en funksjon som er implementert av oppdragsgiveren og som brukes til å finne havnekoden til en havn. Det er her countries brukes. 7.2 locations Denne collection-en er ikke laget av gruppedeltagerne, men av Xeneta. Collection-en inneholder informasjon om havner og andre steder som er tilknyttet sjøhavner (landhavner). De fleste av havnene 36