[go: up one dir, main page]

0% found this document useful (0 votes)
128 views68 pages

Debremarkos University Burie Campus: Department of Computer Science

This document provides an overview and outline of an online butics shopping system project for Debremarkos University. It discusses the background, problems with the existing manual system, objectives to develop a computerized system, and scope. The system aims to address issues like lack of product information, slow searching, and inefficient reporting. It will allow customers to view, buy, and order items online and will manage products, orders, and messaging between customers and administrators. The document outlines the methodology, hardware/software, system requirements and design which will be covered in subsequent chapters. It provides high-level context and purpose for the online shopping system project.

Uploaded by

Mehari Temesgen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
128 views68 pages

Debremarkos University Burie Campus: Department of Computer Science

This document provides an overview and outline of an online butics shopping system project for Debremarkos University. It discusses the background, problems with the existing manual system, objectives to develop a computerized system, and scope. The system aims to address issues like lack of product information, slow searching, and inefficient reporting. It will allow customers to view, buy, and order items online and will manage products, orders, and messaging between customers and administrators. The document outlines the methodology, hardware/software, system requirements and design which will be covered in subsequent chapters. It provides high-level context and purpose for the online shopping system project.

Uploaded by

Mehari Temesgen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 68

DEBREMARKOS UNIVERSITY BURIE

CAMPUS

DEPARTMENT OF COMPUTER SCIENCE


ONLINE BUTIC SHOPPING IP DOCUMENTATION.
PREPARED BY: 1.YASCHLAL EYASU 6.TADESSE SISAY

7.BELETU BIMREW

8. KIDST YARED

2.MAMEN MELESE

3.GIZACHEW WORKU

4.HABTAMU AKOYE

5.BIRHANU MANTIE

3rd year ip project I


Contents
CHAPTER ON

1.1. Introduction........................................................................................................................III
1.2. Background of the study.....................................................................................................III
1.3.Statement of the problem...................................................................................................III
1.4. Objectives...........................................................................................................................III
1.4.1 .General objective.........................................................................................................III
1.4.2. Specific objectives........................................................................................................IV
1.5. Significance of the system..................................................................................................IV
1.6. Scope and limitation...........................................................................................................IV
1.6.1. Scope...........................................................................................................................IV
1.6.2.Limitation.......................................................................................................................V
1.7. Methodology.......................................................................................................................V
1.7.1. Data gathering..............................................................................................................V
1.7.2. Design methodology.....................................................................................................V
1.7.3. Analysis methodology..................................................................................................VI
1.8. Hardware and software used for implementation..............................................................VI
CHAPTER TWO
2.1. Overview of the Existing System........................................................................................VII
2.2. Problem of the existing system.........................................................................................VIII
2.3. Weakness and strength of the existing system.................................................................VIII
2.3.1. Weakness of the existing system...............................................................................VIII
2.3.2. Strength of the existing system....................................................................................IX
2.4. Business rules of the system...............................................................................................IX
2.5. Overview of the proposed system......................................................................................IX
2.5.1. Functional requirements.............................................................................................10
2.5.2. Nonfunctional requirements.......................................................................................11
2.6. Constraints and assumptions.............................................................................................11
2.6.1 Constraints...................................................................................................................11
2.6.2 Assumptions.................................................................................................................12
CHAPTER THREEE
3.1. Introduction...........................................................................................................................13
3.2. Use case identification...................................................................................................13
3.3. Use case diagram...........................................................................................................14
3.4. Sequence diagram..........................................................................................................32
3.5. Class diagram.................................................................................................................44
CHAPTER FOUR
4.System design........................................................................................................................46
4.1 Design Goal.....................................................................................................................46
4.2 System Decomposition and interrelation between them...............................................46
4.3 System Architecture........................................................................................................48
4.4 Deployment Diagram......................................................................................................49
4.5 User interface design......................................................................................................50
CHAPTER FIVE
5.Implementation and Testing..................................................................................................55
5.1. Objective of the Implementation...................................................................................55
5.2. Constraint of Implementation........................................................................................55
5.3. Sample code and description.........................................................................................55
5.4. Testing Overview...........................................................................................................62
CHAPTER SIX
6. Conclusion and Recommendation........................................................................................64
6.1 Conclusion.......................................................................................................................64
6.2 Recommendation............................................................................................................65
CHAPTER ONE
1.1. Introduction
This chapter deals about the system requirement specification that follows to analysis and
design methodology. Statement of problem, proposed objective, scope, limitation, literature
review, hardware and software implementation and test methodology.

1.2. Background of the study


The butics shopping system in burie Town refers to a place that store and sells butics which
enable customers to buy products over the internet. Customer can visit web stores from the
comfort of their homes and shop as they sit in front of the computer. hence, the project will be
designed to intend to bring about the changes, the development and better improvement of the
customer services through enhancing butics shopping system and the effective use of computer
technology to enhance the customer can view, buy their favorite’s product item. .

1.3.Statement of the problem


It is clear that an organization to be well organized and operative, there must be high file
management and fast retrieval and handling method. Thus are the difficulties that avoided in
new scheme are:-

 Customer has shortages of information about butics product item in order to buy easily.

 Searching of items is time taking and it also increasing the work load of the workers.

 There is information gap between the customer and administrator.


 When generating report, it takes time and it may not be easy to manage and analysis
the monthly work due to massive collection of data.

1.4. Objectives
1.4.1 .General objective

The general objective of our project is to develop online butics shopping system for
Habtamu buticshopp in burie town.
1.4.2. Specific objectives

 Design the system using object-oriented models for understanding the system and to
make the implementation easy.

 To evaluate its performance and acceptability in terms of security, userfriendliness,


accuracy and reliability.

 To develop a system that will surely satisfied the customer service.


 Test the performance and reliability of web application.
 To develop system that used to check the customers product need.
 To develop a database for butics shopping and store products.

1.5. Significance of the system


The significance of this project is to solve partial problems within the shopping system .
This project is much more important to:

 Customers are very relevant because it can give clear product in the shop.
 Easily add, delete, and update product item.
 To minimize time and efforts needed to perform tasks.
 The system will provide secure services to customers and easy to use.

1.6. Scope and limitation


1.6.1. Scope

our project should be overcome the drawbacks of their manual system by replacing
computerized system and it provide simple, efficient environment and reduce time consuming
and this project only limited for bu town. Generally, part of our project address: -

 View register customer, view item, and order item, Update item, register item and View
order and generate report.

 Delete product items from database by Administrator.


 Sending and receiving message between Administrator and customer.
 The system generates delivered report.
 Search products using dropdown menu.
 The system announces the total price of the purchase product.

1.6.2.Limitation

 It does not search the item by color, discount ,number

The system not consider for backward item from customer.

 The system is also does not consider ATM.

1.7. Methodology
1.7.1. Data gathering

The team will use the following requirement determination methodology for the development
of our project:

 Interview: -The teamwas use open interview method asked to EDERES to get the basic
information and background information for thebutics shopping system.

 Observations: -We observed physically the current existing system which is done
manually and observe how they perform each activity.
 Document analysis: -To understand the existing system, we can collect more
information by referring books, documents and other reading materials about shopping
system with through internet.

1.7.2. Design methodology

During this phase our team will use E-draw max software to refine the use case model, and to
reflect the establishment environment, model object interactions and behavior that support
the use case scenario, and finally update object model to reflect the physical environment, the
users and other people, their work process, and so on. It is critical for analysts and developers
to understand the application domain for a system to accomplish its intended task effectively
1.7.3. Analysis methodology

The object-oriented approach to software development is decidedly a part of the mainstream


simply because it has proven to be of value in building systems in all sorts of problem domains
and encompassing all degrees of size and complexity. Furthermore, most contemporary
languages, operating systems, and tools are objectoriented in some fashion, giving greater
cause to view the world in terms of objects[4].

The data analysis model applied in this project is an object oriented approach. That is Object
oriented method is select because of the process of analyzing a task (also known as a problem
domain) to develop a conceptual model that can then be used to complete the task. A typical
object oriented approach model would describe computer software that could be used to
satisfy a set of customer-defined requirements[1].

The system analysis model must achieve two primary objectives:-

To establish the basis for the enhancement of a software design.

To define a set of requirement that can be validated once the software is completed
enhanced.

When it comes to objective it is required to generate rapid and continuous value, because the
template is going to be used in organization and different events before the official release.
Besides any developer interested in the platform should be able to use the current capability of
the system. Consequently, regular small releases of the template with new added functionality
are highly desirable. [2]

1.8. Hardware and software used for implementation


For the project implementation; the following Software and hardware tools are used.

Hardware Tools: -

 Server: for connection to the client computer (to host the system.
 Desktop computer with 2 GB RAM and 150 GB hard disk.
 CD/DVD and flash disk to take back up.
 The laptop with 4 GB RAM and 80-300GB HDD. Software Tools

For the System implementation the following software’s are used.

 Microsoft Office word 2007: - for writing documentation.


 Microsoft edraw Max 8.4 version: - for drawing different UML diagrams.
 Php:-scripting language.
 Html:-Client side coding.
 Css:-for the formatting of the web site.
 Java script:-Client side scripting.
 MySql:-for database.
 Notpad++:-It is used as reserve code to write this project.
 Window-7 operating system: - for used to code running the application.
 Microsoft Office power point 2007: - for used to presentation.
 WAMP SERVER: -This software assists to create database or back end of the system
,to run and test system application.

 Anti-Virus software:- used to keep secure ,scan,fix Flash Disk and to prevent data
destruction and corruption.

CHAPTER TWO
2.1. Overview of the Existing System
The existing system of Habtamu butic is a manual system.

In the existing system shopping are takes place in traditional way or a person must be there
physically to participate on the open shopping system. A traditional open shopping system is an
aggregation of supply and demand in the marketplace to effectively establish a price for a
product or service.

The detail existing system function are listed below: -

 The administrator asks the customer about their desire to purchase.


 The customer tells what type of goods needs to buy.
 The administrator shows the goods to the customer and tells the price.
 If the customer agrees with the price of the goods, then he/she pays the price.
 The administrator receives the money and gives receipt

2.2. Problem of the existing system


The existing system has many problems in the working procedure for the organization and
customer. These are: -

 Risk of management data due to massive data collection.


 Accuracy not guaranteed.
 Lack of awareness.
 Not in reach of distance users.
 Not provide online purchasing.
 The customers may be resulted to unnecessary extra expense and waste their
time.

 The customer might not get service of the organization twenty-four hours a day
and seven days a week.

2.3. Weakness and strength of the existing system


2.3.1. Weakness of the existing system

There are many problems for businessmen but the great one is excessive charge backs. The
weaknesses of the system are: -

 Consuming large volume of paper work.


 Lack of immediate retrieval of the required information.
 Lack of prompt updating.
 Time for shopping can make the customer’s options to purchase products from other
places.

2.3.2. Strength of the existing system

The strength of the existing system gives additional service for the customer during purchasing
items. i.e. it purchases the item in credit, satisfy the customer, it prepare receipt for purchasing
item because it uses manual system.

 A distribution of work for the Administrator.


 The Administrator have their own privilege (freedom).
 The customers can buy items in a good price.

2.4. Business rules of the system.


The business rules also implement its own business rule and regulation which are followed to
perform work in easier and best manner.

BR1: -almost all items have some time guaranties given by the business rule.

BR2: -The customer or the owner would purchase with an appropriate.

BR3: -The copy of the original receipt is left for the business rules.

2.5. Overview of the proposed system


In day to day life, we will need to buy lots of goods or products from a shop. Now days, it is
really hard to get some time to go out and get product item by ourselves due to busy
life style or lots of works. In order to solve this, E-Commerce websites have been
started. Using these websites, the customer can buy goods or products by using
Account number preparing a bank database just by visiting the website and ordering
the item online. . It requires lots of time to travel to the particular shop to buy the
goods. Since everyone is leading busy life now days, time means like money to
everyone. Also there are expenses for travelling from house to shop.

In order to overcome these, we have e-commerce solution, i.e. one place where we
can get all required goods/products online. User can choose different products based
on categories, delivery services.

2.5.1. Functional requirements

Functional requirements describe the interaction between the system and its
environment independent of its implementation. The environment includes the user
and any other external system with which the system interacts.

Hence our system has different requirements: -

 The system will allow customer and Administrator to login to the system.
 The system will allow customer to create account.
 The system will allow customer and Administrator to change their password
 The system will allow customer to view items with full information (type, image, and price).

 The system will allow customer to order the item.


 The system will allow Administrator to register item.
 The system will allow Administrator to update item.
 The system will allow Administrator to generate report.
 The system will allow customer and Administrator to logout.
 The system will allow Administrator to delete and edit an item.
 The system will allow Administrator to view customer.
 The system will allow customer to transfer money.
 The system will allow customer and Administrator to search item from the system.
2.5.2. Nonfunctional requirements

As the name suggests, non-functional requirements are requirements that are not
directly services concerned with the specific functions delivered by the system. These
are constraints on the functions offered by the system.

 Security: -should allow login to only authorized users.


 Performance: -this system gives service 24 hours per day with minimum response time so, it is
easy to participate on the shopping system.

 Reliability: - the proposed system will be better due to proper storage of information when
users access the system.

 Availability: - All data in the system will be available all the time.
 No Redundancy: - In the proposed system can be avoided reputation of data anywhere in the
database.

 Accuracy: - The proposed system will be better due to reduction of error. All operation can be
done correctly and it ensures that whatever information is coming from the data base is
accurate.

 Efficiency: - The system must ensure allocation and use of services being requested for the users
by using minimum memory storage, cost, time and human power.

2.6. Constraints and assumptions


2.6.1 Constraints

Constraints are something limit or impose our project. A constraint can be two types which
are:-

1.Business constraint: - It depends on the state of the organization. Some of them in


our proposed system are:-

 During gathering information the manager not always present on their office.
 The time schedule limits our project function of working in order to submit
before the given time deadline.

2.Technical Constraints:-It depends on security and safety. Some of them in our proposed
system are:-

 Network connection problem.


 We does not get lab when we want.

2.6.2 Assumptions

It is a belief of what we assume that are expected to happen during the project's life cycle.

Thus are:-

To access the system the customer should be in network coverage area.

 Customer must be good in computer usage.


 The administrator must check if order is existing or not from the customer.
 Customer must know English language.
 Customer must know the address of web.
 All software and hardware requirements are fulfilling.
CHAPTER THREEE

3. System modeling
3.1. Introduction

This chapter deals about the modeling technique that follows to design the system.
Object oriented analysis design technique will be used. It includes system use case
model, sequence diagrams, class diagram Actor specification, use case identification
&use case description.

3.2. Use case identification

A use case is an interaction between users and a system. It captures the goal of the
users and the responsibility the system to its users. It is the functionality of the system
or the service provided by the system. A use case describes a sequence of action that
provides a measurable value to an actor and draw as a horizontal ellipse.

1. UC-01: Create Account


2. UC-02: Login
3. UC-03: Change password
4. UC-04: Search Item
5. UC-05: View Item
6. UC-06: Order Item
7. UC-07: transfer money
8. UC-08: View Order
9. UC-09: View customer
10. UC-10: Update Item
11. UC-11: Item Registration
12. UC-12: Generate Report
13. UC-13: Logout
14.
UC-14: Delete Item
15. UC-15: Edit Item
3.3. Use case diagram

3.3.1. Actor specification


Actor:-It can be a person, service, organization or other system that play a role in one
or more interaction with our system. Actor has a goal and this goal is what the actor
wants to achieve by interacting with the system.

The following are actors in our project:-

1. Customer: -The customers can get online shop service from the system, which are
capable of order, search, and view item.

2. Administrator: -The person who manage, controlling and coordinating the activity
and responsible for register item, update item, view order, generate report.
Figure 1:Use case Diagram
3.3.2. Use case description

Use case UC-01


number

Use-case Create Account


Name

Actor Customer

Description These use case allow customer to create account to the system.

Precondition The customer wants to create account on our system.

Basic course of User Action System Response


Action

1. The customer home page to 2. The system creates register account user
create account and click on create interface and form.
account link.
4. The system controller verifies a form
3. The customer fill form on and check the form is verified.(If it does not
create account form and create verify back to step 3 or re enter their
account. information)

5. The system send request to


database to save account and reply
account created is saved to the controller.

6. The system reply account is


successfully created on create account user
interface. 7. Use case Ends.

Table 1: Use-case description for Create Account

Use-case UC-02
Number
Use-case Login
Name

Actor Administratorand Customer


Description This use case describes how Administrator and customer , to login to the buying
system

Pre-condition Actor must have Account


Postcondition If the use case was successful, the Actor is now logged in to online shopping system.
If not, the system state is unchanged.

Basic course of User action System Response


Action
1.The Administrator and
customer are open
home page to login to 2. The system prompts the Administrator and
the system. customer to enter user name and password.

3. The Administrator and 5. If they have an account the system


customer submit username verifies that all the filled have been filled out
and password. 4. If they and the login controller check username and
have no username and password are valid.
password create new
6. The controller request to login the
account and apply 2&3.
database and it retrieve the information and
send to the controller.

7. If the authentication false it back to the


login form and if true back to main menu.

8. The system successfully logged in the


system. 9. Use case Ends.
3.1 If all fields are not filled out and not matched to the username and password
Alternate the system notifies the actor message username and password is incorrect and
course of then goes back or returns to step 2 of basic course of Action to enter again
Action

Table 2: Use-case description for Login

Use-case UC-03
Number
Use-case Name Change password
Actor Customer and Administrator

Description These use case allow and Administrator to change password from the system.

Per-condition Customer and Administrator want to change password.


Basic course of User Action System Response
Action
1. The user wants to change password on 2. The system creates change
main menu and click change password link. password user interface and
form.
3. The user fills a form and change password
on the form. 4. The system controller
verifies the form and check the
form is verified.

5. The controller send


request to database to change
password and it send the
changed password to controller.

6. The system replay


password successfully
changed on change password
user interface. 7. Use case Ends.

Table 3: Use-case description for Change Password

Use-case UC-04
Number

Use-case Search Item


Name

Actor Customer and


Administrator
This use case permits Customer to search item from item list in order to
Description
display.

Precondition UC-02

Basic course of User Action System Response


Action

1. The Administrator and 4. The search controller verify


customers enter to home page item name and check item is verified.
to search the item.
5. The system controller sends the
2. The Administrator and request item to database and it
Customer enter the item name retrieve the information and back to
on search form. controller.

3. Clicks on search button. 6. If the item is found it display on


the home page user interface, if not
display item is not matched message.

7. Then the system display all


information about the item based
selected list.

8. Use case End.

Alternative 5.1 If any lists are not selected from the search system goes back or returns
course
to step 2 of basic course of Action to search the item.
of
action
Table 4: Use-case description for Search Item

Use-case UC-05
Number

Use-case View Item


Name

Actor Customer

Description This use case allows Customer to view or display all items with their
detail description about the item.

Precondition Item select

Basic course User Action System Response


of Action

1. The Customer opens the system to 2. The system send request


enter home page. item to database. 3. The
system display item on
home page user interface.

4. Use case Ends.

Table 5: Use-case description for View Item


Use-case UC-06
Number

Use-case Name Order Item

Actor Customer

Description These use case allow customer to order the item from the system.

Pre-condition UC-02

Basic course User Action System Response

of Action
1. The customer is in home page. 2. The system creates search form.

3. The customer writes and 4. The system controller verifies


search item on search form. 6. If the input and check input is verified.
the item found the customer
5. The system retrieves the item
select it on main menu.
and the retrieved search result and
7. The customer click add to cart also the result not found put on
link and click the cart and display home page.
cart user interface.
8. The system create order button.
9. The customer click order
10. The system creates confirmation
button.
and clicks and sends text to
11. The customer writes the customer and saves to the database.
message and confirm on email
12. The system verify message on
form.
database and send message ordered
is successful on cart user Interface.

12. Use case Ends.

Alternate course 6.1 If the item is not found the system state is unchanged.
of action

Table 6: Use-case description for Order Item

Use-case Number UC-07


Use-case Name View Order

Actor Administrator

Description
These use case allow Administrator to view order form the
system.

Pre-condition UC-02

Post-condition The Administrator views the customer order.

Basic course User Action System Response


of
Action

1. The Administrator 2. The system create order link.


initiates to view orders on
4. The system sends the
main menu.
requested order to DB and
3. The Administrator display orders on order
clicks the order link.
UI.
5. Use case Ends.

Table 7: Use-case description for View Order


Use-case Number UC-08

Use-case Name Update Item

Actor Administrator

Description This use case permits staff to update or modify item information

Pre-condition UC-1 & UC-2

Post-condition Updated item information

Basic course of Action User Action System Response


1. The administrator enter
main menu to update item.

3. The administrator writes


the item and search on search
form.

6. The administrator enters


update item information and
click update.

2. The system creates update item user


interface and form.

4. The system controller verifies a


form and check form is verified.
5.The system controller send request
item to database and it retrieve the
item and back to controller and it
display item information on update
item user interface.

7. The controller verifies the form


and send request to update item on
database.

8. The successfully updates


information into database.

9. Use case Ends.


Alternate course of Action 6.1 If item is not found back to basic course of action 6 to
update item.

Table 8: Use-case description for Update Item

Use-case ID UC-09

Use-case Name Registration Item

Actor Administration

Description This use case permits to register item information of the customers

Pre-condition UC-2

Basic course of User Action System Response


Action
5. T
1. The administrator enters the he item controller verifies a
main menu to register item. form and check if it is valid
form.
2. The administrator clicks the item
register link and creates its user 6. The controller register
interface and form. the item in database and it
send the registered item to
3. The administrator fills
controller.
information about the item and registers
the item in item registration form. 7. If the item correctly
registered it display on the
4. If the item registration form not
item register user interface.
found the employee create the form.
8. The system displays
successful item summary.

9. Use case Ends.

Alternate course 2.1. If all fields are not filled out and matched to the registration form the system
of Action notifies the actor message the item information is incorrect and then goes back or
returns to step 2 of basic course of action to register again.

Table 9: Use-case description for Registration Item

Use-case UC-11
Number

Use-case Generate Report


Name
Actor Administrator

Description These use case allow administrator of the organization to generate a report about the
item information of a month.

Precondition Administrator wants to see report , UC-02

Postcondition Generate monthly report information.

Basic course User action System Response


of

Action 1. The administrator wants to

generate report and enter to the


main menu.

2. The administrator cli cks

report pages. 3. The system request to retrieve the report into


database.

4. The system retrieved and generates report on


report UI.

5. Use case Ends.

Alternate 4.1 If the selection information is empty or not found go to 5.


course
of
Action

Table 10: Use-case description for Generate Report

Use-case UC-13
Number

Use-case Logout
Name

Actor Customer and Administrator

Description These use case allow customer and manager to logout from the system at
a time of accomplishing their work.

Precondition UC-02

Postcondition System logout

Basic course of User Action System Response


Action

1. The customer or 3. The system responds to


Administrator wants to logout and the requested action.
enter to main menu.
4. The system successfully
2. The customer or logout back to home page.
administrator clicks the logout
button. 5. Use case Ends.

Table 11: Use-case description for Logout

3.4. Sequence diagram

Sequence diagrams are dynamic model of use cases, showing the interaction among
classes during a specified time period. Sequence diagrams graphically document the
use case by showing the classes, the messages, & the timing of the messages. The
interaction between objects in the system is shown in the following sequence
diagrams. [7]
Figure 2 : login sequence diagram
Figure 3: create account sequence diagram
Figure 4:change password sequence diagram
Figure 5: search item sequence diagram
Figure 6: view item sequence diagram
Figure 7: order item sequence diagram
Figure 8: view order sequence diagram
Figure 9: update item sequence diagram
Figure 10: register item sequence diagram
Figure 11: generator report sequence diagram
Figure 12: logout sequence diagram
3.5.
Class diagram

“Class diagrams are used to describe the structure of the system. Classes are
abstractions that specify the common structure and behavior of asset of objects.
Objects are instances of classes that are created, modified, and destroyed during the
execution of the system. Class diagram describes the system in terms of objects,
attributes, operations, and their associations”[8].

In the diagram, classes are represented with boxes which contain three parts:

 The top part contains the name of the class. It is printed in bold and centered, and
the first letter is capitalized.

 The middle part contains the attributes of the class. They are left-aligned and the
first letter is lowercase.

 The bottom part contains the methods or operation the class can execute. They are
also left-aligned and the first letter is lowercase.
Custaccount

bankname:Type = varchar(50)
location: Type = varchar(20)
1 username: Type = varchar(30)
pwd:Type=string
1 balance: Type=int())
Customer

Feedback
cust_id:Type = varchar(15) mailid:Type = (10)
FirstName:Type = Varchar(30) sub:Type = varchar(20)
FatherName:Type = Varchar() message:Type = varchar(30)
gender:Type = Varchar(6) mesdate:Type=date()
1 * sender:Type=varchar(20)
email:Type = Varchar(20)
username:Type = Varchar(20) reciver:Type=varchar(20)
1
password:Type = string
address:Type = Varchar(30) * *
phone:Type = varchar(13) Order
regdate:Type = date() ord_id:Type = varchar(20)
prd_id:Type = varchar(20)
username:Type = varchar(20)
+search products() ord_pname:Type = varchar(20)
+order product() ord_qty_:Type = varchar(20)
+view report() price:Type = int(10)
ord_fname:Type = varchar(20) 1
ord_fathername:Type = varchar(20)
ord_date:Type = date(10)
1 drd_date:Type = date(10)
Category billing_address:Type = varchar(20)
Admin
address:Type = varchar(20) username:Type = varchar(20)
* password:Type = string
cat_id:Type =varchar(20) admaccno:Type = int(20) email:Type = varchar(20)
sub_cat:Type=varchar(20) price:Type = Decimal(10)
+add category()
description:Type = varchar(20) admaccno:Type = int(20)
delivery_status:Type=Varchar(20) +record product()
+view report()
+deliver product()
1 +view feedback()
+view balance()
1
* 1
Product
username:Type = varchar(20) 1
prd_id:Type=varchar(20)
prd_name:Type = varchar(20) Admin account
photo:Type =varchar(30)
prd_qty:Type = int(10) bankname:Type = varchar(50)
prd_id:Type=varchar(20) * location:Type = varchar(20)
price:Type=Decimal(10,0)
username:Type =varchar(30)
prd_cat:Type =varchar(30)
prd_sub_cat:Type =varchar(30) pwd:Type=string
prd_descrip:Type=varchar() balance:Type=int()
prd_qty_avila:Type=int(10)
prd_delivery_mode:type=varchar
(30)
prd_delivery_time:Type=int(10)

Figure 13: Class diagram


CHAPTER FOUR
4.System design
Systems design is the process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements. Design of software
involves conceiving, planning out and specifying the externally observable
characteristics of the software product. We have data design, architectural design and
user interface design in the design process. These are explained in the following
section. The goal of design process is to provide a blue print for implementation,
testing and maintenance activities.

System design is one of the activities that are required to build and verify software.
The designer’s goal is to produce a model or representation of an entity that will later
be built. Design provides us with representations of software that can assess for
quality. Design is the only way that we can accurately translate customer’s view into
finished software product or system.

4.1 Design Goal

Design goals describe the qualities of the system that developers should optimize. The
design goals are derived from the nonfunctional requirements. Design goals guide the
decisions to be made by us especially when trade-offs are needed.

4.2 System Decomposition and interrelation between them

The rationale behind subsystem decomposition spans many different issues, such as
hardware allocation, persistent storage, access control, global control flow, and
boundary conditions. The comprises three subsystems, which namely and functionally
decomposed as account management, item management, and order management,
The Details of each sub system and their corresponding services are presented as
follow:
Figure 14:system Decomposition diagram
4.3
System Architecture

The term system architecture is used to describe the overall design and structure of a
computer network or system. It includes a wide range of physical devices, a method is
required to organize and connect these items together in a cohesive manner. The
term is also used to describe complex computer_ software tools. Systems Architecture
is a generic discipline to handle objects (existing or to be created) called "systems", in
a way that supports reasoning about the structural properties of these objects. A
system architecture is the conceptual model that defines the structure, behavior, and
more views of a system.

There are three main components to any system architecture of the system theses includes:
storage, connectivity, and user experience.

Figure 15: System Architecture


4.4 Deployment Diagram

Deployment diagram is a structure diagram which shows architecture of the system as


deployment (distribution) of software artifacts to deployment targets.

A deployment diagram is used to depict (show) the relationship among run-time


components and hardware nodes. A web server, for example, is a component that
provides services to Web browsers. It shows the physical architectures of the new
system and how hardware is connected. When it comes time to think about deploying
the system, deployment diagrams are crucial because they show the processors on
the system and the connections between them. A component is a physical unit of
implementation with well defined interfaces that is intended to be used as a
replaceable part of a system. The deployment diagram for this system is shown in the
following figure.
Figure 16: Deployment diagram

4.5 User interface design

This user interface design shows the sample of our project implementation part.
Figure 18: home page user interface
Figure 19:customer login page user interface
Figure 20: customer registration user interface
Figure 22:Admin page user interface
Figure 23:product register page user interface
CHAPTER FIVE
5.Implementation and Testing
5.1. Objective of the Implementation

The objective of system implementation phase is to convert the final physical system
specification in to working and reliable software and hardware, document the word
that has been done, and provide help for current and future users.

5.2. Constraint of Implementation

Constraints are situations that limits on implementing the new system. To develop our project
so many things we face from these: -

 Lack of full and fast internet


service Lack of hardware
tools like laptop.

 Power fluctuation.

5.3. Sample code and description

Sample code for item list display for customer:-

<?phpsession_start();?>

<html>

<head>

<title>online shopping</title>

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

<link rel="shortcut icon" href="imz/su.jpg" />

<link rel="stylesheet" href="css1/style.css" type="text/css" media="all" />

<script src="js1/jquery-1.6.2.min.js" type="text/javascript" charset="utf-8"></script>


<script src="js1/jquery.jcarousel.min.js" type="text/javascript" charset="utf-8"></script><script
src="js1/functions.js" type="text/javascript" charset="utf-8"></script>

</head>

<body>

<div id="wrapper">

<div id="search">

<div class="shell">

<form action="#" method="get" accept-charset="utf-8">

</form><div class="cl">&nbsp;</div>

</div></div>

<div id="header" class="shell">

<h1 align="center"><imgsrc="images/12.png" align="center" height=100 width=950


/></h1>

</div>

<div id="navigation">

<div class="shell"><ul>

<li><a href="loghome.php" title="Home"><h3 style="color:#FFFFFF">Home</h3></a></li>

<li><a href="productdisplayin.php" title="product"><h3


style="color:#FFFFFF">Product</h3></a></li><li><a href="stock.php" title="view item"><h3
style="color:#FFFFFF">view items</h3></a></li>

<li><a href="custaccount.php" title="create account"><h3


style="color:#FFFFFF">create account</h3></a></li>

<li><a href="main.php" title="change


password"><h3 style="color:#FFFFFF">Go to shop</h3></a></li>

</ul>
<div
class="cl">&nbsp;</div>
</div></div><div id="slider">

<div class="slider-outer">

<div class="slider-inner shell"><ul class="slider-items"><li><imgsrc="images/gi.jpg" alt="Slide


Image 1" /><div class="slide-entry"></div>

<a href="#" class="more" title="View More">View More</a></li><li>

<imgsrc="images/products/ac.png" alt="Slide Image 2" height=300 width=975 />

<div class="slide-entry">

</div><a href="#" class="more" title="View More">View More</a></li><li>

<imgsrc="images/gi.jpg" alt="Slide Image 3" />

<div class="slide-entry"></div>

<a href="#" class="more" title="View More">View More</a></li>

<li><imgsrc="images/products/q.png" alt="Slide Image 2" height=300 width=975 />

<div class="slide-entry"></div>

<a href="#" class="more"title="View More">View More</a></li><li>

<imgsrc="images/tr.png" alt="Slide Image 2" height=300 width=975 />

<div class="slide-entry"></div>

<a href="#" class="more" title="View More">View More</a></li></ul>

<div class="cl">&nbsp;</div>

<div class="slider-controls">

</div></div></div>

<div class="cl">&nbsp;</div></div>

<div id="main">

<div class="inner">
<div
class="shell">
<?php

include("connected.php");

if(isset($_SESSION['user']))

$username=$_SESSION['user'];

echo "User name :".

$username;

} else {

?><script> alert('You Are Not Logged In !! Please Login to

access this page'); window.location='login.php';

</script>

<?php

?>

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<script type="text/javascript" src="js/functions.js"></script>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>Online Shopping</title>

<link href="css/online.css" rel="stylesheet" type="text/css" />

<style type="text/css" media="all">


@import "online.css";

</style>
<script language="javascript">

function log out con()

varconlog = confirm('Are you sure you want to log out !!');

if(conlog)

alert(window.location="logout.php");

else

{ r

etur

fals

e;

</script>

</head>

<body background="images/bg.jpg">

<div class="twoColFixLtHdr">

<div id="header">
</div>

<div id="container">

<div id="container1"></div>

<div id="sidebar1">

<div id="subsidebar1">

<div id="subsidebar3">&nbsp;&nbsp; Navigation </div><div id="subsidebar4">Display

<ul><a href="productdisplayin.php" title="list of product">Product </a></ul></div

<div id="subsidebar2"><a href="Main.php" title="you can go to the shopp">Go to


Shop</a></div>

<div id="subsidebar2"><a href="delivered.php" title="deliver report">Delivery


Reports</a></div>

<div id="subsidebar2"><a href="mailcompose.php" title="send


message">Compose</a></div>

<div id="subsidebar2"><a href="mesageview.php" title="view message">message


view</a></div>

<div id="subsidebar4">Account Settings

<ul><a href="changepassword.php" title="change password">Change


Password</a></ul></div><div id="subsidebar2"><a href="" title="logout"
onClick="logoutcon();">Logout</a>

</div></div></div>

<div id="mainContent">

<div id="mainContent1">

<div id="middletxtheadermain">

<blink><div id="middletxtheader" align="right"><h1 align="center" style="color:#FFFFFF">WELL


COME TO THE SYSTEM</h1></div></blink>

<div id="middletxt1">
<div
align="center"><imgsrc="images/r.png" alt="Online Shopping" width="650"
height="100"/></div></div></div>

<div id="middletxt">

<div id="middletxtheader" align="right"></div>

<div align="center"><imgsrc="images/tr.png" alt="Shopping " width="680"


height="420" align="center" /></div></div></div></div>
<div id="footer1">

<marquee behavior="alternate" scrollamount="10"><h2>online butics shopping


system</h2></marquee>

</div></div></div>

</body>

</html>

</div></div></div>

<div id="footer">

<div class="shell">

<p class="bottom-menu"><a href="loghome.php" title="Home">Home</a><span>|


</span><a href="productdisplayin.php" title="product">product</a><span>|</span><a
href="" title="Log In" onClick="logoutcon();">Log out</a><span>|</span><a
href="signup.php" title="Account"></a><span></p>

<div class="cl">&nbsp;</div></div></div></div>

</body>

</html>
5.4.
Testing Overview

Testing is a process of executing a program with the intent of finding an error. A good
test case is one that has a probability of finding an as yet undiscovered error. A
successful test is one that uncovers an as yet undiscovered error. Our Objective is to
design test processes that systematically uncover different classes of errors and do so
with minimum amount of time and effort.

5.4.1 Test by scope


Software testing is a process of running with intent of finding errors in software.it
assures the quality of software and represents final review of other phases of software
like specification, design, code generation etc.

5.4.2 Unit testing


The module interface is tested to ensure that information properly flows into and out
of the program unit under test. The unit testing is normally considered as an adjunct
step to coding step. Because modules are not a standalone program, drivers and/or
stubs software must be developed for each unit. A driver is nothing more than a “main
program” that accepts test cases data and passes it to the module. A stub serves to
replace the modules that are subordinate to the modules to be tested. A stub may do
minimal data manipulation, prints verification of entry and returns. For example:-

5.4.3. Integration testing


If they all work individually, they should work when we put them together. The problem
of course is putting them together. This can be done in two ways:

Top down integration: Modules are integrated by moving downwards through the
control hierarchy, beginning with main control module are incorporated into the
structure in either a depth first or breadth first manner.

Bottom up integration: It begins with construction and testing with atomic modules
i.e. modules at the lowest level of the program structure. Because modules are
integrated from the bottom up, processing required for the modules subordinate to a
given level is always available and the need of stubs is eliminated.
5.4.4.
Testing by requirements

Testing by requirements insures that the entire integrated software system meets
requirements. It tests a configuration to insure known and predictable results. It is
based on process description and flows, emphasizing pre-driven process links and
integration points. In essence testing by requirements is not about checking the
individual parts of design, but about checking the system as a whole.

Test the system by using requirements of software and hardware components such as

computer with operating system containing: - WAMP server: a server used to run the

codes.

PHPMY Admin: front-end, to develop the PHP programming of the system translation.

MYSQL: to hold data base and to store data.

These are used for testing all the functional requirements are function able and access able
inthe environment of WAMP server.

Web browser: for internet connection.


5.4.5. Test implementation (Validation testing)

Validation succeeds when software functions in a manner that can be reasonably expected by
the customer. It covers the following: -

Validation test criteria: Performance, functional characteristics and uncovered deviation


from specification

Configuration review: Ensures that all the elements of software configuration have
been properly developed cataloged and have support for the maintenance phase of
software life cycle
CHAPTER SIX
6. Conclusion and Recommendation
6.1 Conclusion

In this project, the user is provided with an e-commerce system that can be used to
buy butics product item online .The Internet has become a major resource in modern
business, thus butics shopping has gained significance not only from the
entrepreneur’s but also from the customer’s point of view. For the entrepreneur,
butics shopping generates new business opportunities and for the customer, it makes
comparative shopping possible.

The project began by laying out the foundation that determines the development
process. This involved defining the system development methodology, identifying
resource requirements, and setting the project schedule.

Requirements analysis is performed to discover the needs of the new solution to


proposed system. This phase consists of drawing out functional and non-function
requirements of the system.

In analysis, the proposed system is modeled using UML diagrams: use case diagrams, sequence
diagrams, Class diagrams.

We have designed the project to provide the user with easy navigation, retrieval of
data and necessary feedback as much as possible. To implement this system was used
PHP and MySQL also JavaScript were the major software and database used for
developing the entire system.

A good shopping cart design must be accompanied with user- friendly shopping cart
system. It should be convenient for the customer to view the contents of their cart
and to be able to remove or add items to their cart.
Generally, the system would take as a means for butics shop to deliver efficient and
effective report generating, recording categories, products, displaying product
information and information sharing.

The system that we developed is the one that is relatively minor in its type, but it can be a
breakthrough for other system developers to further implementation on the system.

6.2 Recommendation

This system will give a solution for some of the problems in EDERES Butics shopping
system.

 This project will promote e-commerce and online marketing on the Internet, complying
with the information technology more develop.

 Firstly, we recommend EDERES Butics shop to apply and use this system.
 Training for users: -We need to give training for those users of the system.
(Administrator).

 The system is developed for the first time, and it may have some limitation, so we are
willing to welcome every interested person’s idea and we need support of the program
to make the best.

 Server: - The server should be available at all time


 We recommend that who are voluntary to include other features of the system to be
fulfilled.

 The system that developed is the one that is relatively minor in its type, but it can be a
breakthrough for other system developers to further implementation on the system.

You might also like