MARE NOSTRUM. Del 1 Prosessrapport

MARE NOSTRUM Del 1

Forord Rapporten er en prosessdokumentasjon for hovedprosjektet utført av gruppe 17. Vi kom i kontakt med oppdragsgiveren gjennom høgskolen høsten 2012. 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

Innholdsfortegnelse 1 Innledning... 6 1.1 Gruppen... 6 1.2 Om bedriften... 6 1.3 Bakgrunn for oppgaven... 6 1.4 Prosjektmål... 7 1.5 Rammebetingelser... 7 2 Beskrivelse av programmet... 8 2.1 Generell beskrivelse... 8 2.2 Om utvikling av et program for skipingsmarkedet... 8 3 Planlegging og metode... 9 3.1 Planleggingen og prosessen... 9 3.1.1 Hvordan vi planla... 9 3.1.2 Utviklingsmetodikk... 10 3.2 Verktøy... 13 3.2.1 Versjonskontroll... 13 3.2.2 Dokumentasjon... 14 3.2.3 Utvikling... 16 3.2.4 Rammeverk... 16 3.2.5 Logging med Sentry... 16 3.2.6 Symphonical som Arbeidsplanleggingsverktøy... 17 3.3 Teknologi... 18 3.3.1 Nødvendig innstudering av ny materiale... 18 3.3.2 Forhåndskunnskaper... 22 3.4 Arbeidsforhold... 23 3.4.1 Arbeidsforhold mellom gruppemedlemene... 23 3.4.2 Arbeidsforhold mellom gruppen og oppdragsgiveren... 24 3.4.3 Selvstendighet... 24 3.4.4 Arbeidsprosedyrer... 25 3.4.5 Arbeidstider... 25 3.4.6 Arbeidsfordeling... 25 3.4.7 Ansvar... 26 3

4 Utviklingsprosessen... 27 4.1 Utviklingsfasene for prosjektet... 27 4.1.1 Forstudiet... 27 4.1.2 Spesifikasjon... 27 4.1.3 Implementering... 27 4.1.4 Testing... 28 4.1.5 Dokumentasjon... 28 4.2 Utfordringer... 28 4.2.1 Tverrfaglige utfordringer... 28 4.2.2 Utfordringer med parsing av schedule-filer... 29 4.2.3 Problemer med AIS-parseren... 30 4.2.4 Mangelfulle data... 31 4.2.5 Håndtering av store mengder nytt stoff... 31 4.2.6 Nettverksprogrammering... 32 4.2.7 Effektivitet... 33 4.2.8 Å tilpasse oss et eksisterende datasystem som stadig er under endringer... 33 4.3 Viktige valg om oppbygning og funksjon i programmet... 33 4.3.1 AIS-parser... 33 4.3.2 AIS-receiver... 34 4.3.3 Schedule-parser (ScheduleImporter)... 34 4.3.4 Redereristatistikkoppdaterer (DepartureArrivalUpdater)... 34 4.3.5 Web-applikasjonen... 35 4.4 Utvikling av forholdet til oppdragsgiveren under prosessen... 35 5 5 Kravspesifikasjonen og dens rolle... 36 5.1 Kravspesifikasjonen versjon 1... 36 5.2 Tilpasninger av kravspesifikasjonen... 36 5.2.1 Invalidering av krav... 37 5.3 Gruppens forhold til kravspesifikasjonen... 38 6 Om resultatet... 39 7 Avslutning... 40 7.1 Gruppens utbytte... 40 7.2 Produktets fremtid... 40 7.2.1 Bruksområder... 40 4

7.2.2 Utvidelsesmulighet... 41 7.3 Konklusjon... 41 8 Referanser... 42 5

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

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

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

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 3.1.1 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 3.1 - Fremdriftsplanen for prosjektet. 9

3.1.2 Utviklingsmetodikk 3.1.2.1 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

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

Sprint planleggingsmøte: Et møte hvor arbeidet som skal utføres i en Sprint er planlagt av hele scrum laget. Figur 3.2 - Scrum-prosessen 3.1.2.2 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

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. 3.2.6). 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. 3.2.1 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

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. 3.2.1.1 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. 3.2.1.2 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 3.2.2.2) 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å. 3.2.2 Dokumentasjon 3.2.2.1 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 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. 14

3.2.2.2 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 3.2.2.3 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 3.1.1. 3.2.2.4 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. 3.2.2.5 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 ingenting om oppbygningen av programmet. Sekvensdiagrammet inneholder en beskrivelse hvordan de forskjellige klassene i et program kommuniserer med hverandre, avgrenset av Use Case- 15

beskrivelsene. 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. 3.2.3 Utvikling 3.2.3.1 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. 3.2.3.2 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 6.3.3. 3.2.3.3 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. 3.2.4 Rammeverk Vi brukte flask som webapplikasjonsrammeverk. Flask er beskrevet i avsnittet 3.3.1.7. 3.2.5 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 email_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 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. 16

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 3.3 - 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. 3.2.6 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 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 17

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 3.4 - En snapshot av Scrum-tavlen den 8.4.2013. 3.3 Teknologi Denne delen inneholder en presentasjon av alle teknologier som er med i implementasjonen av prosjektet. 3.3.1 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. 3.3.1.1 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, imperativ programmering og funksjonell programmering. Dette gir fleksibilitet til og bruke de paradigmene som passer den bestemte oppgaven. 18

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. 3.3.1.2 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. 3.3.1.3 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. 3.3.1.4 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. 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. 19

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. 3.3.1.5 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 3.1 - 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 hele dokumenter på en gang. MongoDB har allikevel et godt system for å håndtere dette, så det har 20

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. 3.3.1.6 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. 3.3.1.7 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 2. 3.3.1.8 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

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 1. 3.3.2 Forhåndskunnskaper Denne delen av rapporten tar for seg implementasjonsspesifikke teknologier og designprinsipper som en eller flere av oss allerede kjenner til. 3.3.2.1 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. 3.3.2.2 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

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 3.5 - 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 3.4.1 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

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. 3.4.2 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. 3.4.3 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

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. 3.4.4 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. 3.4.5 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. 6-12 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. 3.4.6 Arbeidsfordeling Under prosjektet brukte vi som nevnt i kapittel 3.2.6 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

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. 3.4.7 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 3.1. 26

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 4.1.1 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 26.10.2012. Vi leverte prosjektskisse 7.12.2012 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. 4.1.2 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 4.1.3 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

4.1.4 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. 4.1.5 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). 4.2.1 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

det eventuelt var datafelt i AIS-dataene som blir oppdatert manuelt, siden disse datafeltene i så fall vil bli betraktet som upålitelige. 4.2.2 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 (www.shipmenlink.com). 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 0288-091E 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 0288-091E 02/26 02/27 02/28 03/01 03/02 03/04 EVER UNISON 0289-117E ---- ---- 03/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