Hovedrapport 1. 1 Prolog Forside Synopsis Forord Indholdsfortegnelse Læsevejledning... 7

Transkript

1 Indhold Hovedrapport 1 1 Prolog Forside Synopsis Forord Indholdsfortegnelse Læsevejledning Indledning Problemstilling Problemformulering Projektafgrænsning Mål og forventede resultater Procesmodel Anvendt procesmodel Faktisk forløb Vurdering af procesmodel Indledning til resultater 14 5 Krav og analyse Uddrag fra faktortabel Brugsmønsterdiagram Brugsmønster #07 Køb af rejser Klasser og metoder Brugsmønster #03 Opdatering af software på billetautomaterne Opsumering af krav og analyse Softwarearkitektur Grundlæggende struktur PCMEF+ principper Alternative løsninger Designmål ved brug af PCMEF+ arkitektur Nyttige designmønstre Distribuering af system Netværkskommunikation Database design Opsumering af Softwarearkitektur Design Brugsmønster #08 Almindeligt køb af billet Forklaring af benyttede klasser Overvejelser vedrørende brugsmønster # Sekvensdiagram for brugsmønster # Brugsmønster #15 Indrapportering af logning vedrørende billetsalg Sekvensdiagram for brugsmønster # Brugsmønster #05 Valg af sprog på billetautomat

2 7.3.1 Offline-funktionalitet Brug af Observer-mønsteret Opsumering af Design Implementation Top-10 liste implementation Oprettelse af Top-10 liste Forespørgsel på Top-10 liste Visning af Top-10 liste Statistik og Test Måling og forudsætninger Statistisk model Måling af logningstid på Serversoftware baseret på RMI Serversoftware Perfomance Resterende arbejde Brugsmønster # Brugsmønster # Brugsmønster # Brugsmønster # Generelt TicketMachine Støttediscipliner Konfigurationsstyring Projektstyring Udviklingsmiljø Epilog Konklusion Perspektivering Referenceliste 51 A Appendix 52 A.1 Installationsvejledning A.2 Anvendelse af Secure Sockets Layer (SSL) A.2.1 Generering af nøgler med keytool A.2.2 Anvendelse i Java Bilag b1 1 Forside b1 2 Indholdsfortegnelse b2 3 Ordliste b3 4 Oversigt over brugsmønstre b4 5 Faktortabel b5 6 Brugsmønsteroversigt og kravsporingsmatrice b9 2

3 7 Product Backlog b11 8 Sprint Backlog 1 b12 9 Sprint Backlog 2 b13 10 Sprint Backlog 3 b14 11 Tidsplan b15 12 Review - Referat b16 13 Brugsmønstre b22 14 Sekvensdiagrammer b24 15 Pakkeoversigt b26 16 Designmønstre b29 17 Analyseklassediagram b32 18 Designklassediagram b33 19 Oversigt over GUI til TicketMachine b35 3

4 ETC Billetautomater - et softwaresystem til billetautomater Projektgruppe 1 : Michael Hejselbak Bejer-Andersen [mibej07@student.sdu.dk] Emil Holmegaard [emhol07@student.sdu.dk] Flemming Max Jørgensen [fljoe07@student.sdu.dk] Sven Aage Madsen [svmad04@student.sdu.dk] Thomas Nicky Thulesen [ththu07@student.sdu.dk] Vejleder: Lone Borgersen [lobo@mmmi.sdu.dk] Undervisningsinstitution: Syddansk Universitet - Teknisk Fakultet Kursus: DTSIP4-U1-F09: Statistik i programudvikling Projektperiode:

5 1.2 Synopsis 2

6 1.3 Forord Dette er en projektrapport udarbejdet på 4. semester datateknologi/robotteknologi på Teknisk Fakultet ved Syddansk Universitet i Odense. Projektet er udført af en projektgruppe på fem personer. Rapporten er dokumentation for det udførte projektarbejde omkring softwaresystemet ETC Billetautomater, til det fiktive firma ETC. Softwaresystemet er udviklet i det objektorienterede programmeringssprog Java, ved hjælp af udviklingsmetoden scrum kombineret med Unified Process (UP). Målet med projektet har været at anvende faglighederne opnået i fagene softwarekonstruktion, datakommunikation og statistik tværfagligt. Systemet er udviklet som en distribueret klient/server løsning, og der er benyttet statistiske metoder, til at kontrollere systemets ydeevne. Dette har skaffet grundlag for kvantitativt at måle om systemet er skalerbart. Den distribuerede løsning giver ETC mulighed for nemt at vedligeholde systemet, idet dette nemt kan opdateres fra centralt hold. Der er i løbet af projektperioden udført et formelt review med en anden projektgruppe, hvilket har givet indblik i hvordan et review forløber. Således har projektet haft til mål at opfylde en række softwaremæssige krav fra ETC s side, samt at opfylde de læringsmæssige krav der er opstillet i forbindelse med uddannelsen. Målgruppen for denne rapport er personer der studerer på 4. semester datateknologi/robotteknologi, eller tilsvarende. Projektgruppen vil gerne takke vejleder Lone Borgersen for et godt samarbejde i projektperioden. 3

7 1.4 Indholdsfortegnelse 1 Prolog Forside Synopsis Forord Indholdsfortegnelse Læsevejledning Indledning Problemstilling Problemformulering Projektafgrænsning Mål og forventede resultater Procesmodel Anvendt procesmodel Faktisk forløb Vurdering af procesmodel Indledning til resultater 14 5 Krav og analyse Uddrag fra faktortabel Brugsmønsterdiagram Brugsmønster #07 Køb af rejser Klasser og metoder Brugsmønster #03 Opdatering af software på billetautomaterne Opsumering af krav og analyse Softwarearkitektur Grundlæggende struktur PCMEF+ principper Alternative løsninger Designmål ved brug af PCMEF+ arkitektur Nyttige designmønstre Distribuering af system Netværkskommunikation Database design Opsumering af Softwarearkitektur

8 7 Design Brugsmønster #08 Almindeligt køb af billet Forklaring af benyttede klasser Overvejelser vedrørende brugsmønster # Sekvensdiagram for brugsmønster # Brugsmønster #15 Indrapportering af logning vedrørende billetsalg Sekvensdiagram for brugsmønster # Brugsmønster #05 Valg af sprog på billetautomat Offline-funktionalitet Brug af Observer-mønsteret Opsumering af Design Implementation Top-10 liste implementation Oprettelse af Top-10 liste Forespørgsel på Top-10 liste Visning af Top-10 liste Statistik og Test Måling og forudsætninger Statistisk model Måling af logningstid på Serversoftware baseret på RMI Serversoftware Perfomance Resterende arbejde Brugsmønster # Brugsmønster # Brugsmønster # Brugsmønster # Generelt TicketMachine Støttediscipliner Konfigurationsstyring Projektstyring Udviklingsmiljø Epilog Konklusion Perspektivering Referenceliste 51 5

9 A Appendix 52 A.1 Installationsvejledning A.2 Anvendelse af Secure Sockets Layer (SSL) A.2.1 Generering af nøgler med keytool A.2.2 Anvendelse i Java

10 1.5 Læsevejledning Rapporten er opdelt i to dele, hvor første del er selve hovedrapporten, mens anden del består af bilag. Denne opdeling er foretaget, for at øge læsevenligheden, da hovedrapporten kan læses samtidigt med at læseren kan orientere sig i bilag. Rapporten er bygget op omkring de klassiske UP discipliner: krav, analyse, design og implementation. Først og fremmest vil der være en indledning til projektets problemområde, samt den anvendte procesmodel. Efter dette følger selve resultatdelen, indeholdende de klassiske UP discipliner. Designdisciplinen er delt op i to afsnit. Først den generelle arkitektur og anvendte designmønstre med videre. Dernæst beskrives design af konkrete funktionaliteter i systemet. Efter implementationsdisciplinen beskrives test og statistik. Efterfølgende beskrives færdighedsgraden af det udførte arbejde, og der gøres rede for resterende arbejde. Afslutningsvis konkluderes der på projektet, hvorefter der følger en perspektivering. For at øge overskueligheden af rapporten, benyttes bestemte skrifttyper når der refereres til anvendte klasser, metoder og attributter: Klasser skrives som: klasse Metoder skrives som: metode Attributter skrives som: attribut Litteraturhenvisninger er skrevet på følgende form: Lit.[17] kap. 5.6, side 378 Hvor der henvises til side 378 i kapitel 5.6 i litteratur nummer 17 på referencelisten i kapitel 12 på side 51. Bilagshenvisninger er skrevet på følgende form: bilag 5 på side b5 Hvor der henvises til bilag 5 i bilagskompendiet på side b5. Fodnotenummerering starter fra nummer 1 i hvert kapitel. Brugsmønstre er skrevet på følgende form: brugsmønster #07 Køb af rejser Hvor der henvises til brugsmønster med ID 07 og titlen køb af rejser. Der findes en begrebsliste i bilag 3 på side b3. På den vedlagte cd findes alle de dokumenter der er relevante for projektet, der er en oversigt over hvad cd en indeholder i appendiks?? på side??. 7

11 2. Indledning ETC er et fiktivt datterselskab af et større engelsk firma der varetager en stor del af den interne trafik i England. ETC vandt statens udlicitering af togdrift, som eneste togoperatør vest for Storebælt. ETC ønsker at optimere sine salgskanaler med baggrund i en generelt alt for lille rentabilitet. ETC s salgskanaler omfatter betjente salgssteder, callcentre, netbutik, salg i tog og ca. 500 billetautomater. Det er ETC s mål at udvide salgskanalernes tilgængelighed samt at optimere de 500 billetautomater. ETC ønsker yderligere en let tilgængelig bestilling af billetter via mobile enheder. Dette tilgodeser både kunder og ETC s billetkontrollører. De 500 billetautomater, der er placeret på togstationerne rundt om i landet, er af forskellig oprindelse og dyre at vedligeholde. ETC ønsker derfor at alle billetautomater udskiftes med nye billetautomater, samt at de automatisk kan opdateres fra centralt hold. I bilag?? på side?? forefindes inceptionsdokumentet for ETC billetautomater. Et uddrag af semesterhåndbogen, for 4. semester datateknologi/robotteknologi, findes i bilag?? på side??, der beskriver de faglige mål med projektet. 2.1 Problemstilling ETC har ud fra det fremstillede inceptionsdokument ETC Billetautomater, forventning om at få fremstillet et IT-system, der kan promoverer deres salgskanaler, samt give større tilgængelighed og lettere betjening. Der forventes to nye elektroniske kanaler, billetautomater og mobile enheder, med hver deres specialisering. Billetautomaterne vil forefindes på samtlige stationer og afspejle det lokale salg i form af kvik-køb s billet til de ti mest benyttede stationer. Billetautomaterne skal have en høj oppetid, fungere uafhængigt af ETC s centrale datanet og det skal være muligt at vælge mellem forskellige sprog. De mobile enheder skal ses som et supplement, og disse forventes desuden at blive brugt af togkontrollørerne i en nærmere fremtid. Det er højt prioriteret fra ETC s side, at der leveres et IT-system, som fra centralt hold kan overvåge, opdatere og modtage data fra billetautomaterne. Overvågningen skal bl.a. kontrollere billetautomaternes driftstatus. Det er et krav, at alle billetautomaterne kan opdateres samtidigt med nyt salgsprogrammel og takstdata. Det forventes at billetautomaterne akkumulerer og videresender salgstal til senere forretningsorienterede statistiske mål. Desuden forventes det at systemet kan arbejde sammen med lokale trafikselskabers systemer, således det bliver muligt at købe rejser som involverer brug af lokale trafikselskaber. Brugsmønstermodellen (se figur 5.1 på side 18) giver et umiddelbart indblik i det ønskede system. 2.2 Problemformulering Der ønskes fremstillet et IT-system, som har en bæredygtig softwarearkitektur, med mulighed for at fjernopdatere klienter fra centralt hold. Systemets væsentligste funktionalitet, vil være at kunne udstede togbilletter, dette skal også kunne lade sig gøre uden at der er netværksforbindelse til det centrale databasesystem. IT-systemet på billetautomaterne ønskes fremstillet, således at det er muligt at vælge mellem forskellige sprog. 8

12 2.3 Projektafgrænsning Hensigten med projektet er at udvikle en softwareprototype til afvikling på almindelige PC er. Prototypen vil demonstrere væsentlige aspekter af IT-systemet. Det vurderes at projektet har et omfang, der gør en afgrænsning nødvendig for at overholde projektets tidshorisont. Ved at sammenholde de ikke funktionelle krav, der har høj risiko og stor arkitekturmæssig signifikans, med den læringsmæssige interesse, er følgende krav fra faktortabelen(se bilag?? på side??) udvalgt: F1 Hændelseslog F2 Dagsummer U3 Sprog R1 Drift ved systemnedbrud og lignende P1 Samtidig anvendelse af flere automater S3 Softwarestyring på automat Krav med lav succesprioritet fravælges, da de ikke er essentielle for en repræsentiv prototype i forhold til ETC s ønsker. De udvalgte krav afdækkes i en vis udstrækning af brugsmønstrene markeret med gråt i tabel 2.1. ID: Brugsmønster 01 Start opdatering af klient-software og data 02 Opsætning af konfigurationsfil 03 Opdatering af software på billetautomater 04 Opdatering af data på billetautomaterne 05 Valg af sprog på billetautomat 06* Hjælp og vejledning 07* Køb af rejser 08* Almindeligt køb af billet 09* Kvik-køb af billet 10 Pladsbestilling 11* Afhentning af bestilte varer 12* Annullering af bestilte varer 13* Betaling 14* Udstedelse af tilgodebevis 15 Indrapportering af logning vedrørende billetsalg 16 Tilføjelse af sprogpakke på billetautomat 17 Fjernelse af sprogpakke fra billetautomat 18 Ændring af sprogpakke 19 Generer ledelsesstatistik Tabel 2.1: Oversigt over de brugsmønstre der vedrører emner som ønskes behandlet(markeret med gråt). De ID-numre der er markeret med *, er behandlet i inceptionsdokumentet Funktionaliteter som eksempelvis betaling og inddragelse af andre regionale trafikselskabers systemer udelades, idet disse vil være for omfattende af hensyn til projektperiodens længde. I bilag 6 på side b10 ses en kravsporingsmatrice, hvor de valgte krav og brugsmønstre er markeret. Det vurderes at de valgte brugsmønstre giver en fornuftig dækning af de udvalgte 9

13 krav. 2.4 Mål og forventede resultater Målet med projektet er, at der bliver udarbejdet en prototype ud fra de valgte brugsmønstre, på baggrund af de ikke-funktionelle krav. Systemet skal være distribueret, og der skal anvendes statistiske modeller i forbindelse med softwareløsningen. Der er fokus på design af en forståelig, vedligeholdelsesvenlig og skalerbar softwarearkitektur. I forbindelse med arkitekturmæssige valg, stræbes der efter at dokumentere fordele og ulemper, samt eventuelle mulige alternativer. ETC s mål med det udviklede system er, at aflaste de betjente salgssteder og øge servicen på ubetjente stationer. Billetautomaterne skal være nemme at vedligeholde for ETC s personale, og enkle for brugerne at benytte. Dermed forventes både semestermålene og ETC s mål opfyldt. 10

14 3. Procesmodel Til projekstyring og planlægning er der overordnet anvendt den agile udviklingsmetode scrum. Scrum er anvendt i kombination med UP. I det følgende vil der blive redegjort for de to udviklingsmetoder, og hvordan disse kombineres. Efterfølgende vil den foretagede planlægning og det faktiske forløb blive beskrevet. Slutteligt vurderes valget af procesmodel. 3.1 Anvendt procesmodel Scrum er en iterativ udviklingsmetode som ikke definerer hvilke discipliner, der skal gennemføres og i hvilken rækkefølge. Dette gør scrum yderst fleksibel, og betyder at scrum nemt kan tilpasses forskellige projekter. Scrum bygger på håndtering af krav og planlægning af udviklingsarbejdet. Scrum fokuserer på at krav ikke ligger fast ved starten af et projekt, men løbende udvikles. Specielt for scrum er at udviklingsarbejdet kan udføres i mindre hold, at der er fleksible tidsplaner, og at der udføres hyppige reviews. Arbejdsgangen for scrum er vist på figur 3.1(a). Udover at benytte scrum, vil også UP blive benyttet. En figur der illustrerer UP-metodikken er vist på figur 3.1(b). (a) Oversigt over tankegangen i scrum. (b) Oversigt over arbejdsmængden i forskellige faser og discipliner i Unified Process. Figur 3.1: De to systemudviklingsmetoder, UP og scrum. Et sprint i scrum, vil mere eller mindre svare til en iteration i UP, hvor UP-disciplinerne vil 11

15 blive gennemført på de funktionaliteter, som er angivet i sprint backloggen. Til hvert sprint udfærdiges en sprint backlog, der definerer de opgaver og krav som forventes værende opfyldt efter sprintet. Sprint backloggen udfærdiges ved at tage en delmængde af de krav, som er angivet i product backloggen, og tilføje disse til sprint backloggen. Product backloggen indeholder samtlige krav til systemet, og håndteres af systemets ejer. Sprint backloggen ligger fast under et sprint, mens product backloggen løbende kan ændres. I de enkelte sprints, vil det være elaborationsfasen fra UP, som vil blive bearbejdet, idet formålet med udviklingsarbejdet er at lave en prototype, samt at opbygge en robust softwarearkitektur. Da der benyttes UP, vil projektet være risikostyret, arkitekturcentrisk og brugsmønsterorienteret. Dette vil komme til udtryk i de prioriteringer, der laves for krav, brugsmønstre, sprint backlogs med mere. Til en udviklingsgruppe er der i scrum tilknyttet en scrum master. Dennes rolle er at bevare overblikket over udviklingsforløbet, samt at fjerne de forhindringer der opstår for de enkelte udviklere under udviklingsforløbet. Scrum masteren sørger for at principperne i scrum overholdes, og er mødeleder ved de daglige scrum møder. De daglige scrum møder har til formål at orientere hele udviklingsgruppen om hvad der er lavet siden i går, hvad der skal laves i løbet af dagen, samt hvilke problemer og hindringer der måtte være. 3.2 Faktisk forløb Første skridt i anvendelsen af scrum, er at udfærdige en product backlog. Product backloggen er udfærdiget ud fra samtlige brugsmønstre og krav, se bilag 7 på side b11. Sprint backloggen, for de forskellige sprints, er planlagt ved prioritering af product backloggen ud fra de fire faktorer: arkitekturmæssig betydning, risiko, faglig dækning og gruppens interesseområder. Sprint backlogs for de tre sprints er vist i bilag 8, 9 og 10 på side b12, b13 og b14, hvor der også er vist grafer over forløbet af hvert enkelt sprint. Overordnet er der angivet brugsmønstre i sprint backlogs, idet UP er brugsmønsterorienteret. Under hvert brugsmønster er specificeret hvilke ikke-funktionelle krav der forventes opfyldt i det givne sprint, samt discipliner og andre arbejdsopgaver. Hvert sprint i scrum startes med et møde hvor planlægningen af sprintet foregår, og sprint backloggen udfærdiges. Hvert sprint har i projektet haft en længde som har været bestemt af den øvrige undervisning på studiet. Der har i alt været planlagt tre sprints i projektperioden: Sprint 1 Har fokuseret på billetkøb på billetautomat, samt sprogunderstøttelse og databaseunderstøttelse lokalt på billetautomat. Sprint 2 Har fokuseret på tilføjelse af netværkskommunikation, og opdeling i server og klient, samt dynamisk opdatering af data og software. Databaseunderstøttelsen er flyttet til serverdelen. Desuden er der her blevet tilføjet mulighed for flere typer køb: normalt køb og kvik-køb. Ved slutningen af sprintet er der udført review af primært sprog- og netværksløsning. Sprint 3 Har fokuseret på opnåelse af de statistiske mål med projektet. Der er her udført statistik på behandlingstiden af logning af et køb, for at kunne vurdere om det udviklede system er robust nok til at håndtere mange samtidige køb. Dette udgør således performance test af prototype arkitekturen. I starten af hvert sprint er udført kravarbejde. Dernæst er analysearbejdet og udfærdigelsen af grundliggende retningslinier for softwarearkitekturen udført (så vidt muligt i fællesskab). Hvorefter design, implementation og eventuelt test er udført mere selvstændigt (i enten tomandsgrupper eller individuelt). 12

16 Efter hvert sprint bør eventuelt resterende arbejde føres tilbage til product backloggen, hvor der udføres en ny prioritering og udvælgelse af krav til næste sprint backlog. I praksis er resterende arbejde dog ført direkte videre til næste sprint backlog. Rollen som scrum master har skiftet ved hvert sprint, således tre har haft mulighed for at prøve rollen som scrum master. I scrum holdes der normalt et dagligt scrum møde, hvilket der især i første del af projektperioden, ikke blev gjort i praksis. Dette skyldes at der her har været forholdsvist korte arbejdsdage, og at der derfor ikke har været brug for et scrum møde så ofte. I sidste del af projektperioden har scrum mødet dog fundet sted oftere. I bilag 11 på side b15 ses tidsplanen for projektet, hvor det fremgår at projektet især sidst i perioden er skredet en smule i forhold til det oprindelig planlagte. 3.3 Vurdering af procesmodel Den valgte procesmodel har en række fordele og ulemper. Hvis et projekt har krav som ikke ligger fuldstændig fast fra projektets begyndelse, vil det være en fordel at benytte scrum, idet scrum giver mulighed for at prioritere krav på ny, ved indgangen til hvert sprint. Scrum giver et godt indblik i hvor mange timers arbejde der er tilbage i et sprint, idet det resterende arbejde estimeres. Dette kræver selvfølgeligt at den enkelte udvikler kan lave et pålideligt tidsestimat. Scrum er anvendeligt til at opdele et stort projekt i mindre dele, således flere seperate udviklingsgrupper kan arbejde på det samme projekt. Ved anvendelse af scrum, sikres det at hele projektgruppen løbende er orienteret om status på projektet, de nuværende forhindringer, og de arbejdsopgaver der ligger forude. Hele gruppen er orienteret om hvad andre laver, idet der holdes et dagligt møde. Hvis et medlem af gruppen har et givent problem, som forhindrer det videre arbejde, bliver dette klargjort forholdsvist hurtigt. Således kan der træffes beslutning, om der skal tilføres flere resourcer, eller opgaven skal opgives. Dette sikrer at en mindre gruppe ikke sidder fast med et problem i lang tid, og derved bruger resourcer forgæves. Hvis der opstår mange ændringer eller tilføjelser til product backloggen, kan dette give problemer, idet projektets tidshorisont kan stige dramatisk. 13

17 4. Indledning til resultater I de følgende kapitler vil resultatdelen af dette projekt blive behandlet. Nedenfor beskrives det bearbejdede i projektet samt i hvilken grad det er medtaget i rapporten. Det anbefales at se brugsmønsterdiagrammet 18. Brugsmønster #03 Opdatering af software på billetautomater, er blevet bearbejdet hvad angår krav-, analyse-, design- og implementationsdisciplinen. Dette brugsmønster er, hvad angår krav, beskrevet i afsnit 5.4 på side 21. Brugsmønster #04 Opdatering af data på billetautomaterne, er blevet bearbejdet hvad angår krav-, analyse-, design- og implementationsdisciplinen. Dette brugsmønster beskrives ikke i denne rapport. Det er muligt at opdatere sprog, stationer, kundekategorier og priser fra centralt hold. Brugsmønster #05 Valg af sprog på billetautomat, er blevet bearbejdet hvad angår krav-, analyse-, design- og implementationsdisciplinen. Designdelen for dette brugsmønster er delvist beskrevet i afsnit 7.3 på side 36. Brugsmønster #07 Køb af rejser, er blevet analyseret, men da dette brugsmønster udvides af en række brugsmønstre(heriblandt #08 og #09), er det disse som der er arbejdet videre med. Dette brugsmønster beskrives i afsnit 5.3 på side 17 for krav og analyse. Brugsmønster #08 Almindeligt køb af billet, er blevet bearbejdet hvad angår krav-, analyse-, design- og implementationsdisciplinen. Dette brugsmønster er beskrevet i afsnit 7.1 på side 31 og delvist i afsnit 8.1 på side 39, for henholdsvis design og implementation. Brugsmønster #09 Kvik-køb af billet, er blevet bearbejdet hvad angår krav-, analyse-, design- og implementationsdisciplinen. Dette brugsmønster er ikke beskrevet i rapporten, da dette minder meget om brugsmønster #08. Brugsmønster #15 Indrapportering af logning vedrørende billetsalg, er blevet bearbejdet hvad angår krav-, analyse-, design- og implementationsdisciplinen. Designdelen for dette brugsmønster er beskrevet i afsnit 7.2 på side 33. Brugsmønster #19 Generer ledelsesstatistik, er blevet delvist bearbejdet hvad angår krav-, analyse-, design- og implementationsdisciplinen. Dette brugsmønster er ikke beskrevet i denne rapport. De følgende kapitler vil omhandle krav, analyse, softwarearkitektur, design, implementation samt resterende arbejde. 14

18 5. Krav og analyse Dette kapitel omhandler krav- og analysedisciplinen som de er bearbejdet i dette projekt. I forbindelse med kravdisciplinen, vises et uddrag af den benyttede faktortabel 1. I faktortabellen er kravene prioriteret efter FURPS+ 2. Derudover er der lavet et brugsmønsterdiagram, samt detaljerede brugsmønsterbeskrivelser for brugsmønstrene #07 Køb af rejser og #03 Opdatering af software på billetautomater. Brugsmønster #07 er valgt, da det er projektets bærende brugsmønster. Der er arbejdet videre på brugsmønsteret, som det er beskrevet i inceptionsdokumentet (se bilag?? på side??). Brugsmønster #03 er valgt, da dette senere har betydning for hvordan systemet distribueres. For analysedisciplinen er der udført navne- og udsagnsordsmetoden 3, på brugsmønsterbeskrivelserne. Ud fra denne metode er der dannet et grundlag for at lave et analyseklassediagram (se bilag?? på side??). 5.1 Uddrag fra faktortabel Da ikke alle krav opfyldes i prototypen af ETC Billetautomater, er valgt at vise de krav, som er opfyldt eller delvist opfyldt, se nedenstående tabel??. Der er valgt at vise de krav, som bearbejdes i forbindelse med brugsmønster #07 Køb af rejser, som er det bærende brugsmønster for systemet. Hele faktortabellen kan ses i bilag 5 på side b5. F2 Dagsummer At kunne registrere billetautomaters omsætning (dagsummer) og betalinger centralt. Se specifikke krav på side 18 og 25 i inceptionsdokumentet (bilag??). Betydning Stor betydning for ETC, i forbindelse med sikkerhed og dokumentation af betalinger. Mellem betydning for softwarearkitektur. igen er forbindelse. Se F1 Hændelseslog. Vigtigt for ETC i forbindelse med bogføring. Mellem betydning for softwarearkitektur. Faktor og Kvalitetsscenarie Fleksibilitet og fremtidig udvikling Funktionalitet (Functionality) F1 Hændelseslog Hændelseslog for billetautomater Det skal være muligt gemmes i en log på billetautomaten så vidt også muligt i at se alle det centrale database- transaktioner i forbindelse system. Er der ingen med et rejsekøb forbindelse til dette og tidspunktet for disse system, gemmes log- transaktioner. gen lokalt indtil der Succesprioritet Høj Høj Risiko Middel Middel Fortsættes.. 1 En faktortabel bruges til at holde styr på ikke-funktionelle krav - Lit.[? ] kap.33, side Lit.[2] kap.8.4,side Lit.[1], kap.8.4 side

19 U4 Kort ekspeditionstid Ekspeditionstiden skal være kort, men ikke nødvendigvis ens per ekspedition. Dette løses vha. #09 Kvik-køb af billet. Kvik-købsbillet skal kunne gennemføres, til betaling, ud fra højst to valg. U6 Destinationer Destinationen kan på skærm vælges fra en oversigt Kunden skal kunne over de ti mest brugte angive sin destination ved valg af stationsnavn. destinationer. Ønskes andre stationer vil der Destinationen være mulighed for at kan fx vælges ud fra vælge et begyndelsesbogstav, en alfabetisk liste og dernæst hvor de ti mest benyttede den ønskede station. destinationer står øverst. Pålidelighed (Reliability) Betydning Vigtig for ETC i forbindelse med logning og opsætning af billetautomater. Lille softwarearkitekturmæssig betydning. Det er vigtigt for kundevenligheden i ETC, at det er muligt at vælge flere forskellige sprog. Det er vigtigt at tage højde for valg af forskellige sprog i forbindelse med udarbejdelse af softwarearkitektur. Meget vigtigt for ETC, da kundernes ventetid skal forsøges minimeret mest muligt. Softwarearkitekturen skal således give anledning til en fornuftig ydeevne i systemet. Vigtig for ETC, i forbindelse med hurtig og effektiv udnyttelse af billetautomater. Af mindre betydning for softwarearkitektur. Faktor og Kvalitetsscenarie Fleksibilitet og fremtidig udvikling F3 Stamoplysninger Dette er nødvendigt at implementere for For hver billetautomat at kunne lave fyl- skal det være destgørende logning, muligt at angive samt sikre billetautomatens en række stamoplysninger: almindelige gyldighedsperiode, funktionalitet. region, samarbejdspartnere, betalingskorttyper, billetautomatnummer, pinkodeterminalnr., billetautomat tlf. nr., stationsnr. Se side i inceptionsdokumentet (bilag??). Anvendelighed (Usability) U3 Sprog Der vil være mulighed Kunden skal kunne for valg af dansk, vælge mellem dansk engelsk eller tysk, (standard), engelsk eller samt opdatering af tysk. Der skal være sprog. Senere vil det mulighed for udvidelse med stor sandsynlig- til valg mellem flere hed være nødvendigt sprog. at tilføje mulighed for tilføjelse, ændring og fjernelse af sprogpakker. Succesprioritet Risiko Høj Lav Middel Middel Høj Middel Høj Lav Fortsættes.. 16

20 Faktor og Kvalitetsscenarie Fleksibilitet og fremtidig udvikling R1 Drift ved systemnedbrud Systemet implemente- og res så det er muligt lign. at købe billet ved systemnedbrud. Billetautomaten skal kunne sælge billetter når der mangler forbindelse til det centrale databasesystem, ved lange svartider el.lign. Efter forbindelsen er genetableret, skal nødvendige transaktioner til det centrale databasesystem gennemføres. Ydeevne (Performance) P1 Samtidig anvendelse Det sikres at systetautomater af flere billemet kan håndtere flere samtidige billetautomater. Flere billetautomater Samtidigt skal skal samtidigt kunne systemet være så effektivt, anvendes og indrapportere at der ikke op- til det centrale står ventetid ved man- databasesystem. ge samtidige brugere. Der må i den forbindelse ikke opstå ventetid. Betydning Meget vigtigt for kundevenlighed, og sikkerhed. Stor betydning for softwarearkitektur. Meget vigtig for ETC. Meget vigtigt for softwarearkitektur. Integration, vedligeholdelse og flytbarhed (Supportability) S1 Fremtidig variation af Køb af Rej- at opdatere disse data Det vil være muligt Meget vigtig for ETC. se fra centralt hold. Meget vigtigt for #07 Køb af rejser softwarearkitektur. skal kunne ændres, fx mht. destinationer, billettyper, kundekategorier og lign. Succesprioritet Høj Høj Høj Risiko Høj Høj Høj 5.2 Brugsmønsterdiagram Der er lavet et brugsmønsterdiagram (se figur 5.1) for at give et overblik over hvilke brugsmønstre dette projekt indeholder. På brugsmønsterdiagrammet er nogle af brugsmønstrene markeret med gråt, hvilket betyder at disse er blevet bearbejdet i forbindelse med projektet. 5.3 Brugsmønster #07 Køb af rejser Bearbejdningen af brugsmønster #07 Køb af rejser, omhandler brugsmønsterbeskrivelse for et generelt køb af en billet, uanset om det foregår via en billetautomat, internet-browser eller en mobil enhed. I forbindelse med brugsmønster #07 Køb af rejser, er brugsmønstrene #08 Almindeligt køb af billet og #09 Kvik-køb af billet også bearbejdet, disse kan ses i bilag 13 på side b22. 17

21 Figur 5.1: Brugsmønsterdiagram. De brugsmønstre som er grå, er blevet bearbejdet. Brugsmønster: Køb af rejser ID: 07 Formål: At købe en eller flere billetter. Oversigt: En salgsterminal (såsom en billetautomat) kan benyttes til køb af en rejse. Købet af en rejse kan fx bestå i et enkeltstående køb af en billet, men kan også være sammensat af flere uafhængige delkøb. De forskellige typer af køb er beskrevet i brugsmønstrene #08 Almindeligt køb af billet, #09 Kvik-køb af billet, #10 Pladsbestilling, #11 Afhentning af bestilte varer, #12 Annullering af bestilte varer, #13 Betaling og #14 Udstedelse af tilgodebevis. Når en kunde har bestemt sin rejse, præsenteres den samlet for kunden til godkendelse, hvorefter betalingen gennemføres. Som afslutning får kunden udleveret det eller de købte produkter. Primære aktører: Kunde. Sekundær aktører: PBS. Interessenter: Kunde: Ønsker at købe en billet. ETC: Ønsker at aflaste de betjente salgssteder ved at tilbyde billetkøb ved selvbetjening, samt at tilbyde billetsalg på ubemandede stationer via billetautomater. Prækondition: Ingen. Fortsættes... 18

22 Postkondition: Kunden har fået udleveret det ønskede produkt. Systemet har registreret transaktionen. Aktør 1. Kunden ønsker at købe en billet. System 2. Systemet præsenterer kunden for forskellige valgmuligheder: Kvik-køb, almindeligt køb, forudbestilte varer og vejledt hjælp. 3. Kunden vælger købstype. 4. Systemet præsenterer stationsvalg og anmoder om afrejsestation. 5. Kunden vælger en afrejsestation. 6. Systemet præsenterer stationsvalg og anmoder om destination. 7. Kunden vælger en destination. 8. Systemet registrerer destinationen og anmoder om rejsedato. 9. Kunden vælger en rejsedato. 10. Systemet registrerer rejsedato og anmoder kunden om at vælge billettype/pladsbestilling. 11. Kunden vælger billettype/- 12. Systemet viser kundens valg pladsbestilling og antal. og anmoder om godkendelse. 13. Kunden godkender køb. 14. Systemet anmoder om betaling. 15. Kunden betaler. 16. Systemet godkender betaling, registrerer transaktionen og udskriver billet. Alternative forløb: # Krydsreferencer: F1 Hændelseslog, F2 Dagsummer, U1 Effektiv betjening, U2 Personalisering, U3 Sprog, U4 Kort ekspeditionstid, U5 Betjeningsformer, U6 Destinationer på skærm, R1 Drift ved systemnedbrud og lignende, P1 Samtidig anvendelse af flere automater, S1 Fremtidig variation af Køb af rejse, +1 Software, +2 Løbende overførsel af data til et centralt databasesystem Iteration: 1 Status: Brugsmønstrene #10 Pladsbestilling, #11 Afhentning af bestilte varer, #12 Annullering af bestilte varer, #13 Betaling og #14 Udstedelse af tilgodebevis, forventes ikke at blive bearbejdet. Kommentarer: Det tænkes muligt at gå tilbage til forrige trin og foretage nye valg. 19

23 5.3.1 Klasser og metoder Der er anvendt navne- og udsagnsordsmetoden 4 på brugsmønsterbeskrivelsen, for at finde repræsentative klasser og attributer (se tabel 5.5), samt metoder (se tabel 5.6), der afspejler forretningsgangen i problemdomænet. På analyseklassediagrammet (se bilag?? på side??) er kun medtaget de klasser, attributter og metoder, som er nødvendige jf. projektafgrænsningen i afsnit 2.3 på side 9. Navneord Klasse/attribut Navn i diagram Salgsterminal/Billetautomat Pakke TicketMachine Køb Klasse Purchase Delkøb Klasse SubPurchase Købstyper Attribut typeofpurchase Kunde Klasse CustomerSession System - - Produkt - - Salgstransaktion Klasse SaleTransaction Kvik-køb Klasse QuickPurchase Almindeligt køb Klasse OrdinaryPurchase Forudbestilte varer Klasse BookedPurchase Pladsbestilling Klasse SeatReservation Stationer Klasse Station Afrejsestation Attribut departurestation Destination Attribut destinationstation Antal (generel attribut for fx billet og plads) Attribut numberof- Rejse (se delkøb) - - Betaling Klasse Payment Gyldighed (periode) Attribut validity Tid (dato og klokkeslet) Attribut datetime Pris Attribut ticketprice Tabel 5.5: Navneord for brugsmønster #07 Køb af rejser. Den grå markering er benyttet for overskuelighedens skyld. Udsagnsord Metode Navn i diagram Køb af rejse Metode buytrip Godkend rejse/køb Metode acceptpurchase Betal Metode paytrip Udlevering af produkt Metode deliverproduct Registrer transaktion Metode recordtransaction Præsentation af købsmuligheder Metode showpurchasemethod Vælg købsmulighed Metode choosepurchasemethod Præsentation af stationer Metode showstation Vælg afrejsestation Metode choosedeparturestation Vælg destination (se vælg afrejsestation) Metode choosedestinationstation Vælg billettype/pladsbestilling Metode choosetickettype Vælg antal Metode choosequantity Godkend betaling Metode acceptpayment Annuller køb Metode cancelpurchase Fortsættes... 4 Lit.[1], kap. 8.4, side

24 Udsagnsord Metode Navn i diagram Nulstilling af valg Metode resetchoices Vis hovedmenu Metode showmainmenu Udregn pris Metode calculateprice Tabel 5.6: Udsagnsord for brugsmønster #07 Køb af rejser. Den grå markering er benyttet for overskuelighedens skyld. Klassen CustomerSession repræsenterer funktionaliteten i brugsmønster #07 Køb af rejser. Den indeholder derfor metoder til at sammensætte en billet ud fra de valg kunden kan foretage (såsom stationer og antal). CustomerSession repræsenterer én kundes brug af billetautomaten. Klassen Purchase holder styr på de enkelte billetkøb, samt om der foretages et kvik-køb eller et almindeligt køb. 5.4 Brugsmønster #03 Opdatering af software på billetautomaterne Analyse af brugsmønster #03 Opdatering af software på billetautomater, er lavet ud fra inceptionsdokumentet (se bilag?? på side??) og kravene givet deri. Brugsmønster: Opdatering af software på billetautomaterne ID: 03 Formål: At kunne opdatere softwaren på billetautomaterne, samt udrulle softwaren på nye billetautomater. Oversigt: Administrator kan initialisere opdatering af software fra den centrale server. Herefter vil billetautomaterne hente den nye software og installere denne. Installationen af ny software sker i tidsrum hvor billetautomaten ikke benyttes. Efter installationen startes billetautomaten op med den nye software. Primære aktører: Administrator. Sekundær aktører: Interessenter: Prækondition: Postkondition: Ingen. ETC: ønsker mulighed for at opdatere software på billetautomater fra centralt hold, da dette vil lette vedligeholdelsesarbejdet betragteligt. Ingen. Billetautomaten kører den nye software. Aktør 1. Opdateringen initialiseres af administrator. System 2. Serveren underretter alle forbundne billetautomater, om at ny software er tilgængelig. 3. Billetautomaterne sammenligner nuværende softwareversion med den tilgængelige softwareversion på serveren. Fortsættes... 21

25 Aktør System 4. Billetautomaterne henter den nye software og afslutter applikationen, som ønskes opdateret, på et tidspunkt hvor billetautomaten ikke benyttes. 5. Den nye softwareversion startes. Alternative forløb: Ingen. Krydsreferencer: R2 Driftssikkerhed, S1 Fremtidig variation af Køb af rejse, S2 Regional tilpasning, S3 Softwarestyring på automat, +1 Software Iteration: 1 Status: Analyse påbegyndt i 1. sprint. Kommentarer: Ingen. Ved brugsmønster #03 Opdatering af software på billetautomaterne, er tankerne at der indføres en TMManager (se figur 5.2), der er et selvstændigt program, som starter TicketMachine op. TMManageren, har mulighed for at starte og lukke TicketMachine, derudover har den mulighed for at hente ny software fra serveren. Den sidste funktion som TMManageren har, er en funktion til at spørge TicketMachine om den er klar, det vil sige ikke har igangværende CustomerSession. TicketMachine har attributten isidle, som benyttes til at give besked om at ingen CustomerSession er i gang. Hvis TMManageren har hentet en ny software version ned, spørges TicketMachine om den har nogen CustomerSession i gang, hvis ikke, svarer TicketMachine at den er klar til at blive opdateret. Når TMManager modtager dette svar, vil den lukke TicketMachine ned, og starte den nye version op. 5.5 Opsumering af krav og analyse Kravdisciplinen er meget vigtigt, da dette giver styrende input til hele projektfasen og anvendes som reference, til at styre softwarekonstruktionen i elaborationsfasen. Ved grundigt arbejde med at overholde og opfylde interesanternes krav, opnås en softwareløsning som kunden forventer den. Der er i dette kapitel arbejdet med krav vedrørende brugsmønstrene #03 Opdatering af software på billetautomater og #07 Køb af rejser. 22

26 TicketMachine Server TicketMachine SoftwareController isidle notifyacknowledge softwareupdatenotify getsoftware TMManager has Manager has main starttm closetm downloadsoftware notirytm Figur 5.2: Analyseklassediagram for brugsmønster #03 Opdatering af software på billetautomaterne. 23

27 6. Softwarearkitektur I dette kapitel gennemgås de overvejelser, der er gjort for softwaredesignet af ETC s billetautomater, og den bagvedliggende arkitektur. Den valgte softwarearkitektur vil blive gennemgået, samt alternativer, der kunne have været anvendt. Det vil også blive beskrevet hvad der er gjort for at opretholde den valgte arkitektur. 6.1 Grundlæggende struktur Det er valgt at lave en klient/server struktur med salgsautomater på stationerne og en server i ETC s center. Der er derfor valgt at opdele systemet i tre hoveddele: TicketMachine og TMManager på billetautomaten, samt en Server-del, hvilket kan ses på figur 6.1. TMManager Server TicketMachine Billetautomat TMManager Intranet Applikationsserver TicketMachine Billetautomat MySQL-databaseserver Figur 6.1: Oversigt over netværksarkitekturen for ETC s billetautomatsystem. TicketMachine er det software, som indeholder den grafiske fremstilling til kunderne, de funktionaliteter, der skal bruges for at foretage et billetkøb og metoder til at gemme salgsoplysninger. TMManager er et program, der kører på billetautomaten hele tiden, og som sørger for at opdatere til nye softwareversioner og genstarte TicketMachine-applikationen. Serverdelen skal kunne distribuere opdateringer til billetautomaterne, vise ledelsesstatistik, samt indeholde en database med de oplysninger, som billetautomaterne skal bruge (stationsog prisoplysninger) og kunne gemme salgsdata fra billetautomaterne. Der er valgt en PCMEF+ arkitektur, da der har været fokus på denne arkitektur i undervisningen 1. Derudover er der valgt en klient/server arkitektur, hvor der benyttes PCMEF+ på klienten (TicketMachine), og hvor der på TMManager og Server benyttes en forsimplet PCMEF+ arkitektur, dette fremgår af bilag 15 på side b26. Distribueringsgraden er en 3-tier klient/server arkitektur, med distribueret applikationskerne og remote database 2, på overstående figur??, ses hvordan netværksstrukturen er tænkt. PCMEF+ arkitekturen har vise fordele, som beskrives i det følgende. PCMEF+ arkitekturen benytter sig af seks foruddefinerede pakker (se figur 6.2) med hver deres ansvarsområde. Al kommunikation mellem lagene, skal gå oppefra og ned, således at øvre lag er afhængige af lagene under sig. Presentation layer Er ansvarlig for al præsentation til brugeren, det er her GUI-objekter defineres. 1 Lit. [2] kap. 9, side Lit.[3] kap. 2.3, side

28 Figur 6.2: Oversigt over PCMEF+ arkitekturen. Control layer Håndterer Presentation-lagets forespørgelser, og skal holde styr på den igangværende brugers kundesession. Det er her at klasser, som er ansvarlige for brugerens interaktion (samspil med systemet), er defineret. Domain layer - Entity package Indeholder systemets forretningslogik/-objekter. Domain layer - Mediator package Er en slags formidler mellem Entity-pakken og Foundationlaget, samt en Facade-klasse ned til Foundation, således at Control-laget ikke skal have direkte forbindelse ned til Foundation-laget. Foundation layer Håndterer databaseforbindelse, netværksforbindelse og forbindelse til andre services som systemet ikke selv tilbyder (fx PBS). Acquaintance package Indeholder interfaces, således at et lag kan benytte services fra et ikke tilstødende lag. Ved at have interfaces samlet i én pakke udenfor resten af systemet, kan Neighbor Communication Principle 3 overholdes PCMEF+ principper Der er opstillet syv principper for PCMEF+ arkitekturen 4, hvis disse overholdes vil softwaren opnå en række ønskede egenskaber, nemlig forståelighed, vedligeholdelsesvenlighed og skalerbarhed. De syv principper er: Downward Dependency Principle (DDP) Højere liggende lag er afhængige af lavere liggende lag. Afhængigheder går oppefra og ned. Upward Notification Principle (UNP) Lavere liggende lag kan underrette om ændringer, således højere liggende lag kan ændre status, men samtidig kan overholde DDP. Til opfyldelse af dette princip er Observer-mønsteret velegnet (se afsnit 6.3 på side 27). Neighbor Communication Principle (NCP) Det er kun tilladt at kommunikere med nabo-lag, dvs. at kommunikation med andre lag end det underliggende ikke er tilladt. 3 Lit.[2] kap , side Lit.[2] kap , side

29 Explicit Association Principle (EAP) Afhængigheder mellem metoder bør gøres tydelige, det vil sige at metodeafhængigheder gøres til klasseafhængigheder. Referencer defineres som attributter i klassen, i stedet for lokale variabler i selve metoden. Cycle Elimination Principle (CEP) Cirkulære afhængigheder mellem lag, pakker eller klasser bør nedbrydes. Dette kan gøres ved at indføre en ekstra pakke, klasse eller et interface. Class Naming Principle (CNP) Når klasser navngives, skal det første bogstav i navnet svare til den pakke hvori klassen ligger, fx CActioner ligger i Control-laget. Interfaces navngives med I som begyndelses bogstav, efterfulgt af bogstavet for pakken hvori interfacet ligger, fx IALanguage er et interface, som ligger i Acquaintance pakken. Acquaintance Package Principle (APP) Acquaintance-pakken gør det muligt at kommunikere med lag som ikke er nabolag. Acquaintance-pakken giver mulighed for at eliminere cirkulære afhængigheder. Samt mulighed for at overholde EAP med hensyn til metodeafhængigheder mellem lag, som ikke er nabolag Alternative løsninger Figur 6.3: Oversigt over MVC arkitekturen. Et alternativ til den lagdelte arkitektur PCMEF+, er Model-View-Controller (MVC) arkitekturen (se figur 6.3). Hvor View svarer til et præsentations-lag, Model svarer til et domæne-lag og Controller forbinder de to andre lag. Det vil sige at en hændelse i fx View vil påvirke Controller, som vil påvirke Model, og på den måde opdatere programmet. MVC er ikke en ønsket arkitektur for dette projekt, da der ønskes stor mulighed for genbrug, nem vedligeholdelse og et let forståeligt program Designmål ved brug af PCMEF+ arkitektur Ved at anvende en lagdelt arkitektur kan en række fordele opnås. En af fordelene er at kompleksitet kan reduceres 6, da opgaver og ansvar fordeles i mindre dele. Det kan blive lettere at forstå systemet, hvis der er benyttet en lagdelt arkitektur, som overholder DDP. Grunden til det vil blive lettere at forstå, er at ansvarsfordelingen bliver naturlig, hvis DDP overholdes. En anden fordel er at der er stor mulighed for genbrug, databaseforbindelsen kan måske genbruges fra et tidligere projekt. Det kan også være hele komponenter, der ønskes genbrugt. Det vil derfor være en fordel at benytte Facade mønsteret, når der fremstilles komponenter, da dette vil lette muligheden for genbrug. Hvis NCP overholdes, vil arkitekturen betragtes som stabil. Stabilitet betyder man vil have 5 SOFT undervisningslektion 7 - SOFT7.pdf s. 4 6 SOFT undervisningslektion 1 - SOFT1.pdf s. 3,6,11,13 26

30 nemmere ved at vedligeholde et system, uden at påvirke det eksisterende. En lukket og streng arkitektur, er lettest at teste og udvikle, da ændringer i et lag har en begrænset og kontrolleret indvirkning på de øvrige lag. Dog er den lukkede arkitektur langsommere end den åbne arkitektur, men den åbne arkitektur kan være sværere at forstå, samt at teste og vedligeholde 7. I PCMEF+ arkitekturen giver Acquaintance-pakken mulighed for et kompromis mellem den åbne og lukkede arkitektur. 6.3 Nyttige designmønstre For at overholde arkitekturen kan designmønstre anvendes, de væsentligste beskrives kort her. UML diagrammer for de enkelte designmønstre kan ses i bilag 16 på side b29, dog er Data Transfer Object 8 undladt i dette bilag. Facade Facade mønsteret minimerer forbindelser mellem subsystemer, og der opnås dermed mindre kobling. Facade-klassen vil være den eneste klasse, i en pakke, som er tilgængelig fra andre pakker. En ulempe kan være at performance mindskes, da et metodekald delegeres gennem flere klasser. Abstract Factory Abstract Factory-mønsteret er anvendeligt, hvis der er flere implementationer af et interface (eller en abstrakt klasse). Abstract Factory giver mulighed for at vælge den implementation, som passer bedst som problemløsning. Det giver mulighed for dynamisk at vælge den implementation der ønskes. Chain of Responsibility Formålet med Chain of Responsibility er at undgå at koble afsenderen af et metodekald sammen med modtageren. Dette er specielt anvendeligt, hvis NCP skal overholdes. Kan bruges til at minimere koblingen internt i pakker. Observer Observer-mønsteret benyttes til at overholde UNP, da det gør det muligt at notificere klasser i overliggende lag, og derved have nedadgående afhængigheder og samtidigt overholde DDP. Kan benyttes til at minimere cirkulære afhængigheder. Dette mønster kaldes også publishersubscriber-mønsteret. Mediator Mediator-mønsteret varetager kommunikationen mellem Foundation og de øvrige lag. Fordelen er at pakker ikke har direkte adgang til Foundation, men at al kommunikation går gennem Mediator, eller formidleren som den også kaldes. Dette giver en afgrænsning i systemet, der fjerner mange-til-mange relationer. Data Transfer Object Data Transfer Object-mønsteret aflaster netværket, da data samles i ét objekt inden de overføres, frem for at lave mange individuelle kald over netværket. 7 SOFT undervisningslektion 1 - SOFT1.pdf s [10] URL[ 27

31 6.4 Distribuering af system Det har fra ETC s side været et krav at billetautomater skal kunne fungere offline, samt at software og data skal kunne håndteres fra centralt hold. Softwaren til billetkøb, var derfor tænkt som en ikke-distribueret løsning. Til synkronisering af software og data, kunne der benyttes en ekstra applikation. Denne applikation ville så stå for kommunikationen med serveren. Dette kunne dog ikke stemme overens med de, i semesterhåndbogen (se bilag?? på side??), stillede krav omkring en distribueret software løsning, og der er derfor lavet et kompromis. Figur 6.4: Oversigt over forskellige distribueringsmønstre. Distribueringsmønsteret er valgt som en distribueret applikationskerne, med en remote database, se figur 6.4. Da der jf. krav +1 Software, skal benyttes en MySQL database, vil distribueringsgraden mellem databaseserver og applikationsserver, blive remote database (se figur 6.1 på side 24). Figur 6.5: Oversigt over forskellige distribueringsformer og deres påvirkning. Den distribuerede applikationskerne har både fordele og ulemper, hvilket også kan ses på figur 6.4. Kompleksitet Vil være høj, da systemets forretningslogik skal fordeles ud i flere forskellige applikationer på en sikker og forsvarlig måde. Sikkerhed Systemet vil være mere åbent overfor angreb, når der benyttes en distribueret applikationskerne, end ved de andre distribueringsmønstre. For at opnå en bedre sik- 28

32 kerhed er det valgt at benytte SSL, i forbindelse med kommunikationen mellem klient og server, se appendiks A.2 på side 53. Konsistens Jo større mængder af data, der ligger hos klienterne, des større er risikoen for at data er inkonsistente. Derfor bør der indføres nogle opdateringsmekanismer, der kan håndtere dette. For at opnå konsistens i data, er der benyttet et observer mønster, mellem klient og server, hvor serveren fungerer som publisher. Dette opfylder kravet S3 Softwarestyring på automat. Genbrug Hvad angår genbrugelighed, er den stor, da man kunne forestille sig at databaseserveren kunne blive genbrugt af flere klienttyper, fx mobile enheder og andre salgskanaler. Det samme gælder domænelogikken, hvor det fx kunne være prisberegninger, som kunne genbruges af andre systemer (fx til en web-applikation). Distribueringsomkostninger Ved at have softwaren samlet centralt, behøves ikke så kraftige klienter, til at køre klientsoftwaren. Med en distribueret applikationskerne kræves der mere af klienterne. Opdatering af klientsoftwaren besværliggøres også, hvis der benyttes en distribueret applikationskerne. Dette er løst ved at indføre en manager til hver af billetautomaterne, og igen benytte et observer mønster. Dette opfylder kravet S3 Softwarestyring på automat. Afviklingsform Da klienten har store dele af funktionaliteten liggende lokalt, vil størstedelen af funktionaliteten også kunne benyttes offline. Det betyder også at klienter ikke er så afhængige af at have en hurtig netværksforbindelse, men til gengæld kræver mere processorkraft. Da klienten ikke er så afhængig af netværksforbindelsen, vil der være mulighed for at gøre systemet mere interaktivt, end fx en distribueret præsentationsløsning. Det er vigtigt for ETC at billetautomaten kan fungere offline jf. krav R1 Drift ved systemnedbrud og lignende. Ydeevne Hvis distribueringssnittet er lagt uhensigtsmæssigt, vil det give anledning til flaskehalse på serveren, derfor bør snittet laves, således der er minimal kobling mellem klient og server. For at minimere netværkstrafikken, benyttes et Data Transfer Objectmønster, samt et Remote Observer-mønster, således at klienterne får besked om opdateringer og ikke hyppigt skal spørge efter nye opdateringer Netværkskommunikation Til kommunikation mellem billetautomater og server, kan benyttes én af to transportlagsprotokoller UDP eller TCP. UDP er en upålidelig, forbindelsesløs service, mens TCP omvendt er pålidelig og forbindelsesorienteret 9. Da det er ønsket at data bliver overført fejlfrit og uden tab, vælges protokollen TCP til netværkskommunikationen. Til netværkskommunikation med TCP kan benyttes tre teknikker kendt i Java: Sockets, Servlets og RMI (Remote Method Invocation). Servlets egner sig bedst til webapplikationer 10, mens sockets og RMI egner sig til brug ved almindelige applikationer. RMI kan benyttes til at overføre objekter direkte, såfremt implementationen forefindes på både klient og server 11. RMI kan benyttes til at kalde metoder direkte over netværk, RMI benyttes typisk lokalt på maskinen og/eller på lokalnetværk Lit.[5] kap , side KOM undervisningslektion 5, KOM5.pdf s Lit. [10] URL[ 12 KOM undervisningslektion 4, KOM4.pdf s. 2 29

33 Det er her valgt at benytte RMI som løsning, og det antages at servere og klienter er placeret på et lukket net (jf. figur 6.1 på side 24). RMI kræver typisk mere af netværksforbindelsen end Sockets, men er nemmere at benytte. Til filoverførsel, i forbindelse med opdatering af software, er det valgt at anvende sockets, idet sockets er mere velegnet til dette 13 end RMI. 6.5 Database design Der benyttes en relationel database (i dette tilfælde MySQL), hvilket betyder at klasser skal mappes til tabeller. Der ønskes et databasedesign, som afspejler forretningsmodellen, da dette vil lette behandlingen af data set fra softwaresiden. Dette kan opnås ved at benytte fremmednøgler hvor det er muligt. Derudover bør der benyttes triggers, hvor dette understøtter forretningsmodellen. Det er ofte klasser i Entity-pakken som ønskes mappet. Da der benyttes SQL-sætninger i softwaren, er det indlejret SQL der anvendes. Der benyttes en JDBC-driver, for at opnå adgang til databasen. Det er vigtigt at stjernenotationen (*) ikke benyttes ved select kommandoen 14, da der kan ske ændringer i tabeldesignet, og derved give andre oplysninger end forventet. 6.6 Opsumering af Softwarearkitektur Der er valgt en PCMEF+ arkitektur, som er beskrevet i det foregående og der er fundet nogle nyttige designmønstre, som kan hjælpe til at overholde PCMEF+ principperne. Ydermere er der valgt en 3-tier klient-/serverarkitektur, med en distribueret applikationskerne. Der er fundet nogle mekanismer til at forbedre udvalgte problemstillinger ved den valgte distributionsform. Til netværkskommunikation er der valgt TCP som transportprotokol, og anvendelse af RMI i forbindelse med udveksling af forretningsdata mellem klient og server. Sockets benyttes til filoverførsel ved opdatering af softwareversioner. 13 Lit.[10] URL[ 14 Lit.[2] kap , side

34 7. Design I dette kapitel vil arbejdet med designdisciplinen, for brugsmønstrene #08 Almindeligt køb af billet, #15 Indrapportering af logning vedrørende billetsalg og #05 Valg af sprog på billetautomat blive beskrevet. Brugsmønster #08 er valgt for at vise hvordan nogle af PC- MEF+ principperne (beskrevet i afsnit på side 25) er benyttet. Brugsmønster #15 er valgt, for at vise hvordan kommunikationen mellem klient og server tænkes lavet. Til sidst benyttes brugsmønster #05, for at vise hvordan en billetautomat vil kunne fungere offline, dog med begrænset funktionalitet. 7.1 Brugsmønster #08 Almindeligt køb af billet Der er valgt at fokusere på brugsmønster #08 Almindeligt køb af billet, da dette udvider brugsmønster #07 Køb af rejser, som er analyseret i afsnit 5.3 på side 17. Designklassediagrammet for brugsmønster #08, ses i figur 7.1. TicketMachine domain entity mediator acquaintance ETicket -departurestation -destinationstation -customercategorylist +ETicket() +createallcustomercategories() +setdeparturestation() +setdestinationstation() +getdeparturestation() +getdestinationstation() +incquantitycustomercategory() +decquantitycustomercategory() +getquantitycustomercategory() +getcustomercatergorynames() +getcustomercategoryprice() +gettotalticketprice() +gettripprice() +printticket() +storeticket() EPurchase -saledatetime: -ticketbasket: -currentticket: -typeofpurchase: +EPurchase() +setpurchasetype() +getcurrentticket() +gettypeofpurchase() +gettotalpurchaseprice() +endpurchase() +getsaledatetime() MStationHandler... -allstations -mostusedstationnames -customercategories -automatid... -addstation() -createallstationlist() -createmostusedstationlist() +getstation() +getallstations() +getallstationnames() +getmostusedstations() +createcustomercategories() +getcustomercategories() +gettripprice()... MDefaultSettings -thisstationname -thisautomatid -showstationamount -showstationsfordays... +getthisstationname() +getthisautomatid() +getshowstationamount() +getshowstationsfordays() IATicket +setdeparturestation() +getdeparturestation() +setdestinationstation() +getdestinationstation() +incquantitycustomercategory() +decquantitycustomercategory() +getquantitycustomercategory() +getcustomercategorynames() +getcustomercategoryprice() +gettripprice() +gettotalticketprice() ECustomerCategory EStation -customercategory -categoryquantity -categoryprice +ECustomerCategory() +incquantity() +decquantity() +getquantity() +getcustomercategory() +getcategoryprice() -stationname -zonenumber +EStation() +getthisstationname() +getzonenumber() Figur 7.1: Udsnit af designklassediagram, kun klasser som er medtaget i brugsmønster #08 Almindeligt køb af billet er vist Forklaring af benyttede klasser Klasserne i designklassediagrammet (se figur 7.1) er i det følgende beskrevet: EPurchase Repræsenterer køb, og kan indeholde flere billetter, med andre ord har den en liste med ETicket-objekter, listen ticketbasket. Et køb har et salgstidspunkt (saledatetime) samt en købstype som fx kan være quick eller ordinary. ETicket Repræsenterer en billet, med afrejsestation og destination, samt kundekategorier. Ved instantiering af et ETicket-objekt, hentes en liste fra MStationHandler, med alle definerede kundekategorier. Der oprettes et ECustomerCategory-objekt for hver kundekategori, som så knyttes til et ETicket-objekt. 31

35 En alternativ løsning kunne være, i stedet for ECustomerCategory-objekter, at benytte et 2-dimensionelt array, indholdende kundekategorier, pris og antal. ECustomerCategory Til hver billet er tilknyttet de forskellige kundekategorier der findes. Hver ECustomerCategory indeholder informationer om pris for den pågældende kategori samt kundens valgte antal personer. Designet er lavet således, at det er muligt at tilføje flere kundekategorier i databasen, hvorefter at disse kan benyttes i systemet uden at der skal ændres i koden. Hvert objekt indeholder en prisfaktor (categoryprice), men kan senere udvides til at indeholde anden information. EStation Det er valgt at repræsentere stationer som objekter, da dette gør det muligt at indkapsle stationsoplysninger (såsom zonenumber og stationname) i samme objekt. MDefaultSettings Hver billetautomat skal have nogle unikke egenskaber såsom id-nummer og navnet på den station hvor den står. Disse oplysninger gemmes i MDefaultSettings og kan så herfra tilgås fra andre klasser, fx skal stationsnavnet (thisstationname) bruges som afgangsstation ved billetkøb. MStationHandler Bruges til at holde styr på de forskellige EStation-objekter. Det er muligt at hente alle stationsnavne ud ved hjælp af metoden getallstationnames. MStationHandler sørger for at alle EStation-objekter instantieres. MStationHandler virker som en observer, således det er muligt at opdatere stationslisten ved notifikation fra Foundation, dette sikrer at DDP og UNP principperne overholdes (se afsnit på side 25). IATicket Dette interface er blevet designet for at undgå at EPurchase bliver en Facade klasse til ETicket. Interfacet giver samtidig en skarp grænseflade til, hvad man kan med et ETicket-objekt. Dette giver også mulighed for at benytte et ETicket-objekt i ikke tilstødende lag, idet APP princippet kan benyttes Overvejelser vedrørende brugsmønster #08 Udover at der er fundet designklasser, er der gjort nogle overordnede overvejelser, vedrørende brugsmønsteret. Billetkøb Forløbet i forbindelse med et billetkøb er forsøgt modelleret brugervenligt med henblik på hurtig betjening, således at et billetkøb kan foretages ud fra maksimum to valg inden betaling (se krav U4 i bilag 5 på side b5). Det er efter valg af destination, muligt at til-/fravælge antal billetter, ved henholdsvis aktivering af + eller - funktionaliteterne (se figur 7.2). Billettyper Softwareprototypen er kun tiltænkt håndtering af togbilletter, så derfor oprettes der ikke nogen generel billettype, som kan nedarves til tog-, bus-, færgebilletter med flere. På nuværende tidspunkt undlades dette, da det vil skabe mere forviring end gavn. Hvis det bliver nødvendigt vil det forholdsvist nemt kunne implementeres (antaget at billettyperne benytter samme IATicket-interface), da de andre klasser er sat op til at operere med, og på, et IATicket-interface. Prisberegning Der vil ikke blive opkrævet betaling ved køb af billetter, men der bliver beregnet en billetpris ud fra rejselængde, antal personer og kundekategori. Prisen for rejselængden findes ud fra differensen mellem to takstzoner, fremfor at lave database med priser i mellem alle de mulige stationskombinationer (høj kompleksitet med mange-til-mange relationer). Det ønskes altså kun vist, at der kan findes forskellige priser afhængig af stationsvalg og ikke en mere kompleks prismodel, der tager højde for forskellige krydsende togstrækninger. 32

36 Figur 7.2: Grafisk fremstilling af funktionaliteten til at til-/fravælge antal billetter Sekvensdiagram for brugsmønster #08 I figur 7.3 ses sekvensdiagrammet for brugsmønster #08 Almindeligt køb af billet, dette vil i den følgende blive forklaret. Til at starte med vælger en kunde gennem CCustomerSession et begyndelsesbogstav for den ønskede destination, og der hentes en liste med stationer, som har det givne begyndelsesbogstav. Kunden vælger den ønskede station på listen. Customer øger eller mindsker antallet af personer for en given kundekategori, dette sker i de to løkker. Kunden accepterer sit køb, hvorefter en billet printes og købet logges i systemet. CCustomerSession afsluttes, og en ny gøres klar til den næste kunde. 7.2 Brugsmønster #15 Indrapportering af logning vedrørende billetsalg Når et køb er afsluttet på billetautomaten, skal dette sendes til serveren, for at blive gemt i databasen. Brugsmønster #15 omhandler dette, og vil blive beskrevet i det følgende. Der henvises til designklassediagrammet for TicketMachine og Server i bilag 18 på henholdsvis b33 og b35. Følgende klasser er fælles for TicketMachine og Server: IALogFacility Interface som benyttes til RMI-kommunikationen, således at klienten ved hvilke metoder, der er tilgængelige på serveren. APurchaseLogTransferObject Et objekt til at indeholde de oplysninger, der ønskes sendt mellem klienten og serveren, i dette tilfælde informationer omkring et køb. På Server benyttes følgende klasser: DLogFacility Klassen implementerer interfacet IALogFacility, og indeholder den service som serveren tilbyder klienterne via RMI. DPurchaseQueue Da logning tænkes indført med et kø-system, således at klienter ikke kommer til at vente på svar fra serveren, indføres en klasse til at håndtere en kø, indeholdende de overførte APurchaseLogTransferObject-objekter. 33