MARE NOSTRUM. Hovedprosjekt. Bachelorstudium i ingeniørfag data og informasjonsteknologi

Transkript

1 MARE NOSTRUM GRUPPE 17 Altin Qeriqi Eirik Lund Flogard Haimanot Ftsumbrhan Tekie Hovedprosjekt Bachelorstudium i ingeniørfag data og informasjonsteknologi 2013

2

3 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR HOVEDPROSJEKT TILGJENGELIGHET LUKKET Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Mare Nostrum DATO ANTALL SIDER / BILAG 154 / 2 PROSJEKTDELTAKERE Altin Qeriqi (160934) Eirik Lund Flogard (169963) Haimanot Ftsumbrhan Tekie (163488) INTERN VEILEDER Thor Hasle OPPDRAGSGIVER Xeneta AS KONTAKTPERSON Vilhelm K. Vardøy SAMMENDRAG Prosjektet går ut på å finne en måte å samle inn data om trafikk for frakteskip eller tankskip. Hensikten er at man med disse dataene skal kunne få oversikt over blant annet pålitelighet innenfor shippingmarkedet. Med de innsamlede dataene skal en bruker blant annet kunne hente ut statistikk over punktlighet for et rederi. 3 STIKKORD Datainnsamling Shipping Rederipunktlighet

4

5 Forord Dette er en rapport som handler om hvordan planleggingen og utviklingsprosessen foregikk under gjennomføringen av prosjektet Mare Nostrum. Prosjektet er et hovedprosjekt i bachelorstudium i ingeniørfag data og informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Programvaren som er laget, er utviklet med tanke på å enten bli benyttet eller bli videreutviklet av andre utviklere. En stor takk til Thor Hasle og Vilhelm K. Vardøy. Thor var vår veileder vi fikk tildelt av Høgskolen i Oslo og Akershus som var tilstede når vi trengte råd om formulering av problemstillingen og gjennomføring av prosjektet. Han var også til stor hjelp når vi skulle skrive dokumentasjon for prosjektet. Vilhelm K. Vardøy som er kontaktpersonen hos Xeneta, hjalp oss i gang og ga oss muligheten til å jobbe med et veldig spennende prosjekt.

6 Innholdsfortegnelse 1 - Prosessrapport 2 - Kravspesifikasjon 3 - Produktrapport 4 - Brukermanual 5 - Testrapport 6 - Vedlegg 1: Ordliste

7 MARE NOSTRUM Del 1 Prosessrapport

8 Prosessrapport Forord Rapporten er en prosessdokumentasjon for hovedprosjektet utført av gruppe 17. Vi kom i kontakt med oppdragsgiveren gjennom høgskolen høsten Skolen la prosjektforslag ved informasjonens side for hovedprosjektet. Vi tok kontakt med kontaktpersonen til bedriften som vi mente hadde en interessant oppgave. Kontaktpersonen møtt oss og fortalte om problemstillingen. Vi fikk to ukers tidsrom for å gi svar. Vi takket ja til prosjektet og arbeidet ble påstartet. Kjernen av problemet prosjektet skulle løse var å lage et datasystem som innsamler forskjellige datasett fra forskjellige kilder og lagre disse datasettene på en effektiv og strukturert måte. Dette kan utnyttes av andre utviklere som enkelt og fleksibelt arbeide med datasettene for å utvikle applikasjoner som kan hjelpe bedriftens kunder til å gjøre et fornuftig valg av rederier i sine hverdager. Dokumentet er skrevet med hensyn på sensorer som skal evaluere arbeidet vi har utført. Det kan forekomme en del begreper som brukes i shippingsmarkedet eller andre tekniske ord fra teknologien vi brukte for å løse problemet. Disse begrepene blir forklart i vedlegg 1. 2

9 Prosessrapport Innholdsfortegnelse 1 Innledning Gruppen Om bedriften Bakgrunn for oppgaven Prosjektmål Rammebetingelser Beskrivelse av programmet Generell beskrivelse Om utvikling av et program for skipingsmarkedet Planlegging og metode Planleggingen og prosessen Hvordan vi planla Utviklingsmetodikk Verktøy Versjonskontroll Dokumentasjon Utvikling Rammeverk Logging med Sentry Symphonical som Arbeidsplanleggingsverktøy Teknologi Nødvendig innstudering av ny materiale Forhåndskunnskaper Arbeidsforhold Arbeidsforhold mellom gruppemedlemene Arbeidsforhold mellom gruppen og oppdragsgiveren Selvstendighet Arbeidsprosedyrer Arbeidstider Arbeidsfordeling Ansvar

10 Prosessrapport 4 Utviklingsprosessen Utviklingsfasene for prosjektet Forstudiet Spesifikasjon Implementering Testing Dokumentasjon Utfordringer Tverrfaglige utfordringer Utfordringer med parsing av schedule-filer Problemer med AIS-parseren Mangelfulle data Håndtering av store mengder nytt stoff Nettverksprogrammering Effektivitet Å tilpasse oss et eksisterende datasystem som stadig er under endringer Viktige valg om oppbygning og funksjon i programmet AIS-parser AIS-receiver Schedule-parser (ScheduleImporter) Redereristatistikkoppdaterer (DepartureArrivalUpdater) Web-applikasjonen Utvikling av forholdet til oppdragsgiveren under prosessen Kravspesifikasjonen og dens rolle Kravspesifikasjonen versjon Tilpasninger av kravspesifikasjonen Invalidering av krav Gruppens forhold til kravspesifikasjonen Om resultatet Avslutning Gruppens utbytte Produktets fremtid Bruksområder

11 Prosessrapport Utvidelsesmulighet Konklusjon Referanser

12 Prosessrapport 1 Innledning Prosjektet er et hovedprosjekt ved HIOA. Vi fikk som oppgave om å lage et program som innsamler, bearbeider og lagrer shippingdata i databasen. Ut ifra dataene som er lagret skal systemet rangerer forskjellige skipsrederier i forhold til hvor punktlige rederienes skip er. Oppdragsgiveren er Xeneta. 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 sammen i andre prosjekter 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 seks ansatte. Firmaet er stiftet i 2011 og er basert på en forretningsidé og et ønske om å gjøre det lukkede shippingmarkedet 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 havnen. 6

13 Prosessrapport 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. 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. 1.5 Rammebetingelser Oppdragsgiveren i samarbeid med gruppen har utarbeidet følgende rammebetingelser. Rammebetingelsene er ment å vise de kravene som oppdragsgiveren har satt i forhold til hvilke verktøy og hvilke teknologier vi skal bruke i prosjektet Programmeringsspråk (back-end): Python Visuelt og web: Twitter Bootstrap (HTML, CSS og JS), Python 2.7.3, Flask(0.9) og Jinja2 Databasehåndteringssystem: MongoDB Versjonshåndteringssystem: Git, Github Utviklingsverktøy: Eclipse(Juno), Notepad++, Vim Lagring av prosjektstyringsdokumenter: Intern lagring(backup), Google Docs og Dropbox. Planleggingsverktøy: Microsoft Project 2013, Microsoft Visio 2013 De viktigeste rammebetingelsene for oppdragsgiveren var at gruppen tar i bruk det overnevnte programmeringsspråket og databasehåndteringssystemet for å sørge for kompatibilitet med deres eksisterende systemer. 7

14 Prosessrapport 2 Beskrivelse av programmet Dette kapitlet forklarer den overordnede funksjonaliteten til programmet vi har utviklet i dette prosjektet. Det tar også for seg hvordan det er å utvikle et program for et selskap som jobber med shippingsmarkedet. 2.1 Generell beskrivelse Oppgaven gikk ut på å spore skip på verdensbasis. Dette skal gjøres ved å arbeide mot programmeringsgrensesnitt(api-er) som fanger, tolker og sender ut Automatic Identification System(AIS) data. Dataene skal samles og lagres på et strukturert vis i en database. Videre skal vi samle schedule-data fra forskjellige skipsrederier og formatere disse dataene til et ønsket format og lagre datasettene i en database på en organisert måte. Slik får vi tak i statisk informasjon om skipene til et bestem rederi. Vi får også informasjon om når et rederi har bestemt at skipene deres skal ankomme en havn og når skipene faktisk ankom en havn. Videre sammenligner vi tidsforskjellen mellom forventet ankomsttid og planlagt ankomsttid. Ut ifra denne informasjonen rangeres rederiene etter hvor punktlig de er og dette kan presenteres i en enkelt webside. Informasjonen på websiden er ment å skulle gjøre det enklere for kundene til Xeneta å avgjøre hvilket rederi de ønsker å benytte seg av. 2.2 Om utvikling av et program for skipingsmarkedet Vi hadde et fag som het økonomi og ledelse. Der lærte vi hvor viktig det er å kunne jobbe og tenke tverrfaglig. Denne tankegangen ble tatt med videre til dette prosjektet. Vi var nødt til å sette oss inn i mange nye tverrfaglige emner før vi kunne starte med utviklingen av produktet. Et av de største emnene var shipping. Ingen av oss hadde noe kunnskap om dette fagområdet fra før. Det var mange nye begreper som vi måtte forholde oss til. Ofte var disse begrepene akronymer og det var ikke enkelt å finne en omfattende dokumentasjon som sier hva disse akronymene sto for. Vi leste mange artikler rundt dette for å kunne sette oss inn i begrepene. Vi snakket også med oppdragsgiveren som belyste en del av begrepene for oss. Under første møte med oppdragsgiveren, fikk vi vite at oppdragsgiveren var ikke interessert i den visuelle delen av programvaren skulle være utformet. De var mer interessert i å innsamle forskjellige datasett fra forskjellige kilder og lagre disse datasettene på en effektiv og strukturert måte slik at disse kan utnyttes i seinere tidspunkt av andre utviklere for å lage en applikasjon som oppdragsgiveren kan ønske å tilby sine kunder. 8

15 Prosessrapport 3 Planlegging og metode I den delen av rapporten, beskriver vi hvordan vi planla, hvilke verktøy vi brukte og hvilke nye teknologier vi måtte sette oss inn i slik at vi kan løse problemet. Tilslutt tar vi for oss under hvilke forhold vi har jobbet og hvordan vi samarbeidet med oppdragsgiveren. 3.1 Planleggingen og prosessen Hvordan vi planla Under forstudiet av prosjektet, lagde vi en framdriftsplan. Vi bestemte hvilke faser vi kom til å ha og hvilke aktiviteter vi skal ha under hver fase. Det var veldig mye ukjent på den tiden og framdriftsplanen var en veldig overordnet plan for hvordan vi forventet utviklingsprosessen kom til å se ut. Nedenfor vises også fordelingen av ansvar under prosjektet. Figur Fremdriftsplanen for prosjektet. 9

16 Prosessrapport Utviklingsmetodikk SCRUM Hva er scrum? Scrum er en arbeidsmetodikk som en gruppe kan bruke for å samarbeide om å utvikle et produkt. Metodikken gjør at små deler av produktet blir utviklet om gangen, og videre utviklingen av produktet skjer ved at andre deler av produktet bygger på det som er allerede bygd. Grunnen til at det utvikles kun små deler av et produkt om gangen, er for å stimulere kreativitet og for at laget kan få konstruktiv tilbakemelding fra produkteieren. Tidlige tilbakemeldinger gir utviklerne muligheten til å kunne implementere endringer i produktet. Dette bidrar til at sluttresultatet blir et ønsket resultat, og det hindrer avsporing. Scrum forhindrer også elementer og personlige egenskaper som kan stå i veien for produktivitet. Altså fremheves samarbeid overfor opphevelse av enkelte personer i laget. Det tar skyld og ære fra enkeltpersoner og fordeler det videre til laget. Enkeltpersoners potensial utnyttes til fordel for utviklingen, slik at sluttsummen overgår produktiviteten av hva hver enkelt kunne ha ytet dersom de jobbet hver for seg. På denne måten kan man holde fokus på oppgaven som skal løses. Hvordan fungerer scrum Det å utvikle et komplisert produkt for en kunde er en veldig vanskelig oppgave. Scrum tilbyr struktur som tillater et lag med utviklere til å håndtere og løse oppgaven. Kjernen i scrum er styrt av følgende tre hovedroller. Produkteiere bestemmer hva som må bygges innen de førstkommende 30 dager eller snarere. Utviklerlagene bygger det som må bygges innen de førstkommende 30 dager eller snarere. Utviklerne demonstrerer resultatet for produkteierne. Ut ifra demonstrasjonen, bestemmer produkteierne hva som skal bygges neste. Scrum-master sørger for at prosessen går så smidig som mulig ved å fjerne alt som står i veien for utviklerne. De hjelper også med å forbedre prosessen, laget og produktet som bygges. Scrum nøkkelbegreper I tillegg til overnevnte rollene, bruker scrum følgende nøkkel begreper: 10

17 Prosessrapport Daglig scrum: En daglig møte som varer i 15 minutter. Hensikten med møte er for at lagmedlemmene kan oppdatere hverandre om hva de har gjort og lage en plan for de kommende 24 timer ut ifra arbeidet utført siden siste daglig møte. Definisjon av «Ferdig»: En beskrivelse av hva det vil det si at et arbeid er utført eller ferdig. Dette gjøres for å forsikre felles forståelse og for å sikre gjennomsiktighet innen laget. Sprint: En tidsramme på en måned eller kortere der man utvikler en «ferdig» delprodukt(inkrement). Alle sprintene i et prosjekt skal være like lange. En ny sprint starter med en gang etter at en sprint er avsluttet. Product Backlog: En sortert liste med alt som trenges for produktet som er under utvikling. Det er her kravene blir spesifisert. Produkt eieren er ansvarlig for dets innehold og prioritering av kravene. Inkrement: Er sum av alle produktkøelementene(product Backlog) som er utført i løpet av en Sprint og alle tidligere Sprint. Utviklingslag: Et lag med fagfolk som arbeider med å levere en inkrement av «Ferdig» produkt på slutten av hver sprint. De er organisert på et vis som gjør dem i stand til å utføre oppgaven de får. Sprint Backlog: En samling av utvalgte produktkøelementer(product Backlog) for en Sprint samt en plan for utlevering av produkt inkrement og oppnå Sprint målet. Det er utviklerne som forutsier hvilke funksjonalitet som vil være med i neste produkt inkrementet og hva som må gjøres for å levere funksjonalitetene. Sprint-Mål: Det er målet utviklingslaget jobber mot innen en Sprint. Hvis utviklerne innser at de må gjøre noe annerledes kan de i samarbeid med produkteieren endre målet. 11

18 Prosessrapport Sprint planleggingsmøte: Et møte hvor arbeidet som skal utføres i en Sprint er planlagt av hele scrum laget. Figur Scrum-prosessen Tilpasning av Scrum i vårt prosjekt I begynnelsen bestemte vi oss for å bruke arbeidsmetoden Scrum. Vi valgte Scrum av forskjellige årsaker. Den første grunnen var at vi ønsket å tilegne oss en kvalifisert arbeidsmetode som brukes i relle it-selskaper. For det andre ville vi ha en arbeidsrammevark som er smidig og som på en enkeltvis kan tilpases til vårt prosjekt. I det planleggingsfasen startet, valgte vi en scrum master og planla vår første iterasjon. Men etter at vi begynte med å løse problemstillingen, innså vi at vi måtte gjøre store endringer til den planlagte iterasjonen. Vi visste ut ifra de første samtalene med oppdragsgiveren at vi skulle jobbe med organisering av data. Men vi hadde forventet at dataene vi skulle jobbe med hadde en bedre struktur og at de skulle være lett tilgjengelig. Dessverre viste det seg at alle dataene vi jobbet med under prosjektet var mye mer usortert enn forventet. Denne utfordringen har vi spesifisert i detaljer i underkapitlet 4.2. Dette førte til at arbeidet som vi hadde regnet med å bli ferdig innen en iterasjon hadde en altfor stort omfang som vi kunne ikke bli ferdig med innen fristen. På bakgrunn av dette kuttet vi ut å planlegge flere iterasjoner, fordi dette ville ha ført til mye ekstra arbeid for å omstrukturere planen. Istedenfor å bruke tid på å planlegge iterasjoner, bestemte vi oss for å bruke use-case beskrivelsene og kravspesifikasjonen for å tildele hvert enkelt gruppemedlem nye oppgaver med en gang de ble ferdig med en pågående oppgave. Vi jobbet altså mot selve målene 12

19 Prosessrapport istedenfor iterasjoner. Det var mye ukjent rundt deloppgavene og vi kunne ikke sette noe tidsramme til når delene forventes å bli ferdig. Men vi var strenge med hverandre og utfordret hverandre til å jobbe mot de målene vi satt opp for oss selv. Vi har allikevel beholdt de daglige scrummøtene slik at vi holder hverandre oppdatert. Dette har også vist seg å være veldig nyttig med tanke på at vi ofte har plutselig vært nødt til å endre de forskjellige delene av programmet for å få det til å virke. På den måten kunne resten av gruppemedlemmene eventuelt gjøre endringer i andre deler av programmet raskt og effektivt dersom dette var nødvendig. Vi har også modifisert bruken av sprint-backlog. Ettersom vi ikke hadde oversikt over hvor lang tid en sprint faktisk kommer til å ta, så har vi heller valgt å legge inn oppgaver som skal utføres i sprinten, i det øyeblikket vi begynner på den. For å få en assignment eller et sett med oppgaver, har vi hatt en regel om at vi skal avtale dette med scrummaster før vi begynner på oppgaven slik at vi sikrer at vi prioriterer riktig i forhold til oppdragsgiverens ønsker. Vi har brukt symphonical for å holde hverandre oppdatert med hvilke oppgaver hver enkelt har jobbet med til enhver tid (se kap ). På tross av at arbeidet (særlig i starten av implementasjonsfasen) ikke fungerte som planlagt, fikk vi allikevel gjort mesteparten av det vi skulle. Vi har vært veldig løsningsorienterte og har vært fast bestemt på å fullføre og få til det vi har begynt på, selv om andre kanskje ville gitt opp. 3.2 Verktøy Under prosjektet brukte vi en del verktøy for styring av prosjektet og for håndtering av produktet. Nedenfor er en oversikt over alle de nevneverdige verktøyene vi har brukt i prosjektet Versjonskontroll I prosjektet valgte vi å bruke Git og Github for versjonskontroll. Dette er først og fremst for at gruppen skulle få et fungerende versjonshåndteringssystem som er enkelt å sette seg inn i. Det finnes andre alternativer til Git, men vi mente at disse ville kreve unødig mer tid å sette seg inn i. En annen grunn til at vi valgte å bruke Git og Github, er fordi Xeneta allerede bruker det som versjonshåndtering innad firmaet. Det var derfor også støtte for bruk av Git på Xenetas servere og testservere. Enkelte i gruppen følte seg ukomfortabel med å jobbe med programkode over terminal. Med Git og Github er det vesentlig enkelt å laste inn endringer til serverne for testing. Dette gjorde at vi kunne jobbe på lokal maskin og dytte endringene til serveren for testing. På denne måten slapp vi å redigere koden direkte på server. 13

20 Prosessrapport Bruk av Git og Github har blitt ganske vanlig i dag, men vi er også klar over at det er mange innenfor IT som ikke bruker det. Nedenfor har vi derfor valgt å ha med en kort presentasjon av Git og Github Git Git er et versjonshåndteringssystem som er laget for at flere personer skal kunne jobbe med de samme tingene, uten at man trenger å tenke på hvordan man skal synkronisere arbeidet man har utført på forskjellige maskiner. Git synkroniserer arbeidet en har utført via systemets kommando. Git er raskt og muliggjør alle-til-alle synkronisering. Kommandoene pull og push brukes for henholdsvis få oppdateringer fra og å dytte endringer til prosjektmapper. Git viser også historikk over hva som er blitt gjort tidligere, av hvem endringen er gjort og har implementert muligheter for å omgjøre tidligere endringer. Git settes opp ved at man kloner en mappe der alle filene som tilhører et bestemt prosjekt ligger, slik at man gjør endringer på en kopi av den originale prosjektmappen. Når man har gjort endring på en av filene i den klonede mappen, vil Git kunne oppdage dette. Man kan så velge å overføre endringene man har gjort i den klonede mappen til den originale mappen, slik at endringene man har gjort blir en del av prosjektet. Dette kalles merging. For mer informasjon om Git og hvordan det virker, se Git i kildehenvisning Github Github er en webside som gjerne brukes i kombinasjon med Git. Denne legger prosjektmappen inn som en skybasert tjeneste, og inneholder en god del verktøy for blant annet å styre rettigheter til å se eller endre innholdet av prosjektmappen. Den inneholder også verktøy som lett kan gi en oversikt over hvem som har gjort hva i prosjektet. En stor fordel med Github at i motsetning til Dropbox (se ) og andre skybaserte tjenester, slipper man å utføre noen installasjoner lokalt på maskinen (Foruten Git). Det gjør at man kan få tilgang til prosjektmappen uansett hvor man er og hva slags apparat/device man jobber på Dokumentasjon Googledocs Google Docs er en web basert kontor pakke som er gratis. Programmet brukes for å skrive og redigere dokumenter på nettet. En av grunnene til at vi valgte å bruke programmet var fordi man kan 14

21 Prosessrapport samarbeide med andre brukere på samme dokument i sann tid(real time). Endring i dokumentet lagres automatisk og dokumentet er sikkerhetskopiert i tilfelle noe skjer med våre lokale datamaskiner Dropbox Dropbox er en sky basert tjeneste og et fildelingsprogram som muliggjør deling av filer over mange forskjellige enheter. På denne måten kan man for eksempel laste opp bilder eller andre typer filer, og med en gang få tilgang til dem andre steder fra en annen maskin. I prosjektet har vi hovedsakelig brukt Dropbox til å dele filer vi bruker til dokumentasjonen. Vi har også brukt Dropbox til å dele læremateriell som omhandler enkelte av teknologiene vi har brukt under prosjektet Microsoft Project 2013 Microsoft Project er en prosjektstyringsprogramvare utviklet og solgt av Microsoft. Det brukes for planlegging, organisering og styre resurser i et prosjekt. Vi brukte programvaren for å lage en fremdriftsplan som viste hva som skal gjøres til enhver tid og hvem som er ansvarlig for de overordnede oppgavene. Planen ligger under avsnitt Microsoft Visio 2013 Microsoft Visio 2013 er en applikasjon som brukes for å tegne forskjellige type diagrammer. Programmet er laget slik at det skal gå raskt og enkelt, og gjør det også enklere å holde diagrammet ryddig i forhold til hvis man for eksempel skulle tegne det for hånd. Vi brukte applikasjonen for å tegne sekvensdiagrammer UML I dokumentasjonen av prosjektet har vi hovedsakelig prøvd å holde oss til UML standarden. UML står for Unified Modeling Language, og setter en rekke kriterier eller standarder for å lage visuelle modeller av objekt orientert programvarer. Modellene er veldig nyttige for å planlegge av hva som skal bygges under forstudie fase. Fra UML-standarden, har vi benyttet oss av use-case diagram, klasse diagram, aktivitetsdiagram og sekvensdiagram. Et Use Case-diagram viser hva aktører kan gjøre på systemet, og hvordan systemet og aktørene samhandler med hverandre. Klassediagrammet beskriver selve programstrukturen avgrenset av Use Case-beskrivelsen, i form av klassene som skal programmeres samt relasjoner mellom de forskjellige klassene. Aktivitetsdiagrammet beskriver programmets flyt i flere steg, men nevner i utgangspunktet 15

22 Prosessrapport ingenting om oppbygningen av programmet. Sekvensdiagrammet inneholder en beskrivelse hvordan de forskjellige klassene i et program kommuniserer med hverandre, avgrenset av Use Casebeskrivelsene. Vi har i prosjektet gjort forenklinger og tilpasninger av både sekvensdiagrammer og klassediagrammer for at de skal være lettere å lese, og bedre til å formidle sitt budskap Utvikling Eclipse Eclipse er et integrert utviklingsmiljø(integrated Development Enviroment). Det brukes til å utvikle applikasjon i Java, men fordi Eclipse er utvidbart kan man ved bruk av en del plug-ins, utvikle applikasjoner i andre språk også. Vi brukte plugin-en pydev og importerte Python interpreter og brukte det til å utvikle applikasjonen vi jobbet med. Eclipse har flere versjoner, og vi brukte versjonen 4.3 med sin tilhørende kodenavn Juno Notepad++ Notepad++ er en teksteditor og kildekodeeditor. Den er enkelt å bruke og vi brukte det i sammenheng med å redigere html-filene vi lagde for siden til vår applikasjon. Vi brukte versjon Vim Vim er en teksredigeringsprogram som kan brukes både fra et kommandolinjegrensesnitt og som en applikasjon i en grafisk brukergrensesnitt. Vi brukte det til å redigere kode i testserveren Rammeverk Vi brukte flask som webapplikasjonsrammeverk. Flask er beskrevet i avsnittet Logging med Sentry For å oppdage feil og exceptions (unntak) som skjer mens programmet kjøres på testserveren, ble det flere steder i modulene schedule_importer.py og _handler.py, lagt inn programkoden som loggfører feil og unntak. Eksempler på logging av feil er for linjer i schedule-filer som ikke kunne formateres. Man vet ut ifra denne hendelsesmeldingen at programmet ikke klarte å få tak i de ulike verdiene. Sentry en sanntidsplattform for hendelseslogging. Den overvåker feil og kan vise feilmeldingen eller detaljer ved et unntak på en web-side. I web-siden står det for exceptions-hendelser detaljer om det 16

23 Prosessrapport lokale skopet. Detaljer som for eksempel verdien og datatypen til lokale og globale variabler blir vist på web-siden. Sentry kan altså brukes til debugging. Feilmeldinger som man kan skrive selv og sende til Xeneta sin Sentry-server gjøres på denne måten: raven_client.capturemessage("could not parse line: %s" % line) Unntak kan fanges ved å skrive raven_client.captureexception() på de stedene der det kan kastes exceptions. Exception-meldinger formateres av Sentry gjennom python-autentiseringsklienten Raven. Figur En snapshot av Sentry-websiden for testserveren. Bildet viser de siste seks hendelsene. Linje 2 viser blant annet at en linje fra en schedule-file kunne ikke parses Symphonical som Arbeidsplanleggingsverktøy Symphonical er en digital scrumtavle som enkelt lar deg legge til og administrere arbeidsoppgaver. Oppsettet for symphonical-tavlen er det samme som for en vanlig Scrum-tavle og den er laget slik at flere skal kunne jobbe og endre på den samtidig. Fordi vi i prosjektet valgte å ikke planlegge iterasjoner, bruke vi tavlen til å fordele oppgaver og holde hverandre oppdatert på hva vi drev med, og hva vi var ferdige med. Et veldig typisk bruksscenario var at vi først skrev hvilke deler av prosjektet vi jobbet med for øyeblikket, og spesifiserte videre nøyaktig 17

24 Prosessrapport hvilke deler av programmet og programkoden vi jobbet med, eller hvilke problemer vi prøvde å løse. Vi har kun brukt Symphonical for å jobbe med selve implementasjonsfasen og testfasen. Det var ikke nødvendig å bruke det mens vi jobbet med sluttdokumentasjonen. Vi satt ofte sammen og redigerte sluttdokumentasjonen i Google Docs, hvor alle kunne se og jobbe med samme tekst samtidig. Figur En snapshot av Scrum-tavlen den Teknologi Denne delen inneholder en presentasjon av alle teknologier som er med i implementasjonen av prosjektet Nødvendig innstudering av ny materiale Under avsnittet presenterer vi en rekke teknologier som vi var nødt til å sette oss inn i før og under implementasjonsfasen. Under overskriftene står det kort om hva de forskjellige teknologiene er, hvorfor og hvordan vi har brukt dem Python Python er en høynivå programmeringsspråk som er designet med hensyn på kode leselighet. Språket er utviklet C++ og det er støtte for tre programmeringsparadigmer: objektorientert programmering, 18

25 Prosessrapport imperativ programmering og funksjonell programmering. Dette gir fleksibilitet til og bruke de paradigmene som passer den bestemte oppgaven. Python var en av de viktigste rammebetingelsene fra begynnelsen av prosjektet. Oppdragsgiver ønsket at vi skulle ta i bruk Python for det var språket oppdragsgiveren utviklet sine eksisterende systemer i. Dette vil gjøre jobben med å videreutvikle og vedlikeholde produktet vi lager for oppdragsgiveren. Vi fulgte, etter oppdragsgiverens ønske, pep8 standarden når vi skrev Python koden. Pep8 er et akronym for Python Enhancement Proposals 8 og det beskriver all kode stilen man bør benytte i Python programmeringsspråket for utvikling. Dette fikk vi til ved å bruke en pep8 plugin til eclipse og hver gang vi overskred anbefalingene fra pep8 fikk vi en advarsel på det Twitter bootstrap Twitter Bootstrap er en fri samling av verktøy for å lage websider og webapplikasjoner. Det består av HTML og CSS-basert design mal for skjemaer, knapper, navigasjon og andre grensesnitt komponenter som webutviklere bruker ofte. I tillegg til alt dette inkluderer Twitter Bootstrap JavaScript utvidelser. Vi brukte verktøyene i Twitter bootstrap for å lage websiden til prosjektet. Det var oppdragsgiveren som foreslo det og vi fant det veldig nyttig. Oppdragsgiveren var mest interessert i det back-end programmet som lagrer dataene på en organisert vis for videre bruk og ikke i den grafiske delen av produktet. Derfor var det greit at vi kunne bruke komponentene i Twitter bootstrap slik at vi kan fokusere på det som er viktig for oppdragsgiveren D3.js D3.js er et JavaScript-bibliotek som brukes til å visualisere data i dynamiske diagrammer. D3.js gjør at man enklere kan legge inn grafisk grensesnitt og interaktive løsninger mot sluttbruker. I prosjektet brukes D3.js på web-siden til å lage en grafisk framstilling av puntkligheten til rederier over tid. D3.js er fleksibel og det er veldig enkelt å sende data til javascript-koden som genererer diagrammene Javascript JavaScript, ofte forkortet til JS er en tolket (interpretert) programmeringsspråk. I utgangspunktet var språket laget som en del av nettlesere slik at klient-side skriptene skal kunne samhandle med brukeren, kontrollere nettleserne, kommunisere synkronisk og endre innholdet i dokumentet. Nå brukes det til mer avanserte ting som å utvikle spill og andre type applikasjoner. I likhet med Python støtter språket tre paradigmer. 19

26 Prosessrapport Vi brukte JavaScript i sammenheng med websiden. Det var allerede en del JavaScript filer i det overnevnte webutviklingsverktøy TwitterBootstrap. Vi brukte disse filene for å lage en dynamisk side. Vi brukte JavaScript under testing av innholdet i database. D3.js er også en JavaScript bibliotek. Vi trengte derfor å sette oss litt i teknologien slik at vi kan jobbe med alle disse pakkene som benytter seg av JavaScript MongoDB MongoDB et dokument orientert og en ikke-sql(nosql) database system. I motsetning til den klassiske relasjonal databse, lagres ikke dataene i tabeller. MongoDB lagrer strukturert data som JSON-lignende dokumenter med dynamiske skjemaer som kalles for BSON. Denne måten å lagre data på gjør integreringen i bestemte applikasjoner enklere og raskere. BSON(Binary JavaScript Object Notation) er et datautvekslingsformat som brukes som data lagrings og nettverk overførings format MongoDB database. Det er et binært format for å representere en enkel data struktur og assosiative matriser, også kalt objekter eller dokumenter i MongoDB. For å få med seg hvordan data blir lagret i MongoDB er det greit å se hvordan de forskjellige terminologiene i SQL-database er representert i MongoDB. Tabell Sammenheng mellom terminologiene i SQL og implementasjonen i MongoDB. SQL terminologi/begreper Database Tabell Rad Kolonne Indeks Tabellkombineringer (table joins) Primær nøkkel (spesifiseres av programmereren) Aggregasjon (eks. «group by») MongoDB terminologi/begreper Database Collection Dokument eller BSON dokument Felt Indeks Innebygde dokumenter og linking Primær nøkkel (det lages automatisk og det gis som verdi til _id -feltet) Aggregasjonsrammeverk Vi (i samråd med oppdragsgiver) reflekterte egentlig i etterkant at et annet databasesystem hadde kanskje vært bedre. Dette skyldes at implementasjonen vår har veldig mange enkeltspørringer (for enkeltfelter) mot databasen, mens MongoDB heller er tenkt som en dokument-database, altså hente ut 20

27 Prosessrapport hele dokumenter på en gang. MongoDB har allikevel et godt system for å håndtere dette, så det har derfor ikke vært noe problem med å fortsette å bruke det. En annen grunn til at vi brukte MongoDB er fordi at det er dette systemet oppdragsgiver allerede bruker for sine databaser Celery Celery er et bibliotek eller grensesnitt for Python som brukes til å implementere meldings kø for et nettverk. Celery brukes for å parallellisere prosessering av innkommende data ved å fordele arbeidet på forskjellige noder(maskiner) i nettverket. Disse nodene kalles workers. Celery kan distribuere innkommende tasks eller oppgaver på 2 forskjellige måter: Synkront og asynkront. Når en oppgave kjører synkront betyr det at det sørges for at andre oppgaver kan vente på at en bestemt oppgave gjør seg ferdig. Asynkront kjører bare alle oppgavene uavhengig av hverandre. Celery fungerer med andre ord akkurat som multithreading gjør på en datamaskin. Forskjellen er at den distribuerer ressurser for nettverk og ikke for selve datamaskinen. I dette prosjektet brukes ikke Celery direkte, men det er blant annet implementert i mailserveren som vi bruker. Vi har også prøvd å strukturere koden slik at det blir enkelt å ta i bruk Celery dersom det ønskes Flask Flask er en lettvektig webapplikasjon rammeverk for programmeringsspråket Python. Det er skrevet i Python. Det kalles mikrorammeverk for dets kjerne er veldig enkel men utvidbar. Den har for eksempel ikke noe database abstraksjonslag, form validering eller en tredjeparts bibliotek som tilbyr vanlige funksjonalitet. Flask støtter utvidelser som kan legge til de manglende funksjonalitetene slik at brukeren kan bruke det som om disse funksjonalitetene var implementert i selve rammeverket. Vi valgte å bruke flask etter oppdragsgiverens anbefaling. Xeneta brukte rammeverket for å utvikle deres web applikasjoner også. En annen fordel med Flask var at det var enkelt å komme i gnag med i forhold til andre rammeverk som var egnet til store prosjekter og som krevde lit mere tid for å sette seg inn i. Flask kommer med en template engine Jinja AIS AIS er et akronym for Automatic Identification System. Det brukes primært som antikolisjonsmiddel for skipsfarter. Det brukes også av maritime trafikksentraler for å holde oversikt over skipstrafikken innen sine ansvarsområde. For skip som veier over 300 tonn er obligatorisk å ha en AIS-utstyr som 21

28 Prosessrapport sender og mottar AIS signaler. Disse signalene sendes og mottas over frekvenser på VHF-båndet, en elektromagnetisk stråling i området 30 til 300 MHz. AIS-signalene inneholder forskjellige informasjon om skipet utstyret er om bord på. Dette er mange datafelter og alle er ikke like viktige for prosjektet. Ut ifra artiklene vi leste fant vi ut at det finnes 26 forskjellige typer meldinger. I prosjektet er vi kun interessert i to av dem: Voyage Data og Class A position report. Voyage data inneholder typisk statisk informasjon om skipet, og mesteparten av informasjonen er lagt inn manuelt. I prosjektet brukes Voyage data hovedsakelig til å identifisere et skips mmsinummer via skipets navn eller skipets registreringsnummer(imo-nummer). Class A position report inneholder informasjon om skipets posisjoner som lengde og breddegrad. Det kan nevnes at Class A referer til fastsatte regler som gjelder for oppsettet av meldingen, og hva slags fartøy som kan ta i bruk standarden. Utover det som er nevnt her, er de viktigste datafeltene og de som forøvrig nevnes i rapporten er beskrevet i ordlisten i vedlegg Forhåndskunnskaper Denne delen av rapporten tar for seg implementasjonsspesifikke teknologier og designprinsipper som en eller flere av oss allerede kjenner til Java I prosjektet endte vi opp med å bruke en AIS-parser applikasjon skrevet i Java, fordi AIS-parseren som vi opprinnelig skulle bruke virket ikke. En stor fordel med å bruke Java er at vi slipper å tenke på håndtering av pekere, men ulempen er at selve parsing-en kan gå en del tregere på grunn av at Java har lengere avstand fra minnet enn C++. Oppdragsgiver sa også at det var helt greit å bruke Java til å lage UDP-serveren Effektivitet og parallelisering Under prosjektet har effektivitet vært et område vi har valgt å satse mye på. For det meste har det ligget tankearbeid å tilrettelegge for videre utvidelser med tanke på effektivitet, heller enn å faktisk implementere ekstratiltak for effektivitet i selve programkoden. Hovedgrunnen til dette er (som beskrevet i kapittel 4.2.) at vi ikke har fått mulighet til å bruk systemet. Dermed ville det også vært vanskelig å vite om et tiltak for å forbedre effektiviteten er nødvendig eller ikke. Tanken er derfor at vi i den grad det er mulig, legger til rette i koden for at det skal være lett for andre videreutviklere av 22

29 Prosessrapport systemet å utvide programmet med støtte for effektivitet. Under står det forklart litt hvordan vi har beregnet effektivitet for hele systemet. Pipelining Pipelining har vært en sentral del av prosjektet særlig ettersom vi har brukt dette i beregning av effektivitet. Dette gjelder særlig når vi skal regne ut om parallellisering av en programkomponent lønner seg eller ikke. Pipelines er veldig vanlig å bruke i programmering alt fra assembly-nivå til høynivå kode, selv om kodespråkene er forskjellig så er også prinsippet det samme. Prinsippet bak pipelining er det som navnet antyder, at man bruker prinsippene fra samlebåndet på en fabrikk. Å tenke i form av pipelines har en veldig stor fordel når man skal vurdere implementasjon av støtte for parallellisering. Det involverer i å se på helheten og tiden det tar å prosessere en strøm av data, framfor å se på hver enkelt data. Prinsippet blir egentlig det samme som ole-brumm pinneleken, man putter inn noe og ser hvor lang tid det tar før noe(hva som helst) kommer ut på den andre siden. Eller man ser hvor lang tid det går mellom hver gang noe kommer ut av pipelinen. Når man betrakter en pipeline, så er man alltid nødt til å gå ut ifra at den er full. Data som går gjennom en tom pipeline vil bruke like lang tid som prosesseringstiden for alle komponentene samlet. Det viktigste man bør legge merke til når det gjelder pipelining er at tiden det tar fra man putter noe inn til noe annet kommer ut, avhenger kun av hastigheten på den tregeste komponenten i pipelinen. Figur Illustrasjonen viser en pipeline med 4 data som går igjennom en rekke komponenter eller stasjoner. Hvis diagrammet leses loddrett, kan man se på hvilke stasjoner hver av de 4 dataene befinner seg på et bestemt tidspunkt. 3.4 Arbeidsforhold Arbeidsforhold mellom gruppemedlemene Ved starten av prosjektet, diskuterte vi om hvordan vi tenkte å fordele arbeidet oss imellom. Ut ifra vårt samarbeid fra tidligere prosjekter, visste vi hva hver en i gruppen var flink til. Vi fordelte arbeidet i henhold til det. 23

30 Prosessrapport Det var nødvendig at alle lærte seg det nye programmeringsspråket og hvordan databasesystemet fungerte slik at alle kan delta i den tekniske delen av prosjektet. I tillegg til det ønsket vi at alle kan være i stand til å forstå og bidra med forslag til det arbeidet andre i gruppen gjorde. Det var mye diskusjon mellom gruppemedlemmene slik at vi kunne forstå problemstillingen. Vi har hatt mye fokus på å løse prosjektet på den beste måten vi kunne komme på med, og alle var villige til å lytte på hverandre og ta det beste forslag. Valgene og beslutningene vi har tatt har da vært med tanke på å gjøre den beste beslutning for prosjektet, og ikke for hvert enkelt medlem. Slik unngikk vi krangel oss imellom. Vi har også brukt en god del tid til å jobbe hver for oss. Vi delte problemstillingen i tre. Det første var å lage en modul som tar imot og formaterer Schedule-filene fra forskjellige rederier. Det andre var å jobbe med en AIS-parser applikasjon og lage en UDP-server for å ta imot AIS-data til systemet vårt. Den tredje problemstillingen var å lage den enkelte webløsningen for å vise frem resultatene vi har jobbet med. I den tredje delen var det ikke selve løsningen som var krevende, men å forstå hvordan vi skulle sette sammen alle rammeverkene og modulene til et helt program. På grunn av prosjektets natur og at komponentene vi jobbet med var veldig uavhengige, så var denne inndelingen en god løsning. På denne måten jobbet vi uavhengige med hver vår del i disse tre områdene. Dette gjorde at alle kunne være sysselsatt samtidig uten at vi trengte å vente mye på hverandre. Vi sørget selvfølgelig også for å samarbeide mye for å sørge for at alle de forskjellige delene passet sammen. Det bør også nevnes at gruppen har vært veldig motiverte til å jobbe med prosjektet. Dette skyldes at det har vært så mange utfordringer knyttet til prosjektet. Gruppemedlemmene er av den typen som faktisk liker utfordringer, og liker å finne innovative og kreative løsninger på egen hånd. Ønsket om å finne løsninger på vanskelige ting, har vært en stor pådriver for at vi har klart å fullføre prosjektet Arbeidsforhold mellom gruppen og oppdragsgiveren Gruppen har samarbeidet ganske tett med oppdragsgiveren for å sørge for at kravene hele tiden blir overholdt. Særlig med tanke på prosjektformen som vi har brukt, har det vært nødvendig med ett ukentlig møte med oppdragsgiver for å revidere krav, og for å avklare viktige avgjørelser som har hatt betydning for produktets funksjonalitet Selvstendighet I prosjektet føler vi også at vi har jobbet svært selvstendig. For eksempel da vi innså at AIS-parseren ikke fungerte, lette Eirik på nettet etter alternative biblioteker skrevet i andre programmeringsspråk. Et annet eksempel var da vi fant ut at det egentlig ikke fantes noen oversikt(database) over hvilke skip 24

31 Prosessrapport hvert rederi eide. For å løse slike problemer har vi alltid tatt initiativ selv til å gå på nettet og funnet en løsning på problemet på egen hånd. Vi har også satt oss inn i nye teknologier på egen hånd og eget initiativ. Vi mener derfor at vi har vært selvdrevne under prosjektet, og har mottatt mindre hjelp under prosjektet enn hva som ofte har vært vanlig under hovedprosjekter Arbeidsprosedyrer I forhold til arbeidsmetodikk har vi jobbet slik at vi har i størst mulig grad tatt kvalifiserte og gode beslutninger angående prosjektet selv. Ettersom prosjektet vårt i stor grad har gått ut på å lage et system for å samle inn data, har vi ved beslutninger som vi har ansett kan ha påvirkning på effektiviteten eller kvaliteten på dataene, rådført oss med oppdragsgiver før vi har tatt beslutningen og begynt arbeidet. Dette har typisk vært ved avgjørende designvalg av systemet der vi må velge mellom bedre kvalitet på dataene eller effektivitet på systemet. Vi har altså lagt stor vekt på å passe på at det vi har drevet med, faktisk er det oppdragsgiver har ønsket Arbeidstider Vi har hatt variert arbeidsdager gjennom prosjektet. Gruppemedlemmene hadde en del forskjellige preferanser for hvordan vi har ønsket å jobbe. Arbeidsdagene vi har hatt under prosjektet kan allikevel oppsummeres etter følgende punktene: 1. Gruppen jobber samlet på skolen i ca. 3 timer + 4 til 10 timer på egenhånd 2. Gruppen jobber på skolen i ca timer 3. Gruppen har fri til å jobbe med obligatorisk valgfag, men gjør ca. 2 timers arbeid på egenhånd. Utover møtetiden, kommuniserte vi gjennom epost og telefon. Vi har jobbet slik at vi har i størst mulig grad tatt kvalifiserte og gode beslutninger angående prosjektet selv. Det bør også nevnes at vi har lagt veldig mye tid ned i prosjektet. Vi har blant annet kuttet ut veldig mange fridager (lørdager og søndager) samt alle helligdager som 17. mai, pinse i tillegg til alle feriene for å jobbe med prosjektet Arbeidsfordeling Under prosjektet brukte vi som nevnt i kapittel brukte vi Symphonical til å fordele oppgaver med, i tillegg til fordeling av oppgaver muntlig. Dette gjorde at vi hele tiden kunne holde oss oppdatert over hvilke oppgaver hver gruppemedlem skulle gjøre, og tillot også gruppemedlemene å fordele oppgavene seg i mellom direkte i programmet. For sluttdokumentasjonen valgte vi for enkelhetsskyld i overskriften, å skrive navnet på personer som vi ville at skulle redigere teksten mens vi jobbet. Dette har fungert bra, og hvert av gruppemedlemmene hadde derfor også alltid oversikt over hva de skulle 25

32 Prosessrapport gjøre og hva som stod igjen. På en annen side så har arbeidsfordelingen blitt litt skjev på grunn av forskjell mellom arbeidsmetoder/innstuderingsmetoder og faglig nivå på gruppemedlemmene Ansvar Under prosjektet har vi alltid fordelt ansvar for de forskjellige delene av prosjektet til gruppens medlemmer. Ansvarsfordelingen under prosjektet har i hovedsak vært omtrent slik: Implementasjon og programkode: Altin Dokumentasjon: Eirik Testing: Alle Det bør imidlertid nevnes at det at en person har ansvar for noe, betyr bare at personen er ansvarlig for å sørge for at det blir gjort riktig. Det betyr altså at alle gruppemedlemmene har jobbet innenfor områder som noen andre har ansvar for. For en mer nøyaktig beskrivelse av hva hver enkelt har hatt ansvar for, se figur 3.1 i kapittel

33 Prosessrapport 4 Utviklingsprosessen Denne delen av rapporten tar for seg de forskjellige faglige utfordringene og viktige valg som har vært i forbindelse med utvikling av prosjektet og hvordan vi har løst disse. Veldig mye av prosjekttiden har gått ut på å sette oss inn i teknologier vi har vært helt ukjente med. Overskriftene under er ment å gi en oversikt over hvilke elementer vi har brukt mest tid på, og som har vært mest utfordrende under prosjektet. 4.1 Utviklingsfasene for prosjektet Forstudiet I denne fasen leverte vi statusrapport, en prosjektskisse og en forprosjektrapport. Statusrapporten bestod av en overordnet beskrivelse av gruppen og av virksomheten som ga oss oppdraget i tillegg til oppgaven. Det ble levert Vi leverte prosjektskisse som beskrev detaljene i prosjektoppgaven. Sist i denne fasen leverte vi forprosjekt rapport. Forprosjektrapporten bestod av en enda detaljert beskrivelse av oppgaven, oppgavens rammebetingelser, risikovurdering, løsningsforslag og en arbeidsplan. Dette var nødvendig for alle involverte partiene, slik at skolen kan sikre seg at oppgaven er av ønsket størrelse til et hovedprosjekt. Det er også til fordel både for gruppen og oppdragsgiveren, slik at vi kan avklare eventuelle misforståelser rundt formuleringen av problemstillingen Spesifikasjon I denne fasen jobbet vi med å sette oss i de nye teknologiene vi skulle ta i bruk i prosjektet. Vi lærte hvordan man programmerer i Python og hvordan MongoDB fungerte. Vi satt opp utviklingsmiljøet. Kravspesifikasjonen ble mer detaljert i denne fasen i form av scenariebeskrivelser Implementering I denne fasen implementerte vi de detaljerte use-case/scenarie beskrivelsene vi hadde kommet frem til under spesifikasjonsfasen. Vi forberedte en struktur til programmets kildekode ved å skrive en del pseudokode. Vi diskuterte og bestemte hvilke moduler og klasser vi trengte. Databasestrukturen ble bestemt under denne fasen. Vi ble nødt til å omprioritere en del krav etter oppdragsgiverens ønske. Sidekravene kunne ikke implementeres for noen av dem ble ugyldig og andre grunnet begrensning i tid. For detaljert beskrivelse av hvilke krav som ble tilfredsstilt, se på kravspesifikasjonen i produktrapporten. 27

34 Prosessrapport Testing Vi utførte enhetstester på de fleste modulene vi har lagd. Enhetstestene lagde vi rett etter at vi har implementert en use-case beskrivelse. For mer detaljert beskrivelse av hvilke tester som utført på hvilke deler av programmet, se på testrapporten Dokumentasjon Vi skrev dokumentasjon av prosjektet i form av dagbok. For det meste har vi skrevet hva vi har gjort ukentlig og her førte vi også inn hvilke viktige bestemmelser vi foretok, enten om det var gjennom samarbeid med oppdragsgiveren, veilederen eller innad i gruppen. Dette var til hjelp når vi begynte å skrive dokumentasjonen for alvor. Vi begynte forsiktig å skrive dokumentasjonene når det var fire uker igjen til innleveringen. Vi sluttet å skrive kode omtrent en uke senere. Vi fulgte høyskolens standarddokumentasjonens anbefalinger med en del tilpasninger for å formulere og strukturere dokumentasjonene. 4.2 Utfordringer Her presenteres de ekstra store utfordringene vi støttet på, teori rundt dette og eventuelt hvordan vi løste dem (hvis utfordringen var en hindring). Vi tar for oss både de faglige utfordringene samt utfordringene knyttet til selve gjennomføringen av prosjektet (for eksempel at ting ikke er gått slik som avtalt eller planlagt) Tverrfaglige utfordringer Det bør nevnes at enkelte deler av prosjektet krevde veldig mye kunnskap innenfor tverrfaglige emner. Ved flere tilfeller krevdes det også kunnskap av oss som egentlig faller langt innenfor fagområdet til en elektroingeniør. Dette gjelder for eksempel dekoding av gps-data. Håndtering av gps-data alene krever en relativt god forståelse av design av kretser og datamaskinarkitektur innenfor emner som data-alignment, dekoding og koding av data, trekke ut flags og datafelt fra en bitstreng osv. Det var også nødvendig for oss å sette oss inn i hvordan shipping fungerer og spesielt innenfor hva som er regler og normer innenfor skipstrafikk, og spesielt hva slags fartøy vi kunne få inn data fra. Å gjøre dette var nødvendig for at vi skulle kunne vite hvilke data vi faktisk skulle se etter, og om vi faktisk kunne bruke dataene. Den store utfordringen her var å faktisk lete etter pålitelig informasjon om dette blant all den informasjonen som finnes uten å drukne i nytt stoff. Dette gjaldt særlig informasjonen som gjaldt spesielt om lover og uskrevne regler innenfor skipsfart. Til eksempel lærte vi at det finnes lovverk for bruk av forskjellige typer gps/ais-sendere. Vi var også nødt til å finne ut om 28

35 Prosessrapport det eventuelt var datafelt i AIS-dataene som blir oppdatert manuelt, siden disse datafeltene i så fall vil bli betraktet som upålitelige Utfordringer med parsing av schedule-filer For å oppfylle kravet om å kunne vise en rangert liste over punktligheten til ulike rederier, var det nødvendig å ha en liste over estimerte avgangs- og ankomsttider for containerskip. Disse listene fikk vi fra ShipmenLink ( Det sendes rutetabellfiler hver uke til alle som abonnerer på dette. Disse rutetabellfilene (schedule-filer) inneholder en liste over mange planlagte reiser. Det var nødvendig å ha det klart for oss hvordan reiseinformasjon skulle lagres i databasen før vi kunne jobbe med disse. Det var grunnen til at vi startet så tidlig som mulig med å implementere den delen av programkoden som hadde med tolking(parsing) av schedule-filer å gjøre. Schedule-filene er delt opp i flere grupper og undergrupper av reiseplaner. 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. Disse gruppene kan også være spesifikke handelsruter. Nedenfor er det vist et eksempel på en av disse gruppene. Under finnes det to linjer som starter med navnet på skipet og en voyage-id (reisenummer). En tur (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. Eksemplet under viser f. eks. at skipet Ever Ethic med reisenummer E 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 Det har vært en del utfordringer med å kunne lage et robust program som kan tolke (parse) rutetabellfiler fra ShipmenLink. Man kan ikke se det i eksemplet over, men det finnes repetisjoner av reiseplaner i ulike handelsrutegrupper. Selv om en havn er listet opp ved siden av en annen og det står ETA -og ETD-datoer for et skip, så betyr det ikke nødvendigvis at skipet skal reise direkte fra den ene havnen til den andre. Det fantes også repetisjoner av hele reiser og repetisjoner av deler av reiser med en annen reise-id (voyage-id). Ulike datastrukturer i Python, deriblant lister, mengder (set) og dictionaries måtte brukes for å trekke ut alle reisene for hvert skip og lagre dem i databasen. Alle 29

36 Prosessrapport reisene skulle være med og de skulle stå i kronologisk rekkefølge og ingen repetisjoner skulle forekomme. Det måtte brukes mye regex (regulære uttrykk) for å kunne trekke ut nødvendig informasjon fra schedule-filene. For å kunne skille mellom navnet på skipet, reise-iden og datoene for avgangs- og ankomsttider måtte det i det regex-strengen tas hensyn til at navnet på et skip kunne inneholde bokstaver, tall, punktum, bindestrek og apostrofer. Disse tegnene finnes også i reise-iden førte til at regex-strengen ble større. Under teksten er regex-strengen som brukes til å trekke ut navnet på skipet, reise-iden og datoer for reiser vist. r'^(?p<ship_name>((\w+\.?)+(([\- \']\w+)+ ( [1-9]+))?){1})' \ ' (?P<voyage_id>(([\d\w]+)(\-[\d\w]+)?) (\-){2,})' \ ' +(?P<schedule_info>.+$) Det ble brukt en del tid på å implementere en parser som har en toleranse for små variasjoner i schedule-filene. Etter hvert som flere filer ble mottatt ble det oppdaget flere små variasjoner på formatet i filene. Koden som brukes til å tolke(parse) disse filene ble dermed oppdatert for å håndtere disse variasjonene. For å oppdage feil av tolking av schedule-filer ble det flere steder implementert kode som loggfører unntak og feil. Les mer om dette i avsnittet for logging (avsnitt 3.2.5) Problemer med AIS-parseren Det bør nevnes at AIS-parseren er den delen av programmet som har ansvar for å håndtere og dekode posisjonsdata fra skip. Vi hadde imidlertidig en del utfordringer knyttet til denne delen av programmet under prosjektet. Disse utfordringene er beskrevet i overskriftene under AIS-parseren skrevet i C++ I begynnelsen av prosjektet fikk vi beskjed av oppdragsgiver om å bruke et eksisterende bibliotek til dekoding av AIS-data som var skrevet i C++. Etter som alle i gruppen tar faget Effektiv kode med C og C++ hadde vi nok bakgrunns erfaring med språket at vi skjønte, ut ifra feilmeldingene, at feilen skyldes dårlig håndtering av pekere i programmet(segmentationfault). Problemet var å finne ut nøyaktig hvor i programmet feilen lå. Det kunne ta evigheter. Vi sto dermed overfor en stor utfordring i å finne en løsning på dette problemet. Vi fant ut at det var best å bruke noe som var skrevet i et annet programmeringsspråk enn C++ slik at vi slapp å tenke på feil som var relatert i forhold til håndtering av minneadresser (I C++ må bruk av adresser knyttet til pekere/arrayer håndteres manuelt). 30

37 Prosessrapport AIS-parseren skrevt i java I begynnelsen av implementeringsfasen for hovedprosjektet hadde vi problemer med biblioteket som skulle gå igjennom og dekode gps-data. Derfor bestemte vi oss for å gå på nettet og lete etter et nytt bibliotek som kunne kjøre bedre og mer funksjonelt. Vi endte opp med et bibliotek programmert i programmeringsspråket Java som oppdragsgiver godkjente. Det nye biblioteket kjørte greit og feilfritt, men manglet dekoding og utskrift på flere viktige datafelt som var nødvendig senere i programmet. Vi bestemte oss for å modifisere biblioteket vi fant og tilpasse det etter våre behov. Dette gjorde også at vi kunne integrere en serverapplikasjon direkte inn i parseren (se kapittel i produktdokumentasjonen for nærmere detaljser av hva som er modifisert) Dekoding av gps-data og modifisering Det gikk med ganske mye tid under modifiseringen av javabiblioteket vi bestemte oss for å bruke til prosjektet for å dekode data. Mye av tiden vi brukte ble brukt til å sette oss inn i hvordan dataene skal dekodes slik at vi kunne gå inn i koden og legge til dekoding og utskrift av de datafeltene vi trengte. På grunn av programmets kompleksitet og størrelse tok det også ganske lang tid å finne de stedene vi faktisk måtte endre for å få programmet til å virke. Noe som gjorde oppgaven mye vanskeligere var at vi ikke klarte å finne noen brukbar dokumentasjon til koden. Vi måtte derfor sette oss inn i programmet på egenhånd ved å følge program flyten Mangelfulle data Ved prosjektstart avtalte vi med oppdragsgiveren at vi skulle motta AIS-data fra marinetraffic.com. Da vi hadde jobbet nok med prosjektet til at vi kunne begynne å ta imot data, ga vi Marinetraffic beskjed om å begynne å sende data. Dette gjorde de aldri og de svarte heller ikke da oppdragsgiver forsøkte å få kontakt med dem. Det førte igjen til at alfa-testing av systemet ble en utfordring under prosjektet. Vi måtte derfor lage egne test-data og lage tilpassede integrasjonstester for å få testet systemet på en forsvarlig måte.vi fikk derfor allikevel testet mye av funksjonaliteten, men vi fikk imidlertid ikke testet ut hvordan systemet håndterer dataene over tid. Å lage alle disse testene gjorde at testfasen tok god del mer tid enn hva vi opprinnelig hadde regnet med i begynnelsen av prosjektet Håndtering av store mengder nytt stoff Innstudering av nytt stoff er noe vi har brukt veldig mye tid på under prosjektet. Under underkapitlet 4.3 i denne rapporten står det mer om hva slags stoff vi måtte lære om. Det gir et helhetsbilde på hva vi måttet lære oss av teknologier, men dekker langt ifra alt vi har måttet lese og sette oss inn i. På 31

38 Prosessrapport grunn av at mengden av den nye informasjonen vi måtte sette oss inn i var så stor var det veldig vanskelig å planlegge iterasjonene til prosjektet. Dette var fordi at vi ofte oppdaget at ting vi først hadde antatt ville være ukomplisert, senere viste seg å ikke være det. Det var også en stor utfordring å planlegge hvordan programmet skulle se ut på grunn av dette. Vår løsning var å lese nøyaktig den informasjonen som var nødvendig for at vi skulle kunne klare det vi hadde satt oss mål for på et bestemt tidspunkt. Dette var for å slippe å bruke opp all prosjekttiden på lesing. Ulempen var at vi ofte oppdaget at ting vi først hadde antatt ville være ukomplisert, var veldig komplisert. Dette førte til at vi ikke klarte å få helt oversikt over omfanget av prosjektet før et godt stykke inn i implementasjonsfasen. Gruppen føler at hadde vi jobbet med programmeringsspråket og med et databasesystem som vi jobbet med tidligere, hadde vi greid å vise vår evner til å løse problemer i større grad. Vi hadde vært langt mer effektiv under organiseringen og planlegging av prosjektet. Vi hadde også hatt tid til å fokusere på selve problemområdet enn å bruke mye av tiden til å lese om nye teknologi. Vi har likevel lært å være pragmatiske ved å utnytte verktøy som er egnet for å løse problemstillingen overfor å utnytte verktøy som ikke er egnet til løsningen bare fordi vi var bekvem med det Nettverksprogrammering Vi brukte ganske mye tid på å lese ekstra stoff om nettverksprogrammering for å få satt opp software for de serverne vi trengte. Noe av det som var utfordrende var at vi var nødt til å sette opp nettverkstilkobling mellom forskjellige programmeringsspråk. For eksempel så var det vanskelig å finne en fullstendig ip-protokoll for kommunikasjon som både Python og Java med enkelhet godtok. Java hadde for eksempel ganske mange forskjellige valgmuligheter når det kom til koding(encoding) av data (før dataene blir sendt over nettverket), men det var vanskelig å finne den korresponderende funksjonen i Python for dekodingen etter at en datapakke er mottatt. En annen utfordring er knyttet til UDP-tilkoblingens natur. For at man skal tape minst mulig data gjennom UDP-Connection må en del av programmet konstant lytte på tilkoblingen(socketen) etter innkommende data. Dette krever altså en form for parallellisering, som i seg selv krever at man er nødt til å gjøre noen kompliserte beregninger angående effektivitet. Vi har som nevnt i kravspesifikasjonen brukt en UDP-tilkobling(server) for å motta data i AIS-parser, og vi har derfor laget en alternativ versjon av parseren som støtter parallellisering for å unngå å miste så mye data. Se mer om dette i kapittel 6.1 i produktdokumentasjonen, AIS-parser med multithreading. 32

39 Prosessrapport Effektivitet Effektivitet er et veldig omtalt tema i alle rapportene. En utfordring i prosjektet var at vi måtte utvikle produktet med tanke på effektivitet. Dette var imidlertid ikke et krav fra oppdragsgiver, men vi mener allikevel at dette var nødvendig for at produktet skulle få den funksjonaliteten som oppdragsgiver ønsker Å tilpasse oss et eksisterende datasystem som stadig er under endringer En stor utfordring i prosjektet, var at Xenetas datasystemer var under store endringer under hele prosjektet. Dette gjaldt også selve kjernen av datasystemene deres. Blant annet ble det gjort store endringer i deres implementasjon av Celery som skapte en del problemer for oss under prosjektet. Vi måtte derfor prøve i den grad det er mulig å unngå å bruke funksjoner/funksjonalitet som allerede eksisterte i oppdragsgivers systemer. Oppdragsgiver har imidlertid sagt at de selv tar det fulle ansvar dersom eventuelle endringer påvirker produktet etter at utviklingsfasen er ferdig. Ved prosjektets innlevering vet vi blant annet at en ny utvikler hos Xeneta har fjernet funksjonalitet til Celery, slik at mailserveren vi opprinnelig satt opp ikke fungerer lenger. Nærmere detaljer rundt dette er beskrevet i kapittel 11, Kjente feil i produktrapporten. 4.3 Viktige valg om oppbygning og funksjon i programmet Her følger en liste som punktvis og kort beskriver de viktigste valgene med tanke på design som er gjort i prosjektet, og med fokus på hvorfor de er gjort. De fleste av valgene er beskrevet mye mer spesifikt andre steder i rapporten(e) AIS-parser Lagt til støtte for multi-threading i en egen, alternativ versjon av AIS-parseren. Implementert AIS-parser i Java istedenfor C++ og Python for å unngå problemer relatert til håndtering av pekere. Latt mye av datastrømmen gå igjennom nettverk med tanke på senere innlegging av støtte for Celery Brukt arrayer for å øke effektivitet, blant annet reduksjon av nettverksdelay. Gjort den opprinnelige utskriften av programmet mer kompatibelt for regex. 33

40 Prosessrapport Lagt til try/finally funksjoner som skal få programmet til å fortsette å kjøre istedenfor å krasje AIS-receiver Lagt til datostempling for når dataene er lagt inn i database. Vi var nødt til å gjøre dette fordi AIS-dataene ikke inneholder noe obligatorisk felt for når dataene faktisk er opprettet. Skilt statisk(informasjon som er nesten uforanderlig) og dynamisk informasjon (informasjon som stadig forandres over tid) i 2 collections for bedre oversikt og håndtering. Fått innlegging av dataene sortert etter skipets MMSI-nummer og dato slik at det er lett å finne igjen alle posisjonene skipet har vært på Schedule-parser (ScheduleImporter) Gjorde schedule-parseren om til en klasse for å kutte ned antall metodeargumenter og for å kunne dele viktige variabler som f.eks. listen over alle skip med sine transitter, debuggingvariabler, datoen til rutetabellfilen som tolkes(parses) osv. Brukt dictionaries for skipslister med navn på skip som nøkkel for å øke ytelsen i søk etter skipsnavn betraktelig. Brukt sets (mengdedatastruktur i Python) for å øke effektiviteten på fletting av forskjellige lister av reiseplaner og dermed få en liste over alle unike reiseplaner som kan sorteres. La til hardkodede havnekoder siden søk etter havner med samme navn kan feile. Lagrer reiseplaner i databasen i et dokument som er unikt for hvert skip og schedule-fil reiseplanene ble trukket ut fra Redereristatistikkoppdaterer (DepartureArrivalUpdater) Merker elementer i dokumenter for sletting istedenfor å slette dem mens man itererer alle dokumenter i en collection. Dette gjøres fordi det ikke er anbefalt å slette dokumenter i MongoDB-databaser mens man itererer dem. Itererer gjennom dokumentene i databasen for skip som er på vei til en havn før det itereres gjennom dokumentene for reiseplaner for å kunne hoppe over reiseplandokumenter over skip som Programmet prøver å søke etter navnet til rederiet som eier et skip to ganger: når reiseplandokumentene til skipet itereres og når det skal sjekkes om skipet har ankommet en havn. 34

41 Prosessrapport La til koden som oppdaterer rederier statistikker i denne klassen fordi det ikke finnes andre moduler som har behov for å gjøre det. Inkrementerer bare tallene som brukes i beregning av punktlighetstall i prosent for rederier fordi det ikke er så ofte man trenger å hente inn selve prosenttallene fra databasen og for å gjøre oppdatering av rederistatistikker raskere. Grafene på web-siden trenger ikke disse tallene Web-applikasjonen Lagde bare én stor side for rederipunktlighetsstatistikker, men la til en meny som følger skjermen når man ruller ned. Brukte grafer fra D3.js for å enkelt visualisere rederipunktlighetsstatistikker over tid. La til grafer som viser kumulativ punktlighetsstatistikk over tid for å bedre visualisere punktlighetstrenden til de forskjellige rederiene. 4.4 Utvikling av forholdet til oppdragsgiveren under prosessen Oppdragsgiver har gitt tilbakemelding under hele prosjektet at de har vært fornøyd med gruppens arbeid og progresjon i prosjektet, i lys av at vi har forklart om alle utfordringene vi har hatt rundt prosjektet. Det er viktig å påpeke at oppdragsgiver heller ikke har hatt veldig stor oversikt over omfanget av prosjektet. De opplyste blant annet i begynnelsen at prosjektet kunne ta alt fra en uke til flere måneder. Representant for oppdragsgiver har også sagt at de føler at de ikke har involvert seg så mye i prosjektet som de egentlig burde. De har derfor sagt at de har vært fornøyd med at vi har klart å jobbe veldig selvstendig i prosjektet Oppdragsgiver har også sagt seg villig til å skrive attest, vi skulle etter planen få tilsendt denne Av ukjente grunner mottok vi aldri attesten. Vi hadde heller ikke tid til å følge opp og etterlyse den på grunn av mange andre høyere prioriteringer før innlevering. For alle som er i interesse av innholdet i denne attesten, anmoder vi om å ta kontakt med oppdragsgiver for muntlig eller skriftlig vurdering av gruppens arbeid med prosjektet. 35

42 Prosessrapport 5 Kravspesifikasjonen og dens rolle 5.1 Kravspesifikasjonen versjon 1 Nedenfor ligger den opprinnelige kravspesifikasjonen slik den sto beskrevet i prosjektbeskrivelsen fra starten av prosjektet. Vi visste at de funksjonelle kravene vi spesifiserte ved prosjektstart, egentlig var utformet mer som brukstilfeller og at vi derfor måtte utbedre dette senere i prosjektet. Denne kravspesifikasjonen var dermed heller ment for å ha noe vi kunne gå ut ifra når vi skulle lage scenarier for løsningen. Vi så derfor i starten for oss at hvert av kravene under skulle tilsvare en bestemt usecase/brukstilfelle, slik at vi gikk utifra dette når vi begynte med implementasjonsfasen. Underveis i prosjektet endret vi måten kravene var skrevet på slik at de stemte mer overens med UML standarden. Her er de opprinnelige kravene som ble utformet i starten av prosjektet: Funksjonelle krav Trekke ut hvilke rederier som yter best i forhold til hverandre. Altså finne de som er mest punktlige. Gi kunder en advarsel på at skipet er forsinket med hensyn på posisjonen fra tidligere transitt. Gi et estimat på ankomsttid for et skip og sammenlign dette med planlagt ankomsttid. Spor skipet og tegn ruten på kartet. (kravet har lav prioritet) Vise statistikk over punktligheten til bestemte trade lanes (handelsruter) for en uke, en måned og et år i form av diagrammer. (kravet har lav prioritet) Vise statistikk over den gjennomsnittlige punktligheten til et rederi for en uke, en måned og et år i form av diagrammer/grafer. Lavest prioritet 5.2 Tilpasninger av kravspesifikasjonen Da vi hadde laget en del UML-modeller og kom i gang med implementeringen, skjønte vi fort at de kravene vi hadde satt fikk mye større omfang enn det vi i begynnelsen hadde regnet med. I planleggingsfasen av prosjektet valgte vi å lage brukerscenarier. For enkelhets skyld kalte vi disse for usecase-beskrivelser, men dette er egentlig en litt feilaktig betegnelse. Usecase-beskrivelsene beskrev program flyten og egentlig ikke hvordan brukeren og andre aktører samhandler med systemet. Disse usecase-beskrivelsene brukte vi under implementasjonsfasen, og vi gjorde også ganske mange endringer på disse underveis. I den endelige kravspesifikasjonen for sluttdokumentasjonen endret vi navnet på disse til sekvens scenarier. 36

43 Prosessrapport Grunnen til at vi brukte sekvens scenarier, er at systemet egentlig bare består av algoritmer. Det er derfor veldig lite interaksjoner mellom system og aktør. Derfor ville det være unyttig å fokusere på å beskrive use-caser. I følge wikipedia-siden om use-caser, er use-caser som regel unyttige når man skal beskrive algoritmer. Vi valgte allikevel å ta med et use-case diagram til sluttrapporten for å vise hvordan systemet er ment å kommunisere med aktører på en oversiktlig måte. Vi følte imidlertid at vi ikke behøvde å beskrive disse use-casene nærmere, så vi har derfor valgt å utelate use-case beskrivelser til diagrammet. For den endelige kravspesifikasjonen se på Kravspesifikasjonen Invalidering av krav Noen av kravene vi opprinnelig spesifiserte ble ugyldige. Grunnen til dette var disse kravene krevde et abonnement på satellittdata, og oppdragsgiver regnet ut at det ble for dyrt å ta i bruk dette i overskuelig framtid. Vi fjernet derfor følgende krav: Gi kunder en advarsel på at skipet er forsinket med hensyn på posisjonen fra tidligere transitt Spor skipet og tegn ruten på kartet. (kravet hadde lav prioritet) Advarselen her ville blitt upålitelig fordi man kun kunne sammenlignet data når skipet har kontakt med bakkestasjoner for sending av data. Man kunne heller ikke tegne ruten på karte hvis skipet er langt til havs. Det var også noen få krav vi ikke rakk, men der bruken også har blitt mye mer begrenset enn hva som først var antatt, slik at de egentlig i praksis ville vært en goldplating av produktet. Vise statistikk over punktligheten til bestemte trade lanes (handelsruter) for en uke, en måned og et år i form av diagrammer. Gi et estimat på ankomsttid for et skip og sammenlign dette med planlagt ankomsttid. Å vise statistikk over punktligheten til bestemte lanes, hadde egentlig ingen markedsverdi for kundene, men ville bare vært en morsom finesse. Å gi et eget estimat på ankomsttid for et skip lå et stykke ned på listen og vi estimerte at det ville ta ganske lang tid å implementere. I tillegg så ville det også blitt veldig vanskelig for oss å teste dette for øyeblikket. Vi fant ut at det sistnevnte kravet heller ikke var verdt tiden det tok å implementere det, og vi valgte derfor å fokusere på hovedfunksjonaliteten istedet. 37

44 Prosessrapport Det bør også nevnes at den opprinnelige var designet med tanke på at vi ikke skulle rekke alle kravene. Dette var for at vi skulle få gjort så mye som mulig på prosjektet på den tiden vi hadde til rådighet. Det var også grunnen til at vi vare veldig bevisste på å legge inn kravene i prioritert rekkefølge under planleggingsfasen. 5.3 Gruppens forhold til kravspesifikasjonen Det bør nevnes at ved å følge kravspesifikasjonen og implementere kravene i prioritert rekkefølge, fikk vi brukt tiden mer effektivt ved at vi og Xeneta fikk tid og mulighet til å evaluere kravene og hvilke potensialer kravene har for deres marked og kunder. Det gjorde det også enklere for oss å strukturere, planlegge og fordele arbeidet. Vi gjorde riktignok en del endringer av kravspesifikasjonen mot slutten av implementasjonsfasen, men dette har (som nevnt i 5.2) kun vært å legge til krav som har vært nødvendige for å oppfylle de opprinnelige kravene. Vi innser også at vi sannsynligvis også sparte en del tid ved å følge kravspesifikasjonen ved at vi dermed unngikk å bruke tid på krav som senere har vist seg å være unyttige. Vi mener at kravspesifikasjonen og det endelige produktet samsvarer greit. Vi har påsett at de viktigste kravene som oppdragsgiver har satt er med i produktet. Det ble imidlertid ikke tid til å implementere alle kravene, men dette var på en måte tanken da vi utformet kravspesifikasjonen. Målet var å prøve å oppfylle så mange krav som mulig, på en ryddig og god måte. Å hele tiden evaluere kravene og påse at de samsvarer med produktet har vært et viktig element i vårt arbeid mot sluttproduktet. 38

45 Prosessrapport 6 Om resultatet Produktet som er synlig(frontend) i dette hovedprosjektet er en enkelt dynamisk web-side som viser forskjellige grafer om hvor punktlig forskjellige rederier er i forhold til hverandre. Dette er bare en liten del av hele prosjektet. Bak disse grafene ligger både JavaScript og Python-kode som utgjør den logiske delen av produktet. Det bør nevnes at produktet er designet som et system, og derfor kan ikke produktet kjøres fra cd. Alle modulene kan testes ved å kjøre dem på testserveren. Informasjon om testserver, inkludert brukernavn og passord ligger i vedlegg 2. 39

46 Prosessrapport 7 Avslutning 7.1 Gruppens utbytte Vi er veldig fornøyd med resultatet av prosjektet. Vi synes imidlertid at vi kanskje burde ha brukt juleferien til å sette oss inn i det nye stoffet vi trengte for prosjektet, slik at vi kunne ha planlagt prosjektet bedre i begynnelsen. Vi føler at vi har lært veldig mye under prosjektet. Blant annet har vi lært nye programmeringsspråk som JavaScript og Python. Vi har også lært nye databasespørringsspråk og mange nye måter man effektivt kan organisere databaser på. Vi har også lært mye om prosjektstyring, og vi føler også at vi har lært at total oversikt og planlegging ikke nødvendigvis alltid er nøkkelen til et vellykket prosjekt. Vi føler at grunnen til at dette prosjektet gikk så bra, var at vi gikk bort fra all planleggingen og heller fokuserte på hva som bør gjøres istedenfor hvordan. Vi føler også at vi er blitt enda flinkere til å jobbe selvstendig og være selvdrevne, noe som vi vet er etterlengtede karakteristikker på arbeidsmarkedet. Vi har selvfølgelig som tidligere nevnt hatt en del hindringer i prosjektet som skjev fordeling av arbeid, og veldig tekniske problemer knyttet til selve implementeringen av prosjektet (se kap. 5.2). Dette har imidlertid bare bidratt til å gjøre arbeidet med prosjektet morsommere, ettersom prosjektmedlemmene i gruppen er veldig glad i å løse utfordrende og vanskelige problemstillinger. På bakgrunn av dette synes vi at prosjektet var en suksess, selv om arbeidet med prosjektet også slet oss ut. For oss er ikke resultatet i seg selv en opplevelse, men selve veien til resultatet. Vi er derfor takknemlige for muligheten vi har fått til å jobbe med dette prosjektet. 7.2 Produktets fremtid Bruksområder Xeneta har selv foreslått en god del bruksområder for produktet. De satser imidlertid først og fremst på å bruke det til deres egne kunder, for å kunne tilby informasjon om rederiers punktlighet i tillegg til de tjenestene de allerede tilbyr i dag. Programmet kan også muligens taes i bruk av rederiene selv for å prøve å bli mer konkurransedyktige i forhold til andre konkurrerende rederier. Det kan også rett og slett brukes i trafikkovervåkning til å bare lagre informasjon om hvor lasteskip er, og hvor de er på vei hen. I følge Xeneta så har produktet veldig mange muligheter, og det gjelder bare å velge den mest lønnsomme av det. Mulighetene knyttet til produktet er også litt avhengig av hva slags avtaler Xeneta 40

47 Prosessrapport kan gjøre med leverandører med hensyn på hva slags data de får motta. De mener også produktet med litt tid kan ha gode for å gjøre shippingbransjen over verden bedre og mer effektiv Utvidelsesmulighet Produktet har også relativt mange utvidelsesmuligheter. Noen av mulighetene er de mulighetene som er nevnt i den første kravspesifikasjonen men som ikke er blitt implementert. I tillegg til disse kan Xeneta tilby et register der kundene deres kan slå opp hvem som eier eller leier et bestemt skip. Etter hva vi har erfart er det vanskelig å slå opp denne informasjonen på nettet. Oppdragsgiveren sier også at de ennå ikke har oversikt over det fulle potensialet til produktet, men at de foreløpig kommer til å bruke det til å vise punktlighet av rederier i forhold til hverandre. Vi antar også at potensialet produktet har vil avhenge litt av videreutvikling og ansettelse av for eksempel folk til å samle inn informasjon om hvem som faktisk eier hvilke skip. For utvidelsesmuligheter knyttet til forbedring av den eksisterende funksjonaliteten og endringer av koden for produktet, se kapittel 10 i produktdokumentasjonen. 7.3 Konklusjon Som en oppsummering kan vi si at vi er veldig fornøyd med det produktet vi har fått til og et produkt vi er stolte av. Vi synes at selv om det var enkelte ting vi ikke rakk (som for øvrig var tanken da vi utformet kravspesifikasjonen), så satt vi igjen med et produkt med god kvalitet. Det må også nevnes at vi også hadde en hard arbeidsmoral og nektet å gi opp selv om ting i blant så håpløst ut. Vi føler at vi selv har utvist stor selvstendighet, innovasjon, faglig dyktighet og gode evner til å samarbeide om et prosjekt med mange store utfordringer. Dersom vi måtte påpekt noe vi burde gjort annerledes, så ville det muligens vært at vi burde ha undersøkt selve dataene vi skulle samle inn litt nærmere på forhånd før vi definerte kravspesifikasjonen, for å få bedre oversikt over hva vi måtte gjøre. 41

48 Prosessrapport 8 Referanser Bøker: 1. Systemutvikling, Applikasjoner og databaser av Thor E. Hasle, utgave av Cappelen Damm AS 2008 Nettsider: 2. AIS: 3. AIS-parser skrevet i Java: 4. API: 5. BSON: 6. Celery: 7. D3.js: a. b. c. D3.js-eksempler: 8. Dropbox: 9. Eclipse: Flask: a. b Git: Github: Google Docs: Henvisning til kilde: Javascipt: Microsoft Project: Microsoft Visio: MongoDB: MongoDB vs SQL: Notepadd++: Oppgaven fra Xeneta: Python: a. b. 42

49 Prosessrapport 23. Scenario: Scrum: Scrum bilde: Sentry: Symphoical: Twitter Bootstrap: UML: VHF: Vim: Xeneta: a. pakkene xenta tilbyr: 43

50

51 MARE NOSTRUM Del 2 Kravspesifikasjon

52 Kravspesifikasjon Forord Kravenes hensikt og utforming Kravene i kravspesifikasjonen utformet slik at de skal imøtekomme oppdragsgivers krav, ønsker og spesifikasjoner på best mulig måte. Hensikten med kravspesifikasjonen for prosjektet, er å sørge for at både gruppen og oppdragsgiver har en felles forståelse for hva som faktisk skal med i produktet. Dette skal igjen sørge for at oppdragsgiver faktisk får et produkt som på en hensiktsmessig måte inneholder all funksjonalitet de ønsker seg. Flere av kravene er formulert av oss, på bakgrunn av vurdering gjort etter å ha hørt hva oppdragsgiver ønsker. Dette gjelder alle de ikke-funksjonelle kravene og en del av de funksjonelle. Alle kravene er utformet med tanke på at de skal være minste funksjonalitet som er nødvendig for at produktet skal fungere slik oppdragsgiver ønsker. Kravspesifikasjonens målgruppe Kravspesifikasjonens målgruppe slik vi har tenkt, er hovedsakelig oppdragsgiveren og gruppen. Den er imidlertid også designet slik at en utenforstående også lett skal kunne se nøyaktig hva som er minimums funksjonalitet for det endelige produktet. Vi har også designet selve kravene med tanke på at det skal kreve så lite bakgrunnskunnskap som mulig, noe som er i tråd med de prinsipielle retningslinjene for hvordan kravene skal utformes. 2

53 Kravspesifikasjon Innholdsfortegnelse 1 Lederveiledning Krav Funksjonelle krav: Kjernefunksjonalitet, høyest prioritet: Tilleggsfunksjonalitet(lavere prioritet): Ikke-funksjonelle krav Use case Sekvensscenarioer Kjernefunksjonalitet Scenario 1 (Schedule-parser): Scenario 2 (AIS-parser) Tilleggsfunksjonalitet

54 Kravspesifikasjon 1 Lederveiledning Kravene nedenfor er delt opp i to deler etter hvilke type krav de er: funksjonelle krav og ikkefunksjonelle krav. De er utformet etter standard retningslinjer for hvordan kravene skal defineres. De funksjonelle kravene tar for seg alle kravene som går direkte på funksjonaliteten til programmet, eller med andre ord hva programmet skal kunne gjøre. De ikke-funksjonelle kravene tar for seg krav for hvordan programmet og dets omgivelser(som dokumentasjon) skal være oppbygd. Videre har vi også definert de funksjonelle kravene i to kategorier: kjernefunksjonalitet og tilleggsfunksjonalitet. Kjernefunksjonalitetene er ment å være de viktigste kravene, og er det absolutte minimum som må være med for at prosjektet skal kunne karakteriseres som vellykket. Tilleggsfunksjonaliteten tar for seg krav som bygger på kjernefunksjonaliteten. Disse kravene har verdi for oppdragsgiver, men anses for å være mye mindre viktig enn kravene i under kjernefunksjonaliteten. I kapittel tre har vi med de brukerscenariene som vi har brukt til å utforme programmet. Dette ligger under overskriften Sekvensscenarier. Disse er utformet og tilpasset etter hva oppdragsgiver sier de ønsker, og i forhold til hvordan vi ser for oss at programmet skal virke i funksjonell forstand. Disse scenarioene spesifiserer hvordan vi har sett for oss at kravene skal implementeres eller innføres, og er ment å fungere som en erstatning for use-case beskrivelser. Som nevnt i prosessrapporten(5.2) har vi valgt å kalle disse scenarier istedenfor use-case beskrivelser, fordi vi egentlig ikke har noen nevneverdige interaksjoner mellom system og bruker/aktør. Vi har også i tillegg valgt å lage et enkelt use-case diagram som beskriver interaksjonen mellom systemet og aktørene. Det er som tidligere nevnt veldig begrenset med interaksjon, så vi har valgt å bare enkelt kommentere use-casediagrammet istedenfor å lage fulle use-casebeskrivelser. 4

55 Kravspesifikasjon 2 Krav 2.1 Funksjonelle krav: Kjernefunksjonalitet, høyest prioritet: 1. Systemet skal kunne ta imot informasjon om et skip og dets posisjon fra en av Xeneta sine leverandører. Informasjonen skal mottas gjennom en UDP-server 2. Systemet skal kunne lagre informasjon om skip i en database. Systemet skal kunne lagre posisjonsdata om skipenes reiser mens de er underveis. Systemet skal kunne lagre informasjon om hvert skips navn i databasen. Systemet skal kunne lagre informasjon om hvert skips dimensjoner i database. Systemet skal kunne lagre hvert skips destinasjon i database. Systemet må så sant det er mulig kunne lagre tidspunktet for når dataene er opprettet. Systemet skal kunne filtrere bort irrelevant informasjon, blant annet om skip som ikke er fraktskip. 3. Systemet skal sørge for at informasjon om skipene og informasjon om reiserutene er forenlige. Dataene skal kunne kobles sammen. 4. Systemet skal kunne gjenkjenne en mail med schedule blant innkommende epost. 5. Systemet skal kunne lagre eller om nødvendig oppdatere schedules for hvert skip som mottas via mail. Systemet skal kunne se og avgjøre om oppdatering av schedule er forsvarlig/riktig. 6. Systemet må kunne avgjøre i hvilket land eller verdensdel destinasjonen ligger Tilleggsfunksjonalitet(lavere prioritet): 1. Systemet skal kunne finne ut når et skip er kommet til en havn (destinasjon) med minst mulige feil. 2. Systemet skal finne ut når et skip drar (avgang) 3. Systemet skal kunne beregne hvor lang tid et skip bruker mellom havner 5

56 Kravspesifikasjon 4. Systemet skal kunne beregne forsinkelser ved å sammenligne det reelle/aktuelle tidsbruken på reisen mot det som står i skipets reiseplan (schedule). 5. Systemet skal kunne holde rede på hvilke skip hvert registrert rederi eier. 6. Systemet skal finne gjennomsnittlig punktlighet til rederier. 7. Kundene til Xeneta skal kunne hente ut en rangert list over rederienes punktlighet. 8. Systemet skal kunne vise statistikk over punktligheten til rederier gjennom alle tider. 9. Systemet skal kunne vise statistikk over den gjennomsnittlige punktligheten til et rederi for en måned og et år i form av diagrammer/grafer. Lavest prioritet. 2.2 Ikke-funksjonelle krav Alle de ikke-funksjonelle kravene er designet av gruppen for å sette en målbarhet for hvordan vi ønsker at systemet skal kunne yte når det står ferdig. De er ikke blitt utformet i samarbeid med oppdragsgiver, men er utformet med tanke på hvilke kvalitetsstandarder vi mener er nødvendig for at produktet skal kunne møte oppdragsgivers funksjonelle krav og behov. 1 Pålitelighet -Systemet skal designes med tanken på at det skal ha minst mulig feil som fører til at systemet krasjer. Antall timer nedetid på grunn av systemet sin programvaren skal være på maksimalt 2 timer per måned. 2 Effektivitet -Systemet skal være designet med hensyn på effektivitet. Alle komponentene i systemet skal til enhver tid bruke minst 30 % av total CPU-tid på systemet det kjører på. Systemet skal kunne lagre informasjonen slik at det går raskt å finne den fram igjen. 3 Kvalitet -Systemet skal være designet med tanke på kvalitet Minst 95 % av alle mulige feil skal være kartlagt før systemet taes i bruk Minst 90 % av alle mulige feil skal være fikset før systemet taes i bruk Maximum 10 % av systemets komponenter skal være avhengig av kode fra eksisterende systemer. 6

57 Kravspesifikasjon 4 Utvidbarhet -Systemets kapasitet skal enkelt kunne utvides etter behov Systemets mest ressurskrevende(hardwarekrevende) komponenter skal designes med tanke på at det skal være enkelt å legge til støtte for parallellisering. -Systemet skal være designet slik at koden og systemet lett kan endres. Systemet skal være delt inn slik at komponentene skal kunne kjøres og testes uavhengig av hverandre(objekt orientert). 5 Robusthet - Systemet skal være slik at det kan håndtere ufornuftig eller feilaktig input Systemet skal kunne håndtere all skadelig, uleselig eller ugyldig inputdata på en hensiktsmessig måte, slik at programmet ikke krasjer. 6 Testbarhet -Systemet skal være slik at det er enkelt å teste Hver komponent i systemet skal være slik at det på en hensiktsmessig måte, skal være mulig å teste dem for seg selv med fornuftig inputdata. Løsningen skal gi fornuftige feilmeldinger(exeptions) ved 100 % av kritiske steder i programmet under en test 7 Dokumentasjon - Systemet skal være dokumentert på en hensiktsmessig måte. Dokumentasjonen skal være så presis som overhodet mulig Dokumentasjonen skal ikke inneholde ufornuftige repetisjoner Dokumentasjonen skal være saklig og mest mulig objektiv Dokumentasjonen skal bygges opp etter UML-standard, men tilpasses der det er behov. Systemet skal inneholde kommentarer i kode ved alle viktige funksjoner eller moduler. Alle modulene og klassene skal inneholde docstrings. Dette er en type dokumentasjon som er ment å beskrive hva en metode/klasse eller modul gjør. 7

58 Kravspesifikasjon 3 Use case Figur Use-casediagram som beskriver hele systemet. Legg merke til at det ikke er spesifisert hvem aktør er. Dette er fordi oppdragsgiver ikke er helt sikker på hvem som skal bruke systemet, og faktisk se denne informasjonen. Vi har også valgt å ikke navngi leverandørene, fordi det er usikkert hvem som faktisk kommer til å ende opp med å bli leverandør av dataene. Diagrammet i figur 3.1 over viser hvordan de forskjellige aktørene samhandler med systemet. Vi vil gjerne påpeke at vi ikke har brukt use-casediagrammene under prosjektet fordi use-casene har vært svært få og ukompliserte. Det bør nevnes at for at brukeren skal kunne oppnå den interaksjonen med systemet på en hensiktsmessig måte som beskrevet her, bør alle kravene i kravspesifikasjonen være oppfylt. 8

59 Kravspesifikasjon 4 Sekvensscenarioer Fordi vi av mangel på aktører for systemet og ikke får noe ut av å sette opp relasjoner mellom bruker og system, har vi valgt å bruke scenarier. Istedenfor fokus på aktører i disse beskrivelsene har vi heller fokus på hva systemet gjør og utførelsessekvensene. Vi har bygd opp komponentene i systemet etter hver av disse scenariene. 4.1 Kjernefunksjonalitet Scenario 1 (Schedule-parser): Systemet lagrer alle rutetabellene (schedules) i databasen ved å parse schedule-filen som blir sendt fra ShipmentLink ( Informasjon om alle reisene lagres i en historikk-collection og skipsreisene for den førstkommende uken lagres i databasen. Den sistnevnte listen skal fungere som en cache slik at det blir enklere og mer effektivt å lage informasjon om rederienes punktlighet. Prebetingelse: E-postmeldingen med rutetabellfilene (schedule-filen) fra ShipmentLink. Postbetingelse: Skipsrutetabellfilen er parset og rutetabellene, både for historikkdelen og reisene for neste uke, er lagret i databasen. Collections: schedules.historic og schedules.current. Hovedscenario: 1. Åpner schedule-filen (i txt-format) for lesing. 2. Leser filen til den kommer til en handelsrutegruppe. 3. Lager en liste over havnene. 4. Finner havnekoden til havnen. Repeter steg 3-4 for hver havn. 5. Leser inn en linje og registrerer skipsnavn og reiseinformasjon for dette skipet, Repeter steg 5 til all reiseinformasjon for denne gruppen er registrert. Repeter steg 2-5 til det ikke finnes flere reiseplaner. 6. Registrere alle rutetabeller i en historikk-collection. 7. Registrerer alle reisene for den førstkommende uken i en annen collection som skal som fungere som en cache Scenario 2 (AIS-parser) Systemet mottar og parser kodet(encodede) AIS-data, dekoder dem og filtrer irrelevant data og sender dem til meldingskøen(mq/celery) for innlegging i database. 9

60 Kravspesifikasjon Prebetingelse: Dataene som serveren må være i AIVM format. En liste (collection) av skip som skal reise den førskommende uken er lagret i en egen collection. Nettverksportene som brukes må være ledige. Collections: ship.static og ship.voyagedata. Hovedscenario: 1. Mottar rådata (AIS-data) gjennom UDP-server og legger dem i en array 2. Repeter punkt 1 hvis arrayen ikke er fullt. 3. Velger en datalinje fra arrayen. 4. Sjekker at data er gyldig og kan dekodes. 5. Dekoder data. 6. Legger inn ferdig dekodet data i database dersom det er data for et tankskip eller frakteskip. 7. Gå til punkt 3 dersom det fremdeles er flere data fra arrayet som ikke er dekodet/gjennomgått Utvidelser og unntak: 1a. Dersom arrayet er fullt, legg dataet i et annet array 2a. Dersom data på siste plass i arrayet er ufullstendig (består av 2 linjer, men kun en linje finnes) utvid arrayet med 1 plass og gå punkt 1a. 4a. Dersom data er ugyldig/uleselig, skriv ut eventuelt feilmelding og gå til punkt 3. 7a. hvis alle data i arrayet er dekodet/gjennomgått gå til punkt Tilleggsfunksjonalitet Scenario 1 (Rederistatistikkoppdaterer): Systemet lagrer faktiske avgangs- og ankomsttid til skip og oppdaterer punktlighetsstatistikker for rederier. Prebetingelse: Listen over skip som skal reise denne uken eller er på vei til en havn finnes i databasen (Scenario 1 i avsnitt 4.1.1). Skipsposisjoner og statisk informasjon om skip er lagret i databasen. Lister over skip rederier eier finnes i databasen. Postbetingelse: Informasjon om når et skip begynte å reise fra eller ankom en havn er lagret i databasen. Antall forventede reisedager og antall timers avvik fra ETA-en for avsluttede reise er lagret i databasen. Punktlighetsstatistikker for rederier er oppdatert. Collections: voyages.traveling og voyages.arrivals Hovedscenario: 1. Trekker ut reiseplanene for denne uken (se scenario 1 i avsnitt 4.1.1)til et skip fra listen som ligger i databasen. 2. Finner MMSI-nummeret til skipet. 3. Trekker ut siste posisjon til skipet. 4. Registrerer når skipet begynte å reise fra havnen. 10

61 Kravspesifikasjon 5. Lagrer informasjon om faktisk avgangstid til skipet i egen collection. Lagrer både estimert og faktisk ankomsttid samt annet relevant informasjon (se prebetingelse). Reper steg 1-5 til alle skipene er behandlet. 6. Sletter reiseplaner for reiser der skipet er på vei fra uke-collection (se scenario 1 i avsnitt 4.1.1). 7. Trekker ut dokumentet for et skip som er på vei ( voyages.traveling ). 8. Trekker ut siste posisjon til skipet. 9. Registrerer når skipet er ankommet havn. 10. Lagrer informasjon om faktisk ankomst/avgangstid til skipet i egen collection (lagrer både estimert og faktisk ankomsttid samt andre tilhørende data). 11. Oppdaterer rederipunktlighetsstatistikk for det rederiet som eier skipet. Repeter steg 7-11 til alle skipene er behandlet. 10. Sletter dokumentene i voyages.traveling for skip som er ankommet bestemmelsesstedet. Utvidelser og unntak: 3a. Skipsposisjonen eksisterer ikke eller er for gammelt (Eldre enn tiden mellom hver gang denne jobben kjøres, altså 1 time.). 1. Hopper over til neste skip i listen (steg 1). 4a. Skipet er ikke i bevegelse: 1. Hopper over til neste skip i listen (steg 1) 8a. Skipsposisjonen eksisterer ikke eller er for gammelt (Eldre enn tiden mellom hver gang denne jobben kjøres, altså 1 time.). 1. Hopper over til neste skip i listen (steg 7). 9a. Skipet har ikke ankommet havn. 1. Hopper over til neste skip i listen (steg 7). Scenario 2 (Webside): Bruker får opp en web-side som inneholder punktlighetsstatistikker for alle registrerte rederier. Prebetingelse: Det finnes rederier som det er registrert skipsreiser og statistikker på. Postbetingelse: Rederiene er listet på web-siden og er rangert etter punktlighet. Web-siden inneholder også grafer som viser punktlighetsstatisk over tid for de siste 18 månedene. Hovedscenario: 1. Systemet henter totalstatistikk for alle rederier. 2. Systemet henter forsinkelsesprosentdata og kumulativ forsinkelsesprosentdata for alle rederier. 3. Systemet henter avviksprosentdata og kumulativ avviksprosentdata for alle rederier. 4. Systemet fyller inn tabellen over rederipunktlighetsstatistikker med data fra steg HTML-siden blir generert og sendt til brukeren. 6. Grafene med data hentet i steg 2 og 3 blir generert. 7. Resten av siden blir generert. 11

62

63 MARE NOSTRUM Del 3 Produktrapport

64 Produktrapport 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

65 Produktrapport 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

66 Produktrapport 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

67 Produktrapport Problemer med logging Referanser

68 Produktrapport 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

69 Produktrapport 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

70 Produktrapport 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

71 Produktrapport 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

72 Produktrapport 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

73 Produktrapport 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

74 Produktrapport 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

75 Produktrapport 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

76 Produktrapport 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

77 Produktrapport 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

78 Produktrapport 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

79 Produktrapport 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"

80 Produktrapport "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

81 Produktrapport 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

82 Produktrapport 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

83 Produktrapport 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

84 Produktrapport 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

85 Produktrapport 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

86 Produktrapport 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

87 Produktrapport 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

88 Produktrapport 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

89 Produktrapport 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

90 Produktrapport 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

91 Produktrapport 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))) =

92 Produktrapport 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

93 Produktrapport 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

94 Produktrapport 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

95 Produktrapport 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

96 Produktrapport 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

97 Produktrapport 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

98 Produktrapport 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

99 Produktrapport inneholder gyldige koordinater og ISO-koder. Disse dataene trenger vi for blant å avgjøre om et skip har forlatt eller ankommet en havn. Nedenfor er strukturen på et typisk dokument i denne collection-en vist. iso -verdien er en array som alltid inneholder to elementer, landskoden og stedskoden. For eksempel er [ NL, RTM ] ISO-koden til havnen i Rotterdam i Nederland. Det er ISO-koden til havnene vi har brukt for å identifisere en havn. loc -verdien er også en array med to elementer, men den inneholder to desimaltall istedenfor tekststrenger. Desimaltallene er koordinater i henholdsvis breddegrader og lengdegrader. { } "_id" : <heltall>, "aliases" : [<tekststreng>,...], "continent" : <tekststreng>, "country" : <tekststreng>, "flags" : <heltall>, "iso" : [landkode <tekststreng>, stedskode <tekststreng>], "loc" : [breddegrader <desimaltall>, lengdegrader <desimaltall>], "name" : <tekststreng>, 7.3 schedules.historic Her lagres alle planlagte skipsreiser (schedules) for alle skip. Dokumentene i denne collection-en genereres av klassen ScheduleImporter (les mer i kapittel 6.2). Siden rutetabellfiler kommer hver uke og de inneholder planlagte reiser for flere uker/måneder i fremtiden og i fortiden, forekommer det ofte repetisjoner i dokumentene. Det ønsket av oppdragsgiveren om å lagre alle planlagte reiser for å kunne referere til dem på et senere tidspunkt og for å kunne se hvilke endringer rederier gjører på rutetabeller. Nedenfor er datastrukturen til alle dokumentene i collection-en schedules.historic vist. For å avgjøre hvilket schedule-fil et spesifikt reise ble parset fra, ble det lagt en nøkkel i dokumentene som heter schedule_filename. Verdien på nøkkelen er filnavnet til schedule-filen som ble sendt fra ShipmentLink. Hvert dokument inneholder en array av planlagte reiser i kronologisk rekkefølge for et skip parset fra en bestemt schedule-fil. Denne arrayen er knyttet til nøkkelen schedules og inneholder en array av dokumenter. Hvert av disse dokumentene inneholder havnekoden til havnen skipet skal reise fra (from_loc), havnekoden til havnen skipet skal reise til (to_loc), estimert avgangstid og estimert ankomsttid. 37

100 Produktrapport ObjectID er en spesialdatatype i MongoDB. Nøkkelen _id med datatypen ObjectID legges til automatisk av MongoDB i alle dokumenter hvis man ikke velger å overskrive den manuelt. _id - nøkkelen er unik for alle dokumenter. Ingen dokumenter kan ha samme _id. { "_id" : <ObjectId>, "schedule_filename" : <tekststreng>, "ship_name" : <tekststreng>, "schedules" : [ { "to_loc" : <tekststreng>, "eta" : <tidsstempel (ISODate)>, "etd" : <tidsstempel (ISODate)>, "from_loc" : <tekststreng> },... ] } 7.4 schedules.current I denne collection-en lagres alle reiser som skal skje i uken etter at schedule-filen er parset. Den delen av koden som sjekker om et skip har forlatt en havn (se ) itererer gjennom dokumentene i denne collection-en og hvis skipet har forlatt havnen slettes dokumentet for denne reisen. Nedenfor er strukturen for dokumentene vist. Den er det samme som i collection-en schedules.historic, men nøkkelen schedule_filename finnes ikke. { "_id" : <ObjectId>, "ship_name" : <tekststreng>, "schedules" : [ { "to_loc" : <tekststreng>, "eta" : <tidsstempel (ISODate)>, "etd" : <tidsstempel (ISODate)>, "from_loc" : <tekststreng> }, 38

101 Produktrapport... ] } 7.5 voyages.traveling I denne collection-en lagres det informasjon om hvilke skip som er til havs og er på vei til en havn, altså aktuelle transitter. Noen av verdiene kopieres fra collection-en schedules.current etter at skipet har forlatt havnen. Avgangstiden (tod = time of departure), MMSI-nummeret til skipet, ID-en og navnet til rederiet skipet tilhører blir lagt i tillegg. Dokumentene i denne collection-en blir slettet når skipet har ankommet bestemmelsesstedet. { "_id" : <ObjectId>, "mmsi": <tekststreng>, "ship_name": <tekststreng>, "from_loc": <tekststreng>, "to_loc": <tekststreng>, "etd": <tidsstempel (ISODate)>, "eta": <tidsstempel (ISODate)>, "tod": <tidsstempel (ISODate)>, "shipowner_id": <heltall>, } "shipowner_name": <tekststreng>" 7.6 voyages.arrivals I denne collection-en finnes det lister over alle registrerte transitter. Det finnes dokumenter for hvert eneste skip som det er registrert transitt på. Hver eneste transitt har en array av transitt-dokumenter. Når et skip har ankommet en havn bør dokumentet for transitten i schedules.traveling fjernes og kopieres over til slutten av arrayen i voyages.arrivals. Den faktiske ankomsttiden, totalt antall forventete reisedager og avvik i antall timer skal også legges til i transittdokumentet. { "_id" : <ObjectId>, "mmsi": <tekststreng>, "voyages": [ { "shipowner_id": <heltall>, "shipowner_name": <tekststreng>, 39

102 Produktrapport "from_loc": <tekststreng>", "to_loc": <tekststreng>, "eta": <tidsstempel (ISODate)>, "etd": <tidsstempel (ISODate)>, "tod": <tidsstempel (ISODate)>, "toa": <tidsstempel (ISODate)>, "expected_travel_days": <heltall>, "deviation_hours": <heltall>, },... } ] 7.7 ship.static En av kravene fra oppdragsgiver var å lagre så mye data som mulig om skipene. AIS-data inneholder både statiske data og posisjonsrapporter. I denne collection-en lagres de statiske dataene. For å kunne finne MMSI-nummeret til et skip, så må det søkes i denne collection-en. Navnet på skipet og MMSInummeret til den er det som er relevant for dette prosjektet. Foreløpig lagrer AIS-recieveren alle datatypene som tekststrenger. { "_id" : <ObjectId>, "tostern" : <tekststreng>, "shipname" : <tekststreng>, "positionfixingdevice" : <tekststreng>, "mmsi" : <tekststreng>, "callsign" : <tekststreng>, "tostarboard" : <tekststreng>, "imo" : <tekststreng>, "tobow" : <tekststreng>, "draught" : <tekststreng>, "shiptype" : <tekststreng>, "toport" : <tekststreng>, } "dataterminalready" : <tekststreng ("false" eller "true")> 40

103 Produktrapport 7.8 ship.voyagedata Som nevnt i beskrivelsen av ship.static, så ville oppdragsgiveren at vi skulle lagre så mye informasjon om skipene som mulig. Dette innebærer også lagring av informasjon om posisjonen til et skip over tid. I motsetning til collection-en ship.static, der det lagres statisk informasjon om skipene som sjelden endres, så oppdateres dokumentene i ship.voyagedata veldig ofte. For hvert skip finnes det et dokument som inneholder MMSI-nummeret til skipet, destinasjonsdokumenter (viser hvilken havn skipet er på vei til og estimert ankomsttid) og posisjonsrapporter (informasjon om hastighet, kurs og posisjonen til skipet). Destinasjonsdokumentene som finnes i arrayen destinations er ikke alltid til å stole på siden ikke alle skip sender dette ofte og navnet på bestemmelsesstedet kommer ofte i andre bokstaver enn latinske. Det hender også at bestemmelsesstedet sendes i forskjellige tegnsett slik at de blir uleselige. Det hender også at ugyldig ETA sendes. Dette gjør informasjon om destinasjoner foreløpig ubrukelige. Posisjonsrapporter legges til i arrayen posistions. Dette er dokumenter som blant annet inneholder, kurset til skipet, lengdegrader, breddegrader, hastigheten over land og tidsstempel. Denne typen informasjon blir sendt veldig ofte av skip som er i bevegelse og nær land (flere ganger i minuttet). Foreløpig lagrer AIS-recieveren alle datatypene som tekststrenger. { "_id" : <ObjectId>, "mmsi" : <tekststreng>, "destinations" : [ { "received" : <tidsstempel (ISODate)>, "destination" : <tekststreng>, "eta" : <tekststreng (ofte i formatet: DD-MM hh:mm)> },... ], "positions" : [ { "courseoverground" : <tekststreng>, "maneuverindicator" : <tekststreng>, "rateofturn" : <tekststreng>, 41

104 Produktrapport "navigationstatus" : <tekststreng>, "received" : <tidsstempel (ISODate)>, "getrepeatindicator" : <tekststreng>, "longitude" : <tekststreng>, "speedoverground" : <tekststreng>, "second" : <tekststreng>", "positionaccurate" : <tekststreng ("false" eller "true")>, "latitude" : <tekststreng>, "trueheading" : <tekststreng>, "raimflag" : <tekststreng ("false" eller "true")> },... ] } 7.9 suppliers Collection-en suppliers inneholder en oversikt over forskjellige rederier med navn og ID. Denne collection-en er ikke laget av gruppedeltagerne, men av Xeneta. Den ble bare brukt bare for å finne ut hvilke rederier Xeneta viser informasjon om til sine kunder shipowners Her lagres det informasjon om hvilke skip hvert rederi eier og aggregerte transittider og punktlighetstall for alle transitter registrert på rederiet. Skipsarrayen inneholder en array av dokumenter. I dokumentene finnes det to felter: MMSI-nummeret til skipet og navnet til skipet. Disse dataene hentes foreløpig ikke fra et bestemt sted, men må fylles inn manuelt. Det finnes flere felter i shipowner -dokumenter relatert til punktlighetsstatistikker. Disse er: total_nr_of_transits: Totalt antall reiser (transitter) registrert på rederiet. total_nr_of_transits_with_delays: Totalt antall transitter som ble forsinket eller kom for tidlig. total_expected_travel_days: Totalt antall estimerte dager for alle reisene skipene tok registrert på rederiet. 42

105 Produktrapport total_deviation_hours: Totalt antall timers avvik fra ETA-datoen. Tellet er rundet opp til nærmeste time. Disse tallene er for alle reiser som er registrert på rederiene, men for å kunne viser punktlighetsstatistikk over tid finnes det også tilsvarende for hver måned og år det er registrert reiser for. Månedsstatistikker finnes i arrayen transits_previous_months og årsstatistikker transits_previous_years. Månedsstatistikker inneholder også året og månedsnummeret (month_nr) for den måneden det gjelder for. { "_id" : <ObjectId>, "shipowner_id" : <heltall>, "shipowner_name" : <tekststreng>, "ships" : [ { "mmsi" : <tekststreng>, "ship_name" : <tekststreng> },... ], "total_nr_of_transits" : <heltall>, "total_nr_of_transits_with_delays" : <heltall>, "total_expected_travel_days" : <heltall>, "total_deviation_hours" : <heltall>, "transits_previous_months" : [ { "year" : <heltall>, "month_nr" : <heltall>, "nr_of_transits_with_delays" : <heltall>, "deviation_hours" : <heltall>, "expected_travel_days" : <heltall>, "nr_of_transits" : <heltall>, } ], "transits_previous_years" : [ { 43

106 Produktrapport "year" : <heltall>, "nr_of_transits" : <heltall>, "expected_travel_days" : <heltall>, "nr_of_transits_with_delays" : <heltall>, "deviation_hours" : <heltall>, },... ] } 44

107 Produktrapport 8 Funksjonelt grensesnitt 8.1 Anbefalt spesifikasjoner for hardware Spesifikasjonene under er beregnet ut ifra resultatene fra testing under systemet. Fordi vi ikke vet helt nøyaktig hvor mye datakraft som kreves når systemet tas i bruk, kan vi ikke garantere for at disse spesifikasjonene vil være tilstrekkelig. Aissender Prosessor- Intel core 2 eller ekvivalent Minne: 1GB DDR3 SDRAM HDD: SSD eller RAID OS: Virker på alle OS Aisparser Prosessor: Intel nehalem Xeon processor 2Ghz Minne: 1GB 1333Mhz, DDR3 SDRAM OS: Virker på alle OS Threaded aisparser Prosessor: Intel nehalem Xeon processor 2Ghz Minne: 1GB 1333Mhz, DDR3 SDRAM OS: Virker på alle OS Aisreceiver Prosessor: Intel core 2 eller ekvivalent Minne: 1GB DDR3 SDRAM HDD: SSD eller RAID OS: Virker på alle OS Schedule-parser Prosessor: Intel Core 2 eller ekvivalent Minne: 1GB DDR2 eller DDR3. Harddisk: SSD eller 7200 RPM Harddisk 45

108 Produktrapport OS: Virker på alle operativsystemer. Rederistatistikkoppdaterer Prosessor: Intel Core 2 eller ekvivalent Minne: 1GB Harddisk: SSD eller 7200 RPM Harddisk. OS: Virker på alle operativsystemer. 46

109 Produktrapport 9 Driftssikkerhet 9.1 Avhengighet av eksisterende systemer Vi har tatt utgangspunkt i at Xenetas kjerne -API er konsistent. Vi har i den grad det er mulig unngått å la programmet avhenge av kode i Xenetas datasystemer. Allikevel er det enkelte deler av programmene som avhenger av at eksisterende systemkomponenter hos Xeneta. Dersom disse endres, så bør det påses at endringene ikke påvirker noen av elementene i dette programmet. Det er imidlertid kun schedule-parseren (ScheduleImporter-klassen) og klassen DataHandler (hører til mailserver som mottar reiseplaner) som bruker eksisterende kode fra Xeneta. Avhengighetene er som følger: Schedule-parser I klassen ScheduleImporter (beskrevet i kapittel 6.2) ble funksjonen guess() i modulen location.py (ligger i mappen xeneta/utils) brukt. Denne funksjonen returnerer havnekoden til navnet på havnene som sendes som argument til funksjonen. Denne funksjonen blir brukt i metoden get_port_code() i ScheduleImporter. Funksjonen er viktig for Xenetas applikasjoner og det er ikke forventet at det vil gjøres store endringer her som kan ødelegge systemet vårt. Mailserver Mailserveren er avhengig av Celery og Sentry-logging, som begge er eksisterende komponenter i Xeneta sine datasystemer. Per i dag 15/05/2013 vet vi at Xeneta har gjort store endringer i sin egen kode slik at Celery ikke lenger fungerer slik det skal. Dette førte til at mailserveren, en modul vi er avhengig av for å kunne motta rutetabellfiler (schedules), ikke lenger vil motta e-postmeldinger. Xeneta forklarte at dette skyldes at en av deres nyansatte hadde endret veldig mye kode uten å gi beskjed. Xeneta har også sagt at de påtar seg det fulle ansvaret for at programmet ikke virker som det skal. Vi vil også gjerne påpeke at da vi var ferdig med implementasjonsfasen, fungerte systemet slik det skulle. For mer tekniske detaljer rundt selve feilen, se kapittel 11 i denne rapporten. 47

110 Produktrapport 10 Utvidelsesmuligheter 10.1 Aisparser Parallellisering AIS-parseren er laget slik at det skal være enkelt å legge til støtte for parallellisering. Vi tror på bakgrunn av tester vi har gjort, at det lønner seg å parallellisere denne delen av programmet. Det finnes mange muligheter for å legge til parallellisering på ulike nivåer, for eksempel ved å bruke tråder eller ved å bruke Celery. Dette kan for eksempel gjøres ved å legge inn AIS-parser som en celery-task og få en egen server til å delegere datastrømmene til alle workers i celery. Vi har imidlertid ikke utarbeidet noen bestemt løsning for hvordan man gjør dette. Vi har som tidligere nevnt i underavsnittet , lagt til en alternativ versjon av AIS-parseren som støtter multithreading, men vi har ikke fått mulighet til å teste denne ordentlig ennå Mer avansert filtrering av data AIS-parseren kan også modifiseres til å avvise data som Xeneta ikke ønskes allerede før mesteparten av datafeltene dekodes. Dette gjøres ved å kaste meldingen dersom de første fem bitene av meldingen ikke er av den typen som ønskes. I klassen DecoderImpl ligger funksjonene som faktisk utfører dekodingen av data. Etter følgende linje i filen DecoderImpl.java : AISMessageType messagetype = encodedmessage.getmessagetype(); kan man gjøre test på om for eksempel messagetype==5. Dersom man for eksempel kun ønsker meldingstype 5, bør man sørge for å kaste en exeption dersom meldingstypen ikke er 5. Vi har lagt koden til programmet slik at det vil fortsette til neste linje med rådata ved exeptions, slik at dette vil være den tryggeste måten å fortsette til neste linje med data. Dette må i så fall gjøres før programflyten går videre til Switchblokken lengere ned i koden på samme side. Det bør nevnes at datatypen AISMessageType er en enum, slik at for eksempel tallet 5 faktisk refererer til meldingstypen ShipAndVoyageRelatedData. Datafeltet AISMessageType har også samme navn som klassen ( AISMessageType.java ). 48

111 Produktrapport Dersom man legger til denne funksjonaliteten så bør man fjerne all regex som ser etter meldingstype fra aisparser.java Ved for mye mengder av inputdata til parseren Siden vi ikke har fått muligheten til å teste systemet i virkeligheten, vet vi at det er en mulighet for at det kan komme for mye data til parseren når det taes i bruk. Dette kan fremdeles skje på tross av at man benytter seg av Threadedaisparser. Dersom det er for mye data som kommer inn til parseren samtidig finnes det hovedsakelig tre muligheter å løse problemet. Den ene er å kjøpe ny og forbedret hardware, dersom man ikke ønsker å redusere mengden av data man ønsker å lagre. Den andre muligheten er at vi har tenkt ut at man bør lage en ny modul som dataene går igjennom før selve AIS-parseren. Den kan da kun gjøre en overfladisk undersøkelse(ved å dekode 2 datafelt) for å identifisere et skip, og kaster data fra alle uinteressante skip. Den kan for eksempel avgjøre om et skip er interessant ved å sjekke om skipet finnes i databasen for schedules. Den siste muligheten er å be leverandøren om å selv begrense hvilke skip de sender data om, dette er sannsynligvis også den mest effektive metoden. Ved å unngå å motta uønsket data i første omgang slipper man også å filtrere dem Fjerne bruk av array Vi har valgt å bruke array i til å midlertid oppbevare data i Ais-parser.java. Dette er for å tilrettelegge støtte for multithreading. Det er tenkt at arrayene er ment å fungere som midlertidige pipeline-buffere. Dersom det er sikkert at multithreading aldri kommer til å bli tatt i bruk, kan man fjerne dette ved å følge prosedyren beskrevet under i dette punktet av rapporten. Fjerning av arrayene kan gjøres enkelt ved å fjerne alt i Ais-parser.java som har direkte med håndtering av arrays å gjøre (fjerne alle arrays, og metoder som tar array som input). Deretter bør man omprogrammere metoden handlemessagereceived() slik at dataene skrives direkte ut til TCP-socketen istedenfor at de legges i array. Man bør i så fall også legge objektet som skriver til TCP-socketen som en klassevariabel. Etter omprogrammeringen av handlemessagereceived() bør metoden Handling(String [] line) endres. Alle kall som oppretter klasser i denne metoden bør flyttes til et hensiktsmessig sted slik at 49

112 Produktrapport man slipper å bruke masse kraft på å opprette samme instans av samme klasse mange ganger. Inputen til metoden bør endres fra String[] til String, og resten av innholdet i metoden bør tilpasses dette. Dersom de som skal drifte systemet kun ønsker å kjøre programmet som en enkelt tråd (singelthreading), gir fjerning av arrays en fordel ved at behovet for sporing av datafragmenter (data som er delt opp i flere linjer )på slutten av hvert array forsvinner. En annen fordel er at mottak av data blir mer kontinuerlig, istedenfor å gå i bursts når arrayet fylles. Ulempen er at det blir vesentlig mindre sannsynlig at programmet faktisk klarer å fange opp og dekode meldinger som er delt opp i 2 eller flere deler. Det bør også nevne at det ligger inne støtte for håndtering av datafragmenter i klassen NMEAMessageReceiver. Vi vil allikevel nevne at vi regner med at bruk av arrays i programmet ikke vil føre til noen nevneverdig flaskehals for systemet, på grunn av at det sannsynligvis vil ta lengere tid å legge data inn i databasen (se i underavsnittet ) Aisreceiver Parallellisering Det skal være mulig å enkelt legge til funksjonalitet for parallellisering for programkoden i filen Aisreceiver.py. Her kan man også enten bruke multithreading eller celery, men fordi køen for minneaksesser (med unntak av processor caches) er felles for alle prosessorkjernene er det lite å hente fra å parallellisere ved å bruke multithreading. Ser vi bort ifra prosessorens Translation lookaside buffer vil minneaksessene ta like lang tid Lønner det seg å parallellisere denne modulen? Celery kan ha en positiv effekt på ytelsen dersom nettverket er responsivt nok, i så fall må det være et krav at dataene går igjennom hele systemet i en helt kontinuerlig strøm. Dersom det ikke gjør det, kan forsinkelsen på nettverkstilkoblingen føre til at bruk av celery vil være mindre effektivt. Vi har som sagt valgt å løse eventuell nettverksforsinkelse ved å bruke pipelinebuffers i Aisparser.java. Som tidligere nevnt vet vi at hastigheten på data som blir prosessert i en pipeline er like rask som den tregeste komponenten i pipelinen. Legg merke til at forsinkelse på tilkobling kun spiller noen rolle dersom prosesseringshastigheten for hele strømmen av data, gjennom hele systemet er variabel. 50

113 Produktrapport Figur Diagram som viser prosesseringstid uten parallellisering. Total prosesseringstid for et enkelt data er i worst-case på 41ms (estimert). Men tar man utgangspunkt i at datastrømmen er kontinuerlig vil total ventetid i verste fall være på 21ms fra man putter noe inn til noe kommer ut, og i beste fall være 1.06ms(gitt at alle data som finnes i pipelinen på tidsintervallet har like god prosesseringstid). Legges celery til i AIS-receiver slik systemet ser ut nå, bør det legges til ytterligere 10ms (før boksen der det står AIS-receiver) for nettverksforsinkelse. Det er ganske enkelt å trekke den konklusjonen av figuren at slik den ser ut nå, er det ikke mye å hente på å legge inn støtte for celery i AIS-receiver. Dette er på grunn av forsinkelsestiden til AIS- Sender(som er større eller like AIS-receiver), og fordi det blir mer nettverksforsinkelse ved å sende dataene videre til andre maskiner. På den andre siden, så vil AIS-Sender ikke brukes når løsningen taes i bruk. I virkeligheten så vil det derfor sannsynligvis komme inn mye mer data til AIS-parser (og dermed AIS-receiver) enn det som sendes fra AisSender per i dag. Dersom dette er tilfellet og Aisreceiver-modulen blir en flaskehals, kan bruk av Celery være veldig aktuelt. Vi minner som sagt om at parallellisering i seg selv skaper delays på grunn av schedulingen. Derfor anbefaler vi testing av effektiviteten på systemet før Celery taes i bruk Schedule-parser Schedule-parseren (klassen ScheduleImporter i modulen schedule_importer.py) kan tolke riktig alle rutetabellfilene (schedule-filer) som sendes fra ShipmentLink. Med mindre formatet på schedule-filene fra ShipmentLink blir endret i fremtiden vil det ikke være behov for å gjøre store forandringer i programmet. Men det er et par steder koden kan endres for å gjøre schedule-parseren mer robust og mer effektiv. 51

114 Produktrapport Fordi det finnes flere havner som har samme navn, må også landsnavnet til hvor havnen ligger i brukes i tillegg til navnet på havnen i søket etter havnekode. Xenetas eksisterende kode inneholder en funksjon som gjør dette. Funksjonen heter guess() og ligger i modulen location. I ScheduleImporter-klasssen finnes det ikke kode som sjekker hvilket land eller region havnen ligger i. På grunn av at land ikke sendes som argument til funksjonen guess(). Den kaster da unntak hvis flere enn én havnekode kan være mulige kandidater for en havn som sendes som argument. Derfor måtte det legges til noen hardkodete havner i ScheduleImporter-klassen. Som forklart i kapittel 6.2 er alle reiseplanene gruppert etter kontinent/region og som igjen er gruppert etter handelsruter. Det som kan utvides i ScheduleImporter er å trekke ut informasjon om regionen/kontinentet. Funksjonen guess() som Xeneta implementerte tar foreløpig ikke kontinentet til havnen som argument. For at ScheduleImporter skal utvides til å finne kontinentet eller landet til en havn, så må også guess() -metoden utvides til å bruke kontinentet til å finne en bestemt havn Rederistatistikkoppdatereren Det er anbefalt å lagre så mye data som mulig i en MongoDB-database og det hadde derfor vært aktuelt å lagre også selve prosenttallene for rederipunktlighetsstatistikker i databasen, da slipper man å bruke unødvendig med CPU-ressurser hver gang metoden skal returnere punktlighetsstatistikker til brukere som åpnet web-siden. Metoden register_arrival() i klassen DepartureArrivalUpdater kan derfor utvides til å lagre prosenttallene i databasen Web-applikasjonen Det finnes flere utvidelsesmuligheter i Web-applikasjonen. Web-siden som viser rederipunktlighetsstatistikker kan utvides med mer funksjonalitet og valgmuligheter for brukeren og det kan lages andre sider som kan vise informasjon om bestemte skip. På web-siden kan man legge til valgmuligheter for grafene som gjøre det mulig for brukeren å bestemme startdatoen og sluttdatoen til grafenes tidsakser. En lignende funksjonalitet kan også implementeres for tabellen som i nåværende stund inneholder bare tall for alle transitter registrert på rederiene. Hvis man har tilgang til AIS-data som sendes via satellitt, kan man f.eks. spore et skip hele turen den tar, selv om den er langt fra land. Dette gir flere muligheter til utvidelser. Blant annet kan man tegne på et kart ruten et skip har tatt på en reise, gi kunder en advarsel på at skipet er forsinket med hensyn på posisjonen fra tidligere transitt osv. 52

115 Produktrapport 11 Kjente feil Som tidligere nevnt i kapitlet om driftssikkerhet (kapittel 9), har vi sannsynligvis ikke fått mulighet til å oppdage alle feilene i produktet ennå. Mange av dem er sannsynligvis knyttet til konsistens av dataene og hvor nøyaktige de endelige dataene vil bli. Nedenfor står det kort en oversikt over kjente feil på systemet og eventuelt hva som forårsaker dem Endringer av opprinnelig kode Enkelte deler av programmene vi har implementert selv er avhengig av Xenetas programmoduler, disse er blant annet knyttet til Celery og det som har med logging å gjøre. Etter at vi ble ferdig med det meste av implementasjonen gjorde Xeneta store endringer i sin egen eksisterende kode. Vi fikk beskjed av oppdragsgiver å merge (smelte) sammen endringene de hadde gjort med vår kode hele tiden mens vi programmerte. Tidlig i mai førte en av endringene på Xenetas side at det oppstod problemer med å starte opp Celery på testserveren. Loggingsfunksjonaliteten ble også endret. Problemer relatert til Xenetas endringer står beskrevet i avsnittene under. Siden vi hadde sluttet med utveklingen og det var ikke mye tid igjen, valgte vi å ikke gjøre noe for å fikse problemet Problemer med Celery Schedule-parseren og rederistatistikkoppdatereren er avhengig av at Celery fungerer. Vi er ikke sikre på hva Xeneta har gjort med koden relatert til Celery, men vi vet at de endringene har ført til Celery ikke kan kjøres på testserveren. E-postserveren oppretter en Celery-task når en e-postmelding mottas og i Celery-tasken opprettes en instans av Handler-klassen (se i figur 6.4). I denne klassen analyseres e-postmeldinger og videresendes videre til de modulene som skal behandle e-postmeldingene. Siden Celery ikke fungerer kan ikke Handler startes og e-postmeldinger kan ikke behandles. Schedule-parseren fungerer altså ikke. Rederistatistikkoppdatereren (beskrevet i kapitel 6.3) kan ikke kjøres periodevis av seg selv uten at Celery kjører. Det er som nevnt i avsnitt 6.3.1, Cerley beat som brukes for å kjøre Celery-jobber (Celery tasks) på bestemte tidspunkter. Rederistatistikkoppdatereren vil altså ikke fungere. Enhetstesten til denne programmodulen kan fortsatt brukes til å teste den. 53

116 Produktrapport Problemer med logging Xeneta har også endret måten logging skjer og den delen av koden vår som brukte loggingsfunksjonaliteten fungerer ikke lenger. Schedule-parseren og klassen DataHandler (modulen xeneta/marenostrum/ _handler.py) er de programmodulene som ble påvirket av dette. Enhetstesten for ScheduleImporter fungerer heller ikke. En løsning på dette er å fjerne all kode som er relatert til loggføring av feil og unntak. 54

117 Produktrapport 12 Referanser 1. AIS: 2. AIS-decoder: 3. AIS dekoding: 4. Alpha testing: 5. Data alignment: 6. Handshake: 7. IP: 8. Opprinnelig dokumentasjon for AIS-parser: 9. Parallellisering: Pipelining og pipeline buffer: UDP: TCP: 55

118

119 MARE NOSTRUM Del 4 Brukermanual

120 Brukermanual Forord Denne delen av rapporten er ment å forklare alle som bruker systemet, det mest nødvendige de trenger for å bruke systemet. Det bør også merkes at som nevnt i kapittel 11 i produktrapporten, oppsto det en del problemer med systemet etter at vi var ferdig med implementasjonsfasen på grunn av endringer på kjernefunksjonalitet på systemet deres som de ikke hadde varslet. Denne manualen er imidlertid utformet med tanke på at systemet fungerer slik det gjorde da vi var ferdig med det. 2

121 Brukermanual Innholdsfortegnelse 1 Notasjoner Innledning Hoveddel For administrator Oppstart av AIS-parseren Oppstart av schedule-parseren Oppstart av rederistatistikkoppdatereren Oppstart av web-applikasjonen Feil og rettingsmuligheter For brukere

122 Brukermanual 1 Notasjoner For bruk av alle notasjoner i denne delen av rapporten, se ordlisten i vedlegg 1. 2 Innledning Programmet er laget og bygd for at det skal kunne vise statistikk over hvilke rederier som er mest punktlige. Mesteparten av programmet er kun ment å kjøre i bakgrunnen, derfor vil ikke programmet skrive ut noe særlig meldinger annet enn feilmeldinger når det kjører. Dette er selvfølgelig med unntak av web-siden som skal vise statistikken som programmet skal beregne. De fleste av feilmeldingene i programmet kommer i form av exeptions, men skal ikke kunne oppstå i normale brukstilfeller for sluttbruker. Disse er ofte ganske selvforklarende, men skal kun kunne oppstå ved eventuelle bugs eller feil ved programmet. 4

123 Brukermanual 3 Hoveddel 3.1 For administrator Systemet er designet til å fungere på Linux, men skal virke på alle plattformer med forandringer i filbaner som benyttes av programmet. Dette er fordi vi har valgt å ikke innføre begrensninger på plasseringer av filene av hensyn til oppdragsgiver. Websiden er selvsagt fullstendig plattformuavhengig. Framgangsmåten under for oppstart av programmet er derfor skrevet for Linux Oppstart av AIS-parseren Det er viktig at komponentene i AIS-parseren startes i riktig rekkefølge. Dette er for at nettverkstilkoblingen er nødt til å gjøres i riktig rekkefølge for at programmet skal virke som det skal. Legg også merke til at kun en versjon/instans av programmet kan kjøre samtidig på et system. Figur Denne illustrasjonen viser en helt standard framgangsmåte for å starte opp aisparseren i linux. 1.a Dersom man ønsker å legge aisreceiver.py og mappen dk (som inneholder aisparseren) på forskjellige maskiner, bør man endre linjen clientsocket = new Socket("localhost", 2876); Slik at den kobler til den IP-adressen som aisreceiver.py kjører på. 1.b start aisreceiver.py med kommandoen python aisreceiver.py& i den samme mappen som aisreceiver.py ligger i slik som er gjort i figuren over. 5

124 Brukermanual 2. Gå til det stedet der du har lagt mappen dk, som inneholder java-delen av programmet. Pass på å ikke gå inn i selve mappen dk før man går til neste trinn, men blir værende i mappen under. 3.a Skriv så inn sudo java -cp. dk.tbsalling.aismessages.aisparser& som i illustrasjonen over. 3.b Dersom man isteden ønsker å kjøre aisparseren med innlagt støtte for multithreading, skriv sudo java -cp. dk.tbsalling.aismessages.threadedaisparser& istedenfor kommandoen i punkt 3.a. 4. For at aisparseren skal fungere må det mottas data gjennom udpserveren som ligger implementert i aisparseren. Ais-rådata må derfor sendes fra en distibutør av aisdata til port 2044 på denne serveren. Dersom dette er i orden, fortsett videre til oppstart av schedule-parseren Tilleggsfunksjon 5. Dersom man ikke har noen avtale med noen ekstern leverandør kan man alternativt bruke applikasjonen aissender for å lese av en fil med rådata for testing eller for å eventuelt kjøre et alternativt opplegg. Denne startes opp fra det samme stedet som beskrevet i punkt 2. 6.a Før man utfører oppstartskommandoen av aissender bør man endre plasseringen og eventuelt navnet på filen som skal leses inn slik at den prøver å lese fra riktig sted. For å gjøre dette så endrer man linjen Path file=filesystems.getdefault().getpath("/home/hioa/ais-parsing_test", "nmea.dump"); til Path file=filesystems.getdefault().getpath( <banen der innlesningsfilen ligger>", "<navn på filen som skal leses inn>"). 6.b Dersom man ønsker at aissender.java og aisparser.java skal ligge på forskjellige maskiner, bør man endre hvilken adresse som klienten i aissender.java skal koble seg til. Dette gjør man ved å endre linjen InetAddress inetaddress = InetAddress.getLocalHost();, slik at datafeltet inetaddress inneholder den IP-adressen man ønsker at aissender skal koble seg til. 7. Etter filen er endret kan man starte opp AisSender med kommandoen sudo java -cp. dk.tbsalling.aismessages.aisparser& Oppstart av schedule-parseren Schedule-parseren er ikke et program som kjøres manuelt. Schedule-parseren (klassen ScheduleImporter i modulen schedule_importer.py) kjøres automatisk når e-postserveren mottar en e- postmelding som inneholder en gyldig rutetabellfil. Rutetabellfilen blir formatert(parset) og reiseplanene lagres i databasen. 6

125 Brukermanual Modulen schedule-parseren ligger i (schedule_imorter.py) ligger i mappen xeneta/marenostrum/schedule. Den kan flyttes til et annet sted, men da må importeringskoden i DataHandler-klassen samsvare med filstien til modulen schedule-parseren ligger i. Importeringskoden er foreløpig følgende: from schedule.schedule_importer import ScheduleImporter. For at ScheduleImporter-klassen (schedule-parseren) skal fungere må Celery kjøre. Når en schedule-fil mottas av e-postserveren, lages det en Celery-task som analyserer e-postmeldingen og når det er verifisert at e-postmeldingen inneholder en gyldig schedule-fil som filvedlegg, kan parsingen av filen skje. For å motta schedule-filer hver uke fra ShipmentLink ( må man abonnere på schedule-filer ved å registrere en e-postadresse på deres web-side. Foreløpig abonnerer e-postadressen shipmentlink@marenostrum.xeneta.com på schedule-filer. Hvis man vil registrere en annen e- postadresse, kan man gjøre det på denne siden: Husk å avregistrere den gamle og å endre koden i modulen xeneta/ /handler.py og xeneate/marenostrum/ _handler.py til å godta meldinger med den e-postadressen det er registrert på. ScheduleImporter-klassen og DataHandler-klassen inneholder kode som loggfører feil- og unntakshendelser til Xenetas Sentry-server. Les om logging i avsnitt i Prosessraporten. I avsnitt er det listet opp feilmeldinger og unntak som kan oppstå ved parsing av Schedule-filer Oppstart av rederistatistikkoppdatereren Akkurat som Schedule-parseren, så skal ikke dette programmet (klassen DepartureArrivalUpdater) kjøres manuelt. Den kjøres periodevis og er foreløpig satt til å kjøre en gang i timen. For at DepartureArrivalUpdater-klassen skal fungere må Celery kjøre. Dette er fordi den skal kjøre periodevis som en Celery-task Oppstart av web-applikasjonen Web-applikasjonen startes ved å kjøre kommandoen sudo python xeneta/marenostrum/web/rendering_templates.py & hvis man er i git-rotmappen (annerledes filsti hvis man er i annen mappe). Web-applikasjonen kjører på port 80 og web-siden kan dermed aksesseres ved å gå til siden hioa-project.xeneta.com. 7

126 Brukermanual Feil og rettingsmuligheter Denne delen tar for seg mulige feil ved vanlige brukstilfeller og eventuelt hvordan man fikser dem Adressen er allerede i bruk Dersom denne meldingen kommer opp, kan det komme av to grunner. Enten er en av portene i bruk av et annet program. Da bør man sørge for å lukke programmet på en forsvarlig måte, og deretter starte opp dette programmet. Den andre muligheten er at hele eller deler av programmet allerede kjører. Ønsker man å starte programmet om igjen, bør man drepe alle de aktive prosessene som kjører programmet. De prosessene som man er nødt til å drepe er: aisparser, aisreceiver.py og eventuelt AisSender og Threadedaisparser dersom man har startet opp disse Aisparseren er inresponsiv og treg Sluttbruker bør sørge for at deres system er på høyde med systemkravene som er satt i produktdokumentasjonen. Vi kan ikke garantere at aisparseren vil kjøre effektivt på alle systemer. Hvis dette problemet oppstår ved bruk av threadedaisparser, så skyldes det sannsyneligvis at det kommer mer data inn enn det systemet/maskinen kan håndtere, og det vil derfor hope seg opp. Hvis dette skjer bør man enten bruke den vanlige versjonen av aisparser, oppgradere hardware, eller be leverandøren av aisdata om å begrense datamengden Feilmeldinger knyttet til parsing av schedule-filer Loggingfunksjonen sender feilmeldinger og unntaksfeilmeldinger til Sentry-serveren og på web-siden til Sentry-servren kan man se alle meldingene som har blitt sendt til Sentry-serveren. Dette avsnittet viser en liste over feilmeldinger. "Invalid filename: <FILNAVN>" (exception av typen ValueError). Filnavnet til schedule-filen er ugyldig. Filnavnet må være i formatet Schedules_YYYYMMDD.txt der YYYY er året, MM er måneden og DD dagen for datoen til schedule-filen. "Could not parse line: <REISPLANLINJE>". En linje i schedule-filen kunne ikke parses (tolkes). Enten inneholder akkurat den linjen ugyldige tegn eller så kan formatet i schedulefilen være ugyldig. For det første tillfellet bør kanskje det regulære uttrykket oppdateres til å kunne håndtere linjer av den typen. For det andre tillfellet, kan det rett og slett bare bety at ShipmentLink sendte en schedule-fil som inneholder fiel eller i verste fall er schedule- 8

127 Brukermanual filformatet endret for alle fremtidige schedule-filer og man må oppdatere en stor del av ScheduleImporter-klassen (schedule-parseren). "No schedules for ship '<SKIPNAVN>'. Schedule filename: <FILNAVN>". Det ble ikke funnet noen reiseplaner for dette skipet. Dette er ikke en feil, men bare en advarsel som kan brukes til debugging. Det kan hende at schedule-parseren ikke har klart å parse schedule-filen riktig. "Schedules parsed from a schedule with the same filename (<FILNAVN>) already exists. No schedules will be saved.". Det er blitt oppdaget reiseplaner som er parset fra samme schedulefil. Ingen reiseplaner blir lagret i databasen. En schedule-fil bør ikke parses mer enn én gang. Hvis man må parse den, så må alle reiseplandokumenter i databasen som er knyttet til samme schedule-filnavn slettes. The date YYYY-MM-DD extracted from the schedule filename is not in the current week. The schedules could only be saved in the historic/archive collection.. Datoen ekstrahert fra filnavnet til schedule-filen er ikke i denne uken. Dette betyr at ingen reiseplaner kunne lagres i collection-en schedules.current., altså reiseplaner for den kommende uken. Hvis ikke denne feilmeldingen er forventet, så er det noe galt med den dan delen av koden som ekstraherer datoen ut av filnavnet eller datoen er ugyldig. "Wrong date format: '<DATO>'. Should be mm/dd.". En dato i schedule-filen er i en ugyldig format. "Invalid date: YYYY-MM-DD" (exception av typen ValueError). Datoen i en av reiseplanene er ugyldig. Dette kan enten bety at schedule-filnavnet ikke stemmer overens med datoene i reiseplanene med tanke på skuddår eller at schedule-filen inneholder ugyldige datoer rett og slett Feilmeldinger knyttet til anaylsering av e-postmeldinger Feilmeldingene under er feilmeldinger knyttet til analysering av e-postmeldinger som ble sendt til en adresse som ender "Invalid local-part '<LOKAL ADDRESSE' of the address sent from <AVSENDERS MAILADRESSE>". Den delen av e-postadressen som kommer er ugyldig. Den skal være shipmentlink for at programmet skal verifisere e-postmeldingen som en e- postmelding relatert til rutetabeller fra ShipmenLink. "Invalid schedule message from <AVSENDERS MAILADRESSE>.". Ugyldig e- postmelding. Dette er ikke en gyldig e-postmelding. "Schedule from <AVSENDERS MAILADRESSE> is not a multipart message.". E- postmeldingen er ikke en multi-part-melding. Den inneholder blant annet ikke filvedlegg. 9

128 Brukermanual "No file attachments could be found in schedule from <AVSENDERS MAILADRESSE>". Ingen filvedlegg ble funnet i e-postmeldingen. Det betyr at ingen filvedlegg "File attachment '<FILNAVN>' in schedule from <AVSENDERS MAILADRESSE>is not a txt-file.". Filvedlegget i e-postmeldingen er ikke en txt-fil. Resten av filvedleggene vil bli analysert. OBS! Bare én schedule-fil fra hver e-postmelding vil bli parset. 3.2 For brukere Web-siden viser punktlighetsstatistikker for alle rederier det er registrert transitter på. På web-siden finnes det en tabell over alle rederier med sine punktlighetsstatistikker. I den andre kolonnen står det hvor mange transitter det er registrert på rederiet. Den tredje kolonnen viser hvor stor del av alle transittene kom for tidlig eller for sent. Den fjerde kolonnen viser hvor stor avvik det er fra den estimerte ankomsttiden (ETA) og den virkelige ankomsttiden. Tabellen er sortert etter forsinkelsesprosent (andre kolonne). Man kan klikke på tabell-headeren i en bestemt kolonne for å sortere tabellen etter den kolonnen man klikker på. Over tabellen står det beskrevet hvordan punktlighetsstatistikkene er beregnet. Resten av web-siden inneholder grafer som viser forskjellige punktlighetsstatistikker over tid de siste 18 månedene. For en nærmere forklaring av hvordan tallene og dataene bak grafene blir beregnet, se i produktrapporten i kapittel 6.4. For de fleste brukere, er imidlertid forklaringen på web-siden god nok. 10

129 MARE NOSTRUM Del 5 Testrapport

130 Testrapport Forord Dokumentet er en testrapport for hovedprosjektet Marenostrum utført av gruppe 17. Rapporten er skrevet med hensyn på sensoren slik at sensoren kan evaluere testen vi har utført, og for produktets videreutviklere slik at utviklerne kan se hvilke deler av produktet er testet og hva det finnes av automatiserte enhets tester. 2

131 Testrapport Innholdsfortegnelse 1 Forhold og organisering av testene Testing av AIS-parseren Behovet for testing Testplattform Testspesifikasjoner Konklusjon fra alle testene/mulige feil på systemet Forklaring av overskrifter og parametere i testbeskrivelser Pålitelighetstester: Ytelsestester: Konsistenstester: Schedule-parseren Testplattform Formålet med testing Utførte tester Rederistatistikkoppdatereren Testplattform Formålet med testing Utførte tester

132 Testrapport 1 Forhold og organisering av testene På grunn av at det var veldig mange algoritmer i testen, ble det derfor utført ganske mange tester gjennom prosjektet. De fleste av dem var egentlig ikke planlagte, offisielle tester, men heller tester for å påse at programkode fungerte slik det skulle. Testingen av de forskjellige programkomponentene som er knyttet til prosjektet, har mer eller mindre foregått uavhengig av hverandre. Dette er fordi koden til de forskjellige komponentene er uavhengig av hverandre og at all informasjon som utveksles mellom komponentene går asynkront gjennom MongoDB. Rederistatistikkoppdatereren er imidlertid avhengig av data fra AIS-parser og Scheduleparser, men den er ikke avhengig av at disse komponentene må kjøres samtidig for å kunne virke. Tilsvarende gjelder også websiden, som er avhengig av data fra rederistatistikkoppdatereren. Det bør også nevnes at standarden på testene kan variere litt mellom komponentene. Dette er fordi at testene hovedsakelig ble utført av forskjellige personer, slik at tekstdokumentet også er blitt skrevet av forskjellige personer. Motivene for å utføre testing er også veldig forskjellig. Vi har også følt at enkelte av komponentene som selve websiden. ikke trenger like grundige tester som mer avanserte og kompliserte komponenter som for eksempel AIS-parseren. 4

133 Testrapport 2 Testing av AIS-parseren Under arbeidet med AIS-parseren ble det gjort utallig mange tester, og alle sammen er ikke dokumentert. Vi har imidlertid valgt å dokumentere de testene som har vært mest betydningsfulle og som har ført til at vi har tatt viktige avgjørelser på hvordan denne delen av programmet skal se ut. Testene som er beskrevet under er som regel kjørt flere ganger, gjerne med noen svært små endringer for å rette opp mindre feil, men igjen uten å endre premissene for testen. 2.1 Behovet for testing Testingen har vært en veldig viktig del i denne delen av prosjektet. Fordi delen som skal prosessere GPS-data potensielt mottar data fra hele verden, blir det derfor veldig store mengder data som må prosesseres. Målet med denne delen av programmet er å prosessere så mye data som mulig samt å få lagret nok data til at det er mulig å spore en rute fra et bestemt skips avgangssted fram til skipets destinasjon. Dersom for mye data forsvinner, er det en sjanse for at løsningen for eksempel kan bomme på skipets ankomst til havnen (fordi posisjonen for skipets ankomst drukner i resten av datastrømmen), og at ankomsten aldri vil registreres. Det som kanskje er enda viktigere, er at løsningen i sin helhet er pålitelig og at den har en god mekanisme for feilhåndtering som gjør at programmet ikke krasjer. Dette setter dermed et stort krav til pålitelighet til denne delen av systemet, som (etter planen) skal gå igjennom flere millioner linjer med data. Testingen er derfor spesielt med tanke på at det skal kjøre uten at programmet krasjer. 2.2 Testplattform De fleste av testene er utført på Xeneta sin testserver med følgende spesifikasjoner: Prosessor: AMD Opteron 4170 HE 2.1 GHz Minne: 2 GB RAM Operativsystem: Linux, Ubuntu 2.3 Testspesifikasjoner Testene som er utført er kategorisert i tre kategorier; pålitelighet, effektivitet/ytelse og konsistens. I dette prosjektet legges det imidlertid mest vekt på pålitelighet i forhold til kjøring av løsningen. Det fremste kravet eller målet til slutt er å ha et system som er i stand til å legge inn data på en fornuftig måte slik at kundene kan få en sikker informasjon som er konsistent over tid. Dette vil også være en 5

134 Testrapport indirekte påvirkning fra effektiviteten, siden hvor effektivt programmet vil kjøre kan avgjøre nøyaktig hvor konsistente dataene også blir. Testene som er gjort er også utført med tanke på de verst tenkelige situasjonene, i forsøk på å avdekke eventuelle feil i systemet. 2.4 Konklusjon fra alle testene/mulige feil på systemet Det bør nevnes at i forhold til konsistens av data så er det ganske vanskelig å si hvordan dette vil fungere når systemet tas i bruk. Som nevnt i kapittel i prosessdokumentasjonen, fikk vi ikke mulighet til å teste systemet med sanntidsdata fordi Xeneta fikk problemer med sine leverandører. Vi vet derfor ikke om systemet er i stand til å legge inn nok data over tid, slik at det faktisk ligger nok data i systemet. Dersom det ikke er nok data om et bestemt skip, er det en fare for at ankomster til flere havner ikke blir beregnet. Det er med andre ord en mulighet for at interessant informasjon kan drukne i mengden av data. Sjansene for at dette kan skje kan imidlertid reduseres enten ved å parallellisere systemet slik at større mengder data kan prosessere samtidig. En annen mulighet er for leverandøren å innsnevre hvilket geografisk område som man ønsker å motta data fra, slik at langt færre data må prosesseres. 2.5 Forklaring av overskrifter og parametere i testbeskrivelser Vi påpeker at testrapportene er skrevet med tanke på et nåtidsperspektiv. Kommentarene i selve testskjemaene er en refleksjon over hva vi planla å jobbe videre med etter testen. Hver av testene kan inneholde flere tester som er utført på forskjellige tidspunkt og i forskjellige deler av koden. Testene er derfor angitt med testnummer for å unngå duplikat av testnavnene Pålitelighetstester: Test: AIS-parser inndata Testnummer: 1 Formålet med testen er å prøve å legge inn kodet(encodeded) data i AIS-parseren, og deretter ta dataene som returneres og legge dem inn i MongoDB Tabell Test på parsing av AIS-data. Testnummer: 1. Programversjon: Ikke tilgjenglig Dato: 01/03/2013 6

135 Testrapport Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Resultat: python AIS-parser Lar Python AIS-parser lese inn data fra fil som vi har kalt nmea.dump. Deretter så parses dataene og vi har laget kode som skal legge disse inn i MongoDB når de kommer ut. Dataene som legges inn i mongo, legges bare direkte inn foreløpig. Først startes scriptet opp, deretter skal programmet gå igjennom hele filen og skrive ut alle dataene. Programmet skrev ut mange data, men fikk segmentationfault underveis. Vi vet ikke nøyaktig hva feilen kommer av, annet enn at det sannsynligvis er en peker i C++ delen som peker til et ugyldig sted i minnet (et segment som operativsystemet ikke har allokert til programmet). Kommentar: Vi prøver å se på årsaken til feilen, samtidig som vi går på nettet og ser etter alternativer til C++ biblioteket. Testnummer: 2 Formålet med testen er å sjekke om en ny versjon/bibliotek av en AIS-parser vi fant på nettet faktisk virker og kan brukes til vårt formål. Tabell Test på innlegging av AIS-data. Testnumer: 1 Programversjon 0.1 Dato: 10/03/2013 Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Resultat: Java AIS-parser Vi fant en AIS-parser for Java på nettet som vi har tenkt å prøve ut. Denne testen prøver ikke å legge noe inn i databasen, men skal sjekke at programmet kjører uten å krasje for alle mulige inputdata. Til dette endret vi koden til biblioteket vi fant til å lese inn data fra fil istedenfor å lese inn data fra et array (som fulgte med en demo av programmet). Programmet startes opp, deretter prøver vi med forskjellige typer test-data samt ugyldige data for å prøve å få programmet til å krasje. Programmet skriver ut data riktig og krasjer ikke. Det er imidlertid en del data som den ikke klarer å dekode, men dette er allikevel akseptabelt. Vi la imidlertid merke til at en del av datafeltene i utskriften av programmet mangler. 7

136 Testrapport Kommentar: Vi kommer til å bruke dette biblioteket. Vi må imidlertid modifisere programmet slik at den kan ta imot data fra server. Vi er også nødt til å modifisere programmet slik at den også kan dekode og skrive ut de datafeltene som mangler. Det følger ikke med noen opplagt dokumentasjon til programmet, så vi er derfor nødt til å finne ut av hvordan vi skal dekode dataene, og hvordan programmet virker på egen hånd. Test: innlegging av AIS-data på databasen Formålet med testen er å sjekke om noen av som sendes inn til meldingskøen kan få programmet til å krasje. Tabell Test på innlegging av AIS-data. Programversjon 0.5 Dato: 25/03/2013 Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Resultat: Kommentar: aisreceiver.py Mye av regex i Java er fjernet (etter oppdragsgivers ønske) og det er lagt til regex i aisreceiver.py isteden. Her skal det testes om regex kan feile og få programmet til å krasje for alle testdataene som sendes fra aisparser.java. Ved hjelp av regex, hentes informasjonen som sendes fra aisparser.java, og legges inn i database. Regex-koden er nødt til å sørge for å splitte dataene på riktig sted og sørge for at de blir lagt i en liste. Splittes dataene feil, kan det skje at dataene ikke blir lagt i listen. Dette vil igjen få programmet til å krasje når det prøver å aksessere dette elementet. Det taes utgangspunkt i at uønskede data er blitt sortert ut i aisparser.java Programmet krasjer ikke, men ingen posisjonsdata blir lagt inn i array. Årsaken til at ingen posisjonsdata blir lagt inn kan være at det er noe galt med regex eller med koden som legger dataene i MongoDB Ytelsestester: Test: AIS-parser datasortering Testnummer: 1 Formålet med testen er å teste ytelsen til den delen av AIS-parseren som sjekker og filtrerer bort data som Xeneta ikke ønsker. Dette gjelder typisk data fra for fiskebåter og passasjerbåter. 8

137 Testrapport Tabell Ytelsestest: AIS-parser datasortering. Testnummer: 1. Programversjon 0.2 Dato: 12/03/2013 Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Resultat: Kommentar: java ais-parser Lagt til et array der dataene legges inn i. Det er også lagt inn regex som henter ut dataene, dersom de er av riktig type. Istedenfor å skrive ut til skjerm, skriver programmet nå ut til fil. Rådata legges inn i et array etterhvert som de leses inn. Når arrayet er fullt, vil den sende innholdet sitt til en annen del av programmet som dekoder innholdet. Når dataene er dekodet, skrives de ut til fil gjennom handlemessagesreceived metoden. En del av testene koster en del datakraft. Særlig fordi den må gå igjennom alle data som allerede er prosessert for å matche positionreports med gyldige voyagedata (som er den eneste måten å identifisere om en positionreport tilhører et frakteskip eller ikke). Etter vi har fått programmet til å virke bør vi modifisere koden, slik at den heller gjør sorteringen i når dataene legges inn i databasene istedenfor å sortere hver gang. Det er muligens mulig å søke opp mmsi nummer for en positionreport via en hashtable i programmet. Test: modifikasjon av java Ais-parser med inkludert støtte for multithreading(thread pool) Formålet med testen er å se om det lønner seg å parallellisere AIS-parseren for å øke prosesseringshastigheten på AIS-data-dekoderen, og om det fører til at mer data blir lagret. Tabell Ytelsestest: Modifikasjon av AIS-parser med støtte for multi-threading. Programversjon 0.7 Dato: 03/04/2013 Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Threadedaisparser.java(med resten av bibliotek), aisreceiver.py Lagt til cached threadpool via executors-klassen(java bibliotek) i forsøk på å parallellisere dekodingsprosessen av AIS-data. Hver gang arrayet av rådata fylles opp, opprettes/benyttes en ny tråd som skal kjøre koden som dekoder data. Når dataene er dekodet skrives de ut til socket. 9

138 Testrapport Resultat: Kommentar: Koden ser tilsynelatende ut til å virke og hastighet på dataprosesseringen har økt noe. Det virker imidlertidig som at noen av dataene som blir lagt inn i mongodb er duplikater. Oppdragsgiver sa at det ikke var nødvendig med parallellisering av programmet (de tenkte muligens å gjøre det over nettet via meldingskø) så vi prioriterte derfor ikke å gå videre med testingen av denne delen av programmet. Det er derfor mulig at det er en del ting som må fikses/utbedres i Threadedaisparser Konsistenstester: Test:Sende data fra en en enhetstest kalt aissender.java til en server som oprettes når aisparser.java starter. Tabell Konsistenstest: Sende data fra en en enhetstest kalt aissender.java til en server som oprettes når aisparser.java starter. Programversjon 0.3 Dato: 16/03/2013 Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Resultat: Kommentar: aisparser.java og aissender.java Oprettet klient i aissender.java som leser inn rådata fra filen mnea.dump og sender disse via nettverk til aisparser.java. Dataene sendes via UDP-protokoll slik det er spesifisert av oppdragsgiver Først startes aisparser.java, deretter startes aissender.java. Hver linje som leses inn i aissender.java blir sendt til aisparser.java via nettverk. Deretter blir dataene dekodet, filtrert og gruppert og skrives tilbake til en ny fil. Testen er vellykket i forhold til pålitelighet og ytelse, men en veldig stor del av dataene kommer ikke fram. Grunnen til dette er fordi at dataene sendes gjennom en UDP-socket. Dermed så vil data som sendes mens programmet ikke lytter på socketen forsvinne. Parallellisering av socketlytting og dekoding kan gjøre at nesten alle dataene mottas. Dette forutsetter allikevel at dataene kan dekodes i samme fart som de kommer inn for å unngå at de hoper seg opp. Dermed kan Xeneta bruke egenskapene til UDP-socketen som en begrensning på hvor mange data som de tar inn samtidig. Test: gruppering av data som sendes fra udp-serveren til MQ (meldingskøen) Formålet med testen er å se om dataene som dekodes sorteres og grupperes riktig. Det skal også sjekkes at irrelevant data filtreres ut i AIS-parser. 10

139 Testrapport Tabell Konsistenstest: Gruppering av data som sendes fra udp-serveren til MQ. Programversjon 0.4 Dato: 20/03/2013 Testområde i kode/filer som gjelder: Forberedelser: aisparser.java, aisreceiver.py Lagt inn en modul i Python som tar imot data fra aisparser.java via TCP-tilkobling og skriver ut dataene til fil. Prosedyre: Resultat: Kommentar: Oppretter en server i aisreceiver.py og sender så ferdig data hit. Dataene skrives så til fil fra aisreceiver.py. Fordi det åpenbart blir en del ekstra forsinkelse, så er blir det noe mindre data som faktisk blir sendt over denne tilkoblingen og skrevet ut, i forhold til det som blir skrevet ut i versjon 0.3. Denne løsningen ser ut til å virke. Det gjenstår fremdeles å implementere slike at data skrives ut til MongoDb og ikke til fil. Test: innlegging av AIS-data på databasen Test 1: Formålet med testen er å sjekke om dataene legges inn riktig inn i MongoDB sortert på skipenes mmsi-nummer og destinasjon. Målet er å få lagt inn posisionreports inn i et array for hvert skip Tabell Test for innlegging av AIS-data i databasen. Testnummer 1 Programversjon 0.6 Dato: 28/03/2013 Testområde i kode/filer som gjelder: Forberedelser: aisreceiver.py Lagt inn og renskrevet kode for å legge inn data i MongoDB. Gjort om og fikset bugs i regex slik at datafeltene nå legges inn riktig 11

140 Testrapport Prosedyre: Resultat: Kommentar: Data mottas fra aisparser.java. Avhengig om data er en positionreport eller voyagedata vil det bli lagt inn i databasen. Positionreport blir lagt inn kun dersom det ligger en voyagedata der med samme mmsi-nummer. Voyagedataene blir lagt inn riktig, men det legges fremdeles ikke inn noen positionreports i array. Feilen må skyldes at pymongo-koden ikke er riktig. Test 2: Formålet med testen er å sjekke om dataene legges inn riktig inn i MongoDB sortert på skipenes mmsi-nummer og destinasjon. Tabell Test for innlegging av AIS-data i databasen. Testnummer 2. Programversjon 0.8 Dato: 07/04/2013 Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Resultat: Kommentar: aisreceiver.py Det er gjort flere endringer i pymongo-koden som legger dataene inn i databasen. Det viste seg tidligere at koden som hadde vært fra tidligere bare skrev over det som allerede var der istedenfor å legge til nye data. Se testnummer 1 rett over Programmet legger nå inn posisjonsdata riktig inn i et array. Nå er det mulig å hente ut den siste entrien i arrayet for å for eksemepel finne siste posisjon. Vi må fremdeles finne ut hvordan vi skal finne ut tidspunktet for når et skip er i havn og koble dette med posisjonsdataene. Test 3 Formålet med testen er å sjekke om dataene legges inn riktig inn i MongoDB sortert på skipenes mmsi-nummer. Det skal også testes at de riktige dataene legges inn i staticship collectionen, og at innleggingene i collectionen som inneholder informasjon om lane har et tidsstempel. 12

141 Testrapport Tabell Test for innlegging av AIS-data i databasen. Testnummer 3. Programversjon 0.9/1.0 Dato: 17/04/2013 Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Resultat: Kommentar: aisreceiver.py La til tidstempel for Når dataene legges inn i MongoDB, slik at det er mulig å avgjøre omtrent når skipet har ankommet havn. Det er også delt inn slik at mye av informasjonen i voyagedata havner i en egen collection kalt ship.static. Starter først opp aisreceiver.py, deretter startes aisparser.java og til slutt aissender.java. Aissender.java leser data fra fil og sender via UDP-tilkobling dette til aisparser.java for dekoding. Etter dataene har blitt dekodet og filtrert sendes de via en TCP-tilkobling til aisreceiver.py som igjen sørger for å legge dataene inn i MongoDB. Forsøket var en suksess. Dataene blir nå lagt inn i MongoDB på en fornuftig og konsistent måte. Det gjenstår nå å få integrert denne delen av programmet inn i hoveddelen. Dersom det ikke gjøres noen endringer etter det, kan denne versjonen betraktes som versjon

142 Testrapport 3 Schedule-parseren Under implementasjonen av schedule-parseren (klassen ScheduleImporter) ble det gjennomført flere tester. Etterhvert som det ble klarere på hvordan programmet skulle se ut ble det laget enhetstester. Enhetstestene ble dermed brukt til å utføre resten av testene og de er beskrevet i avsnittene nedenfor. For å være sikker på at schedule-parseren genererer det resultatet vi forventer oss, måtte det lages tester med testdata som ligner så mye som mulig på ekte reiseplaner fra ShipmentLink. Det ble derfor fra en av schedule-filene fra ShipmentLInk klippet ut noen få reiseplaner. Formatet til filene ble bevart. Det forventede resultatet ble lagt i en egen fil. Enhetstestmodulen for ScheduleImporter sammenligner det forventede resultatet med resultatet som programmet kommer med. Hvis de ikke er like, kastes det en assertexception og enhetstesten feiler. 3.1 Testplattform De fleste at testene ble utført på PC-en til en av gruppedeltagerne. Etter at det ble gjort en del endringer på enhetstesten og programkoden som skal testes, ble det også testet på testserveren. Spesifikasjonene til PC-en til deltageren som utførte enhetstestene er: Prosessor: Intel i5 3570K 3.4 GHz Minne (RAM): 8 GB Operativsystem: Windows 7 Professional Spesifikasjonene til testserveren står i kapittel Formålet med testing For å være sikker på at schedule-parseren genererer det resultatet vi forventer oss, ble det laget enhetstester som tester all funksjonalitet i programmet. Alle funksjonene i samme modul, selv static-funksjonene er relatert til parsing av schedule-filer fra ShipmentLink. 14

143 Testrapport 3.3 Utførte tester Det ble utført tester hele tiden under implementasjonen, men de fleste av disse var små tester som testet enkelte deler av programkoden. De testene som er beskrevet under, er de fullverdige enhetstestene som ble gjort etter at det ble gjort store endringer i schedule-parseren. Det er altså bare tester som ble gjort etter at enhetstesten var nesten ferdig utviklet som står beskrevet under. Test 1: Dette var den første enhetstesten som ble utført og den skulle teste om alle reiseplanene ble lagret riktig i databasen. Tabell Test for ScheduleImporter-klassen. Testnummer 1. Programversjon 0.5 Dato: Testområde i kode/filer som gjelder: Forberedelser: Selve parsingdelen av i schedule_importer.py En forminsket versjon av en schedule-fil ble laget. Denne filen skal brukes i enhetstesten. Forventet resultatet ble også lagt i en annen tekstfil. Det gjort en del endringer på ScheduleImporter som hindrer at det skjer til logging til Sentry-serveren under testing. Det ble laget en debuggingvariabel i ScheduleImporter som skal brukes til å avgjøre om det skal logges. Prosedyre: Resultat: Kommentar: Enhetstestkomponenten i IDE-en vi brukte, Eclipse, ble brukt. Enhetstesten feilet på den delen av koden som har med parsing av schedule-filer å gjøre. ETA-datoen ble ikke lagret i reiseplandokumentene i databasen og ETD-datoen var feil på alle dokumentene. Dette medførte til at resultatet ikke stemte overens med det forventede resultatet. ETA-datoen ble ikke lagt til i reiseplanene før de ble lagret i databasen. La til instruksjonen som setter inn datoen før reiseplanene lagres i databasen. Test 2: Dette var den andre enhetstesten som ble utført og den skulle teste programmet for å se om problemene som ble oppdaget under Test 1 var løst. 15

144 Testrapport Tabell Test for ScheduleImporter-klassen. Testnummer 2. Programversjon 0.6 Dato: Testområde i kode/filer som gjelder: Forberedelser: Selve parsingdelen av i schedule_importer.py Gjorde det som sto i kommentarer på Test #1. ETA-datoen blir nå satt inn riktig i databasen. Prosedyre: Samme prosedyre som i Test 1. Resultat: Kommentar: Ingen feil ble oppdaget. Enhetstesten var vellykket. Det ble ikke funnet noen feil i programkoden. Det gjenstår nå å utvide enhetstesten til å teste feil i datoer. Test 3: Schedule-parseren lagrer nå havnekoder istedenfor navnet på havner i reiseplandokumentene. Enhetstesten ble oppdatert til å teste dette og i tillegg teste om ulovlige datoformater fører til at det kastes riktig exception (unntak). Tabell Test for ScheduleImporter-klassen. Testnummer 3. Programversjon 1.0 Dato: Testområde i kode/filer som gjelder: Forberedelser: Alle funksjoner i schedule_importer.py. La til en metode som henter havnekoden til en havn. Oppdaterte testdataene til å inneholde havnekoder istedenfor. Prosedyre: Samme prosedyre som i Test 1 og Test 2. Resultat: Kommentar: Ingen feil ble oppdaget. Enhetstesten var vellykket. Programmet funger uten problemer. Vi kan si at vi er ferdig med schedule-parseren. 16

145 Testrapport 4 Rederistatistikkoppdatereren Også under implementasjonen av rederistatistikkoppdatereren (klassen DepartureArrivalUpdater) ble det gjennomført flere tester, men enhetstestene og testdata for den ble laget mye tidligere enn enhetstesten for ScheduleImporter. En stor fil med testdata ble laget. Det forventede resultatet ble lagt i en egen fil. Enhetstesten sammenligner det forventede resultatet med resultatet av programmets kjøring. Hvis de ikke er like, kastes det en assert-exception og enhetstesten feiler. 4.1 Testplattform De fleste at testene ble utført på PC-en til en av gruppedeltagerne. Når det ble gjort en del endringer på enhetstesten og programkoden som skal testes, ble det også testet på testserveren. Spesifikasjonene til PC-en til deltageren står i avsnitt Formålet med testing For å være sikker på DepartureArrivalUpdater oppdaterer dokumentene riktig i databasen, måtte det lages en enhetstest som tester alle deler av programmet. 4.3 Utførte tester Akkurat som med klassen ScheduleImporter, ble det utført tester hele tiden under implementasjonen av DepartureArrivalUpdater-klassen og de fleste av disse var små tester som testet enkelte deler av programkoden. Testene som er beskrevet under er de fullverdige enhetstestene som ble gjort etter at det ble gjort store endringer i DepartureArrivalUpdater-klassen eller testdata-filene. Det er altså bare tester som ble gjort etter at enhetstesten nesten var ferdig utviklet som står beskrevet under. Test 1: Dette var en av de første enhetstestene som ble utført på dette programmet. Den skal teste om alle reiseplaner, dokumenter for skip som reiser nå og transitthistorikker blir lagret riktig. 17

146 Testrapport Tabell Test for DepartureArrivalUpdater-klassen. Testnummer 1. Programversjon 0.7 Dato: Testområde i kode/filer som gjelder: Forberedelser: Prosedyre: Resultat: Kommentar: Den delen av koden i DepartureArrivalUpdater-klassen som oppdaterer reiseplanene i collection-en schedules.current, dokumenter for nåværende reiser i collection-en voyages.traveling og dokumenter for fullførte transitter i collection-en voyages.arrivals. Den delen av koden som hadde med oppdatering av rederistatistikk å gjøre ble kommentert fordi den ikke var klar ennå. Filene som inneholder testdata ble laget ferdig. Enhetstestkomponenten i IDE-en vi brukte, Eclipse, ble brukt. Ingen feil ble oppdaget. Enhetstesten var vellykket. Programmet fungerte fint, men det manglet et par felter i testdataene som skulle lagres i databasen. Disse er rederiets navn og ID. Test 2: Samme formål som Test #1, men nå sjekkes det også om rederipunktlighetsstatistikker blir oppdatert riktig i collection-en shipowners. Tabell Test for DepartureArrivalUpdater-klassen. Testnummer 2. Programversjon 0.9 Dato: Testområde i kode/filer som gjelder: Forberedelser: All kode i klassen DepartureArrivalUpdater i modulen lanes.py blir testet. Testdata for rederier og statistikker for de ble laget. Prosedyre: Samme prosedyre som i Test 1. Resultat: Kommentar: Ingen feil ble oppdaget. Enhetstesten var vellykket. Programmet fungerte fint, men det bør kanskje legge til mer testdata for å være sikker på at programmet fungerer som den skal. 18

147 MARE NOSTRUM Del 6 Vedlegg 1 - Ordliste