distributed database storage solution in javaproject were java netbeans 6.8, jcreator le 4.5, jasc...

Distributed DatabaseStorage Solution in Java

Johan Funck

May 4, 2010Bachelor’s Thesis in Computing Science, 15 credits

Supervisor at CS-UmU: Jerry ErikssonExaminer: Jonny Petterson

Umea UniversityDepartment of Computing Science

SE-901 87 UMEASWEDEN

Abstract

Car sales companies have in the last couple of years discovered that thereis a big market in storing their customer’s summer and winter tires for a smallfee. For the customers it is very convenient to get rid of the all known storageproblem with season tires. Burlin Motor Umea is one of these companies andthey are offering seasonal storage and change of tires in autumn and spring aswell as washing of tires.

The main problem for this kind of storage is how to make the storage easyto overview and how to keep track of all tires. This paper is a report ona distributed storage solution in Java for summer and winter tires based oncriteria from Burlin Motor Umea.

Contents

1 Introduction 1

1.1 Paper outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Problem Description 3

2.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3.1 Step one: Must-have . . . . . . . . . . . . . . . . . . . . 5

2.3.2 Step two: Optional . . . . . . . . . . . . . . . . . . . . . 5

2.4 Purposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Accomplishment 7

3.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.4 The customer object . . . . . . . . . . . . . . . . . . . . 10

3.3.5 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.6 Label printer . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Results 13

4.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Main window . . . . . . . . . . . . . . . . . . . . . . . . 13

iii

iv CONTENTS

4.1.2 Connecting to the server . . . . . . . . . . . . . . . . . . 14

4.1.3 Searching . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.4 Displaying the storage . . . . . . . . . . . . . . . . . . . 16

4.1.5 Creating a new customer . . . . . . . . . . . . . . . . . 18

4.1.6 Updating a customer . . . . . . . . . . . . . . . . . . . . 19

4.1.7 Printing labels . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.8 Deleting a customer . . . . . . . . . . . . . . . . . . . . 21

4.1.9 Show log . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.1 Data passing . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.2 Handling images . . . . . . . . . . . . . . . . . . . . . . 22

5 Conclusions 23

5.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3 Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Acknowledgments 25

References 27

A CustomerObject 29

List of Figures

3.1 System design client-server-database communication . . . . . . 8

3.2 Server threading . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Client threading . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Main client window . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Main window menu . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Connect to server pop up . . . . . . . . . . . . . . . . . . . . . 15

4.4 Successful connection pop up . . . . . . . . . . . . . . . . . . . 15

4.5 Unsuccessful connection pop up . . . . . . . . . . . . . . . . . . 15

4.6 Search on registration number . . . . . . . . . . . . . . . . . . . 16

4.7 Search on storage location . . . . . . . . . . . . . . . . . . . . . 16

4.8 Displaying customer info . . . . . . . . . . . . . . . . . . . . . . 17

4.9 Storage listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.10 Quick menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.11 New customer window . . . . . . . . . . . . . . . . . . . . . . . 18

4.12 File chooser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.13 Current customer . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.14 Update customer window . . . . . . . . . . . . . . . . . . . . . 20

4.15 Printed label . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.16 Delete customer pop up 1 . . . . . . . . . . . . . . . . . . . . . 21



4.19 Log file pop up . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

v

vi LIST OF FIGURES

Chapter 1

Introduction

The task of this thesis work was to develop a prototype of a distributed databasestorage solution for car tires. Car companies nowadays usually offer winterand summer storage for their customer’s tires. To keep track of the tires it isbecoming more and more advisable to have a computerized solution instead ofa pen and paper solution.

The main criteria were that it should be a network solution i.e. the storageshould be able to be reached from any computer on the intranet and that theapplication was to be run in WinXP.

Burlin Motor Umea is a part of the Burlin Group, which has its main officein Skelleftea. Burlin Motor Umea is the local vendor in Umea of Toyota andLexus and they offer a full service establishment for these cars. Used cars andrental cars are also a part in their business concept as well as tire storage fortheir customers.

1.1 Paper outline

This paper is divided in six chapters. Here is a brief description of each chapter.

Introduction A brief introduction of this thesis contents to the reader.

Problem Description An in-depth explanation of the projects various partsand problems.

Accomplishment An explanation of how the work was done and how theproject proceeded.

Results Describes the outcome of the practical work.

Conclusions What have I learned? Could I have done things otherwise?

Acknowledgments Credit to people who have been of great help during thisthesis.

1

2 Chapter 1. Introduction

Chapter 2

Problem Description

The Burlin Group has outsourced their IT section to a company named Exait.Exait’s main office is located in Pitea but they have departments in LuleaSkelleftea and Stockholm as well. Burlin Motor Umea has their main serverin Skelleftea in Exait’s care. The plan was to implement a Java server and aMicrosoft SQL database on that server and install Java client applications onBurlin Motor Umea’s computers here in Umea.

2.1 Problem Statement

The focus of this project was to implement a prototype software application,which handles Burlin Motor Umea’s customer tire storage.

I had free hands in deciding programming language, system design andappearance (GUI). The only criteria regarding the actual system design wasthat it would be developed to run in WinXP and that the storage should beable to be reached from any computer within the intranet at Burlin MotorUmea i.e. it was to be a distributed system.

2.2 Methods

The project was mainly divided into five steps. Gathering information andrequirements, system design / programming language, GUI, implementationand report writing. Of course the steps were somewhat overlapping so problemsfaced during higher steps resulted in stepping down to overlook the wholeproject and make suitable changes[6].

The gathering of information and requirements was mainly done with in-terviews with staff at Burlin Motor Umea conversations with my supervisorJerry Eriksson and with P-O Ostberg at CS-UmU. I also had some contactwith Exait in the beginning of the project to establish what kind of softwarethat was available on the main server.

3

4 Chapter 2. Problem Description

The second step was to design the system and choosing platform. Re-garding the system design, I initially had two different strategies. One was aclient/server solution in Java or C++ and the other was a web-based solutionwith JSP and Apache TomCat. After discussing these two designs with BurlinMotor Umea it became obvious they did not want a web-based solution andthus it was settled to be a client/server solution.

In the process of deciding programming language, I narrowed down thechoices to Java or C++. Although I was very close to go with any of Microsoft’sVisual languages. In the end, I decided to go with Java. Both because it isplatform independent and because I felt most familiar with it. Because it hasbeen almost six years since I programmed on a regular basis as a student, Ireckoned that I should go with the language I felt most comfortable with.

The third step consisted of designing the GUI[5]. The design should beeasy to understand and easy to use. Because some of the staff in the workshopwill only use this program when it is time for the annual tire changing seasons,it could take up to 6 months between usage. Therefore, the GUI should beintuitive and straightforward.

The implementation step consisted of different smaller steps such as set-ting up a SQL database, implementing the server and client applications anddesigning the GUI. On two occasions, I visited Burlin Motor Umea showedmy work, and took in feedback so I knew I was on the right track regardingboth the implemented functions and the GUI. The tools I used1 to develop thisproject were Java NetBeans 6.8, JCreator LE 4.5, Jasc Paintshop Pro 7, ZebraSetup Utilities, ZebraDesigner and MySQL Server 5.1. All software tools usedwere free or bought at a previous occasion.

Writing the report was done continuously throughout the whole projectboth in a work diary and on an online blog[1]. The blog’s purpose was mainlyan easy way to keep diary of my work progress and to display my work forthose of interest .

2.3 Goals

The main goal was to have a fully working and stable application with all theextra functions working as well. However, it quickly came apparent that thismight not be doable within 10 weeks. Therefore I divided the goal into twosteps, must-have and optional. Step one was to have a basic storage solutionready with the most important functions available. Step two was to have allextra functions working, or at least as many functions as possible.

1Java NetBeans and JCreator to implement GUI and server, Paintshop for designinglogotypes and images, Zebra software for installing the label printer and for designing theprinter labels. MySQL is the database used in this project.

2.4. Purposes 5

2.3.1 Step one: Must-have

The most fundamental requirements was to have a working application withfull database support and basic functions as ”Create new customer”, ”Update”,”Delete” and search functions for registration number and storage location. Acomplete list of the basic functions is shown below.

– Search on registration number or storage location.

– Print tire labels.

– View current customers in storage.

– Create, update and delete customers.

– Sign and log changes in customer information.

2.3.2 Step two: Optional

The optional requirements were sorted out together with Burlin Motor Umeaand not necessary to manage the tire storage.

– Add pictures of tires and rims.

– Print worksheet and customer receipt.

– Print warehouse.

– View list of available storage spaces (almost the same as viewing storage).

– Check for bad tires (tire pattern less than 3 mm) and produce a list ofthese customers.

– Manage database GUI (monitor, see section 3.3.5).

2.4 Purposes

The purpose of this application is to make available an easy way to manageand overlook Burlin Motor Umea’s customer tire storage. For the salespersonsit will be a lot easier to log on to the storage application and retrieve picturesof a specific car’s tires and rims and show them to a customer on the computerscreen. Instead of finding the guy with the keys, physically walk the customerout to the warehouse, unlock the doors, find the tires, climb up and get allfour tires (winter or summer tires depending on season) and show them to thecustomer, put the tires back, lock up and go back into the store.

There also is a major time gain for the workers in the recondition depart-ment who are responsible for the keys to the actual tire storage. As it is now,one of the two reconditioning men must, for safety reasons, follow the salesper-son and customer to the storage, unlock and lock the storage. Every time the

6 Chapter 2. Problem Description

reconditioning men must leave their work to show tires for customers, they loseabout 15 minutes of work. Since the customer always comes first, this couldbe in lunchtime or any other unsuitable moment.

2.5 Related Work

There are mainly two big competitors out on the market regarding tire storagesolutions.

– Hjulius c© by Formac AB

– Kobra II c© by Fordonsdata.

Burlin Motor Umea has used Hjulius c© in the last years but is not com-pletely satisfied with the software. Mainly because there is no network supportin the version they are using. Formac has released newer versions, which of-fers better usability, but the price tag and the former version’s letdowns is adisadvantage.

Kobra II c© is widely used among car companies and is a wide system forhandling all kinds of things. Like billing, spare parts, workshop bookings andmore. Fordonsdata has recently released a module for handling tire storage totheir Kobra II c© system. One of Fordonsdatas main advantages is that BurlinMotor Umea is already using their Kobra II c© system in a wide extent. Theirmain disadvantage is the price tag.

Chapter 3

Accomplishment

The following chapter describes the methods used, design paths and implemen-tation strategies to accomplish this project[6].

3.1 Method

The development phase of this project was quite similar to the method de-scribed in section 2.2.

1. Gather requirements and information. Conversations with Burlin MotorUmea, Exait and my supervisor to narrow down the project into what re-alistically could be done in 10 weeks. Sorting out must-have and optionalgoals.

2. Defining the system design and choosing programming language based onmy own programming skill, estimated learning curve, estimated difficultyand of course the 10 week time limit.

3. Installing necessary software.

4. Implement client, client GUI, server, monitor and database prototypes.

5. Evaluate and analyze prototype.

6. In case of problems and things not thought of, loop back to point 4 andpossibly re-think system design.

7. Finalize application.

3.2 Design

The system design of the client-server-database communication is shown infigure 3.1 below[4]. The client sends upon startup a connection request to

7

8 Chapter 3. Accomplishment

the server. If the connection is accepted, the server sends a connection OKmessage to the client and adds the client to the client list. When the clientsends a question, the server handles it and tries to connect to the database[3]. Ifa connection was successfully made, a query is sent to the database. The serverhandles the database result and if it was a successful query, an OK message issent to the client along with the desired information. The client then handlesthis information and displays it. Upon an unsuccessful connection or query tothe database, the server sends a NOK message to the client, which then takesthe appropriate action.

Figure 3.1: System design of client-server-database communication

The same design applies to the monitor-server-database communication.

3.2.1 Server

The server was designed as a multi threaded server[3] (figure 3.2).

Figure 3.2: The server threading design

This design was chosen to let the server’s main thread and listener thread

3.3. Implementation 9

spend as much time possible listening for incoming connections instead of han-dling the communication issues[5].

3.2.2 Client

The client threading design is very simple (figure 3.3). The main GUI startsupon a successful connection to the server a listener thread which handlesincoming and outgoing communication[3].

Figure 3.3: The clients threading design

3.3 Implementation

All work on implementing this application has been done in my own homeoffice, were I set up a small home network similar to the intranet at BurlinMotor Umea. The label printer was installed on one computer, the server anddatabase on a second computer and the client on a third computer.

3.3.1 Database

The database installed on Burlin Motor Umeas server in Exait’s care is Mi-crosoft SQL Server. However, to be able to do all the programming at home Iinstalled MySQL, which is very easy to manage. Thus, the application at thispoint is for use with MySQL although it can easily be converted to MS SQL.

The database design is quite simple and consists of only one table, whichholds all customer information. The primary key is the storage location andthe registration number of the customer’s vehicle is a unique identifier. Thismakes it impossible to accidentally have two customers stored in one storagelocation. It also makes it impossible to have duplicate entries for one customer,as the customer number is the registration number of the customer’s vehicle.

3.3.2 Server

The server is threaded and consists of a main thread that starts a new thread forincoming client connections and then listens for incoming monitor connections.The client listener holds a client list and upon a successful connection with aclient, it adds the client to the list and starts a new client handler thread for


handling this client. When the client disconnects or the connection is lost, theclient is removed from the list and the client handler thread is terminated[2].

The main thread, after it started the client listener thread, is now listeningfor incoming monitor connections. A monitor connection is handled the sameas a client connection and starts a new monitor handler thread. A monitor isa GUI, which is used to monitor the server’s communication with clients anddatabase. Also, it can be extended to manage the database but this has notyet been implemented.

3.3.3 Client

The client was mainly built in NetBeans as a desktop application, which wasa great time saver. Designing GUI’s in NetBeans turned out to be a lot eas-ier than I thought as there is pre-built event-handlers for almost everything.The design of the GUI changed somewhat during the implementation of morefunctions.

The client application itself consists of a main thread that starts the GUI.When a connection is made to the server, it starts up a new thread that handlesthe communication with the server.

3.3.4 The customer object

The main things passed from server to client are customer objects. The cus-tomer object holds all information for a specific customer such as registrationnumber, storage location, image locations and more. A customer object iscreated when the user creates a new customer (figure 4.11). Upon creation,all entered information and images in the new customer window are insertedinto a customer object and sent via an ObjectStream to the server. The serverparses out images, creates a log file, and stores them on disc. Then the serversends the rest of the customer’s information along with the paths to the savedimages and log file to the database for storage.

When the client sends a request for a specific customer’s information, theserver queries the database for that customer. The returned information (ifthe customer was found) is inserted into a customer object. Images and thelog file are retrieved from their physical disc location and inserted into thecustomer object. If all went well the customer object is sent to the client viaan ObjectStream. The client displays the customer object for the user.

The customer object can be seen in appendix A

3.3.5 Monitor

The monitor is a GUI that allows for example an administrator to monitor theevents occurring in the server. The administrator can then see all communi-cation and message handling. This is very useful for debugging and as futurework, it can easily be extended to manage the database and server.

3.3. Implementation 11

3.3.6 Label printer

The label printer to be used with this application was a Zebra TLP-2844 fromZebra Technologies Corporation. Drives and manuals were downloaded fromtheir website together with a design tool and a setup utility. Since the printerdid not support network printing, the simplest way to be able to print fromdifferent computers was to install the printer on one computer and then sharethe printer over the network.

The labels were to contain mainly two things, the storage location and thecustomer’s registration number. In addition, I added the current date so youcan tell witch date the tires were stored

Chapter 4

Results

4.1 Client

4.1.1 Main window

The main window looks as shown below in figure 4.1. The idea was to make itintuitive and straightforward. All of the functions for daily use can be reachedwithout accessing the menu.

Figure 4.1: Main client window

13

14 Chapter 4. Results

The menu (figure 4.2) holds some more functions that are not used veryoften, like different printing options. It also holds some of the most basicfunctions as create new customer. Below is a list of the menus different options.

Figure 4.2: The menu layout in the main client window.

– ”Anslut” - Connect to the server.

– ”Koppla fran” - Disconnect from the server.

– ”Ny kund” - Create a new customer. Pops up a new window.

– ”Skriv ut...” - Sub menu for printing functions.

• ”Etiketter” - Prints tire labels for the current customer on the labelprinter.

• ”Arbetsunderlag” - (Not implemented) Prints worksheet for work-shop personnel when its time for example a tire change.

• ”Kundkvitto” - (Not implemented) Prints a receipt for the customerupon changing of tires.

• ”Hela lagret” - (Not implemented) Prints out the whole storage withregistration number, storage location and customer info.

– ”Avsluta” - Closes the client application.

4.1.2 Connecting to the server

A dialog that makes it possible to choose connection settings is not yet imple-mented and therefore the connection settings is currently hard coded defaultvalues.

To connect to the server the user either uses the menus ”Anslut” option orsimply clicks any of the buttons in the main window. Since all button eventsrequires that the client is connected they detect the connection status. If theclient is not connected, a pop up window displays (figure 4.3) and asks whetherthe user wants to connect to the server.

4.1. Client 15

Figure 4.3: Connect to server pop up.

Upon a connection attempt from the client, the server either accepts theconnection or refuses it[4]. Upon a successful connection, the client pops up awindow saying the connection was successful (figure 4.4). If no connection wasmade a pop up saying the connection was unsuccessful is shown (figure 4.5).

Figure 4.4: A connection to the server was successfully established

Figure 4.5: Connection to server could not be obtained.

Disconnecting from the server is done either via the menu’s ”Koppla fran”or by simply closing the window, which exits the application, disconnects, closesall threads and cleans up.

4.1.3 Searching

To search for a specific customer’s tires the user simply types in the customerregistration number in the field ”Reg Nr” in the search box up in the rightcorner (figure 4.6) and then clicks on the search button ”Sok”. There is adocument filter wrapped on the text field that converts all typed charactersto uppercase. It also limits the number of typed characters and numbers tosix. This is because a Swedish registration number consists of exactly six


characters (ex ABC123). A function to select a different countries registrationnumber format is yet to be implemented. When the search button is clicked,the registration number is checked if it consists of exactly three letters followedby exactly three digits. If not, there is no search performed. Instead, a blippingsound is heard and the incorrect typed registration number is highlighted.

Figure 4.6: Searching on registration number.

It is also possible to search which customer that holds a specific storagelocation. To do this the user types in the color code of the location in thefield ”Farg” and the number of the location in the field ”Plats” (figure 4.7).These text fields also have document filters wrapped around them allowing onlyuppercase characters in the ”Farg” field and only two characters in the ”Plats”field. Allowing only uppercase characters simplifies searching and comparison.This approach to input was chosen because Burlin Motor Umeas storage isbased on locations that consist of a color and a number like ”GRON 12”.

Figure 4.7: Searching on a storage location.

If the search was successful i.e. there was a matching registration numberor storage location in the database, the client displays the information for thiscustomer in the tab ”Kunduppgifter” (figure 4.8). By clicking on one of thethumbnails, a window pops up and displays a bigger picture of the thumbnailclicked.

4.1.4 Displaying the storage

To display the whole storage in a list the user simply clicks the button ”Visalager” in the ”Alternativ” box located to the right in the main window. The

4.1. Client 17

Figure 4.8: How the customer info is displayed.

storage is then displayed in the tab ”Lager” in the center of the main window(figure 4.9). By double clicking on a customer’s entry in the list, this customer’sinformation is displayed in the ”Kunduppgifter” tab.

Figure 4.9: A list of the current storage.

Also the user can right click a customers entry in the storage list to pop upa quick menu (figure 4.10). The quick menu consists of four entries, which are:

– ”Skriv ut etiketter” - Prints tire labels for this customer (section 4.1.7).

– ”Uppdatera kund” - Brings up the update customer window (section4.1.6).

– ”Uppdatera lager” - Updates the storage listing (not yet implemented).

– ”Ta bort kund” - Deletes this customer (section 4.1.8).


Figure 4.10: The quick menu.

4.1.5 Creating a new customer

Creating a new customer is done by clicking on the button ”Skapa ny kund”.A new window pops up (figure 4.11) and the user simply fills in all the detailsabout the customer. Pictures are added by clicking the buttons in the picturesections of summer and winter tire details, and then selecting the picture tobe inserted in the file chooser dialog that pops up (figure 4.12). A filter onlyshowing pictures is used by default in the file chooser dialog.

Figure 4.11: The window for creating a new customer.

The only things actually required when creating a new customer is regis-tration number, storage color, storage place and a signature. The storage colorand place is chosen by first selecting the storage color and then the storageplace. When choosing storage color the values in the storage place combo boxchanges to the actual numbers available in Burlin Motor Umeas physical stor-age. A function to change these values by for example an administrator is yetto be implemented. Also, a function that only displays the storage locations

4.1. Client 19

Figure 4.12: Add pictures by selecting the picture in the file chooser.

that is not occupied is yet to be implemented.

4.1.6 Updating a customer

To update a customer there has to be a current customer. If there is a currentcustomer, it is shown in the box ”Aktuell kund” (figure 4.13 ) located in thecenter top of the main window. The current customer is set when a successfulsearch on a registration number or on storage location is made. In addition,the current customer is set when the user double clicks on a customer in the”Lager” tab.

Figure 4.13: The current customer.

When the update customer button is clicked a new window pops up (figure4.14). This window is quite similar to the window shown when creating a newcustomer. The only thing that differs is that the registration number and thestorage location are not editable. If the user wants to edit this, creating a newcustomer is advised.

The update window displays all current information about the customer.In order to update the user simply changes the values that is outdated or addsnew pictures. As in the new customer window, the user has to sign the changesbefore clicking the update (”Uppdatera kund”) button located in the lowerright corner.


Figure 4.14: The update customer window

4.1.7 Printing labels

To print labels for a customer there also has to be a current customer selected. Ifso, the user clicks on the button ”Dacketiketter” in the bottom of the customerinformation tab. The client then searches for an installed Zebra TLP-2844printer and if it is found, four labels are printed. One for each tire. A pictureof a printed label is shown below in figure 4.15. Labels can also be printed fromthe storage tab by right clicking on a customer’s entry in the list and choosing”Skriv ut etiketter”.

Figure 4.15: A printed label.

4.1. Client 21

4.1.8 Deleting a customer

To delete a customer the user either uses the quick menu (section 4.1.4) inthe ”Lager” tab or clicks the ”Ta bort kund” button in the bottom of the”Kunduppgifter” tab. When using either of these possibilities to delete a cus-tomer, a pop up displays asking if the user really wants to delete this customer(figure 4.16).

Figure 4.16: Really delete?

If the user clicks yes another pop up shows asking the user to sign the dele-tion of this customer (figure 4.17). This is for security reasons so no customeris accidentally deleted.

Figure 4.17: The user must sign the deletion of a customer.

If a customer was successfully deleted a third pop up displays saying deletionwas a success (figure 4.18).

Figure 4.18: Deletion of a customer was successful

4.1.9 Show log

Each customer has a log file. To view this log file the user clicks the button”Visa logg” in the bottom of the ”Kunduppgifter” tab. The log file for the


current customer is then display in a new window (figure 4.19).

Figure 4.19: Displaying the log file for the current customer.

4.2 Problems

4.2.1 Data passing

The biggest problem I had was how to pass the data in an efficient way. I cameup with the customer object idea at the very beginning but the implementationof the ObjectStreams caused a lot of time spill. It just would not work. Afterseveral hours trying to figure out what was wrong, with the aid of varioussearch sites on the internet, I finally found that the ObjectInputStream mustbe instantiated after the ObjectOutputStream. Before I found this out, I hadalmost made a brand new design for the data passing which took me all toolong.

4.2.2 Handling images

The passing of images back and forth also took some extra time. Since sendingobjects requires that the object to be sent is serializable, it not possible to justadd images to the customer object and then send it through the ObjectStream.This because the Image class is not serializable. To come around this problemI first recreated the picture as a two dimensional integer array list, which isserializable, and then sent it through the ObjectStream and recreated the Imageon the other side. I found this very complicated and the images lost somequality in the process. Then I discovered that the ImageIcon class was in factserializable and the problem was solved. Images can easily be converted toImageIcons and vice versa. Unfortunately, I had already spent a lot of time onthe other solution that set me back a day or two.

Chapter 5

Conclusions

To have free hands regarding system design, programming language etc. turnedout to be a problem rather than an advantage. There are many different waysin designing and implementing an application. Narrowing down which way Ishould follow took a great deal longer than I anticipated and caused quite abit of headache.

To follow the design path I had chosen also proved to be somewhat difficultas problems I had not foreseen forced me to reconsider the design in a fewoccasions.

5.1 Restrictions

There are a few restrictions and the greatest is that the prototype is not fullyworking with all extra functions. I had to skip the print-outs of worksheetand the entire storage. There is also no support for viewing which storagelocations that are not occupied. There is no function for checking for pore tirepatterns and the monitor management is not yet implemented either. Finally,I discovered that when updating a customer’s information I could not changethe pictures of tires and rims. A code related issue and since the adding ofimages was the last function I added, it is not properly bug tested.

5.2 Limitations

The storage is at this point restricted to the actual size of the physical storageat Burlin Motor Umea. However, storing the size of the storage in a .txt fileand allowing the administrator to change these values is not too far away.

The storage is also limited to consist of a color and a place, which may notbe the most optimal solution. However, since the physical storage at BurlinMotor Umea has this solution today, that was the way I decided to implementit.

23

24 Chapter 5. Conclusions

5.3 Thoughts

Overall, I am quite satisfied with the achieved results although I wish I hadbeen able to finish all extra functions and all other ideas I had.

5.4 Future work

I hope that Burlin Motor Umea finds this prototype worth its while and decidesto go with this solution. If so, the first things to do is to perform some seriousbug testing[6], implement all optional requirements and extend the monitor toa management utility for the database and the server.

Chapter 6

Acknowledgments

I would like to thank my supervisor at CS-UmU Jerry Eriksson for making mestart on the thesis report at an early stage and helping me out with whom totalk to with my programming problems.

I would also like to thank P-O Ostberg at CS-UmU for helping me withplatform issues and the system design of this application.

At last, I would like to thank Jan Hellgren at Burlin Motor Umea for thisgreat opportunity to finally do my thesis work and hopefully claim my degreein computer science.

25

26 Chapter 6. Acknowledgments

References

[1] J. Funck. Johan Funcks Blogg. http://johanfunck.blogg.se, 2010.

[2] Tamassia Goodrich. Data Stuctures and Algorithms in JAVA. Wiley, 4thedition, 2005.

[3] Horstmann. Big Java. Wiley, 4rd edition, 2007.

[4] Ross Kurose. Computer Networking - A Top-Down Approach Featuring theInternet. Addison-Wesley, 4th edition, 2008.

[5] Lewis. Java Software Solutions. Addison-Wesley, 2008.

[6] Pfleeger. Software Engineering Theory and Practice. Prentice Hall, 3rdedition, 2006.

27

28 REFERENCES

Appendix A

CustomerObject

public class CustomerObject implements Serializable {

private static final long serialVersionUID = 5884436479064623012L;

// storage info

private String regnr;

private String color;

private int place;

private String carbrand;

private String carmodel;

// customer info

private String name;

private String address;

private String zip;

private String postal;

private String phone;

// summer tire info

private String sTireBrand;

private String sTireDimension;

private String sRimType;

private String sFrontLeft;

private String sFrontRight;

private String sBackLeft;

private String sBackRight;

private String sNote;

private String sRimPicture;

private String sRimThumbPicture;

private String sTirePicture;

private String sTireThumbPicture;

29

30 Chapter A. CustomerObject

// winter tire info

private String wTireBrand;

private String wTireDimension;

private String wRimType;

private String wNail;

private String wFrontLeft;

private String wFrontRight;

private String wBackLeft;

private String wBackRight;

private String wNote;

private String wRimPicture;

private String wRimThumbPicture;

private String wTirePicture;

private String wTireThumbPicture;

// images

private ImageIcon sRimIcon;

private ImageIcon sRimThumbIcon;

private ImageIcon sTireIcon;

private ImageIcon sTireThumbIcon;

private ImageIcon wRimIcon;

private ImageIcon wRimThumbIcon;

private ImageIcon wTireIcon;

private ImageIcon wTireThumbIcon;

// logging

private String sign;

private String logFile;

private byte[] logfileArray;

... getters and setters...

}

distributed database storage solution in javaproject were java netbeans 6.8, jcreator le 4.5, jasc...

Documents