an online sales system - martin toft
TRANSCRIPT
An online sales systemby d105a
Anders Dahl
Christian Hertz
Kenneth Blanner Holleufer
Johnny Jakobsen
Rune Mosbæk
Martin Toft
Steffen Troldtoft
Signatures
Anders Dahl Christian Hertz
Kenneth Blanner Holleufer Johnny Jakobsen
Rune Mosbæk Martin Toft
Steffen Troldtoft
Aalborg UniversityDepartment of Computer Science
TITLE:An online sales system
SUBJECT:Development of software
PROJECT PERIOD:DAT1/INF1Department of Computer ScienceSeptember 2 - December 21, 2004
GROUP:d105a
STUDENTS:Dat. Kenneth Blanner HolleuferDat. Johnny JakobsenDat. Rune MosbækDat. Martin ToftInf. Anders DahlInf. Christian HertzInf. Steffen Troldtoft
INSTRUCTOR:Yin [email protected]
COPIES PRINTED: 9
NUMBER OF PAGES: 127
APPENDIX PAGES: 129 - 146
FINISHED: December 21, 2004
ABSTRACT:
This project addresses the de-velopment of a sales system.The system’s “company” isnot real and we do not haveany economic knowledge toback up the presented ideas.However the system is soenhanced that it is able todeal with the company’selectronic commerce.
The system consists of a webshop where it is possible toorder different products anda warehouse aid applicationwhere it is possible to receivethe orders.
The web shop part of thesystem is usability testedand is in the final state quiteuser-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 stu-dents of informatics and students of computer science, we took this opportu-nity and had a very interesting semester working together, sharing knowledgefrom our different study backgrounds.
The web shop developed in this project can be found athttp://www.conner.dk
The included cdrom contains source code for the entire system. It may seemdifficult to run the applications, because they need Jakarta Tomcat, MySQL,etc. The source code is only ment for viewing. Additionally, this report isincluded as Postscript and PDF.
4
Contents
I Analysis 9
1 The task 111.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 System definition . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Problem domain 142.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 State charts . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Application domain 223.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.3 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.4 Grouping of use cases . . . . . . . . . . . . . . . . . . . 29
3.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.1 Function list . . . . . . . . . . . . . . . . . . . . . . . . 303.2.2 Function specification . . . . . . . . . . . . . . . . . . . 30
3.3 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.1 Interface functionality . . . . . . . . . . . . . . . . . . 323.3.2 Navigation overview . . . . . . . . . . . . . . . . . . . 33
3.4 Technical platform . . . . . . . . . . . . . . . . . . . . . . . . 37
II Design 40
4 The task 424.1 Changes for the analysis part . . . . . . . . . . . . . . . . . . 424.2 Design criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5
5 Architecture 465.1 Technical platform . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.1 Equipment . . . . . . . . . . . . . . . . . . . . . . . . . 465.1.2 System software . . . . . . . . . . . . . . . . . . . . . . 465.1.3 Communication . . . . . . . . . . . . . . . . . . . . . . 475.1.4 Design language . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Component architecture . . . . . . . . . . . . . . . . . . . . . 47
6 Component design 506.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2 Model and function component . . . . . . . . . . . . . . . . . 52
6.2.1 Model-class placement . . . . . . . . . . . . . . . . . . 526.2.2 Function-class placement . . . . . . . . . . . . . . . . . 536.2.3 Function specifications . . . . . . . . . . . . . . . . . . 546.2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 57
7 Graphical user interface design and components 587.1 Creating a successful graphical user interface . . . . . . . . . . 587.2 Usage of the Gestalt laws . . . . . . . . . . . . . . . . . . . . . 597.3 Designing the user interface . . . . . . . . . . . . . . . . . . . 607.4 Web shop GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.4.1 Layout and design . . . . . . . . . . . . . . . . . . . . 707.4.2 Dialogue style in the web shop interface . . . . . . . . 707.4.3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.5 Warehouse GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 727.5.1 Layout and design . . . . . . . . . . . . . . . . . . . . 727.5.2 Dialogue style in the warehouse interface . . . . . . . . 74
8 Database design 758.1 Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768.2 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8.2.1 First circularity . . . . . . . . . . . . . . . . . . . . . . 808.2.2 Second circularity . . . . . . . . . . . . . . . . . . . . . 81
8.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
III Implementation 83
9 System implementation 859.1 Class implementation . . . . . . . . . . . . . . . . . . . . . . . 859.2 Warehouse server . . . . . . . . . . . . . . . . . . . . . . . . . 86
6
9.3 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879.4 Creating the database . . . . . . . . . . . . . . . . . . . . . . 889.5 Client/server implementation . . . . . . . . . . . . . . . . . . 919.6 Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10 Clients 9310.1 Warehouse application . . . . . . . . . . . . . . . . . . . . . . 9310.2 Web shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
IV Test 99
11 Implementation test 10011.1 Class tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10011.2 Functionality tests . . . . . . . . . . . . . . . . . . . . . . . . 10011.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
12 Usability test 10212.1 Test result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10212.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . 113
V Academic requirements 115
13 Academic requirements 11613.1 Analysis, design, implementation, and test . . . . . . . . . . . 116
13.1.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 11613.1.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
13.2 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 11813.3 Database design . . . . . . . . . . . . . . . . . . . . . . . . . . 12113.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 12213.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
VI Conclusion 125
14 Project conclusion 126
VII Appendix 128
A Code test 129
7
A.1 Class tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129A.2 Functionality tests . . . . . . . . . . . . . . . . . . . . . . . . 131
B Test plan 133B.1 Problem statement/test objectives . . . . . . . . . . . . . . . . 133B.2 User profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133B.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.3.1 Greeting and background questionnaire . . . . . . . . . 134B.3.2 Validation test . . . . . . . . . . . . . . . . . . . . . . 134B.3.3 Participant debriefing . . . . . . . . . . . . . . . . . . . 134
B.4 Task list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135B.5 Test environment . . . . . . . . . . . . . . . . . . . . . . . . . 136B.6 Test monitor role . . . . . . . . . . . . . . . . . . . . . . . . . 136B.7 Evaluation measures . . . . . . . . . . . . . . . . . . . . . . . 136B.8 Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137B.9 Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138B.10 Font types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139B.11 Gestalt laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140B.12 Dialogue style in user interfaces . . . . . . . . . . . . . . . . . 141
C Database design 143
Bibliography 147
8
Part I
Analysis
9
A trading company needs an online sales system, which automatically inter-act with a warehouse management system.
The company started out on an idea, of offering products to the consumerthrough the Internet, across the EU. The company concept is that it onlysells products through the Internet and therefore saves money on salesmenand shops. As a result, it can offer the customer products at a very compet-itive price. The company has bought a number of warehouses in some of thecountries in the EU.
The customer will place an order through the online sales site, where thecustomers will have the option of ordering a product from many warehousearound EU, to ensure fast delivery a warehouse near by should be selected.
The company wants to save money when buying products, and thereforeplan to have an effective system to manage orders and their warehouses.The products do not have to be ordered from the main suppliers if the prod-uct is available in another warehouse. Products can be exchanged betweenwarehouses and savings can be achieved by buying large amounts of productssimultaneously. Last the company wants to be able to update and registerproducts, product information and orders, for customer and administrativeusage.
10
Chapter 1
The task
1.1 Purpose
The main objective in this project is to create a computer system that en-ables a company to sell and administer products. Since the company consistsof a number of different warehouses spread out in different countries, the sys-tem must include a website where products from all warehouses are sold, andfurthermore an order management that coordinates inventory and orders be-tween the warehouses.
This projects focus area will be the product sale and order management.Statistics, payment functionalities and accounting, except for calculating theprices of the ordered products will be excluded.
1.2 Context
We chose to describe the situation through rich pictures. An attempt to drawthe problem domain of the situation resulted in the rich picture in figure 1.1.The picture and reflections upon it in the group afterwards gave us in-depthinsight concerning the system, we were about to develop.
1.3 System definition
To be able to evaluate the system definition, we started out with the FAC-TOR criteria listed in table 1.1.
11
Figure 1.1: Rich picture of the problem domain
Based on the factor criteria the following definition were made.
An online sales system, which consists of a web shop and an applicationfor handling orders for numerous warehouses. The web shop will run on anyordinary web browser, where customers can browse through categories andproducts, and place orders. The web shop furthermore includes a track andtrace system, which enables a customer to follow the progress of his/her or-ders.
The application for the warehouses enables the warehouse employees to pro-cess orders simple and efficient. The system will automatically keeps trackof orders and products in the warehouses, and notifies when product countsare running low.
12
F Functionality Product and customer registration, order management, Inter-net sale
A Application domain Warehouse employees and customers shopping online
C Conditions We will carry out the system development. We have someknowledge about system development and expect to learnmore in this semester. The warehouse employee has basicknowledge about computers. The website customer will havea very varying degree of computer knowledge.
T Technology The warehouse client will be written in Java. The website willbe made primarily in JSP. The website will be viewable us-ing Mozilla Firefox 1.0, Internet Explorer 6.0, and most othergraphical browsers. The warehouse client will be able to runon a standard computer with has Java. The website will behosted by a web server with a JSP engine and Java. Thewarehouse server will require Java and a JDBC driver. Allcomputers will require a network connection.
O Objects Products, orders, customers, warehouse, invoice and employ-ees
R Responsibility A warehouse administration and Internet sales system
Table 1.1: FACTOR criteria
13
Chapter 2
Problem domain
The system will handle the customer orders that contains information aboutproducts, the customer, the employee and the warehouse. The registeredproduct information, includes technical specification and price. The cus-tomer information, is their personal data which are used for order handling.An order can be processed by multiple employees, but only one employee canfinish an order, therefore information about this employee must be obtainedfor future order support.
Based on the list of classes and the event table shown in table 2.1, we chooseto show the structural relations between the classes in the diagram at figure2.1.
Figure 2.1: Class diagram
14
2.1 Classes
In this section we will focus on identifying the basic building blocks of ourmodel of the problem domain. We will find and describe the needed classesand events, and in the end structure them in a class diagram, which is shownat figure 2.1.
Customer: A customer is an user of the system and is represented in thecustomer class. The class represents the user by registering personal data,such as name, address, etc. a customer is associated with the order classwith an one-to-many relation, since a customer can place several orders andan order must have exactly one customer.
Order: An order is created when a customer starts adding products. Theorder is a collection of products, a warehouse and a customer. It has the abil-ity 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. Theorder class is the most central class in the system and is therefore associatedwith several of the other classes.
Employee: An employee is a common class for all the people working at thecompany. The role of the people, such as warehouse worker, secretary, etc.,are ignored, so the employee class is the same for every employee. The classonly registers name for the employee and is only associated with the orderclass.
Warehouse: The warehouse is where we keep our products. New productspurchased are added to the warehouse and the product quantity is set, andwhen products are ordered by the customer the product count is decreased.The warehouse class is mainly used for maintaining the quantity of prod-ucts and storing information about a warehouse such as location and contactinformation. The warehouse is associated with the order class with a zero-to-many relation, since a warehouse can have several orders, but also existwithout having any orders to process. However an order can only be assignedto a single warehouse.
Product: The product class is the type of the product, which means weregister name of a certain vendor and model, however the specific productwith a certain registration number is not of relevance. The class describes theinformation about the product such as name, model, price, etc. The productclass 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. Thisenables the company to add new products to the system, without necessarilyadding 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 sys-tematically evaluated and either discarded or added to the event table shownat table 2.1. The state charts in section 2.2.1 also added a few additionalevents, which had not been thought of during the brainstorm.
Customer Order Employee Warehouse Product Invoice
Customer registered +Customer removed +Customer changed *Product added to order * * *Product removed fromorder
* * *
Order placed * + * *Employee registered +Employee removed +Processing started + * *Order closed + * +Invoice deleted +Product registered * +Product removed * +Product received *Warehouse registered +Warehouse removed +
* 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 theclasses. These state charts will help us identify the states the classes cantake. The state charts are followed by a description of a general course anda 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 Description
Name Name of the customer
Address Address for the customer
E-mail A valid e-mail to contact the customer
Phone number Phone number to contact the customer
Country The country where the customer lives
City City the customer lives in
Postal code Postal code for the city
User name The username for the customers website account
Password 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 fired
18
Attribute Description
Product list List of the products added to the order
Customer An associated customer
Delivery country Optional country used for delivery
Delivery city Optional city used for delivery
Delivery postal code Optional postal code used for delivery
Delivery address Optional address used for delivery
Shipping date The date the order got shipped from the warehouse
Creation date The date the order was created
Warehouse 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 Description
Name 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 Description
Name Name for the warehouse
Country Country where the warehouse is placed
City City for the warehouse
Address Address for the warehouse
Postal code Postal code for the warehouse
E-mail E-mail to contact warehouse
Product count The quantity for each type of products
Minimum product count Minimum product count before a signal is sent
Table 2.5: Attributes for warehouse
Figure 2.6: State chart diagram for product type
Attribute Description
Name Name of the product
Model Model of the product
Type The type of the product
Vendor Vendor of the product
Description Description of the product
Price The price the customers are paying
Picture The product picture
Table 2.6: Attributes for product
Figure 2.7: State chart diagram for invoice
Attribute Description
Order A closed order
Employee 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. Thewarehouse facility and the sales site. In the warehouse facility the systemwill support work assignments carried out by warehouse employees, who areworking with processing the orders. This includes packing and shipping prod-ucts and making sure that no other employee are working on the same order.
The warehouse employees reads the needed order information and packs theproducts. Then an invoice containing the customer information is printedout, and the order is shipped. Another work assignment is registering prod-uct and warehouse information. The product information is sent by mail ore-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 createdorders to the warehouse facility.
In this section we will give a total description of the systems usage, functionsand interfaces.
3.1 Usage
The system has three actors, the customer, warehouse employee, and a ware-house 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, wherethe employees have the ability to process the orders. Automatically the sys-tem also monitors the warehouses to make sure the product quantity is notrunning low. The secretary’s 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 theinteraction, we have constructed an actor table as shown in table 3.1.
Customer Warehouse worker Warehouse secretary
Update warehouse list X
Update product list X
Update employee list X
Update product quantity X X
Login X X
Logout X X
Create account X
Change account information X
Update products on order X
Search products X
Place order X
View order status X X
Request products X
Process order X
Finish order X
Table 3.1: Actor table for the system, the actors are listed in the columnsand 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 andpurchase products. The need of this actor group is to find products, addproducts to an order and finally place the order.
23
Characteristic: The Customer group includes many different 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 de-lighted to get an opportunity to buy the product B wants, without leavingthe house. B has never had any significant problems with understandingthe possibility the system provides. B is technologically curious, and willexplored all of the systems possibilities.
Person C is a technical novice, with no real experience with computers, letalone online shopping. As a result C is insecure and will quickly purchase thedesired product and then log of the system again. C only purchase productonline 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 cus-tomers’ orders. The warehouse worker must have access to copies of thecustomers’ 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 hiswork, because he is in the habit of working with pen and paper. The Ware-house worker typically prints out the customers’ order before processing it.
Warehouse Secretary
Purpose: A person who registers and updates a warehouse’s database. Thesecretary needs a well arranged work area, which supports a fast and effectivework routine.
Characteristic: The actor has basic training in the use of the system, other-wise they are often moderate IT users.
Example: Person D registers information in the database. D knows ex-actly how to register and update data fields with the computer system; ithas become a routine work assignment. D uses as little time as possible onthis assignment, but knows that the data must be correct, otherwise the data
24
field 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 markedthe objects and functions, which are involved. The functions are listed insection 3.2 and described in section 3.3.
25
Update warehouse list
Pattern: Update warehouse list is initialized by the warehouse secretary. Theuse case is initialized when a new warehouse need to be added to the systemor when an old warehouse needs to be removed. The information about thewarehouse must be entered manually by the warehouse secretary and after-wards 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. Thisoccur when products needs to be added to the system or when existing prod-ucts needs to be removed. Products added to the system is not available onthe 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, whena 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 thesystem needs to be available on the web shop. This use case is also usedwhen new products arrive to a warehouse and the product count needs tobe changed. It is the warehouse secretary’s job to update the necessary in-formation when needed. Indirectly the customer also uses update productquantity use case. When a customer places an order the system decreasesthe product count, to make sure the number of available products in the webshop is correct.
Objects: Warehouse secretary, Customer.Functions: updateProductQuantity, placeOrder.
26
Create account
Pattern: Create account use case is initialized by the customer, when he/shewants to register as a customer in the web shop. It is required to have anaccount in order to buy products from the web shop and when a new cus-tomer account have been created, the customer have to login before he/shecan place an order.
Objects: Customer.Functions: createAccount.
Login
Pattern: Login is used by the customer, when the customer have an accountfor the web shop and intends to place an order. The warehouse secretaryalso 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 canonly 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 acustomer have changed some personal information. This could be the reasonif 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/shewants to buy a product. The use case for update products on order is alsoused when a customer wants to remove a product from an order, but it canonly 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 customeris trying to locate a specific product. The customer can find the informationby searching on a part of the stored information. If the system find a matchit will send it back to the customer, if not it will inform the customer thatthere 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 finishedadding products to his/her order on the website, and wish to place the or-der at a warehouse. The system asks the customer to select a warehousewhere he/she wish to order from. If the customer has not selected a specificwarehouse, the system will try to locate the best warehouse, either by tryingto find a warehouse that can handle the order by itself, or move the neededproducts between the warehouses. If the customer have chosen a warehouse,which can not handle the order the system will try to move products fromother warehouses to the selected warehouse. The customer will get an esti-mated 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 directedto a page where he/she can add, remove products or choose a new warehouseto handle the order. If the customer chooses to send the order, the systemwill create the order at the chosen warehouse and notify involved warehouses,and send an order confirmation back to the customer by email.Objects: CustomerFunctions: placeOrder.
View order status
Pattern: View order status is initialized by the customer, when the customerwants to view his or her orders. When used all orders placed within a shortperiod will be shown with details about products and price. Another actoris the warehouse worker, who will be able to see orders, which is pending orbeing processed.Objects: Customer, Warehouse worker.Functions: showOrders.
28
Request products
Pattern: Request products is initialized by the warehouse worker. When thewarehouse worker needs a product for an order, which is not available in thewarehouse, the warehouse worker can request another warehouse to send theproduct.
Objects: Warehouse worker.Functions: requestProductFromWarehouse.
Process order
Pattern: The process order is initialized by the warehouse worker. Thewarehouse worker marks that order, to inform other warehouse workers, thatthe order is being processed.
Objects: Warehouse worker.Functions: processOrder.
Finish order
Pattern: Finish order is used by the warehouse worker after the product hasbeen packed and shipped out. The Warehouse worker informs the systemthat 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 thesystem. However the actors work in different domains, so the use cases haveto be put into groups in order to specify what functionality is needed in eachdomain. The customer will probably be sitting at home and using a webbrowser, while the warehouse worker and secretary will be in a warehouseand using an application to interact with the system.
The grouping of the use cases is shown in figure 3.1. It shows that thecustomer takes part in all the use cases in the web shop, and the warehousesecretary and warehouse worker take part in each their use cases in thewarehouse application. We could have chosen to make a web page wherethe warehouse worker and the warehouse secretary could login and do theirtasks; however for security reasons it seemed more convenient to separatethem. 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 identified in the use-cases. It isnot a complete list of all functions, but it shows the most important functionsto implement the system.
3.2.2 Function specification
Most of the functions are self-explained by their names, as we only have onecomplex function. However the place order function need clarification. Amore detailed list of demands for the function is shown in table 3.3.
30
Function Complexity Type
Add warehouse Simple Update
Remove warehouse Simple Update
Add product Simple Update
Remove product Simple Update
Add employee Simple Update
Remove employee Simple Update
Update product quantity Simple Update
Create account Medium Update
Login Simple Update
Logout Simple Update
Update customer Medium Update
Add product to order Simple Update
Remove product from order Medium Update
Search product Medium Read
Place order Complex Update
Show orders Simple Read
Request product from warehouse Medium Update
Process order Simple Update
Close order Medium Update
Table 3.2: Function table
Place order
If a warehouse is not chosen manually, this function finds the warehouse,which is estimated to handle the order fastest. The order is stored and theselected warehouse is informed about the new order. Afterwards the prod-ucts 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 min-imum limit, else the warehouse is informed. At last the function generatesand 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 Complexity Type
Place order Complex Update
Finds appropriate warehouse Complex Calculate
Store the order Simple Update
Decrease the warehouse’s product quantity Simple Update
Inform warehouse about the new order Medium Signal
Inform if the minimum product count is reached Medium Signal
Prints an invoice Simple 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 systeminterfaces, the warehouse employee interface and customer web shop inter-face. The two interfaces have different functionality requirements in order tosubstantiate 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 webshop in figure 3.2 and figure 3.5
Warehouse Navigation
The elements in the figure 3.2 shows how the user can navigate from themain 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 figure 3.5 is the start page, which have 3 frames,where the main page frame is the product catalogue by default. The restof the elements in the figure shows how the page change in the main pageframe, when navigating around in the web shop.
35
Figure 3.5: Navigation diagram for the web shop. The lines of directionmarked with (*) shows that you must be logged in to go there. The lines ofdirection marked with (**) shows that you must be have products in shoppingcart 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 us-ing for this project, will be accompanied by corresponding, object-orientedprogramming. The abstract classes and events presented through part 1 willbe clarified into specific 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 Environ-ment on their personal computer, because the web shop will be distributedto the user as HTML1.
The web shop will run as Java Server Pages, JSP, on a web server. TheseJSP pages will communicate with a Java application running at a databaseserver, i.e. another physical computer. The Java application runs on topof a database service that contains personal information about registeredusers and information about all products. At every warehouse there is acomputer running a Java application which enables the employees to browseand manage orders from the web shop. This application communicates withthe application running on the database server. The general structure isillustrated at figure 3.9.
Operating System
System (DBMS)Database Management
(Java Application)Database Layer
Database Server
Operating System
Web Server
(Java Servlet Application)Web Server Layer
(JSP)Java Server Pages
Web Server
Operating System
Web Browser
User Computer
Warehouse Application(Java Application)
Operating System
Warehouse Computer
Figure 3.9: Technical platform
We will implement the system using Java, because we were taught Javain OOP, an object-oriented programming course at the DAT1 and INF1semester. One of the advantages with Java is that it is almost architectureindependence, i.e. our programs will run on every operating system thatsupports Java. Figure 3.9 illustrates the web server and database server asseparated entities, but it is actually possible to combine their services ontoone computer. However, the separation can be useful when dealing with se-curity issues such as DoS2 attacks.
The database service will be a relational database system, but from an object-oriented point of view it is not important whether the database system isIngres, Oracle, or another product. [6] Information is organized into severaltables, and SQL3 is used to manipulate the tables. On behalf of the user, the
1HyperText Markup Language2Denial of Service3Structured Query Language
38
Java Server Pages running on the web server will query the Java Applicationon the database server, which then query the database service. We want thesystem to automatically inform warehouses when orders is placed, which isthe reason why we do not let the Java Server Pages at the web server and theJava application at the warehouse computer to directly query the databaseservice at the database server. The Java application on top of the databaseservice acts as a middleman and also limits access to specific parts of thedatabase for each client. This gives a little extra security to the database ifthe web server should be hacked.
39
Part II
Design
40
According to the chosen method, the purpose of the design part is to create acoherent representation of the system design. Design criteria for the systemwill be pointed out, where after the system will be structured into compo-nents. The design of the components is meant for specifying a flexible andunderstandable structure, that will ease the implementation. The classes forthe components will be specified and there will be created a diagram for themodel and function component, with all classes including their attributesand operations.
The GUI component is created from various methods including the wisdommethod. Design criteria for the graphical user interface is created and a GUIis 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 dia-gram will be constructed. This ER-digram will then be basis for database’sstructure. The classes from the model component will correspond to theentities 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 twoactors with quite different use cases, we will still use the same class calledemployee 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 theclass diagram as we can use the order class for same purpose. The reasonfor this, is that we have added the processedBy attribute to the order class,which was the only difference 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 reflect some of the specific conditions for the designof the system. The tables 4.1 and 4.2 shows the design criteria for the webshop and the warehouse application with each their order of priority.
42
Criteria Very important Important Less important Irrelevant Easily fulfilled
Usable X
Secure X
Efficient X
Correct X
Reliable X
Maintainable X
Testable X
Flexible X
Comprehensible X
Reusable X
Portable X
Interoperable 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 fastand easy for the user to use
• The security of the web shop is important. The web server will handlethe basic security, and in the implementation the right connectionsbetween the user and the system will be designed
• The efficiency of the web shop is very important. The web shop willpossibly face the job of handling several customers at a given time andall delays are annoying. We certainly do not want customers to leavethe 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 minorconcurrency problems can effect that the information is not 100 percentcorrect, if the customer does not refresh the web page
• Reliability is important. The user should not be bothered with con-nection losses and timeouts from the server
• Maintenance is easy fulfilled when all the web shop’s data is retrievedfrom the server
43
• Functionality tests during development and user tests will be made.Testable is marked less important since no special applications or classesare made
• The applications flexibility is marked as less important
• Comprehensive is marked as very important since the users will leaveand choose another place to shop, if the information is in comprehensive
• The reusable criteria is marked as less important, since most of the webshop is dynamic. A few static pages exist such as company profile andcontact page
• The portable criteria is important. It is difficult to make the web pagelook the same in all screen resolutions and also make it independent ofhaving scripting languages enabled
• The web shop will not communicate with systems or applications otherthan the server, so interoperability is irrelevant
Criteria Very important Important Less important Irrelevant Easily fulfilled
Usable X
Secure X
Efficient X
Correct X
Reliable X
Maintainable X
Testable X
Flexible X
Comprehensible X
Reusable X
Portable X
Interoperable 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 basicsecurity will be managed by the operating system and the databaseserver. No time and effort will be used on making special classes orprograms to manage the application security
• The efficiency of the application is important. With little or no delayit should help the employee in the assigned work area
• The application will handle data coming from the web shop and otherwarehouse applications through the server. Efforts will be made toensure that the data in the system are correct at all times
• Reliability is important. The application will be made so it can functioneven though the web shop or other warehouse application clients aredown
• Maintenance is easy fulfilled. The application will be designed to dy-namically 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 afterdevelopment will be made
• The applications flexibility is marked as very important. It will beobtained through the objected oriented design, that will allow func-tionality to be added or removed easily
• Comprehensive is marked as very important because, there should beno doubt about how an employee should use the application for a giventask
• The reusable criteria is marked as less important, but since the appli-cation is build object oriented, will it be possible to reuse parts of theapplication
• The application will not communicate with other systems or applica-tions, so the interoperable is irrelevant
• The portable criteria will be easily fulfilled when developing the systemwith Java [7]
45
Chapter 5
Architecture
To ease the design and understanding of our system we will in this chapterdescribe the technical platform in depth and choose an architecture for ourcomponents.
5.1 Technical platform
In this chapter we have a short description of the technical platform that oursystem will use. Because the system is using a client-server architecture, wewill have to describe both of them.
5.1.1 Equipment
Because we use Java Server Pages to generate HTML code to the clientswhen they connect to our web server, the only requirement is that the webshop clients have an Internet browser like Mozilla Firefox and a standard PCwith and Internet connection. The warehouse clients will also use standardPC’s with Internet connections but must in addition have JRE1 version 1.5installed. 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 theJava running on our server and the Java Server Pages can send the objectsover the network connection. We have chosen to use the latest Apache2
and Jakarta Tomcat version as web server because we are familiar with this
1Java Runtime Environment, used for executing Java applications on end-user systems2Apache HTTP Server Project, http://httpd.apache.org
46
system, and the system is widely used around the world. For our server wehave also chosen to use the MySQL-database system. The choice is based onthe 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 dif-ferent ways, and interfaces are also needed inside the server. Figure 5.1 onpage 48 gives a basic overview. The Java application controlling access to thedatabase system interacts with the Java Servlet using methods implementedin Java Runtime Environment. The Java programming language and the li-braries already support communication between different applications, suchthat the Java Servlet (which generate HTML pages for the web shop) can ex-change objects with the Java application on top of the database system. Thiscommunication can even take place through networks. The same interfaceis needed on the warehouse client, because the warehouse client also needsto exchange objects with the Java application, which ”guards” the databasesystem.
5.1.4 Design language
Official UML3-notation will be used in the design of the system. UML-notation is described briefly throughout “Objektorienteret Analyse & De-sign” by Mathiassen et al[6].
5.2 Component architecture
We chose to make a system that utilizes a client-server architecture, becausewe have one web shop and several warehouses, which need to share informa-tion.
The web shop and the warehouses will be clients of a server containing allnecessary information, i.e. customer information, product information, or-ders and warehouse information. As seen on figure 5.1 we use an architecturefor distribution in the client-server architecture called local presentation.
3Unified Modeling Language
47
Figure 5.1: Component architecture
When using local presentation the client is only responsible for the user in-terface, while the server is responsible for all the functionality including theunderlying 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 (UserInterface) shown on the web shop client. So the customer’s web browser onlyproduces an user interface from the HTML documents, which the browsergets from the server. We like this choice, since it makes it unnecessary forthe customer to install JRE on the computer. The UIS for the warehousesclient simply uses javax.swing for the UI.
The warehouse server is the central part in our system, it manages all infor-mation about the warehouses in a database, that is the reason for the servercomponent to hold all the functionality in the function and model compo-nents.
We need certain functionality such as:
• Signal when new products are needed for a warehouse (the warehouseswill then have to order them manually)
• Send signal to a certain warehouse when an order for the warehouse isplaced
• 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 system’s components, startingwith 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 ourclass diagram 2.1 and our state charts 2.2.1 and add further technical infor-mation needed for the implementation.
The classes in the model component are responsible for all communicationbetween the function and database component. The classes in the functioncomponent are responsible for communication between the user interface andthe model component. The following is a specification of all the classes andtheir operations and attributes.
Customer
• Purpose: The information registered is the customer’s personal data
• Attributes: name, address, country, email, phone, city, postalCode,username, password
• Operations: login, logout, createAccount, updateAccount, searchProd-uct, viewOrders
Shopping cart
• Purpose: To register information the products the customer wants tobuy
50
• Attributes: customer, products, warehouse, deliveryName, deliveryAt-tention, deliveryAddress, deliveryPostalCode, deliveryCity, deliveryCoun-try
• Operations: addProduct, removeProduct, changeWarehouse, changeDe-liveryPlace, placeOrder
Order
• Purpose: To register information about an order
• Attributes: customer, products, warehouse, status, trackAndTraceNum-ber, creationDate, deliveryDate, processedBy, deliveryName, delivery-Attention, deliveryAddress, deliveryPostalCode, deliveryCity, deliveryCoun-try
• Operations: findWarehouse, printInvoice
Warehouse
• Purpose: To register information about the different warehouses, andtheir 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, pictureWeb-Path, processed, quantity, warehouse
• Operations: createProduct, deleteProduct, changeQuantity, moveFro-mOtherWarehouse, searchForProduct
Employee
• Purpose: Register informations concerning the employee’s work on theorder
• Attributes: name
• Operations: login, logout, addEmployee, removeEmployee
WorkArea
• Purpose: To give functionality to the warehouse
• Attributes: employees, warehouses, products
• Operations: processOrder, finishOrder, viewOrders
51
6.2 Model and function component
This section will from the classes described in section 6.1 try to specify, whichclasses that is placed in the model component and which of them is in thefunction component.
The classes we found in the analysis shown in table 2.1 at page 14 seemedto have a deficiency. In our event table at page 16 we can also see that wehave two common events, which can occur several times. This means thatwe have to create a new class. We have some inconsistency in the way theorder class would look depending on if we want to use it in the web shop or inthe warehouse application. We will therefore create a new shoppingcart classfor the website and use the order class for the warehouse application. Thereis also two common events, which can occur several times for the processingstarted event, therefore we create a new class for the warehouse functionalitycalled workarea.
6.2.1 Model-class placement
In this section we will focus on what functions that can be assigned to theclasses in the model component.
Customer
• login
• logout
• createAccount
• updateAccount
• searchProduct
• viewOrders
Order
• findWarehouse
• 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 func-tions not listed in this section are functions that would make little senseplacing 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
• finishOrder
• viewOrders
6.2.3 Function specifications
The complex functions included in this section are all related to the placeorder use case described in section 3.1.3. To avoid misunderstandings andease the implementation, we made specifications of the functions. Thesespecifications 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 theorder to a warehouse and returns order information to the customer
Input data: ShoppingCart
Conditions: ShoppingCart object exist
Effect: An Order object is created containing information from the shoppingcart object
Algorithm: If a warehouse is not selected the findWarehouse algorithm isrun
Data structures: ArrayList of Product
Placement: ShoppingCart
Involved objects: Customer, ShoppingCart, Product, Warehouse, Order
Triggering events: newOrderCreated
Involved functions: findWarehouse, changeQuantity
Table 6.1: placeOrder function specification
54
The placeOrder function is called when the customer accepts the shoppingcart as an order. This function will call two functions findWarehouse andchangeQuantity. The findWarehouse function is called first and finds a ware-house for the order. The changeQuantity will change the product quantityfor each of the products ordered.
findWarehouse
Name: findWarehouse
Category: passive, compute, reading
Purpose: check if the order can be processed at a warehouse. If one or moreproducts are missing at the warehouse to fulfill the order, determinewhether to choose another warehouse or move the missing products tothe found warehouse
Input data: Order
Conditions: Order object exist
Effect: 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: findWarehouse function specification
The findWarehouse function is called by the placeOrder function. It is pur-pose is to find the warehouse, which can handle the order best. This isdone by remember the warehouse, which have most of the products on theorder. If not all products are available products can be removed from ware-house to warehouse later or wait for a new delivery. The pseudocode for thefindWarehouse algorithm is written in table 6.3.
55
� �1 bestWarehouseAvai lableProducts = 023 i f (Warehouse i s not s e t ){4 for ( i =0; i<numberOfWarehouses ; i++) {56 ava i l ab l eP r oduc t s = 0 ;78 for ( j =0; j<numberOfProductsOnOrder ; j++) {9 i f ( warehouse ( i ) has product ( j ) ) ava i l ab l eP r oduc t s++
10 }1112 i f ( ava i l ab l eP r oduc t s > bestWarehouseAvai lableProducts ) {13 bestWarehouse = i14 bestWarehouseAvai lableProducts = ava i l ab l eP r oduc t s15 }16 }17 }
� �
Table 6.3: findWarehouse 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 fit into the existingones have been made. Last the most complex functions have been specifiedto ease the implementation. Figure 6.1 is the upgraded class diagram.
57
Chapter 7
Graphical user interface designand components
Since we chose GUI design as our main focus area we put a thorough effortinto examining the important design criteria. Hereafter we will describe someof the main things to consider when designing an interface.
7.1 Creating a successful graphical user in-
terface
Creating a graphical web user interface that targets all users in a selectedtarget group can be difficult because we believe users have different taste inGUI design. A user friendly interface which has all the needed navigationfunctions is the first step on the way to perfection.
GUI specialists such as Donald Norman tells us the human mind processesnew information based on observations and inferences, this is applicable withe-commerce web sites as well as for the rest of society’s generalized consumerequipment [14].
The goal of e-commerce web sites is to get the user’s attention, and encour-age the user to use the site. By fulfilling their conceptual models, the basisof navigation is accomplished. The choice of using more atypical functionson the web application needs to be well planned to cohere with the rest ofthe site and for the user to understand these functions.
Overall this means the web application must follow some of the ground prin-ciples of similar websites, which means a design model and a system image
58
that are consistent with the user’s model of the web application. “Ideally,the user’s model and the design model are equivalent” according to Don-ald Norman[14]. The physical appearance, its operation, and the way itresponds, must be consistent with and exemplify the operation of the properconceptual model. Furthermore the website should have no irrelevant con-tent, contrary all relevant information should be easy accessible.
To make a more interesting user interface that keep the users interested andmake them spend time on the site as well as returning, we will examine theGUI elements recommended when building a successful user interface. Inour case the website GUI will represent the company’s public face, thereforethe website GUI should be greater prioritized than the warehouse GUI, bothnonetheless 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 webshop. In the top frame we have chosen to use primary the principle Closureand Continuity to group the elements together. The links are meant to beconceived as one group, which contains navigational links.
In the right frame the principle closure, proximity and symmetry will be theones primarily used. The elements in the text fields will be group together,because we want the user to perceive them as belonging together and whenfiling out one of them, the rest must be filled out as well, this is the principlesproximity and closure. The content of the shopping cart is set between lines,which groups related information together, in order to make the informationeasy-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 de-signed after the continuity and proximity principles. The products namesand thump nails are grouped together into the form of a table. This is theprinciple of both principles while the principle of proximity is used whengrouping the individually thump nail and product name together. On thesites “product search”, “create customer” and “shopping cart”, the princi-ples proximity and closure are used. As with text fields, in the right frame,the principles proximity and closure are used. In addition, on the “shoppingcart” site lines are used to group information together, which is the symmetryand closure being used.
59
7.3 Designing the user interface
In order to design the user interface we will take two use cases discussedin chapter 3. The two use cases are “Process order” and “Place order”.The first thing to do is to make an use case diagrams, this will help usunderstand the complexity involved in performing the specified tasks andthus help us create an user interface that will show the user the importantinformation and functionality that he/she will need to perform his/her task.Hereafter an interaction model will help us understand how the user willinteract with the system through specific tasks and display what needs tobe seen in each window/frame. Then dialog-models will be constructed toenable us to specify in which sequence the tasks will be accomplished. Basedon all this we will make an interaction space model that will be the GUIcomponent of the system, and based on this we will implement the GUI.
Use cases
In figure 7.1 we see the use case for process order. It is important to showthe user which orders are available in the warehouse and also if the order isalready being worked on by another employee. Therefore we have the status“NEW” and “PENDING”. When an user chooses an order a description ofwhat that order contains will appear. If an employee is working on an orderthat contains a lot of products, it would be a good function to mark eachfound item. When all items are found and packed the employee must be ableto finish the order and input his name for future reference.
In figure 7.2 we have the process order interaction diagram. From this di-agram we can see that we will separate this use case into three differentwindows. The first will be an order browser thats lists the different ordersand the next will be a product browser that lists which items an order con-tains. If a warehouse receives a large amount of orders the data quicklybecomes unclear, by doing the above mentioned we distribute the outputand clarify the data.
The last screen will appear when an order is finished and will prompt theuser to enter his or her name. It will be placed as a separate screen appearingevery time an user finishes an order. In this way the user cannot accidentlyforget to put his name on a processed order.
The dialog-model in figure 7.3 shows the order in which the tasks must becompleted. The first 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 willidentify and find each product in the order. When he has found all the itemshe will finish his order and put his name on it.
<Employee> <System>
Open System Display orders
Chose order
Select orderSet status pending
Show products in order
Mark products in order
Enable Finish order
Press finish order
Display employee
Choose employee
[If status new]:
[If status pending]:
[If all products marked]:
[If all products not marked]:
Figure 7.1: Use case for process order
61
Choose employee Employee browser
Order browser
Product browser
Chose order
Finish order
Identify Product
Figure 7.2: Interaction model for process order
62
Finish order
Proces order
Choose employee
Find item 2
<<seq>>
Find item 1
<<seq>> <<seq>>
Chose order
Figure 7.3: Dialog model for process order
In figure 7.4 we have the use case for place order. because an order musthave customer it can be sent to an user must be logged in before he canplace one. When logged in the user must have a screen showing him whatitems his order contains, the price for each item and the total price of theorder. If the user has made an error when putting an item in the shoppingcart there must be an option to either remove an item or change quantity ofthe different items. Because our system gives the user the option to chosewhich warehouse that will take care of the order this must be present, butsince 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 op-tion to accept the order and hereafter taken to the invoice screen. Here theuser will be informed that his order is created and the invoice for the orderwill be displayed. The user will be given a choice to print the invoice forfuture reference. In case we had decided to implement the payment methodsand classes for this system the user would have been taken through paymentscreens before the invoice screen was shown.
63
In figure 7.5 we have the corresponding interaction diagram for this use case.We have chosen to display the available information and functions in threescreens. The first screen will be the log in screen. If the user have not alreadylogged in when the place order button is pressed he will be presented withthe login screen. A log out button will appear when the user is logged in andis visible at all times for log out.
The second screen will display all information about an order so the user canreview it and change it if necessary. In this way an user can get a completeoverview of his or her order without thinking about changing screens or otherunnecessary tasks. The last screen will only show the created invoice for theorder so the user gets confirmation on his order. Here he will have the abilityto print out the invoice.
The dialog model, seen in figure 7.6, is for this use case a little challengingbecause the user has a lot of optional choices and the ability to log outwhenever 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>
Press place orderDisplay order screen
Log in
Enter X of items to remove
Press update
Choose warehouse
in customers country
Order created
Display invoice screen
Prompt user to log in
Remove X items from order
Select warehouse
Print out invoice
Set warehouse to XAccept oder pressed
Enter delivery address Set delivery address
[If default warehouse selected]:
[If customer logged in]:
[not logged in]:
[If quantity of products is right]
[no print invoice]:
[If print invoice pressed]
[If warehouse X selected]:
[If different address is needed]:
[If quantity not right]:
[no delivery address]:
Figure 7.4: Use case for place order
65
Customer info view
Order view Change item quantity
Select warehouse view
Delivery addres view Set delivery address
Set warehouse
Log in view
Log our view
Invoice view View invoice
Print invoice
Log in
Log out
Figure 7.5: Interaction model for place order
66
Change item quantity
Print Invoice
Set warehouse
Log in
Place order Log out
Set delivery address
Accept order
Figure 7.6: Dialog model for place order
The Interactionspacemodel for each of the use cases can be seen on figure7.7 and figure 7.8. We now know how the GUI should be build so it willsupport the use cases we have and the decisions we have made throughoutthe process, now we have to design the GUI objects themselves.
67
<<navigates>><<navigates>>
<<Interaction Space>>
<<output elements>>
<<input elements>>
<<actions>>
<<Interaction Space>>
<<output elements>>
<<input elements>>
<<actions>>
<<Interaction Space>>
<<output elements>>
<<actions>>
<<input elements>>
<<
navi
gate
s>>
<<Interaction Space>>
<<output elements>>
<<actions>>
<<input elements>>
<<conta
ins>>
<<contains>>
OrdertableMain frame
Internal frame(empty)Message field
Exit Close
Selectorder
Close
Finish order
Employee selection
Orderdescribtion
Employeelist
Chose employee
Confirm
Productlist<<Interaction Space>>
<<output elements>>
ProductIDProductNameVendorModelDecriptionQuantity
Orderlist
Status
<<Interaction Space>>
<<output elements>>
<<actions>>
<<input elements>>
OrderIDCreatiun date
<<input elements>>
<<actions>>
Check product
Figure 7.7: Interaction space model for process order
68
<<navigates>><<navigates>>
<<Interaction Space>>
<<output elements>>
<<actions>>
<<input elements>>
<<Interaction Space>>
<<output elements>>
<<input elements>>
<<actions>>
<<
cont
ains
>>
<<Interaction Space>>
<<output elements>>
<<input elements>>
<<actions>>
<<contains>><<co
ntains
>>
<<Interaction Space>>
<<output elements>>
<<input elements>>
<<conta
ins>>
<<
cont
ains
>>
<<Interaction Space>>
<<output elements>>
<<input elements>>
<<actions>>
<<contains>>
<<
cont
ains
>>
<<Interaction Space>> <<Interaction Space>>
<<output elements>>
<<input elements>>
<<actions>>
<<contains>>
Login
NamePassword
Login
Order view
Accept order
OrderIDCreation dateWarehouseIDTotal price
<<Interaction Space>>
<<output elements>>
<<actions>>
Invoice
<<input elements>>
Webshop
VendorName
ModelQuantity
Price
Customer info
NameAddressPostal codeCountry
<<actions>>
Selectwarehouse
<<actions>>
<<Interaction Space>>
<<output elements>>
<<input elements>>
Warehouse
Delivery address
<<output elements>>
<<input elements>>
NameAttentionAddressPostal codeCiryCountry
<<actions>>
Shopping cart
Total PriceVendorNameModelQuantity
<<actions>>
<<Interaction Space>>
<<output elements>>
<<input elements>>
Quantity
Update
Productlist
Invoice productlist
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 de-scribed 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 cus-tomer should have easy access to finding the desired products and the navi-gation should be as simple as possible to relieve the customer’s overview ofthe site. Furthermore we want a simple and clean design without any irrele-vant frames and other irrelevant graphics, but at the same time the graphicsmust be appealing to the customer, because it is an e-commerce site andcustomers 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 ofthis is based on the fact that we want to keep it simple for easy navigationand clean design without irrelevant information, but still supporting featureswho can help the user to gain overview of his shopping. In the left frame wewill 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. Wechose blue, orange, red and gray colors for the primary layout. The reasonfor this is because we want to represent ourselves as a business oriented con-servative company. The blue represent stability, trust, wisdom and integritywhich are important virtues for a serious web shop. Red is used for warningsand to get the attention of the customer. Grey means neutral and time tomake choices. Orange is a complementary color of blue and at the same timeit means creativity, determination, energy and success. The web page willsupport 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 sectionB.10. Arial and Verdana is two of the most supported sans-serif fonts onthe web, we think Verdana is the best looking of the two fonts, therefore wechoose Verdana font as our default. The size of the font will be smaller thana regular size 12 which is the default size of regular printout, this is anotherreason for choosing a sans-serif font [4].
The Verdana font is a very clean font which are sometimes used on businesssites, this font type has conservative symbolic value which we also want ourcompany to cohere and represent. Hereby the customer hopefully will getan 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 directmanipulation and menu selection when browsing through products puttingitems “visually” in a shopping cart, form fill-in will also be used when thecustomer has to register to buy products. Additional information of ourstudies 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 in-formation and links primarily according to the regular concepts of the Worldwide web user.
Top frame
The logo of the company is put in the upper left of the top frame, see figure10.2 the slogan of the company will be placed in the middle of the top frameas it is coherent with the logo.
Navigation is also placed in the top frame. The upper right navigation con-sist of; Create Customer, Customer Details, Track and Trace, Company andContact. The lower right navigation consist of; Product Catalog, ProductSearch and Shopping Cart. Both upper and lower have consistent text graph-ics which change color on mouse over, the lower navigation also have differenticons 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 presseach bar navigation link, ex. a Product category, to go back to an earlierstate, all the way back to for example the Product Catalog, which in thiscase is the first.
The top menus will be accessible at all time, as it only will be the pagesbelow the navigation bar who changes during navigation around the web siteapplication.
Additionally Country, Language and Currency will be implemented, it willconsist of drop down menus containing the countries associated with thesystem. Although this is not necessary for the system to function, it willmost 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 willbe the product catalog, where product categories will be shown, below thecategories advertisements of the sites special offers will be placed. All mainpages 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 whichwill make the text layout coherent so links and regular text look the sameall through the site.
Right frame
In the right frame shopping cart and login/logout will be placed. The back-ground will be a light gray for the frame to cohere with the backgroundgradient of the main frame. There could be a small deviation in the basicuser concepts concerning the shopping cart in the right frame, but we thinkplacing the shopping basket in the right frame would be a great help for thecustomer to keep overview of what is placed in the shopping cart and alsogiving the overview of the total price.
7.5 Warehouse GUI
It is important to have an user-friendly warehouse application interface as iteases the work for the employee and makes it easier to learn for new employeesand companies[13]. We tried to implement this by making an user interfacebased on who the user would be and how the system would be used, whichwe documented in the analysis.
7.5.1 Layout and design
In the warehouse, there is a computer with an interface which is used bymultiple warehouse workers. Therefore the usual form of log in would notbe appropriate in this case. It would simply be too demanding if the ware-house workers had to log in and out for every order they processed. Insteadwhen each individual order is finished it would be possible choosing whichemployee’s name goes with the order by using a drop down menu, see figure7.9.
Figure 7.9: User dropdown menu
1Cascading Style Sheet, a file which controls layout for a website.
72
According to Human-Computer Interaction by Alan J. Dix, it is importantto keep each screen easy to survey. To do this it is necessary to keep thescreen simple. There is multiple ways to do this, the most important is toget rid of irrelevant data and to keep the interface simple[3].
The warehouse GUI should consist of an order list where all the orders willbe queued to ensure a good overview of the screen there should be a displayof status for the individual orders so the employee quickly can see which or-ders to work with. Double-click on the order in the list should open an orderwindow in which the details of the order is displayed. To ensure an employeecan locate an older order from the orderID and creation date should be dis-played also. To simplify the interaction with the application we should makea menu bar at the top of the screen, like it is known from other programs, inwhich the different functions should be implemented.
The status of a new order will be new, by clicking on it and opening the orderit will change status to pending. When the employee then ships the packageto the customer he puts an X in a shipped box the order status changes toshipped. It is a possibility that not all the products ordered by the customerare in stock. Then the order stays pending until it is possible to send all theproducts.
To heighten the usability of the program it should be possible for the user tomake a personal setup so we will make it possible to rearrange the columnsin any order. By clicking on the column heading it should be possible to sortthe orders after orderID or status. Arranging after status should of coursearrange the orders with the new and pending orders in the top, because theseare the most relevant for the employee. The reason for being able to sort isif the employee needs to find a specific order it can be extremely difficult tolocate it if the possibility to sort the data is not there.
The open order window contains the order number, address and name ofthe customer and which products is ordered. The products are plotted intoa table which among other things contains their location in the warehouse.Some products can easily look alike. To avoid a ”human error” we have theremaining information about the product, to ensure the correct product getssent.
The File dropdown menu contains an exit function. The product dropdownmenu contains the options to add or remove products. The order dropdownmenu contains the possibility to open a new order list. The administration
73
dropdown menu gives an option to implement administrative functions likeadd/remove employee, which we will not do.
Warehouse font
Java uses the default fonts installed on the operation system, it uses bydefault a sans-serif font, so the readability is acceptable, we could chose afont type for the warehouse GUI, it would result in less usability because itcould differ 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 theuser 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 tosee statistics on sales. Form fill-in will be used when correcting/adding newproduct categories, products, descriptions and prices.
74
Chapter 8
Database design
Partially based on the modeling component shown in figure 6.1 on page56, the entity-relationship diagram of the database is drawn in figure 8 onpage 82. The database model should contain the same attributes as themodel component, but in some areas the ER-diagram is different. We choseto make the database model as an ER-diagram, because we learned aboutER-diagrams in the Persistence course1 in this semester and because it corre-sponded to our technical platform, the MySQL platform. More informationabout MySQL and the implementation of the database is available in section9.3, however we recommend reading through this chapter first.
During our development of the ER-diagram, the two entities orderDetailsand stockStatus were made as the result of many-to-many relationships.This type of relationships typically have the primary keys of the relatingentities as attributes [15]. However we needed more attributes than just theprimary keys, such as quantity in both orderDetails and stockStatus, so wethought it was better to change the many-to-many relationships into entities.
As regards naming of the entities and relationships, we use a mixture ofSun Microsystems’ naming conventions for Java code and the naming pre-sented in chapter 1 of “Database System Concepts” by Silbershatz et al [15].The latter uses only lower case for relationships. The entities are named sothat all substantives - except for the first one - begin with a capital letterand continue with lower case, e.g. “productDetails” and “stockStatus”. Donot attach additional importance to the naming, we just want to clarify ourchoices to the reader. The naming is applied correct in the ER-diagram, butin some of the following headlines we make exceptions due to layout consid-
1A course held by Kristian Torp on the DAT1/INF1-semester, Department of ComputerScience, Aalborg University
75
erations, e.g. “productDetails” may be written as “ProductDetails”.
In the following sections the database’s entities and relationships will beintroduced, justified, and explained.
8.1 Entities
The entities’ primary keys are underlined at figure 8. We chose to use nu-meric values as the primary key in all entities, because it is faster to searchthrough a list of integers compared to a list of text strings [11]. In some casestext strings would have been the natural alternative, e.g. a compound pri-mary key in warehouses consisting of the warehouse’s name, city, and country.
We list the entities in order of appearance at the ER-diagram in figure 8 onpage 82.
Employees
This entity represents all employees working at all warehouses. Because weopted out the administration part of the sales system, we do not want tokeep personal information about the employees. We settle for an uniqueidentification number and a name. In that way it is possible to distinguishbetween employees with identical names.
Orders
All orders existing in the system will be represented by this entity. Only mas-ter information about an order is stored here, including unique identificationnumber, status, involved customer, involved warehouse, involved employee,delivery details, various dates, and track & trace number for the distributedpackage.
The ER-diagram at figure 8 shows clearly that the delivery details, repre-sented as attributes starting with “delivery”, were not existing in the earlydesign of the database. There are delivery fields for name, att (attention),address, postal code, city, and country. These fields are not always necessary,because the customer may decide to stick with the name and address storedin the Customers entity. We think it is correct to place the attributes in theOrder entity, because the delivery details cohere to a specific order, i.e. thecustomer may choose different delivery details for other orders.
76
OrderDetails
The contents of an order are kept in this entity, i.e. an order identificationnumber, a product identification number, and a quantity are linked together.As an example, an order with the identification number 7 may contain twobikes and five mopeds with the product identification number 1 and 2, respec-tively. 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 systemso the number of records may be extremely big. To ensure distinct recordswe 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 figures. Each product has an unique product identificationnumber and belongs to a certain category in the Categories entity. In addi-tion information about name, vendor, model, price, description, and picturecan be kept in this entity. The product identification number is an unique,primary key.
Categories
Products are organized into categories and this entity keeps informationabout all the categories. Every category has an unique identification num-ber, a name, a description, and a picture. The identification number is theprimary key and is referenced by products in the productDetails entity.
Customers
This entity represents all registered customers in the system. Every customerhas an unique identification number so the system is able to distinguishbetween them. The number is used as an unique, primary key. A personaluser name and password are used by a customer to log on the web shop. Thisentity also keeps the real name and address of a customer which is needed forsending out ordered products and to avoid the hassle of typing in the sameinformation with every order. Additionally a phone number and an e-mailaddress are kept as a convenient way to contact the customer.
77
Warehouses
The sales system supports multiple warehouses and information about all thewarehouses is represented by this entity. We need to store name, address,postal code, city, country, and e-mail address of the warehouses. The latteris kept as a convenient way to contact the warehouse. As an example thewarehouses’ e-mail addresses could be registered in a mailing list, such thatthe warehouses were able to communicate easily and cheaply, however thatis out of the scope of this project. It would be reasonable to use a compoundkey consisting of e.g. name, city, and country as primary key for this entity,but for performance reasons we distinguish between the warehouses using anidentification number as previously mentioned.
StockStatus
This entity links together products, warehouses, and quantities. It has fourattributes which are: identification number for each StockStatus record, aproduct identification number, a warehouse identification number, and aquantity. In this way it is possible to express how many pieces of a sin-gle product type each warehouse got in stock. The primary key is the uniqueidentification number for each record which is only included to ensure dis-tinct records. Moreover it is good practice to remember primary keys in allentities. [15]
8.2 Relationships
In this section the database model’s relationships will be presented and ac-counted for. The first-hand impression of the ER-diagram may give rise toheadache for database experts, because the entities and relationships formtwo circles. Circularities in ER-diagrams are known to be the root of redun-dant data and operational problems, but in section 8.2.1 and 8.2.2 we willexplain why that fact has nearly no impact on our structure [15]. The en-tities orders, orderDetails, productDetails, stockStatus, and warehouses areinvolved 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 causethe employeeID attribute in the order entity. The argument for an one-to-
78
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 onlyrefers to a single order in the orders entity. That is why this relationshipis one-to-many from orders to orderDetails. The products belonging to anorder are listed in orderDetails as product identification numbers togetherwith warehouse identification numbers and quantities.
ProductDetails are-referenced-by orderDetails
The entity productDetails contains, just like the name alludes, details onall registered products, except for the associated stock figures. A record inproductDetails may be referenced by multiple records in orderDetails usingthe product’s unique identification number, i.e. the relationship is one-to-many from productDetails to orderDetails.
Categories contain productDetails
This relationship connects categories and productDetails, because the prod-ucts recorded in productDetails are categorized into categories recorded inthe categories entity. A single category may contain many products, so therelationship 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 customerto 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 toorders.
Warehouses own orders
Each order is assigned to a single warehouse, such that a single warehouseis said to “own” a number of orders. The relationship is one-to-many fromwarehouses to orders, and as a result of this, the orders entity has an attributecalled warehouseID.
79
Warehouses are-referenced-by orderDetails
We want to attach each product on an order to a single warehouse, becausethe products offered on the web shop may be placed at different warehousesinitially. It is then the employees’ job to examine pending orders and checkwhich products that should be moved between the company’s warehousesto send only one package to the customer. As the moving progresses, theproducts’ warehouse property can be updated. The relationship is one-to-many from warehouses to orderDetails, because the records in orderDetailsmay only reference a single warehouse, but a warehouse may be referencedby 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, becausea product may be in stock at several warehouses, but a record in stockStatusmay only reference a single product in productDetails.
Warehouses have stockStatus
Each warehouse has information about stock status which is recorded inthe stockStatus entity. The relationship from warehouses to stockStatus isone-to-many, because a record in stockStatus may only point to a singlewarehouse, but a record in warehouses may be linked together with severalrecords in stockStatus.
8.2.1 First circularity
This circularity is created by the relationships between orderDetails, product-Details, stockStatus, and warehouses. Both orderDetails and stockStatushave the attributes productID and warehouseID, because there are one-to-many relationships away from warehouses and away from productDetails.If the circle had circular derivation of attributes because of unidirectionalone-to-many relationships, it would present a serious problem. If that is thecase, then the database design is impossible to setup in a relational databasemanagement system, because the tables, which represent the entities, haveto be created one at a time, and a table cannot be created if it relates toanother, non-existing table [15].
80
By inserting data into warehouses and productDetails before inserting datainto orderDetails and stockStatus, the circularity is proven unproblematic.However, this design makes it possible to add to an order products whichare not present in the warehouse, which they are referring to in orderDetails,i.e. orderDetails may contain a record stating seven bikes from a warehousethat does not sell bikes (the product identification number for the bikesare not linked together with the identification number of the warehouse instockStatus). That is a matter of debate, because it could be consideredeither a feature or a flaw, e.g. a company may be interested in selling productsprior to having them in stock. The database layer on top of our databaseinsures that the system described in this report does not assign products towarehouses, 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 orderDe-tails, the attribute warehouseID in orderDetails, and the attribute warehou-seID in orders. As previously mentioned, the two warehouseID attributesare needed, because an order in itself is owned by a warehouse and the or-der’s products may temporary be placed at other warehouses. Again, thesolution is to insert data into the entities in correct order. First create awarehouse, then create an order, and finally add products to the order bycreating records in orderDetails. Bear in mind, that records in employees andcustomers are needed to create an order, just like records in productDetailsare needed to create records in orderDetails.
8.3 Summary
We expect the database design to work just fine if implemented in a relationaldatabase server. The implementation will be done using the MySQL databaseserver in section 9.3, where we will explain SQL2 and Java’s database con-nectivity too.
2Structured Query Language
81
0..*
0..*
0..*
0..*
0..*
0..*
1..1
1..1
1..1
1..1
1..1
0..*
1..1
1..1
1..1
0..*
0..*
1..1
employeeID
name
categoryID
name
description
picture
employees
orderDetails
productDetails
categories
contain
contain
process
customerID
status
orderID
place
stockStatus
warehouses
customers
have
are−referenced−by
are−referenced−by
quantity
warehouseID
productID
stockStatusID
country
city
postalCode
address
name
warehouseID
phone
country
city
postalCode
address
name
password
username
customerID
quantity
warehouseID
productID
orderID
orderDetailsID
trackAndTraceNumber
shippingDate
creationDate
employeeID
warehouseID
picture
description
price
model
vendor
name
categoryID
productID
processed
deliveryPostalCode
deliveryName
deliveryAdress
deliveryAtt
deliveryCity
deliveryCountryorders
own
are−referenced−by
Fig
ure
8.1:
Enti
ty-r
elat
ionsh
ipdia
gram
for
the
dat
abas
e
82
Part III
Implementation
83
In the implementation part we focus on how we have implemented our sys-tem. Due to the limited time period we have not implemented the wholesystem. We have focused on getting a working web shop and warehouseserver, but also implemented a part of the warehouse client. The limitationsin the warehouse client is basically the functionality for the actor called sec-retary. There is no login and logout for the warehouse client and as well thereis no options for adding and removing employees, products and warehousesto the system via the warehouse client.
After struggling with RMI-callback and thought about the time costs of get-ting it to work, we have chosen not to implement it. That resulted in thewarehouse client is not updated automatically, but only when the window isopened. The warehouse client was meant to be updated when new orders ar-rives or a product quantity is running low. Another feature not implemented,because it is depended on RMI-callback is the moveFromOtherWarehouseoperation in the product class.
84
Chapter 9
System implementation
In the implementation phase we take the system designed in the design phaseand realize it on the selected technical platform. In this section we willgo through the implementation of the database, the model classes, and thefunction classes.
9.1 Class implementation
The implementation of the classes from the class diagram at figure 6.1 havebeen implemented, but we have made some changes to the design during theimplementation phase. The implementation started with coding the classesin the model component. The main differences in the model component be-tween 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 havenot been implemented, but the functionality the method has is imple-mented in the placeOrder method
• To ease the implementation of the products we have created a newclass called category. It is mainly used for grouping a certain type ofproducts
85
9.2 Warehouse server
We have implemented our warehouse server, which uses RMI for communi-cation across networks and (My)SQL-syntax for storing data in a MySQLdatabase. Our warehouse server works like a top-layer for the MySQLdatabase. The main reason for implementing our warehouse server instead ofjust connecting directly to the MySQL database, is that we want to updatethe warehouse-client as soon as orders are placed in the online web shop. Wealso want to notice warehouse-clients automatically, when a product countis running low. If we have chosen to skip our database server, the warehouseclient could have updated. Instead it updates automatically in time intervals,but we wanted to inform the warehouses instantly when orders are placed ora product count is running low.
When the warehouse server is started, the first step is to load our Databaseclass, which initialize a connection to the MySQL database. Afterwards newinstances of the NetworkWebShop and NetworkWarehouse classes are made,and the database server binds them as remote objects to a specific name.RMIRegistry must run in order for our database server to work. Each ofour remote objects have the necessary methods to make the web shop andwarehouse application work. When a method is called via the RMI, themethods’ arguments are forwarded to local method in one of our system’sclasses, 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 theconnection initialized when the server started. Most of the methods justneed to update some data in the database or retrieve some data. Howeverour placeOrder method in the Order class, which is invoked from the web
86
shop, will have to send data to a specific warehouse, which can be solved byusing RMI-callback.
9.3 MySQL
MySQL is a relational database server owned and sponsored by a singleSwedish, for-profit firm, MySQL AB. It is available under different licenses toaccommodate all intended use, such as the GPL1. Both source code and bina-ries (for Linux, FreeBSD, Windows, etc.) are freely accessible from MySQL’sofficial homepage at http://dev.mysql.com. The application turns in a strongperformance being multithreaded, and security is available through multi-user support. [8] We utilize the latter by creating an user called “wwwuser”only with permission to select from, insert into, update, and delete from ta-bles. The tables will be created and owned by the “root” user who is thedatabase’s administrator. [1]
Just like The Apache Derby Project (the database server introduced to us inthis semester’s PER-course), MySQL is reached from within a Java applica-tion using a JDBC-driver2. Sun Microsystems let the developers of databaseservers develop their own drivers for connectivity; MySQL’s is called MySQLConnector/J.
MySQL Connector/J
MySQL Connector/J is downloadable from MySQL’s official homepage andrequires only a simple installation. We will introduce the reader to Con-nector/J through examples. Please note, that the presented code needs tohave nearly all classes from the java.sql package imported. Within a Javaapplication, 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 astatement:
1GNU General Public License, http://www.gnu.org/licenses/licenses.html#GPL2Java 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 possibleto retrieve information from the database, e.g. the identification number ofa 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.4by building tables representing the entities from chapter 8, database design.Beside informal attributes, the tables will contain primary and foreign keysrepresenting relationships.
9.4 Creating the database
The database is created using MySQL’s command-line tool at the computerrunning MySQL. The tool is started and two commands are typed in tocreate 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 createthe tables in the database. We will present two of them here; one to createcategories, and one to create productDetails. A complete list of “CREATETABLE” queries and resulting tables are available in appendix C. The queryfor creating categories can be seen in figure 9.1. The categories’ name and
88
picture is represented using text strings of up to 60 characters wide. Theidentification 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 linkitself to categories. The attribute “categoryID” in productDetails is a keyreferencing the primary key in categories; hence it is a foreign key. Thisinsures that new products must be “put into” an existing category fromcategories. The query to create productDetails is seen in figure 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 thatthe table’s data field must contain data. The primary keys in a table mustcontain data or else an error will occur. The foreign keys differ a bit, asseen with “orders” where “employeeID” may be “null” (check out appendix
89
C). We chose “not null” for that attribute, because an employee is not nec-essarily appointed when an order is created, but instead the appointmentoccur later when an employee at a warehouse chooses to process the order.In case of the foreign key, the integer in the data field must correspond to aprimary key in another table. When the “not null” condition is set on datafields, that means the information is deemed important to the record, suchas a customer’s name and address. An error will occur if a data entry is notmade 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 au-tomatically happen in other tables, even when they contain a foreign keyreferring to the changed row is the other table. To insure that this doesnot present a problem, the table must be able to handle such situations.Therefore the options “on delete cascade” and “on update cascade” to theSQL 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 specificcategory can be removed by just removing the category itself. In particu-lar the “on delete cascade” option will be used with caution, because we donot want all orders belonging to a customer to disappear if the customer isdeleted. Instead we have chosen to deny deletion of a customer if the cus-tomer is referred to by any order. [15]
Status of the order may only be set to a predefined set of values: “Pending”,“Being processed”, and “Shipped”. We have decided to use a text string forstatus so that it is easy to print out at the web shop and in the warehouseinterface. 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 arecustomerID, warehouseID, and employeeID. Except for employeeID, theseforeign keys cannot be “null”. At an early stage of the database design theemployeeID could not be “null”, but when we realized that an employee wasnot 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 itcannot be “null”. That is not the case for the shipping date which is not setuntil an order has been completely packed in postal packages and shipped.The track & trace number is provided by the mail service when a packageis shipped, so it may be “null” when order status is “Pending” and “Beingprocessed”. We represent the number with a text string, because the formatdiffers between mail services and is not limited to numeric values.
90
The queries listed in appendix C helped us create a working database whichis 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 clien-t/server system were done with RMI(Remote Method Invocation).
The remote interface figure 9.3 declares all the methods that the web shopand the warehouse client can call over the network.
� �1 public interface NetworkWarehouseInterface extends Remote {23 getOrder ( int wId ) throws RemoteException ;4 delOrder ( int order Id ) throws RemoteException ;5 productCategory ( int catID ) throws RemoteException ;6 l i s tCa t ego r y ( ) throws RemoteException ;7 changeOrderState ( int orderID , Str ing s ta tu s ) throws RemoteException ;8 getProductL i s t ( int orderID ) throws RemoteException ;9 changeProductState ( int orderID , int productID , boolean s t a t e ) throws
RemoteException ;10 getEmployees ( ) throws RemoteException ;11 setOrderEmployee ( int orderID , int employeeID ) throws RemoteException ;12 getOrderEmployee ( int orderID ) throws RemoteException ;1314 }
� �
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 HTMLpages. It needs a web server with a JSP engine to display the pages cor-rect. The most common web server for serving JSP pages is Jakarta Tomcat.Jakarta is the group name of some projects by the Apache Foundation. Tom-cat is the name of the web server, which uses Catalina, Coyote and Jasper.[2]
• Catalina: The Java Engine built into Tomcat, it provides the environ-ment needed for servlets to be run
• Coyote: The HTTP connector that is used in Tomcat, which enablesclients to connect
91
� �1 public In t eg e r l og i n ( Str ing username , Str ing password ) {23 In t eg e r r esponse = 0 ;4 Str ing u r l = ”rmi : / / 1 2 7 . 0 . 0 . 1 / ” ;56 try {7 NetworkWebShopInterface networkWebShop = ( NetworkWebShopInterface )
Naming . lookup ( u r l + ”webshop” ) ;8 r esponse = networkWebShop . l og i n ( username
, password ) ;9 } catch ( Exception e ) {
10 e . pr intStackTrace ( ) ;11 }1213 return r e sponse ;1415 }
� �
Figure 9.4: Outline of the servlet application
• Jasper: The Java Server Pages (JSP) handler, which translates JSPcode into servlets
Tomcat have a directory called webapps, where you usually place your webapplications such as our web shop. All files for the web shop must be placedinto a folder, and a subdirectory for the web shop folder must be createdcalled WEB-INF.
The WEB-INF folder is used for java classes and is not directly accessibleto visitors of the web site. The web server we have implemented is locatedin the WEB-INF folder and enables our JSP pages to call methods on ourdatabase server. So our web server class is mainly used as a transparentlayer for letting our JSP pages communicate with the database server. Infigure 9.4 is an example of the servlet code for the login method. It sendsthe username and password entered at the web shop to the warehouse serverand 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 im-plemented java using javax.swing. The orderlist and orderdescriptions areJTables which get their data from 2 datastructures. The data structures callthe getOrders and getProducts methods on server and gets the needed datafrom 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 figure 10.2. It is possibleto log in and log out in the right side of the page, where the customer canalso see the items in the shopping cart. In the center of the page a list ofproduct categories is shown, where the user can click and show all availableproducts for the chosen category as shown in figure 10.3. The process ofadding products to a shopping cart and placing an order is shown in thefollowing figures.
94
Figure 10.2: Web interface 1, the customers browse through products andadds them to the shopping cart
Figure 10.3: Web interface 2, after adding products to shopping cart, thecustomer press the place order
95
Figure 10.4: Web interface 3, the GUI tells the customer to login to placeorder, hereafter the user press the new customer buttom to create an orderaccount
Figure 10.5: Web interface 4, the customer fills in the needed information tobecome a customer and press the create button
96
Figure 10.6: Web interface 5, the customer updates his order, chooses awarehouse, check for correct information and press the accept order button
Figure 10.7: Web interface 6, the customer prints out the order and pressthe Track & Trace link
97
Figure 10.8: Web interface 7, customer views the track and trace informationand 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. Thetest method used is a bottom-up testing, starting with the primitive methodsmoving towards the main functionality. All tests were made using the unittest tool called JUnit1.
11.1 Class tests
Tests were made on all implemented model classes. The tests were madeto insure that the classes stored the information correctly, and that the getmethods in the class returned the right information. New instances of theclasses were made, and their get methods were called on them. The JUnittest 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, anda network to share methods over, the functionality tests had to be madeafter the warehouse server and a client had been made. Without the serverthe clients (warehouse and web shop) cant get in touch with any methodsand add data to their data structures. The test setup up for the getOrdersmethod can be found in appendix A.2.
1http://www.junit.org
100
11.3 Summary
The test cases from the class tests showed that all classes worked as ex-pected. The results from test case 1 in the functionality test showed thatthe getOrders()method returned the expected number of orders, each timeit was called. The results from test case 2 was as expected, the orders re-turned were correct. One problem was found though, the date returned bythe order had minutes and seconds stripped off. The error has been locatedat the database, but no actions have been taken. We did not correct theerror because it is not important for the customer or employee to know theexact 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 utilizethe system usefully, and to find any serious and minor problems with theuser interface. The test will measure the time to complete tasks and notewhere the users run into difficulty and errors. The task simulates a typicalpurchase of a product on the web site. Usability is defiend by Jeffrey Rubinas being one or more of the four factors:
Usefulness: How well a user can use the system to achive the goal of usingthe system. It is this factor which will be used as the evaluation messure inthe test, conducted in this project.
Effectiviness: Concern how easy the system is to operate. This is usuallymessured 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 fill out a background ques-tionnaire to establish the participants characteristics. The result is shown intable 12.1.
102
Characteristic Range Frequency
Education/employment Students 100%
Sex Male 67%
Female 33%
Age 19 33%
21 37%
Use of Internet per week 1-4 hours 33%
4-8 hours 33%
More than 8 hours 33%
Use of computers 5-12 hours 33%
per week More than 12 hours 67%
From where do At home 100%
they use At work/or at school 67%
the Internet Other 33%
Has purchased products online before Yes 100%
Their own definition of their 2 33%
experience with online shopping. 4 33%
From 1 - 5 where 1 is no 5 33%
experience and 5 is expert.
Table 12.1: Result of background questionnaire
From the results shown in table 12.1, a profile of the test participants canbe made: The participants are students, between 19-21 years old and witha majority 67% being males. To make sure the target group is as narrowas possible, the participants should, look alike. Therefore we chose to useparticipant with approximately the same demographically profile.
All of them has bought products online before and uses both computers andthe Internet on a regular basis. We chose only to use participants who hadsome experience working with computers and the Internet, because we wouldlike to see how users, who had some experience and therefore some standardto compare the system to, would utilize the system.
All of the participants use the Internet at home, but in addition 67% ofthe participants uses the Internet at their place of study and 33% go onlinesomewhere else. Where the participants uses the Internet could give a betterunderstanding of the users behavior and establish how the user utilize theInternet and their Internet experience.
The participants experience with online shopping is spread from novice to ex-
103
pert experience, with 67% of the participants being either accomplished usersor 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 experiencebuying products online. At the same time the experts have some expec-tations to the system. The system must be able to meet the demands ofboth.
Result and analysis of evaluation questionnaire
After the test the participants were asked to evaluate the system, based onthe recent experience with the system. As can be read in the table 12.1, theusers evaluation of the system indicates several problems which will be dealtwith in the three subsections Presentation, Overall user reaction to using thesystem and Multimedia.
PresentationWe have conducted a test inspired by the quality survey test which focuseson the user’s opinion of the web site. We decided to make this test becausewe wanted to ensure that an user would like the site and then eventuallyreturn to use the site. Only numbers below 3 is considered a problem in thisreport, and will be analyzed in this section.
Question 3: The amount of information displayed is just right The amountof information on the site was not good enough to satisfy the participants in33% of the test cases. If an user does not have enough information to utilizethe system, the user might decide to take his business elsewhere.
104
Question Range Result
Presentation From 1 - 7
1. The use of graphics is 4 33%
very appropriate for this site 6 67%
2. The design elements are 4 33%
not annoying or distracting 6 33%
7 33%
3. The amount of information 3 33%
displayed is just right 4 33%
6 33%
4. The colors in this web site 6 33%
are pleasant 7 65%
5. This site organized it’s information 4 33%
in a way that is easy for 5 33%
me to understand 7 33%
6. This site’s attractiveness invites 3 33%
me to go further into this site 4 33%
5 33%
Overall user reaction to using the system From 1 - 9
1. Terrible - wonderful 4 67%
5 33%
2. Frustrating - satisfying 6 33%
8 67%
3. Dull - stimulating NA 33%
5 67%
4. Difficult - easy 6 33%
7 33%
9 33%
5. Inadequate power - adequate power 7 33%
9 67%
6. Rigid - flexible 4 33%
5 33%
9 33%
Multimedia From 1 - 9
1. Overall quality of still 4 67%
pictures/photographs. Bad - good 9 33%
2. Overall quality of colors NA 33%
Unnatural - natural 8 33%
9 33%
3. Number of available colors 3 33%
Inadequate - adequate 8 67%
Table 12.2: Result of analyzing the evaluation questionnaire105
Question 6: This site’s 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 siteshould help the end-user to purchase the product, however to catch and holdthe users attention is a study into marketing, which we do not have time toget into in this report.
Overall user reaction to using the systemThis and the next section is about the features which were inadequate tomake the user stay on the site and to ensure that the user would like toreturn later. This is definitely problems which have to be dealt with.
Question 1: The system is terrible - wonderful 67% of the participants gradedthe site to 4, which is on the negative side of the middle. Since the pointto this evaluation number is to grade the users impression of the systemsquality this is bad. It indicates that we have to improve the system appeal.
Question 6: The system is Rigid - flexible The system was criticized, for beingsomewhat rigid. This might be explained because the participant encoun-tered an error during the usability test. Another factor might be the sitesoverall design which may not support the user in finishing the assignment.The last statement can be disputed by the answer of the other participantswho found the page to be flexible, even in one case very flexible.
MultimediaQuestion 1: Overall quality of still pictures/photographs. Bad -good 67%of the participants gave the grade 4 which indicates the site might utilizepictures to help the users find and buy a product. It might be that the par-ticipant wants to see a picture of the product before buying it. It might alsobe that the user are looking for an experience, with flashy animations andpictures.
Question 3: Number of available colors. Inadequate - adequate 33% of theparticipants were not satisfied with the amount of colors displayed on theweb 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 toanalyze when errors and critical errors occurs. In the test transcript TP1
106
means Test person no. 1. In the transcript below only relevant commentsand findings will be written. TM stands for Test monitor.
If no errors occur during a task, it does unfortunately not mean that thereare none. Finding no errors does not prove the absence of errors. If errors arenot found during the tests we consider the user interface to be acceptable.
Test transcript TP1
TP1 fills out the questionnaire without any questions
Preliminary task: TP1 does not really do much here. TP1 only looksunder a few categories.This could indicate that TP1 is not an enthusiastic user or maybe just ner-vous.
Task 1 Creates a new customer account and logs on to the system withoutany problems.It is positive that TP1 does not have any problems with this task. This indi-cates that there are no problems with performing this task.
Task 2 1: TP1 notes that there is very few products to select among, butdoes not have any problems with the task.Concerning TP1’s comment. Since there is no actual company, where theprogram would have been implemented, the actual amount of data is irrele-vant.
TP1 does not understand the colors used to indicate the stock status, anddoes not see the logic behind it.This is a serious design problem. If the user does not understand the statuscolors, this information will only serves as noise and subsequently confuse theuser. The design should make it more clear what the colors mean. Making atextual explanation could probably be a solution.
2: No problems at all
Task 3 Removes the item from the shopping cart and sends the orderwithout any problems.
107
Task 4 TP1 notes that the warehouse where the order should have beensent to is NULL, which the participant says, ”must be a mistake”. Further-more 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 oc-curred because the Track & trace system was not entirely finished. The formof the track & trace system should also be improved so that it contains morecustomer relevant information.
2. Questionnaire TP1 does not comment on the questionnaire.
Test transcript TP2
TP2 fills out the questionnaire without any questions.
Preliminary task: TP2 presses the link product catalog despite the factthat TP2 is already in the product catalogSince the front page of the web site is the product catalog this action is un-necessary. The simple solution to this action might be to make a headline inthe 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 andreport finished.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 littleconfused but solves it by closing and opening the web site.There is no log off button and TP1 really did not have any chance of loggingout. This might be a minor glitch in security, as other users might haveaccess to the prior users profile, if they use the same computer, and the firstuser has not closed the browser. Therefore the website must have a log outfunction, 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 asa result the web site does not show the participants last purchase. So theparticipant 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 easybecause the feature is provided by the program not the web site. There aremultiple possibilities to solve this problem; one could be to force the site toupdate. We chose to solve this by disabling the feature in “Internet explorer”.Another possibility seen in some web shops is to make the previous pageexpired, but we agree that that is an annoying solution to the problem andtherefore 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 thatpart of the program because it is a whole system in it self. Besides it is notallowed 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 wouldlike but other than that there is no problems.
This is the second time we encounter this problem and that is a problem. Itindicates that there is some redesigning to be done here to make the formeasier to understand for the user.
2. Questionnaire We decided to sort the comments in this Questionnaireto 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 screenand there is almost nothing on it, maybe it would look better on my own lit-tle 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 isa good thing. Furthermore the experience from web sites like Goggle showsthat a simple interface with limited amounts of text and commercials are verypopular. The following comment gives us the idea that TP2 is used to themore confusing web sites and therefore thinks that something is missing onour web site.
There is nothing to draw the attention away from what you are doing, therecould be some commercials maybe from this site, but those big ones thatmoves is not good.
109
The first part of the statement sounds good and is backing up the theories,but the following part of the comment, where TP2 requests commercials, isagainst the theories. We therefore decided not to take this entirely serioussince 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 morepictures and information about the things I could buy.This should be taken very serious and it is of course extremely important todescribe the products to sell but since we have very limited time and we arefocusing on the usability of the web site this is not a high priority. We knowthe pictures and text has to be there we just don’t have the time to write allof it inn.
Good colors.... it looks professional. I like the way the color is varying overthe page. I really like the blue colors.These comments indicate that colors we selected were colors in TP2’s taste.We choose these colors based on the our color research in section B.8 colorswhich apparently succeeded very well.
I like that the links is at the top because that is always the first place youlook. I think the page is very easy to understand.This is indicating that the page actually is user friendly which is a good thingfor our validation test.
The pictures beside the categories are ugly and I can’t see what it is.We obviously have to change those pictures.
You used very few colors, but that is also because you don’t have any com-mercials, when you get that it will be better.We believe that the amount of colors is appropriate and since we receivedsome positive comments about the coloring of the web site from TP2 thiscomment is not weighted very high.
There is no log out button. I would like that some where around my username.We will of course have to make one of those and putting it around the username is a good idea.
110
Test transcript TP3
TP3 fills out the questionnaire TP3 asks if it is okay to fill it out in Danish.No further problems or questions
Preliminary task: TP3 would like more information on the products. Asmentioned 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 finds a major bug, because the databasecannot take in a text string in the postal code. TP3 gets help and then goeson with the assignment and finishes the task without finding any other bugsin the system.This is a critical error which haves to be corrected. We have chosen to givean output that displays what has been typed wrong. This we think is the bestway to alert the user.
Task 2 1) no problems at all 2) no problem at all TP3 goes the shortestway to the individual products
when finished with the task TP3 says “that was painless”We take this comment as a compliment to an user friendly design and at thesame time as a comment to the error in the previous task.
Task 3 TP3 removes the CPU without problems, and then TP3 acceptsthe 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 first time any user have had problemsfinding a specific link.Despite this minor problem we won’t change the location of the links. Mainlybecause TP1 didn’t have any problems and TP2 praised the location of thelink. It is the first time anyone have stalled on the page, which actually ruinsa very good statistic.
2. Questionnaire TP3 has a little problems understanding what is meantby 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 informationabout 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 muchtext. We have to note that TP3 is the first to have navigation problems onthe web site. More tests could maybe show that TP3 is outside the averageuser group, or that TP1&2 is. Based on our test we have to say that TP1&2is 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 user’sorders and again we should make the track & trace form more user friendlyby explaining the contents of it clearer.
It wasn’t paradise to be on the web site but it wasn’t terrible either.It was not stimulating but it wasn’t boring either, the site is quite neutral,which is good.It was satisfying that it went so fast finding the merchandise and adding itto the shopping cart.These comments are all pretty good and do not require us to make anychanges.
If I had been an user I would not have figured 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 finding the “track & trace” but didn’t really re-member at the time where the TM asks about it.This indicates that he didn’t really notice that he had a problem locating thelink.
There are no pictures...This is said in a way that makes it sound like they are missed, and with thecomment from TP2 about pictures and description of each product, we con-clude 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 can’t seewhat 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 didnot entirely meet the participants demands. To make sure the system wouldbe able to handle the end-users demands, some changes to the system will benecessary. We have to answer the following question, “Can an end user placean order, without running into any problems?”. This is the same as askingthe question: Does the system live to the usability factor, usefulness?.
Our analyzes shows that only one of the test participants encountered a crit-ical 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 hesi-tation, but the participant recovered, and solved the problem with minimalhelp from the test monitor. The critical error happened when TP3 enteredan invalid value into a text field, which returned an SQL exception.
These two errors however were the only time, any participants had problemssolving a task. And so to answer the question. No the system did not entirelymeet the users demands, and as a result cannot be said to meet the factorusefulness. Therefore at the of the test, the system was not a Usabilitysystem. To make sure the errors determined by the test were corrected thefollowing recommendations have been made.
• Task 2 showed that TP1 had problems with understanding the colorsused 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 theireveryday life. Red green and yellow, which is used at traffic lights couldbe a solution. Furthermore they must be clearly visible, so they aredifficult to overlook
• TP2 demonstrated the need for a log out option was demonstratedwhen the participant had to write the IP address of the site in orderto remove TP1 as the registered user
113
• Based on the comments TP2 made and by the answer made by 33% ofthe participants to question 6 in table 12.1 under presentaion, the website should use more pictures and graphic. However the Jacob Nilsensrule of how to design an user interface on the web is not to use graficsjust to decorate[9]. Therefore our recomendation is only to use graficsto show the site contents
• More informaion about the products is something both TP2 and TP3wants. When two participant agrees that they need more informationbefore buying a product, the recommendation must be to put moreinformation on the site
• TP1 thinks the pictures used to illustrate the categories are ugly andTP3 also makes a comment about this. This is something that shouldbe changed as it might put a potential user off
• As TP3 commented, the track & trace function lacked information,and it was not easy to understand. To ensure the end-user will notmisunderstand the information it should be presented in an easy toread way as well as being easy to survey
We also wanted to find out the answer to the question: Does the systemsfunctions support the user in solving the task? This question concerns theUsability factor usefulness. We wanted to measure if the functions on thewebsite could be used to solve user tasks. And we discovered that they couldto some extent. However TP3 had a serious problem when an error wasdiscovered in task 1. TP1 discovered the need for a log out function, andfinally TP1 noted that it was not possible to see which warehouse the orderwas sent to. According to our test if these problems are solved the functionson 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 reflectupon how the process went, and discuss the different phases. In section 13.1we 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 projectsmain focus , the user interface. in section 13.5 we will look at the tests wemade during the project. We also in section 13.1 discuss the databases andserver.
13.1 Analysis, design, implementation, and
test
In this section we will look at how the work process in each of the four phasesin the project went, and explain our choices and reflect upon them.
13.1.1 Analysis
In this phase of the project we spend a lot of time discussing on the stepswe should take in the project. We followed the SAD curse, did the exer-cises, which corresponded very good to what we had to do in order to makeour project. Every decision and task at this point were discussed in thewhole group and noted on the blackboards. We had some early problemsin deciding what system we should make. At first we decided to make anordinary warehouse management system to an online warehouse, but someof the group members quickly came up with the idea that we should makean online web portal listing computer hardware from different suppliers allover 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 sys-tem in Java, and there was some concern, that the system we had begunto develop, did not contain enough classes to make a project in the scalerequired 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 websitewhere a customer could browse around and place an order, which would besent to a warehouse for processing.
At this point we had lost a considerable amount of time, and began to workhard in order to catch up. Each group member became responsible for a partof the analysis. This of course meant that not all of the group members knewwhat was going on in other part of the project. To ensure the project stayedon course, everything made was controlled by at least a few other membersof the group
In retrospect, it would properly have been a good idea if we had stuck toone idea. Because out of all this we had some trouble writing our systemdefinition in the right “academic” way and also so it would correspond tothe system we actually would make. We had a similar problem concerningthe class diagram, which went through considerable changes right up untilwe began coding the system.
In the beginning it was very difficult for us to separate the problem and appli-cation 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 avery large and complex system, which consisted of an administration part toadministrate statistics, employees, products and warehouses. Fortunately werealized this would become to large for us to make in the time available, andso we simplified it. In the end we decided that we wanted to make a homepage using JSP, that could be used to create customer and order objectsthat would be stored in a database. The system would also be a warehousestorage 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 woulduse network and databases. We also wanted to concentrate on creating agood user interface and believed we, by working with this idea would get theopportunity.
13.1.2 Design
This section concerns the work process in the design as well as how the designis connected with the analysis and the implementation.
117
We had some problems getting the design document done in time for thesecond review. The two weeks between the first and second review was verylittle time, and our work did became somewhat frantic as we worked to meetthe deadline. The material we delivered was a result of this, and not finishedat all. And due to this we continued working with the design for some timeafter this. The final changes in the design document did come later as aresult of working with the implementation. We discovered there was some-thing, which could be done differently, and we choose to add the changes tothe design document, to make it consistent to the program. We felt thatthe things in the documentation should reflect the finished program, but itmust be pointed out that not everything in the design document has beenimplemented.
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 struc-ture. We will explain the problems we had, and how we solved them, insection 13.3.
Later in the design phase we noticed something strange in the OOA&Dmethod. In the application analysis the method deals with the user interfacebut neither the architecture design nor the component design to follow up onthis work. This is somewhat puzzling because the work done in the analysisseems to be wasted, unless you use another design method to create the userinterface. We decided to combine the OOA&D method with a method bettersuited for graphical user interface design explained in the DEIB course.
13.2 User interface
In this section we will discuss the different problems we encountered as wellas our experiences and the decisions we made, involving the work with userinterfaces.
Warehouse and web shop GUI
The analysis made it clear that there was two kinds of requirements for thesystem, so we had to design the GUI according to these. The warehouse GUIhad to be a professional tool, which should enable the user to quickly get the
118
task done, with a minimum of effort and concentration. The web shop GUIhad a different purpose, to sell products. We decided that a website designedto e-commerce, should be visually interesting, but not be an interference insolving the task, and not an annoyance.
we had early on some design suggestions to how the user interface shouldlook like. One of the members form the group made a sketch of how the userinterface 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 ias a reference point as to how the user interface approximately should looklike.
To that end we decide, based on the DEIB lectures, to set up some designrules for the interface. Here are an explanation of how and why we choosethese rules.
Gestalt Laws
We decided to use the Gestalt laws of perceptual organization when we firstheard of them during a DEIB lecture. The reason why we wanted to workwith it, was that we would like the information on the user interface to beunderstood by the end users without any misunderstandings. We meant theGestalt laws could be helpful in meeting this goal. We utilized the Gestaltmost heavily on the design of the web shop, because we chose to test this ina usability test.
We had some difficulties finding appropriate literature which concerned thesubject, as the library did not have the books we looked for and the librari-ans looked baffled when we asked for books or articles concerning the Gestaltlaws. 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 meantthat we tried to make related objects stand out and be identifiable as beingpart of the same group.
A downside working with the Gestalt laws was that the five principles mergewith one another and as a result made it difficult for us to work with.
On the other hand it did make sense in the project to focus on some regula-tions on the design in order to make an user oriented user interface. Thereforeusing 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 acrossand support the systems purpose, sales system, we came up with an idea oflooking at how these two areas could be utilized. The idea came as a resultof a brainstorm, which came about because we wanted to focus more on theuser 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 shopGUI. However, the use of colors where going to be used most prominently inthe web shop user interface. We estimated the use of colors could benefit thesales environment and help set up the web shop as both a conservative andreliable business, which would do little good in the warehouse GUI wherecustomer 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 systemwas to work thoroughly with designing frames. as we meant we by focusingon how the implemented interface should look like would be able to betterunderstand and visualize the user interface early on in the process. We be-lieved we would get a tool which would be valuable in setting up how thewebsite should be designed.
All of us already had some experience working with frames, we had workedwith HTML before, and this had some influence in us choosing to work withframes in the project.
We had some problems with frames, as the page location bar and the shop-ping 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 HTMLinterface was made on one single page.
Wisdom
Because we focused on the GUI, we choose to use the wisdom method taughtto us in the DIEB lecture. The wisdom method was a tool when designinguser interfaces, it gave us a general course to take, from the use cases tofinding out what information the different screens should contain and whichfunctions they should handle. After this the only thing to do was to decidehow the actual GUI frames and windows should look. Because we did nothave a lot of time, we only did two essential use cases. Further more we weretold at the first review only to make on use cases, ass making more wouldbe to much work. The two use cases are however the most central ones inthe whole system. The use cases we choose were “Process order” and “Placeorder”. Process order because this is the central use case for the employeeand therefore it must function properly, and Place order because it is verycentral 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 interactionmodels, but we ran into some problems, as we had no idea how to actuallymake them, and the examples we had from DEIB, consisted of a lot of uselessinformation. Some members missed a couple of work days trying to figureout what to do, but after a meeting with a teacher we knew what we had todo, and the process went fairly fast.
As we made the dialog models ran we into another problem with the “placeorder” use case. We wanted to give the user of the system a lot of options, sohe/she can cancel what he/she does when he/she wants, and also have otheroptional choices. However, the notation we used, does not fit particularly wellfor this kind of use case and we are not sure if the dialog model is absolutelycorrect. Out of these diagrams we made interaction space models on whichwe based the design of the GUI. We could not do this for the whole systemso 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 ofa SQL database. The reason we used MySQL database, was because someof the group members knew it from personal web development projects.
121
When designing the database we had some problems with circularizes in ourdesign, which we could not work around. We were afraid there would beproblems inserting data, but we found out that because our entities are notmutually depending of one another, and the tests we made did not show anyerrors, the database system could be used. We know that the database isnot designed perfectly, however database design and persistence is not partof our focus area.
As we implemented the database, we created and dropped both databasesand a lot of tables, as we designed and redesigned. During so, we learntthat the MySQL syntax and SQL are definitely not the same thing. Notall SQL commands works in MySQL. It may have been the MySQL version4.1.7 we used, but many commands, which should have worked, did not. Asan example the ALTER query did not work as expected. We could not usethe alter command to change foreign or primary key, but it did work whenused with any other attributes.
We discovered that any changes made in the design which involved foreignkeys, would result in us dropping one or more tables. The reason we decidedto implement the database while still working on the design was that wecould see if our design actually worked or not.
To make sure our database could handle a situation where data was deletedor updated the ON DELETE CASCADE and ON UPDATE CASADE, com-mands were used. This was done to make sure that if data was updated ordeleted in one table, data in other tables with a foreign key to the first tablewould be either updated or deleted.
The ER-diagram at figure 8 shows that the delivery details, represented asattributes starting with “delivery”, were not existing in the early design ofthe database.
13.4 Implementation
Our implementation phase started out pretty well and we got our modelclasses and a basic warehouse client GUI made fast. We decided to dividethe implementation out between the members of the group, so some workedwith the database, some with the warehouse server, and others with theclients. Minor problems occurred with that but the problem that kept re-
122
turning all the way through the implementation phase were design changesand errors. A lot of time were used to “fix” minor changes, that sometimesgrew into bigger problems.
The decision about using RMI for our network functionality proved to be angood idea since it was very easy to implement into our system. More ad-vanced functions like a callback between the clients were left out though, sincewe did not have any courses in distributed programming, and not enough timeto study it further.
The web shop were made with JSP and acts like a client on the warehouseserver, sharing methods with the ’warehouse client’. We had some problemssetting up the servers to run JSP and a RMI and we ended up with usingjava version 1.5 instead of the advised version 1.4.
Sadly the system became really hard to install on every platform we tried iton, The user need a web server, a jsp server, and registries for the RMI andjava installed and setup and that is not easy for most people to do.
13.5 Test
Usability test
We decided to use Jeffrey Rubins book [13], as a guide to making the usabil-ity test. To do so we decided we wanted to make profiles of the participants,and therefore made a background questionnaire. The qustionnarie shouldprovide us with information about whether the participants had prior exspe-rience with a web shop. the demografically
At the day of the test, we had invited the first test participants to come ataround 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 tomake sure no major mistakes would occur.
The test went rather smoothly, but we did encounter a few glitches alongthe way. TP3 encountered an SQL error, which he could mot recover fromwithout outside help. The test monitor which could not see the server, alsohad to be helped in order to get on with the test. The interference did notseem 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 wason the other side of the one side mirror. We did this to make them moreconfidence about the whole situation.
The group had an positive experience with the test. The one who had nottried conducting a test before, could see . The data which we got from thetest was immense and gave us a good understanding of the things in thesystem which should be change and which worked as intended. On the downside 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 madethe decision that some of us would be responsible of analyzing the data, andmake 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 de-sign and application implementation. Furthermore we obtained experiencein testing a system.
In order to develop a system that fits the requirements from the warehouseemployees and the website customers, it is important to include them in thedevelopment process. As we were self employed in this project we had toconstruct the foundation of the project our selves. Our only external expe-rience 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 thesystem. We would continue to use test persons if we were to implement therest of the system because a potential user spot the most inadequacy in asystem.
We tried to organize ourselves as a professional development team, to max-imize the project’s outcome. But quickly found out that it was a greaterchallenge than expected.
We used the OOAD method in the development process. The method weregood for the analysis and for most of the design phase, but when we cameto the design of our interfaces it became inadequate. We started using amethod from the DIEB course, which were more appropriate for designinguser interfaces.
Just before starting on the implementation phase, decisions were made onwhat was realistic implementing in the amount of time we had left. The workassignments the secretary, login and logout on the warehouse client, the sig-naling 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 shopalmost fully implementated and a functional warehouse client, capability ofhandling orders. The warehouse administration area, payment system andan e-mail notification were left out for future implementation. This was doneto save time, and stay on focus with the user interfaces. The algorithm usedby the web shop to select a warehouse automaticly could have been mademore advanced, but again that was not in our focus area.
Our database design works and fulfils our systems needs, but yet not perfect.Since the database design courses are placed in later semesters we decidedonly to use a reasonably amount of time to look into database design and gofrom there.
At last we can conclude that the system has reached the goals for thissemester and the goals elaborated and prioritized in the analysis and de-sign document.
127
Part VII
Appendix
128
Appendix A
Code test
Throughout the implementation of the system a lot of tests were made. Toease the testing a tool called JUnit1 were used.
The test method used is a bottom-up testing, starting with the primitivemethods moving towards the main functionality.
A.1 Class tests
1 import java . u t i l . Date ;2 import j u n i t . framework . TestCase ;3 import c l a s s e s . ∗ ;4 import java . u t i l . Date ;5 /∗∗6 ∗ @author d105a7 ∗8 ∗ Test se tup f o r the model c l a s s e s9 ∗
10 ∗/11 public class UnitTest extends TestCase {12 private Employee tes tPer son ;13 private Category tes tCategory ;14 private Customer testCustomer ;15 private Order tes tOrder ;16 private Product tes tProduct ;17 private Warehouse testWarehouse ;18 private f loat pr i c e = 334 ;19 protected void setUp ( ) {20 tes tPer son = new Employee (2 , ”name” ) ;21 tes tCategory = new Category (1 , ” asus ” , ”motherboard” , ” p i c tu r e ” ) ;22 testCustomer = new Customer (1 , ” user ” , ” pass ” , ”name” , ” addres s” ,
9000 , ” aa lborg” , ”denmark ” , ”9945” , ” emai l ” ) ;
1http://www.junit.org
129
23 tes tOrder = new Order (12 , ” s t a tu s ” , 34 , 12 , 1 ,new Date ( ) ,new Date ( ), ” t r ack ” ) ;
24 tes tProduct = new Product (32 , 1 , ”name” , ”vendor ” , ”model” , pr i ce , ”d e s c r i p t i o n ” , ” p i c tu r e ” , 345 , true ) ;
25 testWarehouse = new Warehouse (12 , ”name” , ” addres s” , 34 , ” c i t y ” , ”country ” , ” emai l ” ) ;
26 }27 protected void tearDown ( ) {28 tes tPer son = null ;29 tes tCategory = null ;30 testCustomer = null ;31 tes tOrder = null ;32 tes tProduct = null ;33 testWarehouse = null ;34 }35 /∗∗36 ∗ t e s tCase1 ()37 ∗Employee c l a s s38 ∗∗/39 public void te s tCase1 ( ) {40 a s s e r tEqua l s (2 , te s tPer son . getEmployeeID ( ) ) ;41 a s s e r tEqua l s ( ” poul ” , te s tPer son . getName ( ) ) ;42 }43 /∗∗44 ∗ t e s tCase2 ()45 ∗Category c l a s s46 ∗∗/47 public void te s tCase2 ( ) {48 a s s e r tEqua l s (1 , te s tCategory . getCategoryID ( ) ) ;49 a s s e r tEqua l s ( ” asus ” , te s tCategory . getName ( ) ) ;50 a s s e r tEqua l s ( ”motherboard” , te s tCategory . g e tDes c r i p t i on ( ) ) ;51 a s s e r tEqua l s ( ” p i c tu r e ” , te s tCategory . g e tP i c tu r e ( ) ) ;52 }53 /∗∗54 ∗ t e s tCase3 ()55 ∗Customer c l a s s56 ∗∗/57 public void t e s t c a s e 3 ( ) {58 a s s e r tEqua l s (1 , testCustomer . getCustomerID ( ) ) ;59 a s s e r tEqua l s ( ” user ” , testCustomer . getUserName ( ) ) ;60 a s s e r tEqua l s ( ” pass ” , testCustomer . getPassWord ( ) ) ;61 a s s e r tEqua l s ( ”name” , testCustomer . getName ( ) ) ;62 a s s e r tEqua l s ( ” addres s” , testCustomer . getAddress ( ) ) ;63 a s s e r tEqua l s (9000 , testCustomer . getPostalCode ( ) ) ;64 a s s e r tEqua l s ( ” aa lborg” , testCustomer . getCity ( ) ) ;65 a s s e r tEqua l s ( ”9945” , testCustomer . getPhone ( ) ) ;66 a s s e r tEqua l s ( ” emai l ” , testCustomer . getEmail ( ) ) ;67 }68 /∗∗69 ∗ t e s t c a s e4 ()70 ∗Order c l a s s71 ∗∗/72 public void t e s t c a s e 4 ( ) {73 a s s e r tEqua l s (12 , te s tOrder . getOrderID ( ) ) ;74 a s s e r tEqua l s ( ” s ta tu s ” , te s tOrder . getStatus ( ) ) ;75 a s s e r tEqua l s (34 , te s tOrder . getCustomerID ( ) ) ;76 a s s e r tEqua l s (12 , te s tOrder . getWarehouseID ( ) ) ;77 a s s e r tEqua l s (1 , te s tOrder . getEmployeeID ( ) ) ;78 a s s e r tEqua l s (new Date ( ) , te s tOrder . getCreat ionDate ( ) ) ;79 a s s e r tEqua l s (new Date ( ) , te s tOrder . getShippingDate ( ) ) ;
130
80 }8182 /∗∗83 ∗ t e s t c a s e5 ()84 ∗Product c l a s s85 ∗∗/86 // ge tPr i ce method in the product c l a s s not t e s t e d due to
compl i ca t ions t e s t i n g f l o a t va lues87 public void t e s t c a s e 5 ( ) {88 a s s e r tEqua l s (32 , te s tProduct . getProductID ( ) ) ;89 a s s e r tEqua l s (1 , te s tProduct . getProductID ( ) ) ;90 a s s e r tEqua l s ( ”name” , te s tProduct . getName ( ) ) ;91 a s s e r tEqua l s ( ”model” , te s tProduct . getModel ( ) ) ;92 a s s e r tEqua l s ( ” d e s c r i p t i o n ” , te s tProduct . g e tDes c r i p t i on ( ) ) ;93 a s s e r tEqua l s ( ” p i c tu r e ” , te s tProduct . g e tP i c tu r e ( ) ) ;94 a s s e r tEqua l s (345 , te s tProduct . getQuanti ty ( ) ) ;95 a s s e r tEqua l s ( true , t e s tProduct . g e t I sP r oc e s s ed ( ) ) ;96 }97 /∗∗98 ∗ t e s t c a s e6 ()99 ∗Warehouse c l a s s
100 ∗∗/101 public void t e s t c a s e 6 ( ) {102 a s s e r tEqua l s (12 , testWarehouse . getWarehouseID ( ) ) ;103 a s s e r tEqua l s ( ”name” , testWarehouse . getName ( ) ) ;104 a s s e r tEqua l s ( ” addres s ” , testWarehouse . getAddress ( ) ) ;105 a s s e r tEqua l s (34 , testWarehouse . getPostalCode ( ) ) ;106 a s s e r tEqua l s ( ” c i t y ” , testWarehouse . getCity ( ) ) ;107 a s s e r tEqua l s ( ” country ” , testWarehouse . getCountry ( ) ) ;108 a s s e r tEqua l s ( ” emai l ” , testWarehouse . getEmail ( ) ) ;109 }110 }
A.2 Functionality tests
12 import j u n i t . framework . TestCase ;3 import c l a s s e s . ∗ ;4 import java . u t i l . ArrayList ;5 import java . u t i l . Calendar ;67 /∗∗8 ∗ @author d105a9 ∗
10 ∗ getOrders f un c t i on t e s t11 ∗/12 public class FunctionTest extends TestCase {1314 private stat ic Object [ ] [ ] o rder s ;1516 private ArrayList o r de rL i s t ;1718 private Order tmpOrder ;19
131
20 private int WAREHOUSE ID = 1 ;2122 protected void setUp ( ) {23 RMIConnection rmic = new RMIConnection ( ) ;24 try {25 o rde rL i s t = RMIConnection . d1 . getOrder (Mainprogram .
WAREHOUSE ID) ;26 } catch ( Exception e ) {27 }28 ;29 }3031 protected void tearDown ( ) {32 }3334 public void te s tCase1 ( ) {35 a s s e r tEqua l s (9 , o r de rL i s t . s i z e ( ) ) ;36 }3738 public void te s tCase2 ( ) {3940 tmpOrder = ( Order ) o r de rL i s t . get (6) ;41 a s s e r tEqua l s ( ”Pending” , tmpOrder . getStatus ( ) ) ;42 a s s e r tEqua l s (12 , tmpOrder . getOrderID ( ) ) ;43 Calendar tmpc = Calendar . g e t In s tance ( ) ;44 tmpc . s e t (2004 , Calendar .DECEMBER, 15) ;45 a s s e r tEqua l s ( tmpc . getTime ( ) , tmpOrder . getCreat ionDate ( ) ) ;46 }47 }
132
Appendix B
Test plan
B.1 Problem statement/test objectives
The goal of the test is to find possible flaws in the design which prevents asmooth and problem free usage of the application. To accomplish this theproblems 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 profile
The test involved three participants, at the research lab 1. at Aalborg uni-versity. All of the participants were tested on December 6, 2004. The par-ticipants 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 first is a background questionnaire, which gather information about thetest persons. The other concerning the participants final evaluation of thesystem.
133
Characteristic Range Frequency distribution
Age 18-21 33% below 20 years
Sex Male/Female 67 % male
Education/work Students 100%
Computer experiencebased on time used eachweek
More than five hours pr. week 33%
Previously experience with Yes/No Yes 100%
online shopping
Table B.1: User profiles
B.3.1 Greeting and background questionnaire
The test monitor reads the orientation script aloud, which contains infor-mation concerning the test and the participants part in the test. The testmonitor will insure the participant complete anonymity and that the testand the result only will be used in this project. Moreover, the participantwill be informed that the test sessions will be recorded, and observed by therest of the project group through a spy-mirror. The test monitor will en-sure the participant that there is no right solution to the task, and that theparticipant 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 willimitate how the end-user is going to utilize the system[13]. The test monitorwill set up a scenario, which must look like a scene which the test participantcan identify with. The participants, are asked to imagine being at home orwhere he/she usually buys products online. The participant is handed a notewith a task on it, and is asked to solve it. The test will be observed, theobservers will note any difficulties and errors encountered. The test monitorwill note any relevant behaviors and comments concerning the participant,and any disturbance, which may have influence on the test.
B.3.3 Participant debriefing
After the final task, the test monitor will debrief the participant. The com-puter screen will be turned off and the debriefing will be carried out with theparticipant still sitting in front of the PC.
The debriefing includes:
134
• The participant fills out the second questionnaire
• The Test monitor asks if the user has any additionally comments aboutthe system
When the test is finished, the test monitor thanks the participant for beingpart of the test.
B.4 Task list
Preliminary task: Browse through some of web pages to get some familiaritywith 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 thefirst time. This task is fairly easy to accomplish, and is meant to make theparticipant 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 difficulty level of registering on the web page.If this part is presenting any problems it will be a major problem, becauseif first 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 thatis done often.
Task 2:
• Find a SoundBlaster sound card in the catalog and add it to the shop-ping 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 pri-mary purpose of the web site. It should identify any problems the participantmay have finding a specific piece of hardware on the web site.
Task 3: Remove the Pentium 4 CPU from the shopping cart and send theorderAfter choosing a product, a customer may reconsider, and should thereforebe able to remove that product from the shopping cart. The task shouldshow if the customer has any difficulty finding or using this functionality.
Task 4: Confirm the order has been sent by using the track & trace system.The customer may want to confirm that the order has been sent to the rightwarehouse, or just make sure it has been received.
135
B.5 Test environment
The execution of the test is conducted in an electronic observation roomsetup. The test monitor and test participants were both in the test room,while the observers and technicians, all of which where members of the projectgroup were behind a two-way mirror in the observation room and the techni-cian room. The lighting of the room is going to emulate a typical office, andmust be bright enough to allow the cameras to capture the test participant’sfacial expression during the test. The furniture’s in the test room is notplaced according to any particular order, as we decided to use the existingoffice environment setup in the test room, with desks chairs and a PC. Itemsneeded for the test.
• A PC: Which the participant will use to browse the systems user in-terface
• A pen: To fill out the questionnaires
The implemented system must be able to accomplish all the functionality re-quired by the tasks as well as the finished graphical interface design. The testparticipant is expected to evaluate the graphical interface and test whetheror not the functions are usable.
B.6 Test monitor role
The primary function of the test monitor is to ensure that the test is runningsmoothly. First he will read an orientation script for the test participant andmake sure that there are no questions. Then he hands the participant thebackground questionnaire. At the usability test the test monitor will give theparticipant the assignments. The assignments are handed over one at a time,so the participant only works on one task at the time. The secondary workassignment for the test monitor is to keep the participant calm and help ifthe participant gets stuck.
B.7 Evaluation measures
We will measure the number of participants who solves the tasks and further-more measure any errors or where they have difficulty in solving the task.The errors are classified according to the list below[13].
136
• Comments and observations - test monitor and observers note whenthe participants have difficulty solving a problem. Which is manifestedby either a participant is going back and forth through the web sitesor 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 cannotfinish the task
B.8 Colors
The choice of colors in a GUI should be inviting and appealing toward theuser. According to Ben Scneiderman color speeds recognition when dealingwith several tasks and functionality [14]. He also implies that colors shouldbe conservatively used and limited to a few otherwise it might confuse theviewer. Furthermore the choice of colors may have an embedded meaningwhich differ on cultural background, for example red means hot, blue meanscold, black means death and white means birth but on the other hand inJapan and India white and black has the opposite meaning white meaningdeath and black meaning birth[4]. Today on the World Wide Web colorshave obtained a general accepted meaning, blue text for example means alink and purple text means a visited link. It is also recommended to usethese general standards, as the user otherwise might get confused, especiallyif you were to switch the use of blue and purple link color.
Color symbolism
Color meanings has a general cultural understanding among the populationbecause of our general perception taught through media, so without knowingit everyone has some degree of understanding. Below we have accumulatedsome examples of what general colors symbolize[5].
Blue Sky, Sea, Water, Religious feeling, Peace, Faith, Stability, Melan-choly, 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 briefly analyzed the way frames areused throughout the World Wide Web. We will here briefly describe how weuse frames in our design.
Figure B.1: Frames description
The top frame usually consist of a logo/slogan, navigation is recently consis-tently being adapted into the top frame, contrary to placing the navigationin the left frame.
The reason for placing the navigation in the top frame is because a left sidemenu 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 advertisingbanners is often placed below such navigation link space. The main contentarea is placed in the middle of the page; it can contain large amounts of datacontrary to boundary frames. Right frame is usually used for search link andadvertising. Bottom frame is sometimes used for shopping cart but is mostcommonly not used at all.
B.10 Font types
Fonts are divided into four main categories text fonts, display fonts, deco-rative fonts and specialty fonts. We only need to look at text fonts becausedisplay fonts, decorative fonts and specialty fonts is commonly not supportedon all systems, these fonts are therefore irrelevant, although we can mentionthat these fonts are used in word processors and computer-assisted drawingprograms, 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 thoughtto be easier on the eyes. Examples of serif text font family are Times NewRoman, Georgia and Garamond.
Figure B.2: Serif fonts
The thing serif fonts have in common is a high degree of readability, whichis 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 insmall sizes which make it compatible with low pixel resolutions. Serif fontslike Times New Roman are not very legible in small point sizes because theserifs make the letters look broken. Sans-serif fonts is legible in a way thatmakes it quick and easy for an user to get an overview of even great amountsof information. This means sans-serif fonts is a good choice especially fornavigation menu’s. Other features like italic, bold and underline styles canbe added to fonts to emphasize meanings of the text, it is not recommendedto use italic style on web applications[4].
B.11 Gestalt laws
The visual perception is important in a user interface. This is because theway the user interface is organized has an influence on the way the userunderstands the systems information. According to Jenny Preece[12], thegestalt laws of perceptual organization can be an effective tool when makinga comprehensive design. We have chosen to use the gestalt laws of perceptualorganization in this project. Therefore the design of the user interface willsupport the information by utilizing the Gestalt laws. It should be notedthat the Gestalt laws are not empirically proved, but according to slide 4.23from the DEIB course[16], it is still a good help when designing.
The Gestalt law of perceptual organization is split into five principles, prox-imity, similarity, closure, continuity and symmetry[12]. We have chosen toemploy these principles, hereby we get a tool which will help us communicatethe website information to the user without any interferences. When talkingabout objects in the following, it will include every element like pictures, textand so on in the user interface.
• Proximity: States that objects close to one another is perceived as oneunit. As such this principle will be used to group information togetherand make the user conceive the objects as being related
• Similarity: Objects of similar shape is often perceived as belongingtogether. Some pictures and thumpnails, which will be used on thewebsite, will be seen as a group because of their similarity
• Closure: An incomplete figure is perceived as the complete object,the viewer will put in the missing parts themselves to complete thefigure. The design will use this principle, heavily by enclosing related
140
information, to make sure the information is conceived as belongingtogether
• Continuity: Is a number of objects organized in such a manner thatit makes them appear belonging to the same pattern, instead of beingseen as individual objects. We will follow this principle, and placingobjects near one another so the user will conceived them as united
• Symmetry: Placing objects symmetric in the user interface is perceivedby the viewer as a border creating a figure. We will not consciouslyfollow this principle, but cannot reject that it is somewhere used
As a final note Carlos Pedroza state that the Gestalt grouping laws shouldnot be seen independently, as it influences one another [10]. The result isthat perception is a combination of all of the principles. This means the userinterface in this project is a combination of all the principles.
B.12 Dialogue style in user interfaces
There exist different interaction styles, below we briefly describe the mostcommon used. [14]
Command languageCommand language is a direct way of manipulating with a system, examplesof this could be command prompt of windows or linux. The advantages is itsflexibility and capability, it is also potentially rapid for complex tasks. Thedisadvantages is that it requires substantial training and memorization, it isdifficult to retain and has a poor error handling.
Menu selectionMenu selection is used in GUIs when you want a list of items or links the usercan select. The advantages of menu selection is that it reduces key strokes,higher level of recognition, accurate and structures decision making. Somedisadvantages can be that it requires screen space and it is sometimes dif-ficult to find appropriate terminology and the complexity of several menuscan be overwhelming for the user.
Direct manipulationVisual representation of objects and actions, using pointing, zooming andpanning the user can rapidly perform operations in GUIs. The advantagesis 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 effort.
Form fill-inForm fill-in is used in GUIs when the user needs to provide data, labelledfields is used for this purpose. The advantages is that it simplifies data entry,all information is visible and it is fast for specific types of data and last theuser only need modest training. The disadvantages could be that it consumesscreen space.
Natural languageWhen users interact through their natural language in a system. The advan-tages is that it relieves burden of learning syntax. The disadvantages is thatit requires more keystrokes it is rather unpredictable and therefore requiresa clarification 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 arelisted below. We list the tables in order of dependency, e.g. categories beforeproductDetails.
customersCREATE 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
stockStatusCREATE 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
orderDetailsCREATE 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 Train-ing, http://www.wellho.net/forum/The-Java-Programming-language/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 BartlettPublishers, Inc., first 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, andJan Stage. Objektorienteret analyse & design. Forlaget Marko, thirdedition, 2001.
An introduction to and explanation of the OOA&D method forobject-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 Nielsen’s Website,http://www.useit.com/alertbox/20031110.html.
[10] Carlos Pedroza. Visual Perception: Gestalt Laws,http://coe.sdsu.edu/eet/articles/visualperc1/start.htm.
147
[11] Abhijit A. Pol and Ravindra K. Ahuja. Developing Web-Enabled De-cision Support Systems Using VB .NET and ASP .NET. University ofFlorida, Gainesville, first edition, 2003.
[12] Jenney Preece. Human-Computer Interaction. Addison Wesley, firstedition, 1994.
[13] Jeffrey Rubin. Handbook of Usability Testing. John Wiley & Sons, Inc.,first edition, 1994.
[14] Ben Shneiderman. Designing the User Interface. Addison Wesley Long-man, Inc., third edition, 1998.
[15] Abraham Silberschatz, Henry F. Korth, and S. Sudarshan. DatabaseSystem Concepts. McGraw-Hill, fourth edition, 2001.
[16] Jan Stage. DIEB-course (Design, Implementation, and Evalu-ation of User Interfaces), DAT1/INF1-semester, Aalborg Univer-sity, Denmark, http://www.cs.auc.dk/˜jans/courses/hci-courses/dieb-2004/slides/Lektion04.pdf.
148