Bucket Airlines. SW02 Projekt. Gruppe 2:

Transkript

1 Bucket Airlines SW02 Projekt Gruppe 2: Alireza Derakhshan Frodi Hammer Lars Sønderby Jessen Michael Vestergaard Jessen maj 2003

2 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

3 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 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

4 Indhold Indledning 6 1 Faser i Unified Process Inception Elaboration Construction Transition Requirements Aktører Use Cases Non-functional requirements Tilgængelighed Sikkerhed Performance Fejl tolerance Scalability Analyse & Design Domæne model Arkitektur Klient Server Detailed Design Database Database Access Application Kernel Klient/Server Brugergrænseflade Implementation Database Opsætning af database Database Access OJB PersistenceBroker Application Kernel Klient/Server Brugergrænsefladen

5 INDHOLD INDHOLD 5 Test Komponent test Samlet test Vurdering Deployment Installationsvejledning Brugervejledning Konklusion 43 8 Perspektivering 44 A Bucket Airlines 46 B Test output 50 5

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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, 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

14 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: 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 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 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 Fejl tolerance Systemet skal kunne gendannes efter en evt. strømafbrydelse/genstart 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

15 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

16 3.2. ARKITEKTUR KAPITEL 3. ANALYSE & DESIGN Personer Kunde Assistent -login -kunde.nr -firma -navn -adresse -tlf - +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

17 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 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

18 3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN 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 Database Som persistens lag har vi valgt at benytte en relationel database. Kunde -navn -firma -tlf - -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

19 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 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

20 3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN 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 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

21 3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN 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 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

22 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, 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, 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

23 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, 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

24 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

25 3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN 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

26 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

27 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

28 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

29 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 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 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 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 Oversigt Indeholdet af oversigtvinduet kan variere alt efter hvor dette anvendes. Se figur

30 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

31 3.3. DETAILED DESIGN KAPITEL 3. ANALYSE & DESIGN Bucket Airlines - Reservations oversigt Kunde nr.: Navn: Adresse: Telefon nr.: Firma: 4578 John Doe Hole Olstrup Doe, Inc. Informationer om kunden Fly 54 Dato Tidspunkt Fra Til 1/ :00-15:02 Odense Svendborg Liste over kundens reservationer. Annuller OK Figur 3.13: Design af Vælge reservation -dialogen. 31

32 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)

33 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 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 afgange fordelt over en periode på 60 dage startende fra 29/5/2003. Hver afgang indeholder 9 pladser (ialt ca 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 OJB PersistenceBroker OJB PersistenceBrokeren indeholder bl.a. følgende metoder til håndtering af persistens: store() delete() begintransaction() aborttransaction() getobjectbyquery() getcollectionbyquery() committransaction()

34 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 N relationer er implementeret vha. LinkedList fra JAVA Collection frameworket. Iforhold til vores design i afsnit 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