BOKNINGSSYSTEM FÖR TURISTFÖRETAG

Examensarbete 20 poäng D-nivå BOKNINGSSYSTEM FÖR TURISTFÖRETAG Reg.kod: Oru-Te-EXA089-D109/05 Klas Svedberg och Jon Sandfors Dataingejörsprogrammet 160 p Örebro vårterminen 2005 Handledare: Håkan Lindegren Examinator: Lars Karlsson BOOKING SYSTEM FOR TOURIST COMPANY Örebro universitet Örebro University Institutionen för teknik Department of technology 701 82 Örebro SE-701 82 Örebro, Sweden

Bokningssystem för turistföretag 1 (34) Sammanfattning Denna rapport beskriver utvecklingen av ett system, bestående av ett bokningssystem samt en hemsida som är sammankopplade med varandra. Systemet är framtaget åt ett turistföretag i Stensele, Valle&Anders AB. Företaget, som har två chaufförer anställda, marknadsför och säljer bussresor. Systemet syftar till att förenkla och effektivisera hanteringen av kunder, bokningar och administration. Systemet är uppdelat i två delar. Den ena delen är en hemsida där företaget presenterar sina aktuella resor samt kontaktuppgifter. Den andra delen är ett bokningssystem som består av en applikation. I applikationen kan kunder registreras och resebokningar göras och offerter och fakturor kan skrivas ut. Bokningssystemet är byggt i form av en klient/serverfunktion vilket möjliggör att chaufförerna lätt kan komma åt applikationen även när de är på resande fot. I dagens läge är systemet klart med undantag för test och felrättning. Abstract This report describes the development of a system, containing a booking system and a homepage that are connected to each other. The system is made for a tourist company in Stensele, Valle&Anders AB. The company, that has two chauffeurs employed, markets and sells bus tours. The purpose of the system is to simplify and make it more effective to handle customers, bookings and the administration. The system is divided into two parts. The first part is a homepage where the company can present current trips and contact information. The second part is a booking system that consists of an application. In the application customers can be registered and bookings can be made, offers and invoices can also be printed to customers. The booking system is built in the form of a client-server function that makes it easy for the chauffeurs to connect to the application even when they are out traveling. Today, the system is finished, except for testing and error correction.

Bokningssystem för turistföretag 2 (34) Förord Vi skulle vilja tacka följande personer: Håkan Lindegren som hjälpt oss med rapporten och svarat på frågor Lars Karlsson vår examinator Jack Pencz som tillhandahöll två datorer Anders Johansson och Valentin Eriksson som gav oss möjligheten att göra detta arbete Pia Kristiansson som introducerade oss för Valle&Anders AB ÖREBRO DEN 8 JUNI 2005 Klas Svedberg Jon Sandfors

Bokningssystem för turistföretag 3 (34) Innehållsförteckning 1 INLEDNING... 6 1.1 BAKGRUND... 6 1.2 UPPDRAGSBESKRIVNING... 6 1.2.1 Applikation... 6 1.2.2 Hemsida... 6 1.3 FÖRUTSÄTTNINGAR... 6 2 METOD... 7 2.1 ARBETSGÅNG... 7 2.2 TRESKIKTSMODELL... 7 2.3 SYSTEMÖVERSIKT... 8 3 PROGRAMMERINGSVERKTYG... 9 3.1 BORLAND C++ BUILDER 5.0... 9 3.2 MYSQL SERVER 4.1... 9 3.3 MICROSOFT ACCESS 2000... 9 3.4 NSIS 2.06... 9 3.5 HM NIS EDIT 2.0.3... 10 3.6 MICROSOFT NOTEPAD 5.1... 10 4 GENOMFÖRANDE... 11 4.1 UTREDNING AV KRAV... 11 4.2 DESIGN AV APPLIKATION OCH HEMSIDA... 11 4.2.1 Design för användarvänlighet... 12 4.3 DESIGN AV DATABASER... 13 4.4 IMPLEMENTATION AV KLASSER, HEMSIDA OCH SQL-FRÅGOR... 13 4.5 TEST OCH FELRÄTTNING... 14 4.6 KUNDREGISTER... 14 4.7 FORDON... 14 4.8 KALENDER... 14 4.9 RESOR... 15 4.10 SKRIVA UT FAKTUROR OCH OFFERTER... 15 4.11 ÖVRIGT... 15 4.11.1 Hemsidor... 16 4.11.2 Nedladdning av hemsidor... 16

Bokningssystem för turistföretag 4 (34) 4.11.3 Backup av hemsidor... 16 4.11.4 Backup av databasen... 16 4.11.5 Kryptering... 16 4.11.6 Fordonskomponent... 17 4.11.7 Loginfönster... 19 4.12 HEMSIDAN... 19 4.13 DATABASER... 20 4.13.1 Applikationens databas... 20 4.13.2 Hemsidans databas... 20 4.14 UTVECKLINGSDATA... 20 4.14.1 Dokument... 21 4.14.2 Hemsidan... 21 4.14.3 Installationsfiler... 21 4.14.4 Källkod... 21 5 RESULTAT... 23 5.1 UTREDNING AV KRAV... 23 5.1.1 Design för användarvänlighet... 23 5.1.2 Installation av systemet... 24 5.2 IMPLEMENTATION AV KLASSER, HEMSIDA OCH SQL-FRÅGOR... 25 5.3 KUNDREGISTER... 26 5.4 FORDON... 27 5.5 SKRIVA UT FAKTUROR OCH OFFERTER... 27 5.5.1 Offert... 27 5.5.2 Faktura... 28 5.6 ÖVRIGT... 28 5.6.1 Kryptering... 28 5.6.2 Login-fönster... 28 5.6.3 Låsningen av tangentkombinationer... 29 5.7 UTVECKLINGSDATA... 29 6 DISKUSSION... 30 6.1 APPLIKATION OCH HEMSIDA... 30 6.2 FÖRBÄTTRINGAR OCH FRAMTIDA UTVECKLING... 32 6.3 VAD VI KUNDE GJORT BÄTTRE... 32 7 REFERENSER... 33 8 TERMINOLOGI... 34

Bokningssystem för turistföretag 5 (34) Appendix APPENDIX A FORMULÄR APPENDIX B KOPPLING MOT MYSQL APPENDIX C KOPPLING MOT MICROSOFT ACCES PÅ INTERNET APPENDIX D TABELLERNA I MYSQL-DATABASEN APPENDIX E TABELLEN I MICROSOFT ACCESS-DATABASEN APPENDIX F KOD FÖR TANGENTBORDSLÅSNING APPENDIX G KRYPTERINGSALGORITMEN APPENDIX H UTVECKLA BORLAND-KOMPONENT

Bokningssystem för turistföretag 6 (34) 1 Inledning 1.1 Bakgrund Valle&Anders AB är ett nystartat turistföretag i Stensele. Det drivs av två chaufförer med många års erfarenhet från flera olika företag inom åkeribranschen. Då det är ett nystartat företag behöver det göra reklam för sina tjänster på Internet, genom en egen hemsida. För att registrera bokningar behöver de även en applikation. Applikationen ska, förutom att behandla bokningar, registrera information om företagets fordon, kostnader m m. De vill även enkelt kunna skriva ut offerter och fakturor. 1.2 Uppdragsbeskrivning 1.2.1 Applikation Applikationen ska vara byggd som klient/server, där servern ska tillhandahålla en databas. En databas med kundregister ska ligga till grund för programmet så att företaget lätt kan få tag i återkommande kunder. Fordonen ska också finnas i databasen, där även deras kostnadsuppgifter ska finnas, då företaget vill kunna kontrollera om fordon är lönsamma eller ej. Varje fordon ska kopplas till en kalenderfunktion. Genom detta vet chaufförerna om respektive fordon är ledigt/upptaget. Nya resor ska kunna läggas till och även kunna kopplas ihop med ett visst fordon. Med hjälp av kundregistret och de bokade resorna ska man på ett automatiserat sätt kunna skapa fakturor. Valle&Anders AB får ofta förfrågningar om offerter från föreningar och skolor. Även detta ska gå att skriva ut genom att fylla i uppgifter om diverse kostnader. 1.2.2 Hemsida Hemsidan ska byggas upp utifrån en databas där företaget kan lägga till aktuella resor och ta bort inaktuella resor för att på ett enkelt sätt hålla den uppdaterad. Eftersom företaget är utsatt för konkurrens behövs en slagkraftig hemsida för att utmärka sig i branschen och locka till sig kunder. Sidan måste vara användarvänlig både för företaget och för besökare. 1.3 Förutsättningar Företaget har i dag en dator i sin verksamhet, men de har planer på att expandera och anställa minst en person till som kommer att sitta vid ytterligare en dator. Eftersom chaufförerna ofta är på resande fot är en klient/serverfunktion lämplig för att chaufförerna lätt ska kunna komma åt databasen från vilken dator som helst som har klienten installerad. Eftersom företagets anställda saknar god datorvana måste programmet och uppdateringen av hemsidan vara användarvänlig.

Bokningssystem för turistföretag 7 (34) 2 Metod 2.1 Arbetsgång Vi har använt oss av följande arbetsgång: Utredning av krav Design av applikation och hemsida Design av databaser Implementation av klasser, hemsida och SQL-frågor Test och felrättning För att ha något att arbeta emot så skapade vi först ett GUI (Graphical User Interface) att programmera mot. Efter att ha designat GUI:t för applikationen gick arbetet med att skapa databasen lättare. Under tiden projektet fortgick kom bättre och enklare lösningar fram och designen byggdes delvis om. Vid skapandet av hemsidan använde vi oss av samma arbetsgång. Först skapade vi ett skal som sedan en databas kopplades mot. 2.2 Treskiktsmodell För att få en bra uppdelning av kodningen hade vi som avsikt att använda treskiktmodellen, se Figur 2.1. P g a dålig planering användes dock inte treskiktsmodellen. Presentationsskikt Logikskikt Databasskikt Databaser Figur 2.1 Treskiktsmodellen. Presentationsskiktet: På översta nivån finns presentationsskiktet, det skikt användaren styr och ser. Presentationsskiktet tillhandahåller en brygga till det mellanliggande logikskiktet.

Bokningssystem för turistföretag 8 (34) Logikskiktet: Mellanskiktet innehåller funktioner och logik och sköter kopplingen mellan databasskiktet och presentationsskiktet. Funktionerna och logiken bearbetar och hanterar data, från de olika skikten, som sedan återges i presentationsskiktet. Databasskiktet: På den nedersta nivån sköts all kommunikation med databasen. Databasskiktet sköter kopplingen mellan databaserna och presentationsskiktet och sköter all in- och utmatning till och från databasen. För mer information om treskiktmodellen, se [1]. 2.3 Systemöversikt Systemet består av tre delar: applikationen, hemsidan och databasservern, se Figur 2.2. Applikationen är den centrala delen i systemet. Applikationen är kopplad till hemsidan och dess Access-databas. Kopplingen sker med FTP. Hemsidan använder Access-databasen för att visa aktuella resor som är skapade i applikationen, men har ingen egen koppling tillbaka mot applikationen. Applikationen har även en koppling mot MySQL-servern som tillhandahåller de uppgifter som företaget behöver från en MySQL-databas. Denna koppling sker med SQLanrop. Servern har inte heller någon koppling mot applikationen. Accessdatabas MySQLserver MySQLdatabas Hemsidan SQL Applikation FTP Figur 2.2 Systemöversikt.

Bokningssystem för turistföretag 9 (34) 3 Programmeringsverktyg Detta kapitel beskriver de verktyg och språk vi använt oss av. Följande verktyg har använts: Borland C++ Builder 5.0 MySQL Server 4.1 Microsoft Access 2000 NSIS 2.06 HM NIS Edit 2.0.3 Microsoft Notepad 5.1 Följande språk har använts: C++ SQL (Structured Query Language) HTML (Hyper Text Markup Language) Javascript NSIS-script (Nullsoft Scriptable Install System) Följande skriptspråk har används: ASP (Active Server Pages) med VB-skript 3.1 Borland C++ Builder 5.0 Eftersom det inte fanns några speciella krav på programmeringsspråk eller programmeringsverktyg från företagets sida, använde vi oss av Borland C++ Builder 5.0. Valet av Borland gjorde vi för att det är det verktyget vi använt oss av under vår utbildning vid Örebro Universitet. 3.2 MySQL Server 4.1 Valet av MySQL Server 4.1 gjorde vi för att det är gratis, säkert och stabilt. MySQL har öppen källkod vilket betyder att vem som helst har fri tillgång till källkoden och kan ändra den efter eget behov. MySQL kan laddas ner från Internet [2]. 3.3 Microsoft Access 2000 Microsoft Access 2000 ingår i Microsoft Office 2000 Pro-paketet. Verktyget är en databashanterare som har ett grafiskt gränssnitt. Microsoft Access skapar en databasfil som innehåller alla tabeller som man skapat. 3.4 NSIS 2.06 NSIS är ett verktyg för att skapa en installationsfil. Ett känt program som använder sig av NSIS-teknik är Winamp, som är ett gratis program för att spela upp mediafiler. NSIS finns gratis att ladda hem från [3].

Bokningssystem för turistföretag 10 (34) 3.5 HM NIS Edit 2.0.3 För att så lätt som möjligt skapa installationsfilen med våra önskade inställningar använde vi oss av HM NIS Edit som är ett grafiskt gränssnitt mot NSIS. Programmet finns att ladda hem på [4]. 3.6 Microsoft Notepad 5.1 För att skapa hemsidan och få en så förståelig kod som möjligt utan alla tillägg som kan skapas av HTML-verktyg användes notepad (Anteckningar på svenska Windows-versioner) som ingår i Windows. Notepad är en textredigerare med grundläggande funktioner som används om man vill skapa enkla dokument.

Bokningssystem för turistföretag 11 (34) 4 Genomförande 4.1 Utredning av krav Kraven vi fick från Valle&Anders AB var inte speciellt många, vi fick själva försöka sälja programmet och försöka trycka på vad som skulle underlätta för dem med ett bokningsprogram. Efter diskussion med företaget och det vi nämnt under rubrik 1.2, kan kraven sammanfattas med: Användarvänligt Man ska kunna ha ett kundregister Det ska gå att få en översikt över utgifter som deras fordon har Det ska finnas en kalender där fordonens bokningar syns Det ska finnas resor som är kopplade till ett fordon och kan bokas av kund Det ska gå att skriva ut fakturor och offerter Företaget vill kunna visa upp sig på Internet genom egen hemsida 4.2 Design av applikation och hemsida Vi använde oss av namngivningskonventioner när vi arbetade med vårt program. Små tecken för variabler, då de består av flera ord ska nästa ords första bokstav vara en versal. T ex envariabel. Ett tillägg för komponenter i huvudfönstret är att de ska ha prefix av det blad de finns på. T ex ska en knapp som lägger till en kund och finns på bladet kund heta customeraddcustomer_btn. Komponenter ska följa samma namnkonvention som för variabler, dock med skillnaden för ett suffix som talar om vad för sorts komponent det är. Suffixet ska bestå av ett understreck _ följt av tre bokstäver, i undantagsfall fyra för att skilja liknade suffix åt, t ex _btn och _rbtn för en TBitButton respektive TRadioButton. Ett dokument som beskriver alla använda suffix är skapat. Funktioner följer endast namnkonventioner för funktioner som man ska sätta värden för en medlemsvariabel eller hämta ett sådant. De ska då ha prefixen set respektive get. Önskan är dock att i möjligaste mån ha ett förklarande namn för vad funktionen gör. För att kunna spara information som användaren behöver för nästa session av applikationen, var vi tvungna att välja ett sätt att spara data på. Det finns två sätt man kan göra detta på. Antingen lägger man in uppgifterna i registret eller så skapar man en ini-fil. Registret är bl a skapat just för detta och att man ska slippa använda sig av små filer som ligger i samma mapp som den exekverande filen. Borland har hjälpfunktioner för att både skapa och använda sig av ini-filer och använda registret. Vi valde att använda oss av ini filer. Dels för att de är lättare att återskapa om något blir fel och för att det råder en inkonsekvens mellan Microsofts olika operativsystem om vart man ska lägga data i registret.

Bokningssystem för turistföretag 12 (34) 4.2.1 Design för användarvänlighet Allmänt Målet med designen var att få ett så användarvänligt program som möjligt. De tänkta användarna för denna applikation är Windows-användare, d v s de har bara en grundlig erfarenhet av hur program ser ut i denna miljö. Därför är det tänkt att vi inte ska använda oss av en design som är olik den vanliga som används för program i Windows-miljö som beskrivs i User Interface Design for Programmers [5]. Knappar med ikoner I den mån det hjälper till ska även knappar ha en ikon, förutom en text, som ska förtydliga meningen med knappen. Se Figur 4.1. Ett undantag är för de knappar som är till för att förhandsgranska, den knappen utgörs av endast en ikon, föreställande ett förstoringsglas. Denna symbol används av de flesta Windows program som har en knapp för att förhandsgranska. Figur 4.1 Meddelanderuta med ikoner på knapparna för att tydligare beskriva deras funktion. Radioknappar och checkboxar Vid skapandet av GUI:t ville vi använda oss av reglerna för radioknappar och checkboxar som [6] skriver om. Ett sätt för att uppnå detta var att vi alltid skulle lägga radioknappar och checkboxar i egna boxar för att användare ska förstå att alternativen hör ihop. Installation För att underlätta installationen för Valle&Anders AB, gjorde vi endast en installationsfil för programmet. MySQL-ODBC:n (Open Database Connectivity), som är till för kopplingen mot databasen för applikationen, blev implementerad i denna installation. Vad som utgjorde ett problem här var när installationen av ODBC skulle ske. Valet var mellan före eller efter att programmet skulle installeras. Vi bestämde oss för att installera den före själva applikationen. Eftersom vi inte använder oss av någon komponent som behöver en omstart av operativsystemet, kan Valle & Anders AB nu välja att köra programmet direkt efter att installationen är färdig. För att installera servern använde vi oss också av en egen installationsfil. Den filen installerade servern och kopierade sedan databasen till servern. Den sätter även rättigheterna till användaren för databasen.

Bokningssystem för turistföretag 13 (34) Hjälpknapp i varje fönster Alla dialoger och fönster har en länk till en hjälp-sida som dokumenterar hjälpen för det/den aktuella fönstret/dialogen. Detta är för att underlätta för användaren att snabbt ska kunna hitta svar på eventuella frågor som rör aktuellt fönster/dialog. Hjälpknappen i varje fönster/dialog har tangentbordsnavigering ALT+H, detta för att underlätta åtkomst till hjälpen. Microsoft Access-databas Eftersom vi vill ha ett så användarvänligt program som möjligt använde vi oss av en Accessdatabas för hemsidan, eftersom den skapar en fil som lätt kan läggas upp på hemsidan. Om man t ex skulle ha använt en MySQL-databas är man tvungen att logga in på webbplatsens databas och lägga till tabellen/tabellerna som hemsidan ska arbeta mot. 4.3 Design av databaser När vi skapade databaserna gjorde vi först ett grafiskt gränssnitt att bygga mot. Detta gällde för både applikationen och hemsidan som kan ses i Figur 4.2. Applikationen Hemsidan Skapande av GUI Skapande av hemsidans skal Mindre omplanering Mindre omplanering Implementation av MySQL-databas Implementation av Access-databas Figur 4.2 - Diagram över arbetsgången vid framställande av databaserna. Databasen för applikationen kan ses i Appendix D och databasen för hemsidan kan ses i Appendix E. 4.4 Implementation av klasser, hemsida och SQL-frågor Vårt mål vid implementationen var att arbeta enligt treskiktsmodellen. Att ha tre olika skikt, ett som presenterar information för användaren och som användaren kan interagera med, ett skikt som kopplar samman det presenterande skiktet med skiktet som hanterar kopplingen mot databasen. Arbetsgången för att försöka åstadkomma detta kan ses i Figur 4.3.

Bokningssystem för turistföretag 14 (34) Applikationen Hemsidan Skapande av GUI Skapande av hemsidans skal Mindre omplanering Mindre omplanering Implementation av databas Implementation av databas Implementation av klasser Implementation av SQL-frågor Figur 4.3 - Diagram över arbetsgången för framtagning av systemet. 4.5 Test och felrättning Fel som har uppstått efter vi varit klara med ett subsystem, har omedelbart rättats. Dock saknas en övergripande testplan för hela systemet. Tester bör utföras av personer som inte är involverade i projektet innan leverans. 4.6 Kundregister Kundregistret måste vara uppdelat i två delar, privatkunder och företagskunder. Det som skiljer dessa åt är att privatkunder har personnummer, ett förnamn och ett efternamn. Företagskunder har däremot organisationsnummer och bara ett namn. 4.7 Fordon Det ska finnas möjlighet att lägga till nytt fordon, ändra ett fordons egenskaper, ta bort ett fordon och att lägga in utgifter för ett fordon. Utgifterna som finns i tre kategorier - bränsle, reparation och underhåll - skapar en översikt för företaget om fordonet kan räknas som lönsamt. 4.8 Kalender För att se när ett fordon är ledigt eller inte vid en viss tidpunkt kan man kolla i kalendern, se Figur 4.4, över ett valt fordon. Ett fordon ska inte kunna bokas in på två resor samtidigt, men om en resa startar samma dag som en annan resa slutar så tillåts detta.

Bokningssystem för turistföretag 15 (34) Figur 4.4 - Kalender som visar vilka resor som är kopplade till valt fordon. 4.9 Resor Resor är ihopkopplade med fordonen. För att skapa en resa måste ett fordon väljas som inte är upptaget. Antal platser, pris för resan, pris för mat, pris för övernattning kan fyllas i. Även ett fält övrigt finns för att skapa ytterligare ett alternativ för kunden. 4.10 Skriva ut fakturor och offerter Företagets inkomster inbringas genom att folk betalar sina räkningar; räkningar som skickas ut med fakturor. En annan del i företagets inkomstkällor är att de på uppdrag av andra företag, föreningar eller myndigheter skapar en resa specifikt för dessa. Där kommer offerter in. Vi hade inget krav på oss hur fakturorna eller offerterna skulle se ut. Därför fick vi söka information om vad fakturor och offerter bör innehålla för att de ska kunna bli användbara. Sökningar på Internet och förfrågningar hos personer som jobbar och/eller har egna företag gav oss till slut den grund vi baserade våra fakturor och offerter på. 4.11 Övrigt Här beskrivs genomgången av de delar som inte var med i kraven för denna applikation. Dessa är krav som är skapade av oss, krav som vi tyckte skulle öka användarvänligheten och säkerheten. Varje del inleds med en liten kravgenomgång varför vi tyckt att dessa krav är resonabla att ta med.

Bokningssystem för turistföretag 16 (34) 4.11.1 Hemsidor I applikationen finns möjlighet att skapa enklare hemsidor. Här kan val som hur stilen, placeringen och storleken för texten göras. Möjlighet för att förhandsgranska hur dokumentet ungefär kommer att se ut finns. Man kan även redigera redan befintliga hemsidor som hämtats ner med hjälp av applikationen, se mer under 4.11.2. Man kan även här välja att skicka upp hemsidan man skapat till webbplatsen på Internet. 4.11.2 Nedladdning av hemsidor Här kan man hämta och skicka upp hemsidor som ska visa kommande resor med företaget. Det finns även möjlighet att välja vilka sidor som ska visas i menyn på själva hemsidan och i vilken ordning de kommer att visas. Det finns också en möjlighet att uppdatera hemsidan på Internet efter att man ställt om ordningen och/eller om sidan ska visas. En förhandsgranskning av en vald hemsida finns också. Därifrån kan man ta bort den visade hemsidan; det valet finns även i steget under. Sedan kan man välja att kopiera sidan för att kunna ändra i den eller använda den som man valt att kopiera som en mall för att skapa en ny sida. 4.11.3 Backup av hemsidor Ett menyval möjliggör att man kan skapa en backup av befintlig databas för hemsidorna som ligger på Internet. De val man kan göra här är att göra en backup direkt, som gör att man kopplar upp sig mot FTP-servern på webbhotellet som sidan finns på. Inställningarna för FTP:n måste vara korrekta, så att en koppling kan möjliggöras. En annan möjlighet är att skapa backup:er på ett visst tidsintervall. Intervallet är mellan 1 och 60 dagar och sparas i den ini-fil som tillhör programmet. Man kan även här välja att inte ha något intervall alls. När en backup skapas görs en koppling mellan applikationen och webbhotellet. Databasen som finns att ladda ner sparas som databasensnamn_dagensdatum.mdb. 4.11.4 Backup av databasen Genom att välja i en meny, kan man göra en backup av databasen. Backup kan endast göras på den dator som servern finns på. Ett val man kan göra är att ta en backup av databasen direkt. Då skapas en mapp: Bup_db_ååååmmdd\ I mappen sparas data och tabellinformation. Tabellinformationen sparas i filer med ändelsen.sql och data för tabellerna sparas som.txt-filer. Ett annat val är att man kan välja ett intervall som databasen ska tas backup med. När applikationen startas kontrolleras det mot ini-filen om det ska göras en backup och om så är fallet, om datumet har inträffat eller är idag, görs en backup. Man kan även välja att ingen intervallkontroll om backup på databasen ska finnas. 4.11.5 Kryptering Säkerheten för applikationen är ett krav som vi lade till. Vi ville att ett inloggningsfönster skulle visas när programmet startas. Detta för att förhindra intrång i applikationen. Se mer om det nedan. För att koppla upp mot ftp- och MySQL-servern avkrävdes också ett lösenord.

Bokningssystem för turistföretag 17 (34) Vi använder oss av en ini-fil för att spara inställningar i programmet, det gör att det skulle vara sårbart och öppet att komma åt data i programmet. Därför har vi använt oss av kryptering till vissa data i denna fil, som t ex lösenorden och användarnamnen. Metoder Det fanns flera olika metoder att välja mellan: Microsoft API Tredjepartstillverkare Egentillverkad Microsoft API Microsoft tillhandahåller ett API att använda sig av vid kryptering. Detta API är avancerat i den bemärkelsen att det gör en avancerad kryptering. Tredjepartstillverkare Det finns många krypteringsalgoritmer och tillverkare av krypteringsbibliotek. En del är gratis, men många kostar pengar. Eftersom vi inte har befogenhet att lägga till saker som medför kostnader för företaget vi gör examensarbetet åt, gick de krypteringsalgoritmer bort som kostade pengar. Valet av krypteringsmetod blev till slut att göra en egen. Valet gjorde vi för att det skulle vara enkelt att kontrollera vad som egentligen gjordes med krypteringen och att de eventuella buggar som kunde uppstå i krypteringen skulle vi själva kunna fixa och inte behöva vänta på att någon skulle fixa dem. Det är en av fördelarna jämfört med att använda sig av en tredjepartstillverkares kryptering. Dock ska inte vår säkerhet i krypteringen jämföras med de flesta tillverkares. Vi ansåg också, till fördel för en egentillverkad kryptering att företaget som vi gör programmet åt inte räknas som ett högriskobjekt för intrång. Denna kryptering/dekryptering används på login-fönstret för applikationen och användarnamn och lösenord till både databasen och hemsidan. För mer information om kryptering se [7]. 4.11.6 Fordonskomponent En av de saker som företaget önskade av oss var att de skulle vilja kunna se hur mycket ett fordon kostat under den tid då de haft det i sin ägo. Vi gjorde tre tabeller i databasen, se Appendix D, som tillhör fordonen. Där lagras data för de olika slags utgifter som de kan stöta på. Här kan det vara svårt att få någon riktig känsla för hur mycket kostnaden egentligen är för fordonet utslaget på ett år. Det är här vår komponent kommer in. Valet av att skapa en komponent låg i att vi tyckte det var tekniskt intressant. En fördel med att skapa en egen komponent är att vi kan använda oss av den i andra projekt om så önskas. Den kommer att finnas tillgänglig i fliken Samples i Borland C++ Builders miljö. Först blev det mycket läsande om hur man skapar komponenter i Borland C++ Builder. För det stod bland annat BDN (Borland developer network) [8] och [9] för ovärldelig hjälp. På

Bokningssystem för turistföretag 18 (34) BDN:s [8] forum kan man hitta mycket information om hur man löser vissa problem med komponenter. För att göra det lite enklare för oss själva och slippa krånglig kod med att hantera alla olika Windowsmeddelanden och skapandet och hanteringen av komponenten på formuläret, bestämde vi oss för att använda oss av en basklass som Borland tillhandahåller. Borland bjuder på en uppsjö av olika komponenter som man kan bygga vidare på. Det finns även komponenter som tredjepartstillverkare gjort. De kostar pengar för det mesta, så de sållades ut från detta projekt eftersom vi inte har rättigheterna att lägga till utgifter för företaget. Sen tänkte vi ut hur vi ville att komponenten skulle se ut och hur vi skulle göra för att få den att se ut så. Vad vi ville att den skulle göra var ju att rita ut ett antal staplar som grafiskt skulle visa utgifterna. Grundkravet på komponenten låg därför alltså i att man ska hantera någon slags grafik. Här kom vi fram till att bygga på den färdiga komponenten TCustomPanel. Det som är bra med denna komponent är att den har en TCanvas som man enkelt kan rita på. Utseende Staplarna skapades i ett eget koordinatsystem. De axlar som gjordes var en prisaxel och en tidsaxel. Prisaxeln skulle representera kostnaden med enheter i hela kronor och tidsaxeln skulle representerade tid med enheter i månader och år, se Figur 4.5. Figur 4.5 - Ett exempel på utgifter för Scania-bussen. När vi ritade ut staplarna kontrollerades även det högsta värdet, kostnaden, som någon stapel kunde få. Detta gjordes för att inte någon stapel skulle ritas ovanför komponentens översta

Bokningssystem för turistföretag 19 (34) del. De andra staplarna blir skalade mot detta högsta värde. Värdet visas även vid komponentens pris-axel. Valet som gjordes först med att rita staplarna var att man bara skulle ha ett streck för varje utgift, men det blev för svårt att överblicka. Staplarna som ritades ut gjordes istället av solida rektanglar, som hade en enhetlig färg för samtliga likadana utgifter i olika månader. Ur användarperspektiv kom vi fram till att förklaringar till de uppgifter som visades i komponenten skulle behövas för att underlätta användandet av komponenten. Förklaringarna till de olika staplarna för utgifterna, blev en ruta där information om vilken sorts utgift hörde till vilken färg som staplarna har. För att visa vilken månad som skulle startas med gjorde vi en funktion som tog emot detta. Startmånaden valdes med en visuell komponent som visade den valda startmånaden. Dock valde vi att i vår komponent lägga till vilken aktuell månad och vilket år det var frågan om. Detta för att lättare kunna få en överblick med endast komponentens hjälp över aktuell tid. För mer detaljerad information om hur komponenten är skriven se Appendix H. 4.11.7 Loginfönster Vi hade till en början inte något login-fönster med i designen eller kraven. Men för att kunna skydda data från obehöriga måste ett login-fönster finnas vid start av applikationen. Vi skapade ett fönster som visades direkt vid programstart. Det fönstret gav frågan till användaren om lösenordet. Vi överlät till Valle&Anders AB omdöme om de skulle ha ett lösenord eller ej, d v s de kan ha ett tomt lösenord. Lösenordet sparas och läses krypterat från ini-filen. Byte av lösenord kan göras under en meny i huvudfönstret. För att lösenordet ska ändras måste det gamla lösenordet anges, det nya lösenordet och en bekräftelse på det nya lösenordet. 4.12 Hemsidan Hemsidan kopplade vi samman med applikationen genom att hemsidans Microsoft Accessdatabas laddas ner till applikation. Sedan kan resor skapas i programmet som läggs till i databasen och sedan laddas databasen upp igen. Hemsidan fungerar som ett skal för databasen. Den är huvudsakligen uppbyggd med HTML, men för att skapa popup-menyn använde vi oss av ett javascriptexempel från [10]. För att det skulle se lika ut som möjligt för den besökande skrev vi olika kod för två olika webbläsare. Detta för att menyn skulle hamna på samma ställe oberoende av om den besökande använde sig av Internet Explorer eller Mozilla Firefox. Resemenyns alternativ skapas från rubrikerna på resorna som finns i databasen. Resorna har en flagga (sant eller falskt) i databasen som bestämmer om resan ska visas eller inte, på så sätt kan Valle&Anders AB själv bestämma om de vill visa eller dölja en resa istället för att ta bort den.

Bokningssystem för turistföretag 20 (34) 4.13 Databaser Anledningen att vi använder oss av databaser är att det är enkelt, kraftfullt och flexibelt. Enkelt är det för att man inte behöver skriva en massa kod för att kunna spara data i en tabell. En tabell skapas enkelt med t ex SQL-anropet: CREATE TABLE Kund (KundNr Integer, Namn CHAR[50]) Kraftfullt är det för att man på ett enkelt sätt kan göra avancerade sökningar, t ex om man vill ha reda på alla kunder med ett namn som slutar på sson, kan man skriva SQL-frågan: SELECT * FROM Kund WHERE Namn LIKE %sson Flexibelt är det för att om man vill utöka sina kunddata behöver man inte göra om större delen av sitt program, det räcker med att man skriver SQL-anropet: ALTER TABLE Kund ADD Telefon CHAR[15] för att lägga till ett attribut för telefonnummer. Varför man ska välja en databashanterare kan man läsa mer om i [11]. När vi skapade databaserna var det viktigt att bygga upp dem så att det inte fanns någon redundans. 4.13.1 Applikationens databas För att kunna koppla samman MySQL-databasen med applikationen använder vi oss av ODBC. Varje klientdator måste ha ODBC installerat, efter installationen behövs inga inställningar. För mer detaljerad information om hur ODBC-koppling mot databasen upprättas se Appendix B. 4.13.2 Hemsidans databas För att ansluta hemsidan med Access-databasen används ADO (ActiveX Data Objects). För detaljerad information hur detta fungerar se Appendix C. Vi ville sedan använda oss av ASP för att hämta data från databasen, för att se hur data hämtas med hjälp av ASP-kod se Appendix C. 4.14 Utvecklingsdata När detta examensarbete är klart ska den produkt, som detta examensarbete utvecklat, sparas på en cd-skiva. Den skivan ska innehålla installationen av servern och klienten. Detta dokument, hemsidan samt källkoden till applikationen ska även finnas med. Vad vi gjorde var att vi skapade en mappstruktur som skivan skulle innehålla, se Figur 4.6.

Bokningssystem för turistföretag 21 (34) Figur 4.6 - Mappstrukturen för cd-skivan De mappar som skulle finnas med och ligger direkt i roten för skivan är: Dokument Hemsidan Installationsfiler Källkod 4.14.1 Dokument Här kommer det slutgiltiga dokumentet ligga i Adobe PDF format. 4.14.2 Hemsidan Här läggs hemsidan som Valle&Anders AB har haft som krav. Strukturen av denna mapp är den struktur som Valle&Anders AB kommer att bli instruerad att lägga hemsidan som. Den innehåller även tre undermappar. En för databasen, db, där det ligger en tom databas. Den andra mappen, img, ska innehålla bildfilerna som ska finans på hemsidan. Den sista är skriptmappen, script, där en css-fil kommer att ligga. 4.14.3 Installationsfiler Här läggs de installationsfiler som installerar klient- och serverdelen. Även dokumentation som vägleder Valle&Anders AB genom installationen ska finnas med här. 4.14.4 Källkod Källkoden för applikationen och hjälpen finns här. Det finns även ett dokument som beskriver hur man ska göra för att sätta upp systemet i fall de vill programmera om programmet. Det ska även finnas undermappar här. En mapp för själva applikationen och en för hjälpfilen. Den undermapp som är för applikationen ska ha undermappar. Dessa är nödvändiga för att kunna kompilera. Dessa är:

Bokningssystem för turistföretag 22 (34) Exe, den mapp som startfilen kommer att genereras i. Det ska även finnas med en undermapp, script, för att kunna se hemsidor med korrekt resultat, för vårt projekt. Images, den mapp som alla bilder och ikoner som hör till applikationen ligger i. Interm, den mapp som alla tillfälliga filer kommer att hamna i. Undermappen för hjälpfilerna innehåller de filer och bilder som behövs för att kunna kompilera hjälpen. Ett dokument kommer även att ligga här för hur man kan göra för att ladda ner programmet vi använde oss av och vilka filer vi använde oss av.

Bokningssystem för turistföretag 23 (34) 5 Resultat Det vi ville åstadkomma med arbetet var att underlätta arbetet för Valle&Anders AB med att göra bokningar, att få en överblick över fordonen i verksamheten samt att marknadsföra sig på Internet. Visst kan det verka krångligt att man måste skapa ett fordon för att kunna skapa en resa som en kund sedan kan boka in sig på, men för att förhindra att fordon dubbelbokas måste detta göras. I slutändan underlättar det mer än vad det försvårar. Eftersom kunder är kopplade till resor, är det enkelt att skriva ut fakturor till kunder. Om man väljer en kund som man vill skriva ut en faktura till så kommer automatiskt alla resor som kunden har skulder till fram i en meny. 5.1 Utredning av krav 5.1.1 Design för användarvänlighet Allmänt Eftersom Valle&Anders AB inte har god datorvana designade vi ett eget meddelandeformulär så att en Hjälp-knapp, se Figur 5.1, skulle finnas tillgänglig på varje meddelande. Figur 5.1 - Meddelanderuta med Hjälp-knapp. Programmet är byggt med hjälp av flikar. Detta användes för att användaren skulle få en bra överblick över programmet, och dess funktioner, i stället för att varje funktion ska öppnas i ett nytt fönster. För att ge hemsidan en funktionalitet som de konkurrerande företagen inte har, kopplade vi ihop programmet med hemsidan. Detta för att göra det lättare att lägga upp nya aktuella resor på hemsidan genom en Resor-meny som visar alla resor företaget har, se Figur 5.2.

Bokningssystem för turistföretag 24 (34) Figur 5.2 - Meny för val av resa som information önskas om. 5.1.2 Installation av systemet Systemet levereras med två installationsfiler samt ett arkiv med hemsidans filer. Den ena är installationsfilen för MySQL Server 4.1 som är samma fil som kan laddas ner från [2]. Den andra installationsfilen innehåller applikationen och MySQL ODBC 3.51. Vid installation av applikationen startas installationen för MySQL ODBC 3.51 automatiskt, eftersom varje klientdator måste ha denna programvara. Efter att installationen av ODBC:n är klar fortsätter installationen av applikationen. Arkivet med filerna för hemsidan innehåller alla mappar och en tom databas som behövs för att hemsidan ska fungera. Det enda man behöver göra är att lägga upp alla filerna och mapparna på en webbplats som stödjer ASP.

Bokningssystem för turistföretag 25 (34) Resultat av installationsfilen innehåller sidorna: Välkommen Visa ett välkomstmeddelande för användaren. Licens Där licensen för programmet visas. Här måste användaren godkänna licensen för att kunna fortsätta, detta val görs med så kallade radioknappar. ODBC-installationen Den sida vi själva skapade. För att installera ODBC:n är användaren tvungen att trycka på nästa och installationen fortsätter till nästa sida så fort ODBC:n är installerad. Installationsväg Här väljs vart på hårddisken applikationen ska installeras. Startmenyval Här väljs under vilken mapp i startmenyn som användaren vill lägga genvägarna för applikationen. Installationsförlopp Här visas ett installationsförlopp där man kan överblicka de filer som kopieras till systemet. Sista sidan Under denna sida kan användaren välja om applikationen ska starta efter att man tryckt på Slutför. Figur 5.3 - Installationssidan av MySQL ODBC. 5.2 Implementation av klasser, hemsida och SQL-frågor Vårt mål med att använda treskiktsmodellen blev inte som önskat. Efter för mycket programmering utöver planeringen blev inte uppdelningen av klasserna bra. Kopplingen mot databasen finner man i en egen klass, men hämtning och skrivning av data sker lite varstans. Huvudformuläret kom att innehålla allt för mycket av funktionalitet. Detta beror till viss del av att vi använder oss av flikar. Om man använt formulär i stället för flikar hade all kod hamnat under varsitt formulär, men nu när flikar används hamnar all kod under samma.

Bokningssystem för turistföretag 26 (34) 5.3 Kundregister Privatkunder och företagskunder skiljs inte åt för att de är olika slags kunder, utan alla kunder har unika kundnummer. Detta sker genom arv från en gemensam tabell som bara innehåller kundnummer. För att hämta kunder kan man antingen genom att klicka på Hämta kunder, för att hämta alla kunder, eller så kan man söka efter kunder. Vid sökning efter en kund eller flera kunder kan man ange om man vill snabbsöka (söker på kund-, person- eller organisationsnummer) eller söka efter angiven information, se Figur 5.4. I programmeringstermer är det som skiljer innehålla allt av nedanstående och innehålla något av nedanstående alternativen åt att förstnämnda använder sig av AND i SQL-frågan och det sistnämnda använder sig av OR i SQL-frågan. Figur 5.4 - Sökningsformulär efter kunder.

Bokningssystem för turistföretag 27 (34) Kunder som är funna vid sökning eller hämtade vid klick på Hämta kunder visas i var sin TListView som skiljs åt med hjälp av flikar, se Figur 5.5. Figur 5.5 - Fliken för att visa kundregistret. 5.4 Fordon Det finns möjlighet att se fordonets utgifter på ett grafiskt sätt, där de olika utgifterna visas i olika spalter med egna färger. Utgifterna visas från en bestämd startmånad och ett år framåt, se Figur 4.5. 5.5 Skriva ut fakturor och offerter Vi gjorde så att alla rutor som innehöll data under Offert- och Faktura-fliken kunde ändras av företaget. Då de kanske vill ge mer information till kunden eller ändra prisuppgifter. En extra ruta för övrig information finns också att fylla i vid behov. 5.5.1 Offert Möjlighet att välja en kund finns genom att man kan välja snabbknapp till Kund-fliken och där välja en kund. Kundens alla uppgifter sätts då in i sin rätta del i dokumentet. Samma sak finns som valmöjlighet för att välja en resa. En förhandsgranskning på hur dokumentet ungefär kommer att se ut finns också, samt möjligheten att skriva ut. Alla uppgifter i offerten kan ändras för hand, och samtidigt finns en automatisk koll på de inlagda prisuppgifterna. En summa räknas automatiskt ut för varje rad då antalet och a pris är korrekt ifyllda. Summan kan även den ändras för hand utan att en koll görs, men inte någon av uppgifterna i antal och

Bokningssystem för turistföretag 28 (34) a pris ändras av det. En extra ruta för företagets egna anteckningar/meddelanden till kunden finns också, den fylls aldrig i av applikationen utan är endast till för företaget självt. 5.5.2 Faktura Faktura fungerar i stort sätt lika som offerten. Skillnaden här är att man inte väljer en befintlig resa utan en resa som kunden har en skuld till. De resor som det finns skulder till för den specifikt valda kunden väljs genom en combobox, om inga resor finns obetalda är denna combobox utgråad och inte valbar. Se även Figur 5.6. Figur 5.6 - Ett exempel på hur en faktura kan se ut. 5.6 Övrigt 5.6.1 Kryptering Krypteringen fungerar på ett tillfredsställande sätt. Med tillfredsställande menas här att vi kan blockera det som kan kallas för genomsnittliga användare, de som inte har djupa programmeringskunskaper. 5.6.2 Login-fönster Fönstret för att logga in är ett av det första fönster som man ser när programmet startas. Här måste användaren skriva in rätt lösenord för att gå vidare in i programmet.

Bokningssystem för turistföretag 29 (34) 5.6.3 Låsningen av tangentkombinationer Varje fönster och meddelande förutom huvudfönstret har ingen minimera, maximera och stängknapp. Vi har även låst tangentkombinationen ALT+F4 för att fönster inte ska kunna stängas utan ett knapptryck. Detta är för att vi ska kunna kontrollera flödet i programmet och att inget oförutsägbart ska hända. 5.7 Utvecklingsdata Då applikationen inte är helt färdig kan det ske ändringar i hur uppbyggnaden av skivan. Det som endast är gjort i nuläget är själva strukturen och installationsfilen för serverprogrammet. Allt annat som ska vara med på skivan, inklusive detta dokument, är ännu inte i helt färdigt. Inga hjälpdokument är heller färdiga i dagsläget.

Bokningssystem för turistföretag 30 (34) 6 Diskussion 6.1 Applikation och hemsida Diskussion allmänt Hemsidorna skapas med stilmallar (CSS), så när man ska redigera befintliga sidor måste de vara skapade av antingen programmet eller något/någon annan som vet vilka stilmallar vi använder och hur de ser ut. Resultatet kommer annars att vara odefinierat. Det kommer troligtvis leda till att sidan inte visas som det är tänkt och sidan på Internet inte kommer att få den stilrenhet vi eftersträvat med stilmallarna. Företaget kanske kommer att behöva hjälp med att skaffa ett webbhotell. Vi kommer att rekommendera dem att ta ett hotell som har stöd för ASP, FTP och SMTP. Då kan de till fullo utnyttja applikationens alla funktioner. Då vi ännu inte är klara med e-postdelen av applikationen och företaget kanske inte vill ha den egenskapen kan kravet på SMTP försvinna. Diskussion kryptering Som vi har det nu med krypteringen/dekrypteringen ligger det som en del av källkoden för huvudfönstret, närmare bestämt en klassfunktion som är privat. Det skulle ha varit bättre om vi skapat en helt egen klass för dessa. Anledningen skulle vara om man ville ändra på krypteringsalgoritmen skulle det vara lätt. Man skulle även kunna testköra den så at man är säker på att den fungerar innan man lägger in den i applikationen. Sen skulle det bara vara att skriva över den klassen och bygga om projektet för att få applikationen med den nya krypteringen/dekrypteringen. Den krypteringsalgoritm vi använder oss av är det nog inga större problem att knäcka för en person som vet hur man forcerar krypteringar. Det är heller inte målet med denna krypteringsmetod, då den är mer för att undvika att vem som helst ska kunna komma in och ändra i applikationen och dess data. Diskussion hjälp Då alla hjälpknappar har tangentbordsnavigeringen ALT+H, kan inte menyvalet för hjälp ha den. Det är dock den enda tangentbordsnavigeringen som inte stödjer nomenklaturen för applikationen med hänsyn tagen på hjälp. Menyn för hjälpen har istället fått kombinationen ALT+J. Diskussion namngivningskonvention Anledningen till att som i exemplet i avsnitt 4.2 Design av applikation och hemsida, ha den kanske lite krångliga namnkonventionen customeraddcustomer_btn är relaterat till att vi använder oss av en TPageControl. Den har flera flikar med olika komponenter på varje flik. Alla komponentnamn läggs in i huvudfönstrets klassdeklaration. Eftersom det då blir många komponenter som läggs till, blir det svårt att hitta den komponent man letar efter när man söker efter den. Diskussion testning Om testning skulle ske med en tredje part, skulle det vara bra om denna tredje part var en ovan datoranvändare. Varför en ovan användare skulle vara bra att användas till testningen är att användarvänligheten skulle kontrolleras ordentligt. Att använda en van användare skulle inte vara lika bra p g a att de flesta som kan Windows kan känna igen sig och vet hur vissa

Bokningssystem för turistföretag 31 (34) saker bör/kan fungera och därigenom faller hela idén med testningen för användarvänligheten. Feedback från en van datoranvändare skulle också bli jag tycker att det ska fungera så här!. Medan en ovan användare skulle fråga hur fungerar det?, därigenom skulle man få ett svar på att användarvänligheten måste förbättras. Diskussion installation En brist med att vi använder oss av en installationsfil som vi själva inte gjort är att ODBCinstallationsprogrammet är på engelska. Den av oss skapade installationsfilen är på svenska. Installationen av servern som vi levererar är också på engelska. Dock borde det inte utgöra några svårigheter för Valle & Anders AB eftersom vi ska göra ett dokument över installationsförfarandet till servern. Diskussion splash-fönster Vi startar applikationen med ett s k splash-fönster. Detta fönster visar den buss som Valle & Anders AB har i sin ägo just nu. Själva bilden visas upp i sammanlagt 3 sekunder och den sista sekunden används för att tona ut bilden. Detta fönster kan bli irriterande om man startar programmet. Diskussion fordonskomponent Komponenten är lite väl enkel som den är i dagsläget. Eftersom tidsbrist uppstod även här, fick vi nöja oss med att den visade upp utgifter, från en vald startmånad och ett år framåt. En annan sak om denna komponent är att den inte är generellt skriven, d v s att den är väldigt inriktad mot applikationen och databasen som vi gjort. Att implementera denna komponent i ett annat projekt är möjligt, men troligtvis behövs en del redigerande av komponenten göras. En förbättring som skulle vara önskvärd är att man skulle kunna klicka på data och se information om utgifterna. En sak som skulle behövas ses över är de använda färgerna. Här används gul, blå och röd, där gult kan synas lite dåligt. Grönt hade varit att föredra i den bemärkelsen att den är mer synlig än gult. Dock finns det många i Sverige som är färgblinda och då särskilt röd/grön besvärligt. Därför kom valet att hamna på gul, blå och röd. En annan sak är att, som beskrivet ovan, man skulle kunna ha en länkad komponent till vår komponent. Då skulle en ändring i den länkade komponenten göra så att vår komponent också skulle få en ändrad startmånad. Det skulle göra en smidig lösning för komponenten och man skulle kunna ta bort funktionen som sätter månaden som man ska starta. Som det är nu så används en TMonthCalendar som i dess onchange-funktion ändrar komponentens startmånad genom ett funktionsanrop. Detta skulle alltså kunna undvikas om man skulle länka en sådan komponent till vår komponent. Det skulle kunna visas delenheter för att enklare klargöra för priset på de utgifter som inte är lika stora som den största utgiften, eftersom den enda prisuppgiften som visas just nu är priset på den största utgiften.

Bokningssystem för turistföretag 32 (34) 6.2 Förbättringar och framtida utveckling En liten förbättring av krypteringsalgoritmen fanns som förslag, men på grund av tidsbrist så genomfördes inte detta. Programmet sparar inloggningen krypterat i ini-filen. Men är inloggningen en tom sträng, står ingenting i raden för inloggningen. Följden av det är att det bara är att radera i ini-filen där inloggningen ska stå, starta applikationen, sen välja att logga in med en tom sträng och komma in i applikationen. Vad som skulle kunna förbättra detta är att det alltid ska stå ett krypterat dummy -ord för inloggningen i ini-filen. Det skulle kunna vara ett dummy -ord, som användaren inte ska kunna använda sig av, och att applikationen gör en koll på detta när användaren vill byta lösenord till inloggningen. När en backup görs av applikationen skapas en mapp med namnet Bup_db_åååmmdd\, i den läggs, som det nu är, alla data om databasen med tabeller och data till tabellerna. Vad som skulle vara en förbättring är att göra som när man använder sig av MySQL Administrator, som är skapat också det av MySQL AB, att det sparas endast en fil med alla tabeller och deras data i. Filen är uppbyggd så att den kontrollerar om tabellerna finns, i så fall tar den bort dem, och sedan återskapar dem. Efter att tabellerna är skapade sätts data in i dem. Programmet har just för tillfället ingen funktion som gör det möjligt att återskapa en databas. Det är ett måste om man ska ha någon nytta av att man ska ta backup på databasen. Förslaget hur detta ska fungera är att en fil, som ska innehålla databasens tabeller och namn ska skapas av de filer som skapas när man gör backup på databasen, som beskrivs ovan. Något som hade varit bra för chaufförerna kunde ha varit att man skulle kunna skriva ut en körlista för varje fordon, t ex från kalenderfunktionen. Eftersom företaget inte är speciellt stort i dagsläget kan denna funktion verkar överflödig, men om företaget skulle växa skulle en sådan funktion underlätta betydligt. En utbyggnad av användarkonton med olika behörigheter till programmet kan vara bra. Kanske att chaufförer har en viss behörighet för att se aktuella bokningar och för att lägga in utgifter för fordonen. Sedan ett administrativt konto för att utföra bokningar, skapa nya resor, fordon m m. Men, som nämnt ovan, eftersom företaget inte är stort idag är det inget absolut nödvändighet. 6.3 Vad vi kunde gjort bättre Följande saker kunde vi gjort bättre: Bättre tidsplanering Läst på bättre om de komponenter vi använt oss av Programmerat efter treskiktsmodellen Haft en komplett testplan Låta Valle&Anders AB testköra programmet i ett tidigt skede