An online sales system
by 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 University
Department of Computer Science
ABSTRACT:
TITLE:
An online sales system
SUBJECT:
Development of software
PROJECT PERIOD:
DAT1/INF1
Department of Computer Science
September 2 - December 21, 2004
GROUP:
d105a
STUDENTS:
Dat. Kenneth Blanner Holleufer
Dat. Johnny Jakobsen
Dat. Rune Mosbæk
Dat. Martin Toft
Inf. Anders Dahl
Inf. Christian Hertz
Inf. Steffen Troldtoft
INSTRUCTOR:
Yin Xuepeng
xuepeng@cs.aau.dk
COPIES PRINTED: 9
NUMBER OF PAGES: 127
APPENDIX PAGES: 129 - 146
FINISHED: December 21, 2004
This project addresses the development of a sales system.
The system’s “company” is
not real and we do not have
any economic knowledge to
back up the presented ideas.
However the system is so
enhanced that it is able to
deal with the company’s
electronic commerce.
The system consists of a web
shop where it is possible to
order different products and
a warehouse aid application
where it is possible to receive
the orders.
The web shop part of the
system is usability tested
and is in the final state quite
user-friendly.
We used the OOA&D method
to do the analysis and design,
and theory from the course in
object-oriented programming
to write the systems in Java
and Java Server Pages. The
graphical user interface and
the usability test are designed
using theory from the DIEB
lectures.
Preface
In this semester we had the opportunity to make mixed groups between students of informatics and students of computer science, we took this opportunity and had a very interesting semester working together, sharing knowledge
from our different study backgrounds.
The web shop developed in this project can be found at
http://www.conner.dk
The included cdrom contains source code for the entire system. It may seem
difficult to run the applications, because they need Jakarta Tomcat, MySQL,
etc. The source code is only ment for viewing. Additionally, this report is
included as Postscript and PDF.
4
Contents
I
Analysis
1 The
1.1
1.2
1.3
9
task
11
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
System definition . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Problem domain
2.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 State charts . . . . . . . . . . . . . . . . . . . . . . . .
14
15
16
17
3 Application domain
3.1 Usage . . . . . . . . . . . . .
3.1.1 Overview . . . . . . .
3.1.2 Actors . . . . . . . . .
3.1.3 Use cases . . . . . . .
3.1.4 Grouping of use cases .
3.2 Functions . . . . . . . . . . .
3.2.1 Function list . . . . . .
3.2.2 Function specification .
3.3 User interface . . . . . . . . .
3.3.1 Interface functionality
3.3.2 Navigation overview .
3.4 Technical platform . . . . . .
22
22
23
23
25
29
30
30
30
32
32
33
37
II
Design
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
4 The task
42
4.1 Changes for the analysis part . . . . . . . . . . . . . . . . . . 42
4.2 Design criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5
5 Architecture
5.1 Technical platform . . .
5.1.1 Equipment . . . .
5.1.2 System software .
5.1.3 Communication .
5.1.4 Design language .
5.2 Component architecture
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
46
46
47
47
47
6 Component design
6.1 Components . . . . . . . . . . .
6.2 Model and function component
6.2.1 Model-class placement .
6.2.2 Function-class placement
6.2.3 Function specifications .
6.2.4 Summary . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
50
52
52
53
54
57
7 Graphical user interface design and components
7.1 Creating a successful graphical user interface . . .
7.2 Usage of the Gestalt laws . . . . . . . . . . . . . .
7.3 Designing the user interface . . . . . . . . . . . .
7.4 Web shop GUI . . . . . . . . . . . . . . . . . . .
7.4.1 Layout and design . . . . . . . . . . . . .
7.4.2 Dialogue style in the web shop interface .
7.4.3 Frames . . . . . . . . . . . . . . . . . . . .
7.5 Warehouse GUI . . . . . . . . . . . . . . . . . . .
7.5.1 Layout and design . . . . . . . . . . . . .
7.5.2 Dialogue style in the warehouse interface .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
58
59
60
69
70
70
71
72
72
74
.
.
.
.
.
75
76
78
80
81
81
8 Database design
8.1 Entities . . . . . . . . .
8.2 Relationships . . . . . .
8.2.1 First circularity .
8.2.2 Second circularity
8.3 Summary . . . . . . . .
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Implementation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
9 System implementation
85
9.1 Class implementation . . . . . . . . . . . . . . . . . . . . . . . 85
9.2 Warehouse server . . . . . . . . . . . . . . . . . . . . . . . . . 86
6
9.3
9.4
9.5
9.6
MySQL . . . . . . . . . . . .
Creating the database . . . .
Client/server implementation
Web server . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
88
91
91
10 Clients
93
10.1 Warehouse application . . . . . . . . . . . . . . . . . . . . . . 93
10.2 Web shop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
IV
Test
99
11 Implementation test
100
11.1 Class tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
11.2 Functionality tests . . . . . . . . . . . . . . . . . . . . . . . . 100
11.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
12 Usability test
102
12.1 Test result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . 113
V
Academic requirements
13 Academic requirements
13.1 Analysis, design, implementation, and test
13.1.1 Analysis . . . . . . . . . . . . . . .
13.1.2 Design . . . . . . . . . . . . . . . .
13.2 User interface . . . . . . . . . . . . . . . .
13.3 Database design . . . . . . . . . . . . . . .
13.4 Implementation . . . . . . . . . . . . . . .
13.5 Test . . . . . . . . . . . . . . . . . . . . .
VI
Conclusion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
116
. 116
. 116
. 117
. 118
. 121
. 122
. 123
125
14 Project conclusion
VII
115
126
Appendix
128
A Code test
129
7
A.1 Class tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A.2 Functionality tests . . . . . . . . . . . . . . . . . . . . . . . . 131
B Test plan
B.1 Problem statement/test objectives . . . . . . .
B.2 User profile . . . . . . . . . . . . . . . . . . .
B.3 Methodology . . . . . . . . . . . . . . . . . .
B.3.1 Greeting and background questionnaire
B.3.2 Validation test . . . . . . . . . . . . .
B.3.3 Participant debriefing . . . . . . . . . .
B.4 Task list . . . . . . . . . . . . . . . . . . . . .
B.5 Test environment . . . . . . . . . . . . . . . .
B.6 Test monitor role . . . . . . . . . . . . . . . .
B.7 Evaluation measures . . . . . . . . . . . . . .
B.8 Colors . . . . . . . . . . . . . . . . . . . . . .
B.9 Frames . . . . . . . . . . . . . . . . . . . . . .
B.10 Font types . . . . . . . . . . . . . . . . . . . .
B.11 Gestalt laws . . . . . . . . . . . . . . . . . . .
B.12 Dialogue style in user interfaces . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
133
133
133
133
134
134
134
135
136
136
136
137
138
139
140
141
C Database design
143
Bibliography
147
8
Part I
Analysis
9
A trading company needs an online sales system, which automatically interact with a warehouse management system.
The company started out on an idea, of offering products to the consumer
through the Internet, across the EU. The company concept is that it only
sells products through the Internet and therefore saves money on salesmen
and shops. As a result, it can offer the customer products at a very competitive price. The company has bought a number of warehouses in some of the
countries in the EU.
The customer will place an order through the online sales site, where the
customers will have the option of ordering a product from many warehouse
around EU, to ensure fast delivery a warehouse near by should be selected.
The company wants to save money when buying products, and therefore
plan to have an effective system to manage orders and their warehouses.
The products do not have to be ordered from the main suppliers if the product is available in another warehouse. Products can be exchanged between
warehouses and savings can be achieved by buying large amounts of products
simultaneously. Last the company wants to be able to update and register
products, product information and orders, for customer and administrative
usage.
10
Chapter 1
The task
1.1
Purpose
The main objective in this project is to create a computer system that enables a company to sell and administer products. Since the company consists
of a number of different warehouses spread out in different countries, the system must include a website where products from all warehouses are sold, and
furthermore an order management that coordinates inventory and orders between the warehouses.
This projects focus area will be the product sale and order management.
Statistics, payment functionalities and accounting, except for calculating the
prices of the ordered products will be excluded.
1.2
Context
We chose to describe the situation through rich pictures. An attempt to draw
the problem domain of the situation resulted in the rich picture in figure 1.1.
The picture and reflections upon it in the group afterwards gave us in-depth
insight 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 FACTOR 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 application
for handling orders for numerous warehouses. The web shop will run on any
ordinary web browser, where customers can browse through categories and
products, and place orders. The web shop furthermore includes a track and
trace system, which enables a customer to follow the progress of his/her orders.
The application for the warehouses enables the warehouse employees to process orders simple and efficient. The system will automatically keeps track
of orders and products in the warehouses, and notifies when product counts
are running low.
12
F
Functionality
Product and customer registration, order management, Internet sale
A
Application domain
Warehouse employees and customers shopping online
C
Conditions
We will carry out the system development. We have some
knowledge about system development and expect to learn
more in this semester. The warehouse employee has basic
knowledge about computers. The website customer will have
a very varying degree of computer knowledge.
T
Technology
The warehouse client will be written in Java. The website will
be made primarily in JSP. The website will be viewable using Mozilla Firefox 1.0, Internet Explorer 6.0, and most other
graphical browsers. The warehouse client will be able to run
on a standard computer with has Java. The website will be
hosted by a web server with a JSP engine and Java. The
warehouse server will require Java and a JDBC driver. All
computers will require a network connection.
O
Objects
Products, orders, customers, warehouse, invoice and employees
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 about
products, the customer, the employee and the warehouse. The registered
product information, includes technical specification and price. The customer information, is their personal data which are used for order handling.
An order can be processed by multiple employees, but only one employee can
finish an order, therefore information about this employee must be obtained
for future order support.
Based on the list of classes and the event table shown in table 2.1, we choose
to show the structural relations between the classes in the diagram at figure
2.1.
Figure 2.1: Class diagram
14
2.1
Classes
In this section we will focus on identifying the basic building blocks of our
model of the problem domain. We will find and describe the needed classes
and events, and in the end structure them in a class diagram, which is shown
at figure 2.1.
Customer: A customer is an user of the system and is represented in the
customer class. The class represents the user by registering personal data,
such as name, address, etc. a customer is associated with the order class
with an one-to-many relation, since a customer can place several orders and
an order must have exactly one customer.
Order: An order is created when a customer starts adding products. The
order is a collection of products, a warehouse and a customer. It has the ability to store the information about delivery and current state for the order,
so the customer can follow the order through a track and trace service. The
order class is the most central class in the system and is therefore associated
with several of the other classes.
Employee: An employee is a common class for all the people working at the
company. The role of the people, such as warehouse worker, secretary, etc.,
are ignored, so the employee class is the same for every employee. The class
only registers name for the employee and is only associated with the order
class.
Warehouse: The warehouse is where we keep our products. New products
purchased are added to the warehouse and the product quantity is set, and
when products are ordered by the customer the product count is decreased.
The warehouse class is mainly used for maintaining the quantity of products and storing information about a warehouse such as location and contact
information. The warehouse is associated with the order class with a zeroto-many relation, since a warehouse can have several orders, but also exist
without having any orders to process. However an order can only be assigned
to a single warehouse.
Product: The product class is the type of the product, which means we
register name of a certain vendor and model, however the specific product
with a certain registration number is not of relevance. The class describes the
information about the product such as name, model, price, etc. The product
class is an aggregation of the warehouse class, with a zero-to-many relation.
15
This means a warehouse can exist without having to contain any products,
but also that a product can exist without being added to a warehouse. This
enables the company to add new products to the system, without necessarily
adding the products to the online shop.
Invoice: The invoice class is like an order class, except it also registers,
which of the employees handled the order.
2.2
Events
A brainstorm gave us a lot of possible events for the system, which we systematically evaluated and either discarded or added to the event table shown
at table 2.1. The state charts in section 2.2.1 also added a few additional
events, which had not been thought of during the brainstorm.
Customer registered
Customer removed
Customer changed
Product added to order
Product removed from
order
Order placed
Customer
Order
+
+
*
*
*
*
*
*
+
Employee
*
+
+
*
*
Employee removed
+
+
Order closed
Product
*
*
+
+
Invoice deleted
Product registered
Product removed
Product received
Warehouse registered
Warehouse removed
*
+
Invoice
*
*
Employee registered
Processing started
Warehouse
*
*
*
+
+
Event can occur zero to many times
Event can occur zero to one time
Table 2.1: Event table
16
+
+
2.2.1
State charts
Based on the event table in section 2.2, we will make state charts for the
classes. These state charts will help us identify the states the classes can
take. The state charts are followed by a description of a general course and
a list of attributes.
Customer
Figure 2.2: State chart diagram for customer
General course:
• The customer registers in the system
• Customer login on the web shop
• The customer adds products to an order
• Customer accepts the order
• The customer logout or leaves the web shop
Order
General course:
• Products are added to order
• Order is placed
17
Attribute
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. The
warehouse facility and the sales site. In the warehouse facility the system
will support work assignments carried out by warehouse employees, who are
working with processing the orders. This includes packing and shipping products and making sure that no other employee are working on the same order.
The warehouse employees reads the needed order information and packs the
products. Then an invoice containing the customer information is printed
out, and the order is shipped. Another work assignment is registering product and warehouse information. The product information is sent by mail or
e-mail to the warehouse by its suppliers and then registered into the system.
The primary purpose of the sales site is to sell products and pass created
orders to the warehouse facility.
In this section we will give a total description of the systems usage, functions
and interfaces.
3.1
Usage
The system has three actors, the customer, warehouse employee, and a warehouse secretary. The customers can use the system to register themselves,
order products and later on follow the orders via the track & trace service.
The system automatically informs the warehouses about new orders, where
the employees have the ability to process the orders. Automatically the system also monitors the warehouses to make sure the product quantity is not
running low. The 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 the
interaction, 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 columns
and the use cases in the rows
3.1.2
Actors
List of actors:
• Customer
• Warehouse worker
• Warehouse Secretary
Customer
Purpose: A person who visits the web page, and optionally registers and
purchase products. The need of this actor group is to find products, add
products 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 delighted to get an opportunity to buy the product B wants, without leaving
the house. B has never had any significant problems with understanding
the possibility the system provides. B is technologically curious, and will
explored all of the systems possibilities.
Person C is a technical novice, with no real experience with computers, let
alone online shopping. As a result C is insecure and will quickly purchase the
desired product and then log of the system again. C only purchase product
online because he sometimes can get a product cheaper than in a shop.
Warehouse worker
Purpose: A person who is working at the warehouse and processing the customers’ orders. The warehouse worker must have access to copies of the
customers’ orders, and will mark the job they are currently working with.
Finally he will mark the order as shipped.
Characteristic: The Warehouse worker, has little or no higher education,
and only has a limited knowledge of IT.
Example: Warehouse worker A is reluctant about using computers in his
work, because he is in the habit of working with pen and paper. The Warehouse worker typically prints out the customers’ order before processing it.
Warehouse Secretary
Purpose: A person who registers and updates a warehouse’s database. The
secretary needs a well arranged work area, which supports a fast and effective
work routine.
Characteristic: The actor has basic training in the use of the system, otherwise they are often moderate IT users.
Example: Person D registers information in the database. D knows exactly how to register and update data fields with the computer system; it
has become a routine work assignment. D uses as little time as possible on
this assignment, but knows that the data must be correct, otherwise the data
24
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 marked
the objects and functions, which are involved. The functions are listed in
section 3.2 and described in section 3.3.
25
Update warehouse list
Pattern: Update warehouse list is initialized by the warehouse secretary. The
use case is initialized when a new warehouse need to be added to the system
or when an old warehouse needs to be removed. The information about the
warehouse must be entered manually by the warehouse secretary and afterwards it is stored for further use.
Objects: Warehouse secretary.
Functions: addWarehouse, removeWarehouse.
Update product list
Pattern: Update product list is initialized by the warehouse secretary. This
occur when products needs to be added to the system or when existing products needs to be removed. Products added to the system is not available on
the website before the product quantity is set.
Objects: Warehouse secretary.
Functions: addProduct, removeProduct.
Update employee list
Pattern: Update employee list is initialized by the warehouse secretary, when
a new employee needs to be added to the system or an old one removed.
Objects: Warehouse secretary.
Functions: addEmployee, removeEmployee.
Update product quantity
Pattern: Update product quantity is initialized when products added to the
system needs to be available on the web shop. This use case is also used
when new products arrive to a warehouse and the product count needs to
be changed. It is the warehouse secretary’s job to update the necessary information when needed. Indirectly the customer also uses update product
quantity use case. When a customer places an order the system decreases
the product count, to make sure the number of available products in the web
shop is correct.
Objects: Warehouse secretary, Customer.
Functions: updateProductQuantity, placeOrder.
26
Create account
Pattern: Create account use case is initialized by the customer, when he/she
wants to register as a customer in the web shop. It is required to have an
account in order to buy products from the web shop and when a new customer account have been created, the customer have to login before he/she
can place an order.
Objects: Customer.
Functions: createAccount.
Login
Pattern: Login is used by the customer, when the customer have an account
for the web shop and intends to place an order. The warehouse secretary
also uses login to enter the administration area of the system. The actor,
types in an username and password, which will be validated by the system.
Objects: Customer, Warehouse secretary.
Functions: login.
Logout
Pattern: Logout is used by the customer and warehouse secretary, and can
only be used when a customer or warehouse secretary is already logged in.
Objects: Customer, Warehouse secretary.
Functions: logout.
Change account information
Pattern: Change account information is initialized by the customer, when a
customer have changed some personal information. This could be the reason
if a customer have got a new phone number, e-mail or have changed address.
Objects: Customer.
Functions: updateCustomer.
Update products on order
Pattern: Update products on order is used by the customer when he/she
wants to buy a product. The use case for update products on order is also
used when a customer wants to remove a product from an order, but it can
only be done as long as an order has not been placed yet.
27
Objects: Customer.
Functions: addProductToOrder, removeProductFromOrder.
Search products
Pattern: Search products is initialized by the customer when the customer
is trying to locate a specific product. The customer can find the information
by searching on a part of the stored information. If the system find a match
it will send it back to the customer, if not it will inform the customer that
there were no match found in the system.
Objects: Customer.
Functions: searchProduct.
Place order
Pattern: The place order use case is started when the customer has finished
adding products to his/her order on the website, and wish to place the order at a warehouse. The system asks the customer to select a warehouse
where he/she wish to order from. If the customer has not selected a specific
warehouse, the system will try to locate the best warehouse, either by trying
to find a warehouse that can handle the order by itself, or move the needed
products between the warehouses. If the customer have chosen a warehouse,
which can not handle the order the system will try to move products from
other warehouses to the selected warehouse. The customer will get an estimated shipping date and will get the option of placing the order, or alter it.
If the customer chooses to alter the order, the customer will then be directed
to a page where he/she can add, remove products or choose a new warehouse
to handle the order. If the customer chooses to send the order, the system
will create the order at the chosen warehouse and notify involved warehouses,
and send an order confirmation back to the customer by email.
Objects: Customer
Functions: placeOrder.
View order status
Pattern: View order status is initialized by the customer, when the customer
wants to view his or her orders. When used all orders placed within a short
period will be shown with details about products and price. Another actor
is the warehouse worker, who will be able to see orders, which is pending or
being processed.
Objects: Customer, Warehouse worker.
Functions: showOrders.
28
Request products
Pattern: Request products is initialized by the warehouse worker. When the
warehouse worker needs a product for an order, which is not available in the
warehouse, the warehouse worker can request another warehouse to send the
product.
Objects: Warehouse worker.
Functions: requestProductFromWarehouse.
Process order
Pattern: The process order is initialized by the warehouse worker. The
warehouse worker marks that order, to inform other warehouse workers, that
the order is being processed.
Objects: Warehouse worker.
Functions: processOrder.
Finish order
Pattern: Finish order is used by the warehouse worker after the product has
been packed and shipped out. The Warehouse worker informs the system
that the work is done and at last the system prints out an invoice.
Objects: Warehouse worker.
Functions: closeOrder.
3.1.4
Grouping of use cases
The use cases in section 3.1.3 describes all use cases for every actor in the
system. However the actors work in different domains, so the use cases have
to be put into groups in order to specify what functionality is needed in each
domain. The customer will probably be sitting at home and using a web
browser, while the warehouse worker and secretary will be in a warehouse
and using an application to interact with the system.
The grouping of the use cases is shown in figure 3.1. It shows that the
customer takes part in all the use cases in the web shop, and the warehouse
secretary and warehouse worker take part in each their use cases in the
warehouse application. We could have chosen to make a web page where
the warehouse worker and the warehouse secretary could login and do their
tasks; however for security reasons it seemed more convenient to separate
them. So despite having a web shop, we also create a warehouse application.
29
Figure 3.1: Grouping of use cases
3.2
Functions
This section describes the functionality of the system.
3.2.1
Function list
Table 3.2 is a function list of the functions identified in the use-cases. It is
not a complete list of all functions, but it shows the most important functions
to implement the system.
3.2.2
Function specification
Most of the functions are self-explained by their names, as we only have one
complex function. However the place order function need clarification. A
more 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 the
selected warehouse is informed about the new order. Afterwards the products on the order are decreased from the product count in the warehouse.
After that the functions checks if the product count is still above the minimum limit, else the warehouse is informed. At last the function generates
and returns an invoice.
Input: An order placed by a customer in the web shop.
Output: An invoice for the order given as input.
31
Function
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 system
interfaces, the warehouse employee interface and customer web shop interface. The two interfaces have different functionality requirements in order to
substantiate the users’ needs.
3.3.1
Interface functionality
The required functionality of the interfaces is described below.
Functionality in warehouse application
• Login and logout
• Add and remove warehouse
• Add and remove employees
• Add, remove products
• Change product count
• Request product from warehouse
• Order processing
• Print order
• Finish order (when packed and shipped)
32
Functionality in web shop
• Login and logout
• Find products
• Add products to order
• Remove products from order
• Create new customer
• Update personal information
• Place order
• Print invoice
• Show previous orders (track and trace)
3.3.2
Navigation overview
We have illustrated an overview of the navigation for the warehouse and web
shop in figure 3.2 and figure 3.5
Warehouse Navigation
The elements in the figure 3.2 shows how the user can navigate from the
main window and around in the system.
Figure 3.2: Navigation diagram for the warehouse GUI
33
Examples of warehouse interface
A few examples of the interface design for the warehouse.
Figure 3.3: Warehouse interface 1
34
Figure 3.4: Warehouse interface 2
Web shop navigation
The web shop element in figure 3.5 is the start page, which have 3 frames,
where the main page frame is the product catalogue by default. The rest
of the elements in the figure shows how the page change in the main page
frame, when navigating around in the web shop.
35
Figure 3.5: Navigation diagram for the web shop. The lines of direction
marked with (*) shows that you must be logged in to go there. The lines of
direction marked with (**) shows that you must be have products in shopping
cart to go there
Examples of web shop interface
A few examples of the interface design for the web shop.
Figure 3.6: Web interface 1
36
Figure 3.7: Web interface 2
Figure 3.8: Web interface 3
3.4
Technical platform
The object-oriented analysis and design method (OOA&D) that we are using for this project, will be accompanied by corresponding, object-oriented
programming. The abstract classes and events presented through part 1 will
be 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 Environment on their personal computer, because the web shop will be distributed
to the user as HTML1 .
The web shop will run as Java Server Pages, JSP, on a web server. These
JSP pages will communicate with a Java application running at a database
server, i.e. another physical computer. The Java application runs on top
of a database service that contains personal information about registered
users and information about all products. At every warehouse there is a
computer running a Java application which enables the employees to browse
and manage orders from the web shop. This application communicates with
the application running on the database server. The general structure is
illustrated at figure 3.9.
Web Browser
Java Server Pages
(JSP)
Operating System
Web Server Layer
(Java Servlet Application)
Database Layer
(Java Application)
Warehouse Application
(Java Application)
Web Server
Database Management
System (DBMS)
Operating System
Operating System
Operating System
Web Server
Database Server
User Computer
Warehouse Computer
Figure 3.9: Technical platform
We will implement the system using Java, because we were taught Java
in OOP, an object-oriented programming course at the DAT1 and INF1
semester. One of the advantages with Java is that it is almost architecture
independence, i.e. our programs will run on every operating system that
supports Java. Figure 3.9 illustrates the web server and database server as
separated entities, but it is actually possible to combine their services onto
one computer. However, the separation can be useful when dealing with security issues such as DoS2 attacks.
The database service will be a relational database system, but from an objectoriented point of view it is not important whether the database system is
Ingres, Oracle, or another product. [6] Information is organized into several
tables, and SQL3 is used to manipulate the tables. On behalf of the user, the
1
HyperText Markup Language
Denial of Service
3
Structured Query Language
2
38
Java Server Pages running on the web server will query the Java Application
on the database server, which then query the database service. We want the
system to automatically inform warehouses when orders is placed, which is
the reason why we do not let the Java Server Pages at the web server and the
Java application at the warehouse computer to directly query the database
service at the database server. The Java application on top of the database
service acts as a middleman and also limits access to specific parts of the
database for each client. This gives a little extra security to the database if
the web server should be hacked.
39
Part II
Design
40
According to the chosen method, the purpose of the design part is to create a
coherent representation of the system design. Design criteria for the system
will be pointed out, where after the system will be structured into components. The design of the components is meant for specifying a flexible and
understandable structure, that will ease the implementation. The classes for
the components will be specified and there will be created a diagram for the
model and function component, with all classes including their attributes
and operations.
The GUI component is created from various methods including the wisdom
method. Design criteria for the graphical user interface is created and a GUI
is made according to rules for GUI design.
To make data persistent in our system, information will be saved in a database.
Based on the model component presented later, an entity-relationship diagram will be constructed. This ER-digram will then be basis for database’s
structure. The classes from the model component will correspond to the
entities in the ER-diagram; however, they will not be exactly equal.
41
Chapter 4
The task
The task is to propose the conditions for the design of the system.
4.1
Changes for the analysis part
Even though we in section 3.1.2 on page 23 have shown, that we have two
actors with quite different use cases, we will still use the same class called
employee for both of them, since they still have the same attributes.
The invoice class in the class diagram on page 14 will be removed from the
class diagram as we can use the order class for same purpose. The reason
for this, is that we have added the processedBy attribute to the order class,
which was the only 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 design
of the system. The tables 4.1 and 4.2 shows the design criteria for the web
shop and the warehouse application with each their order of priority.
42
Criteria
Very important
Usable
X
Secure
Important
Less important
Irrelevant
X
Efficient
X
Correct
X
Reliable
X
Maintainable
X
Testable
X
Flexible
X
Comprehensible
X
Reusable
Portable
Easily fulfilled
X
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 fast
and easy for the user to use
• The security of the web shop is important. The web server will handle
the basic security, and in the implementation the right connections
between the user and the system will be designed
• The efficiency of the web shop is very important. The web shop will
possibly face the job of handling several customers at a given time and
all delays are annoying. We certainly do not want customers to leave
the web shop because of slow performance
• The web shop will get product and warehouse data from the server.
It is very important that this information is correct. However minor
concurrency problems can effect that the information is not 100 percent
correct, if the customer does not refresh the web page
• Reliability is important. The user should not be bothered with connection losses and timeouts from the server
• Maintenance is easy fulfilled when all the web shop’s data is retrieved
from the server
43
• Functionality tests during development and user tests will be made.
Testable is marked less important since no special applications or classes
are made
• The applications flexibility is marked as less important
• Comprehensive is marked as very important since the users will leave
and choose another place to shop, if the information is in comprehensive
• The reusable criteria is marked as less important, since most of the web
shop is dynamic. A few static pages exist such as company profile and
contact page
• The portable criteria is important. It is difficult to make the web page
look the same in all screen resolutions and also make it independent of
having scripting languages enabled
• The web shop will not communicate with systems or applications other
than the server, so interoperability is irrelevant
Criteria
Very important
Usable
X
Important
Secure
Irrelevant
Easily fulfilled
X
Efficient
Correct
Less important
X
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 basic
security will be managed by the operating system and the database
server. No time and effort will be used on making special classes or
programs to manage the application security
• The efficiency of the application is important. With little or no delay
it should help the employee in the assigned work area
• The application will handle data coming from the web shop and other
warehouse applications through the server. Efforts will be made to
ensure that the data in the system are correct at all times
• Reliability is important. The application will be made so it can function
even though the web shop or other warehouse application clients are
down
• Maintenance is easy fulfilled. The application will be designed to dynamically get all the information from a server
• Errors that might be in our application can easily be found by an user.
The testable criteria is marked as important and tests under and after
development will be made
• The applications flexibility is marked as very important. It will be
obtained through the objected oriented design, that will allow functionality to be added or removed easily
• Comprehensive is marked as very important because, there should be
no doubt about how an employee should use the application for a given
task
• The reusable criteria is marked as less important, but since the application is build object oriented, will it be possible to reuse parts of the
application
• The application will not communicate with other systems or applications, so the interoperable is irrelevant
• The portable criteria will be easily fulfilled when developing the system
with Java [7]
45
Chapter 5
Architecture
To ease the design and understanding of our system we will in this chapter
describe the technical platform in depth and choose an architecture for our
components.
5.1
Technical platform
In this chapter we have a short description of the technical platform that our
system will use. Because the system is using a client-server architecture, we
will have to describe both of them.
5.1.1
Equipment
Because we use Java Server Pages to generate HTML code to the clients
when they connect to our web server, the only requirement is that the web
shop clients have an Internet browser like Mozilla Firefox and a standard PC
with and Internet connection. The warehouse clients will also use standard
PC’s with Internet connections but must in addition have JRE1 version 1.5
installed. The server is also required to run JRE 1.5.
5.1.2
System software
We will program the system in Java and use NetBeans to make sure that the
Java running on our server and the Java Server Pages can send the objects
over the network connection. We have chosen to use the latest Apache2
and Jakarta Tomcat version as web server because we are familiar with this
1
2
Java Runtime Environment, used for executing Java applications on end-user systems
Apache HTTP Server Project, http://httpd.apache.org
46
system, and the system is widely used around the world. For our server we
have also chosen to use the MySQL-database system. The choice is based on
the fact that the MySQL-database is a widely used open-source system
5.1.3
Communication
The system will have interfaces between the server and clients in two different ways, and interfaces are also needed inside the server. Figure 5.1 on
page 48 gives a basic overview. The Java application controlling access to the
database system interacts with the Java Servlet using methods implemented
in Java Runtime Environment. The Java programming language and the libraries already support communication between different applications, such
that the Java Servlet (which generate HTML pages for the web shop) can exchange objects with the Java application on top of the database system. This
communication can even take place through networks. The same interface
is needed on the warehouse client, because the warehouse client also needs
to exchange objects with the Java application, which ”guards” the database
system.
5.1.4
Design language
Official UML3 -notation will be used in the design of the system. UMLnotation is described briefly throughout “Objektorienteret Analyse & Design” by Mathiassen et al[6].
5.2
Component architecture
We chose to make a system that utilizes a client-server architecture, because
we have one web shop and several warehouses, which need to share information.
The web shop and the warehouses will be clients of a server containing all
necessary information, i.e. customer information, product information, orders and warehouse information. As seen on figure 5.1 we use an architecture
for distribution in the client-server architecture called local presentation.
3
Unified Modeling Language
47
Figure 5.1: Component architecture
When using local presentation the client is only responsible for the user interface, while the server is responsible for all the functionality including the
underlying model component.
In the system we have two types of clients. One client is used for all the
48
customers using the web shop, while the other is meant for the warehouses.
The web shop is on the server-side, and uses the UIS (User Interface System)
component to generate the web pages, that makes up the actual UI (User
Interface) shown on the web shop client. So the customer’s web browser only
produces an user interface from the HTML documents, which the browser
gets from the server. We like this choice, since it makes it unnecessary for
the customer to install JRE on the computer. The UIS for the warehouses
client simply uses javax.swing for the UI.
The warehouse server is the central part in our system, it manages all information about the warehouses in a database, that is the reason for the server
component to hold all the functionality in the function and model components.
We need certain functionality such as:
• Signal when new products are needed for a warehouse (the warehouses
will then have to order them manually)
• Send signal to a certain warehouse when an order for the warehouse is
placed
• Calculate the warehouse, which is estimated to process an order fastest
• Move products to other warehouses, if another warehouse needs them
49
Chapter 6
Component design
We will in this section design and describe the system’s components, starting
with the model component, followed by the function component.
6.1
Components
In this section we will list all classes for the components. We will use our
class diagram 2.1 and our state charts 2.2.1 and add further technical information needed for the implementation.
The classes in the model component are responsible for all communication
between the function and database component. The classes in the function
component are responsible for communication between the user interface and
the model component. The following is a specification of all the classes and
their 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, searchProduct, viewOrders
Shopping cart
• Purpose: To register information the products the customer wants to
buy
50
• Attributes: customer, products, warehouse, deliveryName, deliveryAttention, deliveryAddress, deliveryPostalCode, deliveryCity, deliveryCountry
• Operations: addProduct, removeProduct, changeWarehouse, changeDeliveryPlace, placeOrder
Order
• Purpose: To register information about an order
• Attributes: customer, products, warehouse, status, trackAndTraceNumber, creationDate, deliveryDate, processedBy, deliveryName, deliveryAttention, deliveryAddress, deliveryPostalCode, deliveryCity, deliveryCountry
• Operations: findWarehouse, printInvoice
Warehouse
• Purpose: To register information about the different warehouses, and
their inventory
• Attributes: name, address, postalCode, city, country, email
• Operations: addWarehouse, removeWarehouse
Product
• Purpose: Register information concerning the warehouses’ products
• Attributes: name, vendor, model, description, salesPrice, pictureWebPath, processed, quantity, warehouse
• Operations: createProduct, deleteProduct, changeQuantity, moveFromOtherWarehouse, searchForProduct
Employee
• Purpose: Register informations concerning the employee’s work on the
order
• Attributes: name
• Operations: login, logout, addEmployee, removeEmployee
WorkArea
• Purpose: To give functionality to the warehouse
• Attributes: employees, warehouses, products
• Operations: processOrder, finishOrder, viewOrders
51
6.2
Model and function component
This section will from the classes described in section 6.1 try to specify, which
classes that is placed in the model component and which of them is in the
function component.
The classes we found in the analysis shown in table 2.1 at page 14 seemed
to have a deficiency. In our event table at page 16 we can also see that we
have two common events, which can occur several times. This means that
we have to create a new class. We have some inconsistency in the way the
order class would look depending on if we want to use it in the web shop or in
the warehouse application. We will therefore create a new shoppingcart class
for the website and use the order class for the warehouse application. There
is also two common events, which can occur several times for the processing
started event, therefore we create a new class for the warehouse functionality
called workarea.
6.2.1
Model-class placement
In this section we will focus on what functions that can be assigned to the
classes in the model component.
Customer
• login
• logout
• createAccount
• updateAccount
• searchProduct
• viewOrders
Order
• 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 functions not listed in this section are functions that would make little sense
placing in the existing classes, or functions operating on several objects.
These functions will in the next section be placed in new function classes.
6.2.2
Function-class placement
The unplaced functions will be added in new classes.
ShoppingCart
• addProduct
• removeProduct
• changeWarehouse
• changeDeliveryPlace
• placeOrder
53
WorkArea
• processOrder
• finishOrder
• viewOrders
6.2.3
Function specifications
The complex functions included in this section are all related to the place
order use case described in section 3.1.3. To avoid misunderstandings and
ease the implementation, we made specifications of the functions. These
specifications will be followed by a description.
placeOrder
Name: placeOrder
Category: active, signal, update, reading
Purpose: Creates an order in the database and sends a signal about the
order to a warehouse and returns order information to the customer
Input data: ShoppingCart
Conditions: ShoppingCart object exist
Effect: An Order object is created containing information from the shopping
cart object
Algorithm: If a warehouse is not selected the findWarehouse algorithm is
run
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 shopping
cart as an order. This function will call two functions findWarehouse and
changeQuantity. The findWarehouse function is called first and finds a warehouse for the order. The changeQuantity will change the product quantity
for 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 more
products are missing at the warehouse to fulfill the order, determine
whether to choose another warehouse or move the missing products to
the 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 purpose is to find the warehouse, which can handle the order best. This is
done by remember the warehouse, which have most of the products on the
order. If not all products are available products can be removed from warehouse to warehouse later or wait for a new delivery. The pseudocode for the
findWarehouse algorithm is written in table 6.3.
55
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
bestWarehouseAvailableProducts = 0
i f ( Warehouse i s not s e t ) {
f o r ( i =0; i <numberOfWarehouses ; i ++) {
availableProducts = 0;
f o r ( j =0; j <numberOfProductsOnOrder ; j ++) {
i f ( warehouse ( i ) has p r o d u ct ( j ) ) a v a i l a b l e P r o d u c t s++
}
i f ( avai l abl eP r oducts > bestWarehouseAvailableProducts ) {
bestWarehouse = i
bestWarehouseAvailableProducts = avai l abl eP r oducts
}
}
}
Table 6.3: 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 existing
ones have been made. Last the most complex functions have been specified
to ease the implementation. Figure 6.1 is the upgraded class diagram.
57
Chapter 7
Graphical user interface design
and components
Since we chose GUI design as our main focus area we put a thorough effort
into examining the important design criteria. Hereafter we will describe some
of the main things to consider when designing an interface.
7.1
Creating a successful graphical user interface
Creating a graphical web user interface that targets all users in a selected
target group can be difficult because we believe users have different taste in
GUI design. A user friendly interface which has all the needed navigation
functions is the first step on the way to perfection.
GUI specialists such as Donald Norman tells us the human mind processes
new information based on observations and inferences, this is applicable with
e-commerce web sites as well as for the rest of society’s generalized consumer
equipment [14].
The goal of e-commerce web sites is to get the user’s attention, and encourage the user to use the site. By fulfilling their conceptual models, the basis
of navigation is accomplished. The choice of using more atypical functions
on the web application needs to be well planned to cohere with the rest of
the site and for the user to understand these functions.
Overall this means the web application must follow some of the ground principles of similar websites, which means a design model and a system image
58
that are consistent with the user’s model of the web application. “Ideally,
the user’s model and the design model are equivalent” according to Donald Norman[14]. The physical appearance, its operation, and the way it
responds, must be consistent with and exemplify the operation of the proper
conceptual model. Furthermore the website should have no irrelevant content, contrary all relevant information should be easy accessible.
To make a more interesting user interface that keep the users interested and
make them spend time on the site as well as returning, we will examine the
GUI elements recommended when building a successful user interface. In
our case the website GUI will represent the company’s public face, therefore
the website GUI should be greater prioritized than the warehouse GUI, both
nonetheless should be user friendly.
7.2
Usage of the Gestalt laws
We have chosen to utilize the Gestalt Laws B.11 in the layout of the web
shop. In the top frame we have chosen to use primary the principle Closure
and Continuity to group the elements together. The links are meant to be
conceived as one group, which contains navigational links.
In the right frame the principle closure, proximity and symmetry will be the
ones primarily used. The elements in the text fields will be group together,
because we want the user to perceive them as belonging together and when
filing out one of them, the rest must be filled out as well, this is the principles
proximity and closure. The content of the shopping cart is set between lines,
which groups related information together, in order to make the information
easy-to-read. The Gestalt principle used here are symmetry and closure.
The elements in the main frame are grouped together after the symmetry,
continuity and proximity, closure principles. The product catalog is designed after the continuity and proximity principles. The products names
and thump nails are grouped together into the form of a table. This is the
principle of both principles while the principle of proximity is used when
grouping the individually thump nail and product name together. On the
sites “product search”, “create customer” and “shopping cart”, the principles proximity and closure are used. As with text fields, in the right frame,
the principles proximity and closure are used. In addition, on the “shopping
cart” site lines are used to group information together, which is the symmetry
and closure being used.
59
7.3
Designing the user interface
In order to design the user interface we will take two use cases discussed
in chapter 3. The two use cases are “Process order” and “Place order”.
The first thing to do is to make an use case diagrams, this will help us
understand the complexity involved in performing the specified tasks and
thus help us create an user interface that will show the user the important
information and functionality that he/she will need to perform his/her task.
Hereafter an interaction model will help us understand how the user will
interact with the system through specific tasks and display what needs to
be seen in each window/frame. Then dialog-models will be constructed to
enable us to specify in which sequence the tasks will be accomplished. Based
on all this we will make an interaction space model that will be the GUI
component of the system, and based on this we will implement the GUI.
Use cases
In figure 7.1 we see the use case for process order. It is important to show
the user which orders are available in the warehouse and also if the order is
already being worked on by another employee. Therefore we have the status
“NEW” and “PENDING”. When an user chooses an order a description of
what that order contains will appear. If an employee is working on an order
that contains a lot of products, it would be a good function to mark each
found item. When all items are found and packed the employee must be able
to finish the order and input his name for future reference.
In figure 7.2 we have the process order interaction diagram. From this diagram we can see that we will separate this use case into three different
windows. The first will be an order browser thats lists the different orders
and the next will be a product browser that lists which items an order contains. If a warehouse receives a large amount of orders the data quickly
becomes unclear, by doing the above mentioned we distribute the output
and clarify the data.
The last screen will appear when an order is finished and will prompt the
user to enter his or her name. It will be placed as a separate screen appearing
every time an user finishes an order. In this way the user cannot accidently
forget to put his name on a processed order.
The dialog-model in figure 7.3 shows the order in which the tasks must be
completed. 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 will
identify and find each product in the order. When he has found all the items
he will finish his order and put his name on it.
<Employee>
Open System
<System>
Display orders
Chose order
[If status new]:
Select order
[If status pending]:
Set status pending
Show products in order
Mark products in order
[If all products marked]:
Enable Finish order
[If all products not marked]:
Press finish order
Display employee
Choose employee
Figure 7.1: Use case for process order
61
Order browser
Chose order
Product browser
Identify Product
Finish order
Choose employee
Employee browser
Figure 7.2: Interaction model for process order
62
Chose order
Proces order
<<seq>>
Find item 1
<<seq>>
<<seq>>
Finish order
Find item 2
Choose employee
Figure 7.3: Dialog model for process order
In figure 7.4 we have the use case for place order. because an order must
have customer it can be sent to an user must be logged in before he can
place one. When logged in the user must have a screen showing him what
items his order contains, the price for each item and the total price of the
order. If the user has made an error when putting an item in the shopping
cart there must be an option to either remove an item or change quantity of
the different items. Because our system gives the user the option to chose
which warehouse that will take care of the order this must be present, but
since this is an option the user should not be forced to do this.
When the user has checked all the necessary information he will have the option to accept the order and hereafter taken to the invoice screen. Here the
user will be informed that his order is created and the invoice for the order
will be displayed. The user will be given a choice to print the invoice for
future reference. In case we had decided to implement the payment methods
and classes for this system the user would have been taken through payment
screens before the invoice screen was shown.
63
In figure 7.5 we have the corresponding interaction diagram for this use case.
We have chosen to display the available information and functions in three
screens. The first screen will be the log in screen. If the user have not already
logged in when the place order button is pressed he will be presented with
the login screen. A log out button will appear when the user is logged in and
is visible at all times for log out.
The second screen will display all information about an order so the user can
review it and change it if necessary. In this way an user can get a complete
overview of his or her order without thinking about changing screens or other
unnecessary tasks. The last screen will only show the created invoice for the
order so the user gets confirmation on his order. Here he will have the ability
to print out the invoice.
The dialog model, seen in figure 7.6, is for this use case a little challenging
because the user has a lot of optional choices and the ability to log out
whenever he or she wishes, but the general dialogue is that the user logs in,
he presses place order then accept order, and then logs out.
64
<Customer>
<System>
[If customer logged in]:
Press place order
Display order screen
[not logged in]:
Log in
Prompt user to log in
[If quantity of products is right]
[If quantity not right]:
Enter X of items to remove
Press update
Remove X items from order
[If different address is needed]:
Enter delivery address
[no delivery address]:
Set delivery address
Select warehouse
[If default warehouse selected]:
Choose warehouse
in customers country
[If warehouse X selected]:
Set warehouse to X
Accept oder pressed
Order created
Display invoice screen
[no print invoice]:
[If print invoice pressed]
Print out invoice
Figure 7.4: Use case for place order
65
Log in view
Log in
Log our view
Log out
Invoice view
View invoice
Print invoice
Customer info view
Order view
Delivery addres view
Select warehouse view
Change item quantity
Set delivery address
Set warehouse
Figure 7.5: Interaction model for place order
66
Log in
Change item quantity
Place order
Set delivery address
Log out
Set warehouse
Accept order
Print Invoice
Figure 7.6: Dialog model for place order
The Interactionspacemodel for each of the use cases can be seen on figure
7.7 and figure 7.8. We now know how the GUI should be build so it will
support the use cases we have and the decisions we have made throughout
the process, now we have to design the GUI objects themselves.
67
<<Interaction Space>>
Main frame
<<Interaction Space>>
Ordertable
<<Interaction Space>>
Orderdescribtion
<<output elements>>
Internal frame(empty)
Message field
<<output elements>>
<<output elements>>
<<input elements>>
<<input elements>>
<<input elements>>
<<navigates>>
<<actions>>
Close
Finish order
<<
co
nt
ai
ns
>>
<<navigates>>
Selectorder
<<Interaction Space>>
Orderlist
>>
ns
ai
nt
co
<<actions>>
Close
<<actions>>
Exit
<<
<<navigates>>
<<Interaction Space>>
Productlist
<<output elements>>
ProductID
ProductName
Vendor
Model
Decription
Quantity
<<output elements>>
Status
OrderID
Creatiun date
<<Interaction Space>>
Employee selection
<<input elements>>
Check product
<<output elements>>
Employeelist
<<actions>>
<<input elements>>
<<input elements>>
Chose employee
<<actions>>
<<actions>>
Confirm
Figure 7.7: Interaction space model for process order
68
<<Interaction Space>>
Webshop
<<Interaction Space>>
Order view
<<Interaction Space>>
Invoice
<<output elements>>
<<output elements>>
<<output elements>>
OrderID
Creation date
WarehouseID
Total price
<<input elements>>
<<input elements>>
<<navigates>>
<<navigates>>
<<input elements>>
<<actions>>
<<actions>>
<<actions>>
Print
Accept order
>
in
s>
co
nt
a
co
nt
a
<<
<<
>
in
s>
<<contains>>
>
>
s>
in
s>
in
a
nt
co
a
nt
co
<<Interaction Space>>
Invoice productlist
<<output elements>>
Name
Address
Postal code
Country
<<output elements>>
Vendor
Name
Model
Quantity
Price
<<input elements>>
<<input elements>>
<<actions>>
<<actions>>
<<input elements>>
Warehouse
<<contains>>
<<Interaction Space>>
Customer info
<<output elements>>
<<contains>>
<<Interaction Space>>
Selectwarehouse
<<output elements>>
<<input elements>>
Name
Password
<<
<<
<<Interaction Space>>
Login
<<actions>>
<<actions>>
Login
<<Interaction Space>>
Delivery address
<<Interaction Space>>
Shopping cart
<<Interaction Space>>
Productlist
<<output elements>>
<<output elements>>
<<output elements>>
Vendor
Name
Model
Quantity
<<input elements>>
Name
Attention
Address
Postal code
Ciry
Country
Total Price
<<contains>>
<<input elements>>
<<actions>>
<<actions>>
<<input elements>>
Quantity
<<actions>>
Update
Figure 7.8: Interaction space model for place order
7.4
Web shop GUI
The Web shop GUI has been developed using the methods and concepts described previous in this chapter and in sections B.8, B.9, B.10, B.11 and B.12.
The overall objective with our web application is to sell products. The customer should have easy access to finding the desired products and the navigation should be as simple as possible to relieve the customer’s overview of
the site. Furthermore we want a simple and clean design without any irrelevant frames and other irrelevant graphics, but at the same time the graphics
must be appealing to the customer, because it is an e-commerce site and
customers should preferable return and also recommend the site to others.
69
7.4.1
Layout and design
We chose to use top, main and right frame for our web site. Our choice of
this is based on the fact that we want to keep it simple for easy navigation
and clean design without irrelevant information, but still supporting features
who can help the user to gain overview of his shopping. In the left frame we
will place our shopping basket to give the customer easy overview of the order.
Based on visual perception, section B.11, and color meanings, section B.8,
described in previous chapter we chose the color layout for the web site. We
chose blue, orange, red and gray colors for the primary layout. The reason
for this is because we want to represent ourselves as a business oriented conservative company. The blue represent stability, trust, wisdom and integrity
which are important virtues for a serious web shop. Red is used for warnings
and to get the attention of the customer. Grey means neutral and time to
make choices. Orange is a complementary color of blue and at the same time
it means creativity, determination, energy and success. The web page will
support screen size from 800x600 pixel and greater resolutions.
Web shop font
We choose a sans-serif font for our web shop based on our studies in section
B.10. Arial and Verdana is two of the most supported sans-serif fonts on
the web, we think Verdana is the best looking of the two fonts, therefore we
choose Verdana font as our default. The size of the font will be smaller than
a regular size 12 which is the default size of regular printout, this is another
reason for choosing a sans-serif font [4].
The Verdana font is a very clean font which are sometimes used on business
sites, this font type has conservative symbolic value which we also want our
company to cohere and represent. Hereby the customer hopefully will get
an overall conservative impression of the site, as being a serious business site.
7.4.2
Dialogue style in the web shop interface
The customer interface is a web interface which primarily will be using direct
manipulation and menu selection when browsing through products putting
items “visually” in a shopping cart, form fill-in will also be used when the
customer has to register to buy products. Additional information of our
studies about dialogue style can be found in section B.12.
70
7.4.3
Frames
B.9 Based on our studies about frames in section B.9 we organized our information and links primarily according to the regular concepts of the World
wide web user.
Top frame
The logo of the company is put in the upper left of the top frame, see figure
10.2 the slogan of the company will be placed in the middle of the top frame
as it is coherent with the logo.
Navigation is also placed in the top frame. The upper right navigation consist of; Create Customer, Customer Details, Track and Trace, Company and
Contact. The lower right navigation consist of; Product Catalog, Product
Search and Shopping Cart. Both upper and lower have consistent text graphics which change color on mouse over, the lower navigation also have different
icons for easy recognition.
Below these link menus we have placed a bar which also consists of a menu,
this menu changes according to what menu link is chosen. The user can press
each bar navigation link, ex. a Product category, to go back to an earlier
state, all the way back to for example the Product Catalog, which in this
case is the first.
The top menus will be accessible at all time, as it only will be the pages
below the navigation bar who changes during navigation around the web site
application.
Additionally Country, Language and Currency will be implemented, it will
consist of drop down menus containing the countries associated with the
system. Although this is not necessary for the system to function, it will
most likely not be implemented, due to lack of project time.
Main frame
The main frame will change according to what link is chosen, the default will
be the product catalog, where product categories will be shown, below the
categories advertisements of the sites special offers will be placed. All main
pages will have a gradient background of deepskyblue who gradients into a
71
light gray color, the text size and color will be controlled from CSS1 which
will make the text layout coherent so links and regular text look the same
all through the site.
Right frame
In the right frame shopping cart and login/logout will be placed. The background will be a light gray for the frame to cohere with the background
gradient of the main frame. There could be a small deviation in the basic
user concepts concerning the shopping cart in the right frame, but we think
placing the shopping basket in the right frame would be a great help for the
customer to keep overview of what is placed in the shopping cart and also
giving the overview of the total price.
7.5
Warehouse GUI
It is important to have an user-friendly warehouse application interface as it
eases the work for the employee and makes it easier to learn for new employees
and companies[13]. We tried to implement this by making an user interface
based on who the user would be and how the system would be used, which
we documented in the analysis.
7.5.1
Layout and design
In the warehouse, there is a computer with an interface which is used by
multiple warehouse workers. Therefore the usual form of log in would not
be appropriate in this case. It would simply be too demanding if the warehouse workers had to log in and out for every order they processed. Instead
when each individual order is finished it would be possible choosing which
employee’s name goes with the order by using a drop down menu, see figure
7.9.
Figure 7.9: User dropdown menu
1
Cascading Style Sheet, a file which controls layout for a website.
72
According to Human-Computer Interaction by Alan J. Dix, it is important
to keep each screen easy to survey. To do this it is necessary to keep the
screen simple. There is multiple ways to do this, the most important is to
get rid of irrelevant data and to keep the interface simple[3].
The warehouse GUI should consist of an order list where all the orders will
be queued to ensure a good overview of the screen there should be a display
of status for the individual orders so the employee quickly can see which orders to work with. Double-click on the order in the list should open an order
window in which the details of the order is displayed. To ensure an employee
can locate an older order from the orderID and creation date should be displayed also. To simplify the interaction with the application we should make
a menu bar at the top of the screen, like it is known from other programs, in
which the different functions should be implemented.
The status of a new order will be new, by clicking on it and opening the order
it will change status to pending. When the employee then ships the package
to the customer he puts an X in a shipped box the order status changes to
shipped. It is a possibility that not all the products ordered by the customer
are in stock. Then the order stays pending until it is possible to send all the
products.
To heighten the usability of the program it should be possible for the user to
make a personal setup so we will make it possible to rearrange the columns
in any order. By clicking on the column heading it should be possible to sort
the orders after orderID or status. Arranging after status should of course
arrange the orders with the new and pending orders in the top, because these
are the most relevant for the employee. The reason for being able to sort is
if the employee needs to find a specific order it can be extremely difficult to
locate it if the possibility to sort the data is not there.
The open order window contains the order number, address and name of
the customer and which products is ordered. The products are plotted into
a table which among other things contains their location in the warehouse.
Some products can easily look alike. To avoid a ”human error” we have the
remaining information about the product, to ensure the correct product gets
sent.
The File dropdown menu contains an exit function. The product dropdown
menu contains the options to add or remove products. The order dropdown
menu contains the possibility to open a new order list. The administration
73
dropdown menu gives an option to implement administrative functions like
add/remove employee, which we will not do.
Warehouse font
Java uses the default fonts installed on the operation system, it uses by
default a sans-serif font, so the readability is acceptable, we could chose a
font type for the warehouse GUI, it would result in less usability because it
could 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 the
user interface will be used at the internal storage when processing an order.
Menu selection and direct manipulation will be used by the stock employee.
Substantial use of menu selection will be used when processing orders and to
see statistics on sales. Form fill-in will be used when correcting/adding new
product categories, products, descriptions and prices.
74
Chapter 8
Database design
Partially based on the modeling component shown in figure 6.1 on page
56, the entity-relationship diagram of the database is drawn in figure 8 on
page 82. The database model should contain the same attributes as the
model component, but in some areas the ER-diagram is different. We chose
to make the database model as an ER-diagram, because we learned about
ER-diagrams in the Persistence course1 in this semester and because it corresponded to our technical platform, the MySQL platform. More information
about MySQL and the implementation of the database is available in section
9.3, however we recommend reading through this chapter first.
During our development of the ER-diagram, the two entities orderDetails
and stockStatus were made as the result of many-to-many relationships.
This type of relationships typically have the primary keys of the relating
entities as attributes [15]. However we needed more attributes than just the
primary keys, such as quantity in both orderDetails and stockStatus, so we
thought it was better to change the many-to-many relationships into entities.
As regards naming of the entities and relationships, we use a mixture of
Sun Microsystems’ naming conventions for Java code and the naming presented in chapter 1 of “Database System Concepts” by Silbershatz et al [15].
The latter uses only lower case for relationships. The entities are named so
that all substantives - except for the first one - begin with a capital letter
and continue with lower case, e.g. “productDetails” and “stockStatus”. Do
not attach additional importance to the naming, we just want to clarify our
choices to the reader. The naming is applied correct in the ER-diagram, but
in some of the following headlines we make exceptions due to layout consid1
A course held by Kristian Torp on the DAT1/INF1-semester, Department of Computer
Science, Aalborg University
75
erations, e.g. “productDetails” may be written as “ProductDetails”.
In the following sections the database’s entities and relationships will be
introduced, justified, and explained.
8.1
Entities
The entities’ primary keys are underlined at figure 8. We chose to use numeric values as the primary key in all entities, because it is faster to search
through a list of integers compared to a list of text strings [11]. In some cases
text strings would have been the natural alternative, e.g. a compound primary key in warehouses consisting of the warehouse’s name, city, and country.
We list the entities in order of appearance at the ER-diagram in figure 8 on
page 82.
Employees
This entity represents all employees working at all warehouses. Because we
opted out the administration part of the sales system, we do not want to
keep personal information about the employees. We settle for an unique
identification number and a name. In that way it is possible to distinguish
between employees with identical names.
Orders
All orders existing in the system will be represented by this entity. Only master information about an order is stored here, including unique identification
number, status, involved customer, involved warehouse, involved employee,
delivery details, various dates, and track & trace number for the distributed
package.
The ER-diagram at figure 8 shows clearly that the delivery details, represented as attributes starting with “delivery”, were not existing in the early
design of the database. There are delivery 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 stored
in the Customers entity. We think it is correct to place the attributes in the
Order entity, because the delivery details cohere to a specific order, i.e. the
customer may choose different delivery details for other orders.
76
OrderDetails
The contents of an order are kept in this entity, i.e. an order identification
number, a product identification number, and a quantity are linked together.
As an example, an order with the identification number 7 may contain two
bikes and five mopeds with the product identification number 1 and 2, respectively. That content of an order will ensue two records which will look like
(7,1,2) and (7,2,5) if written using the tuple notation (orderID, productID,
quantity). The entity contains records for all orders existing in the system
so the number of records may be extremely big. To ensure distinct records
we have added a primary key called orderDetailsID which is unique.
ProductDetails
All details concerning the products in the system are stored in this entity,
except for stock figures. Each product has an unique product identification
number and belongs to a certain category in the Categories entity. In addition information about name, vendor, model, price, description, and picture
can be kept in this entity. The product identification number is an unique,
primary key.
Categories
Products are organized into categories and this entity keeps information
about all the categories. Every category has an unique identification number, a name, a description, and a picture. The identification number is the
primary key and is referenced by products in the productDetails entity.
Customers
This entity represents all registered customers in the system. Every customer
has an unique identification number so the system is able to distinguish
between them. The number is used as an unique, primary key. A personal
user name and password are used by a customer to log on the web shop. This
entity also keeps the real name and address of a customer which is needed for
sending out ordered products and to avoid the hassle of typing in the same
information with every order. Additionally a phone number and an e-mail
address are kept as a convenient way to contact the customer.
77
Warehouses
The sales system supports multiple warehouses and information about all the
warehouses is represented by this entity. We need to store name, address,
postal code, city, country, and e-mail address of the warehouses. The latter
is kept as a convenient way to contact the warehouse. As an example the
warehouses’ e-mail addresses could be registered in a mailing list, such that
the warehouses were able to communicate easily and cheaply, however that
is out of the scope of this project. It would be reasonable to use a compound
key consisting of e.g. name, city, and country as primary key for this entity,
but for performance reasons we distinguish between the warehouses using an
identification number as previously mentioned.
StockStatus
This entity links together products, warehouses, and quantities. It has four
attributes which are: identification number for each StockStatus record, a
product identification number, a warehouse identification number, and a
quantity. In this way it is possible to express how many pieces of a single product type each warehouse got in stock. The primary key is the unique
identification number for each record which is only included to ensure distinct records. Moreover it is good practice to remember primary keys in all
entities. [15]
8.2
Relationships
In this section the database model’s relationships will be presented and accounted for. The first-hand impression of the ER-diagram may give rise to
headache for database experts, because the entities and relationships form
two circles. Circularities in ER-diagrams are known to be the root of redundant data and operational problems, but in section 8.2.1 and 8.2.2 we will
explain why that fact has nearly no impact on our structure [15]. The entities orders, orderDetails, productDetails, stockStatus, and warehouses are
involved in the circles.
The relationships are presented in order of appearance in the ER-diagram.
Employees process orders
This is an one-to-many relationship from employees to orders which cause
the employeeID attribute in the order entity. The argument for an one-to78
many relationship is that an employee may be responsible for many orders,
however an order is only processed by one employee.
Orders contain orderDetails
An order may contain many products, but a record in orderDetails only
refers to a single order in the orders entity. That is why this relationship
is one-to-many from orders to orderDetails. The products belonging to an
order are listed in orderDetails as product identification numbers together
with warehouse identification numbers and quantities.
ProductDetails are-referenced-by orderDetails
The entity productDetails contains, just like the name alludes, details on
all registered products, except for the associated stock figures. A record in
productDetails may be referenced by multiple records in orderDetails using
the product’s unique identification number, i.e. the relationship is one-tomany from productDetails to orderDetails.
Categories contain productDetails
This relationship connects categories and productDetails, because the products recorded in productDetails are categorized into categories recorded in
the categories entity. A single category may contain many products, so the
relationship is one-to-many from categories to productDetails.
Customers place orders
Hopefully, customers place orders through the web shop to utilize the system.
That act is represented by this relationship which allows a single customer
to place several orders and limits an order to be placed by one customer.
As a consequence hereof the relationship is one-to-many from customers to
orders.
Warehouses own orders
Each order is assigned to a single warehouse, such that a single warehouse
is said to “own” a number of orders. The relationship is one-to-many from
warehouses to orders, and as a result of this, the orders entity has an attribute
called warehouseID.
79
Warehouses are-referenced-by orderDetails
We want to attach each product on an order to a single warehouse, because
the products offered on the web shop may be placed at different warehouses
initially. It is then the employees’ job to examine pending orders and check
which products that should be moved between the company’s warehouses
to send only one package to the customer. As the moving progresses, the
products’ warehouse property can be updated. The relationship is one-tomany from warehouses to orderDetails, because the records in orderDetails
may only reference a single warehouse, but a warehouse may be referenced
by several records in orderDetails.
ProductDetails are-referenced-by stockStatus
Products recorded in productDetails are referenced by records in stockStatus.
The relationship is one-to-many from productDetails to stockStatus, because
a product may be in stock at several warehouses, but a record in stockStatus
may only reference a single product in productDetails.
Warehouses have stockStatus
Each warehouse has information about stock status which is recorded in
the stockStatus entity. The relationship from warehouses to stockStatus is
one-to-many, because a record in stockStatus may only point to a single
warehouse, but a record in warehouses may be linked together with several
records in stockStatus.
8.2.1
First circularity
This circularity is created by the relationships between orderDetails, productDetails, stockStatus, and warehouses. Both orderDetails and stockStatus
have the attributes productID and warehouseID, because there are one-tomany relationships away from warehouses and away from productDetails.
If the circle had circular derivation of attributes because of unidirectional
one-to-many relationships, it would present a serious problem. If that is the
case, then the database design is impossible to setup in a relational database
management system, because the tables, which represent the entities, have
to be created one at a time, and a table cannot be created if it relates to
another, non-existing table [15].
80
By inserting data into warehouses and productDetails before inserting data
into orderDetails and stockStatus, the circularity is proven unproblematic.
However, this design makes it possible to add to an order products which
are not present in the warehouse, which they are referring to in orderDetails,
i.e. orderDetails may contain a record stating seven bikes from a warehouse
that does not sell bikes (the product identification number for the bikes
are not linked together with the identification number of the warehouse in
stockStatus). That is a matter of debate, because it could be considered
either a feature or a flaw, e.g. a company may be interested in selling products
prior to having them in stock. The database layer on top of our database
insures that the system described in this report does not assign products to
warehouses, where they are not in stock.
8.2.2
Second circularity
This circularity is created by the relationships between orders, orderDetails,
and warehouses. The relationships result in the attribute orderID in orderDetails, the attribute warehouseID in orderDetails, and the attribute warehouseID in orders. As previously mentioned, the two warehouseID attributes
are needed, because an order in itself is owned by a warehouse and the order’s products may temporary be placed at other warehouses. Again, the
solution is to insert data into the entities in correct order. First create a
warehouse, then create an order, and finally add products to the order by
creating records in orderDetails. Bear in mind, that records in employees and
customers are needed to create an order, just like records in productDetails
are needed to create records in orderDetails.
8.3
Summary
We expect the database design to work just fine if implemented in a relational
database server. The implementation will be done using the MySQL database
server in section 9.3, where we will explain SQL2 and Java’s database connectivity too.
2
Structured Query Language
81
deliveryAtt
status
deliveryAdress
customerID
deliveryPostalCode
warehouseID
deliveryCity
employeeID
employees
1..1
employeeID
customerID
name
username
password
process
name
address
0..*
deliveryCountry
creationDate
shippingDate
orders
1..1
place
0..*
1..1
customers
city
0..*
trackAndTraceNumber
orderDetailsID
country
contain
own
phone
orderID
orderDetails
email
1..1
0..*
productID
warehouseID
0..*
are−referenced−by
1..1
warehouses
address
are−referenced−by
have
productID
productDetails
1..1
are−referenced−by
picture
country
stockStatus
stockStatusID
contain
price
description
0..*
email
0..*
vendor
model
postalCode
city
0..*
1..1
categoryID
name
warehouseID
name
1..1
0..*
quantity
processed
postalCode
1..1
categories
categoryID
productID
name
warehouseID
description
quantity
picture
82
orderID
Figure 8.1: Entity-relationship diagram for the database
deliveryName
Part III
Implementation
83
In the implementation part we focus on how we have implemented our system. Due to the limited time period we have not implemented the whole
system. We have focused on getting a working web shop and warehouse
server, but also implemented a part of the warehouse client. The limitations
in the warehouse client is basically the functionality for the actor called secretary. There is no login and logout for the warehouse client and as well there
is no options for adding and removing employees, products and warehouses
to the system via the warehouse client.
After struggling with RMI-callback and thought about the time costs of getting it to work, we have chosen not to implement it. That resulted in the
warehouse client is not updated automatically, but only when the window is
opened. The warehouse client was meant to be updated when new orders arrives or a product quantity is running low. Another feature not implemented,
because it is depended on RMI-callback is the moveFromOtherWarehouse
operation in the product class.
84
Chapter 9
System implementation
In the implementation phase we take the system designed in the design phase
and realize it on the selected technical platform. In this section we will
go through the implementation of the database, the model classes, and the
function classes.
9.1
Class implementation
The implementation of the classes from the class diagram at figure 6.1 have
been implemented, but we have made some changes to the design during the
implementation phase. The implementation started with coding the classes
in the model component. The main differences in the model component between the design and implementation is the placeOrder method.
• In the implementation the method has been placed in the Order class,
while it is located in the shopping cart class in the system design
• In the design the changeQuantity method from the product class have
not been implemented, but the functionality the method has is implemented in the placeOrder method
• To ease the implementation of the products we have created a new
class called category. It is mainly used for grouping a certain type of
products
85
9.2
Warehouse server
We have implemented our warehouse server, which uses RMI for communication across networks and (My)SQL-syntax for storing data in a MySQL
database. Our warehouse server works like a top-layer for the MySQL
database. The main reason for implementing our warehouse server instead of
just connecting directly to the MySQL database, is that we want to update
the warehouse-client as soon as orders are placed in the online web shop. We
also want to notice warehouse-clients automatically, when a product count
is running low. If we have chosen to skip our database server, the warehouse
client could have updated. Instead it updates automatically in time intervals,
but we wanted to inform the warehouses instantly when orders are placed or
a product count is running low.
When the warehouse server is started, the first step is to load our Database
class, which initialize a connection to the MySQL database. Afterwards new
instances of the NetworkWebShop and NetworkWarehouse classes are made,
and the database server binds them as remote objects to a specific name.
RMIRegistry must run in order for our database server to work. Each of
our remote objects have the necessary methods to make the web shop and
warehouse application work. When a method is called via the RMI, the
methods’ arguments are forwarded to local method in one of our system’s
classes, which handles the data and interacts with MySQL.
Our database server have the following system classes:
• Category
• Customer
• Employee
• Order
• Product
• ShoppingCart
• Warehouse
Each of the system classes can access the MySQL database by using the
connection initialized when the server started. Most of the methods just
need to update some data in the database or retrieve some data. However
our placeOrder method in the Order class, which is invoked from the web
86
shop, will have to send data to a specific warehouse, which can be solved by
using RMI-callback.
9.3
MySQL
MySQL is a relational database server owned and sponsored by a single
Swedish, for-profit firm, MySQL AB. It is available under different licenses to
accommodate all intended use, such as the GPL1 . Both source code and binaries (for Linux, FreeBSD, Windows, etc.) are freely accessible from MySQL’s
official homepage at http://dev.mysql.com. The application turns in a strong
performance being multithreaded, and security is available through multiuser support. [8] We utilize the latter by creating an user called “wwwuser”
only with permission to select from, insert into, update, and delete from tables. The tables will be created and owned by the “root” user who is the
database’s administrator. [1]
Just like The Apache Derby Project (the database server introduced to us in
this semester’s PER-course), MySQL is reached from within a Java application using a JDBC-driver2 . Sun Microsystems let the developers of database
servers develop their own drivers for connectivity; MySQL’s is called MySQL
Connector/J.
MySQL Connector/J
MySQL Connector/J is downloadable from MySQL’s official homepage and
requires only a simple installation. We will introduce the reader to Connector/J through examples. Please note, that the presented code needs to
have nearly all classes from the java.sql package imported. Within a Java
application, a database connection is initialized by this short code:
Connection c;
Class.forName("com.mysql.jdbc.Driver").newInstance();
c = DriverManager.getConnection("jdbc:mysql://" + host + "/" + database + "?user=" +
user_name + "&password=" + password);
In our case the connection string is “jdbc:mysql://127.0.0.1/d105a?user=wwwuser&password=nO8xT26Gja”. A query may now be made through a
statement:
1
2
GNU General Public License, http://www.gnu.org/licenses/licenses.html#GPL
Java Database Connectivity
87
Statement s;
s = c.createStatement();
s.executeUpdate("UPDATE customers SET name=’" + name + "’, address=’" + address +
"’, postalCode=" + postalCode + ", city=’" + city + "’, country=’" +
country + "’, phone=’" + phone + "’, email=’" + email +
"’ WHERE customerID=" + customerID);
The query updated a customer account with new values. It is also possible
to retrieve information from the database, e.g. the identification number of
a customer based on an user name:
ResultSet r;
r = s.executeQuery("SELECT customerID FROM customers WHERE username=’" + username +
"’");
To end the example, we close the statement and the connection:
s.close();
c.close();
The system needs a database with contents, so we will continue in section 9.4
by building tables representing the entities from chapter 8, database design.
Beside informal attributes, the tables will contain primary and foreign keys
representing relationships.
9.4
Creating the database
The database is created using MySQL’s command-line tool at the computer
running MySQL. The tool is started and two commands are typed in to
create the database and use it:
(shell)$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 7 to server version: 4.0.22_Debian-6-log
Type ’help;’ or ’\h’ for help. Type ’\c’ to clear the buffer.
mysql> create database d105a;
Query OK, 1 row affected (0.08 sec)
mysql> use d105a;
Database changed
Based on the ER-diagram, we have constructed a list of queries to create
the tables in the database. We will present two of them here; one to create
categories, and one to create productDetails. A complete list of “CREATE
TABLE” queries and resulting tables are available in appendix C. The query
for creating categories can be seen in figure 9.1. The categories’ name and
88
picture is represented using text strings of up to 60 characters wide. The
identification number is an auto-incrementing integer, and the description a
“text” with a maximum length of 65535 (216 − 1) characters. [1]
CREATE TABLE categories (categoryID INT AUTO_INCREMENT, name VARCHAR(60) NOT
NULL, description TEXT, picture VARCHAR(60), PRIMARY KEY (categoryID));
+-------------+-------------+------+-----+---------+----------------+
| Field
| Type
| Null | Key | Default | Extra
|
+-------------+-------------+------+-----+---------+----------------+
| categoryID | int(11)
|
| PRI | NULL
| auto_increment |
| name
| varchar(60) |
|
|
|
|
| description | text
| YES |
| NULL
|
|
| picture
| varchar(60) | YES |
| NULL
|
|
+-------------+-------------+------+-----+---------+----------------+
Figure 9.1: Creation of the table categories
The next table, productDetails, will take advantage of a foreign key to link
itself to categories. The attribute “categoryID” in productDetails is a key
referencing the primary key in categories; hence it is a foreign key. This
insures that new products must be “put into” an existing category from
categories. The query to create productDetails is seen in 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 that
the table’s data field must contain data. The primary keys in a table must
contain data or else an error will occur. The foreign keys differ a bit, as
seen with “orders” where “employeeID” may be “null” (check out appendix
89
C). We chose “not null” for that attribute, because an employee is not necessarily appointed when an order is created, but instead the appointment
occur later when an employee at a warehouse chooses to process the order.
In case of the foreign key, the integer in the data field must correspond to a
primary key in another table. When the “not null” condition is set on data
fields, that means the information is deemed important to the record, such
as a customer’s name and address. An error will occur if a data entry is not
made into a “not null” attribute when inserting data into a table. [15]
When a row is removed or updated from a table, the change does not automatically happen in other tables, even when they contain a foreign key
referring to the changed row is the other table. To insure that this does
not present a problem, the table must be able to handle such situations.
Therefore the options “on delete cascade” and “on update cascade” to the
SQL command “create table” will be used. It is also a considerable feature,
because it eases the operation of the database, e.g. all products in a specific
category can be removed by just removing the category itself. In particular the “on delete cascade” option will be used with caution, because we do
not want all orders belonging to a customer to disappear if the customer is
deleted. Instead we have chosen to deny deletion of a customer if the customer is referred to by any order. [15]
Status of the order may only be set to a predefined set of values: “Pending”,
“Being processed”, and “Shipped”. We have decided to use a text string for
status so that it is easy to print out at the web shop and in the warehouse
interface. Text strings are also more expressive than numeric values, e.g. 1,
2, 3. The entity have three foreign keys referring to other entities which are
customerID, warehouseID, and employeeID. Except for employeeID, these
foreign keys cannot be “null”. At an early stage of the database design the
employeeID could not be “null”, but when we realized that an employee was
not assigned to an order imidiately, we had to make values of “null” possible.
The creation date of an order must be set when creating a new order so it
cannot be “null”. That is not the case for the shipping date which is not set
until an order has been completely packed in postal packages and shipped.
The track & trace number is provided by the mail service when a package
is shipped, so it may be “null” when order status is “Pending” and “Being
processed”. We represent the number with a text string, because the format
differs between mail services and is not limited to numeric values.
90
The queries listed in appendix C helped us create a working database which
is now taking care of persistence in the back-end of our system.
9.5
Client/server implementation
Since everything is implemented in Java the implementation of the client/server system were done with RMI(Remote Method Invocation).
The remote interface figure 9.3 declares all the methods that the web shop
and the warehouse client can call over the network.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public i n t e r f a c e N etw o r k Wa r eh o u s eIn te r f a ce extends Remote {
g etO r d er ( i n t wId ) throws RemoteException ;
d e l O r d e r ( i n t o r d e r I d ) throws RemoteException ;
p r o d u ctC a teg o r y ( i n t catID ) throws RemoteException ;
l i s t C a t e g o r y ( ) throws RemoteException ;
ch a n g eO r d er S ta te ( i n t orderID , S t r i n g s t a t u s ) throws RemoteException ;
g e t P r o d u c t L i s t ( i n t o r d er ID ) throws RemoteException ;
ch a n g eP r o d u c t S t a t e ( i n t orderID , i n t productID , boolean s t a t e ) throws
RemoteException ;
g etE m p l o y ees ( ) throws RemoteException ;
setOrderEmploy ee ( i n t orderID , i n t employeeID ) throws RemoteException ;
getOrderEmployee ( i n t o r d er ID ) throws RemoteException ;
}
Figure 9.3: The remote interface used by the warehouse client
9.6
Web server
The web shop is written in JSP, which is embedded into the static HTML
pages. It needs a web server with a JSP engine to display the pages correct. The most common web server for serving JSP pages is Jakarta Tomcat.
Jakarta is the group name of some projects by the Apache Foundation. Tomcat is the name of the web server, which uses Catalina, Coyote and Jasper.
[2]
• Catalina: The Java Engine built into Tomcat, it provides the environment needed for servlets to be run
• Coyote: The HTTP connector that is used in Tomcat, which enables
clients to connect
91
1
2
3
4
5
6
7
public I n t e g e r l o g i n ( S t r i n g username , S t r i n g password ) {
Integer
String
response = 0;
url
= ” rmi : / / 1 2 7 . 0 . 0 . 1 / ” ;
try {
NetworkWebShopInterface networkWebShop = ( NetworkWebShopInterface )
Naming . l o o k u p ( u r l + ” webshop ” ) ;
response
= networkWebShop . l o g i n ( username
, password ) ;
} catch ( E x cep ti o n e ) {
e . printStackTrace () ;
}
8
9
10
11
12
13
14
15
return r e s p o n s e ;
}
Figure 9.4: Outline of the servlet application
• Jasper: The Java Server Pages (JSP) handler, which translates JSP
code into servlets
Tomcat have a directory called webapps, where you usually place your web
applications such as our web shop. All files for the web shop must be placed
into a folder, and a subdirectory for the web shop folder must be created
called WEB-INF.
The WEB-INF folder is used for java classes and is not directly accessible
to visitors of the web site. The web server we have implemented is located
in the WEB-INF folder and enables our JSP pages to call methods on our
database server. So our web server class is mainly used as a transparent
layer for letting our JSP pages communicate with the database server. In
figure 9.4 is an example of the servlet code for the login method. It sends
the username and password entered at the web shop to the warehouse server
and if it is a valid account it will return a reference to the customer class.
92
Chapter 10
Clients
10.1
Warehouse application
The picture 10.1 shows the implemented warehouse client. The GUI is implemented java using javax.swing. The orderlist and orderdescriptions are
JTables which get their data from 2 datastructures. The data structures call
the getOrders and getProducts methods on server and gets the needed data
from the database.
93
Figure 10.1: Screen dump of the warehouse client
10.2
Web shop
The web shop has been implemented as shown in figure 10.2. It is possible
to log in and log out in the right side of the page, where the customer can
also see the items in the shopping cart. In the center of the page a list of
product categories is shown, where the user can click and show all available
products for the chosen category as shown in figure 10.3. The process of
adding products to a shopping cart and placing an order is shown in the
following figures.
94
Figure 10.2: Web interface 1, the customers browse through products and
adds them to the shopping cart
Figure 10.3: Web interface 2, after adding products to shopping cart, the
customer press the place order
95
Figure 10.4: Web interface 3, the GUI tells the customer to login to place
order, hereafter the user press the new customer buttom to create an order
account
Figure 10.5: Web interface 4, the customer fills in the needed information to
become a customer and press the create button
96
Figure 10.6: Web interface 5, the customer updates his order, chooses a
warehouse, check for correct information and press the accept order button
Figure 10.7: Web interface 6, the customer prints out the order and press
the Track & Trace link
97
Figure 10.8: Web interface 7, customer views the track and trace information
and hereafter logs out and awaits his order in the mail
98
Part IV
Test
99
Chapter 11
Implementation test
Throughout the implementation of the system a lot of tests were made. The
test method used is a bottom-up testing, starting with the primitive methods
moving towards the main functionality. All tests were made using the unit
test tool called JUnit1 .
11.1
Class tests
Tests were made on all implemented model classes. The tests were made
to insure that the classes stored the information correctly, and that the get
methods in the class returned the right information. New instances of the
classes were made, and their get methods were called on them. The JUnit
test setup can be found in appendix A.1.
11.2
Functionality tests
Since our system is designed to use a database as main data source, and
a network to share methods over, the functionality tests had to be made
after the warehouse server and a client had been made. Without the server
the clients (warehouse and web shop) cant get in touch with any methods
and add data to their data structures. The test setup up for the getOrders
method can be found in appendix A.2.
1
http://www.junit.org
100
11.3
Summary
The test cases from the class tests showed that all classes worked as expected. The results from test case 1 in the functionality test showed that
the getOrders()method returned the expected number of orders, each time
it was called. The results from test case 2 was as expected, the orders returned were correct. One problem was found though, the date returned by
the order had minutes and seconds stripped off. The error has been located
at the database, but no actions have been taken. We did not correct the
error because it is not important for the customer or employee to know the
exact minutes and seconds on a shipped and created order.
101
Chapter 12
Usability test
The purpose of the test is to discover whether an actual end user can utilize
the system usefully, and to find any serious and minor problems with the
user interface. The test will measure the time to complete tasks and note
where the users run into difficulty and errors. The task simulates a typical
purchase of a product on the web site. Usability is defiend by Jeffrey Rubin
as being one or more of the four factors:
Usefulness: How well a user can use the system to achive the goal of using
the system. It is this factor which will be used as the evaluation messure in
the test, conducted in this project.
Effectiviness: Concern how easy the system is to operate. This is usually
messured through speed performance.
Leanability: How quickly the user can operate the system.
Attitude: How well the user like to operate the system.
12.1
Test result
The participant used in the test where asked to fill out a background questionnaire to establish the participants characteristics. The result is shown in
table 12.1.
102
Characteristic
Range
Frequency
Education/employment
Students
100%
Sex
Male
67%
Female
33%
19
33%
21
37%
1-4 hours
33%
4-8 hours
33%
Age
Use of Internet per week
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 can
be made: The participants are students, between 19-21 years old and with
a majority 67% being males. To make sure the target group is as narrow
as possible, the participants should, look alike. Therefore we chose to use
participant with approximately the same demographically profile.
All of them has bought products online before and uses both computers and
the Internet on a regular basis. We chose only to use participants who had
some experience working with computers and the Internet, because we would
like to see how users, who had some experience and therefore some standard
to compare the system to, would utilize the system.
All of the participants use the Internet at home, but in addition 67% of
the participants uses the Internet at their place of study and 33% go online
somewhere else. Where the participants uses the Internet could give a better
understanding of the users behavior and establish how the user utilize the
Internet and their Internet experience.
The participants experience with online shopping is spread from novice to ex103
pert experience, with 67% of the participants being either accomplished users
or experts. It is important that not only experts can handle the system,
because the average end-user cannot be expected to have a lot of experience
buying products online. At the same time the experts have some expectations to the system. The system must be able to meet the demands of
both.
Result and analysis of evaluation questionnaire
After the test the participants were asked to evaluate the system, based on
the recent experience with the system. As can be read in the table 12.1, the
users evaluation of the system indicates several problems which will be dealt
with in the three subsections Presentation, Overall user reaction to using the
system and Multimedia.
Presentation
We have conducted a test inspired by the quality survey test which focuses
on the user’s opinion of the web site. We decided to make this test because
we wanted to ensure that an user would like the site and then eventually
return to use the site. Only numbers below 3 is considered a problem in this
report, and will be analyzed in this section.
Question 3: The amount of information displayed is just right The amount
of information on the site was not good enough to satisfy the participants in
33% of the test cases. If an user does not have enough information to utilize
the system, the user might decide to take his business elsewhere.
104
Question
Presentation
Range
Result
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
1. Terrible - wonderful
2. Frustrating - satisfying
3. Dull - stimulating
4. Difficult - easy
5. Inadequate power - adequate power
6. Rigid - flexible
Multimedia
From 1 - 9
4
67%
5
33%
6
33%
8
67%
NA
33%
5
67%
6
33%
7
33%
9
33%
7
33%
9
67%
4
33%
5
33%
9
33%
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
105 the evaluation questionnaire
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 site
should help the end-user to purchase the product, however to catch and hold
the users attention is a study into marketing, which we do not have time to
get into in this report.
Overall user reaction to using the system
This and the next section is about the features which were inadequate to
make the user stay on the site and to ensure that the user would like to
return later. This is definitely problems which have to be dealt with.
Question 1: The system is terrible - wonderful 67% of the participants graded
the site to 4, which is on the negative side of the middle. Since the point
to this evaluation number is to grade the users impression of the systems
quality this is bad. It indicates that we have to improve the system appeal.
Question 6: The system is Rigid - flexible The system was criticized, for being
somewhat rigid. This might be explained because the participant encountered an error during the usability test. Another factor might be the sites
overall design which may not support the user in finishing the assignment.
The last statement can be disputed by the answer of the other participants
who found the page to be flexible, even in one case very flexible.
Multimedia
Question 1: Overall quality of still pictures/photographs. Bad -good 67%
of the participants gave the grade 4 which indicates the site might utilize
pictures to help the users find and buy a product. It might be that the participant wants to see a picture of the product before buying it. It might also
be that the user are looking for an experience, with flashy animations and
pictures.
Question 3: Number of available colors. Inadequate - adequate 33% of the
participants were not satisfied with the amount of colors displayed on the
web site. On the other hand 67% of the rest were exited about the colors.
As a result we have decided not to alter the colors on the site.
Usability test
In this section the usability test will be reported. We have decided only to
analyze when errors and critical errors occurs. In the test transcript TP1
106
means Test person no. 1. In the transcript below only relevant comments
and findings will be written. TM stands for Test monitor.
If no errors occur during a task, it does unfortunately not mean that there
are none. Finding no errors does not prove the absence of errors. If errors are
not found during the tests we consider the user interface to be acceptable.
Test transcript TP1
TP1 fills out the questionnaire without any questions
Preliminary task: TP1 does not really do much here. TP1 only looks
under a few categories.
This could indicate that TP1 is not an enthusiastic user or maybe just nervous.
Task 1 Creates a new customer account and logs on to the system without
any problems.
It is positive that TP1 does not have any problems with this task. This indicates that there are no problems with performing this task.
Task 2 1: TP1 notes that there is very few products to select among, but
does not have any problems with the task.
Concerning TP1’s comment. Since there is no actual company, where the
program would have been implemented, the actual amount of data is irrelevant.
TP1 does not understand the colors used to indicate the stock status, and
does not see the logic behind it.
This is a serious design problem. If the user does not understand the status
colors, this information will only serves as noise and subsequently confuse the
user. The design should make it more clear what the colors mean. Making a
textual explanation could probably be a solution.
2: No problems at all
Task 3 Removes the item from the shopping cart and sends the order
without any problems.
107
Task 4 TP1 notes that the warehouse where the order should have been
sent to is NULL, which the participant says, ”must be a mistake”. Furthermore the form of the track & trace system could be more clear.
The NULL value is an error in the system and it will be corrected. It occurred because the Track & trace system was not entirely finished. The form
of the track & trace system should also be improved so that it contains more
customer relevant information.
2. Questionnaire TP1 does not comment on the questionnaire.
Test transcript TP2
TP2 fills out the questionnaire without any questions.
Preliminary task: TP2 presses the link product catalog despite the fact
that TP2 is already in the product catalog
Since the front page of the web site is the product catalog this action is unnecessary. The simple solution to this action might be to make a headline in
the front page so an user can see that they are in the product catalog.
TP2 then browses through all the sub categories, reads the contents and
report 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 little
confused 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 logging
out. This might be a minor glitch in security, as other users might have
access to the prior users profile, if they use the same computer, and the first
user has not closed the browser. Therefore the website must have a log out
function, to make sure the user have this option.
Task 2 1: TP2 does not have any problems solving this task.
2: TP2 uses the back button which is included in “Internet explorer” and as
a result the web site does not show the participants last purchase. So the
participant goes back to the order form and re orders one more sound card,
without noticing the product counter on that particular product already is
108
set to one and subsequently purchases two.
This is clearly a problem which has to be corrected. The solution is not easy
because the feature is provided by the program not the web site. There are
multiple possibilities to solve this problem; one could be to force the site to
update. We chose to solve this by disabling the feature in “Internet explorer”.
Another possibility seen in some web shops is to make the previous page
expired, but we agree that that is an annoying solution to the problem and
therefore should be avoided.
Task 3 Remove item and send order goes with out any navigation problems
TP2 wonders: what about payment... But we do not want to go into that
part of the program because it is a whole system in it self. Besides it is not
allowed to make this part of the code, it has to be validated by PBS
Task 4 The form of the track and trace system is not as clear as TP2 would
like but other than that there is no problems.
This is the second time we encounter this problem and that is a problem. It
indicates that there is some redesigning to be done here to make the form
easier to understand for the user.
2. Questionnaire We decided to sort the comments in this Questionnaire
to make the analysis easier. The comments originally came in mixed order.
TP2 comments:
The page is too open and there is a lot of unused space. This is a big screen
and there is almost nothing on it, maybe it would look better on my own little screen. The page is a little boring and there could be some more pictures.
These statements have puzzled us a great deal. Our theories say that it is
a good thing. Furthermore the experience from web sites like Goggle shows
that a simple interface with limited amounts of text and commercials are very
popular. The following comment gives us the idea that TP2 is used to the
more confusing web sites and therefore thinks that something is missing on
our web site.
There is nothing to draw the attention away from what you are doing, there
could be some commercials maybe from this site, but those big ones that
moves is not good.
109
The first part of the statement sounds good and is backing up the theories,
but the following part of the comment, where TP2 requests commercials, is
against the theories. We therefore decided not to take this entirely serious
since it is only one of the test persons who mentions this.
The site is simple.... If I wanted to buy anything I would like some more
pictures and information about the things I could buy.
This should be taken very serious and it is of course extremely important to
describe the products to sell but since we have very limited time and we are
focusing on the usability of the web site this is not a high priority. We know
the pictures and text has to be there we just don’t have the time to write all
of it inn.
Good colors.... it looks professional. I like the way the color is varying over
the page. I really like the blue colors.
These comments indicate that colors we selected were colors in TP2’s taste.
We choose these colors based on the our color research in section B.8 colors
which apparently succeeded very well.
I like that the links is at the top because that is always the first place you
look. I think the page is very easy to understand.
This is indicating that the page actually is user friendly which is a good thing
for our validation test.
The pictures beside the categories are ugly and I 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 commercials, when you get that it will be better.
We believe that the amount of colors is appropriate and since we received
some positive comments about the coloring of the web site from TP2 this
comment is not weighted very high.
There is no log out button. I would like that some where around my user
name.
We will of course have to make one of those and putting it around the user
name is a good idea.
110
Test transcript TP3
TP3 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. As
mentioned previously we will only do a limited amount of work in this area.
There is no problems navigating the site.
Task 1 Fills out the personal info and by accident TP3 types space (“ ”)
after his postal code and therefore finds a major bug, because the database
cannot take in a text string in the postal code. TP3 gets help and then goes
on with the assignment and finishes the task without finding any other bugs
in the system.
This is a critical error which haves to be corrected. We have chosen to give
an output that displays what has been typed wrong. This we think is the best
way to alert the user.
Task 2 1) no problems at all 2) no problem at all TP3 goes the shortest
way to the individual products
when finished with the task TP3 says “that was painless”
We take this comment as a compliment to an user friendly design and at the
same time as a comment to the error in the previous task.
Task 3 TP3 removes the CPU without problems, and then TP3 accepts
the order no problem
Task 4 TP3 uses around 15 seconds before locating the “track & trace”
link in the top of the page. This is the first time any user have had problems
finding a specific link.
Despite this minor problem we won’t change the location of the links. Mainly
because TP1 didn’t have any problems and TP2 praised the location of the
link. It is the first time anyone have stalled on the page, which actually ruins
a very good statistic.
2. Questionnaire TP3 has a little problems understanding what is meant
by the words in the questionnaire, and was helped out by the test monitor.
We decided to sort the comments to this Questionnaire to make the analysis
111
easier to read. The comments originally came in mixed order.
TP3 comments:
There is too little info about the products.
Again, we know but we are in time shortage and the amount of information
about a product is not in the middle of our focus
TP3 would like a little more text to guide the navigation.
This could be a good idea, but we have to be careful not to insert too much
text. We have to note that TP3 is the first to have navigation problems on
the web site. More tests could maybe show that TP3 is outside the average
user group, or that TP1&2 is. Based on our test we have to say that TP1&2
is the average because they are the majority.
TP3 was a little unsure if it was his order under the track & trace.
We have to make it clear that it is only possible to see the current user’s
orders and again we should make the track & trace form more user friendly
by 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 it
to the shopping cart.
These comments are all pretty good and do not require us to make any
changes.
If I had been an user I would not have 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 remember at the time where the TM asks about it.
This indicates that he didn’t really notice that he had a problem locating the
link.
There are no pictures...
This is said in a way that makes it sound like they are missed, and with the
comment from TP2 about pictures and description of each product, we conclude that he wants that as well. As explained before, this is not our main
112
focus so what we are going to do about it will be limited.
All of the pictures beside the catalogs are almost the same, and I can’t see
what they are.
The pictures have been criticized before and will be changed.
12.2
Recommendations
After having analyzed the test result, it became clear that the system did
not entirely meet the participants demands. To make sure the system would
be able to handle the end-users demands, some changes to the system will be
necessary. We have to answer the following question, “Can an end user place
an order, without running into any problems?”. This is the same as asking
the question: Does the system live to the usability factor, usefulness?.
Our analyzes shows that only one of the test participants encountered a critical error and one non-critical error. TP2 had some problems solving task 1,
because TP1 had not logged out of the system. This resulted in some hesitation, but the participant recovered, and solved the problem with minimal
help from the test monitor. The critical error happened when TP3 entered
an invalid value into a text field, which returned an SQL exception.
These two errors however were the only time, any participants had problems
solving a task. And so to answer the question. No the system did not entirely
meet the users demands, and as a result cannot be said to meet the factor
usefulness. Therefore at the of the test, the system was not a Usability
system. To make sure the errors determined by the test were corrected the
following recommendations have been made.
• Task 2 showed that TP1 had problems with understanding the colors
used to indicate status. To make sure that this will not be a problem,
the colors should be something which is known to the users from their
everyday life. Red green and yellow, which is used at traffic lights could
be a solution. Furthermore they must be clearly visible, so they are
difficult to overlook
• TP2 demonstrated the need for a log out option was demonstrated
when the participant had to write the IP address of the site in order
to remove TP1 as the registered user
113
• Based on the comments TP2 made and by the answer made by 33% of
the participants to question 6 in table 12.1 under presentaion, the web
site should use more pictures and graphic. However the Jacob Nilsens
rule of how to design an user interface on the web is not to use grafics
just to decorate[9]. Therefore our recomendation is only to use grafics
to show the site contents
• More informaion about the products is something both TP2 and TP3
wants. When two participant agrees that they need more information
before buying a product, the recommendation must be to put more
information on the site
• TP1 thinks the pictures used to illustrate the categories are ugly and
TP3 also makes a comment about this. This is something that should
be changed as it might put a potential user off
• As TP3 commented, the track & trace function lacked information,
and it was not easy to understand. To ensure the end-user will not
misunderstand the information it should be presented in an easy to
read way as well as being easy to survey
We also wanted to find out the answer to the question: Does the systems
functions support the user in solving the task? This question concerns the
Usability factor usefulness. We wanted to measure if the functions on the
website could be used to solve user tasks. And we discovered that they could
to some extent. However TP3 had a serious problem when an error was
discovered in task 1. TP1 discovered the need for a log out function, and
finally TP1 noted that it was not possible to see which warehouse the order
was sent to. According to our test if these problems are solved the functions
on the web shop will be useful.
114
Part V
Academic requirements
115
Chapter 13
Academic requirements
This study report will be divided into three sections, where we will reflect
upon how the process went, and discuss the different phases. In section 13.1
we will look at how the four phases of the project the analysis,the design,
the implementation and the test In section 13.2, we will look at the projects
main focus , the user interface. in section 13.5 we will look at the tests we
made during the project. We also in section 13.1 discuss the databases and
server.
13.1
Analysis, design, implementation, and
test
In this section we will look at how the work process in each of the four phases
in the project went, and explain our choices and reflect upon them.
13.1.1
Analysis
In this phase of the project we spend a lot of time discussing on the steps
we should take in the project. We followed the SAD curse, did the exercises, which corresponded very good to what we had to do in order to make
our project. Every decision and task at this point were discussed in the
whole group and noted on the blackboards. We had some early problems
in deciding what system we should make. At first we decided to make an
ordinary warehouse management system to an online warehouse, but some
of the group members quickly came up with the idea that we should make
an online web portal listing computer hardware from different suppliers all
over Europe. And so we began planing for the development of the system.
116
One of our lecturer pointed out that it would be unwise to code such a system in Java, and there was some concern, that the system we had begun
to develop, did not contain enough classes to make a project in the scale
required by the study guidelines. We decided to go back to the original idea.
However, we liked the web part of the project, and decided to make a website
where a customer could browse around and place an order, which would be
sent to a warehouse for processing.
At this point we had lost a considerable amount of time, and began to work
hard in order to catch up. Each group member became responsible for a part
of the analysis. This of course meant that not all of the group members knew
what was going on in other part of the project. To ensure the project stayed
on course, everything made was controlled by at least a few other members
of the group
In retrospect, it would properly have been a good idea if we had stuck to
one idea. Because out of all this we had some trouble writing our system
definition in the right “academic” way and also so it would correspond to
the system we actually would make. We had a similar problem concerning
the class diagram, which went through considerable changes right up until
we began coding the system.
In the beginning it was very difficult for us to separate the problem and application domain this resulted in use cases that used functions instead of events.
Early in the process we also became too ambitious and began to design a
very large and complex system, which consisted of an administration part to
administrate statistics, employees, products and warehouses. Fortunately we
realized this would become to large for us to make in the time available, and
so we simplified it. In the end we decided that we wanted to make a home
page using JSP, that could be used to create customer and order objects
that would be stored in a database. The system would also be a warehouse
storage program that would be used to view orders and then process them.
We did this because we liked the challenge of making a system that would
use network and databases. We also wanted to concentrate on creating a
good user interface and believed we, by working with this idea would get the
opportunity.
13.1.2
Design
This section concerns the work process in the design as well as how the design
is connected with the analysis and the implementation.
117
We had some problems getting the design document done in time for the
second review. The two weeks between the first and second review was very
little time, and our work did became somewhat frantic as we worked to meet
the deadline. The material we delivered was a result of this, and not finished
at all. And due to this we continued working with the design for some time
after this. The final changes in the design document did come later as a
result of working with the implementation. We discovered there was something, which could be done differently, and we choose to add the changes to
the design document, to make it consistent to the program. We felt that
the things in the documentation should reflect the finished program, but it
must be pointed out that not everything in the design document has been
implemented.
In this phase the work process was both co-operation and individual work.
To ensure the work everybody did was adaptable with the rest of the project.
The while designing the database we found minor problems with the structure. We will explain the problems we had, and how we solved them, in
section 13.3.
Later in the design phase we noticed something strange in the OOA&D
method. In the application analysis the method deals with the user interface
but neither the architecture design nor the component design to follow up on
this work. This is somewhat puzzling because the work done in the analysis
seems to be wasted, unless you use another design method to create the user
interface. We decided to combine the OOA&D method with a method better
suited for graphical user interface design explained in the DEIB course.
13.2
User interface
In this section we will discuss the different problems we encountered as well
as our experiences and the decisions we made, involving the work with user
interfaces.
Warehouse and web shop GUI
The analysis made it clear that there was two kinds of requirements for the
system, so we had to design the GUI according to these. The warehouse GUI
had to be a professional tool, which should enable the user to quickly get the
118
task done, with a minimum of effort and concentration. The web shop GUI
had a different purpose, to sell products. We decided that a website designed
to e-commerce, should be visually interesting, but not be an interference in
solving the task, and not an annoyance.
we had early on some design suggestions to how the user interface should
look like. One of the members form the group made a sketch of how the user
interface could look like, on a computer using the paint program Photoshop.
The Sketch had so many details that the rest of the group desired to use i
as a reference point as to how the user interface approximately should look
like.
To that end we decide, based on the DEIB lectures, to set up some design
rules for the interface. Here are an explanation of how and why we choose
these rules.
Gestalt Laws
We decided to use the Gestalt laws of perceptual organization when we first
heard of them during a DEIB lecture. The reason why we wanted to work
with it, was that we would like the information on the user interface to be
understood by the end users without any misunderstandings. We meant the
Gestalt laws could be helpful in meeting this goal. We utilized the Gestalt
most heavily on the design of the web shop, because we chose to test this in
a usability test.
We had some difficulties finding appropriate literature which concerned the
subject, as the library did not have the books we looked for and the librarians looked baffled when we asked for books or articles concerning the Gestalt
laws. But in the end the library found a book we could use.
During the design we tried to keep the Gestalt principle in mind, which meant
that we tried to make related objects stand out and be identifiable as being
part of the same group.
A downside working with the Gestalt laws was that the five principles merge
with 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 regulations on the design in order to make an user oriented user interface. Therefore
using the Gestalt law of perceptual organization makes sense, as the Gestalt
119
laws set up rules to do just that.
Colors and text
In order to make an user interface, which helps getting information across
and support the systems purpose, sales system, we came up with an idea of
looking at how these two areas could be utilized. The idea came as a result
of a brainstorm, which came about because we wanted to focus more on the
user interface, and wanted to explore these two areas.
We decided to set up some design rules concerning use of colors and text.
These rules apply for the design of the warehouse GUI as well as the web shop
GUI. However, the use of colors where going to be used most prominently in
the web shop user interface. We estimated the use of colors could benefit the
sales environment and help set up the web shop as both a conservative and
reliable business, which would do little good in the warehouse GUI where
customer attraction means nothing.
The choice of which font type to use was based partly on the fact that we,
the designers, liked it and partly because of guidelines we found on the web.
During the test we did ask the participant to evaluate the colors on the site,
to make sure the web shop had colors which suited the websites purpose.
The result is shown in 12.1.
Frames
Another thing we did as part of the focus on the user interface of the system
was to work thoroughly with designing frames. as we meant we by focusing
on how the implemented interface should look like would be able to better
understand and visualize the user interface early on in the process. We believed we would get a tool which would be valuable in setting up how the
website should be designed.
All of us already had some experience working with frames, we had worked
with HTML before, and this had some influence in us choosing to work with
frames in the project.
We had some problems with frames, as the page location bar and the shopping cart did not update automatically. This problem had to be resolve by
120
making java scripts. We believe this should not be a problem, if the HTML
interface was made on one single page.
Wisdom
Because we focused on the GUI, we choose to use the wisdom method taught
to us in the DIEB lecture. The wisdom method was a tool when designing
user interfaces, it gave us a general course to take, from the use cases to
finding out what information the different screens should contain and which
functions they should handle. After this the only thing to do was to decide
how the actual GUI frames and windows should look. Because we did not
have a lot of time, we only did two essential use cases. Further more we were
told at the first review only to make on use cases, ass making more would
be to much work. The two use cases are however the most central ones in
the whole system. The use cases we choose were “Process order” and “Place
order”. Process order because this is the central use case for the employee
and therefore it must function properly, and Place order because it is very
central to the system that the user has no problems when placing an order.
We began making use case diagrams for the two. We had to make interaction
models, but we ran into some problems, as we had no idea how to actually
make them, and the examples we had from DEIB, consisted of a lot of useless
information. Some members missed a couple of work days trying to figure
out what to do, but after a meeting with a teacher we knew what we had to
do, and the process went fairly fast.
As we made the dialog models ran we into another problem with the “place
order” use case. We wanted to give the user of the system a lot of options, so
he/she can cancel what he/she does when he/she wants, and also have other
optional choices. However, the notation we used, does not fit particularly well
for this kind of use case and we are not sure if the dialog model is absolutely
correct. Out of these diagrams we made interaction space models on which
we based the design of the GUI. We could not do this for the whole system
so we had to go with what we felt was right, and by using our Design rules.
13.3
Database design
At the very start of the project we decided to store our data in some kind of
a SQL database. The reason we used MySQL database, was because some
of the group members knew it from personal web development projects.
121
When designing the database we had some problems with circularizes in our
design, which we could not work around. We were afraid there would be
problems inserting data, but we found out that because our entities are not
mutually depending of one another, and the tests we made did not show any
errors, the database system could be used. We know that the database is
not designed perfectly, however database design and persistence is not part
of our focus area.
As we implemented the database, we created and dropped both databases
and a lot of tables, as we designed and redesigned. During so, we learnt
that the MySQL syntax and SQL are definitely not the same thing. Not
all SQL commands works in MySQL. It may have been the MySQL version
4.1.7 we used, but many commands, which should have worked, did not. As
an example the ALTER query did not work as expected. We could not use
the alter command to change foreign or primary key, but it did work when
used with any other attributes.
We discovered that any changes made in the design which involved foreign
keys, would result in us dropping one or more tables. The reason we decided
to implement the database while still working on the design was that we
could see if our design actually worked or not.
To make sure our database could handle a situation where data was deleted
or updated the ON DELETE CASCADE and ON UPDATE CASADE, commands were used. This was done to make sure that if data was updated or
deleted in one table, data in other tables with a foreign key to the first table
would be either updated or deleted.
The ER-diagram at figure 8 shows that the delivery details, represented as
attributes starting with “delivery”, were not existing in the early design of
the database.
13.4
Implementation
Our implementation phase started out pretty well and we got our model
classes and a basic warehouse client GUI made fast. We decided to divide
the implementation out between the members of the group, so some worked
with the database, some with the warehouse server, and others with the
clients. Minor problems occurred with that but the problem that kept re122
turning all the way through the implementation phase were design changes
and errors. A lot of time were used to “fix” minor changes, that sometimes
grew into bigger problems.
The decision about using RMI for our network functionality proved to be an
good idea since it was very easy to implement into our system. More advanced functions like a callback between the clients were left out though, since
we did not have any courses in distributed programming, and not enough time
to study it further.
The web shop were made with JSP and acts like a client on the warehouse
server, sharing methods with the ’warehouse client’. We had some problems
setting up the servers to run JSP and a RMI and we ended up with using
java version 1.5 instead of the advised version 1.4.
Sadly the system became really hard to install on every platform we tried it
on, The user need a web server, a jsp server, and registries for the RMI and
java installed and setup and that is not easy for most people to do.
13.5
Test
Usability test
We decided to use Jeffrey Rubins book [13], as a guide to making the usability test. To do so we decided we wanted to make profiles of the participants,
and therefore made a background questionnaire. The qustionnarie should
provide us with information about whether the participants had prior exsperience with a web shop. the demografically
At the day of the test, we had invited the first test participants to come at
around 14.00 and the next participant to come half an hour later and so on.
We just had enough time, in the test lab, to make a pilot test in order to
make sure no major mistakes would occur.
The test went rather smoothly, but we did encounter a few glitches along
the way. TP3 encountered an SQL error, which he could mot recover from
without outside help. The test monitor which could not see the server, also
had to be helped in order to get on with the test. The interference did not
seem to ruined anybodys consentration and the rest of the rest of the test
123
went as it should.
To avoid the test participants were to nervous, we showed them what was
on the other side of the one side mirror. We did this to make them more
confidence about the whole situation.
The group had an positive experience with the test. The one who had not
tried conducting a test before, could see . The data which we got from the
test was immense and gave us a good understanding of the things in the
system which should be change and which worked as intended. On the down
side we may have found more usability errors if we had tested more people,
but we decided that we did not have time to analyze more data. We made
the decision that some of us would be responsible of analyzing the data, and
make a recommendation based on the test.
124
Part VI
Conclusion
125
Chapter 14
Project conclusion
In this project we gained knowledge and experience of both application design and application implementation. Furthermore we obtained experience
in testing a system.
In order to develop a system that fits the requirements from the warehouse
employees and the website customers, it is important to include them in the
development process. As we were self employed in this project we had to
construct the foundation of the project our selves. Our only external experience where with the three test persons, who we got great response from,
they pointed out quite a few relevant things to correct and improve in the
system. We would continue to use test persons if we were to implement the
rest of the system because a potential user spot the most inadequacy in a
system.
We tried to organize ourselves as a professional development team, to maximize the project’s outcome. But quickly found out that it was a greater
challenge than expected.
We used the OOAD method in the development process. The method were
good for the analysis and for most of the design phase, but when we came
to the design of our interfaces it became inadequate. We started using a
method from the DIEB course, which were more appropriate for designing
user interfaces.
Just before starting on the implementation phase, decisions were made on
what was realistic implementing in the amount of time we had left. The work
assignments the secretary, login and logout on the warehouse client, the signaling from the server to the warehouse when orders are placed were removed.
126
The implementation of the designed system went good. We got the web shop
almost fully implementated and a functional warehouse client, capability of
handling orders. The warehouse administration area, payment system and
an e-mail notification were left out for future implementation. This was done
to save time, and stay on focus with the user interfaces. The algorithm used
by the web shop to select a warehouse automaticly could have been made
more advanced, but again that was not in our focus area.
Our database design works and fulfils our systems needs, but yet not perfect.
Since the database design courses are placed in later semesters we decided
only to use a reasonably amount of time to look into database design and go
from there.
At last we can conclude that the system has reached the goals for this
semester and the goals elaborated and prioritized in the analysis and design document.
127
Part VII
Appendix
128
Appendix A
Code test
Throughout the implementation of the system a lot of tests were made. To
ease the testing a tool called JUnit1 were used.
The test method used is a bottom-up testing, starting with the primitive
methods moving towards the main functionality.
A.1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Class tests
import j a v a . u t i l . Date ;
import j u n i t . framework . TestCase ;
import c l a s s e s . ∗ ;
import j a v a . u t i l . Date ;
/∗ ∗
∗ @author d105a
∗
∗ T e s t s e t u p f o r t h e model c l a s s e s
∗
∗/
public c l a s s U n i tT es t extends TestCase {
private Employee t e s t P e r s o n ;
private Category t e s t C a t e g o r y ;
private Customer tes tC u s to m er ;
private Order t e s t O r d e r ;
private Product t e s t P r o d u c t ;
private Warehouse tes tWa r eh o u s e ;
private f l o a t p r i c e = 3 3 4 ;
protected void setUp ( ) {
t e s t P e r s o n = new Employee ( 2 , ”name” ) ;
t e s t C a t e g o r y = new Category ( 1 , ” a s u s ” , ” motherboard ” , ” p i c t u r e ” ) ;
tes tC u s to m er = new Customer ( 1 , ” u s e r ” , ” p a s s ” , ”name” , ” a d d r e s s ” ,
9 0 0 0 , ” a a l b o r g ” , ” denmark ” , ” 9945 ” , ” e m a i l ” ) ;
1
http://www.junit.org
129
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
t e s t O r d e r = new Order ( 1 2 , ” s t a t u s ” , 3 4 , 1 2 , 1 ,new Date ( ) ,new Date ( )
, ” track ”) ;
t e s t P r o d u c t = new Product ( 3 2 , 1 , ”name” , ” vendor ” , ” model ” , p r i c e , ”
d e s c r i p t i o n ” , ” p i c t u r e ” , 3 4 5 , true ) ;
tes tWa r eh o u s e = new Warehouse ( 1 2 , ”name” , ” a d d r e s s ” , 3 4 , ” c i t y ” , ”
co u n tr y ” , ” e m a i l ” ) ;
}
protected void tearDown ( ) {
tes tP er s on = null ;
tes tC ategor y = null ;
tes tC u s to m er = n u l l ;
tes tO r der = null ;
tes tP r oduct = null ;
tes tWa r eh o u s e = n u l l ;
}
/∗ ∗
∗ testCase1 ()
∗ Employee c l a s s
∗ ∗/
public void t e s t C a s e 1 ( ) {
a s s e r t E q u a l s ( 2 , t e s t P e r s o n . getEmployeeID ( ) ) ;
a s s e r t E q u a l s ( ” p o u l ” , t e s t P e r s o n . getName ( ) ) ;
}
/∗ ∗
∗ testCase2 ()
∗ C at e g or y c l a s s
∗ ∗/
public void t e s t C a s e 2 ( ) {
a s s e r t E q u a l s ( 1 , t e s t C a t e g o r y . g etC a teg o r y ID ( ) ) ;
a s s e r t E q u a l s ( ” a s u s ” , t e s t C a t e g o r y . getName ( ) ) ;
a s s e r t E q u a l s ( ” motherboard ” , t e s t C a t e g o r y . g e t D e s c r i p t i o n ( ) ) ;
assertEquals (” picture ” , testCategory . getPicture () ) ;
}
/∗ ∗
∗ testCase3 ()
∗ Customer c l a s s
∗ ∗/
public void t e s t c a s e 3 ( ) {
a s s e r t E q u a l s ( 1 , tes tC u s to m er . getCustomerID ( ) ) ;
a s s e r t E q u a l s ( ” u s e r ” , tes tC u s to m er . getUserName ( ) ) ;
a s s e r t E q u a l s ( ” p a s s ” , tes tC u s to m er . getPassWord ( ) ) ;
a s s e r t E q u a l s ( ”name” , tes tC u s to m er . getName ( ) ) ;
a s s e r t E q u a l s ( ” a d d r e s s ” , tes tC u s to m er . g e t A d d r e s s ( ) ) ;
a s s e r t E q u a l s ( 9 0 0 0 , tes tC u s to m er . g e t P o s t a l C o d e ( ) ) ;
a s s e r t E q u a l s ( ” a a l b o r g ” , tes tC u s to m er . g e t C i t y ( ) ) ;
a s s e r t E q u a l s ( ” 9945 ” , tes tC u s to m er . getPhone ( ) ) ;
a s s e r t E q u a l s ( ” e m a i l ” , tes tC u s to m er . g etE m a i l ( ) ) ;
}
/∗ ∗
∗ testcase4 ()
∗ Order c l a s s
∗ ∗/
public void t e s t c a s e 4 ( ) {
a s s e r t E q u a l s ( 1 2 , t e s t O r d e r . getOrderID ( ) ) ;
assertEquals (” status ” , testOrder . getStatus () ) ;
a s s e r t E q u a l s ( 3 4 , t e s t O r d e r . getCustomerID ( ) ) ;
a s s e r t E q u a l s ( 1 2 , t e s t O r d e r . getWarehouseID ( ) ) ;
a s s e r t E q u a l s ( 1 , t e s t O r d e r . getEmployeeID ( ) ) ;
a s s e r t E q u a l s (new Date ( ) , t e s t O r d e r . g e t C r e a t i o n D a t e ( ) ) ;
a s s e r t E q u a l s (new Date ( ) , t e s t O r d e r . g e t S h i p p i n g D a t e ( ) ) ;
130
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
}
/∗ ∗
∗ testcase5 ()
∗ Product c l a s s
∗ ∗/
// g e t P r i c e method i n t h e p r o d u c t c l a s s n ot t e s t e d due t o
complications t e s t i ng f l o a t values
public void t e s t c a s e 5 ( ) {
a s s e r t E q u a l s ( 3 2 , t e s t P r o d u c t . g etP r o d u ctID ( ) ) ;
a s s e r t E q u a l s ( 1 , t e s t P r o d u c t . g etP r o d u ctID ( ) ) ;
a s s e r t E q u a l s ( ”name” , t e s t P r o d u c t . getName ( ) ) ;
a s s e r t E q u a l s ( ” model ” , t e s t P r o d u c t . getModel ( ) ) ;
assertEquals ( ” des cr i pti on ” , testProduct . getDescription () ) ;
assertEquals ( ” picture ” , testProduct . getPicture () ) ;
as s er tE qual s (345 , testProduct . getQuantity () ) ;
a s s e r t E q u a l s ( true , t e s t P r o d u c t . g e t I s P r o c e s s e d ( ) ) ;
}
/∗ ∗
∗ testcase6 ()
∗ Warehouse c l a s s
∗ ∗/
public void t e s t c a s e 6 ( ) {
a s s e r t E q u a l s ( 1 2 , tes tWa r eh o u s e . getWarehouseID ( ) ) ;
a s s e r t E q u a l s ( ”name” , tes tWa r eh o u s e . getName ( ) ) ;
a s s e r t E q u a l s ( ” a d d r e s s ” , tes tWa r eh o u s e . g e t A d d r e s s ( ) ) ;
a s s e r t E q u a l s ( 3 4 , tes tWa r eh o u s e . g e t P o s t a l C o d e ( ) ) ;
a s s e r t E q u a l s ( ” c i t y ” , tes tWa r eh o u s e . g e t C i t y ( ) ) ;
a s s e r t E q u a l s ( ” co u n tr y ” , tes tWa r eh o u s e . g etC o u n tr y ( ) ) ;
a s s e r t E q u a l s ( ” e m a i l ” , tes tWa r eh o u s e . g etE m a i l ( ) ) ;
}
}
A.2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Functionality tests
import
import
import
import
j u n i t . framework . TestCase ;
classes .∗;
java . u t i l . ArrayList ;
j a v a . u t i l . C a l en d a r ;
/∗ ∗
∗ @author d105a
∗
∗ getOrders f u n c t i o n t e s t
∗/
public c l a s s F u n cti o n T es t extends TestCase {
private s t a t i c O b j ect [ ] [ ]
orders ;
private A r r a y L i s t o r d e r L i s t ;
private Order tmpOrder ;
131
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
private i n t WAREHOUSE ID = 1 ;
protected void setUp ( ) {
RMIConnection rmic = new RMIConnection ( ) ;
try {
o r d e r L i s t = RMIConnection . d1 . g etO r d er ( Mainprogram .
WAREHOUSE ID) ;
} catch ( E x cep ti o n e ) {
}
;
}
protected void tearDown ( ) {
}
public void t e s t C a s e 1 ( ) {
assertEquals (9 , orderList . s i z e () ) ;
}
public void t e s t C a s e 2 ( ) {
tmpOrder = ( Order ) o r d e r L i s t . g e t ( 6 ) ;
a s s e r t E q u a l s ( ” Pending ” , tmpOrder . g e t S t a t u s ( ) ) ;
a s s e r t E q u a l s ( 1 2 , tmpOrder . getOrderID ( ) ) ;
C a l en d a r tmpc = C a l en d a r . g e t I n s t a n c e ( ) ;
tmpc . s e t ( 2 0 0 4 , C a l en d a r .DECEMBER, 1 5 ) ;
a s s e r t E q u a l s ( tmpc . getTime ( ) , tmpOrder . g e t C r e a t i o n D a t e ( ) ) ;
}
}
132
Appendix B
Test plan
B.1
Problem statement/test objectives
The goal of the test is to find possible flaws in the design which prevents a
smooth and problem free usage of the application. To accomplish this the
problems in focus in this test are:
• Can an end user place an order, without running into any problems?
• Will the system take up to much of the users’ time?
• Does the systems functions support the user?
B.2
User profile
The test involved three participants, at the research lab 1. at Aalborg university. All of the participants were tested on December 6, 2004. The participants were chosen based on their background, as shown in table B.1.
B.3
Methodology
The test will consist of a validation test, as well as two questionnaires. [13]
The first is a background questionnaire, which gather information about the
test persons. The other concerning the participants final evaluation of the
system.
133
Characteristic
Range
Frequency distribution
Age
18-21
33% below 20 years
Sex
Male/Female
67 % male
Education/work
Students
100%
Computer
experience
based on time used each
week
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 information concerning the test and the participants part in the test. The test
monitor will insure the participant complete anonymity and that the test
and the result only will be used in this project. Moreover, the participant
will be informed that the test sessions will be recorded, and observed by the
rest of the project group through a spy-mirror. The test monitor will ensure the participant that there is no right solution to the task, and that the
participant is not being tested and should take whatever time needed.
B.3.2
Validation test
The participant will be asked to carry out a number of tasks, which will
imitate how the end-user is going to utilize the system[13]. The test monitor
will set up a scenario, which must look like a scene which the test participant
can identify with. The participants, are asked to imagine being at home or
where he/she usually buys products online. The participant is handed a note
with a task on it, and is asked to solve it. The test will be observed, the
observers will note any difficulties and errors encountered. The test monitor
will 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 computer screen will be turned off and the debriefing will be carried out with the
participant 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 about
the system
When the test is finished, the test monitor thanks the participant for being
part of the test.
B.4
Task list
Preliminary task: Browse through some of web pages to get some familiarity
with the web site and end the task by returning to the start page.
The task imitates a situation where the user encounters the web site for the
first time. This task is fairly easy to accomplish, and is meant to make the
participant more at ease, and less nervous about the situation.
Task 1: register yourself as a customer and log on the system.
This assignment is testing the difficulty level of registering on the web page.
If this part is presenting any problems it will be a major problem, because
if 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 that
is done often.
Task 2:
• Find a SoundBlaster sound card in the catalog and add it to the shopping cart
• Find the cheapest Pentium 4 CPU and add it to the shopping cart
The assignment is representing a realistic purchase online, which is the primary purpose of the web site. It should identify any problems the participant
may have finding a specific piece of hardware on the web site.
Task 3: Remove the Pentium 4 CPU from the shopping cart and send the
order
After choosing a product, a customer may reconsider, and should therefore
be able to remove that product from the shopping cart. The task should
show if the customer has any 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 right
warehouse, or just make sure it has been received.
135
B.5
Test environment
The execution of the test is conducted in an electronic observation room
setup. The test monitor and test participants were both in the test room,
while the observers and technicians, all of which where members of the project
group were behind a two-way mirror in the observation room and the technician room. The lighting of the room is going to emulate a typical office, and
must be bright enough to allow the cameras to capture the test participant’s
facial expression during the test. The furniture’s in the test room is not
placed according to any particular order, as we decided to use the existing
office environment setup in the test room, with desks chairs and a PC. Items
needed for the test.
• A PC: Which the participant will use to browse the systems user interface
• A pen: To fill out the questionnaires
The implemented system must be able to accomplish all the functionality required by the tasks as well as the finished graphical interface design. The test
participant is expected to evaluate the graphical interface and test whether
or not the functions are usable.
B.6
Test monitor role
The primary function of the test monitor is to ensure that the test is running
smoothly. First he will read an orientation script for the test participant and
make sure that there are no questions. Then he hands the participant the
background questionnaire. At the usability test the test monitor will give the
participant the assignments. The assignments are handed over one at a time,
so the participant only works on one task at the time. The secondary work
assignment for the test monitor is to keep the participant calm and help if
the participant gets stuck.
B.7
Evaluation measures
We will measure the number of participants who solves the tasks and furthermore measure any errors or where they have difficulty in solving the task.
The errors are classified according to the list below[13].
136
• Comments and observations - test monitor and observers note when
the participants have difficulty solving a problem. Which is manifested
by either a participant is going back and forth through the web sites
or if he pause for more than 15 seconds or express some doubt
• Noncritical error. The participant makes an error but is able to recover
• Critical error, the participant makes an error and as a result cannot
finish the task
B.8
Colors
The choice of colors in a GUI should be inviting and appealing toward the
user. According to Ben Scneiderman color speeds recognition when dealing
with several tasks and functionality [14]. He also implies that colors should
be conservatively used and limited to a few otherwise it might confuse the
viewer. Furthermore the choice of colors may have an embedded meaning
which differ on cultural background, for example red means hot, blue means
cold, black means death and white means birth but on the other hand in
Japan and India white and black has the opposite meaning white meaning
death and black meaning birth[4]. Today on the World Wide Web colors
have obtained a general accepted meaning, blue text for example means a
link and purple text means a visited link. It is also recommended to use
these general standards, as the user otherwise might get confused, especially
if you were to switch the use of blue and purple link color.
Color symbolism
Color meanings has a general cultural understanding among the population
because of our general perception taught through media, so without knowing
it everyone has some degree of understanding. Below we have accumulated
some examples of what general colors symbolize[5].
Blue Sky, Sea, Water, Religious feeling, Peace, Faith, Stability, Melancholy, Trust, Loyalty, Wisdom, Tranquility, Integrity.
Red Fire, Love, Passion, Energy, Revolution, Anger, Power, Debt, Danger,
Heat, Warning.
137
Green Money, Growth, Environmentally friendly, Fertility, Envy, Spring,
Freshness, Stability, Loyal, Healing.
Yellow Energy, Sun, Happiness, Cheery, Creativity.
Orange Joy, Sunshine, Creativity, Determination, Success, Encouragement,
Energy, Autumn, Construction.
Purple Royalty, Power, Nobility, Luxury, Spirituality.
Brown Conservative, Stable, Outdoors, Fall, Earth, Organic.
Grey Uncertainty, neutral, between light and dark, time to make choices.
B.9
Frames
To make a consistent website we have briefly analyzed the way frames are
used throughout the World Wide Web. We will here briefly describe how we
use frames in our design.
Figure B.1: Frames description
The top frame usually consist of a logo/slogan, navigation is recently consistently being adapted into the top frame, contrary to placing the navigation
in the left frame.
The reason for placing the navigation in the top frame is because a left side
menu takes up a lot of space and the possibility of creating nice dropdown
138
menus has through the last few years been available without lacking usability.
Left side is most commonly used as navigation link space, and advertising
banners is often placed below such navigation link space. The main content
area is placed in the middle of the page; it can contain large amounts of data
contrary to boundary frames. Right frame is usually used for search link and
advertising. Bottom frame is sometimes used for shopping cart but is most
commonly not used at all.
B.10
Font types
Fonts are divided into four main categories text fonts, display fonts, decorative fonts and specialty fonts. We only need to look at text fonts because
display fonts, decorative fonts and specialty fonts is commonly not supported
on all systems, these fonts are therefore irrelevant, although we can mention
that these fonts are used in word processors and computer-assisted drawing
programs, for more personal text graphics.
Text fonts can be divided into two subcategories serif and sans-serif fonts.
Serif text fonts are used for long passages of text, serifed type is also thought
to be easier on the eyes. Examples of serif text font family are Times New
Roman, Georgia and Garamond.
Figure B.2: Serif fonts
The thing serif fonts have in common is a high degree of readability, which
is why serif fonts is commonly used in books, magazines and newspapers.
Examples of sans-serif text font family are Arial and Verdana.
Figure B.3: Sans-serif fonts
139
Sans-serif fonts are especially used on websites because it is readable even in
small sizes which make it compatible with low pixel resolutions. Serif fonts
like Times New Roman are not very legible in small point sizes because the
serifs make the letters look broken. Sans-serif fonts is legible in a way that
makes it quick and easy for an user to get an overview of even great amounts
of information. This means sans-serif fonts is a good choice especially for
navigation menu’s. Other features like italic, bold and underline styles can
be added to fonts to emphasize meanings of the text, it is not recommended
to use italic style on web applications[4].
B.11
Gestalt laws
The visual perception is important in a user interface. This is because the
way the user interface is organized has an influence on the way the user
understands the systems information. According to Jenny Preece[12], the
gestalt laws of perceptual organization can be an effective tool when making
a comprehensive design. We have chosen to use the gestalt laws of perceptual
organization in this project. Therefore the design of the user interface will
support the information by utilizing the Gestalt laws. It should be noted
that the Gestalt laws are not empirically proved, but according to slide 4.23
from the DEIB course[16], it is still a good help when designing.
The Gestalt law of perceptual organization is split into five principles, proximity, similarity, closure, continuity and symmetry[12]. We have chosen to
employ these principles, hereby we get a tool which will help us communicate
the website information to the user without any interferences. When talking
about objects in the following, it will include every element like pictures, text
and so on in the user interface.
• Proximity: States that objects close to one another is perceived as one
unit. As such this principle will be used to group information together
and make the user conceive the objects as being related
• Similarity: Objects of similar shape is often perceived as belonging
together. Some pictures and thumpnails, which will be used on the
website, will be seen as a group because of their similarity
• Closure: An incomplete figure is perceived as the complete object,
the viewer will put in the missing parts themselves to complete the
figure. The design will use this principle, heavily by enclosing related
140
information, to make sure the information is conceived as belonging
together
• Continuity: Is a number of objects organized in such a manner that
it makes them appear belonging to the same pattern, instead of being
seen as individual objects. We will follow this principle, and placing
objects near one another so the user will conceived them as united
• Symmetry: Placing objects symmetric in the user interface is perceived
by the viewer as a border creating a figure. We will not consciously
follow this principle, but cannot reject that it is somewhere used
As a final note Carlos Pedroza state that the Gestalt grouping laws should
not be seen independently, as it influences one another [10]. The result is
that perception is a combination of all of the principles. This means the user
interface in this project is a combination of all the principles.
B.12
Dialogue style in user interfaces
There exist different interaction styles, below we briefly describe the most
common used. [14]
Command language
Command language is a direct way of manipulating with a system, examples
of this could be command prompt of windows or linux. The advantages is its
flexibility and capability, it is also potentially rapid for complex tasks. The
disadvantages is that it requires substantial training and memorization, it is
difficult to retain and has a poor error handling.
Menu selection
Menu selection is used in GUIs when you want a list of items or links the user
can select. The advantages of menu selection is that it reduces key strokes,
higher level of recognition, accurate and structures decision making. Some
disadvantages can be that it requires screen space and it is sometimes difficult to find appropriate terminology and the complexity of several menus
can be overwhelming for the user.
Direct manipulation
Visual representation of objects and actions, using pointing, zooming and
panning the user can rapidly perform operations in GUIs. The advantages
is that it visually presents the task it is easy to learn and retain encourages
141
exploration and has a high subjective satisfaction and errors can be avoided.
The disadvantages is that it requires a graphic display and pointing device,
it needs more programming effort.
Form fill-in
Form fill-in is used in GUIs when the user needs to provide data, labelled
fields 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 the
user only need modest training. The disadvantages could be that it consumes
screen space.
Natural language
When users interact through their natural language in a system. The advantages is that it relieves burden of learning syntax. The disadvantages is that
it requires more keystrokes it is rather unpredictable and therefore requires
a 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 are
listed below. We list the tables in order of dependency, e.g. categories before
productDetails.
customers
CREATE TABLE customers (customerID INT AUTO_INCREMENT, username VARCHAR(20) NOT NULL,
password VARCHAR(32) NOT NULL, name VARCHAR(60) NOT NULL, address VARCHAR(50) NOT NULL,
postalCode INT NOT NULL, city VARCHAR(30) NOT NULL, country VARCHAR(30) NOT NULL, phone
VARCHAR(14), email VARCHAR(60) NOT NULL, PRIMARY KEY (customerID));
+------------+-------------+------+-----+---------+----------------+
| Field
| Type
| Null | Key | Default | Extra
|
+------------+-------------+------+-----+---------+----------------+
| customerID | int(11)
|
| PRI | NULL
| auto_increment |
| username
| varchar(20) |
|
|
|
|
| password
| varchar(20) |
|
|
|
|
| name
| varchar(60) |
|
|
|
|
| address
| varchar(50) |
|
|
|
|
| postalCode | int(11)
|
|
| 0
|
|
| city
| varchar(30) |
|
|
|
|
| country
| varchar(30) |
|
|
|
|
| phone
| varchar(14) | YES |
| NULL
|
|
143
| email
| varchar(60) |
|
|
|
|
+------------+-------------+------+-----+---------+----------------+
10 rows in set
employees
CREATE TABLE employees (employeeID INT AUTO_INCREMENT, name VARCHAR(60) NOT NULL, PRIMARY
KEY (employeeID));
+------------+-------------+------+-----+---------+----------------+
| Field
| Type
| Null | Key | Default | Extra
|
+------------+-------------+------+-----+---------+----------------+
| employeeID | int(11)
|
| PRI | NULL
| auto_increment |
| name
| varchar(60) |
|
|
|
|
+------------+-------------+------+-----+---------+----------------+
2 rows in set
categories
CREATE TABLE categories (categoryID INT AUTO_INCREMENT, name VARCHAR(60) NOT NULL,
description TEXT, picture VARCHAR(60), PRIMARY KEY (categoryID));
+-------------+-------------+------+-----+---------+----------------+
| Field
| Type
| Null | Key | Default | Extra
|
+-------------+-------------+------+-----+---------+----------------+
| categoryID | int(11)
|
| PRI | NULL
| auto_increment |
| name
| varchar(60) |
|
|
|
|
| description | text
| YES |
| NULL
|
|
| picture
| varchar(60) | YES |
| NULL
|
|
+-------------+-------------+------+-----+---------+----------------+
4 rows in set
warehouses
CREATE TABLE warehouses (warehouseID INT AUTO_INCREMENT, name VARCHAR(60) NOT NULL,
address VARCHAR(50) NOT NULL, postalCode INT NOT NULL, city VARCHAR(30) NOT NULL, country
VARCHAR(30) NOT NULL, email VARCHAR(60), PRIMARY KEY (warehouseID));
+-------------+-------------+------+-----+---------+----------------+
| Field
| Type
| Null | Key | Default | Extra
|
+-------------+-------------+------+-----+---------+----------------+
| warehouseID | int(11)
|
| PRI | NULL
| auto_increment |
| name
| varchar(60) |
|
|
|
|
| address
| varchar(50) |
|
|
|
|
| postalCode | int(11)
|
|
| 0
|
|
| city
| varchar(30) |
|
|
|
|
| country
| varchar(30) |
|
|
|
|
| email
| varchar(60) | YES |
| NULL
|
|
+-------------+-------------+------+-----+---------+----------------+
7 rows in set
144
orders
CREATE TABLE orders (orderID INT AUTO_INCREMENT, status ENUM(’Pending’,
’Being processed’,’Shipped’) NOT NULL DEFAULT ’Pending’, customerID INT NOT NULL,
warehouseID INT NOT NULL, employeeID INT, deliveryName VARCHAR(60), deliveryAtt
VARCHAR(60), deliveryAddress VARCHAR(50), deliveryPostalCode INT, deliveryCity
VARCHAR(30), deliveryCountry VARCHAR(30), creationDate DATE NOT NULL, shippingDate DATE,
trackAndTraceNumber VARCHAR(30), PRIMARY KEY (orderID), FOREIGN KEY (customerID)
REFERENCES customers (customerID) ON UPDATE CASCADE, FOREIGN KEY (warehouseID) REFERENCES
warehouses (warehouseID) ON UPDATE CASCADE, FOREIGN KEY (employeeID) REFERENCES employees
(employeeID) ON UPDATE CASCADE);
+---------------------+--------------------+------+-----+------------+----------------+
| Field
| Type
| Null | Key | Default
| Extra
|
+---------------------+--------------------+------+-----+------------+----------------+
| orderID
| int(11)
|
| PRI | NULL
| auto_increment |
| status
| enum(’Pending’,
|
|
| Pending
|
|
|
| ’Being processed’, |
|
|
|
|
|
| ’Shipped’)
|
|
|
|
|
| customerID
| int(11)
|
| MUL | 0
|
|
| warehouseID
| int(11)
|
| MUL | 0
|
|
| employeeID
| int(11)
| YES | MUL | NULL
|
|
| deliveryName
| varchar(60)
| YES |
| NULL
|
|
| deliveryAtt
| varchar(60)
| YES |
| NULL
|
|
| deliveryAddress
| varchar(50)
| YES |
| NULL
|
|
| deliveryPostalCode | int
| YES |
| NULL
|
|
| deliveryCity
| varchar(30)
| YES |
| NULL
|
|
| deliveryCountry
| varchar(30)
| YES |
| NULL
|
|
| creationDate
| date
|
|
| 0000-00-00 |
|
| shippingDate
| date
| YES |
| NULL
|
|
| trackAndTraceNumber | varchar(30)
| YES |
| NULL
|
|
+---------------------+--------------------+------+-----+------------+----------------+
14 rows in set
productDetails
CREATE TABLE productDetails (productID INT AUTO_INCREMENT, categoryID INT NOT NULL, name
VARCHAR(60) NOT NULL, vendor VARCHAR(60) NOT NULL, model VARCHAR(30) NOT NULL, price
FLOAT NOT NULL, description TEXT, picture VARCHAR(60), PRIMARY KEY (productID), FOREIGN
KEY (categoryID) REFERENCES categories (categoryID) ON DELETE CASCADE ON UPDATE CASCADE);
+-------------+-------------+------+-----+---------+----------------+
| Field
| Type
| Null | Key | Default | Extra
|
+-------------+-------------+------+-----+---------+----------------+
| productID
| int(11)
|
| PRI | NULL
| auto_increment |
| categoryID | int(11)
|
| MUL | 0
|
|
| name
| varchar(60) |
|
|
|
|
| vendor
| varchar(60) |
|
|
|
|
| model
| varchar(30) |
|
|
|
|
| price
| float
|
|
| 0
|
|
| description | text
| YES |
| NULL
|
|
| picture
| varchar(60) | YES |
| NULL
|
|
+-------------+-------------+------+-----+---------+----------------+
8 rows in set
145
stockStatus
CREATE TABLE stockStatus (stockStatusID INT AUTO_INCREMENT, productID INT NOT NULL,
warehouseID INT NOT NULL, quantity INT NOT NULL, PRIMARY KEY (stockStatusID), FOREIGN KEY
(productID) REFERENCES productDetails (productID) ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (warehouseID) REFERENCES warehouses (warehouseID) ON DELETE CASCADE ON UPDATE
CASCADE);
+---------------+---------+------+-----+---------+----------------+
| Field
| Type
| Null | Key | Default | Extra
|
+---------------+---------+------+-----+---------+----------------+
| stockStatusID | int(11) |
| PRI | NULL
| auto_increment |
| productID
| int(11) |
| MUL | 0
|
|
| warehouseID
| int(11) |
| MUL | 0
|
|
| quantity
| int(11) |
|
| 0
|
|
+---------------+---------+------+-----+---------+----------------+
4 rows in set
orderDetails
CREATE TABLE orderDetails (orderDetailsID INT AUTO_INCREMENT, orderID INT NOT NULL,
productID INT NOT NULL, warehouseID INT NOT NULL, quantity INT NOT NULL, processed BOOL
NOT NULL DEFAULT 0, PRIMARY KEY (orderDetailsID), FOREIGN KEY (orderID) REFERENCES orders
(orderID) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY (productID) REFERENCES
productDetails (productID) ON UPDATE CASCADE, FOREIGN KEY (warehouseID) REFERENCES
warehouses (warehouseID) ON UPDATE CASCADE);
+----------------+------------+------+-----+---------+----------------+
| Field
| Type
| Null | Key | Default | Extra
|
+----------------+------------+------+-----+---------+----------------+
| orderDetailsID | int(11)
|
| PRI | NULL
| auto_increment |
| orderID
| int(11)
|
| MUL | 0
|
|
| productID
| int(11)
|
| MUL | 0
|
|
| warehouseID
| int(11)
|
| MUL | 0
|
|
| quantity
| int(11)
|
|
| 0
|
|
| processed
| tinyint(1) |
|
| 0
|
|
+----------------+------------+------+-----+---------+----------------+
6 rows in set
146
Bibliography
[1] MySQL
AB.
MySQL
Reference
Manual,
http://mirrors.sunsite.dk/mysql/Downloads/Manual/manual-a4.pdf.
[2] Wellhouse consultants.
wellho.net:
Computing Training,
http://www.wellho.net/forum/The-Java-Programminglanguage/Apache-Jakarta-Tomcat-Catalina-Coyote-Jasper.html.
[3] Alan J. Dix, Janet E. Finlay, Gregory D. Abowd, and Russel Beale.
Human-Computer Interaction. Prentice Hall, second edition, 1998.
[4] Jonathan Lazar. User-Centered Web Development. Jones and Bartlett
Publishers, Inc., 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, and
Jan Stage. Objektorienteret analyse & design. Forlaget Marko, third
edition, 2001.
An introduction to and explanation of the OOA&D method for
object-oriented system development founded at Aalborg University,
Denmark.
[7] Sun Microsystems. Java Technology, http://java.sun.com.
[8] Wikipedia: MySQL. http://en.wikipedia.org/wiki/Mysql.
[9] Jakob Nielsen.
useit.com:
Jakob
http://www.useit.com/alertbox/20031110.html.
Nielsen’s
[10] Carlos
Pedroza.
Visual Perception:
Gestalt
http://coe.sdsu.edu/eet/articles/visualperc1/start.htm.
147
Website,
Laws,
[11] Abhijit A. Pol and Ravindra K. Ahuja. Developing Web-Enabled Decision Support Systems Using VB .NET and ASP .NET. University of
Florida, Gainesville, first edition, 2003.
[12] Jenney Preece. Human-Computer Interaction. Addison Wesley, first
edition, 1994.
[13] Jeffrey Rubin. Handbook of Usability Testing. John Wiley & Sons, Inc.,
first edition, 1994.
[14] Ben Shneiderman. Designing the User Interface. Addison Wesley Longman, Inc., third edition, 1998.
[15] Abraham Silberschatz, Henry F. Korth, and S. Sudarshan. Database
System Concepts. McGraw-Hill, fourth edition, 2001.
[16] Jan Stage.
DIEB-course (Design, Implementation, and Evaluation of User Interfaces), DAT1/INF1-semester, Aalborg University, Denmark, http://www.cs.auc.dk/˜jans/courses/hci-courses/dieb2004/slides/Lektion04.pdf.
148