An online sales system by d105a. Anders Dahl Christian Hertz Kenneth Blanner Holleufer Johnny Jakobsen Rune Mosbæk Martin Toft Steffen Troldtoft

Size: px
Start display at page:

Download "An online sales system by d105a. Anders Dahl Christian Hertz Kenneth Blanner Holleufer Johnny Jakobsen Rune Mosbæk Martin Toft Steffen Troldtoft"

Transcription

1 An online sales system by d105a Anders Dahl Christian Hertz Kenneth Blanner Holleufer Johnny Jakobsen Rune Mosbæk Martin Toft Steffen Troldtoft

2 Signatures Anders Dahl Christian Hertz Kenneth Blanner Holleufer Johnny Jakobsen Rune Mosbæk Martin Toft Steffen Troldtoft

3 Aalborg University Department of Computer Science TITLE: An online sales system SUBJECT: Development of software PROJECT PERIOD: DAT1/INF1 Department of Computer Science September 2 - December 21, 2004 GROUP: d105a STUDENTS: Dat. Kenneth Blanner Holleufer Dat. Johnny Jakobsen Dat. Rune Mosbæk Dat. Martin Toft Inf. Anders Dahl Inf. Christian Hertz Inf. Steffen Troldtoft INSTRUCTOR: Yin Xuepeng xuepeng@cs.aau.dk COPIES PRINTED: 9 NUMBER OF PAGES: 127 APPENDIX PAGES: FINISHED: December 21, 2004 ABSTRACT: 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.

4 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 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

5 Contents I Analysis 9 1 The task Purpose Context System definition Problem domain Classes Events State charts Application domain Usage Overview Actors Use cases Grouping of use cases Functions Function list Function specification User interface Interface functionality Navigation overview Technical platform II Design 40 4 The task Changes for the analysis part Design criteria

6 5 Architecture Technical platform Equipment System software Communication Design language Component architecture Component design Components Model and function component Model-class placement Function-class placement Function specifications Summary Graphical user interface design and components Creating a successful graphical user interface Usage of the Gestalt laws Designing the user interface Web shop GUI Layout and design Dialogue style in the web shop interface Frames Warehouse GUI Layout and design Dialogue style in the warehouse interface Database design Entities Relationships First circularity Second circularity Summary III Implementation 83 9 System implementation Class implementation Warehouse server

7 9.3 MySQL Creating the database Client/server implementation Web server Clients Warehouse application Web shop IV Test Implementation test Class tests Functionality tests Summary Usability test Test result Recommendations V Academic requirements Academic requirements Analysis, design, implementation, and test Analysis Design User interface Database design Implementation Test VI Conclusion Project conclusion 126 VII Appendix 128 A Code test 129 7

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

9 Part I Analysis 9

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

11 Chapter 1 The task 1.1 Purpose The main objective in this project is to create a computer system that enables a company to sell and administer products. Since the company consists of a number of different warehouses spread out in different countries, the system must include a website where products from all warehouses are sold, and furthermore an order management that coordinates inventory and orders between the warehouses. This projects focus area will be the product sale and order management. Statistics, payment functionalities and accounting, except for calculating the prices of the ordered products will be excluded. 1.2 Context We chose to describe the situation through rich pictures. An attempt to draw the problem domain of the situation resulted in the rich picture in figure 1.1. The picture and reflections upon it in the group afterwards gave us in-depth insight concerning the system, we were about to develop. 1.3 System definition To be able to evaluate the system definition, we started out with the FAC- TOR criteria listed in table

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

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

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

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

16 This means a warehouse can exist without having to contain any products, but also that a product can exist without being added to a warehouse. This enables the company to add new products to the system, without necessarily adding the products to the online shop. Invoice: The invoice class is like an order class, except it also registers, which of the employees handled the order. 2.2 Events A brainstorm gave us a lot of possible events for the system, which we systematically evaluated and either discarded or added to the event table shown at table 2.1. The state charts in section also added a few additional events, which had not been thought of during the brainstorm. Customer Order Employee Warehouse Product Invoice Customer registered + Customer removed + Customer changed * Product added to order * * * Product removed from order * * * Order placed * + * * Employee registered + Employee removed + Processing started + * * Order closed + * + Invoice deleted + Product registered * + Product removed * + Product received * Warehouse registered + Warehouse removed + * Event can occur zero to many times + Event can occur zero to one time Table 2.1: Event table 16

17 2.2.1 State charts Based on the event table in section 2.2, we will make state charts for the classes. These state charts will help us identify the states the classes can take. The state charts are followed by a description of a general course and a list of attributes. Customer Figure 2.2: State chart diagram for customer General course: The customer registers in the system Customer login on the web shop The customer adds products to an order Customer accepts the order The customer logout or leaves the web shop Order General course: Products are added to order Order is placed 17

18 Attribute Name Address Phone number Country City Postal code User name Password Description Name of the customer Address for the customer A valid to contact the customer Phone number to contact the customer The country where the customer lives City the customer lives in Postal code for the city The username for the customers website account The password for the customers website account Table 2.2: Attributes for customer Figure 2.3: State chart diagram for order Order pending in warehouse Order processed by employee Order gets closed Employee General course: Employee gets hired Employee is handling tasks Employee gets fired 18

19 Attribute Product list Customer Delivery country Delivery city Delivery postal code Delivery address Shipping date Creation date Warehouse Description List of the products added to the order An associated customer Optional country used for delivery Optional city used for delivery Optional postal code used for delivery Optional address used for delivery The date the order got shipped from the warehouse The date the order was created The designated warehouse where the order will be processed Table 2.3: Attributes for order Figure 2.4: State chart diagram for employee Warehouse General course: A warehouse gets added to the system Products are added and removed from the warehouse The warehouse is removed from the system Product General course: Product added Product removed 19

20 Attribute Name Description Name of the employee Table 2.4: Attributes for employee Figure 2.5: State chart diagram for warehouse Invoice General course: Invoice is created when order is closed Invoice is kept for a certain period Invoice gets deleted 20

21 Attribute Name Country City Address Postal code Product count Minimum product count Description Name for the warehouse Country where the warehouse is placed City for the warehouse Address for the warehouse Postal code for the warehouse to contact warehouse The quantity for each type of products Minimum product count before a signal is sent Table 2.5: Attributes for warehouse Figure 2.6: State chart diagram for product type Attribute Name Model Type Vendor Description Price Picture Description Name of the product Model of the product The type of the product Vendor of the product Description of the product The price the customers are paying The product picture Table 2.6: Attributes for product Figure 2.7: State chart diagram for invoice Attribute Order Employee Description A closed order The employee who handled the order Table 2.7: Attributes for invoice 21

22 Chapter 3 Application domain The application domain can be divided in to two smaller domains. The warehouse facility and the sales site. In the warehouse facility the system will support work assignments carried out by warehouse employees, who are working with processing the orders. This includes packing and shipping products and making sure that no other employee are working on the same order. The warehouse employees reads the needed order information and packs the products. Then an invoice containing the customer information is printed out, and the order is shipped. Another work assignment is registering product and warehouse information. The product information is sent by mail or to the warehouse by its suppliers and then registered into the system. The primary purpose of the sales site is to sell products and pass created orders to the warehouse facility. In this section we will give a total description of the systems usage, functions and interfaces. 3.1 Usage The system has three actors, the customer, warehouse employee, and a warehouse secretary. The customers can use the system to register themselves, order products and later on follow the orders via the track & trace service. The system automatically informs the warehouses about new orders, where the employees have the ability to process the orders. Automatically the system also monitors the warehouses to make sure the product quantity is not running low. The secretary s job is to update information about warehouses, products and warehouse employees. 22

23 3.1.1 Overview To gain an overview of the actors and use cases, which are involved in the interaction, we have constructed an actor table as shown in table 3.1. Customer Warehouse worker Warehouse secretary Update warehouse list X Update product list X Update employee list X Update product quantity X X Login X X Logout X X Create account X Change account information X Update products on order X Search products X Place order X View order status X X Request products X Process order X Finish order X Table 3.1: Actor table for the system, the actors are listed in the columns and the use cases in the rows Actors List of actors: Customer Warehouse worker Warehouse Secretary Customer Purpose: A person who visits the web page, and optionally registers and purchase products. The need of this actor group is to find products, add products to an order and finally place the order. 23

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

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

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

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

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

29 Request products Pattern: Request products is initialized by the warehouse worker. When the warehouse worker needs a product for an order, which is not available in the warehouse, the warehouse worker can request another warehouse to send the product. Objects: Warehouse worker. Functions: requestproductfromwarehouse. Process order Pattern: The process order is initialized by the warehouse worker. The warehouse worker marks that order, to inform other warehouse workers, that the order is being processed. Objects: Warehouse worker. Functions: processorder. Finish order Pattern: Finish order is used by the warehouse worker after the product has been packed and shipped out. The Warehouse worker informs the system that the work is done and at last the system prints out an invoice. Objects: Warehouse worker. Functions: closeorder Grouping of use cases The use cases in section describes all use cases for every actor in the system. However the actors work in different domains, so the use cases have to be put into groups in order to specify what functionality is needed in each domain. The customer will probably be sitting at home and using a web browser, while the warehouse worker and secretary will be in a warehouse and using an application to interact with the system. The grouping of the use cases is shown in figure 3.1. It shows that the customer takes part in all the use cases in the web shop, and the warehouse secretary and warehouse worker take part in each their use cases in the warehouse application. We could have chosen to make a web page where the warehouse worker and the warehouse secretary could login and do their tasks; however for security reasons it seemed more convenient to separate them. So despite having a web shop, we also create a warehouse application. 29

30 3.2 Functions Figure 3.1: Grouping of use cases This section describes the functionality of the system Function list Table 3.2 is a function list of the functions identified in the use-cases. It is not a complete list of all functions, but it shows the most important functions to implement the system Function specification Most of the functions are self-explained by their names, as we only have one complex function. However the place order function need clarification. A more detailed list of demands for the function is shown in table

31 Function Complexity Type Add warehouse Simple Update Remove warehouse Simple Update Add product Simple Update Remove product Simple Update Add employee Simple Update Remove employee Simple Update Update product quantity Simple Update Create account Medium Update Login Simple Update Logout Simple Update Update customer Medium Update Add product to order Simple Update Remove product from order Medium Update Search product Medium Read Place order Complex Update Show orders Simple Read Request product from warehouse Medium Update Process order Simple Update Close order Medium Update Table 3.2: Function table Place order If a warehouse is not chosen manually, this function finds the warehouse, which is estimated to handle the order fastest. The order is stored and the selected warehouse is informed about the new order. Afterwards the products on the order are decreased from the product count in the warehouse. After that the functions checks if the product count is still above the minimum limit, else the warehouse is informed. At last the function generates and returns an invoice. Input: An order placed by a customer in the web shop. Output: An invoice for the order given as input. 31

32 Function Complexity Type Place order Complex Update Finds appropriate warehouse Complex Calculate Store the order Simple Update Decrease the warehouse s product quantity Simple Update Inform warehouse about the new order Medium Signal Inform if the minimum product count is reached Medium Signal Prints an invoice Simple Read Table 3.3: Demands for the placeorder function 3.3 User interface Based on the previous chapters it is noticed that we have two basic system interfaces, the warehouse employee interface and customer web shop interface. The two interfaces have different functionality requirements in order to substantiate the users needs Interface functionality The required functionality of the interfaces is described below. Functionality in warehouse application Login and logout Add and remove warehouse Add and remove employees Add, remove products Change product count Request product from warehouse Order processing Print order Finish order (when packed and shipped) 32

33 Functionality in web shop Login and logout Find products Add products to order Remove products from order Create new customer Update personal information Place order Print invoice Show previous orders (track and trace) Navigation overview We have illustrated an overview of the navigation for the warehouse and web shop in figure 3.2 and figure 3.5 Warehouse Navigation The elements in the figure 3.2 shows how the user can navigate from the main window and around in the system. Figure 3.2: Navigation diagram for the warehouse GUI 33

34 Examples of warehouse interface A few examples of the interface design for the warehouse. Figure 3.3: Warehouse interface 1 34

35 Figure 3.4: Warehouse interface 2 Web shop navigation The web shop element in figure 3.5 is the start page, which have 3 frames, where the main page frame is the product catalogue by default. The rest of the elements in the figure shows how the page change in the main page frame, when navigating around in the web shop. 35

36 Figure 3.5: Navigation diagram for the web shop. The lines of direction marked with (*) shows that you must be logged in to go there. The lines of direction marked with (**) shows that you must be have products in shopping cart to go there Examples of web shop interface A few examples of the interface design for the web shop. Figure 3.6: Web interface 1 36

37 Figure 3.7: Web interface 2 Figure 3.8: Web interface Technical platform The object-oriented analysis and design method (OOA&D) that we are using for this project, will be accompanied by corresponding, object-oriented programming. The abstract classes and events presented through part 1 will be clarified into specific classes and methods in the design part of this report, part 2 that follows the analysis part. 37

38 The users of our web shop do not have to install the Java Runtime Environment on their personal computer, because the web shop will be distributed to the user as HTML 1. The web shop will run as Java Server Pages, JSP, on a web server. These JSP pages will communicate with a Java application running at a database server, i.e. another physical computer. The Java application runs on top of a database service that contains personal information about registered users and information about all products. At every warehouse there is a computer running a Java application which enables the employees to browse and manage orders from the web shop. This application communicates with the application running on the database server. The general structure is illustrated at figure 3.9. Web Browser Java Server Pages (JSP) Operating System Web Server Layer (Java Servlet Application) Database Layer (Java Application) Warehouse Application (Java Application) User Computer Web Server Database Management System (DBMS) Operating System Operating System Operating System Warehouse Computer Web Server Database Server Figure 3.9: Technical platform We will implement the system using Java, because we were taught Java in OOP, an object-oriented programming course at the DAT1 and INF1 semester. One of the advantages with Java is that it is almost architecture independence, i.e. our programs will run on every operating system that supports Java. Figure 3.9 illustrates the web server and database server as separated entities, but it is actually possible to combine their services onto one computer. However, the separation can be useful when dealing with security issues such as DoS 2 attacks. The database service will be a relational database system, but from an objectoriented point of view it is not important whether the database system is Ingres, Oracle, or another product. [6] Information is organized into several tables, and SQL 3 is used to manipulate the tables. On behalf of the user, the 1 HyperText Markup Language 2 Denial of Service 3 Structured Query Language 38

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

40 Part II Design 40

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

42 Chapter 4 The task The task is to propose the conditions for the design of the system. 4.1 Changes for the analysis part Even though we in section on page 23 have shown, that we have two actors with quite different use cases, we will still use the same class called employee for both of them, since they still have the same attributes. The invoice class in the class diagram on page 14 will be removed from the class diagram as we can use the order class for same purpose. The reason for this, is that we have added the processedby attribute to the order class, which was the only difference between an order and an invoice. 4.2 Design criteria In this section we determine some design criteria for the quality of the system. A few design criteria where pointed out to be more important than the rest. These criteria is meant to reflect some of the specific conditions for the design of the system. The tables 4.1 and 4.2 shows the design criteria for the web shop and the warehouse application with each their order of priority. 42

43 Criteria Very important Important Less important Irrelevant Easily fulfilled Usable Secure Efficient Correct Reliable Maintainable Testable Flexible Comprehensible Reusable Portable Interoperable X X X X X X X X X X X X Table 4.1: Prioritized design criteria for the web shop application Criteria description for web shop table 4.1 The web shop will be designed with a graphical interface which is fast and easy for the user to use The security of the web shop is important. The web server will handle the basic security, and in the implementation the right connections between the user and the system will be designed The efficiency of the web shop is very important. The web shop will possibly face the job of handling several customers at a given time and all delays are annoying. We certainly do not want customers to leave the web shop because of slow performance The web shop will get product and warehouse data from the server. It is very important that this information is correct. However minor concurrency problems can effect that the information is not 100 percent correct, if the customer does not refresh the web page Reliability is important. The user should not be bothered with connection losses and timeouts from the server Maintenance is easy fulfilled when all the web shop s data is retrieved from the server 43

44 Functionality tests during development and user tests will be made. Testable is marked less important since no special applications or classes are made The applications flexibility is marked as less important Comprehensive is marked as very important since the users will leave and choose another place to shop, if the information is in comprehensive The reusable criteria is marked as less important, since most of the web shop is dynamic. A few static pages exist such as company profile and contact page The portable criteria is important. It is difficult to make the web page look the same in all screen resolutions and also make it independent of having scripting languages enabled The web shop will not communicate with systems or applications other than the server, so interoperability is irrelevant Criteria Very important Important Less important Irrelevant Easily fulfilled Usable Secure Efficient Correct Reliable Maintainable Testable Flexible Comprehensible Reusable Portable Interoperable X X X X X X X X X X X X Table 4.2: Prioritized design criteria for the warehouse application Criteria description for warehouse application table 4.2 The application should be fast and easy to use by the employees 44

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

46 Chapter 5 Architecture To ease the design and understanding of our system we will in this chapter describe the technical platform in depth and choose an architecture for our components. 5.1 Technical platform In this chapter we have a short description of the technical platform that our system will use. Because the system is using a client-server architecture, we will have to describe both of them Equipment Because we use Java Server Pages to generate HTML code to the clients when they connect to our web server, the only requirement is that the web shop clients have an Internet browser like Mozilla Firefox and a standard PC with and Internet connection. The warehouse clients will also use standard PC s with Internet connections but must in addition have JRE 1 version 1.5 installed. The server is also required to run JRE System software We will program the system in Java and use NetBeans to make sure that the Java running on our server and the Java Server Pages can send the objects over the network connection. We have chosen to use the latest Apache 2 and Jakarta Tomcat version as web server because we are familiar with this 1 Java Runtime Environment, used for executing Java applications on end-user systems 2 Apache HTTP Server Project, 46

47 system, and the system is widely used around the world. For our server we have also chosen to use the MySQL-database system. The choice is based on the fact that the MySQL-database is a widely used open-source system Communication The system will have interfaces between the server and clients in two different ways, and interfaces are also needed inside the server. Figure 5.1 on page 48 gives a basic overview. The Java application controlling access to the database system interacts with the Java Servlet using methods implemented in Java Runtime Environment. The Java programming language and the libraries already support communication between different applications, such that the Java Servlet (which generate HTML pages for the web shop) can exchange objects with the Java application on top of the database system. This communication can even take place through networks. The same interface is needed on the warehouse client, because the warehouse client also needs to exchange objects with the Java application, which guards the database system Design language Official UML 3 -notation will be used in the design of the system. UMLnotation is described briefly throughout Objektorienteret Analyse & Design by Mathiassen et al[6]. 5.2 Component architecture We chose to make a system that utilizes a client-server architecture, because we have one web shop and several warehouses, which need to share information. The web shop and the warehouses will be clients of a server containing all necessary information, i.e. customer information, product information, orders and warehouse information. As seen on figure 5.1 we use an architecture for distribution in the client-server architecture called local presentation. 3 Unified Modeling Language 47

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

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

50 Chapter 6 Component design We will in this section design and describe the system s components, starting with the model component, followed by the function component. 6.1 Components In this section we will list all classes for the components. We will use our class diagram 2.1 and our state charts and add further technical information needed for the implementation. The classes in the model component are responsible for all communication between the function and database component. The classes in the function component are responsible for communication between the user interface and the model component. The following is a specification of all the classes and their operations and attributes. Customer Purpose: The information registered is the customer s personal data Attributes: name, address, country, , phone, city, postalcode, username, password Operations: login, logout, createaccount, updateaccount, searchproduct, vieworders Shopping cart Purpose: To register information the products the customer wants to buy 50

51 Attributes: customer, products, warehouse, deliveryname, deliveryattention, deliveryaddress, deliverypostalcode, deliverycity, deliverycountry Order Operations: addproduct, removeproduct, changewarehouse, changedeliveryplace, placeorder Purpose: To register information about an order Attributes: customer, products, warehouse, status, trackandtracenumber, creationdate, deliverydate, processedby, deliveryname, delivery- Attention, deliveryaddress, deliverypostalcode, deliverycity, deliverycountry Operations: findwarehouse, printinvoice Warehouse Purpose: To register information about the different warehouses, and their inventory Attributes: name, address, postalcode, city, country, Operations: addwarehouse, removewarehouse Product Purpose: Register information concerning the warehouses products Attributes: name, vendor, model, description, salesprice, pictureweb- Path, processed, quantity, warehouse Operations: createproduct, deleteproduct, changequantity, movefromotherwarehouse, searchforproduct Employee Purpose: Register informations concerning the employee s work on the order Attributes: name Operations: login, logout, addemployee, removeemployee WorkArea Purpose: To give functionality to the warehouse Attributes: employees, warehouses, products Operations: processorder, finishorder, vieworders 51

52 6.2 Model and function component This section will from the classes described in section 6.1 try to specify, which classes that is placed in the model component and which of them is in the function component. The classes we found in the analysis shown in table 2.1 at page 14 seemed to have a deficiency. In our event table at page 16 we can also see that we have two common events, which can occur several times. This means that we have to create a new class. We have some inconsistency in the way the order class would look depending on if we want to use it in the web shop or in the warehouse application. We will therefore create a new shoppingcart class for the website and use the order class for the warehouse application. There is also two common events, which can occur several times for the processing started event, therefore we create a new class for the warehouse functionality called workarea Model-class placement In this section we will focus on what functions that can be assigned to the classes in the model component. Customer Order login logout createaccount updateaccount searchproduct vieworders findwarehouse printinvoice Warehouse 52

53 addwarehouse removewarehouse Product createproduct deleteproduct changequantity movefromotherwarehouse searchforproduct Employee login logout addemployee removeemployee The above list show how some functions are placed on the classes. The functions not listed in this section are functions that would make little sense placing in the existing classes, or functions operating on several objects. These functions will in the next section be placed in new function classes Function-class placement The unplaced functions will be added in new classes. ShoppingCart addproduct removeproduct changewarehouse changedeliveryplace placeorder 53

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

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

56 1 bestwarehouseavailableproducts = if (Warehouse i s not set ){ 4 for ( i =0; i <numberofwarehouses ; i ++) { 5 6 availableproducts = 0; 7 8 for ( j =0; j <numberofproductsonorder; j ++) { 9 if ( warehouse ( i ) has product ( j )) availableproducts++ 10 } if ( availableproducts > bestwarehouseavailableproducts) { 13 bestwarehouse = i 14 bestwarehouseavailableproducts = availableproducts 15 } 16 } 17 } Table 6.3: findwarehouse algorithm Figure 6.1: Class diagram for the model and function components 56

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

58 Chapter 7 Graphical user interface design and components Since we chose GUI design as our main focus area we put a thorough effort into examining the important design criteria. Hereafter we will describe some of the main things to consider when designing an interface. 7.1 Creating a successful graphical user interface Creating a graphical web user interface that targets all users in a selected target group can be difficult because we believe users have different taste in GUI design. A user friendly interface which has all the needed navigation functions is the first step on the way to perfection. GUI specialists such as Donald Norman tells us the human mind processes new information based on observations and inferences, this is applicable with e-commerce web sites as well as for the rest of society s generalized consumer equipment [14]. The goal of e-commerce web sites is to get the user s attention, and encourage the user to use the site. By fulfilling their conceptual models, the basis of navigation is accomplished. The choice of using more atypical functions on the web application needs to be well planned to cohere with the rest of the site and for the user to understand these functions. Overall this means the web application must follow some of the ground principles of similar websites, which means a design model and a system image 58

59 that are consistent with the user s model of the web application. Ideally, the user s model and the design model are equivalent according to Donald Norman[14]. The physical appearance, its operation, and the way it responds, must be consistent with and exemplify the operation of the proper conceptual model. Furthermore the website should have no irrelevant content, contrary all relevant information should be easy accessible. To make a more interesting user interface that keep the users interested and make them spend time on the site as well as returning, we will examine the GUI elements recommended when building a successful user interface. In our case the website GUI will represent the company s public face, therefore the website GUI should be greater prioritized than the warehouse GUI, both nonetheless should be user friendly. 7.2 Usage of the Gestalt laws We have chosen to utilize the Gestalt Laws B.11 in the layout of the web shop. In the top frame we have chosen to use primary the principle Closure and Continuity to group the elements together. The links are meant to be conceived as one group, which contains navigational links. In the right frame the principle closure, proximity and symmetry will be the ones primarily used. The elements in the text fields will be group together, because we want the user to perceive them as belonging together and when filing out one of them, the rest must be filled out as well, this is the principles proximity and closure. The content of the shopping cart is set between lines, which groups related information together, in order to make the information easy-to-read. The Gestalt principle used here are symmetry and closure. The elements in the main frame are grouped together after the symmetry, continuity and proximity, closure principles. The product catalog is designed after the continuity and proximity principles. The products names and thump nails are grouped together into the form of a table. This is the principle of both principles while the principle of proximity is used when grouping the individually thump nail and product name together. On the sites product search, create customer and shopping cart, the principles proximity and closure are used. As with text fields, in the right frame, the principles proximity and closure are used. In addition, on the shopping cart site lines are used to group information together, which is the symmetry and closure being used. 59

60 7.3 Designing the user interface In order to design the user interface we will take two use cases discussed in chapter 3. The two use cases are Process order and Place order. The first thing to do is to make an use case diagrams, this will help us understand the complexity involved in performing the specified tasks and thus help us create an user interface that will show the user the important information and functionality that he/she will need to perform his/her task. Hereafter an interaction model will help us understand how the user will interact with the system through specific tasks and display what needs to be seen in each window/frame. Then dialog-models will be constructed to enable us to specify in which sequence the tasks will be accomplished. Based on all this we will make an interaction space model that will be the GUI component of the system, and based on this we will implement the GUI. Use cases In figure 7.1 we see the use case for process order. It is important to show the user which orders are available in the warehouse and also if the order is already being worked on by another employee. Therefore we have the status NEW and PENDING. When an user chooses an order a description of what that order contains will appear. If an employee is working on an order that contains a lot of products, it would be a good function to mark each found item. When all items are found and packed the employee must be able to finish the order and input his name for future reference. In figure 7.2 we have the process order interaction diagram. From this diagram we can see that we will separate this use case into three different windows. The first will be an order browser thats lists the different orders and the next will be a product browser that lists which items an order contains. If a warehouse receives a large amount of orders the data quickly becomes unclear, by doing the above mentioned we distribute the output and clarify the data. The last screen will appear when an order is finished and will prompt the user to enter his or her name. It will be placed as a separate screen appearing every time an user finishes an order. In this way the user cannot accidently forget to put his name on a processed order. The dialog-model in figure 7.3 shows the order in which the tasks must be completed. The first thing an user does is to choose an order. After this 60

61 the user will be taken to a screen that displays the order, and here he will identify and find each product in the order. When he has found all the items he will finish his order and put his name on it. <Employee> <System> Open System Display orders Chose order Select order [If status new]: Set status pending [If status pending]: Show products in order Mark products in order [If all products marked]: Enable Finish order [If all products not marked]: Press finish order Display employee Choose employee Figure 7.1: Use case for process order 61

62 Order browser Chose order Product browser Identify Product Finish order Employee browser Choose employee Figure 7.2: Interaction model for process order 62

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

64 In figure 7.5 we have the corresponding interaction diagram for this use case. We have chosen to display the available information and functions in three screens. The first screen will be the log in screen. If the user have not already logged in when the place order button is pressed he will be presented with the login screen. A log out button will appear when the user is logged in and is visible at all times for log out. The second screen will display all information about an order so the user can review it and change it if necessary. In this way an user can get a complete overview of his or her order without thinking about changing screens or other unnecessary tasks. The last screen will only show the created invoice for the order so the user gets confirmation on his order. Here he will have the ability to print out the invoice. The dialog model, seen in figure 7.6, is for this use case a little challenging because the user has a lot of optional choices and the ability to log out whenever he or she wishes, but the general dialogue is that the user logs in, he presses place order then accept order, and then logs out. 64

65 <Customer> <System> Press place order [If customer logged in]: Display order screen Log in [not logged in]: Prompt user to log in [If quantity of products is right] [If quantity not right]: Enter X of items to remove Press update Remove X items from order [If different address is needed]: Enter delivery address Set delivery address [no delivery address]: Select warehouse [If default warehouse selected]: Choose warehouse in customers country [If warehouse X selected]: Accept oder pressed Set warehouse to X Order created [no print invoice]: Display invoice screen [If print invoice pressed] Print out invoice Figure 7.4: Use case for place order 65

66 Log in view Log in Invoice view View invoice Log our view Log out Print invoice Customer info view Order view Change item quantity Delivery addres view Set delivery address Select warehouse view Set warehouse Figure 7.5: Interaction model for place order 66

67 Log in Change item quantity Place order Log out Set delivery address Accept order Set warehouse Print Invoice Figure 7.6: Dialog model for place order The Interactionspacemodel for each of the use cases can be seen on figure 7.7 and figure 7.8. We now know how the GUI should be build so it will support the use cases we have and the decisions we have made throughout the process, now we have to design the GUI objects themselves. 67

68 <<Interaction Space>> Main frame <<output elements>> Internal frame(empty) Message field <<input elements>> <<navigates>> <<Interaction Space>> Ordertable <<output elements>> <<input elements>> <<navigates>> <<Interaction Space>> Orderdescribtion <<output elements>> <<input elements>> <<actions>> Exit <<actions>> Close Selectorder <<contains>> <<Interaction Space>> Orderlist <<output elements>> Status OrderID Creatiun date <<actions>> Close Finish order <<navigates>> <<Interaction Space>> Employee selection <<output elements>> Employeelist <<contains>> <<Interaction Space>> Productlist <<output elements>> ProductID ProductName Vendor Model Decription Quantity <<input elements>> Check product <<actions>> <<input elements>> <<actions>> <<input elements>> Chose employee <<actions>> Confirm Figure 7.7: Interaction space model for process order 68

69 <<Interaction Space>> Webshop <<output elements>> <<input elements>> <<navigates>> <<Interaction Space>> Order view <<output elements>> <<input elements>> <<navigates>> <<Interaction Space>> Invoice <<output elements>> OrderID Creation date WarehouseID Total price <<input elements>> <<actions>> <<actions>> <<actions>> Accept order Print <<contains>> <<Interaction Space>> Login <<output elements>> <<input elements>> Name Password <<contains>> <<Interaction Space>> Selectwarehouse <<output elements>> <<input elements>> Warehouse <<contains>> <<contains>> <<contains>> <<contains>> <<Interaction Space>> Customer info <<output elements>> Name Address Postal code Country <<input elements>> <<contains>> <<Interaction Space>> Invoice productlist <<output elements>> Vendor Name Model Quantity Price <<input elements>> <<actions>> Login <<actions>> <<actions>> <<actions>> <<Interaction Space>> Delivery address <<output elements>> <<input elements>> Name Attention Address Postal code Ciry Country <<actions>> <<Interaction Space>> Shopping cart <<output elements>> Total Price <<input elements>> <<actions>> <<contains>> <<Interaction Space>> Productlist <<output elements>> Vendor Name Model Quantity <<input elements>> Quantity <<actions>> Update Figure 7.8: Interaction space model for place order 7.4 Web shop GUI The Web shop GUI has been developed using the methods and concepts described previous in this chapter and in sections B.8, B.9, B.10, B.11 and B.12. The overall objective with our web application is to sell products. The customer should have easy access to finding the desired products and the navigation should be as simple as possible to relieve the customer s overview of the site. Furthermore we want a simple and clean design without any irrelevant frames and other irrelevant graphics, but at the same time the graphics must be appealing to the customer, because it is an e-commerce site and customers should preferable return and also recommend the site to others. 69

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

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

72 light gray color, the text size and color will be controlled from CSS 1 which will make the text layout coherent so links and regular text look the same all through the site. Right frame In the right frame shopping cart and login/logout will be placed. The background will be a light gray for the frame to cohere with the background gradient of the main frame. There could be a small deviation in the basic user concepts concerning the shopping cart in the right frame, but we think placing the shopping basket in the right frame would be a great help for the customer to keep overview of what is placed in the shopping cart and also giving the overview of the total price. 7.5 Warehouse GUI It is important to have an user-friendly warehouse application interface as it eases the work for the employee and makes it easier to learn for new employees and companies[13]. We tried to implement this by making an user interface based on who the user would be and how the system would be used, which we documented in the analysis Layout and design In the warehouse, there is a computer with an interface which is used by multiple warehouse workers. Therefore the usual form of log in would not be appropriate in this case. It would simply be too demanding if the warehouse workers had to log in and out for every order they processed. Instead when each individual order is finished it would be possible choosing which employee s name goes with the order by using a drop down menu, see figure 7.9. Figure 7.9: User dropdown menu 1 Cascading Style Sheet, a file which controls layout for a website. 72

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

74 dropdown menu gives an option to implement administrative functions like add/remove employee, which we will not do. Warehouse font Java uses the default fonts installed on the operation system, it uses by default a sans-serif font, so the readability is acceptable, we could chose a font type for the warehouse GUI, it would result in less usability because it could differ radically from the operation systems layout Dialogue style in the warehouse interface The warehouse employee is a general employee page, with login, where the user interface will be used at the internal storage when processing an order. Menu selection and direct manipulation will be used by the stock employee. Substantial use of menu selection will be used when processing orders and to see statistics on sales. Form fill-in will be used when correcting/adding new product categories, products, descriptions and prices. 74

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

76 erations, e.g. productdetails may be written as ProductDetails. In the following sections the database s entities and relationships will be introduced, justified, and explained. 8.1 Entities The entities primary keys are underlined at figure 8. We chose to use numeric values as the primary key in all entities, because it is faster to search through a list of integers compared to a list of text strings [11]. In some cases text strings would have been the natural alternative, e.g. a compound primary key in warehouses consisting of the warehouse s name, city, and country. We list the entities in order of appearance at the ER-diagram in figure 8 on page 82. Employees This entity represents all employees working at all warehouses. Because we opted out the administration part of the sales system, we do not want to keep personal information about the employees. We settle for an unique identification number and a name. In that way it is possible to distinguish between employees with identical names. Orders All orders existing in the system will be represented by this entity. Only master information about an order is stored here, including unique identification number, status, involved customer, involved warehouse, involved employee, delivery details, various dates, and track & trace number for the distributed package. The ER-diagram at figure 8 shows clearly that the delivery details, represented as attributes starting with delivery, were not existing in the early design of the database. There are delivery fields for name, att (attention), address, postal code, city, and country. These fields are not always necessary, because the customer may decide to stick with the name and address stored in the Customers entity. We think it is correct to place the attributes in the Order entity, because the delivery details cohere to a specific order, i.e. the customer may choose different delivery details for other orders. 76

77 OrderDetails The contents of an order are kept in this entity, i.e. an order identification number, a product identification number, and a quantity are linked together. As an example, an order with the identification number 7 may contain two bikes and five mopeds with the product identification number 1 and 2, respectively. That content of an order will ensue two records which will look like (7,1,2) and (7,2,5) if written using the tuple notation (orderid, productid, quantity). The entity contains records for all orders existing in the system so the number of records may be extremely big. To ensure distinct records we have added a primary key called orderdetailsid which is unique. ProductDetails All details concerning the products in the system are stored in this entity, except for stock figures. Each product has an unique product identification number and belongs to a certain category in the Categories entity. In addition information about name, vendor, model, price, description, and picture can be kept in this entity. The product identification number is an unique, primary key. Categories Products are organized into categories and this entity keeps information about all the categories. Every category has an unique identification number, a name, a description, and a picture. The identification number is the primary key and is referenced by products in the productdetails entity. Customers This entity represents all registered customers in the system. Every customer has an unique identification number so the system is able to distinguish between them. The number is used as an unique, primary key. A personal user name and password are used by a customer to log on the web shop. This entity also keeps the real name and address of a customer which is needed for sending out ordered products and to avoid the hassle of typing in the same information with every order. Additionally a phone number and an address are kept as a convenient way to contact the customer. 77

78 Warehouses The sales system supports multiple warehouses and information about all the warehouses is represented by this entity. We need to store name, address, postal code, city, country, and address of the warehouses. The latter is kept as a convenient way to contact the warehouse. As an example the warehouses addresses could be registered in a mailing list, such that the warehouses were able to communicate easily and cheaply, however that is out of the scope of this project. It would be reasonable to use a compound key consisting of e.g. name, city, and country as primary key for this entity, but for performance reasons we distinguish between the warehouses using an identification number as previously mentioned. StockStatus This entity links together products, warehouses, and quantities. It has four attributes which are: identification number for each StockStatus record, a product identification number, a warehouse identification number, and a quantity. In this way it is possible to express how many pieces of a single product type each warehouse got in stock. The primary key is the unique identification number for each record which is only included to ensure distinct records. Moreover it is good practice to remember primary keys in all entities. [15] 8.2 Relationships In this section the database model s relationships will be presented and accounted for. The first-hand impression of the ER-diagram may give rise to headache for database experts, because the entities and relationships form two circles. Circularities in ER-diagrams are known to be the root of redundant data and operational problems, but in section and we will explain why that fact has nearly no impact on our structure [15]. The entities orders, orderdetails, productdetails, stockstatus, and warehouses are involved in the circles. The relationships are presented in order of appearance in the ER-diagram. Employees process orders This is an one-to-many relationship from employees to orders which cause the employeeid attribute in the order entity. The argument for an one-to- 78

79 many relationship is that an employee may be responsible for many orders, however an order is only processed by one employee. Orders contain orderdetails An order may contain many products, but a record in orderdetails only refers to a single order in the orders entity. That is why this relationship is one-to-many from orders to orderdetails. The products belonging to an order are listed in orderdetails as product identification numbers together with warehouse identification numbers and quantities. ProductDetails are-referenced-by orderdetails The entity productdetails contains, just like the name alludes, details on all registered products, except for the associated stock figures. A record in productdetails may be referenced by multiple records in orderdetails using the product s unique identification number, i.e. the relationship is one-tomany from productdetails to orderdetails. Categories contain productdetails This relationship connects categories and productdetails, because the products recorded in productdetails are categorized into categories recorded in the categories entity. A single category may contain many products, so the relationship is one-to-many from categories to productdetails. Customers place orders Hopefully, customers place orders through the web shop to utilize the system. That act is represented by this relationship which allows a single customer to place several orders and limits an order to be placed by one customer. As a consequence hereof the relationship is one-to-many from customers to orders. Warehouses own orders Each order is assigned to a single warehouse, such that a single warehouse is said to own a number of orders. The relationship is one-to-many from warehouses to orders, and as a result of this, the orders entity has an attribute called warehouseid. 79

80 Warehouses are-referenced-by orderdetails We want to attach each product on an order to a single warehouse, because the products offered on the web shop may be placed at different warehouses initially. It is then the employees job to examine pending orders and check which products that should be moved between the company s warehouses to send only one package to the customer. As the moving progresses, the products warehouse property can be updated. The relationship is one-tomany from warehouses to orderdetails, because the records in orderdetails may only reference a single warehouse, but a warehouse may be referenced by several records in orderdetails. ProductDetails are-referenced-by stockstatus Products recorded in productdetails are referenced by records in stockstatus. The relationship is one-to-many from productdetails to stockstatus, because a product may be in stock at several warehouses, but a record in stockstatus may only reference a single product in productdetails. Warehouses have stockstatus Each warehouse has information about stock status which is recorded in the stockstatus entity. The relationship from warehouses to stockstatus is one-to-many, because a record in stockstatus may only point to a single warehouse, but a record in warehouses may be linked together with several records in stockstatus First circularity This circularity is created by the relationships between orderdetails, product- Details, stockstatus, and warehouses. Both orderdetails and stockstatus have the attributes productid and warehouseid, because there are one-tomany relationships away from warehouses and away from productdetails. If the circle had circular derivation of attributes because of unidirectional one-to-many relationships, it would present a serious problem. If that is the case, then the database design is impossible to setup in a relational database management system, because the tables, which represent the entities, have to be created one at a time, and a table cannot be created if it relates to another, non-existing table [15]. 80

81 By inserting data into warehouses and productdetails before inserting data into orderdetails and stockstatus, the circularity is proven unproblematic. However, this design makes it possible to add to an order products which are not present in the warehouse, which they are referring to in orderdetails, i.e. orderdetails may contain a record stating seven bikes from a warehouse that does not sell bikes (the product identification number for the bikes are not linked together with the identification number of the warehouse in stockstatus). That is a matter of debate, because it could be considered either a feature or a flaw, e.g. a company may be interested in selling products prior to having them in stock. The database layer on top of our database insures that the system described in this report does not assign products to warehouses, where they are not in stock Second circularity This circularity is created by the relationships between orders, orderdetails, and warehouses. The relationships result in the attribute orderid in orderdetails, the attribute warehouseid in orderdetails, and the attribute warehouseid in orders. As previously mentioned, the two warehouseid attributes are needed, because an order in itself is owned by a warehouse and the order s products may temporary be placed at other warehouses. Again, the solution is to insert data into the entities in correct order. First create a warehouse, then create an order, and finally add products to the order by creating records in orderdetails. Bear in mind, that records in employees and customers are needed to create an order, just like records in productdetails are needed to create records in orderdetails. 8.3 Summary We expect the database design to work just fine if implemented in a relational database server. The implementation will be done using the MySQL database server in section 9.3, where we will explain SQL 2 and Java s database connectivity too. 2 Structured Query Language 81

82 0..* 0..* 0..* 0..* 0..* 0..* * * 0..* 1..1 employeeid name categoryid name description picture employees orderdetails productdetails categories contain contain process customerid status orderid place stockstatus warehouses customers have are referenced by are referenced by quantity warehouseid productid stockstatusid country city postalcode address name warehouseid phone country city postalcode address name password username customerid quantity warehouseid productid orderid orderdetailsid trackandtracenumber shippingdate creationdate employeeid warehouseid picture description price model vendor name categoryid productid processed deliverypostalcode deliveryname deliveryadress deliveryatt deliverycity deliverycountry orders own are referenced by Figure 8.1: Entity-relationship diagram for the database 82

83 Part III Implementation 83

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

85 Chapter 9 System implementation In the implementation phase we take the system designed in the design phase and realize it on the selected technical platform. In this section we will go through the implementation of the database, the model classes, and the function classes. 9.1 Class implementation The implementation of the classes from the class diagram at figure 6.1 have been implemented, but we have made some changes to the design during the implementation phase. The implementation started with coding the classes in the model component. The main differences in the model component between the design and implementation is the placeorder method. In the implementation the method has been placed in the Order class, while it is located in the shopping cart class in the system design In the design the changequantity method from the product class have not been implemented, but the functionality the method has is implemented in the placeorder method To ease the implementation of the products we have created a new class called category. It is mainly used for grouping a certain type of products 85

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

87 shop, will have to send data to a specific warehouse, which can be solved by using RMI-callback. 9.3 MySQL MySQL is a relational database server owned and sponsored by a single Swedish, for-profit firm, MySQL AB. It is available under different licenses to accommodate all intended use, such as the GPL 1. Both source code and binaries (for Linux, FreeBSD, Windows, etc.) are freely accessible from MySQL s official homepage at The application turns in a strong performance being multithreaded, and security is available through multiuser support. [8] We utilize the latter by creating an user called wwwuser only with permission to select from, insert into, update, and delete from tables. The tables will be created and owned by the root user who is the database s administrator. [1] Just like The Apache Derby Project (the database server introduced to us in this semester s PER-course), MySQL is reached from within a Java application using a JDBC-driver 2. Sun Microsystems let the developers of database servers develop their own drivers for connectivity; MySQL s is called MySQL Connector/J. MySQL Connector/J MySQL Connector/J is downloadable from MySQL s official homepage and requires only a simple installation. We will introduce the reader to Connector/J through examples. Please note, that the presented code needs to have nearly all classes from the java.sql package imported. Within a Java application, a database connection is initialized by this short code: Connection c; Class.forName("com.mysql.jdbc.Driver").newInstance(); c = DriverManager.getConnection("jdbc:mysql://" + host + "/" + database + "?user=" + user_name + "&password=" + password); In our case the connection string is jdbc:mysql:// /d105a?user=wwwuser&password=no8xt26gja. A query may now be made through a statement: 1 GNU General Public License, 2 Java Database Connectivity 87

88 Statement s; s = c.createstatement(); s.executeupdate("update customers SET name= " + name + ", address= " + address + ", postalcode=" + postalcode + ", city= " + city + ", country= " + country + ", phone= " + phone + ", = " + + " 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: _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

89 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 (2 16 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

90 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

91 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 public interface NetworkWarehouseInterface extends Remote { 2 3 getorder ( int wid) throws RemoteException ; 4 delorder ( int orderid ) throws RemoteException ; 5 productcategory ( int catid ) throws RemoteException ; 6 listcategory () throws RemoteException ; 7 changeorderstate ( int orderid, String status ) throws RemoteException ; 8 getproductlist ( int orderid ) throws RemoteException ; 9 changeproductstate ( int orderid, int productid, boolean s t a t e ) throws RemoteException ; 10 getemployees () throws RemoteException ; 11 setorderemployee ( int orderid, int employeeid ) throws RemoteException ; 12 getorderemployee ( int orderid ) throws RemoteException ; } 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

92 1 public Integer login ( String username, String password ) { 2 3 Integer response = 0; 4 String url = rmi :// / ; 5 6 try { 7 NetworkWebShopInterface networkwebshop = ( NetworkWebShopInterface ) Naming. lookup ( url + webshop ) ; 8 response = networkwebshop. login ( username, password ) ; 9 } catch ( Exception e ) { 10 e. printstacktrace () ; 11 } return response ; } 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

93 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

94 Figure 10.1: Screen dump of the warehouse client 10.2 Web shop The web shop has been implemented as shown in figure 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 The process of adding products to a shopping cart and placing an order is shown in the following figures. 94

95 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

96 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

97 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

98 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

99 Part IV Test 99

100 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 JUnit 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 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

101 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

102 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 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

103 Characteristic Range Frequency Education/employment Students 100% Sex Male 67% Female 33% Age 19 33% 21 37% Use of Internet per week 1-4 hours 33% 4-8 hours 33% More than 8 hours 33% Use of computers 5-12 hours 33% per week More than 12 hours 67% From where do At home 100% they use At work/or at school 67% the Internet Other 33% Has purchased products online before Yes 100% Their own definition of their 2 33% experience with online shopping. 4 33% From 1-5 where 1 is no 5 33% experience and 5 is expert. Table 12.1: Result of background questionnaire From the results shown in table 12.1, a profile of the test participants can be made: The participants are students, between 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 ex- 103

104 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

105 Question Range Result Presentation From The use of graphics is 4 33% very appropriate for this site 6 67% 2. The design elements are 4 33% not annoying or distracting 6 33% 7 33% 3. The amount of information 3 33% displayed is just right 4 33% 6 33% 4. The colors in this web site 6 33% are pleasant 7 65% 5. This site organized it s information 4 33% in a way that is easy for 5 33% me to understand 7 33% 6. This site s attractiveness invites 3 33% me to go further into this site 4 33% 5 33% Overall user reaction to using the system From Terrible - wonderful 4 67% 5 33% 2. Frustrating - satisfying 6 33% 8 67% 3. Dull - stimulating NA 33% 5 67% 4. Difficult - easy 6 33% 7 33% 9 33% 5. Inadequate power - adequate power 7 33% 9 67% 6. Rigid - flexible 4 33% 5 33% 9 33% Multimedia From 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 105the evaluation questionnaire

106 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

107 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

108 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

109 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

110 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

111 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

112 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

113 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 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

114 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

115 Part V Academic requirements 115

116 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 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 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

117 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 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

118 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 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 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

119 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

120 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 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

121 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 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

122 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 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 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 re- 122

123 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 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 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

124 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

125 Part VI Conclusion 125

126 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

127 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 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

128 Part VII Appendix 128

129 Appendix A Code test Throughout the implementation of the system a lot of tests were made. To ease the testing a tool called JUnit 1 were used. The test method used is a bottom-up testing, starting with the primitive methods moving towards the main functionality. A.1 Class tests 1 import java. u t i l. Date ; 2 import junit. framework. TestCase ; 3 import c lasses. ; 4 import java. u t i l. Date ; 5 / d105a 7 8 Test setup for the model classes 9 10 / 11 public cl a ss UnitTest extends TestCase { 12 private Employee testperson ; 13 private Category testcategory ; 14 private Customer testcustomer ; 15 private Order testorder ; 16 private Product testproduct ; 17 private Warehouse testwarehouse ; 18 private float price = 334; 19 protected void setup () { 20 testperson = new Employee (2, name ) ; 21 testcategory = new Category (1, asus, motherboard, picture ) ; 22 testcustomer = new Customer (1, user, pass, name, address, 9000, aalborg, denmark, 9945, ) ;

130 23 testorder = new Order (12, status,34,12,1,new Date (),new Date (), track ) ; 24 testproduct = new Product (32,1, name, vendor, model, price, description, picture, 345,true ) ; 25 testwarehouse = new Warehouse (12, name, address,34, city, country, ) ; 26 } 27 protected void teardown () { 28 testperson = null ; 29 testcategory = null ; 30 testcustomer = null ; 31 testorder = null ; 32 testproduct = null ; 33 testwarehouse = null ; 34 } 35 / 36 testcase1 () 37 Employee class 38 / 39 public void testcase1 () { 40 assertequals (2, testperson. getemployeeid () ) ; 41 assertequals ( poul, testperson. getname () ) ; 42 } 43 / 44 testcase2 () 45 Category class 46 / 47 public void testcase2 () { 48 assertequals (1, testcategory. getcategoryid () ) ; 49 assertequals ( asus, testcategory. getname () ) ; 50 assertequals ( motherboard, testcategory. getdescription () ) ; 51 assertequals ( picture, testcategory. getpicture () ) ; 52 } 53 / 54 testcase3 () 55 Customer class 56 / 57 public void testcase3 () { 58 assertequals (1, testcustomer. getcustomerid () ) ; 59 assertequals ( user, testcustomer. getusername () ) ; 60 assertequals ( pass, testcustomer. getpassword () ) ; 61 assertequals ( name, testcustomer. getname () ) ; 62 assertequals ( address, testcustomer. getaddress () ) ; 63 assertequals (9000, testcustomer. getpostalcode () ) ; 64 assertequals ( aalborg, testcustomer. getcity () ) ; 65 assertequals ( 9945, testcustomer. getphone () ) ; 66 assertequals ( , testcustomer. get () ) ; 67 } 68 / 69 testcase4 () 70 Order class 71 / 72 public void testcase4 () { 73 assertequals (12, testorder. getorderid () ) ; 74 assertequals ( status, testorder. getstatus () ) ; 75 assertequals (34, testorder. getcustomerid () ) ; 76 assertequals (12, testorder. getwarehouseid () ) ; 77 assertequals (1, testorder. getemployeeid () ) ; 78 assertequals (new Date (), testorder. getcreationdate () ) ; 79 assertequals (new Date (), testorder. getshippingdate () ) ; 130

131 80 } / 83 testcase5 () 84 Product class 85 / 86 // getprice method in the product class not tested due to complications testing float values 87 public void testcase5 () { 88 assertequals (32, testproduct. getproductid () ) ; 89 assertequals (1, testproduct. getproductid () ) ; 90 assertequals ( name, testproduct. getname () ) ; 91 assertequals ( model, testproduct. getmodel () ) ; 92 assertequals ( description, testproduct. getdescription () ) ; 93 assertequals ( picture, testproduct. getpicture () ) ; 94 assertequals (345, testproduct. getquantity () ) ; 95 assertequals (true, testproduct. getisprocessed () ) ; 96 } 97 / 98 testcase6 () 99 Warehouse class 100 / 101 public void testcase6 () { 102 assertequals (12, testwarehouse. getwarehouseid () ) ; 103 assertequals ( name, testwarehouse. getname () ) ; 104 assertequals ( address, testwarehouse. getaddress () ) ; 105 assertequals (34, testwarehouse. getpostalcode () ) ; 106 assertequals ( city, testwarehouse. getcity () ) ; 107 assertequals ( country, testwarehouse. getcountry () ) ; 108 assertequals ( , testwarehouse. get () ) ; 109 } 110 } A.2 Functionality tests 1 2 import junit. framework. TestCase ; 3 import c lasses. ; 4 import java. u t i l. ArrayList ; 5 import java. u t i l. Calendar ; 6 7 / d105a 9 10 getorders functiontest 11 / 12 public cl a ss FunctionTest extends TestCase { private static Object [ ] [ ] orders ; private ArrayList orderlist ; private Order tmporder ;

132 20 private int WAREHOUSE ID = 1; protected void setup () { 23 RMIConnection rmic = new RMIConnection () ; 24 try { 25 orderlist = RMIConnection. d1. getorder (Mainprogram. WAREHOUSE ID) ; 26 } catch ( Exception e ) { 27 } 28 ; 29 } protected void teardown () { 32 } public void testcase1 () { 35 assertequals (9, orderlist. s iz e () ) ; 36 } public void testcase2 () { tmporder = ( Order ) orderlist. get (6) ; 41 assertequals ( Pending, tmporder. getstatus () ) ; 42 assertequals (12, tmporder. getorderid () ) ; 43 Calendar tmpc = Calendar. getinstance () ; 44 tmpc. set (2004, Calendar.DECEMBER, 15) ; 45 assertequals (tmpc. gettime (), tmporder. getcreationdate () ) ; 46 } 47 } 132

133 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, 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

134 B.3.1 Characteristic Range Frequency distribution Age % 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 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

135 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

136 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

137 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

138 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

XTendTraders.com Trading room simulator

XTendTraders.com Trading room simulator 2011 2012 XTendTraders.com Trading room simulator BELGHITI ALAOUI Mohammed IMAFA BEN HAMOUDA Ahmed IMAFA EL FERACHI Anas AL EL HAJJI Khalil AL Polytech Nice Sophia Antipolis SI4 AL/IMAFA 2011 2012 1 CONTENTS

More information

High Level Design Distributed Network Traffic Controller

High Level Design Distributed Network Traffic Controller High Level Design Distributed Network Traffic Controller Revision Number: 1.0 Last date of revision: 2/2/05 22c:198 Johnson, Chadwick Hugh Change Record Revision Date Author Changes 1 Contents 1. Introduction

More information

Web Design and Implementation for Online Registration at University of Diyala

Web Design and Implementation for Online Registration at University of Diyala International Journal of Innovation and Applied Studies ISSN 2028-9324 Vol. 8 No. 1 Sep. 2014, pp. 261-270 2014 Innovative Space of Scientific Research Journals http://www.ijias.issr-journals.org/ Web

More information

SCATS SALES AND CUSTOMER TRACKING SYSTEM SOFTWARE REQUIREMENTS SPECIFICATION VERSION: FINAL 1.0

SCATS SALES AND CUSTOMER TRACKING SYSTEM SOFTWARE REQUIREMENTS SPECIFICATION VERSION: FINAL 1.0 SCATS SALES AND CUSTOMER TRACKING SYSTEM SOFTWARE REQUIREMENTS SPECIFICATION VERSION: FINAL 1.0 OCTOBER 28, 2001 REVISION CHART Version Primary Author(s) Description of Version Date Completed Draft Johnny

More information

International Journal of Engineering Technology, Management and Applied Sciences. www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476

International Journal of Engineering Technology, Management and Applied Sciences. www.ijetmas.com November 2014, Volume 2 Issue 6, ISSN 2349-4476 ERP SYSYTEM Nitika Jain 1 Niriksha 2 1 Student, RKGITW 2 Student, RKGITW Uttar Pradesh Tech. University Uttar Pradesh Tech. University Ghaziabad, U.P., India Ghaziabad, U.P., India ABSTRACT Student ERP

More information

Software Requirement Specification For Flea Market System

Software Requirement Specification For Flea Market System Software Requirement Specification For Flea Market System By Ilya Verlinsky, Alexander Sarkisyan, Ambartsum Keshishyan, Igor Gleyser, Andrey Ishuninov 1 INTRODUCTION 1.1 Purpose 1.1.1 Purpose of SRS document

More information

PROJECT MANAGEMENT SYSTEM

PROJECT MANAGEMENT SYSTEM Requirement Analysis Document v.2 14.12.2009 CENG-401 SOFTWARE ENGINEER PROJECT MANAGEMENT SYSTEM (Project Manager) Ahmet Edip SEÇKİN 07010555 (Developer) Erhan ŞEN 07010507 (Developer) Semih Serdar CENGİZOĞLU

More information

User Guide and Tutorial Central Stores Online Ordering System. Central Stores Financial Services Western Washington University

User Guide and Tutorial Central Stores Online Ordering System. Central Stores Financial Services Western Washington University User Guide and Tutorial Central Stores Online Ordering System Central Stores Financial Services Western Washington University TABLE OF CONTENTS 1. Introduction... Page 3 2. Finding and Logging into Central

More information

Client/server is a network architecture that divides functions into client and server

Client/server is a network architecture that divides functions into client and server Page 1 A. Title Client/Server Technology B. Introduction Client/server is a network architecture that divides functions into client and server subsystems, with standard communication methods to facilitate

More information

THE BCS PROFESSIONAL EXAMINATIONS Certificate in IT. October 2006. Examiners Report. Information Systems

THE BCS PROFESSIONAL EXAMINATIONS Certificate in IT. October 2006. Examiners Report. Information Systems THE BCS PROFESSIONAL EXAMINATIONS Certificate in IT October 2006 Examiners Report Information Systems General Comments The pass rate for Section A was disappointing, being lower than previously. One reason

More information

A Monitored Student Testing Application Using Cloud Computing

A Monitored Student Testing Application Using Cloud Computing A Monitored Student Testing Application Using Cloud Computing R. Mullapudi and G. Hsieh Department of Computer Science, Norfolk State University, Norfolk, Virginia, USA r.mullapudi@spartans.nsu.edu, ghsieh@nsu.edu

More information

Business Process Management with @enterprise

Business Process Management with @enterprise Business Process Management with @enterprise March 2014 Groiss Informatics GmbH 1 Introduction Process orientation enables modern organizations to focus on the valueadding core processes and increase

More information

Sports Management Information Systems. Camilo Rostoker November 22, 2002

Sports Management Information Systems. Camilo Rostoker November 22, 2002 Sports Management Information Systems Camilo Rostoker November 22, 2002 Introduction We are in the information age The availability of technology has brought forth a new problem domain how do we manage

More information

Shopping Cart. Analysis & Design. Author:John Smith P08/22-43. Version:1.7 Status:Draft Publication:23/05/2013 Copyright:Modeliosoft

Shopping Cart. Analysis & Design. Author:John Smith P08/22-43. Version:1.7 Status:Draft Publication:23/05/2013 Copyright:Modeliosoft P08/22-43 Shopping Cart Analysis & Design Author:John Smith Version:1.7 Status:Draft Publication:23/05/2013 Copyright: 21, avenue Victor Hugo, 75016 Paris Table of Contents 1 Introduction... 4 2 Use Cases...

More information

Software Requirements Specification. For. Attendance Tracking System, Release 1.0. Version 1.0

Software Requirements Specification. For. Attendance Tracking System, Release 1.0. Version 1.0 Software Requirements Specification For Attendance Tracking System, Release 1.0 Version 1.0 Prepared by Lee Bell, Graham Kennedy, Jonathan Loudin, Roger Seagle February 9, 2003 Table of Contents Table

More information

CatDV Pro Workgroup Serve r

CatDV Pro Workgroup Serve r Architectural Overview CatDV Pro Workgroup Server Square Box Systems Ltd May 2003 The CatDV Pro client application is a standalone desktop application, providing video logging and media cataloging capability

More information

Software Requirements Specification for POS_Connect Page 1. Software Requirements Specification. for. POS_Connect. Version 1.0

Software Requirements Specification for POS_Connect Page 1. Software Requirements Specification. for. POS_Connect. Version 1.0 Page 1 Software Requirements Specification for POS_Connect Version 1.0 1/9/2013 Page 2 Table of Contents Table of Contents Revision History 1. Introduction 1.1 Purpose 1.2 Document Conventions 1.3 Intended

More information

Design Approaches of Web Application with Efficient Performance in JAVA

Design Approaches of Web Application with Efficient Performance in JAVA IJCSNS International Journal of Computer Science and Network Security, VOL.11 No.7, July 2011 141 Design Approaches of Web Application with Efficient Performance in JAVA OhSoo Kwon and HyeJa Bang Dept

More information

Deploying Oracle Business Intelligence Publisher in J2EE Application Servers Release 10.1.3.2.0

Deploying Oracle Business Intelligence Publisher in J2EE Application Servers Release 10.1.3.2.0 Oracle Business Intelligence Publisher Deploying Oracle Business Intelligence Publisher in J2EE Application Servers Release 10.1.3.2.0 Part No. B32481-01 December 2006 Introduction Oracle BI Publisher

More information

E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones.

E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones. E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones Introduction E-Commerce Supply Chain Management involves the co-ordination

More information

Software Requirements Specification For Real Estate Web Site

Software Requirements Specification For Real Estate Web Site Software Requirements Specification For Real Estate Web Site Brent Cross 7 February 2011 Page 1 Table of Contents 1. Introduction...3 1.1. Purpose...3 1.2. Scope...3 1.3. Definitions, Acronyms, and Abbreviations...3

More information

AAUAv's HelpDesk Noddy's Friends Iteration 2: Initial Design and Project Plan

AAUAv's HelpDesk Noddy's Friends Iteration 2: Initial Design and Project Plan AAUAv's HelpDesk Iteration 2: Initial Design and Project Plan David Campos, Hugo Picado, Luis Ribeiro, Pedro Alves david.campos@ua.pt, hugopicado@ua.pt, luisribeiro@ua.pt, pcalves@ua.pt 1 Overview This

More information

Create e-commerce website Opencart. Prepared by : Reth Chantharoth Facebook : https://www.facebook.com/tharothchan.ubee E-mail : rtharoth@yahoo.

Create e-commerce website Opencart. Prepared by : Reth Chantharoth Facebook : https://www.facebook.com/tharothchan.ubee E-mail : rtharoth@yahoo. Create e-commerce website Opencart Prepared by : Reth Chantharoth Facebook : https://www.facebook.com/tharothchan.ubee E-mail : rtharoth@yahoo.com Create e-commerce website Opencart What is opencart? Opencart

More information

Building Java Servlets with Oracle JDeveloper

Building Java Servlets with Oracle JDeveloper Building Java Servlets with Oracle JDeveloper Chris Schalk Oracle Corporation Introduction Developers today face a formidable task. They need to create large, distributed business applications. The actual

More information

Software Architecture Document

Software Architecture Document Software Architecture Document Project Management Cell 1.0 1 of 16 Abstract: This is a software architecture document for Project Management(PM ) cell. It identifies and explains important architectural

More information

Multifunctional Barcode Inventory System for Retailing. Are You Ready for It?

Multifunctional Barcode Inventory System for Retailing. Are You Ready for It? Multifunctional Barcode Inventory System for Retailing. Are You Ready for It? Ling Shi Cai, Leau Yu Beng, Charlie Albert Lasuin, Tan Soo Fun, Chin Pei Yee Abstract This paper explains the development of

More information

GLOB@L LIBRARIES - BULGARIA PROGRAM. Terms of Reference

GLOB@L LIBRARIES - BULGARIA PROGRAM. Terms of Reference GLOB@L LIBRARIES - BULGARIA PROGRAM Terms of Reference Position: Web Design Consultant (WDC) Timeframe: Up to 6 months based on interim outcomes I. BACKGROUND INFORMATION The Glob@l Libraries Bulgaria

More information

TDDC88 Lab 2 Unified Modeling Language (UML)

TDDC88 Lab 2 Unified Modeling Language (UML) TDDC88 Lab 2 Unified Modeling Language (UML) Introduction What is UML? Unified Modeling Language (UML) is a collection of graphical notations, which are defined using a single meta-model. UML can be used

More information

ENTERPRISE DATA WAREHOUSE PRODUCT PERFORMANCE REPORTS USER GUIDE EXTERNAL. Version: 1.0

ENTERPRISE DATA WAREHOUSE PRODUCT PERFORMANCE REPORTS USER GUIDE EXTERNAL. Version: 1.0 ENTERPRISE DATA WAREHOUSE PRODUCT PERFORMANCE REPORTS USER GUIDE EXTERNAL Version: 1.0 September 2004 Table of Contents 1.0 OVERVIEW...1 1.1 Product Performance Overview... 1 1.2 Enterprise Data Warehouse

More information

StreamServe Persuasion SP5 StreamStudio

StreamServe Persuasion SP5 StreamStudio StreamServe Persuasion SP5 StreamStudio Administrator s Guide Rev B StreamServe Persuasion SP5 StreamStudio Administrator s Guide Rev B OPEN TEXT CORPORATION ALL RIGHTS RESERVED United States and other

More information

026-1010 Rev 7 06-OCT-2011. Site Manager Installation Guide

026-1010 Rev 7 06-OCT-2011. Site Manager Installation Guide 026-1010 Rev 7 06-OCT-2011 Site Manager Installation Guide Retail Solutions 3240 Town Point Drive NW, Suite 100 Kennesaw, GA 30144, USA Phone: 770-425-2724 Fax: 770-425-9319 Table of Contents 1 SERVER

More information

1. Introduction 1.1 Methodology

1. Introduction 1.1 Methodology Table of Contents 1. Introduction 1.1 Methodology 3 1.2 Purpose 4 1.3 Scope 4 1.4 Definitions, Acronyms and Abbreviations 5 1.5 Tools Used 6 1.6 References 7 1.7 Technologies to be used 7 1.8 Overview

More information

The Dentist Online Reservation System Design and Implementation Web Based Application and Database Management System Project

The Dentist Online Reservation System Design and Implementation Web Based Application and Database Management System Project 2012 International Conference on Education Technology and Computer (ICETC2012) IPCSIT vol.43 (2012) (2012) IACSIT Press, Singapore The Dentist Online Reservation System Design and Implementation Web Based

More information

DOCUMENTING USE CASES

DOCUMENTING USE CASES Chapter 7 DOCUMENTING USE CASES There is a lot of documentation associated with Use Cases that needs to be organized somehow. You want the documentation to be understandable, but you need other things

More information

Online College Magazine

Online College Magazine Software Requirement Specification Chennai Campus Vandalur-Kelambakkam Road, Chennai 600048 Ciphers Online College Magazine IBM TGMC-2011 Version 1.0 Team Members : Mentor: Prof. B. Sathis Kumar 1. Aanchal

More information

Richmond Systems. SupportDesk Web Interface User Guide

Richmond Systems. SupportDesk Web Interface User Guide Richmond Systems SupportDesk Web Interface User Guide 1 Contents SUPPORTDESK WEB INTERFACE...3 INTRODUCTION TO THE WEB INTERFACE...3 FEATURES OF THE WEB INTERFACE...3 HELPDESK SPECIALIST LOGIN...4 SEARCHING

More information

Eclectic Computing. Time Tracking Tool Software Architecture Document. Version <1.3>

Eclectic Computing. Time Tracking Tool Software Architecture Document. Version <1.3> Eclectic Computing Time Tracking Tool Version Revision History Date Version Description Author 7/Mar/05 1.0 Documentation of high-level architecture. David Janzen 7/Apr/05 1.1 Architecture at end

More information

User Manual for Web. Help Desk Authority 9.0

User Manual for Web. Help Desk Authority 9.0 User Manual for Web Help Desk Authority 9.0 2011ScriptLogic Corporation ALL RIGHTS RESERVED. ScriptLogic, the ScriptLogic logo and Point,Click,Done! are trademarks and registered trademarks of ScriptLogic

More information

Graphical Web based Tool for Generating Query from Star Schema

Graphical Web based Tool for Generating Query from Star Schema Graphical Web based Tool for Generating Query from Star Schema Mohammed Anbar a, Ku Ruhana Ku-Mahamud b a College of Arts and Sciences Universiti Utara Malaysia, 0600 Sintok, Kedah, Malaysia Tel: 604-2449604

More information

ERP guide and questions

ERP guide and questions Scandiweb ERP guide and questions Sometimes client asks you a short questions - how much would cost integration of customers ERP? And sometimes they provide some data on objects to be imported e.g. products,

More information

Communiqué 4. Standardized Global Content Management. Designed for World s Leading Enterprises. Industry Leading Products & Platform

Communiqué 4. Standardized Global Content Management. Designed for World s Leading Enterprises. Industry Leading Products & Platform Communiqué 4 Standardized Communiqué 4 - fully implementing the JCR (JSR 170) Content Repository Standard, managing digital business information, applications and processes through the web. Communiqué

More information

Category: Business Process and Integration Solution for Small Business and the Enterprise

Category: Business Process and Integration Solution for Small Business and the Enterprise Home About us Contact us Careers Online Resources Site Map Products Demo Center Support Customers Resources News Download Article in PDF Version Download Diagrams in PDF Version Microsoft Partner Conference

More information

WebSphere Commerce and Sterling Commerce

WebSphere Commerce and Sterling Commerce WebSphere Commerce and Sterling Commerce Inventory and order integration This presentation introduces WebSphere Commerce and Sterling Commerce inventory and order integration. Order_Inventory_Integration.ppt

More information

Business Application Services Testing

Business Application Services Testing Business Application Services Testing Curriculum Structure Course name Duration(days) Express 2 Testing Concept and methodologies 3 Introduction to Performance Testing 3 Web Testing 2 QTP 5 SQL 5 Load

More information

ecommerce User Guide LS Nav 2013 (7.1) Copyright 2014, LS Retail ehf. All rights reserved. All trademarks belong to their respective holders

ecommerce User Guide LS Nav 2013 (7.1) Copyright 2014, LS Retail ehf. All rights reserved. All trademarks belong to their respective holders ecommerce User Guide LS Nav 2013 (7.1) Copyright 2014, LS Retail ehf. All rights reserved. All trademarks belong to their respective holders Contents 1 Introduction... 1 1.1 System Requirements... 2 2

More information

Installing Management Applications on VNX for File

Installing Management Applications on VNX for File EMC VNX Series Release 8.1 Installing Management Applications on VNX for File P/N 300-015-111 Rev 01 EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103 1-508-435-1000 www.emc.com Copyright

More information

MS SQL Server DBA Training Course. Table of Contents

MS SQL Server DBA Training Course. Table of Contents Table of Contents Overview... 4 About DBA University, Inc.... 4 Malathy Mani Microsoft Certified Solutions Expert (MCSA)... 5 Pricing and Registration... 5 Course Duration and Timings... 5 Sunday, Monday,

More information

WHITE PAPER. Domo Advanced Architecture

WHITE PAPER. Domo Advanced Architecture WHITE PAPER Domo Advanced Architecture Overview There are several questions that any architect or technology advisor may ask about a new system during the evaluation process: How will it fit into our organization

More information

Web Presentation Layer Architecture

Web Presentation Layer Architecture Chapter 4 Web Presentation Layer Architecture In this chapter we provide a discussion of important current approaches to web interface programming based on the Model 2 architecture [59]. From the results

More information

Web Development on the SOEN 6011 Server

Web Development on the SOEN 6011 Server Web Development on the SOEN 6011 Server Stephen Barret October 30, 2007 Introduction Systems structured around Fowler s patterns of Enterprise Application Architecture (EAA) require a multi-tiered environment

More information

SHOPPING APPLICATION FOR E-COMMERCE

SHOPPING APPLICATION FOR E-COMMERCE ABSTRACT: SHOPPING APPLICATION FOR E-COMMERCE Rohini V, Ancy Merlyn D Souza, Sachin Giriyappanavar, Sharun Mathew Department of Computer Science, Christ University, Bengaluru E-commerce is an alternative

More information

Warehouse R x Inventory Management Software. Technical Overview

Warehouse R x Inventory Management Software. Technical Overview Warehouse R x Inventory Management Software Technical Overview January 19, 2009 System Overview Warehouse R X is the latest version of Daifuku America s Warehouse Control System (WCS) software. It provides

More information

Japan Communication India Skill Development Center

Japan Communication India Skill Development Center Japan Communication India Skill Development Center Java Application System Developer Course Detail Track 1B Java Application Software Developer: Phase1 DBMS Concept 20 Entities Relationships Attributes

More information

Identikey Server Windows Installation Guide 3.1

Identikey Server Windows Installation Guide 3.1 Identikey Server Windows Installation Guide 3.1 Disclaimer of Warranties and Limitations of Liabilities Disclaimer of Warranties and Limitations of Liabilities The Product is provided on an 'as is' basis,

More information

Web Hosting Features. Small Office Premium. Small Office. Basic Premium. Enterprise. Basic. General

Web Hosting Features. Small Office Premium. Small Office. Basic Premium. Enterprise. Basic. General General Basic Basic Small Office Small Office Enterprise Enterprise RAID Web Storage 200 MB 1.5 MB 3 GB 6 GB 12 GB 42 GB Web Transfer Limit 36 GB 192 GB 288 GB 480 GB 960 GB 1200 GB Mail boxes 0 23 30

More information

OCR LEVEL 3 CAMBRIDGE TECHNICAL

OCR LEVEL 3 CAMBRIDGE TECHNICAL Cambridge TECHNICALS OCR LEVEL 3 CAMBRIDGE TECHNICAL CERTIFICATE/DIPLOMA IN IT WEB SERVER SCRIPTING A/601/0443 LEVEL 3 UNIT 26 GUIDED LEARNING HOURS: 60 UNIT CREDIT VALUE: 10 WEB SERVER SCRIPTING A/601/0443

More information

An Electronic Journal Management System

An Electronic Journal Management System An Electronic Journal Management System Hrvoje Bogunović, Edgar Pek, Sven Lončarić and Vedran Mornar Faculty of Electrical Engineering and Computing, University of Zagreb Unska 3, 0000 Zagreb, Croatia

More information

Cafeteria Management System

Cafeteria Management System Cafeteria Management System by E3-111 {} {} {} {} {~ ~ ~ ~ ~ ~ ~ ~ ~ ~} { ~ ~ C A K E ~ ~ } { } {\/\/\/\/\/\/\/\/\/\/\/\/\} { C a f e t e r i a } {\/\/\/\/\/\/\/\/\/\/\/\/\} { } {\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\}

More information

THE BCS PROFESSIONAL EXAMINATIONS Diploma. April 2006 EXAMINERS REPORT. Systems Design

THE BCS PROFESSIONAL EXAMINATIONS Diploma. April 2006 EXAMINERS REPORT. Systems Design THE BCS PROFESSIONAL EXAMINATIONS Diploma April 2006 EXAMINERS REPORT Systems Design Question. a) Write a BRIEF explanation of the purpose of TWO of the following UML diagrams as used in Object- Oriented

More information

IBM Rational Web Developer for WebSphere Software Version 6.0

IBM Rational Web Developer for WebSphere Software Version 6.0 Rapidly build, test and deploy Web, Web services and Java applications with an IDE that is easy to learn and use IBM Rational Web Developer for WebSphere Software Version 6.0 Highlights Accelerate Web,

More information

Adding Web 2.0 features to a Fleet Monitoring Dashboard

Adding Web 2.0 features to a Fleet Monitoring Dashboard SpaceOps 2010 ConferenceDelivering on the DreamHosted by NASA Mars 25-30 April 2010, Huntsville, Alabama AIAA 2010-2249 Adding Web 2.0 features to a Fleet Monitoring Dashboard

More information

Software Requirements Specification. Task Management System. for. Prepared by. Version 1.0. Group Name: Pink and Purple. Date:

Software Requirements Specification. Task Management System. for. Prepared by. Version 1.0. Group Name: Pink and Purple. Date: Software Requirements Specification for Task Management System Version 1.0 Prepared by Group Name: Pink and Purple Kathrynn Gonzalez 11387240 kathrynn.gonzalez@gmail.com Tina Roper 11380457 troper17@comcast.net

More information

Critical Infrastructure Protection in the National Capital Region

Critical Infrastructure Protection in the National Capital Region Critical Infrastructure Protection in the National Capital Region Risk-Based Foundations for Resilience and Sustainability Final Report, Volume 10: A Database and Architecture for Comparing Vulnerability

More information

Chapter 5. Regression Testing of Web-Components

Chapter 5. Regression Testing of Web-Components Chapter 5 Regression Testing of Web-Components With emergence of services and information over the internet and intranet, Web sites have become complex. Web components and their underlying parts are evolving

More information

Richmond SupportDesk Web Reports Module For Richmond SupportDesk v6.72. User Guide

Richmond SupportDesk Web Reports Module For Richmond SupportDesk v6.72. User Guide Richmond SupportDesk Web Reports Module For Richmond SupportDesk v6.72 User Guide Contents 1 Introduction... 4 2 Requirements... 5 3 Important Note for Customers Upgrading... 5 4 Installing the Web Reports

More information

Quick Reference Guide: Shared Hosting

Quick Reference Guide: Shared Hosting : Shared Hosting TABLE OF CONTENTS GENERAL INFORMATION...2 WEB SERVER PLATFORM SPECIFIC INFORMATION...2 WEBSITE TRAFFIC ANALYSIS TOOLS...3 DETAILED STEPS ON HOW TO PUBLISH YOUR WEBSITE...6 FREQUENTLY ASKED

More information

Getting Started Guide

Getting Started Guide Getting Started Guide Operations Center 5.0 March 3, 2014 Legal Notices THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE AGREEMENT

More information

How To Set Up Total Recall Web On A Microsoft Memorybook 2.5.2.2 (For A Microtron)

How To Set Up Total Recall Web On A Microsoft Memorybook 2.5.2.2 (For A Microtron) Total Recall Web Web Module Manual and Customer Quick Reference Guides COPYRIGHT NOTICE Copyright 1994-2009 by DHS Associates, Inc. All Rights Reserved. All TOTAL RECALL, TOTAL RECALL SQL, TOTAL RECALL

More information

Modeling Web Applications Using Java And XML Related Technologies

Modeling Web Applications Using Java And XML Related Technologies Modeling Web Applications Using Java And XML Related Technologies Sam Chung Computing & Stware Systems Institute Technology University Washington Tacoma Tacoma, WA 98402. USA chungsa@u.washington.edu Yun-Sik

More information

Enterprise Service Bus

Enterprise Service Bus We tested: Talend ESB 5.2.1 Enterprise Service Bus Dr. Götz Güttich Talend Enterprise Service Bus 5.2.1 is an open source, modular solution that allows enterprises to integrate existing or new applications

More information

EMC Documentum Content Services for SAP iviews for Related Content

EMC Documentum Content Services for SAP iviews for Related Content EMC Documentum Content Services for SAP iviews for Related Content Version 6.0 Administration Guide P/N 300 005 446 Rev A01 EMC Corporation Corporate Headquarters: Hopkinton, MA 01748 9103 1 508 435 1000

More information

Exploiting Key Answers from Your Data Warehouse Using SAS Enterprise Reporter Software

Exploiting Key Answers from Your Data Warehouse Using SAS Enterprise Reporter Software Exploiting Key Answers from Your Data Warehouse Using SAS Enterprise Reporter Software Donna Torrence, SAS Institute Inc., Cary, North Carolina Juli Staub Perry, SAS Institute Inc., Cary, North Carolina

More information

DeskNow. Ventia Pty. Ltd. Advanced setup. Version : 3.2 Date : 4 January 2007

DeskNow. Ventia Pty. Ltd. Advanced setup. Version : 3.2 Date : 4 January 2007 Ventia Pty. Ltd. DeskNow Advanced setup Version : 3.2 Date : 4 January 2007 Ventia Pty Limited A.C.N. 090 873 662 Web : http://www.desknow.com Email : info@desknow.com Overview DeskNow is a computing platform

More information

BUILDING OLAP TOOLS OVER LARGE DATABASES

BUILDING OLAP TOOLS OVER LARGE DATABASES BUILDING OLAP TOOLS OVER LARGE DATABASES Rui Oliveira, Jorge Bernardino ISEC Instituto Superior de Engenharia de Coimbra, Polytechnic Institute of Coimbra Quinta da Nora, Rua Pedro Nunes, P-3030-199 Coimbra,

More information

Getting Things Done: Practical Web/e-Commerce Application Stress Testing

Getting Things Done: Practical Web/e-Commerce Application Stress Testing Getting Things Done: Practical Web/e-Commerce Application Stress Testing Robert Sabourin President Montreal, Canada rsabourin@amibug.com Slide 1 Practical Web/e-Commerce Application Stress Testing Overview:

More information

SOFTWARE ARCHITECTURE FOR FIJI NATIONAL UNIVERSITY CAMPUS INFORMATION SYSTEMS

SOFTWARE ARCHITECTURE FOR FIJI NATIONAL UNIVERSITY CAMPUS INFORMATION SYSTEMS SOFTWARE ARCHITECTURE FOR FIJI NATIONAL UNIVERSITY CAMPUS INFORMATION SYSTEMS Bimal Aklesh Kumar Department of Computer Science and Information Systems Fiji National University Fiji Islands bimal.kumar@fnu.ac.fj

More information

VOL. 2, NO. 1, January 2012 ISSN 2225-7217 ARPN Journal of Science and Technology 2010-2012 ARPN Journals. All rights reserved

VOL. 2, NO. 1, January 2012 ISSN 2225-7217 ARPN Journal of Science and Technology 2010-2012 ARPN Journals. All rights reserved Mobile Application for News and Interactive Services L. Ashwin Kumar Department of Information Technology, JNTU, Hyderabad, India loka.ashwin@gmail.com ABSTRACT In this paper, we describe the design and

More information

Novell ZENworks Asset Management 7.5

Novell ZENworks Asset Management 7.5 Novell ZENworks Asset Management 7.5 w w w. n o v e l l. c o m October 2006 USING THE WEB CONSOLE Table Of Contents Getting Started with ZENworks Asset Management Web Console... 1 How to Get Started...

More information

Sample copy. Introduction To WebLogic Server Property of Web 10.3 Age Solutions Inc.

Sample copy. Introduction To WebLogic Server Property of Web 10.3 Age Solutions Inc. Introduction To WebLogic Server Property of Web 10.3 Age Solutions Inc. Objectives At the end of this chapter, participants should be able to: Understand basic WebLogic Server architecture Understand the

More information

MBARI Deep Sea Guide: Designing a web interface that represents information about the Monterey Bay deep-sea world.

MBARI Deep Sea Guide: Designing a web interface that represents information about the Monterey Bay deep-sea world. MBARI Deep Sea Guide: Designing a web interface that represents information about the Monterey Bay deep-sea world. Pierre Venuat, University of Poitiers Mentors: Brian Schlining and Nancy Jacobsen Stout

More information

Oracle Service Bus Examples and Tutorials

Oracle Service Bus Examples and Tutorials March 2011 Contents 1 Oracle Service Bus Examples... 2 2 Introduction to the Oracle Service Bus Tutorials... 5 3 Getting Started with the Oracle Service Bus Tutorials... 12 4 Tutorial 1. Routing a Loan

More information

Online Enrollment and Administration System

Online Enrollment and Administration System FYP Proposal Report Real World Database Development by Kong Koon Kit Chan Yin Mo Leung Shiu Hong Advised by Prof. Frederick H. Lochovsky Submitted in partial fulfillment of the requirements for COMP 4981

More information

ONLINE ORDERING BOOK SYSTEM: A CASE STUDY IN MALAYSIA HIGHER INSTITUTE

ONLINE ORDERING BOOK SYSTEM: A CASE STUDY IN MALAYSIA HIGHER INSTITUTE ONLINE ORDERING BOOK SYSTEM: A CASE STUDY IN MALAYSIA HIGHER INSTITUTE Zainab Othman 1 Mazliana Hasnan 2 Norlena Hasnan 3 1,2 Universiti Teknologi Mara, Melaka, Malaysia 3 Universiti Utara Malaysia Kuala

More information

CHAPTER 20 TESING WEB APPLICATIONS. Overview

CHAPTER 20 TESING WEB APPLICATIONS. Overview CHAPTER 20 TESING WEB APPLICATIONS Overview The chapter describes the Web testing. Web testing is a collection of activities whose purpose is to uncover errors in WebApp content, function, usability, navigability,

More information

Getting Started using the SQuirreL SQL Client

Getting Started using the SQuirreL SQL Client Getting Started using the SQuirreL SQL Client The SQuirreL SQL Client is a graphical program written in the Java programming language that will allow you to view the structure of a JDBC-compliant database,

More information

Equipment Room Database and Web-Based Inventory Management

Equipment Room Database and Web-Based Inventory Management Equipment Room Database and Web-Based Inventory Management Project Proposal Sean M. DonCarlos Ryan Learned Advisors: Dr. James H. Irwin Dr. Aleksander Malinowski December 12, 2002 TABLE OF CONTENTS Project

More information

Remedy ITSM Service Request Management Quick Start Guide

Remedy ITSM Service Request Management Quick Start Guide Remedy ITSM Service Request Management Quick Start Guide Table of Contents 1.0 Getting Started With Remedy s Service Request Management. 3 2.0 Submitting a Service Request.7 3.0 Updating a Service Request

More information

E-commerce. business. technology. society. Kenneth C. Laudon Carol Guercio Traver. Third Edition. Copyright 2007 Pearson Education, Inc.

E-commerce. business. technology. society. Kenneth C. Laudon Carol Guercio Traver. Third Edition. Copyright 2007 Pearson Education, Inc. Copyright 2007 Pearson Education, Inc. Slide 4-1 E-commerce business. technology. society. Third Edition Kenneth C. Laudon Carol Guercio Traver Copyright 2007 Pearson Education, Inc. Slide 4-2 Chapter

More information

Web-based Automobile Sales Management System. Huabo Xiao

Web-based Automobile Sales Management System. Huabo Xiao 3rd International Conference on Management, Education, Information and Control (MEICI 2015) Web-based Automobile Sales Management System Huabo Xiao College of Information Engineering, Jiangxi University

More information

Web Application Development Using UML

Web Application Development Using UML Web Application Development Using UML Dilip Kothamasu West Chester University West Chester, PA - 19382 dk603365@wcupa.edu Zhen Jiang Department of Computer Science Information Assurance Center West Chester

More information

3-Tier Architecture. 3-Tier Architecture. Prepared By. Channu Kambalyal. Page 1 of 19

3-Tier Architecture. 3-Tier Architecture. Prepared By. Channu Kambalyal. Page 1 of 19 3-Tier Architecture Prepared By Channu Kambalyal Page 1 of 19 Table of Contents 1.0 Traditional Host Systems... 3 2.0 Distributed Systems... 4 3.0 Client/Server Model... 5 4.0 Distributed Client/Server

More information

Web Design Specialist

Web Design Specialist UKWDA Training: CIW Web Design Series Web Design Specialist Course Description CIW Web Design Specialist is for those who want to develop the skills to specialise in website design and builds upon existing

More information

Electronic Commerce Engineering

Electronic Commerce Engineering 219322 Electronic Commerce Engineering Lecture 4 Laudon & Traver: Chapter 4 Building an E-commerce Web Site Copyright 2007 Pearson Education, Inc. Slide 4-1 Building an E-commerce Site: A Systematic Approach

More information

InfoPrint isupplier Portal Training

InfoPrint isupplier Portal Training InfoPrint isupplier Portal Training After Completion of this Course, you should be able to: Understand InfoPrint isupplier Process Overview Understand isupplier Portal On boarding Process Access isupplier

More information

Maximizing ROI on Test and Durability

Maximizing ROI on Test and Durability Maximizing ROI on Test and Durability Product Details Product Overview: ncode Automation is a complete environment for automated data storage, analysis and reporting. It also provides a web-based collaborative

More information

Oracle WebLogic Server 11g: Administration Essentials

Oracle WebLogic Server 11g: Administration Essentials Oracle University Contact Us: 1.800.529.0165 Oracle WebLogic Server 11g: Administration Essentials Duration: 5 Days What you will learn This Oracle WebLogic Server 11g: Administration Essentials training

More information

Outline. CIW Web Design Specialist. Course Content

Outline. CIW Web Design Specialist. Course Content CIW Web Design Specialist Description The Web Design Specialist course (formerly titled Design Methodology and Technology) teaches you how to design and publish Web sites. General topics include Web Site

More information

B.Sc (Computer Science) Database Management Systems UNIT-V

B.Sc (Computer Science) Database Management Systems UNIT-V 1 B.Sc (Computer Science) Database Management Systems UNIT-V Business Intelligence? Business intelligence is a term used to describe a comprehensive cohesive and integrated set of tools and process used

More information

Application of MVC Platform in Bank E-CRM

Application of MVC Platform in Bank E-CRM Application of MVC Platform in Bank E-CRM Liancai Hao (School of Management, Harbin Institute of Technology, Harbin P. R. China 150001) Haolc@hit.edu.cn Abstract Customer relationship management (CRM)

More information