Bucket Airlines. SW02 Projekt. Gruppe 2:

Størrelse: px
Starte visningen fra side:

Download "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) 1 32

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

Assignment #5 Toolbox Contract

Assignment #5 Toolbox Contract Assignment #5 Toolbox Contract Created by: René Kragh Trine Randløv E mail address cph rk70@cphbusiness.dk 23 11 2014 1 Introduktion Dette dokument indeholder en vertikal kontrakt for et system som skal

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

Indholdsfortegnelse for kapitel 2

Indholdsfortegnelse for kapitel 2 Indholdsfortegnelse for kapitel 2 Kapitel 2. Analyse.......................................................... 2 Analyse af 2.1...................................................... 2 Analysen af Database.................................................

Læs mere

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4 Maskine Udlejning 15. oktober 2010 Jacob Weng, Jeppe Boese og Mads Anthony Roskilde Tekniske Gymnasium Udlejningsvirksomhed 3.4 Indholdsfortegnelse Problemformulering:... 2 Planlægning:... 2 Analyse af

Læs mere

Business Online. Business Online - User manual. User Manual Booking. Indholdsfortegnelse

Business Online. Business Online - User manual. User Manual Booking. Indholdsfortegnelse Business Online User Manual Booking Indholdsfortegnelse Login Side 2-3 Hovedside - 4 Bestil rejse (start) - 5 Bestil flyrejse via prisstyret søgning - 6-7 Bestil flyrejse via tidsstyret søgning - 8-12

Læs mere

Rationel VinduesDesigner TM Brugervejledning

Rationel VinduesDesigner TM Brugervejledning Rationel VinduesDesigner TM Brugervejledning indhold: introduktion Side 2 Funktionsliste Side 3 Få adgang til systemet Side 4 opload dine billeder Side 5 Sådan bruges systemet Side 6 Gem dine eksempler

Læs mere

Cyber SPORT Quick Guide

Cyber SPORT Quick Guide Cyber SPORT Quick Guide 2015 Version 1.0 Kom godt i gang Her er en kort introduktion til Cyber, hvor du kan bestille flybilletter, hotelovernatninger samt billeje. 1. Gå på hjemmesiden www.idraettensrejsebureau.dk

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2016 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 29. februar, 2016 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Cyber SPORT Quick Guide

Cyber SPORT Quick Guide Cyber SPORT Quick Guide 2015 Version 1.0 Kom godt i gang Her er en kort introduktion til Cyber, hvor du kan bestille flybilletter, hotelovernatninger samt billeje. 1. Gå på hjemmesiden www.idraettensrejsebureau.dk

Læs mere

Håndbog Til CPR services. Bilag 10 Opsætning af CPR klienten til understøttelse af forskellige installationstyper

Håndbog Til CPR services. Bilag 10 Opsætning af CPR klienten til understøttelse af forskellige installationstyper Håndbog Til CPR services Bilag 10 Opsætning af CPR klienten til understøttelse af forskellige installationstyper CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51

Læs mere

Quick Guide for Mobil Reception (Omhandler mobil reception også kaldet isymphony)

Quick Guide for Mobil Reception (Omhandler mobil reception også kaldet isymphony) Quick Guide for Mobil Reception (Omhandler mobil reception også kaldet isymphony) Generelt Mobil Reception er et værktøj som bruges til at overvåge medarbejdere, kø er og meget andet samt styre dit omstillingsanlæg

Læs mere

www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www

www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www.taxa.nu www Opsætning Indhold: Side 2 Login Side 3 Hovedmenu Administration Side 4 Opret bruger Rediger afdeling

Læs mere

DM531 - Softwarearkitektur Projekt - TaxaTracer, Statisk Kort. Martin Dissing-Hansen 251088 Alexander Poopeiko 090288 Jens Riise Danielsen 100267

DM531 - Softwarearkitektur Projekt - TaxaTracer, Statisk Kort. Martin Dissing-Hansen 251088 Alexander Poopeiko 090288 Jens Riise Danielsen 100267 DM531 - Softwarearkitektur Projekt - TaxaTracer, Statisk Kort Martin Dissing-Hansen 251088 Alexander Poopeiko 090288 Jens Riise Danielsen 100267 December 17, 2009 3.1 Valg at brugsmønster til udvidelse

Læs mere

DATABASE Projekt 1-3. semester

DATABASE Projekt 1-3. semester DATABASE Projekt 1-3. semester Gruppe 2- CLmul-a12e Projekt URL http://www.lucasperch.dk/projekter/database.pdf Gruppe 2 Lucas Perch-Nielsen cph-lp14@cphbusiness.dk http://lucasperch.dk/skole.php Niclas

Læs mere

Samspillet mellem databaser og kort styres af GeoCAD programmet GeoDB.

Samspillet mellem databaser og kort styres af GeoCAD programmet GeoDB. GeoCad modul GeoDB I GeoCAD er det muligt at koble relationsdatabase til GeoEDIT. Her igennem er det muligt at lagre forskellige oplysninger i databasen og koble disse oplysninger til objekter i kortet.

Læs mere

Indledning...3. OnTime Kalenderen...3. Daglig brug af OnTime...4. Oversigter / Views...5. Funktioner...7. Brug af ikoner...12

Indledning...3. OnTime Kalenderen...3. Daglig brug af OnTime...4. Oversigter / Views...5. Funktioner...7. Brug af ikoner...12 Indholdsfortegnelse: Indledning...3 OnTime Kalenderen...3 Daglig brug af OnTime...4 Oversigter / Views...5 Funktioner...7 Brug af ikoner...12 Grafisk visning af tid...13 Side 2 Indledning I større organisationer

Læs mere

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database Kursusbeskrivelse Oprettelse af en Access-database Som eksempel på en Access-database oprettes en simpelt system til administration af kurser. Access-databasen skal indeholde: et instruktørkartotek et

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

Indholdsfortegnelse for kapitel 1

Indholdsfortegnelse for kapitel 1 Indholdsfortegnelse for kapitel 1 Forord.................................................................... 2 Kapitel 1.................................................................. 3 Formål............................................................

Læs mere

ViKoSys. Virksomheds Kontakt System

ViKoSys. Virksomheds Kontakt System ViKoSys Virksomheds Kontakt System 1 Hvad er det? Virksomheds Kontakt System er udviklet som et hjælpeværkstøj til iværksættere og andre virksomheder som gerne vil have et værktøj hvor de kan finde og

Læs mere

Manual til Kundekartotek

Manual til Kundekartotek 2016 Manual til Kundekartotek ShopPlanner Customers Med forklaring og eksempler på hvordan man håndterer kundeoplysninger www.obels.dk 1 Introduktion... 3 1.1 Formål... 3 1.2 Anvendelse... 3 2 Referencer...

Læs mere

Introduktion til OPC Access

Introduktion til OPC Access Introduktion til OPC Access OPC Access anvendes til at kommunikere med jeres produktionsudstyr via OPC. OPC Access kombinerer en SQL Server med OPC, således at jeres produktionsudstyr kobles sammen med

Læs mere

Brugermanual. Outlook Web Access for Exchange Server 2003 (OWA 2003) Udarbejdet af IT-afdelingen 2006

Brugermanual. Outlook Web Access for Exchange Server 2003 (OWA 2003) Udarbejdet af IT-afdelingen 2006 Brugermanual Outlook Web Access for Exchange Server 2003 (OWA 2003) Udarbejdet af IT-afdelingen 2006 Indholdsfortegnelse INDLEDNING... 3 HVORDAN DU FÅR ADGANG TIL DIN EMAIL... 3 OWA 2003 BRUGERGRÆNSEFLADE...

Læs mere

Indholdsfortegnelse for kapitel 3

Indholdsfortegnelse for kapitel 3 Indholdsfortegnelse for kapitel 3 Kapitel 3 Design............................................................ 2 Database........................................................... 3 ER-diagram.................................................

Læs mere

Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE

Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE Fact sheet Indholdsfortegnelse Fact Sheet Gantt kort Valgt af virksomhed Brainstorm Attribut tabel ER-diagram Skitse MySQLWorkbench

Læs mere

Bemærk! Et PHP script har kun brug for at forbinde én gang til databaseserveren. Det kan så sagtens udføre flere kommandoer vha. denne forbindelse.

Bemærk! Et PHP script har kun brug for at forbinde én gang til databaseserveren. Det kan så sagtens udføre flere kommandoer vha. denne forbindelse. Mysqli Webintegrator Når vi arbejder med server-side scripting ( i vort tilfælde PHP), har vi ofte behov for at kunne tilgå data, som vi opbevarer i en database. Det kan f.eks. dreje sig om nyhederne i

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

PBX Online Brugervejledning www.pbxonline.dk

PBX Online Brugervejledning www.pbxonline.dk PBX Online Brugervejledning www.pbxonline.dk Indledning PBX Online er dit personlige omstillingsanlæg som ikke kræver noget fysisk udstyr installeret i dit firma. Du styrer det hele via din web browser.

Læs mere

Smart-ebizz Manual til Bookinsystem Indholdsfortegnelse Kom hurtigt i gang med dit booking system:... 3 Overblikket over dit bookingsystem... 4 Hovedside... 4 Kunder... 4 Opret ny Kunde... 4 Vagtplaner...

Læs mere

Opsætning af MobilePBX med Kalenderdatabase

Opsætning af MobilePBX med Kalenderdatabase Opsætning af MobilePBX med Kalenderdatabase Dette dokument beskriver hvorledes der installeres Symprex Exchange Connector og SQL Server Express for at MobilePBX kan benytte kalenderadadgang via database

Læs mere

FORCE Inspect Online Manual v. 1.02. FORCE Inspect Online Manual. 1 af 18

FORCE Inspect Online Manual v. 1.02. FORCE Inspect Online Manual. 1 af 18 FORCE Inspect Online Manual 1 af 18 Indholdsfortegnelse Indholdsfortegnelse... 2 FORCE Inspect Online Manual... 3 Generelt... 3 Login... 3 Main... 4 Intro sektion... 4 Links sektion... 4 News sektion...

Læs mere

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW - BRUGER-GUIDE -

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW - BRUGER-GUIDE - SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW - BRUGER-GUIDE - INTRODUKTION TIL SKOLERNES DIGITALE BLANKET FLOW Som et udspring af de administrative fællesskaber og et ønske om at effektivisere og digitalisere

Læs mere

Viditronic NDVR Quick Guide. Ver. 2.0

Viditronic NDVR Quick Guide. Ver. 2.0 Viditronic NDVR Quick Guide Ver. 2.0 1 Indholdsfortegnelse 1. HOVEDMENU 3 1.1 START 5 1.2 AKTIVITETSINDIKATOR: 7 1.3 INFORMATIONS VINDUE: 7 1.4 PTZ KAMERA KONTROL: 7 1.5 SKÆRMMENU 8 1.5.1 AKTIVER BEVÆGELSE:

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15.12

Installation og Drift. Aplanner for Windows Systemer Version 8.15.12 Installation og Drift Aplanner for Windows Systemer Version 8.15.12 Aplanner for Windows løsninger Anbefalet driftsopsætning Cloud løsning med database hos PlanAHead Alle brugere, der administrer vagtplaner

Læs mere

Umbraco installationsvejledning

Umbraco installationsvejledning på et ScanNet ASP Webhotel Indledning Beskrivelse Denne vejledning vil indeholde installation af CMS systemet Umbraco på et ASP Webhotel. Det dansk grundlagt Content Management System (CMS) Umbraco er

Læs mere

LEMAN / Præsentation

LEMAN / Præsentation LEMAN / Præsentation Velkommen til LEMAN Internet booking. Vi vil i det følgende gennemgå login, opsætning og indtastnings-muligheder. Systemet findes på http://booking.leman.dk eller via LEMAN s hjemmeside.

Læs mere

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...

Læs mere

Component based software enginering Diku 2005 Kritikopgave

Component based software enginering Diku 2005 Kritikopgave Component based software enginering Diku 2005 Kritikopgave Nicolas Møller Henschel 17. april 2005 1 Indhold 1 Indledning 3 2 Indhold 3 2.1 Introduktionen.......................... 3 2.1.1 Mangler..........................

Læs mere

Katrines Kælder Kasseapparat

Katrines Kælder Kasseapparat Katrines Kælder Kasseapparat Projektdokumentation Aarhus Universitet Gruppe 4-4. Semester - E15 Vejleder: Lars Mortensen Dato 11-09-2015 David Heilesen Danielewicz - 201400148 - IKT Kalle Rønlev Møller

Læs mere

EasyRun En løbers bedste ven

EasyRun En løbers bedste ven En løbers bedsteven Anders Arnfast 06525, Martin Søberg 0655, Ken Falk 06504 09 . INDHOLD. Indhold... 2 2. Introduktion... 3 Opsætning... 3 3. System arkitekturdesign... 4 4. Hardware Design... 5 Ethernet

Læs mere

Daglig brug af JitBesked 2.0

Daglig brug af JitBesked 2.0 Daglig brug af JitBesked 2.0 Indholdsfortegnelse Oprettelse af personer (modtagere)...3 Afsendelse af besked...4 Valg af flere modtagere...5 Valg af flere personer der ligger i rækkefølge...5 Valg af flere

Læs mere

GeckoBooking.dk V. 2.7 - Online kalender og bookingsystem

GeckoBooking.dk V. 2.7 - Online kalender og bookingsystem 1. Login... 2 2. Administrationens opbygning... 2 3. Kalendere... 3 3.1 Ret arbejdstid... 3 3.2 Kalender oversigt... 4 3.2.1 Månedskalender... 5 3.2.2 Uge kalender... 5 3.2.3 Dagskalender... 6 3.2.4. Bookning

Læs mere

Karens lille vejledning til Access

Karens lille vejledning til Access Karens lille vejledning til Access Indhold Hvad er Access? 1 Lave en database 2 Design af tabellen 2 Felttyper 2 Indtastning af data 3 Udtræk fra tabellen 3 Forespørgsel 3 Muligheder med forespørgsel 3

Læs mere

HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE

HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE 1 Tekniske Krav 1.1 Hardware krav: En skærm gerne med touch Hvis skærmen ikke har touch, skal du bruge et tastatur og en mus Webcam Gerne i HD En ekstern lydenhed

Læs mere

Kvikguide. e-bevillingsbrugere. www.onemed.dk

Kvikguide. e-bevillingsbrugere. www.onemed.dk Kvikguide e-bevillingsbrugere Sådan logger du ind som e-bevillingsbruger 1. Klik på Log ind knappen øverst på skærmen. 2. Indtast Brugernavn og Adgangskode som beskrevet. Som indlogget e- bevillingsbruger

Læs mere

Specialiseringen Rapport Lavede Af Rasmus R. Sørensen Side 1 af 6

Specialiseringen Rapport Lavede Af Rasmus R. Sørensen Side 1 af 6 Side 1 af 6 Indholdsfortegnelse INDHOLDSFORTEGNELSE 1 INTRO 3 STARTEN AF SPECIALISERINGEN 3 ANKOMST TIL SKOTLAND 4 DATABASER 5 NETVÆRK 5 INTERAKTION 5 AFSLUTNING AF SPECIALISERINGEN 5 KONKLUSION 6 Side

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Vejledning i brug af Foreningsportalen til brugere med adgangskode

Vejledning i brug af Foreningsportalen til brugere med adgangskode Holstebro Kommune Kultur og Fritid Vejledning i brug af Foreningsportalen til brugere med adgangskode Foreningsportalen kan benyttes både af borgere og foreninger til søgning af foreningsoplysninger og

Læs mere

Brugermanual SuperSail (DS Version) Performance System Release 2.0

Brugermanual SuperSail (DS Version) Performance System Release 2.0 Brugermanual SuperSail (DS Version) Performance System Release 2.0 Side 1 af 14 Indholdsfortegnelse 1 LOGIN MENU... 3 2 HOVED MENU... 4 3 TRACKER INFO MENU... 5 4 KAPSEJLADS MENU... 6 4.1 TILMELD KAPSEJLADS

Læs mere

Database "opbygning"

Database opbygning Database "opbygning" Dette områder falder mest under en DBA's ansvarsområde. Det kan sagtens tænkes at en database udvikler i nogle situationer vil blive nød til at oprette produktions og test) databaser,

Læs mere

Call Recorder Apresa Brugermanual

Call Recorder Apresa Brugermanual Call Recorder Apresa Brugermanual Version. 1.100.11 Vidicode Pleje og vedligeholdelse: CR Apresa må ikke blive våd. Hvis den bliver våd, tør den omgående af med en blød, ren klud. Væsker kan indeholde

Læs mere

Projekt database. http://bysileha.com/3.semester/database-eshop/index.html (vores htmlside)

Projekt database. http://bysileha.com/3.semester/database-eshop/index.html (vores htmlside) Projekt database http://bysileha.com/3.semester/database-eshop/index.html (vores htmlside) Amanda Lindschouw - cph-al144@cphbusiness.dk http://ahldesign.dk/learningthird.html Charlotte Øberg - cph-co74@cphbusiness.dk

Læs mere

GUIDE TIL CLOUD DRIVE

GUIDE TIL CLOUD DRIVE GUIDE TIL CLOUD DRIVE Dette er en guide du kan anvende til nemt at komme effektivt i gang med at anvende Cloud Drive Indholdsfortegnelse 1. Tilgængelige Cloud Drive klienter 2. Guide til Windows klienten

Læs mere

elib Aleph, ver.18 Introduktion til GUI FUJITSU SERVICES A/S

elib Aleph, ver.18 Introduktion til GUI FUJITSU SERVICES A/S Introduktion til GUI FUJITSU SERVICES A/S, 2008 Indholdsfortegnelse 1. Skrivebordet... 3 2. Flytte rundt m.m.... 4 3. Log ind... 6 4. Valg af database... 7 5. Rudernes størrelse... 8 6. Kolonner... 9 7.

Læs mere

Fjernadgang til BEC s systemer via Portal2

Fjernadgang til BEC s systemer via Portal2 Fjernadgang til BEC s systemer via Portal2 - tilgå applikationer og arbejdsplads via webbaseret portal (UAG) Udarbejdet af: Niklas Petersen Gældende fra: 24-08-2015 Version Forfatter Dato Dokumentstatus

Læs mere

OpenTele Server Performance Test Rapport

OpenTele Server Performance Test Rapport OpenTele Server Performance Test Rapport 17. marts 2015 Side 1 af 22 1Indholdsfortegnelse Indholdsfortegnelse Indledning Test forudsætning Beskrivelse af testscenarier Test af OpenTele kliniker web interface

Læs mere

Continia Collection Management Kom hurtigt i gang med CLC version 1.3

Continia Collection Management Kom hurtigt i gang med CLC version 1.3 Continia Collection Management Kom hurtigt i gang med CLC version 1.3 1 Baggrundshistorie for skift af CLC version fra 1.2 til 1.3 Med Collection Management version 1.15 medfølger også en ny version af

Læs mere

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails Casper Fabricius http://casperfabricius.com ActiveRecord O/RM i Ruby on Rails Casper Fabricius Freelance webudvikler - casperfabricius.com 9 års erfaring med webudvikling 6 år med ASP/ASP.NET/C# 3 år med

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15

Installation og Drift. Aplanner for Windows Systemer Version 8.15 Installation og Drift Aplanner for Windows Systemer Version 8.15 Aplanner for Windows løsninger Tekniske forudsætninger Krav vedr. SQL Server SQL Server: SQL Server 2008 Express, SQL Server 2008 R2 eller

Læs mere

Hjælp til MV-ID Administration

Hjælp til MV-ID Administration Hjælp til MV-ID Administration - til brugere af MV-Login Mikro Værkstedet A/S Dokumentversion: 20131002A 1 Indholdsfortegnelse Forord... 3 Kapitel 1. Aktivér MV-Login administratorkontoen... 4 Kapitel

Læs mere

Database. Pr jekt. Hold CLmul-a14e Gruppe 3 3. semester 2015. Vejledere: Tue Becher Ivan R. Frederiksen

Database. Pr jekt. Hold CLmul-a14e Gruppe 3 3. semester 2015. Vejledere: Tue Becher Ivan R. Frederiksen Database Pr jekt Hold CLmul-a14e Gruppe 3 3. semester 2015 Vejledere: Tue Becher Ivan R. Frederiksen Indholdsfortegnelse 1. Problemformulering 2. ER-diagram 3. Attribut-tabel 4. Use Case-model 5. Use Case

Læs mere

EVALUERING I SURVEYXACT TRIN FOR TRIN

EVALUERING I SURVEYXACT TRIN FOR TRIN EVALUERING I SURVEYXACT TRIN FOR TRIN LÆR AT TACKLE 2015 KOMITEEN FOR SUNDHEDSOPLYSNING 1 INDLEDNING Komiteen for Sundhedsoplysning stiller SurveyXact et internetbaseret redskab til kvalitetssikring til

Læs mere

Rev. 05-10. Brugervejledning. Webshop Sika Danmark A/S

Rev. 05-10. Brugervejledning. Webshop Sika Danmark A/S Rev. 05-10 Brugervejledning Webshop Sika Danmark A/S Indholdsfortegnelse Afsnit Emne Side 1. Indledning 2 2. Quickguide forklaring af menu 3 2.1 Menu til venstre 3 2.2 Topmenu 3 3. Log-in 5 4. Bestilling

Læs mere

EVALUERING I SURVEYXACT TRIN FOR TRIN

EVALUERING I SURVEYXACT TRIN FOR TRIN EVALUERING I SURVEYXACT TRIN FOR TRIN LÆR AT TACKLE 2015 KOMITEEN FOR SUNDHEDSOPLYSNING 1 INDLEDNING Komiteen for Sundhedsoplysning stiller SurveyXact et internetbaseret redskab til kvalitetssikring til

Læs mere

Brugervejledning for. Telenor Dialer

Brugervejledning for. Telenor Dialer Brugervejledning for Telenor Dialer 1 Indholdsfortegnelse Generelt om Telenor Dialer.... 5 Telenor Dialer og OneNumber.... 6 Telenor Dialer og OneNumber Mobile.... 6 Faciliteter i Telenor Dialer...7 Installation

Læs mere

En Kort Introduktion til Oracle

En Kort Introduktion til Oracle En Kort Introduktion til Oracle Henrik Bulskov 12. februar 2001 bulskov@ruc.dk 1 Start SQL*Plus... 1 1.1 TELNET... 1 1.2 WINDOWS SQL PLUS... 2 2 Kør et SQL-script... 3 3 Hjælp i SQL*Plus... 3 4 Editering

Læs mere

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 -

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 - - 1 - Indholdsfortegnelse Hvorfor skal jeg tage backup af min blog? Side 3 Tag backup med UpDraft Side 4 Tag manuelt backup Side 8-2 - Hvorfor skal jeg tage backup af min blog? Lige meget om du har opbygget

Læs mere

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav. Miniprojekt2011 Projektbeskrivelse Der skal fremstilles en lille java application på PC, hvor brugeren kan foretage interaktioner med en simpel database på disken via et grafisk brugerinterface. Formålet

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

e-conomic modul til Magento

e-conomic modul til Magento Opsætningsguide til e-conomic modul til Magento Version 4.0.6 Magentomoduler ApS Myggenæsgade 3, 4. Lejl. 4 København kontakt@magentomoduler.dk Opsætning Opsætning af modulet kræver at du har adgang til

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

Prøveeksempler 2012. ClinicCare. Web

Prøveeksempler 2012. ClinicCare. Web ClinicCare Web Prøveeksempler 2012 Hvem er ClinicCare? ClinicCare udvikles af firmaet Novolog, som siden 1995 har udviklet systemer til sundhedssektoren. Over 900 klinikker anvender idag ClinicCare. Det

Læs mere

vejman.dk Brugerdokumentation - kortmodul 14. marts 2012 Version 1.9

vejman.dk Brugerdokumentation - kortmodul 14. marts 2012 Version 1.9 Brugerdokumentation - kortmodul 14. marts 2012 Version 1.9 Indholdsfortegnelse 1 Indledning... 3 1.1 Anbefalinger... 4 1.2 Datahjælp... 4 1.3 Brugerindstillinger... 5 2 Generel funktionalitet... 6 2.1

Læs mere

Ved at klikke på ADMIN i øverste menu linje går man ind i butiks administrations delen.

Ved at klikke på ADMIN i øverste menu linje går man ind i butiks administrations delen. Vejledning i www.tempobooking.dk s butiksadministration. Efter butiks LOGIN vises dagsoversigten: Ved at klikke på ADMIN i øverste menu linje går man ind i butiks administrations delen. Butiksadministrationen

Læs mere

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation

Secure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Testspecifikation Udgave 1 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Testspecifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC Testspecifikation

Læs mere

E-mail. Outlook. Outlook.com

E-mail. Outlook. Outlook.com E-mail Outlook Outlook.com Indhold e-mail elektronisk post... 3 e-mail adresse... 3 Opstart af Microsoft Outlook.com... 4 Skærmbilledet i Outlook... 5 Arbejd med e-mail... 6 Sende e-mail... 7 Modtage og

Læs mere

Inden du kan tage systemet i brug og sende spørgeskemaer, kortlægge arbejdsmiljøet, lave handlingsplaner mv. skal systemet sættes op.

Inden du kan tage systemet i brug og sende spørgeskemaer, kortlægge arbejdsmiljøet, lave handlingsplaner mv. skal systemet sættes op. Indledning Workcyclus er et Internetbaseret arbejdsmiljøsystem, der giver fuldt overblik over virksomhedens arbejdsmiljøtilstand og gør arbejdsmiljøet målbart og synligt på alle niveauer i organisationen.

Læs mere

Administrator manual

Administrator manual Revision 1 Administrator manual INDHOLD LOG IND 1 OVERBLIK 1 ARBEJDSRUM 1 MEDARBEJDERE 2 OPRET NY MEDARBEJDER 2 TRIN 1 AF 4: NAVN OG OPLYSNINGER 2 TRIN 2 AF 4: LEGITIMATION 2 TRIN 3 AF 4: EFFEKTIVITETSNIVEAU

Læs mere

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER -

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER - SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER - INTRODUKTION TIL SKOLERNES DIGITALE BLANKET FLOW Vi er glade for at kunne byde velkommen til opdateret

Læs mere

Kom godt i gang med DLBR Webdyr

Kom godt i gang med DLBR Webdyr Kom godt i gang med DLBR Webdyr Kom godt i gang med DLBR Webdyr Udgivet Februar 2011 Redaktør Tryk Videncentret for Landbrug Videncentret for Landbrug Udgiver Videncentret for Landbrug, KvægIT, 8740 5000

Læs mere

ITONK1 Obligatorisk opgave 2 Badger Brewery Surveillance System

ITONK1 Obligatorisk opgave 2 Badger Brewery Surveillance System Ingeniørhøjskolen i Århus 2. juni 2006 IKT Dalgas Avenue 2 8000 Århus C ITONK1 Obligatorisk opgave 2 Badger Brewery Surveillance System Studerende: Henrik Brix Andersen, 01079 Tomas Stæhr Berg, 03539 Benjamin

Læs mere

Vejledning til Kilometer Registrering

Vejledning til Kilometer Registrering Vejledning til Kilometer Registrering iphone Appen som holder styr på dit firma og privat kørsel. Udviklet af Trisect Development 2011. www.trisect.dk For iphone version 4.2 og nyere. Med Kilometer Registrering

Læs mere

Brugermanual. Tripple Track Fleet

Brugermanual. Tripple Track Fleet Brugermanual Tripple Track Fleet Version 3.15 Side 1 af 19 Indholdsfortegnelse Installation:... 3 Login:... 3 Se alle biler:... 4 Status skift:... 5 Historie:... 7 Punkt information:... 9 Find adresse:...

Læs mere

Kom godt igang med Inventar registrering

Kom godt igang med Inventar registrering Kom godt igang med Inventar registrering (InventoryDB) (Med stregkodesupport) programmet fra PetriSoft Introduktion... 1 Inventar registrering... 2 Værktøjsudleje... 3 Service database til reperationer

Læs mere

Digital skriftlig aflevering med Lectio Censormodul Stedprøver installationsvejledning

Digital skriftlig aflevering med Lectio Censormodul Stedprøver installationsvejledning Digital skriftlig aflevering med Lectio Censormodul Stedprøver installationsvejledning 1. Lokalt installeret afleveringsprogram til stedprøver... 2 2. Systemkrav... 3 3. Netværksopsætning... 4 4. Installation

Læs mere

Object-Relational Mapping

Object-Relational Mapping Databaser for udviklere () Datamatiker TietgenSkolen Underviser: Allan Helboe 06-06-2010 Problemformulering Denne opgave er et forsøg på at beskrive problemerne der opstår ved anvendelsen af en relationel

Læs mere

POST IT! Cph Business Academy Multimediedesign 2. Semester flow april Kirstine Marie Rasmussen cph-

POST IT! Cph Business Academy Multimediedesign 2. Semester flow april Kirstine Marie Rasmussen cph- POST IT! Cph Business Academy Multimediedesign 2. Semester flow 3 9. april 2017 Kirstine Marie Rasmussen cph- kr141@cphbusiness.dk Mette Bejder cph- mb458@cphbusiness.dk Link til POST IT http://mbejder.dk/post-

Læs mere

Vejledning KPK Online Prøverum

Vejledning KPK Online Prøverum Vejledning KPK Online Prøverum INDHOLD Introduktion side 2 Funktionsliste side 2 Få adgang til systemet side 3 Opload dine billeder side 4 Sådan bruges systemet side 5 Gem dine eksempler side 7 Side 1/7

Læs mere

Sikre Beregninger. Kryptologi ved Datalogisk Institut, Aarhus Universitet

Sikre Beregninger. Kryptologi ved Datalogisk Institut, Aarhus Universitet Sikre Beregninger Kryptologi ved Datalogisk Institut, Aarhus Universitet 1 Introduktion I denne note skal vi kigge på hvordan man kan regne på data med maksimal sikkerhed, dvs. uden at kigge på de tal

Læs mere

Systemair Connect. Opsætning

Systemair Connect. Opsætning Systemair Connect Opsætning Opsætning af Systemair Connect Denne vejledning er lavet for at hjælpe dig i gang med opsætningen af Systemair Connect. Du kan bl.a. læse om, hvordan du opbygger en understruktur

Læs mere

MSI pakke til distribution af AutoPilot komponenter.

MSI pakke til distribution af AutoPilot komponenter. MSI pakke til distribution af AutoPilot komponenter. Hermed følger en basal dokumentation for installation af AutoPilot msi pakken. Der vil i det følgende blive forklaret brugen af 4 programmer fra Microsoft,

Læs mere

Vejledning i brug af Interbook (Frederiksberg) til brugere med adgangskode

Vejledning i brug af Interbook (Frederiksberg) til brugere med adgangskode Vejledning i brug af Interbook (Frederiksberg) til brugere med adgangskode Udarbejdet af Kultur & Fritid, februar 2010. - 1 - Hvad er Interbook?...- 3 - Brugernavn og kodeord...- 3 - Startsiden...- 3 -

Læs mere

SmartWeb Brugermanual

SmartWeb Brugermanual SmartWeb Brugermanual Table of Content Table of Content... 1 Best Practice SmartWeb:... 2 Implementering... 4 Egenskaber:... 5 Filer:... 7 Oprettelse af Kategori... 9 Sider og Tekster:... 11 Slideshow...

Læs mere

Kursusgang 11. Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing

Kursusgang 11. Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing Kursusgang 11 Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing Design af brugerflader 11.1 Samme sted Forskellige steder Sidste kursusgang Samtidigt

Læs mere

Rapport generator til Microsoft C5

Rapport generator til Microsoft C5 Generelt Rapportgeneratoren til C5 kan benyttes sammen med alle versioner af C5 og kræver INGEN tillægsmoduler eller tilkøb af C5. Den kører på: C5 version 1.5x, 1.6x, 2.x, 3.x, 4.x, 2008, 2010 og 2012.

Læs mere

Skriftlig opgave. Designtanker i database-nære systemer

Skriftlig opgave. Designtanker i database-nære systemer Skriftlig opgave til eksamen for faget»databaser«designtanker i database-nære systemer Martin Ancher Holm Juni 2010 1 Intro Denne skriftlige opgave indeholder kort de daglige tanker jeg har omkring design

Læs mere

Brugermanual SuperSail (DS Version) Performance System Release 1.0

Brugermanual SuperSail (DS Version) Performance System Release 1.0 Brugermanual SuperSail (DS Version) Performance System Release 1.0 Dokument: SuperSail DS Users Manual 1.0.docx Dato: 09. December - 2013 Revision: 1.0 Antal sider: 19 Side 1 af 19 Indholdsfortegnelse

Læs mere

Tlf. +45 7027 1699 Fax + 45 7027 1899

Tlf. +45 7027 1699 Fax + 45 7027 1899 Firmaordninger I firmaoversigten kan du holde styr på dit kundekartotek samt disses bookinger. Der kan desuden oprettes andre firmaer end dit eget. Herved kan der udbydes særlige ydelser på med egne arbejdstider.

Læs mere

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539)

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 Afsluttende projekt PhotoDays Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 - AFSLUTTENDE PROJEKT PhotoDays Benjamin Sørensen & Tomas Stæhr Berg 02284 & 03539 1 1 Underskrifter Rapporten

Læs mere