Debremarkos University Burie Campus: Department of Computer Science
Debremarkos University Burie Campus: Department of Computer Science
CAMPUS
7.BELETU BIMREW
8. KIDST YARED
2.MAMEN MELESE
3.GIZACHEW WORKU
4.HABTAMU AKOYE
5.BIRHANU MANTIE
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.
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.
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.
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.
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.
1.6.2.Limitation
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.
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 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].
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]
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
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 customer might not get service of the organization twenty-four hours a day
and seven days a week.
There are many problems for businessmen but the great one is excessive charge backs. The
weaknesses of the system are: -
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.
BR1: -almost all items have some time guaranties given by the business rule.
BR3: -The copy of the original receipt is left for the business rules.
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.
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.
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).
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.
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.
Constraints are something limit or impose our project. A constraint can be two types which
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:-
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:-
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.
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. 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
Actor Customer
Description These use case allow customer to create account to the system.
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)
Use-case UC-02
Number
Use-case Login
Name
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.
Use-case UC-04
Number
Precondition UC-02
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
Actor Customer
Description This use case allows Customer to view or display all items with their
detail description about the item.
Actor Customer
Description These use case allow customer to order the item from the system.
Pre-condition UC-02
of Action
1. The customer is in home page. 2. The system creates search form.
Alternate course 6.1 If the item is not found the system state is unchanged.
of action
Actor Administrator
Description
These use case allow Administrator to view order form the
system.
Pre-condition UC-02
Actor Administrator
Description This use case permits staff to update or modify item information
Use-case ID UC-09
Actor Administration
Description This use case permits to register item information of the customers
Pre-condition UC-2
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.
Use-case UC-11
Number
Description These use case allow administrator of the organization to generate a report about the
item information of a month.
Use-case UC-13
Number
Use-case Logout
Name
Description These use case allow customer and manager to logout from the system at
a time of accomplishing their work.
Precondition UC-02
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)
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.
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.
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.
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.
Constraints are situations that limits on implementing the new system. To develop our project
so many things we face from these: -
Power fluctuation.
<?phpsession_start();?>
<html>
<head>
<title>online shopping</title>
</head>
<body>
<div id="wrapper">
<div id="search">
<div class="shell">
</form><div class="cl"> </div>
</div></div>
</div>
<div id="navigation">
<div class="shell"><ul>
</ul>
<div
class="cl"> </div>
</div></div><div id="slider">
<div class="slider-outer">
<div class="slide-entry">
<div class="slide-entry"></div>
<div class="slide-entry"></div>
<div class="slide-entry"></div>
<div class="cl"> </div>
<div class="slider-controls">
</div></div></div>
<div class="cl"> </div></div>
<div id="main">
<div class="inner">
<div
class="shell">
<?php
include("connected.php");
if(isset($_SESSION['user']))
$username=$_SESSION['user'];
$username;
} else {
</script>
<?php
?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Online Shopping</title>
</style>
<script language="javascript">
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></div></div>
<div id="mainContent">
<div id="mainContent1">
<div id="middletxtheadermain">
<div id="middletxt1">
<div
align="center"><imgsrc="images/r.png" alt="Online Shopping" width="650"
height="100"/></div></div></div>
<div id="middletxt">
</div></div></div>
</body>
</html>
</div></div></div>
<div id="footer">
<div class="shell">
<div class="cl"> </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.
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.
These are used for testing all the functional requirements are function able and access able
inthe environment of WAMP server.
Validation succeeds when software functions in a manner that can be reasonably expected by
the customer. It covers the following: -
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.
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.
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.