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
[email protected] 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 &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 , 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