Semesterprojekt - TaxaTracer. Statistik I Programudvikling

Transkript

1 Semesterprojekt - TaxaTracer Statistik I Programudvikling Udarbejdet af: Daryosh (Danni) Derakhshan [dader06] dader06@student.sdu.dk Anders Steffen Andersen [ander06] ander06@student.sdu.dk Kasper Rytter Sæderup [ksaed06] ksaed06@student.sdu.dk Jens Bjarke Pedersen [jped606] jped606@student.sdu.dk Simon Tobias Busch [sbusc06] sbusc06@student.sdu.dk Gruppe nr.: Gruppe 2 Undervisningsinstitution: Syddansk Universitet - Det tekniske fakultet Kursus: SIP4 Vejleder: Lone Borgersen Periode: Forår 2008 Afleveringsdato: Onsdag d

2 Synopsis Et taxaselskab ønsker at kunne få overblik over selskabets taxavogne, sende bestillinger til taxavognene samt lave statistisk analyse over kundernes adfærd. Problemdomænet er analyseret og der er designet systemet TaxaTracer med henblik på at opfylde taxaselskabets ønsker. Systemet vil fungere som et distribueret system, hvor der er klienter i taxavognene og på taxaselskabets kontorer, en applikationsserver samt en databaseserver. Der er i projektet truffet en lang række beslutninger vedrørende datakommunikation, softwarekonstruktion samt statistik, bl.a. hvilken transportprotokol samt bæreteknologi, der benyttes mellem klienter og servere. Gennem projektet er Unified process benyttet i forbindelse med softwareudviklingen og SCRUM er benyttet i forbindelse med projektadministration. Der er udarbejdet en kørende version af TaxaTracer, således begge klienter er konfigureret. Endeligt er TaxaTracer testet med success. Daryosh Derakhshan: Jens Bjarke Pedersen: Anders Steffen Andersen: Simon Tobias Busch: Kasper Rytter Sæderup: Side 2

3 Indhold 1 Prolog Forord Målgruppe Læsevejledning Projektværktøjer og projektstyring Projektværktøjer Projektstyring Indledning Problemstilling Problemformulering Kravspecifikation Projektafgrænsning Brugsmønsterbeskrivelser Mål og forventede resultater Analyse af de udvalgte brugsmønstre 18 5 Systemarkitektur Klient server struktur Pakkestruktur Kommunikation, positionering og database Tekniske memoer Delkonklusion af arkitektur Design af de udvalgte brugsmønstre TaxaTracers forretningsmodel Design af Se taxavogns aktuelle position og Ændre driftstatus Design af Bestilling af taxavogn Design af Analyser bestillinger Design af database Delkonklusion af designet Implementering af TaxaTracer Implementering af RMI Implementering af MySQL database Implementering af den statistiske model Implementering af Observer-pattern Side 3

4 8 Test af TaxaTracer Test metode og type Test af TaxaTracers funktionalitet Delkonklusion af test Epilog Konklusion Perspektivering Reflektionsdokument 63 A Analyse af de udvalgte brugsmønstre 65 A.1 Korte brugsmønstrebeskrivelser og krydstabel A.2 Krydstabel A.2.1 Krydstabel over funktionelle krav og brugsmønstre A.2.2 Krydstabel over ikke-funktionelle krav og brugsmønstre A.3 Analyse af Se taxavogns aktuelle position A.4 Analyse af Ændre driftstatus A.5 Analyse af Bestilling af taxavogn A.6 Analyse af Analyser bestillinger B Fordele og ulemper ved multi-tiered arkitektur 87 C Test af bestilling af taxavogn samt test af statistiske funktioner. 88 D MySQL-database script 90 E Forbindelse til GPS-antenne med Bluetooth 92 E.1 Kommunikationen mellem GPS og TaxaTracer Taxavognklient E.1.1 Java implementation af bluetooth E.2 Implementering af Bluetoothforbindelse F GPS 95 F.1 Baggrund F.2 Beregning af GPS position F.3 Tekniske specifikationer for GPS Holux G Faktortabeller for de ikke funktionelle krav 102 H Referat af formelt reviewmøde med Gruppe3 105 I Kildekode 107 I.1 TaxiTracer - Applikations-Server I.1.1 Connector-Pakken I.1.2 Entity-Pakken Side 4

5 I.1.3 Mediator-Pakken I.1.4 Foundation-Pakken I.2 TaxiTracer - Central-Klient I.2.1 Presentation-Pakken I.2.2 Control-Pakken I.2.3 Control.Connector I.3 TaxiTracer - Taxi-Klient I.3.1 Presentation-Pakken I.3.2 Control-Pakken I.3.3 Control.Connector-Pakken J Kontrolskema 159 Side 5

6 1 Prolog 1.1 Forord Denne rapport er skrevet som et led i civilingeniøruddannelsen indenfor datateknologi på 4. semester, på SDU. Projektforløbet har strukket sig over foråret 2008, og projektet er udvalgt udfra tre projektoplæg stillet af projektgruppens medlemmer. Rapporten vil præsentere resultatet af den udførte analyse af problemstillingen, designet af løsningen samt dokumentation på hvordan det ønskede software er opbygget og implementeret. Til den trykte rapport er vedlagt en CD-ROM med alt det materiale gruppen har udarbejdet, under projektforløbet. Dette inkluderer det udarbejdede program, en digital version af rapporten, tidsplan mm. Herudover ønskes det at takke Lone Borgersen for projektvejledning i løbet af semesteret. 1.2 Målgruppe Rapporten er skrevet til en læser, som minimum er på samme faglige niveau som projektgruppen, dvs. at læseren skal have kendskab til programmeringssproget Java og UML. For at få maksimalt udbytte af rapporten, er det nødvendigt for læseren at være på samme niveau som gruppen, da mere erfarne læsere vil opfatte visse beslutninger som en selvfølge for bestemte problemstillinger. 1.3 Læsevejledning Kapitler opgives på formen 1, 2,... og underafsnit på formen 1.1 og Tabel- og figurtekst er placeret under elementet, og er nummereret på formen x.y, hvor x er kapitelnummer, og y er løbende nummerering. Kildehenvisninger er på formen: [x] - Side y, hvor [x] henviser til kilde nr. x på kildelisten. Side y, er siden i kilden der henvises til. Formler i rapporten er nummereret på formen (x.y), hvor x er kapitelnummer og y er løbende nummerering. Når der refereres til brugsmønstre, skrives brugsmønstrenes navne i kursiv med stort forbogstav, fx Se taxavogns aktuelle position. Når der refereres til klasser, skrives klassens navn med kursiv med stort forbogstav og uden mellemrum, fx Taxi. Når der refereres til objekter, skrives objektets navn med kursiv og lille forbogstav, fx taxi- Driver. Side 6

7 Når der refereres til linjer i kodeeksempler med én linje, er det kun den ene linje der refereres til fx Linje 9. Skrives der kodelinier med paranteser om referes der til intervallet, linjerne inklusiv fx Linje (5-8). Kapitel 4 indeholder et resumé af det oprindelige analysekapitel, hvilket ligger i bilag pga. begrænsninger af sideantal, dog er det muligt at forstå efterfølgende kapitler, ved at læse resuméet i kapitel 4. Hvis der ønskes en mere detaljeret beskrivelse af analysen, henvises til bilag A. Der vil i forbindelse med tabeller benyttes følgende forkortelser: TT: TaxaTracer systemet som helhed. TTT: Taxaklient i taxavognen. TTC: Centalklienten ved centralen. TTS: Applikationsserveren. I kapitel 6 vil der i forbindelse med sekvensdiagrammer optræde et ufuldstændigt kald efterfulgt af en sort prik, betydende at sekvensdiagrammet fortsættes. Ligeledes indledes det fortsættende sekvensdiagram med samme sorte prik. Når et logo, referende til taxaklienten, centralklienten, applikationsserveren og databasen, er placeret ved et diagram eller en figur, refererer logoet til den fysiske placering. Figur 1.1 viser de anvendte logo er. Figur 1.1: Logo er der er anvendt i rapporten Side 7

8 2 Projektværktøjer og projektstyring Formålet med dette kapitel er at beskrive hvilke projektværktøjer, der er benyttet til at gennemføre projektet. Der vil heriblandt blive beskrevet hvilket udviklingsmiljø, konfigurationsstyringsværktøj samt database der er blevet anvendt. Kapitlet vil også præsentere generelle projektstyringsværktøjer, der er blevet benyttet til at optimere projektprocessen. 2.1 Projektværktøjer Projektrapporten skrives i L A TEX, da dette kan benyttes sammen med SubVersion (SVN) til versionstyring, som også bliver anvendt i forbindelse med softwarekonstruktionen. SVN er et godt værktøj når der er flere deltagere i samme projekt, da det effektiviserer arbejdsprocessen ved at muliggøre at flere deltagere kan arbejde på samme afsnit i rapporten. Til softwarekonstruktion benyttes udviklingsmiljøet Eclipse, og tilhørende plugins i forbindelse med UML diagrammer. De fleste figurer i rapporten er udarbejdet i tegneprogrammet Omnigraffle. Til lagring af oplysninger i systemet, benyttes databasen MySQL. Andre MySQL-programmer som MySQL querybrowser og MySQL administrator er blevet benyttet til hhv. test af systemet og administration af databasen. For at sikre kvaliteten af rapporten, er et udvalgt kapitel sendt til review hos en anden projektgruppe. Referatet af reviewmødet kan læses i bilag H. 2.2 Projektstyring Det er valgt at benytte Unified Process (UP) som processmodel til dette projekt samt at benytte SCRUM til projektadministration. Disse to projektværktøjer udgør tilsammen projektstyringen for dette projekt. Figur 2.1 viser en UP-model 1, som illustrerer arbejdsmængden faseafhængigt af den enkelte aktivitet. Figur illustrerer processen for et sprint i SCRUM, som oftest varer 30 dage, med scrummøder hver dag, som illustreret ved pilene. Ønskes yderligere information omkring SCRUM 3, se henvisning. Figur 2.1: UP model Figur 2.2: SCRUM model 1 [6] - Side 38 - Figur archive/scrum1.gif 3 [4] - Kap 1 og 3 Side 8

9 Som fremhævet med rødt på figur 2.1, udarbejdes projektet under elaborationsfasen, hvilket medfører at visse aktiviteter skal udføres. Rapporten vil blive opbygget omkring disse UP-aktiviteter, dog vil kun afsnit om krav, være opbygget omkring brugsmønstrene, da det i denne del af rapporten er vigtigt at se de individuelle brugsmønstre hver for sig. I kapitel 6 - om design, vil kapitlet være en dokumentation af generelle designbeslutninger, hvor flere af brugsmønstrene er omtalt som én helhed. I kapitel 8 - om test, vil testene afspejle visse nøglefunktionaliteter ved systemet. Side 9

10 3 Indledning I et taxaselskab er det ønskeligt at optimere arbejdsgangen, herunder placering af taxavognene i vigtige kunde knudepunkter og uddelegering af bestillinger til de taxavogne der befinder sig nærmest opsamlingstedet. En vognmand vil desuden kunne optimere arbejdsgangen, ved konstant at vide hvor de forskellige taxavogne befinder sig og om de har kunder, er klar til kunder eller holder pause. En taxavogns placering og driftstatus kunne blive oplyst på et grafisk kort, der hermed giver vognmanden overblik over alle taxavognene. En yderligere optimering af taxaselskabets arbejdsgang, kunne udføres ved statistisk analyse af fx bestillinger, kørte km for taxavognene og indtjening, derigennem kan taxavognenes spildtid minimeres. Ved at mange funktioner bliver automatiseret bliver arbejdsgangen optimeret for taxaselskabet og dermed vil de yde en bedre service og forøge indtjeningen. I kraft af at systemet overvåger medarbejderne er der etiske overvejelser om dette rent faktisk er lovligt. Lovgivningen er på dette område uklar, men med medarbejdernes skriftlige accept af overvågningen, er dette ikke et juridisk problem Problemstilling Det implementerede softwaresystem skal lette taxaselskabets arbejde med statistisk analyse, administration af taxavognene og samtidig give overblik over hvor taxavognene befinder sig. Dette gøres ved at konstruere et system, der holder styr på taxavognene og kundetransporter. Det ønskes fra dette system at kunne udsende bestillinger direkte til taxavognene fra centralen. Desuden ønskes en systemdel, der har til ansvar at analysere og udarbejde statistik over kunders typiske adfærdsmønstre, taxavognenes indtægter og kørsel i løbet af dagen. 3.2 Problemformulering Der ønskes udviklet et system, kaldet TaxaTracer (TT), der gør det muligt for centralen at danne et visuelt overblik, over hvor taxavognene befinder sig geografisk, samt deres driftstatus. Herudover skal det være muligt for centralen at oprette en bestilling, som enten sendes til samtlige ledige taxavogne, eller til den ledige taxavogn der er nærmest opsamlingsstedet. Det skal derfor være muligt for taxavognschaufførerne at acceptere en bestemt bestilling. TT skal lette administrations- og analysearbejdet. Systemet skal udarbejde statistik over bl.a. forskellige bestillinger med tilhørende geografisk position, dato og tid, distancen en taxavogn har kørt under kundetransport og indkomst pr. tur. Disse informationer skal gemmes, således systemet kan beregne typiske adfærdsmønstre og dermed forudsige, med en hvis sandsynlighed, hvornår der kommer bestillinger fra hvilke bydele. Således er det muligt at disponere taxavognene på den bedst strategiske måde, resulterende i minimal spildtid for både kunder og taxaselskab og dermed optimere indtjeningen. 1 Side 10

11 3.3 Kravspecifikation I det følgende afsnit opstilles en række krav der har til formål at belyse TaxaTracer s funktionalitet, og dermed hvad systemet skal kunne udføre. De funktionelle krav vil blive kategoriseret efter deres funktionsområde. Der vil blive opstillet en række ikke-funktionelle krav, der vil omhandle kvalitetskrav for TaxaTracer. Disse krav vil ligeledes blive kategoriseret indenfor deres funktionsområder. Funktionelle krav: De funktionelle krav (F) vil blive kategoriseret indenfor følgende kategorier: FG: FS: FB: FAD: FAN: Krav for det grafiske miljø i TT. Krav der omhandler taxavognenes driftstatus i TT. Krav der omhandler bestillinger i TT. Krav der omhandler det administrative i TT. Krav der omhandler statistisk analyse i TT. ID Detaljer ID Detaljer FG 01 TT skal kunne oplyse den enkelte taxavogns position og taxavogns id. FG 02 TT skal kunne oplyse en taxavogns driftstatus. FG 03 Det skal være muligt for TTC at se alle bestillinger der endnu ikke er accepterede. FG 04 TT skal vise resultaterne af de statistiske beregninger grafisk. FB 01 TT skal kunne bestille en taxavogn. FB 02 TT skal give hver bestilling af en taxavogn, et bestillingsnummer. FB 03 TTC skal kunne informere TTT om opsamlingssted og destination. FB 04 TTC skal kunne sende en bestilling ud til alle TTT er. FB 05 TT skal kunne sende en bestilling ud til den nærmeste TTT. FB 06 TT skal lade TTT kunne acceptere en bestilling. FB 07 TT skal lade TTT kunne annullere en accepteret bestilling. FAD 01 TTC skal kunne administrere taxavognene. FAD 02 TT skal give hver taxavogn et unikt identifikationsnummer. FAD 03 TT skal give hver taxavognchauffør et unikt identifikationsnummer. FAD 04 TT skal kunne oplyse informationer om taxavognens tekniske specifikation, FAD 05 TT skal gøre det muligt at administrere taxavognschauffører. ekstra udstyr og farve/reklame. FAD 06 TT skal kunne oplyse chaufføren af en bestemt taxavogn. FAD 07 TT skal kunne oplyse informationer om en bestemt taxavognschauffør. FAN 01 TT skal kunne analysere tid fra ordren er modtaget til kunden er samlet op (spildtid). FAN 02 TT skal kunne analysere indkomster fra ture. Side 11

12 FAN 03 FAN 05 FAN 07 FS 01 TT skal kunne analysere udgifter. TT skal kunne give en statistisk analyse for antallet af bestillinger over en forudbestemt periode. TT skal kunne udskrive resultaterne af den statistiske analyse til en fil. TTT skal kunne skifte og sende driftstatus til TTC. FAN 04 FAN 06 FAN 08 TT skal kunne analysere bestillinger med henblik på tidspunkter og lokationer. TT skal kunne give en statistisk a- nalyse for antallet af bestillinger for et givent område. TT skal kunne analysere chaufførenes pausemønstre. Ikke-funktionelle krav: De ikke-funktionelle krav (K) vil blive kategoriseret indenfor følgende kategorier: KA: KG: KY: KN: KS: Krav der omhandler arkitektur og videreudvikling. Krav der omhandler grafisk brugergrænseflade. Krav der omhandler TT s ydeevne. Krav der omhandler nøjagtighed. Krav der omhandler lagring og sikkerhed af data. Her listes de ikke-funktionelle krav. ID Detaljer ID Detaljer KA 01 TT s softwarearkitektur skal udvikles på en sådan måde at det simpelt KG 01 TT skal være omfattet af en grafisk brugergrænseflade. kan videreudvilkes og / eller opgraders. KG 02 TT skal have et grafisk kort, der viser informationer om taxavognene. KY 01 Der skal ikke være tab af data under data transport. KY 02 TT skal være operationsdygtigt 24 timer i døgnet, 7 dage om ugen. KY 03 TT skal hente taxavognenes position maksimum hvert 5. sekundt. KN 01 TT skal kunne vise taxavognens position, på et grafisk kort, med en nøjagtighed KN 02 GPS-antennen skal have en nøjagtighed på ± 15 meter. på ± 20 meter. KS 01 TT skal gemme registrerede data i en database i en periode på min. 3 KS 02 TT skal tage dagligt backup af databasen. mdr. KS 03 TT skal have mulighed for opdatering og tilføjelse af kort. KS 04 TTS skal registrere og gemme taxavognens position og tilhørende tid. Side 12

13 KS TTS skal registrere og gemme taxa- KS TTS skal registrere og gemme taxa- 05 vognens driftstatus og tilhørende 06 vognens hastighed og tilhørende tid. tid. KS TTS skal registrere og gemme taxa- 07 vognens chauffør og tilhørende tid. 3.4 Projektafgrænsning For at afgrænse systemets funktionalitet, er det nødvendigt at prioritere de brugsmønstre, der er dannet ud fra kravene i afsnit 3.3. For at se korte brugsmønsterbeskrivelser for samtlige, henvises til bilag A.1. Hermed dannes et overblik over hvilke funktionaliteter der er nøglefunktioner og hvilke risici der er forbundet med de enkelte funktioner. Dette er gjort med henblik på at behandle de dele af systemet, som bedst dækker den grundlæggende funktion af systemet, samt de fagligheder der skal arbejdes med i forbindelse med semesteret. I figur 3.1, er gruppens prioritering præsenteret. Gruppen har valgt at benytte en modificeret version af RUP attributter, for at analysere på brugsmønstrene før de prioriteres. De attributter der er valgt at fokusere på er: Benefit - beskriver hvor vigtig funktionen er, fra kundens synspunkt. Den kan have tre værdier, critical, important og useful. Critical vælges når funktionaliteten er yderst vigtig for systemet, og kunderne ikke vil acceptere hvis funktionen udebliver. Important vælges når funktionaliteten er vigtig, men ikke altafgørende for kunders accept, og formindsker dermed kunders tilfredshed, hvis funktionaliteten udebliver. Useful vælges når funktionaliteten er brugbar, men ikke gør nogen forskel for kundernes overordnede billede af systemets funktionalitet. Effort - et estimat der beskriver hvor mange ressourcer der skal bruges for at virkeliggøre funktionen. I denne sammenhæng fokuseres der på arbejdsdage. Denne kan have værdierne high, medium og low. Risk - beskriver risikoen ved at implementere funktionen. Risikoen kan afhænge af erfaring indenfor implementeringen, samt manglende teknologi til realisering af funktionaliteten. Der findes ofte en sammenhæng mellem effort og risk. Risk kan have værdierne high, medium og low. Stability - et estimat over hvor meget funktionen vil ændre sig i løbet af processen. Denne kan også have værdierne high, medium og low. Ved at betragte og vurdere ovenstående parametre for hvert brugsmønster, er det muligt at prioritere brugsmønstrene. Prioriteringen vægtes med tal fra 1-5, hvor 5 vægtes højst. Resultatet kan ses i følgende figur. Side 13

14 Figur 3.1 viser samtidig den afgrænsning gruppen har foretaget, og denne afgrænsning er fore- Figur 3.1: Risikoanalyse og priotering taget med attributterne skal, bør og kan. I denne afgrænsningsproces har der været fokus på, at inddrage brugsmønstre med faglig relevans til de tre fagligheder der skal indgå i projektet, samt at skabe et sammenhængende system. Afsnit 3.5 vil give en beskrivelse af de udvalgte brugsmønstre og deres respektive aktører. 3.5 Brugsmønsterbeskrivelser For at danne overblik over systemets aktører er der udarbejdet en aktørliste, se tabel 3.1, med tilhørende beskrivelser. Navn Centralbruger Taxachauffør Taxaklient Beskrivelse Det er centralbrugerens opgave, at overvåge alle taxavogne, administrere disse og sende bestillinger. Samtidig skal centralbrugeren have mulighed for at udføre statistisk analyse på gemte data. Det er taxachaufførens opgave at ændre driftstatussen for taxavognen og håndtere bestillinger sendt fra centralen. Når taxavognen bevæger sig, skal klienten i taxavognen sørge for at indrapportere den nye position. Tabel 3.1: Aktørliste for TaxaTracer Figur 3.2 giver et overblik over TaxaTracers aktører samt deres respektive brugsmønstre. Ud fra de opstillede krav er der udarbejdet en række brugsmønsterbeskrivelser. Det er en række korte beskrivelser med titel, ID, aktør, formål og kort oversigt over brugsmønsterets funktion. Visse brugsmønstre ligger indenfor samme område og har derfor ID x.x, såsom 1.1 og 1.3. Side 14

15 Figur 3.2: Brugsmønstermodel for TaxaTracer Brugsmønster: Ændre driftstatus. ID 1.1 Aktør: Taxachauffør Formål: At centralen har mulighed for at overvåge taxavognenes driftstatus. Kort oversigt: Taxachaufføren skal kunne ændre taxavognens driftstatus som centralen får oplyst. Tabel 3.2: Kort brugsmønsterbeskrivelse for Ændre driftstatus. Brugsmønster: Se taxavogns aktuelle position. ID 1.3 Aktør: Taxaklient Formål: At centralen har mulighed for at overvåge taxavognenes position. Kort oversigt: For at kunne skabe overblik over taxavognenes lokationer, skal centralenbrugeren få dette oplyst. Tabel 3.3: Kort brugsmønsterbeskrivelse for Se taxavogns aktuelle position. Brugsmønster: Analyser bestillinger. ID 2.2 Aktør: Centralbruger Formål: At analysere tidligere bestillinger af taxavogne. Kort oversigt: Centralklienten skal kunne fremvise en grafisk præsentation af en statistisk analyse af taxavognsbestillinger, ud fra informationer om tidligere gemte bestillinger. Denne analyse skal udføres med rammer, givet af centralbrugeren, bl.a. ugedag og bestillingslokationer. Tabel 3.4: Kort brugsmønsterbeskrivelse for Analyser bestillinger Side 15

16 Brugsmønster: Bestilling af taxavogn. ID 3.2 Aktør: Centralbruger Formål: At bestille en taxavogn til en kunde. Kort oversigt: Det skal være muligt for centralbrugeren at oprette og sende bestillinger til en eller flere taxavogne, ved at angive adresse på opsamlingsstedet. Tabel 3.5: Kort brugsmønsterbeskrivelse for Bestilling af taxavogn. 3.6 Mål og forventede resultater Det er et ønske at analysere, designe og implementere hele systemet. Pga. tid- og pladsmæssige begrænsninger er dette ikke muligt. Det er tilstræbt at de tre fag; hhv. softwarekonstruktion, datakommunikation og statistik, bliver inddraget i projektet med en ligelig vægtning. Det er derfor et mål for dette projekt, at: Analysere og bearbejde de udvalgte krav - for at afdække softwarekonstruktion. Analysere og bearbejde de udvalgte brugsmønstre - for at afdække softwarekonstruktion. Designe softwareløsningen således det er vedligeholdelsesvenligt og let at udvide - for at afdække softwarekonstruktion. Implementere datakommunikation mellem klient og server - for at afdække datakommunikation. Gøre systemet i stand til at udføre beregninger på statistiske modeller - for at afdække statistik. Skrive en rapport hvor projektafgrænsningens omfang er analyseret og designet i sådan en grad at en 3. part kan implementere softwaresystemet. Det forventes at udarbejde en kørende version af TaxaTracer, hvilket vil indeholde en række kernefunktioner for systemet. Disse vil være: Sporing og grafisk visning af taxavognenes aktuelle positioner samt driftstatus. Mulighed for bestilling af en taxavogn. Kommunikation mellem klienter og servere. Systemet skal gemme taxavognenes positioner og driftstatus. Analysere data med henblik på at udarbejde statistik for bestillinger. Det forventes at data bliver simuleret med henblik på test. Det er som mål at teste systemet med en GPS-antenne. Side 16

17 Ovenstående punkter er gruppens forventede resultater, og på den baggrund, udgør visse punkter, vigtige milepæle i tidsplanen. Rapportens konklusion vil gennemgå ovenstående punkter, med henblik på at vurdere om punkterne er opfyldt, hvorledes dette er opnået og argumenter for vigtige trufne valg. For at fokusere på første punkt i målene skal de udvalgte brugsmønstre og krav analyseres og bearbejdes. Kapitel 4 vil kort sammenfatte analysen. Side 17

18 4 Analyse af de udvalgte brugsmønstre Analyseafsnittet er lagt i bilag pga. restriktioner på rapportens sideantal. Der gives her en kort gennemgang af de fundne problemstillinger gennem analyseafsnittet der kan læses i dets fulde længde i bilag A. Igennem analysen er det fundet at brugsmønstrene Se taxavogns aktuelle position og Ændre driftstatus kan behandles samtidigt. Begge omhandler problemstillingen at sende informationer fra taxavognene til centralen og databasen. Disse informationer kan samles og sendes samtidig, da det er ønsket at vide både hvornår positioner eller driftstatus ændres. Centralen skal yderligere modtage og behandle informationen fra taxavognen og oplyse den til brugeren af centralen. Brugeren kan ud fra disse informationer træffe beslutninger om hvortil bestillinger skal sendes. Samtidig skal informationerne vedrørende position og driftstatus lagres da det er et krav fra kundens side at disse kan tilgås i minimum 3 måneder. Prækonditionerne for disse brugsmønstre er, at enten har taxavognene skiftet position eller taxachaufføren har ændret driftstatus. Brugsmønstrene bidrager med klasserne Taxi og Position. Brugsmønsteret Bestilling af taxavogn indeholder problemstillingen for, hvordan centralen kan kommunikere med taxavognen. Når centralen opretter en bestilling, ligger problemet i hvordan bestillingen videregives til taxavognen der efterfølgende kan acceptere bestillingen (indeholdt i et andet brugsmønster). Samtidig skal bestillingen lagres således informationerne kan tilgås senere hvis der ønskes en statistisk analyse af disse. Der skal findes en løsning for opbevaring af data der gør informationerne tilgængelig for programmet på et senere tidspunkt. Prækonditionen for Bestilling af taxavogn er at en kunde indgiver en bestilling til brugeren af centralen. Igennem dette brugsmønster tilføjes klassen Order til klassediagrammet. Problemstillingen i brugsmønsteret Analyser bestillinger er hvordan de tidligere lagrede informationer der ønskes behandlet trækkes ud af systemet og hvor i systemet disse skal behandles. Brugsmønsteret tilføjer ingen nye klasser til forretningsmodellen, der kan ses på figur 4.1. Figur 4.1: Analyseklassediagram af forretningsmodellen for de udvalgte brugsmønstre Side 18

19 5 Systemarkitektur Gennem analysen er de udvalgte brugsmønstre analyseret, og derved er der opstillet en række problemstillinger, kort præsenteret i kapitel 4. Før løsningerne til problemerne kan designes, er det nødvendigt at beslutte hvorledes systemet skal opbygges med henblik på systemets arkitektur, og hvordan dette skal opdeles i en klient-server løsning. Herunder skal deres kommunikationsform fastlægges. Afsnit 5.1 beskriver hvordan TaxaTracers arkitektur bliver opbygget med henblik på at opdele systemet i klienter og servere. Hermed vil der blive analyseret hvor i systemet, opdelingen kan foretages, og hvorfor der er valgt den bestemte opdeling. Der vil i afsnit 5.2, med henblik på pakkeafhængigheder, blive bestemt hvordan TaxaTracers pakkestruktur skal opbygges, for at minimere afhængigheder, gøre systemet vedligeholdelsesvenligt og fremtidssikkert. I afsnit 5.3 bliver det beskrevet hvordan klienten og serveren kan kommunikere. Herunder vil det blive besluttet hvilken transportprotokol der skal anvendes, og der vil blive fremlagt argumenter for den valgte database fremfor alternativer. I afsnit 5.4 opstilles tekniske memoer for TaxaTracers ikke-funktionelle krav. Her vil løsningforslag til de opstillede problemstillinger blive beskrevet. 5.1 Klient server struktur Analysen, i kapitel 4, førte til at systemet skal opdeles i minimum én klient, placeret i taxavognen, og en server placeret på centralen, som kan sende bestillinger ud til taxavognene og se deres positioner. De opstillede krav for systemet gør bl.a. at det skal være muligt at lave statistisk analyse på tidligere oprettede bestillinger - alle nødvendige informationer skal derfor lagres. For at beslutte hvor "tyk"taxaklienten skal være, analyseres dennes funktionalitet. Denne beslutning påvirker serveren, da en tykkere klient vil resultere i tilsvarende tyndere server. Da taxaklienten ikke har et stort ansvarsområde, er det ikke nødvendigt for taxaklienten at kende til forretningsmodellen. Klienten vil ikke kunne sende positioner og modtage bestillinger bedre med dette kendskab. Yderligere er det ikke ønsket at have meget hardware placeret i en taxavogn, da mere kompliceret hardware er mere strømkrævende, hvilket ikke er hensigtsmæssigt i en mobil enhed. Derfor er det valgt at taxaklienten skal være tynd. Taxaselskabet vil få et problem i kraft af at centralserveren, som har til ansvar at sende bestillinger til taxaklienterne og modtage deres positioner, indeholder hele forretningslogikken. Derfor vil det i denne opsætning være mest hensigtsmæssigt at opsætte én centralserver. Det er dog muligt at opsætte flere centralservere, som alle indeholder forretningslogikken. Det er ikke hensigtsmæssigt, da ændringer i én server skal synkroniseres med samtlige centralservere, hvilket giver et komplekst problem og en forøget netværkstrafik. Da det ikke er acceptabelt kun at kunne sende bestillinger fra én computer, er det nødvendigt at en ekstra klient kan varetage centralenserverens funktionelle roller. Herved er det muligt at opsætte en selvstændig applikationsserver, som kan varetage al forretningslogikken. Dette resulterer i at det nu er muligt at have flere centralklienter til at sende Side 19

20 bestillinger til taxaklienterne, hvilket er den løsning der er vurderet at være optimal for et taxaselskab med flere centralbrugere. Både taxaklienten og centralklienten er ønsket at være tynde klienter, dog med mulighed for interaktion med resterende dele af systemet. Det er ikke hensigtsmæssigt at databasen er koblet til applikationsserveren. En kobling vil resultere i at hvis applikationsserveren bryder ned, vil det påvirke databasen. Derudover vil det være muligt, hvis applikationsserver og database er adskilt, at have en ekstra applikationsserver stående i tilfælde af nedbrud eller meget høj trafik, til at aflaste den anden applikationsserver. Denne opsætning betegnes også som at opsætte en server-cluster 1. Når cluster benyttes, er det muligt at have mange applikationsservere stående og varetage alle forespørgsler. Disse vil i tilfælde af høj trafik uddelegere arbejdet optimalt til de forskellige applikationsservere, vha. en workloader, og vil herefter synkronisere serverne når opgavebyrden igen er faldet - dette princip kaldes load balancing. Cluster benyttes når der ønskes forøget ydeevne og tilgængelighed. Hvis en af serverne i clusteret går ned, vil workloaderen blive gjort opmærksom på dette, og vil derfor kun delegere arbejdsopgaver ud til der resterende funktionsdygtige servere. Det skal nævnes at der udadtil ikke er muligt at se om en server er opsat som cluster, så det skal der ikke tages højde for når der sendes forespørgsler til serveren. Indadtil er serverne oftest forbundet med højhastigheds-ethernet, hvilket er nødvendigt da alle serverene skal synkroniseres. At benytte cluster påvirker mange faktorer, bl.a. bliver prisen for at opsætte systemet højere, end hvis der kun blev opsat én server. Samtidig ville systemet være mere usikkert ved forøget trafik ved benyttelse af én server. Da tilgængelighed er et krav, vil en adskillelse af applikationsserver og database vælges. På den måde er systemet fremtidssikkert. Hvis taxaselskabet bliver for stort til at én server ikke er nok til at håndtere forespørgslerne, kan cluster indføres - derfor er denne fleksibilitet indført. Samtidig kan samme princip benyttes i forhold til databasen, hvis det skulle blive nødvendigt. Det er vigtigt at understrege at dette kun er muligt da applikationsserveren og databasen er adskilt, dog vil dette ikke blive implementeret, da dette er komplekst at opsætte og kræver specielt hardware og software. Udfra det ovenstående, ønskes tynde klienter på både taxavognen og centralen, og det ønskes at adskille applikationsserver fra database. Hermed fås tre systemdele; klient, applikationsserver og database. Dette medfører at der vil blive benyttet en 3-tiered softwarearkitektur, hvilket er den mest anvendte softwarearkitektur 2. En tier repræsenterer en systemdel der er uafhængig af andre, og vil ofte være placeret på separate platforme. Systemet vil indeholde en præsentations-tier, en forretninglogik-tier og en data-tier. Figur 5.1 illustrerer hvorledes tiers ne er opdelt. Figur 5.1 viser med fremhævede snit - de snit systemet bliver opbygget efter. De nedtonede snit, illustrerer de alternative snit, der kunne have været valgt. Da der ønskes en tynd klient som har mulighed for interaktion, og stadig uden forretninglogik, kan snittet kun ligge således der skabes en remote user interface. Det er ønsket at adskille applikationsserver og database, da der ikke ønskes at dele af databasen skal være placeret på applikationsserveren, er det kun muligt at lægge snittet ét sted - så der skabes en remote database. Tabel 5.1 og 5.2 beskriver fordele og ulemper ved de valgte snit. Tabeller for de alternative snit, er ikke medtaget i rapporten, da disse snit er blevet fravalgt. Dog kan beskrivelsen af snittenes fordele og ulemper, læses i bilag B Side 20

21 Figur 5.1: TaxaTracer-systemets multi-tiered arkitektur Distributionsniveau Kompleksitet Sikkerhed Distributionsomkostninger Online/ Batch/ Offline Performance Remote user interface Fordel: Det er muligt at opsætte ekstra enheder til klienten, såsom en Bluetooth enhed. Ligeledes er det muligt at sætte en specifik netværks kommunikation op. Fordel: Middel kompleksitet. Opdelingen sørger for et samlet domænelag. Både bluetooth- og netværksforbindelser skal sættes op, hvilket gør systemet middel komplekst. Fordel: Givet at en klient går ned vil dét ikke påvirke det resterende system. Fordel: Distributions- og opdateringsomkostingerne ved en Remote user interface vil være lavere end ved en Distrubuted application kernel da der kun ligger kommunikationssoftware og brugerflade på klienten. Fordel: der er rig mulighed for online og batch opgaver. Ulempe: Der er ikke mulighed for at arbejde offline(afkoblet Internet). Fordel: Da klienten udelukkende skal stå for kommunikation og ganske simple beregninger, er der ikke brug for kraftigt afviklingshardware. Samtidig er der mindre netværkstrafik end ved en Distrubuted presentation, da der ingen kontrolsignalstrafik er. Tabel 5.1: Fordele/ulemper for Remote user interface Distributionsniveau Kompleksitet Sikkerhed Distributionsomkostninger Online/ Batch/ Offline Performance Remote Database Fordel: Mulighed for anden placering, fx hos et tredjeparts firma, der vil foretage backup. Dette giver mulighed for opsætning af flere applikationsservere. Fordel: Der er ikke brug for at udvikle specifikt databasesoftware, da dette er tilgængeligt for den enkelte databasetype. Fordel: Hvis en applikationsserver bryder ned, eller slukkes, vil databasen ikke være påvirket. Ulempe: Sikkerheden bliver kompromiteret da der indføres et link mellem databasen og det resterende system. Ulempe: Distributionsomkostingerne er større, da der skal investeres i seperat hardware til en database. Fordel: Databasen kan både kommunikere med applikationsservere, samt udføre batch job og arbejde uafhængigt af det resterende system offline. Fordel: Der vil være et helt system til at lave beregninger i databasen og dermed god performance. Herudover er strukturen fleksibel nok til at køre cluster, hvilken medfører højere ydeevne samt mindre nedetid. Ulempe: Der er mere netværkstrafik mellem database og det resterende system i forhold til en integreret database. Tabel 5.2: Fordele/ulemper for Remote database Side 21

22 En fundamental regel i en 3-tiered softwarearkitektur er, at præsentation-tier ikke må kommunikere direkte med en data-tier 3, derfor skal denne kommunikation foregå gennem applikationsserveren. For at klienterne kan kommunikere indbyrdes, skal denne kommunikation også foregå gennem applikationsserveren, da klienternes forspørgsel først skal fortolkes og sendes videre, således den spurgte klient, kan forstå forespørgslen. Grunden til at klienterne ikke kan "forstå"hinanden, er fordi forretningslogikken er deres fælles "sprog", men da klienterne ikke besidder denne, skal kommunikationen foregå gennem applikationsserveren. Figur 5.2 viser konklusionen på ovennævnte problemstillinger samt systemets kommunikationsveje. Figur 5.2 viser, hvorledes taxaklienterne kommunikerer gennem Internettet til det Intranet hvor applikationsserveren, centralklienterne og databasen er placeret. Denne systemopsætning tillader hurtig dataoverførsel, da Intranettet er forbundet som en LAN-forbindelse. Denne systemopsætning er mere optimal end den alternative systemopsætning, som figur 5.3 illustrerer, da al dataoverførsel foregår over Internettet, hvilket reducerer overførselshastigheden. Den alternative systemopsætning kan benyttes, når det er ønsket at placere de forskellige systemdele med en større afstand i forhold til hinanden. Arkitekturløsningen der er foretaget, se evt. figur 5.1, giver den grad af fleksibilitet der gør begge systemopsætninger mulig. Figur 5.2: Den foretrukne systemopsætning for TaxaTracer-systemet Figur 5.3: Den alternative systemopsætning for TaxaTracer-systemet Hvilken retning kommunikationen skal forekomme er fastlagt, dog er det endnu uvidst hvilke metoder der kan anvendes for at realisere denne kommunikation. En diskussion af mulige kommunikationsformer, vil blive præsenteret i afsnit 5.3. Da der er valgt en bestemt softwarearkitektur, skal denne videreføres til en konkret pakkestruktur, således det er fastlagt hvilke pakker der er fordelt over de tre tiers. Dette vil afsnit 5.2 give en løsning på. 3 Side 22

23 5.2 Pakkestruktur Pakkestrukturen er essentiel for systemets skalerbarhed. Ved at overholde en pakkestruktur, vil det være muligt at mindske afhængigheder, således dele af systemet kan ændres uden indflydelse på det resterende system. Der findes en række frameworks til at opbygge en pakkestruktur. Et framework kan forekomme i to sammenhænge - et softwareframework, og et arkitekturframework. Et framework består ifølge Pree 4 af frozen spots og hot spots. Frozen spots er de faste rammer som følger med frameworket - rammer der ikke kan ændres på. Hot spots er de dele af frameworket der skal implementeres af udvikleren for at frameworket kan bruges - de fleksible dele. Softwareframeworks anvendes til softwareudvikling, hvilket hjælper udviklere til at genbruge kode. Det er eksempelvist Java s Collection-framework, som giver udviklere mulighed for at lave lister og samlinger, i stedet for selv at programmere det fra bunden. Herved forekommer begrebet softwaregenbrug, hvilket betyder der udnyttes kode (framework) andre har udarbejdet, og tilføjer egen implementering i frameworkets hot spots. Et udbredt arkitekturframework er MVC-frameworket 5 der består af Model, View og Controller pakkerne, hvilket er frameworkets frozen spots, hvor view indeholder brugergrænsefladen, model repræsenterer forretningsmodellen og controller håndterer interaktionen mellem de to pakker. I dette framework er det muligt at udskifte fx en brugergrænseflade, uden at skulle ændre i de andre pakker. En videreudbyggelse af MVC-frameworket er PCMEF, se figur 5.4. Figur 5.4: PCMEF pakkestruktur PCMEF står for Presentation-Control-Mediator-Entity-Foundation, hvor strukturen imellem pakkerne samtidig er frameworkets frozen spots, og er et vertikalt hiarki bestående af lag med en bestemt struktur, der kan indeholde pakker og klasser. Strukturen kan der ikke ændres på, dog 4 [7] - side [3] - side 277 Side 23

24 kan de forskellige pakker implementeres som det er ønsket, hvilket er frameworkets hot spots. De forskellige pakker i PCMEF strukturen har følgende ansvarsområder: Presentation - Håndterer brugerinteraktionen og præsenterer data hentet fra underliggende lag. Control - Håndterer forespørgsler fra Presentation-laget, og er ansvarlig for at behandle brugernes interaktioner fra brugergrænsefladen. Entity - Indeholdt i Domain-laget - Entity-pakken behandler forespørgsler fra Control-laget. Entity indeholder de klasser der repræsenterer forretningsmodellen. Mediator - Indeholdt i Domain-laget - Mediator-pakken etablerer kommunikationen mellem Entity-pakken og Foundation-laget. Mediator-pakken er introduceret for at isolere Entity-pakken og Foundation-laget, ydermere udelukker Mediator-pakken nødvendigheden for kontrolklasser til at tilgå Foundation-laget, hver gang databasen skal tilgås. Foundation - Er ansvarlig for kommunikation med database og forskellige webservices. PCMEF-frameworket indeholder yderligere en række principper, der gør systemet mere robust, skalerbart og nemmere at vedligeholde. Nogle af disse principper som PCMEF indeholder er: Downward Depency Principle (DDP), hvilket gør øvre lag afhængige af nedre. Dette gør at øvre lag kan udskiftes uden at det har indflydelse på de nedre lag, hvilket resulterer i at nedre lag er mere stabile end øvre. Neighbour Communication Principle (NCP), hvilket gør at et lag kun kan kommunikere med nabolag og formindsker således afhængigheder. Upward Notification Principle (UNP), hvilket resulterer i lav kobling fra nedre lag til de øvre. Dette betyder at øvre lag skal anmode, om hændelsesændringer på nedre lag, og virke som observatører, således at nedre lag sender notifikationer op til øvre lag om, at der er sket en ændring. Cycle Elimination Principle (CEP), hvilket eliminerer cirkulære afhængigheder, dette kan gøres med indsættelse af en ekstra pakke, og med indsættelse af et interface. Class Naming Principle (CNP), hvilket gør det muligt at vide hvilken pakke en klasse er indeholdt. Dette gøres ved at navngive klassen med et P, C, M, E eller F afhængigt af hvilken af frameworkets pakker klassen er indeholdt i. Hvis det er ønsket af få en dybere forståelse for principperne bag PCMEF, henvises der til PSE 6. I afsnit 5.1 blev systemets tiers præsenteret. PCMEF pakkerne skal fordeles ud på disse tiers. Det første tier er præsentations-tier, som er indeholdt i begge klienter. Da klienterne både skal have en brugergrænseflade samt mulighed for interaktion, vil det medføre at PCMEF s øverste to pakker, 6 [3] - side 282 Side 24

25 presentation og control, skal være placeret på klienterne. Dernæst skal andet tier, forretningslogiktier, placeres. Da denne også indeholder databaseadgang, skal entity, mediator og foundation være placeret i forretninglogik-tier. Da databasen er en selvstændig tier, er denne ikke inkluderet i PC- MEF. Figur 5.5 viser sammensmeltningen af PCMEF-frameworket og den 3-tiered softwarearkitektur der er blevet valgt. Figur 5.5 viser hvilke pakker systemet indeholder, både for begge klienter Figur 5.5: Pakkediagram for systemet i sin helhed og for applikationsserveren. Figuren viser hvorledes kommunikationen mellem klienter og server går igennem hver deres connector-pakke, hvilket er deres kommunikationsport udadtil. Selvom PCMEF frameworket tillader at der kaldes fra control-laget ned til entity eller mediator, er det ikke blevet gjort, da connector-pakken sørger for at al trafik mellem klienter og servere går igennem denne. Derfor kan connector-pakken anses for at være en facadepakke, hvilket samler kommunikationstrafik og afhængigheder mellem subsystemer 7. I applikationsserveren foregår al trafik også gennem connector-pakken, som er klienternes kommunikationsport indadtil til forretningslogikken. Herefter har klienten adgang til både entity og mediator, se figur 5.5. Databasen er som tidligere nævnt ikke en del af applikationsserveren, da databasen er en selvstændig data-tier, og kan kun tilgås gennem foundation-pakken. Kommunikationen mellem klienterne og applikationsserveren bliver klarlagt i afsnit 5.3, hvor det fastlægges hvilken database der anvendes. 7 [3] - side 286 Side 25

26 5.3 Kommunikation, positionering og database Dette afsnit vil omhandle netværk, positionering og database samt hvilke valg der er truffet vedrørende de forskellige teknologiske muligheder og argumenter herfor. Global Positioning System Til at bestemme taxavognenes aktuelle positioner, benyttes en GPS-antenne. En yderligere gennemgang af GPS kan læses i bilag F. GPS benytter en række satelitter til at beregne bl.a. position, hastighed, dato og tid. Der er andre muligheder for positionering, såsom triangulering mellem mobilmaster, som visse mobiltelefoner benytter 8. Det kan dog ikke forventes at antallet af mobilmaster, eller adgangen til disse, er optimal, da bygninger, træer osv. kan have direkte indflydelse på signalet og vil give unøjagtigheder. GPS er ligeledes en fri tilgængelig teknologi, samtidig med at den opfylder de ønskede krav og derfor er denne blevet valgt. Database Der benyttes den relationelle database, MySQL. Det er nødvendigt at sammenligne en relationel database med en objektorienteret database, for at træffe den rigtige beslutning. Valget af den rigtige database afhænger af det system der skal opbygges og hvilke data der ønskes lagret. Da TaxaTracer indeholder simple objektstrukturer er det ikke nødvendigt at benytte en objektdatabase, da disse oftest bliver benyttet til gemme komplekse objektstrukturer 9. En anden grund til at vælge en relationel database er, at den er beregnet til data, hvilket er et af TaxaTracers fokusområder, da der bl.a. ønskes analyse på bestemte data. Det er ikke ønsket at lagre hele objekter, da det kun er objekttilstande der er ønsket, hvilket en relationel database giver mulighed for. En anden mulighed for at benytte en relationel database er Oracle databasen, men da denne ikke er frit tilgængelig, er denne ikke benyttet. Netværk Det er nødvendigt at overføre data fra mobile klienter, i taxavognene, til en stationær arbitrært placeret server. Derfor ønskes en kommunikationsform med lang rækkevidde og god dækning. Der findes flere muligheder for at skabe denne kommunikation mellem klient og server. Der kunne overvejes brug af applets. En applet er et program skrevet i java, der kan inkluderes i en HTML side, på samme måde som et billede er inkluderes i en side. Når der benyttes en java understøttet browser til at se en side der indeholder en applet, bliver applettens kode overført til brugerens system og afviklet af browserens Java Virtual Machine. En servlet er en javaklasse, benyttet til at udvide funktionaliteterne af servere der udbyder applikationer tilgået via en request-response model. Yderligere ville der med en servlet blive genereret meget netværkstrafik samt stor arbejdsbyrde på serveren, da samtlige klienter skal afvikle programmet på serveren. Derfor ville denne løsning heller ikke egne sig til brug ved centralklienten, hvor Side 26

27 der vil være flere klienter koblet op af gangen. Ved brug af appletter og servletter er programmets funktioner og performance begrænset af den benyttede browser, hvilket ikke er ønskeligt. Tredje mulighed der er overvejet, er en Javaapplikation der gør brug af Remote Method Invocation (RMI). RMI gør det muligt at kalde metoder på en server, som var det på den lokale maskine. RMI benytter transportprotokollen, Transmission Control Protocol (TCP). Dette gør at der skal tages en række hensyn til firewalls og routere når forbindelserne skal oprettes. RMI bliver som regel blokeret, modsat HTTP der benyttes af applets. Dette vurderes dog ikke som et problem, da de klienter der benytter systemet er dedikerede klienter og derfor kan firewalls og porte konfigureres som nødvendigt. En Javaapplikation med benyttelse af RMI anses for at være det optimale og dermed trufne valg. En anden fordel ved at benytte TCP, er at det er en pålidelig protokol dvs. at alt data når frem. Pålideligheden opnås gennem timeouts og retransmission af pakker, skulle de ikke nå frem. Denne garanti tilbyder User Datagram Protocol (UDP) ikke, og da ingen datatab er et konkret krav, er TCP valgt. Denne pålidelighed er dog med til at gøre systemet langsommere end hvis UDP blev anvendt. Valget af netværksforbindelse til de mobile klienter, er mobilt bredbånd gennem 3. generations GSM netværk (3G). 3G er blevet valgt frem for de tidligere versioner af GSM netværk et (fx GPRS) og andre muligheder såsom kortbølgeradio. Fordelene ved 3G-netværket er bl.a. at det er en relativt ny standard, implementeret i den vestlige verden omkring år 2002 og frem, hvilket giver en forventet lang levetid, samt at det tillader hurtig og stabil dataoverførsel gennem kendte protokoller. I Danmark, hvor TaxaTracer regnes implementeret, er der desuden dækning i det meste af landet. 10 Dette betyder at der kan installeres mobilt bredbånd i hver enkelt taxavogn, og at denne gennem det mobile bredbånd, altid kan kontakte serveren. Endnu en fordel ved at benytte 3G-netværket er, at denne netværkstype ikke kun er populær i Danmark, men således store dele af Europa. 11 Under bevægelse af taxavognen vil hastigheden på 3G modemmet falde, men dette vurderes ikke til at være et problem da hastigheden stadig vil opfylde kravene for systemet 12, da dataoverførslen ikke vil bestå af mere end simple datatyper. Klienten på centralen vil typisk befinde sig fysisk adskilt fra systemts server, dog stadig stationær. Dette muliggør en hurtig forbindelse gennem lokalt netværk eller Internetforbindelse fra en ekstern udbyder. 5.4 Tekniske memoer I dette afsnit vil der blive opstillet tekniske memoer for de ikke-funktionelle krav, ud fra de opdelte områder (server, softwarearkitektur, nøjagtighed, grafisk brugergrænseflade og ydeevnen). Inden de tekniske memoer kan udarbejdes, er alle ikke-funktionelle krav analyseret ved brug af en faktortabel (Se bilag G). De tekniske memoer vil uddybe faktortabellen, dokumentere de beslutninger der er blevet truffet ift. de ikke-funktionelle krav, beslutninger truffet for softwarens arkitektur, kommuni Efter samtale med 3 mobil service-support vurderes upload hastigheden til omkring 300kb/s under transport ved en easy mobile 7.2 mbit forbindelse Side 27

28 kation, positionering og database. På denne måde kan der opnås en forståelse for hvilke beslutninger der er truffet for systemet og hvordan softwaren er blevet udviklet. Hermed skabes overblik over systemet, til senere videreudvikling eller vedligeholdelse. De kommende tabeller 5.3, 5.4, 5.5, 5.6 og 5.7, giver resumé af faktortabellerne i bilag G, samt præsenterer løsningen på tidligere beskrevet problemstillinger. Teknisk memo: Server Krav KS01: TT skal gemme registrerede data i en database i en periode på min. 3 mdr. KS04: TTS skal registrere og gemme TTT s position og tilhørende tid KS05: TTS skal registrere og gemme TTT s driftstatus og tilhørende tid. Løsning Til opbevaring af data opsættes en MySQL database. Denne database vil gemme data om taxavognens adfærd samt relaterede data. Motivation Taxaselskabet ønsker at kunne se taxavognenes tidligere positioner, driftstatus og tilhørende tid. Dette bruges til en række forskellige statistiske analyser, således at taxaselskabet kan optimere servicen overfor kunderne samt indtjening. Ikke løste problemer Intet at bemærke Alternative løsninger Intet at bemærke Tabel 5.3: Teknisk Memo: Server Teknisk Memo: Softwarearkitektur Krav KA01: TT s softwarearkitektur skal udvikles på en sådan måde, at det simpelt kan videreudvikles og/eller opgraderes. Løsning For at opfylde kravet, følges principperne bag PCMEF frameworket. Motivation Hvis strukturen er overholdt vil det være nemmere at foretage opdateringer og viderudvikle systemet i den ønskede retning. Ikke løste problemer Intet at bemærke. Alternative løsninger Intet at bemærke. Tabel 5.4: Teknisk memo: Softwarerkitektur Side 28

29 Teknisk memo: Nøjagtighed Krav KN01: TT skal kunne vise taxavognens position, på et grafisk kort, med nøjagtighed på ± 20m. KN02: Positions enhed skal have en nøjagtighed på ± 15 m. KY03: TT skal hente taxavognens position maksimum hvert 5. sekund. Løsning Der bliver implementeret den udgave af Google Maps API, der gør brug af længde og breddegrader til at vise placeringen af en taxavogn. Der bruges en GPS-antenne, forbundet via bluetooth. Bluetooth skal implementeres i Java med bluecove API For at hente en taxavogns position maksimums hvert 5. sekund, opsættes en tråd. Motivation For at taxaselskabet kan bruge programmet til at overvåge taxavognene, er det vigtigt at taxavognen befinder sig på den position kortet oplyser. Ikke løste problemer Fabrikanten oplyser en nøjagtighed på 5-20m dette er ikke blevet testet (Se bilag F.3 for GPSantennens manual). Alternative løsninger Intet at bemærke. Tabel 5.5: Teknisk memo: Nøjagtighed Teknisk memo: Grafisk brugergrænseflade Krav: KG01: TT skal omfattes af en grafisk brugergrænseflade. KG02: TT skal have et grafisk kort der viser informationer om taxavognene. Løsning Taxaklienten skal være simpel og brugervenlig. Taxavognchaufføren skal hurtigt kunne skifte driftstatus eller acceptere en bestilling. Til udvikling af denne grafiske brugerflade bruges Java API en swing. Centralklientens grafiske brugerflade har til opgave, at kunne vise taxavognens position/driftstatus på et kort, oprette bestillinger og vise et pindediagram for en statistisk beregning. Til udvikling af denne brugergrænseflade, bruges Java API en swing, Google Maps API en til det grafiske kort og JFreeChart API til oprettelse af et pindediagram. Taxavognenes driftstatus vil blive vist med farvesymboler (grøn=available, rød=occupied, gul=enroute, blå=break, sort=offline). Motivation Det skal være enkelt for brugeren at benytte programmet, derunder skal det give overblik over taxavognenes positioner og driftstatus. Overblikket giver vognmanden tryghed. Ikke løste problemer Intet at bemærke. Alternative løsninger Intet at bemærke. Tabel 5.6: Teknisk memo: Grafisk brugerflade Side 29

30 Teknisk memo: Ydeevne Krav: KY01: Der skal ikke være tab af data under datatransport. Løsning For at undgå tab af data under datatransport bruges TCP-protokollen, da denne garanterer at alle data bliver sendt og modtaget. Der bruges RMI til dataoverførsler mellem klienter og servere. Motivation Taxaselskabet ønsker at få oplyst korrekte data omkring taxavognenes position og driftstatus, samt at de informationer der lagres i databasen ligeledes er korrekte. Samtidig vil det være afgørende for at få en analyse af forskellige områder, således analysen afspejler virkeligheden bedst muligt. Ikke løste problemer Intet at bemærke. Alternative løsninger Intet at bemærke. Tabel 5.7: Teknisk memo: Ydeevne 5.5 Delkonklusion af arkitektur For at konstruere et system med lav afhængighed som samtidig er vedligeholdelsesvenligt, er det valgt at benytte PCMEF frameworket med dens tilhørende principper. En 3-tiered arkitektur er blevet valgt, med snittene lagt således, der skabes remote user interface og remote database. Disse blev valgt da systemet herved er mere vedligeholdelsesvenligt og skalerbart samt opfyldelse af ønsket om tynde klienter. Da kommunikation mellem klienter og server er påkrævet, blev mulighederne analyseret, og RMI blev valgt. Valget af netværksforbindelse blev 3G, mobilt bredbånd, hvilket er en populær netværksforbindelse i hele Europa. Ved valg af transportprotokol, blev TCP foretrukket fremfor UDP, da TCP er mere pålidelig end UDP. UDP er dog en hurtigere protokol, men signifikansen af korrekt data fremfor hurtigt dataoverførrelse er større, hvorfor TCP er valgt. En GPS-antenne er blevet valgt til at bestemme taxavognenes aktuelle positioner, da den opfylder de stillede krav samt er en frit tilgængelig teknologi. En relationel database er foretrukket til lagring af informationer, da en objektdatabase er beregnet til komplekse objektstrukturer. Derudover ønskes der ikke gemt objekter, men kun objekttilstande, hvilket en relationel database er beregnet til. MySQL er en frit tilgængelig database, hvilket også er argumentet for at vælge denne fremfor fx en Oracle database. Dette kapitel danner grundlag for kapitel 6, omhandlende design af de forskellige systemdele. Side 30

31 6 Design af de udvalgte brugsmønstre Der bliver i dette kapitel designet en løsning for problemerne præsenteret i kapitel 4. I designaktiviten, fastlægges hvordan systemet interagerer med brugeren og andre systemdele. Det er derfor vigtigt at skabe overblik over, hvordan systemet håndterer forskellige problemstillinger, således implementeringen bliver så enkel som muligt. Der ønskes med dette kapitel at skabe det overblik der skal til for, at læseren forstår designet. Der vil yderligere præsenteres resultater af de vigtigste designaktiviteter, der er blevet udarbejdet for at kunne implementere systemet. De vigtige punkter for designaktiviteten vurderes at være følgende: Klassediagrammer - Klassediagrammet der vil blive præsenteret vil være en videreudbyggelse af analyseklassediagrammet præsenteret i kapitel 4. Klassediagrammet udarbejdet under designaktiviteten indeholder samtlige parametre, attributter samt metoder i systemet under forretningsmodellen. Sekvensdiagrammer - Sekvensdiagrammer er en videreudbyggelse af systemsekvensdiagrammer, da det giver overblik over systemets interaktioner på whitebox-plan (systemets interne input/output forhold). Der vil i afsnit 6.1 blive præsenteret systemets forretningsmodel, således der gives overblik over klassernes indbyrdes relationer. Afsnit 6.2 præsenterer sekvensdiagrammer for de to brugsmønstre der dækker funktionen, at sende en taxavogns aktuelle position og driftstatus. I afsnit 6.3 opstilles sekvensdiagrammer for funktionaliteten, at bestille en taxavogn. Afsnit 6.4 omhandler den statistiske analyse af bestillinger og de tilhørende sekvensdiagrammer. Til sidst vil afsnit 6.5 belyse hvordan databasen er designet. 6.1 TaxaTracers forretningsmodel Klassediagrammet beskriver hvorledes forretningsmodellen skal implementeres i systemet, og sekvensdiagrammerne beskriver udførelsen af TaxaTracers funktionaliteter igennem hele systemet, fra klient til applikationsserver og ned i databasen. Det er ud fra disse diagrammer muligt, at implementere løsningen for de opstillede problemer. Figur 6.1 viser en fremhævet og en nedtonet del af klassediagrammet. Den fremhævede del illustrerer klasser der ønskes designet og implementeret, da disse har relevans for de valgte brugsmønstre (se figur 3.1). Den nedtonede del illustrerer de klasser der ikke analyseres og designes yderligere. Side 31

32 Figur 6.1: Klassediagram over forretningsmodellen Det ses på figur 6.1 hvordan Taxi-, Position- og Order klassen er designet, hvilke attributter og metoder de indeholder, samt deres indbyrdes relationer. TaxiCompany og Taxi er begge centrale klasser i systemet. Taxi har to associationer til både Position og Order. Associationerne betegnes med current og previous. Current beskriver det forhold en taxavogn har med sin nuværende position, og det nuværende forhold en taxavogn har til en bestilling. Dertil er det tydeligt at en taxavogn kan have ingen eller én position, og ingen eller kun en igangværende bestilling. Previous beskriver forholdet mellem en taxavogn og dens tidligere positioner og bestillinger. Derfor kan en taxavogn have haft ingen og op til mange positioner og bestillinger tidligere. Disse positioner og bestillinger vil blive gemt i en database, således det er muligt at få oplyst, hvilke bestillinger og positioner en bestemt taxavogn har haft. Netop dette indgår i formålet med at skabe et overvågningssystem for taxaselskabet, hvor al trafik lagres. Dette er nødvendigt, når der skal laves analyse på bestillinger i taxaselskabet. Side 32

33 6.2 Design af Se taxavogns aktuelle position og Ændre driftstatus Til de problemer der er opstillet i kapitel 4, omhandlende analysen, bliver der i dette kapitel designet en løsning. Dette afsnit vil fokusere på designet for hvordan klienten i en taxavogn skal sende informationer til applikationsserveren, hvordan informationerne gemmes i en database og hvordan informationerne sendes videre til alle centralklienter. Det er dermed centralklienten muligt, at se hvor taxavognen befinder sig, og hvilken driftstatus den har. Afsnittet vil præsentere sekvensdiagrammer, for at illustrere et typisk scenarie. Ved hvert sekvensdiagram, findes et tilhørende logo, for at give overblik over hvor sekvensen finder sted; enten på taxaklienten, applikationsserveren eller centralklienten. Hændelsesforløbet starter med, at taxavognen oplyser sin aktuelle position til centralen. En GPS-antenne sender, via bluetooth, en position til klienten i taxavognen, herefter bliver positionen sendt via en 3G forbindelse til centralen. Figur 6.2 viser hvordan TaxiClient kalder settaxainfo() på RMICommunication, og sender både Figur 6.2: Sekvensdiagram over afsendelse af position og driftstatus fra taxavogn GPS-sætningerne, taxiid, driverid samt driftstatus af taxavognen som parametre. RMICommunication, skal fortolke og omstrukturere GPS-sætningerne, således der kun benyttes de parametre applikationsserveren forventer. Metoden parsegpmrc() har til ansvar, at lave de sexagecimale positionsparametre om til længde og bredde i decimalgrader, for dybere gennemgang, se bilag F. Argumentet for at klienten skal lave beregningerne fremfor applikationsserveren er, at det er klientens ansvar at analysere og modulere dens GPS-input, og sende det videre til applikationsserveren, således at applikationsserveren modtager information af en bestemt form, uafhængigt af GPSmodul. Metoden run() kaldes på RMICommunication, der opretter en tråd der, hvert 5. sekund, kontrollerer om taxavognen har flyttet sig eller skiftet driftstatus. I tilfælde af ændringer sendes den relevante information, se figur 6.3. Side 33

34 Figur 6.3: Sekvensdiagram for run()-metoden på taxaklienten Hvis taxavognen enten har skiftet driftstatus eller ændret position, sendes besked til ServerService, ved brug af RMI, hvilket er et remote interface på applikationsserveren. Denne sammenligning er placeret før der sendes informationer til applikationsserveren, da dette vil minimere netværkstrafikken ift. kontrol på applikationsserveren. Hvis taxavognen har ændret position eller driftstatus, Figur 6.4: Sekvensdiagram for lagring samt opdatering af centralklient bliver applikationsserveren gjort opmærksom på dette, og det er nødvendigt at gemme de nye informationer i databasen. Derfor bliver preparedbsaving() kaldt på CDBConnector klassen, se figur 6.4. Når de nye informationer er gemt i databasen, skal de nye taxavognsinformationer distribueres ud til alle centralklienter, der er koblet til applikationsserveren. Det bliver gjort i loop et på figur 6.4, hvor der itereres igennem en samling af centralklienter, der er logget på applikationsserveren. Side 34

35 For hver centralklient, opdateres både position og driftstatus ved metodekald på interfacet CentralClient. UNP-princippet i PCMEF, ligger til grund for kaldet på interfacet. Figur 6.5 illustrerer hvilke hændelser der forekommer på centralklienten, når positionen bliver opdateret. Figur 6.5: Sekvensdiagram hvor centralklienten oplyser taxavognens position og driftstatus For at fuldføre updateposition(), kaldt på ClientImpl, skal centralklienten have kendskab til den taxavogn der ønskes opdateret længde- og breddegrad på. Kendskabet fås gennem TaxiFactory, som holder styr på samtlige taxavogne der er koblet til applikationsserveren. Centralklienten har fået oplyst hvilken taxavogn der har ændret position. Da PCMEF frameworket, ikke tillader opadgående kald, benyttes designmønsteret Observer pattern. Mønsteret gør oberservatør og subjekt uafhængige, da subjektet ikke behøver at kende til dets observatører. Istedet tillader subjektet at observatøren kan abonnere på notifikationer af enhver art. I dette tilfælde, bliver metoden notifyobservers() kaldt på taxi, og alle observatører der abonnerer på positionsskift ift. taxavogne, bliver gjort opmærksom på at der er sket en ændring. I dette tilfælde, er brugergrænsefladen observatøren der har implementeret TaxiObserver-interfacet, da den er interesseret i notifikation, når en taxavogn flytter sig, således kortet kan opdateres. Dette Observer pattern benyttes med pull teknikken, hvilket betyder at observatøren selv har til ansvar for at finde de oplysninger der er blevet ændret. I modsætning til push teknikken, hvor observatøren får ændringen i form af en parameteroverførelse. Pull teknikken er benyttet, da det er vurderet observatørens ansvar at finde ændringen og handle derefter. Metoden setstatus(), på figur 6.4, minder på mange måder om metoden updateposition(), hvorfor denne metode ikke bliver gennemgået. Side 35

36 6.3 Design af Bestilling af taxavogn Ud fra pakkediagrammet på figur 5.5, præsenteret i afsnit 5.2 og den detaljerede brugsmønsterbeskrivelse samt systemsekvensdiagrammet, udarbejdet i analysen, er det muligt at udarbejde et mere detaljeret sekvensdiagram. I det følgende afsnit vil designet for brugsmønsteret Bestilling af taxavogn, blive gennemgået. Det vil ud fra designet været muligt at implementere denne funktionallitet. Det vil først beskrives hvordan bestillingen bliver oprettet fra centralklienten, efterfølgende vil det blive beskrevet hvordan bestillingen bliver behandlet på applikationsserveren. Til sidst beskrives hvordan der oprettes forbindelse til og gemt i databasen samt hvordan taxaklienten modtager en bestilling. Hændelsesforløbet starter med, at centralen modtager en bestilling fra en kunde. Efter bestillingen er indtastet, vil den blive sendt fra centralen til alle taxavogne. Hændelsesforløbet på centralklientens side, ses på figur 6.6. Figur 6.6: Sekvensdiagram for oprettelse af bestilling Oplysningerne for bestillingen (adresse, by, postnummer og telefonummer) indtastes på den del af centralens brugergrænseflade der tager sig af bestillinger. Selve behandlingen af de indtastede oplysninger foregår i klassen CActioner. Denne klasse vil ligeledes sørge for at klassen ConRMI opretter forbindelse til applikationsserveren. Herefter er det muligt at sende bestillingen videre til applikationsserveren ved brug af remote interface et ServerService. Når applikationsserveren modtager bestillingen lagres den i databasen og sendes ud til alle taxaklienter, se figur 6.7. Side 36

37 Figur 6.7: Sekvensdiagram for Bestilling af Taxavogn Herved oprettes der, som det ses på figur 6.7, et aorder-objekt med oplysninger om bestillingen. Yderligere bliver der oprettet et Calender-objekt der tilknyttes bestillingen, således tid og dato registreres til senere brug. Efter aorder-objektet er oprettet kaldes metoden prepareordersaving() på klassen CDBConnector. Denne kalder dematerializeorder() på MBroker, der sørger for at trække de relevante data ud af aorder-objektet og gemme disse i databasen, se figur 6.8. Med metoden getinstance(), ses det at der benyttes designmønsteret Singleton, til at opretholde Figur 6.8: Sekvensdiagram for at lagre bestillingen i databasen én instans af klassen MBroker. Singleton benyttes da det ikke er nødvendigt at have flere instanser af MBroker for at gemme bestillinger i databasen. Samtidig vil flere ubenyttede instanser medføre unødvendig brug af systemressourcer. Singleton benyttes også i forbindelse med de objekter der benyttes i forbindelse med skrivning til og læsning fra databasen. Herefter kan bestillingen sendes Side 37

38 ud til taxaklienterne. Ved brug af RMI interfacet, TaxiClient, kaldes metoden updateorders(), der opdaterer bestillingerne. Figur 6.9 illustrerer hvorledes taxavognene opdaterer deres bestillinger. For Figur 6.9: Sekvensdiagram for at opdatere bestillinger på en taxavogn at vise bestillingerne på Taxaklienternes brugergrænseflader, kræves det at der sendes data til disse. Dette kan ikke ske gennem et direkte kald, da dette vil stride mod pricippet UNP i den benyttede PCMEF arkitektur. For at præsentere en bestilling på klientens brugergrænseflade benyttes derfor Observer pattern. Det gøres derved muligt at notificere taxaklienten. 6.4 Design af Analyser bestillinger Formålet med dette brugsmønster er at give taxaselskabet overblik over efterspørgslen af deres taxavogne. Dette kan bestemmes ud fra det antal bestillinger taxaselskabet modtager. Da det i afsnit 6.3 blev belyst at bestillingerne gemmes i databasen, er det netop med henblik på at kunne lave statistik over tidligere bestillinger. Et taxaselskab vil have glæde af, at få oplyst historikken over, hvornår selskabets kunder bestiller deres taxavogne, fordelt over en bestemt dag. Derfor antages det at bestillingerne er internt uafhængige, men at fordelingen af bestillingerne vil være afhængig af ugedagen samt tidspunktet. Det vil muligvis være tilfældet, at taxaselskabet har mere travlt i weekenden end på hverdage, og mere travlt ved mødetid og fyraftenstid end i intervallet herimellem. Det antages yderligere, at bestillingerne ikke er uniformt fordelt over en bestemt ugedag, hvorfor der ikke er forskel på fordelingen af bestillinger på bestemte ugedage (fx mandage) uanset dato. Disse antagelser benyttes til at udforme den model, der benyttes til statistikberegningerne. For at kunne lave en mere udspecificeret statistisk analyse ønskes det, at kunne koncentrere analysen på bestemte bydele. For at vise den bedste repræsentation af bestillingerne, er det nødvendigt at opstille en realistisk statistisk model. En simpel men effektiv mulighed, er at vise gennemsnittet af samtlige bestillinger i den valgte periode, og præsentere denne sammen med den tilhørende spredning i et søjle eller pindediagram. Der er dog ulemper ved denne løsning, skulle der forekomme ekstrempunkter, dvs. enkelte perioder med flere bestillinger end normalt, vil disse have langt større indflydelse på det samlede gennemsnit end på fx medianen. Indflydelsen fra disse ekstrempunkter vil dog være aftagende med et stigende antal bestillinger. Da det antages at antallet af bestillinger vil være ganske betydelig, kan denne metode anvendes med en acceptabel nøjagtighed. Som alternativ Side 38

39 kunne præsenteres et såkaldt "boksplot". Et boksplot viser øvre og nedre kvartil, højeste og laveste observation samt median. Denne præsentationsform kan dog være indviklet og derved skabe mere forvirring end gavn for brugeren, da det ikke er ligeså intuitivt eller alment kendt som et søjle/pinde diagram. Derfor er det valgt at benytte et pinde diagram, hvor spredningen er markeret. Figur 6.10: Eksempel på hvordan brugeren får præsenteret analysen af bestillinger Det er vigtigt at funktionaliteten i softwaren er simpel at anvende, derfor skal det kun være muligt at vælge en bestemt dato og lokation, det ønskes at analysere. Lokationen defineres ud fra postnummeret taxavognen ønskes fra. Figur 6.10 viser hvordan brugeren får præsenteret analysen, og kan hurtigt og nemt danne sig et overblik over hvordan efterspørgslen fordeler sig i løbet af den valgte dag, med antal bestillinger op ad anden-aksen, og tiden hen ad første-aksen. For at beregne gennemsnit, x, og spredning, s, benyttes følgende formler 1 : x = 1 n n x i (6.1) i=1 s = 1 n (x i x) 2 (6.2) n 1 Designet af den statistiske funktion i programmet kan have væsentlig indflydelse på netværkstrafikken afhængig af opbygningen. Der bliver i det følgende præsenteret to mulige opbygninger. i=1 1. Systemet kan opbygges således, de statisktiske beregninger bliver udført i selve centralklienten. Dette medfører at applikationsserveren skal trække informationerne ud fra databasen og videresende data til centralklienten uden behandling. Beregninger på den fundne data samt den grafiske præsentation vil da blive udarbejdet af centralklienten. 2. Systemet kan opbygges således at de statisktiske beregninger bliver udført i databasen og resultatet bliver sendt via applikationsserveren til centralklienten der ud fra resultaterne danner de ønskede grafer. Det er valgt at benytte sidstnævnte opbygning, da den første vil resultere i overførsel af store mængder data og derved høj belastning af netværket. Yderligere vil databasen være hurtigere til at 1 [2] - afsnit 2.5 Side 39