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

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 Gruppens reviewmøde 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 #

2 7.3 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 Opsummering af Implementation Statistik og test Måling og forudsætninger Statistisk model Forudsætninger for model Statistisk model for de målte logningstider Grundlæggende viden om hypotesetest Måling af logningstid på Serversoftware baseret på RMI Uafhængighed og normalfordelte data Behandling af indsamlede data Hypotesetest ud fra beregnede værdier Test under udviklingen Opsumering af Statistik og test Status Redegørelse for softwareprototypen Resterende arbejde Støttediscipliner Konfigurationsstyring Projektstyring Udviklingsmiljø Epilog Konklusion Perspektivering Refleksionsdokument Billedkilder Referenceliste 57 A Appendiks 58 A.1 Installationsvejledning A.1.1 Opsætning af MySQL-server A.1.2 Opstart af server og billetautomat A.1.3 Nedlukning af server og billetautomat A.1.4 Konfigurationsfiler A.1.5 Afinstallation A.2 Reviews A.3 Anvendelse af Secure Sockets Layer (SSL)

3 A.3.1 Generering af nøgler med keytool A.3.2 Anvendelse i Java A.4 Oversigt over cd Bilag Forside Indholdsfortegnelse Bilag: b1 b1 b2 b3 1 Ordliste b3 2 Product Backlog b5 3 Sprint Backlog 1 b6 4 Sprint Backlog 2 b7 5 Sprint Backlog 3 b8 6 Tidsplan b9 7 Faktortabel b10 8 Brugsmønsteroversigt og kravsporingsmatrice b14 9 Brugsmønstre b16 10 Analyseklassediagram b27 11 Sekvensdiagram for brugsmønster #05 b28 12 Pakkeoversigt b29 13 Designmønstre b30 14 Designklassediagram b33 15 Oversigt over den grafisk brugerflade. b36 16 Uddrag af semesterhåndbog b40 17 Inceptionsdokument b45 3

4 ETC Billetautomater - et softwaresystem til billetautomater Synopsis Denne rapport dokumenterer resultatet af udviklingsarbejdet i forbindelse med et softwaresystem til et fiktivt firma (ETC). Softwaresystemet er beregnet til billetautomater i forbindelse med salg af togrejser. Det udførte arbejde dokumenteres gennem UP-discipliner og de tilhørende artefakter. Derudover er den valgte softwarearkitektur for systemet beskrevet, og der er redegjort for den valgte distributionsform og de anvendte former for netværkskommunikation. Det udviklede system er en prototype, der har den mest centrale funktionalitet, såsom køb af billetter. Systemet er opbygget til at benytte en relationel database til lagring af data. Softwareprototypen har derudover sprogunderstøttelse og kan opdateres fra en central server. Ved hjælp af statistiske metoder, er softwareprototypen blevet undersøgt med hensyn til skalerbarhed og ydeevne. 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.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. Michael Hejselbak Bejer-Andersen Emil Holmegaard Flemming Max Jørgensen Sven Aage Madsen Thomas Nicky Thulesen 2

6 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 Gruppens reviewmøde 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

7 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 Opsummering af Implementation Statistik og test Måling og forudsætninger Statistisk model Forudsætninger for model Statistisk model for de målte logningstider Grundlæggende viden om hypotesetest Måling af logningstid på Serversoftware baseret på RMI Uafhængighed og normalfordelte data Behandling af indsamlede data Hypotesetest ud fra beregnede værdier Test under udviklingen Opsumering af Statistik og test Status Redegørelse for softwareprototypen Resterende arbejde Støttediscipliner Konfigurationsstyring Projektstyring Udviklingsmiljø

8 12 Epilog Konklusion Perspektivering Refleksionsdokument Billedkilder Referenceliste 57 A Appendiks 58 A.1 Installationsvejledning A.1.1 Opsætning af MySQL-server A.1.2 Opstart af server og billetautomat A.1.3 Nedlukning af server og billetautomat A.1.4 Konfigurationsfiler A.1.5 Afinstallation A.2 Reviews A.3 Anvendelse af Secure Sockets Layer (SSL) A.3.1 Generering af nøgler med keytool A.3.2 Anvendelse i Java A.4 Oversigt over cd

9 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 15 på side 57. Alle billedkilder er angivet i kapitel 14 på side 56. Bilagshenvisninger er skrevet på følgende form: bilag 7 på side b10 Hvor der henvises til bilag 7 i bilagskompendiet på side b10. 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 1 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 A.4 på side 65. 6

10 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 Lillebæ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 17 på side b45 forefindes inceptionsdokumentet for ETC billetautomater. Et uddrag af semesterhåndbogen, for 4. semester datateknologi/robotteknologi, findes i bilag 16 på side b40, 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. 7

11 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 7 på side b10) 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æsentativ 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 8

12 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 8 på side b15 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 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. 9

13 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, på nær discipliner der omhandler selve styringen af projektet 1. 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 2. 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 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 1 Lit.[8], se cd. 2 Lit.[17] URL[ 10

14 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 2 på side b5. 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 3, 4 og 5 på side b6, b7 og b8. 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. Efter hver arbejdsdag er lavet tidsestimater for det resterende arbejde. Graferne på bilag 5 på side b8 viser hvordan udviklingen for estimeret restende tid, har været. Generelt har tidsestimaterne været for optimistiske, idet mange opgaver tog længere tid end forventet, men graferne har trods alt været aftagende under det meste af forløbet. 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). 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 6 på side b9 ses tidsplanen 11

15 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. 3.4 Gruppens reviewmøde Gruppen har afholdt et formelt review, meget lignende et inspektionsreview (se appendiks A.2 på side 60), hvor brugsmønsteret #07 Køb af rejser er artefaktet der er til review. Mødet er gennemført under følgende konditioner: 1. Mødeleder: Lone Borgersen 2. Referent: Sven Åge 3. Reviewer: Gruppe 3 (Anders, Jonas, Sebastian, Thor) 4. Producent: Gruppe 1 (Emil, Flemming, Michael, Thomas, Sven Åge) 5. Materiale: ETC-billetautomat (Brugsmønster: #07 Køb af rejser ) Der er foretaget et formelt review som har følgende formalia: Planlægning af review Tidspunkt og deltagere, samt præcisering af emnet til review og dele som ikke er til review, så tiden anvendes optimalt. Forberedelse Læsning af materialet sker uafhængigt af hver enkelt reviewer. Gennemførelse af review Hvor hver enkelt reviewer uafhængigt giver et uforfalsket review. Dette gennemfører reviewlederen bl.a. ved at bryde kontinuiteten af rækkefølgen mellem reviewerne, så der fås mindre afhængighed af de enkelte udsagn. Opfølgning på review Referat med fundne fejl. Rettelse af fejlene. Reviewleder starter reviewet op med at bede parterne overholde formalia, og sørger for at frasortere uvæsentlige ting, såsom stavefejl. 12

16 På bud fra reviewleder, giver reviewerne (gruppe 3), på skift, deres generelle kommentarer til review materialet. Reviewerne kommenterer herefter ud fra kapitler, materialet der er til review. Producenten (gruppe 1), skal ikke argumentere for noget og må kun svare på stillede spørgsmål fra reviewerne, omkring opklaring til forståelse af det reviewede materiale. Det foretagne reviewreferat er struktureret, så at det afspejler den ovenstående nævnte rækkefølge, hvor overskriften er baseret på generelle kommentarer eller det pågældende kapitel der reviewes. Under overskriften er interviewerens navn i venstre margen og i højre interviewerens kommentarer. Efter reviewmødet, var der enighed i gruppen om, at mødet var effektiv og at der blev fundet mange relevante fejl, som gav god respons på hvordan materialet generelt skulle revideres for bedre forståelighed, læsbarhed og korrekthed. Reviewmaterialet og reviewreferat kan findes på cd en. 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 22. 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 18 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 34. 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 dele af det arbejde der er udført i krav- og analysedisciplinerne. 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 17 på side b45). 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 10 på side b27). 5.1 Uddrag fra faktortabel Da ikke alle krav opfyldes i prototypen af ETC Billetautomater, er det 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 7 på side b10. alle transaktioner i forbindelse med et rejsekøb og tidspunktet for disse transaktioner. Mellem betydning for softwarearkitektur. F2 Dagsummer At kunne registrere billetautomaters omsætning (dagsummer) og betalinger centralt. Se specifikke krav på side 18 og 25 i inceptionsdokumentet (bilag 17). Faktor og Fleksibilitet og Kvalitetsscenarie 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 det centrale databasesystem. Er der ingen forbindelse til dette system, gemmes loggen lokalt indtil der igen er forbindelse. Betydning Stor betydning for ETC, i forbindelse med sikkerhed og dokumentation af betalinger. Se F1 Hændelseslog. Vigtigt for ETC i forbindelse med bogføring. Mellem betydning for softwarearkitektur. Succesprioritet Høj Høj Risiko Middel Middel Fortsættes.. 1 En faktortabel bruges til at holde styr på ikke-funktionelle krav - AUAP larman.pdf 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. U6 Destinationer på skærm Kunden skal kunne angive sin destination ved valg af stationsnavn. Destinationen kan fx vælges ud fra en alfabetisk liste hvor de ti mest benyttede destinationer står øverst. 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. Destinationen kan vælges fra en oversigt over de ti mest brugte destinationer. Ønskes andre stationer vil der være mulighed for at vælge et begyndelsesbogstav, og dernæst den ønskede station. 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 Fleksibilitet og Kvalitetsscenarie fremtidig udvikling F3 Stamoplysninger Dette er nødvendigt at implementere for For hver billetautomat at kunne lave fyldest- skal det gørende logning, samt være muligt at sikre billetautomatens angive en række almindelige funktionalitet. stamoplysninger: gyldighedsperiode, region, samarbejdspartnere, betalingskorttyper, billetautomatnummer, pinkodeterminalnr., billetautomat tlf. nr., stationsnr. Se side i inceptionsdokumentet (bilag 17). Anvendelighed (Usability) U3 Sprog Der vil være mulighed Kunden skal kunne for valg af dansk, engelsk vælge mellem dansk eller tysk, samt (standard), engelsk opdatering af sprog. eller tysk. Der skal Senere vil det med være mulighed for udvidelse stor sandsynlighed til valg mellem være nødvendigt flere sprog. at tilføje mulighed for tilføjelse, ændring og fjernelse af sprogpakker. Succesprioritet Høj Middel Høj Høj Risiko Lav Middel Middel Lav Fortsættes.. 16

20 Faktor og Fleksibilitet og Kvalitetsscenarie fremtidig udvikling Pålidelighed (Reliability) R1 Drift ved systemnedbrud Systemet imple- og menteres så det er lign. muligt at købe billet Billetautomaten skal ved systemnedbrud. 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 systemet af flere bil- kan håndtere flere letautomater samtidige billetautomater. Flere billetautomater Samtidigt skal samtidigt kunne skal systemet være anvendes og indrapportere så effektivt, at der til det centrale ikke opstår ventetid databasesystem. Der ved mange samtidige må i den forbindelse brugere. 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 Re- at opdatere disse data Det vil være muligt Meget vigtig for ETC. jse fra centralt hold. Meget vigtigt for #07 Køb af rejser skal kunne ændres, softwarearkitektur. fx mht. destinationer, billettyper, kundekategorier og lign. Succesprioritet Høj Høj Høj Risiko Høj Høj Høj 17

21 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. Figur 5.1: Brugsmønsterdiagram. De brugsmønstre, som er grå, er blevet bearbejdet. 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 9 på side b16. 18

22 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. 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. Fortsættes... 19

23 Aktør System 15. Kunden betaler. 16. Systemet godkender betaling, registrerer transaktionen og udskriver billet. Alternative forløb: Krydsreferencer: #07.1 Køb af rejser: Annullering af køb 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, 2 og 3. 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 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 10 på side b27) er kun medtaget de klasser, attributter og metoder, som er nødvendige jf. projektafgrænsningen i afsnit 2.3 på side 8. 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) - - Fortsættes... 4 Lit.[1], kap. 8.4, side

24 Navneord Klasse/attribut Navn i diagram 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 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 TicketMachineData skal indeholde de informationer en kunde får brug for, når der skal sammensættes en billet (destinationer og priser). Den skal også indeholde informationer om billetautomatens status, både den operationelle status, men også de data der beskriver de enkelte billetautomater (id-nummer). 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. SubPurchase er en generel billettype, som specialiseres til QuickPurchase og OrdinaryPurchase via arv. De oplysninger der er brug for, ved hvert billetkøb, gemmes i Ticket. Oplysninger der skal bruge til F2 Dagsummer gemmes i Log. 21

25 5.4 Brugsmønster #03 Opdatering af software på billetautomaterne Analysen af brugsmønster #03 Opdatering af software på billetautomater, er lavet ud fra inceptionsdokumentet (se bilag 17 på side b45) 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: Ingen. Interessenter: ETC: ønsker mulighed for at opdatere software på billetautomater fra centralt hold, da dette vil lette vedligeholdelsesarbejdet betragteligt. Prækondition: Ingen. Postkondition: 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. 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, 2 og 3. Status: Analyse påbegyndt i 1. sprint. Kommentarer: Ingen. 22

26 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 Ticket- Machine 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. Figur 5.2: Analyseklassediagram for brugsmønster #03 Opdatering af software på billetautomaterne. 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 vigtig, da denne giver styrende input til hele projektfasen. Kravartefakterne anvendes som reference, til at styre softwarekonstruktionen i elaborationsfasen, således at prototypen overholder de anførte krav i faktortabellen (se bilag 7 på side b10). I analysefasen har der været fokus på de ikke-funktionelle krav, fra faktortabellen, der har høj succes prioritet, samt høj risiko. Dette er gjort for at imødegå et design, der kan levere et robust softwareskelet af det bærende brugsmønster #07 Køb af rejser. Det er henholdsvis de ikke-funktionelle krav F1 Hændelseslog, U4 Kort ekspeditionstid, U6 Destinationer på skærm og R1 Drift ved systemnedbrud og lignende der har været fokus på i denne forbindelse. Af faglig interesse er U3 Sprog medtaget og blevet analyseret. Arbejdet af analysen kan ses på analyseklassediagrammet i bilag 10 på side b27. De øvrige krav med høj risiko, P1 Samtidig anvendelse af flere automater og S1 Fremtidig variation af Køb af rejse, kan først løses i designfasen, idet disse er hardwareorienteret. 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 12 på side b29. Distribueringsgraden er en 3-tier klient/server arkitektur, med distribueret applikationskerne og remote database 2, på overstående figur 6.1, 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. 1 Lit.[2] kap. 9, side Lit.[3] kap. 2.3, side

28 Figur 6.2: Oversigt over PCMEF arkitekturen. Presentation layer Er ansvarlig for al præsentation til brugeren, det er her GUI-objekter defineres. 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). 3 Lit.[2] kap , side Lit.[2] kap , side

29 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. 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 5 SOFT undervisningslektion 7 - SOFT7.pdf s. 4 6 SOFT undervisningslektion 1 - SOFT1.pdf s. 3,6,11,13 26

30 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 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 13 på side b30, 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. 7 SOFT undervisningslektion 1 - SOFT1.pdf s Lit.[10] URL[ 27

31 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. 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 16 på side b40), 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

32 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 sikkerhed er det valgt at benytte SSL, i forbindelse med kommunikationen mellem klient og server, se appendiks A.3 på side 62. 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 9 Lit.[5] kap , side KOM undervisningslektion 5, KOM5.pdf s. 1 29

33 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 12. 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. 11 Lit. [10] URL[ 12 KOM undervisningslektion 4, KOM4.pdf s 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 PCMEF 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 18. 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. Der er lavet et udkast til den forventede grafiske brugerflade som det ses på figur 7.2. Figur 7.2: Udkast til grafisk brugerflade til billetautomat. Det endelige resultat kan ses i bilag 15 på side b36. 32

36 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 7 på side b10). Det er efter valg af destination, muligt at til-/fravælge antal billetter, ved henholdsvis aktivering af eller - funktionaliteterne (se figur 7.3). Figur 7.3: Grafisk fremstilling af funktionaliteten for at til-/fravælge antal billetter. 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-tilmange 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. 33

37 7.1.3 Sekvensdiagram for brugsmønster #08 :CCustomerSession :EPurchase :ETicket :MStationHandler :ECustomerCategory getspecifiedstations (selection char) getspecifiedstations (selection char) setdestinationstation (stationname string) setdestinationstation (stationname string) getstation (stationname string) getdestinationstation (stationname Station): String getdestinationstation (stationname Station): String The customer increases a selected CustomerCategory by 1 loop [inccustomer- Category=true ] inccustomercategory () getcustomercategory () inccustomercategory () getcustomercategory () inccustomercategory () getcustomercategory () The customer decreases a selected CustomerCategory by 1 loop [deccustomer- Category=true ] deccustomercategory () getcustomercategory () deccustomercategory () getcustomercategory () deccustomercategory () getcustomercategory () acceptpurchase() printalltickets() logtransaction() closeandreset- Session() loop [for each ticket in Ticket] printalltickets() printticket() Figur 7.4: Sekvensdiagram for brugsmønster #08 Almindeligt køb af billet. I figur 7.4 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 14 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. 34

38 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. DPurchaseLogDispatcher Køres som en tråd, der konstant tager objekter fra køen, og behandler disse objekter. DPurchaseLogStorage Har til formål at opdele APurchaseLogTransferObject-objektet, således at data gøres klar til at blive gemt i databasen. FInsertSQLStorage Håndterer måden hvorpå data indsættes i databasen. FNetworkConnection Har til formål at binde de objekter, der skal være tilgængelige for klienterne. Objekterne bindes til RMI-Registry, med en given identifikation. Klassens ansvarsområde er at håndtere netværksforbindelser via RMI Sekvensdiagram for brugsmønster #15 Brugsmønsteret er delt op i to, da det påregnes med at logningen laves med en køfacilitet på serversiden. Første del omhandler klientens håndtering af at sende logningsdata til serveren og serverens metode til at lægge loggen ind i en kø, dette kan ses på figur 7.5. Anden del omhandler serverens håndtering af køen, dette kan ses på figur 7.6. Figur 7.5: Sekvensdiagram for brugsmønster #15 Indrapportering af logning vedrørende billetsalg. Når et køb er gennemført, svarende til at logtransaction kaldes på figur 7.5, kaldes logpurchase på MPurchaseLog. MPurchaseLog udtrækker de ønskede oplysninger ud af det specificerede IAPurchase-objekt. Disse oplysninger gemmes i et APurchaseLogTransferObject, således at det på et senere tidspunkt er muligt for serveren at modtage og behandle disse oplysninger. Derefter oprettes forbindelse til serveren, og et RMI kald laves for at overføre APurchaseLogTransferObject-objektet. Når serveren modtager objektet, placeres det bagerst i køen (DPurchaseQueue). 35

39 Figur 7.6: Sekvensdiagram for brugsmønster #15 Indrapportering af logning vedrørende billetsalg, håndtering af logningskø. Når serveren startes op, instantieres logningsfaciliteten (fra PInit) som det er vist på figur 7.6. Hvorefter DPurchaseLogDispatcher startes op i en ny tråd, hvor der konstant lyttes efter objekter i DPurchaseQueue. Når DPurchaseLogDispatcher kan få fat i et APurchaseLogTransferObject, sendes det videre til DPurchaseLogStorage, som udtrækker de enkelte elementer ud, og placerer dem i FInsertSQLStorage, som så gemmer dem i databasen. 7.3 Brugsmønster #05 Valg af sprog på billetautomat Gennemgangen af design for dette brugsmønster vil fokusere på, hvordan systemet er designet til at kunne håndtere netværksnedbrud. Brugsmønsteret er underlagt kravet S3 Softwarestyring på automat, og det skal derfor være muligt at opdatere sprog på samtlige billetautomater fra centralt hold. Designet er udført således at sproget kun opdateres ved notifikation fra serveren. Dette betyder at et sprog kan nøjes med at blive hentet én gang, og kun behøver at blive opdateret, hvis der sker en opdatering på serveren. I det følgende vil der blive redegjort for billetautomatens offline-funktionalitet Offline-funktionalitet Ifølge krav R1 Drift ved systemnedbrud og lignende, skal billetautomaten kunne fungere offline. Der er truffet beslutning om, at kun standardsproget skal kunne benyttes, når en billetautomat er offline. Det vil således kun være dette sprog, som forbliver i hukommelsen på billetautomaten. Hvis billetautomaten er online, kan der vælges et hvilket som helst sprog, der så hentes fra serveren. Ved afslutningen af en session vælges standardsproget automatisk, og hvis der findes andre sprog end standardsproget i hukommelsen fjernes disse. Hvis der allerede er valgt et andet sprog end standardsproget, idet billetautomaten mister forbindelsen til serveren, vil dette sprog dog kunne benyttes til afslutningen af den pågældende CCustomerSession-objekt. I figur 7.7 ses designklassediagram for de klasser, der har betydning for offline-funktionaliteten af billetautomaten. Klasserne beskrives i det følgende: PLanguagePanel Indeholder en knap for hvert sprog som er tilgængeligt. Denne klasse fungerer som observer til CConnectionController. Metoden update kaldes hver gang der er en ændring i forbindelsesstatus for billetautomaten. Metoden sørger for at deaktivere alle sprogknapper hvis billetautomaten mister forbindelsen til serveren, og sørger for at aktivere dem igen når billetautomaten kommer online. 36

40 Figur 7.7: Klassediagram for en udvalgt del af brugsmønster #05 Valg af sprog på billetautomat, omhandlende offline-funktionalitet. CConnectionController Fungerer som observable, idet klassen kan notificere tilmeldte observere, hvis der opstår ændringer i forbindelsesstatus for billetautomaten. CConnectionController indeholder information om den nuværende forbindelsesstatus, og har en timer, som med jævne mellemrum aktiverer CConnectionTask. CConnectionTask Bliver aktiveret med jævne mellemrum, for at tjekke forbindelsen. Stationsforbindelsen, og sprogforbindelsen bliver tjekket ved at de to Remote Observers, hver især, bliver bedt om at tjekke deres forbindelse til serveren, og eventuelt lave en ny forbindelse, hvis billetautomaten er offline. Hvis forbindelsesstatus ændres, bliver CConnectionController orienteret. MLanguageHandler Indeholder metoden isconnected, som benyttes til at kontrollere om MLanguageHandler er forbundet til serveren, samt connect som benyttes til at genetablere forbindelse, hvis billetautomaten har været offline. IALanguageConnection Definerer de metoder som MLanguageHandler kan kalde på serveren. Idet denne arver fra interfacet IARemoteObservable, kan metoden checkconnection kaldes. checkconnection har kun til formål at kontrollere om der er forbindelse til serveren, og giver en exception hvis der ikke kan oprettes forbindelse til serveren. Det ses på klassediagrammet (se figur 7.7) at MStationHandler fungerer på tilsvarende vis som MLanguageHandler. Et sekvensdiagram for forbindelsescheck ses i figur Brug af Observer-mønsteret Observer-mønsteret bliver brugt mange gange i forbindelse med sprogfunktionaliteten. Dette gøres, idet PCMEF principperne UNP og DDP ønskes overholdt. Notifikationskæden er som følger: FLanguageConnection (Remote Observable på serveren) 37

41 run() task :CConnectionTask isonline() online: boolean connectioncontroller : CConnectionController languagehandler : MlanguageHandler stationhandler: MStationHandler alt [!online ] connect() connect() opt[!exception ] setonline() [ else ] checkconnection () isconnected() languageconnected : boolean isconnected() stationconnected: boolean opt[!languageconnection OR!stationConnection ] setoffline() Figur 7.8: Sekvensdiagram for hvordan billetautomaten detekterer tabt forbindelse og genetablerer forbindelsen. MLanguageHandler (Remote Observer på billetautomaten) CLanguage PJLabel-/PJButtonObserver FLanguageConnection notificerer alle tilmeldte MLanguageHandler-objekter, hvis data på serveren er blevet ændret, og billetautomaterne ønskes opdateret. MLanguageHandler notificerer dernæst CLanguageHandler for at gøre opmærksom på at data er blevet ændret. Slutteligt notificeres præsentations-laget, idet tekster på knapper og labels ønskes opdateret (et sekvensdiagram for dette kan ses i bilag 11 på side b28). 7.4 Opsumering af Design Der er i dette kapitel arbejdet med designdisciplinen, hvor brugsmønster #08 Almindeligt køb af billet er gennemgået, for at vise hvordan den primære del af domænelogikken er opbygget, samt hvordan PCMEF arkitekturen kan benyttes. Brugsmønster #15 Indrapportering af logning vedrørende billetsalg er gennemgået, for at vise hvordan snittet mellem klient og server er lagt, samt hvordan et Data Transfer Object kan benyttes. Brugsmønster #05 Valg af sprog på billetautomat er beskrevet for at vise hvordan et observer mønster kan benyttes til at overholde nogle af PCMEF principperne. Der er desuden redegjort for hvordan billetautomaten kan arbejde offline og automatisk genetablere forbindelse. 38

42 8. Implementation I det følgende vil det blive gennemgået hvordan funktionaliteten til at vise Top-10 over mest anvendte stationer, er blevet implementeret. 8.1 Top-10 liste implementation Formålet med Top-10 listen er at gøre det hurtigere at købe en billet til de destinationer, der oftest vælges fra en given station. Forløbet gennemgås fra at en liste laves i Foundation (ud fra data i databasen på serveren) og op til den grafiske brugerflade på billetautomaten. Ved designet af denne funktionalitet, er der overvejet to muligheder: Den ene mulighed er at lave en liste med hvor mange billetter, der er solgt til de respektive stationer. Der laves så en metode i MStationHandler til at sortere stationsnavnene efter popularitet. Dernæst generere en ny liste med den ønskede mængde af stationsnavne (Top-10). Den anden mulighed er at lade sorterings- og selektionsarbejdet blive udført af databasen, på bagrund af bestemte parametre. Det er den sidstnævte mulighed, der er implementeret. Dette er gjort da der ellers vil blive sendt mange oplysninger fra databasen, gennem netværket og over til MStationHandler. Disse data kunne indeholde oplysninger for 300 stationer, hvor der fx kun benyttes ti. Databasen er opbygget som vist på figur 8.1. purchase purchase_id INT(10) <pk,fk> not null saledatetime DATETIME not null automat_id VARCHAR(10) not null total_price DOUBLE not null language VARCHAR(35) null type_of_purchase VARCHAR(35) null stations_default name VARCHAR(50) <pk> not null priority INT(10) not null tickets ticket_id INT(10) <pk,fk> not null purchase_id INT(10) not null departure VARCHAR(35) not null destination VARCHAR(35) not null ticket_detail ticket_detail_id INT(10) <pk> not null ticket_id INT(10) not null category_name VARCHAR(50) not null quantity INT(11) not null Figur 8.1: Tabeldesign for et udsnit af databasen anvendt i dette projekt, disse benyttes i forbindelse med Top-10 visningen Oprettelse af Top-10 liste Der startes med at gennemgå implementationen i Foundation, hvor SQL-kommandoerne bliver udført. Kodeudsnit 8.1 viser metoden til at hente en liste over de mest benyttede stationer. I linje 8-12 oprettes en forbindelse til databasen, ved hjælp af FDBConnections-objektet. I linje udføres databaseforespørgelsen. I linje laves en liste over alle de destinationer, der er solgt billetter til, fra en bestemt afrejsestation (thisstationname). Listen indeholder både destinationsnavn og antal solgte billetter dertil. Den tidsperiode der bruges til at afgrænse søgningen, angives med showstationsfordays. Da det ikke er sikkert at der er solgt billetter til det antal stationer, der skal vises, så bruges 39

43 linje 23 til at finde de destinationer, som er nævnt i default stations (se figur 8.1), hvor antal solgte billeter er lig nul (dog kan den angivne afrejsesation ikke indgå eller blive valgt i listen). Hvis der er foretaget flere køb til samme destination, så summeres antallet af solgte billetter (SUM i linje 15) for for hver afrejsestation (GROUP BY i linje 25). Linje 26 laver en sortering på en midlertidig liste (stationlist), efter antal solgte billetter, prioritering for stationer hvor billetantal er nul og en alfabetisk sortering af hensyn til stationer hvor der er samme salgsantal. Til sidst benyttes LIMIT til at begrænse listens længde ud fra showstationamount, dette gøres i linje 27. Når MySQL-databaseserveren har fundet de ønskede oplysninger så gennemløbes en løkke (linje 29-30), hvor hvert enkelt stationsnavn bliver tilføjet til mostusedstationslist. 1 package foundation ; public class FStationsConnection extends ARemoteObservable implements IAStationsConnection { public ArrayList<String > getmostusedstations ( S t r i n g thisstationname, int showstationamount, int showstationsfordays ) throws RemoteException { 6 ArrayList<String > mostusedstationslist = new ArrayList<String >() ; 7 8 Connection dbconn = null ; 9 dbconn = FDBConnections. get Conne ction ( ) ; 10 Statement stmt = null ; 11 R esultset r s = null ; 12 stmt = dbconn. createstatement ( ) ; r s = stmt. executequery ( 15 SELECT name, SUM( quantity ) AS quantity, p r i o r i t y FROM ( 16 (SELECT d e s t i n a t i o n AS name, SUM( t i c k e t d e t a i l. quantity ) AS quantity, IFNULL( s t a t i o n s d e f a u l t. p r i o r i t y, ) AS p r i o r i t y FROM t i c k e t s 17 LEFT OUTER JOIN t i c k e t d e t a i l ON t i c k e t s. t i c k e t I D = t i c k e t d e t a i l. t i c k e t I D 18 LEFT OUTER JOIN s t a t i o n s d e f a u l t ON t i c k e t s. d e s t i n a t i o n = s t a t i o n s d e f a u l t. name 19 LEFT OUTER JOIN purchase ON t i c k e t s. purchase ID = purchase. purchase ID 20 WHERE TIMESTAMPDIFF(DAY, purchase. saledatetime,now( ) ) <= showstationsfordays AND t i c k e t s. departure LIKE thisstationname 21 GROUP BY t i c k e t s. d e s t i n a t i o n ) 22 UNION 23 (SELECT name, 0, p r i o r i t y FROM s t a t i o n s d e f a u l t WHERE name NOT LIKE thisstationname ) 24 ) AS s t a t i o n L i s t 25 GROUP BY name 26 ORDER BY quantity DESC, p r i o r i t y ASC, name ASC 27 LIMIT showstationamount ; ) ; while ( r s. next ( ) ) { 30 mostusedstationslist. add ( r s. g e t S t r i n g ( name ) ) ; 31 } return mostusedstationslist ; 34 } 35 } Kodeudsnit 8.1: Uddrag af FStationsConnection på serveren. 40

44 8.1.2 Forespørgsel på Top-10 liste MStationHandler indeholder en metode til at oprette en liste over de mest anvendte stationer (createmostusedstationlist) samt en metode til at returnere denne liste (getmostusedstation- Names). I kodeudsnit 8.2 linje 22-24, bliver der sat tre attributter. Det er thisstationname der sættes til at indeholde navnet på den station, hvor billetautomaten er placeret, showstationamount, der angiver hvor mange stationsnavne som listen skal indeholde. Sidst bruges showstationsfordays til at bestemme hvor mange dage der skal ses tilbage, når antallet af solgte billetter sammenlignes. Disse attributter kan justeres for hver enkelt billetautomat i filen config.xml. I linje 26 laves et kald til FStationsConnection (der ligger på serveren) for at få en liste over de mest benyttede stationer fra den givne afgangsstation. 1 package domain. mediator ; public c l a s s MStationHandler implements IARemoteObserver { private IAStationsConnection s t a t i o n s C o n n e c t i o n ; 6 private ArrayList <S t r i n g > mostusedstationnames ; private MStationHandler ( ) throws Exception { networkconnection = FNetworkConnection. g e t I n s t a n c e ( ) ; 11 observerremoteobject = networkconnection. createremoteobject ( this ) ; 12 connect ( ) ; } public void conne ct ( ) throws RemoteException, NotBoundException { 17 s t a t i o n s C o n n e c t i o n = ( IAStationsConnection ) networkconnection. getremoteobject ( StationsConnection ) ; 18 s t a t i o n s C o n n e c t i o n. addremoteobserver ( observerremoteobject, automatid ) ; 19 } private void c r e a t e M ostusedstationlist ( ) throws Exception { 22 S t r i n g thisstationname = MDefaultSettings. getthisstationname ( ) ; 23 int showstationamount = MDefaultSettings. getshowstationamount ( ) ; 24 int showstationsfordays = MDefaultSettings. getshowstationsfordays ( ) ; ArrayList<String > s t a t i o n s = s t a t i o n s C o n n e c t i o n. getmostusedstations ( thisstationname, showstationamount, showstationsfordays ) ; mostusedstationnames = s t a t i o n s ; } public ArrayList <S t r i n g > getmostusedstationnames ( ) throws RemoteException { 33 c r e a t e M o s t U s e d S t a t ionlist ( ) ; 34 return mostusedstationnames ; 35 } } Kodeudsnit 8.2: Uddrag af MStationHandler i TicketMachine. 41

45 8.1.3 Visning af Top-10 liste Listen returneres gennem CTicketMachine op til PMainCenterPanel. På kodeudsnit 8.3 linje 13, ses hvordan der oprettes et panel til at vise navnene på de mest brugte destinationer. PStationsPanel er et panel, der opretter et antal knapper (JButton) ud fra navnene i en ArrayList. Argumentet stationnames, sættes (på linje 7) til at indeholde navnene på de mest brugte destinationer. I linje 16 bliver panelet sat til visning. 1 package p r e s e n t a t i o n. gui. layout ; private ArrayList<String > stationnames ; 4 5 public PMainCenterPanel ( ) { 6 try { 7 stationnames = CTicketMachine. g e t I n s t a n c e ( ). getmostusedstationnames ( ) ; 8 } catch ( Exception e ) { 9 e. printstacktrace ( ) ; 10 } l ayout = new GridLayout ( 1, 1 ) ; 13 s t a t i o n s P a n e l = new PStationsPanel ( stationnames ) ; setlayout ( layout ) ; 16 add ( s t a t i o n s P a n e l ) ; 17 } Kodeudsnit 8.3: PMainCenterPanel i TicketMachine. Viser hvordan billetautomatens forside, sættes op til at vise de mest benyttede stationer Opsummering af Implementation Der er valgt at vise et deludsnit af billetautomatens implementation. Top-10 listen giver et indblik i hvordan et godt design minimerer antallet af kritiske aktiviteter (såsom database fjernadgang) på en elegant måde. Der er tre væsentlige punkter i denne funktionalitet, som er interessante: Krav 1 Software om brug af MySQL. Indlejret SQL forespørgsel (generer Top-10 liste, ETC krav U6 Destinationer på skærm ). Velvalgt design for at minimere antallet af database forespørgsler. Minimering af kompleksitet i program, ved at lade databasen håndtere forretningsspecifik logik. 42

46 9. Statistik og test I dette afsnit ønskes den fremstillede serverprototypes softwarekvalitet undersøgt, og til dette anvendes statistiske metoder. Serveren er fremstillet med to forskellige datastrukturer i forbindelse med logning af salgsdata fra billetautomaterne. Datastrukturene er opbygget, henholdsvis med kø (se afsnit 7.2 på side 34) og uden kø (ikke beskrevet i rapporten). Disse datastrukturer testes hvad angår klienters ventetid ved logning. Denne test vil yderligere give en indikation, om hvorvidt den fremstillede software er skalerbar eller ej. 9.1 Måling og forudsætninger For at kunne gennemføre en række køb uden brugerinteraktion, er klientsoftwaren blevet modificeret til dette. Der er indført en statistikpakke, for at mindske påvirkningen på selve billetautomatssoftwaren. Denne statistikpakke repræsenterer et antal kunder, som køber billetter. Generering af data Statistikpakken er konstrueret således, at forekomsten af de genererede køb afspejler en Poissonfordeling 1. Denne fordeling afspejler en naturlig ankomst af kunder, der er vigtig for at simulere en virklighedstro model. Forudsætninger Inden de egentlige målinger foretages, sættes hver billetautomat til at generere tre køb for at opnå steadystate, så de ikke-deterministiske 2 påvirkninger mindskes 3. Der er benyttet et lukket LAN netværk (100 Mbit) til kommunikationen mellem klienter og server. Som server er anvendt en nyere computer (Intel dualcore 3.0 GHz, 4 GB Ram, 250 GB harddisk) med Windows Server Som klienter er anvendt ti ældre computere (Intel 1.7 GHz, 512 MB Ram, 30 GB harddisk) med Windows XP. På klienterne er diverse overflødige baggrundsprogrammer deaktiveret, for at mindske unødigt CPU forbrug. Indsamlede data En observation er én tidsmåling af hvor lang tid en logning har varet for ét køb. Et samlet datasæt består af alle observationer i et givent tidsrum, med et forventet antal køb pr. minut (belastning) pr. klient. Der er indsamlet data med tre forskellige belastninger: 1, 2 og 3 svarende til henholdsvis 1 køb, 10 køb og 20 køb pr. minut. Der er indsamlet datasæt for hver datastruktur, disse grupperes hvor M er datasæt med kø og U er datasæt uden kø. 1 Lit.[6] kap , side Når noget ikke er forudbestemt, eller kontrolleret. 3 Lit.[4] 43

47 9.2 Statistisk model Den statistiske model, som beskrives, har til formål gennem hypotesetest 4 at påvises, at der en signifikant forskel på logningstiden for datastrukturen med kø (M) i forhold til uden kø (U) Forudsætninger for model Det er valgt at foretage en T-test. Det havde været at foretrække at benytte en parret T- test, da denne er bedre til at fremhæve forskelle 5. Men der benyttes en uparret T-test, da der ikke er afhængighed mellem datasættene (M og U). For at benytte en uparret T-test, skal datasættene være normalfordelte, og de enkelte observationer i hvert datasæt, skal være uafhængige af hinanden. Ud fra centralgrænseteoremet 6 er gennemsnit af data normalfordelt når antallet af observationer i et datasæt overstiger 20. Dette forudsætter at alle observationer, i ét datasæt, har samme sandsynlighedsfordeling, med samme forventningsværdi og standardafvigelse. Dette er opfyldt, da antal observationer i hvert datasæt overstiger 20 (se tabel 9.2 på side 46) og har samme fordeling Statistisk model for de målte logningstider Ud fra de givne oplysninger, bliver modellen som følger: M N(µ M, σ 2 M ) hvor µ M (middelværdi) og σ M (standardafvigelse) er ukendt. U N(µ U, σ 2 U ) hvor µ U (middelværdi) og σ U (standardafvigelse) er ukendt. M og U er uafhængige. Datasættene: M 1, M 2, M 3 er uafhængige. Datasættene: U 1, U 2, U 3 er uafhængige. Observationer med kø: m 1, m 2..m n. Alle m n observationer er uafhængige. Observationer uden kø: u 1, u 2..u n. Alle u n observationer er uafhængige. Der vælges et signifikansniveau på: α = 0.01 for høj signifikans 7. Dette vælges for at minimere sandsynligheden for at konkludere forkert Grundlæggende viden om hypotesetest Der benyttes en to-sidet hypotesetest, hvor følgende påstande ønskes undersøgt: H 0 : µ y = µ x, svarende til at de to datastrukturer ingen forskel giver. H 1 : µ x µ y, svarende til at de to datastrukturer giver signifikant forskel. Der indføres et acceptområde A og et kritisk område K, for at afgøre om H 0 kan forkastes eller accepteres. Det acceptable område A er givet ved: op til t α og fra t α til. Hvor 2 2 det kritiske område K er: t α K t α. 2 2 Der benyttes en test-statistic, T, for at afgøre i hvilket område testen befinder sig i. Denne 4 Lit.[6] kap , side Lit.[6] kap.8.2.4, side Lit.[6] kap.5.8,side Et signifikansniveau på α = 0.05 anses for normalt. Dette vil give en sandsynlighed på (1 α) 100% for at konkludere korrekt. 44

48 T -værdi findes ved hjælp af ligning T = M U S 2 M n M S2 U n U (9.1) Det betyder at følgende gælder: T A: accepter H 0. T K: forkast H 0 og dermed accept af H 1. Accepter H 0 Forkast H 0 H 0 er sand Rigtig konklusion Der er ingen forskel på logningstiderne. Forkert konklusion (Type I-fejl) Der er fejlagtigt antaget forskel på logningstiderne. H 1 er sand Forkert konklusion (Type II-fejl) Der er forskel på logningstiderne, men denne er ikke blevet opdaget. Rigtig konklusion Der er forskel på logningstiderne. Tabel 9.1: Oversigt over de to fejltyper ved hypotesetest. Der er i hypotesetest to typer af fejl, som det ses på tabel Type I-fejl er de alvorligste, da H 0 forkastes på et forkert grundlag. Type II-fejl er mindre alvorlige, da H 0 accepteres, selvom H 1 er sand. For at minimere forekomsten af type I-fejl, sættes signifikansniveauet α forholdsvis lavt, da denne angiver sandsynligheden for at type I-fejl opstår. Sandsynligheden for at der forekommer type I-fejl er givet ved: P (T K H 0 sand) = α Derfor bør α vælges så lav som mulig, det bliver dog sværere at forkaste H Måling af logningstid på Serversoftware baseret på RMI Der er indsamlet seks datasæt, med de førnævnte belastninger( køb pr. minut). Det var ikke muligt at øge belastningen yderligere, da den virtuelle Java maskine, på serveren, løb tør for tildelt hukommelse Uafhængighed og normalfordelte data Ovenstående kan vises ud fra et boksplot af datasættene, hvor outliers 10 er frasorteret, som giver information om dataspredningen i quartiler 11. Det tænkes muligt at de indsamlede data, indenfor en gruppe, er afhængige af hinanden forårsaget af den belastning som serveren udsættes for. Det fremgår af figur 9.1, at der ikke er nogen signifikant forskel på de foretagne målinger ved henholdsvis lav og høj belastning. Det antages derfor at der ikke er nogen afhængighed mellem målingerne i gruppen. 8 Lit.[6] kap.8.2.2, side Lit.[6] kap side Outliers er data som har så stor afvigelse fra øvrige data quartiler, at de med omtanke kan sorteres fra. 11 Lit.[7] kap. 24.1, side

49 Logningstid i ms Datasæt for belastningerne 1, 10 og 20 køb pr. minut, uden kø. Figur 9.1: Boksplot af de tre datasæt, uden kø, ved belastningerne 1, 10 og 20 køb pr. minut. Boksplottet viser at der ikke er nogen signifikant forskel på logningstiderne. Datasæt Observationer Gennemsnit Standardafvigelse T M M M U U U Tabel 9.2: Tabel over de beregnede værdier for de forskellige datasæt. T-værdierne er beregnet ud fra både M og U med samme belastning, og har derfor samme T-værdi Behandling af indsamlede data De indsamlede logningstider, for de seks datasæt, er overført til statistikprogrammet R 12. Gennemsnittet er fundet ved hjælp af funktionen mean i R. Ligeledes er standardafvigelsen fundet med funktionen sd. T -værdien er fundet ved hjælp af ligning 9.1. De beregnede værdier er vist i tabel Hypotesetest ud fra beregnede værdier Der foretages en hypotesetest på om der er forskel på de to før omtalte datastrukturer (M og U). Denne test udføres ved hjælp af de beregnede T -værdier fra tabel 9.2. H 0 kan forkastes 13 hvis T > t α, hvor t α er en tabelværdi14 givet ud fra signifikansniveauet 2 2 og antal frihedsgrader 15. Det er entydigt for alle datasæt med samme belastning, det vil sige fx 12 På cd en forefindes et R-script, der har været brugt i forbindelse med databehandlingen af de indsamlede data. 13 Lit.[6] kap.8.2.2,side Lit.[6] kap.d.5,side Ved en T-test sammenlignes der med en T-fordeling der har (observationer-2) frihedsgrader, deraf kan t α 2 findes. 46

50 Datasæt T t T > t Forkast H 0 M 1 og U Sand Ja M 2 og U Sand Ja M 3 og U Sand Ja Tabel 9.3: Hypotesetest, med et signifikansniveau på M 1 og U 1, at H 0 kan forkastes, jf. tabel H 0 kan endda forkastes med høj signifikansniveau (α = 0.01). Det vil sige data strukturen med kø, altså M, giver kortere logningstider end data strukturen uden kø, altså U. Det kan derfor være en fordel at benytte køsystemet. Skalerbarhed i fremstillet serversoftware Der er (se figur 9.1) ingen markant forøgelse af logningstiden, når belastningen stiger fra 1 køb til 20 køb pr. minut. Ud fra dette må det antages at systemet er skalerbart, da logningstiden ikke ændres markant ved større belastning. Den test der er udført, med ti klienter og en belastning på 20 køb pr. minut, svarerende til 200 køb pr. minut, eller at der sker et køb hvert andet minut på 400 billetautomater 16. Det var desværre ikke muligt at teste systemet ved en højere belastning, da den virtuelle Java maskine ikke havde tilstrækkelig med hukommelse. Ved opstart af den virtuelle maskine, er det muligt at angive hvor meget hukommelse der tildeles. Dette kunne have medført, at testen kunne være foregået med højere belastning, dog er der ikke blevet brugt tid på at undersøge dette yderligere. 9.4 Test under udviklingen Der har under udviklinen af softwaren ikke været udført test af hver enkelt metode og klasse, men på funktionaliteten beskrevet i de enkelte brugsmønstre. Det vil sige der ikke har været lavet nogen test-suite, men mindre funktionalitets test. Disse test er lavet ved hjælp af en stack-trace udskrivning i forbindelse med at der er opstået en exception. Desuden er serveren blevet testet i forbindelse med undersøgelsen af de to føromtalte datastrukturer. Denne test kan betegnes som en ydeevne test (performance), samt som en test om, hvorvidt den fremstillede software er skalerbar. 9.5 Opsumering af Statistik og test I dette kapitel er der foretaget måling på softwarekvaliteten ved hjælp af statistiske metoder. Der er fundet frem til at data strukturen hvor der benyttes en kø er mere effektiv end den hvor der ikke benyttes kø. Ydermere er der fundet frem til at det ikke har nogen væsentlig betydning om systemet belastes med 1 køb eller 20 køb pr. minut fra ti klienter, hvilket vil sige softwaren er skalerbar. 16 Der forventes opstillet billetautomater jf. inceptionsdokumentet. 47

51 10. Status Dette kapitel vil omhandle de brugsmønstre og krav, som er blevet udvalgt og bearbejdet. Der følger først en beskrivelse af hvad der er bearbejdet i projektforløbet. I forlængelse af dette beskrives hvad der mangler at blive implementeret, og forslag til tilføjelser Redegørelse for softwareprototypen I dette afsnit redegøres der for hvad der er implementeret i softwareprototypen. Hvis en funktionalitet vedrører et bestemt krav, vil dette stå i en efterfølgende parantes. Brugsmønster #01 Start opdatering af klientsoftware og data Fra serverens grafiske brugerflade kan der gives besked (via RMI) om, at der er ny software- eller dataversion tilgængelig. Brugsmønster #03 Opdatering af software på billetautomat Billetautomaterne kan hente en ny softwareversion fra serveren via en socket-forbindelse. Programmet TMManager sørger for at tjekke for softwareopdateringer, og hente disse samt genstarte TicketMachine. Opdatering og genstart udføres efter at en kunde har afsluttet et billetkøb. Brugsmønster #04 Opdatering af data på billetautomaterne Billetautomaterne kan (via RMI) hente nye oplysninger om stationer, kundekategorier og sprog. Brugsmønster #05 Valg af sprog på billetautomater Dansk er standard sprog (U3). Det kan vælges mellem dansk og engelsk (U3). Der kan tilføjes flere sprog direkte i databasen (U3). Ved oprettelse af en ny CCustomerSession, vil dansk sprog være valgt som standard. Når billetautomaten er offline, vil standardsproget stadig kunne benyttes. Brugsmønster #07 Køb af rejser Der er lavet en funktion til at vise stationsnavne. Flere stationsnavne kan tilføjes til databasen, uden at der skal ændres noget i softwaren (S1). Der vælges automatisk en afrejsestation. Der kan vælges mellem forskellige destinationer. En kunde kan kan vælge mellem forskellige kundekategorier (voksen, barn, m.m.). Der kan tilføjes flere kundekategorier til databasen, uden at der skal ændres i softwaren (S1). 48

52 En kunde kan op- og nedjustere antallet af personer på en billet. Der vises en pris for de enkelte kategorier for det valgte antal personer, samt en totalpris. Der laves en prisudregning, som afhænger af afrejse- og destinationsstation (vha. zonenumre). Der er lavet en udskriftsfunktion (på skærmen), som viser en billet med de valg kunden har foretaget. Brugsmønster #08 Almindeligt køb af billet En kunde kan vælge at se alle tilgængelige destinationer (fraregnet afrejsestation) (U6). Brugsmønster #09 Kvik-køb af billet På billetautomatens forside vises en Top-10 over de mest benyttede destinationer fra den pågældende afrejsestation (U4 og U6). Brugsmønster #15 Indrapportering af logning vedrørende billetsalg Informationer om billetkøb gemmes i en fælles database på en server (F2). Der gemmes informationer om hvilket sprog og hvilken købstype, der er benyttet. Brugsmønster #19 Generer ledelsesstatistik Der er vist to eksempler på ledelsesstatistik. Det kan ses hvor stor en omsætning, der har været for alle automater på en given station/dag/måned/år. Det kan ses hvor mange billetter, der er solgt på en/alle station(er) på en given dag/måned/år (F2). Server Der er fremstillet en grafisk brugerflade, hvor det er muligt at se hvilke billetautomater, der er tilmeldt observerlisten (online). Der er benyttet en MySQL database til at gemme stations- og salgsoplysninger (1). TicketMachine Der er fremstillet en grafisk brugerflade. Ved hjælp af en konfigurationsfil (config.xml) er det muligt at personalisere de enkelte billetautomater med hensyn til stationsnavn, hvor mange stationer der skal vises på forsiden samt periodelængde, der skal bruges til at finde de mest populære destinationer (Top-10 listen). 49

53 10.2 Resterende arbejde Følgende beskriver hvad der mangler at blive implementeret, samt forslag til fremtidige forbedringer. Generelt Der kan foretages nogle generelle ændringer, der vil gøre koden, såvel som systemet, mere ensartet. I koden er der fx anvendt machineid og automatid, selvom der refereres til samme id. Dette kan gøres i forbindelse med en refaktorering. Explicit Association Principle skal overholdes i hele systemet(metodeafhængigheder skal laves til klasseafhængigheder). Det bør overvejes hvordan exceptions skal håndteres i systemet. Softwaren er ikke optimeret med hensyn til hukommelsesforbrug. Som det er nu, hentes alle stationer ind i hukommelsen, således disse kan bruges i offline-tilstand. Det bør overvejes hvor stor funktionalitet der ønskes i offline-tilstand. Krav F1 Hændelseslog er ikke opfyldt. Brugsmønster #01 Start opdatering af klientsoftware og data Der kan fra serveren sættes en opdatering i gang manuelt, dog er dette ikke indført således, at man kan vælge tidspunktet for hvornår, opdateringen automatisk skal starte. Brugsmønster #03 Opdatering af software på billetautomat Opdateringen af klientsoftware, er implementeret således at alle billetautomater skal benytte den samme softwareversion. Dette bør i fremtiden laves, sådan at billetautomater kan deles ind i grupper, alt efter hvilken version de skal benytte. På nuværende tidspunkt er det lavet, så kun jar-filer kan overføres, dette bør i fremtiden laves således at alle slags filer kan sendes til klienten. I fremtiden bør TMManageren laves, så den under opstart, søger efter ny software på serveren, således at nyopstillede billetautomater kun behøver at have installeret TMManageren, og derefter selv sørger for at hente den nyeste softwareversion. Brugsmønster #05 Valg af sprog på billetautomater Billetautomaten mangler tysk sprogunderstøttelse, som det fremgår i U3 Sprog, er dette et ønske fra ETC s side, og bør indføres. Brugsmønster #07 Køb af rejser Dette brugsmønster beskriver hvordan et billetkøb foretages generelt. Softwareprototypen er fremstillet til at fungere på en billetautomat, men mangler at blive udvidet, så den også kan benyttes via internet eller mobile enheder. Det skal her være muligt at vælge en afrejsestation samt en rejsedato. Det skal også være muligt at angive serviceniveau (standard eller business) eller at vælge billettype (enkelt, dobbelt, osv.). Der er ikke lavet noget standard valg af antal og kundekategori (se side 13 i inceptionsdokument i bilag 17 på side b45). 50

54 Brugsmønster #08 Almindeligt køb af billet Det er kun muligt at købe én rejse pr. billetkøb. Når der foretages et almindeligt køb, skal det være muligt at sammensætte flere rejser (billetter) og betale dem samtidigt. Systemet er gjort klart til at håndtere dette via ticketbasket i EPurchase, men mangler implementering i brugergrænsefladen og ved logning af køb. Når en kunde skal vælge en destination, så vises alle stationer på én gang. Dette kan lade sig gøre da der i prototypen, kun er medtaget 50 stationer. Stationsvalget skal fremadrettet ske enten ved at skifte mellem forskellige sider med et antal stationer, søge efter en station med et bestemt begyndelsesbogstav eller måske ved at vise et kort over danmark, hvor der kan vælges fra. Brugsmønster #15 Indrapportering af logning vedrørende billetsalg Logning af salgsdata sker i forbindelse med afslutning af et køb. Det er nødvendigt med netværksforbindelse for at kunne foretage logning. Hvis billetautomaten er offline, bør logningen lagres lokalt indtil der igen er oprettet forbindelse til serveren. Brugsmønster #19 Generer ledelsesstatistik Det er i den grafiske brugerflade, til Server, gjort muligt at se hvor stor omsætning der er, for de enkelte stationer inden for en 7-dages periode. Det er også muligt at se antal og type af solgte billetter, for en given station for en given dag eller måned og/eller år. De resterende krav til ledelsesstatistik (se bilag 2 i inceptionsdokument på bilag 17 på side b45), mangler at blive behandlet. 51

55 11. Støttediscipliner I dette kapitel beskrives de værktøjer, som har været benyttet i projektet Konfigurationsstyring Der er valgt at benytte Subversion (SVN), til konfigurationsstyring. Dette har givet gruppen mulighed for at arbejde individuelt og i mindre grupper, uden at skabe konflikter ved synkronisering af produceret arbejde. Gruppen har undervejs benyttet at kunne gå en revision tilbage, hvis en tilføjelse har haft en uhensigtsmæssig påvirkning på resten af den skrevne kode. Der er benyttet Subclipse 1, som er et plugin til Eclipse, der giver mulighed for at benytte SVN. Der er benyttet et repository på Google s servere 2, som stiller 1 GB lagerplads til rådighed for open source projekter Projektstyring Til projektstyring er benyttet Gantt-kort s tidsplan, således de enkelte sprints i scrum blev planlagt udfra undervisningsplanen. Til at lave den overordnede tidsplan er benyttet Microsoft Excel. Der er benyttet backlogs i forbindelse med scrum, disse er ligeledes lavet i Microsoft Excel Udviklingsmiljø Grundlæggende er der benyttet papir og blyant, til at lave analyse- og designartefakter, for at undgå stort tidsforbrug med tegninger produceret på computer. Når et design har været helt på plads er dette blevet implementeret og derefter tegnet ind i SmartDraw Til at implementere kode, er benyttet Eclipse version I Eclipse er CASE-værktøjet Eclipse- UML 2008 SE 5 blevet benyttet til at generere UML-diagrammer ud fra koden. På den måde har den implementerede kode kunnet sammenlignes med de konstruerede designartefakter. 1 Lit.[11] URL[ 2 Lit.[12] URL[ 3 Lit.[13] URL[ 4 Lit.[14] URL[ 5 Lit.[15] URL[ 52

56 12. Epilog Der vil i det følgende blive konkluderet på de opnåede resultater fra dette projekt Konklusion Der er fremstillet en funktionsdygtig softwareprototype, med en server- og klient-del, som kan køres fra en almindelig pc. For at opfylde kravet om distribution, er der valgt en 3-tier opdeling af systemet. Mellem billetautomat og applikationsserver er der benyttet en distribueret applikationskerne, mens der er benyttet en remote database mellem applikations- og databaseserver. Idet det er tilstræbt at gøre softwaren forståelig, vedligeholdelsesvenlig og skalerbar, er der truffet en række designvalg omkring opdelingen af systemet, såsom uddelegering af ansvarsområder og interaktion internt i systemet. Det er valgt at benytte en PCMEF arkitektur, samt nogle udvalgte designmønstre, der hjælper med at overholde PCMEF principperne. Der har været fokus på klientdelen, hvilket betyder at serverdelen ikke overholder PCMEF principperne i samme grad. Kravet om fjernopdatering af software på klienten, er blevet indfriet ved brug af RMI- og socketkommunikation. Det er muligt at igangsætte en opdatering fra serverens grafiske brugerflade. De væsentligste mål omkring systemets funktionalitet, var at kunne udstede togbilletter. Disse mål er opfyldt idet, det er muligt at sammensætte en billet ud fra valg af stationsnavn og kundekategorier. Billetter bliver ikke fysisk udskrevet, men bliver vist i den grafiske brugerflade. Desuden blev der lavet en simpel prisberegningsmodel. Målet omkring valg af sprog, blev opfyldt ved at benytte et observer-mønster, som sikrede at alle tekster blev ændret samtidigt med at et andet sprog blev valgt. Det er muligt at skifte sprog undervejs i et billetkøb. Der er kun indført dansk og engelsk sprogunderstøttelse, men det er let at tilføje flere sprog. Der blev tilføjet mulighed for at standardsproget kunne benyttes i offline-tilstand. Kravet omhandlende udstedelse af togbilletter i offline-tilstand blev ikke opfyldt. Stationsnavne og kundekategorier kan vises i offline-tilstand, men det er ikke muligt at købe en billet, da priser og logning ikke kan benyttes offline. En billetautomat kan selv holde øje med om den er tilsluttet en server, og hvis dette ikke er tilfældet, vil den forsøge at komme online igen. Det vil være muligt at genbruge dele af systemet til andre typer af klienter, som fx mobile enheder. I forbindelse med kvalitetskontrol, ved hjælp af statistiske metoder, er det vist, at softwareprototypen kan håndtere 200 billetkøb pr. minut. Projektmålene blev dermed opfyldt, med undtagelse af kravet om offline-funktionalitet (som kun delvist blev opfyldt) og krav F1 Hændelseslog. 53

57 12.2 Perspektivering Der er lavet en grundstruktur for softwareprototypen, som kan udvides til at omfatte de brugsmønstre, der ikke blev behandlet. I forbindelse med designet af softwaren, er det holdt i tankerne, at systemet senere skulle kunne udvides med flere funtionaliteter. Det er vist at systemet er skalerbart, således vil det kunne udvides til, dels at indeholde flere togstationer, men også destinationer for fx busser og færger. Den måde hvorpå det er muligt at vælge mellem forskellige sprog, kan også benyttes i forbindelse med udvikling af andre softwaresystemer. Ved at lave et vedligeholdelsesvenligt system, vil der være brug for færre resourcer, i forbindelse med systemets drift og senere softwareudvidelse. Såfremt at billetautomaterne også udvides med at kunne foretage pladsreservationer, vil antallet af betjente salgssteder kunne nedbringes. At der er overvågning af driftstatus, betyder at der fra centralt hold kan detekteres om der opstår problemmer på de enkelte billetautomater. Dette betyder at problemmer kan løses hurtigere, og derved opnå en højere driftsikkerhed. Ud fra den generede ledelsesstatistik, vil det være muligt at optimere antallet af billetautomater på stationerne, samt at tilrettelægge salgsfremstød m.m. 54

58 13. Refleksionsdokument Der er forsøgt at holde en rød tråd gennem rapporten, ved at tage udgangspunkt i det bærende brugsmønster for projektet, nemlig brugsmønster #07 Køb af rejser. Afrapporteringen er primært sket i to-mandsgrupper, for at få en bedre dynamik i arbejdet. Gennem projektet er ligeledes forsøgt at holde en rød tråd, ved at gruppen startede med at diskutere mulighederne for projektet, og derved spore sig ind på hvilke emner der kunne være spændende. Der er forsøgt at holde en demokratisk ledelsespolitik i projektarbejdet, hvilket betyder at alle har haft lige meget at skulle have sagt. Til at forvalte projekts dokumenter, har Blackboard været benyttet, da de studerende i denne projektgruppe har haft adgang til et fælles gruppe community. Ydermere har der været anvendt SVN med et fælles repository, således at filer har kunnet deles og synkroniseres. Til at starte med, var det planlagt at lave en klient, som kunne køre offline, ved at lægge en lokal database på klienten. Dette kunne ikke opfylde semesterhåndbogens krav om distribution, og derfor er den endelige løsning ikke blevet optimal. Med optimal menes at al analyse og design, ikke er tiltænkt den løsning som det er endt op med. 55

59 14. Billedkilder Figur Kilde 3.1(a) på side 10 Lit.[18] URL[ 3.1(b) på side 10 Lit.[1] kap. 2.8, side på side 25 Lit.[2] kap. 9, side på side 26 Lit.[16] URL[/wiki/File:ModelViewControllerDiagram.svg]. 6.4 på side 28 Lit.[3] kap. 2.3, side på side 28 Lit.[3] kap. 2.3, side 5. A.1 på side 62 Lit.[5] kap , side 718. Bilag 13 på side b30 Lit.[2] kap.9.3, side

60 15. Referenceliste [1] Jim Arlow & Ila Neustadt. UML 2 and the Unified Process. Addison-Wesley, 2. udgave, [2] Leszek A. Maciaszek & Bruc Lee Liong. Pratical Software Engineering. Addison-Wesley, 1. udgave, [3] Klaus Renzel & Wolfgang Keller. Client/Server Architectures for Business Information Systems. ENTSTAND, 1. udgave, [4] Andy Georges & Dries Buytaert & Lieven Eeckhout. Stastistically Rigorous Java Performance Evaluation. GHENT UNIVERSITY, Note [5] James F. Kurose & Keith W. Ross. Computer Networking - A top-down Approach. Pearson Education International, 4. udgave, [6] Gunnar G. Løvås. Statistikk for universiteter og høgskoler. 2. udgave, [7] Erwin Kreyszig. Advanced Engineering Mathematics. 9. udgave, [8] Ole Dolriis Scrum til projektstyring. Januar [9] Poul Staal Vinje Test af software. December [10] Sun Microsystems, Inc. A Sun Developer Network Site. 07/ [11] Tigris.org Subclipse project. 23/ [12] Google. Google. 23/ [13] SmartDraw.com. the World s Most Popular Business Graphics Software. 23/ [14] The Eclipse Foundation. Eclipse. 23/ [15] Omondo, Inc. Omondo The Live UML Company. 23/ [16] Wikipedia. The Free Encyclopedia. 27/ [17] Wikipedia. Den frie encyklopædi. 27/ [18] EPF Wiki Eclipse Process Framework Wiki. 27/

61 A. Appendiks A.1 Installationsvejledning Det udviklede system består af tre programer: TicketMachine, TMManager og Server. Server skal startes på serverdelen, mens TMManager skal startes på klienten. TMManager sørger for at starte TicketMachine, samt at lukke denne ned hvis softwaren skal opdateres. Det er nødvendigt at serveren er startet før klienten startes. Når klienten er kørende, vil det være muligt at lukke serveren, hvorefter der vil kunne køres videre med begrænset funktionalitet på klienten. Både server- og klient-del kan startes direkte fra cd en. Dog er det nødvendigt at flytte klientsoftwaren fra cd en hvis man ønsker at opdatere software, idet dette kræver mulighed for at den nye software kan gemmes fysisk. Hvis dette ønskes, bør mappen ETC Billetautomat som minimum flyttes til en placering hvor der er skriverettigheder. Det vil i det følgende blive beskrevet hvordan man kan starte og nedlukke systemet. Først og fremmest beskrives det hvordan MySQL-serveren bør opsættes. Hvis MySQL-serveren er opsat på den angivne måde, kan softwaren startes uden yderligere opsætning, men ellers vil det være nødvendigt at ændre i konfigurationsfilerne. Konfigurationsfiler beskrives i et selvstændigt afsnit. A.1.1 Opsætning af MySQL-server Det antages at en MySQL-server allerede er installeret, og kører på standardporten Det vil være nødvendigt at benytte root -brugernavnet for at kunne sætte adgangsrettigheder og lignende korrekt. Ved at køre SQL-scriptet database definition.sql fra mappen SQL-scripts på cd en, vil de to nødvendige databaser: etc data og etc languages blive oprettet, og de korrekte adgangsrettigheder vil blive givet til brugeren ETC TM på localhost, som oprettes med kodeordet etc. Disse indstillinger er standardindstillinger i konfigurationsfilerne. Ønskes andre navne, vil det være nødvendigt at ændre i både SQL-script, og konfigurationsfiler. Driveren MySQL Connector/J er benyttet til at forbinde Java-program og MySQL-database. Der ligger allerede en standarddriver i ETC Server, men det er muligt at vælge en anden driver i konfigurationsfilen. A.1.2 Opstart af server og billetautomat Først og fremmest er det nødvendigt at starte serveren. Dette gøres ved at starte programmet Server.jar i mappen ETC Server. Hvis ikke jar-filer kan åbnes direkte, er det dog muligt at starte serveren ved køre startserver.bat. Dernæst kan billetautomat-softwaren startes ved at køre filen starttmmanager.bat i mappen ETC Billetautomat. Det vil også være muligt at benytte den tilsvarende jar-fil, men det vil være en fordel at anvende bat-filen, da denne giver mulighed for at lukke systemet korrekt ned. Først og fremmest vil TMManager åbne et skærmbillede der viser at billetautomaten er ude af drift. Denne vil dog forsvinde så snart selve TicketMachine softwaren er kørende. Bemærk at billetautomaten benytter fuld skærm. A.1.3 Nedlukning af server og billetautomat Ved nedlukning har det ikke betydning om server- eller klient-del lukkes ned først. Det vil være en fordel at lukke klienten ned ved at benytte kommandoen shutdown i kommandoprompten for TMManageren. Dette skyldes at selve TMManageren vil være udsynlig ved almindelig 58

62 kørsel af billetmaskinen. Først hvis billetautomaten skal opdateres, vil TMManageren blive synlig, da denne så vil vise et skærmbillede om at billetautomaten er ude af drift. A.1.4 Konfigurationsfiler Serveren vil i mappen config indeholde en xml-fil ved navn config server.xml. Denne fil indeholder indstillinger for serveren. Det er her muligt at vælge hvilke porte serveren skal lytte på, hvilken mappe som indeholder nye softwareversioner (til brug ved opdatering af software på klienter), ssl- og database-indstillinger, samt om der benyttes kø eller ej ved logning. Xmlfilen er kommenteret, så det er muligt nemt at finde de steder hvor ændringer i indstillinger er nødvendige. På billetautomaten forefindes der også en konfigurationsfil ved navn config.xml i mappen config. Her vil det være muligt at angive stationsnavnet for den aktuelle station, maskin-id, serverens ip-adresser, samt den port klienten lytter på ved software- og dataopdateringer. Det fremgår af xml-filen hvilke indstillinger der yderligere kan ændres. Der vil være en beskrivelse af alle indstillinger i selve konfigurationsfilen. Bemærk at både TMManager og TicketMachine benytter samme konfigurationsfil, og det er angivet i konfigurationsfilen hvilken TicketMachine-software der skal startes op af TMManager. A.1.5 Afinstallation Det er forholdsvist nemt at afinstallere systemet, idet mapperne ETC Billetautomat og ETC Server blot skal slettes fra systemet. Er systemet kørt fra cd er det ikke nødvendigt at fjerne nogen filer. Under alle omstændigheder vil det være nødvendigt at fjerne rydde op i MySQLdatabasen. Under SQL-scripts på cd en findes scriptet database cleanup.sql, som blot skal køres med root -rettigheder. Når dette gøres vil de to databaser etc data og etc languages bliver fjernet, sammen med brugeren ETC TM. 59

63 A.2 Reviews Reviews 1 er vigtig når der ønskes gennemført tidlige tests af eksempelvis: produkter, mellemresultater, prototyper eller artefakter før milepæle. Reviews har til formål at foretage verifikation eller validering ud fra normer og standarder for det pågældende område. I forbindelse med review af en data- eller objektmodel, foretages der verifikation af om, sytemet er beskrevet og tegnet på en hensigtsmæssig måde. Validering anvendes når brugere laver review af en prototype, eller inspicerer en sekvens af skærmlayouts for givne funktionaliteter. Reviewet s mål og forudsætninger Der er flere faktorer, der er bestemmende for udbyttet af et review. Der er forskel på om målet er at finde flest fejl, eller påvise at et system er fejlfrit. Der er forskellige typer af review, som sikrer et optimalt udbytte, ud fra de rette forudsætninger. I Walk-Through, hvor formålet er at se om et produkt fungerer, er det en forudsætning, at der er testdata 2 til rådighed. Inspektion er en helt anden kategori, det er et led i 0-fejl udvikling 3. Her er formålet at inspicere et produkt så grundigt, at det bliver fejlfrit. Review typer Der er følgende typer af reviews: Walk-Through Play-Through Fortolkende review Inspektion Godkendende review De fem mest generelle er beskrevet her, og burde være dækkende til de fleste anvendelser. Der findes dog andre varianter. Walk-Through Walk-Through anvendes for test af programkode som skrivebordstest 4, hvor reviewerne agerer maskine. Er også anvendelig til test af en prototype, hvor funktionalitet holdes op mod en kravsspecifikation. Reviewet er primært et værktøj for udvikleren. Teknikken kan anvendes på artefakter som sekvens-, analyseklasse- og designklassediagram m.m. Der er her fokus på at finde afvigelser fra softwarespecifikationerne. Play-Through Play-Through har de samme karakteristika som Walk-Through. Forskellen er at hver reviewer har en delmængde af produktet, der reviewes. Hver reviewer kommer på banen når vedkommendes del bliver aktiv, i den procedurelle gennemgang af produktet ud fra testdata. Modsat Work-Through er Play-Through ikke så anvendelig til test af prototyper, men mere velegnet til test af kommunikation i et distribueret system, hvor der er mange korte sessioner. Hver reviewer agerer de pågældende metoder der indgår i kommunikationen, i en dynamisk form. 1 Lit.[9], kap , side Fiktive eller reele data, der muliggør test af hele funktionaliteten. 3 Nul tolerence for fejl. 4 Kildekoden gennemgås i papirform. 60

64 Fortolkende review Fortolkende review har til formål, at teste om reviewerens forståelse af et produkt er i overenstemmelse med producentens opfattelse. Der er to fortolkende typer reviews, fortolkende review og inspektion. Denne type review kræver meget intens opmærksomhed fra alle deltagere. Det er nødvendigt at være godt forberedt. Ved mødeindkaldelse understreges det, at dette er et fortolkende review. Dette review er meget anvendeligt, når der skal indføres ændringer i et system. Inspektion Inspektion anvendes, som før nævnt i 0-fejl udvikling, hvor der inspiceres på et meget detaljeret nivau. Inspektion anvendes til at finde fejl i produktet, følge op på, om fejl bliver rettet og endelig måle produktets kvalitet. Inspektionen gennemføres med en høj grad af formalisme (der afviges ikke fra den planlagte mødestruktur). Der opereres med følgende rollefordelinger i gennemførelse af en inspektion: 1. Inspektionslederen, der leder de fire faser i inspektionen. 2. En eller flere inspektører, der finder fejl. 3. Forfatteren af produktet. 4. Oplæseren, som også er inspektør. 5. Referenten. Reviewet gennemføres ved at oplæseren giver sin fortolkning af produktet i mindre dele. Der fortsættes hvis inspektørene er enige, ellers konstateres det, at der er uenighed. Hvis det er en fejl, bliver denne ført til referat af referenten. Fejlen klassificeres i et skema af referenten. Fejlens karakter kan have følgende betydninger: A = blokerende fejl, B = alvorlig fejl og C = uhensigtsmæssig fejl. Det vigtigste er opfølgning på fejlene så de bliver rettet. Inspektionsreview er velegnet til White-Box test. Godkendende review Har til formål at bedømme et produkt med udgangspunkt i godkendt eller ej godkendt. Anvendes på produkter der er i en slutfase, hvor produktet bør være reviewet undervejs. 61

65 A.3 Anvendelse af Secure Sockets Layer (SSL) For at løse problemet med usikker netværkskommunikation, kan det være en fordel at benytte SSL. Til SSL benyttes der her asymmetrisk kryptering, ved hjælp af RSA (Rivest, Shamir og Adleman) algoritmen 5. For at benytte asymmetrisk kryptering, kræver det at alle parter der ønsker at kommunikere sikkert, har både en offentlig og en privat nøgle. Den private nøgle er hemmelig, og den offentlige er tilgængelig for alle parter. På figur A.1 ses en illustration af princippet for asymmetrisk kryptering. Figur A.1: Illustration af asymmetrisk kryptografi. Asymmetrisk kryptografi bygger på at en besked der er krypteret med en offentlig nøgle kan dekrypteres med den tilsvarende private nøgle. Desuden er det omvendte muligt, altså at dekryptere en besked med en offentlig nøgle, hvis den er krypteret med den private nøgle. For at gøre netværkskommunikationen sikker, er det derfor nødvendigt at serveren og hver enkel klient, har henholdsvis en privat og en offentlig nøgle. På hver host 6 skal der således placeres et keystore, der er en fil, som indeholder certifikater for denne host. Ligeledes skal der være placeret et truststore, der er en anden fil, som indeholder alle de offentlige certifikater, for de hosts som den pågældende host vil kommunikere med. Således vil hver klient have et truststore med serverens offentlige nøgle, mens serveren vil have et truststore med samtlige klienters offentlige nøgler. A.3.1 Generering af nøgler med keytool Værktøjet keytool er benyttet til at generere offentlige og private nøgler 7. Generering af serverens keystore (offentlig og privat nøgle) kan gøres med kommandoen 8 : k e y t o o l genkey a l i a s Server keyalg RSA keystore S e r v e r K e y s t o r e Argumentet -genkey angiver at der ønskes genereret et nyt nøglepar. Nøgleparret navngives ved hjælp af -alias -argumentet. Navnet på dette alias angives til Server, med argumentet -alias Server. Da RSA algoritmen ønskes benyttet, vælges dette med argumentet -keyalg RSA. Det nye nøglepar skal gemmes i et keystore. Navnet på dette keystore angives med argumentet -keystore Server Keystore. Et keystore kan indeholde mange nøglepar (alias). Findes det angivne keystore ikke allerede, oprettes et nyt. Et keystore svarer til en fysisk fil, og er beskyttet af et password. Generering af to klienters keystore (offentlig og privat nøgle) kan gøres med samme fremgangsmåde, med kommandoerne: k e y t o o l genkey a l i a s K l ient1 keyalg RSA keystore K l i e n t 1 K e y s t o r e 5 Lit.[5] kap.8.2.2, side Endepunkter i kommunikationen, fx server og klient 7 Lit.[10] URL[

66 k e y t o o l genkey a l i a s K l ient2 keyalg RSA keystore K l i e n t 2 K e y s t o r e Når der ønskes genereret et nyt nøglepar, bliver man først og fremmest anmodet om koden til det keystore hvor nøgleparret ønskes placeret - hvad enten det er et nyt eller allerede eksisterende. Dernæst anmodes der om at indtaste en række oplysninger til det nye nøglepar. Slutteligt skal disse oplysninger accepteres, og der gives mulighed for at give nøgleparret et specifikt password. For at kreere et truststore er det nødvendigt, at kende det offentlige certifikat for den host, der ønskes kommunikation med. De offentlige certifikater kan udtrækkes på følgende måde: k e y t o o l export a l i a s Server keystore S e r v e r K e y s t o r e rfc f i l e Server. c e r k e y t o o l export a l i a s K l ient1 keystore K l i e n t 1 K e y s t o r e rfc f i l e K l i e n t 1. c e r k e y t o o l export a l i a s K l ient2 keystore K l i e n t 1 K e y s t o r e rfc f i l e K l i e n t 2. c e r På samme måde som før, vælges det ønskede alias (nøglepar) og keystore. I stedet for genkey benyttes argumentet -export, som angiver at et certifikat skal eksporteres. Med argumentet -rfc angives formatet på det eksporterede certifikat. Argumentet -file Server.cer angiver filnavnet på det eksporterede certifikat. Det eksporterede certifikat er self-signed 9. Ved benyttelse af eksporteringsfunktionen, vil det være nødvendigt at indtaste password for keystore. Oprettelse af truststore for klienter (ens truststore for alle klienter): k e y t o o l import a l i a s Server f i l e Server. c e r keystore K l i e n t T r u s t s t o r e Her angiver argumentet -import at der tilføjes et certifikat til det angivne keystore. Der er nu tale om et nyt keystore, som kaldes Klient Truststore. Det certifikat, der skal betros, angives med argumentet -file Server.cer og certifikatet får alias et Server i Klient Truststore. Der skal angives et password for det nye keystore. Oprettelse af truststore for server. Alle klienters offentlige certifikat skal importeres: k e y t o o l import a l i a s K l i ent1 f i l e Klient1. c e r keystore S e r v e r T r u s t s t o r e k e y t o o l import a l i a s K l i ent2 f i l e Klient2. c e r keystore S e r v e r T r u s t s t o r e Således kan værktøjet keytool benyttes til at generere nøgler, der kan benyttes til sikker kommunikation. A.3.2 Anvendelse i Java Når der er genereret de ønskede keystores til server og klienter, skal henholdsvis server og klient vide hvilke keystores de skal benytte, når de ønsker at anvende sikker kommunikation. Dette gøres ved at sætte tre system properties ved opstart: System. s e t P r o p e r t y ( javax. net. s s l. t r u s t S t o r e, S e r v e r T r u s t s t o r e ) ; System. s e t P r o p e r t y ( javax. net. s s l. keystore, Server K e y s t o r e ) ; System. s e t P r o p e r t y ( javax. net. s s l. keystorepassword, s e r v e r ) ; Når disse system properties er sat, kan SSL anvendes ved at benytte de korrekte socket factories 10, der er specialiseret til netværkskommunikation med SSL. De samme SSL indstillinger både benyttes ved anvendelse af RMI og Sockets. 9 Et ikke kommercielt godkendt certifikat. 10 Lit.[10] URL[ 63

67 Sockets Til sockets kommunikation på serveren, kan følgende kode benyttes (pakken javax.net.ssl benyttes): SSLServerSocketFactory s s l S e r v e r S o c k e t F a c t o r y = ( SSLServerSocketFactory ) SSLServerSocketFactory. g e t D e f a u l t ( ) ; SSLServerSocket welcomingsocket = ( SSLServerSocket ) s s l S e r v e r S o c k e t F a c t o r y. c r e a t e S e r v e r S o c k e t ( port ) ; SSLSocket c o nnectionsocket = ( SSLSocket ) welcomingsocket. accept ( ) ; Og på klienten: SSLSocketFactory s s l S o c k e t F a c t o r y = ( SSLSocketFactory ) SSLSocketFactory. g e t D e f a u l t ( ) ; SSLSocket c l i e n t S o c k e t = ( SSLSocket ) s s l S o c k e t F a c t o r y. c r e a t e S o c k e t ( ipaddress, port ) ; RMI Ønskes der SSL i forbindelse med RMI kan følgende kode benyttes på serveren (pakken javax.rmi.ssl benyttes): SslRMIClientSocketFactory rmiclientsocketfactory = new SslRMIClientSocketFactory ( ) ; SslRMIServerSocketFactory rmiserversocketfactory = new SslRMIServerSocketFactory ( null, null, true ) ; // t r u e f o r f o r c e d c l i e n t a u t h e n t i c a t i o n R e g i s t r y s e r v e r R e g i s t r y = L ocateregistry. c r e a t e R e g i s t r y ( serverport, rmiclientsocketfactory, rmiserversocketfactory ) ; // Export o f o b j e c t Remote remoteobject = UnicastRemoteObject. exportobject ( object, serverport, rmiclientsocketfactory, rmiserversocketfactory ) ; Følgende kode på klienten: SslRMIClientSocketFactory rmiclientsocketfactory = new SslRMIClientSocketFactory ( ) ; SslRMIServerSocketFactory rmiserversocketfactory = new SslRMIServerSocketFactory ( ) ; R e g i s t r y s e r v e r R e g i s t r y = s e r v e r R e g i s t r y = L o c a t e R e g i s t r y. g e t R e g i s t r y ( serverhost, serverport, rmiclientsocketfactory ) ; Remote remoteobject = ( Remote ) s e r v e r R e g i s t r y. lookup ( Object ) ; SslRMIServerSocketFactory og SslRMIClientSocketFactory 11 benytter sig af henholdsvis SSLServer- SocketFactory og SSLSocketFactory, hvilket gør at opsætningen af de tre system properties også er gældende for RMI forbindelser. Således kan en ellers usikker distributionsform gøres mere sikker. 11 Lit.[10] URL[ 64

68 A.4 Oversigt over cd Dette er en oversigt over den cd, som er vedlagt rapporten. De følgende er mapper på cd en: Arbejdspapirer - dokumenter der er arbejdet med i løbet af projektforløbet, men ikke er medtaget i rapporten. Heriblandt projektgrundlaget. ETC Billetautomat - programmet ETC Billetautomater. Installationsvejledning til ETC Billetautomater kan findes i appendiks A.1 på side 58. ETC Server - programmet ETC Server. Installationsvejledning til ETC Server kan findes i appendiks A.1 på side 58. Javadoc - dokumentation for kildekoden til ETC Billetautomater. Kildekode - kildekode til ETC Billetautomater, kildekode til ETC Server og kildekode til TMManager. Litteratur - anvendt litteratur som der refereres til i rapporten, foruden bøger brugt i undervisningen. Mødedokumenter - mødeindkaldelser og referater, fra gruppemøder medvejleder, samt enkelte interne møder. Statistik dokumenter - indsamlede data i forbindelse med test af softwarens skalerbarhed, og et R-script med de benyttede udregninger. SQL-scripts - scripts til at oprette de benyttede tabeller i MySQL. Reviewmaterialer - dokumenter der er anvendt i forbindelse med review, såsom produktet der ønskes reviewet og referat fra reviewet. Udleverede dokumenter - inceptionsdokumentet i sin oprindelige form. 65

69 Det Tekniske Fakultet Maj 2009 SIP4, 4. semester Datateknologi side 1 af 7 Kontrolskema for projektrapporter ved Datateknologiuddannelsens 4. semester Kursuskode: Projektgruppe: Kursusperiode: Vejleder: Lone Borgersen Projekttitel: DTSIP4-U1-F09 Gruppe 1 ETC Billetautomater - et softwaresystem til billetautomater Formålet med dette dokument er at give studerende og vejledere en fælles reference-ramme for udarbejdelsen af projektrapporten. Udformningen gør det muligt forde studerende selv at udføre en kontrol af om rapporten opfylder de formelle krav til struktur og indhold. Dokumentet bidrager ligeledes til at studerende og vejledere får en fælles forståelse af hvilke elementer, der evalueres Rapportens struktur og indhold Som udgangspunkt forventes det, at projektrapporter har et indhold, der svarer til følgende: LoBo 1. Hovedrapport o 1.1 Prolog Forside Synopsis Forord Indholdsfortegnelse Læsevejledning o 1.2 Indledning o 1.3 Procesmodel o 1.4 Resultater Krav Softwarearkitektur Detaljeret design Implementering Test o 1.5 Støttediscipliner Konfigurationsstyring Projektstyring Udviklingsmiljø o 1.6 Epilog Konklusion Perspektivering o 1.7 Referenceliste 2. Refleksionsdokument 3. Produkt o Kildekode (Arkitekturprototype) o Andet 4. Projektets arbejdsmaterialer Bilag Projektrapport Til de med kursiv angivne elementer findes der kontrolskemaer, der hver for sig omhandler form og indhold af det pågældende element. Til sidst findes et skema, der omhandler generelle rapporttekniske elementer

70 Det Tekniske Fakultet Maj 2009 SIP4, 4. semester Datateknologi side 2 af 7 Rapportens omfang og udformning: Hovedrapporten skal have et omfang på max. 60 A4-sider og skal afleveres på papir. Layout, tekststørrelse, figurstørrelse, balance mellem tekst og figurer etc. vælges således at der opnås en læselig og effektiv formidling. Den samlede projektrapport afleveres på cd sammen med hovedrapporten. Cd en skal være mærket med oplysninger svarende til rapportens forside-oplysninger. Kontrolskemaer for enkeltdele af rapporten Skemaerne udfyldes ved i kolonnen Opfyldt at markere de krav, der menes at være opfyldt med et og de uopfyldte med -. Det udfyldte skema indsættes i rapporten under bilag. Skema nr. 1.1 Titel: Prolog Rapportelement Krav Opfyldt /- LoBo Forside Synopsis Forord Indholdsfortegnelse Læsevejledning Er der en korrekt projekttitel, som dækker projekttema og -emne? Er der navn og studienumre på alle projektdeltagere? Er der navn på vejleder(e)? Er der angivet undervisningsinstitution og kursuskode? Er der anført projektperiode? Er der en synopsis på max 150 ord? Giver synopsis en kort beskrivelse af problemstilling, løsningsmetode(r) og konklusion? Målgruppe, forhistorie, anerkendelser (med måde)? Er der overensstemmelse mellem indholdsfortegnelse, kapiteloverskrifter, afsnitsoverskrifter og sidenummerering i rapporten? Er der dækkende og forståelige titler på kapitler og afsnit, og er kapitler og underafsnit passende nummererede? Er der en oversigt over bilag? Er detaljeringsgraden (kapitler, afsnit, delafsnit) passende? Er der en læsevejledning, der fortæller, hvordan den samlede projektrapport (herunder materialet på cd en) er organiseret, og hvordan den skal læses? Skema nr. 1.2 Indledning Titel: Indledning Indeholder indledningen en beskrivelse af de rammer inden for hvilke projektet er blevet udarbejdet? Er der en indledning der fører læseren ind i projektets problemstilling Er der en redegørelse for projektets problemformulering, mål og de oprindeligt forventede resultater. Hænger problemformuleringen, målene og de forventede resultater

71 Maj 2009 Det Tekniske Fakultet LoBo SIP4, 4. semester Datateknologi side 3 af 7 sammen med de læringsmæssige mål der er stillet op for projektet? Er der en redegørelse for den metode/den overordnede fremgangsmåde, der er valgt i projektet (pkt. 1.3) Skema nr. 1.3 Titel: Procesmodel Rapportelement Krav Opfyldt /- Procesmodel Er der redegjort for den anvendte procesmodel og det faktiske forløb? Skema nr. 1.4 Titel: Resultater Rapportelement Krav Opfyldt /- Krav Analyse Softwarearkitektur Designmål Strategier Views Er der en brugsmønstermodel? Er der beskrivelse af andre krav (FURPS) Er der en beskrivelse af alle væsentlige beslutninger, der har indflydelse på de formulerede krav? Er der en domænemodel Er der en beskrivelse af alle væsentlige beslutninger, der har indflydelse på domænemodellen? Er der udarbejdet en softwarearkitektur? Er der en opstilling af designmål baseret på en analyse af de krav, som har relevans for softwarearkitekturen? Er der taget beslutning om og beskrevet strategier for væsentlige design- og konstruktionsforhold, som fx deployering, persistens, adgangsforhold, kontrolflow samt opstart og nedlukning? Er der undersøgt alternative løsningsmuligheder? Er der en sammenhæng mellem designmålene og de trufne beslutninger? Er der beskrevet fordele og ulemper ved de trufne beslutninger sammenlignet med andre muligheder? Er der et logisk view? Viser det logiske view både den statiske struktur (fx i form af et eller flere package/pakke-diagrammer) og den dynamiske struktur (fx i form af sekvensdiagrammer på tværs af packages/pakker) Er der en begrundelse for det logiske view og den systemopdeling det er et udtryk for? Er der andre relevante arkitekturviews? Er der en begrundelse for disse views og den systemopdeling, som de er et udtryk for? -? - -

72 Maj 2009 Det Tekniske Fakultet LoBo SIP4, 4. semester Datateknologi side 4 af 7 Design Implementering Test Statistik Datakommunikation Andet Resterende arbejde Er der en redegørelse for det detaljerede design af relevante dele af systemet? Er der begrundelser for det foretagne design? Er der en lavet en arkitekturprototype? Er der en redegørelse for arkitekturprototypen? Er der gengivet og kommenteret centrale dele af koden? Godtgør arkitekturprototypen, at den udarbejdede softwarearkitektur er et godt grundlag for en efterfølgende konstruktion? Er der udarbejdet test cases for og gennemført test af dele af arkitekturprototypen? Indgår der statistiske modeller i krav, analyse, arkitekturdesign, design og eller implementering? Indgår der datakommunikation i krav, analyse, arkitekturdesign, design og eller implementering? Er der en redegørelse for evt. andet der er behandlet Er der en redegørelse for evt. resterende arbejde (test-del) Skema nr. 1.3 Titel: Støttediscipliner Rapportelement Krav Opfyldt /- Konfigurationsstyring Projektstyring Caseværktøj Er der benyttet konfigurationsstyring? Er der benyttet projektstyring? Er der benyttet caseværktøj? Skema nr. 1.5 Titel: Epilog Rapportelement Krav Opfyldt /- Konklusion Perspektivering Er der en vurdering af de opnåede resultater? Er resultaterne sammenholdt med de forventede resultater? Er der en vurdering af om de opstillede mål er nået? Er der en konklusion der sammenfatter det samlede resultat? Er der en perspektivering, der udpeger konsekvenser af de opnåede resultater og som peger på evt. fremtidig indsats? Skema nr. 2 Titel: Refleksionsdokument Produktelement Krav Med-taget /-

73 Maj 2009 Det Tekniske Fakultet LoBo SIP4, 4. semester Datateknologi side 5 af 7 Refleksionsdokument Projektetablering Planlægning Gennemførelse Afrapportering Refleksionen Indeholder en kritisk gennemgang og vurdering af projektprocessen Nedenfor gives eksempler på hvad refleksionsdokumentet kan indeholde: Infrastruktur: Omhandler refleksionen ledelsesmodel, beslutningsprocesser, samarbejde, kommunikation, samarbejde med vejleder, konfliktløsning, grupperegler, arbejdet med det teoretiske stof, balance mellem proces og resultat Problemformulering: Fremgangsmåde, enighed, teorianvendelse Forvaltning af skriftligt materiale: Hensigtsmæssighed (effektivitet og kvalitet) Fremgangsmåde, opbakning (hensigtsmæssigheden af den valgte infrastruktur, bæredygtighed af problemformulering, informationsindsamling sammenhængende med /delvist overlappende med projektetableringspunktet ovenfor) Projektstyring, aktivitetsniveau Organisering af rapportskrivning, fælles arbejde, trukket rød tråd fra problemformulering til konklusion Var det fornødne grundlag for og tid til refleksionen til stede? Skema nr. 3 Titel: Kildekode (Arkitekturprototype) Produktelement Krav Opfyldt /- Arkitekturprototype Kildekode Installations-vejledning Afinstallationsvejledning Er der en udførbar arkitekturprototype? Er der en oversigt over kildekoden for arkitekturprototypen? Er der medtaget kildekode for arkitekturprototypen? Er der en beskrivelse af hvordan programmet installeres, hvis det er nødvendigt at foretage en installation? Er der en beskrivelse af hvordan programmet, i sin helhed, fjernes fra brugerens computer? - (på cd) Skema nr. 4 Titel: Projektets materialer Produktelement Krav Medtaget /- Projektets materialer Projektgrundlag Projektplaner Projektjournal Er materialer, som er produceret undervejs i projektforløbet medtaget? Nedenfor gives eksempler på sådanne materialer. Problemformulering, infrastruktur, Fase- og milepælsplaner, referencelinier, tids- og aktivitetsplaner, aktivitetsliste, huskeliste, aktivitetsbeskrivelser, Logbog, mødeindkaldelser, referater, fotografier,

74 Maj 2009 Det Tekniske Fakultet LoBo SIP4, 4. semester Datateknologi side 6 af 7 Projektresultater Andre materialer Arbejdsblade (Artefakter: Brugsmønstermodel, domænemodel,, ), Datablade (interviewdata, spørgeskemaundersøgelse, ), Resumeer (af bøger, artikler, foredrag, samtaler, virksomhedsbesøg, ), figurer, tabeller, referenceliste, ordliste Projektrammer, projektoplæg, artikler gemt lokalt, Titel: Rapporttekniske elementer Rapportelement Krav Opfyldt /- Layout Sprog Antal sider Sidenummerering Underskrifter Figurer/diagrammer Tabeller Litteratur Er der anvendt samme layout i alle kapitler? Overholder margin, skriftstørrelse og linjeafstand eventuelle krav? Er layout overskueligt/harmonisk? Er rapporten skrevet i en neutral sprogtone? Er sproget let læseligt og flydende? Er der udført stavekontrol? Er der udført kontrol af tegnsætning? Er evt. krav til antal sider overholdt? Er der korrekt og konsistent sidenummerering i rapporten? Er alle projektdeltageres personlige underskrift i/på rapporten? Er alle figurer konsekvent nummererede? Er der figurtitel og figurtekst til alle figurer? Er figurtitler og figurtekster dækkende og afklarende? Er figurerne tydelige og læsbare? Er figurerne informationsgivende og i den rette sammenhæng? Er alle tabeller konsekvent nummererede? Er der en forklarende tabeltekst til alle tabeller? Er alle søjler og rækker forsynet med parametre? Er der enheder på alle relevante rækker og søjler? Er litteratur angivet på en anerkendt form? Er alle former for litteratur som bøger, artikler og hjemmesider medtaget? Er der kildehenvisninger i teksten? Materiale som gruppen ikke selv har fremstillet i dette projekt skal være angivet med kilde! Er alle kildehenvisninger i teksten anført på samme måde? Er der kildeangivelser på figurer, grafer etc. som projektgruppen ikke selv har frembragt?

75 Maj 2009 Det Tekniske Fakultet LoBo SIP4, 4. semester Datateknologi side 7 af 7 Interne henvisninger Sporbarhed af begreber Er der interne henvisninger i nødvendigt omfang? Er de interne henvisningerne korrekte? Er der en konsekvent brug af samme betegnelse for et givet begreb igennem rapporten, således at samme begreb ikke optræder under flere forskellige betegnelser?

76 ETC Billetautomater - et softwaresystem til billetautomater BILAGSKOMPENDIUM 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:

77 Indholdsfortegnelse Forside Indholdsfortegnelse Bilag: b1 b2 b3 1 Ordliste b3 2 Product Backlog b5 3 Sprint Backlog 1 b6 4 Sprint Backlog 2 b7 5 Sprint Backlog 3 b8 6 Tidsplan b9 7 Faktortabel b10 8 Brugsmønsteroversigt og kravsporingsmatrice b14 9 Brugsmønstre b16 10 Analyseklassediagram b27 11 Sekvensdiagram for brugsmønster #05 b28 12 Pakkeoversigt b29 13 Designmønstre b30 14 Designklassediagram b33 15 Oversigt over den grafisk brugerflade. b36 16 Uddrag af semesterhåndbog b40 17 Inceptionsdokument b45 b2

78 Bilag 1: Ordliste Ord Blackboard Gantt-kort Lukket arkitektur Løs arkitektur Forklaring SDU online kursusadministration (online course-management system). Grafisk representation af et projekts tidsplan. De forskellige faser vises, og det kan ses hvor langt arbejdet er i forhold til den forventede tidsplan. I en lukket arkitektur kan et givent lag kun kommunikere med direkte tilstødende lag. I en løs arkitektur kan et givent lag kun kommunikere med de overliggende og underliggende tilstødende lag. PCMEF (Presentation, Control, Mediator, Entity and Foundation ) Velkendt 4-lags softwarearkitektur, der giver et godt grundlag for at fremstille et struktureret og vedligeholdelsesvenligt stykke software. Product backlog Repository Review Revision Select-kommando Scrum master Sprint Sprint backlog Oversigt over alle de opgaver, som producenten ønsker at der bliver behandlet i udviklingsforløbet. Repository er et centralt sted hvor filer opbevares, og flere deltagere har adgang til. Et review er når et produkt (af den ene eller den anden art) bliver vurderet med det formål at forbedre produktet. Revision, i forbindelse med konfigurationsstyring, betegner et snapshot af projektets tilstand til et givent tidspunkt. Revision svarer til en version af de filer som er under konfigurationsstyring. SELECT er en SQL kommando, der benyttes til at tilgå data i en database. Et eksempel på en select kommando kunne være: SELECT * FROM tablename;. I forbindelse med at der benyttes scrum, er der en scrum master, som bl.a. har til opgave at tage hånd om forhindringer for udviklingsgruppen og kommunikation med andre udviklingsgrupper. Sprint bruges i forbindelse med scrum, hvor der udvælges nogle opgaver som vil blive bearbejdet i sprintet. Der kan undervejs, i et sprint, ikke tilføjes flere opgaver til sprint backloggen. Oversigt over de opgaver, der er planlagt for det specifikke sprint. Fortsættes.. b3

79 Ord SSL Streng arkitektur TCP Transportslagsprotokol Trigger UDP Åben arkitektur Forklaring Secure Sockets Layer - er en krypteringsprotokol, der benyttes i forbindelse med kommunikation over netværk. Mere specifikt benyttes den til at kryptere netværkssegmenter på transportlags niveauet. Med andre ord benyttes SSL til at forhindre uvedkommende i at få del i de data der udveksles. I en streng arkitektur kan et givent lag kun kommunikere med et underliggende og tilstødende lag. Transmission Control Protocol er en transportlagsprotokol, der sikrer at datapakker der sendes over netværket ikke går tabt. En transportlagsprotokol, er en protokol der specificerer hvordan data splittes op i mindre dele, for at blive sendt over netværket, og derefter hvordan data bliver korrekt samlet hos modparten. Et stykke kode der udføres af databasen ved bestemte hændelser, fx ved indsættelse af data. Benyttes for at sikre at datamodellen overholder regler fra forretningsdomænet. User Datagram Protocol er en transportlagsprotokol, der ikke tager hånd om tab af datapakker. UDP er til gengæld velegnet til overførsel af data, hvor hastighed er vigtigere end fuldstændighed (dette gør sig ofte gældende ved fx streaming af video). I en åben arkitektur kan et givent lag kommunikere med alle andre lag. b4

80 Bilag 2: Product Backlog Product Backlog Kommende krav til produktet Sprint no. Krav Kategori Status 1 #05 Valg af sprog på billetautomat Brugsmønster Afsluttet 1 #08(#07) Almindeligt køb af billet Brugsmønster Afsluttet 1 U3 Sprog Krav Afsluttet 1 U6 Destination på skærm Krav Afsluttet 2 #03 Opdatering af software på billetautomater Brugsmønster Afsluttet 2 #04 Opdatering af data på billetautomaterne Brugsmønster Afsluttet 2 #07 Køb af rejser Brugsmønster Afsluttet 2 #09(#07) Kvik-køb af billet Brugsmønster Afsluttet 2 Serverbrugerflade Afsluttet 3 F1 Hændelseslog Krav Ikke startet 3 F2 Dagsummer Krav Afsluttet 3 #19 Generer ledelsesstatistik Brugsmønster Begyndt #01 Start opdatering af klient-software og data Brugsmønster Ikke startet #14 Udstedelse af tilgodebevis Brugsmønster Ikke startet #15 Indrapportering af logning vedrørende billetsalg Brugsmønster Ikke startet U1 Effektiv betjening Krav Ikke startet U4 Kort ekspeditionstid Krav Ikke startet R1 Drift ved systemnedbrud og lignende Krav Ikke startet P1 Samtidig anvendelse af flere billetautomater Krav Ikke startet S1 Fremtidig variation af "Køb af Rejse" Krav Ikke startet S3 Softwarestyring på billetautomat Krav Ikke startet 1 Software Krav Ikke startet 2 Løbende overførsel af data til et centralt databasesystem Krav Ikke startet #02 Opsætning af konfgurationsfil Brugsmønster Laves ikke #06 Hjælp og vejledning Brugsmønster Laves ikke #10 Pladsbestilling Brugsmønster Laves ikke #11 Afhentning af bestilte varer Brugsmønster Laves ikke #12 Annullering af bestilte varer Brugsmønster Laves ikke #13 Betaling Brugsmønster Laves ikke #16 Tilføjelse af sprogpakke på billetautomat Brugsmønster Laves ikke #17 Fjernelse af sprogpakke fra billetautomat Brugsmønster Laves ikke #18 Ændring af sprogpakke Brugsmønster Laves ikke F3 Stamoplysninger Krav Laves ikke U2 Personalisering Krav Laves ikke U5 Betjeningsformer Krav Laves ikke U7 Øve i brug af billetautomat Krav Laves ikke R2 Driftssikkerhed Krav Laves ikke S2 Regional tilpasning Krav Laves ikke Figur 2.1: Den anvendte product backlog. b5

81 Bilag 3: Sprint Backlog 1 Sprint Backlog 1 Scrummaster: Michael Timer angivet i mandetimer Første sprint 20/3-5/4 Dato: Start Krav Ansvarlig Status Tid tilbage: Planlægge sprintet (prioritering) Afsluttet #03 Opdatering af software på billetautomater Analyse Alle Afsluttet Undersøge metoder at opdatere software videreført #04 Opdatering af data på billetautomaterne Analyse videreført #05 Valg af sprog på billetautomat E, T Analyse Afsluttet Undersøge hvordan sprogpakker kan implementeres Afsluttet Design Afsluttet dokumentation af designvalg Implementering af sprog i billetautomat Afsluttet herunder beskrive hvordan sprog implementeres (database/fil?) #07 Køb af rejser F, S, M Analyse Afsluttet Undersøge hvilke data der skal gemmes i database Afsluttet Opbygning af menuer(gui, flowdiagram) Afsluttet Analyseklassediagram Afsluttet dokumentation af analyse Afsluttet Design Afsluttet Designklassediagram Sekvensdiagrammer Udvidelse af de funde databasedata i typer, tabeller m.m. Afsluttet Dokumentation af designbeslutninger Afsluttet F1 Hændelseslog(billetkøb) videreført F2 Dagsummer(automatens omsætning) videreført U3 Sprog Afsluttet U6 Destination på skærm Afsluttet #08(#07) Almindeligt køb af billet Analyse Alle Afsluttet Design Afsluttet Implementering af begrænset funktionalitet af billetautomat Afsluttet #09(#07) Kvik-køb af billet Analyse Alle Afsluttet Afslutte sprint(kladder til rapport & review) Afsluttet analyse(up): udfærdigelse af udvidede brugsmønstre, analyseklassediagram, evt. systemsekvensdiagram samt research og diskussion design(up): udfærdigelse af designsekvensdiagrammer og designklassediagram Figur 3.1: Planlægning af sprint 1. b6

82 Bilag 4: Sprint Backlog 2 Sprint Backlog 2 Scrummaster: Flemming Andet Sprint: 17/4-11/5 Dato: Start Krav Ansvarlig Status Tid tilbage: Planlægning af sprint 2 Alle Afsluttet #03 Opdatering af software på billetautomater Afsluttet Undersøgelse af netværksforbindelse (LAN/IPC) E, S Design E, S Implementation E, S Dokumentation E, S #04 Opdatering af data på billetautomaterne(databse) Analyse overført til server 6 6 Design Implementation #07 Køb af rejser oprette database med stationer/zoner og priser F Afsluttet F1 Log M videreført F2 Dagsummer refaktorering(bl.a. rette kald fra GUI, javadocs) M, F videreført #09(#07) Kvik-køb af billet Design T, F Afsluttet Implementation T, F Afsluttet Konfigurationsfil(.xml) S Afsluttet Netværksforbindelse(overførsel af software/datafiler) S Afsluttet Distribuering(beskrivelse) S Afsluttet Simpel server S,T,E Afsluttet design/implementering tekstbaseret brugerflade(grafisk) T Afsluttet håndtering af softwareversion T, E Afsluttet serverdatabase T, M Afsluttet håndtering af klienter T, E Afsluttet Dokumentation af arbejde Alle Afsluttet Opfølgning og afslutning af sprint 2 Alle Afsluttet Figur 4.1: Planlægning af sprint 2. b7

83 Bilag 5: Sprint Backlog 3 Sprint Backlog 3 Scrummaster: Thomas Tredje sprint: 12/5-20/5 Dato: Start Krav Status Tid tilbage: Planlægning af sprint F1 Log Afsluttet Statistik #19 Generer ledelsesstatistik Afsluttet F2 Dagsummer Afsluttet stresstest/statistik teori Afsluttet kode(til afvikling af statistikmåling) Afsluttet udførsel Afsluttet dokumentation overført til tidsplan Genstart af CCustomerSession Afsluttet Timer tilbage Arbejdstimer tilbage i sprint Start Dato Timer tilbage Arbejdstimer tilbage i sprint Start Dato Timer tilbage Arbejdstimer tilbage i sprint Start Dato Figur 5.1: Planlægning af sprint 3. b8

84 Bilag 6: Tidsplan Figur 6.1: Tidsplan for projektperioden. Figur 6.2: Tidsplan for projektperioden. b9

85 Bilag 7: Faktortabel Faktor og Kvalitetsscenarie Fleksibilitet og fremtidig udvikling Betydning Succesprioritet Funktionalitet (Functionality) F1 Hændelseslog Det skal være muligt i en log på billetautomaten at se alle transaktioner i forbindelse med et rejsekøb og tidspunktet for disse transaktioner. F2 Dagsummer At kunne registrere billetautomaters omsætning (dagsummer) og betalinger centralt. Se specifikke krav på side 18 og 25 i inceptionsdokumentet (bilag 17). F3 Stamoplysninger For hver billetautomat skal det være muligt at angive en række stamoplysninger: gyldighedsperiode, region, samarbejdspartnere, betalingskorttyper, billetautomatnummer, pinkodeterminalnr., billetautomat tlf. nr., stationsnr. Se side i inceptionsdokumentet (bilag 17). Anvendelighed (Usability) U1 Effektiv betjening Billetautomaten skal være hurtig og nem at betjene. Hændelseslog for billetautomater gemmes så vidt også muligt i det centrale databasesystem. Er der ingen forbindelse til dette system, gemmes loggen lokalt indtil der igen er Stor betydning for ETC, i forbindelse med sikkerhed og dokumentation af betalinger. Mellem betydning for softwarearkitektur. forbindelse. Se F1 Hændelseslog. Vigtigt for ETC i forbindelse med bogføring. Dette er nødvendigt at implementere for at kunne lave fyldestgørende logning, samt sikre billetautomatens almindelige funktionalitet. Menuer o.lign. gøres intuitivt enkle og hurtige at betjene. På et senere stadie kunne det være en mulighed at tilegne sig større viden omkring brugervenlighed, eller få hælp til dette fra tredjepart. Mellem betydning for softwarearkitektur. Vigtig for ETC i forbindelse med logning og opsætning af billetautomater. Lille softwarearkitekturmæssig betydning. Stor betydning for kundevenligheden i ETC. Stor softwarearkitekturmæssig betydning, idet data skal være klar når de skal bruges, og der derved ikke opleves unødigt lange svartider i systemet. Risiko Høj Middel Høj Middel Høj Lav Høj Lav Fortsættes.. b10

86 Faktor og Kvalitetsscenarie Fleksibilitet og fremtidig udvikling Betydning Succesprioritet Risiko Lav Høj U2 Personalisering Det skal være muligt at give kunden en personlig kode til billetautomaterne, så kunden kan få en individuel behandling af en billetautomat, som kender kundens normale rejsemønster (fx den foretrukne rejse). U3 Sprog Kunden skal kunne vælge mellem dansk (standard), engelsk eller tysk. Der skal være mulighed for udvidelse til valg mellem flere sprog. U4 Kort ekspeditionstid Ekspeditionstiden skal være kort, men ikke nødvendigvis ens per ekspedition. Kravet forventes opfyldt sent i forløbet. Mindre betydning for ETC. Ekstra avanceret service for kunder der ønsker dette. Der vil være mulighed for valg af dansk, engelsk eller tysk, samt opdatering af sprog. Senere vil det med stor sandsynlighed være nødvendigt at tilføje mulighed for tilføjelse, ændring og fjernelse af sprogpakker. 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. Mellem 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. Middel Middel Høj Middel U5 Betjeningsformer Det skal være muligt at vælge mellem en kvik-betjening eller en vejledt betjening. Vejledt betjening implementeres sidst i forløbet. Softwarearkitekturen skal således give anledning til en fornuftig ydeevne i systemet. Stor betydning for ETC, idet dette vil gøre det muligt at have færre betjente salgssteder. Middel Lav U6 Destinationer på skærm Kunden skal kunne angive sin destination ved valg af stationsnavn. Destinationen kan fx vælges ud fra en alfabetisk liste hvor de ti mest benyttede destinationer står øverst. Destinationen kan vælges fra en oversigt over de ti mest brugte destinationer. Ønskes andre stationer vil der være mulighed for at vælge et begyndelsesbogstav, og dernæst den ønskede station. Mindre softwarearkitekturmæssig betydning. Vigtig for ETC, i forbindelse med hurtig og effektiv udnyttelse af billetautomater. Af mindre betydning for softwarearkitektur. Høj Lav Fortsættes.. b11

87 Faktor og Kvalitetsscenarie Fleksibilitet og fremtidig udvikling Betydning Succesprioritet Risiko Lav Middel U7 Øve i brug af billetautomat Det skal være muligt for kunder og ETC s personale at øve sig i brugen af billetautomaten i et sandkassemiljø. Dette skal kunne gøres via internettet. Pålidelighed (Reliability) R1 Drift ved systemnedbrud og lign. 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. R2 Driftssikkerhed Billetutomatkonceptet skal være driftssikkert. En billetautomat må højst være ude af funktion i sammenlagt 6 timer om måneden. Ydeevne (Performance) P1 Samtidig anvendelse af flere billetautomater Flere billetautomater skal samtidigt kunne anvendes og indrapportere til det centrale databasesystem. Der må i den Kravet opfyldes sent i forløbet. Mindre betydning for ETC, idet billetautomaterne forventes at være nemme at benytte uden forudgående træning. Systemet implementeres så det er muligt at købe billet ved systemnedbrud. Der implementeres mulighed for at lave statistik over oppetiden. Dette vil kunne bruges til at dokumentere at systemet er tilstrækkeligt stabilt, efter systemet er sat i drift. I den forbindelse skal overvågning og redundans overvejes. Det sikres at systemet kan håndtere flere samtidige billetautomater. Samtidigt skal systemet være så effektivt, at der ikke opstår ventetid ved mange samtidige brugere. forbindelse ikke opstå ventetid. Integration, vedligeholdelse og flytbarhed (Supportability) Mindre betydning for softwarearkitekturen. Meget vigtigt for kundevenlighed, og sikkerhed. Stor betydning for softwarearkitektur. Vigtigt for ETC, da billetautomaterne skal være driftssikre. Softwarearkitekturen skal designes så systemet bliver stabilt. Meget vigtig for ETC. Meget vigtigt for softwarearkitektur. Høj Høj Høj Høj Høj Høj Fortsættes.. b12

88 Faktor og Kvalitetsscenarie Fleksibilitet og fremtidig udvikling Betydning Succesprioritet S1 Fremtidig variation af Køb af Rejse #07 Køb af rejser skal kunne ændres, fx mht. destinationer, billettyper, kundekategorier og lign. S2 Regional tilpasning Det skal være muligt at tilpasse billetautomaten til regionale vilkår. S3 Softwarestyring på billetautomat Det skal være muligt at opgradere billetautomaterne on-line med nye data og nyt programmel. Det skal herunder være muligt at føre en log over softwareversioner og dataversioner m.m. på hver billetautomat. Betingelser () 1 Software Systemet skal udvikles vha. Java og MySQL. 2 Løbende overførsel af data til et centralt databasesystem. Det vil være muligt at opdatere disse data fra centralt hold. Vha. dataset der kan opdateres fra centralt hold, vil det være muligt at tilpasse billetautomaterne til regionale forhold. Det vil være muligt at opdatere data, samt software fra centralt hold. Der er ikke umiddelbart muligt at ændre programmeringssprog på et senere tidspunkt. Der tilstræbes databaseuafhængighed, således der er mulighed for at skifte databaseteknologi. Data sendes til det centrale databasesystem såfremt der ikke opstår ventetider herved. Er det ikke muligt at etablere forbindelse til det centrale databasesystem, eller er svartiderne for lange, gemmes dataene midlertidigt lokalt. Meget vigtig for ETC. Meget vigtigt for softwarearkitektur. Vigtigt for brugervenligheden Vigtigt for softwarearkitektur. Meget vigtig for ETC, idet dette kan forhindre omkostninger ved manuelt at opdatere billetautomater. Meget vigtig for udarbejdelse af systemarkitektur. Kravet er vigtigt for ETC. Vigtigt for softwarearkitektur. Vigtigt for at sikre data mod hærværk på billetautomater, strømafbrydelser o.lign. Vigtigt for softwarearkitektur. Risiko Høj Høj Middel Høj Høj Høj Høj Høj Høj Høj b13

89 Brugsmønsteroversigt og kravsporingsma- Bilag 8: trice 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 8.1: Oversigt over de brugsmønstre der vedrører emner som ønskes behandlet. De id-numre der er markeret med *, er behandlet i inceptionsdokumentet b14

90 Brugsmønster id: Krav: F1 Hændelseslog x x x F2 Dagsummer x x x F3 Stamoplysninger x - U1 Effektiv betjening x x U2 Personalisering x x U3 Sprog x x x x x x U4 Kort ekspeditionstid x x U5 Betjeningsformer x x U6 Destinationer på skærm x U7 Øve i brug af automat R1 Drift ved systemnedbrud og lignende x x x x R2 Driftssikkerhed x x P1 Samtidig anvendelse af flere automater x S1 Fremtidig variation af Køb af rejse x x x x x S2 Regional tilpasning x x x x S3 Softwarestyring på automat x x x x Tabel 8.2: Kravsporingsmatrice, hvor brugsmønstre kobles sammen med de krav der vedrører disse. Et x betyder at kravet er indeholdt i brugsmønstret og - betyder at kravet er indeholdt i det udvidede brugsmønster. Krav udvalgt til projektet er markeret med gråt. b15

91 Bilag 9: Brugsmønstre Brugsmønster: Start opdatering af klientsoftware og data ID: 01 Aktører: Tid, Administrator Formål: At starte opdatering af software og data på billetautomater. Oversigt: Ved ny software/konfiguration til billetautomater, kan installationen foretages fra centralt hold. Administratoren igangsætter installationen. Ved tidsbestemte opdateringer (fx takster og lignende) startes opdateringen automatisk. Opdateringen kan omfatte destinationer, billettyper, kundekategorier, regionale forhold, samt softwareopdatering. Opdateringen bør ske uden brugerne af billetautomaterne bemærker dette. Fra centralt hold, håndteres hvilke softwareversioner de enkelte billetautomater har. Reference: R2 Driftssikkerhed, S1 Fremtidig variation af Køb af rejse, S2 Regional tilpasning, S3 Softwarestyring på automat, 1 Software Brugsmønster: Opsætning af konfigurationsfil ID: 02 Aktører: Administrator Formål: Oversigt: Reference: At opsætte konfigurationsfiler til individuelle billetautomater, på forskellige togstationer. F3 Stamoplysninger, U3 Sprog, S1 Fremtidig variation af Køb af rejse, S2 Regional tilpasning, S3 Softwarestyring på automat, 1 Software b16

92 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: Ingen. Interessenter: ETC: ønsker mulighed for at opdatere software på billetautomater fra centralt hold, da dette vil lette vedligeholdelsesarbejdet betragteligt. Prækondition: Ingen. Postkondition: 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. 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, 2 og 3. Status: Analyse påbegyndt i 1. sprint. Kommentarer: Ingen. b17

93 Brugsmønster: Opdatering af data på billetautomaterne ID: 04 Formål: At kunne opdatere billetpriser, destinationer, sprog og lignende informationer på billetautomaterne. Oversigt: Administrator kan initialisere opdatering af data fra den centrale server. Herefter vil systemet automatisk blive opdateret, ved at serveren underretter alle billetautomater. Hvis en billetautomat ikke har forbindelse til serveren, er det billetautomatens opgave at undersøge om nye data er tilgængelige, når der igen er oprettet forbindelse. Primære aktører: Administrator. Sekundær aktører: Interessenter: Prækondition: Postkondition: Ingen. ETC: ønsker mulighed for at opdatere data på billetautomater fra centralt hold, da dette vil lette administrationsarbejdet betragteligt. Ingen. Ingen. Aktør 1. Opdateringen initialiseres af administrator. System 2. Serveren underretter alle forbundne klienter, om at nye data er tilgængelige. 3. Billetautomaterne sammenligner nuværende dataversion med den tilgængelige dataversion på serveren. 4. Billetautomaterne henter de nye data, blokkerer skærmen på et tidspunkt hvor billetautomaten ikke benyttes, indlæser data og frigiver skærmen igen. Alternative forløb: Ingen. Krydsreferencer: 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. Der ses bort fra at bestemte data kan have en gyldighedsperiode. Der ses ligeledes bort fra logning af dataversion, i dette brugsmønster da dette behandles senere. Kommentarer: Ingen. b18

94 Brugsmønster: Valg af sprog på billetautomat ID: 05 Formål: At give mulighed for brugertilpasning. Oversigt: Når kunden ønsker at betjene en billetautomat, kan der vælges mellem flere sprog for menuer og lignende. Dansk er standardvalg. Ved afsluttet billetkøb vælges sproget dansk automatisk. Dansk vælges ligeledes hvis ikke automaten er benyttet i et bestemt tidsrum. Primære aktører: Kunde Sekundær aktører: Ingen. Interessenter: Kunde: Ønsker mulighed for at skifte til sit foretrukne sprog. ETC: Ønsker at øge brugervenligheden ved at tilbyde denne funktionalitet. Prækondition: Ingen. Postkondition: Nyt sprog er valgt, og alle tekster er ændret. Aktør 1. Kunden vælger menupunktet Vælg sprog. 3. Kunden vælger det ønskede sprog. System 2. Systemet viser en liste over mulige sprog. 4. Systemet skifter til det valgt sprog, og returnerer til det sted sprogfunktionen blev kaldt. Alternative forløb: Ingen. Krydsreferencer: U3 Sprog, 1 Software Iteration: 1, 2 og 3. Status: Valg af sprog indgår i flere brugsmønstre, og derfor forventes funktionaliteten udvidet løbende. Timeout vil ikke være en del af dette brugsmønster. Alle destinationer vil foreløbigt være på dansk. Kommentarer: Ingen. Brugsmønster: Hjælp og vejledning ID: 06 Aktører: Kunde Formål: Oversigt: Reference: At give hjælp og vejledning i benyttelse af billetautomaten. U1 Effektiv betjening, U2 Personalisering, U3 Sprog, U4 Kort ekspeditionstid, U5 Betjeningsformer, 1 Software b19

95 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. 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. Fortsættes... b20

96 Aktør System 15. Kunden betaler. 16. Systemet godkender betaling, registrerer transaktionen og udskriver billet. Alternative forløb: Krydsreferencer: #07.1 Køb af rejser: Annullering af køb 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, 2 og 3. 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. Brugsmønster: Køb af rejser: Annullering af køb ID: 07.1 Formål: At annullere køb af billetter m.m. Oversigt: Kunden ønsker at annullere det igangværende køb. Primære aktører: Kunde. Sekundær aktører: Ingen. Prækondition: Kunden er i gang med et køb og har endnu ikke betalt. Postkondition: Købet er annulleret. Aktør 1. Kunden ønsker at annullere køb. System 2. Systemet præsenterer kunden for en mulighed for at annullere køb. 3. Kunden accepterer. 4. Systemet nulstiller valgene og vender tilbage til hovedmenuen. b21

97 Brugsmønster: Almindeligt køb af billet ID: 08 Formål: At købe en billet. Oversigt: Kunden vælger en billet ved et frit valg mellem afrejsestation, destination, billettype, serviceniveau, kundekategori og antal. Primære aktører: Kunde. Sekundær aktører: PBS. Interessenter: Kunde: Ønsker at købe en billet. ETC: Ønsker at sælge en billet. Prækondition: Ingen. Postkondition: Kunden har fået udleveret det ønskede produkt. Systemet har registreret transaktionen. Aktør 1. Kunden ønsker at købe en almindelig billet. 3. Kunden vælger en afrejsestation. System 2. Systemet giver mulighed for valg af alle tilgængelige stationer og anmoder om valg af afrejsestation. 4. Systemet giver mulighed for valg af alle tilgængelige stationer og anmoder om valg af destination. 5. Kunden vælger en destination. 6. Systemet registrerer destinationen og anmoder om rejsedato. 7. Kunden vælger en rejsedato. 8. Systemet registrerer rejsedato og anmoder kunden om at vælge kundetype. 9. Kunden vælger kundetype og 10. Systemet viser kundens valg antal. og anmoder om godkendelse. 11. Kunden godkender køb. 12. Systemet anmoder om betaling. 13. Kunden betaler. 14. Systemet godkender betaling, registrerer transaktionen og udskriver billet. Alternative forløb: Ingen. Krydsreferencer: udvider Brugsmønster #07 Køb af rejser. Iteration: 1, 2 og 3. Status: Kommentarer: Det tænkes muligt at gå tilbage til forrige trin og foretage nye valg. Det vil i første omgang kun være muligt at vælge kundekategori og antal. b22

98 Brugsmønster: Kvik-køb af billet ID: 09 Formål: At købe en billet ud fra de 10 mest anvendte destinationer. Oversigt: Kunden vælger en billet ved et begrænset valg mellem destination, billettype, serviceniveau, kundekategori og antal. Primære aktører: Kunde. Sekundær aktører: PBS. Interessenter: Kunde: Ønsker at købe en billet ud fra et enkelt og hurtigt valg. ETC: Ønsker at sælge en billet. Prækondition: Ingen. Postkondition: Kunden har fået udleveret det ønskede produkt. Systemet har registreret transaktionen. Aktør 1. Kunden ønsker at købe en kvik-købs billet. System 2. Systemet giver mulighed for valg af de 10 mest anvendte stationer og anmoder om valg af destination. 3. Kunden vælger en destination. 4. Systemet registrerer destinationen og anmoder kunden om at vælge billettype. 5. Kunden vælger billettype og 6. Systemet viser kundens valg antal. og anmoder om godkendelse. 7. Kunden godkender køb. 8. Systemet anmoder om betaling. 9. Kunden betaler. 10. Systemet godkender betaling, registrerer transaktionen og udskriver billet. Alternative forløb: Ingen. Krydsreferencer: udvider Brugsmønster #07 Køb af rejser. Iteration: 2 og 3. Status: Kommentarer: Det tænkes muligt at gå tilbage til forrige trin og foretage nye valg. Der tages ikke højde for hvordan en pladsbestilling laves(mht. køreplan og ledige pladsers beliggenhed i det pågældende tog). Det vil i første omgang kun være muligt at vælge kundekategori og antal. b23

99 Brugsmønster: Pladsbestilling ID: 10 Aktører: Kunde Formål: At kunne bestille en bestemt plads i toget. Oversigt: Reference: udvider Brugsmønsteret #07 Køb af rejser. Brugsmønster: Afhentning af bestilte varer ID: 11 Aktører: Kunde Formål: At afhente en bestilling bestående af et eller flere produkter. Oversigt: Et eller flere produkter som er bestilt på forhånd afhentes ved angivelse af booking-nr for bestillingen. Når kunden har opgivet booking-nr, vises oplysninger om det eller de bestilte produkter for kunden til godkendelse. Reference: udvider Brugsmønstret #07 Køb af rejser. Brugsmønster: Annullering af bestilte varer ID: 12 Aktører: Kunde Formål: At annullere købet af en rejse og/eller en bestilling helt eller delvist. Oversigt: Et produkt som er bestilt og som ikke er afhentet kan annulleres helt eller delvist ved angivelse af booking-nr. Når kunden har opgivet booking-nr, vises oplysninger om det eller de bestilte produkter (herunder status). Kunden kan dernæst annullere hele bestillingen eller dele af den. Hvis bestillingen er betalt på forhånd, får kunden et tilgodehavende. I annulleringen kan også indgå de bestillinger, der aktuelt er udført på billetautomaten. Reference: udvider Brugsmønsteret #07 Køb af rejser. b24

100 Brugsmønster: Betaling ID: 13 Aktører: Kunde Formål: At betale et køb af en rejse. Betaling kan ske vha. Dankort/kreditkort eller mønter. Oversigt: De produkter, der bliver købt på billetautomaten, skal kunne betales med enten mønter, betalingskort eller kreditkort. Det skal ikke være muligt at kunne betale med en kombination af mønter og kort ved det samme køb. Billetautomaten skal kune modtage de danske mønttyper: 50 øre, 1 kr., 2 kr., 5 kr., 10 kr. og 20 kr. Billetautomaten skal for hvert møntindkast vise, hvor meget der mangler at blive betalt af billetprisen. Der skal kunne betales med magnetstribe- og chipkort. Billetautomaten skal først anmode om indstikning af kortet, efter at kunden har valgt produkt. Det skal være muligt af fravælge kvitteringen. Reference: udvider Brugsmønsteret #07 Køb af rejser. Brugsmønster: Udstedelse af tilgodebevis ID: 14 Aktører: Kunde Formål: At udstede et tilgodebevis. Oversigt: Reference: udvider Brugsmønsteret #07 Køb af rejser. Brugsmønster: Indrapportering af logning vedrørende billetsalg ID: 15 Aktører: Kunde, Tid Formål: At indsende akkumuleret logning til centralt hold. Oversigt: Logning indrapporteres til det centrale databasesystem, såfremt der er forbindelse til dette. Hvis en billetautomat har mistet forbindelsen til det centrale databasesystem, opsamles logningen lokalt, indtil der igen er forbindelse. Reference: F1 Hændelseslog, F2 Dagsummer, F3 Stamoplysninger, R1 Drift ved systemnedbrud og lignende, P1 Samtidig anvendelse af flere automater, 1 Software, 2 Løbende overførsel af data til et centralt databasesystem b25

101 Brugsmønster: Tilføjelse af sprogpakke på billetautomat ID: 16 Aktører: Administrator Formål: Mulighed for at tilføje flere sprog til billetautomaterne. Oversigt: Reference: Brugsmønster #01 Start opdatering af klientsoftware og data. U3 Sprog, 1 Software Brugsmønster: Fjernelse af sprogpakke fra billetautomat ID: 17 Aktører: Administrator Formål: Mulighed for at fjerne et sprog fra billetautomaterne. Oversigt: Reference: Brugsmønster #01 Start opdatering af klientsoftware og data. U3 Sprog, 1 Software Brugsmønster: Ændring af sprogpakke ID: 18 Aktører: Administrator Formål: Oversigt: Reference: Mulighed for at ændre en sprogpakke på billetautomaterne. Brugsmønster #01 Start opdatering af klientsoftware og data. U3 Sprog, 1 Software Brugsmønster: Generer ledelsesstatistik ID: 19 Aktører: ETC s ledelse Formål: At fremstille ønsket statistik over systemets brug. Oversigt: Reference: Bilag 2 i inceptionsdokument. F1 Hændelseslog, F2 Dagsummer, F3 Stamoplysninger, R2 Driftssikkerhed,1 Software b26

102 Bilag 10: Analyseklassediagram Station stationid stationname getstation Purchase typeofpurchase calculateprice makesubpurchase cancelpurchase acceptpurchase maketicket deliverproduct recordtransaction QuickPurchase showtoptenstations makesubpurchase OrdinaryPurchase showallstations makesubpurchase CustomerSession timeout changelanguage closesession Language prefix langname sentences getsentence Ticket timestamp validperiod departurestation destination ticketprice tickettype servicetype customercategory ticketinfo getticket Log timestamp softwareversion dataversion operationalstatus connectionstatus ticketmachineid getlog TicketMachineData listofallstations toptenstations zoneprice tickettypeprice servicetypeprice customercategoryprice ticketmachineid serverid softwareversion dataversion operationalstatus connectionstatus getlistofallstations gettoptenstations getzoneprice TicketMachine SubPurchase departurestation destinationstation datetime tickettype numberoftickets showstations choosedeparturestation choosedestinationstation choosetickettype choosequantity buytrip Figur 10.1: Analyseklassediagram for TicketMachine. b27

103 Bilag 11: Sekvensdiagram for brugsmønster #05 :CLanguage language :CLanguage observer: Observer Customer getinstance() getinstance() setlanguage(prefix: String) setchanged() notifyobservers() Loop[for each observer in Observer] update(this: Observable, null: Object) getsentence(textcategory: String, texttype: String) Figur 11.1: Designsekvensdiagram for brugsmønster # 05 Valg af sprog på billetautomat. b28

104 Bilag 12: Pakkeoversigt TicketMachine presentation gui PInit PJPanel PJButtonObserver PJLabelObserver layout panels control CInitTicketMachine CLanguage CCustomerService domain entity mediator EPurchase MDefaultSettings ETicket EStation MEntityQuery ECustomerCategory MStationHandler foundation FDBConnection FDriverWrapper FXMLReader FLanguage FMediaterService FNetWorkConnection acquaintance IAInitializable IAStation IARemoteObserver IAConfiguration IATicket IARemoteObservable IALanguage IAXMLReader IAStationConnection TicketMachineManager presentation PManagerInit PBlockScreenPanel control CManager CDownLoadSoftWare domain foundation FNetworkConnection FFileConnection FFileHandler acquaintance IARemoteObservable IASoftwareController IARemoteObserver IAManagerPresentation IAXMLHandler FXMLReader FClientServerCom Server presentation PInit PJPanel PTurnOverPanel PMainPanel PClientsPanel PSoldTicketsPanel PMainSouthPanel PConnectionController PBarChart PUpdateDataPanel PClientsTableModel PUpdateSoftwarePanel PConnectionTask domain DSumOfDay DPurchaseLogStorage DSoftwareController ETCCalendar DPurchaseLogDispatcher DLogFacility DLogFacilityWithoutQueue DPurchaseQueue foundation FStationsConnection FLanguageConnection FFileServerConnection FFileServer FConnectionMonitor- Observable FClientServerCom FNetworkConnection FXMLReader FDBConnections FDriverWrapper FSoldCategories FSumOfDay FInsertSQLStorage acquaintance IAStation IAXMLReader IAStationsConnection IATicket IASoftwareController IALanguageConnection IAPurchase IARemoteObservable ARemoteObservable IALogFacility IARemoteObserver APurchaseLogTransferObject Figur 12.1: Oversigt over klasserne i systemet. b29

105 Bilag 13: Designmønstre Figur 13.1: Oversigt over Facade-mønsteret. Figur 13.2: Oversigt over Abstract Factory-mønsteret. b30

106 Figur 13.3: Oversigt over Chain Of Responsibility-mønsteret. Figur 13.4: Oversigt over Observer-mønsteret. b31

107 Figur 13.5: Oversigt over Mediator-mønsteret. b32

108 Bilag 14: Designklassediagram b33

109 TMManager presentation acquaintance PManagerInit -device: GraphicsDevice -blockscreenframe : JFrame -blockscreenpanel : PBlockScreenPanel PManagerInit () blockscreen() unblockscreen PBlockScreenPanel -labelfont: Font PBlockScreenPanel () IARemoteObservable addremoteobserver() removeremoteobserver notifyallobservers() checkconnection() control CManager -configfile: String -process: Process -xml: IAXMLHandler -userinterface : IAManagerPresentation -pout: PrintStream -pin: Scanner -in: Scanner -path: String -filehandler: FFileHandler -downloadsoftware : CDoownloadSoftware main() getsoftwareobserver (): CDownloadSoftware restarttm() -startticketmachine () -listenforshutdown () CDownloadSoftware -networkconnection : FNetworkConnection -filehost: String -filepath: String -controllerhost : String -fileport: int -controllerport : int -clientport: int -automatid: String -softwarecontroller : IASoftwareController -observerremoteobject : IARemoteObserver CDownloadStoftware () unregister() update() checkconnection () IASoftwareController setnewestsoftware() getnewestsoftware(): String IARemoteObserver update() unregister() checkconnection() IAManagerPresentation blockscreen() unblockscreen() domain IAXMLHandler foundation replacevalue() getvalue(): String FNetworkConnection -rmiclientsockefactory : SslRMIClientSocketFactory -rmiserversocketfactory : SslRMIServerSocketFactory -serverregistry: Registry -clientport: int FNetworkConnection () getremoteobject (): Remote createremoteobject (): Remote FXMLHandler -docbuilderfactory : DocumentBuilderFactory -docbuiler: DocumentBuilder -doc: Document -file: File FXMLHandler () replacevalue () getvalue(): String FFileConnection -sslsocketfactory: SSLSocketFactory -clientsocket: SSLSocket -csc: FClientServerCom -filename: String FFileConnection () getfilename (): String FFileHandler -path: String -FFileHandler() deletefile(): boolean FClientServerCom -socket: Socket -inputstream: inputstream -inputscanner : Scanner -outputwriter: PrintWriter FClieenServerCom () readfromsocket (): String writetosocket() getfile() Figur 14.1: Designklassediagram for TMManager. b34

110 . b35

111 Bilag 15: Oversigt over den grafisk brugerflade. GUI containment hierarchy tree 1a JPanel North PJPanel PMainTitlePanel JLabel -title JLabel -station name 1b JPanel West JPanel PMainBorderPanel (Border Layout) 1c JPanel Center (Grid Layout PJPanel PStationsPanel -Most used stations (Grid Layout) JButton -a station name JButton -a station name... PCategoryBorderPanel 1d JPanel East PJPanel PHelpPanel PJPanel POtherDestinationsPanel JButton -help JButton -otherdestinations PDestinationBorderPanel 1e JPanel South PJPanel PLanguagePanel JButton -select language JButton -select language 2a JPanel North PJPanel PMainTitle JLabel -title JLabel -station name 2b JPanel West PJPanel PReturnPanel JButton -return JPanel PDestinationBorderPanel (Border Layout) 2c JPanel Center (Grid Layout) PJPanel PStationsPanel -all stations (Grid Layout) JButton -a station name JButton -a station name... PCategoryBorderPanel 2d JPanel East PJPanel PHelpPanel JButton -help PInit 2e 3a JPanel South JPanel North PJPanel PLanguagePanel PJPanel PCategoyTitlePanel JButton -select language JButton -select language JLabel -title JLabel -destination JPanel PCategoryBorderPanel (Border Layout) 3b JPanel West JPanel 3c Center (Vertical Box Layout) PJPanel PCategoryPanel (Grid Layout) PJPanel PTotalPricePanel JLabel -category JLabel -quantity JButton -decrease qty. JButton -increase qty. JLabel -price JLabel -total price JButton -print ticket PTicketBorderPanel 3d 3e JPanel East JPanel South PJPanel PLanguagePanel JButton -select language JButton -select language 4a/b/d/e JPanel North/West/East/South JPanel PTicketBorderPanel (Border Layout) 4c JPanel Center JPanel PTicketOutPanel (Vertical Box Layout) JLabel -departure station JLabel -destination station JLabel -quantity & category (for each category) JLabel -total price Figur 15.1: Opbygning af den grafiske brugerflade på billetautomaten. Hvert skærmbillede opbygges med et borderlayout. b36

112 Figur 15.2: Billetautomatens forside. Et kvik-køb fortages ved at vælge en station nævnt ved 1c. Figur 15.3: Oversigt over alle de tilgængelige destinationer. Dette skærmbillede bruges ved et almindeligt køb. b37

113 Figur 15.4: Oversigt over de forskellige billetkategorier, der kan vælges imellem. Figur 15.5: Simuleret udskrift af en billet. Viser en kundes valg, samt den samlede pris. b38

114 Figur 15.6: Opbygning af den grafiske brugerflade for severen. Viser status på de tilsluttede billetautomater Figur 15.7: Udkast til ledelsesstatistik. Viser de sidste 7-dages omsætning, på en udvalgt station Figur 15.8: Udkast til ledelsesstatistik. Viser hvordan billetsalget er fordelt på billetkategorier. b39

115 Bilag 16: Uddrag af semesterhåndbog SEMESTERHÅNDBOG - FORÅRET 2009 AKTIVITET: PROJEKT (PRO) MÅLSÆTNING: at den studerende opnår kompetence til systematisk og disciplineret at planlægge og gennemføre et softwareudviklingsprojekt, som resulterer i en softwareløsning, som har et begrundet design og bestemte målbare kvalitetsegenskaber er distribueret og hvor der er anvendt statistiske modeller til analyse og vurdering af softwareløsningens kvalitet, eller på anden måde er anvendt statistiske modeller i softwareløsningen MÅLBESKRIVELSE: den studerende forventes at kunne gennemføre etablering af et projekt samt planlægge og gennemføre projektet i overensstemmelse hermed anvende agil projektplanlægning tilegne sig og kritisk anvende viden indenfor de fagligheder, som projektet omfatter, herunder udarbejde et forslag til en forståelig, vedligeholdelsesvenlig og skalerbar softwarearkitektur, der har bestemte kvalitetsegenskaber udvikle en softwarearkitekturprototype (softwarearkitektur-implementering) anbefale en distribueret arkitektur og en konkret distributionsform anvende statistiske modeller til analyse og vurdering af softwareløsningens kvalitet eller på anden måde anvende statistiske modeller i softwareløsningen redegøre for fordele og ulemper ved valgte løsninger i sammenligning med alternative løsninger Datateknologiuddannelsen, 4. semester 11 b40

116 SEMESTERHÅNDBOG - FORÅRET 2009 SEMESTERPLAN Uge Semestermøde (Onsdage kl ) 6 Klassemøde: Orientering om semester Semesterkoordination Undervisning og projekt 7 PL-undervisning: Agil projektstyring Gruppedannelse afsluttet 11. februar (meddelt pr. ) Vigtige datoer Man Tir Ons Tor Fre STAT KOM SOFT REG STAT STAT KOM SOFT REG PRO 8 (reserveret) STAT KOM SOFT REG PRO 9 Grupperepræsentantmøde STAT KOM SOFT REG PRO 10 (reserveret) STAT KOM SOFT REG PRO 11 Klassemøde: Præsentation og godkendelse af projektgrundlag Projektgrundlag færdiggjort og godkendt 11. marts STAT KOM SOFT REG PRO 12 (reserveret) STAT KOM SOFT REG PRO 13 Klassemøde: Midtvejsevaluering STAT KOM SOFT REG PRO 14 (reserveret) STAT KOM SOFT REG PRO 15 Påske 16 Grupperepræsentantmøde Tidspunkt for review aftalt med KOM SOFT REG PRO vejleder 15. april 17 (reserveret) STAT KOM SOFT REG PRO 18 Klassemøde: Orientering om STAT KOM SOFT REG PRO projektaflevering og eksamen 19 (reserveret) STAT PRO PRO PRO 20 (reserveret) PRO PRO PRO PRO PRO 21 (reserveret) PRO PRO PRO PRO 22 Klassemøde: Slutevaluering (bemærk fredag den kl ) Projektrapport afleveret på sekretariat 29. maj kl. 12 PRO PRO PRO PRO Bemærk: Semestermøder holdes sædvanligvis onsdage kl Undervisningen er skemalagt til at foregå om formiddagen i D1 Datateknologiuddannelsen, 4. semester 14 b41

117 SEMESTERHÅNDBOG - FORÅRET 2009 SEMESTERPROJEKTET PROJEKTOPLÆG Semesterprojektet er et softwareprojekt med særligt vægt på softwaredesign, distribution og anvendelse af statistik (se den præcise beskrivelse af semesterprojektet side 11). Projektgrupperne skal selv finde en interessant og relevant software-opgave, der gør det muligt at få opfyldt de mål, der er beskrevet for projektet og samtidigt er motiverende at arbejde med. Til inspiration har lærergruppen skitseret tre eksempler: Et togrejsesystem, et elevatorstyringssystem og et system til påtvingning af grøn bølge (se APPENDIKS: PROJEKTEKSEMPLER på side 2). Det står projektgrupperne frit for at bruge disse eksempler. PROJEKTFORLØB Det anbefales at projektforløbet inddeles i tre hovedfaser: Projektetablering & -planlægning, Projektgennemførsel og Afrapportering: Projektetablering & -planlægning I starten af projektforløbet gennemføres en projektetablering, der resulterer i et projektgrundlag. Med udgangspunkt i projektgrundlaget udarbejdes en overordnet plan for hele projektforløbet. Den overordnede projektplan suppleres løbende gennem projektforløbet med detaljerede planer for enkelte delforløb Projektgennemførsel Projektgennemførslen vil typisk forløbe som 2-3 iterationer i en elaborationsfase (som beskrevet i Unified Process). Udarbejdelse af endelig projektrapport I den sidste del af projektforløbet udarbejdes eller færdiggøres projektrapporten på baggrund af de materialer, der er produceret i projektet Projektgrundlaget og den overordnede plan skal præsenteres for og godkendes af lærergruppen førend den egentlige projektgennemførsel kan påbegyndes. Indhold, forløb og længde af hver af projektfaserne samt evt. yderligere opdeling i faser afhænger af det konkrete projekt og den konkrete projektgruppes tilrettelæggelse. Det forventes, at der i projektstyringen og herunder især i den detaljerede planlægning benyttes teknikker fra SCRUM-metoden. I løbet af projektet skal der mindst én gang gennemføres et formelt review af væsentlige dele af projektresultaterne. Tilrettelæggelse af reviewet sker i samarbejde med projektvejleder. Datateknologiuddannelsen, 4. semester 16 SEMESTERHÅNDBOG - FORÅRET 2009 De faste milepæle, dvs. godkendelse af projektgrundlag (incl. overordnet tidsplan) samt aflevering af projektrapport, fremgår af semesterplanen. PROJEKTETS OMFANG Projektets omfang er 10 ECTS point svarende til en tredjedel af den samlede semesterbelastning. På den baggrund forventes den enkelte studerende at bidrage med en arbejdsindsats på ca timer på projektet i hele semestrets forløb (referat af studienævnsmøde ). Det tilrådes som hovedregel, at indsatsen på projektet svarer til det anbefalede. Hvis indsatsen er mindre kan det resultere i et dårligt projektresultat. Omvendt kan en for stor indsats på projektarbejdet give for lille overskud til det nødvendige arbejde med teoristoffet. GRUPPESAMMENSÆTNING De studerende vælger på 4. semester frit deres gruppesammensætning, dog er reglen at studerende, der er nytilkomne i klassen fordeles administrativt på de øvrige projektgrupper af semesterkoordinatoren, og at ingen grupper er dannet før alle er på plads. Når alle grupper er dannet bliver projektlokalerne fordelt. RAPPORT Som grundlag for rapportskrivningen henvises til dokumentet Kontrolskema for projektrapporter ved datateknologiuddannelsens 4. semester, der indeholder en vejledende struktur for rapporten, hvilke delelementer der skal indgå i rapporten, krav til de enkelte delelementer, samt krav til mediet, som de enkelte rapportelementer skal afleveres på. Datateknologiuddannelsen, 4. semester 17 b42

118 SEMESTERHÅNDBOG - FORÅRET 2009 PROJEKTVEJLEDNING I starten af projektperioden, fx ved første vejledermøde, bør der indgås en aftale, en vejledningskontrakt, mellem projektgruppe og vejlederen. Formålet med vejledningskontrakten er at skabe fælles forventninger til vejledningen. Bemærk at vejlederne som hovedregel ikke forventer at deltage i vejledermøder i de uger, hvor der er møder med grupperepræsentanter. VEJLEDERENS ROLLE Forventninger til vejlederens væsentligste rolle: Leder og fordeler arbejdet i gruppen? Indgår i projektarbejdet? Retter gruppens papirer? Holder projektet på sporet? Påpeger om projektet kører af sporet? Griber ind over for samarbejdsvanskeligheder? Forholder sig passiv indtil gruppen spørger om noget? VEJLEDNINGSMØDER Fast ugentligt møde? Fast ugentligt møde, hvis gruppen indkalder? Helt efter behov? DAGSORDEN Gruppen laver dagsorden til hvert møde? En fast dagsorden f.eks.: Gennemgang af referat Status for projektet Diskussion af arbejdspapirer Information fra vejleder... Eventuelt (ingen beslutninger) Skal der være ordstyrer? Deltager hele gruppen altid? Datateknologiuddannelsen, 4. semester 18 SEMESTERHÅNDBOG - FORÅRET 2009 KONTAKT UD OVER MØDER: Kontakt til vejleder pr , personligt eller frit efter behov? Kontakt til faglærer gennem vejleder eller direkte til faglærer? Datateknologiuddannelsen, 4. semester 19 b43

119 APPENDIKS: PROJEKTEKSEMPLER SALG AF TOGREJSER EKSEMPEL PÅ PROBLEMFORMULERING Virksomheden ETC, som påtænker at overtage en del af togdriften i Danmark fra DSB, ønsker at få udviklet en softwarearkitektur for et system til salg af billetter og pladsreservationer, togrejsesystemet TID. TID skal kunne benyttes af såvel ETC s kunder (de rejsende) som af ETC s ansatte (salgsassistenterne). TID skal omfatte forskellige salgskanaler, der til dels opfylder forskellige behov. Kunderne skal kunne købe billetter og pladsreservationer hjemme fra dem selv, fra mobile enheder (mobiltelefoner), ved selvbetjening på stationer og gennem ETC s salgsassistenter. Nogle af salgskanalerne skal sikre meget hurtig betjening, som fx selvbetjeningsenheder opstillet på perronerne, medens andre skal give mulighed for komplekse køb, som køb af billetter til sammensatte rejser med tilhørende pladsreservationer for en blandet gruppe af rejsende. Systemet skal generelt være forståeligt for kunderne og effektivt for ETC at drive og vedligeholde. TID skal kunne kommunikere med ETC s eksisterende it-systemer, herunder skal det kunne hente oplysninger fra køreplanen, som indeholder afgangs- og ankomsttider. Der er således behov for et distribueret system med forskellige klienttyper med forskellig funktionalitet og hvor vigtigheden af kvalitetsegenskaber varierer fra klienttype til klienttype. Spørgsmålet er: Kan der til TID udvikles en skalerbar softwarearkitektur, der realiserer funktionaliteten vedr. salg af billetter og reservationer, og som på den ene side imødekommer behovene for korte svartider ved salgskanaler tæt på togene og på den anden side giver mulighed for komplekse salg af rejser? Underspørgsmål: Kan softwarearkitekturen udformes på en måde så den vil kunne udvides til at omfatte simpelt salg af rejser vha. mobiltelefoner og salg af rejser vha. selvbetjeningsenheder med høj tilgængelighed på ubetjente stationer? Hvilke distributions- og kommunikationsformer kræver et sådant system, og er det muligt at etablere disse? Kan der opstilles statistiske modeller for kvaliteten af designet og kan disse modeller bruges til at påvise at nogle designvalg er bedre end andre? b44

120 ETC Bilag 17: Inceptionsdokument Billetautomater Inceptionsdokument 1. september 2005 Version : 2.0 Udgivelsesdato : 2. september 2005 Udarbejdet : LB Kontrolleret : MV, LDa, NT Godkendt : EI ETC Billetautomater INDHOLDSFORTEGNELSE 1 Indledning Formål Målgruppe Projektmedlemmer Referencer Anerkendelser Læsevejledning 4 2 ETC - baggrund 6 3 Vision Systemets overordnede formål og anvendelse 8 Formål med købskanalen Billetautomater Aktører 9 Kunderne 9 Andre interessenter Anvendelse af Billetautomat 10 Billetsortiment 10 Produkter der kan afhentes 11 Købssituationen generelt 11 Priser 11 Betaling 11 Andet 12 Brugsmønstre 12 Brugsmønster: Køb af rejse 12 Brugsmønster: Alm-Køb af billet 13 Brugsmønster: Kvik-Køb af billet 14 Brugsmønster: Afhentning af bestilling 14 Brugsmønster: Annullering 14 Brugsmønster: Udstedelse af tilgodebevis 15 Brugsmønster: Betaling 15 Brugsmønster: Hjælp og vejledning 15 Kundedialog 16 Udbygningsmuligheder Supplerende oplysninger og specifikationer 16 FURPS 17 Funktionalitet (Functionality) 17 F1 Hændelseslog 17 F2 Dagsummer 17 F3 Stamoplysninger 18 Anvendelighed (Usability) 19 U1 Effektiv betjening 19 U2 Personalisering 19 U3 Sprog 19 U4 Kort ekspeditionstid 20 Inceptionsdokument Version 2.0, 1. september af 31 b45

121 ETC Billetautomater U5 Betjeningsformer 20 U6 Destinationer på skærm 20 U7 Øve i brug af automat 20 Pålidelighed (Reliability) 21 R1 Drift ved systemnedbrud og lign. 21 R2 Driftssikkerhed 21 Ydeevne (Performance) 21 P1 Samtidig anvendelse af flere automater 21 Integration, vedligeholdelse og flytbarhed (Supportability) 21 S1 Fremtidig variation af Køb af rejse 21 S2 Regional tilpasning 21 S3 Softwarestyring på automat 22 Betingelser () 22 1 Software 22 2 Løbende overførsel af data til et centralt databasesystem 22 4 Ordliste 23 5 Versionshistorie 23 Bilag 24 1 Eksempler på billetter 24 2 Krav til ledelsesstatistik 25 3 Datakommunikation 26 4 Overvågning 26 5 Automater 27 1 Fysiske krav Ergonomi Miljø og energi 30 Inceptionsdokument Version 2.0, 1. september af 31 ETC Billetautomater 1 Indledning 1.1 Formål Formålet med dette dokument er at danne grundlag for udviklingen af et Billetautomatsystem til ETC. Dokumentet fastholder såvel visionen med systemet som de overordnede krav til det. 1.2 Målgruppe Dokumentets målgruppe er kunden, som systemet skal udvikles til, og systemets udviklere. 1.3 Projektmedlemmer Dokumentet er udarbejdet af Lone Borgersen. 1.4 Referencer Dette dokument er baseret på oplæg fra ETC. 1.5 Anerkendelser Der skal gives en stor tak til Mads Andreas Peulicke, Kenneth Benjamin Ulmer, Thomas Poulsen, Rune Gregersen, Mads Troelsgaard Olsen og Mads Spangsberg Kristensen, alle IT-ingeniørstuderende på 3. semester foråret 2005, for deres store og fine indsats med at tilvejebringe baggrundsoplysninger om ETC. Resultatet af deres indsats kan ses i Afsnit 2 ETC Baggrund. 1.6 Læsevejledning Inceptionsdokumentet indeholder i Afsnit 2 Billetautomatsystemet en overordnet beskrivelse af det kommende Billetautomatsystem. Denne beskrivelse skal danne grundlag for udviklingen af systemet. I Afsnit 2 ETC- Baggrund beskrives baggrunden for dannelsen af virksomheden ETC og der fremdrages en række centrale forhold i virksomheden. I Afsnit 3.1 Vision beskrives baggrunden for det kommende system og visionen med det. I Afsnit 3.2 Systemets overordnede formål og anvendelse beskrives det kommende systems formål og dets generelle anvendelse. Her beskrives målsætningen med det nye automatkoncept, som det er planlagt at etablere. Der redegøres for de overordnede formål med at udskifte de nuværende billetautomater med en helt ny type. Desuden er der formuleret et sæt succeskriterier for det planlagte koncept. Dernæst i Afsnit 3.3 Aktører og Afsnit 3.4 Billetautomatens anvendelse bliver der redegjort for købskanalen Billetautomater, som de nye automater bliver den væsentligste del af, herunder for produktsortimentet, kundegrupperne og de øvrige interessenter omkring købskanalen. Desuden bliver de øvrige købskanaler i ETC kort beskrevet for at illustrere sammenhængen. I Afsnit 3.4 Billetau- Inceptionsdokument Version 2.0, 1. september af 31 b46

122 ETC Billetautomater tomatens anvendelse beskrives mere specifikt, i en brugsmønstermodel, de krav der er til de opgaver, som Billetautomaten skal kunne løse. Endelig skitseres i Afsnit 3.5 Supplerende oplysninger og specifikationer det systemkoncept, som ETC sigter mod, ligesom øvrige krav specificeres. I Afsnit 4 Ordliste defineres væsentlige domænebegreber. I Afsnit 5 Versionshistorie beskrives dokumentets versioner. Bilagene er supplerende materialer, der giver oplysninger om billetters udseende, krav til ledelsesstatistik, behov for datakommunikation, typer af overvågning og foreløbige fysiske krav til billetautomaterne. Inceptionsdokument Version 2.0, 1. september af 31 ETC Billetautomater 2 ETC - Baggrund ETC blev grundlagt i 2003 med det formål at overtage en del af togdriften i Danmark fra DSB. Ved udlicitering vandt ETC retten til at være eneste togoperatør på strækningerne vest for Lillebælt. ETC har baggrund i et større engelsk firma som står for meget af den interne trafik i England. Indtil 2002 brugte DSB meget energi på at modernisere strækningerne i Jylland, både for at forbedre sikkerheden og for at muliggøre kørsel med højere hastighed. ETC fik tilbud om at købe rullende materiel igennem DSB, men valgte at anvende sine egne kontakter, og havde således nye tog klar på overtagelsesdagen. ETC er ledet af adm. Dir. Peter Jensen som blev ansat på baggrund af sine fine resultater i B&O Han har selv udtænkt firmaets organisation med baggrund i, at der skulle prøves noget nyt. Peter Jensen holder stort fokus på fremtidige indtjeningsmuligheder og vil hele tiden gerne finde nye områder, som ETC kan gå ind i. ETC er opdelt i to overordnede dele, baneafdelingen og turafdelingen, hvor hver del har eget administrativt personale. Direktør Peter Jensen har IT og Personaleafdeling under sig som stabsfunktioner. ETC s hovedkontor er i Fredericia, her er alle de administrative funktioner, og ledelsen samlet. Baneafdelingen er ledet af Kim Skov Andersen, ansat til denne stilling af Peter Jensen i Kim Skov kom fra LEGO, hvor han var leder af HR-afdelingen. Baneafdelingen har ansvar for det rullende materiel, skinnerne, signaler og planlægning af køreplan og turplan. Kim Skov har organiseret de ansatte i vedligeholdelsesafdelingerne i mindre selvstyrende grupper og derved i høj grad elimineret behovet for mellemledere på værkstederne. Kim Skov holder fokus på de arbejdsgange afdelingen har, og hvordan de kan forbedres. Køreplanen er det som udleveres til ETC s kunder og som indeholder afgangs- og ankomsttider. Turplanen er et internt dokument som laves for 14 dage af gangen og indeholder de ansatte togbetjentes arbejdstider. Man har valgt at lade baneafdelingen stå for disse ting ud fra ideen om at de bedst ved, hvilket materiale, der er tilgængeligt hvornår, og hvor langt tid det tager at rejse mellem de forskellige stationer. Kim Skov har gjort meget ud af at sikre et godt forhold til sine ansatte og højne deres motiva tion, hvilket betyder at ETC Bane i dag har en glad og arbejdsom medarbejderstab med meget lavt sygefravær. Turafdelingen er ledet af Michael Fass, ansat til denne stilling af Peter Jensen i Michael Fass er tidligere ansat i DSB og ansat på baggrund af sit know-how om togdrift. ETC Tur er ansvarlig for salg, marketing, service, billetkontrol, fremførsel af togene, og vedligeholdelse af stationerne. Michael Fass har udarbejdet et regelsæt for de ansatte i de forskellige afdelinger og holder stor fokus på at de regler overholdes, hvis alle gør, som de skal, så er der ingen problemer er hans motto. De tre store afdelinger i ETC Tur er salg, billetkontrol og fremførsel af toge. Inceptionsdokument Version 2.0, 1. september af 31 b47

123 ETC Billetautomater Salgsgruppen er fladt organiseret med salgsassistenter på de forskellige stationer og en salgschef på hovedkontoret. Billetkontrol er langt den største personalegruppe i hele ETC. Gruppen styres fra hovedkontoret af en styringsgruppe, som videreformidler ønske om frihed o. lign. til turplanen. De ansatte kommer hovedsagligt fra DSB, og har været igennem ETC s omskolingsprogram. Mange er erfarne folk med godt kendskab til jobbet og med et højt lokalkendskab. De ansatte er firmaets profil udadtil, og Michael Fass har lagt stor vægt på at de skal følge retningslinierne for kundebehandling. Det er også denne gruppe som står direkte for skud, når der er forsinkelser eller andre problemer. Der er i denne afdeling en voksende utilfredshed med den måde firmaet bliver kørt på. Der er kommet mange forslag fra de ansatte om forbedringer af arbejdsmiljøet og arbejdstiderne, men der er ikke sket noget. Man føler i afdelingen, at man i høj grad er med til at tjene firmaets penge, men når gaverne skal fordeles bliver man overset. Der er store problemer med at få turplanen til at køre ordentligt, og lønnen viser sig ofte at være forkert. Fremførsel af tog var ETC s smertensbarn i starten. Det viste sig meget svært at skaffe lokomotivførere nok, og det var nødvendigt for ETC at hæve lønnen for denne gruppe for at få nok ansatte. Der er ikke længere underskud af ansatte, og i ETC s eget træningsprogram er man begyndt at uddanne lokomotivførere også. Der er en del uofficielle frynsegoder som er et levn fra den tid hvor der var mangel på ansatte, det er f.eks. nemmere for en lokomotivfører at få fri og ferie på de ønskede dage. Der er en spirende tvivl om ledelsens evner da mange ansatte oplever at skulle fragte vogne og toge rundt. ETC har en god kundebase, der er tradition for at anvende kollektiv trafik i hvert fald i nogle dele af området. I starten var der store problemer med forsinkelser, og det har skabt en uheldig myte med at ETC altid er forsinket, også nu hvor det kører 99 % af sine toge indenfor 5 minutter af den fastsatte tid. En mindre gruppe kunder har oplevet manglende service eller ligegyldighed fra togbetjentene. Dette har resulteret i at en mindre del kunder er begyndt at bruge andre transportmidler. Økonomien i ETC ser ikke alt for god ud. Der er ikke tale om at firmaet har underskud, der er faktisk et pænt overskud, men der går mange resurser til spilde i firmaet. Det er ikke umiddelbart klart for Peter Jensen hvor pengene forsvinder hen, men faktum er at omsætningen er høj men indtjeningen er lav. 3 Vision ETC har i dag godt 500 billetautomater, hvoraf de ældste er mere end 15 år gamle. Der er flere forskellige typer og fabrikater af automater, og betjeningen af dem varierer også en hel del. Der er også forskellige typer produkter, der kan købes på de forskellige automater, ligesom betalingsmåderne er varierende. En række af automaterne er endvidere ved at være teknologisk forældede. Forskellighederne og den delvise teknologiske forældelse medfører dels, at det nuværende automatkoncept samlet set ikke længere er optimalt med hensyn til kundevenlighed og dels, at det ikke er tilstrækkeligt effektivt at drive, servicere og vedligeholde billetautomaterne. Inceptionsdokument Version 2.0, 1. september af 31 ETC Billetautomater Visionen er at få udviklet et Billetautomat-system, som er enklere for kunderne at betjener og mere effektivt for ETC at drive og vedligeholde. De nye automater skal kunne kommunikere med ETC s eksisterende it-systemer igennem det eksisterende datanet. Alle kortbetalingstransaktioner i automaterne skal behandles og administreres af PBS, som også skal godkende kortbetalingsmodulet og den funktionalitet i automaterne, der vedrører betaling med betalings- og kreditkort. 3.1 Systemets overordnede formål og anvendelse ETC har en række kanaler for køb af billetter, periodekort, klippekort, pladsreservationer osv. Købskanalen Billetautomater er en af dem. De øvrige er: De betjente salgssteder. På alle betjente stationer sælges der i åbningstiden ETC-produkter på moderne pc arbejdspladser (Windows) ved hjælp af billetsalgssystemet ROSA. Desuden sælges lokale produkter på andet udstyr. Telefon. Der findes et antal telefonsalgscentre, hvortil kunderne kan ringe og bestille produkter, som enten bliver sendt med posten, eller som kan hentes i en billetautomat. Netbutik. På ETC s hjemmeside ( kan der købes visse produkter, herunder pladsreservationer. Om ønsket kan produkterne hentes i en automat. I tog. I nogle tog kan der købes billet mod betaling af et gebyr. Formål med købskanalen Billetautomater Formålet med købskanalen Billetautomater er at give kunderne mulighed for at købe billetter på de ubetjente stationer og på de betjente stationer uden for åbningstiderne at lægge en større del af billetkøbet over til selvbetjening for at aflaste de betjente salgssteder. ETC har også besluttet at der fremover skal være mindst én automat til papirbilletter på hver station (uanset der er planer om at indføre et elektronisk rejsekort) for at bevare papirbilletten som et alternativ for de kunder, der enten ikke ønsker eller ikke har behov for et rejsekort. Målene med det nye automatkoncept er at forbedre ETC Koncernens købskanal Billetautomater ved at gøre den enklere for kunderne at betjene og Inceptionsdokument Version 2.0, 1. september af 31 b48

124 ETC Billetautomater mere effektiv for ETC at drive og vedligeholde For at nå målene er det planen at udskifte alle ETC s nuværende billetautomater med nye. For at tilgodese målet om større enkelhed og for at gøre automaterne mere tilgængelige, skal det nye koncept være ensartet, dvs. at alle de nye billetautomater er af samme fabrikat og type. De skal have det samme billetsortiment og de samme betalingsmuligheder og være ensartede at betjene for kunderne. Ved valg af billetsortiment vil der blive taget hensyn til, at det skal være nemt og hurtigt for kunderne at købe billet. For at forbedre salgskanalens effektivitet og rentabilitet skal det sikres, at dens kapacitet bliver udnyttet bedre end i dag. I den forbindelse vil ETC udarbejde målsætninger for salgskanalens omsætning, effektivitet og kvalitet. Organisationen omkring administrationen af konceptet skal gøres enklere og mere ensartet, og der skal løbende kunne udarbejdes ledelsesinformation, som gør det muligt at følge de opstillede mål. For at nå målet om bedre effektivitet med hensyn til drift og vedligeholdelse af de nye automater, skal konceptet hænge bedre sammen informationsteknologisk og være mere fleksibelt end det nuværende. Det forudsætter bl.a., at overvågningen af automaterne foregår på én (eksisterende) overvågningsplatform, og at det bliver muligt at distribuere nyt salgsprogrammel og nye takstdata elektronisk og samtidigt til alle automaterne. Det skal også være muligt at modtage salgsdata fra alle automater elektronisk. Succeskriterierne for det nye automatkoncept er at opnå størst mulig enkelthed, ensartethed, tilgængelighed, effektivitet og fleksibilitet ved køb af billetter og ved drift, vedligeholdelse og administration af konceptet. Der vil blive sigtet mod at realisere et koncept bestående af 300 til 400 automater placeret på alle ETC s stationer. 3.2 Aktører Kunderne Den primære målgruppe for købskanalen vil være de kunder, der ikke har et stort rejsebehov, og de kunder som kan klare sig med enkle standardrejser. Det betyder, at automaterne kun skal kunne udstede billetter, som er simple og hurtige at købe. Der vil typisk være tale om kunder, der ankommer til stationen kort tid før deres tog afgår. Inceptionsdokument Version 2.0, 1. september af 31 ETC Billetautomater Der vil dog også blive satset på kunder, der har bestilt billet på forhånd, fx via telefon eller internettet, og som derefter henter og betaler billetten på en automat. Andre interessenter Af andre interessenter til automaterne ud over kunderne kan nævnes: De amtslige trafikselskaber inklusive HT, hvis produkter vil kunne købes på automaterne Salgsmedarbejderne på stationerne, der vil bistå kunderne med at betjene automaterne, og som skal kunne sammenligne salget med de opstillede salgsmål ETC s servicepersonale, der vil varetage den daglige service og vedligeholdelse af automaterne Overvågningspersonalet i Centret, hvorfra overvågningen af automaterne vil blive styret og koordineret Regnskabspersonalet, der løbende vil følge op på og afstemme salget på automaterne Marketingfolkene, der vil markedsføre automaterne og udvikle nye produkter, som skal kunne købes på automaterne ETC s ledelse, der vil følge købskanalens overordnede rentabilitet og sammenholde den med de opstillede måltal Automatleverandøren 3.3 Anvendelse af Billetautomat I Billetautomaten skal det dels være muligt at købe et billetsortiment, der er enkelt og hurtigt at bestemme dels at afhente produkter, som er bestilt i forvejen, i automaten Billetsortiment Der kan købes billetter indenfor et samlet billetsortiment, der opstår som en kombination af følgende kategorier: Billettype: o Enkeltbilletter o Dobbeltbilletter o 10-turskort o Cykelbillet Serviceniveau: o Standard o Business Inceptionsdokument Version 2.0, 1. september af 31 b49

125 ETC Billetautomater Kundekategori o Voksen o Barn (12-15 år inkl.) o Ung (til ETC WildCard) o 65 billet Afgangsstationen skal altid være den, hvor automaten står. Fra hver automat skal der kunne vælges mellem samtlige øvrige destinationer i landet. Der kan købes ETC-billetter til stationer uden for det amt, som stationen ligger i. Automaten sælger også voksen- og børnebilletter til lokale trafikselskaber ved rejser inden for det pågældende amt. Pensionist/65-billetter til lokale trafikselskaber kan købes i amter, hvor denne billettype findes. En rejse kan være sammensat af en eller flere ETC-rejser og en eller flere lokale rejser Produkter der kan afhentes Billetter og andre produkter, som fx pladsbilletter, der er bestilt i ETC netbutik eller i telefonsalg og tildelt et bookingnummer, kan afhentes i automaten. Det skal være muligt at afhente produkter, som enten er betalt på forhånd, eller som betales på automaten, når de bliver hentet. Købssituationen generelt Flere billetter skal kunne købes efter hinanden og flere produkter skal kunne afhentes og betales på én gang. Priser Produkter til lokale rejser bliver prissat efter de lokale trafikselskabers takstsystemer, mens produkter til ETC-rejser bliver prissat efter ETC s takstsystem. Betaling Køb i automaten kan betales med alle danske mønter (undtagen 25-ører) eller med Dankort, VISA/Dankort, VISA, Eurocard, Mastercard, Diners, Maestro og VISA Electron. Automaten tager kort udstedt i udlandet af typen: VISA, Eurocard, Mastercard og Diners. Betaling med mønter og kort kan ikke kombineres i samme køb. Der kan ikke betales med sedler. Inceptionsdokument Version 2.0, 1. september af 31 ETC Billetautomater Andet Automaterne skal kun kunne bruges til køb af produkter. Det betyder, at de ikke skal kunne bruges til at opsøge informationer om togafgange, forsinkelser osv. Det skal dog være muligt at kunne vise reklamer på automaterne i form af stillbilleder. Brugsmønstre Figur 1 Brugsmønsterdiagram for Billetautomat Brugsmønster: Køb af rejse Aktører: Kunde Formål: At købe en eller flere billetter Oversigt: 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. Kunden kan vælge mellem: Køb af billet (almindeligt køb eller kvik-køb) (beskrevet i brugsmønstrene Alm-Køb af billet og Kvik-køb af billet) Afhentning af bestilt produkt (beskrevet i brugsmønstret Afhentning af bestilt produkt) Annullering af bestilt produkt. (beskrevet i brugs- Inceptionsdokument Version 2.0, 1. september af 31 b50