An online sales system

by d105a

Anders Dahl Christian Hertz Kenneth Blanner Holleufer Johnny Jakobsen Rune Mosbk Martin Toft Steen Troldtoft

Signatures

Anders Dahl

Christian Hertz

Kenneth Blanner Holleufer

Johnny Jakobsen

Rune Mosbk

Martin Toft

Steen Troldtoft

Aalborg University
Department of Computer Science ABSTRACT: TITLE: An online sales system SUBJECT: Development of software PROJECT PERIOD: DAT1/INF1 Department of Computer Science September 2 - December 21, 2004 GROUP: d105a STUDENTS: Dat. Kenneth Blanner Holleufer Dat. Johnny Jakobsen Dat. Rune Mosbk Dat. Martin Toft Inf. Anders Dahl Inf. Christian Hertz Inf. Steen Troldtoft INSTRUCTOR: Yin Xuepeng xuepeng@cs.aau.dk COPIES PRINTED: 9 NUMBER OF PAGES: 127 APPENDIX PAGES: 129 - 146 FINISHED: December 21, 2004
This project addresses the development of a sales system. The systems company is not real and we do not have any economic knowledge to back up the presented ideas. However the system is so enhanced that it is able to deal with the companys electronic commerce. The system consists of a web shop where it is possible to order dierent products and a warehouse aid application where it is possible to receive the orders. The web shop part of the system is usability tested and is in the nal state quite user-friendly. We used the OOA&D method to do the analysis and design, and theory from the course in object-oriented programming to write the systems in Java and Java Server Pages. The graphical user interface and the usability test are designed using theory from the DIEB lectures.

Preface
In this semester we had the opportunity to make mixed groups between students of informatics and students of computer science, we took this opportunity and had a very interesting semester working together, sharing knowledge from our dierent study backgrounds. The web shop developed in this project can be found at http://www.conner.dk The included cdrom contains source code for the entire system. It may seem dicult to run the applications, because they need Jakarta Tomcat, MySQL, etc. The source code is only ment for viewing. Additionally, this report is included as Postscript and PDF.

Contents
I Analysis 9

1 The 1.1 1.2 1.3

task 11 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 System denition . . . . . . . . . . . . . . . . . . . . . . . . . 11 14 15 16 17 22 22 23 23 25 29 30 30 30 32 32 33 37

2 Problem domain 2.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 State charts . . . . . . . . . . . . . . . . . . . . . . . . 3 Application domain 3.1 Usage . . . . . . . . . . . . . 3.1.1 Overview . . . . . . . 3.1.2 Actors . . . . . . . . . 3.1.3 Use cases . . . . . . . 3.1.4 Grouping of use cases . 3.2 Functions . . . . . . . . . . . 3.2.1 Function list . . . . . . 3.2.2 Function specication . 3.3 User interface . . . . . . . . . 3.3.1 Interface functionality 3.3.2 Navigation overview . 3.4 Technical platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

II

Design

40

4 The task 42 4.1 Changes for the analysis part . . . . . . . . . . . . . . . . . . 42 4.2 Design criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5

5 Architecture 5.1 Technical platform . . . 5.1.1 Equipment . . . . 5.1.2 System software . 5.1.3 Communication . 5.1.4 Design language . 5.2 Component architecture

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

46 46 46 46 47 47 47 50 50 52 52 53 54 57 58 58 59 60 69 70 70 71 72 72 74 75 76 78 80 81 81

6 Component design 6.1 Components . . . . . . . . . . . 6.2 Model and function component 6.2.1 Model-class placement . 6.2.2 Function-class placement 6.2.3 Function specications . 6.2.4 Summary . . . . . . . .

7 Graphical user interface design and components 7.1 Creating a successful graphical user interface . . . 7.2 Usage of the Gestalt laws . . . . . . . . . . . . . . 7.3 Designing the user interface . . . . . . . . . . . . 7.4 Web shop GUI . . . . . . . . . . . . . . . . . . . 7.4.1 Layout and design . . . . . . . . . . . . . 7.4.2 Dialogue style in the web shop interface . 7.4.3 Frames . . . . . . . . . . . . . . . . . . . . 7.5 Warehouse GUI . . . . . . . . . . . . . . . . . . . 7.5.1 Layout and design . . . . . . . . . . . . . 7.5.2 Dialogue style in the warehouse interface . 8 Database design 8.1 Entities . . . . . . . . . 8.2 Relationships . . . . . . 8.2.1 First circularity . 8.2.2 Second circularity 8.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

III

Implementation

83

9 System implementation 85 9.1 Class implementation . . . . . . . . . . . . . . . . . . . . . . . 85 9.2 Warehouse server . . . . . . . . . . . . . . . . . . . . . . . . . 86 6

9.3 9.4 9.5 9.6

MySQL . . . . . . . . . . . . Creating the database . . . . Client/server implementation Web server . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

87 88 91 91

10 Clients 93 10.1 Warehouse application . . . . . . . . . . . . . . . . . . . . . . 93 10.2 Web shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

IV

Test

99

11 Implementation test 100 11.1 Class tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 11.2 Functionality tests . . . . . . . . . . . . . . . . . . . . . . . . 100 11.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 12 Usability test 102 12.1 Test result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 12.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . 113

Academic requirements
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

115
116 . 116 . 116 . 117 . 118 . 121 . 122 . 123

13 Academic requirements 13.1 Analysis, design, implementation, and test 13.1.1 Analysis . . . . . . . . . . . . . . . 13.1.2 Design . . . . . . . . . . . . . . . . 13.2 User interface . . . . . . . . . . . . . . . . 13.3 Database design . . . . . . . . . . . . . . . 13.4 Implementation . . . . . . . . . . . . . . . 13.5 Test . . . . . . . . . . . . . . . . . . . . .

VI

Conclusion

125
126

14 Project conclusion

VII

Appendix

128
129 7

A Code test

A.1 Class tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A.2 Functionality tests . . . . . . . . . . . . . . . . . . . . . . . . 131 B Test plan B.1 Problem statement/test objectives . . . . . . . B.2 User prole . . . . . . . . . . . . . . . . . . . B.3 Methodology . . . . . . . . . . . . . . . . . . B.3.1 Greeting and background questionnaire B.3.2 Validation test . . . . . . . . . . . . . B.3.3 Participant debrieng . . . . . . . . . . B.4 Task list . . . . . . . . . . . . . . . . . . . . . B.5 Test environment . . . . . . . . . . . . . . . . B.6 Test monitor role . . . . . . . . . . . . . . . . B.7 Evaluation measures . . . . . . . . . . . . . . B.8 Colors . . . . . . . . . . . . . . . . . . . . . . B.9 Frames . . . . . . . . . . . . . . . . . . . . . . B.10 Font types . . . . . . . . . . . . . . . . . . . . B.11 Gestalt laws . . . . . . . . . . . . . . . . . . . B.12 Dialogue style in user interfaces . . . . . . . . C Database design Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 133 133 133 134 134 134 135 136 136 136 137 138 139 140 141 143 147

Part I Analysis

A trading company needs an online sales system, which automatically interact with a warehouse management system. The company started out on an idea, of oering products to the consumer through the Internet, across the EU. The company concept is that it only sells products through the Internet and therefore saves money on salesmen and shops. As a result, it can oer the customer products at a very competitive price. The company has bought a number of warehouses in some of the countries in the EU. The customer will place an order through the online sales site, where the customers will have the option of ordering a product from many warehouse around EU, to ensure fast delivery a warehouse near by should be selected. The company wants to save money when buying products, and therefore plan to have an eective system to manage orders and their warehouses. The products do not have to be ordered from the main suppliers if the product is available in another warehouse. Products can be exchanged between warehouses and savings can be achieved by buying large amounts of products simultaneously. Last the company wants to be able to update and register products, product information and orders, for customer and administrative usage.

10

Chapter 1 The task

1.1 Purpose

The main objective in this project is to create a computer system that enables a company to sell and administer products. Since the company consists of a number of dierent warehouses spread out in dierent countries, the system must include a website where products from all warehouses are sold, and furthermore an order management that coordinates inventory and orders between the warehouses. This projects focus area will be the product sale and order management. Statistics, payment functionalities and accounting, except for calculating the prices of the ordered products will be excluded.

1.2

Context

We chose to describe the situation through rich pictures. An attempt to draw the problem domain of the situation resulted in the rich picture in gure 1.1. The picture and reections upon it in the group afterwards gave us in-depth insight concerning the system, we were about to develop.

1.3

System denition

To be able to evaluate the system denition, we started out with the FACTOR criteria listed in table 1.1.

11

Figure 1.1: Rich picture of the problem domain Based on the factor criteria the following denition were made. An online sales system, which consists of a web shop and an application for handling orders for numerous warehouses. The web shop will run on any ordinary web browser, where customers can browse through categories and products, and place orders. The web shop furthermore includes a track and trace system, which enables a customer to follow the progress of his/her orders. The application for the warehouses enables the warehouse employees to process orders simple and ecient. The system will automatically keeps track of orders and products in the warehouses, and noties when product counts are running low.

12

F A C

Functionality Application domain Conditions

Product and customer registration, order management, Internet sale Warehouse employees and customers shopping online We will carry out the system development. We have some knowledge about system development and expect to learn more in this semester. The warehouse employee has basic knowledge about computers. The website customer will have a very varying degree of computer knowledge. The warehouse client will be written in Java. The website will be made primarily in JSP. The website will be viewable using Mozilla Firefox 1.0, Internet Explorer 6.0, and most other graphical browsers. The warehouse client will be able to run on a standard computer with has Java. The website will be hosted by a web server with a JSP engine and Java. The warehouse server will require Java and a JDBC driver. All computers will require a network connection. Products, orders, customers, warehouse, invoice and employees A warehouse administration and Internet sales system

Technology

O R

Objects Responsibility

Table 1.1: FACTOR criteria

13

Chapter 2 Problem domain

The system will handle the customer orders that contains information about products, the customer, the employee and the warehouse. The registered product information, includes technical specication and price. The customer information, is their personal data which are used for order handling. An order can be processed by multiple employees, but only one employee can nish an order, therefore information about this employee must be obtained for future order support. Based on the list of classes and the event table shown in table 2.1, we choose to show the structural relations between the classes in the diagram at gure 2.1.

Figure 2.1: Class diagram

14

2.1

Classes

In this section we will focus on identifying the basic building blocks of our model of the problem domain. We will nd and describe the needed classes and events, and in the end structure them in a class diagram, which is shown at gure 2.1. Customer: A customer is an user of the system and is represented in the customer class. The class represents the user by registering personal data, such as name, address, etc. a customer is associated with the order class with an one-to-many relation, since a customer can place several orders and an order must have exactly one customer. Order: An order is created when a customer starts adding products. The order is a collection of products, a warehouse and a customer. It has the ability to store the information about delivery and current state for the order, so the customer can follow the order through a track and trace service. The order class is the most central class in the system and is therefore associated with several of the other classes. Employee: An employee is a common class for all the people working at the company. The role of the people, such as warehouse worker, secretary, etc., are ignored, so the employee class is the same for every employee. The class only registers name for the employee and is only associated with the order class. Warehouse: The warehouse is where we keep our products. New products purchased are added to the warehouse and the product quantity is set, and when products are ordered by the customer the product count is decreased. The warehouse class is mainly used for maintaining the quantity of products and storing information about a warehouse such as location and contact information. The warehouse is associated with the order class with a zeroto-many relation, since a warehouse can have several orders, but also exist without having any orders to process. However an order can only be assigned to a single warehouse. Product: The product class is the type of the product, which means we register name of a certain vendor and model, however the specic product with a certain registration number is not of relevance. The class describes the information about the product such as name, model, price, etc. The product class is an aggregation of the warehouse class, with a zero-to-many relation. 15

This means a warehouse can exist without having to contain any products, but also that a product can exist without being added to a warehouse. This enables the company to add new products to the system, without necessarily adding the products to the online shop. Invoice: The invoice class is like an order class, except it also registers, which of the employees handled the order.

2.2

Events

A brainstorm gave us a lot of possible events for the system, which we systematically evaluated and either discarded or added to the event table shown at table 2.1. The state charts in section 2.2.1 also added a few additional events, which had not been thought of during the brainstorm.
Customer Customer registered Customer removed Customer changed Product added to order Product removed from order Order placed Employee registered Employee removed Processing started Order closed Invoice deleted Product registered Product removed Product received Warehouse registered Warehouse removed Order Employee Warehouse Product Invoice

+ + * * * *

* * + + + * * *

* * *

+ +

* + + + +

* +

* * * + + Event can occur zero to many times Event can occur zero to one time Table 2.1: Event table

16

2.2.1

State charts

Based on the event table in section 2.2, we will make state charts for the classes. These state charts will help us identify the states the classes can take. The state charts are followed by a description of a general course and a list of attributes. Customer

Figure 2.2: State chart diagram for customer General course: The customer registers in the system Customer login on the web shop The customer adds products to an order Customer accepts the order The customer logout or leaves the web shop

Order General course: Products are added to order Order is placed 17

Attribute Name Address E-mail Phone number Country City Postal code User name Password

Description Name of the customer Address for the customer A valid e-mail to contact the customer Phone number to contact the customer The country where the customer lives City the customer lives in Postal code for the city The username for the customers website account The password for the customers website account

Table 2.2: Attributes for customer

Figure 2.3: State chart diagram for order Order pending in warehouse Order processed by employee Order gets closed

Employee General course: Employee gets hired Employee is handling tasks Employee gets red

18

Attribute Product list Customer Delivery country Delivery city Delivery postal code Delivery address Shipping date Creation date Warehouse

Description List of the products added to the order An associated customer Optional country used for delivery Optional city used for delivery Optional postal code used for delivery Optional address used for delivery The date the order got shipped from the warehouse The date the order was created The designated warehouse where the order will be processed

Table 2.3: Attributes for order

Figure 2.4: State chart diagram for employee Warehouse General course: A warehouse gets added to the system Products are added and removed from the warehouse The warehouse is removed from the system Product General course: Product added Product removed 19

Attribute Name

Description Name of the employee

Table 2.4: Attributes for employee

Figure 2.5: State chart diagram for warehouse Invoice General course: Invoice is created when order is closed Invoice is kept for a certain period Invoice gets deleted

20

Attribute Name Country City Address Postal code E-mail Product count Minimum product count

Description Name for the warehouse Country where the warehouse is placed City for the warehouse Address for the warehouse Postal code for the warehouse E-mail to contact warehouse The quantity for each type of products Minimum product count before a signal is sent

Table 2.5: Attributes for warehouse

Figure 2.6: State chart diagram for product type

Attribute Name Model Type Vendor Description Price Picture Description Name of the product Model of the product The type of the product Vendor of the product Description of the product The price the customers are paying The product picture

Table 2.6: Attributes for product

Figure 2.7: State chart diagram for invoice

Attribute Order Employee Description A closed order The employee who handled the order

Table 2.7: Attributes for invoice 21

Chapter 3 Application domain

The application domain can be divided in to two smaller domains. The warehouse facility and the sales site. In the warehouse facility the system will support work assignments carried out by warehouse employees, who are working with processing the orders. This includes packing and shipping products and making sure that no other employee are working on the same order. The warehouse employees reads the needed order information and packs the products. Then an invoice containing the customer information is printed out, and the order is shipped. Another work assignment is registering product and warehouse information. The product information is sent by mail or e-mail to the warehouse by its suppliers and then registered into the system. The primary purpose of the sales site is to sell products and pass created orders to the warehouse facility. In this section we will give a total description of the systems usage, functions and interfaces.

3.1

Usage

The system has three actors, the customer, warehouse employee, and a warehouse secretary. The customers can use the system to register themselves, order products and later on follow the orders via the track & trace service. The system automatically informs the warehouses about new orders, where the employees have the ability to process the orders. Automatically the system also monitors the warehouses to make sure the product quantity is not running low. The secretarys job is to update information about warehouses, products and warehouse employees. 22

3.1.1

Overview

To gain an overview of the actors and use cases, which are involved in the interaction, we have constructed an actor table as shown in table 3.1.
Customer Update warehouse list Update product list Update employee list Update product quantity Login Logout Create account Change account information Update products on order Search products Place order View order status Request products Process order Finish order X X X X X X X X X X X X X Warehouse worker Warehouse secretary X X X X X X

Table 3.1: Actor table for the system, the actors are listed in the columns and the use cases in the rows

3.1.2

Actors

List of actors: Customer Warehouse worker Warehouse Secretary Customer Purpose: A person who visits the web page, and optionally registers and purchase products. The need of this actor group is to nd products, add products to an order and nally place the order.

23

Characteristic: The Customer group includes many dierent types of people. The target group vary depending of what will be sold in the web shop. Example: Person B has used a computer for many years now. B is delighted to get an opportunity to buy the product B wants, without leaving the house. B has never had any signicant problems with understanding the possibility the system provides. B is technologically curious, and will explored all of the systems possibilities. Person C is a technical novice, with no real experience with computers, let alone online shopping. As a result C is insecure and will quickly purchase the desired product and then log of the system again. C only purchase product online because he sometimes can get a product cheaper than in a shop. Warehouse worker Purpose: A person who is working at the warehouse and processing the customers orders. The warehouse worker must have access to copies of the customers orders, and will mark the job they are currently working with. Finally he will mark the order as shipped. Characteristic: The Warehouse worker, has little or no higher education, and only has a limited knowledge of IT. Example: Warehouse worker A is reluctant about using computers in his work, because he is in the habit of working with pen and paper. The Warehouse worker typically prints out the customers order before processing it. Warehouse Secretary Purpose: A person who registers and updates a warehouses database. The secretary needs a well arranged work area, which supports a fast and eective work routine. Characteristic: The actor has basic training in the use of the system, otherwise they are often moderate IT users. Example: Person D registers information in the database. D knows exactly how to register and update data elds with the computer system; it has become a routine work assignment. D uses as little time as possible on this assignment, but knows that the data must be correct, otherwise the data 24

eld must be located and corrected, later which can be time consuming.

3.1.3

Use cases

List of use cases: Update warehouse list Update product list Update employee list Update product quantity Create account Login Logout Change account information Update products on order Search products Place order View order status Request products Process order Finish order In the following we describe each use case. For each use case we have marked the objects and functions, which are involved. The functions are listed in section 3.2 and described in section 3.3. 25

Update warehouse list Pattern: Update warehouse list is initialized by the warehouse secretary. The use case is initialized when a new warehouse need to be added to the system or when an old warehouse needs to be removed. The information about the warehouse must be entered manually by the warehouse secretary and afterwards it is stored for further use. Objects: Warehouse secretary. Functions: addWarehouse, removeWarehouse. Update product list Pattern: Update product list is initialized by the warehouse secretary. This occur when products needs to be added to the system or when existing products needs to be removed. Products added to the system is not available on the website before the product quantity is set. Objects: Warehouse secretary. Functions: addProduct, removeProduct. Update employee list Pattern: Update employee list is initialized by the warehouse secretary, when a new employee needs to be added to the system or an old one removed. Objects: Warehouse secretary. Functions: addEmployee, removeEmployee. Update product quantity Pattern: Update product quantity is initialized when products added to the system needs to be available on the web shop. This use case is also used when new products arrive to a warehouse and the product count needs to be changed. It is the warehouse secretarys job to update the necessary information when needed. Indirectly the customer also uses update product quantity use case. When a customer places an order the system decreases the product count, to make sure the number of available products in the web shop is correct. Objects: Warehouse secretary, Customer. Functions: updateProductQuantity, placeOrder. 26

Create account Pattern: Create account use case is initialized by the customer, when he/she wants to register as a customer in the web shop. It is required to have an account in order to buy products from the web shop and when a new customer account have been created, the customer have to login before he/she can place an order. Objects: Customer. Functions: createAccount. Login Pattern: Login is used by the customer, when the customer have an account for the web shop and intends to place an order. The warehouse secretary also uses login to enter the administration area of the system. The actor, types in an username and password, which will be validated by the system. Objects: Customer, Warehouse secretary. Functions: login. Logout Pattern: Logout is used by the customer and warehouse secretary, and can only be used when a customer or warehouse secretary is already logged in. Objects: Customer, Warehouse secretary. Functions: logout. Change account information Pattern: Change account information is initialized by the customer, when a customer have changed some personal information. This could be the reason if a customer have got a new phone number, e-mail or have changed address. Objects: Customer. Functions: updateCustomer. Update products on order Pattern: Update products on order is used by the customer when he/she wants to buy a product. The use case for update products on order is also used when a customer wants to remove a product from an order, but it can only be done as long as an order has not been placed yet. 27

Objects: Customer. Functions: addProductToOrder, removeProductFromOrder. Search products Pattern: Search products is initialized by the customer when the customer is trying to locate a specic product. The customer can nd the information by searching on a part of the stored information. If the system nd a match it will send it back to the customer, if not it will inform the customer that there were no match found in the system. Objects: Customer. Functions: searchProduct. Place order Pattern: The place order use case is started when the customer has nished adding products to his/her order on the website, and wish to place the order at a warehouse. The system asks the customer to select a warehouse where he/she wish to order from. If the customer has not selected a specic warehouse, the system will try to locate the best warehouse, either by trying to nd a warehouse that can handle the order by itself, or move the needed products between the warehouses. If the customer have chosen a warehouse, which can not handle the order the system will try to move products from other warehouses to the selected warehouse. The customer will get an estimated shipping date and will get the option of placing the order, or alter it. If the customer chooses to alter the order, the customer will then be directed to a page where he/she can add, remove products or choose a new warehouse to handle the order. If the customer chooses to send the order, the system will create the order at the chosen warehouse and notify involved warehouses, and send an order conrmation back to the customer by email. Objects: Customer Functions: placeOrder. View order status Pattern: View order status is initialized by the customer, when the customer wants to view his or her orders. When used all orders placed within a short period will be shown with details about products and price. Another actor is the warehouse worker, who will be able to see orders, which is pending or being processed. Objects: Customer, Warehouse worker. Functions: showOrders. 28

Request products Pattern: Request products is initialized by the warehouse worker. When the warehouse worker needs a product for an order, which is not available in the warehouse, the warehouse worker can request another warehouse to send the product. Objects: Warehouse worker. Functions: requestProductFromWarehouse. Process order Pattern: The process order is initialized by the warehouse worker. The warehouse worker marks that order, to inform other warehouse workers, that the order is being processed. Objects: Warehouse worker. Functions: processOrder. Finish order Pattern: Finish order is used by the warehouse worker after the product has been packed and shipped out. The Warehouse worker informs the system that the work is done and at last the system prints out an invoice. Objects: Warehouse worker. Functions: closeOrder.

3.1.4

Grouping of use cases

The use cases in section 3.1.3 describes all use cases for every actor in the system. However the actors work in dierent domains, so the use cases have to be put into groups in order to specify what functionality is needed in each domain. The customer will probably be sitting at home and using a web browser, while the warehouse worker and secretary will be in a warehouse and using an application to interact with the system. The grouping of the use cases is shown in gure 3.1. It shows that the customer takes part in all the use cases in the web shop, and the warehouse secretary and warehouse worker take part in each their use cases in the warehouse application. We could have chosen to make a web page where the warehouse worker and the warehouse secretary could login and do their tasks; however for security reasons it seemed more convenient to separate them. So despite having a web shop, we also create a warehouse application. 29

Figure 3.1: Grouping of use cases

3.2

Functions

This section describes the functionality of the system.

3.2.1

Function list

Table 3.2 is a function list of the functions identied in the use-cases. It is not a complete list of all functions, but it shows the most important functions to implement the system.

3.2.2

Function specication

Most of the functions are self-explained by their names, as we only have one complex function. However the place order function need clarication. A more detailed list of demands for the function is shown in table 3.3. 30

Function Add warehouse Remove warehouse Add product Remove product Add employee Remove employee Update product quantity Create account Login Logout Update customer Add product to order Remove product from order Search product Place order Show orders Request product from warehouse Process order Close order

Complexity Simple Simple Simple Simple Simple Simple Simple Medium Simple Simple Medium Simple Medium Medium Complex Simple Medium Simple Medium

Type Update Update Update Update Update Update Update Update Update Update Update Update Update Read Update Read Update Update Update

Table 3.2: Function table

Place order

If a warehouse is not chosen manually, this function nds the warehouse, which is estimated to handle the order fastest. The order is stored and the selected warehouse is informed about the new order. Afterwards the products on the order are decreased from the product count in the warehouse. After that the functions checks if the product count is still above the minimum limit, else the warehouse is informed. At last the function generates and returns an invoice. Input: An order placed by a customer in the web shop. Output: An invoice for the order given as input.

31

Function Place order Finds appropriate warehouse Store the order Decrease the warehouses product quantity Inform warehouse about the new order Inform if the minimum product count is reached Prints an invoice

Complexity Complex Complex Simple Simple Medium Medium Simple

Type Update Calculate Update Update Signal Signal Read

Table 3.3: Demands for the placeOrder function

3.3

User interface

Based on the previous chapters it is noticed that we have two basic system interfaces, the warehouse employee interface and customer web shop interface. The two interfaces have dierent functionality requirements in order to substantiate the users needs.

3.3.1

Interface functionality

The required functionality of the interfaces is described below. Functionality in warehouse application Login and logout Add and remove warehouse Add and remove employees Add, remove products Change product count Request product from warehouse Order processing Print order Finish order (when packed and shipped) 32

Functionality in web shop Login and logout Find products Add products to order Remove products from order Create new customer Update personal information Place order Print invoice Show previous orders (track and trace)

3.3.2

Navigation overview

We have illustrated an overview of the navigation for the warehouse and web shop in gure 3.2 and gure 3.5 Warehouse Navigation The elements in the gure 3.2 shows how the user can navigate from the main window and around in the system.

Figure 3.2: Navigation diagram for the warehouse GUI 33

Examples of warehouse interface

A few examples of the interface design for the warehouse.

Figure 3.3: Warehouse interface 1 34

Figure 3.4: Warehouse interface 2

Web shop navigation

The web shop element in gure 3.5 is the start page, which have 3 frames, where the main page frame is the product catalogue by default. The rest of the elements in the gure shows how the page change in the main page frame, when navigating around in the web shop.

35

Figure 3.5: Navigation diagram for the web shop. The lines of direction marked with (*) shows that you must be logged in to go there. The lines of direction marked with (**) shows that you must be have products in shopping cart to go there

Examples of web shop interface A few examples of the interface design for the web shop.

Figure 3.6: Web interface 1 36

Figure 3.7: Web interface 2

Figure 3.8: Web interface 3

3.4

Technical platform

The object-oriented analysis and design method (OOA&D) that we are using for this project, will be accompanied by corresponding, object-oriented programming. The abstract classes and events presented through part 1 will be claried into specic classes and methods in the design part of this report, part 2 that follows the analysis part.

37

The users of our web shop do not have to install the Java Runtime Environment on their personal computer, because the web shop will be distributed to the user as HTML1 . The web shop will run as Java Server Pages, JSP, on a web server. These JSP pages will communicate with a Java application running at a database server, i.e. another physical computer. The Java application runs on top of a database service that contains personal information about registered users and information about all products. At every warehouse there is a computer running a Java application which enables the employees to browse and manage orders from the web shop. This application communicates with the application running on the database server. The general structure is illustrated at gure 3.9.
Web Browser Java Server Pages (JSP) Web Server Layer (Java Servlet Application) Web Server Database Layer (Java Application) Database Management System (DBMS) Operating System Warehouse Application (Java Application) Operating System

Operating System

User Computer

Operating System

Warehouse Computer

Web Server

Database Server

Figure 3.9: Technical platform We will implement the system using Java, because we were taught Java in OOP, an object-oriented programming course at the DAT1 and INF1 semester. One of the advantages with Java is that it is almost architecture independence, i.e. our programs will run on every operating system that supports Java. Figure 3.9 illustrates the web server and database server as separated entities, but it is actually possible to combine their services onto one computer. However, the separation can be useful when dealing with security issues such as DoS2 attacks. The database service will be a relational database system, but from an objectoriented point of view it is not important whether the database system is Ingres, Oracle, or another product. [6] Information is organized into several tables, and SQL3 is used to manipulate the tables. On behalf of the user, the
1 2

HyperText Markup Language Denial of Service 3 Structured Query Language

38

Java Server Pages running on the web server will query the Java Application on the database server, which then query the database service. We want the system to automatically inform warehouses when orders is placed, which is the reason why we do not let the Java Server Pages at the web server and the Java application at the warehouse computer to directly query the database service at the database server. The Java application on top of the database service acts as a middleman and also limits access to specic parts of the database for each client. This gives a little extra security to the database if the web server should be hacked.

39

Part II Design

40

According to the chosen method, the purpose of the design part is to create a coherent representation of the system design. Design criteria for the system will be pointed out, where after the system will be structured into components. The design of the components is meant for specifying a exible and understandable structure, that will ease the implementation. The classes for the components will be specied and there will be created a diagram for the model and function component, with all classes including their attributes and operations. The GUI component is created from various methods including the wisdom method. Design criteria for the graphical user interface is created and a GUI is made according to rules for GUI design. To make data persistent in our system, information will be saved in a database. Based on the model component presented later, an entity-relationship diagram will be constructed. This ER-digram will then be basis for databases structure. The classes from the model component will correspond to the entities in the ER-diagram; however, they will not be exactly equal.

41

Chapter 4 The task

The task is to propose the conditions for the design of the system.

4.1

Changes for the analysis part

Even though we in section 3.1.2 on page 23 have shown, that we have two actors with quite dierent use cases, we will still use the same class called employee for both of them, since they still have the same attributes. The invoice class in the class diagram on page 14 will be removed from the class diagram as we can use the order class for same purpose. The reason for this, is that we have added the processedBy attribute to the order class, which was the only dierence between an order and an invoice.

4.2

Design criteria

In this section we determine some design criteria for the quality of the system. A few design criteria where pointed out to be more important than the rest. These criteria is meant to reect some of the specic conditions for the design of the system. The tables 4.1 and 4.2 shows the design criteria for the web shop and the warehouse application with each their order of priority. 42

Criteria Usable Secure Ecient Correct Reliable Maintainable Testable Flexible Comprehensible Reusable Portable Interoperable

Very important X

Important

Less important

Irrelevant

Easily fullled

X X X X X X X X X X X

Table 4.1: Prioritized design criteria for the web shop application Criteria description for web shop table 4.1 The web shop will be designed with a graphical interface which is fast and easy for the user to use The security of the web shop is important. The web server will handle the basic security, and in the implementation the right connections between the user and the system will be designed The eciency of the web shop is very important. The web shop will possibly face the job of handling several customers at a given time and all delays are annoying. We certainly do not want customers to leave the web shop because of slow performance The web shop will get product and warehouse data from the server. It is very important that this information is correct. However minor concurrency problems can eect that the information is not 100 percent correct, if the customer does not refresh the web page Reliability is important. The user should not be bothered with connection losses and timeouts from the server Maintenance is easy fullled when all the web shops data is retrieved from the server 43

 Functionality tests during development and user tests will be made. Testable is marked less important since no special applications or classes are made The applications exibility is marked as less important Comprehensive is marked as very important since the users will leave and choose another place to shop, if the information is in comprehensive The reusable criteria is marked as less important, since most of the web shop is dynamic. A few static pages exist such as company prole and contact page The portable criteria is important. It is dicult to make the web page look the same in all screen resolutions and also make it independent of having scripting languages enabled The web shop will not communicate with systems or applications other than the server, so interoperability is irrelevant

Criteria Usable Secure Ecient Correct Reliable Maintainable Testable Flexible Comprehensible Reusable Portable Interoperable

Very important X

Important

Less important

Irrelevant

Easily fullled

X X X X X X X X X X X

Table 4.2: Prioritized design criteria for the warehouse application Criteria description for warehouse application table 4.2 The application should be fast and easy to use by the employees 44

 The security of the application is marked as less important. The basic security will be managed by the operating system and the database server. No time and eort will be used on making special classes or programs to manage the application security The eciency of the application is important. With little or no delay it should help the employee in the assigned work area The application will handle data coming from the web shop and other warehouse applications through the server. Eorts will be made to ensure that the data in the system are correct at all times Reliability is important. The application will be made so it can function even though the web shop or other warehouse application clients are down Maintenance is easy fullled. The application will be designed to dynamically get all the information from a server Errors that might be in our application can easily be found by an user. The testable criteria is marked as important and tests under and after development will be made The applications exibility is marked as very important. It will be obtained through the objected oriented design, that will allow functionality to be added or removed easily Comprehensive is marked as very important because, there should be no doubt about how an employee should use the application for a given task The reusable criteria is marked as less important, but since the application is build object oriented, will it be possible to reuse parts of the application The application will not communicate with other systems or applications, so the interoperable is irrelevant The portable criteria will be easily fullled when developing the system with Java [7]

45

Chapter 5 Architecture
To ease the design and understanding of our system we will in this chapter describe the technical platform in depth and choose an architecture for our components.

5.1

Technical platform

In this chapter we have a short description of the technical platform that our system will use. Because the system is using a client-server architecture, we will have to describe both of them.

5.1.1

Equipment

Because we use Java Server Pages to generate HTML code to the clients when they connect to our web server, the only requirement is that the web shop clients have an Internet browser like Mozilla Firefox and a standard PC with and Internet connection. The warehouse clients will also use standard PCs with Internet connections but must in addition have JRE1 version 1.5 installed. The server is also required to run JRE 1.5.

5.1.2

System software

We will program the system in Java and use NetBeans to make sure that the Java running on our server and the Java Server Pages can send the objects over the network connection. We have chosen to use the latest Apache2 and Jakarta Tomcat version as web server because we are familiar with this
1 2

Java Runtime Environment, used for executing Java applications on end-user systems Apache HTTP Server Project, http://httpd.apache.org

46

system, and the system is widely used around the world. For our server we have also chosen to use the MySQL-database system. The choice is based on the fact that the MySQL-database is a widely used open-source system

5.1.3

Communication

The system will have interfaces between the server and clients in two different ways, and interfaces are also needed inside the server. Figure 5.1 on page 48 gives a basic overview. The Java application controlling access to the database system interacts with the Java Servlet using methods implemented in Java Runtime Environment. The Java programming language and the libraries already support communication between dierent applications, such that the Java Servlet (which generate HTML pages for the web shop) can exchange objects with the Java application on top of the database system. This communication can even take place through networks. The same interface is needed on the warehouse client, because the warehouse client also needs to exchange objects with the Java application, which guards the database system.

5.1.4

Design language

Ocial UML3 -notation will be used in the design of the system. UMLnotation is described briey throughout Objektorienteret Analyse & Design by Mathiassen et al[6].

5.2

Component architecture

We chose to make a system that utilizes a client-server architecture, because we have one web shop and several warehouses, which need to share information. The web shop and the warehouses will be clients of a server containing all necessary information, i.e. customer information, product information, orders and warehouse information. As seen on gure 5.1 we use an architecture for distribution in the client-server architecture called local presentation.
3

Unied Modeling Language

47

Figure 5.1: Component architecture When using local presentation the client is only responsible for the user interface, while the server is responsible for all the functionality including the underlying model component. In the system we have two types of clients. One client is used for all the 48

customers using the web shop, while the other is meant for the warehouses. The web shop is on the server-side, and uses the UIS (User Interface System) component to generate the web pages, that makes up the actual UI (User Interface) shown on the web shop client. So the customers web browser only produces an user interface from the HTML documents, which the browser gets from the server. We like this choice, since it makes it unnecessary for the customer to install JRE on the computer. The UIS for the warehouses client simply uses javax.swing for the UI. The warehouse server is the central part in our system, it manages all information about the warehouses in a database, that is the reason for the server component to hold all the functionality in the function and model components. We need certain functionality such as: Signal when new products are needed for a warehouse (the warehouses will then have to order them manually) Send signal to a certain warehouse when an order for the warehouse is placed Calculate the warehouse, which is estimated to process an order fastest Move products to other warehouses, if another warehouse needs them

49

Chapter 6 Component design

We will in this section design and describe the systems components, starting with the model component, followed by the function component.

6.1

Components

In this section we will list all classes for the components. We will use our class diagram 2.1 and our state charts 2.2.1 and add further technical information needed for the implementation. The classes in the model component are responsible for all communication between the function and database component. The classes in the function component are responsible for communication between the user interface and the model component. The following is a specication of all the classes and their operations and attributes. Customer Purpose: The information registered is the customers personal data Attributes: name, address, country, email, phone, city, postalCode, username, password Operations: login, logout, createAccount, updateAccount, searchProduct, viewOrders Shopping cart Purpose: To register information the products the customer wants to buy 50

 Attributes: customer, products, warehouse, deliveryName, deliveryAttention, deliveryAddress, deliveryPostalCode, deliveryCity, deliveryCountry Operations: addProduct, removeProduct, changeWarehouse, changeDeliveryPlace, placeOrder Order Purpose: To register information about an order Attributes: customer, products, warehouse, status, trackAndTraceNumber, creationDate, deliveryDate, processedBy, deliveryName, deliveryAttention, deliveryAddress, deliveryPostalCode, deliveryCity, deliveryCountry Operations: ndWarehouse, printInvoice Warehouse Purpose: To register information about the dierent warehouses, and their inventory Attributes: name, address, postalCode, city, country, email Operations: addWarehouse, removeWarehouse Product Purpose: Register information concerning the warehouses products Attributes: name, vendor, model, description, salesPrice, pictureWebPath, processed, quantity, warehouse Operations: createProduct, deleteProduct, changeQuantity, moveFromOtherWarehouse, searchForProduct Employee Purpose: Register informations concerning the employees work on the order Attributes: name Operations: login, logout, addEmployee, removeEmployee WorkArea Purpose: To give functionality to the warehouse Attributes: employees, warehouses, products Operations: processOrder, nishOrder, viewOrders 51

6.2

Model and function component

This section will from the classes described in section 6.1 try to specify, which classes that is placed in the model component and which of them is in the function component. The classes we found in the analysis shown in table 2.1 at page 14 seemed to have a deciency. In our event table at page 16 we can also see that we have two common events, which can occur several times. This means that we have to create a new class. We have some inconsistency in the way the order class would look depending on if we want to use it in the web shop or in the warehouse application. We will therefore create a new shoppingcart class for the website and use the order class for the warehouse application. There is also two common events, which can occur several times for the processing started event, therefore we create a new class for the warehouse functionality called workarea.

6.2.1

Model-class placement

In this section we will focus on what functions that can be assigned to the classes in the model component. Customer login logout createAccount updateAccount searchProduct viewOrders Order ndWarehouse printInvoice Warehouse 52

 addWarehouse removeWarehouse Product createProduct deleteProduct changeQuantity moveFromOtherWarehouse searchForProduct Employee login logout addEmployee removeEmployee The above list show how some functions are placed on the classes. The functions not listed in this section are functions that would make little sense placing in the existing classes, or functions operating on several objects. These functions will in the next section be placed in new function classes.

6.2.2

Function-class placement

The unplaced functions will be added in new classes. ShoppingCart addProduct removeProduct changeWarehouse changeDeliveryPlace placeOrder 53

WorkArea processOrder nishOrder viewOrders

6.2.3

Function specications

The complex functions included in this section are all related to the place order use case described in section 3.1.3. To avoid misunderstandings and ease the implementation, we made specications of the functions. These specications will be followed by a description. placeOrder Name: placeOrder Category: active, signal, update, reading Purpose: Creates an order in the database and sends a signal about the order to a warehouse and returns order information to the customer Input data: ShoppingCart Conditions: ShoppingCart object exist Eect: An Order object is created containing information from the shopping cart object Algorithm: If a warehouse is not selected the ndWarehouse algorithm is run Data structures: ArrayList of Product Placement: ShoppingCart Involved objects: Customer, ShoppingCart, Product, Warehouse, Order Triggering events: newOrderCreated Involved functions: ndWarehouse, changeQuantity Table 6.1: placeOrder function specication 54

The placeOrder function is called when the customer accepts the shopping cart as an order. This function will call two functions ndWarehouse and changeQuantity. The ndWarehouse function is called rst and nds a warehouse for the order. The changeQuantity will change the product quantity for each of the products ordered. ndWarehouse Name: ndWarehouse Category: passive, compute, reading Purpose: check if the order can be processed at a warehouse. If one or more products are missing at the warehouse to fulll the order, determine whether to choose another warehouse or move the missing products to the found warehouse Input data: Order Conditions: Order object exist Eect: A warehouse best capable of handling the order is found Algorithm: Searching Data structures: ArrayList of Product Placement: Order Involved objects: Order, Warehouse, Product Triggering events: None Involved functions: none Table 6.2: ndWarehouse function specication The ndWarehouse function is called by the placeOrder function. It is purpose is to nd the warehouse, which can handle the order best. This is done by remember the warehouse, which have most of the products on the order. If not all products are available products can be removed from warehouse to warehouse later or wait for a new delivery. The pseudocode for the ndWarehouse algorithm is written in table 6.3. 55


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 bestWarehouseAvailableProducts = 0 i f ( Warehouse i s not s e t ) { f o r ( i =0; i <numberOfWarehouses ; i ++) { availableProducts = 0; f o r ( j =0; j <numberOfProductsOnOrder ; j ++) { i f ( warehouse ( i ) has p r o d u ct ( j ) ) a v a i l a b l e P r o d u c t s++ } i f ( avai l abl eP r oducts > bestWarehouseAvailableProducts ) { bestWarehouse = i bestWarehouseAvailableProducts = avai l abl eP r oducts } } }

Table 6.3: ndWarehouse algorithm

Figure 6.1: Class diagram for the model and function components 56

6.2.4

Summary

The functions found in the analysis have been assigned to the existing classes, and new function classes containing functions that do not t into the existing ones have been made. Last the most complex functions have been specied to ease the implementation. Figure 6.1 is the upgraded class diagram.

57

Chapter 7 Graphical user interface design and components

Since we chose GUI design as our main focus area we put a thorough eort into examining the important design criteria. Hereafter we will describe some of the main things to consider when designing an interface.

7.1

Creating a successful graphical user interface

Creating a graphical web user interface that targets all users in a selected target group can be dicult because we believe users have dierent taste in GUI design. A user friendly interface which has all the needed navigation functions is the rst step on the way to perfection. GUI specialists such as Donald Norman tells us the human mind processes new information based on observations and inferences, this is applicable with e-commerce web sites as well as for the rest of societys generalized consumer equipment [14]. The goal of e-commerce web sites is to get the users attention, and encourage the user to use the site. By fullling their conceptual models, the basis of navigation is accomplished. The choice of using more atypical functions on the web application needs to be well planned to cohere with the rest of the site and for the user to understand these functions. Overall this means the web application must follow some of the ground principles of similar websites, which means a design model and a system image 58

that are consistent with the users model of the web application. Ideally, the users model and the design model are equivalent according to Donald Norman[14]. The physical appearance, its operation, and the way it responds, must be consistent with and exemplify the operation of the proper conceptual model. Furthermore the website should have no irrelevant content, contrary all relevant information should be easy accessible. To make a more interesting user interface that keep the users interested and make them spend time on the site as well as returning, we will examine the GUI elements recommended when building a successful user interface. In our case the website GUI will represent the companys public face, therefore the website GUI should be greater prioritized than the warehouse GUI, both nonetheless should be user friendly.

7.2

Usage of the Gestalt laws

We have chosen to utilize the Gestalt Laws B.11 in the layout of the web shop. In the top frame we have chosen to use primary the principle Closure and Continuity to group the elements together. The links are meant to be conceived as one group, which contains navigational links. In the right frame the principle closure, proximity and symmetry will be the ones primarily used. The elements in the text elds will be group together, because we want the user to perceive them as belonging together and when ling out one of them, the rest must be lled out as well, this is the principles proximity and closure. The content of the shopping cart is set between lines, which groups related information together, in order to make the information easy-to-read. The Gestalt principle used here are symmetry and closure. The elements in the main frame are grouped together after the symmetry, continuity and proximity, closure principles. The product catalog is designed after the continuity and proximity principles. The products names and thump nails are grouped together into the form of a table. This is the principle of both principles while the principle of proximity is used when grouping the individually thump nail and product name together. On the sites product search, create customer and shopping cart, the principles proximity and closure are used. As with text elds, in the right frame, the principles proximity and closure are used. In addition, on the shopping cart site lines are used to group information together, which is the symmetry and closure being used. 59

7.3

Designing the user interface

In order to design the user interface we will take two use cases discussed in chapter 3. The two use cases are Process order and Place order. The rst thing to do is to make an use case diagrams, this will help us understand the complexity involved in performing the specied tasks and thus help us create an user interface that will show the user the important information and functionality that he/she will need to perform his/her task. Hereafter an interaction model will help us understand how the user will interact with the system through specic tasks and display what needs to be seen in each window/frame. Then dialog-models will be constructed to enable us to specify in which sequence the tasks will be accomplished. Based on all this we will make an interaction space model that will be the GUI component of the system, and based on this we will implement the GUI.

Use cases
In gure 7.1 we see the use case for process order. It is important to show the user which orders are available in the warehouse and also if the order is already being worked on by another employee. Therefore we have the status NEW and PENDING. When an user chooses an order a description of what that order contains will appear. If an employee is working on an order that contains a lot of products, it would be a good function to mark each found item. When all items are found and packed the employee must be able to nish the order and input his name for future reference. In gure 7.2 we have the process order interaction diagram. From this diagram we can see that we will separate this use case into three dierent windows. The rst will be an order browser thats lists the dierent orders and the next will be a product browser that lists which items an order contains. If a warehouse receives a large amount of orders the data quickly becomes unclear, by doing the above mentioned we distribute the output and clarify the data. The last screen will appear when an order is nished and will prompt the user to enter his or her name. It will be placed as a separate screen appearing every time an user nishes an order. In this way the user cannot accidently forget to put his name on a processed order. The dialog-model in gure 7.3 shows the order in which the tasks must be completed. The rst thing an user does is to choose an order. After this 60

the user will be taken to a screen that displays the order, and here he will identify and nd each product in the order. When he has found all the items he will nish his order and put his name on it.

<Employee>

<System>

Open System

Display orders

Chose order

[If status new]: Select order

Set status pending

[If status pending]:

Show products in order

Mark products in order

[If all products marked]:

Enable Finish order

[If all products not marked]:

Press finish order

Display employee

Choose employee

Figure 7.1: Use case for process order 61

Order browser

Chose order

Product browser

Identify Product

Finish order

Employee browser

Choose employee

Figure 7.2: Interaction model for process order

62

Chose order

Proces order

<<seq>> Find item 1 Find item 2

<<seq>>

<<seq>> Finish order

Choose employee

Figure 7.3: Dialog model for process order In gure 7.4 we have the use case for place order. because an order must have customer it can be sent to an user must be logged in before he can place one. When logged in the user must have a screen showing him what items his order contains, the price for each item and the total price of the order. If the user has made an error when putting an item in the shopping cart there must be an option to either remove an item or change quantity of the dierent items. Because our system gives the user the option to chose which warehouse that will take care of the order this must be present, but since this is an option the user should not be forced to do this. When the user has checked all the necessary information he will have the option to accept the order and hereafter taken to the invoice screen. Here the user will be informed that his order is created and the invoice for the order will be displayed. The user will be given a choice to print the invoice for future reference. In case we had decided to implement the payment methods and classes for this system the user would have been taken through payment screens before the invoice screen was shown. 63

In gure 7.5 we have the corresponding interaction diagram for this use case. We have chosen to display the available information and functions in three screens. The rst screen will be the log in screen. If the user have not already logged in when the place order button is pressed he will be presented with the login screen. A log out button will appear when the user is logged in and is visible at all times for log out.

The second screen will display all information about an order so the user can review it and change it if necessary. In this way an user can get a complete overview of his or her order without thinking about changing screens or other unnecessary tasks. The last screen will only show the created invoice for the order so the user gets conrmation on his order. Here he will have the ability to print out the invoice.

The dialog model, seen in gure 7.6, is for this use case a little challenging because the user has a lot of optional choices and the ability to log out whenever he or she wishes, but the general dialogue is that the user logs in, he presses place order then accept order, and then logs out. 64

<Customer>

<System>

[If customer logged in]: Press place order [not logged in]: Log in Prompt user to log in

Display order screen

[If quantity of products is right] [If quantity not right]: Enter X of items to remove

Press update [If different address is needed]: Enter delivery address

Remove X items from order

Set delivery address

[no delivery address]:

Select warehouse [If default warehouse selected]: Choose warehouse in customers country

[If warehouse X selected]: Accept oder pressed Set warehouse to X

Order created

[no print invoice]: [If print invoice pressed]

Display invoice screen

Print out invoice

Figure 7.4: Use case for place order

65

Log in view

Log in

Invoice view

View invoice

Print invoice Log our view Log out

Customer info view

Order view

Change item quantity

Delivery addres view

Set delivery address

Select warehouse view

Set warehouse

Figure 7.5: Interaction model for place order

66

Log in

Change item quantity

Place order

Log out

Set delivery address Accept order

Set warehouse

Print Invoice

Figure 7.6: Dialog model for place order

The Interactionspacemodel for each of the use cases can be seen on gure 7.7 and gure 7.8. We now know how the GUI should be build so it will support the use cases we have and the decisions we have made throughout the process, now we have to design the GUI objects themselves. 67

<<Interaction Space>> Main frame <<output elements>> Internal frame(empty) Message field <<input elements>> <<navigates>>

<<Interaction Space>> Ordertable <<output elements>>

<<Interaction Space>> Orderdescribtion <<output elements>>

<<input elements>> <<navigates>>

<<input elements>>

<< >> ns ai nt co

<<actions>> Exit

<<actions>> Close Selectorder

<<actions>> Close Finish order

<<Interaction Space>> Productlist <<output elements>> ProductID ProductName Vendor Model Decription Quantity <<input elements>> Check product <<actions>>

<<Interaction Space>> Orderlist <<output elements>> Status OrderID Creatiun date <<input elements>> <<actions>>

<<Interaction Space>> Employee selection <<output elements>> Employeelist <<input elements>> Chose employee

<<actions>> Confirm

Figure 7.7: Interaction space model for process order

68

<<navigates>>

<<

co nt ai ns >>

<<Interaction Space>> Webshop <<output elements>>

<<Interaction Space>> Order view <<output elements>>

<<Interaction Space>> Invoice <<output elements>> OrderID Creation date WarehouseID Total price <<input elements>>

<<input elements>> <<navigates>>

<<input elements>> <<navigates>>

<<actions>>

<<actions>> Accept order

<<actions>> Print

<<

<<

>

<<contains>>

in s>

in s>

>

a nt co

a nt co

co nt a

co nt a

s> in

s> in

<<

<<

>

>

<<Interaction Space>> Selectwarehouse <<output elements>> <<contains>> <<contains>>

<<Interaction Space>> Customer info <<output elements>> Name Address Postal code Country

<<Interaction Space>> Invoice productlist <<output elements>> Vendor Name Model Quantity Price <<input elements>> <<actions>>

<<Interaction Space>> Login <<output elements>>

<<input elements>> <<input elements>> Name Password <<actions>> Login Warehouse

<<input elements>> <<actions>> <<actions>>

<<Interaction Space>> Delivery address <<output elements>> <<input elements>> Name Attention Address Postal code Ciry Country <<actions>>

<<Interaction Space>> Shopping cart <<output elements>> Total Price <<contains>>

<<Interaction Space>> Productlist <<output elements>> Vendor Name Model Quantity <<input elements>> Quantity <<actions>> Update

<<input elements>> <<actions>>

Figure 7.8: Interaction space model for place order

7.4

Web shop GUI

The Web shop GUI has been developed using the methods and concepts described previous in this chapter and in sections B.8, B.9, B.10, B.11 and B.12. The overall objective with our web application is to sell products. The customer should have easy access to nding the desired products and the navigation should be as simple as possible to relieve the customers overview of the site. Furthermore we want a simple and clean design without any irrelevant frames and other irrelevant graphics, but at the same time the graphics must be appealing to the customer, because it is an e-commerce site and customers should preferable return and also recommend the site to others. 69

7.4.1

Layout and design

We chose to use top, main and right frame for our web site. Our choice of this is based on the fact that we want to keep it simple for easy navigation and clean design without irrelevant information, but still supporting features who can help the user to gain overview of his shopping. In the left frame we will place our shopping basket to give the customer easy overview of the order. Based on visual perception, section B.11, and color meanings, section B.8, described in previous chapter we chose the color layout for the web site. We chose blue, orange, red and gray colors for the primary layout. The reason for this is because we want to represent ourselves as a business oriented conservative company. The blue represent stability, trust, wisdom and integrity which are important virtues for a serious web shop. Red is used for warnings and to get the attention of the customer. Grey means neutral and time to make choices. Orange is a complementary color of blue and at the same time it means creativity, determination, energy and success. The web page will support screen size from 800x600 pixel and greater resolutions. Web shop font We choose a sans-serif font for our web shop based on our studies in section B.10. Arial and Verdana is two of the most supported sans-serif fonts on the web, we think Verdana is the best looking of the two fonts, therefore we choose Verdana font as our default. The size of the font will be smaller than a regular size 12 which is the default size of regular printout, this is another reason for choosing a sans-serif font [4]. The Verdana font is a very clean font which are sometimes used on business sites, this font type has conservative symbolic value which we also want our company to cohere and represent. Hereby the customer hopefully will get an overall conservative impression of the site, as being a serious business site.

7.4.2

Dialogue style in the web shop interface

The customer interface is a web interface which primarily will be using direct manipulation and menu selection when browsing through products putting items visually in a shopping cart, form ll-in will also be used when the customer has to register to buy products. Additional information of our studies about dialogue style can be found in section B.12. 70

7.4.3

Frames

B.9 Based on our studies about frames in section B.9 we organized our information and links primarily according to the regular concepts of the World wide web user. Top frame The logo of the company is put in the upper left of the top frame, see gure 10.2 the slogan of the company will be placed in the middle of the top frame as it is coherent with the logo. Navigation is also placed in the top frame. The upper right navigation consist of; Create Customer, Customer Details, Track and Trace, Company and Contact. The lower right navigation consist of; Product Catalog, Product Search and Shopping Cart. Both upper and lower have consistent text graphics which change color on mouse over, the lower navigation also have dierent icons for easy recognition. Below these link menus we have placed a bar which also consists of a menu, this menu changes according to what menu link is chosen. The user can press each bar navigation link, ex. a Product category, to go back to an earlier state, all the way back to for example the Product Catalog, which in this case is the rst. The top menus will be accessible at all time, as it only will be the pages below the navigation bar who changes during navigation around the web site application. Additionally Country, Language and Currency will be implemented, it will consist of drop down menus containing the countries associated with the system. Although this is not necessary for the system to function, it will most likely not be implemented, due to lack of project time. Main frame The main frame will change according to what link is chosen, the default will be the product catalog, where product categories will be shown, below the categories advertisements of the sites special oers will be placed. All main pages will have a gradient background of deepskyblue who gradients into a 71

light gray color, the text size and color will be controlled from CSS1 which will make the text layout coherent so links and regular text look the same all through the site. Right frame In the right frame shopping cart and login/logout will be placed. The background will be a light gray for the frame to cohere with the background gradient of the main frame. There could be a small deviation in the basic user concepts concerning the shopping cart in the right frame, but we think placing the shopping basket in the right frame would be a great help for the customer to keep overview of what is placed in the shopping cart and also giving the overview of the total price.

7.5

Warehouse GUI

It is important to have an user-friendly warehouse application interface as it eases the work for the employee and makes it easier to learn for new employees and companies[13]. We tried to implement this by making an user interface based on who the user would be and how the system would be used, which we documented in the analysis.

7.5.1

Layout and design

In the warehouse, there is a computer with an interface which is used by multiple warehouse workers. Therefore the usual form of log in would not be appropriate in this case. It would simply be too demanding if the warehouse workers had to log in and out for every order they processed. Instead when each individual order is nished it would be possible choosing which employees name goes with the order by using a drop down menu, see gure 7.9.

Figure 7.9: User dropdown menu

1

Cascading Style Sheet, a le which controls layout for a website.

72

According to Human-Computer Interaction by Alan J. Dix, it is important to keep each screen easy to survey. To do this it is necessary to keep the screen simple. There is multiple ways to do this, the most important is to get rid of irrelevant data and to keep the interface simple[3]. The warehouse GUI should consist of an order list where all the orders will be queued to ensure a good overview of the screen there should be a display of status for the individual orders so the employee quickly can see which orders to work with. Double-click on the order in the list should open an order window in which the details of the order is displayed. To ensure an employee can locate an older order from the orderID and creation date should be displayed also. To simplify the interaction with the application we should make a menu bar at the top of the screen, like it is known from other programs, in which the dierent functions should be implemented. The status of a new order will be new, by clicking on it and opening the order it will change status to pending. When the employee then ships the package to the customer he puts an X in a shipped box the order status changes to shipped. It is a possibility that not all the products ordered by the customer are in stock. Then the order stays pending until it is possible to send all the products. To heighten the usability of the program it should be possible for the user to make a personal setup so we will make it possible to rearrange the columns in any order. By clicking on the column heading it should be possible to sort the orders after orderID or status. Arranging after status should of course arrange the orders with the new and pending orders in the top, because these are the most relevant for the employee. The reason for being able to sort is if the employee needs to nd a specic order it can be extremely dicult to locate it if the possibility to sort the data is not there. The open order window contains the order number, address and name of the customer and which products is ordered. The products are plotted into a table which among other things contains their location in the warehouse. Some products can easily look alike. To avoid a human error we have the remaining information about the product, to ensure the correct product gets sent. The File dropdown menu contains an exit function. The product dropdown menu contains the options to add or remove products. The order dropdown menu contains the possibility to open a new order list. The administration 73

dropdown menu gives an option to implement administrative functions like add/remove employee, which we will not do.

Warehouse font Java uses the default fonts installed on the operation system, it uses by default a sans-serif font, so the readability is acceptable, we could chose a font type for the warehouse GUI, it would result in less usability because it could dier radically from the operation systems layout.

7.5.2

Dialogue style in the warehouse interface

The warehouse employee is a general employee page, with login, where the user interface will be used at the internal storage when processing an order. Menu selection and direct manipulation will be used by the stock employee. Substantial use of menu selection will be used when processing orders and to see statistics on sales. Form ll-in will be used when correcting/adding new product categories, products, descriptions and prices.

74

Chapter 8 Database design

Partially based on the modeling component shown in gure 6.1 on page 56, the entity-relationship diagram of the database is drawn in gure 8 on page 82. The database model should contain the same attributes as the model component, but in some areas the ER-diagram is dierent. We chose to make the database model as an ER-diagram, because we learned about ER-diagrams in the Persistence course1 in this semester and because it corresponded to our technical platform, the MySQL platform. More information about MySQL and the implementation of the database is available in section 9.3, however we recommend reading through this chapter rst. During our development of the ER-diagram, the two entities orderDetails and stockStatus were made as the result of many-to-many relationships. This type of relationships typically have the primary keys of the relating entities as attributes [15]. However we needed more attributes than just the primary keys, such as quantity in both orderDetails and stockStatus, so we thought it was better to change the many-to-many relationships into entities. As regards naming of the entities and relationships, we use a mixture of Sun Microsystems naming conventions for Java code and the naming presented in chapter 1 of Database System Concepts by Silbershatz et al [15]. The latter uses only lower case for relationships. The entities are named so that all substantives - except for the rst one - begin with a capital letter and continue with lower case, e.g. productDetails and stockStatus. Do not attach additional importance to the naming, we just want to clarify our choices to the reader. The naming is applied correct in the ER-diagram, but in some of the following headlines we make exceptions due to layout considA course held by Kristian Torp on the DAT1/INF1-semester, Department of Computer Science, Aalborg University
1

75

erations, e.g. productDetails may be written as ProductDetails. In the following sections the databases entities and relationships will be introduced, justied, and explained.

8.1

Entities

The entities primary keys are underlined at gure 8. We chose to use numeric values as the primary key in all entities, because it is faster to search through a list of integers compared to a list of text strings [11]. In some cases text strings would have been the natural alternative, e.g. a compound primary key in warehouses consisting of the warehouses name, city, and country. We list the entities in order of appearance at the ER-diagram in gure 8 on page 82.

Employees
This entity represents all employees working at all warehouses. Because we opted out the administration part of the sales system, we do not want to keep personal information about the employees. We settle for an unique identication number and a name. In that way it is possible to distinguish between employees with identical names.

Orders
All orders existing in the system will be represented by this entity. Only master information about an order is stored here, including unique identication number, status, involved customer, involved warehouse, involved employee, delivery details, various dates, and track & trace number for the distributed package. The ER-diagram at gure 8 shows clearly that the delivery details, represented as attributes starting with delivery, were not existing in the early design of the database. There are delivery elds for name, att (attention), address, postal code, city, and country. These elds are not always necessary, because the customer may decide to stick with the name and address stored in the Customers entity. We think it is correct to place the attributes in the Order entity, because the delivery details cohere to a specic order, i.e. the customer may choose dierent delivery details for other orders. 76

OrderDetails
The contents of an order are kept in this entity, i.e. an order identication number, a product identication number, and a quantity are linked together. As an example, an order with the identication number 7 may contain two bikes and ve mopeds with the product identication number 1 and 2, respectively. That content of an order will ensue two records which will look like (7,1,2) and (7,2,5) if written using the tuple notation (orderID, productID, quantity). The entity contains records for all orders existing in the system so the number of records may be extremely big. To ensure distinct records we have added a primary key called orderDetailsID which is unique.

ProductDetails
All details concerning the products in the system are stored in this entity, except for stock gures. Each product has an unique product identication number and belongs to a certain category in the Categories entity. In addition information about name, vendor, model, price, description, and picture can be kept in this entity. The product identication number is an unique, primary key.

Categories
Products are organized into categories and this entity keeps information about all the categories. Every category has an unique identication number, a name, a description, and a picture. The identication number is the primary key and is referenced by products in the productDetails entity.

Customers
This entity represents all registered customers in the system. Every customer has an unique identication number so the system is able to distinguish between them. The number is used as an unique, primary key. A personal user name and password are used by a customer to log on the web shop. This entity also keeps the real name and address of a customer which is needed for sending out ordered products and to avoid the hassle of typing in the same information with every order. Additionally a phone number and an e-mail address are kept as a convenient way to contact the customer. 77

Warehouses
The sales system supports multiple warehouses and information about all the warehouses is represented by this entity. We need to store name, address, postal code, city, country, and e-mail address of the warehouses. The latter is kept as a convenient way to contact the warehouse. As an example the warehouses e-mail addresses could be registered in a mailing list, such that the warehouses were able to communicate easily and cheaply, however that is out of the scope of this project. It would be reasonable to use a compound key consisting of e.g. name, city, and country as primary key for this entity, but for performance reasons we distinguish between the warehouses using an identication number as previously mentioned.

StockStatus
This entity links together products, warehouses, and quantities. It has four attributes which are: identication number for each StockStatus record, a product identication number, a warehouse identication number, and a quantity. In this way it is possible to express how many pieces of a single product type each warehouse got in stock. The primary key is the unique identication number for each record which is only included to ensure distinct records. Moreover it is good practice to remember primary keys in all entities. [15]

8.2

Relationships

In this section the database models relationships will be presented and accounted for. The rst-hand impression of the ER-diagram may give rise to headache for database experts, because the entities and relationships form two circles. Circularities in ER-diagrams are known to be the root of redundant data and operational problems, but in section 8.2.1 and 8.2.2 we will explain why that fact has nearly no impact on our structure [15]. The entities orders, orderDetails, productDetails, stockStatus, and warehouses are involved in the circles. The relationships are presented in order of appearance in the ER-diagram.

Employees process orders

This is an one-to-many relationship from employees to orders which cause the employeeID attribute in the order entity. The argument for an one-to78

many relationship is that an employee may be responsible for many orders, however an order is only processed by one employee.

Orders contain orderDetails

An order may contain many products, but a record in orderDetails only refers to a single order in the orders entity. That is why this relationship is one-to-many from orders to orderDetails. The products belonging to an order are listed in orderDetails as product identication numbers together with warehouse identication numbers and quantities.

ProductDetails are-referenced-by orderDetails

The entity productDetails contains, just like the name alludes, details on all registered products, except for the associated stock gures. A record in productDetails may be referenced by multiple records in orderDetails using the products unique identication number, i.e. the relationship is one-tomany from productDetails to orderDetails.

Categories contain productDetails

This relationship connects categories and productDetails, because the products recorded in productDetails are categorized into categories recorded in the categories entity. A single category may contain many products, so the relationship is one-to-many from categories to productDetails.

Customers place orders

Hopefully, customers place orders through the web shop to utilize the system. That act is represented by this relationship which allows a single customer to place several orders and limits an order to be placed by one customer. As a consequence hereof the relationship is one-to-many from customers to orders.

Warehouses own orders

Each order is assigned to a single warehouse, such that a single warehouse is said to own a number of orders. The relationship is one-to-many from warehouses to orders, and as a result of this, the orders entity has an attribute called warehouseID. 79

Warehouses are-referenced-by orderDetails

We want to attach each product on an order to a single warehouse, because the products oered on the web shop may be placed at dierent warehouses initially. It is then the employees job to examine pending orders and check which products that should be moved between the companys warehouses to send only one package to the customer. As the moving progresses, the products warehouse property can be updated. The relationship is one-tomany from warehouses to orderDetails, because the records in orderDetails may only reference a single warehouse, but a warehouse may be referenced by several records in orderDetails.

ProductDetails are-referenced-by stockStatus

Products recorded in productDetails are referenced by records in stockStatus. The relationship is one-to-many from productDetails to stockStatus, because a product may be in stock at several warehouses, but a record in stockStatus may only reference a single product in productDetails.

Warehouses have stockStatus

Each warehouse has information about stock status which is recorded in the stockStatus entity. The relationship from warehouses to stockStatus is one-to-many, because a record in stockStatus may only point to a single warehouse, but a record in warehouses may be linked together with several records in stockStatus.

8.2.1

First circularity

This circularity is created by the relationships between orderDetails, productDetails, stockStatus, and warehouses. Both orderDetails and stockStatus have the attributes productID and warehouseID, because there are one-tomany relationships away from warehouses and away from productDetails. If the circle had circular derivation of attributes because of unidirectional one-to-many relationships, it would present a serious problem. If that is the case, then the database design is impossible to setup in a relational database management system, because the tables, which represent the entities, have to be created one at a time, and a table cannot be created if it relates to another, non-existing table [15].

80

By inserting data into warehouses and productDetails before inserting data into orderDetails and stockStatus, the circularity is proven unproblematic. However, this design makes it possible to add to an order products which are not present in the warehouse, which they are referring to in orderDetails, i.e. orderDetails may contain a record stating seven bikes from a warehouse that does not sell bikes (the product identication number for the bikes are not linked together with the identication number of the warehouse in stockStatus). That is a matter of debate, because it could be considered either a feature or a aw, e.g. a company may be interested in selling products prior to having them in stock. The database layer on top of our database insures that the system described in this report does not assign products to warehouses, where they are not in stock.

8.2.2

Second circularity

This circularity is created by the relationships between orders, orderDetails, and warehouses. The relationships result in the attribute orderID in orderDetails, the attribute warehouseID in orderDetails, and the attribute warehouseID in orders. As previously mentioned, the two warehouseID attributes are needed, because an order in itself is owned by a warehouse and the orders products may temporary be placed at other warehouses. Again, the solution is to insert data into the entities in correct order. First create a warehouse, then create an order, and nally add products to the order by creating records in orderDetails. Bear in mind, that records in employees and customers are needed to create an order, just like records in productDetails are needed to create records in orderDetails.

8.3

Summary

We expect the database design to work just ne if implemented in a relational database server. The implementation will be done using the MySQL database server in section 9.3, where we will explain SQL2 and Javas database connectivity too.

Structured Query Language

81

deliveryName deliveryAtt deliveryAdress deliveryPostalCode deliveryCity deliveryCountry

orderID status customerID warehouseID employeeID

employees 1..1

employeeID name

customerID username password

process name 0..* address 0..* place 1..1 customers postalCode city country contain own 1..1 0..* arereferencedby 1..1 warehouses 1..1 phone email warehouseID name address arereferencedby have postalCode city 1..1 productDetails 0..* 1..1 arereferencedby 0..* 0..* stockStatus email stockStatusID contain categoryID name 1..1 categories description picture productID warehouseID quantity country

creationDate shippingDate trackAndTraceNumber orderDetailsID orderID productID warehouseID quantity processed productID categoryID name vendor model price description picture

orders 1..1

0..*

orderDetails 0..*

82

0..*

Figure 8.1: Entity-relationship diagram for the database

Part III Implementation

83

In the implementation part we focus on how we have implemented our system. Due to the limited time period we have not implemented the whole system. We have focused on getting a working web shop and warehouse server, but also implemented a part of the warehouse client. The limitations in the warehouse client is basically the functionality for the actor called secretary. There is no login and logout for the warehouse client and as well there is no options for adding and removing employees, products and warehouses to the system via the warehouse client. After struggling with RMI-callback and thought about the time costs of getting it to work, we have chosen not to implement it. That resulted in the warehouse client is not updated automatically, but only when the window is opened. The warehouse client was meant to be updated when new orders arrives or a product quantity is running low. Another feature not implemented, because it is depended on RMI-callback is the moveFromOtherWarehouse operation in the product class.

84

Chapter 9 System implementation

In the implementation phase we take the system designed in the design phase and realize it on the selected technical platform. In this section we will go through the implementation of the database, the model classes, and the function classes.

9.1

Class implementation

The implementation of the classes from the class diagram at gure 6.1 have been implemented, but we have made some changes to the design during the implementation phase. The implementation started with coding the classes in the model component. The main dierences in the model component between the design and implementation is the placeOrder method.

In the implementation the method has been placed in the Order class, while it is located in the shopping cart class in the system design In the design the changeQuantity method from the product class have not been implemented, but the functionality the method has is implemented in the placeOrder method To ease the implementation of the products we have created a new class called category. It is mainly used for grouping a certain type of products 85

9.2

Warehouse server

We have implemented our warehouse server, which uses RMI for communication across networks and (My)SQL-syntax for storing data in a MySQL database. Our warehouse server works like a top-layer for the MySQL database. The main reason for implementing our warehouse server instead of just connecting directly to the MySQL database, is that we want to update the warehouse-client as soon as orders are placed in the online web shop. We also want to notice warehouse-clients automatically, when a product count is running low. If we have chosen to skip our database server, the warehouse client could have updated. Instead it updates automatically in time intervals, but we wanted to inform the warehouses instantly when orders are placed or a product count is running low. When the warehouse server is started, the rst step is to load our Database class, which initialize a connection to the MySQL database. Afterwards new instances of the NetworkWebShop and NetworkWarehouse classes are made, and the database server binds them as remote objects to a specic name. RMIRegistry must run in order for our database server to work. Each of our remote objects have the necessary methods to make the web shop and warehouse application work. When a method is called via the RMI, the methods arguments are forwarded to local method in one of our systems classes, which handles the data and interacts with MySQL. Our database server have the following system classes: Category Customer Employee Order Product ShoppingCart Warehouse Each of the system classes can access the MySQL database by using the connection initialized when the server started. Most of the methods just need to update some data in the database or retrieve some data. However our placeOrder method in the Order class, which is invoked from the web 86

shop, will have to send data to a specic warehouse, which can be solved by using RMI-callback.

9.3

MySQL

MySQL is a relational database server owned and sponsored by a single Swedish, for-prot rm, MySQL AB. It is available under dierent licenses to accommodate all intended use, such as the GPL1 . Both source code and binaries (for Linux, FreeBSD, Windows, etc.) are freely accessible from MySQLs ocial homepage at http://dev.mysql.com. The application turns in a strong performance being multithreaded, and security is available through multiuser support. [8] We utilize the latter by creating an user called wwwuser only with permission to select from, insert into, update, and delete from tables. The tables will be created and owned by the root user who is the databases administrator. [1] Just like The Apache Derby Project (the database server introduced to us in this semesters PER-course), MySQL is reached from within a Java application using a JDBC-driver2 . Sun Microsystems let the developers of database servers develop their own drivers for connectivity; MySQLs is called MySQL Connector/J.

MySQL Connector/J
MySQL Connector/J is downloadable from MySQLs ocial homepage and requires only a simple installation. We will introduce the reader to Connector/J through examples. Please note, that the presented code needs to have nearly all classes from the java.sql package imported. Within a Java application, a database connection is initialized by this short code:
Connection c; Class.forName("com.mysql.jdbc.Driver").newInstance(); c = DriverManager.getConnection("jdbc:mysql://" + host + "/" + database + "?user=" + user_name + "&password=" + password);

In our case the connection string is jdbc:mysql://127.0.0.1/d105a?user=wwwuser&password=nO8xT26Gja. A query may now be made through a statement:
1 2

GNU General Public License, http://www.gnu.org/licenses/licenses.html#GPL Java Database Connectivity

87

Statement s; s = c.createStatement(); s.executeUpdate("UPDATE customers SET name=" + name + ", address=" + address + ", postalCode=" + postalCode + ", city=" + city + ", country=" + country + ", phone=" + phone + ", email=" + email + " WHERE customerID=" + customerID);

The query updated a customer account with new values. It is also possible to retrieve information from the database, e.g. the identication number of a customer based on an user name:
ResultSet r; r = s.executeQuery("SELECT customerID FROM customers WHERE username=" + username + "");

To end the example, we close the statement and the connection:

s.close(); c.close();

The system needs a database with contents, so we will continue in section 9.4 by building tables representing the entities from chapter 8, database design. Beside informal attributes, the tables will contain primary and foreign keys representing relationships.

9.4

Creating the database

The database is created using MySQLs command-line tool at the computer running MySQL. The tool is started and two commands are typed in to create the database and use it:
(shell)$ mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 7 to server version: 4.0.22_Debian-6-log Type help; or \h for help. Type \c to clear the buffer. mysql> create database d105a; Query OK, 1 row affected (0.08 sec) mysql> use d105a; Database changed

Based on the ER-diagram, we have constructed a list of queries to create the tables in the database. We will present two of them here; one to create categories, and one to create productDetails. A complete list of CREATE TABLE queries and resulting tables are available in appendix C. The query for creating categories can be seen in gure 9.1. The categories name and 88

picture is represented using text strings of up to 60 characters wide. The identication number is an auto-incrementing integer, and the description a text with a maximum length of 65535 (216 1) characters. [1]
CREATE TABLE categories (categoryID INT AUTO_INCREMENT, name VARCHAR(60) NOT NULL, description TEXT, picture VARCHAR(60), PRIMARY KEY (categoryID)); +-------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-------------+------+-----+---------+----------------+ | categoryID | int(11) | | PRI | NULL | auto_increment | | name | varchar(60) | | | | | | description | text | YES | | NULL | | | picture | varchar(60) | YES | | NULL | | +-------------+-------------+------+-----+---------+----------------+

Figure 9.1: Creation of the table categories The next table, productDetails, will take advantage of a foreign key to link itself to categories. The attribute categoryID in productDetails is a key referencing the primary key in categories; hence it is a foreign key. This insures that new products must be put into an existing category from categories. The query to create productDetails is seen in gure 9.2.
CREATE TABLE productDetails (productID INT AUTO_INCREMENT, categoryID INT NOT NULL, name VARCHAR(60) NOT NULL, vendor VARCHAR(60) NOT NULL, model VARCHAR(30) NOT NULL, price FLOAT NOT NULL, description TEXT, picture VARCHAR(60), PRIMARY KEY (productID), FOREIGN KEY (categoryID) REFERENCES categories (categoryID) ON DELETE CASCADE ON UPDATE CASCADE); +-------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-------------+------+-----+---------+----------------+ | productID | int(11) | | PRI | NULL | auto_increment | | categoryID | int(11) | | MUL | 0 | | | name | varchar(60) | | | | | | vendor | varchar(60) | | | | | | model | varchar(30) | | | | | | price | float | | | 0 | | | description | text | YES | | NULL | | | picture | varchar(60) | YES | | NULL | | +-------------+-------------+------+-----+---------+----------------+

Figure 9.2: Creation of the table productDetails Within the SQL commands creating the tables, the not null means that the tables data eld must contain data. The primary keys in a table must contain data or else an error will occur. The foreign keys dier a bit, as seen with orders where employeeID may be null (check out appendix 89

C). We chose not null for that attribute, because an employee is not necessarily appointed when an order is created, but instead the appointment occur later when an employee at a warehouse chooses to process the order. In case of the foreign key, the integer in the data eld must correspond to a primary key in another table. When the not null condition is set on data elds, that means the information is deemed important to the record, such as a customers name and address. An error will occur if a data entry is not made into a not null attribute when inserting data into a table. [15] When a row is removed or updated from a table, the change does not automatically happen in other tables, even when they contain a foreign key referring to the changed row is the other table. To insure that this does not present a problem, the table must be able to handle such situations. Therefore the options on delete cascade and on update cascade to the SQL command create table will be used. It is also a considerable feature, because it eases the operation of the database, e.g. all products in a specic category can be removed by just removing the category itself. In particular the on delete cascade option will be used with caution, because we do not want all orders belonging to a customer to disappear if the customer is deleted. Instead we have chosen to deny deletion of a customer if the customer is referred to by any order. [15] Status of the order may only be set to a predened set of values: Pending, Being processed, and Shipped. We have decided to use a text string for status so that it is easy to print out at the web shop and in the warehouse interface. Text strings are also more expressive than numeric values, e.g. 1, 2, 3. The entity have three foreign keys referring to other entities which are customerID, warehouseID, and employeeID. Except for employeeID, these foreign keys cannot be null. At an early stage of the database design the employeeID could not be null, but when we realized that an employee was not assigned to an order imidiately, we had to make values of null possible. The creation date of an order must be set when creating a new order so it cannot be null. That is not the case for the shipping date which is not set until an order has been completely packed in postal packages and shipped. The track & trace number is provided by the mail service when a package is shipped, so it may be null when order status is Pending and Being processed. We represent the number with a text string, because the format diers between mail services and is not limited to numeric values.

90

The queries listed in appendix C helped us create a working database which is now taking care of persistence in the back-end of our system.

9.5

Client/server implementation

Since everything is implemented in Java the implementation of the client/server system were done with RMI(Remote Method Invocation). The remote interface gure 9.3 declares all the methods that the web shop and the warehouse client can call over the network.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 public i n t e r f a c e N etw o r k Wa r eh o u s eIn te r f a ce extends Remote { g etO r d er ( i n t wId ) throws RemoteException ; d e l O r d e r ( i n t o r d e r I d ) throws RemoteException ; p r o d u ctC a teg o r y ( i n t catID ) throws RemoteException ; l i s t C a t e g o r y ( ) throws RemoteException ; ch a n g eO r d er S ta te ( i n t orderID , S t r i n g s t a t u s ) throws RemoteException ; g e t P r o d u c t L i s t ( i n t o r d er ID ) throws RemoteException ; ch a n g eP r o d u c t S t a t e ( i n t orderID , i n t productID , boolean s t a t e ) throws RemoteException ; g etE m p l o y ees ( ) throws RemoteException ; setOrderEmploy ee ( i n t orderID , i n t employeeID ) throws RemoteException ; getOrderEmployee ( i n t o r d er ID ) throws RemoteException ; }

Figure 9.3: The remote interface used by the warehouse client

9.6

Web server

The web shop is written in JSP, which is embedded into the static HTML pages. It needs a web server with a JSP engine to display the pages correct. The most common web server for serving JSP pages is Jakarta Tomcat. Jakarta is the group name of some projects by the Apache Foundation. Tomcat is the name of the web server, which uses Catalina, Coyote and Jasper. [2] Catalina: The Java Engine built into Tomcat, it provides the environment needed for servlets to be run Coyote: The HTTP connector that is used in Tomcat, which enables clients to connect 91


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public I n t e g e r l o g i n ( S t r i n g username , S t r i n g password ) { Integer String response = 0; url = rmi : / / 1 2 7 . 0 . 0 . 1 / ;

try { NetworkWebShopInterface networkWebShop = ( NetworkWebShopInterface ) Naming . l o o k u p ( u r l + webshop ) ; response = networkWebShop . l o g i n ( username , password ) ; } catch ( E x cep ti o n e ) { e . printStackTrace () ; } return r e s p o n s e ; }

Figure 9.4: Outline of the servlet application Jasper: The Java Server Pages (JSP) handler, which translates JSP code into servlets Tomcat have a directory called webapps, where you usually place your web applications such as our web shop. All les for the web shop must be placed into a folder, and a subdirectory for the web shop folder must be created called WEB-INF. The WEB-INF folder is used for java classes and is not directly accessible to visitors of the web site. The web server we have implemented is located in the WEB-INF folder and enables our JSP pages to call methods on our database server. So our web server class is mainly used as a transparent layer for letting our JSP pages communicate with the database server. In gure 9.4 is an example of the servlet code for the login method. It sends the username and password entered at the web shop to the warehouse server and if it is a valid account it will return a reference to the customer class.

92

Chapter 10

Clients

10.1

Warehouse application

The picture 10.1 shows the implemented warehouse client. The GUI is implemented java using javax.swing. The orderlist and orderdescriptions are JTables which get their data from 2 datastructures. The data structures call the getOrders and getProducts methods on server and gets the needed data from the database.

93

Figure 10.1: Screen dump of the warehouse client

10.2

Web shop

The web shop has been implemented as shown in gure 10.2. It is possible to log in and log out in the right side of the page, where the customer can also see the items in the shopping cart. In the center of the page a list of product categories is shown, where the user can click and show all available products for the chosen category as shown in gure 10.3. The process of adding products to a shopping cart and placing an order is shown in the following gures. 94

Figure 10.2: Web interface 1, the customers browse through products and adds them to the shopping cart

Figure 10.3: Web interface 2, after adding products to shopping cart, the customer press the place order 95

Figure 10.4: Web interface 3, the GUI tells the customer to login to place order, hereafter the user press the new customer buttom to create an order account

Figure 10.5: Web interface 4, the customer lls in the needed information to become a customer and press the create button 96

Figure 10.6: Web interface 5, the customer updates his order, chooses a warehouse, check for correct information and press the accept order button

Figure 10.7: Web interface 6, the customer prints out the order and press the Track & Trace link 97

Figure 10.8: Web interface 7, customer views the track and trace information and hereafter logs out and awaits his order in the mail

98

Part IV Test

99

Chapter 11 Implementation test

Throughout the implementation of the system a lot of tests were made. The test method used is a bottom-up testing, starting with the primitive methods moving towards the main functionality. All tests were made using the unit test tool called JUnit1 .

11.1

Class tests

Tests were made on all implemented model classes. The tests were made to insure that the classes stored the information correctly, and that the get methods in the class returned the right information. New instances of the classes were made, and their get methods were called on them. The JUnit test setup can be found in appendix A.1.

11.2

Functionality tests

Since our system is designed to use a database as main data source, and a network to share methods over, the functionality tests had to be made after the warehouse server and a client had been made. Without the server the clients (warehouse and web shop) cant get in touch with any methods and add data to their data structures. The test setup up for the getOrders method can be found in appendix A.2.
1

http://www.junit.org

100

11.3

Summary

The test cases from the class tests showed that all classes worked as expected. The results from test case 1 in the functionality test showed that the getOrders()method returned the expected number of orders, each time it was called. The results from test case 2 was as expected, the orders returned were correct. One problem was found though, the date returned by the order had minutes and seconds stripped o. The error has been located at the database, but no actions have been taken. We did not correct the error because it is not important for the customer or employee to know the exact minutes and seconds on a shipped and created order.

101

Chapter 12 Usability test

The purpose of the test is to discover whether an actual end user can utilize the system usefully, and to nd any serious and minor problems with the user interface. The test will measure the time to complete tasks and note where the users run into diculty and errors. The task simulates a typical purchase of a product on the web site. Usability is deend by Jerey Rubin as being one or more of the four factors: Usefulness: How well a user can use the system to achive the goal of using the system. It is this factor which will be used as the evaluation messure in the test, conducted in this project. Eectiviness: Concern how easy the system is to operate. This is usually messured through speed performance. Leanability: How quickly the user can operate the system. Attitude: How well the user like to operate the system.

12.1

Test result

The participant used in the test where asked to ll out a background questionnaire to establish the participants characteristics. The result is shown in table 12.1. 102

Characteristic Education/employment Sex

Range Students Male Female

Frequency 100% 67% 33% 33% 37% 33% 33% 33% 33% 67% 100% 67% 33% 100% 33% 33% 33%

Age

19 21

Use of Internet per week

1-4 hours 4-8 hours More than 8 hours

Use of computers per week From where do they use the Internet Has purchased products online before Their own denition of their experience with online shopping. From 1 - 5 where 1 is no experience and 5 is expert.

5-12 hours More than 12 hours At home At work/or at school Other Yes 2 4 5

Table 12.1: Result of background questionnaire From the results shown in table 12.1, a prole of the test participants can be made: The participants are students, between 19-21 years old and with a majority 67% being males. To make sure the target group is as narrow as possible, the participants should, look alike. Therefore we chose to use participant with approximately the same demographically prole. All of them has bought products online before and uses both computers and the Internet on a regular basis. We chose only to use participants who had some experience working with computers and the Internet, because we would like to see how users, who had some experience and therefore some standard to compare the system to, would utilize the system. All of the participants use the Internet at home, but in addition 67% of the participants uses the Internet at their place of study and 33% go online somewhere else. Where the participants uses the Internet could give a better understanding of the users behavior and establish how the user utilize the Internet and their Internet experience. The participants experience with online shopping is spread from novice to ex103

pert experience, with 67% of the participants being either accomplished users or experts. It is important that not only experts can handle the system, because the average end-user cannot be expected to have a lot of experience buying products online. At the same time the experts have some expectations to the system. The system must be able to meet the demands of both.

Result and analysis of evaluation questionnaire

After the test the participants were asked to evaluate the system, based on the recent experience with the system. As can be read in the table 12.1, the users evaluation of the system indicates several problems which will be dealt with in the three subsections Presentation, Overall user reaction to using the system and Multimedia.

Presentation We have conducted a test inspired by the quality survey test which focuses on the users opinion of the web site. We decided to make this test because we wanted to ensure that an user would like the site and then eventually return to use the site. Only numbers below 3 is considered a problem in this report, and will be analyzed in this section.

Question 3: The amount of information displayed is just right The amount of information on the site was not good enough to satisfy the participants in 33% of the test cases. If an user does not have enough information to utilize the system, the user might decide to take his business elsewhere.

104

Question Presentation 1. The use of graphics is very appropriate for this site 2. The design elements are not annoying or distracting

Range From 1 - 7 4 6 4 6 7

Result

33% 67% 33% 33% 33% 33% 33% 33% 33% 65% 33% 33% 33% 33% 33% 33%

3. The amount of information displayed is just right

3 4 6

4. The colors in this web site are pleasant 5. This site organized its information in a way that is easy for me to understand 6. This sites attractiveness invites me to go further into this site

6 7 4 5 7 3 4 5

Overall user reaction to using the system 1. Terrible - wonderful

From 1 - 9 4 5 67% 33% 33% 67% 33% 67% 33% 33% 33% 33% 67% 33% 33% 33%

2. Frustrating - satisfying

6 8

3. Dull - stimulating

NA 5

4. Dicult - easy

6 7 9

5. Inadequate power - adequate power

7 9

6. Rigid - exible

4 5 9

Multimedia 1. Overall quality of still pictures/photographs. Bad - good 2. Overall quality of colors Unnatural - natural

From 1 - 9 4 9 NA 8 9 67% 33% 33% 33% 33% 33% 67%

3. Number of available colors Inadequate - adequate

3 8

Table 12.2: Result of analyzing 105 the evaluation questionnaire

Question 6: This sites attractiveness invites me to go further into this site. According to 33% of the participant the site lacked images and animations, and did not invite the participant to go deeper into the site. The web site should help the end-user to purchase the product, however to catch and hold the users attention is a study into marketing, which we do not have time to get into in this report. Overall user reaction to using the system This and the next section is about the features which were inadequate to make the user stay on the site and to ensure that the user would like to return later. This is denitely problems which have to be dealt with. Question 1: The system is terrible - wonderful 67% of the participants graded the site to 4, which is on the negative side of the middle. Since the point to this evaluation number is to grade the users impression of the systems quality this is bad. It indicates that we have to improve the system appeal. Question 6: The system is Rigid - exible The system was criticized, for being somewhat rigid. This might be explained because the participant encountered an error during the usability test. Another factor might be the sites overall design which may not support the user in nishing the assignment. The last statement can be disputed by the answer of the other participants who found the page to be exible, even in one case very exible. Multimedia Question 1: Overall quality of still pictures/photographs. Bad -good 67% of the participants gave the grade 4 which indicates the site might utilize pictures to help the users nd and buy a product. It might be that the participant wants to see a picture of the product before buying it. It might also be that the user are looking for an experience, with ashy animations and pictures. Question 3: Number of available colors. Inadequate - adequate 33% of the participants were not satised with the amount of colors displayed on the web site. On the other hand 67% of the rest were exited about the colors. As a result we have decided not to alter the colors on the site.

Usability test
In this section the usability test will be reported. We have decided only to analyze when errors and critical errors occurs. In the test transcript TP1 106

means Test person no. 1. In the transcript below only relevant comments and ndings will be written. TM stands for Test monitor. If no errors occur during a task, it does unfortunately not mean that there are none. Finding no errors does not prove the absence of errors. If errors are not found during the tests we consider the user interface to be acceptable. Test transcript TP1 TP1 lls out the questionnaire without any questions Preliminary task: TP1 does not really do much here. TP1 only looks under a few categories. This could indicate that TP1 is not an enthusiastic user or maybe just nervous. Task 1 Creates a new customer account and logs on to the system without any problems. It is positive that TP1 does not have any problems with this task. This indicates that there are no problems with performing this task. Task 2 1: TP1 notes that there is very few products to select among, but does not have any problems with the task. Concerning TP1s comment. Since there is no actual company, where the program would have been implemented, the actual amount of data is irrelevant. TP1 does not understand the colors used to indicate the stock status, and does not see the logic behind it. This is a serious design problem. If the user does not understand the status colors, this information will only serves as noise and subsequently confuse the user. The design should make it more clear what the colors mean. Making a textual explanation could probably be a solution. 2: No problems at all Task 3 Removes the item from the shopping cart and sends the order without any problems. 107

Task 4 TP1 notes that the warehouse where the order should have been sent to is NULL, which the participant says, must be a mistake. Furthermore the form of the track & trace system could be more clear. The NULL value is an error in the system and it will be corrected. It occurred because the Track & trace system was not entirely nished. The form of the track & trace system should also be improved so that it contains more customer relevant information. 2. Questionnaire TP1 does not comment on the questionnaire. Test transcript TP2 TP2 lls out the questionnaire without any questions. Preliminary task: TP2 presses the link product catalog despite the fact that TP2 is already in the product catalog Since the front page of the web site is the product catalog this action is unnecessary. The simple solution to this action might be to make a headline in the front page so an user can see that they are in the product catalog. TP2 then browses through all the sub categories, reads the contents and report nished. Indicates that TP2 is quite enthusiastic Task 1 TP2 does not know what postal code means and TM translates it. TP1 had not logged out which TP2 notice and because of it became a little confused but solves it by closing and opening the web site. There is no log o button and TP1 really did not have any chance of logging out. This might be a minor glitch in security, as other users might have access to the prior users prole, if they use the same computer, and the rst user has not closed the browser. Therefore the website must have a log out function, to make sure the user have this option. Task 2 1: TP2 does not have any problems solving this task. 2: TP2 uses the back button which is included in Internet explorer and as a result the web site does not show the participants last purchase. So the participant goes back to the order form and re orders one more sound card, without noticing the product counter on that particular product already is 108

set to one and subsequently purchases two. This is clearly a problem which has to be corrected. The solution is not easy because the feature is provided by the program not the web site. There are multiple possibilities to solve this problem; one could be to force the site to update. We chose to solve this by disabling the feature in Internet explorer. Another possibility seen in some web shops is to make the previous page expired, but we agree that that is an annoying solution to the problem and therefore should be avoided. Task 3 Remove item and send order goes with out any navigation problems TP2 wonders: what about payment... But we do not want to go into that part of the program because it is a whole system in it self. Besides it is not allowed to make this part of the code, it has to be validated by PBS Task 4 The form of the track and trace system is not as clear as TP2 would like but other than that there is no problems. This is the second time we encounter this problem and that is a problem. It indicates that there is some redesigning to be done here to make the form easier to understand for the user. 2. Questionnaire We decided to sort the comments in this Questionnaire to make the analysis easier. The comments originally came in mixed order. TP2 comments: The page is too open and there is a lot of unused space. This is a big screen and there is almost nothing on it, maybe it would look better on my own little screen. The page is a little boring and there could be some more pictures. These statements have puzzled us a great deal. Our theories say that it is a good thing. Furthermore the experience from web sites like Goggle shows that a simple interface with limited amounts of text and commercials are very popular. The following comment gives us the idea that TP2 is used to the more confusing web sites and therefore thinks that something is missing on our web site. There is nothing to draw the attention away from what you are doing, there could be some commercials maybe from this site, but those big ones that moves is not good. 109

The rst part of the statement sounds good and is backing up the theories, but the following part of the comment, where TP2 requests commercials, is against the theories. We therefore decided not to take this entirely serious since it is only one of the test persons who mentions this. The site is simple.... If I wanted to buy anything I would like some more pictures and information about the things I could buy. This should be taken very serious and it is of course extremely important to describe the products to sell but since we have very limited time and we are focusing on the usability of the web site this is not a high priority. We know the pictures and text has to be there we just dont have the time to write all of it inn. Good colors.... it looks professional. I like the way the color is varying over the page. I really like the blue colors. These comments indicate that colors we selected were colors in TP2s taste. We choose these colors based on the our color research in section B.8 colors which apparently succeeded very well. I like that the links is at the top because that is always the rst place you look. I think the page is very easy to understand. This is indicating that the page actually is user friendly which is a good thing for our validation test. The pictures beside the categories are ugly and I cant see what it is. We obviously have to change those pictures. You used very few colors, but that is also because you dont have any commercials, when you get that it will be better. We believe that the amount of colors is appropriate and since we received some positive comments about the coloring of the web site from TP2 this comment is not weighted very high. There is no log out button. I would like that some where around my user name. We will of course have to make one of those and putting it around the user name is a good idea. 110

Test transcript TP3 TP3 lls out the questionnaire TP3 asks if it is okay to ll it out in Danish. No further problems or questions Preliminary task: TP3 would like more information on the products. As mentioned previously we will only do a limited amount of work in this area. There is no problems navigating the site. Task 1 Fills out the personal info and by accident TP3 types space ( ) after his postal code and therefore nds a major bug, because the database cannot take in a text string in the postal code. TP3 gets help and then goes on with the assignment and nishes the task without nding any other bugs in the system. This is a critical error which haves to be corrected. We have chosen to give an output that displays what has been typed wrong. This we think is the best way to alert the user. Task 2 1) no problems at all 2) no problem at all TP3 goes the shortest way to the individual products when nished with the task TP3 says that was painless We take this comment as a compliment to an user friendly design and at the same time as a comment to the error in the previous task. Task 3 TP3 removes the CPU without problems, and then TP3 accepts the order no problem Task 4 TP3 uses around 15 seconds before locating the track & trace link in the top of the page. This is the rst time any user have had problems nding a specic link. Despite this minor problem we wont change the location of the links. Mainly because TP1 didnt have any problems and TP2 praised the location of the link. It is the rst time anyone have stalled on the page, which actually ruins a very good statistic. 2. Questionnaire TP3 has a little problems understanding what is meant by the words in the questionnaire, and was helped out by the test monitor. We decided to sort the comments to this Questionnaire to make the analysis 111

easier to read. The comments originally came in mixed order. TP3 comments: There is too little info about the products. Again, we know but we are in time shortage and the amount of information about a product is not in the middle of our focus TP3 would like a little more text to guide the navigation. This could be a good idea, but we have to be careful not to insert too much text. We have to note that TP3 is the rst to have navigation problems on the web site. More tests could maybe show that TP3 is outside the average user group, or that TP1&2 is. Based on our test we have to say that TP1&2 is the average because they are the majority. TP3 was a little unsure if it was his order under the track & trace. We have to make it clear that it is only possible to see the current users orders and again we should make the track & trace form more user friendly by explaining the contents of it clearer. It wasnt paradise to be on the web site but it wasnt terrible either. It was not stimulating but it wasnt boring either, the site is quite neutral, which is good. It was satisfying that it went so fast nding the merchandise and adding it to the shopping cart. These comments are all pretty good and do not require us to make any changes. If I had been an user I would not have gured out that it was a space ( ) after the postal code that was the reason for that error. This problem will of course be corrected. TP3 had a little problems nding the track & trace but didnt really remember at the time where the TM asks about it. This indicates that he didnt really notice that he had a problem locating the link. There are no pictures... This is said in a way that makes it sound like they are missed, and with the comment from TP2 about pictures and description of each product, we conclude that he wants that as well. As explained before, this is not our main 112

focus so what we are going to do about it will be limited. All of the pictures beside the catalogs are almost the same, and I cant see what they are. The pictures have been criticized before and will be changed.

12.2

Recommendations

After having analyzed the test result, it became clear that the system did not entirely meet the participants demands. To make sure the system would be able to handle the end-users demands, some changes to the system will be necessary. We have to answer the following question, Can an end user place an order, without running into any problems?. This is the same as asking the question: Does the system live to the usability factor, usefulness?. Our analyzes shows that only one of the test participants encountered a critical error and one non-critical error. TP2 had some problems solving task 1, because TP1 had not logged out of the system. This resulted in some hesitation, but the participant recovered, and solved the problem with minimal help from the test monitor. The critical error happened when TP3 entered an invalid value into a text eld, which returned an SQL exception. These two errors however were the only time, any participants had problems solving a task. And so to answer the question. No the system did not entirely meet the users demands, and as a result cannot be said to meet the factor usefulness. Therefore at the of the test, the system was not a Usability system. To make sure the errors determined by the test were corrected the following recommendations have been made. Task 2 showed that TP1 had problems with understanding the colors used to indicate status. To make sure that this will not be a problem, the colors should be something which is known to the users from their everyday life. Red green and yellow, which is used at trac lights could be a solution. Furthermore they must be clearly visible, so they are dicult to overlook TP2 demonstrated the need for a log out option was demonstrated when the participant had to write the IP address of the site in order to remove TP1 as the registered user 113

 Based on the comments TP2 made and by the answer made by 33% of the participants to question 6 in table 12.1 under presentaion, the web site should use more pictures and graphic. However the Jacob Nilsens rule of how to design an user interface on the web is not to use gracs just to decorate[9]. Therefore our recomendation is only to use gracs to show the site contents More informaion about the products is something both TP2 and TP3 wants. When two participant agrees that they need more information before buying a product, the recommendation must be to put more information on the site TP1 thinks the pictures used to illustrate the categories are ugly and TP3 also makes a comment about this. This is something that should be changed as it might put a potential user o As TP3 commented, the track & trace function lacked information, and it was not easy to understand. To ensure the end-user will not misunderstand the information it should be presented in an easy to read way as well as being easy to survey We also wanted to nd out the answer to the question: Does the systems functions support the user in solving the task? This question concerns the Usability factor usefulness. We wanted to measure if the functions on the website could be used to solve user tasks. And we discovered that they could to some extent. However TP3 had a serious problem when an error was discovered in task 1. TP1 discovered the need for a log out function, and nally TP1 noted that it was not possible to see which warehouse the order was sent to. According to our test if these problems are solved the functions on the web shop will be useful.

114

Part V Academic requirements

115

Chapter 13 Academic requirements

This study report will be divided into three sections, where we will reect upon how the process went, and discuss the dierent phases. In section 13.1 we will look at how the four phases of the project the analysis,the design, the implementation and the test In section 13.2, we will look at the projects main focus , the user interface. in section 13.5 we will look at the tests we made during the project. We also in section 13.1 discuss the databases and server.

13.1

Analysis, design, implementation, and test

In this section we will look at how the work process in each of the four phases in the project went, and explain our choices and reect upon them.

13.1.1

Analysis

In this phase of the project we spend a lot of time discussing on the steps we should take in the project. We followed the SAD curse, did the exercises, which corresponded very good to what we had to do in order to make our project. Every decision and task at this point were discussed in the whole group and noted on the blackboards. We had some early problems in deciding what system we should make. At rst we decided to make an ordinary warehouse management system to an online warehouse, but some of the group members quickly came up with the idea that we should make an online web portal listing computer hardware from dierent suppliers all over Europe. And so we began planing for the development of the system.

116

One of our lecturer pointed out that it would be unwise to code such a system in Java, and there was some concern, that the system we had begun to develop, did not contain enough classes to make a project in the scale required by the study guidelines. We decided to go back to the original idea. However, we liked the web part of the project, and decided to make a website where a customer could browse around and place an order, which would be sent to a warehouse for processing. At this point we had lost a considerable amount of time, and began to work hard in order to catch up. Each group member became responsible for a part of the analysis. This of course meant that not all of the group members knew what was going on in other part of the project. To ensure the project stayed on course, everything made was controlled by at least a few other members of the group In retrospect, it would properly have been a good idea if we had stuck to one idea. Because out of all this we had some trouble writing our system denition in the right academic way and also so it would correspond to the system we actually would make. We had a similar problem concerning the class diagram, which went through considerable changes right up until we began coding the system. In the beginning it was very dicult for us to separate the problem and application domain this resulted in use cases that used functions instead of events. Early in the process we also became too ambitious and began to design a very large and complex system, which consisted of an administration part to administrate statistics, employees, products and warehouses. Fortunately we realized this would become to large for us to make in the time available, and so we simplied it. In the end we decided that we wanted to make a home page using JSP, that could be used to create customer and order objects that would be stored in a database. The system would also be a warehouse storage program that would be used to view orders and then process them. We did this because we liked the challenge of making a system that would use network and databases. We also wanted to concentrate on creating a good user interface and believed we, by working with this idea would get the opportunity.

13.1.2

Design

This section concerns the work process in the design as well as how the design is connected with the analysis and the implementation. 117

We had some problems getting the design document done in time for the second review. The two weeks between the rst and second review was very little time, and our work did became somewhat frantic as we worked to meet the deadline. The material we delivered was a result of this, and not nished at all. And due to this we continued working with the design for some time after this. The nal changes in the design document did come later as a result of working with the implementation. We discovered there was something, which could be done dierently, and we choose to add the changes to the design document, to make it consistent to the program. We felt that the things in the documentation should reect the nished program, but it must be pointed out that not everything in the design document has been implemented. In this phase the work process was both co-operation and individual work. To ensure the work everybody did was adaptable with the rest of the project. The while designing the database we found minor problems with the structure. We will explain the problems we had, and how we solved them, in section 13.3. Later in the design phase we noticed something strange in the OOA&D method. In the application analysis the method deals with the user interface but neither the architecture design nor the component design to follow up on this work. This is somewhat puzzling because the work done in the analysis seems to be wasted, unless you use another design method to create the user interface. We decided to combine the OOA&D method with a method better suited for graphical user interface design explained in the DEIB course.

13.2

User interface

In this section we will discuss the dierent problems we encountered as well as our experiences and the decisions we made, involving the work with user interfaces.

Warehouse and web shop GUI

The analysis made it clear that there was two kinds of requirements for the system, so we had to design the GUI according to these. The warehouse GUI had to be a professional tool, which should enable the user to quickly get the 118

task done, with a minimum of eort and concentration. The web shop GUI had a dierent purpose, to sell products. We decided that a website designed to e-commerce, should be visually interesting, but not be an interference in solving the task, and not an annoyance. we had early on some design suggestions to how the user interface should look like. One of the members form the group made a sketch of how the user interface could look like, on a computer using the paint program Photoshop. The Sketch had so many details that the rest of the group desired to use i as a reference point as to how the user interface approximately should look like. To that end we decide, based on the DEIB lectures, to set up some design rules for the interface. Here are an explanation of how and why we choose these rules.

Gestalt Laws
We decided to use the Gestalt laws of perceptual organization when we rst heard of them during a DEIB lecture. The reason why we wanted to work with it, was that we would like the information on the user interface to be understood by the end users without any misunderstandings. We meant the Gestalt laws could be helpful in meeting this goal. We utilized the Gestalt most heavily on the design of the web shop, because we chose to test this in a usability test. We had some diculties nding appropriate literature which concerned the subject, as the library did not have the books we looked for and the librarians looked baed when we asked for books or articles concerning the Gestalt laws. But in the end the library found a book we could use. During the design we tried to keep the Gestalt principle in mind, which meant that we tried to make related objects stand out and be identiable as being part of the same group. A downside working with the Gestalt laws was that the ve principles merge with one another and as a result made it dicult for us to work with. On the other hand it did make sense in the project to focus on some regulations on the design in order to make an user oriented user interface. Therefore using the Gestalt law of perceptual organization makes sense, as the Gestalt 119

laws set up rules to do just that.

Colors and text

In order to make an user interface, which helps getting information across and support the systems purpose, sales system, we came up with an idea of looking at how these two areas could be utilized. The idea came as a result of a brainstorm, which came about because we wanted to focus more on the user interface, and wanted to explore these two areas. We decided to set up some design rules concerning use of colors and text. These rules apply for the design of the warehouse GUI as well as the web shop GUI. However, the use of colors where going to be used most prominently in the web shop user interface. We estimated the use of colors could benet the sales environment and help set up the web shop as both a conservative and reliable business, which would do little good in the warehouse GUI where customer attraction means nothing. The choice of which font type to use was based partly on the fact that we, the designers, liked it and partly because of guidelines we found on the web. During the test we did ask the participant to evaluate the colors on the site, to make sure the web shop had colors which suited the websites purpose. The result is shown in 12.1.

Frames
Another thing we did as part of the focus on the user interface of the system was to work thoroughly with designing frames. as we meant we by focusing on how the implemented interface should look like would be able to better understand and visualize the user interface early on in the process. We believed we would get a tool which would be valuable in setting up how the website should be designed. All of us already had some experience working with frames, we had worked with HTML before, and this had some inuence in us choosing to work with frames in the project. We had some problems with frames, as the page location bar and the shopping cart did not update automatically. This problem had to be resolve by 120

making java scripts. We believe this should not be a problem, if the HTML interface was made on one single page.

Wisdom
Because we focused on the GUI, we choose to use the wisdom method taught to us in the DIEB lecture. The wisdom method was a tool when designing user interfaces, it gave us a general course to take, from the use cases to nding out what information the dierent screens should contain and which functions they should handle. After this the only thing to do was to decide how the actual GUI frames and windows should look. Because we did not have a lot of time, we only did two essential use cases. Further more we were told at the rst review only to make on use cases, ass making more would be to much work. The two use cases are however the most central ones in the whole system. The use cases we choose were Process order and Place order. Process order because this is the central use case for the employee and therefore it must function properly, and Place order because it is very central to the system that the user has no problems when placing an order. We began making use case diagrams for the two. We had to make interaction models, but we ran into some problems, as we had no idea how to actually make them, and the examples we had from DEIB, consisted of a lot of useless information. Some members missed a couple of work days trying to gure out what to do, but after a meeting with a teacher we knew what we had to do, and the process went fairly fast. As we made the dialog models ran we into another problem with the place order use case. We wanted to give the user of the system a lot of options, so he/she can cancel what he/she does when he/she wants, and also have other optional choices. However, the notation we used, does not t particularly well for this kind of use case and we are not sure if the dialog model is absolutely correct. Out of these diagrams we made interaction space models on which we based the design of the GUI. We could not do this for the whole system so we had to go with what we felt was right, and by using our Design rules.

13.3

Database design

At the very start of the project we decided to store our data in some kind of a SQL database. The reason we used MySQL database, was because some of the group members knew it from personal web development projects. 121

When designing the database we had some problems with circularizes in our design, which we could not work around. We were afraid there would be problems inserting data, but we found out that because our entities are not mutually depending of one another, and the tests we made did not show any errors, the database system could be used. We know that the database is not designed perfectly, however database design and persistence is not part of our focus area. As we implemented the database, we created and dropped both databases and a lot of tables, as we designed and redesigned. During so, we learnt that the MySQL syntax and SQL are denitely not the same thing. Not all SQL commands works in MySQL. It may have been the MySQL version 4.1.7 we used, but many commands, which should have worked, did not. As an example the ALTER query did not work as expected. We could not use the alter command to change foreign or primary key, but it did work when used with any other attributes. We discovered that any changes made in the design which involved foreign keys, would result in us dropping one or more tables. The reason we decided to implement the database while still working on the design was that we could see if our design actually worked or not. To make sure our database could handle a situation where data was deleted or updated the ON DELETE CASCADE and ON UPDATE CASADE, commands were used. This was done to make sure that if data was updated or deleted in one table, data in other tables with a foreign key to the rst table would be either updated or deleted. The ER-diagram at gure 8 shows that the delivery details, represented as attributes starting with delivery, were not existing in the early design of the database.

13.4

Implementation

Our implementation phase started out pretty well and we got our model classes and a basic warehouse client GUI made fast. We decided to divide the implementation out between the members of the group, so some worked with the database, some with the warehouse server, and others with the clients. Minor problems occurred with that but the problem that kept re122

turning all the way through the implementation phase were design changes and errors. A lot of time were used to x minor changes, that sometimes grew into bigger problems. The decision about using RMI for our network functionality proved to be an good idea since it was very easy to implement into our system. More advanced functions like a callback between the clients were left out though, since we did not have any courses in distributed programming, and not enough time to study it further. The web shop were made with JSP and acts like a client on the warehouse server, sharing methods with the warehouse client. We had some problems setting up the servers to run JSP and a RMI and we ended up with using java version 1.5 instead of the advised version 1.4. Sadly the system became really hard to install on every platform we tried it on, The user need a web server, a jsp server, and registries for the RMI and java installed and setup and that is not easy for most people to do.

13.5

Test

Usability test
We decided to use Jerey Rubins book [13], as a guide to making the usability test. To do so we decided we wanted to make proles of the participants, and therefore made a background questionnaire. The qustionnarie should provide us with information about whether the participants had prior exsperience with a web shop. the demogracally At the day of the test, we had invited the rst test participants to come at around 14.00 and the next participant to come half an hour later and so on. We just had enough time, in the test lab, to make a pilot test in order to make sure no major mistakes would occur. The test went rather smoothly, but we did encounter a few glitches along the way. TP3 encountered an SQL error, which he could mot recover from without outside help. The test monitor which could not see the server, also had to be helped in order to get on with the test. The interference did not seem to ruined anybodys consentration and the rest of the rest of the test 123

went as it should. To avoid the test participants were to nervous, we showed them what was on the other side of the one side mirror. We did this to make them more condence about the whole situation. The group had an positive experience with the test. The one who had not tried conducting a test before, could see . The data which we got from the test was immense and gave us a good understanding of the things in the system which should be change and which worked as intended. On the down side we may have found more usability errors if we had tested more people, but we decided that we did not have time to analyze more data. We made the decision that some of us would be responsible of analyzing the data, and make a recommendation based on the test.

124

Part VI Conclusion

125

Chapter 14 Project conclusion

In this project we gained knowledge and experience of both application design and application implementation. Furthermore we obtained experience in testing a system. In order to develop a system that ts the requirements from the warehouse employees and the website customers, it is important to include them in the development process. As we were self employed in this project we had to construct the foundation of the project our selves. Our only external experience where with the three test persons, who we got great response from, they pointed out quite a few relevant things to correct and improve in the system. We would continue to use test persons if we were to implement the rest of the system because a potential user spot the most inadequacy in a system. We tried to organize ourselves as a professional development team, to maximize the projects outcome. But quickly found out that it was a greater challenge than expected. We used the OOAD method in the development process. The method were good for the analysis and for most of the design phase, but when we came to the design of our interfaces it became inadequate. We started using a method from the DIEB course, which were more appropriate for designing user interfaces. Just before starting on the implementation phase, decisions were made on what was realistic implementing in the amount of time we had left. The work assignments the secretary, login and logout on the warehouse client, the signaling from the server to the warehouse when orders are placed were removed. 126

The implementation of the designed system went good. We got the web shop almost fully implementated and a functional warehouse client, capability of handling orders. The warehouse administration area, payment system and an e-mail notication were left out for future implementation. This was done to save time, and stay on focus with the user interfaces. The algorithm used by the web shop to select a warehouse automaticly could have been made more advanced, but again that was not in our focus area. Our database design works and fulls our systems needs, but yet not perfect. Since the database design courses are placed in later semesters we decided only to use a reasonably amount of time to look into database design and go from there. At last we can conclude that the system has reached the goals for this semester and the goals elaborated and prioritized in the analysis and design document.

127

Part VII Appendix

128

Appendix A Code test

Throughout the implementation of the system a lot of tests were made. To ease the testing a tool called JUnit1 were used. The test method used is a bottom-up testing, starting with the primitive methods moving towards the main functionality.

A.1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Class tests

import j a v a . u t i l . Date ; import j u n i t . framework . TestCase ; import c l a s s e s . ; import j a v a . u t i l . Date ; / @author d105a T e s t s e t u p f o r t h e model c l a s s e s / public c l a s s U n i tT es t extends TestCase { private Employee t e s t P e r s o n ; private Category t e s t C a t e g o r y ; private Customer tes tC u s to m er ; private Order t e s t O r d e r ; private Product t e s t P r o d u c t ; private Warehouse tes tWa r eh o u s e ; private f l o a t p r i c e = 3 3 4 ; protected void setUp ( ) { t e s t P e r s o n = new Employee ( 2 , name ) ; t e s t C a t e g o r y = new Category ( 1 , a s u s , motherboard , p i c t u r e ) ; tes tC u s to m er = new Customer ( 1 , u s e r , p a s s , name , a d d r e s s , 9 0 0 0 , a a l b o r g , denmark , 9945 , e m a i l ) ;

http://www.junit.org

129

23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79

t e s t O r d e r = new Order ( 1 2 , s t a t u s , 3 4 , 1 2 , 1 , new Date ( ) , new Date ( ) , track ) ; t e s t P r o d u c t = new Product ( 3 2 , 1 , name , vendor , model , p r i c e , d e s c r i p t i o n , p i c t u r e , 3 4 5 , true ) ; tes tWa r eh o u s e = new Warehouse ( 1 2 , name , a d d r e s s , 3 4 , c i t y , co u n tr y , e m a i l ) ; } protected void tearDown ( ) { tes tP er s on = null ; tes tC ategor y = null ; tes tC u s to m er = n u l l ; tes tO r der = null ; tes tP r oduct = null ; tes tWa r eh o u s e = n u l l ; } / testCase1 () Employee c l a s s / public void t e s t C a s e 1 ( ) { a s s e r t E q u a l s ( 2 , t e s t P e r s o n . getEmployeeID ( ) ) ; a s s e r t E q u a l s ( p o u l , t e s t P e r s o n . getName ( ) ) ; } / testCase2 () C at e g or y c l a s s / public void t e s t C a s e 2 ( ) { a s s e r t E q u a l s ( 1 , t e s t C a t e g o r y . g etC a teg o r y ID ( ) ) ; a s s e r t E q u a l s ( a s u s , t e s t C a t e g o r y . getName ( ) ) ; a s s e r t E q u a l s ( motherboard , t e s t C a t e g o r y . g e t D e s c r i p t i o n ( ) ) ; assertEquals ( picture , testCategory . getPicture () ) ; } / testCase3 () Customer c l a s s / public void t e s t c a s e 3 ( ) { a s s e r t E q u a l s ( 1 , tes tC u s to m er . getCustomerID ( ) ) ; a s s e r t E q u a l s ( u s e r , tes tC u s to m er . getUserName ( ) ) ; a s s e r t E q u a l s ( p a s s , tes tC u s to m er . getPassWord ( ) ) ; a s s e r t E q u a l s ( name , tes tC u s to m er . getName ( ) ) ; a s s e r t E q u a l s ( a d d r e s s , tes tC u s to m er . g e t A d d r e s s ( ) ) ; a s s e r t E q u a l s ( 9 0 0 0 , tes tC u s to m er . g e t P o s t a l C o d e ( ) ) ; a s s e r t E q u a l s ( a a l b o r g , tes tC u s to m er . g e t C i t y ( ) ) ; a s s e r t E q u a l s ( 9945 , tes tC u s to m er . getPhone ( ) ) ; a s s e r t E q u a l s ( e m a i l , tes tC u s to m er . g etE m a i l ( ) ) ; } / testcase4 () Order c l a s s / public void t e s t c a s e 4 ( ) { a s s e r t E q u a l s ( 1 2 , t e s t O r d e r . getOrderID ( ) ) ; assertEquals ( status , testOrder . getStatus () ) ; a s s e r t E q u a l s ( 3 4 , t e s t O r d e r . getCustomerID ( ) ) ; a s s e r t E q u a l s ( 1 2 , t e s t O r d e r . getWarehouseID ( ) ) ; a s s e r t E q u a l s ( 1 , t e s t O r d e r . getEmployeeID ( ) ) ; a s s e r t E q u a l s ( new Date ( ) , t e s t O r d e r . g e t C r e a t i o n D a t e ( ) ) ; a s s e r t E q u a l s ( new Date ( ) , t e s t O r d e r . g e t S h i p p i n g D a t e ( ) ) ;

130

80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110

} / testcase5 () Product c l a s s / // g e t P r i c e method i n t h e p r o d u c t c l a s s n ot t e s t e d due t o complications t e s t i ng f l o a t values public void t e s t c a s e 5 ( ) { a s s e r t E q u a l s ( 3 2 , t e s t P r o d u c t . g etP r o d u ctID ( ) ) ; a s s e r t E q u a l s ( 1 , t e s t P r o d u c t . g etP r o d u ctID ( ) ) ; a s s e r t E q u a l s ( name , t e s t P r o d u c t . getName ( ) ) ; a s s e r t E q u a l s ( model , t e s t P r o d u c t . getModel ( ) ) ; assertEquals ( des cr i pti on , testProduct . getDescription () ) ; assertEquals ( picture , testProduct . getPicture () ) ; as s er tE qual s (345 , testProduct . getQuantity () ) ; a s s e r t E q u a l s ( true , t e s t P r o d u c t . g e t I s P r o c e s s e d ( ) ) ; } / testcase6 () Warehouse c l a s s / public void t e s t c a s e 6 ( ) { a s s e r t E q u a l s ( 1 2 , tes tWa r eh o u s e . getWarehouseID ( ) ) ; a s s e r t E q u a l s ( name , tes tWa r eh o u s e . getName ( ) ) ; a s s e r t E q u a l s ( a d d r e s s , tes tWa r eh o u s e . g e t A d d r e s s ( ) ) ; a s s e r t E q u a l s ( 3 4 , tes tWa r eh o u s e . g e t P o s t a l C o d e ( ) ) ; a s s e r t E q u a l s ( c i t y , tes tWa r eh o u s e . g e t C i t y ( ) ) ; a s s e r t E q u a l s ( co u n tr y , tes tWa r eh o u s e . g etC o u n tr y ( ) ) ; a s s e r t E q u a l s ( e m a i l , tes tWa r eh o u s e . g etE m a i l ( ) ) ; } }

A.2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 import import import import

Functionality tests
j u n i t . framework . TestCase ; classes .; java . u t i l . ArrayList ; j a v a . u t i l . C a l en d a r ;

/ @author d105a getOrders f u n c t i o n t e s t / public c l a s s F u n cti o n T es t extends TestCase { private s t a t i c O b j ect [ ] [ ] orders ;

private A r r a y L i s t o r d e r L i s t ; private Order tmpOrder ;

131

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

private i n t WAREHOUSE ID = 1 ; protected void setUp ( ) { RMIConnection rmic = new RMIConnection ( ) ; try { o r d e r L i s t = RMIConnection . d1 . g etO r d er ( Mainprogram . WAREHOUSE ID) ; } catch ( E x cep ti o n e ) { } ; } protected void tearDown ( ) { } public void t e s t C a s e 1 ( ) { assertEquals (9 , orderList . s i z e () ) ; } public void t e s t C a s e 2 ( ) { tmpOrder = ( Order ) o r d e r L i s t . g e t ( 6 ) ; a s s e r t E q u a l s ( Pending , tmpOrder . g e t S t a t u s ( ) ) ; a s s e r t E q u a l s ( 1 2 , tmpOrder . getOrderID ( ) ) ; C a l en d a r tmpc = C a l en d a r . g e t I n s t a n c e ( ) ; tmpc . s e t ( 2 0 0 4 , C a l en d a r .DECEMBER, 1 5 ) ; a s s e r t E q u a l s ( tmpc . getTime ( ) , tmpOrder . g e t C r e a t i o n D a t e ( ) ) ; } }

132

Appendix B Test plan

B.1 Problem statement/test objectives

The goal of the test is to nd possible aws in the design which prevents a smooth and problem free usage of the application. To accomplish this the problems in focus in this test are: Can an end user place an order, without running into any problems? Will the system take up to much of the users time? Does the systems functions support the user?

B.2

User prole

The test involved three participants, at the research lab 1. at Aalborg university. All of the participants were tested on December 6, 2004. The participants were chosen based on their background, as shown in table B.1.

B.3

Methodology

The test will consist of a validation test, as well as two questionnaires. [13] The rst is a background questionnaire, which gather information about the test persons. The other concerning the participants nal evaluation of the system. 133

Characteristic Age Sex Education/work Computer experience based on time used each week Previously experience with online shopping

Range 18-21 Male/Female Students More than ve hours pr. week

Frequency distribution 33% below 20 years 67 % male 100% 33%

Yes/No

Yes 100%

Table B.1: User proles

B.3.1

Greeting and background questionnaire

The test monitor reads the orientation script aloud, which contains information concerning the test and the participants part in the test. The test monitor will insure the participant complete anonymity and that the test and the result only will be used in this project. Moreover, the participant will be informed that the test sessions will be recorded, and observed by the rest of the project group through a spy-mirror. The test monitor will ensure the participant that there is no right solution to the task, and that the participant is not being tested and should take whatever time needed.

B.3.2

Validation test

The participant will be asked to carry out a number of tasks, which will imitate how the end-user is going to utilize the system[13]. The test monitor will set up a scenario, which must look like a scene which the test participant can identify with. The participants, are asked to imagine being at home or where he/she usually buys products online. The participant is handed a note with a task on it, and is asked to solve it. The test will be observed, the observers will note any diculties and errors encountered. The test monitor will note any relevant behaviors and comments concerning the participant, and any disturbance, which may have inuence on the test.

B.3.3

Participant debrieng

After the nal task, the test monitor will debrief the participant. The computer screen will be turned o and the debrieng will be carried out with the participant still sitting in front of the PC. The debrieng includes: 134

 The participant lls out the second questionnaire The Test monitor asks if the user has any additionally comments about the system When the test is nished, the test monitor thanks the participant for being part of the test.

B.4

Task list

Preliminary task: Browse through some of web pages to get some familiarity with the web site and end the task by returning to the start page. The task imitates a situation where the user encounters the web site for the rst time. This task is fairly easy to accomplish, and is meant to make the participant more at ease, and less nervous about the situation. Task 1: register yourself as a customer and log on the system. This assignment is testing the diculty level of registering on the web page. If this part is presenting any problems it will be a major problem, because if rst time customers encounter problems it could easily scare them away. Logging on the system is supposed to be a quick task as it is a function that is done often. Task 2: Find a SoundBlaster sound card in the catalog and add it to the shopping cart Find the cheapest Pentium 4 CPU and add it to the shopping cart The assignment is representing a realistic purchase online, which is the primary purpose of the web site. It should identify any problems the participant may have nding a specic piece of hardware on the web site. Task 3: Remove the Pentium 4 CPU from the shopping cart and send the order After choosing a product, a customer may reconsider, and should therefore be able to remove that product from the shopping cart. The task should show if the customer has any diculty nding or using this functionality. Task 4: Conrm the order has been sent by using the track & trace system. The customer may want to conrm that the order has been sent to the right warehouse, or just make sure it has been received. 135

B.5

Test environment

The execution of the test is conducted in an electronic observation room setup. The test monitor and test participants were both in the test room, while the observers and technicians, all of which where members of the project group were behind a two-way mirror in the observation room and the technician room. The lighting of the room is going to emulate a typical oce, and must be bright enough to allow the cameras to capture the test participants facial expression during the test. The furnitures in the test room is not placed according to any particular order, as we decided to use the existing oce environment setup in the test room, with desks chairs and a PC. Items needed for the test. A PC: Which the participant will use to browse the systems user interface A pen: To ll out the questionnaires The implemented system must be able to accomplish all the functionality required by the tasks as well as the nished graphical interface design. The test participant is expected to evaluate the graphical interface and test whether or not the functions are usable.

B.6

Test monitor role

The primary function of the test monitor is to ensure that the test is running smoothly. First he will read an orientation script for the test participant and make sure that there are no questions. Then he hands the participant the background questionnaire. At the usability test the test monitor will give the participant the assignments. The assignments are handed over one at a time, so the participant only works on one task at the time. The secondary work assignment for the test monitor is to keep the participant calm and help if the participant gets stuck.

B.7

Evaluation measures

We will measure the number of participants who solves the tasks and furthermore measure any errors or where they have diculty in solving the task. The errors are classied according to the list below[13]. 136

 Comments and observations - test monitor and observers note when the participants have diculty solving a problem. Which is manifested by either a participant is going back and forth through the web sites or if he pause for more than 15 seconds or express some doubt Noncritical error. The participant makes an error but is able to recover Critical error, the participant makes an error and as a result cannot nish the task

B.8

Colors

The choice of colors in a GUI should be inviting and appealing toward the user. According to Ben Scneiderman color speeds recognition when dealing with several tasks and functionality [14]. He also implies that colors should be conservatively used and limited to a few otherwise it might confuse the viewer. Furthermore the choice of colors may have an embedded meaning which dier on cultural background, for example red means hot, blue means cold, black means death and white means birth but on the other hand in Japan and India white and black has the opposite meaning white meaning death and black meaning birth[4]. Today on the World Wide Web colors have obtained a general accepted meaning, blue text for example means a link and purple text means a visited link. It is also recommended to use these general standards, as the user otherwise might get confused, especially if you were to switch the use of blue and purple link color.

Color symbolism
Color meanings has a general cultural understanding among the population because of our general perception taught through media, so without knowing it everyone has some degree of understanding. Below we have accumulated some examples of what general colors symbolize[5]. Blue Sky, Sea, Water, Religious feeling, Peace, Faith, Stability, Melancholy, Trust, Loyalty, Wisdom, Tranquility, Integrity. Red Fire, Love, Passion, Energy, Revolution, Anger, Power, Debt, Danger, Heat, Warning. 137

Green Money, Growth, Environmentally friendly, Fertility, Envy, Spring, Freshness, Stability, Loyal, Healing. Yellow Energy, Sun, Happiness, Cheery, Creativity. Orange Joy, Sunshine, Creativity, Determination, Success, Encouragement, Energy, Autumn, Construction.

Purple Royalty, Power, Nobility, Luxury, Spirituality. Brown Conservative, Stable, Outdoors, Fall, Earth, Organic. Grey Uncertainty, neutral, between light and dark, time to make choices.

B.9

Frames

To make a consistent website we have briey analyzed the way frames are used throughout the World Wide Web. We will here briey describe how we use frames in our design.

Figure B.1: Frames description The top frame usually consist of a logo/slogan, navigation is recently consistently being adapted into the top frame, contrary to placing the navigation in the left frame. The reason for placing the navigation in the top frame is because a left side menu takes up a lot of space and the possibility of creating nice dropdown 138

menus has through the last few years been available without lacking usability. Left side is most commonly used as navigation link space, and advertising banners is often placed below such navigation link space. The main content area is placed in the middle of the page; it can contain large amounts of data contrary to boundary frames. Right frame is usually used for search link and advertising. Bottom frame is sometimes used for shopping cart but is most commonly not used at all.

B.10

Font types

Fonts are divided into four main categories text fonts, display fonts, decorative fonts and specialty fonts. We only need to look at text fonts because display fonts, decorative fonts and specialty fonts is commonly not supported on all systems, these fonts are therefore irrelevant, although we can mention that these fonts are used in word processors and computer-assisted drawing programs, for more personal text graphics. Text fonts can be divided into two subcategories serif and sans-serif fonts. Serif text fonts are used for long passages of text, serifed type is also thought to be easier on the eyes. Examples of serif text font family are Times New Roman, Georgia and Garamond.

Figure B.2: Serif fonts The thing serif fonts have in common is a high degree of readability, which is why serif fonts is commonly used in books, magazines and newspapers. Examples of sans-serif text font family are Arial and Verdana.

Figure B.3: Sans-serif fonts 139

Sans-serif fonts are especially used on websites because it is readable even in small sizes which make it compatible with low pixel resolutions. Serif fonts like Times New Roman are not very legible in small point sizes because the serifs make the letters look broken. Sans-serif fonts is legible in a way that makes it quick and easy for an user to get an overview of even great amounts of information. This means sans-serif fonts is a good choice especially for navigation menus. Other features like italic, bold and underline styles can be added to fonts to emphasize meanings of the text, it is not recommended to use italic style on web applications[4].

B.11

Gestalt laws

The visual perception is important in a user interface. This is because the way the user interface is organized has an inuence on the way the user understands the systems information. According to Jenny Preece[12], the gestalt laws of perceptual organization can be an eective tool when making a comprehensive design. We have chosen to use the gestalt laws of perceptual organization in this project. Therefore the design of the user interface will support the information by utilizing the Gestalt laws. It should be noted that the Gestalt laws are not empirically proved, but according to slide 4.23 from the DEIB course[16], it is still a good help when designing. The Gestalt law of perceptual organization is split into ve principles, proximity, similarity, closure, continuity and symmetry[12]. We have chosen to employ these principles, hereby we get a tool which will help us communicate the website information to the user without any interferences. When talking about objects in the following, it will include every element like pictures, text and so on in the user interface. Proximity: States that objects close to one another is perceived as one unit. As such this principle will be used to group information together and make the user conceive the objects as being related Similarity: Objects of similar shape is often perceived as belonging together. Some pictures and thumpnails, which will be used on the website, will be seen as a group because of their similarity Closure: An incomplete gure is perceived as the complete object, the viewer will put in the missing parts themselves to complete the gure. The design will use this principle, heavily by enclosing related 140

information, to make sure the information is conceived as belonging together Continuity: Is a number of objects organized in such a manner that it makes them appear belonging to the same pattern, instead of being seen as individual objects. We will follow this principle, and placing objects near one another so the user will conceived them as united Symmetry: Placing objects symmetric in the user interface is perceived by the viewer as a border creating a gure. We will not consciously follow this principle, but cannot reject that it is somewhere used As a nal note Carlos Pedroza state that the Gestalt grouping laws should not be seen independently, as it inuences one another [10]. The result is that perception is a combination of all of the principles. This means the user interface in this project is a combination of all the principles.

B.12

Dialogue style in user interfaces

There exist dierent interaction styles, below we briey describe the most common used. [14] Command language Command language is a direct way of manipulating with a system, examples of this could be command prompt of windows or linux. The advantages is its exibility and capability, it is also potentially rapid for complex tasks. The disadvantages is that it requires substantial training and memorization, it is dicult to retain and has a poor error handling. Menu selection Menu selection is used in GUIs when you want a list of items or links the user can select. The advantages of menu selection is that it reduces key strokes, higher level of recognition, accurate and structures decision making. Some disadvantages can be that it requires screen space and it is sometimes difcult to nd appropriate terminology and the complexity of several menus can be overwhelming for the user. Direct manipulation Visual representation of objects and actions, using pointing, zooming and panning the user can rapidly perform operations in GUIs. The advantages is that it visually presents the task it is easy to learn and retain encourages 141

exploration and has a high subjective satisfaction and errors can be avoided. The disadvantages is that it requires a graphic display and pointing device, it needs more programming eort. Form ll-in Form ll-in is used in GUIs when the user needs to provide data, labelled elds is used for this purpose. The advantages is that it simplies data entry, all information is visible and it is fast for specic types of data and last the user only need modest training. The disadvantages could be that it consumes screen space. Natural language When users interact through their natural language in a system. The advantages is that it relieves burden of learning syntax. The disadvantages is that it requires more keystrokes it is rather unpredictable and therefore requires a clarication dialog.

142

Appendix C Database design

The database consist of these eight tables:
+-----------------+ | Tables_in_d105a | +-----------------+ | categories | | customers | | employees | | orderDetails | | orders | | productDetails | | stockStatus | | warehouses | +-----------------+

The queries to create the tables and the resulting MySQL overviews are listed below. We list the tables in order of dependency, e.g. categories before productDetails.

customers
CREATE TABLE customers (customerID INT AUTO_INCREMENT, username VARCHAR(20) NOT NULL, password VARCHAR(32) NOT NULL, name VARCHAR(60) NOT NULL, address VARCHAR(50) NOT NULL, postalCode INT NOT NULL, city VARCHAR(30) NOT NULL, country VARCHAR(30) NOT NULL, phone VARCHAR(14), email VARCHAR(60) NOT NULL, PRIMARY KEY (customerID)); +------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+-------------+------+-----+---------+----------------+ | customerID | int(11) | | PRI | NULL | auto_increment | | username | varchar(20) | | | | | | password | varchar(20) | | | | | | name | varchar(60) | | | | | | address | varchar(50) | | | | | | postalCode | int(11) | | | 0 | | | city | varchar(30) | | | | | | country | varchar(30) | | | | | | phone | varchar(14) | YES | | NULL | |

143

| email | varchar(60) | | | | | +------------+-------------+------+-----+---------+----------------+ 10 rows in set

employees
CREATE TABLE employees (employeeID INT AUTO_INCREMENT, name VARCHAR(60) NOT NULL, PRIMARY KEY (employeeID)); +------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+-------------+------+-----+---------+----------------+ | employeeID | int(11) | | PRI | NULL | auto_increment | | name | varchar(60) | | | | | +------------+-------------+------+-----+---------+----------------+ 2 rows in set

categories
CREATE TABLE categories (categoryID INT AUTO_INCREMENT, name VARCHAR(60) NOT NULL, description TEXT, picture VARCHAR(60), PRIMARY KEY (categoryID)); +-------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-------------+------+-----+---------+----------------+ | categoryID | int(11) | | PRI | NULL | auto_increment | | name | varchar(60) | | | | | | description | text | YES | | NULL | | | picture | varchar(60) | YES | | NULL | | +-------------+-------------+------+-----+---------+----------------+ 4 rows in set

warehouses
CREATE TABLE warehouses (warehouseID INT AUTO_INCREMENT, name VARCHAR(60) NOT NULL, address VARCHAR(50) NOT NULL, postalCode INT NOT NULL, city VARCHAR(30) NOT NULL, country VARCHAR(30) NOT NULL, email VARCHAR(60), PRIMARY KEY (warehouseID)); +-------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-------------+------+-----+---------+----------------+ | warehouseID | int(11) | | PRI | NULL | auto_increment | | name | varchar(60) | | | | | | address | varchar(50) | | | | | | postalCode | int(11) | | | 0 | | | city | varchar(30) | | | | | | country | varchar(30) | | | | | | email | varchar(60) | YES | | NULL | | +-------------+-------------+------+-----+---------+----------------+ 7 rows in set

144

orders
CREATE TABLE orders (orderID INT AUTO_INCREMENT, status ENUM(Pending, Being processed,Shipped) NOT NULL DEFAULT Pending, customerID INT NOT NULL, warehouseID INT NOT NULL, employeeID INT, deliveryName VARCHAR(60), deliveryAtt VARCHAR(60), deliveryAddress VARCHAR(50), deliveryPostalCode INT, deliveryCity VARCHAR(30), deliveryCountry VARCHAR(30), creationDate DATE NOT NULL, shippingDate DATE, trackAndTraceNumber VARCHAR(30), PRIMARY KEY (orderID), FOREIGN KEY (customerID) REFERENCES customers (customerID) ON UPDATE CASCADE, FOREIGN KEY (warehouseID) REFERENCES warehouses (warehouseID) ON UPDATE CASCADE, FOREIGN KEY (employeeID) REFERENCES employees (employeeID) ON UPDATE CASCADE); +---------------------+--------------------+------+-----+------------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------------+--------------------+------+-----+------------+----------------+ | orderID | int(11) | | PRI | NULL | auto_increment | | status | enum(Pending, | | | Pending | | | | Being processed, | | | | | | | Shipped) | | | | | | customerID | int(11) | | MUL | 0 | | | warehouseID | int(11) | | MUL | 0 | | | employeeID | int(11) | YES | MUL | NULL | | | deliveryName | varchar(60) | YES | | NULL | | | deliveryAtt | varchar(60) | YES | | NULL | | | deliveryAddress | varchar(50) | YES | | NULL | | | deliveryPostalCode | int | YES | | NULL | | | deliveryCity | varchar(30) | YES | | NULL | | | deliveryCountry | varchar(30) | YES | | NULL | | | creationDate | date | | | 0000-00-00 | | | shippingDate | date | YES | | NULL | | | trackAndTraceNumber | varchar(30) | YES | | NULL | | +---------------------+--------------------+------+-----+------------+----------------+ 14 rows in set

productDetails
CREATE TABLE productDetails (productID INT AUTO_INCREMENT, categoryID INT NOT NULL, name VARCHAR(60) NOT NULL, vendor VARCHAR(60) NOT NULL, model VARCHAR(30) NOT NULL, price FLOAT NOT NULL, description TEXT, picture VARCHAR(60), PRIMARY KEY (productID), FOREIGN KEY (categoryID) REFERENCES categories (categoryID) ON DELETE CASCADE ON UPDATE CASCADE); +-------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-------------+------+-----+---------+----------------+ | productID | int(11) | | PRI | NULL | auto_increment | | categoryID | int(11) | | MUL | 0 | | | name | varchar(60) | | | | | | vendor | varchar(60) | | | | | | model | varchar(30) | | | | | | price | float | | | 0 | | | description | text | YES | | NULL | | | picture | varchar(60) | YES | | NULL | | +-------------+-------------+------+-----+---------+----------------+ 8 rows in set

145

stockStatus
CREATE TABLE stockStatus (stockStatusID INT AUTO_INCREMENT, productID INT NOT NULL, warehouseID INT NOT NULL, quantity INT NOT NULL, PRIMARY KEY (stockStatusID), FOREIGN KEY (productID) REFERENCES productDetails (productID) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (warehouseID) REFERENCES warehouses (warehouseID) ON DELETE CASCADE ON UPDATE CASCADE); +---------------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------+---------+------+-----+---------+----------------+ | stockStatusID | int(11) | | PRI | NULL | auto_increment | | productID | int(11) | | MUL | 0 | | | warehouseID | int(11) | | MUL | 0 | | | quantity | int(11) | | | 0 | | +---------------+---------+------+-----+---------+----------------+ 4 rows in set

orderDetails
CREATE TABLE orderDetails (orderDetailsID INT AUTO_INCREMENT, orderID INT NOT NULL, productID INT NOT NULL, warehouseID INT NOT NULL, quantity INT NOT NULL, processed BOOL NOT NULL DEFAULT 0, PRIMARY KEY (orderDetailsID), FOREIGN KEY (orderID) REFERENCES orders (orderID) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (productID) REFERENCES productDetails (productID) ON UPDATE CASCADE, FOREIGN KEY (warehouseID) REFERENCES warehouses (warehouseID) ON UPDATE CASCADE); +----------------+------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------------+------------+------+-----+---------+----------------+ | orderDetailsID | int(11) | | PRI | NULL | auto_increment | | orderID | int(11) | | MUL | 0 | | | productID | int(11) | | MUL | 0 | | | warehouseID | int(11) | | MUL | 0 | | | quantity | int(11) | | | 0 | | | processed | tinyint(1) | | | 0 | | +----------------+------------+------+-----+---------+----------------+ 6 rows in set

146

Bibliography
[1] MySQL AB. MySQL Reference Manual, http://mirrors.sunsite.dk/mysql/Downloads/Manual/manual-a4.pdf. [2] Wellhouse consultants. wellho.net: Computing Training, http://www.wellho.net/forum/The-Java-Programminglanguage/Apache-Jakarta-Tomcat-Catalina-Coyote-Jasper.html. [3] Alan J. Dix, Janet E. Finlay, Gregory D. Abowd, and Russel Beale. Human-Computer Interaction. Prentice Hall, second edition, 1998. [4] Jonathan Lazar. User-Centered Web Development. Jones and Bartlett Publishers, Inc., rst edition, 2001. [5] Judy Litt. The Meaning of Color, http://graphicdesign.about.com/od/color/a/colormeanings.htm. [6] Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen, and Jan Stage. Objektorienteret analyse & design. Forlaget Marko, third edition, 2001. An introduction to and explanation of the OOA&D method for object-oriented system development founded at Aalborg University, Denmark. [7] Sun Microsystems. Java Technology, http://java.sun.com. [8] Wikipedia: MySQL. http://en.wikipedia.org/wiki/Mysql. [9] Jakob Nielsen. useit.com: Jakob http://www.useit.com/alertbox/20031110.html. Nielsens Website, Laws,

[10] Carlos Pedroza. Visual Perception: Gestalt http://coe.sdsu.edu/eet/articles/visualperc1/start.htm. 147

[11] Abhijit A. Pol and Ravindra K. Ahuja. Developing Web-Enabled Decision Support Systems Using VB .NET and ASP .NET. University of Florida, Gainesville, rst edition, 2003. [12] Jenney Preece. Human-Computer Interaction. Addison Wesley, rst edition, 1994. [13] Jerey Rubin. Handbook of Usability Testing. John Wiley & Sons, Inc., rst edition, 1994. [14] Ben Shneiderman. Designing the User Interface. Addison Wesley Longman, Inc., third edition, 1998. [15] Abraham Silberschatz, Henry F. Korth, and S. Sudarshan. Database System Concepts. McGraw-Hill, fourth edition, 2001. [16] Jan Stage. DIEB-course (Design, Implementation, and Evaluation of User Interfaces), DAT1/INF1-semester, Aalborg University, Denmark, http://www.cs.auc.dk/jans/courses/hci-courses/dieb2004/slides/Lektion04.pdf.

148