Create an online catalogue system that specialises in children's toys and enables users to search for specific products.
CHAPTER 1
INTRODUCTION
.0 Introduction
This report presents work conducted for the final year dissertation based on the design and develop of an e-commerce web site, as partial fulfilment of the BSc Honours Computer Science Degree at the university of Hertfordshire.
Toyland is an e-commerce web site, which specialises in selling children's toys.
.1 Project Motivation
Factors, which motivated me to produce this project, were mainly due to my interest in database driven web sites.
I had no prior knowledge of any web design languages such as HyperText Markup Language (HTML) which was the primary language used to create the front end for the system.
At the commencement of the project I was familiar with object oriented methodology such as Unified Modelling Language (UML), used to describe and model the intended system at various stages of the project life- cycle.
Further research had to be carried on PHP and MySQL in order to learn how to implement the link between the back-end database and the front-end. This would enable data to be queried through the web-site. Due to my lack of knowledge in these areas, the project posed as a challenge, as well as a new learning experience.
.2 Aims
The aim of this project is to create an online catalogue system that specialises in children's toys and enables users to search for specific products.
.3 Core Objectives
The objectives of this project are
* To analyse the company's system requirements
* To produce a design for the system using a selected object-oriented methodology.
* Learn PHP and use this to link the database to the front end web site.
* Evaluate the final system
.4 Advanced Objectives
In addition to the core objectives the advanced objectives were identified as
* Addition of help files on the interface application
* To create a mechanism from which customers can give feedback on the web site.
* To implement further categories on the web site so that different types of products can be sold.
.5 Report Structure
The report consists of the following chapters and each has been summarised as below.
Chapter 2
This chapter discusses the use of product life cycle models and they can be applied to the project, in order to identify the process of creating the whole system.
Chapter 3
The chapter aims to identify the user and the scope of the system as well as discussing the techniques employed to conduct the requirements phase. A description of the intended system is also included stating which types of software will be used to implement the system in.
Chapter 4
Chapter four will describe the steps taken to design and implement the database, which will be used as the backend of the system. The client/server architecture is also discussed as well as how and what data will be stored in the database.
Chapter 5
This chapter presents the HCI issues and design principles that need to be considered when designing the web site. Here the implementation of the system is discussed and the use of PHP is explained to link the database and front end with the apache server.
Chapter 6
This chapter will cover the issues of security and how the system was designed to overcome them.
Chapter 7
This chapter presents the type of evaluation carried out on the system once it had been successfully produced, so that flaws or problems in the design and implementation could be uncovered.
Chapter 8
Evaluation of the complete project in terms of objectives being met, methodology undertaken and how well the project was managed will be discussed. This final chapter also presents a critical conclusion for how the project could be improved.
CHAPTER 2
PROJECT LIFECYCLE
2.0 The Project Life-Cycle
In this chapter, the aim is to investigate different approaches for describing the steps of the project life-cycle.
" Once the need for a product has been established the product goes through a series of development phases .... The series of these steps .... Is called the life - cycle model" (Schach, 1999)
After extensively researching the different life cycle models which could be put into practice for this project the following two were decided as most relevant to this project.
* The Waterfall life-cycle Model
* Evolutionary Prototyping
2.1 The Waterfall life-cycle Model
The waterfall model first introduced by Royce 1970 is one of the most widely used life- cycle models.
Figure 2.1: Stages of the Waterfall Model (www.cs.nott.ac.uk, 2002)
The waterfall model is a document driven model where at the end of each stage a document can be produced, i.e. specification document, code document etc. These documents make product maintenance easier (Schach ,1970).
The waterfall approach allows project completion times to be forecasted with more confidence ( Hughes and Cotterell, 2002). However a major weakness of the model is that there is a considerable difference between the written specification document and the actual artefact. This does not ensure that the clients real needs are being met ( Schach, 1970).
By applying the waterfall method, it would enable me to divide the project into smaller tasks, making them more manageable so that progress on the project can be monitored. The documents produced at the end of each stage can be used as well defined deliverables to be included in the report.
2.2 Evolutionary Prototyping
The evolutionary prototyping model is based on the idea of developing an initial implementation, exposing this to user comment and refining this through repeated stages until an adequate system has been developed (Bell 2000)
Due to the lower frequency of systems meting customer requirements, evolutionary prototyping has become a possible software development model (Carter et al). The diagram below shows a general evolutionary prototyping model
The evolutionary prototyping model is based on the idea of developing an initial implementation and refining this through repeated stages until an adequate system has been developed (Bell, 2000). The stages of evolutionary prototyping are as follows:
Figure 2.2 The Evolutionary Prototyping Model (Dr Greer. D,
2.3 Summary of Investigation
The methodology adopted for this project is the evolutionary prototyping method. Evolutionary ...
This is a preview of the whole essay
Due to the lower frequency of systems meting customer requirements, evolutionary prototyping has become a possible software development model (Carter et al). The diagram below shows a general evolutionary prototyping model
The evolutionary prototyping model is based on the idea of developing an initial implementation and refining this through repeated stages until an adequate system has been developed (Bell, 2000). The stages of evolutionary prototyping are as follows:
Figure 2.2 The Evolutionary Prototyping Model (Dr Greer. D,
2.3 Summary of Investigation
The methodology adopted for this project is the evolutionary prototyping method. Evolutionary prototyping has the several benefits over the waterfall model which make it easier to apply to this project, as discussed below:
* A prototype gives a clear picture of what the system will look like and what it will do.
* This enables the developer to cope with the lack of clarity in the requirements.
* Systems are developed faster.
* Development effort is reduced because the final system is the right system.
* Maintenance is reduced because the system meets the users needs
(Bell 2000)
Due to the lack of clarity of user requirements and the tight deadlines the evolutionary model is better suited for this project.
CHAPTER 3
REQUIREMENTS ANALYSIS
3. 0 Requirements Phase
In order to implement the intended system successfully, this project must firstly aim to understand the user and system requirements. An appropriate requirements engineering technique will help elicit the implied needs the system should satisfy.
3.1 The Intended System
The purpose of this project is to build a web site for an online shopping catalogue which specialises in selling toys. The web site should allow users to search the online catalogue so that they can retrieve specific product information which they require. The search facility enables users to browse the whole system quickly and efficiently.
3.2 The User
It is important to specify the audience for who the web site is being developed so that it is designed to support the users characteristics. The users of this web site do not have specific characteristics and so the system must be generalised and easy to use. The online catalogue site is aimed at people wishing to actually purchase products and so it is expected that the users are old enough to possess a credit card, as this is the method of payment on the site.
3.3 Capturing the Scope
The online catalogue site will contain groups of information which the customer requires. It is important to identify the function of each category of information appearing on the site.
The categories which appear on the site are as listed below
* Dolls and Teddy's
* Cars
* Board Games
* Electronic games
The customer can select any of the above categories but only one at a time. From here the user is able to view the products within this category. Product information will include a picture, a brief description and a price. There will be an option to enter the quantity required and to add the item to the shopping basket. Customers can view the contents of their shopping basket at any time during their online shopping trip.
Customers also have a personal account which stores their personal details so that delivery details do not have to be entered again. This is done by giving the customer a unique customer number which when entered retrieves the data required from the system database.
3.4 UML Diagrams
An approach will be selected for practical use to gather all the system requirements.
The intended system will be designed using Unified Modelling Language (UML) diagrams. UML is an object oriented approach whereby the business domain can be reflected in a natural way ( Eriksson and Penker, 1998)
UML diagrams will be used to capture the requirements for the system. The following UML diagrams were used
* Use Case Modelling - Use case diagrams illustrate the behavioural model of the system and describes the possible system interactions which external agents may have with the system ( Maciaszek 2001). Please refer to Appendix ?
* Activity Diagram - These diagrams are used to describe activities performed in an operation. An activity diagram consists of action states, which contain an action to be performed. Decisions, conditions and the execution of all action states, are shown in the diagram (Eriksson and Penker, 1998) Please refer to Appendix ?
* Class Diagram - A class diagram shows the static structure of classes which exist in the system. The diagram also illustrates the relationships which exist between the classes, such associations, operations, and generalizations (Eriksson and Penker, 1998). Please refer to Appendix ?
* State Diagram - A state diagram shows all the possible states which an object of a class can have. They also illustrate how events can change particular states. State diagrams are only drawn for classes where the states are well defined and the behaviour of the class is changed by the different states (Eriksson and Penker, 1998). Please refer to Appendix ?
3.5 Final System Requirements
After producing the above UML diagrams, the final user requirements have been defined for the system :
* The customer connects to the web site via the internet connection on their PC and go to the TOYLAND web page.
* If the customer is already a member they can login or alternatively browse the catalogue without being a member.
* An option is available for the customer to create a personal account online, by filling out the registration form.
* The customer may wish to browse items in the catalogue by either searching through the categories or typing a word into the search. The search results are shown and the product information displayed is a product name, product picture, a brief description and a price.
* If the customer intends to buy the item, they select the item they wish to purchase and add this to their basket. The customer must also specify the quantity of the item.
* To place the order, the customer must authorise their details. New customers have to create an account before they can purchase any of the products. Customers who are already members type in their unique customer number. The system displays the customers details.
* Once the delivery details have been entered the customer can proceed to the checkout and enter their credit card details.
* The transaction is authorised and the customer is given an order number and the details are emailed to the customer.
* The warehouse ships the goods to the customer.
The underlining structure for the above requirements came from Maciaszek 2001 (page number 48) with addition to extra requirements I deduced from the use case specification.
3.6 Choice of Software
This section will focus on the different types of software available which can be used to create the system. This will be broken down into three separate parts to discuss the relevant software which can be used in each area, in order to produce an effective working system.
The Web site (Front-End)
HTML (HyperText Markup Language) is the language of the web. It allows developers to create web pages which display images and text, to be viewed by anyone else on the web regardless of the type of computer or browser being used. HTML can be created in simple applications such as Windows Notepad, although HTML text editors do exist which format commands automatically such as Macromedia Dreamweaver and Microsoft FrontPage. The HTML tags tell the browser 'what to do' and how to format the web page.
In addition to HTML, JavaScript and dHTML may be used to complement the existing HTML code and to improve the functionality of the web page. Dynamic HTML (dHTML) has additional elements which give the developer precise control of the appearance of the web page. For example style sheets, content positioning and downloadable fonts. Javascript allows greater interactivity, images can swap simply by placing the cursor over them. In addition to this JavaScript allows for form elements to influence each other and calculations can be made without having to resort to Common Gateway Interface (CGI) scripts. CGI is the programming interface between web servers and the database which allows the web server to perform data functions and interact with users ( Reis. J)
The Database (Back-End)
There is a vast amount of information stored on the web site in the form of HTML pages and these can become very difficult to manage and navigate. Therefore a database management system needs to be implemented, which will store and organize data so that navigation on the web page is easier. In the database the information is stored in separate elements that are stored in different fields of the database (Danish and Gannon, 1998).
The possible database applications available for me to create the database in are:
* Oracle
* Microsoft Access
* MySQL 4.0
* Oracle
Oracle uses SQL (structured querying language) to define and manipulate relations (tables). The Oracle system aims to be more than a database management system DBMS, its purpose is to 'provide an environment for the development of computer based information systems.' An oracle database is made up of a set of user accounts (Rolland 1990).
* Microsoft Access
MS Access is a relational (RDBMS) which can create a wide range of stand alone tables and databases that link many tables together. MS Access is generally used to create small database applications.
(www.clearform.com/microsoft_access.htm)
With the availability of MS Access toolbars, wizard and graphical use interface activities such as filtering, sorting, querying, and form and report creation are made fairly simple. 'This flexibility allows the experienced developer to build framework database applications, which can be later modified and added to by the client.' (www.clearform.com/microsoft_access.htm)
* MySQL 4.0
MySQL is a database server which can be ideal for small applications. It supports standard SQL and can compile on a number of platforms. With the tools provided by MySQL it is possible to create very client/server applications and database-integrated web sites for free, because MySQL is an open source product, the underlying programming code is available for everyone to see and modify (Yarger et al, 1999).
Linking the Database and the Web site
In order to create a dynamic online environment the following languages can be used. (Zandstra, 2002)
* PHP
* ASP
Below each language will be briefly discussed and then one will be selected for Implementation.
* PHP
PHP is known as one of the middleware classes, it works closely with the web to fulfil requests and indicates to the web server about what is to be served to the client's browser. PHP (personal home pages) is a server-side scripting language which has been designed to integrate well with databases. It works by embedding code within the HTML page (Greenspan. J, Bulger. B, 2001).
* ASP
ASP (Active Server Pages) introduced by Microsoft, are server-generated pages which can perform functions such as accessing databases, serving different pages to different browsers and essentially any functions performed using CGI.
3.7 Selected software for Implementation of the Toyland web site
After conducting research it was decided to use the following software applications to implement the whole system.
The Web site (Front-End)
HTML and Dreamweaver
The Database (Back-End)
The database will be implemented in MySQL version 4.0.11A The reasons for selecting this database application are as follows.
* Cost Effective- MySQL is a free to install from the Internet compared to applications such as Oracle.
* Quick and Powerful - MySQL is very powerful especially for creating e-commerce web sites, particularly if the database is small (as in the case of this project).
Linking the Database and the Web site
PHP and Apache server will be used to link the back-end database to the front-end interface. PHP runs as an Apache extension, known as an Apache module. Apache is an open source web server which is extremely quick and very stable. Apache can be used with PHP and MySQL on which the system will run.
The diagram below illustrates the architecture of the intended system. The applications in brackets are the ones which will be used to implement the Toyland web site.
Figure 3.1 Architecture of Web applications (Greenspan. J, Bulger. B, 2001)
CHAPTER 4
DATABASE DESIGN AND IMPLEMENTATION
4.0 The Architecture of the System
In order to retrieve any product information, from the web site, the users need to be able to connect to the database through a network. This section will discuss the client/server environment which will be implemented for the project as well as the database requirements . The term client/server refers to the relationship between the processes running on separate machines (Orfali et al. 1996).
Listed below are some of the reasons for the use of client/server architecture:
* A server can service many clients at the same time therefore increasing performance.
* Clients initiate the dialogue by requesting a service whereas servers passively await requests from the clients which in turn reduces the communication costs.
* Client and server platforms can be independent of hardware and operating system software platforms.
* Since the server is centrally maintained, it means that the integrity constraints have to be validated and defined in only one place rather than each application program performing its own checks. (Connolly and Begg 2002)
Within the client/server environment, the client is responsible for maintaining and processing the entire dialogue with the user. This involves the management of the graphical user interface, data entry and validation of syntax by imposing specific sequences on events. The server is triggered by requests from the client. The server performs all the logic required to process the request and these are known as transactions. For example authorizing the user, maintaining the integrity of the database and supporting concurrent processing so that updates which need to be satisfy one request do not interfere with updates required to satisfy concurrent requests. The response is transmitted to the client from the server (Renaud 1996).
There are two types of client/server architectures which can be implemented for web sites.
Two-Tier Client/Server architecture
The two-tier architecture approach means that network traffic is reduced because when the client sends a query, the server responds by returning the exact information wanted instead of retrieving the whole file. This also means that update rates are increased. The client runs on the end-user desktop and interacts with the database through the network. The client can only manage the graphical user interface and the server implements both the business logic and data management. These type of clients are called 'thin clients'(Ramakrishnan, Gehrke 2003).
Three-Tier Client/Server architecture
The three-tier architecture is more scalable, robust and flexible it separates the application logic from the data management. The three-tier client/server architecture is made up of three levels. The first being the presentation tier, from which users require a interface to make requests and on which they see the results. The second tier is the middle tier where the application logic is executed. This reflects the business process and is coded in the purpose language i.e. HTML. The third tier is the data management tier which runs on a separate server and involves the DBMS - database management system (Ramakrishnan, Gehrke 2003).
The three-tier client/server architecture is more advantageous over the two-tier approach because it allows users to integrate data from multiple sources (Orfali et al 1996). It is also possible to modify a tier without affecting any of the other tiers. Scalability is increased because the middle tier can share database connections across clients and so the application server can be deployed on many machines therefore reducing the chance of bottle-neck (Ramakrishnan, Gehrke 2003). Security is also maintained by implementing it at every level so that client access to unauthorised data is prevented.
However for the purpose of this project the two-tier client/server approach is most relevant because it is expected to support a limited number of users (no more than a few hundred). The "Toyland" web site is accessed by the user from a web browser on their PC. The user interface, the database and business logic will be downloaded from the server, over the internet. The two-tier system is also much easier to implement in comparison to the complex three-tier approach and seems realistic due to time constraints.
The following diagram illustrates the two-tier client/server architecture used for the "Toyland" web site.
Figure 4.1 The Two Tier Architecture (Shamos 2000)
4.1 Database Design
This section will discuss the steps undertaken to produce an effective database which will be used as the back-end of the Toyland web site.
Now that the system requirements have been uncovered it is possible to design the database management system (DBMS), which will be the back end of the Toyland web site.
As mentioned earlier a DBMS will be designed and the reason for doing so is that it is very advantageous. The following list shows the many advantages of a DBMS taken from Connolly and Begg (2002) page 26-29.
* 'The control of data redundancy (i.e. storing the same information twice)
* Consistency can be maintained as a result of the control of redundant data.
* Sharing of data
* Improved data integrity by enforcing certain constraints so that data violation is eliminated.
* Security is improved by preventing unauthorised access to certain relations or operations (e.g. select, update, etc.)
* Increased productivity due to 'low level handling routines'
* Improved maintenance through data independence (e.g. making applications immune to changes in data descriptions)
* Increased concurrency (allowing multiple users to access the same file simultaneously
* Improved backup and recovery.'
The architecture of the DBMS is broken down into three levels. The first, is the External Level, which shows the users view of the database. The second, is the Conceptual Level, which describes what data is to be stored in the database. The final level is the Internal Level, which describes how the data will be stored in terms of physical representation Connolly and Begg (2002).
The conceptual level will be described in more detail, as it is most relevant to this section. Entities, attributes, relationships, constraints, semantics of the data and integrity will be explained.
First of all the entities have to be identified. The following entities were defined for the Toyland database:
* Product
* Customer
* Order
* Admin
* Category
4.1.1 Entities
The entities were derived from the UML diagrams drawn in chapter 3, during the requirements phase. Each entity defines the main classes that the user will require in order to retrieve information from the web site. The attributes of each entity type have been listed in Appendix X. The Product entity describes the information about the products available on the site. The admin entity is not shown on the Toyland web site but it does exist in the DBMS so that if need be, alterations can be made to any of the relations in the database.
4.1.2 Relationships
Relationships exist between entities to indicate that there is an association between them. Relationships also have constraints such as cardinality, 'describes the maximum number of possible relationship occurrences participating in a given relationship type.' Participation constraints 'determine whether all or some of the entity occurrences participate in a relationship' Connolly and Begg (2002).
The cardinality of a relationship can be one-to-one (1: 1), one-to-many (1: *) or many-to-many (*: *). An example would be that one shopping basket must belong to one customer i.e. a 1:1 relationship exists between shopping basket and customer.
Participation can be either mandatory (meaning that they are involved) or optional (meaning that only some are).
The diagram below illustrates the above example.
Figure 4.2 Multiplicity example showing cardinality and participation constraints (Connolly and Begg, (2002), page 351 figure 11.18).
The relationships identified are illustrated in Appendix X showing the multiplicity of the entities.
4.1.3 Semantics of the data
Data definition DDL
4.1.4 Integrity
According to Connolly and Begg (2002), there are five types of integrity constraints, which can be enforced:
* Required data- this defines which attributes must always contain valid values. Please refer to Appendix X where the attributes semantic data type is listed. It is very important that all the values are NOT NULL, otherwise it will display inadequate information to the customer.
* Domain constraints- presents a CHECK clause that checks whether the values are legal. For example as shown in Appendix X the sex of a customer can only be 'male' or 'female'. The check constraints are also listed within Appendix X which make sure that correct values are selected from the domain.
* Entity integrity- This enforces the rule that a primary key can not be NULL, otherwise it would not be able to be uniquely identified. As shown in Appendix X none of the primary keys are null.
* Referential integrity- This means that any foreign key value must refer to an existing value in the parent table. MySQL does not provide a mechanism for referential integrity.
* Enterprise constraints- These constraints are different according to the business since, they reflect the 'real' world transactions. For example in the Toyland database a customer can only have one shopping basket at a time, or another example is that there can only be a minimum of ten products under one category.
-1-
