Bucket Airlines SW02 Projekt Gruppe 2: Alireza Derakhshan Frodi Hammer Lars Sønderby Jessen Michael Vestergaard Jessen kianosh@mip.sdu.dk frodi@mip.sdu.dk ljessen@mip.sdu.dk emjay@mip.sdu.dk 30. maj 2003
Synopsis Denne rapport beskriver brugen af Unified Process (UP) i forbindelse med analyse, design og implementering af et system til håndtering af fly-reservationer for et flyselskab. Rapporten behandler de forskellige UP faser i forbindelse med projektet og indeholder Use-case og design modeller for systemet. Rapporten behandler også implementeringen af systemet i JAVA og vil i den forbindelse behandle emner som RMI, Swing og Database access. 2
Forord Denne rapport er udarbejdet i forbindelse med SW02 kurset på Mærsk Mc-Kinney Møller instituttet for Produktions teknologi på Syddansk Universitet forår 2003. Denne rapport tager udgangspunkt i Unified Process (UP) og benytter de redskaber der stilles til rådighed for software udvikling. Dette indebærer at de forskellige faser fra UP (inception, elaboration, construction, transition) vil blive gennemgået i denne rapport. Vi vil dog i rapporten ikke beskrive metoden specifikt, men vil derimod anvende den i praksis på en given applikation A. Det er derfor en nødvendighed at læseren er fortrolig med de forskellige faser fra UP[1]. God fornøjelse... Alireza Derakhshan Frodi Hammer Lars Sønderby Jessen Michael Vestergaard Jessen 3
Indhold Indledning 6 1 Faser i Unified Process 7 1.1 Inception................................ 7 1.2 Elaboration............................... 8 1.3 Construction............................... 8 1.4 Transition................................ 8 2 Requirements 9 2.1 Aktører................................. 9 2.2 Use Cases................................ 9 2.3 Non-functional requirements...................... 14 2.3.1 Tilgængelighed......................... 14 2.3.2 Sikkerhed............................ 14 2.3.3 Performance.......................... 14 2.3.4 Fejl tolerance.......................... 14 2.3.5 Scalability........................... 14 3 Analyse & Design 15 3.1 Domæne model............................. 15 3.2 Arkitektur................................ 16 3.2.1 Klient.............................. 17 3.2.2 Server.............................. 18 3.3 Detailed Design............................. 18 3.3.1 Database............................ 18 3.3.2 Database Access........................ 20 3.3.3 Application Kernel....................... 20 3.3.4 Klient/Server.......................... 21 3.3.5 Brugergrænseflade....................... 25 4 Implementation 32 4.1 Database................................. 32 4.1.1 Opsætning af database..................... 33 4.2 Database Access............................ 33 4.2.1 OJB PersistenceBroker..................... 33 4.3 Application Kernel........................... 34 4.4 Klient/Server.............................. 34 4.5 Brugergrænsefladen........................... 35 4
INDHOLD INDHOLD 5 Test 38 5.1 Komponent test............................. 38 5.2 Samlet test................................ 39 5.3 Vurdering................................ 41 6 Deployment 42 6.1 Installationsvejledning......................... 42 6.2 Brugervejledning............................ 42 7 Konklusion 43 8 Perspektivering 44 A Bucket Airlines 46 B Test output 50 5
Indledning Denne rapport vil præsentere et forslag til at udvikle et software system iht. oplæget bilag A. Vi vil hoved sagligt benytte os af Unified Process (UP) metoden og dens faser samt aktiviteter. Da UP er en iterativ metode vil vi starte med at præsentere dens faser og efterfølgende resultatet af dens aktiviteter. I kapitel 1 beskriver vi de enkelte faser, og specificer deres funktion iht. vores projekt. Alle disse aktiviteter der indgår i de forskellige faser vil så blive gennemgået. Vi starter med requirements i kapitel 2, hvor vi fastlægger de use-cases der er kerne use-cases i systemet samt de non-functional requirements. Dermed har vi skabt et udgangspunkt for analys & design aktiviteten, som er beskrevet i kapitel 3 hvor vi ser på systemets arkitektur. Yderligere laver vi et detaljeret design af systemet, som skal ligge til grund for implementeringen der bliver præsenteret i kapitel 4. Her ser vi på de forskellige komponenter fra designet med henblik på implementeringen. Efterfølgende tester vi systemet i kapitel 5. Således sikre vi os, at systemet over holder de krav vi har stillet. Det skal dog bemærkes at aktiviteterne i UP er iterative og vi her kun præsenterer de resultater vi finder frem til. Dvs. at der ikke bliver fokuseret på det egentlige udviklings forløb. 6
Kapitel 1 Faser i Unified Process Unified Process (UP) består af 4 faser: inception, elaboration, construction og transition. Disse faser og deres aktiviteter kan ses på figur 1.1 Figur 1.1: Oversigt over faser og aktiviteter I forbindelse med vores projekt har vi gennemgået de første 3 af disse 4 faser. Forløbet af disse 3 faser vil i det følgende blive kort beskrevet. 1.1 Inception Vores udgangspunkt til inception fasen er et opgave oplæg bestående af et dokument fra en tænkt kunde, Bucket Airlines. Dokumentet indeholder korte beskrivelser af brugsscenarier for det ønskede system samt beskrivelser af kundens forretningsområder og profil. Vores mål med inception fasen er at lokalisere og formalisere de vigtigste use-cases i systemet således at vi kan tydeliggøre over for os selv, og kunden, hvor stort omfanget af projektet er. 7
1.2. ELABORATION KAPITEL 1. FASER I UNIFIED PROCESS Vi starter med at identificere aktørerne i systemet. Ud fra det udleverede dokument kommer vi frem til følgende aktører: Assistent, Kunde, Salgsafdeling, Personaleafdeling. I inception fasen vil vi kun koncentrere os om de 2 første: Assistent og Kunde da de er de centrale for systemet. Se iøvrigt afsnit 2.1 for en udførlig beskrivelse af aktørerne. Vi identificerer herefter de centrale use-cases i systemet. Vi finder frem til følgende centrale use-cases: Opret reservation og opret kunde. Se iøvrigt afsnit 2.2 for en oversift over usecases i vores system. 1.2 Elaboration I elaboration fasen er hovedformålet at få analyseret problem domænet, at etablerer en stabil arkitektur samt at eliminere de højeste risikoelementer i projektet. De beslutninger der skal tages om arkitektur i denne fase, skal tage højde for systemet som helhed; problemstillingen, overordnede funktionalitet samt non-funktionelle krav. I elaboration fasen i dette projekt, startede vi med at revidere de use cases samt aktører vi have identificeret i inception fasen. Dette ledte til en specificering af de kerne use cases systemet skulle implementere (se afsnit 2.2). Udfra disse use cases definerede vi en model af problemdomænet, hvorved vi fik fastlagt klasser og komponenter i systemet, og hvorledes sammenarbejde imellem disse udfører de enkelte use cases (se afsnit 3.1). Desuden har vi fået fastlagt de non-funktionelle krav til systemet (se afsnit 2.3), og derudfra specificeret en passende arkitektur (se afsnit 3.2). For en mere detaljeret gennemgang af designet, herunder systemgrænseflader, se afsnit 3.3 Detailed design. 1.3 Construction Hvis vi tager udgangspunkt i figur 1.1, er hovedaktiviteten i construction fasen implementering samt testning af produktet. Implementeringen bliver gennemgået i kapitel 4, hvor vi dykker ned i implementeringen af systemet og deler koden op i delsystemer, bestående af lag samt komponenter, der bliver afgrænset i ansvarsområder samtidig ser vi nærmere på de mønstre vi kan bruge i de forskellige lag og komponenter. desuden gør vi brug af 3. parts komponenter der iforvejen er veldokumenterede og gennemtestede, til at understøtte samt tilføje nyt funktionalitet til systemet. Testen bliver diskuteret i kapitel 5, hvor vi tester vores samlede system i og med vi bekræfter at det implementerede sammenspil mellem objekter finder sted og udføres korrekt. Dog skal det bemærkes at den vigtigste del i testen er at sammenholde de testresultater vi har opnået mod de krav der er stillet til systemet. Denne test skal så lægges til grund for den næste aktivitet hvor hoved formålet er at klargøre opsættelsen af system i dets designede miljø. Kapitel 6 omhandler deployment aktiviteten hvor vi ser på installations vejledning til opsættelse af programmet samt brugermanualer til brugeren af systemet. 1.4 Transition Da der er mangel på transition fasen, iht. vores projekt, har vi valgt at udlade den. 8
Kapitel 2 Requirements I dette kapitel vil vi gennemgå de krav der beskriver systemet, dvs. hvad systemet skal kunne. Dette gøres idet vi identificerer aktører, der repræsenterer brugere af systemet, eller eksterne systemer der interagerer med systemet. Use cases, der beskriver systemets adfærd, bliver også identificeret med henblik på aktørernes behov. Endvidere bliver systemets non-funktionelle krav specificerede. Vi opnår en fuldt beskrevet use case model, der kan ligge til grundlag for den videre udvikling af systemet. 2.1 Aktører Følgende aktører er identificerede i systemet, iht. oplægget. Assistent Assistentens funktion er, at anvende systemet til at formidle kundens ønsker. Kunde Kunden optræder endnu ikke aktivt i systemet, men en fremtidig web-udvidelse af systemet vil kunne delagtiggøre kunden i systemet. Personaleafdeling Personaleafdelingen deltager heller ikke aktivt i systemet, men en fremtidig udvidelse kan gøre det muligt for denne at lave statistik over personalet. Salgsafdeling Endnu en fremtidigt udvidelse af systemet, kunne være at give salgsafdelingen mulighed for at lave statistik over kunderne. 2.2 Use Cases I dette afsnit vil vi gennemgå de use cases der danner grundlag for det system vi ønsker at konstruere. Vi starter med at præsentere en samlet oversigt over de use cases der kunne være aktuelle for systemet og derfra udvælge de kerne use cases vi mener danner grundlag for systemet. Diagrammet på figur 2.1 viser samtlige aktører og use cases i systemet samt relationerne imellem disse. Følgende use cases er identificerede som kerne use cases i systemet, og er specificerede nedenstående. 9
2.2. USE CASES KAPITEL 2. REQUIREMENTS Opret reservation Bestil rejse Log ind Opret kunde Log ind Afbestil rejse Rediger kunde Ændre bestilt rejse Slet reservation Assistent Kunde Rediger reservation Slet kunde Ændre kunde data Log ud Log ud Ønskes oprettet som kunde Søg efter grupper kriterier «uses» «uses» Salgsafdeling Personaleafdelingen Søg efter kunder Søg efter ansatte Figur 2.1: Oversigt over samtlige use cases Opret reservation Rediger reservation Slet reservation Opret kunde Rediger kunde Slet kunde 10
2.2. USE CASES KAPITEL 2. REQUIREMENTS Opret reservation Preconditions: Der forudsættes at afgangen findes i systemet. Basic flow: En kunde henvender sig til en assistent med et ønske om en rejse. Assistenten laver en forespørgsel på systemet efter billetantal, afgang til den ønskede destination, samt evt. returafgang, på den/de pågældende dato/datoer. Kunden kan vælge mellem følgende billetkategorier: dyre, mindre dyre samt billige. Hvis kunden fortsat ønsker at reservere en eller flere billetter, beder assistenten efter kundens kundenummer. Hvis kunden ikke er oprettet i systemet, opretter assistenten kunden og fortsætter reservationen. Ellers taster assistenten kundens kundenummer ind, og forsætter reservationen iht. afgang(e), antal og billetkategori. Assistenten kan nu oplyse kunden om nummeret på den reserverede plads, på hhv. ind- og udrejse. Postconditions: Der er nu knyttet en reservation til kunden, der indholder billetter knyttet til de valgte pladser på afgangen. Relationships: Assistenten kommunikerer med Opret reservation og evt. Opret kunde. Use Case diagram: Se figur 2.2. Vælg reserver Forespørg efter afgang(e) Rediger kunde Assistent Find kunde Opret kunde (database over kunder) Vis oversigt Reserver plads(er) Figur 2.2: Use case diagram for Opret reservation. 11
2.2. USE CASES KAPITEL 2. REQUIREMENTS Rediger reservation Preconditions: Der forudsættes at kunden samt den reservation der ønskes ændres findes i systemet. Basic flow: En kunde kan ønske at ændre en reservation, hvis kunden ikke kan rejse på den valgte dato eller tidspunkt. Kunden henvender sig til assistenten som sørger for at reservationen bliver ændret. Assistenten beder om et kundenummer og får en liste frem over alle kundens reservationer. Assistenten vælger den ønskede reservationer, der skal ændres. Postconditions: Der gælder nu at den gamle reservation er nedlagt og den nye reservation er knyttet til kunden. Relationships: Assistenten kommunikerer med Rediger reservation. Use case diagram: Se figur 2.3. Vælg rediger reservation Find kunde Vis reservations oversigt Forespørg efter afgang(e) Assistent (kunde database) Opdater reservationer Figur 2.3: Use case diagram for Rediger reservation. Slet reservation Preconditions: Reservationen skal eksistere i systemet. Basic flow: En kunde kan ønske at slette en reservation hvis kunden ikke har lyst til at rejse alligevel. Kunden henvender sig til assistenten som sørger for at reservationen bliver slettet. Assistenten beder om et kundenummer, hvis kunden eksisterer i systemet får assistenten en liste frem over alle kundens reservationer. Assistenten vælger en eller flere af de ønskede reservationer der skal slettes. Postconditions: Der gælder nu at reservationen er slettet, og de reserverede pladser på afgangen er frigivet. Relationships: Assistenten kommunikerer med Slet reservation Use case diagram: Se figur 2.4 på side 12 Vælg slet reservation Find kunde Vis reservations oversigt Slet valgt reservation (kunde database) Assistent Figur 2.4: Use case diagram for Slet reservation. 12
2.2. USE CASES KAPITEL 2. REQUIREMENTS Opret kunde Preconditions Ingen. Basic flow: Hvis en person ikke er kunde skal vedkommende kunne oprettes i systemet. Der oplyses personlige data som navn, adresse, telefonnummer, e-mail samt evt. firmanavn. Postconditions Kunden er blevet oprettet i systemet og kan nu frit benytte de gode services som bucket airlines tilbyder. Relationships: Assistenten kommuniker med Opret kunde. Use case diagram: Se figur 2.5. Vælg opret kunde Forespørg efter personlige oplysninger Check om kunde eksisterer Opret kunde Assistent (kunde database) (kunde database) Figur 2.5: Use case diagram for Opret kunde. Rediger kunde Preconditions Kunden skal eksistere i systemet. Basic flow: En kunde kan ønsker at få sine personlige oplysninger, såsom f.eks. navn, adresse eller tlf. nr., ændret. Assistenten har derfor mulighed for at tilpasse disse data. Postconditions Der gælder nu at kunden har fået ændret sine data. Relationships: Assistenten kommunikerer med Rediger kunde. Use case diagram: Se figur 2.6 Vælg rediger kunde Find kunde Ændre kunde data Assistent (kunde database) (kunde database) Figur 2.6: Use case diagram for Rediger kunde. Slet kunde Preconditions: Kunden skal eksistere i systemet og må ikke have nogle reservationer. Basic flow: Når en kunde ikke længere ønsker at være kunde, kan vedkommende henvende sig til en assistent der så sletter kunden, såfremt denne handling er lovlig dvs. at kunden ikke har fremtidige reservationer i systemet. Postconditions: Kunden er fjernet fra systemet. Relationships: Assistenten kommunikere med Slet kunde. Use case diagram: Se figur 2.7 13
2.3. NON-FUNCTIONAL REQUIREMENTS KAPITEL 2. REQUIREMENTS Vælg slet kunde Find kunde Check for udestående Slet valgt kunde (kunde database) (kunde database) Assistent Figur 2.7: Use case diagram for Slet kunde. 2.3 Non-functional requirements I ovenstående use cases har vi beskrevet systemet funktionelle krav, men ud over disse krav findes de non-funktionelle krav. Når vi betragter systemet som en helhed, må vi antage at flyselskabet ønsker at flere end én assistent kan anvende systemet af gangen - vi har derfor brug for en klient/server platform idet data og beregninger er centraliserede mens brugerne er distribuerede. Desuden er følgende non-funktionelle krav overvejede: 2.3.1 Tilgængelighed Det er vigtigt at vores system har en høj tilgængelighed i det tidsrum hvor det bliver anvendt. Dette dækker over almindelig kontor tid for Bucket Airline. Dvs. at systemet skal være tilgængeligt hele tiden dette gælder også under opdatering af data, backup etc. I fremtiden kan dette blive udbygget til 24-7, hvis kunder skal have mulighed for at bestille billetter online via et website. 2.3.2 Sikkerhed Sikkerhed er ikke noget som bliver dækket af systemet, idet vi forventer at Bucket Airline benytter systemet indenfor et sikkert lokalt netværk. I fremtiden kan dette blive udbygget, således at kunder har mulighed for at logge ind med et brugernavn samt password på et website her kan det også blive nødvendigt med en krypteret forbindelse. 2.3.3 Performance Det er essentielt at systemet har høj performance samt en god respons tid fra serveren således at kunden ikke skal vente i flere minutter ved interaktion med assistenten, eller i fremtiden med systemet igennem websitet. 2.3.4 Fejl tolerance Systemet skal kunne gendannes efter en evt. strømafbrydelse/genstart. 2.3.5 Scalability Systemet skal kunne benyttes af flere samtidige brugere. I fremtiden skal systemet kunne håndtere endnu flere samtidige brugere i form af kunder der benytter systemets via et website. 14
Kapitel 3 Analyse & Design I dette afsnit vil vi analysere samt designe systemet. Vi starter med en analyse af problem domænet, hvor vi betragter de elementer der findes samt koblingen i mellem disse. Derefter vil vi lave et design forslag der skal ligge grund for implementeringen i det videre forløb. Under designet vil vi præsentere en række design mønstre som vi har brugt. Designet har to fokus områder som er design af arkitekturen samt detaljeret design. Design af arkitektur diskuterer den hensigtsmæssige arkitektur og de argumenter der er for og imod. Derefter vil arkitekturen blive behandlet fra en bottom-up perspektiv hvor vi i detailed design ser på hvorledes vi kan splitte systemet op og designe de små dele for sig og samle det igen til en helhed. 3.1 Domæne model På figur 3.1 ses klassediagrammet for vores system. Klasse diagrammet indeholder 3 klynger med hver deres tilhørende klasser. Afgang: Den består af to klasser, nemlig Plads der modellerer de pladser der findes på afgange samt klassen Afgang der modellerer den fysiske afgang. Der er tilknyttet opretbillet() samt sletbillet() funktionaliteten, således tilbyder systemet mulighed for at brugeren kan oprette samt slette billetter i systemet. Reservationer: Klyngens ansvar er at binde en person, i form af kunde, og en afgang sammen. Dette opnås ved de to klasser Reservation samt Billet. Reservation forbinder en kunde til en eller flere billetter. Billet har tilknyttet afgangen samt pladsen for den pågældende reservation. Reservation klassen har tilknyttet funktionalitet i form af to metoder, nemlig tilføj samt fjern billet, der gør det muligt at tilføje en billet til den rejsende kunde. Personer: Klyngen modeller de mennesker der er i problem domænet. Dette drejer sig om Assistenten samt kunden. Assistenten har ikke den store rolle i systemet, udover når der oprettes reservationer så bliver vedkommende vedhæftet idet man så i fremtiden kan udvide systemet, således at man f.eks. kan søge på hvilken assistent der har solgt flest rejser. Kunden derimod spiller den helt centrale rolle i systemet, idet at man som udgangspunkt ofte skal have en kunde for at kunne betjene systemets funktionaliteter. 15
3.2. ARKITEKTUR KAPITEL 3. ANALYSE & DESIGN Personer Kunde Assistent -login -kunde.nr -firma -navn -adresse -tlf -e-mail +hentreservationer() +tilføjreservation() +sletreservation() 1 1 Reservationer - Reservation 1..* 1..* +tilføjbillet() +fjernbillet() 1 1..* Billet -rejsende -tilføjbillet() tilføjer en reference til en billet til reservationen -fjernbillet() fjerner referencen til en billet 1 0..* Afgange 1 1 Plads -nummer -type -reserveret +frigiv() +reserver() * Afgang -dato -tidspunkt -fra -til +opretbillet() +sletbillet() 1 - opretbillet() tager som parameter rejsende og type og returner et Billet objekt med en tilknyttet plads. - sletbillet() tager som parameter et Billet objekt og frigiver pladsen. Figur 3.1: Klassediagram Overordnet ville vi fange de fysiske objekter der indgår i vores kerne use cases og modeller disse i systemet. 3.2 Arkitektur Vi skal ved hjælp af de funktionelle krav (use cases) og non-funktionelle krav vurdere hvilken arkitektur der er passende til vores system. På figur 3.2 ses en generel arkitektur, der er delt op i User Interface, Business Logic og Data Management. Vores system vil komme til at bestå af en server og en klient, hvor arkitekturen på figur 3.2 nødvendigvis skal deles op. Dette betyder at en del af arkitekturen ligger på klienten mens resten befinder sig på serveren. Der findes forskellige løsninger på problematikken i at dele arkitekturen op. Vi har valgt at løse det ved hjælp af en Two-Tiered arkitektur, der benytter Remote User Interface design mønstret, som kan ses på figur 3.3. Denne arkitektur er bedst egnet til vores system med de funktionelle og non-funktionelle krav vi har opstillet tidligere i dette dokument. Det er naturligt at placere snittet her da vores Application Kernel er reletivt tæt knyttet til Database Access og Database. Derudover udnytter vi netværkskommunikationen optimalt når vi har delt det op på denne måde. Hvis f.eks. Dialog Control 16
3.2. ARKITEKTUR KAPITEL 3. ANALYSE & DESIGN Figur 3.2: Arkitektur havde ligget på serveren ville vi opleve, at meget data skulle overføres over nettet mellem Presentation og Dialog Control. Det samme ville gælde hvis vi havde lagt Application Kernel på klienten pga. den før omtalte sammenhæng med Database Access og Database. På denne måde vil serveren stå for behandling og opdatering af data, mens klienten kun står for at præsentere systemet for en bruger, samt lave forespørgelser til serveren. Presentation Dialog Control User Workstation (PC) Presentation Client 1..* Dialog Control 1 Application Kernel Database Access Remote User Interface Server Application Kernel Application Server Database Database Access Database Logical Layers Two Distribution Layers Two Physical Layers Two-Tiered-Architecture Figur 3.3: Two-Tiered-Architecture Idet klienten kun står for Præsentation og Dialog Kontrol opnår vi såkaldte tynde klienter. Dette betyder at klienten har User Interface og serveren har Business Logic og Data Management. 3.2.1 Klient Klienten indeholder Præsentation og Dialog Kontrol. Vores klient bliver som før omtalt en tynd klient. Dette vil sige at klienten forespørger serveren om at få noget udført i domæne modellen. Serveren giver respons tilbage til klienten, der kan præsentere det tilbagekomne for en bruger af systemet. 17
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN 3.2.2 Server Serveren indeholder Application Kernel, Database Access samt Database. Det betyder at vi kan lave en 1:1 mapping mellem vores Domain model og vores Application Kernel. Vores Applikation Kernel kommer altså til at indeholder komponenterne og klasserne fra Domain modellen. 3.3 Detailed Design 3.3.1 Database Som persistens lag har vi valgt at benytte en relationel database. Kunde -navn -firma -tlf -e-mail -adresse 1 0..* Reservation 1 Billet -rejsende 1 Plads -nummer -type 1 1..* 0..* 1..* 1 Afgang -dato -tidspunkt -fra -til 1 2 Destination -land -adresse -lufthavn Figur 3.4: Applikation Kernel diagram På figur 3.4 ses klasserne i vores applikation kernel med tilhørende attributter. Pilene på diagrammet angiver hvilken vej assosieringen af objekterne går. Ud fra diagrammet kan man f.eks. se at det ud fra et Kunde objekt er muligt at få fat på en række reservations objekter, hvorimod det omvendte ikke er muligt. Vi skal have afgjort hvordan vi mapper klasserne til RDBMS 1 tabeller. Vi benytter her mønstrene og terminologierne fra Crossing Chasms[6] dokumentet i forbindelse med designet af RDBMS tabellerne. Hver klasse mappes til en tabel i databasen. Der tilføjes en søjle til hver tabel der indeholder objektets OID (object identifier eller primary key). 1-1 og N-1 relationer løses vha. foreign-key reference. F.eks. indeholder AfgangTabel 2 foreign-key referencer til rækker i DestinationTabel. 1-N relationer løses vha. inverse foreign-key (back pointer) princippet. F.eks. indeholder ReservationTabel 1 foreign-key reference til KundeTabel. 1 Relational DataBase Management System 18
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Kunde klassen mappes til KUNDETABEL: KUNDETABEL ID INT IDENTITY PRIMARY KEY NAVN VARCHAR ADRESSE VARCHAR TLF VARCHAR EMAIL VARCHAR FIRMA VARCHAR Assistent klassen mappes til ASSISTENTTABEL: ASSISTENTTABEL ID INT IDENTITY PRIMARY KEY LOGIN VARCHAR Reservation klassen mappes til RESERVATIONTABEL: RESERVATIONTABEL ID INT IDENTITY PRIMARY KEY KUNDEID INT Billet klassen mappes til BILLETTABEL: BILLETTABEL ID INT IDENTITY PRIMARY KEY REJSENDE VARCHAR PLADSID INT AFGANGID INT RESERVATIONID INT Plads klassen mappes til PLADSTABEL: PLADSTABEL ID INT IDENTITY PRIMARY KEY TYPE INT NAVN VARCHAR AFGANGID INT Afgang klassen mappes til AFGANGTABEL: AFGANGTABEL ID INT IDENTITY PRIMARY KEY AFGANGSDATODATE DATE AFGANGSDATOTIME TIME ANKOMSTDATODATE DATE ANKOMSTDATOTIME TIME FRAID INT TILID INT Destination klassen mappes til DESTINATIONTABEL: DESTINATIONTABEL ID INT IDENTITY PRIMARY KEY LAND VARCHAR LUFTHAVN VARCHAR 19
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN 3.3.2 Database Access Vi følger rådet fra Crossing Chasms[6] dokumentet og vælger en database access løsning der er orthogonal til klasserne i applikation kernelen fremfor at udvide klasserne i vores applikation kernel med database access kode. Vi vælger en arkitektur hvor vi har en central broker klasse der har til opgave at sørge for persistens af vores applikation kernel objekter. Vi opnår på den måde at den eneste nødvendige ændring til vores applikation kernel klasser bliver tilføjelsen af en OID (objekt identifier, primary key) attribut. 3.3.3 Application Kernel På figur 3.1 ses en oversigt over klasserne i vores applikation kernel. opretbillet() (se Tabel 3.1) og sletbillet() (se Tabel 3.2) er de eneste komplekse funktioner. Operation Formål Inddata Betingelser Effekt Algoritme Placering Involverede objekter opretbillet() At oprette en billet til den pågældende afgang. Navn på rejsende (streng) Plads type (1., 2. eller 3. klasse). Ingen Såfremt der var en ledig plads af den ønskede type returneres et nyt Billet objekt og den ledige Plads markeres som reserveret. Plads tabellen løbes igennem og den første ledige plads af den ønskede type markeres som reserveret. Et nyt Billet objekt oprettes og pladsen tilknyttes. Afgang Afgang, Billet, Plads Tabel 3.1: Operationsspecifikation for opretbillet Operation Formål Inddata Betingelser Effekt Placering Involverede objekter sletbillet() At slette en billet til den pågældende afgang. Billet der skal slettes Billet tilhører den pågældende afgang Billetten slettes og den tilhørende plads frigives. Afgang Afgang, Billet, Plads Tabel 3.2: Operationsspecifikation for sletbillet 20
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN 3.3.4 Klient/Server På serveren ligger vores Application Kernel, som vores klient skal have kontakt med. Klienten bruger forskellige klasser i Application Kernel, og vi har valgt at bruge et facade mønster. På den måde får klienten et enkelt interface til et mere complex subsystem. På figur 3.5 ses princippet i facade mønsteret, hvor klienten kun taler til en facade klasse, kaldet ServerFacade. Denne klasse sørger for at dirigere klientens request videre ned i det underliggende system, som i vores tilfælde er Application Kernel og Database Broker. Det vil sige at det er ServerFacade klassen og klienten der står for kommunikationen over et netværk i vores system. Igennem facaden vil klienten have den nødvendige tilgang til Application Kernel og Database Broker. Klient Server ServerFacade Database Broker Application Kernel Figur 3.5: Facade mønster Klient Klienten laver et opkald til serveren hvorved den, hvis der findes en server, får adgang til den Application Kernel, der ligger på serveren. Da klienten er en tynd klient og kun består af User Interface bliver dette yderligere beskrevet i afsnit 3.3.5 der omhandler brugergrænseflade. Klientens tilgang til serveren foregår igennem ServerFacaden. Server Serveren indeholder vores domæne model (Application Kernel), som vi ønsker en klient skal kunne benytte. Som før omtalt benytter vi et facade mønster i serveren for at undgå at klienten skal tilgå Application Kernel og Database Broker direkte. Tilgangen til serveren bliver mere simpel når der bruges et facade mønster. I ServerFacade har vi følgende metoder: findafgange() tabel 3.3 findkunder() tabel 3.4 tilføjkunde() tabel 3.5 opdaterkunde() tabel 3.6 fjernkunde() tabel 3.7 opretreservation() tabel 3.8 sletreservation() tabel 3.9 getdestinations() tabel 3.10 21
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Operation Formål Inddata Betingelser Effekt Algoritme Placering Involverede objekter findafgange() At finde afgange i systemet der matcher inputkriterier Afgang- og ankomst dato (dato/null) lufthavnen der flyves fra og til. (streng/null) Ingen Der søges i databasen efter afgange, som returneres Der oprettes et kriterie, som gives videre til Broker ServerFacade Broker, Afgang Tabel 3.3: Operationsspecifikation for findafgange() Operation Formål Inddata Betingelser Effekt Algoritme Placering Involverede objekter findkunder() At finde kunder i systemet der matcher inputkriterier kundenr (streng) navn, adresse, telefonnummer, e-mail og firma (streng/null) Ingen Der søges i databasen efter kunder, som returneres Der oprettes et kriterie, som gives videre til Brokeren, der finder kunden eller kunderne i databasen. ServerFacade Broker, Kunde Tabel 3.4: Operationsspecifikation for findkunder() Operation Formål Inddata Betingelser Effekt Algoritme Placering Involverede objekter tilfojkunde() At tilføje en kunde til vores system navn, adresse, telefonnummer, e-mail og firma (streng) Ingen. Det er op til anden part at sørge for at kunden ikke findes i forvejen Der er blevet oprettet en kunde, som er blevet tilføjet databasen Et Kunde objekt oprettes og gemmes vha. Brokeren i databasen ServerFacade Broker, Kunde Tabel 3.5: Operationsspecifikation for tilfojkunde() 22
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Operation Formål Inddata Betingelser Effekt Algoritme Placering Involverede objekter opdaterkunde() At opdatere en kundes oplysninger i databasen Kunde navn, adresse, telefonnummer, e-mail og firma (streng) Kunden skal findes i databasen på forhånd Kundens oplysninger er ændret Kunden findes i databasen hvorpå oplysningerne ændres og kunden gemmes i databasen igen ServerFacade Broker, Kunde Tabel 3.6: Operationsspecifikation for opdaterkunde() Operation Formål Inddata Betingelser Effekt Algoritme Placering Involverede objekter fjernkunde() At fjerne en kunde fra systemet Kunde Kunden skal findes i databasen på forhånd Kunden er slettet Kunden findes i databasen hvorpå den slettes ServerFacade Broker, Kunde Tabel 3.7: Operationsspecifikation for fjernkunde() Operation Formål Inddata Betingelser Effekt Algoritme Placering Involverede objekter opretreservation() At sammenhæfte en Kunde med Afgang, Billet og Plads i form af en Reservation Rejsende (array af strenge) Plads type Afgang Kunde Kunde og Afgang skal findes og der skal være billetter nok ledige på den pågældende afgang til alle rejsende Kunden har fået tilknytter en Reservation til sig. Kunden og Afgangen findes og der undersøges om der er billetter nok til alle rejsende. Hvis der er flere billetter tilføjes de til reservationen som til sidst tilføjes kunden. Til sidst gemmes det hele i databasen. ServerFacade Broker, Kunde, Afgang. Plads, Billet Tabel 3.8: Operationsspecifikation for opretreservation() 23
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Operation Formål Inddata Betingelser Effekt Algoritme Placering Involverede objekter sletreservation() At slette en Kundes Reservation Kunde Reservation Kunde og Reservation skal findes Kundens reservation er slettet og pladserne der hørte til reservationen er blevet frigivet Kunde og Reservation findes i databasen og billetterne slettes fra afgange og reservationen slettes. Til sidst gemmes alle ændringer i databasen ServerFacade Broker, Kunde, Afgang, Plads, Billet Tabel 3.9: Operationsspecifikation for sletreservation() Operation Formål Inddata Betingelser Effekt Placering Involverede objekter getdestinations() At hente destinationer fra databasen Ingen Ingen Destinationer hentes ud af databasen ServerFacade Broker Tabel 3.10: Operationsspecifikation for getdestinations() 24
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN 3.3.5 Brugergrænseflade I designet af en brugergrænseflade til et system er det to perspektiver der skal tages højde for, nemlig systemets brugere samt systemets udvikler. Vi vil i efterfølgende tre afsnit gennemgå designet set først fra brugens synspunkt, dernæst fra udviklerne synspunkt samt endelig opstille en skitse af en brugergrænseflade der både opfylder ovenstående to perspektiver samt kravspecifikationen. Som hjælp hertil vil vi gøre brug af design mønstre, samt personlige erfaringer. Set fra brugerens perspektiv I designet af brugergrænsefladen til vores system, må vi forholde os til hvordan systemet mest muligt understøtter brugerne af systemet i deres arbejde, og derfor ikke er til unødig besvær. Det er derfor en god ide at betragte nedenstående principper: Visability: Brugeren guides i brugen af systemet vha. fremstillingen af brugergrænsefladen. F.eks. ved hjælp af en værktøjsbjælke indeholdende ikoner svarende til systemet funktioner. Affordance: Brug af metaforer der indikerer brugen af systemet. Natural mapping: Brugen af entydige relationer imellem en funktionalitet samt de mekanismer der udfører denne. F.eks. ved brugen af wizards i systemet. Contraints: Minimere nødvendig viden samt antallet af muligheder, for at udføre en funktionalitet. F.eks. brugen af en combobox indeholdende valgmulighederne, eller brugen af en pop-up kalender ved dato valg. Conceptual models: Overensstemmelse imellem brugerens forventninger samt systemets opførsel. Systemet sletter f.eks. ikke en kunde, når brugen trykker på knappen opret kunde. Feedback: Indikationer af at en funktions fremskridt samt status. F.eks. ved brugen af Afslut skridtet i en wizards. Eller brugen af hinting i værktøjsbjælken. Safety: At beskytte brugeren imod uhensigtsmæssige handlinger eller fejl. F.eks. brugen af Tilbage-funktionaliteten i en wizard eller vha. shields ved f.eks. annullering af en wizard. Flexibility: Tillad bruger at ændre mening midt i en funktion. Igen f.eks. ved brugen af enten Tilbage- eller Annuller-funktionaliteten i en wizard. Ved at sammenholde ovenstående principper skulle man opnå et design for systemets brugergrænseflade, der først og fremmeste gør brugernes arbejdet med systemet hurtigere, men også et system som er lærenemt og hvor brugerne kan huske hvordan man bruger de enkelte funktioner. Og endelig giver systemet også de enkelte bruger en tilfredsstillelse, idet antallet af succesfulde gennemførte opgaver gerne skulle være større end antallet af fejl begået af brugeren [2]. En anden vigtig overvejelse er hvorvidt brugeren ønsker at interagerer med systemet igennem en objekt-orienteret brugergrænseflade eller igennem en form baseret brugergrænseflade. En grund til at vælge den formbaserede brugergrænseflade over den objekt-orienterede, er at den erfarne bruger som ofte ønsker at udfører nogle fastlagte use cases så hurtigt som muligt, idet brugeren ved hvilke data system skal bruge, 25
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN samt hvilken data der allerede forligger. Brugeren har derfor ikke brug for mange medie skift, dvs. skift imellem tastatur samt mus, men derimod en brugergrænseflade der reflekterer arbejdsgangen med genvejstaster. Men en formbaseret brugergrænseflade kan også være til nytte for den utrænede eller semi-trænede bruger. Et simpelt system indeholdende en eller to use cases kan nemt designes, idet den formbaserede brugergrænseflade dirigerer arbejdsgangen. Derimod er en formbaseret brugergrænsefalde mindre fleksibel end en objekt-orienteret, idet arbejdsgangen dikteres på forhånd, og en uforudset use case vil som oftest være umulig at gennemføre uden ændringer i softwaren. En formbaseret brugergrænseflade, der dikterer en ikke intuitiv arbejdsgang, kan være direkte ubrugelig for slutbrugeren. Det er selvfølgelig også muligt at blande formbaserede og objekt-orienterede brugergrænseflader således at den endelige brugergrænseflade passer brugenes behov bedst muligt [3]. Set fra udviklerens perspektiv Designet af brugergrænsefladen set fra udviklerens synspunkt indeholder følgende overvejelser: Ressourceforbruget af systemet. Systemet skal have højst mulig svartid, set fra et performance synspunkt. Skal kunne testes, pga. stabiliteten af systemet. Kildeteksten skal kunne administreres, pga. evolution. Før ovenstående punkter kan overvejes, er det klart at den valgte tekniske platform i sig selv kan fremtvinge begrænsninger i valget af designet. Men bortset fra dette er det størst problem hvordan man omgås ændringer af systemet. Netop fordi at brugergrænseflade samt business logic ændres i kraft af implementeringen af nye funktioner eller modificering af eksisterende, hvorimod domæne modellen som oftest vil ligge fast. Derfor har vi valgt at benytte os af Model-View-Controller (MVC) mønstret, idet vi opnår at domæne modellen samt kerne funktionaliteten er adskilt fra den grafiske brugergrænseflade [4]. Man kan mappe MVC mønstret direkte over på en two-tier Figur 3.6: Model-View-Controller mønstret. client/server arkitekturen, evt. i en enkelt applikation, idet data og kerne funktionaliteten kører på serveren mens klienten sørger for brugergrænsefladen samt render funktionalitet. Der er klart at jo mere kompleks render algoritmerne bliver jo tykkere 26
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN bliver klienten. En anden ting man skal tage højde for, er om vi ønsker et Single-Document-Interface (SDI) eller Multiple-Document-Interface (MDI). Hvis vi vælger et SDI vil det betyde at brugeren af systemet kun kan udføre en use-case af gangen. F.eks. vil en assistent, der er i gang med at oprette en reservation bestilt f.eks. via fax, ikke samtidigt kunne modtage et telefon opkaldt hvor en ny kunde gerne vil oprette en reservation. Her bliver assistenten derfor nødsaget til at afslutte den igangværende reservation, inden den nye kunde samt reservation kan oprettes. En løsning til ovenstående problem, ville være at i stedet anvende en MDI brugergrænseflade. Det er klart at en MDI er mere kompleks at designe end en SDI. Her skal man overveje hvorvidt de forskellige vinduer (eller views) i systemet skal kommunikere med hinanden. Hvis brugeren f.eks. i det ene vindue opretter en ny reservation, skal et andet vindue der indeholder en oversigt over samtlige af kundens reservation automatisk blive notificeret og opdateret, f.eks. ved brug af observere mønstret? En anden overvejelse, er hvorvidt systemet skal holde styr på de forskellige vinduer. Her kunne man f.eks. gøre brug af View Handler mønstret, hvor en View Handler klasse sørger for at åbne, manipulere (bringe i front, maksimerer, minimerer etc.) og fjerne vinduer (views) fra systemet. Herved opnår man altså at det både bliver nemt for systemet men især også for brugeren at håndtere samtlige åbne vinduer [5]. Design af brugergrænsefladen Vi vil her gennemgå designet for en brugergrænseflade, der opfylder de krav der er stillet iht. de fundne use cases. Vi har valgt at gøre brug af en MDI brugergrænseflade, hvor de enkelte use cases er opbyggede som wizard-vinduer. Dette gør at vi opnår en primært formbaserede brugergrænseflade, men hvor de enkelte wizads også vil gøre bruge af objekt-orienteret design. Derved opnår vi størst mulig fleksibilitet for brugeren, idet vi samtidig sørger for at de enkelte use cases opfyldes. Vi vil først beskrive systemets hovedvindue, og dernæst specificere de enkelte vinduer indeholdt i dette. Hovedvindue Vi har valgt at beskrive hovedevindue vha. et navigationsdiagram. Dette giver en oversigt over hvilke elementer der er at finde i brugergrænsefladen, samt hvilke elementer der går igen. Opret kunde Vinduet indeholder tekstfelter til indtastning af kundens personlige data. Se figur 3.8. Find kunde Vinduet er delt i to dele. Den øverste del indeholder tekstfelter til indtastning af søgekriterier af kunden, mens den nederste indeholder en tabel med samtlige fundne kunder i systemet der matcher søgekriterierne. Desuden er der mulighed for at enten redigere den valgt kunde, eller oprette en ny kunde. Derved mister man ikke den allerede indtastede data iht. den/de valgte afgang(e). Se figur 3.9. 27
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Rediger kunde Slet kunde Opret kunde Opret kunde knap Find kunde Rediger kunde knap Find kunde Slet kunde knap Log ind knap Log ind Log ud knap Hoved menu Find afgang Opret reservation knap Rediger reservation knap Find kunde Find kunde Slet reservation knap Afgangs oversigt Vælg reservation Vælg reservation Find kunde Find afgang Oversigt Passagerer liste Afgangs oversigt Oversigt Oversigt Figur 3.7: Navigationsdigram over brugergrænsefladen. Bucket Airlines - Opret kunde Navn: Adresse: Indtastningfelter til informationer om kunden Telefon nr.: Firma: Annuller OK Knappen OK opretter kunde i systemet Figur 3.8: Design af Opret kunde -dialogen. Rediger kunde Designet af Rediger kunde -dialogen vil minde meget om Opret kunde -dialogen, idet data fra Find kunde -dialogen overføres, og derefter kan redigeres. Slet kunde Slet kunde -dialogen vil stort set kun være en bekræftelse af om man ønsker at slette den valgte kunde. 28
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Bucket Airlines - Find kunde Kunde nr.: Navn: Adresse: Telefon nr.: Firma: 4578 Indtastningfelter til søgekriterier. Det er ikke nødvendigt at udfylde alle Opret Stop Find Start søgning Kunde nr.: Navn Adresse Tlf. Nr. Firma 4578 John Doe Holme Olstrup 800-65985 Doe, Inc. Valgbare søgeresultater Rediger Annuller OK Fortsætter med den valgte kunde til det man valgte fra hovedmenuen, dette kunne evt. være Rediger kunde Figur 3.9: Design af Find kunde -dialogen. Find afgang Vinduet indeholder felter til valg af rejsetype. Der er brugt combobokse for at begrænse brugerens valgmuligheder. F.eks. er det kun muligt at rejse på hhv. 1., 2. eller 3. klasse. Endvidere er der mulighed for at åbne en kalender, der har til hensigt at gøre det nemmere for assistenten at vælge den rigtige dato. Se figur 3.10. Bucket Airlines - Find afgang Valg af type (enkelt eller tur-retur) Rejsetype Tur-retur 1. klasse Valg af Billettype Fra København Til Paris Valg af Fra - Til destination Udrejse Hjemrejse 10 Feb 03 20 Feb 03 Kalender Valg af dato for ud- og hjemrejse Valg af antal rejsende Antal passagerer 2 Voksne Annuller Næste > Figur 3.10: Design af Find afgang -dialogen. Passager liste Vinduet indholder felter til indtastning af passagerer. Se figur 3.11. Oversigt Indeholdet af oversigtvinduet kan variere alt efter hvor dette anvendes. Se figur 3.12. 29
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Bucket Airlines - Passager liste Passagerer Fornavn(e) Fornavn(e) Efternavn Efternavn Indtastning af navn på de passagerer der skal med på rejsen. Annuller < Tilbage Næste > Figur 3.11: Design af Passager liste -dialogen. Bucket Airlines - Oversigt Oversigt over oprettet reservation. Navn Adresse yada yada yada.. Oversigt over reservations- oplysninger Pris Dkr.XXX XXX < Tilbage Annuller Bekræft Endelig oprettelse af reservationen Figur 3.12: Design af Oversigt -vinduet. Vælg reservation Vinduet viser de reservationer der er tilknyttet den valgt kunde. Se figur 3.13. 30
3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Bucket Airlines - Reservations oversigt Kunde nr.: Navn: Adresse: Telefon nr.: Firma: 4578 John Doe Hole Olstrup 800-65985 Doe, Inc. Informationer om kunden Fly 54 Dato Tidspunkt Fra Til 1/8-2005 10:00-15:02 Odense Svendborg Liste over kundens reservationer. Annuller OK Figur 3.13: Design af Vælge reservation -dialogen. 31
Kapitel 4 Implementation I dette kapitel vil vi gå i dybden med implementeringen af systemet. Det hovedsaglige i dette kapitel er en gennemgang af implementerings muligheder der til en hvis grad afviger fra analysen og designet fra kapitel 3. Da vi har valgt at tage en bottom-up tilgang har vi valgt at starte med at diskutere database implementeringen, afsnit 4.1, som vi bygger vores applikations kerne på, afsnit 4.3. Derimellem ligger vi et kommunikations snit, database access afsnit 4.2, som gør det muligt for de øvre lag at tilgå databasen. Dernæst vil vi diskutere klient/server arkitekturen med henblik på implementeringen (afsnit 4.4) efterfulgt af brugergrænsefladen som ligger hos klienten (afsnit 4.5). Vi har desuden valgt at implementere systemet i JAVA, da dette giver os en hurtig implementering, da JAVA stiller et stort klasse bibliotek til rådighed. Desuden er kommunikationen også nem at implementere vha. RMI. Ulempen er at systemet bliver en smule langsommere end hvis vi havde implementeret det i et andet sprog, men fordelene overvejer stærkt ulemperne. 4.1 Database I forbindelse med implementation af den relationelle database stod valget mellem at udvikle vores egen database løsning (f.eks. vha. random access filer) eller at benytte en 3. parts relationel database. Umiddelbart var den sidste mulighed den mest tiltalende da vi på den måde ville spare en del implementationsarbejde. Vi var dog begrænset af kravet om at vores applikation skulle være self-containing og ikke må kræve installation af 3. parts programmer. En traditionel mysql eller postgresql database var derfor udelukket. Efter nogen søgning fandt vi frem til HSQLDB 1, en gratis, open-source, JDBC kompativel, SQL database skrevet i JAVA. HSQLDB database management systemet distribueres i en.jar fil. Brugen af database management systemet kræver kun at.jar filen tilføjes til classpath en. Ved at vælge en komplet SQL database som database opnår vi iøvrigt følgende fordele: Håndtering af sikre transaktioner (commit/rollback). Advancerede søge funktioner (select) 1 http://hsqldb.sourceforge.net/ 32
4.2. DATABASE ACCESS KAPITEL 4. IMPLEMENTATION Let adgang til data i databasen fra 3. parts programmer. HSQLDB databasen kan køre i 2 forskellige operation modes: In-process (kun en JVM må tilgå databasen) og Client/Server (fjere JVM er må tilgå databasen). Da vi ikke har distribueret database access og dermed kun har 1 JVM der tilgår databasen vælger vi at køre HSQLDB databasen i In-process mode. 4.1.1 Opsætning af database Vi benytter det medfølgende program: org.hsqldb.util.scripttool sammen med en række forskellige.sql script filer til at initialisere vores database. Filen init.sql indeholder sql kommandoerne der opretter de nødvendige tabeller i databasen (se iøvrigt under detail design af database i kapitel 3). Filerne afgange.sql, destinationer.sql, kunder.sql og pladser.sql indeholder en række insert sql statements der sørger for at indsætte noget test-data i databasen. Tilsidst kører vi post.sql scriptet for at lave et index på afgangid søjlen i plads tabellen (for at mindske søgetiden). Vores database indeholder ca. 80000 afgange fordelt over en periode på 60 dage startende fra 29/5/2003. Hver afgang indeholder 9 pladser (ialt ca. 720000 pladser). Derudover indeholder vores database ca. 200 kunder. Vi benyttede org.hsqldb.util.databasemanager programmet til at verificere at tabellerne og data erne blev korrekt indsat. 4.2 Database Access Vores idé til database access var at lave en central broker klasse der var istand til at håndtere persistering af klasserne i vores Applikation Kernel, samt at lave forespørgsler (søgninger) i databasen. Vi startede ud med at implementere en simpel prototype som vha. reflektion og hardcodede Java SQL datatype mappings kunne håndtere persistens af nogle af klasserne i vores applikation kernel. Denne prototype beviste overfor os at vores løsning var mulig, om dog en smule omfattende, at implementere. Vi undersøgte herefter muligheden for at benytte en 3. parts database broker. Vi kiggede bl.a. på JDO (Java Data Objects) 2 og OJB (ObJect Relational bridge) 3. OJB s Persistence- Broker API var en løsning der i høj grad lignede vores prototype implementation men som var vores implementation langt overlegen mht. fleksibilitet og funktionalitet. Vi valgte derfor at skrotte vores broker prototype til fordel for PersistenceBrokeren i OJB. 4.2.1 OJB PersistenceBroker OJB PersistenceBrokeren indeholder bl.a. følgende metoder til håndtering af persistens: store() delete() begintransaction() aborttransaction() getobjectbyquery() getcollectionbyquery() committransaction() 2 http://java.sun.com/products/jdo/ 3 http://db.apache.org/ojb 33
4.3. APPLICATION KERNEL KAPITEL 4. IMPLEMENTATION En stor fordel ved OJB PersistenBroker er at der kun kræves enkelte tilføjelser af OID id attributter til klasserne i applikation kernel for at gøre dem persistentbare. En anden stor fordel er at OJB PersistenseBroker selv sørger for transparent object caching således at der altid kun befinder sig en unik instans af et givent objekt i hukommelsen. Selve definitionen af hvordan de forskellige klasser mappes til tabellerne i vores database angives i en xml fil (repository user.xml). I samme fil angives også hvordan objekternes relationer skal håndteres samt hvorvidt relationerne skal ske gennem en proxy (lazy-loading). I filen repository user.xml ses hvordan vi har mappet de forskellige klasser til tabeller i databasen. 4.3 Application Kernel Vi har fulgt designet fra afsnit 3.3.3. 1-N relationer er implementeret vha. LinkedList fra JAVA Collection frameworket. Iforhold til vores design i afsnit 3.3.3 er eneste forskel at der er tilføjet id attributter til OID reference samt setid() og getid() metoder til samtlige klasser. Det skal bemærkes at Assistent klassen ikke er færdig implementeret. 4.4 Klient/Server Til Klient/Server kommunikation har vi valgt at bruge RMI, hovedsagligt fordi det er et godt og velgennemtestet framework, der giver en let tilgang til at lave Klient/Server systemer. Klienten er implementeret på almindelig vis når det gælder RMI. Der connectes til serveren hvorved der skabes forbindelse, så metoderne implementeret på serveren kan benyttes fra klienten. server = (ServerFacadeInterface) Naming.lookup("rmi://"+host+":1099/BucketServer"); hvor ServerFacadeInterface er det interface i RMI sammenhæng, der definerer metoderne på Serveren. Omkring selve klienten er brugergrænsefladen bygget op, som bliver beskrevet i afsnit 4.5 Serveren er også implementeret på almindelig vis når det gælder RMI. Med et interface der definerer metoderne og en almindelig klasse som server, der implementere disse metoder, så de kan kaldes af en klient. Serveren funktionalitet er implementeret igennem et facade mønster, hvor der findes de metoder klienten behøver for at kunne operere i vores Application Kernel og database. Metoderne der blev omtalt i design har vi implementeret. Implementation af Klient/Server har udmundet i afvigelse fra designet i vores Application Kernel. Samtlige klasser i Application Kernel nedarver fra UnicastRemoteObject, og har hver fået tilknyttet et Interface. Dette er gjort for at løse et synkroniseringes spørgsmål når flere klienter tilgår samme objekt på serveren. Vi opnår herved at objektet kun findes på serveren, imens der sendes stubbe ud til klienterne. Når klienter manipulerer objekterne sker dette via stubben på serveren. Det eneste problem der opstår ved bruge af UnicastRemoteObjekter, er når vi fra klientes side medsender objekter som parametre til en metode i serverfacaden. Her er det stubben der medsends, og vi bliver derfor på serveren nødsaget til at lave et tabelopslag i databasen for at lokalisere det rigtige objekt før metoden udføres. 34
4.5. BRUGERGRÆNSEFLADEN KAPITEL 4. IMPLEMENTATION 4.5 Brugergrænsefladen Vi har valgt at implementere brugergrænsefladen vha. Swing, som er et veldokumenteret og -testet framework i Java 4. Ellers er brugergrænsefladen stort set implementeret efter det design der blev præsenteret i afsnit 3.3.5. Princippet bag implementeringen, er at brugeren arbejder med et hovedvindue indeholdende flere interne vinduer, dvs. en desktop. Fra hovedvinduet er det så mulig enten vha. menu- eller værktøjsbjælken at udføre den ønskede funktionalitet (se figur 4.1). Brugeren har desuden mulighed for at minimere samtlige vinduer, eller vælge et specifikt vindue, hvis dette er blevet væk i mængden, i menuen Vinduer. De enkelte forløb, opret-, rediger-, slet kunde samt opret-, rediger-, slet reservation Figur 4.1: Screenshot af systemets hovedvindue. har vi valgt at implementere som guider (Wizards design mønster, [2]), hvor de enkelte trin er udskiftelige paneler. Et eksempel på dette er Ny reservation guiden vist i figur 4.2. Ved hjælp af guiden, har brugeren hele tiden mulighed for at følge med i hvor langt vedkommende er nået, samt hvor mange trin der er tilbage. Endelig viser det sidste trin i samtlige guide, en oversigt af det udførte arbejde. Hvis brugerne ved oversigten finder en fejl, har vedkommende altid mulighed for at rette denne, ved at bruge Tilbage -knapperne. Vi har desuden i guiden Ny reservation, valgt at implementere en kalender der gør det mulig for brugeren at vælge den rigtige dato, hvis vedkommende f.eks. skal reserverer en plads for en kunde på en afgange næste fredag. Brugeren kender ikke nødvendigvis datoen på denne dag (Unambiguous format design mønster, [2]). Den implementerede kalender kan ses på figur 4.4. Desuden er der blevet gjort meget ud af at implementere filtre på input tekstfelterne i guiden, således at brugeren på forhånd ikke har mulighed for at indtaste forkert data. F.eks. er det ikke muligt at indtaste bogstaver og tegn, men kun numre, i feltet Tlf.nr. Der i det hele taget gjort meget for at beskytte brugeren af systemet imod uhen- 4 Se http://java.sun.com/products/jfc/#swing 35
4.5. BRUGERGRÆNSEFLADEN KAPITEL 4. IMPLEMENTATION Figur 4.2: Først trin af guiden Ny reservation. Figur 4.3: Sidste trin af guiden viser en oversigt. sigtsmæssige handlinger. Dette er gjort ved at bruge dialogbokse der, hvor brugeren udfører handlinger der kan have alvorlige konsekvenser (Shield design mønster, [2]). F.eks. viser figur 4.5 at brugeren bliver konfronteret med en dialogboks hvis der trykkes på annuller midt under udførelsen af en guide. Og hvis en bruger af systemet skulle blive i tvivl om hvordan en guide, eller bare et trin i en guide udføres, er der i brugergrænsefladen implementeret en hjælpefunktion indeholdende brugervejledninger. Endelig har vi for at opnå en mere fleksibel brugergrænseflade, valgt at gøre brug af SwingWorker 5 klassen. Denne gør det muligt at implementere en multi-trådet brugergrænseflade, hvor der bliver oprettet en ny tråd hver gang en guide køres. Dette gør at hele brugergrænsefladen ikke blokkeres når der startes en ny guide. 5 Se http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html. 36
4.5. BRUGERGRÆNSEFLADEN KAPITEL 4. IMPLEMENTATION Figur 4.4: Kalenderen hvorfra det er muligt at vælgt dato for ud- og hjemrejse. Figur 4.5: Dialogboks der bekræfter Annuller handlingen. 37
Kapitel 5 Test Vi vil i dette kapitel beskrive hvordan vi har testet vores system. Først beskrives hvorledes vi har testet de forskellige komponenter i systemet hver for sig. Derefter tester vi det samlede system og på den måde også hvordan de enkelte komponenter arbejder sammen. Når vi tester de enkelte komponenter, eller klasser benytter vi JUnit 1, som er et framework udarbejdet med henblik på at teste enkelte enheder i systemer på en nem og effektiv måde. I den samlede test er det svært at benytte JUnit, da vi skal teste hele systemet fra brugergrænsefladen til databasen. Det er generelt svært at teste brugergrænsefladen da man normalt har brug for menneskelig interaktion. Der findes dog værktøjer der kan teste brugergrænseflade, men det er ikke noget vi har brugt. 5.1 Komponent test Til test af de enkelte dele i vores system benytter vi som før omtalt JUnit, da det gør udvikling og evaluering af testkode en del nemmere. Normalt vil testkode have en masse print statements, som kan være svært at overskue og vurdere om det er korrekt. Når man bruger JUnit slipper man for at skulle bruge mennskelig analyse af resultatet, da JUnit sørger for at fortælle om der er fejl eller ej. Det foregår på den måde at man opstiller et test senario, hvor man kender det forventede output. Outputtet sammenlignes med det forventede og JUnit melder tilbage om det forløb som ventet. Herunder ses de JUnit tests vi har lavet: AllTests.java Kører alle de nedenstående tests AppKernelTest.java Tester vores Application Kernel, hvor vi tester domæne modellens klasser og deres metoder. De fleste metoder er trivielle, da der er mange set og get metoder. Disse behøver ikke grundig gennemtestning, men der er dog nogle eksempler på hvorledes det skal gøres. DatabaseTest.java Tester Databasefunktionalitet, om de forskellige objekter i Application Kernel kan skrives og læses korrekt. ServerFacadeTest.java Tester alle metoder i ServerFacaden. ServerFacaden er samlingspunktet i vores system, så derfor er det også vigtigt at den bliver testet grundigt. 1 http://www.junit.org 38
5.2. SAMLET TEST KAPITEL 5. TEST ClientServerTest.java Tester kommunikationen mellem klient og server, herunder også nogle af metoderne i ServerFacaden. Det smarte ved JUnit er at man nemt og bekvemt kan se om testene er forløbet som planlagt. Når AllTest køres får vi følgende output: OK (25 tests) hvilket indikerer at testen er forløbet efter hensigten. 5.2 Samlet test Det samlede system består af en server del samt en klient del. Det skal derfor være mulig igennem klienten, at komme i kontakt med serveren og dennes database via en netværksforbindelse. Klienten skal derfor kunne anvende de metoder servere har til rådighed igennem facaden. Da facaden, og derved også serveren er blevet testet i ovenstående afsnit, og idet en test af brugergrænsefladen er besværlig (andet end at man må antage at hver enkelt komponent i brugergrænsefladen er testet under implementeringen), må en test af det samlede system nødvendigvis være udførelse af en række scenarier der afspejler de use cases der er beskrevet under afsnit 2.2. Dvs. følgende scenarier afprøves fra klientens side af og outputtet fra loggen på serveren udskrives: 1. Opret ny kunde. 2. Rediger eksisterende kunde. 3. Slet eksisterende kunde. 4. Opret ny reservation. 5. Rediger eksisterende reservation. 6. Slet eksisterende reservation. Nedenstående testscenariet er afprøvet på det endelige system. Liniehenvisninger er til bilag B. 1. Først startes serveren, dernæst kobles en klient på. Linie 1-37 viser output fra serverens initialiseringsfase. 2. Der trykkes nu på Ny kunde, hvor følgende indtastes i trin 1: Navn: Eddie Hansen Adresse: Klokkestøbervej 7 Tlf: 43457680 Trin 2 af wizarden bekræfter oprettelsen af kunden, ved at returnerer kundenummeret. I dette tilfælde nummeret 215. Serveren anvender hertil metoderne tilfojkunde() samt findkunder() i serverfacaden. Se linie 39-48. 3. Vi ønsker nu at redigere kundens firma samt e-mail og starter derfor Rediger kunde guiden. I trin 1 finder vi kunden udfra kriterierne: 39
5.2. SAMLET TEST KAPITEL 5. TEST Navn: eddie Systemet returnerer i dette tilfælde 2 kunder, hvor efter vi identificerer den rigtige og trykker på næste. I trin 2 indtaster vi følgender informationer: Firma: Eddie Enterprises E-mail: eddie@ee.com Trin 3 bekræfter opdateringen af kunden. Rediger kunde bruger metoderne findkunder() samt opdaterkunde() fra serverfacaden, se linie 50-61. 4. Vi ønsker nu at oprette en reservation for den netop oprettede kunde og starter derfor Ny reservation guiden. Her søger vi efter en afgang udfra følgende kriterier: Rejsetype: Tur-retur Klasse: 1. klasse Fra: Danmark Til: Afghanistan Afgang: 26.06.03 Ankomst: 02.07.03 Passagerer: 2 I trin 3 finder systemet både for tur samt retur finder systemet 3 afgange. Vi vælger afgangen fra Danmark-Afghanistan kl. 18 samt afgangen fra Afghanistan- Danmark kl. 15. I trin 4 skal vi nu finde kunden og indtaster kriterierne: Navn: eddie Vi finder 2 kunder, og identificerer hurtigt den rigtige. Og trykker på næste. I trin 4 er kundens navn automatisk indsat som passager nr. 1 og indsætter følgende: Passager nr. 2: Charlie I trin 5 får vi en bekræftelse på at der er reserveret to pladser, plads nr. A2 og A1, på de valgte afgange for hhv. Eddie Hansen og Charlie. Ny reservation guiden bruger metoderne findafgange(), findkunder() samt opretreservation(). Serveroutputtet fra disse ses i linie 63-107. 5. Vi ønsker nu at ændre kundens reservationer, og vi vælger derfor Ændre reservation. I trin 1 søger vi efter kunden udfra kriterierne: Navn: eddie Og vi vælger den rigtige kunde. I trin 2 vælger vi afgangen fra Afghanistan- Danmark. I trin 3 ændre vi datoen fra 02.07.03 til 05.07.03. I trin 4 finder systemet 3 afgange på den pågældende dato, og vi vælger afgangen kl. 15. I trin 5 får vi en bekræftelse på ændringen af reservation, samt to nye pladser, hhv. A2 og A1, på afgangen. Klienten bruger i guiden Ændre reservation metoderne findkunder(), findafgange(), opretreservation() samt sletreservation() i serverfacaden. Se linie 109-142. 40
5.3. VURDERING KAPITEL 5. TEST 6. Kunden ønsker nu ikke længere at være kunde i selskabet, og guiden Slet kunde startes. I trin 1 søges efter eddie. Men i trin 2 kommer en dialogboks frem der siger at kunden stadig har reservationer i systemet og at disse skal slettes først. Se linie 144-153. 7. Derfor må vi først slette kundens reservationer vha. Slet reservation. I trin 1 søger vi igen efter eddie, og i trin 2 vælger vi først at slette reservationen Danmark-Afghanistan og i trin 3 får vi en bekræftelse på dette. Vi trykker nu på Tilbage -knappen for at slette reservationen Afghanistan-Danmark. I trin 3 får vi en bekræftelse herpå. Slet reservation bruger metoderne findkunder() samt sletreservation() i serverfacaden, se linie 155-187. 8. Vi har nu endelig mulighed for at slette kunden fra system, og starter guiden Slet kunde. Vi finder igen eddie i trin 1, og i trin 2 får vi en bekræftelse på at kunden er fjernet fra systemet. Slet kunde bruger metoderne findkunder() samt fjernkunde() i serverfacaden, se linie 189-200. Testscenarie gennemgår ikke samtlige mulige kombinationer af funktioner fra brugergrænsefladen, men den gør brug af samtlige metoder tilrådighed for klienten via serverfacaden. Og som bilag B viser, forløber testscenariet korrekt. 5.3 Vurdering Ovenstående afsnit 5.1 og 5.2 viser, at implementeringen af systemet opfylder specifikationerne beskrevet iht. de funktionelle krav samt de supplerende krav i kapitel 2. 41
Kapitel 6 Deployment I dette kapitel vil vi kort nævne hvordan man kan sætte systemet op og betjene det. Systemet er blevet test samt udviklet på Java SDK 1.4.1 1 6.1 Installationsvejledning Den vedlagte CD indeholder et eclipse projekt (BucketAirTest) med kildekode til alle klasser samt JavaDoc (Docs) og testkode (BucketAirTest/tests). Desuden indeholder den en klient samt server distribution i form af to Jar filer som ligger i hvert sit bibliotek med tilhørende filer. Når databasen bliver oprettet opretter vi dermed også nogle data så systemet kan testes. Disse data er nævnt herunder. Opretter 3 afgange pr. dag fra Danmark til alle destinationer i de næste 60 dage. Opretter 3 afgange pr. dag fra alle destinationer til Danmark i de næste 60 dage. Opretter ca. 150-200 kunder i systemet (disser er taget fra de gule siders database). Det skal dog bemærkes at hvis bucket database.data er 60 dage gammel, så vil der ikke kunne oprettes reservationer i systemet. Det er derfor nødvendigt at køre initdatabase.bat filen under server distributionen for at genskabe reservationer 60 dage frem i tiden (dette kan tage noget tid ca.1-2 min på en 1000MHz 128MBram). Serveren kan køres vha. run.bat under server distributionen. Klienten skal først sætte serverens IP adresse i serverip.ini (den står som default til localhost). Klienten kan nu køres, via run.bat filen i klient distributionen, når outputtet fra serveren er up and running slut 6.2 Brugervejledning Brugervejledningen for systemet er at finde online når programmet køres under menupunktet Hjælp - brug evt. F1. 1 http://java.sun.com/j2se/1.4.1/download.html 42
Kapitel 7 Konklusion Vi har i denne rapport beskrevet udviklingen af et projekt, baseret på Unified Process (UP). Projektet har givet os en fornemmelse af fordelene ved en iterativ metode som UP i et udviklingsforløb, hvor man gennemgår nogle overordnede faser; inception, elaboration samt construction. Vi fik i inceptionfasen beskrevet systemets funktionalitet i form af aktører og use cases. Dette giver et overblik over systemet, samt projektets omfang. Ud fra de fundne use cases valgte vi nogle kritiske use cases der skulle danne basis for de funktionelle krav til systemet. I elaborationfasen blev kravene til systemet udbygget med nogle non-funktionelle krav, såsom f.eks. tilgængelighed, performance etc. Endvidere blev en domæne model af systemet opstillet med basis i use case modellen. De samlede krav til systemet samt domæne modellen, ledte til designet af en two-tiered client/server software arkitektur, baseret på design mønstret Remote User Interface. Dette førte til designet af en central database samt application kernel foreliggende på serveren samt en brugergrænseflade liggende på klienterne. I den sidste fase, construction, blev det endelige system implementeret i Java, ved brugen af passende frameworks såsom f.eks. Swing og RMI. I slutningen af fasen, blev det endelige program testet. Testen viste at programmet opfyldte både de funktionelle samt de non-funktionelle krav. Den endelige release af systemet er vedlagt i denne rapport. Projektforløbet har vist UP som en stærk udviklingsmetode, hvor det hurtige design samt implementering af prototype forbedrer forståelsen af projektet som helhed. UP s iterative natur, gør at man hurtigt opdager evt. svagheder eller fejl i designet og derfor får mulighed for at rette disse inden ændringerne bliver for omfattende. Ovenstående gør UP til en effektiv måde at udvikle et projekt på iht. metoder som OOA&D eller vandfald hvor skjulte fejl kan få katastrofale konsekvenser. 43
Kapitel 8 Perspektivering Vores system er åbent for fremtidige udvidelser. I fremtiden kunne man f.eks. udvide systemet med logind/-ud for assistenten. Man kunne også udvide GUI et med et observer pattern således at f.eks. ændringerne i et kunde objekt bliver synlige i brugegrænsefladen hos alle klienter der arbejder med det pågældende kunde objekt. På den måde opnår man den MVC arkitektur vi havde i tankerne. I fremtiden kunne man implementere de resterende use-cases fra fra figur 2.1, således at kunden kan fungere som aktør i systemet via. internettet. 44
Litteratur [1] Rational Unified Process: Best Practices for Software Development Teams. Rev. 11/98 Rational Software. [2] Interaction Patterns In User Interfaces. PLoP2000, Martijn van Welie and Hallvard Trætteberg. [3] Form-Based User Interface - The Architectural Patterns. EuroPLoP 97, Jens Coldewey and Ingolf Krüger. [4] Document-View-Presentaion Pattern. PLoP1999, Ku-Yaw Chang, Lih-Shyang Chen and Chi-Kong Lai. [5] Pattern-Oriented Software Architecture: A System of Patterns. View Handler (pp. 291-304). Wiley, 1996, Frank Buschmann, Regine Meunier and Hans Rohnert. [6] Crossing Chasms - A Pattern Language for Object-RDBMS Integration. Kyle Brown and Bruce G. Whitenack. 45
Bilag A Bucket Airlines Den nyudnævnte direktør for Fyns Kød Eksport A/S Pia Jensen skal på forretningsrejse til USA. Hun har hørt, at Bucket Airlines flyver tit til USA til rimelige priser så derfor ringer til dem for at bestille en flybillet. En assistent besvarer telefonopkaldet og bekræfter, at der findes flere slags billetter til New York på de ønskede datoer. Pia siger, at hun derfor gerne ville bestille en billet. Assistenten spørger, om Pia har rejst med Bucket tidligere. Pia svarer at det har hun desværre ikke, men hun har hørt meget godt om selskabet. Assistenten siger, at han lige skal oprette Pia som en kunde på deres system. Assistenten indtaster navn, adresse, telefonnummer og firmanavn i computeren. Pia Jensen er nu oprettet som kunde hos Bucket Airlines, hvilket betyder, at hendes informationer er lagt ind i systemet. Assistenten får på sin skærm et kundenummer retur, som han giver videre til Pia. Han gør hende opmærksom på, at hun med fordel vil kunne gemme nummeret samt, at hun snart vil få et lille kort, der viser nummeret, med posten. For fremtiden meddeler hun blot sit kundenummer når hun ringer, hvorefter alle hendes data bliver tilgængelige. En af grundene til, at man har valgt at tildele alle rejsende et kundenummer, er blandt andet, at man har en drøm om at implementere et system et par år ude i fremtiden, hvor oplysninger om den enkelte person bliver lagret. Således kan alle oplysninger følger hver enkelt kunde ved senere rejser. Ideen er, at man således f.eks. kan se, om personen skylder penge til flyselskabet, eller om personen har tilgodehavender. Man kan evt. opbygge et bonus system, hvor man optjener point med hver flyvetur, som man så kan bruge til at bestille gratis billetter. Disse tiltag ligger dog et par år ude i fremtiden. I første omgang har man besluttet sig for at implementere en mere simpel struktur, som den er beskrevet i toppen af scenariet. Dette har man valgt at gøre for at sikre flyselskabet et stabilt system fra starten uden fejlkilder. Man skal jo kunne kravle, før man kan gå. Assistenten spørger nu hvad for en flybillet hun kunne tænke sig. Hun har tre typer af flybilletter at vælge imellem. 46
BILAG A. BUCKET AIRLINES Bucket Airlines har taget højde for, at der rejser kunder med forskellige behov og midler. Der er derfor nogle dyre billetter, nogle mindre dyre og nogle billige. De dyre billetter indeholder sæder, hvor man kan lægge sig ned og sove. Desuden får man en gourmet måltid med særligt udvalgte vine. De mindre dyre billetter har store sæder og et stik, der kan bruges til en bærbar computer, men et almindeligt måltid. Desuden må man ændre billetten uden ekstra udgift. De billige billetter han almindelige sæder og kommer med et almindeligt måltid. Man må ikke ændre billetten efter den er bestilt. Pia Jensen vælger en af de mindre dyre billetter, da hun gerne ville arbejde under turen, og hun har ingen planer om at sove og vil heller ikke spilde firmaets penge på et gourmet måltid. Assistenten laver herefter en forespørgsel til systemet efter en mindre dyr billet. Pia skal flyver tilbage en uge efter. Systemet melder tilbage at plads 18A på udturen og 19C på hjemtur passer. Assistent bestiller pladserne og siger til Pia, at hun vil få billetterne med posten 14 dage før udrejsen. Pia Jensen flyver til USA på den aftalte dato. Efter hun har været i USA i 2 dage, får hun besked om, at salg af engelsk oksekød igen er blevet forbudt af EU pga. kogalskab. Det har utrolig stor betydning for Fyns Kød Eksport, fordi engelsk oksekød er deres største konkurrent både i Europa og i USA. Hun bliver derfor nødt til at lave sine rejseplaner om, fordi hun skal tilbage til Danmark så hurtigt som muligt. Hun ringer til Bucket Airlines og forklarer, at hun skal flyver tilbage tidligere end var oprindeligt aftalt. Assistenten, der besvarer telefonopkaldet, er meget forstående. Han går ind i systemet og finder en plads i flyvning til København formiddagen efter. Det passer Pia så assistenten reserverer denne plads og sletter reservationen til den oprindelige hjemtur. Pia Jensen takker mange gange for hjælpen. Da hun flyver hjem er hun meget tilfreds med Bucket Airlines fleksibilitet. Hun er glad for, at det var så nemt at ændre bestillingen. Selv om Bucket Airlines sælger de fleste af deres billetter gennem almindelige rejsebureauer, har selskabet tænkt sig, at det i fremtiden vil sælge billetter fra deres websider. Det skal foregår ved brug af en kundes kundenummer. Desuden er det meningen, at man vil kunne se hvor mange bonuspoint man har optjent fra disse websider. To dage efter sin retur får Pia Jensen en opringning fra en kødgrossist i Frankrig, der tidligere købte alt sit kød fra England. Han vil gerne lave en aftale med Fyns Kød Eksport til at sælge deres kød i Frankrig. Pia bliver derfor nødt til at rejse til Paris med det sammen. Hun rejser sammen med sin finansdirektør Lene Hansen. Lene ringer til Bucket Airlines for at bestille deres billetter. Lene fløj med Bucket 47
BILAG A. BUCKET AIRLINES Airlines for 16 måneder siden, da hun rejste til Italien på ferie. Hun har derfor et kundenummer, som hun oplyser til assistenten der tager telefonen. Assistenten undrer sig over, at det efternavn, som systemet indeholder, ikke stemmer overens med efternavnet, som Lene præsenterede sig med. Assistenten spørger, om der har været ændringer i Lenes data, siden hun sidst fløj med Bucket Airlines. Han kan nemlig se, at Lene er registreret som Lene Larsen. Siden Lenes sidste flyvetur med Bucket Airlines er hun blevet gift med lærer Henrik Hansen. Derfor er det nødvendigt for assistenten at ændre efternavnet til Hansen, og så er alt i orden igen. Derefter bestiller Lene to af de mindre dyre billetter, eftersom de har brug for lidt fleksibilitet. Som allerede nævnt, er ideen med at tildele alle kunder et kundenummer, at det er hurtigere at oprette en reservation, hvis kundens data allerede foreligger. Der er dog også en marketingsrelateret begrundelse for at have en database over flyselskabets kunde. Derfor er det vigtigt, at kundedatabasen altid er opdateret, og at der ikke er kunder registreret, som formentligt aldrig rejser med selskabet igen. Da selskabet er ret nyt, har der endnu ikke været automatiske sletninger af kunder i systemet, men det er fra ledelsens side blevet besluttet, at alle herboende kunder, der ikke har fløjet med selskabet i to år, skal slettes. Desuden vil man slette alle udenlandske kunder, som ikke har fløjet med selskabet i tre år. Således forventer man ved en automatisk sletning ud fra en tidsfaktor at have en rimeligt opdateret kundedatabase. Når Pia og Lene checker ind for deres flyvning til Paris, viser det sig at flyvemaskinen er overbooket. Dvs. at der er blevet solgt flere billetter til turen end der er pladser. Især blandt de billige og mellem dyre pladser kniber det. Derfor bliver flere passagerer opgraderet. De flyver altså i bedre sæder end de har betalt for. Hvem der bliver opgraderet, er afhængig af, hvor tit de enkelte passagerer rejser og hvor meget de har betalt for deres billetter. Da man i tidernes morgen besluttede sig for at starte Bucket Airlines, havde man tænkt meget på, at man ville være unik i sin måde at drive virksomheden på. Det skulle være en oplevelse for kunder at rejse med selskabet, og der skulle være små sjove detaljer, som fik rejsende til at fortælle venner og bekendte om selskabet. Et af de mest anderledes tiltag er uden tvivl et udvidet bonussystem i forhold til det gængse blandt flyselskaber. Ved sin første tur med Bucket Airlines er Pia Jensen blevet oprettet som kunde, og så får hun udleveret et lille plastickort, hvori hendes kundenummer er lagret. Assistenten forklarer Pia, at man kan tjene bonuspoint i Kastrup lufthavn. Dvs. at hver gang man køber noget i Kastrup lufthavn, tjener man bonuspoint, hvis man blot viser plastickortet når man betaler. Disse point kan bruges til at bestille gratis flybilletter. Desuden får man 10 % rabat i toldfri butikker, hvis man viser kortet. Endelig kan man få adgang til en lounge i lufthavn, hvor man kan få en sandwich og en kop kaffe. 48
BILAG A. BUCKET AIRLINES Inden de flyver til Paris køber Pia og Lene en dansk ost som en gave til kødgrossisten i Paris. Bagefter tilbringer de an halv time i Bucket Airlines lounge hvor de slapper lidt af, inden deres fly letter. Så er det ved at være slutningen på året, og man er i de forskellige afdelinger af Bucket Airlines begyndt at se lidt fremad i tiden. Personaleafdelingen laver en oversigt over ansatte og vurderer stabens sammensætning. I salgsafdelingen sidder salgschefen Jane Knudsen, og laver salgsmateriale til næste år. Hun laver to forskellige brochurer. Den ene retter sig imod private kunder, og den anden retter sig imod kunder i erhvervslivet. Jane har været med i udviklingen af Bucket Airlines nye administrationssystem, og hun har hele tiden haft den bagtanke, at systemet skulle være et brugbart værktøj i selskabets markedsføring. Kundedatabasen giver Jane gode muligheder for at lave en differentiering af kunderne. Hun kan søge på mange forskellige variabler for at få en bestemt gruppe til at blive isoleret i systemet. F.eks. kan hun ønske en liste over alle, der er fløjet i den sidste måned, eller måske en liste over alle der er fløjet med de dyre billetter. På denne måde kan systemet være med til at udpege det segment, som man vil rette sin markedsføring imod. Idet salgschefen har et ønske om, at denne salgskampagne både skal rette sig imod private og erhvervs-kunder, så beder Jane systemet om at få en differentieret liste over alle kunder, der henholdsvis er registreret med og uden virksomhedsnavn. Dermed ved hun, hvem der var private kunder, og hvem der var udsendt af et firma. Ved at lave denne differentiering ved hun, hvem der skal have hvilke brochurer. 49
Bilag B Test output Output på serversiden fra testscenariet beskrevet i afsnit 5.2. 1 starter... 2 ServerFacade::ServerFacade() - starting 3 4 [org.apache.ojb.broker.accesslayer.connectionfactorypooledim 5 pl] INFO: Create new connection pool:org.apache.ojb.broker.m 6 etadata.jdbcconnectiondescriptor@9f671b[ 7 jcd-alias=bucket 8 default-connection=true 9 dbms=hsqldb 10 jdbc-level=2.0 11 driver=org.hsqldb.jdbcdriver 12 protocol=jdbc 13 sub-protocol=hsqldb 14 db-alias=bucket_database 15 user=sa 16 password=***** 17 eager-release=false 18 ConnectionPoolDescriptor={whenExhaustedAction=0, maxidle=- 19 1, maxactive=5, maxwait=5000, removeabandoned=false, numtest 20 sperevictionrun=10, testwhileidle=false, minevictableidletim 21 emillis=600000, testonreturn=false, logabandoned=false, remo 22 veabandonedtimeout=300, timebetweenevictionrunsmillis=-1, te 23 stonborrow=true} 24 batchmode=false 25 useautocommit=auto_commit_set_true_and_temporary_false 26 ignoreautocommitexceptions=false 27 sequencedescriptor=org.apache.ojb.broker.metadata.sequence 28 Descriptor@ba9340[ 29 sequencemanagerclass=class org.apache.ojb.broker.util.s 30 equence.sequencemanagerhighlowimpl 31 Properties={grabSize=5} 32 ] 33 ] 34 ServerFacade::ServerFacade() - exiting 35 36 up and running 50
BILAG B. TEST OUTPUT 37 slut 38 39 ServerFacade::tilfojKunde() - starting 40 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 41 Tlf: 43457680 Email: Firma: 42 Done. 43 ServerFacade::tilfojKunde() - exiting 44 45 ServerFacade::findKunder() - starting 46 Kunde: Id: 215 Navn: Adresse: Tlf: Email: Firma: 47 Found: 1 matches. 48 ServerFacade::findKunder() - exiting 49 50 ServerFacade::findKunder() - starting 51 Kunde: Id: Navn: eddie Adresse: Tlf: Email: Firma: 52 Found: 2 matches. 53 ServerFacade::findKunder() - exiting 54 55 ServerFacade::opdaterKunde() - starting 56 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 57 Tlf: 43457680 Email: Firma: 58 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 59 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 60 Done. 61 ServerFacade::opdaterKunde() - exiting 62 63 ServerFacade::findAfgange() - starting 64 Denmark Til: Afghanistan Afgangs dato: Thu Jun 26 00:00:00 C 65 EST 2003 Ankomst dato: 66 Found: 3 matches. 67 ServerFacade::findAfgange() - exiting 68 69 ServerFacade::findAfgange() - starting 70 Afghanistan Til: Denmark Afgangs dato: Wed Jul 02 00:00:00 C 71 EST 2003 Ankomst dato: 72 Found: 3 matches. 73 ServerFacade::findAfgange() - exiting 74 75 ServerFacade::findKunder() - starting 76 Kunde: Id: Navn: eddie Adresse: Tlf: Email: Firma: 77 Found: 2 matches. 78 ServerFacade::findKunder() - exiting 79 80 ServerFacade::opretReservation() - starting 81 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 82 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 83 Afgang: Id: 18231 Afgang fra: Denmark Afgangs dato: Thu Jun 84 26 18:00:00 CEST 2003 Ankomst til: Afghanistan Ankomst dato: 85 Thu Jun 26 21:00:00 CEST 2003 86 Reservation: Id: 1 87 Billet: Id: 1 Rejsende: Eddie HansenPlads: A2 88 Billet: Id: 2 Rejsende: CharliePlads: A1 89 Done. 90 ServerFacade::opretReservation() - exiting 51
BILAG B. TEST OUTPUT 91 92 ServerFacade::opretReservation() - starting 93 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 94 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 95 Afgang: Id: 61847 Afgang fra: Afghanistan Afgangs dato: Wed 96 Jul 02 15:00:00 CEST 2003 Ankomst til: Denmark Ankomst dato: 97 Wed Jul 02 18:00:00 CEST 2003 98 Reservation: Id: 2 99 Billet: Id: 3 Rejsende: Eddie HansenPlads: A2 100 Billet: Id: 4 Rejsende: CharliePlads: A1 101 Done. 102 ServerFacade::opretReservation() - exiting 103 104 ServerFacade::findKunder() - starting 105 Kunde: Id: Navn: eddie Adresse: Tlf: Email: Firma: 106 Found: 2 matches. 107 ServerFacade::findKunder() - exiting 108 109 ServerFacade::findKunder() - starting 110 Kunde: Id: 215 Navn: Adresse: Tlf: Email: Firma: 111 Found: 1 matches. 112 ServerFacade::findKunder() - exiting 113 114 ServerFacade::findAfgange() - starting 115 Afghanistan Til: Denmark Afgangs dato: Sat Jul 05 00:00:00 C 116 EST 2003 Ankomst dato: 117 Found: 3 matches. 118 ServerFacade::findAfgange() - exiting 119 120 ServerFacade::opretReservation() - starting 121 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 122 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 123 Afgang: Id: 63800 Afgang fra: Afghanistan Afgangs dato: Sat 124 Jul 05 15:00:00 CEST 2003 Ankomst til: Denmark Ankomst dato: 125 Sat Jul 05 18:00:00 CEST 2003 126 Reservation: Id: 3 127 Billet: Id: 5 Rejsende: Eddie HansenPlads: A2 128 Billet: Id: 6 Rejsende: CharliePlads: A1 129 Done. 130 ServerFacade::opretReservation() - exiting 131 132 ServerFacade::sletReservation() - starting 133 Reservation: Id: 2 134 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 135 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 136 Afgang: Id: 61847 Afgang fra: Afghanistan Afgangs dato: Wed 137 Jul 02 15:00:00 CEST 2003 Ankomst til: Denmark Ankomst dato: 138 Wed Jul 02 18:00:00 CEST 2003 139 Billet: Id: 3 Rejsende: Eddie Hansen Plads: A2 140 Billet: Id: 4 Rejsende: Charlie Plads: A1 141 Done. 142 ServerFacade::sletReservation() - exiting 143 144 ServerFacade::findKunder() - starting 52
BILAG B. TEST OUTPUT 145 Kunde: Id: Navn: eddie Adresse: Tlf: Email: Firma: 146 Found: 2 matches. 147 ServerFacade::findKunder() - exiting 148 149 ServerFacade::fjernKunde() - starting 150 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 151 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 152 Exception: Kunden har reservationer, de skal slettes først! 153 ServerFacade::fjernKunde() - exiting 154 155 ServerFacade::findKunder() - starting 156 Kunde: Id: Navn: eddie Adresse: Tlf: Email: Firma: 157 Found: 2 matches. 158 ServerFacade::findKunder() - exiting 159 160 ServerFacade::findKunder() - starting 161 Kunde: Id: 215 Navn: Adresse: Tlf: Email: Firma: 162 Found: 1 matches. 163 ServerFacade::findKunder() - exiting 164 165 ServerFacade::sletReservation() - starting 166 Reservation: Id: 1 167 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 168 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 169 Afgang: Id: 18231 Afgang fra: Denmark Afgangs dato: Thu Jun 170 26 18:00:00 CEST 2003 Ankomst til: Afghanistan Ankomst dato: 171 Thu Jun 26 21:00:00 CEST 2003 172 Billet: Id: 1 Rejsende: Eddie Hansen Plads: A2 173 Billet: Id: 2 Rejsende: Charlie Plads: A1 174 Done. 175 ServerFacade::sletReservation() - exiting 176 177 ServerFacade::sletReservation() - starting 178 Reservation: Id: 3 179 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 180 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 181 Afgang: Id: 63800 Afgang fra: Afghanistan Afgangs dato: Sat 182 Jul 05 15:00:00 CEST 2003 Ankomst til: Denmark Ankomst dato: 183 Sat Jul 05 18:00:00 CEST 2003 184 Billet: Id: 5 Rejsende: Eddie Hansen Plads: A2 185 Billet: Id: 6 Rejsende: Charlie Plads: A1 186 Done. 187 ServerFacade::sletReservation() - exiting 188 189 ServerFacade::findKunder() - starting 190 Kunde: Id: Navn: eddie Adresse: Tlf: Email: Firma: 191 Found: 2 matches. 192 ServerFacade::findKunder() - exiting 193 194 ServerFacade::fjernKunde() - starting 195 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 196 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 197 Kunde: Id: 215 Navn: Eddie Hansen Adresse: Klokkestøbervej 7 198 Tlf: 43457680 Email: eddie@ee.com Firma: Eddie Enterprises 53
BILAG B. TEST OUTPUT 199 Done. 200 ServerFacade::fjernKunde() - exiting 201 54